WO2006015614A1

WO2006015614A1 - Providing mobility to a mobile host in a network employing point-to-multipoint multi-protocol label switching

Info

Publication number: WO2006015614A1
Application number: PCT/EP2004/009112
Authority: WO
Inventors: Genadi Velev.; Tetsuya Kawakami
Original assignee: Matsushita Electric Industrial Co., Ltd.
Priority date: 2004-08-13
Filing date: 2004-08-13
Publication date: 2006-02-16
Also published as: EP1776806A1; CN101002437A

Abstract

A method is provided ensuring mobility to a mobile host in a wireless network with point to multipoint multi-protocol label switching deployed in the packet switched core network. When the mobile host is handed over between different domains of the radio access network, connected to different egress nodes of the core network, the setup of a new branch label switched path from an intermediate node to the new egress node is initiated by the intermediate node. The new branch label switched path is then associated with the existing label switched path to the old egress node. The optimum branch label switched path may be determined either by the old or by the new egress node.

Description

PROVIDING MOBILITY TO A MOBILE HOST IN A NETWORK EMPLOYING POINT-TO-MULTIPOINT M ULTI-PROTOCOL LABEL SWITCHING

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention generally relates to mobile networks.

In particular, this invention considers a scenario of a mobile network, in which Multi- Protocol Label Switching (MPLS) is deployed as a transport technology over the whole or a portion of the wired part of the mobile network (i.e. the Core network and partially the Radio Access Network, RAN). To assure the quality of service (QoS) requirements, MPLS-based tunnels are set up, deploying Traffic Engineering (TE) options of MPLS signalling. The data packets destined for a roaming end-receiver (Mobile Host, MH) are tunnelled over one or more such MPLS-based tunnels, which are also referred to as label switched path (LSP) tunnel. Further, one or more point-to-multipoint (P2MP) LSP tunnels are established per MH between the ingress and egress LSRs.

2. .- Description of the Related Art

Mobility management solutions for data communication in cellular networks, for example 2G (GSM) and 3G (UMTS), are technology specific and/or circuit-switched. For a future forth generation (4G) mobile networks mobility solutions are needed which are based on packet-switched transport technologies. The IETF has standardized mobility management for IP-based packet-switched networks known as Mobile IP (MIP). In this standard, the IP routing uses the packet's IP address as information about the destination point, i.e. the IP address determines unambiguously the geographical point of attachment. MIP extends the classical IP routing with the mobile host's possibility to be associated with two IP addresses: a static "home" address and a dynamic "care-of- address" (CoA), which reflects the MH's current point of attachment. An overview about the functionality of MIP can be found in C. Perkins et. al., "IP Mobility Support for IPv4", RFC 3344, August 2002, pp. 3-17. Further herein below, a scenario is assumed, where in contrary to MIP the mobile host keeps the same IP address when it moves within the network of the same operator. The IP packets are tunnelled over the mobile network employing traffic engineered (TE) MPLS, which assures QoS and TE, together with fast transport. The MPLS concept and current approaches for mobility in MPLS are described further below.

System Model

