Route Optimization via RSSI APPs in Indoor Proxy Mobile IPv6 Test-bed

: Traditionally IP mobility support mechanisms, Mobile IPv4 or Mobile IPv6 are based on the host-based solution to keep on going sessions despite the movement. The current trend is towards networks-based solutions where mobility support is based on network operation. Proxy Mobile IPv6 (PMIPv6) has been developed by the Internet Engineering Task Force (IETF) as a network-based mobility management protocol. The development is aimed to guarantee and support mobility for IP devices or called as Mobile Node (MN) without the MN involving in any IP layer mobility related to signaling as stated in RFC5213. PMIPv6 in RFC5213 address the needed to enable Localized Routing (LR) but it not specify a complete procedure to establish Route Optimization (RO). Data packets belong to MN need to travel to Local Mobility Anchor (LMA) via bidirectional tunnel between Mobile Access Gateway (MAG) and LMA. This result to long end to end delay. This un-optimized route result in increasing signaling data delay, huge handover latency, large transport cost and many more. Therefore, it important to optimized the data path so that the data destined to MN will be traverse using the shorter path or directly change traffic tunnel between MAG. As for this, the aims of this study are to reduce the handover latency and optimized data route by the illustration of development the PMIPv6 test-bed with implementation of RO via RSSI APPs. Several experiment will be discuss to see the performance of RO algorithm via RSSI APPs with non-optimized RO.


INTRODUCTION
Internet Engineering Task Force (IETF) has designed a standard communications protocol named as Mobile IP or IP mobility to allow Mobile Node (MN) to move around from one network to another network but still maintain their permanent IP address.As described in IETF (Perkins, 2010) was a Mobile IP for IPv4 addresses while Mobile IPv6 (MIPv6) protocol was designed by IETF to support mobility implementation for the next IP generation of IPv6 (Johnson et al., 2004).
MIPv4 allowed MN to move to foreign network without the need for changing IP address but than MIPv6 was introduce to take over and exchange the IPv4 protocol in future.MIPv6 provides MN with a permanent address set by the Home Agent (HA) which acts as an identifier and a temporary Care-of-Address (CoA) used as a locator.Figure 1 shows mobile IP routing flow for MIPv6 protocol.Figure 1 shows that after MN sends Binding Update (BU) to HA, all traffic destined to the MN will be encapsulated in 'ipv6-to-ipv6' tunnel and send to the CoA of MN.
Although MIPv6 enable a MN to move but this ability is still not sufficient for true mobility as MIPv6 requires the MN to modify its client functionality in the IPv6 stack.Enabling efficient handover is an additional and critical requirement thus IETF again introduces new protocol to tackle the issues occur in MIPv6.The new protocol known as Proxy Mobile IPv6 (PMIPv6).
The main difference between PMIPv6 and MIPv6 is that MIPv6 is a 'host-based' approach while PMIPv6 is a 'network-based' approach.Network-based mobility means that MN does not participate in the exchange of signaling messages to process the mobility.Table 1 shows the differences between MIPv6 and PMIPv6.
PMIPv6 that specified in Gundavelli et al. (2008) is a network based mobility management protocol for localized domain which actively standardized by IETF.PMIPv6 developed to relocate mobility procedures from mobile devices to network components to support in IP networks.The main idea of PMIPv6 is not relaying on mobility function or configuration present in MN which mean that the PMIPv6 provide mobility to IP devices without their involvement in any IP mobility related to signaling.Therefore, PMIPv6 was considered to be the solution for the future all-IP wireless network.

