EP1759494A1

EP1759494A1 - Method for utilizing the same ip address when changing from one service area into another in a mpls based wireless communication system

Info

Publication number: EP1759494A1
Application number: EP04739623A
Authority: EP
Inventors: Genadi Velev; Tetsuya Kawakami
Original assignee: Matsushita Electric Industrial Co Ltd
Current assignee: Panasonic Holdings Corp
Priority date: 2004-06-04
Filing date: 2004-06-04
Publication date: 2007-03-07
Also published as: WO2005119978A1

Abstract

A method is provided for ensuring mobility to a mobile host in a wireless network with multi protocol label switching deployed in the packet switched core network. A Mobile Host has a packet switched connection via a bidirectional Multi-Protocol Label Switching data tunnel from a first ingress node of the core network serving the service area of a radio access network domain, where the Mobile Host is currently located, to an egress node of the core network. When the mobile host moves to a service area of a second radio access network domain, the node of attachment serving the second radio access network domain is informed about the Internet Protocol address of the egress node of the existing data tunnel together with respective LSP tunnel parameters and sets up a new bidirectional Multi-Protocol Label Switching tunnel to the egress node specified by the Internet Protocol Address. During this handover, the Mobile Host does not change its own Internet Protocol address.

Description

METHOD FOR UTILIZING THE SAME IP ADDRESS WHEN CHANGING FROM ONE SE_RV_IC_{E ARE}A INTO ANOTHER IN A MPLS BASED WIRELESS COMMUNICATION SYS_TEM

BACKGROUND OF THE INVENTION

1. Field of the invention

The invention generally relates to signalling in packet switched data traffic on 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 between a Gateway (GW) and a Radio Access Network (RAN). To assure the Quality of Service (QoS) requirements, MPLS is deployed for constraint-based routing of traffic, which is also known as Traffic Engineering (TE) mode of MPLS. Employing TE MPLS, Label Switched Path (LSP) tunnels can be set up between the RAN and the GW in order to tunnel the data packets destined for a roaming Mobile Host (MH) over the core network. The invention is directed to the case where a packet switched connection has been originated by the MH. Therefore the Node of Attachment of the MH is the ingress node of the network, and the GW is the egress node.

2. Description of the Related Art

In the following it will be distinguished between handover procedures managed in the Radio Access Network (RAN) and handovers managed in the core network, which occur when the mobile host is moving between different RAN domains. More specifically this invention relates to the latter case, i.e. mobility in the core network. If the MH changes the Node of Attachment (NoA, i.e. the ingress LSR of the data tunnel) while moving, it is necessary to maintain existing packet switched connections to gateways with the required quality of service.

Mobility management solutions for data communication in cellular networks, for example in second generation (GSM) and third generation (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 IP (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 a static "home" address for the mobile host by an additional 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, pp. 1-62, August 2002.

The MPLS concept employs two distinct functional planes: control plane and forwarding plane. In the control plane, standard routing protocols like "Open Shortest Path First" (OSPF) or Border Gateway Protocol (BGP) are used to exchange information between routers in order to build and maintain a forwarding table. In the forwarding plane, the forwarding component searches in the forwarding table when data packets arrive, in order 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) 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, A. Viswanathan, and R. Gallon, "Multiprotocol Label Switching Architecture", RFC 3031, pp. 3-37, January 2001.

The MPLS described above has still the hop-by-hop forwarding paradigm inherited from standard IP routing. To increase efficiency and the reliability in the MPLS domain, as well as to assure a certain Quality of Service, Traffic Engineering (TE) capabilities can be added to MPLS. 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, pp. 4-10, 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 constraints is called LSP tunnel. 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 D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, pp. 7-15 and 17- 49, December 2001.

Although MPLS is generic transport technique, however, mobility is not available in the specifications. Recent work has considered the deployment of MPLS in mobile networks. While F. Chiussi, D. Khotimsky, and S. Krishnan, "A Network Architecture for MPLS- Based Micro-Mobility", pp. 3-5, 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", pp. 2-4, 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", pp. 2-4, in Proc. of the International Conference on Communications (ICC), June 2001 is a macro-mobility scheme. To deploy mobility in MPLS-based networks, LSP tunnel switching is necessary. 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 Care of Address after a handover.

The method according to the invention can be deployed in 3rd Generation (3G) and Beyond 3G networks, where conversational services (voice and video conferencing) should be supported by packet-oriented data transmission. 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 references 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) Signaling Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, pp. 8-9, 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, bidirectional 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 uni-directional tunnels. More details are given in the cited documents.