This invention is based on the architecture intended to cover 4th generation (4G) mobile networks. The network is divided in a Core network and a Radio Access Network (RAN). One important requirement for the RAN is that various access technologies have to be supported, e.g. Wireless Local Area Network (WLAN), 3rd Generation (3G) RAN and future 4th Generation (4G) RAN. Herein a system model is assumed, in which each of the different radio access technologies is regionally organized in radio access domains. A centralized architecture is suggested for these radio domains, with a control and management entity called radio access controller (RAC). Depending on the radio access technology, the RAC can be an access bridge (regarding IEEE802.1 architecture), access controller (or AC regarding the centralized WLAN access architecture assumed in lETF's CAPWAP working group), or radio network controller (RNC, as defined in 3G). Main function of the RAC in the RAN is to control, manage and monitor the base stations (BS) or access points (AP) that provide the wireless interface on the network side.

MPLS and Mobility in MPLS

This section describes the MPLS technology and the possibilities to apply it as tunnelling protocol in mobile networks.

The MPLS concept employs two distinct functional planes: control plane and forwarding plane. In the control plane, standard routing protocols are used (e.g. "Open Shortest Path First", OSPF, and "Border Gateway Protocol", BGP) to exchange information with other routers to build and maintain a forwarding table. In the forwarding plane, when data packets arrive, the forwarding component searches in the forwarding table to make a routing decision for each packet. To each packet a short label with fixed length is attached identifying the Forwarding Equivalent Class (FEC). The forwarding plane in MPLS is based on a so-called label swapping algorithm. The label switch (known as Label Switch Router, LSR) performs a routing table lookup, maps the packet to a FEC and then assigns a label to the packet before forwarding it to the next LSR in the Label Switched Path (LSP). A detailed specification of MPLS concept can be found in sections 2 and 3 of E. Rosen, Floyd, A. Viswanathan, and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031 , January 2001 , pp. 3-37.

The MPLS described above has still the hop-by-hop forwarding paradigm inherited from standard IP routing. To increase the efficiency and the reliable network operations in the MPLS domain, as well as to meet QoS requirements, Traffic Engineering (TE) capabilities for MPLS are specified mainly in sections 2, 3 and 4 of D. Awduche, J. Malcolm, J. Agogbua, M. O¹DeII, J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999, pp. 4-10. These capabilities can be used to optimize the utilization of network resources and to enhance traffic oriented performance characteristics. An LSP set up by TE constraints is called LSP tunnel, since the flow along an LSP is completely identified by the label applied at the ingress node of the path. If sets of LSP tunnels are associated together, e.g. for the purpose of performing re-route operations to the whole set of LSP tunnels, such sets are called traffic engineered tunnels (TE tunnels). The definition of the terms 'LSP tunnel' and TE tunnel' as well as their difference are specified in sections 2 and 4 of D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001 , pp. 7-15 and 17-49.

Currently MPLS is widely deployed as generic transport technology, however, in the specifications there are no mechanisms available to provide mobility to an LSP tunnel. Several recent publications have considered the deployment of MPLS in mobile networks. In F. Chiussi, D. Khotimsky, and S. Krishnan, "A Network Architecture for MPLS-Based Micro-Mobility", in Proc. of the Wireless Communications and Networking Conference (WCNC), March 2002, section III (pp.3-5), a Label Edge Mobility Agent (LEMA) is defined, which is located on all edge LSRs and some intermediate LSRs building a hierarchically structured network. When a mobile host changes to a new access router, the new access router registers to the intermediate LEMAs that do the mapping of the MH's traffic to a pre-established LSP between intermediate LEMA and edge LEMA. In T. Yang, Y. Dong, Y. Zhang, and D. Makrakis, "Practical Approaches for Supporting Micro Mobility with MPLS", in Proc. of the International Conference on Telecommunications (ICT), June 2002, sections Il and III, a micro-mobility scheme is presented that defines a crossover LSR at the interception of two paths - the path between GW and old FA and those between GW and new FA. The crossover LSR sets up a new LSP to the new FA and forwards the traffic to the new FA.

The mechanisms presented in the cited documents are based on the assumption that both Mobile IP and MPLS are deployed together and the MH will obtain a new IP CoA address after a handover. The invention presented herein aims to introduce mechanisms helping to deploy mobility in the MPLS technology itself and not relying on the signalling of other protocols (e.g. on Mobile IP messages). Further, in contrary to the mechanisms described in Chiussi et al. and in Yang et al., both cited above, with the method described herein below, the MH may retain the same IP address when changing the egress LSRs. This means that at a handover between different radio access schemes the MH will retain its IP address, as long as the ingress LSR (e.g. network GW) remains the same. A method is needed to provide mobility mechanisms to MPLS, so that the user's data flow is re-directed to the new egress LSR without changing the IP address of the MH.

RSVP-TE and Point-to-Multipoint (P2MP) LSP

The MPLS architecture allows the use of multiple label distribution protocols, and thus, in the control plane different signalling protocols like Label Distribution Protocol (LDP) and Resource Reservation Protocol (RSVP) can be used. Initially, RSVP was designed to fulfil the Integrated Services (IntServ) concept for implementing QoS in standard IP- based networks. Employing extensions in RSVP with several additional objects allow to use RSVP as a signalling protocol for providing TE in MPLS. The extended RSVP is known as RSVP-TE and it is described in details in sections 2 and 4 of RFC 3209, pp. 7- 15 and 17-49, cited above. In particular, the extended RSVP protocol supports the instantiation of explicitly routed LSPs, with or without resource reservation. It also supports smooth re-routing of LSP tunnels, pre-emption, and loop detection.

To help understanding the present invention, the identification of the LSP tunnel is explained below in this section. As described in section 2.1 of RFC3209 on pp. 7-8, an LSP tunnel is uniquely identified by SESSION and SENDER_TEMPLATE objects that include ingress LSR, egress LSR, Tunnel ID, LSP ID and sender's IP address. The SESSION object includes 3 parameters: IPv4 (or IPv6) tunnel end point address: the IP address of the egress node for the tunnel

Tunnel ID: a 16-bit identifier which is kept unchanged over the life of the tunnel Extended Tunnel ID: normally it is set to all zero, but it may include the IP address of the ingress node as a globally unique identifier (in order to narrow the scope of a SESSION to the ingress-egress pair) The SENDEFMΕMPLATE object includes:

IPv4 (or IPv6) tunnel sender address: IPv4 (or IPv6) address for a sender node LSP ID: a 16-bit identifier used in the SENDEFMΕMPLATE and the FILTER_SPEC that can be changed to allow a sender to share resources with itself. According to the identification of the LSP tunnel in RFC3209, a new SESSION object has to be generated when an egress LSR changes, as it is assumed in the scenario of this invention, and thus a new LSP tunnel should be set up to the new egress LSR. We refer to the RSVP-TE signalling specified in RFC3209 as point-to-point (P2P) signalling.

Recent work in IETF has concentrated on extensions to P2P RSVP-TE enabling point-to- multipoint (P2MP) LSP signalling. These mechanisms are still not finally specified in IETF, however a proposal is under discussion. R. Aggarwal, D. Papadimitriou, and S. Yasukawa, "Extensions to RSVP-TE for Point to Multipoint TE LSPs", Internet Draft, Work in Progress, describe in section 21 on pp. 27-31 changes to SESSION and SENDER_TEMPLATE objects and the newly defined P2P_SUB_LSP and SERO and SRRO objects. The P2MP LSP, which is constituted of one or more P2P sub-LSPs, is identified by the SESSION and SENDER_TEMPLATE objects. The combination of the SESSION object, the SENDERJΕMPLATE object and the P2P SUB-LSP object identifies each P2P sub-LSP. The differences in the specification of the objects for P2MP LSP and these from RFC3209 are further deeply explained in R. Aggarwal et al. However, the definitions given there are to be merely understood as an example how P2MP LSPs may be implemented. Other particular protocols may serve this purpose as well, as long as they permit to establish point to multipoint tunnels branching at an intermediate LSR. According to the proposal given in R. Aggarwal et al. the establishment of the P2MP LSP as well as each Sub-LSPs is signalled by the ingress LSR.

To share the load over the network, MPLS is designed to determine an explicit path for a particular flow. The explicit route for the LSP tunnel is calculated in the ingress LSR and is encoded in the EXPLICIT_ROUTE object (ERO) and signalled in the Path message. The format and the options of the ERO object are described in reference RFC3209, section 4.3 on pp. 23-31.

CA2292252, "SYSTEM AND METHOD FOR MOBILE SPECIFIC LABEL EDGE ROUTER OPERATION WITHIN A CORE AND EDGE NETWORK", discloses a packet switched communications network utilizing a "mobile specific" label edge router (MLER) configured with mobility management functionality. The MLER supports the handing over of a call from a label switched path to a first MLER associated with a currently serving radio base station to another label switched path for a second MLER associated with a target base station. A method is provided, in which predefined paths are available between Label Edge Router (LER) and BS. At handover, the LER exchanges the MPLS header of the data packets destined to the old base station to MPLS labels targeting the new base station. However, the method described in CA2292252 does not treat the case of changing LER.

US20030110290A1 , "MOBILE TRACKING SYSTEM FOR QOS GUARANTEED PATHS; ROUTER DEVICE USED FOR THIS SYSTEM; MOBILE COMMUNICATIONS TERMINAL; AND CONTROL PROGRAM FOR CONTROLING ROUTER DEVICE", discloses a transit router (TR) used to detect any change of visitor location address reported via an existing QoS path. The TR sets up a new QoS guaranteed path according to the result of detection. The packets are transmitted over the old path until the TR completes the setup of the new path. The mobile communication terminal and the remote terminal are notified that the setup of QoS guaranteed path is completed. In the method presented in US20030110290A1 , a central location manager or an intermediate router (TR) manages the setup of QoS guaranteed paths. For this purpose, the mobile communication terminal is involved in the signalling of its location and required QoS parameter. Thus, since the air interface is the bandwidth bottleneck and it is involved in the signalling path, unnecessary load is put on it.

In WO2003030467A2, "MPLS DATA TRANSMISSION IN PACKET-ORIENTED MOBILE RADIO NETWORKS", a unique MPLS label is assigned to each terminal. This MPLS label allows unambiguous addressing of the data packets to the terminal. The routers tunnel the information packets, using either the MPLS or other tunnelling protocol. The disclosed method allows the end terminal to notify a MPLS router about its unique MPLS label. Then the MPLS router tunnels the data packets to the end terminal using label stacking. The mobile terminal is involved in the MPLS signalling exchange and an unambiguous label needs to be assigned to the MH.

The introduction of TE MPLS in mobile networks incorporates the advantages of packet- switched network with the possibility to provide QoS (especially relevant for real-time services) and TE needed to optimize the network load. Since the deployed system model assumes that an LSP tunnel is set up per MH and the MH changes the tunnel egress nodes while moving, it is required to dynamically change the egress LSR. Most of the currently known schemes for re-direction of user traffic, when deploying MPLS transport, are based on Mobile IP assuming that the MH accepts a new CoA IP address when it changes the egress LSR. However, the assumption in this invention is that the MH keeps the same IP address when it roams between distinct egress LSRs.

One solution to preserve a continuous connection between ingress and egress LSR when the egress LSRs change is to use P2MP LSP tunnel for each MH and set up a new branch LSP when the MH moves to new egress LSR. Nevertheless, the calculation and the signalling for the setup of the branch LSP is done in the ingress LSR. This causes long handover procedures and high signalling load to and from the ingress LSR for large- scale networks. The specific problem addressed in the current invention is how to find the optimal branch LSR and to calculate the branch LSP without the participation of the ingress LSR.

SUMMARY OF THE INVENTION

An improved method is provided which may assure a continuous connection between a moving end-receiver (mobile host, MH) and an ingress LSR of the network, in particular in a case when the egress LSR changes because the MH moves the service area of one radio access domain into the service area of another radio access domain. The presented invention describes a method for maintaining a permanent connectivity from an ingress LSR to a MH via an egress LSR when the transport between ingress and egress LSRs is based on point to multipoint LSP tunnelling. The MH may advantageously keep the same IP address while roaming between distinct egress LSRs. In the described method, new branch LSP is set up between a branch LSR and the new egress LSR when a MH moves to a new egress LSR. The setup is initiated by the branch LSR. Two options are presented how to determine the optimal branch LSR: (1) either the old egress LSR or (2) the new egress LSR can decide the optimal branch point. The calculation of the branch LSP route may be done in the egress LSR, but it can alternatively be calculated in the branch LSR.

In one embodiment, a method for providing mobility to a mobile host in a wireless network using point-to-multipoint multi-protocol label switching as a transport technology between a gateway and a plurality of radio access network domains, comprises the steps of a) setting up a multi-protocol label switching tunnel from an ingress node to a first egress node serving a first radio access network domain; and, if said mobile host moves from a service area of said first radio access network domain to a service area of a second radio access network domain: b) determining a branch multi-protocol label switching tunnel from an intermediate node to a second egress node serving said second radio access network domain; c) initiating a setup of said branch multi-protocol label switching tunnel by said intermediate node and d) associating said branch multi-protocol label switching tunnel with said multi-protocol label switching tunnel set up in step a).

