Multiple Backhaul Mobile Access Router: Design and Experimentation

Transcription

1 Multiple Backhaul Mobile Access Router: Design and Experimentation Yan Sun, Fangfei Chen and Thomas F. La Porta Networking and Security Research Center Department of Computer Science and Engineering The Pennsylvania State University, University Park, PA Abstract The Multiple Backhaul Mobile Access Router aims to provide high capacity and high performance Internet access for emerging mobile wireless applications. In this paper we describe the framework and implementation of a modular mobile access router system. A set of backhaul interface monitoring APIs are provided to support flexible handover policies. We present the experimental results to validate the performance of our mobile access router and illustrate tradeoffs when designing handover policies. 1 I. INTRODUCTION Mobile access routers allow groups of users to connect to the Internet and remain connected as the router moves. These routers are attractive for providing high capacity and high performance Internet access for a group of users in a mobile environment, for example on a train or bus. There are several existing and emerging wireless networks that support mobile applications. These networks include the widely deployed GPRS, UMTS, and CDMA cellular networks as well as WLAN (e.g., ) and emerging broadband Wimax networks. When these technologies are used to provide connectivity from the mobile access router to the Internet, we term them wireless backhaul. The trend is for a mobile access router to support multiple wireless backauls, each with a different wireless technology. This way, the mobile access router has a better chance of maintaining Internet connectivity as it moves. One major effort supporting these architectures is the NEMO protocol developed within the IETF [1]. NEMO is proposed to support network mobility which enables session continuity of a group users attached to a mobile access router. The protocol is an extension of Mobile IPv6. A new IETF draft [2] analyzes multihoming for network mobility. A similar problem has been explored considering clients with multiple wireless interfaces. For example, two different inter-working architectures have been proposed for WLAN- 3G interworking: tightly coupled and loosely coupled [3]. Figure 1 shows the loosely coupled architecture which separates the data path for WLAN access from 3G networks and connects to the 3G core network through the Internet. In contrast, in a tightly coupled architecture the WLAN access can be viewed as an alternative radio access network to the 3G network. We extend the loosely coupled architecture to the mobile access router. 1 The work was funded by National Science Foundation (NSF) grant CNS G Core Network Home Agent (HA) Fig. 1. Internet PDSN Internet SGSN Foreign Agent (FA) Foreign Agent (FA) CDMA BS UMTS BS Wimax AP WiFi AP Multiple Backhauls Mobile Access Router Multiple Backhaul Mobile Access Router System Architecture. Different handover policies have been proposed to improve the performance of vertical handovers [3] [4] [5]. Yet, there are still challenges in determining the relevant network parameters and effective handover decision models related to vertical handover in dynamic network environments. As such, interfaces that allow flexible policies for handover are essential. In this paper we focus on: describing the implementation of a modular mobile access router that supports multiple wireless backhauls using Mobile IP [6]; presenting common APIs that may be used by a network monitor to implement different backhaul switching policies; demonstrating performance measurements of handover policies we implemented to show the utility of the APIs and considerations to be taken when designing such policies; Our system is built on top of the workit Wireless Open Research KIT [7] provided by Alcatel-Lucent Bell Labs. The remainder of the paper is organized as follows. Section II presents the framework of the multiple backhaul mobile access router system. In Section III we demonstrate the details of the multiple backhaul access APIs that may be used by a network monitor. Section IV defines three network selection policies for vertical handover built using the API. Section V explores the performance of the system implementation for different vertical handover policies. Section VI describes the conclusions and future work. II. THE MULTIPLE BACKHAUL MOBILE ACCESS ROUTER Our mobile access router is built based on the loosely coupled architecture described above /08/$ IEEE 4543

