Method to transfer a tunnel between nodes of a GPRS system

Method for setting up channels between nodes in GPRS system

The present invention relates to a method for setting the channel of the first service node of GPRS (General Packet Radio Service) on the second node.

If the mobile terminal (which uses the relevant channel) is switched from the supply area of the first service node to the second node, it is necessary to set up a channel area. This kind of handover will cause a kind of RAU (Routing Area Update), in which the data in the path continues from the first service node to the second service node via the PDP-context of the terminal. The transmission of these data is carried out in the form of information under the GTP (GPRS-Tunnel-Protocol) protocol. The information of this GTP protocol can be used to construct/disassemble the PDP-context and continue to transmit the PDP-context when the routing area is updated. For details of the GTP protocol, please refer to this document 3G TS 23.060 Technical Specification Group Service and System Aspects; GeneralPacket Radio Service(GPRS); Service Description; stage2(Release 1999), for example, version V3.3.0 of April 2000 of 3GPP(3rd Generation Partnership Project, www.3GPP.ORG.

The data transmitted between the two service nodes enables the second service node and a contact area to be accommodated in a Gate Way node and the complete information required for this context is formed there. These information enable the The node switches the GTP channel so that the services required by the terminal can continue without interruption.

As far as the GTP protocol is concerned, there are currently two versions that have been standardized, one of which is GTP-Version 0 in GSM 09.60, also known as Relcase 98 or 97; the other is GTP-Version 1, which has been disclosed above The document TS 23.060 is also called Release 99. What the Version 1 standard pursues is: Version 1 nodes can be operated with Version 0, and the GTP channel can be operated with the highest possible version (Version).

The received node can therefore recognize the GTP version, and the received information can be set accordingly. Each information carries a characteristic symbol in the header, which can correspond to each version. The information set according to version 1 cannot be interpreted by these nodes (which operate according to version 0 or earlier standards). Therefore, the node of version 1 must be in this state, that is, in the case of a GTP version (which uses a node and information is sent to this node), the information is set according to version 1 or version 0.

The main difference between version 0 and version 1 of the GTP protocol is "this method", according to which information is assigned to the formed channel or PDP-context. In version 0, the so-called channel identifier (TIDS) is used, which is transmitted as a part of information and is composed of IMSI (International Mobile Subscriber Identity) and NSAPI (Network Layer Service Access Point Identifier). IMSI is the user's clear and extensive character; NSAPI must refer to one of multiple PDP-contexts (which can be assigned to this user). Since the channel identifier cannot be processed correctly with a length of 12 bytes, a 2-byte length of FlowLabels must be used in its location, which can quickly allocate information to the context. However, these mobile standard fibers may not be clearly marked, because the value range they have is 65000 and each node can clearly form multiple contexts.

Each mobile standard fiber is set when driving the GTP channel; each node that joins this channel informs the opposite node: which mobile standard fiber it uses to obtain subsequent information in this channel (this is different for this kind of PDP-context Words have the same meaning). In the first information (which is sent by a service node to the gateway node in the range of the channel structure to form a PDP Context Request), this kind of mobile standard fiber remains at 0, because each gateway node has not yet set this mobile standard fiber, And the ID of this channel has been transmitted; all subsequent information of this channel must be sent using this mobile standard fiber set by the gateway node. To be correct, two mobile standard fibers must be set separately, one for signal notification and the other for data. However, only the mobile standard fiber used for this kind of signal notification is considered below.

In GTP version 1, the so-called TEID (Tunnel Endpoint Indentifier) is set. Its function is the same as that of the mobile standard fiber, but the length is 4 bytes. This TEID is therefore incompatible with version 0 mobile standard fibers, but these TEIDs can be explicitly set. The channel identifiers known in version 0 are not included in the version 1 information. IMSI and NSAPI (which make the information clearly assigned to the PDP-Context) are only included in the first information (forming the PDP ContextRequest) from the service node to the gateway node.

These two versions of GTP can function perfectly in each of the other versions. During standardization, the node used in version 1 must also support GTP version 0, that is, it is backWards compatible. This is required, so nodes of different versions can be operated together.

However, if mobile radio users move to a network (which includes nodes of different versions) and switch from the supply area of one service node to another, some problems will occur. This kind of switching will cause a kind of RAU (Routing Area Update), in which a channel is transferred from this node (which has previously held this user in its supply area) to a node in God's supply area. In the scope of this process, the PDP-context data must be continuously transmitted from the old node to the new node by means of GTP information. This kind of data requires a new node ^， In order to accommodate this contact area to the gateway node and switch this GTP channel, so that the service required by the user can continue without interruption. If all three nodes that join the switch of this channel belong to the same GTP version, this switch will not cause problems. If two of the nodes are version 0 nodes and the third is version 1 nodes, no problem will occur at this time, because all the information exchanged between the nodes must be GTP version 0 information. Of course, if the two nodes belong to version 1 and the third node belongs to version 0, the following situation will cause difficulties: the two nodes of version 1 communicate with the information of version 1 and therefore the third node is the same as version 0. Information and communication. Three situations must be distinguished as follows:

1. Mobile radio users move from the first serving node of version 0 to the second node of version 1. In this case, the first service node and the second service node, and the gateway node must use GTP version 0 when communicating; the communication between the gateway node and the second service node is based on version 1. When constructing this channel, the gateway node allocates a mobile standard fiber, which is used by the first service node to indicate the information to which this channel belongs. If the two service nodes accommodate the contact area in order to prepare the channel, they will communicate according to version 0, and the first service node provides the mobile standard fiber to the second node. The mobile standard fiber was originally configured by the gateway node. Belongs to this channel. In order to obtain the context data required by this channel by the gateway node, the second service node must be able to provide a kind of information with such a flowing standard fiber to the gateway node. However, the second service node and the gateway node communicate according to version 0, which does not allow the transmission of this mobile standard fiber; the TEID can be transmitted according to version 1 to replace this mobile standard fiber, but this mobile standard fiber is in this case The gateway node used by the channel is not defined. Therefore, the gateway node did not assign the information of GTP version 1 to the existing channel. Since this information "UpdatePDP Context RequeSt" does not include IMSI and NSAPI, the gateway node does not find this context, if the gateway node ignores the TEID.

2. The mobile radio user moves from the first serving node of version 1 to the node of version 0. In this case, when communicating between the first service node and the gateway node, GTP version 1 is used in the construction range of the channel, that is, the TEID of the channel has been determined, but there is no flowing standard fiber. For the communication between the two service nodes, GTP version 0 must be used, but this only allows the use of "mobile standard fiber". It is impossible to transmit the TEID to the second node, even if it exists, it still cannot process the TEID. Therefore, the second service node still cannot find the mobile standard fiber (thereby can request the context data required by the gateway node).

3. The mobile radio user moves from the service node of version 1 to another node of the same version, but the gateway node operates according to version 0. In this case, the service nodes communicate with each other according to version 1, but the gateway node communicates with the service node according to version 0. This gateway node is therefore allocated a flow standard fiber when the channel is formed, but it is not composed of the first <img file="TW525397B_D0001.tif" /> The service is sent to the second node so that the second node cannot query the context information of the gateway node.

The purpose of the present invention is to provide a method so that the channel of the first serving node of the GPRS system can be formed to the second node, if there are at least one version 0 node of the GTP protocol and another under the serving node and gateway node If the node is version 1, the second node can also be used.

When the first service node is a version 0 node and the second service node and the gateway node operate according to the first version, the above-mentioned purpose is achieved by the method described in item 1 of the scope of patent application. The design method is: the requirements required to adjust the context (which makes the second service node point to the gateway node) include the description of the IMSI and NSAPI of the relevant channel. This purpose allows the gateway node to form a clear correspondence to the stored context and make the required context data located at the second node.

The required IMSI and NSAPI descriptions are transmitted in a very simple manner in the following way: The second service node and the gateway node continue to operate the channel formed under the version of the GTP protocol under the same protocol version. In this case, the request for the adjustment context to be sent from the second node to the gateway node (ie, the information "Update PDP Context Request") contains the previously required description. This solution therefore includes: This protocol (which is used in the second service node when communicating with the gateway node) is related to the pre-layering of this channel, and the information that has been exchanged belongs to this channel. If a channel is composed of a second node or another node of version 1, the communication with the gateway node is based on version 1; if the channel is originally formed by a node of version 0, it will communicate with the gateway node Therefore, the communication is based on version 0 in addition, although the two joined nodes are mainly operated with version 0.

This control method of the version used can be easily achieved. If the first service node first sends a message (SGSN Context Request) to guide the channel setup process to the second service node, the second service node is adjusting the context and When there is a request for the gateway node, the version of this information is used and the second node answers all the information directed to it (it has been received) in this version.

Another possibility is that the second node sends a type of information of "Create PDP Context Request" according to version 1 as a requirement to adapt to this channel to replace the traditional information "Update PDP ContextRequest". This information is correctly processed by the receiving gateway node according to the above-mentioned document TS 29.060, that is, the existing PDP context is discovered and the changed parameters are replaced. In this way, the channel to the second service node can be set and can also be changed in this version.

In addition, another way is to send this kind of information "Update PDP Context Request" with TEID, which has a value of 0 and contains IMSI and NSAPI in addition to the information element set according to ts 23.060, so as to be in the gateway node Can be assigned to the corresponding PDP context.

If the second service node or the gateway node is a node of version 0 and the other nodes are nodes of version 1, then the purpose of the present invention is achieved by the method of item 5 of the scope of the patent application, wherein the second service node and the gateway node A mobile standard fiber is needed so that the channel of the first node can be set on the second service node, and the mobile standard fiber is set by the first service node for the second node.

Therefore, there are various possibilities for the distribution of such mobile standard fibers. If the gateway node is a node for version 1 (it forms the structure of the channel according to version 1), only TEID (but without the flowing standard fiber) is assigned to the channel when it is formed. In this case, the appropriate way is that it belongs to the first service node (it allocates the flowing standard fiber to the channel).

The first method is: the first service node allocates a flow standard fiber in this context, the value of which is specific for a channel from a service node of version 1 to a service node of version 0, that is, different values are used for all Among the mobile standard fibers, each mobile standard fiber is used for communication of regular nodes that operate according to version 0. The second service node can respond to the reception of this specific mobile standard fiber, and at this time it sends a message "Create PDP ContextRequest" to the gateway node to replace the information "Update PDP ContextRequest" (which is usually sent to the gateway node , If the second service node has obtained the correct mobile standard fiber from the first service node of the same version).

This "Create PDP Context RequeSt" information contains IMSI and NSAPI and therefore can clearly identify the context to be adjusted on the gateway node. Another design method is: the second service node sends a kind of information "Update PDP Context Request" to the gateway node, which is of course different from the applicable protocol of version 1, and additionally has IMSI and NSAPI and allows a recognition. This design method is possible because the existing regulations do not set such PDP Update Requests with a mobile standard fiber 0 and their processing is therefore not standardized.

The second method is also available when the gateway node operates according to version 1 and the second service node operates according to version 0. The design method is: the gateway node not only allocates each set by the first service node according to version 1. The context is not only a TEID, but also a fixed method, so that each text set by version 1 (correctly its TEID) can be assigned to a mobile standard fiber. Therefore, a TEID and mobile standard fiber in the gateway node corresponds to each context set by GTP version 1. The proper way is that the gateway node can consider the flowing standard fiber caused in this way when setting TEIDs, so that the context can be effectively identified based on the flowing standard fiber. The same method can also be used for the first service node. If a channel (which is set by the first service node according to GTP version 1) needs to be redirected to the second service node according to version 0, the first service node can directly determine the correct value of the mobile standard fiber by using this method and it is available At the second service node, the gateway node can recognize the PDP context accordingly. The second service node can therefore react to the gateway node in the same way to indicate whether it has handed over this channel of a service node according to version 0.

A better (because it is particularly simple) method (used to allocate this mobile standard fiber to TEID) is to make this mobile standard fiber also set with two low-value bytes of TEID. Conversely, if the gateway node is a node of version 0 and the two service nodes are nodes of version 1, then "a mobile standard fiber is allocated to this channel" has been carried out by the gateway node when it was formed. The standard fiber is already known in the first service node. In order to send this mobile standard fiber to the second node (via version 1-information), the appropriate way is to encapsulate it in the TEID column of version 1-information.

Since the mobile standard fiber is not filled in the TEID column, the position still reserved in the TEID column can be advantageously used to transmit a predetermined value, otherwise this value does not appear in the TEID column and the second service node can therefore recognize: The value sent is not related to TEID but related to the "encapsulated" mobile standard fiber, so this value can be processed correctly. Such a predetermined value may be 0, for example.

The embodiments of the present invention will be described below based on the drawings. A brief description of the diagram: Figures 1 to 3 are where two nodes of GTP-version 1 and a node based on GTP-version 0 are added, and a possible configuration diagram when transferring a channel between two service nodes.

Figures 4 to 6 are the signal flow diagrams when transferring this channel in different configurations.

In the configuration in Figure 1, the first service node SGSN1 (the channel of the terminal MS was originally set on this node) is a GTP-version 0 node; it is the second node of the gateway node GGSN and GTP-version 0 The service nodes SGSN2 communicate with each other, that is, the characteristics of the information exchanged are the mobile standard fiber and TEID. The gateway node GGSN and the second service node SGSN2 communicate with each other according to version 1, and the feature of the information is TEIDs.

Figure 4 is the signal flow between the terminal MS and the three nodes SGSN1, SGSN2, and GGSN when driving the PDP text on the one hand and on the other hand when setting up the GTP channel. The information of GTP-version 0 is indicated by thin arrows, and the information of version 1 is indicated by thick arrows. The information that is not exchanged between the nodes (and therefore does not comply with the GTP-protocol, for example, the information exchanged with the terminal MS) is represented by dotted lines.

In step 1, the terminal MS sends a request to SGSN0 to drive the PDP context (Activate PDP Context Request), which also sets the NSAPI and the form or quality of the desired service. The service node SGSN1 aligns the PDP version 0 requirement "Create PDP ContextRequest" with the gateway node GGSN, which will inform the gateway node of the IMSI and NSAPI (step 2). The gateway node generates a new posting in its PDP-context table, which allows the data packets of the terminal MS to circulate and charge between SGSN1 and an external network not shown in the figure, and is allocated to the gateway node A flowing standard fiber. The gateway node sends a message "Create PDP Context Request" in step 3 back to the first service node SGSN1 for confirmation, which contains the allocated mobile standard fiber. The first service node uses this information "Activate PDP ContextRequest" to confirm that the context has been established for this terminal MS (step 4).

With the mobile standard fiber it belongs to, SGSN1 can confirm the data packet of this terminal MS (it belongs to the newly established context), so that the gateway node GGSN can distinguish it from the data packets of other terminals or distinguish it from the data packets of the same terminal. Data packets in other contexts.

The process of setting up such a channel therefore starts with the terminal sending a request "Routing Area Update Request" to the second service node SGSN2 in step 5. This node SGSN2 operates according to GTP-Version 1.

With a kind of information "SGSN ContextRequest" of GTP version 0 (step 6), the first serving node SGSN1 first knows that the context should be forwarded; then SGSN1 uses this information "SGSN ContextResponse" (step 7) to confirm such forwarding And start to buffer these data packets from the PDP network to determine the user station MS required. In step 8, after the new serving node SGSN2 has confirmed that it is ready to receive data with the information "SGSNContext Acknowledge", the node SGSN1 makes the buffered data packets continue to be sent to the node SGSN2 in step 9.

In order to make the data packet needed to determine the subscriber station MS no longer sent to SGSN1, but directly sent to the new service node SGSN2, the open node GGSN must be aware of this change. This is achieved by the requirements required for context adjustment, and such requirements are sent from the SGSN2 to the gateway node GGSN in step 10.

When receiving the context of the same version of the service node, the requirement for context adjustment is the information "Update PDP Context Request", then the second service node uses the information of the type "Create PDP Context Request" in the situation considered here As a request. This kind of information has the IMSI and NSAPI of this terminal MS compared to the GTP version 1 information "Update PDP ContextRequest". This kind of gateway node does not need to wait for this type of information: this kind of information is The confirmed TEID is sent; therefore, it does not have to interpret the TEID of this information, but directly identify the relevant context based on IMSI and NSAPI in the form that it sends. In this way, the found context posting will be actualized. It is to make the new service node SGSN2 and GTP version corresponding to this context to be posted, according to which the communication between the GGSN and the service node is carried out.

If the gateway node has successfully performed this operation, it confirms to the new SGSN2 that this operation has been successful by using such information in the form of "Create PDP Context Response" or "UpdatePDP Context Response" in step 11.

Before the terminal MS has obtained the confirmation of its RAU-required "Routing Area Update Accept" in step 18, the two service nodes must still exchange information with the Home Location Register (HLR) of the mobile radio communication system. During the process, it must be noted in this register that the terminal is allocated to the new service node SGSN2. These steps are no different from those already known in the GSM- or UMTS radio communication system, and will not be detailed here.

Another way is to use the information "Create PDP Context Request" in step 10, a form of "UpdatePDP Context Request" information that is slightly modified relative to GTP-Version 1 can also be used. This modified information contains the TEID with a value of 0 and the IMSI and NSAPI of the terminal MS. The gateway node GGSN did not send out TEIDs with a value of 0. If it receives an "UpdatePDP Context Request" with TEID=0, it can be determined that the TEID is not set by the gateway node GGSN, so there will be no posting in the GGSN context table corresponding to this TEID. This GGSN is therefore traced back to the situation of IMSI and NSAPI in order to recognize this context related to "Update PDPContext Request" and make it actualized in the above-mentioned manner.

Another possible way is: the second service node required for the actualization requirement in step 10 selects this GTP version separately (the information "SGSN Context Acknowledge" has been obtained in step S7), which is version 0 here. In this way, the second service node is a version 0-node for the GGSN in terms of the relevant context, and this adjustable context can be identified by pointing out this mobile standard fiber, and the gateway node can obtain it The same is version 0 answer information. In this way, this context can be correctly set on the new service node SGSN2, when the GTP version used remains the same.

The second method used by the first service node GGSN1 to the second GGSN2 to set up this channel is different from the signal flow chart shown in Figure 4 in that the second service node uses version 0 in step 10 to make the context practical , Where the second node has obtained the flow standard fiber of this channel in step 7. The gateway node also uses version 0 to answer this in step 11. That is, although the second service node SGSN2 and the gateway node GGSN master version 1, they still use version 0 to continue to guide the channel formed by this version 0.

Since in the second method, the version of the channel has not changed when transferring to the second service node, special measures are required, if the channel must be transferred to the third service node of version 1 for the second time.

When this version 0-channel is transferred from the second service node to the third service node, if the two nodes use version 1, this problem will be the same as the following situation: a first service node and version 1 The channel formed between the gateway nodes of version 0 must be transferred to the second service node of version 1. Some of the solutions to this problem described later can therefore be used in this case.

Figure 2 is a configuration in which the first node SGSN1 of GTP version 1, the gateway node GGSN of GTP version 1, and the second service node SGSN2 of version 0 communicate with each other. The first service node SGSN1 and the gateway node GGSN use this version 1 information represented by TEID (Tunnel Endpoint Identifier), and the second service nodes SGSN1 and SGSN2 use this version 0 information represented by the mobile standard fiber and TEID .

The sequence of the steps required for the formation and transfer of the channel shown in Figure 5 corresponds to Figure 4. Of course, the GTP version used for different information is also distinguished by thick and thin arrows. The context request "Create PDP Context Request" in steps 2 and 3 and the answer to it correspond to those in Figure 4 in terms of its goal setting, but the difference is that it uses GTP version 1. Therefore, The gateway node GGSN assigns a TEID to the context and reports this to the first serving node SGSN1.

According to GTP-Version 0, this requirement "GSGN Context Request" (which makes the second serving node SGSN2 point to the first serving node in step 6) is answered by the first serving node with "SGSN Context Response" version 0. In this channel setting that runs purely based on version 0, this information includes a flow set by the gateway channel on the first service node used in this context in its information element (IE) "PDP Context" Standard fiber. Here, since this kind of mobile standard does not exist, a mobile standard fiber in the first service node is calculated from the TEID set by the gateway node GGSN according to the previously determined method. A particularly simple way to calculate this kind of mobile standard fiber is to use the two low-value bytes of TEID as the mobile standard fiber and ignore the two higher-value bytes. This kind of mobile standard fiber is used for context adjustment by the second service node in its step 10 for aligning with the gateway node. Since this method is "as it is" for the gateway node GGSN (with this method, the first service node GGSN1 can generate this mobile standard fiber from TEIDs), the first service node receives the corresponding mobile standard fiber When there is a requirement for actualization of context, in step 10, the second service node can easily find out a few contexts in its table (which may be related to such actualization). In this case, it is extremely easy to determine the actual correlation.

Another possibility to actualize the context is to use a zero-valued mobile standard fiber, similar to the one described in Figure 4 above. Because the mobile standard fiber with this value cannot be set separately or all cases are used by a version 0 service node in the information of the type "Create PDP Context Request" (the mobile standard fiber of this channel is in the sending time of this information Point is still unknown), then when the gateway node GGSN receives the information that the mobile standard fiber value is 0 from the second service node SGSN2, the gateway node GGSN can infer from this: this mobile standard fiber cannot be set by itself , And therefore this information must be allocated to a channel when ignoring this mobile standard fiber and using the identification information sent together (ie, the IMSI and NSAPI in the TID of the terminal included in the information header).

In other ways, the GTP version 0 can still be supplemented. At this time, if the second service node SGSN2 obtains the information of a mobile standard fiber set to 0 from the first service node, the second service node SGSN2 sends a type of "Create PDP" Context Request" information. In the third configuration shown in Figure 3, the two service nodes SGSN1 and SGSN2 belong to GTP version 1 and the gateway node GGSN is a version 0 node. The structure of this channel and its transfer from the first serving node SGSN1 to the second serving node SGSN2 are shown in Figure 6. The structure of this channel in steps 1 to 4 is similar to that in Figures 1 and 4. The two service nodes must use version 1. In order to enable the mobile standard fiber processed between the service node SGSN1 and the gateway node GGSN to be transmitted to the second service node SGSN2, it must be achieved through the version 1 connection. In order to transmit the mobile standard fiber to the second serving node SGSN2, the first serving node SGSN1 must add two high-value bytes to a TEID format, which is transmitted to the second in step 7 (SGSN Context Response) Node SGSN2.

According to the first form of this method, the two information shown by the dotted arrow in Figure 6 are then exchanged: the node SGSN sends the version 1 context adjustment (Update PDP Context Request) request to the gateway in step 10' Node GGSN. Since the GGSN only controls version 0, it notifies the second node SGSN2 (step 10") that it cannot handle this request. The second node then recognizes that the gateway node needs a version 0 information with a mobile standard fiber, and therefore In step 10, a new requirement is generated, this time based on version 0, in which the two low-value bytes of the TEID received by the first node SGSN1 are added as the mobile standard fiber.

According to the second method, the first serving node SGSN1 uses two bytes with a predetermined value so that the mobile standard data allocated to this channel is filled into the TEID format. This predetermined value (here, 0) is not set when the PDP context of version 1 is normally generated, so that the second serving node SGSN2 can recognize the value of these two bytes. In the seventh step, it is sent to the first in TEID format. The information of the second service node is a kind of mobile standard fiber, which is formed again and can immediately select the version 0 information format that can be interpreted by the gateway node GGSN from the requirements required to actualize the context in step 10.

Because in the second form, the version used by the second service node SGSN2 for actualization requirements is not determined by the GGSN during the dialogue between the second node SGSN2 and the gateway node GGSN, but by the information" According to the version of SGSN Context Response", this method is also applicable to the situation mentioned above, namely: a channel that was originally formed between a service node SGSN1 of version 0 and a GGSN of version 1 and subsequently here When the protocol version used by the channel remains at the third service node of version 1, it is switched to the second service node SGSN2 of version 1.

According to the third method, the context information to be transmitted in step 7 is expanded in the following manner: both the mobile standard fiber and the TEID can be transmitted and used as features. This can be achieved by adding other data fields to the context information. The context receives the mobile standard fiber, so that when known, both the TEID and mobile standard fiber can be sent to the second service node SGSN2. It is also possible to add a simple flag whose status indicates that the content of the TEID column of a kind of information can be used as TEID or as a mobile standard fiber. The range of TEID values is therefore not limited.

The third method is also suitable for transferring a channel operating with version 0 to the third service node of version 1.

The fourth possible way is: GTP version 0 is also used between service nodes. The second serving node GGSN2 starts a dialogue with the first node SGSN1 with GTP version 1, so that it can learn about the first node (SGSN1); therefore, the first node must respond with GTP version 1 in the normal way. But the first node SGSN1 pretends to "not understand" the information of this GTP version 1, which prompts the second service node SGSN2 to use version 0, so this mobile standard fiber can be transmitted. This method allows a version 0 channel to be transferred to the third service node while maintaining the version.

Symbol description of main components

SGSN1, SGSN2. . . Service node

GGSN. . . Gate node

MS. . . Terminal

IE. . . Information element

HLR. . . In-situ register