KR100498966B1 - IP multimedia service method in Access Gateway - Google Patents

Abstract

The present invention provides a method for an IP multimedia service in a mobile communication system including an access gateway for transmitting packet data received from a source address to a destination address, when packet data is received from a source address. Analyzing a protocol form of the received packet data, checking whether the received packet data includes a reservation protocol according to the analyzed protocol, and if the reservation protocol is included, performing a procedure of a reservation protocol. And transmitting a reservation message to the source address, and transmitting the received packet data to a destination address when the reservation protocol is not included. Therefore, by adding a data processing algorithm according to the characteristics of the packet data provides a method for more efficient IP multimedia services by separating the packet data transmitted through the access gateway.

Description

IP multimedia service method in Access Gateway

The present invention relates to a mobile communication system, and more particularly, to a method for efficient IP multimedia service in an access gateway of a mobile communication system.

In general, the growth rate of data traffic in the mobile communication system is already ahead of the growth rate of voice traffic. In the concept of expansion, the operator operating the network considers network expansion for data traffic more than voice traffic, which is not increasing in the future, and in this process, many efforts to accommodate voice traffic in IP-based packet networks It has been going on. In addition, various methods and standards have been proposed for this purpose, and some services through the wired network are currently in progress. This can be inferred that voice networks will be absorbed and integrated into packet networks in the future, and this trend shift is also true for wireless services.

To this end, standard studies for wireless services consider the evolution of the network to operate all network components in the packet network in terms of network operation, and the concept of All-IP network has emerged. This concept aims to packetize all communication in stages, and considers that future voice service can be provided through packet network.

Synchronous Code Division Multiple Access (CDMA2000) system interoperates with packet network by packetizing time division multiplex (TDM) voice service currently provided through Mobile Switching Center (MSC) through a phased evolution process. It suggests a way to do it. In the future, the All-IP network aims to provide packetized voice services through an Access Gateway (AGW) which mainly focuses on packet transmission.

However, in the case of wireless service, bandwidth efficiency is also important as compared to wired service. As a method for this, various algorithms for compressing packetized voice and various methods for delivery over wireless are proposed. Compression algorithms expected to be adopted as a standard in 3rd Generation Partnership Project 2 (3GPP2) include Robust Header Compression (ROHC), Line Layer Assisted Robust Header Compression (LLAROHC), and Van Jacobson header compression methods. Since these methods are compression schemes between the access gateway and the terminal, there is a need to propose a new method for negotiating a compression method between the terminal and the access gateway and for efficient transmission of compressed packet data.

Accordingly, an object of the present invention is to add a data processing algorithm according to the characteristics of packet data in a CDMA2000 access gateway to provide a method for more efficient IP multimedia service by classifying packet data transmitted through the access gateway.

Another object of the present invention is to identify a message for a service instance and a quality of service (QoS) through an access gateway, and to provide a wireless service environment and a compression algorithm accordingly.

The method for achieving the object of the present invention, in the mobile communication system including an access gateway for transmitting the packet data received from the source address to the destination address, a method for IP multimedia service at the access gateway, the source address When the packet data is received from the process of analyzing the protocol type of the received packet data, and confirming whether the received protocol includes a reservation protocol in accordance with the analyzed protocol, and the reservation protocol And if the reservation protocol is not included, transmitting the reservation message to the source address by performing a procedure of a reservation protocol, and transmitting the received packet data to a destination address if the reservation protocol is not included.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings. First of all, in adding reference numerals to the components of each drawing, it should be noted that the same reference numerals have the same reference numerals as much as possible even if displayed on different drawings.

In addition, in the following description, many specific details such as specific signals and messages are shown, which are provided to help a more general understanding of the present invention, and it is understood that the present invention may be practiced without these specific details. It will be self-evident to those of ordinary knowledge. In the following description of the present invention, if it is determined that a detailed description of a related known function or configuration may unnecessarily obscure the subject matter of the present invention, the detailed description thereof will be omitted.

