KR20050067948A - Method for applying resource reservation protocol in 3rd generation network - Google Patents

Abstract

The present invention provides an internal QoS (Quality of Service) when reserving resources in a core network for smooth transmission of various multimedia data in an environment based on a 3rd generation network. An extended Resource Reservation Protocol (RSVP) that separates the mechanisms, and uses the Tunneled RSVP mechanism between the Serving Generalized Packet Radio Service Support Node (SGSN) and the Gateway Generalized Packet Radio Service Node (GGSN). The GGSN is responsible for the conversion function to support the interaction between the external packet-based network and the third generation network. It acts as a proxy to provide end-to-end QoS in 3G networks. And it is.

Description

Method for applying resource reservation protocol in 3rd generation network

The present invention relates to a method of operating a Resource Reservation Protocol (RSVP) protocol in a 3rd generation network, and more particularly, between a Serving Generalized Packet Radio Service Support Node (SGSN) and a Gateway Generalized Packet Radio Service Node (GGSN). The present invention relates to RSVP which reserves resources by using the Tunneled RSVP mechanism and integrates and transmits several RSVP Refresh Path messages transmitted to the same terminal.

The popularity of the Internet and a great interest in the field of communication have increased interest in the combination of mobile communication technology in a wireless environment and Internet multimedia communication technology based on IP (Internet Protocol). The most representative of them is the evolution of mobile communication based on IMT 2000 (International Mobile Telecommunications-2000) and UMTS (Universal Mobile Telecommunication System) called 3G networks.

The third generation network based on UMTS and Generalized Packet Radio System (GPRS) is composed of a core network interworking with an IP-based Internet network. The core network consists of a Serving GPRS Support Node (SGSN), a Gateway GPRS Support Node (GGSN) and a Universal Terrestrial Radio Access Network (UTRAN).

The SGSN tracks the location of the mobile host in its routing area and plays the role of location management, session management, and authentication. The SGSN is connected to a UTRAN that provides a data transmission service and a data reception service to the mobile host.

GGSN acts as a gateway that connects the IP-based Internet and third-generation networks, and manages the location, sessions, and authentication of mobile hosts. GGSN uses the GPRS Tunneling Protocol (GTP) to provide tunneling, IP address management, and packet routing to SGSN or UTRAN. GGSN is connected to SGSN through the IP-based UMTS Backbone Network.

In this core network structure, a mobile host accesses an external IP network with its Quality of Service (QoS) Profile through a Packet Data Protocol (PDP) context. However, the core network cannot provide differentiated services according to this QoS profile for the transmitted traffic.

In addition, because communication between SGSN and GGSN is based on Internet Protocol (IP) tunnels, when IP packets arrive at the GGSN in an external IP network, standard IP packets are added to the new GPRS Tunneling Protocol (GTP) packet header (GTP). Header is added to encapsulation and sent to the destination of 3G network. This process occurs because GTP Tunneling technology used in 3G network is used to transmit packets from external IP network to internal mobile host. Therefore, since the RSVP message cannot be distinguished from the core network, there is a problem in that resources are not actually reserved.

RSVP is a signaling protocol used to provide QoS to a specific application data stream or flow.

The sender sends a Sender Tspec, which describes the characteristics of the traffic, to the receiver in a Path message, and the Recipient who receives the Path message responds with a Resv message requesting to reserve the flow. Reserve a resource at.

All intermediate routers between the sender and the receiver accept or reject the Resv message. If the router rejects, the router transmits an error message to the receiver and the signaling process ends. On the other hand, if the acceptance, the bandwidth and buffer for the flow is allocated and the information of the related flow state is set.

Since RSVP operates with a soft-state mechanism, previous reservations will automatically disappear over time, so periodic refresh messages must be sent to keep resources reserved. The update message means that a resource is rescheduled and updated through a path message and a resv message. Hereinafter, a path message for updating is referred to as a refresh path message for convenience.

And when linking 3G network that provides services based on best-effort with IP based Internet, there are many techniques to apply the QoS mechanism provided by IP based Internet to 3G network as it is. For example, there is a technique of transparently processing RSVP in an application in a core network, a technique of preventing RSVP flow in a GGSN, and a technique of applying a Diffserv structure to a core network.

However, since these processing techniques do not support resource reservation in the core network of the third generation network, the QoS provided by the IP-based Internet cannot be provided to an end-user mobile host.

More specifically, the technique of transparently processing RSVP in the application in the core network only provides the role of delivering the RSVP in the application, incurring RSVP update overhead without supporting QoS in the core network.

