KR20090119081A - Method for controlling an overload between sgsn and ggsn in a general packet radio service network and a system therefor - Google Patents

Abstract

PURPOSE: A method for controlling an overload between an SGSN and a GGSN in a wireless packet service network and a system therefor are provided to control a load of the GGSN by not requesting call setup to the GGSN which is in an overload state. CONSTITUTION: An SGSN(Serving GPRS Support Node)(130) searches a plurality of GGSN(Gateway GPRS Support Node)s(140,141,142) when the SGSN receives a packet service request from an MS(Mobile Station/RNC:Radio Network Controller)(110). The SGSN is connected to the mobile terminal. The packet service is provided from a data service network. The GGSNs are connected to the data service network. One GGSN among the GGSNs except a GGSN which is in an overload state is selected. Call setup for the packet service is requested to the selected GGSN.

Description

Method for controlling an overload between SGSN and GGSN in a general packet radio service network and a system therefor}

The present invention relates to overload control in a wireless packet service network, and more particularly, to a method and system for controlling an overload between SGNS and SNS in a Global System for Mobile Communications (GSM) / Wideband Code Division Multiple Access (WCDMA) network. It is about.

In the communication network discussed in the 3GPP (3rd Generation Partnership Project) such as GSM-type second generation (2G) communication network called European communication method and WCDMA-based third generation (3G) communication network developed based on this, packet data by interworking with data service network In order to provide a service, a concept of a general packet radio service (hereinafter referred to as GPRS) has been proposed. GPRS is a high-speed wireless data transmission service provided to an Internet Protocol (IP) network and a mobile terminal wirelessly connected to a packet network for transmitting packet data in a communication system. Hereinafter, for convenience of description, a network for providing packet data to the mobile terminal is collectively called a packet data service network. In order to provide a packet data service to a mobile terminal in the packet data service network, nodes for establishing a packet call with a data service network are performed by nodes of the packet data service network. A stable packet data service is provided by maintaining a plurality of Gateway GPRS Support Nodes (hereinafter referred to as 'GGSN') which are gateways to be connected.

However, each of the plurality of GGSNs may be connected by a plurality of Serving GPRS Support Nodes (hereinafter referred to as 'SGSN') that manage packet data services to the mobile station. Typically, the SGSN selects one GGSN from the list of GGSNs accessible from the list of GGSNs that can access the data service network providing the requested packet data service and requests a call setup for the packet data service from the selected GGSN. In this case, a call establishment request for requesting multiple packet data services to one GGSN may be concentrated. Although a call setup request is concentrated in one GGSN and overloaded, SGSN can continue to request the call setup to the overloaded GGSN, thereby further increasing the load of the GGSN, thus signaling or bearer resources. The call fails due to lack of it. In addition, if the overloaded GGSN fails to send a response to the SGSN after receiving a call requesting call setup, the SGSN waits for a predetermined time and then transmits a call requesting call generation to another GGSN. It takes a lot of time. If the GGSN sends a failure response, the overload of the GGSN, which is overloaded to generate a message for this failure response, is even more weighted. In addition, if the SGSN fails to reach the SGSN normally after a message for a failure response is sent from the GGSN, the SGSN will continue to retransmit the call requesting connection to the overload GGSN to receive the response, thus increasing the load on the overloaded system. It also causes unnecessary time to transmit a call requesting a connection to another GGSN.

Accordingly, the present invention provides a method and system for controlling overload between SGSN and GGSN in a wireless packet service network.

According to one aspect of the preferred embodiment of the present invention, in the wireless packet service network of the present invention, the load control method provides the packet service when a packet service request is received from the mobile terminal by a SGSN connected to the mobile terminal. Searching for a plurality of packet gateway support nodes (GGSNs) connected to a data service network; selecting one GGSN except for an overloaded GGSN among the searched GGSNs; and serving the packet with the selected GGSN. And requesting call setup for the call. In addition, the load control method of the present invention, after the call setup request to the selected GGSN, receiving a response message for the request from the GGSN, checking the inclusion of the overload information in the received response message, If the overload information is included, the method further includes storing the GGSN transmitting the response message as the overload state GGSN.

According to another aspect of the preferred embodiment of the present invention, in the wireless packet service network of the present invention, the load control system requests a packet data service, receives a requested packet data service, and is connected to the mobile terminal. When a packet service request is received from a mobile station, a plurality of packet gateway support nodes (GGSNs) connected to a data service network providing the packet service are searched, and then one GGSN except for an overloaded GGSN among the searched GGSNs. A packet switching support node (SGSN) requesting call setup for packet service and an access point node (APN) are supported to connect to the data service network, and upon receipt of a call setup request from the SGSN, the allocation resource is checked. If the GGSN and the overload state to send a response message containing the overload information to the SGSN and, The site includes a domain name system (DNS) server that provides the information of the GGSN is connected to the service network.

