Method for transferring a tunnel between nodes in a GPRS system.

The present invention relates to methods for Transferring a tunnel from a first controlling Kno th of a GPRS system (General Packet Radio Service) on a second.

The transferring a tunnel is required when a mobile terminal that uses the tunnel in question, from the catchment area of ​​the first controlling node in the switches of the second. This change results in an RAU (Routing Area Update) episode during which data about the PDP context of the terminal from the first to two th controlling nodes are passed. The above transmission of this data is in the form of messages to the GTP protocol (GPRS Tunnelling Protocol). news the GTP protocol are inter alia to the establishment and Clearing PDP contexts and for passing of PDP contexts in the case of routing area updates ver turns. For details about the GTP protocol is on the specification writing <b>3</b>G TS <b>23.060</b> Technical specifics tion Group Services and System Aspects; General Packet Radio Service (GPRS); Service Description; Stage<b>2</b> (Re lease <b>1999</b>), For example in the version V3.3.0 April 2000 of the 3GPP (3^rd Generation Partnership Project, referenced www.3GPP.ORG).

The serving between two nodes transmitted data allowing the second controlling Node aufzu contact to a gateway node take and from there the required full In to procure mation about the context that it him he possible to switch the GTP tunnel, so that the Service for the terminal without interruption continued Who the can.

have been received for the GTP protocol two versions standardized, firstly the GTP Version 0, as Re lease <b>98</b> or. <b>97</b> referred, in GSM 09.60; on the other hand GTP Version <b>1</b>, Also known as Release <b>99</b> referred, in the be already mentioned publication TS <b>23.060</b>, The standardization tion version <b>1</b> demands that node according to version <b>1</b> with such a Version 0 can collaborate sol len and that the GTP tunnel with the respective höchstmögli chen version are operated.

Thus a receiving node the GTP version can recognize, according to a received message he has assumed the messages each carry a head in Indicator that it the assignment to the respective version allows. Messages exchanged in accordance Version<b>1</b> been created are, are nodes, the older of the Version 0 or more Standardization work, can not be interpreted. A Kno of the Version <b>1</b> must therefore be able, depending on GTP- Version that a node to which it sends messages to used, these messages either version <b>1</b> or Version create 0th

A major difference between Version 0 and version <b>1</b> the GTP protocol is the method by a message matches the established tunnel relationship instance is associated with a PDP context. With Version 0 be this so-called tunnel identifiers, abbreviated TIDs used that transfer as part of the message who to and from the IMSI (International Mobile Subscriber Identity) and the NSAPI (Network Layer Service Access Point Identifier) ​​composed. The IMSI is the world's unique identifier of a participant; the NSAPI refe enced a multiple PDP contexts that are part of the participants can be assigned. Since the Tunnel Identifier with 12 byte length are quite bulky, are at their Place additional so-called flow label with a length of 2 bytes used the rapid association of allow messages to a context. The Flow La bels are not necessarily assigned uniquely because they only have a range of about 65,000 and significantly more contexts can be set up per node.

The flow labels are each in Aktivie awarded tion of a GTP tunnel; each in a tunnel participating node in this case signals the counter node, with wel chem FlowLabel he subsequent messages on this Tunnel or what is equivalent, for this PDP Kon text, will receive. In the first message in the frame the construction of a tunnel from a controlling node is sent to a gateway node (Create PDP Con text Request), the flow label to 0, because the gateway Node no flow label awarded, and the Tunnel identifier is transmitted; After all subsequent judge of this tunnel must with the gateway Kno th allocated flow label are sent. exactly genome men are awarded two flow label, a Si gnalisierung and one for data. The following is but le diglich the flow label for signaling considered.

In the GTP version <b>1</b> be called TEID (Tunnel Endpoint Identifier) ​​assigned to the same radio tion as have the flow label, but a length of 4 hold Byte. The TEID are therefore the flow label not compatible to version 0, but they can clearly be awarded. The well-known from the Version 0 tunnel Identifier is in messages of the Version <b>1</b> no longer ent hold. IMSI and NSAPI, the assignment of a unique enable message to a PDP context are only in the first message (Create PDP Context Request) from the BE serving node containing the gateway node.