2 When clients connect to the mobile access router for service, they receive an address from the router using DHCP and are authenticated using a RADIUS server. The addresses assigned to the clients are private addresses administered by the mobile access router. The mobile access router connects to the Internet through one of its backhauls. It provides the NAT service to the clients. The mobile access router manages mobility across wireless links of the same technology, and between technology using Mobile IP. It shields the clients from the handover. The mobile access router integrates the mobility functions in the access router on top of a multi-link virtual network interface driver to support dynamic backhaul monitoring and seamless handoff in addition to group mobility. Figure 2 shows the software framework of the mobile access router in three parts: a multi-link virtual interface driver implemented as a kernel module; the network monitor and mobility modules which direct the handover decisions and implement the handover across backhauls; the security and IP services module and client session database for internal user access. We implement Mobile IP [6] client functions on a virtual network interface which controls the multiple backhauls. This interface acts as a Mobile IP client to the network and is thus assigned a fixed Mobile IP Home Address. Because this address remains constant across handovers, end user sessions are preserved. The handover algorithms can exploit overlapped network coverage to avoid service disruption and packet loss. Our solution does not change the Mobile IP protocol and we require no upgrade to the Mobile IP Home Agent or Foreign Agent as is required by NEMO. The Mobile IP Home Agent and Foreign Agent are provided by the workit Wireless Open Research KIT [7]. Our mobile access router is implemented in Debian Linux. The kernel version supported is up to 2.6. The modular design approach provides flexible framework to allow scalability on different platforms. Below we first describe the implementation of the three main modules of the mobile access router. We then describe the processing flow for an inter-backaul handover and show a basic handover performance result. This motivates our study on wireless link parameters in Section III. A. Multi-link Virtual Interface Module The mobile access router is built on a multi-link virtual interface driver that is used by both the mobility module and access router module as described in the subsequent sections. The main benefit of using a virtual interface is that the higher layer modules, i.e., the mobility and access router modules, may be shielded from changes in backhaul. The virtual interface device driver provides device registration, initialization, transmission and reception. In addition to the standardized operations, a custom IOCTL command SIOCSWITCHBACKHAUL, is provided to the user to trigger the backhaul interface switching. Fig. 2. Access Router PostSQL Session DB Session Mgmt. Radius Web Server Server Security/Web Services DHCP Server Integrated Internal Access Point IF IP Services NAT/ Firewall Network Detection Network Monitor Mobility Client Mobility Multi-link Virtual IF Driver Mobility Host Radius Client Security Network Selection Multi-link Soft IF Multiple Backhauls IFs (Ethernet, , CDMA,etc.) Multi-link Virtual IF Multiple Backhaul Mobile Access Router Software Framework. B. Mobility Module The mobile access router is designed to support multiple backhauls and select the best interface dynamically to provide high quality connectivity. Mobile IP is used to manage handovers on the backhaul to support service continuity. We implement the Mobile IP Client functionalities as member functions of C++ class MipClient. We support RADIUS, challenge/response and NAI in the mobility module. A Multi-link Soft Interface class MIP VIF is designed to initialize the virtual interface and abstract the IOCTL operation invocations of the virtual interface driver. It also abstracts the link status information. MipClient class uses the MIP VIF class to interact with the virtual interface. MipClient class also updates the route/arp entries based on the virtual interface when a reply message is received from the agent. The network monitor is specifically designed to flexibly support new link quality parameters and network selection policies. An abstract link status class BHIface and several derived classes are designed for supported backhaul types. We study the link quality parameters in detail in Section III and use them in handover policies in Section IV. The network selection chooses the best interface based on different policy requirements. We provide a basic handover policy according to link connectivity as member functions of the classes for supported backhaul types. New functionalities can be added to support more complicated policies and decision models. The MipClient class interacts with the network monitor modules to trigger vertical handovers. C. Access Router Module The access router module serves as an access router for its clients. To simplify the system hierarchy we support Simple IP for clients that connect to the mobile router. They are assigned an address using DHCP and maintain this address for the duration of a session. A PostSQL on-disk database is used to store the client session state information and can provide a recovery capability on failure. Web-based user/password authentication is used to interact with Radius Server on the router. The NAT/firewall is designed to provision and dynamically insert the filtering rules on the virtual interface instead of a physical interface. The on-going client sessions are 4544

