KR20080097936A - Method of data processing in wireless communication system - Google Patents

Abstract

A data processing method is provided to classify types or features of data blocks delivered from a PDCP layer. A data processing method at a protocol layer including a header compression function in a wireless communication system comprises the following steps. At least one of a control packet, including control information, and a data packet, including at least a part of the upper layer data block delivered from an upper layer, is generated. A lower layer data block including the generated each packet is produced/transmitted to a lower layer. Instruction information related to a data processing method for the lower layer data block in the lower layer about is delivered to the lower layer.

Description

Data processing method in wireless communication system {Method of data processing in wireless communication system}

The present invention relates to a wireless communication system, and more particularly, to a data processing method in a wireless communication system.

1 is a diagram illustrating a network structure of an E-UMTS. The E-UMTS system is an evolution from the existing WCDMA UMTS system and is currently being standardized by the 3rd Generation Partnership Project (3GPP). E-UMTS is also called a Long Term Evolution (LTE) system.

Referring to FIG. 1, an E-UTRAN consists of base stations (hereinafter, abbreviated as 'eNode B' or 'eNB'). The eNBs are connected via an X2 interface. The eNB is connected to a user equipment (hereinafter abbreviated as UE) through an air interface and is connected to an Evolved Packet Core (EPC) through an S1 interface. The EPC includes a Mobility Management Entity (MME) / System Architecture Evolution (SAE) gateway.

Layers of the radio interface protocol between the terminal and the network are based on the lower three layers of the Open System Interconnection (OSI) reference model, which is widely known in communication systems. And L2 (second layer) and L3 (third layer), wherein the physical layer belonging to the first layer provides an information transfer service using a physical channel. The Radio Resource Control (RRC) layer located in the third layer serves to control radio resources between the UE and the network. To this end, the RRC layer exchanges RRC messages between the UE and the network. The RRC layer may be distributed to network nodes such as Node B and AG, or may be located independently of Node B or AG.

2 is a schematic diagram of an Evolved Universal Terrestrial Radio Access Network (E-UTRAN). In FIG. 2, the hatched portion shows the functional entities of the user plane and the unhatched portion shows the functional entities of the control plane.

3A and 3B illustrate a structure of a radio interface protocol between a UE and an E-UTRAN. FIG. 3A is a control plane protocol configuration diagram and FIG. 3B is a user plane protocol configuration diagram. . The air interface protocols of FIGS. 3A and 3B are horizontally composed of a physical layer, a data link layer, and a network layer, and vertically a user plane for transmitting data information. It is divided into User Plane and Control Plane for Signaling. The protocol layers of FIGS. 3A and 3B are based on the lower three layers of the Open System Interconnection (OSI) reference model, which are well known in communication systems, based on L1 (first layer), L2 (second layer), It may be classified as L3 (third layer).

The physical layer, which is the first layer, provides an information transfer service to an upper layer by using a physical channel. The physical layer is connected to the upper medium access control layer through a transport channel, and data between the medium access control layer and the physical layer moves through the transport channel. Then, data is moved between different physical layers, that is, between physical layers of a transmitting side and a receiving side through physical channels. In E-UMTS, the physical channel is modulated by an orthogonal frequency division multiplexing (OFDM) scheme, thereby utilizing time and frequency as radio resources.

The medium access control (hereinafter, referred to as MAC) layer of the second layer provides a service to a radio link control layer, which is a higher layer, through a logical channel. The Radio Link Control (hereinafter referred to as RLC) layer of the second layer supports reliable data transmission. The PDCP layer of the second layer performs a header compression function to reduce unnecessary control information in order to efficiently transmit data transmitted using an IP packet such as IPv4 or IPv6 in a relatively low bandwidth wireless section. .

The radio resource control layer (hereinafter referred to as RRC) layer located at the bottom of the third layer is defined only in the control plane, and the configuration and resetting of the radio bearer (abbreviated as RB) are performed. It is responsible for the control of logical channels, transport channels and physical channels in relation to configuration and release. In this case, RB means a service provided by the second layer for data transmission between the terminal and the UTRAN.

Hereinafter, the PDCP layer included in the second layer will be described in detail.

