JPWO2016186016A1 - 無線端末及び基地局 - Google Patents

Abstract

一つの実施形態に係る無線端末は、ＤＲＸサイクルごとに発生するオン期間内でＰＤＣＣＨを監視する制御部と、前記オン期間内で、前記ＰＤＣＣＨを介して、スケジューリング情報を含まない特殊な下りリンク制御情報を基地局から受信する受信部とを備える。前記制御部は、前記特殊な下りリンク制御情報の受信に応じて、ＤＲＸ休止期間にわたって前記ＰＤＣＣＨの監視を継続する。

Description

本発明は、移動通信システムにおいて用いられる無線端末及び基地局に関する。

移動通信システムの標準化プロジェクトである３ＧＰＰ（Ｔｈｉｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）において、無線通信におけるレイテンシを低減するレイテンシ低減機能の導入が検討されている。このようなレイテンシ低減機能を実現するための技術として、高速上りリンクアクセス技術及びＴＴＩ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｔｉｍｅ Ｉｎｔｅｒｖａｌ）短縮技術等が挙げられる。

一つの実施形態に係る無線端末は、ＤＲＸサイクルごとに発生するオン期間内でＰＤＣＣＨを監視する制御部と、前記オン期間内で、前記ＰＤＣＣＨを介して、スケジューリング情報を含まない特殊な下りリンク制御情報を基地局から受信する受信部とを備える。前記制御部は、前記特殊な下りリンク制御情報の受信に応じて、ＤＲＸ休止期間にわたって前記ＰＤＣＣＨの監視を継続する。

一つの実施形態に係る基地局は、ＤＲＸサイクルごとに発生するオン期間内でＰＤＣＣＨを監視する無線端末との通信を行う制御部を備える。前記制御部は、前記オン期間内で、前記ＰＤＣＣＨを介して、スケジューリング情報を含まない特殊な下りリンク制御情報を前記無線端末に送信する処理を行う。前記特殊な下りリンク制御情報は、前記ＰＤＣＣＨの監視をＤＲＸ休止期間にわたって前記無線端末に継続させるために用いられる。

一つの実施形態に係る無線端末は、ＤＲＸサイクルごとに発生するオン期間内でＰＤＣＣＨを監視する制御部と、上りリンクデータを基地局に送信する際に、下りリンクデータの受信が予想されることを示す通知を前記基地局に送信する送信部とを備える。前記制御部は、前記通知を送信してから所定の期間において、前記オン期間外であっても前記ＰＤＣＣＨを監視する。

一つの実施形態に係る基地局は、ＤＲＸサイクルごとに発生するオン期間内でＰＤＣＣＨを監視する無線端末との通信を行う制御部と、上りリンクデータを前記無線端末から受信する際に、下りリンクデータの受信が予想されることを示す通知を前記無線端末から受信する受信部とを備える。前記制御部は、前記通知を受信してから所定の期間において、前記オン期間外であっても、前記ＰＤＣＣＨを介して下りリンク制御情報を前記無線端末に送信する処理を行う。

一つの実施形態に係る無線端末は、ＤＲＸサイクルごとに発生するオン期間内でＰＤＣＣＨを監視する制御部を備える。前記制御部は、上りリンクデータを基地局に送信した後、前記上りリンクデータに対応するＡＣＫ／ＮＡＣＫを前記基地局から受信するためにＰＨＩＣＨを監視する。前記制御部は、前記オン期間外であっても、前記ＰＨＩＣＨを監視する際に前記ＰＤＣＣＨも監視する。

一つの実施形態に係る基地局は、ＤＲＸサイクルごとに発生するオン期間内でＰＤＣＣＨを監視する無線端末との通信を行う制御部を備える。前記制御部は、上りリンクデータを前記無線端末から受信した後、ＰＨＩＣＨを介して前記上りリンクデータに対応するＡＣＫ／ＮＡＣＫを前記無線端末に送信する処理を行う。前記制御部は、前記オン期間外であっても、前記ＡＣＫ／ＮＡＣＫを送信する際に、前記ＰＤＣＣＨを介して下りリンク制御情報を前記無線端末に送信する。

ＬＴＥシステム（移動通信システム）を示す図である。 ＵＥ（無線端末）のブロック図である。 ｅＮＢ（基地局）のブロック図である。 ＬＴＥシステムにおける無線インターフェイスのプロトコルスタック図である。 ＬＴＥシステムにおいて用いられる無線フレームの構成図である。 ＲＲＣコネクティッドモードのＤＲＸ状態にあるＵＥの動作を示す図である。 ＴＣＰの概要を説明するための図である。 ＬＴＥシステムにおける通信シーケンスの一例を説明するための図である。 第１実施形態に係る動作シーケンスの一例を示す図である。 第２実施形態に係る動作シーケンスの一例を示す図である。 第３実施形態に係る動作シーケンスの一例を示す図である。 第１実施形態乃至第３実施形態の変更例に係る動作を示す図である。 モバイルトラフィックボリュームによる上位５つのアプリケーションを示す図及びモバイルアプリケーション分析を示す図である。 ＨＴＴＰ／ＦＴＰを用いた典型的な使用の場合のモデル化を示す図である。 付記に係る起こり得る問題を示す図である。

［実施形態の概要］
無線端末は、消費電力を削減するために、ＤＲＸ（Ｄｉｓｃｏｎｔｉｎｕｏｕｓ ｒｅｃｅｐｔｉｏｎ）動作を行う。具体的には、無線端末は、ＤＲＸサイクルごとに発生するオン期間（Ｏｎ ｄｕｒａｔｉｏｎ）内でＰＤＣＣＨを監視する。基地局は、無線端末におけるオン期間を把握しており、オン期間内でＰＤＣＣＨを介して下りリンク制御情報（ＤＣＩ）を無線端末に送信する。ＤＣＩは、無線端末への割当リソースを示すスケジューリング情報を含む。

基地局は、コアネットワークからデータを受信した後、無線端末がオン期間になるまで、当該無線端末に対するデータ送信を待たなければならない。以下において、基地局がコアネットワークからデータを受信してから当該データを無線端末に送信するまでの時間を「下りリンクの転送遅延（ＤＬ ｔｒａｎｓｆｅｒ ｄｅｌａｙ）」と称する。特に、ＤＲＸサイクルが長い場合には、下りリンクの転送遅延が深刻な問題になり得る。

以下の実施形態において、下りリンクの転送遅延を短縮可能とする技術が開示される。

［移動通信システム］
以下において、実施形態に係る移動通信システムであるＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）システムの概要について説明する。

（移動通信システムの構成）
図１は、ＬＴＥシステムの構成を示す図である。図１に示すように、ＬＴＥシステムは、ＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）１００、Ｅ−ＵＴＲＡＮ（Ｅｖｏｌｖｅｄ−ＵＭＴＳ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）１０、及びＥＰＣ（Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｃｏｒｅ）２０を備える。

ＵＥ１００は、無線端末に相当する。ＵＥ１００は、移動型の通信装置であり、セル（サービングセル）との無線通信を行う。

Ｅ−ＵＴＲＡＮ１０は、無線アクセスネットワークに相当する。Ｅ−ＵＴＲＡＮ１０は、ｅＮＢ２００（ｅｖｏｌｖｅｄ Ｎｏｄｅ−Ｂ）を含む。ｅＮＢ２００は、基地局に相当する。ｅＮＢ２００は、Ｘ２インターフェイスを介して相互に接続される。

ｅＮＢ２００は、１又は複数のセルを管理しており、自セルとの接続を確立したＵＥ１００との無線通信を行う。ｅＮＢ２００は、無線リソース管理（ＲＲＭ）機能、ユーザデータ（以下、単に「データ」という）のルーティング機能、モビリティ制御・スケジューリングのための測定制御機能等を有する。「セル」は、無線通信エリアの最小単位を示す用語として用いられる他に、ＵＥ１００との無線通信を行う機能を示す用語としても用いられる。

