1
RSVP Extensions for Seamless Handoff with QoS
Aware in Heterogeneous WLAN/WiMAX Networks
Neng-Chung Wang1, Shiao-Ming Wei2, and Yung-Fa Huang3
1Department of Computer Science and Information Engineering
National United University, Miao-Li 360, Taiwan, R.O.C. Email: [email protected]
2Department of Computer Science and Information Engineering
Chaoyang University of Technology, Taichung 413, Taiwan, R.O.C. Email: [email protected]
3Department of Information and Communication Engineering
Chaoyang University of Technology, Taichung 413, Taiwan, R.O.C. Email: [email protected]
Abstract―In this paper, we propose an RSVP extension
scheme for seamless handoff in heterogeneous WLAN/WiMAX networks. This scheme is based on QoS aware mobility architecture to guarantee a certain QoS. The network selection is initiated by the mobility of the MS and pre-handoff is performed based on signal strength. On the other hand, if the selection is triggered by congestion, the handoff is based on congestion controlling delay according to the QoS parameters. Simulation results show that the proposed scheme outperforms previous schemes.
Index Terms―Handoff, heterogeneous wireless
net-works, quality of service, WiMAX, WLAN..
I. INTRODUCTION
In the recent evolution of wireless mobile net-works, which are characterized by great hetero-geneity, quality of service (QoS) is most important and cannot be ignored. QoS is specified usually as a set of parameters at the user level. These QoS parameters are then mapped or translated into re-source requirements for the architectural layers (e.g. CPU, memory, etc. for the operating system and bandwidth, buffers, etc. for the network). When the resource requirements have been determined, a ne-gotiation process takes place between the network and the called user application to set up a contract detailing the level of resources committed by each party. The level of committed resources might or might not be the same as the original level of
re-quirements, depending on the capabilities of the components involved and the availability of re-sources. If the level of resources committed by the various parties is acceptable to the calling user ap-plication, a contract is set up and the application is admitted to the system, otherwise it is not. Once a contract is agreed on, the application can be started and a policing mechanism ensures that the various parties abide by the contract. Non-conformance by the parties involved might lead to the termination of the application.
The IEEE 802.11 WLAN (Wireless Local Area Network) is rapidly becoming established. It is cheap and easy to install. WLAN provides a higher speed data rate but covers only small areas and al-lows limited mobility. It is normally deployed using a hotspot approach. In comparison, WiMAX (Worldwide Interoperability for Microwave Access) has a large coverage range per cell and guarantees the quality of service. There are a variety of enter-prise network architectures that can be imple-mented using 802.16e. This technology could con-nect campuses or could work directly with end-user laptops and desktop systems, replacing all or part of the wired backbone. While there will certainly be some overlap, the two standards have some im-portant differences. WLAN has already been wide-ly deployed and WiMAX with its wide coverage is developing dramatically. It is a basis for the next
2
generation technology because of its IP architecture and QoS support guarantee.
However, when 802.16 WiMAX and 802.11 WLAN networks are combined, the situation be-comes more complicated. The mutual inferences of devices or terminals from different subnets cause systems to become even more problematical. The completions between users in the same collision area trying to access a channel gets quite fierce. Consequently, the wireless channel gets more unre-liable because its performance deteriorates, even if the duration is short. Furthermore, the differences in delays and hardware resources of the different users make the handoff and roaming even more challenging.
Providing a seamless handoff for QoS connec-tions in heterogeneous WLAN/WiMAX environ-ments becomes important. However, in the wireless networks used today, many mobile users still can-not obtain the network resources they need when employing real-time services like voice, video conferences, video IP phone, and so forth while handoff occurs, and it causes a serious delay or even the break of the link.
There are many researches focused on improving RSVP solution in heterogeneous networks [6, 10]. RSVP can provide the necessary QoS because of its bandwidth guaranteed capacity. However, RSVP cannot provide a resource reservation mechanism that is sufficiently flexible and suitable. In this pa-per, a RSVP extension scheme is proposed for seamless handoff in heterogeneous WLAN/WiMAX networks. The proposed scheme is based on QoS aware mobility architecture to guarantee a certain QoS.
The rest of this paper is organized as follows. In Section 2, related work is discussed. The proposed scheme is developed in Section 3. Simulation re-sults are given in Section 4. Finally, Section 5 draws the conclusions.
II. RELATED WORK
This section presents the RSVP overview and the related researches.
A. RSVP Overview
Resource Reservation Protocol (RSVP) provides real-time and reliable service through the use of virtual circuits. It is a resource reservation setup protocol designed for the Integrated Services (In-tServ) [2, 11] model and has a number of attributes that have led to it being adopted as an Internet standard approved by Internet Engineering Task Force (IETF). RSVP is not a routing protocol but a control protocol, which allows Internet real-time and reliable applications to reserve resources before they start transmitting data. This means that when an application uses RSVP to request a specific link QoS for a data stream, RSVP selects a data path relying on underlying routing protocols, and then reserves resources along the path according the QoS. As long as RSVP is receiver-oriented, each receiver is responsible for reserving resources to guarantee QoS. Thus, the receiver sends an RESV message to reserve resources along all the nodes on the delivery path to the sender.
RSVP provides receiver-oriented setup of re-source reservation for multicast or unicast data flow and adapts dynamically to changing group membership and routes. RSVP reserves resource for simplex flows, for instant, it requests resource in only one direction. Two types of messages, PATH and RESV, are used in RSVP to setup re-source reservation states on the nodes along the path between a sender and a receiver. PATH sages are sent by the source, and each PATH mes-sage is associated with a specific data flow. When PATH messages traverse the network to the desti-nation, they are intercepted by RSVP-enable IP routers on the path. The routers set up soft path states for the data flows. The path state includes the previous and next hops of the flow and its traffic characteristics. As a PATH message reaches the in-tended receiver, the receiver replies with a RESV message if it wants to make a reservation for a spe-cific flow. The RESV message traverses the path back to the sender. If the required resources are available, a soft-state reservation is established in the router. Otherwise, a RESVErr message will be replied to the receiver.
B. Related Researches
3
services, research in wireless network has been in-creasing. In [7] and [8], Huang and Kuo et al. pro-pose an adaptive reservation mechanism for the next generation mobile communication systems. However, they do not apply it for heterogeneous networks. Following this research, more QoS me-chanisms for heterogeneous wireless networks have been proposed [1, 5, 9]. Furthermore, Dai et al. propose a new user-centric algorithm for vertical handoff in heterogeneous wireless networks [4]. This scheme combines one trigger to maintain the connection and another one to maximize the user throughput. However, reserving resources for mo-bile stations necessary for handoff between BS and AP was not considered.
For WLANs, QoS management has been defined by IEEE 802.11. The QoS mechanism for 802.11 cannot be directly applied in the 802.16e environ-ment. Several studies have addressed resource res-ervation in 802.16e or 802.11 [6, 7, 10]. However, few have addressed the QoS in the heterogeneous WLAN/WiMAX environment [3].
III. PROPOSED RSVP EXTENSION SCHEME IN H E-TEROGENEOUS WLAN/WIMAX NETWORKS
In this section, a RSVP extensions scheme for seamless handoff in heterogeneous WLAN/WiMAX networks is proposed. This scheme provides pre-reservation for real-time ser-vices.
A. System Model
In heterogeneous WLAN/WiMAX networks, when an MS move away from a BS the signal level degrades and the MS needs to switch to another BS or AP. The access point (AP) of WLAN is attached to the subscriber station (SS) of WiMAX. The MS is equipped with multiple wireless interfaces, in-cluding any combination of WiMAX and WLAN interface. When a user wants to access a given ser-vice or application, there may be various connec-tivity alternatives to select from, and hence the main question is how to detect availability of mul-tiple alternatives and select the most suitable one for a given type of service [4].
Fig. 1 gives the handoff scenario for a
heteroge-neous WLAN/WiMAX network. A RSVP exten-sion scheme for seamless handoff was proposed to manage the mobility of MSs and make the resource reservations for MSs. In the system model, a gate-way/QoS manager (GW/QM) mechanism is needed. GW/QM forwards the packets transmitted by the sender to MS via a conventional reservation link. The arrow from the MS shows the direction it is moving in. SS/AP is the access point of WLAN and BS is the base station of WiMAX, respectively. No matter what the network is, all access the IP net-work through this gateway.
Fig. 1. Handoff scenario for a heterogeneous WLAN/WiMAX network.
In Fig. 1, MS1 moves from the scope of SS1/AP1 to the scope of SS2/AP2, the related access points and gateways need to cooperate with MS1 to select a network for sustaining service. In the system model, a reserve status report mechanism and a QoS manager (QM) have been added. There are QMs in the gateway of a site which intercept all incoming packets and changes route from regional care-of-address (RCoA) to local care-of-address (LCoA) of MSs according to the mapping table. Then, the intermediate routers forward the packets to MSs via LCoA. Through this mechanism, BSi or
4 SSi/APi periodical broadcast the Reserve
Require-ment Vector (RSRV) message. The RSRV message, including multi-parameters vectors BSi or SSi/APi
exchanges and collects all the related information. Before starting, some QoS parameters which will influence the determining policies are obtained by interacting with MS1. Other information needed in-cludes: neighboring SSi/APi or BSi, characteristic
parameters of link states such as residual band-width, round trip time etc., and resource reserving requirement vectors. Once there is a new call, MS1 sends the requirements through call admission. Because it is assumed that there is no priority in the network situations and no exact measurements as guideline, some statistic parameters are included in the algorithm.
B. Proposed Scheme
The proposed scheme includes a handoff deci-sion, and network selection which is also called pre-handoff, and then the actual handoff. Further-more, it also needs a data structure, the reserve re-quirement vector RSRV. The RSRV is a mul-ti-parameters vector defined as follows:
RSRV={S, Ch, LPR}, where
● S is the information about the signal (Receive Signal Strength, RSS) of MS1 for BSi or SSi/APi
received. S is the received signal strength of the MS1. Through the value of S, the distance be-tween them can be estimated leading to a re-source reserving decision.
● Ch=(BW, DT) is the QoS resource parameter of every relay node still residual, where BW is the residual bandwidth for a relay node and DT is the delay time from it to the neighboring nodes. Through the periodical RSRV broadcasting of BSi or SSi/APi, they exchange and collect all the
related information. Accordingly, they update the routing tables. Actually, Ch is determined by choosing the maximum residual bandwidth path with the minimum delay for each route. Utilizing this metric, all information about each node be-comes available and this metric can be taken as the measurement when establishing the resource reservation path.
● LPR is the lost packet rate (LPR). There is a
predefined threshold value for LPR, LPRth. The
handoff will happen when LPRi > LPRth. MS1
knows the status of the neighboring SSi/APi or
BSi via the RSRV. MS1 then chooses either BSi or
SSi/APi; the one which satisfies the requirements
and then sends the notification information to require the set up of the resource reservation path.
C. Reserving Management
The resources reservation for MS1 is decided ac-cording to the signal strength (RSS) by MS1 from BSi or SSi/APi. As shown in Fig. 2, the RSS is
di-vided into two phases threshold values which are used to decide how to tackle the situation. In Fig. 2, the tracks of the MS1 are consistent with the changing RSS and network status.
Fig. 2. Changing of network status with different RSS thresholds.
Assume that MS1 moves from WLAN network coverage area to WiMAX network coverage area, if MS1 receives no other RSS from the WLANs and the RSS by MS1 from WLAN is less than threshold S2, as shown in Fig. 3, QM will make a pre-reservation for MS1. To allocate resources for the WiMAX network, QM notifies the correspond-ing active BSi to make a pre-reservation for MS1. If
the received signal drops below threshold S1, QM switches the data flow to an active reservation path for MS1. On the other hand, if the RSS from either the old SSi/APi or the new one is less than threshold
S1, the corresponding link is released immediately. In another case, assume that MS1 moves from WiMAX network coverage area to WLAN network
5
coverage area, if MS1 receives an RSS from WLAN which is higher than threshold S1, it sends a notifi-cation message to QM notifying the corresponding active SSi/APi to make a pre-reservation for MS1. If
the received signal is higher than threshold S2, QM switches the old reservation path to the new reser-vation path by performing a seamless handoff and it sends a message to request deleting the BSi
res-ervation path. In a horizontal handoff, MS1 sends a notification message to QM notifying target BSi or
SSi/APi to make the pre-reservation. This is
ac-cording to the RSS of WLAN or WiMAX network when MS1 receives a signal higher than threshold S1. On the other hand, if MS1 receives a signal higher than threshold S2, QM switches the data flow to the active reservation path.
D. Handoff Decision and Network Selection In the case of any one of the following situations, SSi/APi or BSi need to decide if a call admission for
MS1 needs to perform handoff:
1. The signal received by MS1 from BSi or SSi/APi
is so weak it is lower than signalth.
2. Ch is the QoS resource parameter that consid-ers bandwidth and delay time as QoS metrics, for feasible path computation. For example, as shown in Fig. 3, this process in detail as fol-lows:
(1) In the initial state, MS1 is in SS1/AP1, and moves to SS2/AP2.
(2) When MS1 moves to SS2/AP2, there are four paths to choose from. MS1 tries to find the op-timal route to sender, which is P1={SS2/AP2, BS2, R2, GW/QM}, P2={SS2/AP2, BS2, R2, R1, GW/QM}, P3={BS2, R2, GW/QM} and P4={BS2, R2, R1, GW/QM}. P1= {(3, 3), (5, 2), (2, 4)}, the maximum bandwidth of the reserved path is 2 Mbps, delay time is 9 seconds. P2={(3, 3), (5, 2), (4, 2), (3, 1)}, the maximum bandwidth of the reserved path is 3 Mbps, delay time is 8 seconds. P3={(5, 2), (2, 4)}, the maximum bandwidth of the reserved path is 2 Mbps, de-lay time is 6 seconds. P4={(5, 2), (4, 2), (3, 1)}, the maximum bandwidth of the reserved path is 3 Mbps, delay time is 5 seconds. As a result, MS1 chooses the path with maximum residual
bandwidth, P4. If the conditions are the same, then MS1 selects the minimum delay time path. (3) The optimal route is based on signal strength.
In this case, MS1 chooses P2 to establish a RSVP path.
(4) A notification message is sent from MS1 to SS1/AP1. This message is used by MS1 to notify GW/QM of the visiting location and mobile profile.
(5) When receiving the notification message, SS1/AP1 forwards it to BS2.
(6) BS2 receives the notification message, it for-wards it to GW/QM along P2.
(7) GW/QM receives the notification message, it terminates the message.
(8) A DSA-REQ message is sent from GW/QM to SS2/AP2 along P2.
(9) When receiving the DSA-REQ message, SS2/AP2 forwards the PATH message to MS1. At the same time, SS2/AP2 forwards the DSA-RSP message to GW/QM along P2.
(10) Then, a RESV message is sent from MS1 to SS2/AP2.
(11) Now, the newly established path is SS2/AP2-BS2-R2-R1-GW/QM. So, the RSVP tunnel from sender to MS1 is {GW/QM, R1, R2, BS2, SS2/AP2}.
3. SSi/APi or BSi is too busy to satisfy current connection service, in this situation which can be measured in terms of LPR. Therefore, the handoff decision mainly takes the responsibility to check these two conditions periodically. Once any of them occurs, the handoff control algorithm has to choose a network for the call admission.
6
Fig. 3. Handoff for an MS move from the WLAN to WLAN/WiMAX area.
IV. PERFORMANC EVALUATION
In order to evaluate the performance of the pro-posed scheme by the different metrics in the whole network, a simulation was designed and conducted, simulations were carried out on the OPNET 11.5 platform. In the system model, we assumed that an MS which moves in a random direction at the speed of 0-5 m/s. Two kinds of BS or SS/AP, linked together through gateways, follow the MS’s tracks and are responsible for exchanging the packets and maintaining the QoS paths. It was assumed that the WLAN network had a 2 Mbps bandwidth and the WiMAX network a bandwidth of 4 Mbps for downlinking and 2 Mbps for uplinking. The radius of the WLAN was 100 m, 1 Km for WiMAX BS, and their distribution was random.
In the physical model, the channel power gain h was set to 4 dB and the bit error rate error was 10-3. The lost packet probability was lp=0.008, while the data rate b of WLAN was 1 Mbps and that for WiMAX was 384 Kbps. The transmission power of BS or SS/AP was 23 dBm and the transmission power of MS was 3 dBm.
For the necessary of comparison, a network handoff strategy called No Reservation Handoff
Scheme (NRHS) was assumed. In NRHS, none of the BS or SS/AP reserved any resource for MS. The negotiating was initiated whenever the MS became aware of it being necessary between the MS and the target BS or SS/AP.
In Fig. 4, the handoff blocking probabilities were compared for different mobility speed for NRHS, RSVP, and the proposed schemes. The BS or SS/AP was reserved for all the MS in the neigh-boring area. Accordingly, most of the handoff re-quests were rejected when the MS moved faster than 1 m/s because there was no reservation. In the proposed scheme, most of the handoff requests were satisfied when they moved in the BS or SS/AP coverage of others. That was because the mobility of MS could predict and the resources were reserved accordingly. However, the handoff blocking probability was still high when the cost was too high for reserving in the RSVP scheme. The failed handoff would immediately result in another request.
Fig. 5 shows the performance of the lost packet probability with a different number of nodes. It can be observed that the proposed scheme performed better than the other two schemes and its lost pack-et probability was lower than 3.5%.
Fig. 4. Handoff blocking probability vs. speed of mobile station.
7
Fig. 5. Lost packet probability vs. number of nodes.
V. CONCLUSIONS
In this paper, a RSVP extension scheme for seamless handoff in heterogeneous WLAN/WiMAX networks is proposed. This scheme is based on QoS aware mobility architec-ture to guarantee a certain QoS. In order to manage the mobility of mobile users, by resource reserva-tion and precise pre-handoff decisions, the concept of pre-handoff which allowed the BS or SS/AP to reserve some resources and do re-routing before-hand was adopted. Simulation results show that the proposed scheme outperforms previous schemes.
ACKNOWLEDGMENTS
This work was supported by the National Science Council of Republic of China under grant NSC-98-2221-E-239-018.
REFERENCE
[1] J. N. Al-Karaki and A. E. Kamal, “End-to-End Support for Statistical Quality of Service in Heterogeneous Mobile Ad Hoc Networks,” Computer Communications, pp. 2119-2132, November 2005.
[2] R. Braden and L. Zhang, “Resource
ReSerVation Protocol (RSVP) - Version 1 Functional Specification,” RFC 2205, September 1997.
[3] Y.-W. Chen, I.-H. Peng, and S.-T. Guan, “Dy-namic Bandwidth Management for Handoffs with RSVP in 802.16/WLAN Environment,” Advanced Information Networking and Appli-cations Workshops, Vol. 2, pp. 243-248, May 2007.
[4] Z. Dai, R. Fracchia, J. Gosteau, P. Pellati, and G. Vivier, “Vertical Handover Criteria and Al-gorithm in IEEE 80211 80216 Hybrid Net-works,” Proceedings of the IEEE Communica-tion Magazine, Vol. 19, pp. 2480-2484, May 2008.
[5] A. Hasib and A. O. Fapojuwo, “Analysis of
Common Radio Resource Management Scheme for End-to-End QoS Support in Mul-tiservice Heterogeneous Wireless Networks,” IEEE Transactions on Vehicular Technology, Vol. 57, No. 4, pp. 2264-2277, July 2008.
[6] N.-F. Huang and W.-E. Chen, “RSVP
Exten-sions for Real-Time Services in Hierarchical Mobile IPv6,” ACM/Baltzer Mobile Networks and Applications, pp. 625-634, December 2003.
[7] G. S. Kuo and P. C. Ko, “Dynamic RSVP Pro-tocol,” Proceedings of the IEEE Communica-tion Magazine, Vol. 41, pp. 130-135, May 2003.
[8] G. S. Kuo and Ming Wang, “A QoS-Adaptive
Resource Reservation Scheme for MPEG4-based Services in Wireless Net-works,” Proceedings of the IEEE Communica-tion Magazine, Vol. 5, pp. 3261-3265, May 2005.
[9] N. Shenoy and R. Montalvo, “A Framework
for Seamless Roaming across Cellular and Wireless Local Area Networks,” Proceedings of the IEEE Communications Magazine, pp. 50-57, June 2005.
[10] N.-C. Wang, J.-W. Jiang, and Y.-F. Huang, “RSVP Extensions for Real-Time Services in Heterogeneous Wireless Networks,” Computer Communications, pp. 2248-2257, July 2007.
[11] J. Wroclawski, “The Use of the Resource
Reservation Protocol with the Integrated Ser-vice,” IETF RFC 2210, September 1997.
