Saving of stable PDP contexts in case of Hardware or Software failure
Permalink
Bookmark
Share
Twitter
Digg
Reddit
Facebook
Stumbleupon
Del.icio.us| IP.com Number | IPCOM000012287D |
|
|
|---|---|---|---|
| Dated | May 25, 2003 UTC | ||
| Size | 2 page(s) (71.6 KB) | ||
| Disclosed by |
|
||
Publication Summary
In order to enable data transfer to/from the mobile station in UMTS, a so-called PDP context is established in SGSN and in the GGSN. A PDP context in the SGSN comprises all the information required to transport data packets from the Iu-interface to the Gn-interface and vice versa. Likewise, in the GGSN, a PDP context comprises all the information required to transport data packets between the Gn-interface and the Gi-interface. The data flow between the mobile station and the internet service provider is shown in the figure 1. The data packets are transported over the Iu- and Gn-interface via so-called GPRS tunnels. The protocol responsible for these GPRS-tunnels is the GTP (GPRS tunneling protocol). Both the SGSN and the GGSN contain a processor where the GTP-functionality resides (in the following, this will be referred as the GTP Module - GTM). For reliability reasons, there are several GTMs working in some kind or redundancy. Since 1+1 redundancy is usually too expensive, the GTMs will normally work in load sharing. In the following situations, the PDP contexts handled by a given GTM can no longer be served: 1) Hardware (HW)/Software (SW) failure of the GTM 2) Software-Update/Software-Upgrade of the GTM The IP-address of the GTM is visible to the outside world (at the Iu- and Gn-interface), therefore without further measures, the work of the GTM cannot simply be overtaken by another GTM. Hence, the sessions related to the PDP contexts on this GTM are lost. If the above mentioned situations occur frequently, then this loss of sessions has a very bad effect on the overall session drop rate, which is an important aspect of the reliability of an SGSN or GGSN.| Country | Austria |
|---|---|
| Language | English (United States) |
| Related Person(s) |
(CONTACT) Juergen Carstens |
| Copyright | SIEMENS AG 2003 |
About this Publication
This document was submitted to IP.com's Prior Art Database and this preview is designed to provide you with information regarding the contents of this document by displaying up to the first four pages of the document as scaled page renderings and displaying a limited amount of text which was extracted from the document on the Text Preview Tab.
To find out more on how to obtain the entire document, click the Download tab. There is a charge for downloading some Prior Art Database documents; please examine carefully whether you believe this document fills your needs before purchasing.
For more information about the Prior Art Database, visit the Learn section of this website. Thank you for visiting IP.com's Prior Art Database! You may wish to check out our Intellectual Property Library website before you leave.
S
© SIEMENS AG 2003 file: 2003J00719.doc page: 1
Saving of stable PDP contexts in case of Hardware or Software failure
Idea: Mathias Munaf, DE-Berlin; Reinhard Pichler, AT-Wien; Frank Schramm, DE-Berlin; Michael Trawny, DE-Berlin
In order to enable data transfer to/from the mobile station in UMTS, a so-called PDP context is established in SGSN and in the GGSN. A PDP context in the SGSN comprises all the information required to transport data packets from the Iu-interface to the Gn-interface and vice versa. Likewise, in the GGSN, a PDP context comprises all the information required to transport data packets between the Gn-interface and the Gi-interface. The data flow between the mobile station and the internet service provider is shown in the figure 1. The data packets are transported over the Iu- and Gn- interface via so-called GPRS tunnels. The protocol responsible for these GPRS-tunnels is the GTP (GPRS tunneling protocol). Both the SGSN and the GGSN contain a processor where the GTP- functionality resides (in the following, this will be referred as the GTP Module - GTM). For reliability reasons, there are several GTMs working in some kind or redundancy. Since 1+1 redundancy is usually too expensive, the GTMs will normally work in load sharing. In the following situations, the PDP contexts handled by a given GTM can no longer be served:
1) Hardware (HW)/Software (SW) failure of the GTM
2) Software-Update/Software-Upgrade of the GTM
The IP-address of the GTM is visible to the outside world (at the Iu- and Gn-interface), therefore without further measures, the work of the GTM cannot simply be overtaken by another GTM. Hence, the sessions related to the PDP contexts on this GTM are lost. If the above mentioned situations occur frequently, then this loss of sessions has a very bad effect on the overall session drop rate, which is an important aspect of the reliability of an SGSN or GGSN.
Up to now all PDP contexts of the GTM are lost in these situations. The number of contexts thus affected is about 100.000 contexts. The loss of such a big number of contexts implicates a high risk for the SGSN to run into an overload situation when a great portion of the mobile stations thus affected immediately tries to re-establish the PDP contexts that have just been lost.
The target of the invention proposed here is to save the PDP contexts of a GTM also in case of HW/SW-failure as well as SW-Update/Upgrade of the GTM. Below only the solution for the SGSN is described. The PDP contexts are saved by defining pairs (A,B) of GTMs, such that B takes over the work of A in case of a recovery or outage of A and A takes over the work of B in case of a recovery or outage of B. Every GTM stores the "shadow contexts" of its partner. A shadow context on B contains the same information as the corresponding context on A. It is simply marked by a flag as shadow context. In order to detect the outage of the partner GTM and set the flag, the pair of partner GTMs...