ＥＰＣ２０は、コアネットワークに相当する。ＥＰＣ２０は、ＭＭＥ（Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ）／Ｓ−ＧＷ（Ｓｅｒｖｉｎｇ−Ｇａｔｅｗａｙ）３００を含む。ＭＭＥは、ＵＥ１００に対する各種モビリティ制御等を行う。Ｓ−ＧＷは、データの転送制御を行う。ＭＭＥ／Ｓ−ＧＷ３００は、Ｓ１インターフェイスを介してｅＮＢ２００と接続される。Ｅ−ＵＴＲＡＮ１０及びＥＰＣ２０は、ネットワークを構成する。

（無線端末の構成）
図２は、ＵＥ１００（無線端末）のブロック図である。図２に示すように、ＵＥ１００は、受信部１１０、送信部１２０、及び制御部１３０を備える。

受信部１１０は、制御部１３０の制御下で各種の受信を行う。受信部１１０は、アンテナ及び受信機を含む。受信機は、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換して制御部１３０に出力する。

送信部１２０は、制御部１３０の制御下で各種の送信を行う。送信部１２０は、アンテナ及び送信機を含む。送信機は、制御部１３０が出力するベースバンド信号（送信信号）を無線信号に変換してアンテナから送信する。

制御部１３０は、ＵＥ１００における各種の制御を行う。制御部１３０は、プロセッサ及びメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行うベースバンドプロセッサと、メモリに記憶されるプログラムを実行して各種の処理を行うＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）と、を含む。プロセッサは、音声・映像信号の符号化・復号を行うコーデックを含んでもよい。プロセッサは、上述した処理及び後述する処理を実行する。

（基地局の構成）
図３は、ｅＮＢ２００（基地局）のブロック図である。図３に示すように、ｅＮＢ２００は、送信部２１０、受信部２２０、制御部２３０、及びバックホール通信部２４０を備える。

送信部２１０は、制御部２３０の制御下で各種の送信を行う。送信部２１０は、アンテナ及び送信機を含む。送信機は、制御部２３０が出力するベースバンド信号（送信信号）を無線信号に変換してアンテナから送信する。

受信部２２０は、制御部２３０の制御下で各種の受信を行う。受信部２２０は、アンテナ及び受信機を含む。受信機は、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換して制御部２３０に出力する。

制御部２３０は、ｅＮＢ２００における各種の制御を行う。制御部２３０は、プロセッサ及びメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行うベースバンドプロセッサと、メモリに記憶されるプログラムを実行して各種の処理を行うＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）と、を含む。プロセッサは、上述した処理及び後述する処理を実行する。

バックホール通信部２４０は、Ｘ２インターフェイスを介して隣接ｅＮＢ２００と接続され、Ｓ１インターフェイスを介してＭＭＥ／Ｓ−ＧＷ３００と接続される。バックホール通信部２４０は、Ｘ２インターフェイス上で行う通信及びＳ１インターフェイス上で行う通信等に用いられる。

（無線インターフェイスの構成）
図４は、ＬＴＥシステムにおける無線インターフェイスのプロトコルスタック図である。図４に示すように、無線インターフェイスプロトコルは、ＯＳＩ参照モデルの第１層乃至第３層に区分されており、第１層は物理（ＰＨＹ）層である。第２層は、ＭＡＣ（Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）層、ＲＬＣ（Ｒａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌ）層、及びＰＤＣＰ（Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ）層を含む。第３層は、ＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）層を含む。

物理層は、符号化・復号、変調・復調、アンテナマッピング・デマッピング、及びリソースマッピング・デマッピングを行う。ＵＥ１００の物理層とｅＮＢ２００の物理層との間では、物理チャネルを介してデータ及び制御情報が伝送される。

ＭＡＣ層は、データの優先制御、ハイブリッドＡＲＱ（ＨＡＲＱ）による再送処理、及びランダムアクセス手順等を行う。ＵＥ１００のＭＡＣ層とｅＮＢ２００のＭＡＣ層との間では、トランスポートチャネルを介してデータ及び制御情報が伝送される。ｅＮＢ２００のＭＡＣ層は、上下リンクのトランスポートフォーマット（トランスポートブロックサイズ、変調・符号化方式（ＭＣＳ））及びＵＥ１００への割当リソースブロックを決定するスケジューラを含む。

ＲＬＣ層は、ＭＡＣ層及び物理層の機能を利用してデータを受信側のＲＬＣ層に伝送する。ＵＥ１００のＲＬＣ層とｅＮＢ２００のＲＬＣ層との間では、論理チャネルを介してデータ及び制御情報が伝送される。

ＰＤＣＰ層は、ヘッダ圧縮・伸張、及び暗号化・復号化を行う。

ＲＲＣ層は、制御情報を取り扱う制御プレーンでのみ定義される。ＵＥ１００のＲＲＣ層とｅＮＢ２００のＲＲＣ層との間では、各種設定のためのメッセージ（ＲＲＣメッセージ）が伝送される。ＲＲＣ層は、無線ベアラの確立、再確立及び解放に応じて、論理チャネル、トランスポートチャネル、及び物理チャネルを制御する。ＵＥ１００のＲＲＣとｅＮＢ２００のＲＲＣとの間に接続（ＲＲＣ接続）がある場合、ＵＥ１００はＲＲＣコネクティッドモードであり、そうでない場合、ＵＥ１００はＲＲＣアイドルモードである。

ＲＲＣ層の上位に位置するＮＡＳ（Ｎｏｎ−Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ）層は、セッション管理及びモビリティ管理等を行う。

ＵＥ１００は、無線インターフェイスプロトコルの上位のプロトコルとしてＯＳＩ参照モデルの第４層乃至第７層を有する。第４層であるトランスポート層は、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）を含む。ＴＣＰについては後述する。

（ＬＴＥ下位層の概要）
図５は、ＬＴＥシステムにおいて用いられる無線フレームの構成図である。ＬＴＥシステムは、下りリンクにはＯＦＤＭＡ（Ｏｒｔｈｏｇｏｎａｌ Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）、上りリンクにはＳＣ−ＦＤＭＡ（Ｓｉｎｇｌｅ Ｃａｒｒｉｅｒ Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）がそれぞれ適用される。

図５に示すように、無線フレームは、時間方向に並ぶ１０個のサブフレームで構成される。各サブフレームは、時間方向に並ぶ２個のスロットで構成される。各サブフレームの長さは１ｍｓであり、各スロットの長さは０．５ｍｓである。各サブフレームは、周波数方向に複数個のリソースブロック（ＲＢ）を含み、時間方向に複数個のシンボルを含む。各リソースブロックは、周波数方向に複数個のサブキャリアを含む。１つのシンボル及び１つのサブキャリアにより１つのリソースエレメント（ＲＥ）が構成される。また、ＵＥ１００に割り当てられる無線リソース（時間・周波数リソース）のうち、周波数リソースはリソースブロックにより特定でき、時間リソースはサブフレーム（又はスロット）により特定できる。

下りリンクにおいて、各サブフレームの先頭数シンボルの区間は、主に下りリンク制御情報を伝送するための物理下りリンク制御チャネル（ＰＤＣＣＨ）、及び、ＨＡＲＱ ＡＣＫ／ＮＡＣＫ情報を伝送するための物理ＨＡＲＱインジケータチャネル（ＰＨＩＣＨ）として用いられる領域である。また、各サブフレームの残りの部分は、主に下りリンクデータを伝送するための物理下りリンク共有チャネル（ＰＤＳＣＨ）として用いることができる領域である。