In another embodiment, a telecommunication system comprises a multi-protocol label switching network with a plurality of label switching routers forming nodes of said network, one of said nodes being configured as ingress node to provide connection to an external packet switched network; a mobile host having an internet protocol address and being configured to receive packet data; a plurality of radio access network domains, each of said radio access network domains being configured to provide wireless connection between one of said nodes serving as an egress node of said multi-protocol label switching network, and said mobile host; said network being configured to set up a multi-protocol label switching tunnel from said ingress node to a first egress node connecting a first radio access network domain belonging to a first service area where said mobile host is located, and, if the mobile host changes its location from said first service area of said first radio access network domain to a second service area of a second radio access network domain, to determine a branch multi-protocol label switching tunnel from an intermediate node to a second egress node serving said second radio access network domain; to initiate a setup of said branch multi-protocol label switching tunnel by said intermediate node; and to associate said branch multi-protocol label switching tunnel with said multi-protocol label switching tunnel from said ingress node to said first egress node.

In a further embodiment a method to be executed in an intermediate node of a multi¬ protocol label switching core network of a wireless network, comprises the steps of receiving a request to set up a branch multi-protocol label switching tunnel to a second egress node identified in said request; initiating the setup of said branch multi-protocol label switching tunnel; and associating said branch multi-protocol label switching tunnel with an existing multi¬ protocol label switching tunnel identified in said request.