The PDCP layer is connected to the RRC layer or the user application layer as its upper layer, and is connected to the RLC layer as its lower layer. The main functions performed by the PDCP layer are header compression and security. The header compression function is used to improve the efficiency of radio resources. The amount of information that needs to be transmitted from the radio side is increased by using a lot of common contents in the packets transmitted through one internet packet stream. Brings the effect of reducing. Security features include ciphering and integrity checks, which are used to prevent data manipulation or interception by third parties.

Among header compression schemes used in the PDCP layer, Robust Header Compression (ROHC) is used to reduce header information of a Real-time Transport Protocol (RTP) / User Datagram Protocol (UDP) / IP (Internet Protocol) packet. Header compression techniques include RFC2507 in addition to ROHC.

The ROHC technique is based on the fact that the field value of each packet header is almost constant in consecutive packets belonging to one packet stream. Therefore, the ROHC scheme transmits a variable field rather than transmitting the entire field included in the packet header. For reference, the total header size of uncompressed RTP / UDP / IP packets is 40 octets for IPv4 (IP version 4) and 60 octets for IPv6 (IP version 6), whereas payload The size of a pure data portion called) is typically 15 to 20 octets. Therefore, since the control information is much larger than the actual user data to be transmitted, it can be seen that the transmission efficiency is very low. Therefore, if the header compression technique is used, the amount of control information can be greatly reduced. For example, the header size reduced by the ROHC technique is usually only about 1 to 3 octets.

