Nsnam - User contributions [en]

GSOC2022Projects

2022-01-27T08:46:21Z

Mkrana: /* Dynamic IPv6 Address Configuration for LTE */

{{TOC}}

This page contains 2022 Google Summer of Code project ideas for ns-3.

* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]
* [[GSOC2022StudentGuide |ns-3's 2022 GSoC Student guide]]
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]
* [[GSOC2022StudentApplicationTemplate |2022 GSoC Student application template]]
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]
* [[GSOCSelectionProcess | GSoC Student Selection Process]]
* ''Get in contact with the ns-3 team'': [http://mailman.isi.edu/mailman/listinfo/ns-developers ns-developers mailing list] | ''chat'' https://ns-3.zulipchat.com/

=== About the ns-3 project ===

ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.

Users of ns-3 can construct simulations of computer networks using models of traffic generators, protocols such as TCP/IP, and devices and channels such as WiFi, and analyze or visualize the results. Simulation plays a vital role in the research and education process, because of the ability for simulations to obtain reproducible results (particularly for wireless protocol design), scale to large networks, and study systems that have not yet been implemented. A particular emphasis in ns-3 is the high degree of realism in the models (including frameworks for real application and kernel code) and integration of the tool with virtual machine environments and testbeds; we view that researchers need to move more effortlessly between simulation, testbeds, and live experiments, and ns-3 is designed to facilitate that.

ns-3 has participated in past GSoCs during 2008-10, 2012-15, and 2017-21. We seek students interested in the intersection of wireless and computer networking, performance analysis, and open source software.

=== Org admins ===

Google Summer of Code organizational admins for ns-3 are [mailto:tpecorella@mac.com Tommaso Pecorella] and [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com Zulip].

=== Mentors ===

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 Mohit P. Tahiliani or Tommaso Pecorella of interest. Mentors familiar with ns-3 development practices will be preferred, to improve the chances of student code merge. In 2022, we are going to be seeking two-person or multiple-person mentoring teams for projects, to help with the mentoring workload and bring more expertise.

The current list of prospective mentors for 2022 will be posted below:

*To be posted at a later date*

=== Changes from last year ===

Google has changed the program again, allowing us to define medium-sized (175 hours) and large-sized (350 hours) projects. Therefore, we will be seeking to define projects with different scopes, accordingly. In general, we seek projects that aim to improve the existing simulator rather than add new features. Google also is opening participation to non-students (18-years or older).

=== How to apply ===

For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:
* Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC student guide].
* Read [[GSOC2022StudentGuide |ns-3's GSoC Student guide]]
* Look through our [[#Project Ideas]] below to see if you find a project that interests you.
* Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.
* Once it is posted, look through the [[GSOC2022StudentApplicationTemplate |GSoC Student application template]] to start preparing your proposal. We will wait to see whether we are actually part of GSoC before posting this.
* Next, proceed to get in touch with the developers on the mailing list or chat room and refine your proposal.
* In parallel, make sure you prepare a patch as per the patch requirement guidelines. Your application to ns-3 will not be considered if you do not fulfill this requirement.

Below is a list of [[#Project Ideas]] proposed by the ns-3 team for Google Summer of Code 2022. 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.

<blockquote>
Each project idea within a particular priority has been tagged with the following properties:
* ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.
* ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.
* ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful students might apply their experiences coming out of this project.
* ''Difficulty:'' easy, medium or difficult
* ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.

Note that all of the projects require some experience and comfort with C++. Project ideas for which C++ is noted as a required experience will require more and deeper familiarity with the language. A similar notion applies to computer networking, BSD sockets, etc: Familiarity is strongly preferred, but is not required except where explicitly noted due to the topic being more advanced in that regard. A few projects are more Python-centric.
</blockquote>

=== Patch requirement guidelines ===

Each project idea has (or will have) a list of proposed tasks that a student must do to ensure his/her ability to carry out the idea successfully. Performing one task is necessary for a successful application, and performing more than one task is ''not'' necessary.

If a student wants to work on a proposed task he/she should immediately contact the mentor(s) to "claim" that task - in order to avoid (where needed) that multiple students are on the same task. A task might involve fixing a specific open issue, or adding some functionalities to the existing code.

Students that did already contribute to the ns-3 codebase with non-trivial bug fixing or features additions might be exempted from performing a task. If you have doubts about if your contributions made you eligible for the task exemption contact the mentors.

=== Mentors: how to participate ===

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:

* The projects are sized such that there can be a code merge by the end of the coding period. The scope of the project should be such that it is very difficult to *not* have a code merge by the end of the summer.
* The proposed projects are not too open-ended. That is, if the deliverables or a clear path to the same are not well understood, it is better kept outside GSOC.
* There should be a clear merge path to one of the main project code repositories (ns-3-dev, ns-3-dce, bake) by the end of the summer, either because the patches directly apply to these repositories, or because they apply to an ns-3 module that is in the process of being merged with ns-3-dev.

== Project Ideas ==

'''Note to students:''' These ideas are not listed in any priority order. If an idea doesn't have a mentor yet, it means that if you are interested, you should announce your interest and see if there is a mentor who might pick it up.

==== Linux-like Loss Detection Techniques for ns-3 TCP ====

Mentors:This project is a carryover from 2021; it will be a candidate if mentors are available.

Forward Acknowledgement (FACK), Duplicate Selective Acknowledgement (DSACK), Tail Loss Probe (TLP) and Recent Acknowledgement (RACK) are the loss detection techniques implemented in the Linux kernel. These techniques have been already implemented for ns-3 TCP but their code is not yet merged into the mainline. This project has four main goals: (1) update the implementation of these techniques according to the latest ns-3-dev, (2) develop a framework to test the functionality of these techniques, (3) develop example program(s) to demonstrate the usage of these techniques in ns-3 and (4) merge these techniques in the mainline of ns-3.

* ''Required Experience:'' Familiarity with TCP and C++ programming.
* ''Bonus Experience:'' Familiarity with TCP implementation in Linux kernel.
* ''Interests:'' TCP packet loss detection techniques.
* ''Difficulty:'' Medium to Hard.
* ''Recommended Reading:''
** Forward Acknowledgement (FACK) [[https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.41.2559&rep=rep1&type=pdf Paper]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]
** Duplicate Selective Acknowledgment (DSACK) [[https://tools.ietf.org/html/rfc2883 RFC 2883]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]
** Tail Loss Probe (TLP) [[https://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01 Internet Draft]] [[https://gitlab.com/ShikhaBakshi/ns-3-dev/-/commits/TLP Implementation]]
** Recent Acknowledgment (RACK) [[https://tools.ietf.org/html/draft-ietf-tcpm-rack-15 Internet Draft]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]

==== LoRaWAN ====

Mentor: This project is a carryover from 2021; it will be a candidate if mentors are available.

LoRaWAN is a communication technology for the Internet of Things, that allows battery-powered devices to wirelessly transmit data over long distances. Thanks to the lorawan module for ns-3, users can simulate networks where thousands of such devices communicate with a central server through multiple gateways. Packets might collide and be lost, devices might need to re-transmit them, and the central server can tell devices to change their transmission parameters according to suitable, exotic algorithms - we model it all.

This module rapidly grew in the last period, with the addition of various features and functionalities that are not completely tested nor documented, yet. In this project, you will mostly work to (1) integrate these features into the mainline code, and (2) improve the LoRaWAN module's testing and documentation.

Additionally, according to time availability and your interest, you can also help showcasing the potentialities of the lorawan module through the SEM library. Indeed, SEM can be used together with the lorawan module to provide users with meaningful examples, with the dual objective of giving a better understanding of what is going on within a single simulation, as well as how a simulation campaign can be easily conducted.

* ''Required Experience'': Familiarity with C++ programming and the LoRaWAN standard.
* ''Bonus Experience'': Familiarity with Python programming.
* ''Interests'': Internet of Things communication protocols.
* ''Difficulty'': Medium to Hard.
* ''For more info'': https://github.com/signetlabdei/lorawan, http://github.com/signetlabdei/sem
* ''Patch requirement'': Create a pull request that fixes any of the following issues in the lorawan repo:
** Test, fix and make sure the us915 branch works as expected, helping merge it into develop https://github.com/signetlabdei/lorawan/issues/32
** Write a documentation entry describing how the Network Server works, or fix any other point in this issue: https://github.com/signetlabdei/lorawan/issues/58

==== SEM - Examples and documentation ====

Mentor: This project is a carryover from 2021; it will be a candidate if mentors are available.

The SEM Python library was designed to help ns-3 users run complex simulation campaigns. Among other things, SEM strives to make it as easy as possible to parse the output of simulations and to obtain plots that show the impact of simulation parameters on the network's performance.

One of the objectives for the next big SEM release is to provide users with more examples that are both easy to modify and that showcase the full potential of the library and of the Python data analysis ecosystem. In this project, your objective will be to show how SEM can be used from within Jupyter Notebooks to gradually explore the behavior of a network. Aside from the creation of new examples, you will also have the opportunity to try your hand at the all-important task of writing documentation. If there's time and you feel like tackling the issue, in a second part of the project you will also explore how SEM can be used to visualize the behavior of single simulations that leverage ns-3's built-in logging.

* ''Required Experience'': Familiarity with Python and C++ programming.
* ''Bonus Experience'': Familiarity with Jupyter Notebooks.
* ''Difficulty'': Medium.
* ''For more info'': http://github.com/signetlabdei/sem
* ''Patch requirement'': Create a pull request completing any of the following tasks:
** Create a new example SEM script, that runs a program different from wifi-multi-tos and plots some meaningful result
** Add a test that improves the codecov score (you can do this either on the develop branch or on the newrelease branch)

==== Upgrade the AQM Evaluation Suite for ns-3 ====

Mentors: This project is a carryover from 2021; it will be a candidate if mentors are available.

AQM (Active Queue Management) evaluation suite for ns-3 helps to quickly study the performance of AQM algorithms based on the guidelines mentioned in RFC 7928. This suite automates simulation setup, topology creation, traffic generation, program execution, results collection and their graphical representation using ns-3 based on the scenarios mentioned in RFC 7928. It was designed and developed in 2017 and actively maintained till 2019. In the past two years, the traffic control model in ns-3 has grown significantly in terms of supporting state-of-the-art packet scheduling and AQM algorithms. This project has four main goals: (1) upgrade the AQM Evaluation Suite according to the latest ns-3-dev, (2) enable support for latest packet scheduling, AQM algorithms and ECN functionality (3) update the examples in AQM Evaluation Suite to better suit the needs of researchers working in this area, and (4) make AQM Evaluation Suite available on the ns-3 app store.

* ''Required Experience:'' Familiarity with AQM and C++ programming.
* ''Bonus Experience:'' Familiarity with traffic control model in ns-3.
* ''Interests:'' Packet Scheduling algorithms, AQM algorithms and ECN.
* ''Difficulty:'' Medium.
* ''Recommended Reading:''
** AQM Evaluation Suite [[https://dl.acm.org/doi/abs/10.1145/3067665.3067674 Paper]] [[https://aqm-eval-suite.github.io/ Implementation]]
** [https://tools.ietf.org/html/rfc7928 RFC 7928]
** [https://www.nsnam.org/docs/models/html/traffic-control-layer.html Traffic Control Model in ns-3]
* ''Patch requirement:'' Create a pull request to handle the case when an incorrect Scenario name or number is passed via command line. Examples:
** ''./waf --run "aqm-eval-suite-runner --name=<unsupported scenario>"''
** ''./waf --run "aqm-eval-suite-runner --number=<unsupported number>"''

==== TCP maximum segment size (MSS) improvements ====

Mentors: This project is a carryover from 2021; it will be a candidate if mentors are available.

TCP performances are affected by the maximum segment size (MSS) - a wrong choice might either lead to inefficient transmission (higher overhead) or IP fragmentation.

At the moment ns-3 implementation allows to set the MSS via an Attribute (set by default to 536 bytes by TcpSocket Attribute "SegmentSize").
Although it is stated that it "may be adjusted based on MTU discovery", its value is not changed in a simulation.

The goal of the project is to update the MSS handling, allowing to:
1) Set it to a fixed size, or allowing auto-probing of "optimal" MSS,
2) Use and honor the TcpOptionMSS (RFC 793), with a proper example of use, and
3) React to intermediate links with short MTU, and/or to changes in the Path MTU (PMTU).

The last point is to be carefully handled, as in many points in the code there is an implicit assumption that the MSS is constant in a given flow.

Moreover, note that finding the optimal PMTU is not that simple, as IPv6 and IPv4 react differently to packets exceeding the link MTU, and they won't notify if a packet is shorter than the link MTU.
As a consequence, it would be useful to implement the Packetization Layer Path MTU Discovery (RFC 4821) - which might exceed the GSoC timeframe.

Hence, it would be advisable to carefully select the features to be supported and tested in the project, eventually paving the ground for future enhancements.

* ''Required Experience:'' Familiarity with TCP, IPv4 and IPv6, and in particular with fragmentation.
* ''Difficulty:'' Medium / Hard
* ''Recommended reading:''
** [https://en.wikipedia.org/wiki/Path_MTU_Discovery Wikipedia: Path MTU Discovery]
** [https://www.nsnam.org/bugzilla/show_bug.cgi?id=2064 UdpSocket::GetMtu() needed]
** [https://www.nsnam.org/bugzilla/show_bug.cgi?id=1751 TCP should react to MTU changes]
** [https://tools.ietf.org/html/rfc1191 RFC 1191]
** [https://tools.ietf.org/html/rfc4821 RFC 4821]
** [https://tools.ietf.org/html/rfc1122#page-85 RFC 1122]
** [https://tools.ietf.org/html/rfc6691 RFC 6991]
** [https://tools.ietf.org/html/rfc2923 RFC 2923]
** [https://blog.apnic.net/2014/12/15/ip-mtu-and-tcp-mss-missmatch-an-evil-for-network-performance/ APNIC blog - IP MTU and TCP MSS Missmatch – an evil for network performance]
** [https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3650/software/release/16-9/configuration_guide/ip/b_169_ip_3650_cg/configuring_tcp_mss_adjustment.pdf Cisco - Configuring TCP MSS Adjustment]

==== Enable IPv6 support for Ad hoc Routing Protocols in ns-3 ====

Mentors: This project is a carryover from 2021; it will be a candidate if mentors are available.

ns-3 contains models for proactive (DSDV and OLSR) and reactive (AODV and DSR) ad hoc routing protocols. However, these models are IPv4-only and do not provide support of IPv6 addressing. This project aims to enable IPv6 support for ad hoc routing protocols in ns-3, mainly for AODV. There are out-of-tree implementations of OLSR and DSDV that provide support for IPv6 addressing, and can be used as references to get started with this project.

The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.

Note: Enabling IPv6 support for these protocols is not a matter of simply changing out an IPv4-formatted address for an IPv6-formatted address. The IPv6 addressing architecture emphasizes scoping much more than does IPv4 (RFC 4007). Please suggest in your application how IPv6 address configuration (and possibly auto-configuration?) and address scopes (e.g. link-local vs. global) should be used in these protocols. Consulting the RFCs is highly recommended.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3
* ''Interests:'' Ad hoc routing
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]
** [https://www.nsnam.org/workshops/wns3-2016/posters/IPv6-support-for-OLSR.pdf IPv6 Support for OLSR in ns-3]

Possible tasks to fulfill the patch requirement:

* [https://gitlab.com/nsnam/ns-3-dev/-/issues/271 Issue #271] - olsr header and messages are not printing either their size or their content.
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values

==== IPv6 global routing ====

Mentors: This project is a carryover from 2021; it will be a candidate if mentors are available.

Creating a complex topology can be a problem, and sometimes the user do not want to be (also) concerned about setting up dynamic routing protocols (e.g., RIP, RIPng).
For IPv4, ns-3 provides two alternatives: GlobalRouting, and NixRouting, which just "do the trick" - they simply fill the routing tables in intermediate nodes, GlobalRouting using an approach similar to OSPF, NixRouting by leveraging the "abstract" knowledge of the network.
Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.

The problem is that they don't work for IPv6, and that's a huge limitation. The goal of the project is to fix that limitation. Note that the project must cope with different IPv6 address kinds (link-local, global, scoped multicast, etc.). Due to the limitation with GlobalRouting w.r.t. wireless channels, it would be advisable to start working with NixRouting.

The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with NixRouting and GlobalRouting implementations in ns-3
* ''Interests:'' IPv6 routing
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/docs/models/html/nix-vector-routing.html NixRouting model in ns-3]
** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]

Possible tasks to fulfill the patch requirement:
* Add a function to print the path that a packet will use (according to Ipv4NixVectorRouting), i.e., given source and destination IP print the IP addresses of the nodes that Ipv4NixVectorRouting will use.
* Add a function to print the path that a packet will use (according to Ipv4GlobalRouting), i.e., given source and destination IP print the IP addresses of the nodes that Ipv4GlobalRouting will use.

==== Dynamic IPv6 Address Configuration for LTE ====

Mentors: This project is a new project; it will be a candidate if mentors are available.

This project aims to enable the feature of supporting more than one EPCs in LTE module of ns-3. Currently IPv6 support is available in LTE module, but IPv6 address assignment to EPC components like PGW, eNB and UE is static. Manual IPv6 address assignment was there, and so when create another instance of EPC, it configures with the same IPv6 address for the components. Although the interface id will be different for different components, but the initial 64 bit prefix will remain same, hence it is creating conflict in routing for more than one EPCs in a topology. Hence we need to propose a dynamic IPv6 address scheme over there and the implementation will enable two UEs from two EPCs are communicating successfully without any routing conflict.

While you are thinking about any IPv6 layer solution in this case, you will stuck by some issues like, https://www.nsnam.org/bugzilla/show_bug.cgi?id=2835 this i.e. the LTE eNB RRC configuration issue the UL-DL spectrum allocation issue for two EPCs. So, the most important part of this project is to eliminate these issues first i.e. RRC configuration and spectrum allocation must be flexible to be allocated for two different EPCs' eNBs and then the proper addressing scheme.

* ''Required Experience:'' Fundamentals of IPv6 addressing and routing, ICMPv6-based Neighbor Discovery, C++ programming.
* ''Bonus Experience:'' Familiarity with IPv6 support and L3 layer control signaling in ns-3 LTE module
* ''Interests:'' IPv6 address configuration
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/docs/models/html/lte-design.html#epc-data-plane LTE EPC data plane functionalities of LTE module in ns-3]
** [https://www.nsnam.org/docs/models/html/lte-design.html#s1-s5-and-s11 S1 and S5 data flow of LTE module in ns-3]
** [https://datatracker.ietf.org/doc/html/rfc4861 Neighbor Discovery for IP version 6 (IPv6)]

GSOC2022Projects

2022-01-27T08:44:49Z

Mkrana:

{{TOC}}

This page contains 2022 Google Summer of Code project ideas for ns-3.

* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]
* [[GSOC2022StudentGuide |ns-3's 2022 GSoC Student guide]]
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]
* [[GSOC2022StudentApplicationTemplate |2022 GSoC Student application template]]
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]
* [[GSOCSelectionProcess | GSoC Student Selection Process]]
* ''Get in contact with the ns-3 team'': [http://mailman.isi.edu/mailman/listinfo/ns-developers ns-developers mailing list] | ''chat'' https://ns-3.zulipchat.com/

=== About the ns-3 project ===

ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.

Users of ns-3 can construct simulations of computer networks using models of traffic generators, protocols such as TCP/IP, and devices and channels such as WiFi, and analyze or visualize the results. Simulation plays a vital role in the research and education process, because of the ability for simulations to obtain reproducible results (particularly for wireless protocol design), scale to large networks, and study systems that have not yet been implemented. A particular emphasis in ns-3 is the high degree of realism in the models (including frameworks for real application and kernel code) and integration of the tool with virtual machine environments and testbeds; we view that researchers need to move more effortlessly between simulation, testbeds, and live experiments, and ns-3 is designed to facilitate that.

ns-3 has participated in past GSoCs during 2008-10, 2012-15, and 2017-21. We seek students interested in the intersection of wireless and computer networking, performance analysis, and open source software.

=== Org admins ===

Google Summer of Code organizational admins for ns-3 are [mailto:tpecorella@mac.com Tommaso Pecorella] and [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com Zulip].

=== Mentors ===

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 Mohit P. Tahiliani or Tommaso Pecorella of interest. Mentors familiar with ns-3 development practices will be preferred, to improve the chances of student code merge. In 2022, we are going to be seeking two-person or multiple-person mentoring teams for projects, to help with the mentoring workload and bring more expertise.

The current list of prospective mentors for 2022 will be posted below:

*To be posted at a later date*

=== Changes from last year ===

Google has changed the program again, allowing us to define medium-sized (175 hours) and large-sized (350 hours) projects. Therefore, we will be seeking to define projects with different scopes, accordingly. In general, we seek projects that aim to improve the existing simulator rather than add new features. Google also is opening participation to non-students (18-years or older).

=== How to apply ===

For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:
* Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC student guide].
* Read [[GSOC2022StudentGuide |ns-3's GSoC Student guide]]
* Look through our [[#Project Ideas]] below to see if you find a project that interests you.
* Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.
* Once it is posted, look through the [[GSOC2022StudentApplicationTemplate |GSoC Student application template]] to start preparing your proposal. We will wait to see whether we are actually part of GSoC before posting this.
* Next, proceed to get in touch with the developers on the mailing list or chat room and refine your proposal.
* In parallel, make sure you prepare a patch as per the patch requirement guidelines. Your application to ns-3 will not be considered if you do not fulfill this requirement.

Below is a list of [[#Project Ideas]] proposed by the ns-3 team for Google Summer of Code 2022. 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.

<blockquote>
Each project idea within a particular priority has been tagged with the following properties:
* ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.
* ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.
* ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful students might apply their experiences coming out of this project.
* ''Difficulty:'' easy, medium or difficult
* ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.

Note that all of the projects require some experience and comfort with C++. Project ideas for which C++ is noted as a required experience will require more and deeper familiarity with the language. A similar notion applies to computer networking, BSD sockets, etc: Familiarity is strongly preferred, but is not required except where explicitly noted due to the topic being more advanced in that regard. A few projects are more Python-centric.
</blockquote>

=== Patch requirement guidelines ===

Each project idea has (or will have) a list of proposed tasks that a student must do to ensure his/her ability to carry out the idea successfully. Performing one task is necessary for a successful application, and performing more than one task is ''not'' necessary.

If a student wants to work on a proposed task he/she should immediately contact the mentor(s) to "claim" that task - in order to avoid (where needed) that multiple students are on the same task. A task might involve fixing a specific open issue, or adding some functionalities to the existing code.

Students that did already contribute to the ns-3 codebase with non-trivial bug fixing or features additions might be exempted from performing a task. If you have doubts about if your contributions made you eligible for the task exemption contact the mentors.

=== Mentors: how to participate ===

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:

* The projects are sized such that there can be a code merge by the end of the coding period. The scope of the project should be such that it is very difficult to *not* have a code merge by the end of the summer.
* The proposed projects are not too open-ended. That is, if the deliverables or a clear path to the same are not well understood, it is better kept outside GSOC.
* There should be a clear merge path to one of the main project code repositories (ns-3-dev, ns-3-dce, bake) by the end of the summer, either because the patches directly apply to these repositories, or because they apply to an ns-3 module that is in the process of being merged with ns-3-dev.

== Project Ideas ==

'''Note to students:''' These ideas are not listed in any priority order. If an idea doesn't have a mentor yet, it means that if you are interested, you should announce your interest and see if there is a mentor who might pick it up.

==== Linux-like Loss Detection Techniques for ns-3 TCP ====

Mentors:This project is a carryover from 2021; it will be a candidate if mentors are available.

Forward Acknowledgement (FACK), Duplicate Selective Acknowledgement (DSACK), Tail Loss Probe (TLP) and Recent Acknowledgement (RACK) are the loss detection techniques implemented in the Linux kernel. These techniques have been already implemented for ns-3 TCP but their code is not yet merged into the mainline. This project has four main goals: (1) update the implementation of these techniques according to the latest ns-3-dev, (2) develop a framework to test the functionality of these techniques, (3) develop example program(s) to demonstrate the usage of these techniques in ns-3 and (4) merge these techniques in the mainline of ns-3.

* ''Required Experience:'' Familiarity with TCP and C++ programming.
* ''Bonus Experience:'' Familiarity with TCP implementation in Linux kernel.
* ''Interests:'' TCP packet loss detection techniques.
* ''Difficulty:'' Medium to Hard.
* ''Recommended Reading:''
** Forward Acknowledgement (FACK) [[https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.41.2559&rep=rep1&type=pdf Paper]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]
** Duplicate Selective Acknowledgment (DSACK) [[https://tools.ietf.org/html/rfc2883 RFC 2883]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]
** Tail Loss Probe (TLP) [[https://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01 Internet Draft]] [[https://gitlab.com/ShikhaBakshi/ns-3-dev/-/commits/TLP Implementation]]
** Recent Acknowledgment (RACK) [[https://tools.ietf.org/html/draft-ietf-tcpm-rack-15 Internet Draft]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]

==== LoRaWAN ====

Mentor: This project is a carryover from 2021; it will be a candidate if mentors are available.

LoRaWAN is a communication technology for the Internet of Things, that allows battery-powered devices to wirelessly transmit data over long distances. Thanks to the lorawan module for ns-3, users can simulate networks where thousands of such devices communicate with a central server through multiple gateways. Packets might collide and be lost, devices might need to re-transmit them, and the central server can tell devices to change their transmission parameters according to suitable, exotic algorithms - we model it all.

This module rapidly grew in the last period, with the addition of various features and functionalities that are not completely tested nor documented, yet. In this project, you will mostly work to (1) integrate these features into the mainline code, and (2) improve the LoRaWAN module's testing and documentation.

Additionally, according to time availability and your interest, you can also help showcasing the potentialities of the lorawan module through the SEM library. Indeed, SEM can be used together with the lorawan module to provide users with meaningful examples, with the dual objective of giving a better understanding of what is going on within a single simulation, as well as how a simulation campaign can be easily conducted.

* ''Required Experience'': Familiarity with C++ programming and the LoRaWAN standard.
* ''Bonus Experience'': Familiarity with Python programming.
* ''Interests'': Internet of Things communication protocols.
* ''Difficulty'': Medium to Hard.
* ''For more info'': https://github.com/signetlabdei/lorawan, http://github.com/signetlabdei/sem
* ''Patch requirement'': Create a pull request that fixes any of the following issues in the lorawan repo:
** Test, fix and make sure the us915 branch works as expected, helping merge it into develop https://github.com/signetlabdei/lorawan/issues/32
** Write a documentation entry describing how the Network Server works, or fix any other point in this issue: https://github.com/signetlabdei/lorawan/issues/58

==== SEM - Examples and documentation ====

Mentor: This project is a carryover from 2021; it will be a candidate if mentors are available.

The SEM Python library was designed to help ns-3 users run complex simulation campaigns. Among other things, SEM strives to make it as easy as possible to parse the output of simulations and to obtain plots that show the impact of simulation parameters on the network's performance.

One of the objectives for the next big SEM release is to provide users with more examples that are both easy to modify and that showcase the full potential of the library and of the Python data analysis ecosystem. In this project, your objective will be to show how SEM can be used from within Jupyter Notebooks to gradually explore the behavior of a network. Aside from the creation of new examples, you will also have the opportunity to try your hand at the all-important task of writing documentation. If there's time and you feel like tackling the issue, in a second part of the project you will also explore how SEM can be used to visualize the behavior of single simulations that leverage ns-3's built-in logging.

* ''Required Experience'': Familiarity with Python and C++ programming.
* ''Bonus Experience'': Familiarity with Jupyter Notebooks.
* ''Difficulty'': Medium.
* ''For more info'': http://github.com/signetlabdei/sem
* ''Patch requirement'': Create a pull request completing any of the following tasks:
** Create a new example SEM script, that runs a program different from wifi-multi-tos and plots some meaningful result
** Add a test that improves the codecov score (you can do this either on the develop branch or on the newrelease branch)

==== Upgrade the AQM Evaluation Suite for ns-3 ====

Mentors: This project is a carryover from 2021; it will be a candidate if mentors are available.

AQM (Active Queue Management) evaluation suite for ns-3 helps to quickly study the performance of AQM algorithms based on the guidelines mentioned in RFC 7928. This suite automates simulation setup, topology creation, traffic generation, program execution, results collection and their graphical representation using ns-3 based on the scenarios mentioned in RFC 7928. It was designed and developed in 2017 and actively maintained till 2019. In the past two years, the traffic control model in ns-3 has grown significantly in terms of supporting state-of-the-art packet scheduling and AQM algorithms. This project has four main goals: (1) upgrade the AQM Evaluation Suite according to the latest ns-3-dev, (2) enable support for latest packet scheduling, AQM algorithms and ECN functionality (3) update the examples in AQM Evaluation Suite to better suit the needs of researchers working in this area, and (4) make AQM Evaluation Suite available on the ns-3 app store.

* ''Required Experience:'' Familiarity with AQM and C++ programming.
* ''Bonus Experience:'' Familiarity with traffic control model in ns-3.
* ''Interests:'' Packet Scheduling algorithms, AQM algorithms and ECN.
* ''Difficulty:'' Medium.
* ''Recommended Reading:''
** AQM Evaluation Suite [[https://dl.acm.org/doi/abs/10.1145/3067665.3067674 Paper]] [[https://aqm-eval-suite.github.io/ Implementation]]
** [https://tools.ietf.org/html/rfc7928 RFC 7928]
** [https://www.nsnam.org/docs/models/html/traffic-control-layer.html Traffic Control Model in ns-3]
* ''Patch requirement:'' Create a pull request to handle the case when an incorrect Scenario name or number is passed via command line. Examples:
** ''./waf --run "aqm-eval-suite-runner --name=<unsupported scenario>"''
** ''./waf --run "aqm-eval-suite-runner --number=<unsupported number>"''

==== TCP maximum segment size (MSS) improvements ====

Mentors: This project is a carryover from 2021; it will be a candidate if mentors are available.

TCP performances are affected by the maximum segment size (MSS) - a wrong choice might either lead to inefficient transmission (higher overhead) or IP fragmentation.

At the moment ns-3 implementation allows to set the MSS via an Attribute (set by default to 536 bytes by TcpSocket Attribute "SegmentSize").
Although it is stated that it "may be adjusted based on MTU discovery", its value is not changed in a simulation.

The goal of the project is to update the MSS handling, allowing to:
1) Set it to a fixed size, or allowing auto-probing of "optimal" MSS,
2) Use and honor the TcpOptionMSS (RFC 793), with a proper example of use, and
3) React to intermediate links with short MTU, and/or to changes in the Path MTU (PMTU).

The last point is to be carefully handled, as in many points in the code there is an implicit assumption that the MSS is constant in a given flow.

Moreover, note that finding the optimal PMTU is not that simple, as IPv6 and IPv4 react differently to packets exceeding the link MTU, and they won't notify if a packet is shorter than the link MTU.
As a consequence, it would be useful to implement the Packetization Layer Path MTU Discovery (RFC 4821) - which might exceed the GSoC timeframe.

Hence, it would be advisable to carefully select the features to be supported and tested in the project, eventually paving the ground for future enhancements.

* ''Required Experience:'' Familiarity with TCP, IPv4 and IPv6, and in particular with fragmentation.
* ''Difficulty:'' Medium / Hard
* ''Recommended reading:''
** [https://en.wikipedia.org/wiki/Path_MTU_Discovery Wikipedia: Path MTU Discovery]
** [https://www.nsnam.org/bugzilla/show_bug.cgi?id=2064 UdpSocket::GetMtu() needed]
** [https://www.nsnam.org/bugzilla/show_bug.cgi?id=1751 TCP should react to MTU changes]
** [https://tools.ietf.org/html/rfc1191 RFC 1191]
** [https://tools.ietf.org/html/rfc4821 RFC 4821]
** [https://tools.ietf.org/html/rfc1122#page-85 RFC 1122]
** [https://tools.ietf.org/html/rfc6691 RFC 6991]
** [https://tools.ietf.org/html/rfc2923 RFC 2923]
** [https://blog.apnic.net/2014/12/15/ip-mtu-and-tcp-mss-missmatch-an-evil-for-network-performance/ APNIC blog - IP MTU and TCP MSS Missmatch – an evil for network performance]
** [https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3650/software/release/16-9/configuration_guide/ip/b_169_ip_3650_cg/configuring_tcp_mss_adjustment.pdf Cisco - Configuring TCP MSS Adjustment]

==== Enable IPv6 support for Ad hoc Routing Protocols in ns-3 ====

Mentors: This project is a carryover from 2021; it will be a candidate if mentors are available.

ns-3 contains models for proactive (DSDV and OLSR) and reactive (AODV and DSR) ad hoc routing protocols. However, these models are IPv4-only and do not provide support of IPv6 addressing. This project aims to enable IPv6 support for ad hoc routing protocols in ns-3, mainly for AODV. There are out-of-tree implementations of OLSR and DSDV that provide support for IPv6 addressing, and can be used as references to get started with this project.

The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.

Note: Enabling IPv6 support for these protocols is not a matter of simply changing out an IPv4-formatted address for an IPv6-formatted address. The IPv6 addressing architecture emphasizes scoping much more than does IPv4 (RFC 4007). Please suggest in your application how IPv6 address configuration (and possibly auto-configuration?) and address scopes (e.g. link-local vs. global) should be used in these protocols. Consulting the RFCs is highly recommended.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3
* ''Interests:'' Ad hoc routing
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]
** [https://www.nsnam.org/workshops/wns3-2016/posters/IPv6-support-for-OLSR.pdf IPv6 Support for OLSR in ns-3]

Possible tasks to fulfill the patch requirement:

* [https://gitlab.com/nsnam/ns-3-dev/-/issues/271 Issue #271] - olsr header and messages are not printing either their size or their content.
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values

==== IPv6 global routing ====

Mentors: This project is a carryover from 2021; it will be a candidate if mentors are available.

Creating a complex topology can be a problem, and sometimes the user do not want to be (also) concerned about setting up dynamic routing protocols (e.g., RIP, RIPng).
For IPv4, ns-3 provides two alternatives: GlobalRouting, and NixRouting, which just "do the trick" - they simply fill the routing tables in intermediate nodes, GlobalRouting using an approach similar to OSPF, NixRouting by leveraging the "abstract" knowledge of the network.
Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.

The problem is that they don't work for IPv6, and that's a huge limitation. The goal of the project is to fix that limitation. Note that the project must cope with different IPv6 address kinds (link-local, global, scoped multicast, etc.). Due to the limitation with GlobalRouting w.r.t. wireless channels, it would be advisable to start working with NixRouting.

The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with NixRouting and GlobalRouting implementations in ns-3
* ''Interests:'' IPv6 routing
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/docs/models/html/nix-vector-routing.html NixRouting model in ns-3]
** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]

Possible tasks to fulfill the patch requirement:
* Add a function to print the path that a packet will use (according to Ipv4NixVectorRouting), i.e., given source and destination IP print the IP addresses of the nodes that Ipv4NixVectorRouting will use.
* Add a function to print the path that a packet will use (according to Ipv4GlobalRouting), i.e., given source and destination IP print the IP addresses of the nodes that Ipv4GlobalRouting will use.

==== Dynamic IPv6 Address Configuration for LTE ====

Mentors: This project is a new project; it will be a candidate if mentors are available.

This project aims to enable the feature of supporting more than one EPCs in LTE module of ns-3. Currently IPv6 support is available in LTE module, but IPv6 address assignment to EPC components like PGW, eNB and UE is static. Manual IPv6 address assignment was there, and so when create another instance of EPC, it configures with the same IPv6 address for the components. Although the interface id will be different for different components, but the initial 64 bit prefix will remain same, hence it is creating conflict in routing for more than one EPCs in a topology. Hence we need to propose a dynamic IPv6 address scheme over there and the implementation will enable two UEs from two EPCs are communicating successfully without any routing conflict.
While you are thinking about any IPv6 layer solution in this case, you will stuck by some issues like, https://www.nsnam.org/bugzilla/show_bug.cgi?id=2835 this i.e. the LTE eNB RRC configuration issue the UL-DL spectrum allocation issue for two EPCs. So, the most important part of this project is to eliminate these issues first i.e. RRC configuration and spectrum allocation must be flexible to be allocated for two different EPCs' eNBs and then the proper addressing scheme.

* ''Required Experience:'' Fundamentals of IPv6 addressing and routing, ICMPv6-based Neighbor Discovery, C++ programming.
* ''Bonus Experience:'' Familiarity with IPv6 support and L3 layer control signaling in ns-3 LTE module
* ''Interests:'' IPv6 address configuration
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/docs/models/html/lte-design.html#epc-data-plane LTE EPC data plane functionalities of LTE module in ns-3]
** [https://www.nsnam.org/docs/models/html/lte-design.html#s1-s5-and-s11 S1 and S5 data flow of LTE module in ns-3]
** [https://datatracker.ietf.org/doc/html/rfc4861 Neighbor Discovery for IP version 6 (IPv6)]

GSOC2021Projects

2021-03-28T12:50:29Z

Mkrana: /* Integration of MIPv6 module into ns-3 */

{{TOC}}

This page contains 2021 Google Summer of Code project ideas for ns-3.

* [http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2015/help_page GSoC Frequently Asked Questions]
* [[GSOC2021StudentGuide |ns-3's 2021 GSoC Student guide]]
* [http://write.flossmanuals.net/gsocstudentguide/about-this-manual/ GSoC student guide (not ns-3 specific)]
* [[GSOC2021StudentApplicationTemplate |2021 GSoC Student application template]]
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]
* [http://write.flossmanuals.net/gsoc-mentoring/ GSoC Mentor guide (not ns-3 specific)]
* [[GSOCSelectionProcess | GSoC Student Selection Process]]
* ''Get in contact with the ns-3 team'': [http://mailman.isi.edu/mailman/listinfo/ns-developers ns-developers mailing list] | ''chat'' https://ns-3.zulipchat.com/

=== About the ns-3 project ===

ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.

Users of ns-3 can construct simulations of computer networks using models of traffic generators, protocols such as TCP/IP, and devices and channels such as WiFi, and analyze or visualize the results. Simulation plays a vital role in the research and education process, because of the ability for simulations to obtain reproducible results (particularly for wireless protocol design), scale to large networks, and study systems that have not yet been implemented. A particular emphasis in ns-3 is the high degree of realism in the models (including frameworks for real application and kernel code) and integration of the tool with virtual machine environments and testbeds; we view that researchers need to move more effortlessly between simulation, testbeds, and live experiments, and ns-3 is designed to facilitate that.

ns-3 has participated in past GSoCs during 2008-10, 2012-15, and 2017-20. We seek students interested in the intersection of wireless and computer networking, performance analysis, and open source software.

=== Org admins ===

Google Summer of Code organizational admins for ns-3 are [mailto:tpecorella@mac.com Tommaso Pecorella], [mailto:tahiliani.nitk@gmail.com Mohit Tahiliani] and [mailto:tomh@tomh.org Tom Henderson]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com Zulip].

=== Mentors ===

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 or Tommaso Pecorella of interest. Mentors familiar with ns-3 development practices will be preferred, to improve the chances of student code merge. In 2021, we are going to be seeking two-person or multiple-person mentoring teams for projects, to help with the mentoring workload and bring more expertise.

The current list of prospective mentors for 2021 is below:

* Tom Henderson
* Tommaso Pecorella
* Mohit P. Tahiliani
* Manoj Kumar Rana
* Sebastien Deronne
* Hany Assasa
* Davide Magrin
* Vivek Jain
* Viyom Mittal
* Mishal Shah
* Apoorva Bhargava

=== Changes from last year ===

Google has changed the program, reducing it to half the paid time from previous summers. Therefore, we will be seeking to define projects with much reduced scope than in years past. In general, we seek projects that aim to improve the existing simulator rather than add new features.

=== Students: how to participate ===

For students interested in applying to ns-3 for GSOC, please go through the following list to get started:
* Read the official [http://en.flossmanuals.net/GSoCStudentGuide/ GSoC student guide].
* Read [[GSOC2021StudentGuide |ns-3's GSoC Student guide]]
* Look through our [[#Project Ideas]] below to see if you find a project that interests you.
* Review the [http://www.nsnam.org/ns-3-32/documentation ns-3 tutorial] thoroughly, if you have not already done so.
* Once it is posted, look through the [[GSOC2021StudentApplicationTemplate |GSoC Student application template]] to start preparing your proposal. We will wait to see whether we are actually part of GSoC before posting this.
* Next, proceed to get in touch with the developers on the mailing list or chat room and refine your proposal.
* In parallel, make sure you prepare a patch as per the patch requirement guidelines. Your application to ns-3 will not be considered if you do not fulfill this requirement.

Below is a list of [[#Project Ideas]] proposed by the ns-3 team for Google Summer of Code 2021. 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.

<blockquote>
Each project idea within a particular priority has been tagged with the following properties:
* ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.
* ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.
* ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful students might apply their experiences coming out of this project.
* ''Difficulty:'' easy, medium or difficult
* ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.

Note that all of the projects require some experience and comfort with C++. Project ideas for which C++ is noted as a required experience will require more and deeper familiarity with the language. A similar notion applies to computer networking, BSD sockets, etc: Familiarity is strongly preferred, but is not required except where explicitly noted due to the topic being more advanced in that regard. A few projects are more Python-centric.
</blockquote>

=== Patch requirement guidelines ===

Each project idea has (or will have) a list of proposed tasks that a student must do to ensure his/her ability to carry out the idea successfully. Performing one task is necessary for a successful application, and performing more than one task is ''not'' necessary.

If a student wants to work on a proposed task he/she should immediately contact the mentor(s) to "claim" that task - in order to avoid (where needed) that multiple students are on the same task. A task might involve fixing a specific open issue, or adding some functionalities to the existing code.

Students that did already contribute to the ns-3 codebase with non-trivial bug fixing or features additions might be exempted from performing a task. If you have doubts about if your contributions made you eligible for the task exemption contact the mentors.

=== Mentors: how to participate ===

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:

* The projects are sized such that there can be a code merge by the end of the coding period. The scope of the project should be such that it is very difficult to not have a code merge by the end of the summer.
* The proposed projects are not too open-ended. That is, if the deliverables or a clear path to the same are not well understood, it is better kept outside GSOC.
* There should be a clear merge path to one of the main project code repositories (ns-3-dev, ns-3-dce, bake) by the end of the summer, either because the patches directly apply to these repositories, or because they apply to an ns-3 module that is in the process of being merged with ns-3-dev.

== Project Ideas ==

'''Note to students:''' These ideas are not listed in any priority order.

==== Linux-like Loss Detection Techniques for ns-3 TCP ====

Mentors: [mailto:jain.vivek.anand@gmail.com Vivek Jain], [mailto:viyommittal@gmail.com Viyom Mittal], [mailto:apoorvabhargava13@gmail.com Apoorva Bhargava]

Forward Acknowledgement (FACK), Duplicate Selective Acknowledgement (DSACK), Tail Loss Probe (TLP) and Recent Acknowledgement (RACK) are the loss detection techniques implemented in the Linux kernel. These techniques have been already implemented for ns-3 TCP but their code is not yet merged into the mainline. This project has four main goals: (1) update the implementation of these techniques according to the latest ns-3-dev, (2) develop a framework to test the functionality of these techniques, (3) develop example program(s) to demonstrate the usage of these techniques in ns-3 and (4) merge these techniques in the mainline of ns-3.

* ''Required Experience:'' Familiarity with TCP and C++ programming.
* ''Bonus Experience:'' Familiarity with TCP implementation in Linux kernel.
* ''Interests:'' TCP packet loss detection techniques.
* ''Difficulty:'' Medium to Hard.
* ''Recommended Reading:''
** Forward Acknowledgement (FACK) [[https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.41.2559&rep=rep1&type=pdf Paper]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]
** Duplicate Selective Acknowledgment (DSACK) [[https://tools.ietf.org/html/rfc2883 RFC 2883]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]
** Tail Loss Probe (TLP) [[https://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01 Internet Draft]] [[https://gitlab.com/ShikhaBakshi/ns-3-dev/-/commits/TLP Implementation]]
** Recent Acknowledgment (RACK) [[https://tools.ietf.org/html/draft-ietf-tcpm-rack-15 Internet Draft]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]

==== Direct Code Execution upgrade ====

Mentor: [mailto:tomh@tomh.org Tom Henderson]

ns-3 has an extension known as Direct Code Execution, which allows users to build C or C++-based applications, and open source (Linux, FreeBSD) kernels, into ns-3. However, support for the latest kernels (e.g. Linux kernel 5 series) and latest glibc library versions has languished. We also could better integrate DCE with the main ns-3 tree. This project seeks a student interested in DCE, improving usability, and making it current with latest kernels and toolchains. The payoff of this type of project is very high since DCE makes available a lot of real-world models for use in ns-3. If you select this project idea, please engage with us on the developers list, and consider to take a look at solving one of the [https://www.nsnam.org/bugzilla/buglist.cgi?bug_status=__open__&content=&no_redirect=1&order=Importance&product=dce&query_format=specific open DCE issues in our tracker], for starters.
* ''Required Experience:'' good hacking skills on Linux, C, C++, Python
* ''Difficulty:'' Hard.
* ''For more information:'' https://www.nsnam.org/about/projects/direct-code-execution/, https://github.com/direct-code-execution/ns-3-dce
* ''Patch requirement:'' Any progress you can make on one of the following topics:
** Get DCE working on Ubuntu 20.04
** Upgrade the current net-next-nuse to a later kernel version than kernel 4.4
** Get DCE to compile with clang++ (https://github.com/direct-code-execution/ns-3-dce/issues/16)

==== LoRaWAN ====

Mentor: [mailto:davide@magr.in Davide Magrin]

LoRaWAN is a communication technology for the Internet of Things, that allows battery-powered devices to wirelessly transmit data over long distances. Thanks to the lorawan module for ns-3, users can simulate networks where thousands of such devices communicate with a central server through multiple gateways. Packets might collide and be lost, devices might need to re-transmit them, and the central server can tell devices to change their transmission parameters according to suitable, exotic algorithms - we model it all.

This module rapidly grew in the last period, with the addition of various features and functionalities that are not completely tested nor documented, yet. In this project, you will mostly work to (1) integrate these features into the mainline code, and (2) improve the LoRaWAN module's testing and documentation.

Additionally, according to time availability and your interest, you can also help showcasing the potentialities of the lorawan module through the SEM library. Indeed, SEM can be used together with the lorawan module to provide users with meaningful examples, with the dual objective of giving a better understanding of what is going on within a single simulation, as well as how a simulation campaign can be easily conducted.

* ''Required Experience'': Familiarity with C++ programming and the LoRaWAN standard.
* ''Bonus Experience'': Familiarity with Python programming.
* ''Interests'': Internet of Things communication protocols.
* ''Difficulty'': Medium to Hard.
* ''For more info'': https://github.com/signetlabdei/lorawan, http://github.com/signetlabdei/sem
* ''Patch requirement'': Create a pull request that fixes any of the following issues in the lorawan repo:
** Test, fix and make sure the us915 branch works as expected, helping merge it into develop https://github.com/signetlabdei/lorawan/issues/32
** Write a documentation entry describing how the Network Server works, or fix any other point in this issue: https://github.com/signetlabdei/lorawan/issues/58

==== SEM - Examples and documentation ====

Mentor: [mailto:davide@magr.in Davide Magrin]

The SEM Python library was designed to help ns-3 users run complex simulation campaigns. Among other things, SEM strives to make it as easy as possible to parse the output of simulations and to obtain plots that show the impact of simulation parameters on the network's performance.

One of the objectives for the next big SEM release is to provide users with more examples that are both easy to modify and that showcase the full potential of the library and of the Python data analysis ecosystem. In this project, your objective will be to show how SEM can be used from within Jupyter Notebooks to gradually explore the behavior of a network. Aside from the creation of new examples, you will also have the opportunity to try your hand at the all-important task of writing documentation. If there's time and you feel like tackling the issue, in a second part of the project you will also explore how SEM can be used to visualize the behavior of single simulations that leverage ns-3's built-in logging.

* ''Required Experience'': Familiarity with Python and C++ programming.
* ''Bonus Experience'': Familiarity with Jupyter Notebooks.
* ''Difficulty'': Medium.
* ''For more info'': http://github.com/signetlabdei/sem
* ''Patch requirement'': Create a pull request completing any of the following tasks:
** Create a new example SEM script, that runs a program different from wifi-multi-tos and plots some meaningful result
** Add a test that improves the codecov score (you can do this either on the develop branch or on the newrelease branch)

==== Upgrade the AQM Evaluation Suite for ns-3 ====

Mentors: [mailto:viyommittal@gmail.com Viyom Mittal], [mailto:jain.vivek.anand@gmail.com Vivek Jain], [mailto:shahmishal1998@gmail.com Mishal Shah]

AQM (Active Queue Management) evaluation suite for ns-3 helps to quickly study the performance of AQM algorithms based on the guidelines mentioned in RFC 7928. This suite automates simulation setup, topology creation, traffic generation, program execution, results collection and their graphical representation using ns-3 based on the scenarios mentioned in RFC 7928. It was designed and developed in 2017 and actively maintained till 2019. In the past two years, the traffic control model in ns-3 has grown significantly in terms of supporting state-of-the-art packet scheduling and AQM algorithms. This project has four main goals: (1) upgrade the AQM Evaluation Suite according to the latest ns-3-dev, (2) enable support for latest packet scheduling, AQM algorithms and ECN functionality (3) update the examples in AQM Evaluation Suite to better suit the needs of researchers working in this area, and (4) make AQM Evaluation Suite available on the ns-3 app store.

* ''Required Experience:'' Familiarity with AQM and C++ programming.
* ''Bonus Experience:'' Familiarity with traffic control model in ns-3.
* ''Interests:'' Packet Scheduling algorithms, AQM algorithms and ECN.
* ''Difficulty:'' Medium.
* ''Recommended Reading:''
** AQM Evaluation Suite [[https://dl.acm.org/doi/abs/10.1145/3067665.3067674 Paper]] [[https://aqm-eval-suite.github.io/ Implementation]]
** [https://tools.ietf.org/html/rfc7928 RFC 7928]
** [https://www.nsnam.org/docs/models/html/traffic-control-layer.html Traffic Control Model in ns-3]

==== Upgrade Python bindings framework ====

Mentors: [mailto:tomh@tomh.org Tom Henderson]

The project has provided Python bindings via a toolchain combining [https://github.com/gjcarneiro/pybindgen pybindgen], [https://github.com/CastXML/CastXML CastXML], and [https://github.com/CastXML/pygccxml pygccxml]. This is a compile-time solution, and some drawbacks have appeared as the C++ language has evolved but the bindings framework has not kept pace (leading to errors in scanning the APIs, or incomplete API coverage). A recent summary can be found [https://mailman.isi.edu/pipermail/ns-developers/2021-February/015396.html here]. This project would aim to prototype and evaluate whether a different framework could be used (such as [https://cppyy.readthedocs.io/en/latest/ cppyy] or [https://pybind11.readthedocs.io/en/stable/ pybind11]). In any case, work can also include fixing one or more bugs/limitations found in our issue tracker with the label 'python bindings'.

* ''Required Experience:'' Familiarity with C++ and Python/C. Solid Python coding skills.
* ''Interests:'' Python bindings
* ''Difficulty:'' Medium to Hard.
* ''Patch requirement:'' Any progress you can make on one of the following topics:
** Successfully scan bindings on macOS (see https://gitlab.com/nsnam/ns-3-dev/-/issues/93)
** [https://github.com/gjcarneiro/pybindgen/issues/10 Add support for C++ scoped enums in pybindgen]
** Any proof-of-concept implementation (even if only partially working) using cppyy or pybind11

==== TCP maximum segment size (MSS) improvements ====

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], others TBD

TCP performances are affected by the maximum segment size (MSS) - a wrong choice might either lead to inefficient transmission (higher overhead) or IP fragmentation.

At the moment ns-3 implementation allows to set the MSS via an Attribute (set by default to 536 bytes by TcpSocket Attribute "SegmentSize").
Although it is stated that it "may be adjusted based on MTU discovery", its value is not changed in a simulation.

The goal of the project is to update the MSS handling, allowing to:
1) Set it to a fixed size, or allowing auto-probing of "optimal" MSS,
2) Use and honor the TcpOptionMSS (RFC 793), with a proper example of use, and
3) React to intermediate links with short MTU, and/or to changes in the Path MTU (PMTU).

The last point is to be carefully handled, as in many points in the code there is an implicit assumption that the MSS is constant in a given flow.

Moreover, note that finding the optimal PMTU is not that simple, as IPv6 and IPv4 react differently to packets exceeding the link MTU, and they won't notify if a packet is shorter than the link MTU.
As a consequence, it would be useful to implement the Packetization Layer Path MTU Discovery (RFC 4821) - which might exceed the GSoC timeframe.

Hence, it would be advisable to carefully select the features to be supported and tested in the project, eventually paving the ground for future enhancements.

* ''Required Experience:'' Familiarity with TCP, IPv4 and IPv6, and in particular with fragmentation.
* ''Difficulty:'' Medium / Hard
* ''Recommended reading:''
** [https://en.wikipedia.org/wiki/Path_MTU_Discovery Wikipedia: Path MTU Discovery]
** [https://www.nsnam.org/bugzilla/show_bug.cgi?id=2064 UdpSocket::GetMtu() needed]
** [https://www.nsnam.org/bugzilla/show_bug.cgi?id=1751 TCP should react to MTU changes]
** [https://tools.ietf.org/html/rfc1191 RFC 1191]
** [https://tools.ietf.org/html/rfc4821 RFC 4821]
** [https://tools.ietf.org/html/rfc1122#page-85 RFC 1122]
** [https://tools.ietf.org/html/rfc6691 RFC 6991]
** [https://tools.ietf.org/html/rfc2923 RFC 2923]
** [https://blog.apnic.net/2014/12/15/ip-mtu-and-tcp-mss-missmatch-an-evil-for-network-performance/ APNIC blog - IP MTU and TCP MSS Missmatch – an evil for network performance]
** [https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3650/software/release/16-9/configuration_guide/ip/b_169_ip_3650_cg/configuring_tcp_mss_adjustment.pdf Cisco - Configuring TCP MSS Adjustment]

==== Enable IPv6 support for Ad hoc Routing Protocols in ns-3 ====

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], and others TBD

ns-3 contains models for proactive (DSDV and OLSR) and reactive (AODV and DSR) ad hoc routing protocols. However, these models are IPv4-only and do not provide support of IPv6 addressing. This project aims to enable IPv6 support for ad hoc routing protocols in ns-3, mainly for AODV. There are out-of-tree implementations of OLSR and DSDV that provide support for IPv6 addressing, and can be used as references to get started with this project.

The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.

Note: Enabling IPv6 support for these protocols is not a matter of simply changing out an IPv4-formatted address for an IPv6-formatted address. The IPv6 addressing architecture emphasizes scoping much more than does IPv4 (RFC 4007). Please suggest in your application how IPv6 address configuration (and possibly auto-configuration?) and address scopes (e.g. link-local vs. global) should be used in these protocols. Consulting the RFCs is highly recommended.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3
* ''Interests:'' Ad hoc routing
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]
** [https://www.nsnam.org/workshops/wns3-2016/posters/IPv6-support-for-OLSR.pdf IPv6 Support for OLSR in ns-3]

Possible tasks to fulfill the patch requirement:

* [https://gitlab.com/nsnam/ns-3-dev/-/issues/271 Issue #271] - olsr header and messages are not printing either their size or their content.
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values

==== IPv6 global routing ====

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], others TBD

Creating a complex topology can be a problem, and sometimes the user do not want to be (also) concerned about setting up dynamic routing protocols (e.g., RIP, RIPng).
For IPv4, ns-3 provides two alternatives: GlobalRouting, and NixRouting, which just "do the trick" - they simply fill the routing tables in intermediate nodes, GlobalRouting using an approach similar to OSPF, NixRouting by leveraging the "abstract" knowledge of the network.
Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.

The problem is that they don't work for IPv6, and that's a huge limitation. The goal of the project is to fix that limitation. Note that the project must cope with different IPv6 address kinds (link-local, global, scoped multicast, etc.). Due to the limitation with GlobalRouting w.r.t. wireless channels, it would be advisable to start working with NixRouting.

The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with NixRouting and GlobalRouting implementations in ns-3
* ''Interests:'' IPv6 routing
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/docs/models/html/nix-vector-routing.html NixRouting model in ns-3]
** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]

Possible tasks to fulfill the patch requirement:
* Add a function to print the path that a packet will use (according to Ipv4NixVectorRouting), i.e., given source and destination IP print the IP addresses of the nodes that Ipv4NixVectorRouting will use.
* Add a function to print the path that a packet will use (according to Ipv4GlobalRouting), i.e., given source and destination IP print the IP addresses of the nodes that Ipv4GlobalRouting will use.

==== Integration of MIPv6 module into ns-3 ====

Mentor: [mailto:manoj24.rana@gmail.com Manoj Kumar Rana]

The MIPv6 module had already been implemented in ns-3 (The links of their implementations are given below). But, these modules are still lacking in ns-3 main tree. One of the medium access control (MAC) layer issue was NetDevice up/down consistency which has been resolved through the GSoC 2020 project titled, “NetDevice up/down consistency and event chain”. The MIPv6 integration still requires understanding the behaviour of IPv6 and ICMPv6 protocols running in LTE module (mainly between PGW/SGW and eNB). Although IPv6 packets are now transferred over LTE network, the sole purpose of MIPv6 handoff i.e. switching mobile node between LTE and WiFi can only be accomplished by modifying the existing MIPv6 module and extending the existing LTE module.

* ''Required Experience:'' C++, LTE IPv6 support.
* ''Bonus Experience:'' Familiarity with MIPv6/PMIPv6 module implementations in ns-3
* ''Interests:'' IPv6
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/wiki/GSOC2017MobileIp MIPv6 model in ns-3]

Patch Requirement:

* Dynamic IPv6 address configuration of UEs in LTE networks (To be updated): Currently, UEs are assigned static IPv6 address and the assignment is hard-coded within the helper class. But, MIPv6 is a dynamic procedure and so, the standard requires the address to be dynamically configured. It requires the access point i.e. the eNB/epc advertises a 64 bit prefix within the mobile network and the UE will configure an 128 bit IPv6 address from it.

[[Category:GSoC]]

GSOC2021Projects

2021-03-28T12:33:26Z

Mkrana: /* Integration of MIPv6 module into ns-3 */

GSOC2021Projects

2021-03-03T18:50:29Z

Mkrana: /* Integration of MIPv6 module into ns-3 */

{{TOC}}

This page contains 2021 Google Summer of Code project ideas for ns-3. Students interested in participating in ns-3's GSoC program are free to get started on an idea or two, with the understanding that ns-3 has not yet been selected for GSoC and may not ultimately be selected.

* [http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2015/help_page GSoC Frequently Asked Questions]
* [[GSOC2021StudentGuide |ns-3's 2021 GSoC Student guide]]
* [http://en.flossmanuals.net/GSoCStudentGuide/ GSoC student guide (not ns-3 specific)]
* [[GSOC2020StudentApplicationTemplate |2020 GSoC Student application template]]
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]
* [http://en.flossmanuals.net/gsoc-mentoring/ GSoC Mentor guide (not ns-3 specific)]
* [[GSOCSelectionProcess | GSoC Student Selection Process]]
* ''Get in contact with the ns-3 team'': [http://mailman.isi.edu/mailman/listinfo/ns-developers ns-developers mailing list] | ''chat'' https://ns-3.zulipchat.com/

=== About the ns-3 project ===

ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.

Users of ns-3 can construct simulations of computer networks using models of traffic generators, protocols such as TCP/IP, and devices and channels such as WiFi, and analyze or visualize the results. Simulation plays a vital role in the research and education process, because of the ability for simulations to obtain reproducible results (particularly for wireless protocol design), scale to large networks, and study systems that have not yet been implemented. A particular emphasis in ns-3 is the high degree of realism in the models (including frameworks for real application and kernel code) and integration of the tool with virtual machine environments and testbeds; we view that researchers need to move more effortlessly between simulation, testbeds, and live experiments, and ns-3 is designed to facilitate that.

ns-3 has participated in past GSoCs during 2008-10, 2012-15, and 2017-20. We seek students interested in the intersection of wireless and computer networking, performance analysis, and open source software.

=== Org admins ===

Google Summer of Code organizational admins for ns-3 are [mailto:tpecorella@mac.com Tommaso Pecorella], [mailto:tahiliani.nitk@gmail.com Mohit Tahiliani] and [mailto:tomh@tomh.org Tom Henderson]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com Zulip].

=== Mentors ===

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 or Tommaso Pecorella of interest. Mentors familiar with ns-3 development practices will be preferred, to improve the chances of student code merge. In 2021, we are going to be seeking two-person or multiple-person mentoring teams for projects, to help with the mentoring workload and bring more expertise.

The current list of prospective mentors for 2021 is below:

* Tom Henderson
* Tommaso Pecorella
* Mohit P. Tahiliani
* Manoj Kumar Rana
* Sebastien Deronne
* Hany Assasa
* Davide Magrin
* Vivek Jain
* Viyom Mittal
* Mishal Shah

=== Changes from last year ===

Google has changed the program, reducing it to half the paid time from previous summers. Therefore, we will be seeking to define projects with much reduced scope than in years past. In general, we seek projects that aim to improve the existing simulator rather than add new features.

=== Students: how to participate ===

For students interested in applying to ns-3 for GSOC, please go through the following list to get started:
* Read the official [http://en.flossmanuals.net/GSoCStudentGuide/ GSoC student guide].
* Read [[GSOC2021StudentGuide |ns-3's GSoC Student guide]]
* Look through our [[#Project Ideas]] below to see if you find a project that interests you.
* Review the [http://www.nsnam.org/ns-3-32/documentation ns-3 tutorial] thoroughly, if you have not already done so.
* Once it is posted, look through the [[GSOC2021StudentApplicationTemplate |GSoC Student application template]] to start preparing your proposal. We will wait to see whether we are actually part of GSoC before posting this.
* Next, proceed to get in touch with the developers on the mailing list or chat room and refine your proposal.
* In parallel, make sure you prepare a patch as per the patch requirement guidelines (to be posted at a later date). Your application to ns-3 will not be considered if you do not fulfill this requirement.

Below is a list of [[#Project Ideas]] proposed by the ns-3 team for Google Summer of Code 2021. 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.

<blockquote>
Each project idea within a particular priority has been tagged with the following properties:
* ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.
* ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.
* ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful students might apply their experiences coming out of this project.
* ''Difficulty:'' easy, medium or difficult
* ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.

Note that all of the projects require some experience and comfort with C++. Project ideas for which C++ is noted as a required experience will require more and deeper familiarity with the language. A similar notion applies to computer networking, BSD sockets, etc: Familiarity is strongly preferred, but is not required except where explicitly noted due to the topic being more advanced in that regard. A few projects are more Python-centric.
</blockquote>

=== Mentors: how to participate ===

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:

* The projects are sized such that there can be a code merge by the end of the coding period. The scope of the project should be such that it is very difficult to not have a code merge by the end of the summer.
* The proposed projects are not too open-ended. That is, if the deliverables or a clear path to the same are not well understood, it is better kept outside GSOC.
* There should be a clear merge path to one of the main project code repositories (ns-3-dev, ns-3-dce, bake) by the end of the summer, either because the patches directly apply to these repositories, or because they apply to an ns-3 module that is in the process of being merged with ns-3-dev.

== Project Ideas ==

'''Note to students:''' These ideas are not listed in any priority order.

==== Linux-like Loss Detection Techniques for ns-3 TCP ====

Mentors: [mailto:jain.vivek.anand@gmail.com Vivek Jain], [mailto:viyommittal@gmail.com Viyom Mittal], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

Forward Acknowledgement (FACK), Duplicate Selective Acknowledgement (DSACK), Tail Loss Probe (TLP) and Recent Acknowledgement (RACK) are the loss detection techniques implemented in the Linux kernel. These techniques have been already implemented for ns-3 TCP but their code is not yet merged into the mainline. This project has four main goals: (1) update the implementation of these techniques according to the latest ns-3-dev, (2) develop a framework to test the functionality of these techniques, (3) develop example program(s) to demonstrate the usage of these techniques in ns-3 and (4) merge these techniques in the mainline of ns-3.

* ''Required Experience:'' Familiarity with TCP and C++ programming.
* ''Bonus Experience:'' Familiarity with TCP implementation in Linux kernel.
* ''Interests:'' TCP packet loss detection techniques.
* ''Difficulty:'' Medium to Hard.
* ''Recommended Reading:''
** Forward Acknowledgement (FACK) [[https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.41.2559&rep=rep1&type=pdf Paper]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]
** Duplicate Selective Acknowledgment (DSACK) [[https://tools.ietf.org/html/rfc2883 RFC 2883]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]
** Tail Loss Probe (TLP) [[https://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01 Internet Draft]] [[https://gitlab.com/ShikhaBakshi/ns-3-dev/-/commits/TLP Implementation]]
** Recent Acknowledgment (RACK) [[https://tools.ietf.org/html/draft-ietf-tcpm-rack-15 Internet Draft]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]

==== Direct Code Execution upgrade ====

Mentor: [mailto:tomh@tomh.org Tom Henderson]

ns-3 has an extension known as Direct Code Execution, which allows users to build C or C++-based applications, and open source (Linux, FreeBSD) kernels, into ns-3. However, support for the latest kernels (e.g. Linux kernel 5 series) and latest glibc library versions has languished. We also could better integrate DCE with the main ns-3 tree. This project seeks a student interested in DCE, improving usability, and making it current with latest kernels and toolchains. The payoff of this type of project is very high since DCE makes available a lot of real-world models for use in ns-3. If you select this project idea, please engage with us on the developers list, and consider to take a look at solving one of the [https://www.nsnam.org/bugzilla/buglist.cgi?bug_status=__open__&content=&no_redirect=1&order=Importance&product=dce&query_format=specific open DCE issues in our tracker], for starters.
* ''Required Experience:'' good hacking skills on Linux, C, C++, Python
* ''Difficulty:'' Hard.
* ''For more information:'' https://www.nsnam.org/about/projects/direct-code-execution/, https://github.com/direct-code-execution/ns-3-dce

==== LoRaWAN ====

Mentor: [mailto:davide@magr.in Davide Magrin]

LoRaWAN is a communication technology for the Internet of Things, that allows battery-powered devices to wirelessly transmit data over long distances. Thanks to the lorawan module for ns-3, users can simulate networks where thousands of such devices communicate with a central server through multiple gateways. Packets might collide and be lost, devices might need to re-transmit them, and the central server can tell devices to change their transmission parameters according to suitable, exotic algorithms - we model it all.

This module rapidly grew in the last period, with the addition of various features and functionalities that are not completely tested nor documented, yet. In this project, you will mostly work to (1) integrate these features into the mainline code, and (2) improve the LoRaWAN module's testing and documentation.

Additionally, according to time availability and your interest, you can also help showcasing the potentialities of the lorawan module through the SEM library. Indeed, SEM can be used together with the lorawan module to provide users with meaningful examples, with the dual objective of giving a better understanding of what is going on within a single simulation, as well as how a simulation campaign can be easily conducted.

* ''Required Experience'': Familiarity with C++ programming.
* ''Bonus Experience'': Familiarity with Python programming.
* ''Interests'': Internet of Things communication protocols.
* ''Difficulty'': Medium to Hard.
* ''For more info'': https://github.com/signetlabdei/lorawan, http://github.com/signetlabdei/sem

==== SEM - Examples and documentation ====

Mentor: [mailto:davide@magr.in Davide Magrin]

The SEM Python library was designed to help ns-3 users run complex simulation campaigns. Among other things, SEM strives to make it as easy as possible to parse the output of simulations and to obtain plots that show the impact of simulation parameters on the network's performance.

One of the objectives for the next big SEM release is to provide users with more examples that are both easy to modify and that showcase the full potential of the library and of the Python data analysis ecosystem. In this project, your objective will be to show how SEM can be used from within Jupyter Notebooks to gradually explore the behavior of a network. Aside from the creation of new examples, you will also have the opportunity to try your hand at the all-important task of writing documentation. If there's time and you feel like tackling the issue, in a second part of the project you will also explore how SEM can be used to visualize the behavior of single simulations that leverage ns-3's built-in logging.

* ''Required Experience'': Familiarity with Python and C++ programming.
* ''Bonus Experience'': Familiarity with Jupyter Notebooks.
* ''Difficulty'': Medium.
* ''For more info'': http://github.com/signetlabdei/sem

==== Upgrade the AQM Evaluation Suite for ns-3 ====

Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], [mailto:jain.vivek.anand@gmail.com Vivek Jain], [mailto:shahmishal1998@gmail.com Mishal Shah]

AQM (Active Queue Management) evaluation suite for ns-3 helps to quickly study the performance of AQM algorithms based on the guidelines mentioned in RFC 7928. This suite automates simulation setup, topology creation, traffic generation, program execution, results collection and their graphical representation using ns-3 based on the scenarios mentioned in RFC 7928. It was designed and developed in 2017 and actively maintained till 2019. In the past two years, the traffic control model in ns-3 has grown significantly in terms of supporting state-of-the-art packet scheduling and AQM algorithms. This project has four main goals: (1) upgrade the AQM Evaluation Suite according to the latest ns-3-dev, (2) enable support for latest packet scheduling, AQM algorithms and ECN functionality (3) update the examples in AQM Evaluation Suite to better suit the needs of researchers working in this area, and (4) make AQM Evaluation Suite available on the ns-3 app store.

* ''Required Experience:'' Familiarity with AQM and C++ programming.
* ''Bonus Experience:'' Familiarity with traffic control model in ns-3.
* ''Interests:'' Packet Scheduling algorithms, AQM algorithms and ECN.
* ''Difficulty:'' Medium.
* ''Recommended Reading:''
** AQM Evaluation Suite [[https://dl.acm.org/doi/abs/10.1145/3067665.3067674 Paper]] [[https://aqm-eval-suite.github.io/ Implementation]]
** [https://tools.ietf.org/html/rfc7928 RFC 7928]
** [https://www.nsnam.org/docs/models/html/traffic-control-layer.html Traffic Control Model in ns-3]

==== Upgrade Python bindings framework ====

Mentors: [mailto:tomh@tomh.org Tom Henderson], others TBD

The project has provided Python bindings via a toolchain combining [https://github.com/gjcarneiro/pybindgen pybindgen], [https://github.com/CastXML/CastXML CastXML], and [https://github.com/CastXML/pygccxml pygccxml]. This is a compile-time solution, and some drawbacks have appeared as the C++ language has evolved but the bindings framework has not kept pace (leading to errors in scanning the APIs, or incomplete API coverage). A recent summary can be found [https://mailman.isi.edu/pipermail/ns-developers/2021-February/015396.html here]. This project would aim to prototype and evaluate whether a different framework could be used (such as [https://cppyy.readthedocs.io/en/latest/ cppyy] or [https://pybind11.readthedocs.io/en/stable/ pybind11]). In any case, work can also include fixing one or more bugs/limitations found in our issue tracker with the label 'python bindings'.

* ''Required Experience:'' Familiarity with C++ and Python/C. Solid Python coding skills.
* ''Interests:'' Python bindings
* ''Difficulty:'' Medium to Hard.

==== TCP maximum segment size (MSS) improvements ====

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], others TBD

TCP performances are affected by the maximum segment size (MSS) - a wrong choice might either lead to inefficient transmission (higher overhead) or IP fragmentation.

At the moment ns-3 implementation allows to set the MSS via an Attribute (set by default to 536 bytes by TcpSocket Attribute "SegmentSize").
Although it is stated that it "may be adjusted based on MTU discovery", its value is not changed in a simulation.

The goal of the project is to update the MSS handling, allowing to:
1) Set it to a fixed size, or allowing auto-probing of "optimal" MSS,
2) Use and honor the TcpOptionMSS (RFC 793), with a proper example of use, and
3) React to intermediate links with short MTU, and/or to changes in the Path MTU (PMTU).

The last point is to be carefully handled, as in many points in the code there is an implicit assumption that the MSS is constant in a given flow.

Moreover, note that finding the optimal PMTU is not that simple, as IPv6 and IPv4 react differently to packets exceeding the link MTU, and they won't notify if a packet is shorter than the link MTU.
As a consequence, it would be useful to implement the Packetization Layer Path MTU Discovery (RFC 4821) - which might exceed the GSoC timeframe.

Hence, it would be advisable to carefully select the features to be supported and tested in the project, eventually paving the ground for future enhancements.

* ''Required Experience:'' Familiarity with TCP, IPv4 and IPv6, and in particular with fragmentation.
* ''Difficulty:'' Medium / Hard
* ''Recommended reading:''
** [https://en.wikipedia.org/wiki/Path_MTU_Discovery Wikipedia: Path MTU Discovery]
** [https://www.nsnam.org/bugzilla/show_bug.cgi?id=2064 UdpSocket::GetMtu() needed]
** [https://www.nsnam.org/bugzilla/show_bug.cgi?id=1751 TCP should react to MTU changes]
** [https://tools.ietf.org/html/rfc1191 RFC 1191]
** [https://tools.ietf.org/html/rfc4821 RFC 4821]
** [https://tools.ietf.org/html/rfc1122#page-85 RFC 1122]
** [https://tools.ietf.org/html/rfc6691 RFC 6991]
** [https://tools.ietf.org/html/rfc2923 RFC 2923]
** [https://blog.apnic.net/2014/12/15/ip-mtu-and-tcp-mss-missmatch-an-evil-for-network-performance/ APNIC blog - IP MTU and TCP MSS Missmatch – an evil for network performance]
** [https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3650/software/release/16-9/configuration_guide/ip/b_169_ip_3650_cg/configuring_tcp_mss_adjustment.pdf Cisco - Configuring TCP MSS Adjustment]

==== Enable IPv6 support for Ad hoc Routing Protocols in ns-3 ====

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

ns-3 contains models for proactive (DSDV and OLSR) and reactive (AODV and DSR) ad hoc routing protocols. However, these models are IPv4-only and do not provide support of IPv6 addressing. This project aims to enable IPv6 support for ad hoc routing protocols in ns-3, mainly for AODV. There are out-of-tree implementations of OLSR and DSDV that provide support for IPv6 addressing, and can be used as references to get started with this project.

The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.

Note: Enabling IPv6 support for these protocols is not a matter of simply changing out an IPv4-formatted address for an IPv6-formatted address. The IPv6 addressing architecture emphasizes scoping much more than does IPv4 (RFC 4007). Please suggest in your application how IPv6 address configuration (and possibly auto-configuration?) and address scopes (e.g. link-local vs. global) should be used in these protocols. Consulting the RFCs is highly recommended.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3
* ''Interests:'' Ad hoc routing
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]
** [https://www.nsnam.org/workshops/wns3-2016/posters/IPv6-support-for-OLSR.pdf IPv6 Support for OLSR in ns-3]

==== IPv6 global routing ====

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], others TBD

Creating a complex topology can be a problem, and sometimes the user do not want to be (also) concerned about setting up dynamic routing protocols (e.g., RIP, RIPng).
For IPv4, ns-3 provides two alternatives: GlobalRouting, and NixRouting, which just "do the trick" - they simply fill the routing tables in intermediate nodes, GlobalRouting using an approach similar to OSPF, NixRouting by leveraging the "abstract" knowledge of the network.
Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.

The problem is that they don't work for IPv6, and that's a huge limitation. The goal of the project is to fix that limitation. Note that the project must cope with different IPv6 address kinds (link-local, global, scoped multicast, etc.). Due to the limitation with GlobalRouting w.r.t. wireless channels, it would be advisable to start working with NixRouting.

The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with NixRouting and GlobalRouting implementations in ns-3
* ''Interests:'' IPv6 routing
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/docs/models/html/nix-vector-routing.html NixRouting model in ns-3]
** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]

==== Integration of MIPv6 module into ns-3 ====

Mentor: [mailto:manoj24.rana@gmail.com Manoj Kumar Rana]

The MIPv6 module had already been implemented in ns-3 (The links of their implementations are given below). But, these modules are still lacking in ns-3 main tree. One of the medium access control (MAC) layer issue was NetDevice up/down consistency which has been resolved through the GSoC 2020 project titled, “NetDevice up/down consistency and event chain”. The MIPv6 integration still requires understanding the behaviour of IPv6 and ICMPv6 protocols running in LTE module (mainly between PGW/SGW and eNB). Although IPv6 packets are now transferred over LTE network, the sole purpose of MIPv6 handoff i.e. switching mobile node between LTE and WiFi can only be accomplished by modifying the existing MIPv6 module and extending the existing LTE module.

* ''Required Experience:'' C++, LTE IPv6 support.
* ''Bonus Experience:'' Familiarity with MIPv6/PMIPv6 module implementations in ns-3
* ''Interests:'' IPv6
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/wiki/GSOC2017MobileIp MIPv6 model in ns-3]

[[Category:GSoC]]

GSOC2021Projects

2021-03-03T18:44:53Z

Mkrana: /* Integration of MIPv6 module into ns-3 with LTE-WiFi Handoff support */

{{TOC}}

This page contains 2021 Google Summer of Code project ideas for ns-3. Students interested in participating in ns-3's GSoC program are free to get started on an idea or two, with the understanding that ns-3 has not yet been selected for GSoC and may not ultimately be selected.

* [http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2015/help_page GSoC Frequently Asked Questions]
* [[GSOC2021StudentGuide |ns-3's 2021 GSoC Student guide]]
* [http://en.flossmanuals.net/GSoCStudentGuide/ GSoC student guide (not ns-3 specific)]
* [[GSOC2020StudentApplicationTemplate |2020 GSoC Student application template]]
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]
* [http://en.flossmanuals.net/gsoc-mentoring/ GSoC Mentor guide (not ns-3 specific)]
* [[GSOCSelectionProcess | GSoC Student Selection Process]]
* ''Get in contact with the ns-3 team'': [http://mailman.isi.edu/mailman/listinfo/ns-developers ns-developers mailing list] | ''chat'' https://ns-3.zulipchat.com/

=== About the ns-3 project ===

ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.

Users of ns-3 can construct simulations of computer networks using models of traffic generators, protocols such as TCP/IP, and devices and channels such as WiFi, and analyze or visualize the results. Simulation plays a vital role in the research and education process, because of the ability for simulations to obtain reproducible results (particularly for wireless protocol design), scale to large networks, and study systems that have not yet been implemented. A particular emphasis in ns-3 is the high degree of realism in the models (including frameworks for real application and kernel code) and integration of the tool with virtual machine environments and testbeds; we view that researchers need to move more effortlessly between simulation, testbeds, and live experiments, and ns-3 is designed to facilitate that.

ns-3 has participated in past GSoCs during 2008-10, 2012-15, and 2017-20. We seek students interested in the intersection of wireless and computer networking, performance analysis, and open source software.

=== Org admins ===

Google Summer of Code organizational admins for ns-3 are [mailto:tpecorella@mac.com Tommaso Pecorella], [mailto:tahiliani.nitk@gmail.com Mohit Tahiliani] and [mailto:tomh@tomh.org Tom Henderson]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com Zulip].

=== Mentors ===

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 or Tommaso Pecorella of interest. Mentors familiar with ns-3 development practices will be preferred, to improve the chances of student code merge. In 2021, we are going to be seeking two-person or multiple-person mentoring teams for projects, to help with the mentoring workload and bring more expertise.

The current list of prospective mentors for 2021 is below:

* Tom Henderson
* Tommaso Pecorella
* Mohit P. Tahiliani
* Manoj Kumar Rana
* Sebastien Deronne
* Hany Assasa
* Davide Magrin
* Vivek Jain
* Viyom Mittal
* Mishal Shah

=== Changes from last year ===

Google has changed the program, reducing it to half the paid time from previous summers. Therefore, we will be seeking to define projects with much reduced scope than in years past. In general, we seek projects that aim to improve the existing simulator rather than add new features.

=== Students: how to participate ===

For students interested in applying to ns-3 for GSOC, please go through the following list to get started:
* Read the official [http://en.flossmanuals.net/GSoCStudentGuide/ GSoC student guide].
* Read [[GSOC2021StudentGuide |ns-3's GSoC Student guide]]
* Look through our [[#Project Ideas]] below to see if you find a project that interests you.
* Review the [http://www.nsnam.org/ns-3-32/documentation ns-3 tutorial] thoroughly, if you have not already done so.
* Once it is posted, look through the [[GSOC2021StudentApplicationTemplate |GSoC Student application template]] to start preparing your proposal. We will wait to see whether we are actually part of GSoC before posting this.
* Next, proceed to get in touch with the developers on the mailing list or chat room and refine your proposal.
* In parallel, make sure you prepare a patch as per the patch requirement guidelines (to be posted at a later date). Your application to ns-3 will not be considered if you do not fulfill this requirement.

Below is a list of [[#Project Ideas]] proposed by the ns-3 team for Google Summer of Code 2021. 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.

<blockquote>
Each project idea within a particular priority has been tagged with the following properties:
* ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.
* ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.
* ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful students might apply their experiences coming out of this project.
* ''Difficulty:'' easy, medium or difficult
* ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.

Note that all of the projects require some experience and comfort with C++. Project ideas for which C++ is noted as a required experience will require more and deeper familiarity with the language. A similar notion applies to computer networking, BSD sockets, etc: Familiarity is strongly preferred, but is not required except where explicitly noted due to the topic being more advanced in that regard. A few projects are more Python-centric.
</blockquote>

=== Mentors: how to participate ===

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:

* The projects are sized such that there can be a code merge by the end of the coding period. The scope of the project should be such that it is very difficult to not have a code merge by the end of the summer.
* The proposed projects are not too open-ended. That is, if the deliverables or a clear path to the same are not well understood, it is better kept outside GSOC.
* There should be a clear merge path to one of the main project code repositories (ns-3-dev, ns-3-dce, bake) by the end of the summer, either because the patches directly apply to these repositories, or because they apply to an ns-3 module that is in the process of being merged with ns-3-dev.

== Project Ideas ==

'''Note to students:''' These ideas are not listed in any priority order.

==== Linux-like Loss Detection Techniques for ns-3 TCP ====

Mentors: [mailto:jain.vivek.anand@gmail.com Vivek Jain], [mailto:viyommittal@gmail.com Viyom Mittal], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

Forward Acknowledgement (FACK), Duplicate Selective Acknowledgement (DSACK), Tail Loss Probe (TLP) and Recent Acknowledgement (RACK) are the loss detection techniques implemented in the Linux kernel. These techniques have been already implemented for ns-3 TCP but their code is not yet merged into the mainline. This project has four main goals: (1) update the implementation of these techniques according to the latest ns-3-dev, (2) develop a framework to test the functionality of these techniques, (3) develop example program(s) to demonstrate the usage of these techniques in ns-3 and (4) merge these techniques in the mainline of ns-3.

* ''Required Experience:'' Familiarity with TCP and C++ programming.
* ''Bonus Experience:'' Familiarity with TCP implementation in Linux kernel.
* ''Interests:'' TCP packet loss detection techniques.
* ''Difficulty:'' Medium to Hard.
* ''Recommended Reading:''
** Forward Acknowledgement (FACK) [[https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.41.2559&rep=rep1&type=pdf Paper]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]
** Duplicate Selective Acknowledgment (DSACK) [[https://tools.ietf.org/html/rfc2883 RFC 2883]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]
** Tail Loss Probe (TLP) [[https://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01 Internet Draft]] [[https://gitlab.com/ShikhaBakshi/ns-3-dev/-/commits/TLP Implementation]]
** Recent Acknowledgment (RACK) [[https://tools.ietf.org/html/draft-ietf-tcpm-rack-15 Internet Draft]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]

==== Direct Code Execution upgrade ====

Mentor: [mailto:tomh@tomh.org Tom Henderson]

ns-3 has an extension known as Direct Code Execution, which allows users to build C or C++-based applications, and open source (Linux, FreeBSD) kernels, into ns-3. However, support for the latest kernels (e.g. Linux kernel 5 series) and latest glibc library versions has languished. We also could better integrate DCE with the main ns-3 tree. This project seeks a student interested in DCE, improving usability, and making it current with latest kernels and toolchains. The payoff of this type of project is very high since DCE makes available a lot of real-world models for use in ns-3. If you select this project idea, please engage with us on the developers list, and consider to take a look at solving one of the [https://www.nsnam.org/bugzilla/buglist.cgi?bug_status=__open__&content=&no_redirect=1&order=Importance&product=dce&query_format=specific open DCE issues in our tracker], for starters.
* ''Required Experience:'' good hacking skills on Linux, C, C++, Python
* ''Difficulty:'' Hard.
* ''For more information:'' https://www.nsnam.org/about/projects/direct-code-execution/, https://github.com/direct-code-execution/ns-3-dce

==== LoRaWAN ====

Mentor: [mailto:davide@magr.in Davide Magrin]

LoRaWAN is a communication technology for the Internet of Things, that allows battery-powered devices to wirelessly transmit data over long distances. Thanks to the lorawan module for ns-3, users can simulate networks where thousands of such devices communicate with a central server through multiple gateways. Packets might collide and be lost, devices might need to re-transmit them, and the central server can tell devices to change their transmission parameters according to suitable, exotic algorithms - we model it all.

This module rapidly grew in the last period, with the addition of various features and functionalities that are not completely tested nor documented, yet. In this project, you will mostly work to (1) integrate these features into the mainline code, and (2) improve the LoRaWAN module's testing and documentation.

Additionally, according to time availability and your interest, you can also help showcasing the potentialities of the lorawan module through the SEM library. Indeed, SEM can be used together with the lorawan module to provide users with meaningful examples, with the dual objective of giving a better understanding of what is going on within a single simulation, as well as how a simulation campaign can be easily conducted.

* ''Required Experience'': Familiarity with C++ programming.
* ''Bonus Experience'': Familiarity with Python programming.
* ''Interests'': Internet of Things communication protocols.
* ''Difficulty'': Medium to Hard.
* ''For more info'': https://github.com/signetlabdei/lorawan, http://github.com/signetlabdei/sem

==== SEM - Examples and documentation ====

Mentor: [mailto:davide@magr.in Davide Magrin]

The SEM Python library was designed to help ns-3 users run complex simulation campaigns. Among other things, SEM strives to make it as easy as possible to parse the output of simulations and to obtain plots that show the impact of simulation parameters on the network's performance.

One of the objectives for the next big SEM release is to provide users with more examples that are both easy to modify and that showcase the full potential of the library and of the Python data analysis ecosystem. In this project, your objective will be to show how SEM can be used from within Jupyter Notebooks to gradually explore the behavior of a network. Aside from the creation of new examples, you will also have the opportunity to try your hand at the all-important task of writing documentation. If there's time and you feel like tackling the issue, in a second part of the project you will also explore how SEM can be used to visualize the behavior of single simulations that leverage ns-3's built-in logging.

* ''Required Experience'': Familiarity with Python and C++ programming.
* ''Bonus Experience'': Familiarity with Jupyter Notebooks.
* ''Difficulty'': Medium.
* ''For more info'': http://github.com/signetlabdei/sem

==== Upgrade the AQM Evaluation Suite for ns-3 ====

Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], [mailto:jain.vivek.anand@gmail.com Vivek Jain], [mailto:shahmishal1998@gmail.com Mishal Shah]

AQM (Active Queue Management) evaluation suite for ns-3 helps to quickly study the performance of AQM algorithms based on the guidelines mentioned in RFC 7928. This suite automates simulation setup, topology creation, traffic generation, program execution, results collection and their graphical representation using ns-3 based on the scenarios mentioned in RFC 7928. It was designed and developed in 2017 and actively maintained till 2019. In the past two years, the traffic control model in ns-3 has grown significantly in terms of supporting state-of-the-art packet scheduling and AQM algorithms. This project has four main goals: (1) upgrade the AQM Evaluation Suite according to the latest ns-3-dev, (2) enable support for latest packet scheduling, AQM algorithms and ECN functionality (3) update the examples in AQM Evaluation Suite to better suit the needs of researchers working in this area, and (4) make AQM Evaluation Suite available on the ns-3 app store.

* ''Required Experience:'' Familiarity with AQM and C++ programming.
* ''Bonus Experience:'' Familiarity with traffic control model in ns-3.
* ''Interests:'' Packet Scheduling algorithms, AQM algorithms and ECN.
* ''Difficulty:'' Medium.
* ''Recommended Reading:''
** AQM Evaluation Suite [[https://dl.acm.org/doi/abs/10.1145/3067665.3067674 Paper]] [[https://aqm-eval-suite.github.io/ Implementation]]
** [https://tools.ietf.org/html/rfc7928 RFC 7928]
** [https://www.nsnam.org/docs/models/html/traffic-control-layer.html Traffic Control Model in ns-3]

==== Upgrade Python bindings framework ====

Mentors: [mailto:tomh@tomh.org Tom Henderson], others TBD

The project has provided Python bindings via a toolchain combining [https://github.com/gjcarneiro/pybindgen pybindgen], [https://github.com/CastXML/CastXML CastXML], and [https://github.com/CastXML/pygccxml pygccxml]. This is a compile-time solution, and some drawbacks have appeared as the C++ language has evolved but the bindings framework has not kept pace (leading to errors in scanning the APIs, or incomplete API coverage). A recent summary can be found [https://mailman.isi.edu/pipermail/ns-developers/2021-February/015396.html here]. This project would aim to prototype and evaluate whether a different framework could be used (such as [https://cppyy.readthedocs.io/en/latest/ cppyy] or [https://pybind11.readthedocs.io/en/stable/ pybind11]). In any case, work can also include fixing one or more bugs/limitations found in our issue tracker with the label 'python bindings'.

* ''Required Experience:'' Familiarity with C++ and Python/C. Solid Python coding skills.
* ''Interests:'' Python bindings
* ''Difficulty:'' Medium to Hard.

==== TCP maximum segment size (MSS) improvements ====

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], others TBD

TCP performances are affected by the maximum segment size (MSS) - a wrong choice might either lead to inefficient transmission (higher overhead) or IP fragmentation.

At the moment ns-3 implementation allows to set the MSS via an Attribute (set by default to 536 bytes by TcpSocket Attribute "SegmentSize").
Although it is stated that it "may be adjusted based on MTU discovery", its value is not changed in a simulation.

The goal of the project is to update the MSS handling, allowing to:
1) Set it to a fixed size, or allowing auto-probing of "optimal" MSS,
2) Use and honor the TcpOptionMSS (RFC 793), with a proper example of use, and
3) React to intermediate links with short MTU, and/or to changes in the Path MTU (PMTU).

The last point is to be carefully handled, as in many points in the code there is an implicit assumption that the MSS is constant in a given flow.

Moreover, note that finding the optimal PMTU is not that simple, as IPv6 and IPv4 react differently to packets exceeding the link MTU, and they won't notify if a packet is shorter than the link MTU.
As a consequence, it would be useful to implement the Packetization Layer Path MTU Discovery (RFC 4821) - which might exceed the GSoC timeframe.

Hence, it would be advisable to carefully select the features to be supported and tested in the project, eventually paving the ground for future enhancements.

* ''Required Experience:'' Familiarity with TCP, IPv4 and IPv6, and in particular with fragmentation.
* ''Difficulty:'' Medium / Hard
* ''Recommended reading:''
** [https://en.wikipedia.org/wiki/Path_MTU_Discovery Wikipedia: Path MTU Discovery]
** [https://www.nsnam.org/bugzilla/show_bug.cgi?id=2064 UdpSocket::GetMtu() needed]
** [https://www.nsnam.org/bugzilla/show_bug.cgi?id=1751 TCP should react to MTU changes]
** [https://tools.ietf.org/html/rfc1191 RFC 1191]
** [https://tools.ietf.org/html/rfc4821 RFC 4821]
** [https://tools.ietf.org/html/rfc1122#page-85 RFC 1122]
** [https://tools.ietf.org/html/rfc6691 RFC 6991]
** [https://tools.ietf.org/html/rfc2923 RFC 2923]
** [https://blog.apnic.net/2014/12/15/ip-mtu-and-tcp-mss-missmatch-an-evil-for-network-performance/ APNIC blog - IP MTU and TCP MSS Missmatch – an evil for network performance]
** [https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3650/software/release/16-9/configuration_guide/ip/b_169_ip_3650_cg/configuring_tcp_mss_adjustment.pdf Cisco - Configuring TCP MSS Adjustment]

==== Enable IPv6 support for Ad hoc Routing Protocols in ns-3 ====

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

ns-3 contains models for proactive (DSDV and OLSR) and reactive (AODV and DSR) ad hoc routing protocols. However, these models are IPv4-only and do not provide support of IPv6 addressing. This project aims to enable IPv6 support for ad hoc routing protocols in ns-3, mainly for AODV. There are out-of-tree implementations of OLSR and DSDV that provide support for IPv6 addressing, and can be used as references to get started with this project.

The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.

Note: Enabling IPv6 support for these protocols is not a matter of simply changing out an IPv4-formatted address for an IPv6-formatted address. The IPv6 addressing architecture emphasizes scoping much more than does IPv4 (RFC 4007). Please suggest in your application how IPv6 address configuration (and possibly auto-configuration?) and address scopes (e.g. link-local vs. global) should be used in these protocols. Consulting the RFCs is highly recommended.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3
* ''Interests:'' Ad hoc routing
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]
** [https://www.nsnam.org/workshops/wns3-2016/posters/IPv6-support-for-OLSR.pdf IPv6 Support for OLSR in ns-3]

==== IPv6 global routing ====

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], others TBD

Creating a complex topology can be a problem, and sometimes the user do not want to be (also) concerned about setting up dynamic routing protocols (e.g., RIP, RIPng).
For IPv4, ns-3 provides two alternatives: GlobalRouting, and NixRouting, which just "do the trick" - they simply fill the routing tables in intermediate nodes, GlobalRouting using an approach similar to OSPF, NixRouting by leveraging the "abstract" knowledge of the network.
Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.

The problem is that they don't work for IPv6, and that's a huge limitation. The goal of the project is to fix that limitation. Note that the project must cope with different IPv6 address kinds (link-local, global, scoped multicast, etc.). Due to the limitation with GlobalRouting w.r.t. wireless channels, it would be advisable to start working with NixRouting.

The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with NixRouting and GlobalRouting implementations in ns-3
* ''Interests:'' IPv6 routing
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/docs/models/html/nix-vector-routing.html NixRouting model in ns-3]
** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]

==== Integration of MIPv6 module into ns-3 ====

Mentors: [mailto:manoj24.rana@gmail.com Manoj Kumar Rana]

The MIPv6 module had already been implemented in ns-3 (The links of their implementations are given below). But, these modules are still lacking in ns-3 main tree. One of the medium access control (MAC) layer issue was NetDevice up/down consistency which has been resolved through the GSoC 2020 project titled, “NetDevice up/down consistency and event chain”. The MIPv6 integration still requires understanding the behaviour of IPv6 and ICMPv6 protocols running in LTE module (mainly between PGW/SGW and eNB). Although IPv6 packets are now transferred over LTE network, the sole purpose of MIPv6 handoff i.e. switching mobile node between LTE and WiFi can only be accomplished by modifying the existing MIPv6 module and extending the existing LTE module.

* ''Required Experience:'' C++, LTE IPv6 support.
* ''Bonus Experience:'' Familiarity with MIPv6/PMIPv6 module implementations in ns-3
* ''Interests:'' IPv6
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/wiki/GSOC2017MobileIp MIPv6 model in ns-3]

[[Category:GSoC]]

GSOC2021Projects

2021-03-03T18:43:25Z

Mkrana: /* Mentors */

{{TOC}}

This page contains 2021 Google Summer of Code project ideas for ns-3. Students interested in participating in ns-3's GSoC program are free to get started on an idea or two, with the understanding that ns-3 has not yet been selected for GSoC and may not ultimately be selected.

* [http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2015/help_page GSoC Frequently Asked Questions]
* [[GSOC2021StudentGuide |ns-3's 2021 GSoC Student guide]]
* [http://en.flossmanuals.net/GSoCStudentGuide/ GSoC student guide (not ns-3 specific)]
* [[GSOC2020StudentApplicationTemplate |2020 GSoC Student application template]]
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]
* [http://en.flossmanuals.net/gsoc-mentoring/ GSoC Mentor guide (not ns-3 specific)]
* [[GSOCSelectionProcess | GSoC Student Selection Process]]
* ''Get in contact with the ns-3 team'': [http://mailman.isi.edu/mailman/listinfo/ns-developers ns-developers mailing list] | ''chat'' https://ns-3.zulipchat.com/

=== About the ns-3 project ===

ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.

Users of ns-3 can construct simulations of computer networks using models of traffic generators, protocols such as TCP/IP, and devices and channels such as WiFi, and analyze or visualize the results. Simulation plays a vital role in the research and education process, because of the ability for simulations to obtain reproducible results (particularly for wireless protocol design), scale to large networks, and study systems that have not yet been implemented. A particular emphasis in ns-3 is the high degree of realism in the models (including frameworks for real application and kernel code) and integration of the tool with virtual machine environments and testbeds; we view that researchers need to move more effortlessly between simulation, testbeds, and live experiments, and ns-3 is designed to facilitate that.

ns-3 has participated in past GSoCs during 2008-10, 2012-15, and 2017-20. We seek students interested in the intersection of wireless and computer networking, performance analysis, and open source software.

=== Org admins ===

Google Summer of Code organizational admins for ns-3 are [mailto:tpecorella@mac.com Tommaso Pecorella], [mailto:tahiliani.nitk@gmail.com Mohit Tahiliani] and [mailto:tomh@tomh.org Tom Henderson]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com Zulip].

=== Mentors ===

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 or Tommaso Pecorella of interest. Mentors familiar with ns-3 development practices will be preferred, to improve the chances of student code merge. In 2021, we are going to be seeking two-person or multiple-person mentoring teams for projects, to help with the mentoring workload and bring more expertise.

The current list of prospective mentors for 2021 is below:

* Tom Henderson
* Tommaso Pecorella
* Mohit P. Tahiliani
* Manoj Kumar Rana
* Sebastien Deronne
* Hany Assasa
* Davide Magrin
* Vivek Jain
* Viyom Mittal
* Mishal Shah

=== Changes from last year ===

Google has changed the program, reducing it to half the paid time from previous summers. Therefore, we will be seeking to define projects with much reduced scope than in years past. In general, we seek projects that aim to improve the existing simulator rather than add new features.

=== Students: how to participate ===

For students interested in applying to ns-3 for GSOC, please go through the following list to get started:
* Read the official [http://en.flossmanuals.net/GSoCStudentGuide/ GSoC student guide].
* Read [[GSOC2021StudentGuide |ns-3's GSoC Student guide]]
* Look through our [[#Project Ideas]] below to see if you find a project that interests you.
* Review the [http://www.nsnam.org/ns-3-32/documentation ns-3 tutorial] thoroughly, if you have not already done so.
* Once it is posted, look through the [[GSOC2021StudentApplicationTemplate |GSoC Student application template]] to start preparing your proposal. We will wait to see whether we are actually part of GSoC before posting this.
* Next, proceed to get in touch with the developers on the mailing list or chat room and refine your proposal.
* In parallel, make sure you prepare a patch as per the patch requirement guidelines (to be posted at a later date). Your application to ns-3 will not be considered if you do not fulfill this requirement.

Below is a list of [[#Project Ideas]] proposed by the ns-3 team for Google Summer of Code 2021. 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.

<blockquote>
Each project idea within a particular priority has been tagged with the following properties:
* ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.
* ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.
* ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful students might apply their experiences coming out of this project.
* ''Difficulty:'' easy, medium or difficult
* ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.

Note that all of the projects require some experience and comfort with C++. Project ideas for which C++ is noted as a required experience will require more and deeper familiarity with the language. A similar notion applies to computer networking, BSD sockets, etc: Familiarity is strongly preferred, but is not required except where explicitly noted due to the topic being more advanced in that regard. A few projects are more Python-centric.
</blockquote>

=== Mentors: how to participate ===

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:

* The projects are sized such that there can be a code merge by the end of the coding period. The scope of the project should be such that it is very difficult to not have a code merge by the end of the summer.
* The proposed projects are not too open-ended. That is, if the deliverables or a clear path to the same are not well understood, it is better kept outside GSOC.
* There should be a clear merge path to one of the main project code repositories (ns-3-dev, ns-3-dce, bake) by the end of the summer, either because the patches directly apply to these repositories, or because they apply to an ns-3 module that is in the process of being merged with ns-3-dev.

== Project Ideas ==

'''Note to students:''' These ideas are not listed in any priority order.

==== Linux-like Loss Detection Techniques for ns-3 TCP ====

Mentors: [mailto:jain.vivek.anand@gmail.com Vivek Jain], [mailto:viyommittal@gmail.com Viyom Mittal], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

Forward Acknowledgement (FACK), Duplicate Selective Acknowledgement (DSACK), Tail Loss Probe (TLP) and Recent Acknowledgement (RACK) are the loss detection techniques implemented in the Linux kernel. These techniques have been already implemented for ns-3 TCP but their code is not yet merged into the mainline. This project has four main goals: (1) update the implementation of these techniques according to the latest ns-3-dev, (2) develop a framework to test the functionality of these techniques, (3) develop example program(s) to demonstrate the usage of these techniques in ns-3 and (4) merge these techniques in the mainline of ns-3.

* ''Required Experience:'' Familiarity with TCP and C++ programming.
* ''Bonus Experience:'' Familiarity with TCP implementation in Linux kernel.
* ''Interests:'' TCP packet loss detection techniques.
* ''Difficulty:'' Medium to Hard.
* ''Recommended Reading:''
** Forward Acknowledgement (FACK) [[https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.41.2559&rep=rep1&type=pdf Paper]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]
** Duplicate Selective Acknowledgment (DSACK) [[https://tools.ietf.org/html/rfc2883 RFC 2883]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]
** Tail Loss Probe (TLP) [[https://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01 Internet Draft]] [[https://gitlab.com/ShikhaBakshi/ns-3-dev/-/commits/TLP Implementation]]
** Recent Acknowledgment (RACK) [[https://tools.ietf.org/html/draft-ietf-tcpm-rack-15 Internet Draft]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]

==== Direct Code Execution upgrade ====

Mentor: [mailto:tomh@tomh.org Tom Henderson]

ns-3 has an extension known as Direct Code Execution, which allows users to build C or C++-based applications, and open source (Linux, FreeBSD) kernels, into ns-3. However, support for the latest kernels (e.g. Linux kernel 5 series) and latest glibc library versions has languished. We also could better integrate DCE with the main ns-3 tree. This project seeks a student interested in DCE, improving usability, and making it current with latest kernels and toolchains. The payoff of this type of project is very high since DCE makes available a lot of real-world models for use in ns-3. If you select this project idea, please engage with us on the developers list, and consider to take a look at solving one of the [https://www.nsnam.org/bugzilla/buglist.cgi?bug_status=__open__&content=&no_redirect=1&order=Importance&product=dce&query_format=specific open DCE issues in our tracker], for starters.
* ''Required Experience:'' good hacking skills on Linux, C, C++, Python
* ''Difficulty:'' Hard.
* ''For more information:'' https://www.nsnam.org/about/projects/direct-code-execution/, https://github.com/direct-code-execution/ns-3-dce

==== LoRaWAN ====

Mentor: [mailto:davide@magr.in Davide Magrin]

LoRaWAN is a communication technology for the Internet of Things, that allows battery-powered devices to wirelessly transmit data over long distances. Thanks to the lorawan module for ns-3, users can simulate networks where thousands of such devices communicate with a central server through multiple gateways. Packets might collide and be lost, devices might need to re-transmit them, and the central server can tell devices to change their transmission parameters according to suitable, exotic algorithms - we model it all.

This module rapidly grew in the last period, with the addition of various features and functionalities that are not completely tested nor documented, yet. In this project, you will mostly work to (1) integrate these features into the mainline code, and (2) improve the LoRaWAN module's testing and documentation.

Additionally, according to time availability and your interest, you can also help showcasing the potentialities of the lorawan module through the SEM library. Indeed, SEM can be used together with the lorawan module to provide users with meaningful examples, with the dual objective of giving a better understanding of what is going on within a single simulation, as well as how a simulation campaign can be easily conducted.

* ''Required Experience'': Familiarity with C++ programming.
* ''Bonus Experience'': Familiarity with Python programming.
* ''Interests'': Internet of Things communication protocols.
* ''Difficulty'': Medium to Hard.
* ''For more info'': https://github.com/signetlabdei/lorawan, http://github.com/signetlabdei/sem

==== SEM - Examples and documentation ====

Mentor: [mailto:davide@magr.in Davide Magrin]

The SEM Python library was designed to help ns-3 users run complex simulation campaigns. Among other things, SEM strives to make it as easy as possible to parse the output of simulations and to obtain plots that show the impact of simulation parameters on the network's performance.

One of the objectives for the next big SEM release is to provide users with more examples that are both easy to modify and that showcase the full potential of the library and of the Python data analysis ecosystem. In this project, your objective will be to show how SEM can be used from within Jupyter Notebooks to gradually explore the behavior of a network. Aside from the creation of new examples, you will also have the opportunity to try your hand at the all-important task of writing documentation. If there's time and you feel like tackling the issue, in a second part of the project you will also explore how SEM can be used to visualize the behavior of single simulations that leverage ns-3's built-in logging.

* ''Required Experience'': Familiarity with Python and C++ programming.
* ''Bonus Experience'': Familiarity with Jupyter Notebooks.
* ''Difficulty'': Medium.
* ''For more info'': http://github.com/signetlabdei/sem

==== Upgrade the AQM Evaluation Suite for ns-3 ====

Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], [mailto:jain.vivek.anand@gmail.com Vivek Jain], [mailto:shahmishal1998@gmail.com Mishal Shah]

AQM (Active Queue Management) evaluation suite for ns-3 helps to quickly study the performance of AQM algorithms based on the guidelines mentioned in RFC 7928. This suite automates simulation setup, topology creation, traffic generation, program execution, results collection and their graphical representation using ns-3 based on the scenarios mentioned in RFC 7928. It was designed and developed in 2017 and actively maintained till 2019. In the past two years, the traffic control model in ns-3 has grown significantly in terms of supporting state-of-the-art packet scheduling and AQM algorithms. This project has four main goals: (1) upgrade the AQM Evaluation Suite according to the latest ns-3-dev, (2) enable support for latest packet scheduling, AQM algorithms and ECN functionality (3) update the examples in AQM Evaluation Suite to better suit the needs of researchers working in this area, and (4) make AQM Evaluation Suite available on the ns-3 app store.

* ''Required Experience:'' Familiarity with AQM and C++ programming.
* ''Bonus Experience:'' Familiarity with traffic control model in ns-3.
* ''Interests:'' Packet Scheduling algorithms, AQM algorithms and ECN.
* ''Difficulty:'' Medium.
* ''Recommended Reading:''
** AQM Evaluation Suite [[https://dl.acm.org/doi/abs/10.1145/3067665.3067674 Paper]] [[https://aqm-eval-suite.github.io/ Implementation]]
** [https://tools.ietf.org/html/rfc7928 RFC 7928]
** [https://www.nsnam.org/docs/models/html/traffic-control-layer.html Traffic Control Model in ns-3]

==== Upgrade Python bindings framework ====

Mentors: [mailto:tomh@tomh.org Tom Henderson], others TBD

The project has provided Python bindings via a toolchain combining [https://github.com/gjcarneiro/pybindgen pybindgen], [https://github.com/CastXML/CastXML CastXML], and [https://github.com/CastXML/pygccxml pygccxml]. This is a compile-time solution, and some drawbacks have appeared as the C++ language has evolved but the bindings framework has not kept pace (leading to errors in scanning the APIs, or incomplete API coverage). A recent summary can be found [https://mailman.isi.edu/pipermail/ns-developers/2021-February/015396.html here]. This project would aim to prototype and evaluate whether a different framework could be used (such as [https://cppyy.readthedocs.io/en/latest/ cppyy] or [https://pybind11.readthedocs.io/en/stable/ pybind11]). In any case, work can also include fixing one or more bugs/limitations found in our issue tracker with the label 'python bindings'.

* ''Required Experience:'' Familiarity with C++ and Python/C. Solid Python coding skills.
* ''Interests:'' Python bindings
* ''Difficulty:'' Medium to Hard.

==== TCP maximum segment size (MSS) improvements ====

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], others TBD

TCP performances are affected by the maximum segment size (MSS) - a wrong choice might either lead to inefficient transmission (higher overhead) or IP fragmentation.

At the moment ns-3 implementation allows to set the MSS via an Attribute (set by default to 536 bytes by TcpSocket Attribute "SegmentSize").
Although it is stated that it "may be adjusted based on MTU discovery", its value is not changed in a simulation.

The goal of the project is to update the MSS handling, allowing to:
1) Set it to a fixed size, or allowing auto-probing of "optimal" MSS,
2) Use and honor the TcpOptionMSS (RFC 793), with a proper example of use, and
3) React to intermediate links with short MTU, and/or to changes in the Path MTU (PMTU).

The last point is to be carefully handled, as in many points in the code there is an implicit assumption that the MSS is constant in a given flow.

Moreover, note that finding the optimal PMTU is not that simple, as IPv6 and IPv4 react differently to packets exceeding the link MTU, and they won't notify if a packet is shorter than the link MTU.
As a consequence, it would be useful to implement the Packetization Layer Path MTU Discovery (RFC 4821) - which might exceed the GSoC timeframe.

Hence, it would be advisable to carefully select the features to be supported and tested in the project, eventually paving the ground for future enhancements.

* ''Required Experience:'' Familiarity with TCP, IPv4 and IPv6, and in particular with fragmentation.
* ''Difficulty:'' Medium / Hard
* ''Recommended reading:''
** [https://en.wikipedia.org/wiki/Path_MTU_Discovery Wikipedia: Path MTU Discovery]
** [https://www.nsnam.org/bugzilla/show_bug.cgi?id=2064 UdpSocket::GetMtu() needed]
** [https://www.nsnam.org/bugzilla/show_bug.cgi?id=1751 TCP should react to MTU changes]
** [https://tools.ietf.org/html/rfc1191 RFC 1191]
** [https://tools.ietf.org/html/rfc4821 RFC 4821]
** [https://tools.ietf.org/html/rfc1122#page-85 RFC 1122]
** [https://tools.ietf.org/html/rfc6691 RFC 6991]
** [https://tools.ietf.org/html/rfc2923 RFC 2923]
** [https://blog.apnic.net/2014/12/15/ip-mtu-and-tcp-mss-missmatch-an-evil-for-network-performance/ APNIC blog - IP MTU and TCP MSS Missmatch – an evil for network performance]
** [https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3650/software/release/16-9/configuration_guide/ip/b_169_ip_3650_cg/configuring_tcp_mss_adjustment.pdf Cisco - Configuring TCP MSS Adjustment]

==== Enable IPv6 support for Ad hoc Routing Protocols in ns-3 ====

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

ns-3 contains models for proactive (DSDV and OLSR) and reactive (AODV and DSR) ad hoc routing protocols. However, these models are IPv4-only and do not provide support of IPv6 addressing. This project aims to enable IPv6 support for ad hoc routing protocols in ns-3, mainly for AODV. There are out-of-tree implementations of OLSR and DSDV that provide support for IPv6 addressing, and can be used as references to get started with this project.

The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.

Note: Enabling IPv6 support for these protocols is not a matter of simply changing out an IPv4-formatted address for an IPv6-formatted address. The IPv6 addressing architecture emphasizes scoping much more than does IPv4 (RFC 4007). Please suggest in your application how IPv6 address configuration (and possibly auto-configuration?) and address scopes (e.g. link-local vs. global) should be used in these protocols. Consulting the RFCs is highly recommended.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3
* ''Interests:'' Ad hoc routing
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]
** [https://www.nsnam.org/workshops/wns3-2016/posters/IPv6-support-for-OLSR.pdf IPv6 Support for OLSR in ns-3]

==== IPv6 global routing ====

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], others TBD

Creating a complex topology can be a problem, and sometimes the user do not want to be (also) concerned about setting up dynamic routing protocols (e.g., RIP, RIPng).
For IPv4, ns-3 provides two alternatives: GlobalRouting, and NixRouting, which just "do the trick" - they simply fill the routing tables in intermediate nodes, GlobalRouting using an approach similar to OSPF, NixRouting by leveraging the "abstract" knowledge of the network.
Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.

The problem is that they don't work for IPv6, and that's a huge limitation. The goal of the project is to fix that limitation. Note that the project must cope with different IPv6 address kinds (link-local, global, scoped multicast, etc.). Due to the limitation with GlobalRouting w.r.t. wireless channels, it would be advisable to start working with NixRouting.

The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with NixRouting and GlobalRouting implementations in ns-3
* ''Interests:'' IPv6 routing
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/docs/models/html/nix-vector-routing.html NixRouting model in ns-3]
** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]

==== Integration of MIPv6 module into ns-3 with LTE-WiFi Handoff support ====

Mentors: [mailto:manoj24.rana@gmail.com Manoj Kumar Rana]

The MIPv6 module had already been implemented in ns-3 (The links of their implementations are given below). But, these modules are still lacking in ns-3 main tree. One of the medium access control (MAC) layer issue was NetDevice up/down consistency which has been resolved through the GSoC 2020 project titled, “NetDevice up/down consistency and event chain”. The MIPv6 integration still requires understanding the behaviour of IPv6 and ICMPv6 protocols running in LTE module (mainly between PGW/SGW and eNB). Although IPv6 packets are now transferred over LTE network, the sole purpose of MIPv6 handoff i.e. switching mobile node between LTE and WiFi can only be accomplished by modifying the existing MIPv6 module and extending the existing LTE module.

* ''Required Experience:'' C++, LTE IPv6 support.
* ''Bonus Experience:'' Familiarity with MIPv6/PMIPv6 module implementations in ns-3
* ''Interests:'' IPv6
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/wiki/GSOC2017MobileIp MIPv6 model in ns-3]

[[Category:GSoC]]

GSOC2021Projects

2021-03-03T18:41:16Z

Mkrana:

{{TOC}}

This page contains 2021 Google Summer of Code project ideas for ns-3. Students interested in participating in ns-3's GSoC program are free to get started on an idea or two, with the understanding that ns-3 has not yet been selected for GSoC and may not ultimately be selected.

* [http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2015/help_page GSoC Frequently Asked Questions]
* [[GSOC2021StudentGuide |ns-3's 2021 GSoC Student guide]]
* [http://en.flossmanuals.net/GSoCStudentGuide/ GSoC student guide (not ns-3 specific)]
* [[GSOC2020StudentApplicationTemplate |2020 GSoC Student application template]]
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]
* [http://en.flossmanuals.net/gsoc-mentoring/ GSoC Mentor guide (not ns-3 specific)]
* [[GSOCSelectionProcess | GSoC Student Selection Process]]
* ''Get in contact with the ns-3 team'': [http://mailman.isi.edu/mailman/listinfo/ns-developers ns-developers mailing list] | ''chat'' https://ns-3.zulipchat.com/

=== About the ns-3 project ===

ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.

Users of ns-3 can construct simulations of computer networks using models of traffic generators, protocols such as TCP/IP, and devices and channels such as WiFi, and analyze or visualize the results. Simulation plays a vital role in the research and education process, because of the ability for simulations to obtain reproducible results (particularly for wireless protocol design), scale to large networks, and study systems that have not yet been implemented. A particular emphasis in ns-3 is the high degree of realism in the models (including frameworks for real application and kernel code) and integration of the tool with virtual machine environments and testbeds; we view that researchers need to move more effortlessly between simulation, testbeds, and live experiments, and ns-3 is designed to facilitate that.

ns-3 has participated in past GSoCs during 2008-10, 2012-15, and 2017-20. We seek students interested in the intersection of wireless and computer networking, performance analysis, and open source software.

=== Org admins ===

Google Summer of Code organizational admins for ns-3 are [mailto:tpecorella@mac.com Tommaso Pecorella], [mailto:tahiliani.nitk@gmail.com Mohit Tahiliani] and [mailto:tomh@tomh.org Tom Henderson]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com Zulip].

=== Mentors ===

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 or Tommaso Pecorella of interest. Mentors familiar with ns-3 development practices will be preferred, to improve the chances of student code merge. In 2021, we are going to be seeking two-person or multiple-person mentoring teams for projects, to help with the mentoring workload and bring more expertise.

The current list of prospective mentors for 2021 is below:

* Tom Henderson
* Tommaso Pecorella
* Mohit P. Tahiliani
* Sebastien Deronne
* Hany Assasa
* Davide Magrin
* Vivek Jain
* Viyom Mittal
* Mishal Shah

=== Changes from last year ===

Google has changed the program, reducing it to half the paid time from previous summers. Therefore, we will be seeking to define projects with much reduced scope than in years past. In general, we seek projects that aim to improve the existing simulator rather than add new features.

=== Students: how to participate ===

For students interested in applying to ns-3 for GSOC, please go through the following list to get started:
* Read the official [http://en.flossmanuals.net/GSoCStudentGuide/ GSoC student guide].
* Read [[GSOC2021StudentGuide |ns-3's GSoC Student guide]]
* Look through our [[#Project Ideas]] below to see if you find a project that interests you.
* Review the [http://www.nsnam.org/ns-3-32/documentation ns-3 tutorial] thoroughly, if you have not already done so.
* Once it is posted, look through the [[GSOC2021StudentApplicationTemplate |GSoC Student application template]] to start preparing your proposal. We will wait to see whether we are actually part of GSoC before posting this.
* Next, proceed to get in touch with the developers on the mailing list or chat room and refine your proposal.
* In parallel, make sure you prepare a patch as per the patch requirement guidelines (to be posted at a later date). Your application to ns-3 will not be considered if you do not fulfill this requirement.

Below is a list of [[#Project Ideas]] proposed by the ns-3 team for Google Summer of Code 2021. 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.

<blockquote>
Each project idea within a particular priority has been tagged with the following properties:
* ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.
* ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.
* ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful students might apply their experiences coming out of this project.
* ''Difficulty:'' easy, medium or difficult
* ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.

Note that all of the projects require some experience and comfort with C++. Project ideas for which C++ is noted as a required experience will require more and deeper familiarity with the language. A similar notion applies to computer networking, BSD sockets, etc: Familiarity is strongly preferred, but is not required except where explicitly noted due to the topic being more advanced in that regard. A few projects are more Python-centric.
</blockquote>

=== Mentors: how to participate ===

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:

* The projects are sized such that there can be a code merge by the end of the coding period. The scope of the project should be such that it is very difficult to not have a code merge by the end of the summer.
* The proposed projects are not too open-ended. That is, if the deliverables or a clear path to the same are not well understood, it is better kept outside GSOC.
* There should be a clear merge path to one of the main project code repositories (ns-3-dev, ns-3-dce, bake) by the end of the summer, either because the patches directly apply to these repositories, or because they apply to an ns-3 module that is in the process of being merged with ns-3-dev.

== Project Ideas ==

'''Note to students:''' These ideas are not listed in any priority order.

==== Linux-like Loss Detection Techniques for ns-3 TCP ====

Mentors: [mailto:jain.vivek.anand@gmail.com Vivek Jain], [mailto:viyommittal@gmail.com Viyom Mittal], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

Forward Acknowledgement (FACK), Duplicate Selective Acknowledgement (DSACK), Tail Loss Probe (TLP) and Recent Acknowledgement (RACK) are the loss detection techniques implemented in the Linux kernel. These techniques have been already implemented for ns-3 TCP but their code is not yet merged into the mainline. This project has four main goals: (1) update the implementation of these techniques according to the latest ns-3-dev, (2) develop a framework to test the functionality of these techniques, (3) develop example program(s) to demonstrate the usage of these techniques in ns-3 and (4) merge these techniques in the mainline of ns-3.

* ''Required Experience:'' Familiarity with TCP and C++ programming.
* ''Bonus Experience:'' Familiarity with TCP implementation in Linux kernel.
* ''Interests:'' TCP packet loss detection techniques.
* ''Difficulty:'' Medium to Hard.
* ''Recommended Reading:''
** Forward Acknowledgement (FACK) [[https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.41.2559&rep=rep1&type=pdf Paper]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]
** Duplicate Selective Acknowledgment (DSACK) [[https://tools.ietf.org/html/rfc2883 RFC 2883]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]
** Tail Loss Probe (TLP) [[https://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01 Internet Draft]] [[https://gitlab.com/ShikhaBakshi/ns-3-dev/-/commits/TLP Implementation]]
** Recent Acknowledgment (RACK) [[https://tools.ietf.org/html/draft-ietf-tcpm-rack-15 Internet Draft]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]

==== Direct Code Execution upgrade ====

Mentor: [mailto:tomh@tomh.org Tom Henderson]

ns-3 has an extension known as Direct Code Execution, which allows users to build C or C++-based applications, and open source (Linux, FreeBSD) kernels, into ns-3. However, support for the latest kernels (e.g. Linux kernel 5 series) and latest glibc library versions has languished. We also could better integrate DCE with the main ns-3 tree. This project seeks a student interested in DCE, improving usability, and making it current with latest kernels and toolchains. The payoff of this type of project is very high since DCE makes available a lot of real-world models for use in ns-3. If you select this project idea, please engage with us on the developers list, and consider to take a look at solving one of the [https://www.nsnam.org/bugzilla/buglist.cgi?bug_status=__open__&content=&no_redirect=1&order=Importance&product=dce&query_format=specific open DCE issues in our tracker], for starters.
* ''Required Experience:'' good hacking skills on Linux, C, C++, Python
* ''Difficulty:'' Hard.
* ''For more information:'' https://www.nsnam.org/about/projects/direct-code-execution/, https://github.com/direct-code-execution/ns-3-dce

==== LoRaWAN ====

Mentor: [mailto:davide@magr.in Davide Magrin]

LoRaWAN is a communication technology for the Internet of Things, that allows battery-powered devices to wirelessly transmit data over long distances. Thanks to the lorawan module for ns-3, users can simulate networks where thousands of such devices communicate with a central server through multiple gateways. Packets might collide and be lost, devices might need to re-transmit them, and the central server can tell devices to change their transmission parameters according to suitable, exotic algorithms - we model it all.

This module rapidly grew in the last period, with the addition of various features and functionalities that are not completely tested nor documented, yet. In this project, you will mostly work to (1) integrate these features into the mainline code, and (2) improve the LoRaWAN module's testing and documentation.

Additionally, according to time availability and your interest, you can also help showcasing the potentialities of the lorawan module through the SEM library. Indeed, SEM can be used together with the lorawan module to provide users with meaningful examples, with the dual objective of giving a better understanding of what is going on within a single simulation, as well as how a simulation campaign can be easily conducted.

* ''Required Experience'': Familiarity with C++ programming.
* ''Bonus Experience'': Familiarity with Python programming.
* ''Interests'': Internet of Things communication protocols.
* ''Difficulty'': Medium to Hard.
* ''For more info'': https://github.com/signetlabdei/lorawan, http://github.com/signetlabdei/sem

==== SEM - Examples and documentation ====

Mentor: [mailto:davide@magr.in Davide Magrin]

The SEM Python library was designed to help ns-3 users run complex simulation campaigns. Among other things, SEM strives to make it as easy as possible to parse the output of simulations and to obtain plots that show the impact of simulation parameters on the network's performance.

One of the objectives for the next big SEM release is to provide users with more examples that are both easy to modify and that showcase the full potential of the library and of the Python data analysis ecosystem. In this project, your objective will be to show how SEM can be used from within Jupyter Notebooks to gradually explore the behavior of a network. Aside from the creation of new examples, you will also have the opportunity to try your hand at the all-important task of writing documentation. If there's time and you feel like tackling the issue, in a second part of the project you will also explore how SEM can be used to visualize the behavior of single simulations that leverage ns-3's built-in logging.

* ''Required Experience'': Familiarity with Python and C++ programming.
* ''Bonus Experience'': Familiarity with Jupyter Notebooks.
* ''Difficulty'': Medium.
* ''For more info'': http://github.com/signetlabdei/sem

==== Upgrade the AQM Evaluation Suite for ns-3 ====

Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], [mailto:jain.vivek.anand@gmail.com Vivek Jain], [mailto:shahmishal1998@gmail.com Mishal Shah]

AQM (Active Queue Management) evaluation suite for ns-3 helps to quickly study the performance of AQM algorithms based on the guidelines mentioned in RFC 7928. This suite automates simulation setup, topology creation, traffic generation, program execution, results collection and their graphical representation using ns-3 based on the scenarios mentioned in RFC 7928. It was designed and developed in 2017 and actively maintained till 2019. In the past two years, the traffic control model in ns-3 has grown significantly in terms of supporting state-of-the-art packet scheduling and AQM algorithms. This project has four main goals: (1) upgrade the AQM Evaluation Suite according to the latest ns-3-dev, (2) enable support for latest packet scheduling, AQM algorithms and ECN functionality (3) update the examples in AQM Evaluation Suite to better suit the needs of researchers working in this area, and (4) make AQM Evaluation Suite available on the ns-3 app store.

* ''Required Experience:'' Familiarity with AQM and C++ programming.
* ''Bonus Experience:'' Familiarity with traffic control model in ns-3.
* ''Interests:'' Packet Scheduling algorithms, AQM algorithms and ECN.
* ''Difficulty:'' Medium.
* ''Recommended Reading:''
** AQM Evaluation Suite [[https://dl.acm.org/doi/abs/10.1145/3067665.3067674 Paper]] [[https://aqm-eval-suite.github.io/ Implementation]]
** [https://tools.ietf.org/html/rfc7928 RFC 7928]
** [https://www.nsnam.org/docs/models/html/traffic-control-layer.html Traffic Control Model in ns-3]

==== Upgrade Python bindings framework ====

Mentors: [mailto:tomh@tomh.org Tom Henderson], others TBD

The project has provided Python bindings via a toolchain combining [https://github.com/gjcarneiro/pybindgen pybindgen], [https://github.com/CastXML/CastXML CastXML], and [https://github.com/CastXML/pygccxml pygccxml]. This is a compile-time solution, and some drawbacks have appeared as the C++ language has evolved but the bindings framework has not kept pace (leading to errors in scanning the APIs, or incomplete API coverage). A recent summary can be found [https://mailman.isi.edu/pipermail/ns-developers/2021-February/015396.html here]. This project would aim to prototype and evaluate whether a different framework could be used (such as [https://cppyy.readthedocs.io/en/latest/ cppyy] or [https://pybind11.readthedocs.io/en/stable/ pybind11]). In any case, work can also include fixing one or more bugs/limitations found in our issue tracker with the label 'python bindings'.

* ''Required Experience:'' Familiarity with C++ and Python/C. Solid Python coding skills.
* ''Interests:'' Python bindings
* ''Difficulty:'' Medium to Hard.

==== TCP maximum segment size (MSS) improvements ====

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], others TBD

TCP performances are affected by the maximum segment size (MSS) - a wrong choice might either lead to inefficient transmission (higher overhead) or IP fragmentation.

At the moment ns-3 implementation allows to set the MSS via an Attribute (set by default to 536 bytes by TcpSocket Attribute "SegmentSize").
Although it is stated that it "may be adjusted based on MTU discovery", its value is not changed in a simulation.

The goal of the project is to update the MSS handling, allowing to:
1) Set it to a fixed size, or allowing auto-probing of "optimal" MSS,
2) Use and honor the TcpOptionMSS (RFC 793), with a proper example of use, and
3) React to intermediate links with short MTU, and/or to changes in the Path MTU (PMTU).

The last point is to be carefully handled, as in many points in the code there is an implicit assumption that the MSS is constant in a given flow.

Moreover, note that finding the optimal PMTU is not that simple, as IPv6 and IPv4 react differently to packets exceeding the link MTU, and they won't notify if a packet is shorter than the link MTU.
As a consequence, it would be useful to implement the Packetization Layer Path MTU Discovery (RFC 4821) - which might exceed the GSoC timeframe.

Hence, it would be advisable to carefully select the features to be supported and tested in the project, eventually paving the ground for future enhancements.

* ''Required Experience:'' Familiarity with TCP, IPv4 and IPv6, and in particular with fragmentation.
* ''Difficulty:'' Medium / Hard
* ''Recommended reading:''
** [https://en.wikipedia.org/wiki/Path_MTU_Discovery Wikipedia: Path MTU Discovery]
** [https://www.nsnam.org/bugzilla/show_bug.cgi?id=2064 UdpSocket::GetMtu() needed]
** [https://www.nsnam.org/bugzilla/show_bug.cgi?id=1751 TCP should react to MTU changes]
** [https://tools.ietf.org/html/rfc1191 RFC 1191]
** [https://tools.ietf.org/html/rfc4821 RFC 4821]
** [https://tools.ietf.org/html/rfc1122#page-85 RFC 1122]
** [https://tools.ietf.org/html/rfc6691 RFC 6991]
** [https://tools.ietf.org/html/rfc2923 RFC 2923]
** [https://blog.apnic.net/2014/12/15/ip-mtu-and-tcp-mss-missmatch-an-evil-for-network-performance/ APNIC blog - IP MTU and TCP MSS Missmatch – an evil for network performance]
** [https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3650/software/release/16-9/configuration_guide/ip/b_169_ip_3650_cg/configuring_tcp_mss_adjustment.pdf Cisco - Configuring TCP MSS Adjustment]

==== Enable IPv6 support for Ad hoc Routing Protocols in ns-3 ====

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

ns-3 contains models for proactive (DSDV and OLSR) and reactive (AODV and DSR) ad hoc routing protocols. However, these models are IPv4-only and do not provide support of IPv6 addressing. This project aims to enable IPv6 support for ad hoc routing protocols in ns-3, mainly for AODV. There are out-of-tree implementations of OLSR and DSDV that provide support for IPv6 addressing, and can be used as references to get started with this project.

The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.

Note: Enabling IPv6 support for these protocols is not a matter of simply changing out an IPv4-formatted address for an IPv6-formatted address. The IPv6 addressing architecture emphasizes scoping much more than does IPv4 (RFC 4007). Please suggest in your application how IPv6 address configuration (and possibly auto-configuration?) and address scopes (e.g. link-local vs. global) should be used in these protocols. Consulting the RFCs is highly recommended.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3
* ''Interests:'' Ad hoc routing
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]
** [https://www.nsnam.org/workshops/wns3-2016/posters/IPv6-support-for-OLSR.pdf IPv6 Support for OLSR in ns-3]

==== IPv6 global routing ====

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], others TBD

Creating a complex topology can be a problem, and sometimes the user do not want to be (also) concerned about setting up dynamic routing protocols (e.g., RIP, RIPng).
For IPv4, ns-3 provides two alternatives: GlobalRouting, and NixRouting, which just "do the trick" - they simply fill the routing tables in intermediate nodes, GlobalRouting using an approach similar to OSPF, NixRouting by leveraging the "abstract" knowledge of the network.
Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.

The problem is that they don't work for IPv6, and that's a huge limitation. The goal of the project is to fix that limitation. Note that the project must cope with different IPv6 address kinds (link-local, global, scoped multicast, etc.). Due to the limitation with GlobalRouting w.r.t. wireless channels, it would be advisable to start working with NixRouting.

The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with NixRouting and GlobalRouting implementations in ns-3
* ''Interests:'' IPv6 routing
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/docs/models/html/nix-vector-routing.html NixRouting model in ns-3]
** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]

==== Integration of MIPv6 module into ns-3 with LTE-WiFi Handoff support ====

Mentors: [mailto:manoj24.rana@gmail.com Manoj Kumar Rana]

The MIPv6 module had already been implemented in ns-3 (The links of their implementations are given below). But, these modules are still lacking in ns-3 main tree. One of the medium access control (MAC) layer issue was NetDevice up/down consistency which has been resolved through the GSoC 2020 project titled, “NetDevice up/down consistency and event chain”. The MIPv6 integration still requires understanding the behaviour of IPv6 and ICMPv6 protocols running in LTE module (mainly between PGW/SGW and eNB). Although IPv6 packets are now transferred over LTE network, the sole purpose of MIPv6 handoff i.e. switching mobile node between LTE and WiFi can only be accomplished by modifying the existing MIPv6 module and extending the existing LTE module.

* ''Required Experience:'' C++, LTE IPv6 support.
* ''Bonus Experience:'' Familiarity with MIPv6/PMIPv6 module implementations in ns-3
* ''Interests:'' IPv6
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/wiki/GSOC2017MobileIp MIPv6 model in ns-3]

[[Category:GSoC]]

GSOC2021Projects

2021-03-03T18:39:01Z

Mkrana:

{{TOC}}

This page contains 2021 Google Summer of Code project ideas for ns-3. Students interested in participating in ns-3's GSoC program are free to get started on an idea or two, with the understanding that ns-3 has not yet been selected for GSoC and may not ultimately be selected.

* [http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2015/help_page GSoC Frequently Asked Questions]
* [[GSOC2021StudentGuide |ns-3's 2021 GSoC Student guide]]
* [http://en.flossmanuals.net/GSoCStudentGuide/ GSoC student guide (not ns-3 specific)]
* [[GSOC2020StudentApplicationTemplate |2020 GSoC Student application template]]
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]
* [http://en.flossmanuals.net/gsoc-mentoring/ GSoC Mentor guide (not ns-3 specific)]
* [[GSOCSelectionProcess | GSoC Student Selection Process]]
* ''Get in contact with the ns-3 team'': [http://mailman.isi.edu/mailman/listinfo/ns-developers ns-developers mailing list] | ''chat'' https://ns-3.zulipchat.com/

=== About the ns-3 project ===

ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.

Users of ns-3 can construct simulations of computer networks using models of traffic generators, protocols such as TCP/IP, and devices and channels such as WiFi, and analyze or visualize the results. Simulation plays a vital role in the research and education process, because of the ability for simulations to obtain reproducible results (particularly for wireless protocol design), scale to large networks, and study systems that have not yet been implemented. A particular emphasis in ns-3 is the high degree of realism in the models (including frameworks for real application and kernel code) and integration of the tool with virtual machine environments and testbeds; we view that researchers need to move more effortlessly between simulation, testbeds, and live experiments, and ns-3 is designed to facilitate that.

ns-3 has participated in past GSoCs during 2008-10, 2012-15, and 2017-20. We seek students interested in the intersection of wireless and computer networking, performance analysis, and open source software.

=== Org admins ===

Google Summer of Code organizational admins for ns-3 are [mailto:tpecorella@mac.com Tommaso Pecorella], [mailto:tahiliani.nitk@gmail.com Mohit Tahiliani] and [mailto:tomh@tomh.org Tom Henderson]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com Zulip].

=== Mentors ===

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 or Tommaso Pecorella of interest. Mentors familiar with ns-3 development practices will be preferred, to improve the chances of student code merge. In 2021, we are going to be seeking two-person or multiple-person mentoring teams for projects, to help with the mentoring workload and bring more expertise.

The current list of prospective mentors for 2021 is below:

* Tom Henderson
* Tommaso Pecorella
* Mohit P. Tahiliani
* Sebastien Deronne
* Hany Assasa
* Davide Magrin
* Vivek Jain
* Viyom Mittal
* Mishal Shah

=== Changes from last year ===

Google has changed the program, reducing it to half the paid time from previous summers. Therefore, we will be seeking to define projects with much reduced scope than in years past. In general, we seek projects that aim to improve the existing simulator rather than add new features.

=== Students: how to participate ===

For students interested in applying to ns-3 for GSOC, please go through the following list to get started:
* Read the official [http://en.flossmanuals.net/GSoCStudentGuide/ GSoC student guide].
* Read [[GSOC2021StudentGuide |ns-3's GSoC Student guide]]
* Look through our [[#Project Ideas]] below to see if you find a project that interests you.
* Review the [http://www.nsnam.org/ns-3-32/documentation ns-3 tutorial] thoroughly, if you have not already done so.
* Once it is posted, look through the [[GSOC2021StudentApplicationTemplate |GSoC Student application template]] to start preparing your proposal. We will wait to see whether we are actually part of GSoC before posting this.
* Next, proceed to get in touch with the developers on the mailing list or chat room and refine your proposal.
* In parallel, make sure you prepare a patch as per the patch requirement guidelines (to be posted at a later date). Your application to ns-3 will not be considered if you do not fulfill this requirement.

Below is a list of [[#Project Ideas]] proposed by the ns-3 team for Google Summer of Code 2021. 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.

<blockquote>
Each project idea within a particular priority has been tagged with the following properties:
* ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.
* ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.
* ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful students might apply their experiences coming out of this project.
* ''Difficulty:'' easy, medium or difficult
* ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.

Note that all of the projects require some experience and comfort with C++. Project ideas for which C++ is noted as a required experience will require more and deeper familiarity with the language. A similar notion applies to computer networking, BSD sockets, etc: Familiarity is strongly preferred, but is not required except where explicitly noted due to the topic being more advanced in that regard. A few projects are more Python-centric.
</blockquote>

=== Mentors: how to participate ===

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:

* The projects are sized such that there can be a code merge by the end of the coding period. The scope of the project should be such that it is very difficult to not have a code merge by the end of the summer.
* The proposed projects are not too open-ended. That is, if the deliverables or a clear path to the same are not well understood, it is better kept outside GSOC.
* There should be a clear merge path to one of the main project code repositories (ns-3-dev, ns-3-dce, bake) by the end of the summer, either because the patches directly apply to these repositories, or because they apply to an ns-3 module that is in the process of being merged with ns-3-dev.

== Project Ideas ==

'''Note to students:''' These ideas are not listed in any priority order.

==== Linux-like Loss Detection Techniques for ns-3 TCP ====

Mentors: [mailto:jain.vivek.anand@gmail.com Vivek Jain], [mailto:viyommittal@gmail.com Viyom Mittal], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

Forward Acknowledgement (FACK), Duplicate Selective Acknowledgement (DSACK), Tail Loss Probe (TLP) and Recent Acknowledgement (RACK) are the loss detection techniques implemented in the Linux kernel. These techniques have been already implemented for ns-3 TCP but their code is not yet merged into the mainline. This project has four main goals: (1) update the implementation of these techniques according to the latest ns-3-dev, (2) develop a framework to test the functionality of these techniques, (3) develop example program(s) to demonstrate the usage of these techniques in ns-3 and (4) merge these techniques in the mainline of ns-3.

* ''Required Experience:'' Familiarity with TCP and C++ programming.
* ''Bonus Experience:'' Familiarity with TCP implementation in Linux kernel.
* ''Interests:'' TCP packet loss detection techniques.
* ''Difficulty:'' Medium to Hard.
* ''Recommended Reading:''
** Forward Acknowledgement (FACK) [[https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.41.2559&rep=rep1&type=pdf Paper]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]
** Duplicate Selective Acknowledgment (DSACK) [[https://tools.ietf.org/html/rfc2883 RFC 2883]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]
** Tail Loss Probe (TLP) [[https://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01 Internet Draft]] [[https://gitlab.com/ShikhaBakshi/ns-3-dev/-/commits/TLP Implementation]]
** Recent Acknowledgment (RACK) [[https://tools.ietf.org/html/draft-ietf-tcpm-rack-15 Internet Draft]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]

==== Direct Code Execution upgrade ====

Mentor: [mailto:tomh@tomh.org Tom Henderson]

ns-3 has an extension known as Direct Code Execution, which allows users to build C or C++-based applications, and open source (Linux, FreeBSD) kernels, into ns-3. However, support for the latest kernels (e.g. Linux kernel 5 series) and latest glibc library versions has languished. We also could better integrate DCE with the main ns-3 tree. This project seeks a student interested in DCE, improving usability, and making it current with latest kernels and toolchains. The payoff of this type of project is very high since DCE makes available a lot of real-world models for use in ns-3. If you select this project idea, please engage with us on the developers list, and consider to take a look at solving one of the [https://www.nsnam.org/bugzilla/buglist.cgi?bug_status=__open__&content=&no_redirect=1&order=Importance&product=dce&query_format=specific open DCE issues in our tracker], for starters.
* ''Required Experience:'' good hacking skills on Linux, C, C++, Python
* ''Difficulty:'' Hard.
* ''For more information:'' https://www.nsnam.org/about/projects/direct-code-execution/, https://github.com/direct-code-execution/ns-3-dce

==== LoRaWAN ====

Mentor: [mailto:davide@magr.in Davide Magrin]

LoRaWAN is a communication technology for the Internet of Things, that allows battery-powered devices to wirelessly transmit data over long distances. Thanks to the lorawan module for ns-3, users can simulate networks where thousands of such devices communicate with a central server through multiple gateways. Packets might collide and be lost, devices might need to re-transmit them, and the central server can tell devices to change their transmission parameters according to suitable, exotic algorithms - we model it all.

This module rapidly grew in the last period, with the addition of various features and functionalities that are not completely tested nor documented, yet. In this project, you will mostly work to (1) integrate these features into the mainline code, and (2) improve the LoRaWAN module's testing and documentation.

Additionally, according to time availability and your interest, you can also help showcasing the potentialities of the lorawan module through the SEM library. Indeed, SEM can be used together with the lorawan module to provide users with meaningful examples, with the dual objective of giving a better understanding of what is going on within a single simulation, as well as how a simulation campaign can be easily conducted.

* ''Required Experience'': Familiarity with C++ programming.
* ''Bonus Experience'': Familiarity with Python programming.
* ''Interests'': Internet of Things communication protocols.
* ''Difficulty'': Medium to Hard.
* ''For more info'': https://github.com/signetlabdei/lorawan, http://github.com/signetlabdei/sem

==== SEM - Examples and documentation ====

Mentor: [mailto:davide@magr.in Davide Magrin]

The SEM Python library was designed to help ns-3 users run complex simulation campaigns. Among other things, SEM strives to make it as easy as possible to parse the output of simulations and to obtain plots that show the impact of simulation parameters on the network's performance.

One of the objectives for the next big SEM release is to provide users with more examples that are both easy to modify and that showcase the full potential of the library and of the Python data analysis ecosystem. In this project, your objective will be to show how SEM can be used from within Jupyter Notebooks to gradually explore the behavior of a network. Aside from the creation of new examples, you will also have the opportunity to try your hand at the all-important task of writing documentation. If there's time and you feel like tackling the issue, in a second part of the project you will also explore how SEM can be used to visualize the behavior of single simulations that leverage ns-3's built-in logging.

* ''Required Experience'': Familiarity with Python and C++ programming.
* ''Bonus Experience'': Familiarity with Jupyter Notebooks.
* ''Difficulty'': Medium.
* ''For more info'': http://github.com/signetlabdei/sem

==== Upgrade the AQM Evaluation Suite for ns-3 ====

Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], [mailto:jain.vivek.anand@gmail.com Vivek Jain], [mailto:shahmishal1998@gmail.com Mishal Shah]

AQM (Active Queue Management) evaluation suite for ns-3 helps to quickly study the performance of AQM algorithms based on the guidelines mentioned in RFC 7928. This suite automates simulation setup, topology creation, traffic generation, program execution, results collection and their graphical representation using ns-3 based on the scenarios mentioned in RFC 7928. It was designed and developed in 2017 and actively maintained till 2019. In the past two years, the traffic control model in ns-3 has grown significantly in terms of supporting state-of-the-art packet scheduling and AQM algorithms. This project has four main goals: (1) upgrade the AQM Evaluation Suite according to the latest ns-3-dev, (2) enable support for latest packet scheduling, AQM algorithms and ECN functionality (3) update the examples in AQM Evaluation Suite to better suit the needs of researchers working in this area, and (4) make AQM Evaluation Suite available on the ns-3 app store.

* ''Required Experience:'' Familiarity with AQM and C++ programming.
* ''Bonus Experience:'' Familiarity with traffic control model in ns-3.
* ''Interests:'' Packet Scheduling algorithms, AQM algorithms and ECN.
* ''Difficulty:'' Medium.
* ''Recommended Reading:''
** AQM Evaluation Suite [[https://dl.acm.org/doi/abs/10.1145/3067665.3067674 Paper]] [[https://aqm-eval-suite.github.io/ Implementation]]
** [https://tools.ietf.org/html/rfc7928 RFC 7928]
** [https://www.nsnam.org/docs/models/html/traffic-control-layer.html Traffic Control Model in ns-3]

==== Upgrade Python bindings framework ====

Mentors: [mailto:tomh@tomh.org Tom Henderson], others TBD

The project has provided Python bindings via a toolchain combining [https://github.com/gjcarneiro/pybindgen pybindgen], [https://github.com/CastXML/CastXML CastXML], and [https://github.com/CastXML/pygccxml pygccxml]. This is a compile-time solution, and some drawbacks have appeared as the C++ language has evolved but the bindings framework has not kept pace (leading to errors in scanning the APIs, or incomplete API coverage). A recent summary can be found [https://mailman.isi.edu/pipermail/ns-developers/2021-February/015396.html here]. This project would aim to prototype and evaluate whether a different framework could be used (such as [https://cppyy.readthedocs.io/en/latest/ cppyy] or [https://pybind11.readthedocs.io/en/stable/ pybind11]). In any case, work can also include fixing one or more bugs/limitations found in our issue tracker with the label 'python bindings'.

* ''Required Experience:'' Familiarity with C++ and Python/C. Solid Python coding skills.
* ''Interests:'' Python bindings
* ''Difficulty:'' Medium to Hard.

==== TCP maximum segment size (MSS) improvements ====

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], others TBD

TCP performances are affected by the maximum segment size (MSS) - a wrong choice might either lead to inefficient transmission (higher overhead) or IP fragmentation.

At the moment ns-3 implementation allows to set the MSS via an Attribute (set by default to 536 bytes by TcpSocket Attribute "SegmentSize").
Although it is stated that it "may be adjusted based on MTU discovery", its value is not changed in a simulation.

The goal of the project is to update the MSS handling, allowing to:
1) Set it to a fixed size, or allowing auto-probing of "optimal" MSS,
2) Use and honor the TcpOptionMSS (RFC 793), with a proper example of use, and
3) React to intermediate links with short MTU, and/or to changes in the Path MTU (PMTU).

The last point is to be carefully handled, as in many points in the code there is an implicit assumption that the MSS is constant in a given flow.

Moreover, note that finding the optimal PMTU is not that simple, as IPv6 and IPv4 react differently to packets exceeding the link MTU, and they won't notify if a packet is shorter than the link MTU.
As a consequence, it would be useful to implement the Packetization Layer Path MTU Discovery (RFC 4821) - which might exceed the GSoC timeframe.

Hence, it would be advisable to carefully select the features to be supported and tested in the project, eventually paving the ground for future enhancements.

* ''Required Experience:'' Familiarity with TCP, IPv4 and IPv6, and in particular with fragmentation.
* ''Difficulty:'' Medium / Hard
* ''Recommended reading:''
** [https://en.wikipedia.org/wiki/Path_MTU_Discovery Wikipedia: Path MTU Discovery]
** [https://www.nsnam.org/bugzilla/show_bug.cgi?id=2064 UdpSocket::GetMtu() needed]
** [https://www.nsnam.org/bugzilla/show_bug.cgi?id=1751 TCP should react to MTU changes]
** [https://tools.ietf.org/html/rfc1191 RFC 1191]
** [https://tools.ietf.org/html/rfc4821 RFC 4821]
** [https://tools.ietf.org/html/rfc1122#page-85 RFC 1122]
** [https://tools.ietf.org/html/rfc6691 RFC 6991]
** [https://tools.ietf.org/html/rfc2923 RFC 2923]
** [https://blog.apnic.net/2014/12/15/ip-mtu-and-tcp-mss-missmatch-an-evil-for-network-performance/ APNIC blog - IP MTU and TCP MSS Missmatch – an evil for network performance]
** [https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3650/software/release/16-9/configuration_guide/ip/b_169_ip_3650_cg/configuring_tcp_mss_adjustment.pdf Cisco - Configuring TCP MSS Adjustment]

==== Enable IPv6 support for Ad hoc Routing Protocols in ns-3 ====

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

ns-3 contains models for proactive (DSDV and OLSR) and reactive (AODV and DSR) ad hoc routing protocols. However, these models are IPv4-only and do not provide support of IPv6 addressing. This project aims to enable IPv6 support for ad hoc routing protocols in ns-3, mainly for AODV. There are out-of-tree implementations of OLSR and DSDV that provide support for IPv6 addressing, and can be used as references to get started with this project.

The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.

Note: Enabling IPv6 support for these protocols is not a matter of simply changing out an IPv4-formatted address for an IPv6-formatted address. The IPv6 addressing architecture emphasizes scoping much more than does IPv4 (RFC 4007). Please suggest in your application how IPv6 address configuration (and possibly auto-configuration?) and address scopes (e.g. link-local vs. global) should be used in these protocols. Consulting the RFCs is highly recommended.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3
* ''Interests:'' Ad hoc routing
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]
** [https://www.nsnam.org/workshops/wns3-2016/posters/IPv6-support-for-OLSR.pdf IPv6 Support for OLSR in ns-3]

==== IPv6 global routing ====

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], others TBD

Creating a complex topology can be a problem, and sometimes the user do not want to be (also) concerned about setting up dynamic routing protocols (e.g., RIP, RIPng).
For IPv4, ns-3 provides two alternatives: GlobalRouting, and NixRouting, which just "do the trick" - they simply fill the routing tables in intermediate nodes, GlobalRouting using an approach similar to OSPF, NixRouting by leveraging the "abstract" knowledge of the network.
Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.

The problem is that they don't work for IPv6, and that's a huge limitation. The goal of the project is to fix that limitation. Note that the project must cope with different IPv6 address kinds (link-local, global, scoped multicast, etc.). Due to the limitation with GlobalRouting w.r.t. wireless channels, it would be advisable to start working with NixRouting.

The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with NixRouting and GlobalRouting implementations in ns-3
* ''Interests:'' IPv6 routing
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/docs/models/html/nix-vector-routing.html NixRouting model in ns-3]
** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]

==== Integration of MIPv6 module into ns-3 with LTE-WiFi Handoff support ====

Mentors: [mailto:manoj24.rana@gmail.com Manoj Kumar Rana]

The MIPv6 module had already been implemented in ns-3 (The links of their implementations are given below). But, these modules are still lacking in ns-3 main tree. One of the medium access control (MAC) layer issue was NetDevice up/down consistency which has been resolved through the GSoC 2020 project titled, “NetDevice up/down consistency and event chain”. The MIPv6 integration still requires understanding the behaviour of IPv6 and ICMPv6 protocols running in LTE module (mainly between PGW/SGW and eNB). Although IPv6 packets are now transferred over LTE network, the sole purpose of MIPv6 handoff i.e. switching mobile node between LTE and WiFi can only be accomplished by modifying the existing MIPv6 module and extending the existing LTE module.

* ''Required Experience:'' C++, LTE IPv6 support.
* ''Bonus Experience:'' Familiarity with MIPv6/PMIPv6 module implementations in ns-3
* ''Interests:'' IPv6
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/wiki/GSOC2017MobileIp MIPv6 model in ns-3]

[[Category:GSoC]]

GSOC2021Projects

2021-03-03T18:37:50Z

Mkrana: /* Project Ideas */

{{TOC}}

This page contains 2021 Google Summer of Code project ideas for ns-3. Students interested in participating in ns-3's GSoC program are free to get started on an idea or two, with the understanding that ns-3 has not yet been selected for GSoC and may not ultimately be selected.

* [http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2015/help_page GSoC Frequently Asked Questions]
* [[GSOC2021StudentGuide |ns-3's 2021 GSoC Student guide]]
* [http://en.flossmanuals.net/GSoCStudentGuide/ GSoC student guide (not ns-3 specific)]
* [[GSOC2020StudentApplicationTemplate |2020 GSoC Student application template]]
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]
* [http://en.flossmanuals.net/gsoc-mentoring/ GSoC Mentor guide (not ns-3 specific)]
* [[GSOCSelectionProcess | GSoC Student Selection Process]]
* ''Get in contact with the ns-3 team'': [http://mailman.isi.edu/mailman/listinfo/ns-developers ns-developers mailing list] | ''chat'' https://ns-3.zulipchat.com/

=== About the ns-3 project ===

ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.

Users of ns-3 can construct simulations of computer networks using models of traffic generators, protocols such as TCP/IP, and devices and channels such as WiFi, and analyze or visualize the results. Simulation plays a vital role in the research and education process, because of the ability for simulations to obtain reproducible results (particularly for wireless protocol design), scale to large networks, and study systems that have not yet been implemented. A particular emphasis in ns-3 is the high degree of realism in the models (including frameworks for real application and kernel code) and integration of the tool with virtual machine environments and testbeds; we view that researchers need to move more effortlessly between simulation, testbeds, and live experiments, and ns-3 is designed to facilitate that.

ns-3 has participated in past GSoCs during 2008-10, 2012-15, and 2017-20. We seek students interested in the intersection of wireless and computer networking, performance analysis, and open source software.

=== Org admins ===

Google Summer of Code organizational admins for ns-3 are [mailto:tpecorella@mac.com Tommaso Pecorella], [mailto:tahiliani.nitk@gmail.com Mohit Tahiliani] and [mailto:tomh@tomh.org Tom Henderson]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com Zulip].

=== Mentors ===

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 or Tommaso Pecorella of interest. Mentors familiar with ns-3 development practices will be preferred, to improve the chances of student code merge. In 2021, we are going to be seeking two-person or multiple-person mentoring teams for projects, to help with the mentoring workload and bring more expertise.

The current list of prospective mentors for 2021 is below:

* Tom Henderson
* Tommaso Pecorella
* Mohit P. Tahiliani
* Sebastien Deronne
* Hany Assasa
* Davide Magrin
* Vivek Jain
* Viyom Mittal
* Mishal Shah

=== Changes from last year ===

Google has changed the program, reducing it to half the paid time from previous summers. Therefore, we will be seeking to define projects with much reduced scope than in years past. In general, we seek projects that aim to improve the existing simulator rather than add new features.

=== Students: how to participate ===

For students interested in applying to ns-3 for GSOC, please go through the following list to get started:
* Read the official [http://en.flossmanuals.net/GSoCStudentGuide/ GSoC student guide].
* Read [[GSOC2021StudentGuide |ns-3's GSoC Student guide]]
* Look through our [[#Project Ideas]] below to see if you find a project that interests you.
* Review the [http://www.nsnam.org/ns-3-32/documentation ns-3 tutorial] thoroughly, if you have not already done so.
* Once it is posted, look through the [[GSOC2021StudentApplicationTemplate |GSoC Student application template]] to start preparing your proposal. We will wait to see whether we are actually part of GSoC before posting this.
* Next, proceed to get in touch with the developers on the mailing list or chat room and refine your proposal.
* In parallel, make sure you prepare a patch as per the patch requirement guidelines (to be posted at a later date). Your application to ns-3 will not be considered if you do not fulfill this requirement.

Below is a list of [[#Project Ideas]] proposed by the ns-3 team for Google Summer of Code 2021. 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.

<blockquote>
Each project idea within a particular priority has been tagged with the following properties:
* ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.
* ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.
* ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful students might apply their experiences coming out of this project.
* ''Difficulty:'' easy, medium or difficult
* ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.

Note that all of the projects require some experience and comfort with C++. Project ideas for which C++ is noted as a required experience will require more and deeper familiarity with the language. A similar notion applies to computer networking, BSD sockets, etc: Familiarity is strongly preferred, but is not required except where explicitly noted due to the topic being more advanced in that regard. A few projects are more Python-centric.
</blockquote>

=== Mentors: how to participate ===

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:

* The projects are sized such that there can be a code merge by the end of the coding period. The scope of the project should be such that it is very difficult to not have a code merge by the end of the summer.
* The proposed projects are not too open-ended. That is, if the deliverables or a clear path to the same are not well understood, it is better kept outside GSOC.
* There should be a clear merge path to one of the main project code repositories (ns-3-dev, ns-3-dce, bake) by the end of the summer, either because the patches directly apply to these repositories, or because they apply to an ns-3 module that is in the process of being merged with ns-3-dev.

== Project Ideas ==

'''Note to students:''' These ideas are not listed in any priority order.

==== Linux-like Loss Detection Techniques for ns-3 TCP ====

Mentors: [mailto:jain.vivek.anand@gmail.com Vivek Jain], [mailto:viyommittal@gmail.com Viyom Mittal], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

Forward Acknowledgement (FACK), Duplicate Selective Acknowledgement (DSACK), Tail Loss Probe (TLP) and Recent Acknowledgement (RACK) are the loss detection techniques implemented in the Linux kernel. These techniques have been already implemented for ns-3 TCP but their code is not yet merged into the mainline. This project has four main goals: (1) update the implementation of these techniques according to the latest ns-3-dev, (2) develop a framework to test the functionality of these techniques, (3) develop example program(s) to demonstrate the usage of these techniques in ns-3 and (4) merge these techniques in the mainline of ns-3.

* ''Required Experience:'' Familiarity with TCP and C++ programming.
* ''Bonus Experience:'' Familiarity with TCP implementation in Linux kernel.
* ''Interests:'' TCP packet loss detection techniques.
* ''Difficulty:'' Medium to Hard.
* ''Recommended Reading:''
** Forward Acknowledgement (FACK) [[https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.41.2559&rep=rep1&type=pdf Paper]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]
** Duplicate Selective Acknowledgment (DSACK) [[https://tools.ietf.org/html/rfc2883 RFC 2883]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]
** Tail Loss Probe (TLP) [[https://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01 Internet Draft]] [[https://gitlab.com/ShikhaBakshi/ns-3-dev/-/commits/TLP Implementation]]
** Recent Acknowledgment (RACK) [[https://tools.ietf.org/html/draft-ietf-tcpm-rack-15 Internet Draft]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]

==== Direct Code Execution upgrade ====

Mentor: [mailto:tomh@tomh.org Tom Henderson]

ns-3 has an extension known as Direct Code Execution, which allows users to build C or C++-based applications, and open source (Linux, FreeBSD) kernels, into ns-3. However, support for the latest kernels (e.g. Linux kernel 5 series) and latest glibc library versions has languished. We also could better integrate DCE with the main ns-3 tree. This project seeks a student interested in DCE, improving usability, and making it current with latest kernels and toolchains. The payoff of this type of project is very high since DCE makes available a lot of real-world models for use in ns-3. If you select this project idea, please engage with us on the developers list, and consider to take a look at solving one of the [https://www.nsnam.org/bugzilla/buglist.cgi?bug_status=__open__&content=&no_redirect=1&order=Importance&product=dce&query_format=specific open DCE issues in our tracker], for starters.
* ''Required Experience:'' good hacking skills on Linux, C, C++, Python
* ''Difficulty:'' Hard.
* ''For more information:'' https://www.nsnam.org/about/projects/direct-code-execution/, https://github.com/direct-code-execution/ns-3-dce

==== LoRaWAN ====

Mentor: [mailto:davide@magr.in Davide Magrin]

LoRaWAN is a communication technology for the Internet of Things, that allows battery-powered devices to wirelessly transmit data over long distances. Thanks to the lorawan module for ns-3, users can simulate networks where thousands of such devices communicate with a central server through multiple gateways. Packets might collide and be lost, devices might need to re-transmit them, and the central server can tell devices to change their transmission parameters according to suitable, exotic algorithms - we model it all.

This module rapidly grew in the last period, with the addition of various features and functionalities that are not completely tested nor documented, yet. In this project, you will mostly work to (1) integrate these features into the mainline code, and (2) improve the LoRaWAN module's testing and documentation.

Additionally, according to time availability and your interest, you can also help showcasing the potentialities of the lorawan module through the SEM library. Indeed, SEM can be used together with the lorawan module to provide users with meaningful examples, with the dual objective of giving a better understanding of what is going on within a single simulation, as well as how a simulation campaign can be easily conducted.

* ''Required Experience'': Familiarity with C++ programming.
* ''Bonus Experience'': Familiarity with Python programming.
* ''Interests'': Internet of Things communication protocols.
* ''Difficulty'': Medium to Hard.
* ''For more info'': https://github.com/signetlabdei/lorawan, http://github.com/signetlabdei/sem

==== SEM - Examples and documentation ====

Mentor: [mailto:davide@magr.in Davide Magrin]

The SEM Python library was designed to help ns-3 users run complex simulation campaigns. Among other things, SEM strives to make it as easy as possible to parse the output of simulations and to obtain plots that show the impact of simulation parameters on the network's performance.

One of the objectives for the next big SEM release is to provide users with more examples that are both easy to modify and that showcase the full potential of the library and of the Python data analysis ecosystem. In this project, your objective will be to show how SEM can be used from within Jupyter Notebooks to gradually explore the behavior of a network. Aside from the creation of new examples, you will also have the opportunity to try your hand at the all-important task of writing documentation. If there's time and you feel like tackling the issue, in a second part of the project you will also explore how SEM can be used to visualize the behavior of single simulations that leverage ns-3's built-in logging.

* ''Required Experience'': Familiarity with Python and C++ programming.
* ''Bonus Experience'': Familiarity with Jupyter Notebooks.
* ''Difficulty'': Medium.
* ''For more info'': http://github.com/signetlabdei/sem

==== Upgrade the AQM Evaluation Suite for ns-3 ====

Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], [mailto:jain.vivek.anand@gmail.com Vivek Jain], [mailto:shahmishal1998@gmail.com Mishal Shah]

AQM (Active Queue Management) evaluation suite for ns-3 helps to quickly study the performance of AQM algorithms based on the guidelines mentioned in RFC 7928. This suite automates simulation setup, topology creation, traffic generation, program execution, results collection and their graphical representation using ns-3 based on the scenarios mentioned in RFC 7928. It was designed and developed in 2017 and actively maintained till 2019. In the past two years, the traffic control model in ns-3 has grown significantly in terms of supporting state-of-the-art packet scheduling and AQM algorithms. This project has four main goals: (1) upgrade the AQM Evaluation Suite according to the latest ns-3-dev, (2) enable support for latest packet scheduling, AQM algorithms and ECN functionality (3) update the examples in AQM Evaluation Suite to better suit the needs of researchers working in this area, and (4) make AQM Evaluation Suite available on the ns-3 app store.

* ''Required Experience:'' Familiarity with AQM and C++ programming.
* ''Bonus Experience:'' Familiarity with traffic control model in ns-3.
* ''Interests:'' Packet Scheduling algorithms, AQM algorithms and ECN.
* ''Difficulty:'' Medium.
* ''Recommended Reading:''
** AQM Evaluation Suite [[https://dl.acm.org/doi/abs/10.1145/3067665.3067674 Paper]] [[https://aqm-eval-suite.github.io/ Implementation]]
** [https://tools.ietf.org/html/rfc7928 RFC 7928]
** [https://www.nsnam.org/docs/models/html/traffic-control-layer.html Traffic Control Model in ns-3]

==== Upgrade Python bindings framework ====

Mentors: [mailto:tomh@tomh.org Tom Henderson], others TBD

The project has provided Python bindings via a toolchain combining [https://github.com/gjcarneiro/pybindgen pybindgen], [https://github.com/CastXML/CastXML CastXML], and [https://github.com/CastXML/pygccxml pygccxml]. This is a compile-time solution, and some drawbacks have appeared as the C++ language has evolved but the bindings framework has not kept pace (leading to errors in scanning the APIs, or incomplete API coverage). A recent summary can be found [https://mailman.isi.edu/pipermail/ns-developers/2021-February/015396.html here]. This project would aim to prototype and evaluate whether a different framework could be used (such as [https://cppyy.readthedocs.io/en/latest/ cppyy] or [https://pybind11.readthedocs.io/en/stable/ pybind11]). In any case, work can also include fixing one or more bugs/limitations found in our issue tracker with the label 'python bindings'.

* ''Required Experience:'' Familiarity with C++ and Python/C. Solid Python coding skills.
* ''Interests:'' Python bindings
* ''Difficulty:'' Medium to Hard.

==== TCP maximum segment size (MSS) improvements ====

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], others TBD

TCP performances are affected by the maximum segment size (MSS) - a wrong choice might either lead to inefficient transmission (higher overhead) or IP fragmentation.

At the moment ns-3 implementation allows to set the MSS via an Attribute (set by default to 536 bytes by TcpSocket Attribute "SegmentSize").
Although it is stated that it "may be adjusted based on MTU discovery", its value is not changed in a simulation.

The goal of the project is to update the MSS handling, allowing to:
1) Set it to a fixed size, or allowing auto-probing of "optimal" MSS,
2) Use and honor the TcpOptionMSS (RFC 793), with a proper example of use, and
3) React to intermediate links with short MTU, and/or to changes in the Path MTU (PMTU).

The last point is to be carefully handled, as in many points in the code there is an implicit assumption that the MSS is constant in a given flow.

Moreover, note that finding the optimal PMTU is not that simple, as IPv6 and IPv4 react differently to packets exceeding the link MTU, and they won't notify if a packet is shorter than the link MTU.
As a consequence, it would be useful to implement the Packetization Layer Path MTU Discovery (RFC 4821) - which might exceed the GSoC timeframe.

Hence, it would be advisable to carefully select the features to be supported and tested in the project, eventually paving the ground for future enhancements.

* ''Required Experience:'' Familiarity with TCP, IPv4 and IPv6, and in particular with fragmentation.
* ''Difficulty:'' Medium / Hard
* ''Recommended reading:''
** [https://en.wikipedia.org/wiki/Path_MTU_Discovery Wikipedia: Path MTU Discovery]
** [https://www.nsnam.org/bugzilla/show_bug.cgi?id=2064 UdpSocket::GetMtu() needed]
** [https://www.nsnam.org/bugzilla/show_bug.cgi?id=1751 TCP should react to MTU changes]
** [https://tools.ietf.org/html/rfc1191 RFC 1191]
** [https://tools.ietf.org/html/rfc4821 RFC 4821]
** [https://tools.ietf.org/html/rfc1122#page-85 RFC 1122]
** [https://tools.ietf.org/html/rfc6691 RFC 6991]
** [https://tools.ietf.org/html/rfc2923 RFC 2923]
** [https://blog.apnic.net/2014/12/15/ip-mtu-and-tcp-mss-missmatch-an-evil-for-network-performance/ APNIC blog - IP MTU and TCP MSS Missmatch – an evil for network performance]
** [https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3650/software/release/16-9/configuration_guide/ip/b_169_ip_3650_cg/configuring_tcp_mss_adjustment.pdf Cisco - Configuring TCP MSS Adjustment]

==== Enable IPv6 support for Ad hoc Routing Protocols in ns-3 ====

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

ns-3 contains models for proactive (DSDV and OLSR) and reactive (AODV and DSR) ad hoc routing protocols. However, these models are IPv4-only and do not provide support of IPv6 addressing. This project aims to enable IPv6 support for ad hoc routing protocols in ns-3, mainly for AODV. There are out-of-tree implementations of OLSR and DSDV that provide support for IPv6 addressing, and can be used as references to get started with this project.

The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.

Note: Enabling IPv6 support for these protocols is not a matter of simply changing out an IPv4-formatted address for an IPv6-formatted address. The IPv6 addressing architecture emphasizes scoping much more than does IPv4 (RFC 4007). Please suggest in your application how IPv6 address configuration (and possibly auto-configuration?) and address scopes (e.g. link-local vs. global) should be used in these protocols. Consulting the RFCs is highly recommended.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3
* ''Interests:'' Ad hoc routing
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]
** [https://www.nsnam.org/workshops/wns3-2016/posters/IPv6-support-for-OLSR.pdf IPv6 Support for OLSR in ns-3]

==== IPv6 global routing ====

Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], others TBD

Creating a complex topology can be a problem, and sometimes the user do not want to be (also) concerned about setting up dynamic routing protocols (e.g., RIP, RIPng).
For IPv4, ns-3 provides two alternatives: GlobalRouting, and NixRouting, which just "do the trick" - they simply fill the routing tables in intermediate nodes, GlobalRouting using an approach similar to OSPF, NixRouting by leveraging the "abstract" knowledge of the network.
Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.

The problem is that they don't work for IPv6, and that's a huge limitation. The goal of the project is to fix that limitation. Note that the project must cope with different IPv6 address kinds (link-local, global, scoped multicast, etc.). Due to the limitation with GlobalRouting w.r.t. wireless channels, it would be advisable to start working with NixRouting.

The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.

* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
* ''Bonus Experience:'' Familiarity with NixRouting and GlobalRouting implementations in ns-3
* ''Interests:'' IPv6 routing
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/docs/models/html/nix-vector-routing.html NixRouting model in ns-3]
** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]

==== Integration of MIPv6 module into ns-3 with LTE-WiFi Handoff support ====

Mentors: [manoj24.rana@gmail.com Manoj Kumar Rana]

The MIPv6 module had already been implemented in ns-3 (The links of their implementations are given below). But, these modules are still lacking in ns-3 main tree. One of the medium access control (MAC) layer issue was NetDevice up/down consistency which has been resolved through the GSoC 2020 project titled, “NetDevice up/down consistency and event chain”. The MIPv6 integration still requires understanding the behaviour of IPv6 and ICMPv6 protocols running in LTE module (mainly between PGW/SGW and eNB). Although IPv6 packets are now transferred over LTE network, the sole purpose of MIPv6 handoff i.e. switching mobile node between LTE and WiFi can only be accomplished by modifying the existing MIPv6 module and extending the existing LTE module.

* ''Required Experience:'' C++, LTE IPv6 support.
* ''Bonus Experience:'' Familiarity with MIPv6/PMIPv6 module implementations in ns-3
* ''Interests:'' IPv6
* ''Difficulty:'' Medium.
* ''Recommended reading:''
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
** [https://www.nsnam.org/wiki/GSOC2017MobileIp MIPv6 model in ns-3]

[[Category:GSoC]]

GSOC2017MobileIp

2017-08-29T07:52:33Z

Mkrana: /* Documentation */

{{TOC}}

Return to [[GSOC2017AcceptedProjects | GSoC 2017 Accepted Projects]] page.

= Project overview =

* '''Project name:''' Mobile IPv6 Implementation with LTE support

* '''Student:''' [mailto:manoj24.rana@gmail.com Manoj Kumar Rana]

* '''Mentor:''' [mailto:tommypec@gmail.com Tommaso Pecorella]

* '''Abstract:''' The goal of the project is to implement a novel MIPv6 simulation model which can be integrated into ns-3. The project idea aims at testing the code in different network scenarios, containing different link layer technologies such as Wi-Fi, WiMAX and LTE. The current implementation of LTE does not have support of IPv6 in ns-3. So, the idea of testing MIPv6 code into LTE would follow IPv6 support implementation in LTE first and then the MIPv6 support. Thus, implementation of MIPv6 in ns-3 as the base mobility management solution and providing LTE support within it could help the current network researchers working on ns-3.

* '''Code:''' https://github.com/manoj24rana/MobileIPv6

* '''Documentation:'''
# Detail Description about the Implementation: http://www.sciencedirect.com/science/article/pii/S1569190X16302714
# Phase1 Documentation: https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing
# Phase2 Documentation: https://drive.google.com/open?id=0BziHE2fNAdZRbUZKN01Bd1Rjdk0

* '''About me:''' I am a PhD student in the School of Mobile Computing and Communications, Jadavpur University, India. About my research is given here: http://scholar.google.com/citations?user=qouvajAAAAAJ&hl=en.

= Technical Approach =
*'''First,''' I want to restructure the MIPv6 code, published in http://www.sciencedirect.com/science/article/pii/S1569190X16302714, to make it RFC 6275 compliance. To do the restructuring complete, the following approaches will be performed:
#Code refactoring: reorganizing internetstack, helper and header components of the MIPv6 module through modifying the internal functions, attributes and the callback variables.
#Code analysis: both static and dynamic analysis could be performed. The waf tool for code run, PyViz for visualization and tcpdump for pcap tracing could be used.
#Functional tests: The functional test would be performed in three phase: handoff performance testing, data packet transmission testing and both. Use cases like multiple mobile nodes, multiple correspondent node, different mobility model for the mobile node as well as heterogeneous link layer technologies (Wi-Fi and WiMAX) could be used.
#The code will be sent for the code review to the ns-3 team.
* '''Second,''' IPV6 support for LTE would be ensured as LTE currently, only supports IPv4. The changes would possibly be done within the LTE module files (both .cc and .h) like point-topoint-helper, emu-epc-helper, lte-ue-net-device, epc-sgw-pgw-application, epc-enb-application, lte-enb-net-device etc. Then, the code analysis will be performed as done previously for MIPv6 code. The functional tests would follow bidirectional IPv6 packet transmission between remote host and the UE. The modification/rewriting code will create a patch that could enable IPv6 forwarding in the LTE data plane, enabling the UE to receive and use a /64 prefix, as stated in the standard. It is worth noticing that IP packets are tunnelled in the `core' network (i.e., all the EPC part), and their actual IP address is not used for UE identification in the core. As a consequence, IPv6 use in the `core' network, using ULAs or link-local addresses, could be planned if the previous development is faster than foreseen. This modification could also be simpler than expected, as it is not important to keep a dual stack communication in the core network, and using only IPv6 brings some direct benefits (like simplifying the use of multiple EPCs in a single script).
* '''Third,''' To ensure the code quality, the following testing approach could be used: Test MIPv6 handoff performance with the mixed link layer technologies (combination of Wi-Fi, WiMAX and LTE) case, multiple mobile node case, and multiple correspondent node case.

= Deliverables and Plan =
=== Deliverables: ===

-a basic MIPv6 module, aligned with RFC 6275 following ns-3 coding styles;

-a reviewed patch, fixing the IPv6 support issue in LTE;

-proper documentation and tests for the above-mentioned components.

=== Plan: ===

==== May 4 – May 29 (Before the official coding time): ====

-Familiarize myself completely with MIPv6, LTE (the IPv4 part), and the respective interactions.

-Study of the customized files of ns-3 lte and internet modules

-Familiarize myself with the ns-3 coding styles

During this period I will remain in constant touch with my mentor and the ns-3 community. I will remain active on IRC and Mailing lists to discuss and finalize on the modifications (if any) that needs to be on existing models and design of new module (if needed to fit cleanly with ns-3)

Thus with the help of my mentor I will become absolutely clear about my future goals, the final MIPv6 implementation that need to be done as well as the approach that I will follow to support IPv6 in lte model.

==== May 30 – June 26 (Official coding period starts): ====

-Refactor previous MIPv6 headers to RFC compliance header files

-Refactor all the classes to implement the corresponding header file functions

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the newly implemented MIPv6 module in various testing scenarios. The testing will be done with the systems having Wi-Fi and WiMAX link layer technology

-Sending the code for code review to the ns-3 team

After this stage, the standard ns-3 code revision can be started for the MIPv6 code part. Any change requested by the reviewers will be carried out in parallel with the following activities.

==== June 27 – July 24: ====

-Define new or, modify existing header files and cc files in LTE module in such a way that LTE module remains backward compatible with IPv4

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the LTE module

-Sending the code for code review to the ns-3 team

This will help in testing of the LTE module with IPv6 support for possible merge into the project main tree.

==== July 25 – August 21: ====

-Making further changes in the LTE module to support MIPv6 into it. Changes may be required in the other modules of ns-3 also.

-Testing the overall working in the testing scenarios having the combination of Wi-Fi and LTE

-Most of the time will be consumed for rigorous testing and bug fixes.

-Sending the code for code review to the ns-3 team

-Documentation updates.

= Weekly Reports =

=== May 30 - June 6 ===

1. Restructuring the MIPv6 code.

2. Testing the code in the multiple Mobile Node case

3. Changing the Home Agent functionality a little bit

4. Arise Tunnel Implementation Issue [how mobile node would use its home address for all of its data communication]

=== June 7 - June 13 ===

1. Resolved the issue of home address assignment to mobile node for all of its data communication. So, I have made some tricky callbacks in the L4 protocol a little bit. Now, traffic can be directed in both direction i.e. Mobile node to a web server and a web server to a mobile node

2. Also delete a lot of unnecessary files as well as lines in the code.

3. Tests have been done changing the location of different mobility entities. Almost all are successful. Those are included in "mipv6-test1-4.cc" in scratch of https://github.com/manoj24rana/MobileIPv6.

=== June 14 - June 20 ===

1. Done more tests

2. Add some more features such as defending home address and performing NS handling at HA as described in RFC 6275

3. Find an issue on RFC 6275 i.e. how to defend the mobile node's home address by home agent when it returns to its home network. Try to do something on the basis of ns-3 ipv6 implementation to resolve the issue.

=== June 21 - June 27 ===

1. Documentation on how my implementation differs from RFC 6275 as well as

2. Resolve the above issue

3. Sending the code for review.

=== June 28 - July 04 ===

1. Starting LTE IPv6 implementation part: understanding the end-to-end IPv4 part between UE and remote host, decoding it and discuss with my mentor for changing

2. Start writing code, at least one class modification

3. Test the change whether it is right.

=== July 05 - July 11 ===

1. Complete the modification in the lte module classes and also develop a small IPv6 dealing program to test

2. An issue arise i.e. Address Collision occurs at file: file=../src/internet/model/
ipv6-address-generator.cc, line=484". I am trying to resolve it.

3. Runs the previous IPv4 sample programs, which runs fine.

=== July 12 - July 18 ===

1. Resolve the IPv6 address collision issue in the LTE IPv6 support part.

2. I face another issue on handling multicast packets between UE sets and pgw i.e. those multicast packets are not passed between them as in the middle there is an enb.

3. Add the Sphinx documentation in the mipv6 module.

4. The Attributes and TraceSources are uploaded in mipv6 git.

=== July 19 - July 25 ===

1. Making some examples for the main mipv6 repo.

2. Add two tests in the main mipv6 repo.

3. mipv6 doc file further update.

4. Add and change tracesources and some functionalities in mipv6 model.

=== July 26 - August 1 ===

Finalize the MIPv6 code for review. I have added two nice tests replacing the previous tests, further update the mipv6 doc, trace sources, attributes, examples.
The codes are documented highly. Now the /doc/models/build/html dir contains the model documentation and the /doc/html creates doxygen for the mipv6 module.

=== August 2 - August 15 ===

1. Sent the MIPv6 code for review.

2. Solved LTE IPv6 packet sending issues.

3. Complete LTE IPv6 part, i.e. IPv6 packets are received and sent correctly.

4. Discuss with my mentor (Tommaso) elaborately about the next steps such that this implementation could be rebased in the main ns-3 dev quickly.

=== August 16 - August 22 ===

1. Update the LTE UE and PGW address assignment process in such a way that all IP addresses assigned by an EPC are derived from a base prefix (8 for IPv4 and 32 for IPv6) and each EPC holds a unique 16 bit IPv4 and 48 bit IPv6 subnet prefix to assign addresses to PGW and UEs. This address assignment process is made by keeping in mind the issues stated in https://www.nsnam.org/bugzilla/show_bug.cgi?id=1745 and https://groups.google.com/forum/#!topic/ns-3-users/Tc3IKky1OKo. So, now address duplication would not happen in case of more than one EPC as well as any time we could assign addresses without initializing the address helper. Also, user is given the flexibility to reassign the base 8 or, 32 bit address prefix at any time.

2. The LTE module is updated by IPv6 tests, documentation and examples. So, now the sample program is running and users can use them.

=== August 23 - August 29 ===

1. Submit the Google Work Product.

2. Send the LTE Code for review.

3. Try to resolve the reviewer's comment.

= Final Report for Google =
It has been an outstanding experience for me, spending this summer for GSoC project. I gave my full effort to make a very successful GSoC project and so, involved myself almost entirely. The huge interest from the current ns-3 users about my project speeds up the work process, which I have enjoyed most. I have learned a lot of things during this summer. Working for a community like ns-3 polishes my coding networking and communication skills a lot.

This final report contains all the links to all the works done over the summer. There have been almost 11,000 lines with 126 commits contributed in my github repo this summer.

=== Work Product Link ===

This is the complete work product link with full ns-3.25 software:

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6

My contribution:

As I have extended one of my project work (Mobile IPv6) in GSoC, I have divided my contribution into two parts:

The full contribution for this project is in the following link.

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/commit/7164250819b85ec2461e4c20667a516720eeddd5

Contribution during GSoC time period is in the following link (the last 126 commits by me).

https://github.com/manoj24rana/MobileIPv6

=== Installation and Running the Work Product ===

1. Depending on your OS, install the ns-3 Prerequisites from this link: https://www.nsnam.org/wiki/Installation#Prerequisites.

2. Download the code from this repository: https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6 (It is full) or, https://github.com/manoj24rana/MobileIPv6 (It requires other ns-3 components to be installed separately to add some extra features e.g. Visualizer) and extract it.

3. Make sure that you have installed all the perquisites to install ns-3.25.

4. Run the following commands in your cmd prompt to install it:

$ cd The_Project_Folder

$ cd ns-3.25

$ ./waf -d debug --enable-examples --enable-tests configure

$ ./waf

5. Running MIPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running MIPv6: mipv6-multiple.cc, mipv6-single.cc and mipv6-wifi-wimax.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run mipv6-multiple --vis

This will open a visualizer to see the output and the packet transmission in the background cmd prompt.

6. Running LTE IPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running LTE IPv6: lena-ipv6-ue-rh.cc, lena-ipv6-ue-ue.cc and lena-ipv6-addr-conf.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run lena-ipv6-ue-ue --vis

This will open a visualizer to see the output and the packet transmission in the background cmd prompt.

Note: If you have not downloaded from the first link, do not use --vis option at the time of running samples.

=== Documentation ===

Either, you follow the prepared documentation,

For MIPv6,

https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing
or, https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/blob/master/ns-3.25/src/mipv6/doc/mipv6.rst

For LTE IPv6,

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/blob/master/ns-3.25/src/lte/doc/source/lte-design.rst and
and https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/blob/master/ns-3.25/src/lte/doc/source/lte-user.rst

or, you could follow the manual for Creating Documentation here: https://www.nsnam.org/docs/manual/html/documentation.html. I have added the appropriate documentations within the code of the above repo of my implementation.

=== Work Flow ===

The following link will describe the weekly update of this project.

https://www.nsnam.org/wiki/GSOC2017MobileIp#Weekly_Reports

The flow of commits in the code could be found in the following link.

https://github.com/manoj24rana/MobileIPv6

=== Other Issues Resolved ===

I have resolved several other issues in ns-3 during this period as a part of my main implementation. Briefly, these are as follows.

1. Lack of IPv6 support for WiMAX module.

2. Duplicate IPv4 address collision problem in LTE module (https://groups.google.com/forum/#!topic/ns-3-users/Tc3IKky1OKo).

=== Future Enhancement for this Project ===

1. Creating some LTE samples which can run multiple LTE networks in single user's simulation script. It requires cooperation with the existing LTE maintainers in ns-3.

2. Add more options for mobility management. The actual code always switches to the "newest" network. More sophisticated approaches can be tested, like QoS measures and make-before-break.

3. Above all, the beauty of this project is that it is the implementation of the base IP mobility management protocol (MIPv6) in ns-3. The ns-3 users now can easily extend this feature to implement other such protocols, such as NEMO (RFC 3963), PMIPv6 (RFC 5213) etc. and also some upcoming schemes in 5G.

GSOC2017MobileIp

2017-08-29T07:45:35Z

Mkrana: /* Installation and Running the Work Product */

{{TOC}}

Return to [[GSOC2017AcceptedProjects | GSoC 2017 Accepted Projects]] page.

= Project overview =

* '''Project name:''' Mobile IPv6 Implementation with LTE support

* '''Student:''' [mailto:manoj24.rana@gmail.com Manoj Kumar Rana]

* '''Mentor:''' [mailto:tommypec@gmail.com Tommaso Pecorella]

* '''Abstract:''' The goal of the project is to implement a novel MIPv6 simulation model which can be integrated into ns-3. The project idea aims at testing the code in different network scenarios, containing different link layer technologies such as Wi-Fi, WiMAX and LTE. The current implementation of LTE does not have support of IPv6 in ns-3. So, the idea of testing MIPv6 code into LTE would follow IPv6 support implementation in LTE first and then the MIPv6 support. Thus, implementation of MIPv6 in ns-3 as the base mobility management solution and providing LTE support within it could help the current network researchers working on ns-3.

* '''Code:''' https://github.com/manoj24rana/MobileIPv6

* '''Documentation:'''
# Detail Description about the Implementation: http://www.sciencedirect.com/science/article/pii/S1569190X16302714
# Phase1 Documentation: https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing
# Phase2 Documentation: https://drive.google.com/open?id=0BziHE2fNAdZRbUZKN01Bd1Rjdk0

* '''About me:''' I am a PhD student in the School of Mobile Computing and Communications, Jadavpur University, India. About my research is given here: http://scholar.google.com/citations?user=qouvajAAAAAJ&hl=en.

= Technical Approach =
*'''First,''' I want to restructure the MIPv6 code, published in http://www.sciencedirect.com/science/article/pii/S1569190X16302714, to make it RFC 6275 compliance. To do the restructuring complete, the following approaches will be performed:
#Code refactoring: reorganizing internetstack, helper and header components of the MIPv6 module through modifying the internal functions, attributes and the callback variables.
#Code analysis: both static and dynamic analysis could be performed. The waf tool for code run, PyViz for visualization and tcpdump for pcap tracing could be used.
#Functional tests: The functional test would be performed in three phase: handoff performance testing, data packet transmission testing and both. Use cases like multiple mobile nodes, multiple correspondent node, different mobility model for the mobile node as well as heterogeneous link layer technologies (Wi-Fi and WiMAX) could be used.
#The code will be sent for the code review to the ns-3 team.
* '''Second,''' IPV6 support for LTE would be ensured as LTE currently, only supports IPv4. The changes would possibly be done within the LTE module files (both .cc and .h) like point-topoint-helper, emu-epc-helper, lte-ue-net-device, epc-sgw-pgw-application, epc-enb-application, lte-enb-net-device etc. Then, the code analysis will be performed as done previously for MIPv6 code. The functional tests would follow bidirectional IPv6 packet transmission between remote host and the UE. The modification/rewriting code will create a patch that could enable IPv6 forwarding in the LTE data plane, enabling the UE to receive and use a /64 prefix, as stated in the standard. It is worth noticing that IP packets are tunnelled in the `core' network (i.e., all the EPC part), and their actual IP address is not used for UE identification in the core. As a consequence, IPv6 use in the `core' network, using ULAs or link-local addresses, could be planned if the previous development is faster than foreseen. This modification could also be simpler than expected, as it is not important to keep a dual stack communication in the core network, and using only IPv6 brings some direct benefits (like simplifying the use of multiple EPCs in a single script).
* '''Third,''' To ensure the code quality, the following testing approach could be used: Test MIPv6 handoff performance with the mixed link layer technologies (combination of Wi-Fi, WiMAX and LTE) case, multiple mobile node case, and multiple correspondent node case.

= Deliverables and Plan =
=== Deliverables: ===

-a basic MIPv6 module, aligned with RFC 6275 following ns-3 coding styles;

-a reviewed patch, fixing the IPv6 support issue in LTE;

-proper documentation and tests for the above-mentioned components.

=== Plan: ===

==== May 4 – May 29 (Before the official coding time): ====

-Familiarize myself completely with MIPv6, LTE (the IPv4 part), and the respective interactions.

-Study of the customized files of ns-3 lte and internet modules

-Familiarize myself with the ns-3 coding styles

During this period I will remain in constant touch with my mentor and the ns-3 community. I will remain active on IRC and Mailing lists to discuss and finalize on the modifications (if any) that needs to be on existing models and design of new module (if needed to fit cleanly with ns-3)

Thus with the help of my mentor I will become absolutely clear about my future goals, the final MIPv6 implementation that need to be done as well as the approach that I will follow to support IPv6 in lte model.

==== May 30 – June 26 (Official coding period starts): ====

-Refactor previous MIPv6 headers to RFC compliance header files

-Refactor all the classes to implement the corresponding header file functions

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the newly implemented MIPv6 module in various testing scenarios. The testing will be done with the systems having Wi-Fi and WiMAX link layer technology

-Sending the code for code review to the ns-3 team

After this stage, the standard ns-3 code revision can be started for the MIPv6 code part. Any change requested by the reviewers will be carried out in parallel with the following activities.

==== June 27 – July 24: ====

-Define new or, modify existing header files and cc files in LTE module in such a way that LTE module remains backward compatible with IPv4

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the LTE module

-Sending the code for code review to the ns-3 team

This will help in testing of the LTE module with IPv6 support for possible merge into the project main tree.

==== July 25 – August 21: ====

-Making further changes in the LTE module to support MIPv6 into it. Changes may be required in the other modules of ns-3 also.

-Testing the overall working in the testing scenarios having the combination of Wi-Fi and LTE

-Most of the time will be consumed for rigorous testing and bug fixes.

-Sending the code for code review to the ns-3 team

-Documentation updates.

= Weekly Reports =

=== May 30 - June 6 ===

1. Restructuring the MIPv6 code.

2. Testing the code in the multiple Mobile Node case

3. Changing the Home Agent functionality a little bit

4. Arise Tunnel Implementation Issue [how mobile node would use its home address for all of its data communication]

=== June 7 - June 13 ===

1. Resolved the issue of home address assignment to mobile node for all of its data communication. So, I have made some tricky callbacks in the L4 protocol a little bit. Now, traffic can be directed in both direction i.e. Mobile node to a web server and a web server to a mobile node

2. Also delete a lot of unnecessary files as well as lines in the code.

3. Tests have been done changing the location of different mobility entities. Almost all are successful. Those are included in "mipv6-test1-4.cc" in scratch of https://github.com/manoj24rana/MobileIPv6.

=== June 14 - June 20 ===

1. Done more tests

2. Add some more features such as defending home address and performing NS handling at HA as described in RFC 6275

3. Find an issue on RFC 6275 i.e. how to defend the mobile node's home address by home agent when it returns to its home network. Try to do something on the basis of ns-3 ipv6 implementation to resolve the issue.

=== June 21 - June 27 ===

1. Documentation on how my implementation differs from RFC 6275 as well as

2. Resolve the above issue

3. Sending the code for review.

=== June 28 - July 04 ===

1. Starting LTE IPv6 implementation part: understanding the end-to-end IPv4 part between UE and remote host, decoding it and discuss with my mentor for changing

2. Start writing code, at least one class modification

3. Test the change whether it is right.

=== July 05 - July 11 ===

1. Complete the modification in the lte module classes and also develop a small IPv6 dealing program to test

2. An issue arise i.e. Address Collision occurs at file: file=../src/internet/model/
ipv6-address-generator.cc, line=484". I am trying to resolve it.

3. Runs the previous IPv4 sample programs, which runs fine.

=== July 12 - July 18 ===

1. Resolve the IPv6 address collision issue in the LTE IPv6 support part.

2. I face another issue on handling multicast packets between UE sets and pgw i.e. those multicast packets are not passed between them as in the middle there is an enb.

3. Add the Sphinx documentation in the mipv6 module.

4. The Attributes and TraceSources are uploaded in mipv6 git.

=== July 19 - July 25 ===

1. Making some examples for the main mipv6 repo.

2. Add two tests in the main mipv6 repo.

3. mipv6 doc file further update.

4. Add and change tracesources and some functionalities in mipv6 model.

=== July 26 - August 1 ===

Finalize the MIPv6 code for review. I have added two nice tests replacing the previous tests, further update the mipv6 doc, trace sources, attributes, examples.
The codes are documented highly. Now the /doc/models/build/html dir contains the model documentation and the /doc/html creates doxygen for the mipv6 module.

=== August 2 - August 15 ===

1. Sent the MIPv6 code for review.

2. Solved LTE IPv6 packet sending issues.

3. Complete LTE IPv6 part, i.e. IPv6 packets are received and sent correctly.

4. Discuss with my mentor (Tommaso) elaborately about the next steps such that this implementation could be rebased in the main ns-3 dev quickly.

=== August 16 - August 22 ===

1. Update the LTE UE and PGW address assignment process in such a way that all IP addresses assigned by an EPC are derived from a base prefix (8 for IPv4 and 32 for IPv6) and each EPC holds a unique 16 bit IPv4 and 48 bit IPv6 subnet prefix to assign addresses to PGW and UEs. This address assignment process is made by keeping in mind the issues stated in https://www.nsnam.org/bugzilla/show_bug.cgi?id=1745 and https://groups.google.com/forum/#!topic/ns-3-users/Tc3IKky1OKo. So, now address duplication would not happen in case of more than one EPC as well as any time we could assign addresses without initializing the address helper. Also, user is given the flexibility to reassign the base 8 or, 32 bit address prefix at any time.

2. The LTE module is updated by IPv6 tests, documentation and examples. So, now the sample program is running and users can use them.

=== August 23 - August 29 ===

1. Submit the Google Work Product.

2. Send the LTE Code for review.

3. Try to resolve the reviewer's comment.

= Final Report for Google =
It has been an outstanding experience for me, spending this summer for GSoC project. I gave my full effort to make a very successful GSoC project and so, involved myself almost entirely. The huge interest from the current ns-3 users about my project speeds up the work process, which I have enjoyed most. I have learned a lot of things during this summer. Working for a community like ns-3 polishes my coding networking and communication skills a lot.

This final report contains all the links to all the works done over the summer. There have been almost 11,000 lines with 126 commits contributed in my github repo this summer.

=== Work Product Link ===

This is the complete work product link with full ns-3.25 software:

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6

My contribution:

As I have extended one of my project work (Mobile IPv6) in GSoC, I have divided my contribution into two parts:

The full contribution for this project is in the following link.

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/commit/7164250819b85ec2461e4c20667a516720eeddd5

Contribution during GSoC time period is in the following link (the last 126 commits by me).

https://github.com/manoj24rana/MobileIPv6

=== Installation and Running the Work Product ===

1. Depending on your OS, install the ns-3 Prerequisites from this link: https://www.nsnam.org/wiki/Installation#Prerequisites.

2. Download the code from this repository: https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6 (It is full) or, https://github.com/manoj24rana/MobileIPv6 (It requires other ns-3 components to be installed separately to add some extra features e.g. Visualizer) and extract it.

3. Make sure that you have installed all the perquisites to install ns-3.25.

4. Run the following commands in your cmd prompt to install it:

$ cd The_Project_Folder

$ cd ns-3.25

$ ./waf -d debug --enable-examples --enable-tests configure

$ ./waf

5. Running MIPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running MIPv6: mipv6-multiple.cc, mipv6-single.cc and mipv6-wifi-wimax.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run mipv6-multiple --vis

This will open a visualizer to see the output and the packet transmission in the background cmd prompt.

6. Running LTE IPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running LTE IPv6: lena-ipv6-ue-rh.cc, lena-ipv6-ue-ue.cc and lena-ipv6-addr-conf.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run lena-ipv6-ue-ue --vis

This will open a visualizer to see the output and the packet transmission in the background cmd prompt.

Note: If you have not downloaded from the first link, do not use --vis option at the time of running samples.

=== Documentation ===

Either, you follow the prepared documentation,

For MIPv6,

https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing

For LTE IPv6,

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/blob/master/ns-3.25/src/lte/doc/source/lte-design.rst and
https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/blob/master/ns-3.25/src/lte/doc/source/lte-user.rst

or, you could follow the manual for Creating Documentation here: https://www.nsnam.org/docs/manual/html/documentation.html. I have added the appropriate documentations within the code of the above repo of my implementation.

=== Work Flow ===

The following link will describe the weekly update of this project.

https://www.nsnam.org/wiki/GSOC2017MobileIp#Weekly_Reports

The flow of commits in the code could be found in the following link.

https://github.com/manoj24rana/MobileIPv6

=== Other Issues Resolved ===

I have resolved several other issues in ns-3 during this period as a part of my main implementation. Briefly, these are as follows.

1. Lack of IPv6 support for WiMAX module.

2. Duplicate IPv4 address collision problem in LTE module (https://groups.google.com/forum/#!topic/ns-3-users/Tc3IKky1OKo).

=== Future Enhancement for this Project ===

1. Creating some LTE samples which can run multiple LTE networks in single user's simulation script. It requires cooperation with the existing LTE maintainers in ns-3.

2. Add more options for mobility management. The actual code always switches to the "newest" network. More sophisticated approaches can be tested, like QoS measures and make-before-break.

3. Above all, the beauty of this project is that it is the implementation of the base IP mobility management protocol (MIPv6) in ns-3. The ns-3 users now can easily extend this feature to implement other such protocols, such as NEMO (RFC 3963), PMIPv6 (RFC 5213) etc. and also some upcoming schemes in 5G.

GSOC2017MobileIp

2017-08-29T07:43:10Z

Mkrana: /* Installation and Running the Work Product */

{{TOC}}

Return to [[GSOC2017AcceptedProjects | GSoC 2017 Accepted Projects]] page.

= Project overview =

* '''Project name:''' Mobile IPv6 Implementation with LTE support

* '''Student:''' [mailto:manoj24.rana@gmail.com Manoj Kumar Rana]

* '''Mentor:''' [mailto:tommypec@gmail.com Tommaso Pecorella]

* '''Abstract:''' The goal of the project is to implement a novel MIPv6 simulation model which can be integrated into ns-3. The project idea aims at testing the code in different network scenarios, containing different link layer technologies such as Wi-Fi, WiMAX and LTE. The current implementation of LTE does not have support of IPv6 in ns-3. So, the idea of testing MIPv6 code into LTE would follow IPv6 support implementation in LTE first and then the MIPv6 support. Thus, implementation of MIPv6 in ns-3 as the base mobility management solution and providing LTE support within it could help the current network researchers working on ns-3.

* '''Code:''' https://github.com/manoj24rana/MobileIPv6

* '''Documentation:'''
# Detail Description about the Implementation: http://www.sciencedirect.com/science/article/pii/S1569190X16302714
# Phase1 Documentation: https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing
# Phase2 Documentation: https://drive.google.com/open?id=0BziHE2fNAdZRbUZKN01Bd1Rjdk0

* '''About me:''' I am a PhD student in the School of Mobile Computing and Communications, Jadavpur University, India. About my research is given here: http://scholar.google.com/citations?user=qouvajAAAAAJ&hl=en.

= Technical Approach =
*'''First,''' I want to restructure the MIPv6 code, published in http://www.sciencedirect.com/science/article/pii/S1569190X16302714, to make it RFC 6275 compliance. To do the restructuring complete, the following approaches will be performed:
#Code refactoring: reorganizing internetstack, helper and header components of the MIPv6 module through modifying the internal functions, attributes and the callback variables.
#Code analysis: both static and dynamic analysis could be performed. The waf tool for code run, PyViz for visualization and tcpdump for pcap tracing could be used.
#Functional tests: The functional test would be performed in three phase: handoff performance testing, data packet transmission testing and both. Use cases like multiple mobile nodes, multiple correspondent node, different mobility model for the mobile node as well as heterogeneous link layer technologies (Wi-Fi and WiMAX) could be used.
#The code will be sent for the code review to the ns-3 team.
* '''Second,''' IPV6 support for LTE would be ensured as LTE currently, only supports IPv4. The changes would possibly be done within the LTE module files (both .cc and .h) like point-topoint-helper, emu-epc-helper, lte-ue-net-device, epc-sgw-pgw-application, epc-enb-application, lte-enb-net-device etc. Then, the code analysis will be performed as done previously for MIPv6 code. The functional tests would follow bidirectional IPv6 packet transmission between remote host and the UE. The modification/rewriting code will create a patch that could enable IPv6 forwarding in the LTE data plane, enabling the UE to receive and use a /64 prefix, as stated in the standard. It is worth noticing that IP packets are tunnelled in the `core' network (i.e., all the EPC part), and their actual IP address is not used for UE identification in the core. As a consequence, IPv6 use in the `core' network, using ULAs or link-local addresses, could be planned if the previous development is faster than foreseen. This modification could also be simpler than expected, as it is not important to keep a dual stack communication in the core network, and using only IPv6 brings some direct benefits (like simplifying the use of multiple EPCs in a single script).
* '''Third,''' To ensure the code quality, the following testing approach could be used: Test MIPv6 handoff performance with the mixed link layer technologies (combination of Wi-Fi, WiMAX and LTE) case, multiple mobile node case, and multiple correspondent node case.

= Deliverables and Plan =
=== Deliverables: ===

-a basic MIPv6 module, aligned with RFC 6275 following ns-3 coding styles;

-a reviewed patch, fixing the IPv6 support issue in LTE;

-proper documentation and tests for the above-mentioned components.

=== Plan: ===

==== May 4 – May 29 (Before the official coding time): ====

-Familiarize myself completely with MIPv6, LTE (the IPv4 part), and the respective interactions.

-Study of the customized files of ns-3 lte and internet modules

-Familiarize myself with the ns-3 coding styles

During this period I will remain in constant touch with my mentor and the ns-3 community. I will remain active on IRC and Mailing lists to discuss and finalize on the modifications (if any) that needs to be on existing models and design of new module (if needed to fit cleanly with ns-3)

Thus with the help of my mentor I will become absolutely clear about my future goals, the final MIPv6 implementation that need to be done as well as the approach that I will follow to support IPv6 in lte model.

==== May 30 – June 26 (Official coding period starts): ====

-Refactor previous MIPv6 headers to RFC compliance header files

-Refactor all the classes to implement the corresponding header file functions

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the newly implemented MIPv6 module in various testing scenarios. The testing will be done with the systems having Wi-Fi and WiMAX link layer technology

-Sending the code for code review to the ns-3 team

After this stage, the standard ns-3 code revision can be started for the MIPv6 code part. Any change requested by the reviewers will be carried out in parallel with the following activities.

==== June 27 – July 24: ====

-Define new or, modify existing header files and cc files in LTE module in such a way that LTE module remains backward compatible with IPv4

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the LTE module

-Sending the code for code review to the ns-3 team

This will help in testing of the LTE module with IPv6 support for possible merge into the project main tree.

==== July 25 – August 21: ====

-Making further changes in the LTE module to support MIPv6 into it. Changes may be required in the other modules of ns-3 also.

-Testing the overall working in the testing scenarios having the combination of Wi-Fi and LTE

-Most of the time will be consumed for rigorous testing and bug fixes.

-Sending the code for code review to the ns-3 team

-Documentation updates.

= Weekly Reports =

=== May 30 - June 6 ===

1. Restructuring the MIPv6 code.

2. Testing the code in the multiple Mobile Node case

3. Changing the Home Agent functionality a little bit

4. Arise Tunnel Implementation Issue [how mobile node would use its home address for all of its data communication]

=== June 7 - June 13 ===

1. Resolved the issue of home address assignment to mobile node for all of its data communication. So, I have made some tricky callbacks in the L4 protocol a little bit. Now, traffic can be directed in both direction i.e. Mobile node to a web server and a web server to a mobile node

2. Also delete a lot of unnecessary files as well as lines in the code.

3. Tests have been done changing the location of different mobility entities. Almost all are successful. Those are included in "mipv6-test1-4.cc" in scratch of https://github.com/manoj24rana/MobileIPv6.

=== June 14 - June 20 ===

1. Done more tests

2. Add some more features such as defending home address and performing NS handling at HA as described in RFC 6275

3. Find an issue on RFC 6275 i.e. how to defend the mobile node's home address by home agent when it returns to its home network. Try to do something on the basis of ns-3 ipv6 implementation to resolve the issue.

=== June 21 - June 27 ===

1. Documentation on how my implementation differs from RFC 6275 as well as

2. Resolve the above issue

3. Sending the code for review.

=== June 28 - July 04 ===

1. Starting LTE IPv6 implementation part: understanding the end-to-end IPv4 part between UE and remote host, decoding it and discuss with my mentor for changing

2. Start writing code, at least one class modification

3. Test the change whether it is right.

=== July 05 - July 11 ===

1. Complete the modification in the lte module classes and also develop a small IPv6 dealing program to test

2. An issue arise i.e. Address Collision occurs at file: file=../src/internet/model/
ipv6-address-generator.cc, line=484". I am trying to resolve it.

3. Runs the previous IPv4 sample programs, which runs fine.

=== July 12 - July 18 ===

1. Resolve the IPv6 address collision issue in the LTE IPv6 support part.

2. I face another issue on handling multicast packets between UE sets and pgw i.e. those multicast packets are not passed between them as in the middle there is an enb.

3. Add the Sphinx documentation in the mipv6 module.

4. The Attributes and TraceSources are uploaded in mipv6 git.

=== July 19 - July 25 ===

1. Making some examples for the main mipv6 repo.

2. Add two tests in the main mipv6 repo.

3. mipv6 doc file further update.

4. Add and change tracesources and some functionalities in mipv6 model.

=== July 26 - August 1 ===

Finalize the MIPv6 code for review. I have added two nice tests replacing the previous tests, further update the mipv6 doc, trace sources, attributes, examples.
The codes are documented highly. Now the /doc/models/build/html dir contains the model documentation and the /doc/html creates doxygen for the mipv6 module.

=== August 2 - August 15 ===

1. Sent the MIPv6 code for review.

2. Solved LTE IPv6 packet sending issues.

3. Complete LTE IPv6 part, i.e. IPv6 packets are received and sent correctly.

4. Discuss with my mentor (Tommaso) elaborately about the next steps such that this implementation could be rebased in the main ns-3 dev quickly.

=== August 16 - August 22 ===

1. Update the LTE UE and PGW address assignment process in such a way that all IP addresses assigned by an EPC are derived from a base prefix (8 for IPv4 and 32 for IPv6) and each EPC holds a unique 16 bit IPv4 and 48 bit IPv6 subnet prefix to assign addresses to PGW and UEs. This address assignment process is made by keeping in mind the issues stated in https://www.nsnam.org/bugzilla/show_bug.cgi?id=1745 and https://groups.google.com/forum/#!topic/ns-3-users/Tc3IKky1OKo. So, now address duplication would not happen in case of more than one EPC as well as any time we could assign addresses without initializing the address helper. Also, user is given the flexibility to reassign the base 8 or, 32 bit address prefix at any time.

2. The LTE module is updated by IPv6 tests, documentation and examples. So, now the sample program is running and users can use them.

=== August 23 - August 29 ===

1. Submit the Google Work Product.

2. Send the LTE Code for review.

3. Try to resolve the reviewer's comment.

= Final Report for Google =
It has been an outstanding experience for me, spending this summer for GSoC project. I gave my full effort to make a very successful GSoC project and so, involved myself almost entirely. The huge interest from the current ns-3 users about my project speeds up the work process, which I have enjoyed most. I have learned a lot of things during this summer. Working for a community like ns-3 polishes my coding networking and communication skills a lot.

This final report contains all the links to all the works done over the summer. There have been almost 11,000 lines with 126 commits contributed in my github repo this summer.

=== Work Product Link ===

This is the complete work product link with full ns-3.25 software:

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6

My contribution:

As I have extended one of my project work (Mobile IPv6) in GSoC, I have divided my contribution into two parts:

The full contribution for this project is in the following link.

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/commit/7164250819b85ec2461e4c20667a516720eeddd5

Contribution during GSoC time period is in the following link (the last 126 commits by me).

https://github.com/manoj24rana/MobileIPv6

=== Installation and Running the Work Product ===

1. Depending on your OS, install the ns-3 Prerequisites from this link: https://www.nsnam.org/wiki/Installation#Prerequisites.

2. Download the code from this repository: https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6 (It is full) or, https://github.com/manoj24rana/MobileIPv6 (It requires other ns-3 components to be installed separately to add some extra features e.g. Visualizer) and extract it.

3. Make sure that you have installed all the perquisites to install ns-3.25.

4. Run the following commands in your cmd prompt to install it:

$ cd The_Project_Folder

$ cd ns-3.25

$ ./waf -d debug --enable-examples --enable-tests configure

$ ./waf

5. Running MIPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running MIPv6: mipv6-multiple.cc, mipv6-single.cc and mipv6-wifi-wimax.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run mipv6-multiple --vis

This will open a visualizer to see the output and the packet transmission in the background cmd prompt.

6. Running LTE IPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running LTE IPv6: lena-ipv6-ue-rh.cc, lena-ipv6-ue-ue.cc and lena-ipv6-addr-conf.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run lena-ipv6-ue-ue --vis

This will open a visualizer to see the output and the packet transmission in the background cmd prompt.

=== Documentation ===

Either, you follow the prepared documentation,

For MIPv6,

https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing

For LTE IPv6,

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/blob/master/ns-3.25/src/lte/doc/source/lte-design.rst and
https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/blob/master/ns-3.25/src/lte/doc/source/lte-user.rst

or, you could follow the manual for Creating Documentation here: https://www.nsnam.org/docs/manual/html/documentation.html. I have added the appropriate documentations within the code of the above repo of my implementation.

=== Work Flow ===

The following link will describe the weekly update of this project.

https://www.nsnam.org/wiki/GSOC2017MobileIp#Weekly_Reports

The flow of commits in the code could be found in the following link.

https://github.com/manoj24rana/MobileIPv6

=== Other Issues Resolved ===

I have resolved several other issues in ns-3 during this period as a part of my main implementation. Briefly, these are as follows.

1. Lack of IPv6 support for WiMAX module.

2. Duplicate IPv4 address collision problem in LTE module (https://groups.google.com/forum/#!topic/ns-3-users/Tc3IKky1OKo).

=== Future Enhancement for this Project ===

1. Creating some LTE samples which can run multiple LTE networks in single user's simulation script. It requires cooperation with the existing LTE maintainers in ns-3.

2. Add more options for mobility management. The actual code always switches to the "newest" network. More sophisticated approaches can be tested, like QoS measures and make-before-break.

3. Above all, the beauty of this project is that it is the implementation of the base IP mobility management protocol (MIPv6) in ns-3. The ns-3 users now can easily extend this feature to implement other such protocols, such as NEMO (RFC 3963), PMIPv6 (RFC 5213) etc. and also some upcoming schemes in 5G.

GSOC2017MobileIp

2017-08-29T07:35:45Z

Mkrana: /* Work Product Link */

{{TOC}}

Return to [[GSOC2017AcceptedProjects | GSoC 2017 Accepted Projects]] page.

= Project overview =

* '''Project name:''' Mobile IPv6 Implementation with LTE support

* '''Student:''' [mailto:manoj24.rana@gmail.com Manoj Kumar Rana]

* '''Mentor:''' [mailto:tommypec@gmail.com Tommaso Pecorella]

* '''Abstract:''' The goal of the project is to implement a novel MIPv6 simulation model which can be integrated into ns-3. The project idea aims at testing the code in different network scenarios, containing different link layer technologies such as Wi-Fi, WiMAX and LTE. The current implementation of LTE does not have support of IPv6 in ns-3. So, the idea of testing MIPv6 code into LTE would follow IPv6 support implementation in LTE first and then the MIPv6 support. Thus, implementation of MIPv6 in ns-3 as the base mobility management solution and providing LTE support within it could help the current network researchers working on ns-3.

* '''Code:''' https://github.com/manoj24rana/MobileIPv6

* '''Documentation:'''
# Detail Description about the Implementation: http://www.sciencedirect.com/science/article/pii/S1569190X16302714
# Phase1 Documentation: https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing
# Phase2 Documentation: https://drive.google.com/open?id=0BziHE2fNAdZRbUZKN01Bd1Rjdk0

* '''About me:''' I am a PhD student in the School of Mobile Computing and Communications, Jadavpur University, India. About my research is given here: http://scholar.google.com/citations?user=qouvajAAAAAJ&hl=en.

= Technical Approach =
*'''First,''' I want to restructure the MIPv6 code, published in http://www.sciencedirect.com/science/article/pii/S1569190X16302714, to make it RFC 6275 compliance. To do the restructuring complete, the following approaches will be performed:
#Code refactoring: reorganizing internetstack, helper and header components of the MIPv6 module through modifying the internal functions, attributes and the callback variables.
#Code analysis: both static and dynamic analysis could be performed. The waf tool for code run, PyViz for visualization and tcpdump for pcap tracing could be used.
#Functional tests: The functional test would be performed in three phase: handoff performance testing, data packet transmission testing and both. Use cases like multiple mobile nodes, multiple correspondent node, different mobility model for the mobile node as well as heterogeneous link layer technologies (Wi-Fi and WiMAX) could be used.
#The code will be sent for the code review to the ns-3 team.
* '''Second,''' IPV6 support for LTE would be ensured as LTE currently, only supports IPv4. The changes would possibly be done within the LTE module files (both .cc and .h) like point-topoint-helper, emu-epc-helper, lte-ue-net-device, epc-sgw-pgw-application, epc-enb-application, lte-enb-net-device etc. Then, the code analysis will be performed as done previously for MIPv6 code. The functional tests would follow bidirectional IPv6 packet transmission between remote host and the UE. The modification/rewriting code will create a patch that could enable IPv6 forwarding in the LTE data plane, enabling the UE to receive and use a /64 prefix, as stated in the standard. It is worth noticing that IP packets are tunnelled in the `core' network (i.e., all the EPC part), and their actual IP address is not used for UE identification in the core. As a consequence, IPv6 use in the `core' network, using ULAs or link-local addresses, could be planned if the previous development is faster than foreseen. This modification could also be simpler than expected, as it is not important to keep a dual stack communication in the core network, and using only IPv6 brings some direct benefits (like simplifying the use of multiple EPCs in a single script).
* '''Third,''' To ensure the code quality, the following testing approach could be used: Test MIPv6 handoff performance with the mixed link layer technologies (combination of Wi-Fi, WiMAX and LTE) case, multiple mobile node case, and multiple correspondent node case.

= Deliverables and Plan =
=== Deliverables: ===

-a basic MIPv6 module, aligned with RFC 6275 following ns-3 coding styles;

-a reviewed patch, fixing the IPv6 support issue in LTE;

-proper documentation and tests for the above-mentioned components.

=== Plan: ===

==== May 4 – May 29 (Before the official coding time): ====

-Familiarize myself completely with MIPv6, LTE (the IPv4 part), and the respective interactions.

-Study of the customized files of ns-3 lte and internet modules

-Familiarize myself with the ns-3 coding styles

During this period I will remain in constant touch with my mentor and the ns-3 community. I will remain active on IRC and Mailing lists to discuss and finalize on the modifications (if any) that needs to be on existing models and design of new module (if needed to fit cleanly with ns-3)

Thus with the help of my mentor I will become absolutely clear about my future goals, the final MIPv6 implementation that need to be done as well as the approach that I will follow to support IPv6 in lte model.

==== May 30 – June 26 (Official coding period starts): ====

-Refactor previous MIPv6 headers to RFC compliance header files

-Refactor all the classes to implement the corresponding header file functions

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the newly implemented MIPv6 module in various testing scenarios. The testing will be done with the systems having Wi-Fi and WiMAX link layer technology

-Sending the code for code review to the ns-3 team

After this stage, the standard ns-3 code revision can be started for the MIPv6 code part. Any change requested by the reviewers will be carried out in parallel with the following activities.

==== June 27 – July 24: ====

-Define new or, modify existing header files and cc files in LTE module in such a way that LTE module remains backward compatible with IPv4

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the LTE module

-Sending the code for code review to the ns-3 team

This will help in testing of the LTE module with IPv6 support for possible merge into the project main tree.

==== July 25 – August 21: ====

-Making further changes in the LTE module to support MIPv6 into it. Changes may be required in the other modules of ns-3 also.

-Testing the overall working in the testing scenarios having the combination of Wi-Fi and LTE

-Most of the time will be consumed for rigorous testing and bug fixes.

-Sending the code for code review to the ns-3 team

-Documentation updates.

= Weekly Reports =

=== May 30 - June 6 ===

1. Restructuring the MIPv6 code.

2. Testing the code in the multiple Mobile Node case

3. Changing the Home Agent functionality a little bit

4. Arise Tunnel Implementation Issue [how mobile node would use its home address for all of its data communication]

=== June 7 - June 13 ===

1. Resolved the issue of home address assignment to mobile node for all of its data communication. So, I have made some tricky callbacks in the L4 protocol a little bit. Now, traffic can be directed in both direction i.e. Mobile node to a web server and a web server to a mobile node

2. Also delete a lot of unnecessary files as well as lines in the code.

3. Tests have been done changing the location of different mobility entities. Almost all are successful. Those are included in "mipv6-test1-4.cc" in scratch of https://github.com/manoj24rana/MobileIPv6.

=== June 14 - June 20 ===

1. Done more tests

2. Add some more features such as defending home address and performing NS handling at HA as described in RFC 6275

3. Find an issue on RFC 6275 i.e. how to defend the mobile node's home address by home agent when it returns to its home network. Try to do something on the basis of ns-3 ipv6 implementation to resolve the issue.

=== June 21 - June 27 ===

1. Documentation on how my implementation differs from RFC 6275 as well as

2. Resolve the above issue

3. Sending the code for review.

=== June 28 - July 04 ===

1. Starting LTE IPv6 implementation part: understanding the end-to-end IPv4 part between UE and remote host, decoding it and discuss with my mentor for changing

2. Start writing code, at least one class modification

3. Test the change whether it is right.

=== July 05 - July 11 ===

1. Complete the modification in the lte module classes and also develop a small IPv6 dealing program to test

2. An issue arise i.e. Address Collision occurs at file: file=../src/internet/model/
ipv6-address-generator.cc, line=484". I am trying to resolve it.

3. Runs the previous IPv4 sample programs, which runs fine.

=== July 12 - July 18 ===

1. Resolve the IPv6 address collision issue in the LTE IPv6 support part.

2. I face another issue on handling multicast packets between UE sets and pgw i.e. those multicast packets are not passed between them as in the middle there is an enb.

3. Add the Sphinx documentation in the mipv6 module.

4. The Attributes and TraceSources are uploaded in mipv6 git.

=== July 19 - July 25 ===

1. Making some examples for the main mipv6 repo.

2. Add two tests in the main mipv6 repo.

3. mipv6 doc file further update.

4. Add and change tracesources and some functionalities in mipv6 model.

=== July 26 - August 1 ===

Finalize the MIPv6 code for review. I have added two nice tests replacing the previous tests, further update the mipv6 doc, trace sources, attributes, examples.
The codes are documented highly. Now the /doc/models/build/html dir contains the model documentation and the /doc/html creates doxygen for the mipv6 module.

=== August 2 - August 15 ===

1. Sent the MIPv6 code for review.

2. Solved LTE IPv6 packet sending issues.

3. Complete LTE IPv6 part, i.e. IPv6 packets are received and sent correctly.

4. Discuss with my mentor (Tommaso) elaborately about the next steps such that this implementation could be rebased in the main ns-3 dev quickly.

=== August 16 - August 22 ===

1. Update the LTE UE and PGW address assignment process in such a way that all IP addresses assigned by an EPC are derived from a base prefix (8 for IPv4 and 32 for IPv6) and each EPC holds a unique 16 bit IPv4 and 48 bit IPv6 subnet prefix to assign addresses to PGW and UEs. This address assignment process is made by keeping in mind the issues stated in https://www.nsnam.org/bugzilla/show_bug.cgi?id=1745 and https://groups.google.com/forum/#!topic/ns-3-users/Tc3IKky1OKo. So, now address duplication would not happen in case of more than one EPC as well as any time we could assign addresses without initializing the address helper. Also, user is given the flexibility to reassign the base 8 or, 32 bit address prefix at any time.

2. The LTE module is updated by IPv6 tests, documentation and examples. So, now the sample program is running and users can use them.

=== August 23 - August 29 ===

1. Submit the Google Work Product.

2. Send the LTE Code for review.

3. Try to resolve the reviewer's comment.

= Final Report for Google =
It has been an outstanding experience for me, spending this summer for GSoC project. I gave my full effort to make a very successful GSoC project and so, involved myself almost entirely. The huge interest from the current ns-3 users about my project speeds up the work process, which I have enjoyed most. I have learned a lot of things during this summer. Working for a community like ns-3 polishes my coding networking and communication skills a lot.

This final report contains all the links to all the works done over the summer. There have been almost 11,000 lines with 126 commits contributed in my github repo this summer.

=== Work Product Link ===

This is the complete work product link with full ns-3.25 software:

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6

My contribution:

As I have extended one of my project work (Mobile IPv6) in GSoC, I have divided my contribution into two parts:

The full contribution for this project is in the following link.

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/commit/7164250819b85ec2461e4c20667a516720eeddd5

Contribution during GSoC time period is in the following link (the last 126 commits by me).

https://github.com/manoj24rana/MobileIPv6

=== Installation and Running the Work Product ===

1. Depending on your OS, install the ns-3 Prerequisites from this link: https://www.nsnam.org/wiki/Installation#Prerequisites.

2. Download the code from this repository: https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6 and extract it.

3. Make sure that you have installed all the perquisites to install ns-3.25.

4. Run the following commands in your cmd prompt to install it:

$ cd The_Project_Folder

$ cd ns-3.25

$ ./waf -d debug --enable-examples --enable-tests configure

$ ./waf

5. Running MIPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running MIPv6: mipv6-multiple.cc, mipv6-single.cc and mipv6-wifi-wimax.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run mipv6-multiple --vis

This will open a visualizer to see the output and the packet transmission in the background cmd prompt.

6. Running LTE IPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running LTE IPv6: lena-ipv6-ue-rh.cc, lena-ipv6-ue-ue.cc and lena-ipv6-addr-conf.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run lena-ipv6-ue-ue --vis

This will open a visualizer to see the output and the packet transmission in the background cmd prompt.

=== Documentation ===

Either, you follow the prepared documentation,

For MIPv6,

https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing

For LTE IPv6,

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/blob/master/ns-3.25/src/lte/doc/source/lte-design.rst and
https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/blob/master/ns-3.25/src/lte/doc/source/lte-user.rst

or, you could follow the manual for Creating Documentation here: https://www.nsnam.org/docs/manual/html/documentation.html. I have added the appropriate documentations within the code of the above repo of my implementation.

=== Work Flow ===

The following link will describe the weekly update of this project.

https://www.nsnam.org/wiki/GSOC2017MobileIp#Weekly_Reports

The flow of commits in the code could be found in the following link.

https://github.com/manoj24rana/MobileIPv6

=== Other Issues Resolved ===

I have resolved several other issues in ns-3 during this period as a part of my main implementation. Briefly, these are as follows.

1. Lack of IPv6 support for WiMAX module.

2. Duplicate IPv4 address collision problem in LTE module (https://groups.google.com/forum/#!topic/ns-3-users/Tc3IKky1OKo).

=== Future Enhancement for this Project ===

1. Creating some LTE samples which can run multiple LTE networks in single user's simulation script. It requires cooperation with the existing LTE maintainers in ns-3.

2. Add more options for mobility management. The actual code always switches to the "newest" network. More sophisticated approaches can be tested, like QoS measures and make-before-break.

3. Above all, the beauty of this project is that it is the implementation of the base IP mobility management protocol (MIPv6) in ns-3. The ns-3 users now can easily extend this feature to implement other such protocols, such as NEMO (RFC 3963), PMIPv6 (RFC 5213) etc. and also some upcoming schemes in 5G.

GSOC2017MobileIp

2017-08-29T07:31:27Z

Mkrana: /* Work Product Link */

{{TOC}}

Return to [[GSOC2017AcceptedProjects | GSoC 2017 Accepted Projects]] page.

= Project overview =

* '''Project name:''' Mobile IPv6 Implementation with LTE support

* '''Student:''' [mailto:manoj24.rana@gmail.com Manoj Kumar Rana]

* '''Mentor:''' [mailto:tommypec@gmail.com Tommaso Pecorella]

* '''Abstract:''' The goal of the project is to implement a novel MIPv6 simulation model which can be integrated into ns-3. The project idea aims at testing the code in different network scenarios, containing different link layer technologies such as Wi-Fi, WiMAX and LTE. The current implementation of LTE does not have support of IPv6 in ns-3. So, the idea of testing MIPv6 code into LTE would follow IPv6 support implementation in LTE first and then the MIPv6 support. Thus, implementation of MIPv6 in ns-3 as the base mobility management solution and providing LTE support within it could help the current network researchers working on ns-3.

* '''Code:''' https://github.com/manoj24rana/MobileIPv6

* '''Documentation:'''
# Detail Description about the Implementation: http://www.sciencedirect.com/science/article/pii/S1569190X16302714
# Phase1 Documentation: https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing
# Phase2 Documentation: https://drive.google.com/open?id=0BziHE2fNAdZRbUZKN01Bd1Rjdk0

* '''About me:''' I am a PhD student in the School of Mobile Computing and Communications, Jadavpur University, India. About my research is given here: http://scholar.google.com/citations?user=qouvajAAAAAJ&hl=en.

= Technical Approach =
*'''First,''' I want to restructure the MIPv6 code, published in http://www.sciencedirect.com/science/article/pii/S1569190X16302714, to make it RFC 6275 compliance. To do the restructuring complete, the following approaches will be performed:
#Code refactoring: reorganizing internetstack, helper and header components of the MIPv6 module through modifying the internal functions, attributes and the callback variables.
#Code analysis: both static and dynamic analysis could be performed. The waf tool for code run, PyViz for visualization and tcpdump for pcap tracing could be used.
#Functional tests: The functional test would be performed in three phase: handoff performance testing, data packet transmission testing and both. Use cases like multiple mobile nodes, multiple correspondent node, different mobility model for the mobile node as well as heterogeneous link layer technologies (Wi-Fi and WiMAX) could be used.
#The code will be sent for the code review to the ns-3 team.
* '''Second,''' IPV6 support for LTE would be ensured as LTE currently, only supports IPv4. The changes would possibly be done within the LTE module files (both .cc and .h) like point-topoint-helper, emu-epc-helper, lte-ue-net-device, epc-sgw-pgw-application, epc-enb-application, lte-enb-net-device etc. Then, the code analysis will be performed as done previously for MIPv6 code. The functional tests would follow bidirectional IPv6 packet transmission between remote host and the UE. The modification/rewriting code will create a patch that could enable IPv6 forwarding in the LTE data plane, enabling the UE to receive and use a /64 prefix, as stated in the standard. It is worth noticing that IP packets are tunnelled in the `core' network (i.e., all the EPC part), and their actual IP address is not used for UE identification in the core. As a consequence, IPv6 use in the `core' network, using ULAs or link-local addresses, could be planned if the previous development is faster than foreseen. This modification could also be simpler than expected, as it is not important to keep a dual stack communication in the core network, and using only IPv6 brings some direct benefits (like simplifying the use of multiple EPCs in a single script).
* '''Third,''' To ensure the code quality, the following testing approach could be used: Test MIPv6 handoff performance with the mixed link layer technologies (combination of Wi-Fi, WiMAX and LTE) case, multiple mobile node case, and multiple correspondent node case.

= Deliverables and Plan =
=== Deliverables: ===

-a basic MIPv6 module, aligned with RFC 6275 following ns-3 coding styles;

-a reviewed patch, fixing the IPv6 support issue in LTE;

-proper documentation and tests for the above-mentioned components.

=== Plan: ===

==== May 4 – May 29 (Before the official coding time): ====

-Familiarize myself completely with MIPv6, LTE (the IPv4 part), and the respective interactions.

-Study of the customized files of ns-3 lte and internet modules

-Familiarize myself with the ns-3 coding styles

During this period I will remain in constant touch with my mentor and the ns-3 community. I will remain active on IRC and Mailing lists to discuss and finalize on the modifications (if any) that needs to be on existing models and design of new module (if needed to fit cleanly with ns-3)

Thus with the help of my mentor I will become absolutely clear about my future goals, the final MIPv6 implementation that need to be done as well as the approach that I will follow to support IPv6 in lte model.

==== May 30 – June 26 (Official coding period starts): ====

-Refactor previous MIPv6 headers to RFC compliance header files

-Refactor all the classes to implement the corresponding header file functions

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the newly implemented MIPv6 module in various testing scenarios. The testing will be done with the systems having Wi-Fi and WiMAX link layer technology

-Sending the code for code review to the ns-3 team

After this stage, the standard ns-3 code revision can be started for the MIPv6 code part. Any change requested by the reviewers will be carried out in parallel with the following activities.

==== June 27 – July 24: ====

-Define new or, modify existing header files and cc files in LTE module in such a way that LTE module remains backward compatible with IPv4

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the LTE module

-Sending the code for code review to the ns-3 team

This will help in testing of the LTE module with IPv6 support for possible merge into the project main tree.

==== July 25 – August 21: ====

-Making further changes in the LTE module to support MIPv6 into it. Changes may be required in the other modules of ns-3 also.

-Testing the overall working in the testing scenarios having the combination of Wi-Fi and LTE

-Most of the time will be consumed for rigorous testing and bug fixes.

-Sending the code for code review to the ns-3 team

-Documentation updates.

= Weekly Reports =

=== May 30 - June 6 ===

1. Restructuring the MIPv6 code.

2. Testing the code in the multiple Mobile Node case

3. Changing the Home Agent functionality a little bit

4. Arise Tunnel Implementation Issue [how mobile node would use its home address for all of its data communication]

=== June 7 - June 13 ===

1. Resolved the issue of home address assignment to mobile node for all of its data communication. So, I have made some tricky callbacks in the L4 protocol a little bit. Now, traffic can be directed in both direction i.e. Mobile node to a web server and a web server to a mobile node

2. Also delete a lot of unnecessary files as well as lines in the code.

3. Tests have been done changing the location of different mobility entities. Almost all are successful. Those are included in "mipv6-test1-4.cc" in scratch of https://github.com/manoj24rana/MobileIPv6.

=== June 14 - June 20 ===

1. Done more tests

2. Add some more features such as defending home address and performing NS handling at HA as described in RFC 6275

3. Find an issue on RFC 6275 i.e. how to defend the mobile node's home address by home agent when it returns to its home network. Try to do something on the basis of ns-3 ipv6 implementation to resolve the issue.

=== June 21 - June 27 ===

1. Documentation on how my implementation differs from RFC 6275 as well as

2. Resolve the above issue

3. Sending the code for review.

=== June 28 - July 04 ===

1. Starting LTE IPv6 implementation part: understanding the end-to-end IPv4 part between UE and remote host, decoding it and discuss with my mentor for changing

2. Start writing code, at least one class modification

3. Test the change whether it is right.

=== July 05 - July 11 ===

1. Complete the modification in the lte module classes and also develop a small IPv6 dealing program to test

2. An issue arise i.e. Address Collision occurs at file: file=../src/internet/model/
ipv6-address-generator.cc, line=484". I am trying to resolve it.

3. Runs the previous IPv4 sample programs, which runs fine.

=== July 12 - July 18 ===

1. Resolve the IPv6 address collision issue in the LTE IPv6 support part.

2. I face another issue on handling multicast packets between UE sets and pgw i.e. those multicast packets are not passed between them as in the middle there is an enb.

3. Add the Sphinx documentation in the mipv6 module.

4. The Attributes and TraceSources are uploaded in mipv6 git.

=== July 19 - July 25 ===

1. Making some examples for the main mipv6 repo.

2. Add two tests in the main mipv6 repo.

3. mipv6 doc file further update.

4. Add and change tracesources and some functionalities in mipv6 model.

=== July 26 - August 1 ===

Finalize the MIPv6 code for review. I have added two nice tests replacing the previous tests, further update the mipv6 doc, trace sources, attributes, examples.
The codes are documented highly. Now the /doc/models/build/html dir contains the model documentation and the /doc/html creates doxygen for the mipv6 module.

=== August 2 - August 15 ===

1. Sent the MIPv6 code for review.

2. Solved LTE IPv6 packet sending issues.

3. Complete LTE IPv6 part, i.e. IPv6 packets are received and sent correctly.

4. Discuss with my mentor (Tommaso) elaborately about the next steps such that this implementation could be rebased in the main ns-3 dev quickly.

=== August 16 - August 22 ===

1. Update the LTE UE and PGW address assignment process in such a way that all IP addresses assigned by an EPC are derived from a base prefix (8 for IPv4 and 32 for IPv6) and each EPC holds a unique 16 bit IPv4 and 48 bit IPv6 subnet prefix to assign addresses to PGW and UEs. This address assignment process is made by keeping in mind the issues stated in https://www.nsnam.org/bugzilla/show_bug.cgi?id=1745 and https://groups.google.com/forum/#!topic/ns-3-users/Tc3IKky1OKo. So, now address duplication would not happen in case of more than one EPC as well as any time we could assign addresses without initializing the address helper. Also, user is given the flexibility to reassign the base 8 or, 32 bit address prefix at any time.

2. The LTE module is updated by IPv6 tests, documentation and examples. So, now the sample program is running and users can use them.

=== August 23 - August 29 ===

1. Submit the Google Work Product.

2. Send the LTE Code for review.

3. Try to resolve the reviewer's comment.

= Final Report for Google =
It has been an outstanding experience for me, spending this summer for GSoC project. I gave my full effort to make a very successful GSoC project and so, involved myself almost entirely. The huge interest from the current ns-3 users about my project speeds up the work process, which I have enjoyed most. I have learned a lot of things during this summer. Working for a community like ns-3 polishes my coding networking and communication skills a lot.

This final report contains all the links to all the works done over the summer. There have been almost 11,000 lines with 126 commits contributed in my github repo this summer.

=== Work Product Link ===

This is the complete work product link with full ns-3.25 software:

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6

My contribution:

As I have extended one of my project work (Mobile IPv6) in GSoC, I have divided my contribution into two parts:

The full contribution for this project is in the following link.

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/commit/7164250819b85ec2461e4c20667a516720eeddd5

Contribution during GSoC time period is in the following link (the last 128 commits by me).

https://github.com/manoj24rana/MobileIPv6

=== Installation and Running the Work Product ===

1. Depending on your OS, install the ns-3 Prerequisites from this link: https://www.nsnam.org/wiki/Installation#Prerequisites.

2. Download the code from this repository: https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6 and extract it.

3. Make sure that you have installed all the perquisites to install ns-3.25.

4. Run the following commands in your cmd prompt to install it:

$ cd The_Project_Folder

$ cd ns-3.25

$ ./waf -d debug --enable-examples --enable-tests configure

$ ./waf

5. Running MIPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running MIPv6: mipv6-multiple.cc, mipv6-single.cc and mipv6-wifi-wimax.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run mipv6-multiple --vis

This will open a visualizer to see the output and the packet transmission in the background cmd prompt.

6. Running LTE IPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running LTE IPv6: lena-ipv6-ue-rh.cc, lena-ipv6-ue-ue.cc and lena-ipv6-addr-conf.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run lena-ipv6-ue-ue --vis

This will open a visualizer to see the output and the packet transmission in the background cmd prompt.

=== Documentation ===

Either, you follow the prepared documentation,

For MIPv6,

https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing

For LTE IPv6,

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/blob/master/ns-3.25/src/lte/doc/source/lte-design.rst and
https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/blob/master/ns-3.25/src/lte/doc/source/lte-user.rst

or, you could follow the manual for Creating Documentation here: https://www.nsnam.org/docs/manual/html/documentation.html. I have added the appropriate documentations within the code of the above repo of my implementation.

=== Work Flow ===

The following link will describe the weekly update of this project.

https://www.nsnam.org/wiki/GSOC2017MobileIp#Weekly_Reports

The flow of commits in the code could be found in the following link.

https://github.com/manoj24rana/MobileIPv6

=== Other Issues Resolved ===

I have resolved several other issues in ns-3 during this period as a part of my main implementation. Briefly, these are as follows.

1. Lack of IPv6 support for WiMAX module.

2. Duplicate IPv4 address collision problem in LTE module (https://groups.google.com/forum/#!topic/ns-3-users/Tc3IKky1OKo).

=== Future Enhancement for this Project ===

1. Creating some LTE samples which can run multiple LTE networks in single user's simulation script. It requires cooperation with the existing LTE maintainers in ns-3.

2. Add more options for mobility management. The actual code always switches to the "newest" network. More sophisticated approaches can be tested, like QoS measures and make-before-break.

3. Above all, the beauty of this project is that it is the implementation of the base IP mobility management protocol (MIPv6) in ns-3. The ns-3 users now can easily extend this feature to implement other such protocols, such as NEMO (RFC 3963), PMIPv6 (RFC 5213) etc. and also some upcoming schemes in 5G.

GSOC2017MobileIp

2017-08-29T07:13:18Z

Mkrana: /* Final Report for Google */

{{TOC}}

Return to [[GSOC2017AcceptedProjects | GSoC 2017 Accepted Projects]] page.

= Project overview =

* '''Project name:''' Mobile IPv6 Implementation with LTE support

* '''Student:''' [mailto:manoj24.rana@gmail.com Manoj Kumar Rana]

* '''Mentor:''' [mailto:tommypec@gmail.com Tommaso Pecorella]

* '''Abstract:''' The goal of the project is to implement a novel MIPv6 simulation model which can be integrated into ns-3. The project idea aims at testing the code in different network scenarios, containing different link layer technologies such as Wi-Fi, WiMAX and LTE. The current implementation of LTE does not have support of IPv6 in ns-3. So, the idea of testing MIPv6 code into LTE would follow IPv6 support implementation in LTE first and then the MIPv6 support. Thus, implementation of MIPv6 in ns-3 as the base mobility management solution and providing LTE support within it could help the current network researchers working on ns-3.

* '''Code:''' https://github.com/manoj24rana/MobileIPv6

* '''Documentation:'''
# Detail Description about the Implementation: http://www.sciencedirect.com/science/article/pii/S1569190X16302714
# Phase1 Documentation: https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing
# Phase2 Documentation: https://drive.google.com/open?id=0BziHE2fNAdZRbUZKN01Bd1Rjdk0

* '''About me:''' I am a PhD student in the School of Mobile Computing and Communications, Jadavpur University, India. About my research is given here: http://scholar.google.com/citations?user=qouvajAAAAAJ&hl=en.

= Technical Approach =
*'''First,''' I want to restructure the MIPv6 code, published in http://www.sciencedirect.com/science/article/pii/S1569190X16302714, to make it RFC 6275 compliance. To do the restructuring complete, the following approaches will be performed:
#Code refactoring: reorganizing internetstack, helper and header components of the MIPv6 module through modifying the internal functions, attributes and the callback variables.
#Code analysis: both static and dynamic analysis could be performed. The waf tool for code run, PyViz for visualization and tcpdump for pcap tracing could be used.
#Functional tests: The functional test would be performed in three phase: handoff performance testing, data packet transmission testing and both. Use cases like multiple mobile nodes, multiple correspondent node, different mobility model for the mobile node as well as heterogeneous link layer technologies (Wi-Fi and WiMAX) could be used.
#The code will be sent for the code review to the ns-3 team.
* '''Second,''' IPV6 support for LTE would be ensured as LTE currently, only supports IPv4. The changes would possibly be done within the LTE module files (both .cc and .h) like point-topoint-helper, emu-epc-helper, lte-ue-net-device, epc-sgw-pgw-application, epc-enb-application, lte-enb-net-device etc. Then, the code analysis will be performed as done previously for MIPv6 code. The functional tests would follow bidirectional IPv6 packet transmission between remote host and the UE. The modification/rewriting code will create a patch that could enable IPv6 forwarding in the LTE data plane, enabling the UE to receive and use a /64 prefix, as stated in the standard. It is worth noticing that IP packets are tunnelled in the `core' network (i.e., all the EPC part), and their actual IP address is not used for UE identification in the core. As a consequence, IPv6 use in the `core' network, using ULAs or link-local addresses, could be planned if the previous development is faster than foreseen. This modification could also be simpler than expected, as it is not important to keep a dual stack communication in the core network, and using only IPv6 brings some direct benefits (like simplifying the use of multiple EPCs in a single script).
* '''Third,''' To ensure the code quality, the following testing approach could be used: Test MIPv6 handoff performance with the mixed link layer technologies (combination of Wi-Fi, WiMAX and LTE) case, multiple mobile node case, and multiple correspondent node case.

= Deliverables and Plan =
=== Deliverables: ===

-a basic MIPv6 module, aligned with RFC 6275 following ns-3 coding styles;

-a reviewed patch, fixing the IPv6 support issue in LTE;

-proper documentation and tests for the above-mentioned components.

=== Plan: ===

==== May 4 – May 29 (Before the official coding time): ====

-Familiarize myself completely with MIPv6, LTE (the IPv4 part), and the respective interactions.

-Study of the customized files of ns-3 lte and internet modules

-Familiarize myself with the ns-3 coding styles

During this period I will remain in constant touch with my mentor and the ns-3 community. I will remain active on IRC and Mailing lists to discuss and finalize on the modifications (if any) that needs to be on existing models and design of new module (if needed to fit cleanly with ns-3)

Thus with the help of my mentor I will become absolutely clear about my future goals, the final MIPv6 implementation that need to be done as well as the approach that I will follow to support IPv6 in lte model.

==== May 30 – June 26 (Official coding period starts): ====

-Refactor previous MIPv6 headers to RFC compliance header files

-Refactor all the classes to implement the corresponding header file functions

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the newly implemented MIPv6 module in various testing scenarios. The testing will be done with the systems having Wi-Fi and WiMAX link layer technology

-Sending the code for code review to the ns-3 team

After this stage, the standard ns-3 code revision can be started for the MIPv6 code part. Any change requested by the reviewers will be carried out in parallel with the following activities.

==== June 27 – July 24: ====

-Define new or, modify existing header files and cc files in LTE module in such a way that LTE module remains backward compatible with IPv4

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the LTE module

-Sending the code for code review to the ns-3 team

This will help in testing of the LTE module with IPv6 support for possible merge into the project main tree.

==== July 25 – August 21: ====

-Making further changes in the LTE module to support MIPv6 into it. Changes may be required in the other modules of ns-3 also.

-Testing the overall working in the testing scenarios having the combination of Wi-Fi and LTE

-Most of the time will be consumed for rigorous testing and bug fixes.

-Sending the code for code review to the ns-3 team

-Documentation updates.

= Weekly Reports =

=== May 30 - June 6 ===

1. Restructuring the MIPv6 code.

2. Testing the code in the multiple Mobile Node case

3. Changing the Home Agent functionality a little bit

4. Arise Tunnel Implementation Issue [how mobile node would use its home address for all of its data communication]

=== June 7 - June 13 ===

1. Resolved the issue of home address assignment to mobile node for all of its data communication. So, I have made some tricky callbacks in the L4 protocol a little bit. Now, traffic can be directed in both direction i.e. Mobile node to a web server and a web server to a mobile node

2. Also delete a lot of unnecessary files as well as lines in the code.

3. Tests have been done changing the location of different mobility entities. Almost all are successful. Those are included in "mipv6-test1-4.cc" in scratch of https://github.com/manoj24rana/MobileIPv6.

=== June 14 - June 20 ===

1. Done more tests

2. Add some more features such as defending home address and performing NS handling at HA as described in RFC 6275

3. Find an issue on RFC 6275 i.e. how to defend the mobile node's home address by home agent when it returns to its home network. Try to do something on the basis of ns-3 ipv6 implementation to resolve the issue.

=== June 21 - June 27 ===

1. Documentation on how my implementation differs from RFC 6275 as well as

2. Resolve the above issue

3. Sending the code for review.

=== June 28 - July 04 ===

1. Starting LTE IPv6 implementation part: understanding the end-to-end IPv4 part between UE and remote host, decoding it and discuss with my mentor for changing

2. Start writing code, at least one class modification

3. Test the change whether it is right.

=== July 05 - July 11 ===

1. Complete the modification in the lte module classes and also develop a small IPv6 dealing program to test

2. An issue arise i.e. Address Collision occurs at file: file=../src/internet/model/
ipv6-address-generator.cc, line=484". I am trying to resolve it.

3. Runs the previous IPv4 sample programs, which runs fine.

=== July 12 - July 18 ===

1. Resolve the IPv6 address collision issue in the LTE IPv6 support part.

2. I face another issue on handling multicast packets between UE sets and pgw i.e. those multicast packets are not passed between them as in the middle there is an enb.

3. Add the Sphinx documentation in the mipv6 module.

4. The Attributes and TraceSources are uploaded in mipv6 git.

=== July 19 - July 25 ===

1. Making some examples for the main mipv6 repo.

2. Add two tests in the main mipv6 repo.

3. mipv6 doc file further update.

4. Add and change tracesources and some functionalities in mipv6 model.

=== July 26 - August 1 ===

Finalize the MIPv6 code for review. I have added two nice tests replacing the previous tests, further update the mipv6 doc, trace sources, attributes, examples.
The codes are documented highly. Now the /doc/models/build/html dir contains the model documentation and the /doc/html creates doxygen for the mipv6 module.

=== August 2 - August 15 ===

1. Sent the MIPv6 code for review.

2. Solved LTE IPv6 packet sending issues.

3. Complete LTE IPv6 part, i.e. IPv6 packets are received and sent correctly.

4. Discuss with my mentor (Tommaso) elaborately about the next steps such that this implementation could be rebased in the main ns-3 dev quickly.

=== August 16 - August 22 ===

1. Update the LTE UE and PGW address assignment process in such a way that all IP addresses assigned by an EPC are derived from a base prefix (8 for IPv4 and 32 for IPv6) and each EPC holds a unique 16 bit IPv4 and 48 bit IPv6 subnet prefix to assign addresses to PGW and UEs. This address assignment process is made by keeping in mind the issues stated in https://www.nsnam.org/bugzilla/show_bug.cgi?id=1745 and https://groups.google.com/forum/#!topic/ns-3-users/Tc3IKky1OKo. So, now address duplication would not happen in case of more than one EPC as well as any time we could assign addresses without initializing the address helper. Also, user is given the flexibility to reassign the base 8 or, 32 bit address prefix at any time.

2. The LTE module is updated by IPv6 tests, documentation and examples. So, now the sample program is running and users can use them.

=== August 23 - August 29 ===

1. Submit the Google Work Product.

2. Send the LTE Code for review.

3. Try to resolve the reviewer's comment.

= Final Report for Google =
It has been an outstanding experience for me, spending this summer for GSoC project. I gave my full effort to make a very successful GSoC project and so, involved myself almost entirely. The huge interest from the current ns-3 users about my project speeds up the work process, which I have enjoyed most. I have learned a lot of things during this summer. Working for a community like ns-3 polishes my coding networking and communication skills a lot.

This final report contains all the links to all the works done over the summer. There have been almost 11,000 lines with 126 commits contributed in my github repo this summer.

=== Work Product Link ===

This is the complete work product link with full ns-3.25 software:

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6

My contribution:

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/commit/7164250819b85ec2461e4c20667a516720eeddd5

=== Installation and Running the Work Product ===

1. Depending on your OS, install the ns-3 Prerequisites from this link: https://www.nsnam.org/wiki/Installation#Prerequisites.

2. Download the code from this repository: https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6 and extract it.

3. Make sure that you have installed all the perquisites to install ns-3.25.

4. Run the following commands in your cmd prompt to install it:

$ cd The_Project_Folder

$ cd ns-3.25

$ ./waf -d debug --enable-examples --enable-tests configure

$ ./waf

5. Running MIPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running MIPv6: mipv6-multiple.cc, mipv6-single.cc and mipv6-wifi-wimax.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run mipv6-multiple --vis

This will open a visualizer to see the output and the packet transmission in the background cmd prompt.

6. Running LTE IPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running LTE IPv6: lena-ipv6-ue-rh.cc, lena-ipv6-ue-ue.cc and lena-ipv6-addr-conf.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run lena-ipv6-ue-ue --vis

This will open a visualizer to see the output and the packet transmission in the background cmd prompt.

=== Documentation ===

Either, you follow the prepared documentation,

For MIPv6,

https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing

For LTE IPv6,

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/blob/master/ns-3.25/src/lte/doc/source/lte-design.rst and
https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/blob/master/ns-3.25/src/lte/doc/source/lte-user.rst

or, you could follow the manual for Creating Documentation here: https://www.nsnam.org/docs/manual/html/documentation.html. I have added the appropriate documentations within the code of the above repo of my implementation.

=== Work Flow ===

The following link will describe the weekly update of this project.

https://www.nsnam.org/wiki/GSOC2017MobileIp#Weekly_Reports

The flow of commits in the code could be found in the following link.

https://github.com/manoj24rana/MobileIPv6

=== Other Issues Resolved ===

I have resolved several other issues in ns-3 during this period as a part of my main implementation. Briefly, these are as follows.

1. Lack of IPv6 support for WiMAX module.

2. Duplicate IPv4 address collision problem in LTE module (https://groups.google.com/forum/#!topic/ns-3-users/Tc3IKky1OKo).

=== Future Enhancement for this Project ===

1. Creating some LTE samples which can run multiple LTE networks in single user's simulation script. It requires cooperation with the existing LTE maintainers in ns-3.

2. Add more options for mobility management. The actual code always switches to the "newest" network. More sophisticated approaches can be tested, like QoS measures and make-before-break.

3. Above all, the beauty of this project is that it is the implementation of the base IP mobility management protocol (MIPv6) in ns-3. The ns-3 users now can easily extend this feature to implement other such protocols, such as NEMO (RFC 3963), PMIPv6 (RFC 5213) etc. and also some upcoming schemes in 5G.

GSOC2017MobileIp

2017-08-29T07:12:03Z

Mkrana: /* Final Report for Google */

{{TOC}}

Return to [[GSOC2017AcceptedProjects | GSoC 2017 Accepted Projects]] page.

= Project overview =

* '''Project name:''' Mobile IPv6 Implementation with LTE support

* '''Student:''' [mailto:manoj24.rana@gmail.com Manoj Kumar Rana]

* '''Mentor:''' [mailto:tommypec@gmail.com Tommaso Pecorella]

* '''Abstract:''' The goal of the project is to implement a novel MIPv6 simulation model which can be integrated into ns-3. The project idea aims at testing the code in different network scenarios, containing different link layer technologies such as Wi-Fi, WiMAX and LTE. The current implementation of LTE does not have support of IPv6 in ns-3. So, the idea of testing MIPv6 code into LTE would follow IPv6 support implementation in LTE first and then the MIPv6 support. Thus, implementation of MIPv6 in ns-3 as the base mobility management solution and providing LTE support within it could help the current network researchers working on ns-3.

* '''Code:''' https://github.com/manoj24rana/MobileIPv6

* '''Documentation:'''
# Detail Description about the Implementation: http://www.sciencedirect.com/science/article/pii/S1569190X16302714
# Phase1 Documentation: https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing
# Phase2 Documentation: https://drive.google.com/open?id=0BziHE2fNAdZRbUZKN01Bd1Rjdk0

* '''About me:''' I am a PhD student in the School of Mobile Computing and Communications, Jadavpur University, India. About my research is given here: http://scholar.google.com/citations?user=qouvajAAAAAJ&hl=en.

= Technical Approach =
*'''First,''' I want to restructure the MIPv6 code, published in http://www.sciencedirect.com/science/article/pii/S1569190X16302714, to make it RFC 6275 compliance. To do the restructuring complete, the following approaches will be performed:
#Code refactoring: reorganizing internetstack, helper and header components of the MIPv6 module through modifying the internal functions, attributes and the callback variables.
#Code analysis: both static and dynamic analysis could be performed. The waf tool for code run, PyViz for visualization and tcpdump for pcap tracing could be used.
#Functional tests: The functional test would be performed in three phase: handoff performance testing, data packet transmission testing and both. Use cases like multiple mobile nodes, multiple correspondent node, different mobility model for the mobile node as well as heterogeneous link layer technologies (Wi-Fi and WiMAX) could be used.
#The code will be sent for the code review to the ns-3 team.
* '''Second,''' IPV6 support for LTE would be ensured as LTE currently, only supports IPv4. The changes would possibly be done within the LTE module files (both .cc and .h) like point-topoint-helper, emu-epc-helper, lte-ue-net-device, epc-sgw-pgw-application, epc-enb-application, lte-enb-net-device etc. Then, the code analysis will be performed as done previously for MIPv6 code. The functional tests would follow bidirectional IPv6 packet transmission between remote host and the UE. The modification/rewriting code will create a patch that could enable IPv6 forwarding in the LTE data plane, enabling the UE to receive and use a /64 prefix, as stated in the standard. It is worth noticing that IP packets are tunnelled in the `core' network (i.e., all the EPC part), and their actual IP address is not used for UE identification in the core. As a consequence, IPv6 use in the `core' network, using ULAs or link-local addresses, could be planned if the previous development is faster than foreseen. This modification could also be simpler than expected, as it is not important to keep a dual stack communication in the core network, and using only IPv6 brings some direct benefits (like simplifying the use of multiple EPCs in a single script).
* '''Third,''' To ensure the code quality, the following testing approach could be used: Test MIPv6 handoff performance with the mixed link layer technologies (combination of Wi-Fi, WiMAX and LTE) case, multiple mobile node case, and multiple correspondent node case.

= Deliverables and Plan =
=== Deliverables: ===

-a basic MIPv6 module, aligned with RFC 6275 following ns-3 coding styles;

-a reviewed patch, fixing the IPv6 support issue in LTE;

-proper documentation and tests for the above-mentioned components.

=== Plan: ===

==== May 4 – May 29 (Before the official coding time): ====

-Familiarize myself completely with MIPv6, LTE (the IPv4 part), and the respective interactions.

-Study of the customized files of ns-3 lte and internet modules

-Familiarize myself with the ns-3 coding styles

During this period I will remain in constant touch with my mentor and the ns-3 community. I will remain active on IRC and Mailing lists to discuss and finalize on the modifications (if any) that needs to be on existing models and design of new module (if needed to fit cleanly with ns-3)

Thus with the help of my mentor I will become absolutely clear about my future goals, the final MIPv6 implementation that need to be done as well as the approach that I will follow to support IPv6 in lte model.

==== May 30 – June 26 (Official coding period starts): ====

-Refactor previous MIPv6 headers to RFC compliance header files

-Refactor all the classes to implement the corresponding header file functions

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the newly implemented MIPv6 module in various testing scenarios. The testing will be done with the systems having Wi-Fi and WiMAX link layer technology

-Sending the code for code review to the ns-3 team

After this stage, the standard ns-3 code revision can be started for the MIPv6 code part. Any change requested by the reviewers will be carried out in parallel with the following activities.

==== June 27 – July 24: ====

-Define new or, modify existing header files and cc files in LTE module in such a way that LTE module remains backward compatible with IPv4

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the LTE module

-Sending the code for code review to the ns-3 team

This will help in testing of the LTE module with IPv6 support for possible merge into the project main tree.

==== July 25 – August 21: ====

-Making further changes in the LTE module to support MIPv6 into it. Changes may be required in the other modules of ns-3 also.

-Testing the overall working in the testing scenarios having the combination of Wi-Fi and LTE

-Most of the time will be consumed for rigorous testing and bug fixes.

-Sending the code for code review to the ns-3 team

-Documentation updates.

= Weekly Reports =

=== May 30 - June 6 ===

1. Restructuring the MIPv6 code.

2. Testing the code in the multiple Mobile Node case

3. Changing the Home Agent functionality a little bit

4. Arise Tunnel Implementation Issue [how mobile node would use its home address for all of its data communication]

=== June 7 - June 13 ===

1. Resolved the issue of home address assignment to mobile node for all of its data communication. So, I have made some tricky callbacks in the L4 protocol a little bit. Now, traffic can be directed in both direction i.e. Mobile node to a web server and a web server to a mobile node

2. Also delete a lot of unnecessary files as well as lines in the code.

3. Tests have been done changing the location of different mobility entities. Almost all are successful. Those are included in "mipv6-test1-4.cc" in scratch of https://github.com/manoj24rana/MobileIPv6.

=== June 14 - June 20 ===

1. Done more tests

2. Add some more features such as defending home address and performing NS handling at HA as described in RFC 6275

3. Find an issue on RFC 6275 i.e. how to defend the mobile node's home address by home agent when it returns to its home network. Try to do something on the basis of ns-3 ipv6 implementation to resolve the issue.

=== June 21 - June 27 ===

1. Documentation on how my implementation differs from RFC 6275 as well as

2. Resolve the above issue

3. Sending the code for review.

=== June 28 - July 04 ===

1. Starting LTE IPv6 implementation part: understanding the end-to-end IPv4 part between UE and remote host, decoding it and discuss with my mentor for changing

2. Start writing code, at least one class modification

3. Test the change whether it is right.

=== July 05 - July 11 ===

1. Complete the modification in the lte module classes and also develop a small IPv6 dealing program to test

2. An issue arise i.e. Address Collision occurs at file: file=../src/internet/model/
ipv6-address-generator.cc, line=484". I am trying to resolve it.

3. Runs the previous IPv4 sample programs, which runs fine.

=== July 12 - July 18 ===

1. Resolve the IPv6 address collision issue in the LTE IPv6 support part.

2. I face another issue on handling multicast packets between UE sets and pgw i.e. those multicast packets are not passed between them as in the middle there is an enb.

3. Add the Sphinx documentation in the mipv6 module.

4. The Attributes and TraceSources are uploaded in mipv6 git.

=== July 19 - July 25 ===

1. Making some examples for the main mipv6 repo.

2. Add two tests in the main mipv6 repo.

3. mipv6 doc file further update.

4. Add and change tracesources and some functionalities in mipv6 model.

=== July 26 - August 1 ===

Finalize the MIPv6 code for review. I have added two nice tests replacing the previous tests, further update the mipv6 doc, trace sources, attributes, examples.
The codes are documented highly. Now the /doc/models/build/html dir contains the model documentation and the /doc/html creates doxygen for the mipv6 module.

=== August 2 - August 15 ===

1. Sent the MIPv6 code for review.

2. Solved LTE IPv6 packet sending issues.

3. Complete LTE IPv6 part, i.e. IPv6 packets are received and sent correctly.

4. Discuss with my mentor (Tommaso) elaborately about the next steps such that this implementation could be rebased in the main ns-3 dev quickly.

=== August 16 - August 22 ===

1. Update the LTE UE and PGW address assignment process in such a way that all IP addresses assigned by an EPC are derived from a base prefix (8 for IPv4 and 32 for IPv6) and each EPC holds a unique 16 bit IPv4 and 48 bit IPv6 subnet prefix to assign addresses to PGW and UEs. This address assignment process is made by keeping in mind the issues stated in https://www.nsnam.org/bugzilla/show_bug.cgi?id=1745 and https://groups.google.com/forum/#!topic/ns-3-users/Tc3IKky1OKo. So, now address duplication would not happen in case of more than one EPC as well as any time we could assign addresses without initializing the address helper. Also, user is given the flexibility to reassign the base 8 or, 32 bit address prefix at any time.

2. The LTE module is updated by IPv6 tests, documentation and examples. So, now the sample program is running and users can use them.

=== August 23 - August 29 ===

1. Submit the Google Work Product.

2. Send the LTE Code for review.

3. Try to resolve the reviewer's comment.

= Final Report for Google =
It has been an outstanding experience for me, spending this summer for GSoC project. I gave my full effort to make a very successful GSoC project and so, involved myself almost entirely. The huge interest from the current ns-3 users about my project speeds up the work process, which I have enjoyed most. I have learned a lot of things during this summer. Working for a community like ns-3 polishes my coding networking and communication skills a lot.

This final report contains all the links to all the works done over the summer. There have been almost 11,000 lines with 126 commits contributed in my github repo this summer.

=== Work Product Link ===

This is the complete work product link with full ns-3.25 software:

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6

My contribution:

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/commit/7164250819b85ec2461e4c20667a516720eeddd5

=== Installation and Running the Work Product ===

1. Depending on your OS, install the ns-3 Prerequisites from this link: https://www.nsnam.org/wiki/Installation#Prerequisites.

2. Download the code from this repository: https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6 and extract it.

3. Make sure that you have installed all the perquisites to install ns-3.25.

4. Run the following commands in your cmd prompt to install it:

$ cd The_Project_Folder

$ cd ns-3.25

$ ./waf -d debug --enable-examples --enable-tests configure

$ ./waf

5. Running MIPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running MIPv6: mipv6-multiple.cc, mipv6-single.cc and mipv6-wifi-wimax.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run mipv6-multiple --vis

This will open a visualizer to see the output and the packet transmission in the background cmd prompt.

6. Running LTE IPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running LTE IPv6: lena-ipv6-ue-rh.cc, lena-ipv6-ue-ue.cc and lena-ipv6-addr-conf.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run lena-ipv6-ue-ue --vis

This will open a visualizer to see the output and the packet transmission in the background cmd prompt.

=== Documentation ===

Either, you follow the prepared documentation,

For MIPv6,

https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing

For LTE IPv6,

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/blob/master/ns-3.25/src/lte/doc/source/lte-design.rst and
https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/blob/master/ns-3.25/src/lte/doc/source/lte-user.rst

or, you could follow the manual for Creating Documentation here: https://www.nsnam.org/docs/manual/html/documentation.html. I have added the appropriate documentations within the code of the above repo of my implementation.

=== Work Flow ===

The following link will describe the weekly update of this project.

https://www.nsnam.org/wiki/GSOC2017MobileIp#Weekly_Reports

The flow of commits in the code could be found in the following link.

https://github.com/manoj24rana/MobileIPv6

=== Other Issues Resolved ===

I have resolved several other issues in ns-3 during this period as a part of my main implementation. Briefly, these are as follows.

1. Lack of IPv6 support for WiMAX module.

2. Duplicate IPv4 address collision problem in LTE module (https://groups.google.com/forum/#!topic/ns-3-users/Tc3IKky1OKo).

=== Future Enhancement for this Project ===

1. Creating some LTE samples which can run multiple LTE networks in single user's simulation script. It requires cooperation with the existing LTE maintainers in ns-3.

2. Add more options for mobility management. The actual code always switches to the "newest" network. More sophisticated approaches can be tested, like QoS measures and make-before-break.

3. Above all, the beauty of this project is that it is the implementation of the base IP mobility management protocol (MIPv6) in ns-3. The ns-3 users now can easily extend this feature to implement other such protocols, such as NEMO (RFC 3963), PMIPv6 (RFC 5213) etc. and also some upcoming schemes in 5G.

GSOC2017MobileIp

2017-08-29T06:34:31Z

Mkrana: /* Final Report for Google */

{{TOC}}

Return to [[GSOC2017AcceptedProjects | GSoC 2017 Accepted Projects]] page.

= Project overview =

* '''Project name:''' Mobile IPv6 Implementation with LTE support

* '''Student:''' [mailto:manoj24.rana@gmail.com Manoj Kumar Rana]

* '''Mentor:''' [mailto:tommypec@gmail.com Tommaso Pecorella]

* '''Abstract:''' The goal of the project is to implement a novel MIPv6 simulation model which can be integrated into ns-3. The project idea aims at testing the code in different network scenarios, containing different link layer technologies such as Wi-Fi, WiMAX and LTE. The current implementation of LTE does not have support of IPv6 in ns-3. So, the idea of testing MIPv6 code into LTE would follow IPv6 support implementation in LTE first and then the MIPv6 support. Thus, implementation of MIPv6 in ns-3 as the base mobility management solution and providing LTE support within it could help the current network researchers working on ns-3.

* '''Code:''' https://github.com/manoj24rana/MobileIPv6

* '''Documentation:'''
# Detail Description about the Implementation: http://www.sciencedirect.com/science/article/pii/S1569190X16302714
# Phase1 Documentation: https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing
# Phase2 Documentation: https://drive.google.com/open?id=0BziHE2fNAdZRbUZKN01Bd1Rjdk0

* '''About me:''' I am a PhD student in the School of Mobile Computing and Communications, Jadavpur University, India. About my research is given here: http://scholar.google.com/citations?user=qouvajAAAAAJ&hl=en.

= Technical Approach =
*'''First,''' I want to restructure the MIPv6 code, published in http://www.sciencedirect.com/science/article/pii/S1569190X16302714, to make it RFC 6275 compliance. To do the restructuring complete, the following approaches will be performed:
#Code refactoring: reorganizing internetstack, helper and header components of the MIPv6 module through modifying the internal functions, attributes and the callback variables.
#Code analysis: both static and dynamic analysis could be performed. The waf tool for code run, PyViz for visualization and tcpdump for pcap tracing could be used.
#Functional tests: The functional test would be performed in three phase: handoff performance testing, data packet transmission testing and both. Use cases like multiple mobile nodes, multiple correspondent node, different mobility model for the mobile node as well as heterogeneous link layer technologies (Wi-Fi and WiMAX) could be used.
#The code will be sent for the code review to the ns-3 team.
* '''Second,''' IPV6 support for LTE would be ensured as LTE currently, only supports IPv4. The changes would possibly be done within the LTE module files (both .cc and .h) like point-topoint-helper, emu-epc-helper, lte-ue-net-device, epc-sgw-pgw-application, epc-enb-application, lte-enb-net-device etc. Then, the code analysis will be performed as done previously for MIPv6 code. The functional tests would follow bidirectional IPv6 packet transmission between remote host and the UE. The modification/rewriting code will create a patch that could enable IPv6 forwarding in the LTE data plane, enabling the UE to receive and use a /64 prefix, as stated in the standard. It is worth noticing that IP packets are tunnelled in the `core' network (i.e., all the EPC part), and their actual IP address is not used for UE identification in the core. As a consequence, IPv6 use in the `core' network, using ULAs or link-local addresses, could be planned if the previous development is faster than foreseen. This modification could also be simpler than expected, as it is not important to keep a dual stack communication in the core network, and using only IPv6 brings some direct benefits (like simplifying the use of multiple EPCs in a single script).
* '''Third,''' To ensure the code quality, the following testing approach could be used: Test MIPv6 handoff performance with the mixed link layer technologies (combination of Wi-Fi, WiMAX and LTE) case, multiple mobile node case, and multiple correspondent node case.

= Deliverables and Plan =
=== Deliverables: ===

-a basic MIPv6 module, aligned with RFC 6275 following ns-3 coding styles;

-a reviewed patch, fixing the IPv6 support issue in LTE;

-proper documentation and tests for the above-mentioned components.

=== Plan: ===

==== May 4 – May 29 (Before the official coding time): ====

-Familiarize myself completely with MIPv6, LTE (the IPv4 part), and the respective interactions.

-Study of the customized files of ns-3 lte and internet modules

-Familiarize myself with the ns-3 coding styles

During this period I will remain in constant touch with my mentor and the ns-3 community. I will remain active on IRC and Mailing lists to discuss and finalize on the modifications (if any) that needs to be on existing models and design of new module (if needed to fit cleanly with ns-3)

Thus with the help of my mentor I will become absolutely clear about my future goals, the final MIPv6 implementation that need to be done as well as the approach that I will follow to support IPv6 in lte model.

==== May 30 – June 26 (Official coding period starts): ====

-Refactor previous MIPv6 headers to RFC compliance header files

-Refactor all the classes to implement the corresponding header file functions

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the newly implemented MIPv6 module in various testing scenarios. The testing will be done with the systems having Wi-Fi and WiMAX link layer technology

-Sending the code for code review to the ns-3 team

After this stage, the standard ns-3 code revision can be started for the MIPv6 code part. Any change requested by the reviewers will be carried out in parallel with the following activities.

==== June 27 – July 24: ====

-Define new or, modify existing header files and cc files in LTE module in such a way that LTE module remains backward compatible with IPv4

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the LTE module

-Sending the code for code review to the ns-3 team

This will help in testing of the LTE module with IPv6 support for possible merge into the project main tree.

==== July 25 – August 21: ====

-Making further changes in the LTE module to support MIPv6 into it. Changes may be required in the other modules of ns-3 also.

-Testing the overall working in the testing scenarios having the combination of Wi-Fi and LTE

-Most of the time will be consumed for rigorous testing and bug fixes.

-Sending the code for code review to the ns-3 team

-Documentation updates.

= Weekly Reports =

=== May 30 - June 6 ===

1. Restructuring the MIPv6 code.

2. Testing the code in the multiple Mobile Node case

3. Changing the Home Agent functionality a little bit

4. Arise Tunnel Implementation Issue [how mobile node would use its home address for all of its data communication]

=== June 7 - June 13 ===

1. Resolved the issue of home address assignment to mobile node for all of its data communication. So, I have made some tricky callbacks in the L4 protocol a little bit. Now, traffic can be directed in both direction i.e. Mobile node to a web server and a web server to a mobile node

2. Also delete a lot of unnecessary files as well as lines in the code.

3. Tests have been done changing the location of different mobility entities. Almost all are successful. Those are included in "mipv6-test1-4.cc" in scratch of https://github.com/manoj24rana/MobileIPv6.

=== June 14 - June 20 ===

1. Done more tests

2. Add some more features such as defending home address and performing NS handling at HA as described in RFC 6275

3. Find an issue on RFC 6275 i.e. how to defend the mobile node's home address by home agent when it returns to its home network. Try to do something on the basis of ns-3 ipv6 implementation to resolve the issue.

=== June 21 - June 27 ===

1. Documentation on how my implementation differs from RFC 6275 as well as

2. Resolve the above issue

3. Sending the code for review.

=== June 28 - July 04 ===

1. Starting LTE IPv6 implementation part: understanding the end-to-end IPv4 part between UE and remote host, decoding it and discuss with my mentor for changing

2. Start writing code, at least one class modification

3. Test the change whether it is right.

=== July 05 - July 11 ===

1. Complete the modification in the lte module classes and also develop a small IPv6 dealing program to test

2. An issue arise i.e. Address Collision occurs at file: file=../src/internet/model/
ipv6-address-generator.cc, line=484". I am trying to resolve it.

3. Runs the previous IPv4 sample programs, which runs fine.

=== July 12 - July 18 ===

1. Resolve the IPv6 address collision issue in the LTE IPv6 support part.

2. I face another issue on handling multicast packets between UE sets and pgw i.e. those multicast packets are not passed between them as in the middle there is an enb.

3. Add the Sphinx documentation in the mipv6 module.

4. The Attributes and TraceSources are uploaded in mipv6 git.

=== July 19 - July 25 ===

1. Making some examples for the main mipv6 repo.

2. Add two tests in the main mipv6 repo.

3. mipv6 doc file further update.

4. Add and change tracesources and some functionalities in mipv6 model.

=== July 26 - August 1 ===

Finalize the MIPv6 code for review. I have added two nice tests replacing the previous tests, further update the mipv6 doc, trace sources, attributes, examples.
The codes are documented highly. Now the /doc/models/build/html dir contains the model documentation and the /doc/html creates doxygen for the mipv6 module.

=== August 2 - August 15 ===

1. Sent the MIPv6 code for review.

2. Solved LTE IPv6 packet sending issues.

3. Complete LTE IPv6 part, i.e. IPv6 packets are received and sent correctly.

4. Discuss with my mentor (Tommaso) elaborately about the next steps such that this implementation could be rebased in the main ns-3 dev quickly.

=== August 16 - August 22 ===

1. Update the LTE UE and PGW address assignment process in such a way that all IP addresses assigned by an EPC are derived from a base prefix (8 for IPv4 and 32 for IPv6) and each EPC holds a unique 16 bit IPv4 and 48 bit IPv6 subnet prefix to assign addresses to PGW and UEs. This address assignment process is made by keeping in mind the issues stated in https://www.nsnam.org/bugzilla/show_bug.cgi?id=1745 and https://groups.google.com/forum/#!topic/ns-3-users/Tc3IKky1OKo. So, now address duplication would not happen in case of more than one EPC as well as any time we could assign addresses without initializing the address helper. Also, user is given the flexibility to reassign the base 8 or, 32 bit address prefix at any time.

2. The LTE module is updated by IPv6 tests, documentation and examples. So, now the sample program is running and users can use them.

=== August 23 - August 29 ===

1. Submit the Google Work Product.

2. Send the LTE Code for review.

3. Try to resolve the reviewer's comment.

= Final Report for Google =
It has been an outstanding experience for me, spending this summer for GSoC project. I gave my full effort to make a very successful GSoC project and so, involved myself almost entirely. The huge interest from the current ns-3 users about my project speeds up the work process, which I have enjoyed most. I have learned a lot of things during this summer. Working for a community like ns-3 polishes my coding networking and communication skills a lot.

This final report contains all the links to all the works done over the summer. There have been total 11,000 lines with 126 commits contributed in my github repo this summer.

=== Work Product Link ===

This is the complete work product link with full ns-3.25 software:

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6

My contribution:

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/commit/7164250819b85ec2461e4c20667a516720eeddd5

=== Installation and Running the Work Product ===

1. Depending on your OS, install the ns-3 Prerequisites from this link: https://www.nsnam.org/wiki/Installation#Prerequisites.

2. Download the code from this repository: https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6 and extract it.

3. Make sure that you have installed all the perquisites to install ns-3.25.

4. Run the following commands in your cmd prompt to install it:

$ cd The_Project_Folder

$ cd ns-3.25

$ ./waf -d debug --enable-examples --enable-tests configure

$ ./waf

5. Running MIPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running MIPv6: mipv6-multiple.cc, mipv6-single.cc and mipv6-wifi-wimax.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run mipv6-multiple --vis

This will open a visualizer to see the output and the packet transmission in the background cmd prompt.

6. Running LTE IPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running LTE IPv6: lena-ipv6-ue-rh.cc, lena-ipv6-ue-ue.cc and lena-ipv6-addr-conf.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run lena-ipv6-ue-ue --vis

This will open a visualizer to see the output and the packet transmission in the background cmd prompt.

=== Documentation ===

Either, you follow the prepared documentation,

For MIPv6,

https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing

For LTE IPv6,

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/blob/master/ns-3.25/src/lte/doc/source/lte-design.rst and
https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/blob/master/ns-3.25/src/lte/doc/source/lte-user.rst

or, you could follow the manual for Creating Documentation here: https://www.nsnam.org/docs/manual/html/documentation.html. I have added the appropriate documentations within the code of the above repo of my implementation.

=== Work Flow ===

The following link will describe the weekly update of this project.

https://www.nsnam.org/wiki/GSOC2017MobileIp#Weekly_Reports

The flow of commits in the code could be found in the following link.

https://github.com/manoj24rana/MobileIPv6

=== Other Issues Resolved ===

I have resolved several other issues in ns-3 during this period as a part of my main implementation. Briefly, these are as follows.

1. Lack of IPv6 support for WiMAX module.

2. Duplicate IPv4 address collision problem in LTE module (https://groups.google.com/forum/#!topic/ns-3-users/Tc3IKky1OKo).

=== Future Enhancement for this Project ===

1. Creating some LTE samples which can run multiple LTE networks in single user's simulation script. It requires cooperation with the existing LTE maintainers in ns-3.

2. Add more options for mobility management. The actual code always switches to the "newest" network. More sophisticated approaches can be tested, like QoS measures and make-before-break.

3. Above all, the beauty of this project is that it is the implementation of the base IP mobility management protocol (MIPv6) in ns-3. The ns-3 users now can easily extend this feature to implement other such protocols, such as NEMO (RFC 3963), PMIPv6 (RFC 5213) etc. and also some upcoming schemes in 5G.

GSOC2017MobileIp

2017-08-29T05:57:19Z

Mkrana: /* Final Report for Google */

{{TOC}}

Return to [[GSOC2017AcceptedProjects | GSoC 2017 Accepted Projects]] page.

= Project overview =

* '''Project name:''' Mobile IPv6 Implementation with LTE support

* '''Student:''' [mailto:manoj24.rana@gmail.com Manoj Kumar Rana]

* '''Mentor:''' [mailto:tommypec@gmail.com Tommaso Pecorella]

* '''Abstract:''' The goal of the project is to implement a novel MIPv6 simulation model which can be integrated into ns-3. The project idea aims at testing the code in different network scenarios, containing different link layer technologies such as Wi-Fi, WiMAX and LTE. The current implementation of LTE does not have support of IPv6 in ns-3. So, the idea of testing MIPv6 code into LTE would follow IPv6 support implementation in LTE first and then the MIPv6 support. Thus, implementation of MIPv6 in ns-3 as the base mobility management solution and providing LTE support within it could help the current network researchers working on ns-3.

* '''Code:''' https://github.com/manoj24rana/MobileIPv6

* '''Documentation:'''
# Detail Description about the Implementation: http://www.sciencedirect.com/science/article/pii/S1569190X16302714
# Phase1 Documentation: https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing
# Phase2 Documentation: https://drive.google.com/open?id=0BziHE2fNAdZRbUZKN01Bd1Rjdk0

* '''About me:''' I am a PhD student in the School of Mobile Computing and Communications, Jadavpur University, India. About my research is given here: http://scholar.google.com/citations?user=qouvajAAAAAJ&hl=en.

= Technical Approach =
*'''First,''' I want to restructure the MIPv6 code, published in http://www.sciencedirect.com/science/article/pii/S1569190X16302714, to make it RFC 6275 compliance. To do the restructuring complete, the following approaches will be performed:
#Code refactoring: reorganizing internetstack, helper and header components of the MIPv6 module through modifying the internal functions, attributes and the callback variables.
#Code analysis: both static and dynamic analysis could be performed. The waf tool for code run, PyViz for visualization and tcpdump for pcap tracing could be used.
#Functional tests: The functional test would be performed in three phase: handoff performance testing, data packet transmission testing and both. Use cases like multiple mobile nodes, multiple correspondent node, different mobility model for the mobile node as well as heterogeneous link layer technologies (Wi-Fi and WiMAX) could be used.
#The code will be sent for the code review to the ns-3 team.
* '''Second,''' IPV6 support for LTE would be ensured as LTE currently, only supports IPv4. The changes would possibly be done within the LTE module files (both .cc and .h) like point-topoint-helper, emu-epc-helper, lte-ue-net-device, epc-sgw-pgw-application, epc-enb-application, lte-enb-net-device etc. Then, the code analysis will be performed as done previously for MIPv6 code. The functional tests would follow bidirectional IPv6 packet transmission between remote host and the UE. The modification/rewriting code will create a patch that could enable IPv6 forwarding in the LTE data plane, enabling the UE to receive and use a /64 prefix, as stated in the standard. It is worth noticing that IP packets are tunnelled in the `core' network (i.e., all the EPC part), and their actual IP address is not used for UE identification in the core. As a consequence, IPv6 use in the `core' network, using ULAs or link-local addresses, could be planned if the previous development is faster than foreseen. This modification could also be simpler than expected, as it is not important to keep a dual stack communication in the core network, and using only IPv6 brings some direct benefits (like simplifying the use of multiple EPCs in a single script).
* '''Third,''' To ensure the code quality, the following testing approach could be used: Test MIPv6 handoff performance with the mixed link layer technologies (combination of Wi-Fi, WiMAX and LTE) case, multiple mobile node case, and multiple correspondent node case.

= Deliverables and Plan =
=== Deliverables: ===

-a basic MIPv6 module, aligned with RFC 6275 following ns-3 coding styles;

-a reviewed patch, fixing the IPv6 support issue in LTE;

-proper documentation and tests for the above-mentioned components.

=== Plan: ===

==== May 4 – May 29 (Before the official coding time): ====

-Familiarize myself completely with MIPv6, LTE (the IPv4 part), and the respective interactions.

-Study of the customized files of ns-3 lte and internet modules

-Familiarize myself with the ns-3 coding styles

During this period I will remain in constant touch with my mentor and the ns-3 community. I will remain active on IRC and Mailing lists to discuss and finalize on the modifications (if any) that needs to be on existing models and design of new module (if needed to fit cleanly with ns-3)

Thus with the help of my mentor I will become absolutely clear about my future goals, the final MIPv6 implementation that need to be done as well as the approach that I will follow to support IPv6 in lte model.

==== May 30 – June 26 (Official coding period starts): ====

-Refactor previous MIPv6 headers to RFC compliance header files

-Refactor all the classes to implement the corresponding header file functions

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the newly implemented MIPv6 module in various testing scenarios. The testing will be done with the systems having Wi-Fi and WiMAX link layer technology

-Sending the code for code review to the ns-3 team

After this stage, the standard ns-3 code revision can be started for the MIPv6 code part. Any change requested by the reviewers will be carried out in parallel with the following activities.

==== June 27 – July 24: ====

-Define new or, modify existing header files and cc files in LTE module in such a way that LTE module remains backward compatible with IPv4

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the LTE module

-Sending the code for code review to the ns-3 team

This will help in testing of the LTE module with IPv6 support for possible merge into the project main tree.

==== July 25 – August 21: ====

-Making further changes in the LTE module to support MIPv6 into it. Changes may be required in the other modules of ns-3 also.

-Testing the overall working in the testing scenarios having the combination of Wi-Fi and LTE

-Most of the time will be consumed for rigorous testing and bug fixes.

-Sending the code for code review to the ns-3 team

-Documentation updates.

= Weekly Reports =

=== May 30 - June 6 ===

1. Restructuring the MIPv6 code.

2. Testing the code in the multiple Mobile Node case

3. Changing the Home Agent functionality a little bit

4. Arise Tunnel Implementation Issue [how mobile node would use its home address for all of its data communication]

=== June 7 - June 13 ===

1. Resolved the issue of home address assignment to mobile node for all of its data communication. So, I have made some tricky callbacks in the L4 protocol a little bit. Now, traffic can be directed in both direction i.e. Mobile node to a web server and a web server to a mobile node

2. Also delete a lot of unnecessary files as well as lines in the code.

3. Tests have been done changing the location of different mobility entities. Almost all are successful. Those are included in "mipv6-test1-4.cc" in scratch of https://github.com/manoj24rana/MobileIPv6.

=== June 14 - June 20 ===

1. Done more tests

2. Add some more features such as defending home address and performing NS handling at HA as described in RFC 6275

3. Find an issue on RFC 6275 i.e. how to defend the mobile node's home address by home agent when it returns to its home network. Try to do something on the basis of ns-3 ipv6 implementation to resolve the issue.

=== June 21 - June 27 ===

1. Documentation on how my implementation differs from RFC 6275 as well as

2. Resolve the above issue

3. Sending the code for review.

=== June 28 - July 04 ===

1. Starting LTE IPv6 implementation part: understanding the end-to-end IPv4 part between UE and remote host, decoding it and discuss with my mentor for changing

2. Start writing code, at least one class modification

3. Test the change whether it is right.

=== July 05 - July 11 ===

1. Complete the modification in the lte module classes and also develop a small IPv6 dealing program to test

2. An issue arise i.e. Address Collision occurs at file: file=../src/internet/model/
ipv6-address-generator.cc, line=484". I am trying to resolve it.

3. Runs the previous IPv4 sample programs, which runs fine.

=== July 12 - July 18 ===

1. Resolve the IPv6 address collision issue in the LTE IPv6 support part.

2. I face another issue on handling multicast packets between UE sets and pgw i.e. those multicast packets are not passed between them as in the middle there is an enb.

3. Add the Sphinx documentation in the mipv6 module.

4. The Attributes and TraceSources are uploaded in mipv6 git.

=== July 19 - July 25 ===

1. Making some examples for the main mipv6 repo.

2. Add two tests in the main mipv6 repo.

3. mipv6 doc file further update.

4. Add and change tracesources and some functionalities in mipv6 model.

=== July 26 - August 1 ===

Finalize the MIPv6 code for review. I have added two nice tests replacing the previous tests, further update the mipv6 doc, trace sources, attributes, examples.
The codes are documented highly. Now the /doc/models/build/html dir contains the model documentation and the /doc/html creates doxygen for the mipv6 module.

=== August 2 - August 15 ===

1. Sent the MIPv6 code for review.

2. Solved LTE IPv6 packet sending issues.

3. Complete LTE IPv6 part, i.e. IPv6 packets are received and sent correctly.

4. Discuss with my mentor (Tommaso) elaborately about the next steps such that this implementation could be rebased in the main ns-3 dev quickly.

=== August 16 - August 22 ===

1. Update the LTE UE and PGW address assignment process in such a way that all IP addresses assigned by an EPC are derived from a base prefix (8 for IPv4 and 32 for IPv6) and each EPC holds a unique 16 bit IPv4 and 48 bit IPv6 subnet prefix to assign addresses to PGW and UEs. This address assignment process is made by keeping in mind the issues stated in https://www.nsnam.org/bugzilla/show_bug.cgi?id=1745 and https://groups.google.com/forum/#!topic/ns-3-users/Tc3IKky1OKo. So, now address duplication would not happen in case of more than one EPC as well as any time we could assign addresses without initializing the address helper. Also, user is given the flexibility to reassign the base 8 or, 32 bit address prefix at any time.

2. The LTE module is updated by IPv6 tests, documentation and examples. So, now the sample program is running and users can use them.

=== August 23 - August 29 ===

1. Submit the Google Work Product.

2. Send the LTE Code for review.

3. Try to resolve the reviewer's comment.

= Final Report for Google =
It has been an outstanding experience for me, spending this summer for GSoC project. I gave my full effort to make a very successful GSoC project and so, involved myself almost entirely. The huge interest from the current ns-3 users about my project speeds up the work process, which I have enjoyed most. I have learned a lot of things during this summer. Working for a community like ns-3 polishes my coding networking and communication skills a lot.

This final report contains all the links to all the works done over the summer. There have been total 10,000 lines of code with 144 commits contributed in my github repo.

=== Work Product Link ===

This is the complete work product link with full ns-3.25 software:

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6

My contribution:

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/commit/7164250819b85ec2461e4c20667a516720eeddd5

=== Installation and Running the Work Product ===

1. Depending on your OS, install the ns-3 Prerequisites from this link: https://www.nsnam.org/wiki/Installation#Prerequisites.

2. Download the code from this repository: https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6 and extract it.

3. Make sure that you have installed all the perquisites to install ns-3.25.

4. Run the following commands in your cmd prompt to install it:

$ cd The_Project_Folder

$ cd ns-3.25

$ ./waf -d debug --enable-examples --enable-tests configure

$ ./waf

5. Running MIPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running MIPv6: mipv6-multiple.cc, mipv6-single.cc and mipv6-wifi-wimax.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run mipv6-multiple --vis

This will open a visualizer to see the output and the packet transmission in the background cmd prompt.

6. Running LTE IPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running LTE IPv6: lena-ipv6-ue-rh.cc, lena-ipv6-ue-ue.cc and lena-ipv6-addr-conf.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run lena-ipv6-ue-ue --vis

This will open a visualizer to see the output and the packet transmission in the background cmd prompt.

=== Documentation ===

Either, you follow the prepared documentation,

For MIPv6,

https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing

For LTE IPv6,

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/blob/master/ns-3.25/src/lte/doc/source/lte-design.rst and
https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/blob/master/ns-3.25/src/lte/doc/source/lte-user.rst

or, you could follow the manual for Creating Documentation here: https://www.nsnam.org/docs/manual/html/documentation.html. I have added the appropriate documentations within the code of the above repo of my implementation.

=== Work Flow ===

The following link will describe the weekly update of this project.

https://www.nsnam.org/wiki/GSOC2017MobileIp#Weekly_Reports

The flow of commits in the code could be found in the following link.

https://github.com/manoj24rana/MobileIPv6

=== Other Issues Resolved ===

I have resolved several other issues in ns-3 during this period as a part of my main implementation. Briefly, these are as follows.

1. Lack of IPv6 support for WiMAX module.

2. Duplicate IPv4 address collision problem in LTE module (https://groups.google.com/forum/#!topic/ns-3-users/Tc3IKky1OKo).

=== Future Enhancement for this Project ===

1. Creating some LTE samples which can run multiple LTE networks in single user's simulation script. It requires cooperation with the existing LTE maintainers in ns-3.

2. Add more options for mobility management. The actual code always switches to the "newest" network. More sophisticated approaches can be tested, like QoS measures and make-before-break.

3. Above all, the beauty of this project is that it is the implementation of the base IP mobility management protocol (MIPv6) in ns-3. The ns-3 users now can easily extend this feature to implement other such protocols, such as NEMO (RFC 3963), PMIPv6 (RFC 5213) etc. and also some upcoming schemes in 5G.

GSOC2017MobileIp

2017-08-28T15:56:04Z

Mkrana: /* Other Issues Resolved */

{{TOC}}

Return to [[GSOC2017AcceptedProjects | GSoC 2017 Accepted Projects]] page.

= Project overview =

* '''Project name:''' Mobile IPv6 Implementation with LTE support

* '''Student:''' [mailto:manoj24.rana@gmail.com Manoj Kumar Rana]

* '''Mentor:''' [mailto:tommypec@gmail.com Tommaso Pecorella]

* '''Abstract:''' The goal of the project is to implement a novel MIPv6 simulation model which can be integrated into ns-3. The project idea aims at testing the code in different network scenarios, containing different link layer technologies such as Wi-Fi, WiMAX and LTE. The current implementation of LTE does not have support of IPv6 in ns-3. So, the idea of testing MIPv6 code into LTE would follow IPv6 support implementation in LTE first and then the MIPv6 support. Thus, implementation of MIPv6 in ns-3 as the base mobility management solution and providing LTE support within it could help the current network researchers working on ns-3.

* '''Code:''' https://github.com/manoj24rana/MobileIPv6

* '''Documentation:'''
# Detail Description about the Implementation: http://www.sciencedirect.com/science/article/pii/S1569190X16302714
# Phase1 Documentation: https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing
# Phase2 Documentation: https://drive.google.com/open?id=0BziHE2fNAdZRbUZKN01Bd1Rjdk0

* '''About me:''' I am a PhD student in the School of Mobile Computing and Communications, Jadavpur University, India. About my research is given here: http://scholar.google.com/citations?user=qouvajAAAAAJ&hl=en.

= Technical Approach =
*'''First,''' I want to restructure the MIPv6 code, published in http://www.sciencedirect.com/science/article/pii/S1569190X16302714, to make it RFC 6275 compliance. To do the restructuring complete, the following approaches will be performed:
#Code refactoring: reorganizing internetstack, helper and header components of the MIPv6 module through modifying the internal functions, attributes and the callback variables.
#Code analysis: both static and dynamic analysis could be performed. The waf tool for code run, PyViz for visualization and tcpdump for pcap tracing could be used.
#Functional tests: The functional test would be performed in three phase: handoff performance testing, data packet transmission testing and both. Use cases like multiple mobile nodes, multiple correspondent node, different mobility model for the mobile node as well as heterogeneous link layer technologies (Wi-Fi and WiMAX) could be used.
#The code will be sent for the code review to the ns-3 team.
* '''Second,''' IPV6 support for LTE would be ensured as LTE currently, only supports IPv4. The changes would possibly be done within the LTE module files (both .cc and .h) like point-topoint-helper, emu-epc-helper, lte-ue-net-device, epc-sgw-pgw-application, epc-enb-application, lte-enb-net-device etc. Then, the code analysis will be performed as done previously for MIPv6 code. The functional tests would follow bidirectional IPv6 packet transmission between remote host and the UE. The modification/rewriting code will create a patch that could enable IPv6 forwarding in the LTE data plane, enabling the UE to receive and use a /64 prefix, as stated in the standard. It is worth noticing that IP packets are tunnelled in the `core' network (i.e., all the EPC part), and their actual IP address is not used for UE identification in the core. As a consequence, IPv6 use in the `core' network, using ULAs or link-local addresses, could be planned if the previous development is faster than foreseen. This modification could also be simpler than expected, as it is not important to keep a dual stack communication in the core network, and using only IPv6 brings some direct benefits (like simplifying the use of multiple EPCs in a single script).
* '''Third,''' To ensure the code quality, the following testing approach could be used: Test MIPv6 handoff performance with the mixed link layer technologies (combination of Wi-Fi, WiMAX and LTE) case, multiple mobile node case, and multiple correspondent node case.

= Deliverables and Plan =
=== Deliverables: ===

-a basic MIPv6 module, aligned with RFC 6275 following ns-3 coding styles;

-a reviewed patch, fixing the IPv6 support issue in LTE;

-proper documentation and tests for the above-mentioned components.

=== Plan: ===

==== May 4 – May 29 (Before the official coding time): ====

-Familiarize myself completely with MIPv6, LTE (the IPv4 part), and the respective interactions.

-Study of the customized files of ns-3 lte and internet modules

-Familiarize myself with the ns-3 coding styles

During this period I will remain in constant touch with my mentor and the ns-3 community. I will remain active on IRC and Mailing lists to discuss and finalize on the modifications (if any) that needs to be on existing models and design of new module (if needed to fit cleanly with ns-3)

Thus with the help of my mentor I will become absolutely clear about my future goals, the final MIPv6 implementation that need to be done as well as the approach that I will follow to support IPv6 in lte model.

==== May 30 – June 26 (Official coding period starts): ====

-Refactor previous MIPv6 headers to RFC compliance header files

-Refactor all the classes to implement the corresponding header file functions

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the newly implemented MIPv6 module in various testing scenarios. The testing will be done with the systems having Wi-Fi and WiMAX link layer technology

-Sending the code for code review to the ns-3 team

After this stage, the standard ns-3 code revision can be started for the MIPv6 code part. Any change requested by the reviewers will be carried out in parallel with the following activities.

==== June 27 – July 24: ====

-Define new or, modify existing header files and cc files in LTE module in such a way that LTE module remains backward compatible with IPv4

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the LTE module

-Sending the code for code review to the ns-3 team

This will help in testing of the LTE module with IPv6 support for possible merge into the project main tree.

==== July 25 – August 21: ====

-Making further changes in the LTE module to support MIPv6 into it. Changes may be required in the other modules of ns-3 also.

-Testing the overall working in the testing scenarios having the combination of Wi-Fi and LTE

-Most of the time will be consumed for rigorous testing and bug fixes.

-Sending the code for code review to the ns-3 team

-Documentation updates.

= Weekly Reports =

=== May 30 - June 6 ===

1. Restructuring the MIPv6 code.

2. Testing the code in the multiple Mobile Node case

3. Changing the Home Agent functionality a little bit

4. Arise Tunnel Implementation Issue [how mobile node would use its home address for all of its data communication]

=== June 7 - June 13 ===

1. Resolved the issue of home address assignment to mobile node for all of its data communication. So, I have made some tricky callbacks in the L4 protocol a little bit. Now, traffic can be directed in both direction i.e. Mobile node to a web server and a web server to a mobile node

2. Also delete a lot of unnecessary files as well as lines in the code.

3. Tests have been done changing the location of different mobility entities. Almost all are successful. Those are included in "mipv6-test1-4.cc" in scratch of https://github.com/manoj24rana/MobileIPv6.

=== June 14 - June 20 ===

1. Done more tests

2. Add some more features such as defending home address and performing NS handling at HA as described in RFC 6275

3. Find an issue on RFC 6275 i.e. how to defend the mobile node's home address by home agent when it returns to its home network. Try to do something on the basis of ns-3 ipv6 implementation to resolve the issue.

=== June 21 - June 27 ===

1. Documentation on how my implementation differs from RFC 6275 as well as

2. Resolve the above issue

3. Sending the code for review.

=== June 28 - July 04 ===

1. Starting LTE IPv6 implementation part: understanding the end-to-end IPv4 part between UE and remote host, decoding it and discuss with my mentor for changing

2. Start writing code, at least one class modification

3. Test the change whether it is right.

=== July 05 - July 11 ===

1. Complete the modification in the lte module classes and also develop a small IPv6 dealing program to test

2. An issue arise i.e. Address Collision occurs at file: file=../src/internet/model/
ipv6-address-generator.cc, line=484". I am trying to resolve it.

3. Runs the previous IPv4 sample programs, which runs fine.

=== July 12 - July 18 ===

1. Resolve the IPv6 address collision issue in the LTE IPv6 support part.

2. I face another issue on handling multicast packets between UE sets and pgw i.e. those multicast packets are not passed between them as in the middle there is an enb.

3. Add the Sphinx documentation in the mipv6 module.

4. The Attributes and TraceSources are uploaded in mipv6 git.

=== July 19 - July 25 ===

1. Making some examples for the main mipv6 repo.

2. Add two tests in the main mipv6 repo.

3. mipv6 doc file further update.

4. Add and change tracesources and some functionalities in mipv6 model.

=== July 26 - August 1 ===

Finalize the MIPv6 code for review. I have added two nice tests replacing the previous tests, further update the mipv6 doc, trace sources, attributes, examples.
The codes are documented highly. Now the /doc/models/build/html dir contains the model documentation and the /doc/html creates doxygen for the mipv6 module.

=== August 2 - August 15 ===

1. Sent the MIPv6 code for review.

2. Solved LTE IPv6 packet sending issues.

3. Complete LTE IPv6 part, i.e. IPv6 packets are received and sent correctly.

4. Discuss with my mentor (Tommaso) elaborately about the next steps such that this implementation could be rebased in the main ns-3 dev quickly.

=== August 16 - August 22 ===

1. Update the LTE UE and PGW address assignment process in such a way that all IP addresses assigned by an EPC are derived from a base prefix (8 for IPv4 and 32 for IPv6) and each EPC holds a unique 16 bit IPv4 and 48 bit IPv6 subnet prefix to assign addresses to PGW and UEs. This address assignment process is made by keeping in mind the issues stated in https://www.nsnam.org/bugzilla/show_bug.cgi?id=1745 and https://groups.google.com/forum/#!topic/ns-3-users/Tc3IKky1OKo. So, now address duplication would not happen in case of more than one EPC as well as any time we could assign addresses without initializing the address helper. Also, user is given the flexibility to reassign the base 8 or, 32 bit address prefix at any time.

2. The LTE module is updated by IPv6 tests, documentation and examples. So, now the sample program is running and users can use them.

=== August 23 - August 29 ===

1. Submit the Google Work Product.

2. Send the LTE Code for review.

3. Try to resolve the reviewer's comment.

= Final Report for Google =
It has been an outstanding experience for me, spending this summer for GSoC project. I gave my full effort to make a very successful GSoC project and so, involve myself almost entirely. The huge interest from the current ns-3 users about my project speeds up the work what I have enjoyed most. I have learned a lot of things during this summer. First, I could do a lot more works than my expectation. Secondly, coding based on the standard theory always makes my project stuffs correct and wonderful. Third, working for a community like ns-3 polishes my coding networking and communication skills a lot.

This final report contains all the links to all the works done over the summer. There have been total 19,000 lines of code with 146 commits contributed in my github repo.

=== Work Product Link ===

This is the complete work product link with full ns-3.25 software:

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6

My contribution:

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/commit/7164250819b85ec2461e4c20667a516720eeddd5

=== Installation and Running the Work Product ===

1. Depending on your OS, install the ns-3 Prerequisites from this link: https://www.nsnam.org/wiki/Installation#Prerequisites.

2. Download the code from this repository: https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6 and extract it.

3. Make sure that you have installed all the perquisites to install ns-3.25.

4. Run the following commands in your cmd prompt to install it:

$ cd The_Project_Folder

$ cd ns-3.25

$ ./waf -d debug --enable-examples --enable-tests configure

$ ./waf

5. Running MIPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running MIPv6: mipv6-multiple.cc, mipv6-single.cc and mipv6-wifi-wimax.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run mipv6-multiple --vis

This will open a visualizer to see the output and the packet transmission in the background cmd prompt.

6. Running LTE IPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running LTE IPv6: lena-ipv6-ue-rh.cc, lena-ipv6-ue-ue.cc and lena-ipv6-addr-conf.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run lena-ipv6-ue-ue --vis

This will open a visualizer to see the output and the packet transmission in the background cmd prompt.

=== Documentation ===

Either, you follow the prepared documentation,

For MIPv6,

https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing

For LTE IPv6,

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/blob/master/ns-3.25/src/lte/doc/source/lte-design.rst and
https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/blob/master/ns-3.25/src/lte/doc/source/lte-user.rst

or, you could follow the manual for Creating Documentation here: https://www.nsnam.org/docs/manual/html/documentation.html. I have added the appropriate documentations within the code of the above repo of my implementation.

=== Work Flow ===

The following link will describe the weekly update of this project.

https://www.nsnam.org/wiki/GSOC2017MobileIp#Weekly_Reports

The flow of commits in the code could be found in the following link.

https://github.com/manoj24rana/MobileIPv6

=== Other Issues Resolved ===

I have resolved several other issues in ns-3 during this period as a part of my main implementation. Briefly, these are as follows.

1. Lack of IPv6 support for WiMAX module.

2. Duplicate IPv4 address collision problem in LTE module (https://groups.google.com/forum/#!topic/ns-3-users/Tc3IKky1OKo).

=== Future Enhancement for this Project ===

1. Creating some LTE samples which can run multiple LTE networks in single user's simulation script. It requires cooperation with the existing LTE maintainers in ns-3.

2. Add more options for mobility management. The actual code always switches to the "newest" network. More sophisticated approaches can be tested, like QoS measures and make-before-break.

3. Above all, the beauty of this project is that it is the implementation of the base IP mobility management protocol (MIPv6) in ns-3. The ns-3 users now can easily extend this feature to implement other such protocols, such as NEMO (RFC 3963), PMIPv6 (RFC 5213) etc. and also some upcoming schemes in 5G.

GSOC2017MobileIp

2017-08-28T15:46:45Z

Mkrana: /* Future Enhancement for this Project */

{{TOC}}

Return to [[GSOC2017AcceptedProjects | GSoC 2017 Accepted Projects]] page.

= Project overview =

* '''Project name:''' Mobile IPv6 Implementation with LTE support

* '''Student:''' [mailto:manoj24.rana@gmail.com Manoj Kumar Rana]

* '''Mentor:''' [mailto:tommypec@gmail.com Tommaso Pecorella]

* '''Abstract:''' The goal of the project is to implement a novel MIPv6 simulation model which can be integrated into ns-3. The project idea aims at testing the code in different network scenarios, containing different link layer technologies such as Wi-Fi, WiMAX and LTE. The current implementation of LTE does not have support of IPv6 in ns-3. So, the idea of testing MIPv6 code into LTE would follow IPv6 support implementation in LTE first and then the MIPv6 support. Thus, implementation of MIPv6 in ns-3 as the base mobility management solution and providing LTE support within it could help the current network researchers working on ns-3.

* '''Code:''' https://github.com/manoj24rana/MobileIPv6

* '''Documentation:'''
# Detail Description about the Implementation: http://www.sciencedirect.com/science/article/pii/S1569190X16302714
# Phase1 Documentation: https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing
# Phase2 Documentation: https://drive.google.com/open?id=0BziHE2fNAdZRbUZKN01Bd1Rjdk0

* '''About me:''' I am a PhD student in the School of Mobile Computing and Communications, Jadavpur University, India. About my research is given here: http://scholar.google.com/citations?user=qouvajAAAAAJ&hl=en.

= Technical Approach =
*'''First,''' I want to restructure the MIPv6 code, published in http://www.sciencedirect.com/science/article/pii/S1569190X16302714, to make it RFC 6275 compliance. To do the restructuring complete, the following approaches will be performed:
#Code refactoring: reorganizing internetstack, helper and header components of the MIPv6 module through modifying the internal functions, attributes and the callback variables.
#Code analysis: both static and dynamic analysis could be performed. The waf tool for code run, PyViz for visualization and tcpdump for pcap tracing could be used.
#Functional tests: The functional test would be performed in three phase: handoff performance testing, data packet transmission testing and both. Use cases like multiple mobile nodes, multiple correspondent node, different mobility model for the mobile node as well as heterogeneous link layer technologies (Wi-Fi and WiMAX) could be used.
#The code will be sent for the code review to the ns-3 team.
* '''Second,''' IPV6 support for LTE would be ensured as LTE currently, only supports IPv4. The changes would possibly be done within the LTE module files (both .cc and .h) like point-topoint-helper, emu-epc-helper, lte-ue-net-device, epc-sgw-pgw-application, epc-enb-application, lte-enb-net-device etc. Then, the code analysis will be performed as done previously for MIPv6 code. The functional tests would follow bidirectional IPv6 packet transmission between remote host and the UE. The modification/rewriting code will create a patch that could enable IPv6 forwarding in the LTE data plane, enabling the UE to receive and use a /64 prefix, as stated in the standard. It is worth noticing that IP packets are tunnelled in the `core' network (i.e., all the EPC part), and their actual IP address is not used for UE identification in the core. As a consequence, IPv6 use in the `core' network, using ULAs or link-local addresses, could be planned if the previous development is faster than foreseen. This modification could also be simpler than expected, as it is not important to keep a dual stack communication in the core network, and using only IPv6 brings some direct benefits (like simplifying the use of multiple EPCs in a single script).
* '''Third,''' To ensure the code quality, the following testing approach could be used: Test MIPv6 handoff performance with the mixed link layer technologies (combination of Wi-Fi, WiMAX and LTE) case, multiple mobile node case, and multiple correspondent node case.

= Deliverables and Plan =
=== Deliverables: ===

-a basic MIPv6 module, aligned with RFC 6275 following ns-3 coding styles;

-a reviewed patch, fixing the IPv6 support issue in LTE;

-proper documentation and tests for the above-mentioned components.

=== Plan: ===

==== May 4 – May 29 (Before the official coding time): ====

-Familiarize myself completely with MIPv6, LTE (the IPv4 part), and the respective interactions.

-Study of the customized files of ns-3 lte and internet modules

-Familiarize myself with the ns-3 coding styles

During this period I will remain in constant touch with my mentor and the ns-3 community. I will remain active on IRC and Mailing lists to discuss and finalize on the modifications (if any) that needs to be on existing models and design of new module (if needed to fit cleanly with ns-3)

Thus with the help of my mentor I will become absolutely clear about my future goals, the final MIPv6 implementation that need to be done as well as the approach that I will follow to support IPv6 in lte model.

==== May 30 – June 26 (Official coding period starts): ====

-Refactor previous MIPv6 headers to RFC compliance header files

-Refactor all the classes to implement the corresponding header file functions

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the newly implemented MIPv6 module in various testing scenarios. The testing will be done with the systems having Wi-Fi and WiMAX link layer technology

-Sending the code for code review to the ns-3 team

After this stage, the standard ns-3 code revision can be started for the MIPv6 code part. Any change requested by the reviewers will be carried out in parallel with the following activities.

==== June 27 – July 24: ====

-Define new or, modify existing header files and cc files in LTE module in such a way that LTE module remains backward compatible with IPv4

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the LTE module

-Sending the code for code review to the ns-3 team

This will help in testing of the LTE module with IPv6 support for possible merge into the project main tree.

==== July 25 – August 21: ====

-Making further changes in the LTE module to support MIPv6 into it. Changes may be required in the other modules of ns-3 also.

-Testing the overall working in the testing scenarios having the combination of Wi-Fi and LTE

-Most of the time will be consumed for rigorous testing and bug fixes.

-Sending the code for code review to the ns-3 team

-Documentation updates.

= Weekly Reports =

=== May 30 - June 6 ===

1. Restructuring the MIPv6 code.

2. Testing the code in the multiple Mobile Node case

3. Changing the Home Agent functionality a little bit

4. Arise Tunnel Implementation Issue [how mobile node would use its home address for all of its data communication]

=== June 7 - June 13 ===

1. Resolved the issue of home address assignment to mobile node for all of its data communication. So, I have made some tricky callbacks in the L4 protocol a little bit. Now, traffic can be directed in both direction i.e. Mobile node to a web server and a web server to a mobile node

2. Also delete a lot of unnecessary files as well as lines in the code.

3. Tests have been done changing the location of different mobility entities. Almost all are successful. Those are included in "mipv6-test1-4.cc" in scratch of https://github.com/manoj24rana/MobileIPv6.

=== June 14 - June 20 ===

1. Done more tests

2. Add some more features such as defending home address and performing NS handling at HA as described in RFC 6275

3. Find an issue on RFC 6275 i.e. how to defend the mobile node's home address by home agent when it returns to its home network. Try to do something on the basis of ns-3 ipv6 implementation to resolve the issue.

=== June 21 - June 27 ===

1. Documentation on how my implementation differs from RFC 6275 as well as

2. Resolve the above issue

3. Sending the code for review.

=== June 28 - July 04 ===

1. Starting LTE IPv6 implementation part: understanding the end-to-end IPv4 part between UE and remote host, decoding it and discuss with my mentor for changing

2. Start writing code, at least one class modification

3. Test the change whether it is right.

=== July 05 - July 11 ===

1. Complete the modification in the lte module classes and also develop a small IPv6 dealing program to test

2. An issue arise i.e. Address Collision occurs at file: file=../src/internet/model/
ipv6-address-generator.cc, line=484". I am trying to resolve it.

3. Runs the previous IPv4 sample programs, which runs fine.

=== July 12 - July 18 ===

1. Resolve the IPv6 address collision issue in the LTE IPv6 support part.

2. I face another issue on handling multicast packets between UE sets and pgw i.e. those multicast packets are not passed between them as in the middle there is an enb.

3. Add the Sphinx documentation in the mipv6 module.

4. The Attributes and TraceSources are uploaded in mipv6 git.

=== July 19 - July 25 ===

1. Making some examples for the main mipv6 repo.

2. Add two tests in the main mipv6 repo.

3. mipv6 doc file further update.

4. Add and change tracesources and some functionalities in mipv6 model.

=== July 26 - August 1 ===

Finalize the MIPv6 code for review. I have added two nice tests replacing the previous tests, further update the mipv6 doc, trace sources, attributes, examples.
The codes are documented highly. Now the /doc/models/build/html dir contains the model documentation and the /doc/html creates doxygen for the mipv6 module.

=== August 2 - August 15 ===

1. Sent the MIPv6 code for review.

2. Solved LTE IPv6 packet sending issues.

3. Complete LTE IPv6 part, i.e. IPv6 packets are received and sent correctly.

4. Discuss with my mentor (Tommaso) elaborately about the next steps such that this implementation could be rebased in the main ns-3 dev quickly.

=== August 16 - August 22 ===

1. Update the LTE UE and PGW address assignment process in such a way that all IP addresses assigned by an EPC are derived from a base prefix (8 for IPv4 and 32 for IPv6) and each EPC holds a unique 16 bit IPv4 and 48 bit IPv6 subnet prefix to assign addresses to PGW and UEs. This address assignment process is made by keeping in mind the issues stated in https://www.nsnam.org/bugzilla/show_bug.cgi?id=1745 and https://groups.google.com/forum/#!topic/ns-3-users/Tc3IKky1OKo. So, now address duplication would not happen in case of more than one EPC as well as any time we could assign addresses without initializing the address helper. Also, user is given the flexibility to reassign the base 8 or, 32 bit address prefix at any time.

2. The LTE module is updated by IPv6 tests, documentation and examples. So, now the sample program is running and users can use them.

=== August 23 - August 29 ===

1. Submit the Google Work Product.

2. Send the LTE Code for review.

3. Try to resolve the reviewer's comment.

= Final Report for Google =
It has been an outstanding experience for me, spending this summer for GSoC project. I gave my full effort to make a very successful GSoC project and so, involve myself almost entirely. The huge interest from the current ns-3 users about my project speeds up the work what I have enjoyed most. I have learned a lot of things during this summer. First, I could do a lot more works than my expectation. Secondly, coding based on the standard theory always makes my project stuffs correct and wonderful. Third, working for a community like ns-3 polishes my coding networking and communication skills a lot.

This final report contains all the links to all the works done over the summer. There have been total 19,000 lines of code with 146 commits contributed in my github repo.

=== Work Product Link ===

This is the complete work product link with full ns-3.25 software:

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6

My contribution:

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/commit/7164250819b85ec2461e4c20667a516720eeddd5

=== Installation and Running the Work Product ===

1. Depending on your OS, install the ns-3 Prerequisites from this link: https://www.nsnam.org/wiki/Installation#Prerequisites.

2. Download the code from this repository: https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6 and extract it.

3. Make sure that you have installed all the perquisites to install ns-3.25.

4. Run the following commands in your cmd prompt to install it:

$ cd The_Project_Folder

$ cd ns-3.25

$ ./waf -d debug --enable-examples --enable-tests configure

$ ./waf

5. Running MIPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running MIPv6: mipv6-multiple.cc, mipv6-single.cc and mipv6-wifi-wimax.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run mipv6-multiple --vis

This will open a visualizer to see the output and the packet transmission in the background cmd prompt.

6. Running LTE IPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running LTE IPv6: lena-ipv6-ue-rh.cc, lena-ipv6-ue-ue.cc and lena-ipv6-addr-conf.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run lena-ipv6-ue-ue --vis

This will open a visualizer to see the output and the packet transmission in the background cmd prompt.

=== Documentation ===

Either, you follow the prepared documentation,

For MIPv6,

https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing

For LTE IPv6,

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/blob/master/ns-3.25/src/lte/doc/source/lte-design.rst and
https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/blob/master/ns-3.25/src/lte/doc/source/lte-user.rst

or, you could follow the manual for Creating Documentation here: https://www.nsnam.org/docs/manual/html/documentation.html. I have added the appropriate documentations within the code of the above repo of my implementation.

=== Work Flow ===

The following link will describe the weekly update of this project.

https://www.nsnam.org/wiki/GSOC2017MobileIp#Weekly_Reports

The flow of commits in the code could be found in the following link.

https://github.com/manoj24rana/MobileIPv6

=== Other Issues Resolved ===

I have resolved several other issues in ns-3 during this period as a part of my main implementation. Briefly, these are as follows.

1. Lack of IPv6 support for WiMAX module.

2. Duplicate IPv4 address collision problem in LTE module (https://groups.google.com/forum/#!topic/ns-3-users/Tc3IKky1OKo).

3. Affecting this problem (https://www.nsnam.org/bugzilla/show_bug.cgi?id=1745) in LTE IP address assignments.

=== Future Enhancement for this Project ===

1. Creating some LTE samples which can run multiple LTE networks in single user's simulation script. It requires cooperation with the existing LTE maintainers in ns-3.

2. Add more options for mobility management. The actual code always switches to the "newest" network. More sophisticated approaches can be tested, like QoS measures and make-before-break.

3. Above all, the beauty of this project is that it is the implementation of the base IP mobility management protocol (MIPv6) in ns-3. The ns-3 users now can easily extend this feature to implement other such protocols, such as NEMO (RFC 3963), PMIPv6 (RFC 5213) etc. and also some upcoming schemes in 5G.

GSOC2017MobileIp

2017-08-28T10:20:14Z

Mkrana: /* Final Report for Google */

{{TOC}}

Return to [[GSOC2017AcceptedProjects | GSoC 2017 Accepted Projects]] page.

= Project overview =

* '''Project name:''' Mobile IPv6 Implementation with LTE support

* '''Student:''' [mailto:manoj24.rana@gmail.com Manoj Kumar Rana]

* '''Mentor:''' [mailto:tommypec@gmail.com Tommaso Pecorella]

* '''Abstract:''' The goal of the project is to implement a novel MIPv6 simulation model which can be integrated into ns-3. The project idea aims at testing the code in different network scenarios, containing different link layer technologies such as Wi-Fi, WiMAX and LTE. The current implementation of LTE does not have support of IPv6 in ns-3. So, the idea of testing MIPv6 code into LTE would follow IPv6 support implementation in LTE first and then the MIPv6 support. Thus, implementation of MIPv6 in ns-3 as the base mobility management solution and providing LTE support within it could help the current network researchers working on ns-3.

* '''Code:''' https://github.com/manoj24rana/MobileIPv6

* '''Documentation:'''
# Detail Description about the Implementation: http://www.sciencedirect.com/science/article/pii/S1569190X16302714
# Phase1 Documentation: https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing
# Phase2 Documentation: https://drive.google.com/open?id=0BziHE2fNAdZRbUZKN01Bd1Rjdk0

* '''About me:''' I am a PhD student in the School of Mobile Computing and Communications, Jadavpur University, India. About my research is given here: http://scholar.google.com/citations?user=qouvajAAAAAJ&hl=en.

= Technical Approach =
*'''First,''' I want to restructure the MIPv6 code, published in http://www.sciencedirect.com/science/article/pii/S1569190X16302714, to make it RFC 6275 compliance. To do the restructuring complete, the following approaches will be performed:
#Code refactoring: reorganizing internetstack, helper and header components of the MIPv6 module through modifying the internal functions, attributes and the callback variables.
#Code analysis: both static and dynamic analysis could be performed. The waf tool for code run, PyViz for visualization and tcpdump for pcap tracing could be used.
#Functional tests: The functional test would be performed in three phase: handoff performance testing, data packet transmission testing and both. Use cases like multiple mobile nodes, multiple correspondent node, different mobility model for the mobile node as well as heterogeneous link layer technologies (Wi-Fi and WiMAX) could be used.
#The code will be sent for the code review to the ns-3 team.
* '''Second,''' IPV6 support for LTE would be ensured as LTE currently, only supports IPv4. The changes would possibly be done within the LTE module files (both .cc and .h) like point-topoint-helper, emu-epc-helper, lte-ue-net-device, epc-sgw-pgw-application, epc-enb-application, lte-enb-net-device etc. Then, the code analysis will be performed as done previously for MIPv6 code. The functional tests would follow bidirectional IPv6 packet transmission between remote host and the UE. The modification/rewriting code will create a patch that could enable IPv6 forwarding in the LTE data plane, enabling the UE to receive and use a /64 prefix, as stated in the standard. It is worth noticing that IP packets are tunnelled in the `core' network (i.e., all the EPC part), and their actual IP address is not used for UE identification in the core. As a consequence, IPv6 use in the `core' network, using ULAs or link-local addresses, could be planned if the previous development is faster than foreseen. This modification could also be simpler than expected, as it is not important to keep a dual stack communication in the core network, and using only IPv6 brings some direct benefits (like simplifying the use of multiple EPCs in a single script).
* '''Third,''' To ensure the code quality, the following testing approach could be used: Test MIPv6 handoff performance with the mixed link layer technologies (combination of Wi-Fi, WiMAX and LTE) case, multiple mobile node case, and multiple correspondent node case.

= Deliverables and Plan =
=== Deliverables: ===

-a basic MIPv6 module, aligned with RFC 6275 following ns-3 coding styles;

-a reviewed patch, fixing the IPv6 support issue in LTE;

-proper documentation and tests for the above-mentioned components.

=== Plan: ===

==== May 4 – May 29 (Before the official coding time): ====

-Familiarize myself completely with MIPv6, LTE (the IPv4 part), and the respective interactions.

-Study of the customized files of ns-3 lte and internet modules

-Familiarize myself with the ns-3 coding styles

During this period I will remain in constant touch with my mentor and the ns-3 community. I will remain active on IRC and Mailing lists to discuss and finalize on the modifications (if any) that needs to be on existing models and design of new module (if needed to fit cleanly with ns-3)

Thus with the help of my mentor I will become absolutely clear about my future goals, the final MIPv6 implementation that need to be done as well as the approach that I will follow to support IPv6 in lte model.

==== May 30 – June 26 (Official coding period starts): ====

-Refactor previous MIPv6 headers to RFC compliance header files

-Refactor all the classes to implement the corresponding header file functions

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the newly implemented MIPv6 module in various testing scenarios. The testing will be done with the systems having Wi-Fi and WiMAX link layer technology

-Sending the code for code review to the ns-3 team

After this stage, the standard ns-3 code revision can be started for the MIPv6 code part. Any change requested by the reviewers will be carried out in parallel with the following activities.

==== June 27 – July 24: ====

-Define new or, modify existing header files and cc files in LTE module in such a way that LTE module remains backward compatible with IPv4

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the LTE module

-Sending the code for code review to the ns-3 team

This will help in testing of the LTE module with IPv6 support for possible merge into the project main tree.

==== July 25 – August 21: ====

-Making further changes in the LTE module to support MIPv6 into it. Changes may be required in the other modules of ns-3 also.

-Testing the overall working in the testing scenarios having the combination of Wi-Fi and LTE

-Most of the time will be consumed for rigorous testing and bug fixes.

-Sending the code for code review to the ns-3 team

-Documentation updates.

= Weekly Reports =

=== May 30 - June 6 ===

1. Restructuring the MIPv6 code.

2. Testing the code in the multiple Mobile Node case

3. Changing the Home Agent functionality a little bit

4. Arise Tunnel Implementation Issue [how mobile node would use its home address for all of its data communication]

=== June 7 - June 13 ===

1. Resolved the issue of home address assignment to mobile node for all of its data communication. So, I have made some tricky callbacks in the L4 protocol a little bit. Now, traffic can be directed in both direction i.e. Mobile node to a web server and a web server to a mobile node

2. Also delete a lot of unnecessary files as well as lines in the code.

3. Tests have been done changing the location of different mobility entities. Almost all are successful. Those are included in "mipv6-test1-4.cc" in scratch of https://github.com/manoj24rana/MobileIPv6.

=== June 14 - June 20 ===

1. Done more tests

2. Add some more features such as defending home address and performing NS handling at HA as described in RFC 6275

3. Find an issue on RFC 6275 i.e. how to defend the mobile node's home address by home agent when it returns to its home network. Try to do something on the basis of ns-3 ipv6 implementation to resolve the issue.

=== June 21 - June 27 ===

1. Documentation on how my implementation differs from RFC 6275 as well as

2. Resolve the above issue

3. Sending the code for review.

=== June 28 - July 04 ===

1. Starting LTE IPv6 implementation part: understanding the end-to-end IPv4 part between UE and remote host, decoding it and discuss with my mentor for changing

2. Start writing code, at least one class modification

3. Test the change whether it is right.

=== July 05 - July 11 ===

1. Complete the modification in the lte module classes and also develop a small IPv6 dealing program to test

2. An issue arise i.e. Address Collision occurs at file: file=../src/internet/model/
ipv6-address-generator.cc, line=484". I am trying to resolve it.

3. Runs the previous IPv4 sample programs, which runs fine.

=== July 12 - July 18 ===

1. Resolve the IPv6 address collision issue in the LTE IPv6 support part.

2. I face another issue on handling multicast packets between UE sets and pgw i.e. those multicast packets are not passed between them as in the middle there is an enb.

3. Add the Sphinx documentation in the mipv6 module.

4. The Attributes and TraceSources are uploaded in mipv6 git.

=== July 19 - July 25 ===

1. Making some examples for the main mipv6 repo.

2. Add two tests in the main mipv6 repo.

3. mipv6 doc file further update.

4. Add and change tracesources and some functionalities in mipv6 model.

=== July 26 - August 1 ===

Finalize the MIPv6 code for review. I have added two nice tests replacing the previous tests, further update the mipv6 doc, trace sources, attributes, examples.
The codes are documented highly. Now the /doc/models/build/html dir contains the model documentation and the /doc/html creates doxygen for the mipv6 module.

=== August 2 - August 15 ===

1. Sent the MIPv6 code for review.

2. Solved LTE IPv6 packet sending issues.

3. Complete LTE IPv6 part, i.e. IPv6 packets are received and sent correctly.

4. Discuss with my mentor (Tommaso) elaborately about the next steps such that this implementation could be rebased in the main ns-3 dev quickly.

=== August 16 - August 22 ===

1. Update the LTE UE and PGW address assignment process in such a way that all IP addresses assigned by an EPC are derived from a base prefix (8 for IPv4 and 32 for IPv6) and each EPC holds a unique 16 bit IPv4 and 48 bit IPv6 subnet prefix to assign addresses to PGW and UEs. This address assignment process is made by keeping in mind the issues stated in https://www.nsnam.org/bugzilla/show_bug.cgi?id=1745 and https://groups.google.com/forum/#!topic/ns-3-users/Tc3IKky1OKo. So, now address duplication would not happen in case of more than one EPC as well as any time we could assign addresses without initializing the address helper. Also, user is given the flexibility to reassign the base 8 or, 32 bit address prefix at any time.

2. The LTE module is updated by IPv6 tests, documentation and examples. So, now the sample program is running and users can use them.

=== August 23 - August 29 ===

1. Submit the Google Work Product.

2. Send the LTE Code for review.

3. Try to resolve the reviewer's comment.

= Final Report for Google =
It has been an outstanding experience for me, spending this summer for GSoC project. I gave my full effort to make a very successful GSoC project and so, involve myself almost entirely. The huge interest from the current ns-3 users about my project speeds up the work what I have enjoyed most. I have learned a lot of things during this summer. First, I could do a lot more works than my expectation. Secondly, coding based on the standard theory always makes my project stuffs correct and wonderful. Third, working for a community like ns-3 polishes my coding networking and communication skills a lot.

This final report contains all the links to all the works done over the summer. There have been total 19,000 lines of code with 146 commits contributed in my github repo.

=== Work Product Link ===

This is the complete work product link with full ns-3.25 software:

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6

My contribution:

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/commit/7164250819b85ec2461e4c20667a516720eeddd5

=== Installation and Running the Work Product ===

1. Depending on your OS, install the ns-3 Prerequisites from this link: https://www.nsnam.org/wiki/Installation#Prerequisites.

2. Download the code from this repository: https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6 and extract it.

3. Make sure that you have installed all the perquisites to install ns-3.25.

4. Run the following commands in your cmd prompt to install it:

$ cd The_Project_Folder

$ cd ns-3.25

$ ./waf -d debug --enable-examples --enable-tests configure

$ ./waf

5. Running MIPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running MIPv6: mipv6-multiple.cc, mipv6-single.cc and mipv6-wifi-wimax.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run mipv6-multiple --vis

This will open a visualizer to see the output and the packet transmission in the background cmd prompt.

6. Running LTE IPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running LTE IPv6: lena-ipv6-ue-rh.cc, lena-ipv6-ue-ue.cc and lena-ipv6-addr-conf.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run lena-ipv6-ue-ue --vis

This will open a visualizer to see the output and the packet transmission in the background cmd prompt.

=== Documentation ===

Either, you follow the prepared documentation,

For MIPv6,

https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing

For LTE IPv6,

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/blob/master/ns-3.25/src/lte/doc/source/lte-design.rst and
https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/blob/master/ns-3.25/src/lte/doc/source/lte-user.rst

or, you could follow the manual for Creating Documentation here: https://www.nsnam.org/docs/manual/html/documentation.html. I have added the appropriate documentations within the code of the above repo of my implementation.

=== Work Flow ===

The following link will describe the weekly update of this project.

https://www.nsnam.org/wiki/GSOC2017MobileIp#Weekly_Reports

The flow of commits in the code could be found in the following link.

https://github.com/manoj24rana/MobileIPv6

=== Other Issues Resolved ===

I have resolved several other issues in ns-3 during this period as a part of my main implementation. Briefly, these are as follows.

1. Lack of IPv6 support for WiMAX module.

2. Duplicate IPv4 address collision problem in LTE module (https://groups.google.com/forum/#!topic/ns-3-users/Tc3IKky1OKo).

3. Affecting this problem (https://www.nsnam.org/bugzilla/show_bug.cgi?id=1745) in LTE IP address assignments.

=== Future Enhancement for this Project ===

1. LTE EPC part update to allow IP layer control packets. It will ease the IP layer bonding between LTE-LTE, LTE-WiFi and LTE-WiMAX.

2. Creating some LTE samples which can run multiple LTE networks in single user's simulation script. It requires cooperation with the existing LTE maintainers in ns-3.

3. Above all, the beauty of this project is that it is the implementation of the base IP mobility management protocol (MIPv6) in ns-3. The ns-3 users now can easily extend this feature to implement other such protocols, such as NEMO (RFC 3963), PMIPv6 (RFC 5213) etc. and also some upcoming schemes in 5G.

GSOC2017MobileIp

2017-08-28T10:18:36Z

Mkrana: /* Final Report for Google */

{{TOC}}

Return to [[GSOC2017AcceptedProjects | GSoC 2017 Accepted Projects]] page.

= Project overview =

* '''Project name:''' Mobile IPv6 Implementation with LTE support

* '''Student:''' [mailto:manoj24.rana@gmail.com Manoj Kumar Rana]

* '''Mentor:''' [mailto:tommypec@gmail.com Tommaso Pecorella]

* '''Abstract:''' The goal of the project is to implement a novel MIPv6 simulation model which can be integrated into ns-3. The project idea aims at testing the code in different network scenarios, containing different link layer technologies such as Wi-Fi, WiMAX and LTE. The current implementation of LTE does not have support of IPv6 in ns-3. So, the idea of testing MIPv6 code into LTE would follow IPv6 support implementation in LTE first and then the MIPv6 support. Thus, implementation of MIPv6 in ns-3 as the base mobility management solution and providing LTE support within it could help the current network researchers working on ns-3.

* '''Code:''' https://github.com/manoj24rana/MobileIPv6

* '''Documentation:'''
# Detail Description about the Implementation: http://www.sciencedirect.com/science/article/pii/S1569190X16302714
# Phase1 Documentation: https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing
# Phase2 Documentation: https://drive.google.com/open?id=0BziHE2fNAdZRbUZKN01Bd1Rjdk0

* '''About me:''' I am a PhD student in the School of Mobile Computing and Communications, Jadavpur University, India. About my research is given here: http://scholar.google.com/citations?user=qouvajAAAAAJ&hl=en.

= Technical Approach =
*'''First,''' I want to restructure the MIPv6 code, published in http://www.sciencedirect.com/science/article/pii/S1569190X16302714, to make it RFC 6275 compliance. To do the restructuring complete, the following approaches will be performed:
#Code refactoring: reorganizing internetstack, helper and header components of the MIPv6 module through modifying the internal functions, attributes and the callback variables.
#Code analysis: both static and dynamic analysis could be performed. The waf tool for code run, PyViz for visualization and tcpdump for pcap tracing could be used.
#Functional tests: The functional test would be performed in three phase: handoff performance testing, data packet transmission testing and both. Use cases like multiple mobile nodes, multiple correspondent node, different mobility model for the mobile node as well as heterogeneous link layer technologies (Wi-Fi and WiMAX) could be used.
#The code will be sent for the code review to the ns-3 team.
* '''Second,''' IPV6 support for LTE would be ensured as LTE currently, only supports IPv4. The changes would possibly be done within the LTE module files (both .cc and .h) like point-topoint-helper, emu-epc-helper, lte-ue-net-device, epc-sgw-pgw-application, epc-enb-application, lte-enb-net-device etc. Then, the code analysis will be performed as done previously for MIPv6 code. The functional tests would follow bidirectional IPv6 packet transmission between remote host and the UE. The modification/rewriting code will create a patch that could enable IPv6 forwarding in the LTE data plane, enabling the UE to receive and use a /64 prefix, as stated in the standard. It is worth noticing that IP packets are tunnelled in the `core' network (i.e., all the EPC part), and their actual IP address is not used for UE identification in the core. As a consequence, IPv6 use in the `core' network, using ULAs or link-local addresses, could be planned if the previous development is faster than foreseen. This modification could also be simpler than expected, as it is not important to keep a dual stack communication in the core network, and using only IPv6 brings some direct benefits (like simplifying the use of multiple EPCs in a single script).
* '''Third,''' To ensure the code quality, the following testing approach could be used: Test MIPv6 handoff performance with the mixed link layer technologies (combination of Wi-Fi, WiMAX and LTE) case, multiple mobile node case, and multiple correspondent node case.

= Deliverables and Plan =
=== Deliverables: ===

-a basic MIPv6 module, aligned with RFC 6275 following ns-3 coding styles;

-a reviewed patch, fixing the IPv6 support issue in LTE;

-proper documentation and tests for the above-mentioned components.

=== Plan: ===

==== May 4 – May 29 (Before the official coding time): ====

-Familiarize myself completely with MIPv6, LTE (the IPv4 part), and the respective interactions.

-Study of the customized files of ns-3 lte and internet modules

-Familiarize myself with the ns-3 coding styles

During this period I will remain in constant touch with my mentor and the ns-3 community. I will remain active on IRC and Mailing lists to discuss and finalize on the modifications (if any) that needs to be on existing models and design of new module (if needed to fit cleanly with ns-3)

Thus with the help of my mentor I will become absolutely clear about my future goals, the final MIPv6 implementation that need to be done as well as the approach that I will follow to support IPv6 in lte model.

==== May 30 – June 26 (Official coding period starts): ====

-Refactor previous MIPv6 headers to RFC compliance header files

-Refactor all the classes to implement the corresponding header file functions

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the newly implemented MIPv6 module in various testing scenarios. The testing will be done with the systems having Wi-Fi and WiMAX link layer technology

-Sending the code for code review to the ns-3 team

After this stage, the standard ns-3 code revision can be started for the MIPv6 code part. Any change requested by the reviewers will be carried out in parallel with the following activities.

==== June 27 – July 24: ====

-Define new or, modify existing header files and cc files in LTE module in such a way that LTE module remains backward compatible with IPv4

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the LTE module

-Sending the code for code review to the ns-3 team

This will help in testing of the LTE module with IPv6 support for possible merge into the project main tree.

==== July 25 – August 21: ====

-Making further changes in the LTE module to support MIPv6 into it. Changes may be required in the other modules of ns-3 also.

-Testing the overall working in the testing scenarios having the combination of Wi-Fi and LTE

-Most of the time will be consumed for rigorous testing and bug fixes.

-Sending the code for code review to the ns-3 team

-Documentation updates.

= Weekly Reports =

=== May 30 - June 6 ===

1. Restructuring the MIPv6 code.

2. Testing the code in the multiple Mobile Node case

3. Changing the Home Agent functionality a little bit

4. Arise Tunnel Implementation Issue [how mobile node would use its home address for all of its data communication]

=== June 7 - June 13 ===

1. Resolved the issue of home address assignment to mobile node for all of its data communication. So, I have made some tricky callbacks in the L4 protocol a little bit. Now, traffic can be directed in both direction i.e. Mobile node to a web server and a web server to a mobile node

2. Also delete a lot of unnecessary files as well as lines in the code.

3. Tests have been done changing the location of different mobility entities. Almost all are successful. Those are included in "mipv6-test1-4.cc" in scratch of https://github.com/manoj24rana/MobileIPv6.

=== June 14 - June 20 ===

1. Done more tests

2. Add some more features such as defending home address and performing NS handling at HA as described in RFC 6275

3. Find an issue on RFC 6275 i.e. how to defend the mobile node's home address by home agent when it returns to its home network. Try to do something on the basis of ns-3 ipv6 implementation to resolve the issue.

=== June 21 - June 27 ===

1. Documentation on how my implementation differs from RFC 6275 as well as

2. Resolve the above issue

3. Sending the code for review.

=== June 28 - July 04 ===

1. Starting LTE IPv6 implementation part: understanding the end-to-end IPv4 part between UE and remote host, decoding it and discuss with my mentor for changing

2. Start writing code, at least one class modification

3. Test the change whether it is right.

=== July 05 - July 11 ===

1. Complete the modification in the lte module classes and also develop a small IPv6 dealing program to test

2. An issue arise i.e. Address Collision occurs at file: file=../src/internet/model/
ipv6-address-generator.cc, line=484". I am trying to resolve it.

3. Runs the previous IPv4 sample programs, which runs fine.

=== July 12 - July 18 ===

1. Resolve the IPv6 address collision issue in the LTE IPv6 support part.

2. I face another issue on handling multicast packets between UE sets and pgw i.e. those multicast packets are not passed between them as in the middle there is an enb.

3. Add the Sphinx documentation in the mipv6 module.

4. The Attributes and TraceSources are uploaded in mipv6 git.

=== July 19 - July 25 ===

1. Making some examples for the main mipv6 repo.

2. Add two tests in the main mipv6 repo.

3. mipv6 doc file further update.

4. Add and change tracesources and some functionalities in mipv6 model.

=== July 26 - August 1 ===

Finalize the MIPv6 code for review. I have added two nice tests replacing the previous tests, further update the mipv6 doc, trace sources, attributes, examples.
The codes are documented highly. Now the /doc/models/build/html dir contains the model documentation and the /doc/html creates doxygen for the mipv6 module.

=== August 2 - August 15 ===

1. Sent the MIPv6 code for review.

2. Solved LTE IPv6 packet sending issues.

3. Complete LTE IPv6 part, i.e. IPv6 packets are received and sent correctly.

4. Discuss with my mentor (Tommaso) elaborately about the next steps such that this implementation could be rebased in the main ns-3 dev quickly.

=== August 16 - August 22 ===

1. Update the LTE UE and PGW address assignment process in such a way that all IP addresses assigned by an EPC are derived from a base prefix (8 for IPv4 and 32 for IPv6) and each EPC holds a unique 16 bit IPv4 and 48 bit IPv6 subnet prefix to assign addresses to PGW and UEs. This address assignment process is made by keeping in mind the issues stated in https://www.nsnam.org/bugzilla/show_bug.cgi?id=1745 and https://groups.google.com/forum/#!topic/ns-3-users/Tc3IKky1OKo. So, now address duplication would not happen in case of more than one EPC as well as any time we could assign addresses without initializing the address helper. Also, user is given the flexibility to reassign the base 8 or, 32 bit address prefix at any time.

2. The LTE module is updated by IPv6 tests, documentation and examples. So, now the sample program is running and users can use them.

=== August 23 - August 29 ===

1. Submit the Google Work Product.

2. Send the LTE Code for review.

3. Try to resolve the reviewer's comment.

= Final Report for Google =
It has been an outstanding experience for me, spending this summer for GSoC project. I gave my full effort to make a very successful GSoC project and so, involve myself almost entirely. The huge interest from the current ns-3 users about my project speeds up the work what I have enjoyed most. I have learned a lot of things during this summer. First, I could do a lot more works than my expectation. Secondly, coding based on the standard theory always makes my project stuffs correct and wonderful. My mentor helps me a lot on this. Third, working for a community like ns-3 polishes my coding networking and communication skills a lot.

This final report contains all the links to all the works done over the summer. There have been total 19,000 lines of code with 146 commits contributed in my github repo.

=== Work Product Link ===

This is the complete work product link with full ns-3.25 software:

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6

My contribution:

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/commit/7164250819b85ec2461e4c20667a516720eeddd5

=== Installation and Running the Work Product ===

1. Depending on your OS, install the ns-3 Prerequisites from this link: https://www.nsnam.org/wiki/Installation#Prerequisites.

2. Download the code from this repository: https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6 and extract it.

3. Make sure that you have installed all the perquisites to install ns-3.25.

4. Run the following commands in your cmd prompt to install it:

$ cd The_Project_Folder

$ cd ns-3.25

$ ./waf -d debug --enable-examples --enable-tests configure

$ ./waf

5. Running MIPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running MIPv6: mipv6-multiple.cc, mipv6-single.cc and mipv6-wifi-wimax.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run mipv6-multiple --vis

This will open a visualizer to see the output and the packet transmission in the background cmd prompt.

6. Running LTE IPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running LTE IPv6: lena-ipv6-ue-rh.cc, lena-ipv6-ue-ue.cc and lena-ipv6-addr-conf.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run lena-ipv6-ue-ue --vis

This will open a visualizer to see the output and the packet transmission in the background cmd prompt.

=== Documentation ===

Either, you follow the prepared documentation,

For MIPv6,

https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing

For LTE IPv6,

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/blob/master/ns-3.25/src/lte/doc/source/lte-design.rst and
https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/blob/master/ns-3.25/src/lte/doc/source/lte-user.rst

or, you could follow the manual for Creating Documentation here: https://www.nsnam.org/docs/manual/html/documentation.html. I have added the appropriate documentations within the code of the above repo of my implementation.

=== Work Flow ===

The following link will describe the weekly update of this project.

https://www.nsnam.org/wiki/GSOC2017MobileIp#Weekly_Reports

The flow of commits in the code could be found in the following link.

https://github.com/manoj24rana/MobileIPv6

=== Other Issues Resolved ===

I have resolved several other issues in ns-3 during this period as a part of my main implementation. Briefly, these are as follows.

1. Lack of IPv6 support for WiMAX module.

2. Duplicate IPv4 address collision problem in LTE module (https://groups.google.com/forum/#!topic/ns-3-users/Tc3IKky1OKo).

3. Affecting this problem (https://www.nsnam.org/bugzilla/show_bug.cgi?id=1745) in LTE IP address assignments.

=== Future Enhancement for this Project ===

1. LTE EPC part update to allow IP layer control packets. It will ease the IP layer bonding between LTE-LTE, LTE-WiFi and LTE-WiMAX.

2. Creating some LTE samples which can run multiple LTE networks in single user's simulation script. It requires cooperation with the existing LTE maintainers in ns-3.

3. Above all, the beauty of this project is that it is the implementation of the base IP mobility management protocol (MIPv6) in ns-3. The ns-3 users now can easily extend this feature to implement other such protocols, such as NEMO (RFC 3963), PMIPv6 (RFC 5213) etc. and also some upcoming schemes in 5G.

GSOC2017MobileIp

2017-08-28T09:33:15Z

Mkrana: /* Final Report for Google */

{{TOC}}

Return to [[GSOC2017AcceptedProjects | GSoC 2017 Accepted Projects]] page.

= Project overview =

* '''Project name:''' Mobile IPv6 Implementation with LTE support

* '''Student:''' [mailto:manoj24.rana@gmail.com Manoj Kumar Rana]

* '''Mentor:''' [mailto:tommypec@gmail.com Tommaso Pecorella]

* '''Abstract:''' The goal of the project is to implement a novel MIPv6 simulation model which can be integrated into ns-3. The project idea aims at testing the code in different network scenarios, containing different link layer technologies such as Wi-Fi, WiMAX and LTE. The current implementation of LTE does not have support of IPv6 in ns-3. So, the idea of testing MIPv6 code into LTE would follow IPv6 support implementation in LTE first and then the MIPv6 support. Thus, implementation of MIPv6 in ns-3 as the base mobility management solution and providing LTE support within it could help the current network researchers working on ns-3.

* '''Code:''' https://github.com/manoj24rana/MobileIPv6

* '''Documentation:'''
# Detail Description about the Implementation: http://www.sciencedirect.com/science/article/pii/S1569190X16302714
# Phase1 Documentation: https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing
# Phase2 Documentation: https://drive.google.com/open?id=0BziHE2fNAdZRbUZKN01Bd1Rjdk0

* '''About me:''' I am a PhD student in the School of Mobile Computing and Communications, Jadavpur University, India. About my research is given here: http://scholar.google.com/citations?user=qouvajAAAAAJ&hl=en.

= Technical Approach =
*'''First,''' I want to restructure the MIPv6 code, published in http://www.sciencedirect.com/science/article/pii/S1569190X16302714, to make it RFC 6275 compliance. To do the restructuring complete, the following approaches will be performed:
#Code refactoring: reorganizing internetstack, helper and header components of the MIPv6 module through modifying the internal functions, attributes and the callback variables.
#Code analysis: both static and dynamic analysis could be performed. The waf tool for code run, PyViz for visualization and tcpdump for pcap tracing could be used.
#Functional tests: The functional test would be performed in three phase: handoff performance testing, data packet transmission testing and both. Use cases like multiple mobile nodes, multiple correspondent node, different mobility model for the mobile node as well as heterogeneous link layer technologies (Wi-Fi and WiMAX) could be used.
#The code will be sent for the code review to the ns-3 team.
* '''Second,''' IPV6 support for LTE would be ensured as LTE currently, only supports IPv4. The changes would possibly be done within the LTE module files (both .cc and .h) like point-topoint-helper, emu-epc-helper, lte-ue-net-device, epc-sgw-pgw-application, epc-enb-application, lte-enb-net-device etc. Then, the code analysis will be performed as done previously for MIPv6 code. The functional tests would follow bidirectional IPv6 packet transmission between remote host and the UE. The modification/rewriting code will create a patch that could enable IPv6 forwarding in the LTE data plane, enabling the UE to receive and use a /64 prefix, as stated in the standard. It is worth noticing that IP packets are tunnelled in the `core' network (i.e., all the EPC part), and their actual IP address is not used for UE identification in the core. As a consequence, IPv6 use in the `core' network, using ULAs or link-local addresses, could be planned if the previous development is faster than foreseen. This modification could also be simpler than expected, as it is not important to keep a dual stack communication in the core network, and using only IPv6 brings some direct benefits (like simplifying the use of multiple EPCs in a single script).
* '''Third,''' To ensure the code quality, the following testing approach could be used: Test MIPv6 handoff performance with the mixed link layer technologies (combination of Wi-Fi, WiMAX and LTE) case, multiple mobile node case, and multiple correspondent node case.

= Deliverables and Plan =
=== Deliverables: ===

-a basic MIPv6 module, aligned with RFC 6275 following ns-3 coding styles;

-a reviewed patch, fixing the IPv6 support issue in LTE;

-proper documentation and tests for the above-mentioned components.

=== Plan: ===

==== May 4 – May 29 (Before the official coding time): ====

-Familiarize myself completely with MIPv6, LTE (the IPv4 part), and the respective interactions.

-Study of the customized files of ns-3 lte and internet modules

-Familiarize myself with the ns-3 coding styles

During this period I will remain in constant touch with my mentor and the ns-3 community. I will remain active on IRC and Mailing lists to discuss and finalize on the modifications (if any) that needs to be on existing models and design of new module (if needed to fit cleanly with ns-3)

Thus with the help of my mentor I will become absolutely clear about my future goals, the final MIPv6 implementation that need to be done as well as the approach that I will follow to support IPv6 in lte model.

==== May 30 – June 26 (Official coding period starts): ====

-Refactor previous MIPv6 headers to RFC compliance header files

-Refactor all the classes to implement the corresponding header file functions

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the newly implemented MIPv6 module in various testing scenarios. The testing will be done with the systems having Wi-Fi and WiMAX link layer technology

-Sending the code for code review to the ns-3 team

After this stage, the standard ns-3 code revision can be started for the MIPv6 code part. Any change requested by the reviewers will be carried out in parallel with the following activities.

==== June 27 – July 24: ====

-Define new or, modify existing header files and cc files in LTE module in such a way that LTE module remains backward compatible with IPv4

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the LTE module

-Sending the code for code review to the ns-3 team

This will help in testing of the LTE module with IPv6 support for possible merge into the project main tree.

==== July 25 – August 21: ====

-Making further changes in the LTE module to support MIPv6 into it. Changes may be required in the other modules of ns-3 also.

-Testing the overall working in the testing scenarios having the combination of Wi-Fi and LTE

-Most of the time will be consumed for rigorous testing and bug fixes.

-Sending the code for code review to the ns-3 team

-Documentation updates.

= Weekly Reports =

=== May 30 - June 6 ===

1. Restructuring the MIPv6 code.

2. Testing the code in the multiple Mobile Node case

3. Changing the Home Agent functionality a little bit

4. Arise Tunnel Implementation Issue [how mobile node would use its home address for all of its data communication]

=== June 7 - June 13 ===

1. Resolved the issue of home address assignment to mobile node for all of its data communication. So, I have made some tricky callbacks in the L4 protocol a little bit. Now, traffic can be directed in both direction i.e. Mobile node to a web server and a web server to a mobile node

2. Also delete a lot of unnecessary files as well as lines in the code.

3. Tests have been done changing the location of different mobility entities. Almost all are successful. Those are included in "mipv6-test1-4.cc" in scratch of https://github.com/manoj24rana/MobileIPv6.

=== June 14 - June 20 ===

1. Done more tests

2. Add some more features such as defending home address and performing NS handling at HA as described in RFC 6275

3. Find an issue on RFC 6275 i.e. how to defend the mobile node's home address by home agent when it returns to its home network. Try to do something on the basis of ns-3 ipv6 implementation to resolve the issue.

=== June 21 - June 27 ===

1. Documentation on how my implementation differs from RFC 6275 as well as

2. Resolve the above issue

3. Sending the code for review.

=== June 28 - July 04 ===

1. Starting LTE IPv6 implementation part: understanding the end-to-end IPv4 part between UE and remote host, decoding it and discuss with my mentor for changing

2. Start writing code, at least one class modification

3. Test the change whether it is right.

=== July 05 - July 11 ===

1. Complete the modification in the lte module classes and also develop a small IPv6 dealing program to test

2. An issue arise i.e. Address Collision occurs at file: file=../src/internet/model/
ipv6-address-generator.cc, line=484". I am trying to resolve it.

3. Runs the previous IPv4 sample programs, which runs fine.

=== July 12 - July 18 ===

1. Resolve the IPv6 address collision issue in the LTE IPv6 support part.

2. I face another issue on handling multicast packets between UE sets and pgw i.e. those multicast packets are not passed between them as in the middle there is an enb.

3. Add the Sphinx documentation in the mipv6 module.

4. The Attributes and TraceSources are uploaded in mipv6 git.

=== July 19 - July 25 ===

1. Making some examples for the main mipv6 repo.

2. Add two tests in the main mipv6 repo.

3. mipv6 doc file further update.

4. Add and change tracesources and some functionalities in mipv6 model.

=== July 26 - August 1 ===

Finalize the MIPv6 code for review. I have added two nice tests replacing the previous tests, further update the mipv6 doc, trace sources, attributes, examples.
The codes are documented highly. Now the /doc/models/build/html dir contains the model documentation and the /doc/html creates doxygen for the mipv6 module.

=== August 2 - August 15 ===

1. Sent the MIPv6 code for review.

2. Solved LTE IPv6 packet sending issues.

3. Complete LTE IPv6 part, i.e. IPv6 packets are received and sent correctly.

4. Discuss with my mentor (Tommaso) elaborately about the next steps such that this implementation could be rebased in the main ns-3 dev quickly.

=== August 16 - August 22 ===

1. Update the LTE UE and PGW address assignment process in such a way that all IP addresses assigned by an EPC are derived from a base prefix (8 for IPv4 and 32 for IPv6) and each EPC holds a unique 16 bit IPv4 and 48 bit IPv6 subnet prefix to assign addresses to PGW and UEs. This address assignment process is made by keeping in mind the issues stated in https://www.nsnam.org/bugzilla/show_bug.cgi?id=1745 and https://groups.google.com/forum/#!topic/ns-3-users/Tc3IKky1OKo. So, now address duplication would not happen in case of more than one EPC as well as any time we could assign addresses without initializing the address helper. Also, user is given the flexibility to reassign the base 8 or, 32 bit address prefix at any time.

2. The LTE module is updated by IPv6 tests, documentation and examples. So, now the sample program is running and users can use them.

=== August 23 - August 29 ===

1. Submit the Google Work Product.

2. Send the LTE Code for review.

3. Try to resolve the reviewer's comment.

= Final Report for Google =
It has been an outstanding experience for me, spending this summer for GSoC project. I have spent almost all the time during this summer in the project. I have learned the first thing from this project is that I could do a lot more than my expectation. Secondly, the coding part of my project is based on some strong background theory part for which I had to remain constantly aware before starting any new coding. So, applying own logic and intuition becomes very challenging (whether it is appropriate) because standards may say something different. Third, debugging is the utmost part of this project because program may be logically correct, but debugging may say something if I have broken anything in the existing system or, not.

This final report contains all the links to all the works done over the summer. There have been total 19,000 lines of code with 146 commits contributed in my github repo. Several other users (almost 4-5) also urges for the project to be completed soon.

=== Work Product Link ===

This is the complete work product link with full ns-3.25 software:

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6

My contribution:

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/commit/7164250819b85ec2461e4c20667a516720eeddd5

=== Installation and Running the Work Product ===

1. Depending on your OS, install the ns-3 Prerequisites from this link: https://www.nsnam.org/wiki/Installation#Prerequisites.

2. Download the code from this repository: https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6 and extract it.

3. Make sure that you have installed all the perquisites to install ns-3.25.

4. Run the following commands in your cmd prompt to install it:

$ cd The_Project_Folder

$ cd ns-3.25

$ ./waf -d debug --enable-examples --enable-tests configure

$ ./waf

5. Running MIPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running MIPv6: mipv6-multiple.cc, mipv6-single.cc and mipv6-wifi-wimax.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run mipv6-multiple --vis

This will open a visualizer to see the output and the packet transmission in the background cmd prompt.

6. Running LTE IPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running LTE IPv6: lena-ipv6-ue-rh.cc, lena-ipv6-ue-ue.cc and lena-ipv6-addr-conf.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run lena-ipv6-ue-ue --vis

This will open a visualizer to see the output and the packet transmission in the background cmd prompt.

=== Documentation ===

Either, you follow the prepared documentation,

For MIPv6,

https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing

For LTE IPv6,

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/blob/master/ns-3.25/src/lte/doc/source/lte-design.rst and
https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/blob/master/ns-3.25/src/lte/doc/source/lte-user.rst

or, you could follow the manual for Creating Documentation here: https://www.nsnam.org/docs/manual/html/documentation.html. I have added the appropriate documentations within the code of the above repo of my implementation.

=== Work Flow ===

The following link will describe the weekly update of this project.

https://www.nsnam.org/wiki/GSOC2017MobileIp#Weekly_Reports

The flow of commits in the code could be found in the following link.

https://github.com/manoj24rana/MobileIPv6

=== Other Issues Resolved ===

I have resolved several other issues in ns-3 during this period as a part of my main implementation. Briefly, these are as follows.

1. Lack of IPv6 support for WiMAX module.

2. Duplicate IPv4 address collision problem in LTE module (https://groups.google.com/forum/#!topic/ns-3-users/Tc3IKky1OKo).

3. Affecting this problem (https://www.nsnam.org/bugzilla/show_bug.cgi?id=1745) in LTE IP address assignments.

=== Future Enhancement for this Project ===

1. LTE EPC part update to allow IP layer control packets. It will ease the IP layer bonding between LTE-LTE, LTE-WiFi and LTE-WiMAX.

2. Creating some LTE samples which can run multiple LTE networks in single user's simulation script. It requires cooperation with the existing LTE maintainers in ns-3.

3. Above all, the beauty of this project is that it is the implementation of the base IP mobility management protocol (MIPv6) in ns-3. The ns-3 users now can easily extend this feature to implement other such protocols, such as NEMO (RFC 3963), PMIPv6 (RFC 5213) etc. and also some upcoming schemes in 5G.

GSOC2017MobileIp

2017-08-28T04:21:50Z

Mkrana: /* Final Report for Google */

{{TOC}}

Return to [[GSOC2017AcceptedProjects | GSoC 2017 Accepted Projects]] page.

= Project overview =

* '''Project name:''' Mobile IPv6 Implementation with LTE support

* '''Student:''' [mailto:manoj24.rana@gmail.com Manoj Kumar Rana]

* '''Mentor:''' [mailto:tommypec@gmail.com Tommaso Pecorella]

* '''Abstract:''' The goal of the project is to implement a novel MIPv6 simulation model which can be integrated into ns-3. The project idea aims at testing the code in different network scenarios, containing different link layer technologies such as Wi-Fi, WiMAX and LTE. The current implementation of LTE does not have support of IPv6 in ns-3. So, the idea of testing MIPv6 code into LTE would follow IPv6 support implementation in LTE first and then the MIPv6 support. Thus, implementation of MIPv6 in ns-3 as the base mobility management solution and providing LTE support within it could help the current network researchers working on ns-3.

* '''Code:''' https://github.com/manoj24rana/MobileIPv6

* '''Documentation:'''
# Detail Description about the Implementation: http://www.sciencedirect.com/science/article/pii/S1569190X16302714
# Phase1 Documentation: https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing
# Phase2 Documentation: https://drive.google.com/open?id=0BziHE2fNAdZRbUZKN01Bd1Rjdk0

* '''About me:''' I am a PhD student in the School of Mobile Computing and Communications, Jadavpur University, India. About my research is given here: http://scholar.google.com/citations?user=qouvajAAAAAJ&hl=en.

= Technical Approach =
*'''First,''' I want to restructure the MIPv6 code, published in http://www.sciencedirect.com/science/article/pii/S1569190X16302714, to make it RFC 6275 compliance. To do the restructuring complete, the following approaches will be performed:
#Code refactoring: reorganizing internetstack, helper and header components of the MIPv6 module through modifying the internal functions, attributes and the callback variables.
#Code analysis: both static and dynamic analysis could be performed. The waf tool for code run, PyViz for visualization and tcpdump for pcap tracing could be used.
#Functional tests: The functional test would be performed in three phase: handoff performance testing, data packet transmission testing and both. Use cases like multiple mobile nodes, multiple correspondent node, different mobility model for the mobile node as well as heterogeneous link layer technologies (Wi-Fi and WiMAX) could be used.
#The code will be sent for the code review to the ns-3 team.
* '''Second,''' IPV6 support for LTE would be ensured as LTE currently, only supports IPv4. The changes would possibly be done within the LTE module files (both .cc and .h) like point-topoint-helper, emu-epc-helper, lte-ue-net-device, epc-sgw-pgw-application, epc-enb-application, lte-enb-net-device etc. Then, the code analysis will be performed as done previously for MIPv6 code. The functional tests would follow bidirectional IPv6 packet transmission between remote host and the UE. The modification/rewriting code will create a patch that could enable IPv6 forwarding in the LTE data plane, enabling the UE to receive and use a /64 prefix, as stated in the standard. It is worth noticing that IP packets are tunnelled in the `core' network (i.e., all the EPC part), and their actual IP address is not used for UE identification in the core. As a consequence, IPv6 use in the `core' network, using ULAs or link-local addresses, could be planned if the previous development is faster than foreseen. This modification could also be simpler than expected, as it is not important to keep a dual stack communication in the core network, and using only IPv6 brings some direct benefits (like simplifying the use of multiple EPCs in a single script).
* '''Third,''' To ensure the code quality, the following testing approach could be used: Test MIPv6 handoff performance with the mixed link layer technologies (combination of Wi-Fi, WiMAX and LTE) case, multiple mobile node case, and multiple correspondent node case.

= Deliverables and Plan =
=== Deliverables: ===

-a basic MIPv6 module, aligned with RFC 6275 following ns-3 coding styles;

-a reviewed patch, fixing the IPv6 support issue in LTE;

-proper documentation and tests for the above-mentioned components.

=== Plan: ===

==== May 4 – May 29 (Before the official coding time): ====

-Familiarize myself completely with MIPv6, LTE (the IPv4 part), and the respective interactions.

-Study of the customized files of ns-3 lte and internet modules

-Familiarize myself with the ns-3 coding styles

During this period I will remain in constant touch with my mentor and the ns-3 community. I will remain active on IRC and Mailing lists to discuss and finalize on the modifications (if any) that needs to be on existing models and design of new module (if needed to fit cleanly with ns-3)

Thus with the help of my mentor I will become absolutely clear about my future goals, the final MIPv6 implementation that need to be done as well as the approach that I will follow to support IPv6 in lte model.

==== May 30 – June 26 (Official coding period starts): ====

-Refactor previous MIPv6 headers to RFC compliance header files

-Refactor all the classes to implement the corresponding header file functions

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the newly implemented MIPv6 module in various testing scenarios. The testing will be done with the systems having Wi-Fi and WiMAX link layer technology

-Sending the code for code review to the ns-3 team

After this stage, the standard ns-3 code revision can be started for the MIPv6 code part. Any change requested by the reviewers will be carried out in parallel with the following activities.

==== June 27 – July 24: ====

-Define new or, modify existing header files and cc files in LTE module in such a way that LTE module remains backward compatible with IPv4

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the LTE module

-Sending the code for code review to the ns-3 team

This will help in testing of the LTE module with IPv6 support for possible merge into the project main tree.

==== July 25 – August 21: ====

-Making further changes in the LTE module to support MIPv6 into it. Changes may be required in the other modules of ns-3 also.

-Testing the overall working in the testing scenarios having the combination of Wi-Fi and LTE

-Most of the time will be consumed for rigorous testing and bug fixes.

-Sending the code for code review to the ns-3 team

-Documentation updates.

= Weekly Reports =

=== May 30 - June 6 ===

1. Restructuring the MIPv6 code.

2. Testing the code in the multiple Mobile Node case

3. Changing the Home Agent functionality a little bit

4. Arise Tunnel Implementation Issue [how mobile node would use its home address for all of its data communication]

=== June 7 - June 13 ===

1. Resolved the issue of home address assignment to mobile node for all of its data communication. So, I have made some tricky callbacks in the L4 protocol a little bit. Now, traffic can be directed in both direction i.e. Mobile node to a web server and a web server to a mobile node

2. Also delete a lot of unnecessary files as well as lines in the code.

3. Tests have been done changing the location of different mobility entities. Almost all are successful. Those are included in "mipv6-test1-4.cc" in scratch of https://github.com/manoj24rana/MobileIPv6.

=== June 14 - June 20 ===

1. Done more tests

2. Add some more features such as defending home address and performing NS handling at HA as described in RFC 6275

3. Find an issue on RFC 6275 i.e. how to defend the mobile node's home address by home agent when it returns to its home network. Try to do something on the basis of ns-3 ipv6 implementation to resolve the issue.

=== June 21 - June 27 ===

1. Documentation on how my implementation differs from RFC 6275 as well as

2. Resolve the above issue

3. Sending the code for review.

=== June 28 - July 04 ===

1. Starting LTE IPv6 implementation part: understanding the end-to-end IPv4 part between UE and remote host, decoding it and discuss with my mentor for changing

2. Start writing code, at least one class modification

3. Test the change whether it is right.

=== July 05 - July 11 ===

1. Complete the modification in the lte module classes and also develop a small IPv6 dealing program to test

2. An issue arise i.e. Address Collision occurs at file: file=../src/internet/model/
ipv6-address-generator.cc, line=484". I am trying to resolve it.

3. Runs the previous IPv4 sample programs, which runs fine.

=== July 12 - July 18 ===

1. Resolve the IPv6 address collision issue in the LTE IPv6 support part.

2. I face another issue on handling multicast packets between UE sets and pgw i.e. those multicast packets are not passed between them as in the middle there is an enb.

3. Add the Sphinx documentation in the mipv6 module.

4. The Attributes and TraceSources are uploaded in mipv6 git.

=== July 19 - July 25 ===

1. Making some examples for the main mipv6 repo.

2. Add two tests in the main mipv6 repo.

3. mipv6 doc file further update.

4. Add and change tracesources and some functionalities in mipv6 model.

=== July 26 - August 1 ===

Finalize the MIPv6 code for review. I have added two nice tests replacing the previous tests, further update the mipv6 doc, trace sources, attributes, examples.
The codes are documented highly. Now the /doc/models/build/html dir contains the model documentation and the /doc/html creates doxygen for the mipv6 module.

=== August 2 - August 15 ===

1. Sent the MIPv6 code for review.

2. Solved LTE IPv6 packet sending issues.

3. Complete LTE IPv6 part, i.e. IPv6 packets are received and sent correctly.

4. Discuss with my mentor (Tommaso) elaborately about the next steps such that this implementation could be rebased in the main ns-3 dev quickly.

=== August 16 - August 22 ===

1. Update the LTE UE and PGW address assignment process in such a way that all IP addresses assigned by an EPC are derived from a base prefix (8 for IPv4 and 32 for IPv6) and each EPC holds a unique 16 bit IPv4 and 48 bit IPv6 subnet prefix to assign addresses to PGW and UEs. This address assignment process is made by keeping in mind the issues stated in https://www.nsnam.org/bugzilla/show_bug.cgi?id=1745 and https://groups.google.com/forum/#!topic/ns-3-users/Tc3IKky1OKo. So, now address duplication would not happen in case of more than one EPC as well as any time we could assign addresses without initializing the address helper. Also, user is given the flexibility to reassign the base 8 or, 32 bit address prefix at any time.

2. The LTE module is updated by IPv6 tests, documentation and examples. So, now the sample program is running and users can use them.

=== August 23 - August 29 ===

1. Submit the Google Work Product.

2. Send the LTE Code for review.

3. Try to resolve the reviewer's comment.

= Final Report for Google =
Finally it is time for wrapping up my GSoC project and along with it a highly eventful summer. It has been an amazing experience. I’ve learned a lot over the summer, spending countless days and nights in a row to add new things to this game. The community has been more than helpful. I couldn’t have asked for more.

This wrap up post links to all the work done over the summer. There have been a total of 72 PRs and quite a few independent commits in the new modules I’ve created. With over 19,000 lines of code, this summer has boosted my Github stats to a whole new level.

=== Work Product Link ===

This is the complete work product link with full ns-3.25 software:

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6

My contribution:

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/commit/7164250819b85ec2461e4c20667a516720eeddd5

=== Installation and Running the Work Product ===

1. Depending on your OS, install the ns-3 Prerequisites from this link: https://www.nsnam.org/wiki/Installation#Prerequisites.

2. Download the code from this repository: https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6 and extract it.

3. Make sure that you have installed all the perquisites to install ns-3.25.

4. Run the following commands in your cmd prompt to install it:

$ cd The_Project_Folder

$ cd ns-3.25

$ ./waf -d debug --enable-examples --enable-tests configure

$ ./waf

5. Running MIPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running MIPv6: mipv6-multiple.cc, mipv6-single.cc and mipv6-wifi-wimax.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run mipv6-multiple --vis

This will open a visualizer to see the output and the packet transmission in the background cmd prompt.

6. Running LTE IPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running LTE IPv6: lena-ipv6-ue-rh.cc, lena-ipv6-ue-ue.cc and lena-ipv6-addr-conf.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run lena-ipv6-ue-ue --vis

This will open a visualizer to see the output and the packet transmission in the background cmd prompt.

=== Documentation ===

Either, you follow the prepared documentation,

For MIPv6,

https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing

For LTE IPv6,

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/blob/master/ns-3.25/src/lte/doc/source/lte-design.rst and
https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/blob/master/ns-3.25/src/lte/doc/source/lte-user.rst

or, you could follow the manual for Creating Documentation here: https://www.nsnam.org/docs/manual/html/documentation.html. I have added the appropriate documentations within the code of the above repo of my implementation.

=== Work Flow ===

The following link will describe the weekly update of this project.

https://www.nsnam.org/wiki/GSOC2017MobileIp#Weekly_Reports

The flow of commits in the code could be found in the following link.

https://github.com/manoj24rana/MobileIPv6

=== Other Issues Resolved ===

I have resolved several other issues in ns-3 during this period as a part of my main implementation. Briefly, these are as follows.

1. Lack of IPv6 support for WiMAX module.

2. Duplicate IPv4 address collision problem in LTE module (https://groups.google.com/forum/#!topic/ns-3-users/Tc3IKky1OKo).

3. Affecting this problem (https://www.nsnam.org/bugzilla/show_bug.cgi?id=1745) in LTE IP address assignments.

=== Future Enhancement for this Project ===

1. LTE EPC part update to allow IP layer control packets. It will ease the IP layer bonding between LTE-LTE, LTE-WiFi and LTE-WiMAX.

2. Creating some LTE samples which can run multiple LTE networks in single user's simulation script. It requires cooperation with the existing LTE maintainers in ns-3.

3. Above all, the beauty of this project is that it is the implementation of the base IP mobility management protocol (MIPv6) in ns-3. The ns-3 users now can easily extend this feature to implement other such protocols, such as NEMO (RFC 3963), PMIPv6 (RFC 5213) etc. and also some upcoming schemes in 5G.

GSOC2017MobileIp

2017-08-28T04:17:59Z

Mkrana: /* Future Enhancement for this Project */

{{TOC}}

Return to [[GSOC2017AcceptedProjects | GSoC 2017 Accepted Projects]] page.

= Project overview =

* '''Project name:''' Mobile IPv6 Implementation with LTE support

* '''Student:''' [mailto:manoj24.rana@gmail.com Manoj Kumar Rana]

* '''Mentor:''' [mailto:tommypec@gmail.com Tommaso Pecorella]

* '''Abstract:''' The goal of the project is to implement a novel MIPv6 simulation model which can be integrated into ns-3. The project idea aims at testing the code in different network scenarios, containing different link layer technologies such as Wi-Fi, WiMAX and LTE. The current implementation of LTE does not have support of IPv6 in ns-3. So, the idea of testing MIPv6 code into LTE would follow IPv6 support implementation in LTE first and then the MIPv6 support. Thus, implementation of MIPv6 in ns-3 as the base mobility management solution and providing LTE support within it could help the current network researchers working on ns-3.

* '''Code:''' https://github.com/manoj24rana/MobileIPv6

* '''Documentation:'''
# Detail Description about the Implementation: http://www.sciencedirect.com/science/article/pii/S1569190X16302714
# Phase1 Documentation: https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing
# Phase2 Documentation: https://drive.google.com/open?id=0BziHE2fNAdZRbUZKN01Bd1Rjdk0

* '''About me:''' I am a PhD student in the School of Mobile Computing and Communications, Jadavpur University, India. About my research is given here: http://scholar.google.com/citations?user=qouvajAAAAAJ&hl=en.

= Technical Approach =
*'''First,''' I want to restructure the MIPv6 code, published in http://www.sciencedirect.com/science/article/pii/S1569190X16302714, to make it RFC 6275 compliance. To do the restructuring complete, the following approaches will be performed:
#Code refactoring: reorganizing internetstack, helper and header components of the MIPv6 module through modifying the internal functions, attributes and the callback variables.
#Code analysis: both static and dynamic analysis could be performed. The waf tool for code run, PyViz for visualization and tcpdump for pcap tracing could be used.
#Functional tests: The functional test would be performed in three phase: handoff performance testing, data packet transmission testing and both. Use cases like multiple mobile nodes, multiple correspondent node, different mobility model for the mobile node as well as heterogeneous link layer technologies (Wi-Fi and WiMAX) could be used.
#The code will be sent for the code review to the ns-3 team.
* '''Second,''' IPV6 support for LTE would be ensured as LTE currently, only supports IPv4. The changes would possibly be done within the LTE module files (both .cc and .h) like point-topoint-helper, emu-epc-helper, lte-ue-net-device, epc-sgw-pgw-application, epc-enb-application, lte-enb-net-device etc. Then, the code analysis will be performed as done previously for MIPv6 code. The functional tests would follow bidirectional IPv6 packet transmission between remote host and the UE. The modification/rewriting code will create a patch that could enable IPv6 forwarding in the LTE data plane, enabling the UE to receive and use a /64 prefix, as stated in the standard. It is worth noticing that IP packets are tunnelled in the `core' network (i.e., all the EPC part), and their actual IP address is not used for UE identification in the core. As a consequence, IPv6 use in the `core' network, using ULAs or link-local addresses, could be planned if the previous development is faster than foreseen. This modification could also be simpler than expected, as it is not important to keep a dual stack communication in the core network, and using only IPv6 brings some direct benefits (like simplifying the use of multiple EPCs in a single script).
* '''Third,''' To ensure the code quality, the following testing approach could be used: Test MIPv6 handoff performance with the mixed link layer technologies (combination of Wi-Fi, WiMAX and LTE) case, multiple mobile node case, and multiple correspondent node case.

= Deliverables and Plan =
=== Deliverables: ===

-a basic MIPv6 module, aligned with RFC 6275 following ns-3 coding styles;

-a reviewed patch, fixing the IPv6 support issue in LTE;

-proper documentation and tests for the above-mentioned components.

=== Plan: ===

==== May 4 – May 29 (Before the official coding time): ====

-Familiarize myself completely with MIPv6, LTE (the IPv4 part), and the respective interactions.

-Study of the customized files of ns-3 lte and internet modules

-Familiarize myself with the ns-3 coding styles

During this period I will remain in constant touch with my mentor and the ns-3 community. I will remain active on IRC and Mailing lists to discuss and finalize on the modifications (if any) that needs to be on existing models and design of new module (if needed to fit cleanly with ns-3)

Thus with the help of my mentor I will become absolutely clear about my future goals, the final MIPv6 implementation that need to be done as well as the approach that I will follow to support IPv6 in lte model.

==== May 30 – June 26 (Official coding period starts): ====

-Refactor previous MIPv6 headers to RFC compliance header files

-Refactor all the classes to implement the corresponding header file functions

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the newly implemented MIPv6 module in various testing scenarios. The testing will be done with the systems having Wi-Fi and WiMAX link layer technology

-Sending the code for code review to the ns-3 team

After this stage, the standard ns-3 code revision can be started for the MIPv6 code part. Any change requested by the reviewers will be carried out in parallel with the following activities.

==== June 27 – July 24: ====

-Define new or, modify existing header files and cc files in LTE module in such a way that LTE module remains backward compatible with IPv4

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the LTE module

-Sending the code for code review to the ns-3 team

This will help in testing of the LTE module with IPv6 support for possible merge into the project main tree.

==== July 25 – August 21: ====

-Making further changes in the LTE module to support MIPv6 into it. Changes may be required in the other modules of ns-3 also.

-Testing the overall working in the testing scenarios having the combination of Wi-Fi and LTE

-Most of the time will be consumed for rigorous testing and bug fixes.

-Sending the code for code review to the ns-3 team

-Documentation updates.

= Weekly Reports =

=== May 30 - June 6 ===

1. Restructuring the MIPv6 code.

2. Testing the code in the multiple Mobile Node case

3. Changing the Home Agent functionality a little bit

4. Arise Tunnel Implementation Issue [how mobile node would use its home address for all of its data communication]

=== June 7 - June 13 ===

1. Resolved the issue of home address assignment to mobile node for all of its data communication. So, I have made some tricky callbacks in the L4 protocol a little bit. Now, traffic can be directed in both direction i.e. Mobile node to a web server and a web server to a mobile node

2. Also delete a lot of unnecessary files as well as lines in the code.

3. Tests have been done changing the location of different mobility entities. Almost all are successful. Those are included in "mipv6-test1-4.cc" in scratch of https://github.com/manoj24rana/MobileIPv6.

=== June 14 - June 20 ===

1. Done more tests

2. Add some more features such as defending home address and performing NS handling at HA as described in RFC 6275

3. Find an issue on RFC 6275 i.e. how to defend the mobile node's home address by home agent when it returns to its home network. Try to do something on the basis of ns-3 ipv6 implementation to resolve the issue.

=== June 21 - June 27 ===

1. Documentation on how my implementation differs from RFC 6275 as well as

2. Resolve the above issue

3. Sending the code for review.

=== June 28 - July 04 ===

1. Starting LTE IPv6 implementation part: understanding the end-to-end IPv4 part between UE and remote host, decoding it and discuss with my mentor for changing

2. Start writing code, at least one class modification

3. Test the change whether it is right.

=== July 05 - July 11 ===

1. Complete the modification in the lte module classes and also develop a small IPv6 dealing program to test

2. An issue arise i.e. Address Collision occurs at file: file=../src/internet/model/
ipv6-address-generator.cc, line=484". I am trying to resolve it.

3. Runs the previous IPv4 sample programs, which runs fine.

=== July 12 - July 18 ===

1. Resolve the IPv6 address collision issue in the LTE IPv6 support part.

2. I face another issue on handling multicast packets between UE sets and pgw i.e. those multicast packets are not passed between them as in the middle there is an enb.

3. Add the Sphinx documentation in the mipv6 module.

4. The Attributes and TraceSources are uploaded in mipv6 git.

=== July 19 - July 25 ===

1. Making some examples for the main mipv6 repo.

2. Add two tests in the main mipv6 repo.

3. mipv6 doc file further update.

4. Add and change tracesources and some functionalities in mipv6 model.

=== July 26 - August 1 ===

Finalize the MIPv6 code for review. I have added two nice tests replacing the previous tests, further update the mipv6 doc, trace sources, attributes, examples.
The codes are documented highly. Now the /doc/models/build/html dir contains the model documentation and the /doc/html creates doxygen for the mipv6 module.

=== August 2 - August 15 ===

1. Sent the MIPv6 code for review.

2. Solved LTE IPv6 packet sending issues.

3. Complete LTE IPv6 part, i.e. IPv6 packets are received and sent correctly.

4. Discuss with my mentor (Tommaso) elaborately about the next steps such that this implementation could be rebased in the main ns-3 dev quickly.

=== August 16 - August 22 ===

1. Update the LTE UE and PGW address assignment process in such a way that all IP addresses assigned by an EPC are derived from a base prefix (8 for IPv4 and 32 for IPv6) and each EPC holds a unique 16 bit IPv4 and 48 bit IPv6 subnet prefix to assign addresses to PGW and UEs. This address assignment process is made by keeping in mind the issues stated in https://www.nsnam.org/bugzilla/show_bug.cgi?id=1745 and https://groups.google.com/forum/#!topic/ns-3-users/Tc3IKky1OKo. So, now address duplication would not happen in case of more than one EPC as well as any time we could assign addresses without initializing the address helper. Also, user is given the flexibility to reassign the base 8 or, 32 bit address prefix at any time.

2. The LTE module is updated by IPv6 tests, documentation and examples. So, now the sample program is running and users can use them.

=== August 23 - August 29 ===

1. Submit the Google Work Product.

2. Send the LTE Code for review.

3. Try to resolve the reviewer's comment.

= Final Report for Google =

=== Work Product Link ===

This is the complete work product link with full ns-3.25 software:

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6

My contribution:

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/commit/7164250819b85ec2461e4c20667a516720eeddd5

=== Installation and Running the Work Product ===

1. Depending on your OS, install the ns-3 Prerequisites from this link: https://www.nsnam.org/wiki/Installation#Prerequisites.

2. Download the code from this repository: https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6 and extract it.

3. Make sure that you have installed all the perquisites to install ns-3.25.

4. Run the following commands in your cmd prompt to install it:

$ cd The_Project_Folder

$ cd ns-3.25

$ ./waf -d debug --enable-examples --enable-tests configure

$ ./waf

5. Running MIPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running MIPv6: mipv6-multiple.cc, mipv6-single.cc and mipv6-wifi-wimax.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run mipv6-multiple --vis

This will open a visualizer to see the output and the packet transmission in the background cmd prompt.

6. Running LTE IPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running LTE IPv6: lena-ipv6-ue-rh.cc, lena-ipv6-ue-ue.cc and lena-ipv6-addr-conf.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run lena-ipv6-ue-ue --vis

This will open a visualizer to see the output and the packet transmission in the background cmd prompt.

=== Documentation ===

Either, you follow the prepared documentation,

For MIPv6,

https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing

For LTE IPv6,

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/blob/master/ns-3.25/src/lte/doc/source/lte-design.rst and
https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/blob/master/ns-3.25/src/lte/doc/source/lte-user.rst

or, you could follow the manual for Creating Documentation here: https://www.nsnam.org/docs/manual/html/documentation.html. I have added the appropriate documentations within the code of the above repo of my implementation.

=== Work Flow ===

The following link will describe the weekly update of this project.

https://www.nsnam.org/wiki/GSOC2017MobileIp#Weekly_Reports

The flow of commits in the code could be found in the following link.

https://github.com/manoj24rana/MobileIPv6

=== Other Issues Resolved ===

I have resolved several other issues in ns-3 during this period as a part of my main implementation. Briefly, these are as follows.

1. Lack of IPv6 support for WiMAX module.

2. Duplicate IPv4 address collision problem in LTE module (https://groups.google.com/forum/#!topic/ns-3-users/Tc3IKky1OKo).

3. Affecting this problem (https://www.nsnam.org/bugzilla/show_bug.cgi?id=1745) in LTE IP address assignments.

=== Future Enhancement for this Project ===

1. LTE EPC part update to allow IP layer control packets. It will ease the IP layer bonding between LTE-LTE, LTE-WiFi and LTE-WiMAX.

2. Creating some LTE samples which can run multiple LTE networks in single user's simulation script. It requires cooperation with the existing LTE maintainers in ns-3.

3. Above all, the beauty of this project is that it is the implementation of the base IP mobility management protocol (MIPv6) in ns-3. The ns-3 users now can easily extend this feature to implement other such protocols, such as NEMO (RFC 3963), PMIPv6 (RFC 5213) etc. and also some upcoming schemes in 5G.

GSOC2017MobileIp

2017-08-28T04:15:25Z

Mkrana: /* Final Report for Google */

{{TOC}}

Return to [[GSOC2017AcceptedProjects | GSoC 2017 Accepted Projects]] page.

= Project overview =

* '''Project name:''' Mobile IPv6 Implementation with LTE support

* '''Student:''' [mailto:manoj24.rana@gmail.com Manoj Kumar Rana]

* '''Mentor:''' [mailto:tommypec@gmail.com Tommaso Pecorella]

* '''Abstract:''' The goal of the project is to implement a novel MIPv6 simulation model which can be integrated into ns-3. The project idea aims at testing the code in different network scenarios, containing different link layer technologies such as Wi-Fi, WiMAX and LTE. The current implementation of LTE does not have support of IPv6 in ns-3. So, the idea of testing MIPv6 code into LTE would follow IPv6 support implementation in LTE first and then the MIPv6 support. Thus, implementation of MIPv6 in ns-3 as the base mobility management solution and providing LTE support within it could help the current network researchers working on ns-3.

* '''Code:''' https://github.com/manoj24rana/MobileIPv6

* '''Documentation:'''
# Detail Description about the Implementation: http://www.sciencedirect.com/science/article/pii/S1569190X16302714
# Phase1 Documentation: https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing
# Phase2 Documentation: https://drive.google.com/open?id=0BziHE2fNAdZRbUZKN01Bd1Rjdk0

* '''About me:''' I am a PhD student in the School of Mobile Computing and Communications, Jadavpur University, India. About my research is given here: http://scholar.google.com/citations?user=qouvajAAAAAJ&hl=en.

= Technical Approach =
*'''First,''' I want to restructure the MIPv6 code, published in http://www.sciencedirect.com/science/article/pii/S1569190X16302714, to make it RFC 6275 compliance. To do the restructuring complete, the following approaches will be performed:
#Code refactoring: reorganizing internetstack, helper and header components of the MIPv6 module through modifying the internal functions, attributes and the callback variables.
#Code analysis: both static and dynamic analysis could be performed. The waf tool for code run, PyViz for visualization and tcpdump for pcap tracing could be used.
#Functional tests: The functional test would be performed in three phase: handoff performance testing, data packet transmission testing and both. Use cases like multiple mobile nodes, multiple correspondent node, different mobility model for the mobile node as well as heterogeneous link layer technologies (Wi-Fi and WiMAX) could be used.
#The code will be sent for the code review to the ns-3 team.
* '''Second,''' IPV6 support for LTE would be ensured as LTE currently, only supports IPv4. The changes would possibly be done within the LTE module files (both .cc and .h) like point-topoint-helper, emu-epc-helper, lte-ue-net-device, epc-sgw-pgw-application, epc-enb-application, lte-enb-net-device etc. Then, the code analysis will be performed as done previously for MIPv6 code. The functional tests would follow bidirectional IPv6 packet transmission between remote host and the UE. The modification/rewriting code will create a patch that could enable IPv6 forwarding in the LTE data plane, enabling the UE to receive and use a /64 prefix, as stated in the standard. It is worth noticing that IP packets are tunnelled in the `core' network (i.e., all the EPC part), and their actual IP address is not used for UE identification in the core. As a consequence, IPv6 use in the `core' network, using ULAs or link-local addresses, could be planned if the previous development is faster than foreseen. This modification could also be simpler than expected, as it is not important to keep a dual stack communication in the core network, and using only IPv6 brings some direct benefits (like simplifying the use of multiple EPCs in a single script).
* '''Third,''' To ensure the code quality, the following testing approach could be used: Test MIPv6 handoff performance with the mixed link layer technologies (combination of Wi-Fi, WiMAX and LTE) case, multiple mobile node case, and multiple correspondent node case.

= Deliverables and Plan =
=== Deliverables: ===

-a basic MIPv6 module, aligned with RFC 6275 following ns-3 coding styles;

-a reviewed patch, fixing the IPv6 support issue in LTE;

-proper documentation and tests for the above-mentioned components.

=== Plan: ===

==== May 4 – May 29 (Before the official coding time): ====

-Familiarize myself completely with MIPv6, LTE (the IPv4 part), and the respective interactions.

-Study of the customized files of ns-3 lte and internet modules

-Familiarize myself with the ns-3 coding styles

During this period I will remain in constant touch with my mentor and the ns-3 community. I will remain active on IRC and Mailing lists to discuss and finalize on the modifications (if any) that needs to be on existing models and design of new module (if needed to fit cleanly with ns-3)

Thus with the help of my mentor I will become absolutely clear about my future goals, the final MIPv6 implementation that need to be done as well as the approach that I will follow to support IPv6 in lte model.

==== May 30 – June 26 (Official coding period starts): ====

-Refactor previous MIPv6 headers to RFC compliance header files

-Refactor all the classes to implement the corresponding header file functions

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the newly implemented MIPv6 module in various testing scenarios. The testing will be done with the systems having Wi-Fi and WiMAX link layer technology

-Sending the code for code review to the ns-3 team

After this stage, the standard ns-3 code revision can be started for the MIPv6 code part. Any change requested by the reviewers will be carried out in parallel with the following activities.

==== June 27 – July 24: ====

-Define new or, modify existing header files and cc files in LTE module in such a way that LTE module remains backward compatible with IPv4

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the LTE module

-Sending the code for code review to the ns-3 team

This will help in testing of the LTE module with IPv6 support for possible merge into the project main tree.

==== July 25 – August 21: ====

-Making further changes in the LTE module to support MIPv6 into it. Changes may be required in the other modules of ns-3 also.

-Testing the overall working in the testing scenarios having the combination of Wi-Fi and LTE

-Most of the time will be consumed for rigorous testing and bug fixes.

-Sending the code for code review to the ns-3 team

-Documentation updates.

= Weekly Reports =

=== May 30 - June 6 ===

1. Restructuring the MIPv6 code.

2. Testing the code in the multiple Mobile Node case

3. Changing the Home Agent functionality a little bit

4. Arise Tunnel Implementation Issue [how mobile node would use its home address for all of its data communication]

=== June 7 - June 13 ===

1. Resolved the issue of home address assignment to mobile node for all of its data communication. So, I have made some tricky callbacks in the L4 protocol a little bit. Now, traffic can be directed in both direction i.e. Mobile node to a web server and a web server to a mobile node

2. Also delete a lot of unnecessary files as well as lines in the code.

3. Tests have been done changing the location of different mobility entities. Almost all are successful. Those are included in "mipv6-test1-4.cc" in scratch of https://github.com/manoj24rana/MobileIPv6.

=== June 14 - June 20 ===

1. Done more tests

2. Add some more features such as defending home address and performing NS handling at HA as described in RFC 6275

3. Find an issue on RFC 6275 i.e. how to defend the mobile node's home address by home agent when it returns to its home network. Try to do something on the basis of ns-3 ipv6 implementation to resolve the issue.

=== June 21 - June 27 ===

1. Documentation on how my implementation differs from RFC 6275 as well as

2. Resolve the above issue

3. Sending the code for review.

=== June 28 - July 04 ===

1. Starting LTE IPv6 implementation part: understanding the end-to-end IPv4 part between UE and remote host, decoding it and discuss with my mentor for changing

2. Start writing code, at least one class modification

3. Test the change whether it is right.

=== July 05 - July 11 ===

1. Complete the modification in the lte module classes and also develop a small IPv6 dealing program to test

2. An issue arise i.e. Address Collision occurs at file: file=../src/internet/model/
ipv6-address-generator.cc, line=484". I am trying to resolve it.

3. Runs the previous IPv4 sample programs, which runs fine.

=== July 12 - July 18 ===

1. Resolve the IPv6 address collision issue in the LTE IPv6 support part.

2. I face another issue on handling multicast packets between UE sets and pgw i.e. those multicast packets are not passed between them as in the middle there is an enb.

3. Add the Sphinx documentation in the mipv6 module.

4. The Attributes and TraceSources are uploaded in mipv6 git.

=== July 19 - July 25 ===

1. Making some examples for the main mipv6 repo.

2. Add two tests in the main mipv6 repo.

3. mipv6 doc file further update.

4. Add and change tracesources and some functionalities in mipv6 model.

=== July 26 - August 1 ===

Finalize the MIPv6 code for review. I have added two nice tests replacing the previous tests, further update the mipv6 doc, trace sources, attributes, examples.
The codes are documented highly. Now the /doc/models/build/html dir contains the model documentation and the /doc/html creates doxygen for the mipv6 module.

=== August 2 - August 15 ===

1. Sent the MIPv6 code for review.

2. Solved LTE IPv6 packet sending issues.

3. Complete LTE IPv6 part, i.e. IPv6 packets are received and sent correctly.

4. Discuss with my mentor (Tommaso) elaborately about the next steps such that this implementation could be rebased in the main ns-3 dev quickly.

=== August 16 - August 22 ===

1. Update the LTE UE and PGW address assignment process in such a way that all IP addresses assigned by an EPC are derived from a base prefix (8 for IPv4 and 32 for IPv6) and each EPC holds a unique 16 bit IPv4 and 48 bit IPv6 subnet prefix to assign addresses to PGW and UEs. This address assignment process is made by keeping in mind the issues stated in https://www.nsnam.org/bugzilla/show_bug.cgi?id=1745 and https://groups.google.com/forum/#!topic/ns-3-users/Tc3IKky1OKo. So, now address duplication would not happen in case of more than one EPC as well as any time we could assign addresses without initializing the address helper. Also, user is given the flexibility to reassign the base 8 or, 32 bit address prefix at any time.

2. The LTE module is updated by IPv6 tests, documentation and examples. So, now the sample program is running and users can use them.

=== August 23 - August 29 ===

1. Submit the Google Work Product.

2. Send the LTE Code for review.

3. Try to resolve the reviewer's comment.

= Final Report for Google =

=== Work Product Link ===

This is the complete work product link with full ns-3.25 software:

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6

My contribution:

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/commit/7164250819b85ec2461e4c20667a516720eeddd5

=== Installation and Running the Work Product ===

1. Depending on your OS, install the ns-3 Prerequisites from this link: https://www.nsnam.org/wiki/Installation#Prerequisites.

2. Download the code from this repository: https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6 and extract it.

3. Make sure that you have installed all the perquisites to install ns-3.25.

4. Run the following commands in your cmd prompt to install it:

$ cd The_Project_Folder

$ cd ns-3.25

$ ./waf -d debug --enable-examples --enable-tests configure

$ ./waf

5. Running MIPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running MIPv6: mipv6-multiple.cc, mipv6-single.cc and mipv6-wifi-wimax.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run mipv6-multiple --vis

This will open a visualizer to see the output and the packet transmission in the background cmd prompt.

6. Running LTE IPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running LTE IPv6: lena-ipv6-ue-rh.cc, lena-ipv6-ue-ue.cc and lena-ipv6-addr-conf.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run lena-ipv6-ue-ue --vis

This will open a visualizer to see the output and the packet transmission in the background cmd prompt.

=== Documentation ===

Either, you follow the prepared documentation,

For MIPv6,

https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing

For LTE IPv6,

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/blob/master/ns-3.25/src/lte/doc/source/lte-design.rst and
https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/blob/master/ns-3.25/src/lte/doc/source/lte-user.rst

or, you could follow the manual for Creating Documentation here: https://www.nsnam.org/docs/manual/html/documentation.html. I have added the appropriate documentations within the code of the above repo of my implementation.

=== Work Flow ===

The following link will describe the weekly update of this project.

https://www.nsnam.org/wiki/GSOC2017MobileIp#Weekly_Reports

The flow of commits in the code could be found in the following link.

https://github.com/manoj24rana/MobileIPv6

=== Other Issues Resolved ===

I have resolved several other issues in ns-3 during this period as a part of my main implementation. Briefly, these are as follows.

1. Lack of IPv6 support for WiMAX module.

2. Duplicate IPv4 address collision problem in LTE module (https://groups.google.com/forum/#!topic/ns-3-users/Tc3IKky1OKo).

3. Affecting this problem (https://www.nsnam.org/bugzilla/show_bug.cgi?id=1745) in LTE IP address assignments.

=== Future Enhancement for this Project ===

1. LTE EPC part update to allow IP layer control packets. It will ease the IP layer bonding between LTE-LTE, LTE-WiFi and LTE-WiMAX.

2. Creating some LTE samples which can run multiple LTE networks in single user's simulation script. It requires cooperation with the existing LTE maintainers in ns-3.

3. Above all, the beauty of this project is that it is the implementation of the base IP mobility management protocol (MIPv6) in ns-3. The ns-3 users now can easily extend this feature to implement other such protocols, such as NEMO (RFC 3963), PMIPv6 (RFC 5213) etc. and also some upcoming schemes.

GSOC2017MobileIp

2017-08-28T03:56:22Z

Mkrana: /* Final Report for Google */

{{TOC}}

Return to [[GSOC2017AcceptedProjects | GSoC 2017 Accepted Projects]] page.

= Project overview =

* '''Project name:''' Mobile IPv6 Implementation with LTE support

* '''Student:''' [mailto:manoj24.rana@gmail.com Manoj Kumar Rana]

* '''Mentor:''' [mailto:tommypec@gmail.com Tommaso Pecorella]

* '''Abstract:''' The goal of the project is to implement a novel MIPv6 simulation model which can be integrated into ns-3. The project idea aims at testing the code in different network scenarios, containing different link layer technologies such as Wi-Fi, WiMAX and LTE. The current implementation of LTE does not have support of IPv6 in ns-3. So, the idea of testing MIPv6 code into LTE would follow IPv6 support implementation in LTE first and then the MIPv6 support. Thus, implementation of MIPv6 in ns-3 as the base mobility management solution and providing LTE support within it could help the current network researchers working on ns-3.

* '''Code:''' https://github.com/manoj24rana/MobileIPv6

* '''Documentation:'''
# Detail Description about the Implementation: http://www.sciencedirect.com/science/article/pii/S1569190X16302714
# Phase1 Documentation: https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing
# Phase2 Documentation: https://drive.google.com/open?id=0BziHE2fNAdZRbUZKN01Bd1Rjdk0

* '''About me:''' I am a PhD student in the School of Mobile Computing and Communications, Jadavpur University, India. About my research is given here: http://scholar.google.com/citations?user=qouvajAAAAAJ&hl=en.

= Technical Approach =
*'''First,''' I want to restructure the MIPv6 code, published in http://www.sciencedirect.com/science/article/pii/S1569190X16302714, to make it RFC 6275 compliance. To do the restructuring complete, the following approaches will be performed:
#Code refactoring: reorganizing internetstack, helper and header components of the MIPv6 module through modifying the internal functions, attributes and the callback variables.
#Code analysis: both static and dynamic analysis could be performed. The waf tool for code run, PyViz for visualization and tcpdump for pcap tracing could be used.
#Functional tests: The functional test would be performed in three phase: handoff performance testing, data packet transmission testing and both. Use cases like multiple mobile nodes, multiple correspondent node, different mobility model for the mobile node as well as heterogeneous link layer technologies (Wi-Fi and WiMAX) could be used.
#The code will be sent for the code review to the ns-3 team.
* '''Second,''' IPV6 support for LTE would be ensured as LTE currently, only supports IPv4. The changes would possibly be done within the LTE module files (both .cc and .h) like point-topoint-helper, emu-epc-helper, lte-ue-net-device, epc-sgw-pgw-application, epc-enb-application, lte-enb-net-device etc. Then, the code analysis will be performed as done previously for MIPv6 code. The functional tests would follow bidirectional IPv6 packet transmission between remote host and the UE. The modification/rewriting code will create a patch that could enable IPv6 forwarding in the LTE data plane, enabling the UE to receive and use a /64 prefix, as stated in the standard. It is worth noticing that IP packets are tunnelled in the `core' network (i.e., all the EPC part), and their actual IP address is not used for UE identification in the core. As a consequence, IPv6 use in the `core' network, using ULAs or link-local addresses, could be planned if the previous development is faster than foreseen. This modification could also be simpler than expected, as it is not important to keep a dual stack communication in the core network, and using only IPv6 brings some direct benefits (like simplifying the use of multiple EPCs in a single script).
* '''Third,''' To ensure the code quality, the following testing approach could be used: Test MIPv6 handoff performance with the mixed link layer technologies (combination of Wi-Fi, WiMAX and LTE) case, multiple mobile node case, and multiple correspondent node case.

= Deliverables and Plan =
=== Deliverables: ===

-a basic MIPv6 module, aligned with RFC 6275 following ns-3 coding styles;

-a reviewed patch, fixing the IPv6 support issue in LTE;

-proper documentation and tests for the above-mentioned components.

=== Plan: ===

==== May 4 – May 29 (Before the official coding time): ====

-Familiarize myself completely with MIPv6, LTE (the IPv4 part), and the respective interactions.

-Study of the customized files of ns-3 lte and internet modules

-Familiarize myself with the ns-3 coding styles

During this period I will remain in constant touch with my mentor and the ns-3 community. I will remain active on IRC and Mailing lists to discuss and finalize on the modifications (if any) that needs to be on existing models and design of new module (if needed to fit cleanly with ns-3)

Thus with the help of my mentor I will become absolutely clear about my future goals, the final MIPv6 implementation that need to be done as well as the approach that I will follow to support IPv6 in lte model.

==== May 30 – June 26 (Official coding period starts): ====

-Refactor previous MIPv6 headers to RFC compliance header files

-Refactor all the classes to implement the corresponding header file functions

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the newly implemented MIPv6 module in various testing scenarios. The testing will be done with the systems having Wi-Fi and WiMAX link layer technology

-Sending the code for code review to the ns-3 team

After this stage, the standard ns-3 code revision can be started for the MIPv6 code part. Any change requested by the reviewers will be carried out in parallel with the following activities.

==== June 27 – July 24: ====

-Define new or, modify existing header files and cc files in LTE module in such a way that LTE module remains backward compatible with IPv4

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the LTE module

-Sending the code for code review to the ns-3 team

This will help in testing of the LTE module with IPv6 support for possible merge into the project main tree.

==== July 25 – August 21: ====

-Making further changes in the LTE module to support MIPv6 into it. Changes may be required in the other modules of ns-3 also.

-Testing the overall working in the testing scenarios having the combination of Wi-Fi and LTE

-Most of the time will be consumed for rigorous testing and bug fixes.

-Sending the code for code review to the ns-3 team

-Documentation updates.

= Weekly Reports =

=== May 30 - June 6 ===

1. Restructuring the MIPv6 code.

2. Testing the code in the multiple Mobile Node case

3. Changing the Home Agent functionality a little bit

4. Arise Tunnel Implementation Issue [how mobile node would use its home address for all of its data communication]

=== June 7 - June 13 ===

1. Resolved the issue of home address assignment to mobile node for all of its data communication. So, I have made some tricky callbacks in the L4 protocol a little bit. Now, traffic can be directed in both direction i.e. Mobile node to a web server and a web server to a mobile node

2. Also delete a lot of unnecessary files as well as lines in the code.

3. Tests have been done changing the location of different mobility entities. Almost all are successful. Those are included in "mipv6-test1-4.cc" in scratch of https://github.com/manoj24rana/MobileIPv6.

=== June 14 - June 20 ===

1. Done more tests

2. Add some more features such as defending home address and performing NS handling at HA as described in RFC 6275

3. Find an issue on RFC 6275 i.e. how to defend the mobile node's home address by home agent when it returns to its home network. Try to do something on the basis of ns-3 ipv6 implementation to resolve the issue.

=== June 21 - June 27 ===

1. Documentation on how my implementation differs from RFC 6275 as well as

2. Resolve the above issue

3. Sending the code for review.

=== June 28 - July 04 ===

1. Starting LTE IPv6 implementation part: understanding the end-to-end IPv4 part between UE and remote host, decoding it and discuss with my mentor for changing

2. Start writing code, at least one class modification

3. Test the change whether it is right.

=== July 05 - July 11 ===

1. Complete the modification in the lte module classes and also develop a small IPv6 dealing program to test

2. An issue arise i.e. Address Collision occurs at file: file=../src/internet/model/
ipv6-address-generator.cc, line=484". I am trying to resolve it.

3. Runs the previous IPv4 sample programs, which runs fine.

=== July 12 - July 18 ===

1. Resolve the IPv6 address collision issue in the LTE IPv6 support part.

2. I face another issue on handling multicast packets between UE sets and pgw i.e. those multicast packets are not passed between them as in the middle there is an enb.

3. Add the Sphinx documentation in the mipv6 module.

4. The Attributes and TraceSources are uploaded in mipv6 git.

=== July 19 - July 25 ===

1. Making some examples for the main mipv6 repo.

2. Add two tests in the main mipv6 repo.

3. mipv6 doc file further update.

4. Add and change tracesources and some functionalities in mipv6 model.

=== July 26 - August 1 ===

Finalize the MIPv6 code for review. I have added two nice tests replacing the previous tests, further update the mipv6 doc, trace sources, attributes, examples.
The codes are documented highly. Now the /doc/models/build/html dir contains the model documentation and the /doc/html creates doxygen for the mipv6 module.

=== August 2 - August 15 ===

1. Sent the MIPv6 code for review.

2. Solved LTE IPv6 packet sending issues.

3. Complete LTE IPv6 part, i.e. IPv6 packets are received and sent correctly.

4. Discuss with my mentor (Tommaso) elaborately about the next steps such that this implementation could be rebased in the main ns-3 dev quickly.

=== August 16 - August 22 ===

1. Update the LTE UE and PGW address assignment process in such a way that all IP addresses assigned by an EPC are derived from a base prefix (8 for IPv4 and 32 for IPv6) and each EPC holds a unique 16 bit IPv4 and 48 bit IPv6 subnet prefix to assign addresses to PGW and UEs. This address assignment process is made by keeping in mind the issues stated in https://www.nsnam.org/bugzilla/show_bug.cgi?id=1745 and https://groups.google.com/forum/#!topic/ns-3-users/Tc3IKky1OKo. So, now address duplication would not happen in case of more than one EPC as well as any time we could assign addresses without initializing the address helper. Also, user is given the flexibility to reassign the base 8 or, 32 bit address prefix at any time.

2. The LTE module is updated by IPv6 tests, documentation and examples. So, now the sample program is running and users can use them.

=== August 23 - August 29 ===

1. Submit the Google Work Product.

2. Send the LTE Code for review.

3. Try to resolve the reviewer's comment.

= Final Report for Google =

=== Work Product Link ===

This is the complete work product link with full ns-3.25 software:

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6

My contribution:

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/commit/7164250819b85ec2461e4c20667a516720eeddd5

=== Installation and Running the Work Product ===

1. Depending on your OS, install the ns-3 Prerequisites from this link: https://www.nsnam.org/wiki/Installation#Prerequisites.

2. Download the code from this repository: https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6 and extract it.

3. Make sure that you have installed all the perquisites to install ns-3.25.

4. Run the following commands in your cmd prompt to install it:

$ cd The_Project_Folder

$ cd ns-3.25

$ ./waf -d debug --enable-examples --enable-tests configure

$ ./waf

5. Running MIPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running MIPv6: mipv6-multiple.cc, mipv6-single.cc and mipv6-wifi-wimax.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run mipv6-multiple --vis

This will open a visualizer to see the output and the packet transmission in the background cmd prompt.

6. Running LTE IPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running LTE IPv6: lena-ipv6-ue-rh.cc, lena-ipv6-ue-ue.cc and lena-ipv6-addr-conf.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run lena-ipv6-ue-ue --vis

This will open a visualizer to see the output and the packet transmission in the background cmd prompt.

=== Documentation ===

Either, you follow the prepared documentation,

For MIPv6,

https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing

For LTE IPv6,

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/blob/master/ns-3.25/src/lte/doc/source/lte-design.rst and
https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/blob/master/ns-3.25/src/lte/doc/source/lte-user.rst

or, you could follow the manual for Creating Documentation here: https://www.nsnam.org/docs/manual/html/documentation.html. I have added the appropriate documentations within the code of the above repo of my implementation.

=== Work Flow ===

The following link will describe the weekly update of this project.

https://www.nsnam.org/wiki/GSOC2017MobileIp#Weekly_Reports

The flow of commits in the code could be found in the following link.

https://github.com/manoj24rana/MobileIPv6

=== Other Issues Resolved ===

I have resolved several other issues in ns-3 during this period as a part of my main implementation. Briefly, these are as follows.

1. Lack of IPv6 support for WiMAX module.

2. Duplicate IPv4 address collision problem in LTE module (https://groups.google.com/forum/#!topic/ns-3-users/Tc3IKky1OKo).

3. Affecting this problem (https://www.nsnam.org/bugzilla/show_bug.cgi?id=1745) in LTE IP address assignments.

GSOC2017MobileIp

2017-08-28T03:55:52Z

Mkrana: /* Work Product Link */

{{TOC}}

Return to [[GSOC2017AcceptedProjects | GSoC 2017 Accepted Projects]] page.

= Project overview =

* '''Project name:''' Mobile IPv6 Implementation with LTE support

* '''Student:''' [mailto:manoj24.rana@gmail.com Manoj Kumar Rana]

* '''Mentor:''' [mailto:tommypec@gmail.com Tommaso Pecorella]

* '''Abstract:''' The goal of the project is to implement a novel MIPv6 simulation model which can be integrated into ns-3. The project idea aims at testing the code in different network scenarios, containing different link layer technologies such as Wi-Fi, WiMAX and LTE. The current implementation of LTE does not have support of IPv6 in ns-3. So, the idea of testing MIPv6 code into LTE would follow IPv6 support implementation in LTE first and then the MIPv6 support. Thus, implementation of MIPv6 in ns-3 as the base mobility management solution and providing LTE support within it could help the current network researchers working on ns-3.

* '''Code:''' https://github.com/manoj24rana/MobileIPv6

* '''Documentation:'''
# Detail Description about the Implementation: http://www.sciencedirect.com/science/article/pii/S1569190X16302714
# Phase1 Documentation: https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing
# Phase2 Documentation: https://drive.google.com/open?id=0BziHE2fNAdZRbUZKN01Bd1Rjdk0

* '''About me:''' I am a PhD student in the School of Mobile Computing and Communications, Jadavpur University, India. About my research is given here: http://scholar.google.com/citations?user=qouvajAAAAAJ&hl=en.

= Technical Approach =
*'''First,''' I want to restructure the MIPv6 code, published in http://www.sciencedirect.com/science/article/pii/S1569190X16302714, to make it RFC 6275 compliance. To do the restructuring complete, the following approaches will be performed:
#Code refactoring: reorganizing internetstack, helper and header components of the MIPv6 module through modifying the internal functions, attributes and the callback variables.
#Code analysis: both static and dynamic analysis could be performed. The waf tool for code run, PyViz for visualization and tcpdump for pcap tracing could be used.
#Functional tests: The functional test would be performed in three phase: handoff performance testing, data packet transmission testing and both. Use cases like multiple mobile nodes, multiple correspondent node, different mobility model for the mobile node as well as heterogeneous link layer technologies (Wi-Fi and WiMAX) could be used.
#The code will be sent for the code review to the ns-3 team.
* '''Second,''' IPV6 support for LTE would be ensured as LTE currently, only supports IPv4. The changes would possibly be done within the LTE module files (both .cc and .h) like point-topoint-helper, emu-epc-helper, lte-ue-net-device, epc-sgw-pgw-application, epc-enb-application, lte-enb-net-device etc. Then, the code analysis will be performed as done previously for MIPv6 code. The functional tests would follow bidirectional IPv6 packet transmission between remote host and the UE. The modification/rewriting code will create a patch that could enable IPv6 forwarding in the LTE data plane, enabling the UE to receive and use a /64 prefix, as stated in the standard. It is worth noticing that IP packets are tunnelled in the `core' network (i.e., all the EPC part), and their actual IP address is not used for UE identification in the core. As a consequence, IPv6 use in the `core' network, using ULAs or link-local addresses, could be planned if the previous development is faster than foreseen. This modification could also be simpler than expected, as it is not important to keep a dual stack communication in the core network, and using only IPv6 brings some direct benefits (like simplifying the use of multiple EPCs in a single script).
* '''Third,''' To ensure the code quality, the following testing approach could be used: Test MIPv6 handoff performance with the mixed link layer technologies (combination of Wi-Fi, WiMAX and LTE) case, multiple mobile node case, and multiple correspondent node case.

= Deliverables and Plan =
=== Deliverables: ===

-a basic MIPv6 module, aligned with RFC 6275 following ns-3 coding styles;

-a reviewed patch, fixing the IPv6 support issue in LTE;

-proper documentation and tests for the above-mentioned components.

=== Plan: ===

==== May 4 – May 29 (Before the official coding time): ====

-Familiarize myself completely with MIPv6, LTE (the IPv4 part), and the respective interactions.

-Study of the customized files of ns-3 lte and internet modules

-Familiarize myself with the ns-3 coding styles

During this period I will remain in constant touch with my mentor and the ns-3 community. I will remain active on IRC and Mailing lists to discuss and finalize on the modifications (if any) that needs to be on existing models and design of new module (if needed to fit cleanly with ns-3)

Thus with the help of my mentor I will become absolutely clear about my future goals, the final MIPv6 implementation that need to be done as well as the approach that I will follow to support IPv6 in lte model.

==== May 30 – June 26 (Official coding period starts): ====

-Refactor previous MIPv6 headers to RFC compliance header files

-Refactor all the classes to implement the corresponding header file functions

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the newly implemented MIPv6 module in various testing scenarios. The testing will be done with the systems having Wi-Fi and WiMAX link layer technology

-Sending the code for code review to the ns-3 team

After this stage, the standard ns-3 code revision can be started for the MIPv6 code part. Any change requested by the reviewers will be carried out in parallel with the following activities.

==== June 27 – July 24: ====

-Define new or, modify existing header files and cc files in LTE module in such a way that LTE module remains backward compatible with IPv4

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the LTE module

-Sending the code for code review to the ns-3 team

This will help in testing of the LTE module with IPv6 support for possible merge into the project main tree.

==== July 25 – August 21: ====

-Making further changes in the LTE module to support MIPv6 into it. Changes may be required in the other modules of ns-3 also.

-Testing the overall working in the testing scenarios having the combination of Wi-Fi and LTE

-Most of the time will be consumed for rigorous testing and bug fixes.

-Sending the code for code review to the ns-3 team

-Documentation updates.

= Weekly Reports =

=== May 30 - June 6 ===

1. Restructuring the MIPv6 code.

2. Testing the code in the multiple Mobile Node case

3. Changing the Home Agent functionality a little bit

4. Arise Tunnel Implementation Issue [how mobile node would use its home address for all of its data communication]

=== June 7 - June 13 ===

1. Resolved the issue of home address assignment to mobile node for all of its data communication. So, I have made some tricky callbacks in the L4 protocol a little bit. Now, traffic can be directed in both direction i.e. Mobile node to a web server and a web server to a mobile node

2. Also delete a lot of unnecessary files as well as lines in the code.

3. Tests have been done changing the location of different mobility entities. Almost all are successful. Those are included in "mipv6-test1-4.cc" in scratch of https://github.com/manoj24rana/MobileIPv6.

=== June 14 - June 20 ===

1. Done more tests

2. Add some more features such as defending home address and performing NS handling at HA as described in RFC 6275

3. Find an issue on RFC 6275 i.e. how to defend the mobile node's home address by home agent when it returns to its home network. Try to do something on the basis of ns-3 ipv6 implementation to resolve the issue.

=== June 21 - June 27 ===

1. Documentation on how my implementation differs from RFC 6275 as well as

2. Resolve the above issue

3. Sending the code for review.

=== June 28 - July 04 ===

1. Starting LTE IPv6 implementation part: understanding the end-to-end IPv4 part between UE and remote host, decoding it and discuss with my mentor for changing

2. Start writing code, at least one class modification

3. Test the change whether it is right.

=== July 05 - July 11 ===

1. Complete the modification in the lte module classes and also develop a small IPv6 dealing program to test

2. An issue arise i.e. Address Collision occurs at file: file=../src/internet/model/
ipv6-address-generator.cc, line=484". I am trying to resolve it.

3. Runs the previous IPv4 sample programs, which runs fine.

=== July 12 - July 18 ===

1. Resolve the IPv6 address collision issue in the LTE IPv6 support part.

2. I face another issue on handling multicast packets between UE sets and pgw i.e. those multicast packets are not passed between them as in the middle there is an enb.

3. Add the Sphinx documentation in the mipv6 module.

4. The Attributes and TraceSources are uploaded in mipv6 git.

=== July 19 - July 25 ===

1. Making some examples for the main mipv6 repo.

2. Add two tests in the main mipv6 repo.

3. mipv6 doc file further update.

4. Add and change tracesources and some functionalities in mipv6 model.

=== July 26 - August 1 ===

Finalize the MIPv6 code for review. I have added two nice tests replacing the previous tests, further update the mipv6 doc, trace sources, attributes, examples.
The codes are documented highly. Now the /doc/models/build/html dir contains the model documentation and the /doc/html creates doxygen for the mipv6 module.

=== August 2 - August 15 ===

1. Sent the MIPv6 code for review.

2. Solved LTE IPv6 packet sending issues.

3. Complete LTE IPv6 part, i.e. IPv6 packets are received and sent correctly.

4. Discuss with my mentor (Tommaso) elaborately about the next steps such that this implementation could be rebased in the main ns-3 dev quickly.

=== August 16 - August 22 ===

1. Update the LTE UE and PGW address assignment process in such a way that all IP addresses assigned by an EPC are derived from a base prefix (8 for IPv4 and 32 for IPv6) and each EPC holds a unique 16 bit IPv4 and 48 bit IPv6 subnet prefix to assign addresses to PGW and UEs. This address assignment process is made by keeping in mind the issues stated in https://www.nsnam.org/bugzilla/show_bug.cgi?id=1745 and https://groups.google.com/forum/#!topic/ns-3-users/Tc3IKky1OKo. So, now address duplication would not happen in case of more than one EPC as well as any time we could assign addresses without initializing the address helper. Also, user is given the flexibility to reassign the base 8 or, 32 bit address prefix at any time.

2. The LTE module is updated by IPv6 tests, documentation and examples. So, now the sample program is running and users can use them.

=== August 23 - August 29 ===

1. Submit the Google Work Product.

2. Send the LTE Code for review.

3. Try to resolve the reviewer's comment.

= Final Report for Google =

=== Work Product Link ===

This is the complete work product link with full ns-3.25 software:

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6

My contribution:

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/commit/7164250819b85ec2461e4c20667a516720eeddd5

=== Installation and Running the Work Product ===

1. Depending on your OS, install the ns-3 Prerequisites from this link: https://www.nsnam.org/wiki/Installation#Prerequisites.

2. Download the code from this repository: https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6 and extract it.

3. Make sure that you have installed all the perquisites to install ns-3.25.

4. Run the following commands in your cmd prompt to install it:

$ cd The_Project_Folder

$ cd ns-3.25

$ ./waf -d debug --enable-examples --enable-tests configure

$ ./waf

5. Running MIPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running MIPv6: mipv6-multiple.cc, mipv6-single.cc and mipv6-wifi-wimax.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run mipv6-multiple --vis

This will open a visualizer to see the output and the packet transmission in the background cmd prompt.

6. Running LTE IPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running LTE IPv6: lena-ipv6-ue-rh.cc, lena-ipv6-ue-ue.cc and lena-ipv6-addr-conf.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run lena-ipv6-ue-ue --vis

This will open a visualizer to see the output and the packet transmission in the background cmd prompt.

=== Documentation ===

Either, you follow the prepared documentation,

For MIPv6,

https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing

For LTE IPv6,

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/blob/master/ns-3.25/src/lte/doc/source/lte-design.rst and
https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/blob/master/ns-3.25/src/lte/doc/source/lte-user.rst

or, you could follow the manual for Creating Documentation here: https://www.nsnam.org/docs/manual/html/documentation.html. I have added the appropriate documentations within the code of the above repo of my implementation.

=== Work Flow ===

The following link will describe the weekly update of this project.

https://www.nsnam.org/wiki/GSOC2017MobileIp#Weekly_Reports

The flow of commits in the code could be found in the following link.

https://github.com/manoj24rana/MobileIPv6

=== Other Issues Resolved ===

I have resolved several other issues in ns-3 during this period as a part of my main implementation. Briefly, these are as follows.

1. Lack of IPv6 support for WiMAX module.

2. Duplicate IPv4 address collision problem in LTE module (https://groups.google.com/forum/#!topic/ns-3-users/Tc3IKky1OKo).

3. Affecting this problem (https://www.nsnam.org/bugzilla/show_bug.cgi?id=1745) in LTE IP address assignments.

GSOC2017MobileIp

2017-08-28T03:55:25Z

Mkrana: /* Work Product Link */

{{TOC}}

Return to [[GSOC2017AcceptedProjects | GSoC 2017 Accepted Projects]] page.

= Project overview =

* '''Project name:''' Mobile IPv6 Implementation with LTE support

* '''Student:''' [mailto:manoj24.rana@gmail.com Manoj Kumar Rana]

* '''Mentor:''' [mailto:tommypec@gmail.com Tommaso Pecorella]

* '''Abstract:''' The goal of the project is to implement a novel MIPv6 simulation model which can be integrated into ns-3. The project idea aims at testing the code in different network scenarios, containing different link layer technologies such as Wi-Fi, WiMAX and LTE. The current implementation of LTE does not have support of IPv6 in ns-3. So, the idea of testing MIPv6 code into LTE would follow IPv6 support implementation in LTE first and then the MIPv6 support. Thus, implementation of MIPv6 in ns-3 as the base mobility management solution and providing LTE support within it could help the current network researchers working on ns-3.

* '''Code:''' https://github.com/manoj24rana/MobileIPv6

* '''Documentation:'''
# Detail Description about the Implementation: http://www.sciencedirect.com/science/article/pii/S1569190X16302714
# Phase1 Documentation: https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing
# Phase2 Documentation: https://drive.google.com/open?id=0BziHE2fNAdZRbUZKN01Bd1Rjdk0

* '''About me:''' I am a PhD student in the School of Mobile Computing and Communications, Jadavpur University, India. About my research is given here: http://scholar.google.com/citations?user=qouvajAAAAAJ&hl=en.

= Technical Approach =
*'''First,''' I want to restructure the MIPv6 code, published in http://www.sciencedirect.com/science/article/pii/S1569190X16302714, to make it RFC 6275 compliance. To do the restructuring complete, the following approaches will be performed:
#Code refactoring: reorganizing internetstack, helper and header components of the MIPv6 module through modifying the internal functions, attributes and the callback variables.
#Code analysis: both static and dynamic analysis could be performed. The waf tool for code run, PyViz for visualization and tcpdump for pcap tracing could be used.
#Functional tests: The functional test would be performed in three phase: handoff performance testing, data packet transmission testing and both. Use cases like multiple mobile nodes, multiple correspondent node, different mobility model for the mobile node as well as heterogeneous link layer technologies (Wi-Fi and WiMAX) could be used.
#The code will be sent for the code review to the ns-3 team.
* '''Second,''' IPV6 support for LTE would be ensured as LTE currently, only supports IPv4. The changes would possibly be done within the LTE module files (both .cc and .h) like point-topoint-helper, emu-epc-helper, lte-ue-net-device, epc-sgw-pgw-application, epc-enb-application, lte-enb-net-device etc. Then, the code analysis will be performed as done previously for MIPv6 code. The functional tests would follow bidirectional IPv6 packet transmission between remote host and the UE. The modification/rewriting code will create a patch that could enable IPv6 forwarding in the LTE data plane, enabling the UE to receive and use a /64 prefix, as stated in the standard. It is worth noticing that IP packets are tunnelled in the `core' network (i.e., all the EPC part), and their actual IP address is not used for UE identification in the core. As a consequence, IPv6 use in the `core' network, using ULAs or link-local addresses, could be planned if the previous development is faster than foreseen. This modification could also be simpler than expected, as it is not important to keep a dual stack communication in the core network, and using only IPv6 brings some direct benefits (like simplifying the use of multiple EPCs in a single script).
* '''Third,''' To ensure the code quality, the following testing approach could be used: Test MIPv6 handoff performance with the mixed link layer technologies (combination of Wi-Fi, WiMAX and LTE) case, multiple mobile node case, and multiple correspondent node case.

= Deliverables and Plan =
=== Deliverables: ===

-a basic MIPv6 module, aligned with RFC 6275 following ns-3 coding styles;

-a reviewed patch, fixing the IPv6 support issue in LTE;

-proper documentation and tests for the above-mentioned components.

=== Plan: ===

==== May 4 – May 29 (Before the official coding time): ====

-Familiarize myself completely with MIPv6, LTE (the IPv4 part), and the respective interactions.

-Study of the customized files of ns-3 lte and internet modules

-Familiarize myself with the ns-3 coding styles

During this period I will remain in constant touch with my mentor and the ns-3 community. I will remain active on IRC and Mailing lists to discuss and finalize on the modifications (if any) that needs to be on existing models and design of new module (if needed to fit cleanly with ns-3)

Thus with the help of my mentor I will become absolutely clear about my future goals, the final MIPv6 implementation that need to be done as well as the approach that I will follow to support IPv6 in lte model.

==== May 30 – June 26 (Official coding period starts): ====

-Refactor previous MIPv6 headers to RFC compliance header files

-Refactor all the classes to implement the corresponding header file functions

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the newly implemented MIPv6 module in various testing scenarios. The testing will be done with the systems having Wi-Fi and WiMAX link layer technology

-Sending the code for code review to the ns-3 team

After this stage, the standard ns-3 code revision can be started for the MIPv6 code part. Any change requested by the reviewers will be carried out in parallel with the following activities.

==== June 27 – July 24: ====

-Define new or, modify existing header files and cc files in LTE module in such a way that LTE module remains backward compatible with IPv4

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the LTE module

-Sending the code for code review to the ns-3 team

This will help in testing of the LTE module with IPv6 support for possible merge into the project main tree.

==== July 25 – August 21: ====

-Making further changes in the LTE module to support MIPv6 into it. Changes may be required in the other modules of ns-3 also.

-Testing the overall working in the testing scenarios having the combination of Wi-Fi and LTE

-Most of the time will be consumed for rigorous testing and bug fixes.

-Sending the code for code review to the ns-3 team

-Documentation updates.

= Weekly Reports =

=== May 30 - June 6 ===

1. Restructuring the MIPv6 code.

2. Testing the code in the multiple Mobile Node case

3. Changing the Home Agent functionality a little bit

4. Arise Tunnel Implementation Issue [how mobile node would use its home address for all of its data communication]

=== June 7 - June 13 ===

1. Resolved the issue of home address assignment to mobile node for all of its data communication. So, I have made some tricky callbacks in the L4 protocol a little bit. Now, traffic can be directed in both direction i.e. Mobile node to a web server and a web server to a mobile node

2. Also delete a lot of unnecessary files as well as lines in the code.

3. Tests have been done changing the location of different mobility entities. Almost all are successful. Those are included in "mipv6-test1-4.cc" in scratch of https://github.com/manoj24rana/MobileIPv6.

=== June 14 - June 20 ===

1. Done more tests

2. Add some more features such as defending home address and performing NS handling at HA as described in RFC 6275

3. Find an issue on RFC 6275 i.e. how to defend the mobile node's home address by home agent when it returns to its home network. Try to do something on the basis of ns-3 ipv6 implementation to resolve the issue.

=== June 21 - June 27 ===

1. Documentation on how my implementation differs from RFC 6275 as well as

2. Resolve the above issue

3. Sending the code for review.

=== June 28 - July 04 ===

1. Starting LTE IPv6 implementation part: understanding the end-to-end IPv4 part between UE and remote host, decoding it and discuss with my mentor for changing

2. Start writing code, at least one class modification

3. Test the change whether it is right.

=== July 05 - July 11 ===

1. Complete the modification in the lte module classes and also develop a small IPv6 dealing program to test

2. An issue arise i.e. Address Collision occurs at file: file=../src/internet/model/
ipv6-address-generator.cc, line=484". I am trying to resolve it.

3. Runs the previous IPv4 sample programs, which runs fine.

=== July 12 - July 18 ===

1. Resolve the IPv6 address collision issue in the LTE IPv6 support part.

2. I face another issue on handling multicast packets between UE sets and pgw i.e. those multicast packets are not passed between them as in the middle there is an enb.

3. Add the Sphinx documentation in the mipv6 module.

4. The Attributes and TraceSources are uploaded in mipv6 git.

=== July 19 - July 25 ===

1. Making some examples for the main mipv6 repo.

2. Add two tests in the main mipv6 repo.

3. mipv6 doc file further update.

4. Add and change tracesources and some functionalities in mipv6 model.

=== July 26 - August 1 ===

Finalize the MIPv6 code for review. I have added two nice tests replacing the previous tests, further update the mipv6 doc, trace sources, attributes, examples.
The codes are documented highly. Now the /doc/models/build/html dir contains the model documentation and the /doc/html creates doxygen for the mipv6 module.

=== August 2 - August 15 ===

1. Sent the MIPv6 code for review.

2. Solved LTE IPv6 packet sending issues.

3. Complete LTE IPv6 part, i.e. IPv6 packets are received and sent correctly.

4. Discuss with my mentor (Tommaso) elaborately about the next steps such that this implementation could be rebased in the main ns-3 dev quickly.

=== August 16 - August 22 ===

1. Update the LTE UE and PGW address assignment process in such a way that all IP addresses assigned by an EPC are derived from a base prefix (8 for IPv4 and 32 for IPv6) and each EPC holds a unique 16 bit IPv4 and 48 bit IPv6 subnet prefix to assign addresses to PGW and UEs. This address assignment process is made by keeping in mind the issues stated in https://www.nsnam.org/bugzilla/show_bug.cgi?id=1745 and https://groups.google.com/forum/#!topic/ns-3-users/Tc3IKky1OKo. So, now address duplication would not happen in case of more than one EPC as well as any time we could assign addresses without initializing the address helper. Also, user is given the flexibility to reassign the base 8 or, 32 bit address prefix at any time.

2. The LTE module is updated by IPv6 tests, documentation and examples. So, now the sample program is running and users can use them.

=== August 23 - August 29 ===

1. Submit the Google Work Product.

2. Send the LTE Code for review.

3. Try to resolve the reviewer's comment.

= Final Report for Google =

=== Work Product Link ===

This is the complete work product link with full ns-3.25 software:

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6

My contribution:

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/commit/7164250819b85ec2461e4c20667a516720eeddd5

=== Installation and Running the Work Product ===

1. Depending on your OS, install the ns-3 Prerequisites from this link: https://www.nsnam.org/wiki/Installation#Prerequisites.

2. Download the code from this repository: https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6 and extract it.

3. Make sure that you have installed all the perquisites to install ns-3.25.

4. Run the following commands in your cmd prompt to install it:

$ cd The_Project_Folder

$ cd ns-3.25

$ ./waf -d debug --enable-examples --enable-tests configure

$ ./waf

5. Running MIPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running MIPv6: mipv6-multiple.cc, mipv6-single.cc and mipv6-wifi-wimax.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run mipv6-multiple --vis

This will open a visualizer to see the output and the packet transmission in the background cmd prompt.

6. Running LTE IPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running LTE IPv6: lena-ipv6-ue-rh.cc, lena-ipv6-ue-ue.cc and lena-ipv6-addr-conf.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run lena-ipv6-ue-ue --vis

This will open a visualizer to see the output and the packet transmission in the background cmd prompt.

=== Documentation ===

Either, you follow the prepared documentation,

For MIPv6,

https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing

For LTE IPv6,

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/blob/master/ns-3.25/src/lte/doc/source/lte-design.rst and
https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/blob/master/ns-3.25/src/lte/doc/source/lte-user.rst

or, you could follow the manual for Creating Documentation here: https://www.nsnam.org/docs/manual/html/documentation.html. I have added the appropriate documentations within the code of the above repo of my implementation.

=== Work Flow ===

The following link will describe the weekly update of this project.

https://www.nsnam.org/wiki/GSOC2017MobileIp#Weekly_Reports

The flow of commits in the code could be found in the following link.

https://github.com/manoj24rana/MobileIPv6

=== Other Issues Resolved ===

I have resolved several other issues in ns-3 during this period as a part of my main implementation. Briefly, these are as follows.

1. Lack of IPv6 support for WiMAX module.

2. Duplicate IPv4 address collision problem in LTE module (https://groups.google.com/forum/#!topic/ns-3-users/Tc3IKky1OKo).

3. Affecting this problem (https://www.nsnam.org/bugzilla/show_bug.cgi?id=1745) in LTE IP address assignments.

GSOC2017MobileIp

2017-08-28T03:53:21Z

Mkrana: /* Final Report for Google */

{{TOC}}

Return to [[GSOC2017AcceptedProjects | GSoC 2017 Accepted Projects]] page.

= Project overview =

* '''Project name:''' Mobile IPv6 Implementation with LTE support

* '''Student:''' [mailto:manoj24.rana@gmail.com Manoj Kumar Rana]

* '''Mentor:''' [mailto:tommypec@gmail.com Tommaso Pecorella]

* '''Abstract:''' The goal of the project is to implement a novel MIPv6 simulation model which can be integrated into ns-3. The project idea aims at testing the code in different network scenarios, containing different link layer technologies such as Wi-Fi, WiMAX and LTE. The current implementation of LTE does not have support of IPv6 in ns-3. So, the idea of testing MIPv6 code into LTE would follow IPv6 support implementation in LTE first and then the MIPv6 support. Thus, implementation of MIPv6 in ns-3 as the base mobility management solution and providing LTE support within it could help the current network researchers working on ns-3.

* '''Code:''' https://github.com/manoj24rana/MobileIPv6

* '''Documentation:'''
# Detail Description about the Implementation: http://www.sciencedirect.com/science/article/pii/S1569190X16302714
# Phase1 Documentation: https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing
# Phase2 Documentation: https://drive.google.com/open?id=0BziHE2fNAdZRbUZKN01Bd1Rjdk0

* '''About me:''' I am a PhD student in the School of Mobile Computing and Communications, Jadavpur University, India. About my research is given here: http://scholar.google.com/citations?user=qouvajAAAAAJ&hl=en.

= Technical Approach =
*'''First,''' I want to restructure the MIPv6 code, published in http://www.sciencedirect.com/science/article/pii/S1569190X16302714, to make it RFC 6275 compliance. To do the restructuring complete, the following approaches will be performed:
#Code refactoring: reorganizing internetstack, helper and header components of the MIPv6 module through modifying the internal functions, attributes and the callback variables.
#Code analysis: both static and dynamic analysis could be performed. The waf tool for code run, PyViz for visualization and tcpdump for pcap tracing could be used.
#Functional tests: The functional test would be performed in three phase: handoff performance testing, data packet transmission testing and both. Use cases like multiple mobile nodes, multiple correspondent node, different mobility model for the mobile node as well as heterogeneous link layer technologies (Wi-Fi and WiMAX) could be used.
#The code will be sent for the code review to the ns-3 team.
* '''Second,''' IPV6 support for LTE would be ensured as LTE currently, only supports IPv4. The changes would possibly be done within the LTE module files (both .cc and .h) like point-topoint-helper, emu-epc-helper, lte-ue-net-device, epc-sgw-pgw-application, epc-enb-application, lte-enb-net-device etc. Then, the code analysis will be performed as done previously for MIPv6 code. The functional tests would follow bidirectional IPv6 packet transmission between remote host and the UE. The modification/rewriting code will create a patch that could enable IPv6 forwarding in the LTE data plane, enabling the UE to receive and use a /64 prefix, as stated in the standard. It is worth noticing that IP packets are tunnelled in the `core' network (i.e., all the EPC part), and their actual IP address is not used for UE identification in the core. As a consequence, IPv6 use in the `core' network, using ULAs or link-local addresses, could be planned if the previous development is faster than foreseen. This modification could also be simpler than expected, as it is not important to keep a dual stack communication in the core network, and using only IPv6 brings some direct benefits (like simplifying the use of multiple EPCs in a single script).
* '''Third,''' To ensure the code quality, the following testing approach could be used: Test MIPv6 handoff performance with the mixed link layer technologies (combination of Wi-Fi, WiMAX and LTE) case, multiple mobile node case, and multiple correspondent node case.

= Deliverables and Plan =
=== Deliverables: ===

-a basic MIPv6 module, aligned with RFC 6275 following ns-3 coding styles;

-a reviewed patch, fixing the IPv6 support issue in LTE;

-proper documentation and tests for the above-mentioned components.

=== Plan: ===

==== May 4 – May 29 (Before the official coding time): ====

-Familiarize myself completely with MIPv6, LTE (the IPv4 part), and the respective interactions.

-Study of the customized files of ns-3 lte and internet modules

-Familiarize myself with the ns-3 coding styles

During this period I will remain in constant touch with my mentor and the ns-3 community. I will remain active on IRC and Mailing lists to discuss and finalize on the modifications (if any) that needs to be on existing models and design of new module (if needed to fit cleanly with ns-3)

Thus with the help of my mentor I will become absolutely clear about my future goals, the final MIPv6 implementation that need to be done as well as the approach that I will follow to support IPv6 in lte model.

==== May 30 – June 26 (Official coding period starts): ====

-Refactor previous MIPv6 headers to RFC compliance header files

-Refactor all the classes to implement the corresponding header file functions

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the newly implemented MIPv6 module in various testing scenarios. The testing will be done with the systems having Wi-Fi and WiMAX link layer technology

-Sending the code for code review to the ns-3 team

After this stage, the standard ns-3 code revision can be started for the MIPv6 code part. Any change requested by the reviewers will be carried out in parallel with the following activities.

==== June 27 – July 24: ====

-Define new or, modify existing header files and cc files in LTE module in such a way that LTE module remains backward compatible with IPv4

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the LTE module

-Sending the code for code review to the ns-3 team

This will help in testing of the LTE module with IPv6 support for possible merge into the project main tree.

==== July 25 – August 21: ====

-Making further changes in the LTE module to support MIPv6 into it. Changes may be required in the other modules of ns-3 also.

-Testing the overall working in the testing scenarios having the combination of Wi-Fi and LTE

-Most of the time will be consumed for rigorous testing and bug fixes.

-Sending the code for code review to the ns-3 team

-Documentation updates.

= Weekly Reports =

=== May 30 - June 6 ===

1. Restructuring the MIPv6 code.

2. Testing the code in the multiple Mobile Node case

3. Changing the Home Agent functionality a little bit

4. Arise Tunnel Implementation Issue [how mobile node would use its home address for all of its data communication]

=== June 7 - June 13 ===

1. Resolved the issue of home address assignment to mobile node for all of its data communication. So, I have made some tricky callbacks in the L4 protocol a little bit. Now, traffic can be directed in both direction i.e. Mobile node to a web server and a web server to a mobile node

2. Also delete a lot of unnecessary files as well as lines in the code.

3. Tests have been done changing the location of different mobility entities. Almost all are successful. Those are included in "mipv6-test1-4.cc" in scratch of https://github.com/manoj24rana/MobileIPv6.

=== June 14 - June 20 ===

1. Done more tests

2. Add some more features such as defending home address and performing NS handling at HA as described in RFC 6275

3. Find an issue on RFC 6275 i.e. how to defend the mobile node's home address by home agent when it returns to its home network. Try to do something on the basis of ns-3 ipv6 implementation to resolve the issue.

=== June 21 - June 27 ===

1. Documentation on how my implementation differs from RFC 6275 as well as

2. Resolve the above issue

3. Sending the code for review.

=== June 28 - July 04 ===

1. Starting LTE IPv6 implementation part: understanding the end-to-end IPv4 part between UE and remote host, decoding it and discuss with my mentor for changing

2. Start writing code, at least one class modification

3. Test the change whether it is right.

=== July 05 - July 11 ===

1. Complete the modification in the lte module classes and also develop a small IPv6 dealing program to test

2. An issue arise i.e. Address Collision occurs at file: file=../src/internet/model/
ipv6-address-generator.cc, line=484". I am trying to resolve it.

3. Runs the previous IPv4 sample programs, which runs fine.

=== July 12 - July 18 ===

1. Resolve the IPv6 address collision issue in the LTE IPv6 support part.

2. I face another issue on handling multicast packets between UE sets and pgw i.e. those multicast packets are not passed between them as in the middle there is an enb.

3. Add the Sphinx documentation in the mipv6 module.

4. The Attributes and TraceSources are uploaded in mipv6 git.

=== July 19 - July 25 ===

1. Making some examples for the main mipv6 repo.

2. Add two tests in the main mipv6 repo.

3. mipv6 doc file further update.

4. Add and change tracesources and some functionalities in mipv6 model.

=== July 26 - August 1 ===

Finalize the MIPv6 code for review. I have added two nice tests replacing the previous tests, further update the mipv6 doc, trace sources, attributes, examples.
The codes are documented highly. Now the /doc/models/build/html dir contains the model documentation and the /doc/html creates doxygen for the mipv6 module.

=== August 2 - August 15 ===

1. Sent the MIPv6 code for review.

2. Solved LTE IPv6 packet sending issues.

3. Complete LTE IPv6 part, i.e. IPv6 packets are received and sent correctly.

4. Discuss with my mentor (Tommaso) elaborately about the next steps such that this implementation could be rebased in the main ns-3 dev quickly.

=== August 16 - August 22 ===

1. Update the LTE UE and PGW address assignment process in such a way that all IP addresses assigned by an EPC are derived from a base prefix (8 for IPv4 and 32 for IPv6) and each EPC holds a unique 16 bit IPv4 and 48 bit IPv6 subnet prefix to assign addresses to PGW and UEs. This address assignment process is made by keeping in mind the issues stated in https://www.nsnam.org/bugzilla/show_bug.cgi?id=1745 and https://groups.google.com/forum/#!topic/ns-3-users/Tc3IKky1OKo. So, now address duplication would not happen in case of more than one EPC as well as any time we could assign addresses without initializing the address helper. Also, user is given the flexibility to reassign the base 8 or, 32 bit address prefix at any time.

2. The LTE module is updated by IPv6 tests, documentation and examples. So, now the sample program is running and users can use them.

=== August 23 - August 29 ===

1. Submit the Google Work Product.

2. Send the LTE Code for review.

3. Try to resolve the reviewer's comment.

= Final Report for Google =

=== Work Product Link ===

This is the complete work product link with full ns-3.25 software:
https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6

My contribution:
https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/commit/7164250819b85ec2461e4c20667a516720eeddd5

=== Installation and Running the Work Product ===

1. Depending on your OS, install the ns-3 Prerequisites from this link: https://www.nsnam.org/wiki/Installation#Prerequisites.

2. Download the code from this repository: https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6 and extract it.

3. Make sure that you have installed all the perquisites to install ns-3.25.

4. Run the following commands in your cmd prompt to install it:

$ cd The_Project_Folder

$ cd ns-3.25

$ ./waf -d debug --enable-examples --enable-tests configure

$ ./waf

5. Running MIPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running MIPv6: mipv6-multiple.cc, mipv6-single.cc and mipv6-wifi-wimax.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run mipv6-multiple --vis

This will open a visualizer to see the output and the packet transmission in the background cmd prompt.

6. Running LTE IPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running LTE IPv6: lena-ipv6-ue-rh.cc, lena-ipv6-ue-ue.cc and lena-ipv6-addr-conf.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run lena-ipv6-ue-ue --vis

This will open a visualizer to see the output and the packet transmission in the background cmd prompt.

=== Documentation ===

Either, you follow the prepared documentation,

For MIPv6,

https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing

For LTE IPv6,

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/blob/master/ns-3.25/src/lte/doc/source/lte-design.rst and
https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/blob/master/ns-3.25/src/lte/doc/source/lte-user.rst

or, you could follow the manual for Creating Documentation here: https://www.nsnam.org/docs/manual/html/documentation.html. I have added the appropriate documentations within the code of the above repo of my implementation.

=== Work Flow ===

The following link will describe the weekly update of this project.

https://www.nsnam.org/wiki/GSOC2017MobileIp#Weekly_Reports

The flow of commits in the code could be found in the following link.

https://github.com/manoj24rana/MobileIPv6

=== Other Issues Resolved ===

I have resolved several other issues in ns-3 during this period as a part of my main implementation. Briefly, these are as follows.

1. Lack of IPv6 support for WiMAX module.

2. Duplicate IPv4 address collision problem in LTE module (https://groups.google.com/forum/#!topic/ns-3-users/Tc3IKky1OKo).

3. Affecting this problem (https://www.nsnam.org/bugzilla/show_bug.cgi?id=1745) in LTE IP address assignments.

GSOC2017MobileIp

2017-08-28T03:48:25Z

Mkrana: /* Final Report for Google */

{{TOC}}

Return to [[GSOC2017AcceptedProjects | GSoC 2017 Accepted Projects]] page.

= Project overview =

* '''Project name:''' Mobile IPv6 Implementation with LTE support

* '''Student:''' [mailto:manoj24.rana@gmail.com Manoj Kumar Rana]

* '''Mentor:''' [mailto:tommypec@gmail.com Tommaso Pecorella]

* '''Abstract:''' The goal of the project is to implement a novel MIPv6 simulation model which can be integrated into ns-3. The project idea aims at testing the code in different network scenarios, containing different link layer technologies such as Wi-Fi, WiMAX and LTE. The current implementation of LTE does not have support of IPv6 in ns-3. So, the idea of testing MIPv6 code into LTE would follow IPv6 support implementation in LTE first and then the MIPv6 support. Thus, implementation of MIPv6 in ns-3 as the base mobility management solution and providing LTE support within it could help the current network researchers working on ns-3.

* '''Code:''' https://github.com/manoj24rana/MobileIPv6

* '''Documentation:'''
# Detail Description about the Implementation: http://www.sciencedirect.com/science/article/pii/S1569190X16302714
# Phase1 Documentation: https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing
# Phase2 Documentation: https://drive.google.com/open?id=0BziHE2fNAdZRbUZKN01Bd1Rjdk0

* '''About me:''' I am a PhD student in the School of Mobile Computing and Communications, Jadavpur University, India. About my research is given here: http://scholar.google.com/citations?user=qouvajAAAAAJ&hl=en.

= Technical Approach =
*'''First,''' I want to restructure the MIPv6 code, published in http://www.sciencedirect.com/science/article/pii/S1569190X16302714, to make it RFC 6275 compliance. To do the restructuring complete, the following approaches will be performed:
#Code refactoring: reorganizing internetstack, helper and header components of the MIPv6 module through modifying the internal functions, attributes and the callback variables.
#Code analysis: both static and dynamic analysis could be performed. The waf tool for code run, PyViz for visualization and tcpdump for pcap tracing could be used.
#Functional tests: The functional test would be performed in three phase: handoff performance testing, data packet transmission testing and both. Use cases like multiple mobile nodes, multiple correspondent node, different mobility model for the mobile node as well as heterogeneous link layer technologies (Wi-Fi and WiMAX) could be used.
#The code will be sent for the code review to the ns-3 team.
* '''Second,''' IPV6 support for LTE would be ensured as LTE currently, only supports IPv4. The changes would possibly be done within the LTE module files (both .cc and .h) like point-topoint-helper, emu-epc-helper, lte-ue-net-device, epc-sgw-pgw-application, epc-enb-application, lte-enb-net-device etc. Then, the code analysis will be performed as done previously for MIPv6 code. The functional tests would follow bidirectional IPv6 packet transmission between remote host and the UE. The modification/rewriting code will create a patch that could enable IPv6 forwarding in the LTE data plane, enabling the UE to receive and use a /64 prefix, as stated in the standard. It is worth noticing that IP packets are tunnelled in the `core' network (i.e., all the EPC part), and their actual IP address is not used for UE identification in the core. As a consequence, IPv6 use in the `core' network, using ULAs or link-local addresses, could be planned if the previous development is faster than foreseen. This modification could also be simpler than expected, as it is not important to keep a dual stack communication in the core network, and using only IPv6 brings some direct benefits (like simplifying the use of multiple EPCs in a single script).
* '''Third,''' To ensure the code quality, the following testing approach could be used: Test MIPv6 handoff performance with the mixed link layer technologies (combination of Wi-Fi, WiMAX and LTE) case, multiple mobile node case, and multiple correspondent node case.

= Deliverables and Plan =
=== Deliverables: ===

-a basic MIPv6 module, aligned with RFC 6275 following ns-3 coding styles;

-a reviewed patch, fixing the IPv6 support issue in LTE;

-proper documentation and tests for the above-mentioned components.

=== Plan: ===

==== May 4 – May 29 (Before the official coding time): ====

-Familiarize myself completely with MIPv6, LTE (the IPv4 part), and the respective interactions.

-Study of the customized files of ns-3 lte and internet modules

-Familiarize myself with the ns-3 coding styles

During this period I will remain in constant touch with my mentor and the ns-3 community. I will remain active on IRC and Mailing lists to discuss and finalize on the modifications (if any) that needs to be on existing models and design of new module (if needed to fit cleanly with ns-3)

Thus with the help of my mentor I will become absolutely clear about my future goals, the final MIPv6 implementation that need to be done as well as the approach that I will follow to support IPv6 in lte model.

==== May 30 – June 26 (Official coding period starts): ====

-Refactor previous MIPv6 headers to RFC compliance header files

-Refactor all the classes to implement the corresponding header file functions

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the newly implemented MIPv6 module in various testing scenarios. The testing will be done with the systems having Wi-Fi and WiMAX link layer technology

-Sending the code for code review to the ns-3 team

After this stage, the standard ns-3 code revision can be started for the MIPv6 code part. Any change requested by the reviewers will be carried out in parallel with the following activities.

==== June 27 – July 24: ====

-Define new or, modify existing header files and cc files in LTE module in such a way that LTE module remains backward compatible with IPv4

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the LTE module

-Sending the code for code review to the ns-3 team

This will help in testing of the LTE module with IPv6 support for possible merge into the project main tree.

==== July 25 – August 21: ====

-Making further changes in the LTE module to support MIPv6 into it. Changes may be required in the other modules of ns-3 also.

-Testing the overall working in the testing scenarios having the combination of Wi-Fi and LTE

-Most of the time will be consumed for rigorous testing and bug fixes.

-Sending the code for code review to the ns-3 team

-Documentation updates.

= Weekly Reports =

=== May 30 - June 6 ===

1. Restructuring the MIPv6 code.

2. Testing the code in the multiple Mobile Node case

3. Changing the Home Agent functionality a little bit

4. Arise Tunnel Implementation Issue [how mobile node would use its home address for all of its data communication]

=== June 7 - June 13 ===

1. Resolved the issue of home address assignment to mobile node for all of its data communication. So, I have made some tricky callbacks in the L4 protocol a little bit. Now, traffic can be directed in both direction i.e. Mobile node to a web server and a web server to a mobile node

2. Also delete a lot of unnecessary files as well as lines in the code.

3. Tests have been done changing the location of different mobility entities. Almost all are successful. Those are included in "mipv6-test1-4.cc" in scratch of https://github.com/manoj24rana/MobileIPv6.

=== June 14 - June 20 ===

1. Done more tests

2. Add some more features such as defending home address and performing NS handling at HA as described in RFC 6275

3. Find an issue on RFC 6275 i.e. how to defend the mobile node's home address by home agent when it returns to its home network. Try to do something on the basis of ns-3 ipv6 implementation to resolve the issue.

=== June 21 - June 27 ===

1. Documentation on how my implementation differs from RFC 6275 as well as

2. Resolve the above issue

3. Sending the code for review.

=== June 28 - July 04 ===

1. Starting LTE IPv6 implementation part: understanding the end-to-end IPv4 part between UE and remote host, decoding it and discuss with my mentor for changing

2. Start writing code, at least one class modification

3. Test the change whether it is right.

=== July 05 - July 11 ===

1. Complete the modification in the lte module classes and also develop a small IPv6 dealing program to test

2. An issue arise i.e. Address Collision occurs at file: file=../src/internet/model/
ipv6-address-generator.cc, line=484". I am trying to resolve it.

3. Runs the previous IPv4 sample programs, which runs fine.

=== July 12 - July 18 ===

1. Resolve the IPv6 address collision issue in the LTE IPv6 support part.

2. I face another issue on handling multicast packets between UE sets and pgw i.e. those multicast packets are not passed between them as in the middle there is an enb.

3. Add the Sphinx documentation in the mipv6 module.

4. The Attributes and TraceSources are uploaded in mipv6 git.

=== July 19 - July 25 ===

1. Making some examples for the main mipv6 repo.

2. Add two tests in the main mipv6 repo.

3. mipv6 doc file further update.

4. Add and change tracesources and some functionalities in mipv6 model.

=== July 26 - August 1 ===

Finalize the MIPv6 code for review. I have added two nice tests replacing the previous tests, further update the mipv6 doc, trace sources, attributes, examples.
The codes are documented highly. Now the /doc/models/build/html dir contains the model documentation and the /doc/html creates doxygen for the mipv6 module.

=== August 2 - August 15 ===

1. Sent the MIPv6 code for review.

2. Solved LTE IPv6 packet sending issues.

3. Complete LTE IPv6 part, i.e. IPv6 packets are received and sent correctly.

4. Discuss with my mentor (Tommaso) elaborately about the next steps such that this implementation could be rebased in the main ns-3 dev quickly.

=== August 16 - August 22 ===

1. Update the LTE UE and PGW address assignment process in such a way that all IP addresses assigned by an EPC are derived from a base prefix (8 for IPv4 and 32 for IPv6) and each EPC holds a unique 16 bit IPv4 and 48 bit IPv6 subnet prefix to assign addresses to PGW and UEs. This address assignment process is made by keeping in mind the issues stated in https://www.nsnam.org/bugzilla/show_bug.cgi?id=1745 and https://groups.google.com/forum/#!topic/ns-3-users/Tc3IKky1OKo. So, now address duplication would not happen in case of more than one EPC as well as any time we could assign addresses without initializing the address helper. Also, user is given the flexibility to reassign the base 8 or, 32 bit address prefix at any time.

2. The LTE module is updated by IPv6 tests, documentation and examples. So, now the sample program is running and users can use them.

=== August 23 - August 29 ===

1. Submit the Google Work Product.

2. Send the LTE Code for review.

3. Try to resolve the reviewer's comment.

= Final Report for Google =

=== Installation and Running the Work Product ===

1. Depending on your OS, install the ns-3 Prerequisites from this link: https://www.nsnam.org/wiki/Installation#Prerequisites.

2. Download the code from this repository: https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6 and extract it.

3. Make sure that you have installed all the perquisites to install ns-3.25.

4. Run the following commands in your cmd prompt to install it:

$ cd The_Project_Folder

$ cd ns-3.25

$ ./waf -d debug --enable-examples --enable-tests configure

$ ./waf

5. Running MIPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running MIPv6: mipv6-multiple.cc, mipv6-single.cc and mipv6-wifi-wimax.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run mipv6-multiple --vis

This will open a visualizer to see the output and the packet transmission in the background cmd prompt.

6. Running LTE IPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running LTE IPv6: lena-ipv6-ue-rh.cc, lena-ipv6-ue-ue.cc and lena-ipv6-addr-conf.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run lena-ipv6-ue-ue --vis

This will open a visualizer to see the output and the packet transmission in the background cmd prompt.

=== Documentation ===

Either, you follow the prepared documentation,

For MIPv6,

https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing

For LTE IPv6,

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/blob/master/ns-3.25/src/lte/doc/source/lte-design.rst and
https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/blob/master/ns-3.25/src/lte/doc/source/lte-user.rst

or, you could follow the manual for Creating Documentation here: https://www.nsnam.org/docs/manual/html/documentation.html. I have added the appropriate documentations within the code of the above repo of my implementation.

=== Work Flow ===

The following link will describe the weekly update of this project.

https://www.nsnam.org/wiki/GSOC2017MobileIp#Weekly_Reports

The flow of commits in the code could be found in the following link.

https://github.com/manoj24rana/MobileIPv6

=== Other Issues Resolved ===

I have resolved several other issues in ns-3 during this period as a part of my main implementation. Briefly, these are as follows.

1. Lack of IPv6 support for WiMAX module.

2. Duplicate IPv4 address collision problem in LTE module (https://groups.google.com/forum/#!topic/ns-3-users/Tc3IKky1OKo).

3. Affecting this problem (https://www.nsnam.org/bugzilla/show_bug.cgi?id=1745) in LTE IP address assignments.

GSOC2017MobileIp

2017-08-28T03:21:32Z

Mkrana: /* Work Flow */

{{TOC}}

Return to [[GSOC2017AcceptedProjects | GSoC 2017 Accepted Projects]] page.

= Project overview =

* '''Project name:''' Mobile IPv6 Implementation with LTE support

* '''Student:''' [mailto:manoj24.rana@gmail.com Manoj Kumar Rana]

* '''Mentor:''' [mailto:tommypec@gmail.com Tommaso Pecorella]

* '''Abstract:''' The goal of the project is to implement a novel MIPv6 simulation model which can be integrated into ns-3. The project idea aims at testing the code in different network scenarios, containing different link layer technologies such as Wi-Fi, WiMAX and LTE. The current implementation of LTE does not have support of IPv6 in ns-3. So, the idea of testing MIPv6 code into LTE would follow IPv6 support implementation in LTE first and then the MIPv6 support. Thus, implementation of MIPv6 in ns-3 as the base mobility management solution and providing LTE support within it could help the current network researchers working on ns-3.

* '''Code:''' https://github.com/manoj24rana/MobileIPv6

* '''Documentation:'''
# Detail Description about the Implementation: http://www.sciencedirect.com/science/article/pii/S1569190X16302714
# Phase1 Documentation: https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing
# Phase2 Documentation: https://drive.google.com/open?id=0BziHE2fNAdZRbUZKN01Bd1Rjdk0

* '''About me:''' I am a PhD student in the School of Mobile Computing and Communications, Jadavpur University, India. About my research is given here: http://scholar.google.com/citations?user=qouvajAAAAAJ&hl=en.

= Technical Approach =
*'''First,''' I want to restructure the MIPv6 code, published in http://www.sciencedirect.com/science/article/pii/S1569190X16302714, to make it RFC 6275 compliance. To do the restructuring complete, the following approaches will be performed:
#Code refactoring: reorganizing internetstack, helper and header components of the MIPv6 module through modifying the internal functions, attributes and the callback variables.
#Code analysis: both static and dynamic analysis could be performed. The waf tool for code run, PyViz for visualization and tcpdump for pcap tracing could be used.
#Functional tests: The functional test would be performed in three phase: handoff performance testing, data packet transmission testing and both. Use cases like multiple mobile nodes, multiple correspondent node, different mobility model for the mobile node as well as heterogeneous link layer technologies (Wi-Fi and WiMAX) could be used.
#The code will be sent for the code review to the ns-3 team.
* '''Second,''' IPV6 support for LTE would be ensured as LTE currently, only supports IPv4. The changes would possibly be done within the LTE module files (both .cc and .h) like point-topoint-helper, emu-epc-helper, lte-ue-net-device, epc-sgw-pgw-application, epc-enb-application, lte-enb-net-device etc. Then, the code analysis will be performed as done previously for MIPv6 code. The functional tests would follow bidirectional IPv6 packet transmission between remote host and the UE. The modification/rewriting code will create a patch that could enable IPv6 forwarding in the LTE data plane, enabling the UE to receive and use a /64 prefix, as stated in the standard. It is worth noticing that IP packets are tunnelled in the `core' network (i.e., all the EPC part), and their actual IP address is not used for UE identification in the core. As a consequence, IPv6 use in the `core' network, using ULAs or link-local addresses, could be planned if the previous development is faster than foreseen. This modification could also be simpler than expected, as it is not important to keep a dual stack communication in the core network, and using only IPv6 brings some direct benefits (like simplifying the use of multiple EPCs in a single script).
* '''Third,''' To ensure the code quality, the following testing approach could be used: Test MIPv6 handoff performance with the mixed link layer technologies (combination of Wi-Fi, WiMAX and LTE) case, multiple mobile node case, and multiple correspondent node case.

= Deliverables and Plan =
=== Deliverables: ===

-a basic MIPv6 module, aligned with RFC 6275 following ns-3 coding styles;

-a reviewed patch, fixing the IPv6 support issue in LTE;

-proper documentation and tests for the above-mentioned components.

=== Plan: ===

==== May 4 – May 29 (Before the official coding time): ====

-Familiarize myself completely with MIPv6, LTE (the IPv4 part), and the respective interactions.

-Study of the customized files of ns-3 lte and internet modules

-Familiarize myself with the ns-3 coding styles

During this period I will remain in constant touch with my mentor and the ns-3 community. I will remain active on IRC and Mailing lists to discuss and finalize on the modifications (if any) that needs to be on existing models and design of new module (if needed to fit cleanly with ns-3)

Thus with the help of my mentor I will become absolutely clear about my future goals, the final MIPv6 implementation that need to be done as well as the approach that I will follow to support IPv6 in lte model.

==== May 30 – June 26 (Official coding period starts): ====

-Refactor previous MIPv6 headers to RFC compliance header files

-Refactor all the classes to implement the corresponding header file functions

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the newly implemented MIPv6 module in various testing scenarios. The testing will be done with the systems having Wi-Fi and WiMAX link layer technology

-Sending the code for code review to the ns-3 team

After this stage, the standard ns-3 code revision can be started for the MIPv6 code part. Any change requested by the reviewers will be carried out in parallel with the following activities.

==== June 27 – July 24: ====

-Define new or, modify existing header files and cc files in LTE module in such a way that LTE module remains backward compatible with IPv4

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the LTE module

-Sending the code for code review to the ns-3 team

This will help in testing of the LTE module with IPv6 support for possible merge into the project main tree.

==== July 25 – August 21: ====

-Making further changes in the LTE module to support MIPv6 into it. Changes may be required in the other modules of ns-3 also.

-Testing the overall working in the testing scenarios having the combination of Wi-Fi and LTE

-Most of the time will be consumed for rigorous testing and bug fixes.

-Sending the code for code review to the ns-3 team

-Documentation updates.

= Weekly Reports =

=== May 30 - June 6 ===

1. Restructuring the MIPv6 code.

2. Testing the code in the multiple Mobile Node case

3. Changing the Home Agent functionality a little bit

4. Arise Tunnel Implementation Issue [how mobile node would use its home address for all of its data communication]

=== June 7 - June 13 ===

1. Resolved the issue of home address assignment to mobile node for all of its data communication. So, I have made some tricky callbacks in the L4 protocol a little bit. Now, traffic can be directed in both direction i.e. Mobile node to a web server and a web server to a mobile node

2. Also delete a lot of unnecessary files as well as lines in the code.

3. Tests have been done changing the location of different mobility entities. Almost all are successful. Those are included in "mipv6-test1-4.cc" in scratch of https://github.com/manoj24rana/MobileIPv6.

=== June 14 - June 20 ===

1. Done more tests

2. Add some more features such as defending home address and performing NS handling at HA as described in RFC 6275

3. Find an issue on RFC 6275 i.e. how to defend the mobile node's home address by home agent when it returns to its home network. Try to do something on the basis of ns-3 ipv6 implementation to resolve the issue.

=== June 21 - June 27 ===

1. Documentation on how my implementation differs from RFC 6275 as well as

2. Resolve the above issue

3. Sending the code for review.

=== June 28 - July 04 ===

1. Starting LTE IPv6 implementation part: understanding the end-to-end IPv4 part between UE and remote host, decoding it and discuss with my mentor for changing

2. Start writing code, at least one class modification

3. Test the change whether it is right.

=== July 05 - July 11 ===

1. Complete the modification in the lte module classes and also develop a small IPv6 dealing program to test

2. An issue arise i.e. Address Collision occurs at file: file=../src/internet/model/
ipv6-address-generator.cc, line=484". I am trying to resolve it.

3. Runs the previous IPv4 sample programs, which runs fine.

=== July 12 - July 18 ===

1. Resolve the IPv6 address collision issue in the LTE IPv6 support part.

2. I face another issue on handling multicast packets between UE sets and pgw i.e. those multicast packets are not passed between them as in the middle there is an enb.

3. Add the Sphinx documentation in the mipv6 module.

4. The Attributes and TraceSources are uploaded in mipv6 git.

=== July 19 - July 25 ===

1. Making some examples for the main mipv6 repo.

2. Add two tests in the main mipv6 repo.

3. mipv6 doc file further update.

4. Add and change tracesources and some functionalities in mipv6 model.

=== July 26 - August 1 ===

Finalize the MIPv6 code for review. I have added two nice tests replacing the previous tests, further update the mipv6 doc, trace sources, attributes, examples.
The codes are documented highly. Now the /doc/models/build/html dir contains the model documentation and the /doc/html creates doxygen for the mipv6 module.

=== August 2 - August 15 ===

1. Sent the MIPv6 code for review.

2. Solved LTE IPv6 packet sending issues.

3. Complete LTE IPv6 part, i.e. IPv6 packets are received and sent correctly.

4. Discuss with my mentor (Tommaso) elaborately about the next steps such that this implementation could be rebased in the main ns-3 dev quickly.

=== August 16 - August 22 ===

1. Update the LTE UE and PGW address assignment process in such a way that all IP addresses assigned by an EPC are derived from a base prefix (8 for IPv4 and 32 for IPv6) and each EPC holds a unique 16 bit IPv4 and 48 bit IPv6 subnet prefix to assign addresses to PGW and UEs. This address assignment process is made by keeping in mind the issues stated in https://www.nsnam.org/bugzilla/show_bug.cgi?id=1745 and https://groups.google.com/forum/#!topic/ns-3-users/Tc3IKky1OKo. So, now address duplication would not happen in case of more than one EPC as well as any time we could assign addresses without initializing the address helper. Also, user is given the flexibility to reassign the base 8 or, 32 bit address prefix at any time.

2. The LTE module is updated by IPv6 tests, documentation and examples. So, now the sample program is running and users can use them.

=== August 23 - August 29 ===

1. Submit the Google Work Product.

2. Send the LTE Code for review.

3. Try to resolve the reviewer's comment.

= Final Report for Google =

=== Installation and Running the Work Product ===

1. Depending on your OS, install the ns-3 Prerequisites from this link: https://www.nsnam.org/wiki/Installation#Prerequisites.

2. Download the code from this repository: https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6 and extract it.

3. Make sure that you have installed all the perquisites to install ns-3.25.

4. Run the following commands in your cmd prompt to install it:

$ cd The_Project_Folder

$ cd ns-3.25

$ ./waf -d debug --enable-examples --enable-tests configure

$ ./waf

5. Running MIPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running MIPv6: mipv6-multiple.cc, mipv6-single.cc and mipv6-wifi-wimax.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run mipv6-multiple --vis

This will open a visualizer to see the output and the packet transmission in the background cmd prompt.

6. Running LTE IPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running LTE IPv6: lena-ipv6-ue-rh.cc, lena-ipv6-ue-ue.cc and lena-ipv6-addr-conf.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run lena-ipv6-ue-ue --vis

This will open a visualizer to see the output and the packet transmission in the background cmd prompt.

=== Documentation ===

Either, you follow the prepared documentation,

For MIPv6,

https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing

For LTE IPv6,

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/blob/master/ns-3.25/src/lte/doc/source/lte-design.rst and
https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/blob/master/ns-3.25/src/lte/doc/source/lte-user.rst

or, you could follow the manual for Creating Documentation here: https://www.nsnam.org/docs/manual/html/documentation.html. I have added the appropriate documentations within the code of the above repo of my implementation.

=== Work Flow ===

The following link will describe the weekly update of this project.

https://www.nsnam.org/wiki/GSOC2017MobileIp#Weekly_Reports

The flow of commits in the code could be found in the following link.

https://github.com/manoj24rana/MobileIPv6

=== Future Works ===

The following

GSOC2017MobileIp

2017-08-28T03:20:16Z

Mkrana: /* August 23 - August 29 */

{{TOC}}

Return to [[GSOC2017AcceptedProjects | GSoC 2017 Accepted Projects]] page.

= Project overview =

* '''Project name:''' Mobile IPv6 Implementation with LTE support

* '''Student:''' [mailto:manoj24.rana@gmail.com Manoj Kumar Rana]

* '''Mentor:''' [mailto:tommypec@gmail.com Tommaso Pecorella]

* '''Abstract:''' The goal of the project is to implement a novel MIPv6 simulation model which can be integrated into ns-3. The project idea aims at testing the code in different network scenarios, containing different link layer technologies such as Wi-Fi, WiMAX and LTE. The current implementation of LTE does not have support of IPv6 in ns-3. So, the idea of testing MIPv6 code into LTE would follow IPv6 support implementation in LTE first and then the MIPv6 support. Thus, implementation of MIPv6 in ns-3 as the base mobility management solution and providing LTE support within it could help the current network researchers working on ns-3.

* '''Code:''' https://github.com/manoj24rana/MobileIPv6

* '''Documentation:'''
# Detail Description about the Implementation: http://www.sciencedirect.com/science/article/pii/S1569190X16302714
# Phase1 Documentation: https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing
# Phase2 Documentation: https://drive.google.com/open?id=0BziHE2fNAdZRbUZKN01Bd1Rjdk0

* '''About me:''' I am a PhD student in the School of Mobile Computing and Communications, Jadavpur University, India. About my research is given here: http://scholar.google.com/citations?user=qouvajAAAAAJ&hl=en.

= Technical Approach =
*'''First,''' I want to restructure the MIPv6 code, published in http://www.sciencedirect.com/science/article/pii/S1569190X16302714, to make it RFC 6275 compliance. To do the restructuring complete, the following approaches will be performed:
#Code refactoring: reorganizing internetstack, helper and header components of the MIPv6 module through modifying the internal functions, attributes and the callback variables.
#Code analysis: both static and dynamic analysis could be performed. The waf tool for code run, PyViz for visualization and tcpdump for pcap tracing could be used.
#Functional tests: The functional test would be performed in three phase: handoff performance testing, data packet transmission testing and both. Use cases like multiple mobile nodes, multiple correspondent node, different mobility model for the mobile node as well as heterogeneous link layer technologies (Wi-Fi and WiMAX) could be used.
#The code will be sent for the code review to the ns-3 team.
* '''Second,''' IPV6 support for LTE would be ensured as LTE currently, only supports IPv4. The changes would possibly be done within the LTE module files (both .cc and .h) like point-topoint-helper, emu-epc-helper, lte-ue-net-device, epc-sgw-pgw-application, epc-enb-application, lte-enb-net-device etc. Then, the code analysis will be performed as done previously for MIPv6 code. The functional tests would follow bidirectional IPv6 packet transmission between remote host and the UE. The modification/rewriting code will create a patch that could enable IPv6 forwarding in the LTE data plane, enabling the UE to receive and use a /64 prefix, as stated in the standard. It is worth noticing that IP packets are tunnelled in the `core' network (i.e., all the EPC part), and their actual IP address is not used for UE identification in the core. As a consequence, IPv6 use in the `core' network, using ULAs or link-local addresses, could be planned if the previous development is faster than foreseen. This modification could also be simpler than expected, as it is not important to keep a dual stack communication in the core network, and using only IPv6 brings some direct benefits (like simplifying the use of multiple EPCs in a single script).
* '''Third,''' To ensure the code quality, the following testing approach could be used: Test MIPv6 handoff performance with the mixed link layer technologies (combination of Wi-Fi, WiMAX and LTE) case, multiple mobile node case, and multiple correspondent node case.

= Deliverables and Plan =
=== Deliverables: ===

-a basic MIPv6 module, aligned with RFC 6275 following ns-3 coding styles;

-a reviewed patch, fixing the IPv6 support issue in LTE;

-proper documentation and tests for the above-mentioned components.

=== Plan: ===

==== May 4 – May 29 (Before the official coding time): ====

-Familiarize myself completely with MIPv6, LTE (the IPv4 part), and the respective interactions.

-Study of the customized files of ns-3 lte and internet modules

-Familiarize myself with the ns-3 coding styles

During this period I will remain in constant touch with my mentor and the ns-3 community. I will remain active on IRC and Mailing lists to discuss and finalize on the modifications (if any) that needs to be on existing models and design of new module (if needed to fit cleanly with ns-3)

Thus with the help of my mentor I will become absolutely clear about my future goals, the final MIPv6 implementation that need to be done as well as the approach that I will follow to support IPv6 in lte model.

==== May 30 – June 26 (Official coding period starts): ====

-Refactor previous MIPv6 headers to RFC compliance header files

-Refactor all the classes to implement the corresponding header file functions

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the newly implemented MIPv6 module in various testing scenarios. The testing will be done with the systems having Wi-Fi and WiMAX link layer technology

-Sending the code for code review to the ns-3 team

After this stage, the standard ns-3 code revision can be started for the MIPv6 code part. Any change requested by the reviewers will be carried out in parallel with the following activities.

==== June 27 – July 24: ====

-Define new or, modify existing header files and cc files in LTE module in such a way that LTE module remains backward compatible with IPv4

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the LTE module

-Sending the code for code review to the ns-3 team

This will help in testing of the LTE module with IPv6 support for possible merge into the project main tree.

==== July 25 – August 21: ====

-Making further changes in the LTE module to support MIPv6 into it. Changes may be required in the other modules of ns-3 also.

-Testing the overall working in the testing scenarios having the combination of Wi-Fi and LTE

-Most of the time will be consumed for rigorous testing and bug fixes.

-Sending the code for code review to the ns-3 team

-Documentation updates.

= Weekly Reports =

=== May 30 - June 6 ===

1. Restructuring the MIPv6 code.

2. Testing the code in the multiple Mobile Node case

3. Changing the Home Agent functionality a little bit

4. Arise Tunnel Implementation Issue [how mobile node would use its home address for all of its data communication]

=== June 7 - June 13 ===

1. Resolved the issue of home address assignment to mobile node for all of its data communication. So, I have made some tricky callbacks in the L4 protocol a little bit. Now, traffic can be directed in both direction i.e. Mobile node to a web server and a web server to a mobile node

2. Also delete a lot of unnecessary files as well as lines in the code.

3. Tests have been done changing the location of different mobility entities. Almost all are successful. Those are included in "mipv6-test1-4.cc" in scratch of https://github.com/manoj24rana/MobileIPv6.

=== June 14 - June 20 ===

1. Done more tests

2. Add some more features such as defending home address and performing NS handling at HA as described in RFC 6275

3. Find an issue on RFC 6275 i.e. how to defend the mobile node's home address by home agent when it returns to its home network. Try to do something on the basis of ns-3 ipv6 implementation to resolve the issue.

=== June 21 - June 27 ===

1. Documentation on how my implementation differs from RFC 6275 as well as

2. Resolve the above issue

3. Sending the code for review.

=== June 28 - July 04 ===

1. Starting LTE IPv6 implementation part: understanding the end-to-end IPv4 part between UE and remote host, decoding it and discuss with my mentor for changing

2. Start writing code, at least one class modification

3. Test the change whether it is right.

=== July 05 - July 11 ===

1. Complete the modification in the lte module classes and also develop a small IPv6 dealing program to test

2. An issue arise i.e. Address Collision occurs at file: file=../src/internet/model/
ipv6-address-generator.cc, line=484". I am trying to resolve it.

3. Runs the previous IPv4 sample programs, which runs fine.

=== July 12 - July 18 ===

1. Resolve the IPv6 address collision issue in the LTE IPv6 support part.

2. I face another issue on handling multicast packets between UE sets and pgw i.e. those multicast packets are not passed between them as in the middle there is an enb.

3. Add the Sphinx documentation in the mipv6 module.

4. The Attributes and TraceSources are uploaded in mipv6 git.

=== July 19 - July 25 ===

1. Making some examples for the main mipv6 repo.

2. Add two tests in the main mipv6 repo.

3. mipv6 doc file further update.

4. Add and change tracesources and some functionalities in mipv6 model.

=== July 26 - August 1 ===

Finalize the MIPv6 code for review. I have added two nice tests replacing the previous tests, further update the mipv6 doc, trace sources, attributes, examples.
The codes are documented highly. Now the /doc/models/build/html dir contains the model documentation and the /doc/html creates doxygen for the mipv6 module.

=== August 2 - August 15 ===

1. Sent the MIPv6 code for review.

2. Solved LTE IPv6 packet sending issues.

3. Complete LTE IPv6 part, i.e. IPv6 packets are received and sent correctly.

4. Discuss with my mentor (Tommaso) elaborately about the next steps such that this implementation could be rebased in the main ns-3 dev quickly.

=== August 16 - August 22 ===

1. Update the LTE UE and PGW address assignment process in such a way that all IP addresses assigned by an EPC are derived from a base prefix (8 for IPv4 and 32 for IPv6) and each EPC holds a unique 16 bit IPv4 and 48 bit IPv6 subnet prefix to assign addresses to PGW and UEs. This address assignment process is made by keeping in mind the issues stated in https://www.nsnam.org/bugzilla/show_bug.cgi?id=1745 and https://groups.google.com/forum/#!topic/ns-3-users/Tc3IKky1OKo. So, now address duplication would not happen in case of more than one EPC as well as any time we could assign addresses without initializing the address helper. Also, user is given the flexibility to reassign the base 8 or, 32 bit address prefix at any time.

2. The LTE module is updated by IPv6 tests, documentation and examples. So, now the sample program is running and users can use them.

=== August 23 - August 29 ===

1. Submit the Google Work Product.

2. Send the LTE Code for review.

3. Try to resolve the reviewer's comment.

= Final Report for Google =

=== Installation and Running the Work Product ===

1. Depending on your OS, install the ns-3 Prerequisites from this link: https://www.nsnam.org/wiki/Installation#Prerequisites.

2. Download the code from this repository: https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6 and extract it.

3. Make sure that you have installed all the perquisites to install ns-3.25.

4. Run the following commands in your cmd prompt to install it:

$ cd The_Project_Folder

$ cd ns-3.25

$ ./waf -d debug --enable-examples --enable-tests configure

$ ./waf

5. Running MIPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running MIPv6: mipv6-multiple.cc, mipv6-single.cc and mipv6-wifi-wimax.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run mipv6-multiple --vis

This will open a visualizer to see the output and the packet transmission in the background cmd prompt.

6. Running LTE IPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running LTE IPv6: lena-ipv6-ue-rh.cc, lena-ipv6-ue-ue.cc and lena-ipv6-addr-conf.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run lena-ipv6-ue-ue --vis

This will open a visualizer to see the output and the packet transmission in the background cmd prompt.

=== Documentation ===

Either, you follow the prepared documentation,

For MIPv6,

https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing

For LTE IPv6,

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/blob/master/ns-3.25/src/lte/doc/source/lte-design.rst and
https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/blob/master/ns-3.25/src/lte/doc/source/lte-user.rst

or, you could follow the manual for Creating Documentation here: https://www.nsnam.org/docs/manual/html/documentation.html. I have added the appropriate documentations within the code of the above repo of my implementation.

=== Work Flow ===

The following link will describe the weekly update of this project.

https://www.nsnam.org/wiki/GSOC2017MobileIp

The flow of commits in the code could be found in the following link.

https://github.com/manoj24rana/MobileIPv6

=== Future Works ===

The following

GSOC2017MobileIp

2017-08-27T17:49:27Z

Mkrana: /* Work Flow */

{{TOC}}

Return to [[GSOC2017AcceptedProjects | GSoC 2017 Accepted Projects]] page.

= Project overview =

* '''Project name:''' Mobile IPv6 Implementation with LTE support

* '''Student:''' [mailto:manoj24.rana@gmail.com Manoj Kumar Rana]

* '''Mentor:''' [mailto:tommypec@gmail.com Tommaso Pecorella]

* '''Abstract:''' The goal of the project is to implement a novel MIPv6 simulation model which can be integrated into ns-3. The project idea aims at testing the code in different network scenarios, containing different link layer technologies such as Wi-Fi, WiMAX and LTE. The current implementation of LTE does not have support of IPv6 in ns-3. So, the idea of testing MIPv6 code into LTE would follow IPv6 support implementation in LTE first and then the MIPv6 support. Thus, implementation of MIPv6 in ns-3 as the base mobility management solution and providing LTE support within it could help the current network researchers working on ns-3.

* '''Code:''' https://github.com/manoj24rana/MobileIPv6

* '''Documentation:'''
# Detail Description about the Implementation: http://www.sciencedirect.com/science/article/pii/S1569190X16302714
# Phase1 Documentation: https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing
# Phase2 Documentation: https://drive.google.com/open?id=0BziHE2fNAdZRbUZKN01Bd1Rjdk0

* '''About me:''' I am a PhD student in the School of Mobile Computing and Communications, Jadavpur University, India. About my research is given here: http://scholar.google.com/citations?user=qouvajAAAAAJ&hl=en.

= Technical Approach =
*'''First,''' I want to restructure the MIPv6 code, published in http://www.sciencedirect.com/science/article/pii/S1569190X16302714, to make it RFC 6275 compliance. To do the restructuring complete, the following approaches will be performed:
#Code refactoring: reorganizing internetstack, helper and header components of the MIPv6 module through modifying the internal functions, attributes and the callback variables.
#Code analysis: both static and dynamic analysis could be performed. The waf tool for code run, PyViz for visualization and tcpdump for pcap tracing could be used.
#Functional tests: The functional test would be performed in three phase: handoff performance testing, data packet transmission testing and both. Use cases like multiple mobile nodes, multiple correspondent node, different mobility model for the mobile node as well as heterogeneous link layer technologies (Wi-Fi and WiMAX) could be used.
#The code will be sent for the code review to the ns-3 team.
* '''Second,''' IPV6 support for LTE would be ensured as LTE currently, only supports IPv4. The changes would possibly be done within the LTE module files (both .cc and .h) like point-topoint-helper, emu-epc-helper, lte-ue-net-device, epc-sgw-pgw-application, epc-enb-application, lte-enb-net-device etc. Then, the code analysis will be performed as done previously for MIPv6 code. The functional tests would follow bidirectional IPv6 packet transmission between remote host and the UE. The modification/rewriting code will create a patch that could enable IPv6 forwarding in the LTE data plane, enabling the UE to receive and use a /64 prefix, as stated in the standard. It is worth noticing that IP packets are tunnelled in the `core' network (i.e., all the EPC part), and their actual IP address is not used for UE identification in the core. As a consequence, IPv6 use in the `core' network, using ULAs or link-local addresses, could be planned if the previous development is faster than foreseen. This modification could also be simpler than expected, as it is not important to keep a dual stack communication in the core network, and using only IPv6 brings some direct benefits (like simplifying the use of multiple EPCs in a single script).
* '''Third,''' To ensure the code quality, the following testing approach could be used: Test MIPv6 handoff performance with the mixed link layer technologies (combination of Wi-Fi, WiMAX and LTE) case, multiple mobile node case, and multiple correspondent node case.

= Deliverables and Plan =
=== Deliverables: ===

-a basic MIPv6 module, aligned with RFC 6275 following ns-3 coding styles;

-a reviewed patch, fixing the IPv6 support issue in LTE;

-proper documentation and tests for the above-mentioned components.

=== Plan: ===

==== May 4 – May 29 (Before the official coding time): ====

-Familiarize myself completely with MIPv6, LTE (the IPv4 part), and the respective interactions.

-Study of the customized files of ns-3 lte and internet modules

-Familiarize myself with the ns-3 coding styles

During this period I will remain in constant touch with my mentor and the ns-3 community. I will remain active on IRC and Mailing lists to discuss and finalize on the modifications (if any) that needs to be on existing models and design of new module (if needed to fit cleanly with ns-3)

Thus with the help of my mentor I will become absolutely clear about my future goals, the final MIPv6 implementation that need to be done as well as the approach that I will follow to support IPv6 in lte model.

==== May 30 – June 26 (Official coding period starts): ====

-Refactor previous MIPv6 headers to RFC compliance header files

-Refactor all the classes to implement the corresponding header file functions

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the newly implemented MIPv6 module in various testing scenarios. The testing will be done with the systems having Wi-Fi and WiMAX link layer technology

-Sending the code for code review to the ns-3 team

After this stage, the standard ns-3 code revision can be started for the MIPv6 code part. Any change requested by the reviewers will be carried out in parallel with the following activities.

==== June 27 – July 24: ====

-Define new or, modify existing header files and cc files in LTE module in such a way that LTE module remains backward compatible with IPv4

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the LTE module

-Sending the code for code review to the ns-3 team

This will help in testing of the LTE module with IPv6 support for possible merge into the project main tree.

==== July 25 – August 21: ====

-Making further changes in the LTE module to support MIPv6 into it. Changes may be required in the other modules of ns-3 also.

-Testing the overall working in the testing scenarios having the combination of Wi-Fi and LTE

-Most of the time will be consumed for rigorous testing and bug fixes.

-Sending the code for code review to the ns-3 team

-Documentation updates.

= Weekly Reports =

=== May 30 - June 6 ===

1. Restructuring the MIPv6 code.

2. Testing the code in the multiple Mobile Node case

3. Changing the Home Agent functionality a little bit

4. Arise Tunnel Implementation Issue [how mobile node would use its home address for all of its data communication]

=== June 7 - June 13 ===

1. Resolved the issue of home address assignment to mobile node for all of its data communication. So, I have made some tricky callbacks in the L4 protocol a little bit. Now, traffic can be directed in both direction i.e. Mobile node to a web server and a web server to a mobile node

2. Also delete a lot of unnecessary files as well as lines in the code.

3. Tests have been done changing the location of different mobility entities. Almost all are successful. Those are included in "mipv6-test1-4.cc" in scratch of https://github.com/manoj24rana/MobileIPv6.

=== June 14 - June 20 ===

1. Done more tests

2. Add some more features such as defending home address and performing NS handling at HA as described in RFC 6275

3. Find an issue on RFC 6275 i.e. how to defend the mobile node's home address by home agent when it returns to its home network. Try to do something on the basis of ns-3 ipv6 implementation to resolve the issue.

=== June 21 - June 27 ===

1. Documentation on how my implementation differs from RFC 6275 as well as

2. Resolve the above issue

3. Sending the code for review.

=== June 28 - July 04 ===

1. Starting LTE IPv6 implementation part: understanding the end-to-end IPv4 part between UE and remote host, decoding it and discuss with my mentor for changing

2. Start writing code, at least one class modification

3. Test the change whether it is right.

=== July 05 - July 11 ===

1. Complete the modification in the lte module classes and also develop a small IPv6 dealing program to test

2. An issue arise i.e. Address Collision occurs at file: file=../src/internet/model/
ipv6-address-generator.cc, line=484". I am trying to resolve it.

3. Runs the previous IPv4 sample programs, which runs fine.

=== July 12 - July 18 ===

1. Resolve the IPv6 address collision issue in the LTE IPv6 support part.

2. I face another issue on handling multicast packets between UE sets and pgw i.e. those multicast packets are not passed between them as in the middle there is an enb.

3. Add the Sphinx documentation in the mipv6 module.

4. The Attributes and TraceSources are uploaded in mipv6 git.

=== July 19 - July 25 ===

1. Making some examples for the main mipv6 repo.

2. Add two tests in the main mipv6 repo.

3. mipv6 doc file further update.

4. Add and change tracesources and some functionalities in mipv6 model.

=== July 26 - August 1 ===

Finalize the MIPv6 code for review. I have added two nice tests replacing the previous tests, further update the mipv6 doc, trace sources, attributes, examples.
The codes are documented highly. Now the /doc/models/build/html dir contains the model documentation and the /doc/html creates doxygen for the mipv6 module.

=== August 2 - August 15 ===

1. Sent the MIPv6 code for review.

2. Solved LTE IPv6 packet sending issues.

3. Complete LTE IPv6 part, i.e. IPv6 packets are received and sent correctly.

4. Discuss with my mentor (Tommaso) elaborately about the next steps such that this implementation could be rebased in the main ns-3 dev quickly.

=== August 16 - August 22 ===

1. Update the LTE UE and PGW address assignment process in such a way that all IP addresses assigned by an EPC are derived from a base prefix (8 for IPv4 and 32 for IPv6) and each EPC holds a unique 16 bit IPv4 and 48 bit IPv6 subnet prefix to assign addresses to PGW and UEs. This address assignment process is made by keeping in mind the issues stated in https://www.nsnam.org/bugzilla/show_bug.cgi?id=1745 and https://groups.google.com/forum/#!topic/ns-3-users/Tc3IKky1OKo. So, now address duplication would not happen in case of more than one EPC as well as any time we could assign addresses without initializing the address helper. Also, user is given the flexibility to reassign the base 8 or, 32 bit address prefix at any time.

2. The LTE module is updated by IPv6 tests, documentation and examples. So, now the sample program is running and users can use them.

=== August 23 - August 29 ===

1. Submit the Google Work Product.

2. Send the LTE Code for review.

3. Try to run the MIPv6 over LTE.

= Final Report for Google =

=== Installation and Running the Work Product ===

1. Depending on your OS, install the ns-3 Prerequisites from this link: https://www.nsnam.org/wiki/Installation#Prerequisites.

2. Download the code from this repository: https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6 and extract it.

3. Make sure that you have installed all the perquisites to install ns-3.25.

4. Run the following commands in your cmd prompt to install it:

$ cd The_Project_Folder

$ cd ns-3.25

$ ./waf -d debug --enable-examples --enable-tests configure

$ ./waf

5. Running MIPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running MIPv6: mipv6-multiple.cc, mipv6-single.cc and mipv6-wifi-wimax.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run mipv6-multiple --vis

This will open a visualizer to see the output and the packet transmission in the background cmd prompt.

6. Running LTE IPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running LTE IPv6: lena-ipv6-ue-rh.cc, lena-ipv6-ue-ue.cc and lena-ipv6-addr-conf.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run lena-ipv6-ue-ue --vis

This will open a visualizer to see the output and the packet transmission in the background cmd prompt.

=== Documentation ===

Either, you follow the prepared documentation,

For MIPv6,

https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing

For LTE IPv6,

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/blob/master/ns-3.25/src/lte/doc/source/lte-design.rst and
https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/blob/master/ns-3.25/src/lte/doc/source/lte-user.rst

or, you could follow the manual for Creating Documentation here: https://www.nsnam.org/docs/manual/html/documentation.html. I have added the appropriate documentations within the code of the above repo of my implementation.

=== Work Flow ===

The following link will describe the weekly update of this project.

https://www.nsnam.org/wiki/GSOC2017MobileIp

The flow of commits in the code could be found in the following link.

https://github.com/manoj24rana/MobileIPv6

=== Future Works ===

The following

GSOC2017MobileIp

2017-08-27T17:43:37Z

Mkrana: /* Final Report for Google */

{{TOC}}

Return to [[GSOC2017AcceptedProjects | GSoC 2017 Accepted Projects]] page.

= Project overview =

* '''Project name:''' Mobile IPv6 Implementation with LTE support

* '''Student:''' [mailto:manoj24.rana@gmail.com Manoj Kumar Rana]

* '''Mentor:''' [mailto:tommypec@gmail.com Tommaso Pecorella]

* '''Abstract:''' The goal of the project is to implement a novel MIPv6 simulation model which can be integrated into ns-3. The project idea aims at testing the code in different network scenarios, containing different link layer technologies such as Wi-Fi, WiMAX and LTE. The current implementation of LTE does not have support of IPv6 in ns-3. So, the idea of testing MIPv6 code into LTE would follow IPv6 support implementation in LTE first and then the MIPv6 support. Thus, implementation of MIPv6 in ns-3 as the base mobility management solution and providing LTE support within it could help the current network researchers working on ns-3.

* '''Code:''' https://github.com/manoj24rana/MobileIPv6

* '''Documentation:'''
# Detail Description about the Implementation: http://www.sciencedirect.com/science/article/pii/S1569190X16302714
# Phase1 Documentation: https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing
# Phase2 Documentation: https://drive.google.com/open?id=0BziHE2fNAdZRbUZKN01Bd1Rjdk0

* '''About me:''' I am a PhD student in the School of Mobile Computing and Communications, Jadavpur University, India. About my research is given here: http://scholar.google.com/citations?user=qouvajAAAAAJ&hl=en.

= Technical Approach =
*'''First,''' I want to restructure the MIPv6 code, published in http://www.sciencedirect.com/science/article/pii/S1569190X16302714, to make it RFC 6275 compliance. To do the restructuring complete, the following approaches will be performed:
#Code refactoring: reorganizing internetstack, helper and header components of the MIPv6 module through modifying the internal functions, attributes and the callback variables.
#Code analysis: both static and dynamic analysis could be performed. The waf tool for code run, PyViz for visualization and tcpdump for pcap tracing could be used.
#Functional tests: The functional test would be performed in three phase: handoff performance testing, data packet transmission testing and both. Use cases like multiple mobile nodes, multiple correspondent node, different mobility model for the mobile node as well as heterogeneous link layer technologies (Wi-Fi and WiMAX) could be used.
#The code will be sent for the code review to the ns-3 team.
* '''Second,''' IPV6 support for LTE would be ensured as LTE currently, only supports IPv4. The changes would possibly be done within the LTE module files (both .cc and .h) like point-topoint-helper, emu-epc-helper, lte-ue-net-device, epc-sgw-pgw-application, epc-enb-application, lte-enb-net-device etc. Then, the code analysis will be performed as done previously for MIPv6 code. The functional tests would follow bidirectional IPv6 packet transmission between remote host and the UE. The modification/rewriting code will create a patch that could enable IPv6 forwarding in the LTE data plane, enabling the UE to receive and use a /64 prefix, as stated in the standard. It is worth noticing that IP packets are tunnelled in the `core' network (i.e., all the EPC part), and their actual IP address is not used for UE identification in the core. As a consequence, IPv6 use in the `core' network, using ULAs or link-local addresses, could be planned if the previous development is faster than foreseen. This modification could also be simpler than expected, as it is not important to keep a dual stack communication in the core network, and using only IPv6 brings some direct benefits (like simplifying the use of multiple EPCs in a single script).
* '''Third,''' To ensure the code quality, the following testing approach could be used: Test MIPv6 handoff performance with the mixed link layer technologies (combination of Wi-Fi, WiMAX and LTE) case, multiple mobile node case, and multiple correspondent node case.

= Deliverables and Plan =
=== Deliverables: ===

-a basic MIPv6 module, aligned with RFC 6275 following ns-3 coding styles;

-a reviewed patch, fixing the IPv6 support issue in LTE;

-proper documentation and tests for the above-mentioned components.

=== Plan: ===

==== May 4 – May 29 (Before the official coding time): ====

-Familiarize myself completely with MIPv6, LTE (the IPv4 part), and the respective interactions.

-Study of the customized files of ns-3 lte and internet modules

-Familiarize myself with the ns-3 coding styles

During this period I will remain in constant touch with my mentor and the ns-3 community. I will remain active on IRC and Mailing lists to discuss and finalize on the modifications (if any) that needs to be on existing models and design of new module (if needed to fit cleanly with ns-3)

Thus with the help of my mentor I will become absolutely clear about my future goals, the final MIPv6 implementation that need to be done as well as the approach that I will follow to support IPv6 in lte model.

==== May 30 – June 26 (Official coding period starts): ====

-Refactor previous MIPv6 headers to RFC compliance header files

-Refactor all the classes to implement the corresponding header file functions

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the newly implemented MIPv6 module in various testing scenarios. The testing will be done with the systems having Wi-Fi and WiMAX link layer technology

-Sending the code for code review to the ns-3 team

After this stage, the standard ns-3 code revision can be started for the MIPv6 code part. Any change requested by the reviewers will be carried out in parallel with the following activities.

==== June 27 – July 24: ====

-Define new or, modify existing header files and cc files in LTE module in such a way that LTE module remains backward compatible with IPv4

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the LTE module

-Sending the code for code review to the ns-3 team

This will help in testing of the LTE module with IPv6 support for possible merge into the project main tree.

==== July 25 – August 21: ====

-Making further changes in the LTE module to support MIPv6 into it. Changes may be required in the other modules of ns-3 also.

-Testing the overall working in the testing scenarios having the combination of Wi-Fi and LTE

-Most of the time will be consumed for rigorous testing and bug fixes.

-Sending the code for code review to the ns-3 team

-Documentation updates.

= Weekly Reports =

=== May 30 - June 6 ===

1. Restructuring the MIPv6 code.

2. Testing the code in the multiple Mobile Node case

3. Changing the Home Agent functionality a little bit

4. Arise Tunnel Implementation Issue [how mobile node would use its home address for all of its data communication]

=== June 7 - June 13 ===

1. Resolved the issue of home address assignment to mobile node for all of its data communication. So, I have made some tricky callbacks in the L4 protocol a little bit. Now, traffic can be directed in both direction i.e. Mobile node to a web server and a web server to a mobile node

2. Also delete a lot of unnecessary files as well as lines in the code.

3. Tests have been done changing the location of different mobility entities. Almost all are successful. Those are included in "mipv6-test1-4.cc" in scratch of https://github.com/manoj24rana/MobileIPv6.

=== June 14 - June 20 ===

1. Done more tests

2. Add some more features such as defending home address and performing NS handling at HA as described in RFC 6275

3. Find an issue on RFC 6275 i.e. how to defend the mobile node's home address by home agent when it returns to its home network. Try to do something on the basis of ns-3 ipv6 implementation to resolve the issue.

=== June 21 - June 27 ===

1. Documentation on how my implementation differs from RFC 6275 as well as

2. Resolve the above issue

3. Sending the code for review.

=== June 28 - July 04 ===

1. Starting LTE IPv6 implementation part: understanding the end-to-end IPv4 part between UE and remote host, decoding it and discuss with my mentor for changing

2. Start writing code, at least one class modification

3. Test the change whether it is right.

=== July 05 - July 11 ===

1. Complete the modification in the lte module classes and also develop a small IPv6 dealing program to test

2. An issue arise i.e. Address Collision occurs at file: file=../src/internet/model/
ipv6-address-generator.cc, line=484". I am trying to resolve it.

3. Runs the previous IPv4 sample programs, which runs fine.

=== July 12 - July 18 ===

1. Resolve the IPv6 address collision issue in the LTE IPv6 support part.

2. I face another issue on handling multicast packets between UE sets and pgw i.e. those multicast packets are not passed between them as in the middle there is an enb.

3. Add the Sphinx documentation in the mipv6 module.

4. The Attributes and TraceSources are uploaded in mipv6 git.

=== July 19 - July 25 ===

1. Making some examples for the main mipv6 repo.

2. Add two tests in the main mipv6 repo.

3. mipv6 doc file further update.

4. Add and change tracesources and some functionalities in mipv6 model.

=== July 26 - August 1 ===

Finalize the MIPv6 code for review. I have added two nice tests replacing the previous tests, further update the mipv6 doc, trace sources, attributes, examples.
The codes are documented highly. Now the /doc/models/build/html dir contains the model documentation and the /doc/html creates doxygen for the mipv6 module.

=== August 2 - August 15 ===

1. Sent the MIPv6 code for review.

2. Solved LTE IPv6 packet sending issues.

3. Complete LTE IPv6 part, i.e. IPv6 packets are received and sent correctly.

4. Discuss with my mentor (Tommaso) elaborately about the next steps such that this implementation could be rebased in the main ns-3 dev quickly.

=== August 16 - August 22 ===

1. Update the LTE UE and PGW address assignment process in such a way that all IP addresses assigned by an EPC are derived from a base prefix (8 for IPv4 and 32 for IPv6) and each EPC holds a unique 16 bit IPv4 and 48 bit IPv6 subnet prefix to assign addresses to PGW and UEs. This address assignment process is made by keeping in mind the issues stated in https://www.nsnam.org/bugzilla/show_bug.cgi?id=1745 and https://groups.google.com/forum/#!topic/ns-3-users/Tc3IKky1OKo. So, now address duplication would not happen in case of more than one EPC as well as any time we could assign addresses without initializing the address helper. Also, user is given the flexibility to reassign the base 8 or, 32 bit address prefix at any time.

2. The LTE module is updated by IPv6 tests, documentation and examples. So, now the sample program is running and users can use them.

=== August 23 - August 29 ===

1. Submit the Google Work Product.

2. Send the LTE Code for review.

3. Try to run the MIPv6 over LTE.

= Final Report for Google =

=== Installation and Running the Work Product ===

1. Depending on your OS, install the ns-3 Prerequisites from this link: https://www.nsnam.org/wiki/Installation#Prerequisites.

2. Download the code from this repository: https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6 and extract it.

3. Make sure that you have installed all the perquisites to install ns-3.25.

4. Run the following commands in your cmd prompt to install it:

$ cd The_Project_Folder

$ cd ns-3.25

$ ./waf -d debug --enable-examples --enable-tests configure

$ ./waf

5. Running MIPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running MIPv6: mipv6-multiple.cc, mipv6-single.cc and mipv6-wifi-wimax.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run mipv6-multiple --vis

This will open a visualizer to see the output and the packet transmission in the background cmd prompt.

6. Running LTE IPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running LTE IPv6: lena-ipv6-ue-rh.cc, lena-ipv6-ue-ue.cc and lena-ipv6-addr-conf.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run lena-ipv6-ue-ue --vis

This will open a visualizer to see the output and the packet transmission in the background cmd prompt.

=== Documentation ===

Either, you follow the prepared documentation,

For MIPv6,

https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing

For LTE IPv6,

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/blob/master/ns-3.25/src/lte/doc/source/lte-design.rst and
https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/blob/master/ns-3.25/src/lte/doc/source/lte-user.rst

or, you could follow the manual for Creating Documentation here: https://www.nsnam.org/docs/manual/html/documentation.html. I have added the appropriate documentations within the code of the above repo of my implementation.

=== Work Flow ===

The following link will describe the weekly update of this project.

https://www.nsnam.org/wiki/GSOC2017MobileIp

The flow of commits in the code could be found in the following link.

https://github.com/manoj24rana/MobileIPv6

GSOC2017MobileIp

2017-08-27T17:41:25Z

Mkrana: /* Documentation */

{{TOC}}

Return to [[GSOC2017AcceptedProjects | GSoC 2017 Accepted Projects]] page.

= Project overview =

* '''Project name:''' Mobile IPv6 Implementation with LTE support

* '''Student:''' [mailto:manoj24.rana@gmail.com Manoj Kumar Rana]

* '''Mentor:''' [mailto:tommypec@gmail.com Tommaso Pecorella]

* '''Abstract:''' The goal of the project is to implement a novel MIPv6 simulation model which can be integrated into ns-3. The project idea aims at testing the code in different network scenarios, containing different link layer technologies such as Wi-Fi, WiMAX and LTE. The current implementation of LTE does not have support of IPv6 in ns-3. So, the idea of testing MIPv6 code into LTE would follow IPv6 support implementation in LTE first and then the MIPv6 support. Thus, implementation of MIPv6 in ns-3 as the base mobility management solution and providing LTE support within it could help the current network researchers working on ns-3.

* '''Code:''' https://github.com/manoj24rana/MobileIPv6

* '''Documentation:'''
# Detail Description about the Implementation: http://www.sciencedirect.com/science/article/pii/S1569190X16302714
# Phase1 Documentation: https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing
# Phase2 Documentation: https://drive.google.com/open?id=0BziHE2fNAdZRbUZKN01Bd1Rjdk0

* '''About me:''' I am a PhD student in the School of Mobile Computing and Communications, Jadavpur University, India. About my research is given here: http://scholar.google.com/citations?user=qouvajAAAAAJ&hl=en.

= Technical Approach =
*'''First,''' I want to restructure the MIPv6 code, published in http://www.sciencedirect.com/science/article/pii/S1569190X16302714, to make it RFC 6275 compliance. To do the restructuring complete, the following approaches will be performed:
#Code refactoring: reorganizing internetstack, helper and header components of the MIPv6 module through modifying the internal functions, attributes and the callback variables.
#Code analysis: both static and dynamic analysis could be performed. The waf tool for code run, PyViz for visualization and tcpdump for pcap tracing could be used.
#Functional tests: The functional test would be performed in three phase: handoff performance testing, data packet transmission testing and both. Use cases like multiple mobile nodes, multiple correspondent node, different mobility model for the mobile node as well as heterogeneous link layer technologies (Wi-Fi and WiMAX) could be used.
#The code will be sent for the code review to the ns-3 team.
* '''Second,''' IPV6 support for LTE would be ensured as LTE currently, only supports IPv4. The changes would possibly be done within the LTE module files (both .cc and .h) like point-topoint-helper, emu-epc-helper, lte-ue-net-device, epc-sgw-pgw-application, epc-enb-application, lte-enb-net-device etc. Then, the code analysis will be performed as done previously for MIPv6 code. The functional tests would follow bidirectional IPv6 packet transmission between remote host and the UE. The modification/rewriting code will create a patch that could enable IPv6 forwarding in the LTE data plane, enabling the UE to receive and use a /64 prefix, as stated in the standard. It is worth noticing that IP packets are tunnelled in the `core' network (i.e., all the EPC part), and their actual IP address is not used for UE identification in the core. As a consequence, IPv6 use in the `core' network, using ULAs or link-local addresses, could be planned if the previous development is faster than foreseen. This modification could also be simpler than expected, as it is not important to keep a dual stack communication in the core network, and using only IPv6 brings some direct benefits (like simplifying the use of multiple EPCs in a single script).
* '''Third,''' To ensure the code quality, the following testing approach could be used: Test MIPv6 handoff performance with the mixed link layer technologies (combination of Wi-Fi, WiMAX and LTE) case, multiple mobile node case, and multiple correspondent node case.

= Deliverables and Plan =
=== Deliverables: ===

-a basic MIPv6 module, aligned with RFC 6275 following ns-3 coding styles;

-a reviewed patch, fixing the IPv6 support issue in LTE;

-proper documentation and tests for the above-mentioned components.

=== Plan: ===

==== May 4 – May 29 (Before the official coding time): ====

-Familiarize myself completely with MIPv6, LTE (the IPv4 part), and the respective interactions.

-Study of the customized files of ns-3 lte and internet modules

-Familiarize myself with the ns-3 coding styles

During this period I will remain in constant touch with my mentor and the ns-3 community. I will remain active on IRC and Mailing lists to discuss and finalize on the modifications (if any) that needs to be on existing models and design of new module (if needed to fit cleanly with ns-3)

Thus with the help of my mentor I will become absolutely clear about my future goals, the final MIPv6 implementation that need to be done as well as the approach that I will follow to support IPv6 in lte model.

==== May 30 – June 26 (Official coding period starts): ====

-Refactor previous MIPv6 headers to RFC compliance header files

-Refactor all the classes to implement the corresponding header file functions

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the newly implemented MIPv6 module in various testing scenarios. The testing will be done with the systems having Wi-Fi and WiMAX link layer technology

-Sending the code for code review to the ns-3 team

After this stage, the standard ns-3 code revision can be started for the MIPv6 code part. Any change requested by the reviewers will be carried out in parallel with the following activities.

==== June 27 – July 24: ====

-Define new or, modify existing header files and cc files in LTE module in such a way that LTE module remains backward compatible with IPv4

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the LTE module

-Sending the code for code review to the ns-3 team

This will help in testing of the LTE module with IPv6 support for possible merge into the project main tree.

==== July 25 – August 21: ====

-Making further changes in the LTE module to support MIPv6 into it. Changes may be required in the other modules of ns-3 also.

-Testing the overall working in the testing scenarios having the combination of Wi-Fi and LTE

-Most of the time will be consumed for rigorous testing and bug fixes.

-Sending the code for code review to the ns-3 team

-Documentation updates.

= Weekly Reports =

=== May 30 - June 6 ===

1. Restructuring the MIPv6 code.

2. Testing the code in the multiple Mobile Node case

3. Changing the Home Agent functionality a little bit

4. Arise Tunnel Implementation Issue [how mobile node would use its home address for all of its data communication]

=== June 7 - June 13 ===

1. Resolved the issue of home address assignment to mobile node for all of its data communication. So, I have made some tricky callbacks in the L4 protocol a little bit. Now, traffic can be directed in both direction i.e. Mobile node to a web server and a web server to a mobile node

2. Also delete a lot of unnecessary files as well as lines in the code.

3. Tests have been done changing the location of different mobility entities. Almost all are successful. Those are included in "mipv6-test1-4.cc" in scratch of https://github.com/manoj24rana/MobileIPv6.

=== June 14 - June 20 ===

1. Done more tests

2. Add some more features such as defending home address and performing NS handling at HA as described in RFC 6275

3. Find an issue on RFC 6275 i.e. how to defend the mobile node's home address by home agent when it returns to its home network. Try to do something on the basis of ns-3 ipv6 implementation to resolve the issue.

=== June 21 - June 27 ===

1. Documentation on how my implementation differs from RFC 6275 as well as

2. Resolve the above issue

3. Sending the code for review.

=== June 28 - July 04 ===

1. Starting LTE IPv6 implementation part: understanding the end-to-end IPv4 part between UE and remote host, decoding it and discuss with my mentor for changing

2. Start writing code, at least one class modification

3. Test the change whether it is right.

=== July 05 - July 11 ===

1. Complete the modification in the lte module classes and also develop a small IPv6 dealing program to test

2. An issue arise i.e. Address Collision occurs at file: file=../src/internet/model/
ipv6-address-generator.cc, line=484". I am trying to resolve it.

3. Runs the previous IPv4 sample programs, which runs fine.

=== July 12 - July 18 ===

1. Resolve the IPv6 address collision issue in the LTE IPv6 support part.

2. I face another issue on handling multicast packets between UE sets and pgw i.e. those multicast packets are not passed between them as in the middle there is an enb.

3. Add the Sphinx documentation in the mipv6 module.

4. The Attributes and TraceSources are uploaded in mipv6 git.

=== July 19 - July 25 ===

1. Making some examples for the main mipv6 repo.

2. Add two tests in the main mipv6 repo.

3. mipv6 doc file further update.

4. Add and change tracesources and some functionalities in mipv6 model.

=== July 26 - August 1 ===

Finalize the MIPv6 code for review. I have added two nice tests replacing the previous tests, further update the mipv6 doc, trace sources, attributes, examples.
The codes are documented highly. Now the /doc/models/build/html dir contains the model documentation and the /doc/html creates doxygen for the mipv6 module.

=== August 2 - August 15 ===

1. Sent the MIPv6 code for review.

2. Solved LTE IPv6 packet sending issues.

3. Complete LTE IPv6 part, i.e. IPv6 packets are received and sent correctly.

4. Discuss with my mentor (Tommaso) elaborately about the next steps such that this implementation could be rebased in the main ns-3 dev quickly.

=== August 16 - August 22 ===

1. Update the LTE UE and PGW address assignment process in such a way that all IP addresses assigned by an EPC are derived from a base prefix (8 for IPv4 and 32 for IPv6) and each EPC holds a unique 16 bit IPv4 and 48 bit IPv6 subnet prefix to assign addresses to PGW and UEs. This address assignment process is made by keeping in mind the issues stated in https://www.nsnam.org/bugzilla/show_bug.cgi?id=1745 and https://groups.google.com/forum/#!topic/ns-3-users/Tc3IKky1OKo. So, now address duplication would not happen in case of more than one EPC as well as any time we could assign addresses without initializing the address helper. Also, user is given the flexibility to reassign the base 8 or, 32 bit address prefix at any time.

2. The LTE module is updated by IPv6 tests, documentation and examples. So, now the sample program is running and users can use them.

=== August 23 - August 29 ===

1. Submit the Google Work Product.

2. Send the LTE Code for review.

3. Try to run the MIPv6 over LTE.

= Final Report for Google =

=== Installation and Running the Work Product ===

1. Depending on your OS, install the ns-3 Prerequisites from this link: https://www.nsnam.org/wiki/Installation#Prerequisites.

2. Download the code from this repository: https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6 and extract it.

3. Make sure that you have installed all the perquisites to install ns-3.25.

4. Run the following commands in your cmd prompt to install it:

$ cd The_Project_Folder

$ cd ns-3.25

$ ./waf -d debug --enable-examples --enable-tests configure

$ ./waf

5. Running MIPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running MIPv6: mipv6-multiple.cc, mipv6-single.cc and mipv6-wifi-wimax.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run mipv6-multiple --vis

This will open a visualizer to see the output and the packet transmission in the background cmd prompt.

6. Running LTE IPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running LTE IPv6: lena-ipv6-ue-rh.cc, lena-ipv6-ue-ue.cc and lena-ipv6-addr-conf.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run lena-ipv6-ue-ue --vis

This will open a visualizer to see the output and the packet transmission in the background cmd prompt.

=== Documentation ===

Either, you follow the prepared documentation,

For MIPv6,

https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing

For LTE IPv6,

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/blob/master/ns-3.25/src/lte/doc/source/lte-design.rst and
https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/blob/master/ns-3.25/src/lte/doc/source/lte-user.rst

or, you could follow the manual for Creating Documentation here: https://www.nsnam.org/docs/manual/html/documentation.html. I have added the appropriate documentations within the code of the above repo of my implementation.

=== Work Flow ===

The following link will describe the weekly update of this project.

https://www.nsnam.org/wiki/GSOC2017MobileIp

The flow of commits in the code could be found in the following link.

https://github.com/manoj24rana/MobileIPv6

GSOC2017MobileIp

2017-08-27T17:15:13Z

Mkrana: /* Documentation */

{{TOC}}

Return to [[GSOC2017AcceptedProjects | GSoC 2017 Accepted Projects]] page.

= Project overview =

* '''Project name:''' Mobile IPv6 Implementation with LTE support

* '''Student:''' [mailto:manoj24.rana@gmail.com Manoj Kumar Rana]

* '''Mentor:''' [mailto:tommypec@gmail.com Tommaso Pecorella]

* '''Abstract:''' The goal of the project is to implement a novel MIPv6 simulation model which can be integrated into ns-3. The project idea aims at testing the code in different network scenarios, containing different link layer technologies such as Wi-Fi, WiMAX and LTE. The current implementation of LTE does not have support of IPv6 in ns-3. So, the idea of testing MIPv6 code into LTE would follow IPv6 support implementation in LTE first and then the MIPv6 support. Thus, implementation of MIPv6 in ns-3 as the base mobility management solution and providing LTE support within it could help the current network researchers working on ns-3.

* '''Code:''' https://github.com/manoj24rana/MobileIPv6

* '''Documentation:'''
# Detail Description about the Implementation: http://www.sciencedirect.com/science/article/pii/S1569190X16302714
# Phase1 Documentation: https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing
# Phase2 Documentation: https://drive.google.com/open?id=0BziHE2fNAdZRbUZKN01Bd1Rjdk0

* '''About me:''' I am a PhD student in the School of Mobile Computing and Communications, Jadavpur University, India. About my research is given here: http://scholar.google.com/citations?user=qouvajAAAAAJ&hl=en.

= Technical Approach =
*'''First,''' I want to restructure the MIPv6 code, published in http://www.sciencedirect.com/science/article/pii/S1569190X16302714, to make it RFC 6275 compliance. To do the restructuring complete, the following approaches will be performed:
#Code refactoring: reorganizing internetstack, helper and header components of the MIPv6 module through modifying the internal functions, attributes and the callback variables.
#Code analysis: both static and dynamic analysis could be performed. The waf tool for code run, PyViz for visualization and tcpdump for pcap tracing could be used.
#Functional tests: The functional test would be performed in three phase: handoff performance testing, data packet transmission testing and both. Use cases like multiple mobile nodes, multiple correspondent node, different mobility model for the mobile node as well as heterogeneous link layer technologies (Wi-Fi and WiMAX) could be used.
#The code will be sent for the code review to the ns-3 team.
* '''Second,''' IPV6 support for LTE would be ensured as LTE currently, only supports IPv4. The changes would possibly be done within the LTE module files (both .cc and .h) like point-topoint-helper, emu-epc-helper, lte-ue-net-device, epc-sgw-pgw-application, epc-enb-application, lte-enb-net-device etc. Then, the code analysis will be performed as done previously for MIPv6 code. The functional tests would follow bidirectional IPv6 packet transmission between remote host and the UE. The modification/rewriting code will create a patch that could enable IPv6 forwarding in the LTE data plane, enabling the UE to receive and use a /64 prefix, as stated in the standard. It is worth noticing that IP packets are tunnelled in the `core' network (i.e., all the EPC part), and their actual IP address is not used for UE identification in the core. As a consequence, IPv6 use in the `core' network, using ULAs or link-local addresses, could be planned if the previous development is faster than foreseen. This modification could also be simpler than expected, as it is not important to keep a dual stack communication in the core network, and using only IPv6 brings some direct benefits (like simplifying the use of multiple EPCs in a single script).
* '''Third,''' To ensure the code quality, the following testing approach could be used: Test MIPv6 handoff performance with the mixed link layer technologies (combination of Wi-Fi, WiMAX and LTE) case, multiple mobile node case, and multiple correspondent node case.

= Deliverables and Plan =
=== Deliverables: ===

-a basic MIPv6 module, aligned with RFC 6275 following ns-3 coding styles;

-a reviewed patch, fixing the IPv6 support issue in LTE;

-proper documentation and tests for the above-mentioned components.

=== Plan: ===

==== May 4 – May 29 (Before the official coding time): ====

-Familiarize myself completely with MIPv6, LTE (the IPv4 part), and the respective interactions.

-Study of the customized files of ns-3 lte and internet modules

-Familiarize myself with the ns-3 coding styles

During this period I will remain in constant touch with my mentor and the ns-3 community. I will remain active on IRC and Mailing lists to discuss and finalize on the modifications (if any) that needs to be on existing models and design of new module (if needed to fit cleanly with ns-3)

Thus with the help of my mentor I will become absolutely clear about my future goals, the final MIPv6 implementation that need to be done as well as the approach that I will follow to support IPv6 in lte model.

==== May 30 – June 26 (Official coding period starts): ====

-Refactor previous MIPv6 headers to RFC compliance header files

-Refactor all the classes to implement the corresponding header file functions

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the newly implemented MIPv6 module in various testing scenarios. The testing will be done with the systems having Wi-Fi and WiMAX link layer technology

-Sending the code for code review to the ns-3 team

After this stage, the standard ns-3 code revision can be started for the MIPv6 code part. Any change requested by the reviewers will be carried out in parallel with the following activities.

==== June 27 – July 24: ====

-Define new or, modify existing header files and cc files in LTE module in such a way that LTE module remains backward compatible with IPv4

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the LTE module

-Sending the code for code review to the ns-3 team

This will help in testing of the LTE module with IPv6 support for possible merge into the project main tree.

==== July 25 – August 21: ====

-Making further changes in the LTE module to support MIPv6 into it. Changes may be required in the other modules of ns-3 also.

-Testing the overall working in the testing scenarios having the combination of Wi-Fi and LTE

-Most of the time will be consumed for rigorous testing and bug fixes.

-Sending the code for code review to the ns-3 team

-Documentation updates.

= Weekly Reports =

=== May 30 - June 6 ===

1. Restructuring the MIPv6 code.

2. Testing the code in the multiple Mobile Node case

3. Changing the Home Agent functionality a little bit

4. Arise Tunnel Implementation Issue [how mobile node would use its home address for all of its data communication]

=== June 7 - June 13 ===

1. Resolved the issue of home address assignment to mobile node for all of its data communication. So, I have made some tricky callbacks in the L4 protocol a little bit. Now, traffic can be directed in both direction i.e. Mobile node to a web server and a web server to a mobile node

2. Also delete a lot of unnecessary files as well as lines in the code.

3. Tests have been done changing the location of different mobility entities. Almost all are successful. Those are included in "mipv6-test1-4.cc" in scratch of https://github.com/manoj24rana/MobileIPv6.

=== June 14 - June 20 ===

1. Done more tests

2. Add some more features such as defending home address and performing NS handling at HA as described in RFC 6275

3. Find an issue on RFC 6275 i.e. how to defend the mobile node's home address by home agent when it returns to its home network. Try to do something on the basis of ns-3 ipv6 implementation to resolve the issue.

=== June 21 - June 27 ===

1. Documentation on how my implementation differs from RFC 6275 as well as

2. Resolve the above issue

3. Sending the code for review.

=== June 28 - July 04 ===

1. Starting LTE IPv6 implementation part: understanding the end-to-end IPv4 part between UE and remote host, decoding it and discuss with my mentor for changing

2. Start writing code, at least one class modification

3. Test the change whether it is right.

=== July 05 - July 11 ===

1. Complete the modification in the lte module classes and also develop a small IPv6 dealing program to test

2. An issue arise i.e. Address Collision occurs at file: file=../src/internet/model/
ipv6-address-generator.cc, line=484". I am trying to resolve it.

3. Runs the previous IPv4 sample programs, which runs fine.

=== July 12 - July 18 ===

1. Resolve the IPv6 address collision issue in the LTE IPv6 support part.

2. I face another issue on handling multicast packets between UE sets and pgw i.e. those multicast packets are not passed between them as in the middle there is an enb.

3. Add the Sphinx documentation in the mipv6 module.

4. The Attributes and TraceSources are uploaded in mipv6 git.

=== July 19 - July 25 ===

1. Making some examples for the main mipv6 repo.

2. Add two tests in the main mipv6 repo.

3. mipv6 doc file further update.

4. Add and change tracesources and some functionalities in mipv6 model.

=== July 26 - August 1 ===

Finalize the MIPv6 code for review. I have added two nice tests replacing the previous tests, further update the mipv6 doc, trace sources, attributes, examples.
The codes are documented highly. Now the /doc/models/build/html dir contains the model documentation and the /doc/html creates doxygen for the mipv6 module.

=== August 2 - August 15 ===

1. Sent the MIPv6 code for review.

2. Solved LTE IPv6 packet sending issues.

3. Complete LTE IPv6 part, i.e. IPv6 packets are received and sent correctly.

4. Discuss with my mentor (Tommaso) elaborately about the next steps such that this implementation could be rebased in the main ns-3 dev quickly.

=== August 16 - August 22 ===

1. Update the LTE UE and PGW address assignment process in such a way that all IP addresses assigned by an EPC are derived from a base prefix (8 for IPv4 and 32 for IPv6) and each EPC holds a unique 16 bit IPv4 and 48 bit IPv6 subnet prefix to assign addresses to PGW and UEs. This address assignment process is made by keeping in mind the issues stated in https://www.nsnam.org/bugzilla/show_bug.cgi?id=1745 and https://groups.google.com/forum/#!topic/ns-3-users/Tc3IKky1OKo. So, now address duplication would not happen in case of more than one EPC as well as any time we could assign addresses without initializing the address helper. Also, user is given the flexibility to reassign the base 8 or, 32 bit address prefix at any time.

2. The LTE module is updated by IPv6 tests, documentation and examples. So, now the sample program is running and users can use them.

=== August 23 - August 29 ===

1. Submit the Google Work Product.

2. Send the LTE Code for review.

3. Try to run the MIPv6 over LTE.

= Final Report for Google =

=== Installation and Running the Work Product ===

1. Depending on your OS, install the ns-3 Prerequisites from this link: https://www.nsnam.org/wiki/Installation#Prerequisites.

2. Download the code from this repository: https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6 and extract it.

3. Make sure that you have installed all the perquisites to install ns-3.25.

4. Run the following commands in your cmd prompt to install it:

$ cd The_Project_Folder

$ cd ns-3.25

$ ./waf -d debug --enable-examples --enable-tests configure

$ ./waf

5. Running MIPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running MIPv6: mipv6-multiple.cc, mipv6-single.cc and mipv6-wifi-wimax.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run mipv6-multiple --vis

This will open a visualizer to see the output and the packet transmission in the background cmd prompt.

6. Running LTE IPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running LTE IPv6: lena-ipv6-ue-rh.cc, lena-ipv6-ue-ue.cc and lena-ipv6-addr-conf.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run lena-ipv6-ue-ue --vis

This will open a visualizer to see the output and the packet transmission in the background cmd prompt.

=== Documentation ===

Either, you follow the prepared documentation,

For MIPv6,

https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing

For LTE IPv6,

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/blob/master/ns-3.25/src/lte/doc/source/lte-design.rst and
https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/blob/master/ns-3.25/src/lte/doc/source/lte-user.rst

or, you could follow the manual for Creating Documentation here: https://www.nsnam.org/docs/manual/html/documentation.html. I have added the appropriate documentations within the code of the above repo for my implementation.

=== Work Flow ===

The following link will describe the weekly update of this project.

https://www.nsnam.org/wiki/GSOC2017MobileIp

The flow of commits in the code could be found in the following link.

https://github.com/manoj24rana/MobileIPv6

GSOC2017MobileIp

2017-08-27T15:07:28Z

Mkrana: /* Documentation */

{{TOC}}

Return to [[GSOC2017AcceptedProjects | GSoC 2017 Accepted Projects]] page.

= Project overview =

* '''Project name:''' Mobile IPv6 Implementation with LTE support

* '''Student:''' [mailto:manoj24.rana@gmail.com Manoj Kumar Rana]

* '''Mentor:''' [mailto:tommypec@gmail.com Tommaso Pecorella]

* '''Abstract:''' The goal of the project is to implement a novel MIPv6 simulation model which can be integrated into ns-3. The project idea aims at testing the code in different network scenarios, containing different link layer technologies such as Wi-Fi, WiMAX and LTE. The current implementation of LTE does not have support of IPv6 in ns-3. So, the idea of testing MIPv6 code into LTE would follow IPv6 support implementation in LTE first and then the MIPv6 support. Thus, implementation of MIPv6 in ns-3 as the base mobility management solution and providing LTE support within it could help the current network researchers working on ns-3.

* '''Code:''' https://github.com/manoj24rana/MobileIPv6

* '''Documentation:'''
# Detail Description about the Implementation: http://www.sciencedirect.com/science/article/pii/S1569190X16302714
# Phase1 Documentation: https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing
# Phase2 Documentation: https://drive.google.com/open?id=0BziHE2fNAdZRbUZKN01Bd1Rjdk0

* '''About me:''' I am a PhD student in the School of Mobile Computing and Communications, Jadavpur University, India. About my research is given here: http://scholar.google.com/citations?user=qouvajAAAAAJ&hl=en.

= Technical Approach =
*'''First,''' I want to restructure the MIPv6 code, published in http://www.sciencedirect.com/science/article/pii/S1569190X16302714, to make it RFC 6275 compliance. To do the restructuring complete, the following approaches will be performed:
#Code refactoring: reorganizing internetstack, helper and header components of the MIPv6 module through modifying the internal functions, attributes and the callback variables.
#Code analysis: both static and dynamic analysis could be performed. The waf tool for code run, PyViz for visualization and tcpdump for pcap tracing could be used.
#Functional tests: The functional test would be performed in three phase: handoff performance testing, data packet transmission testing and both. Use cases like multiple mobile nodes, multiple correspondent node, different mobility model for the mobile node as well as heterogeneous link layer technologies (Wi-Fi and WiMAX) could be used.
#The code will be sent for the code review to the ns-3 team.
* '''Second,''' IPV6 support for LTE would be ensured as LTE currently, only supports IPv4. The changes would possibly be done within the LTE module files (both .cc and .h) like point-topoint-helper, emu-epc-helper, lte-ue-net-device, epc-sgw-pgw-application, epc-enb-application, lte-enb-net-device etc. Then, the code analysis will be performed as done previously for MIPv6 code. The functional tests would follow bidirectional IPv6 packet transmission between remote host and the UE. The modification/rewriting code will create a patch that could enable IPv6 forwarding in the LTE data plane, enabling the UE to receive and use a /64 prefix, as stated in the standard. It is worth noticing that IP packets are tunnelled in the `core' network (i.e., all the EPC part), and their actual IP address is not used for UE identification in the core. As a consequence, IPv6 use in the `core' network, using ULAs or link-local addresses, could be planned if the previous development is faster than foreseen. This modification could also be simpler than expected, as it is not important to keep a dual stack communication in the core network, and using only IPv6 brings some direct benefits (like simplifying the use of multiple EPCs in a single script).
* '''Third,''' To ensure the code quality, the following testing approach could be used: Test MIPv6 handoff performance with the mixed link layer technologies (combination of Wi-Fi, WiMAX and LTE) case, multiple mobile node case, and multiple correspondent node case.

= Deliverables and Plan =
=== Deliverables: ===

-a basic MIPv6 module, aligned with RFC 6275 following ns-3 coding styles;

-a reviewed patch, fixing the IPv6 support issue in LTE;

-proper documentation and tests for the above-mentioned components.

=== Plan: ===

==== May 4 – May 29 (Before the official coding time): ====

-Familiarize myself completely with MIPv6, LTE (the IPv4 part), and the respective interactions.

-Study of the customized files of ns-3 lte and internet modules

-Familiarize myself with the ns-3 coding styles

During this period I will remain in constant touch with my mentor and the ns-3 community. I will remain active on IRC and Mailing lists to discuss and finalize on the modifications (if any) that needs to be on existing models and design of new module (if needed to fit cleanly with ns-3)

Thus with the help of my mentor I will become absolutely clear about my future goals, the final MIPv6 implementation that need to be done as well as the approach that I will follow to support IPv6 in lte model.

==== May 30 – June 26 (Official coding period starts): ====

-Refactor previous MIPv6 headers to RFC compliance header files

-Refactor all the classes to implement the corresponding header file functions

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the newly implemented MIPv6 module in various testing scenarios. The testing will be done with the systems having Wi-Fi and WiMAX link layer technology

-Sending the code for code review to the ns-3 team

After this stage, the standard ns-3 code revision can be started for the MIPv6 code part. Any change requested by the reviewers will be carried out in parallel with the following activities.

==== June 27 – July 24: ====

-Define new or, modify existing header files and cc files in LTE module in such a way that LTE module remains backward compatible with IPv4

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the LTE module

-Sending the code for code review to the ns-3 team

This will help in testing of the LTE module with IPv6 support for possible merge into the project main tree.

==== July 25 – August 21: ====

-Making further changes in the LTE module to support MIPv6 into it. Changes may be required in the other modules of ns-3 also.

-Testing the overall working in the testing scenarios having the combination of Wi-Fi and LTE

-Most of the time will be consumed for rigorous testing and bug fixes.

-Sending the code for code review to the ns-3 team

-Documentation updates.

= Weekly Reports =

=== May 30 - June 6 ===

1. Restructuring the MIPv6 code.

2. Testing the code in the multiple Mobile Node case

3. Changing the Home Agent functionality a little bit

4. Arise Tunnel Implementation Issue [how mobile node would use its home address for all of its data communication]

=== June 7 - June 13 ===

1. Resolved the issue of home address assignment to mobile node for all of its data communication. So, I have made some tricky callbacks in the L4 protocol a little bit. Now, traffic can be directed in both direction i.e. Mobile node to a web server and a web server to a mobile node

2. Also delete a lot of unnecessary files as well as lines in the code.

3. Tests have been done changing the location of different mobility entities. Almost all are successful. Those are included in "mipv6-test1-4.cc" in scratch of https://github.com/manoj24rana/MobileIPv6.

=== June 14 - June 20 ===

1. Done more tests

2. Add some more features such as defending home address and performing NS handling at HA as described in RFC 6275

3. Find an issue on RFC 6275 i.e. how to defend the mobile node's home address by home agent when it returns to its home network. Try to do something on the basis of ns-3 ipv6 implementation to resolve the issue.

=== June 21 - June 27 ===

1. Documentation on how my implementation differs from RFC 6275 as well as

2. Resolve the above issue

3. Sending the code for review.

=== June 28 - July 04 ===

1. Starting LTE IPv6 implementation part: understanding the end-to-end IPv4 part between UE and remote host, decoding it and discuss with my mentor for changing

2. Start writing code, at least one class modification

3. Test the change whether it is right.

=== July 05 - July 11 ===

1. Complete the modification in the lte module classes and also develop a small IPv6 dealing program to test

2. An issue arise i.e. Address Collision occurs at file: file=../src/internet/model/
ipv6-address-generator.cc, line=484". I am trying to resolve it.

3. Runs the previous IPv4 sample programs, which runs fine.

=== July 12 - July 18 ===

1. Resolve the IPv6 address collision issue in the LTE IPv6 support part.

2. I face another issue on handling multicast packets between UE sets and pgw i.e. those multicast packets are not passed between them as in the middle there is an enb.

3. Add the Sphinx documentation in the mipv6 module.

4. The Attributes and TraceSources are uploaded in mipv6 git.

=== July 19 - July 25 ===

1. Making some examples for the main mipv6 repo.

2. Add two tests in the main mipv6 repo.

3. mipv6 doc file further update.

4. Add and change tracesources and some functionalities in mipv6 model.

=== July 26 - August 1 ===

Finalize the MIPv6 code for review. I have added two nice tests replacing the previous tests, further update the mipv6 doc, trace sources, attributes, examples.
The codes are documented highly. Now the /doc/models/build/html dir contains the model documentation and the /doc/html creates doxygen for the mipv6 module.

=== August 2 - August 15 ===

1. Sent the MIPv6 code for review.

2. Solved LTE IPv6 packet sending issues.

3. Complete LTE IPv6 part, i.e. IPv6 packets are received and sent correctly.

4. Discuss with my mentor (Tommaso) elaborately about the next steps such that this implementation could be rebased in the main ns-3 dev quickly.

=== August 16 - August 22 ===

1. Update the LTE UE and PGW address assignment process in such a way that all IP addresses assigned by an EPC are derived from a base prefix (8 for IPv4 and 32 for IPv6) and each EPC holds a unique 16 bit IPv4 and 48 bit IPv6 subnet prefix to assign addresses to PGW and UEs. This address assignment process is made by keeping in mind the issues stated in https://www.nsnam.org/bugzilla/show_bug.cgi?id=1745 and https://groups.google.com/forum/#!topic/ns-3-users/Tc3IKky1OKo. So, now address duplication would not happen in case of more than one EPC as well as any time we could assign addresses without initializing the address helper. Also, user is given the flexibility to reassign the base 8 or, 32 bit address prefix at any time.

2. The LTE module is updated by IPv6 tests, documentation and examples. So, now the sample program is running and users can use them.

=== August 23 - August 29 ===

1. Submit the Google Work Product.

2. Send the LTE Code for review.

3. Try to run the MIPv6 over LTE.

= Final Report for Google =

=== Installation and Running the Work Product ===

1. Depending on your OS, install the ns-3 Prerequisites from this link: https://www.nsnam.org/wiki/Installation#Prerequisites.

2. Download the code from this repository: https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6 and extract it.

3. Make sure that you have installed all the perquisites to install ns-3.25.

4. Run the following commands in your cmd prompt to install it:

$ cd The_Project_Folder

$ cd ns-3.25

$ ./waf -d debug --enable-examples --enable-tests configure

$ ./waf

5. Running MIPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running MIPv6: mipv6-multiple.cc, mipv6-single.cc and mipv6-wifi-wimax.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run mipv6-multiple --vis

This will open a visualizer to see the output and the packet transmission in the background cmd prompt.

6. Running LTE IPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running LTE IPv6: lena-ipv6-ue-rh.cc, lena-ipv6-ue-ue.cc and lena-ipv6-addr-conf.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run lena-ipv6-ue-ue --vis

This will open a visualizer to see the output and the packet transmission in the background cmd prompt.

=== Documentation ===

Either, you follow the prepared documentation,

For MIPv6,

https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing

For LTE IPv6,

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/blob/master/ns-3.25/src/lte/doc/source/lte-design.rst and
https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/blob/master/ns-3.25/src/lte/doc/source/lte-user.rst

or, you could follow the manual for Creating Documentation here: https://www.nsnam.org/docs/manual/html/documentation.html. I have added the appropriate documentations within the code of the above repo for my implementation.

GSOC2017MobileIp

2017-08-27T15:06:25Z

Mkrana: /* Documentation */

{{TOC}}

Return to [[GSOC2017AcceptedProjects | GSoC 2017 Accepted Projects]] page.

= Project overview =

* '''Project name:''' Mobile IPv6 Implementation with LTE support

* '''Student:''' [mailto:manoj24.rana@gmail.com Manoj Kumar Rana]

* '''Mentor:''' [mailto:tommypec@gmail.com Tommaso Pecorella]

* '''Abstract:''' The goal of the project is to implement a novel MIPv6 simulation model which can be integrated into ns-3. The project idea aims at testing the code in different network scenarios, containing different link layer technologies such as Wi-Fi, WiMAX and LTE. The current implementation of LTE does not have support of IPv6 in ns-3. So, the idea of testing MIPv6 code into LTE would follow IPv6 support implementation in LTE first and then the MIPv6 support. Thus, implementation of MIPv6 in ns-3 as the base mobility management solution and providing LTE support within it could help the current network researchers working on ns-3.

* '''Code:''' https://github.com/manoj24rana/MobileIPv6

* '''Documentation:'''
# Detail Description about the Implementation: http://www.sciencedirect.com/science/article/pii/S1569190X16302714
# Phase1 Documentation: https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing
# Phase2 Documentation: https://drive.google.com/open?id=0BziHE2fNAdZRbUZKN01Bd1Rjdk0

* '''About me:''' I am a PhD student in the School of Mobile Computing and Communications, Jadavpur University, India. About my research is given here: http://scholar.google.com/citations?user=qouvajAAAAAJ&hl=en.

= Technical Approach =
*'''First,''' I want to restructure the MIPv6 code, published in http://www.sciencedirect.com/science/article/pii/S1569190X16302714, to make it RFC 6275 compliance. To do the restructuring complete, the following approaches will be performed:
#Code refactoring: reorganizing internetstack, helper and header components of the MIPv6 module through modifying the internal functions, attributes and the callback variables.
#Code analysis: both static and dynamic analysis could be performed. The waf tool for code run, PyViz for visualization and tcpdump for pcap tracing could be used.
#Functional tests: The functional test would be performed in three phase: handoff performance testing, data packet transmission testing and both. Use cases like multiple mobile nodes, multiple correspondent node, different mobility model for the mobile node as well as heterogeneous link layer technologies (Wi-Fi and WiMAX) could be used.
#The code will be sent for the code review to the ns-3 team.
* '''Second,''' IPV6 support for LTE would be ensured as LTE currently, only supports IPv4. The changes would possibly be done within the LTE module files (both .cc and .h) like point-topoint-helper, emu-epc-helper, lte-ue-net-device, epc-sgw-pgw-application, epc-enb-application, lte-enb-net-device etc. Then, the code analysis will be performed as done previously for MIPv6 code. The functional tests would follow bidirectional IPv6 packet transmission between remote host and the UE. The modification/rewriting code will create a patch that could enable IPv6 forwarding in the LTE data plane, enabling the UE to receive and use a /64 prefix, as stated in the standard. It is worth noticing that IP packets are tunnelled in the `core' network (i.e., all the EPC part), and their actual IP address is not used for UE identification in the core. As a consequence, IPv6 use in the `core' network, using ULAs or link-local addresses, could be planned if the previous development is faster than foreseen. This modification could also be simpler than expected, as it is not important to keep a dual stack communication in the core network, and using only IPv6 brings some direct benefits (like simplifying the use of multiple EPCs in a single script).
* '''Third,''' To ensure the code quality, the following testing approach could be used: Test MIPv6 handoff performance with the mixed link layer technologies (combination of Wi-Fi, WiMAX and LTE) case, multiple mobile node case, and multiple correspondent node case.

= Deliverables and Plan =
=== Deliverables: ===

-a basic MIPv6 module, aligned with RFC 6275 following ns-3 coding styles;

-a reviewed patch, fixing the IPv6 support issue in LTE;

-proper documentation and tests for the above-mentioned components.

=== Plan: ===

==== May 4 – May 29 (Before the official coding time): ====

-Familiarize myself completely with MIPv6, LTE (the IPv4 part), and the respective interactions.

-Study of the customized files of ns-3 lte and internet modules

-Familiarize myself with the ns-3 coding styles

During this period I will remain in constant touch with my mentor and the ns-3 community. I will remain active on IRC and Mailing lists to discuss and finalize on the modifications (if any) that needs to be on existing models and design of new module (if needed to fit cleanly with ns-3)

Thus with the help of my mentor I will become absolutely clear about my future goals, the final MIPv6 implementation that need to be done as well as the approach that I will follow to support IPv6 in lte model.

==== May 30 – June 26 (Official coding period starts): ====

-Refactor previous MIPv6 headers to RFC compliance header files

-Refactor all the classes to implement the corresponding header file functions

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the newly implemented MIPv6 module in various testing scenarios. The testing will be done with the systems having Wi-Fi and WiMAX link layer technology

-Sending the code for code review to the ns-3 team

After this stage, the standard ns-3 code revision can be started for the MIPv6 code part. Any change requested by the reviewers will be carried out in parallel with the following activities.

==== June 27 – July 24: ====

-Define new or, modify existing header files and cc files in LTE module in such a way that LTE module remains backward compatible with IPv4

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the LTE module

-Sending the code for code review to the ns-3 team

This will help in testing of the LTE module with IPv6 support for possible merge into the project main tree.

==== July 25 – August 21: ====

-Making further changes in the LTE module to support MIPv6 into it. Changes may be required in the other modules of ns-3 also.

-Testing the overall working in the testing scenarios having the combination of Wi-Fi and LTE

-Most of the time will be consumed for rigorous testing and bug fixes.

-Sending the code for code review to the ns-3 team

-Documentation updates.

= Weekly Reports =

=== May 30 - June 6 ===

1. Restructuring the MIPv6 code.

2. Testing the code in the multiple Mobile Node case

3. Changing the Home Agent functionality a little bit

4. Arise Tunnel Implementation Issue [how mobile node would use its home address for all of its data communication]

=== June 7 - June 13 ===

1. Resolved the issue of home address assignment to mobile node for all of its data communication. So, I have made some tricky callbacks in the L4 protocol a little bit. Now, traffic can be directed in both direction i.e. Mobile node to a web server and a web server to a mobile node

2. Also delete a lot of unnecessary files as well as lines in the code.

3. Tests have been done changing the location of different mobility entities. Almost all are successful. Those are included in "mipv6-test1-4.cc" in scratch of https://github.com/manoj24rana/MobileIPv6.

=== June 14 - June 20 ===

1. Done more tests

2. Add some more features such as defending home address and performing NS handling at HA as described in RFC 6275

3. Find an issue on RFC 6275 i.e. how to defend the mobile node's home address by home agent when it returns to its home network. Try to do something on the basis of ns-3 ipv6 implementation to resolve the issue.

=== June 21 - June 27 ===

1. Documentation on how my implementation differs from RFC 6275 as well as

2. Resolve the above issue

3. Sending the code for review.

=== June 28 - July 04 ===

1. Starting LTE IPv6 implementation part: understanding the end-to-end IPv4 part between UE and remote host, decoding it and discuss with my mentor for changing

2. Start writing code, at least one class modification

3. Test the change whether it is right.

=== July 05 - July 11 ===

1. Complete the modification in the lte module classes and also develop a small IPv6 dealing program to test

2. An issue arise i.e. Address Collision occurs at file: file=../src/internet/model/
ipv6-address-generator.cc, line=484". I am trying to resolve it.

3. Runs the previous IPv4 sample programs, which runs fine.

=== July 12 - July 18 ===

1. Resolve the IPv6 address collision issue in the LTE IPv6 support part.

2. I face another issue on handling multicast packets between UE sets and pgw i.e. those multicast packets are not passed between them as in the middle there is an enb.

3. Add the Sphinx documentation in the mipv6 module.

4. The Attributes and TraceSources are uploaded in mipv6 git.

=== July 19 - July 25 ===

1. Making some examples for the main mipv6 repo.

2. Add two tests in the main mipv6 repo.

3. mipv6 doc file further update.

4. Add and change tracesources and some functionalities in mipv6 model.

=== July 26 - August 1 ===

Finalize the MIPv6 code for review. I have added two nice tests replacing the previous tests, further update the mipv6 doc, trace sources, attributes, examples.
The codes are documented highly. Now the /doc/models/build/html dir contains the model documentation and the /doc/html creates doxygen for the mipv6 module.

=== August 2 - August 15 ===

1. Sent the MIPv6 code for review.

2. Solved LTE IPv6 packet sending issues.

3. Complete LTE IPv6 part, i.e. IPv6 packets are received and sent correctly.

4. Discuss with my mentor (Tommaso) elaborately about the next steps such that this implementation could be rebased in the main ns-3 dev quickly.

=== August 16 - August 22 ===

1. Update the LTE UE and PGW address assignment process in such a way that all IP addresses assigned by an EPC are derived from a base prefix (8 for IPv4 and 32 for IPv6) and each EPC holds a unique 16 bit IPv4 and 48 bit IPv6 subnet prefix to assign addresses to PGW and UEs. This address assignment process is made by keeping in mind the issues stated in https://www.nsnam.org/bugzilla/show_bug.cgi?id=1745 and https://groups.google.com/forum/#!topic/ns-3-users/Tc3IKky1OKo. So, now address duplication would not happen in case of more than one EPC as well as any time we could assign addresses without initializing the address helper. Also, user is given the flexibility to reassign the base 8 or, 32 bit address prefix at any time.

2. The LTE module is updated by IPv6 tests, documentation and examples. So, now the sample program is running and users can use them.

=== August 23 - August 29 ===

1. Submit the Google Work Product.

2. Send the LTE Code for review.

3. Try to run the MIPv6 over LTE.

= Final Report for Google =

=== Installation and Running the Work Product ===

1. Depending on your OS, install the ns-3 Prerequisites from this link: https://www.nsnam.org/wiki/Installation#Prerequisites.

2. Download the code from this repository: https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6 and extract it.

3. Make sure that you have installed all the perquisites to install ns-3.25.

4. Run the following commands in your cmd prompt to install it:

$ cd The_Project_Folder

$ cd ns-3.25

$ ./waf -d debug --enable-examples --enable-tests configure

$ ./waf

5. Running MIPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running MIPv6: mipv6-multiple.cc, mipv6-single.cc and mipv6-wifi-wimax.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run mipv6-multiple --vis

This will open a visualizer to see the output and the packet transmission in the background cmd prompt.

6. Running LTE IPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running LTE IPv6: lena-ipv6-ue-rh.cc, lena-ipv6-ue-ue.cc and lena-ipv6-addr-conf.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run lena-ipv6-ue-ue --vis

This will open a visualizer to see the output and the packet transmission in the background cmd prompt.

=== Documentation ===

Either, you follow the prepared documentation,

For MIPv6,

https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing

For LTE IPv6,

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/blob/master/ns-3.25/src/lte/doc/source/lte-design.rst and
https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/blob/master/ns-3.25/src/lte/doc/source/lte-user.rst

or, you could follow the manual for Creating Documentation here: https://www.nsnam.org/docs/manual/html/documentation.html. I have added the appropriate documentations within the code the above repo for my implementation.

GSOC2017MobileIp

2017-08-27T15:05:59Z

Mkrana: /* Documentation */

{{TOC}}

Return to [[GSOC2017AcceptedProjects | GSoC 2017 Accepted Projects]] page.

= Project overview =

* '''Project name:''' Mobile IPv6 Implementation with LTE support

* '''Student:''' [mailto:manoj24.rana@gmail.com Manoj Kumar Rana]

* '''Mentor:''' [mailto:tommypec@gmail.com Tommaso Pecorella]

* '''Abstract:''' The goal of the project is to implement a novel MIPv6 simulation model which can be integrated into ns-3. The project idea aims at testing the code in different network scenarios, containing different link layer technologies such as Wi-Fi, WiMAX and LTE. The current implementation of LTE does not have support of IPv6 in ns-3. So, the idea of testing MIPv6 code into LTE would follow IPv6 support implementation in LTE first and then the MIPv6 support. Thus, implementation of MIPv6 in ns-3 as the base mobility management solution and providing LTE support within it could help the current network researchers working on ns-3.

* '''Code:''' https://github.com/manoj24rana/MobileIPv6

* '''Documentation:'''
# Detail Description about the Implementation: http://www.sciencedirect.com/science/article/pii/S1569190X16302714
# Phase1 Documentation: https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing
# Phase2 Documentation: https://drive.google.com/open?id=0BziHE2fNAdZRbUZKN01Bd1Rjdk0

* '''About me:''' I am a PhD student in the School of Mobile Computing and Communications, Jadavpur University, India. About my research is given here: http://scholar.google.com/citations?user=qouvajAAAAAJ&hl=en.

= Technical Approach =
*'''First,''' I want to restructure the MIPv6 code, published in http://www.sciencedirect.com/science/article/pii/S1569190X16302714, to make it RFC 6275 compliance. To do the restructuring complete, the following approaches will be performed:
#Code refactoring: reorganizing internetstack, helper and header components of the MIPv6 module through modifying the internal functions, attributes and the callback variables.
#Code analysis: both static and dynamic analysis could be performed. The waf tool for code run, PyViz for visualization and tcpdump for pcap tracing could be used.
#Functional tests: The functional test would be performed in three phase: handoff performance testing, data packet transmission testing and both. Use cases like multiple mobile nodes, multiple correspondent node, different mobility model for the mobile node as well as heterogeneous link layer technologies (Wi-Fi and WiMAX) could be used.
#The code will be sent for the code review to the ns-3 team.
* '''Second,''' IPV6 support for LTE would be ensured as LTE currently, only supports IPv4. The changes would possibly be done within the LTE module files (both .cc and .h) like point-topoint-helper, emu-epc-helper, lte-ue-net-device, epc-sgw-pgw-application, epc-enb-application, lte-enb-net-device etc. Then, the code analysis will be performed as done previously for MIPv6 code. The functional tests would follow bidirectional IPv6 packet transmission between remote host and the UE. The modification/rewriting code will create a patch that could enable IPv6 forwarding in the LTE data plane, enabling the UE to receive and use a /64 prefix, as stated in the standard. It is worth noticing that IP packets are tunnelled in the `core' network (i.e., all the EPC part), and their actual IP address is not used for UE identification in the core. As a consequence, IPv6 use in the `core' network, using ULAs or link-local addresses, could be planned if the previous development is faster than foreseen. This modification could also be simpler than expected, as it is not important to keep a dual stack communication in the core network, and using only IPv6 brings some direct benefits (like simplifying the use of multiple EPCs in a single script).
* '''Third,''' To ensure the code quality, the following testing approach could be used: Test MIPv6 handoff performance with the mixed link layer technologies (combination of Wi-Fi, WiMAX and LTE) case, multiple mobile node case, and multiple correspondent node case.

= Deliverables and Plan =
=== Deliverables: ===

-a basic MIPv6 module, aligned with RFC 6275 following ns-3 coding styles;

-a reviewed patch, fixing the IPv6 support issue in LTE;

-proper documentation and tests for the above-mentioned components.

=== Plan: ===

==== May 4 – May 29 (Before the official coding time): ====

-Familiarize myself completely with MIPv6, LTE (the IPv4 part), and the respective interactions.

-Study of the customized files of ns-3 lte and internet modules

-Familiarize myself with the ns-3 coding styles

During this period I will remain in constant touch with my mentor and the ns-3 community. I will remain active on IRC and Mailing lists to discuss and finalize on the modifications (if any) that needs to be on existing models and design of new module (if needed to fit cleanly with ns-3)

Thus with the help of my mentor I will become absolutely clear about my future goals, the final MIPv6 implementation that need to be done as well as the approach that I will follow to support IPv6 in lte model.

==== May 30 – June 26 (Official coding period starts): ====

-Refactor previous MIPv6 headers to RFC compliance header files

-Refactor all the classes to implement the corresponding header file functions

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the newly implemented MIPv6 module in various testing scenarios. The testing will be done with the systems having Wi-Fi and WiMAX link layer technology

-Sending the code for code review to the ns-3 team

After this stage, the standard ns-3 code revision can be started for the MIPv6 code part. Any change requested by the reviewers will be carried out in parallel with the following activities.

==== June 27 – July 24: ====

-Define new or, modify existing header files and cc files in LTE module in such a way that LTE module remains backward compatible with IPv4

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the LTE module

-Sending the code for code review to the ns-3 team

This will help in testing of the LTE module with IPv6 support for possible merge into the project main tree.

==== July 25 – August 21: ====

-Making further changes in the LTE module to support MIPv6 into it. Changes may be required in the other modules of ns-3 also.

-Testing the overall working in the testing scenarios having the combination of Wi-Fi and LTE

-Most of the time will be consumed for rigorous testing and bug fixes.

-Sending the code for code review to the ns-3 team

-Documentation updates.

= Weekly Reports =

=== May 30 - June 6 ===

1. Restructuring the MIPv6 code.

2. Testing the code in the multiple Mobile Node case

3. Changing the Home Agent functionality a little bit

4. Arise Tunnel Implementation Issue [how mobile node would use its home address for all of its data communication]

=== June 7 - June 13 ===

1. Resolved the issue of home address assignment to mobile node for all of its data communication. So, I have made some tricky callbacks in the L4 protocol a little bit. Now, traffic can be directed in both direction i.e. Mobile node to a web server and a web server to a mobile node

2. Also delete a lot of unnecessary files as well as lines in the code.

3. Tests have been done changing the location of different mobility entities. Almost all are successful. Those are included in "mipv6-test1-4.cc" in scratch of https://github.com/manoj24rana/MobileIPv6.

=== June 14 - June 20 ===

1. Done more tests

2. Add some more features such as defending home address and performing NS handling at HA as described in RFC 6275

3. Find an issue on RFC 6275 i.e. how to defend the mobile node's home address by home agent when it returns to its home network. Try to do something on the basis of ns-3 ipv6 implementation to resolve the issue.

=== June 21 - June 27 ===

1. Documentation on how my implementation differs from RFC 6275 as well as

2. Resolve the above issue

3. Sending the code for review.

=== June 28 - July 04 ===

1. Starting LTE IPv6 implementation part: understanding the end-to-end IPv4 part between UE and remote host, decoding it and discuss with my mentor for changing

2. Start writing code, at least one class modification

3. Test the change whether it is right.

=== July 05 - July 11 ===

1. Complete the modification in the lte module classes and also develop a small IPv6 dealing program to test

2. An issue arise i.e. Address Collision occurs at file: file=../src/internet/model/
ipv6-address-generator.cc, line=484". I am trying to resolve it.

3. Runs the previous IPv4 sample programs, which runs fine.

=== July 12 - July 18 ===

1. Resolve the IPv6 address collision issue in the LTE IPv6 support part.

2. I face another issue on handling multicast packets between UE sets and pgw i.e. those multicast packets are not passed between them as in the middle there is an enb.

3. Add the Sphinx documentation in the mipv6 module.

4. The Attributes and TraceSources are uploaded in mipv6 git.

=== July 19 - July 25 ===

1. Making some examples for the main mipv6 repo.

2. Add two tests in the main mipv6 repo.

3. mipv6 doc file further update.

4. Add and change tracesources and some functionalities in mipv6 model.

=== July 26 - August 1 ===

Finalize the MIPv6 code for review. I have added two nice tests replacing the previous tests, further update the mipv6 doc, trace sources, attributes, examples.
The codes are documented highly. Now the /doc/models/build/html dir contains the model documentation and the /doc/html creates doxygen for the mipv6 module.

=== August 2 - August 15 ===

1. Sent the MIPv6 code for review.

2. Solved LTE IPv6 packet sending issues.

3. Complete LTE IPv6 part, i.e. IPv6 packets are received and sent correctly.

4. Discuss with my mentor (Tommaso) elaborately about the next steps such that this implementation could be rebased in the main ns-3 dev quickly.

=== August 16 - August 22 ===

1. Update the LTE UE and PGW address assignment process in such a way that all IP addresses assigned by an EPC are derived from a base prefix (8 for IPv4 and 32 for IPv6) and each EPC holds a unique 16 bit IPv4 and 48 bit IPv6 subnet prefix to assign addresses to PGW and UEs. This address assignment process is made by keeping in mind the issues stated in https://www.nsnam.org/bugzilla/show_bug.cgi?id=1745 and https://groups.google.com/forum/#!topic/ns-3-users/Tc3IKky1OKo. So, now address duplication would not happen in case of more than one EPC as well as any time we could assign addresses without initializing the address helper. Also, user is given the flexibility to reassign the base 8 or, 32 bit address prefix at any time.

2. The LTE module is updated by IPv6 tests, documentation and examples. So, now the sample program is running and users can use them.

=== August 23 - August 29 ===

1. Submit the Google Work Product.

2. Send the LTE Code for review.

3. Try to run the MIPv6 over LTE.

= Final Report for Google =

=== Installation and Running the Work Product ===

1. Depending on your OS, install the ns-3 Prerequisites from this link: https://www.nsnam.org/wiki/Installation#Prerequisites.

2. Download the code from this repository: https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6 and extract it.

3. Make sure that you have installed all the perquisites to install ns-3.25.

4. Run the following commands in your cmd prompt to install it:

$ cd The_Project_Folder

$ cd ns-3.25

$ ./waf -d debug --enable-examples --enable-tests configure

$ ./waf

5. Running MIPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running MIPv6: mipv6-multiple.cc, mipv6-single.cc and mipv6-wifi-wimax.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run mipv6-multiple --vis

This will open a visualizer to see the output and the packet transmission in the background cmd prompt.

6. Running LTE IPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running LTE IPv6: lena-ipv6-ue-rh.cc, lena-ipv6-ue-ue.cc and lena-ipv6-addr-conf.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run lena-ipv6-ue-ue --vis

This will open a visualizer to see the output and the packet transmission in the background cmd prompt.

=== Documentation ===

Either, you follow the prepared documentation,

For MIPv6,

https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing

For LTE IPv6,

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/blob/master/ns-3.25/src/lte/doc/source/lte-design.rst and

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/blob/master/ns-3.25/src/lte/doc/source/lte-user.rst

or, you could follow the manual for Creating Documentation here: https://www.nsnam.org/docs/manual/html/documentation.html. I have added the appropriate documentations within the code the above repo for my implementation.

GSOC2017MobileIp

2017-08-27T15:04:26Z

Mkrana: /* Installation and Running the Work Product */

{{TOC}}

Return to [[GSOC2017AcceptedProjects | GSoC 2017 Accepted Projects]] page.

= Project overview =

* '''Project name:''' Mobile IPv6 Implementation with LTE support

* '''Student:''' [mailto:manoj24.rana@gmail.com Manoj Kumar Rana]

* '''Mentor:''' [mailto:tommypec@gmail.com Tommaso Pecorella]

* '''Abstract:''' The goal of the project is to implement a novel MIPv6 simulation model which can be integrated into ns-3. The project idea aims at testing the code in different network scenarios, containing different link layer technologies such as Wi-Fi, WiMAX and LTE. The current implementation of LTE does not have support of IPv6 in ns-3. So, the idea of testing MIPv6 code into LTE would follow IPv6 support implementation in LTE first and then the MIPv6 support. Thus, implementation of MIPv6 in ns-3 as the base mobility management solution and providing LTE support within it could help the current network researchers working on ns-3.

* '''Code:''' https://github.com/manoj24rana/MobileIPv6

* '''Documentation:'''
# Detail Description about the Implementation: http://www.sciencedirect.com/science/article/pii/S1569190X16302714
# Phase1 Documentation: https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing
# Phase2 Documentation: https://drive.google.com/open?id=0BziHE2fNAdZRbUZKN01Bd1Rjdk0

* '''About me:''' I am a PhD student in the School of Mobile Computing and Communications, Jadavpur University, India. About my research is given here: http://scholar.google.com/citations?user=qouvajAAAAAJ&hl=en.

= Technical Approach =
*'''First,''' I want to restructure the MIPv6 code, published in http://www.sciencedirect.com/science/article/pii/S1569190X16302714, to make it RFC 6275 compliance. To do the restructuring complete, the following approaches will be performed:
#Code refactoring: reorganizing internetstack, helper and header components of the MIPv6 module through modifying the internal functions, attributes and the callback variables.
#Code analysis: both static and dynamic analysis could be performed. The waf tool for code run, PyViz for visualization and tcpdump for pcap tracing could be used.
#Functional tests: The functional test would be performed in three phase: handoff performance testing, data packet transmission testing and both. Use cases like multiple mobile nodes, multiple correspondent node, different mobility model for the mobile node as well as heterogeneous link layer technologies (Wi-Fi and WiMAX) could be used.
#The code will be sent for the code review to the ns-3 team.
* '''Second,''' IPV6 support for LTE would be ensured as LTE currently, only supports IPv4. The changes would possibly be done within the LTE module files (both .cc and .h) like point-topoint-helper, emu-epc-helper, lte-ue-net-device, epc-sgw-pgw-application, epc-enb-application, lte-enb-net-device etc. Then, the code analysis will be performed as done previously for MIPv6 code. The functional tests would follow bidirectional IPv6 packet transmission between remote host and the UE. The modification/rewriting code will create a patch that could enable IPv6 forwarding in the LTE data plane, enabling the UE to receive and use a /64 prefix, as stated in the standard. It is worth noticing that IP packets are tunnelled in the `core' network (i.e., all the EPC part), and their actual IP address is not used for UE identification in the core. As a consequence, IPv6 use in the `core' network, using ULAs or link-local addresses, could be planned if the previous development is faster than foreseen. This modification could also be simpler than expected, as it is not important to keep a dual stack communication in the core network, and using only IPv6 brings some direct benefits (like simplifying the use of multiple EPCs in a single script).
* '''Third,''' To ensure the code quality, the following testing approach could be used: Test MIPv6 handoff performance with the mixed link layer technologies (combination of Wi-Fi, WiMAX and LTE) case, multiple mobile node case, and multiple correspondent node case.

= Deliverables and Plan =
=== Deliverables: ===

-a basic MIPv6 module, aligned with RFC 6275 following ns-3 coding styles;

-a reviewed patch, fixing the IPv6 support issue in LTE;

-proper documentation and tests for the above-mentioned components.

=== Plan: ===

==== May 4 – May 29 (Before the official coding time): ====

-Familiarize myself completely with MIPv6, LTE (the IPv4 part), and the respective interactions.

-Study of the customized files of ns-3 lte and internet modules

-Familiarize myself with the ns-3 coding styles

During this period I will remain in constant touch with my mentor and the ns-3 community. I will remain active on IRC and Mailing lists to discuss and finalize on the modifications (if any) that needs to be on existing models and design of new module (if needed to fit cleanly with ns-3)

Thus with the help of my mentor I will become absolutely clear about my future goals, the final MIPv6 implementation that need to be done as well as the approach that I will follow to support IPv6 in lte model.

==== May 30 – June 26 (Official coding period starts): ====

-Refactor previous MIPv6 headers to RFC compliance header files

-Refactor all the classes to implement the corresponding header file functions

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the newly implemented MIPv6 module in various testing scenarios. The testing will be done with the systems having Wi-Fi and WiMAX link layer technology

-Sending the code for code review to the ns-3 team

After this stage, the standard ns-3 code revision can be started for the MIPv6 code part. Any change requested by the reviewers will be carried out in parallel with the following activities.

==== June 27 – July 24: ====

-Define new or, modify existing header files and cc files in LTE module in such a way that LTE module remains backward compatible with IPv4

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the LTE module

-Sending the code for code review to the ns-3 team

This will help in testing of the LTE module with IPv6 support for possible merge into the project main tree.

==== July 25 – August 21: ====

-Making further changes in the LTE module to support MIPv6 into it. Changes may be required in the other modules of ns-3 also.

-Testing the overall working in the testing scenarios having the combination of Wi-Fi and LTE

-Most of the time will be consumed for rigorous testing and bug fixes.

-Sending the code for code review to the ns-3 team

-Documentation updates.

= Weekly Reports =

=== May 30 - June 6 ===

1. Restructuring the MIPv6 code.

2. Testing the code in the multiple Mobile Node case

3. Changing the Home Agent functionality a little bit

4. Arise Tunnel Implementation Issue [how mobile node would use its home address for all of its data communication]

=== June 7 - June 13 ===

1. Resolved the issue of home address assignment to mobile node for all of its data communication. So, I have made some tricky callbacks in the L4 protocol a little bit. Now, traffic can be directed in both direction i.e. Mobile node to a web server and a web server to a mobile node

2. Also delete a lot of unnecessary files as well as lines in the code.

3. Tests have been done changing the location of different mobility entities. Almost all are successful. Those are included in "mipv6-test1-4.cc" in scratch of https://github.com/manoj24rana/MobileIPv6.

=== June 14 - June 20 ===

1. Done more tests

2. Add some more features such as defending home address and performing NS handling at HA as described in RFC 6275

3. Find an issue on RFC 6275 i.e. how to defend the mobile node's home address by home agent when it returns to its home network. Try to do something on the basis of ns-3 ipv6 implementation to resolve the issue.

=== June 21 - June 27 ===

1. Documentation on how my implementation differs from RFC 6275 as well as

2. Resolve the above issue

3. Sending the code for review.

=== June 28 - July 04 ===

1. Starting LTE IPv6 implementation part: understanding the end-to-end IPv4 part between UE and remote host, decoding it and discuss with my mentor for changing

2. Start writing code, at least one class modification

3. Test the change whether it is right.

=== July 05 - July 11 ===

1. Complete the modification in the lte module classes and also develop a small IPv6 dealing program to test

2. An issue arise i.e. Address Collision occurs at file: file=../src/internet/model/
ipv6-address-generator.cc, line=484". I am trying to resolve it.

3. Runs the previous IPv4 sample programs, which runs fine.

=== July 12 - July 18 ===

1. Resolve the IPv6 address collision issue in the LTE IPv6 support part.

2. I face another issue on handling multicast packets between UE sets and pgw i.e. those multicast packets are not passed between them as in the middle there is an enb.

3. Add the Sphinx documentation in the mipv6 module.

4. The Attributes and TraceSources are uploaded in mipv6 git.

=== July 19 - July 25 ===

1. Making some examples for the main mipv6 repo.

2. Add two tests in the main mipv6 repo.

3. mipv6 doc file further update.

4. Add and change tracesources and some functionalities in mipv6 model.

=== July 26 - August 1 ===

Finalize the MIPv6 code for review. I have added two nice tests replacing the previous tests, further update the mipv6 doc, trace sources, attributes, examples.
The codes are documented highly. Now the /doc/models/build/html dir contains the model documentation and the /doc/html creates doxygen for the mipv6 module.

=== August 2 - August 15 ===

1. Sent the MIPv6 code for review.

2. Solved LTE IPv6 packet sending issues.

3. Complete LTE IPv6 part, i.e. IPv6 packets are received and sent correctly.

4. Discuss with my mentor (Tommaso) elaborately about the next steps such that this implementation could be rebased in the main ns-3 dev quickly.

=== August 16 - August 22 ===

1. Update the LTE UE and PGW address assignment process in such a way that all IP addresses assigned by an EPC are derived from a base prefix (8 for IPv4 and 32 for IPv6) and each EPC holds a unique 16 bit IPv4 and 48 bit IPv6 subnet prefix to assign addresses to PGW and UEs. This address assignment process is made by keeping in mind the issues stated in https://www.nsnam.org/bugzilla/show_bug.cgi?id=1745 and https://groups.google.com/forum/#!topic/ns-3-users/Tc3IKky1OKo. So, now address duplication would not happen in case of more than one EPC as well as any time we could assign addresses without initializing the address helper. Also, user is given the flexibility to reassign the base 8 or, 32 bit address prefix at any time.

2. The LTE module is updated by IPv6 tests, documentation and examples. So, now the sample program is running and users can use them.

=== August 23 - August 29 ===

1. Submit the Google Work Product.

2. Send the LTE Code for review.

3. Try to run the MIPv6 over LTE.

= Final Report for Google =

=== Installation and Running the Work Product ===

1. Depending on your OS, install the ns-3 Prerequisites from this link: https://www.nsnam.org/wiki/Installation#Prerequisites.

2. Download the code from this repository: https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6 and extract it.

3. Make sure that you have installed all the perquisites to install ns-3.25.

4. Run the following commands in your cmd prompt to install it:

$ cd The_Project_Folder

$ cd ns-3.25

$ ./waf -d debug --enable-examples --enable-tests configure

$ ./waf

5. Running MIPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running MIPv6: mipv6-multiple.cc, mipv6-single.cc and mipv6-wifi-wimax.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run mipv6-multiple --vis

This will open a visualizer to see the output and the packet transmission in the background cmd prompt.

6. Running LTE IPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running LTE IPv6: lena-ipv6-ue-rh.cc, lena-ipv6-ue-ue.cc and lena-ipv6-addr-conf.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run lena-ipv6-ue-ue --vis

This will open a visualizer to see the output and the packet transmission in the background cmd prompt.

=== Documentation ===

Either, you follow the prepared documentation,

For MIPv6, https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing

For LTE IPv6, https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/blob/master/ns-3.25/src/lte/doc/source/lte-design.rst and

https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6/blob/master/ns-3.25/src/lte/doc/source/lte-user.rst

or, you could follow the manual for Creating Documentation here: https://www.nsnam.org/docs/manual/html/documentation.html. I have added the appropriate documentations within the repo for my implementation.

GSOC2017MobileIp

2017-08-27T14:35:59Z

Mkrana: /* Installation and Running the Work Product */

{{TOC}}

Return to [[GSOC2017AcceptedProjects | GSoC 2017 Accepted Projects]] page.

= Project overview =

* '''Project name:''' Mobile IPv6 Implementation with LTE support

* '''Student:''' [mailto:manoj24.rana@gmail.com Manoj Kumar Rana]

* '''Mentor:''' [mailto:tommypec@gmail.com Tommaso Pecorella]

* '''Abstract:''' The goal of the project is to implement a novel MIPv6 simulation model which can be integrated into ns-3. The project idea aims at testing the code in different network scenarios, containing different link layer technologies such as Wi-Fi, WiMAX and LTE. The current implementation of LTE does not have support of IPv6 in ns-3. So, the idea of testing MIPv6 code into LTE would follow IPv6 support implementation in LTE first and then the MIPv6 support. Thus, implementation of MIPv6 in ns-3 as the base mobility management solution and providing LTE support within it could help the current network researchers working on ns-3.

* '''Code:''' https://github.com/manoj24rana/MobileIPv6

* '''Documentation:'''
# Detail Description about the Implementation: http://www.sciencedirect.com/science/article/pii/S1569190X16302714
# Phase1 Documentation: https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing
# Phase2 Documentation: https://drive.google.com/open?id=0BziHE2fNAdZRbUZKN01Bd1Rjdk0

* '''About me:''' I am a PhD student in the School of Mobile Computing and Communications, Jadavpur University, India. About my research is given here: http://scholar.google.com/citations?user=qouvajAAAAAJ&hl=en.

= Technical Approach =
*'''First,''' I want to restructure the MIPv6 code, published in http://www.sciencedirect.com/science/article/pii/S1569190X16302714, to make it RFC 6275 compliance. To do the restructuring complete, the following approaches will be performed:
#Code refactoring: reorganizing internetstack, helper and header components of the MIPv6 module through modifying the internal functions, attributes and the callback variables.
#Code analysis: both static and dynamic analysis could be performed. The waf tool for code run, PyViz for visualization and tcpdump for pcap tracing could be used.
#Functional tests: The functional test would be performed in three phase: handoff performance testing, data packet transmission testing and both. Use cases like multiple mobile nodes, multiple correspondent node, different mobility model for the mobile node as well as heterogeneous link layer technologies (Wi-Fi and WiMAX) could be used.
#The code will be sent for the code review to the ns-3 team.
* '''Second,''' IPV6 support for LTE would be ensured as LTE currently, only supports IPv4. The changes would possibly be done within the LTE module files (both .cc and .h) like point-topoint-helper, emu-epc-helper, lte-ue-net-device, epc-sgw-pgw-application, epc-enb-application, lte-enb-net-device etc. Then, the code analysis will be performed as done previously for MIPv6 code. The functional tests would follow bidirectional IPv6 packet transmission between remote host and the UE. The modification/rewriting code will create a patch that could enable IPv6 forwarding in the LTE data plane, enabling the UE to receive and use a /64 prefix, as stated in the standard. It is worth noticing that IP packets are tunnelled in the `core' network (i.e., all the EPC part), and their actual IP address is not used for UE identification in the core. As a consequence, IPv6 use in the `core' network, using ULAs or link-local addresses, could be planned if the previous development is faster than foreseen. This modification could also be simpler than expected, as it is not important to keep a dual stack communication in the core network, and using only IPv6 brings some direct benefits (like simplifying the use of multiple EPCs in a single script).
* '''Third,''' To ensure the code quality, the following testing approach could be used: Test MIPv6 handoff performance with the mixed link layer technologies (combination of Wi-Fi, WiMAX and LTE) case, multiple mobile node case, and multiple correspondent node case.

= Deliverables and Plan =
=== Deliverables: ===

-a basic MIPv6 module, aligned with RFC 6275 following ns-3 coding styles;

-a reviewed patch, fixing the IPv6 support issue in LTE;

-proper documentation and tests for the above-mentioned components.

=== Plan: ===

==== May 4 – May 29 (Before the official coding time): ====

-Familiarize myself completely with MIPv6, LTE (the IPv4 part), and the respective interactions.

-Study of the customized files of ns-3 lte and internet modules

-Familiarize myself with the ns-3 coding styles

During this period I will remain in constant touch with my mentor and the ns-3 community. I will remain active on IRC and Mailing lists to discuss and finalize on the modifications (if any) that needs to be on existing models and design of new module (if needed to fit cleanly with ns-3)

Thus with the help of my mentor I will become absolutely clear about my future goals, the final MIPv6 implementation that need to be done as well as the approach that I will follow to support IPv6 in lte model.

==== May 30 – June 26 (Official coding period starts): ====

-Refactor previous MIPv6 headers to RFC compliance header files

-Refactor all the classes to implement the corresponding header file functions

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the newly implemented MIPv6 module in various testing scenarios. The testing will be done with the systems having Wi-Fi and WiMAX link layer technology

-Sending the code for code review to the ns-3 team

After this stage, the standard ns-3 code revision can be started for the MIPv6 code part. Any change requested by the reviewers will be carried out in parallel with the following activities.

==== June 27 – July 24: ====

-Define new or, modify existing header files and cc files in LTE module in such a way that LTE module remains backward compatible with IPv4

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the LTE module

-Sending the code for code review to the ns-3 team

This will help in testing of the LTE module with IPv6 support for possible merge into the project main tree.

==== July 25 – August 21: ====

-Making further changes in the LTE module to support MIPv6 into it. Changes may be required in the other modules of ns-3 also.

-Testing the overall working in the testing scenarios having the combination of Wi-Fi and LTE

-Most of the time will be consumed for rigorous testing and bug fixes.

-Sending the code for code review to the ns-3 team

-Documentation updates.

= Weekly Reports =

=== May 30 - June 6 ===

1. Restructuring the MIPv6 code.

2. Testing the code in the multiple Mobile Node case

3. Changing the Home Agent functionality a little bit

4. Arise Tunnel Implementation Issue [how mobile node would use its home address for all of its data communication]

=== June 7 - June 13 ===

1. Resolved the issue of home address assignment to mobile node for all of its data communication. So, I have made some tricky callbacks in the L4 protocol a little bit. Now, traffic can be directed in both direction i.e. Mobile node to a web server and a web server to a mobile node

2. Also delete a lot of unnecessary files as well as lines in the code.

3. Tests have been done changing the location of different mobility entities. Almost all are successful. Those are included in "mipv6-test1-4.cc" in scratch of https://github.com/manoj24rana/MobileIPv6.

=== June 14 - June 20 ===

1. Done more tests

2. Add some more features such as defending home address and performing NS handling at HA as described in RFC 6275

3. Find an issue on RFC 6275 i.e. how to defend the mobile node's home address by home agent when it returns to its home network. Try to do something on the basis of ns-3 ipv6 implementation to resolve the issue.

=== June 21 - June 27 ===

1. Documentation on how my implementation differs from RFC 6275 as well as

2. Resolve the above issue

3. Sending the code for review.

=== June 28 - July 04 ===

1. Starting LTE IPv6 implementation part: understanding the end-to-end IPv4 part between UE and remote host, decoding it and discuss with my mentor for changing

2. Start writing code, at least one class modification

3. Test the change whether it is right.

=== July 05 - July 11 ===

1. Complete the modification in the lte module classes and also develop a small IPv6 dealing program to test

2. An issue arise i.e. Address Collision occurs at file: file=../src/internet/model/
ipv6-address-generator.cc, line=484". I am trying to resolve it.

3. Runs the previous IPv4 sample programs, which runs fine.

=== July 12 - July 18 ===

1. Resolve the IPv6 address collision issue in the LTE IPv6 support part.

2. I face another issue on handling multicast packets between UE sets and pgw i.e. those multicast packets are not passed between them as in the middle there is an enb.

3. Add the Sphinx documentation in the mipv6 module.

4. The Attributes and TraceSources are uploaded in mipv6 git.

=== July 19 - July 25 ===

1. Making some examples for the main mipv6 repo.

2. Add two tests in the main mipv6 repo.

3. mipv6 doc file further update.

4. Add and change tracesources and some functionalities in mipv6 model.

=== July 26 - August 1 ===

Finalize the MIPv6 code for review. I have added two nice tests replacing the previous tests, further update the mipv6 doc, trace sources, attributes, examples.
The codes are documented highly. Now the /doc/models/build/html dir contains the model documentation and the /doc/html creates doxygen for the mipv6 module.

=== August 2 - August 15 ===

1. Sent the MIPv6 code for review.

2. Solved LTE IPv6 packet sending issues.

3. Complete LTE IPv6 part, i.e. IPv6 packets are received and sent correctly.

4. Discuss with my mentor (Tommaso) elaborately about the next steps such that this implementation could be rebased in the main ns-3 dev quickly.

=== August 16 - August 22 ===

1. Update the LTE UE and PGW address assignment process in such a way that all IP addresses assigned by an EPC are derived from a base prefix (8 for IPv4 and 32 for IPv6) and each EPC holds a unique 16 bit IPv4 and 48 bit IPv6 subnet prefix to assign addresses to PGW and UEs. This address assignment process is made by keeping in mind the issues stated in https://www.nsnam.org/bugzilla/show_bug.cgi?id=1745 and https://groups.google.com/forum/#!topic/ns-3-users/Tc3IKky1OKo. So, now address duplication would not happen in case of more than one EPC as well as any time we could assign addresses without initializing the address helper. Also, user is given the flexibility to reassign the base 8 or, 32 bit address prefix at any time.

2. The LTE module is updated by IPv6 tests, documentation and examples. So, now the sample program is running and users can use them.

=== August 23 - August 29 ===

1. Submit the Google Work Product.

2. Send the LTE Code for review.

3. Try to run the MIPv6 over LTE.

= Final Report for Google =

=== Installation and Running the Work Product ===

1. Depending on your OS, install the ns-3 Prerequisites from this link: https://www.nsnam.org/wiki/Installation#Prerequisites.

2. Download the code from this repository: https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6 and extract it.

3. Make sure that you have installed all the perquisites to install ns-3.25.

4. Run the following commands in your cmd prompt to install it:

$ cd The_Project_Folder

$ cd ns-3.25

$ ./waf -d debug --enable-examples --enable-tests configure

$ ./waf

5. Running MIPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running MIPv6: mipv6-multiple.cc, mipv6-single.cc and mipv6-wifi-wimax.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run mipv6-multiple --vis

This will open a visualizer to see the output and the packet transmission in the background cmd prompt.

6. Running LTE IPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running LTE IPv6: lena-ipv6-ue-rh.cc, lena-ipv6-ue-ue.cc and lena-ipv6-addr-conf.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run lena-ipv6-ue-ue --vis

This will open a visualizer to see the output and the packet transmission in the background cmd prompt.

GSOC2017MobileIp

2017-08-27T14:33:07Z

Mkrana: /* Installation and Running the Work Product */

{{TOC}}

Return to [[GSOC2017AcceptedProjects | GSoC 2017 Accepted Projects]] page.

= Project overview =

* '''Project name:''' Mobile IPv6 Implementation with LTE support

* '''Student:''' [mailto:manoj24.rana@gmail.com Manoj Kumar Rana]

* '''Mentor:''' [mailto:tommypec@gmail.com Tommaso Pecorella]

* '''Abstract:''' The goal of the project is to implement a novel MIPv6 simulation model which can be integrated into ns-3. The project idea aims at testing the code in different network scenarios, containing different link layer technologies such as Wi-Fi, WiMAX and LTE. The current implementation of LTE does not have support of IPv6 in ns-3. So, the idea of testing MIPv6 code into LTE would follow IPv6 support implementation in LTE first and then the MIPv6 support. Thus, implementation of MIPv6 in ns-3 as the base mobility management solution and providing LTE support within it could help the current network researchers working on ns-3.

* '''Code:''' https://github.com/manoj24rana/MobileIPv6

* '''Documentation:'''
# Detail Description about the Implementation: http://www.sciencedirect.com/science/article/pii/S1569190X16302714
# Phase1 Documentation: https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing
# Phase2 Documentation: https://drive.google.com/open?id=0BziHE2fNAdZRbUZKN01Bd1Rjdk0

* '''About me:''' I am a PhD student in the School of Mobile Computing and Communications, Jadavpur University, India. About my research is given here: http://scholar.google.com/citations?user=qouvajAAAAAJ&hl=en.

= Technical Approach =
*'''First,''' I want to restructure the MIPv6 code, published in http://www.sciencedirect.com/science/article/pii/S1569190X16302714, to make it RFC 6275 compliance. To do the restructuring complete, the following approaches will be performed:
#Code refactoring: reorganizing internetstack, helper and header components of the MIPv6 module through modifying the internal functions, attributes and the callback variables.
#Code analysis: both static and dynamic analysis could be performed. The waf tool for code run, PyViz for visualization and tcpdump for pcap tracing could be used.
#Functional tests: The functional test would be performed in three phase: handoff performance testing, data packet transmission testing and both. Use cases like multiple mobile nodes, multiple correspondent node, different mobility model for the mobile node as well as heterogeneous link layer technologies (Wi-Fi and WiMAX) could be used.
#The code will be sent for the code review to the ns-3 team.
* '''Second,''' IPV6 support for LTE would be ensured as LTE currently, only supports IPv4. The changes would possibly be done within the LTE module files (both .cc and .h) like point-topoint-helper, emu-epc-helper, lte-ue-net-device, epc-sgw-pgw-application, epc-enb-application, lte-enb-net-device etc. Then, the code analysis will be performed as done previously for MIPv6 code. The functional tests would follow bidirectional IPv6 packet transmission between remote host and the UE. The modification/rewriting code will create a patch that could enable IPv6 forwarding in the LTE data plane, enabling the UE to receive and use a /64 prefix, as stated in the standard. It is worth noticing that IP packets are tunnelled in the `core' network (i.e., all the EPC part), and their actual IP address is not used for UE identification in the core. As a consequence, IPv6 use in the `core' network, using ULAs or link-local addresses, could be planned if the previous development is faster than foreseen. This modification could also be simpler than expected, as it is not important to keep a dual stack communication in the core network, and using only IPv6 brings some direct benefits (like simplifying the use of multiple EPCs in a single script).
* '''Third,''' To ensure the code quality, the following testing approach could be used: Test MIPv6 handoff performance with the mixed link layer technologies (combination of Wi-Fi, WiMAX and LTE) case, multiple mobile node case, and multiple correspondent node case.

= Deliverables and Plan =
=== Deliverables: ===

-a basic MIPv6 module, aligned with RFC 6275 following ns-3 coding styles;

-a reviewed patch, fixing the IPv6 support issue in LTE;

-proper documentation and tests for the above-mentioned components.

=== Plan: ===

==== May 4 – May 29 (Before the official coding time): ====

-Familiarize myself completely with MIPv6, LTE (the IPv4 part), and the respective interactions.

-Study of the customized files of ns-3 lte and internet modules

-Familiarize myself with the ns-3 coding styles

During this period I will remain in constant touch with my mentor and the ns-3 community. I will remain active on IRC and Mailing lists to discuss and finalize on the modifications (if any) that needs to be on existing models and design of new module (if needed to fit cleanly with ns-3)

Thus with the help of my mentor I will become absolutely clear about my future goals, the final MIPv6 implementation that need to be done as well as the approach that I will follow to support IPv6 in lte model.

==== May 30 – June 26 (Official coding period starts): ====

-Refactor previous MIPv6 headers to RFC compliance header files

-Refactor all the classes to implement the corresponding header file functions

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the newly implemented MIPv6 module in various testing scenarios. The testing will be done with the systems having Wi-Fi and WiMAX link layer technology

-Sending the code for code review to the ns-3 team

After this stage, the standard ns-3 code revision can be started for the MIPv6 code part. Any change requested by the reviewers will be carried out in parallel with the following activities.

==== June 27 – July 24: ====

-Define new or, modify existing header files and cc files in LTE module in such a way that LTE module remains backward compatible with IPv4

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the LTE module

-Sending the code for code review to the ns-3 team

This will help in testing of the LTE module with IPv6 support for possible merge into the project main tree.

==== July 25 – August 21: ====

-Making further changes in the LTE module to support MIPv6 into it. Changes may be required in the other modules of ns-3 also.

-Testing the overall working in the testing scenarios having the combination of Wi-Fi and LTE

-Most of the time will be consumed for rigorous testing and bug fixes.

-Sending the code for code review to the ns-3 team

-Documentation updates.

= Weekly Reports =

=== May 30 - June 6 ===

1. Restructuring the MIPv6 code.

2. Testing the code in the multiple Mobile Node case

3. Changing the Home Agent functionality a little bit

4. Arise Tunnel Implementation Issue [how mobile node would use its home address for all of its data communication]

=== June 7 - June 13 ===

1. Resolved the issue of home address assignment to mobile node for all of its data communication. So, I have made some tricky callbacks in the L4 protocol a little bit. Now, traffic can be directed in both direction i.e. Mobile node to a web server and a web server to a mobile node

2. Also delete a lot of unnecessary files as well as lines in the code.

3. Tests have been done changing the location of different mobility entities. Almost all are successful. Those are included in "mipv6-test1-4.cc" in scratch of https://github.com/manoj24rana/MobileIPv6.

=== June 14 - June 20 ===

1. Done more tests

2. Add some more features such as defending home address and performing NS handling at HA as described in RFC 6275

3. Find an issue on RFC 6275 i.e. how to defend the mobile node's home address by home agent when it returns to its home network. Try to do something on the basis of ns-3 ipv6 implementation to resolve the issue.

=== June 21 - June 27 ===

1. Documentation on how my implementation differs from RFC 6275 as well as

2. Resolve the above issue

3. Sending the code for review.

=== June 28 - July 04 ===

1. Starting LTE IPv6 implementation part: understanding the end-to-end IPv4 part between UE and remote host, decoding it and discuss with my mentor for changing

2. Start writing code, at least one class modification

3. Test the change whether it is right.

=== July 05 - July 11 ===

1. Complete the modification in the lte module classes and also develop a small IPv6 dealing program to test

2. An issue arise i.e. Address Collision occurs at file: file=../src/internet/model/
ipv6-address-generator.cc, line=484". I am trying to resolve it.

3. Runs the previous IPv4 sample programs, which runs fine.

=== July 12 - July 18 ===

1. Resolve the IPv6 address collision issue in the LTE IPv6 support part.

2. I face another issue on handling multicast packets between UE sets and pgw i.e. those multicast packets are not passed between them as in the middle there is an enb.

3. Add the Sphinx documentation in the mipv6 module.

4. The Attributes and TraceSources are uploaded in mipv6 git.

=== July 19 - July 25 ===

1. Making some examples for the main mipv6 repo.

2. Add two tests in the main mipv6 repo.

3. mipv6 doc file further update.

4. Add and change tracesources and some functionalities in mipv6 model.

=== July 26 - August 1 ===

Finalize the MIPv6 code for review. I have added two nice tests replacing the previous tests, further update the mipv6 doc, trace sources, attributes, examples.
The codes are documented highly. Now the /doc/models/build/html dir contains the model documentation and the /doc/html creates doxygen for the mipv6 module.

=== August 2 - August 15 ===

1. Sent the MIPv6 code for review.

2. Solved LTE IPv6 packet sending issues.

3. Complete LTE IPv6 part, i.e. IPv6 packets are received and sent correctly.

4. Discuss with my mentor (Tommaso) elaborately about the next steps such that this implementation could be rebased in the main ns-3 dev quickly.

=== August 16 - August 22 ===

1. Update the LTE UE and PGW address assignment process in such a way that all IP addresses assigned by an EPC are derived from a base prefix (8 for IPv4 and 32 for IPv6) and each EPC holds a unique 16 bit IPv4 and 48 bit IPv6 subnet prefix to assign addresses to PGW and UEs. This address assignment process is made by keeping in mind the issues stated in https://www.nsnam.org/bugzilla/show_bug.cgi?id=1745 and https://groups.google.com/forum/#!topic/ns-3-users/Tc3IKky1OKo. So, now address duplication would not happen in case of more than one EPC as well as any time we could assign addresses without initializing the address helper. Also, user is given the flexibility to reassign the base 8 or, 32 bit address prefix at any time.

2. The LTE module is updated by IPv6 tests, documentation and examples. So, now the sample program is running and users can use them.

=== August 23 - August 29 ===

1. Submit the Google Work Product.

2. Send the LTE Code for review.

3. Try to run the MIPv6 over LTE.

= Final Report for Google =

=== Installation and Running the Work Product ===

1. Depending on your OS, install the ns-3 Prerequisites from this link: https://www.nsnam.org/wiki/Installation#Prerequisites.

2. Download the code from this repository: https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6 and extract it.

3. Make sure that you have installed all the perquisites to install ns-3.25.

4. Run the following commands in your cmd prompt to install it:

$ cd The_Project_Folder

$ cd ns-3.25

$ ./waf -d debug --enable-examples --enable-tests configure

$ ./waf

5. Running MIPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running MIPv6: mipv6-multiple.cc, mipv6-single.cc and mipv6-wifi-wimax.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run mipv6-multiple --vis

This will open a visualizer to see the output and the packet transmission in the background cmd.

6. Running LTE IPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running LTE IPv6: lena-ipv6-ue-rh.cc, lena-ipv6-ue-ue.cc and lena-ipv6-addr-conf.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run lena-ipv6-ue-ue --vis

This will open a visualizer to see the output and the packet transmission in the background cmd.

GSOC2017MobileIp

2017-08-27T14:31:45Z

Mkrana: /* Final Report */

{{TOC}}

Return to [[GSOC2017AcceptedProjects | GSoC 2017 Accepted Projects]] page.

= Project overview =

* '''Project name:''' Mobile IPv6 Implementation with LTE support

* '''Student:''' [mailto:manoj24.rana@gmail.com Manoj Kumar Rana]

* '''Mentor:''' [mailto:tommypec@gmail.com Tommaso Pecorella]

* '''Abstract:''' The goal of the project is to implement a novel MIPv6 simulation model which can be integrated into ns-3. The project idea aims at testing the code in different network scenarios, containing different link layer technologies such as Wi-Fi, WiMAX and LTE. The current implementation of LTE does not have support of IPv6 in ns-3. So, the idea of testing MIPv6 code into LTE would follow IPv6 support implementation in LTE first and then the MIPv6 support. Thus, implementation of MIPv6 in ns-3 as the base mobility management solution and providing LTE support within it could help the current network researchers working on ns-3.

* '''Code:''' https://github.com/manoj24rana/MobileIPv6

* '''Documentation:'''
# Detail Description about the Implementation: http://www.sciencedirect.com/science/article/pii/S1569190X16302714
# Phase1 Documentation: https://drive.google.com/file/d/0BziHE2fNAdZRaTBzRDViblVZd3c/view?usp=sharing
# Phase2 Documentation: https://drive.google.com/open?id=0BziHE2fNAdZRbUZKN01Bd1Rjdk0

* '''About me:''' I am a PhD student in the School of Mobile Computing and Communications, Jadavpur University, India. About my research is given here: http://scholar.google.com/citations?user=qouvajAAAAAJ&hl=en.

= Technical Approach =
*'''First,''' I want to restructure the MIPv6 code, published in http://www.sciencedirect.com/science/article/pii/S1569190X16302714, to make it RFC 6275 compliance. To do the restructuring complete, the following approaches will be performed:
#Code refactoring: reorganizing internetstack, helper and header components of the MIPv6 module through modifying the internal functions, attributes and the callback variables.
#Code analysis: both static and dynamic analysis could be performed. The waf tool for code run, PyViz for visualization and tcpdump for pcap tracing could be used.
#Functional tests: The functional test would be performed in three phase: handoff performance testing, data packet transmission testing and both. Use cases like multiple mobile nodes, multiple correspondent node, different mobility model for the mobile node as well as heterogeneous link layer technologies (Wi-Fi and WiMAX) could be used.
#The code will be sent for the code review to the ns-3 team.
* '''Second,''' IPV6 support for LTE would be ensured as LTE currently, only supports IPv4. The changes would possibly be done within the LTE module files (both .cc and .h) like point-topoint-helper, emu-epc-helper, lte-ue-net-device, epc-sgw-pgw-application, epc-enb-application, lte-enb-net-device etc. Then, the code analysis will be performed as done previously for MIPv6 code. The functional tests would follow bidirectional IPv6 packet transmission between remote host and the UE. The modification/rewriting code will create a patch that could enable IPv6 forwarding in the LTE data plane, enabling the UE to receive and use a /64 prefix, as stated in the standard. It is worth noticing that IP packets are tunnelled in the `core' network (i.e., all the EPC part), and their actual IP address is not used for UE identification in the core. As a consequence, IPv6 use in the `core' network, using ULAs or link-local addresses, could be planned if the previous development is faster than foreseen. This modification could also be simpler than expected, as it is not important to keep a dual stack communication in the core network, and using only IPv6 brings some direct benefits (like simplifying the use of multiple EPCs in a single script).
* '''Third,''' To ensure the code quality, the following testing approach could be used: Test MIPv6 handoff performance with the mixed link layer technologies (combination of Wi-Fi, WiMAX and LTE) case, multiple mobile node case, and multiple correspondent node case.

= Deliverables and Plan =
=== Deliverables: ===

-a basic MIPv6 module, aligned with RFC 6275 following ns-3 coding styles;

-a reviewed patch, fixing the IPv6 support issue in LTE;

-proper documentation and tests for the above-mentioned components.

=== Plan: ===

==== May 4 – May 29 (Before the official coding time): ====

-Familiarize myself completely with MIPv6, LTE (the IPv4 part), and the respective interactions.

-Study of the customized files of ns-3 lte and internet modules

-Familiarize myself with the ns-3 coding styles

During this period I will remain in constant touch with my mentor and the ns-3 community. I will remain active on IRC and Mailing lists to discuss and finalize on the modifications (if any) that needs to be on existing models and design of new module (if needed to fit cleanly with ns-3)

Thus with the help of my mentor I will become absolutely clear about my future goals, the final MIPv6 implementation that need to be done as well as the approach that I will follow to support IPv6 in lte model.

==== May 30 – June 26 (Official coding period starts): ====

-Refactor previous MIPv6 headers to RFC compliance header files

-Refactor all the classes to implement the corresponding header file functions

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the newly implemented MIPv6 module in various testing scenarios. The testing will be done with the systems having Wi-Fi and WiMAX link layer technology

-Sending the code for code review to the ns-3 team

After this stage, the standard ns-3 code revision can be started for the MIPv6 code part. Any change requested by the reviewers will be carried out in parallel with the following activities.

==== June 27 – July 24: ====

-Define new or, modify existing header files and cc files in LTE module in such a way that LTE module remains backward compatible with IPv4

-Compiling and running the module and fixes the errors/bugs

-Testing the overall working of the LTE module

-Sending the code for code review to the ns-3 team

This will help in testing of the LTE module with IPv6 support for possible merge into the project main tree.

==== July 25 – August 21: ====

-Making further changes in the LTE module to support MIPv6 into it. Changes may be required in the other modules of ns-3 also.

-Testing the overall working in the testing scenarios having the combination of Wi-Fi and LTE

-Most of the time will be consumed for rigorous testing and bug fixes.

-Sending the code for code review to the ns-3 team

-Documentation updates.

= Weekly Reports =

=== May 30 - June 6 ===

1. Restructuring the MIPv6 code.

2. Testing the code in the multiple Mobile Node case

3. Changing the Home Agent functionality a little bit

4. Arise Tunnel Implementation Issue [how mobile node would use its home address for all of its data communication]

=== June 7 - June 13 ===

1. Resolved the issue of home address assignment to mobile node for all of its data communication. So, I have made some tricky callbacks in the L4 protocol a little bit. Now, traffic can be directed in both direction i.e. Mobile node to a web server and a web server to a mobile node

2. Also delete a lot of unnecessary files as well as lines in the code.

3. Tests have been done changing the location of different mobility entities. Almost all are successful. Those are included in "mipv6-test1-4.cc" in scratch of https://github.com/manoj24rana/MobileIPv6.

=== June 14 - June 20 ===

1. Done more tests

2. Add some more features such as defending home address and performing NS handling at HA as described in RFC 6275

3. Find an issue on RFC 6275 i.e. how to defend the mobile node's home address by home agent when it returns to its home network. Try to do something on the basis of ns-3 ipv6 implementation to resolve the issue.

=== June 21 - June 27 ===

1. Documentation on how my implementation differs from RFC 6275 as well as

2. Resolve the above issue

3. Sending the code for review.

=== June 28 - July 04 ===

1. Starting LTE IPv6 implementation part: understanding the end-to-end IPv4 part between UE and remote host, decoding it and discuss with my mentor for changing

2. Start writing code, at least one class modification

3. Test the change whether it is right.

=== July 05 - July 11 ===

1. Complete the modification in the lte module classes and also develop a small IPv6 dealing program to test

2. An issue arise i.e. Address Collision occurs at file: file=../src/internet/model/
ipv6-address-generator.cc, line=484". I am trying to resolve it.

3. Runs the previous IPv4 sample programs, which runs fine.

=== July 12 - July 18 ===

1. Resolve the IPv6 address collision issue in the LTE IPv6 support part.

2. I face another issue on handling multicast packets between UE sets and pgw i.e. those multicast packets are not passed between them as in the middle there is an enb.

3. Add the Sphinx documentation in the mipv6 module.

4. The Attributes and TraceSources are uploaded in mipv6 git.

=== July 19 - July 25 ===

1. Making some examples for the main mipv6 repo.

2. Add two tests in the main mipv6 repo.

3. mipv6 doc file further update.

4. Add and change tracesources and some functionalities in mipv6 model.

=== July 26 - August 1 ===

Finalize the MIPv6 code for review. I have added two nice tests replacing the previous tests, further update the mipv6 doc, trace sources, attributes, examples.
The codes are documented highly. Now the /doc/models/build/html dir contains the model documentation and the /doc/html creates doxygen for the mipv6 module.

=== August 2 - August 15 ===

1. Sent the MIPv6 code for review.

2. Solved LTE IPv6 packet sending issues.

3. Complete LTE IPv6 part, i.e. IPv6 packets are received and sent correctly.

4. Discuss with my mentor (Tommaso) elaborately about the next steps such that this implementation could be rebased in the main ns-3 dev quickly.

=== August 16 - August 22 ===

1. Update the LTE UE and PGW address assignment process in such a way that all IP addresses assigned by an EPC are derived from a base prefix (8 for IPv4 and 32 for IPv6) and each EPC holds a unique 16 bit IPv4 and 48 bit IPv6 subnet prefix to assign addresses to PGW and UEs. This address assignment process is made by keeping in mind the issues stated in https://www.nsnam.org/bugzilla/show_bug.cgi?id=1745 and https://groups.google.com/forum/#!topic/ns-3-users/Tc3IKky1OKo. So, now address duplication would not happen in case of more than one EPC as well as any time we could assign addresses without initializing the address helper. Also, user is given the flexibility to reassign the base 8 or, 32 bit address prefix at any time.

2. The LTE module is updated by IPv6 tests, documentation and examples. So, now the sample program is running and users can use them.

=== August 23 - August 29 ===

1. Submit the Google Work Product.

2. Send the LTE Code for review.

3. Try to run the MIPv6 over LTE.

= Final Report for Google =

=== Installation and Running the Work Product ===

1. Depending on your OS, install the ns-3 Prerequisites from this link: https://www.nsnam.org/wiki/Installation#Prerequisites.

2. Download the code from this repository: https://github.com/manoj24rana/GSoC17-ns-3.25-lte-mipv6 and extract it.

3. Make sure that you have installed all the perquisites to install ns-3.25.

4. Run the following commands in your cmd prompt to install it:

$ cd The_Project_Folder

$ cd ns-3.25

$ ./waf -d debug --enable-examples --enable-tests configure

$ ./waf

5. Running MIPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running MIPv6: mipv6-multiple.cc, mipv6-single.cc and mipv6-wifi-wimax.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run mipv6-multiple --vis

This will open a visualizer to see the output and the packet transmission in the background cmd.

6. Running LTE IPv6 sample

Hold on the same directory (i.e. /ns-3.25). There are three samples for running LTE IPv6: lena-ipv6-ue-rh.cc, lena-ipv6-ue-ue.cc and lena-ipv6-addr-conf.cc. You could simply run one of the sample just by typing the following:

$ ./waf --run lena-ipv6-ue-ue --vis

GSOC2017MobileIp

2017-08-27T13:19:05Z

Mkrana: /* opedwknfk */

GSOC2017MobileIp

2017-08-27T13:15:35Z

Mkrana: /* Weekly Reports */

GSOC2009WimaxUplinkScheduler

2017-08-27T13:08:17Z

Mkrana: /* General */

{{TOC}}

= General =
The ns-3 WiMAX module lacks the implementation of a more sophisticated uplink scheduler for QoS provisioning. The main goal of this project is to port the uplink scheduler implemented in the ns-2 WiMAX module developed by the Computer Networks Laboratory [http://www.lrc.ic.unicamp.br/wimax_ns2/] at University of Campinas to the ns-3 WiMAX module.

The second goal of this project is to implement propagation and error models to allow the simulation of more realistic scenarios.

= Project Background =
To support multimedia applications, the IEEE 802.16 standard defines five types of service flows (UGS, ertPs, rtPS, nrtPS and BE), each with different QoS requirements. However, the scheduling mechanism is left to be defined by proprietary implementations. Many scheduling algorithms for the IEEE 802.16 standard have been proposed in the literature, and one of them, proposed in [http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4411386], is implemented in the WiMAX module [http://linkinghub.elsevier.com/retrieve/pii/S1569190X08000920] developed for the ns-2 by the Computer Networks Laboratory (LRC - [http://www.lrc.ic.unicamp.br/wimax_ns2/]) at University of Campinas. The ns-3 WiMAX module implements a FCFS scheduler and, therefore, it lacks the implementation of a more sophisticated scheduler for QoS provision. The scheduler is responsible by the resource allocation and, consequently, is fundamental for the QoS provision. While the downlink scheduling requires one scheduler in the base station, uplink scheduling needs two components, one in the base station and one in the subscriber station. The base station uplink scheduler allocates bandwidth to subscriber stations and the subscriber station scheduler defines which packets will be sent in the received grants.

In this project, a more sophisticated uplink scheduler to support the QoS requirements of multimedia applications will be implemented. The recent WiMAX module for ns-2 developed by LRC[http://linkinghub.elsevier.com/retrieve/pii/S1569190X08000920] supports bandwidth allocation and scheduling services. The uplink and the downlink scheduler developed by LRC will be ported to the ns-3 WiMAX module.

As secondary goals, propagation and error model for ns-3 will be implemented. These models can bring more realism to the module, with throughput and error rate closer to reality. Theses models may reflect the sub-urban environment of WiMAX networks.

= Approach =

== Primary goal ==

* '''To port the uplink scheduler developed by LRC to the ns-3:'''

The uplink scheduler developed by LRC will be ported to ns-3. The existing scheduler uses three queues, which are the low priority queue, the intermediate queue and the high priority queue. The scheduler servers the queues in strict priority order. UGS grants are stored in high priority queue. nrtPS and rtPS bandwidth requests are stored in the intermediate queue, but they can migrate to the high priority queue to have their QoS requirements satisfied. And the low priority queue stores the bandwidth requests of the BE service flow. In this project, I will port the uplink scheduler developed by LRC to ns-3.

To feed the queues I will need to access some information in the bandwidth request messages, such as which connection has sent the request, how much bandwidth it is requesting, and with which type of service it is associated. Moreover, I will have to learn how to include the scheduling agenda in the UL-MAP message, which is transmitted by the base station to the subscriber stations at the beginning of each frame.

According to [3], the bandwidth requests and the UL-MAP transmission is already implemented. So my work will consist in getting information from the bandwidth request messages for the scheduling process and sending the scheduling result through the UL-MAP messages. The FCFS scheduler implemented in the ns-3 WiMAX module will be replaced by the one implemented in [1].

At the ns-3 WiMAX module, the uplink scheduler is implemented in the UplinkScheduler::Schedule() and in the UplinkScheduler::ServiceUnsolicitedGrants methods. So, the scheduler code implemented in [1] will be ported to these methods. The information required to feed the scheduler queues will be provided by the bandwidth manager of the ns-3 module through the BandwidthManager::ProcessBandwidthRequest method. The scheduling result will be included in the UL-MAP through the UplinkScheduler::AddUplinkAllocation, which is already implemented.

* '''Tests and Validation:'''

To be sure that the implemented scheduler is providing the requested QoS, I will run several validation tests for different scenarios and verify if the scheduler can provide fair bandwidth sharing among flows in the same service level. Moreover, I will verify whether the scheduler provides the maximum delay requirement for UGS and rtPS connections and the minimum rate requirement for rtPS and nrtPS connections as well as whether the BE traffic is not being starved. By simulating scenarios with different service levels and ranging the number of nodes, it will be possible to check whether the scheduler is providing the expected QoS.

To get a stable module, I intend to run many tests, white and black box tests. The current ns-3 regression test also must pass.

== Secondary goals ==
* '''Propagation and error models implementation:'''

In order to archive a more realist simulator, I propose to implement propagation and error models for ns-3. The propagation models appropriated for WiMAX sub-urbans environments are SUI, COST231 and TU-6. AWGN noise can be implemented and it is possible to find the SNR (Signal to Noise Ratio). With an error model, like YANS (Yet Another Network Simulator), we find the BER/PER and a packet is dropped according to this PER value. I will implement SUI and COST231 model for propagation model, AWGN for noise model and YANS for error model. This features must be easy to change and must be configurable by C++ script.

I will implement a new class, for example SUIPropagationLossModel. The models will be connected and will be chose at WiMAX Channel. The error model will be connected to WiMAX PHY. It will be necessary severals modifications at WiMAX PHY and WiMAX Channel in order to support these models.

To validate these models, I will compare the results to theoretical values and also with other results from literature.

* '''ertPS service implementation:'''

The current WiMAX module for ns-3 is compliant with the IEEE 802.16-2004 standard and it does not include ertPS service flow specified in the IEEE 802.16-2005 standard, which is an amendment to the IEEE 802.16-2004 standard. I will add this new service flow to the ns-3 module and adapt the scheduling mechanism for such service.

= Schedule =

=== Uplink Scheduler ===

* Plan and implement simulation scripts. (OK)
* Recover QoS information and bandwidth request information. (OK)
* Plan queue struct. (OK)
* Implement priotity queues. (OK)
* Schedule jobs of queues. (OK)
* Implement method to garantee delay requeriments. (OK)
* Implement method to garantee bandwidth requeriments.
* Implement simulation scripts to validate scheduler.

=== Propagation model ===

* Implementation of sui-propagation-loss-model/cost231-propagation-loss-model.
* Implementation of Noise class.
* Adaptation of yans error model with correct params for WiMAX PHY layer.
* Implement simulation scripts to validate error model.

=== ertPS flow ===

* Implementation of ertPS flow.
* Adaptation of scheduler to suport ertPS flow.
* Implement simulation scripts to validate ertPS flow and scheduler.



[[Category:GSoC]]

GSOC2017MobileIp

2017-08-27T12:53:33Z

Mkrana: /* August 16 - August 22 */

GSOC2017MobileIp

2017-08-17T09:08:25Z

Mkrana: /* August 2 - August 15 */