Title of Invention	A METHOD FOR QOS GUARANTEES IN A MULTILAYER STRUCTURE
Abstract	A method in which a user equipment processes data in a wireless mobile communication system is provided. The method includes the steps of receiving a first data block from an upper layer, transferring a second data block including the first data block to a lower layer at a particular protocol layer, discarding the first and second data blocks present in the particular protocol layer if a certain period of time has passed, and transferring information associated with the discard of the second data block to the lower layer.

Title of Invention

A METHOD FOR QOS GUARANTEES IN A MULTILAYER STRUCTURE

Abstract

A method in which a user equipment processes data in a wireless mobile communication system is provided. The method includes the steps of receiving a first data block from an upper layer, transferring a second data block including the first data block to a lower layer at a particular protocol layer, discarding the first and second data blocks present in the particular protocol layer if a certain period of time has passed, and transferring information associated with the discard of the second data block to the lower layer.

Full Text	A METHOD FOR QoS GUARANTEES IN A MULTILAYER STRUCTURE TECHNICAL FIELD The present invention relates to a wireless mobile communication system, and more particularly, to a method in which a terminal (or user equipment) processes data in a wireless mobile communication system. BACKGROUND ART A radio protocol based on the 3rd Generation Partnership Project (3GPP) radio access network standard is divided into a first (LI) layer, a second (L2) layer, and a third (L3) layer based on the lower three layers of the Open System Interconnection (OSI) reference model. The second layer of the radio protocol includes a Medium Access Control (MAC) layer, a Radio Link Control (RLC) layer and a Packet Data Convergence Protocol (PDCP) layer. The third layer includes a Radio Resource Control (RRC) layer at the bottom of the third layer. The RLC layer is responsible for guaranteeing Quality of Service (QoS) of each Radio Bearer (RB) and performing data transmission according to the QoS. The RLC layer includes one or two RLC entities for each RB in order to guarantee QoS specific to the RB. The RLC layer also provides three RLC modes, a Transparent Mode (TM), an Unacknowledged Mode (UM), and an Acknowledged Mode (AM), in order to support various QoS. The PDCP layer is located above the RLC layer and can perform header compression on data transmitted using IP packets such as IPv4 or IPv6 packets. The PDCP layer is present only in a packet-switched domain and includes one PDCP entity per RB. The RRC layer sets a variety of operating methods, parameters, and characteristics of channels associated with the first and second layers of the radio protocol in order to satisfy QoS. Specifically, the RRC layer determines which header compression method would be used at the PDCP layer and determines an operating mode, a RLC PDU size, and values of various protocol parameters which are used for the RLC layer. DISCLOSURE OF THE INVENTION TECHNICAL PROBLEM QoS is the quality of services transmitted and received through a wireless mobile communication system. Typical factors that affect QoS include delay, error ratio, and bitrate. QoS of a service is determined appropriately according to the type of the service. In the case of real-time services such as VoIP or streaming services using a wireless mobile communication system, problems such as video interruption or audio distortion occur if transfer delay is significant. That is, even though data is received by the counterpart, the quality is lowered if it takes more than a specific time to transfer the data to the counterpart. Indeed, data received after a specific time has elapsed is mostly not used by an application. Accordingly, attempting to transmit a data block, whose transfer time has exceeded the allowed transfer time, or storing such a data block causes overhead and waste of resources. The following is a more detailed description with reference to the PDCP layer. Data units received from the outside of the L2 layer are stored in a buffer of the PDCP layer. The data units are stored in the PDCP layer until they are received by the counterpart. However, if transmission of data blocks associated with a PDCP SDU is delayed at a lower layer, the time duration during which the PDCP SDU must stay in the buffer of the PDCP layer increases. Specifically, the capacity of the buffer may become insufficient if the amount of data is large, if data is constantly received from the outside, or if transmission of some PDCP SDUs is kept delayed. Especially, if the buffer is full, new data received from the outside is immediately discarded since there is no space in which to store the new data. This directly affects the QoS. An object of the present invention devised to solve the above problems of the conventional technologies lies in providing a data processing method that guarantees Quality of Service (QoS) and efficiently manages data in a wireless mobile communication system which uses a multilayer structure. Another object of the present invention devised to solve the problem lies in providing a method in which a specific protocol layer of a User Equipment (UE) or a base station decides data to be discarded (or deleted) and instructs a lower layer to discard the data. A further object of the present invention devised to solve the problem lies in providing a method in which a lower layer discards data when a specific protocol layer of a UE or a base station has instructed the lower layer to discard the data. Objects of the present invention are not limited to those described above and other objects will be clearly understood by those skilled in the art from the following description. TECHNICAL SOLUTION In one aspect of the present invention, provided herein is a method of processing data by a user equipment in a wireless mobile communication system, the method including the steps of receiving a first data block from an upper layer; transferring a second data block including the first data block to a lower layer at a particular protocol layer; discarding the first and second data blocks present in the particular protocol layer if a certain period of time has passed; and transferring information associated with the discard of the second data block to the lower layer. Preferably, the upper layer is a RRC layer. Preferably, the lower layer is a RLC layer. Preferably, the specific protocol layer is a PDCP layer. In another aspect of the present invention, provided herein is a method of processing data by a user equipment or a base station in a wireless mobile communication system, the method including the steps of operating a timer for a first data block at a particular protocol layer when receiving the first data block from an upper layer; transferring a second data block including the first data block to a lower layer at a particular protocol layer; discarding the first and second data blocks present in the particular protocol layer if the timer expires; and transferring information associated with the discard of the second data block to the lower layer. Preferably, the upper layer is a RRC layer. Preferably, the lower layer is a RLC layer. Preferably, the specific protocol layer is a PDCP layer. In another aspect of the present invention, provided herein is a method of processing data by a user equipment or a base station in a wireless mobile communication system, the method including the steps of receiving a data block from an upper layer, receiving an instruction to discard the data block from the upper layer, and discarding the data block at a particular protocol layer if no part of the data block has been transmitted. ADVANTAGEOUS EFFECTS Embodiments of the present invention have the following advantages. First, it is possible to guarantee QoS and to efficiently manage data in a wireless mobile communication system which uses a multilayer structure. Second, a specific protocol layer of a User Equipment (UE) or a base station can decide data to be discarded (or deleted) and instruct a lower layer to discard the data. Third, a lower layer can discard data when a specific protocol layer of a UE or a base station has instructed the lower layer to discard the data. Advantages of the present invention are not limited to those described above and other advantages will be clearly understood by those skilled in the art from the following description. DESCRIPTION OF DRAWINGS The accompanying drawings, which are included to provide a further understanding of the invention, illustrate embodiments of the invention and together with the description serve to explain the principle of the invention. In the drawings: FIG. 1 illustrates a network structure of an E-UMTS. FIG. 2 illustrates a schematic structure of an Evolved Universal Terrestrial Radio Access Network (E- UTRAN). FIGs. 3A and 3B illustrate the configurations of a control plane and a user plane of a radio interface protocol between a UE and an E-UTRAN. FIG. 4 illustrates an example structure of a physical channel used in an E-UMTS system. FIG. 5 is a block diagram of a PDCP layer used in an E-UMTS system. FIG. 6 is a block diagram of an AM entity of a RLC layer used in an E-UMTS system. FIG. 7 illustrates example operations of a protocol layer performed at a UE or base station according to an embodiment of the present invention. FIG. 8 illustrates example operations of a protocol layer performed at a UE or base station according to another embodiment of the present invention. MODE FOR INVENTION The above and other configurations, operations, and features of the present invention will be easily understood from the embodiments of the invention described below with reference to the accompanying drawings. The embodiments described below are examples wherein technical features of the invention are applied to an Evolved Universal Mobile Telecommunications System (E-UMTS). FIG. 1 shows a network structure of the E-UMTS to which an embodiment of the present invention is applied. The E-UMTS system is an evolved version of the conventional WCDMA UMTS system and basic standardization thereof is in progress under the 3rd Generation Partnership Project (3GPP) . The E-UMTS is also referred to as a Long Term Evolution (LTE) system. For details of the technical specifications of the UMTS and E-UMTS, reference can be made to Release 7 and Release 8 of "3rd Generation Partnership Project; Technical Specification Group Radio Access Network". As shown in FIG. 1, the E-UMTS mainly includes a User Equipment (UE), base stations (or eNBs or eNode Bs), and an Access Gateway (AG) which is located at an end of a network (E-UTRAN) and which is connected to an external network. Generally, an eNB can simultaneously transmit multiple data streams for a broadcast service, a multicast service, and/or a unicast service. AGs can be divided into AGs responsible for processing user traffic and AGs responsible for processing control traffic. Here, an AG for processing new user traffic and an AG for processing control traffic can communicate with each other using a new interface. One or more cells are present for one eNB. An interface for transmission of user traffic or control traffic can be used between eNBs. A Core Network (CN) may include an AG and network nodes for user registration of UEs. An interface for discriminating between the E-UTRAN and the CN can be used. The AG manages mobility of a UE on a Tracking Area (TA) basis. One TA includes a plurality of cells. When the UE has moved from a specific TA to another TA, the UE notifies the AG that the TA where the UE is located has been changed. FIG. 2 illustrates a network structure of an Evolved Universal Terrestrial Radio Access Network (E-UTRAN) system which is a mobile communication system to which the embodiment of the present invention is applied. The E- UTRAN system is an evolved version of the conventional UTRAN system. The E-UTRAN includes base stations (eNBs), which are connected through X2 interfaces. Each eNB is connected to User Equipments (UEs) through a radio interface and is connected to an Evolved Packet Core (EPC) through an SI interface. FIGs. 3A and 3B illustrate the configurations of a control plane and a user plane of a radio interface protocol between a UE and a UMTS Terrestrial Ratio Access Network (UTRAN) based on the 3GPP radio access network standard. The radio interface protocol is divided horizontally into a physical layer, a data link layer, and a network layer and vertically into a user plane for data information transmission and a control plane for signaling. The protocol layers of FIGs. 3A and 3B can be divided into a Ll layer (first layer) , a L2 layer (second layer), and a L3 layer (third layer) based on the lower three layers of the Open System Interconnection (OSI) reference model widely known in communication systems. The control plane is a passage through which control messages that a UE and a network use in order to manage calls are transmitted. The user plane is a passage through which data (e.g., voice data or Internet packet data) generated at an application layer is transmitted. The following is a detailed description of the layers of the radio protocol control and user planes. The physical layer, which is the first layer, provides an information transfer service to an upper layer using a physical channel. The physical layer is connected to a Media Access Control (MAC) layer, located above the physical layer, through a transport channel. Data is transferred between the MAC layer and the physical layer through the transport channel. Data transfer between different physical layers, specifically between the respective physical layers of transmitting and receiving sides, is performed through the physical channel. The physical channel is modulated according to the Orthogonal Frequency Division Multiplexing (OFDM) method, using time and frequencies as radio resources. The MAC layer of the second layer provides a service to a Radio Link Control (RLC) layer, located above the MAC layer, through a logical channel. The RLC layer of the second layer supports reliable data transfer. The functions of the RLC layer may also be implemented through internal functional blocks of the MAC layer. In this case, the RLC layer need not be provided. A PDCP layer of the second layer performs a header compression function to reduce unnecessary control information in order to efficiently transmit IP packets such as IPv4 or IPv6 packets in a radio interval with a relatively narrow bandwidth. A Radio Resource Control (RRC) layer located at the bottom of the third layer is defined only in the control plane and is responsible for control of logical, transport, and physical channels in association with configuration, re-configuration and release of Radio Bearers (RBs). The RB is a service that the second layer provides for data communication between the UE and the UTRAN. To accomplish this, the RRC layer of the UE and the RRC layer of the network exchange RRC messages. The UE is in a RRC connected mode if a RRC connection has been established between the RRC layer of the radio network and the RRC layer of the UE. Otherwise, the UE is in a RRC idle mode. A Non-Access Stratum (NAS) layer located above the RRC layer performs functions such as session management and mobility management. One cell of the eNB is set to provide a bandwidth such as 1.25, 2.5, 5, 10, or 20MHz to provide a downlink or uplink transmission service to UEs. Here, different cells may be set to provide different bandwidths. Downlink transport channels for transmission of data from the network to the UE include a Broadcast Channel (BCH) for transmission of system information, a Paging Channel (PCH) for transmission of paging messages, and a downlink Shared Channel (SCH) for transmission of user traffic or control messages. User traffic or control messages of a downlink multicast or broadcast service may be transmitted through a downlink SCH and may also be transmitted through a downlink multicast channel (MCH). Uplink transport channels for transmission of data from the UE to the network include a Random Access Channel (RACH) for transmission of initial control messages and an uplink SCH for transmission of user traffic or control messages. Logical channels, which are located above the transport channels and are mapped to the transport channels, include a Broadcast Control Channel (BCCH), a Paging Control Channel (PCCH), a Common Control Channel (CCCH), a Multicast Control Channel (MCCH), and a Multicast Traffic Channel (MTCK). FIG. 4 illustrates an example of a physical channel structure used in an E-UMTS system. A physical channel includes a plurality of subframes on the time axis and a plurality of subcarriers on the frequency axis. Here, one subframe includes a plurality of symbols on the time axis. One subframe includes a plurality of resource blocks and one resource block includes a plurality of symbols and a plurality of subcarriers. Each subframe can use specific subcarriers of a specific symbol (e.g., a first symbol) of the subframe for a Physical Downlink Control Channel (PDCCH) (i.e., a L1/L2 control channel). A L1/L2 control information transmission region and a data transmission region are shown in FIG. 4. The Evolved Universal Mobile Telecommunications System (E-UMTS), which is currently under discussion, uses 10ms radio frames, each including 10 subframes. Each subframe includes two consecutive slots, each of which is 0.5ms long. One subframe includes multiple OFDM symbols. Some (for example, the first symbol) of the OFDM symbols can be used to transmit L1/L2 control information. A Transmission Time Interval (TTI), which is a unit time during which data is transmitted, is lms. The eNB and the UE transmit and receive most data other than a specific control signal or specific service data through a PDSCH which is a physical channel by using a DL-SCH which is a transport channel. Information indicating which PDSCH data is transmitted to a UE (one or a plurality of UEs) or how the UEs receive and decode PDSCH data is included in a PDSCH which is a physical channel, and then transmitted. For example, let us assume that a specific PDCCH has been CRC-masked with a Radio Network Temporary Identity (RNTI) "A" and an information associated with data to be transmitted is transmitted through a specific subframe by using a radio resource (e.g., a frequency position) "B" and a transmit format information (e.g., transmit block size, modulation scheme, coding information, etc) "C" . Under this assumption, one or more UEs in a cell monitor the PDCCH using their own RNTI information. And, if one or more specific UEs contain the RNTI ,VA", , the specific UEs read the PDCCH and receive a PDSCH indicated by "B" and "C" in the received PDCCH information at a corresponding time. FIG. 5 is a block diagram of a PDCP layer used in an E-UMTS system. This block diagram illustrates functional blocks that may differ from actual implementations. The PDCP layer is not limited to a specific implementation. As shown in FIG. 5, the PDCP layer is located at the top of the L.2 structure and is generally connected to a device such as a computer at an upper side of the PDCP layer and exchanges IP packets with the device. Accordingly, the PDCP layer is responsible for primarily storing IP packets received from the outside. A PDCP entity is connected to a RRC or a user application at an upper side of the PDCP entity and is connected to a RLC layer at a lower side of the PDCP entity. Data which the PDCP entity exchanges with an upper layer is referred to as a "PDCP SDU". One PDCP entity includes transmitting and receiving sides as shown in FIG. 5. The transmitting side of the PDCP entity shown at a left side of FIG. 5 constructs a PDU from a SDU received from an upper layer or from control information internally generated at the PDCP entity and transmits the PDU to a peer PDCP entity of a receiving side. The receiving side shown at the right side of FIG. 5 extracts a PDCP SDU or control information from a PDCP PDU received from a peer PDCP entity of a transmitting side. As described above, PDUs generated at a PDCP entity of the transmitting side are divided into two types, data and control PDUs. The PDCP data PDU is a data block that the PDCP creates by processing a SDU received from an upper layer. The PDCP control is a data block that the PDCP internally creates to transfer a control information to a peer entity. The PDCP data PDU is created at RBs of both a user plane and a control plane. However, some functions of the PDCP are selectively applied depending on which plane is used. That is, a header compression function is applied only to user plane data. An integrity protection function among security functions is applied only to control plane data. The security functions also include a ciphering function for data security. The ciphering function is applied to both user plane and control plane data. The PDCP control PDU is generated only at the control plane RB. The PDCP control PDU is classified mainly into two types, one being associated with a PDCP status report for notifying the transmitting side of the status of a PDCP reception buffer, the other being associated with a Header Compression (HC) feedback packet for notifying a header compressor of the status of a header decompressor. FIG. 6 is a block diagram of an AM entity of a RLC layer used in an E-UMTS system. This block diagram illustrates functional blocks that may differ from actual implementations. The RLC layer is not limited to a specific implementation. Although the RLC layer has three modes, TM, UM and AM, TM and UM entities are not illustrated since the TM entity performs almost no function at the RLC layer and the UM entity is similar to the AM entity except that it has no retransmission function. The UM RLC layer transmits each PDU to the receiving side by attaching a PDU header including a Sequence Number (SN) to the PDU to notify the receiving side of which PDU has been lost during transmission. Due to this function, at the user plane, the UM RLC is mainly responsible for transmitting broadcast/multicast data or transmitting real-time packet data such as voice (e.g., VoIP) or streaming data of a Packet Service (PS) domain. At the control plane, the UM RLC is responsible for transmitting a RRC message which does not require acknowledgement among RRC messages that would be transmitted to a specific UE or a specific UE group in a cell. Similar to the UM RLC, the AM RLC constructs a PDU by attaching a PDU header including a SN when constructing the PDU. However, unlike the UM RLC, the receiving side acknowledges a PDU transmitted by the transmitting side at the AM RLC. The reason why the receiving side acknowledges each PDU transmitted by the transmitting side at the AM RLC is to request that the transmitting side should retransmit a PDU that the AM RLC has not received. This retransmission function is the most significant feature of the AM RLC. That is, the purpose of the AM RLC is to guarantee error-free data transmission through retransmission. Due to this purpose, the AM RLC is mainly- responsible in the user plane for transmitting non-real- time packet data such as TCP/IP of the PS domain and is responsible in the control plane for transmitting a RRC message that must need reception acknowledgment resposonse among RRC messages transmitted to a specific UE in the cell. In terms of directionality, the UM RLC and AM RLC differ in that the UM RLC is used for unidirectional communication whereas the AM RLC is used for bidirectional communication due to the presence of feedback from the receiving side. In terms of structural aspects, the UM RLC and AM RLC differ in that one UM RLC entity has either a transmission or reception structure whereas one AM RLC entity includes both transmitting and receiving sides. The AM RLC is complicated due to the retransmission function. For managing retransmission, the AM RLC includes a retransmission buffer in addition to transmission/reception buffers and uses transmission/reception windows for flow control and performs a variety of functions as follows. The transmitting side performs polling to request that a receiving side of a peer reception provide status information. The receiving side provides a status report to report a buffer status of the receiving side to a peer RLC entity of a transmitting side. The receiving side constructs a status PDU carrying status information. To support these functions, the AM RLC requires a variety of protocol parameters, status variables and timers. PDUs used to control data transmission at the AM RLC such as a status report or status information are referred to as "control PDUs" and PDUs used to transfer user data are referred to as "data PDUs". However, at the AM RLC, a RLC data PDU is specifically classified into an AMD PDU and an AMD PDU segment. Each AMD PDU segment includes part of data belonging to the AMD PDU. In the LTE, the maximum size of a data block that the UE transmits is changed at each transmission. Accordingly, when the AM RLC entity of the transmitting side receives a negative acknowledgement from an AM RLC entity of the receiving side after constructing and transmitting a 200-byte AMD PDU at a certain time, the 200-byte AMD PDU cannot be retransmitted by the AM RLC entity of the transmitting side without alteration if the maximum transmittable data block size is 100 bytes. Here, the AM RLC entity of the transmitting side uses AMD PDU segments which are small units into which the corresponding AMD PDU is divided. In this procedure, the AM RLC entity of the transmitting side divides the AMD PDU into AMD PDU segments and transmits the AMD PDU segments over a plurality of time intervals and the AM RLC entity of the receiving side reconstructs the received AMD PDU segments into an AMD PDU. The functions of the RLC entity can be considered those of Segmentation and Reassembly (SAR) in their entirety. That is, the RLC of the transmitting site is responsible for adjusting the size of a MAC PDU indicated by a MAC entity, which is a lower entity, and RLC SDUs received from an upper entity. Specifically, the RLC transmitting side constructs a RLC PDU by segmenting and concatenating RLC SDUs received from an upper entity so as to match a MAC PDU size (i.e., a RLC PDU size) indicated by a lower entity. A header of a RLC PDU includes information associated with segmentation, concatenation or the like of RLC SDUs. Based on this information, the receiving side reconstructs RLC SDUs from received RLC PDUs. An overall data transmission procedure performed at L2 is as follows. First, externally created data (e.g., an IP packet) is transferred to a PDCP entity and is then converted into a PDCP SDU. The PDCP entity stores the PDCP SDU in its own buffer until transmission is completed. The PDCP entity processes the PDCP SDU to create PDCP PDUs and transfers the created PDCP PDUs to the RLC entity. A data block that the RLC entity receives from an upper entity is a RLC SDU, which is identical to a PDCP PDU. The RLC entity performs appropriate processing on the RLC SDU and constructs and transmits a RLC PDU. Example of General Operation of Frotocol Layer according to Embodiment of the Invention An embodiment of the present invention suggests a method for effectively managing data while satisfying Quality of Service (QoS) of an established (or configured) Radio Bearer (RB). To accomplish this, the embodiment of the present invention decides whether or not to discard data stored in a protocol layer entity of the transmitting side taking into consideration an allowed transfer time or a maximum allowed delay of data and a maximum buffer size that can be accommodated by the protocol layer entity of the transmitting side. Preferably, the protocol layer is a PDCP layer. An examplary general operation of the embodiment of the present invention is described in detail below focusing on the PDCP layer. Here, the term "discard" can be used interchangeably with similar terms such as "deletion", "delete", "abandon", "erase", "remove" and the like. In an embodiment of the present invention, the PDCP entity can decide whether or not to discard a PDCP SDU when transmission of the PDCP SDU has been delayed for a predetermined time in order to guarantee QoS of an established RB. The predetermined time can be set flexibly taking into consideration the type of data to be transmitted. The predetermined time can be set by the network. Preferably, the predetermined time can be set by a layer (e.g., RRC layer) above the PDCP layer. If needed, the PDCP SDU and/or PDC? PDU may not be discarded even when the predetermined time has elapsed. In an embodiment, the PDCP entity starts (in other terms, activates, runs or operates) a timer for a FDCP SDU when the PDCP SDU is received from an upper layer. Preferably, the upper layer is a Radio Resource Control (RRC) layer. The timer can run individually for each PDCP SDU. The timer can also run commonly for a specific number of PDCP SDUs or a specific group of PDCP SDUs. For example, when a specific number of related PDCP SDUs or a specific group of PDCP SDUs is present, the timer can run only for the first PDCP SDU. When the RLC entity has notified the PDCP entity that the RLC SDU (i.e., PDCP PDU) has been successfully transmitted while the timer is running, the PDCP entity can discard the PDCP PDU. In an implementation, the PDCP entity can discard a PDCP PDU when PDCP PDUs with serial numbers lower than that of the PDCP PDU have been successfully transmitted. The PDCP entity can also discard a PDCP PDU when PDCP SDUs previous to a PDCP SDU associated with the PDCP PDU have been successfully transmitted. When the PDCP PDU has been discarded, a timer of the PDCP SDU associated with the PDCP PDU is stopped. Preferably, the PDCP SDU whose timer has been stopped is discarded. When the timer expires while the PDCP entity has not received any notification of whether or not the PDCP PDU has been successfully transmitted from the RLC entity, the PDCP entity can decide to discard a PDCP SDU associated with the timer. The timer can be given a variety of names depending on its function. In an embodiment of the present invention, the timer can be referred to as a "discard_timer" since it is associated with discarding data of the PDCP layer. In an implementation, the value of the timer can be set by the network. Preferably, the value of the timer can be set by a layer (e.g., RRC layer) above the PDCP layer. The value of the timer is a setting associated with the timer. For example, the value of the timer may indicate a PDCP SDU or a PDCP PDU, based on which the timer will run. The value of the timer can also indicate an oneration performed at the PDCP layer, based on which the timer will run. The value of the timer may also include information associated with the time when the timer will expire after it is activated (i.e., information associated with the timer's expiration time). The timer's expiration time can be set taking into consideration all times associated with transmission of an IP packet (e.g., each duration the IP packet stays at the RLC entity and the PDCP entity, a transmission period, the maximum allowable delay of data, etc.). In addition, the timer expiration time can be set flexibly according to data type since not all IP packets or PDCP PDUs have the same importance. For example, a full- header packet is essential to form a context of header compression. Accordingly, a different timer value can be set according to the characteristics or attributes of packets. A timer may not be activated or the expiration time thereof may be set to infinity for a specified packet or PDCP PDU/SDU. Alternatively, the discard process may not be performed for the specified packet or PDCP PDU/SDU even when the timer has expired. When the PDCP entity has decided to discard a specific PDCP SDU and a PDCP PDU associated with the PDCP SDU has not been transferred to the RLC entity, the PDCP entity provides no notification to the RLC entity and discards the PDCP SDU. Preferably, the PDCP entity discards the PDCP PDU associated with the PDCP SDU together with the PDCP SDU. When the PDCP entity has decided to discard a specific PDCP SDU and a PDCP PDU associated with the PDCP SDU has already been transferred to the RLC entity, the PDCP entity provides information associated with discard of the PDCP SDU and/or PDCP PDU to the RLC entity and discards the PDCP SDU. Preferably, the information associated with the discard may be information indicating that a certain PDCP PDU (i.e., RLC SDU) or PDCP SDU has been discarded. The information associated with the discard may also be information requesting that the associated RLC SDU should be discarded or information used to request that the associated RLC SDU should be discarded. In the above procedure, when the PDCP SDU has been discarded, it is assumed that the associated PDCP PDU has been successfully transmitted and the successful transmission is reported to an upper layer. In the above procedure, when the RLC entity receives the information associated with the discard of a specific PDCP SDU and/or PDCP PDU (i.e., RLC SDU) from the PDCP entity, the RLC entity performs an operation for discarding an associated RLC SDU. The UM RLC entity discards the associated RLC SDU and no longer attempts to transmit a RLC PDU associated with the RLC SDU. The AM RLC entity performs an operation for discarding the associated RLC SDU. Preferably, the operation includes an operation of a RLC entity of a transmitting side to notify a RLC entity of a receiving side of a command indicating that the RLC SDU will no longer be transmitted. In this case, the AMD RLC entity of the transmitting side can also notify the AM RLC entity of the receiving side of a serial number cf a lower boundary of a reception RLC window or a transmission RLC window in association with the discarded RLC SDU. The AMD RLC entity of the transmitting side can notify the AM RLC entity of the receiving side of information associated with byte- offset together with the serial number. Preferably, the RLC entity may discard the RLC SDU when no part of the RLC SDU indicated by the PDCP layer has been transmitted. For example, in the case where the RLC SDU is segmented into at least one segment, the RLC SDU may be discarded if no segment of the RLC SDU has been transmitted. The transmitting side can determine whether or not any part of the RLC SDU has been transmitted based on whether or not the transmitting side has actually- transmitted any part of the RLC SDU. It does not matter whether cr not the receiving side has actually received data. That is, the transmitting side determines whether or not the data has been transmitted, only from the viewpoint of the transmitting side. Preferably, the transmitting side may determine whether or not any part of the RLC SDU has been transmitted based on whether or not any part of the RLC SDU has been mapped to a RLC PDU, preferably to a RLC data PDU. For example, when an upper layer has requested that a RLC SDU be discarded, the RLC SDU may be discarded only when no segment of the RLC SDU has been mapped to a RLC data PDU. In addition, when the RLC SDU, which has been requested to be discarded by the upper layer, is constructed into at least one RLC PDU, the RLC SDU can be discarded only when no related RLC PDU has been transmitted. Further, the RLC SDU may not be discarded when the RLC SDU is included in specific RLC PDUs and it has been attempted to transmit at least one of the specific RLC PDUs through a wireless interface. The RLC SDU may also be discarded only when the RLC SDU is not included in any RLC PDU or when it has not been attempted to transmit any one of the specific RLC PDUs through a wireless interface although the RLC SDU is included in the specific RLC PDUs. Whether or not it has been attempted to transmit the RLC PDU through a wireless interface can be determined based on whether or not any part of the RLC SDU has been mapped to a RLC PDU, preferably to a RLC data PDU. Although the above operations have been described mainly based on a PDCP SDU for ease of explanation, the operations may also be performed based on a PDCP PDU. Specifically, a timer may run in association with the PDCP PDU and associated operations may be performed accordingly. FIG. 7 illustrates examplary operations of a protocol layer performed at a UE or base station according to an embodiment of the present invention. As shown in FIG. 7, packets A and B are transferred from an upper layer to a PDCP layer (S710) . PDCP SDUs of the packets A and B are stored in a PDCP buffer and a discard_timer starts for each of the packets (S770). A MAC layer requests that a RLC layer transfer new MAC SDUs (RLC PDUs) (S720) . If the RLC layer has no new data to be transmitted, the RLC layer requests that a PDCP layer transfer new RLC SDUs (PDCP PDUs) (S730) . The PDCP layer performs header compression, ciphering and header addition on the PDCP SDUs of the packet A to create PDCP PDUs of the packet A (S740) . The PDCP layer transfers the PDCP PDUs of the packet A to the RLC layer (S750) . The RLC layer stores the PDCP PDUs (i.e., RLC SDUs) of the packet A in a RLC buffer. The RLC layer constructs a RLC PDD from the received RLC SDU of the packet A and transfers the RLC PDU to the MAC layer. The MAC/PHY layers perform transmission of the RLC PDU (S760). In FIG. 7, it is assumed that the PDCP layer has not received information, indicating that the receiving side has successfully received the PDCP PDU of the packet A, from the RLC layer until a discard_timer of the PDCP SDU for the packet A expires. It is also assumed that a discard_timer of the PDCP SDU for the packet B has expired almost at the same time. Since the discard_timers for the packets A and B have expired, the PDCP layer decides to discard the packets A and B from the buffer (S770) . Since the packet B has not yet been assigned a SN and has not been compressed or ciphered, the packet B is removed from the PDCP entity and the RLC entity is not notified that the packet B has been discarded. On the other hand, since the packet A has been assigned a SN and has already been compressed and transferred to the RLC entity, the PDCP layer requests that the RLC layer should discard a RLC SDU associated with the packet A (S780) . According to this notification, the RLC layer performs an operation for discarding the RLC SDU. The operation for discarding the RLC layer is described in more detail with reference to FIG. 8. FIG. 8 illustrates examplary operations of a protocol layer performed at a UE or base station according to another embodiment of the present invention. As shown in FIG. 8, a PDCP layer receives data blocks such as IP packets from an upper layer (811-813). The PDCP layer adds a SN to each of the received blocks and stores the blocks in a PDCP SDU buffer (821-823). At a request of a lower layer, the PDCP layer constructs PDCP SDUs into PDCP data PDUs and transfers the PDCP data PDUs to the RLC layer (831, 832 and 834). In this case, the PDCP layer can also generates a PDCP control PDU (833) including feedback information or the like associated with header compression into. The RLC layer stores the received RLC SDUs in a RLC SDU buffer (831-834) . At a request of a lower layer, the RLC layer may segment and concatenate the RLC SDUs to construct a plurality of RLC PDUs (841-844) . Although not illustrated in FIG. 8, when the PDCP layer receives a data block or stores data in the PDCP SDU buffer, a discard_timer is activated for each PDCP SDU, a specific number of PDCP SDUs or a specific group of PDCP SDUs. Alternatively, the discard_timer can run based on the PDCP PDU. The procedure in which the PDCP layer decides whether or not to discard the PDCP SDU is similar to that of FIG. 7. The following is a description of examplary operations of the PDCP layer in association with a PDCP control PDU according to another embodiment. Thereafter, the description will be given focusing on an operation of the RLC layer to discard a RLC SDU according to an instruction from the PDCP layer. The procedure of the RLC layer to discard the RLC SDU is applied to both the examples of FIGs. 7 and 8. As shown in FIG. 3, PDCP data PDUs 831, 832, and 834 and a PDCP control PDU 833 are created in association with a PDCP SDU. In the example of FIG. 8, the PDCP control PDU 833 includes feedback information associated with header compression. When the fact that the PDCP control PDU can be created in association with a PDCP SDU is taken into consideration, a PDCP control PDU associated with a specific PDCP SDU can be discarded when the specific PDCP SDU is discarded. For example, a PDCP data PDU is created immediately after header compression is performed on the specific PDCP SDU. In this case, a PDCP control PDU can also be created. Here, the PDCP control PDU and the PDCP data PDU can be discarded together since they are associated with the PDCP SDU. Preferably, when a PDCP control PDU has been generated, the PDCP control PDU is discarded when a PDCP SDU generated simultaneously with the PDCP control PDU is discarded. Preferably, when a PDCP control PDU has been generated, the PDCP control PDU is discarded when a PDCP SDU generated immediately before the PDCP control PDU is discarded. Preferably, when a PDCP control PDU has been generated, the PDCP control PDU is discarded when a PDCP SDU generated next to the PDCP control PDU is discarded. Preferably, the PDCP control PDU includes a header compression packet. In addition, when the fact that not all PDCP control PDUs are associated with a PDCP SDU is taken into consideration, the PDCP control PDU may not be discarded even when the specific PDCP SDU has been discarded. Preferably, when a PDCP control PDU has been generated, the PDCP control PDU is not discarded even when a PDCP SDU generated simultaneously with the PDCP control PDU is discarded. Preferably, when a PDCP control PDU has been generated, the PDCP control PDU is not discarded even when a PDCP SDU generated immediately before the PDCP control PDU is discarded. Preferably, when a PDCP control PDU has been generated, the PDCP control PDU is not discarded even when a PDCP SDU generated next to the PDCP control PDU is discarded. Preferably, the PDCP control PDU is a PDCP status report. A separate timer can also run for a PDCP control PDU. Preferably, a separate timer starts for a PDCP control PDU when the PDCP control PDU is generated and the PDCP control PDU is discarded when the timer expires. Preferably, the same timer as that applied to a PDCP data PDU starts for a PDCP control PDU when the PDCP control PDU is generated and the PDCP control PDU is discarded when the timer expires. In this case, different timer values can be set for both the PDCP data PDU and the PDCP control PDU. In the above procedure, when a PDCP control PDU has been discarded, the PDC? entity notifies the RLC layer that the PDCP control PDU has been discarded. That is, the PDCP entity determines data to be discarded to guarantee QoS and instructs the RLC entity below the PDCP entity to discard a corresponding RLC SDU. The following is a description of an examplary procedure in which the RLC layer discards a specific RLC SDU when the PDCP layer has instructed the RLC layer to discard the RLC SDU. As shown in FIG. 8, one RLC SDU may be divided into a plurality of RLC PDUs to be transmitted or one RLC PDU may include a plurality of RLC SDUs. In the procedure for discarding specific RLC SDUs according to an instruction of the PDCP layer, removal of a RLC PDU including a plurality of RLC SDUs is wasteful if it is only necessary to discard some of the plurality of RLC SDUs included in the RLC PDU. In this case, the transmitting side of the AM RLC entity should not attempt to transmit RLC SDUs that were discarded according to the instruction of the PDCP layer and should attempt to retransmit other RLC SDUs until the RLC entity of the receiving side notifies the transmitting side of successful reception. To accomplish this, the transmitting side of the RLC entity may divide the RLC PDU (particularly, the AM RLC data PDU) to construct AM RLC data PDU segments that do not include the discarded RLC SDUs and then transmit the AM RLC data PDU segments to the receiving side. That is, when a RLC SDU has been discarded, the AM RLC data PDU segments including the discarded RLC SDU are no longer transmitted. In the procedure for discarding specific RLC SDUs according to an instruction of the PDCP layer, the UM RLC entity discards all RLC PDUs including the RLC SDU and no longer transmits the discarded RLC PDUs. The UM RLC entity also discards the RLC SDU and no longer transmits associated RLC PDUs. Preferably, even when the PDCP layer has instructed to discard a specific RLC SDU, the RLC SDU may be removed from the RLC buffer only when no part of the RLC SDU has been attempted to be transmitted or has been transmitted. That is, in the case where the RLC SDU has been divided into a plurality of segments, the RLC SDU can be removed from the RLC buffer only when no segment of the RLC SDU has been attempted to be transmitted or has been transmitted. For example, the RLC SDU may be removed from the RLC buffer only when no segment of the RLC SDU has been mapped to a RLC data PDU. According to the embodiments of the present invention, it is possible to satisfy QoS of an established radio bearer and to effectively manage data in multiple protocol layers. The above embodiments are provided by combining components and features of the present invention in specific forms. The components or features of the present invention should be considered optional if not explicitly stated otherwise. The components or features may be implemented without being combined with other components or features. The embodiments of the present invention may also be provided by combining some of the components and/or features. The order of the operations described above 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 will be apparent that claims which are not explicitly dependent on each other can be combined to provide an embodiment or new claims can be added through amendment after this application is filed. The above embodiments of the present invention have been described focusing mainly on the data communication relationship between a UE (or terminal) and a Base Station (BS) . Specific operations which have been described as being performed by the BS may also be performed by upper nodes as needed. That is, it will be apparent to those skilled in the art that the BS or any other network node may perform various operations for communication with terminals in a network including a number of network nodes including BSs. The term "base station (BS)" may be replaced with another term such as "fixed station", "Node B", "eNode B (eNB)", or "access point". The term "terminal" may also be replaced with another term such as "user equipment (UE)", "mobile station (MS)", "mobile station (MS)", or "mobile subscriber station (MSS)". The embodiments of the present invention can be implemented by hardware, firmware, software, or any combination thereof. In the case where the present invention is implemented by hardware, an embodiment of the present invention may be implemented by one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), processors, controllers, microcontrollers, microprocessors, or the like. In the case where the present invention is implemented by firmware or software, the embodiments of the present invention may be implemented in the form of modules, processes, functions, or the like which perform the features or operations described above. Software code can be stored in a memory unit so that it can be executed by a processor. The memory unit may be located inside or outside the processor and can communicate data with the processor through a variety of known means. INDUSTRIAL APPLICABILITY Those skilled in the art will appreciate that the present invention may be embodied in other specific forms than those set forth herein without departing from the spirit and essential characteristics of the present invention. The above description is therefore to be construed in all aspects as illustrative and not restrictive. The scope of the invention should be determined by reasonable interpretation of the appended claims and all changes coming within the equivalency range of the invention are intended to be embraced in the scope of the invention. WHAT IS CLAIMED IS: 1. A method of processing data by a user equipment in a wireless mobile communication system, the method comprising the steps of: receiving a first data block from an upper layer; transferring a second data block including the first data block to a lower layer at a particular protocol layer; discarding the first and second data blocks present in the particular protocol layer if a certain period of time has passed; and transferring an information associated with the discard of the second data block to the lower layer. 2. A method of processing data by a user equipment in a wireless mobile communication system, the method comprising the steps of: operating a timer for a first data block at a particular protocol layer when receiving the first data block from an upper layer; transferring a second data block including the first data block to a lower layer at a particular protocol layer; discarding the first and second data blocks present in the particular protocol layer if the timer expires; and transferring an information associated with the discard of the second data block to the lower layer. 3. The method of claim 1 or 2, wherein the information associated with the discard serves to indicate the discard of the second data block or to instruct the lower layer to discard the second data block. 4. The method of claim 1 or 2, further comprising the step of discarding the second data block by the lower layer if no part of the second data block has been transmitted. 5. The method of claim 1 or 2, wherein the particular protocol layer is a Packet Data Convergence Protocol (PDCP) layer. 6. The method of claim 5, wherein the first data block is a PDCP Service Data Unit (PDCP SDU). 7. The method of claim 5, wherein the second data block is a PDCP Protocol Data Unit (PDCP PDU). 8. The method of claim 5, wherein the upper layer is a Radio Resource Control (RRC) layer. 9. The method of claim 5, wherein the lower layer is a Radio Link Control (RLC) layer. 10. The method of claim 3, wherein the RLC layer operates in an Acknowledged Mode (AM) or an Unacknowledged Mode (UM). 11. The method of claim 1, wherein the certain period of time is indicated by a network. 12. The method of claim 1, wherein the certain period of time is indicated by an upper layer above the particular protocol layer. 13. The method of claim 2, wherein a value of the timer is indicated by a network. 14. The method of claim 2, wherein a value of the timer is indicated by an upper layer above the particular protocol layer. 15. A method of processing data by a user equipment in a wireless mobile communication system, the method comprising the steps of: receiving a data block from an upper layer; receiving information associated with discard of the data block from the upper layer; and discarding the data block at a particular protocol layer if no part of the data block has been transmitted. 16. The method of claim 15, wherein the information associated with the discard serves to indicate the discard of the data block or to instruct discard of the data block. 17. The method of claim 15, wherein the upper layer is a PDCP layer. 18. The method of claim 17, wherein the data block is a RLC SDU. 19. The method of claim 17, wherein the particular protocol layer is a RLC layer. 20. The method of claim 19, wherein the RLC layer operates in an Acknowledged Mode (AM) or an Unacknowledged Mode (UM). 21. The method of claim 15, wherein, when the data block is segmented into at least one segment, the data block is discarded if no segment of the data block has been transmitted. 22. The method of claim 15, wherein whether or not any part of the data block has been transmitted is determined based on whether or not any part of the data block has been mapped to a data PDU of the particular protocol layer. A method in which a user equipment processes data in a wireless mobile communication system is provided. The method includes the steps of receiving a first data block from an upper layer, transferring a second data block including the first data block to a lower layer at a particular protocol layer, discarding the first and second data blocks present in the particular protocol layer if a certain period of time has passed, and transferring information associated with the discard of the second data block to the lower layer.

