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

The present invention relates to methods for folding ei nes tunnel from a first controlling node of a GPRS System (General Packet Radio Service) on a second.

The transferring a tunnel is needed, when a mobile Terminal that uses the tunnel in question, from the feeder area of ​​the first serving node in the second changes. This change results in an RAU (Routing Area Update) the effect of the in the course of data on the PDP context weiterge terminal from the first to the second controlling node be sufficient. The transmission of this data is in the form messages after the GTP protocol (GPRS Tunnel Proto protocol). News of the GTP protocol are among others Construction and dismantling of PDP contexts and for handing USAGE of PDP contexts in the case of routing area updates det. For details about the GTP protocol to the Specification writing 3G TS 23.060 Technical Specification Group Services and System Aspects; General Packet Radio Ser vice (GPRS); Service Description; Stage 2 (Release 1999), the Example in version V3.3.0 April 2000 the 3GPP (3^rd Generation Partnership Project, www.3GPP. referenced ORG).

The serving between two nodes transmitted data allowing the second controlling node, a contact take a gateway node and from there the be constrained complete information about the context to be create, allowing it to switch the GTP tunnel scarf th, so that the service for the terminal without interruption can be continued.

of the GTP protocol previously standardized two versions to date, firstly the GTP Version 0, also known as Release 98 or 97 denotes, in GSM 09.60; secondly GTP Version 1, also called Release 99, in the abovementioned publica publication TS 23.060. The standardization of version 1 demands that node according to version 1 with such by Version can work together to 0, and the GTP tunnels with the highest possible version are operated.

Order that a receiving node can identify the GTP version, according to a received message has been created, tra gen messages each in the head an indicator that the allows assignment to the respective version. News that have been prepared in accordance with Version 1, are of nodes Own Version 0 or even older standardizations, uninterpretable. A node of the Version 1 must therefore be able, depending on the GTP version that node, he at the Sending messages, applies these messages either ge according to version 1 or version to create 0th

A major difference between Version 0 and Version 1 the GTP protocol is the procedure by which a message the established tunnel or to a PDP context is done. In version 0 of this, so-called tunnel Identifier, abbreviated TIDs, used as part of the post report is transmitted and from the IMSI (International Mobile Subscriber Identity) and the NSAPI (Network Layer Ser Service Access Point Identifier) ​​composed. The IMSI is the world's unique identification number of a participant; of the NSAPI references one of a plurality of PDP contexts that the Users 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 messages allow a context. The flow labels are not necessarily clearly assigned because it only a Wertebe rich of about 65,000 and have considerably more contexts depending Kno th can be built.

The flow labels are respectively in the activation of a GTP Tunnels awarded; each node involved in a tunnel this case signals to the counter node, flow label with which he subsequent messages on this tunnel or, which amounts is significant for this PDP context is obtained. In the first message of the frame of the construction of a tunnel sent a serving node to a gateway node is (Create PDP Context Request), the flow label to 0, because the gateway node still a flow label awarded can, and the tunnel identifier is transmitted; all by following news of this tunnel must with the gate way nodes allocated flow label are sent. Just ge taken will be awarded every two flow label, one for Signaling and one for data. The following is but only considered the flow label for signaling.

In the GTP Version 1 are called TEID (Tunnel Endpoint Identifier) ​​assigned to the same function as the flow have labels, but have a length of 4 bytes. The TEID are therefore not flow labels Version 0 compati bel, but they can be assigned uniquely. The from the Version 0 known tunnel identifier is in news after Version 1 no longer included. IMSI and NSAPI, the one a ermögli unique assignment of the message to a PDP context chen, are only in the first message (Create PDP Context Request) from the serving node to the gateway node contained th.

Within each version function both Versio of the GTP operate properly. In the standardization Shaped changed that a node for version 1 and the GTP version 0 un supports, therefore, is backward compatible. This is erforder Lich, so different node versions colaboration th can.