ROHC techniques are largely uni-directional mode (hereinafter abbreviated as' U-mode '), Bi-directional Optimistic mode (hereinafter abbreviated as' O-mode') and Bi-directional reliable mode (hereinafter referred to as' R- abbreviated as 'mode'). In the U-mode, the unidirectional communication is performed from the transmitting side to the receiving side, and in the O-mode or R-mode, the bidirectional communication is performed so that the transmitting side transmits a real time packet and the receiving side transmits transmission status information to the transmitting side. Accordingly, the ROHC schemes of the O-mode and R-mode control the transmission of real-time traffic packets by receiving ROHC status information (ACK or NACK) from the receiving side in the reverse direction as well as transmitting header compression packets of data. The ROHC status information transmitted from the receiving side to the transmitting side may be used for different purposes depending on the mode. O-mode mainly sends NACK-related information to increase compression efficiency, and R-mode supports more robust header compression techniques using strict logic using ROHC state information. The ROHC state information may be referred to as feedback information in the header compression process. In addition to ROHC, other head compression techniques use feedback information.

Looking more closely at the U-mode of the ROHC techniques, the compressor has three states: full context formation state, dynamic context formation state, and full context complete state. The types of compressed header packets that can be transmitted are different for each state, and operation methods are also different. First, look at the structure of the context, which consists of a static context and a dynamic context.

4 is a view for explaining the state of the ROHC U-mode compressor and its transition process according to the prior art. Referring to FIG. 4, the entire context formation state means a state in which no entire context is formed or the entire context is completely damaged and needs to be reconfigured. The dynamic context formation state refers to a state in which a dynamic context part of the entire context is damaged and needs to be reconstructed, and the entire context complete state literally means a complete state without damage. Each state transitions to a different state every cycle. At this time, each cycle is different. For example, the transition period from the full context complete state to the full context formed state is much greater than the transition period from the full context complete state to the dynamic context formed state.

The data block generated in the PDCP layer according to the prior art as described above may be classified into various types according to whether data included in the data block is data transmitted from a higher layer or data generated by the PDCP layer itself. . Meanwhile, according to the type of each data block generated in the PDCP layer, there is a need for different data processing methods in a lower layer that receives data blocks from the PDCP layer and performs data processing. Therefore, in order to improve data processing efficiency from a lower layer's point of view, a method capable of distinguishing types or features of data blocks transmitted from the PDCP layer is required.

The present invention has been made in accordance with the necessity as described above, and an object of the present invention is to provide a method for efficiently processing data in a wireless communication system.

A data processing method according to an aspect of the present invention is a data processing method in a protocol layer having a header compression function in a wireless communication system, comprising: a control packet including control information and a higher layer data block transferred from a higher layer Generating at least one of a data packet including at least a portion, generating and transferring a lower layer data block including each generated packet to a lower layer, and at the lower layer for the lower layer data block And delivering the indication information related to the data processing method of the lower layer.

A data processing method according to another aspect of the present invention is a data processing method at a transport side protocol layer of a wireless communication system, comprising: a higher layer data block including a control packet including control information or a compressed packet in which header compression is performed Receiving from the upper layer, receiving instruction information related to a data processing method for the upper layer data block from the upper layer, and performing data processing for the upper layer data block according to the indication information. It may comprise a step.

According to the present invention, there is an effect that can efficiently use radio resources in a wireless communication system.

The construction, operation, and other features of the present invention will be readily understood by the embodiments of the present invention described with reference to the accompanying drawings.

FIG. 5 is a diagram functionally illustrating entities included in a transmitting side and a receiving side PDCP layer of an E-UMTS system. Although FIG. 5 illustrates one entity corresponding to each function performed in the PDCP layer, two or more entities may be combined to form one entity.

Referring to FIG. 5, the transmitting PDCP layer receives higher layer data, that is, a PDCP SDU (Service Data Unit) from an upper layer such as an RRC or an application layer. The upper layer data received from the RRC layer is signaling information of a control plane for performing a function of the RRC layer, and the upper layer data received from the application layer is data of a user plane.

The SN assignment entity 11 assigns a sequence number (SN) to the PDCP SDU received from the higher layer. The header compression entity 12 performs a header compression function on the data of the user plane transmitted from the upper layer, that is, the PDCP SDU. As described above, the header compression entity 12 may use the ROHC technique as a compression scheme, and based on the fact that the field values of each packet header are substantially constant in consecutive packets belonging to one packet stream, Constructs a header that contains only some of the fields contained in the. However, the header compression is not performed for all PDCP SDUs, but transmits a full header that is not header compressed periodically to the receiver. The receiving side reconstructs the compressed headers based on the entire received headers. The header compression function is not applied to higher layer data received from the RRC layer.

Meanwhile, the header compression entity 12 generates a control packet that is not related to the PDCP SDU received from the higher layer, that is, does not include higher layer data. The control packet includes control information generated by the header compression entity as related to the performance of the PDCP layer. Examples of the control information may include feedback information or status information on the PDCP PDU transmitted from the receiver. The feedback information includes information related to header compression of a PDCP PDU transmitted from the receiving side. The status information may include information on whether a PDCP PDU transmitted from the receiving side has been successfully received or needs retransmission. The control information may include other control information in addition to the feedback information or the state information.

FIG. 6 is a diagram for describing a process in which control information is generated in the header compression entity 12 and transmitted to a receiving side.

Referring to FIG. 6, the first control information B is transmitted from left to right, which is response information such as feedback information or status information on a compressed packet stream transmitted from right to left, that is, 'Stream C'. information). The second control information D is transmitted from right to left, which is response information about a compressed packet stream transmitted from left to right, that is, 'Stream A'. In other words, 'Stream A' is a flow of packets in which PDCP SDUs received through 'Point E' are compressed and transmitted, but the first control information B transmitted in the same direction is received through 'Point E'. It is not related to PDCP SDUs, but rather to the flow of packets that are delivered to the PDCP layer via Point F and connected to Stream C. That is, the first and second control information is information related to the management of the context information. Therefore, the control information is information generated regardless of the PDCP SDU received from the higher layer from the perspective of the transmitting PDCP layer. Accordingly, a serial number is not assigned by the SN assignment entity.

Referring back to FIG. 5, the integrity check entity 13 performs integrity protection on a PDCP SDU including control plane data, that is, a PDCP SDU received from the RRC layer. The integrity check may be performed by attaching a field called Message Authentication Code for Integrity Protection (MAC-I) to the DPCP PDU to be transmitted.

