considers both the flow rate demand and network re- ..... Otherwise, the flow is dropped. It should be ..... Handoff call blocking rate: which is the percentage of.
End-to-end QoS Framework for Heterogeneous Wired-cum-Wireless Networks Ming Li, Hua Zhu, Imrich Chlamtac, B. Prabhakaran* Erik Jonsson School of Engineering & Computer Science, University of Texas at Dallas, TX 75083 {mingli, zhuhua, chlamtac, praba}@utdallas.edu Abstract With information access becoming more and more ubiquitous, there is a need for providing QoS support for communication that spans wired and wireless networks. For the wired side, RSVP/SBM has been widely accepted as a flow reservation scheme in IEEE 802 style LANs. Thus, it would be desirable to investigate the integration of RSVP and a flow reservation scheme in wireless LANs, as an end-to-end solution for QoS guarantee in wiredcum-wireless networks. For this purpose, we propose WRESV, a lightweight RSVP-like flow reservation and admission control scheme for IEEE 802.11 wireless LANs. Using WRESV, wired/wireless integration can be easily implemented by cross-layer interaction at the Access Point. Main components of the integration are RSVP-WRESV parameter mapping and the initiation of new reservation messages, depending on where senders/receivers are located. In addition, to support smooth roaming of mobile users among different basic service sets (BSS), we devise an efficient handoff scheme that considers both the flow rate demand and network resource availability for continuous QoS support. Furthermore, various optimizations for supporting multicast session and QoS re-negotiation are proposed for better performance improvement. Extensive simulation results show that the proposed scheme is promising in enriching the QoS support of multimedia applications in heterogeneous wired-cum-wireless networks.
1. Introduction IEEE 802.11 wireless LANs are being successfully used as the last-mile technology in the present-day pervasive computing environments. In many instances, wireless/mobile users need to access/exchange information stored in some servers located in wired networks. Considering that information being accessed or exchanged
*
comprise multiple media formats, supporting QoS across wired and wireless networks becomes important. RSVP/SBM [7][23] has been widely accepted as a reservation scheme for flow reservation in IEEE 802 style LANs to support Integrated Service (IntServ) [6]. Thus, a natural idea would be the integration of RSVP in wired infrastructure and a RSVP-like flow reservation protocol in wireless LAN. Advantages of this approach are: (1) Reservation based schemes can provide ensured QoS guarantee than service differentiation, especially when network traffic is high. (2) Per-flow signaling for end-toend reservation becomes quite easy through integration of a RSVP-like flow reservation protocol in wireless LAN and RSVP. (3) The message mapping and resource management are only needed at the access point, which has more computational power. (4) The overhead of the integration can be minimized by cross-layer interaction between MAC and upper layers. To the best of our knowledge, there is no RSVP-like flow reservation and admission control scheme in IEEE 802.11 wireless LAN for the integration with RSVP. Although many optimizations have been proposed to improve QoS support by providing service differentiation in IEEE 802.11 wireless LANs [1][2][17][22], they have two major disadvantages. First, most schemes do not provide explicit flow reservation and admission control. Without this, it is impossible to guarantee QoS of realtime flows when network traffic becomes heavy. Second, most schemes only consider QoS support in WLANs and thus are not interoperable with QoS schemes in wired networks. These two disadvantages make existing QoS schemes incomplete and inefficient in practice. Better schemes that provide flow reservation and seamlessly integrate with wired QoS schemes will gain more popularity. In this paper, we propose Wireless LAN Flow Reservation Protocol (WRESV), a RSVP-like flow reservation and admission control scheme for QoS guarantee in IEEE 802.11 WLANs. WRESV takes a similar approach of signaling for flow reservation for easy integration with
This work is supported in part by the National Science Foundation under Grant No. 0237954 for the project CAREER: Animation Databases.
RSVP. However, unlike RSVP, no soft-states are recorded at the mobile hosts (MHs) and no refresh messages are required in WRESV. Therefore, WRESV does not suffer from the scalability issue. Furthermore, WRESV uses channel busy time to estimate channel available bandwidth at the AP for accurate admission control decisions. With the integration of WRESV and RSVP, end-toend quality of service can be guaranteed. The major components of this integration are RSVP-WRESV parameter mapping, and initiation of new reservation messages at the boundary of the wired and wireless network, depending on the location of the sender/receiver. In addition, various optimizations for supporting multicast session and QoS re-negotiation are proposed for better performance improvement. Finally, a QoS aware handoff scheme is devised so that MHs can move among various cells without experiencing serious performance degradation. This paper is organized as follows. Section 2 reviews the related works in QoS schemes in IEEE 802.11 wireless LANs and wired/wireless integration. Section 3 overviews the RSVP/SBM protocol. Section 4 describes the system architecture. Section 5 introduces the proposed WRESV protocol. Section 6 discusses the details of the protocol integration of WRESV and RSVP. Section 7 proposes the scheme for seamless handoff to support user mobility. Section 8 discusses simulation results of the proposed framework and Section 9 concludes this paper.
2. Related works Several admission control schemes have been proposed in order to guarantee QoS in wireless LANs [24]. Barry and Campbell [2] propose a Virtual MAC algorithm that passively monitors the channel by using virtual MAC frames and estimates local service level (i.e. throughput and delay) by the measurement of virtual frames. Valaee and Li [22] suggest another measurement based admission procedure using a sequence of probe packet for ad hoc networks. Instead of using probe packets, Shah and Chen [17] propose a measurement based admission control scheme using data packets to measure the network load. Banchs and Pérez [1] propose ARME, an extension of DCF, that uses a token bucket based algorithm to detect whether the network is in an overloaded condition, and thus improve the performance of system by adjusting contention window appropriately. All these schemes only consider the QoS guarantee within wireless LANs and no attempt has been made for the more challenging problem of supporting QoS over wired-cumwireless networks. In recent years, cross-layer interaction [8][17] has gained more attention for protocol design in wireless network because of its efficiency. Usually, cross-layer
interaction is implemented for different layers to share same useful information such as flow characteristics, node location and network topology so that they can cooperate closely to meet applications’ QoS requirements. Integrating Differentiated Service (DiffServ) [5] with IEEE 802.11 WLAN has been studied. Park and Kim [15] propose a QoS architecture between DiffServ and IEEE 802.11e [3] by mapping priorities with IEEE 802.1D/Q. In order to support QoS and Mobility for wireless Internet, García-Macías and Rousseau [10] present a hierarchical QoS architecture to extend DiffServ to WLANs with flexible mobility management. In this paper, we focus on a different approach of integrating RSVP with QoS schemes in IEEE 802.11 wireless LANs. Talukdar and Badrinath [20] design MRSVP to enhance RSVP with advance resource reservations in order to provide integrated service to networks with mobile hosts. Then, Tseng and Lee [21] propose Hierarchical MRSVP to make advance reservation only when a mobile user moves to the overlapped area of the boundary cells between two regions, and thus provide better network resource utilization. However, both MRSVP and HMRSVP are basically working with Mobile IP, not for wireless LANs. Moon and Aghvami [14] propose a QoS mechanism in all-IP wireless access networks. In their scheme, re-routing of RSVP branch path toward the crossover router at every handoff event is made for reduction of resource reservation delays and signaling overheads. Also, advance reservation is made via a new BS for on-going flows to maintain QoS guarantee. Shankar and Choi [18] propose a MAC-level QoS signaling for IEEE 802.11e WLAN and address its interaction with RSVP and SBM. However, no effort is made to handle the specific issue of admission control in wireless LANs. Also, mobility issue is not addressed. From the above review, we can see that existing works in the literature either work on QoS support in wireless LAN, or focus mainly on protocol extension of RSVP without take advantage of special characteristics of IEEE 802.11. We feel that it is of high importance that in order to support seamless QoS support spanning wired/wireless networks as well as different BSSs in wireless LANs, issues such as admission control in wireless LAN, protocol integration, and handoff support need to be addressed in combination to provide an end-to-end QoS solution.
3. Overview of RSVP/SBM Integrated Service (IntServ) model [6][11] is proposed as an extension of Internet architecture to support realtime as well as non-real-time applications in current IP networks. The major components of the framework to implement IntServ are the packet scheduler, the admission control routine, the classifier, and the resource reser-
vation setup protocol. As the most popular resource reservation setup protocol, Resource ReSerVation Protocol (RSVP) [7] is designed to meet the requirements of IntServ model in a multicast, heterogeneous network environment. Further, Subnet Bandwidth Manager (SBM) [23] is proposed for RSVP-based admission control in IEEE 802-style networks. There are two basic message types in RSVP: RSVP_Path and RSVP_Resv. For each unicast/multicast session, the sender sends out Path message, which contains the SESSION object corresponding to a specific multicast session. Other objects Path message carries are SENDER_TEMPLATE, SENDER_TSPEC, ADSPEC, and PHOP. The purpose of the Path message is to establish the route for Resv message, provide sender specific characteristics, and record path state at intermediate routers. On the other hand, Resv messages are sent from receivers upstream to the sender with objects such as FLOWSPEC and TSPEC, which specify the desired QoS, and the traffic characteristic of the flow, respectively. Resv is sent along the route reserved to the Path message hop by hop and get merged if necessary. If a reservation request is rejected at an intermediate router, a ResvErr message will be sent to the receiver for notification. RSVP takes a “soft-state” approach to manage the reservation state in routers and hosts. Soft states are stored in intermediate routers and are refreshed periodically by Path and Resv messages, or deleted if no matching refresh messages arrive before the expiration of a “cleanup timeout” interval. Also, soft states can be removed explicitly by a teardown message from an end host. Due to the use of soft state, RSVP does not posses very good scalability. Currently, RSVP is the leading standard for design and implementation of IntServ on Internet and many protocols have been proposed to extend it for IP-based mobile/wireless networks [14][18][20][21]. It should be noted that some other IP reservation protocols (e.g., ST-II [9]) contain some noteworthy architectural differences from RSVP such as the use of hard-state and senderinitiated reservations. However, we focus on RSVP only and we believe that the design issues discussed in this paper are general and thus applicable to the integration with other protocols.
4. System architecture The architecture of wireless Internet is depicted in Figure 1 (revised from MIRAI architecture [12]). Multiple basic service sets (BSSs) are inter-connected by a distribution system (DS) and form an extended service set (ESS). An ESS is connected to the Internet via a gateway router. In each BSS, all mobile hosts (MHs) are within the broadcast region of their associated AP and can only
access the infrastructure through the AP. All MHs can roam among different BSSs of the same or different ESSs. Internet
Infrastructure
Gateway Router
Access Point
Wireless LAN
Figure 1. Architecture of Wireless Internet In such a wired-cum-wireless network, mobile/wireless users usually access/exchange information stored somewhere on the Internet via their associated APs and the gateway routers. For multimedia applications such as audio/video streaming, end-to-end QoS guarantee is highly desirable in order to ensure user satisfaction. Therefore, we propose a framework where RSVP is integrated with WRESV, a wireless LAN flow reservation protocol, designed to be seamlessly integrated with RSVP for end-to-end QoS support. In addition, due to the node mobility, if a MH moves towards another cell, its bandwidth should be allocated in the new cell and released from the old cell. To address this issue, WRESV provides a seamless handoff scheme for support of user mobility. The major objectives of the proposed RSVP-WRESV framework are: • End-to-end QoS guarantee is provided through wired/wireless signaling and accurate wireless LAN admission control. • Seamless roaming is supported when users move among different BSSs. If a self-organized ad hoc network is attached to the wired infrastructure through the AP, in order to make bandwidth reservation, a MH may have to send messages to AP through several hops, incurring larger signaling overhead and higher probability of reservation failure due to the considerable wireless link error. Furthermore, admission control decisions become more complicated due to issues of both inter-flow and intra-flow contention [16]. Therefore, our model is more appropriate for infrastructure based WLANs. Investigation of integration between wired networks and ad hoc networks will be our future work.
5. WRESV – Wireless LAN flow reservation protocol RSVP is designed to provide integrated service for packet-switched network such as IEEE 802.3. We extend RSVP to wireless LANs with several modifications by fully considering the characteristics of IEEE 802.11 wireless LANs. First, since all packets are relayed by AP, AP can act as a proxy for admission control and flow reservation, defined as wireless bandwidth manager (WBM). Second, by introducing signaling message for handoff process, seamless handoff is also well supported. Finally, the broadcast nature of the wireless medium can be utilized in multicast sessions so that wireless LAN bandwidth usage becomes more efficient. In our protocol, WBM monitors the wireless channel continuously and estimates the channel available bandwidth to ensure accurate admission control decisions. Before data transmission of a real-time flow, the source station sends a request with its QoS requirement to AP, which will accept/reject the flow according to the estimated available bandwidth in wireless LAN. For convenience, we call the proposed flow reservation scheme Wireless LAN Flow Reservation Protocol (WRESV). In the following subsections, we will discuss channel available bandwidth estimation and the flow reservation procedure in details.
5.1. Channel available bandwidth estimation To extend reservation based protocols such as RSVP to wireless LAN, the success of the flow reservation largely relies on the accuracy and efficiency of the admission control decisions, which in turn depends on accurate and dynamic online estimation of available bandwidth. We calculate available bandwidth based on two important metrics: node saturation throughput and channel busy time. To fully consider the shared medium CSMA/CA MAC in IEEE 802.11, we define saturation throughput of a node i, bsat,i, as the maximum aggregate throughput that can be received by i under the current network condition. Similar to [13] and [17], saturation throughput is calculated as
bsat ,i =
t ack
S − t enqueue
RTS/CTS/ACK, and the time for data packet transmission. If collision occurs, then ∆t increases due to additional time taken for multiple re-transmissions before eventual successful data reception. Usually, bsat,i is affected by multiple factors, including PHY rate, packet size, degree of traffic contention, and channel loss ratio. Given the average packet payload, ∆t well considers the effect of these factors. Under high traffic load, a node has to wait for a longer period of time before accessing the channel, resulting larger ∆t and thus lower saturation throughput. If channel loss ratio is high, then multiple re-transmissions may be required before a packet is successfully received. In addition, if auto fallback is enabled, PHY transmission rate may be different if link distance is different. If a link has higher physical rate, ∆t is smaller and bsat,i will be comparably larger. Although we assume a fixed data transmission rate throughout this paper, it is obvious that equation (1) can be applied to multi-rate channel without modification. Based on bsat,i, we can get channel available bandwidth, bava,i, by considering channel busy time. In other words, bava,i should be the remaining allocable bandwidth for a node. Let αi be the percentage in time that node i is in “busy” state. Note that a node is not in “busy” state unless all the following conditions are satisfied simultaneously: • No packet is waiting in the MAC queue: If there are packets waiting in the queue for channel access, a node is considered in busy state since it needs to handle all existing packets in the queue. • The node is not in NAV state: When it hears some packet transmission in the network, e.g., RTS or DATA, it sets its network allocation vector (NAV) value as non-zero. From this time until the time NAV is reduced to zero, the channel is reserved for the corresponding packet transmission and in busy state. • The node does not sense a busy channel at the MAC layer: If a node is not in NAV state, there are several possible reasons for it to sense a busy channel: (i) It attempts to send a packet; (ii) It is the receiver of a packet; (iii) It hears an ongoing transmission (such as the first RTS in Figure 2).
(1)
Where S is the MAC layer payload (upper layer packet) length in the current measurement period. tenqueue and tack are the time when a packet arrives at MAC layer of node i and when node i receives a MAC ACK about the same packet, respectively. The duration ∆t of tack tenqueue actually includes the time a node waiting for channel access, time of transmitting protocol packets
Figure 2. Special case of sensing a busy channel. Here when C hears RTS from A, it knows that channel has been busy for DIFS+RTS time.
α is important for the accuracy of available bandwidth estimation. If α is very low (e.g., 0.1), then almost the whole saturation throughput is allocable to new flows. On the other hand, If α is very high (e.g., 0.8), it is highly possible that the channel is busy transmitting existing flows and not much free bandwidth can be used for new data transmissions. Therefore, α well reflects the dynamics of wireless channel resource availability. With channel busy time estimated, we have that (2) bava ,i = (1 − α i ) ⋅ bsat ,i Then, combining equations (1) and (2), we obtain the following expression for channel available bandwidth estimation. S (3) bava ,i = (1 − α i ) ⋅ t ack − t enqueue This measurement can effectively calculate the available channel bandwidth experienced by a node during a very short period of time. In a wireless LAN where stations are within the broadcast region of each other, AP can measure the available bandwidth of the channel and enforce admission control accordingly. In our implementation, available bandwidth estimation is updated every second to ensure the accuracy. Available bandwidth estimation
Bandwidth (Mbps)
1.5
Available bandw idth
1
0.5
0 0
10
20
30
40
50
60
Time (second)
Figure 3. Estimation of available bandwidth To show the effectiveness and accuracy of the proposed available bandwidth estimation scheme, we conduct a simple simulation. Starting from 1 second, a new CBR flow of 80Kbps is introduced to a wireless LAN with 2Mbps physical bandwidth every 3 seconds until 60 second. As shown in Figure 3, available bandwidth decreases as the increase of number of flows in the BSS. At the time of 51, the network is approaching saturation status and there is only less than 100Kbps available bandwidth. At this time, there have been 16 flows in the network with total traffic of 1.25 Mbps. Also, notice that actually after 51 second, the channel busy time is almost 1. Thus the available bandwidth becomes very small and does not decrease significantly as new flows arrive after 52 seconds. Therefore, the proposed scheme does capture the bandwidth availability change dynamically with reasonable accuracy.
Note that we assume that AP is always capable of estimating channel available bandwidth. However, if AP does not send any packet, e.g., it is only the receiver of packets originated from some MHs, this assumption may not hold since it is not possible for AP to calculate bsat,i in equation (1). In this case, an initial value for bsat,i can be set to AP. In this paper, we use 1.2 Mbps for 2Mbps physical channel bandwidth.
5.2. Flow reservation procedure We adopt explicit signaling for request/response reservation messages for efficient admission control. REQUEST is defined as the message sent from wireless sender to AP which specifies the traffic characteristics of the source, and RESPONSE is defined as the message sent from AP to the wireless sender which indicates whether the flow can be supported or not. Since AP acts as a proxy for admission control, it can make the decision locally without the necessity of forwarding REQUEST to the wireless receiver. In addition, to address seamless mobility support, HANDOFF message is sent when a mobile host attempt to move into a new BSS. The contents of signaling messages are fully compatible with RSVP specification [7]. As shown in Figure 4, REQUEST, RESPONSE, and HANDOFF all contain session id and traffic QoS specification. Session id is represented by a triple (Destination Address, Protocol ID, Destination Port). QoS specification is described in one or more fields QoS_Spec of bandwidth/delay requirements such as Minimum Data Rate, Mean Data Rate, Maximum Data Rate, Maximum delay, and Maximum jitter. Here Mean/Maximum Data Rate corresponds to Token Bucket Rate and Peak Data Rate specified in RSVP. A Result field is also included in RESPONSE message to indicate the success/failure of flow reservation. In HANDOFF message, an extra field of Current AP is included so that the target AP will be able to communicate with the originally associated AP of the mobile host. These messages are sent as the payload of IEEE 802.11 MAC frames. Since only one pair of request/response messages are sent per flow, the signaling overhead is O(n), with n be the number of real-time flows in the network.
Figure 4. Contents of WRESV message
It should be noted that Maximum delay/jitter are included in the QoS_Spec field for generality. Actually, we can use reservation messages to estimate the path end-toend delay and then check whether the delay requirements of a flow can be satisfied. More complicated measurement based approach for delay/jitter statistics has been proposed by Bianchi and Borgonovo [4]. In this paper, we focus on the more challenging problem of bandwidth guarantee in wireless networks. The flow reservation procedure of WRESV works as follows. Before data transmission, the sender of a realtime flow sends its traffic information (embedded in REQUEST message) to AP, which obtains the traffic information in the EF field, and checks whether or not the bandwidth demand can be accepted according to the bandwidth availability. Once admitted, the new flow is added to a reserved flow list maintained at AP. Then, AP sets the result in the EF field of the response message and sends it back to the sender. If the result is 1, then the flow is accepted and allowed for transmission immediately. Otherwise, the flow is dropped. It should be noted that when a flow finishes, it is not necessary for the sender to notify AP. The reason is that a released flow does not consume channel time and the new estimated channel available bandwidth will be increased. Thus, when a new flow request arrives, AP is aware of the channel status change and will make decision on admission/rejection of the new flow according to the new available bandwidth estimation. Therefore, in our admission control protocol, only two messages are exchanged per flow, which is quite efficient.
…... AP
Gateway
IP Routers
Server
`
Wireless User
Figure 5. Illustration of end-to-end reservation
6.1. End-to-end reservation The end-to-end reservation setup procedures for downstream (wired-to-wireless) and upstream (wirelessto-wired) flows are depicted in Figure 6a and Figure 6b, respectively. Since admission control decisions of MHs are delegated by WBM at AP, reservation setup procedures for downstream and upstream flows work differently for efficiency.
(a) Downstream reservation
6. RSVP-WRESV integration With the proposed admission control strategy and signaling scheme, WRESV itself can work alone for QoS support in single-hop wireless LANs. In this section, we focus on integration of RSVP-WRESV integration so that QoS guarantees spanning wired and wireless networks can be provided. As shown in Figure 5, to establish endto-end flow reservation, signaling messages need to be sent between wireless users and wired servers through wireless AP, gateway router, and intermediate IP routers. As QoS signaling schemes for the Internet and wireless LAN, RSVP and WRESV should be integrated to realize end-to-end flow reservation. Since WRESV follows the same procedure of request/response as RSVP does, mapping of signaling messages can be made between the reservation messages of Path/Resv of RSVP, and REQUEST/RESPONSE of WRESV, respectively. To facilitate information sharing and message mapping, cross-layer interaction between MAC and upper layers at AP is implemented.
(b) Upstream reservation Figure 6. Procedures of successful end-to-end reservation setup
6.1.1.
Downstream reservation
When RSVP_Path message from a sender arrives, AP needs to enforce admission controls for both WLAN and wired network. Based on the available bandwidth of the
wireless channel, WBM admits the flow by allocating bandwidth for the flow, or rejects the reservation because of the unavailability of the resources. If the flow can not be satisfied in WLAN, AP just gives up the reservation. Otherwise, AP checks whether the outgoing link supports the requested rate. AP initiates reservation request and sends RSVP_Resv to the sender only when admission controls in both WLAN and wired network succeed. If all the intermediate routers along the path from AP to the sender approve the reservation, the sender may send RSVP_ResvConf back to AP, indicating the success of the whole reservation procedure. If RSVP_ResvConf has not been received after a certain time period, AP times out and removes the local information of the flow. An interesting feature of this procedure is that since WBM delegates all admission control decisions for MHs in the same cell, no extra overhead is put to wireless receivers, making the protocol quite efficient.
6.1.2.
Upon receipt of the WRESV_REQUEST from a MH, WBM checks if the flow can be admitted immediately. If the reservation request cannot be supported in the WLAN, then it is not necessary to send RSVP_Path to the destination. On the other hand, if enough bandwidth is available in WLAN, there is still no guarantee that QoS requirements of the flow can be supported in the wired network. Therefore, reserving bandwidth for the flow at this time may take the risk of incorrectly denying future flows. However, it is still not safe to reserve bandwidth for a flow even after AP receives RSVP_Resv, i.e., the success of the reservation in wired network. WBM has to enforce admission control again to make sure that bandwidth availability does not change during the time interval between sending RSVP_Path and receiving RSVP_Resv at AP. Although certain overhead is involved in checking bandwidth availability, this technique can effectively avoid unnecessary signaling and thus saves wireless bandwidth.
Upstream reservation
6.2. Support of multicast session When WRESV_REQUEST message from the sender MH arrives at AP, AP obtains the session id and maps the QoS specific parameters such as mean/maximum data rate in WRESV_REQUEST. Then, the AP sends RSVP_Path to wired receivers along the path selected by a specific routing protocol. Due to some possible errors, RSVP_PathErr may be sent from receiver or an intermediate router to AP. In this case, no reservation request is received at the AP. After some time, AP times out and may send RSVP_PathTear message to the receiver to remove all the path states. Note that the reservation messages outside of the wireless LAN is processed by RSVP/SBM agents located at intermediate routers. Thus, as far as AP is concerned, it receives two messages, RSVP_Resv or RSVP_ResvTear, indicating the success or failure of the corresponding flow reservation in the wired network, respectively. According to the type of message received, the AP acts as follows. • If a RSVP_Resv is received, WBM enforces the admission control in the wireless LAN. If it is successful, AP maps the necessary information in the reservation message and sends WRESV_RESPONSE to the sender with result field being 1. At the same time, AP sends RSVP_ResvConf back to the receiver for the confirmation of the reservation. • If WBM rejects the reservation in WLAN, AP sends WRESV_RESPONSE to the sender (with Result field being 0) and also RSVP_ResvTear to the receiver to remove all soft states stored in intermediate routers and receivers in the wired network. Then, the sender may try to make reservation some time later. Optimization: An optimization, named dual admission technique, can be made for reservation of upstream flows.
For RSVP to support QoS of a multicast session, a host sends IGMP messages to join a multicast group and then sends RSVP messages to reserve resources along the delivery path(s) of that group. Reservation requests from next hop routers for the same multicast session are merged at intermediate routers. With RSVP-WRESV integration, support of multicast is very straightforward. We discuss the following situations according to locations of receivers of a multicast session. (1) All receivers are in the wired network If the sender is also in the wired network, then this multicast session can be taken care by RSVP/SBM alone. Otherwise, as discussed above, AP acts as the proxy for the wireless sender. Thus, all reservation requests from receivers are merged at AP and the WBM then enforces admission control according to the final merged reservation message. Since this merging is handled at the network and upper layer by RSVP/SBM, the multicasting is actually managed by RSVP/SBM no matter where the sender is. (2) All receivers are in the wireless network Due to the broadcast nature of wireless LAN, an AP only makes admission control decision for a specific multicast group upon the reception of the first “join group” request. If the request is accepted, any subsequent “join group” request will be automatically accepted by the AP. If the reservation succeeds, AP shall multicast to all the senders after receiving the multicast data packets. All wireless stations subscribing the multicast group will decode the packets by matching the session id.
(3)
Some receivers are in the wired network, others are in the wireless network.
This is actually the combination of the previous two cases. Thus, we can classify the receivers and handle it accordingly with the methods discussed above separately. In above discussion, if AP is the sender/receiver, then reservation is established in either wireless side or wired side, depending on where the receivers are located. However, no cross-boundary integration is necessary.
then target AP sends WRESV RESPONSE message with result of 1. Also, target AP sends an Inter-access-point protocol (IAPP or IEEE std 802.11f [25]) message to request the home AP to forward all data belong to the MH to it. For the MH, if its handoff request is accepted, it will be associated with the target AP. Otherwise, the call is dropped.
7. Handoff support and QoS Re-negotiation In WLAN, MHs may move between BSSs and transfer its associated AP from one cell (home cell) to another cell (target cell), which is called horizontal hand-off. Usually, handoff is made based on signal to noise ratio (SNR) at a MH. However, it is possible that a MH may move from a less crowded cell to a more crowded cell and its QoS requirements are no longer satisfied, leading to serious performance degradation. Therefore, support of mobility in the context of QoS in WLAN imposes another important concern of whether or not to move into a new cell for smooth handoff. Furthermore, due to high channel error rate and node mobility, the link condition may not be very stable and the estimated channel available bandwidth may vary by certain amount. In this case, it is possible that bandwidth requirements of admitted flows can no longer be satisfied. Therefore, QoS re-negotiation is necessary. Therefore, in addition to RSVP-WRESV integration, support of smooth handoff and QoS re-negotiation is also required to provide ubiquitous end-to-end QoS guarantee.
7.1. Support of smooth handoff To prevent QoS degradation when a node moves to a new cell, two measures are taken as follows. First, we reserve a fixed amount of channel available bandwidth (15-20%) for handoff to minimize handoff blocking probability. The actual proportion depends on the frequency of node mobility and traffic load. Second, admission control is enforced every time a node moves into a new cell with ongoing traffic. Within the proposed framework of RSVP-WRESV integration, support of mobility is quite straightforward. The operation of hand-off in our reservation scheme is illustrated in Figure 7. When a MH intends to move into a target cell which has the highest SNR, it initiates an uplink end-to-end reservation to the gateway router by sending a WRESV_HANDOFF to the AP of the target cell (target AP) along with the identity of its home AP. The rest of the processing is exactly the same as the one described in Section 6.1.2. If the reservation is successful,
Figure 7. Illustration of the handoff procedure From a mobile user’s perspective, it is desirable to have very low handoff latency. Basically, handoff latency is composed by probe delay, authentication delay, and reassociation delay. To reduce the handoff delay, one can use selective scanning and AP caching to accelerate the probing process [19]. However, study of handoff delay reduction is out of the scope of this paper.
7.2. QoS re-negotiation There may be several possible approaches for renegotiation. We take a threshold based scheme to handle QoS re-negotiation as follows. AP allocates a small portion of bandwidth Bmin (100Kbps in our case). When AP notices that available bandwidth decreases below Bmin, it does not grant any new flow transmission. If available bandwidth drops below 50% of Bmin, then AP sends a message to the source of the most recently initiated flow and requests it to transmit with the minimum data rate. If available bandwidth becomes zero, then a flow has to be dropped or transferred to a neighboring cell. Since AP estimates its bava every second, the experienced available bandwidth decrease should be caused by flows initiated in the BSS during the last second. Therefore, AP looks up the reserved flow list, chooses the most recently initiated flows as candidates, and then requests it to handoff. When a MH receives a request for handoff, it shall follow the procedure described in Section 7.1. If the handoff fails, the MH notifies the AP and drops the flow. Then, AP removes the corresponding flow from the reserved flow list and takes action under following two situations: • If the flow sender is in wired network, AP sends a RSVP_ResvTear to the sender, which will leads to the removal of all soft states of the dropped flow stored in all intermediate routers.
ns-2 network simulator is used to validate the proposed scheme with appropriate modifications. The physical channel bandwidth for wireless LAN is set to be 2Mbps and it is assumed that each station only initiates one flow at a time. For each wired link, the bandwidth is set to 2Mbps with delay of 2ms. In our simulations, we evaluated the proposed RSVP-WRESV integrated protocol with node mobility. The following performance metrics are measured: • Throughput: the amount of data successfully received per second for a flow. The higher the throughput, the better the bandwidth satisfaction is. • Packet delay: the end-to-end transmission latency per packet. For delay-constrained real-time flows, the lower the packet delay, the better the QoS of a flow is. • Overall delivery ratio: the percentage of successfully transmitted packets among all packets transmitted by all senders. We use overall delivery ratio to show the performance of all real-time flows on average. • New call blocking rate: the percentage of rejection ratio for all new flow reservation requests. • Handoff call blocking rate: which is the percentage of rejection occurs when a MH attempts to move into a different BSS with an ongoing flow. Our simulation results are discussed as follows. In Section 8.1, we evaluate the performance of RSVPWRESV in a single BSS where node mobility is not introduced. In Section 8.2, we focus on the performance evaluation of node mobility in an ESS under the existing protocol and the proposed scheme.
Throughput (Kbps)
8. Performance evaluation
Throughput vs Time 200 150 100 BASIC RSVP-WRESV
50 0 10
20
30
40
50
60
50
60
Time (s)
(a) Throughput Packet delay vs Time 0.06 Packet delay (s)
If the flow sender is in wireless LAN, AP sends a notification to the corresponding MH, which silently gives up the data transmission of the flow.
RSVP-WRESV
0.05 0.04 0.03 0.02 0.01 0 10
20
30
40 Time (s)
(b) Packet delay with RSVP-WRESV Packet delay vs Time 1 Packet delay (s)
•
BASIC
0.8 0.6 0.4 0.2 0 10
20
30
40
50
60
Time (s)
8.1. RSVP-WRESV integration In this simulation, we compared the performance of the proposed RSVP-WRESV integration scheme with the BASIC case of a wired-cum-wireless network without admission control enforced. We use CBR flows with packet size of 800 bytes. Bit-rates for real-time and besteffort flows are of 160Kbps and 40Kbps, respectively. All senders are located in a wireless LAN and send packets to a common wired node through their AP. Initially, five background best-effort flows exist in the network, and then from 15 second, a new real-time flow is introduced every 3 seconds to gradually increase the traffic load. The duration of the simulation is 60 seconds. Only real-time flows need admission control.
(c) Packet delay without RSVP-WRESV Figure 8. Throughput and packet delay of an individual real-time flow We first measured the overhead of signaling in our protocol for flow reservation and admission control. In our simulation, the average reservation delay is around 10ms, even when the channel is approaching saturation. Note that this reservation delay includes the round-trip delay the source to the AP, then to the destination. Therefore, per-flow overhead is acceptable. When network is saturated, all reservation requests from wireless senders are rejected at AP, and the error messages are returned immediately without going through the wired part. In this case, the signaling overhead is even smaller. The throughput and mean delay of the first real-time flow are depicted in Figure 8. We can see that when the
number of real-time flows increases, the network traffic keeps increasing without admission control. At 34 to 37 seconds, the network reaches saturation status. With the large traffic load, the BASIC scheme cannot effectively protect real-time flows. On the other hand, with the proposed RSVP-WRESV scheme, real-time flows maintain satisfactory performance in terms of high throughput and low delay due to the rejection of new flows at time of 31 second. With RSVP-RESV, the packet delay is always below 50ms, which is very desirable. On the contrast, under the BASIC scheme, packet delays become more than 100ms at 35 second and even several seconds after 40 seconds. The reason for this large delay is that when the network reaches saturation, nodes contend for channel access seriously and a lot of channel collision happens, leading to large backoff time and MAC layer packet retransmissions. Overall delivery ratio
Delivery ratio (%)
120% 100% 80% 60%
BASIC
40%
RSVP-WRESV
20% 0% 0
2
4
6
8
10
12
Number of real-time flow s
Figure 9. Overall delivery ratio of real-time flows We also calculated the overall delivery ratio of all real-time flows. Here the number of real-time flows varies from 1 to 12. We can see from Figure 9 that after admitting 6 flows (corresponding to a total of 1.16Mbps traffic load, including best-effort flows), the network is not able to support more real-time flows. However, without RSVP-WRESV, all new flows are allowed to enter the wireless LAN. As a result, the delivery ratio decreases as the network is saturated. With 12 real-time flows, only 63% packets are successfully received, which may not be tolerable for bandwidth constrained multimedia applications and very inefficient in terms of the use of network resource.
8.2. Support of user mobility
Figure 10. Arrangement of BSSs To study the mobility, an ESS is formed with seven APs, as shown in Figure 10. The distance of any two adjacent APs is 400 meters. APs are connected by wired backbone. For each cell, a different wireless channel is allocated so that data transmissions in different BSSs do not interference with each other. The transmission range of all MHs and APs is set to 250 meters. Initially, 40 mobile hosts are randomly distributed in the area. Then, each MH moves according to way-point random walk model with maximum speed of 5m/s and pause time of 10s. MHs start sending CBR flows to a common gateway router through their associated APs every 15 seconds so that new flows are introduced throughout the simulation. Flow rates are 80Kbps, 120Kbps, 160Kbps, and 200Kbps with ratio of 1:1:1:1. The duration of the simulation is 1000 seconds for all cases. First, we run the simulation without RSVP-WRESV handoff support. In this case, MHs move among cells freely without being blocked and there are totally 113 handoffs. The number of handoffs for each MH varies from 0 to 10, depending on the mobility pattern of a MH and the time when its flow is initiated. By monitoring the channel availability at APs, we found that out of these 113 handoffs, 32 of them cannot be supported with enough available bandwidth, indicating the necessity of enforcing admission control at the time of the handoff.
Table 1. New call blocking rate and handoff call blocking rate Reserved bandwidth for handoff (Kbps) 0 100 200 300 Number of new flow rejections 0 2 4 6 New call blocking rate 0% 5% 10% 15% Number of handoffs 82 84 86 86 Number of handoff rejections 14 11 9 7 Handoff blocking rate 17% 13.1% 10.5% 8.1%
400 7 17.5% 88 5 5.7%
Throughput (Kbps)
120 80 40 0 200
400 600 Time (s)
Throughput (Kbps)
160 120 80 40 0 0
200
400 600 Time (s)
800
1000
800
1000
(a) Without RSVP-WRESV Throughput vs Time 200 160 120 80 40 0 0
200
400 600 Time (s)
(b) With RSVP-WRESV Figure 12. Performance of MH 10
9. Conclusion
Throughput vs Time 160
0
Throughput vs Time 200
Throughput (Kbps)
Then, we calculated the new call blocking rate and the handoff call blocking rate with the proposed RSVPWRESV framework. Here we vary the reserved bandwidth for handoff at each AP as 0, 100, 200, 300, and 400 Kbps, respectively. The corresponding results are shown in Table 1. We can see that with the increase of the reserved bandwidth for handoff, new call blocking rate increases due to less available bandwidth allocable to new flows. On the other hand, handoff blocking rate decreases with the increase of reserved bandwidth for handoff due to more resources available at the time when handoffs occur. When there are 400 Kbps available bandwidth reserved for flow handoff, only 5.7% handoffs are blocked. In addition, with higher handoff call blocking rate, total number of handoffs slightly increase due to more node mobility. Next, we measured the performance of MH 13 that moves most frequently and makes a total of 10 handoffs. The throughput MH 13 receives over time is depicted in Figure 11. We can see that as it moves, MH 13 may enter a BSS with high traffic and thus experiences significant performance degradation. Especially at time of 681 second and 859 second, it enters BSS 0 and receives only about 50% throughput thereafter before it moves out. Notice that with our configuration of BSSs, more handoffs occur at the boundary of BSS 0 than at boundaries of other BSSs. Under RSVP-WRESV, flow 13 is blocked at time of 329 second when it moves into BSS 0, which is already saturated then.
800
1000
Figure 11. Performance of the flow with most frequent handoffs Finally, we show the improvement of RSVP-WRESV over BASIC on supporting seamless node mobility. In Figure 12a, flow 10 experiences significant performance degradation without RSVP-WRESV, especially after it moves into BSS 0 at 574 second. However, it can be seen from Figure 12b that with RSVP-WRESV, even though MH 10 makes five handoffs (the first vertical line indicates the start of the flow), its throughput is well supported. Therefore, the proposed scheme does provide QoS guarantee in heterogeneous wired/wireless networks with node mobility.
Wireless users accessing Internet often require QoS guarantees from both the wireless and wired network. To address this issue, we propose WRESV, a general flow reservation and admission control scheme for IEEE 802.11 wireless LANs, and investigate the integration of RSVP-WRESV. The proposed integration scheme considers both features of RSVP and the characteristic of wireless medium, thereby efficiently supporting multicast session as well as node mobility. With cross-layer interaction, overhead of message mapping at the boundary of the wired and wireless network is significantly reduced. Extensive simulation results show that the proposed framework can provide sufficient QoS support for realtime flows in heterogeneous wired/wireless networks.
10. References [1] A. Banchs, X. Pérez, “Providing throughput guarantees in IEEE 802.11 wireless LAN,” in Proceedings of IEEE WCNC, Vol. 1, pp. 130-138, 2002. [2] M. Barry, A. T. Campell, A. Veres, “Distributed control algorithms for service differentiation in wireless packet networks,” in Proceedings of IEEE INFOCOM 2001.
[3] M. Benveniste, G. Chesson, M. Hoeben, A. Singla, H. Teunissen, M. Wentink, “EDCF proposed draft text”, IEEE working document 802.11-01/13lrl, March 2001. [4] G. Bianchi, F. Borgonovo, A. Capone, L. Fratta, C. Petrioli, “PCP-DV: An End-to-End Admission Control Mechanism for IP Telephony”. IWDC 2001, pp. 470-480, Taormina, Italy, September 2001. [5] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, “An Architecture for Differentiated Service”, RFC 2475, December 1998. [6] R. Braden, D. Clark, S. Shenker, “Integrated Services in the Internet Architecture: an Overview”, RFC 1633, June 1994. [7] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin, “Resource Reservation Protocol (RSVP)-Version 1 Functional Specification”, RFC 2205, September 1997. [8] K. Chen, S. H. Shah, K. Nahrstedt, "Cross-Layer Design for Data Accessibility in Mobile Ad hoc Networks", Journal of Wireless Personal Communications, Vol. 21, pp. 4975, 2002. [9] L. Delgrossi and L. Berger, “Internet Stream Protocol Version 2 (ST2) Protocol Specification - Version ST2+”, RFC 1819, August 1995. [10] J. A. García-Macías, F. Rousseau, G. Berger-Sabbatel, L. Toumi, A. Duda, “Quality of Service and Mobility for the Wireless Internet”, Wireless Networks, Vol. 9, pp. 341-352, 2003. [11] A. Ghanwani, W. Pace, V. Srinivasan, A. Smith, M. Seaman, “A Framework for Integrated Services Over Shared and Switched IEEE 802 LAN Technologies”, RFC 2816, May 2000. [12] P. J. M. Havinga, G. Wu, “Wireless Internet on Heterogeneous Networks”, In Proceedings of Workshop on Mobile Communications in Perspective, Enschede, the Netherlands, February 2001. [13] M. Kazantzidis, M. Gerla, S.-J. Lee, “Permissible throughput network feedback for adaptive multimedia in AODV MANETs,” in Proceedings of IEEE ICC’01, Vol. 5, pp. 1352-1356, June 11-14, 2001. [14] B. Moon and A. H. Aghvami, "Quality of Service Mechanisms in All-IP Wireless Access Networks," IEEE Journal on Selected Areas in Communications, Vol.22, No.5, pp.873 -888, June, 2004.
[15] S. Park, K. Kim, D. C. Kim, S. Choi, S. Hong, "Collaborative QoS Architecture between DiffServ and 802.11e Wireless LAN," in Proc. IEEE VTC'03-Spring, Jeju, Korea, April 2003. [16] K. Sanzgiri, I. D. Chakeres and E. M. Belding-Royer, "Determining Intra-Flow Contention along Multihop Paths in Wireless Networks". In Proceedings of Broadnets 2004 Wireless Networking Symposium, San Jose, CA, October 2004. [17] S. H. Shah, K. Chen, K. Nahrstedt, “Dynamic bandwidth management for single-hop ad hoc wireless networks,” in Proceedings of PerCom’03, Fort-Worth, Texas, 2003. [18] S. Shankar, S. Choi, "QoS Signaling for Parameterized Traffic in IEEE 802.11e Wireless LANS," Lecture Notes in Computer Science, vol. 2402, pp. 67-84, August 2002. [19] S. Shin, A. Forte, A. Rawat, H. Schulzrinne, "Reducing MAC Layer Handoff Latency in IEEE 802.11 Wireless LANs", In Proceeding of ACM MobiWAC, 2004. [20] A. Talukdar, B. R. Badrinath, A. Acharya, “MRSVP: A reservation protocol for an Integrated Services Packet Networks with Mobile hosts," Wireless Networks, Vol. 7-1, pp. 5-19, 2001. [21] C. Tseng, G-C Lee and R-S Liu, “HMRSVP: A Hierarchical Mobile RSVP Protocol,” ACM Wireless Networks, Vol. 9, No. 2, pp. 95-102, 2003. [22] S. Valaee, B. Li, “Distributed call admission control in wireless ad hoc networks,” in Proceedings of IEEE VTC, Vancouver, September, 2002. [23] R. Yavatkar, D. Hoffman, Y. Bernet, F. Baker, M. Speer, “SBM (Subnet Bandwidth Manager):A Protocol for RSVPbased Admission Control over IEEE 802-style networks”, RFC2814, May 2000. [24] H. Zhu, M. Li, I. Chlamtac, B. Prabhakaran, "Survey of Quality of Service in IEEE 802.11 Networks", IEEE Wireless Communications, Special Issue on Mobility and Resource Management, Vol. 11, No. 4, August 2004, pp. 614. [25] IEEE 802.11F-2003: IEEE Trial-Use Recommended Practice for Multi-Vendor Access Point Interoperability via an Inter-Access Point Protocol Across Distribution Systems Supporting IEEE 802.11 ™ Operation, June 2003.
