EP2338264B1 - Optimierung von weiterleitungen an nicht vertrauenswürdige nicht-gpp-netzwerke - Google Patents

Optimierung von weiterleitungen an nicht vertrauenswürdige nicht-gpp-netzwerke Download PDF

Info

Publication number
EP2338264B1
EP2338264B1 EP09778682.6A EP09778682A EP2338264B1 EP 2338264 B1 EP2338264 B1 EP 2338264B1 EP 09778682 A EP09778682 A EP 09778682A EP 2338264 B1 EP2338264 B1 EP 2338264B1
Authority
EP
European Patent Office
Prior art keywords
tentative
mobile node
network
epdg
gateway
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Not-in-force
Application number
EP09778682.6A
Other languages
English (en)
French (fr)
Other versions
EP2338264A1 (de
Inventor
Jens Bachmann
Genadi Velev
Shinkichi Ikeda
Jun Hirano
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Panasonic Intellectual Property Corp of America
Original Assignee
Panasonic Intellectual Property Corp of America
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Panasonic Intellectual Property Corp of America filed Critical Panasonic Intellectual Property Corp of America
Priority to EP09778682.6A priority Critical patent/EP2338264B1/de
Publication of EP2338264A1 publication Critical patent/EP2338264A1/de
Application granted granted Critical
Publication of EP2338264B1 publication Critical patent/EP2338264B1/de
Not-in-force legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/14—Reselecting a network or an air interface
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/164—Implementing security features at a particular protocol layer at the network layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H04W12/088—Access security using filters or firewalls
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0011—Control or signalling for completing the hand-off for data sessions of end-to-end connection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0011—Control or signalling for completing the hand-off for data sessions of end-to-end connection
    • H04W36/0019—Control or signalling for completing the hand-off for data sessions of end-to-end connection adapted for mobile IP [MIP]

Definitions

  • the invention relates to a method for ensuring session continuity upon a handover of a mobile node to a non-3GPP network, when using a security gateway to allow communications between the unsecure non-3GPP network and the secure 3GPP core network.
  • the handover of the mobile node is to be expedited by interactions between the various entities in the forefront of the actual handover.
  • the invention relates to a mobile node, a security gateway and a packet data network gateway that participate in the invention.
  • UMTS Universal Mobile Telecommunications System
  • 3GPP 3 rd Generation Partnership Project
  • the 3GPP launched a study item "Evolved UTRA and UTRAN” better known as “Long Term Evolution (LTE)”.
  • LTE Long Term Evolution
  • the E-UTRAN consists of evolved Node Bs (eNB or eNodeB), providing the E-UTRA user plane (PDCP/RLC/MAC/PHY) and control plane (RRC) protocol terminations towards the mobile node.
  • eNB evolved Node Bs
  • RRC control plane
  • the eNB hosts the Physical (PHY), Medium Access Control (MAC), Radio Link Control (RLC), and Packet Data Control Protocol (PDCP) layers that include the functionality of user-plane header-compression and encryption. It also offers Radio Resource Control (RRC) functionality corresponding to the control plane. Further, it performs many functions including radio resource management, admission control, scheduling, enforcement of negotiated UL-QoS (Quality of Service), cell information broadcast, ciphering/deciphering of user and control plane data, and compression/decompression of DL/UL user plane packet headers.
  • RRC Radio Resource Control
  • the eNBs are also connected by means of the S1 interface to the EPC (Evolved Packet Core), more specifically to the MME (Mobility Management Entity) by means of the S1-MME, and to the Serving Gateway (S-GW) by means of the S1-U.
  • EPC Evolved Packet Core
  • MME Mobility Management Entity
  • S-GW Serving Gateway
  • the S-GW routes and forwards user data packets, while also acting as the mobility anchor for the user plane during inter-eNB handovers and as the anchor for mobility between LTE and other 3GPP technologies (terminating S4 interface and relaying the traffic between 2G/3G systems and Packet Data Network Gateway).
  • the S-GW terminates the DL data path and triggers paging when DL data arrives for the UE. It manages and stores UE contexts, e.g. parameters of the IP bearer service, network internal routing information. It also performs replication of the user traffic in case of lawful interception.
  • the MME is the key control-node for the LTE access-network. It is responsible for idle mode UE tracking and paging procedure including retransmissions. It is involved in the bearer activation/deactivation process and is also responsible for choosing the S-GW for a UE at the initial attach and at time of intra-LTE handover involving Core Network (CN) node relocation. It is responsible for authenticating the user (by interacting with the Home Subscriber Server, HSS). It checks the authorization of the UE to camp on the service provider's Public Land Mobile Network (PLMN) and enforces UE roaming restrictions.
  • PLMN Public Land Mobile Network
  • the MME is the termination point in the network for ciphering/integrity protection for NAS signaling and handles the security key management.
  • the MME also provides the control plane function for mobility between LTE and 2G/3G access networks with the S3 interface terminating at the MME from the SGSN (Serving GPRS Support Node).
  • the MME also terminates the S6a interface towards the home HSS for roaming UEs.
  • the Packet Data Network Gateway provides connectivity for the UE to external packet data networks by being the point of exit and entry of traffic for the UE.
  • a UE may have simultaneous connectivity with more than one PDN-GW for accessing multiple PDNs.
  • the PDN-GW performs policy enforcement, packet filtering for each user, charging support, lawful Interception and packet screening.
  • Another key role of the PDN-GW is to act as the anchor for mobility between 3GPP and non-3GPP technologies.
  • the new 3GPP Core Network is mainly separated into three logical entities.
  • the PDN-GW is the gateway to the external networks and the global mobility anchor for mobility between 3GPP and non-3GPP access technologies (likeCDMA2000, WiMAX or WIFI).
  • the Serving Gateway is the mobility anchor for mobility between 3GPP accesses (E-UTRAN, UTRAN, GERAN).
  • a Mobility Management Entity is the control plane entity responsible for the mobility management of mobile terminals (also referred to in the following as UEs or MNs) moving between different EUTRAN base stations (eNodeBs) and also responsible for the session management.
  • the MME is responsible for mobility management and session management.
  • specific mobility management and evolved packet system context information is stored in the MME.
  • These contexts comprise, e.g. the mobility state, the temporary identity, the current Tracking Area List, last known cell, authentication vectors, access restrictions, subscribed QoS profile, subscribed charging characteristics, and for each active PDN connection the APN (Access Point Name) in use, IPv4/IPv6 addresses, PDN-GW address for control plane, and also information for each EPS (Evolved Packet System) bearer within the PDN connection, as for example EPS bearer QoS profile, EPS bearer charging characteristics.
  • EPS Evolved Packet System
  • the mobility management within the 3GPP system is network controlled, and two protocol variants are standardised for the interface between the PDN-GW and the S-GW.
  • One is based on GTP (GPRS Tunneling Protocol), the protocol used in the legacy GPRS (General Packet Radio Service) system, and the other one is Proxy Mobile IPv6 (PMIPv6), developed in the IETF (Internet Engineering Task Force).
  • PMIPv6 Proxy Mobile IPv6
  • the mobile terminal can be connected to the Core Network, i.e. the PDN-GW, via PMIPv6 as well, in case the non-3GPP access supports PMIPv6.
  • the mobile terminal can be connected to the Core Network via Client Mobile IP versions, i.e. Mobile IPv4 Foreign Agent Mode (MIP4FA) or Dual Stack Mobile IPv6 (DSMIPv6).
  • Client Mobile IP versions i.e. Mobile IPv4 Foreign Agent Mode (MIP4FA) or Dual Stack Mobile IPv6 (DSMIPv6).
  • MIP4FA Mobile IPv4 Foreign Agent Mode
  • DSMIPv6 Dual Stack Mobile IPv6
  • EAP-AKA Extensible Authentication Protocol-Authentication and Key Agreement
  • IP address used to route packets to the mobile terminal in the non-3GPP access.
  • This IP address is the Care-of Address in the terminology of Mobile IP.
  • DSMIPv6 the address is assigned to the mobile terminal, and the mobile terminal is sending Binding Updates using its Care-of address to the PDN-GW, which has the function of the Home Agent (HA).
  • HA Home Agent
  • the Care-of address is an address of a Mobile Access Gateway (MAG) that is located in the non-3GPP access network, and the MAG is sending Proxy Binding Updates using its (Proxy-) Care-of Address to the PDN-GW of the 3GPP network, which has the function of the Local Mobility Anchor (LMA).
  • MAG Mobile Access Gateway
  • LMA Local Mobility Anchor
  • non-3GPP accesses two different types, i.e. untrusted non-3GPP access and trusted non-3GPP access, and whether a non-3GPP access is trusted or not is left to the 3GPP operator.
  • a non-3GPP access may be a trusted access for one UE from an operator A and an untrusted access for another UE from operator A.
  • the UE When the UE moves into or attaches initially in an untrusted non-3GPP access ( Figure 2 ), it has to discover an ePDG first, establish an IPsec Key Exchange IKEv2/IPsec tunnel with the ePDG and can connect to the Evolved Packet Core EPC (PDN GW) over the ePDG IPsec tunnel between PDN-GW and ePDG.
  • PDN GW Evolved Packet Core EPC
  • the UE when the UE moves into or attaches initially in a trusted non-3GPP access (see Figure 3 ), it can connect directly to the EPC (PDN GW) via an MIP tunnel.
  • the UE When a UE performs a handover to an untrusted non-3GPP access network, the UE must first discover an ePDG and then establish a secure tunnel to said ePDG, before the UE can send and receive user data.
  • the discovery of the ePDG and the establishment of the secure tunnel takes time, and thus the handover to the untrusted non-3GPP network access is further delayed. This may entail various disadvantages such as data loss, degradation of communication quality and speech interruptions.
  • one object of the invention is to provide an improved method for ensuring IP session continuity upon a handover of a mobile node to an untrusted non-3GPP network.
  • the possible handover to an untrusted non-3GPP network is prepared in advance as far as possible.
  • a mobile node which is currently located in a 3GPP or non-3GPP network access eventually needs to hand-off to another network access.
  • various different access networks may be available for hand-off, wherein the mobile node decides for one of the access networks during the actual handover.
  • ePDG as security gateway
  • the two tunnels are established, however maintained deactivated until their use is actually needed.
  • tentative tunnels are created for the mobile node beforehand, which are only activated when the handover is actually due.
  • the necessary tunnels for providing data between the UE in the future non-3GPP network and the other mobile node are to be prepared in advance, so that when actually handing over to the non-3GPP network, the IP session may be continued without any significant interruption by only activating the already established tunnels.
  • the security tunnel and IP tunnel are created for each and every possible ePDG. Later on, when one of same is selected by the mobile node for handover, the tentative tunnels created for the remaining non-selected ePDGs may be discarded or maintained for future use.
  • the invention provides a method for ensuring IP session continuity upon a handover of a mobile node from a source network to a non-3GPP network.
  • the mobile node is first located in the source network and has an ongoing IP session via a packet data network gateway in the source network. Then, while the mobile node is attached to the source network, a tentative security association is established between the mobile node and a security gateway, wherein the security gateway provides for the source network a secure communication intermediary to the non-3GPP network.
  • the tentative security association between the mobile node and the security gateway is updated by using the mobile node's local address in the non-3GPP network, for establishing a secure tunnel between the mobile node and the security gateway.
  • a tentative tunnel between the security gateway and the packet data network gateway is established.
  • the tentative tunnel between the packet data network gateway and the security gateway is activated.
  • the security gateway is informed about the IP address of the mobile node, which is to be used for the establishment of the security association. This may be done implicitly or explicitly.
  • the tentative security association is established between the security gateway and the mobile node using an address of the mobile node allocated when in the source network.
  • the tentative security association is established by exchanging the address of the mobile node allocated when in the source network with a local address of the mobile node in the non-3GPP network.
  • the step of establishing the tentative security association comprises detecting by the security gateway that the tentative security association is tentative based on an indication provided by the mobile node to the security gateway, or based on the mobile node's address being allocated when in the source network, or based on an inquiry to an authentication server, contacted by the security gateway during the establishment of the tentative security association.
  • the step of establishing the tentative tunnel between the packet data network gateway and the security gateway comprises configuring by the security gateway a tentative binding cache entry at the packet data network gateway using the address of the security gateway, upon establishing the tentative security association.
  • a general security gateway identification is provided to the mobile node during the step of establishing the tentative security association or the tentative tunnel.
  • the tentative tunnel is activated by transmitting a message from the mobile node to the packet data network gateway comprising the general security gateway identification.
  • the tentative tunnel between the packet data network gateway and the security gateway is established by the security gateway and activated by the mobile node.
  • the mobile node receives an authentication token, for later authorizing the mobile node to activate the tentative tunnel established by the security gateway.
  • a plurality of non-3GPP networks are available for the handover of the mobile node, and at least one security gateway candidate is determined for the plurality of non-3GPP networks.
  • a tentative security association is established between the mobile node and each determined security gateway candidate.
  • a tentative tunnel is established between the packet data network gateway and each determined security gateway candidate.
  • a tentative security association with each determined security gateway candidate is established by transmitting from each determined security gateway candidate to the mobile node information on access networks preferable for each determined security gateway candidate. Said information on access networks is used by the mobile node to determine the target security gateway among the security gateway candidates.
  • the mobile node establishes a second IP session via a second packet data network gateway.
  • the second IP session is established by establishing a second tentative tunnel between the second packet data network gateway and the security gateway for the second IP session.
  • the second IP session is established by transmitting a general security gateway identification from the mobile node to the second packet data network gateway.
  • the second tentative tunnel is established by the second packet data network gateway using the general security gateway identification.
  • the source network is a non-3GPP network and the ongoing IP session of the mobile node goes via a security gateway of the source non-3GPP network.
  • a security association between the security gateway of the source non-3GPP network and the mobile node is updated by using the mobile node's home address for establishing a tentative state of said security association between the security gateway of the source non-3GPP network and the mobile node.
  • a tunnel between the packet data network gateway and the security gateway of the source non-3GPP network used for the IP session is changed into a tentative state.
  • a direct interface is established between the security gateway and an entity in the source network.
  • the tentative security association is established between the mobile node and the security gateway by communicating over the direct interface between the entity in the source network and the security gateway.
  • the source network is a non-3GPP network
  • the ongoing IP session of the mobile node goes via a further security gateway of the source non-3GPP network.
  • the entity in the source network is a mobility management entity. Furthermore, the mobility management entity learns the IP address of the security gateway by:
  • the invention further provides a mobile node attached to a source network for ensuring IP session continuity upon a handover of the mobile node to a non-3GPP network.
  • the mobile node has an ongoing IP session via a packet data network gateway in the source network.
  • a receiver and a transmitter of the mobile node exchange messages with a security gateway for establishing a tentative security association between the mobile node and the security gateway, while the mobile node is attached to the source network.
  • the security gateway provides for the source network a secure communication intermediary to the non-3GPP network.
  • the receiver and transmitter of the mobile node further exchange messages with the security gateway for updating the tentative security association between the mobile node and the security gateway by using the mobile node's local address in the non-3GPP network for establishing a secure tunnel between the mobile node and the security gateway.
  • the invention also provides a security gateway for providing a secure communication intermediary to non-3GPP networks and for ensuring IP session continuity for a mobile node upon a handover from a source network to one of the non-3GPP networks.
  • the mobile node is first located in the source network and has an ongoing IP session via a packet data network gateway in the source network.
  • a receiver and transmitter of the security gateway exchange messages with the mobile node for establishing a tentative security association between the mobile node and the security gateway, while the mobile node is attached to the source network.
  • the processor further activates the tentative security association between the mobile node and the security gateway by using the mobile node's local address in the non-3GPP network for establishing a secure tunnel between the mobile node and the security gateway.
  • the invention further provides a packet data network gateway in a source network to which a mobile node is attached for ensuring IP session continuity upon a handover of the mobile node to a non-3GPP network.
  • the mobile node has an ongoing IP session via the packet data network gateway.
  • a processor of the packet data network gateway establishes a tentative tunnel between the packet data network gateway and a security gateway, which provides for the source network a secure communication intermediary to the non-3GPP network, in response to the establishment of a tentative security association between the mobile node and the security gateway, while the mobile node is attached to the source network.
  • a receiver of the packet data network gateway receives a message from the mobile node for activating the tentative tunnel between the packet data network gateway and the security gateway, when the mobile node performs the handover to the non-3GPP network.
  • the processor activates the tentative tunnel between the packet data network gateway and the security gateway in response to the received message.
  • a mobile node is a physical entity within a communication network.
  • One node may have several functional entities.
  • a functional entity refers to a software or hardware module that implements and/or offers a predetermined set of functions to other functional entities of a node or the network.
  • Nodes may have one or more interfaces that attach the node to a communication facility or medium over which nodes can communicate.
  • a network entity may have a logical interface attaching the functional entity to a communication facility or medium over it may communicate with other functional entities or correspondent nodes.
  • a 3GPP system is a communication system standardised by the 3GPP consisting of a 3GPP core network and a 3GPP radio access network.
  • a 3GPP core network is related to the part of the 3GPP system which consists of physical entities that are independent of the connection technology of the terminal (e.g. radio, wired).
  • a 3GPP access network is related to the part of the 3GPP system which consists of entities dependent on the 3GPP radio access technology, e.g. the base station.
  • a non-3GPP access network is a communication system consisting of entities providing nodes connectivity to a network independent from a 3GPP system.
  • a security association may be defined as a set of security information that two nodes or functional entities share in order to support secure communication.
  • a security association may include a data encryption algorithm, data encryption key(s) (e.g. a secret key or a public/private key pair, initialization vector(s), digital certificates, etc.).
  • data encryption key(s) e.g. a secret key or a public/private key pair, initialization vector(s), digital certificates, etc.
  • there is a security association provided between a mobile node in a foreign network and its home agent in the home network so, even if the mobile node is attached to a foreign network, encrypted and/or authenticated/authorized communication between the home agent and the mobile node (e.g. through a secured tunnel) may be ensured.
  • the security association is typically bound to the addresses of the endpoints, i.e. to the
  • Tentative is an adjective used in this invention mainly for describing a state of a tunnel.
  • a tentative tunnel is established however not yet "activated". Consequently, the endpoint entities of the tentative tunnel have established all necessary parameters (e.g. Binding-Cache-Entry) for the tentative tunnel, however do not use the tunnel for any data forwarding. Nor are any reactions carried out for a tentative tunnel which would be conducted in case a non-tentative tunnel is established.
  • an actual tunnel can be established in a fast way by only activating the tentative tunnel, since the necessary steps have been already performed beforehand.
  • the adjective "tentative" is also used for describing an IPsec security association/tunnel.
  • a IPsec security association may be active, though it is still tentative.
  • a tentative IPsec SA/tunnel need not be deactivated since no data would be transmitted anyway over said communication link.
  • a tentative IPsec tunnel would be provided between the ePDG2 and the UE. Since no data is received in ePDG2 for the UE, no data would be forwarded over said IPsec tunnel.
  • the IKE SA is merely used to negotiate shared keys between the communication partners. These shared keys are then used in the negotiation for the IPsec SA.
  • the IPsec SA defines the communication partners, and which packets are to be transmitted to which IP address, and the encryption used for the transmission of said packets etc.. Therefore, the IPsec SA may as well be referred to as an IPsec tunnel, whereas IKE SA is only necessary for exchanging keys.
  • Fig. 4a illustrates the starting position in an exemplary embodiment of the invention, in which the mobile node is located in a 3GPP access network and has an ongoing IP session with e.g. another mobile node.
  • the IP session communication is achieved via the 3GPP access network, a Serving-Gateway of the 3GPP access, a PDN-GW in the evolved Packet core network and via the Packet data network (1).
  • Proxy-Mobile IP is used, wherein the PDN-GW is the home agent of the mobile; the UE's Home Address is allocated at the PDN-GW, and the PDN-GW tunnels data packets from the PDN to the UE using a Care-of address.
  • the PMIP tunnel is established between the PDN-GW and the S-GW, since with Proxy-MIP the S-GW is the mobility anchor for mobility within the 3GPP access network, for instance when changing the eNode-Bs.
  • the Care-of address is an IP address of the S-GW.
  • the embodiments of the invention shall prepare at the forefront all possible data paths which could be needed after the handover.
  • the data path would be changed since the UE needs to communicate via an ePDG with the PDN-GW.
  • the UE needs to discover the possible ePDG, i.e. the IP addresses of the ePDGs.
  • the IP addresses of the ePDGs it is assumed that the one untrusted non-3GPP network access can be served by several ePDGs, however only one is to be selected by the mobile when eventually performing the handover to said non-3GPP network access.
  • the mobile node may use pre-configured information or the DNS (Domain Name System) system.
  • the mobile node may have a list of ePDG IP addresses stored on a smart card (USIM) that should be used from a specific non-3GPP access.
  • USIM smart card
  • the mobile node uses the SSID (Service Set Identifier) broadcasted by the network and performs a lookup in the table to determine the ePDG to be used.
  • SSID Service Set Identifier
  • the mobile constructs a FQDN (Fully Qualified Domain Name) using for example some information from the non-3GPP access and/or operator identities of the PLMN (Public Land Mobile Network) and performs a DNS query to resolve it.
  • the DNS response will contain one or more IP addresses of equivalent ePDGs the mobile node can connect to.
  • the UE uses its own IP address (MN's home address) assigned by the PDN-GW and IKEv2 to establish a tentative secure tunnel (IPsec) to the ePDG (2). Since the mobile node is still at the 3GPP access network, and the address used for IKEv2 is the home address allocated at the PDN-GW, said IPsec tunnel would go via the S-GW and the PDN-GW to the ePDG. However, as can be seen from Fig. 4a and 4b , the tentative IPsec tunnel also goes via the PDN. The reason is that the PDN-GW is configured to route all traffic sent by a mobile node to an IP network and this is the PDN.
  • MN's home address IP address assigned by the PDN-GW and IKEv2
  • IPsec tentative secure tunnel
  • the PDN can be for example the public internet, a corporate network or an intra operator network (for provisioning of IMS(IP Multimedia Subsystem) services).
  • the IP address of the ePDG used by the mobile node is an address of the external interface of the ePDG.
  • the tentative IPsec tunnel would thus use an external interface to the ePDG, and thus a different ePDG IP address (this will be discussed in more detail later.
  • the tentative IPsec tunnel is depicted as crossing the core network; however, this is only for reasons of better illustration and does not necessarily coincide with the technical implementation in which the tentative IPsec tunnel contacts the external ePDG interface from the PDN.
  • IPsec provides security services at the IP layer for other protocols and applications in order for them to communicate securely. That is, IPsec sets up a secure path between two communicating nodes over insecure intermediate systems.
  • IPsec is composed of several components to provide security service, wherein the two main ones are the Authentication Header (AH) protocol and the Encapsulating Security Payload (ESP) protocol. They provide authenticity and privacy to IP data by adding particular headers to the IP data packet.
  • the Internet Key Exchange (IKE) is the protocol used to set up a security association (SA) in the IPsec protocol suite. IKE uses a Diffie-Hellman key exchange to set up a shared session secret, from which cryptographic keys are derived.
  • IPsec Security Associations are logical connections between the two communication partners, i.e. in the invention mainly between the UE and the ePDG, and all traffic traversing the IPsec SA is provided the same security processing, e.g. integrity protection and encryption.
  • a tentative IPsec tunnel is pre-established, this should not necessarily be construed as comprising the assigning of resources to the IPsec tunnel. Instead, the pre-establishment of a tentative IPsec tunnel may also be understood as only comprising the negotiation of the IKE security association, which consumes the greatest part of the IPsec tunnel establishment. Therefore, according to the invention, it is possible to only pre-establish the security association between the UE and ePDG, or the actual IPsec tunnel may be tentatively established including the resource reservation and allocation.
  • IPsec tunnel between the UE and the ePDG is only tentative, i.e. the just-established IPsec tunnel between the UE and the ePDG is not to be used but shall rather remain idle until it is eventually needed.
  • the establishment of the IPsec tunnel between the UE and the ePDG would trigger the ePDG to transmit a Proxy Binding Update message to the PDN-GW and thus switching the traffic to the ePDG, instead of continuing transmitting the traffic via the 3GPP network to the UE. Since the UE is actually still in the 3GPP access network, this switching would be detrimental since this would lead to data loss and IP session interruption.
  • the UE may inform the ePDG that this tunnel is only a pre-establishment of a tunnel to be used later after handover.
  • any message of the IKE exchange for establishing the security association may be adapted to carry a flag or similar, from which the ePDG derives that the IPsec tunnel is merely tentative.
  • the ePDG may detect implicitly that the IPsec tunnel is only a pre-established tunnel, because the IP address used by the UE in the IKEv2 exchange is the home address of the UE. In particular, if the UE would have indeed performed the handover, the IKEv2 message exchange would have been performed with a local address in the non-3GPP access network, but not with the home address of the MN.
  • AAA authentication, authorization and accounting
  • the ePDG is the AAA client that contacts the AAA server for authentication of the UE.
  • the AAA server may detect that the UE is still in an access that does not require the ePDG.
  • the ePDG may derive that the IPsec tunnel is only a tentative one, i.e. that the UE has not performed the handover yet.
  • a skilled person is able to think of further possibilities for achieving said purpose.
  • the PMIP tunnel from the PDN-GW to the ePDG can be established in advance. Accordingly, in response to the IPsec tunnel establishment, the ePDG transmits a Proxy Binding Update (PBU) message to the PDN-GW for triggering same to establish a tentative PMIP tunnel to the ePDG without effecting the path switch in the PDN-GW.
  • PBU Proxy Binding Update
  • the PMIP tunnel between the PDN-GW and the ePDG shall be tentative as well, i.e. not being used yet.
  • a tentative state (4) of the PMIP tunnel could be crerated in the PDN-GW.
  • PMIP could be enhanced by addition of a new flag in the PBU that indicates the tunnel pre-establishment.
  • the tentative PMIP tunnel pre-establishment could for example comprise the IP address of the ePDG as tentative Binding Cache Entry as well as security, tunnel and QoS parameters.
  • the previous steps are performed so as to establish the two tentative tunnels, i.e. the secure tunnel between the UE and the ePDG, and subsequently the PMIP tunnel between the PDN-GW and the ePDG. Both are to be in a tentative state, since the UE is still in the source network, and those tentative tunnels are only to be used in case the UE actually performs the handover to said non-3GPP access network.
  • the ePDG may only create the states for the IPsec tunnel between the UE and the ePDG during the IKE/IPsec tunnel pre-establishment. Thus, no signaling is performed by the ePDG to the PDN-GW at that time. Rather, the PMIP tunnel between the ePDG and the PDN-GW is established during the handover of the UE to the untrusted non-3GPP access. In other words, according to this alternative embodiment of the invention, only the tentative IPsec tunnel between the UE and the ePDG is created beforehand.
  • Fig. 4b shows the network deployment and message exchange when the MN performs the handover to the untrusted non-3GPP network.
  • the UE informs the PDN-GW (5) of the ID of the ePDG to be used after the handover and to switch the path of the data traffic to the ePDG (6), i.e. activate the tentative state of the PMIP tunnel (in case no tentative PMIP tunnel has been established, a new state for a PMIP tunnel is created).
  • This path switch trigger can be initiated by the UE over any connection, for example over 3GPP access specific procedures directly (i.e. via Non-Access Stratum (NAS) signalling to the MME), to ensure minimal delay, and needs not to be performed via the pre-established ePDG connection.
  • NAS Non-Access Stratum
  • the L2 handover After the L2 handover is completed, it is necessary to activate the tentative IPsec tunnel between the UE and the ePDG, so that the new data path from the PDN-GW to the UE can be used. Furthermore, it is necessary to update the IPsec tunnel with the UE's new local address (7), which was assigned to the UE during the handover to the new untrusted non-3GPP network area by the access point to which the UE attached.
  • an extension to protocols is used so that the individual addresses to which an established security association is bound may be updated.
  • One possible solution may be to send a message containing the new address to which the security association is bound to the respective other peer (i.e. the ePDG). This signalling message may for example be protected by the security association.
  • the signaling message(s) for updating the addresses bound to a security association may be designed similar to the messages as for example defined in Eronen, "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", IETF RFC 4555, June 2006 (available at http://www.ietf.org ) or similar to the messages for establishing a new security association (see e.g. Haley et al., "Mobility Header Home Agent Switch Message", IETF Internet Draft, draft-ietf-mip6-ha-switch-00.txt, June 2006 ).
  • FIG. 4c This is illustrated in Fig. 4c , showing the network deployment when the UE has already attached to the new non-3GPP access network.
  • the handover of the UE to the non-3GPP network is finished, and the IP session data is transferred over the new data path.
  • the optimized handover procedure produces a shorter delay, since the handover was prepared beforehand, i.e. the necessary tunnels were already established, albeit not yet activated. Thus, when performing the handover, it suffices to activate the tentative tunnels, which can be done faster than to establish the tunnels from scratch.
  • Proxy MIP is used by the network.
  • the principles of the invention also apply to scenarios in which Client-Mobile IP is used, though with a small change.
  • the UE when using Client MIP, the UE is connected to its Home Agent, the PDN-GW via a CMIP tunnel, whereas with Proxy-MIP the UE is not directly connected to the Home Agent, i.e. the Local Mobililty Agent (LMA), but only to the ePDG, i.e. the MAG. Therefore the PMIP tunnel from the PDN-GW only reaches to the ePDG.
  • LMA Local Mobililty Agent
  • the MIP tunnel would go from the PDN-GW (UE's HA) to the UE, instead of going from the PDN-GW to the ePDG (UE's MAG) when employing Proxy-MIP.
  • the Client-MIP tunnel would be inside the IPsec tunnel; in other words, the data packets are first encapsulated in the PDN-GW according to Client-MIP, then the data packets are further encapsulated as a whole according to IPsec.
  • the UE when the UE activates in the PDN-GW the tentative PMIP tunnel (or creates a new state for a PMIP tunnel) to the ePDG (step (6) in Fig. 4b ), one problem is how the UE may identify the ePDG to the PDN-GW, because, when the UE establishes the connection with the ePDG for the IPsec tunnel, it uses the external IP address of the ePDG, as can be appreciated from the Fig. 4b in which the IPsec tunnel coming from the PDN arrives at the external interface of the ePDG.
  • the tunnel between the PDN-GW and the ePDG may be based on an internal IP address, different from the external one (see e.g. also Fig. 4b ).
  • the PDN-GW would need to notify the internal IP address of the ePDG, instead of the external one.
  • the PDN-GW or ePDG may provide a common ID for the ePDG, i.e. an ePDG-ID, to the UE during pre-establishment of the IPsec tunnel (2). Then, the UE uses the ePDG-ID to inform the PDN-GW about the ePDG to be used for the PDN-GW to know which tentative tunne is to be activated (or to which ePDG a PMIP tunnel is to be created).
  • ePDG-ID a common ID for the ePDG
  • the PDN-GW may derive the appropriate IP address of the ePDG, independent from the interface which is to be used to contact the ePDG.
  • a tentativ PIMP tunnel has been created between the ePDG and the PDN-GW
  • the tentative state of the PMIP tunnel is established by the ePDG (step (3)) but the state is later activated by the UE (step (5)); or in case no tentative tunnel between the ePDG and the PDN-GW has been created, the PMIP tunnel establishment in the PDN-GW is triggered by the UE, but the tunnel is actually between PDN-GW and ePDG.
  • the PDN-GW must ensure that the entity that triggers the activation is authorized to do so.
  • an authentication token may be generated during the pre-establishment of the PMIP tunnel or the IPsec tunnel between the UE and the ePDG, which is then provided to the UE. Said authentication token is then transmitted together with the activation of the PMIP tunnel, so that the PDN-GW accepts the activation and performs the necessary steps.
  • the ePDG-ID may also comprise said authentication token that is generated during the pre-establishment and that can be only known to the PDN-GW, ePDG and UE.
  • the above-mentioned steps of the embodiment to prepare the handover to a non-3GPP network while the UE is still in the source network may be conducted anytime before the handover. Since the ongoing IP sessions may change significantly while in one network, advantageously, the steps should be performed only when a handover is to be expected. In order to determine whether a handover is getting more likely, there are several possibilities. For instance, whether a non-3GPP access is everywhere available in the vicinity of the current location or not can be determined by using neighbour graphs showing the deployment of the non-3GPP/3GPP access networks. Or if non-3GPP access is everywhere available in the movement direction of the mobile terminal or not.
  • the current access might also inform the mobile node about a neighbour non-3GPP access cell list, and if the number of neighbour cells decreases, the mobile terminal may start the pre-establishment of tentative tunnels for its ongoing IP sessions.
  • the mobile node may start to pre-establish the tentative tunnels if the signal strength of the current access base station decreases and the signal strength of no other base station of the current access network starts to increase.
  • Another possibility to determine the likelihood of a handover to a non-3GPP network is when the mobile terminal stores its own movement patterns and therefore learns whether non-3GPP access coverage is available or not.
  • the mobile terminal can detect whether its current movement matches to any stored pattern, and based on the stored moving pattern, the mobile terminal knows at what point a handover to a non-3GPP access has occurred in the past, and thus it can decide when to start pre-establishing the tentative tunnels for its ongoing IP sessions.
  • the foregoing embodiment of the invention assumes that only one untrusted non-3GPP network is available for the UE handover and also assumes that only one ePDG is available to be selected by the UE. However, it may well be that there is only one untrusted non-3GPP network but several ePDGs that may serve said non-3GPP network. Similarly, there might be several non-3GPP networks (and possibly also 3GPP networks) available for handover, and for each of said non-3GPP networks there might be one or more ePDGs that may serve them. In any case, there might be several ePDG candidates for a future handover.
  • an IPsec tunnel (IKE security association) between the UE and each ePDG is pre-established, and a PMIP tunnel between the PDN-GW and each ePDG may be pre-established. Then, shortly before the handover, the UE selects one of the plurality of non-3GPP networks and correspondingly selects one of the ePDG candidates that serves said selected non-3GPP network. Accordingly, only the tentative PMIP tunnel and IPsec tunnel for said selected ePDG are activated and updated appropriately to form the new data path. After finishing the handover, the UE is thus able to quickly resume the IP session, without any significant interruption by the handover.
  • IKE security association IKE security association
  • a tentative PMIP tunnel may be and a tentative IPsec tunnel is pre-established for each ePDG candidate.
  • the remaining tentative tunnels are no longer necessary. Therefore, the tentative tunnels for the remaining ePDG may either be broken down or maintained for future use.
  • the UE may also indicate to the PDN-GW which tentative entry for the PMIP tunnels may be removed or be kept for future use.
  • the other ePDG candidates may be contacted to delete the security association established with the UE, or may keep said security association for a predetermined time.
  • One further embodiment of the invention suggests that during the IPsec tunnel pre-establishment the ePDG may inform the UE about access networks and related information that are preferable from this ePDG. With this information, the selection of the best ePDG from the new non-3GPP access network can be optimized.
  • the UE has connectivity to only one Packet Data Network (PDN) via one PDN-GW.
  • PDN Packet Data Network
  • the UE may have connectivity to multiple PDNs simultaneously, i.e. for example a connection to an Internet PDN for web-browsing and a connection to a corporate network PDN for accessing corporate emails, thereby using multiple PDN-GWs, as can be seen in Fig. 5a .
  • PDN Packet Data Network
  • the UE may have connectivity to multiple PDNs simultaneously, i.e. for example a connection to an Internet PDN for web-browsing and a connection to a corporate network PDN for accessing corporate emails, thereby using multiple PDN-GWs, as can be seen in Fig. 5a .
  • the various ongoing IP sessions are to be maintained, and thus appropriate new data paths are to be established in said respect.
  • the above-discussed embodiment of the invention can be adapted to pre-establish two tentative IPsec tunnels between the UE and ePDG respectively one for PDN-GW1 and PDN-GW2 using the two Home Addresses assigned by the two PDN-GWs. Subsequently, the ePDG would trigger the two PDN-GWs to establish a tentative PMIP tunnel to the ePDG. Accordingly, when performing the handover, the UE needs to contact each PDN-GW in order to activate the respective tentative PMIP tunnels to the ePDG. Furthermore, the MOBIKE protocol can be used after handover, to update the two IPsec tunnels with the new local IP address assigned to the UE in the non-3GPP access network. Consequently, two separate data paths would have been pre-established and then activated for use after the handover; one for each ongoing IP session.
  • the UE may include the APNs of both PDN-GWs during the tunnel establishment, i.e. in the IDr payload of the IKE_AUTH message, the APNs separated by a specific delimiter symbol. Based on the APNs, the ePDG finds out that connections to two PDN-GWs are needed. Further, the UE should include in the IKE_AUTH a configuration payload (CFG_REQUEST) with two Configuration Attributes requesting for two internal addresses in order to get both corresponding home addresses. Therefore, network/air resources are saved by re-using the IPsec tunnel.
  • CFG_REQUEST configuration payload
  • the UE is active in the 3GPP access network and has a connection to a PDN-GW1 (1), using a first Home Address HoA1 assigned by PDN-GW1. Furthermore, the UE has pre-established a tentative PMIP tunnel between the PDN-GW1 and an ePDG (2) in addition to the tentative IPsec tunnel between the ePDG and the UE. Then, the UE establishes an additional PDN connection with a different PDN-GW2 (3) using a second Home Address HoA2 assigned by PDN-GW2.
  • Fig. 5b shows the network deployment when the UE has attached to the new non-3GPP network.
  • the UE activates the tentative IPsec tunnel to the ePDG and updates same using e.g. MOBIKE with the UE's local IP address (5). Since the second IP session via PDN-GW2 has been established after the pre-establishment of the tunnels for the first IP session is performed, no tentative tunnels have been set up for PDN-GW2.
  • a further embodiment of the invention is disclosed to solve the problems discussed with reference to Fig. 5a and 5b , namely when a further IP session is set up after the pre-establishment for a first IP session is already completed.
  • the UE re-initiates the inventive pre-establishment procedure with the ePDG and signals connectivity with PDN-GW1 and PDN-GW2 (2).
  • this embodiment of the invention can be compared to the previous-discussed case where the two IP sessions are already set up from the beginning, and the pre-establishment is performed with both PDN-GWs at the same time.
  • the ePDG instructs the two PDN-GWs to respectively set up a tentative PMIP tunnel to the ePDG.
  • the tentative tunnels for the first IP session and for the second IP session are then activated and updated during and after the handover so as to establish the new data paths to the new non-3GPP access network.
  • this procedure increases the signalling over the air, since the pre-establishment for the first IP session is conducted twice.
  • Fig. 7 Another solution to said problem is depicted in Fig. 7 according to a different embodiment of the invention.
  • the difference to the first solution of Fig. 6 is that instead of pre-establishing the tentative tunnels for both IP sessions, the pre-establishment is performed only for the second IP session, while maintaining the tentative tunnels already established for the first IP session.
  • the UE after establishment of the additional PDN connection (1), the UE pre-establishes another tentative IPsec tunnel with the ePDG, this time using MN's HoA2 via PDN-GW2 (2).
  • the ePDG would then trigger the PDN-GW2 to establish a tentative PMIP tunnel to the ePDG.
  • the UE receives an authentication token from the ePDG within or in addition to a common ePDG-ID (1). Then, in case an additional PDN connection is established before performing the handover, the UE includes the authentication token and the ePDG-ID in the PDN connectivity request (2) for establishing said new PDN connection to the PDN-GW2. Based on the ePDG-ID, the PDN-GW2 learns the ePDG the UE has already pre-established the IPsec tunnel to and can therefore create the tentative BCE (3) and the tentative PMIP tunnel to the ePDG (4).
  • the authentication token is provided from PDN-GW2 to ePDG in order for the ePDG to identify the UE and to allow modification of the SPD (Security Policy Database), to tunnel packets from the PDN-GW2 also on the tentative IPSec tunnel between UE and ePDG (5) originally established only for the first IP session via PDN-GW1.
  • SPD Security Policy Database
  • An additional advantage of this mechanism is that in case of pre-established tentative IKE/IPSec tunnels with multiple ePDGs, no additional signalling from the UE is needed, since the establishment of the tentative PMIP tunnels is triggered by the establishment of the IP session with the new PDN-GW. Furthermore, the tentative IPsec tunnel established for previous IP session may thus be reused. In contrast thereto, in the alternative solutions before, the UE needs to signal the change to the ePDG, and, in case of several ePDG candidates, to each ePDG.
  • an ePDG-ID has been provided to the UE during pre-establishment of the tentative tunnels for the first PDN-GW1 (1). Then, the ePDG-ID is provided from the UE to the new PDN-GW2 during establishment of the new PDN connection (2), so that the PDN-GW2 learns the ePDG.
  • the new PDN-GW2 discovers the ePDG based on the ePDG-ID.
  • the ePDG-ID could be an IP address of the inner ePDG interface.
  • the ePDG-ID could be an encrypted ePDG IP address, and the new PDN-GW2 can decrypt the ePDG-ID by either a shared secret between the PDN-GWs, or the new PDN-GW2 asks the AAA server to decrypt the ePDG-ID.
  • the ePDG-ID could be an FQDN (Fully Qualified Domain Name) of the ePDG, different from the FQDN used by the UE to discover the ePDG.
  • FQDN Frully Qualified Domain Name
  • the ePDG-ID can be assigned by the old PDN-GW1, and the new PDN-GW2 can ask the old PDN-GW about the ePDG IP address corresponding to the ePDG-ID.
  • the new PDN-GW2 needs to know the old PDN-GW1.
  • the UE includes the APN (Access Point Name) used for the old PDN-GW1 in the PDN connectivity request to the new PDN-GW2 when establishing the new IP session.
  • the new PDN-GW2 may thus discover the old PDN-GW1 based on this APN.
  • another possibility to enable the PDN-GW2 to learn the old PDN-GW1 is that the MME, that is contacted during session establishment, includes the old PDN-GW1 IP address in the PDN connectivity request transmitted to the PDN-GW2.
  • the ePDG IP address is provided to the PDN-GW2 from the MME in the following way.
  • the MME can be provided with the ePDG information from the AAA/HSS (Home Subscriber Server) when the UE is performing authentication during pre-establishment of the tentative IPsec tunnel for the first IP session.
  • the ePDG IP address and ePDG-ID are provided by the ePDG to the AAA/HSS. Because there is a change in the AAA/HSS UE context, the MME is updated with the new context, including the ePDG IP address and ePDG-ID. Accordingly, in the PDN connectivity request for establishing the second IP session via the new PDN-GW2 the MME can then add (or substitute the ePDG ID by) the ePDG IP address received from the AAA/HSS.
  • the ePDG-ID to be used from the new PDN-GW2 could be different from the ePDG-ID used from the old PDN-GW1 (e.g. in case the ePDG-ID relates to an IP address of the ePDG).
  • the old PDN-GW1 is in a HPLMN (Home Public Land Mobile Network) and the new PDN-GW is in the VPLMN (Visited Public Land Mobile Network).
  • a Visited Public Land Mobile Network is that PLMN on which the mobile subscriber has roamed when leaving its HLPMN.
  • an ePDG may be reached via different IP addresses from the differing PLMNs.
  • IPv4 addressing is used within the HPLMN, where also the ePDG is located
  • the PDN-GW1 may use the local IPv4 address to contact the ePDG and therefore the ePDG-ID is the local IPv4 address.
  • the local IPv4 address of the ePDG in the HPLMN is not reachable and instead NAT is used.
  • the new PDN-GW uses the NAT's IP address and therefore the ePDG-ID is the NAT's IPv4 address.
  • Fig. 9 In the PDN connectivity request from the UE to the new PDN-GW2 the APN of the old PDN-GW1 is included (1).
  • the MME determines the old PDN-GW1 based on the APN and provides the new PDN-GW2 IP address and some user specific information (e.g. authentication token or MN-Network Access Identifier) to the old PDN-GW1 (2).
  • the old PDN-GW1 provides the new PDN-GW2 IP address together with the user specific information to the ePDG (3).
  • the ePDG will setup the PMIP tunnel and the tentative BCE in the new PDN-GW2 (4).
  • the ePDG-ID assigned by the new PDN-GW2 is provided to the UE during the completion of the UE requested PDN connectivity procedure.
  • the UE is attached to a 3GPP access and at the same time connected to a non-3GPP access .
  • the UE has a PDN connection established over the 3GPP access and might be actively exchanging user data via the 3GPP network, whereas no user data exchange is performed via the non-3GPP network.
  • the UE might also perform the pre-establishment of the tentative IKE/IPsec SA with the ePDG, and optionally the tentative PMIP tunnel between ePDG and PDN-GW.
  • the UE would establish the IKE/IPsec SA with the ePDG over the non-3GPP access and use its local address in the non-3GPP network instead of the home address of the UE at the PDN-GW.
  • no MOBIKE signalling is necessary to update the tentative IKE/IPsec SA, though MOBIKE might be used to trigger the PDN-GW to perform the path switch.
  • the ePDG learns the address of the UE when establishing said PMIP tunnel with the PDN-GW, i.e. the PDN-GW signals the "home" IP address of the mobile node to the ePDG within the PBA, which is transmitted in response to the PBU from the ePDG.
  • the ePDG is not aware of the IP address/prefix assigned by the PDN-GW to the UE. Further, the ePDG cannot assign the IP address/prefix to the UE during the pre-establishment of the IPsec tunnel and further, the UE does not know if the expected IP address/prefix is assigned on the IKE/IPsec SA.
  • IKE/IPsec SA is established without IP address/prefix, and later, during MOBIKE signalling, the PMIP tunnel is established and a (child) SA with the appropriate IP address/prefix is configured. It is advantageous to adapt the IKEv2 protocol in said respect.
  • IKEv2 protocol it is not possible to have an IPsec SA without associated IP addresses.
  • Traffic Selector payloads TSi and TSr
  • TSi and TSr Traffic Selector payloads
  • IPsec tunnel is established with a different/local IP address/prefix and later, during MOBIKE signalling, the PMIP tunnel is established and a (child) SA with the real IP address/prefix is configured.
  • this mechanism would waste IP addresses (that could be a problem e.g. in case of use of IPv4 addresses) and increase complexity on the UE side because of the different IP address/prefix for the same PDN connection.
  • the ePDG in case of pre-establishment, assigns the IP address/prefix corresponding to the source address used by the UE for the IKE signalling, i.e. the ePDG would learn the IP address/prefix to be assigned implicitly. However, this may not work in all cases, because the IP address used for the IKE signalling may be different from the IP address/prefix to be assigned.
  • the UE is behind a NAT. In this case the source IP address of the UE seen by the ePDG is different from the IP address to be assigned. Another example is described in the following below.
  • a further problem may arise when the UE has two IP sessions, respectively one via PDN-GW1 and PDN-GW2. It is assumed that the ePDG may only be reached via PDN-GW2, however the UE wants to pre-establish the tentative IP sec tunnel to the ePDG for the IP session going over PDN-GW1. In said case, the ePDG could implicitly accept the source address from which it receives the IKE_SA_Init messages, i.e. the UE's IP address allocated at the PDN-GW2, as the IP address of the UE for which it shall establish the tentative IKE/IPsec SA.
  • the ePDG when performing the IKE_SA_INIT, the ePDG should not use the source address from which the IKE_SA_INIT has been transmitted, because said source address is the IP address of the mobile node allocated at the PDN-GW2, and not the one allocated at the PDN-GW1. Instead, the UE's IP address allocated at the PDN-GW1 has to be explicitly signaled to the ePDG, in order for the ePDG to establish the tentative IKE/IPsec SA with the appropriate IP address. As said already, usually the ePDG would learn the correct IP address explicitly from the PDN-GW during the PBU/PBA exchange.
  • the UE indicates during the IKE/IPsec SA pre-establishment the previously allocated IP address/prefix for the PDN-GW1 connection to the ePDG, e.g. in the INTERNAL_IP4_ADDRESS or the INTERNAL_IP6_ADDRESS attribute in the CFG_REQUEST Configuration Payload within the IKE_AUTH request message.
  • the ePDG does not exchange PBU/PBA with the PDN-GW and just assigns the indicated IP address/prefix to the UE during the IKE/IPsec SA establishment without verifying the IP address/prefix . Furthermore, the ePDG stores the IP address/prefix in a separate database entry, independent from any routing table or IKE/IPsec security policy database. As long as the IKE/IPsec tunnel is only pre-established, the ePDG shall not forward any downlink packets over the IPsec tunnel to the UE (Basically there should be not downlink packets arriving at the ePDG), and the ePDG does not forward any uplink packets received over the tentative IPsec tunnel.
  • the ePDG exchanges PBU/PBA (including the indicated IP address/prefix with the PDN-GW.
  • PBU/PBA including the indicated IP address/prefix with the PDN-GW.
  • the ePDG forwards packets in uplink and downlink (and updates the database entries).
  • an explicit signaling of the UE's IP address is needed in case the PDN-GW or another node in the PDN implements NAT (Network Address Translation) for the UE.
  • NAT Network Address Translation
  • the IP address of the UE is translated in the PDN-GW or in the other node into the address of the private network.
  • the UE should also explicitly inform the ePDG about the IP address which is to be use for establishing the tentative IKE/IPsec SA. This may be also done in the INTERNAL_IP4_ADDRESS or the INTERNAL_IP6_ADDRESS attribute in the CFG_REQUEST Configuration Payload within the IKE_AUTH request message.
  • the following scenario according to Fig. 10a and b is assumed, where the old ePDG is not reachable from the new access, however the previous IPsec and PMIP tunnels shall be maintained in a tentative state for future use.
  • the UE is actively connected over an untrusted non-3GPP access 1 to ePDG1 and is using HoA for one IP session (1) via the PDN-GW. From a neighbouring untrusted non-3GPP access 2 the UE cannot use ePDG1, i.e. it needs to use ePDG2.
  • the UE pre-establishes a tentative IKE/IPSec tunnel with the ePDG2 using HoA and the tentative PMIP tunnel between the PDN-GW and ePDG2 (2).
  • the UE receives the ePDG2-ID.
  • two tentative tunnels are pre-established for using same when in untrusted non-3GPP network 2 by only activating the tunnels, while still attached to untrusted non-3GPP network 1.
  • the UE Immediately before the handover to untrusted non-3GPP access 2, the UE indicates the ePDG2-ID to the PDN-GW to activate the tentative state of the PMIP tunnel to ePDG2 (3).
  • the PDN-GW switches the PMIP tunnel to ePDG2 (4), and furthermore the UE activates the tentative IPsec tunnel and uses MOBIKE to update the IPsec tunnel to the ePDG2 (5) using the UE's local IP address at the untrusted non-3GPP access 2.
  • the ePDG1 is not reachable, thus the IPsec tunnel as well as the PMIP tunnel provided for the data path to the non-3GPP network 1 will be broken down.
  • the IKE security association has a lifetime which expires in case the connection between the IKE-SA endpoints is interrupted for a predetermined time.
  • the PMIP tunnel is also bound to an active connection; in case the PMIP tunnel is not needed for a predetermined time, same is torn down.
  • IPsec and PMIP tunnels would have to be established from scratch. It would be advantageous to maintain already established tunnels (IPsec and PMIP) used in a source network in a tentative state, while the UE is attached to another access network, be it a non-3GPP or 3GPP or trusted/untrusted network.
  • Fig. 11 One way to overcome this problem is depicted in Fig. 11 , according to same the UE after handover to ePDG2 uses MOBIKE with its own HoA to keep the IPsec tunnel to ePDG1 alive (1) by maintaining connectivity between ePDG1 and the UE.
  • the UE signals to the ePDG1 that the IPsec tunnel between ePDG1 and PDN-GW shall be maintained in a tentative state.
  • the ePDG1 instructs the PDN-GW to not trigger the path switch; thereby the PMIP tunnel between the ePDG and the PDN-GW is kept and a tentative state of the PMIP tunnel for ePDG1 is established in the PDN-GW (2).
  • Fig. 12a and b Another possibility without the drawbacks described above is shown in Fig. 12a and b.
  • the main difference to the previous embodiment of the invention of Fig. 11 is that the relevant steps are already performed while the UE is still attached to non-3GPP network 1 and not after the handover to non-3GPP network 2.
  • the UE immediately before the handover of the UE to non-3GPP network 2, the UE uses the MOBIKE protocol with ePDG1 using its HoA so as to ensure connectivity of the IPsec tunnel also after the handover, since the IKE SA between ePDG1 and UE is updated using the UE's HoA.
  • the IPsec tunnel between the PDN-GW and ePDG1 is put into a tentative state.
  • the MOBIKE signaling of the UE with ePDG1 also includes the identification of ePDG2 (1) which will be used after the handover for connecting the UE to the core network.
  • the ePDG1 transmits a message including the ePDG2-ID to the PDN-GW (2) and thus triggers in the PDN-GW to activate the tentative state of the pre-established PMIP tunnel to the ePDG2 and to switch to said activated PMIP tunnel to ePDG2 (3).
  • the ePDG1 triggers to change the state of the PMIP tunnel between the PDN-GW and ePDG1 into tentative (4).
  • the UE further uses MOBIKE to update the IKE/IPSec tunnel to the ePDG2 after the handover to non-3GPP network 2 is complete.
  • Fig. 13 and 14 Two possibilities for coping with said scenario will be presented in connection with Fig. 13 and 14 , though said possibilities entail other problems which render them non-functional.
  • the IPsec tunnel between UE and ePDG2 is not deactivated when handing over from non-3GPP network 2 to non-3GPP network 1 but updated with the Home Address of the UE (1), which was assigned by the PDN-GW.
  • the scenarios of Fig. 13 and 14 differ from one another in that the IPsec tunnel between UE and ePDG is updated before the handover to non-3GPP access 1 on the one hand ( Fig. 13 ), and conversely updated after the handover to non-3GPP access 1 ( Fig. 14 ).
  • the UE updates the active IPsec tunnel for ePDG2 instead of deactivating it. More specifically, the UE might change the IPsec tunnel from "local IP address - ePDG2" to "HoA - ePDG2" (1) by using its Home Address with MOBIKE, and the PMIP tunnel between the PDN-GW and ePDG2 needs to be maintained active as well. Conversely, since the PMIP tunnel to ePDG2 is active, the PMIP tunnel between the PDN-GW and ePDG1 is maintained in a tentative state.
  • the PDN-GW would tunnel packets destined to HoA to ePDG2 (2) and ePDG2 would tunnel packets destined to HoA to HoA, i.e. they would be received at the PDN-GW (3). As apparent, this would cause a loop and the data packets would not be delivered to the UE.
  • the UE is again initially located in non-3GPP network 2 and performs a handover to non-3GPP network 1, i.e. activates the tentative PMIP/IPsec tunnels for ePDG1.
  • the IPsec tunnel between UE and ePDG2 is not deactivated but updated via MOBIKE using the UE's HoA, assigned by the PDN-GW.
  • the PMIP tunnel to ePDG2 is deactivated and instead the tentative PMIP tunnel to ePDG1 is activated for use by the UE after the handover.
  • the PMIP tunnel between the PDN-GW and ePDG2 would need to remain active and conversely the PMIP tunnel to ePDG1 tentative.
  • the PMIP tunnel to ePDG1 shall remain active in order to correctly receive the data when in the new non-3GPP network area. Therefore, this approach is not feasible.
  • Fig. 15a and 15b One working solution will be presented in Fig. 15a and 15b , according to a further embodiment of the invention.
  • tunnelling between the ePDGs is used.
  • the UE is located in non-3GPP network 2, expects a handover and thus pre-establishes tentative PMIP/IPsec tunnels in non-3GPP network 1 (1).
  • the UE suspects to get into a ping-pong scenario, while performing the UE-ePDG1 IKE/IPsec tunnel pre-establishment, the UE triggers the ePDG1 to setup a tentative forwarding (PMIP) tunnel between ePDG1 and ePDG2 (2).
  • PMIP tentative forwarding
  • the UE updates the IPsec tunnel to the ePDG1 using MOBIKE (3) and triggers ePDG2 to forward packets to ePDG1.
  • the PMIP tunnel from PDN-GW to ePDG1 is not activated but maintained in a tentative state.
  • the IPsec tunnel to the ePDG2 can be updated via MOBIKE using the UE's HoA. Then, in case ping-pong occurs, it suffices to update the IPsec tunnel between the UE and respectively ePDG1 and ePDG2.
  • the path switch is closer to the UE, i.e. signalling load is reduced and the PDN-GW is not affected.
  • the UE is actively connected over an untrusted non-3GPP access 1 to ePDG1 and is using HoA for the IP session. From a neighbouring untrusted non-3GPP access 2 the UE can use ePDG1, but ePDG2 is preferable. The UE pre-establishes the IKE/IPSec tunnel with the ePDG2 using the HoA over the existing PDN-GW connection and receives the ePDG2-ID. Immediately before the handover the UE uses MOBIKE to the ePDG1 with the HoA and includes in addition the ePDG2-ID.
  • This signalling triggers the change of the state in the PDN-GW and at the same time updates the IKE/IPSec SA with the ePDG1.
  • the ePDG1 updates the PMIP tunnel to the PDN-GW and includes the ePDG2-ID.
  • the PDN-GW activates the tentative state, switches the tunnel to the ePDG2 and makes the tunnel to the ePDG1 tentative.
  • the UE uses MOBIKE to update the IKE/IPSec tunnel to the ePDG2.
  • a ping-pong effect may occur with increased processing in PGW, ePDG and UE, and increased signalling.
  • the UE when suspecting to get into a ping-pong scenario, uses MOBIKE with only the active IPsec tunnel to ePDG2 (1) and keeps the other IPsec tunnel to ePDG1 in a tentative state (2). Therefore, data is received via ePDG2 and the IPsec tunnel between UE and ePDG2, while the IPsec tunnel to ePDG1 is in a tentative state, though the UE is in non-3GPP network 1.
  • the UE assumes that ping-pong will not happen anymore, it updates the tunnel to the not preferred ePDG using the HoA (3) (if not used already) and updates the tunnel to the preferred ePDG using the local address (4).
  • the UE uses the IP address assigned by the PDN-GW to establish the tentative IKE/IPsec tunnel to the ePDG.
  • the UE in order for the UE to be able to exchange IKE messages with the ePDG it is required that the ePDG is reachable from the appropriate PDN.
  • this requirement might not be true always. Instead, one problem is that the ePDG may not be reachable from this used PDN.
  • the UE could be a single PDN UE, i.e.
  • only one PDN connection is possible per time (for example because the UE implementation is simpler/easier/cheaper and does not support connectivity with multiple PDNs, or the UE is subscribed to use only a single PDN at a time) or from UE and network perspective it is preferable to have only a single PDN connection (because multiple PDNs increase signalling load, states and resources in the UE and the network).
  • the UE is a single PDN UE or a single PDN connection is preferred and the current PDN connection is for example a private or corporate network, the ePDG may not be reachable from this used PDN, because all traffic from/to external networks is blocked by a firewall.
  • Fig. 17 the unreachability of the ePDG is illustrated for a particular exemplary scenario, in which the UE tries to establish a connection to the Internet to thus reach the ePDG to pre-establish the tentative IKE/IPsec SA.
  • the UE it is not allowed for the UE to have further PDN connections apart from the PDN-GW1 connection to the Private/Corporate PDN (1).
  • the UE may not reach the Internet via PDN-GW2.
  • the PDN-GW1 only allows traffic with the Private/Corporate. Therefore, PDN-GW1 blocks traffic going to the Internet.
  • the object is how to pre-establish the IKE/IPsec SA with the ePDG when the UE is connected to a PDN from which the ePDG is not reachable.
  • One possible first solution to said problem is that the UE disconnects from the first PDN connection and switches to a different, a second PDN connection when no data is sent or received and pre-establishes the IKE/IPsec tunnel with the ePDG and switches back to the previous, the first PDN, afterwards.
  • IP address preservation for the first PDN connection cannot be ensured, because when the UE disconnects from the first PDN-GW1 and reconnects later, the PDN-GW1 may have assigned the previously allocated IP prefix meanwhile to a different UE.
  • this procedure requires that there is a time period without uplink/downlink data, which in praxis may not be available, and even less at the required moment when wanting to perform the pre-establishment of the tentative IKE/IPsec SA.
  • the UE sends a trigger to either the PDN-GW1 or the S-GW to buffer downlink packets and preserve the IP address for a later re-attach. Then, the UE may disconnect from the PDN-GW1 connection and switch to the second PDN-GW2 to pre-establish the tentative IKE/IPsec SA with the ePDG. After the IKE/IPsec tunnel with the ePDG is successfully pre-established and put in a tentative state, the UE switches back to the first PDN. In more detail, the UE may send a special PDN disconnection message with an IP address preservation indication to the MME.
  • the MME When receiving this special PDN disconnection, the MME keeps the UE context and the S5 bearer between the PDN-GW and the S-GW/MME.
  • the MME may send a trigger to the S-GW to buffer downlink packets, or the S-GW may alternatively forward the trigger to the PDN-GW1 so that the PDN-GW1 performs the downlink buffering instead of the S-GW.
  • the UE keeps its IP address and buffers uplink packets coming from the applications at the UE.
  • the UE uses a second PDN connection to establish the tentative IKE/IPsec tunnel with the ePDG and switches afterwards back to the first PDN connection is that the dead peer detection (DPD), that is usually performed periodically for an IKE SA, detects that the UE is not reachable any more and thus the tentative IKE SA is eventually deleted.
  • the DPD mechanism may be deactivated, e.g. triggered by the UE.
  • the UE has to keep the IKE SA alive by synchronizing the keep alive timer interval between the UE and the ePDG such that the UE can switch to the second PDN connection to keep the IKE SA alive before the corresponding timer in the ePDG expires.
  • a further alternative to said first solution when the ePDG is not reachable for the UE via the current PDN is that when the UE powers up, the UE connects to a second PDN connection first, instead of connecting to the intended first PDN. Then, the UE may establish the IKE/IPsec tunnel with the ePDG, and signals the APN of the desired (first) PDN in the IKE signalling to the ePDG. Subsequently, the ePDG establishes the PDN connection with the PDN-GW1.
  • the UE disconnects from the PDN-GW2 and signals handover PDN connection establishment to the MME for PDN-GW1, and in response thereto, the MME triggers the S-GW to initiate the switch of the PMIP tunnel from the ePDG to the 3GPP Access for the connection to PDN-GW1.
  • This solution is illustrated in Fig. 18 .
  • the UE can create the pre-established tentative IKE/IPsec tunnel for the PDN connection with the ePDG even for a legacy ePDG.
  • 3GPP Release-8 the PDN-GW initiated Resource Allocation Deactivation is performed in case of handover to the 3GPP access and thus would delete the IKE SA state in the ePDG.
  • the UE may indicate in the handover PDN connection establishment to the MME (step 3) that the resources in the source access should not be deactivated. This can be informed to the S-GW and included in the PBU from the S-GW to the PDN-GW.
  • the IKE SA between the UE and the ePDG is still active, even if the UE is in the 3GPP access.
  • the BCE (Binding Cache Entry) in the PDN-GW must be updated in order to switch the path and enable transfer of data packets to the ePDG, but MOBIKE does not trigger the ePDG to send the PBU. Therefore, before moving to the untrusted non-3GPP access, the UE may signal to the MME to trigger the S5 deactivation and S2b activation. Thus, the BCE in the PDN-GW can be updated.
  • a second more advantageous solution for those cases in which the ePDG is not reachable from the PDN is that the ePDG is enhanced to support a direct interface with other network entities, such as the MME for example.
  • the interface may also connect the ePDG with another entity from the core network such as the S-GW or the PDN-GW.
  • the direct interface is configured between the ePDG and the MME.
  • the UE is able to pre-establish the tentative IKE/IPsec SA with the ePDG via the MME, e.g. using NAS (Non-Access Stratum) signaling. This is depicted in Fig. 19 .
  • the new interface between the MME and the ePDG may be similar to the S101 interface between an MME and HRPD networks, which has been standardized for supporting HRPD (High Rate Packet Data) pre-registration during an optimized HRPD handover.
  • the new interface may be termed S101ePDG, and enables interactions between the ePDG with MMEs.
  • the S101ePDG interface is configured to be used for the pre-establishment of the tentative IKE/IPsec SA between the UE and the ePDG. Similar to the S101 interface, the S101ePDG interface may be based on the GTP-C protocol.
  • the protocol stack, UDP and IP headers used for the S101ePDG interface may be based on the GTP-C protocol.
  • Direct Transfer Request and Direct Transfer Response messages may be used to transport data between the MME and the ePDG, for instance within a transparent container.
  • Fig. 20 is a signalling diagram illustrating the signal exchange between the UE and the ePDG via the direct interface S101ePDG between ePDG and UE for pre-establishing an IKE/IPsec SA.
  • the MME determines the ePDG IP address, despite the transparent tunneling from the UE to the ePDG.
  • the UE may have a pre-configured ePDG IP address that is used in case the IKE/IPsec tunnel is established over a transparent tunnel.
  • An IP address of the same ePDG is also pre-configured in the MME, and the MME forwards all IKE messages from UEs to this ePDG.
  • the UE may include the ePDG IP address in a non-transparent part of the UL Information Transfer message.
  • the MME can determine the appropriate ePDG, for example either by using the IP address provided by the UE directly or by mapping the IP address to another corresponding address.
  • the MME may be pre-configured with a default ePDG, that can be different from the ePDG selected by the UE. The MME sends the message to this default ePDG and in case it is the wrong ePDG, i.e. not the one of the IKE message, the ePDG sends a relocation trigger to the MME with the IP address of the ePDG included in the IKE message. Then, the MME forwards the transparent message to this new ePDG.
  • the UE includes an anycast IP address as destination address in the IKE_SA_INIT message. Then, the MME selects an arbitrary ePDG and the ePDG replies with its real IP address that is used by the UE in the following IKE messages.
  • IP address used by the MME for the communication with the ePDG over the direct interface can be different from the IP address used by the UE for the IKE signalling, because the MME may use an IP address of an internal interface of the ePDG instead of the external IP address used by the UE. Therefore, in this case some additional functionality may be required at the ePDG or the UE to determine the appropriate IP address
  • the eNB includes a statically configured Sector ID in the Uplink S1 Tunnelling message.
  • the Sector ID is then used by the MME to determine the correct HRPD access node.
  • the Sector ID may be re-used and may correspond to the ePDG, e.g. the ePDG IP address.
  • the Sector ID is also in this case statically configured in the eNB or it is provided by the UE to the eNB.
  • Other messages i.e.
  • the UL/DL Information transfer between the UE and the eNB can be reused; the UL/DL S1 Tunnelling between the eNB and the MME can be reused; the Direct Transfer Request between MME and ePDG can be used, identical to the MME-HRPD.
  • the UE-ePDG IKE signalling can be performed transparently over the E-UTRAN and EPC, and the tentative IKE SA can be established although the ePDG is not reachable from the PDN.
  • a new direct interface may be considered between the two ePDGs. Accordingly, before doing the handover to the other target ePDG, the UE might reach the target ePDG via the source ePDG in order to pre-establish the tentative IE/IPsec SA with the target ePDG, and optionally establish the tentative IPsec tunnel between the target ePDG and the PDN-GW.
  • one problem of ePDG unreachability from a particular PDN may be that there is a firewall in the PDN or PDN-GW that blocks all traffic from/to external networks.
  • the PDN-GW/Firewall can be configured (or triggered by the UE) to let messages for the pre-establishment of a tentative IKE/IPsec SA to the ePDG pass.
  • the PDN-GW needs to know that the signalling is for ePDG tunnel pre-establishment of an existing PDN connection (in case PDN is private/corporate network and global IPv6 addresses are used, usually packets to nodes not part of private/corporate network are blocked).
  • the PDN-GW can be configured with ePDG IP addresses, however, the PDN-GW might not know all possible ePDGs (e.g. difficult in roaming scenarios). Another possibility is that the UE informs the PDN-GW via PCO (protocol configuration options) about the ePDG IP address. But PCO may not work in all accesses, for example if the UE is in a trusted non-3GPP access (like WiMAX), PCO might not be supported.
  • PCO protocol configuration options
  • the PDN-GW allows the UE to signal IKE messages to external nodes.
  • the UE includes in the IKE_SA_INIT a new IKE notify payload from type "external ePDG pre-establishment" to inform the PDN-GW about IKE with external ePDG.
  • the PDN-GW checks the IKE_SA_INIT messages from the UE, if the payload is included, the packet is routed to the internet, otherwise to the private/corporate network. Then, the PDN-GW needs to know that the IKE/IPsec SA is established with a valid ePDG. Therefore, the UE includes a "PDN-GW notification flag" during IKE signalling with the ePDG that triggers the AAA server to inform the PDN-GW about the validity of the ePDG (both notifications can be combined).
  • a computing device or processor may for example be general purpose processors, digital signal processors (DSP), application specific integrated circuits (ASIC), field programmable gate arrays (FPGA) or other programmable logic devices, etc.
  • DSP digital signal processors
  • ASIC application specific integrated circuits
  • FPGA field programmable gate arrays
  • the various embodiments of the invention may also be performed or embodied by a combination of these devices.
  • the various embodiments of the invention may also be implemented by means of software modules, which are executed by a processor or directly in hardware. Also a combination of software modules and a hardware implementation may be possible.
  • the software modules may be stored on any kind of computer readable storage media, for example RAM, EPROM, EEPROM, flash memory, registers, hard disks, CD-ROM, DVD, etc.

Claims (14)

  1. Verfahren zum Sicherstellen der IP-Sitzungskontinuität bei einer Weiterleitung eines mobilen Knotens von einem Quellnetzwerk an ein Nicht-3GPP-Netzwerk, wobei sich der mobile Knoten zuerst im Quellnetzwerk befindet und eine laufende IP-Sitzung über ein Paketdatennetzwerk-Gateway in dem Quellnetzwerk hat,
    während der mobile Knoten mit dem Quellnetzwerk verknüpft ist, umfasst das Verfahren die Schritte:
    Errichten einer vorläufigen Sicherheitszuordnung zwischen dem mobilen Knoten und einem Sicherheits-Gateway, wobei das Sicherheits-Gateway für das Quellnetzwerk eine sichere Kommunikationsvermittlung zu dem Nicht-3GPP-Netzwerk bereitstellt, und
    Errichten eines vorläufigen Tunnels zwischen dem Sicherheits-Gateway und dem Paketdatennetzwerk-Gateway,
    wenn die Weiterleitung des mobilen Knotens an das Nicht-3GPP-Netzwerk durchgeführt wird, umfasst das Verfahren des Weiteren die Schritte:
    Aktualisieren der vorläufigen Sicherheitszuordnung zwischen dem mobilen Knoten und dem Sicherheits-Gateway durch Verwendung der lokalen Adresse des mobilen Knotens in dem Nicht-3GPP-Netzwerk, um einen sicheren Tunnel zwischen dem mobilen Knoten und dem Sicherheits-Gateway zu errichten, und
    Aktivieren des vorläufigen Tunnels zwischen dem Paketdatennetzwerk-Gateway und dem Sicherheits-Gateway.
  2. Verfahren nach Anspruch 1, wobei das Sicherheits-Gateway über die IP-Adresse des mobilen Knotens informiert wird, die für die Errichtung der Sicherheitszuordnung zu verwenden ist.
  3. Verfahren nach Anspruch 2, wobei das Sicherheits-Gateway über die IP-Adresse des mobilen Knotens implizit oder explizit informiert wird.
  4. Verfahren nach einem der Ansprüche 1 bis 3, wobei die vorläufige Sicherheitszuordnung zwischen dem Sicherheits-Gateway und dem mobilen Knoten mittels einer Adresse des mobilen Knotens errichtet wird, die zugewiesen wird, wenn im Quellnetzwerk, und
    wobei das Aktualisieren der vorläufigen Sicherheitszuordnung das Austauschen der Adresse des mobilen Knotens, die zugewiesen wird, wenn im Quellnetzwerk, mit einer lokalen Adresse des mobilen Knotens im Nicht-3GPP-Netzwerk umfasst.
  5. Verfahren nach einem der Ansprüche 1 bis 4, wobei der Schritt zum Errichten der vorläufigen Sicherheitszuordnung den Schritt umfasst:
    Detektieren durch das Sicherheits-Gateway, dass die vorläufige Sicherheitszuordnung vorläufig ist, auf der Basis einer
    Anzeige, die von dem mobilen Knoten für das Sicherheits-Gateway bereitgestellt wird, oder auf der Basis darauf,
    dass die Adresse des mobilen Knotens zugewiesen wird, wenn im Quellnetzwerk, oder auf der Basis
    einer Anfrage an einen Authentifizierungsserver, der während der Errichtung der vorläufigen Sicherheitszuordnung vom Sicherheits-Gateway kontaktiert wird.
  6. Verfahren nach einem der Ansprüche 2 bis 5, wobei der Schritt zum Errichten des vorläufigen Tunnels zwischen dem Paketdatennetzwerk-Gateway und dem Sicherheits-Gateway den Schritt umfasst:
    beim Errichten der vorläufigen Sicherheitszuordnung Konfigurieren durch das Sicherheits-Gateway eines vorläufigen Bindung-Cache-Eintrags am Paketdatennetzwerk-Gateway mittels der Adresse des Sicherheits-Gateway.
  7. Verfahren nach einem der Ansprüche 2 bis 5, wobei eine allgemeine Sicherheits-Gateway Identifizierung für den mobilen Knoten während des Schritts zum Errichten der vorläufigen Sicherheitszuordnung oder des vorläufigen Tunnels bereitgestellt wird, und wobei der Schritt zum Aktivieren des vorläufigen Tunnels das Senden einer Nachricht von dem mobilen Knoten zu dem Paketdatennetzwerk-Gateway umfasst, das die allgemeine Sicherheits-Gateway Identifizierung umfasst.
  8. Verfahren nach einem der Ansprüche 2 bis 8, wobei der vorläufige Tunnel zwischen dem Paketdatennetzwerk-Gateway und dem Sicherheits-Gateway durch das Sicherheits-Gateway errichtet und durch den mobilen Knoten aktiviert wird, wobei das Verfahren des Weiteren den Schritt umfasst:
    Empfangen durch den mobilen Knoten eines Authentifizierungstokens für eine später Autorisierung des mobilen Knotens, um den vom Sicherheits-Gateway errichteten vorläufigen Tunnel zu aktivieren.
  9. Verfahren nach einem der Ansprüche 2 bis 8, wobei eine Vielzahl von Nicht-3GPP-Netzwerken für die Weiterleitung des mobilen Knotens verfügbar sind und wobei
    mindestens ein Sicherheits-Gateway Kandidat für die Vielzahl von Nicht-3GPP-Netzwerken bestimmt wird,
    eine vorläufige Sicherheitszuordnung zwischen dem mobilen Knoten und jedem bestimmten Sicherheits-Gateway Kandidaten errichtet wird,
    ein vorläufiger Tunnel zwischen dem Paketdaten-Netzwerk-Gateway und jedem bestimmten Sicherheits-Gateway Kandidaten errichtet wird, und
    wobei, wenn die Weiterleitung des mobilen Knotens an ein Ziel-Nicht-3GPP-Netzwerk durchgeführt wird, die vorläufige Sicherheitszuordnung aktualisiert und der vorläufige Tunnel aktiviert wird, der für das Zielsicherheits-Gateway des Ziel-Nicht-3GPP-Netzwerks errichtet wurde.
  10. Verfahren nach Anspruch 9, wobei der Schritt zum Errichten einer vorläufigen Sicherheitszuordnung mit jedem bestimmten Sicherheits-Gateway Kandidaten den Schritt umfasst:
    Senden von jedem bestimmten Sicherheits-Gateway Kandidaten an den mobilen Knoten von Informationen über Zugangsnetzwerke, die für jeden bestimmten Sicherheits-Gateway Kandidaten bevorzugt werden, und
    wobei die Informationen über Zugangsnetzwerke von dem mobilen Knoten verwendet werden, um das Zielsicherheits-Gateway unter den Sicherheits-Gateway Kandidaten zu bestimmen.
  11. Verfahren nach einem der Ansprüche 1 bis 10, wobei der mobile Knoten eine zweite IP-Sitzung über ein zweites Paketdatennetzwerk-Gateway erreichtet und der Schritt zum Errichten der zweiten IP-Sitzung des Weiteren die Schritte umfasst:
    Errichten eines zweiten vorläufigen Tunnels zwischen dem zweiten Paketdatennetzwerk-Gateway und dem Sicherheits-Gateway für die zweite IP-Sitzung.
  12. Verfahren nach Anspruch 11, wobei der Schritt zum Errichten der zweiten IP-Sitzung des Weiteren die Schritte umfasst:
    Senden einer allgemeinen Sicherheits-Gateway Identifizierung von dem mobilen Knoten an das zweite Paketdatennetzwerk-Gateway,
    wobei der zweite vorläufige Tunnel durch das zweite Paketdatennetzwerk-Gateway mittels der allgemeinen Sicherheits-Gateway Identifizierung errichtet wird.
  13. Verfahren nach einem der Ansprüche 1 bis 12, wobei das Quellnetzwerk ein Nicht-3GPP-Netzwerk ist und die laufende IP-Sitzung des mobilen Knotens über ein Sicherheits-Gateway des Quell-Nicht-3GPP-Netzwerks geht, wobei das Verfahren des Weiteren die Schritte umfasst, die nach der Weiterleitung des mobilen Knotens an das Ziel-Nicht-3GPP-Netzwerk durchgeführt werden:
    Aktualisieren einer Sicherheitszuordnung zwischen dem Sicherheits-Gateway des Quell-Nicht-3GPP-Netzwerks und dem mobilen Knoten durch Verwendung der Heimatadresse des mobilen Knotens zum Errichten eines vorläufigen Zustands der Sicherheitszuordnung zwischen dem Sicherheits-Gateway des Quell-Nicht-3GPP-Netzwerks und dem mobilen Knoten,
    Ändern eines Tunnels zwischen dem Paketdatennetzwerk-Gateway und dem Sicherheits-Gateway des Quell-Nicht-3GPP-Netzwerks, das für die IP-Sitzung verwendet wird, in einen vorläufigen Zustand.
  14. Mobiler Knoten, der mit einem Quellnetzwerk verknüpft ist, um eine IP-Sitzungskontinuität bei einer Weiterleitung des mobilen Knotens an ein Nicht-3GPP-Netzwerk sicherzustellen, wobei der mobile Knoten eine laufende IP-Sitzung über ein Paketdatennetzwerk-Gateway im Quellnetzwerk hat, wobei der mobile Knoten umfasst:
    einen Empfänger und einen Sender, die angepasst sind, um Nachrichten mit einem Sicherheits-Gateway zur Errichtung einer vorläufigen Sicherheitszuordnung zwischen dem mobilen Knoten und dem Sicherheits-Gateway auszutauschen, während der mobile Knoten mit dem Quellnetzwerk verknüpft ist, wobei das Sicherheits-Gateway für das Quellnetzwerk eine sichere Kommunikationsvermittlung zu dem Nicht-3GPP-Netzwerk bereitstellt,
    wobei in Reaktion auf das Errichten des vorläufigen Sicherheitstunnels das Sicherheits-Gateway angepasst ist, um einen vorläufigen Tunnel zwischen dem Sicherheits-Gateway und dem Paketdatennetzwerk-Gateway zu errichten,
    der Sender und der Empfänger des mobilen Knotens des Weiteren angepasst sind, um, wenn die Weiterleitung des mobilen Knotens zum Nicht-3GPP-Netzwerk durchgeführt wird,
    Nachrichten mit dem Sicherheits-Gateway zum Aktualisieren der vorläufigen Sicherheitszuordnung zwischen dem mobilen Knoten und dem Sicherheits-Gateway durch Verwenden der lokalen Adresse des mobilen Knotens in dem Nicht-3GPP-Netzwerk auszutauschen, um einen sicheren Tunnel zwischen dem mobilen Knoten und dem Sicherheits-Gateway zu errichten, und
    wobei der Sender des Weiteren angepasst ist, um, wenn die Weiterleitung des mobilen Knotens an das Nicht-3GPP-Netzwerk durchgeführt wird, eine Nachricht an das Paketdatennetzwerk-Gateway zur Aktivierung des vorläufigen Tunnels für das Sicherheits-Gateway zu senden.
EP09778682.6A 2008-09-23 2009-09-23 Optimierung von weiterleitungen an nicht vertrauenswürdige nicht-gpp-netzwerke Not-in-force EP2338264B1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP09778682.6A EP2338264B1 (de) 2008-09-23 2009-09-23 Optimierung von weiterleitungen an nicht vertrauenswürdige nicht-gpp-netzwerke

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP08016714A EP2166724A1 (de) 2008-09-23 2008-09-23 Optimierung von Weiterleitungen an nicht vertrauenswürdige Nicht-GPP-Netzwerke
PCT/EP2009/006882 WO2010034483A1 (en) 2008-09-23 2009-09-23 Optimization of handovers to untrusted non-3gpp networks
EP09778682.6A EP2338264B1 (de) 2008-09-23 2009-09-23 Optimierung von weiterleitungen an nicht vertrauenswürdige nicht-gpp-netzwerke

Publications (2)

Publication Number Publication Date
EP2338264A1 EP2338264A1 (de) 2011-06-29
EP2338264B1 true EP2338264B1 (de) 2018-05-30

Family

ID=40316942

Family Applications (2)

Application Number Title Priority Date Filing Date
EP08016714A Withdrawn EP2166724A1 (de) 2008-09-23 2008-09-23 Optimierung von Weiterleitungen an nicht vertrauenswürdige Nicht-GPP-Netzwerke
EP09778682.6A Not-in-force EP2338264B1 (de) 2008-09-23 2009-09-23 Optimierung von weiterleitungen an nicht vertrauenswürdige nicht-gpp-netzwerke

Family Applications Before (1)

Application Number Title Priority Date Filing Date
EP08016714A Withdrawn EP2166724A1 (de) 2008-09-23 2008-09-23 Optimierung von Weiterleitungen an nicht vertrauenswürdige Nicht-GPP-Netzwerke

Country Status (5)

Country Link
US (1) US8964695B2 (de)
EP (2) EP2166724A1 (de)
JP (1) JP5578579B2 (de)
KR (1) KR20110063642A (de)
WO (1) WO2010034483A1 (de)

Families Citing this family (108)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
ES2447546T3 (es) * 2008-04-11 2014-03-12 Telefonaktiebolaget L M Ericsson (Publ) Acceso a través de redes de acceso no-3GPP
US8804682B2 (en) 2009-04-17 2014-08-12 Panasonic Intellectual Property Corporation Of America Apparatus for management of local IP access in a segmented mobile communication system
EP2466962A3 (de) * 2009-09-18 2013-01-02 NEC Corporation Kommunikationssystem und Kommunikationssteuerungsverfahren
US8732816B2 (en) 2009-10-27 2014-05-20 Telefonaktiebolaget L M Ericsson (Publ) Method and apparatus for exchanging data between a user equipment and a core network via a security gateway
US8483132B2 (en) * 2009-12-04 2013-07-09 Intel Corporation Apparatus and methods for upgrading an airlink in a wireless system
US9021072B2 (en) * 2010-01-28 2015-04-28 Verizon Patent And Licensing Inc. Localized media offload
CN102763441A (zh) * 2010-02-12 2012-10-31 Nec欧洲有限公司 用于支持到相同apn的多个同时pdn连接的方法和移动终端设备
CA2696037A1 (en) 2010-03-15 2011-09-15 Research In Motion Limited Advertisement and dynamic configuration of wlan prioritization states
US9491036B2 (en) * 2010-03-18 2016-11-08 Qualcomm Incorporated Method and apparatus for facilitating prefix allocation and advertisement or delegation
CN102369695B (zh) 2010-04-29 2013-12-18 华为技术有限公司 关联会话的方法、装置及系统
WO2011141154A1 (en) * 2010-05-11 2011-11-17 Nec Europe Ltd. Method for handling failure of a mme in a lte/epc network
CN102348193B (zh) * 2010-07-28 2016-06-15 中兴通讯股份有限公司 一种网关标识上报的方法及系统
CN102377629B (zh) * 2010-08-20 2014-08-20 华为技术有限公司 终端穿越私网与ims核心网中服务器通信的方法、装置及网络系统
US8565129B1 (en) * 2010-09-01 2013-10-22 Sprint Spectrum L.P. Supporting simple IP with address translation in a proxy mobile IP gateway
US8649355B1 (en) 2010-09-01 2014-02-11 Sprint Spectrum L.P. Supporting simple IP with address translation in a wireless communication device
EP2620019B1 (de) * 2010-09-20 2018-01-17 BlackBerry Limited Verfahren und vorrichtung für paketvermittelte dienstkontinuität während eines leitungsvermittelten fallbacks
US8892724B1 (en) 2010-10-08 2014-11-18 Sprint Spectrum L.P. Assigning a type of address based on expected port utilization
CN102487489A (zh) * 2010-12-03 2012-06-06 华为技术有限公司 消息发送方法、消息处理方法和设备
US8953521B1 (en) * 2010-12-15 2015-02-10 Sprint Communications Company L.P. Facilitating communication between wireless access components
KR20120071721A (ko) * 2010-12-23 2012-07-03 한국전자통신연구원 ＰＭＩＰｖ6에서 플로우 기반의 이동성을 지원하기 위한 방법 및 장치
MX2013008150A (es) 2011-01-14 2013-09-13 Nokia Siemens Networks Oy Soporte de autenticacion externo sobre una red no confiable.
EP2676462B1 (de) * 2011-02-17 2014-12-31 Telefonaktiebolaget LM Ericsson (PUBL) Verfahren und vorrichtung zum aufbau einer pdn-verbindung
US8654723B2 (en) * 2011-03-04 2014-02-18 Rogers Communications Inc. Method and device for re-using IPSec tunnel in customer premises equipment
JP2012222410A (ja) * 2011-04-04 2012-11-12 Fujitsu Ltd 通信装置、通信システムおよび通信方法
US9084093B2 (en) 2011-04-04 2015-07-14 Interdigital Patent Holdings, Inc. Method and apparatus for controlling the application of selected IP traffic offload and local IP access
EP2538719B1 (de) * 2011-06-24 2020-03-11 Vodafone IP Licensing limited Telekommunikationsnetzwerk
EP3493565B1 (de) * 2011-07-04 2020-11-18 Koninklijke KPN N.V. Auslösung mit zeitanzeiger
US20140169332A1 (en) * 2011-07-05 2014-06-19 Nec Europe Ltd Method for supporting selection of pdn connections for a mobile terminal and mobile terminal
CN102917356B (zh) * 2011-08-03 2015-08-19 华为技术有限公司 将用户设备接入演进的分组核心网络的方法、设备和系统
US8750180B2 (en) 2011-09-16 2014-06-10 Blackberry Limited Discovering network information available via wireless networks
EP2582102A1 (de) * 2011-10-13 2013-04-17 Alcatel Lucent Verkehrsoptimierung für einen IP-Anschluss Über ein IP-Konnektivitätszugangsnetzwerk und für eine Anwendung mit Auswahl der IP-Verbindungsendpunkte
US9191985B2 (en) * 2011-11-09 2015-11-17 Verizon Patent And Licensing Inc. Connecting to an evolved packet data gateway
KR20130055194A (ko) * 2011-11-18 2013-05-28 삼성전자주식회사 이종 네트워크 간 핸드오버 방법 및 장치
CN103167572B (zh) * 2011-12-13 2015-07-29 中国移动通信集团公司 一种基于wlan接入ims的注册方法、系统及服务器
GB2498192A (en) 2012-01-04 2013-07-10 Ibm Moving OSI layer 4 connections for UMTS network with data offload at celltower
CN103220817A (zh) * 2012-01-20 2013-07-24 中兴通讯股份有限公司 会话建立方法及装置
US8885626B2 (en) * 2012-04-06 2014-11-11 Chris Gu Mobile access controller for fixed mobile convergence of data service over an enterprise WLAN
US8879530B2 (en) * 2012-04-06 2014-11-04 Chris Yonghai Gu Mobile gateway for fixed mobile convergence of data service over an enterprise WLAN
US9204299B2 (en) 2012-05-11 2015-12-01 Blackberry Limited Extended service set transitions in wireless networks
US9986466B2 (en) * 2012-05-22 2018-05-29 Verizon Patent And Licensing Inc. Anycast-based content delivery with mobility support
CN103428798B (zh) * 2012-05-22 2016-09-21 华为终端有限公司 网关选择方法、服务器、用户设备、网关及分组数据系统
US9439214B2 (en) * 2012-05-31 2016-09-06 Cisco Technology, Inc. Leveraging multiple access technologies simultaneously
US10812964B2 (en) 2012-07-12 2020-10-20 Blackberry Limited Address assignment for initial authentication
US9137621B2 (en) 2012-07-13 2015-09-15 Blackberry Limited Wireless network service transaction protocol
US8639233B1 (en) 2012-07-23 2014-01-28 Sprint Communications Company L.P. Data session continuity between wireless networks
US9300766B2 (en) * 2012-07-31 2016-03-29 At&T Intellectual Property I, L.P. Method and apparatus for initiating and maintaining sessions between endpoints
CN104641718B (zh) * 2012-09-14 2019-07-30 交互数字专利控股公司 用于在3gpp中启用非3gpp卸载的系统增强
AU2013328675B2 (en) * 2012-10-09 2016-02-18 Telefonaktiebolaget L M Ericsson (Publ) Method and apparatus for establishing and using PDN connections
WO2014057940A1 (ja) * 2012-10-09 2014-04-17 京セラ株式会社 無線通信装置及び通信制御方法
CN104823412B (zh) * 2012-10-10 2018-09-04 诺基亚通信公司 对等体复活检测的方法及装置
EP2720420B1 (de) * 2012-10-12 2018-11-21 Alcatel Lucent Verfahren zum Austausch von Informationen zur Errichtung eines Pfads zwischen zwei Knoten eines Kommunikationsnetzwerks
EP2939496B1 (de) * 2012-12-26 2018-06-13 LG Electronics Inc. Verfahren und vorrichtung zur erfassung von informationen über einen zugangspunkt in einem drahtlosen kommunikationssystem
US9674772B2 (en) * 2013-01-03 2017-06-06 Lg Electronics Inc. Method and apparatus for acquiring information on access point in wireless communication system
US9301127B2 (en) 2013-02-06 2016-03-29 Blackberry Limited Persistent network negotiation for peer to peer devices
KR20140124116A (ko) * 2013-04-16 2014-10-24 삼성전자주식회사 이동 통신 네트워크에서 데이터-패스를 최적화시키는 장치 및 방법
KR20140136365A (ko) 2013-05-20 2014-11-28 삼성전자주식회사 효과적인 무선 랜 선택 방법 및 장치
CN104185302B (zh) * 2013-05-27 2017-09-29 电信科学技术研究院 一种pdn连接管理方法和设备
CN105230072B (zh) 2013-06-20 2019-10-18 三星电子株式会社 用于在无线lan中控制服务的质量的方法和设备
KR102207484B1 (ko) 2013-08-30 2021-01-26 삼성전자 주식회사 무선 랜에서 다중 연결을 지원하는 방법 및 장치
KR20150051126A (ko) 2013-10-31 2015-05-11 삼성전자주식회사 무선랜 제어 방법 및 장치
KR102232121B1 (ko) * 2013-11-14 2021-03-25 삼성전자주식회사 장치 대 장치 통신 시스템에서 보안키를 관리하는 방법 및 장치
US9420503B2 (en) * 2014-01-21 2016-08-16 Cisco Technology, Inc. System and method for seamless mobility in a network environment
WO2015165250A1 (zh) * 2014-04-30 2015-11-05 华为技术有限公司 一种终端接入通信网络的方法、装置及通信系统
WO2015169552A1 (en) * 2014-05-05 2015-11-12 Telefonaktiebolaget L M Ericsson (Publ) Protecting wlcp message exchange between twag and ue
US11147042B1 (en) * 2014-07-08 2021-10-12 Sprint Communications Company L.P. Wireless communication system to deliver pages to wireless communication devices based on wireless fidelity network identifiers
US20160014828A1 (en) * 2014-07-11 2016-01-14 Mavenir Systems, Inc. System and method for co-located epdg and pgw functions
US9794771B2 (en) * 2014-07-31 2017-10-17 Cisco Technology, Inc. Node selection in network transitions
CN106797406B (zh) * 2014-08-21 2021-01-08 诺基亚技术有限公司 使用6LoWPAN头部压缩机制的IPv4通信
US9332015B1 (en) 2014-10-30 2016-05-03 Cisco Technology, Inc. System and method for providing error handling in an untrusted network environment
CN105991562B (zh) * 2015-02-05 2019-07-23 华为技术有限公司 IPSec加速方法、装置及系统
US9788247B1 (en) * 2015-03-13 2017-10-10 Sprint Communications Company L.P. Long term evolution (LTE) communication system to transfer communications from non-LTE to LTE networks
WO2016154935A1 (en) * 2015-03-31 2016-10-06 Telefonaktiebolaget Lm Ericsson (Publ) Methods and devices for facilitating emergency calls over wireless communication systems
US10616764B2 (en) * 2015-04-08 2020-04-07 Telefonaktiebolaget Lm Ericsson (Publ) Methods and devices for selecting network partition in untrusted WLAN access
WO2016169003A1 (zh) * 2015-04-22 2016-10-27 华为技术有限公司 接入点名称授权的方法、装置及系统
US9602493B2 (en) 2015-05-19 2017-03-21 Cisco Technology, Inc. Implicit challenge authentication process
CN107615825B (zh) * 2015-05-28 2021-01-05 瑞典爱立信有限公司 在不可信wlan接入上的多个pdn连接
US9843913B2 (en) 2015-06-12 2017-12-12 At&T Intellectual Property I, L.P. e911 call continuity for WiFi offload
US10057929B2 (en) * 2015-08-18 2018-08-21 Samsung Electronics Co., Ltd. Enhanced hotspot 2.0 management object for trusted non-3GPP access discovery
CN106470465B (zh) * 2015-08-19 2021-05-04 中兴通讯股份有限公司 Wifi语音业务发起方法、lte通信设备、终端及通信系统
US10582379B2 (en) * 2015-08-28 2020-03-03 Lg Electronics Inc. Method for supporting and setting IPsec in mobile communication
US10237795B2 (en) * 2015-10-11 2019-03-19 Qualcomm Incorporated Evolved packet data gateway (EPDG) reselection
US10064058B2 (en) 2015-12-08 2018-08-28 Cisco Technology, Inc. Node selection using a combination of subscription entitlement and nodal characteristics
US20170171752A1 (en) * 2015-12-14 2017-06-15 Qualcomm Incorporated Securing signaling interface between radio access network and a service management entity to support service slicing
EP3412110B1 (de) 2016-02-05 2021-04-28 Telefonaktiebolaget LM Ericsson (PUBL) Dienstqualität in einem neutralen host-netzwerk
US11089519B2 (en) * 2016-04-13 2021-08-10 Qualcomm Incorporated Migration of local gateway function in cellular networks
US9998970B2 (en) * 2016-04-28 2018-06-12 Samsung Electronics Co., Ltd. Fast VoWiFi handoff using IKE v2 optimization
US11388588B2 (en) * 2016-05-13 2022-07-12 Nokia Solutions And Networks Oy Optimized small data transmission over uplink
US10587568B2 (en) 2016-06-28 2020-03-10 Motorola Mobility Llc EPDG selection
WO2018061942A1 (ja) * 2016-09-30 2018-04-05 株式会社Ｎｔｔドコモ ゲートウェイ選択方法および通信システム
US20200022074A1 (en) * 2016-09-30 2020-01-16 Ntt Docomo, Inc. Gateway selection method and communication system
KR102246671B1 (ko) * 2016-11-11 2021-05-03 텔레호낙티에볼라게트 엘엠 에릭슨(피유비엘) 제5세대 코어 네트워크에 대한 비-3gpp 액세스를 위한 사용자 평면 모델
US10390277B2 (en) * 2016-11-30 2019-08-20 Samsung Electronics Co., Ltd. MOBIKE aware LTE to Wi-Fi handoff optimization
US10375744B2 (en) * 2016-12-06 2019-08-06 At&T Intellectual Property I, L.P. Session continuity between software-defined network-controlled and non-software-defined network-controlled wireless networks
US11258694B2 (en) * 2017-01-04 2022-02-22 Cisco Technology, Inc. Providing dynamic routing updates in field area network deployment using Internet Key Exchange v2
US10841084B2 (en) * 2017-02-03 2020-11-17 Qualcomm Incorporated Session management authorization token
US10624020B2 (en) * 2017-02-06 2020-04-14 Qualcomm Incorporated Non-access stratum transport for non-mobility management messages
CN110476397B (zh) * 2017-04-01 2021-01-05 华为技术有限公司 用户鉴权方法和装置
US20190097968A1 (en) * 2017-09-28 2019-03-28 Unisys Corporation Scip and ipsec over nat/pat routers
CN109819440B (zh) * 2017-11-20 2022-08-26 华为技术有限公司 鉴权的方法和装置
US10548052B2 (en) 2018-01-30 2020-01-28 Comcast Cable Communications, Llc Predictive client mobility session management
WO2019148500A1 (zh) * 2018-02-05 2019-08-08 华为技术有限公司 一种切换方法及装置
US10716037B2 (en) * 2018-10-11 2020-07-14 International Business Machines Corporation Assessment of machine learning performance with limited test data
US10952119B2 (en) * 2018-11-16 2021-03-16 T-Mobile Usa, Inc. Handover optimization based on mobility characteristics of user devices
US11218917B2 (en) * 2018-12-21 2022-01-04 Mediatek Inc. Optimized handovers of Wi-Fi offload service from a Wi-Fi network to a cellular network
WO2021140004A1 (en) * 2020-01-07 2021-07-15 Sony Group Corporation Methods for enhancing service continuity between a wireless device and a second network, related core network nodes, and related wireless devices
US20210385735A1 (en) * 2020-06-08 2021-12-09 Qualcomm Incorporated Gateway-based voice calls via a base station
US11576090B2 (en) * 2020-06-26 2023-02-07 T-Mobile Usa, Inc. MME based handover decision
US11792305B1 (en) * 2022-06-21 2023-10-17 Fidus Global, Llc Warehouse control system

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB0312681D0 (en) * 2003-06-03 2003-07-09 Ericsson Telefon Ab L M IP mobility
US7738871B2 (en) * 2004-11-05 2010-06-15 Interdigital Technology Corporation Wireless communication method and system for implementing media independent handover between technologically diversified access networks
US7738882B2 (en) * 2005-06-13 2010-06-15 Toshiba America Research, Inc. Framework of media-independent pre-authentication improvements: including considerations for failed switching and switchback
KR100879982B1 (ko) * 2006-12-21 2009-01-23 삼성전자주식회사 모바일 와이맥스 네트워크 시스템에서의 보안 시스템 및방법
US8446875B2 (en) * 2007-02-23 2013-05-21 Toshiba America Research, Inc. Media independent pre-authentication supporting fast-handoff in proxy MIPv6 environment
US8576795B2 (en) * 2007-03-16 2013-11-05 Qualcomm Incorporated Method and apparatus for handoff between source and target access systems
WO2009031048A2 (en) * 2007-09-07 2009-03-12 Alcatel Lucent Interworking between wimax and 3gpp networks
EP2223494A1 (de) * 2007-11-23 2010-09-01 Telefonaktiebolaget LM Ericsson (publ) Mobilität drahtloser lan
US20090290556A1 (en) * 2008-05-23 2009-11-26 Pouya Taaghol Wireless network handover with single radio operation
WO2010011740A2 (en) * 2008-07-24 2010-01-28 Nortel Networks Limited Anchoring services of a mobile station attached to a first service domain at a home agent in a second service domain
US8891441B2 (en) * 2008-09-04 2014-11-18 Intel Corporation L2 tunneling-based low latency single radio handoffs

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
None *

Also Published As

Publication number Publication date
US8964695B2 (en) 2015-02-24
EP2338264A1 (de) 2011-06-29
KR20110063642A (ko) 2011-06-13
EP2166724A1 (de) 2010-03-24
WO2010034483A1 (en) 2010-04-01
JP5578579B2 (ja) 2014-08-27
US20110216743A1 (en) 2011-09-08
JP2012503385A (ja) 2012-02-02

Similar Documents

Publication Publication Date Title
EP2338264B1 (de) Optimierung von weiterleitungen an nicht vertrauenswürdige nicht-gpp-netzwerke
EP2244495B1 (de) Routenoptimierung eines Datenpfades zwischen Kommunikationsknoten unter Verwendung eines Routenoptimierungsagenten
EP2353271B1 (de) Sichere Tunnelherstellung bei Anschluss oder Handover an ein Zugangsnetz
US8910271B2 (en) System and method for handover between interworking WLAN and EUTRAN access systems
US8688970B2 (en) Access-network to core-network trust relationship detection for a mobile node
US8780800B2 (en) Optimized home link detection
US9973338B2 (en) Configuration of liveness check using internet key exchange messages
Abbas et al. A review of mobility supporting tunneling protocols in wireless cellular networks
Said et al. A Comparative Study on Security implementation in EPS/LTE and WLAN/802.11
WG et al. Internet-Draft Kudelski Security Intended status: Informational S. Gundavelli, Ed. Expires: September 14, 2016 Cisco March 13, 2016

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20110310

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO SE SI SK SM TR

AX Request for extension of the european patent

Extension state: AL BA RS

DAX Request for extension of the european patent (deleted)
RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: PANASONIC INTELLECTUAL PROPERTY CORPORATION OF AME

REG Reference to a national code

Ref country code: DE

Ref legal event code: R079

Ref document number: 602009052563

Country of ref document: DE

Free format text: PREVIOUS MAIN CLASS: H04L0029060000

Ipc: H04W0012080000

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: GRANT OF PATENT IS INTENDED

RIC1 Information provided on ipc code assigned before grant

Ipc: H04W 36/00 20090101ALI20171129BHEP

Ipc: H04L 29/06 20060101ALI20171129BHEP

Ipc: H04W 12/08 20090101AFI20171129BHEP

INTG Intention to grant announced

Effective date: 20171219

RIN1 Information on inventor provided before grant (corrected)

Inventor name: IKEDA, SHINKICHI

Inventor name: HIRANO, JUN

Inventor name: VELEV, GENADI

Inventor name: BACHMANN, JENS

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE PATENT HAS BEEN GRANTED

AK Designated contracting states

Kind code of ref document: B1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO SE SI SK SM TR

REG Reference to a national code

Ref country code: GB

Ref legal event code: FG4D

REG Reference to a national code

Ref country code: CH

Ref legal event code: EP

REG Reference to a national code

Ref country code: AT

Ref legal event code: REF

Ref document number: 1004889

Country of ref document: AT

Kind code of ref document: T

Effective date: 20180615

REG Reference to a national code

Ref country code: IE

Ref legal event code: FG4D

REG Reference to a national code

Ref country code: DE

Ref legal event code: R096

Ref document number: 602009052563

Country of ref document: DE

REG Reference to a national code

Ref country code: NL

Ref legal event code: MP

Effective date: 20180530

REG Reference to a national code

Ref country code: LT

Ref legal event code: MG4D

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20180530

Ref country code: CY

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20180530

Ref country code: ES

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20180530

Ref country code: LT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20180530

Ref country code: BG

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20180830

Ref country code: NO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20180830

Ref country code: FI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20180530

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: DE

Payment date: 20180920

Year of fee payment: 10

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: GR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20180831

Ref country code: LV

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20180530

Ref country code: HR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20180530

REG Reference to a national code

Ref country code: AT

Ref legal event code: MK05

Ref document number: 1004889

Country of ref document: AT

Kind code of ref document: T

Effective date: 20180530

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: NL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20180530

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20180530

Ref country code: PL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20180530

Ref country code: DK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20180530

Ref country code: AT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20180530

Ref country code: CZ

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20180530

Ref country code: RO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20180530

Ref country code: EE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20180530

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SM

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20180530

Ref country code: IT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20180530

REG Reference to a national code

Ref country code: DE

Ref legal event code: R097

Ref document number: 602009052563

Country of ref document: DE

PLBE No opposition filed within time limit

Free format text: ORIGINAL CODE: 0009261

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MC

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20180530

REG Reference to a national code

Ref country code: CH

Ref legal event code: PL

26N No opposition filed

Effective date: 20190301

GBPC Gb: european patent ceased through non-payment of renewal fee

Effective date: 20180923

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20180530

REG Reference to a national code

Ref country code: BE

Ref legal event code: MM

Effective date: 20180930

REG Reference to a national code

Ref country code: IE

Ref legal event code: MM4A

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: LU

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20180923

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20180923

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: CH

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20180930

Ref country code: BE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20180930

Ref country code: LI

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20180930

Ref country code: FR

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20180930

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: GB

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20180923

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MT

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20180923

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: TR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20180530

REG Reference to a national code

Ref country code: DE

Ref legal event code: R119

Ref document number: 602009052563

Country of ref document: DE

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: HU

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT; INVALID AB INITIO

Effective date: 20090923

Ref country code: PT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20180530

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MK

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20180530

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: DE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20200401

Ref country code: IS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20180930