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 2013 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. The project has participated in past GSoCs during 2008-10 and 2012.

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 Lalith Suresh 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 177 mentoring organizations, and at least one other organization (possibly more) has posted project ideas related to ns-3. 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:

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

Vehicular Ad-hoc Networks

Mentors: Guillaume Rémy and Darwin Astudillo

  • 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).

802.15.4 Energy Model

Mentors: Tommaso Pecorella

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:


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.


High performance ns-3 emulation with Direct NIC Access

Mentors: José Nuñez

The current ns-3 emulation framework has certain limitations in terms of throughput performance, due to the computationally intensive polling between the user space ns-3 instance and the kernel. One reason for this limitation is the use of PF_INET sockets. An alternative that is expected to yield better performance is the use of PF_RING sockets. As part of this project, the student shall integrate the use of PF_RING sockets into the ns-3 emulation framework. For example, the student could create a new class HighSpeedEmuNetDevice using PF_RING sockets, and then do some profiling to verify the improvement in performance with respect to the existing ns-3 EmuNetDevice.


LTE Idle Mode Procedures

Mentors: Jaime Ferragut Nicola Baldo

  • The current ns-3 LTE module does not support idle mode procedures. As part of the GSoC, a student could consider implementing one or more of the following procedures: Cell selection and reselection, Paging, Tracking Area Update.
  • Required Experience: C++, LTE
  • Interests: mobility management
  • Difficulty: medium/hard
  • Recommended reading:
    • 3GPP TS 36.300 "E-UTRA and E-UTRAN overall description", section 10.1.1 "Mobility Management in ECM-IDLE"
    • 3GPP TS 36.304 "User Equipment (UE) procedures in idle mode"
    • 3GPP TS 24.301 "Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS)"


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


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

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 could be a starting point. Also, work could be done on using actual Linux code in the ns-3 Direct Code Execution (DCE) project.


High performance ns-3 emulation with Direct NIC Access (2)

Mentors: Hajime Tazaki

The current ns-3 emulation framework has certain limitations in terms of throughput performance, due to the computationally intensive polling between the user space ns-3 instance and the kernel. One reason for this limitation is the use of PF_INET sockets. An alternative that is expected to yield better performance is the use of netmap packet I/O.

The target of this project would be:

  1. Identifying the bottle of ns-3. Using profiler (oprofile etc) would be the start point.
  2. Introducing netmap interface as a FdNetDeviceHelper.
  3. Performance comparison between existing one (i.e., EmuNetDevice) with the netmap one.
  4. Creating a patch for fdnetdevice module (and ask reviews).
  5. Documentation including how netmap should be installed/configured. Though netmap supports FreeBSD platform, it is fine to start only with Linux version in this project.

Linux SCTP support over DCE

Mentors: Hajime Tazaki

Stream Control Transmission Protocol (SCTP) is an alternate transport protocol rather than traditional TCP and UDP. It covers a broad feature for application messaging, but one of interesting feature is using multiple streams in a single session. Almost none of applications are using SCTP at this moment in fact, but it is used in the back-end of LTE.

In this project, instead of implementing huge amount of specification of SCTP (134 pages in RFC 2960), we reuse existing Linux implementation over Direct Code Execution (DCE). DCE allows us to simulate existing implementation over ns-3 without (ideally) modifying original code.

The target of this project would be:

  1. Modifying DCE Linux module to support SCTP
    1. enabling CONFIG_IP_SCTP option (and related one) and build it (I have incomplete patch)
    2. writing simple SCTP program (I also have)
    3. writing sample scenario script using above SCTP program (I also have)
  2. Implement missing part of DCE Linux module to run SCTP code over ns-3
  3. Implement DCE Cradle wrapper socket for SCTP (optional)
  4. Create patch for ns-3-dce (and code review)


Road Topology Model

Mentors: Nicholas Loulloudes


Envisioned protocols, services and applications that will be developed and deployed on VANET-enabled vehicles, will require knowledge of the underlying road topology. Since the ns-3 community aims at supporting network simulations for the vehicular environments, it is important to develop a road-topology model in ns-3. Currently, vehicle movement in ns-3 is simulated by utilizing traces in the ns-2 mobility format. These traces can be generated and exported using a number of traffic simulators such as SUMO[1], VanetMobiSim[2], etc. However, given the simplicity of the ns-2 mobility format (x-y-z coordinates), nodes in the simulation are agnostic of the underlying road topology map, and hence they cannot evaluate if for example they are moving on an arterial road, or a city road or they are stopped at an intersection. A solution to this, is to provide the ability to import in ns-3 a map of the simulated area either from a public repository such as OpenStreetMap.org [3], or TigerMaps[4] or from a traffic simulator such as SUMO[3]. By parsing the map file before the simulation start, the road topology model can be populated with information such as: the structure of the road network (roads and junctions), speed limits / one-way streets, number of lanes, traffic lights etc. In addition, the necessary mechanisms should be developed, to enable each node in the simulation (i.e a vehicle) , to identify its whereabouts on the road-topology based on its current geographic coordinates.


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.

The target of this project would be:

  1. Create a RIOT interface at ns-3
  2. Create a ns-3 architecture for RIOT
  3. Link these two parts taking into account:
    1. Real time/non-real time simulations (ns-3 clock should be used to control RIOT machines)
    2. Implement an interrupt handler for creating ns-3 events on the ns-3 scheduler
    3. Interaction between ns-3 and RIOT schedulers
    4. Implement the communication between RIOT nodes
    5. Implement the RIOT Physical layer
    6. Provide mechanisms to interconnect RIOT machines using RIOT mac and standard ns-3 PHY-MAC layers
  4. Provide tests
  5. Provide examples of execution
  6. Provide a good documentation support of the project
  • 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

Extension of the LTE HO algorithm and UE measurements support

Mentors: Nicola Baldo Marco Miozzo Manuel Requena

  • The ns-3 LTE module provides only basic functionality for supporting HO decision making algorithms. In detail, the UE measurement model currently includes only 2 events from the 6 defined by 3GPP. The project aims at overcome this limitation of the module in order to provide HO algorithms, and in general RRM ones, the comprehensive set of triggers for performing smart HO, load balancing and QoS management. The project could cover all or some of the following steps in order to adapt the effort to the GSoC time constraints:
    • a) Implementation of intra-freq UE measurements report triggering (the existing support for A2 and A4 can be taken as an example)
    • b) Refinement of the HO procedure (see the reference model [5] and the state of the art [6]; other proposals by the student could be considered as well)
    • c) Implementation of inter-freq UE measurements: task devoted to the extension of the measurements to other frequencies respect the one of the serving cell (imply work on Mac, Scheduler and Phy layer)
  • Required Experience: C++, LTE
  • Interests: LTE, 3GPP, RRM
  • Difficulty:
    • a) easy
    • b) medium
    • c) hard
  • Recommended reading:
Retrieved from "https://www.nsnam.org/mediawiki/index.php?title=GSOC2013Projects&oldid=7545"