function within the respective version both versions of the GTP properly. In the standardization tion is required that a node for Version <b>1</b> also the GTP Version 0 supports, therefore is backward compatible. This is required so that nodes of different Ver sions can work together.

However, problems arise when a mobile radio subscriber to the node in a network different contains Licher versions, moves while the Einzugsbe rich of a serving node in the other changes. This change results in an RAU (Routing Area Up date) the result in which a tunnel from the node in the sen catchment area of ​​the participants stopped previously has passed to the node of the new catchment area becomes. Under this procedure, data must have the PDP context from the old to the new nodes using GTP messages are passed. These data be urges the new nodes to contact the gateway Kno th record and switch the GTP tunnel so that the service for the subscriber disruption continues can be set. If all three of the switching of the is tunnel nodes involved the same GTP version hear the change is easy. Even if two of them are nodes of the Version 0 and the third a node of the Version <b>1</b> is, there is no problem, since all the information exchanged between nodes After must direct those GTP Version 0 be. If all recently two nodes of the Version <b>1</b> and the third of the Version 0 belong to, the fact that the two nodes by version <b>1</b> another with version-1 messages and the third node commu with Version 0 messages cate to difficulties. Three cases have to distinguish the.

<ul><li>1. The mobile subscriber moves from one first controlling node of the Version 0 to a second by Version <b>1</b>, This situation must for the communication of the first controlling node with the second and with the gateway node GTP Version 0 is used; communication between rule gateway node and the second serving Node takes on the version <b>1</b> instead of. When setting up the Tunnel assigns the gateway node, a flow label to which for the first controlling node Tagging belonging to the Tunnel After used direct. If the two controlling Kno take th contact to the transfer of the tunnel prepare, they communicate using Version 0, and the first controlling node supplies the second with the Flow Label, originally from the gateway node the tunnel has been assigned. To REQUIRED chen context data of the tunnel by the gateway node to obtain, should the second controlling node a Message with this flow label to the gateway Node can send. The second use Kno However, th and the gateway node communicate the version <b>1</b>That the transfer of flow labels does not allow. Although Instead the flow label could be a TEID after version <b>1</b> are transmitted, but is a such non defi in the gateway node for the tunnel ned. The gateway node may thus consist of the the channel no message of the GTP Version <b>1</b> Assign NEN. Because the message "Update PDP Context Request" neither IMSI nor NSAPI contains, is the gateway Node also then not in a position to the context to see if he ignored the TEID.</li><li>2. The mobile subscriber moves from one first controlling node of the Version <b>1</b> to a the version 0. In this case, in the communication tion between the first controlling node and the gateway node as part of the construction of Tunnels GTP version <b>1</b> been used, ie it is although a TEID specified for the tunnel, but no flow label. For communication between the two controlling nodes must GTP Version 0 ver be used, but this only allows flow label. One way to the TEID to the second node to transmitted, is not, and even if they would, they could not handle this. The second Bedie Designating node therefore has no way to flow Labels find out with which it needed the Context data from the gateway node could request.</li><li>3. The mobile subscriber moves from one controlling node of the Version <b>1</b> to another the same version, but the gateway node processing tet the version 0. In this case, communicating the controlling nodes with each other on the version <b>1</b>, With the gateway node However, according to version 0 Gateway node thus allocates build a Tun nels a flow label, this, however, can not by first be transferred to the second node, so that this not the context information from the Gateway node can query.</li></ul>

The object of the invention is procedural use reindeer for transferring a tunnel from a first the node of a GPRS system to a second attire ben, which will work even when under the be controlling node and the gateway node at least a node of the Version 0 and another on the version <b>1</b> of GTP protocol are.

