WO2008081007A1 - Network initiated relocation of a gateway support node - Google Patents
Network initiated relocation of a gateway support node Download PDFInfo
- 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
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
- H04W88/16—Gateway arrangements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W24/00—Supervisory, monitoring or testing arrangements
- H04W24/02—Arrangements for optimising operational condition
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/20—Manipulation of established connections
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
- H04W80/04—Network 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
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.
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)
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)
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 |
-
2008
- 2008-01-07 WO PCT/EP2008/000052 patent/WO2008081007A1/en active Application Filing
Patent Citations (3)
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)
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 | |
US20060291448A1 (en) | Fixed access point for a terminal device | |
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 | |
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 | |
EP3529954B1 (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 |