KR101458789B1 - ASN Gateway in Broadband Wireless Communication System for Supporting ROHC Channel Negotiation Method - Google Patents

Abstract

The control station supporting the ROHC channel negotiation method according to an aspect of the present invention for providing a method for negotiating a ROHC channel receives a subscriber profile including an ROHC policy from AAA or PCRF, A service flow acknowledgment unit for generating and distributing a Classification Rule and triggering ROHC channel negotiation with a terminal related to the subscriber profile; An ROHC function unit performing ROHC channel negotiation with the terminal by exchanging ROHC per channel parameters with the terminal; And a data path management unit for delivering the downlink packet to the ROHC functional unit when the downlink packet is ROHC-applied, and for forwarding the uplink packet to the ROHC functional unit when the uplink packet is ROHC-compressed .

Description

[0001] The present invention relates to a control channel for a broadband wireless communication system supporting an ROHC channel negotiation method,

The present invention relates to a broadband wireless communication system, and more particularly, to a ROH channel negotiation in a broadband wireless communication system.

In a wireless communication system, it is particularly important to utilize limited resources as efficiently as possible. However, this makes it more difficult to utilize the IP protocol in the air interface, since in the IP-based protocol the area of the various headers in the data to be transmitted is very large, resulting in a small payload area .

For example, if VoIP is implemented using IPv4, a considerable amount of radio frequency bandwidth will be wasted in transmitting the header, and IPv6 will cause more bandwidth loss because the header size is further expanded.

In addition, in a poor communication environment, the bit error rate (BER) of the air interface and the round trip time (RTT) of the uplink and the downlink are greatly increased, which causes a lot of problems in most header compression methods according to the prior art.

For this reason, a demand has arisen for a header compression method suitable for packet transmission over various IP protocols and air interfaces, and in particular, there is a demand for an efficient header compression method that can be utilized in a condition where the bit error rate and delay increase greatly . For this reason, the Internet Engineering Task Force (IETF) has recently standardized the header compression method known as ROHC (RObust Header Compression).

One of the important reasons for the development of ROHC is to solve this problem because there are a lot of redundancies between not only the packets but also between the IP headers used for packet transmission. That is, most of the information in the header does not change at all during data packet transmission. In this case, information contained in the header can be easily reconstructed at the receiving end even if it is not transmitted.

For the above reasons, the WIBRO technology and the WiMAX NWG (Worldwide Interoperability for Microwave Access Forum Network Working Group), based on the IEEE 802.16 technology standard, provide the wireless Internet service of the terminal through the header compression method such as ROHC I am trying to provide.

However, although a method for negotiating a ROHC channel within a WiMAX network is required, a solution has not yet been proposed.

SUMMARY OF THE INVENTION The present invention provides a control station in a broadband wireless communication system that supports a method for negotiating a ROHC channel in a broadband wireless communication system.

The present invention also provides a ROHC technique in a communication environment such as WiMAX or WiBro.

According to an aspect of the present invention, a control station for supporting an ROHC channel negotiation method includes: a receiving unit configured to receive a subscriber profile including an ROHC policy from an AAA or a PCRF and to provide a classification rule for ROHC A service flow acknowledgment unit for triggering ROHC channel negotiation with a terminal associated with the subscriber profile; An ROHC function unit performing ROHC channel negotiation with the terminal by exchanging ROHC per channel parameters with the terminal; And a data path management unit for delivering the downlink packet to the ROHC functional unit when the downlink packet is ROHC-applied, and for forwarding the uplink packet to the ROHC functional unit when the uplink packet is ROHC-compressed .

According to the present invention, the ROHC channel negotiation procedure can be clarified because the ROHC channel can be negotiated between the ROHC entity and the ROHC entity through the message exchange in the wireless and wired sections including the ROHC facilitation parameter during the service flow generation process in which the ROHC is applied It is effective.

Also, the present invention supports the ROHC scheme in an environment such as WiMAX or WiBro, and thus can efficiently utilize the radio resources of the radio interface section.

1 is a configuration diagram of a wireless communication system that provides an ROHC service according to an embodiment of the present invention;
Figure 2 shows a TLV of a ROHC per channel parameter according to an embodiment of the present invention.
3 is a diagram illustrating a mapping relationship between a ROHC context identifier and a service flow for ROHC packet transmission / reception in a wireless communication system according to an exemplary embodiment of the present invention.
4 is a diagram schematically illustrating a ROHC channel negotiation procedure according to an embodiment of the present invention;
5 illustrates ROHC channel negotiation procedures for predefined service flows in unidirectional mode;
6 is a diagram showing a ROHC channel negotiation procedure for a predefined service flow in bidirectional mode;
7 is a diagram illustrating a ROHC channel negotiation procedure for a dynamic service flow in a unidirectional mode;
8 shows ROHC channel negotiation procedures for dynamic service flows in bidirectional mode;
9 is a flowchart illustrating a method for generating a service flow for an ROHC initiated by an AAA in accordance with an embodiment of the present invention.
10 is a flow chart illustrating a method for generating a service flow for ROHC initiated by PCRF in accordance with another embodiment of the present invention.
11 is a flow chart illustrating a method for deleting a service flow for ROHC initiated by PCRF in accordance with another embodiment of the present invention.

