GSOC2013Projects

From Nsnam
Jump to navigation Jump to search

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

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

GSoC 2013 Ideas

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

GSOC 2012 Timeline is:

  • March 18 - 19:00 UTC: Mentoring organizations can begin submitting applications to Google.
  • March 29 - 19:00 UTC: Mentoring organization application deadline.
  • April 8 - 19:00 UTC: List of accepted mentoring organizations published on the Google Summer of Code 2013 site.
  • April 9-21: Would-be student participants discuss application ideas with mentoring organizations.
  • April 22 - 19:00 UTC: Student application period opens.
  • May 3 - 19:00 UTC: Student application deadline.

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

While discussions about ideas can be done earlier, please note that ns-3 will not receive an answer to its GSOC application before April 8.

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 51,000 successful downloads of our released software between January 2011 and January 2012, and we have a users mailing list of about 2392 members now averaging 574 posts per month. The code base has a total of 113 authors and 25 maintainers.

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

Our mentor pool for this year:

Getting started

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


Project Ideas

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


High Priority Projects

Project Idea Example

Mentors: Mentor Person

  • Project description: High level description of project.
    • Required Experience: C++, Linux kernel hacking, something.
    • Interests: Emulation, Foo, Bar.
    • Difficulty: easy/medium/hard.
    • Recommended reading:
      • Reference 1
      • Reference 2

Medium Priority Projects

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. However, there is an alternative solution that implements 802.11 layers: PhySim [4], that does a more accurate job and is more appropriate for vehicular network simulations. Depending on the skills of the student, it could be possible to properly integrate PhySim in the latest NS-3 version, and start WAVE implementation on top of it.
  2. 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)
  3. higher layers: nothing specific to WAVE is currently available.
  4. 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 (e.g. SUMO).


Simulating the Internet of Things in NS-3

Mentors: Peter Kourzanov, Hong.R. Li

In this project we hope to improve the Wireless Personal Area Network (WPAN) support in NS-3. In particular, the aim is to bring higher-level ZB models [7] and the underlying 802.15.4 Low-Rate WPAN (LR-WPAN) models [6] in NS-3 to the level at which large-scale simulations can be validated against real-system test-beds. In particular, current NS-3 work mentions missing support for the beaconing (i.e., slotted) mode [2], no support for ZB and ZBP standards [1], as well as lack of validation against real Hardware (HW) [2]. Older, but mature ZB 2003 code from NS-2 [5] can be taken as a starting point, although we expect that a significant effort shall be spent on porting it to NS-3 and upgrading it from ZB 2003 to ZBP 2007/2012 compliance. Alternatively, a new implementation of ZBP and/or extensions for ZBP 2012 and ZBGP might need to be developed for NS-3. This project can be executed on the premises of NXP Semiconductors Research in Eindhoven (Netherlands), Sheffield (United Kingdom) and/or in Singapore which in this case will donate a WSN test-bed for experimentation and validation. The work can be partially (excluding validation) executed remotely, with no access to the test-bed.The resulting code shall be contributed to the NS-3 community.

    • Required experience : C++
    • Bonus experience : NS-2, WSN, Matlab
    • Interests : ZB, embedded, wireless, sensor networks
    • Difficulty : medium
    • Recommended reading :
      1. LR-WPAN status page
      2. LR-WPAN model-library document
      3. Preliminary LR-WPAN code for NS-3
      4. Preliminary IPv6 over Low-power WPAN (6LoWPAN) code for NS-3
      5. Mature implementation of ZB 2003 in NS-2 (included in version 2.35)
      6. LR-WPAN page on Wikipedia
      7. ZB page on Wikipedia


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, 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
      • 6LoWPAN-nd Neighbor Discovery Optimization for Low Power and Lossy Networks


=== RPL protocol Metric and Constraints ===Mentors: Tommaso Pecorella* RPL protocol Metric and Constraints: The RPL protocol is a flexible routing protocol for Wireless Sensor Networks. The actual ns-3 module is implementing only some basic metrics such as Hop Count and ETX.The RPL module is in active development and it is not publicly available, however the code will be provided to the student before the program start.The goal of the idea is to extend the actual implementation so to support other metric kinds and options (additive, min-max, etc.).** Required Experience: C++, IPv6,** Bonus Experience: RPL protocol** Interests: WSN, routing ** Difficulty: medium** Recommended reading:*** RFC 6550 RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks*** RFC 6551 Routing Metrics Used for Path alculation in 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.
    2. Flow Monitor module does not work on the IPv6 stack
    3. FlowLabel header field is not currenly 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.


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

Low Priority Projects

Retrieved from "https://www.nsnam.org/mediawiki/index.php?title=GSOC2013Projects&oldid=7445"