However, problems arise when a mobile subscriber located in a network, the nodes of different versions contains, move and operate it from the catchment area of ​​a the node in the other switches. This change has an RAU (Routing Area Update) episode, in which a tunnel from the node in the catchment area, the participant was previously located at the node of the new Einzugsbe Reich is passed. Under this procedure, data must over the PDP context from the old to the new nodes using GTP messages are passed. This data is needed the new node to aufzuneh contact with the gateway node men and to switch the GTP tunnel, so that the service the subscriber can be continued without interruption. If all three involved in the switching of the tunnel belong to the same node GTP version, the switchover tion problem. Although two of them by node Version 0, and the third, a node of the Version 1, There were no problems, since all between nodes exchanged messages be those of the GTP Version 0 have to. However, if two nodes of the Version 1 and the third version 0 belong to, the fact that the two nodes of the Version 1 with each other with Version-1- News and the third node with version-0- communicate messages to difficulties. Three cases are to be distinguished.

<ul><li>1. The mobile subscriber moves from one first be controlling node of the Version 0 to a second after version 1. In this situation needs to communicate the first serving node to the second and the gateway Node GTP version 0 are used; communication between will rule gateway node and the second serving node Version 1 instead. In the construction of the tunnel assigns the Ga teway node a flow label, which operated from the first the node for marking associated with the tunnel Messages used. If the two controlling nodes Make contact to prepare for the transfer of the tunnel, communicate it to version 0, and the first use Node provides the second with the flow label, which originally Lich has been the gateway node associated with the tunnel. Around necessary context data for the tunnel from the gateway to obtain nodes would the second controlling node a Message with this flow label to the gateway node ski bridges can. The second controlling node and the gateway Nodes communicate using Version 1, to the delegation the tion of flow label does not permit. Instead the flow label although could be transmitted a TEID to version 1, but is no such defi in the gateway node for the tunnel ned. The gateway node thus can the existing channel allocate any message GTP version. 1 Because the message "Update PDP Context Request" neither IMSI nor NSAPI contains, is the gateway node also then not in a position to the Kon text to find, if he ignores the TEID.</li><li>2. The mobile subscriber moves from one first be controlling node of the Version 1 to 0. In the version this case, in the communication between the first BE controlling node and the gateway node within the structure been the tunnel GTP Version 1 used, that it is indeed a TEID specified for the tunnel, but no flow La bel. For communication between the two controlling Kno th must be GTP version 0 used this allowed but only flow label. One way to the TEID to the second Node transfer, is not, and even if they be would, it could not process it. The second be serving node therefore has no way that flow label find out with whom he from the required context data Gateway node could request. </li><li>3. The mobile subscriber moves from one use the nodes of the Version 1 to another of the same Ver sion, but the gateway node is operating on Version 0. In this case, the controlling nodes communicate untereinan of Version 1, with the gateway node but after Versi on 0. The gateway node thus allocates build a Tun nels a flow label, this, however, can not from the first are transmitted to the second node, so that this also Check not the context information from the gateway node can.</li></ul>

The object of the invention is to provide methods for Umle gene of a tunnel from a first controlling node of a specify the GPRS system to a second, the even funk tioning when under the controlling node and the Ga teway node at least one node of the Version 0 and other are using Version 1 of the GTP protocol.

The object is for the case that the first controlling Kno th is a node of the Version 0 and the second controlling Node and the gateway node are nodes of the Version 1, achieved by a method Claim 1. This provides that the call for adaptation of the context that the second controlling node addressed to the gateway node, a contains details of the IMSI and NSAPI of the relevant tunnel. This information allows the gateway node, a unique prepare correspondence to a stored context and so the required context data to the second node to lie remote.

The required details of the IMSI and NSAPI can in a very simp che way be transferred by the fact that the second serve de node and the gateway node to using Version 0 of GTP Protocol established tunnel under the same protocol version to continue to operate. In this case contains from two th node to the gateway node to send invitation to Adaptation of the context, the message "Update PDP Context Re quest ", from the outset, this required information. This solu solution thus implies that the protocol of the second controlling node in communication with the gateway Node applies, depending on the history of the tunnel which include the exchanged messages. When a Tunnel from the second node itself or from another bone th has been built according to version 1, finds the Communi cation instead of the gateway node of the Version 1; was the originally laid tunnel from a node of the Version 0 builds, then the communication with the gateway node wei terhin Version 0, though both involved nodes Versi on 1 dominate.

