EP1730901A1

EP1730901A1 - Providing mobility in a wireless network employing multi-protocol label switching

Info

Publication number: EP1730901A1
Application number: EP04724585A
Authority: EP
Inventors: Velev Genadi
Original assignee: Matsushita Electric Industrial Co Ltd
Current assignee: Panasonic Holdings Corp
Priority date: 2004-03-31
Filing date: 2004-03-31
Publication date: 2006-12-13
Also published as: WO2005096556A1; CN1926822A; BRPI0418648A

Abstract

A method is provided ensuring mobility to a mobile host in a wireless network with 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, a new data tunnel from the ingress node to the new egress node is built up. The mobile host does not change its Internet protocol address during handover.

Description

PROVIDING MOBILITY IN A WIRELESS NETWORK EMPLOYING MϋLTI - PROTOCOL LABEL SWITCHING

BACKGROUND OF THE INVENTION

1. Field of the Invention

The invention generally relates to packet data transmission in wireless networks, such as cellular mobile networks and wireless local area networks, and in particular to protocols providing the routing of packet data through the core network of the wireless network.

In the wireless network, a mobile data terminal (herein called "mobile host", MH), such as a mobile phone or a portable personal computer, is providing a packet switched data connection, for example to a server computer in the Internet or to another mobile data terminal in another wireless network. Packet data in this context may contain hypertext markup language (HTML) documents or coded audio and video signals like voice over Internet protocol, video conferencing signals or video streaming. Especially for real time audio and video data, but also for other types of data, uncontrolled delay or even loss of data packets in the transmission can impact the practical use up to complete uselessness. To handle this problem, mechanisms have been introduced in the related protocols to ensure a certain quality of service (QoS) of the packet data transmission.

The wireless network consists of a so called core network and a plurality of radio access network (RAN) domains providing wireless connection between the mobile host and the core network. The core network has an external connection through a gateway (GW) to other networks, like for example the world wide Internet.

A scenario is considered, in which multi-protocol label switching (MPLS) is deployed as a transport technology between the gateway (GW) and the radio access network domains. To assure the needed QoS requirements, MPLS-based tunnels between the GW and the RAN domains are set up deploying traffic engineering (TE) options of MPLS signalling. A tunnel is a virtual connection between two nodes of a network, wherein payload data is encapsulated with lower layer protocol headers and transmitted over the network, in order to provide a transparent point-to-point connection. The data packets destined to a roaming MH are tunnelled in such MPLS- based tunnel over the core network.

In the context of this invention it will be differentiated between handover procedures managed in the RAN and such managed in the core network assuring the re-routing of the data traffic (or of the data tunnels). Since the MH changes the node of attachment (NoA, i.e. egress LSR of the data tunnel) while moving, it is necessary to provide a method for redirecting packet data in the core network such that they reach the MH without undue delay or even loss of packets.

2. Description of the Related Art

Mobility management solutions for data communication, for example in second generation (Global System for Mobile Communication, GSM) and third generation (Universal Mobile Telecommunications System, UMTS) cellular networks, are proprietary and technology specific. The Internet Engineering Task Force (IETF) has standardized mobility management within Internet protocol-(IP)-based networks known as Mobile Internet protocol (MIP). 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. More detailed information about the functionality of MIP can be found in C. Perkins et. al., "IP Mobility Support for IPv4", RFC 3344, August 2002.

The MPLS concept employs two distinct functional planes: control plane and forwarding plane. In the control plane, standard routing protocols are used to exchange information between routers to build and maintain a forwarding table. Such standard protocols are for example "open shortest path first" (OSPF) and border gateway protocol (BGP). 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 label swapping algorithm. The label switch (known as Label Switch Router, LSR) as a node of the network 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 E. Rosen, Floyd, A. Viswanathan, and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031 , January 2001.

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 can be deployed. The requirements for TE- MPLS are defined in D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999. These capabilities can be used to optimise the utilization of network resources and to enhance traffic oriented performance characteristics. A LSP set up by TE functionality is called TE-LSP or LSP tunnel, since the flow along an LSP is completely identified by the label applied at the ingress node of the path.

MPLS is generic rather than proprietary transport technique, however, mobility is not available in the specifications. Several recent publications have considered the deployment of MPLS in mobile networks. Whereas 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 and 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 consider micro-mobility within the mobile operator's network, the proposal described in Z. Ren, C.-K. Tham, C.-C. Foo, C.-C. Ko, "Integration of Mobile IP and Multi-Protocol Label Switching", in Proc. of the International Conference on Communications (ICC), June 2001 , is a macro-mobility scheme. To deploy mobility in MPLS, MPLS Label Switched Path (LSP) tunnel switching is needed. 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.

