JP2018129842A

JP2018129842A - 無線端末、基地局、及び無線通信方法

Info

Publication number: JP2018129842A
Application number: JP2018054904A
Authority: JP
Inventors: 真人藤代; Masato Fujishiro; 空悟守田; Kugo Morita; 裕之安達; Hiroyuki Adachi; 憲由福田; Noriyoshi Fukuda
Original assignee: Kyocera Corp
Current assignee: Kyocera Corp
Priority date: 2015-05-15
Filing date: 2018-03-22
Publication date: 2018-08-16
Anticipated expiration: 2036-04-28
Also published as: EP3282799A4; JP6466613B2; EP3282799B1; US10750542B2; JP6641034B2; JPWO2016185896A1; JP2019071659A; EP3282799A1; US20180070383A1; WO2016185896A1; JP6313524B2

Abstract

【課題】無線通信におけるレイテンシを提言する方法を提供する。
【解決手段】無線端末は、ランダムアクセス手順を制御する制御部を備える。ランダムアクセス手順は、ランダムアクセスプリアンブルを基地局に送信する第１の処理と、ランダムアクセス応答を基地局から受信する第２の処理と、ランダムアクセス応答に基づいて基地局に上りリンク送信を行う第３の処理と、を含む。制御部は、第１の処理又は第３の処理において、無線端末の送信バッファ内の上りリンクデータの量を基地局に通知する。
【選択図】図１０

Description

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

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

一つの実施形態に係る無線端末は、ランダムアクセス手順を制御する制御部を備える。前記ランダムアクセス手順は、ランダムアクセスプリアンブルを基地局に送信する第１の処理と、ランダムアクセス応答を前記基地局から受信する第２の処理と、前記ランダムアクセス応答に基づいて前記基地局に上りリンク送信を行う第３の処理と、を含む。前記制御部は、前記第１の処理又は前記第３の処理において、前記無線端末の送信バッファ内の上りリンクデータの量を前記基地局に通知する。

一つの実施形態に係る基地局は、ランダムアクセス手順を制御する制御部を備える。前記ランダムアクセス手順は、ランダムアクセスプリアンブルを無線端末から受信する第１の処理と、ランダムアクセス応答を前記無線端末に送信する第２の処理と、前記ランダムアクセス応答に基づく上りリンク送信を前記無線端末から受信する第３の処理と、を含む。前記制御部は、前記第１の処理又は前記第３の処理において、前記無線端末の送信バッファ内の上りリンクデータの量を前記無線端末から取得する。

一つの実施形態に係るプロセッサは、ランダムアクセス手順を行う無線端末を制御する。前記ランダムアクセス手順は、ランダムアクセスプリアンブルを基地局に送信する第１の処理と、ランダムアクセス応答を前記基地局から受信する第２の処理と、前記ランダムアクセス応答に基づいて前記基地局に上りリンク送信を行う第３の処理と、を含む。前記プロセッサは、前記第１の処理又は前記第３の処理において、前記無線端末の送信バッファ内の上りリンクデータの量を前記基地局に通知する。

実施形態に係るＬＴＥシステム（移動通信システム）を示す図である。実施形態に係るＵＥ（無線端末）のブロック図である。実施形態に係るｅＮＢ（基地局）のブロック図である。ＬＴＥシステムにおける無線インターフェイスのプロトコルスタック図である。ＬＴＥシステムにおいて用いられる無線フレームの構成図である。ＢＳＲＭＡＣ制御要素を説明するための図である。ＴＣＰの概要を説明するための図である。一般的なランダムアクセス手順及び上りリンクの送信手順を示すシーケンス図である。実施形態に係るランダムアクセス手順のパターン１を示すシーケンス図である。実施形態に係るランダムアクセス手順のパターン２を示すシーケンス図である。実施形態に係るランダムアクセス手順のパターン３を示すシーケンス図である。実施形態の付記に係る図である。実施形態の付記に係る図である。実施形態の付記に係る図である。

［実施形態の概要］
一般的な上りリンクの送信手順は、以下の第１のステップ乃至第３のステップを含む。

第１のステップにおいて、無線端末は、ＰＵＳＣＨ（ＰｈｙｓｉｃａｌＵｐｌｉｎｋＳｈａｒｅｄＣｈａｎｎｅｌ）リソースを要求するためのスケジューリング要求（ＳＲ）を、ＰＵＣＣＨ（ＰｈｙｓｉｃａｌＵｐｌｉｎｋＣｏｎｔｒｏｌＣｈａｎｎｅｌ）リソースを用いて基地局に送信する。基地局は、ＳＲの受信に応じて、無線端末にＰＵＳＣＨリソースを割り当てる。