In the concept of bi-directional tunnels, 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 the initiator and the egress LSR corresponds to the terminator.

For reasons which will be explained below in conjunction with the detailed description of the invention, only bi-directional tunnels will be considered, wherein the initiator (ingress LSR) is the NoA and the terminator (egress LSR) is the GW. Therefore the terms "ingress LSR" and "egress LSR" will be used herein below instead of "initiator" and "terminator".

The method for setup of bi-directional LSP tunnels provides means for both symmetric and asymmetric tunnels. For voice and video conferencing services a symmetric bidirectional tunnel is advantageous. When a bi-directional tunnel is used to support video streaming, an asymmetric tunnel, where the bandwidth for the upstream direction is lower than in the downstream direction, can optimally fit the traffic requirements. The method according to the present invention can be applied to both symmetric and asymmetric tunnels.

Figure 1 gives an example of a network architecture in which the present invention can be applied. A mobile network 100 is illustrated with TE MPLS deployed in the Core network 101 and optionally also in the Radio Access Network (RAN). In the RAN various access technologies could be applied, e.g. Wireless LAN, 3rd Generation (3G) RAN and future 4th Generation (4G) RAN. Each of the different radio access technologies are organized regionally in radio access domains 102, 103 managed by an entity, which is herein below called Node of Attachment (NoA) 104, 105. The NoAs are connected to the Core network 101 through Core Routers (CR) 106, 107. As an illustrative example, two distinct access domains 102, 103 out of a possible plurality are connected to CR2 107. The data transport in the access domains is carried out on the link-layer (also called Layer 2, L2) of the protocol. In Figure 1, the names without parenthesis show the functional categorization as for instance "NoA", "router", "gateway" etc. The names in parenthesis represent MPLS terminology, e.g. "ingress LSR", "egress LSR" etc.

The Gateway (GW) 108 of the mobile network, as shown in Figure 1, is an entity implementing the functions of egress LSR in the MPLS transport layer and Foreign Agent (FA) or Access Router (AR) in the IP layer (Layer 3, L3). Both terms FA and AR will be used herein below because both Internet Protocol versions, IPv4 and IPv6, are supported in this invention. 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., cited above. It is not necessary that the egress LSR and FA/AR are physically located in the same entity. However, it is rather important that egress LSR and FA/AR communicate via common L2 technology as shown in Figure 3. According to this latter figure, the mobile network provides L2 connectivity between the FA/AR and MH 109. FA/AR provides L3 services to the MH 109. The communication between MH and FA/AR, as well as the mobile IP functionality are not discussed herein in more detail. Herein below, "GW" will be used as a generic term including the functions of egress LSR and FA/AR.

The L2 connection between MH 109 and GW 108 can be logically separated in two connections: one between MH 109 and NoA (carried out in L2) 104, 105 and another one between NoA 104, 105 and GW 108 based on MPLS transport. In this context, the ingress LSR is in the NoA 104, 105 and the egress LSR is in the GW 108. The packets from the MH 109 are encapsulated at the ingress LSR 104, 105 (i.e. addition of MPLS label), transported over the pre-set up LSP tunnel 110, 111 , de-capsulated at the egress LSR 108 and transported further according to the destination IP address. In the system architecture shown in Figure 1 and in the context of this invention, the NoA 104, 105 is an entity implementing in the data plane (i) L2 protocol(s) used in the access domain and (ii) ingress LSR functionality. In the control plane, the NoA implements (i) MPLS control protocol(s), i.e. RSVP-TE, and (ii) some context transfer mechanism, which allows the NoA 104, 105 to exchange Authorisation, Authentication and Accounting (AAA) related information and MPLS-related information with other NoAs or a central entity 112. For instance, the NoA 104, 105 may be implemented in an Access Controller (AC or also called Access Bridge) as specified in the lETF's "Control And Provisioning of Wireless Access Points" (CAPWAP) working group , but in other scenarios it can be implemented in a Base Station (BS) 113, 114, 115 or Access Point (AP). Since the packet transport within the radio access domain is usually performed in Layer 2 and one radio access domain forms a kind of Local Area Network (LAN), in Figure 1 the LSP tunnel 110, 111 starts from the NoA 104, 105, respectively as an illustrative example. A more general overlay model is depicted in Figure 2. Further herein below, the term "NoA" is used for the first MPLS-capable node from the perspective of the MH 109. The MH 109 is not required to support MPLS, and communicates with the NoA on Layer 2 (L2). The protocol stacks for the data transport between MH 109 and Gateway 108 can be seen in Figure 3.

