EP1282997A2 - Method for transferring a tunnel between nodes in a gprs system - Google Patents

Method for transferring a tunnel between nodes in a gprs system

Info

Publication number
EP1282997A2
EP1282997A2 EP01944918A EP01944918A EP1282997A2 EP 1282997 A2 EP1282997 A2 EP 1282997A2 EP 01944918 A EP01944918 A EP 01944918A EP 01944918 A EP01944918 A EP 01944918A EP 1282997 A2 EP1282997 A2 EP 1282997A2
Authority
EP
European Patent Office
Prior art keywords
node
version
tunnel
nodes
sgsn2
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
Application number
EP01944918A
Other languages
German (de)
French (fr)
Other versions
EP1282997B1 (en
Inventor
Hans Müller
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens AG
Original Assignee
Siemens AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from DE10038182A external-priority patent/DE10038182C2/en
Application filed by Siemens AG filed Critical Siemens AG
Publication of EP1282997A2 publication Critical patent/EP1282997A2/en
Application granted granted Critical
Publication of EP1282997B1 publication Critical patent/EP1282997B1/en
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

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
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • 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
    • H04W36/125—Reselecting a serving backbone network switching or routing node involving different types of service backbones
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/20—Manipulation of established connections
    • H04W76/22—Manipulation of transport tunnels
    • 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/08—Protocols for interworking; Protocol conversion
    • 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]
    • 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

Definitions

  • the present invention relates to methods for moving a tunnel from a first serving node of a GPRS system (General Packet Radio Service) to a second.
  • GPRS system General Packet Radio Service
  • Moving a tunnel is necessary if a mobile device that uses the tunnel in question 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 about the PDP context of the terminal device is passed on from the first to the second serving node.
  • RAU Recording Area Update
  • 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.
  • the data transmitted between the two serving nodes enables the second serving node to contact a gateway node and from there to obtain the required complete information about the context which enables it to switch the GTP tunnel so that the service for the terminal can continue without interruption.
  • GTP version 1 also known as Release 98 or 97, in GSM 09.60
  • GTP version 1 also referred to as Release 99, in the aforementioned publication TS 23.060.
  • the standardization of version 1 requires that nodes according to version 1 should be able to work with those according to version 0 and that the GTP tunnels are operated with the highest possible version.
  • the messages each have an identifier in the header that enables the assignment to the respective version.
  • Messages created according to version 1 cannot be interpreted by nodes that work according to version 0 or older standardizations.
  • a version 1 node must therefore be able to create either version 1 or version 0 messages, depending on the GTP version a node to which it is sending messages.
  • Version 0 uses so-called tunnel identifiers, abbreviated TIDs, which are transmitted as part of the message and are composed of the IMSI (International Mobile Subscriber Identity) and the NSAPI (Network Layer Service Access Point Identifier).
  • IMSI International Mobile Subscriber Identity
  • NSAPI Network Layer Service Access Point Identifier
  • the IMSI is the worldwide unique identification number of a participant; the NSAPI references one of several PDP contexts that can be assigned to the participant. Since the tunnel identifiers with a length of 12 bytes are rather unwieldy, so-called flow labels with a length of 2 bytes are used in their place, which enable messages to be quickly assigned to a context. However, the flow labels are not necessarily assigned clearly because they only 65,000 and have significantly more contexts per node.
  • the flow labels are assigned when a GTP tunnel is activated; each node involved in a tunnel informs the opposite node of the flow label with which it wants to receive subsequent messages on this tunnel or, which is synonymous for this PDP context.
  • the flow label For the first message that is sent from a serving node to a gateway node during the establishment of a tunnel (Create PDP Context Request), the flow label is set to 0 because the gateway node has not yet been able to assign a flow label, and the tunnel identifier is transmitted; all subsequent messages in this tunnel must be sent with the flow label assigned by the gateway node.
  • two flow labels are assigned, one for signaling and one for data. In the following, however, only the flow label for signaling is considered.
  • TEID tunnel Endpoint Identifier
  • IMSI and NSAPI which enable the message to be clearly assigned to a PDP context, are only contained in the first message (Create PDP Context Request) from the serving node to the gateway node.
  • both versions of the GTP work perfectly. Standardization requires that a node for version 1 also support GTP version 0, ie it is backwards compatible. This is required lent so nodes of different versions can work together.
  • the mobile subscriber moves from a first serving node according to version 0 to a second serving according to version 1.
  • GTP version 0 must be used for the communication of the first serving node with the second and with the gateway node; the communication between the gateway node and the second serving node takes place according to version 1.
  • the teway node to a flow label, which is used by the first serving node to identify messages belonging to the tunnel.
  • the two serving nodes contact to prepare for the relocation of the tunnel, they communicate according to version 0, and the first serving node supplies the second with the flow label that was originally assigned to the tunnel by the gateway node.
  • the second serving node In order to receive the necessary context data of the tunnel from the gateway node, the second serving node should be able to send a message with this flow label to the gateway node. However, the second serving node and the gateway node communicate according to version 1, which does not allow the transfer of flow labels. Instead of the flow label, a TEID according to version 1 could be transmitted, but one is not defined in the gateway node for the tunnel. The gateway node can therefore not assign a message according to GTP version 1 to the existing channel. Since the message “Update PDP Context Request * contains neither IMSI nor NSAPI, the gateway node is not able to find the context even if it ignores the TEID.
  • the mobile radio subscriber moves from a first serving node according to version 1 to one according to version 0.
  • GTP version 1 is used for the communication between the first serving node and the gateway node in the course of setting up the tunnel been, ie a TEID has been set for the tunnel, but no flow label.
  • GTP version 0 must be used for communication between the two serving nodes, but this only allows flow labels.
  • Transferring nodes does not exist, and even if it existed, it could not process them.
  • the second serving node therefore has no way of finding out the flow labels with which it could request the required context data from the gateway node.
  • the mobile subscriber moves from a serving node according to version 1 to another of the same version, but the gateway node works according to version 0.
  • the serving nodes communicate with each other according to version 1, but with the gateway node according to version 0.
  • the gateway node thus assigns a flow label when a tunnel is set up, but this cannot be transferred from the first to the second node, so that it cannot query the context information from the gateway node.
  • the object of the invention is to provide methods for relocating a tunnel from a first serving node of a GPRS system to a second, which also function if at least one version 0 node exists between the serving node and the gateway node and others are after version 1 of the GTP protocol.
  • the task is solved by a method according to claim 1.
  • the request to adapt the context, which the second serving node directs to the gateway node contains an indication of the IMSI and NSAPI of the tunnel in question.
  • This specification allows the gateway node to establish a clear correspondence to a stored context and thus to deliver the required context data to the second node.
  • the required specification of IMSI and NSAPI can be transmitted in a very simple manner by the second serving node and the gateway node continuing to operate the tunnel established under version 0 of the GTP protocol under the same protocol version.
  • the request to be sent from the second node to the gateway node contains Adaptation of the context, the message "Update PDP Context Request", this required information from the start.
  • This solution thus means that the protocol which the second serving node uses when communicating with the gateway node depends on the history of the tunnel to which the exchanged messages belong.
  • Such control of the version used can be implemented in a simple manner if the first serving node first sends a message initiating the tunneling process (SGSN Context Response) to the second serving node, the second serving node the version of this message for its request to adapt the Context used at the gateway node and this replies to all messages addressed to him in the version in which he received them.
  • SGSN Context Response a message initiating the tunneling process
  • the second node sends a message of the type "Create PDP Context Request * according to version 1" instead of the conventional message "Update PDP Context Request *" as a request to adapt the tunnel.
  • This message is processed correctly by the receiving gateway node in accordance with the above-cited document TS 29.060, ie the existing PDP context is found again and the changed parameters are replaced. In this way, the tunnel to the second serving node is relocated and the version changed.
  • the message “Update PDP Context Request * can also be sent with a TEID that has the value 0, and which, in addition to the information elements provided in accordance with TS 23.060, additionally contains IMSI and NSAPI for assignment to enable the corresponding PDP context in the gateway node.
  • the object is achieved by the method according to claim 5, in which a flow label, the second serving node and the gateway node need, in order to be able to switch the tunnel from the first to the second serving node, the second is made available by the first serving node.
  • the gateway node is a version 1 node, ie the channel was set up according to version 1, then the tunnel is only one when it is set up
  • a first variant provides that the first serving node assigns the context a flow label with a value which is specific for the redirection of a tunnel from a serving node according to version 1 to a serving node according to version 0, that is to say which is different from all Flow labels that are used for communication between nodes that work according to version 0.
  • the second serving node can react to the receipt of such a specific flow label by instead of a message “Update PDP Context Request *, which it would normally send to the gateway node if it receives a correct flow label from a first serving node of the received the same version would have sent a message "Create PDP Context Request * to the gateway node, which contains IMSI and NSAPI and thus allows a clear identification of the context to be adapted at the gateway node.
  • Such a procedure is possible because the existing standard does not provide any PDP update requests with flow label 0 and their processing is therefore not standardized.
  • a second variant of the method which can also be used if the gateway node operates according to version 1 and the second serving node operates according to version 0, provides that the gateway node has every context established by the first serving node according to version 1 not only assigns a TEID, but at the same time has a defined procedure according to which it can assign a flow label to every context established according to Version 1 or more precisely its TEID.
  • every context established according to GTP version 1 corresponds to a TEID and a flow label.
  • the gateway node can expediently take the resulting flow labels into account when assigning TEIDs in the sense that an effective identification of contexts is possible on the basis of the flow labels.
  • the same procedure is also available to the first serving node.
  • the first serving node can immediately determine the correct value of the flow label using the method and make it available to the second serving node, by means of which the gateway node can identify the PDP context.
  • the second serving node can the gateway node in the address in the same way as if it had received the tunnel from a serving node after version 0.
  • a preferred, because particularly simple, method for assigning the flow label to a TEID is to equate the flow label with the two least significant bytes of the TEID. If, however, 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 done
  • the flow label does not fill in the TEID field, it is advantageously possible to use the remaining space in the TEID field for the transmission of a predetermined value, which otherwise does not occur in one TEID and on which the second
  • serving nodes can therefore recognize that the transmitted value is not a TEID, but rather a “packaged * flow label” and can accordingly process the value correctly.
  • a predetermined value can e.g. 0.
  • FIGS. 1 to 3 show the possible constellations in the transfer of a tunnel between two serving nodes with the participation of two nodes according to GTP version 1 and one node according to version 0;
  • FIGS. 4 to 6 show the sequence of signaling when the tunnel is handed over in the various constellations.
  • 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 shows the signaling sequence 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 moving the GTP tunnel.
  • 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.
  • step 1 the terminal MS sends a request to activate a PDP context (Activate PDP Context Request) to the SGSN0, which, among other things, specifies the NSAPI and the type or quality of the desired service.
  • PDP context Activate PDP Context Request
  • the SGSN1 node then sends 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 calculate and charge to him a flow label.
  • step 3 he sends a message “Create PDP Context Response * back to the first serving node SGSNl, which is the assigned flow label contains.
  • 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).
  • the SGSN1 is able to identify data packets of the terminal MS that belong to the newly established context so that the gateway node GGSN them from the data packets of other terminals or from other contexts associated data packets of the same terminal can distinguish.
  • the process of moving a tunnel begins with the terminal in step 5 sending a "Routing Area Update Request *" to the second serving node SGSN2.
  • This SGSN2 node works according to GTP version 1.
  • step 6 With a message “SGSN Context Request * according to GTP version 0 (step 6), he 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 newly serving node SGSN2 has confirmed its readiness to take over data by a message “SGSN Context Aeknowledge *, the node SGSN1 forwards the buffered data packets in step 9 to the node SGSN2.
  • the gateway node GGSN 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. While in the case of the transfer of a context from a serving node of the same version, the request to adapt the context would be a message “Update PDP Context Request *, in the case considered here, the second serving node uses a message of the type as a request
  • the gateway node If the gateway node has successfully carried out this operation, it confirms this in step 11 to the new SGSN2 with a message which can be of the type “Create PDP Context Response * or“ Update PDP Context Response *.
  • a message of the type" Up- date PDP Context Request * can be applied.
  • This modified message contains a TEID with the value 0 and IMSI and NSAPI of the terminal MS.
  • the second serving node for the update request of step 10 chooses the GTP version in which it received the message “SGSN Context Aeknowledge *” in step S7, in this case version 0. In this way if it issues itself 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 response messages from the gateway node. In this way, the context is changed to the new serving nodes SGSN2 correctly assigned, even if the GTP version used remains the same.
  • a second method for moving 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 version 0 in step 10 for its request to update the context in which it already received the flow label of the tunnel in step 7.
  • the gateway node also replies to this in step 11 using version 0. This means that although second serving node SGSN2 and gateway node GGSN version 1, they do so using sion 0 tunnel continued using version 0.
  • FIG. 2 shows a configuration in which a first node SGSN1 according to GTP version 1, a gateway node GGSN according to GTP version 1 and a second serving node SGSN2 according to version 0 communicate with one another.
  • the first serving node SGSN1 and the gateway node GGSN use among themselves those identified by tunnel endpoint identifier TEID
  • Version 1 messages the two serving nodes SGSN1 and SGSN2 use messages identified by flow labels and TEID according to Version 0.
  • the tunnel shown in FIG. 5 corresponds to that of FIG. 4.
  • the GTP versions used for the different messages again indicated by thick and thin arrows, are different.
  • the context requirement “Create PDP Context Request *” and the answer to it in steps 2 and 3 correspond to those in their objective of Figure 4, but with the difference that GTP version 1 is used for them and that, as a result, the gateway node GGSN assigns a tunnel endpoint identifier TEID to the context and reports this back to the first serving node SGSN1.
  • 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 knows the method according to which the first serving node GGSN1 generates flow labels from TEIDs, it can easily receive a small number from the second serving node when the corresponding flow label is received in a request for context update in step 10 identify contexts in its directory that may be affected by the update. It is then easily possible to determine the actual victims among these.
  • Another way of updating the context is to use flow labels with the value 0, similar to that described above with reference to FIG. 4. Because flow labels with otherwise not assigned this value or at most 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 is not yet known at the time the message is sent, the Gateway node GGSN, when it receives a message with such a flow label with the value 0 from the second serving node SGSN2, conclude that the flow label cannot have been assigned by itself and that an assignment of the message to one is therefore made Tunnels must be neglected with 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.
  • GTP version 0 an addition to GTP version 0 can be provided, in which the second serving node SGSN2 sends a message of the type “Create PDP Context Request *” when it receives a message from the first serving node with the flow label set to 0.
  • both serving nodes SGSNl 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 serving node SGSNl to the second SGSN2 are shown in FIG. 6.
  • 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 operating nodes must apply version 1 to each other.
  • the first serving node SGSN1 adds two higher order bytes to the format of a TEID, which is transmitted to the second node SGSN2 in step 7 (SGSN Context Response).
  • SGSN Context Response two messages shown as dashed arrows in FIG. 6 are then exchanged:
  • the SGSN node sends a version 1 context adaptation request (Update PDP Context Request) to the gateway node GGSN. Since this 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 creates 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 SGSNl as a flow label.
  • the first serving node SGSN1 uses two bytes with a predetermined value in order to expand the flow label assigned 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 information transmitted to it is actually a flow label, restores it and can therefore select the version 0 message format that can be interpreted by the gateway node GGSN from the start for the request to update the context in step 10.
  • the version used by the second serving node SGSN2 for the update request is not determined by the latter in a dialog between the second node SGSN2 and gateway node GGSN, but is determined by the version of the SGSN Context Response message, this is suitable Variant also for the case already mentioned above, that a tunnel that originally established between a serving node SGSN 1 according to version 0 and a version 1 GGSN and then switched to a second serving node SGSN2 according to version 1 while maintaining the protocol version originally used for the tunnel at a third serving node according to version 1.
  • the context information to be transmitted in step 7 can also be expanded such 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, the status of which indicates 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.
  • This third variant is also suitable for relocating a tunnel operated under version 0 to a third serving node according to version 1.
  • a fourth option is to use GTP version 0 between the serving nodes.
  • the second serving node GGSN2 starts the dialogue with the first node SGSNl with GTP version 1, which the first node (SGSNl) understands; he would normally have to answer with GTP version 1.
  • the first node SGSN1 does not "understand” the GTP version 1 message, it causes the second serving node SGSN2 to use version 0, so that the flow label can be transmitted.
  • This variant also allows the relocation of a Version-O tunnel while maintaining the version at a third serving node.