Before describing the embodiments of the present invention in detail, the terms used in the present invention will be briefly described.

ROHC Function: A functional entity including a ROHC De-Compressor and a Robust Header-Compression Compressor defined in RFC 3095.

ROHC Service Flow (ROHC SF): An 802.16e service flow mapped to a ROHC channel. In other words, a Convergence Sub-Layer (CS) type is defined as "packet, ROHC header compressed IP" in the service flow.

ROHC Channel: A logical unidirectional point-to-point channel that transmits ROHC packets from a ROHC compression unit to a decompression unit, see Section 2 of RFC 37757.

ROHC Compressor: A functional entity that inspects an IP header and compresses the IP header into an ROHC header having an ROHC header context. See the definition of the ROHC compression example in the RFC 3775 document.

ROHC De-Compressor: A functional entity that maintains the header context and reconstructs it from the compressed headers into the original header. See the definition of the ROHC decompressor example in the RFC 3775 document.

Per-Channel Negotiation: A procedure for negotiating channel-unit parameters between the ROHC compression unit and the ROHC decompression unit.

Per-Channel Parameters: The ROHC channel is based on a number of parameters to form part of the established channel state and per-context state.

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

FIG. 1 is a block diagram of a wireless communication system providing a ROHC (Robust Header Compression) service according to an embodiment of the present invention.

1, a wireless communication system according to an exemplary embodiment of the present invention includes a CSN (Connectivity Service Network) 102, an ASN (Access Service Network) 108, and a mobile station 120, Transmits the ROHC downlink packet from the MS 120 to the CSN 102, and transmits the ROHC uplink packet from the MS 120 to the CSN 102.

The CSN 102 includes an Authentication-Authorization-Accounting (AAA) 104 and a Policy and Charging Rules Function (PCRF) 106. The CSN 102 authenticates the user through the AAA 104 for the ASN 108 and the terminal 120 , Authorization verification, and account management functions, and generates rules related to the user's network service policy and billing through the PCRF (106). The CSN 102 includes a Home Agent (HA) to support the mobility of the AT 120, and delivers the packet to the AT 120 through the ASN 108 in the HA.

The AAA 104 transmits the Subscriber Profile including the ROHC policy to the ASN-GW (Access Service Network GateWay) 110 during the user authentication process for the pre-provisioned service flow . It also maintains the subscriber profile that contains the ROHC policy. Accordingly, the AAA 104 performs the above-described functions to allow the ASN-GW 110, which serves as the terminal 120 and the control station (not shown), to recognize whether or not ROHC is applied.

The PCRF 106 transmits the subscriber profile including the ROHC policy to the ASN-GW 110 for dynamic service flow so that the ASN-GW 110 transmits the ROHC packet transmission / reception method And the like.

The ASN 108 includes an ASN-GW 110 and a base station 118 as a control station and has a function of establishing a wireless interface and a Layer-2 connection between the base station (BS1 118) and the terminal 120, A network discovery function, a network selection function, a forwarding function for establishing a Layer-3 connection of the terminal 120, and a radio resource management function.

The ASN-GW 110 includes a service flow authorization unit 112, a data path function unit 114 and an ROHC function unit (ROHC function: not shown) To the base station 118, decompresses the ROHC compressed uplink packet, and transmits the decompressed uplink packet to the CSN 102.

Here, the ROHC functional unit is disposed together with the data path management unit 114, and includes an ROHC compression unit (not shown) and an ROHC decompression unit (not shown). The ROHC functional unit can be expressed as an ROHC entity It is possible.

The service flow acknowledgment unit (SFA) 112 receives the ROHC policy from the AAA 104 or PCRF 106. Then, a classification rule for ROHC is generated and distributed, and the ROHC functional unit 124 of the terminal 120 and information on the service flow are transmitted through SFM (Service Flow Management: not shown) of the base station 118 Exchange.

If the terminal 120 accepts the service flow including the ROHC classification rule, the service flow acknowledgment unit 112 transmits a ROHC Per-Channel Parameter Negotiation (ROHC Per-Channel Parameter Negotiation) message after a Service Flow Negotiation ).

In addition, the service flow acknowledgment unit 112 generates service flow information of a service flow for ROHC packet transmission / reception, and the ASN-GW 110, the base station 118, and the terminal 120 acquire the service flow information I will.

A data path ID (Data Path ID), which is a sub-TLV of the service flow information generated by the service flow acknowledgment unit 112, includes a data path tag such as a general routing encapsulation key (GRE Key) ).

In addition, the service flow information includes ROHC parameters obtained through information exchange with the ROHC compression unit and the ROHC decompression unit of the ASN-GW 110. Here, the ROHC parameter includes a ROHC per-context parameter, a ROHC per-context parameter, a profile, a context, a ROHC context identifier, and a classifier ) May be included.

In one embodiment, the ROHC per channel parameters are defined as TLV (Type, Length, Value) as shown in FIG. 2A, and the ROHC per channel parameters are repeated without Type, Length, and Value padding . The types of ROHC per channel parameters may include a MAX CID type 210, a LARGE CIDS type 220, and a PROFILE 230 type as shown in FIG. 2B.

