From Nsnam
Revision as of 21:56, 10 February 2012 by Tommaso (Talk | contribs) (Satellite stacks: Licklider Transmission Protocol (LTP))

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

GSoC 2012 Ideas

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

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 been in development since 2005 and has been making quarterly releases since June 2008 (our last release was ns-3.10 in January 2011). ns-3 is replacing the popular ns-2 tool which was developed in the 1997-2000 timeframe but became out of date and unmaintained. The tool is coming into wide use; our web server logged almost 71000 successful downloads of our released software between January 2010 and January 2011, and we have a users mailing list of about 900 members now averaging 200-300 posts per month.

Our GSoC organizational admin is Lalith Suresh and our backup org admin is Tom Henderson.

Project Ideas

The following are project ideas which the ns-3 team has identified as important and is most interested in working on as part of the 2012 Google Summer of Code. Applicants are however free to propose their own ideas. In addition, 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 an idea that you'd like to work on. 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 more stronger a proposal it will develop into, and the higher your chances of being accepted into the programme.

Each project idea 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.

Priority Project Ideas

The following are work areas the ns-3 project has identified as the highest priorities, has several mentors available, and would be especially interested in having students work on.

Project area


  • Project name: Detailed description of project goes here.
  • Technical Requirements
    • Required Experience:
    • Bonus Experience:
    • Interests:
    • Difficulty:
    • Recommended reading:

Stream Control Transmission Protocol (SCTP)

Mentors: Tommaso Pecorella

  • SCTP implementation and testing: SCTP is a message-based L4 protocol with features similar to both TCP and UDP. It was originally developed as a reliable protocol to transport PSTN control streams, and it's currently used to carry 3G and 4G signaling over IP networks. The use of SCTP, however, is not limited to signaling transport, as its features makes it very interesting for a lot of other applications where UDP or TCP fails. Currently there is no SCTP implementation for ns-3. An SCTP implementation would have to comply with the IPv4 and IPv6 layers and have programming APIs toward the application layer similar to the ones defined in the available SCTP implementations for Linux.
  • Required Experience: C++
  • Bonus Experience: L4 protocols understanding
  • Interests: L4 protocols modeling and simulation
  • Difficulty: medium
  • Recommended reading:
    • RFC 3286 An Introduction to the Stream Control Transmission Protocol
    • RFC 6458 Sockets API Extensions for the Stream Control Transmission Protocol
    • all the relevant RFCs about SCTP

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

Mentors: Tommaso Pecorella

  • 6LoWPAN-nd implementation and testing: 6LoWPAN-nd is novel draft 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: medium
  • Recommended reading:
    • RFC 4919 IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals
    • 6LoWPAN-nd Neighbor Discovery Optimization for Low Power and Lossy Networks

Vehicular Ad-hoc Networks

Mentors: Guillaume Rémy

  • Wireless Access in Vehicular Environments (WAVE) The IEEE 1609 Family of Standards for Wireless Access in Vehicular Environments (WAVE) defines the architecture, communications model, management structure, security mechanisms, and physical access for wireless communications in the vehicular environment. Some components of this specification has already been implemented for ns-3. However, we are still far from the simulation of WAVE on ns-3. The current status is as follows and it is up to the student to decide how much he/she wants to implement: 1) The PHY is ready as-is: the 5 MHz and 10 Mhz channel options (i.e., 802.11p) are already implemented, with a corresponding error model. 2) As for the PHY-specific parameters (slot duration etc.), currently only coverage class 0 is supported [0]. 3) The MAC needs to be modified. First, some trivial reworking is needed [1], and the rest depends on what the student wishes to implement. One possible approach is to use [2] as a guideline for implementing what is discussed in [3]. The most complex piece to implement are the channel switch logic (the execution of the channel switch command is already implemented) 4) higher layers: nothing specific to WAVE is currently available. 5) mobility models: no mobility model specific for vehicular scenarios is included in ns-3. But given that ns-3 can work with ns-2 mobility traces, it should be possible to find a mobility trace generator for vehicular scenarios that can be reused with ns-3.

Realistic spatial models for wireless link simulations

Mentors: Tommaso Pecorella

  • Spatial models for wireless links: Wireless system simulation is heavily dependant on the radio link assumptions. While several models exist for different scanarios (e.g., indoor, outdoor, etc.), radio-opaque obstacles are about always simulated with simple statistical assumptions. This is a suitable assumption only for some kind of scenarios, while in some other cases (e.g., vehicular networks, indoor low-power communications, etc.) this approach is not suitable. In order to increase the results accuracy it is needed to develop a link between spatial maps (2D and 3D) of radio-opaque objects so to properly calculate the link metrics, i.e., to properly adapt the link statistics. Two example scenarios could be: vehicular networks in a city and Wireless Sensor Netorks in a logistic area. The 2D / 3D maps should be read from scenario files, described in an open.source language chosen by the developer.
  • Required Experience: C++, 3D maps
  • Bonus Experience: radio link caracterization
  • Interests: wireless system realistic simulations
  • Difficulty: medium / hard
  • Recommended reading:
    • none

