Difference between revisions of "GSOC2017MobileIp"

From Nsnam
Jump to: navigation, search
(Technical Approach)
(Technical Approach)
Line 20: Line 20:
  
 
= Technical Approach =
 
= 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:To do the restructuring complete, the following approaches will be performed:
+
* '''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:To do the restructuring complete, the following approaches will be performed:
1) Code refactoring: reorganizing internetstack, helper and header components of the MIPv6 module through modifying the internal functions, attributes and the callback variables.
+
  1) Code refactoring: reorganizing internetstack, helper and header components of the MIPv6 module through modifying the internal functions,  
2) 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.
+
  attributes and the callback variables.
3) 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.
+
  2) Code analysis: both static and dynamic analysis could be performed. The waf tool for code run, PyViz for visualization and tcpdump for pcap  
4) The code will be sent for the code review to the ns-3 team.
+
  tracing could be used.
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.  
+
  3) Functional tests: The functional test would be performed in three phase: handoff performance testing, data packet transmission testing and both.  
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).
+
  Use cases like multiple mobile nodes, multiple correspondent node, different mobility model for the mobile node as well as heterogeneous link layer  
Third, to ensure the code quality, the following testing approach could be used:
+
  technologies (Wi-Fi and WiMAX) 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.
+
  4) 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.
  
 
= Milestones and Deliverables =
 
= Milestones and Deliverables =

Revision as of 15:50, 14 May 2017

Main Page - Current Development - Developer FAQ - Tools - Related Projects - Project Ideas - Summer Projects

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

Return to GSoC 2017 Accepted Projects page.

Project overview

  • Project name: Mobile IPv6 Implementation with LTE support
  • 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: Link to be provided
  • Documentation: Link to be provided
  • About me: Insert short bio

Technical Approach

 1) Code refactoring: reorganizing internetstack, helper and header components of the MIPv6 module through modifying the internal functions, 
 attributes and the callback variables.
 2) 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.
 3) 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.
 4) 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.

Milestones and Deliverables