Framework for Seamless Roaming, Handoff and QoS Mapping in Next Generation Wireless Networks - Phase III

------------------------------------------------------------------------------------------------------------------------

                    

Faculty Members: Dr. Nirmala Shenoy and Prof. Bruce Hartpence

Cisco Champion: Rafael Mantilla, Montalvo Ph. D.

ITS Technical Support: Andrew Elble

Period of Activity: Spring Quarter 2004

-------------------------------------------------------------------------------------------------------------------------    

Activities for phase III

  1. Extend the Opnet model – Cellular to WLAN roaming to study the handling of voice calls during roaming and implement Bicasting
  2. Implement code at layer 2, which will facilitate a quick predictive handoff. This code will be used later on to initiate a layer 3 handoff based on MobileIP.
  3. Develop an AAA server with a Profile server which will store the user / service profile for WLAN users (similar to HLR/VLR of cellular users) on MobileIPv4
  4. To study the mechanisms and delays at layer 2 and layer 3 during handoff using MobileIPv6 over the IPV6 test bed using Linux routers
  5. QoS mapping and negotiation for WLAN to cellular (UMTS) roaming with IPv4 and IPv6 as the core networ on the MobileIPv4 test bed

---------------------------------------------------------------------------------------------------------

 

Activity 1: Extend the Opnet model that was used for Cellular- WLAN roaming studies to implement bicasting as part of the framework and study the handling of voice calls

The bicasting model was implemented. The opnet model used is shown below. The node called the HIMA (Hierarchical Intersystem Mobility Agent) implements bicasting, handles predictive handoff, performs message translation and is also aproxy HLR. At the HIMA we modelled a remote server that generates data packets for the mobile user. The remote server gets triggered when the mobile starts a data session.

The AAA/ Profile servers were implemented.

The predictive handoff scheme used earlier was modified to suit the framework. The predictive handoff message flow (with the HIMA) is shown in the figure below. The handoff performance was evaluated with the framework and without the framework. Some comparative results are shown below.

The wasted capacity in terms of processing time was estimated for redirecting (without framework)the packets and processing them for bicasting (with framework). The comparison graphs are given below

Performance estimates for VoIP were made on the studies conducted for handling data. Data redirection will not be effective for voice packets, hence without the HIMA, handoff of voice calls resulted in information loss. With the framework, no information loss was percieved at the user.

Implementing of the framework, still requires a predictive handoff process. Whereas without the framework, the handoff effects manifest as reduced throughtput for data calls and lost information for voice calls, in the case of handoff with the framework, the reduction in data throughput is reduced and there is no information loss for voice calls.

     Punita Mishra



 

Voice Peformance:

Offered Load
Number of Voice packets lost
95%
55
90%
85%
 
80%

---------------------------------------------------------------------------------------------------------

   Namgyal Dolker

Activity 2: To conduct performance studies on the MobileIPv4 test bed to analyze the layer 2 and layer 3 delays and the interaction of the messsages at these layers. The source codes for the WLAN driver and MobileIPv4 client will be studied and suitably modified to incorporate the framework features.

In the IPv4 test bed:

Analysis of the scenario - different IP subnets but same SSID , no WEP key, same channel. The roaming was analyzed using a mobile node running windows or linux. Birdstep software was used in the windows system. For the Linux systems, mobileIP dynamics freeware was used. With same SSID, the delays were

Analysis of the scenario - different IP subnets different SSIDs , no WEP key, same channel. This was analyzed for the mobile node running windows. Linux systems do not allow the support of a second standby AP with a different SSID.

However the handoff delays as analysed were primarily due the layer 2 handoff, with different SSIDs. Moreover with the same SSID (different IP subnets) and with the birdstep running on the windows based mobile node the handoff times varied erratically, whereas the Linux based systems exhibited a more stable operation. Hence it was decided to use Linux based systems for further tests.

However in Linux based systems, it was not possible to change to an AP with a different SSID, be it wihtin the same IP subnet or different IP subnets. This was one of the problems targeted.

The second problem noticed was the drop in throughput as the user roamed far away from one AP. The signal strength threshold normally is set at -72dbm for initiating a handoff. So that Mobile node did was not initiate a layer 2 hadoff till the threshold was reached, this led a to a drop in the throughput. An analysis of captures conducted using Linkferret revealed that numerous probe requests and responses were exchanged before the mobile attached to the new AP, which resulted in delaying the traffic flow to the mobile.