The term Mobile Host (MH) used herein is a common representative for a mobile computing device as notebook, 3G User Equipment (UE) or even a Personal Area Network (PAN), which is formed by several personal devices. The MH 109 is connected via wireless link with one of the BS 113, 114, 115, which terminate the wireless communication and provide wire line packet-switched connection with further entities in the mobile network. The BS might but need not be the first entity which initiates the LSP tunnel.

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 Quality of Service (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 RFC3209 cited above. 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.

Herein, RSVP-TE is considered as a signalling protocol. Two mechanisms are currently available in RSVP-TE, which allow to perform changes on existing LSP tunnels. These mechanisms are discussed in more detailed below.

- One mechanism is MPLS-based recovery, which assures the re-routing of LSP when link or node failures occur. The framework for this mechanism is described in V. Sharma, F. Hellstrand, "Framework for Multi-Protocol Label Switching (MPLS)-based Recovery", RFC 3469, pp. 32-35, February 2003, and a proposed solution can be found in P. Pan, D.-H. Gan, G. Swallow, J. P. Vasseur, D. Cooper, A. Atlas, M. Jork, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", pp. 2-4, 7-9, Internet Draft, Work in Progress, where two different techniques for local repair - one-to-one backup and facility backup - are proposed. In this context, the LSP re-routing is with respect of the LSP's intermediate LSRs, without changing the edge LSRs, i.e. ingress and egress LSR. The other mechanism is LSP modification as proposed in RFC3209 cited above.

Common to the mechanisms explained above is that the SESSION object in RSVP-TE's "Path" message (see RFC3209 cited above) 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 context of figure 1 , since the location of the ingress LSR changes when MH 109 is handed over from BS 113 in RANI 102 to BS 114 in RAN2 103. In IP access networks that support host mobility, the MH may run services on subnets that are left behind when the host moves. Examples of such services are Authentication, Authorization, and Accounting (AAA), header compression and Quality of Service (QoS). In order for the MH to obtain those services on the new subnet, the host must explicitly re-establish the service by performing the necessary signalling flows from scratch. One approach in Internet Engineering Task Force (IETF) to speed up this process is to transfer information on the existing state associated with these services, or context, to the new subnet, a process called "context transfer". Detailed description of the context, context transfer and the motivation to perform this activity process can be found in J. Kempf et. al., "Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network", RFC 3374, pp. 3-7, September 2002 and on the homepage of Seamoby working group in IETF .

CA2292252 discloses a System and method for mobile specific label edge router operation within a core and edge network. In this document, the 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 WO0045560A2 a public mobile access network is implemented 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. In this proposal, 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.

WO2003030467A2 describes 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.

International application No. PCT/EP2004/003421 teaches a method for a handover in the case that the Mobile Host is attached to the egress node of the core network. In this case the MPLS tunnel has been initiated from a gateway or from another node of attachment serving another mobile host.

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 ingress node is changed during a handover.

SUMMARY OF THE INVENTION

It is an object of the present 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.

This object is achieved by the method, telecommunication system and apparatus according to the independent claims. Advantageous embodiments are specified in the dependent claims.

In one embodiment, a method for providing mobility to 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 comprises the steps of a) setting up a first bidirectional multi-protocol label switching tunnel from a first ingress node to an egress node, the first ingress 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) informing a second ingress node serving the second radio access network domain about an internet protocol address of the egress node and LSP tunnel parameters identifying the existing tunnels connecting first ingress node to the egress node; and c) setting up a second bidirectional multi-protocol label switching tunnel from the second ingress node to the egress node; the mobile host having an IP address in step c) identical with an IP address assigned to the mobile host in step a).

This embodiment provides the advantage of reduced signalling, as there is no need to assign a new IP Care of Address to the Mobile Host. In a further embodiment, the first ingress node tears down the first bidirectional multiprotocol label switching tunnel after step c) has been completed. This enhances advantageously the reliability of the packet switched connection, as interruptions are avoided.

In another embodiment, the second ingress node sets up the second bidirectional multiprotocol label switching tunnel using tunnel parameters identical to tunnel parameters of the first bidirectional multi-protocol label switching tunnel, and the tunnel parameters of the first bidirectional multi-protocol label switching tunnel are informed to the second ingress node in step b) together with the internet protocol address of the egress node. This allows to maintain the existing Quality of Service and simplifies the protocol advantageously, making use of the standardized message structures.