ｅＮＢ２００は、基本的には、ＰＤＣＣＨを用いて下りリンク制御情報（ＤＣＩ）をＵＥ１００に送信し、ＰＤＳＣＨを用いて下りリンクデータをＵＥ１００に送信する。ＰＤＣＣＨが搬送する下りリンク制御情報は、上りリンクスケジューリング情報、下りリンクスケジューリング情報、ＴＰＣコマンドを含む。上りリンクスケジューリング情報は上りリンク無線リソースの割当てに関するスケジューリング情報（ＵＬ ｇｒａｎｔ）であり、下りリンクスケジューリング情報は、下りリンク無線リソースの割当てに関するスケジューリング情報である。ＴＰＣコマンドは、上りリンクの送信電力の増減を指示する情報である。ｅＮＢ２００は、下りリンク制御情報の送信先のＵＥ１００を識別するために、送信先のＵＥ１００の識別子（ＲＮＴＩ：Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｔｅｍｐｏｒａｒｙ ＩＤ）でスクランブリングしたＣＲＣビットを下りリンク制御情報に含める。各ＵＥ１００は、自ＵＥ宛ての可能性がある下りリンク制御情報について、自ＵＥのＲＮＴＩでＣＲＣビットをデスクランブリングすることにより、ＰＤＣＣＨをブラインド復号（Ｂｌｉｎｄ ｄｅｃｏｄｉｎｇ）し、自ＵＥ宛の下りリンク制御情報を検出する。ＰＤＳＣＨは、下りリンクスケジューリング情報が示す下りリンク無線リソース（リソースブロック）により下りリンクデータを搬送する。

上りリンクにおいて、各サブフレームにおける周波数方向の両端部は、主に上りリンク制御情報を伝送するための物理上りリンク制御チャネル（ＰＵＣＣＨ）として用いられる領域である。各サブフレームにおける残りの部分は、主に上りリンクデータを伝送するための物理上りリンク共有チャネル（ＰＵＳＣＨ）として用いることができる領域である。

ＵＥ１００は、基本的には、ＰＵＣＣＨを用いて上りリンク制御情報（ＵＣＩ）をｅＮＢ２００に送信し、ＰＵＳＣＨを用いて上りリンクデータをｅＮＢ２００に送信する。ＰＵＣＣＨが運搬する上りリンク制御情報は、ＣＱＩ（Ｃｈａｎｎｅｌ Ｑｕａｌｉｔｙ Ｉｎｄｉｃａｔｏｒ）、ＰＭＩ（Ｐｒｅｃｏｄｉｎｇ Ｍａｔｒｉｘ Ｉｎｄｉｃａｔｏｒ）、ＲＩ（Ｒａｎｋ Ｉｎｄｉｃａｔｏｒ）、スケジューリング要求（ＳＲ）、ＨＡＲＱ ＡＣＫ／ＮＡＣＫを含む。ＣＱＩは、下りリンクのチャネル品質を示すインデックスであり、下りリンク伝送に用いるべきＭＣＳの決定等に用いられる。ＰＭＩは、下りリンクの伝送のために用いることが望ましいプレコーダマトリックスを示すインデックスである。ＲＩは、下りリンクの伝送に用いることが可能なレイヤ数（ストリーム数）を示すインデックスである。ＳＲは、ＰＵＳＣＨリソースの割り当てを要求する情報である。ＨＡＲＱ ＡＣＫ／ＮＡＣＫは、下りリンクデータを正しく受信したか否かを示す送達確認情報である。

（ＲＲＣコネクティッドモードにおけるＤＲＸ）
以下において、ＲＲＣコネクティッドモードにおけるＤＲＸについて説明する。図６は、ＲＲＣコネクティッドモードのＤＲＸ状態にあるＵＥ１００の動作を示す図である。

図６に示すように、ＲＲＣコネクティッドモードにおいてＤＲＸ状態にあるＵＥ１００は、ＰＤＣＣＨを間欠的に監視する。ＰＤＣＣＨを監視する周期は「ＤＲＸサイクル（ＤＲＸ Ｃｙｃｌｅ）」と称される。また、ＤＲＸサイクルごとに発生する監視期間は「オン期間（Ｏｎ ｄｕｒａｔｉｏｎ）」と称される。「Ｏｎ ｄｕｒａｔｉｏｎ」は、「ウェイクアップ期間」と称されることもある。ＰＤＣＣＨを監視しなくてもよい期間は、「スリープ期間」（又は「Ｏｐｐｏｒｔｕｎｉｔｙ ｆｏｒ ＤＲＸ」）と称されることもある。

下りリンクデータはＰＤＳＣＨを介して伝送され、ＰＤＳＣＨのスケジューリング情報（下りリンクスケジューリング情報）がＰＤＣＣＨに含まれている。ＵＥ１００は、「Ｏｎ ｄｕｒａｔｉｏｎ」においてＰＤＣＣＨを介してスケジューリング情報を検出した場合、スケジューリング情報により指定されたＰＤＳＣＨリソースを用いて下りリンクデータを受信することができる。

ＤＲＸサイクルには、ショートＤＲＸサイクル及びロングＤＲＸサイクルがある。ショートＤＲＸサイクル及びロングＤＲＸサイクルは、「Ｏｎ ｄｕｒａｔｉｏｎ」は同じで、スリープ期間の長さが異なる。例えば、「Ｏｎ ｄｕｒａｔｉｏｎ」は、１ｍｓから２００ｍｓまでの間で「Ｏｎ ｄｕｒａｔｉｏｎ ｔｉｍｅｒ」により設定が可能である。ロングＤＲＸサイクル（及びオフセット時間）は「ｌｏｎｇＤＲＸ−ＣｙｃｌｅＳｔａｒｔＯｆｆｓｅｔ」により設定され、ショートＤＲＸサイクルは「ｓｈｏｒｔＤＲＸ−Ｃｙｃｌｅ」により設定される。なお、ＤＲＸが設定される場合において、３ＧＰＰの仕様上、ロングＤＲＸが必須機能であり、ショートＤＲＸはオプション機能である。よって、ショートＤＲＸサイクルは、ＵＥ１００に設定されないことがある。

ＤＲＸは、下記のような複数のタイマに基づいて制御される。

・ｄｒｘ−ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒ： 上りリンク（ＵＬ）或いは下りリンク（ＤＬ）のユーザデータのスケジューリングを示すＰＤＣＣＨを正しく復号した後の連続するサブフレーム（ＰＤＣＣＨサブフレーム）の数
・ＨＡＲＱ ＲＴＴ Ｔｉｍｅｒ： ＤＬのＨＡＲＱ再送が行われるまでの最小サブフレーム数
・ｄｒｘ−ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒ： 再送に使用される期間

ＵＥ１００は、「Ｏｎ ｄｕｒａｔｉｏｎ」中に自身宛のＰＤＣＣＨの復号に成功すると「ｄｒｘ−ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒ」を起動する。同時に、「ＨＡＲＱ ＲＴＴ Ｔｉｍｅｒ」を起動する。ＤＬデータを正しく復号できなかった場合、「ＨＡＲＱ ＲＴＴ Ｔｉｍｅｒ」が満了すると同時に「ｄｒｘ−ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒ」を起動する。ＵＥ１００は、ＤＬデータの再送を受け、正しく復号できた場合、「ｄｒｘ−ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒ」を停止する。そして、「ｄｒｘ−ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒ」が満了すると同時にスリープ期間に移る。

なお、「Ｏｎ ｄｕｒａｔｉｏｎ ｔｉｍｅｒ」、「ｄｒｘ−ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒ」、又は「ｄｒｘ−ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒ」が動作中の状態は、「Ａｃｔｉｖｅ状態」と称される。ＵＥ１００は、Ａｃｔｉｖｅ状態においてＰＤＣＣＨを監視する。

上述したＤＲＸの各パラメータを含む設定情報（Ｏｎ ｄｕｒａｔｉｏｎ、各種タイマ、ロングＤＲＸサイクル、ショートＤＲＸサイクル等）は、個別ＲＲＣメッセージ中の情報要素である「ＤＲＸ−Ｃｏｎｆｉｇ」によりｅＮＢ２００がＵＥ１００に設定する。

（ＴＣＰの概要）
図７は、ＴＣＰの概要を説明するための図である。実施形態において、ＵＥ１００は、ＬＴＥシステムのネットワークを介して、インターネット上のサーバとのＴＣＰ通信を行う。