Full Text

A METHOD FOR QoS GUARANTEES IN A MULTILAYER STRUCTURE
TECHNICAL FIELD
The present invention relates to a wireless mobile
communication system, and more particularly, to a method in
which a terminal (or user equipment) processes data in a
wireless mobile communication system.
BACKGROUND ART
A radio protocol based on the 3rd Generation
Partnership Project (3GPP) radio access network standard is
divided into a first (LI) layer, a second (L2) layer, and a
third (L3) layer based on the lower three layers of the
Open System Interconnection (OSI) reference model. The
second layer of the radio protocol includes a Medium Access
Control (MAC) layer, a Radio Link Control (RLC) layer and a
Packet Data Convergence Protocol (PDCP) layer. The third
layer includes a Radio Resource Control (RRC) layer at the
bottom of the third layer.
The RLC layer is responsible for guaranteeing Quality
of Service (QoS) of each Radio Bearer (RB) and performing
data transmission according to the QoS. The RLC layer
includes one or two RLC entities for each RB in order to
guarantee QoS specific to the RB. The RLC layer also

provides three RLC modes, a Transparent Mode (TM), an
Unacknowledged Mode (UM), and an Acknowledged Mode (AM), in
order to support various QoS.
The PDCP layer is located above the RLC layer and can
perform header compression on data transmitted using IP
packets such as IPv4 or IPv6 packets. The PDCP layer is
present only in a packet-switched domain and includes one
PDCP entity per RB.
The RRC layer sets a variety of operating methods,
parameters, and characteristics of channels associated with
the first and second layers of the radio protocol in order
to satisfy QoS. Specifically, the RRC layer determines
which header compression method would be used at the PDCP
layer and determines an operating mode, a RLC PDU size, and
values of various protocol parameters which are used for
the RLC layer.
DISCLOSURE OF THE INVENTION
TECHNICAL PROBLEM
QoS is the quality of services transmitted and
received through a wireless mobile communication system.
Typical factors that affect QoS include delay, error ratio,
and bitrate. QoS of a service is determined appropriately
according to the type of the service.
In the case of real-time services such as VoIP or
streaming services using a wireless mobile communication
system, problems such as video interruption or audio
distortion occur if transfer delay is significant. That is,
even though data is received by the counterpart, the
quality is lowered if it takes more than a specific time to
transfer the data to the counterpart. Indeed, data
received after a specific time has elapsed is mostly not
used by an application. Accordingly, attempting to
transmit a data block, whose transfer time has exceeded the
allowed transfer time, or storing such a data block causes
overhead and waste of resources.
The following is a more detailed description with
reference to the PDCP layer. Data units received from the
outside of the L2 layer are stored in a buffer of the PDCP
layer. The data units are stored in the PDCP layer until
they are received by the counterpart. However, if
transmission of data blocks associated with a PDCP SDU is
delayed at a lower layer, the time duration during which
the PDCP SDU must stay in the buffer of the PDCP layer
increases. Specifically, the capacity of the buffer may
become insufficient if the amount of data is large, if data
is constantly received from the outside, or if transmission
of some PDCP SDUs is kept delayed. Especially, if the
buffer is full, new data received from the outside is
immediately discarded since there is no space in which to
store the new data. This directly affects the QoS.
An object of the present invention devised to solve
the above problems of the conventional technologies lies in
providing a data processing method that guarantees Quality
of Service (QoS) and efficiently manages data in a wireless
mobile communication system which uses a multilayer
structure.
Another object of the present invention devised to
solve the problem lies in providing a method in which a
specific protocol layer of a User Equipment (UE) or a base
station decides data to be discarded (or deleted) and
instructs a lower layer to discard the data.
A further object of the present invention devised to
solve the problem lies in providing a method in which a
lower layer discards data when a specific protocol layer of
a UE or a base station has instructed the lower layer to
discard the data.
Objects of the present invention are not limited to
those described above and other objects will be clearly
understood by those skilled in the art from the following
description.
TECHNICAL SOLUTION
In one aspect of the present invention, provided
herein is a method of processing data by a user equipment
in a wireless mobile communication system, the method
including the steps of receiving a first data block from an
upper layer; transferring a second data block including the
first data block to a lower layer at a particular protocol
layer; discarding the first and second data blocks present
in the particular protocol layer if a certain period of
time has passed; and transferring information associated
with the discard of the second data block to the lower
layer. Preferably, the upper layer is a RRC layer.
Preferably, the lower layer is a RLC layer. Preferably,
the specific protocol layer is a PDCP layer.
In another aspect of the present invention, provided
herein is a method of processing data by a user equipment
or a base station in a wireless mobile communication system,
the method including the steps of operating a timer for a
first data block at a particular protocol layer when
receiving the first data block from an upper layer;
transferring a second data block including the first data
block to a lower layer at a particular protocol layer;
discarding the first and second data blocks present in the
particular protocol layer if the timer expires; and
transferring information associated with the discard of the
second data block to the lower layer. Preferably, the
upper layer is a RRC layer. Preferably, the lower layer is
a RLC layer. Preferably, the specific protocol layer is a
PDCP layer.
In another aspect of the present invention, provided
herein is a method of processing data by a user equipment
or a base station in a wireless mobile communication system,
the method including the steps of receiving a data block
from an upper layer, receiving an instruction to discard
the data block from the upper layer, and discarding the
data block at a particular protocol layer if no part of the
data block has been transmitted.
ADVANTAGEOUS EFFECTS
Embodiments of the present invention have the
following advantages.
First, it is possible to guarantee QoS and to
efficiently manage data in a wireless mobile communication
system which uses a multilayer structure.
Second, a specific protocol layer of a User Equipment
(UE) or a base station can decide data to be discarded (or
deleted) and instruct a lower layer to discard the data.
Third, a lower layer can discard data when a specific
protocol layer of a UE or a base station has instructed the
lower layer to discard the data.
Advantages of the present invention are not limited
to those described above and other advantages will be
clearly understood by those skilled in the art from the
following description.
DESCRIPTION OF DRAWINGS
The accompanying drawings, which are included to
provide a further understanding of the invention,
illustrate embodiments of the invention and together with
the description serve to explain the principle of the
invention.
In the drawings:
FIG. 1 illustrates a network structure of an E-UMTS.
FIG. 2 illustrates a schematic structure of an
Evolved Universal Terrestrial Radio Access Network (E-
UTRAN).
FIGs. 3A and 3B illustrate the configurations of a
control plane and a user plane of a radio interface
protocol between a UE and an E-UTRAN.
FIG. 4 illustrates an example structure of a physical
channel used in an E-UMTS system.
FIG. 5 is a block diagram of a PDCP layer used in an
E-UMTS system.
FIG. 6 is a block diagram of an AM entity of a RLC
layer used in an E-UMTS system.
FIG. 7 illustrates example operations of a protocol
layer performed at a UE or base station according to an
embodiment of the present invention.
FIG. 8 illustrates example operations of a protocol
layer performed at a UE or base station according to
another embodiment of the present invention.
MODE FOR INVENTION
The above and other configurations, operations, and
features of the present invention will be easily understood
from the embodiments of the invention described below with
reference to the accompanying drawings. The embodiments
described below are examples wherein technical features of
the invention are applied to an Evolved Universal Mobile
Telecommunications System (E-UMTS).
FIG. 1 shows a network structure of the E-UMTS to
which an embodiment of the present invention is applied.
The E-UMTS system is an evolved version of the conventional
WCDMA UMTS system and basic standardization thereof is in
progress under the 3rd Generation Partnership Project
(3GPP) . The E-UMTS is also referred to as a Long Term
Evolution (LTE) system. For details of the technical
specifications of the UMTS and E-UMTS, reference can be
made to Release 7 and Release 8 of "3rd Generation
Partnership Project; Technical Specification Group Radio
Access Network".
As shown in FIG. 1, the E-UMTS mainly includes a User
Equipment (UE), base stations (or eNBs or eNode Bs), and an
Access Gateway (AG) which is located at an end of a network
(E-UTRAN) and which is connected to an external network.
Generally, an eNB can simultaneously transmit multiple data
streams for a broadcast service, a multicast service,
and/or a unicast service. AGs can be divided into AGs
responsible for processing user traffic and AGs responsible
for processing control traffic. Here, an AG for processing
new user traffic and an AG for processing control traffic
can communicate with each other using a new interface. One
or more cells are present for one eNB. An interface for
transmission of user traffic or control traffic can be used
between eNBs. A Core Network (CN) may include an AG and
network nodes for user registration of UEs. An interface
for discriminating between the E-UTRAN and the CN can be
used. The AG manages mobility of a UE on a Tracking Area
(TA) basis. One TA includes a plurality of cells. When
the UE has moved from a specific TA to another TA, the UE
notifies the AG that the TA where the UE is located has
been changed.
FIG. 2 illustrates a network structure of an Evolved
Universal Terrestrial Radio Access Network (E-UTRAN) system
which is a mobile communication system to which the
embodiment of the present invention is applied. The E-
UTRAN system is an evolved version of the conventional
UTRAN system. The E-UTRAN includes base stations (eNBs),
which are connected through X2 interfaces. Each eNB is
connected to User Equipments (UEs) through a radio
interface and is connected to an Evolved Packet Core (EPC)
through an SI interface.
FIGs. 3A and 3B illustrate the configurations of a
control plane and a user plane of a radio interface
protocol between a UE and a UMTS Terrestrial Ratio Access
Network (UTRAN) based on the 3GPP radio access network
standard. The radio interface protocol is divided
horizontally into a physical layer, a data link layer, and
a network layer and vertically into a user plane for data
information transmission and a control plane for signaling.
The protocol layers of FIGs. 3A and 3B can be divided into
a Ll layer (first layer) , a L2 layer (second layer), and a
L3 layer (third layer) based on the lower three layers of
the Open System Interconnection (OSI) reference model
widely known in communication systems.
The control plane is a passage through which control
messages that a UE and a network use in order to manage
calls are transmitted. The user plane is a passage through
which data (e.g., voice data or Internet packet data)
generated at an application layer is transmitted. The
following is a detailed description of the layers of the
radio protocol control and user planes.
The physical layer, which is the first layer,
provides an information transfer service to an upper layer
using a physical channel. The physical layer is connected
to a Media Access Control (MAC) layer, located above the
physical layer, through a transport channel. Data is
transferred between the MAC layer and the physical layer
through the transport channel. Data transfer between
different physical layers, specifically between the
respective physical layers of transmitting and receiving
sides, is performed through the physical channel. The
physical channel is modulated according to the Orthogonal
Frequency Division Multiplexing (OFDM) method, using time
and frequencies as radio resources.
The MAC layer of the second layer provides a service
to a Radio Link Control (RLC) layer, located above the MAC
layer, through a logical channel. The RLC layer of the
second layer supports reliable data transfer. The
functions of the RLC layer may also be implemented through
internal functional blocks of the MAC layer. In this case,
the RLC layer need not be provided. A PDCP layer of the
second layer performs a header compression function to
reduce unnecessary control information in order to
efficiently transmit IP packets such as IPv4 or IPv6
packets in a radio interval with a relatively narrow
bandwidth.
A Radio Resource Control (RRC) layer located at the
bottom of the third layer is defined only in the control
plane and is responsible for control of logical, transport,
and physical channels in association with configuration,
re-configuration and release of Radio Bearers (RBs). The
RB is a service that the second layer provides for data
communication between the UE and the UTRAN. To accomplish
this, the RRC layer of the UE and the RRC layer of the
network exchange RRC messages. The UE is in a RRC
connected mode if a RRC connection has been established
between the RRC layer of the radio network and the RRC
layer of the UE. Otherwise, the UE is in a RRC idle mode.
A Non-Access Stratum (NAS) layer located above the
RRC layer performs functions such as session management and
mobility management.
One cell of the eNB is set to provide a bandwidth
such as 1.25, 2.5, 5, 10, or 20MHz to provide a downlink or
uplink transmission service to UEs. Here, different cells
may be set to provide different bandwidths.
Downlink transport channels for transmission of data
from the network to the UE include a Broadcast Channel
(BCH) for transmission of system information, a Paging
Channel (PCH) for transmission of paging messages, and a
downlink Shared Channel (SCH) for transmission of user
traffic or control messages. User traffic or control
messages of a downlink multicast or broadcast service may
be transmitted through a downlink SCH and may also be
transmitted through a downlink multicast channel (MCH).
Uplink transport channels for transmission of data from the
UE to the network include a Random Access Channel (RACH)
for transmission of initial control messages and an uplink
SCH for transmission of user traffic or control messages.
Logical channels, which are located above the
transport channels and are mapped to the transport channels,
include a Broadcast Control Channel (BCCH), a Paging
Control Channel (PCCH), a Common Control Channel (CCCH), a
Multicast Control Channel (MCCH), and a Multicast Traffic
Channel (MTCK).
FIG. 4 illustrates an example of a physical channel
structure used in an E-UMTS system. A physical channel
includes a plurality of subframes on the time axis and a
plurality of subcarriers on the frequency axis. Here, one
subframe includes a plurality of symbols on the time axis.
One subframe includes a plurality of resource blocks and
one resource block includes a plurality of symbols and a
plurality of subcarriers. Each subframe can use specific
subcarriers of a specific symbol (e.g., a first symbol) of
the subframe for a Physical Downlink Control Channel
(PDCCH) (i.e., a L1/L2 control channel). A L1/L2 control
information transmission region and a data transmission
region are shown in FIG. 4. The Evolved Universal Mobile
Telecommunications System (E-UMTS), which is currently
under discussion, uses 10ms radio frames, each including 10
subframes. Each subframe includes two consecutive slots,
each of which is 0.5ms long. One subframe includes
multiple OFDM symbols. Some (for example, the first
symbol) of the OFDM symbols can be used to transmit L1/L2
control information. A Transmission Time Interval (TTI),
which is a unit time during which data is transmitted, is
lms.
The eNB and the UE transmit and receive most data
other than a specific control signal or specific service
data through a PDSCH which is a physical channel by using a
DL-SCH which is a transport channel. Information
indicating which PDSCH data is transmitted to a UE (one or
a plurality of UEs) or how the UEs receive and decode PDSCH
data is included in a PDSCH which is a physical channel,
and then transmitted.
For example, let us assume that a specific PDCCH has
been CRC-masked with a Radio Network Temporary Identity
(RNTI) "A" and an information associated with data to be
transmitted is transmitted through a specific subframe by
using a radio resource (e.g., a frequency position) "B" and
a transmit format information (e.g., transmit block size,
modulation scheme, coding information, etc) "C" . Under
this assumption, one or more UEs in a cell monitor the
PDCCH using their own RNTI information. And, if one or
more specific UEs contain the RNTI ,VA", , the specific UEs
read the PDCCH and receive a PDSCH indicated by "B" and "C"
in the received PDCCH information at a corresponding time.
FIG. 5 is a block diagram of a PDCP layer used in an
E-UMTS system. This block diagram illustrates functional
blocks that may differ from actual implementations. The
PDCP layer is not limited to a specific implementation.
As shown in FIG. 5, the PDCP layer is located at the
top of the L.2 structure and is generally connected to a
device such as a computer at an upper side of the PDCP
layer and exchanges IP packets with the device.
Accordingly, the PDCP layer is responsible for primarily
storing IP packets received from the outside.
A PDCP entity is connected to a RRC or a user
application at an upper side of the PDCP entity and is
connected to a RLC layer at a lower side of the PDCP entity.
Data which the PDCP entity exchanges with an upper layer is
referred to as a "PDCP SDU".
One PDCP entity includes transmitting and receiving
sides as shown in FIG. 5. The transmitting side of the
PDCP entity shown at a left side of FIG. 5 constructs a PDU
from a SDU received from an upper layer or from control
information internally generated at the PDCP entity and
transmits the PDU to a peer PDCP entity of a receiving side.
The receiving side shown at the right side of FIG. 5
extracts a PDCP SDU or control information from a PDCP PDU
received from a peer PDCP entity of a transmitting side.
As described above, PDUs generated at a PDCP entity
of the transmitting side are divided into two types, data
and control PDUs. The PDCP data PDU is a data block that
the PDCP creates by processing a SDU received from an upper
layer. The PDCP control is a data block that the PDCP
internally creates to transfer a control information to a
peer entity.
The PDCP data PDU is created at RBs of both a user
plane and a control plane. However, some functions of the
PDCP are selectively applied depending on which plane is
used. That is, a header compression function is applied
only to user plane data. An integrity protection function
among security functions is applied only to control plane
data. The security functions also include a ciphering
function for data security. The ciphering function is
applied to both user plane and control plane data.
The PDCP control PDU is generated only at the control
plane RB. The PDCP control PDU is classified mainly into
two types, one being associated with a PDCP status report
for notifying the transmitting side of the status of a PDCP
reception buffer, the other being associated with a Header
Compression (HC) feedback packet for notifying a header
compressor of the status of a header decompressor.
FIG. 6 is a block diagram of an AM entity of a RLC
layer used in an E-UMTS system. This block diagram
illustrates functional blocks that may differ from actual
implementations. The RLC layer is not limited to a
specific implementation.
Although the RLC layer has three modes, TM, UM and AM,
TM and UM entities are not illustrated since the TM entity
performs almost no function at the RLC layer and the UM
entity is similar to the AM entity except that it has no
retransmission function.
The UM RLC layer transmits each PDU to the receiving
side by attaching a PDU header including a Sequence Number
(SN) to the PDU to notify the receiving side of which PDU
has been lost during transmission. Due to this function,
at the user plane, the UM RLC is mainly responsible for
transmitting broadcast/multicast data or transmitting
real-time packet data such as voice (e.g., VoIP) or
streaming data of a Packet Service (PS) domain. At the
control plane, the UM RLC is responsible for transmitting a
RRC message which does not require acknowledgement among
RRC messages that would be transmitted to a specific UE or
a specific UE group in a cell.
Similar to the UM RLC, the AM RLC constructs a PDU by
attaching a PDU header including a SN when constructing the
PDU. However, unlike the UM RLC, the receiving side
acknowledges a PDU transmitted by the transmitting side at
the AM RLC. The reason why the receiving side acknowledges
each PDU transmitted by the transmitting side at the AM RLC
is to request that the transmitting side should retransmit
a PDU that the AM RLC has not received. This
retransmission function is the most significant feature of
the AM RLC. That is, the purpose of the AM RLC is to
guarantee error-free data transmission through
retransmission. Due to this purpose, the AM RLC is mainly-
responsible in the user plane for transmitting non-real-
time packet data such as TCP/IP of the PS domain and is
responsible in the control plane for transmitting a RRC
message that must need reception acknowledgment resposonse
among RRC messages transmitted to a specific UE in the cell.
In terms of directionality, the UM RLC and AM RLC
differ in that the UM RLC is used for unidirectional
communication whereas the AM RLC is used for bidirectional
communication due to the presence of feedback from the
receiving side. In terms of structural aspects, the UM RLC
and AM RLC differ in that one UM RLC entity has either a
transmission or reception structure whereas one AM RLC
entity includes both transmitting and receiving sides.
The AM RLC is complicated due to the retransmission
function. For managing retransmission, the AM RLC includes
a retransmission buffer in addition to
transmission/reception buffers and uses
transmission/reception windows for flow control and
performs a variety of functions as follows. The
transmitting side performs polling to request that a
receiving side of a peer reception provide status
information. The receiving side provides a status report
to report a buffer status of the receiving side to a peer
RLC entity of a transmitting side. The receiving side
constructs a status PDU carrying status information. To
support these functions, the AM RLC requires a variety of
protocol parameters, status variables and timers. PDUs
used to control data transmission at the AM RLC such as a
status report or status information are referred to as
"control PDUs" and PDUs used to transfer user data are
referred to as "data PDUs".
However, at the AM RLC, a RLC data PDU is
specifically classified into an AMD PDU and an AMD PDU
segment. Each AMD PDU segment includes part of data
belonging to the AMD PDU. In the LTE, the maximum size of
a data block that the UE transmits is changed at each
transmission. Accordingly, when the AM RLC entity of the
transmitting side receives a negative acknowledgement from
an AM RLC entity of the receiving side after constructing
and transmitting a 200-byte AMD PDU at a certain time, the
200-byte AMD PDU cannot be retransmitted by the AM RLC
entity of the transmitting side without alteration if the
maximum transmittable data block size is 100 bytes. Here,
the AM RLC entity of the transmitting side uses AMD PDU
segments which are small units into which the corresponding
AMD PDU is divided. In this procedure, the AM RLC entity
of the transmitting side divides the AMD PDU into AMD PDU
segments and transmits the AMD PDU segments over a
plurality of time intervals and the AM RLC entity of the
receiving side reconstructs the received AMD PDU segments
into an AMD PDU.
The functions of the RLC entity can be considered
those of Segmentation and Reassembly (SAR) in their
entirety. That is, the RLC of the transmitting site is
responsible for adjusting the size of a MAC PDU indicated
by a MAC entity, which is a lower entity, and RLC SDUs
received from an upper entity. Specifically, the RLC
transmitting side constructs a RLC PDU by segmenting and
concatenating RLC SDUs received from an upper entity so as
to match a MAC PDU size (i.e., a RLC PDU size) indicated by
a lower entity. A header of a RLC PDU includes information
associated with segmentation, concatenation or the like of
RLC SDUs. Based on this information, the receiving side
reconstructs RLC SDUs from received RLC PDUs.
An overall data transmission procedure performed at
L2 is as follows. First, externally created data (e.g., an
IP packet) is transferred to a PDCP entity and is then
converted into a PDCP SDU. The PDCP entity stores the PDCP
SDU in its own buffer until transmission is completed. The
PDCP entity processes the PDCP SDU to create PDCP PDUs and
transfers the created PDCP PDUs to the RLC entity. A data
block that the RLC entity receives from an upper entity is
a RLC SDU, which is identical to a PDCP PDU. The RLC
entity performs appropriate processing on the RLC SDU and
constructs and transmits a RLC PDU.
Example of General Operation of Frotocol Layer
according to Embodiment of the Invention
An embodiment of the present invention suggests a
method for effectively managing data while satisfying
Quality of Service (QoS) of an established (or configured)
Radio Bearer (RB). To accomplish this, the embodiment of
the present invention decides whether or not to discard
data stored in a protocol layer entity of the transmitting
side taking into consideration an allowed transfer time or
a maximum allowed delay of data and a maximum buffer size
that can be accommodated by the protocol layer entity of
the transmitting side. Preferably, the protocol layer is a
PDCP layer. An examplary general operation of the
embodiment of the present invention is described in detail
below focusing on the PDCP layer. Here, the term "discard"
can be used interchangeably with similar terms such as
"deletion", "delete", "abandon", "erase", "remove" and the
like.
In an embodiment of the present invention, the PDCP
entity can decide whether or not to discard a PDCP SDU when
transmission of the PDCP SDU has been delayed for a
predetermined time in order to guarantee QoS of an
established RB. The predetermined time can be set flexibly
taking into consideration the type of data to be
transmitted. The predetermined time can be set by the
network. Preferably, the predetermined time can be set by
a layer (e.g., RRC layer) above the PDCP layer. If needed,
the PDCP SDU and/or PDC? PDU may not be discarded even when
the predetermined time has elapsed.
In an embodiment, the PDCP entity starts (in other
terms, activates, runs or operates) a timer for a FDCP SDU
when the PDCP SDU is received from an upper layer.
Preferably, the upper layer is a Radio Resource Control
(RRC) layer. The timer can run individually for each PDCP
SDU. The timer can also run commonly for a specific number
of PDCP SDUs or a specific group of PDCP SDUs. For example,
when a specific number of related PDCP SDUs or a specific
group of PDCP SDUs is present, the timer can run only for
the first PDCP SDU.
When the RLC entity has notified the PDCP entity that
the RLC SDU (i.e., PDCP PDU) has been successfully
transmitted while the timer is running, the PDCP entity can
discard the PDCP PDU. In an implementation, the PDCP
entity can discard a PDCP PDU when PDCP PDUs with serial
numbers lower than that of the PDCP PDU have been
successfully transmitted. The PDCP entity can also discard
a PDCP PDU when PDCP SDUs previous to a PDCP SDU associated
with the PDCP PDU have been successfully transmitted. When
the PDCP PDU has been discarded, a timer of the PDCP SDU
associated with the PDCP PDU is stopped. Preferably, the
PDCP SDU whose timer has been stopped is discarded.
When the timer expires while the PDCP entity has not
received any notification of whether or not the PDCP PDU
has been successfully transmitted from the RLC entity, the
PDCP entity can decide to discard a PDCP SDU associated
with the timer. The timer can be given a variety of names
depending on its function. In an embodiment of the present
invention, the timer can be referred to as a
"discard_timer" since it is associated with discarding data
of the PDCP layer.
In an implementation, the value of the timer can be
set by the network. Preferably, the value of the timer can
be set by a layer (e.g., RRC layer) above the PDCP layer.
The value of the timer is a setting associated with the
timer. For example, the value of the timer may indicate a
PDCP SDU or a PDCP PDU, based on which the timer will run.
The value of the timer can also indicate an oneration
performed at the PDCP layer, based on which the timer will
run. The value of the timer may also include information
associated with the time when the timer will expire after
it is activated (i.e., information associated with the
timer's expiration time). The timer's expiration time can
be set taking into consideration all times associated with
transmission of an IP packet (e.g., each duration the IP
packet stays at the RLC entity and the PDCP entity, a
transmission period, the maximum allowable delay of data,
etc.).
In addition, the timer expiration time can be set
flexibly according to data type since not all IP packets or
PDCP PDUs have the same importance. For example, a full-
header packet is essential to form a context of header
compression. Accordingly, a different timer value can be
set according to the characteristics or attributes of
packets. A timer may not be activated or the expiration
time thereof may be set to infinity for a specified packet
or PDCP PDU/SDU. Alternatively, the discard process may
not be performed for the specified packet or PDCP PDU/SDU
even when the timer has expired.
When the PDCP entity has decided to discard a
specific PDCP SDU and a PDCP PDU associated with the PDCP
SDU has not been transferred to the RLC entity, the PDCP
entity provides no notification to the RLC entity and
discards the PDCP SDU. Preferably, the PDCP entity
discards the PDCP PDU associated with the PDCP SDU together
with the PDCP SDU.
When the PDCP entity has decided to discard a
specific PDCP SDU and a PDCP PDU associated with the PDCP
SDU has already been transferred to the RLC entity, the
PDCP entity provides information associated with discard of
the PDCP SDU and/or PDCP PDU to the RLC entity and discards
the PDCP SDU. Preferably, the information associated with
the discard may be information indicating that a certain
PDCP PDU (i.e., RLC SDU) or PDCP SDU has been discarded.
The information associated with the discard may also be
information requesting that the associated RLC SDU should
be discarded or information used to request that the
associated RLC SDU should be discarded.
In the above procedure, when the PDCP SDU has been
discarded, it is assumed that the associated PDCP PDU has
been successfully transmitted and the successful
transmission is reported to an upper layer.
In the above procedure, when the RLC entity receives
the information associated with the discard of a specific
PDCP SDU and/or PDCP PDU (i.e., RLC SDU) from the PDCP
entity, the RLC entity performs an operation for discarding
an associated RLC SDU.
The UM RLC entity discards the associated RLC SDU and
no longer attempts to transmit a RLC PDU associated with
the RLC SDU.
The AM RLC entity performs an operation for
discarding the associated RLC SDU. Preferably, the
operation includes an operation of a RLC entity of a
transmitting side to notify a RLC entity of a receiving
side of a command indicating that the RLC SDU will no
longer be transmitted. In this case, the AMD RLC entity of
the transmitting side can also notify the AM RLC entity of
the receiving side of a serial number cf a lower boundary
of a reception RLC window or a transmission RLC window in
association with the discarded RLC SDU. The AMD RLC entity
of the transmitting side can notify the AM RLC entity of
the receiving side of information associated with byte-
offset together with the serial number.
Preferably, the RLC entity may discard the RLC SDU
when no part of the RLC SDU indicated by the PDCP layer has
been transmitted. For example, in the case where the RLC
SDU is segmented into at least one segment, the RLC SDU may
be discarded if no segment of the RLC SDU has been
transmitted. The transmitting side can determine whether
or not any part of the RLC SDU has been transmitted based
on whether or not the transmitting side has actually-
transmitted any part of the RLC SDU. It does not matter
whether cr not the receiving side has actually received
data. That is, the transmitting side determines whether or
not the data has been transmitted, only from the viewpoint
of the transmitting side.
Preferably, the transmitting side may determine
whether or not any part of the RLC SDU has been transmitted
based on whether or not any part of the RLC SDU has been
mapped to a RLC PDU, preferably to a RLC data PDU. For
example, when an upper layer has requested that a RLC SDU
be discarded, the RLC SDU may be discarded only when no
segment of the RLC SDU has been mapped to a RLC data PDU.
In addition, when the RLC SDU, which has been
requested to be discarded by the upper layer, is
constructed into at least one RLC PDU, the RLC SDU can be
discarded only when no related RLC PDU has been transmitted.
Further, the RLC SDU may not be discarded when the RLC SDU
is included in specific RLC PDUs and it has been attempted
to transmit at least one of the specific RLC PDUs through a
wireless interface. The RLC SDU may also be discarded only
when the RLC SDU is not included in any RLC PDU or when it
has not been attempted to transmit any one of the specific
RLC PDUs through a wireless interface although the RLC SDU
is included in the specific RLC PDUs. Whether or not it
has been attempted to transmit the RLC PDU through a
wireless interface can be determined based on whether or
not any part of the RLC SDU has been mapped to a RLC PDU,
preferably to a RLC data PDU.
Although the above operations have been described
mainly based on a PDCP SDU for ease of explanation, the
operations may also be performed based on a PDCP PDU.
Specifically, a timer may run in association with the PDCP
PDU and associated operations may be performed accordingly.
FIG. 7 illustrates examplary operations of a protocol
layer performed at a UE or base station according to an
embodiment of the present invention.
As shown in FIG. 7, packets A and B are transferred
from an upper layer to a PDCP layer (S710) . PDCP SDUs of
the packets A and B are stored in a PDCP buffer and a
discard_timer starts for each of the packets (S770). A MAC
layer requests that a RLC layer transfer new MAC SDUs (RLC
PDUs) (S720) . If the RLC layer has no new data to be
transmitted, the RLC layer requests that a PDCP layer
transfer new RLC SDUs (PDCP PDUs) (S730) . The PDCP layer
performs header compression, ciphering and header addition
on the PDCP SDUs of the packet A to create PDCP PDUs of the
packet A (S740) . The PDCP layer transfers the PDCP PDUs of
the packet A to the RLC layer (S750) . The RLC layer stores
the PDCP PDUs (i.e., RLC SDUs) of the packet A in a RLC
buffer. The RLC layer constructs a RLC PDD from the
received RLC SDU of the packet A and transfers the RLC PDU
to the MAC layer. The MAC/PHY layers perform transmission
of the RLC PDU (S760).
In FIG. 7, it is assumed that the PDCP layer has not
received information, indicating that the receiving side
has successfully received the PDCP PDU of the packet A,
from the RLC layer until a discard_timer of the PDCP SDU
for the packet A expires. It is also assumed that a
discard_timer of the PDCP SDU for the packet B has expired
almost at the same time.
Since the discard_timers for the packets A and B have
expired, the PDCP layer decides to discard the packets A
and B from the buffer (S770) . Since the packet B has not
yet been assigned a SN and has not been compressed or
ciphered, the packet B is removed from the PDCP entity and
the RLC entity is not notified that the packet B has been
discarded.
On the other hand, since the packet A has been
assigned a SN and has already been compressed and
transferred to the RLC entity, the PDCP layer requests that
the RLC layer should discard a RLC SDU associated with the
packet A (S780) . According to this notification, the RLC
layer performs an operation for discarding the RLC SDU.
The operation for discarding the RLC layer is described in
more detail with reference to FIG. 8.
FIG. 8 illustrates examplary operations of a protocol
layer performed at a UE or base station according to
another embodiment of the present invention.
As shown in FIG. 8, a PDCP layer receives data blocks
such as IP packets from an upper layer (811-813). The PDCP
layer adds a SN to each of the received blocks and stores
the blocks in a PDCP SDU buffer (821-823). At a request of
a lower layer, the PDCP layer constructs PDCP SDUs into
PDCP data PDUs and transfers the PDCP data PDUs to the RLC
layer (831, 832 and 834). In this case, the PDCP layer can
also generates a PDCP control PDU (833) including feedback
information or the like associated with header compression
into. The RLC layer stores the received RLC SDUs in a RLC
SDU buffer (831-834) . At a request of a lower layer, the
RLC layer may segment and concatenate the RLC SDUs to
construct a plurality of RLC PDUs (841-844) .
Although not illustrated in FIG. 8, when the PDCP
layer receives a data block or stores data in the PDCP SDU
buffer, a discard_timer is activated for each PDCP SDU, a
specific number of PDCP SDUs or a specific group of PDCP
SDUs. Alternatively, the discard_timer can run based on
the PDCP PDU.
The procedure in which the PDCP layer decides whether
or not to discard the PDCP SDU is similar to that of FIG. 7.
The following is a description of examplary operations of
the PDCP layer in association with a PDCP control PDU
according to another embodiment. Thereafter, the
description will be given focusing on an operation of the
RLC layer to discard a RLC SDU according to an instruction
from the PDCP layer. The procedure of the RLC layer to
discard the RLC SDU is applied to both the examples of FIGs.
7 and 8.
As shown in FIG. 3, PDCP data PDUs 831, 832, and 834
and a PDCP control PDU 833 are created in association with
a PDCP SDU. In the example of FIG. 8, the PDCP control PDU
833 includes feedback information associated with header
compression.
When the fact that the PDCP control PDU can be
created in association with a PDCP SDU is taken into
consideration, a PDCP control PDU associated with a
specific PDCP SDU can be discarded when the specific PDCP
SDU is discarded. For example, a PDCP data PDU is created
immediately after header compression is performed on the
specific PDCP SDU. In this case, a PDCP control PDU can
also be created. Here, the PDCP control PDU and the PDCP
data PDU can be discarded together since they are
associated with the PDCP SDU. Preferably, when a PDCP
control PDU has been generated, the PDCP control PDU is
discarded when a PDCP SDU generated simultaneously with the
PDCP control PDU is discarded. Preferably, when a PDCP
control PDU has been generated, the PDCP control PDU is
discarded when a PDCP SDU generated immediately before the
PDCP control PDU is discarded. Preferably, when a PDCP
control PDU has been generated, the PDCP control PDU is
discarded when a PDCP SDU generated next to the PDCP
control PDU is discarded. Preferably, the PDCP control PDU
includes a header compression packet.
In addition, when the fact that not all PDCP control
PDUs are associated with a PDCP SDU is taken into
consideration, the PDCP control PDU may not be discarded
even when the specific PDCP SDU has been discarded.
Preferably, when a PDCP control PDU has been generated, the
PDCP control PDU is not discarded even when a PDCP SDU
generated simultaneously with the PDCP control PDU is
discarded. Preferably, when a PDCP control PDU has been
generated, the PDCP control PDU is not discarded even when
a PDCP SDU generated immediately before the PDCP control
PDU is discarded. Preferably, when a PDCP control PDU has
been generated, the PDCP control PDU is not discarded even
when a PDCP SDU generated next to the PDCP control PDU is
discarded. Preferably, the PDCP control PDU is a PDCP
status report.
A separate timer can also run for a PDCP control PDU.
Preferably, a separate timer starts for a PDCP control PDU
when the PDCP control PDU is generated and the PDCP control
PDU is discarded when the timer expires. Preferably, the
same timer as that applied to a PDCP data PDU starts for a
PDCP control PDU when the PDCP control PDU is generated and
the PDCP control PDU is discarded when the timer expires.
In this case, different timer values can be set for both
the PDCP data PDU and the PDCP control PDU.
In the above procedure, when a PDCP control PDU has
been discarded, the PDC? entity notifies the RLC layer that
the PDCP control PDU has been discarded. That is, the PDCP
entity determines data to be discarded to guarantee QoS and
instructs the RLC entity below the PDCP entity to discard a
corresponding RLC SDU. The following is a description of
an examplary procedure in which the RLC layer discards a
specific RLC SDU when the PDCP layer has instructed the RLC
layer to discard the RLC SDU.
As shown in FIG. 8, one RLC SDU may be divided into a
plurality of RLC PDUs to be transmitted or one RLC PDU may
include a plurality of RLC SDUs.
In the procedure for discarding specific RLC SDUs
according to an instruction of the PDCP layer, removal of a
RLC PDU including a plurality of RLC SDUs is wasteful if it
is only necessary to discard some of the plurality of RLC
SDUs included in the RLC PDU. In this case, the
transmitting side of the AM RLC entity should not attempt
to transmit RLC SDUs that were discarded according to the
instruction of the PDCP layer and should attempt to
retransmit other RLC SDUs until the RLC entity of the
receiving side notifies the transmitting side of successful
reception. To accomplish this, the transmitting side of
the RLC entity may divide the RLC PDU (particularly, the AM
RLC data PDU) to construct AM RLC data PDU segments that do
not include the discarded RLC SDUs and then transmit the AM
RLC data PDU segments to the receiving side. That is, when
a RLC SDU has been discarded, the AM RLC data PDU segments
including the discarded RLC SDU are no longer transmitted.
In the procedure for discarding specific RLC SDUs
according to an instruction of the PDCP layer, the UM RLC
entity discards all RLC PDUs including the RLC SDU and no
longer transmits the discarded RLC PDUs. The UM RLC entity
also discards the RLC SDU and no longer transmits
associated RLC PDUs.
Preferably, even when the PDCP layer has instructed
to discard a specific RLC SDU, the RLC SDU may be removed
from the RLC buffer only when no part of the RLC SDU has
been attempted to be transmitted or has been transmitted.
That is, in the case where the RLC SDU has been divided
into a plurality of segments, the RLC SDU can be removed
from the RLC buffer only when no segment of the RLC SDU has
been attempted to be transmitted or has been transmitted.
For example, the RLC SDU may be removed from the RLC buffer
only when no segment of the RLC SDU has been mapped to a
RLC data PDU.
According to the embodiments of the present invention,
it is possible to satisfy QoS of an established radio
bearer and to effectively manage data in multiple protocol
layers.
The above embodiments are provided by combining
components and features of the present invention in
specific forms. The components or features of the present
invention should be considered optional if not explicitly
stated otherwise. The components or features may be
implemented without being combined with other components or
features. The embodiments of the present invention may
also be provided by combining some of the components and/or
features. The order of the operations described above 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 will be apparent that claims which are not explicitly
dependent on each other can be combined to provide an
embodiment or new claims can be added through amendment
after this application is filed.
The above embodiments of the present invention have
been described focusing mainly on the data communication
relationship between a UE (or terminal) and a Base Station
(BS) . Specific operations which have been described as
being performed by the BS may also be performed by upper
nodes as needed. That is, it will be apparent to those
skilled in the art that the BS or any other network node
may perform various operations for communication with
terminals in a network including a number of network nodes
including BSs. The term "base station (BS)" may be
replaced with another term such as "fixed station", "Node
B", "eNode B (eNB)", or "access point". The term
"terminal" may also be replaced with another term such as
"user equipment (UE)", "mobile station (MS)", "mobile
station (MS)", or "mobile subscriber station (MSS)".
The embodiments of the present invention can be
implemented by hardware, firmware, software, or any
combination thereof. In the case where the present
invention is implemented by hardware, an embodiment of the
present invention may be implemented by one or more
application specific integrated circuits (ASICs), digital
signal processors (DSPs), digital signal processing devices
(DSPDs), programmable logic devices (PLDs), field
programmable gate arrays (FPGAs), processors, controllers,
microcontrollers, microprocessors, or the like.
In the case where the present invention is
implemented by firmware or software, the embodiments of the
present invention may be implemented in the form of modules,
processes, functions, or the like which perform the
features or operations described above. Software code can
be stored in a memory unit so that it can be executed by a
processor. The memory unit may be located inside or
outside the processor and can communicate data with the
processor through a variety of known means.
INDUSTRIAL APPLICABILITY
Those skilled in the art will appreciate that the
present invention may be embodied in other specific forms
than those set forth herein without departing from the
spirit and essential characteristics of the present
invention. The above description is therefore to be
construed in all aspects as illustrative and not
restrictive. The scope of the invention should be
determined by reasonable interpretation of the appended
claims and all changes coming within the equivalency range
of the invention are intended to be embraced in the scope
of the invention.
WHAT IS CLAIMED IS:
1. A method of processing data by a user equipment
in a wireless mobile communication system, the method
comprising the steps of:
receiving a first data block from an upper layer;
transferring a second data block including the first
data block to a lower layer at a particular protocol layer;
discarding the first and second data blocks present
in the particular protocol layer if a certain period of
time has passed; and
transferring an information associated with the
discard of the second data block to the lower layer.
2. A method of processing data by a user equipment
in a wireless mobile communication system, the method
comprising the steps of:
operating a timer for a first data block at a
particular protocol layer when receiving the first data
block from an upper layer;
transferring a second data block including the first
data block to a lower layer at a particular protocol layer;
discarding the first and second data blocks present
in the particular protocol layer if the timer expires; and
transferring an information associated with the
discard of the second data block to the lower layer.
3. The method of claim 1 or 2, wherein the
information associated with the discard serves to indicate
the discard of the second data block or to instruct the
lower layer to discard the second data block.
4. The method of claim 1 or 2, further comprising
the step of discarding the second data block by the lower
layer if no part of the second data block has been
transmitted.
5. The method of claim 1 or 2, wherein the
particular protocol layer is a Packet Data Convergence
Protocol (PDCP) layer.
6. The method of claim 5, wherein the first data
block is a PDCP Service Data Unit (PDCP SDU).
7. The method of claim 5, wherein the second data
block is a PDCP Protocol Data Unit (PDCP PDU).
8. The method of claim 5, wherein the upper layer
is a Radio Resource Control (RRC) layer.
9. The method of claim 5, wherein the lower layer
is a Radio Link Control (RLC) layer.
10. The method of claim 3, wherein the RLC layer
operates in an Acknowledged Mode (AM) or an Unacknowledged
Mode (UM).
11. The method of claim 1, wherein the certain
period of time is indicated by a network.
12. The method of claim 1, wherein the certain
period of time is indicated by an upper layer above the
particular protocol layer.
13. The method of claim 2, wherein a value of the
timer is indicated by a network.
14. The method of claim 2, wherein a value of the
timer is indicated by an upper layer above the particular
protocol layer.
15. A method of processing data by a user equipment
in a wireless mobile communication system, the method
comprising the steps of:
receiving a data block from an upper layer;
receiving information associated with discard of the
data block from the upper layer; and
discarding the data block at a particular protocol
layer if no part of the data block has been transmitted.
16. The method of claim 15, wherein the information
associated with the discard serves to indicate the discard
of the data block or to instruct discard of the data block.
17. The method of claim 15, wherein the upper layer
is a PDCP layer.
18. The method of claim 17, wherein the data block
is a RLC SDU.
19. The method of claim 17, wherein the particular
protocol layer is a RLC layer.
20. The method of claim 19, wherein the RLC layer
operates in an Acknowledged Mode (AM) or an Unacknowledged
Mode (UM).
21. The method of claim 15, wherein, when the data
block is segmented into at least one segment, the data
block is discarded if no segment of the data block has been
transmitted.
22. The method of claim 15, wherein whether or not
any part of the data block has been transmitted is
determined based on whether or not any part of the data
block has been mapped to a data PDU of the particular
protocol layer.

A method in which a user equipment processes data in a wireless mobile communication system is provided. The
method includes the steps of receiving a first data block from an upper layer, transferring a second data block including the first data
block to a lower layer at a particular protocol layer, discarding the first and second data blocks present in the particular protocol layer
if a certain period of time has passed, and transferring information associated with the discard of the second data block to the lower
layer.

Documents:

http://ipindiaonline.gov.in/patentsearch/GrantedSearch/viewdoc.aspx?id=EMwAg3gImXEMjCTuVOBmqQ==&loc=wDBSZCsAt7zoiVrqcFJsRw==

« Previous Patent

Next Patent »

Patent Number

278166

Indian Patent Application Number

4312/KOLNP/2009

PG Journal Number

52/2016

Publication Date

16-Dec-2016

Grant Date

15-Dec-2016

Date of Filing

14-Dec-2009

Name of Patentee

LG ELECTRONICS INC.

Applicant Address

20, YEOUIDO-DONG, YEONGDEUNGPO-GU, SEOUL 150-721 REPUBLIC OF KOREA

Inventors:

#	Inventor's Name	Inventor's Address
1	LEE, YOUNG DAE	LG INSTITUTE, HOGYE 1 (IL)-DONG, DONGAN-GU, ANYANG-SI, GYEONGGI-DO 431-080 REPUBLIC OF KOREA
2	PARK, SUNG JUN	LG INSTITUTE, HOGYE 1 (IL)-DONG, DONGAN-GU, ANYANG-SI, GYEONGGI-DO 431-080 REPUBLIC OF KOREA
3	YI, SEUNG JUNE	LG INSTITUTE, HOGYE 1 (IL)-DONG, DONGAN-GU, ANYANG-SI, GYEONGGI-DO 431-080 REPUBLIC OF KOREA
4	CHUN, SUNG DUCK	LG INSTITUTE, HOGYE 1 (IL)-DONG, DONGAN-GU, ANYANG-SI, GYEONGGI-DO 431-080 REPUBLIC OF KOREA

PCT International Classification Number

H04L12/56; H04L12/56

PCT International Application Number

PCT/KR2008/005519

PCT International Filing date

2008-09-18

PCT Conventions:

#	PCT Application Number	Date of Convention	Priority Country
1	60/976,800	2007-10-02	U.S.A.
2	60/983,304	2007-10-29	U.S.A.
3	60/973,442	2007-09-18	U.S.A.
4	10-2008-0091192	2008-09-17	U.S.A.