KR20060009433A - Method for packet service in a mobile communication using a header compression - Google Patents

Abstract

The present invention provides a method and apparatus for compressing a header of a packet in a mobile communication system, the terminal transmitting a call setup request message including a header compression request parameter to the SGSN, and SGSN responds to the call setup request message. Determining first header compression parameters for use with an RNC, and then transmitting the first header compression parameters to the RNC, and the SGSN uses with a GGSN in response to the call setup request message. Determining second header compression parameters for the second header compression parameters, and transmitting the second header compression parameters to the GGSN, and using the first and second header compression parameters between the RNC and the SGSN and between the SGSN and the GGSN. Performing a header compression and header restoration on the packets according to the packet service As reducing the size of the header lowers the overhead, it is possible to improve the efficiency of communication.

VoIP, GGSN, SGSN, IP / UDP / RTP, GTP, INNER HEADER, OUTER HEADER

Description

Packet service method using header compression in mobile communication system {METHOD FOR PACKET SERVICE IN A MOBILE COMMUNICATION USING A HEADER COMPRESSION}             

1 is a simplified diagram of a system architecture for performing a typical VoIP service.

2 is a diagram illustrating in detail a protocol stack for VoIP packet transmission in a conventional UMTS network core network.

3 is a diagram illustrating in detail a situation in which VoIP packets are transmitted in a UMTS network core network according to an embodiment of the present invention.

4 is a diagram illustrating the structure of GGSN and SGSN in a Gn interface according to an embodiment of the present invention.

5 is a diagram illustrating the structure of the SGSN and RNC in the lu interface in accordance with an embodiment of the present invention.

6 is a flowchart illustrating a procedure of exchanging header compression parameters according to an embodiment of the present invention.

One drawing.

FIG. 7 illustrates operation of SGSN on an lu interface according to an embodiment of the present invention. FIG.                 

8 illustrates the operation of an RNC on an lu interface in accordance with an embodiment of the present invention.

9 illustrates the operation of an SGSN on a Gn interface according to an embodiment of the present invention.

10 is a diagram illustrating operation of a GGSN on a Gn interface according to an embodiment of the present invention.

11 is a diagram illustrating in detail a situation in which VoIP packets are transmitted in a UMTS network core network according to a second embodiment of the present invention.

12 is a diagram illustrating the structure of GGSN, SGSN, and RNC on a Gn interface and a lu interface according to a second embodiment of the present invention.

13 is a diagram illustrating a process of exchanging control signals according to a second embodiment of the present invention.

TECHNICAL FIELD The present invention relates to packet services in a mobile communication system, and more particularly, to header compression between a core network consisting of a Serving GPRS Support Node (SGSN) and a Gateway GPRS Support Node (GGSN) in a Universal Mobile Telecommunications System (UMTS) network. .                         

In the 3rd Generation Partnership Project (3GPP), which is responsible for standardizing the UMTS communication system, a method of supporting voice over Internet protocol (hereinafter referred to as "VoIP") communication is being discussed. VoIP refers to a communication technique that forms a voice frame generated by a voice coder (codec) into an IP (Internet Protocol) packet and delivers it to a receiver through the Internet to enable voice service.

Hereinafter, with reference to the accompanying drawings will be described in detail.

1 is a diagram schematically illustrating a system structure for performing a typical VoIP service.

The terminal 100 is an AMR (Adaptive Multi-Rate) codec that transforms a human voice into a voice frame, and an IP / UDP / that makes the voice frame into an IP / UDP (User Datagram Protocol) / RTP (Real Time Protocol) packet. Packet Data Convergence Protocol (PDCP) / Radio Link Control (RLC) / Medium Access Control (MAC) / PHY (Physical) Protocol to convert RTP protocol stack and IP / UDP / RTP packets into radio frames for transmission over a wireless channel. It is provided.

The data transmitted by the terminal 100 is transferred to the Radio Network Control (RNC) 130 via the Node B 120, and the RNC 130 converts the data into original IP / UDP / RTP packets to form a core network. And the IP / UDP / RTP packet is transmitted to the other party's caller 180 via the IP network 170.                         

Voice data of the other party's caller 180 is transmitted to the terminal 100 in the reverse order.

The voice data generated by the codec of the terminal 100 becomes a VoIP packet via the IP / UDP / RTP protocol stack. The RLC PDU (or Transport Block: after the RLC PDU has been processed in the physical layer is called a transport block) is channel decoded in the Node B physical layer and then transmitted to the RNC 130. The RNC reconstructs the RLC PDUs back into VoIP packets and sends them to the core network. In addition, VoIP packets are transmitted between the RNC 130 and the core network 150 and inside the core network 150 through a GTP tunnel. The core network consists of SGSN and GGSN, and delivers VoIP packets to the other party through the IP network or PSTN. Forward data transfer proceeds in the reverse order.

A Packet Data Convergence Protocol (PDCP) layer compresses the header of the VOIP packet, and an RLC layer converts the packet transmitted from the PDCP layer into a form suitable for transmission over a wireless channel. The RLC layer is classified into an unacknowledged mode (UM), an acknowledged mode (AM), and a transparent mode (TM) according to an operation method. VoIP operates in RLC UM mode, and the operation of RLC UM is as follows.

