(57)【要約】  一つの実施形態に係る無線端末は、ランダムアクセス手順を制御する制御部を備える。前記ランダムアクセス手順は、ランダムアクセスプリアンブルを基地局に送信する第１の処理と、ランダムアクセス応答を前記基地局から受信する第２の処理と、前記ランダムアクセス応答に基づいて前記基地局に上りリンク送信を行う第３の処理と、を含む。前記制御部は、前記第１の処理又は前記第３の処理において、前記無線端末の送信バッファ内の上りリンクデータの量を前記基地局に通知する。
2016185896.tif 000002
【特許請求の範囲】
【請求項１】
ランダムアクセス手順を制御する制御部を備える無線端末であって、
前記ランダムアクセス手順は、ランダムアクセスプリアンブルを基地局に送信する第１の処理と、ランダムアクセス応答を前記基地局から受信する第２の処理と、前記ランダムアクセス応答に基づいて前記基地局に上りリンク送信を行う第３の処理と、を含み、
前記制御部は、前記第１の処理又は前記第３の処理において、前記無線端末の送信バッファ内の上りリンクデータの量を前記基地局に通知する
無線端末。
【請求項２】
前記制御部は、前記第３の処理において、前記上りリンクデータの量を示す報告を前記基地局に送信することにより、前記上りリンクデータの量を前記基地局に通知する
請求項１に記載の無線端末。
【請求項３】
前記制御部は、前記第１の処理において、前記報告を前記基地局に送信するための無線リソースの割り当てを前記基地局に要求する
請求項２に記載の無線端末。
【請求項４】
前記ランダムアクセス手順は、前記第３の処理の後に競合解決メッセージを前記基地局から受信する第４の処理を含み、
前記制御部は、前記第４の処理において、前記上りリンクデータを送信するための無線リソースの割り当て情報を前記基地局から受信する
請求項２に記載の無線端末。
【請求項５】
前記制御部は、前記第４の処理において前記割り当て情報を前記基地局から受信したことに応じて、前記ランダムアクセス手順が終了するとともに前記上りリンクデータを前記基地局に送信する
請求項４に記載の無線端末。
【請求項６】
ランダムアクセス手順を制御する制御部を備える基地局であって、
前記ランダムアクセス手順は、ランダムアクセスプリアンブルを無線端末から受信する第１の処理と、ランダムアクセス応答を前記無線端末に送信する第２の処理と、前記ランダムアクセス応答に基づく上りリンク送信を前記無線端末から受信する第３の処理と、を含み、
前記制御部は、前記第１の処理又は前記第３の処理において、前記無線端末の送信バッファ内の上りリンクデータの量を前記無線端末から取得する
基地局。
【請求項７】
ランダムアクセス手順を行う無線端末を制御するプロセッサであって、
前記ランダムアクセス手順は、ランダムアクセスプリアンブルを基地局に送信する第１の処理と、ランダムアクセス応答を前記基地局から受信する第２の処理と、前記ランダムアクセス応答に基づいて前記基地局に上りリンク送信を行う第３の処理と、を含み、
前記プロセッサは、前記第１の処理又は前記第３の処理において、前記無線端末の送信バッファ内の上りリンクデータの量を前記基地局に通知する
プロセッサ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、移動通信システムにおいて用いられる無線端末、基地局、及びプロセッサに関する。
【背景技術】
【０００２】
移動通信システムの標準化プロジェクトである３ＧＰＰ（Ｔｈｉｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ）において、無線通信におけるレイテンシを低減するレイテンシ低減機能の導入が検討されている。このようなレイテンシ低減機能を実現するための技術として、高速上りリンクアクセス技術及びＴＴＩ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｔｉｍｅ  Ｉｎｔｅｒｖａｌ）短縮技術等が挙げられる。
【発明の概要】
【０００３】
一つの実施形態に係る無線端末は、ランダムアクセス手順を制御する制御部を備える。前記ランダムアクセス手順は、ランダムアクセスプリアンブルを基地局に送信する第１の処理と、ランダムアクセス応答を前記基地局から受信する第２の処理と、前記ランダムアクセス応答に基づいて前記基地局に上りリンク送信を行う第３の処理と、を含む。前記制御部は、前記第１の処理又は前記第３の処理において、前記無線端末の送信バッファ内の上りリンクデータの量を前記基地局に通知する。
【０００４】
一つの実施形態に係る基地局は、ランダムアクセス手順を制御する制御部を備える。前記ランダムアクセス手順は、ランダムアクセスプリアンブルを無線端末から受信する第１の処理と、ランダムアクセス応答を前記無線端末に送信する第２の処理と、前記ランダムアクセス応答に基づく上りリンク送信を前記無線端末から受信する第３の処理と、を含む。前記制御部は、前記第１の処理又は前記第３の処理において、前記無線端末の送信バッファ内の上りリンクデータの量を前記無線端末から取得する。
【０００５】
一つの実施形態に係るプロセッサは、ランダムアクセス手順を行う無線端末を制御する。前記ランダムアクセス手順は、ランダムアクセスプリアンブルを基地局に送信する第１の処理と、ランダムアクセス応答を前記基地局から受信する第２の処理と、前記ランダムアクセス応答に基づいて前記基地局に上りリンク送信を行う第３の処理と、を含む。前記プロセッサは、前記第１の処理又は前記第３の処理において、前記無線端末の送信バッファ内の上りリンクデータの量を前記基地局に通知する。
【図面の簡単な説明】
【０００６】
【図１】実施形態に係るＬＴＥシステム（移動通信システム）を示す図である。
【図２】実施形態に係るＵＥ（無線端末）のブロック図である。
【図３】実施形態に係るｅＮＢ（基地局）のブロック図である。
【図４】ＬＴＥシステムにおける無線インターフェイスのプロトコルスタック図である。
【図５】ＬＴＥシステムにおいて用いられる無線フレームの構成図である。
【図６】ＢＳＲ  ＭＡＣ制御要素を説明するための図である。
【図７】ＴＣＰの概要を説明するための図である。
【図８】一般的なランダムアクセス手順及び上りリンクの送信手順を示すシーケンス図である。
【図９】実施形態に係るランダムアクセス手順のパターン１を示すシーケンス図である。
【図１０】実施形態に係るランダムアクセス手順のパターン２を示すシーケンス図である。
【図１１】実施形態に係るランダムアクセス手順のパターン３を示すシーケンス図である。
【図１２】実施形態の付記に係る図である。
【図１３】実施形態の付記に係る図である。
【図１４】実施形態の付記に係る図である。
【発明を実施するための形態】
【０００７】
［実施形態の概要］
一般的な上りリンクの送信手順は、以下の第１のステップ乃至第３のステップを含む。
【０００８】
第１のステップにおいて、無線端末は、ＰＵＳＣＨ（Ｐｈｙｓｉｃａｌ  Ｕｐｌｉｎｋ  Ｓｈａｒｅｄ  Ｃｈａｎｎｅｌ）リソースを要求するためのスケジューリング要求（ＳＲ）を、ＰＵＣＣＨ（Ｐｈｙｓｉｃａｌ  Ｕｐｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ）リソースを用いて基地局に送信する。基地局は、ＳＲの受信に応じて、無線端末にＰＵＳＣＨリソースを割り当てる。
【０００９】
第２のステップにおいて、無線端末は、基地局から割り当てられたＰＵＳＣＨリソースを用いて、無線端末の送信バッファ内の上りリンクデータの量を示すバッファ情報を含むバッファステータス報告（ＢＳＲ）を基地局に送信する。基地局は、ＢＳＲの受信に応じて、適切な量のＰＵＳＣＨリソースを無線端末に割り当てる。
【００１０】
第３のステップにおいて、無線端末は、基地局から割り当てられたＰＵＳＣＨリソースを用いて、無線端末の送信バッファ内の上りリンクデータを基地局に送信する。
【００１１】
一方で、ＲＲＣコネクティッドモードの無線端末は、上りリンク同期状態が非同期（Ｎｏｎ−ｓｙｎｃｈｒｏｎｉｓｅｄ）である場合、上りリンク送信を行うために、ランダムアクセス手順を行う。また、ＲＲＣコネクティッドモードの無線端末は、初期接続（Ｉｎｉｔｉａｌ  ａｃｃｅｓｓ）を行うために、ランダムアクセス手順を行う。
【００１２】
無線端末は、ランダムアクセス手順の終了後に、上述した上りリンクの送信手順（すなわち、第１のステップ乃至第３のステップ）を行うことにより、上りリンクデータを基地局に送信可能である。しかしながら、ランダムアクセス手順の後に上りリンクの送信手順（第１のステップ乃至第３のステップ）を行う方法には、上りリンクのレイテンシを低減する、すなわち高速上りリンクアクセスを可能とする点において改善の余地がある。
【００１３】
以下の実施形態において、高速上りリンクアクセスを可能とするための技術が開示される。
【００１４】
一つの実施形態に係る無線端末は、ランダムアクセス手順を制御する制御部を備える。前記ランダムアクセス手順は、ランダムアクセスプリアンブルを基地局に送信する第１の処理と、ランダムアクセス応答を前記基地局から受信する第２の処理と、前記ランダムアクセス応答に基づいて前記基地局に上りリンク送信を行う第３の処理と、を含む。前記制御部は、前記第１の処理又は前記第３の処理において、前記無線端末の送信バッファ内の上りリンクデータの量を前記基地局に通知する。
【００１５】
一つの実施形態に係る基地局は、ランダムアクセス手順を制御する制御部を備える。前記ランダムアクセス手順は、ランダムアクセスプリアンブルを無線端末から受信する第１の処理と、ランダムアクセス応答を前記無線端末に送信する第２の処理と、前記ランダムアクセス応答に基づく上りリンク送信を前記無線端末から受信する第３の処理と、を含む。前記制御部は、前記第１の処理又は前記第３の処理において、前記無線端末の送信バッファ内の上りリンクデータの量を前記無線端末から取得する。
【００１６】
一つの実施形態に係るプロセッサは、ランダムアクセス手順を行う無線端末を制御する。前記ランダムアクセス手順は、ランダムアクセスプリアンブルを基地局に送信する第１の処理と、ランダムアクセス応答を前記基地局から受信する第２の処理と、前記ランダムアクセス応答に基づいて前記基地局に上りリンク送信を行う第３の処理と、を含む。前記プロセッサは、前記第１の処理又は前記第３の処理において、前記無線端末の送信バッファ内の上りリンクデータの量を前記基地局に通知する。
【００１７】
［実施形態］
（１）移動通信システムの構成
図１は、実施形態に係る移動通信システムであるＬＴＥシステムの構成を示す図である。図１に示すように、ＬＴＥシステムは、ＵＥ（Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ）１００、Ｅ−ＵＴＲＡＮ（Ｅｖｏｌｖｅｄ−ＵＭＴＳ  Ｔｅｒｒｅｓｔｒｉａｌ  Ｒａｄｉｏ  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ）１０、及びＥＰＣ（Ｅｖｏｌｖｅｄ  Ｐａｃｋｅｔ  Ｃｏｒｅ）２０を備える。
【００１８】
ＵＥ１００は、無線端末に相当する。ＵＥ１００は、移動型の通信装置であり、セル（サービングセル）との無線通信を行う。
【００１９】
Ｅ−ＵＴＲＡＮ１０は、無線アクセスネットワークに相当する。Ｅ−ＵＴＲＡＮ１０は、ｅＮＢ２００（ｅｖｏｌｖｅｄ  Ｎｏｄｅ−Ｂ）を含む。ｅＮＢ２００は、基地局に相当する。ｅＮＢ２００は、Ｘ２インターフェイスを介して相互に接続される。
【００２０】
ｅＮＢ２００は、１又は複数のセルを管理しており、自セルとの接続を確立したＵＥ１００との無線通信を行う。ｅＮＢ２００は、無線リソース管理（ＲＲＭ）機能、ユーザデータ（以下、単に「データ」という）のルーティング機能、モビリティ制御・スケジューリングのための測定制御機能等を有する。「セル」は、無線通信エリアの最小単位を示す用語として用いられる他に、ＵＥ１００との無線通信を行う機能を示す用語としても用いられる。
【００２１】
ＥＰＣ２０は、コアネットワークに相当する。ＥＰＣ２０は、ＭＭＥ（Ｍｏｂｉｌｉｔｙ  Ｍａｎａｇｅｍｅｎｔ  Ｅｎｔｉｔｙ）／Ｓ−ＧＷ（Ｓｅｒｖｉｎｇ−Ｇａｔｅｗａｙ）３００を含む。ＭＭＥは、ＵＥ１００に対する各種モビリティ制御等を行う。Ｓ−ＧＷは、データの転送制御を行う。ＭＭＥ／Ｓ−ＧＷ３００は、Ｓ１インターフェイスを介してｅＮＢ２００と接続される。Ｅ−ＵＴＲＡＮ１０及びＥＰＣ２０は、ネットワークを構成する。
【００２２】
（２）無線端末の構成
図２は、ＵＥ１００（無線端末）のブロック図である。図２に示すように、ＵＥ１００は、受信部１１０、送信部１２０、及び制御部１３０を備える。
【００２３】
受信部１１０は、制御部１３０の制御下で各種の受信を行う。受信部１１０は、アンテナ及び受信機を含む。受信機は、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換して制御部１３０に出力する。
【００２４】
送信部１２０は、制御部１３０の制御下で各種の送信を行う。送信部１２０は、アンテナ及び送信機を含む。送信機は、制御部１３０が出力するベースバンド信号（送信信号）を無線信号に変換してアンテナから送信する。
【００２５】
制御部１３０は、ＵＥ１００における各種の制御を行う。制御部１３０は、プロセッサ及びメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行うベースバンドプロセッサと、メモリに記憶されるプログラムを実行して各種の処理を行うＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）と、を含む。プロセッサは、音声・映像信号の符号化・復号を行うコーデックを含んでもよい。プロセッサは、上述した処理及び後述する処理を実行する。
【００２６】
（３）基地局の構成
図３は、ｅＮＢ２００（基地局）のブロック図である。図３に示すように、ｅＮＢ２００は、送信部２１０、受信部２２０、制御部２３０、及びバックホール通信部２４０を備える。
【００２７】
送信部２１０は、制御部２３０の制御下で各種の送信を行う。送信部２１０は、アンテナ及び送信機を含む。送信機は、制御部２３０が出力するベースバンド信号（送信信号）を無線信号に変換してアンテナから送信する。
【００２８】
受信部２２０は、制御部２３０の制御下で各種の受信を行う。受信部２２０は、アンテナ及び受信機を含む。受信機は、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換して制御部２３０に出力する。
【００２９】
制御部２３０は、ｅＮＢ２００における各種の制御を行う。制御部２３０は、プロセッサ及びメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行うベースバンドプロセッサと、メモリに記憶されるプログラムを実行して各種の処理を行うＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）と、を含む。プロセッサは、上述した処理及び後述する処理を実行する。
【００３０】
バックホール通信部２４０は、Ｘ２インターフェイスを介して隣接ｅＮＢ２００と接続され、Ｓ１インターフェイスを介してＭＭＥ／Ｓ−ＧＷ３００と接続される。バックホール通信部２４０は、Ｘ２インターフェイス上で行う通信及びＳ１インターフェイス上で行う通信等に用いられる。
【００３１】
（４）無線インターフェイス
図４は、ＬＴＥシステムにおける無線インターフェイスのプロトコルスタック図である。図４に示すように、無線インターフェイスプロトコルは、ＯＳＩ参照モデルの第１層乃至第３層に区分されており、第１層は物理（ＰＨＹ）層である。第２層は、ＭＡＣ（Ｍｅｄｉｕｍ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ）層、ＲＬＣ（Ｒａｄｉｏ  Ｌｉｎｋ  Ｃｏｎｔｒｏｌ）層、及びＰＤＣＰ（Ｐａｃｋｅｔ  Ｄａｔａ  Ｃｏｎｖｅｒｇｅｎｃｅ  Ｐｒｏｔｏｃｏｌ）層を含む。第３層は、ＲＲＣ（Ｒａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ）層を含む。
【００３２】
物理層は、符号化・復号、変調・復調、アンテナマッピング・デマッピング、及びリソースマッピング・デマッピングを行う。ＵＥ１００の物理層とｅＮＢ２００の物理層との間では、物理チャネルを介してデータ及び制御情報が伝送される。
【００３３】
ＭＡＣ層は、データの優先制御、ハイブリッドＡＲＱ（ＨＡＲＱ）による再送処理、及びランダムアクセス手順等を行う。ＵＥ１００のＭＡＣ層とｅＮＢ２００のＭＡＣ層との間では、トランスポートチャネルを介してデータ及び制御情報が伝送される。ｅＮＢ２００のＭＡＣ層は、上下リンクのトランスポートフォーマット（トランスポートブロックサイズ、変調・符号化方式（ＭＣＳ））及びＵＥ１００への割当リソースブロックを決定するスケジューラを含む。
【００３４】
ＲＬＣ層は、ＭＡＣ層及び物理層の機能を利用してデータを受信側のＲＬＣ層に伝送する。ＵＥ１００のＲＬＣ層とｅＮＢ２００のＲＬＣ層との間では、論理チャネルを介してデータ及び制御情報が伝送される。
【００３５】
ＰＤＣＰ層は、ヘッダ圧縮・伸張、及び暗号化・復号化を行う。
【００３６】
ＲＲＣ層は、制御情報を取り扱う制御プレーンでのみ定義される。ＵＥ１００のＲＲＣ層とｅＮＢ２００のＲＲＣ層との間では、各種設定のためのメッセージ（ＲＲＣメッセージ）が伝送される。ＲＲＣ層は、無線ベアラの確立、再確立及び解放に応じて、論理チャネル、トランスポートチャネル、及び物理チャネルを制御する。ＵＥ１００のＲＲＣとｅＮＢ２００のＲＲＣとの間に接続（ＲＲＣ接続）がある場合、ＵＥ１００はＲＲＣコネクティッドモードであり、そうでない場合、ＵＥ１００はＲＲＣアイドルモードである。
【００３７】
ＲＲＣ層の上位に位置するＮＡＳ（Ｎｏｎ−Ａｃｃｅｓｓ  Ｓｔｒａｔｕｍ）層は、セッション管理及びモビリティ管理等を行う。
【００３８】
ＵＥ１００は、無線インターフェイスプロトコルの上位のプロトコルとしてＯＳＩ参照モデルの第４層乃至第７層を有する。第４層であるトランスポート層は、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）を含む。ＴＣＰについては後述する。
【００３９】
（５）ＬＴＥ下位層の概要
図５は、ＬＴＥシステムにおいて用いられる無線フレームの構成図である。ＬＴＥシステムは、下りリンクにはＯＦＤＭＡ（Ｏｒｔｈｏｇｏｎａｌ  Ｆｒｅｑｕｅｎｃｙ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅ  Ａｃｃｅｓｓ）、上りリンクにはＳＣ−ＦＤＭＡ（Ｓｉｎｇｌｅ  Ｃａｒｒｉｅｒ  Ｆｒｅｑｕｅｎｃｙ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅ  Ａｃｃｅｓｓ）がそれぞれ適用される。
【００４０】
図５に示すように、無線フレームは、時間方向に並ぶ１０個のサブフレームで構成される。各サブフレームは、時間方向に並ぶ２個のスロットで構成される。各サブフレームの長さは１ｍｓであり、各スロットの長さは０．５ｍｓである。各サブフレームは、周波数方向に複数個のリソースブロック（ＲＢ）を含み、時間方向に複数個のシンボルを含む。各リソースブロックは、周波数方向に複数個のサブキャリアを含む。１つのシンボル及び１つのサブキャリアにより１つのリソースエレメント（ＲＥ）が構成される。また、ＵＥ１００に割り当てられる無線リソース（時間・周波数リソース）のうち、周波数リソースはリソースブロックにより特定でき、時間リソースはサブフレーム（又はスロット）により特定できる。
【００４１】
下りリンクにおいて、各サブフレームの先頭数シンボルの区間は、主に下りリンク制御情報を伝送するための物理下りリンク制御チャネル（ＰＤＣＣＨ）、及び、ＨＡＲＱ  ＡＣＫ／ＮＡＣＫを伝送するための物理ＨＡＲＱインジケータチャネル（ＰＨＩＣＨ）として用いられる領域である。 また、各サブフレームの残りの部分は、主に下りリンクデータを伝送するための物理下りリンク共有チャネル（ＰＤＳＣＨ）として用いることができる領域である。
【００４２】
ｅＮＢ２００は、基本的には、ＰＤＣＣＨを用いて下りリンク制御情報（ＤＣＩ）をＵＥ１００に送信し、ＰＤＳＣＨを用いて下りリンクデータをＵＥ１００に送信する。ＰＤＣＣＨが搬送する下りリンク制御情報は、上りリンクスケジューリング情報、下りリンクスケジューリング情報、ＴＰＣコマンドを含む。上りリンクスケジューリング情報は上りリンク無線リソースの割当てに関するスケジューリング情報（ＵＬ  ｇｒａｎｔ）であり、下りリンクスケジューリング情報は、下りリンク無線リソースの割当てに関するスケジューリング情報である。ＴＰＣコマンドは、上りリンクの送信電力の増減を指示する情報である。ｅＮＢ２００は、下りリンク制御情報の送信先のＵＥ１００を識別するために、送信先のＵＥ１００の識別子（ＲＮＴＩ：Ｒａｄｉｏ  Ｎｅｔｗｏｒｋ  Ｔｅｍｐｏｒａｒｙ  ＩＤ）でスクランブリングしたＣＲＣビットを下りリンク制御情報に含める。各ＵＥ１００は、自ＵＥ宛ての可能性がある下りリンク制御情報について、自ＵＥのＲＮＴＩでデスクランブリング後、ＣＲＣチェックをすることにより、ＰＤＣＣＨをブラインド復号（Ｂｌｉｎｄ  ｄｅｃｏｄｉｎｇ）し、自ＵＥ宛の下りリンク制御情報を検出する。ＰＤＳＣＨは、下りリンクスケジューリング情報が示す下りリンク無線リソース（リソースブロック）により下りリンクデータを搬送する。
【００４３】
上りリンクにおいて、各サブフレームにおける周波数方向の両端部は、主に上りリンク制御情報を伝送するための物理上りリンク制御チャネル（ＰＵＣＣＨ）として用いられる領域である。各サブフレームにおける残りの部分は、主に上りリンクデータを伝送するための物理上りリンク共有チャネル（ＰＵＳＣＨ）として用いることができる領域である。
【００４４】
ＵＥ１００は、基本的には、ＰＵＣＣＨを用いて上りリンク制御情報（ＵＣＩ）をｅＮＢ２００に送信し、ＰＵＳＣＨを用いて上りリンクデータをｅＮＢ２００に送信する。ＰＵＣＣＨが運搬する上りリンク制御情報は、ＣＱＩ（Ｃｈａｎｎｅｌ  Ｑｕａｌｉｔｙ  Ｉｎｄｉｃａｔｏｒ）、ＰＭＩ（Ｐｒｅｃｏｄｉｎｇ  Ｍａｔｒｉｘ  Ｉｎｄｉｃａｔｏｒ）、ＲＩ（Ｒａｎｋ  Ｉｎｄｉｃａｔｏｒ）、スケジューリング要求（ＳＲ）、ＨＡＲＱ  ＡＣＫ／ＮＡＣＫを含む。ＣＱＩは、下りリンクのチャネル品質を示すインデックスであり、下りリンク伝送に用いるべきＭＣＳの決定等に用いられる。ＰＭＩは、下りリンクの伝送のために用いることが望ましいプレコーダマトリックスを示すインデックスである。ＲＩは、下りリンクの伝送に用いることが可能なレイヤ数（ストリーム数）を示すインデックスである。ＳＲは、ＰＵＳＣＨリソースの割り当てを要求する情報である。ＨＡＲＱ  ＡＣＫ／ＮＡＣＫは、下りリンクデータを正しく受信したか否かを示す送達確認情報である。
【００４５】
（６）ＳＲの概要
ＵＥ１００は、ＰＵＳＣＨリソースを要求するためのＳＲを、ＰＵＣＣＨリソースを用いてｅＮＢ２００に送信する。ｅＮＢ２００は、ＳＲの受信に応じて、ＵＥ１００にＰＵＳＣＨリソースを割り当てる（すなわち、ＵＥ１００に「ＵＬ  ｇｒａｎｔ」を送信する）。
【００４６】
ＵＥ１００は、ｅＮＢ２００からＲＲＣシグナリングにより設定されるＰＵＣＣＨパラメータであるＮ(1)PUCCH,SRIに従って、ＳＲの送信用のＰＵＣＣＨリソースを決定する。当該パラメータは、ＵＥ固有のパラメータである。
【００４７】
また、ＳＲの送信周期（ＳＲ  ｐｅｒｉｏｄｉｃｉｔｙ）及びサブフレームオフセット（ＳＲ  ｓｕｂｆｒａｍｅ  ｏｆｆｓｅｔ）を含むＳＲ設定（ＳＲ  ｃｏｎｆｉｇｕｒａｔｉｏｎ）は、ｅＮＢ２００からＵＥ１００にＲＲＣシグナリングにより設定されるパラメータである「ＳＲ  ｃｏｎｆｉｇｕｒａｔｉｏｎ  ｉｎｄｅｘ」により定められる。当該パラメータは、ＵＥ固有のパラメータである。「ＳＲ  ｃｏｎｆｉｇｕｒａｔｉｏｎ」の一例を表１に示す。
【００４８】
【表１】
2016185896.tif 000003
【００４９】
表１の例において、ＳＲの送信用のＰＵＣＣＨリソースの周期（ＳＲ  ｐｅｒｉｏｄｉｃｉｔｙ）は、１［ｍｓ］乃至８０［ｍｓ］の範囲内である。
【００５０】
ＵＥ１００は、例えば下記の式（１）を満たす各サブフレームにおいてＳＲを送信可能である。
【００５１】
【数１】
2016185896.tif 000004
【００５２】
但し、「ｎf」はシステムフレーム番号（無線フレーム番号）であり、「ｎS」はフレーム内のスロット番号（０番乃至１９番）であり、「ＮOFFSET,SR」はサブフレームオフセット（ＳＲ  ｓｕｂｆｒａｍｅ  ｏｆｆｓｅｔ）であり、「ＳＲPERIODICITY」はＳＲ周期（ＳＲ  ｐｅｒｉｏｄｉｃｉｔｙ）である。
【００５３】
（７）ＢＳＲの概要
ＵＥ１００は、ｅＮＢ２００から割り当てられたＰＵＳＣＨリソースを用いて、ＢＳＲをｅＮＢ２００に送信する。ＢＳＲは、ＵＥ１００の送信バッファ（ＵＬバッファ）内の上りリンクデータの量を示すバッファ情報（Ｂｕｆｆｅｒ  Ｓｉｚｅ）を含む。ＢＳＲは、ＵＥ１００のＭＡＣ層からｅＮＢ２００のＭＡＣ層に送信されるＭＡＣ制御要素の一種である。ＢＳＲ  ＭＡＣ制御要素は、第１のフォーマット及び第２のフォーマットをサポートする。第１のフォーマットは、「Ｓｈｏｒｔ  ＢＳＲ」及び「Ｔｒｕｎｃａｔｅｄ  ＢＳＲ」の送信に用いられる。第２のフォーマットは、「Ｌｏｎｇ  ＢＳＲ」の送信に用いられる。
【００５４】
図６は、ＢＳＲ  ＭＡＣ制御要素を説明するための図である。
【００５５】
図６（Ａ）に示すように、ＢＳＲ  ＭＡＣ制御要素の第１のフォーマットは、１つの「ＬＣＧ  ＩＤ」フィールド及び１つの「Ｂｕｆｆｅｒ  Ｓｉｚｅ」フィールドからなる。「ＬＣＧ  ＩＤ」は、論理チャネルのグループを識別するＩＤであり、２ビットのビット長を有する。「Ｂｕｆｆｅｒ  Ｓｉｚｅ」は、「ＬＣＧ  ＩＤ」に対応するグループ内の全ての論理チャネルのデータ量を示すインデックスであり、６ビットのビット長を有する。インデックスとデータ量（バッファサイズ値）との対応関係の一例を表２に示す。
【００５６】
【表２】
2016185896.tif 000005
【００５７】
図６（Ｂ）に示すように、ＢＳＲ  ＭＡＣ制御要素の第２のフォーマットは、４つの「Ｂｕｆｆｅｒ  Ｓｉｚｅ」フィールドからなる。「Ｂｕｆｆｅｒ  Ｓｉｚｅ」フィールドは、「ＬＣＧ  ＩＤ  ＃０」乃至「ＬＣＧ  ＩＤ  ＃３」に対応して設けられる。ＢＳＲ  ＭＡＣ制御要素の第２のフォーマットによれば、１つのＢＳＲで４つの「ＬＣＧ  ＩＤ」の各データ量を示すことができる。
【００５８】
（８）ＴＣＰの概要
図７は、ＴＣＰの概要を説明するための図である。実施形態において、ＵＥ１００は、ＬＴＥシステムのネットワークを介して、インターネット上のサーバとのＴＣＰ通信を行う。
【００５９】
図７に示すように、サーバは、ＵＥ１００からの「ＴＣＰ  ＡＣＫ」に基づいてネットワークの混雑状況を判断する。サーバは、「ＴＣＰ  ＡＣＫ」の受信に応じて、ウィンドウサイズを徐々に増加させる。ウィンドウサイズとは、「ＴＣＰ  ＡＣＫ」を待たずに連続的に送信する「ＴＣＰ  Ｓｅｇｍｅｎｔ」の量である。一方、サーバは、「ＴＣＰ  ＡＣＫ」の受信に失敗（タイムアウト）した場合、ウィンドウサイズを半減させる。このような制御は「スロースタート」と称される。
【００６０】
よって、ＬＴＥシステムの下りリンクが混雑していない場合でも、ＵＥ１００が上りリンクにおいて「ＴＣＰ  ＡＣＫ」を速やかに送信しなければ、下りリンクのＴＣＰスループットを高めることができない。すなわち、ＵＥ１００において「ＴＣＰ  ＡＣＫ」を生成してから「ＴＣＰ  ＡＣＫ」をｅＮＢ２００に送信完了するまでの遅延時間（上りリンクのレイテンシ）を短縮できれば、下りリンクのＴＣＰスループットを高めることができる。ここで、「ＴＣＰ  ＡＣＫ」をＵＥ１００からｅＮＢ２００に送信するためには、ｅＮＢ２００からＵＥ１００に適切な量の上りリンクリソース（具体的には、ＰＵＳＣＨリソース）を割り当てることが必要である。
【００６１】
（９）一般的なランダムアクセス手順及び上りリンクの送信手順
以下において、一般的なランダムアクセス手順及び上りリンクの送信手順について説明する。図８は、一般的なランダムアクセス手順及び上りリンクの送信手順を示すシーケンス図である。図８の初期状態において、ＵＥ１００は、ＲＲＣコネクティッドモード又はＲＲＣアイドルモードである。
【００６２】
図８に示すように、ＲＲＣコネクティッドモードのＵＥ１００は、上りリンク同期状態が非同期（Ｎｏｎ−ｓｙｎｃｈｒｏｎｉｓｅｄ）である場合、上りリンク送信を行うために、ランダムアクセス手順（ステップＳ１）を行う。また、ＲＲＣアイドルモードのＵＥ１００は、初期接続（Ｉｎｉｔｉａｌ  ａｃｃｅｓｓ）を行うために、ランダムアクセス手順（ステップＳ１）を行う。ＵＥ１００は、ランダムアクセス手順（ステップＳ１）の終了後に、上りリンクの送信手順（ステップＳ２）を行うことにより、上りリンクデータ（ＵＬデータ）をｅＮＢ２００に送信する。
【００６３】
具体的には、ステップＳ１−１において、ＵＥ１００は、ランダムアクセス手順の第１の処理として、ランダムアクセスプリアンブル（ＲＡ  Ｐｒｅａｍｂｌｅ）をＰＲＡＣＨ上でｅＮＢ２００に送信する。「ＲＡ  Ｐｒｅａｍｂｌｅ」は、Ｍｓｇ１と称されることがある。「ＲＡ  Ｐｒｅａｍｂｌｅ」は、ＭＡＣ層においてＵＥ１００からｅＮＢ２００へのランダムアクセスを行うための信号である。ｅＮＢ２００は、「ＲＡ  Ｐｒｅａｍｂｌｅ」を受信する。
【００６４】
ステップＳ１−２において、ｅＮＢ２００は、ランダムアクセス手順の第２の処理として、ＤＬ−ＳＣＨ上でランダムアクセス応答（ＲＡ  Ｒｅｓｐｏｎｓｅ）をＵＥ１００に送信する。「ＲＡ  Ｒｅｓｐｏｎｓｅ」は、ＭＡＣ制御要素（ＭＡＣ  ＣＥ）の一種であり、Ｍｓｇ２と称されることがある。具体的には、ｅＮＢ２００は、ＵＥ１００から受信した「ＲＡ  Ｐｒｅａｍｂｌｅ」に基づいて、ＵＥ１００との間の上りリンク遅延を推定する。また、ｅＮＢ２００は、ＵＥ１００に割り当てる上りリンク無線リソースを決定する。そして、ｅＮＢ２００は、遅延推定の結果に基づくタイミング補正値（ＴＡ：Ｔｉｍｉｎｇ  Ａｄｖａｎｃｅ）、無線リソースの割り当て情報（ＵＬ  ｇｒａｎｔ）、プリアンブル識別子（Ｐｒｅａｍｂｌｅ  ＩＤ）、及び「Ｔｅｍｐｏｒａｒｙ  Ｃ−ＲＮＴＩ」を含む「ＲＡ  Ｒｅｓｐｏｎｓｅ」をＵＥ１００に送信する。なお、「Ｐｒｅａｍｂｌｅ  ＩＤ」は、ＵＥ１００から受信した「ＲＡ  Ｐｒｅａｍｂｌｅ」の信号系列を示すＩＤである。また、物理層（ＰＤＣＣＨ）において、「ＲＡ  Ｒｅｓｐｏｎｓｅ」の送信には専用のＲＮＴＩ（ＲＡ−ＲＮＴＩ）が用いられる。ＵＥ１００は、「ＲＡ  Ｒｅｓｐｏｎｓｅ」を受信する。
【００６５】
ステップＳ１−３において、ＵＥ１００は、ランダムアクセス手順の第３の処理として、「ＲＡ  Ｒｅｓｐｏｎｓｅ」に基づいてＵＬ−ＳＣＨ上でｅＮＢ２００に上りリンク送信（Ｓｃｈｅｄｕｌｅｄ  Ｔｒａｎｓｍｉｓｓｉｏｎ）を行う。「Ｓｃｈｅｄｕｌｅｄ  Ｔｒａｎｓｍｉｓｓｉｏｎ」は、Ｍｓｇ３と称されることがある。初期接続（Ｉｎｉｔｉａｌ  ａｃｃｅｓｓ）の場合、「Ｓｃｈｅｄｕｌｅｄ  Ｔｒａｎｓｍｉｓｓｉｏｎ」は、「ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔ」メッセージである。それ以外の場合（すなわち、ＵＥ１００にＣ−ＲＮＴＩが割り当てられている場合）、「Ｓｃｈｅｄｕｌｅｄ  Ｔｒａｎｓｍｉｓｓｉｏｎ」は、ＵＥ１００のＣ−ＲＮＴＩを含むメッセージである。ｅＮＢ２００は、「Ｓｃｈｅｄｕｌｅｄ  Ｔｒａｎｓｍｉｓｓｉｏｎ」を受信する。
【００６６】
ステップＳ１−４において、ｅＮＢ２００は、ランダムアクセス手順の第３の処理として、競合解決（Ｃｏｎｔｅｎｔｉｏｎ  Ｒｅｓｏｌｕｔｉｏｎ）メッセージをＵＥ１００に送信する。「Ｃｏｎｔｅｎｔｉｏｎ  Ｒｅｓｏｌｕｔｉｏｎ」メッセージは、Ｍｓｇ４と称されることがある。「Ｃｏｎｔｅｎｔｉｏｎ  Ｒｅｓｏｌｕｔｉｏｎ」メッセージは、ステップＳ１−３でＵＥ１００から受信したメッセージの内容を含む。初期接続（Ｉｎｉｔｉａｌ  ａｃｃｅｓｓ）の場合、物理層（ＰＤＣＣＨ）において、「Ｃｏｎｔｅｎｔｉｏｎ  Ｒｅｓｏｌｕｔｉｏｎ」メッセージの送信には「Ｔｅｍｐｏｒａｒｙ  Ｃ−ＲＮＴＩ」が用いられる。ＵＥ１００にＣ−ＲＮＴＩが割り当てられている場合、物理層（ＰＤＣＣＨ）において、「Ｃｏｎｔｅｎｔｉｏｎ  Ｒｅｓｏｌｕｔｉｏｎ」メッセージの送信には「Ｃ−ＲＮＴＩ」が用いられる。ＵＥ１００は、「Ｃｏｎｔｅｎｔｉｏｎ  Ｒｅｓｏｌｕｔｉｏｎ」メッセージを受信する。
【００６７】
このように、ランダムアクセス手順（ステップＳ１）は、ステップＳ１−１乃至Ｓ１−４からなる。次に、上りリンクの送信手順（ステップＳ２）について説明する。
【００６８】
ステップＳ２−１において、ＵＥ１００は、ＰＵＳＣＨリソースの割り当てを要求するためのＳＲを、ＰＵＣＣＨ上でｅＮＢ２００に送信する。
【００６９】
ステップＳ２−２において、ｅＮＢ２００は、ＳＲの受信に応じて、ＵＥ１００にＰＵＳＣＨリソースを割り当てる。具体的には、ｅＮＢ２００は、上りリンクのスケジューリング情報（ＵＬ  ｇｒａｎｔ）を含むＤＣＩをＰＤＣＣＨ上でＵＥ１００に送信する。
【００７０】
ステップＳ２−３において、ＵＥ１００は、ｅＮＢ２００から割り当てられたＰＵＳＣＨリソースを用いて、ＵＥ１００の送信バッファ内の上りリンクデータの量を示すバッファ情報を含むＢＳＲをｅＮＢ２００に送信する。
【００７１】
ステップＳ２−４において、ｅＮＢ２００は、ＢＳＲの受信に応じて、適切な量のＰＵＳＣＨリソースをＵＥ１００に割り当てる。具体的には、ｅＮＢ２００は、上りリンクのスケジューリング情報（ＵＬ  ｇｒａｎｔ）を含むＤＣＩをＰＤＣＣＨ上でＵＥ１００に送信する。
【００７２】
ステップＳ２−５において、ＵＥ１００は、ｅＮＢ２００から割り当てられたＰＵＳＣＨリソースを用いて、ＵＥ１００の送信バッファ内の上りリンクデータ（例えば、ＴＣＰ  ＡＣＫパケット）をｅＮＢ２００に送信する。
【００７３】
このように、上りリンクの送信手順（ステップＳ２）は、ステップＳ２−１乃至Ｓ２−５からなる。
【００７４】
しかしながら、ランダムアクセス手順（ステップＳ１）の後に上りリンクの送信手順（ステップＳ２）を行う方法には、上りリンクのレイテンシを低減する、すなわち高速上りリンクアクセスを可能とする点において改善の余地がある。
【００７５】
（１０）実施形態に係るランダムアクセス手順
以下において、実施形態に係るランダムアクセス手順について説明する。
【００７６】
（１０．１）パターン１
図９は、実施形態に係るランダムアクセス手順のパターン１を示すシーケンス図である。ここでは、図８との相違点を主として説明する。
【００７７】
図９に示すように、ステップＳ１１において、ＵＥ１００は、ランダムアクセス手順の第１の処理として、ランダムアクセスプリアンブル（ＲＡ  Ｐｒｅａｍｂｌｅ）をＰＲＡＣＨ上でｅＮＢ２００に送信する。ＵＥ１００は、第１の処理において、報告（ＢＳＲ）をｅＮＢ２００に送信するための無線リソースの割り当てをｅＮＢ２００に要求する。例えば、ＵＥ１００は、特定の信号系列又はリソース（Ｓｐｅｃｉｆｉｃ  ｓｅｑｕｅｎｃｅ／ｒｅｓｏｕｒｃｅ）により特別な「ＲＡ  Ｐｒｅａｍｂｌｅ」を送信する。ここで、特定の信号系列とは、例えば特定のプリアンブルグループに属する信号系列である。特定のリソースとは、例えば特定の「ＰＲＡＣＨ  Ｍａｓｋ  Ｉｎｄｅｘ」である。このような特別な「ＲＡ  Ｐｒｅａｍｂｌｅ」は、高速上りリンクアクセス用の「ＲＡ  Ｐｒｅａｍｂｌｅ」とみなすこともできる。具体的には、特別な「ＲＡ  Ｐｒｅａｍｂｌｅ」は、ＳＲの機能が追加された「ＲＡ  Ｐｒｅａｍｂｌｅ」である。ｅＮＢ２００は、特別な「ＲＡ  Ｐｒｅａｍｂｌｅ」を受信する。
【００７８】
ステップＳ１２において、ｅＮＢ２００は、ランダムアクセス手順の第２の処理として、ＤＬ−ＳＣＨ上でランダムアクセス応答（ＲＡ  Ｒｅｓｐｏｎｓｅ）をＵＥ１００に送信する。「ＲＡ  Ｒｅｓｐｏｎｓｅ」に含まれる情報は、一般的なランダムアクセス手順において「ＲＡ  Ｒｅｓｐｏｎｓｅ」に含まれる情報と同様である。但し、実施形態において、ｅＮＢ２００は、特別な「ＲＡ  Ｐｒｅａｍｂｌｅ」の受信に応じて、通常の「Ｓｃｈｅｄｕｌｅｄ  Ｔｒａｎｓｍｉｓｓｉｏｎ」用の無線リソースだけではなく、ＢＳＲ送信用の無線リソースもＵＥ１００に割り当て、これらの無線リソースを示す割り当て情報（ＵＬ  ｇｒａｎｔ）を「ＲＡ  Ｒｅｓｐｏｎｓｅ」に含める。ＵＥ１００は、「ＲＡ  Ｒｅｓｐｏｎｓｅ」を受信する。
【００７９】
ステップＳ１３において、ＵＥ１００は、ランダムアクセス手順の第３の処理として、「ＲＡ  Ｒｅｓｐｏｎｓｅ」に基づいてＵＬ−ＳＣＨ上でｅＮＢ２００に上りリンク送信（Ｓｃｈｅｄｕｌｅｄ  Ｔｒａｎｓｍｉｓｓｉｏｎ）を行う。ＵＥ１００は、第３の処理において、ＢＳＲをｅＮＢ２００に送信することにより、ＵＥ１００の送信バッファ内の上りリンクデータの量をｅＮＢ２００に通知する。ｅＮＢ２００は、「Ｓｃｈｅｄｕｌｅｄ  Ｔｒａｎｓｍｉｓｓｉｏｎ」と共にＢＳＲをＵＥ１００から受信する。
【００８０】
ステップＳ１４において、ｅＮＢ２００は、ランダムアクセス手順の第３の処理として、競合解決（Ｃｏｎｔｅｎｔｉｏｎ  Ｒｅｓｏｌｕｔｉｏｎ）メッセージをＵＥ１００に送信する。ここで、ｅＮＢ２００は、ＢＳＲの受信に応じて、上りリンクデータ（ＵＬ  ｄａｔａ）を送信するための無線リソース（ＰＵＳＣＨリソース）をＵＥ１００に割り当て、当該無線リソースを示す割り当て情報（ＵＬ  ｇｒａｎｔ）をＰＤＣＣＨ上でＵＥ１００に送信する。ＵＥ１００は、「Ｃｏｎｔｅｎｔｉｏｎ  Ｒｅｓｏｌｕｔｉｏｎ」メッセージと共に「ＵＬ  ｇｒａｎｔ」をｅＮＢ２００から受信する。
【００８１】
ステップＳ１５において、ＵＥ１００は、上りリンクデータ（ＵＬ  ｄａｔａ）を送信するための「ＵＬ  ｇｒａｎｔ」をｅＮＢ２００から受信したことに応じて、ランダムアクセス手順が終了するとともに上りリンクデータをｅＮＢ２００に送信する。ｅＮＢ２００は、ランダムアクセス手順が終了するとともに上りリンクデータをＵＥ１００から受信する。
【００８２】
このように、実施形態に係るランダムアクセス手順によれば、ＵＥ１００がランダムアクセス手順の過程でＳＲと同様な情報及びＢＳＲをｅＮＢ２００に送信することができる。このため、ＵＥ１００がランダムアクセス手順の後にＳＲ及びＢＳＲをｅＮＢ２００に送信することなく、直ちに上りリンクデータをｅＮＢ２００に送信することができる。具体的には、図９に示すシーケンスによれば、図８のステップＳ２−１乃至Ｓ２−４を省略することができる。従って、実施形態に係るランダムアクセス手順によれば、高速上りリンクアクセスを可能とすることができる。
【００８３】
（１０．２）パターン２
図１０は、実施形態に係るランダムアクセス手順のパターン２を示すシーケンス図である。ここでは、図８との相違点を主として説明する。パターン２は、パターン１のシーケンスの一部を簡略化したパターンである。
【００８４】
図１０に示すように、本パターンのステップＳ２１及びＳ２２は、図８に示す一般的なランダムアクセス手順と同様である。
【００８５】
ステップＳ２３において、ＵＥ１００は、ランダムアクセス手順の第３の処理として、「ＲＡ  Ｒｅｓｐｏｎｓｅ」に基づいてＵＬ−ＳＣＨ上でｅＮＢ２００に上りリンク送信（Ｓｃｈｅｄｕｌｅｄ  Ｔｒａｎｓｍｉｓｓｉｏｎ）を行う。ＵＥ１００は、第３の処理において、ＢＳＲをｅＮＢ２００に送信することにより、ＵＥ１００の送信バッファ内の上りリンクデータの量をｅＮＢ２００に通知する。ここで送信されるＢＳＲは、一般的なＢＳＲに比べてラフなＢＳＲ（Ｒｏｕｇｈ  ＢＳＲ）であり、一般的なＢＳＲに比べてビット長が短い。例えば、上りリンクデータ量（バッファサイズ）を２ビットのインデックスで表現する場合、インデックス「００」は「１００バイト未満」を表し、インデックス「０１」は「１００バイト以上５００バイト未満」を表し、インデックス「１０」は「５００バイト以上５００ｋバイト未満」を表し、インデックス「１１」は「５００ｋバイト以上１Ｍバイト未満」を表す。或いは、インデックスは、表２に示したようなＢＳＲテーブルを指定するものでもよい。例えば、インデックス「００」はＢＳＲテーブル中の「Ｉｎｄｅｘ  ０〜１５」を表し、インデックス「０１」はＢＳＲテーブル中の「Ｉｎｄｅｘ  １６〜３１」を表し、インデックス「１０」はＢＳＲテーブル中の「Ｉｎｄｅｘ  ３２〜４７」を表し、インデックス「１１」はＢＳＲテーブル中の「Ｉｎｄｅｘ  ４８〜６３」を表す。なお、ここではＢＳＲテーブルを４等分する一例を示したが、４等分に限定されない。ｅＮＢ２００は、「Ｓｃｈｅｄｕｌｅｄ  Ｔｒａｎｓｍｉｓｓｉｏｎ」と共に「Ｒｏｕｇｈ  ＢＳＲ」をＵＥ１００から受信する。
【００８６】
ステップＳ２４において、ｅＮＢ２００は、ランダムアクセス手順の第３の処理として、競合解決（Ｃｏｎｔｅｎｔｉｏｎ  Ｒｅｓｏｌｕｔｉｏｎ）メッセージをＵＥ１００に送信する。ここで、ｅＮＢ２００は、「Ｒｏｕｇｈ  ＢＳＲ」の受信に応じて、上りリンクデータ（ＵＬ  ｄａｔａ）を送信するための無線リソース（ＰＵＳＣＨリソース）をＵＥ１００に割り当て、当該無線リソースを示す割り当て情報（ＵＬ  ｇｒａｎｔ）をＰＤＣＣＨ上でＵＥ１００に送信する。ＵＥ１００は、「Ｃｏｎｔｅｎｔｉｏｎ  Ｒｅｓｏｌｕｔｉｏｎ」メッセージと共に「ＵＬ  ｇｒａｎｔ」をｅＮＢ２００から受信する。
【００８７】
ステップＳ２５において、ＵＥ１００は、上りリンクデータ（ＵＬ  ｄａｔａ）を送信するための「ＵＬ  ｇｒａｎｔ」をｅＮＢ２００から受信したことに応じて、ランダムアクセス手順が終了するとともに上りリンクデータをｅＮＢ２００に送信する。ｅＮＢ２００は、ランダムアクセス手順が終了するとともに上りリンクデータをＵＥ１００から受信する。
【００８８】
（１０．３）パターン３
図１１は、実施形態に係るランダムアクセス手順のパターン３を示すシーケンス図である。ここでは、図８との相違点を主として説明する。パターン３は、主として初期接続（Ｉｎｉｔｉａｌ  ａｃｃｅｓｓ）を対象としたパターンである。図１１の初期状態において、ＵＥ１００は、ＲＲＣコネクティッドモードである。
【００８９】
図１１に示すように、ステップＳ３０において、ＵＥ１００は、ｅＮＢ２００とのＲＲＣ接続を解放するための「ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｌｅａｓｅ」メッセージをｅＮＢ２００から受信し、ＲＲＣアイドルモードに遷移する。「ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｌｅａｓｅ」メッセージは、高速上りリンクアクセス（Ｆａｓｔ  Ｕｐｌｉｎｋ  Ａｃｃｅｓｓ）の設定情報（Ｃｏｎｆｉｇｕｒａｔｉｏｎ）を含む。ＵＥ１００は、当該Ｃｏｎｆｉｇｕｒａｔｉｏｎを記憶する。当該Ｃｏｎｆｉｇｕｒａｔｉｏｎは、当該Ｃｏｎｆｉｇｕｒａｔｉｏｎの適用有無を示すフラグや当該Ｃｏｎｆｉｇｕｒａｔｉｏｎの有効時間を示すタイマ値を含む。若しくは、当該Ｃｏｎｆｉｇｕｒａｔｉｏｎにより特別なランダムアクセスプリアンブルを指定してもよい。
【００９０】
ステップＳ３１において、ＵＥ１００は、記憶しているＣｏｎｆｉｇｕｒａｔｉｏｎに基づいて、ランダムアクセス手順の第１の処理として、ランダムアクセスプリアンブル（ＲＡ  Ｐｒｅａｍｂｌｅ）をＰＲＡＣＨ上でｅＮＢ２００に送信する。ＵＥ１００は、第１の処理において、特別な「ＲＡ  Ｐｒｅａｍｂｌｅ」を送信する。以降の動作（ステップＳ３２乃至Ｓ３５）は、パターン１と同様であるが、初期接続（Ｉｎｉｔｉａｌ  ａｃｃｅｓｓ）用の動作に従う。
【００９１】
（１１）実施形態のまとめ
実施形態に係るランダムアクセス手順によれば、ＵＥ１００がランダムアクセス手順の過程で上りリンクのデータ量（バッファサイズ）をｅＮＢ２００に通知することができる。このため、ＵＥ１００がランダムアクセス手順の後にＢＳＲをｅＮＢ２００に送信することなく、直ちに上りリンクデータをｅＮＢ２００に送信することができる。従って、高速上りリンクアクセスを可能とすることができる。
【００９２】
［その他の実施形態］
上述した実施形態において、ＵＥがバッファしているデータ量を示す情報としてＢＳＲを例示したが、これに限定されない。ＵＥ内でバッファしている上りリンクデータを示す量が適用されてもよい。例えば、アプリケーション層も含めたＵＥの各レイヤがバッファしているデータ量を通知してもよい。
【００９３】
上述した実施形態において、ＵＥ１００は、ランダムアクセス手順の第３の処理（Ｓｃｈｅｄｕｌｅｄ  Ｔｒａｎｓｍｉｓｓｉｏｎ）において上りリンクのデータ量（バッファサイズ）をｅＮＢ２００に通知していた。しかしながら、ＵＥ１００は、ランダムアクセス手順の第１の処理（ＲＡ  Ｐｒｅａｍｂｌｅ）において上りリンクのデータ量（バッファサイズ）をｅＮＢ２００に通知してもよい。例えば、「ＲＡ  Ｐｒｅａｍｂｌｅ」の信号系列（ｓｅｑｕｅｎｃｅ）及びリソース（ＰＲＡＣＨ  Ｍａｓｋ  Ｉｎｄｅｘ）の組み合わせに対してバッファサイズを対応付ける。このような対応付けは、例えば仕様により予め規定される。ＵＥ１００は、バッファサイズに応じて信号系列（ｓｅｑｕｅｎｃｅ）及びリソース（ＰＲＡＣＨ  Ｍａｓｋ  Ｉｎｄｅｘ）の組み合わせを選択し、選択した組み合わせを用いて「ＲＡ  Ｐｒｅａｍｂｌｅ」をｅＮＢ２００に送信する。ｅＮＢ２００は、ＵＥ１００から受信した「ＲＡ  Ｐｒｅａｍｂｌｅ」に適用されている信号系列（ｓｅｑｕｅｎｃｅ）及びリソース（ＰＲＡＣＨ  Ｍａｓｋ  Ｉｎｄｅｘ）の組み合わせに基づいてバッファサイズを特定することができる。
【００９４】
上述した実施形態において、移動通信システムとしてＬＴＥシステムを例示した。しかしながら、本発明はＬＴＥシステムに限定されない。ＬＴＥシステム以外のシステムに本発明を適用してもよい。
【００９５】
［付記］
（１．はじめに）
ＬＴＥのためのレイテンシ低減技術に関する新たな研究項目が承認された。この研究の目的は、以下のように、パケットデータレイテンシを低減するために２つの技術分野を識別する。
【００９６】
・高速アップリンクアクセス解決策［ＲＡＮ２］：
・ＴＴＩショートニングおよび低減された処理時間［ＲＡＮ１］：
高速上りリンクアクセス解決策は、現在のＴＴＩ長さおよび処理時間、すなわちＴＴＩショートニングを維持することを備えたいくつかの実施技術、および、備えていないいくつかの実施技術と比較して、リソース効率を改善することが期待されている。
【００９７】
本付記では、高速上りリンクアクセス解決策に関する研究に対する初期検討が提供される。
【００９８】
（２．議論）
（２．１．作業仮説）
本研究のモチベーション文書は、上りリンクリソース割当のための現在の標準化されたメカニズムが、ＴＣＰスループットの観点から、ＬＴＥの潜在的なスループットパフォーマンスを圧迫することを示している。ＴＣＰスループットの低下は、往復時間レイテンシ、すなわちＵＬにおけるＴＣＰ−ＡＣＫ送信によるＴＣＰスロースタートアルゴリズムによって引き起こされる。したがって、高速上りリンクアクセス解決策は、ＴＣＰレイヤにおいて構築された上部レイヤによって提供されるユーザ体験を改善することが期待されている。作業仮説のために、ＳＩＤは、高速上りリンクアクセス解決策に言及する。
【００９９】
研究分野は、エアインターフェース容量、バッテリ寿命、制御チャネルリソース、仕様インパクト、および技術的可能性を含むリソース効率を含んでいる。ＦＤＤデュプレクスモードとＴＤＤデュプレクスモードとの両方が考慮される。
【０１００】
第１の態様として、典型的なアプリケーションおよび使用の場合に関するレイテンシ改善による、低減された応答時間、および、改善されたＴＣＰスループットのような潜在的な利得が識別され、文書化される。この評価では、ＲＡＮ２は、短縮化されたＴＴＩと同様に、プロトコル強化によるレイテンシ低減を仮定し得る。結論として、この研究の本態様は、どのレイテンシ低減が、望ましいであるのかを示すことになっている［ＲＡＮ２］。
【０１０１】
その解決策は、ネットワーク容量、ＵＥ電力消費、制御チャネルリソースを改善することが期待されている。特に、改善されたＴＣＰスループットは、主要なパフォーマンスインジケータとして考慮され得る。
【０１０２】
考察１：ＤＬ  ＴＣＰスループットが、ＵＬレイテンシ低減解決策によって改善されることが期待される。
【０１０３】
高速上りリンクアクセス解決策特有の態様の場合；
アクティブなＵＥと、長期間、非アクティブであったが、ＲＲＣ接続コネクティッドに維持されているＵＥとのために、スケジュールされたＵＬ送信のためのユーザプレーンレイテンシを低減することと、現在のＴＴＩ長さおよび処理時間を維持する維持しない両方について今日の規格によって許容されている事前スケジューリング解決策と比較して、プロトコル強化およびシグナリング強化によって、より高いリソース効率の解決策を得ることと、に注目されるべきである。
【０１０４】
アクティブなＵＥは、データを連続的に送信／受信していると仮定される。したがって、ＵＥは、アクティブ時間にあると考えられる。すなわち、非アクティビティタイマが動作していることにより、ＤＲＸは適用されない。
【０１０５】
考察２：アクティブ時間にあるＵＥが考慮される。
【０１０６】
長い時間、非アクティブであるが、ＲＲＣコネクティッドに維持されているＵＥは、ＵＥが長いＤＲＸサイクルを適用し、上りリンク送信を実行するために少なくともＳＲとＢＳＲとを送信する必要があると解釈され得る。さらに、タイムアライメントタイマＴＡＴが終了した場合、ＵＥは、ＳＲ送信前に、ランダムアクセスプロシージャを開始する。これは、ユーザ経験、すなわち、実際の応答時間を低下させる。
【０１０７】
考察３：長いＤＲＸサイクルの適用を備え、ＵＬ許可のないＵＥが考慮される。
【０１０８】
考察４：ＵＥが長い間非アクティブであれば、タイムアライメントタイマが終了し得る。
【０１０９】
事前スケジューリング解決策と比較して、高速上りリンクアクセス解決策は、たとえ現在のＴＴＩ長さおよび処理長さが仮定されていても、より高いリソース効率であるべきである。ＴＴＩショートニングは、より一般的な解決策であり、増加されたＨＡＲＱインタラクションのおかげで、下りリンク配信のみならず、上りリンクアクセスレイテンシのレイテンシも低減することが期待されている。
【０１１０】
考察５：高速上りリンク解決策は、ＴＴＩショートニングアプローチと独立した利得を有する。
【０１１１】
モチベーション文書では、高速上りリンクアクセスのための可能なアプローチが、実施技術である事前スケジューリングに基づいており、事前スケジューリングによって、ｅＮＢが、ＳＲ受信前に上りリンクリソースを割り当てることが述べられている。しかしながら、ＵＥが送るべき上りリンクデータを有していなくても、事前スケジューリング技術は、上りリンク制御チャネル（すなわち、ＰＵＳＣＨ）および下りリンク制御チャネル（すなわち、ＰＤＣＣＨ）において無線リソースを消費する。既存のＳＰＳが事前スケジューリングのために使用されている場合において、ＵＥは、設定されたＳＰＳリソースの暗黙的な解放を回避するために、パディングデータを送信する必要があることも議論されている。したがって、モチベーション文書は、標準化されたアプローチが事前スケジューリング技術を強化することを期待されることを提案した。これは、事前許可、ＳＰＳ同様のメカニズム、データが利用可能ではない場合における無パディング、および／または、動的なスケジューリングへの円滑な移行を含み得る。
【０１１２】
考察６：標準化されたアプローチは、実施技術と比較して、リソース効率を強化することが期待されている。
【０１１３】
（２．２．典型的な使用の場合）
今日のモバイルトラフィックの増加は、モバイルビデオトラフィックの成長によって引き起こされ、この傾向は、パブリックレポートによれば、将来のトラフィックを支配することが予想されている。ビデオストリーミングは、（ＵＤＰによる）ライブストリーミング向けでなければ、典型的にＴＣＰ（ＴＣＰによるＨＴＴＰ）を用いることが良く知られている。したがって、ビデオストリーミングの使用の場合は、この研究の範囲に沿っている。
【０１１４】
レポートはまた、ソーシャルネットワーキングおよびウェブブラウジングは、モバイルトラフィックの２番目に支配的なアプリケーションであるとしており、これによって、これらアプリケーションは、典型的にＨＴＴＰに構築され、したがって、ＴＣＰを使用することを指摘している。多くの３ＧＰＰ代表者は既に通じているように、３ＧＰＰ  ＦＴＰサービスは、ＴＣＰも用いるＴｄｏｃｓをダウンロードするために、各代表者によって連続的にアクセスされ得る。したがって、ＨＴＴＰまたはＦＴＰに構築されたアプリケーションにおける振る舞いは、典型的な使用の場合であると考えられるべきである。
【０１１５】
提案１：ＨＴＴＰおよびＦＴＰに構築されたアプリケーションにおけるユーザ振る舞いは、この研究における典型的な使用の場合であると考えられるべきである。
【０１１６】
図１２は、モバイルトラフィックボリュームによる上位５つのアプリケーション及びモバイルアプリケーション分析を示す図である。
【０１１７】
そのようなアプリケーションにおける最も典型的な振る舞いは、要求／応答ダイアログとしてモデル化され得る。たとえば、ユーザがＦＴＰでファイルをダウンロードしたい場合、クライアントは、ＲＥＴＲコマンド（別名、ＧＥＴ）をサーバに先ず送り、その後、ファイルダウンロードが開始する。同じ振る舞いは、ＨＴＴＰに対しても適用可能である。これによって、図１３に例示されるように、ウェブブラウザは、先ずＧＥＴを送り、その後、ユーザがウェブページを開いた時にウェブページがダウンロードされる。典型的な振る舞いを考慮すると、ＲＡＮ２は、対応するＤＬ  ＴＣＰパケット（たとえば、ＧＥＴのような要求）に先行する最初の上りリンクデータ送信が、単に仮定されるだけか、または、高速上りリンクアクセス解決策においても強化されるべきであるかを議論すべきである。
【０１１８】
提案２：ＲＡＮ２は、対応するＤＬ  ＴＣＰパケットに先行する最初の上りリンクデータ送信が、単に仮定されるだけか、または、高速上りリンクアクセス解決策においても強化されるべきであるかを議論すべきである。
【０１１９】
図１３は、ＨＴＴＰ／ＦＴＰを用いた典型的な使用の場合のモデル化を示す図である。
【０１２０】
（２．３．本質的な問題）
２．１で言及したように、上りリンクアクセスレイテンシに至る重大な問題は、事前スケジューリング技術、または、強化されたＳＰＳを用いた事前許可技術の何れによっても解決されることはできない。図１４は、（図１４を参照する）高速上りリンクアクセス解決策によって対処されるべき３つの重大な問題を例示する。
【０１２１】
重大な問題１：ＤＬ伝送遅れ
ＤＬ伝送遅れは、長いＤＲＸサイクルによって引き起こされる。最悪の場合では、サービス提供セルは、ＤＬ  ＴＣＰパケット受信後、１０〜２５６０サブフレームの間、送信機会を待つ必要がある。
【０１２２】
重大な問題２：早過ぎる／遅過ぎる割当
早過ぎる割当は、事前スケジューリング技術、または、ＳＲ受信前の事前許可アプローチによって引き起こされ得る。一方、遅過ぎる割当は、ＳＲ周期、すなわち、ＳＲ周期＊ｓｒ−ＰｒｏｈｉｂｉｔＴｉｍｅｒによって、または、単純過ぎるスケジューラ実施、すなわち、対応するＢＳＲ受信に基づいて、ＴＣＰ  ＡＣＫパケットのための上りリンクリソース（したがって、ＵＥのＳＲ送信後の７サブフレーム）を割り当てるものによって可能となる。
【０１２３】
重大な問題３：多過ぎる／少な過ぎる割当
多過ぎる／少な過ぎる割当は、事前スケジューリング技術、または、ＢＳＲ前の事前許可アプローチによって引き起こされ得る。ＵＥのバッファステータスを知ることなく、スケジューラは、上りリンクリソースを盲目的に割り当てる必要がある。
【０１２４】
重大な問題４：初期上りリンク遅れ
考察４で述べられたように、ＴＡＴが終了した場合、ＵＥは、あらゆる上りリンク送信の前に、ランダムアクセスプロシージャを開始すべきである。
【０１２５】
もちろん、賢い実装技術が、３つの重大な問題によるネガティブなインパクト、たとえば、ＤＬ  ＩＰパケットの内部を理解すること、および、以前の上りリンク許可の使用に基づいて上りリンクリソースを割り当てること、のうちのいくつかを低減し得る。しかしながら、標準化されたアプローチは、上記リストされたすべての問題ではないが、ほとんどを解決することが期待されるであろう。
【０１２６】
提案３：ＤＬ伝送遅れ、早過ぎる／遅過ぎる割当、多過ぎる／少な過ぎる割当、ＴＡＴ終了は、高速上りリンクアクセス解決策によって最適化されるべきである。
【０１２７】
（２．４．潜在的な解決策アプローチ）
２．３で議論されたように、ＤＲＸ、ＳＲ、ＢＳＲ、および／または、プロシージャが再考されなければ、重大な問題は解決されないであろう。これらの問題は、たとえ強化されたＳＰＳを用いた事前許可アプローチが適用されても、対処されることはないであろう。なぜなら、実際の許可と理想的な割当との間のミスマッチ（図１４）が、エアインターフェース容量、バッテリ寿命、制御チャネルリソースを含むリソース効率の低下を引き起こすからである。
【０１２８】
考察７：事前許可アプローチは、既存の実施技術と比べて良好なパフォーマンスを有し得るが、これら重大な問題を未だに解決することはないであろう。
【０１２９】
これら重大な問題を解決するために、以下の解決策アプローチが考慮され得る。
【０１３０】
たとえば、最初のＵＬ送信（すなわち、ＧＥＴ）によってトリガされた、高速なＤＬ割当のための、ＤＲＸにおける拡張されたＯｎＤｕｒａｔｉｏｎハンドリング。
【０１３１】
たとえば、ＳＲとＢＳＲとの統合による、最初のＵＬパケット送信のためのシグナリング往復の低減。
【０１３２】
スペクトル効率へのインパクトの少ない、より短いＳＲ周期［ＲＡＮ１］。
【０１３３】
たとえば、ＵＬデータ許可のための追加の機能を用いた、ＲＡＣＨプロシージャ強化。
【０１３４】
したがって、ＲＡＮ２は、ＵＬ許可メカニズム自体だけでなく、ＵＬ許可に関連するプロシージャも研究すべきである。
【０１３５】
提案４：ＲＡＮ２はまた、ＤＲＸ、ＳＲ、ＢＳＲ、およびＲＡＣＨの強化を研究すべきである。
【０１３６】
（３．結論）
この付記では、承認された作業項目説明に基づいて作業仮説が議論された。典型的な使用の場合およびそのモデリングが提供される。４つの重大な問題および潜在的な解決策アプローチが、この研究のために特定される。
【０１３７】
［相互参照］
米国仮出願第６２／１６２１８４号（２０１５年５月１５日出願）の全内容が参照により本願明細書に組み込まれている。
【産業上の利用可能性】
【０１３８】
本発明は、通信分野において有用である。
【図１】
2016185896.tif 000006
【図２】
2016185896.tif 000007
【図３】
2016185896.tif 000008
【図４】
2016185896.tif 000009
【図５】
2016185896.tif 000010
【図６】
2016185896.tif 000011
【図７】
2016185896.tif 000012
【図８】
2016185896.tif 000013
【図９】
2016185896.tif 000014
【図１０】
2016185896.tif 000015
【図１１】
2016185896.tif 000016
【図１２】
2016185896.tif 000017
【図１３】
2016185896.tif 000018
【図１４】
2016185896.tif 000019
【手続補正書】
【提出日】平成29年11月8日(2017.11.8)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ランダムアクセス手順を制御する制御部を備える無線端末であって、
前記ランダムアクセス手順は、ランダムアクセスプリアンブルを基地局に送信する第１の処理と、ランダムアクセス応答を前記基地局から受信する第２の処理と、前記ランダムアクセス応答に基づいて前記基地局に上りリンク送信を行う第３の処理と、を含み、
前記制御部は、前記第３の処理において、前記無線端末の送信バッファ内の上りリンクデータの量を示す第１の報告を前記基地局に送信することにより、前記上りリンクデータの量を前記基地局に通知し、
前記制御部は、前記ランダムアクセス手順のタイミングとは異なるタイミングで、前記無線端末の送信バッファ内の上りリンクデータの量を示す第２の報告を前記基地局に送信することにより、前記上りリンクデータの量を前記基地局に通知し、
前記第１の報告によって示されるデータの量の粒度は、前記第２の報告によって示されるデータの量の粒度よりも大きい
無線端末。
【請求項２】
前記第１の報告のビット長は、前記第２の報告のビット長よりも短い、
請求項１に記載の無線端末。
【請求項３】
ランダムアクセス手順を制御する制御部を備える基地局であって、
前記ランダムアクセス手順は、ランダムアクセスプリアンブルを無線端末から受信する第１の処理と、ランダムアクセス応答を前記無線端末に送信する第２の処理と、前記ランダムアクセス応答に基づく上りリンク送信を前記無線端末から受信する第３の処理と、を含み、
前記制御部は、前記第３の処理において、前記無線端末の送信バッファ内の上りリンクデータの量を示す第１の報告を前記無線端末から受信することにより、前記上りリンクデータの量を把握し、
前記制御部は、前記ランダムアクセス手順のタイミングとは異なるタイミングで、前記無線端末の送信バッファ内の上りリンクデータの量を示す第２の報告を前記無線端末から受信することにより、前記上りリンクデータの量を把握し、
前記第１の報告によって示されるデータの量の粒度は、前記第２の報告によって示されるデータの量の粒度よりも大きい
基地局。
【請求項４】
前記第１の報告のビット長は、前記第２の報告のビット長よりも短い、
請求項３に記載の基地局。
【請求項５】
無線端末と基地局との間でランダムアクセス手順を行うステップであって、前記ランダムアクセス手順は、ランダムアクセスプリアンブルを基地局に送信する第１の処理と、ランダムアクセス応答を前記基地局から受信する第２の処理と、前記ランダムアクセス応答に基づいて前記基地局に上りリンク送信を行う第３の処理と、を含む、ステップと、
前記無線端末が、前記第３の処理において、前記無線端末の送信バッファ内の上りリンクデータの量を示す第１の報告を前記基地局に送信することにより、前記上りリンクデータの量を前記基地局に通知するステップと、
前記無線端末が、前記ランダムアクセス手順のタイミングとは異なるタイミングで、前記無線端末の送信バッファ内の上りリンクデータの量を示す第２の報告を前記基地局に送信することにより、前記上りリンクデータの量を前記基地局に通知するステップと、を備え、
前記第１の報告によって示されるデータの量の粒度は、前記第２の報告によって示されるデータの量の粒度よりも大きい
無線通信方法。
【請求項６】
前記第１の報告のビット長は、前記第２の報告のビット長よりも短い、
請求項５に記載の無線通信方法。
【国際調査報告】
2016185896.tif 000020
2016185896.tif 000021
2016185896.tif 000022