WO2010066152A1

WO2010066152A1 - Method and system for reducing redundant message retransmission in radio link control (rlc) layer

Info

Publication number: WO2010066152A1
Application number: PCT/CN2009/074697
Authority: WO
Inventors: 李邈; 汤德龙
Original assignee: 中兴通讯股份有限公司
Priority date: 2008-12-10
Filing date: 2009-10-29
Publication date: 2010-06-17
Also published as: CN101753281A; CN101753281B

Abstract

The present invention provides a method and a system for reducing redundant message retransmission in the Radio Link Control (RLC) layer, which are utilized for solve the technical problem of air interface resource waste caused by repeatedly transmitting the redundant message that the receiving end has acknowledged after RLC protocol entity reestablishment. Before the RLC protocol entity receives a reestablishment instruction, every Data Radio Bear (DRB) belonging to the User Equipment (UE) attempts to send a status report to the transmitting end. The transmitting end deletes the messages that have been acknowledged before receiving a reestablishment request and does not retransmit these messages any more after reestablishment is completed to reduce the redundant message retransmission.

Description

Method and system for reducing redundant message retransmission by radio link control layer

The present invention relates to the field of mobile communications, and in particular to a LTE (Long Term Evolution) system, in a Re-establishment procedure of a radio link control layer protocol entity, reducing or avoiding retransmission of redundant words on a transmitting side Method and system. Background technique

The RLC (Radio Link Control) protocol layer is a sublayer of L2 (Layer 2) in the radio interface protocol stack of LTE. It is located above the MAC (Media Access Control) layer, RLC. The protocol layer provides segmentation and retransmission services for user and control data. The functions of the RLC protocol layer include link control, encapsulation and reassembly, cascading, user data transmission, error correction, protocol error detection and repair. Each RLC protocol entity is configured by RRC (Radio Resource Control) and operates in three modes: Transparent Mode (TM), Unacknowledged Mode (UM), and Acknowledge Mode ( Acknowledged Mode, AM).

The ARQ (Auto Repeat Request) in the acknowledge mode is implemented by the receiver sending a Status Report to the sender. The sender determines which PDUs are based on the ACK_SN and NACK_SN in the Status Report. The Data Unit (Protocol Data Unit) has been acknowledged by the receiving end, and which PDUs or PDU fragments need to be retransmitted to ensure the reliability of data transmission. In the 36.322 protocol, in order to prevent the Status Report from being sent too frequently and occupying the air interface resource, a t-StatusProhibit timer is set at the receiving end of the RLC protocol entity, and the timer is started after each Status Report is sent. The Status Report is prohibited from being sent while the timer is running.