Reduction in handover-related signaling overhead:
The handover-related signaling overhead can be reduced in PMIPv6 since it avoids tunneling overhead over the air as well as the remote Binding Updates either to the HA or to the Correspondent Node (CN).
Location privacy: Keeping the Mobile Node's Home Address (MN-HoA) unchanged over the PMIPv6 domain dramatically reduces the chance that the attacker can deduce the precise location of the mobile node.
There are two main entities in PMIPv6.Local Mobility Anchor (LMA) and Mobile Access Gateway (MAG).The function of LMA is to act as the persistent HA for MN and as the topological anchor point for MN prefix assignments.LMA also function as default multicast upstream for the corresponding MAG which manages the links to maintain the state of MN.
LMA is responsible to detect MN movements and change of attachment.Packets sent to and received from MN are routed via tunnels between LMA and the corresponding MAG.
Others function of LMA is to maintain a collection of host route and their associated mobility management domain under its control while MAG is a functional network element that terminates a specific edge link and tracks mobile node IP-layer mobility between edge links.MAG performs the mobility-related signaling on behalf of MN which is attached to it.MAG acts as an Access Router for MN, which is the first-hop router in the Localized Mobility Management (LMM).
The PMIPv6 describes a mobility management solution without a MN's participation in mobility management related to signaling process (Gundavelli et al., 2008;Sangjin et al., 2010;Kang-Won et al., 2010).The signaling flow starts when a MN enters a PMIPv6 domain and MN attaches to an access link provided by a MAG.
MAG on that access link performs the access authentication process which it identifies MN, the LMA's address and other configuration parameters.To update the LMA about the current location of MN, MAG sends Proxy Binding Update (PBU) to the LMA which also contain MAG address with identity of the MN.
Upon receiving this request, the LMA allocates MN's home network prefix and sends back to the MAG as Proxy Binding Acknowledgement.It also creates the Binding Cache entry and sets up its endpoint of the bidirectional tunnel to the MAG.While MAG sets up its endpoint of bi-directional tunnel to the LMA, it also sets up the forwarding channel for MN's traffic.MAG then sends Router Advertisement messages to MN on access link including the prefix allocates to MN.
Upon receiving the Router Advertisement messages on the access link, MN attempts to configure an address using interface either stateful or stateless address configuration modes.After obtaining the initial address configuration in PMIPv6 domain, if MN moves, the MAG updates the location of the MN and will signal the LMA and advertises the same prefix to MN. MN keeps the address configured when it first enter the LMA domain.This means that MAG configured the same link local address for specific MN.
As in Table 1, we can see that no Localized Routing in PMIPv6 (Gundavelli et al., 2008) protocol.As for this LR is an important feature needed in PMIPv6.The function of this localized routing is to allow traffic data to take a shorter path when being delivered from source to destination (Gundavelli et al., 2008;Rasem et al., 2012).This function result a lower latency especially for real time data (Rasem et al., 2012;Jun and Xiaoming, 2008).
PMIPv6 cannot directly apply the Route Optimization (RO) in MIPv6 as MN is not involved in mobility signaling thus it cannot perform signaling to set up a RO (Liebsch, 2010).In PMIPv6, data packets have to always go through the LMA even if the CN and MN sit on the same network.Gundavelli et al. (2008) PMIPv6 protocol does not fully specify the procedure to establish such localization routing state.The problem specified in Liebsch (2010) which have several scenarios to be considered.
As of all these concern, the aims of this project is to reduce the handover latency without terminate or interrupt current on-going session by optimized the data route or path.This done by development of Route Optimization via RSSI APPs which will be discuss farther in this study.

LITERATURE REVIEW
Over the past few years, there has been a huge interest in PMIPv6 research area after it was proposed to overcome the long registration delay problem.With PMIPv6, it can avoid tunneling overhead over the air and support the hosts without any involvement in the mobility management side.
Several related research has been proposed in this field such as in Daniel (2012).Paper (Daniel, 2012) presented an experimental evaluation on PMIPv6 under different implementation configurations and they evaluated the impact on the performances on PMIPv6 real test-bed.Daniel (2012) implement PMIPv6 test-bed under Linux Ubuntu 7.10 vanilla, while the kernel used is version 2.6.20.Daniel (2012) 1) hub or router.
The three computers are needed to be setup as LMA, MAG1 and MAG2 while notebooks are represent and acted as MN and CN.The hub or router is needed to work as interfaces that connect LMA, MAG1 and MAG2.AP will acted as AP for MAG1 and MAG2 as well.
d APs is the distance between AP1 and AP2.Communication or handover process are different and vary when d APs change.An experimental are done with different d APs to see the correlation between distance and handover latency.
The flow and step to build and develop this PMIPv6 test-bed started with installation of Linux Ubuntu 10.04 LTS to all computers and notebooks in the network.After that an update and system upgrade should be taken to ensure that all system are up to date and parallel all the system specification.
The next important step is the kernel configuration.All linux has their own kernel setting.To allow PMIPv6 features, several setting needed to be change and modified as well.Same goes to the IPv6 addresses setting in Linux, some files and coding need to be modified so that the system allow the usage of IPv6 addresses.
All the steps and flows above are done to all computers and notebooks means to LMA, MAGs, MN and CN devices but than, only computers (LMA and MAGs) will be configure and installed with OAI PMIPv6 software as MN and CN did not require any software modification.After all the steps taken, next flow is to modified and configure the APs system.This is important because the APs should be run in masquering mode or otherwise the test-bed will not succesfully run.Finally, after all the setup been made, the system can be run successfully.

