JP2011508560A - Mobile communication system and PDCP status report transfer method thereof - Google Patents

Abstract

The present invention relates to a mobile communication system capable of preventing occurrence of data loss at the time of RLC reconfiguration and a PDCP status report transfer method thereof. When an RLC reconfiguration occurs due to an RLC internal error, the receiving PDCP entity triggers a status report and forwards it to the transmitting PDCP entity even if the PDCP entity does not change. The transmitting PDCP entity confirms the reception status of each PDCP SDU based on the triggered PDCP status report, and then retransmits the PDCP SDU that is not normally received by the receiving PDCP entity.

Description

  This application is based on US Provisional Application No. 61 / 025,311 filed on Feb. 1, 2008, and Korean Patent Application No. 10-2009-0007574 filed on South Korea on Jan. 30, 2009. As a basis for claiming priority, the contents of all of which are hereby incorporated by reference.

  The present invention relates to an LTE (Long Term Evolution) system, and in particular, a mobile communication system for transferring a PDCP (Packet Data Convergence Protocol) status report when reconfiguring an RLC (Radio Link Control), and a method for transferring the PDCP status report About.

  FIG. 1 is a diagram illustrating an example of a network structure of E-UMTS (Evolved Universal Mobile Telecommunication Systems). E-UMTS has evolved from the existing Universal Mobile Telecommunications System (UMTS), and standardization work for E-UMTS is performed by 3GPP (Third Generation Partnership Project). E-UMTS is also called an LTE system.

  The LTE network includes an E-UTRAN (Evolved UMTS Terrestrial Radio Access Network) and a CN (Core Network). The E-UTRAN includes a UE (User Equipment), an eNB (Evolved NodeB), and an aGW (Access Gateway) that is located at the end of the network and is connected to an external network.

  The aGW is divided into a first part for handling user traffic and a second part for handling control traffic. The aGW part for processing the user traffic and the aGW part for processing the control traffic can be connected via a communication interface.

  One eNB has one or more cells. A plurality of eNBs are connected to each other via an interface for transmitting the user traffic and / or control traffic. The CN includes an aGW and a node for user registration of the UE. An interface for distinguishing between E-UTRAN and CN in UMTS can also be used.

  2 and 3 are diagrams showing the structure of a radio interface protocol between a mobile terminal and E-UTRAN in conformity with the 3GPP radio access network standard.

  The radio interface protocol includes a physical layer, a data link layer, and a network layer in the horizontal direction, and a user plane (U-plane) for transmitting data information and a control signal transmission in the vertical direction. Control plane (C-plane). The protocol layers shown in FIG. 2 and FIG. 3 are based on the lower three layers of the Open System Interconnection (OSI) reference model, which is well known in the interconnection scheme, the first layer (L1), It is divided into a second layer (L2) and a third layer (L3).

  Such a radio protocol layer exists in pairs between the mobile terminal and the E-UTRAN, and is responsible for data transmission in the radio section.

  Hereinafter, the radio protocol layers of the control plane shown in FIG. 2 and the user plane shown in FIG. 3 will be described. As described above, the physical layer, which is the first layer, provides an information transfer service to an upper layer. The physical layer is connected to an upper layer, for example, a MAC (Medium Access Control) layer via a transport channel, and data transmission between the MAC layer and the physical layer is performed via the transport channel. Here, the transport channel is divided into a dedicated transport channel and a common transport channel according to a channel sharing state. Further, data transmission is performed between different physical layers, for example, a transmission-side physical layer and a reception-side physical layer via a physical channel using radio resources.

  The second layer includes a plurality of layers. First, the MAC layer plays a role of mapping a plurality of logical channels to a plurality of transport channels, and also plays a role of logical channel multiplexing for mapping a plurality of logical channels to one transport channel. The MAC layer is connected to the RLC layer, which is an upper layer, via a logical channel, and the logical channel largely includes a control channel for transmitting control plane information and a user plane depending on the type of information to be transmitted. And a traffic channel for transmitting information.

  The RLC layer of the second layer plays a role of adjusting data size so as to be suitable for data transmission in the radio section in the lower layer by segmenting and concatenating data received from the upper layer.

  The RLC layer includes a transparent mode (TM), a non-acknowledged mode (UM), and a response mode in order to guarantee various QoS required by each radio bearer (RB). (Acknowledged Mode; AM) three operation modes are provided. In particular, the AM RLC performs a retransmission function using an automatic repeat request (ARQ) function for reliable data transmission.

  The second PDCP layer is located above the RLC layer. The PDCP layer is used to efficiently transmit data using IP packets such as IPv4 and IPv6 in a wireless section having a relatively narrow bandwidth. For this reason, the PDCP layer reduces unnecessary control information by a function such as header compression. The header compression by the PDCP layer plays a role of efficiently transmitting data in a wireless section by transmitting only necessary information in the header portion of the data. In the LTE system, the PDCP layer also performs a security function. The security functions include an encryption function for preventing third party data eavesdropping and an integrity protection function for preventing third party data manipulation.

  The RRC (Radio Resource Control) layer located at the top of the third layer is defined only in the control plane, and is associated with a logical channel, a transport channel, a radio channel (RB) setting, reconfiguration, and release. And is responsible for controlling physical channels. Here, RB means a logical path provided by the first and second layers of the radio protocol for data transmission between the mobile terminal and the UTRAN. In general, RB setting refers to a process of defining characteristics of a radio protocol layer and a channel necessary for providing a specific service, and setting specific parameters and operation methods. RB is divided into SRB (Signaling Radio Bearer) and DRB (Data Radio Bearer), but SRB is used as a route for transmitting RRC messages in the control plane, and DRB is used as a route for transmitting user data in the user plane. The

  Hereinafter, the PDCP entity will be specifically described.

  As shown in FIG. 2, the PDCP entity has an RRC layer or user application connected at the upper level and an RLC layer connected at the lower level.

  FIG. 4 is a diagram illustrating a detailed structure of the PDCP entity. The illustrated block is a functional block and may differ from the actual block.

  Referring to FIG. 4, one PDCP entity includes a transmission PDCP entity and a reception PDCP entity. The left transmission PDCP entity configures a service data unit (Service Data Unit; SDU) received from an upper layer or control information uniquely generated by the PDCP entity into a protocol data unit (Protocol Data Unit; PDU), and receives the PDCP entity. (Peer entity). Then, the right receiving PDCP entity extracts PDCP SDU or control information from the PDCP PDU received from the transmitting PDCP entity (peer entity).

  As described above, the PDU generated by the transmission PDCP entity includes a data PDU (Data PDU) and a control PDU (Control PDU). The data PDU is a data block generated by processing the SDU received by the PDCP from an upper layer, and the control PDU is a data block generated uniquely by the PDCP for transmitting control information to a peer entity. is there.

  The data PDU is generated in both the RB of the user plane and the control plane, but some functions of the PDCP are selectively applied according to the plane to be used.

  More specifically, the header compression function is applied only to user plane data, and the integrity protection function of the security functions is applied only to control plane data. The security function includes an encryption function for data security in addition to the integrity protection function, and the encryption function is applied to both user plane and control plane data.

  The control PDU is generated only in the user plane RB. In addition, the control PDU is informed of the status report (Status Report) for notifying the reception side of the PDCP buffer to the transmission side, and the header decompressor (Header Compressor) status of the header decompressor (Header Compressor). There is a header compression (HC) feedback packet.

  The status report is transferred from the receiving PDCP entity to the transmitting PDCP entity. Accordingly, the reception PDCP entity notifies the transmission PDCP entity of the reception state of each PDCP SDU, so that the PDCP SDU received by the transmission PDCP entity is not retransmitted, and the PDCP SDU not received is retransmitted. The PDCP status report is transferred in the form of a PDCP STATUS PDU.

  FIG. 5 is a diagram illustrating the structure of a PDCP STATUS PDU.

  Referring to FIG. 5, the PDCP STATUS PDU includes a 1-bit D / C (Data / Control) indicating whether the PDU is a data PDU or a control PDU, and a 3-bit PDU type indicating the type of the control PDU. Including. Here, if the PDU type is “000”, it indicates a PDCP status report, if “001”, header compression feedback information is indicated, and the remaining values indicate reserved PDUs (reserved PDUs).

  Further, the PDCP STATUS PDU has successfully received a 12-bit FMS (First Missing SN) indicating the sequence number (SN) of the PDCP SDU that the receiving side failed to receive first, and a PDCP SDU satisfying modulo 4096. And a variable-length bitmap indicating the above. Here, if the corresponding bit position in the bitmap field is 0, PDCP SDU reception failure is indicated, and if it is 1, PDCP SDU reception success is indicated. The PDCP SDU SN is composed of the FMS and the bit position.

  In the LTE system, the PDCP status report is used at the time of handover.

  First, after transmitting a PDCP SDU from an upper layer, the transmission PDCP entity stores it in a transmission buffer for retransmission that will be requested in the future.

  When a handover occurs, the transmitting PDCP entity receives information on whether or not the receiving PDCP entity has successfully received the PDCP SDU through a PDCP status report. Next, the transmitting PDCP entity retransmits PDCP SDUs not received by the receiving PDCP entity after handover. In particular, on the network side, when a handover occurs, the eNB changes from the source to the target, and the PDCP entity changes. Therefore, retransmission using such a status report is always necessary.

  In the prior art, retransmission of the PDCP layer is allowed only at the time of handover, and data loss is usually prevented by using a retransmission function of AM RLC. That is, only when the base station (eNB) changes and the PDCP entity changes as in handover, the PDCP layer is allowed to be retransmitted after handover in order to prevent data loss that may occur in the process. Therefore, in the prior art, the transfer of the PDCP status report is allowed only when a handover occurs.

  However, such a conventional method has the following problems.

  When an RLC internal error such as retransmission of endless RLC occurs in the RLC layer below PDCP, the RLC entity is reconfigured. However, even when RLC reconfiguration occurs in this way, PDCP retransmission is necessary. It is. The reason for this is that when an RLC reconfiguration occurs, both the transmitting RLC entity and the receiving RLC entity are reconfigured, but when the RLC reconfiguration occurs, the transmitting RLC PDU (outstanding RLC PDU) is determined by the receiving RLC entity. This is because it is not known whether the data has been received normally.

  That is, since the PDCP entity does not know the transmission result of the transmitting RLC PDU (outbound RLC PDU) when the RLC reconfiguration occurs, the PDCP entity confirms the transmission result, and after the RLC reconfiguration, the PDCP SDU that failed to transmit A resending process is required.

  Accordingly, an object of the present invention is to provide a mobile communication system capable of reducing data loss due to RLC reconfiguration by transferring a status report to the PDCP layer at the time of RLC reconfiguration, and a method for transferring the PDCP status report. There is to do.

  To achieve the above object, the present invention includes receiving an indication that a receiving PDCP entity has detected a layer 2 error with RLC reconfiguration, and triggering a PDCP status report by the RLC reconfiguration. And a PDCP status report transfer method comprising: configuring the PDCP status report; and transferring the configured PDCP status report to a transmitting PDCP entity after the RLC reconfiguration is completed.

  Preferably, the reception step, the trigger step, and the transfer step are performed using a radio bearer mapped to RLC AM.

  The indication is preferably received from a higher layer.

  The indication is preferably received from a lower layer.

  The second layer error preferably includes an RLC error.

  The second layer error is preferably an error not related to a handover procedure.

  The PDCP status report preferably indicates whether a PDCP SDU has been received.

  The PDCP status report is preferably configured after processing the PDCP data PDU received from the RLC by the RLC reconfiguration.

  To achieve the above objective, the present invention provides a receiving PDCP entity configured to configure and forward a PDCP status report upon receiving an indication that a layer 2 error with RLC reconfiguration has been detected. And a transmitting PDCP entity configured to retransmit the PDCP SDU that the receiving PDCP entity failed to receive based on the forwarded PDCP status report.

  The receiving PDCP entity triggers a PDCP status report by the RLC reconfiguration when the layer 2 error is detected, configures the PDCP status report, and after the RLC reconfiguration is completed, the configured Preferably, a PDCP status report is forwarded to the sending PDCP entity.

  The indication is preferably received from a higher layer.

  The indication is preferably received from a lower layer.

  The second layer error preferably includes an RLC error.

  The second layer error is preferably an error not related to a handover procedure.

  The PDCP status report preferably indicates whether the PDCP SDU has been received normally.

  The PDCP status report is preferably configured after processing the PDCP data PDU received from the RLC by the RLC reconfiguration.

  As described above, when RLC reconfiguration occurs due to an RLC internal error, even if the PDCP entity does not change, the receiving PDCP entity triggers a status report and forwards it to the transmitting PDCP entity, and the transmitting PDCP entity After confirming the reception status of each PDCP SDU based on the PDCP status report, it is possible to prevent data loss in any case by retransmitting the PDCP SDU that failed to be transmitted.