In still another embodiment, a method is provided to be executed in a first egress node of a multi-protocol label switching core network of a wireless network, said first egress node receiving data packets over an existing multi-protocol label switching tunnel and forwarding the data packets to a mobile host via a first radio access network, the method comprising the steps of receiving, from the mobile host, information about an identifier of a second egress node of said label switching core network serving a second radio access domain; determining an intermediate node on the route of the existing multi-protocol label switching tunnel as a branch node for a branch multi-protocol label switching tunnel to said second egress node; and requesting a setup of said branch multi-protocol label switching tunnel, associated with said existing multi-protocol label switching tunnel, from said determined intermediate note.

In still a further embodiment, a method to be executed in a second egress node of a multi-protocol label switching core network of a wireless network comprises the steps of receiving, from a mobile host, information about an identifier of a first egress node of said label switching core network serving a first radio access domain and information about an identifier of said mobile host; obtaining, from said first egress node, information about an existing multi-protocol label switching tunnel carrying data packets for said mobile host; determining an intermediate node on the route of the existing multi-protocol label switching tunnel as a branch node for a branch multi-protocol label switching tunnel to said second egress node; and requesting from said determined intermediate node a setup of said branch multi-protocol label switching tunnel, associated with said existing multi-protocol label switching tunnel, from said determined intermediate node to the second egress node.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings are incorporated into and form a part of the specification for the purpose of explaining the principles of the invention. The drawings are not to be understood as limiting the invention to only the illustrated and described examples of how the invention can be made and used. Further features and advantages will become apparent from the following and more particular description of the invention, as illustrated in the accompanying drawings, wherein

Figure 1 describes an exemplary system architecture of a mobile network;

Figure 2 represents an overlay model of the network shown in figure 1 from MPLS perspective;

Figure 3 illustrates an alternative to Figure 9.2, wherein the entity determining the branch

LSR is the new egress LSR;

Figure 4 shows the data plane protocol stacks in the regarded entities of the network of figure 1 ;

Figure 5 shows the protocol stack in the regarded entities of the network of figure 1 in the control plane;

Figure 6 shows the signalling in the case where the old egress LSR determines the branch LSR; Figure 7 shows the signalling in the case where the new egress LSR determines the branch LSR; and

Figure 8 shows the structure of a label switched router which may serve as a node in a MPLS network.

DETAILED DESCRIPTION OF THE INVENTION

The exemplary embodiments of the present invention will be described with reference to the figure drawings wherein like elements and structures are indicated by like reference numbers.

Figure 1 describes an exemplary system architecture, which can be used for a better understanding of the present invention. The MH 109 is attached to a mobile network 100, and it can be connected to the Internet 116 or to any other private or public network through a gateway (GW) 108. If the MH 109 is in the home network, it uses the home IP address for communication with any other host. In the case that the MH 109 is in a foreign mobile network, the MH 109 needs a Care-of-Address (CoA) as described above. In the case of MIPv4, the MH 109 can retrieve the CoA from a Foreign Agent (FA) located e.g. at the GW 108. In the case of MIPv6 the MH 109 can generate the CoA by itself with the help of an Access Router (AR). The mechanism for retrieving a CoA is not explained herein in more detail. In the example depicted in Figure 1 , a LSP tunnel 110 is built between the GW 108 and the radio access controller RAC 104 (refer above for more details). Based on the system model depicted in Figure 1 , the following assumptions are made:

- Micro-mobility scenario, where the MH 109 retains the same IP address while moving between different egress LSRs 104, 105 in a mobile network.

- To assure the fulfilment of required QoS, the MPLS is used in TE mode, as this further allows the mobile operator to configure the load in the network more accurately.

- An LSP tunnel is set up per data flow to each MH. This requires to change the route of the LSP tunnel when the MH moves between egress LSRs.

Figure 1 shows only one examplary system architecture in which the method described herein can be applied. Other scenarios for the configuration of the mobile network are possible, in which the egress point of the LSP tunnel changes due to MH mobility. The data transport over the RAN 102, 103 is performed on the link-layer (also called layer 2, L2), whereas the transport over the Core network 101 is carried over the IP layer (layer 3, L3) packet-switched network due to scalability reasons. In the method described herein, the transport over the packet-switched Core network 101 is based on the TE MPLS. In Figure 1 , the names without parentheses show the functional categorization as for instance RAC, gateway etc. The names in parenthesis show the corresponding names in MPLS terminology, e.g. ingress/egress LSR etc.

The gateway (GW) 108 of the mobile network, as shown in Figure 1 , is an entity implementing the functions of ingress LSR in the MPLS transport layer and Foreign Agent (FA) or Access Router (AR) in the IP layer. We use both terms FA and AR to show that both Internet Protocol versions, IPv4 and IPv6, may be supported. Normally, FA is an element of mobile IPv4 protocol, whereas AR is rather used in connection with mobile IPv6 protocol. A detailed description of the FA functionality can be found in C. Perkins et. al., "IP Mobility Support for IPv4", RFC 3344, August 2002, pp. 5-6 and 47-54. It is not necessary that the egress LSR and FA/AR are physically located in the same entity, it is rather important that egress LSR and FA/AR communicate via common L2 technology as shown in Figure 4. According to this latter figure, the mobile network provides L2 connectivity between the FA/AR and MH109. The FA/AR provides L3 services 401 to the MH 109. The communication between MH 109 and FA/AR, as well as the mobile IP functionality are not in the scope of this invention. Further herein below we will use "GW" as a generic term including the functions of egress LSR and FA/AR. Since the focus herein is on the MPLS data transport over the Core network, one possibility to map the LSP tunnel physically on the mobile network may be on the link between GW 108 and RAC 104, 105.

