特許 7149258 無線通信装置及び無線通信方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2022-09-28

(45)【発行日】2022-10-06

(54)【発明の名称】無線通信装置及び無線通信方法

(51)【国際特許分類】

   H04W 28/06 20090101AFI20220929BHJP

   H04W 80/06 20090101ALI20220929BHJP

【ＦＩ】

H04W28/06

H04W80/06

【請求項の数】 3

(21)【出願番号】P 2019505574

(86)(22)【出願日】2017-03-14

(86)【国際出願番号】 JP2017010280

(87)【国際公開番号】W WO2018167858

(87)【国際公開日】2018-09-20

【審査請求日】2020-02-07

【審判番号】

【審判請求日】2022-01-26

(73)【特許権者】

【識別番号】392026693

【氏名又は名称】株式会社ＮＴＴドコモ

(74)【代理人】

【識別番号】100083806

【弁理士】

【氏名又は名称】三好 秀和

(72)【発明者】

【氏名】内野 徹

(72)【発明者】

【氏名】ハプサリ ウリ アンダルマワンティ

(72)【発明者】

【氏名】高橋 秀明

(72)【発明者】

【氏名】花木 明人

【合議体】

【審判長】廣川 浩

【審判官】中木 努

【審判官】石田 紀之

(56)【参考文献】

【文献】米国特許出願公開第２０１６／０１８３１２３（ＵＳ，Ａ１）

【文献】特開２０１６－０４６６５２（ＪＰ，Ａ）

【文献】Ａｐｐｌｅ， ＬＧ Ｅｌｅｃｔｒｏｎｉｃｓ，ＲｏＨＣ Ｓｙｍｍｅｔｒｉｃ ＤＬ／ＵＬ Ｐａｒａｍｅｔｅｒｓ Ｌｉｍｉｔａｔｉｏｎ ｉｎ ＬＴＥ，３ＧＰＰ ＴＳＧ－ＲＡＮ ＷＧ２ ＃９７ Ｒ２－１７０１７６１，３ＧＰＰ，２０１７年０２月０４日アップロード

(58)【調査した分野】(Int.Cl.，ＤＢ名)

H04W4/00-99/00

(57)【特許請求の範囲】

【請求項1】

上りリンクまたは下りリンクの何れか一方に、パケット・データ・コンバージェンス・プロトコル・レイヤにおけるヘッダ圧縮を適用する非対称ヘッダ圧縮を実行する無線通信装置であって、
前記無線通信装置の能力情報を対向無線通信装置に通知する能力通知部を備え、
前記能力通知部は、前記上りリンク及び前記下りリンクの両方に前記ヘッダ圧縮を適用する対称ヘッダ圧縮の内容を示すフィールドと、前記対称ヘッダ圧縮の内容を示すフィールドとは別個である前記非対称ヘッダ圧縮の内容を示すフィールドとを含む前記能力情報を通知する無線通信装置。

【請求項2】

前記非対称ヘッダ圧縮の内容を示すフィールド、及び前記対称ヘッダ圧縮の内容を示すフィールドは、サポート可能な前記ヘッダ圧縮のプロファイルと、前記ヘッダ圧縮に用いることができるセッション数と含み、
前記能力通知部は、少なくとも前記非対称ヘッダ圧縮のプロファイルについて、前記対称ヘッダ圧縮のプロファイルを示すフィールドを共用する請求項１に記載の無線通信装置。

【請求項3】

上りリンクまたは下りリンクの何れか一方に、パケット・データ・コンバージェンス・プロトコル・レイヤにおけるヘッダ圧縮を適用する非対称ヘッダ圧縮を実行する無線通信装置における無線通信方法であって、
前記上りリンク及び前記下りリンクの両方に前記ヘッダ圧縮を適用する対称ヘッダ圧縮の内容を示すフィールドと、前記対称ヘッダ圧縮の内容を示すフィールドとは別個である前記非対称ヘッダ圧縮の内容を示すフィールドとを、前記無線通信装置の能力情報に含めるステップと、
前記能力情報を対向無線通信装置に通知するステップと
を含む無線通信方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、パケット・データ・コンバージェンス・プロトコル・レイヤ（PDCPレイヤ）におけるヘッダ圧縮を適用する無線通信装置及び無線通信方法に関する。

【背景技術】

【0002】

3rd Generation Partnership Project（3GPP）は、Long Term Evolution（LTE）を仕様化し、LTEのさらなる高速化を目的としてLTE-Advanced（以下、LTE-Advancedを含めてLTEという）を仕様化している。また、3GPPでは、さらに、5G（5th generation mobile communication system）などと呼ばれるLTEの後継システムの仕様が検討されている。

【0003】

LTEでは、音声パケットを伝送することが可能（VoLTE）だが、音声パケットは、ペイロードに対するヘッダ（RTP/UDP/IP）の比率が高いため、当該ヘッダを圧縮することが規定されている。具体的には、LTEのパケット・データ・コンバージェンス・プロトコル・レイヤ（PDCPレイヤ）では、RFC3095などで規定されるRObust Header Compression（ROHC）に従って、RTP/UDP/IPなどのヘッダが圧縮される。これにより、音声パケットの伝送効率を高めている。

【0004】

LTEでは、圧縮対象のヘッダの種類などに応じた複数のROHC Profileが規定されており、ユーザ装置（UE）は、サポート可能なROHC Profile（supportedROHC-Profiles）、及びROHCに用い得るセッション数、具体的には、ROHCに用い得るメモリ数（maxNumberROHC-ContextSessions）のフィールドを含む、当該UEの能力情報（UE-EUTRA-Capability）を無線基地局（eNB）に通知する。

【0005】

一方、LTEのRelease-14では、主にUEのメモリ及び消費電力削減のため、上りリンク（UL）のみ、或いは下りリンク（DL）のみ、ROHCによるヘッダ圧縮を適用すること（便宜上、Asymmetric ROHC（非対称ヘッダ圧縮）という）が検討されている（例えば、非特許文献１参照）。

【先行技術文献】

【非特許文献】

【0006】

【文献】“RoHC Symmetric DL/UL Parameters Limitation in LTE”, 3GPP TSG-RAN WG2 #97, 3R2-1701761, 2017年2月

【発明の概要】

【0007】

上述したAsymmetric ROHC（非対称ヘッダ圧縮）は、UL及びDLの両方にROHCを適用する既存のヘッダ圧縮（便宜上、Symmetric ROHC（対称ヘッダ圧縮）という）に対して制約を設ける制御となるため、単にAsymmetric ROHCを導入しても、バックワードコンパチビリティーを確保できない問題がある。

【0008】

具体的には、UE能力（UE-EUTRA-Capability）を示す既存のフィールド（supportedROHC-Profiles）にAsymmetric ROHCに対応可能なことを示す内容を単に追加しても、Asymmetric ROHCに対応していない非対応eNBは、Asymmetric ROHCに関連する当該フィールドの内容を認識することができない。このため、非対応eNBは、Asymmetric ROHCに対応しているUEと、Symmetric ROHCの設定を試みてしまい、Asymmetric ROHCを正しく設定できないことが懸念される。

【0009】

そこで、本発明は、このような状況に鑑みてなされたものであり、上りリンクまたは下りリンクの何れか一方にROHCによるヘッダ圧縮が適用される非対称ヘッダ圧縮をサポートする無線基地局と、既存の対称ヘッダ圧縮のみをサポートする無線基地局とが混在する場合でも、適切に非対称ヘッダ圧縮を設定することができるユーザ装置などの無線通信装置及び無線通信方法の提供を目的とする。

【0010】

本発明の一態様は、上りリンクまたは下りリンクの何れか一方に、パケット・データ・コンバージェンス・プロトコル・レイヤにおけるヘッダ圧縮を適用する非対称ヘッダ圧縮を実行する無線通信装置であって、対向無線通信装置から、前記非対称ヘッダ圧縮をサポートしていることを示すサポート通知を受信するサポート通知受信部と、前記サポート通知受信部が前記サポート通知を受信した場合、前記非対称ヘッダ圧縮のプロファイルを無線通信装置の能力情報に含めることによって、前記非対称ヘッダ圧縮の設定に用いる情報を前記対向無線通信装置に通知する能力通知部とを備える。