In still a further embodiment, the second ingress node is informed about the internet protocol address of the egress node by the first ingress

This simplifies the handover, as the first ingress node has the information of the internet protocol address of the egress node available from the setup of the first MPLS tunnel.

In still another embodiment, the second ingress node is informed about the internet protocol address of the egress node by means of a context transfer, the context transfer further comprising at least one item out of a list consisting of authentication information, authorization information, quality of service information, header compression information and LSP tunnel information.

This assured advantageously that the same Quality of Service, access rights and so on are still available to the mobile host after the handover.

In still a further embodiment, the context transfer is carried out between the first ingress node and the second ingress node.

This simplifies the handover in networks, where the Nodes of Attachment handle the context information.

In a further embodiment, the context transfer is carried out between the mobile host and the second ingress node. This is advantageous in a case, where MPLS-related information is stored in the mobile host. In still another embodiment, the context transfer is carried out between a central entity and the second ingress node, wherein the central entity stores and manages traffic context information of a plurality of network nodes.

This simplifies the handover in network structures, where the context is handled in a central entity (e.g. AAA server).

In still a further embodiment, the first ingress node checks in step b) for other available tunnels associated with the mobile host and informs the second ingress node about an internet protocol address of an egress node and tunnel parameters for each of the other available tunnels.

This assures that the exact number of the existing LSP tunnels (used by the traffic for the MH) will be set up by the second ingress node.

In still another embodiment, the second ingress node sets up a new multi-protocol label switching tunnel for each of the other available tunnels.

This assures advantageously that all services of the mobile host can continue after the handover.

In still a further embodiment, a telecommunication system comprises a multi-protocol label switching network with a plurality of label switching routers forming nodes of the network, one of the nodes being configured as egress node to provide connection to an external packet switched network, the egress node having a first Internet Protocol address; a mobile host having a second internet protocol address and being configured to send and receive packet data; a plurality of radio access network domains, each of the radio access network domains being configured to provide wireless connection between one of the nodes and the mobile host; the network being configured to set up a first multiprotocol label switching tunnel from the first ingress node to the egress node, the first ingress node connecting a first radio access network domain belonging to a first service area where the mobile host is located; if the mobile host changes its location from the first service area of the first radio access network domain to a second service area of a second radio access network domain, to inform a second ingress node serving the second radio access network domain about an internet protocol address of the egress node and LSP tunnel parameters identifying the existing tunnels connecting first ingress node to the egress node; and to set up a second multi-protocol label switching tunnel from the second ingress node connecting the second radio access network domain to the egress node, whereby the second internet protocol address belonging to the mobile host is not changed.

In still another embodiment, a router comprises a processing unit and at least one network interface providing connection to other routers, the router being configured to serve as a second ingress node to a packet switched network using multi-protocol label switching as a transport technology between a gateway and a plurality of radio access network domains, and further being adapted to carry out the following steps when a mobile host changes its location from a service area of a first radio access network domain to a service area of a second radio access network domain: receiving from a first ingress node serving the first radio access network domain (i) an

Internet Protocol address identifying an egress node of the network and (ii) LSP tunnel parameters identifying the existing tunnels connecting first ingress node to the egress node; setting up a bidirectional multi-protocol label switching tunnel to the egress node identified by the Internet Protocol address and having the LSP tunnel parameters as communicated by the first ingress node; receiving packet data from a mobile host via a second radio access network domain and forwarding the packet data to an egress node of the network through the bi-directional multi-protocol label switching tunnel; receiving packet data from the egress node via the bi-directional multi-protocol label switching tunnel and forwarding the packed data to the mobile host via the second radio access network domain.

In still a further embodiment, a router comprises a processing unit and at least one network interface providing connection to other routers, the router being configured to serve a first radio access network domain as a first ingress node to a packet switched network using multi-protocol label switching as a transport technology between a gateway and a plurality of radio access network domains, and further being adapted to carry out the following steps: setting up a first bidirectional multi-protocol label switching tunnel to an egress node; 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, informing a second ingress node serving the second radio access network domain about an internet protocol address of the egress node and LSP tunnel parameters identifying the existing tunnels connecting first ingress node to the egress node. In another embodiment, a mobile host comprises radio frequency, communication means and a processing unit. The mobile host is adapted for communication in a wireless network using multi-protocol label switching as a transport technology between a gateway and a plurality of radio access network domains. The mobile host is further configured to maintain a wireless connection to a base station belonging to a first radio access network domain served by a first ingress node, 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, to receive a broadcast message from a second ingress node serving the second radio access network domain; to initiate an attachment to the second ingress node; and to transmit information to the second ingress node about an internet protocol address of an ingress node and LSP tunnel parameters identifying a multi-protocol label switching tunnel existing between the first ingress and the ingress node.