The foregoing has outlined rather broadly the features and technical advantages of the present invention in order that those skilled in the art may better understand it from the following detailed description of the invention. In addition to these features and advantages, further features and advantages of the present invention which form the subject of the claims of the present invention will be better understood from the following detailed description of the invention.

The present invention can control the load of the GGSN by not requesting the call setup to the GGSN under an overload condition, thereby improving the performance of the entire system. In addition, when the GGSN supporting a specific APN supported by the provider providing the mobile communication service transitions to an overload, the SGSN detects this, and the subsequent call establishment request attempts to call another supportable GGSN except for the overload GGSN. The time required to receive a call to another GGSN after receiving a failure response message can be shortened. By not requesting additional new call creation with an overload GGSN, the GGSN can quickly transition to a steady state, thereby improving overall network stability. In addition, when a GGSN supporting a plurality of APNs is excessively occupied by a specific APN and transitioned to an overloaded state, the present invention may control a call attempt request for each APN so that the service can be smoothly supported. By excluding the GGSN, which is overloaded, from the call setup request attempt for a predetermined time, the present invention can prevent the load weighting caused by unnecessary message transmission in advance, thereby reducing the overall call failure rate.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings. In this case, it should be noted that like elements are denoted by like reference numerals as much as possible. In addition, detailed descriptions of well-known functions and configurations that may blur the gist of the present invention will be omitted.

1 is a schematic configuration diagram of a mobile communication system in a packet service network according to an embodiment of the present invention.

Referring to FIG. 1, in order to provide a packet data service requested by a mobile station (MS) 110, 111, the mobile station 110, 111 is a UTRAN (UMTS Terrestrial Radio Access Network) 120 or a base station system. (Base Station System: BSS) 121 is connected to the SGSN 130. The UTRAN 120 may be configured with a base station Node B and a radio network controller (hereinafter referred to as 'RNC') for allocating or managing radio resources of corresponding base stations, and the mobile terminal 110. A function of receiving a communication request signal, a data transmission request signal or uploading data from the SGSN 130, receiving the packet data from the SGSN 130, and transmitting the packet data to the corresponding mobile terminal 110. To perform. The base station subsystem (BSS) 121 may be composed of a base transceiver station (BTS) and a base station controller (BSC), and a data request signal from the mobile station 111. Receives and transmits to the SGSN 130, and transmits the data received from the SGSN 130 to the mobile terminal 111.

The SGSN 130 manages a mobile terminal's mobility management, an incoming / outgoing signal processing procedure, and a session for transmitting and receiving packet data for a packet data service, and refers to a home location register (HLR). And authentication and billing functions in conjunction with the 160. In addition, SGSN 130 performs a routing processing function of the packet data. The GGSN 140 is an IP-based packet network that provides the packet service, that is, a node that supports access to the data service network 170 through an access point node (hereinafter referred to as an 'APN'). For the packet data service, the mobile station 110 or 111 assigns an IP address, manages a session, and performs packet routing function. In addition, the GGSN 140 serves as a gateway to the data service network 170 connected through the APN. Here, the APN is a delimiter including an IP address for accessing the Internet providing packet data, and may be used as a delimiter for a specific service. In this case, the SGSN 130 may be connected to a network providing a packet data service through a selected GGSN among a plurality of GGSNs.

The HLR 160 performs authentication function for the requested mobile terminal while storing mobile terminal information, subscriber information of the mobile terminal, location information, and the like. The domain name system (hereinafter referred to as 'DNS') server 150 stores information about a domain name and its corresponding IP address, and then information about GGSN supporting specific APN from SGSN 130. When receiving a request for the IP address information of the corresponding GGSN informs SGSN (130).