【0011】

本発明の一態様は、上りリンクまたは下りリンクの何れか一方に、パケット・データ・コンバージェンス・プロトコル・レイヤにおけるヘッダ圧縮を適用する非対称ヘッダ圧縮を実行する無線通信装置であって、前記ヘッダ圧縮が適用された圧縮パケットを受信するパケット受信部と、前記パケット受信部が前記圧縮パケットを受信した場合、前記無線通信装置の受信方向において前記ヘッダ圧縮を適用しない前記非対称ヘッダ圧縮を適用するため、前記圧縮パケットを受信できなかったことを示す否定応答を対向無線通信装置に送信する否定応答送信部とを備える。

【0012】

本発明の一態様は、上りリンクまたは下りリンクの何れか一方に、パケット・データ・コンバージェンス・プロトコル・レイヤにおけるヘッダ圧縮を適用する非対称ヘッダ圧縮を実行する無線通信装置であって、前記無線通信装置の能力情報を対向無線通信装置に通知する能力通知部を備え、前記能力通知部は、前記上りリンク及び前記下りリンクの両方に前記ヘッダ圧縮を適用する対称ヘッダ圧縮の内容を示すフィールドと、前記対称ヘッダ圧縮の内容を示すフィールドとは別個である前記非対称ヘッダ圧縮の内容を示すフィールドとを含む前記能力情報を通知する。

【0013】

本発明の一態様は、上りリンクまたは下りリンクの何れか一方に、パケット・データ・コンバージェンス・プロトコル・レイヤにおけるヘッダ圧縮を適用する非対称ヘッダ圧縮を実行する無線通信装置における無線通信方法であって、対向無線通信装置から、前記非対称ヘッダ圧縮をサポートしていることを示すサポート通知を受信するステップと、前記サポート通知を受信した場合、前記非対称ヘッダ圧縮のプロファイルを無線通信装置の能力情報に含めることによって、前記非対称ヘッダ圧縮の設定に用いる情報を前記対向無線通信装置に通知するステップとを含む。

【0014】

本発明の一態様は、上りリンクまたは下りリンクの何れか一方に、パケット・データ・コンバージェンス・プロトコル・レイヤにおけるヘッダ圧縮を適用する非対称ヘッダ圧縮を実行する無線通信装置における無線通信方法であって、前記ヘッダ圧縮が適用された圧縮パケットを受信するステップと、前記圧縮パケットを受信した場合、前記無線通信装置の受信方向において前記非対称ヘッダ圧縮を適用するため、前記圧縮パケットを受信できなかったことを示す否定応答を対向無線通信装置に送信するステップとを含む。

【0015】

本発明の一態様は、上りリンクまたは下りリンクの何れか一方に、パケット・データ・コンバージェンス・プロトコル・レイヤにおけるヘッダ圧縮を適用する非対称ヘッダ圧縮を実行する無線通信装置における無線通信方法であって、前記上りリンク及び前記下りリンクの両方に前記ヘッダ圧縮を適用する対称ヘッダ圧縮の内容を示すフィールドと、前記対称ヘッダ圧縮の内容を示すフィールドとは別個である前記非対称ヘッダ圧縮の内容を示すフィールドとを、前記無線通信装置の能力情報に含めるステップと、前記能力情報を対向無線通信装置に通知するステップとを含む。

【図面の簡単な説明】

【0016】

【図1】図１は、無線通信システム10の全体概略構成図である。

【図2】図２は、UE200の機能ブロック構成図である。

【図3】図３は、eNB100Aの機能ブロック構成図である。

【図4】図４（ａ）及び（ｂ）は、Symmetric ROHC及びAsymmetric ROHCの概念図である。

【図5】図５は、UE200の動作フロー図（動作例１）である。

【図6】図６（ａ）及び（ｂ）は、既存のSymmetric ROHCの内容を示すフィールド及びAsymmetric ROHCの内容を示すフィールドの構成例を示す図である。

【図7】図７は（ａ）及び（ｂ）は、既存のSymmetric ROHCの内容を示すフィールドにAsymmetric ROHCをサポートすることを示す情報を含めた能力情報の構成例を示す図である。

【図8】図８は、eNB100AとUE200とによるAsymmetric ROHCの適用動作シーケンス（動作例２）を示す図である。

【図9】図９は、UE200の動作フロー図（動作例２）である。

【図10】図１０は、UE200の動作フロー図（動作例３）である。

【図11】図１１（ａ）及び（ｂ）は、eNB100A及びeNB100BにおけるAsymmetric ROHCの適用動作フロー図である。

【図12】図１２（ａ）、（ｂ）及び（ｃ）は、UE-EUTRA-Capabilityに含まれるフィールド（Capability field）の構成例を示す図である。

【図13】図１３（ａ）～（ｄ）は、Symmetric ROHC及びAsymmetric ROHCが混在し得る場合におけるROHCの設定例を示す図である。

【図14】図１４は、Symmetric ROHC及びAsymmetric ROHCが混在する場合において、UE200が指定する割り当てパタン例を示す図である。

【図15】図１５（ａ）、（ｂ）及び（ｃ）は、Symmetric ROHC及びAsymmetric ROHCが混在する場合における割り当てパタンの通知例を示す図である。

【図16】図１６は、eNB100A, 100B、及びUE200のハードウェア構成の一例を示す図である。

【発明を実施するための形態】

【0017】

以下、実施形態を図面に基づいて説明する。なお、同一の機能や構成には、同一または類似の符号を付して、その説明を適宜省略する。

【0018】

（１）無線通信システムの全体概略構成
図１は、本実施形態に係る無線通信システム10の全体概略構成図である。無線通信システム10は、Long Term Evolution（LTE）に従った無線通信システムであり、無線アクセスネットワーク20及びユーザ装置200（以下、UE200）を含む。

【0019】

無線アクセスネットワーク20は、3GPPにおいて規定されるEvolved Universal Terrestrial Radio Access Network（E-UTRAN）であり、無線基地局100A, 無線基地局100B（以下、eNB100A, eNB100B）を含む。なお、無線通信システム10は、必ずしもLTE（E-UTRAN）に限定されない。例えば、無線アクセスネットワーク20は、5Gとして規定されるUE200（ユーザ装置）と無線通信を実行する無線基地局を含む無線アクセスネットワークであってもよい。

【0020】

eNB100A, 100B及びUE200は、LTEの仕様に従った無線通信を実行する。具体的には、eNB100A及びUE200は、LTE Release-14に従った無線通信を実行する。一方、eNB100Bは、LTE Release-14には対応しておらず、Release-14よりも前のRelease（例えば、Release-13）に対応している。また、eNB100A, 100B及びUE200は、音声パケットの伝送（VoLTE）に対応している。

【0021】

本実施形態において、UE200は、無線通信装置を構成し、eNB100Aは、UE200と対向して無線通信を実行する対向無線通信装置を構成する。

【0022】

UE200は、eNB100A, 100Bと、ユーザデータ用の無線ベアラであるデータ無線ベアラ（DRB）を設定する。具体的には、UE200は、eNB100AとDRB31を設定する。また、UE200は、eNB100BとDRB32を設定する。なお、UE200は、eNB100A及びeNB100Bとシグナリング用の無線ベアラ（SRB、不図示）を設定する。

【0023】

eNB100A及びUE200は、上りリンク（UL）または下りリンク（DL）の何れか一方に、パケット・データ・コンバージェンス・プロトコル・レイヤ（PDCPレイヤ）におけるヘッダ圧縮（具体的には、ROHC RTP/UDP/IPなど）を適用する非対称ヘッダ圧縮を実行する。具体的には、eNB100A及びUE200は、ULのみ、或いはDLのみ、RObust Header Compression（ROHC）によるヘッダ圧縮を適用するAsymmetric ROHCをサポートしている。なお、本実施形態では、ULのみにROHCを適用し、DLにはROHCが適用されないケースを例として説明する。

【0024】