On the UE (User Equipment) side and the eNodeB (E-UTRAN NodeB, On the evolved base station side, the UE and the eNodeB establish a peer RLC protocol entity corresponding to each logical channel (Logic Channel) belonging to the UE, and the protocol entity performs a processing flow of the RLC protocol layer. The local end described in this document refers to an RLC protocol entity that is subordinate to a certain UE and corresponds to a specific logical channel in the UE or the eNodeB, and the opposite end is the same as the above, and the same logical channel is corresponding to the protocol entity. A peer RLC protocol entity.

The RLC protocol entity re-establishment procedure refers to the RLC protocol entity, and the entity reset process indicated by the upper layer. In this process, it involves the processing of the current uplink and downlink packets and the setting of the timer. A series of related processes, such as changes in protocol state variables. The present invention is directed to the reconstruction process in the AM confirmation mode.

In the 36.322 protocol, the current description of the re-establishment process of the RLC protocol entity in the AM mode is as shown in FIG. 1: After receiving the RRC re-establishment indication, the receiving end directly delivers all the received messages in the receiving sliding window to the upper layer. That is, the PDCP (Packet Data Convergence Protocol) layer, regardless of whether it is continuous, does not send a Status Report to the sender at this time. After the reestablishment is completed, the sender needs to resend the packet that the receiver has not sent back a response.

The conditions currently triggering the RLC protocol entity reconstruction process include the following categories:

(1) handover, indicated by RRC;

(2) The RLC protocol layer handles the exception;

(3) The network is in a bad situation. If a packet is retransmitted multiple times, it will fail to be sent.

Figure 2 illustrates the causes of redundant message transmission during RLC protocol entity re-establishment. As shown in the figure, before the rebuild process occurs, the receiver receives the message with sequence numbers 0, 1, 2, 3, and 7, and 4, 5, and 6 are missing. Upon receiving the upper layer indication re-establishment, the receiving end will deliver all the 5 packets of 0, 1, 2, 3, and 7 to the PDCP layer. For PDCP, packets with sequence numbers 0, 1, 2, and 3 belong to consecutively received packets and can continue to be delivered to the upper layer. Starting from sequence 4, they need to wait for the retransmission of the sender after rebuilding. Text.

However, during the reconstruction process, the receiving end does not send a Status Report to the sender. For the delivery side, all messages with sequence numbers from 0 to 7 did not receive a response. After the RLC protocol entity reconstruction process is completed, the sender will retransmit all the packets with sequence numbers from 0 to 7. After the RLC protocol entity at the receiving end is reset, all state variables and timers are reset to zero. It is impossible to determine whether these messages are retransmitted or newly sent, so they are still delivered to PDCP, and PDCP determines whether the message is repeated. For PDCP, packets of sequence numbers 0, 1, 2, 3, and 7 are redundant packets and can only be discarded. In terms of the process, because of the lack of interaction between the receiving end and the transmitting end during the rebuilding process, the packets that have been received correctly by the receiving end but have not been sent due to the re-establishment of the Status Report cause the transmitting end not to receive the response are repeatedly transmitted. The processing time of the air interface resource and the protocol layer is wasted.

In the recent protocol, the reconstruction process for a single DRB (Data Radio Bear) is removed, and the UE is completely rebuilt by all UEs. This means that a DRB exception may result in redundant packet transmission on multiple DRBs, resulting in a waste of larger air interface resources. Summary of the invention

In view of the above, the main purpose of the present invention is to provide a method for reducing the retransmission of a message by the radio link control layer, which is used to solve the problem that the RLC protocol entity of the transmitting end repeatedly retransmits the redundant message received by the receiving end, resulting in Technical problems of wasted air resources.

The basic idea of the present invention is: In the condition for triggering the RLC protocol entity reconstruction process, except for the handover directly initiated by the upper layer, the reconstruction under the other two conditions is initiated by the RLC to the upper layer, and then initiated by the upper layer. It can be seen that the RLC protocol layer can predict in advance whether the reestablishment occurs. Therefore, each data radio bearer (DRB) belonging to the UE attempts to send a status report before the RLC protocol entity receives the reestablishment indication. To the sender, the sender first processes the acknowledged packets before receiving the reestablishment request, and does not repeat the retransmission after the reestablishment is completed, thereby reducing redundant packet retransmission.

In order to achieve the above object, the technical solution of the present invention is achieved as follows:

A method for reducing packet retransmission by a radio link control layer includes the following steps: Step A: On the eNodeB or the UE side, when the RLC protocol entity corresponding to a certain logical channel detects an abnormality that triggers the re-establishment of the RLC protocol entity, the local end is notified to the other RLC protocol entity corresponding to the logical channel that belongs to the same UE or only Notifying the local end that the RLC protocol entity in the acknowledge mode corresponding to the logical channel belongs to the same UE;

On the eNodeB side, multiple RLC protocol entities that belong to the same UE are usually running on the same board or digital signal processor, and only the RLC protocol entity of the UE is included on the UE side. The RLC protocol entity that detects the re-establishment of the RLC protocol entity may be notified by the function call, the message communication mechanism, or the global variable identifier to notify other local devices that belong to the same UE and corresponding to the logical channel, whether it is the eNodeB side or the UE side. The RLC protocol entity needs to re-establish all RLC protocol entities that belong to the same UE.

Step B: The RLC protocol entity in the acknowledge mode received by the local end sends a status report to the peer RLC protocol entity.

In step A, if the abnormal RLC protocol entity only informs the local end that the RLC protocol entity in the acknowledgment mode belongs to the same UE, the step does not need to determine whether the currently received RLC protocol entity is in the acknowledgment mode; In A, if the abnormal RLC protocol entity is notified that the local end is subordinate to all the RLC protocol entities of the same UE, then the step B needs to determine whether the current RLC protocol entity is in the acknowledgment mode, and only the RLC protocol entity in the acknowledgment mode needs to send. status report. If the RLC protocol entity that triggers the RLC protocol entity re-establishment exception is also in the acknowledgment mode, the RLC protocol entity and the other RLC protocol entities in the acknowledgment mode that belong to the same UE at the local end need to send the status to the peer. report.

Step C: After receiving the status report, the peer-to-peer RLC protocol entity deletes the protocol data unit (PDU) that has been acknowledged in the status report and the service data unit (Service Data Unit corresponding to the upper layer). SDU).

