WO2008081007A1 - Network initiated relocation of a gateway support node - Google Patents

Network initiated relocation of a gateway support node Download PDF

Info

Publication number
WO2008081007A1
WO2008081007A1 PCT/EP2008/000052 EP2008000052W WO2008081007A1 WO 2008081007 A1 WO2008081007 A1 WO 2008081007A1 EP 2008000052 W EP2008000052 W EP 2008000052W WO 2008081007 A1 WO2008081007 A1 WO 2008081007A1
Authority
WO
WIPO (PCT)
Prior art keywords
support node
gateway support
gateway
network
data protocol
Prior art date
Application number
PCT/EP2008/000052
Other languages
French (fr)
Inventor
Vesa Hellgren
Original Assignee
Nokia Corporation
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 Nokia Corporation filed Critical Nokia Corporation
Publication of WO2008081007A1 publication Critical patent/WO2008081007A1/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W88/00Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/16Gateway arrangements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W24/00Supervisory, monitoring or testing arrangements
    • H04W24/02Arrangements for optimising operational condition
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W76/00Connection management
    • H04W76/20Manipulation of established connections
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W80/00Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/04Network layer protocols, e.g. mobile IP [Internet Protocol]

Definitions

  • the present invention relates to a method, a system and a network element for a network-initiated relocation of a gateway support node in a network comprising at least two gateway support nodes and a serving support node and configured to use a tunnelling protocol between gateway and serving support nodes, and further relates to a gateway support node included in such a network.
  • routing information In particular in GPRS (general packet radio system) networks using a GTP (GPRS tunnelling protocol) between a SGSN (serving GPRS support node) and a GGSN (gateway GPRS support node), routing information must be updated towards SGSN and data networks (Gi interface).
  • GTP GPRS tunnelling protocol
  • GGSN B will have to use the Gn address of GGSN A towards SGSN, when GGSN B starts serving the PDP (packet data protocol) con- texts of the failed GGSN A.
  • PDP packet data protocol
  • PDP context is created in GGSN A.
  • a method of a network-initiated relocation of a gateway support node in a network using a tunnelling protocol between gateway and serving support nodes wherein the current gateway support node passes an information about said data protocol context to another gateway support node, and - the other gateway support node makes a network-initiated modification on said data protocol context and informs a serving support node of that the other gateway support node is now the current gateway support node for said data protocol context.
  • the method may include registering a terminal to a home agent in the other gate- way support node before passing the information about the data protocol context to the other gateway node, and further include carrying out the network-initiated modification and informing the service support node only if a co-location of the gateway support node and home agent functionality is required.
  • the method includes selecting the other gateway support node to become a standby node for the current gateway support node before passing the information about the data protocol context to the other gateway node, and further includes carrying out the network-initiated modification and informing the service support node when the other gateway support node detects that the current gateway support node is failed.
  • the method can be used in a number of different systems, for example in one, where, the network is a GPRS (general packet radio system) network, the tunnelling protocol is a GPRS tunnelling protocol, the gateway support node is a gateway GPRS support node, the serving support node is a serving GPRS support node, and the data protocol is a packet data protocol.
  • GPRS general packet radio system
  • a gateway support node is configured to pass an information about a data protocol context to another gateway support node, and is further configured to make a network-initiated modification of a data protocol context received from another gateway support node and to inform a serving support node of that the other gateway support node is now the current gateway support node for the data protocol context.
  • the system may for example be used for a network-initiated relocation of a gateway support node in a network comprising at least two gateway support nodes and a serving support node and configured to use a tunnelling protocol between gateway and serving support nodes.
  • a gateway support node comprises a home agent, and is configured to pass an information about a data protocol context to another gateway support node if a co-location of the gateway support node and home agent functionality is required.
  • a gateway support node is selected to become a standby node for another gateway support node being the current gateway support node, and is further configured to make a network-initiated modification on a data protocol context received from the other gateway support node and to inform a serving support node of that it is now the current gateway support node for the data protocol context rather than the other gateway support node when detecting that the other gateway support node is failed.
  • the system can be used in a number of different environments, for example in one, where, the network is a GPRS (general packet radio system) network, the tunnelling protocol is a GPRS tunnelling protocol, the gateway support node is a gateway GPRS support node, the serving support node is a serving GPRS support node, and the data protocol is a packet data protocol.
  • GPRS general packet radio system
  • a network element comprising a controller which is configured to control a gateway support node to pass an information about a data protocol context to another gateway support node, and to make a network-initiated modification of a data protocol context received from another gateway support node and to inform a serving support node of that it is now the current gateway support node for the data protocol context rather than the other gateway support node.
  • the network element may be part of a network comprising at least two gateway support nodes and a serving support node and configured to use a tunneling protocol between gateway and serving support nodes.
  • the controller is configured to control a gateway support node comprising a home agent to pass an information about a data protocol context to another gateway support node if a co-location of the gateway support node and home agent functionality is required.
  • the controller is configured to control a gateway support node to selectively become a standby node for another gateway support node being the current gateway support node, and to make a network-initiated modification on a data protocol context received from the other gateway support node and to inform a serving support node of that it is now the current gateway support node for the data protocol context rather than the other gateway support node when detecting that the other gateway support node is failed.
  • the network element can be used in a number of different environments, for ex- ample in one, where the network is a GPRS (general packet radio system) network, the tunnelling protocol is a GPRS tunnelling protocol, the gateway support node is a gateway GPRS support node, the serving support node is a serving GPRS support node, and the data protocol is a packet data protocol.
  • GPRS general packet radio system
  • a gateway support node comprising a transmitter which is configured to pass an information about a data protocol context to another gateway support node, a receiver which is configured to receive a data protocol context from another gateway support node, and a processing unit which is configured to make a network-initiated modification of the received data protocol context, wherein said transmitter is further configured to inform a serving support node of that it is now the current gateway support node for the data protocol context rather than the other gateway support node.
  • the gateway support node may be part of a network comprising at least two gateway support nodes and a serving support node and configured to use a tunnelling protocol between gateway and serving support nodes, the gateway support node.
  • the gateway support node further comprises a home agent, and said transmitter is configured to pass an information about a data protocol context to another gateway support node if a co-location of the gateway support node and home agent functionality is required.
  • the gateway support node further com- prises a detector which is configured to detect whether or not another gateway support node is failed, and said processing unit and said transmitter are further configured to make a network-initiated modification on a data protocol context received from the other gateway support node and to inform a serving support node of that the gateway support node is now the current gateway support node for the data protocol context rather than the other gateway support node if said detector detects that the other gateway support node is failed.
  • the gateway support node can be used in a number of different environments, for example in one, where the network is a GPRS (general packet radio system) network, the tunnelling protocol is a GPRS tunnelling protocol, the gateway support node is a gateway GPRS support node, the serving support node is a serving GPRS support node, and the data protocol is a packet data protocol.
  • GPRS general packet radio system
  • the present invention allows a co-location of a home agent and a gateway support node even if the terminal mobile IP client does not support a redirection of a mobile IP session to another home agent.
  • the present invention can be used for many other problems relating to the data protocol context anchoring to a gateway support node. For example, during upgrade the contexts could be moved to another gateway support node. Even a dynamic load balancing could be possible; if one gateway support node becomes too loaded, it could move some contexts to another gateway support node. BRIEF DESCRIPTION OF THE DRAWINGS
  • Figure 1 is a schematic block diagram of a system relating to the present in- vention
  • Figure 2 is a schematic flow diagram showing the operation of a network- initiated relocation according to a first embodiment of the present invention.
  • Figure 3 is a schematic flow diagram showing the operation of a network- initiated relocation according to a second embodiment of the present invention.
  • GPRS general packet radio system
  • GTP GPRS tunnelling protocol
  • SGSN serving GPRS support node
  • GGSN gateway GPRS support node
  • FIG. 1 schematically shows an embodiment of a system including a UE (user equipment) which is connected to multiple radio networks.
  • the radio networks comprise an UTRAN (UMTS (universal mobile telecommunication system) terrestrial radio access network)/GERAN (....radio access network) and a WLAN (wireless local area network). So, the UE has a multi-radio functionality.
  • the UTRAN/GERAN and the WLAN each are associated to a DNS (domain name system).
  • the UTRAN/GERAN is connected to a SGSN, and the WLAN is connected to a TTG (.).
  • the SGSN is connected to a GGSN via a Gn/Gp interface, and the TTG is connected via a Gn' interface to the GGSN.
  • FIG. 1 shows one GGSN only, at least two GGSNs are provided, and that all GGSNs each support a Home Agent functionality.
  • FIG. 1 explains a solution related to the Home Agent problem.
  • the UE first creates an I-WLAN context in the TTG, which will then activate a PDP context in GGSN 2.
  • the UE does not have a Home Agent address in its static configuration, so that it will register to any Home Agent. Since a co-location of Home Agent and GGSN functions is essential (e.g. for charging reasons), a MIP (mobile internet protocol) registration is done to GGSN 2.
  • Next another context is created in the UTRAN/GERAN network.
  • An activation of a PDP context request (“Activate PDP Ctx Request") defines an APN (access point name).
  • the SGSN will then make a DNS (domain name system) query to resolve the IP (internet protocol) address related to the APN.
  • the DNS system typically gives 1-n IP addresses.
  • the SGSN selects one of the returned IP addresses and sends a "Create PDP Ctx (context) Request" message there. In figure 2, however the
  • the PDP context is created in GGSN 1.
  • the GGSN 1 does not know that there is a MIP session in GGSN 2, since no information about that is included in the "Create PDP Ctx Request" message.
  • the Home Agent functionality of GGSN 1 intercepts the MIP registration going to GGSN 2, and then GGSN 1 will start moving the context to GGSN 2.
  • the "Send info about GPRS ctx (context)" message contains a signalling which is not defined in standards.
  • the embodiment shown is related to the "Update PDP Context Request" message coming from GGSN 2, wherein GGSN 2 informs of that it will start handling the PDP context as recently created. Once the PDP context has been moved to GGSN 2, GGSN 2 can inform GGSN 1 of that it can release the context.
  • GGSN 1 When the GGSN is changed during the period between the "Update PDP Context Request” and “Update PDP Context Response” messages, GGSN 1 should forward all uplink user plane traffic to GGSN 2, and GGSN 2 will forward all downlink user plane traffic to GGSN 1.
  • Figure 3 shows another situation wherein a zero downtime is required so that con- texts cannot be terminated during a controlled shutdown (e.g. due to an upgrade).
  • GGSN 1 first moves context(s) to GGSN 2 with signalling being not defined in standards. Then, the GGSN 2 carries out network-initiated PDP contexts updates in a similar way as shown in figure 2. The end result is that all contexts from GGSN
  • GGSN 1 have been moved to GGSN 2, so that a shutdown of GGSN 1 does not cause a termination of the PDP contexts.
  • PDP contexts is created in GGSN A.
  • GGSN A passes information about the context to the GGSN B.
  • GGSN B will make network-initiated PDP context modification. It will inform SGSN that GGSN B is now the GGSN node for the created PDP context.
  • the new GGSN may change the IP address of the terminal. This is already supported in the GTP protocol. This may be required to avoid a routing update towards data networks (Gi in- terface); if data packets destined to the old terminal IP address are forwarded to the old GGSN 1 a new IP address may be required.
  • PDP context is created to GGSN A.
  • GGSN B is selected to become a standby node for the GGSN A, and infor- mation about the new context is passed to GGSN B.
  • GGSN B will detect when GGSN A has failed. It will then make network- initiated PDP context modification. SGSN will now start using GGSN B as new GGSN for the PDP context.
  • the change of GGSN will affect also the other side (Gi interface). It was mentioned earlier that sometimes the IP address of the terminal may have to be changed. This may be avoided, if tunnelling is used in the Gi interface and the new GGSN may replace the old GGSN as tunnel endpoint. After all, a small change is made to the existing GTP-C (GTP control plane) functionality defined in 3GPP 29.060.
  • GTP-C and GTP-U (GTP user plane) address of the PDP context may be included. If that happens, SGSN will start using the new GTP-C and GTP-U address for the PDP context. So, the functionality is similar as in the case where SGSN is changed in the PDP context modification, but the difference is in the reversed roles of GGSN and SGSN.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

A network-initiated relocation of a gateway support node in a network using a tunnelling protocol between gateway and serving support nodes, wherein a current gateway support node passes an information about a data protocol context to another gateway support node, and the other gateway support node makes a network-initiated modification on said data protocol context and informs a serving support node of that the other gateway support node is now the current gateway support node for said data protocol context.

Description

Network initiated relocation of a gateway support node
FIELD OF THE INVENTION
The present invention relates to a method, a system and a network element for a network-initiated relocation of a gateway support node in a network comprising at least two gateway support nodes and a serving support node and configured to use a tunnelling protocol between gateway and serving support nodes, and further relates to a gateway support node included in such a network.
BACKGROUND OF THE INVENTION
In particular in GPRS (general packet radio system) networks using a GTP (GPRS tunnelling protocol) between a SGSN (serving GPRS support node) and a GGSN (gateway GPRS support node), routing information must be updated towards SGSN and data networks (Gi interface).
In case e.g. GGSN A fails, GGSN B will have to use the Gn address of GGSN A towards SGSN, when GGSN B starts serving the PDP (packet data protocol) con- texts of the failed GGSN A.
Even if the PDP contexts could be moved to GGSN B, this change must be currently transparent to SGSN. However, failure is not the only case where the PDP contexts might need a relocation. If e.g. Home Agent functionality and GGSN functionality need to be in the same node, following case may happen:
1. PDP context is created in GGSN A.
2. Terminal registers to Home Agent in GGSN B.
3. If co-location of the GGSN and Home Agent functionality is required, either the Mobile IP session should be moved to GGSN A or PDP context should be moved to GGSN B.
SUMMARY OF THE INVENTION
Accordingly, it is an object of the present invention to meet the above problems.
In order to achieve the above and further objects, according to a first aspect of the present invention, there is provided a method of a network-initiated relocation of a gateway support node in a network using a tunnelling protocol between gateway and serving support nodes, wherein the current gateway support node passes an information about said data protocol context to another gateway support node, and - the other gateway support node makes a network-initiated modification on said data protocol context and informs a serving support node of that the other gateway support node is now the current gateway support node for said data protocol context.
The method may include registering a terminal to a home agent in the other gate- way support node before passing the information about the data protocol context to the other gateway node, and further include carrying out the network-initiated modification and informing the service support node only if a co-location of the gateway support node and home agent functionality is required.
In a further embodiment, the method includes selecting the other gateway support node to become a standby node for the current gateway support node before passing the information about the data protocol context to the other gateway node, and further includes carrying out the network-initiated modification and informing the service support node when the other gateway support node detects that the current gateway support node is failed.
The method can be used in a number of different systems, for example in one, where, the network is a GPRS (general packet radio system) network, the tunnelling protocol is a GPRS tunnelling protocol, the gateway support node is a gateway GPRS support node, the serving support node is a serving GPRS support node, and the data protocol is a packet data protocol.
According to a second aspect of the present invention, there is provided a system, wherein a gateway support node is configured to pass an information about a data protocol context to another gateway support node, and is further configured to make a network-initiated modification of a data protocol context received from another gateway support node and to inform a serving support node of that the other gateway support node is now the current gateway support node for the data protocol context.
The system may for example be used for a network-initiated relocation of a gateway support node in a network comprising at least two gateway support nodes and a serving support node and configured to use a tunnelling protocol between gateway and serving support nodes.
According to an embodiment of the system, a gateway support node comprises a home agent, and is configured to pass an information about a data protocol context to another gateway support node if a co-location of the gateway support node and home agent functionality is required.
According to a still further embodiment of the system, a gateway support node is selected to become a standby node for another gateway support node being the current gateway support node, and is further configured to make a network-initiated modification on a data protocol context received from the other gateway support node and to inform a serving support node of that it is now the current gateway support node for the data protocol context rather than the other gateway support node when detecting that the other gateway support node is failed.
The system can be used in a number of different environments, for example in one, where, the network is a GPRS (general packet radio system) network, the tunnelling protocol is a GPRS tunnelling protocol, the gateway support node is a gateway GPRS support node, the serving support node is a serving GPRS support node, and the data protocol is a packet data protocol.
According to a third aspect of the present invention, there is provided a network element comprising a controller which is configured to control a gateway support node to pass an information about a data protocol context to another gateway support node, and to make a network-initiated modification of a data protocol context received from another gateway support node and to inform a serving support node of that it is now the current gateway support node for the data protocol context rather than the other gateway support node.
The network element may be part of a network comprising at least two gateway support nodes and a serving support node and configured to use a tunneling protocol between gateway and serving support nodes.
According to an embodiment of the network element, the controller is configured to control a gateway support node comprising a home agent to pass an information about a data protocol context to another gateway support node if a co-location of the gateway support node and home agent functionality is required. - A -
According to a still further embodiment of the network element, the controller is configured to control a gateway support node to selectively become a standby node for another gateway support node being the current gateway support node, and to make a network-initiated modification on a data protocol context received from the other gateway support node and to inform a serving support node of that it is now the current gateway support node for the data protocol context rather than the other gateway support node when detecting that the other gateway support node is failed.
The network element can be used in a number of different environments, for ex- ample in one, where the network is a GPRS (general packet radio system) network, the tunnelling protocol is a GPRS tunnelling protocol, the gateway support node is a gateway GPRS support node, the serving support node is a serving GPRS support node, and the data protocol is a packet data protocol.
According to a fourth aspect of the present invention, there is provided a gateway support node comprising a transmitter which is configured to pass an information about a data protocol context to another gateway support node, a receiver which is configured to receive a data protocol context from another gateway support node, and a processing unit which is configured to make a network-initiated modification of the received data protocol context, wherein said transmitter is further configured to inform a serving support node of that it is now the current gateway support node for the data protocol context rather than the other gateway support node.
The gateway support node may be part of a network comprising at least two gateway support nodes and a serving support node and configured to use a tunnelling protocol between gateway and serving support nodes, the gateway support node.
According to an embodiment, the gateway support node further comprises a home agent, and said transmitter is configured to pass an information about a data protocol context to another gateway support node if a co-location of the gateway support node and home agent functionality is required.
According to a still further embodiment, the gateway support node further com- prises a detector which is configured to detect whether or not another gateway support node is failed, and said processing unit and said transmitter are further configured to make a network-initiated modification on a data protocol context received from the other gateway support node and to inform a serving support node of that the gateway support node is now the current gateway support node for the data protocol context rather than the other gateway support node if said detector detects that the other gateway support node is failed.
The gateway support node can be used in a number of different environments, for example in one, where the network is a GPRS (general packet radio system) network, the tunnelling protocol is a GPRS tunnelling protocol, the gateway support node is a gateway GPRS support node, the serving support node is a serving GPRS support node, and the data protocol is a packet data protocol.
In previously known solutions, there is often a need to "move" a Gn interface to another gateway support node. Using the present invention, this is no longer needed; i.e. no routing updates are required towards the serving support node.
In previously known solutions, when a failed gateway support node is recovering, there is a need to move the data protocol contexts back to it. This is required if the Gn interface is "moved" back to the original location. Due to the present invention, there is no need for it any more because the serving support node knows that the data protocol context is no longer in the recovered gateway support node.
In the previously known co-location solutions, there was an assumption that the home agent address or the use of the mobile IP (internet protocol) can be known already during the data protocol context activation. With the present invention, this is not always the case anymore, and the home agent address may be defined only in the terminal internal configuration.
The present invention allows a co-location of a home agent and a gateway support node even if the terminal mobile IP client does not support a redirection of a mobile IP session to another home agent.
The present invention can be used for many other problems relating to the data protocol context anchoring to a gateway support node. For example, during upgrade the contexts could be moved to another gateway support node. Even a dynamic load balancing could be possible; if one gateway support node becomes too loaded, it could move some contexts to another gateway support node. BRIEF DESCRIPTION OF THE DRAWINGS
The invention will now be described based on embodiments with reference to the accompanying drawings in which:
Figure 1 is a schematic block diagram of a system relating to the present in- vention;
Figure 2 is a schematic flow diagram showing the operation of a network- initiated relocation according to a first embodiment of the present invention; and
Figure 3 is a schematic flow diagram showing the operation of a network- initiated relocation according to a second embodiment of the present invention.
DESCRIPTION OF AN EMBODIMENT
The following description deals with a GPRS (general packet radio system) network which is using a GTP (GPRS tunnelling protocol) between a SGSN (serving GPRS support node) and a GGSN (gateway GPRS support node).
Figure 1 schematically shows an embodiment of a system including a UE (user equipment) which is connected to multiple radio networks. In the embodiment shown, the radio networks comprise an UTRAN (UMTS (universal mobile telecommunication system) terrestrial radio access network)/GERAN (....radio access network) and a WLAN (wireless local area network). So, the UE has a multi-radio functionality. The UTRAN/GERAN and the WLAN each are associated to a DNS (domain name system). Moreover, the UTRAN/GERAN is connected to a SGSN, and the WLAN is connected to a TTG (....). The SGSN is connected to a GGSN via a Gn/Gp interface, and the TTG is connected via a Gn' interface to the GGSN. With respect thereto, it is to be noted that, although figure 1 shows one GGSN only, at least two GGSNs are provided, and that all GGSNs each support a Home Agent functionality.
Figure 1 explains a solution related to the Home Agent problem. The UE first creates an I-WLAN context in the TTG, which will then activate a PDP context in GGSN 2. The UE does not have a Home Agent address in its static configuration, so that it will register to any Home Agent. Since a co-location of Home Agent and GGSN functions is essential (e.g. for charging reasons), a MIP (mobile internet protocol) registration is done to GGSN 2. Next another context is created in the UTRAN/GERAN network. An activation of a PDP context request ("Activate PDP Ctx Request") defines an APN (access point name). The SGSN will then make a DNS (domain name system) query to resolve the IP (internet protocol) address related to the APN. The DNS system typically gives 1-n IP addresses. The SGSN selects one of the returned IP addresses and sends a "Create PDP Ctx (context) Request" message there. In figure 2, however the DNS part is not shown.
The PDP context is created in GGSN 1. The GGSN 1 does not know that there is a MIP session in GGSN 2, since no information about that is included in the "Create PDP Ctx Request" message. The Home Agent functionality of GGSN 1 intercepts the MIP registration going to GGSN 2, and then GGSN 1 will start moving the context to GGSN 2. The "Send info about GPRS ctx (context)" message contains a signalling which is not defined in standards.
The embodiment shown is related to the "Update PDP Context Request" message coming from GGSN 2, wherein GGSN 2 informs of that it will start handling the PDP context as recently created. Once the PDP context has been moved to GGSN 2, GGSN 2 can inform GGSN 1 of that it can release the context.
When the GGSN is changed during the period between the "Update PDP Context Request" and "Update PDP Context Response" messages, GGSN 1 should forward all uplink user plane traffic to GGSN 2, and GGSN 2 will forward all downlink user plane traffic to GGSN 1.
Figure 3 shows another situation wherein a zero downtime is required so that con- texts cannot be terminated during a controlled shutdown (e.g. due to an upgrade).
GGSN 1 first moves context(s) to GGSN 2 with signalling being not defined in standards. Then, the GGSN 2 carries out network-initiated PDP contexts updates in a similar way as shown in figure 2. The end result is that all contexts from GGSN
1 have been moved to GGSN 2, so that a shutdown of GGSN 1 does not cause a termination of the PDP contexts.
So, for a network-initiated relocation of a GGSN basically the implementation does not require any new information elements, because they are already defined. However, the information elements are currently not allowed in the network-initiated PDP context modification. The new GGSN must be able to send the PDP context modification message.
When a co-location of Home Agent and GGSN is required, following steps can be executed:
1. PDP contexts is created in GGSN A.
2. Terminal registers to Home Agent in GGSN B.
3. If co-location of the GGSN and Home Agent functionality is required, GGSN A passes information about the context to the GGSN B.
4. GGSN B will make network-initiated PDP context modification. It will inform SGSN that GGSN B is now the GGSN node for the created PDP context.
The steps above can be executed in the order above, or in some other order.
When a network-initiated PDP context modification is done, the new GGSN may change the IP address of the terminal. This is already supported in the GTP protocol. This may be required to avoid a routing update towards data networks (Gi in- terface); if data packets destined to the old terminal IP address are forwarded to the old GGSN1 a new IP address may be required.
If GGSN A fails, following steps can be executed:
1. PDP context is created to GGSN A.
2. GGSN B is selected to become a standby node for the GGSN A, and infor- mation about the new context is passed to GGSN B.
3. GGSN B will detect when GGSN A has failed. It will then make network- initiated PDP context modification. SGSN will now start using GGSN B as new GGSN for the PDP context.
The steps above can be executed in the order above, or in some other order.
The change of GGSN will affect also the other side (Gi interface). It was mentioned earlier that sometimes the IP address of the terminal may have to be changed. This may be avoided, if tunnelling is used in the Gi interface and the new GGSN may replace the old GGSN as tunnel endpoint. After all, a small change is made to the existing GTP-C (GTP control plane) functionality defined in 3GPP 29.060. In the network initiated PDP context modification, the GTP-C and GTP-U (GTP user plane) address of the PDP context may be included. If that happens, SGSN will start using the new GTP-C and GTP-U address for the PDP context. So, the functionality is similar as in the case where SGSN is changed in the PDP context modification, but the difference is in the reversed roles of GGSN and SGSN.
Finally, it should be noted that the above described embodiments are of an example for implementing the present invention, but the scope of the present invention should not necessarily be limited by the above description. The scope of the present invention is defined by the following claims.

Claims

Claims
1. A method of a network-initiated relocation of a gateway support node in a network using a tunnelling protocol between gateway and serving support nodes, wherein a) a current gateway support node passes an information about a data protocol context to another gateway support node, and b) the other gateway support node makes a network-initiated modification on said data protocol context and informs a serving support node of that the other gateway support node is now the current gateway support node for said data protocol context.
2. The method according to claim 1 , wherein before step a) a terminal is registered to a home agent in the other gateway support node, and steps b) and c) are carried out only if a co-location of the gateway support node and home agent functionality is required.
3. The method according to claim 1 , wherein before step a) the other gateway support node is selected to become a standby node for the current gateway support node, and step c) is carried out when the other gateway support node detects that the current gateway support node is failed.
4. The method according to claim 1 , wherein the network is a GPRS (general packet radio system) network, the tunnelling protocol is a GPRS tunnelling protocol, the gateway support node is a gateway GPRS support node, the serving support node is a serving GPRS support node, and the data protocol is a packet data protocol.
5. A system for a network-initiated relocation of a gateway support node in a network comprising at least two gateway support nodes and a serving support node and configured to use a tunnelling protocol between gateway and serving support nodes, wherein a gateway support node is configured to pass an information about a data protocol context to another gateway support node, and is further configured to make a network-initiated modification of a data protocol context received from another gateway support node and to inform a serving support node of that the other gateway support node is now the current gateway support node for the data protocol context.
6. The system according to claim 5, wherein a gateway support node comprises a home agent, and is configured to pass an information about a data protocol context to another gateway support node if a co-location of the gateway support node and home agent functionality is required.
7. The system according to claim 5, wherein a gateway support node is selected to become a standby node for another gateway support node being the current gateway support node, and is further configured to make a network-initiated modification on a data protocol context received from the other gateway support node and to inform a serving support node of that it is now the current gateway support node for the data protocol context rather than the other gateway support node when detecting that the other gateway support node is failed.
8. The system according to claim 5, wherein the network is a GPRS (general packet radio system) network, the tunnelling protocol is a GPRS tunnelling protocol, the gateway support node is a gateway GPRS support node, the serving support node is a serving GPRS support node, and the data protocol is a packet data protocol.
9. A network element for a network comprising at least two gateway support nodes and a serving support node and configured to use a tunnelling protocol between gateway and serving support nodes, the network element comprising a controller which is configured to control a gateway support node to pass an information about a data protocol context to another gateway support node, and to make a network-initiated modification of a data protocol context received from another gateway support node and to inform a serving support node of that it is now the current gateway support node for the data protocol context rather than the other gateway support node.
10. The network element according to claim 9, wherein the controller is configured to control a gateway support nodes comprising a home agent to pass an information about a data protocol context to another gateway support node if a co-location of the gateway support node and home agent functionality is required.
11. The network element according to claim 9, wherein the controller is configured to control a gateway support node to selectively become a standby node for another gateway support node being the current gateway support node, and to make a network-initiated modification on a data protocol context received from the other gateway support node and to inform a serving support node of that it is now the current gateway support node for the data protocol context rather than the other gateway support node when detecting that the other gateway support node is failed.
12. The network element according to claim 9, wherein the network is a GPRS (general packet radio system) network, the tunnelling protocol is a GPRS tunnelling protocol, the gateway support node is a gateway GPRS support node, the serving support node is a serving GPRS support node, and the data protocol is a packet data protocol.
13. A gateway support node for a network comprising at least two gateway support nodes and a serving support node and configured to use a tunnelling protocol between gateway and serving support nodes, the gateway support node comprising a transmitter which is configured to pass an information about a data protocol context to another gateway support node, a receiver which is configured to receive a data protocol context from another gateway support node, and a processing unit which is configured to make a network- initiated modification of the received data protocol context, wherein said transmitter is further configured to inform a serving support node of that it is now the current gateway support node for the data protocol context rather than the other gateway support node.
14. The gateway support node according to claim 14, further comprising a home agent, wherein said transmitter is configured to pass an information about a data protocol context to another gateway support node if a co-location of the gateway support node and home agent functionality is required.
15. The gateway support node according to claim 13 further comprising a detector which is configured to detect whether or not another gateway support node is failed, and said processing unit and said transmitter are further con- figured to make a network-initiated modification on a data protocol context received from the other gateway support node and to inform a serving support node of that the gateway support node is now the current gateway support node for the data protocol context rather than the other gateway support node if said detector detects that the other gateway support node is failed.
16. The gateway support node according to claim 13, wherein the network is a GPRS (general packet radio system) network, the tunnelling protocol is a GPRS tunnelling protocol, the gateway support node is a gateway GPRS support node, the serving support node is a serving GPRS support node, and the data protocol is a packet data protocol.
PCT/EP2008/000052 2007-01-05 2008-01-07 Network initiated relocation of a gateway support node WO2008081007A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US87866407P 2007-01-05 2007-01-05
US60/878,664 2007-01-05