The RLC UM entity on the transmitting side divides, concatenates, or pads an RLC Service Data Unit (“SUD”), which is data transmitted from a higher layer, into a size suitable for transmission over a wireless channel, and divides it. RLC protocol data unit (hereinafter referred to as “PDU”) is created by inserting information about serial / concatenation / padding and serial number, and delivers this RLC PDU to lower layer. Interpret serial number and split / concatenation / padding information of RLC PDU delivered from layer, and reconstruct RLC SDU and deliver to upper layer.

As seen above, the VoIP packet is transmitted with the header compressed between the terminal 100 and the RNC 130, but the header is not compressed between the RNC 130 and the core network 150 or within the core network 150. Is sent in the state.

2 is a diagram illustrating in detail a protocol stack for VoIP packet transmission in a conventional UMTS network core network.

The UMTS network consists of the UE 205, the RNC 210, the SGSN 215, and the GGSN 220. The UE 205 means a user terminal, and the RNC 210 manages transmission resources of a radio access network, manages cell mobility of terminals, and the like. The SGSN 215 manages a transmission resource of an Iu interface, which is an interface between the RNC 210 and the SGSN 215, manages mobility of a terminal in a wider area than a cell, and manages authentication information of the terminal. do. The GGSN 220 manages the transmission resources of the Gn interface, which is an interface between the SGSN 215 and the GGSN 220, and supports interworking with the external network. VoIP packets are transmitted through the GPRS tunneling protocol (GPRS Tunneling Protocol) in the Iu interface and the Gn interface, and the GTP tunnel is connected between nodes located at both ends of the tunnel. A logical connection that is established at, which is identified by the Tunnel End Point ID (hereinafter referred to as “TEID.”) In the GTP tunnel, a Quality of Service (QoS) is guaranteed, so separate services are available for services with different QoS. GTP tunnels are configured.

In a UMTS network, VoIP packets are transmitted from the GGSN 220 to the SGSN 215 via the GTP tunnel to the RNC 210 and from the RNC 210 via the SGSN 215 to the GGSN 220. The structure of the VoIP packet is shown in FIG.

For example, the process of transmitting the VoIP packet from the UE to the GGSN 220 in the reverse direction will be described below.

AMR data generated in the AMR codec of the UE 505 is made into VoIP packets in the form of IP header + UDP header + RTP header + AMR data via the IP / UDP / RTP protocol stack. The VoIP packet is compressed in a header in the PDCP layer, and the compressed packet is transmitted over a radio channel through a radio protocol stack composed of RLC / MAC / PHY.

Here, the PDCP layer compresses the header using the ROHC (Robust Header compression) protocol, and when using the ROHC protocol, an IP / UDP / RTP header of about 60 bytes is compressed into an ROHC header of about 2 bytes. Therefore, the VoIP packet transmitted from the UE 205 to the RNC 210 is the same as that of the reference numeral 225.

The packet 225 has a form in which an RLC header, a PDCP header, and an ROHC header are added to AMR data. If the PDCP header is assumed to be 0 bytes, the overhead size is about 3 bytes. The size of the AMR data varies depending on whether the AMR data is Silence Description (SID) or actual voice data. The size of the AMR data is 7 bytes for the silence section information and 32 bytes for the actual voice data. Therefore, the total size of 225 would be 10 bytes or 35 bytes.

The VoIP packet 225 is restored to the original IP header + UDP header + RTP header + AMR data form through the radio protocol stack and PDCP stack of the RNC 510.

The recovered packet is delivered to the GTP-U (User) protocol stack 240 for transmission over the lu interface at the RNC 210. The GTP-U protocol stack 240 adds a GTP-U header to the VoIP packet. The GTP-U header stores information such as a TEID. Packets from the GTP-U protocol stack 240 are delivered to SGSN 215 via the IP / UDP protocol stack and the L1 / L2 stack. The IP / UDP protocol stack is for routing between the RNC 210 and the SGSN 215 and serves as a transport layer of a GTP tunnel.

Therefore, the structure of the VoIP packet in the Iu interface is shown as 230. As shown in 230, headers added to the VoIP packet in the lu interface include IP header, UDP header, GTP-U header, IP header, UDP header, There is an RTP header, which totals up to 96 bytes. Considering that AMR data is only 7 bytes or 32 bytes, this amount of overhead can be considered very large. The same is true for the VOIP packet 235 of the Gn interface transmitted to the GSSN 520 via the GTP tunnel.

In the prior art VoIP packet transmission operating as described above, an overhead of about 96 bytes is added to the VoIP packet in the Iu interface and the Gn interface. If the VoIP packet is divided into an inner header 245 and an outer header 240 based on the GTP header, the outer header 240 may include the GGSN 220, the SGSN 215, and the RNC 210. Since the node directly processes, the nodes may take an action to reduce the outer header 240. For example, there may be a method of transmitting one outer header 240 and several VoIP packets together or a method of compressing an IP / UDP header of the outer header 240. However, since the inner header 245 is transparent to the GGSN 220, the SGSN 215, and the RNC 210, the inner header 245 cannot be applied to the inner header 245. Considering that greater than 240, a technique for reducing the waste of system resources due to the inner header 245 is essential.