At this time, the MAX CID type 210 is a field in which the highest Context Identifier number used by the ROHC compression unit is recorded, and its length is 2 bits.

Next, the LARGE CIDS type 220 is a field in which a representation type of a context identifier is recorded. If the value is False, a short context identifier representation type is used as a representation type of a context identifier. If the value is True Indicates that the embedded context identifier representation type is used as the representation type of the context identifier. At this time, if the value of the LARGE CIDS type is 0x00, it is determined as False, and if it is 0x01, it is determined as True.

Here, the short context identifier representation type covers the context identifier numbers 0 to 15, and the embedded context identifier representation type covers the context identifier numbers 0 to 16383.

The PROFILE type field 230 is a field in which at least one profile supported by the ROHC decompression unit is recorded. When the value Ox0000 is recorded, the PROFILE type field 230 indicates an uncompressed IP packet. If a value of 0x0001 is recorded, the RTP / Compression. When a value of 0x0002 is recorded, UDP / IP compression is indicated. When a value of 0x0003 is recorded, ESP / IP compression is indicated.

Meanwhile, the ROHC per channel parameter may optionally include a FEEDBACK_FOR type 240 in which an identifier (SFID) of a service flow to which ROHC feedback is transmitted is recorded, as shown in FIG. 2B, The length is 4 bits as shown.

In this way, before receiving the ROHC packet, the ASN-GW 110 and the terminal 120 can determine whether to receive the ROHC packet of the service flow for receiving the ROHC packet through the service flow information and the ROHC context identifier mapped to the service flow It is possible to acquire and store the ROHC parameters including the ROHC parameters.

The ROHC functional unit of the ASN-GW 110 initiates per channel parameter negotiation for ROHC channel negotiation with the ROHC functional unit 124 in the terminal 120.

The per channel parameter negotiation is performed by exchanging per channel parameters between the ASN-GW 110 and the ROHC compression units and the decompression units in the terminal 120. Since the ROHC channel is mapped to the service flow on a one-to-one basis, the per-channel parameters are included in the service flow information, and the DSA-REQ / DSA-RSP message including the service flow information is negotiated .

The ROHC compression unit of the ASN-GW 110 compresses IP headers into ROHC packet headers that maintain the ROHC context, and the ROHC decompression unit maintains header contexts and restores the compressed headers into the original header.

The data path management unit (DPF) 114 performs classification for downlink (DL) packets and checks whether ROHC application is required.

When the DL packets belong to the ROHC channel, the data path management unit 114 delivers the DL packets to the ROHC compressor. Then, encapsulation of R6 (data path between the terminal and the base station) data path tag is performed and transmitted to the base station (BS1: 118).

The data path management unit 114 receives an uplink (UL) packet from the base station 118 and, if the UL packets belong to the ROHC channel, transfers the UL packet to the ROHC decompression unit.

The base station 118 maintains the mapping relationship between the R6 data path tag and the CID (802.16e CID). And processes the UL packets by processing the DL packets by replacing the R6 GRE key, which is the R6 data path tag, with the 802.16e CID, and replacing the 802.16e CID with the R6 GRE key.

If the DSA message includes the ROHC parameter, the terminal 120 establishes a channel between the ROHC functional unit 124 and the CS layer. If the DL packets belong to the ROHC channel, the DL packets are forwarded to the ROHC decompression unit included in the ROHC function unit 124.

Also, the terminal 120 performs classification for confirming whether the ROHC is applied to the UL traffic. When the UL packet belongs to the ROHC channel, the terminal 120 performs ROHC compression. And transmits the UL packet to the base station 118 using the appropriate 802.16e CID mapped to the ROHC channel of the UL packet.

3 is a diagram illustrating a mapping relationship between a ROHC context identifier and a service flow for ROHC packet transmission / reception in a wireless communication system according to an exemplary embodiment of the present invention. Hereinafter, the service flow is mapped to the ROHC channel at 1: 1, and one ROHC channel may have an IP flow using a plurality of ROHCs. Here, the ROHC channel means a header compression transport channel to which ROHC is applied.

The IP flow 308 and the service flow identifier (SFID) 302 are N: 1 (N (N)), which is a downlink packet that can have N kinds of IP flows 308 transmitted from the CSN 102. [ Is a positive integer), and the ROHC context identifier 306 and the IP flow 308 are mapped to 1: 1.

In the ASN 108, the service flow identifier 302 is mapped 1: 1 to the ROHC channel 304, which is a logical channel. Here, the ROHC channel 304 and the ROHC context identifier 306 are mapped to 1: N. As a result, the service flow identifier 302 and the ROHC context identifier 306 are mapped 1: N via the ROHC channel 304.

Also, since the service flow identifier 302 is mapped to the connection identifier 310 between the base station 118 and the terminal 120 by 1: 1, the connection identifier 310 and the ROHC context identifier 306 are also 1: Lt; / RTI > Here, the above-described mapping relationship is equally applied to the ASN 108 or the terminal 120.