Publications (1)

Publication Number Publication Date
WO2008081007A1 true WO2008081007A1 (en) 2008-07-10

Family

ID=39301425

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2008/000052 WO2008081007A1 (en) 2007-01-05 2008-01-07 Network initiated relocation of a gateway support node

Country Status (1)

Country Link
WO (1) WO2008081007A1 (en)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102111458A (en) * 2009-12-23 2011-06-29 中国移动通信集团公司 Method and device for obtaining IP address of mobile terminal
WO2012073134A1 (en) 2010-11-30 2012-06-07 Telefonaktiebolaget L M Ericsson (Publ) Mobile gateways in pool for session resilience
CN102625405A (en) * 2011-02-01 2012-08-01 中兴通讯股份有限公司 Mobility management method, gateway node and core network
WO2012129137A1 (en) * 2011-03-18 2012-09-27 Alcatel-Lucent Usa Inc. System and method for failover recovery at geo-redundant gateways
US20140169330A1 (en) * 2012-12-14 2014-06-19 Telefonaktiebolaget L M Ericsson (Publ) Network Gateway Selection at Multipath Communication
WO2015051845A1 (en) * 2013-10-10 2015-04-16 Telefonaktiebolaget L M Ericsson (Publ) A pool of network gateways
WO2022084385A1 (en) * 2020-10-20 2022-04-28 Telefonaktiebolaget Lm Ericsson (Publ) Notification of packet data network gateway (pgw) ip address change

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001028185A1 (en) * 1999-10-08 2001-04-19 Telefonaktiebolaget Lm Ericsson (Publ) Wide area network mobility for ip based networks
US20030169712A1 (en) * 2002-03-05 2003-09-11 Shiao-Li Tsao Re-allocation method for a distributed GGSN system
EP1841275A2 (en) * 2006-03-31 2007-10-03 Fujitsu Ltd. Roaming in wireless networks

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001028185A1 (en) * 1999-10-08 2001-04-19 Telefonaktiebolaget Lm Ericsson (Publ) Wide area network mobility for ip based networks
US20030169712A1 (en) * 2002-03-05 2003-09-11 Shiao-Li Tsao Re-allocation method for a distributed GGSN system
EP1841275A2 (en) * 2006-03-31 2007-10-03 Fujitsu Ltd. Roaming in wireless networks