The encryption entity 14 performs ciphering on the compressed packet in which header compression is performed on the header compression entity 12 and the RRC message in which integrity protection is performed by the integrity checking entity 13. The data before encryption (PLAINTEXT BLOCK) is encrypted through bit operations with encryption parameters and MASK generated by a specific encryption algorithm to form a CIPHERTEXT BLOCK. The CIPHERTEXT BLOCK is transmitted to the receiver through the radio section, and the receiving side recovers the original PLAINTEXT BLOCK by generating and decrypting the same MASK through the encryption algorithm used at the transmitter. As the encryption algorithm, in addition to the f8 algorithm used in 3GPP, various conventional methods may be used. The encryption parameters mean CK, COUNT-C, BEARER, DIRECTION, LENGTH, etc. Among the parameters, CONUNT-C is a value related to the sequence number of the PDCP SDU on which encryption is performed and changes over time. . In Fig. 5, control packets to which no serial number is assigned are not encrypted.

The header adding entity 15 generates a PDCP PDU by adding a PDCP header to the data block received from the header compression entity 12 or the encryption entity 14. The generated PDCP PDUs can be classified into three types. The first is a PDCP PDU including upper layer data of a control plane received from the RRC layer. The second is a PDCP PDU including upper layer data of a user plane received from an upper layer application layer. Third is a PDCP PDU containing a control packet generated by the header compression entity 12. Each type of PDCP PDU includes a different header according to an embodiment of the present invention. As shown in FIG. 5, encryption by the encryption entity 14 is performed before header addition, so encryption is not performed on the header of the PDCP PDU regardless of the type of PDCP PDU.

FIG. 7 is a diagram illustrating an embodiment of a data format of a PDCP PDU including upper layer data of a control plane. As described above, after the upper layer data of the control plane, that is, the control information transmitted from the RRC layer, a serial number is assigned by the SN allocation entity 11 of FIG. 5, the integrity check entity 13 Integrity protection is performed. Therefore, the header of the PDCP PDU shown in FIG. 7 includes a PDCP SN field including a serial number. 'R' field means a reserved bit. The MAC-I field contains a message authentication code added by the integrity check entity 13 for integrity protection.

8 is a diagram illustrating an embodiment of a data format of a PDCP PDU including upper layer data of a user plane. The header of the PDCP PDU of FIG. 8 includes a D / C field and a PDCP SN field. The D / C field includes information indicating whether the corresponding PDCP PDU includes user data or control information. In FIG. 8, the D / C field includes an indicator indicating that the corresponding PDCP PDU includes user data.

9A and 9B illustrate an embodiment of a data format of a PDCP PDU including control information generated in a PDCP layer, not received from a higher layer, and each includes different types of control information. Doing. The PDCP PDUs of FIGS. 9A and 9B commonly include a D / C field and a PDU Type field. The D / C field includes an indicator indicating that the corresponding PDCP PDU includes control information. The PDU Type field includes information indicating the type of control information included in a corresponding PDCP PDU. 9A and 9B include different types of control information, so each PDU Type field includes different information. Accordingly, the receiver may determine what kind of control information is included in the corresponding PDCP PDU using the information included in the PDU Type field.

Control information included in the PDCP PDU of FIG. 9A is an interspersed ROHC feedback packet. The intermittent ROHC feedback packet is a packet generated by the header compression entity of FIG. 5 and is independent of the PDCP SDU transmitted from the upper layer and includes feedback information on the PDCP PDU transmitted from the receiver. Information included in the PDCP PDU of FIG. 9B includes information indicating success or failure of reception of a plurality of PDCP PDUs transmitted from a receiver as status report information. For example, the status report information may include in a bitmap format whether a plurality of PDCP PDUs transmitted from the receiving side have been successfully received. In addition to the control information included in the PDCP PDUs shown in FIGS. 9A and 9B, when there are other types of control information generated in the PDCP PDU layer, a PDCP PDU including such control information may be configured, and in the header of the corresponding PDCP PDU. The included PDU Type fields may be distinguished from each other by including different information from the PDU Type fields included in the PDCP PDUs of FIGS. 9A and 9B. An example of another kind of control information generated in the PDCP layer may include status report information for indicating acknowledgment information of PDCP SDUs after performing handover.