第２のステップにおいて、無線端末は、基地局から割り当てられたＰＵＳＣＨリソースを用いて、無線端末の送信バッファ内の上りリンクデータの量を示すバッファ情報を含むバッファステータス報告（ＢＳＲ）を基地局に送信する。基地局は、ＢＳＲの受信に応じて、適切な量のＰＵＳＣＨリソースを無線端末に割り当てる。

第３のステップにおいて、無線端末は、基地局から割り当てられたＰＵＳＣＨリソースを用いて、無線端末の送信バッファ内の上りリンクデータを基地局に送信する。

一方で、ＲＲＣコネクティッドモードの無線端末は、上りリンク同期状態が非同期（Ｎｏｎ−ｓｙｎｃｈｒｏｎｉｓｅｄ）である場合、上りリンク送信を行うために、ランダムアクセス手順を行う。また、ＲＲＣコネクティッドモードの無線端末は、初期接続（Ｉｎｉｔｉａｌａｃｃｅｓｓ）を行うために、ランダムアクセス手順を行う。

無線端末は、ランダムアクセス手順の終了後に、上述した上りリンクの送信手順（すなわち、第１のステップ乃至第３のステップ）を行うことにより、上りリンクデータを基地局に送信可能である。しかしながら、ランダムアクセス手順の後に上りリンクの送信手順（第１のステップ乃至第３のステップ）を行う方法には、上りリンクのレイテンシを低減する、すなわち高速上りリンクアクセスを可能とする点において改善の余地がある。

以下の実施形態において、高速上りリンクアクセスを可能とするための技術が開示される。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（６）ＳＲの概要
ＵＥ１００は、ＰＵＳＣＨリソースを要求するためのＳＲを、ＰＵＣＣＨリソースを用いてｅＮＢ２００に送信する。ｅＮＢ２００は、ＳＲの受信に応じて、ＵＥ１００にＰＵＳＣＨリソースを割り当てる（すなわち、ＵＥ１００に「ＵＬｇｒａｎｔ」を送信する）。

ＵＥ１００は、ｅＮＢ２００からＲＲＣシグナリングにより設定されるＰＵＣＣＨパラメータであるＮ⁽¹⁾ _PUCCH,SRIに従って、ＳＲの送信用のＰＵＣＣＨリソースを決定する。当該パラメータは、ＵＥ固有のパラメータである。

また、ＳＲの送信周期（ＳＲｐｅｒｉｏｄｉｃｉｔｙ）及びサブフレームオフセット（ＳＲｓｕｂｆｒａｍｅｏｆｆｓｅｔ）を含むＳＲ設定（ＳＲｃｏｎｆｉｇｕｒａｔｉｏｎ）は、ｅＮＢ２００からＵＥ１００にＲＲＣシグナリングにより設定されるパラメータである「ＳＲｃｏｎｆｉｇｕｒａｔｉｏｎｉｎｄｅｘ」により定められる。当該パラメータは、ＵＥ固有のパラメータである。「ＳＲｃｏｎｆｉｇｕｒａｔｉｏｎ」の一例を表１に示す。

表１の例において、ＳＲの送信用のＰＵＣＣＨリソースの周期（ＳＲｐｅｒｉｏｄｉｃｉｔｙ）は、１［ｍｓ］乃至８０［ｍｓ］の範囲内である。

ＵＥ１００は、例えば下記の式（１）を満たす各サブフレームにおいてＳＲを送信可能である。

但し、「ｎ_f」はシステムフレーム番号（無線フレーム番号）であり、「ｎ_S」はフレーム内のスロット番号（０番乃至１９番）であり、「Ｎ_OFFSET,SR」はサブフレームオフセット（ＳＲｓｕｂｆｒａｍｅｏｆｆｓｅｔ）であり、「ＳＲ_PERIODICITY」はＳＲ周期（ＳＲｐｅｒｉｏｄｉｃｉｔｙ）である。

（７）ＢＳＲの概要
ＵＥ１００は、ｅＮＢ２００から割り当てられたＰＵＳＣＨリソースを用いて、ＢＳＲをｅＮＢ２００に送信する。ＢＳＲは、ＵＥ１００の送信バッファ（ＵＬバッファ）内の上りリンクデータの量を示すバッファ情報（ＢｕｆｆｅｒＳｉｚｅ）を含む。ＢＳＲは、ＵＥ１００のＭＡＣ層からｅＮＢ２００のＭＡＣ層に送信されるＭＡＣ制御要素の一種である。ＢＳＲＭＡＣ制御要素は、第１のフォーマット及び第２のフォーマットをサポートする。第１のフォーマットは、「ＳｈｏｒｔＢＳＲ」及び「ＴｒｕｎｃａｔｅｄＢＳＲ」の送信に用いられる。第２のフォーマットは、「ＬｏｎｇＢＳＲ」の送信に用いられる。