図７に示すように、サーバは、ＵＥ１００からの「ＴＣＰ ＡＣＫ」に基づいてネットワークの混雑状況を判断する。サーバは、「ＴＣＰ ＡＣＫ」の受信に応じて、ウィンドウサイズを徐々に増加させる。ウィンドウサイズとは、「ＴＣＰ ＡＣＫ」を待たずに連続的に送信する「ＴＣＰ Ｓｅｇｍｅｎｔ」の量である。一方、サーバは、「ＴＣＰ ＡＣＫ」の受信に失敗（タイムアウト）した場合、ウィンドウサイズを半減させる。このような制御は「スロースタート」と称される。

よって、ｅＮＢ２００が下りリンクにおいてデータ（ＴＣＰ Ｓｅｇｍｅｎｔ）を速やかに送信し、且つ、ＵＥ１００が上りリンクにおいて「ＴＣＰ ＡＣＫ」を速やかに送信しなければ、下りリンクのＴＣＰスループットを高めることができない。換言すると、ｅＮＢ２００がＥＰＣ２０からデータを受信してから当該データをＵＥ１００に送信するまでの時間（下りリンクの転送遅延）を短縮できれば、下りリンクのＴＣＰスループットを高めることができる。

（通信シーケンスの一例）
図８は、ＬＴＥシステムにおける通信シーケンスの一例を説明するための図である。図８において、ＵＥ１００は、ｅＮＢ２００とのＲＲＣ接続を確立した状態（すなわち、ＲＲＣコネクテッドモード）においてＤＲＸ動作を行う。

図８に示すように、ステップＳ１において、ｅＮＢ２００は、ＥＰＣ２０からＴＣＰパケット（ＴＣＰセグメント）を受信する。

ステップＳ２において、ｅＮＢ２００は、ＰＤＣＣＨリソースを用いて、ＰＤＳＣＨリソースをＵＥ１００に割り当てる。また、ｅＮＢ２００は、ＰＤＳＣＨリソースを用いて、ＥＰＣ２０から受信したＴＣＰパケットに対応する下りリンクデータをＵＥ１００に送信する。具体的には、ｅＮＢ２００は、下りリンクスケジューリング情報を含むＤＣＩをＰＤＣＣＨ上でＵＥ１００に送信し、当該ＤＣＩが示すＰＤＳＣＨリソースを用いてＵＥ１００に下りリンクデータを送信する。

但し、ｅＮＢ２００は、ＥＰＣ２０からＴＣＰパケットを受信した後、ＵＥ１００がオン期間になるまで、当該ＵＥ１００に対するデータ送信を待たなければならない。特に、ＤＲＸサイクルが長い場合には、下りリンクの転送遅延（ＤＬ ｔｒａｎｓｆｅｒ ｄｅｌａｙ）が深刻な問題になり得る。

この段階で、ｅＮＢ２００は、ＰＤＣＣＨリソースを用いて、（周期的な）ＰＵＳＣＨリソースを予めＵＥ１００に割り当ててもよい（ステップＳ２Ａ）。具体的には、ｅＮＢ２００は、上りリンクスケジューリング情報（ＵＬ ｇｒａｎｔ）を含むＤＣＩをＰＤＣＣＨ上でＵＥ１００に送信してもよい。このような手法は、「Ｐｒｅ−ｇｒａｎｔ」と称される。なお、以下のステップＳ３乃至Ｓ６は、「Ｐｒｅ−ｇｒａｎｔ」を行わない場合の動作である。

ＵＥ１００は下りリンクデータを受信し、下りリンクデータをＵＥ１００の上位層に移動する。ＵＥ１００の上位層は、ＴＣＰ ＡＣＫを生成してＵＥ１００の下位層に通知する。ＵＥ１００は、送信バッファ（ＵＥ１００の下位層）に上りリンクデータ（ＴＣＰ ＡＣＫパケット）が存在することに応じて、ｅＮＢ２００に対するＰＵＳＣＨリソースの割り当ての要求を決定する。

ステップＳ３において、ＵＥ１００は、ＰＵＳＣＨリソースの割り当てを要求するためのＳＲを、ＰＵＣＣＨリソースを用いてｅＮＢ２００に送信する。

ステップＳ４において、ｅＮＢ２００は、ＳＲの受信に応じて、ＵＥ１００にＰＵＳＣＨリソースを割り当てる。

ステップＳ５において、ＵＥ１００は、ｅＮＢ２００から割り当てられたＰＵＳＣＨリソースを用いて、ＵＥ１００の送信バッファ内の上りリンクデータの量を示すバッファ情報を含むＢＳＲをｅＮＢ２００に送信する。

ステップＳ６において、ｅＮＢ２００は、ＢＳＲの受信に応じて、適切な量のＰＵＳＣＨリソースをＵＥ１００に割り当てる。ＵＥ１００は、ｅＮＢ２００から割り当てられたＰＵＳＣＨリソースを用いて、ＵＥ１００の送信バッファ内の上りリンクデータ（ＴＣＰ ＡＣＫパケット）をｅＮＢ２００に送信する。

［第１実施形態］
以下において、第１実施形態について説明する。

第１実施形態に係るＵＥ１００は、ＤＲＸサイクルごとに発生するオン期間内でＰＤＣＣＨを監視するＤＲＸ動作を行う。ＵＥ１００は、オン期間内で、ＰＤＣＣＨを介して、スケジューリング情報を含まない特殊な下りリンク制御情報をｅＮＢ２００から受信する受信部１１０と、特殊な下りリンク制御情報の受信に応じて、ＤＲＸ休止期間にわたってＰＤＣＣＨの監視を継続する制御部１３０と、を備える。特殊な下りリンク制御情報は、ＤＲＸ休止期間を指定する情報を含んでもよい。

第１実施形態に係るｅＮＢ２００は、ＤＲＸサイクルごとに発生するオン期間内でＰＤＣＣＨを監視するＤＲＸ動作を行うＵＥ１００との通信を行う。ｅＮＢ２００は、オン期間内で、ＰＤＣＣＨを介して、スケジューリング情報を含まない特殊な下りリンク制御情報をＵＥ１００に送信する処理を行う制御部２３０を備える。特殊な下りリンク制御情報は、ＰＤＣＣＨの監視をＤＲＸ休止期間にわたってＵＥ１００に継続させるために用いられる。特殊な下りリンク制御情報は、ＤＲＸ休止期間を指定する情報を含んでもよい。

図９は、第１実施形態に係る動作シーケンスの一例を示す図である。図９において、ＵＥ１００は、ｅＮＢ２００とのＲＲＣ接続を確立した状態（すなわち、ＲＲＣコネクテッドモード）においてＤＲＸ動作を行う。

ステップＳ１１において、ＵＥ１００は、ＰＵＳＣＨを介して上りリンクデータ（ＵＬデータ）をｅＮＢ２００に送信する。ＵＬデータは、例えばＦＴＰ（Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）のｇｅｔコマンドである。但し、ステップＳ１１は必須ではなく、省略してもよい。ｅＮＢ２００は、ＵＥ１００から受信したＵＬデータをＥＰＣ２０に転送する。

ステップＳ１２において、ＵＥ１００は、オン期間（Ｏｎ ｄｕｒａｔｉｏｎ）内でＰＤＣＣＨを監視する。

ステップＳ１３において、ｅＮＢ２００は、オン期間内で、ＰＤＣＣＨを介して、スケジューリング情報（「Ｒｅｓｏｕｒｃｅ ｂｌｏｃｋ ａｓｓｉｇｎｍｅｎｔ」及びＭＣＳ）を含まない特殊な下りリンク制御情報（ＤＣＩ）をＵＥ１００に送信する。特殊なＤＣＩは、ＨＡＲＱプロセス情報及びＴＣＰコマンド等も含まない。すなわち、特殊なＤＣＩは、実質的に空のＤＣＩである。ｅＮＢ２００は、ＵＥ１００からのＵＬデータの受信に応じて、特殊なＤＣＩをＵＥ１００に送信してもよい。

ステップＳ１４において、ＵＥ１００は、オン期間内で自身宛のＰＤＣＣＨの復号に成功したことに応じて、「ｄｒｘ−ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒ」を起動する。すなわち、ＵＥ１００は、「ｄｒｘ−ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒ」により定められるＤＲＸ休止期間に移行し、ＤＲＸ休止期間にわたってＰＤＣＣＨの監視を継続する。