Further, in step A, the abnormality that triggers the re-establishment of the RLC protocol entity refers to a protocol processing error or a packet retransmission exception; Further, in step B, the radio link control protocol entity in the acknowledge mode received by the local end notifies the RLC protocol entity of the peer peer whether the status report prohibit timer (t-StatusProhibit timer) is running or not. Send a status report ( Status Report );

Further, in step B, the step of the RLC protocol entity in the acknowledge mode received by the local end to send a status message to the peer RLC protocol entity is as follows:

Step B01, determining whether the t-StatusProhibit timer is running, if not, executing step B02; if running, executing B03;

Step B02: Send a status report to the peer RLC protocol entity, perform step B05; Step B03, stop the t-StatusProhibit timer, and then perform step B04;

Step B04: Send a status report to the peer-to-peer RLC protocol entity;

Step B05. Restart the t-StatusProhibit timer.

Further, in step B, the status report that is sent should include: the current message sequence number that the current local RLC protocol entity expects to receive, the message sequence number and the packet fragment identifier that the current local RLC protocol entity has not received yet. .

Further, in step C, after receiving the status report, the peer-to-peer RLC protocol entity compares the sequence number of the unreceived message and the packet fragment identifier included in the packet with the sent packet. The message sequence number and the packet fragment identifier that are not included in the status report are considered to be acknowledged by the status report, and the received protocol data unit (PDU) and the upper layer are deleted. Corresponding Service Data Unit (SDU).

Another object of the present invention is to provide a system for reducing the retransmission of redundant packets by the radio link control layer, including the UE side and the eNodeB side, and the UE side and the eNodeB side both include a control plane processing unit and a user plane processing unit, and the user The plane processing unit includes one or more radio link control protocol entities corresponding to the logical channel, and when the radio link control protocol entity corresponding to a certain logical channel detects an abnormality that triggers reestablishment of the radio link control protocol entity, Notifying the local end that other radio link control protocol entities belonging to the same terminal or radio link control in the acknowledge mode The function of the protocol entity; the radio link control protocol entity in the acknowledge mode received by the local end has the function of sending a status report to the peer peer radio link control protocol entity after receiving the notification.

Further, the RLC protocol entity of the present invention further includes:

An entity processing module, configured to implement basic functions of an RLC protocol entity;

a notification module, configured to detect a trigger when an RLC protocol entity corresponding to a certain logical channel

When the abnormality of the RLC protocol entity is re-established, the local end is notified to other radio link control protocol entities belonging to the same terminal or the radio link control protocol entity in the acknowledge mode;