3 Network Detection Unit Network Selection Unit Handover Unit Handover Triggered Monitor Triggered Yes No New Backhaul Yes Add New Backhaul Select Best IF based on Policy Best IF == Current IF? No Successful Radius Authentication Successful MIP Reg. on new IF sequence number RRR R R Access IF Parameters Handle New IF Multi-link Soft Interface Switch Invocation Fig. 3. Handover Processing Flow. Handover End preserved when the backhaul switches since the virtual interface does not change and the per user filter rules are still valid. This is desirable compared with the approach in [3] which uses a packet filter library that installs per user packet filtering rules on the physical interface. D. Handover Processing Flow In this subsection we briefly describe the processing flow for a handover between backhauls. Please refer to Figure 3 for this discussion. This illustrates the processing flow and interaction between the network monitor module and mobility module to trigger a handover in the mobile access router. Assume internal users have already registered with the mobile access router, have received IP addresses and had their NAT filters installed. In this example, the handover occurs from backhaul type A to backhaul type B. Before the handover, packets from the client are received by the mobile access router, a NAT function is performed, and the packets are sent to the virtual interface. This interface transmits the packets out on interface A. If a router advertisement is received from a new backhaul network, the network monitor must decide if it should switch backhauls. Assume at some time an advertisement from backhaul network B is received and interface A becomes unavailable. This is detected by the network monitor. The network selection function determines that a handover to backhaul B must be performed. The Mobile IP client in the mobility module then sends a Mobile IP Registration message to the new FA. During the handover the packets from the internal users are still transmitted through the virtual interface which directs the traffic to the old backhaul A. The reply message from the new FA triggers the multi-link soft interface to interact with the multi-link virtual interface driver. The virtual interface driver changes the physical backhaul to interface B. At this time, packets received at the mobile access router from the client continue to be routed to the virtual interface via the NAT function, which then transmits them out interface B. E. Preliminary Handover Performance To determine the base performance of the system we perform a simple experiment using WLAN and ethernet as two backahuls from the mobile access router. Handovers are forced from the ethernet to the WLAN by disconnecting the ethernet cable. We transfer a large file from an internal ftp sever. We monitor the traffic using tcpdump for the the active data sessions :10 08:20 08:30 08:40 08:50 09:00 09:10 09:20 09:30 09:40 09:50 10:00 time Fig. 4. TCP Time Sequence Graph. TCP sequence number progression vs. time is used as the metric to evaluate the backhaul handover performance. The result is shown in Figure 4. This experiment results in the worst case handover latency because the monitor waits for the active backhaul link to break before initiating a backhaul change. The handover latency is approximately 12s which includes the network discovery time, the network registration time and the client processing time. This undesirable handover performance motivates the study of different link quality parameters based upon which the decision to switch backhauls may be made. We build a set of APIs to provide basic functions that can be used to extend the network monitor module which makes the backhaul switching decision. The APIs communicate with different wireless devices and provide information such as RSSI, noise level, BER, etc. III. MULTIPLE BACKHAUL ACCESS APIS Our challenge is to provide a set of APIs that may be used by the network monitor to implement flexible backhaul switching policies. We have two main design goals for these APIs. First, we can only control processing in the client; we cannot upgrade network equipment such as base stations or access routers. Second, the APIs must hide the details of the wireless interface from the network monitor. After studying several wireless cards it is apparent that while it is possible to obtain values for certain parameters of interest, some parameter values may only be estimated or inferred depending on the interface card. We provide a summary of the API below. If a function starts with Get, the value is obtained from the interface; if it starts with Cal, the value is calculated and can be taken as an estimate. / Common functions / // Use ioctl () or serial communication int GetRSSI(char InterfaceName); / Functions for cards only / // Parsed from /proc/ net / wireless int GetNoise(char InterfaceName); // Wireless extension long GetBitRate(char InterfaceName); // Calculated from SNR double CalBitErrorRate(char InterfaceName); // Calculated from BER and MTU double CalFrameErrorRate(char InterfaceName); Most cards support a standard called the Wireless Extension. This provides a general way to get information from these cards using IOCTL requests. Using this method, the IOCTL returns must be parsed. The interface allows the RSSI, MTU and transmission rate to be obtained directly. 4545