Referring back to figurei , according to the scenario assumed herein, the ingress LSR is in the GW 108 and the egress LSR is in the RAC 104. The packets entering the mobile network and destined for a particular MH 109 are encapsulated at the ingress LSR (i.e. addition of MPLS label), transported over a pre-set up LSP tunnel 110, de-capsulated at the egress LSR 104 and transported on L2 over the RAN 102 to the MH 109. With respect to the assumption in figure 1 , the RAC 104, 105 is an entity implementing in the data plane L2 protocol(s) used in the radio access domain, and edge/egress LSR functionality. In the control plane, the RAC implements MPLS control protocol(s), i.e. RSVP-TE, and further some additional IP-based signalling protocols for e.g. exchanging Authorization, Authentication and Accounting (AAA) with central entities in the Core network. According to the assumption that the packet transport within the radio access domains 102, 103 is performed in Layer 2 and one radio access domain forms a kind of Local Area Network (LAN), we assume in figure 1 that the LSP tunnel 110 starts from the GW 108 and ends at the RAC104. However, the current invention is applicable to other scenarios where the LSP tunnel 110 is formed over the whole or a portion of the wired part of the mobile network. For example, one LSP tunnel can start from the GW and end at the BS. Therefore, we would like to generalize the system model and to introduce an MPLS overlay model as depicted in Figure 2 where the focus is on the MPLS-related functions of the entities rather than on the physical location. Further herein, the term RAC is used as the first MPLS-capable node from the MH's perspective. The MH does not support MPLS, and communicates with the RAC on L2. The protocol stacks suggested herein for the data transport between MH and Gateway can be seen in Figure 4.

The term mobile host (MH) used herein is a common representative for a mobile computing device like notebook, 3G-user equipment (UE) or even a personal area network (PAN), which is formed by several personal devices. The MH 109 is connected to a BS 113 via a wireless link, which terminates the wireless communication and assures wire line packet-switched connection with other entities in the mobile network.

Referring now to figures 2 and 6, a first embodiment, in which the old egress LSR1 determines the branch LSR, is now described in detail. Figure 2 represents an overlay model from MPLS perspective, based on the system architecture depicted in Figure 1. An initial "existing P2MP LSP" 110 connects the ingress LSR 108 and the old egress LSR 104. When the MH 109 moves from radio access domain 102 served by old egress LSR 104 to another radio access domain 103 served by new egress LSR 105, the following procedures take place:

1. Firstly, MH 109 communicates via an L2 connection 601 with egress LSR1 and via an old P2MP LSP tunnel 110 between old egress LSR 104 and ingress LSR 108. When the MH 109 moves to the area of a new egress LSR 105, the MH 109 receives in step 602 a broadcast message from new egress LSR, transmitted by base station 114 shown in figure 1 (e.g. this could be a beacon message in case of IEEE802.11 radio access). Based on this message, the MH 109 can learn in step 603 the identifier of the new egress LSR 105 (e.g. IP address, or a MAC address). This phase corresponds to step 201 in figure 2.

2. The MH 109 informs the old egress LSR 104 in step 604 about the identifier of new egress LSR 105 (step 202 in Figure 2). In the case that a plurality of LSPs serving MH 109 exist, the corresponding information is also included in the exchange of step 604. Thereafter, the egress LSR 1 can calculate which of the intermediate LSRs 106, 107 in the path of the existing P2MP LSP is closest to new egress LSR 105. In other words, old egress LSR 104 determines an optimal branch LSR 107 in step 605. This calculation is possible because the new egress LSR 105 has exact knowledge of the network topology and of the route of the existing LSP 110. This is for example the case with OSPF applied as routing protocol where all routers within a routing area have a complete knowledge about the area topology. In the illustrative example of figure 2 and figure 6, the optimal branch LSR is intermediate LSR 107.

3. After the old egress LSR 104 determines the optimal branch LSR 107, old egress LSR 104 sends a request to intermediate LSR 107 in step 606. This corresponds to step 203 in Figure 2. Upon receiving the request, the intermediate LSR 107 initiates the setup of a new branch LSP 111 to new egress LSR 105, wherein the traffic parameters (or Quality of Service parameters) are the same as of the existing P2MP LSP tunnel 110. There are two possibilities for calculation of the branch LSP route:

- Either the old egress LSR 104 calculates the route and signals it to the branch LSR 107 together together with the request for the setup of new branch LSP 111 in step 606 or

- the branch LSP 107 calculates the LSP route by itself using its routing table (e.g. in case of OSPF this can be the tree of shortest paths).

4. Having the information about the identifier of new egress 105 and the branch LSP's 111 ERO object, the branch LSR 107 can generate in step 607 a Path message for the setup of new branch LSP 111. The setup of new branch LSP 111 to new egress LSR 105 is depicted as step 204 in Figure 2. After the setup is completed, the intermediate LSR 107 updates its forwarding table in step 608, such that the incoming packets from the existing P2MP LSP 110 are duplicated and sent to both interfaces connecting intermediate LSR 107 with old egress LSR 104 and new egress LSR 105. In other words, new branch LSP 111 is associated with the existing LSP 110. At request, the branch LSR 107 can tear down the branch 112 to the old egress LSR 104. Further, the intermediate LSR 107 updates the ingress LSR 108 about the changes of the P2MP LSP route with the new ERO object by sending the corresponding information to it. These changes may comprise the setup of new branch LSPs as well as the tearing down of branches of existing LSPs.

Before the branch 112 to the old egress LSR 104 is torn down, MH 109 may be connected for a certain time period to both radio access network domains. During a so- called "soft handover" MH 109 may receive data packets simultaneously from both RAN domains 102 and 103.

Referring now to figures 3 and 7, an alternative is described in which new egress LSR 105 determines the branch LSR 107. After the MH 109 moves to the RAN area 103 (see figure 1) served by new egress LSR 105, the following procedures take place:

1. Firstly, MH 109 communicates via a L2 connection 701 with old egress LSR 104 and via an old P2MP LSP tunnel 110 between old egress LSR 104 and ingress LSR 108. When the MH 109 moves to the RAN area 103 of a new egress LSR 105, the MH 109 receives in step 702 a broadcast message from egress LSR2, transmitted by base station 114 (e.g. this could be a beacon message in case of IEEE802.11 radio access). The MH 109 establishes in step 703 a L2 connection 704 with the new egress LSR 105. The procedures for establishing this L2 connection depend on the deployed L2 technology. This phase corresponds to step 301 in Figure 3.