In future wireless networks, conversational services (voice and video conferencing) should be supported. To simplify the maintenance of traffic flow in downstream and upstream data paths, bi-directional MPLS tunnels can be used to connect the Gateway and the NoA. The setup of bi-directional LSPs is described in detail in R. Dube, M. Costa, "Bi-directional LSPs for classical MPLS", Internet Draft, Work in Progress (in context of "classical" MPLS) and L. Berger et.al., "Generalized Multi- Protocol Label Switching (GMPLS) Signalling Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003 (in context of Generalized MPLS), which differ only in the message format rather than the procedures for the LSP setup. Using the described mechanism, bi-directional LSP setup is indicated by the presence of an "Upstream Label" in the Path message. With respect to the signalling procedures, there is no difference to the setup of unidirectional tunnels. For more details refer to the documents cited above.

Herein below, the term "initiator" is used to represent the LSR that initiates LSP setup and the term "terminator" to represent the LSR at the other end of the LSP. This means that the ingress LSR in case of uni-directional tunnel corresponds to initiator and the egress LSR corresponds to terminator. As the procedures to set up unidirectional and bi-directional MPLS tunnels do not differ, for the description of the invention, uni-directional tunnels will be regarded and the terms ingress and egress LSR will be used for the ease of explanation. However, this is not to be understood as limiting, and the described procedures can be applied to bidirectional tunnels as well.

The method for setup of bi-directional MPLS tunnels provides means for both symmetric and asymmetric tunnels. Having a voice service or video conferencing, a symmetric bi-directional tunnel can be preferable. In contrary, when the bi-directional tunnel is used to support video streaming, an asymmetric tunnel, where the bandwidth for the upstream path is lower than in the downstream path, can optimally fit to the traffic requirements. The method according to the invention does not impact the procedures for set up symmetric/asymmetric tunnels.

The MPLS architecture does not assume a single label distribution protocol, 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 detail in D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. In particular, the extended RSVP protocol supports the instantiation of explicitly routed LSPs, with or without resource reservations. It also supports smooth rerouting of LSP tunnels, pre-emption, and loop detection.

In the description of the present invention below, RSVP-TE is considered as an exemplary signalling protocol. However, it is understood that the invention can also be applied to other particular protocols providing data tunnels in a packet switched network. Two mechanisms are currently available in RSVP-TE, which allow to perform changes on existing LSP tunnels. These mechanisms are:

- MPLS-based recovery, which assures the re-routing of a LSP when link or node failures occur. The framework for this mechanism is described in RFC 3469 and a proposed solution can be found in "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", where two different techniques for local repair - one-to-one backup (creates detour LSPs at each potential point of local repair) and facility backup (creates a bypass tunnel to protect a potential failure point) are proposed.

- LSP modification as proposed in RFC3209.

Common to both mechanisms cited above is that the SESSION object in RSVP-TE's "Path" message (see RFC 3209) is kept the same, which means that the ingress and egress nodes of the LSP tunnel, as well as LSP ID are not changed. Thus, neither of the above mechanisms can be used for signalling in the present invention, since having a moving MH, the location of the egress LSR changes.

Therefore a method is needed to provide mobility for a mobile host in a wireless network with multi-protocol label switching deployed in the core network, ensuring uninterrupted routing of packet data.

In CA2292252 "SYSTEM AND METHOD FOR MOBILE SPECIFIC LABEL EDGE ROUTER OPERATION WITHIN A CORE AND EDGE NETWORK", a packet switched communications network utilizes 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. In the disclosed method, paths are available between Label Edge Router (LER) and BS. At handover, the Label Edge Router changes the MPLS header of the data packets destined to the old base station with MPLS labels targeting the new base station. CA2292252 proposes a segmentation of the LSP within the MPLS domain, where an intermediate LER changes the packet's header. This requires extended functionality of the intermediate LER. Therefore a simplified method is needed with minimum additional requirements to intermediate nodes of the core network.

WO0045560A2 "PUBLIC MOBILE DATA COMMUNICATIONS NETWORK" is an example of a public mobile access network using a home/foreign agent model where the home and foreign agents transfer data packets over the public mobile access network via a data tunnel. The Mobile IP packets are carried using MPLS LSPs. The home agent is located at a point of presence near to Internet backbone and each base station has implemented foreign agent functionality. A data tunnel is established between the home agent and one of the foreign agents. WO0045560A2 assumes Mobile IP that runs over MPLS LSP. This requires extended functionality from the mobile host. Therefore a method is needed which relieves the mobile host largely from mobility management tasks.

In the method disclosed 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 another tunnelling protocol. This provides a method for 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. WO2003030467A2 assumes that each terminal has a unique MPLS label allowing the tunnelling from ingress point to the mobile host. This requires an adaptation of the signalling in the radio access network. Therefore there is a need for a method which does not include the mobile host in the MPLS functionality.