4 CDMA cards do not provide such an interface. Instead, the interface to these cards is similar to that of a modem. Values of select parameters may be read from a serial port. In the commercial CDMA cards used in our implementation the only available measured parameter is the received signal strength indication (RSSI) of a link. For either card, we cannot get a bit or frame error rate directly from the interface. One possibility is to generate traffic and monitor the error rate, but this is difficult to do efficiently without modification of the base station or access router in the backbone network. A second option is to estimate the bit error rate from the RSSI. This is not straightforward for the cards because different modulation methods are used depending on the transmission rate. To get this estimation, we first use the GetRate function to determine the modulation scheme, and then apply the appropriate error rate formula for the modulation scheme. Once the bit error rate (BER) is determined, this can easily be mapped into an estimation of the frame error rate (FER) if we assume bit errors are independent and we know the size of the frames being transmitted. To determine the frame size with use the GetMTU function and apply the formula: FER =1 (1 BER) MTU IV. POLICIES FOR VERTICAL HANDOVER The APIs provided in Section III can be used to build sophisticated backhaul switching polices. For example, switching may be triggered based on error rates, data rates, or signal quality. Here we define a basic threshold scheme based on signal to noise ratio (SNR), and by adjusting the threshold values can implement several policies. Clearly, the policies described here are simple, but they are adequate for our purposes of showing the utility of the API and implementation of the mobile access router. In the threshold scheme, the mobile access router has a primary link, p, and a secondary link, s. As the names indicate, the mobile access router will use the primary link if its performance is good enough as defined by the thresholds, and will switch to the secondary link only when necessary. The primary link has two thresholds associated with it, T p low and T p hi. The secondary link has a single threshold, T s. In our experiments, the thresholds correspond to values of SNR, but they can easily be mapped to other parameters such as transmission rate, error rates, or delay. If the primary link is in service, it remains in use as long as the measured SNR p >= T p low. If the measured SNR p falls below T p low and the measured SNR for the secondary link, SNR s >= T s, the mobile router will switch to the secondary backhaul. The mobile access router returns to the primary backhaul if either SNR s <T s or SNR p >T p hi. By adjusting the thresholds, several policies can be implemented as described below: 1) Persistent Policy: The mobile access router attempts to stay on the primary backhaul unless it is unavailable. To implement this policy, T p low is set to the minimum SNR at which communication may take place, and T p hi is set very close to T p low. TABLE I SIMPLE IP HANDOVER POLICY THRESHOLD Policy Primary Link Primary Link Secondary Link Low Th. (db) High Th. (db) Th. (db) Persistent Aggressive Predictive ) Aggressive Policy: The mobile access router attempts to always use the link with higher quality; it favors the primary link only if it is above a high threshold. This may be implemented by setting T p low and T s to relatively high values and setting T p hi close to T p low. This policy may lead to instability by aggressively switching between backhauls. 3) Predictive Policy: The mobile router attempts to stay on the primary backhaul, but switches to the secondary link before the primary link is lost, thus improving performance. This may be implemented by setting T p low to a value above the minimum needed for communication, but at a point at which it is beginning to degrade. To promote stability, T p hi is set to a relatively high value. In all three policies, a stability period is set. If the threshold is not violated for a duration of longer than the stability period, no backhaul switching is performed. The level of aggressiveness, stability, etc., may be tuned by setting the thresholds. V. PERFORMANCE EVALUATION A. Testbed Setup The experimental setup consists of our mobile access router in a loosely coupled Mobile IP-based WLAN- Ethernet/WLAN-CDMA testbed. The wireless backhaul from the mobile access router is either WLAN (802.11) or CDMA. An ethernet connection is also available when the mobile access router is inside a building. We used Soekris WLAN access points (APs) with a Netgate 200mW long range b PCMCIA card. The CDMA network used was the Verizon wireless network. The Verizon CDMA network used in the testing provides its own Mobile IP Home Agent. This Home Agent will not serve traffic to a mobile device connected via a WLAN. Therefore, we were unable to test the vertical handoff between WLAN and CDMA using Mobile IP. Instead we tested simple IP vertical handovers between CDMA and WLAN networks to compare the performance of the handover policies. Table I summarizes the SNR thresholds used for each policy tested. A stability threshold of 3 seconds is used. The data for all tests for are collected using tcpdump and analyzed using tcptrace[8]. B. WLAN-CDMA Simple IP Handover Performance To avoid firewall filtering we conduct an ICMP Ping test from the mobile client to a server inside the CSE department of Penn State University. To measure handover performance, we track ICMP sequence number progression vs. time. The mobile router physically traverses a path inside the building along the lobby at normal walking speed. The 4546