A mobile host according to this embodiment may advantageously serve in a system according to the present invention, in which MPLS-related information is stored in the mobile host.

Another embodiment of the present invention relates to the implementation of the preceding embodiment using hardware and software. This embodiment may also be implemented by means of software modules which are executed by a processor or directly in hardware. Also, a combination of software modules are hardware implementation may be possible. The software modules may be stored on any kind of computer readable storage media, for example RAM, EPROM, EEPROM, flash memory, registers, hard disks, CD-ROM, DVD, etc.

This embodiment provides the advantage that software may be updated in order to implement new functions or correct errors.

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 construed 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 illustrates an exemplary system architecture of a cellular network;

Figure 2 illustrates an overlay system model for a packet switched connection in the network shown in Figure 1 ;

Figure 3 illustrates data plane protocol stacks in Gateway 108, intermediate LSR 107, NoA 104 or 105 and MH 109;

Figure 4 illustrates the protocol stack in the control plane of a network as shown in Figure 1 ;

Figure 5 illustrates procedures carried out to se set up a second LSP tunnel in the case that a context transfer takes place between first and second ingress LSR;

Figure 6 illustrates procedures carried out to se set up a second LSP tunnel in the case that a context transfer takes place the second ingress LSR and a central entity;

Figure 7 illustrates procedures carried out to se set up a second LSP tunnel in the case that the Mobile Host carries the MPLS-related information;

Figure 8 illustrates an exemplary structure of a router 104, 105, 106, 107, 108 of the network shown in Figure 1.

Figure 9 illustrates an exemplary structure of a mobile host 109 for use in a network shown in Figure 1.

DETAILED DESCRIPTION OF THE INVENTION

The illustrative 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. Referring now to figure 1 , MH 109 is attached to a mobile network 100 consisting of core network 101 and at least one radio access network (RAN). The core network 101 uses MPLS in TE mode to assure the required Quality of Service (QoS) and to be able to control the traffic load in the network in an accurate way. Two RAN domains 102 and 103 are illustrated in the example of figure 1. Each RAN domain comprises a plurality of base stations 113, 114, 115 and is connected to the core network via a Node of Attachment (NoA) 104, 105. The NoA is located in the same entity with the respective ingress node of the core network 101. To this end, IP and MPLS protocols are implemented in each NoA. MH 109 has a wireless connection to one of the base stations, here 113. It can be connected to the Internet 116 or one or more other private or public networks over RAN domain 102 and core network 101 through a GW 108. It could also be connected to a second Mobile Host via the same RAN domain or another RAN domain served by another NoA, for example 105. 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 needs a Care-of-Address (CoA) as described above. The MH 109 can either retrieve the CoA in case of MIPv4 from a Foreign Agent (FA) located e.g. at the GW 108 or in case of MIPv6 to generate the CoA by itself with the help of Access Router (AR) which may also be located in the GW 108. The mechanism for retrieving a CoA is out of scope of this invention and is not further explained. The LSP tunnel 110 is built between the NoA 104 (a definition of NoA is given above) and GW 108. In the example shown in Figure 1 , the NoA 104 is an Access Controller (refer above), but the NoA 104 might be any other IP/MPLS capable RAN entity, as e.g. BS 109.

If MH moves and is about to leave the service area of base station 113, it searches for a broadcast message sent by another base station 114. A handover will be performed, which is explained in more detail below. After this handover, MH 109 will have a wireless connection with BS 114 and a connection to GW 108 via NoA2 105 and a new LSP 111. The MH 109 retains the same IP address while moving within the network of one mobile operator.