The above mapping relationship is recognized in the ASN 108 and the terminal 120 when a service flow for ROHC is created. The ASN-GW 118 and the AT 120 can determine whether ROHC is applied by referring to the mapping relationship. The mapping relationship allows the ASN-GW, the base station, or the terminal to which the ROHC packet is to be transmitted to be identified. The base station 118 and the terminal 120 acquire the mapping relationship through the service flow information.

The service flow information includes a Packet Classification Rule, an Enhanced Compressed RTP Context Identifier (ROHC / ECRTP) Context Identifier, a Classifier Type, or a Convergence Sub-Layer Parameter Encoding Rule, . ≪ / RTI >

The ROHC application status is defined by a classifier type or CS parameter encoding rule, and the ROHC context identifier 306 is defined by the ROHC / ECRTP context identifier. Accordingly, the ASN-GW 110 and the AT 120 can know whether ROHC is applicable to the corresponding service flow through the service flow information and acquire the ROHC context identifier 306 mapped to the IP flow belonging to the corresponding service flow do.

In addition, the base station 118 refers to the service flow information and obtains the mapping information of the data path identifier (GRE key) and the connection identifier 310 corresponding to the service flow.

The terminal 120 refers to the service flow information and generates a ROHC channel 304 including the connection identifier 310 between the base station 118 and the terminal 120 corresponding to the service flow and the ROHC context identifier 306 ). ≪ / RTI >

Through the above mapping information, the ASN-GW 110 can know the ROHC application of the received DL packet, and can know the base station 118 to which the ROHC packet is to be transmitted after ROHC compression. The base station 118 may know the terminal 120 to which the received ROHC packet is to be transmitted. In addition, the terminal 120 can determine whether ROHC is applied to the received ROHC packet and perform ROHC decompression. The UL packet can be described as an inverse process of the above-described process.

1, service flow information generated by the service flow acceptance unit 112 and including ROHC parameters such as ROHC application status, ROHC perch channel parameter, and ROHC context identifier is transmitted to a data path setup request (Path_Reg_Req) Message to be transmitted from the ASN-GW 110 to the base station 118.

Then, the service flow information may be included in the dynamic service addition (DSA-REQ) message transmitted from the base station 118 to the terminal 120. Here, since the Path_Reg_Req message and the DSA-REQ message can include the service flow information as the TLV, the ROHC parameter can be transmitted.

In addition, service flow information including a predetermined ROHC parameter is transmitted from the AT 120 to the ASN-GW 110 through the Path_Reg_Rsp message and the DSA-RSP message.

That is, the ASN-GW 110 and the SS 120 can perform ROHC channel negotiation by exchanging ROHC parameters through the service flow information included in the Path_Reg_Req / Rsp and the DSA-REQ / RSP .

4 is a diagram schematically illustrating an ROHC channel negotiation procedure (ROHC Channel Negotiation Procedure) according to an embodiment of the present invention.

As shown, the ROHC channel negotiation procedure is initiated by a DSA request message (DSA-REQ) or a DSC request message (DSC-REQ) of 802.16e. At this time, the 802.16e MAC layer does not interpret the TLH (ROHC Parameter Payload TLV) of the ROHC parameter.

Specifically, the base station 118 and the terminal 120 perform a negotiation procedure using a DSA-REQ / RSP or a DSC-REQ / RSP including a ROHC parameter as a TLV for ROHC channel negotiation, The ROHC entity 124 of the terminal 120 performs a negotiation procedure so that ROHC parameters for ROHC channel negotiation can be exchanged.

