WO2013001838A1 - 受信装置、送信装置及びフィードバック方法 - Google Patents

受信装置、送信装置及びフィードバック方法 Download PDF

Info

Publication number
WO2013001838A1
WO2013001838A1 PCT/JP2012/004248 JP2012004248W WO2013001838A1 WO 2013001838 A1 WO2013001838 A1 WO 2013001838A1 JP 2012004248 W JP2012004248 W JP 2012004248W WO 2013001838 A1 WO2013001838 A1 WO 2013001838A1
Authority
WO
WIPO (PCT)
Prior art keywords
pdcp
rohc
header
data
pdu
Prior art date
Application number
PCT/JP2012/004248
Other languages
English (en)
French (fr)
Inventor
良昌 白崎
成基 山口
Original Assignee
パナソニック株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by パナソニック株式会社 filed Critical パナソニック株式会社
Publication of WO2013001838A1 publication Critical patent/WO2013001838A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/04—Protocols for data compression, e.g. ROHC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/06—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/02—Data link layer protocols

Definitions

  • 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.
  • 3GPP 3rd Generation Partnership Project
  • TSG RAN Technical Specification Group Radio Access Network
  • UE User Equipment
  • E-UTRAN Enhanced Universal Terrestrial Radio Access Access Network
  • eNodeB Evolved Node Node B
  • FIG. 1 is a diagram showing a network architecture used in the LTE communication system.
  • the UE is connected to E-UTRAN composed of a plurality of base stations (eNodeBs), and transmits and receives user data to and from E-UTRAN.
  • E-UTRAN composed of a plurality of base stations (eNodeBs)
  • eNodeBs base stations
  • 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, data encryption / decryption, and packets during handover. It is divided into a PDCP (Packet Data Convergence Protocol) sublayer that performs sequence control and the like.
  • MAC Medium Access Control
  • RLC Radio Link Control
  • PDCP Packet Data Convergence Protocol
  • FIG. 2 is a diagram showing the arrangement of the user data control protocol stack.
  • 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 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 in each UE and eNodeB.
  • 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 is retransmitted in the RLC sublayer of user data until acknowledgment is obtained, Of the user data, Data Radio Bearer-Unacknowledged Mode (DRB-UM) that does not confirm delivery in the RLC sublayer.
  • SRB Signaling Radio Bearer
  • DRB-AM Data Radio Bearer-Acknowledged Mode
  • DRB-UM Data Radio Bearer-Unacknowledged Mode
  • DRB-AM and DRB-UM are collectively referred to as DRB.
  • FIG. 3 is a diagram showing a PDCP sublayer functional configuration.
  • RoHC Robust Header Compression
  • Data that is subject to RoHC application is user data that flows on the DRB.
  • headers that can be compressed by RoHC there are RTP, UDP, TCP, and IP headers.
  • Each header compression method is defined as a profile.
  • the PDCP sublayer transmission entity has a RoHC header compression entity, and performs header compression by RoHC before ciphering.
  • the PDHC sublayer receiving entity includes a RoHC header decompression entity, and performs header decompression by RoHC after performing deciphering (see FIG. 3).
  • the RoHC header decompression entity can send RoHC feedback packets to the RoHC header compression entity.
  • the RoHC feedback packet is transmitted in one direction from the PDCP sublayer receiving entity (RoHC header decompression entity) to the PDCP sublayer transmitting entity (RoHC header compression entity) by PDCP control pdu.
  • PDCP control pdu including a 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 optional fields according to the header decompression success and failure information in the RoHC header decompression entity and other RoHC compression profiles.
  • the RoHC feedback packet is used for RoHC compression, acquisition of the compression state of the decompression entity, operation in each compression state, control mode switching for controlling transition of the compression state, and the like.
  • FIG. 4 is a diagram for explaining the RoHC header compressed entity state.
  • 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.
  • IR Initialization and Refresh
  • FO First Order
  • SO Serviced Order
  • the RoHC header compression entity In the IR state, the RoHC header compression entity does not compress the header information to be compressed, and sends all header information to the RoHC header decompression entity.
  • the header compression rate is the highest.
  • the target header can be restored by the RoHC header decompression entity.
  • FIG. 5 is a diagram for explaining the state of the RoHC header decompression entity.
  • the RoHC header decompression entity has three states: NC (No (Context) state, SC (Static Context) state, and FC (Full Context) state.
  • NC No (Context) state
  • SC Static Context
  • FC Full Context
  • 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.
  • 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.
  • control modes include U-mode (Unidirectional mode), O-mode (Bidirectional Optimistic mode), and R-mode (Bidirectional Reliable mode).
  • U-mode Unidirectional mode
  • O-mode Beidirectional Optimistic mode
  • R-mode Beidirectional Reliable mode
  • the optimum mode depends on the environment in which RoHC is used (feedback response time, transmission path error rate, header size variation, etc.).
  • 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.
  • ACK header decompression success notification
  • NACK header decompression context update request
  • 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 generated in the RoHC header decompression entity. Even 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).
  • CID context identifier
  • Non-Patent Document 1 Non-Patent Document 2
  • Non-Patent Document 3 Non-Patent Document 3
  • 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".
  • FIG. 7 is a diagram illustrating an example in which the accumulated RoHC feedback packet is wasted.
  • the R-mode RoHC header compression entity transitions to a high compression state by receiving a header decompression success notification (ACK) using a RoHC feedback packet, 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.
  • ACK header decompression success notification
  • NACK header decompression context update request
  • STATIC NACK header decompression context update request
  • the RoHC header compression entity 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.
  • 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.
  • transmission data other than the RoHC feedback packet for example, transmission data from another PDCP entity
  • 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.
  • 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.
  • the efficiency of the synchronization processing of the RoHC header compression entity and the RoHC header decompression entity can be improved.
  • FIG. 9A and 9B are block diagrams showing the configuration of the communication system according to one embodiment of the present invention.
  • FIG. 9A and FIG. 9B are collectively treated as FIG.
  • description of functional blocks not directly related to RoHC feedback packet transmission control is omitted.
  • 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.
  • the device 100 can be viewed as the eNodeB and the device 200 as the 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.
  • the RoHC header compression entity 121 first performs target header compression processing. Thereafter, the ciphering processing unit 122 performs encryption, and the PDCPPDPDU generation unit 123 adds a PDCP header.
  • the PDCP PDU is transmitted to the RLC sublayer 130.
  • the RLC / PDCP / PDU identification unit 135 in the RLC sublayer 130 identifies whether the PDCP / PDU transmitted from the PDCP sublayer 120 is a PDCP / CONTROL / DATA / PDU, and if the PDCP / PDU is a PDCP / DATA / PDU, the PDCP / DATA / PDU is RLC transmitted. If the PDCP ⁇ PDU is a PDCP CONTROL PDU stored in the buffer 131, 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 receives RLC sublayer header information including information for identifying each data or information for data size and order control. It is added to the extracted data and an RLC PDU is generated. The RLC PDU is transmitted to the lower layer 140 (MAC / PHY) and transferred to the device 200 through the radio propagation environment 300.
  • data is received from the radio propagation environment 300 by the lower layer 240 (MAC / PHY), and when the RLC PDU is received, it is transmitted to the RLC sublayer 230.
  • the RLC PDU analysis unit 233 in the RLC sublayer 230 determines whether the received data is PDCP CONTROL PDU or PDCP DATA PDU (user data), and if the received data is determined to be PDCP DATA PDU, Stored in the RLC reception buffer 234.
  • 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 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, the target header is decompressed by the RoHC header decompression 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 that the RoHC feedback packet is lost, 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.
  • ACK header decompression success notification
  • NACK RoHC header decompression context update request
  • the RoHC feedback packet generated by the RoHC header decompression entity 221 is stored once in the RoHC feedback packet storage unit 225, stored in the PDCP / PDU control unit 224, and transmitted to the RLC sublayer 230.
  • the RLC PDCP PDU identification 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 generator 232 preferentially extracts the data stored in the CONTROL data buffer 236 from the data stored in the RLC transmission buffer 231 and transmits the data 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.
  • the RLC / PDU analysis unit 133 checks the transmitted PDCP / CONTROL / PDU, omits the order control, and transmits it to the PDCP sublayer 120.
  • the PDCP / PDU analysis unit 124 checks the PDCP / CONTROL / PDU and transmits it to the RoHC header compression entity 121 if it is a RoHC feedback packet.
  • 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.
  • the radio propagation environment 300 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.
  • the CONTROL data buffer 236 discards the old PDCP CONTROL PDU and newly receives it from the PDCP sub layer 220 when the PDCP CONTROL PDU already received from the PDCP sub layer 220 remains in the buffer in an untransmitted state.
  • PDCP CONTROL PDU only one latest RoHC feedback packet (PDCP CONTROL PDU) can be transmitted to the device 100.
  • the operation may be to confirm the RoHC CID and discard only the same CID.
  • FIG. 10 shows the format of RLC PDU in the AM mode.
  • 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. .
  • FIG. 11 shows an RLC PDU format in the UM mode (10 bits SN).
  • the RLC PDU generator 232 maps the PDCP CONTROL PDU to an unused area described in R1
  • the RLC PDU analyzer 133 can identify the PDCP CONTROL PDU.
  • the first R1 bit is Data / Control (D / C) field, and in the case of CONTROL PDU, it can be identified by determining that it is PDCP CONTROL PDU.
  • FIG. 12 shows an RLC PDU format in the UM mode (5 bits SN).
  • the first 1 bit (D / C) of the PDCP header defined in Non-Patent Document 2 is a bit for identifying whether it is 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.
  • 3G (3rd Generation) RLC sublayer (specified in 3GPP TS25.322) can be identified by the same means to identify PDCP CONTROL PDUs in the RLC sublayer.
  • the RoHC feedback packet which is the control information of the PDCP sublayer
  • the RoHC feedback packet 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 application example is described based on the 3GPP LTE communication protocol stack, but the scope of the present invention is not limited to this.
  • the present invention is applied to store one latest RoHC feedback packet. It is possible to improve efficiency.
  • the names communication system, transmission control apparatus, and transmission control method are used.
  • the apparatus is a radio communication terminal, LTE terminal, mobile communication system, and method is a communication control method. It may be.
  • each component constituting the communication system for example, the type of device, the radio propagation environment, and the like are not limited to the above-described embodiment.
  • 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.
  • the method of circuit integration is not limited to LSI, and may be realized by a dedicated circuit or a general-purpose processor.
  • An FPGA Field Programmable Gate Array
  • a reconfigurable processor that can reconfigure the connection and setting of circuit cells inside the LSI may be used.
  • the receiving device, transmitting device, and feedback method of the present invention are useful for packet communication systems that communicate packets between a user communication device such as a portable terminal device and an operator communication device such as a base station device.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Communication Control (AREA)