The pre-reconstruction status reporting module is configured to send a status report to the peer peer RLC protocol entity before the local end of the RLC protocol entity in the acknowledgment mode is re-established.

Further, the pre-reconstruction status reporting module sends a status report to the peer-to-peer wireless link control protocol entity regardless of whether the status report prohibits the timer running. The status report includes: the current local RLC protocol entity expects to receive The next packet sequence number to which the current local RLC protocol entity has not received the packet sequence number and packet fragmentation identifier;

Further, after receiving the status report, the peer-to-peer-to-peer-to-peer radio link control protocol entity compares the number of the packet that has not been received and the packet fragment identifier that is included in the packet with the sent packet, and deletes the packet The message sequence number and the packet data identifier corresponding to the packet fragment identifier and the service data unit corresponding to the upper layer are not included in the status report.

It should be noted that if the network is in a bad situation, the status report may not be sent to the peer. Therefore, this solution is a protection mechanism. Whether it can be effective in real time depends on the network environment when the rebuild is triggered.

After the implementation of the method of the present invention, after the RLC protocol entity is re-established, the protocol entity of the sending end only sends the unacknowledged message received by the receiving end, thereby avoiding the repeated transmission of the received message by the receiving end, and reducing the air interface. Overhead. DRAWINGS

Figure 1 shows the implementation of the RLC protocol entity reconstruction process in general;

Figure 2 is a schematic diagram of redundant text retransmission after completion of the reconstruction process;

3 is a schematic diagram showing the logical structure of the system of the present invention;

4 is a logical structural diagram of an RLC protocol entity in the system of the present invention;

FIG. 5A is a flowchart of a process when an RLC protocol entity detects a triggering reconstruction abnormality according to an embodiment of the present invention;

FIG. 5B is a flowchart of a process when an RLC protocol entity detects a triggering reconstruction abnormality according to another embodiment of the present invention;

6 is a processing flow after the RLC protocol entity receives the notification according to the present invention;

FIG. 7 is a flowchart of processing before and after the status report is received by the peer RLC protocol entity according to the present invention;

FIG. 8 is a timing chart of the overall implementation of the reconstruction process of the present invention. BEST MODE FOR CARRYING OUT THE INVENTION The present invention will be further described in detail below with reference to the accompanying drawings.

3 is a schematic diagram of a logical structure of a system according to the present invention, which includes two parts, a UE end and an eNodeB end, and the protocol hierarchical relationship and module composition of the two ends are basically the same. Both ends include a control plane processing unit and a user plane processing unit. Each UE has a corresponding user plane processing unit on the eNodeB end for processing user plane data subordinate to the same UE. The RLC protocol entity in the user plane processing unit is used to complete the radio link control layer protocol function, and each end may include multiple service logical channels. Therefore, multiple RLC protocol entities correspond to service logical channels, and each RLC protocol entity The RLC protocol entity in the control plane processing unit is notified by the RLC protocol entity when the RLC protocol entity detects an abnormality that triggers the RLC protocol entity reestablishment. Wireless resource control entity The re-instruction message is sent to all the RLC protocol entities that are subordinate to the same UE. After the local RLC protocol entity is re-established, the unacknowledged message data is re-sent. In the present invention, when detecting an abnormality that triggers the re-establishment of the RLC protocol entity, the RLC protocol entity first notifies all the RLC protocol entities that belong to the same UE at the local end, and the RLC protocol entity that receives the notification and is in the confirmed mode is re-established. The status report is sent to the peer RLC protocol entity.