図６は、ＢＳＲＭＡＣ制御要素を説明するための図である。

図６（Ａ）に示すように、ＢＳＲＭＡＣ制御要素の第１のフォーマットは、１つの「ＬＣＧＩＤ」フィールド及び１つの「ＢｕｆｆｅｒＳｉｚｅ」フィールドからなる。「ＬＣＧＩＤ」は、論理チャネルのグループを識別するＩＤであり、２ビットのビット長を有する。「ＢｕｆｆｅｒＳｉｚｅ」は、「ＬＣＧＩＤ」に対応するグループ内の全ての論理チャネルのデータ量を示すインデックスであり、６ビットのビット長を有する。インデックスとデータ量（バッファサイズ値）との対応関係の一例を表２に示す。

図６（Ｂ）に示すように、ＢＳＲＭＡＣ制御要素の第２のフォーマットは、４つの「ＢｕｆｆｅｒＳｉｚｅ」フィールドからなる。「ＢｕｆｆｅｒＳｉｚｅ」フィールドは、「ＬＣＧＩＤ＃０」乃至「ＬＣＧＩＤ＃３」に対応して設けられる。ＢＳＲＭＡＣ制御要素の第２のフォーマットによれば、１つのＢＳＲで４つの「ＬＣＧＩＤ」の各データ量を示すことができる。

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

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

よって、ＬＴＥシステムの下りリンクが混雑していない場合でも、ＵＥ１００が上りリンクにおいて「ＴＣＰＡＣＫ」を速やかに送信しなければ、下りリンクのＴＣＰスループットを高めることができない。すなわち、ＵＥ１００において「ＴＣＰＡＣＫ」を生成してから「ＴＣＰＡＣＫ」をｅＮＢ２００に送信完了するまでの遅延時間（上りリンクのレイテンシ）を短縮できれば、下りリンクのＴＣＰスループットを高めることができる。ここで、「ＴＣＰＡＣＫ」をＵＥ１００からｅＮＢ２００に送信するためには、ｅＮＢ２００からＵＥ１００に適切な量の上りリンクリソース（具体的には、ＰＵＳＣＨリソース）を割り当てることが必要である。

（９）一般的なランダムアクセス手順及び上りリンクの送信手順
以下において、一般的なランダムアクセス手順及び上りリンクの送信手順について説明する。図８は、一般的なランダムアクセス手順及び上りリンクの送信手順を示すシーケンス図である。図８の初期状態において、ＵＥ１００は、ＲＲＣコネクティッドモード又はＲＲＣアイドルモードである。

図８に示すように、ＲＲＣコネクティッドモードのＵＥ１００は、上りリンク同期状態が非同期（Ｎｏｎ−ｓｙｎｃｈｒｏｎｉｓｅｄ）である場合、上りリンク送信を行うために、ランダムアクセス手順（ステップＳ１）を行う。また、ＲＲＣアイドルモードのＵＥ１００は、初期接続（Ｉｎｉｔｉａｌａｃｃｅｓｓ）を行うために、ランダムアクセス手順（ステップＳ１）を行う。ＵＥ１００は、ランダムアクセス手順（ステップＳ１）の終了後に、上りリンクの送信手順（ステップＳ２）を行うことにより、上りリンクデータ（ＵＬデータ）をｅＮＢ２００に送信する。

具体的には、ステップＳ１−１において、ＵＥ１００は、ランダムアクセス手順の第１の処理として、ランダムアクセスプリアンブル（ＲＡＰｒｅａｍｂｌｅ）をＰＲＡＣＨ上でｅＮＢ２００に送信する。「ＲＡＰｒｅａｍｂｌｅ」は、Ｍｓｇ１と称されることがある。「ＲＡＰｒｅａｍｂｌｅ」は、ＭＡＣ層においてＵＥ１００からｅＮＢ２００へのランダムアクセスを行うための信号である。ｅＮＢ２００は、「ＲＡＰｒｅａｍｂｌｅ」を受信する。