Referring back to FIG. 5, each PDCP PDU generated in the PDCP layer is delivered to an RLC layer, which is a lower layer. In addition, the PDCP layer delivers indication information related to the data processing method in the RLC layer for each PDCP PDU to the RLC layer. The indication information may be included in a specific primitive used for information exchange between the PDCP layer and the RLC layer, and may be transferred from the PDCP layer to the RLC layer. Meanwhile, the indication information may be included in a corresponding PDCP PDU in the PDCP layer, for example, in a specific field of a header of the PDCP PDU, and transmitted to the RLC layer.

The indication information is information related to a data processing method in the RLC layer for each PDCP PDU, and indicates whether the corresponding PDCP PDU can be segmented in the RLC layer and included in different data blocks, that is, RLC PDUs. Segmentation information, connection information indicating whether the corresponding PDCP PDU is concatenated with other PDCP PDUs in the RLC layer and included in one RLC PDU, and whether the corresponding PDCP PDU includes a control packet or a compressed packet. It may include at least one or more of the information indicating, the type information indicating the type (type) of the PDCP PDU and the delivery information indicating whether the PDCP PDU is emergency data or non-emergency data.

In FIG. 5, the RLC layer performs data processing according to the indication information on one or more PDCP PDUs (RLC SDUs) received from the PDCP layer. The RLC layer can be divided into three modes. The first mode is the TM mode (transparent mode), the TM RLC entity performs the function of delivering to the lower layer without performing a separate data processing for the RLC SDU delivered from the PDCP layer. The second mode is an unacknowledged mode, and the UM RLC entity performs functions such as splitting / concatenating RLC SDUs and generating RLC PDUs through header addition. The third mode is an AM mode, which performs functions related to retransmission of the RLC SDU in addition to the function of the UM mode. The RLC layer shown in FIG. 5 is an example of configuration of a UM RLC entity.

In FIG. 5, the transmit buffer 16 stores the PDCP PDUs (RLC SDUs) that the upper layer carries from the PDCP layer. The segmentation / connection entity 17 segments the RLC SDUs output from the transmission buffer 16 as necessary or concatenates two or more RLC SDUs. The RLC header addition entity 18 adds an RLC header to the RLC SDU partitioned or concatenated by the partition / concatenation entity 17 to generate an RLC PDU. The generated RLC PDU is delivered to the lower layer. The TM RLC entity has only a transmit buffer, and the AM RLC entity has a retransmission buffer and an RLC control entity in addition to the components of the UM RLC entity.

Hereinafter, specific methods of performing data processing on the PDCP PDU according to the indication information received from the PDCP layer will be described.

When the indication information includes partitioning information indicating that the PDCP PDU received from the PDCP layer can be split, the partitioning / connection entity 17 of the RLC layer splits the corresponding PDCP PDU into two or more. The RLC header addition entity 18 adds an RLC header to each partitioned portion to generate an RLC PDU. If the indication information includes partition information indicating that the PDCP PDU received from the PDCP layer cannot be split, the RLC layer does not split the corresponding PDCP PDU.

When the indication information includes connection information indicating that the PDCP PDU received from the PDCP layer can be included in one RLC PDU in connection with another PDCP PDU in the RLC layer, the partitioning / connection entity 17 of the RLC layer Associates the corresponding PDCP PDU with one or more PDCP PDUs, and the RLC header addition entity 18 adds a header to the connected PDCP DPUs to generate one RLC PDU. If the indication information includes connection information indicating that the PDCP PDU received from the PDCP layer is connected to another PDCP PDU in the RLC layer and cannot be included in one RLC PDU, the RLC layer may associate the PDCP PDU with another PDCP PDU. Create an RLC PDU with the corresponding PDCP PDU without connection. In this case, if there is extra space in the corresponding RLC PDU, it may be filled with padding.

In determining whether to split or connect a specific PDCP PDU, the type of the corresponding PDCP PDU may be considered. For example, if the PDCP PDU contains a compressed packet, split it or allow it to be associated with another PDCP PDU containing the compressed packet, and if the PDCP PDU contains a control packet or other control information, perform the split or concatenation. It can be included in one RLC PDU. When two or more PDCP PDUs including a compressed packet are connected and included in one RLC PDU, a serial number of another PDCP PDU may be omitted except for a serial number SN included in a header of one PDCP PDU. Meanwhile, according to the prior art, a separate serial number is added to the header of the RLC PDU. Since the serial number is also included in the header of the PDCP PDU included in the RLC PDU, the serial number may be omitted from the header of the RLC PDU.

