Home Agent Discovery upon Changing the Mobility Management Scheme

The present invention relates to a method of finding a home agent that manages (serves) a mobile node immediately after the mobile node changes its mobility management method in a packet switching network, and the mobile node. Furthermore, the present invention relates to a home agent that supports a mobile node when it discovers its own serving home agent immediately after changing the mobility management method.

Communication systems are evolving into Internet Protocol (IP) -based networks. The communication system consists of many interconnected networks, within which voice and data are transmitted in fragments, so-called packets, from one terminal to another. Each packet is routed forward by each router without a connection. Therefore, an IP packet consists of an IP header and payload information, which in particular contains the source and destination IP addresses. For scalability reasons, large IP networks are usually divided into subnets and use a hierarchical addressing scheme. Therefore, the IP address not only identifies the corresponding terminal, but also contains location information (current subnet) about this terminal. This location information is also typically referred to as an IP address prefix. The additional information provided by the routing protocol allows each router in a packet-switched network to identify the next router to a particular destination.

When a terminal is a mobile, a so-called mobile node (MN), that moves between subnets, the terminal may (allow the mobile node to hold its own address) because of a hierarchical addressing scheme. If this mechanism is not provided, see the article on proxy mobile IP below), you must change your IP address to a phase-correct address using the subnet prefix (domain). .. However, connections at higher layers, such as TCP connections on the transport layer of the OSI model, are defined by the IP address (and port) of the communicating node, so one of those nodes will, for example, move to own itself. If you change the IP address, the connection will be lost.