ステップＳ１−２において、ｅＮＢ２００は、ランダムアクセス手順の第２の処理として、ＤＬ−ＳＣＨ上でランダムアクセス応答（ＲＡＲｅｓｐｏｎｓｅ）をＵＥ１００に送信する。「ＲＡＲｅｓｐｏｎｓｅ」は、ＭＡＣ制御要素（ＭＡＣＣＥ）の一種であり、Ｍｓｇ２と称されることがある。具体的には、ｅＮＢ２００は、ＵＥ１００から受信した「ＲＡＰｒｅａｍｂｌｅ」に基づいて、ＵＥ１００との間の上りリンク遅延を推定する。また、ｅＮＢ２００は、ＵＥ１００に割り当てる上りリンク無線リソースを決定する。そして、ｅＮＢ２００は、遅延推定の結果に基づくタイミング補正値（ＴＡ：ＴｉｍｉｎｇＡｄｖａｎｃｅ）、無線リソースの割り当て情報（ＵＬｇｒａｎｔ）、プリアンブル識別子（ＰｒｅａｍｂｌｅＩＤ）、及び「ＴｅｍｐｏｒａｒｙＣ−ＲＮＴＩ」を含む「ＲＡＲｅｓｐｏｎｓｅ」をＵＥ１００に送信する。なお、「ＰｒｅａｍｂｌｅＩＤ」は、ＵＥ１００から受信した「ＲＡＰｒｅａｍｂｌｅ」の信号系列を示すＩＤである。また、物理層（ＰＤＣＣＨ）において、「ＲＡＲｅｓｐｏｎｓｅ」の送信には専用のＲＮＴＩ（ＲＡ−ＲＮＴＩ）が用いられる。ＵＥ１００は、「ＲＡＲｅｓｐｏｎｓｅ」を受信する。

ステップＳ１−３において、ＵＥ１００は、ランダムアクセス手順の第３の処理として、「ＲＡＲｅｓｐｏｎｓｅ」に基づいてＵＬ−ＳＣＨ上でｅＮＢ２００に上りリンク送信（ＳｃｈｅｄｕｌｅｄＴｒａｎｓｍｉｓｓｉｏｎ）を行う。「ＳｃｈｅｄｕｌｅｄＴｒａｎｓｍｉｓｓｉｏｎ」は、Ｍｓｇ３と称されることがある。初期接続（Ｉｎｉｔｉａｌａｃｃｅｓｓ）の場合、「ＳｃｈｅｄｕｌｅｄＴｒａｎｓｍｉｓｓｉｏｎ」は、「ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｑｕｅｓｔ」メッセージである。それ以外の場合（すなわち、ＵＥ１００にＣ−ＲＮＴＩが割り当てられている場合）、「ＳｃｈｅｄｕｌｅｄＴｒａｎｓｍｉｓｓｉｏｎ」は、ＵＥ１００のＣ−ＲＮＴＩを含むメッセージである。ｅＮＢ２００は、「ＳｃｈｅｄｕｌｅｄＴｒａｎｓｍｉｓｓｉｏｎ」を受信する。

ステップＳ１−４において、ｅＮＢ２００は、ランダムアクセス手順の第３の処理として、競合解決（ＣｏｎｔｅｎｔｉｏｎＲｅｓｏｌｕｔｉｏｎ）メッセージをＵＥ１００に送信する。「ＣｏｎｔｅｎｔｉｏｎＲｅｓｏｌｕｔｉｏｎ」メッセージは、Ｍｓｇ４と称されることがある。「ＣｏｎｔｅｎｔｉｏｎＲｅｓｏｌｕｔｉｏｎ」メッセージは、ステップＳ１−３でＵＥ１００から受信したメッセージの内容を含む。初期接続（Ｉｎｉｔｉａｌａｃｃｅｓｓ）の場合、物理層（ＰＤＣＣＨ）において、「ＣｏｎｔｅｎｔｉｏｎＲｅｓｏｌｕｔｉｏｎ」メッセージの送信には「ＴｅｍｐｏｒａｒｙＣ−ＲＮＴＩ」が用いられる。ＵＥ１００にＣ−ＲＮＴＩが割り当てられている場合、物理層（ＰＤＣＣＨ）において、「ＣｏｎｔｅｎｔｉｏｎＲｅｓｏｌｕｔｉｏｎ」メッセージの送信には「Ｃ−ＲＮＴＩ」が用いられる。ＵＥ１００は、「ＣｏｎｔｅｎｔｉｏｎＲｅｓｏｌｕｔｉｏｎ」メッセージを受信する。

