WO2010000090A1

WO2010000090A1 - Inter-domain handover mechanisms between network-based localized network mobility domains

Info

Publication number: WO2010000090A1
Application number: PCT/CN2008/001251
Authority: WO
Inventors: Xiaoming Fu; Niklas Neumann; Jun LEI; Gong Zhang
Original assignee: Huawei Technologies Co Ltd; Georg August Universitaet Goettingen; Universitaetsmedizin Goettingen Georg August Universitaet
Current assignee: Huawei Technologies Co Ltd; Georg August Universitaet Goettingen; Universitaetsmedizin Goettingen Georg August Universitaet
Priority date: 2008-07-01
Filing date: 2008-07-01
Publication date: 2010-01-07
Anticipated expiration: 2011-01-01
Also published as: WO2010000090A8

Abstract

The invention relates to a method for handovers between at least two network mobility domains. The domains are part of a system with local mobility anchors and a mobile node being connectable with each of the network mobility domains. A first connection is established between the mobile node and a first network mobility domain; and the local mobility anchor of the first network mobility domain is designated a session mobility anchor. A second connection between the mobile node and a second network mobility domain of the at least two network mobility domains is established. The step of establishing comprises a step of locating wherein a local entity pertaining to the second network mobility domain locates the session mobility anchor to which the mobile node is designated. The step of locating the session mobility anchor comprises the following step carried out by the local entity: retrieving a session mobility anchor identification. The session mobility anchor identification is retrieved from at least one of: a transmission sent by the mobile node to the second network mobility domain, and a data base comprising a mobile node identification identifying the mobile node. The data base stores the mobile node identification related to a session mobility anchor identification of the session mobility anchor dedicated to the mobile node. The local entity comprises at least one of: a mobile access gateway of the second network mobility domain, the local mobility anchor of the second network mobility domain which provides a visited local mobility anchor, or another entity pertaining to and being connected to the second network mobility domain. Further, the invention relates to a local mobility anchor adapted to retrieving the identification according to the invention. Additionally, the invention relates to a retrieval unit for supplying a requesting local mobility anchor with requested session mobility anchor information, the retrieval unit comprising the data base. Finally, the invention relates to a computer program product implementing the inventive method when running on a programmable processor.

Description

INTER-DOMAIN HANDOVER MECHANISMS BETWEEN NETWORK-BASED LOCALIZED NETWORK MOBILITY DOMAINS

Technical field

The invention relates to the field of mobile data connections, in which a mobile node, e.g. a notebook is connected to a fixed node like a wireless router. Data is transferred between router and notebook via a wireless connection, the router routing data from and to a network, e.g. the Internet, connected to the router via a wired connection. The mobile node changes the point of connection requiring signaling and link control processes to enable another point of connection (another wireless router) to be connected to the mobile node. The present invention relates to the field of handover mechanism providing such processes.

This invention relates to a mechanism to setup and maintain handover and data forwarding procedures that allows a mobile node (MN) to move between different domains that provide (localized) network-based mobility support for the MN to communicate with a corresponding node (CN). Different from previous approaches like Mobile IP(v6), Proxy Mobile IPv6 or their extensions, this new approach does not require a home domain or a central entity which performs complex signaling processes induced by handover, and the all the mobile nodes' data forwarding and possible charging.

Prior Art

A mobile node in the current internet needs to maintain a fixed endpoint when it moves to allow for seamless connectivity with its corresponding nodes. In order to provide continuous mobility support for a mobile node that is moving between different mobility domains, a steady anchor point has to be provided for corresponding nodes. In the host- based mobility approaches, this is the home agent (HA). Such approaches are described as the standard RFC3775 of the Internet Engineering Task Force (IETF), defined in at least in parts in "Mobility Support in IPv6", Network Working Group D. Johnson, Rice University; C. Perkins, Nokia Research Center; J. Arkko, Ericsson, June 2004, retrievable under ftp://ftp.rfc-editor.org/in-notes/rfc3775.txt. In the standard draft Proxy Mobile IPv6 (PMIP), the steady anchor point is the local mobility anchor (LMA). A document describing the PMIP standard the IETF draft ,,Proxy Mobile IPv6, draft-ietf-netlrnm-proxymip6-15.txt" by NETLMM WG, S. Gundavelli (Editor); K. Leung, Cisco; V. Devarapall, Wichorus; K. Chowdhury, Starent Networks; B. Patil, Nokia Siemens Networks of May 16, 2008, which retrievable under http://tools.ietf.org/html/draft-ietf-netlmm-proxymip6-15. The anchor point defined in this standard draft allows the mobile node to change its point of attachment (so-called mobile access gateway, or MAG) to a network without its corresponding nodes to notify that. All the mobile node's traffic is routed through this anchor point which then forwards the traffic to the mobile node. When a mobile node leaves a PMIP domain, however, it moves beyond the control of the LMA which breaks the mobility. Hence, a network-based mobility management protocol like Proxy Mobile IPv6 does not rely on changes on mobile nodes, but mainly rely on the network to handle the mobility management; it also provides better performance with less overhead than Mobile IPv6-based approaches. This is described in the publication: "Evaluating the Benefits of Introducing PMIPvό for Localized Mobility Management", Jun Lei, Xiaoming Fu, Computer Networks Group, University of Goettingen, Germany, Proceedings of IEEE International Wireless Communications and Mobile Computing Conference 2008 (IWCMC 2008), Crete, Greece, IEEE, August 2008. The publication "A New Decentralized Mobility Management Service Architecture for IPv6-based Networks", Xiaoming Fu, Deguang Le, Jun Lei, in Proceedings of the 3rd ACM International Workshop on Wireless Multimedia Networking and Performance Modeling (WMuNeP'07), Crete, Greece, October 2007 proposes a distributed mobility management scheme (DMMS) which relaxes the home domain requirement, but it requires the MN to make the decision and maintains the binding with the mobility agents; hence it is still host-based approach and has deployment concerns. Both publications are retrievable under http://www.net.informatik.uni-goettingen.de/publications/.