4 is a schematic diagram of a logical structure of an RLC protocol entity in the system according to the present invention, including: an entity processing module, a notification module, and a pre-reconstruction status reporting module. The entity processing module is configured to complete the function of the radio link control layer in the existing protocol. The notification module is configured to notify the local RLC protocol when the RLC protocol entity corresponding to a certain logical channel detects an abnormality that triggers the RLC protocol entity to be reestablished. The pre-reconstruction status reporting module is configured to send a status advertisement to the peer peer RLC protocol entity before the local RLC protocol entity is re-established. After the entity processing module detects the abnormality, the pre-reconstruction status reporting module and the notification module are notified. Before the re-establishment, the status reporting module sends a status report message to the opposite end, and the notification module sends an abnormality notification message to other RLC protocol entities that belong to the same UE at the local end. Afterwards, the entity processing module reports the abnormality to the radio resource control entity, and the radio resource control entity decides to reconstruct and sends a reestablishment indication to the entity processing module.

In an embodiment of the present invention, five RLC protocol entities belonging to a UE (User Equipment) are supported in an eNodeB, and are all in an acknowledge mode, corresponding to DRBs of five different services, and are used by DRB1~DRB5. respectively. Assume that the RLC protocol entity receiving end of each DRB receives 10 packets with sequence numbers 0~9 in sequence, all of which are 1024 bytes. Since the condition of the Status Report is not reached, it is not sent to the sender. The RLC peering protocol entity of the UE sends a Status Report; the peer RLC protocol entity of each DRB on the UE side has sent 10 "3⁄4 texts with sequence numbers 0~9, and 5 4s with sequence numbers 10~14. The process is to be sent, and the length is also 1024 bytes. When the RLC protocol entity corresponding to the DRB1 detects the protocol error or the packet retransmission exceeds the threshold, the processing flow is as shown in Figure 5A:

Step 501: The RLC protocol entity of the DRB1 detects a protocol processing error or a certain packet weight. Pass an exception that exceeds the threshold;

Step 502: The RLC protocol entity of the DRB1 notifies all RLC protocol entities belonging to the UE from the DRB1 to the DRB5 by means of a message or a function call;

Step 503: The RLC protocol entity of the DRB1 notifies the local radio resource control entity of the exception.

In an embodiment of the present invention, eight RLC protocol entities belonging to a UE (User Equipment) are allocated to an eNodeB, and respectively correspond to DRBs of eight different services, and are respectively used by DRB1~DRB8. Among them, DRB1~DRB5 are RLC protocol entities in acknowledgment mode, and DRB6~DRB8 are RLC protocol entities in non-acknowledgment mode. Assume that the RLC protocol entity receiving end of each DRB receives 10 packets with sequence numbers 0~9 in sequence, all of which are 1024 bytes. Because the conditions of the Status Report are not met, the current RLC protocol for all acknowledge modes. The entity does not send the Status Report to the RLC peering protocol entity of the UE, that is, the UE; the peer RLC protocol entity of each DRB on the UE side has sent 10 packets with sequence numbers 0-9, and the sequence number is 10. The five packets of ~14 are to be sent, and the length is also 1024 bytes. After the RLC protocol entity corresponding to the DRB1 detects the protocol error or the packet retransmission exceeds the threshold, the processing flow is as shown in Figure 5B.

Step 511: The RLC protocol entity of the DRB1 detects an exception of the protocol processing error or a packet retransmission exceeding the threshold;

Step 512: The RLC protocol entity of the DRB1 notifies the RLC protocol entity of the acknowledgment mode of the UE from the DRB1 to the DRB5 by means of a message or a function call, but does not notify the DRB6 to the DRB8 RLC protocol entity of the non-acknowledgement mode;

Step 513: The RLC protocol entity of the DRB1 notifies the local radio resource control entity of the exception.

For each of the notified RLC protocol entities (including the first detected RLC protocol entity) from DRB1 to DRB5, the following steps are performed as shown in FIG. 6: Step 601: The RLC protocol entity receives the notification that it is detected that an abnormality that may trigger the re-establishment of the RLC protocol entity is detected.

Step 602: The RLC protocol entity determines whether its own t-StatusProhibit timer is in the running state, and if yes, proceeds to process 603, otherwise jumps directly to the process 604; Step 603: Stops the t-StatusProhibit timer ;