なお、特殊なＤＣＩは、一時的に用いられる「ｄｒｘ−ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒ」の値（サブフレーム数）を指定する情報を含んでもよい。この場合、ＵＥ１００は、指定されたサブフレーム期間中は、ＰＤＣＣＨの監視を行う。

ステップＳ１５において、ｅＮＢ２００は、ＥＰＣ２０からデータ（ＴＣＰパケット）を受信する。なお、特殊なＤＣＩをＵＥ１００に送信した場合、ｅＮＢ２００は、オン期間終了後もＵＥ１００がＰＤＣＣＨの監視を継続する状態（すなわち、Ａｃｔｉｖｅ状態）であると認識する。よって、ｅＮＢ２００は、オン期間終了後もＵＥ１００に対するＰＤＣＣＨ（及びＤＬデータ）の送信が可能であると判断する。

ステップＳ１６において、ｅＮＢ２００は、下りリンクスケジューリング情報を含むＤＣＩをＰＤＣＣＨ上でＵＥ１００に送信する。

ステップＳ１７において、ｅＮＢ２００は、当該ＤＣＩ（下りリンクスケジューリング情報）が示すＰＤＳＣＨリソースを用いて、ＵＥ１００に下りリンクデータ（ＤＬデータ）を送信する。ＵＥ１００は、ＤＬデータを受信する。

このように、第１実施形態によれば、ｅＮＢ２００は、ＥＰＣ２０からＴＣＰパケットを受信した後、当該ＵＥ１００に対するデータ送信を速やかに行うことができる。よって、ＤＲＸサイクルが長い場合でも、下りリンクの転送遅延（ＤＬ ｔｒａｎｓｆｅｒ ｄｅｌａｙ）を短縮することができる。その結果、下りリンクのＴＣＰスループットを高めることができる。

［第２実施形態］
以下において、第２実施形態について、第１実施形態との相違点を主として説明する。

第２実施形態に係るＵＥ１００は、ＤＲＸ動作を行う。ＵＥ１００は、上りリンクデータをｅＮＢ２００に送信する際に、下りリンクデータの受信が予想されることを示す通知をｅＮＢ２００に送信する送信部１２０と、当該通知を送信してから所定の期間において、オン期間外であってもＰＤＣＣＨを継続的に監視する制御部１３０と、を備える。当該通知は、当該所定の期間を示す情報、下りリンクデータを受信するために期待する割り当てデータ量又はスループットを示す情報、下りリンクデータの受信が予想されるタイミングを示す情報、ＰＤＣＣＨの継続的な監視を開始することを示す情報のうち少なくとも１つを含んでもよい。これらの情報は、例えば、ＵＥ１００のアプリケーション層等から得ることができる。

第２実施形態に係るｅＮＢ２００は、ＤＲＸ動作を行うＵＥ１００との通信を行う。ｅＮＢ２００は、上りリンクデータをＵＥ１００から受信する際に、下りリンクデータの受信が予想されることを示す通知をＵＥ１００から受信する受信部２２０と、当該通知を受信してから所定の期間において、オン期間外であっても、ＰＤＣＣＨを介して下りリンク制御情報（ＤＣＩ）をＵＥ１００に送信する処理を行う制御部２３０と、を備える。

図１０は、第２実施形態に係る動作シーケンスの一例を示す図である。図１０において、ＵＥ１００は、ｅＮＢ２００とのＲＲＣ接続を確立した状態（すなわち、ＲＲＣコネクテッドモード）においてＤＲＸ動作を行う。

ステップＳ２１において、ＵＥ１００は、ＰＵＳＣＨを介して上りリンクデータ（ＵＬデータ）をｅＮＢ２００に送信する。ＵＬデータは、例えばＦＴＰのｇｅｔコマンドである。ＵＥ１００は、ＵＬデータをｅＮＢ２００に送信する際に、下りリンクデータ（ＤＬデータ）の受信が予想されることを示す通知（以下、「ＤＬ通知」と称する）をｅＮＢ２００に送信する。ＤＬ通知は、例えばＭＡＣ制御要素（ＭＡＣ層シグナリング）により送信される。ｅＮＢ２００は、ＵＥ１００から受信したＵＬデータをＥＰＣ２０に転送する。また、ｅＮＢ２００は、ＤＬ通知をＵＥ１００から受信した場合、一定期間の間はオン期間外でもＵＥ１００がＰＤＣＣＨの監視を継続する状態（すなわち、Ａｃｔｉｖｅ状態）であると認識する。よって、ｅＮＢ２００は、一定期間の間はオン期間外でもＵＥ１００に対するＰＤＣＣＨ（及びＤＬデータ）の送信が可能であると判断する。

ＤＬ通知は、当該一定期間を示す情報、ＤＬデータを受信するために期待する割り当てデータ量又はスループットを示す情報、ＤＬデータの受信が予想されるタイミング（例えば、１５サブフレーム後）を示す情報、のうち少なくとも１つを含んでもよい。これらの情報は、ＤＬデータの送信処理（ステップＳ２４及びＳ２５）においてｅＮＢ２００により利用される。

ステップＳ２２において、ＵＥ１００は、ＤＬ通知の送信に応じて、一定期間に対応するタイマを起動する。すなわち、ＵＥ１００は、当該タイマにより定められるＤＲＸ休止期間に移行し、ＤＲＸ休止期間にわたってＰＤＣＣＨの監視を継続する。

ステップＳ２３において、ｅＮＢ２００は、ＥＰＣ２０からデータ（ＴＣＰパケット）を受信する。

ステップＳ２４において、ｅＮＢ２００は、下りリンクスケジューリング情報を含むＤＣＩをＰＤＣＣＨ上でＵＥ１００に送信する。ＤＬデータを受信するために期待する割り当てデータ量又はスループットを示す情報がＤＬ通知に含まれていた場合、ｅＮＢ２００は、当該情報に基づいて下りリンクスケジューリング情報を生成する。

ステップＳ２５において、ｅＮＢ２００は、当該ＤＣＩ（下りリンクスケジューリング情報）が示すＰＤＳＣＨリソースを用いて、ＵＥ１００にＤＬデータを送信する。ＵＥ１００は、ＤＬデータを受信する。

このように、第２実施形態によれば、第１実施形態と同様に、下りリンクの転送遅延（ＤＬ ｔｒａｎｓｆｅｒ ｄｅｌａｙ）を短縮することができる。その結果、下りリンクのＴＣＰスループットを高めることができる。

［第２実施形態の変更例］
図１０に示すシーケンスは、以下のように一部を変更可能である。

ＵＥ１００は、ステップＳ２１におけるＵＬデータ送信時に、ＭＡＣ ＣＥ等で、ＰＤＣＣＨの継続的な監視（モニタ）を開始する旨をｅＮＢ２００に通知し、ステップＳ２２におけるＰＤＣＣＨ監視を開始（つまり、ＤＲＸ動作を一時的に休止）してもよい。

また、ＵＥ１００は、ステップＳ２２におけるＰＤＣＣＨの継続的な監視を、次回ＤＬデータが伝送された場合に停止して、通常ＤＲＸ動作に戻してもよい（暗示的なＰＤＣＣＨ継続監視停止）。或いは、ＵＥ１００は、ステップＳ２１におけるＵＬデータ送信（ｇｅｔコマンド）に対応するＤＬデータを受信し、例えば上位レイヤから当該ＤＬデータの受信を通知された場合に、ＰＤＣＣＨの継続的な監視を停止してもよい。この場合、ＵＥ１００は、当該ＰＤＣＣＨ監視の停止をＭＡＣ ＣＥ等でｅＮＢ２００に通知してもよい（明示的なＰＤＣＣＨ継続監視停止）。

［第３実施形態］
以下において、第３実施形態について、第１実施形態及び第２実施形態との相違点を主として説明する。