When the mobile node moves between network-based mobility domains that are under different administrative control, this becomes challenging. Previously, an approach has been proposed, which is based on a home domain, however with limited scalability and data efficiency issues. This approach is described in the IETF standard draft "Roaming Mechanism between PMIPv6 Domains, draft-park-netlmm-pmipv6-roaming-00", Network Working Group, J-H. Na, ETRI; S. Park, Chungnam, National University; J-M. Moon, S. Lee, ETRI; E. Lee, S-H. Kim, Chungnam National University of December 03, 200, retrievable under http://tools.ietf.org/html/draft-park-netlmm-pmipv6-roaming-00. In this standard draft, each handover involves connecting to a new network mobility domain by an authentication process carried out by an AAA (entity for authentication, authorization and accounting maintained by a provider), which may reside on a server located far away. Further, the AAA retrieves the address of the initial local mobility anchor and sends it to the mobile access gateway. This mechanism is inherently linked with a time consuming authentication process, data transfer over long distances and a large overhead since each handover starts an authentication process even if a authentication is not required by the new network mobility domain. This is apparent when imaging a scenario with small domains and a relatively fast moving mobile node, e.g. a laptop in a train or car passing an office with a number of departments, each providing a network mobility domain (e.g. a WLAN area).

The approach described in the IETF standard draft "Interactions between PMIPvό and MIPv6: scenarios and related issues, draft-giaretta-netlmm-mip-interactions-02" by NETLMM Working Group G. Giaretta (Ed.), Qualcomm of November 15, 2007 and retrievable under http://tools.ietf.org/html/draft-giaretta-netlmm-mip-interactions-02 relies on Mobile IPv6-enabled mobile nodes, but they require the involvement of Mobile IPv6 home domain (mostly, the home agent, HA), which also suffer from the similar issue like discussed in the standard draft "Roaming Mechanism between PMIPvό Domains" mentioned above.

Summarized, the handover mechanisms known in the prior art suffer from complexity as regards system structure and process steps, reduced flexibility when moving between different domains and a high latency when connecting to the new network mobility domain, which substantially impairs the reliability of the connection.

It is therefore an object of the invention to provide a handover mechanism with improved performance in comparison to the handover mechanisms known in the prior art. In particular, it is an object of the invention to provide a handover mechanism overcoming or at least reducing the disadvantages of prior art set out above.

Summary of the invention

The invention provides an improved handover mechanism by the implementation of the session mobility anchor (SMA), to which the mobile node (MN) is dedicated (before and after the handover), as well as by a local mobility anchor (LMA) of a network mobility domain to which the mobility node is handed over (a visited local mobility anchor, LMAv), which locates the session mobility anchor (SMA). The SMA is the first LMA of at least two LMAs to which a mobile node (MN) connects to. The functionality of locating the session mobility anchor (SMA) is realized by the visited local mobility anchor (LMAv). The visited local mobility anchor (LMAv) can establish a connection between the MN and the SMA. In this way, the MN can be assigned to the SMA before and after the handover, the SMA thus providing a persistent local mobility anchor for the MN. In this way, the MN can be associated to the first LMA to which it connects to, that is to the SMA, and remains to be associated or designated to the SMA during handovers among the at least two network mobility domains. Thus, the MN can be handed over without any change of the dedicated local mobility node for the MN. Accordingly, the handover mechanism of the invention provides transparent routing without routing or signaling involvement of the MN as regards LMA changes.

In general, the entity locating the SMA to which the MN is associated or dedicated to can be any local entity of the second network mobility domain. The local entity is preferably the LMA of the second network mobility domain. This LMA is also denoted as visited local mobility anchor (LMAv) since it is the current LMA to which the MN tries to connect to. Other realizations of the local entity are a mobile access gateway (MAG) of the second network mobility domain or other entities or units pertaining to and being connected to the second network mobility domain. Such entities or units form a part or perform a function of the second network mobility domain, such that the step of locating according to the invention is an additional feature of the respective (local) entity or unit. The local entity pertaining to a mobile network domain preferably pertains exclusively to this mobile network domain or is shared by a subgroup of mobile network domain of the at least two mobile network domains. The mobile network domain to which the local entity pertains to is connectable by the MN; thus, the MN is in the range of the mobile network domain to which the MN tries to connect to. Particularly, the LMAv is located in the mobile network domain, to which the MN pertains to.