5 Fig. 5. ICMP Time SEQ with SNR - Persistent Policy. Fig. 7. ICMP Time SEQ with SNR - Aggressive Policy. Fig. 6. Packet Loss Distribution - Persistent Policy. initial backhaul is WLAN. The first handover switches the backhaul to CDMA; a subsequent handover occurs which switches the backhaul back to WLAN. The timing of the handovers differs for the different policies. The packet size is set to 1400 bytes and the transmission interval is 10ms. This rate saturates the CDMA network and results in high packet loss when the CDMA backhaul is used. We use this rate to show that available network throughput is critical to support different service requirements in addition to the signal quality such as the SNR parameter. 1) Persistent Policy: The goal of the persistent policy is to keep the WLAN connection as long as possible. For this policy we chose T low p = 0dB and T hi p = 10dB. These values were chosen because we observed that WLAN performance (such as throughput) degrades to zero quickly at these values. Figure 5 shows the ICMP time sequence graph during the experiment with the persistent policy. The packet number progression vs. time is indicative of the system throughput. We include the measured SNR and transmission rate on the y-axis as well to show how this correlates to actual throughput of the wireless link. Figure 6 shows two bursts of packet loss which correspond to two SNR drop-offs near the handover time. The first burst occurs at 53 seconds due to a sudden, but brief drop in SNR on the WLAN backhaul, and results in 635 lost packets (corresponding to the (53, 635) in the Figure). This drop is shorter than the stability timer, so no handover occurs. The second burst of lost packets (55, 407) corresponds to a drop in WLAN SNR to -23dB which triggers the first Fig. 8. Packet Loss Distribution - Aggressive Policy. backhaul handover at 57 seconds. There is an short blackout time after the backhaul switch before the first message is received from the CDMA network. We count the WLAN packet loss during the last stability period until the blackout period ends as shown in Figure 10. The CDMA backhaul link experiences a burst of packet loss during its first 3 seconds of use. The backhaul uses the CDMA network for a short time and then switches back to the WLAN link at 63 seconds when the WLAN has a measured SNR of 11dB. Because the WLAN SNR is still low there is visible packet loss (in Figure 6) even after the second handover resulting in decreased throughput. In addition, there is a sudden SNR drop at 81s. This results in another burst of packet loss before the link stabilizes. This drop in SNR is not sustained longer than the stability timer so no backhaul handover to CDMA occurs. In summary, the packet loss of persistent policy is mainly due to the instability of the WLAN link at relatively low SNR values. The packet loss from CDMA network is discussed in more detail below. 2) Aggressive Policy: The rapid drop-off in performance observed on the WLAN link makes setting the thresholds for the aggressive policy difficult because there is not a large range of values during which a switch from WLAN may take place. We set relatively high threshold values for both backhauls, as shown in Table I and the CDMA network quality is very good and stable in the building. The time sequence graph for the experiments with the aggressive policy is shown in Figure 7. The aggressive policy properly chooses to use the backhaul with the highest 4547