The network components when a current IP multimedia service including a Voice over IP (VoIP) service is provided through a Code Division Multiple Access 2000 (CDMA2000) network will be described below.

1 is a block diagram showing a CDMA2000 network configuration.

The CDMA2000 network 100 includes a wireless network unit 110 including a terminal 111 and a base station controller 112, a switching network unit 120, and a public switched telepone network (PSTN) 130.

The switching network unit 120 includes an access gateway (AGW) 121, an authentication unit (AAA: Authentication, Authorization and Accounting) 122, a communication node (CN: Correspond Node) 123, and a media gateway (MGW). 124, a Home Agent (HA) 125, and the like are connected to the IP network 125. The base station controller 112 is connected to the IP network 126 through the access gateway 200. The public telephone network 130 is connected to the IP network 126 through the media gateway 124.

2 is a diagram illustrating a VoIP service and IP multimedia service processing procedure through the network of FIG. 1.

Referring to FIG. 2, in order to start a service, the mobile station 111 includes a base station controller (BSC / PCF: Base Station) including a desired service option (Service Option 33) in a message for call setup in step 200. The controller requests a call setup to the controller / packet control function 112 and sets a wireless channel between the terminal 111 and the base station controller (BSC) 112. In step 210, the base station controller (BSC / PCF) 112 establishes a radio protocol (RP) session for connection between the access gateway 121 and the base station controller 112.

In step 220, the access gateway 121 and the terminal 111 establish a PPP (Point-to-Point) session through the established wireless channel and the RP session. At this time, the IP address to be used by the terminal 111 and other necessary options (Timer, compression method, etc.) are negotiated with each other.

Then, in step 230, the access gate 102 requests subscriber authentication for the terminal to the authenticator 122 during the PPP setup process or after the PPP setup is completed. When the authentication is confirmed in step 240, the exsex gateway 121 receives the subscriber profile from the authenticator 122 and manages the profile.

In step 250, the terminal 111 performs signal processing based on a session initiation protocol (SIP) for the IP multimedia service with the communication node 123. At this time, a session is established between the terminal 111 and the communication node 123, and substantial voice packets or IP multimedia packets are transmitted through the established session.

 However, packet voice or IP multimedia packet data provided through such session establishment will incur a lot of Real Time Protocol / User Datagram Protocol / Internet Protocol (RTP / UDP / IP) overhead if the communication node does not provide compression. In the case of real-time data, transmission may be performed without considering radio characteristics, such as retransmission at the RLP layer of the terminal and the base station control period. In addition, due to the lack of efficient wireless use, it does not have a special advantage over the conventional TDMA scheme, but rather decreases the wireless efficiency within the same cell radius, so that the number of subscribers that can be accommodated may be smaller.

 As a solution to this, 3GPP2 (3rd Generation Partnership Project 2) proposes three service instances (SIs) as a method for efficient transmission in a wireless section according to packet characteristics. The service instances consider transmission in the radio section according to the characteristics of the packet data.

The first service instance (SI-Type 1) is a service instance suitable for FTP (File Transfer Protocol), E-mail, Streaming Text, Web Browsing, etc., and it is a structure capable of RLP retransmission in data and wireless intervals requiring relatively low transmission speed. . It is also a service instance that can be set by service option 33 that is currently implemented.

The second service instance (SI-Type 2) is a service instance for VoIP service that meets the wireless characteristics and does not perform HDLC framing at the access gateway, and radio link protocol framing (RLP) in the radio section. no framing). In terms of wireless characteristics, it is similar to the case of providing voice service in a service through a current switching system (MSC).