第３実施形態に係るＵＥ１００は、ＤＲＸ動作を行う。ＵＥ１００は、上りリンクデータをｅＮＢ２００に送信した後、上りリンクデータに対応するＡＣＫ／ＮＡＣＫ（ＨＡＲＱ ＡＣＫ／ＮＡＣＫ）をｅＮＢ２００から受信するためにＰＨＩＣＨを監視する制御部１３０を備える。なお、ＬＴＥの仕様上、ＵＥ１００は、オン期間と無関係にＰＨＩＣＨを監視する。ＵＥ１００の制御部１３０は、オン期間外であっても、ＰＨＩＣＨを監視する際にＰＤＣＣＨも監視する。

第３実施形態に係るｅＮＢ２００は、ＤＲＸ動作を行うＵＥ１００との通信を行う。ｅＮＢ２００は、上りリンクデータをＵＥ１００から受信した後、ＰＨＩＣＨを介して上りリンクデータに対応するＡＣＫ／ＮＡＣＫをＵＥ１００に送信する処理を行う制御部２３０を備える。制御部２３０は、オン期間外であっても、ＡＣＫ／ＮＡＣＫを送信する際に、ＰＤＣＣＨを介して下りリンク制御情報（ＤＣＩ）をＵＥ１００に送信する。

図１１は、第３実施形態に係る動作シーケンスの一例を示す図である。図１１において、ＵＥ１００は、ｅＮＢ２００とのＲＲＣ接続を確立した状態（すなわち、ＲＲＣコネクテッドモード）においてＤＲＸ動作を行う。

ステップＳ３１において、ＵＥ１００は、ＰＵＳＣＨを介して上りリンクデータ（ＵＬデータ）をｅＮＢ２００に送信する。ｅＮＢ２００は、ＵＥ１００から受信したＵＬデータをＥＰＣ２０に転送する。

ステップＳ３２において、ｅＮＢ２００は、ＥＰＣ２０からデータ（ＴＣＰパケット）を受信する。

ステップＳ３３において、ＵＥ１００は、ＵＬデータに対応するＡＣＫ／ＮＡＣＫをｅＮＢ２００から受信するためにＰＨＩＣＨを監視する。ＵＥ１００は、オン期間外であっても、ＰＨＩＣＨを監視する際にＰＤＣＣＨも監視する。具体的には、ＵＥ１００は、ＰＨＩＣＨを監視するサブフレーム中のＰＤＣＣＨを監視する。

ステップＳ３４において、ｅＮＢ２００は、ＰＨＩＣＨを介して、ＵＬデータに対応するＡＣＫ／ＮＡＣＫをＵＥ１００に送信する。ＵＥ１００は、ＡＣＫ／ＮＡＣＫを受信する。

ステップＳ３５において、ｅＮＢ２００は、下りリンクスケジューリング情報を含むＤＣＩをＰＤＣＣＨ上でＵＥ１００に送信する。ＵＥ１００は、当該ＤＣＩを受信する。当該ＤＣＩは、下りリンクスケジューリング情報に加えて、又は下りリンクスケジューリング情報に代えて、上りリンクスケジューリング情報（ＵＬ ｇｒａｎｔ）を含んでもよい。

ステップＳ３６において、ｅＮＢ２００は、当該ＤＣＩ（下りリンクスケジューリング情報）が示すＰＤＳＣＨリソースを用いて、ＵＥ１００にＤＬデータを送信する。ＵＥ１００は、ＤＬデータを受信する。

このように、第３実施形態によれば、第１実施形態と同様に、下りリンクの転送遅延（ＤＬ ｔｒａｎｓｆｅｒ ｄｅｌａｙ）を短縮することができる。その結果、下りリンクのＴＣＰスループットを高めることができる。

［その他の実施形態］
図１２は、実施形態の変更例に係る動作を示す図である。本変更例は、上述した実施形態に係る動作（すなわち、下りリンクの転送遅延を短縮する動作）を適切に制御するための方法に関する。図１２の初期状態において、ＵＥ１００は、ｅＮＢ２００のセルにおいてＲＲＣコネクティッドモードである。

図１２に示すように、ＵＥ１００は、実施形態に係る機能（すなわち、下りリンクの転送遅延を短縮する機能）をＵＥ１００が有することを示す能力情報（ＵＥ Ｃａｐａｂｉｌｉｔｙ Ｉｎｆｏｒｍａｔｉｏｎ）をｅＮＢ２００に送信する（ステップＳ１０１）。ｅＮＢ２００は、「ＵＥ Ｃａｐａｂｉｌｉｔｙ Ｉｎｆｏｒｍａｔｉｏｎ」を受信する。但し、ｅＮＢ２００は、「ＵＥ Ｃａｐａｂｉｌｉｔｙ Ｉｎｆｏｒｍａｔｉｏｎ」をＵＥ１００から受信せずに、「ＵＥ Ｃａｐａｂｉｌｉｔｙ Ｉｎｆｏｒｍａｔｉｏｎ」をＭＭＥ３００から取得してもよい。ｅＮＢ２００は、「ＵＥ Ｃａｐａｂｉｌｉｔｙ Ｉｎｆｏｒｍａｔｉｏｎ」に基づいて、実施形態に係る機能をＵＥ１００が有することを確認する。或いは、ＵＥ１００は、下りリンクの転送遅延を短縮する機能に興味を持つことを示す興味通知をｅＮＢ２００に送信してもよい。興味通知は、ＲＲＣメッセージの一種である「ＵＥ Ａｓｓｉｓｔａｎｃｅ Ｉｎｆｏｒｍａｔｉｏｎ」によりＵＥ１００からｅＮＢ２００に送信されてもよい。ＵＥ１００は、「ＵＥ Ｃａｐａｂｉｌｉｔｙ Ｉｎｆｏｒｍａｔｉｏｎ」及び興味通知（ＵＥ Ａｓｓｉｓｔａｎｃｅ Ｉｎｆｏｒｍａｔｉｏｎ）のうち、何れか一方のみ又は両方をｅＮＢ２００に送信してもよい。ｅＮＢ２００は、実施形態に係る機能に関するパラメータを含む設定情報（Ｃｏｎｆｉｇｕｒａｔｉｏｎｓ）をＵＥ１００に送信する（ステップＳ１０２）。ＵＥ１００は、当該Ｃｏｎｆｉｇｕｒａｔｉｏｎｓ（パラメータ）を記憶する。ＵＥ１００は、当該Ｃｏｎｆｉｇｕｒａｔｉｏｎｓ（パラメータ）を記憶している場合にのみ、上述した実施形態に係る動作を行う。

上述した実施形態において、移動通信システムとしてＬＴＥシステムを例示した。しかしながら、本発明はＬＴＥシステムに限定されない。ＬＴＥシステム以外のシステムに本発明を適用してもよい。

［付記］
（１．はじめに）
ＬＴＥのためのレイテンシ低減技術に関する新たな研究項目が承認された。この研究の目的は、以下のように、パケットデータレイテンシを低減するために２つの技術分野を識別する。

・高速アップリンクアクセス解決策［ＲＡＮ２］：
・ＴＴＩショートニングおよび低減された処理時間［ＲＡＮ１］：
高速上りリンクアクセス解決策は、現在のＴＴＩ長さおよび処理時間、すなわちＴＴＩショートニングを維持することを備えたいくつかの実施技術、および、備えていないいくつかの実施技術と比較して、リソース効率を改善することが期待されている。

本付記では、高速上りリンクアクセス解決策に関する研究に対する初期検討が提供される。

（２．議論）
（２．１．作業仮説）
本研究のモチベーション文書は、上りリンクリソース割当のための現在の標準化されたメカニズムが、ＴＣＰスループットの観点から、ＬＴＥの潜在的なスループットパフォーマンスを圧迫することを示している。ＴＣＰスループットの低下は、往復時間レイテンシ、すなわちＵＬにおけるＴＣＰ−ＡＣＫ送信によるＴＣＰスロー開始アルゴリズムによって引き起こされる。したがって、高速上りリンクアクセス解決策は、ＴＣＰレイヤにおいて構築された上部レイヤによって提供されるユーザ経験を改善することが期待されている。作業仮説のために、ＳＩＤは、高速上りリンクアクセス解決策に言及する。