Uu, Um, Iu, Gb, Gn, Gi, Gr are the nodes, i.e., mobile terminals 110 and 111, UTRAN 120, BSS 121, SGSN 130, GGSN 140, DNS server ( 150, interfaces between the HLR 160 and the data service network 170.

When a packet data service is requested from the mobile terminals 110 and 111 of FIG. 1, a call setup process between the mobile terminals 110 and 111 and the data service network 170 according to the standard (3GPP) will be described in detail with reference to FIG. 2. Take a look.

2 is a flowchart illustrating a call setup process according to an embodiment of the present invention.

Referring to FIG. 2, the RNC managing the MS 110 and the MS 110, which are mobile terminals normally registered to a local subscriber, are connected to the SGSN 130 in step 210 for the packet data service to the SGSN 130. To set up a call, a service request message is sent. The SGSN 130 analyzes the service request message received from the MS 110 through the RNC in step 220 to authenticate whether the subscriber is a registered subscriber, and then responds to the service request message if the subscriber is an authenticated subscriber. A service accept message, which is a message, is transmitted to the MS 110. At this time, the transmission to the MS 110 is transmitted under the management of the RNC, but for convenience of description below, the RNC is omitted and only the MS 110 is described. In step 230, the MS 110 accepting the service transmits an PDP context activation request message (Activate PDP (Packet Data Protocol) Context Request) including the call information to be serviced to the SGSN 130. In this case, the PDP context activation request message includes APN information and quality of service (QoS) information of the packet service requested by the MS 110.

The SGSN 130 extracts APN information from the PDP context activation request message received from the MS 110 in step 240 and then retrieves the IP address of the GGSN supporting the extracted APN. In the present invention, SGSN 130 stores the IP address information of the GGSN supporting for each APN obtained in the previous process in a database. At this time, when the information of the GGSN is overloaded, SGSN 130 stores the overload status information for the GGSN. The GGSN set to such an overload state is excluded from the request for call establishment in subsequent attempts. That is, a call establishment request is attempted to another GGSN supporting the APN except for the GGSN which is overloaded. If SGSN 130 does not exist the information of the GGSN corresponding to the extracted APN, after querying the GGSN information supporting the requested APN to the DNS server 150 that provides information on the GGSN supporting the APN The inquiry process of receiving the GGSN information list (GGSN IP List) from the DNS server 150 is performed. Although one DNS server 150 is illustrated in FIG. 2, two or more DNS servers may exist. After the inquiry process, SGSN 130 stores the obtained GGSN information. In this process, the GGSN requests the call setup to the IP address of the selected GGSN by selecting one from the top of the list or one of the GGSNs supporting the APN. For convenience of explanation, in the case where the GGSN is not overloaded, the call setup request process is sequentially performed from the top of the list of corresponding GGSNs. In FIG. 2, it is assumed that GGSN1 140, GGSN2 141, and GGSN3 143 exist as GGSN supporting the extracted APN, and SGSN 130 transfers information that GGSN1 140 is in an overloaded state. It is assumed that it is acquired and stored through the call setup process.

Since it is assumed that the GGSN1 140 is in an overloaded state among the GGSNs supporting the extracted APNs, in FIG. 2, the SGSN 130 selects the next rank GGSN2 141 among the remaining ones except for the GGSN1 140 and then, in step 250. A PDP context request message (Create PDP Context Request) is transmitted to the IP address of the GGSN2 141. After receiving the PDP context creation request message from the SGSN 130, the GGSN2 141 performs a procedure such as resource allocation and authentication, and then, when ready for call setup, the GGSN2 141 responds to the PDP context creation request message in step 260. A PDP context response message (Create PDP Context Response) is transmitted to the SGSN 130. At this time, if the GGSN2 141 is also overloaded, a PDP context response message (Add PDP Context Response) added to the GPRS Tunneling Protocol (hereinafter referred to as GTP) message to the SGSN 130 is added. send. A detailed description of adding overload state information to the GTP message will be described later. The SGSN 130 that receives the overload state information of the GGSN2 141 stores the overload state with respect to the stored GGSN2 141 in step 270. By doing so, the GGSN2 141 is excluded from the call setup request object in the call setup request. At this time, the exclusion from the call establishment request target for the GGSN2 141 is until the timer to be described later expires.

Upon receiving the PDP context creation response message, the SGSN 130 transmits an PDP context activation accept message (Activate PDP Context Accept), which is a response to the PDP context activation request message received in step 230, to the MS 110 in step 280. When the MS 110 receives the PDP context activation accept message, the call setup process is completed. Accordingly, in step 290, the MS 110 may be connected to the APN through the GGSN2 141 to receive a desired packet data service.

For a process between SGSN and GGSN in a PDP context setup process performed for packet service to MS 110, that is, a SGSN selects one GGSN from among a plurality of GGSNs supporting a specific APN and performs a call setup request. See details in SGSN and GGSN, respectively.

3 is a flowchart illustrating a process of performing a call setup request in SGSN according to a preferred embodiment of the present invention.

Referring to FIG. 3, in step 305, the SSGN 130 of FIG. 1 receives a PDP context activation request message from the MSs 110 and 111. Here, the PDP context activation request message is received by the SGSN 130 from the MSs 110 and 111 via the RNC in the UTRAN 120 as described in FIG. 2, but without reference to the UTRAN 120 for convenience of description below. It is described as being received from the MSs 110 and 111. In step 310, the SGSN 130 retrieves information on the GGSNs supporting the APN by extracting APN information included in the received PDP context activation request message. In the previous process, information of GGSNs supporting the APN obtained after inquiring the DNS server 150 is stored in the SGSN 130. In step 315, the SGSN 130 checks whether information of GGSNs supporting the APN exists. If information on the GGSNs supporting the APN exists, the SGSN 130 proceeds to step 320, and if not present, proceeds to step 360. In step 320, the SGSN 130 checks whether the GGSNs supporting the APN are overloaded. In this case, the information on the overload is information indicating the load state of the GGSN and is obtained by receiving a message including an overload extension header from the GGSN and stored together with the GGSN information. In step 325, the SGSN 130 selects a GGSN that is not stored as an overload GGSN and transmits a PDP context creation request message requesting call setup to an IP address of the selected GGSN. Here, the selection of the GGSN is explained on the assumption that the upper GGSN is selected among the GGSNs that are not overloaded in the list of GGSNs supporting the APN, but the order of selection may be determined differently.

In step 330, the SGSN 130 checks whether a response message to the PDP context creation request message sent to the selected GGSN is received from the GGSN. If the response message is received, SGSN 130 proceeds to step 335, otherwise proceeds to step 370. In step 335, the SGSN 130 checks whether an extension header is included in the PDP context creation response message, which is the received response message. At this time, the overload extension header is one of the extension headers of the GPRS Tunneling Protocol (hereinafter referred to as 'GTP')-C message and indicates an overload state of the GGSN. The GTP is a protocol for controlling the interface between the SGSN and the GGSN. The GTP may be divided into a GTP-C (Control) protocol for control message transmission and a GTP-U (User) protocol for data transmission. The load state field value is included in an extended header portion of a control message (hereinafter, referred to as a 'GTP-C message') transmitted by the GTP-C protocol. For detailed description, the header of the GTP-C message defined in the standard (3GPP Technical Specification (TS) 29.060 V8.3.0) will be described with reference to FIGS. 5A and 5B.

5A is a table showing a header structure of a GTP-C message used in a wireless packet service network.

Referring to FIG. 5A, a header of 12 octets includes a 3-bit version field, a protocol type (PT) field of each 1-bit field, an extension header flag (E) field, Sequence number flag (S) field, N-PDU flag (Protocol Data Unit flag) field, 8-bit message type field, 16-bit length field, 32-bit tunnel endpoint identifier (Tunnel Endpoint Identifier: TEID) field, 16-bit sequence number field, 8-bit N-PDU number field, 8-bit Next Extension Header Type. The version field is a field indicating GTP protocol version information, the PT field is a field indicating type information about GTP to be interpreted, the E field is a field indicating whether the next extended header field is set, and the S field is a sequence number field. Is a field indicating whether or not is set, and the PN field is a field indicating whether the N-PDU number field is set. Load state information of the GGSN of the present invention may be added to the next extension header type field.

5B is a table defining a GTP-C extended header type according to a preferred embodiment of the present invention.

Referring to FIG. 5B, if the field value indicating the next extension header is '0000 0000', there is no extension header. If the field value indicating the next extension header is '0000 0001', it indicates whether SGSN supports MSMS. If the field value indicating the next extension header is '0000 0010', it indicates the MS information change report support indicator indicating whether SGSN supports the MS information change reporting mechanism, and the field value indicating the next extension header. If '1100 0000', the Serving Radio Network Subsystem (SRNS) transport time to provide Packet Date Convergence Protocol (PDCP) sequence numbers of non-acknowledged N-PDUs. PDCP PDU number to be transmitted. If the field value indicating next extension header is '1100 0001', it supports DTM during the call. Indicates a stop request transmitted at the handover in the SGSN when the MS moves to the cell, and indicates a 'stop response' that is a response to the 'stop request' when the field value indicating the next extended header is '1100 0010'. . In addition to the next extension header defined in the above-described standard (3GPP TS 29.060), a field indicating a load state of the GGSN is defined as shown in FIG. 5B. If the field value indicating the next extension header is '1100 0011', it indicates an overload indicating information on the overload state of the GGSN requested to set up a call. The structure of the extended header indicating whether overloaded is shown in Table 1 below.

Bits Octets 8 7 6 5 4 3 2 One One One 2 0xFF 3 0xFF 4 Next Extension Header Type

In Table 1, since the overloaded header is 4 octets long, the value of the first octet displayed as the length is '1', and the initial values of the second and third octets are set to '0xFF'. do. The fourth octet indicates whether the next extension header is followed. If there is no subsequent extension header, the fourth field is set to '0'.

The load state of the GGSN indicated by the overload extension header may have three stages as shown in Table 2 below.

 Value  Definition 0x0001  Minor overload state 0x0002  Major overload state 0x0003  Critical overload state

If the value of the overload extension header is '0001 (hexadecimal)', it indicates that GGSN is a minor overload condition; if the value of the overload extension header is '0002 (hexadecimal)', it indicates that the GGSN is a major overload condition If the value of the overload extension header is '0003 (hexadecimal)', it indicates that the GGSN is in a critical overload state. In detail, the overload condition may be displayed by using the second and third octets of Table 1, for example, in the case of the value of '0x0001' of Table 2, '0x00' is the second octet position. '0x01' may be displayed in place of the third octet to indicate an overload condition. The degree of the overload state may be set by a system operator and the like, and the overload state may be divided into fewer or more steps instead of the three steps illustrated in Table 2. Of course. When the overload stage is set as shown in Table 2, the SGSN releases the overload stage set in the GGSN by the following processes.

1. If the SGSN includes an overload extension header set to one of the steps in Table 2 in a response message received from a specific GGSN, the call setup request is not attempted for a predetermined time with the specific GGSN. Here, the predetermined time is a predetermined time set by the operator or the like, and the timer is driven in each step along with the overload state setting. In this case, the timer driven in stages sets a timer for a predetermined time in the case of a minor overload state, and sets a timer for twice as long as the time determined in the slight overload state in the case of a severe overload state, In the case of a severe overload condition, the timer is set to three times as long as the time specified for the minor overload condition.

2. The GGSN stores the IP address of the GGSN along with the overload state and releases the overload state after a predetermined time, that is, when the set timer expires.

3. If the call setup to the GGSN is requested after the overload state set for the GGSN is released, the call setup is requested to the GGSN without excluding the GGSN.

If the SGSN 130 includes the overload extension header in the received PDP context creation response message in step 340, the SGSN 130 proceeds to step 345. In step 345, the SGSN 130 checks the overload step included in the PDP context creation response message and sets and stores an overload state in the GGSN. By doing so, the GGSN is excluded from the list of GGSNs to be attempted when the PDP context establishment request is made. Although the PDP context creation response message including the overload extension header is received, the current call setup is possible since the response message is received from the requesting GGSN. In step 350, the SGSN 130 transmits a PDP activation acceptance message to the MS 110. As a result, the MS 110 may access the data service network to which the MS 110 is to be connected and receive a packet data service. In FIG. 3, the response message received from the GGSN is limited to the message that accepts the GGSN call setup request in step 335. However, when the response message received from the GGSN indicates a call setup failure, step 380 is executed.

Since the SGSN 130 does not store information on the GGSNs supporting the requested APN, the SGSN 130 queries the DNS server 150 for information on the corresponding GGSNs in step 360. In step 365, the SGSN 130 transmits a PDP context creation request message for requesting call establishment to one GGSN among the GGSNs obtained from the DNS server 150.

The SGSN 130 waits for a predetermined time a response message for the PDP context creation request message requested to the GGSN in step 370, and then checks whether the response message is received in step 375. If a response message is received, the SGSN 130 proceeds to step 330, otherwise, in step 380, the SGSN 130 selects a different GGSN from among the GGSNs supporting the requested APN and requests a call establishment request for setting up a call. To send. At this time, the selected GGSN is one of the normal GGSNs except for the GGSNs in which an overloaded state is set among the GGSNs supporting the requested APN.

A process of transmitting a PDP context creation response message including information on whether an overload condition is received by the GGSN receiving the PDP context creation request message will be described in detail with reference to FIG. 4.

4 is a flowchart illustrating a process of performing a response to a call establishment request in a GGSN according to a preferred embodiment of the present invention.

Referring to FIG. 4, in step 410, the GGSN 140 of FIG. 1 receives a PDP context creation request message requesting call setup from the SGSN 130. In step 420, the GGSN 140 checks the allocated resource state of the GGSN 140 in order to confirm whether the resource allocation for the call setup and the overload state is set in the SGSN 130. In step 430, the GGSN 140 checks whether the overload state is set, and then proceeds to step 440 when the overload state is set. Otherwise, the GGSN 140 proceeds to step 470. In step 440, the GGSN 140 checks the degree of overload. At this time, the degree of overload may be divided into three stages as shown in Table 2. That is, in the case of an overload condition, it is divided into three phases, a mild overload condition, a serious overload condition, and a serious overload condition, and a criterion for classifying them may be determined by an operator operating the system. In step 450, the GGSN 140 generates a PDP context creation response message including the overload extension header set according to the identified overload condition. Here, the overload extension header follows the structure of the GTP-C header shown in FIGS. 5A and 5B. In step 460, the GGSN 140 transmits the generated PDP context creation response message. If the GGSN is not in an overload state, the GGSN 140 generates a PDP context creation response message that does not include the overload extension header in step 470.

6 is a flowchart illustrating a call setup process between SGSN and GGSN according to an overload condition according to an embodiment of the present invention.

Referring to FIG. 6, when the SGSN 130 of FIG. 2 receives a call setup request for a packet data service from the MS 110 in step 610, the APN information is extracted from the received message and the information of the GGSNs supporting the APN is extracted. Search. In FIG. 6, it is assumed that SGSN 130 stores information on GGSNs supporting the extracted APNs, and GGSN1 140, GGSN2 141, and GGSN2 142 are GGSNs supporting the APN. Assume that there is In addition, it is assumed that the GGSN2 141 is stored as an overload GGSN during the previous call setup process.

In step 613, the SGSN 130 transmits a PDP context creation request message to the GGSN1 140 that is higher in the list of GGSNs supporting the APN. Receiving the call establishment request, the GGSN1 140 checks the resource status in step 615, generates a PDP context creation response message, and transmits it to the SGSN 130. Here, the GGSN1 140 confirming the resource state generates a PDP context creation response message including the overload extension header indicating the overload state. The overload condition and the overload extension header are as described above with reference to FIGS. 5A and 5B and <Table 2>. Upon receiving the PDP context creation response message including the overload extension header, the SGSN 130 checks and stores the overload state of the GGSN1 140 from the overload extension header. After the call setup request, the GGSN1 140 is excluded from the call request target until the timer expires. At this time, the GGSN1 140 operates the set timer as described in Table 2 according to the set overload state step, and when the driven timer expires, the overload state set in the GGSN1 140 is released. The detailed description of this is omitted as it is shown in <Table 2>. In operation 630, the SGSN 130 that has received the call establishment request may provide the packet data service to the MS requesting the call establishment by connecting to the GGSN1 140.

Thereafter, in step 640, when the SGSN 130 receives a call setup request for the same APN as the APN extracted in step 610, the SGSN 130 searches for information on the GGSNs supporting the APN. The GGSNs supporting the APN include GGSN1 (140), GGSN2 (141), and GGSN3 (142). Among them, GGSN1 (140) and GGSN2 (141) are stored as overloaded GGSN, so SGSN (130) is GGSN1. 140 and GGSN2 141 request call establishment to GGSN3 142 except from the call request target. That is, in step 643, the SGSN 130 transmits a PDP context creation request message to the GGSN3 142. In response to this, the GGSN3 142 transmits a PDP context creation response message to the SGSN 130 in step 645. At this time, the GGSN3 142 transmits a general PDP context creation response message that does not include an overload extension header because the resource is not in an overloaded state. The SGSN 130 that has received the call establishment request may provide the packet data service to the MS requesting the call establishment by connecting to the GGSN3 143 in step 650.

7 is a flowchart illustrating a call setup process between SGSN and GGSN according to an overload condition according to another embodiment of the present invention.

Referring to FIG. 7, a packet data service is performed by a call previously established between the SGSN 130 and the GGSN1 140 of FIG. 2 in step 710. In step 713, the echo request message (Echo Request) is transmitted to the GGSN1 140 to check the path for the call. In order to check whether the established call path is maintained, a confirmation message is periodically transmitted to the opposite node, which is an echo request message. The echo request message may be transmitted by the SGSN 130 to the GGSN1 140, or may be transmitted by the GGSN1 140 to the SGSN 130. It is assumed that the transmission. In response to receiving the echo request message in step 715, the GGSN1 140 transmits an echo response message to the SGSN 130 in response thereto. At this time, the GGSN1 140 checks the allocation resource state and generates an echo request message including an overload extension header indicating that the overload state is overloaded. In this case, as described in Table 2, the overload extension header may be divided into three levels of overload conditions, and a detailed description thereof will be omitted. In addition, the structure of the echo request message and echo response message is in accordance with the structure of the echo request message and echo response message specified in the standard (3GPP TS 29.060 V8.3.0), and is an optional information element. Extension field can be used. The structure of the private extension field defined in the standard is outlined in Table 3 below.

Bits Octets 8 7 6 5 4 3 2 One One Type = 255 (Decimal) 2 ~ 3 Length 4 ~ 5 Extension Identifier 6 ~ m Extension Value

As shown in Table 3, the first octet represents the type of the private extended field, the second through third octets represent the length of the private extended field, and the fourth through fifth octets are used for the enterprise-specific use. Field represents an Extension Identifier field that identifies the company, and the sixth to mth octets are the extension value fields, which contain tags, lengths, and values. Indicates. Here, the overload state of Table 2 may be represented by an extended value field, and the format of the extended value field may be a TLV (Tag, Length, Value) format as shown in Table 4 below.

Extension Value length Description TAG 1 byte Type: Octet Tag Identifier = H'xx (Dxx) ― GSN Overload Length 1 byte Type: Octet Length of Value field (2) Value 2 bytes Type: Octet Value: GSN Overload Value

 As shown in Table 4, the extended value field may include a tag field of 1 byte, a length field of 1 byte, and a value field of 2 bytes. The tag field value is an octet type and can be used after being defined for each service provider. The tag field value indicates whether a value indicating an overload state of a GPRS support node (GSN) is set. ) Value (H'xx). The length field value is set to '2' because it indicates the length of a value field of 2 bytes. The value field value is an octet type and has a length of 2 bytes. The overload condition can be set.

7 again, the SGSN 130 checks the overload extension header included in the echo response message received in step 720 and stores the overload state of the GGSN1 140. The GGSN1 140 stored in an overloaded state is then excluded until the timer set in the GGSN list requesting call setup expires when a new call setup request is made. The timers are driven for a predetermined time according to the overload condition and can be driven in three stages as shown in <Table 2>. When the timer expires, the overload is cleared.

Thereafter, in step 730, when a call setup request for a packet data service is requested from the MS, the APN information is extracted from the received message to retrieve information on the GGSNs supporting the APN. In this case, the extracted APN information is the same APN as the APN of the packet service provided in step 710. Thus, the list of GGSNs supporting the APN is also GGSN1 140, GGSN2 141 and GGSN3 142. FIG. 7 assumes that SGSN 130 stores information about GGSNs supporting the extracted APNs as in FIG. 6, and GGSN1 140 and GGSN2 141 are GGSNs supporting the APNs. Assume there is a GGSN2 142.

The SGSN 130 selects a GGSN to request call setup in order to provide the requested packet data service. The GGSN1 140 is stored as an overloaded GGSN in step 720, and the GGSN2 141 is in the call setup process before the step 710. Since it is assumed that the GGSN is stored in an overloaded state, the SGSN 130 attempts a call setup request to the GGSN3 142. That is, in step 733, the SGSN 130 transmits a PDP context creation request message to the GGSN3 142. Receiving the call establishment request, the GGSN3 142 checks the resource status in step 735, generates a PDP context creation response message, and transmits it to the SGSN 130. Here, the GGSN3 140 confirming the resource state generates a PDP context creation response message including the overload extension header indicating the overload state. The overload condition and the overload extension header are as described above with reference to FIGS. 5A and 5B and <Table 2>. Upon receiving the PDP context creation response message including the overload extension header, the SGSN 130 checks and stores the overload state of the GGSN3 142 from the overload extension header in step 740. After the call setup request, the GGSN3 142 is excluded from the call request target until the timer expires. At this time, the GGSN3 142 operates the set timer as described in Table 2 according to the set overload state step. When the driven timer expires, the overload state set in the GGSN3 142 is released. Detailed description thereof is as shown in <Table 2> and will be omitted. In operation 750, the SGSN 130, which has received the call establishment request, may connect with the GGSN3 142 to provide the packet data service to the MS requesting the call establishment. As described above, the present invention can solve the problem of further increasing the load of the overloaded GGSN by not attempting a call setup request with the overloaded GGSN or degrading the performance of the overall system.

On the other hand, the embodiments of the present invention disclosed in the specification and drawings are merely presented specific examples to easily explain the technical contents of the present invention and help the understanding of the present invention, and are not intended to limit the scope of the present invention. It will be apparent to those skilled in the art that other modifications based on the technical idea of the present invention can be carried out in addition to the embodiments disclosed herein.

1 is a schematic configuration diagram of a mobile communication system including a packet service network according to an embodiment of the present invention.

2 is a flowchart illustrating a call setup process according to an embodiment of the present invention.

3 is a flowchart illustrating a process of performing a call setup request in SGSN according to a preferred embodiment of the present invention.

4 is a flowchart illustrating a process of performing a response to a call establishment request in a GGSN according to a preferred embodiment of the present invention.

5A is a table showing the header structure of a GTP-C message used in a wireless packet service network.

5B is a table defining a GTP-C extended header type according to a preferred embodiment of the present invention.

6 is a flowchart illustrating a call setup process between SGSN and GGSN according to an overload condition according to an embodiment of the present invention.

7 is a flowchart illustrating a call setup process between SGSN and GGSN according to an overload condition according to another embodiment of the present invention.

Claims (21)

A load control method in a wireless packet service network, Retrieving a plurality of packet gateway support nodes (GGSNs) connected to a data service network providing the packet service when a packet service request is received from the mobile station by a packet switched support node (SGSN) connected to a mobile station; Selecting one GGSN except for an overload GGSN from the searched GGSNs, Requesting call setup for the packet service to the selected GGSN. The method of claim 1, Receiving a response message for the request from the GGSN after a call establishment request to the selected GGSN; Checking whether the overload information is included in the received response message; If the overload information is included, storing the GGSN transmitting the response message as the overload state GGSN. The method of claim 2, wherein the overload information is A load control method characterized by one of three phases: minor overload, major overload, and critical overload. The method of claim 3, wherein the overload information, And an extension header of a radio packet service (GPRS) tunneling protocol (GTP) -control protocol message header, which is a protocol for controlling a connection between the SGSN and the GGSNs. The method of claim 4, wherein the overload state, A load control method, characterized in that released when the timer (Timer) during the time corresponding to the overload state of each step expires. The method of claim 2, wherein the overload information is A load control method, characterized in that it represents one of at least two set overload condition steps. The method of claim 2, After retrieving the GGSNs, if the GGSNs connected to the data service network providing the requested packet service do not exist in the stored information, request information of the GGSNs connected to the data service network to a domain name system (DNS) server. Process, And receiving and storing the information of the GGSNs from the DNS server. The method according to claim 1 or 7, GGSNs connected to the data service network providing the packet service are nodes supporting access to the data service network providing the packet service through an access point node (APN). The method of claim 5, wherein the requesting for call establishment for the packet service to the selected GGSN comprises: And transmitting a PDP context creation request message (PDP Context Request). The method of claim 9, wherein the response message, Load control method characterized in that the PDP context creation response message (Create PDP Context Response). The method of claim 10, wherein the response message, And if the overload information is not included, storing the GGSN transmitting the response message as a GGSN in a normal state. In a load control system in a wireless packet service network, A mobile terminal for requesting a packet data service and receiving a requested packet data service; After retrieving a plurality of packet gateway support nodes (GGSNs) connected to the mobile station and connected to a data service network providing the packet service upon receiving a packet service request from the mobile station, the GGSNs are overloaded. A packet switched support node (SGSN) requesting call establishment for the packet service with one GGSN except for a GGSN, A GGSN supporting access to the data service network through an access point node (APN), and when a call setup request is received from the SGSN, an allocated resource is checked and a response message including the overload information is transmitted to the SGSN when it is overloaded. Load control system comprising a. The method of claim 12, wherein the SGSN, When the response message is received from the GGSN, after checking whether the received response message includes the overload information, if the overload information is included, the GGSN transmitting the response message is stored as a GGSN of the overload state Load control system. The method of claim 13, wherein the overload information, A load control system characterized by one of three phases: minor overload, major overload, and critical overload. The method of claim 14, wherein the overload information, And an extension header of a radio packet service (GPRS) tunneling protocol (GTP) -control protocol message header, which is a protocol for controlling a connection between the SGSN and the GGSNs. The method of claim 15, wherein the SGSN, And a timer for a time corresponding to the overload state of each step, and releasing the overload state set in the GGSN when the timer expires. The method of claim 13, wherein the overload information, A load control system, characterized in that it represents one of at least two set overload condition steps. The method of claim 13, And a domain name system (DNS) server for providing information of GGSNs connected to the data service network. The method of claim 16, wherein the SGSN, And a packet data protocol (PDP) context creation request message (PDP Context Request) for requesting call establishment for the packet service. 20. The method of claim 19, wherein the GGSN And a PDP context response message (Create PDP Context Response) in response to the PDP context creation request message. The method of claim 20, wherein the SGSN, And when the overload information is not included in the PDP context creation response message, storing the GGSN transmitting the response message as a normal state GGSN.

Images