DE10038182A1 - Procedure for laying a tunnel between nodes of a GPRS system - Google Patents
Procedure for laying a tunnel between nodes of a GPRS systemInfo
- Publication number
- DE10038182A1 DE10038182A1 DE10038182A DE10038182A DE10038182A1 DE 10038182 A1 DE10038182 A1 DE 10038182A1 DE 10038182 A DE10038182 A DE 10038182A DE 10038182 A DE10038182 A DE 10038182A DE 10038182 A1 DE10038182 A1 DE 10038182A1
- Authority
- DE
- Germany
- Prior art keywords
- node
- version
- nodes
- tunnel
- serving
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/46—Interconnection of networks
- H04L12/4633—Interconnection of networks using encapsulation techniques, e.g. tunneling
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W36/00—Hand-off or reselection arrangements
- H04W36/12—Reselecting a serving backbone network switching or routing node
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/24—Negotiation of communication capabilities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
Abstract
Die Erfindung bezieht sich auf Verfahren zum Umlegen eines Tunnels von einem ersten bedienenden Knoten (SGSN1) eines Mobilfunk-Kommunikationssystems, insbesondere eines GPRS-Systems, auf einen zweiten (SGSN2), wobei das Mobilfunk-Kommunikationssystem bedienende Knoten (SGSN1, SGSN2) und einen Gateway-Knoten (GGSN) aufweist, wobei wenigstens einer dieser Knoten ein Knoten nach Version 0 des GTP-Protokolls ist und der andere dieser Knoten Knoten nach Version 1 des GTP-Protokolls sind. Um eine korrekte Umlegung des Tunnels zu erreichen, enthält in dem Fall, daß der erste bedienende Knoten (SGSN1) der Knoten nach Version 0 ist, die Aufforderung zur Anpassung des Kontexts eine Angabe von IMSI und NSAPI des betreffenden Tunnels. Wenn der zweite bedienende Knoten (SGSN2) oder der Gateway-Knoten (GGSN) ein Knoten nach Version 0 ist, ordnet der erste bedienende Knoten (SGSN1) dem Kontext ein Flow Label zu, und der zweite bedienende Knoten (SGSN2) sendet die Aufforderung zur Anpassung des den Tunnel betreffenden Kontexts unter Einfügung dieses zugeordneten Flow Labels.The invention relates to methods for moving a tunnel from a first serving node (SGSN1) of a mobile radio communication system, in particular a GPRS system, to a second (SGSN2), the serving mobile radio communication system (SGSN1, SGSN2) and one Gateway node (GGSN), wherein at least one of these nodes is a node according to version 0 of the GTP protocol and the other of these nodes are nodes according to version 1 of the GTP protocol. In order to achieve a correct relocation of the tunnel, in the event that the first serving node (SGSN1) is the node according to version 0, the request to adapt the context contains an indication of the IMSI and NSAPI of the tunnel in question. If the second serving node (SGSN2) or the gateway node (GGSN) is a version 0 node, the first serving node (SGSN1) assigns a flow label to the context and the second serving node (SGSN2) sends the request Adaptation of the context regarding the tunnel by inserting this assigned flow label.
Description
Die vorliegende Erfindung betrifft Verfahren zum Umlegen ei nes Tunnels von einem ersten bedienenden Knoten eines GPRS- Systems (General Packet Radio Service) auf einen zweiten.The present invention relates to methods for flipping egg tunnel from a first serving node of a GPRS Systems (General Packet Radio Service) to a second.
Das Umlegen eines Tunnels ist erforderlich, wenn ein mobiles Endgerät, das den betreffenden Tunnel nutzt, aus dem Einzugs bereich des ersten bedienenden Knotens in den des zweiten wechselt. Dieser Wechsel hat ein RAU (Routing Area Update) zur Folge, in dessen Verlauf Daten über den PDP-Kontext des Endgeräts vom ersten zum zweiten bedienenden Knoten weiterge reicht werden. Die Übertragung dieser Daten erfolgt in Form von Nachrichten nach dem GTP-Protokoll (GPRS-Tunnel-Proto koll). Nachrichten des GTP-Protokolls werden unter anderem zum Auf- und Abbau von PDP-Kontexten und zum Weiterreichen von PDP-Kontexten im Falle von Routing Area Updates verwen det. Für Einzelheiten über das GTP-Protokoll wird auf die Spezifikationsschrift 3G TS 23.060 Technical Specification Group Services and System Aspects; General Packet Radio Ser vice (GPRS); Service Description; Stage 2 (Release 1999), zum Beispiel in der Version V3.3.0 vom April 2000 des 3GPP (3rd Generation Partnership Project, www.3GPP. ORG) verwiesen.Moving a tunnel is necessary if a mobile device that uses the relevant tunnel changes from the catchment area of the first serving node to that of the second. This change results in a RAU (Routing Area Update), in the course of which data on the PDP context of the end device is passed on from the first to the second serving node. This data is transmitted in the form of messages according to the GTP protocol (GPRS tunnel protocol). Messages of the GTP protocol are used, among other things, to set up and tear down PDP contexts and to pass on PDP contexts in the case of routing area updates. For details on the GTP protocol, see specification 3G TS 23.060 Technical Specification Group Services and System Aspects; General Packet Radio Service (GPRS); Service Description; Stage 2 (Release 1999), for example in version V3.3.0 of April 2000 of the 3GPP (3rd Generation Partnership Project, www.3GPP. ORG) directed.
Die zwischen den zwei bedienenden Knoten übertragenen Daten ermöglichen es dem zweiten bedienenden Knoten, einen Kontakt zu einem Gateway-Knoten aufzunehmen und sich von dort die be nötigten vollständigen Informationen über den Kontext zu be schaffen, die es ihm ermöglichen, den GTP-Tunnel umzuschal ten, so daß der Dienst für das Endgerät unterbrechungsfrei fortgesetzt werden kann. The data transferred between the two serving nodes enable the second serving node to make a contact to a gateway node and from there the be required complete information about the context create that enable him to switch the GTP tunnel ten, so that the service for the terminal is uninterrupted can continue.
Für das GTP-Protokoll sind bisher zwei Versionen standardi siert, zum einen die GTP-Version 0, auch als Release 98 bzw. 97 bezeichnet, in GSM 09.60; zum anderen GTP-Version 1, auch als Release 99 bezeichnet, in der bereits genannten Veröf fentlichung TS 23.060. Die Standardisierung der Version 1 verlangt, daß Knoten gemäß Version 1 mit solchen nach Version 0 zusammenarbeiten können sollen, und daß die GTP-Tunnel mit der jeweils höchstmöglichen Version betrieben werden.So far, two versions are standard for the GTP protocol based on GTP version 0, also as Release 98 or Designated 97, in GSM 09.60; to the other GTP version 1, too referred to as Release 99, in the aforementioned publication publication TS 23.060. The standardization of version 1 requires version 1 nodes with version 1 nodes 0 should be able to work together, and that the GTP tunnel with the highest possible version.
Damit ein empfangender Knoten die GTP-Version erkennen kann, gemäß der eine empfangene Nachricht erstellt worden ist, tra gen die Nachrichten jeweils im Kopf ein Kennzeichen, das die Zuordnung zur jeweiligen Version ermöglicht. Nachrichten, die gemäß Version 1 erstellt worden sind, sind von Knoten, die nach Version 0 oder noch älteren Standardisierungen arbeiten, nicht interpretierbar. Ein Knoten nach Version 1 muß daher in der Lage sein, je nach GTP-Version, die ein Knoten, an den er Nachrichten sendet, anwendet, diese Nachrichten entweder ge mäß Version 1 oder Version 0 zu erstellen.So that a receiving node can recognize the GTP version, according to which a received message was created, tra the messages each have a flag in their head that indicates the Allocation to the respective version enabled. News that created according to version 1 are of nodes that work according to version 0 or older standardizations, not interpretable. A node according to version 1 must therefore be in be able, depending on the GTP version, the one node to which it is connected Sends messages, applies these messages either according to version 1 or version 0.
Ein wesentlicher Unterschied zwischen Version 0 und Version 1 des GTP-Protokolls ist das Verfahren, nach dem eine Nachricht dem aufgebauten Tunnel beziehungsweise einem PDP-Kontext zu geordnet wird. Bei Version 0 werden hierfür sogenannte Tunnel Identifier, abgekürzt TIDs, verwendet, die als Teil der Nach richt übertragen werden und sich aus der IMSI (International Mobile Subscriber Identity) und dem NSAPI (Network Layer Ser vice Access Point Identifier) zusammensetzen. Die IMSI ist die weltweit eindeutige Kennziffer eines Teilnehmers; der NSAPI referenziert einen von mehreren PDP-Kontexten, die dem Teilnehmer zugeordnet sein können. Da die Tunnel Identifier mit 12 Byte Länge recht unhandlich sind, werden an ihrer Stelle zusätzlich sogenannte Flow Labels mit einer Länge von 2 Byte verwendet, die ein schnelle Zuordnung von Nachrichten zu einem Kontext ermöglichen. Die Flow Labels werden aber nicht unbedingt eindeutig vergeben, da sie nur einen Wertebe reich von ca. 65,000 haben und deutlich mehr Kontexte je Kno ten aufgebaut werden können.A major difference between version 0 and version 1 The GTP protocol is the procedure by which a message is sent the established tunnel or a PDP context is ordered. Version 0 uses so-called tunnels Identifier, abbreviated TIDs, used as part of the After be transferred and derived from the IMSI (International Mobile Subscriber Identity) and the NSAPI (Network Layer Ser vice access point identifier). The IMSI is the worldwide unique identification number of a participant; the NSAPI references one of several PDP contexts that the Participants can be assigned. Because the tunnel identifier with a length of 12 bytes are quite unwieldy, are at their Place additional flow labels with a length of 2 bytes used, which is a fast allocation of messages allow for a context. The flow labels are however not necessarily uniquely assigned, since they only have one value rich of approximately 65,000 and have significantly more contexts per node can be built.
Die Flow Labels werden jeweils bei der Aktivierung eines GTP- Tunnels vergeben; jeder an einem Tunnel beteiligte Knoten teilt dabei dem Gegenknoten mit, mit welchem Flow Label er nachfolgende Nachrichten auf diesem Tunnel oder, was gleich bedeutend ist, für diesen PDP-Kontext, erhalten will. Bei der ersten Nachricht, die im Rahmen des Aufbaus eines Tunnels von einem bedienenden Knoten an einen Gateway-Knoten gesendet wird (Create PDP Context Request) steht das Flow Label auf 0, weil der Gateway-Knoten noch kein Flow Label hat vergeben können, und der Tunnel Identifier wird übertragen; alle nach folgenden Nachrichten dieses Tunnels müssen mit dem vom Gate way-Knoten vergebenen Flow Label gesendet werden. Genau ge nommen werden jeweils zwei Flow Label vergeben, eines für Signalisierung und eines für Daten. Im folgenden wird aber lediglich das Flow Label für Signalisierung betrachtet.The flow labels are activated when a GTP Assign tunnels; each node involved in a tunnel tells the opposite node which flow label it is using subsequent messages on this tunnel or whatever is important for this PDP context. In the first message in the context of building a tunnel of sent to a serving node to a gateway node If (Create PDP Context Request) the flow label is set to 0, because the gateway node has not yet assigned a flow label can, and the tunnel identifier is transmitted; all after following messages of this tunnel must be with that from the gate the flow label assigned to the way node. Exactly Two flow labels are assigned, one for Signaling and one for data. In the following, however only considered the flow label for signaling.
In der GTP-Version 1 werden sogenannte TEID (Tunnel Endpoint Identifier) vergeben, die die gleiche Funktion wie die Flow Labels haben, jedoch eine Länge von 4 Byte besitzen. Die TEID sind daher mit den Flow Labels nach Version 0 nicht kompati bel, sie können aber eindeutig vergeben werden. Der aus der Version 0 bekannte Tunnel Identifier ist in Nachrichten nach Version 1 nicht mehr enthalten. IMSI und NSAPI, die eine ein deutige Zuordnung der Nachricht zu einem PDP-Kontext ermögli chen, sind nur in der ersten Nachricht (Create PDP Context Request) vom bedienenden Knoten an den Gateway-Knoten enthal ten.So-called TEID (Tunnel Endpoint Identifier) which have the same function as the Flow Labels, but have a length of 4 bytes. The TEID are therefore not compatible with the flow labels according to version 0 bel, but they can be clearly assigned. The one from the Version 0 known tunnel identifier is in messages after Version 1 no longer included. IMSI and NSAPI, the one one clear assignment of the message to a PDP context possible are only in the first message (Create PDP Context Request) from the serving node to the gateway node ten.
Innerhalb der jeweiligen Version funktionieren beide Versio nen des GTP einwandfrei. In der Standardisierung ist gefor dert, daß ein Knoten für Version 1 auch die GTP-Version 0 un terstützt, also rückwärtskompatibel ist. Dies ist erforder lich, damit Knoten unterschiedlicher Versionen zusammenarbei ten können.Both versions work within the respective version the GTP properly. Standardization is required changes that a node for version 1 also the GTP version 0 and supported, i.e. is backwards compatible. This is a requirement Lich, so that nodes of different versions work together can.
Es treten jedoch Probleme auf, wenn ein Mobilfunkteilnehmer sich in einem Netz, das Knoten unterschiedlicher Versionen enthält, bewegt und dabei vom Einzugsbereich eines bedienen den Knotens in den eines anderen wechselt. Dieser Wechsel hat ein RAU (Routing Area Update) zur Folge, bei dem ein Tunnel von dem Knoten, in dessen Einzugsbereich sich der Teilnehmer zuvor aufgehalten hat, an den Knoten des neuen Einzugsbe reichs übergeben wird. Im Rahmen dieser Prozedur müssen Daten über den PDP-Kontext vom alten zum neuen Knoten mit Hilfe von GTP-Nachrichten weitergereicht werden. Diese Daten benötigt der neue Knoten, um den Kontakt zum Gateway-Knoten aufzuneh men und den GTP-Tunnel umzuschalten, so daß der Dienst für den Teilnehmer unterbrechungsfrei fortgesetzt werden kann. Wenn alle drei an der Umschaltung des Tunnels beteiligten Knoten der gleichen GTP-Version angehören, ist die Umschal tung unproblematisch. Auch wenn zwei von ihnen Knoten nach Version 0 sind und der dritte ein Knoten nach Version 1 ist, ergeben sich keine Probleme, da sämtliche zwischen den Knoten ausgetauschten Nachrichten solche nach GTP-Version 0 sein müssen. Wenn allerdings zwei Knoten der Version 1 und der dritte der Version 0 angehören, führt die Tatsache, daß die zwei Knoten nach Version 1 untereinander mit Version-1- Nachrichten und mit dem im dritten Knoten mit Version-0- Nachrichten kommunizieren, zu Schwierigkeiten. Drei Fälle sind zu unterscheiden.However, problems arise when a cellular subscriber itself in a network that nodes different versions contains, moves and operate from the catchment area the node changes to that of another. This change has result in a RAU (Routing Area Update), in which a tunnel from the node in whose catchment area the participant is previously stopped at the knot of the new move-in area is handed over. This procedure requires data about the PDP context from the old to the new node with the help of GTP messages are forwarded. This data is needed the new node to contact the gateway node men and switch the GTP tunnel so that the service for the participant can continue without interruption. If all three involved in switching the tunnel The switch belongs to nodes of the same GTP version unproblematic. Even if two of them knot after Are version 0 and the third is a node after version 1, there are no problems since all between the nodes exchanged messages are those according to GTP version 0 have to. However, if two nodes of version 1 and third belong to version 0, the fact that the two nodes after version 1 with each other with version 1- Messages and with that in the third node with version 0 Communicate messages to trouble. Three cases are to be distinguished.
- 1. Der Mobilfunkteilnehmer bewegt sich von einem ersten be dienenden Knoten nach Version 0 zu einem zweiten nach Version 1. Bei dieser Situation muß für die Kommunikation des ersten bedienenden Knotens mit dem zweiten und mit dem Gateway- Knoten GTP-Version 0 benutzt werden; die Kommunikation zwi schen Gateway-Knoten und zweitem bedienenden Knoten findet nach Version 1 statt. Beim Aufbau des Tunnels ordnet der Ga teway-Knoten ein Flow Label zu, welches vom ersten bedienen den Knoten zum Kennzeichnen von zu dem Tunnel gehörenden Nachrichten benutzt wird. Wenn die zwei bedienenden Knoten Kontakt aufnehmen, um die Umlegung des Tunnels vorzubereiten, kommunizieren sie nach Version 0, und der erste bedienende Knoten liefert an den zweiten das Flow Label, das ursprüng lich vom Gateway-Knoten dem Tunnel zugeordnet worden ist. Um die erforderlichen Kontextdaten des Tunnels vom Gateway- Knoten zu erhalten, müßte der zweite bedienende Knoten eine Nachricht mit diesem Flow Label an den Gateway-Knoten schi cken können. Der zweite bedienende Knoten und der Gateway- Knoten kommunizieren jedoch nach Version 1, die die Übertra gung von Flow Labels nicht zuläßt. Anstelle des Flow Labels könnte zwar ein TEID nach Version 1 übertragen werden, doch ist ein solcher im Gateway-Knoten für den Tunnel nicht defi niert. Der Gateway-Knoten kann somit dem bestehenden Kanal keine Nachricht nach GTP-Version 1 zuordnen. Da die Nachricht "Update PDP Context Request" weder IMSI noch NSAPI enthält, ist der Gateway-Knoten auch dann nicht in der Lage, den Kon text zu finden, wenn er den TEID ignoriert.1. The mobile subscriber moves from a first one serving nodes after version 0 to a second after version 1. In this situation, the communication of the first serving node with the second and with the gateway GTP version 0 nodes are used; the communication between gateway gateway and second serving node after version 1 instead. When building the tunnel, the Ga teway node to a flow label, which serve from the first the node for identifying those belonging to the tunnel News is used. If the two serving nodes Contact us to prepare the relocation of the tunnel, communicate according to version 0, and the first operator The second node is supplied with the flow label, which originally Lich assigned to the tunnel by the gateway node. Around the required context data of the tunnel from the gateway To get knots, the second serving knot should have one Send message with this flow label to the gateway node can cick. The second serving node and the gateway However, nodes communicate according to version 1, which is the transfer flow labels is not permitted. Instead of the flow label a TEID version 1 could be transmitted, but such is not defined in the gateway node for the tunnel kidney. The gateway node can thus join the existing channel do not assign a message according to GTP version 1. Because the message "Update PDP Context Request" contains neither IMSI nor NSAPI, the gateway node is then unable to connect the con Find text if he ignores the TEID.
- 2. Der Mobilfunkteilnehmer bewegt sich von einem ersten be dienenden Knoten nach Version 1 zu einem nach Version 0. In diesem Fall ist bei der Kommunikation zwischen dem ersten be dienenden Knoten und dem Gateway-Knoten im Rahmen des Aufbaus des Tunnels GTP-Version 1 verwendet worden, d. h. es ist zwar ein TEID für den Tunnel festgelegt worden, aber kein Flow La bel. Für die Kommunikation zwischen den zwei bedienenden Kno ten muß GTP-Version 0 verwendet werden, diese erlaubt jedoch nur Flow Label. Eine Möglichkeit, den TEID an den zweiten Knoten zu übertragen, besteht nicht, und selbst wenn sie be stünde, könnte dieser sie nicht verarbeiten. Der zweite be dienende Knoten hat daher keine Möglichkeit, die Flow Labels herauszufinden, mit denen er die benötigten Kontextdaten vom Gateway-Knoten anfordern könnte. 2. The mobile subscriber moves from a first one serving nodes according to version 1 to one according to version 0. In In this case, communication between the first be serving nodes and the gateway node as part of the setup the GTP version 1 tunnel has been used, d. H. it is a TEID has been set for the tunnel, but no flow la bel. For communication between the two operating kno GTP version 0 must be used, but this allows flow label only. One way to pass the TEID to the second Transferring nodes does not exist, and even if they are would not be able to process it. The second be serving nodes therefore has no way of using the flow labels find out with which he gets the required context data from Could request gateway nodes.
- 3. Der Mobilfunkteilnehmer bewegt sich von einem bedienen den Knoten nach Version 1 zu einem anderen der gleichen Ver sion, aber der Gateway-Knoten arbeitet nach Version 0. In diesem Fall kommunizieren die bedienenden Knoten untereinan der nach Version 1, mit dem Gateway-Knoten jedoch nach Versi on 0. Der Gateway-Knoten ordnet somit beim Aufbau eines Tun nels ein Flow Label zu, dieses kann jedoch nicht vom ersten an den zweiten Knoten übertragen werden, so daß dieser auch nicht die Kontextinformationen vom Gateway-Knoten abfragen kann.3. The cell phone subscriber moves from a serve the version 1 node to another of the same ver sion, but the gateway node works according to version 0. In in this case, the serving nodes communicate with each other that according to version 1, with the gateway node but according to Versi on 0. The gateway node thus orders when building a tun a flow label, but this cannot be the first are transmitted to the second node, so that it too do not query the context information from the gateway node can.
Die Aufgabe der Erfindung besteht darin, Verfahren zum Umle gen eines Tunnels von einem ersten bedienenden Knoten eines GPRS-Systems auf einen zweiten anzugeben, die auch dann funk tionieren, wenn sich unter den bedienenden Knoten und dem Ga teway-Knoten wenigstens ein Knoten nach Version 0 und andere nach Version 1 des GTP-Protokolls befinden.The object of the invention is methods for Umle towards a tunnel from a first serving node GPRS system to specify a second, which then also radio function when there are operator nodes and Ga teway node at least one node according to version 0 and others according to version 1 of the GTP protocol.
Die Aufgabe wird für den Fall, daß der erste bedienende Kno ten ein Knoten nach Version 0 ist und der zweite bedienende Knoten und der Gateway-Knoten Knoten nach Version 1 sind, durch ein Verfahren nach Anspruch 1 gelöst. Dieses sieht vor, daß die Aufforderung zur Anpassung des Kontexts, die der zweite bedienende Knoten an den Gateway-Knoten richtet, eine Angabe von IMSI und NSAPI des betreffenden Tunnels enthält. Diese Angabe erlaubt es dem Gateway-Knoten, eine eindeutige Entsprechung zu einem gespeicherten Kontext herzustellen und so die benötigten Kontextdaten an den zweiten Knoten zu lie fern.The task is in the event that the first kno ten is a node after version 0 and the second is serving Nodes and the gateway node are version 1 nodes, solved by a method according to claim 1. This provides that the contextual prompt that the second serving node to the gateway node, one Includes the IMSI and NSAPI of the tunnel in question. This specification allows the gateway node to be unique Create correspondence to a stored context and so that the required context data is sent to the second node remote.
Die benötigte Angabe von IMSI und NSAPI kann auf ganz einfa che Weise dadurch übertragen werden, daß der zweite bedienen de Knoten und der Gateway-Knoten den unter Version 0 des GTP- Protokolls aufgebauten Tunnel unter der gleichen Protokoll version weiterbetreiben. In diesem Fall enthält die vom zwei ten Knoten an den Gateway-Knoten zu sendende Aufforderung zur Anpassung des Kontexts, die Nachricht "Update PDP Context Re quest", von vorneherein diese benötigten Angaben. Diese Lö sung beinhaltet also, daß das Protokoll, welches der zweite bedienende Knoten bei der Kommunikation mit dem Gateway- Knoten anwendet, von der Vorgeschichte des Tunnels abhängt, zu denen die ausgetauschten Nachrichten gehören. Wenn ein Tunnel vom zweiten Knoten selber oder von einem anderen Kno ten nach Version 1 aufgebaut worden ist, findet die Kommuni kation mit dem Gateway-Knoten nach Version 1 statt; wurde der Tunnel ursprünglich von einem Knoten nach Version 0 aufge baut, so läuft die Kommunikation mit dem Gateway-Knoten wei terhin nach Version 0, obwohl beide beteiligten Knoten Versi on 1 beherrschen.The required information on IMSI and NSAPI can be summarized in simple terms che way to be transmitted by operating the second de node and the gateway node that is under version 0 of the GTP Protocol built tunnel under the same protocol continue version. In this case, it contains the two Request to send to the gateway node Adaptation of the context, the message "Update PDP Context Re quest ", this required information from the outset solution therefore implies that the protocol, which is the second serving nodes when communicating with the gateway Applies knots, depends on the history of the tunnel, to which the exchanged messages belong. When a Tunnel from the second node itself or from another node has been built according to version 1, the commun cation with the gateway node according to version 1 instead; was the Tunnel originally opened from a node according to version 0 builds, the communication with the gateway node runs white after version 0, although both nodes involved Versi master on 1.
Eine solche Steuerung der verwendeten Version läßt sich auf einfache Weise realisieren, wenn der erste bedienende Knoten zunächst eine dem Tunnelverlegungsvorgang einleitende Nach richt (SGSN Context Response) an den zweiten bedienenden Kno ten sendet, der zweite bedienenden Knoten die Version dieser Nachricht für seine Aufforderung zur Anpassung des Kontexts an den Gateway-Knoten verwendet und dieser alle an ihn ge richteten Nachrichten in der Version beantwortet, in der er sie empfangen hat.Such control of the version used can be easily realize when the first serving node first of all an introduction to the tunnel laying process addressed (SGSN Context Response) to the second serving node ten sends, the second serving node the version of this Message for his request to adapt the context used on the gateway node and this all ge to him addressed messages in the version in which he answered she received.
Eine alternative Möglichkeit ist die, daß der zweite Knoten als Aufforderung zur Anpassung des Tunnels anstelle der her kömmlichen Nachricht "Update PDP Context Request" eine Nach richt vom Typ "Create PDP Context Request" nach Version 1 sendet. Diese Nachricht wird gemäß der oben zitierten Schrift T5 29.060 vom empfangenden Gateway-Knoten richtig verarbei tet, d. h. der bestehende PDP-Kontext wird wiedergefunden und die veränderten Parameter werden ersetzt. Auf diese Weise wird sowohl der Tunnel zum zweiten bedienenden Knoten verlegt als auch in der Version verändert. An alternative possibility is that the second knot as an invitation to adapt the tunnel instead of the ago conventional message "Update PDP Context Request" a post of type "Create PDP Context Request" according to version 1 sends. This message is in accordance with the scripture cited above T5 29.060 correctly processed by the receiving gateway node tet, d. H. the existing PDP context is found and the changed parameters are replaced. In this way the tunnel is moved to the second serving node changed as well in the version.
Weiterhin alternativ kann vorgesehen werden, daß auch die Nachricht "Update PDP Context Request" mit einem TEID gesen det werden kann, der den Wert 0 hat, und die zusätzlich zu dem gemäß TS 23.060 vorgesehenen Informationselementen zu sätzlich IMSI und NSAPI enthält, um eine Zuordnung zu dem entsprechenden PDP-Kontext im Gateway-Knoten zu ermöglichen.Furthermore, it can alternatively be provided that the Message "Update PDP Context Request" sent with a TEID can be detected, which has the value 0, and which in addition to the information elements provided in accordance with TS 23.060 additionally contains IMSI and NSAPI to make an assignment to the enable corresponding PDP context in the gateway node.
In dem Fall, daß der zweite bedienende Knoten oder der Gate way-Knoten ein Knoten nach Version 0 ist und die jeweils an deren Knoten nach Version 1 sind, wird die Aufgabe gelöst durch das Verfahren nach Anspruch 5, bei dem ein Flow Label, das der zweite bedienende Knoten und der Gateway-Knoten benö tigen, um den Tunnel vom ersten auf den zweiten bedienenden Knoten umlegen zu können, dem zweiten vom ersten bedienenden Knoten zur Verfügung gestellt wird.In the event that the second serving node or gate way node is a node according to version 0 and the respective on whose nodes are after version 1, the task is solved by the method according to claim 5, in which a flow label, that the second serving node and the gateway node need to serve the tunnel from the first to the second To be able to knot, the second from the first operator Knot is provided.
Dabei gibt es verschiedene Möglichkeiten, die Zuordnung des Flow Labels vorzunehmen. Wenn der Gateway-Knoten ein Knoten nach Version 1 ist, der Aufbau des Kanals also nach Version 1 stattgefunden hat, dann ist dem Tunnel beim Aufbau nur ein TEID, aber kein Flow Label zugeordnet worden. In diesem Fall ist es zweckmäßigerweise der erste bedienende Knoten, der die Zuordnung eines Flow Labels zum Tunnel vornimmt.There are various ways of assigning the Make flow labels. If the gateway node is a node is after version 1, the structure of the channel is therefore according to version 1 has taken place, then the tunnel is only one during construction TEID, but no flow label has been assigned. In this case it is expediently the first operating node that the Assigns a flow label to the tunnel.
Eine erste Variante sieht vor, daß der erste bedienende Kno ten dem Kontext ein Flow Label mit einem Wert zuordnet, der für die Umleitung eines Tunnels von einem bedienenden Knoten nach Version 1 zu einem bedienenden Knoten nach Version 0 spezifisch ist, d. h. der verschieden ist von allen Flow La bels, die für die Kommunikation von regulär nach Version 0 arbeitenden Knoten verwendet werden. Der zweite bedienende Knoten kann auf den Empfang eines solchen spezifischen Flow Labels reagieren, indem er anstelle einer Nachricht "Update PDP Context Request", die er normalerweise an den Gateway- Knoten senden würde, wenn er ein korrektes Flow Label von ei nem ersten bedienenden Knoten der gleichen Version erhalten hätte, eine Nachricht "Create PDP Context Request" an den Ga teway-Knoten sendet, die IMSI und NSAPI enthält und somit ei ne eindeutige Identifizierung des anzupassenden Kontexts am Gateway-Knoten erlaubt. Alternativ kann auch vorgesehen wer den, daß der zweite bedienende Knoten eine Nachricht "Update PDP Context Request" an den Gateway-Knoten sendet, die aller dings abweichend vom geltenden Protokoll der Version 1 zu sätzlich IMSI und NSAPI enthält und so wiederum eine Identi fizierung zuläßt. Eine solche Vorgehensweise ist möglich, weil die bestehende Norm keine PDP Update Requests mit Flow Label 0 vorsieht und deren Verarbeitung daher nicht normiert ist.A first variant provides that the first operator Kno assigned a flow label to the context with a value that for rerouting a tunnel from a serving node after version 1 to a serving node after version 0 is specific, d. H. which is different from all Flow La bels for communication from regular to version 0 working nodes are used. The second operator Node can be on the receipt of such a specific flow Labels respond by saying "Update PDP Context Request ", which he normally sends to the gateway Node would send if it had a correct flow label from egg received the first serving node of the same version would have sent a message "Create PDP Context Request" to the Ga teway node that contains IMSI and NSAPI and thus ei ne clear identification of the context to be adapted on Gateway nodes allowed. Alternatively, who can be provided that the second serving node receives a message "Update PDP Context Request "to the gateway node that sends all deviates from the applicable protocol of version 1 additionally contains IMSI and NSAPI and thus again an identification permits. Such an approach is possible because the existing standard does not have PDP update requests with flow Provides label 0 and its processing is therefore not standardized is.
Eine zweite Variante des Verfahrens, die ebenfalls dann an wendbar ist, wenn der Gateway-Knoten nach Version 1 und der zweite bedienende Knoten nach Version 0 arbeiten, sieht vor, daß der Gateway-Knoten jedem vom ersten bedienenden Knoten nach Version 1 etablierten Kontext nicht nur eine TEID zuord net, sondern gleichzeitig über ein festgelegtes Verfahren verfügt, nach dem er jedem nach Version 1 etablierten Kontext bzw. genauer gesagt dessen TEID ein Flow Label zuordnen kann. Somit entspricht im Gateway-Knoten jedem nach GTP-Version 1 etablierten Kontext ein TEID und ein Flow Label. Zweckmäßi gerweise kann der Gateway-Knoten bereits bei der Vergabe von TEIDs die daraus resultierenden Flow Labels in dem Sinne be rücksichtigen, daß eine effektive Identifizierung von Kontex ten anhand der Flow Labels möglich ist. Das gleiche Verfahren steht auch dem erSten bedienenden Knoten zur Verfügung. Wenn ein Tunnel, der von dem ersten bedienenden Knoten nach GTP- Version 1 etabliert worden ist, auf einen zweiten bedienenden Knoten nach Version 0 umgelenkt werden muß, so kann der erste bedienende Knoten durch Anwendung des Verfahrens unmittelbar den korrekten Wert des Flow Labels ermitteln und dem zweiten bedienenden Knoten zur Verfügung stellen, anhand dessen der Gateway-Knoten den PDP-Kontext identifizieren kann. Somit kann der zweite bedienende Knoten den Gateway-Knoten in der gleichen Weise ansprechen, als ob er den Tunnel von einem be dienenden Knoten nach Version 0 übergeben bekommen hätte.A second variant of the procedure, which is then also on is reversible if the gateway node according to version 1 and the second operating nodes work after version 0, provides that the gateway node to each of the first serving nodes context established after version 1 not just assign a TEID net, but at the same time using a defined procedure according to which he has any context established after version 1 or more precisely whose TEID can assign a flow label. Thus, in the gateway node, everyone corresponds to GTP version 1 established context a TEID and a flow label. Expedient In some cases, the gateway node can already assign TEIDs the resulting flow labels in the sense be take into account that effective context identification flow labels is possible. The same procedure is also available to the first serving node. If a tunnel leading from the first serving node to GTP Version 1 has been established on a second serving Node must be redirected to version 0, so the first serving nodes by applying the method immediately determine the correct value of the flow label and the second make available the serving node on the basis of which the Gateway node can identify the PDP context. Consequently the second serving node can be the gateway node in the address the same way as if he were the tunnel from a be serving node after version 0.
Ein bevorzugtes, weil besonders einfaches Verfahren zum Zu ordnen des Flow Labels zu einem TEID ist das Gleichsetzen des Flow Labels mit den zwei niederwertigen Bytes des TEID. Wenn hingegen der Gateway Knoten ein Knoten nach Version 0 und die beiden bedienenden Knoten Knoten nach Version 1 sind, so ist die Zuordnung eines Flow Labels zum Tunnel bereits bei dessen Aufbau vom Gateway-Knoten vorgenommen worden, und die ses Flow Label ist dem ersten bedienenden Knoten bekannt. Um dieses Flow Label an den zweiten Knoten - über Version 1- Nachrichten - zu übermitteln, ist es zweckmäßig, es im TEID- Feld einer Version 1-Nachricht zu "verpacken".A preferred method because it is particularly simple to close assigning the flow label to a TEID is equivalent to the Flow labels with the two least significant bytes of the TEID. If, on the other hand, the gateway node is a version 0 node and the two serving nodes are version 1 nodes, the assignment of a flow label to the tunnel is already included its structure was carried out by the gateway node, and the This flow label is known to the first operating node. Around this flow label at the second node - via version 1- Messages - it is advisable to transmit it in the TEID- "Package" field of a Version 1 message.
Da das Flow Label das TEID-Feld nicht ausfüllt, ist es vor teilhaft möglich, den verbleibenden Platz in dem TEID-Feld zur Übertragung eines vorgegebenen Wertes zu nutzen, der an dernfalls in einem TEID nicht vorkommt und an dem der zweite bedienende Knoten daher zu erkennen vermag, daß es sich bei dem übertragenen Wert nicht um einen TEID, sondern um ein "verpacktes" Flow Label handelt, und den Wert dementsprechend korrekt verarbeiten kann. Ein solcher vorgegebener Wert kann z. B. 0 sein.Since the flow label does not fill in the TEID field, it is there partially possible, the remaining space in the TEID field to transfer a predetermined value to the otherwise not in one TEID and on which the second serving nodes can therefore recognize that it is at the transferred value not by a TEID, but by one "packaged" flow label, and the value accordingly can process correctly. Such a predetermined value can e.g. B. 0.
Ausführungsbeispiele werden nachfolgend anhand der Zeichnun gen näher erläutert. Es zeigen:Exemplary embodiments are described below with reference to the drawings gene explained in more detail. Show it:
Fig. 1 bis 3 die möglichen Konstellationen bei der Überga be eines Tunnels zwischen zwei bedienenden Knoten unter Beteiligung von jeweils zwei Knoten nach GTP- Version 1 und einem Knoten nach Version 0; Figs. 1 to 3, the possible constellations in Überga be a tunnel between two controlling nodes involving any two nodes of the GTP version 1 and a node of the Version 0;
Fig. 4 bis 6 den Ablauf der Signalisierung bei der Überga be des Tunnels in den verschiedenen Konstellatio nen. Fig. 4 to 6 the sequence of signaling at the transition of the tunnel in the various constellations.
Bei der Konstellation der Fig. 1 ist der erste bedienende Knoten SGSN1, über den der Tunnel des Endgeräts MS ursprüng lich aufgebaut worden ist, ein Knoten nach GTP-Version 0; er kommuniziert mit dem Gateway-Knoten GGSN und dem zweiten be dienenden Knoten SGSN2 nach GTP-Version 0, d. h. die ausge tauschten Nachrichten sind gekennzeichnet durch Flow Label und TEID. Der Gateway-Knoten GGSN und der zweite bedienende Knoten SGSN2 kommunizieren miteinander nach Version 1 mit durch TEIDs gekennzeichneten Nachrichten.In the constellation of FIG. 1, the first serving node SGSN1, via which the tunnel of the terminal MS was originally set up, is a node according to GTP version 0; it communicates with the gateway node GGSN and the second serving node SGSN2 according to GTP version 0, ie the exchanged messages are identified by flow label and TEID. The gateway node GGSN and the second serving node SGSN2 communicate with one another according to version 1 with messages identified by TEIDs.
Fig. 4 zeigt den Ablauf der Signalisierung zwischen einem Endgerät MS und den drei Knoten SGSN1, SGSN2 und GGSN einer seits beim Aktivieren eines PDP-Kontexts und andererseits bei der Umlegung des GTP-Tunnels. Dabei sind Nachrichten gemäß in GTP-Version 0 durch magere, Nachrichten nach Version 1 durch fette Pfeile dargestellt. Nachrichten, die nicht zwischen Knoten ausgetauscht werden und daher nicht an das GTP-Proto koll gebunden sind wie etwa mit dem Endgerät MS ausgetauschte Nachrichten sind gestrichelt dargestellt. Fig. 4 shows the sequence of signaling between a terminal MS and the three nodes SGSN1, SGSN2 and GGSN on the one hand when activating a PDP context and on the other hand when the GTP tunnel is relocated. Messages in GTP version 0 are represented by lean arrows, messages according to version 1 by bold arrows. Messages that are not exchanged between nodes and are therefore not bound to the GTP protocol, such as messages exchanged with the terminal MS, are shown in dashed lines.
In Schritt 1 sendet das Endgerät MS eine Anforderung zur Ak tivierung eines PDP-Kontexts (Activate PDP Context Request) an den SGSN0, der unter anderem die NSAPI und Art bzw. Quali tät des gewünschten Dienstes spezifiziert. Der bedienende Knoten SGSN1 richtet daraufhin eine Anforderung "Create PDP Context Request" nach PDP-Version 0 an den Gateway-Knoten GGSN, in der die IMSI und NSAPI dem Gateway-Knoten mitgeteilt werden (Schritt 2). Der Gateway-Knoten erzeugt daraufhin ei nen neuen Eintrag in seiner PDP-Kontexttabelle, die es ihm erlaubt, Datenpakete des Endgeräts MS zwischen dem SGSN1 und einem externen, in den Figuren nicht dargestellten PDP- Netzwerk zu routen und Gebühren zu berechnen, und teilt ihm ein Flow Label zu. Als Bestätigung sendet er in Schritt 3 ei ne Nachricht "Create PDP Context Response" zurück an den ers ten bedienenden Knoten SGSN1, die das zugeteilte Flow Label enthält. Der erste bedienende Knoten bestätigt seinerseits die Einrichtung des Kontexts dem Endgerät MS durch eine Nach richt "Activate PDP Context Accept" (Schritt 4).In step 1 , the terminal MS sends a request to activate a PDP context (Activate PDP Context Request) to the SGSN0, which specifies, among other things, the NSAPI and the type or quality of the desired service. The serving node SGSN1 then makes a request "Create PDP Context Request" according to PDP version 0 to the gateway node GGSN, in which the IMSI and NSAPI are communicated to the gateway node (step 2 ). The gateway node then creates a new entry in its PDP context table, which allows it to route data packets of the terminal MS between the SGSN1 and an external PDP network, not shown in the figures, and to charge them, and shares them a flow label too. In step 3, as confirmation, he sends a "Create PDP Context Response" message back to the first serving node SGSN1, which contains the assigned flow label. The first serving node in turn confirms the establishment of the context to the terminal MS by a message "Activate PDP Context Accept" (step 4 ).
Durch das zugeordnete Flow Label ist der SGSN1 in der Lage, Datenpakte des Endgeräts MS, die zu dem neu eingerichteten Kontext gehören, so zu kennzeichnen, daß der Gateway-Knoten GGSN sie von den Datenpakten anderer Endgeräte oder von ande ren Kontexten zugehörigen Datenpaketen des gleichen Endgeräts unterscheiden kann.The assigned flow label enables the SGSN1 to Data packets of the terminal MS, which are related to the newly set up Context belong, so that the gateway node GGSN from the data packets of other devices or from other contexts associated data packets of the same terminal can distinguish.
Der Prozeß des Umlegen eines Tunnels beginnt damit, daß das Endgerät in Schritt 5 eine Aufforderung "Routing Area Update Request" an den zweiten bedienenden Knoten SGSN2 sendet. Die ser Knoten SGSN2 arbeitet nach GTP-Version 1.The process of moving a tunnel begins with the terminal sending a "Routing Area Update Request" to the second serving node SGSN2 in step 5 . This node SGSN2 works according to GTP version 1.
Durch eine Nachricht "SGSN Context Request" nach GTP-Version 0 (Schritt 6) gibt er dem ersten bedienenden Knoten SGSN1 zu nächst bekannt, daß der Kontext übergeben werden soll; der SGSN1 bestätigt dies durch eine Nachricht "SGSN Context Res ponse" (Schritt 7) und beginnt, von dem PDP-Netzwerk kommende und für die Teilnehmerstation MS bestimmte Datenpakete zu puffern. Nachdem im Schritt 8 der neu bedienende Knoten SGSN2 seine Bereitschaft zur Übernahme von Daten durch eine Nach richt "SGSN Context Acknowledge" bestätigt hat, leitet der Knoten SGSN1 die gepufferten Datenpakete in Schritt 9 zum Knoten SGSN2 weiter.With a "SGSN Context Request" message according to GTP version 0 (step 6 ), it first announces to the first serving node SGSN1 that the context is to be transferred; the SGSN1 confirms this with a message "SGSN Context Response" (step 7 ) and begins to buffer data packets coming from the PDP network and intended for the subscriber station MS. After the new serving node SGSN2 has confirmed its readiness to take over data by a message "SGSN Context Acknowledge" in step 8 , the node SGSN1 forwards the buffered data packets in step 9 to the node SGSN2.
Um zu erreichen, daß für die Teilnehmerstation MS bestimmte Datenpakte nicht mehr an SGSN1, sondern direkt an den neuen bedienenden Knoten SGSN2 geroutet werden, muß der Gateway- Knoten GGSN über die Änderung informiert werden. Dies erfolgt durch eine Aufforderung zur Anpassung des Kontexts, die in Schritt 10 vom SGSN2 an den Gateway-Knoten GGSN gesendet wird. In order to ensure that data packets intended for the subscriber station MS are no longer routed to SGSN1, but rather directly to the new serving node SGSN2, the gateway node GGSN must be informed of the change. This is done by a request to adapt the context, which is sent in step 10 from the SGSN2 to the gateway node GGSN.
Während im Falle der Übernahme eines Kontexts von einem be dienenden Knoten der gleichen Version die Aufforderung zur Anpassung des Kontexts eine Nachricht "Update PDP Context Re quest" wäre, verwendet der zweite bedienenden Knoten im hier betrachteten Fall als Aufforderung eine Nachricht vom Typ "Create PDP Context Request". Diese Nachricht enthält im Ge gensatz zur Nachricht "Update PDP Context Request" gemäß GTP- Version 1 IMSI und NSAPI des Endgerätes MS. Der Gateway- Knoten erwartet bei einer Nachricht dieses Typs nicht, daß sie mit einem definierten TEID gesendet wird; er versucht da her nicht, einen solchen TEID der Nachricht zu interpretie ren, sondern er identifiziert den betreffenden Kontext in dem von ihm geführten Verzeichnis direkt anhand von IMSI und NSAPI. Der so gefundene Kontexteintrag wird aktualisiert, in dem ihm der neue bedienende Knoten SGSN2 sowie die GTP- Version zugeordnet wird, nach der die Kommunikation zwischen GGSN und bedienendem Knoten abläuft.While in the case of taking over a context from a be serving nodes of the same version Adapting the context of a message "Update PDP Context Re quest "would be used by the second serving node in here consider a message of the type as a request "Create PDP Context Request". This message contains in Ge sentence to the message "Update PDP Context Request" according to GTP Version 1 IMSI and NSAPI of the MS terminal. The gateway Node does not expect a message of this type to it is sent with a defined TEID; he tries there not to interpret such a TEID of the message but identifies the relevant context in the he maintains a directory based on IMSI and NSAPI. The context entry found in this way is updated in which the new serving node SGSN2 and the GTP Version is assigned, according to which the communication between GGSN and serving node expires.
Wenn der Gateway-Knoten diese Operation erfolgreich ausge führt hat, bestätigt er dies in Schritt 11 dem neuen SGSN2 durch eine Nachricht, die vom Typ "Create PDP Context Respon se" oder "Update PDP Context Response" sein kann.If the gateway node has successfully carried out this operation, it confirms this in step 11 to the new SGSN2 by a message which can be of the type "Create PDP Context Respon se" or "Update PDP Context Response".
Bevor das Endgerät MS in Schritt 18 eine Bestätigung seiner RAU-Anforderung "Routing Area Update Accept" erhält, findet noch ein Nachrichtenaustausch der beiden bedienenden Knoten mit dem Home Location Register HLR des Mobilfunk-Kommunika tionssystems statt, in deren Verlauf die Zuordnung des Endge räts MS zu dem neuen bedienenden Knoten SGSN2 in diesem Re gister vermerkt wird. Diese Schritte unterscheiden sich nicht von den für ein GSM- oder UMTS-Funk-Kommunikation bekannten Schritten und werden deshalb hier nicht eingehend beschrie ben.Before the terminal MS receives a confirmation of its RAU request "Routing Area Update Accept" in step 18 , there is still a message exchange between the two serving nodes with the home location register HLR of the mobile radio communication system, in the course of which the assignment of the terminal device MS to the new serving node SGSN2 is noted in this register. These steps do not differ from the steps known for GSM or UMTS radio communication and are therefore not described in detail here.
Alternativ zur Verwendung der Nachricht "Create PDP Context Request" in Schritt 10 kann auch eine gegenüber der geltenden GTP-Version 1 geringfügig modifizierte Nachricht vom Typ "Up date PDP Context Request" angewendet werden. Diese modifi zierte Nachricht enthält einen TEID mit dem Wert 0 sowie IMSI und NSAPI des Endgeräts MS. Der Gateway-Knoten GGSN vergibt selbst keine TEIDs mit Wert 0. Wenn er einen "Update PDP Con text Request" mit TEID = 0 empfängt, so kann daraus beschlos sen werden, daß der TEID nicht vom Gateway-Knoten GGSN verge ben worden ist und daß ihm somit kein Eintrag im Kontextver zeichnis des GGSN entspricht. Daher greift der GGSN in einen solchem Falle auf IMSI und NSAPI zurück, um den von dem "Up date PDP Context Request" betroffenen Kontext zu identifizie ren und wie oben beschrieben zu aktualisieren.As an alternative to using the "Create PDP Context Request" message in step 10 , a "Up date PDP Context Request" type message that is slightly modified compared to the applicable GTP version 1 can also be used. This modified message contains a TEID with the value 0 and IMSI and NSAPI of the terminal MS. The gateway node GGSN does not assign any TEIDs with a value of 0. If it receives an "Update PDP Con text Request" with TEID = 0, it can be concluded that the TEID has not been assigned by the gateway node GGSN and that no entry in the context directory of the GGSN corresponds to it. In such a case, the GGSN therefore uses IMSI and NSAPI in order to identify the context affected by the "Up date PDP Context Request" and to update it as described above.
Eine weitere Alternative ist, daß der zweite bedienende Kno ten für die Aktualisierungsaufforderung des Schritts 10 je weils diejenige GTP-Version wählt, in der er in Schritt S7 die Nachricht "SGSN Context Acknowledge" erhalten hat, hier also die Version 0. Auf diese Weise gibt er sich dem GGSN ge genüber für den betroffenen Kontext als Version-0-Knoten aus, kann diesem den anzupassenden Kontext durch Angabe eines Flow Labels identifizieren, und erhält vom Gateway-Knoten Antwort nachrichten ebenfalls in Version 0. Auf diese Weise wird der Kontext auf den neuen bedienenden Knoten SGSN2 korrekt umge legt, auch wenn die verwendete GTP-Version die gleiche bleibt.Another alternative is that the second serving node for the update request of step 10 each selects the GTP version in which he received the message "SGSN Context Acknowledge" in step S7, in this case version 0. In this way if it reports to the GGSN as the version 0 node for the context in question, it can identify the context to be adapted by specifying a flow label, and it also receives version 0 reply messages from the gateway node. In this way, the context becomes correctly moved to the new serving node SGSN2, even if the GTP version used remains the same.
Ein zweites Verfahren zum Umlegen des Tunnels vom ersten be dienenden Knoten GGSN1 auf den zweiten GGSN2 unterscheidet sich vom in Fig. 4 gezeigten Signalisierungsablauf dadurch, daß auch der zweite bedienende Knoten in Schritt 10 für seine Aufforderung zur Aktualisierung des Kontexts Version 0 ver wendet, in der er bereits in Schritt 7 das Flow Label des Tunnels erhalten hat. Der Gateway-Knoten antwortet darauf in Schritt 11 ebenfalls unter Verwendung von Version 0. Das heißt obwohl zweiter bedienender Knoten SGSN2 und Gateway- Knoten GGSN Version 1 beherrschen, führen sie den unter Ver sion 0 aufgebauten Tunnel unter Anwendung von Version 0 wei ter.A second method for relocating the tunnel from the first serving node GGSN1 to the second GGSN2 differs from the signaling sequence shown in FIG. 4 in that the second serving node also uses ver in step 10 for its request to update the context version 0 in which he already received the flow label of the tunnel in step 7 . The gateway node also replies to this in step 11 using version 0. That is, although second serving node SGSN2 and gateway node GGSN master version 1, they continue the tunnel built under version 0 using version 0.
Da sich bei diesem zweiten Verfahren die Version des Tunnels beim Umlegen auf den zweiten bedienenden Knoten nicht ändert, sind besondere Vorkehrungen erforderlich, falls der Tunnel ein zweites Mal, auf einen dritten bedienenden Knoten nach Version 1 umgelegt werden muß.Because in this second procedure the version of the tunnel does not change when moving to the second serving node, special precautions are required if the tunnel a second time, after a third serving node Version 1 must be switched.
Bei der Übergabe dieses Version-0-Tunnels von einem zweiten an einen dritten bedienenden Knoten, die beide Version 1 an wenden, stellen sich die gleichen Probleme wie in dem Fall, daß ein zwischen einem ersten bedienenden Knoten nach Version 1 und einem Gateway-Knoten nach Version 0 aufgebauter Tunnel an einen zweiten bedienenden Knoten nach Version 1 umgelegt werden muß. Einige der an späterer Stelle beschriebenen Lö sungen dieses Problems sind daher auch auf diesen Fall an wendbar.When this version 0 tunnel is handed over by a second to a third serving node, both of which are version 1 the same problems as in the case that one between a first serving node by version 1 and a gateway node built according to version 0 transferred to a second serving node according to version 1 must become. Some of the Lö described later Solutions to this problem are therefore also relevant to this case reversible.
Fig. 2 zeigt eine Konfiguration, in der ein erster Knoten SGSN1 nach GTP-Version 1, ein Gateway-Knoten GGSN nach GTP- Version 1 und ein zweiter bedienender Knoten SGSN2 nach Ver sion 0 miteinander kommunizieren. Der erste bedienende Knoten SGSN1 und der Gateway-Knoten GGSN verwenden untereinander al so durch Tunnel Endpoint Identifier TEID gekennzeichnete Nachrichten nach Version 1, die zwei bedienenden Knoten SGSN1 und SGSN2 verwenden untereinander durch Flow Labels und TEID gekennzeichnete Nachrichten nach Version 0. Fig. 2 shows a configuration in which a first node SGSN1 version of the GTP version 1, a gateway node GGSN to the GTP version 1 and a second controlling node SGSN2 according to United 0 communicate with each other. The first serving node SGSN1 and the gateway node GGSN use messages that are identified by tunnel endpoint identifier TEID according to version 1, the two serving nodes SGSN1 and SGSN2 use messages identified by flow labels and TEID according to version 0.
Die Reihenfolge der Schritte zum Aufbauen und Umlegen des Tunnels, die in Fig. 5 dargestellt ist, entspricht der von Fig. 4. Allerdings sind die für die verschiedenen Nachrich ten verwendeten GTP-Versionen, wiederum durch dicke und dünne Pfeile gekennzeichnet, unterschiedlich. Die Kontextanforde rung "Create PDP Context Request" und die Antwort darauf in den Schritten 2 und 3 entsprechen in ihrer Zielsetzung denen von Fig. 4, allerdings mit dem Unterschied, daß für sie GTP- Version 1 eingesetzt wird, und daß infolgedessen der Gateway- Knoten GGSN dem Kontext einen Tunnel Endpoint Identifier TEID zuordnet und diesen an den ersten bedienenden Knoten SGSN1 zurückmeldet.The sequence of steps for building and transferring the tunnel, which is shown in Fig. 5, corresponding to that of Fig. 4. However, the GTP versions th used for the various Nachrich, in turn, characterized by thick and thin arrows, different. The context request "Create PDP Context Request" and the answer to it in steps 2 and 3 correspond in their objectives to those of FIG. 4, with the difference, however, that GTP version 1 is used for them and that the gateway Node GGSN assigns a context to a tunnel endpoint identifier TEID and reports this back to the first serving node SGSN1.
Die Anforderung "SGSN Context Request" nach GTP-Version 0, die der zweite bedienende Knoten SGSN2 in Schritt 6 an der ersten richtet, wird von diesem mit einem "SGSN Context Res ponse" nach Version 0 beantwortet. Bei einer rein nach Versi on 0 ablaufenden Kanalumlegung enthielte diese Nachricht in ihrem Informationselement (IE) "PDP Context" ein vom Gateway- Knoten an den ersten bedienenden Knoten für diesen Kontext vergebenes Flow Label. Da hier ein solches Flow-Label nicht existiert, wird stattdessen im ersten bedienenden Knoten ein Flow Label nach einem vorab festgelegten Verfahren aus dem vom Gateway-Knoten GGSN vergebenen TEID berechnet ist. Ein besonders einfaches Verfahren zur Berechnung des Flow Labels ist, jeweils die zwei niederwertigen Bytes eines TEID als Flow Label zu verwenden und die zwei höherwertigen zu ver nachlässigen. Dieses Flow Label wird vom zweiten bedienenden Knoten SGSN2 in seiner in Schritt 10 an den Gateway-Knoten gerichteten Aufforderung zur Kontextanpassung verwendet. Da dem Gateway-Knoten GGSN das Verfahren "bekannt" ist, nach dem der erste bedienende Knoten GGSN1 Flow Labels aus TEIDs er zeugt, kann er bei Empfang des entsprechenden Flow Labels in einer Aufforderung zur Kontextaktualisierung in Schritt 10 vom zweiten bedienenden Knoten leicht eine geringe Zahl von Kontexten in seinem Verzeichnis ausfindig machen, die von der Aktualisierung betroffen sein könnten. Unter diesen den tat sächlichen Betroffenen zu ermitteln, ist dann ohne weiteres möglich.The "SGSN Context Request" according to GTP version 0, which the second serving node SGSN2 directs to the first in step 6 , is answered by this with a "SGSN context response" according to version 0. In the case of a channel change purely according to version 0, this message would contain in its information element (IE) "PDP Context" a flow label assigned by the gateway node to the first serving node for this context. Since such a flow label does not exist here, a flow label is instead calculated in the first serving node according to a predetermined method from the TEID assigned by the gateway node GGSN. A particularly simple method for calculating the flow label is to use the two least significant bytes of a TEID as the flow label and to neglect the two more significant ones. This flow label is used by the second serving node SGSN2 in its request to the gateway node in step 10 for context adaptation. Since the gateway node GGSN is "familiar" with the method according to which the first serving node GGSN1 generates flow labels from TEIDs, it can easily receive a small one from the second serving node upon receipt of the corresponding flow label in a request for context update in step 10 Find the number of contexts in its directory that could be affected by the update. It is then easily possible to determine the actual victims among these.
Eine andere Möglichkeit, den Kontext zu aktualisieren, ist die Verwendung von Flow Labels mit dem Wert 0, ähnlich wie oben mit Bezug auf Fig. 4 beschrieben. Da Flow Labels mit diesem Wert ansonsten nicht vergeben bzw. allenfalls von ei nem bedienenden Knoten nach Version 0 in Nachrichten vom Typ "Create PDP Context Request" verwendet werden, bei denen ein Flow Label des Tunnels zum Zeitpunkt des Sendens der Nach richt noch nicht bekannt ist, kann der Gateway-Knoten GGSN, wenn er vom zweiten bedienenden Knoten SGSN2 eine Nachricht mit einem solchen Flow Label mit Wert 0 empfängt, daraus fol gern, daß das Flow Label nicht von ihm selbst vergeben worden sein kann und daß deshalb eine Zuordnung der Nachricht zu ei nem Tunnel unter Vernachlässigung des Flow Labels und unter Verwendung von mitübertragener Identifizierungsinformation, das heißt der im TID im Kopf der Nachricht enthaltenen IMSI und NSAPI des Endgeräts, stattfinden muß.Another possibility to update the context is to use flow labels with the value 0, similar to that described above with reference to FIG. 4. Since flow labels with this value are not otherwise assigned or are used by a serving node according to version 0 in messages of the type "Create PDP Context Request", for which a flow label of the tunnel was not yet known at the time the message was sent If the gateway node GGSN receives a message with such a flow label with the value 0 from the second serving node SGSN2, it can be concluded that the flow label cannot have been assigned by itself and that an assignment of the Message to a tunnel, neglecting the flow label and using the transmitted identification information, that is, the IMSI and NSAPI of the terminal device contained in the TID in the header of the message.
Als weitere Alternative kann noch eine Ergänzung von GTP- Version 0 vorgesehen werden, bei der der zweite bedienenden Knoten SGSN2 eine Nachricht vom Typ "Create PDP Context Re quest" sendet, wenn er vom ersten bedienenden Knoten eine Nachricht mit auf 0 gesetztem Flow Label erhält.As a further alternative, an addition to GTP Version 0 will be provided, with the second operator Node SGSN2 a message of the type "Create PDP Context Re quest "sends when it receives one from the first serving node Received message with flow label set to 0.
Bei der in Fig. 3 gezeigten dritten Konstellation sind beide bedienenden Knoten SGSN1 und SGSN2 Knoten nach GTP-Version 1 und der Gateway-Knoten GGSN ist ein Knoten nach Version 0. Der Aufbau des Tunnels und seine Übergabe vom ersten bedie nenden Knoten SGSN1 an den zweiten SGSN2 sind in Fig. 6 ge zeigt. Der Aufbau des Tunnels in den Schritten 1 bis 4 läuft genauso ab wie mit Bezug auf Fig. 1 und 4 beschrieben. Un tereinander müssen die zwei bedienenden Knoten Version 1 an wenden. Um das zwischen bedienendem Knoten SGSN1 und Gateway- Knoten GGSN ausgehandelte Flow Label an den zweiten bedienen den Knoten SGSN2 zu übertragen, muß es also über eine Verbin dung der Version 1 befördert werden. Um dieses Flow Label zum zweiten bedienenden Knoten SGSN2 zu befördern, ergänzt es der erste bedienende Knoten SGSN1 um zwei höherwertige Bytes auf das Format eines TEID, der in Schritt 7 (SGSN Context Respon se) an den zweiten Knoten SGSN2 übermittelt wird. In the third constellation shown in FIG. 3, both serving nodes SGSN1 and SGSN2 are nodes according to GTP version 1 and the gateway node GGSN is a node according to version 0. The construction of the tunnel and its transfer from the first operating node SGSN1 to second SGSN2 are shown in FIG . The construction of the tunnel in steps 1 to 4 proceeds in exactly the same way as described with reference to FIGS. 1 and 4. The two serving nodes must use version 1 among themselves. In order to transmit the flow label negotiated between serving node SGSN1 and gateway node GGSN to the second serving node SGSN2, it must therefore be transported via a version 1 connection. In order to convey this flow label to the second serving node SGSN2, the first serving node SGSN1 adds two higher order bytes to the format of a TEID, which is transmitted in step 7 (SGSN context response) to the second node SGSN2.
Einer ersten Variante des Verfahrens zufolge werden anschlie ßend zwei in Fig. 6 als gestrichelte Pfeile dargestellte Nachrichten ausgetauscht: Der Knoten SGSN sendet in Schritt 10' eine Aufforderung zur Kontextanpassung (Update PDP Con text Request) nach Version 1 an den Gateway-Knoten GGSN. Da dieser nur Version 0 beherrscht, signalisiert er dem zweiten Knoten SGSN2 (Schritt 10"), daß er die Aufforderung nicht verarbeiten kann. Daran erkennt der zweite Knoten, daß der Gateway-Knoten eine Version-0-Nachricht mit einem Flow-Label benötigt, und erzeugt daraufhin in Schritt 10 eine neue Auf forderung, diesmal nach Version 0, in die sie die zwei niedrigerwertigen Bytes des vom ersten Knoten SGSN1 empfange nen TEID als Flow Label einfügt.According to a first variant of the method, two messages shown as dashed arrows in FIG. 6 are then exchanged: In step 10 ', the node SGSN sends a request for context adaptation (update PDP text request) according to version 1 to the gateway node GGSN. Since the latter only supports version 0, it signals the second node SGSN2 (step 10 ") that it cannot process the request. The second node then recognizes that the gateway node needs a version 0 message with a flow label , and then generates a new request in step 10 , this time after version 0, into which it inserts the two lower-order bytes of the TEID received from the first node SGSN1 as a flow label.
Einer zweiten Variante zufolge verwendet der erste bedienende Knoten SGSN1 zwei Bytes mit einem vorgegebenen Wert, um das dem Tunnel zugeteilte Flow Label auf das Format eines TEID zu ergänzen. Dieser vorgegebene Wert, hier 0, sollte dann bei der normalen Erzeugung eines PDP Kontexts der Version 1 nicht vergeben werden, so daß der zweite bedienende Knoten SGSN2 an dem Wert dieser 2 Bytes erkennen kann, daß es sich bei der in Schritt 7 im Format eines TEID an ihn übertragenen Informati on in Wirklichkeit um ein Flow Label handelt, dieses wieder herstellt und somit für die Aufforderung zur Aktualisierung des Kontexts in Schritt 10 von vorneherein das von dem Gate way-Knoten GGSN interpretierbare Nachrichtenformat der Versi on 0 wählen kann.According to a second variant, the first serving node SGSN1 uses two bytes with a predetermined value in order to supplement the flow label allocated to the tunnel to the format of a TEID. This specified value, here 0, should then not be assigned during the normal generation of a PDP context of version 1, so that the second serving node SGSN2 can recognize from the value of these 2 bytes that it is in step 7 in the format of a TEID the information transferred to it is actually a flow label, restores it and can therefore choose the message format of version 0 that can be interpreted by the gateway node GGSN from the start for the request to update the context in step 10 .
Da bei dieser zweiten Variante die vom zweiten bedienenden Knoten SGSN2 für die Aktualisierungsaufforderung verwendete Version nicht im Dialog zwischen zweitem Knoten SGSN2 und Ga teway-Knoten GGSN von letzterem festgelegt wird, sondern durch die Version der Nachricht SGSN Context Response be stimmt ist, eignet sich diese Variante auch für den oben be reits angesprochenen Fall, daß ein Tunnel, der ursprünglich zwischen einem bedienenden Knoten SGSN1 nach Version 0 und einem Version-1-GGSN aufgebaut und dann zu einem zweiten be dienenden Knoten SGSN2 nach Version 1 unter Beibehaltung ur sprünglich für den Tunnel verwendeten Protokollversion an ei nen dritten bedienenden Knoten nach Version 1 umgelegt wird.Since in this second variant the one operating from the second Node SGSN2 used for the update request Version not in dialog between second node SGSN2 and Ga teway node GGSN is set by the latter, but by the version of the SGSN Context Response message is true, this variant is also suitable for the above already mentioned case that a tunnel that was originally between a serving node SGSN1 according to version 0 and built a version 1 GGSN and then be to a second serving node SGSN2 after version 1 while maintaining ur protocol version originally used for the tunnel to ei a third serving node is moved to version 1.
Gemäß einer dritten Variante kann die in Schritt 7 zu über tragende Kontextinformation auch dahingehend erweitert wer den, daß sowohl Flow Labels als auch TEID transportiert wer den können, jeweils als solche gekennzeichnet. Dies kann durch Hinzufügen eines zusätzlichen Datenfeldes zu der Kon textinformation erfolgen, die das Flow Label aufnimmt, so daß, wenn bekannt, sowohl TEID als auch Flow Label an den zweiten bedienenden Knoten SGSN2 übergeben werden können. Denkbar ist auch die Hinzufügung eines einfachen Flags, des sen Status den Inhalt des TEID-Feldes einer Nachricht als TEID oder als Flow Label kennzeichnet. Damit ist der Wertebe reich für TEID nicht eingeschränkt.According to a third variant, the context information to be transmitted in step 7 can also be expanded so that both flow labels and TEID can be transported, each identified as such. This can be done by adding an additional data field to the context information that the flow label contains, so that, if known, both TEID and flow label can be transferred to the second serving node SGSN2. It is also conceivable to add a simple flag whose status identifies the content of the TEID field of a message as a TEID or as a flow label. This means that the range of values for TEID is not restricted.
Auch diese dritte Variante ist für die Umlegung eines unter Version 0 betriebenen Tunnels an einen dritten bedienenden Knoten nach Version 1 geeignet.This third variant is also for transferring an under Version 0 operated tunnels to a third operator Suitable for version 1 nodes.
Eine vierte Möglichkeit ist, auch zwischen den bedienenden Knoten GTP-Version 0 anzuwenden. Zwar beginnt der zweite be dienende Knoten GGSN2 den Dialog mit dem ersten Knoten SGSN1 mit GTP Version 1, was der erste Knoten (SGSN1) versteht; er müßte daher normalerweise mit GTP Version 1 antworten. Indem jedoch der erste Knoten SGSN1 "Nichtverstehen" der GTP Versi on 1 Nachricht vortäuscht, veranlaßt er den zweiten bedienen den Knoten SGSN2, Version 0 zu verwenden, so daß das Flow La bel übertragen werden kann. Auch diese Variante erlaubt die Umlegung eines Version-0-Tunnels unter Beibehaltung der Ver sion an einen dritten bedienenden Knoten.A fourth option is also between the operators Apply node GTP version 0. The second begins serving nodes GGSN2 the dialogue with the first node SGSN1 with GTP version 1 what the first node (SGSN1) understands; he would normally have to answer with GTP version 1. By doing however the first node SGSN1 "Do not understand" the GTP Versi pretends 1 message, causes the second to serve to use the node SGSN2, version 0, so that the flow La bel can be transferred. This variant also allows the Relocation of a version 0 tunnel while maintaining ver sion to a third serving node.
Claims (17)
Priority Applications (11)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| DE10038182A DE10038182C2 (en) | 2000-05-16 | 2000-08-04 | Procedure for laying a tunnel between nodes of a GPRS system |
| AT01944918T ATE272301T1 (en) | 2000-05-16 | 2001-05-09 | METHOD FOR TURNING A TUNNEL BETWEEN NODES OF A GPRS SYSTEM |
| DE50103011T DE50103011D1 (en) | 2000-05-16 | 2001-05-09 | METHOD FOR FOLDING A TUNNEL BETWEEN NODES OF A GPRS SYSTEM |
| ES01944918T ES2225563T3 (en) | 2000-05-16 | 2001-05-09 | PROCEDURE TO TRANSFER A TUNNEL BETWEEN NODES OF A GPRS SYSTEM. |
| CA002408993A CA2408993C (en) | 2000-05-16 | 2001-05-09 | Method for transferring a tunnel between nodes in a gprs system |
| US10/276,730 US7283497B2 (en) | 2000-05-16 | 2001-05-09 | Method for transferring a tunnel between nodes in GPRS system |
| CNB018096875A CN1225939C (en) | 2000-05-16 | 2001-05-09 | Method for transferring tunnel between nodes in GPRS system |
| EP01944918A EP1282997B1 (en) | 2000-05-16 | 2001-05-09 | Method for transferring a tunnel between nodes in a gprs system |
| PCT/DE2001/001757 WO2001089232A2 (en) | 2000-05-16 | 2001-05-09 | Method for transferring a tunnel between nodes in a gprs system |
| TW090111644A TW525397B (en) | 2000-05-16 | 2001-05-15 | Method to transfer a tunnel between nodes of a GPRS system |
| HK04100006A HK1057303A1 (en) | 2000-05-16 | 2004-01-02 | Method for transferring a tunnel between nodes in a gprs system |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| DE10023963 | 2000-05-16 | ||
| DE10038182A DE10038182C2 (en) | 2000-05-16 | 2000-08-04 | Procedure for laying a tunnel between nodes of a GPRS system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| DE10038182A1 true DE10038182A1 (en) | 2001-12-20 |
| DE10038182C2 DE10038182C2 (en) | 2002-10-24 |
Family
ID=7642260
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| DE10038182A Expired - Fee Related DE10038182C2 (en) | 2000-05-16 | 2000-08-04 | Procedure for laying a tunnel between nodes of a GPRS system |
| DE50103011T Expired - Fee Related DE50103011D1 (en) | 2000-05-16 | 2001-05-09 | METHOD FOR FOLDING A TUNNEL BETWEEN NODES OF A GPRS SYSTEM |
Family Applications After (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| DE50103011T Expired - Fee Related DE50103011D1 (en) | 2000-05-16 | 2001-05-09 | METHOD FOR FOLDING A TUNNEL BETWEEN NODES OF A GPRS SYSTEM |
Country Status (2)
| Country | Link |
|---|---|
| DE (2) | DE10038182C2 (en) |
| ZA (1) | ZA200209264B (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1392036A1 (en) * | 2002-08-22 | 2004-02-25 | TeliaSonera Finland Oyj | Data transmission method and arrangement |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO1997026739A1 (en) * | 1996-01-15 | 1997-07-24 | Nokia Telecommunications Oy | Packet radio network with charging information collected by nodes and forwarded to billing centre |
| WO1998059505A1 (en) * | 1997-06-20 | 1998-12-30 | Telefonaktiebolaget Lm Ericsson (Publ) | Data packet radio service with enhanced mobility management |
| WO1999016266A1 (en) * | 1997-09-25 | 1999-04-01 | Telefonaktiebolaget Lm Ericsson (Publ) | Selectable packet-switched and circuit-switched services in a mobile communications network |
| WO2000005909A1 (en) * | 1998-07-21 | 2000-02-03 | Nokia Telecommunications Oy | Method and apparatus for the transmission of packets of data |
| WO2000014981A1 (en) * | 1998-09-09 | 2000-03-16 | Telia Ab (Publ) | Procedure to obtain a communication route between a transmitting computer and a mobile gprs-node via ggsn |
| WO2000018154A2 (en) * | 1998-09-21 | 2000-03-30 | Nokia Networks Oy | Ip mobility mechanism for a packet radio network |
-
2000
- 2000-08-04 DE DE10038182A patent/DE10038182C2/en not_active Expired - Fee Related
-
2001
- 2001-05-09 DE DE50103011T patent/DE50103011D1/en not_active Expired - Fee Related
-
2002
- 2002-11-14 ZA ZA200209264A patent/ZA200209264B/en unknown
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO1997026739A1 (en) * | 1996-01-15 | 1997-07-24 | Nokia Telecommunications Oy | Packet radio network with charging information collected by nodes and forwarded to billing centre |
| WO1998059505A1 (en) * | 1997-06-20 | 1998-12-30 | Telefonaktiebolaget Lm Ericsson (Publ) | Data packet radio service with enhanced mobility management |
| WO1999016266A1 (en) * | 1997-09-25 | 1999-04-01 | Telefonaktiebolaget Lm Ericsson (Publ) | Selectable packet-switched and circuit-switched services in a mobile communications network |
| WO2000005909A1 (en) * | 1998-07-21 | 2000-02-03 | Nokia Telecommunications Oy | Method and apparatus for the transmission of packets of data |
| WO2000014981A1 (en) * | 1998-09-09 | 2000-03-16 | Telia Ab (Publ) | Procedure to obtain a communication route between a transmitting computer and a mobile gprs-node via ggsn |
| WO2000018154A2 (en) * | 1998-09-21 | 2000-03-30 | Nokia Networks Oy | Ip mobility mechanism for a packet radio network |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1392036A1 (en) * | 2002-08-22 | 2004-02-25 | TeliaSonera Finland Oyj | Data transmission method and arrangement |
Also Published As
| Publication number | Publication date |
|---|---|
| DE50103011D1 (en) | 2004-09-02 |
| DE10038182C2 (en) | 2002-10-24 |
| ZA200209264B (en) | 2003-10-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP1282997B1 (en) | Method for transferring a tunnel between nodes in a gprs system | |
| DE69828572T2 (en) | METHOD AND DEVICE FOR DEFLECTING A CONNECTION IN A CONNECTION IN A REMOTE DETECTOR NETWORK WITH A VARIETY OF NETWORK ELEMENTS | |
| EP1252787B1 (en) | Method for operating a mobile radiotelephone network | |
| DE69922188T2 (en) | Optimization of routing area update in standby mode for multi-system packet radio networks | |
| DE10302788B4 (en) | Device and method for rearranging TFTs in a mobile communication system | |
| DE60216791T2 (en) | ADDRESS TRANSFER AND CORRELATION OF MESSAGES BETWEEN NETWORK NODES | |
| DE60218992T2 (en) | Method and apparatus for data broadcasting in third generation networks | |
| DE19742681C2 (en) | GPRS subscriber selection from several Internet service providers | |
| DE69923673T2 (en) | RAU optimization for UMTS in the URA state | |
| DE60003525T2 (en) | TRANSMISSION OF QUALITY SERVICE IMAGE INFORMATION IN A PACKET RADIO | |
| DE19832290B4 (en) | Communication system and method for establishing connections between terminals of a first and a second communication network | |
| DE60001466T2 (en) | SRNS LAYING IN A UMTS NETWORK | |
| DE60030404T2 (en) | Procedures for passing on real-time connections in wireless communication systems | |
| DE60133754T2 (en) | COMMUNICATION SYSTEM THAT SUPPORTS THE WIRELESS TRANSMISSION OF PACKAGE DATA AND METHOD AND ARRANGEMENT THEREFOR | |
| EP1077556B1 (en) | Data communication between a first mobile switching center of a first wireless communication system and a second mobile switching center of a second wireless communication system | |
| DE10246679A1 (en) | Reassignment procedure for a distributed GGSN system | |
| EP1391081A2 (en) | Heterogeneous mobile radio system | |
| DE10008148A1 (en) | Operating method for mobile radio network involves passing failure message from first link control layer protocol unit after receiving a confirmation message from second protocol unit | |
| DE112004000040T5 (en) | Method and system for generating IP addresses of access terminals and sending messages for the generation of IP addresses in an IP system | |
| WO2003009624A1 (en) | Method for carrying out a qos-oriented handoff between a first and a second ip-based, especially mobile ipv6-based, communication path, between a mobile node (mn) and a correspondent node (cn) | |
| DE60316032T2 (en) | SEAMLESS CHANGE OF THE RADIO ACCESS NETWORK DEPENDING ON THE REQUIRED SERVICE QUALITY (QOS) | |
| EP2387261B1 (en) | Provision of an end-to-end connection from a terminal to a network | |
| WO2007025905A1 (en) | Communications system, switching node computer and method for determining a control node | |
| DE60222419T2 (en) | METHOD FOR ADJUSTING THE BANDWIDTH OF A CONNECTION IN A TELECOMMUNICATIONS NETWORK | |
| EP1364549B1 (en) | Method for relocating the diversity point of a mobile station in a radio access network |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| OP8 | Request for examination as to paragraph 44 patent law | ||
| D2 | Grant after examination | ||
| 8364 | No opposition during term of opposition | ||
| 8327 | Change in the person/name/address of the patent owner |
Owner name: NOKIA SIEMENS NETWORKS GMBH & CO.KG, 81541 MUE, DE |
|
| R119 | Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee |
Effective date: 20110301 |