The object is for the case that the first Bedie Designating node is a node of the Version 0 and the second controlling node and the gateway node node after version <b>1</b> are achieved by a method Claim 1. This provides that the request for adaptation of Context that the second controlling node to the gate way nodes depends, details of the IMSI and NSAPI of the tunnel in question contains. This information allows the Gateway node, a unique match to a produce stored context and so the needed to deliver context data to the second node.

The required details of the IMSI and NSAPI can be transmitted in a very simple manner by the second controlling node and the gateway node to built using Version 0 of GTP protocol tunnel un continue to operate ter the same protocol version. In this Contains the case from the second node to the gateway bone th to send request for adaptation of the context, the message "Update PDP Context Request", from the front in this necessary information. This solution includes So that the protocol that the second controlling Node when communicating with the gateway node applies, depending on the history of the tunnel to which include the exchanged messages. When a Tunnel from the second node itself or by another Node of the Version <b>1</b> has been established, finds the Communication with the gateway node of the Version <b>1</b> instead of; The tunnel was originally from a node built on the version 0, so running to communicate with the gateway node continues to version 0, although both involved nodes Version <b>1</b> dominate.

Such control of the used version can be realized in a simple manner if the first be controlling node first a the Tunnelverlegungsvor gang introductory message (SGSN Context Response) to the second controlling node sends the second Bedie nenden node version of this message for his on call for adaptation of the context to the gateway Nodes used and these all addressed to him by addressed in version answered, in which he received them Has.

An alternative possibility is that the second Node as a request for adapting the tunnel to instead of the conventional message "Update PDP Context Request "a message of the" Create PDP Context Re quest "to version <b>1</b> sends. This message is in accordance with the above-cited document T5 29,060 by the receiving Gateway node processed correctly, that the existing PDP context is again found and the changing Pa parameters are replaced. In this way, both the Tunnel for the second controlling node installed and in the version changes.

Still alternatively, it may be provided that the message "Update PDP Context Request" with egg nem TEID can be sent, which has the value 0, and in addition to the TS in accordance with <b>23.060</b> provided Infor mationselementen additionally contains the IMSI and NSAPI to a mapping to the appropriate PDP context in Gateway node to allow.

In the case that the second controlling node or the gateway node is a node of the Version 0 and each other node of the Version <b>1</b> are, the Object is achieved by the method of claim 5, wherein which a flow label, the second controlling node and require the gateway node to the tunnel from the first to be able to transfer to the second controlling node, the second controlling the first node available is provided.

There are different possibilities to make proper the flow label. When the gate way nodes a node of the Version <b>1</b> is the structure of So after channel version <b>1</b> has taken place, then the Tunnel build only a TEID but no flow label been assigned. In this case it is expediently as the first controlling node, assigning the one Flow label makes the tunnel.

A first variant provides that the first Bedie Designating the context node a flow label with a value mapped, by the diversion of a tunnel a controlling node of the Version <b>1</b> to a serving Node is specific to version 0, ie the different is by all Flow Labels that of the communication regularly Version 0 working node uses who the. The second controlling node can to receive such a specific flow labels respond by instead of a message "Update PDP Context Request", the he would normally send to the gateway node, when a correct flow label of a first Bedie nenden node would have received the same version, a Message "Create PDP Context Request" to the gateway Node sends the IMSI and NSAPI contain and therefore a to uniquely identify the appropriate context on Gateway node allows. Alternatively, provided be that the second controlling node a message "Update PDP Context Request" to the gateway node sends, but the deviation from the current protocol the version <b>1</b> additionally contains the IMSI and NSAPI and so again suitable for identification. Such Pre dure is possible because the existing standard no PDP Update requests with a flow label 0 and whose Ver processing is thus not standardized.