Figure 2 represents an overlay system model that is used as a reference model in the present invention. As mentioned before, the Node of Attachment (NoA) and the MPLS's ingress LSR must be located in the same entity. An initial "old LSP" 110 connects the old ingress 104 and the egress LSR 108. As described above, the new ingress LSR 105 can retrieve information needed to set up the new LSP 111 to the egress LSR 108 in different ways. With the help of arrows 201 to 203, Figure 2 depicts one exemplary way how the MPLS-related information is retrieved by the new ingress LSR 105 from the old ingress LSR 104. Beginning with step (1) 201 , the MH 109 receives a broadcast message from the new NoA 105. Having received this message, the MH 109 knows the NoA's identifier. During step (2) 202 the MH 109 informs the old ingress LSR 104 about the desired new NoA (new ingress LSR) 105. In step (3) 203 the old ingress LSR 104 contacts the desired NoA (new ingress LSR) 105 and informs it, together with other information, about the MPLS-specific parameters. Finally in step (4) 204, the new ingress LSR 105 can start to set up the new LSP 111.

Figure 3 shows the data plane protocol stacks in the regarded entities, i.e. Gateway 108, intermediate LSR 107, NoA 104 or 105 and MH 109. In the implementation option depicted in the figure, FA/AR 301 is located in an entity different from the Gateway 108. Another alternative could be to locate FA/AR 301 and Gateway 108 in the same entity. Herein below, without restricting the scope of the invention to it, the case will be regarded that the FA/AR 301 and Gateway 108 are in the same node and this node will be referred to as GW or egress LSR. It is important to mention that the communication 302 between GW 108 and MH 109 takes place on the second protocol layer L2. The data transport 303 between GW 108 and NoA 104 or 105 through the intermediate LSR 107 is based on MPLS technology. Between the NoA 104 or 105 and MH 109 the data transport 304 can take place on L2.

Figure 4 shows the protocol stack in the control plane. The separation between data plane and control plane is carried out in order to emphasize the differences of the used protocols. As described above, the present invention is implemented in a RSVP-TE MPLS control protocol 401. All 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 old ingress LSR 104 and new ingress LSR 105 is carried out in the control plane as well, however other protocols, e.g. applied for context transfer, are used in this case.

Referring now to figure 5, the procedures to set up a new LSP tunnel are explained in more detail for the case that the context parameters are managed by the old (serving)

LSR.

In this alternative, the old ingress LSR 104 has exact knowledge of the traffic parameters belonging to the LSP tunnel 110 of the MH 109, the IP address of the egress LSR 108 and the context. In this case, the steps for setting up the new LSP tunnel are as follows: (1) Each ingress LSR, which has the functions of normal router, sends periodically a broadcast message 501. This message is broadcasted over the L2 radio access domain and transmitted over the air interface. The MH 109 detects a new NoA 105, when it receives a broadcast message with an NoA's ID different from its current NoA's ID. If the MH 109 would like to attach to the new NoA 105, the MH 109 informs the old NoA 104 about the new NoA's ID in step 502.

(2) The old NoA 104 initiates communication to the new NoA 105 in step 503. As a consequence, MPLS-related information is transferred in 504. MPLS-related information could be exchanged directly between new and old ingress LSR using proprietary techniques. Implementation of this approach may lead to extensions in the RSVP-TE protocol, conflicting with the RSVP concept, since RSVP messages would be exchanged between entities (in this case new and old ingress LSRs) not involved in the data transport path. Therefore it is preferred to include the MPLS-related information in the "context". In this alternative, the new NoA obtains the MPLS-related information among other parameters during the context transfer operation.

At this time, the old ingress node 104 may check whether other tunnels associated with the MH 109 exist. Further tunnels may have the same egress node as the first tunnel, but they might as well have different egress nodes. For example, MH 109 might run at the same time a web browsing service connected to the Internet 116 via GW 108, and a voice or video conferencing service connected to another MH via another NoA of the same core network. The first ingress node 104 would inform the second ingress node 105 about the tunnel parameters of all further tunnels e.g. via a context transfer similar to 504. This step is not depicted in figure 5, but would take place between 504 and 505. To allow the new ingress LSR 105 to set up new tunnels for MH 109 identical to the existing ones from the old ingress LSR, the new ingress LSR 105 should obtain complete MPLS- related information about the MH's LSP tunnels maintained by the old ingress LSR 104. This MPLS-related information includes QoS parameter for each tunnel and the egress LSR's IP address.

(3) Receiving the MPLS-related parameters, the new NoA 105 can start to set up one ore several new LSP tunnels to the egress LSR 108 and possibly other egress LSRs with step 505 and from now on, the NoA 105 acts as a new ingress LSR. At the same time, the new NoA allows the MH 109 to attach to it, illustrated by arrow 506.

