JP2013013001A - Receiver, transmitter, and feedback method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a receiver, transmitter, and feedback method for implementing efficient synchronous processing of a RoHC header compression entity and a RoHC header decompression entity.SOLUTION: A CONTROL data buffer 236 disposes of an old PDCP CONTROL PDU and stores a PDCP CONTROL PDU newly received from a PDCP sublayer 220 in the buffer, when the PDCP CONTROL PDU is already received from the PDCP sublayer 220 and remains in an untransmitted state in the buffer. An RLC PDU generation part 232 retrieves the data stored in the CONTROL data buffer 236 in preference to data stored in an RLC transmission buffer 231, and transmits the retrieved data to a lower layer 240.

Description

  The present invention relates to a receiving apparatus, a transmitting apparatus, and a feedback method in a receiving apparatus that communicate packet data having a compressible header.

  Currently, Long Term Evolution (hereinafter referred to as LTE), which is a next generation mobile communication system, is being studied in the Technical Specification Group Radio Access Network (TSG RAN) of the 3rd Generation Partnership Project (hereinafter referred to as 3GPP). In 3GPP LTE, a mobile terminal device (hereinafter referred to as UE: User Equipment) is connected to an E-UTRAN (Enhanced Universal Terrestrial Radio Access Network) composed of a plurality of base station devices (hereinafter referred to as eNodeB: Evolved Node B). Then, user data is transmitted and received.

  FIG. 1 is a diagram illustrating a network architecture used in the LTE communication scheme.

  As shown in FIG. 1, the UE is connected to E-UTRAN composed of a plurality of base stations (eNodeB), and transmits and receives user data to and from E-UTRAN.

  Here, user data between the UE and the eNodeB is controlled by layer 1 (physical layer) and layer 2 (data link layer) of a communication protocol used in 3GPP LTE. Layer 2 includes a MAC (Medium Access Control) sublayer that performs radio resource allocation control, an RLC (Radio Link Control) sublayer that controls radio links, and data encryption / decryption and handover packets. It is divided into a PDCP (Packet Data Convergence Protocol) sublayer that performs order control and the like.

  FIG. 2 is a diagram showing the arrangement of the user data control system protocol stack.

  As shown in FIG. 2, user data between the UE and the eNodeB is controlled by LTE communication protocol layer 1 and layer 2 (MAC / RLC / PDCP). Radio bearers are set in the RLC / PDCP sublayers of the UE and eNodeB at the start of communication. Multiple radio bearers can be activated. An RLC / PDCP entity (entity) corresponding to each UE and eNodeB is generated for each radio bearer, and control information for transmission / reception data passing through the radio bearer is held.

  Radio bearers are roughly classified into three. That is, Signaling Radio Bearer (SRB) that transmits / receives a layer 3 (RRC / NAS) communication control message, Data Radio Bearer-Acknowledged Mode (DRB-AM) that retransmits user data until delivery confirmation is obtained in the RLC sublayer, It is Data Radio Bearer-Unacknowledged Mode (DRB-UM) which does not confirm delivery in the RLC sublayer among user data. Hereinafter, DRB-AM and DRB-UM are collectively referred to as DRB.

  FIG. 3 is a diagram showing a PDCP sublayer functional configuration.

  The 3GPP LTE standard stipulates that IP header compression (RoHC) can be applied in the PDCP sublayer. Data that is subject to RoHC application is user data that flows on the DRB. As headers that can be compressed by RoHC, there are RTP, UDP, TCP, and IP headers. Each header compression method is defined as a profile.

  In the PDCP sublayer transmission entity, there is a RoHC header compression entity, and header compression by RoHC is performed before ciphering. On the other hand, the PDHC sublayer receiving entity includes a RoHC header decompression entity, and performs header decompression by RoHC after performing deciphering (see FIG. 3).

  When header compression by RoHC is performed, the RoHC header decompression entity can send a RoHC feedback packet to the RoHC header compression entity. The RoHC feedback packet is transmitted in one direction from the PDCP sublayer reception entity (RoHC header decompression entity) to the PDCP sublayer transmission entity (RoHC header compression entity) by PDCP control pdu. The PDCP control pdu including the RoHC feedback packet does not include data (user data, PDCP status report) other than the RoHC feedback packet, and can include only one RoHC feedback packet.

  The RoHC feedback packet includes header decompression success / failure information in the RoHC header decompression entity, and other optional fields according to the RoHC compression profile. The RoHC feedback packet is used to synchronize the compression state of RoHC compression and decompression entities, to operate in each compression state, and to switch control modes for controlling the transition of the compression state.

  FIG. 4 is a diagram illustrating the RoHC header compression entity state.

  As shown in FIG. 4, the RoHC header compression entity has three compression states: an IR (Initialization and Refresh) state, an FO (First Order) state, and an SO (Second Order) state.

  In the IR state, the RoHC header compression entity does not compress the header information to be compressed, and sends all the header information to the RoHC header decompression entity.

  In the FO state, most of the static fields (parameters that hardly change in units of packets) in the RoHC compression target header information are compressed. Some static and dynamic fields (parameters that vary on a packet-by-packet basis) are sent to the RoHC header decompression entity without compression.

  In the SO state, the header compression rate is the highest. By sending only the RTP sequence number from the RoHC header compression entity, the target header can be restored by the RoHC header decompression entity.

  FIG. 5 is a diagram illustrating the RoHC header decompression entity state.

  As shown in FIG. 5, the RoHC header decompression entity has three states: an NC (No Context) state, an SC (Static Context) state, and an FC (Full Context) state. The initial state of the RoHC header decompression entity is the NC state, and there is no information (header decompression context) necessary for header decompression, and the decompression process cannot be performed correctly. When receiving the header decompression context, the RoHC header decompression entity transitions to the FC state. After that, the transition to SC state and NC state is triggered by continuous header decompression failure.

  FIG. 6 is a diagram for explaining the RoHC header compression entity control mode.

  In the RoHC header compression entity, there are control modes that determine the operation in each header compression state and the header compression state transition.

  As shown in FIG. 6, the control modes include U-mode (Unidirectional mode), O-mode (Bidirectional Optimistic mode), and R-mode (Bidirectional Reliable mode). There are three modes. The optimum mode depends on the environment in which RoHC is used (feedback response time, transmission path error rate, header size variation, etc.).

  In U-mode, RoHC feedback packets are not used. Transition to the high compression state (IR → FO → SO) is performed by transmitting a certain number of packets. Transition to the low compression state (SO → FO, SO → IR, FO → IR) is performed at regular intervals, and information necessary for header decompression is transmitted to the RoHC header decompression entity.

  In O-mode, a RoHC feedback packet is used to make an error recovery request (header decompression context update request) from the RoHC header decompression entity to the RoHC header compression entity. It is also possible to implement a response when an important header decompression context is received by a RoHC feedback packet (optional function).

  In R-mode, RoHC feedback packets are used more actively. The RoHC header compression entity transitions to a high compression state by receiving a header decompression success notification (ACK) by a RoHC feedback packet, and low by receiving a header decompression context update request (NACK, STATIC NACK) by a RoHC feedback packet. Transition to the compressed state.

  The transition of the control mode (U-mode, O-mode, R-mode) in the RoHC header compression entity is determined by the RoHC header decompression entity. The RoHC header decompression entity gives a control mode parameter to the RoHC feedback packet, and the RoHC header compression entity confirms the necessity of control mode transition by checking the control mode parameter when receiving the RoHC feedback packet.

  Multiple header decompression contexts may be created within a RoHC header decompression entity. Within the RoHC header compression entity, multiple compression states and control modes corresponding to the header decompression context are managed. The corresponding header decompression context, the compression state in the RoHC header compression entity, and the control mode are called a RoHC context, and are distinguished by a context identifier (CID).

  The above is described in, for example, Non-Patent Document 1, Non-Patent Document 2, and Non-Patent Document 3.