In addition, the base station 118 and the anchor ASN-GW 110 include the ROHC parameter as a TLV in a message used in the data path R6 between the base station 118 and the anchor ASN-GW 110, The anchor ASN-GW 110 performs an RO negotiation procedure so that ROHC parameters for ROHC channel negotiation can be exchanged in the ROHC entity of the anchor ASN-GW 110. [

Referring again to FIG. 1, the ASN-GW 110 receives a subscriber profile including dynamic service flow information including the ROHC policy from the PCRF 106 during a dynamic service flow establishment procedure. Then, the ASN-GW 110 determines whether or not ROHC is applied to the dynamic service flow. The ASN-GW 110 then initiates the procedure of the dynamic service flow with the ROHC and triggers the ROHC negotiation between the ASN-GW 110 and the terminal 120.

Hereinafter, the ROHC channel negotiation procedure between the control station and the terminal will be described in detail with reference to FIG. 5 to FIG.

5 is a diagram showing a ROHC channel negotiation procedure for a service flow defined in the unidirectional mode.

As shown, the SFA 112 of the ASN-GW 110, which is the control station, receives the information of the prescribed service flow including the subscriber profile having the ROHC policy from the AAA 104.

That is, the AAA 104 must provide the ASN-GW 110 with information about the subscriber profile including IP / UDP or IP / UDP / RTP, in order to determine the ROHC profile.

Thereafter, an R6 path-registration procedure (R6 path-reg-procedure) for establishing an initial service flow is performed between the SFA 112 and the SFM (Service Flow Management) 119 included in the base station 118, An 802.16e DSA procedure for establishing an initial service flow between terminals 120 is performed. Meanwhile, during the DSA procedure, the UE checks whether it supports ROHC.

Thereafter, an IP acquisition procedure is performed between the DHCP Relay / Proxy CMIPv4 FA 510 included in the ASN-GW 110 and the DHCP / CMIPv4 client 530 included in the AT 120. [

GW 110 determines that the ROHC is required to be applied through the subscriber profile after the IP of the terminal is acquired through the IP acquisition procedure. If the ASN-GW 110 determines that the ROHC is supported, ROHC < / RTI > facilitated parameter negotiation for ROHC channel negotiation between terminal 120 and terminal 120 begins. At this time, the ROHC per channel parameters may include MAX_CID type, LARGE_CIDS type, PROFILE type and MRRU type.

Specifically, the ROHC per channel parameters are exchanged between the ASN-GW 110 and the base station 118 using the R6 control path, that is, the GRE-tag-info and the connection identifier, in the downlink period Channel parameters between the base station 118 and the terminal 120 by exchanging at least one of the DSA message or the DSC message including the ROHC facilitation parameter as described above between the base station 118 and the terminal 120 do.

As described above, the ROHC channel negotiation is performed between the ASN-GW 110 and the terminal 120 by exchanging the ROHC per-channel parameters using the R6 control path in the wired section and the DSA / DSC message in the wireless section.

Meanwhile, at least one of the DSA message or the DSC message including the ROHC facilitation parameter is transmitted and received between the subscriber station 120 and the subscriber station 120 in the uplink interval, as described above, Exchanges channel parameters and exchanges ROHC per channel parameters between the base station 118 and the ASN-GW 110 using the R6 control path.

As described above, the ROHC channel negotiation is performed between the ASN-GW 110 and the terminal 120 by exchanging the ROHC per channel parameters using the R6 control path in the wired section and the DSA / DSC message in the wireless section. do.

6 is a diagram showing a ROHC channel negotiation procedure for the service flow defined in the bidirectional mode.

6, in the ROHC channel negotiation process, the feedback for the uplink corresponding to the downlink is transmitted together in the downlink period, and the feedback for the downlink corresponding to the uplink period is transmitted together with the uplink Therefore, only the difference from FIG. 5 will be described with reference to FIG. 6.

First, ROHC channel negotiation is performed between the ASN-GW 110 and the base station 118 in the downlink interval, together with ROHC per channel parameters using the R6 control path, as well as feedback information on the uplink, The terminal 120 transmits not only the ROHC per channel parameters but also the feedback information on the uplink through the DSA / DSC message.

In the ROHC channel negotiation, not only the ROHC per channel parameters but also the feedback information for the downlink are transmitted together with the DSA / DSC message between the terminal 120 and the base station 118 in the uplink interval, The ASN-GW 110 transmits the ROHC per channel parameters as well as the feedback information on the downlink using the R6 control path.

7 is a diagram illustrating a ROHC channel negotiation procedure for a dynamic service flow in a unidirectional mode.

As shown, the SFA 112 of the ASN-GW 110, which is the control station, receives the information of the dynamic service flow including the subscriber profile having the ROHC policy from the PCRF 106.

That is, the PCRE 106 must provide the ASN-GW 110 with information about the subscriber profile including IP / UDP or IP / UDP / RTP, in order to determine the ROHC profile.

Thereafter, an R6 path-registration procedure (R6 path-reg-procedure) for establishing a dynamic service flow is performed between the SFA 112 and the SFM (Service Flow Management) 119 included in the base station 118, An 802.16e DSA procedure for establishing a dynamic service flow between terminals 120 is performed. Meanwhile, during the DSA procedure, the UE checks whether it supports ROHC.

If it is determined that the ROHC is applied through the subscriber profile and the ASN-GW 110 determines that the terminal supports the ROHC, the ASN-GW 110 transmits the ROHC channel negotiation between the ASN- Channel parameter negotiation begins. At this time, the ROHC per channel parameters may include MAX_CID type, LARGE_CIDS type, PROFILE type and MRRU type.

The ROHC channel negotiation procedure between the ASN-GW 110 and the terminal 120 is the same as that shown in FIG. 5, so a detailed description thereof will be omitted.

8 is a diagram illustrating a ROHC channel negotiation procedure for a dynamic service flow in a bidirectional mode.

8, in the ROHC channel negotiation process, the feedback for the uplink corresponding to the downlink is transmitted together in the downlink period, and the feedback for the downlink corresponding to the uplink period is transmitted together with the uplink Only the difference from FIG. 7 will be described.

First, ROHC channel negotiation is performed between the ASN-GW 110 and the base station 118 in the downlink interval, together with ROHC per channel parameters using the R6 control path, as well as feedback information on the uplink, The terminal 120 transmits not only the ROHC per channel parameters but also the feedback information on the uplink through the 802.16e DSA / DSC message.

Next, in the ROHC channel negotiation, not only the ROHC per-channel parameters but also the feedback information on the downlink are transmitted together with the 802.16e DSA / DSC message between the terminal 120 and the base station 118 in the uplink interval, ) And the ASN-GW 110 transmit ROHC per channel parameters as well as feedback information on the downlink using the R6 control path.

In FIGS. 6 and 8, it is described that the ROHC feedback information is transmitted in a piggybacked form. That is, in the above-described embodiment, the ROHC feedback information for the uplink corresponding to the downlink is piggybacked between the compressed header packets of the downlink, is transmitted interspersed, The ROHC feedback information for the link is piggybacked between uplink compressed header packets and then interspersed and transmitted. In this case, the service flow for the downlink and the service flow for the uplink will be established at the same time.

In another embodiment, the ROHC feedback information may be transmitted through a single dedicated channel feedback channel (ROHC feedback channel) for transmission of ROHC feedback information, or may be transmitted through two dedicated ROHC feedback channels Channel).