(4) After the setup of the LSP tunnel(s) 111 is completed, and the attachment of the MH 109 to the NoA 105 is finalised, the MH 109 can start to send and receive data packets through the new NoA 105. (5) Finally, when the MH 109 detaches from the old NoA 104, with step 507, the LSP tunnel(s) 110 from the old ingress LSR 104 are released with step 508.

Now the handover procedure will be described for the case that the traffic context is managed and stored centralized, for example in AAA 112 of figure 1. Referring to figure 6, when a MH requires a new attachment to the network in 601 , the new NoA 105 contacts a central entity (central context database) 602 in the network to request information about the MH 109 with step 603. In this case there is no need for direct contact between NoAs 104 and 105. The new ingress LSR 105 receives the context information from the central context database 602 in step 604. Thus, the handover procedures are concentrated on the network side and the MH is not involved in it, meaning that the MH does not need to carry any information and to contact the old NoA. In this embodiment, the old ingress LSR should inform the central context database 602 each time when MPLS sessions have been changed. In this way the database 602 is kept permanently updated.

Alternatively, the MPLS-related information could be stored in the MH. This is an opposite approach to the one described in figure 6, where the MH 109 is unaware of the MPLS status. Referring to figure 7, when the MH 109 receives a broadcast message from the new NoA in step 701 , the MH initiates attachment to the new NoA with step 702. During the attachment procedures the MH transmits the MPLS-related information to the new NoA with step 703, so that consequently the new NoA can initiate the setup of new LSP tunnel(s) in step 704.

Referring now to figure 8, a schematic of a router 800 is illustrated, which could form the first ingress node 104 or second ingress node 105. The router 800 comprises a processing unit 801 which can store and execute programmable instructions causing it to carry out the necessary steps to perform the task of the first or second ingress node as described above. It further comprises a network interface 802 to connect it to other routers of the core network 101 and an interface 803 to the radio access network. Router 800 may comprise further network interfaces 804 to connect it with more routers, and a display unit and an input unit, for example for maintenance purpose if it is not maintained remotely from the network via network interface 802.

Referring now to figure 9, a schematic 900 is illustrated of a mobile host which could be configured to take part in the method shown in figure 7. It comprises a processing unit 901 for controlling other hardware sections of the mobile host, for processing signals transmitted and received via RF communication means 902, for generating and modifying images displayed on the display unit 904, for processing audio signals input and output via audio circuit 905 and for carrying out steps related to transmission protocols. All tasks of processing unit 901 are controlled by instructions stored in instruction memory 903. Instruction memory 903 may be mask programmed ROM, nonvolatile memory like flash or EEPROM, or volatile RAM. In the latter case, as well as in the case of reprogrammable non-volatile memory, instructions may be loaded to instruction memory 903 from another storage medium like magnetic disk, optical disk, magnetic tape, other non-volatile solid state memory or the like.

Various embodiments as described above and in figures 5, 6, and 7 may advantageously provide an improved, simplified and more reliable method for providing mobility to a mobile host in a network with MPLS transport technology. As another advantage of the described embodiments, a specified Quality of Service can be assured while roaming in a cellular network. A communication system employing the described method may assure mobility to a mobile host running one or more services demanding distinct QoS requirements based on packet switched connections.

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

CLAIMS:

1. A method for providing mobility to a mobile host in a wireless network using multiprotocol 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 bidirectional multi-protocol label switching tunnel from a first ingress node to an egress node, said first ingress 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) informing a second ingress node serving said second radio access network domain about an internet protocol address of said egress node and LSP tunnel parameters identifying the existing tunnel connecting first ingress node to the egress node; and c) setting up a second bidirectional multi-protocol label switching tunnel from said second ingress node to said egress node; said mobile host having an IP address in step c) identical with an IP address assigned to said mobile host in step a).

2. The method according to claim 1, wherein said first ingress node tears down said first bidirectional multi-protocol label switching tunnel after step c) has been completed.

3. The method according to claim 1 or 2, wherein said second ingress node sets up said second bidirectional multi-protocol label switching tunnel using tunnel parameters identical to tunnel parameters of said first bidirectional multi-protocol label switching tunnel, and said tunnel parameters of said first bidirectional multiprotocol label switching tunnel are informed to said second ingress node in step b) together with said internet protocol address of said egress node.

4. The method according to one of the claims 1 to 3, wherein said second ingress node is informed about said internet protocol address of said egress node by said first ingress node.

