In order to provide guaranteed quality of service for real-time applications in the next IP-based mobile networks, end to end resource reservation should be executed. Two IETF protocols, RSVP and QoS NSLP, have been devised for resource reservation. But both of them are developed without considering mobility management protocols. Tremendous previous works have been carried out to extend these protocols to improve the performance when they are used in IP-based mobility scenarios for resource

more »

... rvation. This survey provides a description and analysis of these previous works. We list some critical issues regarding resource reservation in IP-based mobility scenarios, and analyze the solutions proposed to address these issues. Also, we point out some opened issues that need to be resolved before resource reservation is widely used in mobility scenarios. have been carried out to extend RSVP to make it applicable in mobility scenarios. However, people found that, due to RSVP"s limitation, these extensions need to change the basic logic of RSVP, and they become more and more complex. This is why another signalling protocol, Next Steps in Signaling (NSIS), which has been developed by the IETF NSIS working group, considers the mobility characteristic for its QoS signaling. This protocol intends to design a signaling protocol which is more suitable for mobility scenarios, and will probably replace RSVP protocol. But it must be noted that this group addresses not only QoS signaling protocol, but also other signaling applications, such as firewall and NAT control [12] . The requirements and challenges of resource reservation for IP Mobility can be found in [1], [13] . In this paper, we give a survey that describes and analyses the previous works on reservation for mobility scenarios from the following aspects:  Interaction with mobility protocols,  Obsolete reservation release,  Reservation in advance,  Reservation aggregation. Also, we will discuss some related approaches (e.g. path-decoupled or pathcoupled) regarding resource reservation in mobility scenarios. Resource reservation protocols are developed independently of Mobile IP protocols. To adapt efficiently resource reservation protocols in mobility scenarios, the resource reservation protocol must interact with Mobile IP protocols. For example, Mobile IP protocol should inform the reservation protocol about the MN"s mobility status (e.g. a handover being impending, a handover being ended), so the reservation protocol can decide when to reserve resources for the MN"s next location. Another issue is, with Mobile IP, reservation protocol messages are invisible to intermediate routers of the IP tunnel between Home Agent (HA) and Foreign Agent (or MN) due to the IP tunnel encapsulation. Hence it is necessary for mobile IP to act differently regarding the reservation message than data packets [14] [15] . To improve the performance of mobile IP, some extensions, e.g. Hierarchical MIPv6 (HMIPv6) [17] and Fast MIPv6 (FMIPv6) [17] , have been proposed to manage the mobility more efficiently. It is desired to enable reservation protocol to work with these extensions. Another issue regarding resource reservation in mobility scenarios is to release obsolete reservations. Reservations for the MN"s current location become obsolete after its departure. These obsolete reservations should be released as quickly as possible. Otherwise, they would block other resource requests. It is relatively simple to release obsolete reservations in the cases where a reservation proxy performs reservations on behave of the MN, because the reservation proxy can be responsible for the obsolete reservation release [7], [19], [20]. In the case where the reservations are performed without the reservation proxy, it requires a new entity, often the CRossover Node (CRN) [1], [21] that is intersecting node between the old path and the new path, to take care of the obsolete reservation release. If the CRN is also incapable, a new method which resorts on reservation"s soft state mechanism can be used for this task [22] . To avoid service disruption after the MN"s handover, reservation for the MN"s next location should be performed before the arrival of the MN. This is called reservation in advance (or advance reservation), and which is a critical task in reservation for mobility scenarios. To do this, a simple method is to perform reservation on all MN"s neighbouring locations or all the locations that a MN is expected to visit [6][7]. However, this mechanism involves a tremendous waste of resources, because the advance reservation is not used before the MN moves to these locations. Hence, it is more acceptable to reserve resources only on a neighbouring location which will be probably visited [8]- [9] . Obviously, the latter