Mobile IPv6 Specified by Johnson et al., "Mobility Support in IPv6", IETF RFC 3775, June 2004 (available at http://www.ietf.org and incorporated herein by reference). Mobile IPv6 (MIPv6) is an IP-based mover that allows each mobile node to move between subnets in a way that is transparent to higher layers and applications, that is, without breaking higher layer connections. It is a protocol. Therefore, one mobile node has configured two IP addresses: awareness address (CoA) and home address (HoA). The higher layer of the mobile node uses the home address for communication with the communication partner associated with the destination terminal, the so-called communication partner (CN). This address does not change and serves the purpose of identifying mobile nodes. Topologically, the home address belongs to the mobile node's home network (HN).

In contrast, the awareness address changes with every move that causes a change in the subnet (new prefixes have been announced) and is used as a locator for the routing infrastructure. Topologically, the awareness address belongs to the network to which the mobile node is currently connected. One of a set of anchors, so-called home agents (HAs), placed on the home link holds the mapping of the mobile node's awareness address at the mobile node's home address and receives an incoming call for the mobile node. Redirects traffic to its current location. The reason for having a set of home agents instead of one is redundancy and load balancing.

Currently, mobile IPv6 defines two modes of operation: bidirectional tunneling and route optimization. When two-way tunneling is used, data packets sent by the other party and addressed to the home address of the mobile node are intercepted by the home agent in the home network and tunneled to the noticed address of the mobile node. .. The data packet transmitted by the mobile node is reverse tunneled to the home agent, which decapsulates the packet and transmits the packet to the communication partner. For this behavior, the home agent must be informed of the current location of the mobile node (ie, the awareness address). Therefore, the mobile node sends a location update message to the home agent, which is called a binding update (BU) message in MIPv6. The binding update message includes a sequence number so that the home agent can identify the newness and correct order of the binding update message. These binding update messages are sent over the IPsec Security Association and are cryptographically protected to provide data origin authentication and integrity protection. This requires mobile nodes and home agents to share a private key. Therefore, the home agent only receives binding update messages for the home address of the mobile node, which is encrypted with the corresponding shared key.

Extension to mobile IPv6 Mobile IPv6 has been extended in recent years to allow mobile nodes to be dynamically bootstrapped by home agents (available at http://www.ietf.org and incorporated herein by reference). , Giaretta et al., Mobile IPv6 Bootstrap in Split Scenarios, RFC 5026, October 2007). Bootstrapping includes discovering the home agent, setting up a security association to ensure mobile IP signaling, and configuring the corresponding home address with the home agent.

IPsec security associations may be dynamically established using IKEv2. IKEv2 is Kaufman's Internet Key Exchange (IKEv2) Protocol, IETF RFC 4306, December 2005; Arkko et al., "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", IETF RFC 3776, June 2004, and Devarapalli et al., "Mobile IPv6 Operation and Revised IPsec Architecture with IKEv2," IETF RFC 4877, April 2007 (all three documents at http://www.ietf.org) Available and incorporated herein by reference). Another protocol that allows the establishment of security associations to ensure mobile IP signaling is available from http://www.ietf.org and is contained herein by reference by Patel et al. Authentication Protocol for Mobile IPv6 , IETF RFC 4285, an authentication protocol from January 2006.

There are multiple ways to discover home agents by mobile nodes. One option is for the mobile node to be preconfigured with the Home Agent's DNS name and query the DNS (Domain Name System) for a list of Home Agent's IP addresses (http: // www. Giaretta et al., "Mobile IPv6 Bootstrap in Split Scenarios," RFC 5026, October 2007), available from ietf.org and incorporated herein by reference). Another option is for the mobile node to be preconfigured with a suffix of the anycast home agent address and to a group of home agents via anycast to the DHAAD message (IETF RFC). 3775) or IKE_SA_INIT messages (available from http://www.ietf.org and incorporated herein by reference) by Dupont et al., IKEv2-based homes in mobile IPv6 / NEMO bootstraps. Agent Assignment , IETF Internet Draft, draft-dupont-ikev2-hassign-02.txt, see January 2007). The anycast home agent address prefix can be preconfigured on the mobile node or dynamically retrieved from the network. Further, the prefix may be the same as the prefix of the home address of the mobile node.

This anycast concept assigns multiple home agents the same anycast address, and messages sent to this anycast are delivered to any home agent that is part of the anycast group. .. Typically, the message is delivered to the home agent closest to the sender. You can also combine the discovery of DNS-based home agents with the discovery of anycast-based home agents. Therefore, the mobile node is preconfigured with a DNS name, and DNS returns an anycast address. Figure 1 shows an example of finding a home agent using IKE Anycasting.

In a deployment scenario where the access network operator and the home network operator are the same or have a trust relationship, the home agent address for the mobile node is assigned by the home network or visiting network and uses the AAA protocol. It is delivered to the access network via and can be assigned to mobile nodes using the DHCP protocol. With this approach, the mobile node queries the DHCP server to obtain the home agent IP address (both available from http://www.ietf.org and incorporated herein by reference, by Chowdhury et al. "MIP6 Bootstrapping for Integration Scenarios", IETF Internet Draft, draft-ietf-mip6-bootstrapping-integrated-dhc-05.txt, June 2007, and Hee Jin See Jang et al., DHCP Options for Home Information Discovery in MIPv6, IETF Internet Draft, draft-ietf-mip6-hiopt-10.txt, January 2008).

Client-based vs. network-based mobility management Mobile IP is a host-based or client-based protocol because mobility management signaling lies between the host / client and the home agent. Therefore, MIP is sometimes also referred to as Client Mobile IP (Client MIP or CMIP).

Another increasingly popular approach is the network-based approach for IP mobility management. Entity in the visit access network acts as a proxy for the mobile node and manages mobility to the mobile node, including signaling location updates to the home agent. Network-based mobility management is considered to have several advantages, such as less signaling overhead than wireless and mobility support for simple IP nodes (ie, non-client MIP capable nodes). A commonly identified drawback is that this management requires support from the visit access network.

The IETF (Internet Engineering Task Force) is working on such an approach for local mobility management based on the Mobile IP protocol. The protocol is called a proxy mobile IP (proxy MIP or PMIP) because the network entity acts as a proxy on behalf of the mobile node. A variant of IPv6 called PMIPv6 (available from http://www.ietf.org and incorporated herein by reference), "Proxy Mobile IPv6" by Gundavelli et al., IETF Internet Draft, draft-ietf-netlmm. -proxymip6-10.txt, see February 2008), and a variant of IPv4 called Proxy MIPv4 (available from http://www.ietf.org and included herein by reference). See Leung et al., WiMAX Forum / 3GPP3 Proxy Mobile IPv4, IETF Internet Draft, draft-leung-mip4-proxy-mode-07.txt, February 2008).

PMIPv6 introduces a new logical entity called the Mobile Access Gateway (MAG), which is typically co-located with the access router (AR) to which the mobile node is currently connected. Send a binding update message on behalf of the mobile node. Proxy MIP-Home Agent is an extended Client MIP-Home Agent Anchor, called the Local Mobility Anchor (LMA). Since the local mobility anchor includes a home agent function, the local mobility anchor may also be referred to herein as a home agent. Each binding update message sent by the mobile access gateway is marked with a flag so that the binding update message can be identified as a proxy binding update (PBU) message by the local mobility anchor. , Can be distinguished from each binding update message (ie, CMIP signaling message) sent by the mobile node.

In addition, proxy binding update messages include, among other things, network access identifier (NAI) options, home prefix options, and timestamp options. NAI options are available (available from http://www.ietf.org, "Network Access Identifiers" by Aboda et al., Included herein by reference, IETF RFC 4282, as defined in December 2005). It includes the NAI of a mobile node, which has the form "username @ realm" and is used to identify the mobile node.

Home prefix options include the home address or home prefix of the mobile node. In proxy MIPv6, typically every mobile node is assigned a unique prefix. When a mobile node connects to a new mobile access gateway, the mobile access gateway sends a proxy binding update to the local mobility anchor to register the new location for that mobile node. Proxy binding updates can be triggered, for example, by successful network authentication, by DHCP (Dynamic Host Configuration Protocol) messages or otherwise. In addition, the mobile access gateway notifies the mobile node of the home prefix of the mobile node. Therefore, the mobile node's IP stack thinks it is at home and is unaware that it will change subnets as long as the mobile node moves inside the proxy MIP domain. A tunnel is established between the local mobility anchor and the mobile access gateway, and all traffic from / to the mobile node is forwarded through this tunnel.

3GPP SAE Systems (both available at http://www.3gpp.org and incorporated herein by reference) 3GPP TS 23.401 "General Packet Radio Service for Evolved UMTS Radio Access Network (E-UTRAN)" (GPRS) Improvements, version 8.0.0, and 3GPP TS 23.402, Architecture Improvements for Non-3GPP Access, version 8.0.0) for mobility management for handovers between access technologies. Both MIPv6 and proxy MIPv6 (client) are specified. The home agent function and local mobility anchor function are part of the public data network gateway (PDN-GW), the mobile node function is part of the user device (equivalent to the mobile node), and the mobile access gateway function is. , Part of the Evolved Packet Data Gateway (ePDG), Access Gateway and Access Router for non-3GPP networks. Equivalent words are used interchangeably below.

3GPP SAE systems define different types of access networks. 3GPP access networks use 3GPP wireless technologies such as GSM / GPRS, UMTS, LTE to provide network access to terminals, while non-3GPP access networks use non-3GPP wireless technologies such as WLAN, WiMax, CDMA2000, etc. And provide network access. Non-3GPP access networks can be further subdivided into trusted non-3GPP access networks and untrusted non-3GPP access networks, depending on the level of trust by the 3GPP operator. Terminals located within a trusted non-3GPP access network can directly access 3GPP services such as the mobile IPv6 service provided by PDN-GW, while being located within an untrusted non-3GPP access network. The terminal may access the 3GPP service only when it is on the ePDG. The terminal must first authenticate with the ePDG, and then all traffic from and to the terminal is protected with integrity and confidentiality and sent to the ePDG over a secure IPsec tunnel. Is similar to a VPN server. The terminal typically uses DNS to discover the ePDG address and IKEv2 to set up an IPsec tunnel.

It is possible that some access networks support PMIP but others do not. Therefore, mobility management for mobile nodes can be migrated from PMIPv6 to MIPv6 during a session and vice versa. If a mobile node is migrating from a domain with network-based mobility management to a domain with host-based mobility management, the mobile node can be guaranteed session continuity by the network. It is necessary to discover and register the anchor (home agent) that was once used. Since the mobile node typically does not know its home agent when mobility is managed by the network, the mobile node receives abruptly to prevent visible interruptions during data service. Mobile nodes need to discover a particular home agent as quickly as possible, at least if the discovery cannot be made before the handover in a predictable way, for example because they have gone out of the available area. .. In addition, one node should not be able to identify the home agent serving another mobile node. Otherwise, an out-of-route attacker could implement a targeted denial of service (DoS) attack against the home agent of a particular mobile node.

An object of the present invention is to propose a home agent discovery method that maintains session continuity in a seamless manner immediately after a mobile node changes its own mobility management method.

This object is solved by the subject matter of the independent claims. An advantageous embodiment of the present invention is the subject of the dependent claims.

The main gist of the present invention is for a mobile node to reveal to the network information about its former movement or location (such as a former connection point) during the anchor (home agent) discovery process. If a home agent discovery message from a mobile node is received by the home agent or home agent discovery server, the home agent or home agent discovery server will use the mobile node before the correct anchor (ie, mobility management method change). A clue can be returned to the mobile node to help discover the home agent on which the mobile node is registered.

In some cases, the clues in the response message may already be sufficient to uniquely identify the serving home agent so that another home agent discovery message is received by the mobile node on the correct home agent. unknown. If not, the home agent may also return a response message to the mobile node containing clues to help the mobile node find the correct anchor, and the mobile node sends another home agent discovery message. You may use these new clues in doing so. In general, clues in the response message may be determined by the home agent (discovery server), for example, based on information about the former location of the mobile node included in the home agent discovery message by the mobile node.

According to an exemplary embodiment of the present invention, there is provided a method of finding a home agent serving a mobile node immediately after the mobile node changes its mobility management method in a packet-switched network. In this way, the mobile node sends a home agent discovery message to the home agent discovery server. The home agent discovery message contains information about the location of the mobile node before changing the mobility management method. The mobile node also receives a response message from the home agent discovery server with information to assist the mobile node in discovering the home agent serving the mobile node. The mobile terminal sends another home agent discovery message to the home agent based on the information contained in the response message received from the home agent discovery server.

For example, the home agent discovery server may be a home agent in a core network, a NAS / DHCP server, or a trusted packet data gateway, such as an evolved packet data gateway in a 3GPP-based network.

Sending a home agent discovery message to a home agent or home agent discovery server necessarily suggests that the destination identified in the home agent discovery message is a unique identifier for each home agent or home agent discovery server. It should be noted that it is not. In an exemplary variant of this embodiment, the mobile node uses an anycast address, a multicast address, or a unicast address as the destination address of the home agent discovery message sent to the home agent or the home agent discovery server. Therefore, the home agent discovery message may be sent, for example, to a group address that identifies a plurality of nodes, or to an address that uniquely identifies a specific node in the packet-switched network.

In another exemplary variant of this embodiment, the home agent discovery server and / or home agent receiving the home agent discovery message is based on the location information provided by the mobile node in its home agent discovery message. , Determine the information to be included in the response message.

In another embodiment of the invention, the mobile node (next) from the information contained in the response message received from the home agent discovery server or another home agent that received the mobile mode home agent discovery message. Derivation of the destination address of the home agent discovery message. For example, the information contained in the response message is redirect information that instructs or permits the node to derive the anycast group address, multicast group address, or unicast address of the home agent to which the next home agent discovery message is addressed. It is possible. In another example, the anycast group address or unicast address may be a temporarily valid address and / or is configured for use only by the mobile node or group of mobile nodes. Therefore, the mobile node may use the address provided in the response message as the destination address of the next home agent discovery message.

It should be noted that the information in the response message received on the mobile node in response to the home agent discovery message does not necessarily have to be a (routable) address. In another exemplary embodiment, the information may include clues, which are valid addresses from the clues contained in the response by the mobile node (anycast group address, multicast group address or unicast discussed above). Cast address, etc.) can be derived. Such clues may be, for example, a subnet address prefix or (part of) a DNS domain name.

Furthermore, in another exemplary embodiment of the invention, the first home agent discovery message sent by the mobile node immediately after changing the mobility management scheme may not only include location information, but also by the mobile node. The home agent discovery message (s) sent may include information about the location of the mobile node before changing the mobility management scheme. The content of the home agent discovery message may depend, for example, on whether the mobile node is able to derive its own serving home agent from the information contained in the response message to the home agent discovery message that was once sent. For example, if the response includes a unicast address that identifies a single home agent, the mobile node may assume, for example, that the identified home agent is the home agent serving that mobile node. Often, therefore, location information may not be included in the home agent discovery message.

In another embodiment of the present invention, a home agent that receives a home agent discovery message from a mobile node but does not serve the home agent in which the mobile node is registered determines the home agent that serves the mobile node. Help the mobile node discover or send a response message containing information indicating that the other mobile node is the home agent serving the mobile node.

In another exemplary embodiment, the home agent discovery message and the response message to it are messages of an authentication procedure for authenticating a mobile node. For example, the authentication procedure may be a procedure for establishing a security association between the mobile node and each home agent. In a variant of this exemplary embodiment, if the home agent indicates in its response message to the home agent discovery message that it is the home agent serving the mobile node, then the mobile node is said to be You may continue the authentication procedure and update your bindings in the packet-switched network (eg, by binding update) by your home agent.

In another embodiment of the invention, the home agent discovery message sent to the home agent discovery server is a DHCP information request message that includes additional location information. Thus, the home agent discovery server in this exemplary embodiment is a DHCP server that responds to DHCP request messages with a DHCP information response that includes clues to help the mobile node discover the correct home agent.

In another embodiment of the invention, the home agent discovery message sent to the home agent discovery server is a binding update that includes authentication options that are extended by location information. Therefore, the home agent discovery server in this exemplary embodiment is a home agent, and the response message of the home agent discovery server additionally contains clues to help the mobile node discover the correct home agent. It is a binding reception confirmation.

As already shown above, in one exemplary embodiment, the mobile node may iteratively send home agent discovery messages to other home agents until the termination condition is reached. Such termination conditions may, for example, indicate in the response message that the home agent is the home agent serving the mobile node, or may be reaching the iteration threshold, or (eg, response). The response message already proves that the mobile node is not a registered home agent (if the message contains an address that has already been used as the destination address for past home agent discovery messages): Create a home agent discovery message address.

In another embodiment of the invention, one or all of the home agent discovery messages sent by a mobile node include a temporary identifier for that mobile node. The mapping of the temporary identifier to the corresponding non-temporary identifier of the mobile node is known only to the home agent (discovery server) and the mobile node.

In one variant of this embodiment, the home agent (which can also be the home agent discovery server) that receives the home agent discovery message uses the mobile node's temporary or non-temporary identifier to enter the binding cache entry for that mobile node. You may search for. An example of a mobile node's non-temporary identifier is the NAI (Network Access Identifier) or address of the mobile node. An example of a temporary identifier is TMSI (Temporary Mobile Subscriber Identity) or Pseudo NAI when implementing the invention within a 3GPP-based mobile communication system such as UMTS or LTE / SAE. Pseudo-NAI uses the pseudo-username in the username section of NAI (available from http://www.ietf.org and is incorporated herein by reference in the "third generation extension" of Arkko et al. Possible Authentication Protocol Methods, Authentication and Key Sharing (EAP-AKA), IETF RFC 4187, Section 4.1.1.9). In another example, the temporary identifier can be created as part of the NAI by using TMSI.

In another variant of this embodiment, the home agent that receives the home agent discovery message serves the mobile node if there is no binding cache entry for the mobile node in the home agent's binding cache. Respond to the home agent discovery message by sending a response message containing information that helps the mobile node discover the agent. Otherwise, the home agent indicates in a response message that it is a home agent that has served the mobile node before the mobile node changed its mobility management scheme.

In another exemplary embodiment of the invention, the home agent discovery server is located within a domain where client-based mobility management schemes are used. In addition, the home agent (s) that receive the home agent discovery message from the mobile node may be located in another domain that provides a network-based mobility management scheme.

In another exemplary embodiment of the invention, the trigger for the mobile node to change the mobility management scheme supports client-based mobility schemes from one domain that supports network-based mobility schemes. Handover of the mobile node to another domain or vice versa.

As previously indicated, in some embodiments of the invention, the home agent discovery message and the response message to it are messages of an authentication procedure for authenticating the mobile node. The information contained in the response message is information that helps the mobile node discover another home agent (ie, the response from the home agent is the home on which the home agent serves the mobile node. If not (indicating that it is not an agent), the authentication procedure is restarted based on the information contained in the response message to the home agent address message.

Another embodiment of the present invention relates to a mobile node that discovers that a home agent is serving a mobile node immediately after changing its mobility management scheme within a packet-switched network. The mobile node is a transmitter that sends a home agent discovery message to the home agent discovery server, and the transmitter contains information about the location of the mobile node before the home agent discovery message changes the mobility management method. , And a receiver that receives a response message from the home agent containing information that assists the mobile node in finding the home agent that serves the mobile node. The mobile node transmitter is capable of sending another home agent discovery message to another home agent based on the information contained in the response message received from the home agent discovery server.

The mobile node according to another embodiment of the present invention is a processing unit that derives the destination address of the home agent discovery message from the information contained in the response message received from the home agent discovery server (or home agent). To be equipped. In one variant of this embodiment, the mobile node uses the address provided in the response message as the destination address of the (next) home agent discovery message sent to one (other) home agent.

According to another embodiment of the present invention, the processing unit of the mobile node continuously determines the information related to the position of the mobile node, and stores the position information in the storage device included in the mobile node. To do. In one exemplary implementation, the mobile node stores location information that has been determined since the last change in mobility management schemes. The location information is, for example, the identifier of the mobile access gateway that the mobile node initially connected to, the record of the mobile access gateway identifier that the mobile node was connected to while moving in the network, periodically or by the GPS receiver of the mobile node. It may be a recording of a GPS position triggered by an event and determined. Therefore, the term "continuously" should not be misunderstood as relating only to a permanent record of location-related information, and conversely, it should be triggered by a location event or timer-based on a regular basis. Can also be included.

Further, in one embodiment of the invention, the home agent indicates that it is the home agent serving the mobile node in the response message, or another termination condition (eg, the maximum number of home agent discovery messages sent). Until it reaches, the mobile node causes its transmitter to repeatedly send home agent discovery messages to each of the other home agents.

Other embodiments of the present invention relate to home agents for use within packet-switched networks. The home agent includes a receiver that receives a home agent discovery message from the mobile node that includes information about the location of the mobile node before changing the mobility management method. The home agent also holds (stores) the bindings of multiple mobile nodes served by the home agent in a binding cache (eg, storage) and the mobile node that is the source of the received home agent discovery message. It has a processing unit that determines whether or not there is a binding cache entry for.

The processor also finds a home agent serving the mobile node based on the location information contained in the home agent discovery message if there is no binding cache entry for the mobile node. It may be designed to determine the information that assists. In addition, the home agent is the source of the received home agent discovery message with a response message in the home agent transmitter that contains information that assists the mobile node in discovering the home agent serving the mobile node. It may have the ability to send to a mobile node.

In another embodiment, the processing unit of the home agent determines the anycast group address, multicast group address, or unicast address of another home agent (or a group of home agents) based on the location information received from the mobile node. It is configured to determine.

In one exemplary embodiment, the home agent is located within the core network of a mobile communication system, such as a 3GPP-based mobile communication network.

Another embodiment of the present invention relates to a packet-switched communication network comprising one mobile node and / or at least one home agent, according to one of the various embodiments described herein.

Another embodiment of the present invention serves the mobile node to the mobile node immediately after the mobile node changes its mobility management method in the packet switching network when executed by the processing device of the mobile node. Store instructions to discover the home agent and provide a computer-readable medium. The mobile node sends a home agent discovery message to the home agent discovery server, and the home agent discovery message contains information about the location of the mobile node before changing the mobility management method, and from the home agent discovery server, the mobile node concerned. Receive a response message containing information to help the mobile node discover the home agent serving the mobile node, and another based on the information contained in the response message received from the home agent discovery server. You can discover your own serving agent by sending a home agent discovery message to another home agent.

Another embodiment of the present invention provides a mobile node with information that assists the mobile node in discovering a home agent serving the mobile node when executed by the home agent: Home agent discovery from the mobile node. To receive the message, the home agent discovery message contains information about the location of the mobile node before changing the mobility management method; bindings of multiple mobile nodes served by the home agent. Keeping in the binding cache; determining if there is a binding cache entry for the mobile node that originated the received home agent discovery message; binding cache entry for that mobile node If is not present, the location information contained in the home agent discovery message is used to determine information to assist the mobile node in discovering the home agent serving the mobile node; By sending a response message containing information to assist the mobile node in discovering the home agent serving the mobile node to the mobile node that is the source of the received home agent discovery message: Concers a computer-readable medium that stores instructions to be provided to an agent.

Hereinafter, the present invention will be described in more detail with reference to the accompanying drawings. Similar or corresponding details in the drawings are numbered the same.<figref num="1">The IKEv2 signaling procedure by Dupont et al. "IKEv2-based home agent assignment in mobile IPv6 / NEMO bootstrap" is shown.</figref><figref num="2">An exemplary packet-switched network that provides different mobility management schemes within different network areas is illustrated, based on which each aspect of the invention will be illustrated in more detail.</figref><figref num="3">An exemplary signaling flow according to an exemplary embodiment of the present invention for discovering a home agent serving a mobile node and registering the mobile node with the discovered serving home agent is shown.</figref><figref num="4">An exemplary of the invention that allows to discover a home agent serving a mobile node, establish an IPsec security association with the serving home agent, and subsequently send binding updates to that serving home agent. The modified IKEv2 signaling procedure according to the above embodiment is shown.</figref><figref num="5">An exemplary signaling flow according to an exemplary embodiment of the present invention for discovering a home agent serving a mobile node and registering the mobile node with the discovered serving home agent is shown in the first home. The home agent that receives the agent discovery message does not have to identify the home agent that serves the mobile node.</figref><figref num="6">An exemplary signaling flow of a modified dynamic home agent discovery procedure according to an exemplary embodiment of the invention is shown.</figref><figref num="7">An extended binding update procedure according to an exemplary embodiment of the invention is provided with an authentication option for discovering a home agent on which a mobile node is registered.</figref><figref num="8">Shown is an exemplary DHCP signaling according to an exemplary embodiment of the invention for discovering a home agent in which a mobile node is registered.</figref><figref num="9">Illustrating an exemplary scenario according to another aspect of the invention, the data path for a mobile node is optimized after moving the mobile node from a trusted access network to an untrusted access network.</figref>

Hereinafter, the principles of the present invention will be described with respect to various embodiments. For illustrative purposes, most of the examples below are used by (client) mobile IP, either changing from a network-based mobility scheme to a client-based mobility scheme, or out of the reach of a proxy mobile IP domain. For mobile nodes that enter the network area.

When a mobile node is connecting to a network that uses network-based mobility management, the network selects an anchor (home agent / local mobility anchor) for the mobile node and uses standard signaling mechanisms. Register the mobile node with this home agent / local mobility anchor. If the mobile node moves from this network area with network-based mobility management to a network area with host-based mobility management, the IP address prefix in this new network area is typically , Different from what is provided to a mobile node in a network area that uses network-based mobility management (in the case of PMIP, the home address prefix of that mobile node). Therefore, the mobile node needs to configure a new IP address according to the prefix notified in the new access area and register the newly configured address in its anchor (home agent) as its own notice address. is there.

To provide session continuity, mobile nodes must register with the same anchor (home agent) that they registered when using network-based mobility management. In other words, if a mobile node leaves the PMIP domain and enters another domain (which has an IP address prefix different from the IP address prefix provided within the PMIP domain), the mobile node is phased. You need to register the correct IP address with the home agent in the PMIP domain that was registered by your PMIP proxy in the PMIP domain. Therefore, the mobile node should be enabled to discover the address of the home agent that the network has once registered with the mobile node. The reason is that the registration of a mobile node within the PMIP domain was transparent to that mobile node, and as a result, the mobile node is unaware of its serving home agent.

In particular, a mobile node is moving within a huge packet-switched network with many home agents (eg, a network of large operators in China, India or the United States), and the mobile node has been in session since the initial connection. If the mobile node has traveled a long distance in, the mobile node may find the wrong home agent in a different network area at the start of the (client) mobile IP boot. The reason is that the home agent discovery or assignment mechanism is typically designed to assign a home agent that is closer to the current location of the mobile node. For example, an anycast home agent discovery message is typically delivered to the closest member of all anycast group members. However, the member is not necessarily the home agent who served the mobile node after the move and before booting into the new network area.

FIG. 2 illustrates an exemplary packet-switched network that provides different mobility management schemes within different network areas, based on which each aspect of the invention is illustrated in more detail. For example, within one area of the network may be a 3GPP-based network that provides access via its own radio access network and network-based mobility management (see left side of Figure 2). On the other hand, there is a second network area (see right side in Figure 2), which provides, for example, wireless LAN access and uses a client-based mobility scheme. The first and second network areas typically advertise various address prefixes on the wireless link.

The operator or part of its core network may be considered a CMIP home network for mobile nodes. The core network connected to each access network may be logically divided into different areas, and the core network of area number 1 includes three home agents 204, 205, and 206, in which the home agent is a mobile access gateway. MAG201, 202, 203 register mobile nodes in the PMIP domain provided within the 3GPP network area. In addition, each address prefix for home agent addresses within different core network regions may be the same or different. Each home agent in a particular area may be assigned to a different group, each with a common group identifier (eg DNS name, anycast address or multicast address).

The core network of region number 2 also has three home agents 208, 209, 210, which are connected to the access network by the access router AR207. Each node in a different core network area is interconnected and may be individually connected to the Internet to route traffic to several destinations connected to the Internet (eg, communication partners). For illustrative purposes, the network area, which provides 3GPP-based access and uses a network-based mobility scheme and is assigned core network area number 1, is geographically located in Shanghai, China. On the other hand, the network area to which core network area number 2 is assigned while providing WLAN access and client-based mobility management method is geographically located in Beijing, China.

The mobile node 200 uses network-based mobility management and may be assumed to be initially connected to a 3GPP-based network area in Shanghai, China, which assigns the home agent 204 to the mobile node 200. Users of Mobile Node 200 then travel long distances to Beijing, China, where they travel to network areas with host-based mobility management. When initiating a (client) mobile IPv6 boot in Beijing, China, mobile node 200 discovers one of the three home agents in core network area number 2 (eg, home agent 208) and said the home agent. Is not the home agent 204 with the mobile node registered, and is therefore the "wrong" home agent and cannot provide session continuity.

One approach considered by the present invention to overcome this undesired situation is that the mobile node 200 first begins to discover any home agent within the network area to which it has moved, and said movement. When mode 201 attempts to register with a home agent that has discovered its new address (home agent 208 in this example), the home agent 208 sends mobile node 200 to the correct home agent (home agent 204 in this example). Is to relocate. However, this approach synchronizes the binding cache of all home agents in the network so that all home agents know the correct home agent for every mobile node and the mobile node is correct during the binding update procedure. Must be able to relocate to a home agent. Obviously, in large networks where many home agents and mobile nodes are served, this can be cumbersome and inefficient, but can be resolved by removing the decision to move to another entity, such as a AAA server.

Even if such a solution is implemented, another important issue is handover delay. The handover delay in this proposed solution may be assumed to be very high if the home agent discovery cannot be proactively performed (but not always possible) prior to the handover. The reason is that the mobile node must first bootstrap the security association, then register with the wrong home agent, then dismantle the security association and registration again, and finally start the boot with the correct home agent. Because. This can result in unwanted or even unacceptable interrupts for the service (from the user's point of view). Removing the transfer decision to a central entity such as AAA can further increase the handover delay, as it typically requires additional signaling between the home agent and the central entity (AAA server).

Another, potentially more preferred approach, according to the main aspects of the invention, is for the mobile node's former movement or location when it is necessary to discover its own home agent with which it is registered. Is to reveal the information of. When a home agent discovery message containing such information from a mobile node is received by the home agent or home agent discovery server, the home agent or home agent discovery server uses the home agent on which the mobile node is registered as the mobile node. Can return clues to mobile nodes to help them discover. A mobile node attempts to discover, for example, its own serving home agent immediately after a mobility management change due to, for example, the movement of the mobile node, the movement of the mobile node to an untrusted access network, etc. May be good.

The information contained in the response by the home agent or home agent discovery server is, for example, a clue that allows the mobile node to derive a valid address (eg anycast group address, multicast group address or unicast address). May include. In general, one or more clues provided to a mobile node should be, for example, an address prefix, an address suffix, or a home agent on which the mobile node is registered. It may be (a part of) the DNS domain name of the domain assumed by the discovery server. Another possibility is to include one or more addresses in the response message, if available.

To help the home agent or home agent discovery server determine the clues or redirect information to be provided to the mobile node, for example, does the mobile node change the mobility management method to the home agent discovery message? Information indicating the location or movement of the mobile node, such as the location of the mobile node at the time of initial connection before connecting to an untrusted access network, may be included so that the network covers everything in the network. Can help identify the home agent serving the mobile node without asking for synchronization of the home agent's binding cache.

Such information, which is also referred to as location information in the present specification, includes, for example, an identifier (for example, an IP address, a layer 2 address of a base station (for example, a MAC address), etc.), a mobile access gateway or an access router to which the mobile node is connected. The geographic location of the mobile node (eg, obtained from a GPS receiver), cell ID, SSID, routing / tracking area, public terrestrial mobile network identifier, or even notified service information, access network or access technology. It may be a type. The mobile node is determined by the mobile node on a periodic or event-triggered basis, etc., about its position at the time of initial connection and / or the position visited by itself while moving in the packet switching network. May include information about. In some cases, a single former location (eg, a single former location) is required to allow the home agent or home agent discovery server to obtain clues about the correct location or address of the serving home agent on the mobile node. It may be sufficient to include only the initial connection location) in the home agent discovery message.

In addition to or as an alternative to location information, the mobile node may also indicate the identifier of the mobile node in the home agent discovery message. For example, such an identifier may be the NAI of the mobile node, its current address or prefix.

Therefore, the home agent or home agent discovery server is a clue that it communicates with the requesting mobile node in the home agent discovery response message based on the mobile node's identifier and / or location information in the home agent discovery message. Can be derived. In addition, the home agent or home agent discovery server may retain other information, mapping information, which allows the mobile node to have (part of) the location information and / or the identifier of the mobile node. Allows you to map to clues that help you find your home agent. For example, a home agent may hold a list of mobile access gateway identifiers, such as domains or address prefixes, that can be provided to mobile nodes as clues to identify a given area within a packet-switched network. .. Another option is for the home agent to determine the configurable address (anycast, multicast, or unicast) that the home agent or home agent discovery server provides to the mobile node based on the identified network area. It may be possible.

In some cases, the clues in the response message received from the entity to which the first home agent discovery message was sent may have been sufficient to uniquely identify the serving home agent (even unicast). This address should be, but not necessarily, the address of the home agent on which the mobile node is registered, even if the address is provided in response to the first home agent address discovery message. Note that it is not necessary). Optionally, the home agent discovery message may have a flag indicating the certainty of clues during the home agent discovery. For example, if the home agent can identify the (unicast) home agent address of the home agent on which the mobile node is registered, the home agent will include the (unicast) home agent address in the response message, and , A flag may be set in the mobile node to indicate to the mobile node that the home agent is confident that the indicated address is correct. This makes it possible to reduce the signaling overhead. The mobile node does not have to confirm whether the instructed home agent is actually the home agent to which the mobile node is registered, and the mobile node is sent to the home agent next. It is not necessary to include location information in the message of.

If the information in the home agent discovery response is incorrect, the home agent that receives another home agent discovery message sent by the mobile node also contains new clues to help the mobile node discover the correct anchor. The response message may be returned to the mobile node, and the mobile node may use the new clue in sending another home agent discovery message. In general, clues in a response message are, for example, a home agent or home agent discovery server based on information about the mobile node's former location (s) included in the home agent discovery message by the mobile node. May be determined by.

It should be noted that in general, the terms "home agent discovery message" and "home agent discovery server" have been used herein. The reason is that it may be different in which signaling procedure the location information of the mobile node is included. Therefore, the term "home agent discovery message" includes at least one of the location information of the mobile node and the mobile node identifier, and the entity that receives the home agent discovery message is not the home agent to which the mobile node is registered. Is understood as a signaling message that triggers the receiving node to respond (Home Agent Discovery Response) by sending clues that allow the mobile node to discover its serving home agent. It shall be. In this regard, the home agent discovery server refers to a server or network node within the core network or packet-switched network of the mobile communication system that receives and responds to the home agent discovery message.

The home agent discovery message and response may be, for example, a newly defined signaling message added to an existing signaling procedure, or an extended signaling message of an existing signaling procedure. For example, in some embodiments, the home agent discovery message and the response message to it are for authenticating a mobile node or for exchanging a shared key and receiving the home agent discovery message with the mobile node. Message of the authentication procedure that establishes a security association with. This authentication procedure may be, for example, an IKEv2 signaling procedure for establishing an IPsec security association (see IETF RFC 4306, IETF RFC3776, and IETF RFC 4877 previously described herein) and is a home agent. The discovery message and its response may be a modified message of this signaling procedure.

In some other embodiments of the invention, the home agent discovery message sent to the home agent discovery server is a binding update that includes an authentication option (provided in IETF RFC 4285) that is extended by location information. .. Therefore, the home agent discovery server in this exemplary embodiment is a home agent, and its response message is a binding receipt confirmation that additionally contains clues to help the mobile node discover the correct home agent. is there.

In yet another embodiment of the invention, the home agent discovery message sent to the home agent discovery server is a DHCP information request message that includes additional location information and optionally a mobile node identifier. Thus, the home agent discovery server in this exemplary embodiment is a DCHP server responding to a DHCP request message with a DHCP information response that includes clues to help the mobile node discover the correct home agent.

FIG. 3 is an exemplary signaling for discovering a home agent serving mobile node 200 and registering the mobile node 200 with the discovered serving home agent 204, according to an exemplary embodiment of the invention. Shows the flow. The mobile node 200 has a session in progress while traveling through the network, and when located within the PMIP domain, a network-based mobility management protocol (here a proxy for illustration purposes). It can be assumed that the 301 transfers session data by utilizing MIPv6).

For example, the mobile node 200 loses coverage of the handover / PMIP domain access network, leaves the PMIP domain, or moves into a network area where better quality of service can be provided by another access technology. Immediately after the move, change the mobility management method (here, client MIPv6 for illustrative purposes) (step 302). The change to client MIPv6 requires a new topologically correct awareness address configuration (eg, subnet or (sub) domain) for communication on mobile node 200 inside the client MIPv6 network area. To ensure session continuity, the mobile node 200 must register its newly configured awareness address with the home agent serving the mobile node 200 before changing the mobility management method. .. Since the proxy MIPv6 has been used immediately after the initial connection before the change to the mobility management method client MIPv6, it can be assumed that the mobile node 200 does not know its own serving home agent.

Mobile node 200 sends a home agent discovery message to the new network area (client MIPv6 access network area and core network area number 2 in this example) (step 303). This message may be sent, for example, using anycast addresses of all home agents in the network as destination addresses.

The home agent discovery message helps the recipient of the message identify the correct home agent serving the mobile node (step 304), or the location or network area where the serving home agent should be found. It contains local information that can at least make it possible to provide clues about (eg, clues to core network area number 1) to mobile node 200.

The local information included in the home agent discovery message may be, for example, information about the initial connection point of the mobile node 200 in the network area before changing the mobility method (proxy MIPv6 domain in this example). The reason is that this early connection point is where the network allocates a home agent for the mobile node 200 and the home agent allocation algorithm typically takes into account the current location of the mobile node. ..

The points of connection are, for example, the identified geographic location (eg, if the mobile node 200 has a GPS receiver), the IP address of the MAG / default router, the cell ID, the SSID, (mobile), as mentioned earlier. It can be the type of routing / tracking area, public terrestrial mobile network identifier, notified service information, access network or access technology (if node 200 was previously within 3GPP access). If the PMIP home address and prefix that the network assigns to the mobile node is addressed to a particular home agent, the mobile node address prefix may be included in the home agent discovery message by the mobile node 200 and at the time of initial connection. Another local piece of information that may help the network identify the home agent of the mobile node (eg PDN-GW in a 3GPP SAE network). Proxy Mobile IP was based on the tunnel interface of Mobile Node 200 with its own PMIP proxy (eg 3GPP). If the ePDG in the SAE network has served the mobile node 200 as a PMIP proxy, the mobile node is also assigned as location information to the mobile node by the tunnel end point IP address (eg ePDG IP address or ePDG). You may also signal information about the end of the tunnel, such as a remote address).

In general, home agent discovery messages have the following parameters: a mobile node identifier that allows the network to identify the mobile node (eg NAI or pseudo-NAI), a session identifier that identifies the session (PMIP home address), and Optionally include one or more of the flags that a home agent / local mobility anchor is required to continue an existing session. It should be noted that in practical implementations of mobile IP, MIP is often used to connect with AAA. Therefore, not only are binding cache entries within each home agent typically identified by their respective home address on each mobile node, but NAI is also used additionally to systematize and retrieve bindings.

In the example of moving from a proxy MIPv6 domain to a client MIPv6 network area, the mobile node 200 may signal a NAI or pseudo-NAI that identifies the mobile node (this identifier is the awareness address in the registration binding cache by the home agent). Because it may be assumed that it is used to retain and identify). Therefore, if the home agent does not hold a binding cache entry for the indicated mobile node identifier, then the home agent is not serving (previously not serving) mobile node 200. , Identifying clues to a home agent or serving home agent serving mobile node 200 (step 304).

In the example shown in Figure 3, the home agent discovery message is routed to home agent 208 in core network area number 2 (see Figure 2). For illustrative purposes, it is further envisioned that the home agent 208 can identify the correct home agent address (ie, the home agent 204 address) that has served the mobile node 200 before changing the mobility management scheme. Therefore, the home agent 208 includes the redirect information option in the response message sent to the mobile node 200 in response to the home agent discovery message (step 305). This redirect information includes the (unicast) address of home agent 204.

The home agent discovery response from the home agent 208 notifies the mobile node 200 that the home agent 208 is not a home agent being served. The mobile node 200 detects the redirect information option in the response message and identifies the information in it as a unicast address (step 306). Therefore, the mobile node 200 generates another home agent discovery message, and the address indicated in the home agent discovery response message received from the home agent 208 (step 305) is the address of the new home agent discovery message. It is used as a destination to send the home agent discovery message to the home agent 204 (step 307).

The content of this new home agent discovery message may be similar to the content sent to home agent 208 (step 303). Receiving the home agent discovery message (step 307) Since the home agent 204 is a serving home agent, the home agent 204 is another home agent indicating that it is a home agent on which the mobile node 200 is registered. Respond with a discovery message (step 308). Immediately after receiving the response, the mobile node 200 sends a binding update to the home agent 204 (step 309) and registers a new (noticeable) address with the home agent 204 that is updating the binding for that mobile node. , And confirm receipt of the updated binding (step 310). Immediately after updating the mobile node binding, the home agent 204 and mobile node 200 can continue the session and may exchange session data (step 311).

In another embodiment of the invention, the procedure of FIG. 3 may be further optimized. For example, if all the information needed to send a binding update is available to the mobile node 200, for example, all security related parameters that should be included during the binding update are to the mobile node 200. Available to and / or the mobile node 200 is confident that the address pointed to during the response from the home agent 208 is correct (eg, by each flag being set during the response). If so, steps 306 and 307 may be omitted, and mobile node 200 sends a binding update to home agent 204 immediately after receiving a home agent discovery response with redirect information from home agent 208. May be sent (step 308). In this exemplary embodiment, the mobile node 200 may trust that the redirect information in the home agent discovery response is correct so that the redirect information points to a unicast address or in any other way. If uniquely identifying the correct home agent, mobile node 200 may assume that the redirect information identifies the correct serving home agent 204 (or this information may be indicated in the response by a flag). ), As a result, none of the home agent discovery messages need to be sent to the home agent 204. Similarly, along with clues that help identify the correct home agent, even if the redirect information does not point to a specific address (eg, the prefix of core network area number 1 in the example discussed with respect to Figure 3). Further, even if it is assumed that the mobile node 200 may uniquely identify the serving home agent using the redirect information (for example, there is only one home agent with this prefix).

In general, in some embodiments, home agent discovery messages and responses need to be registered with their serving home agent to ensure that the mobile node changes its mobility management scheme or session continuity. It should be noted that this may be achieved by extending existing signaling messages during the procedure that takes place immediately after configuring the address. To minimize registration delays, the response, including the location of the mobile node and clues to the home agent serving the mobile node, causes the mobile node to change its mobility management regimen or session continuity. It may be provided in the first signaling message of each step that takes place immediately after configuring a new address that needs to be registered with its serving home agent to ensure. This aspect will be schematically illustrated below with reference to FIG.

4 discovers the home agent serving mobile node, establishing an IPsec security association with the serving home agent, and the binding A subsequent it possible to Ppudeto transmitting to the serving home agent, the A modified IKEv2 signaling procedure according to an exemplary embodiment of the invention is shown. The signaling procedure is essentially defined in the IETF RFC 4306 and corresponds to a signaling procedure that considers the alternative configurations suggested in the IETF RFC3776 and IETF RFC4877 previously described herein. Therefore, the following description focuses on the changes applied by this procedure by this exemplary embodiment.

For illustrative purposes, situations that are substantially similar to those outlined with respect to FIG. 3 may be assumed. Since the mobile node 200 uses the proxy MIPv6 in the PMIP domain of the network, it can be assumed that the mobile node 200 changes its own mobility management method (migration from PMIP to CMIP) to the client MIPv6 service area of the network. The mobile node 200 sets a new IP address (notice address) based on the prefix notified during the new network area where the client MIPv6 is used, and, for example, the pre-defined URI of the home agent in the network. You may ask the DNS server to get an IP address for it (for example, there may be a DNS input for "homeagents.example.com" in the DNS recording). The DNS server returns the anycast address (ANYCAST) of the anycast group to which the home agent in the network belongs. Alternatively, the anycast address may be known to the mobile node 200, or the pre-notified in the client MIPv6 network area (eg, during the DHCP option for the local home agent address or prefix). It may be configured based on a fix, so that no DNS request is required in this case.

As directed above, if a non-serving home agent receives a home agent discovery message, it is desirable to redirect the mobile node 200 as soon as possible during the IKEv2 signaling procedure. The earliest point in time containing location information is likely to be the first message in the security association configuration, which is the IKE_SA_INIT request message when using the IKEv2 signaling procedure. Therefore, in this exemplary embodiment, the IKE_SA_INIT request of the IKEv2 signaling procedure is extended to include the location information of the mobile node and therefore represents an exemplary implementation of the home agent discovery message.

Location information may be included, for example, in the options newly defined in this signaling message. This is illustrated in FIG. 4 in the form of an option "initial connection info" that includes location information (eg, the MAG IP address of the mobile node 200 serving MAG in the PMIP domain). In addition, the IKE_SA_INIT request of the IKEv2 signaling procedure may be extended to include an option to signal the mobile node identifier. This is indicated in FIG. 4 by, for example, an IKE_SA_INIT request containing a parameter ID that can be a mobile node NAI or pseudo NAI.

This IKE_SA_INIT request is sent using the anycast address (anycast) as the destination address and the (notice) address of the newly configured mobile node as the source address. This means that in Figure 4, an IKE_SA_INIT request is sent from the source address on port 500 corresponding to the newly configured awareness address CoA to the destination ANYCAST for port 500 [CoA: 500 ANYCAST: 500]. Illustrated by. A similar notation is used for the remaining signaling messages shown in Figure 4.

The IKE_SA_INIT request was received by the home agent 208, which itself could not process the message and identify the binding cache entry for the mobile node's NAI in the IKE_SA_INIT request, so it owns the mobile node 200. Recognize that you are not serving. Therefore, the home agent 208 attempts to identify the home agent serving the mobile node 200, using location information and optionally additional knowledge of network topology, domain prefixes, etc., and into the PMIP domain of the network. Identifies the home agent address HA_ADDRESS of the potential home agent that the mobile node first registered when connecting.

Home agent 208 responds to the IKE_SA_INIT request with an extended IKE_SAJNIT response. This IKE_SA_INIT response includes a redirect option that handles the IKE_SA_INIT request and contains clues to the correct home agent (or its own address) identified by the home agent when it detects that it is not the serving home agent of the mobile node. Therefore, the home agent 208 includes the determined home agent address HA_ADDRESS in the IKE_SA_INIT response and sends the response message to the mobile node 200.

The mobile node 200 that receives the IKE_SA_INIT response recognizes that the home agent 208 that sends this response is not the home agent for which the mobile node 200 is registered based on the included redirect information. Therefore, the mobile node 200 interrupts the IKEv2 signaling procedure and makes an IKE_SA_INIT request from the destination indicated by the IKE-SA_INIT response from the home agent 208 (address HA_ADDRESS in this example), or the mobile node from the home agent 208. A new IKEv2 signaling procedure may be initiated that points to an address that can be derived from the redirect information (clues) in the IKE_SA_INIT response (this behavior may be referred to as the mobile node restarting the IKEv2 signaling procedure).

The new home agent that receives the IKE_SA_INIT request notices that it is serving the mobile node (based on NAI) and responds with a normal IKE_SAJNIT response without redirect information. The mobile node then continues normal IKEv2 signaling and sends an IKE AUTH message to authenticate itself and set up an IPSec security association.

Immediately after receiving the IKE_AUTH response message from the home agent 204, the mobile node 200 establishes an IPsec security association with the home agent 204 and therefore a MIPv6 binding to register the new awareness address CoA with its serving home agent 204. Owns all relevant security parameters for generating and sending updates. Immediately after updating the binding, the home agent 204 sends a confirmation of receipt of the MIPv6 binding to the mobile node 200.

In the exemplary embodiment described with reference to FIGS. 3 and 4 above, the home agent receiving the home agent discovery message identifies the mobile node (especially based on location information) and registers itself. It has been assumed that it has the ability to notify mobile nodes about home agents that are being used. However, this is not always the case. For example, if a mobile node sends a home agent discovery message to an anycast group of which the correct home agent is a member, it is possible that the wrong home agent in this group will receive and reject the message. .. In this case, the mobile node either attempts to send the message again with a home agent discovery message with the same anycast group, or the message concerned, until it expects the message to be routed to the correct home agent. The wrong home agent can give more precise clues (eg, the correct home agent unicast address, or another anycast address that points to a different anycast group). Reporting a unicast address is possible, for example, if all home agents in one anycast group know the binding caches of all other home agents that are members of the same anycast group. is there.

This scenario is illustrated below in more detail and exemplary with respect to FIG. FIG. 5 discovers a mobile node 200 serving a home agent according to an exemplary embodiment of the present invention, registers the mobile node 200 with the discovered serving home agent 204, and sends a first home agent discovery message. The receiving home agent shows an exemplary signaling flow that does not have to identify the home agent serving the mobile node.

In essence, steps 501, 502 and 503 correspond to steps 301, 302 and 303 in FIG. Therefore, the description in FIG. 3 above is referred to for these three steps.

Home agent 208 processes a home agent discovery message that is essentially similar to step 304 in FIG. However, this time, the location information (and other available information) in the home agent discovery message is not sufficient to uniquely identify the mobile node 200 served by the home agent in the home agent 208. However, the information available to Home Agent 208 may not be sufficient to indicate, for example, the IP address prefix of region number 1, or anycast or multicast address, or DNS name to mobile node 200. Therefore, the home agent 208 may indicate that it is not the home agent on which the mobile node 200 is registered during the home agent discovery response sent to the mobile node 200 (step 505), and the home. Agent 208 may additionally include the IP anycast address or multicast address, or the DNS name of the address prefix or core network area number 1 in the response message.

The response notifies the mobile node 200 that the home agent 208 is not the home agent for which the mobile node 200 was registered in the PMIP domain. The mobile node 200 further uses the anycast address or address prefix of the core network area number 1 or the redirect information indicating the DNS name to determine the anycast address based on the address prefix (step 506). For example, each home agent in a core network area may all belong to an anycast group whose anycast address can be determined from the address prefix notified in the network area according to pre-determined rules. As a result, the mobile node 200 can derive the correct anycast address from the address prefix provided in the home agent discovery response message. Alternatively, the redirect information may include a DNS name that the mobile node 200 resolves using a DNS service.

Immediately after determining the anycast address of the home agent in the PMIP domain, the mobile node 200 sends a home agent discovery message to this determined anycast address (step 507). The home agent discovery message is similar to the home agent discovery message in step 503, except that it is addressed to the determined anycast address.

In this example, the anycast address determined by the mobile node 200 is the group address of the home agents 204, 205, 206 within the core network area number 1 shown in FIG. The home agent discovery message can be assumed to be routed to the anycast group's home agent 205, however, that home agent 205 is not the home agent on which the mobile node 200 is registered. In this example, it can be assumed that each home agent in one anycast group knows the bindings held by other group members, so that the home agent 205 discovers the mobile node and / or home agent. The session identifier indicated in the message can be used to identify the correct home agent for the anycast group in which the mobile node 200 is registered (step 508). Therefore, the home agent 205 indicates that the home agent 205 is not the home agent serving the mobile node 200, and the home agent 204 has the IP address of the home agent 204 (in the redirect option of the home agent discovery response message). Respond to the home agent discovery message by sending a home agent discovery response containing (HA address) (step 509).

Upon receiving the response message, Mobile Node 200 may now send yet another home agent discovery message to the correct home agent 204 (step 510), and receives an acknowledgment from the home agent (step 511). Immediately after that, the mobile node 200 registers its new awareness address with the home agent 204 (steps 512, 513) and continues the session (step 514). In some scenarios, steps 510 to 514 correspond to steps 306 to 310 in FIG. Step 510 and step 511 may be optional as described for step 308 and step 309 above. As mentioned earlier, multicast or unicast addresses can likewise be used in place of anycast addresses.

In general, a mobile node sends a new home agent discovery message to a destination directed by a past home agent discovery response message or derived from a home agent discovery response message until it finds the home agent it was registered with. It should be noted that you may continue to do so. However, there are termination conditions, and as a result, it seems desirable to never discover your own serving home agent. Therefore, in another embodiment of the invention, different termination conditions may be defined.

For example, if the home agent clues contained in the home agent discovery response continue to be incorrect and the mobile node sends a home agent discovery message to the incorrect anycast group, the mobile node will send this incorrect anycast group. There must be some mechanism to prevent a permanent search within. One option is if the mobile node simply limits the number of trials (eg 5) and does not find the correct home agent inside of these trials, then the mobile node has the following higher range: Switch to an anycast group with (eg, a global anycast address that includes all home agents in an anycast group that includes a larger core network area or the entire core network, as well as home agents in subregions within the core network) .. Another option is for the mobile node to trigger when it notices that the same false home agent responds to the home agent discovery request a predetermined number of times.

A further option to prevent multiple hits of the same false home agent is for the false home agent receiving the discovery message to unconfigure the anycast address and leave the anycast group. However, this typically requires a unique home agent anycast address for each mobile node, and as a result, the home agent discovery process for other mobile nodes is unaffected.

In addition, another termination condition may be required if the home agent discovery response may not give a more rigorous clue to the correct home agent. For example, different but non-serving home agents continue to respond to home agent discovery messages, but their clues may be repetitive or incorrect, resulting in further mobile node cues. Sending another home agent discovery message may not make any progress in discovering the home agent serving the mobile node. Therefore, if the mobile node repeatedly receives, for example, the same clue (eg, the same but incorrect unicast IP address), the mobile node may interrupt the discovery procedure.

The different options discussed above may also be used together to avoid excessive time-consuming home agent discovery or trapping of mobile nodes in a loop.

Of course, the IKEv2 signaling procedure for establishing an IPsec security association is not the only signaling procedure in which the principles and ideas of the present invention can be implemented. Another option according to another embodiment of the invention is to use the principles and ideas in dynamic home agent address discovery (DHAAD) known in IETF RFC 3775. In this exemplary embodiment, the DHAAD request message may be extended, for example, by including location information and optionally a mobile node identifier.

FIG. 6 shows an exemplary signaling flow of a modified dynamic home agent discovery procedure according to an exemplary embodiment of the invention. Similar to steps 301, 302 and 501, 502 of FIGS. 3 and 5, mobile node 200 may have in-progress sessions and exchange session data with its own home agent 204 (step 601). , The mobility management method may be changed (step 602). The mobile node 200 may then configure a new awareness address (not shown) and obtain an anycast address (anycast) that may have been assigned to each home agent in the core network (step). 603). This may be achieved, for example, by querying the DNS server for an IP address within the home agent's network (eg, querying a preconfigured DNS name such as "homeagents.example.com"). Alternatively, this anycast address may be known to the mobile node 200, or may be derived from a network prefix notified within the access network to which the mobile node 200 is connected.

Immediately after acquiring the anycast address (step 603), the mobile node 200 sends a DHAAD request addressed to the anycast address (step 604). The DHAAD request is extended by including the location information of the mobile node 200 previously described herein, and may further optionally include an identifier of the mobile node 200, such as NAI or pseudo-NAI.

Considering the example scenario in Figure 2, the mobile node may have moved to the network area where the access router AR207 is serving the access network and the client MIPv6 is used for mobility management. Therefore, the routing protocol may route the DHAAD request to the nearest home agent, and in this example it is assumed that the home agent is the home agent 208. Home agent 208 determines that it is not serving the mobile node it is querying (for example, by not being able to find a binding cache entry for mobile node 200) and is therefore requesting DHAAD. Attempts are made to at least determine clues to the home agent serving mobile node 200 based on location information and any other information available to home agent 208 (step 605). Each home agent in the anycast group knows the binding to each other, or the home agent 208 concludes from the location information which home agent served the mobile node 200 before changing the mobility management scheme. Assuming that it is possible, the home agent 208 indicates that it is not serving the mobile node 200 and to the correct home agent (eg, the unicast, multicast or anycast address of the home agent 204 in the redirect information option or Respond to the DHAAD request by sending a DHAAD response containing clues (indicating its own DNS name) (step 606).

Immediately after receiving the response, the mobile node 200 receives a DHAAD response from the home agent 208 that the home agent 204 indicated as the serving home agent during the DHAAD response is exactly the home agent on which the mobile node 200 was registered. It may be optionally confirmed by sending another DHAAD request with its location information and its own identifier to the address indicated in (step 607). Therefore, the home agent 204 will receive the DHAAD request and respond to the DHAAD request indicating that it is exactly the home agent serving the mobile node 200 (step 608).

The mobile node 200 uses, for example, the binding update procedure specified in IETF RFC 3775 (including, for example, establishing an IPsec security association with the home agent 204 using the IKEv2 signaling procedure) to transfer its awareness address to the home agent 204. Registration (step 609) may be further advanced. Immediately after updating the binding on the home agent 204, mobile node 200 may continue the session (step 610).

In this exemplary embodiment described above with respect to the DHAAD procedure, the DHAAD request is considered a home agent discovery message and the DHAAD response is considered a response to it. Therefore, the term "home agent discovery server" in this exemplary embodiment refers to a home agent that receives a first DHAAD request.

In another embodiment of the invention, the principles and ideas of the invention apply to binding update procedures using authentication options of authentication protocols known from IETF RFC 4285 previously described herein. This example is outlined with reference to FIG. 7, which shows an extended binding update procedure with the authentication option according to this exemplary embodiment of the invention.

Again, assume that mobile node 200 has an ongoing session (step 701) and that mobile node 200 changes its mobility management protocol from proxy MIPv6 to (client) MIPv6 (step 702). Immediately after configuring the new awareness address (CoA), the mobile node 200 sends a binding update (BU) message with authentication options to the anycast address of the home agent in the core network (step 703). This binding update is extended by additional options including the location information of the mobile node 200 and optionally the identifier of the mobile node 200, as previously described herein. Binding updates are routed to home agent 208 in core network area number 2 (see Figure 2). The home agent 208 recognizes that the mobile node 200 is not registered with the home agent, and serves the mobile node 200 by using the location information during the binding update as described above in the present specification. Attempts to identify the home agent (step 704). The home agent 208 responds to the binding update by sending a binding receipt confirmation message to the mobile node 200 (step 705) indicating that the binding has not been updated. Further, the home agent 208 includes the IP address of the home agent 204 or its DNS name, or redirect information indicating information for the mobile node to derive them in the binding reception confirmation, and the home agent 204 is mobile. Identified by home agent 208 as the home agent serving node 200.

The mobile node 200 receives a binding receipt containing redirect information with the address of the home agent 204, followed by a new binding update to the address indicated during the binding receipt received from the home agent 208. Send (step 706).

The mobile node 200 has received the unicast address of the home agent whose binding reception is being confirmed, or can already acquire the unicast address of its own serving home agent based on the redirect information contained in the binding reception confirmation. If so, this new binding update may be a state-of-the-art binding update that includes authentication options with that authentication protocol. This behavior may be used, for example, when the mobile node 200 is confident that the home agent address identifies the correct home agent serving the mobile node 200. If the mobile node is not sure that the new binding update will be routed to its serving home agent (eg group address is returned during binding receipt confirmation), mobile node 200 will be like step 703. May send a binding update containing the location information of the mobile node 200 and optionally an identifier.

Assuming that the home agent 204 is the home agent on which the mobile node 200 is registered, the home agent 204 processes the binding update specified in IETF RFC4285 and authenticates the binding update of the mobile node 200 with the AAA server. Will (steps 707, 708). If this authentication is successful, the home agent 204 registers a new awareness address for mobile node 200 in its binding cache and sends a binding receipt confirmation (BAck) to mobile node 200 (step 709) to bind. Check for updates. Therefore, the mobile node 200 may continue to exchange session data 710 for sessions initiated before changing the mobility management scheme.

Another possibility with other embodiments of the invention is to extend the DCHP protocol procedure. FIG. 8 shows exemplary DHCP signaling for discovering a home agent serving mobile node 200, according to an exemplary embodiment of the invention. Similar to the previous embodiments described so far, mobile node 200 has an ongoing session (step 801) and changes its mobility management protocol from proxy MIPv6 to (client) MIPv6 (step 802). ) Is assumed for exemplification purposes. The mobile node 200 configures a new awareness address (CoA) immediately after changing the mobility management method. The mobile node 200 sends a DHCP information request message containing the identifier of its operator's home network (typically preconfigured within the mobile node) to contact the home agent serving the mobile node. (Step 803). Droms et al.'Dynamic Host Configuration Protocol for IPv6, both available from http://www.ietf.org and incorporated herein by reference, in each of the traditional parameters in the DHCP information request message. (DHCPv6) , IETF RFC3315, July 2003, and Hee Jin Jang et al., DHCP Options for Home Information Discovery in MIPv6 , IETF Internet Draft, draft-ietf-mip6-hiopt-10. In addition to txt, see January 2008), Mobile Node 200 allows the receiving DHCP server (NAS relay) to potentially identify its serving home agent based on location information. To do this, include your location and optionally one of your identifiers in the message. The DHCP information request message may be addressed to the DHCP multicast address (DHCP_MULTICAST). The DHCP server that receives the request attempts to identify the home agent serving mobile node 200 based on its location and mobile node identifier (step 804). Assuming that the DHCP server can identify the home agent on which the mobile node 200 is registered, the DHCP server includes the home agent information option including the home agent address in the response message (DHCP information response). Send the response message to mobile node 200 (step 805).

Immediately after receiving the response, the mobile node 200 uses the binding update procedure specified in IETF RFC 3775 (including, for example, using the IKEv2 signaling procedure, for example, to establish an IPsec security association with the home agent 204). You may proceed further by registering your own noticed address with the home agent 204 whose address is shown in the DHCP response (step 806). Immediately after updating the binding on the home agent 204, mobile node 200 may continue the session (step 807).

In this exemplary embodiment, the DHCP server (NAS relay) may be considered a home agent discovery server, and the terms "home agent discovery message" and "response" are equivalent to the extended DCHP information request and response message. Can be considered to be.

One problem that can occur in the scenarios considered herein is that the network may have relocated the home agent while the mobile node was moving within the proxy mobile IP domain. According to another embodiment of the invention, the mobile node may store additional information about the intermediate (access) network to which the mobile node is connected as it travels. When the mobile node provides these additional information to the network immediately after changing the mobility management method, the mobile node may include the additional information in the location information. For example, a mobile node may infer that a home agent relocation has occurred, and therefore the mobile node travels a given distance (eg, measured from geolocation, visiting access routers, number of cells, etc.). It may store information about the current intermediate network when it does, or when it travels across access networks or management domains.

The "wrong" home agent discovery server that receives the anycast home agent discovery message may, for example, maintain a database for mapping the location indicated by the mobile node to the home agent address. The home agent discovery server then rejects the request and redirects new anycast or unicast addresses or other identifiers, etc. for the area where the correct home agent or the correct home agent discussed above is likely to be located. Clues may be included. The mobile node may send a new home agent discovery message to the indicated address derived from the received clues.

In one exemplary implementation, the concept of deployment may define multiple home agent anycast groups for different domains, services or access technologies. Different groups may have different ranges, and this "wrong" home agent or home agent discovery server is a clue about another anycast group with a smaller or more specific range for the mobile node. Will give. A mobile node could, for example, first connect to a proxy mobile IP network in Shanghai (core network area number 1 in Figure 2) and assign a home agent 204. After moving to Beijing (core network area number 2 in Figure 2), the mobile node initiates home agent discovery and makes an initial connection to the widest range of anycast addresses (eg, globally valid anycast addresses). Send an IKE message with information about the point. The home agent 208 receives this message and the mobile node receives a more specific anycast group, for example, the anycast address of the anycast group of the Shanghai home agent (ie, the home agent in core network area number 1 in Figure 2). Respond with clues derived from the mobile node's local information that it should be tried. The mobile node finally sends an IKE message to the anycast address of the home agent in Shanghai and finds the correct home agent (home agent 204) in this group.

In another embodiment of the invention, the mobile node provides feedback on the clues to the wrong home agent. For example, if a mobile node tells a home agent that is not serving the mobile node that the previous clues were useful in finding the correct home agent, the home agent that is not serving the mobile node will For example, it stores this information in its own database (ie, the correct home agent address mapping and the reported location of the mobile node's former connection), as well as future clues to other mobile nodes by this home agent. You may improve your own process of providing clues for greater precision.

Another issue that may need to be considered in system design may be security. In some embodiments of the invention, the home agent discovery message includes a mobile node identifier, so that the recipient of the message receives the binding cache entry of the mobile node and the home agent on which this mobile node is registered. Can be identified. However, it may be desirable for an out-of-route attacker to simply send a home agent discovery message containing the identifier of another mobile node so that the mobile node cannot discover the currently registered home agent. The reason is that otherwise an attacker could launch a targeted attack on the home agent of a particular mobile node.

In one exemplary embodiment of the invention, the mobile node uses a temporary or pseudo-identifier during home agent discovery, and mapping of that identifier to the actual mobile node's identity is only for the mobile node and network. Known (not known to attackers). This pseudo-identifier can be negotiated between the network and the mobile node prior to the transition to (client) mobile IP, for example during initial connection or past authentication. In each IP network, the pseudo-NAI is a common temporary identifier for privacy protection, which is typically negotiated between the network and the mobile node during network authentication. Therefore, the mobile node may use this identifier, for example, for inclusion in the home agent discovery message. The alternative temporary or pseudo-identifier may be the TMSI of the mobile node, which is also a negotiated temporary pseudo-identifier used within the GSM / UMTS / LTE communication network.

According to one exemplary embodiment, both the network and the mobile node can generate a pseudo NAI from the TMSI that is negotiated between the network and the mobile node within 3GPP access. For example, a pseudo NAI can be constructed from TMSI in the username part and a domain from the domain part (eg, "TMSI@example.com"). If a mobile node is moving from a 3GPP network to a non-3GPP network, the mobile node may use pseudo-NAI without any additional signaling or delay resulting from pseudo-NAI negotiation. Since the mobile node's TMSI is typically stored in a 3GPP network migration management entity (MME), the mobility management entity transfers the TMSI assigned to the mobile node to the home agent prior to the handover. You may. This transfer may be achieved directly, for example, between the mobility management entity and the home agent via the AAA / HSS server, for example during network authentication.

According to another embodiment of the invention, another strategy against the threat of finding a home agent on any mobile node is to dynamically configure an anycast address on the home agent. For example, if every mobile node is assigned a unique home agent discovery anycast address, and this address is configured on the home agent only during the time the mobile node moves from the proxy MIP to the (client) MIP. It is generally not possible for an attacker to identify the home agent of a mobile node. This is only possible during the time the mobile node makes the transition from the proxy MIP to the (client) MIP, which is generally difficult to find by off-route attackers.

In some of the embodiments of the invention described above, a home agent that has received a home agent discovery message but has not served a mobile node typically responds with a home agent discovery response that includes redirect information. , And the mobile node responds by sending another home agent discovery message. In another embodiment, instead of rejecting the home agent discovery request message from the "wrong" home agent and sending a clue to the mobile node containing the correct home agent address or area, it serves the mobile node. No home agent may forward the home agent discovery message to the correct home agent address or region, and then the home agent receiving the forwarded message may have the home agent serving a mobile node. May respond to the mobile node, or may forward the home agent discovery message again.

In one variant of this embodiment, the home agent discovery message may include a counter option to count the number of times the message has been transferred so that the home agent discovery message is not forwarded between home agents without a response to the mobile node. Good. When the counter exceeds the threshold (or decrements the counter by 1 to reach zero), the home agent receiving the home agent discovery message includes a redirect option if the home agent is not serving the mobile node. Respond to the mobile node by sending a home agent discovery response message. The mobile node may then either interrupt the home agent discovery or resend another home agent discovery message (including location information) based on redirect cues in the response message.

In addition, although most of the previous embodiments discussed with respect to Figures 2-8 envisioned a mobility management change from proxy MIP to client MIP, this also applies to handover from (client) MIP to proxy MIP. It should be noted that it is also possible to use the invention as well. In this case, the mobile access gateway (which acts as a proxy for the mobile node) may need to find a home agent that the mobile node has previously registered with, and performs a home agent discovery. Maybe. For example, the mobile access gateway may query for information about the location of the mobile node in the past from the mobile node, or such information may be provided, and as previously described herein. A home agent discovery message containing local information may be sent to the network to discover the home agent.

In addition, it should be noted that the anycast group to which each home agent can be assigned can be changed by the operator to match, for example, the size of the network, the number of PDN-GWs or the number of mobile nodes registered in the network. Will be done.

Another aspect of the invention is data path optimization in scenarios where multiple anchors (eg, ePDG and PDN-GW) are used in a single data session. According to another aspect of the invention, a similar approach is used for the home agent discovery discussed above. The idea is to move one of the anchors closer to another anchor.

For example, in 3GPP SAE, UEs (mobile nodes) located in untrusted non-3GPP networks are typically pinned to PDN-GWs (home agents / local mobility anchors) for mobility management. It also maintains a secure tunnel to the ePDG to access the 3GPP network. In addition, if the UE (mobile node) is located in an untrusted network, the data path for session data from the UEE (of the mobile node) to / is through a secure tunnel in the core network. Note that it should be routed to and from this ePDG to the PDN-GW (Home Agent / Local Mobility Anchor) serving the UE (Mobile Node) (through another secure tunnel). Should be. PDN-GW establishes an internet connection for session data.

An example scenario is shown in Fig. 9. The UE (Mobile Node 900) is first connected to a trusted non-3GPP or 3GPP access network (area number 1) connected to the core network and assigned PDN-GW904 (home agent). Both core network area number 1 and core network area number 2 are part of one core network. It can be assumed that the UE (Mobile Node 900) moves to an untrusted non-3GPP network (served by access router 907), which is also connected to the core network (step 908). Since the UE has entered an untrusted non-3GPP network, the UE (Mobile Node 900) typically begins discovering and setting up an IPsec tunnel to the ePDG (here ePDG906) (step 909). .. The UE (Mobile Node 900) includes location information and identifiers for the initial connection location in one of the initial messages sent to the ePDG906 to set up a secure tunnel. For example, as in the example discussed above for Figure 4, the UE (Mobile Node 900) may use the IKEv2 signaling procedure and extend the IKE_SA_INIT message by including its location and its identifier. You may. The ePDG906 may identify the current mobile node PDN-GW (PDN-GW904) based on location information, and data if the UE (Mobile Node 900) uses another ePDG (ePDG905 in this example). Notice that the path will be much shorter. Therefore, the ePDG906 may reject the IKE request (step 910) and send a clue to the UE (Mobile Node 900) to move or redirect the UE (Mobile Node 900) to the ePDG905. The UE (Mobile Node 900) then establishes a secure tunnel with the ePDG905 and ensures a shorter data path.

According to another embodiment as one optimization of the above procedure, the first discovered ePDG (ePDG906) may receive an IKE request, so that the UE (Mobile Node 900) will receive the more optimal ePDG905. This ePDG can be used until a secure tunnel to is established and the UE (Mobile Node 900) is fully relocated to the new ePDG905. Therefore, response 910 to tunnel establishment request 909 may instruct further tunnel establishment, additionally including clues to redirect to ePDG905. This temporary connection to the two ePDGs can minimize the handover delay while ensuring an optimized data path.

Data path optimization is independent of the type of mobility management used before and after the handover and does not need to involve changing the mobility management scheme. However, if the (client) MIP was used before the move (handover), the UE already knew its current PDN-GW address (ie the address of PDN-GW904) and in the IKE_SA_INIT message. It may include the address of PDN-GW.

Alternatively, in another exemplary embodiment, the UE may also discover the ePDG905 by constructing a DNS name based on a known PDN-GW DNS name. For example, if the known PDN-GW name is "PDN-GW1.operator.de", the DNS name for discovering the ePDG address can be "ePDG.PDN-GW1.operator.de".

Another scenario in which a common anchor can be discovered and used using the principles outlined above is that the mobile node has multiple independent attachments, connections or sessions to the network (eg, WLAN HTTP session and LTE VoIP session). It is a situation with. In such a scenario, it may be desirable to use the same anchor for all of these sessions for efficiency reasons. If the mobile node discovers a home agent for an additional connection, the mobile node will find the location information of the mobile node to discover the home agent that the mobile node is using for other connections. And an identifier may be included.

In another scenario, according to another exemplary embodiment of the invention, the UE (Mobile Node) is handing over to a new non-3GPP access network using client-based mobility management, which access network I don't know if it's a trusted non-3GPP network or an untrusted non-3GPP network. Therefore, the UE should either set up an IPsec tunnel to this ePDG and then discover the ePDG to register with PDN-GW through the ePDG tunnel, or the UE should be safe with the ePDG. I don't know if I can register directly with PDN-GW without the need for a tunnel.

In this embodiment, even assuming that the UE is located in an untrusted access network and initiates a secure tunnel with the ePDG (eg IPsec tunnel) by sending a tunnel setup message. Good. This tunnel setup message may be, for example, an IKE_SA_INIT request message for the IKEv2 signaling procedure sent to the ePDG. Again, this tunnel setup message is extended by incorporating location information as previously described herein. The tunnel setup message may use a new awareness address configured as a source address by the UE (Mobile Node) immediately after the handover. The ePDG (for example, based on the source address of the IKE_SA_INIT request message or based on the location information in the message) allows the UE (Mobile Node) to be in a trusted non-3GPP access network or an untrusted non-3GPP access network. You may notice if it is located. Based on this information, the UE either receives the tunnel establishment and proceeds with the tunnel establishment, or sends a response message containing clues (eg, IKE_SA_INIT response message) to the UE as described in various embodiments of the invention. By sending to the PDN-GW address, the tunnel setup request can be rejected and the UE (mobile node) redirects to the PDN-GW serving the UE (mobile node). The redirect information may additionally include information that the redirect destination is a PDN-GW or home agent and not an ePDG, so that the mobile node can behave when connecting to the redirect destination.

Other embodiments of the invention relate to the implementation of the various embodiments described above using hardware and software. It is recognized that various embodiments of the present invention have been implemented or implemented using arithmetic units (processing units). Arithmetic logic units or processing devices are, for example, general purpose processing devices, digital signal processing devices (DSPs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs) or other programmable logic devices. May be good.

Various embodiments of the present invention may also be implemented or embodied by a combination of these devices.

In addition, various embodiments of the invention may also be implemented by a processor or software modules that run directly in hardware. A combination of software modules and hardware implementations would also be possible. The software module may be stored on any kind of computer-readable storage medium, such as RAM, EPROM, FEPROM, flash memory, registers, hard disks, CD-ROMs, DVDs, and the like.

In the previous paragraph, various embodiments and variations of the present invention have been described. As shown in the specific embodiments, a large number of modifications and / or modifications can be made to the invention without departing from the broadly described spirit or scope of the invention. It will be understood by those skilled in the art.

In addition, it should be noted that most of the embodiments are outlined for 3GPP-based communication systems, and that the terminology used in the previous section is primarily for 3GPP and IETF terms. However, the terminology and descriptions of various embodiments relating to IETF-based and 3GPP-based architectures are not intended to limit the principles and ideas of the invention to such systems.

Also, the description given in the section of the art above is intended to better understand the exemplary embodiments specific to the IETF, most of which are described herein. It should not be understood as limiting to a specific implementation of a described process and function in a mobile communications network. Nevertheless, the improvements proposed herein can be easily applied within the architecture described in the technical field section. Moreover, the concepts of the invention can be readily used within the LTE RAN currently discussed by 3GPP.