The third service instance (SI-Type 3) is classified as a service instance for multimedia packet communication such as "Streaming Audio and video", and requires a relatively high speed packet transmission and provides real-time characteristics.

 In order to use the above service instances, messages that can be exchanged between the terminal and the access gateway are required. However, the role of the existing access gateway manages the established session, provides packetized data to the terminal through PPP encryption, and decapsulates PPP packet data from the terminal to the Correspond Node (CN). Forwarding, no search capability is provided for higher protocols beyond the network layer. The following processing procedure to solve this problem will be described with reference to the drawings.

The received packet format may be set in the order of PPP, IP, UDP / TCP, and may be set to another type of protocol in the IP upper layer. The process to be described later describes the process of analyzing the upper protocol User Datagram Protocol (UDP), Generic Routing Encapsulation (GRE), and IP, and the ports of the protocols are defined in the standard in the 3rd Generation Partnership Project 2 (3GPP2). It should be noted.

3 is a flowchart illustrating a processing procedure of separating packet data for each protocol type for an IP multimedia service according to an embodiment of the present invention.

Referring to FIG. 3, when the packet data is received in step 300, the access gateway 121 analyzes a protocol type (hereinafter, referred to as "PT") of the packet data. In the separation operation, when the PT is UDP in step 310, the UDP packet processing is performed in step 410. On the other hand, if it is not UDP, the PT checks whether the PT is GRE, and if the GRE packet is performed in step 420, the GRE processing operation is performed. In the case of the IP-in-IP, the IP-in-IP processing is performed in step 430. Otherwise, the packet is transmitted to the corresponding destination address, and then the operation is terminated. In addition, the processing procedure is terminated after performing each of the processing steps 410, 420, and 430.

4 is a flowchart illustrating a processing procedure when the protocol type is UDP in the operation of FIG. 3.

3 and 4, the access gateway 121 analyzes the UDP port of the received packet when the PT is UDP in step 310. In this case, when the UDP port number is 699 in step 411, the controller determines that the message is a message for establishing a new RP session on the RP interface (hereinafter referred to as an “A11 message”) in step 512 and performs a corresponding processing procedure. On the other hand, if not, the access gateway 121 checks whether the UDP port is 1812 in step 413. In this case, if the UDP port matches 1812, the authentication process is performed in step 414. Otherwise, in step 415, it is checked whether UDP is 1813. In this case, the charging process is performed in step 416. On the other hand, if it is not, the RSVP process is checked in step 417 and the RSVP process is performed in step 418. At this time, if UDP is not RSVP, the received packet is transmitted to the corresponding address, that is, the terminal 111, and then the operation is terminated. In addition, after performing each processing in steps 412, 414, 416, and 418, the processing procedure ends.

5 is a flowchart illustrating a processing procedure when the protocol type is GRE in the operation of FIG. 3.

3 and 5, the access gateway 121 performs an operation for processing a received packet when the PT is GRE in step 320. In this case, if a packet in which PT is determined to be a GRE is received in step 421, it is determined that the session has already been established and received through RP tunneling, and the session is found using a GRE key. Then, the access gateway 121 extracts the IP data through PPP processing in step 522 and checks whether the PT of the corresponding IP packet is a UDP port. In this case, if the UDP port number is 434 in step 423, the operation ends after the mobile IP processing procedure is performed in step 424. On the other hand, if not, in step 425, it is checked whether the RSVP protocol is used. In this case, the RSVP protocol is terminated after performing the RSVP processing procedure in step 426. Otherwise, it is determined as general data in step 427, and transmits a packet to the corresponding address, that is, the terminal 111, and ends the processing procedure. .

FIG. 6 is a flowchart illustrating a processing procedure when the protocol type is IP_in_IP in the operation of FIG. 3.

3 and 6, when the PT of the received packet is IP-in-IP in step 330, the access gateway 121 performs an operation for processing the received packet. At this time, the access gateway 121 determines the IP-in-IP packet as data received from the home agent (HA) 125. Then, in step 431, IP-in-IP decoding is performed, and in step 432, a preset session is found. Accordingly, the access gateway 121 checks whether the protocol of the packet decoded in step 433 is the RSVP protocol. In this case, the RSVP is determined to be an RSVP using a mobile IP from the home agent 125, and the RSVP processing is terminated after the RSVP processing procedure is performed in step 434. On the other hand, in step 435, the received packet is transmitted to the corresponding address, that is, the terminal 111, and then the processing is terminated.