A second variant of the method, which also is applicable when the gateway node to Ver sion <b>1</b> and the second controlling node of the Version 0 ar BEITEN, provides that the gateway node to each of the first controlling node of the Version <b>1</b> established context not only a TEID associates, but also a defined procedure has, after it each according Ver sion <b>1</b> established context or more precisely its TEID a flow can assign label. Thus, corresponding to the gate way each node of the GTP Version <b>1</b> established context a TEID and a flow label. Conveniently, the Gateway node already in the award of the TEIDs represents from flow labels resulting in the sense berücksichti gen that an effective identification of contexts to hand the flow labels. The same procedure is also the first controlling node. If a tunnel, the serving of the first node GTP Version <b>1</b> has been established, on a second controlling node are redirected to version 0 must, as the first controlling node can by applica tion of the process directly the correct value of the Calculate flow labels and the second controlling Kno provide th available, based on which the gateway Kno th can identify the PDP context. Thus, the second controlling node to the gateway node in the moving appeal chen way as if he a be the tunnel get passed controlling node of the Version 0 would have.

A preferred because particularly simple procedural ren for allocating the flow label to a TEID is the Equate the flow label to the two least significant Bytes of the TEID. If, however, the gateway node Node of the Version 0 and the two controlling nodes Node of the Version <b>1</b> are, then the assignment of a Flow Label to the tunnel during its construction from the gate way nodes have been made, and this flow label is known to the first controlling node. to this Flow label to the second node - over version <b>1</b>-After judge - to convey, it is expedient for it in the TEID Field of a Version <b>1</b>Message to "pack".

Since the flow label the TEID field does not fill, it is advantageously possible, the remaining space in the TEID field for transmitting a predetermined value to use, which does not occur otherwise in a TEID and where the second controlling node to recognize therefore capable, that it is the transmitted value is not egg NEN TEID but a "packed" flow label is, and can process the value accordingly correct. Such a predetermined value may be,., 0.

Embodiments will now be based of the drawings explained in more detail. Show it:

<b>Fig.</b> 1 to 3 the possible constellations in Handover of a tunnel between two controlling nodes with the participation of two nodes of the GTP Ver sion <b>1</b> and a node of the Version 0;

<b>Fig.</b> 4 to 6 the signaling procedure for the Handover of the tunnel in the various Constellation NEN.

In the constellation of <b>Fig.</b> 1 is the first Bedie Designating node SGSN 1, through which the tunnel for the terminal MS has been originally constructed by a node GTP Version 0; it communicates with the gateway node GGSN and the second controlling node according SGSN2 GTP Version 0, that the exchanged messages are characterized by a flow label and TEID. The gateway Node GGSN and the second controlling node SGSN2 communicate with each other on the version <b>1</b> with by TEIDs marked messages.

<b>Fig.</b> 4 shows the flow of signaling between tween a terminal MS and the three nodes SGSN 1, SGSN2 and GGSN one hand when activating a PDP Context and the other part in the transfer of the GTP Tun nels. Here Headlines accordance with in GTP Version 0 lean, messages of the Version <b>1</b> represents by bold arrows posed. Messages that failed to be between nodes be exchanged and therefore not ge to the GTP protocol connected are exchanged, such as with the terminal MS Messages are shown in dashed lines.

In step <b>1</b> sends the terminal MS a require- tion for the activation of a PDP context (PDP Activate Context Request) to the SGSN0, which inter alia NSAPI and nature and quality of the desired service specified. The controlling node SGSN 1 aims towards a request "Create PDP Context Request" to PDP Version 0 to the gateway node GGSN, in the IMSI and NSAPI are the gateway node (Step <b>2</b>). The gateway node then generates a new entry in its PDP context table, which he he permits, data packets of the terminal MS between the SGSN1 and an external, in the figures not dargestell th PDP network to route and to calculate charges, and allocates a flow label to. As confirmation sending in step <b>3</b> a message "Create PDP Context Response" to back to the first controlling node SGSN 1, to the divided flow label contains. The first controlling node itself confirms the establishment of the context of the End device MS with a message "Activate PDP Context Ac cept "(step <b>4</b>).