2. After the L2 attachment, the MH 109 informs the new egress LSR 105 in step 705 about the identifier of its previous L2 point of attachment, which is LSR 104. In the same step, MH 109 may also inform the new egress LSR 105 about its own identifier. Thereafter, the new egress LSR 105 can exchange information with old egress LSR 104 in step 706 about the existing LSP 110 serving currently the MH 109. This is shown by step 302 in Figure 3. In the case that a plurality of LSPs serving MH 109 exist, the corresponding information is also included in the exchange of step 706. Having information about the route of the existing P2MP LSPs to old egress LSR 104, the new egress LSR 105 can calculate in step 707 the optimal branch LSR from traffic engineering perspective. This calculation is possible because new egress LSR 105 has exact knowledge of the network topology (e.g., as mentioned in the preceding example, with OSPF). In the example shown in figure 3 and figure 7, the optimal branch LSR is intermediate LSR 107.

3. After the new egress LSR 105 determines the optimal branch LSR (intermediate LSR 107), new egress LSR 105 sends a request to intermediate LSR 107 in step 708. This corresponds to step 303 in Figure 3. Upon receiving the request, the intermediate LSR 107 initiates in step 709 the setup of a new branch LSP 111 to new egress LSR 105, wherein the traffic parameters (or Quality of Service parameters) are the same as in the existing P2MP LSP tunnel 110. There are two possibilities for calculation of the branch LSP route:

- Either the new egress LSR 105 calculates the route and signals it to the branch LSR 107 together with the request for the setup of new branch LSP 111 or

- the branch LSR 107 calculates the LSP route by itself using its routing table (e.g. in case of OSPF this can be the tree of shortest paths).

4. Having the information about the identifier of new egress LSR 105 and the branch LSP's 111 ERO object, the branch LSR 107 can generate a Path message for the setup of a new branch LSP 111 in step 709. The setup of new branch LSP 111 to new egress LSR 105 is depicted as step 304 in Figure 3. The procedures of the following step 710 are the same as described above in item 4 in conjunction with figures 2 and 6.

The term "branch LSP" is defined in this context as the LSP between a branch LSR and a particular egress LSR, which is clearly depicted in figure 2 and figure 3. This definition differs from the definition of sub-LSP, which according Aggarwal et al., cited above, is a label switched path from the ingress LSR to a particular egress LSR. In the context of Aggarwal et al., the branch LSP can be regarded as a part of a sub-LSP. After the setup of a new branch LSP is completed, in order to conform with the standard, the branch LSP may be integrated in a sub-LSP, which includes the path from the ingress LSR to the egress LSR. The procedures of incorporation of a branch LSP into a sub-LSP are not discussed herein in further detail.

Figure 4 shows the data plane protocol stacks in the regarded entities, i.e. ingress LSR, intermediate LSR 107, egress LSR 104, 105 and MH 109. The figure shows the protocol stacks of FA/AR and ingress LSR separately, however for the description herein it is assumed that FA/AR and ingress LSR are located in the same entity - in the Gateway 108. It is important to mention that the communication 401 between GW 108 and MH 109 takes place on L2. The L2 data between ingress LSR 108 and egress LSR 104, 105 is tunnelled through an LSP tunnel 402. Between the egress LSR 104, 105 and MH 109 the data transport is supposed to be on L2 (connection 403). For instance, if the L2 technology were Ethernet, then the resulting protocol stack over the Core network would be Ethernet over MPLS (EoMPLS) and over the RAN the native Ethernet packets would be further processed. Figure 5 shows the protocol stack in the control plane. The separation between data plane and control plane is carried out in order to depict the differences of the used protocols. As it is described above, the MPLS signalling protocol 501 assumed herein is RSVP-TE. All entities involved in the transport over an LSP tunnel - ingress, egress and intermediate LSRs - communicate on basis of RSVP-TE messages, which are encapsulated in UDP/IP packets and sent between the LSRs as normal IP packets. The communication between new egress LSR 105 (RAC2) and ingress LSR 108 (GW) from Figure 2 is carried out in the control plane as well.

As it becomes obvious from the two examples described above in connection with figures 2, 3, 6 and 7, this invention defines the following extensions to existing MPLS entities:

New functions in the egress LSR:

Ability to learn the ID of other egress LSRs via a MH.

Further, the egress LSR is able to calculate the nearest/closest LSR from the existing P2MP LSP to a new egress LSR2 (i.e. optimal branch LSR).

Optionally the egress LSR may calculate the optimal route for the new branch LSP as well.

The egress LSR is able to signal a request to the newly calculated branch LSR, for requesting the setup of a new branch LSP.

The egress LSR may also have the capability to receive (in case of new egress LSR) or alternatively to send (in case of old egress LSR) the ERO object of an existing P2MP LSP.

New functions in a branch LSR (i.e. intermediate LSR) allow to process a request for setup of a new branch LSP. An intermediate LSR becomes a branch LSR only if the request for new branch LSP setup is destined to the intermediate LSR itself. The following procedures have to be performed only in the branch LSR that is receiver of the request for new branch LSP setup:

Generate a new Path message for the setup of a branch LSP, wherein the new egress LSR ID to be included with the Path message is received with the request message.

Extract the QoS parameters from the existing P2MP LSP(s) to the same MH.

Calculate the branch LSP route (ERO object) or obtain the branch LSP route from the request message. Ability to associate the newly set branch LSP with an existing P2MP LSP (e.g. to update the forwarding table accordingly and to duplicate incoming packets to the old and new branch LSPs).

It is not mandatory that all intermediate LSRs implement the functions described above. Only the intermediate LSRs, which are able to perform the functions of branch LSR, can be included in the data base available at the egress LSRs that determine the optimal branch LSR, as described in item 2 of the examples explained above in conjunction with figures 2, 3, 6 and 7.