It is a main aspect of the invention to let the visited network where a mobile node is initially connected to (i.e., bootstraps or "root") to be responsible to provide the actual mobility services to the mobile node. This is independent from the actual or previous location of the mobile node, i.e. independent of the identity of LANs (or network mobility domains to which the mobile node MN has been previously connected to). Thus, the first network to which the MN connects to is responsible to provide the actual mobility services to the MN, no matter where the MN moves to. The mechanisms according to the invention implement an inter-domain signaling between the bootstrapping network domain (i.e. the network domain of the SMA) and the new visited domain (the domain of the LMAv), to setup session handover and data forwarding between the different domains. In particular, not a central node within all network mobility domains or within a common network to which the network mobility domains are connected to is responsible for forwarding and resolving the SMA. Rather, it is a local entity of the new network mobility domain, in particular the LMAv, which resolves (retrieves or infers) the first domain to which the MN has been connected to, i.e. the SMA. Preferably, the local entity resolving the first network mobility domain of the SMA (or, alternatively, another entity of the new network mobility domain) provides forwarding by establishing a connection between the network mobility domain of the SMA and the network mobility domain of the LMAv, e.g. between SMA and LMAv. This connection can be a tunneling connection established by the LMAv.

The concept underlying the invention as described therein can be realized by: a method for handovers between at least two network mobility domains (one of which comprising the

SMA and another comprising the LMAv), in which the SMA is located the LMAv, which retrieves a SMA identification e.g. from a transmission of the MN or from a data base mapping the MN (MN identification) onto the corresponding SMA (SMA identification).

If the SMA to which the MN is dedicated is known (by the location process), the LMAv or anther entity of the network, e.g. an entity of the network domain, to which the MN connects to, a connection from this network domain to the network domain of the SMA can be established, preferably by establishing a tunnel.

Similarly, the concept underlying the invention as described therein can be realized by a first embodiment of the LMA: a LMA adapted to retrieve the SMA identification as described above. To this end, the LMA comprises a port and a retrieval unit for retrieving the SMA identification. The retrieval unit is connected to the port and is adapted to detect the SMA identification from a transmission received by the port and sent by the mobile node to a network mobility domain. Alternatively, instead of the LMA, a MAG or another local entity pertaining to a mobile network domain can be used to implement the invention.

In this case, the MAG or other local entity is defined by the features described with regard to LMA.

Additionally, the concept underlying the invention as described therein can be realized by a second embodiment of the LMA: a LMA comprising an identification request port, a identification request generation unit and an identification request receive unit, which are operatively connected with each other. The identification request generation unit is a code generator which generated a session mobility anchor request containing the MN identification of the MN (preferably together with an identification of the LMAv). The LMA transmits the request to a data base (DB). Preferably, the LMA further comprises a receiver for receiving the response of the DB, the response containing the SMA identification (of the SMA to which the MN is dedicated to). Alternatively, instead of the

LMA, a MAG or another local entity pertaining to a mobile network domain can be used to implement the invention. In this case, the MAG or other local entity is defined by the features described with regard to LMA.

Thus, the first embodiment of the LMA (or MAG or local entity) retrieves the SMA passively from a message of the MN (similar to a message monitor detecting the SMA information), whereas the second embodiment of the LMA (or MAG or local entity) actively generates and sends a request to a database for resolving the SMA of the MN. Both embodiments can be combined in one LMA (the mode of operation of the LMA should be selectable). Further, both embodiments are preferably adapted to establish a connection to another LMA (i.e. the SMA). This could be realized by a connection establishing unit with a port for receiving the SMA address and being adapted to establish a tunneling connection with the SMA. The process of establishing could be carried out by a TX/RX-entity processing data according to the respective protocol stack for establishing an IP-tunnel.

In addition, the concept underlying the invention as described therein can be realized by: a computer program product comprising code representing instructions implementing the step of retrieving an SMA identification as described above. According to the instructions represented by the code, SMA is retrieved from a transmission sent by the MN (i.e. the passive retrieval process described above) or from the data base mapping MN data on LMA (SMA) data (i.e. the active retrieval process described above).

Finally, the concept underlying the invention as described therein can be realized by: identification request response unit comprising a memory, a processor connected therewith, and a I/O-port connected to the processor. The memory, together with the processor, is adapted for maintaining a look-up table which realizes the mapping of MN data onto LMA data, and, consequently realizes the data base. Further, the response unit comprises an I/O- port receiving requests and transmitting the request data to the processor. The processor retrieves the corresponding SMA data from the look-up table (i.e. the data base), transmits this SMA data (which also might be a not-in-list-signal) to the I/O-port, which in turn forwards the SMA data to a respective entity (to the second network mobility domain or to the LMAv). Of course, the I/O-port might send the information to another entity forwarding the information to the entity from which the request has been sent.