3GPP TS36.323 Evolved Universal Terrestrial Radio Access (E-UTRA); Packet Data Convergence Protocol (PDCP) specification (Release 8) IETF RFC 3095: "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP and uncompressed". IETF RFC 4815: "RObust Header Compression (ROHC): Corrections and Clarifications to RFC 3095".

  However, in the RoHC feedback packet transmission control described above, if a plurality of RoHC feedback packets to be transmitted from the decompression entity are accumulated in a situation where transmission is not possible due to deterioration of the wireless environment, there is a possibility that it will be wasted. This will be specifically described below.

  FIG. 7 is a diagram illustrating an example in which the accumulated RoHC feedback packet is wasted.

  As shown in FIG. 7 (a), when data transmission is disabled from the RoHC header decompression entity (UE or eNodeB) due to deterioration of the radio environment, a plurality of RoHC feedback packets to be transmitted from the RLC sublayer on the decompression entity side are generated, May accumulate. As shown in FIG. 7 (b), when the radio environment is improved and data transmission from the UE is resumed, the accumulated RoHC feedback packet is delivered to the RoHC header compression entity. Receiving a packet may cause the RoHC header compression entity to make unnecessary state transitions.

  The R-mode RoHC header compression entity receives a header decompression success notification (ACK) using a RoHC feedback packet, transitions to a high compression state, and receives a header decompression context update request (NACK, STATIC NACK) using a RoHC feedback packet. To make a transition to a low compression state. After multiple header decompression notifications (ACK) are accumulated in the RLC sublayer on the RoHC header decompression entity side, header decompression context update requests (NACK, STATIC NACK) are generated and pending transmission, and header decompression success notification ( The RoHC header compression entity that has received (ACK) transitions to the high compression state. However, when the header decompression context update request (NACK, STATIC NACK) is received, it is necessary to transition to the low compression state again.

  When the RoHC header compression entity performs the header compression processing of user data and sends it to the RoHC header decompression entity when transitioning to the high compression state, the RoHC header decompression entity is already in a state where the header decompression context needs to be updated. It is highly possible that header decompression will fail and be discarded.

  In addition, the RoHC header decompression entity described above can return the RoHC feedback packet to the RoHC header compression entity earlier so that the state of the compression entity and decompression entity can be transitioned earlier, and communication in a state more suitable for the wireless environment. Is possible. However, as shown in FIGS. 8A and 8B, when transmission data other than the RoHC feedback packet (for example, transmission data from another PDCP entity) has been transmitted to the RLC sublayer first, The RoHC feedback packet is transmitted after transmission of other transmission data that has been transmitted earlier, and the transition to a state more suitable for the wireless environment is delayed.

  An object of the present invention is to provide a receiving device, a transmitting device, and a feedback method for improving the efficiency of synchronization processing of a RoHC header compression entity and a RoHC header decompression entity.

  The receiving apparatus of the present invention includes receiving means for receiving header-compressed data, header decompressing means for decompressing the header of the data, and feedback information including information indicating success or failure of header decompression in the header decompressing means. Generating means for generating; mapping means for mapping the feedback information to a control protocol data unit (Control PDU) of an RLC sublayer; and transmitting means for transmitting the feedback information mapped to the control protocol data unit. Take the configuration.

  The receiving apparatus of the present invention includes receiving means for receiving header-compressed data, header decompressing means for decompressing the header of the data, and feedback information including information indicating success or failure of header decompression in the header decompressing means. The configuration includes a generating unit that generates and a transmitting unit that preferentially transmits the feedback information to other data.

  The transmission apparatus of the present invention includes a receiving unit that receives data transmitted from a communication partner, and PDCP sublayer control information that is feedback information including information indicating success or failure of header decompression in the communication partner. If included, a configuration is provided that includes notification means for omitting the order control and notifying the PDCP sublayer of the control information of the PDCP sublayer, and transmission means for compressing and transmitting the data corresponding to the feedback information. .

  The feedback method of the present invention includes a header decompression step for header decompression of header-compressed data, a generation step for generating feedback information including information indicating success or failure of header decompression in the header decompression step, and the feedback information. A mapping step of mapping the control protocol data unit (Control PDU) of the RLC sublayer, and a transmission step of transmitting the feedback information mapped to the control protocol data unit.

  According to the present invention, it is possible to improve the efficiency of the synchronization processing of the RoHC header compression entity and the RoHC header decompression entity.

Diagram showing network architecture used in LTE communication system Diagram showing the layout of the user data control protocol stack Diagram showing PDCP sublayer function configuration Diagram explaining RoHC header compression entity status Diagram explaining RoHC header decompression entity status Diagram explaining RoHC header compression entity control mode Diagram showing an example where the accumulated RoHC feedback packet is wasted Diagram showing an example of transmission delay of RoHC feedback packet The block diagram which shows the structure of the communication system which concerns on one embodiment of this invention. Diagram showing RLC PDU format in AM mode Diagram showing RLC PDU format in UM mode Diagram showing RLC PDU format in UM mode

  Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings.

(One embodiment)
In the present embodiment, a case where the LTE communication protocol is applied and RoHC feedback packet transmission control is performed on the RLC sublayer will be described as an example.

  FIG. 9 is a block diagram showing a configuration of a communication system according to an embodiment of the present invention. In FIG. 9, description of functional blocks not directly related to RoHC feedback packet transmission control is omitted.

  As illustrated in FIG. 9, the communication system includes a device 100 in which the RoHC header compression entity 121 is activated and a device 200 in which the RoHC header decompression entity 221 is activated. Connect via environment 300.

  The device 100 that activates the RoHC header compression entity 121 is, for example, a UE (mobile terminal device), and the device 200 that activates the RoHC header decompression entity 221 is, for example, an eNodeB.

  Since both the RoHC header compression entity 121 and the RoHC header decompression entity 221 actually exist in each of the UE and the eNodeB, it is possible to view the device 100 as an eNodeB and the device 200 as a UE. The following explanation is based on the assumption that the RoHC header compression processing and ciphering processing have already been started in the device 100 and the device 200.

  PDCP SDU is transmitted from the upper layer 110 (user data system) in the device 100 to the PDCP sublayer 120. In the PDCP sublayer 120, the RoHC header compression entity 121 first performs target header compression processing. Thereafter, the ciphering processing unit 122 performs encryption, and the PDCP PDU generation unit 123 adds a PDCP header. The PDCP PDU is transmitted to the RLC sublayer 130.

  The RLC PDCP PDU identifying unit 135 in the RLC sublayer 130 identifies whether the PDCP PDU transmitted from the PDCP sublayer 120 is a PDCP CONTROL PDU or a DATA PDU. If it is stored in the buffer 131 and the PDCP PDU is a PDCP CONTROL PDU, the PDCP CONTROL PDU is stored in the Control data buffer 136.

  The RLC PDU generation unit 132 extracts data from the Control data buffer 136 and the RLC transmission buffer 131, and extracts header information of the RLC sublayer including information for identifying each data and information for data size and order control. RLC PDU is generated by attaching to the data. The RLC PDU is transmitted to the lower layer 140 (MAC / PHY) and transferred to the device 200 through the radio propagation environment 300.

  In the device 200, data is received from the radio propagation environment 300 by the lower layer 240 (MAC / PHY), and when an RLC PDU is received, the data is transmitted to the RLC sublayer 230. The RLC PDU analysis unit 233 in the RLC sublayer 230 determines whether the received data is a PDCP CONTROL PDU or a PDCP DATA PDU (user data), and determines that the received data is a PDCP DATA PDU. Stored in the RLC reception buffer 234. On the other hand, when the RLC PDU analysis unit 233 determines that the received data is a PDCP CONTROL PDU, the RLC PDU analysis unit 233 transmits the PDCP CONTROL PDU to the PDCP sublayer 220.

  The PDCP PDU analysis unit 223 in the PDCP sublayer 220 determines whether the transmitted PDCP PDU is a PDCP CONTROL PDU or a PDCP DATA PDU, and transmits the PDCP DATA PDU to the deciphering processing unit 222. The PDCP DATA PDU (user data) is decrypted by the deciphering processing unit 222 and the target header is decompressed by the RoHC header decompressing entity 221, and then the upper layer 215 (user data) System).

  The RoHC header decompression entity 221 may generate a RoHC feedback packet depending on the control mode. As an example, RoHC header decompression processing is successfully executed, header decompression success notification (ACK) is set, and RoHC header decompression processing is failed a certain number of times, RoHC header decompression context update request (NACK, STATIC NACK) is set Generate a feedback packet. Considering the loss of the RoHC feedback packet, the RoHC feedback packet may be generated every time the RoHC header is decompressed, or the same RoHC feedback packet may be retransmitted every certain time.

  The RoHC feedback packet generated by the RoHC header decompression entity 221 is once stored in the RoHC feedback packet storage unit 225, stored in the PDCP CONTROL PDU by the PDCP PDU generation unit 224, and transmitted to the RLC sublayer 230.

  The RLC PDCP PDU identifying unit 235 identifies whether the transmitted PDCP PDU is a PDCP CONTROL PDU or a DATA PDU, and if the PDCP PDU is a PDCP CONTROL PDU, stores the PDCP CONTROL PDU in the CONTROL data buffer 236. If it is a PDCP DATA PDU, the PDCP DATA PDU is stored in the RLC transmission buffer 231. The RLC PDU generation unit 232 preferentially extracts the data stored in the CONTROL data buffer 236 from the data stored in the RLC transmission buffer 231 and transmits it to the lower layer 240.

  The PDCP CONTROL PDU received by the lower layer 140 (MAC / PHY) of the device 100 through the radio propagation environment 300 is transmitted to the RLC sublayer 130. In the RLC sublayer 130, the RLC PDU analysis unit 133 checks the transmitted PDCP CONTROL PDU, omits the order control, and transmits it to the PDCP sublayer 120.

  In the PDCP sublayer 120, the PDCP PDU analysis unit 124 checks the PDCP CONTROL PDU, and if it is a RoHC feedback packet, transmits it to the RoHC header compression entity 121. The RoHC header compression entity 121 confirms the content of the RoHC feedback packet, and changes the compression state, transmits the RoHC header decompression context information necessary for the RoHC header decompression entity 221, changes the control mode, and the like.

  When the radio propagation environment 300 is good, only the above operation is repeated. However, a situation may occur in which the radio propagation environment 300 deteriorates and the transmission error rate increases or transmission becomes impossible at all. In such a situation, if transmission from the device 200 to the device 100 is continued, data that cannot be transmitted is accumulated in the RLC sublayer, so that the transmission data resource is depleted.

  Therefore, the CONTROL data buffer 236 discards the old PDCP CONTROL PDU and newly receives it from the PDCP sublayer 220 when the PDCP CONTROL PDU already received from the PDCP sublayer 220 remains unsent in the buffer. Store the PDCP CONTROL PDU in a buffer. Thereby, only one latest RoHC feedback packet (PDCP CONTROL PDU) can be transmitted to the device 100. Note that when discarding the RoHC feedback packet (PDCP CONTROL PDU), the operation may be to confirm the RoHC CID and discard only the same CID.

  Here, a means for identifying and analyzing the PDCP DATA PDU and the PDCP CONTROL PDU generated by the PDCP sublayers 120 and 220 in the RLC sublayer 130 and the RLC sublayer 230 will be described.

  First, the case where the AM mode of the RLC sublayer defined in Non-Patent Document 2 is used will be described. FIG. 10 shows the format of the RLC PDU in the AM mode. The RLC PDU generation unit 232 maps the PDCP CONTROL PDU to an unused code in the Control PDU Type (CPT) field (3 bits), so that the RLC PDU analysis unit 133 can identify the PDCP CONTROL PDU. That is, in Non-Patent Document 2, the codes “001” to “111” in the CPT field are unused as reserved codes, and therefore can be easily identified by assigning the code “001” to the PDCP CONTROL PDU. .

  Next, the case where the 10-bit SN in the UM mode of the RLC sublayer defined in Non-Patent Document 2 is described. FIG. 11 shows an RLC PDU format in the UM mode (10-bit SN). When the RLC PDU generation unit 232 maps the PDCP CONTROL PDU to the unused area described in R1, the RLC PDU analysis unit 133 can identify the PDCP CONTROL PDU. For example, as in the AM mode, the head R1 bit can be identified as a Data / Control (D / C) field in the case of a CONTROL PDU if it is determined as a PDCP CONTROL PDU.

  Finally, a case where 5 bit SN in the RLC sublayer UM mode is used will be described. FIG. 12 shows an RLC PDU format in the UM mode (5 bit SN). In this case, since there is no unused area, it is necessary to analyze the header of the PDCP PDU. Since the first 1 bit (D / C) of the PDCP header defined in Non-Patent Document 2 is a bit for identifying a DATA PDU or a CONTROL PDU, it can be identified by analyzing the area. This means can be applied to the other formats described above.

  A 3G (3rd Generation) RLC sublayer (specified in 3GPP TS25.322) can be identified in the same way by the PDLC CONTROL PDU in the RLC sublayer.

  As described above, according to the present embodiment, in the RLC sublayer, the RoHC feedback packet, which is the control information of the PDCP sublayer, is preferentially transmitted with respect to other user data, so that a state suitable for the wireless environment can be quickly achieved. Transition is possible. Also, redundant state transitions of the RoCH header compression entity can be suppressed by suppressing multiple transmissions of RoHC feedback packets. Therefore, the efficiency of the synchronization processing of the RoHC header compression entity and the RoHC header decompression entity can be improved.

  The above description is an illustration of a preferred embodiment of the present invention, and the scope of the present invention is not limited to this.

  In the present embodiment, the application example is described based on the 3GPP LTE communication protocol stack, but the scope of the present invention is not limited to this. For example, if the system is applicable to RoHC, and a situation occurs in which RoHC feedback packets accumulate in devices and terminals where RoHC header decompression entities exist, the present invention is applied to store one latest RoHC feedback packet. It is possible to improve efficiency.

  In the above embodiment, the names communication system, transmission control apparatus, and transmission control method are used. However, this is for convenience of explanation, and the apparatus is a radio communication terminal, LTE terminal, mobile communication system, and method is a communication control method. It may be.

  Furthermore, each component which comprises the said communication system, for example, the kind of apparatus, a radio propagation environment, etc., is not restricted to embodiment mentioned above.

  Each functional block used in the description of the above embodiment is typically realized as an LSI which is an integrated circuit. These may be individually made into one chip, or may be made into one chip so as to include a part or all of them. The name used here is LSI, but it may also be called IC, system LSI, super LSI, or ultra LSI depending on the degree of integration.

  Further, the method of circuit integration is not limited to LSI's, and implementation using dedicated circuitry or general purpose processors is also possible. An FPGA (Field Programmable Gate Array) that can be programmed after manufacturing the LSI, or a reconfigurable processor that can reconfigure the connection and setting of circuit cells inside the LSI may be used.

  Further, if integrated circuit technology comes out to replace LSI's as a result of the advancement of semiconductor technology or a derivative other technology, it is naturally also possible to carry out function block integration using this technology. For example, biotechnology can be applied.

  INDUSTRIAL APPLICABILITY The receiving device, transmitting device, and feedback method of the present invention are useful for packet communication systems that communicate packets between user communication devices such as mobile terminal devices and operator communication devices such as base station devices.