High-level architecture (HLA) interfaces for ns-3

Mentors: Tommaso Pecorella

  • High-level architecture interfaces: High-level architecture (IEEE 1516) is a standard system to define APIs between simulators, in order to achieve an effective simulator federation. Simulators federations are used to bind variousl kinds of simulators (e.g., scenario simulators, network simulators, phisical link simulators, etc.) into a powerful and flexible system able to perform complex analysis of high-level events (e.g., disaster recovery simulations). In such complex simulations it is impossible to build a single simulaiton tool, so simulators federation are mandatory. Ns-3 can play the role of an HLA element, provided that HLA support is added. This involves 1) applications level API, 2) mobility API, radio link quality API and possibly more.
  • Required Experience: C++
  • Bonus Experience: Simulators federation concepts
  • Interests: Complex scenarios simulations
  • Difficulty: hard
  • Recommended reading:

ns-3 Firewall model


  • ns-3-netfilter: Complex network scenarios do require an high level of accuracy in order to effectively mimic a realistic network. Nowadays, firewalls are an integral part of any network, and with IPv6 deployment it is expected an even wider spread in their use. The effects of a firewall presence can not be simply simulated by dropping off packets at the source nodes, neither at the receivers nodes. It is then useful to include a firewalling module in ns-3. The module should mimic the Linux netfilter behaviour and accept common iptables configuration files, so to ease its configuration. Moreover it should be able to filter both IPv4 and IPv6 packets and be structured so to allow different future implementations (e.g., BSD IPFW). Early work on this topic is present in one of ns-3 repositories, and might useful as starting point.
  • Required Experience: C++
  • Bonus Experience: Linux netfilter (iptables)
  • Interests: Network Firewalls
  • Difficulty: medium
  • Recommended reading:

Node stop / start models

Mentors: Tommaso Pecorella Vedran Miletić

  • Node stop / start: In wireless systems (but in wired systems as well) sometimes a node can fail due to general shutdown. This is pretty common in wireless systems, where nodes are battery-operated, however the same applies to wired systems, e.g., when a computer does a reboot. Currently in ns-3 there's no standardized way to handle this, and despite the presence of an Energy module, when the energy is depleted the node will not stop operating. A real module should as well handle the case of a node restarting, e.g., when the batteries are recharged or the reboot is finished.

The module should interface with the Energy module and allow a general applications to all the other relevant modules, ranging from Applications to MAC modules.

  • Required Experience: C++
  • Bonus Experience:
  • Interests: Node energy management
  • Difficulty: easy / medium
  • Recommended reading:
    • none

Network Address and Port Translation (NAT) models


  • ns-3-NAT NATs should burn. IPv6 rules and IPv4 should be declared as obsolete. Those statements could be true but the reality is different, we'll have to cope with NATs for some time more. Since we'll have to bear with NATs and private address spaces, it can be a good idea to be able to evaluate their effects in a complex network. The ns-3 NAT module should mimic the Linux NAT behaviour at minimum, and possibly be able to be configured so to behave like any other NAT variant. The compliance with PCP (Port Control Protocol) is a premium, but it's not strictly required.
  • Required Experience: C++
  • Bonus Experience: NAT and IPv4 translation tables
  • Interests: NATs and NAT traversal techniques
  • Difficulty: easy / medium
  • Recommended reading:

Deep Space networking: Licklider Transmission Protocol (LTP)

Mentors: Tommaso Pecorella

  • ns-3-LTP Licklider Transmission Protocol (LTP) is a point to point protocol for the use in deep space links. It have a number of interesting properties, mainly related to the constraints found in space links, like ultra-high round trip delay and so on. LTP is currenlty under revision as a proposed standard by the Consultative Committee for Space Data Systems (CCSDS), however its principles are well-known to the satellite networking community, RFCs and reference Linux implementations are available. An ns-3 implementation should comply with the already existing IETF specification and with the CCSDS one.
  • Required Experience: C++
  • Bonus Experience: Satellite and Deep Space networking
  • Interests: Deep Space networking
  • Difficulty: easy / medium
  • Recommended reading:

Additional Project Ideas

The following are additional project ideas that the ns-3 team has highlighted as important projects to support, and are suggested for students to extend. Not all of them have specific mentors assigned yet but we would seek out mentors from our mentor pool if high quality applications came in on these topics (or any ns-3 topic, for that matter).