Based on the above study, it was decided to write code in Linux systems that would monitor the signal strength of the current AP, and then initiate a handoff at a specified threshold (set lesser than -72 dbm). This code would also look for a better AP and then associate/ authenticate with this new AP.

This code was written and tested both over the mobileIPv4 and MobileIP v6 test beds succesfully and reduced the layer 2 handoff considerably.

Focussing on MobileIPv6 networks. The delays currently experienced are due to layer 3 attachement process, where unless a Router Solicitaion was sent, the mobile node could not acquire a new IPv6 address and set up binding with the home network or the correspondent node.

The code written for speeding layer 2 handoff, will be used to speed up layer 3 handoff.

Below is given the modular approach to relate the layer 3 and layer 2 handoff process.

---------------------------------------------------------------------------------------------------------     

 

Activity 3:

Develop an AAA server which will also store the user / service profile for WLAN users (similar to HLR/VLR of cellular users). This is necessary to provide Quality of Service as per the user subscription. This is currently targeted to work in the MobileIPv4 test bed

  1. TACACS+ software is currently being used for the AAA server. This has been installed and tested for working with the MobileIP v4 test bed shown below
  2. A module to investigate the possibility of per user profile mapping and downloading from AAAH to AAAF in MobileIP environment was written.
  3. The module has been tested for storing the mobile user profile and is accessible for download, when the mobile node communicates with the home network.
  4. The Profile Mapping is an add-on module based on the patched Tacacs+ v9a from http://www.gazi.edu.tr/tacacs/. Additional codes are added in order to enable profile mapping mechanism such that a user profile could be mapped into the foreign network when a mobile device roams away from home to the foreign.
  5. The program is written in C with MySql (for database connection) and libconfuse (for config file parsing) support. It’s designed in such way that the modification to the original program is minimal.The following diagram shows the module structure and the relationship between each file:
    Travis Wu

---------------------------------------------------------------------------------------------------------

 

  Vishal Mankotia


Activity 4: To study the mechanisms at layer 2 and layer 3 during handoff using MobileIPv6 over IPV6 test bed using Linux routers from IPV6 freeware that is available. Study the mechanisms at layer 2 and layer 3 during handoff using MobileIPv6

The MobileIPv6 test bed was set up, with an ftp server acting as remote node. This node was also configured to act as a correspondent node and support MobileIPv6.

The following sceanrios were tested

Application
Remote Node
Roaming direction
UDP
CN off
Home->Foreign
UDP
CN off
Foreign->Home
UDP
CN on
Home->Foreign
UDP
CN on
Foreign->Home
TCP
CN off
Home->Foreign
TCP
CN off
Foreign->Home
TCP
CN on
Home->Foreign
TCP
CN on
Foreign->Home

The above experiments were then repeated with Iperf. Iperf is a freeware that allows for TCP or UDP sessions to be run at an Iperf client (the remote server). The Iperf Server runs at the receiving end -i.e. the mobile node in this case and collects statitics on packets lost, jitter and bandwidth. This was very helpful in assessing the performance degradation while roaming.

Each experiment was repeated five times to check for consistency.

During these experiments, the sequence of messages exchanged during a handoff for the different scenarios were analaysed. The sequences which contributed to delays in layer 2 and layer 2 handoff werre analaysed in detail. As a result of this study we are currently implementing in code a predictive handoff, which starts at layer 2 (WLAN drivers) and involves MobileIPv6.

The MobileIPv6 test bed used is shown below.

 

                         ---------------------------------------------------------------------------------------------------------     

 

John Sheftic

 


Activity 5: QoS mapping and negotiation for WLAN to cellular (UMTS) roaming with IPv4 and IPv6 as the core networ

On the MobileIPv4 test bed

  1. Study QoS offered by Cisco APs which implement 802.11e for the downstream side. The first set of experiments were codnucted within one subnet. The QoS was measured in terms of delay, jitter, packet loss and data rate.
  2. A software tool called Iperf was identified and this was used to at the remote server, to provide UDP and TCP traffic.
  3. The CWmax and CWmin were adjusted via the DSCP to give priority to selected traffic. The degradation in Qos was tested under load conditions.
  4. Change the setup so that APs communicate across the core network different IP subnets. Repeat the experiments above.