受信装置、送信装置及びフィードバック方法
【課題】RoHCヘッダ圧縮エンティティ及びRoHCヘッダ解凍エンティティの同期処理の効率化を図る受信装置、送信装置及びフィードバック方法を提供する。
【解決手段】CONTROLデータバッファ２３６は、既にPDCPサブレイヤ２２０から受信しているPDCP CONTROL PDUが未送信の状態でバッファに残っている場合、古いPDCP CONTROL PDUを破棄して、新たにPDCPサブレイヤ２２０から受信したPDCP CONTROL PDUをバッファに格納する。RLC PDU生成部２３２では、RLC送信バッファ２３１に格納されたデータに対してCONTROLデータバッファ２３６に格納されたデータを優先的に取り出して下位レイヤ２４０へ送信する。
【解決手段】CONTROLデータバッファ２３６は、既にPDCPサブレイヤ２２０から受信しているPDCP CONTROL PDUが未送信の状態でバッファに残っている場合、古いPDCP CONTROL PDUを破棄して、新たにPDCPサブレイヤ２２０から受信したPDCP CONTROL PDUをバッファに格納する。RLC PDU生成部２３２では、RLC送信バッファ２３１に格納されたデータに対してCONTROLデータバッファ２３６に格納されたデータを優先的に取り出して下位レイヤ２４０へ送信する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、圧縮可能なヘッダを有するパケットデータを通信する受信装置、送信装置及び受信装置におけるフィードバック方法に関する。
【背景技術】
【０００２】
現在、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）が生成され、無線ベアラを通る送受信データに対する制御情報が保持される。
【０００８】
無線ベアラは大きく３つに分類される。すなわち、レイヤ３（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）を適用可能であることが規定されている。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）
３００ 無線伝搬環境
【技術分野】
【０００１】
本発明は、圧縮可能なヘッダを有するパケットデータを通信する受信装置、送信装置及び受信装置におけるフィードバック方法に関する。
【背景技術】
【０００２】
現在、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）が生成され、無線ベアラを通る送受信データに対する制御情報が保持される。
【０００８】
無線ベアラは大きく３つに分類される。すなわち、レイヤ３（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）を適用可能であることが規定されている。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）
３００ 無線伝搬環境
【特許請求の範囲】
【請求項１】
ヘッダ圧縮されたデータを受信する受信手段と、
前記データのヘッダ解凍を行うヘッダ解凍手段と、
前記ヘッダ解凍手段におけるヘッダ解凍の成功又は失敗を示す情報を含むフィードバック情報を生成する生成手段と、
前記フィードバック情報をRLCサブレイヤの制御プロトコルデータユニット（Control PDU）にマッピングするマッピング手段と、
前記制御プロトコルデータユニットにマッピングされた前記フィードバック情報を送信する送信手段と、
を具備する受信装置。
【請求項２】
前記RLCサブレイヤにおいて、PDCPサブレイヤからの制御プロトコルデータユニットを１ユニット分のみ保管する保管手段を具備する請求項１に記載の受信装置。
【請求項３】
ヘッダ圧縮されたデータを受信する受信手段と、
前記データのヘッダ解凍を行うヘッダ解凍手段と、
前記ヘッダ解凍手段におけるヘッダ解凍の成功又は失敗を示す情報を含むフィードバック情報を生成する生成手段と、
前記フィードバック情報を他のデータに対して優先して送信する送信手段と、
を具備する受信装置。
【請求項４】
通信相手から送信されたデータを受信する受信手段と、
前記通信相手におけるヘッダ解凍の成功又は失敗を示す情報を含むフィードバック情報である、PDCPサブレイヤの制御情報が前記データに含まれる場合、順序制御を省略して前記PDCPサブレイヤの制御情報をPDCPサブレイヤに通知する通知手段と、
前記フィードバック情報に応じたデータをヘッダ圧縮して送信する送信手段と、
を具備する送信装置。
【請求項５】
ヘッダ圧縮されたデータのヘッダ解凍を行うヘッダ解凍工程と、
前記ヘッダ解凍工程におけるヘッダ解凍の成功又は失敗を示す情報を含むフィードバック情報を生成する生成工程と、
前記フィードバック情報をRLCサブレイヤの制御プロトコルデータユニット（Control PDU）にマッピングするマッピング工程と、
前記制御プロトコルデータユニットにマッピングされた前記フィードバック情報を送信する送信工程と、
を具備するフィードバック方法。
【請求項１】
ヘッダ圧縮されたデータを受信する受信手段と、
前記データのヘッダ解凍を行うヘッダ解凍手段と、
前記ヘッダ解凍手段におけるヘッダ解凍の成功又は失敗を示す情報を含むフィードバック情報を生成する生成手段と、
前記フィードバック情報をRLCサブレイヤの制御プロトコルデータユニット（Control PDU）にマッピングするマッピング手段と、
前記制御プロトコルデータユニットにマッピングされた前記フィードバック情報を送信する送信手段と、
を具備する受信装置。
【請求項２】
前記RLCサブレイヤにおいて、PDCPサブレイヤからの制御プロトコルデータユニットを１ユニット分のみ保管する保管手段を具備する請求項１に記載の受信装置。
【請求項３】
ヘッダ圧縮されたデータを受信する受信手段と、
前記データのヘッダ解凍を行うヘッダ解凍手段と、
前記ヘッダ解凍手段におけるヘッダ解凍の成功又は失敗を示す情報を含むフィードバック情報を生成する生成手段と、
前記フィードバック情報を他のデータに対して優先して送信する送信手段と、
を具備する受信装置。
【請求項４】
通信相手から送信されたデータを受信する受信手段と、
前記通信相手におけるヘッダ解凍の成功又は失敗を示す情報を含むフィードバック情報である、PDCPサブレイヤの制御情報が前記データに含まれる場合、順序制御を省略して前記PDCPサブレイヤの制御情報をPDCPサブレイヤに通知する通知手段と、
前記フィードバック情報に応じたデータをヘッダ圧縮して送信する送信手段と、
を具備する送信装置。
【請求項５】
ヘッダ圧縮されたデータのヘッダ解凍を行うヘッダ解凍工程と、
前記ヘッダ解凍工程におけるヘッダ解凍の成功又は失敗を示す情報を含むフィードバック情報を生成する生成工程と、
前記フィードバック情報をRLCサブレイヤの制御プロトコルデータユニット（Control PDU）にマッピングするマッピング工程と、
前記制御プロトコルデータユニットにマッピングされた前記フィードバック情報を送信する送信工程と、
を具備するフィードバック方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【公開番号】特開２０１３−１３００１（Ｐ２０１３−１３００１Ａ）
【公開日】平成２５年１月１７日（２０１３．１．１７）
【国際特許分類】
【出願番号】特願２０１１−１４５６１１（Ｐ２０１１−１４５６１１）
【出願日】平成２３年６月３０日（２０１１．６．３０）
【出願人】（０００００５８２１）パナソニック株式会社 (73,050)
【Ｆターム（参考）】
【公開日】平成２５年１月１７日（２０１３．１．１７）
【国際特許分類】
【出願日】平成２３年６月３０日（２０１１．６．３０）
【出願人】（０００００５８２１）パナソニック株式会社 (73,050)
【Ｆターム（参考）】
[ Back to top ]