Next, the technique of blocking RSVP flow in GGSN does not properly reflect the change in the network in the situation where the QoS of each application of the mobile host is dynamically changed. In addition, the end-to-end QoS structure of RSVP is broken, which does not guarantee QoS in the core network.

Finally, the Diffserv architecture is applied to the core network simply by applying Diffserv to the core network. QoS is not provided for each end-to-end flow.

In order to solve the above problems, an object of the present invention is to guarantee the end-to-end flow QoS by reserving resources using the Tunneled RSVP mechanism between the SGSN and GGSN in the third generation network.

Another object of the present invention is to integrate and transmit several RSVP Refresh Path messages transmitted to the same terminal.

To this end, the method of operating the RSVP protocol in the GGSN of the third generation network according to the present invention, the first process of transmitting the first Path message received from the CN to the mobile host, and establishing a first RSVP session between the GGSN and SGSN ; A second step of setting the first RSVP session to a long_term state when a predetermined number of Refresh messages are exchanged after establishing the first RSVP session; A third step of processing, by the GGSN, on behalf of the mobile host, a Refresh Path message transmitted to a first RSVP session set to the long_term state; A fourth step of changing the QoS information of the first RSVP session and changing the configuration of the first RSVP session when the QoS requirement of the first RSVP session is changed after the long_term state setting; And establishing a plurality of second RSVP sessions between the plurality of other CNs and the mobile host after setting the long_term state, generating a Unified_msg object including information of the first RSVP session and the second RSVP session and generating the first RSVP. And a fifth process of integrating a session and each refresh message transmitted to the second RSVP session and processing the same as one.

 Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings.

According to the present invention, the end-to-end RSVP message of the RSVP protocol is transmitted without modification, and reserves resources using a Tunneled RSVP mechanism between SGSN and GGSN. Each node in the core network must be able to understand Tunneled RSVP messages and manage reserved resources. In addition, the GGSN operates as a proxy server by applying the RSVP protocol according to the present invention to the third generation network, and separates the refresh domain between the third generation network and the external Internet zone and controls the RSVP refresh message. do.

1 shows a flowchart of a method for processing an RSVP protocol in a GGSN according to the present invention, and FIG. 2 is a flowchart of a message transmitted between each node of a third generation network according to the present invention. Hereinafter, the processing of the RSVP protocol and the transmission of messages according to it will be described with reference to the drawings.

First, when an RSVP Path message (M1) for configuring RSVP from CN (Correspondent Node) arrives at the GGSN (S110), the GGSN delivers the RSVP Path message (M1) directly to the mobile host.

At this time, the GGSN reserves the resources between the SGSN and the GGSN using the Tunneled RSVP mechanism. The GGSN also creates a GTP tunnel and assigns a GTP tunnel ID between the SGSN and the GGSN. The mobile host receiving the first RSVP Path message M1 transmits an Activate PDP context request message M2 to the SGSN. This process is terminated when the mobile host receives a confirmation (Confirmation) for the Activate PDP context request message (M2) from the GGSN via the SGSN (S120). The above procedure follows the same procedure as defined in 3G control phase behavior and all information is stored in the flow table. The mapping information to be maintained in SGSN and GGSN is GTP tunnel ID, Tunneled RSVP session, end-to-end RSVP session, and PDP context.

When the mobile host receives the Activate PDP Response message M3, the mobile host sends an RSVP Resv message M4 to the CN via SGSN. When SGSN receives this RSVP Resv message (M4), SGSN generates a Tunneled RSVP Resv message (M5) and transmits it to GGSN (S140).

When the end-to-end RSVP session is created (S140), and then two RSVP Refresh messages (M6 to M9) are successfully exchanged, the GGSN sets the session to the "long_term" state (S150). At this time, the "long_term" state means that the mobile host has a reliable path.

For flows classified as "long_term" state, the GGSN acts as a proxy RSVP server and subsequent RSVP Refresh Path messages are processed by the GGSN on behalf of the mobile host.

And every time GGSN receives a third Refresh Path message from CN, it triples the existing Time_value object of this Refresh Path message. This is to allow the GGSN to reduce the RSVP overhead inside the 3G network by making the GGSN and CN update cycles less frequent.

An important purpose of the RSVP Refresh message is to maintain the reliability of the RSVP routing path. Since RSVP is a proposed protocol for maintaining a reliable path in the Internet environment, multimedia applications cannot know when and where the routing path will be broken. For this reason, the RSVP protocol must periodically check routes using refresh messages. In contrast, location information of third generation networks is more reliable than the Internet environment. This is due to the fact that third generation networks have a separate hierarchical architecture and have short paths of three to five hops from the mobile host to the GGSN. In addition, 3G networks use G and I interface protocols as signaling protocols for mobility management and billing management. As a result, frequent refresh messages are not required in 3G networks.