Abstract

　RoHCヘッダ圧縮エンティティ及びRoHCヘッダ解凍エンティティの同期処理の効率化を図る受信装置、送信装置及びフィードバック方法を提供する。CONTROLデータバッファ（２３６）は、既にPDCPサブレイヤ（２２０）から受信しているPDCP CONTROL PDUが未送信の状態でバッファに残っている場合、古いPDCP CONTROL PDUを破棄して、新たにPDCPサブレイヤ（２２０）から受信したPDCP CONTROL PDUをバッファに格納する。RLC PDU生成部（２３２）では、RLC送信バッファ（２３１）に格納されたデータに対してCONTROLデータバッファ（２３６）に格納されたデータを優先的に取り出して下位レイヤ（２４０）へ送信する。

Description

受信装置、送信装置及びフィードバック方法
　本発明は、圧縮可能なヘッダを有するパケットデータを通信する受信装置、送信装置及び受信装置におけるフィードバック方法に関する。
　現在、3rd Generation Partnership Project（以下、3GPPという）のTechnical Specification Group Radio Access Network(TSG RAN)において、次世代移動通信システムであるLong Term Evolution（以下、LTEという）の検討が進められている。3GPP LTEでは、携帯端末装置（以下、UE：User Equipmentという）は、複数の基地局装置（以下、eNodeB：Evolved Node Bという）から構成されるE-UTRAN（Enhanced Universal Terrestrial Radio Access Network）に接続して、ユーザデータの送受信を行う。
　図１は、LTE通信方式で使用されるネットワークアーキテクチャ（network architecture）を示す図である。
　図１に示すように、UEは、複数の基地局（eNodeB）から構成されるE-UTRANに接続し、E-UTRANとの間でユーザデータの送受信を行う。
　ここで、UEとeNodeBとの間のユーザデータは、3GPP LTEで使用される通信プロトコルのレイヤ１（物理レイヤ）及びレイヤ２（データリンクレイヤ）で制御される。また、レイヤ２は、無線リソースの割当制御等を行うMAC（Medium Access Control）サブレイヤと、無線リンクの制御を行うRLC（Radio Link Control）サブレイヤと、データの暗号化／復号化、ハンドオーバ時のパケット順序制御等を行うPDCP（Packet Data Convergence Protocol）サブレイヤとに分けられる。
　図２は、ユーザデータ制御系プロトコルスタックの配置を示す図である。
　図２に示すように、UEとeNodeB間のユーザデータは、LTE通信プロトコルレイヤ１、レイヤ２（MAC/RLC/PDCP）により制御される。UE、eNodeBそれぞれのRLC/PDCPサブレイヤには、通信開始時に無線ベアラ（Radio Bearer）が設定される。無線ベアラは、複数起動可能である。無線ベアラ１本につきUE、eNodeBそれぞれに対応するRLC/PDCPエンティティ（entity）が生成され、無線ベアラを通る送受信データに対する制御情報がUE、eNodeBそれぞれに保持される。
　無線ベアラは大きく３つに分類される。すなわち、レイヤ３（RRC/NAS）の通信制御メッセージを送受信するSignalling Radio Bearer（SRB）、ユーザデータのうちRLCサブレイヤにて送達確認が取れるまで再送するData Radio Bearer - Acknowledged Mode （DRB-AM）、ユーザデータのうちRLCサブレイヤにて送達確認を行わないData Radio Bearer - Unacknowledged Mode （DRB-UM）である。以下、DRB-AMとDRB-UMを合わせてDRBと呼ぶ。
　図３は、PDCPサブレイヤ機能構成を示す図である。
　3GPP LTE規格では、PDCPサブレイヤにてIPヘッダ圧縮（RoHC: Robust Header Compression）を適用可能であることが規定されている。RoHC適用対象となるデータはDRB上を流れるユーザデータとなる。RoHCにより圧縮可能なヘッダとして、RTP、UDP、TCP、IPのヘッダがあり、それぞれのヘッダ圧縮方法がプロファイルとして規定されている。
　PDCPサブレイヤ送信エンティティには、RoHCヘッダ圧縮エンティティが存在し、サイファリング（Ciphering）実施前にRoHCによるヘッダ圧縮を実施する。一方、PDCPサブレイヤ受信エンティティには、RoHCヘッダ解凍エンティティが存在し、デサイファリング（Deciphering）実施後にRoHCによるヘッダ解凍を実施する（図３参照）。
　RoHCによるヘッダ圧縮が実施されているとき、RoHCヘッダ解凍エンティティは、RoHCヘッダ圧縮エンティティ宛にRoHCフィードバックパケットを送信できる。RoHCフィードバックパケットは、PDCP control pduによりPDCPサブレイヤ受信エンティティ（RoHCヘッダ解凍エンティティ）からPDCPサブレイヤ送信エンティティ（RoHCヘッダ圧縮エンティティ）へと一方向に送信される。RoHCフィードバックパケットを含むPDCP control pduは、RoHCフィードバックパケット以外のデータ（ユーザデータ、PDCPステータスレポート）を含まず、RoHCフィードバックパケットを１つだけ含めることができる。
　RoHCフィードバックパケットには、RoHCヘッダ解凍エンティティにおけるヘッダ解凍成功、失敗情報、その他RoHC圧縮プロファイルに応じてオプションフィールドが含まれる。RoHCフィードバックパケットは、RoHC圧縮、解凍エンティティの圧縮状態の同期獲得、各圧縮状態での動作、圧縮状態の遷移を制御する制御モード切替などに用いられる。
　図４は、RoHCヘッダ圧縮エンティティ状態を説明する図である。
　図４に示すように、RoHCヘッダ圧縮エンティティには、IR（Initialization and Refresh）状態、FO（First Order）状態、SO（Second Order）状態の３つの圧縮状態が存在する。
　IR状態では、RoHCヘッダ圧縮エンティティは圧縮対象となるヘッダ情報を圧縮せず、すべてのヘッダ情報をRoHCヘッダ解凍エンティティへ送信する。
　FO状態では、RoHC圧縮対象ヘッダ情報のうち、静的フィールド（パケット単位でほとんど変動しないパラメータ）のほとんどを圧縮する。一部の静的フィールドと動的フィールド（パケット単位で変動するパラメータ）は圧縮せずにRoHCヘッダ解凍エンティティへと送信される。
　SO状態では、ヘッダの圧縮率が最高となる。RoHCヘッダ圧縮エンティティからはRTPシーケンス番号のみを送信することで、RoHCヘッダ解凍エンティティで対象ヘッダの復元が可能となる。
　図５は、RoHCヘッダ解凍エンティティ状態を説明する図である。
　図５に示すように、RoHCヘッダ解凍エンティティには、NC（No Context）状態、SC（Static Context）状態、FC（Full Context）状態の３つの状態が存在する。RoHCヘッダ解凍エンティティの初期状態はNC状態であり、ヘッダ解凍に必要な情報（ヘッダ解凍コンテキスト）がなく、解凍処理を正しく実施できない状態となる。RoHCヘッダ解凍エンティティは、ヘッダ解凍コンテキストを受信するとFC状態へと遷移する。以降は、連続的なヘッダ解凍失敗を契機にSC状態、NC状態へと遷移することになる。
　図６は、RoHCヘッダ圧縮エンティティ制御モードを説明する図である。
　RoHCヘッダ圧縮エンティティにおいては、各ヘッダ圧縮状態における動作、ヘッダ圧縮状態遷移を決める制御モードが存在する。
　図６に示すように、制御モードには、U-mode（Unidirectional mode：単方向モード）、O-mode（Bidirectional Optimistic mode：双方向楽観モード）、R-mode（Bidirectional Reliable mode：双方向信頼性モード）の３つのモードが存在する。最適なモードは、RoHCが使用される環境（フィードバッグ応答時間、伝送路のエラー率、ヘッダサイズのバリエーションなど）に依存する。
　U-modeでは、RoHCフィードバックパケットを使用しない。高圧縮状態への遷移（IR→FO→SO）は、一定数のパケットを送信することで実施する。低圧縮状態への遷移（SO→FO、SO→IR、FO→IR）は一定周期毎に実施し、ヘッダ解凍に必要な情報をRoHCヘッダ解凍エンティティへ送信する。
　O-modeでは、RoHCフィードバックパケットを使用し、RoHCヘッダ解凍エンティティからRoHCヘッダ圧縮エンティティへ異常復旧要求（ヘッダ解凍コンテキスト更新要求）を行う。また、RoHCフィードバックパケットにより重要なヘッダ解凍コンテキストを受信した場合の応答を実施することもできる（オプション機能）。
　R-modeでは、より積極的にRoHCフィードバックパケットを使用する。RoHCヘッダ圧縮エンティティは、RoHCフィードバックパケットによるヘッダ解凍成功通知（ACK）を受信することで高圧縮状態へ遷移し、RoHCフィードバックパケットによるヘッダ解凍コンテキスト更新要求（NACK、STATIC NACK）を受信することで低圧縮状態へ遷移する。
　RoHCヘッダ圧縮エンティティにおける制御モード（U-mode、O-mode、R-mode）の遷移は、RoHCヘッダ解凍エンティティが決定する。RoHCヘッダ解凍エンティティは、RoHCフィードバックパケットに制御モードパラメータを付与し、RoHCヘッダ圧縮エンティティは、RoHCフィードバックパケット受信時に制御モードパラメータを確認して制御モード遷移の要否を確認する。
　ヘッダ解凍コンテキストは、RoHCヘッダ解凍エンティティ内に複数生成されることがある。RoHCヘッダ圧縮エンティティ内においても、ヘッダ解凍コンテキストに対応した圧縮状態、制御モードを複数管理することになる。対応するヘッダ解凍コンテキスト、RoHCヘッダ圧縮エンティティ内の圧縮状態、制御モードをRoHCコンテキストと呼び、コンテキスト識別子（CID）で区別している。
　以上は、例えば、非特許文献１、非特許文献２及び非特許文献３に記載されている。
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".
　しかしながら、上述したRoHCフィードバックパケット送信制御にあっては、無線環境劣化に伴い送信不可となった状況において、解凍エンティティより送信するRoHCフィードバックパケットが複数蓄積されると、無駄になる可能性がある。以下、具体的に説明する。
　図７は、蓄積したRoHCフィードバックパケットが無駄になる例を示す図である。
　図７（ａ）に示すように、無線環境劣化に伴いRoHCヘッダ解凍エンティティ（UE or eNodeB）からデータ送信不可となった場合、解凍エンティティ側のRLCサブレイヤより送信するRoHCフィードバックパケットが複数生成され、蓄積することがある。図７（ｂ）に示すように、無線環境が改善し、UEからのデータ送信が再開した際、蓄積されたRoHCフィードバックパケットがRoHCヘッダ圧縮エンティティへと配送されることになるが、古いRoHCフィードバックパケットを受けることにより、RoHCヘッダ圧縮エンティティが不用な状態遷移をすることがある。
　R-modeのRoHCヘッダ圧縮エンティティは、RoHCフィードバックパケットによりヘッダ解凍成功通知（ACK）を受信することで高圧縮状態へ遷移し、RoHCフィードバックパケットによるヘッダ解凍コンテキスト更新要求（NACK、STATIC NACK）を受信することで低圧縮状態へ遷移する。ヘッダ解凍成功通知（ACK）がRoHCヘッダ解凍エンティティ側のRLCサブレイヤに複数蓄積された後に、ヘッダ解凍コンテキスト更新要求（NACK、STATIC NACK）が生成されて送信保留されていた場合、ヘッダ解凍成功通知（ACK）を受取ったRoHCヘッダ圧縮エンティティは高圧縮状態へ遷移する。しかしながら、ヘッダ解凍コンテキスト更新要求（NACK、STATIC NACK）を受けた時点で、再び低圧縮状態へ遷移する必要があるため、高圧縮状態へ遷移させるだけ無駄となってしまう。
　高圧縮状態へ遷移した際に、RoHCヘッダ圧縮エンティティがユーザデータのヘッダ圧縮処理を実施してRoHCヘッダ解凍エンティティへと送信した場合、RoHCヘッダ解凍エンティティは、すでにヘッダ解凍コンテキスト更新が必要な状態となっており、ヘッダ解凍に失敗して破棄となる可能性が高い。
　また、上述したRoHCヘッダ解凍エンティティは、より早くRoHCフィードバックパケットをRoHCヘッダ圧縮エンティティへ返すことにより、圧縮エンティティ及び解凍エンティティの状態をより早く遷移させることができ、無線環境により適した状態での通信が可能となる。しかしながら、図８（ａ）及び図８（ｂ）に示すように、RoHCフィードバックパケット以外の送信データ（例えば、他のPDCPエンティティからの送信データ）が先にRLCサブレイヤに送信されていた場合は、先に送信されていた他の送信データの送信後にRoHCフィードバックパケットを送信することになり、無線環境により適した状態への遷移が遅れてしまう。
　本発明の目的は、RoHCヘッダ圧縮エンティティ及びRoHCヘッダ解凍エンティティの同期処理の効率化を図る受信装置、送信装置及びフィードバック方法を提供することである。
　本発明の受信装置は、ヘッダ圧縮されたデータを受信する受信手段と、前記データのヘッダ解凍を行うヘッダ解凍手段と、前記ヘッダ解凍手段におけるヘッダ解凍の成功又は失敗を示す情報を含むフィードバック情報を生成する生成手段と、前記フィードバック情報をRLCサブレイヤの制御プロトコルデータユニット（Control PDU）にマッピングするマッピング手段と、前記制御プロトコルデータユニットにマッピングされた前記フィードバック情報を送信する送信手段と、を具備する構成を採る。
　本発明の受信装置は、ヘッダ圧縮されたデータを受信する受信手段と、前記データのヘッダ解凍を行うヘッダ解凍手段と、前記ヘッダ解凍手段におけるヘッダ解凍の成功又は失敗を示す情報を含むフィードバック情報を生成する生成手段と、前記フィードバック情報を他のデータに対して優先して送信する送信手段と、を具備する構成を採る。
　本発明の送信装置は、通信相手から送信されたデータを受信する受信手段と、前記通信相手におけるヘッダ解凍の成功又は失敗を示す情報を含むフィードバック情報である、PDCPサブレイヤの制御情報が前記データに含まれる場合、順序制御を省略して前記PDCPサブレイヤの制御情報をPDCPサブレイヤに通知する通知手段と、前記フィードバック情報に応じたデータをヘッダ圧縮して送信する送信手段と、を具備する構成を採る。
　本発明のフィードバック方法は、ヘッダ圧縮されたデータのヘッダ解凍を行うヘッダ解凍工程と、前記ヘッダ解凍工程におけるヘッダ解凍の成功又は失敗を示す情報を含むフィードバック情報を生成する生成工程と、前記フィードバック情報をRLCサブレイヤの制御プロトコルデータユニット（Control PDU）にマッピングするマッピング工程と、前記制御プロトコルデータユニットにマッピングされた前記フィードバック情報を送信する送信工程と、を具備するようにした。
　本発明によれば、RoHCヘッダ圧縮エンティティ及びRoHCヘッダ解凍エンティティの同期処理の効率化を図ることができる。
LTE通信方式で使用されるネットワークアーキテクチャを示す図 ユーザデータ制御系プロトコルスタックの配置を示す図 PDCPサブレイヤ機能構成を示す図 RoHCヘッダ圧縮エンティティ状態を説明する図 RoHCヘッダ解凍エンティティ状態を説明する図 RoHCヘッダ圧縮エンティティ制御モードを説明する図 蓄積したRoHCフィードバックパケットが無駄になる例を示す図 RoHCフィードバックパケットの送信遅延が生じる例を示す図 本発明の一実施の形態に係る通信システムの構成を示すブロック図 本発明の一実施の形態に係る通信システムの構成を示すブロック図 AMモード時のRLC PDUのフォーマットを示す図 UMモード時のRLC PDUフォーマットを示す図 UMモード時のRLC PDUフォーマットを示す図
　以下、本発明の実施の形態について、図面を参照して詳細に説明する。
　（一実施の形態）
　本実施の形態は、LTE通信プロトコルを適用し、また、RLCサブレイヤ上でRoHCフィードバックパケットを送信制御する場合を例に説明する。
　図９Ａ及び図９Ｂは、本発明の一実施の形態に係る通信システムの構成を示すブロック図である。以下、図９Ａ及び図９Ｂをまとめて図９と扱う。図９においては、RoHCフィードバックパケット送信制御に直接関係しない機能ブロックの記載は省略されている。
　図９に示すように、通信システムは、RoHCヘッダ圧縮エンティティ１２１を起動している機器１００と、RoHCヘッダ解凍エンティティ２２１を起動している機器２００とを含み、機器１００と機器２００とは無線伝搬環境３００を介して接続する。
　RoHCヘッダ圧縮エンティティ１２１を起動している機器１００は、例えば、UE（携帯端末装置）であり、RoHCヘッダ解凍エンティティ２２１を起動している機器２００は、例えば、eNodeBである。
　RoHCヘッダ圧縮エンティティ１２１及びRoHCヘッダ解凍エンティティ２２１は、実際にはUEとeNodeBのそれぞれに両方が存在していることから、機器１００をeNodeB、機器２００をUEとして見ることも可能である。なお、RoHCヘッダ圧縮処理及びサイファリング処理が、機器１００及び機器２００において起動済みであるという前提で以降を説明する。
　機器１００内の上位レイヤ１１０（ユーザデータ系）からPDCPサブレイヤ１２０に対してPDCP SDUが送信される。PDCPサブレイヤ１２０では、まず、RoHCヘッダ圧縮エンティティ１２１において対象ヘッダの圧縮処理を実施する。その後、サイファリング処理部１２２にて暗号化を行い、PDCP PDU生成部１２３にてPDCPヘッダを付与する。PDCP PDUは、RLCサブレイヤ１３０へと送信される。
　RLCサブレイヤ１３０内のRLC PDCP PDU識別部１３５は、PDCPサブレイヤ１２０から送信されたPDCP PDUがPDCP CONTROL PDUかDATA PDUかを識別し、PDCP PDUがPDCP DATA PDUであれば、PDCP DATA PDUをRLC送信バッファ１３１に格納し、PDCP PDUがPDCP CONTROL PDUであれば、PDCP CONTROL PDUをControlデータバッファ１３６に格納する。
　RLC PDU生成部１３２は、Controlデータバッファ１３６およびRLC送信バッファ１３１からデータを取り出し、各データを識別するための情報、またはデータサイズおよび順序制御のための情報を含んだRLCサブレイヤのヘッダ情報を、取り出したデータに付与して、RLC PDUを生成する。RLC PDUは、下位レイヤ１４０（MAC/PHY）へと送信され、無線伝搬環境３００を通して機器２００へと転送される。
　機器２００では、下位レイヤ２４０（MAC/PHY）により無線伝搬環境３００からデータを受信し、RLC PDUが受信された場合にはRLCサブレイヤ２３０へと送信される。RLCサブレイヤ２３０内のRLC PDU解析部２３３は、受信したデータがPDCP CONTROL PDUかPDCP DATA PDU（ユーザデータ）かを判定し、受信したデータがPDCP DATA PDUであると判定した場合、PDCP DATA PDUをRLC受信バッファ２３４に格納する。一方、RLC PDU解析部２３３は、受信したデータがPDCP CONTROL PDUであると判定した場合、PDCP CONTROL PDUをPDCPサブレイヤ２２０へと送信する。
　PDCPサブレイヤ２２０内のPDCP PDU解析部２２３は、送信されたPDCP PDUがPDCP CONTROL PDUかPDCP DATA PDUかを判定し、PDCP DATA PDUについてはデサイファリング処理部２２２へと送信する。PDCP DATA PDU（ユーザデータ）は、デサイファリング処理部２２２にて暗号化解除処理が実施され、RoHCヘッダ解凍エンティティ２２１にて対象ヘッダの解凍処理が実施された上で、上位レイヤ２１５（ユーザデータ系）へと送信される。
　RoHCヘッダ解凍エンティティ２２１では、制御モードに応じてRoHCフィードバックパケットを生成することがある。例として、RoHCヘッダ解凍処理が正常に実施できた場合にヘッダ解凍成功通知（ACK）を、RoHCヘッダ解凍処理が一定回数失敗した場合にヘッダ解凍コンテキスト更新要求（NACK、STATIC NACK）を設定したRoHCフィードバックパケットを生成する。RoHCフィードバックパケットが欠損することを考慮し、RoHCヘッダ解凍実施毎にRoHCフィードバックパケットを生成することもあれば、一定時間毎に同じRoHCフィードバックパケットを再送する動作もありうる。
　RoHCヘッダ解凍エンティティ２２１で生成されたRoHCフィードバックパケットは、RoHCフィードバックパケット保管部２２５に一度格納され、PDCP PDU生成部２２４にて、PDCP CONTROL PDU内に格納してRLCサブレイヤ２３０へ送信される。
　RLC PDCP PDU識別部２３５は、送信されたPDCP PDUがPDCP CONTROL PDUかDATA PDUかを識別し、PDCP PDUがPDCP CONTROL PDUであれば、PDCP CONTROL PDUをCONTROLデータバッファ２３６に格納し、PDCP PDUがPDCP DATA PDUであれば、PDCP DATA PDUをRLC送信バッファ２３１に格納する。RLC PDU生成部２３２では、RLC送信バッファ２３１に格納されたデータに対してCONTROLデータバッファ２３６に格納されたデータを優先的に取り出して下位レイヤ２４０へ送信する。
　無線伝搬環境３００を通して機器１００の下位レイヤ１４０（MAC/PHY）で受信されたPDCP CONTROL PDUは、RLCサブレイヤ１３０へと送信される。RLCサブレイヤ１３０内では、RLC PDU解析部１３３において、送信されたPDCP CONTROL PDUを確認し、順序制御を省略してPDCPサブレイヤ１２０へ送信する。
　PDCPサブレイヤ１２０内では、PDCP PDU解析部１２４にて、PDCP CONTROL PDUを確認し、RoHCフィードバックパケットであれば、RoHCヘッダ圧縮エンティティ１２１へと送信する。RoHCヘッダ圧縮エンティティ１２１では、RoHCフィードバックパケットの内容を確認し、圧縮状態の変更、RoHCヘッダ解凍エンティティ２２１で必要としているRoHCヘッダ解凍コンテキスト情報の送信、制御モードの変更などを実施する。
　無線伝搬環境３００が良好である場合は、上記動作を繰り返すのみである。しかし、無線伝搬環境３００が劣化して伝送エラー率が高くなる、もしくはまったく送信できなくなるといった状況も発生する。このような状況において、機器２００から機器１００への送信を継続していると、送信しきれないデータがRLCサブレイヤに蓄積することで送信データ用リソースが枯渇してしまう。
　そこで、CONTROLデータバッファ２３６は、既にPDCPサブレイヤ２２０から受信しているPDCP CONTROL PDUが未送信の状態でバッファに残っている場合、古いPDCP CONTROL PDUを破棄して、新たにPDCPサブレイヤ２２０から受信したPDCP CONTROL PDUをバッファに格納する。これにより、最新のRoHCフィードバックパケット（PDCP CONTROL PDU）１つだけを機器１００へ送信することができる。なお、RoHCフィードバックパケット（PDCP CONTROL PDU）を破棄する際には、RoHCのCIDを確認して同じCIDのものだけを破棄する動作としてもよい。
　ここで、PDCPサブレイヤ１２０、２２０で生成されたPDCP DATA PDU、PDCP CONTROL PDUを、RLCサブレイヤ１３０、RLCサブレイヤ２３０において識別、解析する手段について説明する。
　まず、非特許文献２に規定されているRLCサブレイヤのAMモードを使用する場合について説明する。図１０は、AMモード時のRLC PDUのフォーマットである。RLC PDU生成部２３２がControl PDU Type (CPT) field(3bits)の未使用コードにPDCP CONTROL PDUをマッピングすることにより、RLC PDU解析部１３３ではPDCP CONTROL PDUを識別することが可能となる。つまり、非特許文献２では、CPTフィールドのコード“001”～“111”は、予約コードとして未使用であるため、コード“001”を、PDCP CONTROL PDUに割り当てることによって、簡単に識別可能となる。
　次に、非特許文献２に規定されているRLCサブレイヤのUMモードの10bit SNを使用する場合について説明する。図１１は、UMモード（10bit SN）時のRLC PDUフォーマットである。RLC PDU生成部２３２がR1で記載されている未使用領域にPDCP CONTROL PDUをマッピングすることにより、RLC PDU解析部１３３ではPDCP CONTROL PDUを識別することが可能となる。例えば、先頭のR1ビットを、AMモード時と同様に、Data/Control (D/C) fieldとして、CONTROL PDUの場合は、PDCP CONTROL PDUと判断するようにすれば識別可能である。
　最後に、RLCサブレイヤのUMモードの5bit SNを使用する場合について説明する。図１２は、UMモード（5bit SN）時のRLC PDUフォーマットである。この場合には、未使用領域がないため、PDCP PDUのヘッダを解析する必要がある。非特許文献２に規定されたPDCPヘッダの先頭1ビット（D/C）が、DATA PDUかCONTROL PDUかを識別するビットであるため、その領域を解析することにより識別が可能となる。この手段は、前述の他のフォーマットでも適用可能である。
　3G（3rd Generation）のRLCサブレイヤ（3GPP TS25.322に規定）についても同様な手段で、RLCサブレイヤにおいて、PDCP CONTROL PDUを識別することが可能である。
　このように、本実施の形態によれば、RLCサブレイヤにおいて、PDCPサブレイヤの制御情報であるRoHCフィードバックパケットを他のユーザデータに対して優先的に送信することにより、無線環境により適した状態へいち早く遷移することができる。また、RoHCフィードバックパケットの複数回送信を抑制することにより、RoCHヘッダ圧縮エンティティの冗長な状態遷移を抑制することができる。よって、これらのことから、RoHCヘッダ圧縮エンティティ及びRoHCヘッダ解凍エンティティの同期処理の効率化を図ることができる。
　以上の説明は、本発明の好適な実施の形態の例証であり、本発明の範囲はこれに限定されるものではない。
　本実施の形態では、適用例として3GPP LTE通信プロトコルスタックを基に記載しているが、本発明の範囲はこれに限定されるものではない。例えば、RoHCを適用可能なシステムであり、RoHCヘッダ解凍エンティティが存在する機器、端末にRoHCフィードバックパケットが蓄積するような状況が生じる場合、本発明を適用して最新のRoHCフィードバックパケットを１つ保管するという効率化が可能である。
　上記実施の形態では、通信システム、送信制御装置及び送信制御方法という名称を用いたが、これは説明の便宜上であり、装置は無線通信端末、ＬＴＥ端末、移動通信システム、方法は通信制御方法等であってもよい。
　さらに、上記通信システムを構成する各構成部、例えば、機器の種類、無線伝搬環境などは前述した実施の形態に限られない。
　また、上記実施の形態の説明に用いた各機能ブロックは、典型的には集積回路であるＬＳＩとして実現される。これらは個別に１チップ化されてもよいし、一部又は全てを含むように１チップ化されてもよい。ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。
　また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）、または、ＬＳＩ内部の回路セルの接続及び設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。
　さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。例えば、バイオ技術の適用等が可能である。
　２０１１年６月３０日出願の特願２０１１－１４５６１１の日本出願に含まれる明細書、図面及び要約書の開示内容は、すべて本願に援用される。
　本発明の受信装置、送信装置及びフィードバック方法は、携帯端末装置等のユーザ通信装置と基地局装置等のオペレータ通信装置との間においてパケットを通信するパケット通信システム等に有用である。
　１００、２００　機器
　１１０、２１５　上位レイヤ（ユーザデータ系）
　１２０　PDCPサブレイヤ
　１２１　RoHCヘッダ圧縮エンティティ
　１２２　サイファリング処理部
　１２３　PDCP PDU生成部
　１２４　PDCP PDU解析部
　１３０　RLCサブレイヤ
　１３１　RLC送信バッファ
　１３２　RLC PDU生成部
　１３３　RLC PDU解析部
　１３４　RLC受信バッファ
　１３５　RLC PDCP PDU識別部
　１３６　Controlデータバッファ
　１４０　下位レイヤ
　２１０　上位レイヤ（RRC）
　２２０　PDCPレイヤ
　２２１　RoHCヘッダ解凍エンティティ
　２２２　デサイファリング処理部
　２２３　PDCP PDU解析部
　２２４　PDCP PDU生成部
　２２５　RoHCフィードバックパケット保管部
　２３０　RLCサブレイヤ
　２３１　RLC送信バッファ
　２３２　RLC PDU生成部
　２３３　RLC PDU解析部
　２３４　RLC受信バッファ
　２３５　RLC PDCP PDU識別部
　２３６　Controlデータバッファ
　２４０　下位レイヤ（MAC/PHY）
　３００　無線伝搬環境