Through the associated flow label is the SGSN 1 capable of data packets of the terminal MS, the new to the furnished context include, so to indicate that the gateway node GGSN to the data packets ande rer terminals or associated by other contexts As can distinguish packets occur the same terminal.

The process of transferring a tunnel starts since with that the terminal in step S a prompt "Rou ting Area Update Request "serving the second Node SGSN2 sends. This node SGSN2 after works GTP Version <b>1</b>,

Through a message "SGSN Context Request" GTP Version 0 (step <b>6</b>) It is the first use the node SGSN 1 initially known that the context to be passed; the SGSN 1 confirms this by a Message "SGSN Context Response" (step <b>7</b>) And be starts, coming from the PDP network and for the part subscriber station MS to buffer certain data packets. After the step <b>8th</b> the new controlling node SGSN2 his willingness to accept data through a has message "SGSN Context Acknowledge" confirmed lei tet the node SGSN 1, the buffered data packets in step <b>9</b> to node SGSN2 on.

In order to achieve that, for the subscriber station MS specific data packets no longer SGSN 1 but routed directly to the new controlling node SGSN2 be, the gateway node GGSN need on the amendments tion to be kept informed. This is done by a Aufforde tion for adaptation of the context, in step <b>10</b> from SGSN2 is sent to the gateway node GGSN.

While in the case of acquisition of a context from a controlling node of the same version of the Call for adaptation of the context a message "Update PDP Context Request" would be used the second controlling node in the case considered here as Aufforde tion a message of the "Create PDP Context Re quest ". This message contains, in contrast to message "Update PDP Context Request" under GTP version <b>1</b> IMSI and NSAPI of the terminal MS. The gateway node he waiting for a message of this type is not to cooperate with egg nem defined TEID is sent; He therefore attempts not to interpret such a TEID the message, but identifies the relevant context in the of him out directly on the basis of the IMSI and NSAPI. The context entry thus found is updated, by him the new controlling node SGSN2 and GTP version is assigned, according to which the communication tion between GGSN and controlling node is complete.

If the gateway node success this operation has executed successfully, he confirmed this in step <b>11</b> the new SGSN2 by a message of the "Create PDP Context Response "or" Update PDP Context Re sponse "may be.

Before the terminal MS in step <b>18</b> an Affirmation tion of its RAU request "Routing Area Update Ac cept receives "still finds a message exchange of at the controlling node to the Home Location Register HLR of the mobile communications system instead, in de ren course the assignment of the terminal MS to the new controlling node SGSN2 noted in this register becomes. These steps do not differ from a GSM or UMTS radio communication known Steps and therefore will not be detailed here described ben.

As an alternative to using the message "Create PDP Context Request "in step <b>10</b> may also against above the applicable GTP Version <b>1</b> slightly modified Type message "Update PDP Context Request" is be used. This modified message contains a TEID with the value 0 and IMSI and NSAPI of the terminal MS. The gateway node GGSN does not itself TEIDs with value 0. When an "Update PDP Context Re quest "with TEID = 0 receive, so can it decided be that the TEID not by the gateway node GGSN has been awarded and that, therefore, no entry in corresponding context directory of GGSN. Therefore, without prejudice to the GGSN in a such a case on the IMSI and NSAPI back, to the of the "Update PDP Context Request" person concerned identify NEN context and as described above to update.

Another alternative is that the second Bedie Designating nodes for update notice step <b>10</b> in each case that GTP version selected, in which it in Step S7, the message "SGSN Context Acknowledge" he has hold, say the Version 0. In this way, he gives Compared to the GGSN for the affected context as Version 0 nodes, can this be the appropriate identify context by specifying a flow label, and replaced by the gateway node response messages also in Version 0. In this way, the context is the new controlling node SGSN2 allocated correctly even if the GTP version being used remains the same.