Software and hardware requirement:
The hardware specification for this PMIPv6 test-bed project are listed in Table 3. Specification shows all the IP address for every components in the PMIPv6 test-bed and their hardware details.
Hardware needed for LMA, MAG, MN and CN did not require specific type of processor, RAM, type of devices (computer or notebook) and more.But, for LMA and MAGs, the hardware require should use computer as it need more than two Ethernet card to be used to connect to AP, MN or CN.
The type of AP that used should be an AP that can be configure or modified their setting and program because the AP should be work on masquering mode to fulfill the PMIPv6 test-bed.In this project, Cisco Aironet 1200 Series AP are used which can be configure and modified to be used in masquering mode.
Several software used to build up this PMIPv6 testbed project.The main software needed is Linux Open Source (OS) for the base system.The Linux type used in this work is Ubuntu 10.04 LTS that chosen to be used in all components (LMA, MAG1, MAG2, MN and CN) in this PMIPv6 test-bed.
As Linux was chosen to be as the platform system, the next important thing to look down is the kernel version for the Linux.In this project, the kernel version used is 2.6.32.59+drm33.24which a modification kernel from kernel version 2.6.32.
To setup the PMIPv6 environment system, Open Air Interfaces software version 0.4.1 are used to be installed and configure in LMA, MAG1 and MAG2 devices while MN and CN did not need any modification as the key properties for PMIPv6 technology proposed is that no client software is required.Therefore CN and MN is a single device without any settings needed to be changed in them.

Kernel setup and installation:
As mention previously, kernel version used in this PMIPv6 test-bed is 2.6.32.15+drm.33.24.This kernel is modified version from kernel version 2.6.32.The kernel needed to enable several features to support PMIPv6 environment to be use lists here: After modified the kernel, several packages needed to be installed to fully run this PMIPv6 test-bed project.