The introduction of MPLS in mobile networks incorporates the advantages of packet- switched network with possibility to provide QoS (especially relevant for real-time services) and TE. Since the MH roams between BSs (and consequently between ARs), the egress LSR terminating the MPLS tunnel may change during handover. In such a scenario an appropriate method to provide mobility to the MH is needed. Currently known schemes for employing mobility in MPLS are based on Mobile IP and require that the MH accepts a new IP address when it registers at the new AR.

There is a need for an improved and simplified method to provide mobility for a mobile host in a wireless network, in particular in the case when the egress node is changed during a handover.

SUMMARY OF THE INVENTION

Hence, it is an object of this invention to provide mobility in an improved and simplified way to a mobile host in a wireless network with multi-protocol label switching deployed in the core network. It is another object of the invention to provide a possibility to maintain a defined quality of service of the packet switched connection while the mobile host is moving in the service area of the wireless network.

This object is achieved with the method and system of the independent claims. Possible embodiments of the invention are specified in the dependent claims.

In one embodiment of the present invention a method is provided comprising the steps of (a) setting up a first multi-protocol label switching tunnel from an ingress node to a first egress node serving a first radio access network domain and, if the mobile host moves from a service area of the first radio access network domain to a service area of a second radio access network domain, (b) setting up a second multiprotocol label switching tunnel from the ingress node to a second egress node serving the second radio access network domain, the mobile host having an IP address in step (b) identical with an IP address assigned to the mobile host in step (a).

The method of setting up a new tunnel to the second (new) egress node instead of re-routing the existing tunnel provides the advantage of compatibility with existing resource reservation protocols, as the tunnel end point address is a part of the tunnel identifier. The mobility handling is simplified because it can be managed in the ingress node without requiring additional functionality in intermediate nodes and the requirement on the functionality of the MH is reduced.

In another embodiment the second MPLS tunnel may have a quality of service parameter equal to a quality of service parameter of the first MPLS tunnel. This ensures that the quality of service does not change when the MH moves inside the service area of the wireless network.

In a further embodiment the difference between identifiers of the first and second MPLS tunnels is only a tunnel end point address. This provides the advantage of simplified signalling and reduces traffic necessary for signalling in the core network. In still a further embodiment the second MPLS tunnel is built up before the first MPLS tunnel is torn down. This embodiment provides the advantage of improved reliability avoiding the risk of loss of data packages.

In still another embodiment, the setup of the second MPLS tunnel may be initiated from the first egress node.

This embodiment provides the advantage of simplified signalling, as the first (old) egress node has all information necessary to request the setup of a new tunnel to the second (new) egress node.

In still a further embodiment, the method may comprise the steps of (c) informing the first egress node about the handover; (d) sending, by the first egress node, (d1 ) an acknowledgement for attachment to the second egress node, and (d2) a message to the ingress node with information about the second egress node; (e) starting, by the ingress node, upon reception of the message specified in (d2), the setup of a second multi-protocol label switching tunnel to the second egress node; (f) completing, by the second egress node, after receiving the acknowledgement as specified in (d1 ) and signalling from the ingress node concerning the setup of the second multi-protocol label switching tunnel, handover procedures in the network; (g) switching, by the ingress node, traffic from the first to the second tunnel when a tunnel setup acknowledge is received; and (h) tearing down the first tunnel by the ingress node.

This embodiment provides the advantage of quick and reliable signalling while requiring only one element in the protocol, which is not part of the current standard and has to be newly introduced.

In still a further embodiment, step (c) comprises (d) informing, by the mobile host, the second egress node about the IP address of the mobile host and an IP address of the first egress node; and (c2) requesting, by the second egress node, an authorization from the first egress node.

In still another embodiment the message in step (d2) is a dedicated message in a resource reservation protocol. This embodiment provides the advantage of compatibility with existing protocols. In still another embodiment the message in step (d2) contains a dedicated object in a resource reservation protocol. This embodiment provides the advantage of compatibility with existing protocols while at the same time minimising signalling traffic, as identical elements common to both tunnels are not repeated in step (d2).

In still a further embodiment the first egress node is informed in step (c) about the handover and about an identifier of the second egress node by the mobile host. This embodiment may work also in cases where there is no direct communication between first and second egress node possible over the core network, for example with loosely coupled radio access network domains.

In still a further embodiment the ingress node checks in step (e) for other available tunnels to the mobile host via the first egress node and starts a set up of a tunnel to the second egress node for each such tunnel. This embodiment has the advantage of greatly reducing signalling between the first egress node and the ingress node, because the first egress node has to send the message in step (d2) only once for all existing tunnels to the same MH.