Accordingly, an object of the present invention, which was devised to solve the problems of the prior art operating as described above, is to provide a method and apparatus for compressing a header of a VoIP packet in a mobile communication system.

Another object of the present invention is to provide a method and apparatus for increasing communication efficiency by compressing and transmitting a header of a VOIP packet between an RNC and a core network or within a core network.

It is still another object of the present invention to provide a method and apparatus for compressing or restoring headers of packets corresponding to a packet service by configuring a header compressor and a header decompressor on top of a GTP tunnel of an RNC, SGSN, and GGSN. .

In accordance with an aspect of the present invention, a terminal transmits a call setup request message including a header compression request parameter to the SGSN, and the SGSN is connected to the call setup request message. In response to determining first header compression parameters for use with the RNC, transmitting the first header compression parameters to the RNC, and the SGSN communicates with the GGSN in response to the call setup request message. Determining second header compression parameters for use in the step of transmitting the second header compression parameters to the GGSN, and compressing the first and second headers between the RNC and the SGSN and between the SGSN and the GGSN. Performing header compression and header restoration on packets according to the packet service using parameters. To provide.

According to another embodiment of the present invention, the UE transmits a call setup request message including a header compression request parameter to the SGSN, and the SGSN responds to the call setup request message between the RNC and the GGSN. Determining header compression parameters for use, transmitting, by the SGSN, the header compression parameters to the RNC and the GGSN;

It is to provide a process for performing header compression and header recovery for the packets according to the packet service using the compression parameters between the RNC and the GGSN.

Hereinafter, the operating principle of the present invention will be described in detail with reference to the accompanying drawings. In the following description of the present invention, if it is determined that a detailed description of a known function or configuration may unnecessarily flow the gist of the present invention, the detailed description thereof will be omitted. Terms to be described later are terms defined in consideration of functions in the present invention, and may be changed according to intentions or customs of users or operators. Therefore, the definition should be made based on the contents throughout the specification.

The present invention proposes a method for header compression and decompression by the GGSN, SGSN, RNC, etc. for the inner header of the VoIP packet, thereby reducing the size of the inner header added to the VoIP packet by 60 to 1 to 2 bytes. To be.

3 is a diagram illustrating in detail a situation in which VoIP packets are transmitted in a UMTS network core network according to an embodiment of the present invention.

In FIG. 3, the header processing apparatus is provided in the Gn interface and the Iu interface, thereby reducing the size of the IP / UDP / RTP header, which is an inner header of the VoIP packet. For example, ROHC (Robust Header Compression) may be used as a header compression protocol that may be included in the header processing apparatus. ROHC is a header compression protocol defined in RFC 3095. It can perform header compression and decompression operations for various combinations of protocols, and in particular compresses the size of a 60-byte IP / UDP / RTP header to a few bytes. do. Since ROHC is the header compression protocol most widely used in 3GPP and operates most efficiently for VoIP packets, it will be described assuming that the header compressor is equipped with ROHC.

The GGSN 320 is provided with a header processing device 323 for the Gn interface above the GTP-U protocol 324, and the header processing device 323 provides a header of an IP / UDP / RTP packet transmitted from an external network. It compresses and delivers the packet to the GTP tunnel or restores the packet received through the GTP tunnel to IP / UDP / RTP packet and routes it to the external network.

The SGSN 315 is provided with a header processing unit 319 for the Gn interface above the GTP-U protocol 318, and a header processing unit 317 for the Iu interface is provided above the GTP-U protocol 316. .

The header processing unit 319 of the Gn interface restores the header of the packet received from the GGSN 320 to the header processing unit 317 or compresses the header of the packet received from the header processing unit 317 to GTP. Transmit to GGSN 320 via a tunnel.

The header processing unit 317 of the lu interface restores the header of the packet received from the RNC 310 to the header processing unit 319, or compresses the header of the packet received from the header processing unit 319. Transmit to RNC 310 via GTP tunnel.

The RNC 310 includes a header processing unit 313 on top of the GTP-U protocol 314. The header processing apparatus 313 restores the header of the packet received from the SGSN 315 to the PDCP layer or compresses the header of the packet received from the PDCP layer to the SGSN 315 through the GTP tunnel.

In this way, the header processing device located above the GTP protocol in the Iu interface and the Gn interface compresses the header of the packet before transmitting the packet through the GTP tunnel. Therefore, the inner header size is reduced from the previous 60 bytes to about 2 bytes on average. The structure of the VoIP packet in the Iu interface and the Gn interface is as shown by reference numeral 330.

In the UMTS network, one PDP context is configured for one packet service, one bearer is configured for one PDP (Packet Data Protocol, hereinafter referred to as “PDP”) context, and one bearer is configured. For both forward and reverse GTP tunnels are established.

A PDP context is a place where QoS information of a packet service, IP address of a UE, GTP tunnel related information, etc. are stored. The PDP context is present in the terminal, SGSN 215 and GGSN 220, and must be established before the packet call is serviced. For example, QoS information and TEID, which are identifiers of the forward and reverse GTP tunnels, are defined in the PDP context. When the PDP context is configured, the associated GTP tunnel is configured together. A GTP tunnel is a transport bearer used within the core network of UMTS that uses GTP-U / UDP / IP. The UDP and IP headers include IP addresses of tunnel endpoints and UDP port numbers corresponding to GTP-U. In the GTP-U header, a TEID, which is an identifier of a tunnel, is inserted. GTP tunnels are also bearers that guarantee the QoS described in the PDP context.                     

