GSOC2014Projects

Main Page - Roadmap - Summer Projects - Project Ideas - Developer FAQ - Tools - Related Projects

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

• GSoC Frequently Asked Questions
• GSoC Mentor guide
• GSoC student guide
• ns-3's GSoC Student guide
• ns-3's GSoC Mentor guide
• GSoC Student Selection Process
• Patch Requirement Guidelines
• GSoC Student application template
• GSoC 2013 page | GSoC 2013 Accepted Projects
• GSoC 2012 page | GSoC 2012 Accepted Projects
• NSoC 2011 Ideas page | NSoC 2011 Accepted Projects
• GSoC 2010 Ideas page | GSoC 2010 Accepted Projects
• GSoC 2009 Ideas page | GSoC 2009 Accepted Projects
• GSoC Organization Administrator guide
• Get in contact with the ns-3 team: ns-developers mailing list | IRC #ns-3 on freenode.net

GSoC 2014 Ideas

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

GSOC 2014 Timeline is:

• February 3 - 20:00 UTC: Mentoring organizations can begin submitting applications to Google.
• February 14 - 20:00 UTC: Mentoring organization application deadline.
• February 24 - 20:00 UTC: List of accepted mentoring organizations published on the Google Summer of Code 2014 site.
• February 24 - March 21: Would-be student participants discuss application ideas with mentoring organizations.
• March 10 - 19:00 UTC: Student application period opens.
• March 21 - 19:00 UTC: Student application deadline.
• April 21 - 19:00 UTC: Student selections announced
• May 19 - Coding begins
• August 18 - Coding ends

Full timeline is here: http://www.google-melange.com/gsoc/events/google/gsoc2014

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

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

ns-3 is one of 190 mentoring organizations, and at other organizations have posted project ideas related to ns-3 in the past. For instance, the Wiselib project has listed ns-3 integration as one of its project ideas at http://www.Wiselib.org/gsoc.

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.

Getting started

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

• Read the official GSoC student guide.
• Read ns-3's GSoC Student guide.
• Look through our ideas list below to see if you find a project that interests you.
• Review the ns-3 tutorial thoroughly, if you have not already done so.
• Look through the GSoC Student application template to start preparing your proposal.
• Next, proceed to get in touch with the developers on the mailing list and refine your proposal.
• 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.

Project Ideas

The following are a list of project proposals from the ns-3 team for Google Summer of Code 2014. 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 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.

Guidelines for project ideas

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 or they directly apply to an ns-3 module that is in the process of merging with ns-3-dev.

Project Ideas

Please see last year's page for guidelines on how to create project ideas.

Note to students: These ideas are not listed in any priority order, and other project ideas not listed here are also encouraged.

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.
• Required Experience: C++, sockets API
• Interests:
• Difficulty: easy/medium
• Recommended reading:
  • Unix Network Programming (Stevens) or equivalent
  • Previous thread on this topic: http://mailman.isi.edu/pipermail/ns-developers/2007-July/003136.html
• Bonus points: How would you implement backpressure on the traffic generator? See https://www.nsnam.org/bugzilla/show_bug.cgi?id=1006

ARP and NDisc cache visibility

Mentors: Tom Henderson Vedran Miletić

• There is no API for reading and manipulating the IPv4 ARP and IPv6 Neighbor Discovery caches. Something similar to how PrintRoutes is done for IPv4 would be useful. Additional work on this project could focus on IP address handling for interfaces (bugs 757 and 760), and bug 187 (enabling perfect ARP).
• Required Experience: C++
• Interests: IPv4 and Ipv6
• Difficulty: easy/medium
• Recommended reading:
  • source code in src/internet, and the bugs mentioned above

INSTOOLS for ns-3

Mentors: Tom Henderson

INSTOOLS for ns-3: INSTOOLS is a software instrumentation package for GENI experiments. It logs a lot of artifacts of experiments, such as ARP and IP routing tables, Netflow graphs, etc, to databases. The aim of this project is to instrument ns-3 nodes to capture as much of this data as is applicable. A bonus is to try to integrate further with ProtoGENI and INSTOOLS such as making the ns-3 data archived just like it was a GENI experiment.

• Required Experience: Familiarity with Linux networking and with C++ programming.
• Bonus Experience: Experience with GENI and/or Emulab
• Interests: Simulator tool development, integration with testbed experiments
• Difficulty: Medium
• Recommended Reading: http://groups.geni.net/geni/wiki/InstrumentationTools

bufferbloat-related models

Mentors: Tom Henderson Dave Taht

bufferbloat models: Bufferbloat is an interesting contemporary research topic. This project proposal is to develop models, examples, and visualizations around the bufferbloat problem. Some technical solutions include Linux Byte Queue Limits (BQL) and active queue management (AQM) techniques (we just have RED queues in ns-3-dev but no models yet for the others). Note: There is already some ns-3 code available (see below) but the authors have not updated it for a while; this or some recent ns-2 code could be a starting point. Also, work could be done on using actual Linux code in the ns-3 Direct Code Execution (DCE) project.