If multiple P2MP LSPs exist per MH from ingress to old egress LSR, the procedures for new branch LSP setup are performed for all P2MP LSPs. One option for maintaining multiple P2MP LSPs per MH is to organize them in one P2MP TE tunnel as described in section 3.1 of R. Aggarwal et al., on pp. 3-4. Therein, a P2MP TE Tunnel is identified by a P2MP SESSION object. This object contains the P2MP ID defined as a destination identifier, a tunnel ID and an extended tunnel ID. The fields of this object are the same as the SESSION object (defined in RFC 3209, cited above) except for the fact that the destination address is a P2MP identifier and not an IP address of the egress node. This identifier encodes the P2MP ID and identifies the set of destination(s) of the P2MP LSP. A P2MP LSP tunnel is identified by the combination of the P2MP SESSION object and the SENDER_TEMPLATE object. The SENDERJΕMPLATE object is the same as in RFC3209. The SENDER_TEMPLATE object contains the ingress LSR source address and the LSP ID. Multiple instances of the P2MP TE tunnel i.e. multiple P2MP LSP tunnels can be created, each with a different LSP ID. These P2MP LSP tunnels use different labels.

If the LSP tunnels associated with the MH ID at the branch LSR are bi-directional, the branch LSR sets up the new branch LSP(s) as bi-directional tunnel(s).

Figure 8 shows an exemplary structure of a label switched router 800 which may serve as a node in a MPLS network. The router 800 comprises a processor or CPU 801 to programmably carry out steps of the methods described above, depending on the role of the node or LSR in the network. Instructions together with data to be processed may be preliminarily stored in RAM 802 during execution of the program. Additionally, the instructions of the program may be stored permanently in non-volatile memory 803, which may be semiconductor memory like read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM₁ EEPROM, Flash) or magnetic hard disc. Alternatively or additionally the instructions may be stored in other computer-readable media like optical disc, magnetic disc or magnetic tape, to be inserted into media reader 804 which would be a corresponding disc or tape drive unit. The LSR also comprises network interfaces 805 to connect it with other LSRs. If the LSR serves as radio access controller (RAC), it further comprises a specific interface 806 to the radio access network. All components may be linked with some or all of the other components by a bus 807 or by dedicated links.

To allow seamless mobility for the MH, it is important that the data flow with a correspondent node is kept alive during handovers. Various embodiments as described above may advantageously perform this inter-access-domain handover in a fast manner and without packet losses. Furthermore, data packets are transmitted simultaneously to old and new egress LSRs and thus a soft handover can advantageously be supported. Another advantage of deployed P2MP LSP is the ability to simultaneously connect the end-receiver (MH) with different egress LSRs, and thus, with different radio access domains.

In the current P2MP LSP proposals in IETF, the ingress LSR is responsible for all LSP changes. The method described herein shifts the procedures from ingress to egress and branch LSRs, and thus reduces the processing in the ingress LSR, as the branch LSR initiates the new branch LSP setup. Further the signalling to and from the ingress LSR is reduced as well.

One further advantage of the proposed method is the ability of the egress LSR to determine the optimal branch LSR relying on the topology information of the routing area and the knowledge of the existing LSP route. The optimal determination of the branch LSR allows a better utilization of the network resources.

Another benefit of the present invention is that there is no need to implement the micro- mobility Mobile IP extensions, e.g. hierarchical MIP or fast MIP, in either of the network entities. Standard MIPv4 or MIPv6 has to be implemented in the Gateway (FA/AR) and the MH (according to the scenario in Figure 4). Since most of the routers distributed on the market currently are MPLS-capable, the method presented above concentrates the handover procedures on the network side and provides reduced signalling and processing compared to micro-mobility MIP extensions. Further, the management of the MH mobility is done mainly on the network side, advantageously relieving the MH from these tasks. Moreover, this reduces the signalling load on the radio link.

While the invention has been described with respect to the embodiments constructed in accordance therewith, it will be apparent to those skilled in the art that various modifications, variations and improvements of the present invention may be made in the light of the above teachings and within the purview of the appended claims without departing from the spirit and intended scope of the invention. In addition, those areas in which it is believed that those of ordinary skill in the art are familiar, have not been described herein in order to not unnecessarily obscure the invention described herein. Accordingly, it is to be understood that the invention is not to be limited by the specific illustrative embodiments, but only by the scope of the appended claims.

Claims

What is claimed is

1. A method for providing mobility to a mobile host in a wireless network using point- to-multipoint multi-protocol label switching as a transport technology between a gateway and a plurality of radio access network domains, comprising the steps of

a) setting up a multi-protocol label switching tunnel from an ingress node to a first egress node serving a first radio access network domain;

and, if said mobile host moves from a service area of said first radio access network domain to a service area of a second radio access network domain:

b) determining a branch multi-protocol label switching tunnel from an intermediate node to a second egress node serving said second radio access network domain;

c) initiating a setup of said branch multi-protocol label switching tunnel by said intermediate node and

d) associating said branch multi-protocol label switching tunnel with said multi¬ protocol label switching tunnel set up in step a).

2. The method according to claim 1 , wherein step c) further comprises, prior to initiating said setup, and executed within said intermediate node, calculation of an optimal explicit traffic engineered route for said branch multi-protocol label switching tunnel.

3. The method according to claim 1 , wherein step b) further comprises calculation of an optimal explicit traffic engineered route for said branch multi-protocol label switching tunnel.

4. The method according to claim 1 or 3, wherein step b) is carried out by said first egress node and in a step e), after step b) and prior to step c), said first egress node sends a request to said intermediate node to set up said branch multi-protocol label switching tunnel to said second egress node.

5. The method according to claim 4, wherein, in a step f) after step a) and prior to step b), said mobile host obtains information about an identifier of said second egress node from said wireless network and sends a notification about said identifier to said first egress node.

