https://www.nsnam.org/mediawiki/api.php?action=feedcontributions&user=Nicolabaldo&feedformat=atomNsnam - User contributions [en]2024-03-28T09:07:21ZUser contributionsMediaWiki 1.24.1https://www.nsnam.org/mediawiki/index.php?title=GSOC2015Projects&diff=9313GSOC2015Projects2015-02-19T11:39:10Z<p>Nicolabaldo: /* ns-3's GSoC 2015 */</p>
<hr />
<div>{{TOC}}<br />
<br />
'''Note:''' ns-3 is applying but has not yet been selected for GSoC 2015; Google will announce selected organizations on March 2.<br />
<br />
* [http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2015/help_page GSoC Frequently Asked Questions]<br />
* [http://en.flossmanuals.net/gsocmentoring/ GSoC Mentor guide]<br />
* [http://en.flossmanuals.net/GSoCStudentGuide/ GSoC student guide]<br />
* [[GSOC2014StudentGuide |ns-3's GSoC Student guide (from 2014)]]<br />
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br />
* [[GSOCSelectionProcess | GSoC Student Selection Process]]<br />
* [[GSOC2014PatchRequirement | Patch Requirement Guidelines (from 2014) ]]<br />
* [[GSOC2014StudentApplicationTemplate |GSoC Student application template (from 2014)]]<br />
* ''Get in contact with the ns-3 team'': [http://mailman.isi.edu/mailman/listinfo/ns-developers ns-developers mailing list] | ''IRC'' #ns-3 on freenode.net<br />
<br />
== ns-3's GSoC 2015 ==<br />
<br />
This webpage highlights project ideas for ns-3's Google Summer of Code 2015 effort, should ns-3 be selected to participate.<br />
<br />
The ten week coding period for projects runs from 25 May to 21 August, 2015. The full project timeline is here: http://www.google-melange.com/gsoc/events/google/gsoc2015<br />
<br />
=== About the ns-3 project ===<br />
<br />
ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br />
<br />
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.<br />
<br />
Our GSoC organizational admin is [mailto:tomhend@u.washington.edu Tom Henderson] and our backup org admin is [mailto:tpecorella@mac.com Tommaso Pecorella]. The project has participated in past GSoCs during 2008-10 and 2012-14.<br />
<br />
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.<br />
<br />
=== ns-3 and other GSoC mentoring organisations ===<br />
<br />
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.<br />
<br />
=== Students: how to participate ===<br />
<br />
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:<br />
* Read the official [http://en.flossmanuals.net/GSoCStudentGuide/ GSoC student guide].<br />
* Read [[GSOC2014StudentGuide |ns-3's GSoC Student guide]].<br />
* Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br />
* Review the [http://www.nsnam.org/ns-3-22/documentation/ns-3 tutorial] thoroughly, if you have not already done so.<br />
* Look through the [[GSOC2014StudentApplicationTemplate |GSoC Student application template]] to start preparing your proposal.<br />
* Next, proceed to get in touch with the developers on the mailing list and refine your proposal.<br />
* In parallel, make sure you prepare a patch as per the [[GSOC2014PatchRequirement | Patch Requirement Guidelines]]. Your application to ns-3 will not be considered if you do not fulfill this requirement.<br />
<br />
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 [http://mailman.isi.edu/mailman/listinfo/ns-developers 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 [http://mailman.isi.edu/mailman/listinfo/ns-developers 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.<br />
<br />
<blockquote><br />
Each project idea within a particular priority has been tagged with the following properties:<br />
* ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br />
* ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br />
* ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful students might apply their experiences coming out of this project.<br />
* ''Difficulty:'' easy, medium or difficult<br />
* ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br />
<br />
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.<br />
</blockquote><br />
<br />
=== Mentors: how to participate ===<br />
<br />
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:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
== Project Ideas ==<br />
<br />
'''Note to students:''' These ideas are not listed in any priority order.<br />
<br />
==== Decouple traffic generators from sockets ====<br />
<br />
Mentors: [mailto:tomh@tomh.org Tom Henderson] [mailto:rivanvx@gmail.com Vedran Miletić]<br />
<br />
* 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.<br />
* ''Required Experience:'' C++, sockets API<br />
* ''Interests:'' <br />
* ''Difficulty:'' easy/medium<br />
* ''Recommended reading:''<br />
** Unix Network Programming (Stevens) or equivalent<br />
** Previous thread on this topic: http://mailman.isi.edu/pipermail/ns-developers/2007-July/003136.html<br />
* ''Bonus points:'' How would you implement backpressure on the traffic generator? See https://www.nsnam.org/bugzilla/show_bug.cgi?id=1006<br />
<br />
==== ARP and NDisc cache visibility ====<br />
<br />
Mentors: [mailto:tomh@tomh.org Tom Henderson] [mailto:rivanvx@gmail.com Vedran Miletić]<br />
<br />
* 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).<br />
* ''Required Experience:'' C++<br />
* ''Interests:'' IPv4 and Ipv6<br />
* ''Difficulty:'' easy/medium<br />
* ''Recommended reading:''<br />
** source code in src/internet, and the bugs mentioned above<br />
<br />
<br />
==== Inter-frequency measurement support for the LTE module ====<br />
<br />
Mentors: [mailto:nbaldo@cttc.es Nicola Baldo] [mailto:mmiozzo@cttc.es Marco Miozzo]<br />
<br />
* 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. <br />
<br />
* ''Required Experience:'' C++, LTE<br />
* ''Interests:'' Mobility Management in LTE<br />
* ''Difficulty:'' hard<br />
* ''Recommended reading:''<br />
** [http://www.nsnam.org/docs/release/3.19/models/html/lte-design.html#ue-rrc-measurements-model documentation of the UE Measurement model in the ns-3 LTE module]<br />
** 3GPP TS 36.331 section 5.5 Measurements<br />
** 3GPP TS 36.133, Section 8.2 UE Measurements Procedures in RRC_CONNECTED State <br />
<br />
<br />
==== GPU acceleration for vector arithmetics in the spectrum module ====<br />
<br />
Mentors: [mailto:nbaldo@cttc.es Nicola Baldo] [mailto:mmiozzo@cttc.es Marco Miozzo]<br />
<br />
* 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). <br />
* ''Required Experience:'' C++<br />
* ''Bonus Experience:'' CUDA, OpenCL...<br />
* ''Interests:'' GPU acceleration<br />
* ''Difficulty:'' hard<br />
* ''Recommended reading:''<br />
** [http://www.nsnam.org/docs/models/html/spectrum.html ns-3 spectrum module documentation]<br />
** http://en.wikipedia.org/wiki/OpenCL<br />
** http://en.wikipedia.org/wiki/CUDA<br />
<br />
<br />
==== Carrier Aggregation support for the LTE module ====<br />
<br />
Mentors: [mailto:mmiozzo@cttc.es Marco Miozzo] [mailto:nbaldo@cttc.es Nicola Baldo]<br />
<br />
* 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.<br />
<br />
* ''Required Experience:'' C++, LTE<br />
* ''Interests:'' LTE-A, HetNet<br />
* ''Difficulty:'' hard<br />
* ''Recommended reading:''<br />
** LTE-A HetNets using Carrier Aggregation, Nomor whitepaper [http://www.nomor.de/uploads/db/a3/dba3e71e617a0ab4b7d3821afd59cc5e/Newsletter_CA_HetNet_2013-06.pdf]<br />
** [http://www.nsnam.org/docs/release/3.19/models/html/lte-design.html]<br />
** 3GPP TS 36.211 <br />
** 3GPP TS 36.213<br />
** 3GPP TS 36.331<br />
<br />
<br />
==== Support of RRC IDLE mode procedures for the LTE module ====<br />
<br />
Mentors: [mailto:nbaldo@cttc.es Nicola Baldo] [mailto:mmiozzo@cttc.es Marco Miozzo] <br />
<br />
* 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.<br />
* ''Required Experience:'' C++, LTE<br />
* ''Interests:'' Mobility Management in LTE systems<br />
* ''Difficulty:'' hard<br />
* ''Recommended reading:''<br />
** 3GPP TS 36.304 [http://www.3gpp.org/DynaReport/36304.htm]<br />
** 3GPP TS 23.401, Section 5.3.3 ("Tracking Area Update Procedures") [http://www.3gpp.org/DynaReport/23401.htm]<br />
** 3GPP TS 36.331<br />
<br />
==== 802.15.4 realistic MAC and Energy Model ====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br />
<br />
'''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.<br />
The goal of the project are:<br />
# Model the 4-state radio model (Sleep, Tx, Rx, Transitioning)<br />
# Develop one 'realistic' MAC model (the choice is left to the student)<br />
# Link the 4-state model with the Energy module.<br />
<br />
* ''Required Experience:'' C++, WSN<br />
* ''Bonus Experience:'' ns-3 Energy model, lr-wpan module<br />
* ''Interests:'' WSN, Battery discharge<br />
* ''Difficulty:'' hard<br />
* ''Recommended reading:''<br />
** [http://www.sics.se/~adam/dunkels07softwarebased.pdf Software-based On-line Energy Estimation for Sensor Nodes] <br />
** [http://cds.unibe.ch/research/pub_files/HBNH11.pdf On the Accuracy of Software-based Energy Estimation Techniques]<br />
** [http://dunkels.com/adam/dunkels11contikimac.pdf The ContikiMAC Radio Duty Cycling Protocol]<br />
<br />
==== 802.15.4 Bootstrap ====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br />
<br />
'''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.<br />
* ''Required Experience:'' C++, WSN<br />
* ''Bonus Experience:'' 802.15.4 standard<br />
* ''Interests:'' WSN<br />
* ''Difficulty:'' medium<br />
* ''Recommended reading:''<br />
** [http://standards.ieee.org/getieee802/download/802.15.4-2011.pdf 802.15.4 Standard]<br />
<br />
<br />
==== 802.15.4 Beacon-enabled mode ====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br />
<br />
'''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. <br />
* ''Required Experience:'' C++, WSN<br />
* ''Bonus Experience:'' 802.15.4 standard<br />
* ''Interests:'' WSN<br />
* ''Difficulty:'' medium/hard<br />
* ''Recommended reading:''<br />
** [http://standards.ieee.org/getieee802/download/802.15.4-2011.pdf 802.15.4 Standard]<br />
<br />
==== Neighbor Discovery Optimization for Low Power and Lossy Networks (6LoWPAN-nd) ====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br />
<br />
'''6LoWPAN-nd implementation and testing:''' [https://datatracker.ietf.org/doc/rfc6775/ 6LoWPAN-nd] is novel protocol from IETF's [http://tools.ietf.org/wg/6lowpan/ 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. <br />
* ''Required Experience:'' C++, IPv6<br />
* ''Bonus Experience:'' WSN networking<br />
* ''Interests:'' WSN, IPv6, node bootstrap, efficient packet compression <br />
* ''Difficulty:'' hard<br />
* ''Recommended reading:''<br />
** [http://tools.ietf.org/html/rfc4919 RFC 4919] IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals<br />
** [https://datatracker.ietf.org/doc/rfc6775/ RFC 6775] Neighbor Discovery Optimization for Low Power and Lossy Networks<br />
<br />
<br />
<br />
[[Category:GSoC]]</div>Nicolabaldohttps://www.nsnam.org/mediawiki/index.php?title=GSOC2015Projects&diff=9312GSOC2015Projects2015-02-19T11:38:22Z<p>Nicolabaldo: </p>
<hr />
<div>{{TOC}}<br />
<br />
'''Note:''' ns-3 is applying but has not yet been selected for GSoC 2015; Google will announce selected organizations on March 2.<br />
<br />
* [http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2015/help_page GSoC Frequently Asked Questions]<br />
* [http://en.flossmanuals.net/gsocmentoring/ GSoC Mentor guide]<br />
* [http://en.flossmanuals.net/GSoCStudentGuide/ GSoC student guide]<br />
* [[GSOC2014StudentGuide |ns-3's GSoC Student guide (from 2014)]]<br />
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br />
* [[GSOCSelectionProcess | GSoC Student Selection Process]]<br />
* [[GSOC2014PatchRequirement | Patch Requirement Guidelines (from 2014) ]]<br />
* [[GSOC2014StudentApplicationTemplate |GSoC Student application template (from 2014)]]<br />
* ''Get in contact with the ns-3 team'': [http://mailman.isi.edu/mailman/listinfo/ns-developers ns-developers mailing list] | ''IRC'' #ns-3 on freenode.net<br />
<br />
== ns-3's GSoC 2015 ==<br />
<br />
This webpage highlights project ideas for ns-3's Google Summer of Code 2015 effort, should ns-3 be selected to participate.<br />
<br />
The ten week coding period for projects runs from 25 May to 21 August, 2015. The full project timeline is here: http://www.google-melange.com/gsoc/events/google/gsoc2015<br />
<br />
=== About the ns-3 project ===<br />
<br />
ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br />
<br />
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.<br />
<br />
Our GSoC organizational admin is [mailto:tomhend@u.washington.edu Tom Henderson] and our backup org admin is [mailto:tpecorella@mac.com Tommaso Pecorella]. The project has participated in past GSoCs during 2008-10 and 2012-14.<br />
<br />
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.<br />
<br />
=== ns-3 and other GSoC mentoring organisations ===<br />
<br />
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.<br />
<br />
=== Students: how to participate ===<br />
<br />
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:<br />
* Read the official [http://en.flossmanuals.net/GSoCStudentGuide/ GSoC student guide].<br />
* Read [[GSOC2014StudentGuide |ns-3's GSoC Student guide]].<br />
* Look through our [[#Project ideas]] below to see if you find a project that interests you.<br />
* Review the [http://www.nsnam.org/ns-3-22/documentation/ns-3 tutorial] thoroughly, if you have not already done so.<br />
* Look through the [[GSOC2014StudentApplicationTemplate |GSoC Student application template]] to start preparing your proposal.<br />
* Next, proceed to get in touch with the developers on the mailing list and refine your proposal.<br />
* In parallel, make sure you prepare a patch as per the [[GSOC2014PatchRequirement | Patch Requirement Guidelines]]. Your application to ns-3 will not be considered if you do not fulfill this requirement.<br />
<br />
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 [http://mailman.isi.edu/mailman/listinfo/ns-developers 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 [http://mailman.isi.edu/mailman/listinfo/ns-developers 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.<br />
<br />
<blockquote><br />
Each project idea within a particular priority has been tagged with the following properties:<br />
* ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br />
* ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br />
* ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful students might apply their experiences coming out of this project.<br />
* ''Difficulty:'' easy, medium or difficult<br />
* ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br />
<br />
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.<br />
</blockquote><br />
<br />
=== Mentors: how to participate ===<br />
<br />
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:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
== Project Ideas ==<br />
<br />
'''Note to students:''' These ideas are not listed in any priority order.<br />
<br />
==== Decouple traffic generators from sockets ====<br />
<br />
Mentors: [mailto:tomh@tomh.org Tom Henderson] [mailto:rivanvx@gmail.com Vedran Miletić]<br />
<br />
* 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.<br />
* ''Required Experience:'' C++, sockets API<br />
* ''Interests:'' <br />
* ''Difficulty:'' easy/medium<br />
* ''Recommended reading:''<br />
** Unix Network Programming (Stevens) or equivalent<br />
** Previous thread on this topic: http://mailman.isi.edu/pipermail/ns-developers/2007-July/003136.html<br />
* ''Bonus points:'' How would you implement backpressure on the traffic generator? See https://www.nsnam.org/bugzilla/show_bug.cgi?id=1006<br />
<br />
==== ARP and NDisc cache visibility ====<br />
<br />
Mentors: [mailto:tomh@tomh.org Tom Henderson] [mailto:rivanvx@gmail.com Vedran Miletić]<br />
<br />
* 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).<br />
* ''Required Experience:'' C++<br />
* ''Interests:'' IPv4 and Ipv6<br />
* ''Difficulty:'' easy/medium<br />
* ''Recommended reading:''<br />
** source code in src/internet, and the bugs mentioned above<br />
<br />
<br />
==== Inter-frequency measurement support for the LTE module ====<br />
<br />
Mentors: [mailto:nbaldo@cttc.es Nicola Baldo] [mailto:mmiozzo@cttc.es Marco Miozzo]<br />
<br />
* 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. <br />
<br />
* ''Required Experience:'' C++, LTE<br />
* ''Interests:'' Mobility Management in LTE<br />
* ''Difficulty:'' hard<br />
* ''Recommended reading:''<br />
** [http://www.nsnam.org/docs/release/3.19/models/html/lte-design.html#ue-rrc-measurements-model documentation of the UE Measurement model in the ns-3 LTE module]<br />
** 3GPP TS 36.331 section 5.5 Measurements<br />
** 3GPP TS 36.133, Section 8.2 UE Measurements Procedures in RRC_CONNECTED State <br />
<br />
<br />
==== GPU acceleration for vector arithmetics in the spectrum module ====<br />
<br />
Mentors: [mailto:nbaldo@cttc.es Nicola Baldo] [mailto:mmiozzo@cttc.es Marco Miozzo]<br />
<br />
* 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). <br />
* ''Required Experience:'' C++<br />
* ''Bonus Experience:'' CUDA, OpenCL...<br />
* ''Interests:'' GPU acceleration<br />
* ''Difficulty:'' hard<br />
* ''Recommended reading:''<br />
** [http://www.nsnam.org/docs/models/html/spectrum.html ns-3 spectrum module documentation]<br />
** http://en.wikipedia.org/wiki/OpenCL<br />
** http://en.wikipedia.org/wiki/CUDA<br />
<br />
<br />
==== Carrier Aggregation support for the LTE module ====<br />
<br />
Mentors: [mailto:mmiozzo@cttc.es Marco Miozzo] [mailto:nbaldo@cttc.es Nicola Baldo]<br />
<br />
* 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.<br />
<br />
* ''Required Experience:'' C++, LTE<br />
* ''Interests:'' LTE-A, HetNet<br />
* ''Difficulty:'' hard<br />
* ''Recommended reading:''<br />
** LTE-A HetNets using Carrier Aggregation, Nomor whitepaper [http://www.nomor.de/uploads/db/a3/dba3e71e617a0ab4b7d3821afd59cc5e/Newsletter_CA_HetNet_2013-06.pdf]<br />
** [http://www.nsnam.org/docs/release/3.19/models/html/lte-design.html]<br />
** 3GPP TS 36.211 <br />
** 3GPP TS 36.213<br />
** 3GPP TS 36.331<br />
<br />
<br />
==== Support of RRC IDLE mode procedures for the LTE module ====<br />
<br />
Mentors: [mailto:nbaldo@cttc.es Nicola Baldo] [mailto:mmiozzo@cttc.es Marco Miozzo] <br />
<br />
* 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.<br />
* ''Required Experience:'' C++, LTE<br />
* ''Interests:'' Mobility Management in LTE systems<br />
* ''Difficulty:'' hard<br />
* ''Recommended reading:''<br />
** 3GPP TS 36.304 [http://www.3gpp.org/DynaReport/36304.htm]<br />
** 3GPP TS 23.401, Section 5.3.3 ("Tracking Area Update Procedures") [http://www.3gpp.org/DynaReport/23401.htm]<br />
** 3GPP TS 36.331<br />
<br />
==== 802.15.4 realistic MAC and Energy Model ====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br />
<br />
'''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.<br />
The goal of the project are:<br />
# Model the 4-state radio model (Sleep, Tx, Rx, Transitioning)<br />
# Develop one 'realistic' MAC model (the choice is left to the student)<br />
# Link the 4-state model with the Energy module.<br />
<br />
* ''Required Experience:'' C++, WSN<br />
* ''Bonus Experience:'' ns-3 Energy model, lr-wpan module<br />
* ''Interests:'' WSN, Battery discharge<br />
* ''Difficulty:'' hard<br />
* ''Recommended reading:''<br />
** [http://www.sics.se/~adam/dunkels07softwarebased.pdf Software-based On-line Energy Estimation for Sensor Nodes] <br />
** [http://cds.unibe.ch/research/pub_files/HBNH11.pdf On the Accuracy of Software-based Energy Estimation Techniques]<br />
** [http://dunkels.com/adam/dunkels11contikimac.pdf The ContikiMAC Radio Duty Cycling Protocol]<br />
<br />
==== 802.15.4 Bootstrap ====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br />
<br />
'''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.<br />
* ''Required Experience:'' C++, WSN<br />
* ''Bonus Experience:'' 802.15.4 standard<br />
* ''Interests:'' WSN<br />
* ''Difficulty:'' medium<br />
* ''Recommended reading:''<br />
** [http://standards.ieee.org/getieee802/download/802.15.4-2011.pdf 802.15.4 Standard]<br />
<br />
<br />
==== 802.15.4 Beacon-enabled mode ====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br />
<br />
'''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. <br />
* ''Required Experience:'' C++, WSN<br />
* ''Bonus Experience:'' 802.15.4 standard<br />
* ''Interests:'' WSN<br />
* ''Difficulty:'' medium/hard<br />
* ''Recommended reading:''<br />
** [http://standards.ieee.org/getieee802/download/802.15.4-2011.pdf 802.15.4 Standard]<br />
<br />
==== Neighbor Discovery Optimization for Low Power and Lossy Networks (6LoWPAN-nd) ====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br />
<br />
'''6LoWPAN-nd implementation and testing:''' [https://datatracker.ietf.org/doc/rfc6775/ 6LoWPAN-nd] is novel protocol from IETF's [http://tools.ietf.org/wg/6lowpan/ 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. <br />
* ''Required Experience:'' C++, IPv6<br />
* ''Bonus Experience:'' WSN networking<br />
* ''Interests:'' WSN, IPv6, node bootstrap, efficient packet compression <br />
* ''Difficulty:'' hard<br />
* ''Recommended reading:''<br />
** [http://tools.ietf.org/html/rfc4919 RFC 4919] IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals<br />
** [https://datatracker.ietf.org/doc/rfc6775/ RFC 6775] Neighbor Discovery Optimization for Low Power and Lossy Networks<br />
<br />
<br />
<br />
[[Category:GSoC]]</div>Nicolabaldohttps://www.nsnam.org/mediawiki/index.php?title=GSOC2015Projects&diff=9306GSOC2015Projects2015-02-12T16:54:22Z<p>Nicolabaldo: /* Project Ideas */</p>
<hr />
<div>{{TOC}}<br />
<br />
'''Note:''' ns-3 is applying but has not yet been selected for GSoC 2015; Google will announce selected organizations on March 2.<br />
<br />
* [http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2015/help_page GSoC Frequently Asked Questions]<br />
* [http://en.flossmanuals.net/gsocmentoring/ GSoC Mentor guide]<br />
* [http://en.flossmanuals.net/GSoCStudentGuide/ GSoC student guide]<br />
* [[GSOC2014StudentGuide |ns-3's GSoC Student guide (from 2014)]]<br />
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br />
* [[GSOCSelectionProcess | GSoC Student Selection Process]]<br />
* [[GSOC2014PatchRequirement | Patch Requirement Guidelines (from 2014) ]]<br />
* [[GSOC2014StudentApplicationTemplate |GSoC Student application template (from 2014)]]<br />
* ''Get in contact with the ns-3 team'': [http://mailman.isi.edu/mailman/listinfo/ns-developers ns-developers mailing list] | ''IRC'' #ns-3 on freenode.net<br />
<br />
= GSoC 2015 Ideas =<br />
<br />
This webpage highlights project ideas for ns-3's Google Summer of Code 2015 effort, should ns-3 be selected to participate.<br />
<br />
The ten week coding period for projects runs from 25 May to 21 August, 2015. The full project timeline is here: http://www.google-melange.com/gsoc/events/google/gsoc2015<br />
<br />
== About the ns-3 project ==<br />
<br />
ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br />
<br />
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.<br />
<br />
Our GSoC organizational admin is [mailto:tomhend@u.washington.edu Tom Henderson] and our backup org admin is [mailto:tpecorella@mac.com Tommaso Pecorella]. The project has participated in past GSoCs during 2008-10 and 2012-14.<br />
<br />
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.<br />
<br />
== ns-3 and other GSoC mentoring organisations ==<br />
<br />
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.<br />
<br />
== Getting started ==<br />
<br />
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:<br />
* Read the official [http://en.flossmanuals.net/GSoCStudentGuide/ GSoC student guide].<br />
* Read [[GSOC2014StudentGuide |ns-3's GSoC Student guide]].<br />
* Look through our ideas list below to see if you find a project that interests you.<br />
* Review the [http://www.nsnam.org/ns-3-22/documentation/ns-3 tutorial] thoroughly, if you have not already done so.<br />
* Look through the [[GSOC2014StudentApplicationTemplate |GSoC Student application template]] to start preparing your proposal.<br />
* Next, proceed to get in touch with the developers on the mailing list and refine your proposal.<br />
* In parallel, make sure you prepare a patch as per the [[GSOC2014PatchRequirement | Patch Requirement Guidelines]]. Your application to ns-3 will not be considered if you do not fulfill this requirement.<br />
<br />
== Project Ideas ==<br />
<br />
The following are a list of project proposals from 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 [http://mailman.isi.edu/mailman/listinfo/ns-developers 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 [http://mailman.isi.edu/mailman/listinfo/ns-developers 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.<br />
<br />
<blockquote><br />
Each project idea within a particular priority has been tagged with the following properties:<br />
* ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br />
* ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br />
* ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful students might apply their experiences coming out of this project.<br />
* ''Difficulty:'' easy, medium or difficult<br />
* ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br />
<br />
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.<br />
</blockquote><br />
<br />
= Guidelines for project ideas =<br />
<br />
For mentors who're adding project ideas to the list below, please ensure that:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
= Project Ideas =<br />
<br />
'''Note to students:''' These ideas are not listed in any priority order.<br />
<br />
=== Decouple traffic generators from sockets ===<br />
<br />
Mentors: [mailto:tomh@tomh.org Tom Henderson] [mailto:rivanvx@gmail.com Vedran Miletić]<br />
<br />
* 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.<br />
* ''Required Experience:'' C++, sockets API<br />
* ''Interests:'' <br />
* ''Difficulty:'' easy/medium<br />
* ''Recommended reading:''<br />
** Unix Network Programming (Stevens) or equivalent<br />
** Previous thread on this topic: http://mailman.isi.edu/pipermail/ns-developers/2007-July/003136.html<br />
* ''Bonus points:'' How would you implement backpressure on the traffic generator? See https://www.nsnam.org/bugzilla/show_bug.cgi?id=1006<br />
<br />
=== ARP and NDisc cache visibility ===<br />
<br />
Mentors: [mailto:tomh@tomh.org Tom Henderson] [mailto:rivanvx@gmail.com Vedran Miletić]<br />
<br />
* 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).<br />
* ''Required Experience:'' C++<br />
* ''Interests:'' IPv4 and Ipv6<br />
* ''Difficulty:'' easy/medium<br />
* ''Recommended reading:''<br />
** source code in src/internet, and the bugs mentioned above<br />
<br />
<br />
=== Inter-frequency measurement support for the LTE module ===<br />
<br />
Mentors: [mailto:nbaldo@cttc.es Nicola Baldo] [mailto:mmiozzo@cttc.es Marco Miozzo]<br />
<br />
* 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. <br />
<br />
* ''Required Experience:'' C++, LTE<br />
* ''Interests:'' Mobility Management in LTE<br />
* ''Difficulty:'' hard<br />
* ''Recommended reading:''<br />
** [http://www.nsnam.org/docs/release/3.19/models/html/lte-design.html#ue-rrc-measurements-model documentation of the UE Measurement model in the ns-3 LTE module]<br />
** 3GPP TS 36.331 section 5.5 Measurements<br />
** 3GPP TS 36.133, Section 8.2 UE Measurements Procedures in RRC_CONNECTED State <br />
<br />
<br />
=== GPU acceleration for vector arithmetics in the spectrum module ===<br />
<br />
Mentors: [mailto:nbaldo@cttc.es Nicola Baldo] [mailto:mmiozzo@cttc.es Marco Miozzo]<br />
<br />
* 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). <br />
* ''Required Experience:'' C++<br />
* ''Bonus Experience:'' CUDA, OpenCL...<br />
* ''Interests:'' GPU acceleration<br />
* ''Difficulty:'' hard<br />
* ''Recommended reading:''<br />
** [http://www.nsnam.org/docs/models/html/spectrum.html ns-3 spectrum module documentation]<br />
** http://en.wikipedia.org/wiki/OpenCL<br />
** http://en.wikipedia.org/wiki/CUDA<br />
<br />
<br />
=== Carrier Aggregation support for the LTE module ===<br />
<br />
Mentors: [mailto:mmiozzo@cttc.es Marco Miozzo] [mailto:nbaldo@cttc.es Nicola Baldo]<br />
<br />
* 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.<br />
<br />
* ''Required Experience:'' C++, LTE<br />
* ''Interests:'' LTE-A, HetNet<br />
* ''Difficulty:'' hard<br />
* ''Recommended reading:''<br />
** LTE-A HetNets using Carrier Aggregation, Nomor whitepaper [http://www.nomor.de/uploads/db/a3/dba3e71e617a0ab4b7d3821afd59cc5e/Newsletter_CA_HetNet_2013-06.pdf]<br />
** [http://www.nsnam.org/docs/release/3.19/models/html/lte-design.html]<br />
** 3GPP TS 36.211 <br />
** 3GPP TS 36.213<br />
** 3GPP TS 36.331<br />
<br />
<br />
=== Support of RRC IDLE mode procedures for the LTE module ===<br />
<br />
Mentors: [mailto:nbaldo@cttc.es Nicola Baldo] [mailto:mmiozzo@cttc.es Marco Miozzo] <br />
<br />
* 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.<br />
* ''Required Experience:'' C++, LTE<br />
* ''Interests:'' Mobility Management in LTE systems<br />
* ''Difficulty:'' hard<br />
* ''Recommended reading:''<br />
** 3GPP TS 36.304 [http://www.3gpp.org/DynaReport/36304.htm]<br />
** 3GPP TS 23.401, Section 5.3.3 ("Tracking Area Update Procedures") [http://www.3gpp.org/DynaReport/23401.htm]<br />
** 3GPP TS 36.331<br />
<br />
<br />
<br />
[[Category:GSoC]]</div>Nicolabaldohttps://www.nsnam.org/mediawiki/index.php?title=GSOC2014Projects&diff=8380GSOC2014Projects2014-02-20T11:58:17Z<p>Nicolabaldo: /* Support of RRC IDLE mode procedures for the LTE module */</p>
<hr />
<div>{{TOC}}<br />
<br />
* [http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2014/help_page GSoC Frequently Asked Questions]<br />
* [http://en.flossmanuals.net/gsocmentoring/ GSoC Mentor guide]<br />
* [http://en.flossmanuals.net/GSoCStudentGuide/ GSoC student guide]<br />
* [[GSOC2014StudentGuide |ns-3's GSoC Student guide]]<br />
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br />
* [[GSOCSelectionProcess | GSoC Student Selection Process]]<br />
* [[GSOC2013PatchRequirement | Patch Requirement Guidelines]]<br />
* [[GSOC2013StudentApplicationTemplate |GSoC Student application template]]<br />
* [[GSOC2013Projects |GSoC 2013 page]] | [[GSOC2013AcceptedProjects | GSoC 2013 Accepted Projects]]<br />
* [[GSOC2012Projects |GSoC 2012 page]] | [[GSOC2012AcceptedProjects |GSoC 2012 Accepted Projects]]<br />
* [[GSOC2011Projects |NSoC 2011 Ideas page]] | [[NSOC2011AcceptedProjects |NSoC 2011 Accepted Projects]]<br />
* [[GSOC2010Projects |GSoC 2010 Ideas page]] | [[GSOC2010AcceptedProjects |GSoC 2010 Accepted Projects]]<br />
* [[GSOC2009Projects |GSoC 2009 Ideas page]] | [[GSOC2009AcceptedProjects |GSoC 2009 Accepted Projects]]<br />
* [[GSOC2010OAReport |GSoC Organization Administrator guide]]<br />
* ''Get in contact with the ns-3 team'': [http://mailman.isi.edu/mailman/listinfo/ns-developers ns-developers mailing list] | ''IRC'' #ns-3 on freenode.net<br />
<br />
= GSoC 2014 Ideas =<br />
<br />
This webpage highlights project ideas for ns-3's Google Summer of Code 2014 effort.<br />
<br />
GSOC 2014 Timeline is:<br />
* February 3 - 20:00 UTC: Mentoring organizations can begin submitting applications to Google.<br />
* February 14 - 20:00 UTC: Mentoring organization application deadline.<br />
* February 24 - 20:00 UTC: List of accepted mentoring organizations published on the Google Summer of Code 2014 site.<br />
* February 24 - March 21: Would-be student participants discuss application ideas with mentoring organizations.<br />
* March 10 - 19:00 UTC: Student application period opens.<br />
* March 21 - 19:00 UTC: Student application deadline.<br />
* April 21 - 19:00 UTC: Student selections announced<br />
* May 19 - Coding begins<br />
* August 18 - Coding ends<br />
Full timeline is here: http://www.google-melange.com/gsoc/events/google/gsoc2014<br />
<br />
While discussions about ideas can be done earlier, please note that ns-3 will not receive an answer to its GSOC application before February 24. <br />
<br />
== About the ns-3 project ==<br />
<br />
ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br />
<br />
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.<br />
<br />
Our GSoC organizational admin is [mailto:tomhend@u.washington.edu Tom Henderson] and our backup org admin is [mailto:tpecorella@mac.com Tommaso Pecorella]. The project has participated in past GSoCs during 2008-10 and 2012-13.<br />
<br />
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.<br />
<br />
== ns-3 and other GSoC mentoring organisations ==<br />
<br />
ns-3 is one of ~175 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.<br />
<br />
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.<br />
<br />
== Getting started ==<br />
<br />
For students interested in applying to ns-3 for GSOC, go through the following list to get started:<br />
* Read the official [http://en.flossmanuals.net/GSoCStudentGuide/ GSoC student guide].<br />
* Read [[GSOC2013StudentGuide |ns-3's GSoC Student guide]].<br />
* Look through our ideas list below to see if you find a project that interests you.<br />
* Review the [http://www.nsnam.org/ns-3-19/documentation/ ns-3 tutorial] thoroughly, if you have not already done so.<br />
* Look through the [[GSOC2013StudentApplicationTemplate |GSoC Student application template]] to start preparing your proposal.<br />
* Next, proceed to get in touch with the developers on the mailing list and refine your proposal.<br />
* In parallel, make sure you prepare a patch as per the [[GSOC2013PatchRequirement | Patch Requirement Guidelines]]. Your application to ns-3 will not be considered if you do not fulfill this requirement.<br />
<br />
== Project Ideas ==<br />
<br />
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 [http://mailman.isi.edu/mailman/listinfo/ns-developers 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 [http://mailman.isi.edu/mailman/listinfo/ns-developers 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.<br />
<br />
<blockquote><br />
Each project idea within a particular priority has been tagged with the following properties:<br />
* ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br />
* ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br />
* ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful students might apply their experiences coming out of this project.<br />
* ''Difficulty:'' easy, medium or difficult<br />
* ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br />
<br />
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.<br />
</blockquote><br />
<br />
= Guidelines for project ideas =<br />
<br />
For mentors who're adding project ideas to the list below, please ensure that:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
= Project Ideas =<br />
<br />
Please see [[GSOC2013Projects | last year's page]] for guidelines on how to create project ideas.<br />
<br />
'''Note to students:''' These ideas are not listed in any priority order, and other project ideas not listed here are also encouraged.<br />
<br />
=== Decouple traffic generators from sockets ===<br />
<br />
Mentors: [mailto:tomh@tomh.org Tom Henderson] [mailto:rivanvx@gmail.com Vedran Miletić]<br />
<br />
* 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.<br />
* ''Required Experience:'' C++, sockets API<br />
* ''Interests:'' <br />
* ''Difficulty:'' easy/medium<br />
* ''Recommended reading:''<br />
** Unix Network Programming (Stevens) or equivalent<br />
<br />
=== ARP and NDisc cache visibility ===<br />
<br />
Mentors: [mailto:tomh@tomh.org Tom Henderson] [mailto:rivanvx@gmail.com Vedran Miletić]<br />
<br />
* 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).<br />
* ''Required Experience:'' C++<br />
* ''Interests:'' IPv4 and Ipv6<br />
* ''Difficulty:'' easy/medium<br />
* ''Recommended reading:''<br />
** source code in src/internet, and the bugs mentioned above<br />
<br />
=== INSTOOLS for ns-3 ===<br />
<br />
Mentors: [mailto:tomh@tomh.org Tom Henderson]<br />
<br />
'''INSTOOLS for ns-3:''' [http://groups.geni.net/geni/wiki/InstrumentationTools 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.<br />
* ''Required Experience:'' Familiarity with Linux networking and with C++ programming. <br />
* ''Bonus Experience:'' Experience with GENI and/or Emulab<br />
* ''Interests:'' Simulator tool development, integration with testbed experiments<br />
* ''Difficulty:'' Medium<br />
* ''Recommended Reading:'' http://groups.geni.net/geni/wiki/InstrumentationTools<br />
<br />
=== bufferbloat-related models ===<br />
<br />
Mentors: [mailto:tomh@tomh.org Tom Henderson]<br />
<br />
'''bufferbloat models:''' [https://www.youtube.com/watch?v=-D-cJNtKwuw Bufferbloat] is an interesting contemporary research topic. <br />
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.<br />
* ''Interests:'' Internet performance, linux kernel networking <br />
* ''Difficulty:'' easy to hard, depending on the depth of the project<br />
* ''Recommended reading:'' <br />
** http://gettys.wordpress.com/category/bufferbloat/<br />
** [http://www.bufferbloat.net/projects/cerowrt CeroWrt]<br />
** [http://www.ietf.org/proceedings/86/slides/slides-86-iccrg-3.pdf ICCRG presentation]<br />
** [http://pollere.net/CoDel.html ns-2 code]<br />
** [https://codereview.appspot.com/6463048/ ns-3 code review]<br />
<br />
=== 802.15.4 realistic MAC and Energy Model ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br />
<br />
'''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.<br />
The goal of the project are:<br />
# Model the 4-state radio model (Sleep, Tx, Rx, Transitioning)<br />
# Develop one 'realistic' MAC model (the choice is left to the student)<br />
# Link the 4-state model with the Energy module.<br />
<br />
* ''Required Experience:'' C++, WSN<br />
* ''Bonus Experience:'' ns-3 Energy model, lr-wpan module<br />
* ''Interests:'' WSN, Battery discharge<br />
* ''Difficulty:'' hard<br />
* ''Recommended reading:''<br />
** [http://www.sics.se/~adam/dunkels07softwarebased.pdf Software-based On-line Energy Estimation for Sensor Nodes] <br />
** [http://cds.unibe.ch/research/pub_files/HBNH11.pdf On the Accuracy of Software-based Energy Estimation Techniques]<br />
** [http://dunkels.com/adam/dunkels11contikimac.pdf The ContikiMAC Radio Duty Cycling Protocol]<br />
<br />
=== 802.15.4 Bootstrap ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br />
<br />
'''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.<br />
* ''Required Experience:'' C++, WSN<br />
* ''Bonus Experience:'' 802.15.4 standard<br />
* ''Interests:'' WSN<br />
* ''Difficulty:'' medium<br />
* ''Recommended reading:''<br />
** [http://standards.ieee.org/getieee802/download/802.15.4-2011.pdf 802.15.4 Standard]<br />
<br />
<br />
=== 802.15.4 Beacon-enabled mode ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br />
<br />
'''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. <br />
* ''Required Experience:'' C++, WSN<br />
* ''Bonus Experience:'' 802.15.4 standard<br />
* ''Interests:'' WSN<br />
* ''Difficulty:'' medium/hard<br />
* ''Recommended reading:''<br />
** [http://standards.ieee.org/getieee802/download/802.15.4-2011.pdf 802.15.4 Standard]<br />
<br />
=== Neighbor Discovery Optimization for Low Power and Lossy Networks (6LoWPAN-nd) ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br />
<br />
'''6LoWPAN-nd implementation and testing:''' [https://datatracker.ietf.org/doc/rfc6775/ 6LoWPAN-nd] is novel protocol from IETF's [http://tools.ietf.org/wg/6lowpan/ 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. <br />
* ''Required Experience:'' C++, IPv6, RPL<br />
* ''Bonus Experience:'' WSN networking<br />
* ''Interests:'' WSN, IPv6, node bootstrap, efficient packet compression <br />
* ''Difficulty:'' hard<br />
* ''Recommended reading:''<br />
** [http://tools.ietf.org/html/rfc4919 RFC 4919] IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals<br />
** [https://datatracker.ietf.org/doc/rfc6775/ RFC 6775] Neighbor Discovery Optimization for Low Power and Lossy Networks<br />
<br />
=== IPv6 stack validation and improvements ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br />
<br />
'''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):<br />
# There is no [http://en.wikipedia.org/wiki/Path_MTU_discovery path MTU discovery] see also [http://tools.ietf.org/html/rfc1981 RFC 1981].<br />
# Flow Monitor module does not work on the IPv6 stack<br />
# FlowLabel header field is not currenly used<br />
# IPSec is not supported<br />
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.<br />
* ''Required Experience:'' C++, TCP/IP networking<br />
* ''Bonus Experience:'' IPv6 protocols<br />
* ''Interests:'' IPv6 internetworking<br />
* ''Difficulty:'' easy / medium, depending on the features implemented<br />
* ''Recommended reading:''<br />
** [http://www.ietf.org/rfc/rfc4294.txt RFC 4294 - IPv6 Node Requirements]<br />
** [http://tools.ietf.org/html/rfc1981 RFC 1981 - Path MTU Discovery for IP version 6]<br />
** ns-3 Flowmon module documentation<br />
** [http://tools.ietf.org/html/rfc6437 RFC 6437 - IPv6 Flow Label Specification]<br />
** [http://tools.ietf.org/html/rfc4302 RFC 4302 - IP Authentication Header]<br />
** [http://tools.ietf.org/html/rfc4303 RFC 4303 - IP Encapsulating Security Payload (ESP)]<br />
<br />
<br />
=== Multicast IPv6 traffic support ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br />
<br />
'''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.<br />
* ''Required Experience:'' C++, IPv6,<br />
* ''Bonus Experience:'' Multicast routing protocols (MLDv2/IGMPv3 and PIM)<br />
* ''Interests:'' routing, multicast<br />
* ''Difficulty:'' medium/hard<br />
* ''Recommended reading:''<br />
** [http://www.h3c.com/portal/Products___Solutions/Products/Switches/H3C_S5500-SI_Series_Switches/White_Paper/200806/688942_57_0.htm Multicast Technology White Paper]<br />
** [http://www.alliedtelesis.co.nz/documentation/at9800/291/pdf/ipv6mu.pdf IPv6 Multicasting]<br />
** All the relevant RFCs (search in [http://www.rfc-editor.org/search/rfc_search.php RFC Editor search engine])<br />
<br />
<br />
=== Licklider Transmission Protocol (LTP) ===<br />
<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella] [mailto:luca.ronga@cnit.it Luca Ronga]<br />
<br />
<br />
'''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.<br />
* ''Required Experience:'' C++<br />
* ''Bonus Experience:'' Satellite and Deep Space networking<br />
* ''Interests:'' Deep Space networking<br />
* ''Difficulty:'' easy / medium<br />
* ''Recommended reading:''<br />
** [http://en.wikipedia.org/wiki/Licklider_Transmission_Protocol Licklider Transmission Protocol]<br />
** [http://tools.ietf.org/html/rfc5325 RFC 5325: Licklider Transmission Protocol—Motivation]<br />
** [http://tools.ietf.org/html/rfc5326 RFC 5326: Licklider Transmission Protocol—Specification]<br />
** [http://public.ccsds.org/sites/cwe/rids/Lists/CCSDS%207341R2/Attachments/734x1r2.pdf Licklider Transmission Protocol (LTP) for CCSDS]<br />
<br />
<br />
=== Inter-frequency measurement support for the LTE module ===<br />
<br />
Mentors: [mailto:nbaldo@cttc.es Nicola Baldo] [mailto:mmiozzo@cttc.es Marco Miozzo]<br />
<br />
* 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. <br />
<br />
* ''Required Experience:'' C++, LTE<br />
* ''Interests:'' Mobility Management in LTE<br />
* ''Difficulty:'' hard<br />
* ''Recommended reading:''<br />
** [http://www.nsnam.org/docs/release/3.19/models/html/lte-design.html#ue-rrc-measurements-model documentation of the UE Measurement model in the ns-3 LTE module]<br />
** 3GPP TS 36.331 section 5.5 Measurements<br />
** 3GPP TS 36.133, Section 8.2 UE Measurements Procedures in RRC_CONNECTED State <br />
<br />
<br />
=== LTE Fractional Frequency Reuse algorithms ===<br />
<br />
Mentors: [mailto:nbaldo@cttc.es Nicola Baldo] [mailto:mmiozzo@cttc.es Marco Miozzo]<br />
<br />
* 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.<br />
* ''Required Experience:'' C++, LTE<br />
* ''Interests:'' Self Organized Networks, HetNets, Inter Cell Interference Coordination<br />
* ''Difficulty:'' hard<br />
* ''Recommended reading:''<br />
** [http://www.nsnam.org/docs/release/3.19/models/html/lte-design.html#mac LTE MAC in ns-3]<br />
** [http://www.nsnam.org/docs/release/3.19/models/html/lte-design.html#x2-c-son-primitives LTE SON primitives in ns-3]<br />
** Thomas Novlan, Jeffrey G. Andrews, Illsoo Sohn, Radha Krishna Ganti, Arunabha Ghosh, "Comparison of Fractional Frequency Reuse Approaches in the OFDMA Cellular Downlink"<br />
** Alexander L. Stolyar, Harish Viswanathan, "Self-organizing Dynamic Fractional Frequency Reuse for Best-Effort Traffic Through Distributed Inter-cell Coordination"<br />
** Heui-Chang Lee, Dong-Chan Oh, and Yong-Hwan Lee, "Mitigation of Inter-Femtocell Interference with Adaptive Fractional Frequency Reuse"<br />
** there are lots of other papers on this topic, please do your own research<br />
<br />
<br />
=== GPU acceleration for vector arithmetics in the spectrum module ===<br />
<br />
Mentors: [mailto:nbaldo@cttc.es Nicola Baldo] [mailto:mmiozzo@cttc.es Marco Miozzo]<br />
<br />
* 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). <br />
* ''Required Experience:'' C++<br />
* ''Bonus Experience:'' CUDA, OpenCL...<br />
* ''Interests:'' GPU acceleration<br />
* ''Difficulty:'' hard<br />
* ''Recommended reading:''<br />
** [http://www.nsnam.org/docs/models/html/spectrum.html ns-3 spectrum module documentation]<br />
** http://en.wikipedia.org/wiki/OpenCL<br />
** http://en.wikipedia.org/wiki/CUDA<br />
<br />
<br />
=== Carrier Aggregation support for the LTE module ===<br />
<br />
Mentors: [mailto:mmiozzo@cttc.es Marco Miozzo] [mailto:nbaldo@cttc.es Nicola Baldo]<br />
<br />
* 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.<br />
<br />
* ''Required Experience:'' C++, LTE<br />
* ''Interests:'' LTE-A, HetNet<br />
* ''Difficulty:'' hard<br />
* ''Recommended reading:''<br />
** LTE-A HetNets using Carrier Aggregation, Nomor whitepaper [http://www.nomor.de/uploads/db/a3/dba3e71e617a0ab4b7d3821afd59cc5e/Newsletter_CA_HetNet_2013-06.pdf]<br />
** [http://www.nsnam.org/docs/release/3.19/models/html/lte-design.html]<br />
** 3GPP TS 36.211 <br />
** 3GPP TS 36.213<br />
** 3GPP TS 36.331<br />
<br />
<br />
=== Support of RRC IDLE mode procedures for the LTE module ===<br />
<br />
Mentors: [mailto:nbaldo@cttc.es Nicola Baldo] [mailto:mmiozzo@cttc.es Marco Miozzo] <br />
<br />
* 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.<br />
* ''Required Experience:'' C++, LTE<br />
* ''Interests:'' Mobility Management in LTE systems<br />
* ''Difficulty:'' hard<br />
* ''Recommended reading:''<br />
** 3GPP TS 36.304 [http://www.3gpp.org/DynaReport/36304.htm]<br />
** 3GPP TS 23.401, Section 5.3.3 ("Tracking Area Update Procedures") [http://www.3gpp.org/DynaReport/23401.htm]<br />
** 3GPP TS 36.331<br />
<br />
[[Category:GSoC]]</div>Nicolabaldohttps://www.nsnam.org/mediawiki/index.php?title=GSOC2014Projects&diff=8379GSOC2014Projects2014-02-20T11:56:42Z<p>Nicolabaldo: /* Project Ideas */</p>
<hr />
<div>{{TOC}}<br />
<br />
* [http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2014/help_page GSoC Frequently Asked Questions]<br />
* [http://en.flossmanuals.net/gsocmentoring/ GSoC Mentor guide]<br />
* [http://en.flossmanuals.net/GSoCStudentGuide/ GSoC student guide]<br />
* [[GSOC2014StudentGuide |ns-3's GSoC Student guide]]<br />
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br />
* [[GSOCSelectionProcess | GSoC Student Selection Process]]<br />
* [[GSOC2013PatchRequirement | Patch Requirement Guidelines]]<br />
* [[GSOC2013StudentApplicationTemplate |GSoC Student application template]]<br />
* [[GSOC2013Projects |GSoC 2013 page]] | [[GSOC2013AcceptedProjects | GSoC 2013 Accepted Projects]]<br />
* [[GSOC2012Projects |GSoC 2012 page]] | [[GSOC2012AcceptedProjects |GSoC 2012 Accepted Projects]]<br />
* [[GSOC2011Projects |NSoC 2011 Ideas page]] | [[NSOC2011AcceptedProjects |NSoC 2011 Accepted Projects]]<br />
* [[GSOC2010Projects |GSoC 2010 Ideas page]] | [[GSOC2010AcceptedProjects |GSoC 2010 Accepted Projects]]<br />
* [[GSOC2009Projects |GSoC 2009 Ideas page]] | [[GSOC2009AcceptedProjects |GSoC 2009 Accepted Projects]]<br />
* [[GSOC2010OAReport |GSoC Organization Administrator guide]]<br />
* ''Get in contact with the ns-3 team'': [http://mailman.isi.edu/mailman/listinfo/ns-developers ns-developers mailing list] | ''IRC'' #ns-3 on freenode.net<br />
<br />
= GSoC 2014 Ideas =<br />
<br />
This webpage highlights project ideas for ns-3's Google Summer of Code 2014 effort.<br />
<br />
GSOC 2014 Timeline is:<br />
* February 3 - 20:00 UTC: Mentoring organizations can begin submitting applications to Google.<br />
* February 14 - 20:00 UTC: Mentoring organization application deadline.<br />
* February 24 - 20:00 UTC: List of accepted mentoring organizations published on the Google Summer of Code 2014 site.<br />
* February 24 - March 21: Would-be student participants discuss application ideas with mentoring organizations.<br />
* March 10 - 19:00 UTC: Student application period opens.<br />
* March 21 - 19:00 UTC: Student application deadline.<br />
* April 21 - 19:00 UTC: Student selections announced<br />
* May 19 - Coding begins<br />
* August 18 - Coding ends<br />
Full timeline is here: http://www.google-melange.com/gsoc/events/google/gsoc2014<br />
<br />
While discussions about ideas can be done earlier, please note that ns-3 will not receive an answer to its GSOC application before February 24. <br />
<br />
== About the ns-3 project ==<br />
<br />
ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br />
<br />
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.<br />
<br />
Our GSoC organizational admin is [mailto:tomhend@u.washington.edu Tom Henderson] and our backup org admin is [mailto:tpecorella@mac.com Tommaso Pecorella]. The project has participated in past GSoCs during 2008-10 and 2012-13.<br />
<br />
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.<br />
<br />
== ns-3 and other GSoC mentoring organisations ==<br />
<br />
ns-3 is one of ~175 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.<br />
<br />
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.<br />
<br />
== Getting started ==<br />
<br />
For students interested in applying to ns-3 for GSOC, go through the following list to get started:<br />
* Read the official [http://en.flossmanuals.net/GSoCStudentGuide/ GSoC student guide].<br />
* Read [[GSOC2013StudentGuide |ns-3's GSoC Student guide]].<br />
* Look through our ideas list below to see if you find a project that interests you.<br />
* Review the [http://www.nsnam.org/ns-3-19/documentation/ ns-3 tutorial] thoroughly, if you have not already done so.<br />
* Look through the [[GSOC2013StudentApplicationTemplate |GSoC Student application template]] to start preparing your proposal.<br />
* Next, proceed to get in touch with the developers on the mailing list and refine your proposal.<br />
* In parallel, make sure you prepare a patch as per the [[GSOC2013PatchRequirement | Patch Requirement Guidelines]]. Your application to ns-3 will not be considered if you do not fulfill this requirement.<br />
<br />
== Project Ideas ==<br />
<br />
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 [http://mailman.isi.edu/mailman/listinfo/ns-developers 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 [http://mailman.isi.edu/mailman/listinfo/ns-developers 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.<br />
<br />
<blockquote><br />
Each project idea within a particular priority has been tagged with the following properties:<br />
* ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br />
* ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br />
* ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful students might apply their experiences coming out of this project.<br />
* ''Difficulty:'' easy, medium or difficult<br />
* ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br />
<br />
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.<br />
</blockquote><br />
<br />
= Guidelines for project ideas =<br />
<br />
For mentors who're adding project ideas to the list below, please ensure that:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
= Project Ideas =<br />
<br />
Please see [[GSOC2013Projects | last year's page]] for guidelines on how to create project ideas.<br />
<br />
'''Note to students:''' These ideas are not listed in any priority order, and other project ideas not listed here are also encouraged.<br />
<br />
=== Decouple traffic generators from sockets ===<br />
<br />
Mentors: [mailto:tomh@tomh.org Tom Henderson] [mailto:rivanvx@gmail.com Vedran Miletić]<br />
<br />
* 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.<br />
* ''Required Experience:'' C++, sockets API<br />
* ''Interests:'' <br />
* ''Difficulty:'' easy/medium<br />
* ''Recommended reading:''<br />
** Unix Network Programming (Stevens) or equivalent<br />
<br />
=== ARP and NDisc cache visibility ===<br />
<br />
Mentors: [mailto:tomh@tomh.org Tom Henderson] [mailto:rivanvx@gmail.com Vedran Miletić]<br />
<br />
* 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).<br />
* ''Required Experience:'' C++<br />
* ''Interests:'' IPv4 and Ipv6<br />
* ''Difficulty:'' easy/medium<br />
* ''Recommended reading:''<br />
** source code in src/internet, and the bugs mentioned above<br />
<br />
=== INSTOOLS for ns-3 ===<br />
<br />
Mentors: [mailto:tomh@tomh.org Tom Henderson]<br />
<br />
'''INSTOOLS for ns-3:''' [http://groups.geni.net/geni/wiki/InstrumentationTools 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.<br />
* ''Required Experience:'' Familiarity with Linux networking and with C++ programming. <br />
* ''Bonus Experience:'' Experience with GENI and/or Emulab<br />
* ''Interests:'' Simulator tool development, integration with testbed experiments<br />
* ''Difficulty:'' Medium<br />
* ''Recommended Reading:'' http://groups.geni.net/geni/wiki/InstrumentationTools<br />
<br />
=== bufferbloat-related models ===<br />
<br />
Mentors: [mailto:tomh@tomh.org Tom Henderson]<br />
<br />
'''bufferbloat models:''' [https://www.youtube.com/watch?v=-D-cJNtKwuw Bufferbloat] is an interesting contemporary research topic. <br />
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.<br />
* ''Interests:'' Internet performance, linux kernel networking <br />
* ''Difficulty:'' easy to hard, depending on the depth of the project<br />
* ''Recommended reading:'' <br />
** http://gettys.wordpress.com/category/bufferbloat/<br />
** [http://www.bufferbloat.net/projects/cerowrt CeroWrt]<br />
** [http://www.ietf.org/proceedings/86/slides/slides-86-iccrg-3.pdf ICCRG presentation]<br />
** [http://pollere.net/CoDel.html ns-2 code]<br />
** [https://codereview.appspot.com/6463048/ ns-3 code review]<br />
<br />
=== 802.15.4 realistic MAC and Energy Model ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br />
<br />
'''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.<br />
The goal of the project are:<br />
# Model the 4-state radio model (Sleep, Tx, Rx, Transitioning)<br />
# Develop one 'realistic' MAC model (the choice is left to the student)<br />
# Link the 4-state model with the Energy module.<br />
<br />
* ''Required Experience:'' C++, WSN<br />
* ''Bonus Experience:'' ns-3 Energy model, lr-wpan module<br />
* ''Interests:'' WSN, Battery discharge<br />
* ''Difficulty:'' hard<br />
* ''Recommended reading:''<br />
** [http://www.sics.se/~adam/dunkels07softwarebased.pdf Software-based On-line Energy Estimation for Sensor Nodes] <br />
** [http://cds.unibe.ch/research/pub_files/HBNH11.pdf On the Accuracy of Software-based Energy Estimation Techniques]<br />
** [http://dunkels.com/adam/dunkels11contikimac.pdf The ContikiMAC Radio Duty Cycling Protocol]<br />
<br />
=== 802.15.4 Bootstrap ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br />
<br />
'''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.<br />
* ''Required Experience:'' C++, WSN<br />
* ''Bonus Experience:'' 802.15.4 standard<br />
* ''Interests:'' WSN<br />
* ''Difficulty:'' medium<br />
* ''Recommended reading:''<br />
** [http://standards.ieee.org/getieee802/download/802.15.4-2011.pdf 802.15.4 Standard]<br />
<br />
<br />
=== 802.15.4 Beacon-enabled mode ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br />
<br />
'''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. <br />
* ''Required Experience:'' C++, WSN<br />
* ''Bonus Experience:'' 802.15.4 standard<br />
* ''Interests:'' WSN<br />
* ''Difficulty:'' medium/hard<br />
* ''Recommended reading:''<br />
** [http://standards.ieee.org/getieee802/download/802.15.4-2011.pdf 802.15.4 Standard]<br />
<br />
=== Neighbor Discovery Optimization for Low Power and Lossy Networks (6LoWPAN-nd) ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br />
<br />
'''6LoWPAN-nd implementation and testing:''' [https://datatracker.ietf.org/doc/rfc6775/ 6LoWPAN-nd] is novel protocol from IETF's [http://tools.ietf.org/wg/6lowpan/ 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. <br />
* ''Required Experience:'' C++, IPv6, RPL<br />
* ''Bonus Experience:'' WSN networking<br />
* ''Interests:'' WSN, IPv6, node bootstrap, efficient packet compression <br />
* ''Difficulty:'' hard<br />
* ''Recommended reading:''<br />
** [http://tools.ietf.org/html/rfc4919 RFC 4919] IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals<br />
** [https://datatracker.ietf.org/doc/rfc6775/ RFC 6775] Neighbor Discovery Optimization for Low Power and Lossy Networks<br />
<br />
=== IPv6 stack validation and improvements ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br />
<br />
'''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):<br />
# There is no [http://en.wikipedia.org/wiki/Path_MTU_discovery path MTU discovery] see also [http://tools.ietf.org/html/rfc1981 RFC 1981].<br />
# Flow Monitor module does not work on the IPv6 stack<br />
# FlowLabel header field is not currenly used<br />
# IPSec is not supported<br />
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.<br />
* ''Required Experience:'' C++, TCP/IP networking<br />
* ''Bonus Experience:'' IPv6 protocols<br />
* ''Interests:'' IPv6 internetworking<br />
* ''Difficulty:'' easy / medium, depending on the features implemented<br />
* ''Recommended reading:''<br />
** [http://www.ietf.org/rfc/rfc4294.txt RFC 4294 - IPv6 Node Requirements]<br />
** [http://tools.ietf.org/html/rfc1981 RFC 1981 - Path MTU Discovery for IP version 6]<br />
** ns-3 Flowmon module documentation<br />
** [http://tools.ietf.org/html/rfc6437 RFC 6437 - IPv6 Flow Label Specification]<br />
** [http://tools.ietf.org/html/rfc4302 RFC 4302 - IP Authentication Header]<br />
** [http://tools.ietf.org/html/rfc4303 RFC 4303 - IP Encapsulating Security Payload (ESP)]<br />
<br />
<br />
=== Multicast IPv6 traffic support ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br />
<br />
'''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.<br />
* ''Required Experience:'' C++, IPv6,<br />
* ''Bonus Experience:'' Multicast routing protocols (MLDv2/IGMPv3 and PIM)<br />
* ''Interests:'' routing, multicast<br />
* ''Difficulty:'' medium/hard<br />
* ''Recommended reading:''<br />
** [http://www.h3c.com/portal/Products___Solutions/Products/Switches/H3C_S5500-SI_Series_Switches/White_Paper/200806/688942_57_0.htm Multicast Technology White Paper]<br />
** [http://www.alliedtelesis.co.nz/documentation/at9800/291/pdf/ipv6mu.pdf IPv6 Multicasting]<br />
** All the relevant RFCs (search in [http://www.rfc-editor.org/search/rfc_search.php RFC Editor search engine])<br />
<br />
<br />
=== Licklider Transmission Protocol (LTP) ===<br />
<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella] [mailto:luca.ronga@cnit.it Luca Ronga]<br />
<br />
<br />
'''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.<br />
* ''Required Experience:'' C++<br />
* ''Bonus Experience:'' Satellite and Deep Space networking<br />
* ''Interests:'' Deep Space networking<br />
* ''Difficulty:'' easy / medium<br />
* ''Recommended reading:''<br />
** [http://en.wikipedia.org/wiki/Licklider_Transmission_Protocol Licklider Transmission Protocol]<br />
** [http://tools.ietf.org/html/rfc5325 RFC 5325: Licklider Transmission Protocol—Motivation]<br />
** [http://tools.ietf.org/html/rfc5326 RFC 5326: Licklider Transmission Protocol—Specification]<br />
** [http://public.ccsds.org/sites/cwe/rids/Lists/CCSDS%207341R2/Attachments/734x1r2.pdf Licklider Transmission Protocol (LTP) for CCSDS]<br />
<br />
<br />
=== Inter-frequency measurement support for the LTE module ===<br />
<br />
Mentors: [mailto:nbaldo@cttc.es Nicola Baldo] [mailto:mmiozzo@cttc.es Marco Miozzo]<br />
<br />
* 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. <br />
<br />
* ''Required Experience:'' C++, LTE<br />
* ''Interests:'' Mobility Management in LTE<br />
* ''Difficulty:'' hard<br />
* ''Recommended reading:''<br />
** [http://www.nsnam.org/docs/release/3.19/models/html/lte-design.html#ue-rrc-measurements-model documentation of the UE Measurement model in the ns-3 LTE module]<br />
** 3GPP TS 36.331 section 5.5 Measurements<br />
** 3GPP TS 36.133, Section 8.2 UE Measurements Procedures in RRC_CONNECTED State <br />
<br />
<br />
=== LTE Fractional Frequency Reuse algorithms ===<br />
<br />
Mentors: [mailto:nbaldo@cttc.es Nicola Baldo] [mailto:mmiozzo@cttc.es Marco Miozzo]<br />
<br />
* 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.<br />
* ''Required Experience:'' C++, LTE<br />
* ''Interests:'' Self Organized Networks, HetNets, Inter Cell Interference Coordination<br />
* ''Difficulty:'' hard<br />
* ''Recommended reading:''<br />
** [http://www.nsnam.org/docs/release/3.19/models/html/lte-design.html#mac LTE MAC in ns-3]<br />
** [http://www.nsnam.org/docs/release/3.19/models/html/lte-design.html#x2-c-son-primitives LTE SON primitives in ns-3]<br />
** Thomas Novlan, Jeffrey G. Andrews, Illsoo Sohn, Radha Krishna Ganti, Arunabha Ghosh, "Comparison of Fractional Frequency Reuse Approaches in the OFDMA Cellular Downlink"<br />
** Alexander L. Stolyar, Harish Viswanathan, "Self-organizing Dynamic Fractional Frequency Reuse for Best-Effort Traffic Through Distributed Inter-cell Coordination"<br />
** Heui-Chang Lee, Dong-Chan Oh, and Yong-Hwan Lee, "Mitigation of Inter-Femtocell Interference with Adaptive Fractional Frequency Reuse"<br />
** there are lots of other papers on this topic, please do your own research<br />
<br />
<br />
=== GPU acceleration for vector arithmetics in the spectrum module ===<br />
<br />
Mentors: [mailto:nbaldo@cttc.es Nicola Baldo] [mailto:mmiozzo@cttc.es Marco Miozzo]<br />
<br />
* 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). <br />
* ''Required Experience:'' C++<br />
* ''Bonus Experience:'' CUDA, OpenCL...<br />
* ''Interests:'' GPU acceleration<br />
* ''Difficulty:'' hard<br />
* ''Recommended reading:''<br />
** [http://www.nsnam.org/docs/models/html/spectrum.html ns-3 spectrum module documentation]<br />
** http://en.wikipedia.org/wiki/OpenCL<br />
** http://en.wikipedia.org/wiki/CUDA<br />
<br />
<br />
=== Carrier Aggregation support for the LTE module ===<br />
<br />
Mentors: [mailto:mmiozzo@cttc.es Marco Miozzo] [mailto:nbaldo@cttc.es Nicola Baldo]<br />
<br />
* 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.<br />
<br />
* ''Required Experience:'' C++, LTE<br />
* ''Interests:'' LTE-A, HetNet<br />
* ''Difficulty:'' hard<br />
* ''Recommended reading:''<br />
** LTE-A HetNets using Carrier Aggregation, Nomor whitepaper [http://www.nomor.de/uploads/db/a3/dba3e71e617a0ab4b7d3821afd59cc5e/Newsletter_CA_HetNet_2013-06.pdf]<br />
** [http://www.nsnam.org/docs/release/3.19/models/html/lte-design.html]<br />
** 3GPP TS 36.211 <br />
** 3GPP TS 36.213<br />
** 3GPP TS 36.331<br />
<br />
<br />
=== Support of RRC IDLE mode procedures for the LTE module ===<br />
<br />
Mentors: [mailto:nbaldo@cttc.es Nicola Baldo] [mailto:mmiozzo@cttc.es Marco Miozzo] <br />
<br />
* 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 procedure (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.<br />
* ''Required Experience:'' C++, LTE<br />
* ''Interests:'' Mobility Management in LTE systems<br />
* ''Difficulty:'' hard<br />
* ''Recommended reading:''<br />
** 3GPP TS 36.304 [http://www.3gpp.org/DynaReport/36304.htm]<br />
** 3GPP TS 23.401, Section 5.3.3 ("Tracking Area Update Procedures") [http://www.3gpp.org/DynaReport/23401.htm]<br />
** 3GPP TS 36.331<br />
<br />
[[Category:GSoC]]</div>Nicolabaldohttps://www.nsnam.org/mediawiki/index.php?title=GSOC2014Projects&diff=8360GSOC2014Projects2014-02-14T15:51:16Z<p>Nicolabaldo: /* LTE Fractional Frequency Reuse algorithms */</p>
<hr />
<div>{{TOC}}<br />
<br />
* [http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2014/help_page GSoC Frequently Asked Questions]<br />
* [http://en.flossmanuals.net/gsocmentoring/ GSoC Mentor guide]<br />
* [http://en.flossmanuals.net/GSoCStudentGuide/ GSoC student guide]<br />
* [[GSOC2013StudentGuide |ns-3's GSoC Student guide]]<br />
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br />
* [[GSOCSelectionProcess | GSoC Student Selection Process]]<br />
* [[GSOC2013PatchRequirement | Patch Requirement Guidelines]]<br />
* [[GSOC2013StudentApplicationTemplate |GSoC Student application template]]<br />
* [[GSOC2013AcceptedProjects | GSoC 2013 Accepted Projects]]<br />
* [[GSOC2012Projects |GSoC 2012 page]] | [[GSOC2012AcceptedProjects |GSoC 2012 Accepted Projects]]<br />
* [[GSOC2011Projects |NSoC 2011 Ideas page]] | [[NSOC2011AcceptedProjects |NSoC 2011 Accepted Projects]]<br />
* [[GSOC2010Projects |GSoC 2010 Ideas page]] | [[GSOC2010AcceptedProjects |GSoC 2010 Accepted Projects]]<br />
* [[GSOC2009Projects |GSoC 2009 Ideas page]] | [[GSOC2009AcceptedProjects |GSoC 2009 Accepted Projects]]<br />
* [[GSOC2010OAReport |GSoC Organization Administrator guide]]<br />
* ''Get in contact with the ns-3 team'': [http://mailman.isi.edu/mailman/listinfo/ns-developers ns-developers mailing list] | ''IRC'' #ns-3 on freenode.net<br />
<br />
= GSoC 2014 Ideas =<br />
<br />
This webpage highlights project ideas for ns-3's Google Summer of Code 2014 effort.<br />
<br />
GSOC 2014 Timeline is:<br />
* February 3 - 20:00 UTC: Mentoring organizations can begin submitting applications to Google.<br />
* February 14 - 20:00 UTC: Mentoring organization application deadline.<br />
* February 24 - 20:00 UTC: List of accepted mentoring organizations published on the Google Summer of Code 2014 site.<br />
* February 24 - March 21: Would-be student participants discuss application ideas with mentoring organizations.<br />
* March 10 - 19:00 UTC: Student application period opens.<br />
* March 21 - 19:00 UTC: Student application deadline.<br />
* April 21 - 19:00 UTC: Student selections announced<br />
* May 19 - Coding begins<br />
* August 18 - Coding ends<br />
Full timeline is here: http://www.google-melange.com/gsoc/events/google/gsoc2014<br />
<br />
While discussions about ideas can be done earlier, please note that ns-3 will not receive an answer to its GSOC application before February 24. <br />
<br />
== About the ns-3 project ==<br />
<br />
ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br />
<br />
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.<br />
<br />
Our GSoC organizational admin is TBD and our backup org admin is [mailto:tomhend@u.washington.edu Tom Henderson]. The project has participated in past GSoCs during 2008-10 and 2012-13.<br />
<br />
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.<br />
<br />
== ns-3 and other GSoC mentoring organisations ==<br />
<br />
ns-3 is one of ~175 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.<br />
<br />
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.<br />
<br />
== Getting started ==<br />
<br />
For students interested in applying to ns-3 for GSOC, go through the following list to get started:<br />
* Read the official [http://en.flossmanuals.net/GSoCStudentGuide/ GSoC student guide].<br />
* Read [[GSOC2013StudentGuide |ns-3's GSoC Student guide]].<br />
* Look through our ideas list below to see if you find a project that interests you.<br />
* Review the [http://www.nsnam.org/ns-3-19/documentation/ ns-3 tutorial] thoroughly, if you have not already done so.<br />
* Look through the [[GSOC2013StudentApplicationTemplate |GSoC Student application template]] to start preparing your proposal.<br />
* Next, proceed to get in touch with the developers on the mailing list and refine your proposal.<br />
* In parallel, make sure you prepare a patch as per the [[GSOC2013PatchRequirement | Patch Requirement Guidelines]]. Your application to ns-3 will not be considered if you do not fulfill this requirement.<br />
<br />
== Project Ideas ==<br />
<br />
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 [http://mailman.isi.edu/mailman/listinfo/ns-developers 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 [http://mailman.isi.edu/mailman/listinfo/ns-developers 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.<br />
<br />
<blockquote><br />
Each project idea within a particular priority has been tagged with the following properties:<br />
* ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br />
* ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br />
* ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful students might apply their experiences coming out of this project.<br />
* ''Difficulty:'' easy, medium or difficult<br />
* ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br />
<br />
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.<br />
</blockquote><br />
<br />
= Guidelines for project ideas =<br />
<br />
For mentors who're adding project ideas to the list below, please ensure that:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
= Project Ideas =<br />
<br />
Please see [[GSOC2013StudentGuide | last year's page]] for guidelines on how to create project ideas.<br />
<br />
'''Note to students:''' These ideas are not listed in any priority order, and other project ideas not listed here are also encouraged.<br />
<br />
=== Decouple traffic generators from sockets ===<br />
<br />
Mentors: [mailto:tomh@tomh.org Tom Henderson] [mailto:rivanvx@gmail.com Vedran Miletić]<br />
<br />
* 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.<br />
* ''Required Experience:'' C++, sockets API<br />
* ''Interests:'' <br />
* ''Difficulty:'' easy/medium<br />
* ''Recommended reading:''<br />
** Unix Network Programming (Stevens) or equivalent<br />
<br />
=== ARP and NDisc cache visibility ===<br />
<br />
Mentors: [mailto:tomh@tomh.org Tom Henderson] [mailto:rivanvx@gmail.com Vedran Miletić]<br />
<br />
* 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).<br />
* ''Required Experience:'' C++<br />
* ''Interests:'' IPv4 and Ipv6<br />
* ''Difficulty:'' easy/medium<br />
* ''Recommended reading:''<br />
** source code in src/internet, and the bugs mentioned above<br />
<br />
=== INSTOOLS for ns-3 ===<br />
<br />
Mentors: [mailto:tomh@tomh.org Tom Henderson]<br />
<br />
'''INSTOOLS for ns-3:''' [http://groups.geni.net/geni/wiki/InstrumentationTools 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.<br />
* ''Required Experience:'' Familiarity with Linux networking and with C++ programming. <br />
* ''Bonus Experience:'' Experience with GENI and/or Emulab<br />
* ''Interests:'' Simulator tool development, integration with testbed experiments<br />
* ''Difficulty:'' Medium<br />
* ''Recommended Reading:'' http://groups.geni.net/geni/wiki/InstrumentationTools<br />
<br />
=== bufferbloat-related models ===<br />
<br />
Mentors: [mailto:tomh@tomh.org Tom Henderson]<br />
<br />
'''bufferbloat models:''' [https://www.youtube.com/watch?v=-D-cJNtKwuw Bufferbloat] is an interesting contemporary research topic. <br />
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.<br />
* ''Interests:'' Internet performance, linux kernel networking <br />
* ''Difficulty:'' easy to hard, depending on the depth of the project<br />
* ''Recommended reading:'' <br />
** http://gettys.wordpress.com/category/bufferbloat/<br />
** [http://www.bufferbloat.net/projects/cerowrt CeroWrt]<br />
** [http://www.ietf.org/proceedings/86/slides/slides-86-iccrg-3.pdf ICCRG presentation]<br />
** [http://pollere.net/CoDel.html ns-2 code]<br />
** [https://codereview.appspot.com/6463048/ ns-3 code review]<br />
<br />
=== 802.15.4 realistic MAC and Energy Model ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br />
<br />
'''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.<br />
The goal of the project are:<br />
# Model the 4-state radio model (Sleep, Tx, Rx, Transitioning)<br />
# Develop one 'realistic' MAC model (the choice is left to the student)<br />
# Link the 4-state model with the Energy module.<br />
<br />
* ''Required Experience:'' C++, WSN<br />
* ''Bonus Experience:'' ns-3 Energy model, lr-wpan module<br />
* ''Interests:'' WSN, Battery discharge<br />
* ''Difficulty:'' hard<br />
* ''Recommended reading:''<br />
** [http://www.sics.se/~adam/dunkels07softwarebased.pdf Software-based On-line Energy Estimation for Sensor Nodes] <br />
** [http://cds.unibe.ch/research/pub_files/HBNH11.pdf On the Accuracy of Software-based Energy Estimation Techniques]<br />
** [http://dunkels.com/adam/dunkels11contikimac.pdf The ContikiMAC Radio Duty Cycling Protocol]<br />
<br />
=== 802.15.4 Bootstrap ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br />
<br />
'''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.<br />
* ''Required Experience:'' C++, WSN<br />
* ''Bonus Experience:'' 802.15.4 standard<br />
* ''Interests:'' WSN<br />
* ''Difficulty:'' medium<br />
* ''Recommended reading:''<br />
** [http://standards.ieee.org/getieee802/download/802.15.4-2011.pdf 802.15.4 Standard]<br />
<br />
<br />
=== 802.15.4 Beacon-enabled mode ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br />
<br />
'''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. <br />
* ''Required Experience:'' C++, WSN<br />
* ''Bonus Experience:'' 802.15.4 standard<br />
* ''Interests:'' WSN<br />
* ''Difficulty:'' medium/hard<br />
* ''Recommended reading:''<br />
** [http://standards.ieee.org/getieee802/download/802.15.4-2011.pdf 802.15.4 Standard]<br />
<br />
=== Neighbor Discovery Optimization for Low Power and Lossy Networks (6LoWPAN-nd) ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br />
<br />
'''6LoWPAN-nd implementation and testing:''' [https://datatracker.ietf.org/doc/rfc6775/ 6LoWPAN-nd] is novel protocol from IETF's [http://tools.ietf.org/wg/6lowpan/ 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. <br />
* ''Required Experience:'' C++, IPv6, RPL<br />
* ''Bonus Experience:'' WSN networking<br />
* ''Interests:'' WSN, IPv6, node bootstrap, efficient packet compression <br />
* ''Difficulty:'' hard<br />
* ''Recommended reading:''<br />
** [http://tools.ietf.org/html/rfc4919 RFC 4919] IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals<br />
** [https://datatracker.ietf.org/doc/rfc6775/ RFC 6775] Neighbor Discovery Optimization for Low Power and Lossy Networks<br />
<br />
=== IPv6 stack validation and improvements ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br />
<br />
'''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):<br />
# There is no [http://en.wikipedia.org/wiki/Path_MTU_discovery path MTU discovery] see also [http://tools.ietf.org/html/rfc1981 RFC 1981].<br />
# Flow Monitor module does not work on the IPv6 stack<br />
# FlowLabel header field is not currenly used<br />
# IPSec is not supported<br />
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.<br />
* ''Required Experience:'' C++, TCP/IP networking<br />
* ''Bonus Experience:'' IPv6 protocols<br />
* ''Interests:'' IPv6 internetworking<br />
* ''Difficulty:'' easy / medium, depending on the features implemented<br />
* ''Recommended reading:''<br />
** [http://www.ietf.org/rfc/rfc4294.txt RFC 4294 - IPv6 Node Requirements]<br />
** [http://tools.ietf.org/html/rfc1981 RFC 1981 - Path MTU Discovery for IP version 6]<br />
** ns-3 Flowmon module documentation<br />
** [http://tools.ietf.org/html/rfc6437 RFC 6437 - IPv6 Flow Label Specification]<br />
** [http://tools.ietf.org/html/rfc4302 RFC 4302 - IP Authentication Header]<br />
** [http://tools.ietf.org/html/rfc4303 RFC 4303 - IP Encapsulating Security Payload (ESP)]<br />
<br />
<br />
=== Multicast IPv6 traffic support ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br />
<br />
'''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.<br />
* ''Required Experience:'' C++, IPv6,<br />
* ''Bonus Experience:'' Multicast routing protocols (MLDv2/IGMPv3 and PIM)<br />
* ''Interests:'' routing, multicast<br />
* ''Difficulty:'' medium/hard<br />
* ''Recommended reading:''<br />
** [http://www.h3c.com/portal/Products___Solutions/Products/Switches/H3C_S5500-SI_Series_Switches/White_Paper/200806/688942_57_0.htm Multicast Technology White Paper]<br />
** [http://www.alliedtelesis.co.nz/documentation/at9800/291/pdf/ipv6mu.pdf IPv6 Multicasting]<br />
** All the relevant RFCs (search in [http://www.rfc-editor.org/search/rfc_search.php RFC Editor search engine])<br />
<br />
<br />
=== Licklider Transmission Protocol (LTP) ===<br />
<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella] [mailto:luca.ronga@cnit.it Luca Ronga]<br />
<br />
<br />
'''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.<br />
* ''Required Experience:'' C++<br />
* ''Bonus Experience:'' Satellite and Deep Space networking<br />
* ''Interests:'' Deep Space networking<br />
* ''Difficulty:'' easy / medium<br />
* ''Recommended reading:''<br />
** [http://en.wikipedia.org/wiki/Licklider_Transmission_Protocol Licklider Transmission Protocol]<br />
** [http://tools.ietf.org/html/rfc5325 RFC 5325: Licklider Transmission Protocol—Motivation]<br />
** [http://tools.ietf.org/html/rfc5326 RFC 5326: Licklider Transmission Protocol—Specification]<br />
** [http://public.ccsds.org/sites/cwe/rids/Lists/CCSDS%207341R2/Attachments/734x1r2.pdf Licklider Transmission Protocol (LTP) for CCSDS]<br />
<br />
<br />
<br />
<br />
<br />
=== Inter-frequency measurement support for the LTE module ===<br />
<br />
Mentors: [mailto:nbaldo@cttc.es Nicola Baldo] [mailto:mmiozzo@cttc.es Marco Miozzo]<br />
<br />
* 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. <br />
<br />
* ''Required Experience:'' C++, LTE<br />
* ''Interests:'' Mobility Management in LTE<br />
* ''Difficulty:'' hard<br />
* ''Recommended reading:''<br />
** [http://www.nsnam.org/docs/release/3.19/models/html/lte-design.html#ue-rrc-measurements-model documentation of the UE Measurement model in the ns-3 LTE module]<br />
** 3GPP TS 36.331 section 5.5 Measurements<br />
** 3GPP TS 36.133, Section 8.2 UE Measurements Procedures in RRC_CONNECTED State <br />
<br />
<br />
<br />
<br />
=== LTE Fractional Frequency Reuse algorithms ===<br />
<br />
Mentors: [mailto:nbaldo@cttc.es Nicola Baldo] [mailto:mmiozzo@cttc.es Marco Miozzo]<br />
<br />
* 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.<br />
* ''Required Experience:'' C++, LTE<br />
* ''Interests:'' Self Organized Networks, HetNets, Inter Cell Interference Coordination<br />
* ''Difficulty:'' hard<br />
* ''Recommended reading:''<br />
** [http://www.nsnam.org/docs/release/3.19/models/html/lte-design.html#mac LTE MAC in ns-3]<br />
** [http://www.nsnam.org/docs/release/3.19/models/html/lte-design.html#x2-c-son-primitives LTE SON primitives in ns-3]<br />
** Thomas Novlan, Jeffrey G. Andrews, Illsoo Sohn, Radha Krishna Ganti, Arunabha Ghosh, "Comparison of Fractional Frequency Reuse Approaches in the OFDMA Cellular Downlink"<br />
** Alexander L. Stolyar, Harish Viswanathan, "Self-organizing Dynamic Fractional Frequency Reuse for Best-Effort Traffic Through Distributed Inter-cell Coordination"<br />
** Heui-Chang Lee, Dong-Chan Oh, and Yong-Hwan Lee, "Mitigation of Inter-Femtocell Interference with Adaptive Fractional Frequency Reuse"<br />
** there are lots of other papers on this topic, please do your own research<br />
<br />
=== GPU acceleration for vector arithmetics in the spectrum module ===<br />
<br />
Mentors: [mailto:nbaldo@cttc.es Nicola Baldo] [mailto:mmiozzo@cttc.es Marco Miozzo]<br />
<br />
* 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). <br />
* ''Required Experience:'' C++<br />
* ''Bonus Experience:'' CUDA, OpenCL...<br />
* ''Interests:'' GPU acceleration<br />
* ''Difficulty:'' hard<br />
* ''Recommended reading:''<br />
** [http://www.nsnam.org/docs/models/html/spectrum.html ns-3 spectrum module documentation]<br />
** http://en.wikipedia.org/wiki/OpenCL<br />
** http://en.wikipedia.org/wiki/CUDA<br />
<br />
<br />
=== Carrier Aggregation support for the LTE module ===<br />
<br />
Mentors: [mailto:mmiozzo@cttc.es Marco Miozzo] [mailto:nbaldo@cttc.es Nicola Baldo]<br />
<br />
* 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.<br />
<br />
* ''Required Experience:'' C++, LTE<br />
* ''Interests:'' LTE-A, HetNet<br />
* ''Difficulty:'' hard<br />
* ''Recommended reading:''<br />
** LTE-A HetNets using Carrier Aggregation, Nomor whitepaper [http://www.nomor.de/uploads/db/a3/dba3e71e617a0ab4b7d3821afd59cc5e/Newsletter_CA_HetNet_2013-06.pdf]<br />
** [http://www.nsnam.org/docs/release/3.19/models/html/lte-design.html]<br />
** 3GPP TS 36.211 <br />
** 3GPP TS 36.213<br />
** 3GPP TS 36.331<br />
<br />
<br />
[[Category:GSoC]]</div>Nicolabaldohttps://www.nsnam.org/mediawiki/index.php?title=GSOC2014Projects&diff=8359GSOC2014Projects2014-02-14T15:49:14Z<p>Nicolabaldo: /* Project Ideas */</p>
<hr />
<div>{{TOC}}<br />
<br />
* [http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2014/help_page GSoC Frequently Asked Questions]<br />
* [http://en.flossmanuals.net/gsocmentoring/ GSoC Mentor guide]<br />
* [http://en.flossmanuals.net/GSoCStudentGuide/ GSoC student guide]<br />
* [[GSOC2013StudentGuide |ns-3's GSoC Student guide]]<br />
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br />
* [[GSOCSelectionProcess | GSoC Student Selection Process]]<br />
* [[GSOC2013PatchRequirement | Patch Requirement Guidelines]]<br />
* [[GSOC2013StudentApplicationTemplate |GSoC Student application template]]<br />
* [[GSOC2013AcceptedProjects | GSoC 2013 Accepted Projects]]<br />
* [[GSOC2012Projects |GSoC 2012 page]] | [[GSOC2012AcceptedProjects |GSoC 2012 Accepted Projects]]<br />
* [[GSOC2011Projects |NSoC 2011 Ideas page]] | [[NSOC2011AcceptedProjects |NSoC 2011 Accepted Projects]]<br />
* [[GSOC2010Projects |GSoC 2010 Ideas page]] | [[GSOC2010AcceptedProjects |GSoC 2010 Accepted Projects]]<br />
* [[GSOC2009Projects |GSoC 2009 Ideas page]] | [[GSOC2009AcceptedProjects |GSoC 2009 Accepted Projects]]<br />
* [[GSOC2010OAReport |GSoC Organization Administrator guide]]<br />
* ''Get in contact with the ns-3 team'': [http://mailman.isi.edu/mailman/listinfo/ns-developers ns-developers mailing list] | ''IRC'' #ns-3 on freenode.net<br />
<br />
= GSoC 2014 Ideas =<br />
<br />
This webpage highlights project ideas for ns-3's Google Summer of Code 2014 effort.<br />
<br />
GSOC 2014 Timeline is:<br />
* February 3 - 20:00 UTC: Mentoring organizations can begin submitting applications to Google.<br />
* February 14 - 20:00 UTC: Mentoring organization application deadline.<br />
* February 24 - 20:00 UTC: List of accepted mentoring organizations published on the Google Summer of Code 2014 site.<br />
* February 24 - March 21: Would-be student participants discuss application ideas with mentoring organizations.<br />
* March 10 - 19:00 UTC: Student application period opens.<br />
* March 21 - 19:00 UTC: Student application deadline.<br />
* April 21 - 19:00 UTC: Student selections announced<br />
* May 19 - Coding begins<br />
* August 18 - Coding ends<br />
Full timeline is here: http://www.google-melange.com/gsoc/events/google/gsoc2014<br />
<br />
While discussions about ideas can be done earlier, please note that ns-3 will not receive an answer to its GSOC application before February 24. <br />
<br />
== About the ns-3 project ==<br />
<br />
ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br />
<br />
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.<br />
<br />
Our GSoC organizational admin is TBD and our backup org admin is [mailto:tomhend@u.washington.edu Tom Henderson]. The project has participated in past GSoCs during 2008-10 and 2012-13.<br />
<br />
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.<br />
<br />
== ns-3 and other GSoC mentoring organisations ==<br />
<br />
ns-3 is one of ~175 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.<br />
<br />
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.<br />
<br />
== Getting started ==<br />
<br />
For students interested in applying to ns-3 for GSOC, go through the following list to get started:<br />
* Read the official [http://en.flossmanuals.net/GSoCStudentGuide/ GSoC student guide].<br />
* Read [[GSOC2013StudentGuide |ns-3's GSoC Student guide]].<br />
* Look through our ideas list below to see if you find a project that interests you.<br />
* Review the [http://www.nsnam.org/ns-3-19/documentation/ ns-3 tutorial] thoroughly, if you have not already done so.<br />
* Look through the [[GSOC2013StudentApplicationTemplate |GSoC Student application template]] to start preparing your proposal.<br />
* Next, proceed to get in touch with the developers on the mailing list and refine your proposal.<br />
* In parallel, make sure you prepare a patch as per the [[GSOC2013PatchRequirement | Patch Requirement Guidelines]]. Your application to ns-3 will not be considered if you do not fulfill this requirement.<br />
<br />
== Project Ideas ==<br />
<br />
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 [http://mailman.isi.edu/mailman/listinfo/ns-developers 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 [http://mailman.isi.edu/mailman/listinfo/ns-developers 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.<br />
<br />
<blockquote><br />
Each project idea within a particular priority has been tagged with the following properties:<br />
* ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br />
* ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br />
* ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful students might apply their experiences coming out of this project.<br />
* ''Difficulty:'' easy, medium or difficult<br />
* ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br />
<br />
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.<br />
</blockquote><br />
<br />
= Guidelines for project ideas =<br />
<br />
For mentors who're adding project ideas to the list below, please ensure that:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
= Project Ideas =<br />
<br />
Please see [[GSOC2013StudentGuide | last year's page]] for guidelines on how to create project ideas.<br />
<br />
'''Note to students:''' These ideas are not listed in any priority order, and other project ideas not listed here are also encouraged.<br />
<br />
=== Decouple traffic generators from sockets ===<br />
<br />
Mentors: [mailto:tomh@tomh.org Tom Henderson] [mailto:rivanvx@gmail.com Vedran Miletić]<br />
<br />
* 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.<br />
* ''Required Experience:'' C++, sockets API<br />
* ''Interests:'' <br />
* ''Difficulty:'' easy/medium<br />
* ''Recommended reading:''<br />
** Unix Network Programming (Stevens) or equivalent<br />
<br />
=== ARP and NDisc cache visibility ===<br />
<br />
Mentors: [mailto:tomh@tomh.org Tom Henderson] [mailto:rivanvx@gmail.com Vedran Miletić]<br />
<br />
* 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).<br />
* ''Required Experience:'' C++<br />
* ''Interests:'' IPv4 and Ipv6<br />
* ''Difficulty:'' easy/medium<br />
* ''Recommended reading:''<br />
** source code in src/internet, and the bugs mentioned above<br />
<br />
=== INSTOOLS for ns-3 ===<br />
<br />
Mentors: [mailto:tomh@tomh.org Tom Henderson]<br />
<br />
'''INSTOOLS for ns-3:''' [http://groups.geni.net/geni/wiki/InstrumentationTools 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.<br />
* ''Required Experience:'' Familiarity with Linux networking and with C++ programming. <br />
* ''Bonus Experience:'' Experience with GENI and/or Emulab<br />
* ''Interests:'' Simulator tool development, integration with testbed experiments<br />
* ''Difficulty:'' Medium<br />
* ''Recommended Reading:'' http://groups.geni.net/geni/wiki/InstrumentationTools<br />
<br />
=== bufferbloat-related models ===<br />
<br />
Mentors: [mailto:tomh@tomh.org Tom Henderson]<br />
<br />
'''bufferbloat models:''' [https://www.youtube.com/watch?v=-D-cJNtKwuw Bufferbloat] is an interesting contemporary research topic. <br />
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.<br />
* ''Interests:'' Internet performance, linux kernel networking <br />
* ''Difficulty:'' easy to hard, depending on the depth of the project<br />
* ''Recommended reading:'' <br />
** http://gettys.wordpress.com/category/bufferbloat/<br />
** [http://www.bufferbloat.net/projects/cerowrt CeroWrt]<br />
** [http://www.ietf.org/proceedings/86/slides/slides-86-iccrg-3.pdf ICCRG presentation]<br />
** [http://pollere.net/CoDel.html ns-2 code]<br />
** [https://codereview.appspot.com/6463048/ ns-3 code review]<br />
<br />
=== 802.15.4 realistic MAC and Energy Model ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br />
<br />
'''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.<br />
The goal of the project are:<br />
# Model the 4-state radio model (Sleep, Tx, Rx, Transitioning)<br />
# Develop one 'realistic' MAC model (the choice is left to the student)<br />
# Link the 4-state model with the Energy module.<br />
<br />
* ''Required Experience:'' C++, WSN<br />
* ''Bonus Experience:'' ns-3 Energy model, lr-wpan module<br />
* ''Interests:'' WSN, Battery discharge<br />
* ''Difficulty:'' hard<br />
* ''Recommended reading:''<br />
** [http://www.sics.se/~adam/dunkels07softwarebased.pdf Software-based On-line Energy Estimation for Sensor Nodes] <br />
** [http://cds.unibe.ch/research/pub_files/HBNH11.pdf On the Accuracy of Software-based Energy Estimation Techniques]<br />
** [http://dunkels.com/adam/dunkels11contikimac.pdf The ContikiMAC Radio Duty Cycling Protocol]<br />
<br />
=== 802.15.4 Bootstrap ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br />
<br />
'''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.<br />
* ''Required Experience:'' C++, WSN<br />
* ''Bonus Experience:'' 802.15.4 standard<br />
* ''Interests:'' WSN<br />
* ''Difficulty:'' medium<br />
* ''Recommended reading:''<br />
** [http://standards.ieee.org/getieee802/download/802.15.4-2011.pdf 802.15.4 Standard]<br />
<br />
<br />
=== 802.15.4 Beacon-enabled mode ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br />
<br />
'''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. <br />
* ''Required Experience:'' C++, WSN<br />
* ''Bonus Experience:'' 802.15.4 standard<br />
* ''Interests:'' WSN<br />
* ''Difficulty:'' medium/hard<br />
* ''Recommended reading:''<br />
** [http://standards.ieee.org/getieee802/download/802.15.4-2011.pdf 802.15.4 Standard]<br />
<br />
=== Neighbor Discovery Optimization for Low Power and Lossy Networks (6LoWPAN-nd) ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br />
<br />
'''6LoWPAN-nd implementation and testing:''' [https://datatracker.ietf.org/doc/rfc6775/ 6LoWPAN-nd] is novel protocol from IETF's [http://tools.ietf.org/wg/6lowpan/ 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. <br />
* ''Required Experience:'' C++, IPv6, RPL<br />
* ''Bonus Experience:'' WSN networking<br />
* ''Interests:'' WSN, IPv6, node bootstrap, efficient packet compression <br />
* ''Difficulty:'' hard<br />
* ''Recommended reading:''<br />
** [http://tools.ietf.org/html/rfc4919 RFC 4919] IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals<br />
** [https://datatracker.ietf.org/doc/rfc6775/ RFC 6775] Neighbor Discovery Optimization for Low Power and Lossy Networks<br />
<br />
=== IPv6 stack validation and improvements ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br />
<br />
'''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):<br />
# There is no [http://en.wikipedia.org/wiki/Path_MTU_discovery path MTU discovery] see also [http://tools.ietf.org/html/rfc1981 RFC 1981].<br />
# Flow Monitor module does not work on the IPv6 stack<br />
# FlowLabel header field is not currenly used<br />
# IPSec is not supported<br />
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.<br />
* ''Required Experience:'' C++, TCP/IP networking<br />
* ''Bonus Experience:'' IPv6 protocols<br />
* ''Interests:'' IPv6 internetworking<br />
* ''Difficulty:'' easy / medium, depending on the features implemented<br />
* ''Recommended reading:''<br />
** [http://www.ietf.org/rfc/rfc4294.txt RFC 4294 - IPv6 Node Requirements]<br />
** [http://tools.ietf.org/html/rfc1981 RFC 1981 - Path MTU Discovery for IP version 6]<br />
** ns-3 Flowmon module documentation<br />
** [http://tools.ietf.org/html/rfc6437 RFC 6437 - IPv6 Flow Label Specification]<br />
** [http://tools.ietf.org/html/rfc4302 RFC 4302 - IP Authentication Header]<br />
** [http://tools.ietf.org/html/rfc4303 RFC 4303 - IP Encapsulating Security Payload (ESP)]<br />
<br />
<br />
=== Multicast IPv6 traffic support ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br />
<br />
'''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.<br />
* ''Required Experience:'' C++, IPv6,<br />
* ''Bonus Experience:'' Multicast routing protocols (MLDv2/IGMPv3 and PIM)<br />
* ''Interests:'' routing, multicast<br />
* ''Difficulty:'' medium/hard<br />
* ''Recommended reading:''<br />
** [http://www.h3c.com/portal/Products___Solutions/Products/Switches/H3C_S5500-SI_Series_Switches/White_Paper/200806/688942_57_0.htm Multicast Technology White Paper]<br />
** [http://www.alliedtelesis.co.nz/documentation/at9800/291/pdf/ipv6mu.pdf IPv6 Multicasting]<br />
** All the relevant RFCs (search in [http://www.rfc-editor.org/search/rfc_search.php RFC Editor search engine])<br />
<br />
<br />
=== Licklider Transmission Protocol (LTP) ===<br />
<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella] [mailto:luca.ronga@cnit.it Luca Ronga]<br />
<br />
<br />
'''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.<br />
* ''Required Experience:'' C++<br />
* ''Bonus Experience:'' Satellite and Deep Space networking<br />
* ''Interests:'' Deep Space networking<br />
* ''Difficulty:'' easy / medium<br />
* ''Recommended reading:''<br />
** [http://en.wikipedia.org/wiki/Licklider_Transmission_Protocol Licklider Transmission Protocol]<br />
** [http://tools.ietf.org/html/rfc5325 RFC 5325: Licklider Transmission Protocol—Motivation]<br />
** [http://tools.ietf.org/html/rfc5326 RFC 5326: Licklider Transmission Protocol—Specification]<br />
** [http://public.ccsds.org/sites/cwe/rids/Lists/CCSDS%207341R2/Attachments/734x1r2.pdf Licklider Transmission Protocol (LTP) for CCSDS]<br />
<br />
<br />
<br />
<br />
<br />
=== Inter-frequency measurement support for the LTE module ===<br />
<br />
Mentors: [mailto:nbaldo@cttc.es Nicola Baldo] [mailto:mmiozzo@cttc.es Marco Miozzo]<br />
<br />
* 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. <br />
<br />
* ''Required Experience:'' C++, LTE<br />
* ''Interests:'' Mobility Management in LTE<br />
* ''Difficulty:'' hard<br />
* ''Recommended reading:''<br />
** [http://www.nsnam.org/docs/release/3.19/models/html/lte-design.html#ue-rrc-measurements-model documentation of the UE Measurement model in the ns-3 LTE module]<br />
** 3GPP TS 36.331 section 5.5 Measurements<br />
** 3GPP TS 36.133, Section 8.2 UE Measurements Procedures in RRC_CONNECTED State <br />
<br />
<br />
<br />
<br />
=== LTE Fractional Frequency Reuse algorithms ===<br />
<br />
Mentors: [mailto:nbaldo@cttc.es Nicola Baldo] [mailto:mmiozzo@cttc.es Marco Miozzo]<br />
<br />
* The aim of this project is to develop a set of model for 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.<br />
* ''Required Experience:'' C++, LTE<br />
* ''Interests:'' Self Organized Networks, HetNets, Inter Cell Interference Coordination<br />
* ''Difficulty:'' hard<br />
* ''Recommended reading:''<br />
** [http://www.nsnam.org/docs/release/3.19/models/html/lte-design.html#mac LTE MAC in ns-3]<br />
** [http://www.nsnam.org/docs/release/3.19/models/html/lte-design.html#x2-c-son-primitives LTE SON primitives in ns-3]<br />
** Thomas Novlan, Jeffrey G. Andrews, Illsoo Sohn, Radha Krishna Ganti, Arunabha Ghosh, "Comparison of Fractional Frequency Reuse Approaches in the OFDMA Cellular Downlink"<br />
** Alexander L. Stolyar, Harish Viswanathan, "Self-organizing Dynamic Fractional Frequency Reuse for Best-Effort Traffic Through Distributed Inter-cell Coordination"<br />
** Heui-Chang Lee, Dong-Chan Oh, and Yong-Hwan Lee, "Mitigation of Inter-Femtocell Interference with Adaptive Fractional Frequency Reuse"<br />
** there are lots of other papers on this topic, please do your own research<br />
<br />
<br />
<br />
=== GPU acceleration for vector arithmetics in the spectrum module ===<br />
<br />
Mentors: [mailto:nbaldo@cttc.es Nicola Baldo] [mailto:mmiozzo@cttc.es Marco Miozzo]<br />
<br />
* 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). <br />
* ''Required Experience:'' C++<br />
* ''Bonus Experience:'' CUDA, OpenCL...<br />
* ''Interests:'' GPU acceleration<br />
* ''Difficulty:'' hard<br />
* ''Recommended reading:''<br />
** [http://www.nsnam.org/docs/models/html/spectrum.html ns-3 spectrum module documentation]<br />
** http://en.wikipedia.org/wiki/OpenCL<br />
** http://en.wikipedia.org/wiki/CUDA<br />
<br />
<br />
=== Carrier Aggregation support for the LTE module ===<br />
<br />
Mentors: [mailto:mmiozzo@cttc.es Marco Miozzo] [mailto:nbaldo@cttc.es Nicola Baldo]<br />
<br />
* 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.<br />
<br />
* ''Required Experience:'' C++, LTE<br />
* ''Interests:'' LTE-A, HetNet<br />
* ''Difficulty:'' hard<br />
* ''Recommended reading:''<br />
** LTE-A HetNets using Carrier Aggregation, Nomor whitepaper [http://www.nomor.de/uploads/db/a3/dba3e71e617a0ab4b7d3821afd59cc5e/Newsletter_CA_HetNet_2013-06.pdf]<br />
** [http://www.nsnam.org/docs/release/3.19/models/html/lte-design.html]<br />
** 3GPP TS 36.211 <br />
** 3GPP TS 36.213<br />
** 3GPP TS 36.331<br />
<br />
<br />
[[Category:GSoC]]</div>Nicolabaldohttps://www.nsnam.org/mediawiki/index.php?title=GSOC2014Projects&diff=8358GSOC2014Projects2014-02-14T13:31:03Z<p>Nicolabaldo: /* Project Ideas */</p>
<hr />
<div>{{TOC}}<br />
<br />
* [http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2014/help_page GSoC Frequently Asked Questions]<br />
* [http://en.flossmanuals.net/gsocmentoring/ GSoC Mentor guide]<br />
* [http://en.flossmanuals.net/GSoCStudentGuide/ GSoC student guide]<br />
* [[GSOC2013StudentGuide |ns-3's GSoC Student guide]]<br />
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br />
* [[GSOCSelectionProcess | GSoC Student Selection Process]]<br />
* [[GSOC2013PatchRequirement | Patch Requirement Guidelines]]<br />
* [[GSOC2013StudentApplicationTemplate |GSoC Student application template]]<br />
* [[GSOC2013AcceptedProjects | GSoC 2013 Accepted Projects]]<br />
* [[GSOC2012Projects |GSoC 2012 page]] | [[GSOC2012AcceptedProjects |GSoC 2012 Accepted Projects]]<br />
* [[GSOC2011Projects |NSoC 2011 Ideas page]] | [[NSOC2011AcceptedProjects |NSoC 2011 Accepted Projects]]<br />
* [[GSOC2010Projects |GSoC 2010 Ideas page]] | [[GSOC2010AcceptedProjects |GSoC 2010 Accepted Projects]]<br />
* [[GSOC2009Projects |GSoC 2009 Ideas page]] | [[GSOC2009AcceptedProjects |GSoC 2009 Accepted Projects]]<br />
* [[GSOC2010OAReport |GSoC Organization Administrator guide]]<br />
* ''Get in contact with the ns-3 team'': [http://mailman.isi.edu/mailman/listinfo/ns-developers ns-developers mailing list] | ''IRC'' #ns-3 on freenode.net<br />
<br />
= GSoC 2014 Ideas =<br />
<br />
This webpage highlights project ideas for ns-3's Google Summer of Code 2014 effort.<br />
<br />
GSOC 2014 Timeline is:<br />
* February 3 - 20:00 UTC: Mentoring organizations can begin submitting applications to Google.<br />
* February 14 - 20:00 UTC: Mentoring organization application deadline.<br />
* February 24 - 20:00 UTC: List of accepted mentoring organizations published on the Google Summer of Code 2014 site.<br />
* February 24 - March 21: Would-be student participants discuss application ideas with mentoring organizations.<br />
* March 10 - 19:00 UTC: Student application period opens.<br />
* March 21 - 19:00 UTC: Student application deadline.<br />
* April 21 - 19:00 UTC: Student selections announced<br />
* May 19 - Coding begins<br />
* August 18 - Coding ends<br />
Full timeline is here: http://www.google-melange.com/gsoc/events/google/gsoc2014<br />
<br />
While discussions about ideas can be done earlier, please note that ns-3 will not receive an answer to its GSOC application before February 24. <br />
<br />
== About the ns-3 project ==<br />
<br />
ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br />
<br />
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.<br />
<br />
Our GSoC organizational admin is TBD and our backup org admin is [mailto:tomhend@u.washington.edu Tom Henderson]. The project has participated in past GSoCs during 2008-10 and 2012-13.<br />
<br />
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.<br />
<br />
== ns-3 and other GSoC mentoring organisations ==<br />
<br />
ns-3 is one of ~175 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.<br />
<br />
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.<br />
<br />
== Getting started ==<br />
<br />
For students interested in applying to ns-3 for GSOC, go through the following list to get started:<br />
* Read the official [http://en.flossmanuals.net/GSoCStudentGuide/ GSoC student guide].<br />
* Read [[GSOC2013StudentGuide |ns-3's GSoC Student guide]].<br />
* Look through our ideas list below to see if you find a project that interests you.<br />
* Review the [http://www.nsnam.org/ns-3-19/documentation/ ns-3 tutorial] thoroughly, if you have not already done so.<br />
* Look through the [[GSOC2013StudentApplicationTemplate |GSoC Student application template]] to start preparing your proposal.<br />
* Next, proceed to get in touch with the developers on the mailing list and refine your proposal.<br />
* In parallel, make sure you prepare a patch as per the [[GSOC2013PatchRequirement | Patch Requirement Guidelines]]. Your application to ns-3 will not be considered if you do not fulfill this requirement.<br />
<br />
== Project Ideas ==<br />
<br />
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 [http://mailman.isi.edu/mailman/listinfo/ns-developers 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 [http://mailman.isi.edu/mailman/listinfo/ns-developers 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.<br />
<br />
<blockquote><br />
Each project idea within a particular priority has been tagged with the following properties:<br />
* ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br />
* ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br />
* ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful students might apply their experiences coming out of this project.<br />
* ''Difficulty:'' easy, medium or difficult<br />
* ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br />
<br />
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.<br />
</blockquote><br />
<br />
= Guidelines for project ideas =<br />
<br />
For mentors who're adding project ideas to the list below, please ensure that:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
= Project Ideas =<br />
<br />
Please see [[GSOC2013StudentGuide | last year's page]] for guidelines on how to create project ideas.<br />
<br />
'''Note to students:''' These ideas are not listed in any priority order, and other project ideas not listed here are also encouraged.<br />
<br />
=== Decouple traffic generators from sockets ===<br />
<br />
Mentors: [mailto:tomh@tomh.org Tom Henderson] [mailto:rivanvx@gmail.com Vedran Miletić]<br />
<br />
* 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.<br />
* ''Required Experience:'' C++, sockets API<br />
* ''Interests:'' <br />
* ''Difficulty:'' easy/medium<br />
* ''Recommended reading:''<br />
** Unix Network Programming (Stevens) or equivalent<br />
<br />
=== ARP and NDisc cache visibility ===<br />
<br />
Mentors: [mailto:tomh@tomh.org Tom Henderson] [mailto:rivanvx@gmail.com Vedran Miletić]<br />
<br />
* 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).<br />
* ''Required Experience:'' C++<br />
* ''Interests:'' IPv4 and Ipv6<br />
* ''Difficulty:'' easy/medium<br />
* ''Recommended reading:''<br />
** source code in src/internet, and the bugs mentioned above<br />
<br />
=== INSTOOLS for ns-3 ===<br />
<br />
Mentors: [mailto:tomh@tomh.org Tom Henderson]<br />
<br />
'''INSTOOLS for ns-3:''' [http://groups.geni.net/geni/wiki/InstrumentationTools 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.<br />
* ''Required Experience:'' Familiarity with Linux networking and with C++ programming. <br />
* ''Bonus Experience:'' Experience with GENI and/or Emulab<br />
* ''Interests:'' Simulator tool development, integration with testbed experiments<br />
* ''Difficulty:'' Medium<br />
* ''Recommended Reading:'' http://groups.geni.net/geni/wiki/InstrumentationTools<br />
<br />
=== bufferbloat-related models ===<br />
<br />
Mentors: [mailto:tomh@tomh.org Tom Henderson]<br />
<br />
'''bufferbloat models:''' [https://www.youtube.com/watch?v=-D-cJNtKwuw Bufferbloat] is an interesting contemporary research topic. <br />
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.<br />
* ''Interests:'' Internet performance, linux kernel networking <br />
* ''Difficulty:'' easy to hard, depending on the depth of the project<br />
* ''Recommended reading:'' <br />
** http://gettys.wordpress.com/category/bufferbloat/<br />
** [http://www.bufferbloat.net/projects/cerowrt CeroWrt]<br />
** [http://www.ietf.org/proceedings/86/slides/slides-86-iccrg-3.pdf ICCRG presentation]<br />
** [http://pollere.net/CoDel.html ns-2 code]<br />
** [https://codereview.appspot.com/6463048/ ns-3 code review]<br />
<br />
=== 802.15.4 realistic MAC and Energy Model ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br />
<br />
'''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.<br />
The goal of the project are:<br />
# Model the 4-state radio model (Sleep, Tx, Rx, Transitioning)<br />
# Develop one 'realistic' MAC model (the choice is left to the student)<br />
# Link the 4-state model with the Energy module.<br />
<br />
* ''Required Experience:'' C++, WSN<br />
* ''Bonus Experience:'' ns-3 Energy model, lr-wpan module<br />
* ''Interests:'' WSN, Battery discharge<br />
* ''Difficulty:'' hard<br />
* ''Recommended reading:''<br />
** [http://www.sics.se/~adam/dunkels07softwarebased.pdf Software-based On-line Energy Estimation for Sensor Nodes] <br />
** [http://cds.unibe.ch/research/pub_files/HBNH11.pdf On the Accuracy of Software-based Energy Estimation Techniques]<br />
** [http://dunkels.com/adam/dunkels11contikimac.pdf The ContikiMAC Radio Duty Cycling Protocol]<br />
<br />
=== 802.15.4 Bootstrap ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br />
<br />
'''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.<br />
* ''Required Experience:'' C++, WSN<br />
* ''Bonus Experience:'' 802.15.4 standard<br />
* ''Interests:'' WSN<br />
* ''Difficulty:'' medium<br />
* ''Recommended reading:''<br />
** [http://standards.ieee.org/getieee802/download/802.15.4-2011.pdf 802.15.4 Standard]<br />
<br />
<br />
=== 802.15.4 Beacon-enabled mode ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br />
<br />
'''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. <br />
* ''Required Experience:'' C++, WSN<br />
* ''Bonus Experience:'' 802.15.4 standard<br />
* ''Interests:'' WSN<br />
* ''Difficulty:'' medium/hard<br />
* ''Recommended reading:''<br />
** [http://standards.ieee.org/getieee802/download/802.15.4-2011.pdf 802.15.4 Standard]<br />
<br />
=== Neighbor Discovery Optimization for Low Power and Lossy Networks (6LoWPAN-nd) ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br />
<br />
'''6LoWPAN-nd implementation and testing:''' [https://datatracker.ietf.org/doc/rfc6775/ 6LoWPAN-nd] is novel protocol from IETF's [http://tools.ietf.org/wg/6lowpan/ 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. <br />
* ''Required Experience:'' C++, IPv6, RPL<br />
* ''Bonus Experience:'' WSN networking<br />
* ''Interests:'' WSN, IPv6, node bootstrap, efficient packet compression <br />
* ''Difficulty:'' hard<br />
* ''Recommended reading:''<br />
** [http://tools.ietf.org/html/rfc4919 RFC 4919] IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals<br />
** [https://datatracker.ietf.org/doc/rfc6775/ RFC 6775] Neighbor Discovery Optimization for Low Power and Lossy Networks<br />
<br />
=== IPv6 stack validation and improvements ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br />
<br />
'''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):<br />
# There is no [http://en.wikipedia.org/wiki/Path_MTU_discovery path MTU discovery] see also [http://tools.ietf.org/html/rfc1981 RFC 1981].<br />
# Flow Monitor module does not work on the IPv6 stack<br />
# FlowLabel header field is not currenly used<br />
# IPSec is not supported<br />
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.<br />
* ''Required Experience:'' C++, TCP/IP networking<br />
* ''Bonus Experience:'' IPv6 protocols<br />
* ''Interests:'' IPv6 internetworking<br />
* ''Difficulty:'' easy / medium, depending on the features implemented<br />
* ''Recommended reading:''<br />
** [http://www.ietf.org/rfc/rfc4294.txt RFC 4294 - IPv6 Node Requirements]<br />
** [http://tools.ietf.org/html/rfc1981 RFC 1981 - Path MTU Discovery for IP version 6]<br />
** ns-3 Flowmon module documentation<br />
** [http://tools.ietf.org/html/rfc6437 RFC 6437 - IPv6 Flow Label Specification]<br />
** [http://tools.ietf.org/html/rfc4302 RFC 4302 - IP Authentication Header]<br />
** [http://tools.ietf.org/html/rfc4303 RFC 4303 - IP Encapsulating Security Payload (ESP)]<br />
<br />
<br />
=== Multicast IPv6 traffic support ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br />
<br />
'''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.<br />
* ''Required Experience:'' C++, IPv6,<br />
* ''Bonus Experience:'' Multicast routing protocols (MLDv2/IGMPv3 and PIM)<br />
* ''Interests:'' routing, multicast<br />
* ''Difficulty:'' medium/hard<br />
* ''Recommended reading:''<br />
** [http://www.h3c.com/portal/Products___Solutions/Products/Switches/H3C_S5500-SI_Series_Switches/White_Paper/200806/688942_57_0.htm Multicast Technology White Paper]<br />
** [http://www.alliedtelesis.co.nz/documentation/at9800/291/pdf/ipv6mu.pdf IPv6 Multicasting]<br />
** All the relevant RFCs (search in [http://www.rfc-editor.org/search/rfc_search.php RFC Editor search engine])<br />
<br />
<br />
=== Licklider Transmission Protocol (LTP) ===<br />
<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella] [mailto:luca.ronga@cnit.it Luca Ronga]<br />
<br />
<br />
'''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.<br />
* ''Required Experience:'' C++<br />
* ''Bonus Experience:'' Satellite and Deep Space networking<br />
* ''Interests:'' Deep Space networking<br />
* ''Difficulty:'' easy / medium<br />
* ''Recommended reading:''<br />
** [http://en.wikipedia.org/wiki/Licklider_Transmission_Protocol Licklider Transmission Protocol]<br />
** [http://tools.ietf.org/html/rfc5325 RFC 5325: Licklider Transmission Protocol—Motivation]<br />
** [http://tools.ietf.org/html/rfc5326 RFC 5326: Licklider Transmission Protocol—Specification]<br />
** [http://public.ccsds.org/sites/cwe/rids/Lists/CCSDS%207341R2/Attachments/734x1r2.pdf Licklider Transmission Protocol (LTP) for CCSDS]<br />
<br />
<br />
<br />
<br />
<br />
=== Inter-frequency measurement support for the LTE module ===<br />
<br />
Mentors: [mailto:nbaldo@cttc.es Nicola Baldo]<br />
<br />
* 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. <br />
<br />
* ''Required Experience:'' C++, LTE<br />
* ''Interests:'' Mobility Management in LTE<br />
* ''Difficulty:'' hard<br />
* ''Recommended reading:''<br />
** [http://www.nsnam.org/docs/release/3.19/models/html/lte-design.html#ue-rrc-measurements-model documentation of the UE Measurement model in the ns-3 LTE module]<br />
** 3GPP TS 36.331 section 5.5 Measurements<br />
** 3GPP TS 36.133, Section 8.2 UE Measurements Procedures in RRC_CONNECTED State <br />
<br />
<br />
<br />
<br />
=== LTE Fractional Frequency Reuse algorithms ===<br />
<br />
Mentors: [mailto:nbaldo@cttc.es Nicola Baldo]<br />
<br />
* The aim of this project is to develop a set of model for 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.<br />
* ''Required Experience:'' C++, LTE<br />
* ''Interests:'' Self Organized Networks, HetNets, Inter Cell Interference Coordination<br />
* ''Difficulty:'' hard<br />
* ''Recommended reading:''<br />
** [http://www.nsnam.org/docs/release/3.19/models/html/lte-design.html#mac LTE MAC in ns-3]<br />
** [http://www.nsnam.org/docs/release/3.19/models/html/lte-design.html#x2-c-son-primitives LTE SON primitives in ns-3]<br />
** Thomas Novlan, Jeffrey G. Andrews, Illsoo Sohn, Radha Krishna Ganti, Arunabha Ghosh, "Comparison of Fractional Frequency Reuse Approaches in the OFDMA Cellular Downlink"<br />
** Alexander L. Stolyar, Harish Viswanathan, "Self-organizing Dynamic Fractional Frequency Reuse for Best-Effort Traffic Through Distributed Inter-cell Coordination"<br />
** Heui-Chang Lee, Dong-Chan Oh, and Yong-Hwan Lee, "Mitigation of Inter-Femtocell Interference with Adaptive Fractional Frequency Reuse"<br />
** there are lots of other papers on this topic, please do your own research<br />
<br />
<br />
<br />
=== GPU acceleration for vector arithmetics in the spectrum module ===<br />
<br />
Mentors: [mailto:nbaldo@cttc.es Nicola Baldo]<br />
<br />
* 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). <br />
* ''Required Experience:'' C++<br />
* ''Bonus Experience:'' CUDA, OpenCL...<br />
* ''Interests:'' GPU acceleration<br />
* ''Difficulty:'' hard<br />
* ''Recommended reading:''<br />
** [http://www.nsnam.org/docs/models/html/spectrum.html ns-3 spectrum module documentation]<br />
** http://en.wikipedia.org/wiki/OpenCL<br />
** http://en.wikipedia.org/wiki/CUDA<br />
<br />
<br />
<br />
<br />
[[Category:GSoC]]</div>Nicolabaldohttps://www.nsnam.org/mediawiki/index.php?title=GSOC2013UeMeasurementActiveIdle&diff=7631GSOC2013UeMeasurementActiveIdle2013-06-04T12:32:25Z<p>Nicolabaldo: /* Project overview */</p>
<hr />
<div>== Project overview ==<br />
<br />
* '''Project name:''' Improvements to UE Measurements in Active and Idle Mode for the LTE Module<br />
<br />
* '''Student:''' [mailto:buherman@student.jyu.fi Budiarto Herman]<br />
<br />
* '''Mentors:''' [mailto:nicola.baldo@cttc.es Nicola Baldo], [mailto:marco.miozzo@cttc.es Marco Miozzo], [mailto:mrequena@cttc.es Manuel Requena], [mailto:jaime.ferragut@cttc.es Jaime Ferragut]<br />
<br />
* '''Abstract:''' The LTE module of ns-3 was recently updated (LENA M6) with support for UE measurements and automatic handover. The project aims to improve these models with more advanced features based on 3GPP E-UTRAN specifications and several research publications. The development covers three major features: UE measurements, initial cell selection, and handover algorithms.<br />
<br />
* '''Related links:'''<br />
** [[code.nsnam.org |Code repository (TBD)]]<br />
** [[GSOC2013UeMeasurementActiveIdle/MidTermReport |Mid-term evaluation report]]<br />
** [[GSOC2013UeMeasurementActiveIdle/FinalReport |Final evaluation report]]<br />
<br />
* '''About me (the student).''' I'm a Master's student in University of Jyväskylä, Finland. Radio technology is my major subject study and I'm working on simulations of LTE using ns-3.<br />
<br />
== Approach ==<br />
<br />
The project is divided into three major ''blocks'':<br />
<br />
; UE measurements : Additional reporting configuration to UE measurement model.<br />
<!-- Consider separating this into triggers and configuration --><br />
<br />
; Initial cell selection : UE mechanism to automatically determine the best eNodeB to attach to, based on RSRP.<br />
<br />
; Handover algorithms : Two additional handover algorithms for automatic handover execution.<br />
<br />
The UE measurements block can be said as the core piece of the project, because the other blocks are dependant on it. For instance, initial cell selection utilizes the measurements of RSRP gathered during UE's idle state. While handover algorithms will request certain measurements and ''consume'' them during UE's active state.<br />
<br />
=== Code base ===<br />
<br />
The development will be conducted using the latest revision of LENA ([http://lena.cttc.es/hg/lena/ Mercurial repository]) as the code base. The reason behind this decision is the fact that several important features are not yet available in ''ns-3-dev'' repository at the time the project begins. For example, LENA M6 was released with some supports of UE measurements and automatic handover, which are essential for the project.<br />
<!-- Later update with the exact number of revision where the repository is cloned from --><br />
<br />
During the course of the project, updates in LENA repository may be pulled to the project repository on a case-by-case basis.<br />
<br />
=== Methodology ===<br />
<br />
Despite the dependencies, each of the project blocks are designed to be cohesive by itself. Hence the project will focus on one block at a time, and then move on to the next block. The development of each block includes the actual code, test code, documentation, and code review. Progress will be published in frequent basis to the public repository.<br />
<br />
The following pseudocode illustrates the procedure outlined above.<br />
<br />
<code><br />
for each project block X<br />
write design documentation of X<br />
define test vector of X<br />
implement X<br />
write test code for X<br />
write test documentation for X<br />
submit X to rietveld for code review<br />
end for<br />
</code><br />
<br />
<br />
<br />
== Deliverables ==<br />
<br />
Each deliverable is labeled with a letter and an integer. The letter corresponds to the block which the deliverable is associated with.<br />
<br />
* Deliverables related to UE measurements:<br />
** ''D1:'' Design documentation<br />
** ''D2:'' Test vector definition<br />
** ''D3:'' Periodical reporting criteria<br />
** ''D4:'' Event A1 evaluator<br />
** ''D5:'' Event A3 evaluator<br />
** ''D6:'' Event A5 evaluator<br />
** '''Milestone-I:''' Immediate reporting criteria are complete<br />
** ''D7:'' Support for time-to-trigger<br />
** '''Milestone-II:''' Time-to-trigger support is ready<br />
** ''D8:'' Modular interface for configuring reporting<br />
** ''D9:'' Test case verifying different combinations of configuration<br />
** '''Milestone-III:''' Reporting is configurable<br />
** ''D10:'' Test documentation<br />
<br />
* Deliverables related to initial cell selection:<br />
** ''E1:'' Design documentation<br />
** ''E2:'' Test vector definition<br />
** ''E3:'' UE measurement during IDLE_CELL_SELECTION<br />
** ''E4:'' UE attachment to the strongest cell<br />
** ''E5:'' RSRP option for REM<br />
** ''E6:'' Test case with fast fading<br />
** ''E7:'' Test case with buildings<br />
** '''Milestone-IV:''' Initial cell selection is verified<br />
** ''E8:'' Test documentation<br />
<br />
* Deliverables related to handover algorithms:<br />
** ''F1:'' Design documentation<br />
** ''F2:'' Choice of reference publication<br />
** ''F3:'' Test vector definition<br />
** ''F4:'' Handover algorithm SAP interface<br />
** ''F5:'' Strongest-cell algorithm<br />
** ''F6:'' Topology helper for test simulation<br />
** '''Milestone-V:''' Ideal handover functionality is ready<br />
** ''F7:'' Ping-pong detector<br />
** ''F8:'' Ping-pong test case<br />
** ''F9:'' Example updated<br />
** ''F10:'' Failure case during Random Access<br />
** ''F11:'' Failure case during RRC Connection Reconfiguration<br />
** ''F12:'' Failure test case<br />
** '''Milestone-VI:''' Realistic handover functionality is ready<br />
** ''F13:'' Test suite for model validation with reference publication<br />
** ''F14:'' Analysis of model validation<br />
** '''Milestone-VII:''' Handover model is validated<br />
** ''F15:'' UTPR algorithm<br />
** ''F16:'' Test case updated<br />
** '''Milestone-VIII:''' Second handover model is validated<br />
** ''F17:'' Test documentation updated<br />
<br />
<br />
<br />
== Schedule ==<br />
<br />
After acceptance notice is announced in the beginning of Week 22 (May 27), the project will enter the community bonding period, which consist of the following activities:<br />
<br />
* Setting up a Wiki account<br />
* Setting up access to repository<br />
* Initial meeting with mentors<br />
* Answering questions in ''ns-3-users''<br />
* D1<br />
* D2<br />
<br />
Then at Week 25 (June 17) the coding phase will begin. The first half of the project is planned as follow:<br />
<br />
* ''Week 25:'' D3, D4, D5, D6, Milestone-I<br />
* ''Week 26:'' D7, Milestone-II, D8<br />
* ''Week 27:'' D9, Milestone-III, D10<br />
* ''Week 28:'' E1, E2, E3<br />
* ''Week 29:'' E4, E5, E6<br />
* ''Week 30:'' E7, Milestone-IV, E8, F1<br />
<br />
Week 31 (July 29) will be reserved for mid-term evaluation. After that (August 5), the second half of the project will begin as below:<br />
<br />
* ''Week 32:'' F2, F3, F4<br />
* ''Week 33:'' F5, F6, Milestone-V,<br />
* ''Week 34:'' F7, F8, F9, F10<br />
* ''Week 35:'' F11, F12, Milestone-VI, F13<br />
* ''Week 36:'' F14, Milestone-VII, F15<br />
* ''Week 37:'' F16, Milestone-VIII, F17<br />
<br />
Week 38 (September 16) will be the pencil down week, and Week 39 (September 23) will be allocated for the final evaluation.<br />
<br />
<br />
<br />
== Progress Report ==<br />
<br />
Reports on progress are divided into weekly, mid-term, and final reports. The weekly reports will be available in this section after the end of the corresponding week. On the other hand, the other types of reports are available from separate Wiki pages ([[GSOC2013UeMeasurementActiveIdle/MidTermReport |mid-term evaluation report]] and [[GSOC2013UeMeasurementActiveIdle/FinalReport |final evaluation report]]).</div>Nicolabaldohttps://www.nsnam.org/mediawiki/index.php?title=Developer_FAQ&diff=7608Developer FAQ2013-05-31T17:40:02Z<p>Nicolabaldo: /* Mercurial tips */</p>
<hr />
<div>{{TOC}}<br />
<br />
== Mercurial repository layout for developers ==<br />
<br />
# In your home dir on code.nsnam.org, you will find a new directory named "<code>repositories/username</code>". e.g.: <code>/home/tomh/repositories/tomh</code>. If you create a repository in this directory, it will appear automatically on http://code.nsnam.org<br />
#* Note: To enable this for new users, edit /var/www/cgi-hg/hgweb.config<br />
# You can obviously ssh to your personal account and manage these repositories<br />
# You can push to these repositories with the command: <code>hg push ssh://tomh@code.nsnam.org/repositories/tomh/ns-3-com</code><br />
# You can pull with the usual commands: <code>hg clone http://code.nsnam.org/tomh/ns-3-com</code><br />
# If you want to allow another user to push into your repository, all you have to do is change the unix permissions of your repository to allow this user write permissions. This means that if you want to give everyone write permissions, you can "<code>chmod -R g +rw /home/tomh/repositories/tomh/ns-3-com/</code>". If you want to allow only a smaller subset of users to push, we will need to create unix group which matches this subset<br />
# The push command for the main tree is still: <code>hg push ssh://code@code.nsnam.org/repos/ns-3-dev</code><br />
# '''New developers, please read this:''' When creating a new repository, do not "hg clone" it into your directory on code.nsnam.org (which will generate a big ns-commits mail message); instead, just copy (cp -r) or rsync it to your local "/home/username/repositories/username" directory.<br />
<br />
=== Mercurial tips ===<br />
<br />
# '''How to undo a commit''': Let's suppose you are working on a private repository and you check something in, but some other files were inadvertently checked in, and you want to revert and start over. There are two ways to do this:<br />
## <code>hg revert</code>: This can be used to revert the repository to a previous revision number. For example, to revert to changeset number #1000, type <code>hg revert -r 1000 --all</code>. This does '''not''' remove your checkin from the repository history. For example, if your mistaken checkin was number 1001, and you revert back to 1000 and then commit, you will be at changeset number 1002 now even though the code matches what was in there at changeset 1000.<br />
## <code>hg rollback</code>: This can be used to completely wipe clean the last transaction only (commit, import, push, pull). Use with care-- cannot be undone. <br />
# '''How to rename a file''': <code>hg rename old-file-name new-file-name</code> This is preferable to adding the new file name and removing the old file name, because it preserves revision history. Don't forget to commit once you are done.<br />
# '''How to merge a branch''': If you have forked a branch repository, have worked on it, and are ready to merge it back to ns-3-dev, here are the steps to take (Also, read [http://hgbook.red-bean.com/hgbookch3.html this chapter] to better understand how the mercurial source tree is structured when merging is occurring):<br />
##''cd into your branch''<br />
##<code>hg pull http://code.nsnam.org/ns-3-dev</code><br />
##<code>hg merge</code><br />
##''resolve all of the merge issues, if any, and confirm that it builds and validates''<br />
##<code>hg ci -m"merge your-branch-name with tip"</code><br />
##<code>hg push ssh://code@code.nsnam.org/repos/ns-3-dev</code><br />
# '''How to create patches for circulation''': <code>hg export tip</code> Suppose you don't have write access to the main repositories, but have some patches you'd like to circulate. This command outputs out all the diffs for the latest changeset you committed into your local repository. Simply redirect this output to a file, and you can circulate your patch for consideration. This is for when you have committed changesets. If you would like to export uncommitted changes as a patch, use: <code>hg diff</code> This gets the diffs of all the uncommitted changes versus what is checked into the repository. Redirect to a file for circulation among developers, or for inclusion with a bug report, etc.<br />
# '''Save a push URL so that you don't need to enter it each time''': If you are tired of having to specify the same ssh URL each time when you go to push, you can specify a default push location in the branch's local hgrc.<br />
##''cd into your branch''<br />
##<code>vi .hg/hgrc</code><br />
##''add the following line to the [paths] section''<br />
##<code>default-push = ssh://username@code.nsnam.org/repositories/username/ns-3-reponame</code><br />
##<code>hg push</code> should now "just work" without the URL<br />
# '''How to fix two-headed repositories''': Note, please never check in code by forcing it (with hg push -f option). This will cause the repository to have multiple heads. If the repository ends up with two heads, this can fix it:<br />
##<code>hg merge</code><br />
##<code>hg commit -m"merge two heads"</code><br />
##<code>hg push ... </code><br />
# '''Don't use named branches''': that is, never do "<code>hg branch</code>" nor "<code>hg push --new-branch</code>"<br />
<br />
== The WAF build system ==<br />
See also the [http://www.nsnam.org/wiki/index.php/User_FAQ#WAF_.28new_build_process.29 Waf User FAQ].<br />
<br />
=== Obtaining WAF ===<br />
A snapshot of WAF is distributed with ns-3 releases and mercurial branches. This snapshopt has been tested to work correctly with ns-3, although the ''trunk'' version from the main WAF repository usually works equally well.<br />
<br />
=== Documentation resources ===<br />
There is a [http://freehackers.org/~tnagy/wafbook/index.html WAF book]. Some useful tips can be found in the [http://code.google.com/p/waf/w/list WAF Wiki]. Finally, there is a plethora of examples distributed in WAF itself, in the 'demos' directory.<br />
<br />
=== How to add new ns-3 modules ===<br />
<br />
Ns-3 is organized as a set of ''modules''. Each module is built as a set of object files, has a name, may depend on other modules, and installs a specific set of ''public header files''.<br />
<br />
Starting with version 3.11, ns-3 went to a modular directory structure. The following chapter in the ns-3 Manual shows how to add a module in the new directory structure:<br />
<br />
:[http://www.nsnam.org/docs/release/3.13/manual/html/new-modules.html Adding a New Module to ns-3 (version 3.11 or later)]<br />
<br />
If you are using a version of ns-3 earlier than 3.11, then follow the instructions in this FAQ.<br />
<br />
To add a new ns-3 module to the WAF build system, begin by creating a directory under the <code>src/</code> subtree, with the source files inside. We will use ''p2p'' module as example here. Each module needs to define a <code>wscript</code> file. For instance let us see what <code>src/devices/point-to-point/wscript</code> contains:<br />
<pre><br />
## -*- Mode: python; py-indent-offset: 4; indent-tabs-mode: nil; coding: utf-8; -*-<br />
<br />
def build(bld):<br />
module = bld.create_ns3_module('point-to-point', ['node'])<br />
module.source = [<br />
'point-to-point-net-device.cc',<br />
'point-to-point-channel.cc',<br />
'point-to-point-topology.cc',<br />
]<br />
headers = bld.create_obj('ns3header')<br />
headers.module = 'point-to-point'<br />
headers.source = [<br />
'point-to-point-net-device.h',<br />
'point-to-point-channel.h',<br />
'point-to-point-topology.h',<br />
]<br />
</pre><br />
<br />
A wscript file is basically a special python module. The main entry point to this module is the <code>build(bld)</code> python function.<br />
<br />
In the code above, the ''module'' variable represents a ns-3 module; internally it is a WAF 'objects' build object that will be linked to be come part of the ns3 library. It is created by calling a special method bld.create_ns3_module, whose first parameter is the name of the module, and the second parameter is a list of other modules that this module depends on. Additionally, module.sources has to be set to the list of source files (excluding header files) that constitute the module. Warning: beware that the name of the module must match the name of the directory where it is built. In this case, the module is in 'src/devices/point-to-point', so the module name must be 'point-to-point'.<br />
<br />
There is usually also a ''headers'' object. It is used to declare public header files. These files are copied to the build directory, and can be included from any module or program with <code>#include "ns3/header-name.h"</code>.<br />
<br />
A final step, after the wscript file is created, is to register it. Open the file <code>src/wscript</code> and add the new module to the <code>all_modules</code> list variable:<br />
<pre><br />
all_modules = (<br />
'core',<br />
'common',<br />
'simulator',<br />
'node',<br />
'internet-node',<br />
'devices/point-to-point', # <---- example here<br />
'applications',<br />
)<br />
</pre><br />
<br />
=== Adding programs ===<br />
Use the special method bld.create_ns3_program(name, [...dependencies...]). Example:<br />
<pre><br />
obj = bld.create_ns3_program('main-simple',<br />
['node', 'internet-node', 'applications'])<br />
obj.source = 'main-simple.cc'<br />
</pre><br />
<br />
== Generating new python bindings ==<br />
<br />
See the [http://www.nsnam.org/wiki/index.php/NS-3_Python_Bindings ns-3 python wiki page].<br />
<br />
== Release Process ==<br />
<br />
[[Release Process]]<br />
<br />
== Mercurial ==<br />
<br />
* Adrian Tam's [http://mercurial.selenic.com/wiki/QuickReferenceCardsAndCheatSheets mercurial cheatsheet]<br />
* [http://wiki.pylonshq.com/display/pylonscookbook/Mercurial+for+Subversion+Users Mercurial for subversion users]<br />
<br />
=== Your .hgrc file ===<br />
<br />
Each mercurial checkin is made by a user. If there is no .hgrc configuration file in the user's home directory, mercurial will default to using the accountname@hostname. This leads to commit lines like the following:<br />
<br />
changeset: 7:e53ac3c458e9<br />
user: tomh@powerbook.local<br />
<br />
To avoid this, and have it print something nicer, like<br />
<br />
changeset: 7:e53ac3c458e9<br />
user: Tom Henderson <tomh@tomh.org><br />
<br />
you need to add an .hgrc file to your home directory, such as follows:<br />
<br />
[ui]<br />
username = Tom Henderson <tomh@tomh.org><br />
<br />
or, for each checkin, you will need to specify the user string manually, such as:<br />
<br />
hg commit -u"Tom Henderson <tomh@tomh.org>" -m"commit message"<br />
<br />
If you want to commit a change on behalf of another user, such as attributing a bug fix to the original author, you can use the above -u command to override what is in your .hgrc file<br />
<br />
== Coding style == <br />
<br />
Of course, you need to follow the ns-3 coding style: http://www.nsnam.org/developers/contributing-code/coding-style/<br />
<br />
=== If you use emacs ===<br />
<br />
All ns-3 files include this:<br />
<pre><br />
/* -*- Mode:C++; c-file-style:"gnu"; indent-tabs-mode:nil; -*- */<br />
</pre><br />
<br />
The "gnu" indentation style mostly conforms to the ns3 coding guidelines, but has a few quirks. One of these is that code after "namespace ns3 {" is indented, while the ns3 coding style says it should not. One workaround is typing the following command for every open buffer:<br />
<pre><br />
C-c C-o innamespace <ret> 0 <ret><br />
</pre><br />
Fixing this issue permanently would require using a different modeline, as discussed [http://www.nabble.com/emacs-indentation-innamespace-td22802271.html in this thread].<br />
<br />
=== If you use VIM ===<br />
<br />
If you use VIM you should add the following lines to your ~/.vimrc:<br />
<pre><br />
set ts=2<br />
set sw=2<br />
set sta<br />
set et<br />
set ai<br />
set si<br />
set cin<br />
</pre><br />
<br />
And the following lines to realize white space errors (trailing white spaces):<br />
<pre><br />
let c_no_bracket_error=1<br />
let c_no_curly_error=1<br />
let c_comment_strings=1<br />
let c_gnu=1<br />
</pre><br />
<br />
== Submitting patches for consideration ==<br />
<br />
The best way to submit a patch for consideration is to request a patch review:<br />
<br />
# download http://codereview.appspot.com/static/upload.py<br />
# record the changes you want to request a review for in a mercurial repository: "hg commit ..."<br />
# within the mercurial repository, run upload.py to submit a review with http://codereview.appspot.com/. Make sure you specify ns-3-reviews@googlegroups.com as a CC.<br />
# paste your review request on http://www.nsnam.org/wiki/index.php/Reviews<br />
# announce your review request on ns-developers<br />
<br />
When you send a tree without a detailed summary of your changes, it would help if you could send a list of the changesets you want to merge. To generate it, first merge with ns-3-dev and then, from your modified directory, run "hg outgoing -p http://code.nsnam.org/ns-3-dev"<br />
<br />
Also, avoid spurious coding style and whitespace changes when preparing such a patch, as it distracts from the readability of your proposed technical changes.<br />
<br />
If you already pulled changes from ns-3-dev into your private repository after you started doing your private modifications, there is an issue to be considered. upload.py does not let you specify a range of revisions, nor a set of changesets. So if you just run upload.py in your private repository, also the changesets pulled from ns-3-dev will be published on codereview, which is of course not desirable.<br />
<br />
A possible workaround is to pull your changes into a temporary repository which is an up-to-date clone of ns-3-dev. The following code should do the trick. This code assumes that your private repository is in path DEV_BRANCH_WITH_NEW_FEATURE, and that it is in sync with ns-3-dev.<br />
<br />
<pre><br />
hg clone http://code.nsnam.org/ns-3-dev ns-3-tmp<br />
cd ns-3-tmp<br />
export REVNO=`hg tip -q | sed 's/:.*$//'`<br />
hg pull DEV_BRANCH_WITH_NEW_FEATURE<br />
hg merge<br />
hg commit -m "merged new feature"<br />
upload.py --rev=$REVNO --cc=ns-3-reviews@googlegroups.com <br />
</pre><br />
<br />
== Checking in code ==<br />
<br />
=== General guidelines ===<br />
<br />
Please always update your code to the tip of ns-3-dev before checking in. Never force a push (which creates another head on the repository). If someone else pushed something before you got a chance to perform your push, you will need to pull those changes, resolve any possible conflicts, and then push. Also don't push with "--new-branch" ([http://mailman.isi.edu/pipermail/ns-developers/2013-May/011169.html the use of ''named branches'' is not allowed]).<br />
<br />
Before checking in code, it is good practice to pull from ns-3-dev and deal with any merge issues in advance:<br />
<br />
cd ns-3-dev<br />
hg pull -u<br />
<br />
Once you think you have code to commit (or after you have done a bunch of small commits), it is good practice to run the test suite:<br />
<br />
./test.py<br />
<br />
Depending on the intrusiveness and nature of your patch, you may want to go further with your testing, including testing debug, optimized, and static versions, and running test.py with the -g option for valgrind.<br />
<br />
When you are ready to push upstream, the command to check in code is:<br />
<br />
hg push ssh://code@code.nsnam.org/repos/ns-3-dev<br />
<br />
If it fails because you forgot to do an update before this step, you will need to:<br />
<br />
hg pull<br />
hg update<br />
hg commit -m "branch merge"<br />
./test.py (make sure you didn't break anything)<br />
hg push ssh://code@code.nsnam.org/repos/ns-3-dev<br />
<br />
If your commit closes a bug in the bugzilla database, please label the commit with the bug number, note the resultant hexidecimal changelog ID, and mark the bug as RESOLVED FIXED and list the changelog ID in the tracker entry. e.g.:<br />
<br />
hg commit -m "bug 1365: unused variable declaration of a private data member"<br />
<br />
=== When to commit ===<br />
<br />
When is it OK to commit code (from a bugzilla patch, or from a code review)?<br />
* If you are the maintainer of an existing module, you can commit changes when you want, as long as you coordinate with the release manager (if it is close to a release or code freeze date).<br />
* If you are not the maintainer, please obtain +1 from the maintainer if the change is not trivial. You may have to remind him or her about it; if you do not get a response, email the release manager.<br />
* If you would like to add a new module, or to commit to a module that does not have a maintainer, it usually should have some review by core maintainers. Email the release manager for help.<br />
* When in doubt, email the release manager.<br />
<br />
=== Checking in patches from other users ===<br />
<br />
If you as a maintainer check in a patch authored by someone else, it is good practice to credit them in the commit message using the --user or -u option to hg; e.g.:<br />
<br />
hg commit -m"...commit message..." -u"A User <a.user@example.com>"<br />
<br />
You can sometimes find the appropriate user string by searching the hg log for their previous commits; e.g.<br />
<br />
hg log | grep <username><br />
<br />
Reference: http://www.gnu.org/prep/maintain/html_node/Recording-Contributors.html<br />
<br />
=== Checking that you don't introduce regressions or leaks ===<br />
<br />
just before you do a checkin you should run the ns-3 tests. Make sure that you have valgrind installed, and change into the top level directory and type<br />
<br />
./test.py --grind<br />
<br />
If you do this, you will see a bunch of passing tests and then, if something goes wrong:<br />
<br />
FAIL: TestSuite test-tcp-large-transfer<br />
<br />
=== Logging your changes in the release notes ===<br />
<br />
The project maintains two files for tracking changes to the codebase. As you check in changes to the code that fix bugs, add features, or change the existing behavior of the simulator, you should also update these files.<br />
<br />
# ''CHANGES.html'': Used to log changes to the build system, new API, changes to existing API, and changed behavior.<br />
# ''RELEASE_NOTES'': Summarize new user-visible features and bugs fixed.<br />
<br />
These files may both be updated, or maybe only one is updated for a given changeset. For instance, if you change the API on a class, you might add a simple bullet "Changed API for class X to improve ability to do Y" to RELEASE_NOTES, but add more detail about exactly which signatures changed in the CHANGES.html file. If the change is trivial (e.g. adding missing Doxygen), there is no need to edit these files. <br />
<br />
Please update these files when you make changes to ns-3-dev rather than relying on the release manager later documenting them.<br />
<br />
=== Fixing a bug from the Bugzilla tracker ===<br />
<br />
Q. What I should do when a bug will be fixed (send a mail to the mailing list, write some comment to bugzilla, other ) ?<br />
<br />
A. The typical thing to do is:<br />
<br />
* check in the bug fix to ns-3-dev with a commit message that indicates the bug number, such as "bug 903: TapBridge doesn't close cleanly"<br />
<br />
* remember what the changeset number is; e.g.<br />
<br />
changeset: 1763:4624d5aba98f<br />
^^^^^^^^^^^^<br />
it is this hexadecimal value<br />
<br />
* mark the bug as "Resolved, Fixed" in Bugzilla, with a comment such as "fixed in changset 4624d5aba98f". Bugzilla will notify the ns-bugs mailing list of the fix, and the ns-commits list will be notified of the checkin.<br />
<br />
== Using gcov and lcov code coverage tools ==<br />
<br />
Here is a brief howto for using the [http://ltp.sourceforge.net/coverage/lcov.php lcov] front-end to gcc's code coverage tool [http://gcc.gnu.org/onlinedocs/gcc/Gcov.html gcov]<br />
<br />
A custom version of lcov and its associated tools (geninfo, genhtml) is stored in the directory utils/lcov/, and this is the version that waf uses to run lcov. As of ns-3.13, the version of lcov in ns-3 is lcov-1.9, with geninfo patched to deal with [http://old.nabble.com/-Ltp-coverage--lcov-hangs-td28514226.html this branching bug]. <br />
<br />
You probably also need to have a version of lcovrc file installed somewhere (either at /etc/lcovrc or ~/.lcovrc). The easiest way to do this is to install lcov from your package manager; e.g.<br />
sudo apt-get install lcov<br />
or install it from source. But just be aware that waf will use the version that is maintained in the utils/lcov/ directory.<br />
<br />
Then, for instance, to see the coverage of the ns-3 test suite, type: <br />
<br />
./waf configure --enable-gcov --enable-examples --enable-tests<br />
./test.py<br />
./waf --lcov-report<br />
<br />
You will find a file "index.html" in the directory build/debug-gcov/lcov-report/ that you can look at with your browser.<br />
<br />
Note that if you want to test coverage of another program, you will want to zero the counters for lcov. You can't presently do this from within waf but you can run this command from your top-level ns-3 directory:<br />
<br />
utils/lcov/lcov --directory build --zerocounters<br />
<br />
and it should report:<br />
<br />
Deleting all .da files in build and subdirectories<br />
Done.<br />
<br />
== The preferred way to create a private repository ==<br />
<br />
Let's say that developer "alice" wants to create a new repository "ns-3-dev-new-feature" that will exist on the code server as alice/ns-3-dev-new-feature. Suppose she wants to fork from the tip of ns-3-dev.<br />
<br />
cd /home/alice/repositories/alice<br />
cp -r /home/code/repos/ns-3-dev ns-3-dev-new-feature<br />
cd ns-3-dev-new-feature/.hg<br />
<br />
At this point, edit the "hgrc" file to provide contact/description information:<br />
<br />
[paths]<br />
default = http://code.nsnam.org/alice/ns-3-dev-new-feature<br />
[web]<br />
description = alice's new feature<br />
contact = <alice@example.com><br />
<br />
Next, check that your repository shows up properly on the [http://code.nsnam.org/?sort=lastchange web page]. <br />
<br />
At this point, you are done with the code server, and you can perform "hg clone http://code.nsnam.org/alice/ns-3-dev-new-feature" on your local machine.<br />
<br />
'''Note:''' A common minor problem is if you do an "hg clone" into the new directory instead of a "cp -r", there will be a huge ns-commits mail message generated. This is why "cp -r" is preferred way to do this.<br />
<br />
== Testing code on nsnam.org hosts ==<br />
Some times a compilation error can only reproduced in certain architectures. nsnam.org has some machines that can be accessed remotely for testing purposes, if you have an appropriate account. Contact Tom Henderson if you need an account.<br />
<br />
=== Full Suite ===<br />
Note that this takes several hours to run. It puts a specified branch through its paces on several machines/architectures. You can specify a branch to test and a notification email address where you will receive a report about how the branch performed in the tests (SUCCESS or FAILURE).<br />
$ ssh ns-regression.ee.washington.edu<br />
$ sudo -u nsnam bash<br />
$ cd /usr/local/bin/<br />
$ ./ns-3-run-tests.sh -h<br />
usage: ./ns-3-run-tests.sh options<br />
<br />
This script runs the ns-3 branch through the ns-regression testbed.<br />
OPTIONS:<br />
-h Help: show this message<br />
-n ns-3 branch Default: ns-3-dev<br />
-m mailto address. Where to send the mail. If unspecified, program output will just scroll onto stdout.<br />
$ ./ns-3-run-tests.sh -n mathieu/ns-3-simu -m someone@wherever.com<br />
<br />
=== Ubuntu x86_64 ===<br />
ssh ns-regression.ee.washington.edu<br />
<br />
=== Mac OS X PowerPC ===<br />
ssh ns-regression.ee.washington.edu<br />
sudo -u nsnam bash<br />
<enter your password><br />
ssh darwin-ppc<br />
<br />
== Adding a buildslave to our BuildBot ==<br />
The ns-3 project uses BuildBot to test the ns-3-dev build daily. The buildmaster resides on a server at the University of Washington. Currently, we use several buildslaves running Fedora Core 10 with different versions of gcc as well as a Mac OS X PPC machine. For a quick snapshot of the current buildslaves in use, please see the buildbot [http://ns-regression.ee.washington.edu:8010/waterfall waterfall].<br />
<br />
If you would like to see another buildslave, for example mingw or cygwin, and you have a machine to donate daily cycles, please complete the following steps:<br />
<br />
# Install buildbot using a package manager or installing from source: [http://buildbot.net/trac/wiki/DownloadInstall download]<br />
# When creating the buildslave, you will need to provide a slavename and password. Note that you will have to send us this name and password. You also need the hostname and port of our buildmaster: ns-regression.ee.washington.edu:9989<br />
# Follow the buildbot manual to setup a buildslave: [http://buildbot.net/buildbot/docs/0.8.1/Creating-a-buildslave.html creating a buildslave]<br />
# Send John Abraham <john.abraham@gatech.edu> an email with your buildslave name and password, and we will update the buildmaster configuration to accept connections from your buildslave.<br />
<br />
To change the buildmaster master script, edit master.cfg and then 'make reconfig' in the /home/buildmaster/master directory.<br />
<br />
To restart buildbot on ns-regression:<br />
su buildmaster<br />
cd /home/buildmaster<br />
/usr/bin/buildbot start master</div>Nicolabaldohttps://www.nsnam.org/mediawiki/index.php?title=Developer_FAQ&diff=7607Developer FAQ2013-05-31T17:39:28Z<p>Nicolabaldo: /* Mercurial tips */</p>
<hr />
<div>{{TOC}}<br />
<br />
== Mercurial repository layout for developers ==<br />
<br />
# In your home dir on code.nsnam.org, you will find a new directory named "<code>repositories/username</code>". e.g.: <code>/home/tomh/repositories/tomh</code>. If you create a repository in this directory, it will appear automatically on http://code.nsnam.org<br />
#* Note: To enable this for new users, edit /var/www/cgi-hg/hgweb.config<br />
# You can obviously ssh to your personal account and manage these repositories<br />
# You can push to these repositories with the command: <code>hg push ssh://tomh@code.nsnam.org/repositories/tomh/ns-3-com</code><br />
# You can pull with the usual commands: <code>hg clone http://code.nsnam.org/tomh/ns-3-com</code><br />
# If you want to allow another user to push into your repository, all you have to do is change the unix permissions of your repository to allow this user write permissions. This means that if you want to give everyone write permissions, you can "<code>chmod -R g +rw /home/tomh/repositories/tomh/ns-3-com/</code>". If you want to allow only a smaller subset of users to push, we will need to create unix group which matches this subset<br />
# The push command for the main tree is still: <code>hg push ssh://code@code.nsnam.org/repos/ns-3-dev</code><br />
# '''New developers, please read this:''' When creating a new repository, do not "hg clone" it into your directory on code.nsnam.org (which will generate a big ns-commits mail message); instead, just copy (cp -r) or rsync it to your local "/home/username/repositories/username" directory.<br />
<br />
=== Mercurial tips ===<br />
<br />
# '''How to undo a commit''': Let's suppose you are working on a private repository and you check something in, but some other files were inadvertently checked in, and you want to revert and start over. There are two ways to do this:<br />
## <code>hg revert</code>: This can be used to revert the repository to a previous revision number. For example, to revert to changeset number #1000, type <code>hg revert -r 1000 --all</code>. This does '''not''' remove your checkin from the repository history. For example, if your mistaken checkin was number 1001, and you revert back to 1000 and then commit, you will be at changeset number 1002 now even though the code matches what was in there at changeset 1000.<br />
## <code>hg rollback</code>: This can be used to completely wipe clean the last transaction only (commit, import, push, pull). Use with care-- cannot be undone. <br />
# '''How to rename a file''': <code>hg rename old-file-name new-file-name</code> This is preferable to adding the new file name and removing the old file name, because it preserves revision history. Don't forget to commit once you are done.<br />
# '''How to merge a branch''': If you have forked a branch repository, have worked on it, and are ready to merge it back to ns-3-dev, here are the steps to take (Also, read [http://hgbook.red-bean.com/hgbookch3.html this chapter] to better understand how the mercurial source tree is structured when merging is occurring):<br />
##''cd into your branch''<br />
##<code>hg pull http://code.nsnam.org/ns-3-dev</code><br />
##<code>hg merge</code><br />
##''resolve all of the merge issues, if any, and confirm that it builds and validates''<br />
##<code>hg ci -m"merge your-branch-name with tip"</code><br />
##<code>hg push ssh://code@code.nsnam.org/repos/ns-3-dev</code><br />
# '''How to create patches for circulation''': <code>hg export tip</code> Suppose you don't have write access to the main repositories, but have some patches you'd like to circulate. This command outputs out all the diffs for the latest changeset you committed into your local repository. Simply redirect this output to a file, and you can circulate your patch for consideration. This is for when you have committed changesets. If you would like to export uncommitted changes as a patch, use: <code>hg diff</code> This gets the diffs of all the uncommitted changes versus what is checked into the repository. Redirect to a file for circulation among developers, or for inclusion with a bug report, etc.<br />
# '''Save a push URL so that you don't need to enter it each time''': If you are tired of having to specify the same ssh URL each time when you go to push, you can specify a default push location in the branch's local hgrc.<br />
##''cd into your branch''<br />
##<code>vi .hg/hgrc</code><br />
##''add the following line to the [paths] section''<br />
##<code>default-push = ssh://username@code.nsnam.org/repositories/username/ns-3-reponame</code><br />
##<code>hg push</code> should now "just work" without the URL<br />
# '''How to fix two-headed repositories''': Note, please never check in code by forcing it (with hg push -f option). This will cause the repository to have multiple heads. If the repository ends up with two heads, this can fix it:<br />
##<code>hg merge</code><br />
##<code>hg commit -m"merge two heads"</code><br />
##<code>hg push ... </code><br />
# '''Don't use named branches''': that is, never do <code>hg branch</code> nor <code>hg push --new-branch</code><br />
<br />
== The WAF build system ==<br />
See also the [http://www.nsnam.org/wiki/index.php/User_FAQ#WAF_.28new_build_process.29 Waf User FAQ].<br />
<br />
=== Obtaining WAF ===<br />
A snapshot of WAF is distributed with ns-3 releases and mercurial branches. This snapshopt has been tested to work correctly with ns-3, although the ''trunk'' version from the main WAF repository usually works equally well.<br />
<br />
=== Documentation resources ===<br />
There is a [http://freehackers.org/~tnagy/wafbook/index.html WAF book]. Some useful tips can be found in the [http://code.google.com/p/waf/w/list WAF Wiki]. Finally, there is a plethora of examples distributed in WAF itself, in the 'demos' directory.<br />
<br />
=== How to add new ns-3 modules ===<br />
<br />
Ns-3 is organized as a set of ''modules''. Each module is built as a set of object files, has a name, may depend on other modules, and installs a specific set of ''public header files''.<br />
<br />
Starting with version 3.11, ns-3 went to a modular directory structure. The following chapter in the ns-3 Manual shows how to add a module in the new directory structure:<br />
<br />
:[http://www.nsnam.org/docs/release/3.13/manual/html/new-modules.html Adding a New Module to ns-3 (version 3.11 or later)]<br />
<br />
If you are using a version of ns-3 earlier than 3.11, then follow the instructions in this FAQ.<br />
<br />
To add a new ns-3 module to the WAF build system, begin by creating a directory under the <code>src/</code> subtree, with the source files inside. We will use ''p2p'' module as example here. Each module needs to define a <code>wscript</code> file. For instance let us see what <code>src/devices/point-to-point/wscript</code> contains:<br />
<pre><br />
## -*- Mode: python; py-indent-offset: 4; indent-tabs-mode: nil; coding: utf-8; -*-<br />
<br />
def build(bld):<br />
module = bld.create_ns3_module('point-to-point', ['node'])<br />
module.source = [<br />
'point-to-point-net-device.cc',<br />
'point-to-point-channel.cc',<br />
'point-to-point-topology.cc',<br />
]<br />
headers = bld.create_obj('ns3header')<br />
headers.module = 'point-to-point'<br />
headers.source = [<br />
'point-to-point-net-device.h',<br />
'point-to-point-channel.h',<br />
'point-to-point-topology.h',<br />
]<br />
</pre><br />
<br />
A wscript file is basically a special python module. The main entry point to this module is the <code>build(bld)</code> python function.<br />
<br />
In the code above, the ''module'' variable represents a ns-3 module; internally it is a WAF 'objects' build object that will be linked to be come part of the ns3 library. It is created by calling a special method bld.create_ns3_module, whose first parameter is the name of the module, and the second parameter is a list of other modules that this module depends on. Additionally, module.sources has to be set to the list of source files (excluding header files) that constitute the module. Warning: beware that the name of the module must match the name of the directory where it is built. In this case, the module is in 'src/devices/point-to-point', so the module name must be 'point-to-point'.<br />
<br />
There is usually also a ''headers'' object. It is used to declare public header files. These files are copied to the build directory, and can be included from any module or program with <code>#include "ns3/header-name.h"</code>.<br />
<br />
A final step, after the wscript file is created, is to register it. Open the file <code>src/wscript</code> and add the new module to the <code>all_modules</code> list variable:<br />
<pre><br />
all_modules = (<br />
'core',<br />
'common',<br />
'simulator',<br />
'node',<br />
'internet-node',<br />
'devices/point-to-point', # <---- example here<br />
'applications',<br />
)<br />
</pre><br />
<br />
=== Adding programs ===<br />
Use the special method bld.create_ns3_program(name, [...dependencies...]). Example:<br />
<pre><br />
obj = bld.create_ns3_program('main-simple',<br />
['node', 'internet-node', 'applications'])<br />
obj.source = 'main-simple.cc'<br />
</pre><br />
<br />
== Generating new python bindings ==<br />
<br />
See the [http://www.nsnam.org/wiki/index.php/NS-3_Python_Bindings ns-3 python wiki page].<br />
<br />
== Release Process ==<br />
<br />
[[Release Process]]<br />
<br />
== Mercurial ==<br />
<br />
* Adrian Tam's [http://mercurial.selenic.com/wiki/QuickReferenceCardsAndCheatSheets mercurial cheatsheet]<br />
* [http://wiki.pylonshq.com/display/pylonscookbook/Mercurial+for+Subversion+Users Mercurial for subversion users]<br />
<br />
=== Your .hgrc file ===<br />
<br />
Each mercurial checkin is made by a user. If there is no .hgrc configuration file in the user's home directory, mercurial will default to using the accountname@hostname. This leads to commit lines like the following:<br />
<br />
changeset: 7:e53ac3c458e9<br />
user: tomh@powerbook.local<br />
<br />
To avoid this, and have it print something nicer, like<br />
<br />
changeset: 7:e53ac3c458e9<br />
user: Tom Henderson <tomh@tomh.org><br />
<br />
you need to add an .hgrc file to your home directory, such as follows:<br />
<br />
[ui]<br />
username = Tom Henderson <tomh@tomh.org><br />
<br />
or, for each checkin, you will need to specify the user string manually, such as:<br />
<br />
hg commit -u"Tom Henderson <tomh@tomh.org>" -m"commit message"<br />
<br />
If you want to commit a change on behalf of another user, such as attributing a bug fix to the original author, you can use the above -u command to override what is in your .hgrc file<br />
<br />
== Coding style == <br />
<br />
Of course, you need to follow the ns-3 coding style: http://www.nsnam.org/developers/contributing-code/coding-style/<br />
<br />
=== If you use emacs ===<br />
<br />
All ns-3 files include this:<br />
<pre><br />
/* -*- Mode:C++; c-file-style:"gnu"; indent-tabs-mode:nil; -*- */<br />
</pre><br />
<br />
The "gnu" indentation style mostly conforms to the ns3 coding guidelines, but has a few quirks. One of these is that code after "namespace ns3 {" is indented, while the ns3 coding style says it should not. One workaround is typing the following command for every open buffer:<br />
<pre><br />
C-c C-o innamespace <ret> 0 <ret><br />
</pre><br />
Fixing this issue permanently would require using a different modeline, as discussed [http://www.nabble.com/emacs-indentation-innamespace-td22802271.html in this thread].<br />
<br />
=== If you use VIM ===<br />
<br />
If you use VIM you should add the following lines to your ~/.vimrc:<br />
<pre><br />
set ts=2<br />
set sw=2<br />
set sta<br />
set et<br />
set ai<br />
set si<br />
set cin<br />
</pre><br />
<br />
And the following lines to realize white space errors (trailing white spaces):<br />
<pre><br />
let c_no_bracket_error=1<br />
let c_no_curly_error=1<br />
let c_comment_strings=1<br />
let c_gnu=1<br />
</pre><br />
<br />
== Submitting patches for consideration ==<br />
<br />
The best way to submit a patch for consideration is to request a patch review:<br />
<br />
# download http://codereview.appspot.com/static/upload.py<br />
# record the changes you want to request a review for in a mercurial repository: "hg commit ..."<br />
# within the mercurial repository, run upload.py to submit a review with http://codereview.appspot.com/. Make sure you specify ns-3-reviews@googlegroups.com as a CC.<br />
# paste your review request on http://www.nsnam.org/wiki/index.php/Reviews<br />
# announce your review request on ns-developers<br />
<br />
When you send a tree without a detailed summary of your changes, it would help if you could send a list of the changesets you want to merge. To generate it, first merge with ns-3-dev and then, from your modified directory, run "hg outgoing -p http://code.nsnam.org/ns-3-dev"<br />
<br />
Also, avoid spurious coding style and whitespace changes when preparing such a patch, as it distracts from the readability of your proposed technical changes.<br />
<br />
If you already pulled changes from ns-3-dev into your private repository after you started doing your private modifications, there is an issue to be considered. upload.py does not let you specify a range of revisions, nor a set of changesets. So if you just run upload.py in your private repository, also the changesets pulled from ns-3-dev will be published on codereview, which is of course not desirable.<br />
<br />
A possible workaround is to pull your changes into a temporary repository which is an up-to-date clone of ns-3-dev. The following code should do the trick. This code assumes that your private repository is in path DEV_BRANCH_WITH_NEW_FEATURE, and that it is in sync with ns-3-dev.<br />
<br />
<pre><br />
hg clone http://code.nsnam.org/ns-3-dev ns-3-tmp<br />
cd ns-3-tmp<br />
export REVNO=`hg tip -q | sed 's/:.*$//'`<br />
hg pull DEV_BRANCH_WITH_NEW_FEATURE<br />
hg merge<br />
hg commit -m "merged new feature"<br />
upload.py --rev=$REVNO --cc=ns-3-reviews@googlegroups.com <br />
</pre><br />
<br />
== Checking in code ==<br />
<br />
=== General guidelines ===<br />
<br />
Please always update your code to the tip of ns-3-dev before checking in. Never force a push (which creates another head on the repository). If someone else pushed something before you got a chance to perform your push, you will need to pull those changes, resolve any possible conflicts, and then push. Also don't push with "--new-branch" ([http://mailman.isi.edu/pipermail/ns-developers/2013-May/011169.html the use of ''named branches'' is not allowed]).<br />
<br />
Before checking in code, it is good practice to pull from ns-3-dev and deal with any merge issues in advance:<br />
<br />
cd ns-3-dev<br />
hg pull -u<br />
<br />
Once you think you have code to commit (or after you have done a bunch of small commits), it is good practice to run the test suite:<br />
<br />
./test.py<br />
<br />
Depending on the intrusiveness and nature of your patch, you may want to go further with your testing, including testing debug, optimized, and static versions, and running test.py with the -g option for valgrind.<br />
<br />
When you are ready to push upstream, the command to check in code is:<br />
<br />
hg push ssh://code@code.nsnam.org/repos/ns-3-dev<br />
<br />
If it fails because you forgot to do an update before this step, you will need to:<br />
<br />
hg pull<br />
hg update<br />
hg commit -m "branch merge"<br />
./test.py (make sure you didn't break anything)<br />
hg push ssh://code@code.nsnam.org/repos/ns-3-dev<br />
<br />
If your commit closes a bug in the bugzilla database, please label the commit with the bug number, note the resultant hexidecimal changelog ID, and mark the bug as RESOLVED FIXED and list the changelog ID in the tracker entry. e.g.:<br />
<br />
hg commit -m "bug 1365: unused variable declaration of a private data member"<br />
<br />
=== When to commit ===<br />
<br />
When is it OK to commit code (from a bugzilla patch, or from a code review)?<br />
* If you are the maintainer of an existing module, you can commit changes when you want, as long as you coordinate with the release manager (if it is close to a release or code freeze date).<br />
* If you are not the maintainer, please obtain +1 from the maintainer if the change is not trivial. You may have to remind him or her about it; if you do not get a response, email the release manager.<br />
* If you would like to add a new module, or to commit to a module that does not have a maintainer, it usually should have some review by core maintainers. Email the release manager for help.<br />
* When in doubt, email the release manager.<br />
<br />
=== Checking in patches from other users ===<br />
<br />
If you as a maintainer check in a patch authored by someone else, it is good practice to credit them in the commit message using the --user or -u option to hg; e.g.:<br />
<br />
hg commit -m"...commit message..." -u"A User <a.user@example.com>"<br />
<br />
You can sometimes find the appropriate user string by searching the hg log for their previous commits; e.g.<br />
<br />
hg log | grep <username><br />
<br />
Reference: http://www.gnu.org/prep/maintain/html_node/Recording-Contributors.html<br />
<br />
=== Checking that you don't introduce regressions or leaks ===<br />
<br />
just before you do a checkin you should run the ns-3 tests. Make sure that you have valgrind installed, and change into the top level directory and type<br />
<br />
./test.py --grind<br />
<br />
If you do this, you will see a bunch of passing tests and then, if something goes wrong:<br />
<br />
FAIL: TestSuite test-tcp-large-transfer<br />
<br />
=== Logging your changes in the release notes ===<br />
<br />
The project maintains two files for tracking changes to the codebase. As you check in changes to the code that fix bugs, add features, or change the existing behavior of the simulator, you should also update these files.<br />
<br />
# ''CHANGES.html'': Used to log changes to the build system, new API, changes to existing API, and changed behavior.<br />
# ''RELEASE_NOTES'': Summarize new user-visible features and bugs fixed.<br />
<br />
These files may both be updated, or maybe only one is updated for a given changeset. For instance, if you change the API on a class, you might add a simple bullet "Changed API for class X to improve ability to do Y" to RELEASE_NOTES, but add more detail about exactly which signatures changed in the CHANGES.html file. If the change is trivial (e.g. adding missing Doxygen), there is no need to edit these files. <br />
<br />
Please update these files when you make changes to ns-3-dev rather than relying on the release manager later documenting them.<br />
<br />
=== Fixing a bug from the Bugzilla tracker ===<br />
<br />
Q. What I should do when a bug will be fixed (send a mail to the mailing list, write some comment to bugzilla, other ) ?<br />
<br />
A. The typical thing to do is:<br />
<br />
* check in the bug fix to ns-3-dev with a commit message that indicates the bug number, such as "bug 903: TapBridge doesn't close cleanly"<br />
<br />
* remember what the changeset number is; e.g.<br />
<br />
changeset: 1763:4624d5aba98f<br />
^^^^^^^^^^^^<br />
it is this hexadecimal value<br />
<br />
* mark the bug as "Resolved, Fixed" in Bugzilla, with a comment such as "fixed in changset 4624d5aba98f". Bugzilla will notify the ns-bugs mailing list of the fix, and the ns-commits list will be notified of the checkin.<br />
<br />
== Using gcov and lcov code coverage tools ==<br />
<br />
Here is a brief howto for using the [http://ltp.sourceforge.net/coverage/lcov.php lcov] front-end to gcc's code coverage tool [http://gcc.gnu.org/onlinedocs/gcc/Gcov.html gcov]<br />
<br />
A custom version of lcov and its associated tools (geninfo, genhtml) is stored in the directory utils/lcov/, and this is the version that waf uses to run lcov. As of ns-3.13, the version of lcov in ns-3 is lcov-1.9, with geninfo patched to deal with [http://old.nabble.com/-Ltp-coverage--lcov-hangs-td28514226.html this branching bug]. <br />
<br />
You probably also need to have a version of lcovrc file installed somewhere (either at /etc/lcovrc or ~/.lcovrc). The easiest way to do this is to install lcov from your package manager; e.g.<br />
sudo apt-get install lcov<br />
or install it from source. But just be aware that waf will use the version that is maintained in the utils/lcov/ directory.<br />
<br />
Then, for instance, to see the coverage of the ns-3 test suite, type: <br />
<br />
./waf configure --enable-gcov --enable-examples --enable-tests<br />
./test.py<br />
./waf --lcov-report<br />
<br />
You will find a file "index.html" in the directory build/debug-gcov/lcov-report/ that you can look at with your browser.<br />
<br />
Note that if you want to test coverage of another program, you will want to zero the counters for lcov. You can't presently do this from within waf but you can run this command from your top-level ns-3 directory:<br />
<br />
utils/lcov/lcov --directory build --zerocounters<br />
<br />
and it should report:<br />
<br />
Deleting all .da files in build and subdirectories<br />
Done.<br />
<br />
== The preferred way to create a private repository ==<br />
<br />
Let's say that developer "alice" wants to create a new repository "ns-3-dev-new-feature" that will exist on the code server as alice/ns-3-dev-new-feature. Suppose she wants to fork from the tip of ns-3-dev.<br />
<br />
cd /home/alice/repositories/alice<br />
cp -r /home/code/repos/ns-3-dev ns-3-dev-new-feature<br />
cd ns-3-dev-new-feature/.hg<br />
<br />
At this point, edit the "hgrc" file to provide contact/description information:<br />
<br />
[paths]<br />
default = http://code.nsnam.org/alice/ns-3-dev-new-feature<br />
[web]<br />
description = alice's new feature<br />
contact = <alice@example.com><br />
<br />
Next, check that your repository shows up properly on the [http://code.nsnam.org/?sort=lastchange web page]. <br />
<br />
At this point, you are done with the code server, and you can perform "hg clone http://code.nsnam.org/alice/ns-3-dev-new-feature" on your local machine.<br />
<br />
'''Note:''' A common minor problem is if you do an "hg clone" into the new directory instead of a "cp -r", there will be a huge ns-commits mail message generated. This is why "cp -r" is preferred way to do this.<br />
<br />
== Testing code on nsnam.org hosts ==<br />
Some times a compilation error can only reproduced in certain architectures. nsnam.org has some machines that can be accessed remotely for testing purposes, if you have an appropriate account. Contact Tom Henderson if you need an account.<br />
<br />
=== Full Suite ===<br />
Note that this takes several hours to run. It puts a specified branch through its paces on several machines/architectures. You can specify a branch to test and a notification email address where you will receive a report about how the branch performed in the tests (SUCCESS or FAILURE).<br />
$ ssh ns-regression.ee.washington.edu<br />
$ sudo -u nsnam bash<br />
$ cd /usr/local/bin/<br />
$ ./ns-3-run-tests.sh -h<br />
usage: ./ns-3-run-tests.sh options<br />
<br />
This script runs the ns-3 branch through the ns-regression testbed.<br />
OPTIONS:<br />
-h Help: show this message<br />
-n ns-3 branch Default: ns-3-dev<br />
-m mailto address. Where to send the mail. If unspecified, program output will just scroll onto stdout.<br />
$ ./ns-3-run-tests.sh -n mathieu/ns-3-simu -m someone@wherever.com<br />
<br />
=== Ubuntu x86_64 ===<br />
ssh ns-regression.ee.washington.edu<br />
<br />
=== Mac OS X PowerPC ===<br />
ssh ns-regression.ee.washington.edu<br />
sudo -u nsnam bash<br />
<enter your password><br />
ssh darwin-ppc<br />
<br />
== Adding a buildslave to our BuildBot ==<br />
The ns-3 project uses BuildBot to test the ns-3-dev build daily. The buildmaster resides on a server at the University of Washington. Currently, we use several buildslaves running Fedora Core 10 with different versions of gcc as well as a Mac OS X PPC machine. For a quick snapshot of the current buildslaves in use, please see the buildbot [http://ns-regression.ee.washington.edu:8010/waterfall waterfall].<br />
<br />
If you would like to see another buildslave, for example mingw or cygwin, and you have a machine to donate daily cycles, please complete the following steps:<br />
<br />
# Install buildbot using a package manager or installing from source: [http://buildbot.net/trac/wiki/DownloadInstall download]<br />
# When creating the buildslave, you will need to provide a slavename and password. Note that you will have to send us this name and password. You also need the hostname and port of our buildmaster: ns-regression.ee.washington.edu:9989<br />
# Follow the buildbot manual to setup a buildslave: [http://buildbot.net/buildbot/docs/0.8.1/Creating-a-buildslave.html creating a buildslave]<br />
# Send John Abraham <john.abraham@gatech.edu> an email with your buildslave name and password, and we will update the buildmaster configuration to accept connections from your buildslave.<br />
<br />
To change the buildmaster master script, edit master.cfg and then 'make reconfig' in the /home/buildmaster/master directory.<br />
<br />
To restart buildbot on ns-regression:<br />
su buildmaster<br />
cd /home/buildmaster<br />
/usr/bin/buildbot start master</div>Nicolabaldohttps://www.nsnam.org/mediawiki/index.php?title=Developer_FAQ&diff=7606Developer FAQ2013-05-31T17:35:47Z<p>Nicolabaldo: /* General guidelines */</p>
<hr />
<div>{{TOC}}<br />
<br />
== Mercurial repository layout for developers ==<br />
<br />
# In your home dir on code.nsnam.org, you will find a new directory named "<code>repositories/username</code>". e.g.: <code>/home/tomh/repositories/tomh</code>. If you create a repository in this directory, it will appear automatically on http://code.nsnam.org<br />
#* Note: To enable this for new users, edit /var/www/cgi-hg/hgweb.config<br />
# You can obviously ssh to your personal account and manage these repositories<br />
# You can push to these repositories with the command: <code>hg push ssh://tomh@code.nsnam.org/repositories/tomh/ns-3-com</code><br />
# You can pull with the usual commands: <code>hg clone http://code.nsnam.org/tomh/ns-3-com</code><br />
# If you want to allow another user to push into your repository, all you have to do is change the unix permissions of your repository to allow this user write permissions. This means that if you want to give everyone write permissions, you can "<code>chmod -R g +rw /home/tomh/repositories/tomh/ns-3-com/</code>". If you want to allow only a smaller subset of users to push, we will need to create unix group which matches this subset<br />
# The push command for the main tree is still: <code>hg push ssh://code@code.nsnam.org/repos/ns-3-dev</code><br />
# '''New developers, please read this:''' When creating a new repository, do not "hg clone" it into your directory on code.nsnam.org (which will generate a big ns-commits mail message); instead, just copy (cp -r) or rsync it to your local "/home/username/repositories/username" directory.<br />
<br />
=== Mercurial tips ===<br />
<br />
# '''How to undo a commit''': Let's suppose you are working on a private repository and you check something in, but some other files were inadvertently checked in, and you want to revert and start over. There are two ways to do this:<br />
## <code>hg revert</code>: This can be used to revert the repository to a previous revision number. For example, to revert to changeset number #1000, type <code>hg revert -r 1000 --all</code>. This does '''not''' remove your checkin from the repository history. For example, if your mistaken checkin was number 1001, and you revert back to 1000 and then commit, you will be at changeset number 1002 now even though the code matches what was in there at changeset 1000.<br />
## <code>hg rollback</code>: This can be used to completely wipe clean the last transaction only (commit, import, push, pull). Use with care-- cannot be undone. <br />
# '''How to rename a file''': <code>hg rename old-file-name new-file-name</code> This is preferable to adding the new file name and removing the old file name, because it preserves revision history. Don't forget to commit once you are done.<br />
# '''How to merge a branch''': If you have forked a branch repository, have worked on it, and are ready to merge it back to ns-3-dev, here are the steps to take (Also, read [http://hgbook.red-bean.com/hgbookch3.html this chapter] to better understand how the mercurial source tree is structured when merging is occurring):<br />
##''cd into your branch''<br />
##<code>hg pull http://code.nsnam.org/ns-3-dev</code><br />
##<code>hg merge</code><br />
##''resolve all of the merge issues, if any, and confirm that it builds and validates''<br />
##<code>hg ci -m"merge your-branch-name with tip"</code><br />
##<code>hg push ssh://code@code.nsnam.org/repos/ns-3-dev</code><br />
# '''How to create patches for circulation''': <code>hg export tip</code> Suppose you don't have write access to the main repositories, but have some patches you'd like to circulate. This command outputs out all the diffs for the latest changeset you committed into your local repository. Simply redirect this output to a file, and you can circulate your patch for consideration. This is for when you have committed changesets. If you would like to export uncommitted changes as a patch, use: <code>hg diff</code> This gets the diffs of all the uncommitted changes versus what is checked into the repository. Redirect to a file for circulation among developers, or for inclusion with a bug report, etc.<br />
# '''Save a push URL so that you don't need to enter it each time''': If you are tired of having to specify the same ssh URL each time when you go to push, you can specify a default push location in the branch's local hgrc.<br />
##''cd into your branch''<br />
##<code>vi .hg/hgrc</code><br />
##''add the following line to the [paths] section''<br />
##<code>default-push = ssh://username@code.nsnam.org/repositories/username/ns-3-reponame</code><br />
##<code>hg push</code> should now "just work" without the URL<br />
# '''How to fix two-headed repositories''': Note, please never check in code by forcing it (with hg push -f option). This will cause the repository to have multiple heads. If the repository ends up with two heads, this can fix it:<br />
##<code>hg merge</code><br />
##<code>hg commit -m"merge two heads"</code><br />
##<code>hg push ... </code><br />
<br />
== The WAF build system ==<br />
See also the [http://www.nsnam.org/wiki/index.php/User_FAQ#WAF_.28new_build_process.29 Waf User FAQ].<br />
<br />
=== Obtaining WAF ===<br />
A snapshot of WAF is distributed with ns-3 releases and mercurial branches. This snapshopt has been tested to work correctly with ns-3, although the ''trunk'' version from the main WAF repository usually works equally well.<br />
<br />
=== Documentation resources ===<br />
There is a [http://freehackers.org/~tnagy/wafbook/index.html WAF book]. Some useful tips can be found in the [http://code.google.com/p/waf/w/list WAF Wiki]. Finally, there is a plethora of examples distributed in WAF itself, in the 'demos' directory.<br />
<br />
=== How to add new ns-3 modules ===<br />
<br />
Ns-3 is organized as a set of ''modules''. Each module is built as a set of object files, has a name, may depend on other modules, and installs a specific set of ''public header files''.<br />
<br />
Starting with version 3.11, ns-3 went to a modular directory structure. The following chapter in the ns-3 Manual shows how to add a module in the new directory structure:<br />
<br />
:[http://www.nsnam.org/docs/release/3.13/manual/html/new-modules.html Adding a New Module to ns-3 (version 3.11 or later)]<br />
<br />
If you are using a version of ns-3 earlier than 3.11, then follow the instructions in this FAQ.<br />
<br />
To add a new ns-3 module to the WAF build system, begin by creating a directory under the <code>src/</code> subtree, with the source files inside. We will use ''p2p'' module as example here. Each module needs to define a <code>wscript</code> file. For instance let us see what <code>src/devices/point-to-point/wscript</code> contains:<br />
<pre><br />
## -*- Mode: python; py-indent-offset: 4; indent-tabs-mode: nil; coding: utf-8; -*-<br />
<br />
def build(bld):<br />
module = bld.create_ns3_module('point-to-point', ['node'])<br />
module.source = [<br />
'point-to-point-net-device.cc',<br />
'point-to-point-channel.cc',<br />
'point-to-point-topology.cc',<br />
]<br />
headers = bld.create_obj('ns3header')<br />
headers.module = 'point-to-point'<br />
headers.source = [<br />
'point-to-point-net-device.h',<br />
'point-to-point-channel.h',<br />
'point-to-point-topology.h',<br />
]<br />
</pre><br />
<br />
A wscript file is basically a special python module. The main entry point to this module is the <code>build(bld)</code> python function.<br />
<br />
In the code above, the ''module'' variable represents a ns-3 module; internally it is a WAF 'objects' build object that will be linked to be come part of the ns3 library. It is created by calling a special method bld.create_ns3_module, whose first parameter is the name of the module, and the second parameter is a list of other modules that this module depends on. Additionally, module.sources has to be set to the list of source files (excluding header files) that constitute the module. Warning: beware that the name of the module must match the name of the directory where it is built. In this case, the module is in 'src/devices/point-to-point', so the module name must be 'point-to-point'.<br />
<br />
There is usually also a ''headers'' object. It is used to declare public header files. These files are copied to the build directory, and can be included from any module or program with <code>#include "ns3/header-name.h"</code>.<br />
<br />
A final step, after the wscript file is created, is to register it. Open the file <code>src/wscript</code> and add the new module to the <code>all_modules</code> list variable:<br />
<pre><br />
all_modules = (<br />
'core',<br />
'common',<br />
'simulator',<br />
'node',<br />
'internet-node',<br />
'devices/point-to-point', # <---- example here<br />
'applications',<br />
)<br />
</pre><br />
<br />
=== Adding programs ===<br />
Use the special method bld.create_ns3_program(name, [...dependencies...]). Example:<br />
<pre><br />
obj = bld.create_ns3_program('main-simple',<br />
['node', 'internet-node', 'applications'])<br />
obj.source = 'main-simple.cc'<br />
</pre><br />
<br />
== Generating new python bindings ==<br />
<br />
See the [http://www.nsnam.org/wiki/index.php/NS-3_Python_Bindings ns-3 python wiki page].<br />
<br />
== Release Process ==<br />
<br />
[[Release Process]]<br />
<br />
== Mercurial ==<br />
<br />
* Adrian Tam's [http://mercurial.selenic.com/wiki/QuickReferenceCardsAndCheatSheets mercurial cheatsheet]<br />
* [http://wiki.pylonshq.com/display/pylonscookbook/Mercurial+for+Subversion+Users Mercurial for subversion users]<br />
<br />
=== Your .hgrc file ===<br />
<br />
Each mercurial checkin is made by a user. If there is no .hgrc configuration file in the user's home directory, mercurial will default to using the accountname@hostname. This leads to commit lines like the following:<br />
<br />
changeset: 7:e53ac3c458e9<br />
user: tomh@powerbook.local<br />
<br />
To avoid this, and have it print something nicer, like<br />
<br />
changeset: 7:e53ac3c458e9<br />
user: Tom Henderson <tomh@tomh.org><br />
<br />
you need to add an .hgrc file to your home directory, such as follows:<br />
<br />
[ui]<br />
username = Tom Henderson <tomh@tomh.org><br />
<br />
or, for each checkin, you will need to specify the user string manually, such as:<br />
<br />
hg commit -u"Tom Henderson <tomh@tomh.org>" -m"commit message"<br />
<br />
If you want to commit a change on behalf of another user, such as attributing a bug fix to the original author, you can use the above -u command to override what is in your .hgrc file<br />
<br />
== Coding style == <br />
<br />
Of course, you need to follow the ns-3 coding style: http://www.nsnam.org/developers/contributing-code/coding-style/<br />
<br />
=== If you use emacs ===<br />
<br />
All ns-3 files include this:<br />
<pre><br />
/* -*- Mode:C++; c-file-style:"gnu"; indent-tabs-mode:nil; -*- */<br />
</pre><br />
<br />
The "gnu" indentation style mostly conforms to the ns3 coding guidelines, but has a few quirks. One of these is that code after "namespace ns3 {" is indented, while the ns3 coding style says it should not. One workaround is typing the following command for every open buffer:<br />
<pre><br />
C-c C-o innamespace <ret> 0 <ret><br />
</pre><br />
Fixing this issue permanently would require using a different modeline, as discussed [http://www.nabble.com/emacs-indentation-innamespace-td22802271.html in this thread].<br />
<br />
=== If you use VIM ===<br />
<br />
If you use VIM you should add the following lines to your ~/.vimrc:<br />
<pre><br />
set ts=2<br />
set sw=2<br />
set sta<br />
set et<br />
set ai<br />
set si<br />
set cin<br />
</pre><br />
<br />
And the following lines to realize white space errors (trailing white spaces):<br />
<pre><br />
let c_no_bracket_error=1<br />
let c_no_curly_error=1<br />
let c_comment_strings=1<br />
let c_gnu=1<br />
</pre><br />
<br />
== Submitting patches for consideration ==<br />
<br />
The best way to submit a patch for consideration is to request a patch review:<br />
<br />
# download http://codereview.appspot.com/static/upload.py<br />
# record the changes you want to request a review for in a mercurial repository: "hg commit ..."<br />
# within the mercurial repository, run upload.py to submit a review with http://codereview.appspot.com/. Make sure you specify ns-3-reviews@googlegroups.com as a CC.<br />
# paste your review request on http://www.nsnam.org/wiki/index.php/Reviews<br />
# announce your review request on ns-developers<br />
<br />
When you send a tree without a detailed summary of your changes, it would help if you could send a list of the changesets you want to merge. To generate it, first merge with ns-3-dev and then, from your modified directory, run "hg outgoing -p http://code.nsnam.org/ns-3-dev"<br />
<br />
Also, avoid spurious coding style and whitespace changes when preparing such a patch, as it distracts from the readability of your proposed technical changes.<br />
<br />
If you already pulled changes from ns-3-dev into your private repository after you started doing your private modifications, there is an issue to be considered. upload.py does not let you specify a range of revisions, nor a set of changesets. So if you just run upload.py in your private repository, also the changesets pulled from ns-3-dev will be published on codereview, which is of course not desirable.<br />
<br />
A possible workaround is to pull your changes into a temporary repository which is an up-to-date clone of ns-3-dev. The following code should do the trick. This code assumes that your private repository is in path DEV_BRANCH_WITH_NEW_FEATURE, and that it is in sync with ns-3-dev.<br />
<br />
<pre><br />
hg clone http://code.nsnam.org/ns-3-dev ns-3-tmp<br />
cd ns-3-tmp<br />
export REVNO=`hg tip -q | sed 's/:.*$//'`<br />
hg pull DEV_BRANCH_WITH_NEW_FEATURE<br />
hg merge<br />
hg commit -m "merged new feature"<br />
upload.py --rev=$REVNO --cc=ns-3-reviews@googlegroups.com <br />
</pre><br />
<br />
== Checking in code ==<br />
<br />
=== General guidelines ===<br />
<br />
Please always update your code to the tip of ns-3-dev before checking in. Never force a push (which creates another head on the repository). If someone else pushed something before you got a chance to perform your push, you will need to pull those changes, resolve any possible conflicts, and then push. Also don't push with "--new-branch" ([http://mailman.isi.edu/pipermail/ns-developers/2013-May/011169.html the use of ''named branches'' is not allowed]).<br />
<br />
Before checking in code, it is good practice to pull from ns-3-dev and deal with any merge issues in advance:<br />
<br />
cd ns-3-dev<br />
hg pull -u<br />
<br />
Once you think you have code to commit (or after you have done a bunch of small commits), it is good practice to run the test suite:<br />
<br />
./test.py<br />
<br />
Depending on the intrusiveness and nature of your patch, you may want to go further with your testing, including testing debug, optimized, and static versions, and running test.py with the -g option for valgrind.<br />
<br />
When you are ready to push upstream, the command to check in code is:<br />
<br />
hg push ssh://code@code.nsnam.org/repos/ns-3-dev<br />
<br />
If it fails because you forgot to do an update before this step, you will need to:<br />
<br />
hg pull<br />
hg update<br />
hg commit -m "branch merge"<br />
./test.py (make sure you didn't break anything)<br />
hg push ssh://code@code.nsnam.org/repos/ns-3-dev<br />
<br />
If your commit closes a bug in the bugzilla database, please label the commit with the bug number, note the resultant hexidecimal changelog ID, and mark the bug as RESOLVED FIXED and list the changelog ID in the tracker entry. e.g.:<br />
<br />
hg commit -m "bug 1365: unused variable declaration of a private data member"<br />
<br />
=== When to commit ===<br />
<br />
When is it OK to commit code (from a bugzilla patch, or from a code review)?<br />
* If you are the maintainer of an existing module, you can commit changes when you want, as long as you coordinate with the release manager (if it is close to a release or code freeze date).<br />
* If you are not the maintainer, please obtain +1 from the maintainer if the change is not trivial. You may have to remind him or her about it; if you do not get a response, email the release manager.<br />
* If you would like to add a new module, or to commit to a module that does not have a maintainer, it usually should have some review by core maintainers. Email the release manager for help.<br />
* When in doubt, email the release manager.<br />
<br />
=== Checking in patches from other users ===<br />
<br />
If you as a maintainer check in a patch authored by someone else, it is good practice to credit them in the commit message using the --user or -u option to hg; e.g.:<br />
<br />
hg commit -m"...commit message..." -u"A User <a.user@example.com>"<br />
<br />
You can sometimes find the appropriate user string by searching the hg log for their previous commits; e.g.<br />
<br />
hg log | grep <username><br />
<br />
Reference: http://www.gnu.org/prep/maintain/html_node/Recording-Contributors.html<br />
<br />
=== Checking that you don't introduce regressions or leaks ===<br />
<br />
just before you do a checkin you should run the ns-3 tests. Make sure that you have valgrind installed, and change into the top level directory and type<br />
<br />
./test.py --grind<br />
<br />
If you do this, you will see a bunch of passing tests and then, if something goes wrong:<br />
<br />
FAIL: TestSuite test-tcp-large-transfer<br />
<br />
=== Logging your changes in the release notes ===<br />
<br />
The project maintains two files for tracking changes to the codebase. As you check in changes to the code that fix bugs, add features, or change the existing behavior of the simulator, you should also update these files.<br />
<br />
# ''CHANGES.html'': Used to log changes to the build system, new API, changes to existing API, and changed behavior.<br />
# ''RELEASE_NOTES'': Summarize new user-visible features and bugs fixed.<br />
<br />
These files may both be updated, or maybe only one is updated for a given changeset. For instance, if you change the API on a class, you might add a simple bullet "Changed API for class X to improve ability to do Y" to RELEASE_NOTES, but add more detail about exactly which signatures changed in the CHANGES.html file. If the change is trivial (e.g. adding missing Doxygen), there is no need to edit these files. <br />
<br />
Please update these files when you make changes to ns-3-dev rather than relying on the release manager later documenting them.<br />
<br />
=== Fixing a bug from the Bugzilla tracker ===<br />
<br />
Q. What I should do when a bug will be fixed (send a mail to the mailing list, write some comment to bugzilla, other ) ?<br />
<br />
A. The typical thing to do is:<br />
<br />
* check in the bug fix to ns-3-dev with a commit message that indicates the bug number, such as "bug 903: TapBridge doesn't close cleanly"<br />
<br />
* remember what the changeset number is; e.g.<br />
<br />
changeset: 1763:4624d5aba98f<br />
^^^^^^^^^^^^<br />
it is this hexadecimal value<br />
<br />
* mark the bug as "Resolved, Fixed" in Bugzilla, with a comment such as "fixed in changset 4624d5aba98f". Bugzilla will notify the ns-bugs mailing list of the fix, and the ns-commits list will be notified of the checkin.<br />
<br />
== Using gcov and lcov code coverage tools ==<br />
<br />
Here is a brief howto for using the [http://ltp.sourceforge.net/coverage/lcov.php lcov] front-end to gcc's code coverage tool [http://gcc.gnu.org/onlinedocs/gcc/Gcov.html gcov]<br />
<br />
A custom version of lcov and its associated tools (geninfo, genhtml) is stored in the directory utils/lcov/, and this is the version that waf uses to run lcov. As of ns-3.13, the version of lcov in ns-3 is lcov-1.9, with geninfo patched to deal with [http://old.nabble.com/-Ltp-coverage--lcov-hangs-td28514226.html this branching bug]. <br />
<br />
You probably also need to have a version of lcovrc file installed somewhere (either at /etc/lcovrc or ~/.lcovrc). The easiest way to do this is to install lcov from your package manager; e.g.<br />
sudo apt-get install lcov<br />
or install it from source. But just be aware that waf will use the version that is maintained in the utils/lcov/ directory.<br />
<br />
Then, for instance, to see the coverage of the ns-3 test suite, type: <br />
<br />
./waf configure --enable-gcov --enable-examples --enable-tests<br />
./test.py<br />
./waf --lcov-report<br />
<br />
You will find a file "index.html" in the directory build/debug-gcov/lcov-report/ that you can look at with your browser.<br />
<br />
Note that if you want to test coverage of another program, you will want to zero the counters for lcov. You can't presently do this from within waf but you can run this command from your top-level ns-3 directory:<br />
<br />
utils/lcov/lcov --directory build --zerocounters<br />
<br />
and it should report:<br />
<br />
Deleting all .da files in build and subdirectories<br />
Done.<br />
<br />
== The preferred way to create a private repository ==<br />
<br />
Let's say that developer "alice" wants to create a new repository "ns-3-dev-new-feature" that will exist on the code server as alice/ns-3-dev-new-feature. Suppose she wants to fork from the tip of ns-3-dev.<br />
<br />
cd /home/alice/repositories/alice<br />
cp -r /home/code/repos/ns-3-dev ns-3-dev-new-feature<br />
cd ns-3-dev-new-feature/.hg<br />
<br />
At this point, edit the "hgrc" file to provide contact/description information:<br />
<br />
[paths]<br />
default = http://code.nsnam.org/alice/ns-3-dev-new-feature<br />
[web]<br />
description = alice's new feature<br />
contact = <alice@example.com><br />
<br />
Next, check that your repository shows up properly on the [http://code.nsnam.org/?sort=lastchange web page]. <br />
<br />
At this point, you are done with the code server, and you can perform "hg clone http://code.nsnam.org/alice/ns-3-dev-new-feature" on your local machine.<br />
<br />
'''Note:''' A common minor problem is if you do an "hg clone" into the new directory instead of a "cp -r", there will be a huge ns-commits mail message generated. This is why "cp -r" is preferred way to do this.<br />
<br />
== Testing code on nsnam.org hosts ==<br />
Some times a compilation error can only reproduced in certain architectures. nsnam.org has some machines that can be accessed remotely for testing purposes, if you have an appropriate account. Contact Tom Henderson if you need an account.<br />
<br />
=== Full Suite ===<br />
Note that this takes several hours to run. It puts a specified branch through its paces on several machines/architectures. You can specify a branch to test and a notification email address where you will receive a report about how the branch performed in the tests (SUCCESS or FAILURE).<br />
$ ssh ns-regression.ee.washington.edu<br />
$ sudo -u nsnam bash<br />
$ cd /usr/local/bin/<br />
$ ./ns-3-run-tests.sh -h<br />
usage: ./ns-3-run-tests.sh options<br />
<br />
This script runs the ns-3 branch through the ns-regression testbed.<br />
OPTIONS:<br />
-h Help: show this message<br />
-n ns-3 branch Default: ns-3-dev<br />
-m mailto address. Where to send the mail. If unspecified, program output will just scroll onto stdout.<br />
$ ./ns-3-run-tests.sh -n mathieu/ns-3-simu -m someone@wherever.com<br />
<br />
=== Ubuntu x86_64 ===<br />
ssh ns-regression.ee.washington.edu<br />
<br />
=== Mac OS X PowerPC ===<br />
ssh ns-regression.ee.washington.edu<br />
sudo -u nsnam bash<br />
<enter your password><br />
ssh darwin-ppc<br />
<br />
== Adding a buildslave to our BuildBot ==<br />
The ns-3 project uses BuildBot to test the ns-3-dev build daily. The buildmaster resides on a server at the University of Washington. Currently, we use several buildslaves running Fedora Core 10 with different versions of gcc as well as a Mac OS X PPC machine. For a quick snapshot of the current buildslaves in use, please see the buildbot [http://ns-regression.ee.washington.edu:8010/waterfall waterfall].<br />
<br />
If you would like to see another buildslave, for example mingw or cygwin, and you have a machine to donate daily cycles, please complete the following steps:<br />
<br />
# Install buildbot using a package manager or installing from source: [http://buildbot.net/trac/wiki/DownloadInstall download]<br />
# When creating the buildslave, you will need to provide a slavename and password. Note that you will have to send us this name and password. You also need the hostname and port of our buildmaster: ns-regression.ee.washington.edu:9989<br />
# Follow the buildbot manual to setup a buildslave: [http://buildbot.net/buildbot/docs/0.8.1/Creating-a-buildslave.html creating a buildslave]<br />
# Send John Abraham <john.abraham@gatech.edu> an email with your buildslave name and password, and we will update the buildmaster configuration to accept connections from your buildslave.<br />
<br />
To change the buildmaster master script, edit master.cfg and then 'make reconfig' in the /home/buildmaster/master directory.<br />
<br />
To restart buildbot on ns-regression:<br />
su buildmaster<br />
cd /home/buildmaster<br />
/usr/bin/buildbot start master</div>Nicolabaldohttps://www.nsnam.org/mediawiki/index.php?title=GSOC2013Projects&diff=7544GSOC2013Projects2013-04-16T09:02:54Z<p>Nicolabaldo: /* Extension Of The LTE HO Algorithm And UE Measurements Support */</p>
<hr />
<div>{{TOC}}<br />
<br />
* [http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2012/faqs GSoC Frequently Asked Questions]<br />
* [http://en.flossmanuals.net/gsocmentoring/ GSoC Mentor guide]<br />
* [http://en.flossmanuals.net/GSoCStudentGuide/ GSoC student guide]<br />
* [[GSOC2013StudentGuide |ns-3's GSoC Student guide]]<br />
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br />
* [[GSOCSelectionProcess | GSoC Student Selection Process]]<br />
* [[GSOC2013PatchRequirement | Patch Requirement Guidelines]]<br />
* [[GSOC2013StudentApplicationTemplate |GSoC Student application template]]<br />
* [[GSOC2012Projects |GSoC 2012 page]] | [[GSOC2012AcceptedProjects |GSoC 2012 Accepted Projects]]<br />
* [[GSOC2011Projects |NSoC 2011 Ideas page]] | [[NSOC2011AcceptedProjects |NSoC 2011 Accepted Projects]]<br />
* [[GSOC2010Projects |GSoC 2010 Ideas page]] | [[GSOC2010AcceptedProjects |GSoC 2010 Accepted Projects]]<br />
* [[GSOC2009Projects |GSoC 2009 Ideas page]] | [[GSOC2009AcceptedProjects |GSoC 2009 Accepted Projects]]<br />
* [[GSOC2010OAReport |GSoC Organization Administrator guide]]<br />
* ''Get in contact with the ns-3 team'': [http://mailman.isi.edu/mailman/listinfo/ns-developers ns-developers mailing list] | ''IRC'' #ns-3 on freenode.net<br />
<br />
= GSoC 2013 Ideas =<br />
<br />
This webpage highlights project ideas for ns-3's Google Summer of Code 2013 effort.<br />
<br />
GSOC 2013 Timeline is:<br />
* March 18 - 19:00 UTC: Mentoring organizations can begin submitting applications to Google.<br />
* March 29 - 19:00 UTC: Mentoring organization application deadline.<br />
* April 8 - 19:00 UTC: List of accepted mentoring organizations published on the Google Summer of Code 2013 site.<br />
* April 9-21: Would-be student participants discuss application ideas with mentoring organizations.<br />
* April 22 - 19:00 UTC: Student application period opens.<br />
* May 3 - 19:00 UTC: Student application deadline.<br />
Full timeline is here: http://www.google-melange.com/gsoc/events/google/gsoc2013<br />
<br />
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. <br />
<br />
== About the ns-3 project ==<br />
<br />
ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Our GSoC organizational admin is [mailto:suresh.lalith@gmail.com Lalith Suresh] and our backup org admin is [mailto:tomhend@u.washington.edu Tom Henderson]. The project has participated in past GSoCs during 2008-10 and 2012.<br />
<br />
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.<br />
<br />
== ns-3 and other GSoC mentoring organisations ==<br />
<br />
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.<br />
<br />
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.<br />
<br />
== Getting started ==<br />
<br />
For students interested in applying to ns-3 for GSOC, go through the following list to get started:<br />
* Read the official [http://en.flossmanuals.net/GSoCStudentGuide/ GSoC student guide].<br />
* Read [[GSOC2013StudentGuide |ns-3's GSoC Student guide]].<br />
* Look through our ideas list below to see if you find a project that interests you.<br />
* Review the [http://www.nsnam.org/ns-3-16/documentation/ ns-3 tutorial] thoroughly, if you have not already done so.<br />
* Look through the [[GSOC2013StudentApplicationTemplate |GSoC Student application template]] to start preparing your proposal.<br />
* Next, proceed to get in touch with the developers on the mailing list and refine your proposal.<br />
* In parallel, make sure you prepare a patch as per the [[GSOC2013PatchRequirement | Patch Requirement Guidelines]]. Your application to ns-3 will not be considered if you do not fulfill this requirement.<br />
<br />
== Project Ideas ==<br />
<br />
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 [http://mailman.isi.edu/mailman/listinfo/ns-developers 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 [http://mailman.isi.edu/mailman/listinfo/ns-developers 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.<br />
<br />
<blockquote><br />
Each project idea within a particular priority has been tagged with the following properties:<br />
* ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br />
* ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br />
* ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful students might apply their experiences coming out of this project.<br />
* ''Difficulty:'' easy, medium or difficult<br />
* ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br />
<br />
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.<br />
</blockquote><br />
<br />
= Guidelines for project ideas =<br />
<br />
For mentors who're adding project ideas to the list below, please ensure that:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
= Project Ideas =<br />
<br />
=== Vehicular Ad-hoc Networks ===<br />
<br />
Mentors: [mailto:guillaume.remy@ieee.org Guillaume Rémy]<br />
<br />
* '''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:<br />
# 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.<br />
# 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)<br />
# higher layers: nothing specific to WAVE is currently available.<br />
# 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).<br />
** ''Required experience:'' C++.<br />
** ''Bonus experience:'' Wireless networking, WAVE.<br />
** ''Interests:'' Wireless networking, VANETs.<br />
** ''Difficulty:'' medium to hard, depending on what the student proposes to implement.<br />
** ''Recommended reading''<br />
*** [0] http://www.nsnam.org/bugzilla/show_bug.cgi?id=700#c11<br />
*** [1] http://www.nsnam.org/bugzilla/show_bug.cgi?id=945<br />
*** [2] http://www.nsnam.org/bugzilla/show_bug.cgi?id=978#c16<br />
*** [3] http://www.nsnam.org/bugzilla/attachment.cgi?id=968<br />
*** [4] http://dsn.tm.kit.edu/english/ns3-physim.php<br />
<br />
<br />
=== 802.15.4 Energy Model ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br />
<br />
* '''802.15.4 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. Hence it is not possible to simulate correctly the energy discharge of a Wireless Sensor Node correctly. The goal is to develop the missing classes needed to link the two modules, and to validate the results against the literature models.<br />
** ''Required Experience:'' C++, WSN<br />
** ''Bonus Experience:'' ns-3 Energy model<br />
** ''Interests:'' WSN, Battery discharge<br />
** ''Difficulty:'' easy<br />
** ''Recommended reading:''<br />
*** [http://www.sics.se/~adam/dunkels07softwarebased.pdf Software-based On-line Energy Estimation for Sensor Nodes] <br />
*** [http://cds.unibe.ch/research/pub_files/HBNH11.pdf On the Accuracy of Software-based Energy Estimation Techniques]<br />
*** [http://dunkels.com/adam/dunkels11contikimac.pdf The ContikiMAC Radio Duty Cycling Protocol]<br />
<br />
=== 802.15.4 Bootstrap ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br />
<br />
* '''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.<br />
** ''Required Experience:'' C++, WSN<br />
** ''Bonus Experience:'' 802.15.4 standard<br />
** ''Interests:'' WSN<br />
** ''Difficulty:'' medium<br />
** ''Recommended reading:''<br />
*** [http://standards.ieee.org/getieee802/download/802.15.4-2011.pdf 802.15.4 Standard]<br />
<br />
<br />
<br />
=== 802.15.4 Beacon-enabled mode ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br />
<br />
* '''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. <br />
** ''Required Experience:'' C++, WSN<br />
** ''Bonus Experience:'' 802.15.4 standard<br />
** ''Interests:'' WSN<br />
** ''Difficulty:'' medium/hard<br />
** ''Recommended reading:''<br />
*** [http://standards.ieee.org/getieee802/download/802.15.4-2011.pdf 802.15.4 Standard]<br />
<br />
<br />
=== Simulating the Internet of Things in NS-3 === <br />
Mentors: [mailto:peter.kourzanov@gmail.com Peter Kourzanov], [mailto:hong.r.li@nxp.com Hong.R. Li]<br />
<br />
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.<br />
** ''Required experience'' : C++<br />
** ''Bonus experience'' : NS-2, WSN, Matlab<br />
** ''Interests'' : ZB, embedded, wireless, sensor networks<br />
** ''Difficulty'' : medium<br />
** ''Recommended reading'' :<br />
**# LR-WPAN [http://www.nsnam.org/wiki/index.php/Lr-wpan status page]<br />
**# LR-WPAN [http://code.nsnam.org/tomh/ns-3-lr-wpan/file/735b14afde8e/lr-wpan-documentation.pdf model-library document]<br />
**# Preliminary LR-WPAN [http://code.nsnam.org/tomh/ns-3-lr-wpan code] for NS-3<br />
**# Preliminary IPv6 over Low-power WPAN (6LoWPAN) [http://code.nsnam.org/tpecorella/ns-3-6LoWPAN code] for NS-3<br />
**# Mature [http://cint.ccny.cuny.edu/awnl/Software implementation] of ZB 2003 in [http://www.isi.edu/nsnam/ns NS-2] (included in version 2.35)<br />
**#* original [http://cint.ccny.cuny.edu/awnl/Software/WPAN_ZBR_pub.pdf presentation] from CUNY<br />
**#* adaptation and bug-fixes from [http://www.ee.washington.edu/research/funlab/802_15_4 Funlab]<br />
**# [http://en.wikipedia.org/wiki/IEEE_802.15.4 LR-WPAN] page on Wikipedia<br />
**# [http://en.wikipedia.org/wiki/ZigBee ZB] page on Wikipedia<br />
<br />
<br />
=== Neighbor Discovery Optimization for Low Power and Lossy Networks (6LoWPAN-nd) ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br />
<br />
* '''6LoWPAN-nd implementation and testing:''' [http://tools.ietf.org/html/draft-ietf-6lowpan-nd-18 6LoWPAN-nd] is novel draft protocol from IETF's [http://tools.ietf.org/wg/6lowpan/ 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. <br />
** ''Required Experience:'' C++, IPv6, RPL<br />
** ''Bonus Experience:'' WSN networking<br />
** ''Interests:'' WSN, IPv6, node bootstrap, efficient packet compression <br />
** ''Difficulty:'' hard<br />
** ''Recommended reading:''<br />
*** [http://tools.ietf.org/html/rfc4919 RFC 4919] IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals<br />
*** [http://tools.ietf.org/html/draft-ietf-6lowpan-nd-18 6LoWPAN-nd] Neighbor Discovery Optimization for Low Power and Lossy Networks<br />
<br />
<br />
=== RPL protocol Metric and Constraints ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br />
<br />
* '''RPL protocol Metric and Constraints:''' The [http://tools.ietf.org/wg/roll/ 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.).<br />
** ''Required Experience:'' C++, IPv6,<br />
** ''Bonus Experience:'' RPL protocol<br />
** ''Interests:'' WSN, routing <br />
** ''Difficulty:'' medium<br />
** ''Recommended reading:''<br />
*** [http://tools.ietf.org/html/rfc6550 RFC 6550] RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks<br />
*** [http://tools.ietf.org/html/rfc6551 RFC 6551] Routing Metrics Used for Path alculation in Low-Power and Lossy Networks<br />
<br />
<br />
=== IPv6 stack validation and improvements ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br />
<br />
* '''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):<br />
*# There is no [http://en.wikipedia.org/wiki/Path_MTU_discovery path MTU discovery] see also [http://tools.ietf.org/html/rfc1981 RFC 1981].<br />
*# Flow Monitor module does not work on the IPv6 stack<br />
*# FlowLabel header field is not currenly used<br />
*# IPSec is not supported<br />
* 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.<br />
** ''Required Experience:'' C++, TCP/IP networking<br />
** ''Bonus Experience:'' IPv6 protocols<br />
** ''Interests:'' IPv6 internetworking<br />
** ''Difficulty:'' easy / medium, depending on the features implemented<br />
** ''Recommended reading:''<br />
*** [http://www.ietf.org/rfc/rfc4294.txt RFC 4294 - IPv6 Node Requirements]<br />
*** [http://tools.ietf.org/html/rfc1981 RFC 1981 - Path MTU Discovery for IP version 6]<br />
*** ns-3 Flowmon module documentation<br />
*** [http://tools.ietf.org/html/rfc6437 RFC 6437 - IPv6 Flow Label Specification]<br />
*** [http://tools.ietf.org/html/rfc4302 RFC 4302 - IP Authentication Header]<br />
*** [http://tools.ietf.org/html/rfc4303 RFC 4303 - IP Encapsulating Security Payload (ESP)]<br />
<br />
<br />
=== Multicast IPv6 traffic support ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br />
<br />
* '''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.<br />
** ''Required Experience:'' C++, IPv6,<br />
** ''Bonus Experience:'' Multicast routing protocols (MLDv2/IGMPv3 and PIM)<br />
** ''Interests:'' routing, multicast<br />
** ''Difficulty:'' medium/hard<br />
** ''Recommended reading:''<br />
*** [http://www.h3c.com/portal/Products___Solutions/Products/Switches/H3C_S5500-SI_Series_Switches/White_Paper/200806/688942_57_0.htm Multicast Technology White Paper]<br />
*** [http://www.alliedtelesis.co.nz/documentation/at9800/291/pdf/ipv6mu.pdf IPv6 Multicasting]<br />
*** All the relevant RFCs (search in [http://www.rfc-editor.org/search/rfc_search.php RFC Editor search engine])<br />
<br />
<br />
=== High performance ns-3 emulation with Direct NIC Access ===<br />
<br />
Mentors: [mailto:jose.nunez@cttc.cat José Nuñez]<br />
<br />
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. <br />
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.<br />
* ''Required Experience:'' C++, Linux <br />
* ''Interests:'' network performance, emulation<br />
* ''Difficulty:'' hard<br />
* ''Recommended reading:''<br />
** http://www.ntop.org/products/pf_ring/libzero-for-dna/<br />
<br />
<br />
=== LTE Idle Mode Procedures ===<br />
<br />
Mentors: [mailto:jaime.ferragut@cttc.es Jaime Ferragut] [mailto:nicola.baldo@cttc.es Nicola Baldo]<br />
<br />
* 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.<br />
* ''Required Experience:'' C++, LTE<br />
* ''Interests:'' mobility management<br />
* ''Difficulty:'' medium/hard<br />
* ''Recommended reading:''<br />
** 3GPP TS 36.300 "E-UTRA and E-UTRAN overall description", section 10.1.1 "Mobility Management in ECM-IDLE"<br />
** 3GPP TS 36.304 "User Equipment (UE) procedures in idle mode"<br />
** 3GPP TS 24.301 "Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS)"<br />
<br />
<br />
=== Decouple traffic generators from sockets ===<br />
<br />
Mentors: [mailto:tomh@tomh.org Tom Henderson] [mailto:rivanvx@gmail.com Vedran Miletić]<br />
<br />
* 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.<br />
* ''Required Experience:'' C++, sockets API<br />
* ''Interests:'' <br />
* ''Difficulty:'' easy/medium<br />
* ''Recommended reading:''<br />
** Unix Network Programming (Stevens) or equivalent<br />
<br />
<br />
=== ARP and NDisc cache visibility ===<br />
<br />
Mentors: [mailto:tomh@tomh.org Tom Henderson] [mailto:rivanvx@gmail.com Vedran Miletić]<br />
<br />
* 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).<br />
* ''Required Experience:'' C++<br />
* ''Interests:'' IPv4 and Ipv6<br />
* ''Difficulty:'' easy/medium<br />
* ''Recommended reading:''<br />
** source code in src/internet, and the bugs mentioned above<br />
<br />
<br />
=== INSTOOLS for ns-3 ===<br />
<br />
Mentors: [mailto:tomh@tomh.org Tom Henderson]<br />
<br />
'''INSTOOLS for ns-3:''' [http://groups.geni.net/geni/wiki/InstrumentationTools 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.<br />
* ''Required Experience:'' Familiarity with Linux networking and with C++ programming. <br />
* ''Bonus Experience:'' Experience with GENI and/or Emulab<br />
* ''Interests:'' Simulator tool development, integration with testbed experiments<br />
* ''Difficulty:'' Medium<br />
* ''Recommended Reading:'' http://groups.geni.net/geni/wiki/InstrumentationTools<br />
<br />
<br />
=== bufferbloat-related models ===<br />
<br />
Mentors: [mailto:tomh@tomh.org Tom Henderson]<br />
<br />
'''bufferbloat models:''' [https://www.youtube.com/watch?v=-D-cJNtKwuw Bufferbloat] is an interesting contemporary research topic. <br />
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).<br />
Note: There is already some ns-3 code available (see below) but the authors have not<br />
updated it for a while; this could be a starting point. Also, work could<br />
be done on using actual Linux code in the ns-3 Direct Code Execution (DCE)<br />
project.<br />
* ''Interests:'' Internet performance, linux kernel networking <br />
* ''Difficulty:'' easy to hard, depending on the depth of the project<br />
* ''Recommended reading:'' <br />
** http://gettys.wordpress.com/category/bufferbloat/<br />
** [http://www.bufferbloat.net/projects/cerowrt CeroWrt]<br />
** [http://www.ietf.org/proceedings/86/slides/slides-86-iccrg-3.pdf ICCRG presentation]<br />
** [http://pollere.net/CoDel.html ns-2 code]<br />
** [https://codereview.appspot.com/6463048/ ns-3 code review]<br />
<br />
<br />
=== High performance ns-3 emulation with Direct NIC Access (2) ===<br />
Mentors: [mailto:tazaki@sfc.wide.ad.jp Hajime Tazaki]<br />
<br />
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.<br />
<br />
The target of this project would be:<br />
<br />
# Identifying the bottle of ns-3. Using profiler (oprofile etc) would be the start point.<br />
# Introducing netmap interface as a FdNetDeviceHelper.<br />
# Performance comparison between existing one (i.e., EmuNetDevice) with the netmap one.<br />
# Creating a patch for fdnetdevice module (and ask reviews).<br />
# 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.<br />
<br />
* ''Required Experience:'' C++, Linux, Profiling (e.g., gprof/oprofile)<br />
* ''Interests:'' network performance, emulation<br />
* ''Difficulty:'' hard<br />
* ''Recommended reading:''<br />
** [http://info.iet.unipi.it/~luigi/netmap/ netmap]<br />
** Luigi Rizzo, [http://info.iet.unipi.it/~luigi/papers/20120503-netmap-atc12.pdf netmap: a novel framework for fast packet I/O], Usenix ATC'12, June 2012<br />
** Luigi Rizzo, [http://queue.acm.org/detail.cfm?id=2103536 Revisiting network I/O APIs: The netmap Framework], Communications of the ACM, March 2012<br />
** [http://nepi.inria.fr/wiki/FdNetDevice FdNetDevice] (will be merged at ns-3.17)<br />
<br />
=== Linux SCTP support over DCE ===<br />
Mentors: [mailto:tazaki@sfc.wide.ad.jp Hajime Tazaki]<br />
<br />
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.<br />
<br />
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.<br />
<br />
The target of this project would be:<br />
<br />
# Modifying DCE Linux module to support SCTP<br />
## enabling CONFIG_IP_SCTP option (and related one) and build it (I have incomplete patch)<br />
## writing simple SCTP program (I also have)<br />
## writing sample scenario script using above SCTP program (I also have)<br />
# Implement missing part of DCE Linux module to run SCTP code over ns-3<br />
# Implement DCE Cradle wrapper socket for SCTP (optional)<br />
# Create patch for ns-3-dce (and code review)<br />
<br />
* ''Required Experience:'' C/C++, Linux, Kernel<br />
* ''Interests:'' transport protocol, Direct Code Execution<br />
* ''Difficulty:'' medium<br />
* ''Recommended reading:''<br />
** [http://tools.ietf.org/html/rfc3286 RFC 3286] An Introduction to the Stream Control Transmission Protocol]<br />
** [http://lksctp.sourceforge.net Linux Kernel Stream Control Transmission Protocol Tools (lksctp-tools)]<br />
** [http://linux.die.net/man/7/sctp sctp(7) - Linux man page]<br />
** [http://code.nsnam.org/ns-3-dce/file/456bb670b7d2/example/dce-dccp.cc DCE DCCP protocol example simulation scenario]<br />
** [http://www.nsnam.org/projects/direct-code-execution/ Direct Code Execution]<br />
** [https://github.com/thehajime/net-next-sim DCE Linux module]<br />
** [https://sites.google.com/site/thehajime/Home/wns3-2013-tazaki.pdf?attredirects=0 DCE Cradle]<br />
<br />
<br />
=== Road Topology Model ===<br />
Mentors: [mailto:loulloudes.n@cs.ucy.ac.cy Nicholas Loulloudes]<br />
<br />
<br />
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. <br />
* Interests: VANETs. realistic simulations<br />
* Required experience: C++, XML, Python<br />
* Bonus experience: Python, Perl, Graph theory <br />
* Difficulty: medium <br />
* Recommended reading:<br />
** [1] http://sumo.sourceforge.net/ <br />
** [2] http://vanet.eurecom.fr/ <br />
** [3] http://www.openstreetmap.org/ <br />
** [4] http://www.census.gov/geo/maps-data/data/tiger.html<br />
<br />
<br />
<br />
=== Improve ns-3 support to sensor networks, RIOT adaptation ===<br />
<br />
Mentors: [mailto:daniel.camara@inria.fr Daniel Camara]<br />
<br />
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. <br />
<br />
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.<br />
<br />
The target of this project would be:<br />
<br />
# Create a RIOT interface at ns-3<br />
# Create a ns-3 architecture for RIOT<br />
# Link these two parts taking into account:<br />
## Real time/non-real time simulations (ns-3 clock should be used to control RIOT machines)<br />
## Implement an interrupt handler for creating ns-3 events on the ns-3 scheduler<br />
## Interaction between ns-3 and RIOT schedulers<br />
## Implement the communication between RIOT nodes<br />
## Implement the RIOT Physical layer<br />
## Provide mechanisms to interconnect RIOT machines using RIOT mac and standard ns-3 PHY-MAC layers<br />
# Provide tests<br />
# Provide examples of execution<br />
# Provide a good documentation support of the project<br />
<br />
* ''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.<br />
<br />
* ''Required Experience:'' C/C++<br />
<br />
* ''Interests:'' Sensor networks, simulation, operating systems<br />
<br />
* ''Difficulty:'' medium<br />
<br />
* ''Recommended reading:''<br />
** [1] E. Baccelli, O. Hahm, M. Wählisch, M. Günes, T. C. Schmidt, [http://hal.inria.fr/hal-00768685/ 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<br />
** [2] RIOT OS web site, [http://riot-os.github.io/RIOT/ http://riot-os.github.io/RIOT/]<br />
** [3] Heiko Will, Kaspar Schleiser, Jochen Schiller, [http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.173.1862 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<br />
<br />
=== Extension of the LTE HO algorithm and UE measurements support ===<br />
<br />
Mentors: [mailto:nicola.baldo@cttc.es Nicola Baldo] [mailto:marco.miozzo@cttc.es Marco Miozzo] [mailto:mrequena@cttc.es Manuel Requena]<br />
<br />
*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:<br />
<br />
** a) Implementation of intra-freq UE measurements report triggering (the existing support for A2 and A4 can be taken as an example)<br />
** 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)<br />
** 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)<br />
* ''Required Experience:'' C++, LTE<br />
* ''Interests:'' LTE, 3GPP, RRM<br />
* ''Difficulty:'' <br />
** a) easy<br />
** b) medium<br />
** c) hard<br />
<br />
* ''Recommended reading:''<br />
<br />
** [1] http://iptechwiki.cttc.es/LTE-EPC_Network_Simulator_%28LENA%29<br />
** [2] TS 36.300 section 22.3.3 Intra-LTE/frequency Automatic Neighbour Relation Function<br />
** [3] TS 36.331 section 5.5 Measurements<br />
** [4] TS 36.133, Section 8.2 UE Measurements Procedures in RRC_CONNECTED State<br />
** [5] "Evaluation of the Automatic Neighbor Relation Function in a Dense Urban Scenario", C.M. Mueller, H. Bakker, L. Ewe Inst. of Commun. Networks & Comput. Eng., Univ. of Stuttgart, Stuttgart, Germany 06/2011; DOI:10.1109/VETECS.2011.5956375 In proceeding of: Vehicular Technology Conference (VTC Spring), 2011 IEEE 73rd<br />
** [6] "Energy-Efficient Mobility Management for the Integrated Macrocell-Femtocell LTE Network", D. Xenakis, N. Passas, L. Di Gregorio and Ch. Verikoukis, presented at BeFemto Femto Winter School, Feb 2012, Barcelona, Spain<br />
*** http://sites.cttc.es/femtoschool/images/presentations/16_dionysisxenakis_univathens_energyefficientmobilitymanagement.pdf<br />
*** https://www.youtube.com/watch?v=H0hNrLh6mUw&list=PL551D6BB1392B03EE</div>Nicolabaldohttps://www.nsnam.org/mediawiki/index.php?title=GSOCMentorGuide&diff=7542GSOCMentorGuide2013-04-15T16:50:37Z<p>Nicolabaldo: </p>
<hr />
<div>{{TOC}}<br />
<br />
[[GSOC2013Projects]]<br />
<br />
=ns-3 mentor guidelines=<br />
<br />
Below are some specific guidelines and FAQs to applying to be a mentor in ns-3's GSoC program. These guidelines apply above and beyond what you will read on the GSOC site and on other wikis [1,2]. If you want to propose ideas and become a mentor, please read the below and the references cited.<br />
<br />
<br />
== How do mentors apply? ==<br />
<br />
Mentors apply by submitting project ideas on the ideas page, or by contacting the org admin (Lalith) directly.<br />
<br />
<br />
== How are mentors chosen? ==<br />
<br />
Mentor selection in ns-3 is somewhat secondary to student selection. We will select the strongest student applications that have reasonable, credible mentoring plans. If a student project proposal is exceptionally strong, but has been developed with no mentor or suggested project proposal, the selection committee or organizational admin will try to find a mentor during the application selection phase. However, all things being equal in the student applications, we will select the student project that has a solid mentoring commitment over one that doesn't have any mentor identified.<br />
<br />
The rules for mentor selection are as follows:<br />
<br />
* Projects will have one lead mentor but may have backups or assistants.<br />
* At least one mentor on the mentoring team '''must''' be a maintainer of some sort (commit privileges on the code server, or equivalent). This policy will allow us to also shepherd new mentors into the ns-3 project.<br />
* Mentors will be selected based on the student projects selected.<br />
* Mentors may work for companies so long as they are able to devote the necessary time (several hours per week, up to ten hours per week in some cases) to the project.<br />
<br />
<br />
== Can people form mentor teams? ==<br />
<br />
See above.<br />
<br />
<br />
== Can prospective mentors help students develop applications? ==<br />
<br />
Yes. Mentors are expected to provide routine feedback to the students' proposals during the application phase. That said, mentors are expected to adhere to the following guidelines:<br />
<br />
* Mentors should take reasonable steps to ensure that a student does not develop an unfair competitive advantage from private conversations with mentors.<br />
* During the application phase, it is best to hold project development discussions on the ns-developers list so that any prospective applicant can benefit from the discussion.<br />
* When discussing a proposal with a student, the mentor must ensure that the proposal is scoped appropriately. That is:<br />
** 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.<br />
** 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.<br />
** 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.<br />
<br />
<br />
== Do prospective mentors have any role in selecting the student projects? ==<br />
<br />
A selection committee will be formed by the organizational admin (Lalith) and this committee may be composed of some prospective mentors. Please contact Lalith if you would like to serve on this committee.<br />
<br />
<br />
== How much time does it take? ==<br />
<br />
We are asking mentors to commit to a minimum of 2-4 hours per week helping their student, and it may be more time in spots (such as around midterm and final evaluations). The amount of time required to make the project successful depends on the student and the degree of difficulty of the project. Almost daily interaction is needed on some projects.<br />
<br />
As a guideline, we would encourage at least two meetings per week, where the meetings occur on Skype, IRC, or other interactive media.<br />
<br />
<br />
== How do payments work? ==<br />
<br />
Each mentor is eligible for $500. In the past, the payment system worked as follows. Google required one individual to register as a vendor and accept payment for all mentors, and mentors were paid from this after U.S. taxes were withdrawn on the amount.<br />
<br />
Mentors are encouraged to donate their mentor proceeds to the ns-3 Consortium. Mentors who prefer to receive their payments should arrange this with the organization admins.<br />
<br />
<br />
== What if a mentor has some summer vacation planned? ==<br />
<br />
Mentors must arrange for backup mentoring during the period that they are unavailable.<br />
<br />
<br />
<br />
[1] http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2013/help_page<br />
<br />
[2] http://en.flossmanuals.net/GSoCMentoring/what-makes-a-good-mentor/</div>Nicolabaldohttps://www.nsnam.org/mediawiki/index.php?title=GSOCMentorGuide&diff=7541GSOCMentorGuide2013-04-15T16:49:41Z<p>Nicolabaldo: </p>
<hr />
<div>{{TOC}}<br />
<br />
[[GSOC2013Projects GSOC2013 Ideas page]]<br />
<br />
=ns-3 mentor guidelines=<br />
<br />
Below are some specific guidelines and FAQs to applying to be a mentor in ns-3's GSoC program. These guidelines apply above and beyond what you will read on the GSOC site and on other wikis [1,2]. If you want to propose ideas and become a mentor, please read the below and the references cited.<br />
<br />
<br />
== How do mentors apply? ==<br />
<br />
Mentors apply by submitting project ideas on the ideas page, or by contacting the org admin (Lalith) directly.<br />
<br />
<br />
== How are mentors chosen? ==<br />
<br />
Mentor selection in ns-3 is somewhat secondary to student selection. We will select the strongest student applications that have reasonable, credible mentoring plans. If a student project proposal is exceptionally strong, but has been developed with no mentor or suggested project proposal, the selection committee or organizational admin will try to find a mentor during the application selection phase. However, all things being equal in the student applications, we will select the student project that has a solid mentoring commitment over one that doesn't have any mentor identified.<br />
<br />
The rules for mentor selection are as follows:<br />
<br />
* Projects will have one lead mentor but may have backups or assistants.<br />
* At least one mentor on the mentoring team '''must''' be a maintainer of some sort (commit privileges on the code server, or equivalent). This policy will allow us to also shepherd new mentors into the ns-3 project.<br />
* Mentors will be selected based on the student projects selected.<br />
* Mentors may work for companies so long as they are able to devote the necessary time (several hours per week, up to ten hours per week in some cases) to the project.<br />
<br />
<br />
== Can people form mentor teams? ==<br />
<br />
See above.<br />
<br />
<br />
== Can prospective mentors help students develop applications? ==<br />
<br />
Yes. Mentors are expected to provide routine feedback to the students' proposals during the application phase. That said, mentors are expected to adhere to the following guidelines:<br />
<br />
* Mentors should take reasonable steps to ensure that a student does not develop an unfair competitive advantage from private conversations with mentors.<br />
* During the application phase, it is best to hold project development discussions on the ns-developers list so that any prospective applicant can benefit from the discussion.<br />
* When discussing a proposal with a student, the mentor must ensure that the proposal is scoped appropriately. That is:<br />
** 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.<br />
** 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.<br />
** 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.<br />
<br />
<br />
== Do prospective mentors have any role in selecting the student projects? ==<br />
<br />
A selection committee will be formed by the organizational admin (Lalith) and this committee may be composed of some prospective mentors. Please contact Lalith if you would like to serve on this committee.<br />
<br />
<br />
== How much time does it take? ==<br />
<br />
We are asking mentors to commit to a minimum of 2-4 hours per week helping their student, and it may be more time in spots (such as around midterm and final evaluations). The amount of time required to make the project successful depends on the student and the degree of difficulty of the project. Almost daily interaction is needed on some projects.<br />
<br />
As a guideline, we would encourage at least two meetings per week, where the meetings occur on Skype, IRC, or other interactive media.<br />
<br />
<br />
== How do payments work? ==<br />
<br />
Each mentor is eligible for $500. In the past, the payment system worked as follows. Google required one individual to register as a vendor and accept payment for all mentors, and mentors were paid from this after U.S. taxes were withdrawn on the amount.<br />
<br />
Mentors are encouraged to donate their mentor proceeds to the ns-3 Consortium. Mentors who prefer to receive their payments should arrange this with the organization admins.<br />
<br />
<br />
== What if a mentor has some summer vacation planned? ==<br />
<br />
Mentors must arrange for backup mentoring during the period that they are unavailable.<br />
<br />
<br />
<br />
[1] http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2013/help_page<br />
<br />
[2] http://en.flossmanuals.net/GSoCMentoring/what-makes-a-good-mentor/</div>Nicolabaldohttps://www.nsnam.org/mediawiki/index.php?title=GSOC2013Projects&diff=7460GSOC2013Projects2013-03-22T19:05:47Z<p>Nicolabaldo: /* Medium Priority Projects */</p>
<hr />
<div>{{TOC}}<br />
<br />
<div style="float: left; width: 100%"><br />
* [http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2012/faqs GSoC Frequently Asked Questions]<br />
* [http://en.flossmanuals.net/gsocmentoring/ GSoC Mentor guide]<br />
* [http://en.flossmanuals.net/GSoCStudentGuide/ GSoC student guide]<br />
* [[GSOC2013StudentGuide |ns-3's GSoC Student guide]]<br />
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br />
* [[GSOC2013PatchRequirement | Patch Requirement Guidelines]]<br />
* [[GSOC2013StudentApplicationTemplate |GSoC Student application template]]<br />
* [[GSOC2012Projects |GSoC 2012 page]] | [[GSOC2012AcceptedProjects |GSoC 2012 Accepted Projects]]<br />
* [[GSOC2011Projects |NSoC 2011 Ideas page]] | [[NSOC2011AcceptedProjects |NSoC 2011 Accepted Projects]]<br />
* [[GSOC2010Projects |GSoC 2010 Ideas page]] | [[GSOC2010AcceptedProjects |GSoC 2010 Accepted Projects]]<br />
* [[GSOC2009Projects |GSoC 2009 Ideas page]] | [[GSOC2009AcceptedProjects |GSoC 2009 Accepted Projects]]<br />
* [[GSOC2010OAReport |GSoC Organization Administrator guide]]<br />
* ''Get in contact with the ns-3 team'': [http://mailman.isi.edu/mailman/listinfo/ns-developers ns-developers mailing list] | ''IRC'' #ns-3 on freenode.net<br />
<br />
</div><br />
<p><br />
<br />
<br />
= GSoC 2013 Ideas =<br />
<br />
This webpage highlights project ideas for ns-3's Google Summer of Code 2013 effort.<br />
<br />
GSOC 2012 Timeline is:<br />
* March 18 - 19:00 UTC: Mentoring organizations can begin submitting applications to Google.<br />
* March 29 - 19:00 UTC: Mentoring organization application deadline.<br />
* April 8 - 19:00 UTC: List of accepted mentoring organizations published on the Google Summer of Code 2013 site.<br />
* April 9-21: Would-be student participants discuss application ideas with mentoring organizations.<br />
* April 22 - 19:00 UTC: Student application period opens.<br />
* May 3 - 19:00 UTC: Student application deadline.<br />
Full timeline is here: http://www.google-melange.com/gsoc/events/google/gsoc2013<br />
<br />
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. <br />
<br />
== About the ns-3 project ==<br />
<br />
ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Our GSoC organizational admin is [mailto:suresh.lalith@gmail.com Lalith Suresh] and our backup org admin is [mailto:tomhend@u.washington.edu Tom Henderson].<br />
<br />
Our mentor pool for this year:<br />
<br />
== Getting started ==<br />
<br />
For students interested in applying to ns-3 for GSOC, go through the following list to get started:<br />
* Read the official [http://en.flossmanuals.net/GSoCStudentGuide/ GSoC student guide].<br />
* Read [[GSOC2013StudentGuide |ns-3's GSoC Student guide]].<br />
* Look through our ideas list below to see if you find a project that interests you.<br />
* Look through the [[GSOC2013StudentApplicationTemplate |GSoC Student application template]] to start preparing your proposal.<br />
* Next, proceed to get in touch with the developers on the mailing list and refine your proposal.<br />
* In parallel, make sure you prepare a patch as per the [[GSOC2013PatchRequirement | Patch Requirement Guidelines]]. Your application to ns-3 will not be considered if you do not fulfill this requirement.<br />
<br />
<br />
== Project Ideas ==<br />
<br />
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 [http://mailman.isi.edu/mailman/listinfo/ns-developers 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 [http://mailman.isi.edu/mailman/listinfo/ns-developers 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.<br />
<br />
<blockquote><br />
Each project idea within a particular priority has been tagged with the following properties:<br />
* ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br />
* ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br />
* ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful students might apply their experiences coming out of this project.<br />
* ''Difficulty:'' easy, medium or difficult<br />
* ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br />
<br />
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.<br />
</blockquote><br />
<br />
= Guidelines for project ideas =<br />
<br />
For mentors who're adding project ideas to the list below, please ensure that:<br />
<br />
* 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.<br />
* 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.<br />
<br />
<br />
= High Priority Projects =<br />
<br />
=== Project Idea Example ===<br />
<br />
Mentors: [mailto:mentor@email Mentor Person]<br />
<br />
* Project description: High level description of project.<br />
** ''Required Experience:'' C++, Linux kernel hacking, something.<br />
** ''Interests:'' Emulation, Foo, Bar.<br />
** ''Difficulty:'' easy/medium/hard.<br />
** ''Recommended reading:'' <br />
*** Reference 1<br />
*** Reference 2<br />
<br />
= Medium Priority Projects =<br />
<br />
=== Vehicular Ad-hoc Networks ===<br />
<br />
Mentors: [mailto:guillaume.remy@ieee.org Guillaume Rémy]<br />
<br />
* '''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:<br />
# 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.<br />
# 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)<br />
# higher layers: nothing specific to WAVE is currently available.<br />
# 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).<br />
** ''Required experience:'' C++.<br />
** ''Bonus experience:'' Wireless networking, WAVE.<br />
** ''Interests:'' Wireless networking, VANETs.<br />
** ''Difficulty:'' medium to hard, depending on what the student proposes to implement.<br />
** ''Recommended reading''<br />
*** [0] http://www.nsnam.org/bugzilla/show_bug.cgi?id=700#c11<br />
*** [1] http://www.nsnam.org/bugzilla/show_bug.cgi?id=945<br />
*** [2] http://www.nsnam.org/bugzilla/show_bug.cgi?id=978#c16<br />
*** [3] http://www.nsnam.org/bugzilla/attachment.cgi?id=968<br />
*** [4] http://dsn.tm.kit.edu/english/ns3-physim.php<br />
<br />
<br />
=== 802.15.4 Energy Model ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br />
<br />
* '''802.15.4 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. Hence it is not possible to simulate correctly the energy discharge of a Wireless Sensor Node correctly. The goal is to develop the missing classes needed to link the two modules, and to validate the results against the literature models.<br />
** ''Required Experience:'' C++, WSN<br />
** ''Bonus Experience:'' ns-3 Energy model<br />
** ''Interests:'' WSN, Battery discharge<br />
** ''Difficulty:'' easy<br />
** ''Recommended reading:''<br />
*** [http://www.sics.se/~adam/dunkels07softwarebased.pdf Software-based On-line Energy Estimation for Sensor Nodes] <br />
*** [http://cds.unibe.ch/research/pub_files/HBNH11.pdf On the Accuracy of Software-based Energy Estimation Techniques]<br />
<br />
=== 802.15.4 Bootstrap ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br />
<br />
* '''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.<br />
** ''Required Experience:'' C++, WSN<br />
** ''Bonus Experience:'' 802.15.4 standard<br />
** ''Interests:'' WSN<br />
** ''Difficulty:'' medium<br />
** ''Recommended reading:''<br />
*** [http://standards.ieee.org/getieee802/download/802.15.4-2011.pdf 802.15.4 Standard]<br />
<br />
<br />
<br />
=== 802.15.4 Beacon-enabled mode ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br />
<br />
* '''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. <br />
** ''Required Experience:'' C++, WSN<br />
** ''Bonus Experience:'' 802.15.4 standard<br />
** ''Interests:'' WSN<br />
** ''Difficulty:'' medium/hard<br />
** ''Recommended reading:''<br />
*** [http://standards.ieee.org/getieee802/download/802.15.4-2011.pdf 802.15.4 Standard]<br />
<br />
<br />
=== Simulating the Internet of Things in NS-3 === <br />
Mentors: [mailto:peter.kourzanov@gmail.com Peter Kourzanov], [mailto:hong.r.li@nxp.com Hong.R. Li]<br />
<br />
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.<br />
** ''Required experience'' : C++<br />
** ''Bonus experience'' : NS-2, WSN, Matlab<br />
** ''Interests'' : ZB, embedded, wireless, sensor networks<br />
** ''Difficulty'' : medium<br />
** ''Recommended reading'' :<br />
**# LR-WPAN [http://www.nsnam.org/wiki/index.php/Lr-wpan status page]<br />
**# LR-WPAN [http://code.nsnam.org/tomh/ns-3-lr-wpan/file/735b14afde8e/lr-wpan-documentation.pdf model-library document]<br />
**# Preliminary LR-WPAN [http://code.nsnam.org/tomh/ns-3-lr-wpan code] for NS-3<br />
**# Preliminary IPv6 over Low-power WPAN (6LoWPAN) [http://code.nsnam.org/tpecorella/ns-3-6LoWPAN code] for NS-3<br />
**# Mature [http://cint.ccny.cuny.edu/awnl/Software implementation] of ZB 2003 in [http://www.isi.edu/nsnam/ns NS-2] (included in version 2.35)<br />
**#* original [http://cint.ccny.cuny.edu/awnl/Software/WPAN_ZBR_pub.pdf presentation] from CUNY<br />
**#* adaptation and bug-fixes from [http://www.ee.washington.edu/research/funlab/802_15_4 Funlab]<br />
**# [http://en.wikipedia.org/wiki/IEEE_802.15.4 LR-WPAN] page on Wikipedia<br />
**# [http://en.wikipedia.org/wiki/ZigBee ZB] page on Wikipedia<br />
<br />
<br />
=== Neighbor Discovery Optimization for Low Power and Lossy Networks (6LoWPAN-nd) ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br />
<br />
* '''6LoWPAN-nd implementation and testing:''' [http://tools.ietf.org/html/draft-ietf-6lowpan-nd-18 6LoWPAN-nd] is novel draft protocol from IETF's [http://tools.ietf.org/wg/6lowpan/ 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. <br />
** ''Required Experience:'' C++, IPv6, RPL<br />
** ''Bonus Experience:'' WSN networking<br />
** ''Interests:'' WSN, IPv6, node bootstrap, efficient packet compression <br />
** ''Difficulty:'' hard<br />
** ''Recommended reading:''<br />
*** [http://tools.ietf.org/html/rfc4919 RFC 4919] IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals<br />
*** [http://tools.ietf.org/html/draft-ietf-6lowpan-nd-18 6LoWPAN-nd] Neighbor Discovery Optimization for Low Power and Lossy Networks<br />
<br />
<br />
=== RPL protocol Metric and Constraints ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br />
<br />
* '''RPL protocol Metric and Constraints:''' The [http://tools.ietf.org/wg/roll/ 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.).<br />
** ''Required Experience:'' C++, IPv6,<br />
** ''Bonus Experience:'' RPL protocol<br />
** ''Interests:'' WSN, routing <br />
** ''Difficulty:'' medium<br />
** ''Recommended reading:''<br />
*** [http://tools.ietf.org/html/rfc6550 RFC 6550] RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks<br />
*** [http://tools.ietf.org/html/rfc6551 RFC 6551] Routing Metrics Used for Path alculation in Low-Power and Lossy Networks<br />
<br />
<br />
=== IPv6 stack validation and improvements ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br />
<br />
* '''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):<br />
*# There is no [http://en.wikipedia.org/wiki/Path_MTU_discovery path MTU discovery] see also [http://tools.ietf.org/html/rfc1981 RFC 1981].<br />
*# Flow Monitor module does not work on the IPv6 stack<br />
*# FlowLabel header field is not currenly used<br />
*# IPSec is not supported<br />
* 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.<br />
** ''Required Experience:'' C++, TCP/IP networking<br />
** ''Bonus Experience:'' IPv6 protocols<br />
** ''Interests:'' IPv6 internetworking<br />
** ''Difficulty:'' easy / medium, depending on the features implemented<br />
** ''Recommended reading:''<br />
*** [http://www.ietf.org/rfc/rfc4294.txt RFC 4294 - IPv6 Node Requirements]<br />
*** [http://tools.ietf.org/html/rfc1981 RFC 1981 - Path MTU Discovery for IP version 6]<br />
*** ns-3 Flowmon module documentation<br />
*** [http://tools.ietf.org/html/rfc6437 RFC 6437 - IPv6 Flow Label Specification]<br />
*** [http://tools.ietf.org/html/rfc4302 RFC 4302 - IP Authentication Header]<br />
*** [http://tools.ietf.org/html/rfc4303 RFC 4303 - IP Encapsulating Security Payload (ESP)]<br />
<br />
<br />
=== Multicast IPv6 traffic support ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br />
<br />
* '''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.<br />
** ''Required Experience:'' C++, IPv6,<br />
** ''Bonus Experience:'' Multicast routing protocols (MLDv2/IGMPv3 and PIM)<br />
** ''Interests:'' routing, multicast<br />
** ''Difficulty:'' medium/hard<br />
** ''Recommended reading:''<br />
*** [http://www.h3c.com/portal/Products___Solutions/Products/Switches/H3C_S5500-SI_Series_Switches/White_Paper/200806/688942_57_0.htm Multicast Technology White Paper]<br />
*** [http://www.alliedtelesis.co.nz/documentation/at9800/291/pdf/ipv6mu.pdf IPv6 Multicasting]<br />
*** All the relevant RFCs (search in [http://www.rfc-editor.org/search/rfc_search.php RFC Editor search engine])<br />
<br />
<br />
=== High performance ns-3 emulation with Direct NIC Access ===<br />
<br />
Mentors: [mailto:jose.nunez@cttc.cat José Nuñez]<br />
<br />
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. <br />
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.<br />
* ''Required Experience:'' C++, Linux <br />
* ''Interests:'' network performance, emulation<br />
* ''Difficulty:'' hard<br />
* ''Recommended reading:''<br />
** http://www.ntop.org/products/pf_ring/libzero-for-dna/<br />
<br />
<br />
=== LTE Idle Mode Procedures ===<br />
<br />
Mentors: [mailto:jaime.ferragut@cttc.es Jaime Ferragut] [mailto:nicola.baldo@cttc.es Nicola Baldo]<br />
<br />
* 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.<br />
* ''Required Experience:'' C++, LTE<br />
* ''Interests:'' mobility management<br />
* ''Difficulty:'' medium/hard<br />
* ''Recommended reading:''<br />
** 3GPP TS 36.300 "E-UTRA and E-UTRAN overall description", section 10.1.1 "Mobility Management in ECM-IDLE"<br />
** 3GPP TS 36.304 "User Equipment (UE) procedures in idle mode"<br />
** 3GPP TS 24.301 "Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS)"<br />
<br />
= Low Priority Projects =<br />
<br />
<br />
[[Category:GSoC]]</div>Nicolabaldohttps://www.nsnam.org/mediawiki/index.php?title=DevelMeetingMar2013&diff=7350DevelMeetingMar20132013-02-27T11:42:45Z<p>Nicolabaldo: /* Attendees */</p>
<hr />
<div><br />
{{TOC}}<br />
<br />
= Location and Schedule =<br />
<br />
The meeting will occur Wed March 6 through Fri March 8 at INRIA Sophia Antipolis. INRIA will provide us with a large enough conference room to meet. We will meet for three days, and people can attend whatever portion they feel like.<br />
<br />
A more detailed schedule will be posted at a later date.<br />
<br />
== Other events this week ==<br />
<br />
* Information about Monday's [http://www.nsnam.org/consortium/activities/annual-meeting-march-2013/ Annual Meeting March 2013]<br />
* Information about Tuesday's [http://www.nsnam.org/wns3/wns3-2013/ Workshop on ns-3 2013]<br />
<br />
== Lodging and Directions ==<br />
<br />
INRIA Sophia Antipolis is located on a hillside above [http://en.wikipedia.org/wiki/Antibes Antibes] / [http://en.wikipedia.org/wiki/Juan-les-Pins Juan les Pins], France. It is possible to reach the center by public transport from Antibes, Nice, and Cannes.<br />
<br />
* [https://www.nsnam.org/consortium/activities/annual-meeting-march-2013/venue-and-useful-information/ Venue and Useful Information]<br />
* [https://www.nsnam.org/consortium/activities/annual-meeting-march-2013/accommodation/ Hotel accommodations]<br />
<br />
== Registration ==<br />
<br />
Attendance is free but everyone must obtain a visitor badge to enter INRIA. Please list yourself as an attendee and provide contact information as needed to tomh@tomh.org if you want to attend.<br />
<br />
== Attendees ==<br />
<br />
Please add your name here if you intend to attend, and which days.<br />
<br />
* [[User:Tomh|Tom Henderson]], Wed, Thurs, Fri<br />
* [[User:Vedranm|Vedran Miletic]], Wed, Thurs, Fri (Fri half day only)<br />
* George Riley, Wed, Thurs<br />
* Brian Swenson, Wed, Thurs<br />
* Nicola Baldo, Wed, Thurs, Fri (Fri half day only)<br />
* Daniel Camara, Wed, Thurs, Fri<br />
* Peter Barnes, Fri (and possibly parts of Wed, Thurs)<br />
<br />
* [[User:tommaso|Tommaso Pecorella]], Wed, Thurs, Fri (Fri half day only)<br />
<br />
* [[User:Tazaki|Hajime Tazaki]], Wed, Thurs, Fri<br />
* Alina Quereilhac, Wed, Thurs, Fri<br />
<br />
= Suggested agenda/topics =<br />
<br />
Please list suggested discussion topics below and we will build a schedule at a later date. Please also suggest 'read-ahead' items as needed.<br />
<br />
* Object Start/Stop<br />
* ns-3 in education<br />
* XML as a language for simulation specification, Peter Barnes' talk<br />
** some ideas could be taken from SimGrid guys, they have rather small XML files that say a lot of things<br />
* data collection framework<br />
* variable test scope (bug 1563)<br />
* Modularization of ns-3<br />
* <b>user feedback:</b> what areas (documentation, API) can be improved from a user standpoint? This discussion will be based on feedback from people who have been active on the ns-3-users mailing list.<br />
* DCE release plan review<br />
* Time::SetResolution patch by Peter Barnes and Mathieu Lacage, how to fix it and proceed with merging<br />
<br />
[[Category:DevelMeeting]]</div>Nicolabaldohttps://www.nsnam.org/mediawiki/index.php?title=DevelMeetingMar2013&diff=7196DevelMeetingMar20132013-02-01T12:58:00Z<p>Nicolabaldo: /* Attendees */</p>
<hr />
<div><br />
{{TOC}}<br />
<br />
= Location and Schedule =<br />
<br />
The meeting will occur Wed March 6 through Fri March 8 at INRIA Sophia Antipolis. INRIA will provide us with a large enough conference room to meet. We will meet for three days, and people can attend whatever portion they feel like.<br />
<br />
A more detailed schedule will be posted at a later date.<br />
<br />
= Attending =<br />
<br />
Attendance is free; however, you must register to attend to obtain a visitor badge. Please contact tomh@tomh.org if you would like to attend.<br />
<br />
== Attendees ==<br />
<br />
Please add your name here if you intend to attend, and which days.<br />
<br />
* Tom Henderson, Wed, Thurs, Fri<br />
* Vedran Miletic, Wed, Thurs, Fri<br />
* George Riley, Wed, Thurs<br />
* Brian Swenson, Wed, Thurs<br />
* Nicola Baldo, Wed, Thurs, maybe Fri<br />
<br />
= Suggested agenda/topics =<br />
<br />
Please list suggested discussion topics below and we will build a schedule at a later date.<br />
<br />
* Object Start/Stop<br />
* ns-3 in education<br />
* data collection framework<br />
* variable test scope (bug 1563)</div>Nicolabaldohttps://www.nsnam.org/mediawiki/index.php?title=DevelMeetingMar2013&diff=7195DevelMeetingMar20132013-02-01T12:51:48Z<p>Nicolabaldo: /* Suggested agenda/topics */</p>
<hr />
<div><br />
{{TOC}}<br />
<br />
= Location and Schedule =<br />
<br />
The meeting will occur Wed March 6 through Fri March 8 at INRIA Sophia Antipolis. INRIA will provide us with a large enough conference room to meet. We will meet for three days, and people can attend whatever portion they feel like.<br />
<br />
A more detailed schedule will be posted at a later date.<br />
<br />
= Attending =<br />
<br />
Attendance is free; however, you must register to attend to obtain a visitor badge. Please contact tomh@tomh.org if you would like to attend.<br />
<br />
== Attendees ==<br />
<br />
Please add your name here if you intend to attend, and which days.<br />
<br />
* Tom Henderson, Wed, Thurs, Fri<br />
* Vedran Miletic, Wed, Thurs, Fri<br />
* George Riley, Wed, Thurs<br />
* Brian Swenson, Wed, Thurs<br />
<br />
= Suggested agenda/topics =<br />
<br />
Please list suggested discussion topics below and we will build a schedule at a later date.<br />
<br />
* Object Start/Stop<br />
* ns-3 in education<br />
* data collection framework<br />
* variable test scope (bug 1563)</div>Nicolabaldohttps://www.nsnam.org/mediawiki/index.php?title=Ns-3.16&diff=7020Ns-3.162012-10-01T20:10:04Z<p>Nicolabaldo: /* new feature reviews */</p>
<hr />
<div>{{TOC}}<br />
<br />
This page summarizes the ongoing release planning for ns-3.16. The ns-3 release process is listed [http://www.nsnam.org/developers/release-process/ here] and [[Release Process | here]].<br />
<br />
= Release schedule =<br />
<br />
* Wed Nov 21 -- new feature freeze<br />
* Wed Dec 5 -- code freeze on ns-3-dev<br />
* Wed Dec 12 -- ns-3.16 released<br />
<br />
= Proposed supported platforms =<br />
<br />
TBD (recent versions of OS X, Linux, and FreeBSD)<br />
<br />
= Packaging =<br />
<br />
Source tarball (tar.bz2).<br />
<br />
= new feature reviews =<br />
<br />
* bake: [http://www.nsnam.org/wiki/index.php/BakeIntegration wiki description]<br />
* Low resolution radio model: [http://codereview.appspot.com/5466046 code review]<br />
* Brian Panneton's antenna model updates http://mailman.isi.edu/pipermail/ns-developers/2012-April/010322.html<br />
* [http://codereview.appspot.com/6201059/ New IEEE 802.11b indoor wireless channel models for (HMM and BEAR)]<br />
* [http://codereview.appspot.com/6192052/ Longley-Rice and ITU terrain-aware propagation models]<br />
* [https://www.nsnam.org/bugzilla/show_bug.cgi?id=454 TCP Echo] Code review [http://codereview.appspot.com/5654053/ here], needs updating<br />
* [http://codereview.appspot.com/5552055/ Finishing ns-3-click-mac extensions] -> Blocked by queue API resolution<br />
* [http://codereview.appspot.com/4685048/ Monitor mode support] ([http://codereview.appspot.com/5552055/ Update from Bjorn]) <br />
* [http://groups.google.com/group/ns-3-reviews/browse_thread/thread/512bf466d3cd5ec0?pli=1 UAN Mobility Model merge (from previous GSOC)] <br />
** blocked on resolving changes to WaypointMobilityModel API<br />
* Switched Ethernet device: http://codereview.appspot.com/5615049/<br />
* HTTP traffic generator: http://codereview.appspot.com/4940041/<br />
* GPSR: http://codereview.appspot.com/5401042<br />
* TMix and Delaybox: http://code.google.com/p/tmix-ns3/<br />
* LTE MAC Schedulers by Dizhi Zhou (GSoC 2012): http://codereview.appspot.com/6591047/<br />
<br />
= Bugs being worked =<br />
<br />
== Simulation core ==<br />
<br />
Bugs or issues involving things that are not related to protocol or channel models.<br />
<br />
* [http://codereview.appspot.com/6497052 1237 Code cleanup related to includes] Vedran Miletić<br />
* [https://www.nsnam.org/bugzilla/show_bug.cgi?id=582 582 Tags are not serialized and deserialized from Packet::Serialize and Packet::Deserialize] Peter Barnes<br />
** Patchset 1: Add class Hash: generic hash function interface http://codereview.appspot.com/6357056/<br />
** Patchset 2: Add hashes to TypeId. http://codereview.appspot.com/6344063/<br />
** Patchset 3: Refactor PacketTagList http://codereview.appspot.com/6354061/<br />
* [https://www.nsnam.org/bugzilla/show_bug.cgi?id=938 938 Doxygen cleanup] Vedran Miletić and Tom Henderson<br />
* [https://www.nsnam.org/bugzilla/show_bug.cgi?id=1192 1192 Some test cases fail to clean up properly (missing DoTeardown)] Claudio Freire<br />
* [http://codereview.appspot.com/4664057/ NetDevice queue feedback] Ruben Merz, Frederic Urbani, and Tom Henderson<br />
** explained here: http://mailman.isi.edu/pipermail/ns-developers/2011-July/009170.html<br />
* Object::Stop patch http://mailman.isi.edu/pipermail/ns-developers/2012-May/010392.html<br />
* FdReader device refactoring (Alina Quereilhac)<br />
<br />
== Bugs in ns-3 models ==<br />
<br />
[https://www.nsnam.org/bugzilla/buglist.cgi?bug_status=__open__&content=&product=&query_format=specific&order=bug_id%20DESC&query_based_on= Open bugs] will be worked on a best-effort basis.</div>Nicolabaldohttps://www.nsnam.org/mediawiki/index.php?title=GSOC2012Projects&diff=6621GSOC2012Projects2012-03-08T16:57:50Z<p>Nicolabaldo: /* Project Ideas */</p>
<hr />
<div>{{TOC}}<br />
<br />
<div style="float: left; width: 100%"><br />
* [http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2012/faqs GSoC Frequently Asked Questions]<br />
* [http://en.flossmanuals.net/gsocmentoring/ GSoC Mentor guide]<br />
* [http://en.flossmanuals.net/GSoCStudentGuide/ GSoC student guide]<br />
* [[GSOC2012StudentGuide |ns-3's GSoC Student guide]]<br />
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br />
* [[GSOC2012StudentApplicationTemplate |GSoC Student application template]]<br />
* [[GSOC2012Projects |GSoC 2012 page]]<br />
* [[GSOC2011Projects |NSoC 2011 Ideas page]] | [[NSOC2011AcceptedProjects |NSoC 2011 Accepted Projects]]<br />
* [[GSOC2010Projects |GSoC 2010 Ideas page]] | [[GSOC2010AcceptedProjects |GSoC 2010 Accepted Projects]]<br />
* [[GSOC2009Projects |GSoC 2009 Ideas page]] | [[GSOC2009AcceptedProjects |GSoC 2009 Accepted Projects]]<br />
* [[GSOC2010OAReport |GSoC Organization Administrator guide]]<br />
* ''Get in contact with the ns-3 team'': [http://mailman.isi.edu/mailman/listinfo/ns-developers ns-developers mailing list] | ''IRC'' #ns-3 on freenode.net<br />
<br />
</div><br />
<p><br />
<br />
<br />
= GSoC 2012 Ideas =<br />
<br />
This webpage highlights project ideas for ns-3's Google Summer of Code 2012 effort.<br />
<br />
GSOC 2012 Timeline is:<br />
* February 27 - 19:00 UTC: Mentoring organizations can begin submitting applications to Google.<br />
* March 9 - 23:00 UTC: Mentoring organization application deadline.<br />
* March 16 - 19:00 UTC: List of accepted mentoring organizations published on the Google Summer of Code 2012 site.<br />
* March 17-25: Would-be student participants discuss application ideas with mentoring organizations.<br />
* March 26 - 19:00 UTC: Student application period opens.<br />
* April 6 - 19:00 UTC: Student application deadline.<br />
Full timeline is here: http://www.google-melange.com/gsoc/events/google/gsoc2012<br />
<br />
While discussions about ideas can be done earlier, please note that ns-3 will not receive an answer to its GSOC application before March 16. <br />
<br />
== About the ns-3 project ==<br />
<br />
ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Our GSoC organizational admin is [mailto:suresh.lalith@gmail.com Lalith Suresh] and our backup org admin is [mailto:tomhend@u.washington.edu Tom Henderson].<br />
<br />
== Project Ideas ==<br />
<br />
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. The project ideas ''have not'' been ordered in order of importance or priority. Please email the [http://mailman.isi.edu/mailman/listinfo/ns-developers 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 [http://mailman.isi.edu/mailman/listinfo/ns-developers 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.<br />
<br />
<blockquote><br />
Each project idea has been tagged with the following properties:<br />
* ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br />
* ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br />
* ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful students might apply their experiences coming out of this project.<br />
* ''Difficulty:'' easy, medium or difficult<br />
* ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br />
<br />
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.<br />
</blockquote><br />
<br />
=== Project area ===<br />
<br />
Mentors:<br />
<br />
* '''Project name:''' Detailed description of project goes here.<br />
* ''Technical Requirements''<br />
** ''Required Experience:''<br />
** ''Bonus Experience:''<br />
** ''Interests:''<br />
** ''Difficulty:''<br />
** ''Recommended reading:''<br />
<br />
=== Stream Control Transmission Protocol (SCTP) ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br />
<br />
* '''SCTP implementation and testing:''' [http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol 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.<br />
* ''Required Experience:'' C++<br />
* ''Bonus Experience:'' L4 protocols understanding<br />
* ''Interests:'' L4 protocols modeling and simulation<br />
* ''Difficulty:'' medium<br />
* ''Recommended reading:''<br />
** [http://tools.ietf.org/html/rfc3286 RFC 3286] An Introduction to the Stream Control Transmission Protocol<br />
** [http://tools.ietf.org/html/rfc6458 RFC 6458] Sockets API Extensions for the Stream Control Transmission Protocol<br />
** all the relevant RFCs about SCTP<br />
<br />
<br />
=== Neighbor Discovery Optimization for Low Power and Lossy Networks (6LoWPAN-nd) ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br />
<br />
* '''6LoWPAN-nd implementation and testing:''' [http://tools.ietf.org/html/draft-ietf-6lowpan-nd-18 6LoWPAN-nd] is novel draft protocol from IETF's [http://tools.ietf.org/wg/6lowpan/ 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. <br />
* ''Required Experience:'' C++, IPv6<br />
* ''Bonus Experience:'' WSN networking<br />
* ''Interests:'' WSN, IPv6, node bootstrap, efficient packet compression <br />
* ''Difficulty:'' medium<br />
* ''Recommended reading:''<br />
** [http://tools.ietf.org/html/rfc4919 RFC 4919] IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals<br />
** [http://tools.ietf.org/html/draft-ietf-6lowpan-nd-18 6LoWPAN-nd] Neighbor Discovery Optimization for Low Power and Lossy Networks<br />
<br />
<br />
=== Vehicular Ad-hoc Networks ===<br />
<br />
Mentors: [mailto:guillaume.remy@ieee.org Guillaume Rémy]<br />
<br />
* '''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.<br />
** ''Required experience:'' C++.<br />
** ''Bonus experience:'' Wireless networking, WAVE.<br />
** ''Interests:'' Wireless networking, VANETs.<br />
** ''Difficulty:'' medium to hard, depending on what the student proposes to implement.<br />
** ''Recommended reading'' <br />
*** [0] http://www.nsnam.org/bugzilla/show_bug.cgi?id=700#c11<br />
*** [1] http://www.nsnam.org/bugzilla/show_bug.cgi?id=945<br />
*** [2] http://www.nsnam.org/bugzilla/show_bug.cgi?id=978#c16<br />
*** [3] http://www.nsnam.org/bugzilla/attachment.cgi?id=968<br />
<br />
<br />
=== Realistic spatial models for wireless link simulations ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella] [mailto:loulloudes.n@cs.ucy.ac.cy Nicholas Loulloudes]<br />
<br />
* '''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.<br />
* ''Required Experience:'' C++, 3D maps<br />
* ''Bonus Experience:'' radio link caracterization<br />
* ''Interests:'' wireless system realistic simulations<br />
* ''Difficulty:'' medium / hard<br />
* ''Recommended reading:''<br />
** none<br />
<br />
<br />
=== High-level architecture (HLA) interfaces for ns-3 ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br />
<br />
* '''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.<br />
* ''Required Experience:'' C++<br />
* ''Bonus Experience:'' Simulators federation concepts<br />
* ''Interests:'' Complex scenarios simulations<br />
* ''Difficulty:'' hard<br />
* ''Recommended reading:''<br />
** [http://en.wikipedia.org/wiki/High-level_architecture_(simulation) High-level architecture]<br />
** [http://en.wikipedia.org/wiki/Run-Time_Infrastructure_(simulation) Run-Time Infrastructure]<br />
** IEEE 1516-2010 - IEEE Standard for Modeling and Simulation (M&S) High Level Architecture (HLA) -- Framework and Rules<br />
<br />
<br />
=== ns-3 Firewall model ===<br />
<br />
Mentors: [mailto:adrian.sw.tam@gmail.com Adrian S.W. Tam]<br />
<br />
* '''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.<br />
* ''Required Experience:'' C++<br />
* ''Bonus Experience:'' Linux netfilter (iptables)<br />
* ''Interests:'' Network Firewalls<br />
* ''Difficulty:'' medium<br />
* ''Recommended reading:''<br />
** [http://www.netfilter.org/ netfilter.org]<br />
** [http://code.nsnam.org/tomh/ns-3-netfilter/ ns-3-netfilter]<br />
<br />
<br />
=== Node stop / start models ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella] [mailto:rivanvx@gmail.com Vedran Miletić]<br />
<br />
* '''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.<br />
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.<br />
* ''Required Experience:'' C++<br />
* ''Bonus Experience:'' <br />
* ''Interests:'' Node energy management<br />
* ''Difficulty:'' easy / medium<br />
* ''Recommended reading:''<br />
** http://mailman.isi.edu/pipermail/ns-developers/2011-June/009068.html<br />
** http://www.nsnam.org/docs/meetings/november10.txt (item 2)<br />
<br />
=== Network Address and Port Translation (NAT) models ===<br />
<br />
Mentors: [mailto:adrian.sw.tam@gmail.com Adrian S.W. Tam]<br />
<br />
* '''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.<br />
* ''Required Experience:'' C++<br />
* ''Bonus Experience:'' NAT and IPv4 translation tables<br />
* ''Interests:'' NATs and NAT traversal techniques<br />
* ''Difficulty:'' easy / medium<br />
* ''Recommended reading:''<br />
** [http://www.cisco.com/web/about/ac123/ac147/ac174/ac182/about_cisco_ipj_archive_article09186a00800c83ec.html The Trouble with NAT]<br />
** [http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_7-3/anatomy.html Anatomy: A Look Inside Network Address Translators]<br />
** [http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_14-4/144_pcp.html Port Control Protocol]<br />
<br />
<br />
=== Deep Space networking: Licklider Transmission Protocol (LTP) ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella] <br />
<br />
* '''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.<br />
* ''Required Experience:'' C++<br />
* ''Bonus Experience:'' Satellite and Deep Space networking<br />
* ''Interests:'' Deep Space networking<br />
* ''Difficulty:'' easy / medium<br />
* ''Recommended reading:''<br />
** [http://en.wikipedia.org/wiki/Licklider_Transmission_Protocol Licklider Transmission Protocol]<br />
** [http://tools.ietf.org/html/rfc5325 RFC 5325: Licklider Transmission Protocol—Motivation]<br />
** [http://tools.ietf.org/html/rfc5326 RFC 5326: Licklider Transmission Protocol—Specification]<br />
** [http://public.ccsds.org/sites/cwe/rids/Lists/CCSDS%207341R2/Attachments/734x1r2.pdf Licklider Transmission Protocol (LTP) for CCSDS]<br />
<br />
<br />
=== IPv6 stack validation and improvements ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella] <br />
<br />
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. <br /><br />
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):<br />
# There is no [http://en.wikipedia.org/wiki/Path_MTU_discovery path MTU discovery] see also [http://tools.ietf.org/html/rfc1981 RFC 1981].<br />
# Flow Monitor module does not work on the IPv6 stack<br />
# FlowLabel header field is not currenly used<br />
# IPSec is not supported<br />
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.<br />
* ''Required Experience:'' C++, TCP/IP networking<br />
* ''Bonus Experience:'' IPv6 protocols<br />
* ''Interests:'' IPv6 internetworking<br />
* ''Difficulty:'' easy / medium, depending on the features implemented<br />
* ''Recommended reading:''<br />
** [http://www.ietf.org/rfc/rfc4294.txt RFC 4294 - IPv6 Node Requirements]<br />
** [http://tools.ietf.org/html/rfc1981 RFC 1981 - Path MTU Discovery for IP version 6]<br />
** ns-3 Flowmon module documentation<br />
** [http://tools.ietf.org/html/rfc6437 RFC 6437 - IPv6 Flow Label Specification]<br />
** [http://tools.ietf.org/html/rfc4302 RFC 4302 - IP Authentication Header]<br />
** [http://tools.ietf.org/html/rfc4303 RFC 4303 - IP Encapsulating Security Payload (ESP)]<br />
<br />
<br />
=== Deep Space networking: Bundle Protocol (BP) ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella] <br />
<br />
* '''ns-3-BP''' Delay Tolerant Networks (DTN) are a class of networks resilient to either ultra-high delays or link disruptions. Common examples are sensor networks, vehicular networks, military networks and Deep Space networks. To provide the end-to-end network services the DTN protocols, also known as bundle protocols, sit above the link or transport layers of the constituent internets, forming a store-and-forward overlay network. Currently BP has been used for specific projects, but its performances on large-scale topologies is still under evaluation. BP is an application protocol, and should be able to use whatever Layer4 protocol is available, ranging from TCP/IP to LTP. An ns-3 implementation should comply with the already existing IETF specification and with the CCSDS one.<br />
* ''Required Experience:'' C++<br />
* ''Bonus Experience:'' Satellite and Deep Space networking<br />
* ''Interests:'' Deep Space networking<br />
* ''Difficulty:'' easy / medium<br />
* ''Recommended reading:''<br />
** [http://tools.ietf.org/html/rfc4838 RFC 4838: Delay-Tolerant Networking Architecture]<br />
** [http://tools.ietf.org/html/rfc5050 RFC 5050: Bundle Protocol Specification]<br />
** [http://public.ccsds.org/sites/cwe/rids/Lists/CCSDS%207342R1/Attachments/734x2r1.pdf CCSDS Bundle Protocol Specification]<br />
<br />
<br />
=== PackMime-HTTP ===<br />
<br />
Mentors: [mailto:mweigle@cs.odu.edu Michele Weigle]<br />
<br />
* '''PackMime-HTTP:''' PackMime-HTTP is a module for generating synthetic web traffic based on a traffic model developed at Bell Labs. The main parameter controlling traffic intensity is rate, the average number of new TCP connections started each second. The goal of this project is to port the PackMime-HTTP web traffic generation code from ns-2 to ns-3. The implementation of PackMime-HTTP in ns-3 can borrow significantly from the implementation of Tmix in ns-3, as the ns-2 version of Tmix was based on PackMime-HTTP.<br />
* ''Required Experience:'' C++<br />
* ''Bonus Experience:'' knowledge of HTTP, TCP, familiarity with PackMime-HTTP in ns-2<br />
* ''Interests:'' application-level and transport-level modeling and simulation<br />
* ''Difficulty:'' medium<br />
* ''Recommended reading:'' <br />
** [http://www.cs.odu.edu/~mweigle/research/packmime/ packmime]<br />
** Stochastic Models for Generating Synthetic HTTP Source Traffic, J. Cao, W.S. Cleveland, Y. Gao, K. Jeffay, F.D. Smith, and M.C. Weigle, Proceedings of IEEE INFOCOM, Hong Kong, March 2004, available at [http://www.cs.odu.edu/~mweigle/papers/INFOCOM04.pdf INFOCOM04.pdf] <br />
<br />
<br />
=== Tmix and DelayBox ===<br />
<br />
Mentors: [mailto:mweigle@cs.odu.edu Michele Weigle]<br />
<br />
* '''Tmix and DelayBox:''' Tmix is a module for generating synthetic Internet traffic based on collected traces that have been converted into "connection vectors". Much of the implementation has already been completed, but it needs to be validated and updated to work with the latest version of ns-3. Completing this project also includes completing the DelayBox module that Tmix relies on. The implementation of DelayBox in ns-3 has also been started, but not yet fully completed.<br />
* ''Required Experience:'' C++<br />
* ''Bonus Experience:'' knowledge of HTTP, TCP, familiarity with Tmix and DelayBox in ns-2<br />
* ''Interests:'' application-level and transport-level modeling and simulation<br />
* ''Difficulty:'' medium<br />
* ''Recommended reading:'' <br />
** [http://www.cs.odu.edu/inets/Tmix Tmix]<br />
** Michele C. Weigle, Prashanth Adurthi, Felix Hernandez-Campos, Kevin Jeffay and F. Donelson Smith, "Tmix: A Tool for Generating Realistic Application Workloads in ns-2," Computer Communication Review, Vol. 36, No. 3, July 2006, pp. 67-76, available at [http://www.cs.odu.edu/~mweigle/papers/ccr06.pdf ccr06.pdf]<br />
** Prashanth Adurthi and Michele C. Weigle, "Realistic TCP Traffic Generation in ns-2 and GTNetS," Tech Report, June 2006, available at [http://www.cs.odu.edu/~mweigle/papers/adurthi-tmix-TR06.pdf adurthi-tmix-TR06.pdf]<br />
<br />
<br />
=== XORP support by Direct Code Execution ===<br />
<br />
*Mentors: [mailto:tazaki@nict.go.jp Hajime Tazaki]<br />
*'''XORP support by Direct Code Execution''': This project aims to provide the integration of XORP [1] and ns-3 to simulate active running protocol implementation. XORP is an open-source routing protocol implementation that supports various protocols such as OSPF, RIP, BGP, OLSR, VRRP, PIM, IGMP, MLD, etc. Using existing implementation enables us to conduct reliable protocol simulations and help researchers/network operators to reveal the problems of existing network incident, for example. With previous contributions for Direct Code Execution (DCE) [2], XORP could be integrated with necessary system call, library call emulation and helper library to generate configuration file for the execution of XORP protocol implementation.<br />
*Required Experience: C++, C?, debugger experience<br />
*Bonus Experience: network protocol design, implementation, XORP development experience, Routing protocol development<br />
*Interests: routing protocol stack, socket application development<br />
*Difficulty: difficult<br />
*Recommended reading:<br />
** [1] XORP routing protocol suite, http://www.xorp.org/<br />
** [2] Lacage, Experimentation Tools for Networking Research, http://cutebugs.net/files/thesis.pdf<br />
<br />
<br />
=== Sensor Networks Operating System Over ns-3 (Contiki - ns-3) === <br />
<br />
* Mentors: [mailto:daniel.camara@inria.fr Daniel Câmara]<br />
*'''Contiki – ns-3''': [http://www.contiki-os.org Contiki] is a popular open source Operating System for sensor networks. It provides all the functionalities a sensor application could need e.g. access to the sensor hardware, file system, network stack. All that with a really small footprint, and for a series of different platforms. The idea of this project is to be able to use the power of ns-3 to simulate realistic sensor networks running real applications over Contiki. The advantage of this is that developers can test their applications, the real ones, before deploying them on real sensors. The general sensor networks research community can also profit from that, since people will be able to make much more realistic simulations. Simulations will be actually running over the code of a real sensor network operating, powered by ns-3. Simulations will be more realistic and, on contrast to testbeds, they will be fully reproducible and larger scale networks can be easily tested. What could be more attractive to people working on the sensor networks field than being able to follow, and even debug, the whole data exchange process of a massive sensor network from the “comfort” of its preferred debugger? Not only the project is interesting from an engineering point of view, since the idea is to enable the use of a real sensor networks operating system over ns-3, but it can also be extremely useful for the networks community. Contiki is written in C and has a series of well-defined interfaces for enabling the code to run in new sensor architectures. What we intend is to develop a new “sensor architecture” that will be, in fact, a ns-3 node that implements the required interfaces from Contiki. On the other side, we will create a nw-3 sensor node that will run the Contiki OS.<br />
<br />
*Required Experience: C/C++<br />
*Bonus Experience: Sensor networks<br />
*Interests: Sensor networks<br />
*Difficulty: medium<br />
*Recommended reading:<br />
** [http://www.contiki-os.org Contiki] web site - [http://www.contiki-os.org http://www.contiki-os.org]<br />
** [http://www.sics.se/contiki/wiki/index.php/Why_Contiki Why Contiki] - [http://www.sics.se/contiki/wiki/index.php/Why_Contiki http://www.sics.se/contiki/wiki/index.php/Why_Contiki]<br />
** [http://www.sics.se/~adam/dunkels11contikimac.pdf The ContikiMAC Radio Duty Cycling Protocol] - [http://www.sics.se/~adam/dunkels11contikimac.pdf http://www.sics.se/~adam/dunkels11contikimac.pdf]<br />
<br />
<br />
=== Allow ns-3 native applications to use the ns-3-linux linux kernel stack ===<br />
<br />
*Mentors: [mailto:tazaki@nict.go.jp Hajime Tazaki], [mailto:frederic.urbani@inria.fr Frederic Urbani]<br />
*'''Allow ns-3 native applications to use the ns-3-linux linux kernel stack''': Simulating existing implementations without a bunch of modifications (patching) contributes the reality/credibility of the result of simulations. We can avoid re-implementations of the protocols with special version for ns-3 (or nasty #ifdefs). Direct Code Execution (DCE) [1] helps a lot supporting not only POSIX socket applications, but also linux network kernel stack (ns-3-linux) [2] in the ns-3 simulations. It is abstracted as layer 3 protocol implementation on top of ns-3 and has already integrated with existing applications such as Zebra [3], CCNx [4], UMIP [3]. However, existing applications using ns-3 native stack do not benefit this feature because of lack of bridging between ns-3 core and ns-3-linux. This project aims to integrate these two components, ns-3-linux and ns-3 core, to be able to utilize protocols implemented in linux kernel as simulated models.<br />
The design and implementation of this functionality might consist of several directions: <br />
# provide new socket factories to interact with the linux tcp, udp, sctp, etc. sockets.<br />
# introduce new L3protocol classes on top of ns-3-linux implementation to align the other pieces of ns-3 core.<br />
# make this new stack close to other API of ns-3 core so that existing ns-3 applications can run without much pain.<br />
# the bridge provided by this functionality will align the inconsistency of ns-3 core and ns-3-linux. For example of such a inconsistency, assigning an IP address in ns-3 core reflects the state of network stack while ns-3-linux will be configured after Simulator::Run () (see the example of IP address configuration (RunIp function) with ns-3-linux [5])<br />
<br />
*Required Experience: C++, C, Linux Kernel development, ns-3 network stack understandings<br />
*Bonus Experience: network protocol design, implementation, source code reading, debugger experience<br />
*Interests: network stack (L3/L4), kernel development<br />
*Difficulty: difficult<br />
*Recommended reading:<br />
** [1] Lacage, Experimentation Tools for Networking Research, http://cutebugs.net/files/thesis.pdf<br />
** [2] ns-3-linux: http://code.nsnam.org/furbani/ns-3-linux<br />
** [3] NEMO simulation with UMIP and ns-3-dce: http://code.nsnam.org/thehajime/ns-3-dce-quagga-umip/<br />
** [4] NS3 DCE CCNx Quick Start: http://www-sop.inria.fr/members/Frederic.Urbani/ns3dceccnx/<br />
** [5] http://code.nsnam.org/furbani/ns-3-dce/file/310a7c5bd5de/example/dce-linux.cc#l12<br />
<br />
=== INSTOOLS for ns-3 ===<br />
<br />
Mentors: [mailto:tomh@tomh.org Tom Henderson]<br />
<br />
* '''INSTOOLS for ns-3:''' [http://groups.geni.net/geni/wiki/InstrumentationTools 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.<br />
** ''Required Experience:'' Familiarity with Linux networking and with C++ programming. <br />
** ''Bonus Experience:'' Experience with GENI and/or Emulab<br />
** ''Interests:'' Simulator tool development, integration with testbed experiments<br />
** ''Difficulty:'' Medium<br />
** ''Recommended Reading:'' http://groups.geni.net/geni/wiki/InstrumentationTools<br />
<br />
=== ns-3 in the cloud ===<br />
<br />
Mentors: [mailto:tomh@tomh.org Tom Henderson]<br />
<br />
* '''ns-3 in the cloud:''' We want to document how to run ns-3 in [http://aws.amazon.com Amazon Web Services]. The ns-3 project would pay for compute time in the cloud. This project will perform some benchmarks of the cloud services, and look at options for scaling to large ns-3 simulations. This project will use the MPI feature of ns-3 to construct large distributed simulations, and document how to distribute the simulation instances in the cloud. The outcome of this project will be clear documentation for how to use ns-3 in the cloud including the documentation of benchmarking results, and test and example programs that can be run in the cloud.<br />
* ''Required Experience:'' C++ programming<br />
* ''Bonus Experience:'' MPI-based programming<br />
* ''Interests:'' Large-scale simulations, parallel simulations. <br />
* ''Difficulty:'' Medium<br />
* ''Recommended Reading:'' [http://aws.amazon.com/ Amazon Web Services] and [http://www.nsnam.org/docs/release/3.13/models/singlehtml/index.html#document-distributed MPI for ns-3]<br />
<br />
=== LTE Scheduling with the FemtoForum MAC Scheduler API ===<br />
<br />
Mentors: [mailto:nicola.baldo@cttc.es Nicola Baldo], [mailto:marco.miozzo@cttc.es Marco Miozzo]<br />
<br />
* The [http://iptechwiki.cttc.es/LTE-EPC_Network_Simulator_%28LENA%29 ns-3 LTE module released by the LENA project] supports the [http://www.femtoforum.org/femto/technical.php FemtoForum MAC LTE MAC Scheduler Interface Specification] for the implementation of MAC schedulers. Currently, only simple Round Robin and Proportional Fair schedulers are supported. As part of this project, the student should implement one or more scheduling algorithms found in the literature on top of the FemtoForum MAC Scheduler API. A few example algorithms are listed below in the references; however, the choice of the algorithm is left to the student. In any case, we stress that the focus of this project should be on the implementation of an existing and well-defined algorithm (not on the design of a new algorithm). <br />
<br />
** ''Required experience:'' C++<br />
** ''Bonus experience:'' ns-3, 3GPP standards<br />
** ''Interests:'' LTE, dynamic packet scheduling, radio resource management<br />
** ''Difficulty:'' hard<br />
** ''Recommended reading'' <br />
*** [http://mailman.isi.edu/pipermail/ns-developers/2011-March/008734.html ns-3 LTE module released by the LENA project]<br />
*** [http://www.femtoforum.org/femto/technical.php FemtoForum MAC LTE MAC Scheduler Interface Specification]<br />
*** Giuseppe Piro, Luigi Alfredo Grieco, Gennaro Boggia, Rossella Fortuna, and Pietro Camarda, [http://telematics.poliba.it/publications/2011/IEEETMM/PIRO-IEEETMM2011.pdf Two-level downlink scheduling for real-time multimedia services in LTE networks], IEEE Trans. Multimedia, vol. 13, no. 5, pp. 1052 - 1065, Oct., 2011, doi: 10.1109/TMM.2011.2152381 . <br />
*** Stefania Sesia, Matthew P. J. Baker, Issam Toufik, ''Long Term Evolution: from theory to practice'', John Wiley and Sons, 2009<br />
*** B. Sadiq, R. Madan, and A. Sampath, ''Downlink scheduling for multiclass traffic in LTE'', EURASIP Journal on Wireless Communications andNetworking, vol. 2009, Article ID510617, 2009<br />
*** G. Monghal, K. I. Pedersen, I. Z. Kov´acs, and P. E. Mogensen, ''QoS oriented time and frequency domain packet schedulers for the UTRAN long term evolution,'' in Proceedings of the IEEEVehicular Technology Conference (VTC 2008), pp. 2532– 2536, 2008. <br />
*** D. López-Pérez, A. Ladanyi, A. Jüttner, H. Rivano and J. Zhang, ''Optimization Method for the Joint Allocation of Modulation Schemes, Coding Rates, Resource Blocks and Power in Self-Organizing LTE Networks'', IEEE INFOCOM (International Conference on Computer Communications), Shanghai, China, April 2011<br />
<br />
=== Random Mobility in presence of Buildings ===<br />
<br />
Mentors: [mailto:nicola.baldo@cttc.es Nicola Baldo], [mailto:marco.miozzo@cttc.es Marco Miozzo]<br />
<br />
* The ns-3 [http://mailman.isi.edu/pipermail/ns-developers/2012-March/010020.html buildings module] (currently under review for inclusion in ns-3-dev) provides means to simulate the presence of buildings in a wireless network topology, however it currently only support static users. As part of this project, the student should add support for random mobility models that explicitly deal with the presence of buildings.<br />
<br />
** ''Required experience:'' C++<br />
** ''Bonus experience:'' ns-3, mobility models<br />
** ''Interests:'' wireless networks<br />
** ''Difficulty:'' medium<br />
** ''Recommended reading'' <br />
*** [http://lena.cttc.es/buildings/ buildings module documentation]<br />
<br />
<br />
<br />
<br />
<br />
<br />
[[Category:GSoC]]</div>Nicolabaldohttps://www.nsnam.org/mediawiki/index.php?title=DevelMeetingMar2012&diff=6604DevelMeetingMar20122012-03-05T17:00:31Z<p>Nicolabaldo: /* Tentative Attendance */</p>
<hr />
<div>{{TOC}}<br />
<br />
= Location and Schedule =<br />
<br />
At the same hotel as SIMUTools 2012, on Saturday March 24, the day after [http://www.nsnam.org/wns3/wns3-2012/ WNS3]<br />
<br />
* The meeting site is the [http://www.simutools.org/2012/Venue/ConferenceSite same site] as the conference<br />
* The meeting has no registration fees<br />
* The meeting is open to anyone interested<br />
* Arrangements for lunch and coffee are still being investigated.<br />
* The tentative schedule is 09h00-17h00 with lunch break.<br />
* Remote participation (e.g. WebEx and audio) is being investigated.<br />
<br />
= Tentative Attendance =<br />
<br />
If you'd like to attend, please add your name.<br />
<br />
* Tommaso Pecorella (University of Florence)<br />
* Tom Henderson<br />
* Felipe Perrone<br />
* George Riley<br />
* Lalith Suresh<br />
* Peter Barnes<br />
* Nicola Baldo<br />
<br />
= Tentative Topics =<br />
* Memory leaks extermination process, see John Abraham mail: [http://mailman.isi.edu/pipermail/ns-developers/2012-February/009990.html]<br />
* Review ns-3 packaging status (Fedora/Ubuntu), discuss long term support for releases<br />
* Review some emerging products of [http://redmine.eg.bucknell.edu/perrone/projects/framework SAFE]<br />
** Steady state and termination detector (code will be posted in advance of meeting)<br />
** API and architecture for data collection (code will be posted in advance of meeting)<br />
** Experiment execution manager<br />
* Further modularization of ns-3, including moving towards realizing the app store<br />
* Documentation: what are requirements for future merges, and how to define a realistic path to clean up and finish the current codebase<br />
* list netiquette and FAQ. Draft here: https://www.nsnam.org/wiki/index.php/Ns-3-users-netiquette.<br />
* check-style mercurial hook for ns-3-dev<br />
* new [http://mailman.isi.edu/pipermail/ns-developers/2012-January/009789.html Jenkins CI system]: what are the near-term requirements/priorities for this<br />
<br />
= Action Points =</div>Nicolabaldohttps://www.nsnam.org/mediawiki/index.php?title=Current_Development&diff=5839Current Development2011-07-01T15:43:02Z<p>Nicolabaldo: /* the LTE-EPC Network Simulator (LENA) project */</p>
<hr />
<div>{{TOC}}<br />
<br />
On this page, we will try to maintain pointers to current ns-3 development work, and post some suggested project ideas. If you are interested in collaborating on one of these projects, please do not hesitate to contact the individuals identified.<br />
<br />
Much of the current activity is centered around the next release, which is ns-3.12 due in summer 2011. The release page should list code that is under active review for merging: [[Ns-3.12 | ns-3.12 release page]]<br />
<br />
If you are new to ns-3 and want to contribute, please read these guidelines: [http://www.nsnam.org/contributing.html Contributing to ns-3] and review the information on this page below. Please visit our [[Suggested_Projects]] page.<br />
<br />
'''Note:''' ns-3 developers sometimes hang out on IRC at #ns-3 at irc.freenode.net. <br />
<br />
We conduct many of our reviews at http://codereview.appspot.com. <br />
<br />
= Related projects =<br />
<br />
There are several projects under development that are integrating external libraries or frameworks with ns-3.<br />
<br />
== NSF Frameworks for ns-3 project ==<br />
<br />
A multi-year project funded by NSF to improve usability of ns-3. Please see [[NSF_Frameworks]] page.<br />
<br />
== PhySim-Wifi ==<br />
<br />
[http://dsn.tm.uni-karlsruhe.de/english/ns3-physim.php PhySim-Wifi] is a detailed and accurate implementation of the OFDM-based IEEE 802.11 standard, with higher fidelity at the physical layer than found in ns-3.<br />
<br />
== ns-3-Wireless-Planning ==<br />
<br />
[http://code.google.com/p/ns3-wireless-planning/wiki/Tutorial ns-3-Wireless-Planning] integrates two powerful applications: Radio Mobile (radio-systems simulator) and ns-3.<br />
<br />
== Synchronized emulation (Slicetime) ==<br />
<br />
The goal of the [http://www.comsys.rwth-aachen.de/projects/slicetime/ Slicetime] Project is to enable large-scale network emulation features by synchronizing the execution of a network simulator with virtual machines hosting arbitrary networking software. <br />
<br />
== the LTE-EPC Network Simulator (LENA) project ==<br />
<br />
A team of developers at CTTC (Nicola Baldo, Marco Miozzo, Manuel Requena, Jaume Nin) has [http://mailman.isi.edu/pipermail/ns-developers/2011-March/008734.html announced] the LENA (LTE/EPC Network simulAtor) project to be working in collaboration with Ubiquisys on an enhanced LTE module for ns-3.<br />
<br />
Links:<br />
* [http://www.ubiquisys.com/femtocell-media-press-releases-id-203.htm official press release from Ubiquisys' website]<br />
* [http://iptechwiki.cttc.es/LTE-EPC_Network_Simulator_%28LENA%29 Wiki]<br />
* [http://www.cttc.es/en/projects/private/project/lena.jsp official project page at CTTC]<br />
<br />
= Development for main trunk of ns-3 =<br />
<br />
Some of these projects are active, some dormant, but all seem oriented towards merging with the main trunk of ns-3 if they can be finished off.<br />
<br />
== ns-3 core ==<br />
<br />
=== Multi-threaded simulation implementation for multicore ===<br />
<br />
* ''ns-developers post'': http://mailman.isi.edu/pipermail/ns-developers/2009-July/006197.html<br />
* ''code location'': http://code.nsnam.org/guillaume/ns-3-multithreading/<br />
* ''status'': ns-3.11 merge?<br />
<br />
=== Linux namespaces and ns-3 ===<br />
<br />
* ''summary'': Tom Goff has contributed code and documentation about how to use ns-3 with Linux namespaces.<br />
* ''code location'': See the below wiki page.<br />
* ''background'': http://www.nsnam.org/wiki/index.php/HOWTO_use_Linux_namespaces_with_ns-3<br />
* ''status'': Working on integration of this capability with the [http://cs.itd.nrl.navy.mil/work/core/index.php CORE network emulator]. Some form of this will likely be merged with ns-3 and CORE in the future. <br />
<br />
== Device and channel models ==<br />
<br />
=== Miscellaneous wifi enhancements ===<br />
<br />
* ''code location'': http://codereview.appspot.com/65051<br />
* ''reviewer(s)'': Mathieu Lacage<br />
* ''status'': Some of these pieces made it into ns-3.5-- others are pending<br />
* ''background'': http://groups.google.com/group/ns-3-reviews/browse_thread/thread/f0b36d7373421a7d#<br />
<br />
=== Patch to pause and resume an interface ===<br />
<br />
* ''code location'': http://codereview.appspot.com/62054<br />
* ''reviewer(s)'': TBD<br />
* ''status'':<br />
<br />
=== 802.11 model extensions ===<br />
<br />
There are several efforts ongoing to extend the ns-3 Wifi model.<br />
<br />
==== Harmonization with ns-2 802.11 Ext models ====<br />
* ''summary'': ns-2.33 added a new 802.11 model with much more detailed channel modeling. An effort has been started to port over reusable components from that implementation to ns-3's wifi model, while reusing already implemented basic components. The goal is a harmonization of the 802.11 models of ns-2 and ns-3. Leading aim is to support research on vehicular networks. Planned near-term features:<br />
** Equalizing PHY models including capture effects, user-definable coding rates (e.g. 5.9 GHz from 802.11p)<br />
** EDCA QoS extensions of 802.11e<br />
* Already finished features:<br />
** Nakagami/Rayleigh propagation loss model<br />
* ''ns-developers post'': http://mailman.isi.edu/pipermail/ns-developers/2008-November/004936.html<br />
* ''code location'': http://idlebox.net/2008/ns-3-wifi/code/ns-3-wifiex/<br />
* ''status'': under current active development. Time frame till this is completed: 4-5 month.<br />
<br />
==== 802.11n ====<br />
<br />
* ''summary'': University of Florence (LART lab) has begun work on an 802.11n model for ns3. The main goal is to simulate the frame aggregation feature. In the future, they aim to implement the High Throughput terminal behaviour with MIMO technology. They plan to add, to ns-3's 802.11 model, the following 802.11n features:<br />
** Frame Aggregation<br />
** Block ACK<br />
** HCF (EDCA and support for HCCA)<br />
** TXOP<br />
** HT terminal (also with protection modes)<br />
** MIMO<br />
Also interested to verify the 11n terminal throughput when are associated terminal of a/b/g standards.<br />
* Already finished features (in ns-3.5):<br />
** HCF, TXOP, Frame Aggregation<br />
* Merged for ns-3.8:<br />
** Block ACK<br />
* ''code location'': http://code.nsnam.org/mirko/ns-3-80211n<br />
* ''status'': Frame aggregation and block ack merged already; Tommaso Pecorella announced his lab's next steps [http://mailman.isi.edu/pipermail/ns-developers/2010-August/008303.html here]<br />
<br />
=== Wireless Interference (Jamming) Model ===<br />
<br />
* ''summary'': [http://www.ee.washington.edu/research/nsl/faculty/radha/ Network Security Lab (NSL)], University of Washington, Seattle has begun work on a wireless interference (jamming) model for ns3. The goal is to to enable researchers to use ns3 to study jamming and its mitigation methods.<br />
* ''wiki page'': http://www.nsnam.org/wiki/index.php/NS-3_wireless_jamming_model<br />
* ''code location'': http://codereview.appspot.com/1055041/show<br />
* ''status'': Public review.<br />
<br />
=== Vehicular Ad Hoc Networks (VANET) ===<br />
<br />
* ''summary'': Michele Weigle's group is working on VANET and has posted a patch for review in the past, but has taken it off the table for ns-3 merge consideration until more work is done.<br />
* ''code location'': None publicly posted at this time.<br />
<br />
=== ns-3, 802.15.4 + 6LoWPAN ===<br />
<br />
Tommaso Pecorella announced his plans [http://mailman.isi.edu/pipermail/ns-developers/2010-August/008304.html here]<br />
<br />
Current status is:<br />
* RPL implementation (storing, multicast): almost finished, will be posted for public discussion soon.<br />
** RPL is based on [http://tools.ietf.org/wg/roll/ draft-ietf-roll-rpl-18]<br />
** metrics implemented are of0 and minrank-hysteresis-of<br />
* 6LoWPAN implementation: estimated to be completed in march-april<br />
* 802.15.4: working on it, can't really say right now.<br />
<br />
Boeing is working on lr-wpan (IEEE 802.15.4-2006) support; details [[lr-wpan | here]].<br />
<br />
=== LTE ===<br />
<br />
In addition to the LENA project above, several developers expressed their interest in enhancing the LTE code initially developed within the GSoC 2010:<br />
<br />
* Leo Razoumov [http://mailman.isi.edu/pipermail/ns-developers/2010-November/008467.html announced] possible interest in the following contributions:<br />
** MIMO<br />
** PHY model abstractions<br />
** scheduling models<br />
** mobility and traffic models <br />
* Giuseppe Piro and his group (DEE, Politecnico di Bari) [http://mailman.isi.edu/pipermail/ns-developers/2010-November/008469.html announced] the intent to continue with the development of the LTE module, focusing mainly on the following MAC layer aspects:<br />
** RRM<br />
** scheduling<br />
** AMC<br />
* Marco Mezzavilla and his group (DEI, University of Padova) [http://mailman.isi.edu/pipermail/ns-developers/2010-November/008483.html announced] interest in working on the following:<br />
** MAC layer<br />
** mobility<br />
** traffic modelization<br />
** MIMO<br />
and have posted a repository in February 2011 [http://mailman.isi.edu/pipermail/ns-developers/2011-February/008653.html details here].<br />
<br />
== Link layer ==<br />
<br />
=== 802.21 media independent handover ===<br />
<br />
* ''wiki page'': http://www.nsnam.org/wiki/index.php/NS-3_MIH_implementation<br />
* ''code location'': http://code.nsnam.org/salumu/ns-3-mih/<br />
* ''status'': Dormant-- no merge plans announced.<br />
<br />
== MPLS ==<br />
<br />
* ''Submitted by'': Andrey Churin<br />
* ''code location'': http://code.google.com/p/ns-3-shop/<br />
* ''reviewer(s)'': None<br />
* ''status'': Project has moved to Google hosting. <br />
<br />
== Network layer ==<br />
<br />
=== IPv4 fragmentation ===<br />
<br />
there are two implementations being reviewed:<br />
* http://codereview.appspot.com/4440051/<br />
* http://mailman.isi.edu/pipermail/ns-developers/2011-April/008850.html<br />
<br />
=== IPv6 for ns-3 ===<br />
<br />
Note: the below is stale information but is kept in case it is useful for future developers. The below ns-3-ipv6-2nd is not on the current roadmap for merge to ns-3-dev. There are two groups working on implementing transport for IPv6 (see bug 1045). <br />
<br />
* ''summary'': Ipv6 support for ns-3<br />
* ''ns-developers post'': http://mailman.isi.edu/pipermail/ns-developers/2008-June/004283.html<br />
* ''code location'': hg clone https://svnet.u-strasbg.fr/hg/ns-3-ipv6-2nd/<br />
* ''status'': ns-3.3 contains the first merge (Ipv6Address) of this code. ns-3.7 and ns-3.8 will continue to add features. Here is a tentative roadmap: http://mailman.isi.edu/pipermail/ns-developers/2009-July/006211.html<br />
<br />
=== API and functionality for marking TOS bytes in packets ===<br />
<br />
* ''Submitted by:'' Antti Makela<br />
* ''code location:'' http://www.nsnam.org/bugzilla/show_bug.cgi?id=897<br />
* ''reviewer(s):'' None<br />
* ''status:'' Need to consider whether this fits into the Linux netfilter support that is planned<br />
<br />
=== DSR routing ===<br />
<br />
* ''Submitted by:'' Yufei Cheng<br />
* ''status:'' Announced here: http://mailman.isi.edu/pipermail/ns-developers/2010-December/008496.html<br />
<br />
=== DSDV routing ===<br />
<br />
* ''Submitted by:'' Hemanth Narra<br />
* ''code location:'' http://codereview.appspot.com/1668042/show<br />
* ''status:'' Announced here: http://mailman.isi.edu/pipermail/ns-developers/2010-December/008496.html<br />
<br />
== Transport layer ==<br />
<br />
=== TCP Vegas ===<br />
<br />
* ''Submitted by:'' Juan Pablo Poujade<br />
* ''code location:'' http://mailman.isi.edu/pipermail/ns-developers/2010-February/007419.html<br />
* ''reviewers:'' none officially<br />
* ''status:'' Waiting for guidance on how TCP congestion control variants will be implemented in general<br />
<br />
=== Multipath TCP ===<br />
<br />
NS-3 module for [http://datatracker.ietf.org/wg/mptcp/charter/ MPTCP] (Multipath TCP). The current release is compatible with 3.8 version of NS-3.<br />
A check of the compatibility with the latest version is needed.<br />
<br />
* ''Submitted by:'' Bachir CHIHANI<br />
* ''code location:'' http://code.google.com/p/mptcp-ns3/<br />
<br />
== Application layer ==<br />
<br />
=== Chord/DHash DHT ===<br />
<br />
* ''Submitted by'': Harjot Gill<br />
* ''code location:'' http://codereview.appspot.com/180107/show<br />
* ''reviewers:'' Mathieu Lacage, Tom Henderson<br />
* ''background:'' http://mailman.isi.edu/pipermail/ns-developers/2009-December/007222.html<br />
* ''status:'' Dormant for a while<br />
<br />
=== Synchronous posix/sockets API ===<br />
<br />
* ''summary'': An ns-3 "process" environment<br />
* ''ns-developers post'': http://mailman.isi.edu/pipermail/ns-developers/2008-April/003912.html<br />
* ''code location'': http://code.nsnam.org/mathieu/ns-3-simu<br />
* ''status'': still in development<br />
<br />
=== real-world application integration ===<br />
<br />
* ''summary'': port of quagga routing to ns-3<br />
* ''wiki page'': http://www.nsnam.org/wiki/index.php/Real_World_Application_Integration<br />
* ''code location'': http://code.nsnam.org/lj/quagga-porting/<br />
* ''status'': Was developed by Liu Jian, Google Summer of Code. Portions of this code are planned for a future release (ns-3.8 or later) when ns-3-simu is merged.<br />
<br />
=== ns-3-simu sockopt patches ===<br />
<br />
* ''code location'': Four patches listed in http://mailman.isi.edu/pipermail/ns-developers/2009-June/006144.html<br />
* ''reviewer(s)'': TBD<br />
* ''status'': review requested on June 22<br />
* ''background'': http://mailman.isi.edu/pipermail/ns-developers/2009-June/006144.html<br />
<br />
=== Pastry ===<br />
<br />
* ''Summary:'' An implementation of [http://www.freepastry.org/ Pastry] within ns-3. Including some experimental key-based routing API.<br />
* ''Developers:'' Robert Nitsch and Dominic Scheurer ([https://www.tu-darmstadt.de/ Technische Universität Darmstadt]).<br />
* ''Code location:'' https://bitbucket.org/r_nitsch/libpastry/<br />
* ''Doxygen documentation:'' http://libpastry.robertnitsch.de<br />
* ''Status:''<br />
** Mostly finished.<br />
** Not using ns-3 coding style consistently yet (this will be the easiest issue to fix).<br />
** Node arrival process needs some tweaking.<br />
** Review needed. (We're going to request one as soon as we're ready.)<br />
<br />
== Visualization ==<br />
<br />
Jeremy Norman and the iNSpect team have posted some plans for a visualization library for ns-3:<br />
* http://mailman.isi.edu/pipermail/ns-developers/2008-March/003777.html<br />
* http://mailman.isi.edu/pipermail/ns-developers/2008-November/004914.html<br />
<br />
George Riley has made a [[NetAnim | prototype animator]] for PointToPoint links.<br />
<br />
Joe Kopena is working on what he calls a "decorator" http://code.nsnam.org/tjkopena/<br />
<br />
Hagen Paul Pfeifer is working on a MANET visualizer http://nv.dev.jauu.net/<br />
<br />
=== Graphical simulation builder ===<br />
<br />
Pierre Weiss and Sebastien Vincent have written an [[Ns3Generator| ns-3 scenario generator]] in Qt. <br />
* http://mailman.isi.edu/pipermail/ns-developers/2010-May/007998.html<br />
* Mercurial download: http://svnet.u-strasbg.fr/hg/ns-3-generator/<br />
<br />
=== NetExplorer ===<br />
<br />
[http://code.google.com/p/ns-3-shop/wiki/NetExplorer | NetExplorer] is Gnome/Gtk network animation tool for NS-3. <br />
<br />
== Miscellaneous == <br />
<br />
=== L2 Ethernet switch module ===<br />
<br />
* ''ns-developers post'': http://groups.google.com/group/ns-3-users/browse_thread/thread/0091ac611dde1928#<br />
* ''status'': No code yet, starting development.<br />
<br />
=== Parallel simulations (2008) ===<br />
<br />
* ''summary'': ns-3 extensions for parallelization<br />
* ''wiki page'': http://www.nsnam.org/wiki/index.php/Parallel_Simulations<br />
* ''code location'': http://code.nsnam.org/pfeifer/ns-3-para/<br />
* ''status'': dormant since 2008 Google Summer of Code<br />
<br />
=== Delay Box for ns-3 ===<br />
<br />
Matt Crinklaw is working on a port of ns-2 DelayBox to ns-3.<br />
* ''summary'': http://www.isi.edu/nsnam/ns/doc/node247.html (from ns-2 documentation)<br />
* ''code location'': http://freehg.org/u/mlaw<br />
* ''status'': No status update recently. Dormant.<br />
<br />
=== Simulation Configuration and State Detection ===<br />
<br />
In order to configure simulations across multiple, probably virtualized, machines a large amount of configuration must be performed in order to construct the component systems. The oppportunity for human error to creep in during this process renders it essentially manually unworkable for all but the simplest topologies. Craig Dowell is thinking about how to address this problem.<br />
<br />
[[SimulationConfiguration | Simulation Configuration]]<br />
<br />
= Build system and project infrastructure =<br />
<br />
== Modular build and package management ==<br />
<br />
This issue is being tracked (requirements and wish list) on [[App_Store_Technical_Requirements | this page]]<br />
<br />
== State of Doxygen ==<br />
<br />
Need to bring Doxygen into compliance (no errors, no warnings for missing documentation).<br />
<br />
== Buildbots ==<br />
<br />
* investigate hooking code coverage (lcov) into the report<br />
* investigate how the whole buildbot farm may be made available to a maintainer to test out a non-ns-3-dev repo. <br />
<br />
== Code contribution guidance ==<br />
<br />
Tom took action item to simplify and clarify the project code contribution guidelines (for people wishing to contribute new code to ns-3).<br />
<br />
== Samples directory ==<br />
<br />
Consider cleanup and move of samples/ directory to examples/?<br />
<br />
== Documentation ==<br />
<br />
Considering to refactor documentation to split the existing manual into a model library and a software core reference manual, to add a lighter-weight tutorial, and to add a "cookbook" of howtos for common ns-3 tasks.<br />
<br />
== Website ==<br />
<br />
Status: INRIA is organizing some updates to the website.</div>Nicolabaldohttps://www.nsnam.org/mediawiki/index.php?title=Current_Development&diff=5838Current Development2011-07-01T15:40:47Z<p>Nicolabaldo: /* LENA */</p>
<hr />
<div>{{TOC}}<br />
<br />
On this page, we will try to maintain pointers to current ns-3 development work, and post some suggested project ideas. If you are interested in collaborating on one of these projects, please do not hesitate to contact the individuals identified.<br />
<br />
Much of the current activity is centered around the next release, which is ns-3.12 due in summer 2011. The release page should list code that is under active review for merging: [[Ns-3.12 | ns-3.12 release page]]<br />
<br />
If you are new to ns-3 and want to contribute, please read these guidelines: [http://www.nsnam.org/contributing.html Contributing to ns-3] and review the information on this page below. Please visit our [[Suggested_Projects]] page.<br />
<br />
'''Note:''' ns-3 developers sometimes hang out on IRC at #ns-3 at irc.freenode.net. <br />
<br />
We conduct many of our reviews at http://codereview.appspot.com. <br />
<br />
= Related projects =<br />
<br />
There are several projects under development that are integrating external libraries or frameworks with ns-3.<br />
<br />
== NSF Frameworks for ns-3 project ==<br />
<br />
A multi-year project funded by NSF to improve usability of ns-3. Please see [[NSF_Frameworks]] page.<br />
<br />
== PhySim-Wifi ==<br />
<br />
[http://dsn.tm.uni-karlsruhe.de/english/ns3-physim.php PhySim-Wifi] is a detailed and accurate implementation of the OFDM-based IEEE 802.11 standard, with higher fidelity at the physical layer than found in ns-3.<br />
<br />
== ns-3-Wireless-Planning ==<br />
<br />
[http://code.google.com/p/ns3-wireless-planning/wiki/Tutorial ns-3-Wireless-Planning] integrates two powerful applications: Radio Mobile (radio-systems simulator) and ns-3.<br />
<br />
== Synchronized emulation (Slicetime) ==<br />
<br />
The goal of the [http://www.comsys.rwth-aachen.de/projects/slicetime/ Slicetime] Project is to enable large-scale network emulation features by synchronizing the execution of a network simulator with virtual machines hosting arbitrary networking software. <br />
<br />
== the LTE-EPC Network Simulator (LENA) project ==<br />
<br />
A team of developers at CTTC (Nicola Baldo, Marco Miozzo, Manuel Requena, Jaume Nin) has [http://mailman.isi.edu/pipermail/ns-developers/2010-November/008461.html announced] the LENA (LTE/EPC Network simulAtor) project to be working in collaboration with Ubiquisys on an enhanced LTE module for ns-3.<br />
<br />
Links:<br />
* [http://www.ubiquisys.com/femtocell-media-press-releases-id-203.htm official press release from Ubiquisys' website]<br />
* [http://iptechwiki.cttc.es/LTE-EPC_Network_Simulator_%28LENA%29 Wiki]<br />
* [http://www.cttc.es/en/projects/private/project/lena.jsp official project page at CTTC]<br />
<br />
= Development for main trunk of ns-3 =<br />
<br />
Some of these projects are active, some dormant, but all seem oriented towards merging with the main trunk of ns-3 if they can be finished off.<br />
<br />
== ns-3 core ==<br />
<br />
=== Multi-threaded simulation implementation for multicore ===<br />
<br />
* ''ns-developers post'': http://mailman.isi.edu/pipermail/ns-developers/2009-July/006197.html<br />
* ''code location'': http://code.nsnam.org/guillaume/ns-3-multithreading/<br />
* ''status'': ns-3.11 merge?<br />
<br />
=== Linux namespaces and ns-3 ===<br />
<br />
* ''summary'': Tom Goff has contributed code and documentation about how to use ns-3 with Linux namespaces.<br />
* ''code location'': See the below wiki page.<br />
* ''background'': http://www.nsnam.org/wiki/index.php/HOWTO_use_Linux_namespaces_with_ns-3<br />
* ''status'': Working on integration of this capability with the [http://cs.itd.nrl.navy.mil/work/core/index.php CORE network emulator]. Some form of this will likely be merged with ns-3 and CORE in the future. <br />
<br />
== Device and channel models ==<br />
<br />
=== Miscellaneous wifi enhancements ===<br />
<br />
* ''code location'': http://codereview.appspot.com/65051<br />
* ''reviewer(s)'': Mathieu Lacage<br />
* ''status'': Some of these pieces made it into ns-3.5-- others are pending<br />
* ''background'': http://groups.google.com/group/ns-3-reviews/browse_thread/thread/f0b36d7373421a7d#<br />
<br />
=== Patch to pause and resume an interface ===<br />
<br />
* ''code location'': http://codereview.appspot.com/62054<br />
* ''reviewer(s)'': TBD<br />
* ''status'':<br />
<br />
=== 802.11 model extensions ===<br />
<br />
There are several efforts ongoing to extend the ns-3 Wifi model.<br />
<br />
==== Harmonization with ns-2 802.11 Ext models ====<br />
* ''summary'': ns-2.33 added a new 802.11 model with much more detailed channel modeling. An effort has been started to port over reusable components from that implementation to ns-3's wifi model, while reusing already implemented basic components. The goal is a harmonization of the 802.11 models of ns-2 and ns-3. Leading aim is to support research on vehicular networks. Planned near-term features:<br />
** Equalizing PHY models including capture effects, user-definable coding rates (e.g. 5.9 GHz from 802.11p)<br />
** EDCA QoS extensions of 802.11e<br />
* Already finished features:<br />
** Nakagami/Rayleigh propagation loss model<br />
* ''ns-developers post'': http://mailman.isi.edu/pipermail/ns-developers/2008-November/004936.html<br />
* ''code location'': http://idlebox.net/2008/ns-3-wifi/code/ns-3-wifiex/<br />
* ''status'': under current active development. Time frame till this is completed: 4-5 month.<br />
<br />
==== 802.11n ====<br />
<br />
* ''summary'': University of Florence (LART lab) has begun work on an 802.11n model for ns3. The main goal is to simulate the frame aggregation feature. In the future, they aim to implement the High Throughput terminal behaviour with MIMO technology. They plan to add, to ns-3's 802.11 model, the following 802.11n features:<br />
** Frame Aggregation<br />
** Block ACK<br />
** HCF (EDCA and support for HCCA)<br />
** TXOP<br />
** HT terminal (also with protection modes)<br />
** MIMO<br />
Also interested to verify the 11n terminal throughput when are associated terminal of a/b/g standards.<br />
* Already finished features (in ns-3.5):<br />
** HCF, TXOP, Frame Aggregation<br />
* Merged for ns-3.8:<br />
** Block ACK<br />
* ''code location'': http://code.nsnam.org/mirko/ns-3-80211n<br />
* ''status'': Frame aggregation and block ack merged already; Tommaso Pecorella announced his lab's next steps [http://mailman.isi.edu/pipermail/ns-developers/2010-August/008303.html here]<br />
<br />
=== Wireless Interference (Jamming) Model ===<br />
<br />
* ''summary'': [http://www.ee.washington.edu/research/nsl/faculty/radha/ Network Security Lab (NSL)], University of Washington, Seattle has begun work on a wireless interference (jamming) model for ns3. The goal is to to enable researchers to use ns3 to study jamming and its mitigation methods.<br />
* ''wiki page'': http://www.nsnam.org/wiki/index.php/NS-3_wireless_jamming_model<br />
* ''code location'': http://codereview.appspot.com/1055041/show<br />
* ''status'': Public review.<br />
<br />
=== Vehicular Ad Hoc Networks (VANET) ===<br />
<br />
* ''summary'': Michele Weigle's group is working on VANET and has posted a patch for review in the past, but has taken it off the table for ns-3 merge consideration until more work is done.<br />
* ''code location'': None publicly posted at this time.<br />
<br />
=== ns-3, 802.15.4 + 6LoWPAN ===<br />
<br />
Tommaso Pecorella announced his plans [http://mailman.isi.edu/pipermail/ns-developers/2010-August/008304.html here]<br />
<br />
Current status is:<br />
* RPL implementation (storing, multicast): almost finished, will be posted for public discussion soon.<br />
** RPL is based on [http://tools.ietf.org/wg/roll/ draft-ietf-roll-rpl-18]<br />
** metrics implemented are of0 and minrank-hysteresis-of<br />
* 6LoWPAN implementation: estimated to be completed in march-april<br />
* 802.15.4: working on it, can't really say right now.<br />
<br />
Boeing is working on lr-wpan (IEEE 802.15.4-2006) support; details [[lr-wpan | here]].<br />
<br />
=== LTE ===<br />
<br />
In addition to the LENA project above, several developers expressed their interest in enhancing the LTE code initially developed within the GSoC 2010:<br />
<br />
* Leo Razoumov [http://mailman.isi.edu/pipermail/ns-developers/2010-November/008467.html announced] possible interest in the following contributions:<br />
** MIMO<br />
** PHY model abstractions<br />
** scheduling models<br />
** mobility and traffic models <br />
* Giuseppe Piro and his group (DEE, Politecnico di Bari) [http://mailman.isi.edu/pipermail/ns-developers/2010-November/008469.html announced] the intent to continue with the development of the LTE module, focusing mainly on the following MAC layer aspects:<br />
** RRM<br />
** scheduling<br />
** AMC<br />
* Marco Mezzavilla and his group (DEI, University of Padova) [http://mailman.isi.edu/pipermail/ns-developers/2010-November/008483.html announced] interest in working on the following:<br />
** MAC layer<br />
** mobility<br />
** traffic modelization<br />
** MIMO<br />
and have posted a repository in February 2011 [http://mailman.isi.edu/pipermail/ns-developers/2011-February/008653.html details here].<br />
<br />
== Link layer ==<br />
<br />
=== 802.21 media independent handover ===<br />
<br />
* ''wiki page'': http://www.nsnam.org/wiki/index.php/NS-3_MIH_implementation<br />
* ''code location'': http://code.nsnam.org/salumu/ns-3-mih/<br />
* ''status'': Dormant-- no merge plans announced.<br />
<br />
== MPLS ==<br />
<br />
* ''Submitted by'': Andrey Churin<br />
* ''code location'': http://code.google.com/p/ns-3-shop/<br />
* ''reviewer(s)'': None<br />
* ''status'': Project has moved to Google hosting. <br />
<br />
== Network layer ==<br />
<br />
=== IPv4 fragmentation ===<br />
<br />
there are two implementations being reviewed:<br />
* http://codereview.appspot.com/4440051/<br />
* http://mailman.isi.edu/pipermail/ns-developers/2011-April/008850.html<br />
<br />
=== IPv6 for ns-3 ===<br />
<br />
Note: the below is stale information but is kept in case it is useful for future developers. The below ns-3-ipv6-2nd is not on the current roadmap for merge to ns-3-dev. There are two groups working on implementing transport for IPv6 (see bug 1045). <br />
<br />
* ''summary'': Ipv6 support for ns-3<br />
* ''ns-developers post'': http://mailman.isi.edu/pipermail/ns-developers/2008-June/004283.html<br />
* ''code location'': hg clone https://svnet.u-strasbg.fr/hg/ns-3-ipv6-2nd/<br />
* ''status'': ns-3.3 contains the first merge (Ipv6Address) of this code. ns-3.7 and ns-3.8 will continue to add features. Here is a tentative roadmap: http://mailman.isi.edu/pipermail/ns-developers/2009-July/006211.html<br />
<br />
=== API and functionality for marking TOS bytes in packets ===<br />
<br />
* ''Submitted by:'' Antti Makela<br />
* ''code location:'' http://www.nsnam.org/bugzilla/show_bug.cgi?id=897<br />
* ''reviewer(s):'' None<br />
* ''status:'' Need to consider whether this fits into the Linux netfilter support that is planned<br />
<br />
=== DSR routing ===<br />
<br />
* ''Submitted by:'' Yufei Cheng<br />
* ''status:'' Announced here: http://mailman.isi.edu/pipermail/ns-developers/2010-December/008496.html<br />
<br />
=== DSDV routing ===<br />
<br />
* ''Submitted by:'' Hemanth Narra<br />
* ''code location:'' http://codereview.appspot.com/1668042/show<br />
* ''status:'' Announced here: http://mailman.isi.edu/pipermail/ns-developers/2010-December/008496.html<br />
<br />
== Transport layer ==<br />
<br />
=== TCP Vegas ===<br />
<br />
* ''Submitted by:'' Juan Pablo Poujade<br />
* ''code location:'' http://mailman.isi.edu/pipermail/ns-developers/2010-February/007419.html<br />
* ''reviewers:'' none officially<br />
* ''status:'' Waiting for guidance on how TCP congestion control variants will be implemented in general<br />
<br />
=== Multipath TCP ===<br />
<br />
NS-3 module for [http://datatracker.ietf.org/wg/mptcp/charter/ MPTCP] (Multipath TCP). The current release is compatible with 3.8 version of NS-3.<br />
A check of the compatibility with the latest version is needed.<br />
<br />
* ''Submitted by:'' Bachir CHIHANI<br />
* ''code location:'' http://code.google.com/p/mptcp-ns3/<br />
<br />
== Application layer ==<br />
<br />
=== Chord/DHash DHT ===<br />
<br />
* ''Submitted by'': Harjot Gill<br />
* ''code location:'' http://codereview.appspot.com/180107/show<br />
* ''reviewers:'' Mathieu Lacage, Tom Henderson<br />
* ''background:'' http://mailman.isi.edu/pipermail/ns-developers/2009-December/007222.html<br />
* ''status:'' Dormant for a while<br />
<br />
=== Synchronous posix/sockets API ===<br />
<br />
* ''summary'': An ns-3 "process" environment<br />
* ''ns-developers post'': http://mailman.isi.edu/pipermail/ns-developers/2008-April/003912.html<br />
* ''code location'': http://code.nsnam.org/mathieu/ns-3-simu<br />
* ''status'': still in development<br />
<br />
=== real-world application integration ===<br />
<br />
* ''summary'': port of quagga routing to ns-3<br />
* ''wiki page'': http://www.nsnam.org/wiki/index.php/Real_World_Application_Integration<br />
* ''code location'': http://code.nsnam.org/lj/quagga-porting/<br />
* ''status'': Was developed by Liu Jian, Google Summer of Code. Portions of this code are planned for a future release (ns-3.8 or later) when ns-3-simu is merged.<br />
<br />
=== ns-3-simu sockopt patches ===<br />
<br />
* ''code location'': Four patches listed in http://mailman.isi.edu/pipermail/ns-developers/2009-June/006144.html<br />
* ''reviewer(s)'': TBD<br />
* ''status'': review requested on June 22<br />
* ''background'': http://mailman.isi.edu/pipermail/ns-developers/2009-June/006144.html<br />
<br />
=== Pastry ===<br />
<br />
* ''Summary:'' An implementation of [http://www.freepastry.org/ Pastry] within ns-3. Including some experimental key-based routing API.<br />
* ''Developers:'' Robert Nitsch and Dominic Scheurer ([https://www.tu-darmstadt.de/ Technische Universität Darmstadt]).<br />
* ''Code location:'' https://bitbucket.org/r_nitsch/libpastry/<br />
* ''Doxygen documentation:'' http://libpastry.robertnitsch.de<br />
* ''Status:''<br />
** Mostly finished.<br />
** Not using ns-3 coding style consistently yet (this will be the easiest issue to fix).<br />
** Node arrival process needs some tweaking.<br />
** Review needed. (We're going to request one as soon as we're ready.)<br />
<br />
== Visualization ==<br />
<br />
Jeremy Norman and the iNSpect team have posted some plans for a visualization library for ns-3:<br />
* http://mailman.isi.edu/pipermail/ns-developers/2008-March/003777.html<br />
* http://mailman.isi.edu/pipermail/ns-developers/2008-November/004914.html<br />
<br />
George Riley has made a [[NetAnim | prototype animator]] for PointToPoint links.<br />
<br />
Joe Kopena is working on what he calls a "decorator" http://code.nsnam.org/tjkopena/<br />
<br />
Hagen Paul Pfeifer is working on a MANET visualizer http://nv.dev.jauu.net/<br />
<br />
=== Graphical simulation builder ===<br />
<br />
Pierre Weiss and Sebastien Vincent have written an [[Ns3Generator| ns-3 scenario generator]] in Qt. <br />
* http://mailman.isi.edu/pipermail/ns-developers/2010-May/007998.html<br />
* Mercurial download: http://svnet.u-strasbg.fr/hg/ns-3-generator/<br />
<br />
=== NetExplorer ===<br />
<br />
[http://code.google.com/p/ns-3-shop/wiki/NetExplorer | NetExplorer] is Gnome/Gtk network animation tool for NS-3. <br />
<br />
== Miscellaneous == <br />
<br />
=== L2 Ethernet switch module ===<br />
<br />
* ''ns-developers post'': http://groups.google.com/group/ns-3-users/browse_thread/thread/0091ac611dde1928#<br />
* ''status'': No code yet, starting development.<br />
<br />
=== Parallel simulations (2008) ===<br />
<br />
* ''summary'': ns-3 extensions for parallelization<br />
* ''wiki page'': http://www.nsnam.org/wiki/index.php/Parallel_Simulations<br />
* ''code location'': http://code.nsnam.org/pfeifer/ns-3-para/<br />
* ''status'': dormant since 2008 Google Summer of Code<br />
<br />
=== Delay Box for ns-3 ===<br />
<br />
Matt Crinklaw is working on a port of ns-2 DelayBox to ns-3.<br />
* ''summary'': http://www.isi.edu/nsnam/ns/doc/node247.html (from ns-2 documentation)<br />
* ''code location'': http://freehg.org/u/mlaw<br />
* ''status'': No status update recently. Dormant.<br />
<br />
=== Simulation Configuration and State Detection ===<br />
<br />
In order to configure simulations across multiple, probably virtualized, machines a large amount of configuration must be performed in order to construct the component systems. The oppportunity for human error to creep in during this process renders it essentially manually unworkable for all but the simplest topologies. Craig Dowell is thinking about how to address this problem.<br />
<br />
[[SimulationConfiguration | Simulation Configuration]]<br />
<br />
= Build system and project infrastructure =<br />
<br />
== Modular build and package management ==<br />
<br />
This issue is being tracked (requirements and wish list) on [[App_Store_Technical_Requirements | this page]]<br />
<br />
== State of Doxygen ==<br />
<br />
Need to bring Doxygen into compliance (no errors, no warnings for missing documentation).<br />
<br />
== Buildbots ==<br />
<br />
* investigate hooking code coverage (lcov) into the report<br />
* investigate how the whole buildbot farm may be made available to a maintainer to test out a non-ns-3-dev repo. <br />
<br />
== Code contribution guidance ==<br />
<br />
Tom took action item to simplify and clarify the project code contribution guidelines (for people wishing to contribute new code to ns-3).<br />
<br />
== Samples directory ==<br />
<br />
Consider cleanup and move of samples/ directory to examples/?<br />
<br />
== Documentation ==<br />
<br />
Considering to refactor documentation to split the existing manual into a model library and a software core reference manual, to add a lighter-weight tutorial, and to add a "cookbook" of howtos for common ns-3 tasks.<br />
<br />
== Website ==<br />
<br />
Status: INRIA is organizing some updates to the website.</div>Nicolabaldohttps://www.nsnam.org/mediawiki/index.php?title=HOWTO_determine_the_path_of_an_attribute_or_trace_source&diff=5837HOWTO determine the path of an attribute or trace source2011-06-30T14:12:07Z<p>Nicolabaldo: </p>
<hr />
<div>==Aggregated Objects==<br />
$-prefixed items in a path are used to perform an aggregation lookup using the TypeId of the Object you are looking for.<br />
Since almost all TypeIds have a ns3:: prefix, you will usually see the compound prefix $ns3:: <br />
<br />
Example: <br />
<pre>/NodeList/*/$ns3::TcpL4Protocol</pre> <br />
the above path works because ns3::TcpL4Protocol instances are aggregated to the node in which they exist.<br />
On the other hand see this one:<br />
<pre>/NodeList/0/DeviceList/0/$ns3::WifiRemoteStationManager</pre> <br />
the above path is getting device 0 in node 0, and, then, doing GetObject<WifiRemoteStationManager><br />
on it but it gets null because the remote station manager is not<br />
aggregated to the device.<br />
<br />
==Objects of a specific type==<br />
$-prefixed items in a path are also used to do a ''type cast'' to an object of a particular type. <br />
<br />
For example: <br />
<pre>/NodeList/*/DeviceList/*/$ns3::WifiNetDevice</pre><br />
will match only with devices of type WifiNetDevice. <br />
<br />
Conversely, the following:<br />
<pre>/NodeList/*/DeviceList/*</pre><br />
will match with any device, regardless of the type.<br />
<br />
==Objects referenced by attributes of other Objects==<br />
2) non-$ prefixed non-terminating items in a path are used to perform an<br />
attribute lookup on an attribute of type Pointer. This is often used as an alternative to object aggregation.<br />
<br />
As an example, when using a wifi device:<br />
<pre>/NodeList/0/DeviceList/0/RemoteStationManager/MacTxDataFailed</pre> <br />
the above path works, because devices with TypeId ns3::WifiNetDevice have a RemoteStationManager attribute which is of type Ptr<WifiRemoteStationManager>. On the other hand, see this one:<br />
<pre>/NodeList/0/TcpL4Protocol</pre> <br />
the above path doesn't work, <pre>/NodeList/0</pre> gets you to a Node Object, and there is no Attribute named TcpL4Protocol. All this in spite of the fact that TcpL4Protocol is aggregated with Node -- remember that for querying aggregated objects you need the $ prefix.<br />
<br />
<br />
==Hints==<br />
* A nice way to figure out a path is to [[HOWTO use the ConfigStore | use the ConfigStore]]: if you use it to dump all attributes in a text file, you can see a valid path for each attribute (this, arguably, does not work for trace sources).<br />
* Also, note that there is a 'Config' LogComponent: just activate it by stating <code>LogComponentEnable ("Config", LOG_LEVEL_ALL);</code> somewhere in your simulation script.<br />
<br />
<br />
==References==<br />
*http://groups.google.com/group/ns-3-users/browse_thread/thread/c162f5a8d13fe9d1/67b21278f7abf925?lnk=gst&q=config#67b21278f7abf925<br />
*http://mailman.isi.edu/pipermail/ns-developers/2009-August/006350.html</div>Nicolabaldohttps://www.nsnam.org/mediawiki/index.php?title=Proposed_Release_Process&diff=5617Proposed Release Process2011-04-29T14:52:41Z<p>Nicolabaldo: /* List of fixed bugs */</p>
<hr />
<div>This page outlines proposed changes to the naming of releases, release process, and repository organization.<br />
<br />
== Naming ==<br />
<br />
ns-3 stable releases are numbered with the convention <major>.<minor>.<build>, where <major>=3. The first stable release is numbered 3.1.0. Changes to stable releases which do not add features or change API (i.e., hotfixes) will increment the build number (e.g., "3.1.1", "3.1.2", etc.)<br />
<br />
ns-3 unstable releases made from the ns-3-dev repository are named by the following convention: "ns-3-dev-yyyy-mm-dd"<br />
<br />
== Repositories ==<br />
<br />
ns-3-dev is the development (unstable) repository for the project. Stable releases are made by forking from ns-3-dev.<br />
<br />
ns-3.1.0 --(hotfixes, if any)-- ns-3.2.0 -- (hotfixes, if any)<br />
/ /<br />
/ /<br />
ns-3-dev ---------------------------------------------------------------------<br />
/ \<br />
/ \<br />
(features merged) ns-3-dev-yyyy-mm-dd (e.g. an "unstable" release)<br />
<br />
<br />
In addition, developer-specific repositories can be maintained in parallel as usual.<br />
<br />
== Release process for stable releases ==<br />
<br />
Stable releases are, in general, date driven and regularly scheduled. Each stable release has a release manager who decides on inclusion or removal of changesets once the release branch is forked.<br />
<br />
A stable release is prepared by tagging then cloning ns-3-dev to a new repository named by the release number <major>.<minor> (e.g., "ns-3.1"). This is then maintained in parallel with ns-3-dev, which can continue to undergo development. The stable release branch is strictly a subset of ns-3-dev at all times; the release manager decides which changesets (if any) to pull from ns-3-dev. In parallel, ns-3.<minor>-ref-traces will be forked and maintained also.<br />
<br />
Releases are created by issuing the "./waf dist" command to create compressed tarballs; detailed release steps are in the file doc/release_steps.txt. The "./waf dist" command will package up both ns-3.x and ns-3.x-ref-traces repositories. <br />
<br />
After the release, the repository will be maintained until the next stable release. If a hotfix (critical bug fix) is discovered post-release, the release manager/committee can decide to issue a hotfix release by incrementing the build number (e.g., "ns-3.1.1"). <br />
<br />
Once the next stable release is forked from ns-3-dev, the previous stable release branch and regression-traces branch are tarred and archived, and removed from the web-accessible repository list. All past releases, however, continue to be available in a "releases/" directory on the server, in compressed tarball form.<br />
<br />
An exception to the above is there is a backward-incompatible API change; in this case, the previous stable release branch will continue to be maintained for TBD additional time.<br />
<br />
=== Release candidates ===<br />
<br />
Prior to the stable release, the release manager can issue release candidates. There should be at least one release candidate per release, generally more than a week prior to the scheduled release date, to allow for testing.<br />
<br />
=== Deadlines ===<br />
<br />
There are a few deadlines and steps for incorporating code into a scheduled ns-3 release:<br />
<br />
* '''(14 days prior)''' deadline for forking the stable branch from ns-3-dev. After this point, new features or API are not going into this release. Bug fixes, documentation, and example scripts can continue to be contributed to this branch. <br />
<br />
* '''(3 days prior)''' deadline for any checkins that do not come from the release manager. After this point, commits should be limited to priority P1 bug fixes made by the release manager. <br />
<br />
=== Packaging ===<br />
<br />
ns-3 releases are source releases (tar.bz2). Anyone who wants to contribute alternative packaging (e.g., rpms) can volunteer to do so and coordinate it with the project.<br />
<br />
=== Release Notes ===<br />
Release Notes should be filled in for the release being made in the RELEASE_NOTE file.<br />
<br />
==== List of fixed bugs ====<br />
You can generate a draft list (probably incomplete, but still a good approximation) using a command like this:<br />
hg log -r ns-3.10:tip --template " - {desc|fill68} \n" | grep -e '[Bb]ug'<br />
in the above, replace "ns-3.10" with the tag of the previous stable release.<br />
<br />
== Release process for unstable releases ==<br />
<br />
A developer may make an unstable release from ns-3-dev, between release cycles, for allowing people to test major changes. The process for this is simpler and the name convention is just to tag ns-3-dev with the tag "ns-3-dev-yyyy-mm-dd" and create a "./waf dist" at that point.</div>Nicolabaldohttps://www.nsnam.org/mediawiki/index.php?title=Proposed_Release_Process&diff=5616Proposed Release Process2011-04-29T14:52:07Z<p>Nicolabaldo: /* Release process for stable releases */</p>
<hr />
<div>This page outlines proposed changes to the naming of releases, release process, and repository organization.<br />
<br />
== Naming ==<br />
<br />
ns-3 stable releases are numbered with the convention <major>.<minor>.<build>, where <major>=3. The first stable release is numbered 3.1.0. Changes to stable releases which do not add features or change API (i.e., hotfixes) will increment the build number (e.g., "3.1.1", "3.1.2", etc.)<br />
<br />
ns-3 unstable releases made from the ns-3-dev repository are named by the following convention: "ns-3-dev-yyyy-mm-dd"<br />
<br />
== Repositories ==<br />
<br />
ns-3-dev is the development (unstable) repository for the project. Stable releases are made by forking from ns-3-dev.<br />
<br />
ns-3.1.0 --(hotfixes, if any)-- ns-3.2.0 -- (hotfixes, if any)<br />
/ /<br />
/ /<br />
ns-3-dev ---------------------------------------------------------------------<br />
/ \<br />
/ \<br />
(features merged) ns-3-dev-yyyy-mm-dd (e.g. an "unstable" release)<br />
<br />
<br />
In addition, developer-specific repositories can be maintained in parallel as usual.<br />
<br />
== Release process for stable releases ==<br />
<br />
Stable releases are, in general, date driven and regularly scheduled. Each stable release has a release manager who decides on inclusion or removal of changesets once the release branch is forked.<br />
<br />
A stable release is prepared by tagging then cloning ns-3-dev to a new repository named by the release number <major>.<minor> (e.g., "ns-3.1"). This is then maintained in parallel with ns-3-dev, which can continue to undergo development. The stable release branch is strictly a subset of ns-3-dev at all times; the release manager decides which changesets (if any) to pull from ns-3-dev. In parallel, ns-3.<minor>-ref-traces will be forked and maintained also.<br />
<br />
Releases are created by issuing the "./waf dist" command to create compressed tarballs; detailed release steps are in the file doc/release_steps.txt. The "./waf dist" command will package up both ns-3.x and ns-3.x-ref-traces repositories. <br />
<br />
After the release, the repository will be maintained until the next stable release. If a hotfix (critical bug fix) is discovered post-release, the release manager/committee can decide to issue a hotfix release by incrementing the build number (e.g., "ns-3.1.1"). <br />
<br />
Once the next stable release is forked from ns-3-dev, the previous stable release branch and regression-traces branch are tarred and archived, and removed from the web-accessible repository list. All past releases, however, continue to be available in a "releases/" directory on the server, in compressed tarball form.<br />
<br />
An exception to the above is there is a backward-incompatible API change; in this case, the previous stable release branch will continue to be maintained for TBD additional time.<br />
<br />
=== Release candidates ===<br />
<br />
Prior to the stable release, the release manager can issue release candidates. There should be at least one release candidate per release, generally more than a week prior to the scheduled release date, to allow for testing.<br />
<br />
=== Deadlines ===<br />
<br />
There are a few deadlines and steps for incorporating code into a scheduled ns-3 release:<br />
<br />
* '''(14 days prior)''' deadline for forking the stable branch from ns-3-dev. After this point, new features or API are not going into this release. Bug fixes, documentation, and example scripts can continue to be contributed to this branch. <br />
<br />
* '''(3 days prior)''' deadline for any checkins that do not come from the release manager. After this point, commits should be limited to priority P1 bug fixes made by the release manager. <br />
<br />
=== Packaging ===<br />
<br />
ns-3 releases are source releases (tar.bz2). Anyone who wants to contribute alternative packaging (e.g., rpms) can volunteer to do so and coordinate it with the project.<br />
<br />
=== Release Notes ===<br />
Release Notes should be filled in for the release being made in the RELEASE_NOTE file.<br />
<br />
==== List of fixed bugs ====<br />
You can generate a draft list (probably incomplete, but still a good approximation) using a command like this:<br />
hg log -r ns-3.10:tip --template " - {desc|fill68} \n" | grep -e '[Bb]ug'<br />
<br />
== Release process for unstable releases ==<br />
<br />
A developer may make an unstable release from ns-3-dev, between release cycles, for allowing people to test major changes. The process for this is simpler and the name convention is just to tag ns-3-dev with the tag "ns-3-dev-yyyy-mm-dd" and create a "./waf dist" at that point.</div>Nicolabaldohttps://www.nsnam.org/mediawiki/index.php?title=Main_Page&diff=5487Main Page2011-03-28T16:27:43Z<p>Nicolabaldo: /* Recent Events */</p>
<hr />
<div>{{TOC}}<br />
<br />
This [http://en.wikipedia.org/wiki/MediaWiki wiki] complements the [http://www.nsnam.org/ ns-3] main web site. <br />
'''Account Policy:''' Due to spam problems, we have disabled the ability for newly created user accounts to edit/move pages; even our experience on the ns-2 wiki with [http://www.mediawiki.org/wiki/Extension:ConfirmEdit Mediawiki captchas] has ineffective. For now, if you create a new account and want edit privileges, just email [mailto:ns-developers-owner@isi.edu?subject=ns-3-wiki-enable] with your username and we will enable it for write privileges. '''Note:''' [http://www.isi.edu/nsnam/ns ns-2] has a separate wiki, at http://nsnam.isi.edu/nsnam<br />
<br />
== Upcoming Releases ==<br />
* Information about '''ns-3.11''', tentatively scheduled for May 8, 2011, will be tracked [[Ns-3.11 | on the ns-3.11 wiki page]]. Our most recent release was [[Ns-3.10 | ns-3.10]].<br />
<br />
== Upcoming Events ==<br />
* ns-3 applied but was not selected to the 2011 '''[http://www.google-melange.com/ Google Summer of Code]'''. We are now considering alternatives; please contact Lalith Suresh or view our [[GSOC2011Projects]] page if you are interested in an alternative mentoring arrangement.<br />
<br />
== Recent Events ==<br />
* '''[[DevelMeetingMarch2011]]''' March 26, Barcelona Spain; meeting minutes will be posted shortly.<br />
* '''[[Wns3-2011]]:''' The third annual Workshop on ns-3, Friday 25 March 2011, Barcelona Spain.<br />
* '''[[DevelMeetingNov2010]]''' Friday Nov. 5, 2010 in Washington DC, after the [http://www.geni.net GENI Engineering Conference].<br />
* 2010 Google Summer of Code [http://www.nsnam.org/wiki/index.php/GSOC2010AcceptedProjects project page] and [http://nsnam.blogspot.com/2010/10/2010-google-summer-of-code-wrapup.html wrapup].<br />
<br />
== Current ns-3-dev Build and Test Results == <br />
* [http://ns-regression.ee.washington.edu:8010/waterfall Buildbot Waterfall Display]<br />
<br />
To see detailed information for a particular system and compiler combination, find the appropriate column. For example, "fc10-g++-4.4.0" indicates that a Fedora Core 10 system using the g++ 4.4.0 compiler has been used to build and run the tests. Scroll down until you see build results in that column. Select a "[view results]" link to view the test framework reports for the current build. Note that time flows from bottom to top in this display. This means that most recent build is shown first in the column, but it also means that the results for each build instance are shown "backward" with the Mercurial pull at the bottom, and the optimized build results at the top.<br />
<br />
== Next Level == <br />
We have created the following pages to allow ns-3 users to contribute various information:<br />
* '''[[Roadmap]]''' - Plans for future releases, and what developers are working on<br />
* '''[[Current Development]]''' - What people are working on for ns-3<br />
* '''[[Developer FAQ]]''' - Answers to frequently asked questions for ns-3 developers<br />
* '''[[User FAQ]]''' - Answers to frequently asked questions for ns-3 users<br />
* '''[[HOWTOs]]''' - HOWTOs guides for various simulation activities <br />
* '''[http://www.nsnam.org/wiki/index.php/Category:Samples Samples]''' - Code samples and examples<br />
* '''[[Troubleshooting]]''' - Tips for working around compilation, etc. problems<br />
* '''[[Contributed Code]]''' - Links to third-party ns-3 software contributions<br />
* '''[[Papers]]''' - Research papers about ns-3 or using ns-3</div>Nicolabaldohttps://www.nsnam.org/mediawiki/index.php?title=Wns3-2011&diff=5486Wns3-20112011-03-28T10:42:03Z<p>Nicolabaldo: </p>
<hr />
<div>{{TOC}}<br />
<br />
The [http://www.wns3.org/2011/ 2011 Workshop on ns-3] was held in conjunction with SIMUTools 2011 in Barcelona Spain on 25 March 2011. The technical program chairs were Nicola Baldo and Ruben Merz. This edition of the workshop was the first to review and accept refereed publications. There were eight paper presentations and six invited talks. Papers will be available through the ACM Digital Library. This page archives the presentation materials or abstracts from those talks.<br />
<br />
* <b>Keynote</b><br />
** Tom Henderson, '''ns-3 project status''' <br />
* <b>Papers</b><br />
** Joshua Pelkey and George Riley, '''Distributed Simulation with MPI in ns-3'''<br />
** Lalith Suresh Puthalath and Ruben Merz, '''NS-3-Click: Click Modular Router Integration for NS-3'''<br />
** Pavel Boyko and Andrey Mazo, '''Qemunet: an Approach to an Automated Virtualized Testbed'''<br />
** Hemanth Narra, Yufei Cheng, Egemen Cetinkaya, Justin Rohrer and James Sterbenz, '''Destination-Sequenced Distance Vector (DSDV) Routing Protocol Implementation in ns-3'''<br />
** George Riley and Joshua Pelkey, '''An XML Experiment Description Language for ns-3''' <br />
** Giuseppe Piro, Nicola Baldo and Marco Miozzo, '''An LTE module for the ns-3 network simulator''' <br />
** Evgeni Bikov and Pavel Boyko, '''Direct Execution of OLSR MANET Routing Daemon in ns-3'''<br />
** José Núñez-Martínez and Josep Mangues-Bafalluy, '''Design, Implementation, and Tracing of Backpressure Routing for Ns-3 <br />
'''<br />
* <b>Short talks</b><br />
** Jason Liu, '''PrimoGENI'''<br />
** Felipe Perrone, '''Automation of the ns-3 workflow'''<br />
** George Riley, '''Brite integration with ns-3'''<br />
** Nicola Baldo, '''The LENA project: a product-oriented open source LTE/EPC Network Simulator based on ns-3''' <br />
** Jose Nunez, '''Using ns-3 emulation to experiment with Wireless Mesh Network Routing: Lessons learned'''<br />
<br />
[[Wns3-2010]]<br />
<br />
[[Wns3-2009]]</div>Nicolabaldohttps://www.nsnam.org/mediawiki/index.php?title=Wns3-2011&diff=5485Wns3-20112011-03-28T10:40:01Z<p>Nicolabaldo: </p>
<hr />
<div>{{TOC}}<br />
<br />
The [http://www.wns3.org/2011/ 2011 Workshop on ns-3] was held in conjunction with SIMUTools 2011 in Barcelona Spain on 25 March 2011. The technical program chairs were Nicola Baldo and Ruben Merz. This edition of the workshop was the first to review and accept refereed publications. There were eight paper presentations and six invited talks. Papers will be available through the ACM Digital Library. This page archives the presentation materials or abstracts from those talks.<br />
<br />
* <b>Keynote</b><br />
** Tom Henderson, '''ns-3 project status''' <br />
* <b>Papers</b><br />
** Joshua Pelkey and George Riley, '''Distributed Simulation with MPI in ns-3'''<br />
** Lalith Suresh Puthalath and Ruben Merz, '''NS-3-Click: Click Modular Router Integration for NS-3'''<br />
** Pavel Boyko and Andrey Mazo, '''Qemunet: an Approach to an Automated Virtualized Testbed'''<br />
** Hemanth Narra, Yufei Cheng, Egemen Cetinkaya, Justin Rohrer and James Sterbenz, '''Destination-Sequenced Distance Vector (DSDV) Routing Protocol Implementation in ns-3'''<br />
** George Riley and Joshua Pelkey, '''An XML Experiment Description Language for ns-3''' <br />
** Giuseppe Piro, Nicola Baldo and Marco Miozzo, '''An LTE module for the ns-3 network simulator''' <br />
** Evgeni Bikov and Pavel Boyko, '''Direct Execution of OLSR MANET Routing Daemon in ns-3'''<br />
** José Núñez-Martínez and Josep Mangues-Bafalluy, '''Design, Implementation, and Tracing of Backpressure Routing for Ns-3 <br />
'''<br />
* <b>Short talks</b><br />
** Jason Liu, '''PrimoGENI'''<br />
** Felipe Perrone, '''Automation of the ns-3 workflow'''<br />
** George Riley, '''Brite integration with ns-3'''<br />
** Nicola Baldo, '''The LENA project: a product-oriented open source LTE/EPC Network Simulator based on ns-3''' [[Media:nbaldo_wns3_2011_lena.pdf slides (pdf)]]<br />
** Jose Nunez, '''Using ns-3 emulation to experiment with Wireless Mesh Network Routing: Lessons learned'''<br />
<br />
[[Wns3-2010]]<br />
<br />
[[Wns3-2009]]</div>Nicolabaldohttps://www.nsnam.org/mediawiki/index.php?title=Wns3-2011&diff=5484Wns3-20112011-03-28T10:39:42Z<p>Nicolabaldo: </p>
<hr />
<div>{{TOC}}<br />
<br />
The [http://www.wns3.org/2011/ 2011 Workshop on ns-3] was held in conjunction with SIMUTools 2011 in Barcelona Spain on 25 March 2011. The technical program chairs were Nicola Baldo and Ruben Merz. This edition of the workshop was the first to review and accept refereed publications. There were eight paper presentations and six invited talks. Papers will be available through the ACM Digital Library. This page archives the presentation materials or abstracts from those talks.<br />
<br />
* <b>Keynote</b><br />
** Tom Henderson, '''ns-3 project status''' <br />
* <b>Papers</b><br />
** Joshua Pelkey and George Riley, '''Distributed Simulation with MPI in ns-3'''<br />
** Lalith Suresh Puthalath and Ruben Merz, '''NS-3-Click: Click Modular Router Integration for NS-3'''<br />
** Pavel Boyko and Andrey Mazo, '''Qemunet: an Approach to an Automated Virtualized Testbed'''<br />
** Hemanth Narra, Yufei Cheng, Egemen Cetinkaya, Justin Rohrer and James Sterbenz, '''Destination-Sequenced Distance Vector (DSDV) Routing Protocol Implementation in ns-3'''<br />
** George Riley and Joshua Pelkey, '''An XML Experiment Description Language for ns-3''' <br />
** Giuseppe Piro, Nicola Baldo and Marco Miozzo, '''An LTE module for the ns-3 network simulator''' <br />
** Evgeni Bikov and Pavel Boyko, '''Direct Execution of OLSR MANET Routing Daemon in ns-3'''<br />
** José Núñez-Martínez and Josep Mangues-Bafalluy, '''Design, Implementation, and Tracing of Backpressure Routing for Ns-3 <br />
'''<br />
* <b>Short talks</b><br />
** Jason Liu, '''PrimoGENI'''<br />
** Felipe Perrone, '''Automation of the ns-3 workflow'''<br />
** George Riley, '''Brite integration with ns-3'''<br />
** Nicola Baldo, '''The LENA project: a product-oriented open source LTE/EPC Network Simulator based on ns-3''' [[Image:nbaldo_wns3_2011_lena.pdf slides (pdf)]]<br />
** Jose Nunez, '''Using ns-3 emulation to experiment with Wireless Mesh Network Routing: Lessons learned'''<br />
<br />
[[Wns3-2010]]<br />
<br />
[[Wns3-2009]]</div>Nicolabaldohttps://www.nsnam.org/mediawiki/index.php?title=Wns3-2011&diff=5483Wns3-20112011-03-28T10:39:30Z<p>Nicolabaldo: </p>
<hr />
<div>{{TOC}}<br />
<br />
The [http://www.wns3.org/2011/ 2011 Workshop on ns-3] was held in conjunction with SIMUTools 2011 in Barcelona Spain on 25 March 2011. The technical program chairs were Nicola Baldo and Ruben Merz. This edition of the workshop was the first to review and accept refereed publications. There were eight paper presentations and six invited talks. Papers will be available through the ACM Digital Library. This page archives the presentation materials or abstracts from those talks.<br />
<br />
* <b>Keynote</b><br />
** Tom Henderson, '''ns-3 project status''' <br />
* <b>Papers</b><br />
** Joshua Pelkey and George Riley, '''Distributed Simulation with MPI in ns-3'''<br />
** Lalith Suresh Puthalath and Ruben Merz, '''NS-3-Click: Click Modular Router Integration for NS-3'''<br />
** Pavel Boyko and Andrey Mazo, '''Qemunet: an Approach to an Automated Virtualized Testbed'''<br />
** Hemanth Narra, Yufei Cheng, Egemen Cetinkaya, Justin Rohrer and James Sterbenz, '''Destination-Sequenced Distance Vector (DSDV) Routing Protocol Implementation in ns-3'''<br />
** George Riley and Joshua Pelkey, '''An XML Experiment Description Language for ns-3''' <br />
** Giuseppe Piro, Nicola Baldo and Marco Miozzo, '''An LTE module for the ns-3 network simulator''' <br />
** Evgeni Bikov and Pavel Boyko, '''Direct Execution of OLSR MANET Routing Daemon in ns-3'''<br />
** José Núñez-Martínez and Josep Mangues-Bafalluy, '''Design, Implementation, and Tracing of Backpressure Routing for Ns-3 <br />
'''<br />
* <b>Short talks</b><br />
** Jason Liu, '''PrimoGENI'''<br />
** Felipe Perrone, '''Automation of the ns-3 workflow'''<br />
** George Riley, '''Brite integration with ns-3'''<br />
** Nicola Baldo, '''The LENA project: a product-oriented open source LTE/EPC Network Simulator based on ns-3''' [[Media:nbaldo_wns3_2011_lena.pdf slides (pdf)]]<br />
** Jose Nunez, '''Using ns-3 emulation to experiment with Wireless Mesh Network Routing: Lessons learned'''<br />
<br />
[[Wns3-2010]]<br />
<br />
[[Wns3-2009]]</div>Nicolabaldohttps://www.nsnam.org/mediawiki/index.php?title=Wns3-2011&diff=5482Wns3-20112011-03-28T10:32:57Z<p>Nicolabaldo: </p>
<hr />
<div>{{TOC}}<br />
<br />
The [http://www.wns3.org/2011/ 2011 Workshop on ns-3] was held in conjunction with SIMUTools 2011 in Barcelona Spain on 25 March 2011. The technical program chairs were Nicola Baldo and Ruben Merz. This edition of the workshop was the first to review and accept refereed publications. There were eight paper presentations and six invited talks. Papers will be available through the ACM Digital Library. This page archives the presentation materials or abstracts from those talks.<br />
<br />
* <b>Keynote</b><br />
** Tom Henderson, '''ns-3 project status''' <br />
* <b>Papers</b><br />
** Joshua Pelkey and George Riley, '''Distributed Simulation with MPI in ns-3'''<br />
** Lalith Suresh Puthalath and Ruben Merz, '''NS-3-Click: Click Modular Router Integration for NS-3'''<br />
** Pavel Boyko and Andrey Mazo, '''Qemunet: an Approach to an Automated Virtualized Testbed'''<br />
** Hemanth Narra, Yufei Cheng, Egemen Cetinkaya, Justin Rohrer and James Sterbenz, '''Destination-Sequenced Distance Vector (DSDV) Routing Protocol Implementation in ns-3'''<br />
** George Riley and Joshua Pelkey, '''An XML Experiment Description Language for ns-3''' <br />
** Giuseppe Piro, Nicola Baldo and Marco Miozzo, '''An LTE module for the ns-3 network simulator''' <br />
** Evgeni Bikov and Pavel Boyko, '''Direct Execution of OLSR MANET Routing Daemon in ns-3'''<br />
** José Núñez-Martínez and Josep Mangues-Bafalluy, '''Design, Implementation, and Tracing of Backpressure Routing for Ns-3 <br />
'''<br />
* <b>Short talks</b><br />
** Jason Liu, '''PrimoGENI'''<br />
** Felipe Perrone, '''Automation of the ns-3 workflow'''<br />
** George Riley, '''Brite integration with ns-3'''<br />
** Nicola Baldo, '''The LENA project: a product-oriented open source LTE/EPC Network Simulator based on ns-3''' [[File:nbaldo_wns3_2011_lena.pdf|slides (pdf)]]<br />
** Jose Nunez, '''Using ns-3 emulation to experiment with Wireless Mesh Network Routing: Lessons learned'''<br />
<br />
[[Wns3-2010]]<br />
<br />
[[Wns3-2009]]</div>Nicolabaldohttps://www.nsnam.org/mediawiki/index.php?title=Wns3-2011&diff=5481Wns3-20112011-03-28T10:32:24Z<p>Nicolabaldo: </p>
<hr />
<div>{{TOC}}<br />
<br />
The [http://www.wns3.org/2011/ 2011 Workshop on ns-3] was held in conjunction with SIMUTools 2011 in Barcelona Spain on 25 March 2011. The technical program chairs were Nicola Baldo and Ruben Merz. This edition of the workshop was the first to review and accept refereed publications. There were eight paper presentations and six invited talks. Papers will be available through the ACM Digital Library. This page archives the presentation materials or abstracts from those talks.<br />
<br />
* <b>Keynote</b><br />
** Tom Henderson, '''ns-3 project status''' <br />
* <b>Papers</b><br />
** Joshua Pelkey and George Riley, '''Distributed Simulation with MPI in ns-3'''<br />
** Lalith Suresh Puthalath and Ruben Merz, '''NS-3-Click: Click Modular Router Integration for NS-3'''<br />
** Pavel Boyko and Andrey Mazo, '''Qemunet: an Approach to an Automated Virtualized Testbed'''<br />
** Hemanth Narra, Yufei Cheng, Egemen Cetinkaya, Justin Rohrer and James Sterbenz, '''Destination-Sequenced Distance Vector (DSDV) Routing Protocol Implementation in ns-3'''<br />
** George Riley and Joshua Pelkey, '''An XML Experiment Description Language for ns-3''' <br />
** Giuseppe Piro, Nicola Baldo and Marco Miozzo, '''An LTE module for the ns-3 network simulator''' <br />
** Evgeni Bikov and Pavel Boyko, '''Direct Execution of OLSR MANET Routing Daemon in ns-3'''<br />
** José Núñez-Martínez and Josep Mangues-Bafalluy, '''Design, Implementation, and Tracing of Backpressure Routing for Ns-3 <br />
'''<br />
* <b>Short talks</b><br />
** Jason Liu, '''PrimoGENI'''<br />
** Felipe Perrone, '''Automation of the ns-3 workflow'''<br />
** George Riley, '''Brite integration with ns-3'''<br />
** Nicola Baldo, '''The LENA project: a product-oriented open source LTE/EPC Network Simulator based on ns-3''' [[File:nbaldo_wns3_2011_lena.pdf slides (pdf)]]<br />
** Jose Nunez, '''Using ns-3 emulation to experiment with Wireless Mesh Network Routing: Lessons learned'''<br />
<br />
[[Wns3-2010]]<br />
<br />
[[Wns3-2009]]</div>Nicolabaldohttps://www.nsnam.org/mediawiki/index.php?title=Wns3-2011&diff=5480Wns3-20112011-03-28T08:45:24Z<p>Nicolabaldo: </p>
<hr />
<div>{{TOC}}<br />
<br />
The [http://www.wns3.org/2011/ 2011 Workshop on ns-3] was held in conjunction with SIMUTools 2011 in Barcelona Spain on 25 March 2011. The technical program chairs were Nicola Baldo and Ruben Merz. This edition of the workshop was the first to review and accept refereed publications. There were eight paper presentations and six invited talks. Papers will be available through the ACM Digital Library. This page archives the presentation materials or abstracts from those talks.<br />
<br />
* <b>Keynote</b><br />
** Tom Henderson, '''ns-3 project status''' <br />
* <b>Papers</b><br />
** Joshua Pelkey and George Riley, '''Distributed Simulation with MPI in ns-3'''<br />
** Lalith Suresh Puthalath and Ruben Merz, '''NS-3-Click: Click Modular Router Integration for NS-3'''<br />
** Pavel Boyko and Andrey Mazo, '''Qemunet: an Approach to an Automated Virtualized Testbed'''<br />
** Hemanth Narra, Yufei Cheng, Egemen Cetinkaya, Justin Rohrer and James Sterbenz, '''Destination-Sequenced Distance Vector (DSDV) Routing Protocol Implementation in ns-3'''<br />
** George Riley and Joshua Pelkey, '''An XML Experiment Description Language for ns-3''' <br />
** Giuseppe Piro, Nicola Baldo and Marco Miozzo, '''An LTE module for the ns-3 network simulator''' <br />
** Evgeni Bikov and Pavel Boyko, '''Direct Execution of OLSR MANET Routing Daemon in ns-3'''<br />
** José Núñez-Martínez and Josep Mangues-Bafalluy, '''Design, Implementation, and Tracing of Backpressure Routing for Ns-3 <br />
'''<br />
* <b>Short talks</b><br />
** Jason Liu, '''PrimoGENI'''<br />
** Felipe Perrone, '''Automation of the ns-3 workflow'''<br />
** George Riley, '''Brite integration with ns-3'''<br />
** Nicola Baldo, '''The LENA project: a product-oriented open source LTE/EPC Network Simulator based on ns-3'''<br />
** Jose Nunez, '''Using ns-3 emulation to experiment with Wireless Mesh Network Routing: Lessons learned'''<br />
<br />
[[Wns3-2010]]<br />
<br />
[[Wns3-2009]]</div>Nicolabaldohttps://www.nsnam.org/mediawiki/index.php?title=Wns3-2011&diff=5479Wns3-20112011-03-28T08:44:09Z<p>Nicolabaldo: </p>
<hr />
<div>{{TOC}}<br />
<br />
The [http://www.wns3.org/2011/ 2011 Workshop on ns-3] was held in conjunction with SIMUTools 2011 in Barcelona Spain on 25 March 2011. The technical program chairs were Nicola Baldo and Ruben Merz. This edition of the workshop was the first to review and accept refereed publications. There were eight paper presentations and six invited talks. Papers will be available through the ACM Digital Library. This page archives the presentation materials or abstracts from those talks.<br />
<br />
* <b>Papers</b><br />
** Joshua Pelkey and George Riley, '''Distributed Simulation with MPI in ns-3'''<br />
** Lalith Suresh Puthalath and Ruben Merz, '''NS-3-Click: Click Modular Router Integration for NS-3'''<br />
** Pavel Boyko and Andrey Mazo, '''Qemunet: an Approach to an Automated Virtualized Testbed'''<br />
** Hemanth Narra, Yufei Cheng, Egemen Cetinkaya, Justin Rohrer and James Sterbenz, '''Destination-Sequenced Distance Vector (DSDV) Routing Protocol Implementation in ns-3'''<br />
** George Riley and Joshua Pelkey, '''An XML Experiment Description Language for ns-3''' <br />
** Giuseppe Piro, Nicola Baldo and Marco Miozzo, '''An LTE module for the ns-3 network simulator''' <br />
** Evgeni Bikov and Pavel Boyko, '''Direct Execution of OLSR MANET Routing Daemon in ns-3'''<br />
** José Núñez-Martínez and Josep Mangues-Bafalluy, '''Design, Implementation, and Tracing of Backpressure Routing for Ns-3 <br />
'''<br />
* <b>Short talks</b><br />
** Tom Henderson, '''ns-3 project status''' (keynote)<br />
** Jason Liu, '''PrimoGENI'''<br />
** Felipe Perrone, '''Automation of the ns-3 workflow'''<br />
** George Riley, '''Brite integration with ns-3'''<br />
** Nicola Baldo, '''The LENA project: a product-oriented open source LTE/EPC Network Simulator based on ns-3'''<br />
** Jose Nunez, '''Using ns-3 emulation to experiment with Wireless Mesh Network Routing: Lessons learned'''<br />
<br />
[[Wns3-2010]]<br />
<br />
[[Wns3-2009]]</div>Nicolabaldohttps://www.nsnam.org/mediawiki/index.php?title=Wns3-2011&diff=5478Wns3-20112011-03-28T08:41:57Z<p>Nicolabaldo: </p>
<hr />
<div>{{TOC}}<br />
<br />
The [http://www.wns3.org/2011/ 2011 Workshop on ns-3] was held in conjunction with SIMUTools 2011 in Barcelona Spain on 25 March 2011. The technical program chairs were Nicola Baldo and Ruben Merz. This edition of the workshop was the first to review and accept refereed publications. There were eight paper presentations and six invited talks. Papers will be available through the ACM Digital Library. This page archives the presentation materials or abstracts from those talks.<br />
<br />
* <b>Papers</b><br />
** Joshua Pelkey and George Riley, Distributed Simulation with MPI in ns-3<br />
** Lalith Suresh Puthalath and Ruben Merz, NS-3-Click: Click Modular Router Integration for NS-3<br />
** Pavel Boyko and Andrey Mazo, Qemunet: an Approach to an Automated Virtualized Testbed<br />
** Hemanth Narra, Yufei Cheng, Egemen Cetinkaya, Justin Rohrer and James Sterbenz, Destination-Sequenced Distance Vector (DSDV) Routing Protocol Implementation in ns-3<br />
** George Riley and Joshua Pelkey, An XML Experiment Description Language for ns-3 <br />
** Giuseppe Piro, Nicola Baldo and Marco Miozzo, An LTE module for the ns-3 network simulator <br />
** Evgeni Bikov and Pavel Boyko, Direct Execution of OLSR MANET Routing Daemon in ns-3<br />
** José Núñez-Martínez and Josep Mangues-Bafalluy, Design, Implementation, and Tracing of Backpressure Routing for Ns-3 <br />
<br />
* <b>Short talks</b><br />
** Tom Henderson, ns-3 project status (keynote)<br />
** Jason Liu, PrimoGENI<br />
** Felipe Perrone, Automation of the ns-3 workflow<br />
** George Riley, Brite integration with ns-3<br />
** Nicola Baldo, The LENA project: a product-oriented open source LTE/EPC Network Simulator based on ns-3<br />
** Jose Nunez, Using ns-3 emulation to experiment with Wireless Mesh Network Routing: Lessons learned<br />
<br />
[[Wns3-2010]]<br />
<br />
[[Wns3-2009]]</div>Nicolabaldohttps://www.nsnam.org/mediawiki/index.php?title=DevelMeetingMar2011&diff=5470DevelMeetingMar20112011-03-25T16:37:37Z<p>Nicolabaldo: /* Tentative Topics */</p>
<hr />
<div>{{TOC}}<br />
<br />
= Location and Schedule =<br />
<br />
Will be held in Barcelona, on Saturday, March 26th. That's one day after WNS3 co-located with Simutools 2011.<br />
<br />
The meeting will be hosted at the CTTC Demo Centre, calle Sancho de Avila 110-130, 08018 Barcelona.<br />
<br />
<!--You can have look at the tentative Simutools program for Thursday here: http://www.simutools.org/2011/Programme/Schedule--><br />
<br />
= Tentative Attendance =<br />
<br />
If you'd like to attend, please add your name.<br />
* Tom Henderson<br />
* Nicola Baldo<br />
* Ruben Merz<br />
* Felipe Perrone<br />
* Lalith Suresh<br />
* Marco Miozzo<br />
* Giuseppe Piro<br />
* George Riley<br />
* Mustafa Al-Bado<br />
* Pavel Boyko<br />
* Andrey Mazo<br />
* Aurimas Liutikas<br />
* Jose Nuñez<br />
* Jaime Ferragut<br />
* Justin P. Rohrer<br />
<br />
= Tentative Topics =<br />
* 9:30 A+) Data collection framework (Felipe)<br />
* 10:30 A+) Review modular build system<br />
* 11:00 A+) next phase of the modular build system<br />
* 11:30 A) ns-3 Summer of Code (Lalith)<br />
* 12:00 A) Website review (Tom)<br />
* 12:30 lunch<br />
* 14:00 A) Usability of ns-3 <br />
** e.g., using it as courseware<br />
** also look at feedback from mailing lists<br />
* 14:30 B) Documentation (Tom)<br />
* 15:00 B) Deterministic MAC/Physical wireless models for new users and for routing/transport development (Justin)<br />
* 15:30 B) Simple non-IP network layer example (Justin)<br />
* 16:00 C) Topology generation (George)<br />
* 16:15 C) ns-3-click development (Lalith, Ruben)<br />
* 16:30 AOB<br />
* 17:00 beer<br />
<br />
= Action Points =<br />
<br />
* Tom to write the guidelines for release managers<br />
* Ruben to check for a polling system to poll/survey/googledocs</div>Nicolabaldohttps://www.nsnam.org/mediawiki/index.php?title=DevelMeetingMar2011&diff=5469DevelMeetingMar20112011-03-25T16:32:28Z<p>Nicolabaldo: /* Tentative Topics */</p>
<hr />
<div>{{TOC}}<br />
<br />
= Location and Schedule =<br />
<br />
Will be held in Barcelona, on Saturday, March 26th. That's one day after WNS3 co-located with Simutools 2011.<br />
<br />
The meeting will be hosted at the CTTC Demo Centre, calle Sancho de Avila 110-130, 08018 Barcelona.<br />
<br />
<!--You can have look at the tentative Simutools program for Thursday here: http://www.simutools.org/2011/Programme/Schedule--><br />
<br />
= Tentative Attendance =<br />
<br />
If you'd like to attend, please add your name.<br />
* Tom Henderson<br />
* Nicola Baldo<br />
* Ruben Merz<br />
* Felipe Perrone<br />
* Lalith Suresh<br />
* Marco Miozzo<br />
* Giuseppe Piro<br />
* George Riley<br />
* Mustafa Al-Bado<br />
* Pavel Boyko<br />
* Andrey Mazo<br />
* Aurimas Liutikas<br />
* Jose Nuñez<br />
* Jaime Ferragut<br />
* Justin P. Rohrer<br />
<br />
= Tentative Topics =<br />
* A+) Data collection framework (Felipe)<br />
* A+) Review modular build system<br />
* A+) next phase of the modular build system<br />
* A) ns-3 Summer of Code (Lalith)<br />
* A) Website review (Tom)<br />
* A) Usability of ns-3 <br />
** e.g., using it as courseware<br />
** also look at feedback from mailing lists<br />
* B) Documentation (Tom)<br />
* B) Deterministic MAC/Physical wireless models for new users and for routing/transport development (Justin)<br />
* B) Simple non-IP network layer example (Justin)<br />
* C) Topology generation (George)<br />
* C) ns-3-click development (Lalith, Ruben)<br />
<br />
= Action Points =<br />
<br />
* Tom to write the guidelines for release managers<br />
* Ruben to check for a polling system to poll/survey/googledocs</div>Nicolabaldohttps://www.nsnam.org/mediawiki/index.php?title=DevelMeetingMar2011&diff=5468DevelMeetingMar20112011-03-25T16:31:30Z<p>Nicolabaldo: /* Tentative Topics */</p>
<hr />
<div>{{TOC}}<br />
<br />
= Location and Schedule =<br />
<br />
Will be held in Barcelona, on Saturday, March 26th. That's one day after WNS3 co-located with Simutools 2011.<br />
<br />
The meeting will be hosted at the CTTC Demo Centre, calle Sancho de Avila 110-130, 08018 Barcelona.<br />
<br />
<!--You can have look at the tentative Simutools program for Thursday here: http://www.simutools.org/2011/Programme/Schedule--><br />
<br />
= Tentative Attendance =<br />
<br />
If you'd like to attend, please add your name.<br />
* Tom Henderson<br />
* Nicola Baldo<br />
* Ruben Merz<br />
* Felipe Perrone<br />
* Lalith Suresh<br />
* Marco Miozzo<br />
* Giuseppe Piro<br />
* George Riley<br />
* Mustafa Al-Bado<br />
* Pavel Boyko<br />
* Andrey Mazo<br />
* Aurimas Liutikas<br />
* Jose Nuñez<br />
* Jaime Ferragut<br />
* Justin P. Rohrer<br />
<br />
= Tentative Topics =<br />
* A) Website review (Tom)<br />
* B) Documentation (Tom)<br />
* A+) Data collection framework (Felipe)<br />
* C) Topology generation (George)<br />
* C) ns-3-click development (Lalith, Ruben)<br />
* A) ns-3 Summer of Code (Lalith)<br />
* B) Deterministic MAC/Physical wireless models for new users and for routing/transport development (Justin)<br />
* B) Simple non-IP network layer example (Justin)<br />
* A+) Review modular build system<br />
* A+) next phase of the modular build system<br />
* A) Usability of ns-3 <br />
** e.g., using it as courseware<br />
** also look at feedback from mailing lists<br />
<br />
= Action Points =<br />
<br />
* Tom to write the guidelines for release managers<br />
* Ruben to check for a polling system to poll/survey/googledocs</div>Nicolabaldohttps://www.nsnam.org/mediawiki/index.php?title=DevelMeetingMar2011&diff=5467DevelMeetingMar20112011-03-25T16:25:16Z<p>Nicolabaldo: /* Action Points */</p>
<hr />
<div>{{TOC}}<br />
<br />
= Location and Schedule =<br />
<br />
Will be held in Barcelona, on Saturday, March 26th. That's one day after WNS3 co-located with Simutools 2011.<br />
<br />
The meeting will be hosted at the CTTC Demo Centre, calle Sancho de Avila 110-130, 08018 Barcelona.<br />
<br />
<!--You can have look at the tentative Simutools program for Thursday here: http://www.simutools.org/2011/Programme/Schedule--><br />
<br />
= Tentative Attendance =<br />
<br />
If you'd like to attend, please add your name.<br />
* Tom Henderson<br />
* Nicola Baldo<br />
* Ruben Merz<br />
* Felipe Perrone<br />
* Lalith Suresh<br />
* Marco Miozzo<br />
* Giuseppe Piro<br />
* George Riley<br />
* Mustafa Al-Bado<br />
* Pavel Boyko<br />
* Andrey Mazo<br />
* Aurimas Liutikas<br />
* Jose Nuñez<br />
* Jaime Ferragut<br />
* Justin P. Rohrer<br />
<br />
= Tentative Topics =<br />
* Website review (Tom)<br />
* Documentation (Tom)<br />
* Data collection framework (Felipe)<br />
* Topology generation (George)<br />
* ns-3-click development (Lalith, Ruben)<br />
* ns-3 Summer of Code (Lalith)<br />
* Deterministic MAC/Physical wireless models for new users and for routing/transport development (Justin)<br />
* Simple non-IP network layer example (Justin)<br />
* Review modular build system<br />
* next phase of the modular build system<br />
* Usability of ns-3 <br />
** e.g., using it as courseware<br />
** also look at feedback from mailing lists<br />
<br />
= Action Points =<br />
<br />
* Tom to write the guidelines for release managers<br />
* Ruben to check for a polling system to poll/survey/googledocs</div>Nicolabaldohttps://www.nsnam.org/mediawiki/index.php?title=DevelMeetingMar2011&diff=5466DevelMeetingMar20112011-03-25T16:18:26Z<p>Nicolabaldo: /* Tentative Topics */</p>
<hr />
<div>{{TOC}}<br />
<br />
= Location and Schedule =<br />
<br />
Will be held in Barcelona, on Saturday, March 26th. That's one day after WNS3 co-located with Simutools 2011.<br />
<br />
The meeting will be hosted at the CTTC Demo Centre, calle Sancho de Avila 110-130, 08018 Barcelona.<br />
<br />
<!--You can have look at the tentative Simutools program for Thursday here: http://www.simutools.org/2011/Programme/Schedule--><br />
<br />
= Tentative Attendance =<br />
<br />
If you'd like to attend, please add your name.<br />
* Tom Henderson<br />
* Nicola Baldo<br />
* Ruben Merz<br />
* Felipe Perrone<br />
* Lalith Suresh<br />
* Marco Miozzo<br />
* Giuseppe Piro<br />
* George Riley<br />
* Mustafa Al-Bado<br />
* Pavel Boyko<br />
* Andrey Mazo<br />
* Aurimas Liutikas<br />
* Jose Nuñez<br />
* Jaime Ferragut<br />
* Justin P. Rohrer<br />
<br />
= Tentative Topics =<br />
* Website review (Tom)<br />
* Documentation (Tom)<br />
* Data collection framework (Felipe)<br />
* Topology generation (George)<br />
* ns-3-click development (Lalith, Ruben)<br />
* ns-3 Summer of Code (Lalith)<br />
* Deterministic MAC/Physical wireless models for new users and for routing/transport development (Justin)<br />
* Simple non-IP network layer example (Justin)<br />
* Review modular build system<br />
* next phase of the modular build system<br />
* Usability of ns-3 <br />
** e.g., using it as courseware<br />
** also look at feedback from mailing lists<br />
<br />
= Action Points =<br />
<br />
* Tom to write the guidelines for release managers</div>Nicolabaldohttps://www.nsnam.org/mediawiki/index.php?title=DevelMeetingMar2011&diff=5465DevelMeetingMar20112011-03-25T15:58:24Z<p>Nicolabaldo: /* Tentative Topics */</p>
<hr />
<div>{{TOC}}<br />
<br />
= Location and Schedule =<br />
<br />
Will be held in Barcelona, on Saturday, March 26th. That's one day after WNS3 co-located with Simutools 2011.<br />
<br />
The meeting will be hosted at the CTTC Demo Centre, calle Sancho de Avila 110-130, 08018 Barcelona.<br />
<br />
<!--You can have look at the tentative Simutools program for Thursday here: http://www.simutools.org/2011/Programme/Schedule--><br />
<br />
= Tentative Attendance =<br />
<br />
If you'd like to attend, please add your name.<br />
* Tom Henderson<br />
* Nicola Baldo<br />
* Ruben Merz<br />
* Felipe Perrone<br />
* Lalith Suresh<br />
* Marco Miozzo<br />
* Giuseppe Piro<br />
* George Riley<br />
* Mustafa Al-Bado<br />
* Pavel Boyko<br />
* Andrey Mazo<br />
* Aurimas Liutikas<br />
* Jose Nuñez<br />
* Jaime Ferragut<br />
* Justin P. Rohrer<br />
<br />
= Tentative Topics =<br />
* Website review (Tom)<br />
* Documentation (Tom)<br />
* Data collection framework (Felipe)<br />
* Topology generation (George)<br />
* ns-3-click development (Lalith, Ruben)<br />
* ns-3 Summer of Code (Lalith)<br />
* Deterministic MAC/Physical wireless models for new users and for routing/transport development (Justin)<br />
* Simple non-IP network layer example (Justin)<br />
* Review modular build system<br />
* next phase of the modular build system<br />
* Usability of ns-3 <br />
** e.g., using it as courseware<br />
** also look at feedback from mailing lists</div>Nicolabaldohttps://www.nsnam.org/mediawiki/index.php?title=DevelMeetingMar2011&diff=5435DevelMeetingMar20112011-03-24T11:13:16Z<p>Nicolabaldo: /* Tentative Attendance */</p>
<hr />
<div>{{TOC}}<br />
<br />
= Location and Schedule =<br />
<br />
Will be held in Barcelona, on Saturday, March 26th. That's one day after WNS3 co-located with Simutools 2011.<br />
<br />
The meeting will be hosted at the CTTC Demo Centre, calle Sancho de Avila 110-130, 08018 Barcelona.<br />
<br />
<!--You can have look at the tentative Simutools program for Thursday here: http://www.simutools.org/2011/Programme/Schedule--><br />
<br />
= Tentative Attendance =<br />
<br />
If you'd like to attend, please add your name.<br />
* Tom Henderson<br />
* Nicola Baldo<br />
* Ruben Merz<br />
* Felipe Perrone<br />
* Lalith Suresh<br />
* Marco Miozzo<br />
* Giuseppe Piro<br />
* George Riley<br />
* Mustafa Al-Bado<br />
* Pavel Boyko<br />
* Andrey Mazo<br />
* Aurimas Liutikas<br />
* Jose Nuñez<br />
* Jaime Ferragut<br />
* Justin Rohrer<br />
<br />
= Tentative Topics =<br />
* Website review (Tom)<br />
* Documentation (Tom)<br />
* Data collection framework (Felipe)<br />
* Topology generation (George)<br />
* ns-3-click development (Lalith, Ruben)<br />
* ns-3 Summer of Code (Lalith)</div>Nicolabaldohttps://www.nsnam.org/mediawiki/index.php?title=GSOC2011Projects&diff=5283GSOC2011Projects2011-03-11T17:01:56Z<p>Nicolabaldo: /* Project Ideas */</p>
<hr />
<div>{{TOC}}<br />
<br />
<div style="float: left; width: 50%"><br />
<br />
* [http://www.google-melange.com/document/show/gsoc_program/google/gsoc2011/faqs GSoC Frequently Asked Questions]<br />
* [http://en.flossmanuals.net/GSoCMentoringGuide GSoC Mentors Guide]<br />
* [http://www.booki.cc/gsocstudentguide/_v/1.0/what-is-google-summer-of-code/ Official GSoC Student Guide]<br />
* [[GS02011StudentGuide |ns-3 GSoC Student guide]]<br />
* [[GS02011StudentApplicationTemplate |GSoC Student application template]]<br />
* [[GSOC2011Projects |GSoC 2011 Ideas page]]<br />
* [[GSOC2010Projects |GSoC 2010 Ideas page]] | [[GSOC2010AcceptedProjects |GSoC 2010 Accepted Projects]]<br />
* [[GSOC2009Projects |GSoC 2009 Ideas page]] | [[GSOC2009AcceptedProjects |GSoC 2009 Accepted Projects]]<br />
* [[GSOC2010OAReport |GSoC Organization Administrator guide]]<br />
* ''Get in contact with the ns-3 team'': [http://mailman.isi.edu/mailman/listinfo/ns-developers ns-developers mailing list] | ''IRC'' #ns-3 on freenode.net<br />
</div><div style="float: left; width: 50%"><br />
[[Image:Ns3GSOC2011Flyer.jpg]]<br />
</div><br />
<p><br />
<br />
= GSoC 2011 Ideas =<br />
<br />
This webpage highlights project ideas for ns-3's [http://code.google.com/soc Google Summer of Code] 2011 effort.<br />
<br />
<br />
== About the ns-3 project ==<br />
<br />
ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education. <br />
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.<br />
<br />
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.<br />
<br />
Our GSOC organizational admin is [mailto:suresh.lalith@gmail.com Lalith Suresh] and our backup org admin is [mailto:tomhend@u.washington.edu Tom Henderson].<br />
<br />
== Project Ideas ==<br />
<br />
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 2011 Google Summer of Code. GSoC applicants are however free to propose their own ideas. In addition, please note that these ideas are not limited to Google Summer of Code, anyone is welcome to work on them. Please email the [http://mailman.isi.edu/mailman/listinfo/ns-developers ns-developers list] if you have an idea that you'd like to work on. GSoC applicants are encouraged to look over this list, pick one that especially interests them, think about it, and discuss potential approaches on the [http://mailman.isi.edu/mailman/listinfo/ns-developers ns-developers list]. Previous experience suggests 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 ranked high.<br />
<br />
<blockquote><br />
Each project idea has been tagged with the following properties:<br />
* ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br />
* ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br />
* ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful students might apply their experiences coming out of this project.<br />
* ''Difficulty:'' easy, medium or difficult<br />
* ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br />
<br />
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.<br />
</blockquote><br />
<br />
<br />
=== Priority Project Ideas ===<br />
---------<br />
<br />
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. <br />
<br />
<blockquote><br />
<br />
==== Antenna Models ====<br />
<br />
Mentors: [mailto:ruben@net.t-labs.tu-berlin.de Ruben Merz]<br />
<br />
* '''Antenna Radiation Patterns''' This project would implement support for antenna radiation patterns in the physical layer of ns-3. In addition to enhancing the realism of the ns-3 physical layer, this would also enable to implement directional antennas in ns-3. This project can have a large impact on the ns-3 simulator as it would allow several wireless physical layers to benefit from it, namely 802.11, WiMAX and LTE. If time permits, validation with an 802.11 testbed is envisioned.<br />
** ''Required Experience:'' C++, some knowledge of radio propagation is a plus<br />
** ''Bonus Experience:'' physical layer modeling and simulation, wireless networking<br />
** ''Interests:'' wireless networking, physical layer modeling and simulation<br />
** ''Difficulty'': medium<br />
** ''Recommended readings'': ns-3 propagation models (files <code>*propagation*.{cc,h}</code>), [http://www.ece.cmu.edu/~andersoe/papers/simulation-wiopt.pdf The Impact of Directional Antenna Models on Simulation Accuracy]<br />
<br />
<br />
==== Vehicular Ad-hoc Networks ====<br />
<br />
Mentors: [mailto:g.remy00@gmail.com Guillaume Rémy]<br />
<br />
* '''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.<br />
** ''Required experience:'' C++.<br />
** ''Bonus experience:'' Wireless networking, WAVE.<br />
** ''Interests:'' Wireless networking, VANETs.<br />
** ''Difficulty:'' medium to hard, depending on what the student proposes to implement.<br />
** ''Recommended reading'' <br />
*** [0] http://www.nsnam.org/bugzilla/show_bug.cgi?id=700#c11<br />
*** [1] http://www.nsnam.org/bugzilla/show_bug.cgi?id=945<br />
*** [2] http://www.nsnam.org/bugzilla/show_bug.cgi?id=978#c16<br />
*** [3] http://www.nsnam.org/bugzilla/attachment.cgi?id=968<br />
<br />
<br />
==== Long Term Evolution ====<br />
<br />
Mentors: [mailto:peppe@giuseppepiro.com Giuseppe Piro]<br />
<br />
* '''LTE networks''' Long Term Evolution represents an emerging and promising technology for providing broadband ubiquitous Internet access. Recently a basic LTE module, which includes both PHY and MAC layers, has been developed for ns-3. However, LTE is a very complex standard, and for this reason at this time it is not possible yet to simulate a complete LTE system. Possible aspects of the LTE networks that can be developed are: periodic and aperiodic CQI feedbacks management, a more complete AMC module, frequency-time correlated channel models for both pedestrian and vehicular environment, PHY error model based on BLER curves, uplink, packet scheduling and other MAC functionalities.<br />
** ''Required experience:'' C++, generic understanding of PHY and MAC layers.<br />
** ''Bonus experience:'' ns-3, LTE.<br />
** ''Interests:'' 4G mobile communications.<br />
** ''Difficulty:'' medium to hard, depending on what the student proposes to implement.<br />
** ''Recommended reading'' <br />
*** Stefania Sesia, Matthew P. J. Baker, Issam Toufik, "Long Term Evolution: from theory to practice", John Wiley and Sons, 2009<br />
*** Giuseppe Piro, Nicola Baldo, and Marco Miozzo", An LTE module for the ns-3 network simulator", Proc. of Workshop on NS-3, Barcelona, Spain, Mar., 2011.<br />
<br />
<br />
==== Satellite network stack ====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br />
<br />
* '''Satellite networks''' ns-2 incorporates support for satellite network simulations (http://ala.isti.cnr.it/wnlab/tdmadama). Since that work some relevant standards have been approved, particularly by ETSI. This project would investigate the architecture needed to support ETSI-BSM interfaces and some simple satellite return links, like bent-pipe and basic DVB-RCS.<br />
** ''Required Experience:'' C/C++<br />
** ''Bonus Experience:'' Satellite communication protocols, ns-2, basic UML<br />
** ''Interests:'' Satellite systems, Bandwidth-on-demand, control theory<br />
** ''Difficulty'': medium to difficult (depending on the implementation details the student want to include)<br />
** ''Recommended reading:'' <br />
*** [http://www.etsi.org/website/technologies/broadbandsatmultimedia.aspx Broadband Satellite Multimedia] <br />
*** [http://en.wikipedia.org/wiki/DVB-RCS Digital Video Broadcasting - Return Channel via Satellite]<br />
*** [http://en.wikipedia.org/wiki/DVB-S2 Digital Video Broadcasting - Satellite - Second Generation]<br />
<br />
<br />
==== Advanced Queues for NS-3 ====<br />
<br />
Mentors: TBD or [mailto:duy@soe.ucsc.edu Duy Nguyen]<br />
<br />
* '''Advanced Queue Management''' ns-3 currently has very limited support for more advanced queuing disciplines. The goal of this project is to provide fresh implementation of RED queue to ns-3 by surveying RED queue implementation in ns-2, Linux Kernel (if applicable), and, especially, Sally's RED paper. The preferred outcome of this project will be NS-3 Simulator Tests for RED Technical Report (similar to NS Simulator Tests for RED Technical Report) with extensive validation test cases and providing a framework for other advanced queuing development in ns-3<br />
** ''Required Experience:'' C/C++, knowledge of queuing theory<br />
** ''Bonus Experience:'' ns-2 queues, Linux queues<br />
** ''Interests:'' Advanced queuing models and simulations, queuing theory<br />
** ''Difficulty'': medium to difficult <br />
** ''Recommended reading:'' <br />
*** [http://groups.google.com/group/ns-3-reviews/browse_thread/thread/6359c7c94a334f03 Current Progress on Queues in ns-3] <br />
*** [http://icir.org/floyd/red.html General Information on RED]<br />
*** [http://sourceforge.net/projects/nsnam/files/ns-2/2.34/ See ns-2.34/queue/* ]<br />
*** [http://icir.org/floyd/papers/red/red.html Sally's RED paper]<br />
*** [http://icir.org/floyd/papers/redsims.ps NS Simulator Tests for RED Technical Report]<br />
*** [http://code.nsnam.org/duy/ns-3-dev-queues/ If can be useful]<br />
<br />
<br />
==== Click Modular Router ====<br />
<br />
Mentors: [mailto:suresh.lalith@gmail.com Lalith Suresh] and [mailto:ruben@net.t-labs.tu-berlin.de Ruben Merz]<br />
<br />
* '''Click MAC Extensions for ns-3-click''' Last year's GSoC saw the integration of the Click Modular router with ns-3. However, one of the limitations of the implementation was that the usage of Click was confined to layer 3 only so as to allow all of ns-3's network device types to work under Click. Click's Wifi MAC specific elements cannot be used with ns-3-click yet. This project would involve keeping ns-3-click compatible with Click's Wifi MAC layer elements. Some possible steps in this direction are: 1) Implementing full Radiotap and/or atheros-descriptor header support for ns-3, 2) Implementing a ClickWifiMac abstraction that acts as a MAC high model for a NetDevice, connecting Click's interfaces directly to the lower MAC layers, 3) possibly implementing tx-queue feedback. Getting step 2 right can be a little tricky. Helpers will also be required to ease the end user's life. The above should be implemented as an alternate run-mode for ns-3-click operation. This should then be extensively tested and validated against some stock Click graphs.<br />
** ''Required Experience:'' C++.<br />
** ''Bonus Experience:'' Click, routing architectures, wireless networking.<br />
** ''Interests:'' Routing architectures, protocol development.<br />
** ''Difficulty:'' Medium.<br />
** ''Recommended Reading:''<br />
*** [http://portal.acm.org/citation.cfm?id=570772 NS-Click original paper]<br />
*** [http://read.cs.ucla.edu/click/nsclick NS-Click webpage]<br />
*** [https://www.pats.ua.ac.be/software/nsmadwifi Integration of ns-2 wireless features and Click]<br />
<br />
<br />
<br />
==== TinyOS code execution in ns-3 ====<br />
<br />
Mentors: [mailto:marco.miozzo@cttc.es Marco Miozzo] (CTTC), [mailto:nicola.baldo@cttc.es Nicola Baldo] (CTTC), [mailto:nicola.bui@patavinatech.com Nicola Bui] (Patavina Technologies)<br />
<br />
* '''TinyOS code execution in ns-3''' TinyOS is one of the most used operating system for wireless sensor networks; however the only tool available for simulating tinyOS code is TOSSIM, which supports the MicaZ platform only. The objective of this project is to allow the execution of TinyOS code within the ns-3 simulator, by simulating the hardware interfaces (radio, timers, etc.) of actual sensor platforms. To achieve this, the student will be asked to develop a phy/mac module that leverage on the Spectrum framework for channel modelling and that offers telosb-like interfaces to TinyOS. For the 2011 GSoC, we propose to focus on telosb hardware, since it is one of the most used research platform and mentors have strong expertise on it. The improvements with respect to TOSSIM are the possibility of testing real sensor application within mixed technology scenarios: i.e.: inter-technology interference in the ISM bands and interoperability (as a possible future extension).<br />
** ''Required Experience:'' ns-3, C++, C, TinyOS<br />
** ''Bonus Experience:'' nesC, telosb<br />
** ''Interests:'' wireless sensor networks<br />
** ''Difficulty:'' High<br />
** ''Recommended reading:''<br />
*** [http://www.tinyos.net/ TinyOS website]<br />
*** [http://docs.tinyos.net/index.php/TinyOS_Tutorials TinyOS tutorials]<br />
*** [http://nescc.sourceforge.net/ nesC]<br />
<br />
<br />
==== LTE Time Division Duplex (TDD) support ====<br />
<br />
Mentors: Nicola Baldo, Marco Miozzo<br />
<br />
* The currently available ns-3 LTE modules supports only the Frequency Division Duplex (FDD) mode of operation. Recently, a lot of interest has emerged for the Time Division Duplex (TDD) operation as well. As part of this project, the student is requested to extend the [http://mailman.isi.edu/pipermail/ns-developers/2011-March/008734.html ns-3 LTE module released by the LENA project] to support TDD. The suggested approach is to:<br />
*** extend the MAC layer to handle the TDD frame structure (i.e., the uplink/downlink/special subframe allocation)<br />
*** extend the PHY layer to support TX/RX in a single frequency band, including also the handling of the special subframe.<br />
** ''Required experience:'' C++<br />
** ''Bonus experience:'' ns-3, 3GPP standards<br />
** ''Interests:'' LTE<br />
** ''Difficulty:'' hard<br />
** ''Recommended reading'' <br />
*** 3GPP TS 36.300 EUTRA-EUTRAN Overall Description (in particular Section 5 Physical Layer for E-UTRA)<br />
*** [http://mailman.isi.edu/pipermail/ns-developers/2011-March/008734.html ns-3 LTE module released by the LENA project]<br />
*** [http://www.femtoforum.org/femto/technical.php FemtoForum MAC LTE MAC Scheduler Interface Specification]<br />
*** Stefania Sesia, Matthew P. J. Baker, Issam Toufik, ''Long Term Evolution: from theory to practice'', John Wiley and Sons, 2009<br />
<br />
<br />
<br />
==== LTE Scheduling with the FemtoForum MAC Scheduler API ====<br />
<br />
Mentors: Marco Miozzo, Nicola Baldo<br />
<br />
* The [http://mailman.isi.edu/pipermail/ns-developers/2011-March/008734.html ns-3 LTE module released by the LENA project] supports the [http://www.femtoforum.org/femto/technical.php FemtoForum MAC LTE MAC Scheduler Interface Specification] for the implementation of MAC schedulers. Currently, only a simple Round Robin scheduler is supported. As part of this project, the student is requested to implement one or more scheduling algorithms found in the literature on top of the FemtoForum MAC Scheduler API. A few example algorithms are listed below in the references; however, the choice of the algorithm is left to the student. In any case, we stress that the focus of this project should be on the implementation of an alredy defined algorithm (not on the design of a new algorithm). <br />
<br />
** ''Required experience:'' C++<br />
** ''Bonus experience:'' ns-3, 3GPP standards<br />
** ''Interests:'' LTE, dynamic packet scheduling, radio resource management<br />
** ''Difficulty:'' hard<br />
** ''Recommended reading'' <br />
*** [http://mailman.isi.edu/pipermail/ns-developers/2011-March/008734.html ns-3 LTE module released by the LENA project]<br />
*** [http://www.femtoforum.org/femto/technical.php FemtoForum MAC LTE MAC Scheduler Interface Specification]<br />
*** Stefania Sesia, Matthew P. J. Baker, Issam Toufik, ''Long Term Evolution: from theory to practice'', John Wiley and Sons, 2009<br />
*** B. Sadiq, R. Madan, and A. Sampath, ''Downlink scheduling for multiclass traffic in LTE'', EURASIP Journal on Wireless Communications andNetworking, vol. 2009, Article ID510617, 2009<br />
*** G. Monghal, K. I. Pedersen, I. Z. Kov´acs, and P. E. Mogensen, ''QoS oriented time and frequency domain packet schedulers for the UTRAN long term evolution,'' in Proceedings of the IEEEVehicular Technology Conference (VTC 2008), pp. 2532– 2536, 2008. <br />
*** D. López-Pérez, A. Ladanyi, A. Jüttner, H. Rivano and J. Zhang, ''Optimization Method for the Joint Allocation of Modulation Schemes, Coding Rates, Resource Blocks and Power in Self-Organizing LTE Networks'', IEEE INFOCOM (International Conference on Computer Communications), Shanghai, China, April 2011<br />
<br />
<br />
<br />
==== Model Store ====<br />
<br />
Mentors: TBD<br />
<br />
* '''Model Store.''' The recent ns-3 developers meeting identified a high priority project need to extend the overall build and packaging system for ns-3 to support a user-contributed "model store" inspired by the iPhone App Store. Presently, ns-3 has a monolithic build system and model contributors from outside the project have the choice of trying to integrate their code into the main tree, or else maintaining it (or not) as an independent third-party archive. However, from a maintenance perspective, the project cannot accept maintenance of all contributed models in the long term, and users also do not want to download and build an ever growing code base that may contain many models of no interest to them. Yet we do not want this maintenance and build time bottleneck to stifle user contributions. What we envision is a student project to develop a system and template for future contributors that will allow third-party developers to package, distribute, and update ns-3 protocol models and manage dependencies between models and the core of ns-3.<br />
* ''[[App Store Technical Requirements]]''<br />
* ''Required Experience:'' Python (ns-3 build system is Python-based)<br />
* ''Bonus Experience:'' Packaging frameworks, C++<br />
* ''Interests:'' Build systems, packaging<br />
* ''Difficulty:'' Medium to high<br />
* ''Recommended reading:'' ns-3's waf build system, package management tools, Firefox plugin management, Apple App Store<br />
<br />
<br />
=== Additional Project Ideas ===<br />
---------<br />
<br />
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).<br />
<br />
<blockquote><br />
<br />
==== General ====<br />
<br />
Mentors: WANTED, contact [mailto:boyko@iitp.ru Pavel Boyko]<br />
<br />
* '''Failure and Recovery Models'''<br />
** ''Description'': Introduce the concept of node, device and link failure and recovery to NS-3. Implement. <br />
** ''Required Experience:'' C++, basic software architecture, basic UML<br />
** ''Bonus Experience:'' ns-3 programming, contributions to open source projects.<br />
** ''Interests:'' modelling, software engineering, C++ programming<br />
** ''Difficulty:'' medium, the most difficult part is to define "correct" failure&recovery model<br />
<br />
==== Mobility ====<br />
<br />
Mentors: WANTED, contact [mailto:boyko@iitp.ru Pavel Boyko]<br />
<br />
* '''Coordinate Systems'''<br />
** ''Description'': Introduce the concept of coordinate system to NS-3. Implement [http://en.wikipedia.org/wiki/Geographic_coordinate_system geographic], [http://en.wikipedia.org/wiki/Geocentric_coordinates geocentric] and local Cartesian ([http://en.wikipedia.org/wiki/Map_projection projected]) coordinate systems. <br />
** ''Required Experience:'' C++, basic software architecture, basic UML, basic math<br />
** ''Bonus Experience:'' ns-3 programming, contributions to open source projects.<br />
** ''Interests:'' software engineering, C++ programming, geographic information systems<br/><br />
** ''Difficulty:'' easy<br />
<br />
<br />
Mentors: WANTED, contact [mailto:boyko@iitp.ru Pavel Boyko]<br />
<br />
* '''Satellite Mobility Model'''<br />
** ''Description'': Implement LEO/MEO satellite mobility model for NS-3.<br />
** ''Required Experience:'' C++, basic math, orbit mechanics is a plus<br />
** ''Bonus Experience:'' ns-3 programming, contributions to open source projects.<br />
** ''Interests:'' satellite communications, C++ programming<br/><br />
** ''Difficulty:'' medium<br />
** ''Reading:'' [http://imj.ucsb.edu/papers/172.pdf A SATELLITE MOBILITY MODEL FOR QUALNET NETWORK SIMULATIONS]<br />
** ''Reading:'' [http://www.isi.edu/nsnam/ns/doc/node197.html ns-2 LEO satellite models]<br />
<br />
==== Routing ====<br />
<br />
* '''Generalized Router Models/Structure.''' Many simulators, including ns-3, do not provide high fidelity models of Internet routers. For instance, intra-device latencies and input queuing behavior are not modeled. This project would adapt recent results on [http://www.cs.ucsb.edu/~rchertov/papers/infocom08.pdf empirical router testing] to develop a new, more detailed Router node type for ns-3.<br />
** ''Required Experience:''<br />
** ''Bonus Experience:'' Routing architectures, routing protocols, queueing theory, statistics<br />
** ''Interests:'' High fidelity simulation, queueing theory, statistics, data driven model development<br />
** ''Difficulty:'' medium-to-high, because there may be a dependency on Click router<br />
<br />
<br />
Mentors: WANTED, contact [mailto:aachurin@gmail.com Andrey Churin]<br />
<br />
* '''MPLS'''<br />
** ''Description'': Implement basic MPLS + LDP + RSVP stack model. <br />
** ''Required Experience:'' C++<br />
** ''Bonus Experience:'' ns-3 programming, contributions to open source projects.<br />
** ''Interests:'' MPLS, C++ programming<br/><br />
** ''Difficulty:'' medium<br />
** ''Reading:'' [http://code.google.com/p/ns3-mpls/source/checkout MPLS+LDP model by Andrey Churin], unfinished. Related RFC.<br />
<br />
==== MAC and PHY Models ====<br />
<br />
Mentors: [mailto:ruben@net.t-labs.tu-berlin.de Ruben Merz]<br />
<br />
* '''CSMA/CD and Aloha'''<br />
** ''Description'': Implement a CSMA/CD MAC protocol. Optionally, implement slotted aloha. A good reference describing the CSMA/CD and aloha protocols as well as basic theoretical results about these protocols is "Computer Networking: A Top-Down Approach.".<br />
** ''Required Experience:'' basic C++, know what aloha and CSMA/CD are.<br />
** ''Bonus Experience:'' ns-3 programming, contributions to open source projects.<br />
** ''Interests:'' networking, C++ programming<br/><br />
** ''Difficulty:'' easy<br />
** ''Recommended reading:'' [http://www.scribd.com/doc/5367449/Computer-Networking-A-TopDown-Approach-Featuring-The-Internet-aa Computer Networking: a top down approach], chapter 5.<br />
<br />
Mentors: TBD<br />
<br />
* '''SNS for ns-3 Wifi.''' [http://www.cs.cornell.edu/people/egs/sns/ Staged Network Simulations (SNS)] is a patch for the ns-2 wireless models which provides for function approximation and caching. That mechanism greatly speeds up the many calculations required in mobile wireless simulations. This project would incorporate those techniques into the ns-3 WiFi model.<br />
** ''Required Experience:''<br />
** ''Bonus Experience:'' Software profiling, software tuning<br />
** ''Interests:'' Approximation, caching, software profiling, high performance computing, scientific computing<br />
** ''Difficulty:'' depends on what functionality the student proposes to implement<br />
<br />
==== Applications and Systems ====<br />
<br />
* '''Large Scale Topology Generation and Management.''' ns-2 incorporates support for [http://www.isi.edu/nsnam/ns/ns-topogen.html various topology generators], which would be useful to also support in ns-3. This project would investigate porting topology generators or mapping their output to ns-3 simulations. It would also touch on the problem of coherent IP addressing in generated topologies. In particular, [http://www.cs.utah.edu/flux/papers/ipassign-ftn2005-04-base.html recent work] by the Emulab project may be useful in this regard.<br />
** ''Required Experience:''<br />
** ''Bonus Experience:'' Graph theory, network management, Internet topology<br />
** ''Interests:'' Internet topology, Internet autonomous systems, graph theory<br />
** ''Difficulty:'' depends on what functionality the student proposes to implement<br />
<br />
<br />
Mentors: WANTED, contact [mailto:boyko@iitp.ru Pavel Boyko]<br />
<br />
* '''VoIP Toolkit'''<br />
** ''Description'': Implement VoIP quality testing toolkit. Depending on author's skills and resources it can include<br />
*** RTP model + sender and receiver applications measuring delay, jitter, packet loss and [http://www.itu.int/ITU-T/studygroups/com12/emodelv1/index.htm MOS] <br />
*** SIP model measuring [http://en.wikipedia.org/wiki/Call_Setup_Success_Rate call setup success rate], call dropping rate, etc.<br />
*** Application for sending and receiving real audio samples over simulated network to allow subjective QoS estimation<br />
*** Video support<br />
*** etc... <br />
** ''Required Experience:'' C++, basic VoIP understanding<br />
** ''Bonus Experience:'' ns-3 programming, contributions to open source projects.<br />
** ''Interests:'' VoIP, software engineering, C++ programming<br/><br />
** ''Difficulty:'' medium<br />
<br />
* '''SNMP Agent'''<br />
** ''Description'': Implement SNMP agent inside ns-3 to allow monitor, visualize and control simulated network using any available SNMP manager<br />
** ''Required Experience:'' C++, basic SNMP understanding<br />
** ''Bonus Experience:'' fun, ns-3 programming, contributions to open source projects.<br />
** ''Interests:'' Network management, SNMP, C++ programming<br/><br />
** ''Difficulty:'' medium<br />
<br />
<br />
</blockquote><br />
<br />
<br />
<br />
[[Category:GSoC]]</div>Nicolabaldohttps://www.nsnam.org/mediawiki/index.php?title=Main_Page&diff=5272Main Page2011-03-04T17:03:15Z<p>Nicolabaldo: /* Upcoming Events */</p>
<hr />
<div>{{TOC}}<br />
<br />
This [http://en.wikipedia.org/wiki/MediaWiki wiki] complements the [http://www.nsnam.org/ ns-3] main web site. <br />
'''Account Policy:''' Due to spam problems, we have disabled the ability for newly created user accounts to edit/move pages; even our experience on the ns-2 wiki with [http://www.mediawiki.org/wiki/Extension:ConfirmEdit Mediawiki captchas] has ineffective. For now, if you create a new account and want edit privileges, just email [mailto:ns-developers-owner@isi.edu?subject=ns-3-wiki-enable] with your username and we will enable it for write privileges. '''Note:''' [http://www.isi.edu/nsnam/ns ns-2] has a separate wiki, at http://nsnam.isi.edu/nsnam<br />
<br />
== Upcoming Releases ==<br />
* Information about '''ns-3.11''', tentatively scheduled for April 11, 2011, will be tracked [[Ns-3.11 | on the ns-3.11 wiki page]]. Our most recent release was [[Ns-3.10 | ns-3.10]].<br />
<br />
== Upcoming Events ==<br />
* '''[[WNS3]] 2011 Call for Participation:''' Please join us for the [http://www.wns3.org Workshop on ns-3], Friday 25 March 2011 in Barcelona Spain.<br />
* ns-3 will apply to the '''[http://www.google-melange.com/ Google Summer of Code]'''. Lalith Suresh will be our org admin. Please check our [[GSOC2011Projects]] page.<br />
* '''ns-3 developers meeting:''' March 26, Barcelona Spain; please check [http://www.nsnam.org/wiki/index.php/DevelMeetingMarch2011 here] if interested<br />
<br />
== Recent Events ==<br />
* ns-3 developers meeting: Friday Nov. 5, 2010 in Washington DC ([http://www.nsnam.org/wiki/index.php/DevelMeetingNov2010 '''logistics''']), after the [http://www.geni.net GENI Engineering Conference].<br />
* Google Summer of Code [http://www.nsnam.org/wiki/index.php/GSOC2010AcceptedProjects project page] and [http://nsnam.blogspot.com/2010/10/2010-google-summer-of-code-wrapup.html wrapup].<br />
<br />
== Current ns-3-dev Build and Test Results == <br />
* [http://ns-regression.ee.washington.edu:8010/waterfall Buildbot Waterfall Display]<br />
<br />
To see detailed information for a particular system and compiler combination, find the appropriate column. For example, "fc10-g++-4.4.0" indicates that a Fedora Core 10 system using the g++ 4.4.0 compiler has been used to build and run the tests. Scroll down until you see build results in that column. Select a "[view results]" link to view the test framework reports for the current build. Note that time flows from bottom to top in this display. This means that most recent build is shown first in the column, but it also means that the results for each build instance are shown "backward" with the Mercurial pull at the bottom, and the optimized build results at the top.<br />
<br />
== Next Level == <br />
We have created the following pages to allow ns-3 users to contribute various information:<br />
* '''[[Roadmap]]''' - Plans for future releases, and what developers are working on<br />
* '''[[Current Development]]''' - What people are working on for ns-3<br />
* '''[[Developer FAQ]]''' - Answers to frequently asked questions for ns-3 developers<br />
* '''[[User FAQ]]''' - Answers to frequently asked questions for ns-3 users<br />
* '''[[HOWTOs]]''' - HOWTOs guides for various simulation activities <br />
* '''[http://www.nsnam.org/wiki/index.php/Category:Samples Samples]''' - Code samples and examples<br />
* '''[[Troubleshooting]]''' - Tips for working around compilation, etc. problems<br />
* '''[[Contributed Code]]''' - Links to third-party ns-3 software contributions<br />
* '''[[Papers]]''' - Research papers about ns-3 or using ns-3</div>Nicolabaldohttps://www.nsnam.org/mediawiki/index.php?title=App_Store_Technical_Requirements&diff=5227App Store Technical Requirements2011-02-17T17:17:26Z<p>Nicolabaldo: /* Module dependencies */</p>
<hr />
<div>{{TOC}}<br />
<br />
= Goals =<br />
<br />
The long-term goal is to move ns-3 to separate modules, for build and <br />
maintenance reasons. For build reasons, since ns-3 is becoming large, <br />
we would like to allow users to enable/disable subsets of the available <br />
model library. For maintenance reasons, it is important that we move to <br />
a development model where modules can evolve on different timescales and <br />
be maintained by different organizations.<br />
<br />
An analogy is the GNOME desktop, which is composed of a number of <br />
individual libraries that evolve on their own timescales. A build <br />
framework called [http://live.gnome.org/Jhbuild jhbuild] exists for <br />
building and managing the dependencies between these disparate projects.<br />
<br />
Once we have a modular build, and an ability to separately download and <br />
install third-party modules, we will need to distinguish the maintenance <br />
status or certification of modules. The ns-3 project will maintain a <br />
set of core ns-3 modules including those essential for all ns-3 <br />
simulations, and will maintain a master build file containing metadata <br />
to contributed modules; this will allow users to fetch and build what <br />
they need. Eventually, modules will have a maintenance state associated <br />
with them describing aspects such as who is the maintainer, whether it <br />
is actively maintained, whether it contains documentation or tests, <br />
whether it passed an ns-3 project code review, whether it is currently <br />
passing the tests, etc. The current status of all known ns-3 modules <br />
will be maintained in a database and be browsable on the project web site.<br />
<br />
[[image:Maintenance-status-example.PNG]]<br />
<br />
'''Figure caption''': ''Mock-up of future model status page (models and colors selected are just for example purposes)''<br />
<br />
The basic idea of the ns-3 app store would be to store on a server a set of user-submitted metadata which describes various source code packages. Typical metadata would include:<br />
* unique name<br />
* version number<br />
* last known good ns-3 version (tested against)<br />
* description<br />
* download url<br />
* untar/unzip command<br />
* configure command<br />
* build command<br />
* system prerequisites (if user needs to apt-get install other libraries)<br />
* list of ns-3 package dependencies (other ns-3 packages which this package depends upon)<br />
<br />
= Requirements =<br />
<br />
== Build and configuration ==<br />
<br />
* Enable optimized, debug, and static builds<br />
* Separate tests from models<br />
* Doxygen support<br />
* Test.py framework supports the modularization<br />
* Python bindings support the modularization<br />
* integrate lcov code coverage tests<br />
* integrate with buildbots<br />
<br />
== API and work flow ==<br />
<br />
Assume that our download script is called download.py and our<br />
build script is called build.py.<br />
<br />
wget http://www.nsnam.org/releases/ns-allinone-3.x.tar.bz2<br />
bunzip2 ns-allinone-3.x.tar.bz2 && tar xvf ns-allinone-3.x.tar.bz2<br />
cd ns-allinone-3.x<br />
<br />
In this directory, users will find the following directory layout:<br />
<br />
build.py download.py constants.py? VERSION LICENSE README<br />
<br />
Download essential modules:<br />
<br />
./download.py<br />
<br />
This will leave a layout such as follows:<br />
<br />
download.py build.py pygccxml pybindgen ns-3.10 gcc-xml<br />
<br />
<br />
For typical users, the next step is as follows:<br />
<br />
./build.py<br />
<br />
The above will take the following steps:<br />
* build all typical prerequisites such as pybindgen<br />
* cd ns3-10<br />
* ./waf configure && ./waf && ./waf install<br />
<br />
The above will install headers into build/debug/ns3/ and libraries for each of the enabled modules into build/debug/lib. Each enabled module will be placed in a separate library that has a name of the form libns3-simulator.so for the simulator module.<br />
<br />
'''Open issue:''' How to express and honor platform limitations, such as<br />
only trying to download/build NSC on platforms supporting it.<br />
<br />
Once the build process is done, there will be a bunch of libraries in a <br />
common build directory, and all applicable headers. Specifically,<br />
we envision for module simulator, there may be a libns3-simulator.so, libns3-simulator-test.so,<br />
a python .so, and possibly others. <br />
<br />
=== Python ===<br />
<br />
We have a few choices for supporting Python. First, note that this type<br />
of system provides an opportunity for the python build tools to be added<br />
as packages to the overall build system, so that users can more easily<br />
build their bindings. We can try to build lots of small python modules,<br />
or run a scan at the very end of the ns-3 build process to build a customized<br />
python ns3 module, such as:<br />
<br />
* python-scan.py<br />
* ...<br />
* pybindgen<br />
<br />
which operates on the headers in the build/debug/ns3 directory and creates<br />
a python module .so library that matches the ns-3 configured components.<br />
<br />
'''Open issue:''' What is the eventual python API? Should each module be<br />
imported separately such as import node as ns.node, or should we try to<br />
go for a single ns3 python module? Or, we could continue to maintain bindings. Another consideration is that constantly generating bindings will slow down the builds.<br />
<br />
=== Tests ===<br />
<br />
Tests are run by running ./test.py, which knows how to find the available<br />
test libraries and run the tests.<br />
<br />
Presently, test.py hardcodes the examples or samples; it needs to become<br />
smarter to learn what examples are around and need testing.<br />
<br />
=== Doxygen ===<br />
<br />
Doxygen can be run such as "build.py doxygen" on the build/debug/ns3 <br />
directory. I would guess that we don't try to modularize this but instead<br />
to run on the build/debug/ns3/ directory once all headers have been copied in.<br />
<br />
=== Build flags ===<br />
<br />
To configure different options such as -g, -fprofile-arcs, e.g., use the<br />
CFLAGS environment variable.<br />
<br />
=== Running programs ===<br />
<br />
To run programs:<br />
<br />
./build.py shell<br />
build/debug/examples/csma/csma-bridge<br />
or<br />
python build/debug/examples/csma/csma-bridge.py<br />
<br />
=== Other examples ===<br />
<br />
Build all known ns-3 modules:<br />
<br />
./build.py all<br />
<br />
In the above case, suppose that the program could not download and fetch<br />
a module. Here, it can interactively prompt the user "Module foo not <br />
found; do you wish to continue [Y/n]?".<br />
<br />
Build the core of ns-3, plus device models WiFi and CSMA:<br />
<br />
./build ns3-core wifi csma<br />
<br />
ns3-core is a meta-module containing simulator common node mobility etc. <br />
'''Open issue:''' what is the right granularity for this module?<br />
<br />
=== Example third-party ns-3 module ===<br />
<br />
Suppose a research group at Example Univ. publishes a new WiMin device <br />
module. It gets a new unique module name from ns-3 project, such as <br />
wimin. It also contributes metadata to the master ns-3 build script. <br />
<br />
==== Downloading ====<br />
<br />
The "download.py" system should have enough metadata to fetch it, whether<br />
it is a tarball release or some other kind of release. <br />
<br />
'''Open issue:''' How does user toggle the download behavior of a module?<br />
Is there a sticky "./download.py --disable-module=wimin" option? Or does<br />
user manually edit the module metadata file?<br />
<br />
'''Open issue:''' Where does this module download to? Options include:<br />
# ns-3-allinone/wimin<br />
# ns-3-allinone/ns-3-dev/wimin<br />
# ns-3-allinone/ns-3-dev/modules/wimin<br />
<br />
In the first case above, this will result in an ns-3-allinone directory that<br />
is flat and possibly including non-ns3 modules mixed with ns-3 modules<br />
(e.g. pygccxml, nam-1, aodv, olsr, simulator, click, ... will all be at<br />
the same directory level). <br />
<br />
In the second case, it has advantage of keeping all ns-3-specific modules<br />
within an ns-3 subdirectory. This may support better the developer who<br />
has multiple ns-3 branches that are supported by "common" libraries such<br />
as nsc, pybindgen, etc. that do not have to change.<br />
<br />
The third case is somewhat analogous to the present situation where we<br />
have ns-3-allinone/ns-3-dev/src/wimin.<br />
<br />
==== Building ====<br />
<br />
./build.py<br />
<br />
at the top level should recurse and cause the wimin module to be built<br />
based on the provided (jhbuild) metadata.<br />
<br />
At this top level, there need to be some global CFLAGS in effect that<br />
cause debug/optimized/static to be consistently performed.<br />
<br />
Let's assume that the downloaded module looked like this:<br />
<br />
ns-3-allinone/ns-3-dev/wimin/model<br />
/examples<br />
/doc<br />
/test<br />
/helper<br />
/bindings<br />
<br />
After the build step, it looks like this:<br />
<br />
ns-3-allinone/ns-3-dev/wimin/model<br />
/examples<br />
/doc<br />
/test<br />
/helper<br />
/lib/libns3-wimin.so<br />
/lib/libns3-wimin-test.so<br />
/bindings/ns3wimin.so<br />
/include<br />
/bin<br />
<br />
==== Installing ====<br />
<br />
The install step will next put it into these places:<br />
<br />
installprefix/bin<br />
installprefix/include/wimin<br />
installprefix/bindings/python<br />
installprefix/lib<br />
<br />
where installprefix defaults to either "ns-3-allinone/install/debug" <br />
or "ns-3-allinone/ns-3-dev/install/debug" but can be overridden if<br />
a different prefix is configured.<br />
<br />
= Plan and Status =<br />
<br />
== Plan ==<br />
<br />
We are aiming to first make the existing ns-3 modular, and then work<br />
on the second issue of supporting easy integration of modules<br />
maintained by third parties.<br />
<br />
This plan will be carried out in two stages:<br />
* Stage 1: (for review/merge now) make existing ns-3 modular<br />
** users can explicitly disable unneeded modules from their build<br />
** tests are decoupled from the main libraries; changes to test programs do not cause all examples to be relinked<br />
* Stage 2: (post ns-3.11) enable the "app store" concept<br />
** allow jhbuild or similar scripts to orchestrate a larger build, including managing third-party dependencies (e.g. click or openflow)<br />
** each module gets an independent version number, and metadata coordinates version dependencies between modules<br />
** allow users to use their own build system if they want<br />
<br />
== Stage 1 Status ==<br />
<br />
Stage 1 is proposed for ns-3.11 release. The primary goal is to be able to enable/disable modules and allow users to tailor the build to include the components that they need. <br />
<br />
Making the existing ns-3 into a modular system is mainly a job of reorganizing the source tree and modifying waf and the python bindings generation code. <br />
<br />
There is a prototype repository at http://code.nsnam.org/watrous/ns-3-dev-pending that basically contains what is proposed for ns-3.11. The items that have been completed to date are:<br />
# Resolve the main circular dependencies in the core modules of ns-3, and reorganize the following modules: simulator, core, common, node, internet-stack into a new set of modules: core, network, internet, propagation, spectrum, along the lines of what was discussed on the list<br />
# A new file .ns3rc that allows users to specify which items are in the build or out of the build.<br />
# separate libraries for each module: each module builds one "model" library and one "test" library. Only the test-runner links the test code.<br />
# The example programs that test.py runs (if examples are enabled in the build) are specified in each examples directory in a new file "examples-to-run.py", rather than in the main test.py program. <br />
<br />
ns-3-dev-pending is not finished but is far enough along for people to get the idea of what it will eventually look like for ns-3.11. The items that are unfinished but are proposed to be finished for this release are:<br />
# Generate python bindings, at least the first step below. Gustavo previously proposed to do this in two stages: <br />
## require all modules to be built for python while modular python binding generation is worked on. The python user would import a single monolithic python module, as is presently done.<br />
## make python bindings truly modular; bindings would be maintained in a bindings/ directory with each module, and the python modules will be decomposed along module boundaries (e.g. "import ns3-network")<br />
# not all modules are cut over to the new module directory structure, but we believe that the main dependency issues are resolved or easily resolvable, and the other modules can be cut over in short order<br />
# src/helper will go away; helpers will be maintained on a per-module basis.<br />
# Not all test code has been properly redistributed in the new directory layout. The plan is that "build verification tests" (BVTs) will live with the model code, and other tests (e.g. UNIT) will live in a test/ directory.<br />
# some examples or samples may migrate from the top level examples/ or samples/ directory to the module examples/ directory for this release. However, since some examples contain many more dependencies than the individual modules that are linked, we suggest to keep a top-level directory for such example programs.<br />
# Presently the system requires that each module have a test library. This requires at least that each wscript have a test block in its wscript file so that libns3-modulename-test.so is created.<br />
# ./waf --doxygen needs to be re-enabled; print-introspected-doxygen utility is not presently built as part of all modules.<br />
# Fix project documentation (tutorial, wiki, manual, etc.) to align with the new layout<br />
<br />
=== New module layout ===<br />
<br />
A prototypical module looks like this:<br />
<br />
src/modulename/<br />
doc/<br />
examples/<br />
examples-to-run.py<br />
helper/<br />
model/<br />
test/<br />
utils/<br />
wscript<br />
<br />
Not all directories will be present in each module.<br />
<br />
=== Module dependencies ===<br />
<br />
[[File:Module-relationships.png]]<br />
<br />
[[File:plot_module_dependencies]]<br />
<br />
=== Modular libraries ===<br />
<br />
Enabling a module will cause two libraries to be built: libns3-modulename.so and libns3-modulename-test.so. For example, try these commands:<br />
<br />
./waf configure --disable-python --enable-modules=core<br />
./waf<br />
cd build/debug/<br />
ls<br />
<br />
and the following libraries should be present:<br />
<br />
bindings libns3-core.so ns3 scratch utils<br />
examples libns3-core-test.so samples src<br />
<br />
Running test.py will cause only those tests that depend on module core to be run:<br />
<br />
20 of 24 tests passed (20 passed, 4 skipped, 0 failed, 0 crashed, 0 valgrind errors)<br />
<br />
Repeat for the "network" module instead of the "core" module, and the following will be built, since network depends on core:<br />
<br />
bindings libns3-core.so libns3-network.so ns3 scratch utils<br />
examples libns3-core-test.so libns3-network-test.so samples src<br />
<br />
=== the .ns3rc file ===<br />
<br />
Using a command-line option (--enable-modules=modulename) to ./waf at configure stage can be used to control which modules are built. There is an alternate way, which is to write an .ns3rc file:<br />
<br />
cat .ns3rc<br />
<br />
#! /usr/bin/env python<br />
<br />
# A list of the modules that will be enabled when ns-3 is run.<br />
# Modules that depend on the listed modules will be enabled also.<br />
#<br />
# All modules can be enabled by choosing 'all_modules'.<br />
modules_enabled = ['core', 'network', 'internet', 'mpi', 'mobility', 'bridge', 'propagation', 'spectrum']<br />
<br />
<br />
The precedence rules are as follows:<br />
<br />
# the --enable-modules configure string overrides any .ns3rc file<br />
# the .ns3rc file in the top level ns-3 directory is next consulted, if present<br />
# the system searches for ~/.ns3rc if the above two are unspecified<br />
# /etc/ns3rc is checked<br />
<br />
If none of the above limits the modules to be built, all modules that waf knows about will be built.<br />
<br />
Presently, the .ns3rc file in the repository http://code.nsnam.org/watrous/ns-3-dev-pending lives in the top-level directory. As such, it will be prone to accidental checkins from maintainers that enable/disable the default configuration. Therefore, it is proposed that the maintained version live in the utils/ directory, and users will need to manually copy to their preferred place (top level directory, their home directory) to enable persistent modular build configuration.<br />
<br />
=== examples-to-run.py ===<br />
<br />
In ns-3.10, test.py hardcodes a number of examples to run in the test suite. In ns-3.11, we propose to add a new file "examples-to-run.py" in each module test/ directory, to tell the test framework which of the models should be run and under which test conditions. The syntax is the same as in current test.py; e.g. the src/spectrum/test/examples-to-run.py is given below:<br />
<br />
#! /usr/bin/env python<br />
## -*- Mode: python; py-indent-offset: 4; indent-tabs-mode: nil; coding: utf-8; -*-<br />
# A list of C++ examples to run in order to ensure that they remain<br />
# buildable and runnable over time. Each tuple in the list contains<br />
#<br />
# (example_name, do_run, do_valgrind_run).<br />
#<br />
# See test.py for more information.<br />
cpp_examples = [<br />
("adhoc-aloha-ideal-phy", "True", "True"),<br />
("adhoc-aloha-ideal-phy-with-microwave-oven", "True", "True"),<br />
]<br />
# A list of Python examples to run in order to ensure that they remain<br />
# runnable over time. Each tuple in the list contains<br />
#<br />
# (example_name, do_run).<br />
#<br />
# See test.py for more information.<br />
python_examples = []<br />
<br />
=== Open issue review ===<br />
<br />
'''Open issue:''' Should src/ directory be renamed to modules/, or kept as is?<br />
<br />
* Suggest to keep as src/ at least for now, to minimize changes<br />
<br />
'''Open issue:''' Should modules be flat in the modules/ directory, or preserve<br />
hierarchy such as modules/routing/dsdv?<br />
<br />
* Suggest to flatten, per Nicola's (and others) suggestion<br />
<br />
'''Open issue:''' Should tests be built by default, or should they be disabled?<br />
In other programs, you typically do a "make test" explicitly. Here, we<br />
could add a "./waf test" explicit command, or we could make it built by<br />
default but disabled if users "./waf configure --disable-tests".<br />
<br />
* The present situation is that test libraries will be built by default.<br />
<br />
'''Open issue:''' Bug 848: Linux FHS requires version number appended to the<br />
library. Should we start doing this?<br />
<br />
* Currently, we are not proposing to fix this for ns-3.11.<br />
<br />
'''Open issue:''' Do we want to keep including version number in the ns-3 directory name?<br />
<br />
* No change proposed for ns-3.11<br />
<br />
'''Open issue:''' Install/uninstall to typical file system locations, e.g.<br />
/usr/lib/libns3-simulator.so.3.10<br />
/usr/lib/libns3-simulator.so.3 -> /usr/lib/libns3-simulator.so.3.10<br />
<br />
* No change proposed for ns-3.11.<br />
<br />
'''Open issue:''' Documentation organization. Proposing that each module<br />
contain<br />
its .rst file(s) in the module/<modulename>/doc/ directory. Modules that<br />
want to chain up to the main documentation tree can do so by adding<br />
themselves<br />
to the index.rst. In the future, when users develop modules in the app<br />
store<br />
framework, users can choose to chain up to the main manual, or they can<br />
provide<br />
their own makefiles and even choose their own markup (e.g. latex) if<br />
they want, and separate html/pdf can be generated.<br />
<br />
* No change proposed for ns-3.11<br />
<br />
== Stage 2 Status ==<br />
<br />
For the second stage, we have been looking at GNOME jhbuild to build packages at<br />
the top-level ns-3-allinone directory. jhbuild may need to be <br />
wrapped by a specialized ns-3 build.py or download.py wrapper. However, we<br />
encountered these limitations so far:<br />
# jhbuild has no support for scons<br />
# waf support is limited; for instance, controlling configuration options is limited<br />
# jhbuild has no support for hierarchical builds: although you can have metamodules, and moduleset includes, there is (AFAIK) no option to say "build only this metamodule". The options to "start at module X", or "skip module Y" are not sufficient.</div>Nicolabaldohttps://www.nsnam.org/mediawiki/index.php?title=App_Store_Technical_Requirements&diff=5226App Store Technical Requirements2011-02-17T17:13:53Z<p>Nicolabaldo: /* Module dependencies */</p>
<hr />
<div>{{TOC}}<br />
<br />
= Goals =<br />
<br />
The long-term goal is to move ns-3 to separate modules, for build and <br />
maintenance reasons. For build reasons, since ns-3 is becoming large, <br />
we would like to allow users to enable/disable subsets of the available <br />
model library. For maintenance reasons, it is important that we move to <br />
a development model where modules can evolve on different timescales and <br />
be maintained by different organizations.<br />
<br />
An analogy is the GNOME desktop, which is composed of a number of <br />
individual libraries that evolve on their own timescales. A build <br />
framework called [http://live.gnome.org/Jhbuild jhbuild] exists for <br />
building and managing the dependencies between these disparate projects.<br />
<br />
Once we have a modular build, and an ability to separately download and <br />
install third-party modules, we will need to distinguish the maintenance <br />
status or certification of modules. The ns-3 project will maintain a <br />
set of core ns-3 modules including those essential for all ns-3 <br />
simulations, and will maintain a master build file containing metadata <br />
to contributed modules; this will allow users to fetch and build what <br />
they need. Eventually, modules will have a maintenance state associated <br />
with them describing aspects such as who is the maintainer, whether it <br />
is actively maintained, whether it contains documentation or tests, <br />
whether it passed an ns-3 project code review, whether it is currently <br />
passing the tests, etc. The current status of all known ns-3 modules <br />
will be maintained in a database and be browsable on the project web site.<br />
<br />
[[image:Maintenance-status-example.PNG]]<br />
<br />
'''Figure caption''': ''Mock-up of future model status page (models and colors selected are just for example purposes)''<br />
<br />
The basic idea of the ns-3 app store would be to store on a server a set of user-submitted metadata which describes various source code packages. Typical metadata would include:<br />
* unique name<br />
* version number<br />
* last known good ns-3 version (tested against)<br />
* description<br />
* download url<br />
* untar/unzip command<br />
* configure command<br />
* build command<br />
* system prerequisites (if user needs to apt-get install other libraries)<br />
* list of ns-3 package dependencies (other ns-3 packages which this package depends upon)<br />
<br />
= Requirements =<br />
<br />
== Build and configuration ==<br />
<br />
* Enable optimized, debug, and static builds<br />
* Separate tests from models<br />
* Doxygen support<br />
* Test.py framework supports the modularization<br />
* Python bindings support the modularization<br />
* integrate lcov code coverage tests<br />
* integrate with buildbots<br />
<br />
== API and work flow ==<br />
<br />
Assume that our download script is called download.py and our<br />
build script is called build.py.<br />
<br />
wget http://www.nsnam.org/releases/ns-allinone-3.x.tar.bz2<br />
bunzip2 ns-allinone-3.x.tar.bz2 && tar xvf ns-allinone-3.x.tar.bz2<br />
cd ns-allinone-3.x<br />
<br />
In this directory, users will find the following directory layout:<br />
<br />
build.py download.py constants.py? VERSION LICENSE README<br />
<br />
Download essential modules:<br />
<br />
./download.py<br />
<br />
This will leave a layout such as follows:<br />
<br />
download.py build.py pygccxml pybindgen ns-3.10 gcc-xml<br />
<br />
<br />
For typical users, the next step is as follows:<br />
<br />
./build.py<br />
<br />
The above will take the following steps:<br />
* build all typical prerequisites such as pybindgen<br />
* cd ns3-10<br />
* ./waf configure && ./waf && ./waf install<br />
<br />
The above will install headers into build/debug/ns3/ and libraries for each of the enabled modules into build/debug/lib. Each enabled module will be placed in a separate library that has a name of the form libns3-simulator.so for the simulator module.<br />
<br />
'''Open issue:''' How to express and honor platform limitations, such as<br />
only trying to download/build NSC on platforms supporting it.<br />
<br />
Once the build process is done, there will be a bunch of libraries in a <br />
common build directory, and all applicable headers. Specifically,<br />
we envision for module simulator, there may be a libns3-simulator.so, libns3-simulator-test.so,<br />
a python .so, and possibly others. <br />
<br />
=== Python ===<br />
<br />
We have a few choices for supporting Python. First, note that this type<br />
of system provides an opportunity for the python build tools to be added<br />
as packages to the overall build system, so that users can more easily<br />
build their bindings. We can try to build lots of small python modules,<br />
or run a scan at the very end of the ns-3 build process to build a customized<br />
python ns3 module, such as:<br />
<br />
* python-scan.py<br />
* ...<br />
* pybindgen<br />
<br />
which operates on the headers in the build/debug/ns3 directory and creates<br />
a python module .so library that matches the ns-3 configured components.<br />
<br />
'''Open issue:''' What is the eventual python API? Should each module be<br />
imported separately such as import node as ns.node, or should we try to<br />
go for a single ns3 python module? Or, we could continue to maintain bindings. Another consideration is that constantly generating bindings will slow down the builds.<br />
<br />
=== Tests ===<br />
<br />
Tests are run by running ./test.py, which knows how to find the available<br />
test libraries and run the tests.<br />
<br />
Presently, test.py hardcodes the examples or samples; it needs to become<br />
smarter to learn what examples are around and need testing.<br />
<br />
=== Doxygen ===<br />
<br />
Doxygen can be run such as "build.py doxygen" on the build/debug/ns3 <br />
directory. I would guess that we don't try to modularize this but instead<br />
to run on the build/debug/ns3/ directory once all headers have been copied in.<br />
<br />
=== Build flags ===<br />
<br />
To configure different options such as -g, -fprofile-arcs, e.g., use the<br />
CFLAGS environment variable.<br />
<br />
=== Running programs ===<br />
<br />
To run programs:<br />
<br />
./build.py shell<br />
build/debug/examples/csma/csma-bridge<br />
or<br />
python build/debug/examples/csma/csma-bridge.py<br />
<br />
=== Other examples ===<br />
<br />
Build all known ns-3 modules:<br />
<br />
./build.py all<br />
<br />
In the above case, suppose that the program could not download and fetch<br />
a module. Here, it can interactively prompt the user "Module foo not <br />
found; do you wish to continue [Y/n]?".<br />
<br />
Build the core of ns-3, plus device models WiFi and CSMA:<br />
<br />
./build ns3-core wifi csma<br />
<br />
ns3-core is a meta-module containing simulator common node mobility etc. <br />
'''Open issue:''' what is the right granularity for this module?<br />
<br />
=== Example third-party ns-3 module ===<br />
<br />
Suppose a research group at Example Univ. publishes a new WiMin device <br />
module. It gets a new unique module name from ns-3 project, such as <br />
wimin. It also contributes metadata to the master ns-3 build script. <br />
<br />
==== Downloading ====<br />
<br />
The "download.py" system should have enough metadata to fetch it, whether<br />
it is a tarball release or some other kind of release. <br />
<br />
'''Open issue:''' How does user toggle the download behavior of a module?<br />
Is there a sticky "./download.py --disable-module=wimin" option? Or does<br />
user manually edit the module metadata file?<br />
<br />
'''Open issue:''' Where does this module download to? Options include:<br />
# ns-3-allinone/wimin<br />
# ns-3-allinone/ns-3-dev/wimin<br />
# ns-3-allinone/ns-3-dev/modules/wimin<br />
<br />
In the first case above, this will result in an ns-3-allinone directory that<br />
is flat and possibly including non-ns3 modules mixed with ns-3 modules<br />
(e.g. pygccxml, nam-1, aodv, olsr, simulator, click, ... will all be at<br />
the same directory level). <br />
<br />
In the second case, it has advantage of keeping all ns-3-specific modules<br />
within an ns-3 subdirectory. This may support better the developer who<br />
has multiple ns-3 branches that are supported by "common" libraries such<br />
as nsc, pybindgen, etc. that do not have to change.<br />
<br />
The third case is somewhat analogous to the present situation where we<br />
have ns-3-allinone/ns-3-dev/src/wimin.<br />
<br />
==== Building ====<br />
<br />
./build.py<br />
<br />
at the top level should recurse and cause the wimin module to be built<br />
based on the provided (jhbuild) metadata.<br />
<br />
At this top level, there need to be some global CFLAGS in effect that<br />
cause debug/optimized/static to be consistently performed.<br />
<br />
Let's assume that the downloaded module looked like this:<br />
<br />
ns-3-allinone/ns-3-dev/wimin/model<br />
/examples<br />
/doc<br />
/test<br />
/helper<br />
/bindings<br />
<br />
After the build step, it looks like this:<br />
<br />
ns-3-allinone/ns-3-dev/wimin/model<br />
/examples<br />
/doc<br />
/test<br />
/helper<br />
/lib/libns3-wimin.so<br />
/lib/libns3-wimin-test.so<br />
/bindings/ns3wimin.so<br />
/include<br />
/bin<br />
<br />
==== Installing ====<br />
<br />
The install step will next put it into these places:<br />
<br />
installprefix/bin<br />
installprefix/include/wimin<br />
installprefix/bindings/python<br />
installprefix/lib<br />
<br />
where installprefix defaults to either "ns-3-allinone/install/debug" <br />
or "ns-3-allinone/ns-3-dev/install/debug" but can be overridden if<br />
a different prefix is configured.<br />
<br />
= Plan and Status =<br />
<br />
== Plan ==<br />
<br />
We are aiming to first make the existing ns-3 modular, and then work<br />
on the second issue of supporting easy integration of modules<br />
maintained by third parties.<br />
<br />
This plan will be carried out in two stages:<br />
* Stage 1: (for review/merge now) make existing ns-3 modular<br />
** users can explicitly disable unneeded modules from their build<br />
** tests are decoupled from the main libraries; changes to test programs do not cause all examples to be relinked<br />
* Stage 2: (post ns-3.11) enable the "app store" concept<br />
** allow jhbuild or similar scripts to orchestrate a larger build, including managing third-party dependencies (e.g. click or openflow)<br />
** each module gets an independent version number, and metadata coordinates version dependencies between modules<br />
** allow users to use their own build system if they want<br />
<br />
== Stage 1 Status ==<br />
<br />
Stage 1 is proposed for ns-3.11 release. The primary goal is to be able to enable/disable modules and allow users to tailor the build to include the components that they need. <br />
<br />
Making the existing ns-3 into a modular system is mainly a job of reorganizing the source tree and modifying waf and the python bindings generation code. <br />
<br />
There is a prototype repository at http://code.nsnam.org/watrous/ns-3-dev-pending that basically contains what is proposed for ns-3.11. The items that have been completed to date are:<br />
# Resolve the main circular dependencies in the core modules of ns-3, and reorganize the following modules: simulator, core, common, node, internet-stack into a new set of modules: core, network, internet, propagation, spectrum, along the lines of what was discussed on the list<br />
# A new file .ns3rc that allows users to specify which items are in the build or out of the build.<br />
# separate libraries for each module: each module builds one "model" library and one "test" library. Only the test-runner links the test code.<br />
# The example programs that test.py runs (if examples are enabled in the build) are specified in each examples directory in a new file "examples-to-run.py", rather than in the main test.py program. <br />
<br />
ns-3-dev-pending is not finished but is far enough along for people to get the idea of what it will eventually look like for ns-3.11. The items that are unfinished but are proposed to be finished for this release are:<br />
# Generate python bindings, at least the first step below. Gustavo previously proposed to do this in two stages: <br />
## require all modules to be built for python while modular python binding generation is worked on. The python user would import a single monolithic python module, as is presently done.<br />
## make python bindings truly modular; bindings would be maintained in a bindings/ directory with each module, and the python modules will be decomposed along module boundaries (e.g. "import ns3-network")<br />
# not all modules are cut over to the new module directory structure, but we believe that the main dependency issues are resolved or easily resolvable, and the other modules can be cut over in short order<br />
# src/helper will go away; helpers will be maintained on a per-module basis.<br />
# Not all test code has been properly redistributed in the new directory layout. The plan is that "build verification tests" (BVTs) will live with the model code, and other tests (e.g. UNIT) will live in a test/ directory.<br />
# some examples or samples may migrate from the top level examples/ or samples/ directory to the module examples/ directory for this release. However, since some examples contain many more dependencies than the individual modules that are linked, we suggest to keep a top-level directory for such example programs.<br />
# Presently the system requires that each module have a test library. This requires at least that each wscript have a test block in its wscript file so that libns3-modulename-test.so is created.<br />
# ./waf --doxygen needs to be re-enabled; print-introspected-doxygen utility is not presently built as part of all modules.<br />
# Fix project documentation (tutorial, wiki, manual, etc.) to align with the new layout<br />
<br />
=== New module layout ===<br />
<br />
A prototypical module looks like this:<br />
<br />
src/modulename/<br />
doc/<br />
examples/<br />
examples-to-run.py<br />
helper/<br />
model/<br />
test/<br />
utils/<br />
wscript<br />
<br />
Not all directories will be present in each module.<br />
<br />
=== Module dependencies ===<br />
<br />
[[File:Module-relationships.png]]<br />
<br />
[[File:plot_module_dependencies.sh]]<br />
<br />
=== Modular libraries ===<br />
<br />
Enabling a module will cause two libraries to be built: libns3-modulename.so and libns3-modulename-test.so. For example, try these commands:<br />
<br />
./waf configure --disable-python --enable-modules=core<br />
./waf<br />
cd build/debug/<br />
ls<br />
<br />
and the following libraries should be present:<br />
<br />
bindings libns3-core.so ns3 scratch utils<br />
examples libns3-core-test.so samples src<br />
<br />
Running test.py will cause only those tests that depend on module core to be run:<br />
<br />
20 of 24 tests passed (20 passed, 4 skipped, 0 failed, 0 crashed, 0 valgrind errors)<br />
<br />
Repeat for the "network" module instead of the "core" module, and the following will be built, since network depends on core:<br />
<br />
bindings libns3-core.so libns3-network.so ns3 scratch utils<br />
examples libns3-core-test.so libns3-network-test.so samples src<br />
<br />
=== the .ns3rc file ===<br />
<br />
Using a command-line option (--enable-modules=modulename) to ./waf at configure stage can be used to control which modules are built. There is an alternate way, which is to write an .ns3rc file:<br />
<br />
cat .ns3rc<br />
<br />
#! /usr/bin/env python<br />
<br />
# A list of the modules that will be enabled when ns-3 is run.<br />
# Modules that depend on the listed modules will be enabled also.<br />
#<br />
# All modules can be enabled by choosing 'all_modules'.<br />
modules_enabled = ['core', 'network', 'internet', 'mpi', 'mobility', 'bridge', 'propagation', 'spectrum']<br />
<br />
<br />
The precedence rules are as follows:<br />
<br />
# the --enable-modules configure string overrides any .ns3rc file<br />
# the .ns3rc file in the top level ns-3 directory is next consulted, if present<br />
# the system searches for ~/.ns3rc if the above two are unspecified<br />
# /etc/ns3rc is checked<br />
<br />
If none of the above limits the modules to be built, all modules that waf knows about will be built.<br />
<br />
Presently, the .ns3rc file in the repository http://code.nsnam.org/watrous/ns-3-dev-pending lives in the top-level directory. As such, it will be prone to accidental checkins from maintainers that enable/disable the default configuration. Therefore, it is proposed that the maintained version live in the utils/ directory, and users will need to manually copy to their preferred place (top level directory, their home directory) to enable persistent modular build configuration.<br />
<br />
=== examples-to-run.py ===<br />
<br />
In ns-3.10, test.py hardcodes a number of examples to run in the test suite. In ns-3.11, we propose to add a new file "examples-to-run.py" in each module test/ directory, to tell the test framework which of the models should be run and under which test conditions. The syntax is the same as in current test.py; e.g. the src/spectrum/test/examples-to-run.py is given below:<br />
<br />
#! /usr/bin/env python<br />
## -*- Mode: python; py-indent-offset: 4; indent-tabs-mode: nil; coding: utf-8; -*-<br />
# A list of C++ examples to run in order to ensure that they remain<br />
# buildable and runnable over time. Each tuple in the list contains<br />
#<br />
# (example_name, do_run, do_valgrind_run).<br />
#<br />
# See test.py for more information.<br />
cpp_examples = [<br />
("adhoc-aloha-ideal-phy", "True", "True"),<br />
("adhoc-aloha-ideal-phy-with-microwave-oven", "True", "True"),<br />
]<br />
# A list of Python examples to run in order to ensure that they remain<br />
# runnable over time. Each tuple in the list contains<br />
#<br />
# (example_name, do_run).<br />
#<br />
# See test.py for more information.<br />
python_examples = []<br />
<br />
=== Open issue review ===<br />
<br />
'''Open issue:''' Should src/ directory be renamed to modules/, or kept as is?<br />
<br />
* Suggest to keep as src/ at least for now, to minimize changes<br />
<br />
'''Open issue:''' Should modules be flat in the modules/ directory, or preserve<br />
hierarchy such as modules/routing/dsdv?<br />
<br />
* Suggest to flatten, per Nicola's (and others) suggestion<br />
<br />
'''Open issue:''' Should tests be built by default, or should they be disabled?<br />
In other programs, you typically do a "make test" explicitly. Here, we<br />
could add a "./waf test" explicit command, or we could make it built by<br />
default but disabled if users "./waf configure --disable-tests".<br />
<br />
* The present situation is that test libraries will be built by default.<br />
<br />
'''Open issue:''' Bug 848: Linux FHS requires version number appended to the<br />
library. Should we start doing this?<br />
<br />
* Currently, we are not proposing to fix this for ns-3.11.<br />
<br />
'''Open issue:''' Do we want to keep including version number in the ns-3 directory name?<br />
<br />
* No change proposed for ns-3.11<br />
<br />
'''Open issue:''' Install/uninstall to typical file system locations, e.g.<br />
/usr/lib/libns3-simulator.so.3.10<br />
/usr/lib/libns3-simulator.so.3 -> /usr/lib/libns3-simulator.so.3.10<br />
<br />
* No change proposed for ns-3.11.<br />
<br />
'''Open issue:''' Documentation organization. Proposing that each module<br />
contain<br />
its .rst file(s) in the module/<modulename>/doc/ directory. Modules that<br />
want to chain up to the main documentation tree can do so by adding<br />
themselves<br />
to the index.rst. In the future, when users develop modules in the app<br />
store<br />
framework, users can choose to chain up to the main manual, or they can<br />
provide<br />
their own makefiles and even choose their own markup (e.g. latex) if<br />
they want, and separate html/pdf can be generated.<br />
<br />
* No change proposed for ns-3.11<br />
<br />
== Stage 2 Status ==<br />
<br />
For the second stage, we have been looking at GNOME jhbuild to build packages at<br />
the top-level ns-3-allinone directory. jhbuild may need to be <br />
wrapped by a specialized ns-3 build.py or download.py wrapper. However, we<br />
encountered these limitations so far:<br />
# jhbuild has no support for scons<br />
# waf support is limited; for instance, controlling configuration options is limited<br />
# jhbuild has no support for hierarchical builds: although you can have metamodules, and moduleset includes, there is (AFAIK) no option to say "build only this metamodule". The options to "start at module X", or "skip module Y" are not sufficient.</div>Nicolabaldohttps://www.nsnam.org/mediawiki/index.php?title=DevelMeetingMar2011&diff=5206DevelMeetingMar20112011-02-14T18:10:20Z<p>Nicolabaldo: /* Location and Schedule */</p>
<hr />
<div>{{TOC}}<br />
<br />
= Location and Schedule =<br />
<br />
Will be held in Barcelona, on Saturday, March 26th. That's one day after WNS3 co-located with Simutools 2011.<br />
<br />
The meeting will be hosted at the CTTC Demo Centre, calle Sancho de Avila 110-130, 08018 Barcelona.<br />
<br />
<!--You can have look at the tentative Simutools program for Thursday here: http://www.simutools.org/2011/Programme/Schedule--><br />
<br />
= Tentative Attendance =<br />
<br />
If you'd like to attend, please add your name.<br />
* Tom Henderson<br />
* Nicola Baldo<br />
* Ruben Merz<br />
* Felipe Perrone<br />
* Lalith Suresh<br />
* Marco Miozzo<br />
* Giuseppe Piro<br />
* George Riley<br />
* Ken Renard<br />
* Mustafa Al-Bado<br />
<br />
= Tentative Topics =<br />
* IPv6 transport</div>Nicolabaldohttps://www.nsnam.org/mediawiki/index.php?title=Papers&diff=5097Papers2011-01-14T17:57:28Z<p>Nicolabaldo: </p>
<hr />
<div>{{TOC}}<br />
<br />
__FORCETOC__<br />
<br />
== Papers about ns-3 ==<br />
<bibtex><br />
@inproceedings{weingartner:icc2009,<br />
author = {Weingartner, Elias and vom Lehn, Hendrik and Wehrle, Klaus},<br />
title = {A performance comparison of recent network simulators},<br />
booktitle = {Proceedings of the IEEE International Conference on Communications 2009 (ICC 2009)},<br />
address = {Dresden, Germany},<br />
publisher = {IEEE},<br />
year = {2009},<br />
abstract = {A widespread methodology for performance analysis in the field of communication systems engineering is network simulation. While ns-2 has established itself as virtually the standard network simulation tool, other network simulators have gained more and more attention during the last years. In this paper, we briefly survey new developments in the field of network simulation and conduct a performance comparison study by implementing an identical simulation set-up in five simulators, namely ns-2, OMNet++, ns-3, SimPy and JiST/SWANS. Our results reveal large differences according to both run-time performance and memory usage.},<br />
url = {http://ds.informatik.rwth-aachen.de/members/weingaertner/publications/2008-06-Weingaertner-ICC-NetworkSimulatorComparison}<br />
}<br />
</bibtex><br />
<br />
<bibtex><br />
@inproceedings{montavont:wns22008,<br />
author={Julian Montavont and Sebastien Vincent and Nicolas Montavont},<br />
title={Implementation of an IPv6 stack for ns-3},<br />
booktitle={2nd International Workshop on NS-2 (WNS2 2008)},<br />
month={October},<br />
year={2008},<br />
}<br />
</bibtex><br />
<br />
<bibtex><br />
@inproceedings{farooq:simutools2009,<br />
author={J. Farooq and T. Turletti},<br />
title={An IEEE 802.16 WiMAX Module for the NS-3 Simulator}<br />
booktitle={2nd International Conference on Simulation Tools and Techniques (SIMUTools'09)},<br />
month={March},<br />
year={2009},<br />
url={ftp://ftp-sop.inria.fr/rodeo/turletti/simutools09.pdf}<br />
}<br />
</bibtex><br />
<br />
<bibtex><br />
@inproceedings{bonada:simutools2008,<br />
author={Eduard Bonada, Darko Cavic},<br />
title={(Poster) How to implement a layer 2 bridge in ns-3},<br />
booktitle={1st ACM/ICST International Conference on Simulation Tools and Techniques for Communications, Networks and Systems (SIMUTools 2008)},<br />
month={March},<br />
year={2008},<br />
}<br />
</bibtex><br />
<br />
<bibtex><br />
@inproceedings{carneiro:nstools2009,<br />
author = {Carneiro, Gustavo and Ricardo, Manuel and Fortuna, Pedro},<br />
title = {FlowMonitor - a network monitoring framework for the Network Simulator 3 (NS-3)},<br />
booktitle = {Proceedings of ICST NSTools 2009},<br />
address = {Pisa, Italy},<br />
year = {2009},<br />
month = {October}<br />
}<br />
</bibtex><br />
<br />
<bibtex><br />
@inproceedings{baldo:nstools2009,<br />
author = {Baldo, Nicola and Miozzo, Marco},<br />
title = {Spectrum-aware Channel and PHY layer modeling for ns3},<br />
booktitle = {Proceedings of ICST NSTools 2009},<br />
address = {Pisa, Italy},<br />
year = {2009},<br />
month = {October}<br />
url = {http://www.cttc.es/resources/doc/091029-1088-9305.pdf}<br />
}<br />
</bibtex><br />
<br />
<bibtex><br />
@inproceedings{xia:nstools2009,<br />
author = {Xia, Yu},<br />
title = {Design and Implementation of Switch Module for NS-3},<br />
booktitle = {Proceedings of ICST NSTools 2009},<br />
address = {Pisa, Italy},<br />
year = {2009},<br />
month = {October}<br />
}<br />
</bibtex><br />
<br />
<bibtex><br />
@inproceedings{wang:ects2009,<br />
author = {Wang, Anbao and Jiang, Wenrong},<br />
title= {Research of Teaching on Network Course Based on NS-3}, <br />
booktitle = {Education Technology and Computer Science, 2009. ETCS '09. First International Workshop on},<br />
location = {Wuhan, Hubei},<br />
isbn = {978-1-4244-3581-4},<br />
year = {2009}<br />
}<br />
</bibtex><br />
<br />
<bibtex><br />
@inproceedings{baldo:simutools2010,<br />
author = {Nicola Baldo and Manuel Requena and Jose Nunez and Marc Portoles and Jaume Nin and Paolo Dini and Josep Mangues},<br />
title = {Validation of the ns-3 IEEE 802.11 model using the EXTREME testbed},<br />
booktitle = {Proceedings of SIMUTools Conference, 2010},<br />
location = {Torremolinos, Malaga Spain},<br />
year = {2010},<br />
month = {March}<br />
}<br />
</bibtex><br />
<br />
<bibtex><br />
@inproceedings{ismail:simutools2010,<br />
author = {Mohamed Amine Ismail and Giuseppe Piro and Luigi Alfredo Grieco and Thierry Turletti},<br />
title = {An Improved IEEE 802.16 WiMAX Module for the ns-3 Simulator},<br />
booktitle = {Proceedings of SIMUTools Conference, 2010},<br />
location = {Torremolinos, Malaga Spain},<br />
year = {2010},<br />
month = {March}<br />
}<br />
</bibtex><br />
<br />
<bibtex><br />
@inproceedings{alvarez:simutools2010,<br />
author = {Alberto Alvarez and Rafael Orea and Sergio Cabrero and Xabiel G. Pañeda and Roberto García and David Melendi},<br />
title = {Limitations of network emulation with single-machine and distributed ns-3},<br />
booktitle = {Proceedings of SIMUTools Conference, 2010},<br />
location = {Torremolinos, Malaga Spain},<br />
year = {2010},<br />
month = {March}<br />
}<br />
</bibtex><br />
<br />
<bibtex><br />
@inproceedings{papanastasiou:wcnc2010,<br />
author = {Papanastasiou, Stylianos and Mittag, Jens and Ström, Erik G and Hartenstein, Hannes},<br />
title = {Bridging the Gap Between Physical Layer Emulation and Network Simulation},<br />
booktitle = {Proceedings of IEEE WCNC Conference, 2010},<br />
location = {Sydney, Australia},<br />
year = {2010},<br />
month = {April}<br />
}<br />
</bibtex><br />
<br />
Make sure to check also the [[WNS3]] page.<br />
<br />
== Research using ns-3 ==<br />
This page lists papers or posters written using ns-3. If you want to add your paper to the list, please paste in a bibtex entry or send the bibtex to a wiki maintainer.<br />
aintainer.<br />
<br />
<bibtex><br />
@INPROCEEDINGS{5657700, <br />
author={Suresh, P. Lalith and Kaur, Rajbir and Gaur, M. S. and Laxmi, V.}, <br />
booktitle={Wireless Days (WD), 2010 IFIP}, title={Collusion attack resistance through forced MPR switching in OLSR}, <br />
year={2010}, <br />
month=oct., <br />
volume={}, <br />
number={}, <br />
pages={1 -5}, <br />
keywords={}, <br />
doi={10.1109/WD.2010.5657700}, <br />
ISSN={2156-9711},}<br />
</bibtex><br />
<br />
<bibtex><br />
@inproceedings{Suresh P.:2010:CAD:1854099.1854151,<br />
author = {Suresh P., Lalith and Kaur, Rajbir and Gaur, Manoj Singh and Laxmi, Vijay},<br />
title = {A collusion attack detection method for OLSR-based MANETS employing scruple packets},<br />
booktitle = {Proceedings of the 3rd international conference on Security of information and networks},<br />
series = {SIN '10},<br />
year = {2010},<br />
isbn = {978-1-4503-0234-0},<br />
location = {Taganrog, Rostov-on-Don, Russian Federation},<br />
pages = {256--262},<br />
numpages = {7},<br />
url = {http://doi.acm.org/10.1145/1854099.1854151},<br />
doi = {http://doi.acm.org/10.1145/1854099.1854151},<br />
acmid = {1854151},<br />
publisher = {ACM},<br />
address = {New York, NY, USA},<br />
keywords = {collusion attack, manets, multi point relay (mpr), olsr},<br />
} <br />
</bibtex><br />
<br />
<bibtex><br />
@inproceedings{Kubota2010Cross,<br />
author = {Flavio A. Kubota and Juliana F. Borin and Nelson L. S. da Fonseca},<br />
title = {Cross-layer Uplink Scheduler for the IEEE 802.16 standard},<br />
booktitle = {Proceedings of the IEEE Global Communications Conference},<br />
series = {GLOBECOM 2010},<br />
month = {December},<br />
year = {2010},<br />
location = {Miami, USA},<br />
numpages = {6},<br />
address = {Miami, USA},<br />
publisher = {IEEE},<br />
}<br />
</bibtex><br />
<br />
<bibtex><br />
@inproceedings{Krishnan:2010:SAA:1851182.1851235,<br />
author = {Krishnan, Sundaresan and Chaporkar, Prasanna},<br />
title = {Stochastic approximation algorithm for optimal throughput performance of wireless LANs},<br />
booktitle = {Proceedings of the ACM SIGCOMM 2010 conference on SIGCOMM},<br />
series = {SIGCOMM '10},<br />
year = {2010},<br />
isbn = {978-1-4503-0201-2},<br />
location = {New Delhi, India},<br />
pages = {409--410},<br />
numpages = {2},<br />
url = {http://doi.acm.org/10.1145/1851182.1851235},<br />
doi = {http://doi.acm.org/10.1145/1851182.1851235},<br />
acmid = {1851235},<br />
publisher = {ACM},<br />
address = {New York, NY, USA},<br />
keywords = {IEEE 802.11, hidden nodes, stochastic approximation, weighted fairness},<br />
}<br />
</bibtex><br />
<bibtex><br />
@INPROCEEDINGS{5530060, <br />
author={Paul, A.B. and Konwar, S. and Gogoi, U. and Chakraborty, A. and<br />
Yeshmin, N. and Nandi, S.}, <br />
booktitle={Education Technology and Computer (ICETC), 2010 2nd<br />
International Conference on}, title={Implementation and performance<br />
evaluation of AODV in Wireless Mesh Networks using NS-3}, <br />
year={2010}, <br />
month=june, <br />
volume={5}, <br />
number={}, <br />
pages={V5-298 -V5-303}, <br />
keywords={AODV;IETF group;NS-3;ad hoc on demand distance vector routing<br />
protocol;multihop wireless access network;network simulator;normalized<br />
routing overhead;packet delivery ratio;performance evaluation;throughput<br />
calculation;wireless mesh networks;Internet;ad hoc networks;routing<br />
protocols;wireless mesh networks;}, <br />
doi={10.1109/ICETC.2010.5530060}, <br />
ISSN={},}<br />
</bibtex><br />
<bibtex><br />
@article{DBLP:journals/corr/abs-1004-4554,<br />
author = {Hadi Arbabi and<br />
Michele C. Weigle},<br />
title = {Highway Mobility and Vehicular Ad-Hoc Networks in NS-3},<br />
journal = {CoRR},<br />
volume = {abs/1004.4554},<br />
year = {2010},<br />
ee = {http://arxiv.org/abs/1004.4554},<br />
bibsource = {DBLP, http://dblp.uni-trier.de}<br />
}<br />
</bibtex><br />
<bibtex><br />
@INPROCEEDINGS{5506341, <br />
author={Papanastasiou, Stylianos and Mittag, Jens and Strom, Erik G. and<br />
Hartenstein, Hannes}, <br />
booktitle={Wireless Communications and Networking Conference (WCNC),<br />
2010 IEEE}, title={Bridging the Gap between Physical Layer Emulation and<br />
Network Simulation}, <br />
year={2010}, <br />
month=april, <br />
volume={}, <br />
number={}, <br />
pages={1 -6}, <br />
keywords={}, <br />
doi={10.1109/WCNC.2010.5506341}, <br />
ISSN={1525-3511},}<br />
</bibtex><br />
<bibtex><br />
@inproceedings{broyles:2010:DAA,<br />
Address = {San Diego, CA},<br />
Author = {Dan Broyles and Abdul Jabbar and James P. G. Sterbenz},<br />
Booktitle = {Proceedings of the International Telemetering Conference ({ITC})},<br />
Date-Added = {2010-05-31 15:23:53 -0500},<br />
Date-Modified = {2010-05-31 15:32:16 -0500},<br />
Month = {October},<br />
Title = {Design and analysis of a {3--D} Gauss-Markov Mobility Model for Highly-Dynamic Airborne Networks},<br />
Year = {2010}}<br />
</bibtex><br />
<bibtex><br />
@inproceedings{Cetinkaya:2010:ACF,<br />
author = "Egemen K. &Ccedil;etinkaya and Dan Broyles and Amit Dandekar and Sripriya Srinivasan and James P.G. Sterbenz",<br />
title = "A Comprehensive Framework to Simulate Network Attacks and Challenges",<br />
booktitle = {Proceedings of the IEEE/IFIP Second International Workshop on Reliable Networks Design and Modeling (RNDM)},<br />
year = {2010},<br />
month = {October},<br />
address = {Moscow, Russia},<br />
pages = {538--544},<br />
doi = {http://dx.doi.org/10.1109/ICUMT.2010.5676585},<br />
biburl = {https://wiki.ittc.ku.edu/resilinets/Bib-Cetinkaya-Broyles-Dandekar-Srinivasan-Sterbenz-2010},<br />
url = {http://www.ittc.ku.edu/resilinets/papers/Cetinkaya-Broyles-Dandekar-Srinivasan-Sterbenz-2010.pdf}<br />
}<br />
</bibtex><br />
<br />
<bibtex><br />
@inproceedings{1815404,<br />
author = {Hrizi, Fatma and Filali, Fethi},<br />
title = {simITS: an integrated and realistic simulation platform for vehicular networks},<br />
booktitle = {IWCMC '10: Proceedings of the 6th International Wireless Communications and Mobile Computing Conference},<br />
year = {2010},<br />
isbn = {978-1-4503-0062-9},<br />
pages = {32--36},<br />
location = {Caen, France},<br />
doi = {http://doi.acm.org/10.1145/1815396.1815404},<br />
publisher = {ACM},<br />
address = {New York, NY, USA},<br />
}<br />
</bibtex><br />
<br />
<bibtex><br />
@inproceedings{vutukuru2009cross-layer,<br />
author = "Mythili Vutukuru and Hari Balakrishnan and Kyle Jamieson",<br />
title = "Cross-Layer Wireless Bit Rate Adaptation",<br />
booktitle = {ACM SIGCOMM '09: Proceedings of the ACM SIGCOMM 2009 conference on Data<br />
communication},<br />
year = {2009},<br />
month = {August},<br />
address = {Barcelona, Spain},<br />
url = {http://nms.csail.mit.edu/papers/sigcomm258-vutukuru.pdf}<br />
}<br />
</bibtex><br />
<br />
<bibtex><br />
@inproceedings{lipsin,<br />
address = {New York, NY, USA},<br />
author = {Petri Jokela and Andr\'{a}s Zahemszky and Christian Esteve Rothenberg and Somaya Arianfar and Pekka Nikander},<br />
booktitle = {ACM SIGCOMM '09: Proceedings of the ACM SIGCOMM 2009 conference on Data<br />
communication},<br />
interhash = {d460bc0ba3aa60c7312482e1304cfa18},<br />
intrahash = {0a200b6790f53be5f0621e992b8875a3},<br />
pages = {195--206},<br />
publisher = {ACM},<br />
title = {LIPSIN: Line Speed Publish/Subscribe Inter-networking},<br />
year = 2009,<br />
keywords = {imported},<br />
added-at = {2010-04-06T16:35:05.000+0200},<br />
location = {Barcelona, Spain},<br />
isbn = {978-1-60558-594-9},<br />
biburl = {http://www.bibsonomy.org/bibtex/20a200b6790f53be5f0621e992b8875a3/chesteve},<br />
doi = {http://doi.acm.org/10.1145/1592568.1592592}<br />
url = {http://ccr.sigcomm.org/online/?q=node/491}<br />
}<br />
</bibtex><br />
<br />
<bibtex><br />
@inproceedings{1639905,<br />
author = {Pelov, Alexander Pelov and Noel, Thomas},<br />
title = {Creating advanced mobility models with LEMMA},<br />
booktitle = {SpringSim '09: Proceedings of the 2009 Spring Simulation Multiconference},<br />
year = {2009},<br />
pages = {1--8},<br />
location = {San Diego, California},<br />
publisher = {Society for Computer Simulation International},<br />
address = {San Diego, CA, USA},<br />
}<br />
</bibtex><br />
<br />
<bibtex><br />
@inproceedings{1711117,<br />
author = {Trisnawan, Primantara Hari and Budiarto, Rahmat},<br />
title = {Priority-based QoS mechanism for multiple multicast IPTV streams},<br />
booktitle = {AINTEC '09: Asian Internet Engineering Conference},<br />
year = {2009},<br />
isbn = {978-1-60558-614-4},<br />
pages = {19--24},<br />
location = {Bangkok, Thailand},<br />
doi = {http://doi.acm.org/10.1145/1711113.1711117},<br />
publisher = {ACM},<br />
address = {New York, NY, USA},<br />
}<br />
</bibtex><br />
<br />
<bibtex><br />
@inproceedings{1346061,<br />
author = {Bracuto, Michele and D'Angelo, Gabriele},<br />
title = {Detailed Simulation of Large-Scale Wireless Networks},<br />
booktitle = {DS-RT '07: Proceedings of the 11th IEEE International Symposium on Distributed Simulation and Real-Time Applications},<br />
year = {2007},<br />
isbn = {0-7695-3011-7},<br />
pages = {268--275},<br />
doi = {http://dx.doi.org/10.1109/DS-RT.2007.19},<br />
publisher = {IEEE Computer Society},<br />
address = {Washington, DC, USA},<br />
}<br />
</bibtex><br />
<br />
<bibtex><br />
@inproceedings{maguolo:mediawin2008,<br />
author={Federico Maguolo and Mathieu Lacage and Thierry Turletti},<br />
title={Efficient Collision Detection for Auto Rate Fallback Algorithm},<br />
booktitle={Third Workshop on multiMedia Applications over Wireless Networks (MediaWiN 2008)},<br />
month={July},<br />
year={2008},<br />
url={ftp://ftp-sop.inria.fr/rodeo/turletti/mediawin08.pdf}<br />
}<br />
</bibtex><br />
<br />
<bibtex><br />
@inproceedings{kopena:netdb2007,<br />
author={Joseph B. Kopena and Boon Thau Loo},<br />
title={OntoNet: Scalable Knowledge Based Networking},<br />
booktitle={4th International Workshop on Networking Meets Databases},<br />
month={April},<br />
year={2008},<br />
url={http://www.cis.upenn.edu/~boonloo/papers/ontonet.pdf}<br />
}<br />
</bibtex><br />
<br />
<bibtex><br />
@inproceedings{1641895,<br />
author = {Tazaki, Hajime and Van Meter, Rodney and Wakikawa, Ryuji and Wongsaardsakul, Thirapon and Kanchanasut, Kanchana and Dias de Amorim, Marcelo and Murai, Jun},<br />
title = {Selecting an appropriate routing protocol for in-field MANEMO experiments},<br />
booktitle = {PE-WASUN '09: Proceedings of the 6th ACM symposium on Performance evaluation of wireless ad hoc, sensor, and ubiquitous networks},<br />
year = {2009},<br />
isbn = {978-1-60558-618-2},<br />
pages = {101--107},<br />
location = {Tenerife, Canary Islands, Spain},<br />
doi = {http://doi.acm.org/10.1145/1641876.1641895},<br />
publisher = {ACM},<br />
address = {New York, NY, USA},<br />
}<br />
</bibtex><br />
<br />
<bibtex><br />
@inproceedings{sigcomm2009,<br />
author={Shivkumar C. Muthukumar and Xiaozhou Li and Changbin Liu and Joseph B. Kopena and Mihai Oprea and Boon Thau Loo},<br />
title={Declarative Toolkit for Rapid Network Protocol Simulation and Experimentation},<br />
booktitle={ACM SIGCOMM Conference on Data Communications (demo)},<br />
month={August},<br />
year={2009},<br />
}<br />
</bibtex><br />
<br />
<bibtex><br />
@inproceedings{wintech2009,<br />
author={Shivkumar C. Muthukumar and Xiaozhou Li and Changbin Liu and Joseph B. Kopena and Mihai Oprea and Richardo Correa and Boon Thau Loo and Prithwish Basu},<br />
title={RapidMesh: Declarative Toolkit for Rapid Experimentation of Wireless Mesh Networks}, <br />
booktitle={4th ACM International Workshop on Wireless Network Testbeds, Experimental Evaluation and Characterization (WiNTECH 2009), in conjunction with ACM MobiCom}, <br />
month={September},<br />
year={2009},<br />
</bibtex><br />
<br />
<bibtex><br />
@inproceedings{simutools2009,<br />
author={Fatma Hrizi and Fethi Filali},<br />
title={An Integrated and Realistic Simulation Platform for Vehicular Networks}, <br />
booktitle={SIMUTools 2010 Conference, Poster Session},<br />
month={March},<br />
year={2010},<br />
url={http://www.simutools.org/Programme/AcceptedPosters}<br />
</bibtex><br />
<br />
<bibtex><br />
@inproceedings{simutools2009,<br />
author={Fabian Mauchle and Sandra Frei and Andreas Rinkel},<br />
title={Simulating Mobile IPv6 with ns-3},<br />
booktitle={SIMUTools 2010 Conference, Poster Session},<br />
month={March},<br />
year={2010},<br />
url={http://www.simutools.org/Programme/AcceptedPosters}<br />
</bibtex><br />
<br />
<bibtex><br />
@inproceedings{simutools2009,<br />
author={Luiz Felipe Perrone and Bryan Ward and Andrew Hallagan},<br />
title={An Experiment Automation Framework for ns-3},<br />
booktitle={SIMUTools 2010 Conference, Poster Session},<br />
month={March},<br />
year={2010},<br />
url={http://www.simutools.org/Programme/AcceptedPosters}<br />
</bibtex><br />
<br />
<br />
== Papers about good simulation practices ==<br />
<br />
Please read these papers if you would like to improve the credibility of your simulation work:<br />
<bibtex><br />
@article{1096174,<br />
author = {Stuart Kurkowski and Tracy Camp and Michael Colagrosso },<br />
title = {MANET simulation studies: the incredibles},<br />
journal = {SIGMOBILE Mob. Comput. Commun. Rev.},<br />
volume = {9},<br />
number = {4},<br />
year = {2005},<br />
issn = {1559-1662},<br />
pages = {50--61},<br />
doi = {http://doi.acm.org/10.1145/1096166.1096174},<br />
publisher = {ACM},<br />
address = {New York, NY, USA},<br />
url = {http://portal.acm.org/citation.cfm?id=1096166.1096174#}<br />
}<br />
</bibtex><br />
<br />
<bibtex><br />
@article{stojmenovic2008sws,<br />
title={Simulations in wireless sensor and ad hoc networks: matching and advancing models, metrics, and solutions},<br />
author={Ivan Stojmenovic},<br />
journal={IEEE Communications Magazine},<br />
volume={46},<br />
number={12},<br />
pages={102--107},<br />
year={2008}<br />
}<br />
</bibtex><br />
<br />
[http://www.cc.gatech.edu/~ammar/presentations/ANSS/ANSS-KEY_files/frame.htm “Why We STILL Don’t Know How to Simulate Networks”]<br />
–Mostafa Ammar, Georgia Institute of Technology, Annual Simulation Symposium 2005 <br />
<br />
[http://www.icir.org/floyd/talks/WNS2-Oct06.pdf “Maintaining a Critical Attitude Towards Simulation Results”]<br />
–Sally Floyd, WNS2 Workshop Keynote, October 2006<br />
<br />
[http://www.stormingmedia.us/15/1505/A150504.html “An Integrated Approach to Evaluating Simulation Credibility”] <br />
–Muessig, Laack, and Wrobleski, U.S. Naval Air Warfare Center, August 2001</div>Nicolabaldo