• Interests: Internet performance, linux kernel networking
• Difficulty: easy to hard, depending on the depth of the project
• Recommended reading:
  • http://gettys.wordpress.com/category/bufferbloat/
  • CeroWrt
  • ICCRG presentation
  • ns-2 code
  • ns-3 code review

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.

• Required Experience: C++, WSN
• Bonus Experience: ns-3 Energy model, lr-wpan module
• Interests: WSN, Battery discharge
• Difficulty: hard
• Recommended reading:
  • Software-based On-line Energy Estimation for Sensor Nodes
  • On the Accuracy of Software-based Energy Estimation Techniques
  • The ContikiMAC Radio Duty Cycling Protocol

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 Standard

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:
  • 802.15.4 Standard

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, RPL
• 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

IPv6 stack validation and improvements

Mentors: Tommaso Pecorella

IPv6 stack validation and improvements: IPv6 use is going to increase dramatically in the next years. Various international projects are required to use IPv6 (e.g., EU FP7, EU 2020, etc.). Hence, simulations should be run on IPv6 rather than IPv4, and it is becoming an imperative action to have a reliable, full-featured IPv6 stack for ns-3. IPv6 stack for ns-3 works, but it lacks a number of interesting and useful features. A few missing features are (the list is not exhaustive):

1. There is no path MTU discovery see also RFC 1981. Added in 3.20
2. Flow Monitor module does not work on the IPv6 stack. Added in 3.20
3. FlowLabel header field is not currently used.
4. IPSec is not supported.

The candidate should check the missing features and select a set to develop and test. A general test of the IPv6 stack to be done against a reference Linux implementation is a premium.

• Required Experience: C++, TCP/IP networking
• Bonus Experience: IPv6 protocols
• Interests: IPv6 internetworking
• Difficulty: easy / medium, depending on the features implemented
• Recommended reading:
  • RFC 4294 - IPv6 Node Requirements
  • RFC 1981 - Path MTU Discovery for IP version 6
  • ns-3 Flowmon module documentation
  • RFC 6437 - IPv6 Flow Label Specification
  • RFC 4302 - IP Authentication Header
  • RFC 4303 - IP Encapsulating Security Payload (ESP)

Multicast IPv6 traffic support

Mentors: Tommaso Pecorella

Multicast IPv6 traffic: Multicast traffic support is of paramount importance for IPv6 networks. While Multicast traffic is used everyday with local addresses, and ns-3 is supporting it, MLDv2 and PIM are missing. As a consequence global multicast routes must be manually set in routers, which is cumbersome, error-prone and not suitable for realistic scenarios, where the users are joining/leaving multicast groups on the fly. The implementor will have to both modify the actual routing protocols so to enable dynamic multicast routes support and to actually develop the MLDv2 and/or the PIM protocol modules.

• Required Experience: C++, IPv6,
• Bonus Experience: Multicast routing protocols (MLDv2/IGMPv3 and PIM)
• Interests: routing, multicast
• Difficulty: medium/hard
• Recommended reading:
  • Multicast Technology White Paper
  • IPv6 Multicasting
  • All the relevant RFCs (search in RFC Editor search engine)

Licklider Transmission Protocol (LTP)

Mentors: Tommaso Pecorella Luca Ronga

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:
  • Licklider Transmission Protocol
  • RFC 5325: Licklider Transmission Protocol—Motivation
  • RFC 5326: Licklider Transmission Protocol—Specification
  • Licklider Transmission Protocol (LTP) for CCSDS

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.

• Required Experience: C++, LTE
• Interests: Mobility Management in LTE
• Difficulty: hard
• Recommended reading:
  • documentation of the UE Measurement model in the ns-3 LTE module
  • 3GPP TS 36.331 section 5.5 Measurements
  • 3GPP TS 36.133, Section 8.2 UE Measurements Procedures in RRC_CONNECTED State

LTE Fractional Frequency Reuse algorithms

Mentors: Nicola Baldo Marco Miozzo

• The aim of this project is to develop a set of state-of-the-art Fractional Frequency Reuse algorithm implementations for the ns-3 LTE module. Interested students shall select a set of representative algorithms published in the scientific literature, and implement them in ns-3. The implementation shall be done within the LTE MAC Scheduler leveraging the X2 SON primitives.
• Required Experience: C++, LTE
• Interests: Self Organized Networks, HetNets, Inter Cell Interference Coordination
• Difficulty: hard
• Recommended reading:
  • LTE MAC in ns-3
  • LTE SON primitives in ns-3
  • Thomas Novlan, Jeffrey G. Andrews, Illsoo Sohn, Radha Krishna Ganti, Arunabha Ghosh, "Comparison of Fractional Frequency Reuse Approaches in the OFDMA Cellular Downlink"
  • Alexander L. Stolyar, Harish Viswanathan, "Self-organizing Dynamic Fractional Frequency Reuse for Best-Effort Traffic Through Distributed Inter-cell Coordination"
  • Heui-Chang Lee, Dong-Chan Oh, and Yong-Hwan Lee, "Mitigation of Inter-Femtocell Interference with Adaptive Fractional Frequency Reuse"
  • there are lots of other papers on this topic, please do your own research

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:
  • ns-3 spectrum module documentation
  • http://en.wikipedia.org/wiki/OpenCL
  • http://en.wikipedia.org/wiki/CUDA

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