The structure of GGSN, SGSN and RNC in Gn interface and Iu interface will be described in more detail with reference to FIG. 4.

4 is a diagram illustrating the structure of GGSN and SGSN in a Gn interface according to an embodiment of the present invention.

The GGSN 405 forwards the IP packets 403 coming from the external network to the appropriate GTP tunnels 440 and 420, and routes the packets received through the GTP tunnels 470 and 485 to the external network. Perform reverse operation.

The header compressor 415 and the header decompressor 475 at the endpoints of the GTP tunnels 420 and 470 for the VoIP service of the GGSN 405 can be applied to bearers of services requiring header compression such as VoIP. It is provided.

The forward operation on the Gn interface is shown below.

The GGSN 405 transfers the IP packet 403 received from the external network to a traffic flow template (hereinafter referred to as “TFT”) 410. The TFT 410 serves to deliver the IP packets 403 to an appropriate bearer based on preset criteria. The criterion may be for example a source IP address, a destination IP address, a source UDP port number, a destination UDP port number, etc. The parameters always have a constant value for a particular service. For example, in the VoIP service, the IP address of the sending side and the receiving side is always constant, and the source port number and the destination port number are always constant.

The TFT 410 examines the IP packet 403 according to the criterion, and if the IP packet 403 is a VoIP packet, forwards the VoIP packet to a bearer 495 for VoIP service. Since the first device configured in the bearer 495 is a header compressor 415, the VoIP packet is eventually delivered to the header compressor 415. The header compressor 415 compresses the IP / UDP / RTP header of the received VOIP packet and transmits it to the SGSN 450 through the DL (Downlink) GTP tunnel 420 of the Gn interface. The DL GTP tunnel 420 is a bearer composed of GTP-U / UDP / IP / L2 / L1 and is connected to the SGSN 450. The transmission of the packet to the SGSN through the DL GTP tunnel by the header compressor 415 means that the header compressor 415 forwards the packet to the GTP-U protocol entity (not shown) of the GGSN 405. . The GTP-U protocol entity adds an appropriate TEID to the packet and then transmits the packet to the corresponding GTP-U protocol entity (not shown) of SGSN 450 using IP / UDP / L2 / L1. SGSN 450 delivers the compressed packet received through GTP tunnel 420 to header decompressor 425. The header decompressor 425 restores the header of the compressed packet, converts the header of the compressed packet into an original VoIP packet, and delivers the original VoIP packet to the header compressor 430. The header compressor 730 compresses the header of the VoIP packet and transmits the header to the RNC through the DL GTP tunnel 435 of the Iu interface.

The reverse operation on the Gn interface is as follows.

The compressed packet arriving at the SGSN 450 through the UL GTP tunnel 455 of the Iu interface is in a state in which the IP / UDP / RTP header is compressed by the header processing apparatus of the RNC, and the compressed packet is the header decompressor 460. Is delivered. The header decompressor 460 restores the IP / UDP / RTP header of the compressed packet to the header compressor 465, and the header compressor 465 recompresses the header of the received packet. It passes through the UL GTP tunnel 470 of the Gn interface to the GGSN 405. The compressed packet is delivered to the header decompressor 475 of the GGSN through the UL GTP tunnel 470, and the header decompressor 475 restores the header of the received packet to the original VoIP packet. The data is transmitted to the IP routing function 480. The IP routing function 480 refers to the destination IP address of the received VoIP packet and routes the VoIP packet to an external network.

For reference, bearers configured for other services that do not need to compress headers include DL GTP tunnel 440 and UL GTP tunnel 485 on Gn interface and DL GTP tunnel 445 and UL GTP tunnel 490 on Iu interface. It consists only.

5 is a diagram illustrating the structure of the SGSN and RNC in the lu interface according to an embodiment of the present invention.

Here, the same reference numerals are used for the same entities as in FIG. 4. The SGSN 450 connects the packets received from the GTP tunnels 440 and 420 of the Gn interface to the GTP tunnels 445 and 435 of the Iu interface, and the packets received from the GTP tunnels 455 and 490 of the Iu interface. To the GTP tunnels 470 and 490 of the Gn interface. The connection between the GTP tunnels 445, 435, 525, 535 of the lu interface and the GTP tunnels 440, 420, 470, 490 of the Gn interface is established at the stage where the PDP context is established.                     

Packets received by the RNC 505 through the GTP tunnels 445, 435 of the lu interface are forwarded to the appropriate PDCP entities 530, 525, 535 and packets received from the PDCP entities 530, 525, 535 are appropriate. It is connected by a GTP tunnel. The PDCP entities 530, 525, and 535 compress or restore the header of the IP packet, thereby reducing the overhead added to the IP packet between the RNC 505 and the terminal.

A header processing device is provided at the end points of the GTP tunnels 435 and 455 for the Voip service between the RNC 505 and the SGSN 450. This is to reduce the overhead added to VoIP packets on the Iu interface.

To this end, the RNC is equipped with a header restorer 515 between the forward GTP tunnel 435 of the Iu interface and the PDCP entity 525 for VoIP services, and the reverse GTP tunnel 455 and the PDCP entity 525 of the Iu interface. The header compressor 520 is provided in between.