Meanwhile, when the UE enters the idle mode by performing the idle mode entry procedure after the ROHC channel negotiation, the negotiated ROHC per channel parameters can be stored in the paging controller.

In addition, when the UE enters the idle mode by performing the idle mode entry procedure, the internal states and the dynamically established contexts such as the ROHC context identifier for a given UE will be reset.

Hereinafter, a procedure for creating or deleting a service flow for ROHC will be described with reference to FIGS. 9 to 11. FIG.

FIG. 9 is a flowchart illustrating a method for generating a service flow for an ROHC initiated by AAA according to an exemplary embodiment of the present invention. Referring to FIG.

It is noted in Figure 9 that service flow generation for ROHC channel establishment can be initiated by base station 118 or terminal 120. [

First, access authentication is performed between the terminal 120 and the AAA 104 (S902). During the authentication procedure, the subscriber station 120 and the ASN-GW 110 receive a pre-provisioned service flow information including a ROHC policy from the AAA 104, Receive the profile.

Next, an initial service flow (ISF) establishing procedure is performed between the terminal 120 and the anchor SFA 112 (S904). Here, the ASN-GW 110 may trigger the anchor SFA 112 to generate an ISF and optionally trigger another to generate the specified service flow.

Next, the terminal 120 performs a procedure for IP acquisition (IP Acquisition) with the home agent (HA) 107 (S906).

Next, the ROHC function of the ASN-GW 110 triggers the anchor SFA 112 to generate a service flow for the ROHC. At this time, the ROHC functional unit of the ASN-GW 110 transmits the ROHC parameter to the anchor SFA 112. The anchor SFA 112 transmits a path registration request message (Path_Reg_Req) including the received ROHC parameter to the SFM (Service Flow Management) 119 of the base station 118 (S908).

In one embodiment, the service flow information included in the Path_Reg_Req may have a Reservation Action TLV requesting creation of a service flow for ROHC.

At this time, the Path_Reg_Req / Rsp, DSA-REQ / RSP, and DSC-REQ / RSP messages include service flow information (SF Info) as a sub-TLV. The service flow information includes a classifier for ROHC application, A ROHC parameter including a context identifier (ROHC Context ID), a per channel parameter, and the like.

Then, the SFM 119 receiving the Path_Reg_Req confirms the radio resource and determines whether to accept the service flow request for ROHC. If the request is accepted, a DSA request message (DSA-REQ) corresponding to IEEE 802.16e is transmitted to the terminal 120 (S910). Here, the DSA-REQ includes service flow information, and the service flow information includes an ROHC parameter.

Next, when the terminal 120 receives the DSA-REQ from the SFM 119, it checks whether the DSA-REQ includes the TLV carrying the ROHC parameter. If the DSA-REQ includes the TLV with the ROHC parameter, the terminal 120 transmits the ROHC-REQ message to the upper layer corresponding to the ROHC entity 124 (S912).

At this time, a service access point (SAP) is created between the upper layers corresponding to the Convergence Sublayer (CS) and the ROHC entity 124. This creates a connection identifier (802.16e CID) and a service flow identifier ). ≪ / RTI >

In one embodiment, when the downlink packet is received at the terminal 120, ROHC application of the downlink packet is performed according to the mapping information for the ROHC channel identifier of the ROHC channel formed in the terminal 120, A classification procedure can be carried out to determine whether or not it is possible. Also, using the mapping information, a classification procedure for determining whether ROHC is applied to the uplink packet can be performed.

On the other hand, the classification rule received through the DSA-REQ is included in the ROHC-REQ for classification of packets to be ROHC-compressed by the ROHC entity 124.

Next, the ROHC entity 124 of the terminal 120 adds the ROHC context ID received through the ROHC-REQ to the mapping table, and transmits the ROHC context ID to the mapping table using the ROHC response message (ROHC-RSP) To the MAC layer via the ROHC service access point generated in step S914.

Next, the terminal 120 identifies the connection identifier and the service flow identifier using the ROHC SAP Index of the ROHC service access point, and then transmits the DSA response message (DSA-RSP) to the SFM 119 (S916 ).

Here, the DSA-RSP includes ROHC parameters for ROHC negotiation (ROHC negotiation). The ROHC parameter for ROHC negotiation is obtained from the ROHC entity 124 of the terminal 120 and is intended to be transmitted to the ROHC entity of the ASN-GW 110 for ROHC negotiation.

On the other hand, if the ROHC negotiation can not be completed through the DSA procedure, negotiation can be continued using the DSC (Dynamic Service Change) message in the link layer in step S922.