In still a further embodiment the setup of the second multi-protocol label switching tunnel is initiated from the second egress node.

In still another embodiment the method may comprise the steps of (i) informing, by the mobile host, the first egress node about an IP address of the second egress node; (k) sending context information from the first egress node to the second egress node; (I) sending a request from the second egress node to the ingress node to set up the second multi-protocol label switching tunnel; (m) starting, by the ingress node, upon reception of the request specified in (c), the setup of the second multi-protocol label switching tunnel to the second egress node; (n) completing, by the second egress node, after receiving signalling from the ingress node concerning the setup of the second multi-protocol label switching tunnel, handover procedures in the network; (o) switching, by the ingress node, traffic from the old tunnel to the second tunnel when a tunnel setup acknowledge is received; and (p) tearing down the old tunnel by the ingress node. This embodiment provides the advantage of quick and reliable signalling while requiring only one element in the protocol, which is not part of the current standard and has to be newly introduced.

In still a further embodiment, the request in step (I) may be a dedicated message in a resource reservation protocol. This embodiment provides the advantage of compatibility with existing protocols.

In still a further embodiment, the request in step (I) may be a dedicated object in a resource reservation protocol. This embodiment provides the advantage of compatibility with existing protocols while at the same time minimising signalling traffic, as identical elements common to both tunnels are not repeated in step (I).

In still another embodiment, the ingress node checks in step (m) for other available tunnels to the mobile host via the first egress node and starts a set up of a second tunnel for each such tunnel. This embodiment has the advantage of greatly reducing signalling between the first egress node and the ingress node, because the first egress node has to send the message in step (I) only once for all existing tunnels to the same MH.

In still another embodiment, the wireless network is a cellular network. This embodiment provides the advantage of compatibility with existing cellular networks.

In still another embodiment, the wireless network is a wireless local area network. This embodiment provides the advantage of compatibility with existing local area networks.

In an 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 and said mobile host, said network being configured to set up a first 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 set up a second multi-protocol label switching tunnel from said ingress node to a second egress node connecting said second radio access network domain, wherein said mobile host does not change said Internet protocol address.

A telecommunication system according to this embodiment provides the advantage that it can be obtained by upgrade of existing systems, due to the compatibility with existing resource reservation protocols. There is no requirement for additional functionality in intermediate nodes and the requirement on the functionality of the MH is reduced.

In a further embodiment, an apparatus forming a first egress node of a multi-protocol label switching network being configured to receive packet data from an ingress node of said network through a multi-protocol label switching tunnel and forward said packet data to a mobile host via a first radio access network domain, is further adapted to carry out the steps of sending, upon receiving information about a handover of said mobile host from said first radio access network domain to a second radio access network domain, an acknowledgement message to a second egress node connecting said second radio access network domain; and sending a message to said ingress node with information about said second egress node.

An apparatus according to this embodiment can advantageously serve as egress node in a telecommunication system according to the preceding embodiment.

In still another embodiment, an apparatus forming an ingress node from an external packet switched network to a multi-protocol label switching network, being configured to receive packet data from said external network and forward said packet data to a mobile host via a multi-protocol label switching tunnel, a first egress node of the multi-protocol label switching network, and a first radio access network domain, is further adapted to carry out the steps of starting, upon reception of a message from said first egress node with information about a second egress node connecting a second radio access network domain, into which the location of said mobile host is handed over, a setup of a second multi-protocol label switching tunnel to said second egress node; switching, upon reception of a tunnel setup acknowledge from said second egress node, traffic from said first to said second tunnel; and tearing down said first tunnel.

An apparatus according to this embodiment can advantageously serve as ingress node (gateway) in a telecommunication system according to another embodiment of this invention.

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 shows an exemplary architecture of a wireless network.

Figure 2 illustrates a handover of a mobile host between two egress nodes of the core network.

Figure 3 illustrates the protocol stacks in the entities shown in Figure 2.

Figure 4 depicts the signalling flow between the entities involved in the handover procedure when the setup of the new MPLS tunnel is initiated from the first (old) egress node.

Figure 5 shows an alternative to the signalling flow shown in Figure 4.

Figure 6 shows the signalling flow between the entities involved in the handover procedure when the setup of the new MPLS tunnel is initiated by the second (new) egress node.

Figure 7 illustrates a procedure for handling multiple tunnels to a mobile host

Figure 8 shows the format of a MPLS tunnel identifier.

Figure 9 shows the format of a SESSION_ATTRIBUTE object in RSVP-TE.

Figure 10 shows the constitution of a PATH message in RSVP-TE. Figure 11 shows a possibility for a new message in RSVP-TE requesting the setup of a new MPLS tunnel from the ingress node.