（２）無線通信システムの機能ブロック構成
次に、無線通信システム10の機能ブロック構成について説明する。具体的には、eNB100A及びUE200の機能ブロック構成について説明する。

【0025】

（２．１）UE200
図２は、UE200の機能ブロック構成図である。図２に示すように、UE200は、無線通信部210、データ送受信部220、ヘッダ圧縮処理部230、能力通知部240及びACK/NACK処理部250を備える。

【0026】

無線通信部210は、eNB100A及びeNB100BとLTEに従った無線通信を実行する。具体的には、無線通信部210は、eNB100AとDRB31（図１参照）を設定することができる。また、無線通信部210は、eNB100BとDRB32（図１参照）を設定することができる。さらに、無線通信部210は、eNB100A及びeNB100Bと、シグナリング用の無線ベアラ（SRB、不図示）を設定することができる。

【0027】

データ送受信部220は、ユーザデータを含むパケット、及び制御データを含むパケットを送受信する。

【0028】

また、データ送受信部220は、無線アクセスネットワーク20（具体的には、eNB100AまたはeNB100B）から報知情報（MIB（Master Information Block）及びSIB（System Information Block））を受信する。さらに、データ送受信部220は、個別シグナリングによる情報、特に、本実施形態では、UE capability enquiry、或いはRRC Connection Reconfigurationを受信する。なお、報知情報及び／又はシグナリングについては、後述する。以降の説明においても、報知情報及び／又はシグナリングは後述の種類・手段などを適宜適用してもよい。

【0029】

データ送受信部220は、eNB100A（対向無線通信装置）から、Asymmetric ROHC（非対称ヘッダ圧縮）をサポートしていることを示すサポート通知を受信する。本実施形態において、データ送受信部220は、サポート通知受信部を構成する。

【0030】

具体的には、データ送受信部220は、上述した報知情報、或いは個別シグナリングによって、当該サポート通知を受信する。

【0031】

また、データ送受信部220は、ROHCが適用された圧縮パケットを受信する。本実施形態において、データ送受信部220は、パケット受信部を構成する。具体的には、データ送受信部220は、ROHC（ヘッダ圧縮）が適用されていない非圧縮パケットを受信した後、当該非圧縮パケットに続けて、圧縮パケットを受信する。

【0032】

ヘッダ圧縮処理部230は、データ送受信部220が送受信するパケットのヘッダの圧縮及び伸張処理を実行する。具体的には、ヘッダ圧縮処理部230は、ROHCに従って、RTP/UDP/IPヘッダなどの圧縮（compress）及び伸張（decompress）を実行する。ヘッダ圧縮処理部230は、ヘッダ圧縮に用いることができるセッション数（maxNumberROHC-ContextSessions）に応じたメモリを搭載する。

【0033】

ROHCでは、音声パケットのようなRTPパケットの場合、RTP/UDP/IPヘッダフィールドのうち、パケット間で変化のある部分のみを送信することによって、実際に送信するビット数を低減する。ROHCでは、当該ヘッダを最小３バイトまで圧縮できる。

【0034】

変化しないフィールド（Static part）として、は、SSRC（RTPレイヤの識別子）及びIPアドレスなどが挙げられる。変化するフィールド（dynamic part）としては、RTP timestamp、RTP-Sequence Number及びUDP checksumなどが挙げられる。

【0035】

なお、一つのベアラ（DRB）に対して、複数のRTP/RTCPセッションが設定されることがあるが、当該複数セッションのうち、幾つのセッションに対してヘッダ圧縮が可能かは、UE200及びeNB100A（eNB100B）の能力に依存する。

【0036】

上述したように、UE200、つまり、ヘッダ圧縮処理部230は、Asymmetric ROHCをサポートしている。

【0037】

図４（ａ）及び（ｂ）は、Symmetric ROHC及びAsymmetric ROHCの概念図である。具体的には、図４（ａ）は、Symmetric ROHC（対称ヘッダ圧縮）の概念図を示し、図４（ｂ）は、Asymmetric ROHC（非対称ヘッダ圧縮）の概念図を示す。

【0038】

図４（ａ）及び（ｂ）に示すように、Symmetric ROHCでは、ULデータ及びDLデータ（パケット）の両方において、ROHCによるヘッダ圧縮・伸張が実行されるが、Asymmetric ROHCでは、ULデータのみにおいて、ROHCによるヘッダ圧縮・伸張が実行される。つまり、DLデータについては、ROHCが適用されない。

【0039】

Asymmetric ROHC導入のモチベーションは、TDD（Time Division Duplex）のようにDL及びULの無線リソースが非対称である場合、ROHCによる利点（伝送効率化）は、何れかのリンクのみで大きいという想定に基づいている。例えば、DLにおけるサブフレーム数が、ULにおけるサブフレーム数よりもかなり多くなるようなTDDの構成では、ROHCによる利点は、無線リソース（サブフレーム数）が少ないULに対して、より大きくなる。

【0040】

なお、一方のリンクにおいてROHC非適用とする方法としては、ROHC（Compressor）をバイパスする方法、或いは当該データをUncompressed sessionにのみ割り当てる方法が考えられる。

【0041】

能力通知部240は、UE200（無線通信装置）の能力情報をeNB100A（対向無線通信装置）に通知する。なお、能力通知部240は、当該能力情報をeNB100Bにも通知することができる。ここでは、eNB100Aへの通知を例として説明する。

【0042】

能力通知部240は、UE200の能力情報として、UE-EUTRA-CapabilityをeNB100Aに通知する。

【0043】

具体的には、能力通知部240は、データ送受信部220（サポート通知受信部）がサポート通知を受信した場合、Asymmetric ROHCのプロファイルをUE200の能力情報に含めることによって、Asymmetric ROHCの設定に用いる情報（ここでは、ROHC Capabilityという）をeNB100Aに通知する。

【0044】

なお、既存のSymmetric ROHCのプロファイルについては、3GPP TS 36.323 Packet Data Convergence Protocol (PDCP) specificationの5.5.1章（Supported header compression protocols and profiles）に規定されているが、本実施形態では、Asymmetric ROHCのプロファイル（ROHC Profile）が追加されている。

【0045】

より具体的には、能力通知部240は、データ送受信部220（サポート通知受信部）がサポート通知を受信した場合、UL及びDLの両方にROHCを適用するSymmetric ROHCの内容を示すフィールドと、Symmetric ROHCの内容を示すフィールドとは別個であるAsymmetric ROHCの内容を示すフィールドとを含む当該能力情報（UE-EUTRA-Capability）をeNB100Aに通知することができる。

【0046】

また、能力通知部240は、データ送受信部220（サポート通知受信部）がサポート通知を受信した場合、Symmetric ROHCの内容を示すフィールドに、Asymmetric ROHCをサポートすることを示す情報を含めた能力情報をeNB100Aに通知することもできる。

【0047】

つまり、能力通知部240は、Asymmetric ROHCのプロファイル（ROHC Profile）をUE-EUTRA-Capabilityに含めることによって、Asymmetric ROHCの設定に用いる情報をeNB100Aに通知することができる。

【0048】

また、能力通知部240は、データ送受信部220（サポート通知受信部）がサポート通知を受信したか否かに関わらず、Symmetric ROHCの内容を示すフィールドと、Symmetric ROHCの内容を示すフィールドとは別個であるAsymmetric ROHCの内容を示すフィールドとを含む能力情報をeNB100Aに通知することもできる。

【0049】

Asymmetric ROHCの内容を示すフィールド、及びSymmetric ROHCの内容を示すフィールドは、サポート可能なヘッダ圧縮のプロファイル（supportedROHC-Profiles）と、ヘッダ圧縮に用いることができるセッション数（maxNumberROHC-ContextSessions）と含んでいる。

【0050】

なお、能力通知部240は、少なくともAsymmetric ROHCのプロファイルについて、Symmetric ROHCのプロファイルを示すフィールド（supportedROHC-Profiles）を共用してもよい。さらに、能力通知部240は、Asymmetric ROHCのヘッダ圧縮に用いることができるセッション数について、Symmetric ROHCのヘッダ圧縮に用いることができるセッション数を示すフィールド（maxNumberROHC-ContextSessions）を共用してもよい。