100, 200 equipment 110, 215 Upper layer (user data system)
120 PDCP sublayer 121 RoHC header compression entity 122 Ciphering processing unit 123 PDCP PDU generation unit 124 PDCP PDU analysis unit 130 RLC sublayer 131 RLC transmission buffer 132 RLC PDU generation unit 133 RLC PDU analysis unit 134 RLC reception buffer 135 RLC PDCP PDU identification unit 136 Control data buffer 140 Lower layer 210 Upper layer (RRC)
220 PDCP layer 221 RoHC header decompression entity 222 Deciphering processing unit 223 PDCP PDU analysis unit 224 PDCP PDU generation unit 225 RoHC feedback packet storage unit 230 RLC sublayer 231 RLC transmission buffer 232 RLC PDU generation unit 233 RLC PDU analysis unit 234 RLC reception Buffer 235 RLC PDCP PDU identification unit 236 Control data buffer 240 Lower layer (MAC / PHY)
300 Radio propagation environment

Claims (5)

Receiving means for receiving header-compressed data;
Header decompression means for performing header decompression of the data;
Generating means for generating feedback information including information indicating success or failure of header decompression in the header decompression means;
Mapping means for mapping the feedback information to a control protocol data unit (Control PDU) of the RLC sublayer;
Transmitting means for transmitting the feedback information mapped to the control protocol data unit;
A receiving apparatus comprising:   The receiving apparatus according to claim 1, further comprising a storage unit that stores only one unit of control protocol data units from the PDCP sublayer in the RLC sublayer. Receiving means for receiving header-compressed data;
Header decompression means for performing header decompression of the data;
Generating means for generating feedback information including information indicating success or failure of header decompression in the header decompression means;
Transmission means for preferentially transmitting the feedback information to other data;
A receiving apparatus comprising: Receiving means for receiving data transmitted from a communication partner;
When the PDCP sublayer control information, which is feedback information including information indicating success or failure of header decompression at the communication partner, is included in the data, the order control is omitted and the PDCP sublayer control information is notified to the PDCP sublayer Notification means to
Transmission means for header-compressing and transmitting data according to the feedback information;
A transmission apparatus comprising: A header decompression step for decompressing the header compressed data;
Generating step for generating feedback information including information indicating success or failure of header decompression in the header decompression step;
A mapping step of mapping the feedback information to an RLC sublayer control protocol data unit (Control PDU);
Transmitting the feedback information mapped to the control protocol data unit;
A feedback method comprising:

Images