研究分野は、エアインターフェース容量、バッテリ寿命、制御チャネルリソース、仕様インパクト、および技術的可能性を含むリソース効率を含んでいる。ＦＤＤデュプレクスモードとＴＤＤデュプレクスモードとの両方が考慮される。

第１の態様として、典型的なアプリケーションおよび使用の場合に関するレイテンシ改善による、低減された応答時間、および、改善されたＴＣＰスループットのような潜在的な利得が識別され、文書化される。この評価では、ＲＡＮ２は、短縮化されたＴＴＩと同様に、プロトコル強化によるレイテンシ低減を仮定し得る。結論として、この研究の本態様は、どのレイテンシ低減が、望ましいであるのかを示すことになっている［ＲＡＮ２］。

その解決策は、ネットワーク容量、ＵＥ電力消費、制御チャネルリソースを改善することが期待されている。特に、改善されたＴＣＰスループットは、主要なパフォーマンスインジケータとして考慮され得る。

観察１：ＤＬ ＴＣＰスループットが、ＵＬレイテンシ低減解決策によって改善されることが期待される。

高速上りリンクアクセス解決策特有の態様の場合；
アクティブなＵＥと、長期間、非アクティブであったが、ＲＲＣ接続コネクティッドに維持されているＵＥとのために、スケジュールされたＵＬ送信のためのユーザプレーンレイテンシを低減することと、現在のＴＴＩ長さおよび処理時間を維持する維持しない両方について今日の規格によって許容されている事前スケジューリング解決策と比較して、プロトコル強化およびシグナリング強化によって、より高いリソース効率の解決策を得ることと、に注目されるべきである。

アクティブなＵＥは、データを連続的に送信／受信していると仮定される。したがって、ＵＥは、アクティブ時間にあると考えられる。すなわち、非アクティビティタイマが動作していることにより、ＤＲＸは適用されない。

観察２：アクティブ時間にあるＵＥが考慮される。

長い時間、非アクティブであるが、ＲＲＣコネクティッドに維持されているＵＥは、ＵＥが長いＤＲＸサイクルを適用し、上りリンク送信を実行するために少なくともＳＲとＢＳＲとを送信する必要があると解釈され得る。さらに、時間アライメントタイマＴＡＴが終了した場合、ＵＥは、ＳＲ送信前に、ランダムアクセスプロシージャを開始する。これは、ユーザ経験、すなわち、実際の応答時間を低下させる。

観察３：長いＤＲＸサイクルの適用を備え、ＵＬ許可のないＵＥが考慮される。

観察４：ＵＥが長い間非アクティブであれば、時間アライメントタイマが終了し得る。

事前スケジューリング解決策と比較して、高速上りリンクアクセス解決策は、たとえ現在のＴＴＩ長さおよび処理長さが仮定されていても、より高いリソース効率であるべきである。ＴＴＩショートニングは、より一般的な解決策であり、増加されたＨＡＲＱインタラクションのおかげで、下りリンク配信のみならず、上りリンクアクセスレイテンシのレイテンシも低減することが期待されている。

観察５：高速上りリンク解決策は、ＴＴＩショートニングアプローチと独立した利得を有する。

モチベーション文書では、高速上りリンクアクセスのための可能なアプローチが、実施技術である事前スケジューリングに基づいており、事前スケジューリングによって、ｅＮＢが、ＳＲ受信前に上りリンクリソースを割り当てることが述べられている。しかしながら、ＵＥが送るべき上りリンクデータを有していなくても、事前スケジューリング技術は、上りリンク制御チャネル（すなわち、ＰＵＳＣＨ）および下りリンク制御チャネル（すなわち、ＰＤＣＣＨ）においてラジオリソースを消費する。既存のＳＰＳが事前スケジューリングのために使用されている場合において、ＵＥは、設定されたＳＰＳリソースの暗黙的な解放を回避するために、パディングデータを送信する必要があることも議論されている。したがって、動機付け文書は、標準化されたアプローチが事前スケジューリング技術を強化することを期待されることを提案した。これは、事前許可、ＳＰＳ同様のメカニズム、データが利用可能ではない場合における無パディング、および／または、動的なスケジューリングへの円滑な移行を含み得る。

観察６：標準化されたアプローチは、実施技術と比較して、リソース効率を強化することが期待されている。

（２．２．典型的な使用の場合）
今日のモバイルトラフィックの増加は、モバイルビデオトラフィックの成長によって引き起こされ、この傾向は、パブリックレポートによれば、将来のトラフィックを支配することが予想されている。ビデオストリーミングは、（ＵＤＰによる）ライブストリーミング向けでなければ、典型的にＴＣＰ（ＴＣＰによるＨＴＴＰ）を用いることが良く知られている。したがって、ビデオストリーミングの使用の場合は、この研究の範囲に沿っている。

レポートはまた、ソーシャルネットワーキングおよびウェブブラウジングは、モバイルトラフィックを、第２の支配的なアプリケーションとして用い、これによって、これらアプリケーションは、典型的にＨＴＴＰに構築され、したがって、ＴＣＰを使用することを指摘している。多くの３ＧＰＰ代表者は既に通じているように、３ＧＰＰ ＦＴＰサービスは、ＴＣＰも用いるＴｄｏｃｓをダウンロードするために、各代理人によって連続的にアクセスされ得る。したがって、ＨＴＴＰまたはＦＴＰに構築されたアプリケーションにおける振る舞いは、典型的な使用の場合であると考えられるべきである。

提案１：ＨＴＴＰおよびＦＴＰに構築されたアプリケーションにおけるユーザ振る舞いは、この研究における典型的な使用の場合であると考えられるべきである。

図１３は、モバイルトラフィックボリュームによる上位５つのアプリケーション及びモバイルアプリケーション分析を示す図である。

そのようなアプリケーションにおける最も典型的な振る舞いは、要求／応答ダイアログとしてモデル化され得る。たとえば、ユーザがＦＴＰでファイルをダウンロードしたい場合、クライアントは、ＲＥＴＲコマンド（別名、ゲット）をサーバに先ず送り、その後、ファイルダウンロードが開始する。同じ振る舞いは、ＨＴＴＰに対しても適用可能である。これによって、図１４に例示されるように、ウェブブラウザは、先ずゲットを送り、その後、ユーザがウェブページを開いた時にウェブページがダウンロードされる。典型的な振る舞いを考慮すると、ＲＡＮ２は、対応するＤＬ ＴＣＰパケット（たとえば、ゲットのような要求）に先行する最初の上りリンクデータ送信が、単に仮定されるだけか、または、高速上りリンクアクセス解決策においても強化されるべきであるかを議論すべきである。

提案２：ＲＡＮ２は、対応するＤＬ ＴＣＰパケットに先行する最初の上りリンクデータ送信が、単に仮定されるだけか、または、高速上りリンクアクセス解決策においても強化されるべきであるかを議論すべきである。

（２．３．本質的な問題）
２．１で言及したように、上りリンクアクセスレイテンシに至る深刻な問題は、事前スケジューリング技術、または、強化されたＳＰＳを用いた事前許可技術の何れによっても解決されることはできない。

深刻な問題１：ＤＬ伝送遅れ
ＤＬ伝送遅れは、長いＤＲＸサイクルによって引き起こされる。最悪の場合では、サービス提供セルは、ＤＬ ＴＣＰパケット受信後、１０〜２５６０サブフレームの間、送信機会を待つ必要がある。

深刻な問題２：早過ぎる／遅過ぎる割当
早過ぎる割当は、事前スケジューリング技術、または、ＳＲ受信前の事前許可アプローチによって引き起こされ得る。一方、遅過ぎる割当は、ＳＲ周期、すなわち、ＳＲ周期＊ｓｒ−ＰｒｏｈｉｂｉｔＴｉｍｅｒによって、または、単純過ぎるスケジューラ実施、すなわち、対応するＢＳＲ受信に基づいて、ＴＣＰ ＡＣＫパケットのための上りリンクリソース（したがって、ＵＥのＳＲ送信後の７サブフレーム）を割り当てるものによって可能となる。