【0051】

ACK/NACK処理部250は、データ送受信部220が受信したパケットに対するACK（肯定応答）及びNACK（否定応答）の送信処理を実行する。

【0052】

特に、本実施形態では、ACK/NACK処理部250は、データ送受信部220（パケット受信部）がROHCによる圧縮パケットを受信した場合、UE200（無線通信装置）の受信方向においてROHCを適用しないAsymmetric ROHCを適用するため、つまり、Asymmetric ROHCの適用を目的として、当該圧縮パケットを受信できなかったことを示すNACK（否定応答）をeNB100A（対向無線通信装置）に送信する。

【0053】

なお、NACKは、圧縮パケットを受信できなかった場合だけでなく、当該圧縮パケットのヘッダを伸張できなかった場合にも送信される。本実施形態において、ACK/NACK処理部250は、否定応答送信部を構成する。

【0054】

具体的には、Asymmetric ROHCにより、DLに対してROHC非適用とする場合、ACK/NACK処理部250は、非圧縮パケットに引き続いて、ROHCによる圧縮パケットを受信した場合、当該圧縮パケットに対するNACKまたはSTATIC-NACKを返送する。これにより、ROHCによるヘッダ圧縮が中止され、データ送受信部220は、非圧縮パケットを連続して受信することができる。

【0055】

（２．２）eNB100A
図３は、eNB100Aの機能ブロック構成図である。図３に示すように、eNB100Aは、無線通信部110、データ送受信部120、ヘッダ圧縮処理部130及びUE能力取得部140を備える。

【0056】

無線通信部110は、上述した無線通信部210と同様に、UE200とLTEに従った無線通信を実行する。
具体的には、無線通信部110は、UE200とDRB31（図１参照）を設定することができる。さらに、無線通信部110は、UE200とシグナリング用の無線ベアラ（SRB、不図示）を設定することができる。

【0057】

データ送受信部120は、上述したデータ送受信部220と同様に、ユーザデータを含むパケット、及び制御データを含むパケットを送受信する。

【0058】

また、データ送受信部120は、報知情報（MIB（Master Information Block）及びSIB（System Information Block））を送信する。さらに、データ送受信部120は、個別シグナリングによる情報、特に、本実施形態では、UE capability enquiry、或いはRRC Connection Reconfigurationを送信する。

【0059】

データ送受信部120は、eNB100AがAsymmetric ROHC（非対称ヘッダ圧縮）をサポートしていることを示すサポート通知をUE200に送信する。具体的には、データ送受信部120は、上述した報知情報、或いは個別シグナリングによって、当該サポート通知を送信する。

【0060】

ヘッダ圧縮処理部130は、上述したヘッダ圧縮処理部230と同様に、データ送受信部120が送受信するパケットのヘッダ圧縮処理を実行する。具体的には、ヘッダ圧縮処理部130は、UE能力取得部140によって取得されたUE200の能力情報に基づいて、ヘッダ圧縮処理を実行する。

【0061】

より具体的には、ヘッダ圧縮処理部130は、ROHCに従って、RTP/UDP/IPヘッダなどの圧縮（compress）及び伸張（decompress）を実行する。

【0062】

また、上述したように、eNB100A、つまり、ヘッダ圧縮処理部130は、Asymmetric ROHCをサポートしている。

【0063】

UE能力取得部140は、UE200の能力情報を取得する。具体的には、UE能力取得部140は、UE200から通知されたUE-EUTRA-Capabilityの内容に基づいて、UE200の各種能力を取得する。

【0064】

特に、本実施形態では、UE能力取得部140は、Symmetric ROHC及びAsymmetric ROHCについて、サポート可能なヘッダ圧縮のプロファイル（supportedROHC-Profiles）と、ヘッダ圧縮に用いることができるセッション数（maxNumberROHC-ContextSessions）を取得する。

【0065】

UE能力取得部140は、取得した当該情報をヘッダ圧縮処理部130などに提供する。

【0066】

（３）無線通信システムの動作
次に、無線通信システム10の動作について説明する。具体的には、eNB100AとUE200とにおけるAsymmetric ROHCの適用動作について説明する。

【0067】

より具体的には、以下の３つの動作例について説明する。

【0068】

(i) UE200は、無線アクセスネットワーク20（eNB100A）がAsymmetric ROHCに対応している場合にのみ、Asymmetric ROHCの能力情報を通知する。

【0069】

(ii) UE200は、eNB100Aから送信されたROHCによる圧縮パケットに対してNACKを送信する。

【0070】

(iii) UE200は、Symmetric ROHC及びAsymmetric ROHCの両方の能力情報を送信する。

【0071】

（３．１）動作例１
図５は、UE200の動作フロー図（動作例１）である。図５に示すように、UE200は、eNB100Aから、無線アクセスネットワーク20（eNB100A）がAsymmetric ROHCをサポートしていることを示すサポート通知を受信したか否かを判定する（S10）。これにより、UE200は、eNB100AがAsymmetric ROHCをサポートしていることを認識し得る。

【0072】

なお、eNB100Aは、Asymmetric ROHCをサポートしていることを直接的に示すのではなく、Asymmetric ROHCが導入されたRRC（Radio Resource Control）のバージョンに対応していることを示すサポート通知を送信してもよい。

【0073】

UE200は、当該サポート通知を受信した場合、Asymmetric ROHCの設定に用いる情報（ROHC Capability）をeNB100Aに通知する（S20）。

【0074】

具体的には、UE200は、ROHC Capabilityとして、サポート可能なヘッダ圧縮のプロファイル（supportedROHC-Profiles）、及びヘッダ圧縮に用いることができるセッション数（maxNumberROHC-ContextSessions）を含むUE200の能力情報（UE-EUTRA-Capability）をeNB100Aに通知する。

【0075】

図６（ａ）及び（ｂ）は、既存のSymmetric ROHCの内容を示すフィールド及びAsymmetric ROHCの内容を示すフィールドの構成例を示す。

【0076】

既存のSymmetric ROHCの内容を示すフィールド（Capability field(Conventional)）及びAsymmetric ROHCの内容を示すフィールド（Capability field(New)）は、UE200の能力情報（UE-EUTRA-Capability）に含まれる。

【0077】

