1. Field of the Invention
The present invention relates, in general, to a mobile communication system, and in particular, to an apparatus and method for reordering traffic flow templates in a mobile communication system using traffic flow templates.
2. Description of the Related Art
A universal mobile telecommunications system (UMTS) mobile communication system is a typical 3rd generation mobile communication system. The UMTS system supports not only a voice service but also a packet data service, and further supports high-speed data communication and moving picture communication.
FIG. 1 illustrates a block diagram of a general UMTS network structure. Referring to FIG. 1, a mobile station (MS) 111, connected to a UMTS terrestrial radio access network (UTRAN) 113, processes a call and supports both a circuit service (CS) and a packet service (PS). The UTRAN 113, comprises a Node B (not shown) and a radio network controller (RNC) (not shown), is connected to the mobile station 111 via a Uu interface, and the RNC is connected to a service General Packet Radio Service (GPRS) support node (SGSN) 115 via a interface unit (Iu) interface. Here, the GPRS is a packet data service operating in the UMTS network. The UTRAN 113 provides protocol translation to transmit radio data or control messages, transmitted by the mobile station 111 over the air, to a core network (CN) using a GPRS tunneling protocol (GTP). Here, the, core network includes the SGSN 115 and a gateway GPRS support node (GGSN) 119.
The SGSN 115 is a network node for managing subscriber information and location information of the mobile station 111. The SGSN 115, is connected to the UTRAN 113 via the lu interface and the GGSN 119 via a Gn interface, and exchanges data and control messages with the UTRAN 113 and the GGSN 119. The SGSN 115, is also connected to a home location register (HLR) 117 via a Gr interface, and manages the subscriber information and location information of the mobile station 111.
The home location register 117 stores subscriber information and routing information for a packet domain. The home location register 117 is connected to the SGSN 115 via the Gr interface and the GGSN 119 via a Gc interface. The home location register 117 can be located in another public land mobile network (PLMN) and is capable of handling a roaming service for the mobile station 111. Further, the GGSN 119, located at an end of the GTP in the UMTS network, is connected via a Gi interface to an external network, e.g., the Internet 121, a packet domain network (PDN), or another PLMN.
A block diagram of an UMTS core network, in which traffic flow templates (TFTs) are used, will be described with reference to FIG. 2.
FIG. 2 is a block diagram illustrating a general UMTS core network using TFTs. It should be noted that the term TFTs is used in reference to performing packet filtering using TFTs. TFTs is performed in the UMTS core network. The use of the TFTs will be described herein below. A packet data protocol (PDP) context is classified into a primary PDP context and a secondary PDP context. The secondary PDP context exists only when a PDP context having the same information as the secondary PDP context, i.e., the primary PDP context exists. That is, since the secondary PDP context reuses the intact information of the primary PDP context, the secondary PDP context is generated after the generation of the primary PDP context. The primary PDP context and the secondary PDP context are identical to each other based on the information actually used. However, the primary and secondary contexts are different from each other based on a respective GTP tunnel which transmits packet data.
Particularly, in the UMTS core network, when the secondary PDP context is activated, the TFT information is used as a filter for distinguishing the primary PDP context form the secondary PDP context. As illustrated in FIG. 2, a UMTS core network 200, or a wideband code division multiple access (WCDMA) core network, has 7 TFTs stored therein, and generates a total of 8 GTP tunnels which takes into consideration secondary PDP contexts corresponding to the 7 TFTs. Internet protocol (IP) packet data received from an external network, e.g., the Internet 121, is applied to the GGSN 119 via the Gi interface. The GGSN 119 has 7 TFTs, e.g., TFT1 to TFT7 stored therein. A path used for the IP packet data received via the Gi interface is determined via the stored 7 TFTs by using packet filtering. The IP packet data filtered using the TFTs in the GGSN 119 is transmitted to the SGSN 115 via the determined path, i.e., the determined GTP tunnel, and the SGSN 115 transmits the IP packet data received from the GGSN 119 to an RAN 211 via the Iu interface via the corresponding GTP tunnel.
FIG. 3 illustrates an example of a general TFT format. Before discussing the TFT format of FIG. 3, a general discussion of how a TFT is generated will be discussed. A TFT is generated in the mobile station 111, and the generated TFT is transmitted to the GGSN 119 via the UTRAN 113 and the SGSN 115. The GGSN 119 filters packet data received via an external network, for example, the Internet 121, and uses the TFT to distinguish a primary GTP tunnel from a secondary GTP tunnel, thereby searching for a GTP tunnel through which the packet data will be actually transmitted. The primary GTP tunnel using the primary PDP context and the secondary GTP tunnel using the secondary PDP context are identical to each other for a PDP address. Therefore, in the case where no TFT exists, it is impossible to determine a GTP tunnel to transmit the packet data. For example, it is impossible to determine whether the packet data is to be transmitted through the primary GTP tunnel or the secondary GTP tunnel.
Further, the TFT can have, for example, a total of 8 packet filters identified by unique packet filter identifiers (IDs). Each packet filter has a unique evaluation precedence index for all TFTs associated with the PDP contexts sharing the same PDP address. The evaluation precedence index has a specific value between 255 and 0. The mobile station 111 manages a packet filter ID and an evaluation precedence index of a packet filter, and generates the contents of the packet filter. In addition, the TFT is associated with the PDP context on a one-to-one basis in a secondary PDP context activation procedure. That is, the TFT can be generated in addition to the PDP context generated in the PDP context activation procedure via a PDP context modification procedure initiated by the mobile station 111, or can be modified through a PDP context modification procedure initiated by the mobile station 111. One PDP context cannot have two or more TFTs.
Referring now to FIG. 3, the TFT has a TFT type field (Traffic Flow Template Type), a TFT type length field illustrated as “Length of Traffic Flow Template Type”, a TFT operation code field illustrated as “TFT operation code”, a packet filter field illustrated as “number of packet filters”, and a packet filter list field illustrated as “Packet filter List”. The TFT type field, a field indicating the type of TFT used, is preferably set to a value of 137 in the UMTS core network 200. In an embodiment of the invention, the TFT type field can be set to different values based on the network. The TFT type length field, a field indicating a length of the TFT type used, has a prescribed length, for example, a 2-byte field and represents a size of a remaining field excluding the TFT type field and the TFT type length field. The TFT operation code field, a field representing an operation code for the TFT used, analyzes a value represented by the TFT operation code field and determines a method in which the TFT received from the mobile station 111 is to be processed. Codes used in the TTF operation illustrated in Table 1.
TABLE 1Bits (765)Description000Spare001New TFT is generated010Stored TFT is deleted011Packet filter is added to stored TFT100Packet filter of stored TFT is replaced101Packet filter of stored TFT is deleted110Reserved111Reserved
As illustrated in Table 1, a TFT operation code “000” represents a spare value, a TFT operation code “001” represents an operation of generating a new TFT, a TFT operation code “010” represents an operation of deleting a stored TFT, a TFT operation code “011” represents an operation of adding a packet filter to a stored TFT, a TFT operation code “100” represents an operation of replacing a packet filter of a stored TFT, a TFT operation code field “101” represents an operation of deleting a packet filter of a stored TFT, and TFT operation codes “110” and “111” represent reversed fields. The GGSN 119 reads the TFT operation code field and performs a corresponding operation.
The packet filter number field, a field representing the number of packet filters which is set in the TFT used, represents the number of packet filters existing in a packet filter list of the TFT. For example, if the TFT operation code field has a value “101,” i.e., if a stored TFT is deleted, a value of the packet filter number field is set to 0. Therefore, if the stored TFT is deleted, a value of the other packet filter number field is set to a value being larger than 0 and smaller than or equal to 8 (0<number of packet filters≦8). A value of the packet filter number field is set to a value larger than 0 and smaller than or equal to 8 because the maximum number of packet filters used in the UMTS core network 200 is set to 8. The TFT information can have a minimum of 1 packet filter and a maximum of up to 8 packet filters. The packet filter is divided into a single-field packet filter with a single content and a multi-field packet filter with multiple contents. The single-field packet filter is comprised of a single content filtered by a packet filter, e.g., a single content such as a source address. The multi-field packet filter is comprised of multiple contents filtered by a packet filter, e.g., multiple contents such as a source address, a protocol and a destination address. The packet filter list field is a field representing the contents for information used by the packet filters set in the TFT.
If the TFT having the format of FIG. 3 is stored in the GGSN 119 and IP packet data from the Internet 121 is received, the received IP packet data is filtered via packet filters stored in the stored TFT. The filtered IP packet data uses a PDP context where a corresponding TFT is stored. Therefore, in the case where there exists 3 packet filters labeled first to third packet filtersamong a plurality of packet filters in the TFT, if the received IP packet data does not satisfy the first packet filter among the 3 packet filters, then a second packet filter, which is the next packet filter stored in the TFT, is applied. In this manner, if all the packet filters are not satisfied, the received IP packet data uses another GTP tunnel, and attempts packet filtering using the next TFT instead of the packet filtering-completed TFT.
A GTP tunnel generation procedure based on primary PDP context activation will be described with reference to FIG. 4.
FIG. 4 is a signal flow diagram illustrating an example of a GTP tunnel generation operation based on primary PDP context activation. In order to transmit packet data in a UMTS packet domain, it is necessary to first generate a GTP tunnel for transmitting the packet data. A path through which the GTP tunnel is generated is divided into an MS-initiated activation path where a GTP tunnel generation request is transmitted from the mobile station 111 to the UMTS core network and a network-requested activation path where a GTP tunnel generation request is transmitted from an external network to the UMTS core network.
Referring to FIG. 4, upon detecting generation of packet data, the mobile station (MS) 111 generates a GTP tunnel in order to transmit the packet data. Specifically, the mobile station 111 transmits an Activate PDP Context Request message to the SGSN 115 in step 411. Parameters included in the Activate PDP Context Request message include Network layer Service Access Point Identifier (NSAPI), TI, PDP Type, PDP Address, Access Point Network, and Quality of Service (QoS).
The NSAPI, information generated in the mobile station 111, can use a total of 11 values ranging from #5 to #15. The NSAPI value is associated with the PDP Address and a PDP context ID on a one-to-one basis. The PDP Address, represents an IP address of the mobile station 111 used in the UMTS packet domain, and is information constituting the PDP context information. The PDP context stores various information concerning the GTP tunnel. The PDP context is managed by the PDP context ID. The TI is used in the mobile station 111, the UTRAN 113 and the SGSN 115, and is uniquely assigned to GTP tunnels in order to identify the GTP tunnels. Although the TI and the NSAPI are similar to each other in their concept, they are different from each other in that the TI is used in the mobile station 111, the UTRAN 113 and the SGSN 115, and the NSAPI is used in the mobile station 111, the SGSN 115 and the GGSN 119. The PDP Type represents a type of GTP tunnel that is generated via the Activate PDP Context Request message. The type of GTP tunnel includes Internet Protocol (IP), Point to Point Protocol (PPP), and Mobile IP. The Access Point Network represents an access point of a service network that the GTP tunnel generation-requesting mobile station 111 currently desires to access. The QoS represents the quality of the packet data transmitted through the currently generated GTP tunnel. That is, packet data using a GTP tunnel with high QoS is processed earlier than the packet data using a GTP tunnel with low QoS.
Referring to FIG. 4, upon receiving the Activate PDP Context Request message, the SGSN 115 transmits a Radio Access Bearer Setup message to the UTRAN 113 thereby establishing a radio access bearer to the UTRAN 113 in step 413. The UTRAN 113 then transmits a Radio Access Bearer Setup message to the mobile station 111 to set up a radio access bearer to the mobile station 111 in step 413. The radio access bearer is set up between the SGSN 115 and the UTRAN 113 and between the UTRAN 113 and the mobile station 111. If a trace function is activated in the UTRAN 113, the SGSN 115 transmits the Invoke Trace message to the UTRAN 113 along with trace information acquired from a home location register (not shown) or an operation and maintenance center (OMC) in step 415. The trace function is used to trace a flow of data.
When a radio access bearer is set up to the UTRAN 113, the SGSN 115 transmits a Create PDP Context Request message to the GGSN 119 in step 417. A tunnel endpoint ID (TEID) is set up between the SGSN 115 and the GGSN 119. The tunnel endpoint ID is set up to transmit packet data between network nodes using the GTP tunnel. That is, the SGSN 115 stores a tunnel endpoint ID of the GGSN 119, and the GGSN 119 stores a tunnel endpoint ID of the SGSN 115. Therefore, the Create PDP Context Request message includes a tunnel endpoint ID that should be used when the GGSN 119 transmits packet data to the SGSN 115.
Upon receiving the Create PDP Context Request message, the GGSN 119 transmits a Create PDP Context Response message to the SGSN 115 in step 419 if PDP context creation is completed in response to the Create PDP Context Request message. Generation of a GTP tunnel between the SGSN 115 and the GGSN 119 is completed, enabling packet data transmission. Upon receiving the Create PDP Context Response message, the SGSN 115 transmits an Activate PDP Context Accept message to the mobile station 111 in step 421. As the mobile station 111 receives the Activate PDP Context Accept message, a radio channel is generated between the mobile station 111 and the UTRAN 113. As a result, generation of a GTP tunnel among the UTRAN 113, the SGSN 115 and the GGSN 119 is completed. That is, the mobile station 111 can transmit and receive all packet data transmitted over its PDP address. A GTP tunnel generated in the PDP context procedure is associated with a PDP context on a one-to-one basis. If the GTP tunnel changes, the PDP context also changes. Therefore, different tunnel information is provided.
A general GTP tunnel generation procedure based on PDP context activation, i.e., a primary PDP context activation procedure, has been described With reference to FIG. 4. A GTP tunnel generation procedure based on secondary PDP context activation will now be described with reference to FIG. 5.
FIG. 5 is a signal flow diagram illustrating an example of a conventional GTP tunnel generation procedure based on secondary PDP context activation. The secondary PDP context activation procedure is defined as a procedure for newly generating a GTP tunnel by reusing the intact GTP tunnel information of the previously activated primary PDP context. That is, the GTP tunnel generated according to the secondary PDP context activation procedure is called a secondary GTP tunnel as stated above. The secondary GTP tunnel uses the intact primary PDP context information.
Referring to FIG. 5, the mobile station 111 transmits an Activate Secondary PDP Context Request message to the SGSN 115 to generate a secondary GTP tunnel in step 511. Parameters included in the Activation Secondary PDP Context Request message include NSAPI, Linked TI, PDP Type, PDP Address, Access Point Network and QoS. Unlike the Activate PDP Context Request message, the Activate Secondary PDP Context Request message includes a Linked TI. and provides the intact information on the previously activated primary PDP context, i.e., the intact primary GTP tunnel information. As described in conjunction with FIG. 4, since TI is used to identify a GTP tunnel among the mobile station 111, the UTRAN 113 and the SGSN 115, the Linked TI is used to provide the same information as the primary GTP tunnel.
Upon receiving the Activate Secondary PDP Context Request message, the SGSN 115 transmits a Radio Access Bearer Setup message to the UTRAN 113 in order to set up a radio access bearer to the UTRAN 113 in step 513. The UTRAN 113 then transmits a Radio Access Bearer Setup message to the mobile station 111 to set up a radio access bearer to the mobile station 111 in step 515. A radio access bearer is set up between the SGSN 115 and the UTRAN 113 and between the UTRAN 113 and the mobile station 111.
When a radio access bearer is set up to the UTRAN 113, the SGSN 115 transmits a Create PDP Context Request message to the GGSN 119 in step 517. The SGSN 115 transmits a primary NSAPI to indicate that the GTP tunnel to be generated is a secondary GTP tunnel. The primary NSAPI value is associated with information on the previously activated primary PDP context on a one-to-one basis. It is possible to use the primary PDP context information by consulting the primary NSAPI value. Further, the SGSN 115 transmits the Create PDP Context Request message using TFT information. To distinguish the primary GTP tunnel from the secondary GTP tunnel. That is, if TFT is not stored in the primary GTP tunnel, TFT is stored only in the secondary GTP tunnels. As described in conjunction with the primary GTP tunnel generation, a tunnel endpoint ID is newly set up between the SGSN 115 and the GGSN 119, and the tunnel endpoint ID is set up to transmit packet data between network nodes using the GTP tunnel. That is, the SGSN 115 stores a tunnel endpoint ID of the GGSN 119, and the GGSN 119 stores a tunnel endpoint ID of the SGSN 115. Therefore, the Create PDP Context Request message includes a tunnel endpoint ID that should be used when the GGSN 119 transmits packet data to the SGSN 115.
Upon receiving the Create PDP Context Request message, the GGSN 119 transmits a Create PDP Context Response message to the SGSN 115 in step 519 if PDP context creation is completed in response to the Create PDP Context Request message. Generation of a secondary GTP tunnel between the SGSN 115 and the GGSN 119 is completed, enabling packet data transmission. Upon receiving the Create PDP Context Response message, the SGSN 115 transmits an Activate PDP Context Accept message to the mobile station 111 (Step 521). As the mobile station 111 receives the Activate PDP Context Accept message, a radio channel is generated between the mobile station 111 and the UTRAN 113. As a result, generation of a secondary GTP tunnel among the UTRAN 113, the SGSN 115 and the GGSN 119 is completed. That is, the mobile station 111 can transmit and receive all packet data transmitted over its PDP address. A secondary GTP tunnel generated in the PDP context procedure is also associated with a PDP context on a one-to-one basis.
FIG. 6 is a diagram illustrating an example of a TFT information format for generation of a new TFT. If a TFT operation code of a TFT illustrated in FIG. 3 is set to “001,” a new TFT is generated. A “0” field as illustrated in FIG. 6, is a spare bit, and is a non-assigned field, the use of which is not determined yet, and is generally set to “0.” In FIG. 6, a packet filter list field is subdivided. Referring to FIG. 6, a packet filter identifier (ID) is used to identify a corresponding packet filter among a plurality of packet filters set in the TFT. As stated above, since it is assumed that the maximum number of packet filters that can be set in the TFT is 8 by way of example, the maximum number of packet filter IDs is also set to 8. In FIG. 6, the packet filter ID is expressed with 0th to 2nd bits, and the remaining 4th to 7th bits are set as spare bits.
Packet filter evaluation precedence represents an order applied to all packet filters set in the TFT. That is, the packet filter evaluation precedence represents an order in which the packet filters are to be applied to packet data received from an external network. As the packet filter evaluation precedence value is small, the order applied to the packet data received from the external network becomes smaller. If packet data is received from the external network, the TFT packet filters stored in the GGSN 119 are applied to the received packet data beginning at a packet filter with the smallest packet filter evaluation precedence value. If a header of the received packet data is not matched, a packet filter with the smallest packet filter evaluation precedence value applies the received packet data to a packet filter with a second smallest packet filter evaluation precedence value. In addition, a packet filer contents length field (length of packet filter contents) represents a length of corresponding packet filter's contents.
Finally, a packet filter content field includes a packet filter component type ID, and has a variable length. A length of the packet filter contents is variable because the packet filters have different lengths and the number of packet filters set in the TFT is variable according to circumstances. The packet filter component type ID, once it is used, cannot be used for any packet filter. It is not possible to form a packet filter by using an IPv4 source address type together with an IPv6 source address type in the same TFT. Further, it is not possible to form the packet filter by using a single destination port type together with a destination port range type. In addition, it is not possible to form the packet filter by using a single source port type together with a source port range type. The packet filter component types and their associated packet filter component type IDs are illustrated in Table 2.
TABLE 2Bits (76543210)Description0001 0000IPv4 source address type0010 0000IPv6 source address type0011 0000Protocol identifier/Next header type0100 0000Single destination port type0100 0001Destination port range type0101 0000Single source port type0101 0001Source port range type0110 0000Security parameter index type0111 0000Type of service/Traffic class type1000 0000Flow label typeAll other valuesReserved
As illustrated in Table 2, a plurality of packet filter components can be formed in one packet filter. For example, a terminal equipment (TE) can classify TCP/IPv4 packet data transmitted to a TCP port 5003 at 172.168.8.0/24, and a packet filter can be formed as defined below.
packet filter identifier=1;
IPv4 Source Address=172.168.8.0;
Protocol Number for TCP=6;
Destination Port=5003;
Classifying packet data in this manner using a plurality of parameters is called multi-field classification, and the packet filter component types will be described below.
First, an TPv4 source address type will be described. Packet filter contents set in the IPv4 source address type comprise an IPv4 address field having a 4-octet size and an IPv4 address mask field having a 4-octet size. The IPv4 address field is transmitted earlier than the IPv4 address mask. The IPv4 address field cannot be set in the TFT that is transmitted as the Activate Secondary PDP Context Request message used to access a service network of an access point network (APN).
That is, the mobile station 111 receives an actual IP address via a domain name service (DNS) server for a service network that the mobile station 111 first accesses while initially activating a secondary PDP context. In this case, since the mobile station 111 has already been waiting to transmit the Activate Secondary PDP Context Request message, it is impossible to modify packet filter contents of the set TFT. After the initial access, since the mobile station 111 recognizes an IP address of a corresponding service received from the DNS server, it is possible to use the IPv4 source address type as contents of the set TFT packet filter. When the mobile station 111 transmits the Activate Secondary PDP Context Request message to communicate with another mobile station instead of initially accessing a new service network, it is not possible to use the IPv4 source address type for the TFT as packet filter contents.
An IPv6 source address type will now be described. The IPv6 source address type comprises a 16-octet IPv6 address field and a 16-octet IPv6 address mask field. The IPv6 address field is transmitted earlier than the IPv6 address mask field.
An protocol ID/Next header type will now be described. The protocol ID/Next header type comprises a 1-octet protocol ID, e.g., IPv4, or a Next header type, e.g., IPv6. A single destination port type comprises a 2-octet destination port number. The Single destination port type can be either a UDP port value or a TCP port value according to a protocol field value of an lIP header. A destination port range type comprises a minimum value of a 2-octet destination port number and a maximum value of the 2-octet destination port number. The destination port range type can be a range of either a UDP port or a TCP port according to a protocol field value of an IP header.
A single source port type comprises a 2-octet source port number, and can be either a UDP port value or a TCP port value according to a protocol field value of an IP header. A source port range type comprises a minimum value of a 2-octet source port number and a maximum value of the 2-octet source port number, and can range from either a UDP port or TCP port according to a protocol field value of an IP header. A security parameter index type comprises a 4-octet IP security parameter index (SPI). A type of service/traffic class type comprises 1-octet Type of service (IPv4)/Traffic class (IPv6), and 1-octet Type of service mask (IPv4)/Traffic class mask (IPv6). A flow label type comprises a 3-octet IPv6 flow label, and 4th to 7th bits of a first octet constitute a spare field, and an IPv6 flow label is included in the remaining 20 bits.
Up to now, a procedure for generation a new TFT for a TFT operation code “001” has been described with reference to FIG. 6. With reference to FIG. 7, a description will be provide for deleting a stored TFT for a TFT operation code “010,” adding a packet filter to a stored TFT for a TFT operation code “011,” and replacing a packet filter of a stored TFT for a TFT operation code “100.”
FIG. 7 is a diagram illustrating a TFT information format for deleting a stored TFT, adding a packet filter to the stored TFT or replacing a packet filter of the stored TFT.
In the case of deleting a TFT, a TFT operation code is checked regardless of a packet filter list field. Thereafter, if the TFT operation code value is a prescribed value representing TFT deletion, i.e., “010,” then the same TFT as the TFT type to be deleted among the TFTs stored in the GGSN 119 is deleted from the GGSN 119. In the case of adding a packet filter to the stored TFT, the same information deleting a TFT is used, and contents of a corresponding packet filter list is added to the stored TFT. In the case of replacing a packet filter of the stored TFT, the same information of deleting a TFT and the case of adding a packet filter to the stored TFT is used, and the contents of a corresponding packet filter is deleted and then replaced.
Hitherto, a procedure for deleting a stored TFT for a TFT operation code “010,” a procedure for adding a packet filter to a stored TFT for a TFT operation code “011,” and a procedure for replacing a packet filter of a stored TFT for a TFT operation code “100” has been described with reference to FIG. 7. A procedure for deleting a packet filter of a stored TFT for a TFT operation code “101” will now be described with reference to FIG. 8.
FIG. 8 is a diagram illustrating a TFT information format for deleting a packet filter of a stored TFT. As illustrated in FIG. 8, when deleting a packet filter from a stored TFT, consideration is taken into of only a packet filter ID regardless of a packet filter list. The GGSN 119 deletes, from packet filters of the stored TFT, a packet filter corresponding to a packet filter ID of the TFT information provided from the mobile station 111. FIG. 8 shows a case of deleting, from a stored TFT, N packet filters of first to Nth packet filters.
Referring to FIG. 9 which is a block diagram illustrating a TFT packet filtering procedure in a general UMTS core network. For the convenience of explanation, FIG. 9 will be described based on the assumption that each TFT has a single packet filter. The GGSN 119 of the UMTS core network 200 has a total of 4 TFTs stored therein. Each of the 4 TFTs has one packet filter. That the GGSN 119 has the 4 TFTs stored therein means that the GGSN 119 includes one primary GTP tunnel for the SGSN 115 and 5 GTP tunnels, i.e., a primary PCP context, and 4 secondary GTP tunnels for secondary PDP contexts, and the 5 GTP tunnels share the same PDP context. The 5 GTP tunnels are identified by only the TFT.
If packet data received from an external network, e.g., the Internet 121, fails to undergo packet filtering through the 4 TFTs, the packet data is transmitted to the SGSN 115 through only a primary PDP context or a primary GTP tunnel. For example, if it is assumed that the packet data received from the Internet 121 has Type of Service (TOS) of 0x30, a protocol of TCP, a source address of 1.1.1.1, a destination address of 2.2.2.2, a source port of 200 and a destination port of 50, then the received packet data does not undergo packet filtering at up to TFT1 and TFT2 since it is not coincident with packet filter contents, and undergoes packet filtering at TFT3 since it is coincident with packet filter contents of TFT3. The received packet data is transmitted to the SGSN 115 through a GTP tunnel corresponding to the coincident TFT3. The packet data received from the Internet 121 fails to undergo packet filtering at TFT1 and TFT2 because as a source address, the TFT1 packet filter contents, is 3.3.3.3, it is not coincident with a source address “1.1.1.1” of the received packet data, and as a protocol, the TFT2 packet filter contents, is ICMP, it is not coincident with a protocol TCP of the received packet data. Further, the reason why the received packet data is filtered at the TFT3 is because TOS, the TFT3 packet filter contents, is 0×30. It is coincident with TOS “0×30” of the received packet data.
As described above, a TFT is generated usually in association with a PDP context (GTP tunnel) in the secondary PDP context activation procedure. The TFT can be added, modified or deleted via an MS-initiated PDP context modification procedure where the mobile station 111 modifies a PDP context generated in a PDP context activation procedure. Also as stated above, one PDP context can have only one TFT. In the case where the mobile station 111 intends to generate a new TFT or modify a TFT stored in the GGSN 119, the TFT should preferably store at least one valid packet filter. If there exists no valid packet filter in the stored FTF, the MS-initiated PDP context modification procedure fails, and the GGSN 119 transmits an error code representing failure of the MS-initiated PDP context modification procedure for the TFT to the mobile station 111. The TFT is deleted, if a PDP context associated with the TFT is inactivated.
As described above, however, the packet data received at the GGSN 119 from the external network undergoes packet filtering through a TFT stored in the GGSN 119, and the packet filtering through the TFT is sequentially performed beginning at a packet filter with the smallest packet filter evaluation precedence for at least one packet filter stored in the TFT. For example, if 5 TFTs are stored in the GGSN 119 and each of the 5 TFTs stores 4 packet filters, packet data received from an external network, i.e., the Internet 121, undergoes packet filtering for the 4 packet filters beginning at the first TFT among the 5 TFTs. If the packet filtering fails, the packet data received from the external network undergoes packet filtering by the second TFT. Therefore, as compared with the case where the TFT is not used for the packet data received from the external network 121, a UMTS core network performance loss can occur due to the packet filtering. If TFTs stored in the GGSN 119 abruptly increase in number and the packet data received from the external network 121 abruptly increases in amount, a performance loss due to the packet filtering can fatally affect the UMTS core network.