The PDCP layer is above a Radio Link Control (RLC) layer in a radio interface protocol stack of the LTE, its entity function is as shown in FIG. 1. An RLC entity to which the PDCP corresponds may be either in an Unacknowledged Mode (UM) or an Acknowledged Mode (AM). For easy description, the PDCP layer/entity here corresponding to the RLC layer AM/UM is called an AM/UM-type PDCP layer/entity. A PDCP reestablishment procedure refers to a PDCP entity resetting procedure instructed by an upper layer. There are many reasons for triggering PDCP reestablishment, such as switching, or RRC link reconfiguration. This application concerns a reestablishment procedure with regard to Data Radio Bearer (DRB). During the reestablishment, a series of related processes such as the processing of resident messages at the PDCP layer and the update of a security configuration are involved and the resetting of a Robust Header Compression (ROHC) module may be triggered. After the PDCP reestablishment, a Status Report generated according to an actual reception condition of messages is transmitted to an opposite end, so as to achieve the purpose of reducing retransmission of messages and saving air interface bandwidths. Below related background arts of the ROHC and the status report are introduced.
The ROHC provides header compression and decompression functions for a service message at the PDCP layer. The header compression refers to compressing redundant information in a header of a service message, such as an IP, a User Datagram Protocol (UDP), a Real-time Transport Protocol (RTP), and restoring the complete header at a receiving end, so as to achieve the purpose of saving air interface bandwidths. With regard to a service with a short message dead-load length, such as Voice over IP (VOIP), the system gain obtained after the adoption of the header compression is significant. The position of the ROHC in the PDCP message processing is shown in FIG. 1. The ROHC module corresponding to a PDCP transmitting entity is called a compressor, and the one corresponding to a receiving entity is called a decompressor. The ROHC has three operating modes including a Unidirectional Mode (U-Mode), a Bi-directional Optimistic Mode (O-Mode), and a Bi-directional Reliable Mode (R-Mode). In the U-Mode, messages are transmitted in one direction only, that is compressor->decompressor. The U-Mode does not have a feedback mechanism. The compressor is always started in the U-mode, and then shifted to another mode when receiving a feedback message carrying mode information from the decompressor. In the O-Mode, the decompressor has a feedback channel via which feedback messages are transmitted, therefore being capable of informing the compressor of the feedback information in time. The compressor adjusts a compression policy and the type of transmitted packets in time according to the received feedback information. In the R-Mode, the feedback channel is used frequently to enhance system robustness, and the certainty of messages to the compressor relies on the feedback information sent back by the decompressor.
A model of the feedback mechanism is shown in FIG. 2. The compressor transmits compressed messages via an ROHC channel. While receiving and processing a compressed message, the decompressor generates feedback information. The feedback information is then transmitted to the compressor via the feedback channel. The feedback mechanisms of O-Mode and R-Mode are mainly classified into two types, including Interspersed Feedback and Piggybacked Feedback, according to transmission manners. The former adopts an interspersed feedback message transmitted on a channel. As for the PDCP, such interspersed feedback message is encapsulated into a feedback-type control message (i.e. Control PDU) at the PDCP layer and transmitted via an air interface. The Piggybacked feedback is embedded into a reverse ROHC compressed message and transmitted, such feedback is invisible to the PDCP. In an embodiment of the present invention, it exclusively refers to the feedback mechanism of the interspersed feedback. Both interspersed feedback and piggybacked feedback carry decompressed information of the decompressor for informing the compressor whether the compressed message is successfully decompressed, and may trigger the transition of an operating mode and operating state of the compressor. It should be noted that mode switching of the ROHC is always initiated by the decompressor, and mode switching of the compressor is triggered through transmitting a feedback carrying mode information.
The flow of processing a feedback message at the PDCP layer is shown in FIG. 3. The processing on the receiving side is: 1. receiving: a feedback-type control message transmitted by the PDCP on an opposite end is received; 2. parsing: a PDCP packet header is removed and feedback information is delivered to the compressor; 3. processing: the compressor carries out mode switching, state transition, adjustment of a packaging policy and other operations according to the feedback information. The processing on the transmitting side is: 1. generating: the decompressor decompresses a service message and generates feedback information; 2. encapsulating: the feedback information is encapsulated into a control message (i.e. CTRL PDU) by the transmitting side; 3. transmitting: the control message carrying the feedback information is delivered to a lower layer and transmitted to the opposite end via an air interface.
The status report is a PDCP control message carrying an actual reception condition of service messages and is applied to a PDCP reestablishment process of the DRB mapped to the AM mode. In the status report, there are bit sequences. A series of messages starting from the first lost message during reestablishment correspond to the sequences one to one. These bit sequences are called bitmaps. Each packet has a corresponding bit, 1 meaning received and 0 meaning lost. The status report is always generated by a receiving entity during the reestablishment and transmitted to an opposite transmitting entity via a reverse transmission channel. After the transmitting entity receives the report, it will adjust a local message transmission policy according to bitmap information, and will not transmit the messages that have been acknowledged in the status report, so as to save air interface resources. If a radio bearer is configured so that it can transmit a status report, then during the reestablishment procedure, a PDCP entity on the receiving side generates a status report according to an actual reception condition of the service messages and transmit it as the first message after the reestablishment. The generation and processing procedures of the status report also include a message receiving processing procedure and a message transmitting processing procedure, as shown in FIG. 4, which are similar to those of a feedback, therefore not be further described here.
When a reestablishment occurs, message reception and transmission at an air interface stop, and the PDCP entity begins to process resident messages at the current layer.
The existing processing method is:
On the local receiving side:
a) taking out a resident PDCP Data Protocol Data Unit (PDU), and performing unpacking, decryption, and decompression sequentially to generate a PDCP Service Data Unit (SDU);
b) with regard to a PDCP entity corresponding to an RLC UM
c) for a UM-type PDCP entity, delivering the PDCP SDU to an upper layer; for an AM-type PDCP entity, delivering PDCP SDUs with continuous serial numbers (SN) to an upper layer, and caching PDCP SDUs with message cavity, i.e. with discontinuous SNs, and processing it after reestablishment; for a base station, the upper layer here typically refers to a GPRS Tunnelling Protocol for User Plane (GTP-U) layer; and for a terminal, the upper layer here typically refers to an application layer.
d) repeating steps a) and b) until all the resident messages (PDCP Data PDU) on the receiving side are processed;
e) updating a security configuration of a decryption module (such as changing a password), and resetting a decompressor so as to return to the initial state and operating mode.
On the local transmitting side:
a) updating a security configuration of an encryption module (such as changing a password), and updating a compressor so as to return to the initial state and operating mode;
b) re-compressing and re-encrypting an SDU, which is not successfully transmitted but has been allocated with an SN, by the reset compressor and encryptor to generate a new Data PDU;
c) delivering the newly generated PDU instead of a resident Data PDU to a lower layer (i.e. an RLC protocol layer);
d) processing SDUs in ascending SN order; and repeating steps b) and c) until all the resident messages on the transmitting side are processed.
The problem of this solution is that it fails to process resident control messages (Feedback and Status Report) at a PDCP layer during reestablishment.
Feedback messages generated during a reestablishment procedure or feedback messages residing at a PDCP layer may become invalid. According to generation reasons, three types of invalid feedback messages will occur during reestablishment:
Type 1: feedback-type control messages residing in a PDCP receiving buffer;
Type 2: feedback messages generated when service messages residing in a receiving buffer are processed before a decompressor is reset; and
Type 3: feedback-type control messages residing in a PDCP transmitting buffer.
During PDCP reestablishment, ROHC resetting is triggered, that is the compressor/decompressor restarts work from the initial state and operating mode. Therefore, information in feedback messages of Type 1 is out of date, and is useless to the local compressor. Feedback messages of Type 2 and Type 3 are transmitted to an opposite compressor in a normal process. The reestablishment is synchronous with respect to an E-UTRAN Node B (eNB) side and a User Equipment (UE) side, and the opposite compressor is also reset at the same time. Therefore, feedback messages of Type 2 and Type 3 are also invalid information. During the ROHC resetting, a new context is established. If allocated Context IDs (CID) are consistent with those in these feedback messages, then after the opposite compressor receives a feedback message of Type 2 or 3, it may enter mode switching and other abnormal processes without being known by the decompressor. On the other hand, the transmission of these invalid feedback messages after reestablishment causes a waste of air interface resources. Particularly, before reestablishment, the ROHC works in the R-Mode and the number of feedback messages is rather large, so the invalid feedback messages after the reestablishment may cause even more significant waste of resources.
During the reestablishment, resident status reports at the PDCP layer become invalid. The status reports are classified into two types according to generation locations:
Type 1: resident status report-type control messages in a PDCP reception buffer; and
Type 2: resident status report-type control messages in a PDCP transmission buffer.
A status report of Type 1 may influence the transmission policy of local messages. The status report typically is the first packet of messages received after reestablishment. If a status report appears in a PDCP resident message during the reestablishment, then it corresponds to the last reestablishment, wherein the reception information contained in the status report is out of date. The reception information contained in the status report of Type 1 can not reflect an actual reception condition on an opposite side in real time, which may cause retransmission of messages. A status report of Type 2 is transmitted to an opposite end. Similar to the status report of Type 1, it may influence the transmission efficiency of the messages on the opposite end.
In a word, the existing technical solution for processing resident messages during PDCP reestablishment fails to process feedback messages or status reports. Invalid feedback messages may result in a waste of air interface resources and even may make a compressor enter mode switching and other abnormal processes without being known by a decompressor, which results in a delay in processing of normal service data after the reestablishment. The out-of-date information included in invalid status reports influence the transmission policy of uplink and downlink messages, thereby resulting in message retransmission which leads to the reduction of the utilization of air interface resources.