On the other hand, when the PDP context is changed by the internal policy of the 3rd generation network and when the QoS environment of the external network is changed, the QoS requirement of the session is changed (S170). In this case, since the GGSN acts as a proxy server, the GGSN needs to perform an appropriate operation according to the QoS change. Accordingly, the GGSN modifies the QoS information of the flow table set in step S120 (S180).

If the PDP context is changed due to the internal policy of the 3rd generation network and the QoS environment is changed (S230), since the QoS change occurs in the 3rd generation network, the GGSN returns to the above-described step S140 and the updated RSVP message and the Modify_PDP_request message. By transmitting (S140) it should reflect the change in the current proxy RSVP session.

However, when the QoS environment is changed due to a change in the QoS flowspec of the external Internet, resource relocation must be performed in the third generation network. Therefore, the GGSN stops operating as a proxy server in the existing session, and returns to the above-described S120 process to forward the Tunneled RSVP message and the Modify_PDP_request message directly to the mobile host with the updated RSVP Refresh message.

When the CN and the mobile host continue to communicate by the above-described process, when the RSVP Path message M1 for RSVP configuration arrives at the GGSN for the same mobile host as the CN by another sender CN1 and CN2 (S110). No), GGSN adds two new Tunneled RSVP sessions (No in S130).

After a certain time, if these two new RSVP sessions are also set to the "long_term" state (Yes in S130), the GGSN first determines whether there is no change in the QoS of the current RSVP session (S160), and if there are no changes in the QoS, In operation S210, a Unified_msg including RSVP session information is generated. In the present invention, Unified_msg is a proposed object to reduce signaling overhead, and thus, GGSN simultaneously updates three RSVP sessions for CN, CN1, and CN2 with one refresh message including Unified_msg object (S220). This can reduce the update overhead of each session. 3 shows the format of a Unified_msg object.

On the other hand, if a change in QoS occurs during each RSVP session before generating Unified_msg for three RSVP sessions (Yes in S160), the GGSN modifies the QoS information of the flow table set in step S120 described above (S190). The Unified_msg is removed for the RSVP session (S200). Then, for the session whose QoS is changed, the path message is transmitted according to the QoS change factor in step S230 described above, and the path message including the Unified_msg object is transmitted as it is for the session for which the QoS is not changed (S220).

As described above, the present invention is to forcibly break the structure of the end-to-end QoS of the RSVP in the core network through the end-to-end flow QoS guarantee by reserving resources using the Tunneled RSVP mechanism between the SGSN and GGSN in the third generation network In this case, by integrating and transmitting multiple RSVP update messages along the same network path to one mobile host, the duplicated messages are not propagated, thereby preventing waste of bandwidth in the wireless network section.

1 is a flow diagram of a method for processing an RSVP protocol in a GGSN in accordance with the present invention.

2 is a diagram showing the application of the RSVP protocol according to the present invention to a third generation network.

3 is a structural diagram of a Unified_msg object format.

Claims (4)

In the method of operating the RSVP protocol in the GGSN of the third generation network, Transmitting a first Path message received from the CN to the mobile host and establishing a first RSVP session between the GGSN and the SGSN; A second step of setting the first RSVP session to a long_term state when a predetermined number of Refresh messages are exchanged after establishing the first RSVP session; A third step of processing, by the GGSN, on behalf of the mobile host, a Refresh Path message transmitted to a first RSVP session set to the long_term state; A fourth step of changing the QoS information of the first RSVP session and changing the configuration of the first RSVP session when the QoS requirement of the first RSVP session is changed after the long_term state setting; And If a plurality of second RSVP sessions are established between the plurality of other CNs and the mobile host after the long_term state is set, the first RSVP session is generated by generating a Unified_msg object including information of the first RSVP session and the second RSVP session. And a fifth process of integrating each refresh message transmitted to the second RSVP session and processing the same as one. The method of claim 1, The GGSN further includes a sixth step of tripleling an existing Time_value object of the Refresh Path message whenever the third Refresh Path message is received from the CN. The method of claim 1, In the first step, establishing the first RSVP session is to reserve a resource using a Tunneled RSVP mechanism. The method of claim 1, In the second process, when the two refresh messages are exchanged, the method of operating the RSVP protocol in a third generation network, wherein the first RSVP session is set to a long_term state.