Claims (5)

  1. 　ヘッダ圧縮されたデータを受信する受信手段と、
    　前記データのヘッダ解凍を行うヘッダ解凍手段と、
    　前記ヘッダ解凍手段におけるヘッダ解凍の成功又は失敗を示す情報を含むフィードバック情報を生成する生成手段と、
    　前記フィードバック情報をRLCサブレイヤの制御プロトコルデータユニット（Control PDU）にマッピングするマッピング手段と、
    　前記制御プロトコルデータユニットにマッピングされた前記フィードバック情報を送信する送信手段と、
    　を具備する受信装置。
  2. 　前記RLCサブレイヤにおいて、PDCPサブレイヤからの制御プロトコルデータユニットを１ユニット分のみ保管する保管手段を具備する請求項１に記載の受信装置。
  3. 　ヘッダ圧縮されたデータを受信する受信手段と、
    　前記データのヘッダ解凍を行うヘッダ解凍手段と、
    　前記ヘッダ解凍手段におけるヘッダ解凍の成功又は失敗を示す情報を含むフィードバック情報を生成する生成手段と、
    　前記フィードバック情報を他のデータに対して優先して送信する送信手段と、
    　を具備する受信装置。
  4. 　通信相手から送信されたデータを受信する受信手段と、
    　前記通信相手におけるヘッダ解凍の成功又は失敗を示す情報を含むフィードバック情報である、PDCPサブレイヤの制御情報が前記データに含まれる場合、順序制御を省略して前記PDCPサブレイヤの制御情報をPDCPサブレイヤに通知する通知手段と、
    　前記フィードバック情報に応じたデータをヘッダ圧縮して送信する送信手段と、
    　を具備する送信装置。
  5. 　ヘッダ圧縮されたデータのヘッダ解凍を行うヘッダ解凍工程と、
    　前記ヘッダ解凍工程におけるヘッダ解凍の成功又は失敗を示す情報を含むフィードバック情報を生成する生成工程と、
    　前記フィードバック情報をRLCサブレイヤの制御プロトコルデータユニット（Control PDU）にマッピングするマッピング工程と、
    　前記制御プロトコルデータユニットにマッピングされた前記フィードバック情報を送信する送信工程と、
    　を具備するフィードバック方法。