Next, the SFM 119 transmits the path registration response message (Path_Reg_Rsp) to the anchor SFA 112 to confirm the reservation (S918). If the reduced resource is granted by the SFM 119, the set of QoS parameters of the granted resource is returned to the anchor SFA 112 by the SFM 119. Here, the parameters for the ROHC negotiation included in the Path_Reg_Rsp are transmitted to the ROHC entity of the ASN-GW 110.

Next, the anchor SFA 112 transmits a path registration acknowledgment message (Path_Reg_Ack) to the SFM 119 to confirm the reservation (S920).

If the reduced resource is granted by the SFM 119, the set of QoS parameters of the granted resource is returned to the anchor SFA 112 by the SFM 119.

Next, if the ROHC negotiation can not be completed through the DSA procedure, the ROHC negotiation is continuously performed using the DSC procedure until the negotiation is completed (S922). In one embodiment, the DSC procedure may be a negotiation procedure for exchanging ROHC parameters using a DSC request / response message (DSC-REQ / RSP) between the terminal 120 and the SFM 119.

10 is a flowchart showing a PCRF initiated ROHC Service Flow Creation Method initiated by PCRF according to another embodiment of the present invention. Hereinafter, for the sake of convenience of explanation, a description that can be understood through FIG. 9 is omitted.

The AF (Application Function) 103 provides service information (Application level Session Info) to the PCRF 106 for AF session signaling (S1002).

Next, the PCRF 106 performs authorization and policy determination and provides a PCC (Policy and Charging Control) decision including a new ROHC policy to the anchor SFA 112a (S1004). In one embodiment, the above-described PCC Rules Provision can be performed using a RAR message (Re-Auth-Request).

Next, the Policy Decision Function (PDF) of the anchor SFA 112a receives the QoS profile from the PCRF 106. [ The PDF transmits a Resource Reservation Request (RR_Req) containing QoS parameters to the Serving SFA 112b (S1006). In one embodiment, RR_Req includes service flow information (SF info with ROHC) for ROHC.

Next, the serving SFA 112b transmits Path_Reg_Req including the received QoS information TLV (QoS info TLV) and the ROHC parameter to the SFM 119 (S1008).

Next, the SFM 119 identifies the radio resource and determines whether to accept the service flow request for ROHC based on the QoS information (QoS-Info) parameter and possible resources. In the case of accepting the request, the base station 118 transmits a DSA-REQ corresponding to IEEE 802.16e to the terminal (S1010). Here, the DSA-REQ includes the ROHC parameter and the ROHC classification rule.

Next, upon receiving the DSA-REQ message from the SFM 119, the terminal 120 checks whether the DSA-REQ includes the TLV carrying the ROHC parameter. If the DSA-REQ includes the TLV carrying the ROHC parameter, the terminal 120 transmits the ROHC-REQ to the upper layer corresponding to the ROHC entity 124 (S1012).

At this time, a service access point between the upper layer corresponding to the CS and the ROHC entity 124 is generated, and it is used to map the 802.16e CID and the SFID in the CS. The Classification Rule received through the DSA-REQ is included in the ROHC-REQ for classifying the packet to be compressed by the ROHC entity 124.

Next, the ROHC entity 124 of the terminal 120 adds the ROHC context ID to the mapping table and transmits the result to the MAC layer through the ROHC service access point previously created using the ROHC-RSP (S1014).

The UE 120 identifies the CID and the SFID using the ROHC SAP Index of the ROHC and then transmits the DSA-RSP to the SFM 119 S1016).

Here, the DSA-RSP includes ROHC parameters for negotiation. If the ROHC negotiation can not be completed through the DSA procedure, negotiation can be continued using the DSC message at the link layer in step S1022 described later.

Next, assuming that a request to create a service flow for ROHC is granted by the SFM 119 and the terminal 120, the SFM 119 transmits Path_Reg_Rsp to the serving SFA 112b to confirm the reservation (S1018).

If the reduced resource is granted by the SFM 119, the set of QoS parameters of the granted resource is returned by the SFM 119. Here, Path_Reg_Rsp includes a ROHC parameter for ROHC negotiation.

Next, the serving SFA 112b transmits Path_Reg_Ack to the SFM 119 (S1020).

On the other hand, if the ROHC negotiation can not be completed through the DSA procedure, the ROHC negotiation may continue using the DSC procedure until completion (S1022).

Next, when there is a successful response from the SFM 119, the serving SFA 112b transmits a resource reservation response message (RR_Rsp) having the QoS information parameter including the allowed QoS value to the anchor SFA 112a for confirmation of the reservation, (S1024).

Next, when there is a successful response from the serving SFA 112b, the anchor SFA 112a transmits a resource reservation acknowledgment message (RR_Ack) to the serving SFA 112b (S1026).

Next, the PDF of the anchor SFA 112a transmits a PCC rule provision ACK including a PCC decision to the PCRF 106 (S1028).

Next, the PCRF 106 transmits an ACK message including the PCC decision to the AF 103 (S1030).

11 is a flowchart showing a PCRF Initiated ROHC Service Flow Deletion Method for ROHC initiated by PCRF according to another embodiment of the present invention. Hereinafter, for the sake of convenience of description, a description that can be understood through FIG. 4 and FIG. 5 will be omitted.