OAI
PMIPv6 open source (http://www.openairinterface.org):As mention in previous section, the main software used in this PMIPv6 test-bed is OAI PMIPv6 software version 0.4.1.This software only installed and configure in LMA and MAGs devices.Installation and configuration for LMA and MAG are different base on their needs and functions.
LMA setup: Modification and reconfiguration on the LMA device are needed to make the test-bed function as their requirement.First of all, FreeRadius Client and FreeRadius Server are needed to be installed and configured.The version that used in this test-bed is FreeRadius Client version 1.1.6and FreeRadius Server version 2.1.12.This software is a modified version by OAI from freeradius.org.
Next step for installation and configuration OAI PMIPv6 software on LMA device are copying three configuration files to FreeRadius Server.This step are important in order to correctly connect to the clients.This three files are 'users', 'radius.conf'and 'clients' files.In 'users' file, all MN MAC Address needed to be edited follow the MAC Address for MN devices that used in the test-bed.
After all steps taken, OAI PMIPv6 software are needed to be recompile.
MAG setup: Such as like LMA, All MAGs also needed to follow several steps to installed and configured OAI PMIPv6 software.All MAGs devices needed to be installed with FreeRadius Client.FreeRadius Libraries needed to be written in 'ld.so.conf' file while FreeRadius Server need to be written in 'hosts' file.After that step for installing and configuring SYSLOG Server take over.In this step, the 'local7.info'code will be written in 'syslog.conf'file.
Upon successful of rewrite the 'syslog.conf'file, 'pmip_syslof.conf'file needed to be created.In this file, the SYSLOGD should be equal to '-r'.
After that, 'radius6server' for localhost need to be exist in 'radiusclient.conf'file in 'authserver' and 'acctserver' part.Final step will be the step of recompiling OAI PMIPv6 software to be successfully configured to be used later.
Access point cisco aironet 1200: Access Point (AP) that used in this project is Cisco Aironet 1200 Series, as mention in previous section.This AP needed to be configured to enable their SYSLOG client and acted in masquering mode.This is because, the AP should be a separator for the MAG function that connected to it.
To configure the Cisco Aironet 1200 AP, first open the internet explore page and enter the IP address of the AP into the web link space.New interface to setup the Cisco Aironet 1200 Series will be open.At the setup page, change the name of the AP to 'MAG1-AP' or 'MAG2-AP' as needed.After that, enable only the 'radio 0-802.11G' to make sure there is no another signal on other frequency that used the same named.
Go to Syslog facility and select 'local use 7'.After that, change the Server Name to specified MAG server (IP Address).Last step to successfully configure that AP is by changing the IP Address of the AP.After that step, the AP is ready to be used for the real PMIPv6 test-bed.

ROUTE OPTIMIZATION ALGORITHM
The Route Optimization (RO) is Using Multicasting Binding Cache approach to MAGs method, add on RSSI APPs and Prediction method.RSSI APPs is the APPs that been installed to the MN so that MN will keep sending Signal Strength of every APs of MAGs detected and sent to the LMA.
LMA is a Dynamic LMA which it will calculate and compare all the Signal Strength given by MN via RSSI APPs and keep update the MAGs with all the RSSI using Multicasting Binding Cache approach.Since the LMA is in the local domain, it can always multicast its binding cache to all the MAGs to keep update cache ahead before any operation (Handover, data communication, etc.) take happen.
The Prediction method will change the data path route automatically when MAGs detect AP-MAG1 = AP-MAG2 or AP-MAG1>AP-MAG2 for the first time follow to the topology.It's mean, before handover happen, the path route of data communication already change to the shorter path or known as Route Optimization (RO), without need to wait for the handover process to end to change the data path route.
The data travel to maximum path if there is no RO implementation.Data from CN will be sent to MAG1 to LMA, than back to MAG1 and lastly to MN (CN→MAG1→LMA→MAG1→MN), rather than with LR via RSSI APPs the data will be travel by shorter path which data from CN to MAG1 than direct to MN because they attach to the same MAG (CN→MAG1→MN).
While MN moving, it keep sending the signal strength of both MAGs (MAG1 and MAG2) to LMA so that LMA are up to date of the MN location.As LMA which always sending BU to MAGs using multiple binding cache approach to MAGs will keep update the caches to MAGs before any operation (handover) happen.
The prediction method will change the data path when MAGs detect the signal strength of AP-MAG1 equal to signal strength of AP-MAG2 or when AP-MAG1 higher than signal strength AP-MAG2 (AP-MAG1≥AP-MAG2).This mean, before handover happen, the data path already change to the shorter path, without need to wait for the handover process to end to change the path flow.The data flow with LR via RSSI APPs and without LR shows in Fig. 3.In Fig. 3, we can see that data paths flow is the black arrows and the red arrow is the deleted or reduction path.

RSSI APPs:
Received Signal Strength Indicator (RSSI) method as a basis in Location Tracking System is inexpensive and simple in implementation.RSSI technique also does not have a significant impact on local power consumption.There are other related definitions on RSSI discussed by IEEE 802.11 standard.RSSI is Radio Frequency (RF) energy measured by the circuitry on a wireless Network Interface Card (NIC).
RSSI is a circuit to measure the strength of an incoming signal.RSSI is a signal output which is proportional to the RF input power and a common unit for RSSI is dBm.The output signal is used to measure the RF signal strength on a specific channel and indicate the usage on that channel.Receiver sensitivity refers to the ability of the receiver to pick the weakest of signals.The higher receiver sensitivity, the better accuracy of the device to obtained RSSI measurement.
Discussions on circuits which measure the signal strength based on the output voltage were also made.RSSI is typically higher when the device is closer and it is directly proportional to the distance between device and the AP.For example, the RSSI detected decreases as device moves away from the AP.The further the device (receiver) is from the AP (transmitter), the greater the loss and thus a lower RSSI.
Theoretically, the indoor signal path loss obeys the Distance Power Law that is given in Eq. (1) (Ali et al., 2004): In this equation, P r is the received power, P r (d o ) is the received power at the reference distance d o and n is the path loss exponent that indicates the rate at which the path loss increases with distance.It depends on the surrounding and building type.And d o is the close-in reference distance (1 m) and d is the separation between the RF signal transmitter and receiver.
The term X σ is a zero mean Gaussian random variable with standard deviation σ.Equation ( 2) is modified to include Wall Attenuation Factor (WAF) (Ali et al., 2004).The modified distance power law is given as Eq. ( 2) (Ali et al., 2004), where T is number of walls between transmitter and receiver: Predictions: Prediction process happen in LMA.LMA will evaluated and compare every signal strength of MAGs send by MN via RSSI APPs.This prediction approach needed so that the RO will change the data path route while handover process happen.This result in reducing the delay of data paths between CN and MN while handover because the RO already change the path to new shorter path base on topology.
As in this study, the prediction will take note the signal strength between AP-MAG1 and AP-MAG2.When RSSI for AP-MAG1 = AP-MAG2 or AP-MAG1>AP-MAG2 for first time, the LR will be prepare to be change to the CN→MAG1→ MAG2→MN while handover rather than data paths without RO which data travel is CN→MAG1→ LMA→MAG2→MN.

RESULTS AND DISCUSSION
The aims of this project is to develop PMIPv6 testbed with implementation of LR via RSSI APPs.As for this, experimental to check the handover latency and LR performances has done.The topology for this experiment shows in Fig. 4. The scenario start when CN and MN connected to the same MAG (MAG1).In a time, MN is moving and handoff to foreign MAG (MAG2).
The experiment are looking at the delay and latency of packet data destined to MN from CN with RO via RSSI APPs and without LR implementation.The data travel to maximum path if there is no LR implementation.Data from CN will be sent to MAG1 to LMA, than back to MAG1 and lastly to MN (CN→MAG1→LMA→MAG1→MN), rather than with LR via RSSI APPs the data will be travel by shorter path which data from CN to MAG1 than direct to MN because they attach to the same MAG (CN→ MAG1→MN).
While MN moving, it keep sending the signal strength of both MAGs (MAG1 and MAG2) to LMA so that LMA are up to date of the MN location.As LMA which always sending BU to MAGs using multiple The prediction method will change the data path when MAGs detect the signal strength of AP-MAG1 equal to signal strength of AP-MAG2 or when AP-MAG1 higher than signal strength AP-MAG2 (AP-MAG1≥AP-MAG2).This mean, before handover happen, the data path already change to the shorter path, without need to wait for the handover process to end to change the path flow.The data flow with LR via RSSI APPs and without LR shows in Fig. 5.
To allow IPv6 addresses to be used in the system, the kernel setting should enable the IPv6.As mention in previous section, the kernel 2.6.32 should be setup to meet IPv6 forwarding.Figure 6 shows that the LMA system has been successfully enabled in the PMIPv6.To see this result, the LMA need to be run and the script in Fig. 6 will be seen.
Final result to prove that this PMIPv6 test-bed project is successfully developed is by making communication between MN and CN. Figure 7 shows that MN can communicate with CN with 'ping' procedure.
Experiment has done for topology shown in Fig. 4 with two scenarios which d APs 5 and 10 m.The experiment has done for handover without LR and handover with LR to check and compare the handover latency.As to mention again, to enable multimedia communication (seamless multimedia handover) while handover happen, the handover latency should be less than 50 msec.
Figure 8 shows the handover latency versus packets send for scenario 1. Scenario 1 is the scenario where distance between AP-MAGs is 5 m (d APs = 5 m).We can see that the handover latency without LR is more than 50 msec while data packets send more than 30 packets (64 bytes every packets).As for this, it cannot be used for seamless multimedia handover.When the LR algorithm (RSSI APPs LR with Dynamic LMA for PMIPv6) used, the handover latency will be minimize until less than 10 msec for 10 to 100 packets send.This conclude that the LR algorithm can be used for seamless multimedia handover as it reduce the handover delay.
While Fig. 9 shows the handover latency versus packets send for scenario 2. Scenario 2 is the scenario where distance between AP-MAGs is 10 m (d APs = 10 m).
We can see that the handover latency without LR is more than 50 msec while data packets send more than 20 packets (64 bytes every packets).As for this, it cannot be used for seamless multimedia handover.When the LR algorithm (RSSI APPs LR with Dynamic LMA for PMIPv6) used, the handover latency will be minimise until less than 20 msec for 10 to 100 packets send.This conclude that the LR algorithm can be used for seamless multimedia handover as it reduce the handover delay.The delay is higher than scenario 1 because when the dAPs is large, the delay time will increase.This result follow the work done by Nur Haliza (2010) and Wahab et al. (2012) which if distance between APs is large than more error and delay will be occur.

Fig. 3 :
Fig. 3: Data flow with RO via RSSI APPs and without RO

Fig. 6 :
Fig. 6: Successfully enable PMIPv6 features binding cache approach to MAGs will keep update the caches to MAGs before any operation (handover) happen.The prediction method will change the data path when MAGs detect the signal strength of AP-MAG1 equal to signal strength of AP-MAG2 or when AP-MAG1 higher than signal strength AP-MAG2 (AP-MAG1≥AP-MAG2).This mean, before handover happen, the data path already change to the shorter path, without need to wait for the handover process to end to change the path flow.The data flow with LR via RSSI APPs and without LR shows in Fig.5.To allow IPv6 addresses to be used in the system, the kernel setting should enable the IPv6.As mention in previous section, the kernel 2.6.32 should be setup to meet IPv6 forwarding.Figure6shows that the LMA system has been successfully enabled in the PMIPv6.To see this result, the LMA need to be run and the script in Fig.6will be seen.

Table 1 :
MIPv6 and PMIPv6 differences Handover performance optimization: PMIPv6 can reduce latency in IP handovers by limiting the mobility management within the PMIPv6 domain.Therefore, it can largely avoid remote service which not only cause long service delays but consume more network resources.
reused MIPv6 for Linux version 2.0.2.Research journal in Iapichino and Bonnet (2010) also presented the real PMIPv6 test-bed implementation but it focus on Network Mobility (NEMO).Iapichino and Bonnet (2010) propoed a NEMO supporting scheme, which supports MN's mobility between PMIPv6 networks and mobile networks as well as the basic NEMO.Journal in Iapichino and Bonnet (2010) used PMIPv6 daemon which they implemented based on the MPL (2.0.2).The software they used to develop their PMIPv6 NEMO network is Linux Debian with kernel version 2.6.20. is 2.6.31.Software that used in Hyo-Beom et al. (2010) is OpenWRT Kamikaze 7.09.Linksys WRT54GL v1.1 is used as the Access Point in Hyo-Beom et al. (2010).Hyo-Beom et al. (2010) only compare their system performance result with previous work.Another related research is Rasem et al. (2012) where looking at improvement localized routing handover.Rasem et al. (2012) is a project which run the simulation without test-bed development.Proxy Mobile IPv6 is the only network-based mobility management protocol standardized by IETF.There are two models deployed for PMIPv6 and they are Flat Domain Model and Domain Chaining.Table 2 shows the difference in architecture between Flat Domain Model and Domain Chaining.In this PMIPv6 test-bed project, the model used is Flat Domain Model.The PMIPv6 test-bed architecture for this work is shown in Fig. 2. In this architecture, we can see that the PMIPv6 test-bed consists of several entities which (3) computers, (2) notebooks, (2) Access Points (AP) and ( Hyo-Beom et al. (2010)focused only hardware or real test-bed.Their test-bed OS used Ubuntu 9.04 and the kernel

Table 2 :
Flat domain model and domain chaining differences Flat domain modelDomain chaining Fig. 2: Architecture for mobile IPv6