このように、ランダムアクセス手順（ステップＳ１）は、ステップＳ１−１乃至Ｓ１−４からなる。次に、上りリンクの送信手順（ステップＳ２）について説明する。

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

ステップＳ２−２において、ｅＮＢ２００は、ＳＲの受信に応じて、ＵＥ１００にＰＵＳＣＨリソースを割り当てる。具体的には、ｅＮＢ２００は、上りリンクのスケジューリング情報（ＵＬｇｒａｎｔ）を含むＤＣＩをＰＤＣＣＨ上でＵＥ１００に送信する。

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

ステップＳ２−４において、ｅＮＢ２００は、ＢＳＲの受信に応じて、適切な量のＰＵＳＣＨリソースをＵＥ１００に割り当てる。具体的には、ｅＮＢ２００は、上りリンクのスケジューリング情報（ＵＬｇｒａｎｔ）を含むＤＣＩをＰＤＣＣＨ上でＵＥ１００に送信する。

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

このように、上りリンクの送信手順（ステップＳ２）は、ステップＳ２−１乃至Ｓ２−５からなる。

しかしながら、ランダムアクセス手順（ステップＳ１）の後に上りリンクの送信手順（ステップＳ２）を行う方法には、上りリンクのレイテンシを低減する、すなわち高速上りリンクアクセスを可能とする点において改善の余地がある。

（１０）実施形態に係るランダムアクセス手順
以下において、実施形態に係るランダムアクセス手順について説明する。

（１０．１）パターン１
図９は、実施形態に係るランダムアクセス手順のパターン１を示すシーケンス図である。ここでは、図８との相違点を主として説明する。

図９に示すように、ステップＳ１１において、ＵＥ１００は、ランダムアクセス手順の第１の処理として、ランダムアクセスプリアンブル（ＲＡＰｒｅａｍｂｌｅ）をＰＲＡＣＨ上でｅＮＢ２００に送信する。ＵＥ１００は、第１の処理において、報告（ＢＳＲ）をｅＮＢ２００に送信するための無線リソースの割り当てをｅＮＢ２００に要求する。例えば、ＵＥ１００は、特定の信号系列又はリソース（Ｓｐｅｃｉｆｉｃｓｅｑｕｅｎｃｅ／ｒｅｓｏｕｒｃｅ）により特別な「ＲＡＰｒｅａｍｂｌｅ」を送信する。ここで、特定の信号系列とは、例えば特定のプリアンブルグループに属する信号系列である。特定のリソースとは、例えば特定の「ＰＲＡＣＨＭａｓｋＩｎｄｅｘ」である。このような特別な「ＲＡＰｒｅａｍｂｌｅ」は、高速上りリンクアクセス用の「ＲＡＰｒｅａｍｂｌｅ」とみなすこともできる。具体的には、特別な「ＲＡＰｒｅａｍｂｌｅ」は、ＳＲの機能が追加された「ＲＡＰｒｅａｍｂｌｅ」である。ｅＮＢ２００は、特別な「ＲＡＰｒｅａｍｂｌｅ」を受信する。

ステップＳ１２において、ｅＮＢ２００は、ランダムアクセス手順の第２の処理として、ＤＬ−ＳＣＨ上でランダムアクセス応答（ＲＡＲｅｓｐｏｎｓｅ）をＵＥ１００に送信する。「ＲＡＲｅｓｐｏｎｓｅ」に含まれる情報は、一般的なランダムアクセス手順において「ＲＡＲｅｓｐｏｎｓｅ」に含まれる情報と同様である。但し、実施形態において、ｅＮＢ２００は、特別な「ＲＡＰｒｅａｍｂｌｅ」の受信に応じて、通常の「ＳｃｈｅｄｕｌｅｄＴｒａｎｓｍｉｓｓｉｏｎ」用の無線リソースだけではなく、ＢＳＲ送信用の無線リソースもＵＥ１００に割り当て、これらの無線リソースを示す割り当て情報（ＵＬｇｒａｎｔ）を「ＲＡＲｅｓｐｏｎｓｅ」に含める。ＵＥ１００は、「ＲＡＲｅｓｐｏｎｓｅ」を受信する。

ステップＳ１３において、ＵＥ１００は、ランダムアクセス手順の第３の処理として、「ＲＡＲｅｓｐｏｎｓｅ」に基づいてＵＬ−ＳＣＨ上でｅＮＢ２００に上りリンク送信（ＳｃｈｅｄｕｌｅｄＴｒａｎｓｍｉｓｓｉｏｎ）を行う。ＵＥ１００は、第３の処理において、ＢＳＲをｅＮＢ２００に送信することにより、ＵＥ１００の送信バッファ内の上りリンクデータの量をｅＮＢ２００に通知する。ｅＮＢ２００は、「ＳｃｈｅｄｕｌｅｄＴｒａｎｓｍｉｓｓｉｏｎ」と共にＢＳＲをＵＥ１００から受信する。