A second method for transferring the tunnel the first controlling node GGSN1 to second GGSN 2 differs from in <b>Fig.</b> 4 shown signaled sierungsablauf in that also the second controlling Nodes in step <b>10</b> for his invitation to Aktualisie tion of the context version 0 used in which it is already in step <b>7</b> the flow has received label for the tunnel. The gate way nodes responds in step <b>11</b> also under Using Version 0. This means although second be serving node and gateway node GGSN SGSN2 Ver sion <b>1</b> dominate, they lead the aufgebau under Version 0 th tunnel using Version 0 further.

Since in this second method, the version the tunnel when tilted to the second serving Node does not change, special precautions are erforder Lich, if the tunnel a second time, a third be controlling node of the Version <b>1</b> must be allocated.

When passing this version 0 tunnel of egg nem second serving to a third node, both version <b>1</b> apply, the same problems arise as in the case that one between a first controlling Node of the Version <b>1</b> and a gateway node according Version 0 tunnel constructed to a second serving Node of the Version <b>1</b> must be allocated. Some of later described solutions to this problem are thus also applicable to this case.

<b>Fig.</b> 2 shows a configuration in which a first Node SGSN 1 of the GTP Version <b>1</b>, A gateway node GGSN GTP Version <b>1</b> and a second controlling Node SGSN2 kommunizie Version 0 together ren. The first controlling node SGSN 1 and the gateway Node GGSN using one to another through tunnels Endpoint Identifier TEID messages marked the version <b>1</b>, The two controlling nodes SGSN 1 and SGSN2 use each other by flow labels and TEID flagged messages by Version 0th

The sequence of steps for constructing and Transferring the tunnel, which in <b>Fig.</b> 5 is shown, corresponds to the of <b>Fig.</b> 4. However, for the various Messages used GTP versions, again by in thick and thin arrows different. The Context request "Create PDP Context Request" and the Answer in steps <b>2</b> and <b>3</b> corresponding in Objective of which <b>Fig.</b> 4, but with the sub- difference that for them GTP version <b>1</b> is used, and in that consequently, the gateway node GGSN the context ei NEN tunnel endpoint identifier TEID assigns and this reports back to the first controlling node SGSN 1.

The requirement "SGSN Context Request" to GTP Version 0, the second controlling node SGSN2 in step <b>6</b> directed at the first, is that of a "SGSN Context Response" answered the version 0th at a running purely Version 0 channel assignment contained this message in their information element (IE) "PDP Context" a be the gateway node to the first serving node for this context, allocated Flow La bel. Here, since such a flow label does not exist, Instead, the first controlling node a flow label according to a predetermined method from the Gateway node GGSN TEID assigned is calculated. A particularly simple method for calculation of the Flow labels, respectively, the two least significant bytes of a using TEID as the flow label and the two höherwer neglecting term. This flow label is from second controlling node SGSN2 in his step <b>10</b> addressed to the gateway node Invitation to Kon text adjustment used. Since the gateway node GGSN the method "known" is, after the first use Node GGSN1 flow generated labels from TEIDs, he can at Receiving the corresponding flow label in a Auffor ation for context updating in step <b>10</b> the second controlling node easily a small number of contexts to locate in his directory of the Aktua tion could be affected. Among these the tatsächli to determine chen concerned, is then readily pos Lich.

Another way to the context aktuali Sieren, is the use of flow labels with the value 0, similarly as described above with reference to <b>Fig.</b> 4 described. da flow not assigned labels with this value otherwise, or al lenfalls of a controlling node of the Version 0 News of the "Create PDP Context Request" ver be used, in which a flow label of the tunnel for Time of transmission of the message is not yet known can the gateway node GGSN, if he be the second serving node SGSN2 a message with a sol chen flow label with value 0 receives, conclude that the flow label not been allocated by itself can and that, therefore, an association of the message ei a tunnel, ignoring the flow label and using also transmitted Identifizierungsin formation, ie the ent in TID in the message header preserved IMSI and NSAPI of the terminal, must take place.

As yet another alternative, a supplement are provided by GTP version is 0, in which the second controlling node SGSN2 a message of type "Create PDP Context Request" sends, when it from the first controlling node a message set, with on 0 Flow Label receives.