Figure 12 shows a possibility for a new object in RSVP-TE requesting the setup of a new MPLS tunnel from the ingress node.

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 gives an example of a network structure 100 where TE MPLS is deployed in a wireless network consisting of core network 113 and radio access network (RAN). In the RAN several access technologies could be supported, e.g. wireless local area network (WLAN), 3rd Generation (3G) RAN and future 4th Generation (4G) RAN or cordless technologies like DECT. Each of the different radio access technologies is organized regionally in radio access domains managed by an access router (AR). The ARs are connected to the Core network 113 through a Core Edge Router (CER). 3G and 4G access domains 104, 105 are connected to CER2 8.

The MPLS tunnel 4 or 5 is set up between an ingress LSR 1 in the mobile network (e.g. Gateway, GW) and an egress LSR 2 or 3, e.g. NoA (AR or base station, BS). The packets destined to a MH 6 are encapsulated at the ingress LSR 1 (i.e. MPLS label is added to the IP header), transported over the previously set up MPLS tunnel 4, de-capsulated at the egress LSR 2 and transported further according to the native IP address 7. The case is regarded where the GW 1 performs also the functionality of Foreign Agent (FA) as described in the MIP specification RFC 3344, and thus, it can assign a CoA address 7 to a foreign MH 6 which is then valid within the whole mobile network 100. The egress LSR 2 is implemented in the NoA, where the MH 6 needs to authenticate at handover. In the system architecture shown in figure 1 , the NoA is AR, but in other scenarios is can be a BS. The MH 6 does not support MPLS. Further, it can be seen from figure 1 that the MPLS tunnel is terminated at the AR, since the packet transport within the radio access domain 104 is assumed to be performed in Layer 2 and one radio access domain forms a kind of Local Area Network (LAN). However, it is possible that the MPLS tunnel is terminated at another node, as for example BS, where the functionality according to the invention is implemented.

The MH 6 is a mobile computing device like for example a notebook or 3G's User Equipment (UE) etc. The MH 6 is connected via wireless link with a BS 113, which terminates the wireless communication and assures wire line packet-switched oriented connection with further entities in the mobile network. The BS might be the last entity, which terminates the MPLS tunnel 4.

When the MH 6 moves in the direction of arrow 115, such that it enters the service area of BS 114 and is about to leave the service are of BS 113, a handover is necessary, not only between BS 113 and BS 114, but also between the first RAN domain 104 and the second RAN domain 105. In order to be able to continuously deliver data packets to the MH 6, the network builds up a new LSP 5 to the second egress node 3. The MH's location database is not distributed in the network, but rather concentrated in the ingress LSR, where the database is created and maintained. Employing the database, the ingress LSR can map each incoming data packet to a MPLS tunnel based on the IP address. Thus it is not necessary to change the IP address of the MH as long as the MH is roaming within the same wireless network.

Referring now to figure 2, a detail of the wireless network 100 is shown. First, the mobile host 6 has a wireless connection to the old egress LSR 2, which receives data packets from the gateway or ingress LSR 1 over a first tunnel or LSP 4. In the example of figure 2, the LSP passes one intermediate LSR 8, which may be the core edge router. In another example, LSP 4 might pass a plurality of such intermediate LSRs. After a handover, the MH 6 has a wireless connection to the new egress LSR 3. A new LSP 5 is built up from ingress LSR 1 to the new egress LSR 2 and the data traffic is switched from LSP 4 to LSP 5. After that, the old LSP 4 may be torn down.

Figure 3 illustrated the protocol stack in the data plane of a MPLS network. 301 is the protocol stack of the gateway 1 , 302 belongs to the intermediate LSR 8, 303 to the respective egress LSR 2 or 3, and 304 to the mobile host 6. Every pair of neighbouring nodes in the network maintains a bidirectional data connection 305, 306 in the MPLS protocol plane. The MPLS tunnel 307 is a virtual point-to-point connection from ingress node 1 to egress node 2 or 3. It is implemented by sending encapsulated data packets hop-wise over the MPLS data connections 305 and 306. The egress node 2 or 3 forwards the received data packets to the MH 6, for example through a connection 308 in layer 2 of the radio access network protocol.

Figure 4 shows an illustrative example of a method to set up a new MPLS tunnel from the ingress node to a new egress node to which the mobile host is handed over, initiated by the old egress node where the mobile host has been attached so far. The embodiment described in Figure 4 exhibits the advantage that the old egress node has exact knowledge of the (1 ) MH's authorization and connection session parameter, (2) MPLS tunnel's ingress node, (3) tunnel traffic parameters and (4) the IP address of the new egress node. A detailed description of the steps for setting up the new MPLS tunnel are described as follows:

When the MH detects in step 401 a new NoA (will be the new egress LSR), the MH requires in step 402 authentication and informs it about its own IP address and the IP address of the current (old) NoA (old egress LSR).

The new egress LSR does not know, if the MH is authorized for using the network resources, and therefore, it requests in step 403 an authorization from the old egress LSR, which still serves the MH. Extensible Authentication Protocol (EAP) represents one possibility how the communication can proceed between MH and new egress LSR, as well as between new egress LSR and old egress LSR.

When receiving a request from the new egress LSR, the old egress LSR checks in step 404 its database. If the MH is currently served (i.e. also authorized and active tunnels are established from the Gateway) by the old egress LSR, the LSR initiates two activities to enable the handover: (i) it sends an acknowledgement for attachment 405 to the new egress LSR and (ii) it sends a message 406 to the ingress LSR with an update of the new egress LSR. The latter message includes e.g. the IP addresses of the new egress LSR and of the MH. The ingress LSR needs the information about the concerned MH because it should update its database, where the incoming IP packets are classified to the MPLS tunnels according the MH's IP address.

At receiving the update message from the egress LSR, the ingress LSR starts in step 407 the setup of a new TE tunnel to the new egress LSR with the same parameter as the old tunnel. During the setup procedure, the ingress LSR still sends the MH's traffic on the old tunnel.

After receiving the acknowledgement for attachment and the tunnel setup signalling, the new egress LSR completes the handover procedures in the RAN in order to accomplish the whole handover of the MH.

Finally, when the tunnel setup acknowledgement 408 is received by the ingress LSR, it switches in step 409 the traffic from the old to the new tunnel and tears down the old tunnel in step 410.

Referring now to figure 5, alternatively to the signalling flow shown in 403 of figure 4, the old egress LSR can obtain the new egress LSR's identifier (e.g. IP address) by the MH as shown in step 501. This would be feasible in the case where the network configuration does not allow a direct communication between new and old egress LSRs (e.g. with loose coupling between RAN domains). In this scenario, the MH can inform the old egress LSR about the new NoA (new egress LSR) and consequently the old egress LSR initiates the signalling to the ingress LSR.

An advantage of the methods described in figures 4 and 5 is that the old egress LSR can directly signal the identifier (e.g. IP address) of the new egress LSR's to the ingress LSR, which speeds up the procedure by saving the delay of additional signalling, which would otherwise be necessary.

Figure 6 illustrates another embodiment of the invention, where the signalling initiated by the new egress LSR. This option is feasible in the case, where the new and old egress LSRs communicate with each other in order to exchange traffic context parameters, like for example the existing tunnel traffic parameters. In the 3rd Generation Partnership Project the traffic context parameters are called PDP context. In step 601 , the new egress LSR sends periodically a broadcast message. In case of version 6 of the Internet protocol, for example, a router advertisement message is sent every 3 seconds. Upon receiving it, the MH informs in step 602 the old egress node about the IP address of the new egress node. Subsequently, the old egress LSR communicates the traffic context in step 603 to the new egress LSR. In this way the new egress LSR is informed about the identifier (IP address) of the ingress LSR, which is a part of the MPLS tunnel parameter contained in the context. Now, the new egress LSR can contact the ingress LSR in step 604 and require the setup of a new MPLS tunnel to the new egress LSR. The signalling is completed by steps 605 to 608 in the same way as described before in connection with figure 4.

In the procedures described above, a setup of one MPLS tunnel per user is regarded. However, the method can also be applied in cases, in which one user is connected via multiple tunnels to the gateway. This is the case when the tunnels are set up per application because different applications may have different QoS requirements. When a user of a MH connected to the gateway via multiple tunnels moves to new NoA, then one of the methods described above can be applied for each of the tunnels separately. However, this process can be optimised in another embodiment with the exemplary procedure shown in figure 7. When the ingress LSR receives a notification message from the old egress LSR to establish one new tunnel to the new egress LSR, the ingress LSR starts procedure 700. First, in step 701 , a new list is created having the existing MPLS tunnel specified in the request message as first entry. Then the ingress LSR checks its database in step 702 for other available tunnels to the same user. Other tunnels found as a result of this search are added to the list. In step 703, the ingress node sets up a new MPLS tunnel to the new egress LSR for the first entry in the list, which is deleted in step 704. In step 705, it is checked whether the list is empty. If this is the case, the procedure is terminated in step 706. Otherwise it jumps back to step 703 to treat the next entry in the list.

The methods proposed so far can be applied for both uni-directional and bidirectional MPLS tunnels. The procedures described above will be the same in both cases, since the setup of bi-directional tunnels is initiated as usual by the ingress LSR (initiator) and the only difference to uni-directional tunnels are the RSVP-TE message formats.