5. The method according to claim 3, wherein said second ingress node is informed about said internet protocol address of said egress node by means of a context transfer, said context transfer further comprising at least one item out of a list consisting of authentication information, authorization information, quality of service information, header compression information and LSP tunnel information.

6. The method according to claim 5, wherein said context transfer is carried out between said first ingress node and said second ingress node.

7. The method according to claim 5, wherein said context transfer is carried out between said mobile host and said second ingress node.

8. The method according to claim 5, wherein said context transfer is carried out between a central entity and said second ingress node, wherein said central entity stores and manages traffic context information of a plurality of network nodes.

9. The method according to one of the claims 1 to 8, wherein said first ingress node checks in step b) for other available tunnels associated with said mobile host and informs said second ingress node about an internet protocol address of an egress node and tunnel parameters for each of said other available tunnels.

10. The method according to claim 9, wherein the second ingress node sets up a new multi-protocol label switching tunnel for each of said other available tunnels.

11. 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 egress node to provide connection to an external packet switched network, said egress node having a first Internet Protocol address; a mobile host having a second internet protocol address and being configured to send and 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 first ingress node to said egress node, said first ingress node connecting a first radio access network domain belonging to a first service area where said mobile host is located; 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 inform a second ingress node serving said second radio access network domain about an internet protocol address of said egress node and LSP tunnel parameters identifying the existing tunnels connecting first ingress node to the egress node; and to set up a second multi-protocol label switching tunnel from said second ingress node connecting said second radio access network domain to said egress node, whereby said second internet protocol address belonging to said mobile host is not changed.

12. A router comprising a processing unit and at least one network interface providing connection to other routers, said router being configured to serve as a second ingress node to a packet switched network using multi-protocol label switching as a transport technology between a gateway and a plurality of radio access network domains, and further being adapted to carry out the following steps when a mobile host changes its location from a service area of a first radio access network domain to a service area of a second radio access network domain: receiving an Internet Protocol address identifying an egress node of said network from a first ingress node serving said first radio access network domain; setting up a bi-directional multi-protocol label switching tunnel to said egress node identified by said Internet Protocol address; receiving packet data from a mobile host via a second radio access network domain and forwarding said packet data to an egress node of said network through said bi-directional multi-protocol label switching tunnel; and receiving packet data from said egress node via said bi-directional multi-protocol label switching tunnel and forwarding said packed data to said mobile host via said second radio access network domain.

13. A router comprising a processing unit and at least one network interface providing connection to other routers, said router being configured to serve a first radio access network domain as a first ingress node to a packet switched network using multi-protocol label switching as a transport technology between a gateway and a plurality of radio access network domains, and further being adapted to carry out the following steps: setting up a first bidirectional multi-protocol label switching tunnel to an egress node; 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, informing a second ingress node serving said second radio access network domain about an internet protocol address of said egress node and LSP tunnel parameters identifying the existing tunnels connecting first ingress node to the egress node.

14. A mobile host (109) comprising radio frequency communication means and a processing unit, for communication in a wireless network (100) using multi-protocol label switching as a transport technology between a gateway (108) and a plurality of radio access network domains (102, 103), said mobile host being configured to maintain a wireless connection to a first base station (113) belonging to a first radio access network domain (102) served by a first ingress node (104), and, if said mobile host moves from a service area of said first radio access network domain (102) to a service area of a second radio access network domain (103), to receive a broadcast message from a second ingress node (105) serving a second radio access network domain (103); to initiate an attachment to said second ingress node (105); to transmit information to said second ingress node (105) about an Internet Protocol address of an egress node and LSP tunnel parameters identifying a multi-protocol label switching tunnel (110) existing between said first ingress node (104) and said egress node.

15. A computer-readable medium having stored thereon instructions that, when executed on a processor of a mobile host for communication in a wireless network (100) using multi-protocol label switching as a transport technology between a gateway (108) and a plurality of radio access network domains (102, 103), cause the mobile host to maintain a wireless connection to a first base station (113) belonging to a first radio access network domain (102) served by a first ingress node (104),

and, if said mobile host moves from a service area of said first radio access network domain(102) to a service area of a second radio access network domain (103), to receive a broadcast message from a second ingress node (105) serving a second radio access network domain (103);

to initiate an attachment to said second ingress node (105); and

to transmit information to said second ingress node (105) about an Internet Protocol address of an egress node and LSP tunnel parameters identifying a multi-protocol label switching tunnel (110) existing between said first ingress node (104) and said engress node.