6. The method according to claim 1 or 3, wherein step b) is carried out by said second egress node; and

in a step g), after step b) and prior to step c), said second egress node sends a request to said intermediate node to set up said branch multi-protocol label switching tunnel to said second egress node.

7. The method according to claim 6, wherein, in a step h) after step a) and prior to step b), said mobile host establishes a connection to said second egress node and sends a notification about its own identifier and an identifier of said first egress node to said second egress node; and

said second egress node obtains, from said first egress node, information about an existing multi-protocol label switching tunnel carrying data packets for said mobile host.

8. The method according to claim 7, wherein said information about an existing multi¬ protocol label switching tunnel comprises information about an explicit route of said existing multi-protocol label switching tunnel.

9. The method according to one of the preceding claims, wherein, in a step k), after said step d) is completed, the intermediate node duplicates packets arriving over said multi-protocol label switching tunnel set up in step a) and forwards them to the first and second egress nodes.

10. The method according to claim 9, wherein during step k) said mobile host receives data packets simultaneously from said first and second radio access network domain.

11. The method according to any of the preceding claims, wherein the branch multi¬ protocol label switching tunnel is assigned quality of service parameters equal to corresponding quality of service parameters of the multi-protocol label switching tunnel set up in step a).

12. The method according to any of the claims 9 or 10, comprising, after step k), the steps of

I) sending a request from said first egress node to said intermediate node, to tear down a branch multi-protocol label switching tunnel from the intermediate node to the first egress node, said branch multi-protocol label switching tunnel being associated with the multi-protocol label switching tunnel set up in step a);

m) initiating, by said intermediate node, the tearing down of said branch multi¬ protocol label switching tunnel from the intermediate node to the first egress node.

13. The method according to any of the claims 1 to 8, comprising, after step d), the steps of

14. The method according to any of the preceding claims, wherein step a) comprises the setup of further multi-protocol label switching tunnels to the first egress node for the same mobile host, and step c) and d) are performed for each of the multi¬ protocol label switching tunnels.

15. The method according to any of the preceding claims, wherein said intermediate node sends information to said gateway about changes to routings of multi-protocol label switching tunnels, said changes being initiated by said intermediate node.

16. A telecommunication system comprising a multi-protocol label switching network with a plurality of label switching routers forming nodes of said network, one of said nodes being configured as ingress node to provide connection to an external packet switched network; a mobile host having an internet protocol address and being configured to receive packet data; a plurality of radio access network domains, each of said radio access network domains being configured to provide wireless connection between one of said nodes serving as an egress node of said multi-protocol label switching network, and said mobile host; said network being configured to set up a multi-protocol label switching tunnel from said ingress node to a first egress node connecting a first radio access network domain belonging to a first service area where said mobile host is located, and, if the mobile host changes its location from said first service area of said first radio access network domain to a second service area of a second radio access network domain:

to determine a branch multi-protocol label switching tunnel from an intermediate node to a second egress node serving said second radio access network domain;

to initiate a setup of said branch multi-protocol label switching tunnel by said intermediate node; and

to associate said branch multi-protocol label switching tunnel with said multi¬ protocol label switching tunnel from said ingress node to said first egress node.

17. A method to be executed in an intermediate node of a multi-protocol label switching core network of a wireless network, comprising the steps of

receiving a request to set up a branch multi-protocol label switching tunnel to a second egress node identified in said request; initiating the setup of said branch multi-protocol label switching tunnel; and

associating said branch multi-protocol label switching tunnel with an existing multi¬ protocol label switching tunnel identified in said request.

18. The method of claim 17, further comprising the steps of

receiving, after said setup of said branch multi-protocol label switching tunnel has been completed, a request to tear down a branch multi-protocol label switching tunnel from the intermediate node to the first egress node, said branch multi¬ protocol label switching tunnel being associated with the multi-protocol label switching tunnel set up in step a);

initiating the tearing down of said branch multi-protocol label switching tunnel from the intermediate node to the first egress node.

19. A computer-readable storage medium having stored instructions thereon that, when executed on the processor of a network node, cause the network node to perform the method defined in claim 17 or 18.

20. A method to be executed in a first egress node of a multi-protocol label switching core network of a wireless network, said first egress node receiving data packets over an existing multi-protocol label switching tunnel and forwarding the data packets to a mobile host via a first radio access network, the method comprising the steps of receiving, from the mobile host, information about an identifier of a second egress node of said label switching core network serving a second radio access domain; determining an intermediate node on the route of the existing multi-protocol label switching tunnel as a branch node for a branch multi-protocol label switching tunnel to said second egress node; and

requesting a setup of said branch multi-protocol label switching tunnel, associated with said existing multi-protocol label switching tunnel, from said determined intermediate note.

21. The method according to claim 20, further comprising the step of sending, after said setup of said branch multi-protocol label switching tunnel has been completed, a request to said intermediate node to tear down a branch multi¬ protocol label switching tunnel from the intermediate node to the first egress node, said branch multi-protocol label switching tunnel being associated with the multi¬ protocol label switching tunnel set up in step a);

22. A computer-readable storage medium having stored instructions thereon that, when executed on the processor of a network node, cause the network node to perform the method defined in claim 20 or 21.

23. A method to be executed in a second egress node of a multi-protocol label switching core network of a wireless network, comprising the steps of receiving, from a mobile host, information about an identifier of a first egress node of said label switching core network serving a first radio access domain and information about an identifier of said mobile host; obtaining, from said first egress node, information about an existing multi-protocol label switching tunnel carrying data packets for said mobile host; determining an intermediate node on the route of the existing multi-protocol label switching tunnel as a branch node for a branch multi-protocol label switching tunnel to said second egress node; and requesting from said determined intermediate node a setup of said branch multi¬ protocol label switching tunnel, associated with said existing multi-protocol label switching tunnel, from said determined intermediate node to the second egress node.

24. A computer-readable storage medium having stored instructions thereon that, when executed on the processor of a network node, cause the network node to perform the method defined in claim 23.