図６（ａ）に示すように、eNB100Aは、Asymmetric ROHCのサポート通知をUE200に送信する。この場合、UE200は、Capability field(Conventionalを含めず、Capability field(Newのみを含む能力情報をeNB100Aに通知する。つまり、UE200は、Capability field(Conventionalを利用しない。

【0078】

一方、図６（ｂ）に示すように、eNB100Bは、Asymmetric ROHCをサポートしていないため、Asymmetric ROHCのサポート通知を送信しない。この場合、UE200は、Capability field(Conventional及びCapability field(Newの何れも利用せず、eNB100Bに送信しない。

【0079】

eNB100Bは、Capability field(Conventionalを含む能力情報も受信しないため、UE200が単にROHCをサポートしていないと判定し、ROHCによるヘッダ圧縮を実行しない。つまり、eNB100Bは、ROHCをサポートしていないUEとしてUE200を取り扱うことになる。

【0080】

図７（ａ）及び（ｂ）は、既存のSymmetric ROHCの内容を示すフィールドにAsymmetric ROHCをサポートすることを示す情報を含めた能力情報の構成例を示す。

【0081】

図７（ａ）及び（ｂ）に示す能力情報の構成例では、既存のSymmetric ROHCの内容を示すフィールド（Capability field）を流用し、eNBがAsymmetric ROHCをサポートしている場合にのみ、Asymmetric ROHCの内容を含める。

【0082】

図７（ａ）に示すように、eNB100Aは、Asymmetric ROHCのサポート通知をUE200に送信する。この場合、UE200は、既存のsupportedROHC-Profilesを流用して、Asymmetric ROHCのプロファイルを通知する。図７（ａ）では、Profile0x0001がTrueに設定されている。また、ヘッダ圧縮に用いることができるセッション数maxNumberROHC-ContextSessionsが2に設定されている。この数値は、ULに適用される当該セッション数のみを意味する。つまり、Asymmetric ROHC適用時の数値である。

【0083】

また、図７（ａ）に示すように、UE200は、既存のsupportedROHC-Profilesを流用して、Asymmetric ROHCをサポートしていることを通知する。図７（ａ）では、PDCP-parameters-14（Release-14用のPDCPパラメータ）として、Asymmetric ROHCがサポートされることが示されている。

【0084】

このようなCapability fieldを含む能力情報を受信したeNB100Aは、UE200がAsymmetric ROHCをサポートしていることを認識するとともに、maxNumberROHC-ContextSessionsの数値については、既存のSymmetric ROHCのようなUL及びDL両方向を含む数値ではなく、片方向（UL）のみに適用される数値に読み替える。

【0085】

一方、図７（ｂ）に示すように、eNB100Bは、Asymmetric ROHCをサポートしていないため、Asymmetric ROHCのサポート通知を送信しない。この場合、UE200は、Capability fieldを含む能力情報自体は送信するが、ROHCをサポートしていないことを示すsupportedROHC-Profilesを設定する。具体的には、図７（ｂ）では、Profile0x0001及びProfile0x0002の何れもがFalseに設定されている。

【0086】

このようなCapability fieldを含む能力情報を受信したeNB100Bは、UE200が単にROHCをサポートしていないと判定し、ROHCによるヘッダ圧縮を実行しない。

【0087】

（３．２）動作例２
図８は、eNB100AとUE200とによるAsymmetric ROHCの適用動作シーケンス（動作例２）を示す。

【0088】

図８に示すように、eNB100Aは、UE200との通信を開始し、ROHCによるヘッダ圧縮が実行されていない、つまり、フルヘッダを含むIRパケットを所定数送信する（S110～S130）。

【0089】

なお、IRパケットとは、RFC3095において規定されているパケットの一種（Initiation and Refresh state）であり、Decompressor側において、ROHC Contextを確立するために用いられる。

【0090】

より具体的には、IRパケットでは、IPパケットは圧縮されずにフルヘッダで送信され、Decompressor側は、当該ヘッダの内容や変化パターンを基にコンテキストを確立することが可能である。なお、ROHCに必要なその他の情報（例えば、Context ID）は、ROHCヘッダを用いてさらに通知される。

【0091】

次いで、eNB100Aは、フルヘッダを含むIRパケットを所定数送信した後、ROHCによるヘッダ圧縮が実行されたUO-0パケット（圧縮パケット）を送信する（S140）。UO-0パケットもRFC3095において規定されている。

【0092】

UE200は、UO-0パケットを受信すると、UE200の受信方向、つまり、DL方向においてROHCを適用しないようにAsymmetric ROHCを適用することを決定する（S150）。すなわち、UE200は、UL方向のみにROHCを適用する。

【0093】

UE200は、DL方向においてROHCを適用しないようにするため、当該UO-0パケットを受信できなかったことを示すNACK（STATIC-NACK）をeNB100Aに返送する（S160）。

【0094】

当該NACKを受信したeNB100Aは、UE200が圧縮パケットを処理できないと判定する。そこで、eNB100Aは、圧縮パケットではなく、フルヘッダを含むIRパケット（非圧縮パケット）を送信する（S170, S180）。

【0095】

なお、eNB100Aは、IRパケットによって非圧縮パケットを送信してもよいし、当該パケット（IPフローデータ）をUncompressed sessionにのみ割り当ててもよい。

【0096】

図９は、UE200の動作フロー図（動作例２）である。具体的には、図９は、図８に示したS140の処理以降におけるUE200内部の動作フローを示す。

【0097】

図９に示すように、UE200は、ROHCによるヘッダ圧縮が実行された圧縮パケット（UO-0パケット）を受信したか否かを判定する（S210）。

【0098】

UE200は、圧縮パケットを受信した場合、DL方向においてROHCを適用しないAsymmetric ROHCを適用するか否かを判定する（S220）。なお、S220の処理は、S210の処理よりも前に予め実行されても構わない。

【0099】

UE200は、Asymmetric ROHCを適用しない場合、圧縮パケットのヘッダを伸張（Decompress）する（S230）。

【0100】

UE200は、Asymmetric ROHCを適用する場合、当該UO-0パケットを受信できなかったことを示すNACK（STATIC-NACK）をeNB100Aに返送する（S240）。

【0101】

UE200がNACKをeNB100Aに返送すると、図８に示したように、eNB100Aは、圧縮パケットではなく、フルヘッダを含むIRパケット（非圧縮パケット）を送信する。UE200は、当該非圧縮パケットを受信する（S250）。

【0102】

その後、UE200は、パケットの受信処理を実行する（S260）。具体的には、UE200は、ヘッダの内容に基づいてPDU/SDUを再構成し、上位レイヤに出力する。

【0103】

なお、UE200は、動作例２の場合においても、上述したように、Asymmetric ROHCに関するUE200の能力情報をeNB100Aに通知してもよい。

【0104】

動作例２において、UE200がUE200の能力情報をeNB100Aに通知した場合、eNB100Aは、UE200に対して不要な圧縮パケットを送信することを回避できる。一方、Asymmetric ROHCをサポートしていないeNB100Bは、当該NACKが返送されることによって、UE200のメモリが不足していると認識するに過ぎない。

【0105】

（３．３）動作例３
動作例３では、上述したように、UE200は、Symmetric ROHC及びAsymmetric ROHCの両方の能力情報を送信する。以下、本動作例における基本動作フロー、Asymmetric ROHC適用の通知例及び変形例について説明する。

【0106】

（３．３．１）基本動作フロー
図１０は、UE200の動作フロー図（動作例３）である。図１０に示すように、UE200は、Capability field(ConventionalをeNB100A（またはeNB100B）に通知する（S310）。Capability field(Conventionalは、動作例１において説明した内容（図６参照）と同様であるが、さらに後述する。

【0107】

また、UE200は、Capability field(NewをeNB100A（またはeNB100B）に通知する（S320）。Capability field(Newも動作例１において説明した内容（図６参照）と同様であるが、さらに後述する。

【0108】

なお、S310とS320とは、入れ替えても構わない。このように、UE200は、Asymmetric ROHCをサポートしていることを示すサポート通知を受信したか否かに関わらず、Capability field(Conventional、つまり、Symmetric ROHCの内容を示すフィールドと、Capability field(New、つまり、Asymmetric ROHCの内容を示すフィールドとを含む能力情報をeNB100Aに通知する。

【0109】

図１１（ａ）及び（ｂ）は、eNB100A及びeNB100BにおけるAsymmetric ROHCの適用動作フロー図である。具体的には、図１１（ａ）は、eNB100BにおけるAsymmetric ROHCの適用動作フローを示す。図１１（ｂ）は、eNB100AにおけるAsymmetric ROHCの適用動作フローを示す。

【0110】

図１１（ａ）に示すように、eNB100Bは、Capability field(Conventional及びCapability field(Newを含む能力情報を受信する（S410）。

【0111】

Asymmetric ROHCをサポートしていないeNB100Bは、Capability field(Conventionalに基づいて、ROHCによるヘッダ圧縮の要否について判定する（S420）。ここでは、ヘッダ圧縮が必要、つまり、ROHCを適用すると判定されたものとする。

【0112】

eNB100Bは、当該判定結果に基づいて、圧縮パケットをUE200に送信する（S430）。

【0113】

一方、図１１（ｂ）に示すように、eNB100Aも、Capability field(Conventional及びCapability field(Newを含む能力情報を受信する（S510）。

【0114】

Asymmetric ROHCをサポートしているeNB100Aは、Capability field(ConventionalまたはCapability field(Newの何れかに基づいて、ROHCによるヘッダ圧縮の要否について判定する（S520）。ここでは、Capability field(Newに基づいてヘッダ圧縮が不要、つまり、ROHCを適用しないと判定されたものとする。

【0115】

eNB100Aは、当該判定結果に基づいて、非圧縮パケットをUE200に送信する（S530）。

【0116】

このように、eNB100B（Asymmetric ROHC非サポート）は、既存のCapability field(Conventionalの内容を参照し、Symmetric ROHCを適用する。一方、eNB100A（Asymmetric ROHCサポート）は、Symmetric ROHCまたはAsymmetric ROHCの何れかを適用する。

【0117】

なお、UE200（ヘッダ圧縮処理部230）は、搭載するメモリの規模（maxNumberROHC-ContextSessionsに応じたメモリ数）に基づいて、Symmetric ROHC及びAsymmetric ROHCのそれぞれについて、ROHC CapabilityをeNB100A（eNB100B）に通知する。仮に、Symmetric ROHCに割り当てるメモリ数が不足する場合には、Asymmetric ROHCのみについて、ROHC Capabilityを通知してもよい。或いは、UE200は、ROHCに適用できるメモリ数や処理能力が不足する場合、上述した動作例２、つまり、適宜NACKを返送することによって、メモリ状況に応じてAsymmetric ROHC（またはSymmetric ROHC）を適用するようにしてもよい。

【0118】

（３．３．２）Asymmetric ROHC適用の通知例
図１２（ａ）、（ｂ）及び（ｃ）は、UE-EUTRA-Capabilityに含まれるフィールド（Capability field）の構成例を示す。図１２（ａ）、（ｂ）及び（ｃ）に示すように、本動作例では、Capability field(Conventional及びCapability field(Newの両方を含むUE-EUTRA-Capabilityが通知される。

【0119】

図１２（ａ）は、Asymmetric ROHCの設定に必要な内容の全てをCapability field(Newを用いて通知する例を示す。図１２（ａ）に示すように、ULにおいてROHCが適用されること、Asymmetric ROHCのプロファイル（supportedROHC-Profiles）及びAsymmetric ROHCに用い得るセッション数（maxNumberROHC-ContextSessions）がCapability field(Newを用いて通知される。

【0120】

図１２（ｂ）及び（ｃ）は、Asymmetric ROHCに関する内容の一部をCapability field(Newを用いて通知する例を示す。

【0121】

具体的には、図１２（ｂ）に示すように、Asymmetric ROHCのプロファイル（supportedROHC-Profiles）が、Capability field(Conventionalを用いて通知され、Asymmetric ROHCに用い得るセッション数（maxNumberROHC-ContextSessions）が、Capability field(Newを用いて通知される。つまり、supportedROHC-Profilesについては、Symmetric ROHCのプロファイルを示すフィールドが共用される。

【0122】

図１２（ｃ）では、Asymmetric ROHCのプロファイル（supportedROHC-Profiles）及びAsymmetric ROHCに用い得るセッション数（maxNumberROHC-ContextSessions）が、Capability field(Conventionalを用いて通知される。つまり、supportedROHC-Profiles及びmaxNumberROHC-ContextSessionsについて、Symmetric ROHCの当該フィールドが共用される。

【0123】

この場合、Capability field(Newは、ULにおいてROHCが適用されることのみの通知（図１２（ｃ）のAsymROHC-UL）に用いられる。

【0124】

また、この場合、図１２（ｃ）に示す（Capability field(New下方の斜線部分参照）ように、既存領域の何倍（例えば、２倍）の領域（具体的には、セッション（メモリ）数）がAsymmetric ROHCとしてサポート可能などが、別途、3GPPの仕様で決定されてもよい。

【0125】

（３．３．３）変形例
次に、本動作例の変形例について説明する。Asymmetric ROHCの適用可否、及びROHC用のセッション数（メモリ数）は、ベアラ（DRB）毎に設定することが可能である。しかしながら、本動作例のように、Symmetric ROHC及びAsymmetric ROHCのROHC Capabilityが別個に通知される場合、例えば、特に、eNB100AとUE200との間に複数のDRBが設定されていると、eNB100Aは、Symmetric ROHC及びAsymmetric ROHCをどのように各DRBに設定するかを判定することができない。

【0126】

この結果、eNB100Aは、UE200の能力（搭載されているメモリ数）を最大限活用したROHCの利点（伝送効率化）を得ることが難しくなる。

【0127】

図１３（ａ）～（ｄ）は、Symmetric ROHC及びAsymmetric ROHCが混在し得る場合におけるROHCの設定例を示す。

【0128】

図１３（ａ）に示すように、ここでは、eNB100AとUE200との間に２本のDRB（#1, #2）が設定されている。また、UE200は、#1～5までの５つのROHC用のメモリを搭載しているものとする。

【0129】

この場合、DRB毎のSymmetric ROHC及びAsymmetric ROHCの設定例としては、例えば、図１３（ｂ）～（ｄ）に示すようなパタンが挙げられる。図１３（ｂ）では、１セッション分のSymmetric ROHCが各DRBに設定される。この結果、UE200の４メモリ（(UL用1+DL用1)×2）を消費する。

【0130】

図１３（ｃ）では、３セッション分のAsymmetric ROHCがDRB#1に設定され、２セッション分のAsymmetric ROHCがDRB#2に設定される。この結果、UE200の５メモリ（UL用3+UL用2）を消費する。

【0131】

図１３（ｄ）では、１セッション分のSymmetric ROHCがDRB#1に設定され、３セッション分のAsymmetric ROHCがDRB#2に設定される。この結果、UE200の５メモリ（UL用1+DL用1)+UL用3）を消費する。

【0132】

このように、複数のDRBが設定され、Symmetric ROHC及びAsymmetric ROHCが混在し得る場合、様々な割り当てパタンが存在する。そこで、eNB100Aは、UE200内部において対応可能なメモリの割り当てパタンを予め認識しておき、当該割り当てパタンに基づいて、Symmetric ROHC及びAsymmetric ROHCを設定してもよい。

【0133】

この場合、UE200は、対応可能なメモリの割り当てパタンを指定し、指定した割り当てパタンをeNB100Aに予め通知する。図１４は、Symmetric ROHC及びAsymmetric ROHCが混在する場合において、UE200が指定する割り当てパタン例を示す。

【0134】

図１４に示すように、UE200が搭載するメモリ数（ここでは、５メモリ）に応じて、対応可能な割り当てパタンが指定される。なお、割り当てパタンは、設定されるDRB数を考慮して決定されてもよい。

【0135】

また、当該割り当てパタンは、各パタンの優先度を含んでもよい。当該優先度は、通信実行中（具体的には、RRC-CONNECTED状態）に変更されてもよい。さらに、通信実行中に当該優先度が変更された場合、UE200は、当該優先度を変更したことを、RRC/PDCP/RLC/MACレイヤの何れかのメッセージによって通知すればよい。

【0136】

eNB100Aは、通知された内容に基づいて、UE200の能力（メモリ数）を超過しないように、Symmetric ROHC及びAsymmetric ROHCの少なくとも何れかを設定する。また、eNB100Aは、通知された内容に基づいて、割り当てパタンの内容（優先度）を更新してもよい。

【0137】

図１５（ａ）、（ｂ）及び（ｃ）は、Symmetric ROHC及びAsymmetric ROHCが混在する場合における割り当てパタンの通知例を示す。

【0138】

図１５（ａ）に示すように、Symmetric ROHC及びAsymmetric ROHCが混在する場合、Symmetric ROHCのROHC Capabilityと、Asymmetric ROHCのROHC Capabilityとによって構成される複数のリスト（図１５（ａ）の外枠は、各リストを示す）によって、割り当てパタンを通知してもよい。

【0139】

或いは、図１５（ｂ）に示すように、UE200が割り当て可能な最大のメモリ数、つまり、maxNumberROHC-ContextSessionsと、Symmetric ROHCまたはAsymmetric ROHCの何れかのROHC Capabilityとを含む割り当てパタンを通知してもよい。この場合、通知されないROHCの割り当て（図１５（ｂ）では、Symmetric ROHC）については、最大のメモリ数（１５）とAsymmetric ROHCの割り当て数とによって暗黙的に示すことが可能である。

【0140】

さらに、図１５（ｃ）に示すように、3GPPの仕様において割り当てパタンが規定されており、当該割り当てパタンを識別するインデックスのみを通知してもよい。或いは、各インデックスについて、True（対応可）またはFalse（対応不可）を示してもよい。

【0141】

（４）作用・効果
上述した実施形態によれば、以下の作用効果が得られる。具体的には、上述した動作例１によれば、eNBからAsymmetric ROHCのサポート通知を受信した場合、UE200は、Asymmetric ROHCのプロファイルをUE200の能力情報（UE-EUTRA-Capability）に含めることによって、Asymmetric ROHCの設定に用いる情報をeNB100Aに通知する。一方、Asymmetric ROHCをサポートしていないeNB100Bに対しては、Asymmetric ROHCのプロファイルは通知されない。このため、eNB100Bは、ROHCをサポートしていないUEとしてUE200を取り扱い、DL方向において、ROHCによるヘッダ圧縮を実行しない。

【0142】

また、動作例１によれば、UE200は、Symmetric ROHCの内容を示すフィールドと、Symmetric ROHCの内容を示すフィールドとは別個であるAsymmetric ROHCの内容を示すフィールドとを含む能力情報をeNB100A（eNB100B）に通知することができる。さらに、動作例１によれば、UE200は、Symmetric ROHCの内容を示すフィールドに、Asymmetric ROHCをサポートすることを示す情報を含めた能力情報をeNB100A（eNB100B）に通知することもできる。

【0143】

このため、eNB100B（Asymmetric ROHC非サポート）によるROHC設定に悪影響を与えることなく、Asymmetric ROHCの設定に必要な情報をeNB100A（Asymmetric ROHCサポート）に通知できる。これにより、eNB100B（Asymmetric ROHC非サポート）とのバックワードコンパチビリティーを確保しつつ、Asymmetric ROHCを導入できる。

【0144】

上述した動作例２によれば、UE200は、非圧縮パケットに続けて、ROHCによる圧縮パケットを受信した場合、当該圧縮パケットを受信できなかったことを示すNACK（否定応答）をeNB100Aに送信する。このため、eNB100Aによる圧縮パケットの送信が中止され、非圧縮パケットが送信される。これにより、UE200の受信方向（つまり、DL方向）においてROHCを適用しないAsymmetric ROHCを設定することができる。

【0145】

一方、Asymmetric ROHCをサポートしていないeNB100Bは、当該NACKが返送されることによって、UE200のメモリが不足していると認識するに過ぎない。この結果、eNB100Bとのパケット送受信では、ROHCが適用されない。

【0146】

これにより、eNB100B（Asymmetric ROHC非サポート）とのバックワードコンパチビリティーを確保しつつ、Asymmetric ROHCを導入できる。

【0147】

また、動作例２では、動作例１と同様に、UE200がUE200の能力情報をeNB100Aに通知してもよい。この場合、eNB100Aは、UE200に対して不要な圧縮パケットを送信することを回避できる。

【0148】

上述した動作例３によれば、UE200は、Symmetric ROHCの内容を示すフィールドと、Symmetric ROHCの内容を示すフィールドとは別個であるAsymmetric ROHCの内容を示すフィールドとを含む能力情報をeNB100Aに通知する。このため、UE200は、eNB100A（Asymmetric ROHCサポート）及びeNB100B（Asymmetric ROHC非サポート）の両方が認識可能なROHC Capabilityを通知することができる。これにより、eNB100B（Asymmetric ROHC非サポート）とのバックワードコンパチビリティーを確保しつつ、Asymmetric ROHCを導入できる。

【0149】

また、動作例３では、少なくともAsymmetric ROHCのプロファイルについて、Symmetric ROHCのプロファイルを示すフィールドを共用することができる。このため、Asymmetric ROHCの設定に必要な情報量を抑制しつつ、Asymmetric ROHCを導入できる。

【0150】

すなわち、上述した実施形態によれば、Asymmetric ROHCをサポートするeNB100Aと、既存のSymmetric ROHCのみをサポートするeNB100Bとが混在する場合でも、適切にAsymmetric ROHCを設定することができる。

【0151】

さらに、Asymmetric ROHCの設定に必要な情報をeNB100Aに通知することによって、UE200が搭載するROHC用メモリを最大限に活用したAsymmetric ROHCによるヘッダ圧縮を実現し得る。

【0152】

（５）その他の実施形態
以上、実施形態に沿って本発明の内容を説明したが、本発明はこれらの記載に限定されるものではなく、種々の変形及び改良が可能であることは、当業者には自明である。

【0153】

例えば、上述したAsymmetric ROHCに関するROHC Capabilityは、TCP ACK less機能のCapabilityとして流用されてもよい。TCP ACK less機能とは、TCPレイヤにおける肯定応答（TCP ACK）送信に必要となる無線帯域削減を図るものである。

【0154】

具体的には、パケットの受信側は、TCP ACKを送信せずに破棄する。パケットの送信側は、PDCP SDU（IPパケット）に対するレイヤ２でのACK（例えば、RLC-ACK）を受信した場合、TCP ACKを自身で生成して上位レイヤへ送信する。

【0155】

つまり、TCPによるトラフィックフローを用いて、DLにおけるピークスループットを達成するためには、TCP ACK送信のためのUL帯域をも確保する必要が生じるが、TDDシステムでは、DL/ULの無線リソースの非対称性（DL帯域がUL帯域よりも広帯域）に起因する制限が生じ得る。

【0156】

この問題を解決するためTCP ACK less機能が提案されている。Asymmetric ROHC及びTCP ACK less機能のCapabilityを合わせて適用することによって、DL/ULへの無線リソース配分を、さらにDL優先とすることが可能となり、Asymmetric ROHC及びTCP ACK less機能の組み合わせは、DL/UL帯域のさらに効率的な利用の観点からも非常に効果的である。

【0157】

また、TCP ACK less機能は、PDCP SDUの内容を意識する必要があるが、ROHCでは既にPDCP SDUの内容を把握する機構が存在しているため、TCP-ACK less機能と共通化できる部分もあり、UE200及びeNB100Aの実装の観点からもメリットがある。

【0158】

また、上述した実施形態では、ヘッダ圧縮のプロトコルとしてROHCが用いられていたが、必ずしもROHCに限定されるものではない。つまり、ROHCと同様のヘッダ圧縮機能を有するプロトコルであれば、ROHC以外でも構わない。

【0159】

上述した実施形態では、DL方向においてROHCが適用されず、UL方向のみにROHCが適用される例について説明したが、UE200が送受信するデータの特性などによっては、UL方向においてROHCが適用されず、DL方向のみにROHCが適用されてもよい。

【0160】

さらに、上述した実施形態では、UE200がAsymmetric ROHCに関する能力をeNB100A（eNB100B）に通知していたが、eNB100A（eNB100B）が、同様の機能を備えてもよい。つまり、eNB100A（eNB100B）が、Asymmetric ROHCに関する能力をUE200に通知し、UE200が、通知された能力に基づいてAsymmetric ROHCを設定してもよい。

【0161】

また、上述した実施形態の説明に用いたブロック図（図２，３）は、機能ブロック図を示している。これらの機能ブロック（構成部）は、ハードウェア及び／またはソフトウェアの任意の組み合わせによって実現される。また、各機能ブロックの実現手段は特に限定されない。すなわち、各機能ブロックは、物理的及び／または論理的に結合した１つの装置により実現されてもよいし、物理的及び／または論理的に分離した２つ以上の装置を直接的及び／または間接的に（例えば、有線及び／または無線）で接続し、これら複数の装置により実現されてもよい。

【0162】

さらに、上述したeNB100A, 100B、及びUE200（当該装置）は、本発明の送信電力制御の処理を行うコンピュータとして機能してもよい。図１６は、当該装置のハードウェア構成の一例を示す図である。図１６に示すように、当該装置は、プロセッサ1001、メモリ1002、ストレージ1003、通信装置1004、入力装置1005、出力装置1006及びバス1007などを含むコンピュータ装置として構成されてもよい。

【0163】

当該装置の各機能ブロック（図２，３参照）は、当該コンピュータ装置の何れかのハードウェア要素、または当該ハードウェア要素の組み合わせによって実現される。

【0164】

プロセッサ1001は、例えば、オペレーティングシステムを動作させてコンピュータ全体を制御する。プロセッサ1001は、周辺装置とのインタフェース、制御装置、演算装置、レジスタなどを含む中央処理装置（CPU）で構成されてもよい。

【0165】

メモリ1002は、コンピュータ読み取り可能な記録媒体であり、例えば、ROM（Read Only Memory）、EPROM（Erasable Programmable ROM）、EEPROM（Electrically Erasable Programmable ROM）、RAM（Random Access Memory）などの少なくとも１つで構成されてもよい。メモリ1002は、レジスタ、キャッシュ、メインメモリ（主記憶装置）などと呼ばれてもよい。メモリ1002は、上述した実施形態に係る方法を実行可能なプログラム（プログラムコード）、ソフトウェアモジュールなどを保存することができる。

【0166】

ストレージ1003は、コンピュータ読み取り可能な記録媒体であり、例えば、CD-ROM（Compact Disc ROM）などの光ディスク、ハードディスクドライブ、フレキシブルディスク、光磁気ディスク（例えば、コンパクトディスク、デジタル多用途ディスク、Blu-ray（登録商標）ディスク）、スマートカード、フラッシュメモリ（例えば、カード、スティック、キードライブ）、フロッピー（登録商標）ディスク、磁気ストリップなどの少なくとも１つで構成されてもよい。ストレージ1003は、補助記憶装置と呼ばれてもよい。上述の記録媒体は、例えば、メモリ1002及び／またはストレージ1003を含むデータベース、サーバその他の適切な媒体であってもよい。

【0167】

通信装置1004は、有線及び／または無線ネットワークを介してコンピュータ間の通信を行うためのハードウェア（送受信デバイス）であり、例えばネットワークデバイス、ネットワークコントローラ、ネットワークカード、通信モジュールなどともいう。

【0168】

入力装置1005は、外部からの入力を受け付ける入力デバイス（例えば、キーボード、マウス、マイクロフォン、スイッチ、ボタン、センサなど）である。出力装置1006は、外部への出力を実施する出力デバイス（例えば、ディスプレイ、スピーカー、LEDランプなど）である。なお、入力装置1005及び出力装置1006は、一体となった構成（例えば、タッチパネル）であってもよい。

【0169】

また、プロセッサ1001及びメモリ1002などの各装置は、情報を通信するためのバス1007で接続される。バス1007は、単一のバスで構成されてもよいし、装置間で異なるバスで構成されてもよい。

【0170】

また、情報の通知は、上述した実施形態に限られず、他の方法で行われてもよい。例えば、情報の通知は、物理レイヤシグナリング（例えば、DCI（Downlink Control Information）、UCI（Uplink Control Information））、上位レイヤシグナリング（例えば、RRCシグナリング、MAC（Medium Access Control）シグナリング、報知情報（MIB（Master Information Block）、SIB（System Information Block））、その他の信号またはこれらの組み合わせによって実施されてもよい。また、RRCシグナリングは、RRCメッセージと呼ばれてもよく、例えば、RRC Connection Setupメッセージ、RRC Connection Reconfigurationメッセージなどであってもよい。

【0171】

さらに、入出力された情報は、特定の場所（例えば、メモリ）に保存されてもよいし、管理テーブルで管理してもよい。入出力される情報は、上書き、更新、または追記され得る。出力された情報は削除されてもよい。入力された情報は他の装置へ送信されてもよい。

【0172】

上述した実施形態におけるシーケンス及びフローチャートなどは、矛盾の無い限り、順序を入れ替えてもよい。

【0173】

また、上述した実施形態において、eNB100A（eNB100B、以下同）によって行われるとした特定動作は、他のネットワークノード（装置）によって行われることもある。また、複数の他のネットワークノードの組み合わせによってeNB100Aの機能が提供されても構わない。

【0174】

なお、本明細書で説明した用語及び／または本明細書の理解に必要な用語については、同一のまたは類似する意味を有する用語と置き換えてもよい。例えば、該当する記載がある場合、チャネル及び／またはシンボルは信号（シグナル）であってもよい。また、信号はメッセージであってもよい。また、「システム」及び「ネットワーク」という用語は、互換的に使用されてもよい。

【0175】

さらに、パラメータなどは、絶対値で表されてもよいし、所定の値からの相対値で表されてもよいし、対応する別の情報で表されてもよい。例えば、無線リソースはインデックスで指示されるものであってもよい。

【0176】

eNB100A（基地局）は、１つまたは複数（例えば、３つ）のセル（セクタとも呼ばれる）を収容することができる。基地局が複数のセルを収容する場合、基地局のカバレッジエリア全体は複数のより小さいエリアに区分でき、各々のより小さいエリアは、基地局サブシステム（例えば、屋内用の小型基地局RRH：Remote Radio Head）によって通信サービスを提供することもできる。

【0177】

「セル」または「セクタ」という用語は、このカバレッジにおいて通信サービスを行う基地局、及び／または基地局サブシステムのカバレッジエリアの一部または全体を指す。さらに、「基地局」「eNB」、「セル」、及び「セクタ」という用語は、本明細書では互換的に使用され得る。基地局は、固定局（fixed station）、NodeB、eNodeB（eNB）、アクセスポイント（access point）、フェムトセル、スモールセルなどの用語で呼ばれる場合もある。

【0178】

UE200は、当業者によって、加入者局、モバイルユニット、加入者ユニット、ワイヤレスユニット、リモートユニット、モバイルデバイス、ワイヤレスデバイス、ワイヤレス通信デバイス、リモートデバイス、モバイル加入者局、アクセス端末、モバイル端末、ワイヤレス端末、リモート端末、ハンドセット、ユーザエージェント、モバイルクライアント、クライアント、またはいくつかの他の適切な用語で呼ばれる場合もある。

【0179】

本明細書で使用する「に基づいて」という記載は、別段に明記されていない限り、「のみに基づいて」を意味しない。言い換えれば、「に基づいて」という記載は、「のみに基づいて」と「に少なくとも基づいて」の両方を意味する。

【0180】

また、「含む（including）」、「含んでいる（comprising）」、及びそれらの変形の用語は、「備える」と同様に、包括的であることが意図される。さらに、本明細書或いは特許請求の範囲において使用されている用語「または（or）」は、排他的論理和ではないことが意図される。

【0181】

本明細書で使用した「第１」、「第２」などの呼称を使用した要素へのいかなる参照も、それらの要素の量または順序を全般的に限定するものではない。これらの呼称は、２つ以上の要素間を区別する便利な方法として本明細書で使用され得る。したがって、第１及び第２の要素への参照は、２つの要素のみがそこで採用され得ること、または何らかの形で第１の要素が第２の要素に先行しなければならないことを意味しない。

【0182】

本明細書の全体において、例えば、英語でのa, an, 及びtheのように、翻訳により冠詞が追加された場合、これらの冠詞は、文脈から明らかにそうではないことが示されていなければ、複数のものを含むものとする。

【0183】

上記のように、本発明の実施形態を記載したが、この開示の一部をなす論述及び図面はこの発明を限定するものであると理解すべきではない。この開示から当業者には様々な代替実施の形態、実施例及び運用技術が明らかとなろう。

【産業上の利用可能性】

【0184】

上述したように、本発明によれば、上りリンクまたは下りリンクの何れか一方にROHCによるヘッダ圧縮が適用される非対称ヘッダ圧縮をサポートする無線基地局と、既存の対称ヘッダ圧縮のみをサポートする無線基地局とが混在する場合でも、適切に非対称ヘッダ圧縮を設定することができる。

【符号の説明】

【0185】

10 無線通信システム
20 無線アクセスネットワーク
31, 32 DRB
100A, 100B eNB
110 無線通信部
120 データ送受信部
130 ヘッダ圧縮処理部
140 UE能力取得部
200 UE
210 無線通信部
220 データ送受信部
230 ヘッダ圧縮処理部
240 能力通知部
250 ACK/NACK処理部
1001 プロセッサ
1002 メモリ
1003 ストレージ
1004 通信装置
1005 入力装置
1006 出力装置
1007 バス

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】