If the indication information indicates information indicating whether the PDCP PDU received from the PDCP layer includes a control packet or a compression packet or type information indicating a type of the corresponding PDCP PDU, the RLC layer indicates that the PDCP According to the type of the PDU, a data processing process preset for the corresponding PDCP PDU is performed. For example, PDCP PDUs containing control information or control packets can be set to not perform partitioning or concatenation, or PDCP PDUs containing compressed packets can be set to perform partitioning or concatenation as necessary. have. As another example, a PDCP PDU including control information or a control packet may not be divided, but may be configured to connect with another PDCP PDU.

When the indication information includes delivery information indicating that the PDCP PDU received from the PDCP layer is emergency data, the RLC layer may immediately transmit the corresponding PDCP PDU to a lower layer without performing a separate data processing process. If the indication information includes delivery information indicating that the PDCP PDU received from the PDCP layer is non-emergency data, the RLC layer delivers the PDCP PDU to a lower layer after a predetermined data processing process.

When the RLC header adding entity 18 of the RLC layer generates an RLC PDU by adding an RLC header to the RLC SDU, the RLC header includes at least one indicator for informing information related to the characteristics of the RLC SDU. Can be. For example, the indicator may indicate the type of PDCP PDU included in the RLC PDU, that is, whether the corresponding PDCP PDU includes a control packet or control information or a compressed packet. In addition, the indicator may indicate whether the control packet is RoHC feedback information or status report information when the PDCP PDU includes a control packet. As another example, the indicator may indicate whether the RLC SDU included in the corresponding RLC PDU includes information generated in the RLC layer or information related to the PDCP layer. Alternatively, the indicator may indicate whether the RLC SDU included in the corresponding RLC PDU includes information related to the PDCP SDU or information not related to the PDCP SDU.

In another embodiment, when the RLC header addition entity 18 of the RLC layer generates an RLC PDU by adding an RLC header to an RLC SDU, whether the serial number is included in the RLC header or the corresponding RLC PDU is included. An indicator indicating whether a serial number is included in the PDCP PDU included in the RLC PDU or whether the PDCP PDU included in the RLC PDU is related to a specific serial number may be included. As another example, the RLC PDU may include an indicator indicating whether the PDCP PDU included in the RLC PDU is prohibited from splitting or whether the PDCP PDU should be immediately delivered to the PDCP layer of the receiver. As another example, the RLC PDU may include an indicator indicating whether the PDCP PDU included in the RLC PDU is a full packet.

The RLC layer of the receiving side may change the data processing procedure according to at least one or more indicators included in the header of the RLC PDU transmitted from the transmitting side. For example, when the at least one indicator indicates that the PDCP PDU included in the RLC PDU includes control information or a control packet, or indicates that the PDCP PDU includes a full packet, the RLC layer of the receiving side. The PDCP may set the PDCP PDU to be delivered to the upper layer regardless of the serial number order. Even when the at least one indicator indicates that the PDCP PDU included in the RLC PDU should be immediately delivered to the upper layer, the RLC layer immediately delivers the PDCP PDU to the upper layer regardless of the serial number.

The embodiments described above are the components and features of the present invention are combined in a predetermined form. Each component or feature is to be considered optional unless stated otherwise. Each component or feature may be embodied in a form that is not combined with other components or features. It is also possible to combine some of the components and / or features to form an embodiment of the invention. The order of the operations described in the embodiments of the present invention may be changed. Some components or features of one embodiment may be included in another embodiment or may be replaced with corresponding components or features of another embodiment. It is obvious that the claims may be combined to form an embodiment by combining claims that do not have an explicit citation relationship in the claims or as new claims by post-application correction.

Embodiments according to the present invention may be implemented by various means, for example, hardware, firmware, software, or a combination thereof. In the case of a hardware implementation, an embodiment of the present invention may include one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), FPGAs ( field programmable gate arrays), processors, controllers, microcontrollers, microprocessors, and the like.