When in <b>Fig.</b> third constellation shown 3 are both serving node SGSN 1 and SGSN2 node GTP Version <b>1</b> and the gateway node GGSN is a Node of the Version 0. The construction of the tunnel and its Handover from the first controlling node SGSN 1 to the second SGSN2 are in <b>Fig.</b> 6 is shown. The construction of the Tun nels in steps <b>1</b> to <b>4</b> creation is the same as with respect on <b>Fig.</b> 1 and 4 will be described. Among themselves must two controlling nodes Version <b>1</b> apply. to the between the controlling node SGSN 1 and gateway Kno th GGSN negotiated flow label to the second Bedie transfer nenden node SGSN2, it must therefore be a Connection version <b>1</b> to get promoted. to this Flow label for the second controlling node SGSN2 transport, it complements the first controlling node SGSN 1 two higher bytes to the format of TEID, the in step <b>7</b> (SGSN Context Response) to the second bone th SGSN2 is transmitted.

A first variant of the method according to who the then two in <b>Fig.</b> Darge 6 as dashed arrows presented exchanged messages: The node SGSN in step <b>10</b>'A request for context matching (Up date PDP Context Request) to Version <b>1</b> at the gateway Node GGSN. Since this only version 0 dominates, signaled he Siert the second node SGSN2 (step <b>10</b>"), That it the Prompt can not handle. This tells the second node that the gateway node, a version-0- Message with a flow label required, and produced represents aufhin in step <b>10</b> A new call, this time to Version 0, in which they, the two low-order bytes of the received from the first node SGSN 1 TEID as Flow Label inserts.

A second variant according to the first use controlling node SGSN 1 two bytes with a PRE- ted value to the tunnel the allocated flow label on supplement the format of TEID. This predetermined Value, here 0, should be in the normal production of a PDP context of Version <b>1</b> not be forgiven, so that the second controlling node SGSN2 to the value of 2 bytes can recognize that it is in the step <b>7</b> For the mat a TEID transmitted to him information in action probability is a flow label, this restores and thus for the request for updating the Kon texts in step <b>10</b> from the outset that of the gateway Node GGSN interpretable message format of Ver sion can choose 0th

Since in this second variant by the second BE serving node SGSN2 for Aktualisierungsaufforde tion version used not in the dialogue between the second Node SGSN2 and gateway nodes GGSN of the latter is set, but by the Message Version SGSN Context Response is determined, this is Va variant for the case already mentioned above that a tunnel which originally between a serving Node SGSN 1 Version 0 and Version 1 GGSN constructed and then to a second serving node SGSN2 by Version <b>1</b> while maintaining originally for used the tunnel protocol version to a third controlling node of the Version <b>1</b> is folded.

According to a third variant, the step <b>7</b> to transfer context information to the effect he also panded be that both flow label and TEID can be transported, each marked as such distinguished. This can occur by adding an extra carried out the data field to the context information, which the Flow Label receives, so that, if known, both TEID as the flow label to the second controlling node SGSN2 can be passed. It is also conceivable Added easy Flags whose status to In halt the TEID field of a message as a TEID or Flow label identifies. Thus, the range of values ​​for TEID not restricted.

This third version is egg for apportioning nes operated using Version 0 tunnel to a third be controlling node of the Version <b>1</b> suitable.

A fourth possibility is also to be between serving Node GTP version apply 0th Although be begins the second controlling node GGSN 2 dialogue with the first node SGSN 1 with GTP Version <b>1</b>What the first Node (SGSN 1) refers; he would therefore normally with GTP Version <b>1</b> reply. However, by the first Kno th SGSN 1 "does not understand" GTP Version <b>1</b> message pretending he causes the second controlling node SGSN2 to use version 0, so that the flow label can be transferred. This variant allows the Apportionment of a Version 0 tunnel while maintaining the Version to a third controlling node.