Step 604: Send a status report (Status Report) to the peer RLC protocol entity, where the ACK_SN is equal to 10, that is, the packets with the identifiers 0-9 are received, and the current local RLC protocol entity expects to receive the message. The next sequence number is 10; in addition, the status report should also include the message sequence number and packet fragmentation identifier information that has not been received by the current local RLC protocol entity;

Step 605: Start the t-StatusProhibit timer.

After the RLC protocol entity of the peer end receives the Status Report, the processing flow is as shown in Figure 7: Step 701: The RLC protocol entity receives the Status Report sent by the peer end;

Step 702: According to the received Status Report, compare the sequence number and the packet fragment identifier of the packet that have not been received into the sent packet, and the sequence number and packet of the packet that are not included in the status report. The slice can be considered as confirmed by the status report, and the received protocol data unit and the upper layer corresponding service data unit are deleted. In this embodiment, since the ACK_SN in the status report is equal to 10, the description is 0-9. The PDU has been correctly received by the peer RLC protocol entity. Therefore, the PDU with the sequence number 0~9 is deleted from the sent queue, and the upper layer is notified to delete the corresponding SDU.

Step 703: The reconstruction is completed;

Step 704: Retransmit the SDUs that have not been deleted to the peer RLC, that is, the SDUs corresponding to the PDUs of the sequence numbers 10-14.

In summary, the reconstruction process including the method of the present invention is as shown in Fig. 8, and the following steps are performed:

Step 801: The receiving end RLC protocol entity learns that an entity that may trigger the RLC protocol is likely to be triggered. Built exception

Step 802: The RLC protocol entity of the receiving end sends a status report to the peer end. The status report sent by the RLC protocol entity may include the following content: The current local RLC protocol entity expects to receive the next message sequence number and the current local end. The number of the packet and the fragmentation identifier of the packet that have not been received by the RLC protocol entity.

Step 803: After receiving the Status Report, the RLC protocol entity deletes the PDU correctly received by the peer RLC protocol entity in the sent queue, and notifies the upper layer to delete the corresponding SDU.

After receiving the status report, the RLC protocol entity of the sending end compares the sequence number and the packet fragment identifier of the packet that has not been received with the sent packet, and deletes the sequence number and the packet that are not included in the status report. The protocol data unit corresponding to the fragment identifier and the service data unit corresponding to the upper layer (the message sequence number and the packet fragment identifier not included in the status report can be considered as confirmed by the status report).

Step 804: The RLC protocol entity receives the re-establishment indication of the upper layer. Step 805: The RLC protocol entity receives all the packets in the buffer, regardless of whether they are continuously delivered to the PDCP.

Step 806: Reconstruction of the RLC protocol entity is completed;

Step 807: The sending end RLC protocol entity sends the PDU that has not been acknowledged to the opposite end. As can be seen from the description of this process, the receiving end and the sending end perform a Status Report interaction before receiving the re-establishment indication, so that the transmitting end can delete the PDU confirmed by the receiving end. In this way, only those PDUs that are not confirmed are transmitted after the re-establishment, and a large number of retransmissions of redundant messages are avoided. In this embodiment, five DRBs, each DRB does not repeatedly transmit 10 PDUs with sequence numbers 0-9, each length is 1024 bytes, that is, the data transmission is reduced by 50K in the air interface. The effect is quite obvious.

The above is only the preferred embodiment of the present invention and is not intended to limit the scope of the present invention.

Claims

Claim

A method for reducing a retransmission of a redundant packet by a radio link control layer, comprising:

A. On the evolved base station or the terminal side, when the radio link control protocol entity corresponding to the logical channel detects an abnormality that triggers the reestablishment of the radio link control protocol entity, the local end is notified to the other wireless device corresponding to the logical channel that belongs to the same terminal. a link control protocol entity or a radio link control protocol entity in an acknowledgment mode;