It is a figure which shows the network structure of the LTE system which is a mobile communication system with which a prior art and this invention are applied. It is a figure which shows each layer of the control plane of a radio protocol. It is a figure which shows each layer of the user plane of a radio | wireless protocol. It is a figure which shows the detailed structure of a PDCP entity. It is a figure which shows the structure of PDCP STATUS PDU. 3 is a flowchart illustrating a method for transferring a status report of a mobile communication system according to a preferred embodiment of the present invention.

  The present invention applies to mobile communication systems, especially E-UMTS evolved from UMTS. However, the present invention is not limited to this, and can be applied to all communication systems and communication protocols to which the technical idea of the present invention can be applied.

  Hereinafter, preferred embodiments of the present invention will be described in detail.

  In general, when an RLC internal error such as retransmission of an end RLC occurs in an RLC layer below PDCP, the RLC entity is reset. When the RLC reconfiguration occurs, both the transmitting RLC entity and the receiving RLC entity are reconfigured. Therefore, when the RLC reconfiguration occurs, the transmitting RLC PDU (outstanding RLC PDU) is successfully received by the receiving RLC entity. It is not known whether or not (data loss may occur).

  Therefore, not only when a handover occurs but also when an RLC reconfiguration occurs due to an RLC internal error, the transmitting PDCP needs to retransmit the PDCP SDU based on the status report transferred from the receiving PDCP.

  A PDCP status report transfer method according to the present invention includes receiving an indication that a receiving PDCP entity has detected a layer 2 error with RLC reconfiguration, triggering a PDCP status report by the RLC reconfiguration, and Configuring a PDCP status report and forwarding the configured PDCP status report to a transmitting PDCP entity after the RLC reconfiguration is completed.

  The reception step, the trigger step, and the transfer step are performed using a radio bearer mapped to RLC AM.

  The indication is received from a higher layer.

  The indication is received from a lower layer.

  The second layer error includes an RLC error.

  The layer 2 error is an error not related to the handover procedure.

  The PDCP status report indicates whether a PDCP SDU has been received.

  The PDCP status report is configured after processing the PDCP data PDU received from the RLC by the RLC reconfiguration.

  That is, in the present invention, when the lower RLC layer is reconfigured to prevent data loss, even if the PDCP entity does not change, the receiving PDCP entity forwards the PDCP status report to the transmitting PDCP entity, and the transmission The PDCP entity confirms the reception status of each PDCP SDU based on the transferred PDCP status report, and then retransmits the PDCP SDU that failed to be transmitted.

  Therefore, in the present invention, the PDCP layer and the RLC layer perform the following operations.

  The RLC confirms whether RLC reconfiguration occurs due to an internal error such as retransmission of the endless RLC. When the RLC reconfiguration occurs, the RLC notifies the upper layer of the RLC (PDCP) and the upper layer of the RLC peer RLC (peer PDCP).

  Various methods for the RLC to notify the RLC reconfiguration to the upper layer (PDCP) of the RLC can be realized.

  For example, the RLC may immediately notify the RLC reconfiguration to the upper layer (PDCP) of the RLC, the RLC notifies the control layer (RRC) of the RLC reconfiguration, and the RRC notifies the RCP reconfiguration to the PDCP layer. You may make it notify.

  Various methods can also be realized in which the RLC notifies the RLC reconfiguration to the upper layer of the RLC peer RLC (peer PDCP).

  For example, the RLC may notify the RLC reconfiguration to the peer RLC using a RESET PDU or the like, and the peer RLC may notify the RLC reconfiguration to the upper layer (peer PDCP) of the peer RLC. Alternatively, the RLC may notify the control layer (RRC) of the RLC reconfiguration, the RRC may notify the peer RRC of the RLC reconfiguration, and the peer RRC may notify the peer PDCP of the RLC reconfiguration.

  Among the PDCPs notified of the RLC reconfiguration, the receiving PDCP entity transmits a PDCP status report to the transmitting PDCP entity to notify the reception status of the receiving side, and the transmitting PDCP entity to which the PDCP status report is transferred includes the RLC After the reconfiguration, the PDCP SDU not received by the receiving PDCP entity is retransmitted.

  That is, when RLC reconfiguration is notified from RLC or RRC to PDCP, the reception PDCP entity grasps the status of the reception buffer of the reception PDCP entity and transfers the PDCP status report to the transmission PDCP entity.

  In order to accurately report the PDCP status, the receiving PDCP entity must know whether the reception was successful in consideration of the PDCP SDU transferred to the PDCP entity due to RLC reconfiguration when grasping the status of the receiving buffer. I must. RLC typically forwards RLC SDUs in-sequence to PDCP entities, but in an RLC reconfiguration situation, it forwards successfully received RLC SDUs to PDCP entities out-of-sequence. To do. Therefore, the receiving PDCP entity knows whether the PDCP SDU has been successfully received by restoring the header of the PDCP PDU.

  When the PDCP status report is transferred from the receiving PDCP entity, the transmitting PDCP entity accurately grasps the PDCP SDU that has failed to be transmitted, and retransmits the PDCP SDU that has failed to be transmitted after RLC reconfiguration.

  FIG. 6 is a flowchart illustrating a method for transferring a status report of a mobile communication system according to a preferred embodiment of the present invention.

  Referring to FIG. 6, the transmitting RLC entity or the receiving RLC entity continues to confirm the occurrence of RLC reconfiguration (S10). When the RLC reconfiguration is detected, the RLC performs an operation of sharing the RLC reconfiguration information (S11).

  The sharing of the RLC reconfiguration information means that the RLC immediately notifies the PDCP of the RLC reconfiguration, or the RLC notifies the control layer (RRC) of the RLC reconfiguration and the RRC notifies the PDCP of the RLC reconfiguration. Is done.

  Also, the sharing of the RLC reconfiguration information may be performed by the RLC notifying the peer RLC of the RLC reconfiguration through a RESET PDU or the like, and the peer RLC notifying the RLC reconfiguration to the upper layer (peer PDCP) of the peer RLC, or This is done by the RLC notifying the RLC reconfiguration to the control layer (RRC), the RRC notifying the RLC reconfiguration to the peer RRC, and the peer RRC notifying the peer PDCP of the RLC reconfiguration.

  When the RLC reconfiguration information is shared, the reception PDCP entity notifies the reception status by transferring the PDCP status report triggered by the RLC reconfiguration to the transmission PDCP entity (S12).

  When the PDCP status report is transferred, the transmitting PDCP entity accurately grasps the PDCP SDU that has been successfully transmitted and the PDCP SDU that has failed to be transmitted, and retransmits the PDCP SDU that has failed to be transmitted (S13).

  The present invention has been described by taking as an example a case where RLC reconfiguration has occurred due to an RLC internal error, but it can also be applied to cases where an internal error in the first and second layers has occurred.

  On the other hand, as described above, the method according to the present invention can be realized by hardware or software, or a combination thereof. For example, the method according to the present invention can be stored in a storage medium (eg internal memory of a mobile terminal, flash memory, hard disk, etc.). The method according to the invention can also be implemented as a code or command word of a software program that can be executed by a processor (for example a microprocessor of a mobile terminal).

  Although the present invention has been described with reference to the above embodiments, this is merely exemplary. It will be apparent to those skilled in the art that various modifications and other equivalent embodiments of the present invention are possible within the spirit and scope of the invention. It will also be understood that the present invention can be realized by selecting and combining the above-described embodiments in whole or in part. Accordingly, the present invention includes various modifications and variations of the present invention provided within the scope of the appended claims and their equivalents.