ステップＳ１４において、ｅＮＢ２００は、ランダムアクセス手順の第３の処理として、競合解決（ＣｏｎｔｅｎｔｉｏｎＲｅｓｏｌｕｔｉｏｎ）メッセージをＵＥ１００に送信する。ここで、ｅＮＢ２００は、ＢＳＲの受信に応じて、上りリンクデータ（ＵＬｄａｔａ）を送信するための無線リソース（ＰＵＳＣＨリソース）をＵＥ１００に割り当て、当該無線リソースを示す割り当て情報（ＵＬｇｒａｎｔ）をＰＤＣＣＨ上でＵＥ１００に送信する。ＵＥ１００は、「ＣｏｎｔｅｎｔｉｏｎＲｅｓｏｌｕｔｉｏｎ」メッセージと共に「ＵＬｇｒａｎｔ」をｅＮＢ２００から受信する。

ステップＳ１５において、ＵＥ１００は、上りリンクデータ（ＵＬｄａｔａ）を送信するための「ＵＬｇｒａｎｔ」をｅＮＢ２００から受信したことに応じて、ランダムアクセス手順が終了するとともに上りリンクデータをｅＮＢ２００に送信する。ｅＮＢ２００は、ランダムアクセス手順が終了するとともに上りリンクデータをＵＥ１００から受信する。

このように、実施形態に係るランダムアクセス手順によれば、ＵＥ１００がランダムアクセス手順の過程でＳＲと同様な情報及びＢＳＲをｅＮＢ２００に送信することができる。このため、ＵＥ１００がランダムアクセス手順の後にＳＲ及びＢＳＲをｅＮＢ２００に送信することなく、直ちに上りリンクデータをｅＮＢ２００に送信することができる。具体的には、図９に示すシーケンスによれば、図８のステップＳ２−１乃至Ｓ２−４を省略することができる。従って、実施形態に係るランダムアクセス手順によれば、高速上りリンクアクセスを可能とすることができる。

（１０．２）パターン２
図１０は、実施形態に係るランダムアクセス手順のパターン２を示すシーケンス図である。ここでは、図８との相違点を主として説明する。パターン２は、パターン１のシーケンスの一部を簡略化したパターンである。

図１０に示すように、本パターンのステップＳ２１及びＳ２２は、図８に示す一般的なランダムアクセス手順と同様である。

ステップＳ２３において、ＵＥ１００は、ランダムアクセス手順の第３の処理として、「ＲＡＲｅｓｐｏｎｓｅ」に基づいてＵＬ−ＳＣＨ上でｅＮＢ２００に上りリンク送信（ＳｃｈｅｄｕｌｅｄＴｒａｎｓｍｉｓｓｉｏｎ）を行う。ＵＥ１００は、第３の処理において、ＢＳＲをｅＮＢ２００に送信することにより、ＵＥ１００の送信バッファ内の上りリンクデータの量をｅＮＢ２００に通知する。ここで送信されるＢＳＲは、一般的なＢＳＲに比べてラフなＢＳＲ（ＲｏｕｇｈＢＳＲ）であり、一般的なＢＳＲに比べてビット長が短い。例えば、上りリンクデータ量（バッファサイズ）を２ビットのインデックスで表現する場合、インデックス「００」は「１００バイト未満」を表し、インデックス「０１」は「１００バイト以上５００バイト未満」を表し、インデックス「１０」は「５００バイト以上５００ｋバイト未満」を表し、インデックス「１１」は「５００ｋバイト以上１Ｍバイト未満」を表す。或いは、インデックスは、表２に示したようなＢＳＲテーブルを指定するものでもよい。例えば、インデックス「００」はＢＳＲテーブル中の「Ｉｎｄｅｘ０〜１５」を表し、インデックス「０１」はＢＳＲテーブル中の「Ｉｎｄｅｘ１６〜３１」を表し、インデックス「１０」はＢＳＲテーブル中の「Ｉｎｄｅｘ３２〜４７」を表し、インデックス「１１」はＢＳＲテーブル中の「Ｉｎｄｅｘ４８〜６３」を表す。なお、ここではＢＳＲテーブルを４等分する一例を示したが、４等分に限定されない。ｅＮＢ２００は、「ＳｃｈｅｄｕｌｅｄＴｒａｎｓｍｉｓｓｉｏｎ」と共に「ＲｏｕｇｈＢＳＲ」をＵＥ１００から受信する。