Abstract

The invention relates to a method for transferring a tunnel from a first operating node (SGSN1) of a mobile radio communication system, especially a GPRS system, to a second operating node (SGSN2). The mobile radio communication system comprises operating nodes (SGSN1, SGSN2) and a gateway node (GGSN), at least one of these nodes being a node according to version 0 of the GTP protocol, and others being nodes according to version 1 of the GTP protocol. When the first operating node (SGSN1) is the node according to version 0, the request to adapt the context contains IMSI and NSAPI information of the tunnel concerned in order to correctly transfer said tunnel. If the second operating node (SGSN2) or the gateway node (GGSN) is a node according to version 0, the first operating node (SGSN1) allocates a flow label to the context, and the second operating node (SGSN2) sends the request to adapt the context of the tunnel concerned along with said allocated flow label.

Description

Beschreibungdescription
Verfahren zum Umlegen eines Tunnels zwischen Knoten eines GPRS-SystemsProcedure for laying a tunnel between nodes of a GPRS system
Die vorliegende Erfindung betrifft Verfahren zum Umlegen eines Tunnels von einem ersten bedienenden Knoten eines GPRS- Systems (General Packet Radio Service) auf einen zweiten.The present invention relates to methods for moving a tunnel from a first serving node of a GPRS system (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 Einzugsbereich 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 weitergereicht werden. Die Übertragung dieser Daten erfolgt in Form von Nachrichten nach dem GTP-Protokoll (GPRS-Tunnel-Protokoll) . 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 verwendet. 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 Service (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 tunnel in question 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 about the PDP context of the terminal 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 benötigten vollständigen Informationen über den Kontext zu beschaffen, die es ihm ermöglichen, den GTP-Tunnel umzuschalten, so daß der Dienst für das Endgerät unterbrechungsfrei fortgesetzt werden kann. Für das GTP-Protokoll sind bisher zwei Versionen standardisiert, 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.The data transmitted between the two serving nodes enables the second serving node to contact a gateway node and from there to obtain the required complete information about the context which enables it to switch the GTP tunnel so that the service for the terminal can continue without interruption. So far, two versions have been standardized for the GTP protocol, on the one hand GTP version 0, also known as Release 98 or 97, in GSM 09.60; on the other hand GTP version 1, also referred to as Release 99, in the aforementioned publication TS 23.060. The standardization of version 1 requires that nodes according to version 1 should be able to work with those according to version 0 and that the GTP tunnels are operated with the highest possible version.
Damit ein empfangender Knoten die GTP-Version erkennen kann, gemäß der eine empfangene Nachricht erstellt worden ist, tragen 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 gemäß 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, the messages each have an identifier in the header that enables the assignment to the respective version. Messages created according to version 1 cannot be interpreted by nodes that work according to version 0 or older standardizations. A version 1 node must therefore be able to create either version 1 or version 0 messages, depending on the GTP version a node to which it is sending messages.
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 zugeordnet wird. Bei Version 0 werden hierfür sogenannte Tunnel Identifier, abgekürzt TIDs, verwendet, die als Teil der Nachricht übertragen werden und sich aus der IMSI (International Mobile Subscriber Identity) und dem NSAPI (Network Layer Service 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 Knoten aufgebaut werden können.An essential difference between version 0 and version 1 of the GTP protocol is the procedure according to which a message is assigned to the established tunnel or a PDP context. Version 0 uses so-called tunnel identifiers, abbreviated TIDs, which are transmitted as part of the message and are composed of the IMSI (International Mobile Subscriber Identity) and the NSAPI (Network Layer Service Access Point Identifier). The IMSI is the worldwide unique identification number of a participant; the NSAPI references one of several PDP contexts that can be assigned to the participant. Since the tunnel identifiers with a length of 12 bytes are rather unwieldy, so-called flow labels with a length of 2 bytes are used in their place, which enable messages to be quickly assigned to a context. However, the flow labels are not necessarily assigned clearly because they only 65,000 and have significantly more contexts per node.
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 gleichbedeutend 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 nachfolgenden Nachrichten dieses Tunnels müssen mit dem vom Gate- way-Knoten vergebenen Flow Label gesendet werden. Genau genommen 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 assigned when a GTP tunnel is activated; each node involved in a tunnel informs the opposite node of the flow label with which it wants to receive subsequent messages on this tunnel or, which is synonymous for this PDP context. For the first message that is sent from a serving node to a gateway node during the establishment of a tunnel (Create PDP Context Request), the flow label is set to 0 because the gateway node has not yet been able to assign a flow label, and the tunnel identifier is transmitted; all subsequent messages in this tunnel must be sent with the flow label assigned by the gateway node. Strictly speaking, two flow labels are assigned, one for signaling and one for data. In the following, however, only the flow label for signaling is considered.
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 kompatibel, 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 eindeutige Zuordnung der Nachricht zu einem PDP-Kontext ermöglichen, sind nur in der ersten Nachricht (Create PDP Context Request) vom bedienenden Knoten an den Gateway-Knoten enthal- ten.In GTP version 1, so-called TEID (Tunnel Endpoint Identifier) are assigned, 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, but they can be clearly assigned. The tunnel identifier known from version 0 is no longer contained in messages after version 1. IMSI and NSAPI, which enable the message to be clearly assigned to a PDP context, are only contained in the first message (Create PDP Context Request) from the serving node to the gateway node.
Innerhalb der jeweiligen Version funktionieren beide Versionen des GTP einwandfrei. In der Standardisierung ist gefordert, daß ein Knoten für Version 1 auch die GTP-Version 0 un- terstützt, also rückwärtskompatibel ist. Dies ist erforder- lieh, damit Knoten unterschiedlicher Versionen zusammenarbeiten können.Within the respective version, both versions of the GTP work perfectly. Standardization requires that a node for version 1 also support GTP version 0, ie it is backwards compatible. This is required lent so nodes of different versions can work together.
Es treten jedoch Probleme auf, wenn ein Mobilfunkteilnehmer sich in einem Netz, das Knoten unterschiedlicher Versionen enthält, bewegt und dabei vom Einzugsbereich eines bedienenden 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 Einzugsbereichs ü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- en 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 Umschaltung 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 mobile radio subscriber moves in a network which contains nodes of different versions and thereby changes from the service area of one serving node to that of another. This change results in a RAU (Routing Area Update), in which a tunnel is transferred from the node in whose catchment area the subscriber was previously to the node of the new catchment area. As part of this procedure, data about the PDP context must be passed on from the old to the new node using GTP messages. The new node needs this data in order to establish contact with the gateway node and switch the GTP tunnel so that the service for the subscriber can be continued without interruption. If all three nodes involved in the switchover of the tunnel belong to the same GTP version, the switchover is unproblematic. Even if two of them are Version 0 nodes and the third is a Version 1 node, there are no problems since all messages exchanged between the nodes must be GTP Version 0 messages. However, if two nodes are version 1 and the third node is version 0, the fact that the two nodes of version 1 communicate with each other with version 1 messages and with the one in the third node with version 0 messages creates difficulties. There are three cases.
1. Der Mobilfunkteilnehmer bewegt sich von einem ersten bedienenden 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- sehen 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 bedienenden 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ünglich 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 schicken können. Der zweite bedienende Knoten und der Gateway- Knoten kommunizieren jedoch nach Version 1, die die Übertragung 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 definiert. 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 serving node according to version 0 to a second serving according to version 1. In this situation, GTP version 0 must be used for the communication of the first serving node with the second and with the gateway node; the communication between the gateway node and the second serving node takes place according to version 1. When building the tunnel, the teway node to a flow label, which is used by the first serving node to identify messages belonging to the tunnel. When the two serving nodes contact to prepare for the relocation of the tunnel, they communicate according to version 0, and the first serving node supplies the second with the flow label that was originally assigned to the tunnel by the gateway node. In order to receive the necessary context data of the tunnel from the gateway node, the second serving node should be able to send a message with this flow label to the gateway node. However, the second serving node and the gateway node communicate according to version 1, which does not allow the transfer of flow labels. Instead of the flow label, a TEID according to version 1 could be transmitted, but one is not defined in the gateway node for the tunnel. The gateway node can therefore not assign a message according to GTP version 1 to the existing channel. Since the message “Update PDP Context Request * contains neither IMSI nor NSAPI, the gateway node is not able to find the context even if it ignores the TEID.
2. Der Mobilfunkteilnehmer bewegt sich von einem ersten bedienenden 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 Label. Für die Kommunikation zwischen den zwei bedienenden Knoten muß GTP-Version 0 verwendet werden, diese erlaubt jedoch nur Flow Label. Eine Möglichkeit, den TEID an den zweiten2. The mobile radio subscriber moves from a first serving node according to version 1 to one according to version 0. In this case, GTP version 1 is used for the communication between the first serving node and the gateway node in the course of setting up the tunnel been, ie a TEID has been set for the tunnel, but no flow label. GTP version 0 must be used for communication between the two serving nodes, but this only allows flow labels. One way to pass the TEID to the second
Knoten zu übertragen, besteht nicht, und selbst wenn sie bestünde, könnte dieser sie nicht verarbeiten. Der zweite bedienende Knoten hat daher keine Möglichkeit, die Flow Labels herauszufinden, mit denen er die benötigten Kontextdaten vom Gateway-Knoten anfordern könnte. 3. Der Mobilfunkteilnehmer bewegt sich von einem bedienenden Knoten nach Version 1 zu einem anderen der gleichen Version, 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 Version 0. Der Gateway-Knoten ordnet somit beim Aufbau eines Tunnels 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.Transferring nodes does not exist, and even if it existed, it could not process them. The second serving node therefore has no way of finding out the flow labels with which it could request the required context data from the gateway node. 3. The mobile subscriber moves from a serving node according to version 1 to another of the same version, but the gateway node works according to version 0. In this case, the serving nodes communicate with each other according to version 1, but with the gateway node according to version 0. The gateway node thus assigns a flow label when a tunnel is set up, but this cannot be transferred from the first to the second node, so that it cannot query the context information from the gateway node.
Die Aufgabe der Erfindung besteht darin, Verfahren zum Umlegen 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 Gateway-Knoten wenigstens ein Knoten nach Version 0 und andere nach Version 1 des GTP-Protokolls befinden.The object of the invention is to provide methods for relocating a tunnel from a first serving node of a GPRS system to a second, which also function if at least one version 0 node exists between the serving node and the gateway node and others are after 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 liefern.In the event that the first serving node is a version 0 node and the second serving node and the gateway node are version 1 nodes, the task is solved by a method according to claim 1. This provides that the request to adapt the context, which the second serving node directs to the gateway node, contains an indication of the IMSI and NSAPI of the tunnel in question. This specification allows the gateway node to establish a clear correspondence to a stored context and thus to deliver the required context data to the second node.
Die benötigte Angabe von IMSI und NSAPI kann auf ganz einfache Weise dadurch übertragen werden, daß der zweite bedienende 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 zweiten Knoten an den Gateway-Knoten zu sendende Aufforderung zur Anpassung des Kontexts, die Nachricht „Update PDP Context Request', 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 Knoten nach Version 1 aufgebaut worden ist, findet die Kommunikation mit dem Gateway-Knoten nach Version 1 statt; wurde der Tunnel ursprünglich von einem Knoten nach Version 0 aufgebaut, so läuft die Kommunikation mit dem Gateway-Knoten weiterhin nach Version 0, obwohl beide beteiligten Knoten Version 1 beherrschen.The required specification of IMSI and NSAPI can be transmitted in a very simple manner by the second serving node and the gateway node continuing to operate the tunnel established under version 0 of the GTP protocol under the same protocol version. In this case, the request to be sent from the second node to the gateway node contains Adaptation of the context, the message "Update PDP Context Request", this required information from the start. This solution thus means that the protocol which the second serving node uses when communicating with the gateway node depends on the history of the tunnel to which the exchanged messages belong. If a tunnel has been established by the second node itself or by another node according to version 1, communication with the gateway node according to version 1 takes place; If the tunnel was originally set up by a node according to version 0, communication with the gateway node continues to operate according to version 0, although both participating nodes are capable of version 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 Nachricht (SGSN Context Response) an den zweiten bedienenden Knoten 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 gerichteten Nachrichten in der Version beantwortet, in der er sie empfangen hat.Such control of the version used can be implemented in a simple manner if the first serving node first sends a message initiating the tunneling process (SGSN Context Response) to the second serving node, the second serving node the version of this message for its request to adapt the Context used at the gateway node and this replies to all messages addressed to him in the version in which he received them.
Eine alternative Möglichkeit ist die, daß der zweite Knoten als Aufforderung zur Anpassung des Tunnels anstelle der herkömmlichen Nachricht „Update PDP Context Request* eine Nachricht vom Typ „Create PDP Context Request* nach Version 1 sendet. Diese Nachricht wird gemäß der oben zitierten Schrift TS 29.060 vom empfangenden Gateway-Knoten richtig verarbeitet, 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. Weiterhin alternativ kann vorgesehen werden, daß auch die Nachricht „Update PDP Context Request* mit einem TEID gesendet 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.An alternative possibility is that the second node sends a message of the type "Create PDP Context Request * according to version 1" instead of the conventional message "Update PDP Context Request *" as a request to adapt the tunnel. This message is processed correctly by the receiving gateway node in accordance with the above-cited document TS 29.060, ie the existing PDP context is found again and the changed parameters are replaced. In this way, the tunnel to the second serving node is relocated and the version changed. Furthermore, it can alternatively be provided that the message “Update PDP Context Request * can also be sent with a TEID that has the value 0, and which, in addition to the information elements provided in accordance with TS 23.060, additionally contains IMSI and NSAPI for assignment to enable the corresponding PDP context in the gateway node.
In dem Fall, daß der zweite bedienende Knoten oder der Gateway-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 the gateway node is a node according to version 0 and the other nodes are according to version 1, the object is achieved by the method according to claim 5, in which a flow label, the the second serving node and the gateway node need, in order to be able to switch the tunnel from the first to the second serving node, the second is made available by the first serving node.
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 einThere are various ways of assigning the flow label. If the gateway node is a version 1 node, ie the channel was set up according to version 1, then the tunnel is only one when it is set up
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.TEID, but no flow label has been assigned. In this case, it is expedient for the first serving node to assign a flow label to the tunnel.
Eine erste Variante sieht vor, daß der erste bedienende Knoten 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 einem ersten bedienenden Knoten der gleichen Version erhalten hätte, eine Nachricht „Create PDP Context Request* an den Gateway-Knoten sendet, die IMSI und NSAPI enthält und somit eine 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 allerdings abweichend vom geltenden Protokoll der Version 1 zusätzlich IMSI und NSAPI enthält und so wiederum eine Identifizierung 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 serving node assigns the context a flow label with a value which is specific for the redirection of a tunnel from a serving node according to version 1 to a serving node according to version 0, that is to say which is different from all Flow labels that are used for communication between nodes that work according to version 0. The second serving node can react to the receipt of such a specific flow label by instead of a message “Update PDP Context Request *, which it would normally send to the gateway node if it receives a correct flow label from a first serving node of the received the same version would have sent a message "Create PDP Context Request * to the gateway node, which contains IMSI and NSAPI and thus allows a clear identification of the context to be adapted at the gateway node. Alternatively, provision can also be made for the second serving node to send an “Update PDP Context Request *” message to the gateway node, which, in contrast to the applicable version 1 protocol, additionally contains IMSI and NSAPI and thus in turn permits identification. Such a procedure is possible because the existing standard does not provide any PDP update requests with flow label 0 and their processing is therefore not standardized.
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 zuordnet, 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äßigerweise kann der Gateway-Knoten bereits bei der Vergabe von TEIDs die daraus resultierenden Flow Labels in dem Sinne berücksichtigen, daß eine effektive Identifizierung von Kontexten 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 bedienenden Knoten nach Version 0 übergeben bekommen hätte.A second variant of the method, which can also be used if the gateway node operates according to version 1 and the second serving node operates according to version 0, provides that the gateway node has every context established by the first serving node according to version 1 not only assigns a TEID, but at the same time has a defined procedure according to which it can assign a flow label to every context established according to Version 1 or more precisely its TEID. Thus, in the gateway node, every context established according to GTP version 1 corresponds to a TEID and a flow label. The gateway node can expediently take the resulting flow labels into account when assigning TEIDs in the sense that an effective identification of contexts is possible on the basis of the flow labels. The same procedure is also available to the first serving node. If a tunnel that has been established by the first serving node according to GTP version 1 has to be redirected to a second serving node according to version 0, the first serving node can immediately determine the correct value of the flow label using the method and make it available to the second serving node, by means of which the gateway node can identify the PDP context. Thus, the second serving node can the gateway node in the address in the same way as if it had received the tunnel from a serving node after version 0.
Ein bevorzugtes, weil besonders einfaches Verfahren zum Zu- 5 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 beiA preferred, because particularly simple, method for assigning the flow label to a TEID is to equate the flow label with the two least significant bytes of the TEID. If, however, 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 done
10 dessen Aufbau vom Gateway-Knoten vorgenommen worden, und dieses 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* . '1510 whose structure was carried out by the gateway node, and this flow label is known to the first serving node. In order to transmit this flow label to the second node - via Version 1 messages - it is advisable to "package" it in the TEID field of a Version 1 message. '15
Da das Flow Label das TEID-Feld nicht ausfüllt, ist es vorteilhaft möglich, den verbleibenden Platz in dem TEID-Feld zur Übertragung eines vorgegebenen Wertes zu nutzen, der andernfalls in einem TEID nicht vorkommt und an dem der zweiteSince the flow label does not fill in the TEID field, it is advantageously possible to use the remaining space in the TEID field for the transmission of a predetermined value, which otherwise does not occur in one TEID and on which the second
20 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.20 serving nodes can therefore recognize that the transmitted value is not a TEID, but rather a “packaged * flow label” and can accordingly process the value correctly. Such a predetermined value can e.g. 0.
2525
Ausführungsbeispiele werden nachfolgend anhand der Zeichnungen näher erläutert. Es zeigen:Exemplary embodiments are explained in more detail below with reference to the drawings. Show it:
Figuren 1 bis 3 die möglichen Konstellationen bei der Überga- 30 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 show the possible constellations in the transfer of a tunnel between two serving nodes with the participation of two nodes according to GTP version 1 and one node according to version 0;
Figuren 4 bis 6 den Ablauf der Signalisierung bei der Überga- 35 be des Tunnels in den verschiedenen Konstellationen. Bei der Konstellation der Figur 1 ist der erste bedienende Knoten SGSNl, über den der Tunnel des Endgeräts MS ursprünglich aufgebaut worden ist, ein Knoten nach GTP-Version 0; er kommuniziert mit dem Gateway-Knoten GGSN und dem zweiten bedienenden Knoten SGSN2 nach GTP-Version 0, d.h. die ausgetauschten 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.FIGS. 4 to 6 show the sequence of signaling when the tunnel is handed over in the various constellations. 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.
Figur 4 zeigt den Ablauf der Signalisierung zwischen einem Endgerät MS und den drei Knoten SGSNl, SGSN2 und GGSN einerseits 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-Protokoll gebunden sind wie etwa mit dem Endgerät MS ausgetauschte Nachrichten sind gestrichelt dargestellt.FIG. 4 shows the signaling sequence 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 moving the GTP tunnel. 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 Aktivierung eines PDP-Kontexts (Activate PDP Context Request) an den SGSN0, der unter anderem die NSAPI und Art bzw. Quali- tat des gewünschten Dienstes spezifiziert. Der bedienendeIn step 1, the terminal MS sends a request to activate a PDP context (Activate PDP Context Request) to the SGSN0, which, among other things, specifies the NSAPI and the type or quality of the desired service. The operator
Knoten SGSNl 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 SGSNl 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 ersten bedienenden Knoten SGSNl, die das zugeteilte Flow Label enthält. Der erste bedienende Knoten bestätigt seinerseits die Einrichtung des Kontexts dem Endgerät MS durch eine Nachricht „Activate PDP Context Accept* (Schritt 4) .The SGSN1 node then sends 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 calculate and charge to him a flow label. As a confirmation, in step 3 he sends a message “Create PDP Context Response * back to the first serving node SGSNl, which is the assigned flow label contains. 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 SGSNl 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 anderen Kontexten zugehörigen Datenpaketen des gleichen Endgeräts unterscheiden kann.Through the assigned flow label, the SGSN1 is able to identify data packets of the terminal MS that belong to the newly established context so that the gateway node GGSN them from the data packets of other terminals 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 in step 5 sending a "Routing Area Update Request *" to the second serving node SGSN2. This SGSN2 node works according to GTP version 1.
Durch eine Nachricht „SGSN Context Request* nach GTP-Version 0 (Schritt 6) gibt er dem ersten bedienenden Knoten SGSNl zunächst bekannt, daß der Kontext übergeben werden soll; der SGSNl bestätigt dies durch eine Nachricht „SGSN Context Response* (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- rieht „SGSN Context Aeknowledge* bestätigt hat, leitet der Knoten SGSNl die gepufferten Datenpakete in Schritt 9 zum Knoten SGSN2 weiter.With a message “SGSN Context Request * according to GTP version 0 (step 6), he 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 newly serving node SGSN2 has confirmed its readiness to take over data by a message “SGSN Context Aeknowledge *, 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 SGSNl, 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. Während im Falle der Übernahme eines Kontexts von einem bedienenden Knoten der gleichen Version die Aufforderung zur Anpassung des Kontexts eine Nachricht „Update PDP Context Request* wäre, verwendet der zweite bedienenden Knoten im hier betrachteten Fall als Aufforderung eine Nachricht vom TypIn 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. While in the case of the transfer of a context from a serving node of the same version, the request to adapt the context would be a message “Update PDP Context Request *, in the case considered here, the second serving node uses a message of the type as a request
„Create PDP Context Request* . Diese Nachricht enthält im Gegensatz 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 daher nicht, einen solchen TEID der Nachricht zu interpretieren, 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."Create PDP Context Request *. In contrast to the message “Update PDP Context Request * according to GTP version 1 IMSI and NSAPI of the terminal MS. The gateway node does not expect a message of this type to be sent with a defined TEID; he therefore does not attempt to interpret such a TEID of the message, but rather identifies the relevant context in the directory he maintains using the IMSI and NSAPI. The context entry found in this way is updated by assigning it the new serving node SGSN2 and the GTP version according to which the communication between the GGSN and the serving node takes place.
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 Response* 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 with a message which can be of the type “Create PDP Context Response * 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 Endgerä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 beschrieben.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, during the course of which the terminal is assigned 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 modifizierte 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 beschlossen werden, daß der TEID nicht vom Gateway-Knoten GGSN vergeben worden ist und daß ihm somit kein Eintrag im Kontextverzeichnis 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 identifizieren und wie oben beschrieben zu aktualisieren.As an alternative to using the message "Create PDP Context Request * in step 10, a message of the type" Up- date PDP Context Request * can be applied. 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 Context Request * with TEID = 0, it can be concluded that the TEID has not been assigned by the gateway node GGSN and that therefore no entry in the context directory of the GGSN corresponds to it. In such a case, the GGSN therefore uses IMSI and NSAPI to identify the context affected by the “Update PDP Context Request *” and to update it as described above.
Eine weitere Alternative ist, daß der zweite bedienende Knoten für die Aktualisierungsaufforderung des Schritts 10 je- weils diejenige GTP-Version wählt, in der er in Schritt S7 die Nachricht „SGSN Context Aeknowledge* erhalten hat, hier also die Version 0. Auf diese Weise gibt er sich dem GGSN gegenü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 Antwortnachrichten ebenfalls in Version 0. Auf diese Weise wird der Kontext auf den neuen bedienenden Knoten SGSN2 korrekt umgelegt, auch wenn die verwendete GTP-Version die gleiche bleibt.Another alternative is that the second serving node for the update request of step 10 chooses the GTP version in which it received the message “SGSN Context Aeknowledge *” in step S7, in this case version 0. In this way if it issues itself 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 response messages from the gateway node. In this way, the context is changed to the new serving nodes SGSN2 correctly assigned, even if the GTP version used remains the same.
Ein zweites Verfahren zum Umlegen des Tunnels vom ersten bedienenden 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 verwendet, 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 weiter.A second method for moving 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 version 0 in step 10 for its request to update the context in which it already received the flow label of the tunnel in step 7. The gateway node also replies to this in step 11 using version 0. This means that although second serving node SGSN2 and gateway node GGSN version 1, they do so using sion 0 tunnel continued 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ß.Since in this second method the version of the tunnel does not change when moving to the second serving node, special precautions are necessary if the tunnel has to be moved a second time to a third serving node according to version 1.
Bei der Übergabe dieses Version-O-Tunnels von einem zweiten an einen dritten bedienenden Knoten, die beide Version 1 anwenden, 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 anwendbar.When this Version-O tunnel is transferred from a second to a third serving node, which both use Version 1, the same problems arise as in the case where a between a first serving node according to Version 1 and a gateway node follows Version 0 established tunnel must be relocated to a second serving node according to version 1. Some of the solutions to this problem described later are therefore also applicable to this case.
Figur 2 zeigt eine Konfiguration, in der ein erster Knoten SGSNl nach GTP-Version 1, ein Gateway-Knoten GGSN nach GTP- Version 1 und ein zweiter bedienender Knoten SGSN2 nach Version 0 miteinander kommunizieren. Der erste bedienende Knoten SGSNl und der Gateway-Knoten GGSN verwenden untereinander al- so durch Tunnel Endpoint Identifier TEID gekennzeichneteFIG. 2 shows a configuration in which a first node SGSN1 according to GTP version 1, a gateway node GGSN according to GTP version 1 and a second serving node SGSN2 according to version 0 communicate with one another. The first serving node SGSN1 and the gateway node GGSN use among themselves those identified by tunnel endpoint identifier TEID
Nachrichten nach Version 1, die zwei bedienenden Knoten SGSNl und SGSN2 verwenden untereinander durch Flow Labels und TEID gekennzeichnete Nachrichten nach Version 0.Version 1 messages, 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 desThe order of the steps to build and move the
Tunnels, die in Figur 5 dargestellt ist, entspricht der von Figur 4. Allerdings sind die für die verschiedenen Nachrichten 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 Figur 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 SGSNl zurückmeldet.The tunnel shown in FIG. 5 corresponds to that of FIG. 4. However, the GTP versions used for the different messages, again indicated by thick and thin arrows, are different. The context requirement “Create PDP Context Request *” and the answer to it in steps 2 and 3 correspond to those in their objective of Figure 4, but with the difference that GTP version 1 is used for them and that, as a result, the gateway node GGSN assigns a tunnel endpoint identifier TEID to the context 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 Version 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 vernachlä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 erzeugt, 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 tatsächlichen Betroffenen zu ermitteln, ist dann ohne weiteres möglich.The request “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 an“ 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 knows the method according to which the first serving node GGSN1 generates flow labels from TEIDs, it can easily receive a small number from the second serving node when the corresponding flow label is received in a request for context update in step 10 identify contexts in its directory that may 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 Figur 4 beschrieben. Da Flow Labels mit diesem Wert ansonsten nicht vergeben bzw. allenfalls von einem 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- rieht 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 folgern, 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 way of updating the context is to use flow labels with the value 0, similar to that described above with reference to FIG. 4. Because flow labels with otherwise not assigned this value or at most 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 is not yet known at the time the message is sent, the Gateway node GGSN, when it receives a message with such a flow label with the value 0 from the second serving node SGSN2, conclude that the flow label cannot have been assigned by itself and that an assignment of the message to one is therefore made Tunnels must be neglected with 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 Request* 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 can be provided, in which the second serving node SGSN2 sends a message of the type “Create PDP Context Request *” when it receives a message from the first serving node with the flow label set to 0.
Bei der in Figur 3 gezeigten dritten Konstellation sind beide bedienenden Knoten SGSNl 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 SGSNl an den zweiten SGSN2 sind in Fig. 6 gezeigt. Der Aufbau des Tunnels in den Schritten 1 bis 4 läuft genauso ab wie mit Bezug auf Figur 1 und 4 beschrieben. Untereinander müssen die zwei bedienenden Knoten Version 1 anwenden. Um das zwischen bedienendem Knoten SGSNl und Gateway- Knoten GGSN ausgehandelte Flow Label an den zweiten bedienenden Knoten SGSN2 zu übertragen, muß es also über eine Verbin-, düng 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 SGSNl um zwei höherwertige Bytes auf das Format eines TEID, der in Schritt 7 (SGSN Context Response) an den zweiten Knoten SGSN2 übermittelt wird. Einer ersten Variante des Verfahrens zufolge werden anschließend zwei in Figur 6 als gestrichelte Pfeile dargestellte Nachrichten ausgetauscht: Der Knoten SGSN sendet in Schritt 10' eine Aufforderung zur Kontextanpassung (Update PDP Context 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-O-Nachricht mit einem Flow-Label benötigt, und erzeugt daraufhin in Schritt 10 eine neue Aufforderung, diesmal nach Version 0, in die sie die zwei niedrigerwertigen Bytes des vom ersten Knoten SGSNl empfangenen TEID als Flow Label einfügt.In the third constellation shown in FIG. 3, both serving nodes SGSNl 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 serving node SGSNl to the second SGSN2 are shown in FIG. 6. 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 operating nodes must apply version 1 to each other. In order to transmit the flow label negotiated between the serving node SGSN1 and the gateway node GGSN to the second serving node SGSN2, it must be conveyed 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 to the second node SGSN2 in step 7 (SGSN Context Response). According to a first variant of the method, two messages shown as dashed arrows in FIG. 6 are then exchanged: In step 10 ', the SGSN node sends a version 1 context adaptation request (Update PDP Context Request) to the gateway node GGSN. Since this 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 creates 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 SGSNl as a flow label.
Einer zweiten Variante zufolge verwendet der erste bedienende Knoten SGSNl 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 Information 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 Gateway-Knoten GGSN interpretierbare Nachrichtenformat der Version 0 wählen kann.According to a second variant, the first serving node SGSN1 uses two bytes with a predetermined value in order to expand the flow label assigned 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 information transmitted to it is actually a flow label, restores it and can therefore select the version 0 message format 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 Gateway-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 bereits angesprochenen Fall, daß ein Tunnel, der ursprünglich zwischen einem bedienenden Knoten SGSN 1 nach Version 0 und einem Version-1-GGSN aufgebaut und dann zu einem zweiten bedienenden Knoten SGSN2 nach Version 1 unter Beibehaltung ursprünglich für den Tunnel verwendeten Protokollversion an ei- nen dritten bedienenden Knoten nach Version 1 umgelegt wird.Since in this second variant the version used by the second serving node SGSN2 for the update request is not determined by the latter in a dialog between the second node SGSN2 and gateway node GGSN, but is determined by the version of the SGSN Context Response message, this is suitable Variant also for the case already mentioned above, that a tunnel that originally established between a serving node SGSN 1 according to version 0 and a version 1 GGSN and then switched to a second serving node SGSN2 according to version 1 while maintaining the protocol version originally used for the tunnel at a third serving node according to version 1.
Gemäß einer dritten Variante kann die in Schritt 7 zu übertragende Kontextinformation auch dahingehend erweitert werden, 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 Kontextinformation 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, dessen Status den Inhalt des TEID-Feldes einer Nachricht als TEID oder als Flow Label kennzeichnet. Damit ist der Wertebereich für TEID nicht eingeschränkt.According to a third variant, the context information to be transmitted in step 7 can also be expanded such 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, the status of which indicates 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 suitable for relocating a tunnel operated under version 0 to a third serving node according to version 1.
Eine vierte Möglichkeit ist, auch zwischen den bedienenden Knoten GTP-Version 0 anzuwenden. Zwar beginnt der zweite bedienende Knoten GGSN2 den Dialog mit dem ersten Knoten SGSNl mit GTP Version 1, was der erste Knoten (SGSNl) versteht; er müßte daher normalerweise mit GTP Version 1 antworten. Indem jedoch der erste Knoten SGSNl „Nichtverstehen* der GTP Versi- on 1 Nachricht vortäuscht, veranlaßt er den zweiten bedienenden Knoten SGSN2, Version 0 zu verwenden, so daß das Flow Label übertragen werden kann. Auch diese Variante erlaubt die Umlegung eines Version-O-Tunnels unter Beibehaltung der Version an einen dritten bedienenden Knoten. A fourth option is to use GTP version 0 between the serving nodes. The second serving node GGSN2 starts the dialogue with the first node SGSNl with GTP version 1, which the first node (SGSNl) understands; he would normally have to answer with GTP version 1. However, by pretending that the first node SGSN1 does not "understand" the GTP version 1 message, it causes the second serving node SGSN2 to use version 0, so that the flow label can be transmitted. This variant also allows the relocation of a Version-O tunnel while maintaining the version at a third serving node.

Claims

Patentansprüche claims
1. Verfahren zum Umlegen eines Tunnels von einem ersten bedienenden Knoten (SGSNl) eines Mobilfunk-Kommunikations- Systems, insbesondere eines GPRS-Systems, auf einen zweiten (SGSN2) , wobei das Mobilfunk-Kommunikationssystem bedienende Knoten (SGSNl, SGSN2) und einen Gateway-Knoten (GGSN) aufweist, wobei wenigstens einer dieser Knoten ein Knoten nach Version 0 des GTP-Protokolls ist und andere dieser Knoten Knoten nach Version 1 des GTP-Protokolls sind, bei dem der zweite Knoten (SGSISf2) eine Nachricht ü- ber den Bedarf zum Umlegen des Tunnels (RAU request) von einem Endgerät (MS) erhält und daraufhin eine Aufforderung zur Anpassung des den Tunnel betreffenden Kontexts an den Gateway-Knoten (GGSN) richtet, dadurch gekennzeichnet, daß in dem Fall, daß der erste bedienende Knoten (SGSNl) ein Knoten nach Version 0 ist und der zweite bedienende Knoten (SGSN2) und der Gateway-Knoten (GGSN) Knoten nach Version 1 sind, die Aufforderung zur Anpassung des Kontexts eine Angabe von IMSI und NSAPI des betreffenden Tunnels enthält.1. Method for moving a tunnel from a first serving node (SGSNl) of a mobile radio communication system, in particular a GPRS system, to a second (SGSN2), the mobile radio communication system serving node (SGSNl, SGSN2) and a gateway Node (GGSN), wherein at least one of these nodes is a node according to version 0 of the GTP protocol and other of these nodes are nodes according to version 1 of the GTP protocol, in which the second node (SGSISf2) transmits a message Receives the need to move the tunnel (RAU request) from a terminal (MS) and then directs a request to adapt the context relating to the tunnel to the gateway node (GGSN), characterized in that in the event that the first serving node (SGSNl) is a version 0 node and the second serving node (SGSN2) and the gateway node (GGSN) are version 1 nodes, the request to adapt the context is an indication of IMSI and d contains the NSAPI of the tunnel in question.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß die Aufforderung eine Nachricht vom Typ „Create PDP Context Request* ist.2. The method according to claim 1, characterized in that the request is a message of the type "Create PDP Context Request *.
3. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß die Aufforderung eine Nachricht vom Typ „Update PDP Context Request* ist, die einen TEID mit dem Wert 0 und die die Angabe über IMSI und NSAPI des Tunnels enthält.3. The method according to claim 1, characterized in that the request is a message of the type "Update PDP Context Request *, which contains a TEID with the value 0 and which specifies the IMSI and NSAPI of the tunnel.
4. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß der Gateway-Knoten (GGSN) und der zweite bedienende Knoten (SGSN2) den umgelegten Tunnel gemäß Version 0 des GTP- Protokolls betreiben. 4. The method according to claim 1, characterized in that the gateway node (GGSN) and the second serving node (SGSN2) operate the switched tunnel according to version 0 of the GTP protocol.
5. Verfahren zum Umlegen eines Tunnels von einem ersten bedienenden Knoten (SGSNl) eines Mobilfunk-Kommunikationssystems, insbesondere eines GPRS-Systems, auf einen zweiten (SGSN2), wobei das Mobilfunk-Kommunikationssystem be- dienende Knoten (SGSNl, SGSN2) und einen Gateway-Knoten5. Method for moving a tunnel from a first serving node (SGSNl) of a mobile radio communication system, in particular a GPRS system, to a second (SGSN2), the mobile radio communication system serving nodes (SGSNl, SGSN2) and a gateway -Node
(GGSN) aufweist, wobei wenigstens einer dieser Knoten ein Knoten nach Version 0 des GTP-Protokolls ist und andere dieser Knoten Knoten nach Version 1 des GTP-Protokolls sind, bei dem der zweite Knoten (SGSN2) eine Nachricht ü- ber den Bedarf zum Umlegen des Tunnels (RAU request) von einem Endgerät (MS) erhält und daraufhin eine Aufforderung zur Anpassung des den Tunnel betreffenden Kontexts an den Gateway-Knoten (GGSN) richtet, dadurch gekennzeichnet, daß in dem Fall, daß der erste bedienende Knoten (SGSNl) und der Gateway-Knoten (GGSN) Knoten nach Version 1 sind und der zweite bedienende Knoten (SGSN2) ein Knoten nach Version 0 ist, oder in dem Fall, daß der Gateway-Knoten (GGSN) ein Knoten nach Version 0 ist und die bedienenden Knoten (SGSNl, SGSN2) jeweils Knoten nach Version 1 sind, der erste bedienende Knoten (SGSNl) ein dem Kontext zugeordnetes Flow Label an den zweiten bedienenden Knoten ü- berträgt und daß der zweite bedienende Knoten (SGSN2) die Aufforderung zur Anpassung des den Tunnel betreffenden Kontexts unter Einfügung dieses zugeordneten Flow Labels sendet.(GGSN), wherein at least one of these nodes is a node according to version 0 of the GTP protocol and other of these nodes are nodes according to version 1 of the GTP protocol, in which the second node (SGSN2) sends a message about the need for Relocate the tunnel (RAU request) from a terminal (MS) and then directs a request to adapt the tunnel-related context to the gateway node (GGSN), characterized in that in the event that the first serving node (SGSNl ) and the gateway node (GGSN) are version 1 nodes and the second serving node (SGSN2) is a version 0 node, or in the event that the gateway node (GGSN) is a version 0 node and the serving nodes (SGSNl, SGSN2) are each nodes according to version 1, the first serving node (SGSNl) transmits a flow label assigned to the context to the second serving node and that the second serving node (SGSN2) receives the request for adaptation solution of the context relating to the tunnel with the insertion of this assigned flow label.
6. Verfahren nach Anspruch 5, dadurch gekennzeichnet, daß in dem Fall, daß der erste bedienende Knoten (SGSNl) und der Gateway-Knoten (GGSN) Knoten nach Version 1 sind und der zweite bedienende Knoten (SGSN2) ein Knoten nach Version 0 ist, der erste bedienende Knoten (SGSNl) dem Kontext ein Flow Label mit einem vorgegebenen 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. 6. The method according to claim 5, characterized in that in the event that the first serving node (SGSNl) and the gateway node (GGSN) are version 1 nodes and the second serving node (SGSN2) is a version 0 node , the first serving node (SGSNl) assigns the context a flow label with a predetermined value which is specific for the redirection of a tunnel from a serving node according to version 1 to a serving node according to version 0.
7. Verfahren nach Anspruch 6, dadurch gekennzeichnet, daß der Wert des Flow Labels 0 ist.7. The method according to claim 6, characterized in that the value of the flow label is 0.
8. Verfahren nach einem der Ansprüche 5 bis 7, dadurch ge- kennzeichnet, daß der zweite bedienende Knoten (SGSN2) als Aufforderung zur Anpassung des den Tunnel betreffenden Kontexts eine Nachricht vom Typ „Create PDP Context Request* sendet.8. The method according to any one of claims 5 to 7, characterized in that the second serving node (SGSN2) sends a message of the type "Create PDP Context Request *" as a request to adapt the context relating to the tunnel.
9. Verfahren nach Anspruch 5, dadurch gekennzeichnet, daß in dem Fall, daß der erste bedienende Knoten (SGSNl) und der Gateway-Knoten (GGSN) Knoten nach Version 1 sind und der zweite bedienende Knoten (SGSN2) ein Knoten nach Version 0 ist, der erste bedienende Knoten (SGSNl) jedem nach Versi- on 1 etablierten Kontext den Flow Label nach einem gegebenen Verfahren zuordnet, und daß der Gateway-Knoten (GGSN) das gleiche Flow Label nach dem gleichen Verfahren zuordnet.9. The method according to claim 5, characterized in that in the event that the first serving node (SGSNl) and the gateway node (GGSN) are version 1 nodes and the second serving node (SGSN2) is a version 0 node , the first serving node (SGSN1) assigns the flow label according to a given method to each context established according to version 1, and that the gateway node (GGSN) assigns the same flow label using the same method.
10. Verfahren nach Anspruch 9, dadurch gekennzeichnet, daß das Verfahren zum Zuordnen des Flow Labels das Gleichsetzen des Flow Labels mit den zwei niederwertigen Bytes des TEID umfaßt.10. The method according to claim 9, characterized in that the method for assigning the flow label comprises equating the flow label with the two least significant bytes of the TEID.
11. Verfahren nach Anspruch 5, dadurch gekennzeichnet, daß in dem Fall, daß der Gateway-Knoten (GGSN) ein Knoten nach Version 0 ist und die bedienenden Knoten (SGSNl, SGSN2) Knoten nach Version 1 sind, das dem Tunnel vom Gateway- Knoten (GGSN) zugeteilte Flow Label im TEID-Feld einer vom ersten (SGSNl) an den zweiten bedienenden Knoten (SGSN2) gesendete Nachricht übertragen wird.11. The method according to claim 5, characterized in that in the event that the gateway node (GGSN) is a node according to version 0 and the serving nodes (SGSNl, SGSN2) are nodes according to version 1, the tunnel from the gateway Flow label assigned to nodes (GGSN) is transmitted in the TEID field of a message sent by the first (SGSNl) to the second serving node (SGSN2).
12. Verfahren nach Anspruch 11, dadurch gekennzeichnet, daß der zweite bedienende Knoten eine Aufforderung zur Kon- textaktualisierung nach Version 1 an den Gateway-Knoten (GGSN) sendet, und daß er, wenn der Gateway-Knoten (GGSN) die Aufforderung nicht verarbeiten kann, das Flow Label aus dem TEID-Feld extrahiert und eine neue Aufforderung nach Version 0 unter Verwendung des extrahierten Flow Labels sendet.12. The method according to claim 11, characterized in that the second serving node sends a request for context update according to version 1 to the gateway node (GGSN), and that when the gateway node (GGSN) can't process the prompt, extracts the flow label from the TEID field, and sends a new version 0 prompt using the extracted flow label.
13. Verfahren nach Anspruch 11, dadurch gekennzeichnet, daß in vom Flow Label nicht ausgefüllte Bytes des TEID-Feldes ein vorgegebener Wert eingetragen wird, der für die Umleitung eines Tunnels zwischen zwei bedienenden Knoten nach Version 1 über einen Gateway-Knoten nach Version 0 spezifisch ist.13. The method according to claim 11, characterized in that a predetermined value is entered in bytes of the TEID field which are not filled in by the flow label and which are specific for the redirection of a tunnel between two serving nodes according to version 1 via a gateway node according to version 0 is.
14. Verfahren nach Anspruch 13, dadurch gekennzeichnet, daß der zweite bedienende Knoten (SGSN2) die Aufforderung zur Kontextaktualisierung nach Version 0 sendet, wenn das TEID-Feld den vorgegebenen Wert enthält.14. The method according to claim 13, characterized in that the second serving node (SGSN2) sends the request for context update according to version 0 if the TEID field contains the predetermined value.
15. Verfahren nach Anspruch 13 oder 14, dadurch gekennzeichnet, daß der spezifische Wert 0 ist.15. The method according to claim 13 or 14, characterized in that the specific value is 0.
16. Verfahren nach Anspruch 11, dadurch gekennzeichnet, daß zusätzlich zu dem TEID-Feld eine Kennung übertragen wird, die angibt, ob das TEID-Feld einen TEID oder ein Flow Label enthält.16. The method according to claim 11, characterized in that in addition to the TEID field, an identifier is transmitted which indicates whether the TEID field contains a TEID or a flow label.
17. Verfahren nach Anspruch 5, dadurch gekennzeichnet, daß in dem Fall, daß der Gateway-Knoten (GGSN) ein Knoten nach Version 0 ist und die bedienenden Knoten (SGSNl, SGSN2) Knoten nach Version 1 sind, das dem Tunnel vom Gateway- Knoten (GGSN) zugeteilte Flow Label in einem speziellen, vom TEID-Feld verschiedenen Datenfeld einer Nachricht vom ersten an den zweiten bedienenden Knoten (SGSNl bzw. SGSN2) übermittelt wird. 17. The method according to claim 5, characterized in that in the case that the gateway node (GGSN) is a node according to version 0 and the serving nodes (SGSNl, SGSN2) are nodes according to version 1, the tunnel from the gateway Flow label assigned to nodes (GGSN) is transmitted in a special data field of a message, different from the TEID field, from the first to the second serving node (SGSN1 or SGSN2).
EP01944918A 2000-05-16 2001-05-09 Method for transferring a tunnel between nodes in a gprs system Expired - Lifetime EP1282997B1 (en)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
DE10023963 2000-05-16
DE10023963 2000-05-16
DE10038182A DE10038182C2 (en) 2000-05-16 2000-08-04 Procedure for laying a tunnel between nodes of a GPRS system
DE10038182 2000-08-04
PCT/DE2001/001757 WO2001089232A2 (en) 2000-05-16 2001-05-09 Method for transferring a tunnel between nodes in a gprs system

Publications (2)

Publication Number Publication Date
EP1282997A2 true EP1282997A2 (en) 2003-02-12
EP1282997B1 EP1282997B1 (en) 2004-07-28

Family

ID=26005699

Family Applications (1)

Application Number Title Priority Date Filing Date
EP01944918A Expired - Lifetime EP1282997B1 (en) 2000-05-16 2001-05-09 Method for transferring a tunnel between nodes in a gprs system

Country Status (9)

Country Link
US (1) US7283497B2 (en)
EP (1) EP1282997B1 (en)
CN (1) CN1225939C (en)
AT (1) ATE272301T1 (en)
CA (1) CA2408993C (en)
ES (1) ES2225563T3 (en)
HK (1) HK1057303A1 (en)
TW (1) TW525397B (en)
WO (1) WO2001089232A2 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9298560B2 (en) 2013-05-16 2016-03-29 Tektronix Texas, Inc. System and method for GTP session persistence and recovery

Families Citing this family (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1246479A1 (en) * 2001-03-26 2002-10-02 Lucent Technologies Inc. GPRS mobile telecommunications systems
US8041819B1 (en) * 2002-03-19 2011-10-18 Cisco Technology, Inc. Method and system for providing network services
US7830853B2 (en) * 2002-12-06 2010-11-09 Qualcomm Incorporated Techniques for supporting GSM to W-CDMA reselection
US7602753B2 (en) * 2003-03-12 2009-10-13 Lg Electronics Inc. Apparatus and method for tracing GPRS tunnel protocol resource
US7490152B2 (en) * 2003-04-11 2009-02-10 Alcatel-Lucent Usa Inc. Version caching mechanism
CN1283055C (en) * 2003-08-15 2006-11-01 华为技术有限公司 Treatment method for establishing context request of packet data protocol
EP1702480A1 (en) * 2003-12-30 2006-09-20 Telefonaktiebolaget LM Ericsson (publ) System and method relating to mobility in a mobile communications system
GB0402183D0 (en) * 2004-01-31 2004-03-03 Alcyone Holding S A Wireless mobility gateway
US8824430B2 (en) * 2004-01-31 2014-09-02 Athonet Srl Wireless mobility gateway
US7440459B2 (en) * 2004-02-02 2008-10-21 Lucent Technologies Inc. Methods of detecting protocol support in wireless communication systems
US20050221770A1 (en) * 2004-03-31 2005-10-06 Shipshock Michael D User configurable pre-activated GPRS PDP context handling for improved activation time
CN100334895C (en) * 2004-06-25 2007-08-29 华为技术有限公司 Request of side-response movable table service of network in universal group wireless service
US7614058B2 (en) * 2004-09-21 2009-11-03 Dell Products L. P. System and method for virtual media command filtering
CN1306766C (en) * 2004-09-30 2007-03-21 华为技术有限公司 Service recognition and route method in multimedia broadcast multicast service system
KR100641174B1 (en) 2004-10-14 2006-11-02 엘지전자 주식회사 Method for activating packet data protocol of general packet radio service
US20070213057A1 (en) * 2006-03-08 2007-09-13 Interdigital Technology Corporation Method and apparatus for supporting routing area update procedures in a single tunnel gprs-based wireless communication system
CN101128043B (en) 2006-08-15 2011-02-02 华为技术有限公司 Data processing method for switching between systems or change
CN100486381C (en) * 2006-08-18 2009-05-06 中兴通讯股份有限公司 Method for GGSN in packet domain to obtain information of starting up single tunnel by SGSN
CN101686443B (en) * 2007-08-15 2013-10-09 华为技术有限公司 Information transfer method and information transfer device
CN101370001B (en) 2007-08-15 2011-01-05 华为技术有限公司 Information transfer method
CN101394592B (en) * 2007-09-19 2012-04-04 中兴通讯股份有限公司 Dissolving method for non-uniformity of MBMS UE in SGSN and GGSN
CN101472312B (en) 2008-01-31 2010-07-07 华为技术有限公司 Control method and communication system for releasing resource as well as relevant equipment
JP4740368B2 (en) * 2009-12-24 2011-08-03 株式会社エヌ・ティ・ティ・ドコモ Mobile communication method and switching center
WO2012031217A1 (en) * 2010-09-03 2012-03-08 Huawei Technologies Co., Ltd. System and method for virtual private local area network service to use the flow aware pseudowire
US8982842B2 (en) * 2012-11-16 2015-03-17 Tektronix, Inc. Monitoring 3G/4G handovers in telecommunication networks
CN104040987B (en) * 2012-12-27 2017-05-24 华为技术有限公司 User plane data transmission method, mobility management network element, evolved node b and system
US9860325B2 (en) * 2014-03-18 2018-01-02 Axis Ab Tunnel broker in a service oriented architecture
US10601610B2 (en) * 2017-04-05 2020-03-24 Nokia Of America Corporation Tunnel-level fragmentation and reassembly based on tunnel context
US11050789B2 (en) 2017-06-15 2021-06-29 Palo Alto Networks, Inc. Location based security in service provider networks
US10812532B2 (en) 2017-06-15 2020-10-20 Palo Alto Networks, Inc. Security for cellular internet of things in mobile networks
US10721272B2 (en) 2017-06-15 2020-07-21 Palo Alto Networks, Inc. Mobile equipment identity and/or IOT equipment identity and application identity based security enforcement in service provider networks
US10708306B2 (en) 2017-06-15 2020-07-07 Palo Alto Networks, Inc. Mobile user identity and/or SIM-based IoT identity and application identity based security enforcement in service provider networks
US10834136B2 (en) 2017-06-15 2020-11-10 Palo Alto Networks, Inc. Access point name and application identity based security enforcement in service provider networks
CN113518387B (en) * 2020-04-10 2023-07-21 华为技术有限公司 Wireless network communication method and communication equipment based on internet protocol version IPv6

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FI972725A (en) * 1997-06-24 1998-12-25 Nokia Telecommunications Oy re-routing
FI108192B (en) * 1998-03-19 2001-11-30 Nokia Networks Oy A method and apparatus for controlling quality of service in a mobile communication system
DE59911543D1 (en) 1998-07-06 2005-03-10 Siemens Ag Forwarding a packet data connection in a mobile network
FI105969B (en) * 1998-08-10 2000-10-31 Nokia Networks Oy Quality of service management in a mobile communication system
US6839339B1 (en) * 2000-02-02 2005-01-04 Lucent Technologies Inc. Header compression for general packet radio service tunneling protocol (GTP)-encapsulated packets

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO0189232A2 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9298560B2 (en) 2013-05-16 2016-03-29 Tektronix Texas, Inc. System and method for GTP session persistence and recovery

Also Published As

Publication number Publication date
ES2225563T3 (en) 2005-03-16
US7283497B2 (en) 2007-10-16
US20030153296A1 (en) 2003-08-14
CN1225939C (en) 2005-11-02
WO2001089232A2 (en) 2001-11-22
ATE272301T1 (en) 2004-08-15
WO2001089232A3 (en) 2002-04-04
HK1057303A1 (en) 2004-03-19
TW525397B (en) 2003-03-21
CA2408993A1 (en) 2002-11-14
CN1429465A (en) 2003-07-09
EP1282997B1 (en) 2004-07-28
CA2408993C (en) 2008-01-08

Similar Documents

Publication Publication Date Title
EP1282997B1 (en) Method for transferring a tunnel between nodes in a gprs system
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
DE69828572T2 (en) METHOD AND DEVICE FOR DEFLECTING A CONNECTION IN A CONNECTION IN A REMOTE DETECTOR NETWORK WITH A VARIETY OF NETWORK ELEMENTS
DE19742681C2 (en) GPRS subscriber selection from several Internet service providers
EP1273147B1 (en) Method for operating a mobile radio network
DE10302788B4 (en) Device and method for rearranging TFTs in a mobile communication system
DE69923673T2 (en) RAU optimization for UMTS in the URA state
DE60216791T2 (en) ADDRESS TRANSFER AND CORRELATION OF MESSAGES BETWEEN NETWORK NODES
DE60133754T2 (en) COMMUNICATION SYSTEM THAT SUPPORTS THE WIRELESS TRANSMISSION OF PACKAGE DATA AND METHOD AND ARRANGEMENT THEREFOR
DE60001466T2 (en) SRNS LAYING IN A UMTS NETWORK
DE60032229T2 (en) AUTOMATIC IP ADDRESS AWARD FOR MOBILE OPERATING DEVICES
DE69935397T2 (en) Method and device for real-time data transmission in a packet radio network
DE19950653B4 (en) Method for operating a cellular network
DE60106457T2 (en) ALLOCATION OF DATA TRANSMISSION OPERATORS IN THE PACKAGED DATA TRANSMISSION
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
WO2002087160A2 (en) Heterogeneous mobile radio system
DE10039193A1 (en) Method and arrangement for performing a handover in mobile data transmission systems with data duplication
DE60316032T2 (en) SEAMLESS CHANGE OF THE RADIO ACCESS NETWORK DEPENDING ON THE REQUIRED SERVICE QUALITY (QOS)
WO2007025905A1 (en) Communications system, switching node computer and method for determining a control node
EP1364549B1 (en) Method for relocating the diversity point of a mobile station in a radio access network
DE60300616T2 (en) A method for routing messages between mobile and cell control functional units from a distributed radio access network
EP1266493B1 (en) Method for transmitting a data packet from a first network unit to a second network unit in a data network
DE10038182C2 (en) Procedure for laying a tunnel between nodes of a GPRS system
DE19833069A1 (en) Terminal device-to-exchange modem connection method via local networks

Legal Events

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

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20021028

AK Designated contracting states

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE TR

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

17Q First examination report despatched

Effective date: 20040316

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

AK Designated contracting states

Kind code of ref document: B1

Designated state(s): AT DE ES FR GB

REG Reference to a national code

Ref country code: GB

Ref legal event code: FG4D

Free format text: NOT ENGLISH

REG Reference to a national code

Ref country code: IE

Ref legal event code: FG4D

Free format text: GERMAN

REF Corresponds to:

Ref document number: 50103011

Country of ref document: DE

Date of ref document: 20040902

Kind code of ref document: P

REG Reference to a national code

Ref country code: ES

Ref legal event code: FG2A

Ref document number: 2225563

Country of ref document: ES

Kind code of ref document: T3

REG Reference to a national code

Ref country code: IE

Ref legal event code: FD4D

ET Fr: translation filed
PLBE No opposition filed within time limit

Free format text: ORIGINAL CODE: 0009261

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

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

26N No opposition filed

Effective date: 20050429

REG Reference to a national code

Ref country code: FR

Ref legal event code: TP

REG Reference to a national code

Ref country code: GB

Ref legal event code: 732E

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

Ref country code: ES

Payment date: 20090521

Year of fee payment: 9

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

Ref country code: AT

Payment date: 20090515

Year of fee payment: 9

Ref country code: DE

Payment date: 20090525

Year of fee payment: 9

Ref country code: FR

Payment date: 20090513

Year of fee payment: 9

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

Ref country code: GB

Payment date: 20090522

Year of fee payment: 9

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

Effective date: 20100509

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

Ref country code: AT

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

Effective date: 20100509

REG Reference to a national code

Ref country code: FR

Ref legal event code: ST

Effective date: 20110131

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

Ref country code: DE

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

Effective date: 20101201

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

Ref country code: FR

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

Effective date: 20100531

REG Reference to a national code

Ref country code: ES

Ref legal event code: FD2A

Effective date: 20110714

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

Ref country code: ES

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

Effective date: 20110704

Ref country code: GB

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

Effective date: 20100509

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

Ref country code: ES

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

Effective date: 20100510