深刻な問題３：多過ぎる／少な過ぎる割当
多過ぎる／少な過ぎる割当は、事前スケジューリング技術、または、ＢＳＲ前の事前許可アプローチによって引き起こされ得る。ＵＥのバッファステータスを知ることなく、スケジューラは、上りリンクリソースを盲目的に割り当てる必要がある。

深刻な問題４：初期上りリンク遅れ
観察４で述べられたように、ＴＡＴが終了した場合、ＵＥは、あらゆる上りリンク送信の前に、ランダムアクセスプロシージャを開始すべきである。

もちろん、賢い実施が、３つの深刻な問題によるネガティブなインパクト、たとえば、ＤＬ ＩＰパケットの内部を理解すること、および、以前の上りリンク許可の使用に基づいて上りリンクリソースを割り当てること、のうちのいくつかを低減し得る。しかしながら、標準化されたアプローチは、上記リストされたすべての問題ではないが、ほとんどを解決することが期待されるであろう。

提案３：ＤＬ伝送遅れ、早過ぎる／遅過ぎる割当、多過ぎる／少な過ぎる割当、ＴＡＴ終了は、高速上りリンクアクセス解決策によって最適化されるべきである。

（２．４．潜在的な解決策アプローチ）
２．３で議論されたように、ＤＲＸ、ＳＲ、ＢＳＲ、および／または、プロシージャが再考されなければ、深刻な問題は解決されないであろう。これらの問題は、たとえ強化されたＳＰＳを用いた事前許可アプローチが適用されても、対処されることはないであろう。なぜなら、実際の許可と理想的な割当との間のミスマッチ（図１５）が、エアインターフェース容量、バッテリ寿命、制御チャネルリソースを含むリソース効率の低下を引き起こすからである。

観察７：事前許可アプローチは、既存の実施技術と比べて良好なパフォーマンスを有し得るが、これら深刻な問題を未だに解決することはないであろう。

これら深刻な問題を解決するために、以下の解決策アプローチが考慮され得る。

たとえば、最初のＵＬ送信（すなわち、ゲット）によってトリガされた、高速なＤＬ割当のための、ＤＲＸにおける拡張されたＯｎＤｕｒａｔｉｏｎハンドリング。

たとえば、ＳＲとＢＳＲとの統合による、最初のＵＬパケット送信のためのシグナリング往復の低減。

スペクトル効率へのインパクトの少ない、より短いＳＲ周期［ＲＡＮ１］。

たとえば、ＵＬデータ許可のための追加の機能を用いた、ＲＡＣＨプロシージャ強化。

したがって、ＲＡＮ２は、ＵＬ許可メカニズム自体だけでなく、ＵＬ許可に関連するプロシージャも研究すべきである。

提案４：ＲＡＮ２はまた、ＤＲＸ、ＳＲ、ＢＳＲ、およびＲＡＣＨの強化を研究すべきである。

（３．結論）
この付記では、承認された作業項目説明に基づいて作業仮説が議論された。典型的な使用の場合およびそのモデリングが提供される。４つの深刻な問題および潜在的な解決策アプローチが、この研究のために特定される。

［相互参照］
米国仮出願第６２／１６２１２３号（２０１５年５月１５日出願）の全内容が参照により本願明細書に組み込まれている。

本発明は、通信分野において有用である。

Claims (12)

1. ＤＲＸ（Ｄｉｓｃｏｎｔｉｎｕｏｕｓ ｒｅｃｅｐｔｉｏｎ）サイクルごとに発生するオン期間内でＰＤＣＣＨ（Ｐｈｙｓｉｃａｌ Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）を監視する制御部と、
   前記オン期間内で、前記ＰＤＣＣＨを介して、スケジューリング情報を含まない特殊な下りリンク制御情報を基地局から受信する受信部と、を備え、
   前記制御部は、前記特殊な下りリンク制御情報の受信に応じて、ＤＲＸ休止期間にわたって前記ＰＤＣＣＨの監視を継続する、
   無線端末。
2. 前記特殊な下りリンク制御情報は、前記ＤＲＸ休止期間を指定する情報を含む、
   請求項１に記載の無線端末。
3. 基地局であって、
   ＤＲＸサイクルごとに発生するオン期間内でＰＤＣＣＨを監視する無線端末との通信を行う制御部を備え、
   前記制御部は、前記オン期間内で、前記ＰＤＣＣＨを介して、スケジューリング情報を含まない特殊な下りリンク制御情報を前記無線端末に送信する処理を行い、
   前記特殊な下りリンク制御情報は、前記ＰＤＣＣＨの監視をＤＲＸ休止期間にわたって前記無線端末に継続させるために用いられる、
   基地局。
4. 前記特殊な下りリンク制御情報は、前記ＤＲＸ休止期間を指定する情報を含む、
   請求項３に記載の基地局。
5. ＤＲＸサイクルごとに発生するオン期間内でＰＤＣＣＨを監視する制御部と、
   上りリンクデータを基地局に送信する際に、下りリンクデータの受信が予想されることを示す通知を前記基地局に送信する送信部と、を備え、
   前記制御部は、前記通知を送信してから所定の期間において、前記オン期間外であっても前記ＰＤＣＣＨを継続的に監視する、
   無線端末。
6. 前記所定の期間は、前記無線端末が前記基地局から前記下りリンクデータを受信した際に終了する、
   請求項５に記載の無線端末。
7. 前記通知は、前記所定の期間を示す情報、前記下りリンクデータを受信するために期待する割り当てデータ量又はスループットを示す情報、前記下りリンクデータの受信が予想されるタイミングを示す情報、前記ＰＤＣＣＨの継続的な監視を開始することを示す情報のうち少なくとも１つを含む、
   請求項５に記載の無線端末。
8. 前記制御部は、前記ＰＤＣＣＨの継続的な監視を停止する場合に、当該停止を前記基地局に通知する、
   請求項５に記載の無線端末。
9. ＤＲＸサイクルごとに発生するオン期間内でＰＤＣＣＨを監視する無線端末との通信を行う制御部と、
   上りリンクデータを前記無線端末から受信する際に、下りリンクデータの受信が予想されることを示す通知を前記無線端末から受信する受信部と、を備え、
   前記制御部は、前記通知を受信してから所定の期間において、前記オン期間外であっても、前記ＰＤＣＣＨを介して下りリンク制御情報を前記無線端末に送信する処理を行う、
   基地局。
10. 前記通知は、前記一定の期間を示す情報、前記下りリンクデータを受信するために期待する割り当てデータ量又はスループットを示す情報、前記下りリンクデータの受信が予想されるタイミングを示す情報、のうち少なくとも１つを含む、
    請求項９に記載の基地局。
11. 無線端末であって、
    ＤＲＸサイクルごとに発生するオン期間内でＰＤＣＣＨを監視する制御部を備え、
    前記制御部は、上りリンクデータを基地局に送信した後、前記上りリンクデータに対応するＡＣＫ（Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）／ＮＡＣＫ（Ｎｅｇａｔｉｖｅ ＡＣＫ）を前記基地局から受信するためにＰＨＩＣＨ（Ｐｈｙｓｉｃａｌ ＨＡＲＱ Ｉｎｄｉｃａｔｏｒ Ｃｈａｎｎｅｌ）を監視し、
    前記制御部は、前記オン期間外であっても、前記ＰＨＩＣＨを監視する際に前記ＰＤＣＣＨも監視する、
    無線端末。
12. 基地局であって、
    ＤＲＸサイクルごとに発生するオン期間内でＰＤＣＣＨを監視する無線端末との通信を行う制御部を備え、
    前記制御部は、上りリンクデータを前記無線端末から受信した後、ＰＨＩＣＨを介して前記上りリンクデータに対応するＡＣＫ／ＮＡＣＫを前記無線端末に送信する処理を行い、
    前記制御部は、前記オン期間外であっても、前記ＡＣＫ／ＮＡＣＫを送信する際に、前記ＰＤＣＣＨを介して下りリンク制御情報を前記無線端末に送信する、
    基地局。

Images