The first or second embodiment of the LMA or the identification request response unit can realized in hardware only, as a hardware/software combination or as computer code modules, together with a programmable processor realizing the respective features. The LMA or the identification request response unit can be a part of a unit realizing other functions. In this case, the LMA and the identification request response unit can be computer code added to the (memory of) the unit and some of the features (e.g. the ports and the processor) can be realized by elements being part of the unit and being used for the realization of the other functions of the unit. According to the invention, a local mobility anchor or a group of or all local mobility anchors of a plurality of network mobility domains has/have the ability to identify the SMA initially associated to a MN and has preferably further the ability to establish a connection to the session mobility anchor. This mechanism of identifying the SMA and routing/forwarding between MN and SMA is distributed over all network mobility domains comprising a local mobility anchor according to the invention. In other words, the entity implementing the identification process for identifying the SMA to which the MN is dedicated, is provided in a decentralized arrangement and is realized by (distributed) local mobility anchors of (distributed) network mobility domains, in contrast to centralized approaches (centralized LMA identification / centralized signaling / centralized routing) described in the prior art. This fundamental difference as regards the system architecture results in simple implementations (existent local mobility anchors can be used for implementing the function of identifying the session mobility anchor e.g. by reprogramming), a substantially reduced amount of signalization procedures, significantly reduced reaction times (which are due to the fact that the entity implementing the function of localizing the session mobility anchor is arranged in the current network mobility domain establishing a connection to the MN) and significantly reduced latency (by direct routing over minimized distances and by simple signalization procedures).

In addition to the function of localizing, that is determining or identifying the SMA (the first LMA the MN has been dedicated to), the LMA is preferably adapted for establishing a connection to the session mobility anchor as well as to the mobile node. However, in other embodiments of the invention, the process of establishing a connection between the visited local mobility anchor (LMAv) and the SMA is carried out by another entity of the network or of one of the network mobility domains, for example, by the SMA or by a mobile access gateway (MAG) of the new network mobility domain (to which the MN is handed over) or of the preceding network mobility domain (to which the MN has been dedicated before handover). Such a connection between visited local mobility anchor (the new local mobility anchor of the network mobility domain, to which the MN is handed over) is preferably a tunnel providing a transparent connection.

According to the invention, a handover is carried out between (at least) two network mobility domains, each of which comprises a local mobility anchor, by establishing a first mobile connection between mobile node MN and a first network mobility domain. The first network mobility domain is preferably the network mobility domain of (at least) two network mobility domains, to which the MN initially connects to. The local mobility anchor of the first network mobility domain is designated as a session mobility anchor (which can be seen as the "root" local mobility anchor), and the mobile node is designated to this session mobility anchor as the local mobility anchor, which is initially dedicated to or associated with the mobile node. During the handovers, the association between mobile node and session mobility anchor is kept unchanged.

Upon movement of the mobile node, the mobile node is coming into the range of a new network mobility domain denoted as second network mobility domain, to which a connection is required, when the first connection is to be released (e.g. due to critical signal strength / SNR level). For the MN, the first connection is replaced by the second connection, preferably in a overlapping manner. Such a change between first and second connection is denoted as handover. Thus, the second mobile connection between the mobile node and the second network mobility domain is established (and the first connection is released, preferably after successful establishment of the second connection, i.e. overlapping). According to the invention, the step of establishing the second connection comprises locating the SMA (=LMA of the first network mobility domain) by the LMA of the second network mobility domain, the local mobility anchor of the second network mobility domain being denoted as visited local mobility anchor, LMAv. Locating the SMA can be performed by assessing an identification or identifier of the SMA and does not necessarily mean to locate the session mobility anchor in the sense of a spatial localization like in form of geographic coordinates.