The RNC 505 restores the header from the header restorer 515 to the PDCP entity 525 and transmits the packet received through the GTP tunnel 435 of the Iu interface, and transmits the packet received from the PDCP entity 525. The header is compressed and transmitted to the GTP tunnel 455 of the Iu interface.

For reference, a header decompressor or a header compressor is not provided between the PDCP entity 530 and the GTP tunnels 445 and 490 as in the related art.

6 is a diagram illustrating a process of exchanging control signals according to an embodiment of the present invention.

The terminal exchanges a VoIP call establishment signal with the other party to establish a call (605). The process is performed through the Session Initiation Protocol (SIP), and the parameters required for call setup are exchanged through the Session Description Protocol (SDP). Parameters exchanged through the SDP may include a media type of a call, a required bandwidth, codec information, and the like.

The UE determines whether header compression is required in the Iu interface and the Gn interface through parameters of the SDP received during the call setup process. If the media type of the call you want to set up is audio, header compression is essential. On the other hand, if the media type of the call to be set is video, the need for header compression is reduced. In this case, whether or not to compress the header may be determined according to the policy of the operator.

If it is determined that header compression is necessary, the UE notifies SGSN that header compression is required for the bearer in the process of configuring the bearer. The establishment of a bearer is typically started by the UE sending 610 a message indicating an ACTIVATE PDP context request to the SGSN. Therefore, the terminal includes a header compression request parameter in the message and requests the header compression from the SGSN.

The SGSN determines parameters for a bearer that will service the call in the lu interface in consideration of the characteristics of the call, and then sends the ASSIGNMENT REQUEST message to the radio access bearer (RAB). Forward to RNC via 615. In this case, the message also includes header compression parameters to be set in the RNC.

The header compression parameter is determined according to the type of header compression protocol included in the header processing apparatus. For example, if the header processing apparatus includes the ROHC, the parameters may be as follows.

MAX CID is the maximum value of the context ID (CID) that can be used by the ROHC header compressor and ROHC header decompressor. A context is a space in which parameters related to header compression / restore are stored, and one header compressor / restore may have several contexts. PROFILE is information on the types of protocols that the ROHC header compressor and the header decompressor can compress / restore. The ROHC header compressor and the ROHC header decompressor can perform header compression and restoration on various protocols. For example, PROFILE 1 means compression / restore of IP / UDP / RTP header, and PROFILE 2 means compression / restore of IP / UDP header.

The RNC and SGSN set up a bearer to service the call on the lu interface (620). This means setting up a forward GTP tunnel and a reverse GTP tunnel to service the call. Prior to establishing a bearer, the RNC and SGSN may exchange a response message for the RAB allocation request.

After completing bearer setup, the RNC and SGSN set up a header compression processing device on the lu interface (625). That is, the RNC and SGSN set the header compressor 430 at the SGSN which is the start point of the forward GTP tunnel, and set the header decompressor 515 at the RNC which is the end point of the forward GTP tunnel. Connect with forward GTP tunnel 435. In addition, the RNC and the SGSN set the header compressor 520 at the RNC which is the start point of the reverse GTP tunnel, and the header decompressor 460 at the SGSN which is the end point of the reverse GTP tunnel. ).

In addition, the SGSN determines parameters for a bearer that will service the call in the Gn interface, and then transmits the parameters to the GGSN through a CREAT PDP context request message (630). The request message includes header compression parameters to be set in the GGSN.

SGSN and GGSN establish a bearer to service the call on Gn interface (635). This means setting up a forward GTP tunnel and a reverse GTP tunnel to service the call. Prior to the bearer establishment, GGSN and SGSN may exchange a response message for a CREAT PDP context request message.

After completing bearer setup, the GGSN and SGSN set up a header processing device on the Gn interface (640). Similarly, GGSN and SGSN set up the header compressor 415 at GGSN, which is the start point of the forward GTP tunnel, and set up the header decompressor 425 at SGSN, which is the end point of the forward GTP tunnel. Connect with the tunnel 420. In addition, the GGSN and SGSN set up a header compressor 465 at SGSN, which is the start point of the reverse GTP tunnel, and set up a header decompressor 475 at GGSN, which is the end point of the reverse GTP tunnel. Connect with                     

When the above process is completed, the actual media stream is transmitted and received through the GTP tunnel and the header processing apparatus of the Gn interface and the Iu interface (645).