ステップＳ２４において、ｅＮＢ２００は、ランダムアクセス手順の第３の処理として、競合解決（ＣｏｎｔｅｎｔｉｏｎＲｅｓｏｌｕｔｉｏｎ）メッセージをＵＥ１００に送信する。ここで、ｅＮＢ２００は、「ＲｏｕｇｈＢＳＲ」の受信に応じて、上りリンクデータ（ＵＬｄａｔａ）を送信するための無線リソース（ＰＵＳＣＨリソース）をＵＥ１００に割り当て、当該無線リソースを示す割り当て情報（ＵＬｇｒａｎｔ）をＰＤＣＣＨ上でＵＥ１００に送信する。ＵＥ１００は、「ＣｏｎｔｅｎｔｉｏｎＲｅｓｏｌｕｔｉｏｎ」メッセージと共に「ＵＬｇｒａｎｔ」をｅＮＢ２００から受信する。

ステップＳ２５において、ＵＥ１００は、上りリンクデータ（ＵＬｄａｔａ）を送信するための「ＵＬｇｒａｎｔ」をｅＮＢ２００から受信したことに応じて、ランダムアクセス手順が終了するとともに上りリンクデータをｅＮＢ２００に送信する。ｅＮＢ２００は、ランダムアクセス手順が終了するとともに上りリンクデータをＵＥ１００から受信する。

（１０．３）パターン３
図１１は、実施形態に係るランダムアクセス手順のパターン３を示すシーケンス図である。ここでは、図８との相違点を主として説明する。パターン３は、主として初期接続（Ｉｎｉｔｉａｌａｃｃｅｓｓ）を対象としたパターンである。図１１の初期状態において、ＵＥ１００は、ＲＲＣコネクティッドモードである。

図１１に示すように、ステップＳ３０において、ＵＥ１００は、ｅＮＢ２００とのＲＲＣ接続を解放するための「ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｌｅａｓｅ」メッセージをｅＮＢ２００から受信し、ＲＲＣアイドルモードに遷移する。「ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｌｅａｓｅ」メッセージは、高速上りリンクアクセス（ＦａｓｔＵｐｌｉｎｋＡｃｃｅｓｓ）の設定情報（Ｃｏｎｆｉｇｕｒａｔｉｏｎ）を含む。ＵＥ１００は、当該Ｃｏｎｆｉｇｕｒａｔｉｏｎを記憶する。当該Ｃｏｎｆｉｇｕｒａｔｉｏｎは、当該Ｃｏｎｆｉｇｕｒａｔｉｏｎの適用有無を示すフラグや当該Ｃｏｎｆｉｇｕｒａｔｉｏｎの有効時間を示すタイマ値を含む。若しくは、当該Ｃｏｎｆｉｇｕｒａｔｉｏｎにより特別なランダムアクセスプリアンブルを指定してもよい。

ステップＳ３１において、ＵＥ１００は、記憶しているＣｏｎｆｉｇｕｒａｔｉｏｎに基づいて、ランダムアクセス手順の第１の処理として、ランダムアクセスプリアンブル（ＲＡＰｒｅａｍｂｌｅ）をＰＲＡＣＨ上でｅＮＢ２００に送信する。ＵＥ１００は、第１の処理において、特別な「ＲＡＰｒｅａｍｂｌｅ」を送信する。以降の動作（ステップＳ３２乃至Ｓ３５）は、パターン１と同様であるが、初期接続（Ｉｎｉｔｉａｌａｃｃｅｓｓ）用の動作に従う。

（１１）実施形態のまとめ
実施形態に係るランダムアクセス手順によれば、ＵＥ１００がランダムアクセス手順の過程で上りリンクのデータ量（バッファサイズ）をｅＮＢ２００に通知することができる。このため、ＵＥ１００がランダムアクセス手順の後にＢＳＲをｅＮＢ２００に送信することなく、直ちに上りリンクデータをｅＮＢ２００に送信することができる。従って、高速上りリンクアクセスを可能とすることができる。

［その他の実施形態］
上述した実施形態において、ＵＥがバッファしているデータ量を示す情報としてＢＳＲを例示したが、これに限定されない。ＵＥ内でバッファしている上りリンクデータを示す量が適用されてもよい。例えば、アプリケーション層も含めたＵＥの各レイヤがバッファしているデータ量を通知してもよい。