Improve ns-3 support to sensor networks, RIOT adaptation

Mentors: Daniel Camara

The wireless sensor networks field is a rising star in terms of research, the number of applications and problems related to it increases every day. In fact, a whole new set of other research fields rely heavily on wireless sensor networks. E.g. smart cities, internet of the things, vehicular networks and public safety networks . This project intends to improve the support of ns-3 to to sensor networks. RIOT[1][2] is a brand new operating system for wireless sensor networks. It has a series of interesting characteristics that makes it a perfect candidate to became THE standard OS for small sensor devices.

This project intends to enable the execution of several instances of RIOT OS, over the same machine, and link these instances using ns-3. Why to simulate a sensor devices if we can emulate a whole network using a real sensor OS? Not only the simulations will be more realistic, but also we will be sure that the applications developed over this simulation environment will run seamless over real sensor nodes. The importance of this project is two folded. Without a shadow of a doubt it will be important and useful for the ns-3 community. However, up today RIOT still does not have a standard simulation environment. This project will provide RIOT users an invaluable access to the whole power of ns-3 simulations. It will be a tool that will be certainly used on all future developments and tests of RIOT.

• Support: The RIOT developers are interested on this project, since it will make their life easier ;). This means we will have access to them and any doubts about the operating system itself should be fast addressed by them.

• Required Experience: C/C++
• Interests: Sensor networks, simulation, operating systems
• Difficulty: medium
• Recommended reading:
  • [1] E. Baccelli, O. Hahm, M. Wählisch, M. Günes, T. C. Schmidt, RIOT: One OS to Rule Them All in the IoT, INRIA Research Report N° 8176, Project-Team HiPERCOM, ISSN 0249-6399 ISRN INRIA/RR--8176--FR+ENG, December 2012
  • [2] RIOT OS web site, http://riot-os.github.io/RIOT/
  • [3] Heiko Will, Kaspar Schleiser, Jochen Schiller, A Real-Time Kernel for Wireless Sensor Networks Employed in Rescue Scenarios The 4th IEEE International Workshop on Practical Issues In Building Sensor Network Applications (SenseApp 2009) Zürich, Switzerland; 20-23 October 2009

Port ns-3 components to Python 3.3 and improve Python code quality

Mentors: To be determined

Linux distributions in 2014 are expected to transition away from Python 2.7 support to Python 3.3 support. Ubuntu 14.04 release is already planning a Python 3.3-only default.

ns-3 has several components that rely on Python, and not all are Python 3.3+ compatible. This GSoC project would focus on updating our bindings generation process (pygccxml), PyViz visualizer, and wscript files (used by Waf) to support Python 3.3. Regarding wscript files in particular, student should also propose a refactoring and reorganization to make them easier to maintain in the future.

• Required Experience: C++ and Python
• Interests: Python development
• Difficulty: medium
• Recommended reading: pygccxml: http://sourceforge.net/projects/pygccxml/
• Recommended reading: Discussion on ns-developers list: http://mailman.isi.edu/pipermail/ns-developers/2014-March/011794.html

Time Synchronization Channel Hopping

Mentors: Peter Kourzanov, Hong Li

The Internet of Things (IoT) needs extensive simulations to prove that the radios, the protocols, the middle-ware and the applications are up to the task of scaling technology both in numbers and in power consumption. One of the approaches to provide such scaling is represented by the IEEE 802.15.4 Low-Rate WPAN (LR-WPAN) and the subsequent 15.4e standards, including the Time Scheduled Channel Hopping (TSCH) part. 6TiSCH offers the Internet Protocol (IP) based solution for Open Systems Interconnect (OSI) layer 3-7, including an application layer (COAP).

The challenge of this task is to bring the implementation of 15.4 models in NS-3 to a level where existing components such as RPL, IPv6 and optionally CBOR/COAP can be evaluated on top of channel models present in NS-3. This entails adapting the preliminary LR-WPAN models to include 15.4e and validating the results using one of the commercially available 15.4 implementations.

• Required experience: C++
• Bonus experience: Wireless Sensor Networks (WSN), Matlab
• Interests: embedded, wireless, sensor networks
• Difficulty: medium
• Recommended reading:
  • LR-WPAN status page
  • Preliminary LR-WPAN code for ns-3
  • LR-WPAN page on Wikipedia
  • 6TiSCH status pages