In the above process, the SGSN exchanges the control message with the RNC and sets up the bearer and the header processing device (615, 620, 625), and the SGSN exchanges the control message with the GGSN and sets up the bearer and the header processing device ( There is no causal relationship between 630, 635, and 640, and the order may be changed. For example, SGSN may first perform control message exchange with bearer and header compression with GGSN, and control message exchange with bearer / header setup with RNC and control message exchange with bearer / header compression with GGSN at the same time. It may be.

7 illustrates an operation of an SGSN on an lu interface according to an exemplary embodiment of the present invention.

Upon receiving an ACTIVATE PDP CONTEXT request with header compression request parameters from the UE, the SGSN recognizes (705) that a header compressor and header decompressor must be set on the lu interface. The SGSN determines header compression parameters for header compressor and header decompressor settings of the lu interface (710). As described above, the header compression parameter is determined according to a header compression protocol to be provided in the header compressor and the decompressor. Taking ROHC as an example, MAX CID or Profile corresponds to the header compression parameter.

The SGSN sends a RAB Assignment Request message to the RNC to establish a header compressor, header decompressor and GTP tunnel on the lu interface (715). The request message includes information necessary for establishing a forward GTP tunnel and header setting device setting parameters determined in step 710. The SGSN receives a response message from the RNC (717). The response message includes information necessary for establishing a reverse GTP tunnel. The information includes a tunnel identifier (TEID) of a reverse GTP tunnel.

The SGSN establishes a forward GTP tunnel and a reverse GTP tunnel on the lu interface (720). The GTP tunnels are connected to the RNC.

SGSN sets up the header compressor and header restorer (725). The header compressor and header decompressor is for header compression and decompression at the lu interface, and performs header compression / restore operation together with the header compressor and header decompressor of the RNC.

SGSN connects the forward GTP tunnel and the header compressor (730) and connects the reverse GTP tunnel and the header decompressor (735).

8 illustrates an operation of an RNC on an lu interface according to an embodiment of the present invention.

When the RNC receives the RAB allocation request message including the header compression parameter and the forward GTP tunnel information from the SGSN (805), the RNC determines the information necessary for establishing the reverse GTP tunnel and transmits the information to the SGSN in the response message (807). The RNC then establishes a forward GTP tunnel and a reverse GTP tunnel (810).

The RNC sets up a header compressor and a header decompressor according to the header compression parameter (815). The RNC connects the reverse GTP tunnel and the header compressor set in step 810 and connects the forward GTP tunnel and the header decompressor (825).

9 illustrates an operation of an SGSN on a Gn interface according to an embodiment of the present invention.

Upon receipt of an ACTIVATE PDP CONTEXT request with header compression request parameters from the UE, SGSN recognizes that a header compressor and a header decompressor must be configured on the Gn interface. The SGSN determines header compression parameters for header compressor and header decompressor settings of the Gn interface (910).

The SGSN sends a CREAT PDP CONTEXT request message to the GGSN to establish a header compressor, header decompressor and GTP tunnel on the Gn interface (915). The request message includes information necessary for establishing a GTP tunnel and the determined header compression parameter. When SGSN receives the response message for the CREAT PDP CONTEXT request (920), the SGSN establishes a forward GTP tunnel and a reverse GTP tunnel on the Gn interface (925). The GTP tunnels are connected with a GGSN.

The SGSN sets up a header compressor and a header restorer (930). The header compressor and header decompressor is for header compression and decompression at the Gn interface, and performs a header compression / restore operation together with the header compressor and header decompressor of GGSN.

The SGSN connects the reverse GTP tunnel and the header compressor set in step 925 (935) and the forward GTP tunnel and the header decompressor (940).

10 is a diagram illustrating an operation of a GGSN on a Gn interface according to an embodiment of the present invention.

When the GGSN receives the CREAT PDP CONTEXT request message including the header compression parameter (1005), the GGSN determines the information necessary for establishing the forward GTP tunnel, and transmits the determined information to the SGSN in the response message (1010). The information necessary for establishing the forward GTP tunnel includes a tunnel identifier (TEID) for use in the forward GTP tunnel.

The GGSN establishes a forward and reverse GTP tunnel (1015). In operation 1020, the GGSN sets up a header compressor and a header decompressor with reference to the header compression parameter.

The GGSN connects the reverse GTP tunnel and the header restorer (1025) and connects the forward GTP tunnel and the header compressor (1030).

The first embodiment of the present invention has been described above. In the first embodiment of the present invention, header compression and decompression are performed separately in the Iu interface and the Gn interface. To this end, SGSN is equipped with a header compressor and a header restorer. The second embodiment of the present invention proposes a scheme in which header compression and decompression is performed only in the RNC and the GGSN. In this case, packets whose headers are compressed in the GGSN are sent directly to the RNC without being reconstructed and compressed again in the SGSN. On the other hand, since the distance between the header compressor and the header decompressor is far, there is a disadvantage that it takes more time to transmit the feedback information. For optimal performance of the currently preferred header compression protocol, such as ROHC, the header decompressor should deliver feedback information as quickly as possible to the header compressor, and the first embodiment of the present invention is advantageous over the second embodiment in this respect. . However, the second embodiment is more advantageous in that the configuration of the SGSN can be simplified.

11 is a diagram illustrating in detail a situation in which VoIP packets are transmitted in a UMTS network core network according to a second embodiment of the present invention.

Here, the description will focus on differences from the first embodiment.

In the second embodiment of the present invention, a header processing apparatus is provided in the RNC 1110 and the GGSN 1120 to handle header compression and restoration. The SGSN 1115 is not involved in header compression and decompression, and determines whether to set header processing devices of the RNC 1110 and the GGSN 1120 and delivers the configuration information to the corresponding node.

The header processing apparatus 1123 of the GGSN 1120 includes a reverse header decompressor and a forward header compressor. The header processing unit 1113 of the RNC 1110 includes a reverse header compressor and a forward header decompressor.

Packets transmitted in the reverse direction from the UE 1105 are input to the reverse header compressor of the RNC 1110. The header compressor compresses the header of the packet and transmits it to the SGSN 1115 through a reverse GTP tunnel configured at an lu interface. The SGSN 1115 transmits the packet to the GGSN 1120 through a reverse GTP tunnel configured on a Gn interface. The GGSN 1120 restores the header of the packet and transmits the packet to the external network.

The forwarded packet is input to the forward header compressor of the GGSN 1120. The header compressor compresses the header of the packet and transmits it to the SGSN 1115 through a forward GTP tunnel configured at a Gn interface. The SGSN 1115 transmits the packet to the RNC 1110 through a forward GTP tunnel configured at an lu interface. The RNC 1110 restores the header of the packet and transfers it to the PDCP.

12 is a diagram illustrating the structure of GGSN, SGSN and RNC on a Gn interface and a lu interface according to a second embodiment of the present invention.

In the second embodiment, the structures of the GGSN 1205, SGSN 1250, and RNC 1285 are shown on the Gn interface and the Iu interface, and the following description will focus on differences from the first embodiment.

In the second embodiment, the SGSN 1250 is not equipped with a header compressor or a header decompressor. Therefore, the packet compressed by the header compressor 1215 of the GGSN 1210 is delivered to the PDCP entity 1290 after the header is recovered by the header decompressor 1240 of the RNC 1285. Also, the packet compressed by the header compressor 1245 of the RNC 1285 is transmitted to the external network after the header is recovered by the header decompressor 1275 of the GGSN 1205. The SGSN 1250 connects the GTP tunnels 1235 and 1255 of the Iu interface with the GTP tunnels 1220 and 1270 of the Gn interface, and does not participate in header compression and restoration.

13 is a diagram illustrating a process of exchanging control signals according to a second embodiment of the present invention.

The terminal exchanges a VoIP call establishment signal with the other party to establish a call (1305). The process is done via SIP and the parameters required for call setup are exchanged via SDP. Parameters exchanged through the SDP may include media type exchanged through a call, bandwidth required, codec information, and the like.

The UE determines whether header compression is required in the Iu interface and the Gn interface for the call to be set up through the parameters of the SDP received in the call setup process. If the media type of the call you want to set up is audio, header compression is essential. On the other hand, if the media type of the call to be set is video, the need for header compression is reduced. In this case, whether or not to compress the header may be determined according to the policy of the operator.

If it is determined that header compression is necessary, the UE notifies SGSN that header compression is required for the bearer in the process of configuring the bearer. The setup of the bearer is typically started by the terminal sending a message, ACTIVATE PDP CONTEXT request to the SGSN. The UE requests the SGSN by including a header compression request parameter in the message (1310).

The SGSN determines parameters for a bearer that will service the call in the lu interface in consideration of the characteristics of the call, and then transmits the parameters to the RNC through an RAB allocation request message (1315). In this case, the message also includes header compression parameters to be set in the RNC.                     

The SGSN sending the RAB assignment request message and the RNC receiving the RAB assignment request message configure a bearer to service the call on the Iu interface (1620). In this case, a response message to the RAB allocation request message may be exchanged between the RNC and the SGSN. Establishing a bearer on the lu interface means setting up a forward GTP tunnel and a reverse GTP tunnel to service the call.

Upon completion of the forward and reverse GTP tunnel setup, the RNC sets up a header processing device (1325). That is, the RNC sets up a header compressor 1245 and connects it with the reverse GTP tunnel 1255, and sets up a header decompressor 1240 and connects it with the forward GTP tunnel 1235.

In addition, the SGSN determines parameters for a bearer that will service the call in the Gn interface, and then transmits the parameters to the GGSN through a CREAT PDP CONTEXT request message (1330). The request message includes header compression configuration parameters to be set in the GGSN. Here, the header compression parameters transmitted to the GGSN are the same as the header compression parameters transmitted to the RNC.

The SGSN sending the CREAT PDP CONTEXT request message and the GGSN and SGSN receiving the CREAT PDP CONTEXT request message establish a bearer to service the call on the Gn interface (1335). This means setting up a forward GTP tunnel and a reverse GTP tunnel to service the call. At this time, prior to bearer setup, a response message to the CREAT PDP CONTEXT request message may be exchanged between SGSN and GGSN. After completing the bearer setup, the GGSN sets up a header processing apparatus (1340). That is, the GGSN sets up the header compressor 1215 and connects it with the forward GTP tunnel 1220, and sets up the header decompressor 1275 and connects it with the forward GTP tunnel 1270.

When the above process is completed, the actual media stream is transmitted and received through the GTP tunnel and the header processing apparatus of the Gn interface and the Iu interface (1345).

The causal relationship between the process of setting the bearer and the header processing apparatus (1315, 1320, 1325) and the process of setting the bearer and the header processing apparatus after SGSN exchanges a control message with the GGSN (1330, 1335, 1340) Is not present and the order may be changed. For example, the control message exchange and bearer and header processing device setting of the Gn interface may be executed first, or the control message exchange and bearer / header processing device setting of the Iu interface and the control message exchange and bearer / header processing device setting of the Gn interface may be executed. Can be performed simultaneously.

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 those equivalent to the scope of the claims.

In the present invention operating as described in detail above, the effects obtained by the representative ones of the disclosed inventions will be briefly described as follows.                     

According to the present invention, instead of compressing and transmitting the header only between the terminal and the RNC, the header is compressed and restored in the SGSN and GGSN in the RNC, the core network, and the core network. This reduces the overhead and increases the efficiency of communication.

Claims (20)

A wireless network controller (RNC) for controlling wireless communication of a mobile terminal, a service node (SGSN) connected to the wireless network controller to control packet services of the mobile terminal, and a gateway node for connecting the service node to the Internet ( In the method for providing a packet service using header compression in a mobile communication system consisting of GGSN), The terminal transmitting a call setup request message including a header compression request parameter to the SGSN; The SGSN determines first header compression parameters for use with the RNC in response to the call setup request message, and then transmits the first header compression parameters to the RNC; The SGSN determining second header compression parameters for use with the GGSN in response to the call setup request message, and then transmitting the second header compression parameters to the GGSN; And performing header compression and header decompression on packets according to the packet service using the first and second header compression parameters between the RNC and the SGSN and between the SGSN and the GGSN. Said method. The method of claim 1, The transmitting of the call setup request message may include determining whether header compression is necessary for the packet service to be initiated by the terminal, and transmitting the call setup request message when the header compression is required. The method of claim 1, Setting up a first bearer for the call between the RNC and the SGSN, and configuring header processing devices in the SGSN and the RNC using the first header compression parameter, respectively; Connecting header processing apparatuses to the first bearing. The method of claim 3, wherein Wherein the first header compression parameters are included in a radio access bearer allocation request message together with a call setup parameter for setting up the first bearer and transmitted from the SGSN to the RNC. The method of claim 3, wherein The first bearer is composed of a forward GTP (GPRS Tunneling Protocol) tunnel and a reverse GTP tunnel, the forward GTP tunnel is connected to the header compressor of the SGSN and the header decompressor of the RNC, The reverse GTP tunnel is connected to a header restorer of the SGSN and a header compressor of the RNC. The method of claim 1, Setting up a second bearer for the call between the SGSN and the GGSN, and configuring header processing apparatuses in the SGSN and the GGSN including the header compressor and the header decompressor using the second header compression parameter, respectively, Connecting header processing devices to the second bearer. The method of claim 6, And wherein the second header compression parameters are included in a radio access bearer allocation request message together with a call setup parameter for setting up the second bearer and transmitted from the SGSN to the GGSN. The method of claim 6, The second bearer is composed of a forward GTP tunnel and a reverse GTP tunnel, the forward GTP tunnel is connected to the header compressor of the GGSN and the header decompressor of the SGSN, The reverse GTP tunnel is connected to a header restorer of the GGSN and a header compressor of the SGSN. The method of claim 1, The header compression and header restoration are performed using a Robust Header Compression (ROHC) protocol. The method of claim 1, The packet is characterized in that the Internet Protocol (IP) / User Datagram Protocol (UDP) / Real Time Protocol (RTP) packet for VOIP services. A wireless network controller (RNC) for controlling wireless communication of a mobile terminal, a service node (SGSN) connected to the wireless network controller to control packet services of the mobile terminal, and a gateway node for connecting the service node to the Internet ( In the method for providing a packet service using header compression in a mobile communication system consisting of GGSN), The terminal transmitting a call setup request message including a header compression request parameter to the SGSN; The SGSN determining header compression parameters for use between the RNC and the GGSN in response to the call setup request message; The SGSN transmitting the header compression parameters to the RNC and the GGSN; And performing header compression and header restoration on packets according to the packet service using the compression parameters between the RNC and the GGSN. The method of claim 11, The transmitting of the call setup request message may include determining whether header compression is necessary for the packet service to be initiated by the terminal, and transmitting the call setup request message when the header compression is required. The method of claim 11, After configuring a first bearer for the call between the RNC and the SGSN, and configured a header processing device in the RNC using a header compression parameter, the header processing device comprises the header processing device; The method further comprises the step of connecting to the bearer. The method of claim 13, And the header compression parameters are transmitted from the SGSN to the RNC in a radio access bearer assignment request message including a call setup parameter for setting up the first bearer. The method of claim 13, The first bearer is composed of a forward GTP tunnel and a reverse GTP tunnel, the forward GTP tunnel is connected to the header decompressor of the RNC, The reverse GTP tunnel is connected to a header compressor of the RNC. The method of claim 11, Setting up a second bearer for the call between the SGSN and the GGSN, configuring a header processing device in the GGSN including a header compressor and a header decompressor using the header compression parameters, and then configuring the header processing device in the GGSN. The method further comprises the step of connecting to the bearer. The method of claim 16, And the header compression parameters are transmitted from the SGSN to the GGSN in a radio access bearer allocation request message including a call setup parameter for setting up the second bearer. The method of claim 16, The second bearer is composed of a forward GTP tunnel and a reverse GTP tunnel, the forward GTP tunnel is connected to the header compressor of the GGSN, The reverse GTP tunnel is connected to a header decompressor of the GGSN. The method of claim 11, The header compression and header restoration are performed using a Robust Header Compression (ROHC) protocol. The method of claim 11, The packet is characterized in that the IP / UDP / RTP packet for VOIP service.

Images