上述した実施形態において、ＵＥ１００は、ランダムアクセス手順の第３の処理（ＳｃｈｅｄｕｌｅｄＴｒａｎｓｍｉｓｓｉｏｎ）において上りリンクのデータ量（バッファサイズ）をｅＮＢ２００に通知していた。しかしながら、ＵＥ１００は、ランダムアクセス手順の第１の処理（ＲＡＰｒｅａｍｂｌｅ）において上りリンクのデータ量（バッファサイズ）をｅＮＢ２００に通知してもよい。例えば、「ＲＡＰｒｅａｍｂｌｅ」の信号系列（ｓｅｑｕｅｎｃｅ）及びリソース（ＰＲＡＣＨＭａｓｋＩｎｄｅｘ）の組み合わせに対してバッファサイズを対応付ける。このような対応付けは、例えば仕様により予め規定される。ＵＥ１００は、バッファサイズに応じて信号系列（ｓｅｑｕｅｎｃｅ）及びリソース（ＰＲＡＣＨＭａｓｋＩｎｄｅｘ）の組み合わせを選択し、選択した組み合わせを用いて「ＲＡＰｒｅａｍｂｌｅ」をｅＮＢ２００に送信する。ｅＮＢ２００は、ＵＥ１００から受信した「ＲＡＰｒｅａｍｂｌｅ」に適用されている信号系列（ｓｅｑｕｅｎｃｅ）及びリソース（ＰＲＡＣＨＭａｓｋＩｎｄｅｘ）の組み合わせに基づいてバッファサイズを特定することができる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

図１３は、ＨＴＴＰ／ＦＴＰを用いた典型的な使用の場合のモデル化を示す図である。

（２．３．本質的な問題）
２．１で言及したように、上りリンクアクセスレイテンシに至る重大な問題は、事前スケジューリング技術、または、強化されたＳＰＳを用いた事前許可技術の何れによっても解決されることはできない。図１４は、（図１４を参照する）高速上りリンクアクセス解決策によって対処されるべき３つの重大な問題を例示する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Claims

ランダムアクセス手順を制御する制御部を備える無線端末であって、
前記制御部は、前記ランダムアクセス手順におけるＭｓｇ３送信において、前記無線端末の送信バッファ内の上りリンクデータの量を示す第１の報告を基地局に送信することにより、前記上りリンクデータの量を前記基地局に通知し、
前記制御部は、前記ランダムアクセス手順のタイミングとは異なるタイミングで、前記無線端末の送信バッファ内の上りリンクデータの量を示す第２の報告を前記基地局に送信することにより、前記上りリンクデータの量を前記基地局に通知し、
前記第１の報告によって示されるデータの量の粒度は、前記第２の報告によって示されるデータの量の粒度よりも大きい
無線端末。
前記第１の報告のビット長は、前記第２の報告のビット長よりも短い、
請求項１に記載の無線端末。
ランダムアクセス手順を制御する制御部を備える基地局であって、
前記制御部は、前記ランダムアクセス手順におけるＭｓｇ３受信において、無線端末の送信バッファ内の上りリンクデータの量を示す第１の報告を前記無線端末から受信することにより、前記上りリンクデータの量を把握し、
前記制御部は、前記ランダムアクセス手順のタイミングとは異なるタイミングで、前記無線端末の送信バッファ内の上りリンクデータの量を示す第２の報告を前記無線端末から受信することにより、前記上りリンクデータの量を把握し、
前記第１の報告によって示されるデータの量の粒度は、前記第２の報告によって示されるデータの量の粒度よりも大きい
基地局。
前記第１の報告のビット長は、前記第２の報告のビット長よりも短い、
請求項３に記載の基地局。
無線端末が、ランダムアクセス手順におけるＭｓｇ３送信において、前記無線端末の送信バッファ内の上りリンクデータの量を示す第１の報告を基地局に送信することにより、前記上りリンクデータの量を前記基地局に通知するステップと、
前記無線端末が、前記ランダムアクセス手順のタイミングとは異なるタイミングで、前記無線端末の送信バッファ内の上りリンクデータの量を示す第２の報告を前記基地局に送信することにより、前記上りリンクデータの量を前記基地局に通知するステップと、を備え、
前記第１の報告によって示されるデータの量の粒度は、前記第２の報告によって示されるデータの量の粒度よりも大きい
無線通信方法。
前記第１の報告のビット長は、前記第２の報告のビット長よりも短い、
請求項５に記載の無線通信方法。