Such control the version can be on realize a simple manner if the first controlling node first one the tunnel relocation operation introductory After report (SGSN Context Response) to the second controlling Kno th sends, the second controlling node, the version of this Message for his call for adaptation of the context used at the gateway node, and this all to him ge oriented messages in the version answered in which it it has received.

An alternative possibility is that the second node as a request for adapting the tunnel instead of her tional message "Update PDP Context Request" a Following report of the "Create PDP Context Request" Version 1 sends. This message is in accordance with the above-cited document T5 29,060 by the receiving gateway node properly proces Tet, that is, the existing PDP context is recovered and the changed parameters are replaced. In this way routed, both the tunnel for the second controlling node changed as well as in the version.

Still alternatively, it may be provided that the Message "Update PDP Context Request" Gesen with a TEID det may be, which has the value 0, and in addition to the measures planned under TS 23.060 items of information to additionally contains the IMSI and NSAPI for an allocation to the appropriate PDP context in the gateway node to allow.

In the case that the second controlling node or the gate way node is a node of the Version 0 and each of whose nodes are using Version 1, the problem is solved by the method according to claim 5, wherein a flow label, the second controlling node and the gateway node Benö term to the tunnel from the first to the second controlling to be able to transfer node, the second from the first-use Node is provided.

There are various possibilities, the association of the Flow labels make. If the gateway node, a node is the Version 1 type, the structure of the channel so the Version 1 has taken place, then the tunnel build only a TEID, but no flow label has been assigned. In this case is expediently the first controlling node of the Assignment of a flow label makes the tunnel.

A first variant provides that the first controlling Kno th the context a flow label of a value mapped, for the diversion of a tunnel from a controlling node Version 1 to a controlling node of the Version 0 is specific, that is different from all flow La lever, which for the communication of regularly Version 0 working nodes are used. The second use Node to receipt of such a specific flow Labels respond by instead of a message "he Update PDP Context Request ", which he normally at the gateway Node would send when a correct flow label of egg get nem first controlling node of the same version would have a message "Create PDP Context Request" to the Ga teway node sends the IMSI and NSAPI contain and thus ei ne unambiguous identification of to matching context on Gateway node allows. Alternatively, provided he to that of the second controlling node a message "Update PDP Context Request "sends to the gateway node, the all recently deviating from the current protocol version 1 to additionally contains the IMSI and NSAPI and so turn a Identi fication permits. Such an approach is possible because the existing standard does not provide for PDP update requests with Flow Label 0, and their processing is therefore not normalized is.

A second variant of the method, which also then to is reversible if the gateway node of the Version 1 and the second controlling node of the Version 0, envisages that the gateway nodes each serving from the first node Assign Version 1 established context not only a TEID net, but at the same time over a defined procedure has, after he established each of the Version 1 Context said or more precisely its TEID a flow can assign label. Thus, the gateway nodes each corresponding to the GTP Version 1 established a context TEID and a flow label. Zweckmäßi sarily, the gateway node already in the award of TEIDs be the flow labels resulting in the sense take into account that an effective identification of Kontex th reference to the flow labels. The same procedure is also the first controlling node. If a tunnel, the serving of the first node of the GTP has been established version 1, serving on a second Node must be redirected to version 0, then the first controlling node directly by applying the method determine the correct value of the flow label and the second make controlling nodes available, the basis of which Gateway node can identify the PDP context. Thus , the second controlling node to the gateway node in the responsive same manner as if he a be the tunnel serving node would get passed to version 0th

A preferred because particularly simple method to organize the flow label to a TEID is equating the Flow label to the two least significant bytes of the TEID. If, however, the gateway node is a node of the Version 0 and the two controlling nodes are nodes of the Version 1, the assignment of a flow label to the tunnel is already in the structure of which has been made by the gateway node, and flow label is known to the first controlling node. Around this flow label to the second node - using Version 1 News - to convey, it is expedient to it in the TEID Field of a Version 1 message to "pack".

Since the flow label does not fill the TEID field, it is above geous possible the remaining space in the TEID field for transmitting a predetermined value to use, the at Otherwise, in a TEID does not occur and at which the second can therefore be seen controlling node that is in itself the transferred value is not a TEID but a "Packed" flow label is, and the value accordingly can handle properly. Such a predetermined value can z. B. 0 be.