Referring now to figure 8, an exemplary data structure 800 is shown, which unambiguously identifies an MPLS tunnel. It comprises two objects from the RSVP- TE protocol, namely a SESSION object 801 and a SENDER_TEMPLATE or FILTER_SPEC object 802. The SESSION object 801 contains the IP address 803 of the tunnel end point, i.e. the egress node of the network, a tunnel identifier 805 and an extended tunnel identifier 806. Field 804 has no meaning in the context of the present invention and may be filled with zeroes. The SENDER_TEMPLATE or FILTER_SPEC object contains the IP address of the tunnel sender, i.e. the ingress node of the network, and the tunnel identifier 809. Field 808, again, is filled with zeroes. The structure in figure 8 is only an example of a data structure identifying a tunnel. Other structures could be thought of serving the same purpose.

Figure 9 shows the data structure of a SESSION_ATTRIBUTE object 900 in RSVP- TE as an example of a data structure conveying QoS information. Fields 901 to 903 are optional and not explained in further detail. Field 904 specifies the priority of the tunnel in comparison to other traffic with respect to taking resources and can assume a value between 0 and 7. Field 905 specifies the priority of the tunnel for holding resources. The flags 906 are control switches concerning the routing of the tunnel and are not regarded in detail in this context. Field 908 contains a null padded session name and field 907 the length of this name. In other protocols other structures than that shown in figure 9 could serve the same purpose of specifying the quality of service of the tunnel.

Figure 10 illustrates the structure of a RSVP-TE PATH message 1000, which is sent by the ingress node in order to built up a new tunnel, like for example in steps 407 and 605 of figure 4 and 6, respectively. It contains the SESSION object 801 explained in conjunction with figure 8, the SESSION__ATTRIBUTE object 900 from figure 9 and the SENDER_TEMPLATE object from figure 8. The EXPLICIT_ROUTE object contains subobjects defining network nodes which should or must be passed by the route of the tunnel. Other fields of the PATH message 1000 are not explained in more detail.

According to one embodiment of the present invention, the difference of the identifier between the old and new tunnel is only the tunnel end point address 803. This means that the same SENDER_TEMPLATE and FILTER_SPEC objects 802 together with the modified SESSION 801 and EXPLICIT_ROUTE 1005 objects are sent with the Path message 1000 along the path of the new MPLS tunnel. Since the mobile operator has a perfect knowledge of the network's topology, the route for the new tunnel can advantageously be determined fast.

For the implementation of the proposed method a new object or message is necessary in the protocol for the request to set up a new MPLS tunnel for an existing one, used for example in step 406 or 604. Figure 11 illustrates an exemplary proposal for a possible structure of such a message 1100. As the identifier of the new requested tunnel differs from the identifier of the old existing tunnel only by the end point address, message 1100 may contain besides a header 1101 only the old SESSION object with the IP address of the old egress node and the new SESSION object with the IP address of the new egress node. Thus, message 1100 can be kept advantageously short.

The case where a new object 1200 (normally included in the Path message) in the protocol is used for the request of the setup of a new tunnel, is illustrated in an example in figure 12. In this proposal, object 1200 is obtained by an extension of SESSION object 801 , to which the IP address 1201 of the new egress node is appended.

As a possible advantage, the procedures described in figures 4 to 6 allow seamless mobility for the MH, because the connection with the correspondent counterpart is kept alive during handovers. These handovers can be between base stations within both the same or different access technologies. The described handover procedures in the core network assure the mobility of the tunnels, and may fulfil this mobility in a fast manner without packet losses. This is achieved by the principle of "make-before- brake", as the new MPLS tunnel is set up before the traffic is switched on the new tunnel, and last the old tunnel is torn down.

To avoid the negotiation of the session QoS parameters between MH and networks managing entity about the traffic context, the proposed method uses the same tunnel parameter as in the old tunnel. Another benefit of the proposed method is that its deployment requires no changes in the implementation of the signalling protocols apart from ingress and egress LSR. That is, no changes in the intermediate LSRs are necessary. Further, the proposed method makes widely use of available RSVP-TE signalling and minimises necessary modifications.

Another benefit of the methods described above is that there is no need to implement the micro-mobility Mobile IP in the network entities except in the Gateway and the MH. Since most of the routers distributed on the market now are MPLS-capable, the embodiments presented above can be implemented with handover procedures only on the network side. Signalling and processing effort is reduced compared to micro- mobility MIP extensions. Further the MH is relieved from mobility management tasks, which are taken over by the network equipment. This enables a reduction of processing power and consequently leads to lower power consumption, smaller batteries and smaller MH.

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 of a mobile host in a wireless network using 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 first 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) setting up a second multi-protocol label switching tunnel from said ingress node to a second egress node serving said second radio access network domain; said mobile host having an IP address in step b) identical with an IP address assigned to said mobile host in step a).