When performing the RSVP processing procedure in the procedure of Figures 3 to 6 will be described with reference to the drawings.

7A and 7B are flowcharts illustrating a processing procedure in case of RSVP in the operations of FIGS. 4 to 6.

Referring to FIGS. 4 to 5 and FIGS. 7A and 7B, as a result of analyzing each of the analyzed upper protocols (UDP, GRE, and IP-in-IP) in steps 418, 426, and 434, RSVP is analyzed. If it is determined that is included in the processing procedure checks what type of message RSVP message is carried out according to each message type. First, in step 500, the access gateway 121 determines whether the RSVP message is a path message (RSVP Path Massge). In the case of the route message, the packet is transmitted to the corresponding destination address, that is, the terminal 111 in step 505. On the other hand, if it is not a route message, in step 510 it is checked whether the RSVP reservation message (RSVP Resv Message). As a result of the check, in the case of the reservation message, the reservation message is authenticated in step 511, and then in step 512, the authentication is confirmed. In this case, if authentication fails, in step 513, authentication response messages (Path Tear and Resv Tear) are transmitted to the corresponding address in response to the authentication, and then the processing procedure is terminated. The Path Tear message is transmitted to the terminal 111 and the Resv Tear message is transmitted to the communication node 123.

On the other hand, if authentication is successful, a flow treatment function for determining a service instance is performed through a flow spec in step 513. In this case, for example, if the desired voice codec is a CDMA2000 voice codec, in step 511, if the CDMA2000 voice codec is a second service instance corresponding to a service instance for a VoIP service conforming to a wireless characteristic, SI-Type 2) is set, and a new call setup is requested to the base station controller 112 to set the corresponding radio channel. On the other hand, if it is not the desired codec, the access gateway 121 considers the IP multimedia data and requests a new call setup to the base station controller 112 to set the third service instance (SI-Type 3). In response to the new call establishment request, when the RP session between the base station controller 112 and the terminal 112 and the RP session between the base station controller 112 and the access gateway 121 are completed, the access gateway 121 flows in step 518. Manage the resources through mapping. Thereafter, in step 519, the packet including the reservation message (Resv Message) is transmitted to the destination address of the message, that is, the terminal 111, and the processing is terminated. Thereafter, VoIP data and IP multimedia data coming through the established session are transmitted to each other through the mapped service instance and the wireless channel.

On the other hand, if the message is not a reservation message in step 510, the ResvConf message in step 520, a PathErr message in step 530, and a reservation error (ResvErr) in step 540. In the case of the message, the packet including the message is transmitted to the destination, that is, the terminal 111, and the processing procedure is terminated.

The above procedure has been described with reference to FIGS. 3 to 7 when the resource reservation fails when performing the resource reservation processing procedure using the standard RSVP protocol. Same as

8 is a diagram illustrating a processing procedure when resource reservation is successful according to a standard RSVP protocol in an access gateway according to an embodiment of the present invention.

Referring to FIG. 8, in step 610, the communication node 123 communicating with the terminal 111 communicates with a path message of the resource reservation protocol during SIP signaling (eg, 183 Session Progress). RSVP Path Message) is transmitted to the terminal 111 through the access gateway 121. At this time, the access gateway 121 detects the path message, performs necessary RSVP processing, and loads data in the PPP frame to the terminal 111. Then, the terminal 111 calculates a quality of service (QoS) parameter (Delay and Bandwidth, etc.) required by the corresponding node 123 through the received RSVP Path message, and the terminal 111 accepts it. Resource reservation protocol (RSVP Resv Message), which includes the Flow Spec and Filter Spec, for resource reservation A path message (RSVP Path Message) is a source address, a receive path that is, transmitted to the communication node 123.