Embodiments will now be based on the Zeichnun explained gen closer. Show it:

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

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

In the constellation of <b>Fig.</b> 1 is the first use Node SGSN1 over which the tunnel for the terminal MS originally has been set up, is a node of the GTP Version 0; he communicates with the gateway node GGSN and the second BE serving node SGSN2 GTP Version 0, ie the out exchanged messages are characterized by flow label and TEID. The gateway node GGSN and the second controlling Node SGSN2 communicate by Version 1 with by TEIDs marked messages.

<b>Fig.</b> 4 shows the flow of the signaling between a Terminal MS and the three nodes SGSN 1, GGSN and a SGSN2 hand, when activating a PDP context, and on the other hand at the transfer of the GTP tunnel. Here Headlines accordance in GTP Version 0 through by lean, messages of the Version 1 bold arrows shown. Messages that are not between Node to be replaced and therefore not to the GTP-Proto protocol are bound exchanged such as with the terminal MS Messages are shown in dashed lines.

In step <b>1</b> the terminal transmits a request to MS Ak vation of a PDP context (Activate PDP Context Request) the SGSN0, inter alia, the NSAPI and type or quality specified ity of the desired service. The use Node SGSN 1 then directed a request "Create PDP Context Request "to PDP Version 0 to the gateway node GGSN in the communication of the IMSI and NSAPI the gateway node (step <b>2</b>). The gateway node then generates ei NEN new entry in its PDP context table, which he allows data packets of the terminal MS between the SGSN 1 and an external, not shown in the figures PDP to route network and to charge fees, and tells him a flow label. As a confirmation, it sends in step<b>3</b> egg ne message "Create PDP Context Response" back to the ers th controlling node SGSN 1 that the allocated flow label contains. The first controlling node itself confirms the establishment of the context of the terminal MS by a post report "Activate PDP Context Accept" (step <b>4</b>).

Through the associated flow label the SGSN 1 is capable, Data packets of the terminal MS, the new to the one established Context include, so to indicate that the gateway node GGSN them of the data packets of other terminals or of walls ren contexts associated data packets of the same terminal can differ.

The process of transferring a tunnel begins with the Terminal in step <b>5</b> an invitation "Routing Area Update Request "sends to the second controlling node SGSN2. The these nodes SGSN2 works GTP Version. 1

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

In order to achieve that intended for the subscriber station MS Data packets no longer SGSN 1, but directly to the new controlling node SGSN2 be routed, the gateway must Node GGSN to be informed about the change. this happens by a request for adaptation of the context, which in step <b>10</b> sent from the SGSN2 sends to the gateway node GGSN becomes.

While in the case of acquisition of a context be of a serving node of the same version of the invitation to Adaptation of the context a message "Update PDP Context Re quest "would be the second controlling node used here considered as inducements a message type "Create PDP Context Request". This message contains the Ge contrast to the message "Update PDP Context Request" under GTP Version 1 IMSI and NSAPI of the terminal MS. The gateway Node is not expected for a message of this type that it is sent with a defined TEID; He tried as ago not to interpretie such TEID Message reindeer, but identifies the relevant context in the guided him directly on the basis of the IMSI and NSAPI. The context entry thus found is updated in the him the new controlling node SGSN2 and GTP Version is assigned to the communication between GGSN and controlling node is complete.

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

Before the terminal MS in step <b>18</b> a confirmation of his RAU request "Routing Area Update Accept" receives, finds even a message exchange between the two controlling nodes and the home location register HLR of the mobile radio communication tion system instead of in the course of the assignment of Endge chine MS to the new controlling node SGSN2 in this Re registers is noted. These steps do not differ from the well known for a GSM or UMTS radio communication 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> can also be a force against the GTP Version 1 slightly modified type message "Up date PDP Context Request "be applied. These modifi graced message includes a TEID with the value 0 and IMSI and NSAPI of the terminal MS. The gateway node GGSN does even no TEIDs with value 0. When an "Update PDP Con receives text Request "with TEID = 0, then it beschlos be sen that the TEID not by the gateway node GGSN verge Ben has been and that, therefore, no entry in Kontextver corresponds in the GGSN. The GGSN thus in a such a case back to the IMSI and NSAPI in order to from the "Up to iden date PDP Context Request "affected context and update reindeer as described above.