Locating the SMA comprises retrieving a session mobility anchor identification, whereby this retrieval can be carried out directly (actively) or indirectly (passively). Such an identification is preferably a unique identification, e.g. realized in form of a binary code with a predefined number of bits such as a (physical) address, a MAC (medium access control) address, an IP address, an IP submask or a similar binary number, which also can be represented as HEX code or ASCII code. In general, the MN identification can be a identifier directly denoting the MN of can be an (indirect) identifier, which is mapped onto the identity (or an IP address, e.g. the MN's home address) of the MN. Within the network (e.g. if a server tries to resolve MN in order to send data to the MN), the MN is identified by its home address of the MN. In the same way, the MN has a mobile node identification, which can be realized in the same or a different way as the SMA identification. The identifications can by unique among all entities or within subgroups of all SMA or MN entities.

Direct Retrieval A direct retrieval is carried out by the visited local mobility anchor (LMAv), which retrieves an entry of a data base (DB), the data base storing SMAs (local mobility anchors, which have been initially accessed by a MN) in relationship with respective mobile nodes MN, which are dedicated to the respective SMA. Thus, direct retrieval or direct location means to provide a data base (DB) which is dedicated to the function of maintaining session mobility anchor information in relationship with mobile note information of the MNs dedicated thereto. Based on this information, a LMAv can send a request identifying the MN requesting connection to the LMAv. A DB receives this request (for example in form of a request message sent by the LMAv) and returns the SMA information associated with the MN information. The SMA information is sent back to the LMAv, for example, in form of a request return message transmitted by the DB or by an transmitting unit (e.g. a processor) connected therewith. The DB stores SMA information (only once for one SMA), in relation to information identifying the MN or MNs which has or have been dedicated to the SMA. In a preferred embodiment, the visited local mobility anchor retrieves an entry of a shared look-up table the entries of which map mobile node identifications onto session mobility anchors dedicated thereto. The shared look-up data table is accessible by each of the local mobility anchors of the network mobility domains, the look-up data table realizing the DB. If a MN information cannot be fond in the DB (for example, due to deletion after expiry of a time period after previous connection establishment, because the mobile node has never been connected before to one of the network mobility domains associated with a certain DB, or the MN logged off or closed the session), the DB stores the mobile node information together with information identifying the actual LMA to which the MN is dedicated to. Thus, the request sent by the LMAv preferably comprises both: information identifying the MN as well as information identifying the LMA to which the MN established a connection. The request can be sent by the LMA via the mobile access gateway (MAG) or could be sent by the MAG of the network mobility domain to which the MN establishes the connection upon the requesting of the LMA. Further, the LMAv can request other entities of its network mobility domain to correspond with the DB in order to support the requesting LMAv retrieve the SMA information requested by the LMAv. Such assisting units corresponding with the DB are preferably adapted to forward the information gathered from the DB to the LMAv. Alternatively, the DB's response can be transmitted directly from the DB to the requesting LMAv. The MNs identity can be resolved by retrieving a corresponding entry of the Binding Update List (stored in the MN). Thus, the second mobility network domain can retrieve the MN' s SMA (initial LMAv) by a request sent to the MN, the MN responding by sending the corresponding (latest) LMA entry to the second mobility network domain, e.g. to the LMAv, the MAG of the second mobility network domain or another local entity of the second network mobility domain retrieving the identity of the SMA to which the MN is dedicated to. In this case, the DB is distributed over the MNs of the system or located within the connecting MN.

Further, the DB can be a stand-alone unit or can be a part of a router or server unit. In another embodiment, the DB is provided by a cache memory of a router or of a server and a processor connected therewith. In a further embodiment, a mobile access gateway (MAG) provides the DB, preferable at least one MAG of at least two network mobility domains, all MAGs of at least two network mobility domains or the MAG of the first mobility domain.

Indirect Retrieval

In indirect retrieval or indirect location, no particular data base dedicated to the maintenance of MN-^SMA mapping data exists. Thus, the session mobility anchor (the first LMA to which the MN connects to or tries to connect) is detected by analyzing the behavior of the MN, that is by analyzing messages or requests (in general: transmissions), which are sent from the mobile node to the second network mobility domain, that is to the local mobility anchor to which the MN connects to (the LMAv). For example, the MN sends a connection request to the LMA when coming into range of the LMA, making the

LMA to the LMAv. In particular, the MN sends a router solicitation message to the LMA comprising information identifying the MN. A connection request message comprises, among other, information identifying the MN, e.g. a binary code in the header of the message representing a physical address or a MAC address or a IP address of the MN. Further, the MN identification data can be retrieved from a Binding Update message. A detailed example of retrieving session mobility anchor identifications from messages sent by the mobile node is given below in the detailed description of the figures.

All terms used above for defining the invention correspond to the terms used in the corresponding IETF standards, if applicable. These IETF standards are the IETF standards discussed in this specification, e.g. RFC 3775, RFC 4282. The terms used herein as well the respective features, functions and definitions are defined in these standards in detail.

The features, functions and definitions given in these standards form a part of this description since the invention relates to a modification of the protocol defined in these standards.

Description of the drawings Fig. 1 shows an exemplary embodiment of the inventive hand-over mechanism as a system overview, together with a data base for active SMA retrieval; and

Fig. 2 shows an exemplary of the inventive hand-over mechanism using passive SMA retrieval.

Fig. 1 shows a system performing the inventive handover process. The system comprises a corresponding node CN and three network mobility domains Nl₅ N2 and N3. Each network mobility domain has a mobile access gateway MAG_1, MAGJ2 and MAG_3 and a local mobility anchor LMA_1, LMA_2 and LMA_3. MAG_1 of Nl is connected to LMA_1, MAG_2 of N2 is connected to LMA_2 and MAG_3 of N3 is connected to LMA_3. Thus, each MAG of the respective network mobility domain is connected to the LMA of the respective network mobility domain.

A corresponding node is connected to the LMA_1. Since LMA_1 is the first LMA to be connected to mobile node MN, LMA is the SMA (session mobility domain) for the network mobility domains Nl - N3 (i.e. for all network mobility domains of the system). Preferably, all or a group of network mobility domains are PMIP (Proxy Mobile IPv6) domains.

In a particular embodiment, a data base (DB) is connected to LMA_1, LMA_2 and LMA_3. Each of these connections as well as the DB is optional for the system according to the invention and is shown in dotted lines.

In the following, an exemplary handover procedure is described by means of the system shown in Fig. 1. When a mobile node MN initially attaches to network mobility domain Nl, i.e. a PMIP domain, the local mobility anchor LMA_1 of Nl becomes the session mobility anchor (SMA) for the mobile node. For the duration of the mobility session this SMA (the LMA the MN initially connects to) will handle all incoming and outgoing connections for the MN. As long as the MN stays within the local PMIP domain Nl, this only includes regular PMIP operations. Such operations are described in A document describing the PMIP standard the IETF draft ,,Proxy Mobile IPv6, draft-ietf-netlmm- proxymip6-15.txt" by NETLMM WG, S. Gundavelli (Editor); K. Leung, Cisco; V. Devarapall, Wichorus; K. Chowdhury, Starent Networks; B. Patil, Nokia Siemens Networks of May 16, 2008, which is discussed in the introductory part of this specification.

When the MN leaves the local PMIP domain Nl as shown by the first movement mvel, however, the new PMIP domain's LMA J2 will initialize a connection cl (e.g. a tunnel) to the SMA to allow the SMA to continue to serve as an anchor point for the MN. Within the new PMIP domain N2 all regular PMIP operations still apply with the exception that all traffic for the MN is tunneled from the new LMA LMA_2 to the SMA (=LMA_1) which in turn communicates with the CN. Since LMA_2 is a new LMA visited by the MN₅ which has been connected to the initial LMA_1 (= SMA) before, LMA_2 becomes the visited LMA (LMAv) upon establishing a connection to mobile network domain N2. From the point of view of the SMA, the current LMA LMAJ2 of a MN can be seen as a MAG (MAGJ2) which performs the corresponding operations.

When the MN leaves the current local PMIP domain N2 as shown by the second movement mve2, the new PMIP domain's LMA_3 will initialize a connection c2 (e.g. a tunnel) to the SMA (=LMA_1) to allow the SMA to still continue to serve as an anchor point for the MN. Thus, the dedication of MN to the SMA is persistent even after movement mvel and mve2, i.e. is persistent for all movements (connection changes) within all (or at least a subset with N > 1 network domains) of mobile network domains of the system.

Upon arrival at the range of N2 (after move mvel) and arrival at the range of N3 (after move mve2), the LMA of the new domain (LMA_2 after move mvel and LMA_3 after move mve2) localizes the SMA. In the embodiment of the system shown in Fig. 1 comprising the data base DB, the new LMA (= the visited LMA, LMAv) retrieves SMA identification information of the SMA to which the MN is dedicated to by transmitting a request to the DB over one of the connections shown in Fig. 1 with dotted lines. The DB retrieves the corresponding SMA identification information and transmits the information to the requesting LMAv. A corresponding on the connections shown with dotted lines can be used for transmitting the information to the requesting LMAv. The DB can be connected to the LMAv (LMA_1 - LMA_3) via the CN.

When a MN attaches to a PMIP domain, the LMA of this domain has to locate the SMA for this MN and initiate a tunnel between itself and the SMA. In case the PMIP domain is the first domain the MN attaches to within its mobility session, the current LMA becomes the SMA and continues with its regular PMIP operations. If the MN was already attached to a different PMIP domain, its SMA resides within this previous domain and the LMA needs to establish a binding with the SMA in order to send and receive the data for the MN through its SMA. Depending on the scenario, the LMA can directly or indirectly locate the

SMA for a MN. Direct location or active location or retrieval of a SMA for a MN requires some kind of look-up between associated PMIP domains Nl - N3. For example, this can be achieved by maintaining the common database DB shown in Fig. 1, where SMAs deposit the information for which MN they are responsible for, i.e. for each known MN an SMA to which the MN is dedicated to. Such a database as shown in dotted lines in Fig. 1 can be established by service level agreements between the operators of PMIP domains Nl - N2. For a LMA (the LMAv) to locate the SMA for a MN it will send a look-up request to the database using the MNs identity. The MNs identity can be its Network Access Identifier (NAI) as the look-up key. The Network Access Identifier (NAI) is the user identity submitted by the client during network access authentication.

In roaming, the purpose of the NAI is to identify the user as well as to assist in the routing of the authentication request. In general, the NAI is defined in the IETF Standard: "RFCc4282 - The Network Access Identifier", Network Working Group, B. Aboba, Microsoft; M. Beadle, ENDFORCE; J. Arkko, Ericsson; P. Eronen, Nokia; December 2005. If the database does not have an entry for the MN, the LMAv becomes the SMA for the mobility session of the MN.

The DB can be connected to the LMAs as depicted in Fig. 1, or, alternatively, be a part of the MN or can be an entity directly connectable by the MN, e.g. a look-up table stored in the MN like a cache or binding update list. Further, these implementations can be provided as a combination of these examples.

In Fig. 1, a direct (or active) retrieval is carried out using the DB shown in Fig. 1 as described above. An indirect or passive retrieval is described in the following by means of Fig. 2.

Fig. 2 shows a signaling flow according to an embodiment of the invention. Fig. 2 shows signals and events together with the corresponding entities in form of a protocol flow over time t (vertical arrow). If no common database exists between PMIP domains (network mobility domains), the LMA (the LMAv) can use an indirect scheme to locate the SMA of a MN. For this purpose, the LMA infers the SMA assigned IP address of the MN and uses this address to send its session transfer request to. Since the SMA is responsible for this IP address, the LMA will indirectly reach the SMA. If there is no reply to the request, the LMA must assume that no previous SMA exists and become the SMA for the mobility session of the MN. The SMA assigned IP address of a MN is the IP address the MN got assigned when it initially attached to a PMIP domain. The LMA can try to infer this IP address, for example, by analyzing the MN' s Router Solicitation or DHCP requests. Figure 2 shows the signalling flow when a MN attaches to a PMIP domain. The MN attaches to the MAG (Attach) and sends a router solicitation message (Rtr Sol) 10, to the MAG of the visited network domain. Thus, as in the normal PMIP case, the MN sends a Router Solicitation message 10 that is received by the local MAG.

The MAG then sends its Proxy Binding update 20 to the LMA. In other words, as a response, the MAG sends a Proxy Binding Update (PBU) message 20 to the LMAv to which the MAG is connected to. In general, a PBU is a binding registration request message sent by a mobile access gateway MAG to a mobile node's local mobility anchor LMA (in Fig. 2 identical with LMAv) for establishing a binding between the mobile node's home network prefix(es) assigned to a given interface of a mobile node and its current care-of address (Proxy-CoA), i.e. the SMA.

To register itself with the SMA as the new LMA for the MN, the LMA forwards this PBU 20 to the SMA as a message 30. In this way, the LMA (=LMAv) retrieves the SMA identification information from the PBU 20 and sends a PBU message 30 to the SMA. The

SMA then determines the corresponding policies for the MN as it would for a local MN and constructs the Proxy Binding Acknowledgement 40. The SMA is connected with the corresponding node for forwarding data from and to the MN via connection 50. Thus, the SMA responds to the PBU message 30 by sending back a PBA message 40 to the LMA. In general, a Proxy Binding Acknowledgement (PBA) message is a binding registration reply message sent by a local mobility anchor (in this case the SMA) in response to a PBU request message that it received from a mobile access gateway (MAG). Thus, the PBA 40 is sent to the LMA as if it were a local MAG and a bi-directional tunnel providing the connection 50 is established between the SMA and the LMA.

The LMA forwards the received PBA 40 in form of a PBA message 60 to its MAG which in turn uses the PBA 60 to configure the MN. Also, the LMA establishes a connection 70 to the MAG by providing a bi-direct tunnel to this MAG. All traffic for the MN is then routed from the SMA through the LMA and the MAG, i.e. via the concatenated connections 50 and 70.

Upon reception of PBA message 60, the MAG responds on the router solicitation message 10 by sending a Router Advertisement message (Rtr Adv) 80 to the MN. All future movements of the MN within the new PMIP domain are covered by local mobility operations, e.g. the operations described in as described in IETF draft ,,Proxy Mobile IPv6, draft-ietf-netlmm-proxymip6-15.txt" by NETLMM WG, S. Gundavelli (Editor); K. Leung, Cisco; V. Devarapall, Wichorus; K. Chowdhury, Starent Networks; B. Patil, Nokia Siemens Networks of May 16, 2008, a discussed in the introductory part of the description.

AU messages and steps described above are according to the protocol Proxy Mobile IPv6. In this standard, the particular physical implantations and respective definitions are discussed.

As connection between MN and mobility network domain pertaining thereto a wireless connection is used, e.g. WLAN, IEEE 802.11, or any other wireless data connection. The MN can be a WLAN enabled notebook as known from the prior art. The MAG (MAGs) and/or the LMA (LMAs) can be realized by a wireless router configured to realize the invention. As data base, a server can be used, e.g. an IP server comprising memory for storing the respective mapping data. Further, the mapping data (MN->SMA) can also be stored within the MN as binding data list as defined in the RFC standards given above, e.g RFC 3775.

Claims

1. Method for handovers between at least two network mobility domains, comprising the steps of: (a) providing each of the network mobility domains with a local mobility anchor;

(b) providing a mobile node being connectable with each of the network mobility domains;

(c) establishing a first connection between the mobile node and a first network mobility domain of the at least two network mobility domains; (d) designating the local mobility anchor of the first network mobility domain as a session mobility anchor, the mobile node being designated to the session mobility anchor as its local mobility anchor; after the steps (c) and (d), performing the step of:

(e) establishing a second connection between the mobile node and a second network mobility domain of the at least two network mobility domains; wherein the step (e) of establishing the second connection comprises:

(f) a local entity pertaining to the second network mobility domain locating the session mobility anchor to which the mobile node is designated, wherein the step of locating the session mobility anchor comprises a step of retrieving carried out by the local entity, the step of retrieving comprising: retrieving a session mobility anchor identification from at least one of: a transmission sent by the mobile node to the second network mobility domain, and a data base comprising a mobile node identification identifying the mobile node, the data base storing the mobile node identification related to a session mobility anchor identification of the session mobility anchor dedicated to the mobile node, the local entity comprising at least one of: a mobile access gateway of the second network mobility domain, the local mobility anchor of the second network mobility domain which provides a visited local mobility anchor, or another entity pertaining to and being connected to the second network mobility domain.

2. Method according to claim 1, further comprising: the visited local mobility anchor establishing a network tunneling connection between the session mobility anchor and the local mobility anchor of the second network mobility domain, the network tunneling connection providing a transparent data connection between the mobile node and the session mobility anchor via the mobile access gateway of the second network mobility domain.

3. Method according to claim 1, further comprising a step of providing the data base accessible by at least the visited local mobility anchor, wherein the session mobility anchor identification is retrieved from the data base, the local mobility anchor of the first network mobility domain transmitting the mobile node identification of the mobile node to the data base, the data base storing the mobile node identification in relation to local mobility anchor information identifying the session mobility anchor, the session mobility anchor transmitting the mobile node identification to the data base upon establishing a first connection or upon designating the local mobility anchor of the first network mobility domain as a session mobility anchor identification, wherein the data base stores a shared look-up data table of at least one mobile node identification related to at least one of the local mobility anchors, or a list of mobile node identifications related to the session mobility anchor, the data base residing at the mobile access gateway of the second network mobility domains, in a network connected to one of the network mobility domains, in the mobile node in a provider network or in a memory of a router as cached routing data pertaining to the session mobility anchor.

4. Method according to claim 3, wherein the step (f) of locating comprises: the visited local mobility anchor transmitting a look-up request message in order to retrieve an entry of the data base, and, in response to the look-up request message, transmitting a look-up response message to the visited local mobility anchor, the look-up response message comprising the session mobility anchor identification of the session mobility anchor dedicated to the mobile node.

5. Method according to claim 1, wherein the session mobility anchor identification is retrieved from a transmission sent by the mobile node to the mobile access gateway of the second network mobility domain, wherein the transmission comprises at least one of: a connection request, a DHCP request, router solicitation data, a router solicitation message, a message, a data packet, a data packet header, a signaling packet.

6. Method according to claim 1, wherein the mobile node is permanently designated to the session mobility anchor during the complete duration of the first connection, of the second connection and at least until a disconnection of the mobile node from the least two network mobility domains.

7. Local mobility anchor comprising a port and a retrieval unit for retrieving a session mobility anchor identification, the retrieval unit being connected to the port and being adapted to detect the session mobility anchor identification from a transmission received by the port and sent by the mobile node to a network mobility domain.

8. Local mobility anchor comprising an identification request port, a identification request generation unit connected to the identification request port, and an identification request receive unit connected to the identification request port, the identification request generation unit being adapted for generating a session mobility anchor request containing a mobile node identification identifying a mobile node connectable to the local mobility anchor, and transmitting the request via the identification request port to a data base connectable to the local mobility anchor and storing the mobile node identification related to a session mobility anchor identification of the session mobility anchor dedicated to the mobile node.

9. Computer program product comprising code, the code representing instructions implementing the step: retrieving a session mobility anchor identification from at least one of: a transmission sent by a mobile node requesting connection to a new network mobility domain different to a preceding network mobility domain to which the mobile node has been connected before requesting connection, and a data base comprising a mobile node identification identifying the mobile node requesting connection, the data base storing the mobile node identification related to a local mobility anchor identification of the preceding local mobility anchor dedicated to the mobile node.

10. An identification request response unit comprising a memory, a processor connected therewith, and a I/O-port connected to the processor, the memory maintaining a lookup table storing mobile node identifiers in relation to local mobility anchor identifiers, the local mobility anchor identifiers identifying local mobility anchors to which mobile nodes pertaining to the local mobility anchor identifiers are designated; the I/O-port adapted to receive requests containing one of the mobile node identifiers; the processor being adapted to process the requests, to retrieve the local mobility anchor identifier corresponding to the mobile node identifier from the memory and to transmit the local mobility anchor identifier via the I/O-port; the I/O-port being further adapted to receive an assigning message containing a local mobility anchor identifier as well as a mobile node identifier dedicated thereto; and the processor being further adapted to store the local mobility anchor identifier and the mobile node identifier of the assigning message in relationship to each other in the memory.