Claims (16)

Receiving an indication that a layer 2 error with RLC reconfiguration has been detected;
Triggering a PDCP status report by the RLC reconfiguration;
Configuring the PDCP status report;
And transferring the configured PDCP status report to the transmitting PDCP entity after the RLC reconfiguration is completed.   The PDCP state from the receiving PDCP entity to the transmitting PDCP entity according to claim 1, wherein the receiving step, the triggering step, and the forwarding step are performed using a radio bearer mapped to RLC AM. Report transfer method.   The method of claim 1, wherein the indication is received from an upper layer. The PDCP status report transfer method from the reception PDCP entity to the transmission PDCP entity according to claim 1.   The method of claim 1, wherein the indication is received from a lower layer, from a receiving PDCP entity to a transmitting PDCP entity.   The method according to claim 1, wherein the second layer error includes an RLC error.   The method of claim 1, wherein the second layer error is an error that is not related to a handover procedure.   The method of claim 1, wherein the PDCP status report indicates whether a PDCP SDU has been received or not, from the receiving PDCP entity to the transmitting PDCP entity.   The method of claim 1, wherein the PDCP status report is configured after processing the PDCP data PDU received from the RLC by the RLC reconfiguration. . A receiving PDCP entity configured to configure and forward a PDCP status report upon receiving an indication that a layer 2 error with RLC reconfiguration has been detected;
A mobile communication system comprising: a transmission PDCP entity configured to retransmit a PDCP SDU whose transmission success has not been confirmed by the PDCP status report.   The receiving PDCP entity triggers a PDCP status report by the RLC reconfiguration when the layer 2 error is detected, configures the PDCP status report, and after the RLC reconfiguration is completed, the configured The mobile communication system according to claim 9, wherein a PDCP status report is forwarded to the transmitting PDCP entity.   The mobile communication system according to claim 9, wherein the instruction is received from an upper layer.   The mobile communication system according to claim 9, wherein the instruction is received from a lower layer.   The mobile communication system according to claim 9, wherein the second layer error includes an RLC error.   The mobile communication system according to claim 9, wherein the second layer error is an error not related to a handover procedure.   The mobile communication system according to claim 9, wherein the PDCP status report indicates whether a PDCP SDU has been received.   The mobile communication system according to claim 10, wherein the PDCP status report is configured after processing a PDCP data PDU received from an RLC by the RLC reconfiguration.