Another alternative is that the second controlling bone th for the update prompt of step <b>10</b> ever Weil that GTP version selected, in which he in step S7 the message "SGSN Context Acknowledge" has obtained here So the version 0. In this way, he gives the GGSN ge compared for the affected context than version-0-node, can this be the right context by specifying a Flow Labels identify, and replaced by the gateway node response also news in version 0. In this way, the Context to the new controlling node SGSN2 correctly converted sets, even if the GTP version used the same remains.

A second method for transferring the tunnel from the first be serving node GGSN1 different to the second GGSN 2 from in <b>Fig.</b> 4 signaling sequence shown in that the second controlling node in step <b>10</b> for his Call for updating the context Version 0 ver turns, in which it already in step <b>7</b> the flow label of Tunnels received. The gateway node responds in step <b>11</b> That also using Version 0. ie although second controlling node and gateway SGSN2 Node GGSN mastered version 1, they perform the procedure under Ver sion 0 established tunnel using Version 0 wei ter.

Since in this second method, the version of the tunnel when tilted to the second controlling node does not change, special precautions are required if the tunnel a second time, according to a third controlling node Version 1 is to be allocated.

When passing this version 0 tunnel of a second to a third controlling nodes to both Version 1 contact, the same problems arise as in the case, that one between a first controlling node of the Version 1 and a gateway node constructed Version 0 tunnel allocated to a second controlling node of the Version 1 must become. Some of the Lö described later solutions of this problem are therefore also in this case reversible.

<b>Fig.</b> 2 shows a configuration in which a first node SGSN 1 of the GTP Version 1, a gateway node GGSN of the GTP Version 1 and a second controlling node SGSN2 to Ver sion 0 communicate. The first controlling node SGSN 1 and the gateway node GGSN to use each other al marked so by Tunnel Endpoint Identifier TEID News by Version 1, the two controlling nodes SGSN 1 and SGSN2 use each other by flow label and TEID flagged messages by Version 0th

The sequence of steps for setting up and transferring the Tunnels in <b>Fig.</b> 5 is shown, corresponds to that of <b>Fig.</b> 4. However, the different for Nachrich th used GTP versions, in turn, through thick and thin in arrows different. The Kontextanforde request "Create PDP Context Request" and the answer to it in steps <b>2</b> and <b>3</b> meet a number of objectives which from <b>Fig.</b> 4, but with the difference that for them GTP- Version 1 is used, and that consequently the gateway Node GGSN the context a tunnel endpoint identifier TEID assigns and those serving to the first node SGSN 1 Previous reports.

The requirement "SGSN Context Request" using GTP Version 0, the second controlling node SGSN2 in step <b>6</b> at the first directed, is of this with an "SGSN Context Res ponse "answered the version 0th A purely by Versi on 0 running channel assignment contained in this message their information element (IE) "PDP Context" a gateway from Node to the first controlling node for this context , allocated flow label. Here, since such a non flow label there is instead a first controlling node Flow Label by a predetermined method from the assigned by the gateway node GGSN TEID is calculated. On particularly simple method for calculating the flow label is, respectively, the two least significant bytes of the TEID and to use flow label and the two high-order to ver negligent. This flow label is serving the second Node SGSN2 in his step <b>10</b> at the gateway node directed request for context matching used. There the gateway node GGSN, the process is "known" by the the first controlling node GGSN1 flow labels from TEIDs he testifies, he may, upon receipt of the corresponding flow label in a request for context updating in step <b>10</b> the second controlling node easily a small number of making contexts in its directory, by the Update could be affected. Among these the tat to identify outlying concerned, is then readily possible.

Another way to update the context is, the use of flow labels with the value 0, similar to above with reference to <b>Fig.</b> 4 described. Since Flow Labels this value not otherwise assigned or most of ei nem controlling node of the Version 0 type messages "Create PDP Context Request" may be used, where a Flow Label of the tunnel at the time of sending the Following report is not yet known, the gateway node GGSN, if a message from the second controlling node SGSN2 with such a flow label receives with value 0, it fol been like that the flow label is not allocated by itself can be and that is why an association of message to egg a tunnel, ignoring the flow label and under Use is also transmitted identification information, ie the IMSI contained in the TID in the message header and NSAPI of the terminal, must take place.