The access gateway 121 detects the reservation message through the processing procedures of FIGS. 7A and 7B described above in operation 630, and then, based on the load of the access gateway 121, an internal policy of the access gateway 121, and an authorization function based on the subscriber profile in operation 640. Do this. In case of passing the authorization function, if a new call connection (A10) is required for the IP multimedia service including the VoIP service, the base station is transmitted through a message requesting call setup (hereinafter, referred to as an all-RUP / RACK message) in step 640. Requires controller 112 to make a new call. Then, in step 650, the base station controller 112 requests the call setup from the terminal 111 through the service option requested by the access gateway 121 in the A11-RUP / RACK message to set up a wireless channel. Then, in step 660, a call connection is attempted with the access gateway 121 to establish a new RP session corresponding thereto.

When the call setup is completed, in step 670, the access gateway 121 performs flow mapping according to the above-described method of FIGS. 7A and 7B. After the flow mapping is completed, the access gateway 121 transmits a reservation message of the resource reservation protocol to the destination address, that is, the terminal 111 in step 680.

On the other hand, the reverse direction is also set by the same processing procedure and the terminal 111 and the communication node 123 through the above processing procedure to complete the setting to exchange the VoIP data and IP multimedia data with each other.

Meanwhile, in the detailed description of the present invention, specific embodiments have been described, but various modifications are possible without departing from the scope of the present invention. Therefore, the scope of the present invention should not be limited to the described embodiments, but should be defined not only by the scope of the following claims, but also by the equivalents of the claims.

As described above, the present invention can provide the IP multimedia service including the VoIP service by processing the packet data in the access gateway more efficiently, thereby providing a header compression method that reduces a lot of overhead and utilizing radio resources according to the characteristics of the packet data. There is an effect that can be different.

1 is a block diagram showing a network configuration of a CDMA200 system;

2 is a diagram illustrating a VoIP service and IP multimedia service processing procedure through the network of FIG. 1;

3 is a flowchart illustrating a processing procedure for an IP multimedia service according to an embodiment of the present invention;

4 is a flowchart illustrating a processing procedure when the protocol type is UDP in the operation of FIG. 3;

5 is a flowchart illustrating a processing procedure when the protocol type is GRE in the operation of FIG. 3;

6 is a flowchart illustrating a processing procedure when the protocol type is IP_in_IP in the operation of FIG. 3;

7A and 7B are flowcharts showing a processing procedure in case of RSVP in the operations of Figs. 4 to 6;

8 is a diagram illustrating a processing procedure when resource reservation is successful according to a standard RSVP protocol in an access gateway according to an embodiment of the present invention.

Claims (10)

delete delete delete delete In the mobile communication system comprising an access gateway for transmitting the packet data received from the source address to the destination address, the method for providing IP multimedia service at the access gateway, Receiving packet data from the source address; Determining a protocol type of the received packet data; Processing the received packet data according to the determined protocol type; And transmitting the packet data to the destination address when the determined protocol type does not belong to a preset protocol type. The method of claim 5, The preset protocol type may include UDP, GRE, and IP-in-IP. The method of claim 6, If the determined protocol type is UDP, the access gateway examines the UDP port of the received packet data, performs a processing procedure corresponding to the UDP port value, and determines whether the protocol is a reserved protocol. Way. The method of claim 6, And if the determined protocol type is GRE, the access gateway determines that the received packet data is data received through RP tunneling, performs PPP processing, and determines whether the reserved protocol is a reserved protocol. The method of claim 6, When the determined protocol type is IP-in-IP, the access gateway determines that the received packet data is data received from a home agent, performs IP-in-IP decoding, and determines whether the protocol includes a reservation protocol. Characterized in that the method. The method according to any one of claims 7 to 9, And if the packet data includes a reservation protocol, perform a reservation protocol procedure according to a service instance.