PCT/JP2012/004248 2011-06-30 2012-06-29 受信装置、送信装置及びフィードバック方法 WO2013001838A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2011145611A JP2013013001A (ja) 2011-06-30 2011-06-30 受信装置、送信装置及びフィードバック方法
JP2011-145611 2011-06-30

Publications (1)

Publication Number Publication Date
WO2013001838A1 true WO2013001838A1 (ja) 2013-01-03

Family

ID=47423755

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2012/004248 WO2013001838A1 (ja) 2011-06-30 2012-06-29 受信装置、送信装置及びフィードバック方法

Country Status (2)

Country Link
JP (1) JP2013013001A (ja)
WO (1) WO2013001838A1 (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016209358A1 (en) * 2015-06-25 2016-12-29 Qualcomm Incorporated Adaptive rohc state transition
CN111800826A (zh) * 2019-08-01 2020-10-20 维沃移动通信有限公司 一种rohc反馈处理方法及用户设备
WO2023283051A1 (en) * 2021-07-09 2023-01-12 Qualcomm Incorporated Transmission of previously compressed packets to avoid throughput drop

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6524771B2 (ja) * 2015-03-23 2019-06-05 日本電気株式会社 通信装置、パケット伝送方法、及び、プログラム
CN110891287B (zh) * 2018-09-07 2021-05-28 维沃移动通信有限公司 以太网包头压缩、解压缩的方法和设备、及可读存储介质

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010537510A (ja) * 2007-08-14 2010-12-02 クゥアルコム・インコーポレイテッド Ｍａｃフレーム内のｐｄｃｐ制御ｐｄｕのトランスポート
JP2011511565A (ja) * 2008-02-01 2011-04-07 インターデイジタル パテント ホールディングス インコーポレイテッド 論理チャネルを優先順位付けするための方法および装置

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010537510A (ja) * 2007-08-14 2010-12-02 クゥアルコム・インコーポレイテッド Ｍａｃフレーム内のｐｄｃｐ制御ｐｄｕのトランスポート
JP2011511565A (ja) * 2008-02-01 2011-04-07 インターデイジタル パテント ホールディングス インコーポレイテッド 論理チャネルを優先順位付けするための方法および装置

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016209358A1 (en) * 2015-06-25 2016-12-29 Qualcomm Incorporated Adaptive rohc state transition
US9538421B1 (en) 2015-06-25 2017-01-03 Qualcomm Incorporated Adaptive ROHC state transition
CN111800826A (zh) * 2019-08-01 2020-10-20 维沃移动通信有限公司 一种rohc反馈处理方法及用户设备
WO2023283051A1 (en) * 2021-07-09 2023-01-12 Qualcomm Incorporated Transmission of previously compressed packets to avoid throughput drop

Also Published As

Publication number Publication date
JP2013013001A (ja) 2013-01-17

Similar Documents

Publication Publication Date Title
JP5244260B2 (ja) Ｐｄｃｐ層の再確立方法及び装置
EP2136501B1 (en) Method of delivering a PDCP data unit to an upper layer
KR101603624B1 (ko) 패킷 데이터 컨버젼스 프로토콜에서 제어 프로토콜 데이터 유닛의 동작
EP2135366B1 (en) Method of transmitting data in a wireless communication system
US8744433B2 (en) Mobile communication method and system
WO2012108215A1 (ja) 通信システム、送信制御装置及び送信制御方法
WO2013001838A1 (ja) 受信装置、送信装置及びフィードバック方法
KR102273873B1 (ko) Lte 시스템을 이용한 호 수행 방법 및 장치
JP5387680B2 (ja) 中継局、通信システム及び通信方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12803921

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 12803921

Country of ref document: EP

Kind code of ref document: A1