Cited By (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102111458A (en) * 2009-12-23 2011-06-29 中国移动通信集团公司 Method and device for obtaining IP address of mobile terminal
CN105915642B (en) * 2010-11-30 2019-05-28 瑞典爱立信有限公司 For the mobile gateway in the pond of session elasticity
CN105915642A (en) * 2010-11-30 2016-08-31 瑞典爱立信有限公司 Mobile Gateways In Pool For Session Resilience
CN103250398A (en) * 2010-11-30 2013-08-14 瑞典爱立信有限公司 Mobile gateways in pool for session resilience
US8559299B2 (en) 2010-11-30 2013-10-15 Telefonaktiebolaget L M Ericsson (Publ) Mobile gateways in pool for session resilience
JP2013544480A (en) * 2010-11-30 2013-12-12 テレフオンアクチーボラゲット エル エム エリクソン(パブル) Mobile gateway in the pool for session resilience
US9407498B2 (en) 2010-11-30 2016-08-02 Telefonaktiebolaget L M Ericsson (Publ) Mobile gateways in pool for session resilience
WO2012073134A1 (en) 2010-11-30 2012-06-07 Telefonaktiebolaget L M Ericsson (Publ) Mobile gateways in pool for session resilience
TWI492582B (en) * 2010-11-30 2015-07-11 Ericsson Telefon Ab L M Mobile gateways in pool for session resilience
AU2011336205B2 (en) * 2010-11-30 2014-12-04 Telefonaktiebolaget L M Ericsson (Publ) Mobile gateways in pool for session resilience
US9055081B2 (en) 2010-11-30 2015-06-09 Telefonaktiebolaget Lm Ericsson (Publ) Mobile gateways in pool for session resilience
CN102625405A (en) * 2011-02-01 2012-08-01 中兴通讯股份有限公司 Mobility management method, gateway node and core network
WO2012103753A1 (en) * 2011-02-01 2012-08-09 中兴通讯股份有限公司 Mobility management method, gateway node and core network
CN102625405B (en) * 2011-02-01 2017-07-14 南京中兴新软件有限责任公司 A kind of motion management method, gateway node and core network
WO2012129137A1 (en) * 2011-03-18 2012-09-27 Alcatel-Lucent Usa Inc. System and method for failover recovery at geo-redundant gateways
US8913484B2 (en) 2011-03-18 2014-12-16 Alcatel Lucent System and method for session restoration at geo-redundant gateways
US8908528B2 (en) 2011-03-18 2014-12-09 Alcatel Lucent System and method for session resiliancy at geo-redundant gateways
US8848514B2 (en) 2011-03-18 2014-09-30 Alcatel Lucent System and method for failover handling at geo-redundant gateways
CN103535072A (en) * 2011-03-18 2014-01-22 阿尔卡特朗讯公司 System and method for session resiliancy at geo-redundant gateways
WO2014090329A1 (en) * 2012-12-14 2014-06-19 Telefonaktiebolaget L M Ericsson (Publ) Network gateway selection at multipath communication
US20140169330A1 (en) * 2012-12-14 2014-06-19 Telefonaktiebolaget L M Ericsson (Publ) Network Gateway Selection at Multipath Communication
WO2015051845A1 (en) * 2013-10-10 2015-04-16 Telefonaktiebolaget L M Ericsson (Publ) A pool of network gateways
WO2022084385A1 (en) * 2020-10-20 2022-04-28 Telefonaktiebolaget Lm Ericsson (Publ) Notification of packet data network gateway (pgw) ip address change

Similar Documents

Publication Publication Date Title
JP6896850B2 (en) Systems and methods for session management
US7218618B2 (en) Method of providing mobile IP functionality for a non mobile IP capable mobile node and switching device for acting as a mobile IP proxy
JP5538544B2 (en) Mobility anchor relocation
EP1832081B1 (en) Method and device for setting a route for communication connection
US8494484B2 (en) Communication apparatus and communication method for tunnel switching
US20120113959A1 (en) Connection management method, connection management system, mobile terminal, packet data gateway and mobile management gateway
FI108491B (en) Repositioning the serving network element
WO2008081007A1 (en) Network initiated relocation of a gateway support node
EP2210387A1 (en) Technique for providing support for a plurality of mobility management protocols
EP1561325B1 (en) Fast recovery from unusable home server
EP1770917A1 (en) Method for managing communications and related core network node
KR101079883B1 (en) Method, system and device for releasing internet protocol connecting loading in communication system
JP2018508155A (en) Communications system
EP2135395B1 (en) Communication of information between devices in communication networks
KR20120052223A (en) Message-sending method and serving gprs support node
US8116272B2 (en) Method for dealing with the packet domain gateway support node errors
EP1400138A1 (en) Arrangement for improving the connectivity in a mobile telephone system
EP2061264B1 (en) A method and system for acquiring that sgsn has started single tunnel by ggsn in a packet domain
EP2761969B1 (en) PMIPv6 MAG RESTORATION
KR20090098889A (en) A method of providing a mobility service
US10912008B2 (en) Method and apparatuses for attaching a radio base station to a core network node

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08700997

Country of ref document: EP

Kind code of ref document: A1

DPE1 Request for preliminary examination filed after expiration of 19th month from priority date (pct application filed from 20040101)
NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 08700997

Country of ref document: EP

Kind code of ref document: A1