First, the AF 103 such as the terminal 120 and the 3GPP call session control function (CSCF) completes an application session release procedure (S1102).

Next, the AF 103 provides the PCRF 106 with service information for AF session signaling (S1104). Herein, the service information includes an Application Session Removal Note.

Next, the PCRF 106 performs authority verification and policy decision, and provides all new PCC decisions to the PDF of the anchor SFA 112a (S1106). In one embodiment, the provision of the PCC decision described above may be performed using a RAR message (Re-Auth-Request) including a PCC Rules Removal Notification.

Next, the PDF of the anchor SFA 112a receives the QoS profile from the PCRF 106. [ Then, the PDF transmits RR_Req including the QoS parameter to the serving SFA 112b (S1108). Here, the RR_Req includes service flow information (SF info with ROHC) for ROHC.

In one embodiment, the service flow information included in the RR_Req may have a Reservation Action TLV requesting deletion of a service flow for ROHC.

Next, the serving SFA 112b checks whether a data path should be generated. If the data path is generated, the serving SFA 112b transmits Path_Reg_Req including the received QoS information TLV to the SFM 119 of the base station 118 (S1110).

In one embodiment, the service flow information included in the Path_Reg_Req may have a Reservation Action TLV requesting deletion of a service flow for ROHC.

Next, the SFM 119 identifies the radio resource and determines whether to accept the service flow deletion request for ROHC based on the QoS information (QoS-Info) parameter and available resources. The base station 118 transmits a DSD-REQ message corresponding to IEEE 802.16e to the SS 120 (S1112).

Next, the UE 120 determines whether to permit deletion of a service flow for ROHC according to DSD-REQ according to IEEE 802.16e, and transmits a DSD response message (DSD-RSP) to the SFM 119 (S1114).

Next, the SFM 119 transmits Path_Reg_Rsp to the serving SFA 112b to confirm the reservation (S1116). If resources reduced by the SFM 119 are granted, Path_Reg_Rsp MUST include a set of granted QoS parameters.

Next, when there is a successful response from the SFM 119, the serving SFA 112b transmits the RR_Rsp including the QoS information parameter to the anchor SFA 112a for confirmation of reservation (S1118).

Next, the serving SFA 112b transmits Path_Reg_Ack to the SFM 119 (S1120).

Thereafter, when there is a successful response from the serving SFA 112b, the anchor SFA 112a transmits RR_Ack to the serving SFA 112b (S1122), and the PDF sends an ACK (indicating acceptance or rejection of the PCC decision to the PCRF 106) Message is transmitted (S1124).

Finally, the PCRF 106 stores the service information and transmits an ACK message to the AF 103 (S1126).

The ROHC channel negotiation method described above can be implemented in the form of a program command that can be executed through various computer means and recorded on a computer-readable recording medium. At this time, the computer-readable recording medium may include program commands, data files, data structures, and the like, alone or in combination. On the other hand, the program instructions recorded on the recording medium may be those specially designed and configured for the present invention or may be available to those skilled in the art of computer software.

The computer-readable recording medium includes a magnetic recording medium such as a magnetic medium such as a hard disk, a floppy disk and a magnetic tape, an optical medium such as a CD-ROM and a DVD, a magnetic disk such as a floppy disk, A magneto-optical media, and a hardware device specifically configured to store and execute program instructions such as ROM, RAM, flash memory, and the like. The recording medium may be a transmission medium, such as a light or metal line, a wave guide, or the like, including a carrier wave for transmitting a signal designating a program command, a data structure, and the like.

The program instructions also include machine language code, such as those generated by the compiler, as well as high-level language code that can be executed by a computer using an interpreter or the like. The hardware devices described above may be configured to operate as one or more software modules to perform the operations of the present invention, and vice versa.

It will be understood by those skilled in the art that the present invention can be embodied in other specific forms without departing from the spirit or essential characteristics thereof.

It is therefore to be understood that the above-described embodiments are illustrative in all aspects and not restrictive. The scope of the present invention is defined by the appended claims rather than the detailed description and all changes or modifications derived from the meaning and scope of the claims and their equivalents are to be construed as being included within the scope of the present invention do.

Claims (3)

A service flow acknowledgment unit receiving a subscriber profile including an ROHC policy from AAA or PCRF, generating and distributing a classification rule for ROHC, and triggering ROHC channel negotiation with a terminal related to the subscriber profile;
An ROHC function unit performing ROHC channel negotiation with the terminal by exchanging ROHC per channel parameters with the terminal; And
And a data path management unit for transmitting the downlink packet to the ROHC functional unit when the downlink packet is required to be applied to the ROHC, and for forwarding the uplink packet to the ROHC functional unit when the uplink packet is ROHC compressed . 2. The ROHC system as claimed in claim 1,
An ROHC compression unit for compressing the header of the downlink packet into an ROHC packet header; And
And an ROHC decompression unit for decompressing the header of the ROHC compressed UL packet into an IP packet header. 2. The data processing apparatus according to claim 1,
If the downlink packet belongs to the ROHC channel, the downlink packet is delivered to the ROHC compressor,
Encapsulates a data path tag between the UE and the BS in the downlink packet to which the ROHC is applied, and transmits the encapsulated data to the BS.

Images