6 Fig. 9. ICMP Time SEQ with SNR - Predictive Policy. SNR as long as possible, but does not achieve overall higher throughput performance than the other policies. The reason is that, although the CDMA link has higher SNR, its sustainable transmission rate is lower than the WLAN, and thus it incurs high packet loss. The packet loss over time is shown in Figure 8. Since the threshold values of the WLAN network were set hight, the CDMA backhaul was used for a longer period of time. 3) Predictive Policy: Figure 9 shows the time sequence graph for the predictive policy. The handover from WLAN to CDMA occurs at 54s, and the subsequent handover back to WLAN occurs at 73s. These handovers correspond to measured SNR values of 8dB and 25dB, respectively. The predictive handover policy uses lower threshold values than the aggressive policy, so the backhaul tends to remain on the primary link, in this case WLAN, for a longer period of time. There is no burst packet loss related to handover (not shown). Because messages are buffered in the client kernel, and the handovers are relatively close in time, interleaved packets are received over the CDMA and WLAN backhaul. The higher packet loss rate of CDMA network accounts for almost all lost packets in this experiment. The overall throughput achieved using the predictive policy is better than the other two policies we explored. The main reason is that the WLAN backhaul provided a higher data rate, and hence resulted in less packet loss. This illustrates that, depending on network environments, different policies and thresholds will lead to better performance. The APIs we provide allow the flexible development of these policies. Figure 10 shows the causes for packet loss for all three policies. For the aggressive policy, loss on the CDMA backhaul dominates the performance. This argues for a tradeoff between SNR and transmission rate. This is possible using the APIs as discussed in the next subsection. 4) Combined Policy: Based on our observations above, we define a new policy that attempts to stress the use of backhaul with the highest transmission rate, but also avoids long pauses by predicting when link outage will occur. To implement this policy, we set SNR thresholds T hi SNR p and T low SNR p to the same values as the corresponding SNR thresholds for the predictive policy. In addition, we defined a new set of thresholds based on transmission rate with the same relationship as with the Fig. 10. Packet Loss Comparison - Three Policies. aggressive SNR policy. That is, we set T low rate p = T rate s and set T hi rate p close to T low rate p. In our experiments, this policy performed exactly as the predictive policy because of the behavior of the WLAN backhaul link. This link always had a higher rate than the CDMA link unless it was about to drop below the threshold at which the link was broken. In this setting, this is the desirable behavior. In settings with different wireless technology being used for backhaul, it would remain on the link with the highest rate but avoid outages. VI. CONCLUSION AND FUTURE WORK In this paper we present a flexible framework and implementation of a Multiple Backhaul Mobile Access Router. A set of backhaul interface monitoring APIs is provided to support flexible handover policies. We present experimental results to validate the performance of our mobile access router and several handover policies. In the future, we plan to evaluate the performance of Mobile IP vertical handovers across different wireless links and extend the handover polices to more sophisticated decision models. ACKNOWLEDGMENT The authors would like to acknowledge the workit group in Bell Labs, New Jersey, especially Girish Chandranmenon, Clement Lee, Milind Buddhikot and Scott Miller. REFERENCES [1] V. Devarapalli, R. Wakikawa, A. Petrescu, and P. Thubert, Network mobility (nemo) basic support protocol, RFC 3963, [2] C. Ng, T. Ernst, E. Paik, and M. Bagnulo, Analysis of multihoming in network mobility support, draft-ietf-nemo-multihoming-issues-07, [3] M. Buddhikot, G. Chandranmenon, S. Han, Y. W. Lee, S. Miller, and L. Salgarelli, Integration of and third-generation wireless data networks, in the IEEE INFOCOM, [4] R. Chakravorty, P. Vidales, K. Subramanian, I. Pratt, and J. Crowcroft, Performance issues with vertical handovers - experiences from gprs cellular and wlan hot-spots integration, in the IEEE PERCOM, [5] E. S. Navarro and V. Wong, Comparison between vertical handoff decision algorithms for heterogeneous wireless networks, in VTC, [6] C. E. Perkins, Ip mobility support for ipv4, RFC 3220, [7] Workit - wireless open research kit, 2007, [8] Tcptrace, v 6.6.0,