2003 Kluwer Academic Publishers. Manufactured in The Netherlands.
HMRSVP: A Hierarchical Mobile RSVP Protocol
CHIEN-CHAO TSENG∗, GWO-CHUAN LEE and REN-SHIOU LIUDepartment of Computer Science and Information Engineering, National Chiao Tung University, Hsin-Chu, Taiwan 30050, ROC TSAN-PIN WANG
Department of Computer Science and Information Management, Providence University, Sha-Lu, Taiwan 43309, ROC
Abstract. In this paper, we propose a hierarchical Mobile RSVP (HMRSVP) that can achieve mobility independent QoS-guaranteed
services in mobile computing environments. The HMRSVP integrates RSVP with Mobile IP regional registration and makes advance resource reservations only when an inter-region movement may possibly occur. We first show that, by NS simulator, our HMRSVP can achieve the same QoS guarantees as MRSVP does with fewer resource reservations. Then, we show that HMRSVP outperforms MRSVP in terms of reservation blocking, forced termination and session completion probabilities.
Keywords: mobile IP, RSVP, MRSVP, quality of services
1. Introduction
ReSource reserVation Protocol (RSVP) [2,11] is a protocol that can provide QoS guarantees for integrated services on the Internet. However, RSVP cannot be used directly in a mobile computing environment for the following two reasons. First, RSVP messages are invisible to the intermediate routers of the IP tunnel used in Mobile IP [7] because the IP tunnel is im-plemented using an IP-in-IP encapsulation scheme. Second, after a mobile host moves to a new location, the previously allocated resources are no longer available.
Some schemes have been proposed to resolve the mo-bility impact on RSVP in mobile computing environments. The RSVP Tunnel [11] was proposed to resolve the RSVP signaling invisibility problem. The RSVP Tunnel does not support seamless handoffs for QoS guarantees due to the lack of advance reservations in a neighborhood. Mobile RSVP (MRSVP) [9,10] overcomes the handoff impact of mobility on RSVP by making advance resource reservations in all neighboring subnets. However, these excessive re-source reservations may demand too much bandwidth and de-grade the network performance. In this paper, we propose a new Mobile RSVP Protocol – a hierarchical Mobile RSVP (HMRSVP) that can achieve the same QoS-guaranteed seam-less handoff as MRSVP does but makes fewer advance re-source reservations. HMRSVP adopts the hierarchical con-cept of Mobile IP regional registration [5] and makes advance resource reservations for a mobile host only when the mobile host resides in the overlapped area of the boundary cells be-tween two regions. To measure the performance of our pro-posal, we compare the HMRSVP performance with that of MRSVP in terms of data transmission rate, reservation block-ing, forced termination and session completion probabilities using simulations. Numerical results show that HMRSVP, compared with MRSVP, reduces the reservation blocking and ∗Corresponding author.
forced termination probabilities by 50% and 27%, respec-tively, when the offered load is 0.6. They also show that HMRSVP improves the session completion probability by more than 8% if the load is larger than 0.6.
The rest of this paper is organized as follows. In section 2, we discuss the mobility impact on RSVP in mobile environ-ments. In section 3, we introduce the related research: RSVP Tunnel and MRSVP. The HMRSVP scheme is proposed in section 4. Section 5 presents our simulation models and re-sults. Finally, we make some conclusions in section 6.
2. Mobility impacts on RSVP
RSVP is a signaling protocol for Internet resource reserva-tions. Two types of messages, PATH and RESV, are used in RSVP to setup resource reservation states on the nodes along the path between a sender and a recipient. Initially, the sender learns the IP address of the recipient using some out-of-band mechanism and sends a PATH message to the cipient to find a path all the way from the sender to the re-cipient for a specific flow. When a router receives a PATH message, it will record which upstream router the PATH mes-sage was received from and forwards the PATH mesmes-sage to a downstream router. The PATH message is then passed from one to another downstream router and finally received by the recipient. The recipient will respond with a RESV message to make a resource reservation for the specific flow. The RESV message will be transmitted in reverse along the same path as the PATH message was originally transmitted. Upon re-ceiving a RESV message, each router or host on the path will reserve resources for the specific flow if sufficient resources are available. However, two mobility impacts occur on the original RSVP signaling protocol.
First, RSVP is not aware of mobility. According to the original RSVP signaling protocol, the resource reservation path cannot be dynamically adapted along with the
move-ment of a mobile host. In other words, once a mobile host (MH) handoffs to a new region, its prior reserved resources are no longer available and the service quality of the MH may degrade significantly due to the lack of resources reserved for the MH in the new region. Second, IP-in-IP makes RSVP messages invisible. Mobile IP uses an IP-in-IP encapsulation technique [6] to route IP packets correctly to an MH that is away from its home network. If the RSVP protocol is applied, RSVP messages, PATH and RESV, will be encapsulated in an IP-IP encapsulated packet with a protocol number as in-teger 4 in the outer IP header, concealing the original RSVP protocol number 46 in the inner IP header. As a consequence, the routers on the path of an IP tunnel cannot correctly recog-nize RSVP signals to provide the required QoS.
3. Related research
In this section, we address two important technologies, RSVP Tunnel and MRSVP, proposed to resolve the mobility impact on RSVP in mobile environments.
3.1. RSVP Tunnel
Terzis et al. [12] proposed RSVP Tunnel to resolve the RSVP message invisibility problem. The underlying principle of RSVP Tunnel is to establish nested RSVP sessions between the tunnel end-points, namely entry and exit points. That is, an extra pair of tunnel PATH and RESV messages, with-out encapsulating IP headers, is sent to establish a QoS-guaranteed communication path between the tunnel entry and exit points.
Initially, a sender issues an end-to-end PATH message, which records the addresses of the sender and recipient in its IP header with the RSVP protocol number 46. When the end-to-end PATH message is delivered to the tunnel entry point, it is encapsulated with a new IP header, which records the ad-dresses of the tunnel entry and exit points with the Mobile IP protocol number, 4. The tunnel entry point, after sending the encapsulated end-to-end PATH message, issues a new tunnel PATH message which records the addresses of the tunnel en-try and exit points with the RSVP protocol number 46. On receiving the encapsulated end-to-end PATH message, each router on the path of the tunnel directly forwards the mes-sage downstream to the exit point. However, on receiving the tunnel PATH message, each router performs the path-finding function as described in the original RSVP protocol because the RSVP protocol number 46 is visible in this mes-sage. When these tunnel and encapsulated end-to-end PATH messages arrive at the exit point, the encapsulated end-to-end PATH message will be decapsulated and forwarded to the re-cipient, while the tunnel PATH message will be processed only by the exit point and need not be forwarded to the recip-ient. In response, the recipient, on receiving the end-to-end PATH message, replies an end-to-end RESV message to the sender. In a similar way, when the tunnel exit point receives the end-to-end RESV message, it will tunnel the message to
the sender as described before. In addition, the tunnel exit point will also issue a tunnel RESV message to the tunnel en-try point. Thus, all routers on the tunnel path, when receiving the tunnel RESV message, can reserve the desired resources for the recipient if sufficient resources are available.
Using the above nested RSVP session, RSVP Tunnel can actually resolve the RSVP signaling invisibility problem. However, it does not make advance resource reservations in its neighboring networks. Therefore, if an MH moves to a new foreign region, the MH’s service may be terminated be-cause of the lack of resources in the new region.
3.2. MRSVP
Mobile ReSource reserVation Protocol (MRSVP) was pro-posed by Talukdar [9,10] to achieve the desired mobility in-dependent service guarantees in Integrated Services Packet Networks [3] with real-time multimedia applications. The MRSVP protocol makes advance resource reservations at multiple locations where an MH may possibly visit during the service time. The MH can thus achieve the required ser-vice quality when it moves to a new location where resources are reserved in advance. We describe the MRSVP protocol as follows.
Just as Mobile-IP protocol requires mobility agents to aid in routing, MRSVP requires proxy agents to make re-source reservations for the MHs. A proxy agent is said to be a local proxy agent if it is collocated within the loca-tion where an MH currently visits, or a remote proxy agent if it is within the MH’s neighboring subnetwork. The local and remote proxy agents are recorded in a Mobility Specifi-cation (MSPEC). The MSPEC indicates the set of loSpecifi-cations where an MH may possibly visit in the near future. When a recipient MH moves to a new location, it needs to search all of the proxy agents in its neighborhood and then update MSPEC using a Proxy Discovery Protocol [10]. The updated MSPEC is sent as a Receiver_MSPEC message to the sender that initializes the flow to the recipient MH. By examining the Receiver_MSPEC message, the sender can obtain the lo-cations where the recipient MH may possibly visit. In ad-dition, the recipient MH sends a Receiver_SPEC message to all remote proxy agents recorded in MSPEC. These remote proxy agents can thus retrieve the QoS-guaranteed parame-ters for the recipient MH’s services. Through the exchange of a pair of PATH and RESV messages between the sender and recipient, an active resource reservation can be built from the local proxy agent of the sender to the local proxy agent of the recipient. Several passive resource reservation paths are then built from the remote proxy agents of the sender to the remote proxy agents of the recipient.
An active reservation is the path on which packets are ac-tually transmitted, whereas passive reservation paths are only reserved in advance without any actual packet flows. When the MH moves to a new location, MRSVP changes the passive reservation of the new visited location into an active state and the original active reservation is altered into a passive state at the same time. In this way, the needed resources for the
MH in the new region can be retrieved rapidly because the resources were preserved in the original passive reservation path. That is, a seamless handoff for QoS guarantees can be retained using the MRSVP protocol. However, MRSVP demands too much bandwidth in making advance resource reservations. This excessive resource waste may degrade sys-tem performance significantly.
4. Hierarchical MRSVP
The main idea behind our HMRSVP protocol is to integrate RSVP with a Mobile IP regional registration protocol and make advance resource reservations only when the handoff delay tends to be long.
In the base Mobile IP protocol, each time an MH moves, it must register with its home mobility agent (HA). In cases when the HA is far away, this registration process may be-come too expensive. The Mobile IP regional registration pro-tocol localizes the registration process within a region when an MH makes an intra-region movement [5]. A region refers to a cluster of routers or subnets encompassed by an enter-prise or campus network. Mobility Agents (MAs) in a region are arranged hierarchically according to its topology. Be-cause of the hierarchical nature and IP-routing properties of the Internet, foreign MAs can perform the registration process with some degree of independence from the HA and regis-trations for MH intra-region movements can thus be isolated within the region. The setup time for the resource reservation path for an intra-region handoff is normally short. Therefore, HMRSVP adopts the hierarchical concept of Mobile IP re-gional registration and makes advance resource reservations for an MH only when the MH visits the overlapped area of the boundary cells between two regions.
Figure 1 illustrates the resource reservation paths estab-lished in the HMRSVP scheme. The dark lines represent ac-tive resource reservation paths, while the dashed line repre-sents a passive resource reservation path. As shown in fig-ure 1(a), the MH is currently visiting a non-boundary cell MAi and we can presume that the MH will make only intra-region handoffs in the near future. Therefore, the HMRSVP only establishes an active resource reservation along the path from the sender to the MH without making any advance re-source reservations. In figure 1(b), when the MH enters the overlapped area of the boundary cells between two regions, the HMRSVP will establish an extra passive resource reser-vation along the path from the sender to the boundary cell MAk of the MH’s neighboring region. In this scenario, the HMRSVP establishes a passive reservation because the MH may make an inter-region movement into a new region. Un-like MRSVP, which establishes excessive passive reservations in all of the MH’s surrounding cells regardless which cell the MH is currently visiting, HMRSVP only makes an advance resource reservation in the MH’s neighboring boundary cell when the MH tends to perform an inter-region movement.
In the following subsections, we will explain our HMRSVP protocol in detail. For simplicity, we use a two-level
hi-(a)
(b) Figure 1. The hierarchical MRSVP scheme.
erarchical topology to illustrate the protocol flow of the HMRSVP.
4.1. Receiver is a mobile
Figure 2 illustrates a two-level hierarchy of cooperating proxy agents that can provide Mobile IP regional registration and hierarchical mobile RSVP services to mobile hosts. PR0 to
PR3 are the proxy agents of subnets CR0 to CR3, respec-tively. GMAR1 and GMAR2 are the top-level gateway mo-bility agents of an enterprise region. We assume that a mobile receiver MR initially resides in the foreign subnet CR1and a corresponding host CH is the data sender.
In our HMRSVP, two RSVP tunnels, one from CH to GMAR1and another from GMAR1to PR1, will be established along the RSVP reservation path from CH to MR. Initially, MR will send a Receiver_MSpec{GMAR1} message to inform CH that MR is visiting a subnet within the service area of GMAR1. From the Receiver_MSpec{GMAR1}, CH can learn that MR is currently away from the home region of MR. Therefore, the HMRSVP module1 of CH will intercept the end-to-end Active PATH message issued by the RSVP soft-ware of CH, and tunnel the message to GMAR1. In addi-tion, the HMRSVP module of CH will also send a tunnel Active PATH to initiate the reservation of the RSVP tunnel CH–GMAR1. On receiving the encapsulated end-to-end Ac-tive PATH message, GMAR1will re-tunnel the original end-to-end message to PR1. GMAR1will also send a tunnel Active 1The HMRSVP module could also be situated at a proxy agent that provides HMRSVP service to CH. Without loss of generality, we assume that CH is equipped with the HMRSVP functions.
Figure 2. MR makes an intra-region handoff.
PATH to initiate the reservation of the RSVP tunnel GMAR1–
PR1. PR1will then decapsulate the end-to-end Active PATH message tunneled from GMAR1 and forward the end-to-end Active PATH message to MR. MR will reply an end-to-end Active RESV message to CH through the tunnels of GMAR1–
PR1and GMAR1–CH.
When MR moves from the subnet CR1to the CR2, an intra-region handoff occurs. The registration message sent by MR is transmitted only up to GMAR1. On receiving the registra-tion message, the Mobile IP module of GMAR1informs the HMRSVP module of GMAR1that MR is moving to the sub-net CR2. The HMRSVP modules of GMAR1and PR2, by ex-changing an Active PATH and an Active RESV message, will establish a new RSVP tunnel between GMAR1and PR2. The original active reservation tunnel from GMAR1to PR1will be torn down after the new active RSVP tunnel, GMAR1–PR2, is established. The new reservation can be performed very quickly because PR1and PR2both reside within the same re-gion served by GMAR1.
If MR moves continuously from CR2toward to CR3, an inter-region handoff may occur as shown in figure 3. We as-sumed that MR can detect that it has moved into the over-lapped area of two boundary cells by some means [10] as soon as it moves into this area. When MR moves into the overlapped area of the boundary cells CR2 and CR3, it per-forms a home registration by sending a Multiple Simultaneous Registration to acquire a new care-of-address from PR3[5,8].
PR3will send this registration message to GMAR2, which will then forward this message to MR’s HA. The HA will add the GMAR2 care-of-address into the care-of-address list of MR and then return a Registration Reply message to GMAR2.
GMAR2will send this reply message to MR through PR3. MR then sends a Reciever_Spec message to inform PR3 of the original QoS parameters. In the meanwhile, MR also sends a Receiver_MSpec{GMAR1, GMAR2} message to inform CH that MR is visiting an overlapped area of the boundary cells of GMAR1 and GMAR2. On receiving the Receiver_MSpec message, CH tunnels an end-to-end Passive PATH to GMAR2
Figure 3. MR makes an inter-region handoff.
and GMAR2in turn re-tunnel the end-to-end Passive message to PR3. However, PR3will not forward the original end-to-end Passive PATH to MR. Instead, PR3 itself will return an end-to-end Passive RESV to CH through the two RSVP tun-nels GMAR2–PR3and GMAR2–CH. These two RSVP tunnels constitute a passive resource reservation path from CH to PR3. It should be noted that we could have reserved the passive reservation path between GMAR2and PR3at the time when the MR performs an inter-region handoff. However, we chose to make the passive reservation path GMAR2–PR3in advance because the CH–GMAR2path is reserved over the Internet and is more involved compared with the GMAR2–PR3intra-region path reservation. Moreover, the passively reserved resources of the intra-region path GMAR2–PR3 could be borrowed by other MHs currently visiting the region. The resource reser-vation borrowing policy will be explained later (section 5).
Assume that MR moves continuously toward subnet CR3 and MR changes its point of attachment to subnet CR3. The passive reservation path from CH to PR3will be changed to active, whereas the original active reservation path from CH to PR2will be altered to passive. If MR moves further toward subnet CR3and leaves the overlapped area of CR3and CR2, the passive reservation path on CR2will then be torn down.
4.2. Data sender is also a mobile
In this subsection, the operation of our HMRSVP is explained using a case when the data sender is also a mobile host, de-noted as MS in figure 4. As shown in figure 4, HMRSVP will establish three RSVP tunnels PS1–GMAS1, GMAS1–GMAR1, and GMAR1–PR1along the RSVP reservation path from MS to MR.
When MS moves from CS1to CS2, an intra-region handoff occurs. The registration message sent by MS is only trans-mitted through PS2to GMAS1. Again, only a new RSVP tun-nel will be established from PS2 to GMAS1, and the origi-nal reservation path from PS1to GMAS1will be torn down after the new PS2–GMAS1 RSVP tunnel has been estab-lished.
Figure 4. MS makes an intra-region handoff.
Figure 5. MS makes an inter-region handoff.
If MS moves continuously from CS2 toward to CS3, an inter-region handoff may occur, as shown in figure 5. When MS visits the overlapped area of the boundary cells CS2and
CS3of the regions GMAS1and GMAS2, respectively, it per-forms a home registration by sending a Multiple Simultane-ous Registration to HA through PS3and GMAS2. Upon re-ceiving a successful registration from MS’s HA, MS issues a Sender_Spec message and a Receiver_MSpec message to in-form PS3of the original QoS parameters and the proxy agent of MR, respectively. PS3then tunnels an end-to-end Passive PATH to GMAS2and GMAS2in turn re-tunnel the end-to-end Passive message to GMAR1. In this case, GMAR1is the end point of a passive RSVP tunnel because the resources on the path from GMAR1to PR1are already reserved in advance by the active reservation. In other words, the end-to-end Pas-sive PATH is only tunneled to GMAR1, which will then re-turn an end-to-end Passive RESV message to PS3through the two RSVP tunnels GMAS2–GMAR1and GMAS2–PS3. There-fore, only two new RSVP tunnels, PS3–GMAS2and GMAS2–
Figure 6. NS simulation topology.
GMAR1, will be established and these two RSVP tunnels con-stitute a new passive resource reservation path from PS3 to
GMAR1.
Assume that MS moves continuously toward subnet CS3 and MS changes its point of attachment to subnet CS3. The passive reservation path from PS3to GMAR1will be changed to active, whereas the original active reservation path from PS2to GMAR1will be altered to passive. If MS moves further toward subnet CS3and leaves the overlapped area of CS3and
CS2, the passive reservation path on CS2will be torn down.
5. Simulation models and numerical results
In this section, we present our simulation models and results. In our first experiments, the NS network simulator proposed by U.C. Berkeley [1,4] was used to estimate the data transmis-sion rates for the HMRSVP, MRSVP and RSVP approaches. Figure 6 depicts the simulation topology used in the NS sim-ulation. In this topology, we assume that the bandwidths of the links between all nodes are 5 Mbps and the transmission delays on the links from a CH, HA, or GMA to a router are all set to 25 ms. The link transmission delay between an MA and its parent GMA is 2 ms because GMA and MA1/MA2 are located in the same region.
Figure 7 shows the simulation results for the average data transmission rate using the HMRSVP, MRSVP and RSVP ap-proaches over simulation time. In this simulation, an MH is initially located at its home network during the time from 0 to 30 seconds. After 30 seconds of simulation time, the MH handoffs to a foreign subnet served by a mobility agent MA1 with a parent GMA. Later the MH moves around the sub-nets served by MA1 and another mobility agent MA2 with the same parent GMA, during the time from 30 to 130 sec-onds, and finally the MH goes back to its home network after 130 seconds. In the figure, we can observe that the MH can maintain a stable data transmission rate at 64 Kbps when the
Figure 7. Average data transmission rate.
Figure 8. 8× 8 mesh simulation model.
MH is at the home network regardless which approaches are applied. If the MH moves away from its home network and enters the foreign network served by the GMA, the average data transmission rate becomes unstable using the RSVP pro-tocol. This is because the RSVP protocol does not reserve re-sources in advance at the foreign network, and thus the service quality of the MH cannot be guaranteed. On the other hand, if the HMRSVP or MRSVP is applied, the data rate is al-ways stable at 64 Kbps except for the handoff time. This phe-nomenon shows that, although HMRSVP pre-reserves MH’s needed resources in advance only at the overlapped area of the boundary cells, it can still maintain a high QoS guarantee for the service quality of the MH as MRSVP does.
To measure the performance of the HMRSVP protocol, we used an 8× 8 wrapped-around mesh topology as shown in figure 8 to simulate a mobile computing environment with an unbounded number of regions. For simplicity, we only built a hierarchical infrastructure of two-tier agents. Each of the 8× 8 cells is served by an MA, and all 64 MAs are served by a GMA. When the MH moves left and away from the cell served by MA07, an inter-region handoff occurs and the MH will enter the cell served by MA77in a new region. Similarly, when the MH moves up and away from the cell served by MA70, an inter-region handoff occurs and the MH will enter the cell served by MA77in a new region.
The simulation parameters used in our model are as fol-lows.
• Reservation inter arrival time (1/λ). The reservation in-ter arrival time represents the average inin-ter arrival time for each RSVP session of an MH. We assume that the reserva-tion inter arrival time of a RSVP session is an exponential distribution with mean 1/λ.
• Reservation holding time (1/µ). The reservation holding time represents the average holding time for each RSVP session of an MH. We assume that the reservation holding time of a RSVP session is an exponential distribution with mean 1/µ.
• Capacity (C). The capacity C represents the average total number of available RSVP sessions supported by a cell. • Average number of MHs per FA (N). N represents the
average number of MHs visiting a cell.
• Offered load (ρ). ρ represents the system offered load for a cell, and thus it is equal to N λ/Cµ.
• Reservation blocking probability (Pb). Pbrepresents the probability that a failure occurred when an MH wishes to create a new active reservation for a RSVP session. • Forced termination probability (Pf). Pf represents the
probability that an active reservation can not be success-fully made and the reservation is forced to terminate when an MH handoffs to a new cell.
• Session completion probability (Pc). Pc represents the probability that an MH can make an initial active reser-vation for a RSVP session and can complete the session successfully regardless how many cell-handoffs the MH makes during the connection time.
We present the performance results by comparing the reser-vation blocking, forced termination and session comple-tion probabilities of the MRSVP and HMRSVP schemes with/without an enhanced management policy on the re-sources that have been reserved by a passive resource reser-vation. The underlying principles behind the resource man-agement policy are illustrated as follows.
• The passively reserved resources, i.e., resources which are passively reserved by other MHs in the neighboring re-gions, of a region can be borrowed by the MHs visiting the region currently. The resources borrowed by an MH in a region should be returned when the original owner of the borrowed resources is about to handoff to the region. • If an MH makes its active resource reservation by
bor-rowing the passively reserved resources from some MH in a neighboring region, the MH cannot make a passive resource reservation since the active resource reservation may be terminated at anytime.
Figures 9–11 show our simulation results in terms of reser-vation blocking, forced termination and session completion probabilities, respectively. In the figures, the curves denoted by HMRSVP-R and MRSVP-R stand for numerical results for the HMRSVP and MRSVP schemes with the enhanced management policy on the passively reserved resources.
Figure 9 illustrates the reservation blocking probabilities for the four resource reservation schemes under discussion.
Figure 9. Reservation blocking probabilities.
Figure 10. Forced termination probabilities.
When the offered load increases, the reservation blocking probability increases in all schemes. It is obvious that the greater the offered load, the lesser the available resources and thus the higher the reservation blocking probabilities. On the other hand, we can observe that the reservation blocking prob-ability of MRSVP is larger than that of HMRSVP. This is be-cause MRSVP reserves much greater resources in neighbor-ing regions than HMRSVP does, and thus the average num-ber of remaining resources in the MRSVP decreases. As a consequence, the reservation blocking probability of a new RSVP session will increase. Furthermore, from the blocking
Figure 11. Session completion probabilities.
probabilities of MRSVP-R and HMRSVP-R, we can observe that the resource management policy can effectively improve the blocking probabilities of both the MRSVP and HMRSVP schemes.
Figure 10 depicts the forced termination probabilities for the four resource reservation schemes under discussion. In general, the greater the resources reserved in advance in the MH’s neighboring regions, the higher the guaranteed QoS. However, the forced termination probability of the MRSVP is higher than that of the HMRSVP if the offered load is less than about 0.65 in our simulation. This is because if the of-fered load is small, the HMRSVP scheme, which does not re-serve resources in every neighboring region, will retain more available resources than the MRSVP does. When the load is larger than 0.65, the benefit of excessive advance reservations for the MRSVP scheme will be obvious. A similar phenom-enon can be also observed in that the forced termination prob-ability will decrease when we apply the resource management policy in both schemes.
The session completion probability is a combinational ef-fect of the reservation blocking probability and forced termi-nation probability. Figure 11 shows the session completion probabilities for the four resource reservation schemes. It is obvious that when the offered load increases, the session completion probability decreases in all schemes. We can fur-ther observe that HMRSVP outperforms MRSVP in terms of session completion probability. If the offered load is larger than 0.8, the session completion probability of the MRSVP scheme is lower than 60%. However, if the load reaches to 1.0, the HMRSVP scheme can still retain about 75% ses-sion completion. The reason is that HMRSVP can reduce the reservation blocking probability with less increase in forced termination probability. Similarly, if the reserved resource management policy is applied, the session completion proba-bility will also increase in both schemes. That is, even though
the offered load reaches 1.0, the session completion proba-bility of the MRSVP-R scheme can be maintained at about 75%.
From the phenomena mentioned above, we could conclude that HMRSVP outperforms MRSVP in terms of reservation blocking, forced termination and session completion proba-bilities. Only when the offered load is large, will the forced termination probability of HMRSVP be worse than that of MRSVP. Moreover, if the reserved resource management pol-icy is applied, we can improve the performances of both the HMRSVP and MRSVP schemes.
6. Conclusions
We proposed an HMRSVP protocol that can achieve mo-bility independent QoS-guaranteed services to support real-time mulreal-timedia applications in mobile computing environ-ments. Our HMRSVP integrates RSVP with the Mobile IP regional registration protocol and makes advance resource reservations only when an MH moves into the overlapped area of the boundary cells between two regions. The under-lying idea behind the HMRSVP is to reserve in advance only those resources which are likely to be used in the near future. Moreover, we also proposed a resource management policy to improve the performances of the HMRSVP and MRSVP protocols. The numerical results show that our HMRSVP could achieve not only the same QoS guarantees as MRSVP but also could outperform MRSVP in terms of reservation blocking, forced termination and session completion proba-bilities. However, there exist other factors that may affect the HMRSVP performance, such as the mobility rate of the MHs, the size of an overlapped area, the end-points of a pas-sive RSVP tunnel, the time to tear down a paspas-sive reservation path, etc. Therefore, we need to conduct more performance studies on the effectiveness of our HMRSVP scheme in the future.
Acknowledgement
This work was sponsored in part by the MOE Program of Excellent Research under contract 90-E-FA04-1-4.
References
[1] E. Amir, H. Balakrishnan et al., The network simulator ns-2 homepage, http://www.isi.edu/nsnam/ns(October 2000).
[2] R. Braden, L. Zhang, S. Berson, S. Herzog and S. Jamin, Resource ReServation Protocol (RSVP) version 1 functional specification, RFC 2205 (September 1997).
[3] D.D. Clark, S. Shenker and L. Zhang, Supporting real-time applications in an integrated services packet network: architecture and mechanism, in: Proc. of SIGCOMM’92 (1992).
[4] K. Fall and K. Varadhan, ns notes and documentations, http:// www.isi.edu/nsnam/ns/ns-documentation.html (Octo-ber 2000).
[5] E. Gustafsson, A. Jonson and Ch.E. Perkins, Mobile IP regional regis-tration, Internet-Draft: draft-ietf-mobileip-reg-tunnel-04.txt(March 2001).
[6] Ch.E. Perkins, IP encapsulation within IP, RFC 2003, Internet Engi-neering Task Force (October 1996).
[7] Ch.E. Perkins, Mobile IP Design Principles and Practices (Addison-Wesley, Reading, MA, 1998).
[8] Ch.E. Perkins, IP mobility support for IPv4, RFC 2002: draft-ietf-mobileip-rfc2002-bis-04.txt, Internet Engineering Task Force (February 2001).
[9] A.K. Talukdar, B.R. Badrinath and A. Acharya, Integrated services packet networks with mobile hosts: architecture and performance, Wireless Networks 5(2) (1999) 111–124.
[10] A.K. Talukdar, B.R. Badrinath and A. Acharya, MRSVP: a resource reservation protocol for an integrated services network with mobile hosts, Wireless Networks 7(1) (2001) 5–19.
[11] A. Terzis, J. Krawczyk, J. Wroclawski and L. Zhang, RSVP operation over IP tunnels, RFC 2746 (January 2000).
[12] A. Terzis, M. Srivastava and L. Zhang, A simple Qos signaling protocol for mobile hosts in the integrated services Internet, in: Proc. of IEEE
INFOCOM ’99 (1999).
Chien-Chao Tseng is currently a professor in the Department of Computer
Science and Information Engineering at National Chiao-Tung University, Hsin-Chu, Taiwan. He received his B.S. degree in industrial engineering from National Tsing-Hua University, Hsin-Chu, Taiwan, in 1981; MS and Ph.D. degrees in computer science from the Southern Methodist University, Dallas, Texas, USA, in 1986 and 1989, respectively. His research interests include mobile computing, and wireless Internet.
E-mail: [email protected]
Gwo-Chuan Lee is currently a Ph.D. candidate in the Department of
Com-puter Science and Information Engineering at National Chiao-Tung Univer-sity, Hsin-Chu, Taiwan. He received his B.S. degree in computer science and information engineering from National Chiao-Tung University, Hsin-Chu, Taiwan, in 1988; M.S. degree in computer science from National Taiwan University, Taipei, Taiwan, in 1990. His research interests include mobile computing, wireless Internet, and Java technology.
E-mail: [email protected]
Ren-Shiou Liu is currently an engineer in Acer Mobile Networks Inc.,
Hsin-Chu, Taiwan. He received his B.S. and M.S. degrees in computer science and information engineering from National Chiao-Tung University, Hsin-Chu, Taiwan, in 1998 and 2000.
E-mail: [email protected]
Tsan-Pin Wang is currently an Associate Professor in the Department of
Computer Science and Information Management at Providence University, Shalu, Taiwan. He received the B.S. degree in applied mathematics; M.S. and Ph.D. in computer science and information engineering, from National Chiao Tung University, Taiwan, ROC, in 1990, 1992, and 1997, respectively. From 1992 to 1993, he was a system engineer in the R&D Division of Taiwan NEC Ltd. From 1997 to 2001, he was an Assistant Professor at Providence University. His research interests include mobile computing, mobile commu-nications, and computer networks.