2. The method according to claim 1 , said second multi-protocol label switching tunnel having a quality of service parameter equal to a quality of service parameter of said first multi-protocol label switching tunnel.

3. The method according to claim 2, wherein the difference between identifiers of said first and second multi-protocol label switching tunnels is only a tunnel end point address.

4. The method of claim 3, wherein said second multi-protocol label switching tunnel is set up before said first multi-protocol label switching tunnel is torn down.

5. The method of claim 4, wherein said setup of said second multi-protocol label switching tunnel is initiated from said first egress node.

6. The method of claim 5, comprising the steps of c) informing said first egress node about said handover d) sending, by said first egress node, d1 ) an acknowledgement for attachment to said second egress node; and d2) a message to said ingress node with information about said second egress node; e) starting, by said ingress node, upon reception of the message specified in d2), said setup of a second multi-protocol label switching tunnel to said second egress node; f) completing, by said second egress node, after receiving the acknowledgement as specified in d1 ) and signalling from said ingress node concerning said setup of said second multi-protocol label switching tunnel, handover procedures in said network; g) switching, by said ingress node, traffic from said first to said second tunnel when a tunnel setup acknowledge is received; and h) tearing down said first tunnel by the ingress node.

7. The method according to claim 6, wherein step c) comprises d ) informing, by said mobile host, said second egress node about said IP address of said mobile host and an IP address of said first egress node; and c2) requesting, by said second egress node, an authorization from said first egress node.

8. The method according to claim 7, wherein said message in step d2) is a dedicated message in a resource reservation protocol.

9. The method according to claim 7, wherein said message in step d2) contains a dedicated object in a resource reservation protocol.

10. The method according to claim 6, wherein in step c) said first egress node is informed about said handover and about an identifier of said second egress node by said mobile host.

11. The method according to claim 6, wherein said ingress node checks in step e) for other available tunnels to said mobile host via said first egress node and starts a set up of a tunnel to said second egress node for each such tunnel.

12. The method of claim 4, wherein said setup of said second multi-protocol label switching tunnel is initiated from said second egress node.

13. The method of claim 12 comprising the steps: i) informing , by said mobile host, said old egress node about an IP address of said second egress node; k) sending context information from said old egress node to said second egress node;

I) sending a request from said second egress node to said ingress node to set up said second multi-protocol label switching tunnel; m) starting, by said ingress node, upon reception of said request specified in c), said setup of said second multi-protocol label switching tunnel to said second egress node; n) completing, by said second egress node, after receiving signalling from said ingress node concerning said setup of said second multi-protocol label switching tunnel, handover procedures in the network; o) switching, by said ingress node, traffic from said old tunnel to said second tunnel when a tunnel setup acknowledge is received; and p) tearing down said old tunnel by said ingress node.

14. The method according to claim 13, wherein said request in step I) is a dedicated message in a resource reservation protocol.

15. The method according to claim 13, wherein said request in step I) is a dedicated object in a resource reservation protocol. *

16. The method according to claim 13, wherein said ingress node checks in step m) for other available tunnels to said mobile host via said old egress node and starts a set up of a second tunnel for each such tunnel.

17. A method according to one of the claims 1 to 16, wherein said wireless network is a cellular network.

18. A method according to one of the claims 1 to 16, wherein said wireless network is a wireless local area network.

19. 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 and said mobile host; said network being configured to set up a first 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 set up a second multi-protocol label switching tunnel from said ingress node to a second egress node connecting said second radio access network domain, wherein said mobile host does not change said Internet protocol address.

20. An apparatus forming a first egress node of a multi-protocol label switching network being configured to receive packet data from an ingress node of said network through a multi-protocol label switching tunnel and forward said packet data to a mobile host via a first radio access network domain, further being adapted to carry out the following steps: send, upon receiving information about a handover of said mobile host from said first radio access network domain to a second radio access network domain, an acknowledgement message to a second egress node connecting said second radio access network domain and send a message to said ingress node with information about said second egress node.

21. An apparatus forming an ingress node from an external packet switched network to a multi-protocol label switching network, being configured to receive packet data from said external network and forward said packet data to a mobile host via a multi-protocol label switching tunnel, a first egress node of the multi-protocol label switching network, and a first radio access network domain, further being adapted to carry out the following steps: start, upon reception of a message from said first egress node with information about a second egress node connecting a second radio access network domain, into which the location of said mobile host is handed over, a setup of a second multi-protocol label switching tunnel to said second egress node; switch, upon reception of a tunnel setup acknowledge from said second egress node, traffic from said first to said second tunnel; and tear down said first tunnel.