As yet another alternative, an addition of GTP- Version 0 are provided, wherein the second controlling Node SGSN2 a message of the "Create PDP Context Re quest "sends when a by the first controlling node Message with a set to 0 flow label is replaced.

When in <b>Fig.</b> 3 third constellation shown, both controlling node SGSN 1 and SGSN2 node of the GTP Version 1 and the gateway node GGSN is a node of the Version 0th The construction of the tunnel and its transfer from the first Bedie nenden nodes SGSN 1 to the second SGSN2 are in <b>Fig.</b> 6 ge shows. The construction of the tunnel in the steps<b>1</b> to <b>4</b> Browsing as well as from with reference to <b>Fig.</b> 1 and 4 will be described. U.N after the other to the two controlling nodes v1 contact. In order between the controlling node SGSN 1 and gateway Node GGSN negotiated flow label to the second serve to transfer the node SGSN2, it must therefore have a Verbin tion of version 1 are transported. This flow label to to convey the second controlling node SGSN2, it complements the first controlling node SGSN 1 to two high-order bytes the format of TEID, in step <b>7</b> (SGSN Context Respon s) is transmitted to the second node SGSN2.

A first variant of the method according to subsequent ßend two in <b>Fig.</b> 6, shown as dashed arrows Messages exchanged: The node SGSN in step <b>10</b>'A request for context matching (Update PDP Con text Request) Version 1 to the gateway node GGSN. There this is only capable of Version 0, it signals the second Node SGSN2 (step <b>10</b>") That it does not prompt the can handle. This tells the second node that the Gateway node a Version 0 message with a flow label required and then generates in step <b>10</b> In a new requirement, this time to version 0, in which they two the lower order bytes of receive from the first node SGSN 1 NEN TEID inserts as the flow label.

A second variant according to use of first-use Node SGSN1 two bytes of predetermined value to the the tunnel allocated flow label on the format of TEID to complete. This predetermined value, here 0, should be at the normal production of a PDP context is not the version 1 be forgiven, so that the second controlling node to SGSN2 can recognize the value of these two bytes, that it is in the step <b>7</b> transferred to it in the format of a TEID infor on in reality is a flow label, this again manufactures and thus the call for update the context in step <b>10</b> from the outset that from the gate way node GGSN interpretable message format of Versi on 0 can choose.

Since, in this second variant, the-use of the second used node SGSN2 for update prompt Version no dialog between the second node and SGSN2 Ga teway node GGSN is determined by the latter, but through which the message SGSN Context Response be Version is true, this variant is also suitable for the above be already mentioned case where a tunnel which originally between a controlling node SGSN 1 Version 0 and constructed a version-1-GGSN and then to a second BE serving node SGSN2 Version 1 while maintaining ur originally used for the tunneling protocol version ei NEN third controlling node is allocated on the version. 1

According to a third variant, the step <b>7</b> to supporting context information also been expanded who to that both flow label and TEID transported who the can, designated as such. This can by adding an additional data field to the Kon text information take place that receives the flow label, so that, if known, both the TEID and the flow label to the second controlling node SGSN2 can be passed. Also conceivable is the addition of a simple flag, the sen state the content of the TEID field of a message featuring TEID or as the flow label. Thus, the Wertebe rich for TEID not restricted.

This third variant is for apportioning an under Version 0 tunnel operated at a third controlling Node suitable to version. 1

A fourth possibility is also between the serving Node GTP version apply 0th Although the second be begins controlling node GGSN 2 dialogue with the first node SGSN 1 with GTP Version 1, which sees the first node (SGSN 1); he would therefore normally respond with GTP version. 1 while However, the first node SGSN 1 "does not understand" GTP Versi on pretending 1 message, it causes the second serve the node SGSN2 to use version 0, so that the flow La can be transferred bel. This variant allows the Apportionment of a Version 0 tunnel while maintaining the Ver sion to a third controlling node.