In the case of an implementation by firmware or software, the data processing method in the wireless communication system according to an embodiment of the present invention may be implemented in the form of a module, procedure, function, etc. that performs the functions or operations described above. The software code may be stored in a memory unit and driven by a processor. The memory unit may be located inside or outside the processor, and may exchange data with the processor by various known means.

It is apparent to those skilled in the art that the present invention can be embodied in other specific forms without departing from the spirit and essential features of the present invention. Accordingly, the above detailed description should not be construed as limiting in all aspects and should be considered as illustrative. The scope of the invention should be determined by reasonable interpretation of the appended claims, and all changes within the equivalent scope of the invention are included in the scope of the invention.

The present invention is applicable to a wireless communication system such as a mobile communication system, a wireless internet system, and the like.

1 is a diagram illustrating a network structure of an E-UMTS.

2 is a schematic diagram of an Evolved Universal Terrestrial Radio Access Network (E-UTRAN).

3A and 3B illustrate a structure of a radio interface protocol between a UE and an E-UTRAN. FIG. 3A is a control plane protocol configuration diagram and FIG. 3B is a user plane protocol configuration diagram. .

4 is a view for explaining the state of the ROHC U-mode compressor and its transition process according to the prior art.

FIG. 5 is a diagram functionally illustrating entities included in a transmitting PDCP layer and an RLC layer of an E-UMTS system.

FIG. 6 is a diagram for describing a process in which control information is generated in the header compression entity of FIG. 5 and transmitted to a receiving side.

FIG. 7 is a diagram illustrating an embodiment of a data format of a PDCP PDU including upper layer data of a control plane.

8 is a diagram illustrating an embodiment of a data format of a PDCP PDU including upper layer data of a user plane.

9A and 9B illustrate an embodiment of a data format of a PDCP PDU including control information generated in a PDCP layer, not received from a higher layer.

Claims (19)

A data processing method in a protocol layer having a header compression function in a wireless communication system, Generating at least one of a control packet including control information and a data packet including at least a portion of an upper layer data block transferred from an upper layer; Generating a lower layer data block including each generated packet and delivering the lower layer data block to the lower layer; And Passing indication information related to a data processing method in the lower layer to the lower layer data block to the lower layer. The method of claim 1, And the indication information is information indicating whether the lower layer data block may be divided in the lower layer and included in different data blocks. The method of claim 1, And the indication information is information indicating whether the lower layer data block is connected to another lower layer data block in the lower layer to be included in one data block. The method of claim 1, And the indication information is information indicating a type of the lower layer data block. The method of claim 1, And the indication information is information indicating whether the lower layer data block includes a control packet or a data packet. The method of claim 1, And the indication information is information indicating whether the lower layer data block is emergency data or non-emergency data. The method of claim 1, And the control information is header compression feedback information related to a block of data transmitted from a receiving side. The method of claim 1, And the control information is status information on a data block transmitted from a receiving side. The method of claim 1, And wherein the data packet is generated by performing header compression on the upper layer data block. The method of claim 9, And the control packet is generated by an entity that performs the header compression function. A data processing method in a transport side protocol layer of a wireless communication system, Receiving an upper layer data block including a control packet including control information or a compressed packet in which header compression is performed, from an upper layer; Receiving indication information related to a data processing method for the upper layer data block from the upper layer; And And performing data processing on the upper layer data block according to the indication information. The method of claim 11, The indication information is information indicating whether the upper layer data block is divided in the protocol layer and may be included in different data blocks. The method of claim 11, And the indication information is information indicating whether the higher layer data block can be included in one data block in connection with another higher layer data block in the protocol layer. The method of claim 11, And the indication information is information indicating a type of the higher layer data block. The method of claim 11, And the indication information is information indicating whether the upper layer data block includes the control packet or the compressed packet. The method of claim 11, And the indication information is information indicating whether the upper layer data block is emergency data or non-emergency data. The method of claim 11, And the control information is header compression feedback information related to a block of data transmitted from a receiving side. The method of claim 11, And the control information is status information on a data block transmitted from a receiving side. The method of claim 11, And the control packet is generated by an entity that performs a header compression function.

Images