B. The radio link control protocol entity in the acknowledge mode received by the local end sends a status report to the peer-to-peer radio link control protocol entity;

C. After receiving the status report, the peer-to-peer wireless link control protocol entity deletes the received protocol data unit and the upper layer corresponding service data unit in the status report.

The method according to claim 1, wherein in step A, the abnormality of the triggering of the wireless link control protocol entity reconstruction is a protocol processing error or a message retransmission exception.

The method according to claim 1, wherein in step B, the radio link control protocol entity in the acknowledge mode received by the local end is correct regardless of whether the status report prohibits the timer from running. The peer-to-peer radio link control protocol entity sends a status report.

The method according to claim 1, wherein in step B, the radio link control protocol entity in the acknowledge mode received by the local end sends a notification to the peer-to-peer wireless link control protocol entity. The steps to report the status are as follows:

B01, determining whether the state prohibits the timer running, if not, executing step B02; if running, executing B03;

B02, sending a status report to the peer-to-peer wireless link control protocol entity, executing B05;

B03, the stop state prohibits the timer, and then performs step B04;

B04. Send a status report to a peer-to-peer wireless link control protocol entity.

B05. Start state inhibit timer.

The method according to claim 1, wherein in step B, the local end receives The status report sent by the radio link control protocol entity in the acknowledged mode to the peer-to-peer radio link control protocol entity includes: the current message sequence number that the current local radio link control protocol entity expects to receive, The packet sequence number and packet fragment identifier that have not been received by the local radio link control protocol entity.

The method according to claim 1, wherein, in step C, after the peer-to-peer wireless link control protocol entity receives the status report, the unreceived message included therein The text sequence number and the packet fragment identifier are compared with the sent packet, and the packet sequence number and the protocol data unit corresponding to the packet fragment identifier and the service data unit corresponding to the upper layer are deleted.

7. A radio link control layer system for reducing redundancy >3⁄4 text retransmission, comprising a terminal side and an evolved base station side, both ends including a control plane processing unit and a user plane processing unit, wherein the user plane processing unit includes one or a plurality of radio link control protocol entities corresponding to the logical channel, wherein when the radio link control protocol entity corresponding to the logical channel detects an abnormality that triggers reestablishment of the radio link control protocol entity, the notification local end is subordinate to The function of the other radio link control protocol entity corresponding to the logical channel of the same terminal or the radio link control protocol entity in the acknowledge mode;

After receiving the notification, the radio link control protocol entity in the acknowledge mode received by the local end has the function of transmitting a status report to the peer peer radio link control protocol entity.

8. The system according to claim 7, wherein the radio link control protocol entity of the present invention further comprises:

An entity processing module, configured to implement a basic function of a radio link control protocol entity; and a notification module, configured to: when a radio link control protocol entity corresponding to a certain logical channel detects an abnormality that triggers reestablishment of a radio link control protocol entity The local end belongs to another radio link control protocol entity corresponding to the logical channel belonging to the same terminal or the radio link control protocol entity in the acknowledge mode; The pre-reconstruction status reporting module is configured to send a status report to the peer peer to peer radio link control protocol entity before the local end is reestablished in the acknowledgment mode of the radio link control protocol entity.

The system according to claim 8, wherein the pre-reconstruction status reporting module sends a status report to the peer-to-peer radio link control protocol entity regardless of whether the status report prohibits the timer running; The status report includes: the current packet sequence number that the current local RLC protocol entity expects to receive, the packet sequence number and the packet fragment identifier that the current local RLC protocol entity has not received;

The system according to claim 9, wherein, after receiving the status report, the peer-to-peer-to-peer radio link control protocol entity includes the sequence number and the message that have not been received. The fragment identifier is compared with the sent packet, and the packet sequence number not included in the status report and the protocol data unit corresponding to the packet fragment identifier and the service data unit corresponding to the upper layer are deleted.