JPWO2016185895A1

JPWO2016185895A1 - 無線端末、基地局、及びプロセッサ

Info

Publication number: JPWO2016185895A1
Application number: JP2017519100A
Authority: JP
Inventors: 真人藤代; 智春山▲崎▼
Original assignee: Kyocera Corp
Current assignee: Kyocera Corp
Priority date: 2015-05-15
Filing date: 2016-04-28
Publication date: 2018-03-15
Anticipated expiration: 2036-04-28
Also published as: US10624069B2; WO2016185895A1; JP6783755B2; US20180084542A1

Abstract

ＰＵＳＣＨリソースを用いて上りリンクデータを基地局に送信する無線端末は、前記ＰＵＳＣＨリソースの割り当てを要求するためのスケジューリング要求を、ＰＵＣＣＨリソースを用いて前記基地局に送信する処理を行う制御部を備える。前記スケジューリング要求は、前記無線端末の送信バッファ内の前記上りリンクデータの量を示すバッファ情報を含む。

Description

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

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

一つの実施形態に係る無線端末は、ＰＵＳＣＨリソースを用いて上りリンクデータを基地局に送信する。前記無線端末は、前記ＰＵＳＣＨリソースの割り当てを要求するためのスケジューリング要求を、ＰＵＣＣＨリソースを用いて前記基地局に送信する処理を行う制御部を備える。前記スケジューリング要求は、前記無線端末の送信バッファ内の前記上りリンクデータの量を示すバッファ情報を含む。

一つの実施形態に係る基地局は、ＰＵＳＣＨリソースを用いて上りリンクデータを無線端末から受信する。前記基地局は、前記ＰＵＳＣＨリソースの割り当てを要求するためのスケジューリング要求を、ＰＵＣＣＨリソースを用いて前記無線端末から受信する処理を行う制御部を備える。前記スケジューリング要求は、前記無線端末の送信バッファ内の前記上りリンクデータの量を示すバッファ情報を含む。

一つの実施形態に係るプロセッサは、ＰＵＳＣＨリソースを用いて上りリンクデータを基地局に送信する無線端末を制御する。前記プロセッサは、前記ＰＵＳＣＨリソースの割り当てを要求するためのスケジューリング要求を、ＰＵＣＣＨリソースを用いて前記基地局に送信する処理を実行する。前記スケジューリング要求は、前記無線端末の送信バッファ内の前記上りリンクデータの量を示すバッファ情報を含む。

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

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

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

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

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

しかしながら、このような上りリンクの送信手順は、上りリンクのレイテンシを低減する、すなわち、高速上りリンクアクセスを可能とする点において、改善の余地がある。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

下りリンクにおいて、各サブフレームの先頭数シンボルの区間は、主に下りリンク制御信号を伝送するための物理下りリンク制御チャネル（ＰＤＣＣＨ：ＰｈｙｓｉｃａｌＤｏｗｎｌｉｎｋＣｏｎｔｒｏｌＣｈａｎｎｅｌ）として用いられる領域である。ＰＤＣＣＨの詳細については後述する。また、各サブフレームの残りの部分は、主に下りリンクデータを伝送するための物理下りリンク共有チャネル（ＰＤＳＣＨ：ＰＵＳＣＨ：ＰｈｙｓｉｃａｌＤｏｗｎｌｉｎｋＳｈａｒｅｄＣｈａｎｎｅｌ）として用いることができる領域である。

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

上りリンクにおいて、各サブフレームにおける周波数方向の両端部は、主に上りリンク制御信号を伝送するための物理上りリンク制御チャネル（ＰＵＣＣＨ：ＰｈｙｓｉｃａｌＵｐｌｉｎｋＣｏｎｔｒｏｌＣｈａｎｎｅｌ）として用いられる領域である。各サブフレームにおける残りの部分は、主に上りリンクデータを伝送するための物理上りリンク共有チャネル（ＰＵＳＣＨ：ＰｈｙｓｉｃａｌＵｐｌｉｎｋＳｈａｒｅｄＣｈａｎｎｅｌ）として用いることができる領域である。

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

（ＰＵＣＣＨ）
ＰＵＣＣＨは、上りリンク制御チャネルに相当する。上述したように、上りリンクにおける各サブフレームにおける周波数方向の両端部にはＰＵＣＣＨ領域が設けられる。ＰＵＣＣＨ領域に含まれる無線リソースは、ＰＵＣＣＨリソースとしてＵＥ１００に割り当てられる。各サブフレームにおける残りの部分にはＰＵＳＣＨ領域が設けられる。ＰＵＳＣＨ領域に含まれる無線リソースは、ＰＵＳＣＨリソースとしてＵＥ１００に割り当てられる。

１つのＰＵＣＣＨリソースは、サブフレーム内の２つのスロットの１リソースブロックずつを用いる。また、サブフレーム内のスロット間で周波数ホッピングが適用されており、スロット間でダイバシティ効果を得ている。ＰＵＣＣＨリソースは、リソースインデックスｍにより識別される。

また、複数のフォーマット（ＰＵＣＣＨフォーマット）がサポートされている。各ＰＵＣＣＨフォーマットは、下記のように、異なる種類の制御信号を運搬する。１サブフレーム内で送信可能な制御信号のビット数は、ＰＵＣＣＨフォーマットごとに異なる。

・ＰＵＣＣＨフォーマット１：ＳＲ
・ＰＵＣＣＨフォーマット１ａ／１ｂ：Ａｃｋ／Ｎａｃｋ
・ＰＵＣＣＨフォーマット２：ＣＱＩ／ＰＭＩ／ＲＩ
・ＰＵＣＣＨフォーマット２ａ／２ｂ：ＣＱＩ／ＰＭＩ／ＲＩ及びＡｃｋ／Ｎａｃｋ

さらに、多数のＡｃｋ／Ｎａｃｋを伝送するためのＰＵＣＣＨフォーマット３が規定されている。

変調方式及びサブフレーム当たりビット数については、下記の表１のように規定されている。

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

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

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

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

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

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

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

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

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

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

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

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

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

（一般的な上りリンクの送信手順）
図８は、一般的な上りリンクの送信手順を説明するための図である。図８において、ＵＥ１００は、ｅＮＢ２００とのＲＲＣ接続を確立した状態（すなわち、ＲＲＣコネクテッドモード）にある。

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

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

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

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

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

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

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

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

図８（Ｂ）は、ＵＥ１００に割り当てられる上りリンクリソース（ＰＵＳＣＨ）を示す。図８（Ｂ）において、ＵＥ１００がＴＣＰＡＣＫを生成したタイミングを「Ｔ１」と表記している。「Ｔ１」において、ＴＣＰＡＣＫのデータ量に対して適切な量のＰＵＳＣＨリソースが割り当てられることが理想的なリソース割り当て（ｉｄｅａｌａｌｌｏｃａｔｉｏｎ）である。

図８（Ｂ）に示すように、ＳＲ及びＢＳＲを用いる一般的な上りリンクの送信手順（Ｓｉｍｐｌｅａｌｌｏｃａｔｉｏｎ）においては、理想的な割り当てタイミングである「Ｔ１」よりも後のタイミング「Ｔ２」において、上りリンクデータのためのＰＵＳＣＨリソースが割り当てられている。このような割り当ては、理想的な割り当てタイミングに対して、遅すぎる割り当て（Ｔｏｏｌａｔｅａｌｌｏｃａｔｉｏｎ）である。このような遅すぎる割り当ての場合、上りリンクのレイテンシを低減することができない。

これに対し、Ｐｒｅ−ｇｒａｎｔを用いる上りリンクの送信手順においては、理想的な割り当てタイミングである「Ｔ１」よりも前のタイミング「Ｔ０」において、上りリンクデータのためのＰＵＳＣＨリソースが割り当てられている。このような割り当ては、理想的な割り当てタイミングに対して、早過ぎる割り当て（Ｔｏｏｅａｒｌｙａｌｌｏｃａｔｉｏｎ）である。このような早過ぎる割り当ての場合、ＵＥ１００の上りリンクデータ量が不明な状態でＵＥ１００にＰＵＳＣＨリソースが割り当てられる。このため、割り当てリソース量が過多（Ｔｏｏｍｕｃｈａｌｌｏｃａｔｉｏｎ）又は過小（Ｔｏｏｌｅｓｓａｌｌｏｃａｔｉｏｎ）になり得る。

（実施形態に係る上りリンクの送信手順）
図９は、実施形態に係る上りリンクの送信手順を説明するための図である。図９において、ＵＥ１００は、ｅＮＢ２００とのＲＲＣ接続を確立した状態（すなわち、ＲＲＣコネクテッドモード）にある。ここでは、図８（Ａ）との相違点を主として説明する。

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

ステップＳ１２において、ｅＮＢ２００は、ＰＤＣＣＨリソースを用いて、ＰＤＳＣＨリソースをＵＥ１００に割り当てる。また、ｅＮＢ２００は、ＰＤＳＣＨリソースを用いて、ＥＰＣ２０から受信したＴＣＰパケットに対応する下りリンクデータをＵＥ１００に送信する。

ステップＳ１３において、ＵＥ１００は、ＰＵＳＣＨリソースの割り当てを要求するためのＳＲを、ＰＵＣＣＨリソースを用いてｅＮＢ２００に送信する。実施形態において、ＵＥ１００は、ＵＥ１００の送信バッファ内の上りリンクデータの量を示すバッファ情報をＳＲに含める。以下において、このようなＳＲを「ＳＲｗ／ＢＳＲ」と称する。「ＳＲｗ／ＢＳＲ」は、ＢＳＲの機能が追加されたＳＲである。「ＳＲｗ／ＢＳＲ」を導入することにより、ＢＳＲ手順（図８のステップＳ５及びＳ６）を省略することができる。このため、理想的な割り当てタイミングに近いタイミングでｅＮＢ２００が適切な量のＰＵＳＣＨリソースをＵＥ１００に割り当て可能となる。なお、一般的なＢＳＲはＰＵＳＣＨリソースを用いて送信されるが、「ＳＲｗ／ＢＳＲ」はＰＵＣＣＨリソースを用いて送信されることに留意すべきである。

「ＳＲｗ／ＢＳＲ」に含まれるバッファ情報は、ＵＥ１００の送信バッファ内の上りリンクデータの大凡の量を示すインデックスである。このようなインデックスを用いることにより、「ＳＲｗ／ＢＳＲ」のデータ量（ビット長）を削減することができる。実施形態において、当該バッファ情報（インデックス）は、ＰＵＳＣＨリソースを用いて送信される他のバッファ情報（すなわち、通常のＢＳＲに含まれるバッファ情報）のビット長とは異なるビット長を有する。具体的には、「ＳＲｗ／ＢＳＲ」に含まれるバッファ情報は、通常のＢＳＲに含まれるバッファ情報に比べてビット長が短い。例えば、「ＳＲｗ／ＢＳＲ」に含まれるバッファ情報は２ビットのビット長を有し、通常のＢＳＲに含まれるバッファ情報は６ビットのビット長を有する。

例えば、インデックス「００」は「１００バイト未満」を表し、インデックス「０１」は「１００バイト以上５００バイト未満」を表し、インデックス「１０」は「５００バイト以上５００ｋバイト未満」を表し、インデックス「１１」は「５００ｋバイト以上１Ｍバイト未満」を表す。このようなインデックスを用いる場合、バッファ情報のビット長は２ビットである。このような「ＳＲｗ／ＢＳＲ」用のインデックスとバッファ量との対応関係は、ｅＮＢ２００からＲＲＣシグナリング等により設定されてもよい。例えばＲＲＣ設定で、インデックス「００」、「０１」、「１０」、「１１」のそれぞれの上限値及び／又は下限値を設定する。

或いは、インデックスは、表３に示したようなＢＳＲテーブルを指定するものでもよい。この指定は、ｅＮＢ２００からＵＥ１００に設定される、又はＵＥ１００に事前設定（Ｐｒｅｃｏｎｆｉｇｕｒｅ）される。例えば、インデックス「００」はＢＳＲテーブル中の「Ｉｎｄｅｘ０〜１５」を表し、インデックス「０１」はＢＳＲテーブル中の「Ｉｎｄｅｘ１６〜３１」を表し、インデックス「１０」はＢＳＲテーブル中の「Ｉｎｄｅｘ３２〜４７」を表し、インデックス「１１」はＢＳＲテーブル中の「Ｉｎｄｅｘ４８〜６３」を表す。なお、ここではＢＳＲテーブルを４等分する一例を示したが、４等分に限定されない。このような「ＳＲｗ／ＢＳＲ」用のインデックスとＢＳＲテーブル中のＩｎｄｅｘとの対応関係は、ｅＮＢ２００からＲＲＣシグナリング等により設定されてもよい。

「ＳＲｗ／ＢＳＲ」は、バッファ情報を含まない通常のＳＲの送信に用いられるＰＵＣＣＨフォーマット（ＰＵＣＣＨフォーマット１）とは異なる特定のＰＵＣＣＨフォーマットを用いて送信される。特定のＰＵＣＣＨフォーマットとは、例えば、新たなＰＵＣＣＨフォーマット１ｃである。ＰＵＣＣＨフォーマット１ｃには、ＢＰＳＫ（１ビット）又はＱＰＳＫ（2ビット）が適用される。このビットを「ＳＲｗ／ＢＳＲ」にマッピングし、ＰＵＣＣＨフォーマット１ｃが送信された場合、ｅＮＢ２００は、受信したＰＵＣＣＨが「ＳＲｗ／ＢＳＲ」を含んでいると認識する。

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

（実施形態のまとめ）
実施形態によれば、「ＳＲｗ／ＢＳＲ」を導入することにより、ＢＳＲ手順（図８のステップＳ５及びＳ６）を省略することができる。このため、理想的な割り当てタイミングに近いタイミングでｅＮＢ２００が適切な量のＰＵＳＣＨリソースをＵＥ１００に割り当て可能となる。

［実施形態の変更例１］
本変更例は、上述した実施形態に係る動作を適切に制御するための方法に関する。図１０は、本変更例に係る動作を示す図である。図１０の初期状態において、ＵＥ１００は、ｅＮＢ２００のセルにおいてＲＲＣコネクティッドモードである。

図１０に示すように、ＵＥ１００は、「ＳＲｗ／ＢＳＲ」を送信する機能をＵＥ１００が有することを示す能力情報（ＵＥＣａｐａｂｉｌｉｔｙＩｎｆｏｒｍａｔｉｏｎ）をｅＮＢ２００に送信する（ステップＳ１０１）。ｅＮＢ２００は、「ＵＥＣａｐａｂｉｌｉｔｙＩｎｆｏｒｍａｔｉｏｎ」を受信する。但し、ｅＮＢ２００は、「ＵＥＣａｐａｂｉｌｉｔｙＩｎｆｏｒｍａｔｉｏｎ」をＵＥ１００から受信せずに、「ＵＥＣａｐａｂｉｌｉｔｙＩｎｆｏｒｍａｔｉｏｎ」をＭＭＥ３００から取得してもよい。ｅＮＢ２００は、「ＵＥＣａｐａｂｉｌｉｔｙＩｎｆｏｒｍａｔｉｏｎ」に基づいて、「ＳＲｗ／ＢＳＲ」を送信する機能をＵＥ１００が有することを確認する。

或いは、ＵＥ１００は、高速上りリンクアクセスに興味を持つことを示す興味通知をｅＮＢ２００に送信してもよい。興味通知は、高速上りリンクアクセスに関する設定（すなわち、「ＳＲｗ／ＢＳＲ」の設定）を要求する設定要求とみなすこともできる。興味通知は、ＲＲＣメッセージの一種である「ＵＥＡｓｓｉｓｔａｎｃｅＩｎｆｏｒｍａｔｉｏｎ」によりＵＥ１００からｅＮＢ２００に送信されてもよい。なお、ＵＥ１００は、「ＵＥＣａｐａｂｉｌｉｔｙＩｎｆｏｒｍａｔｉｏｎ」及び興味通知（ＵＥＡｓｓｉｓｔａｎｃｅＩｎｆｏｒｍａｔｉｏｎ）のうち、何れか一方のみ又は両方をｅＮＢ２００に送信してもよい。これによって、ｅＮＢ２００は、「ＳＲｗ／ＢＳＲ」を送信する機能をＵＥ１００が有することを確認してもよい。

ｅＮＢ２００は、各種のパラメータを含む設定情報（Ｃｏｎｆｉｇｕｒａｔｉｏｎｓ）をＵＥ１００に送信する（ステップＳ１０２）。各種のパラメータは、「ＳＲｗ／ＢＳＲ」の設定に関するパラメータを含む。ＵＥ１００は、Ｃｏｎｆｉｇｕｒａｔｉｏｎｓ（各種のパラメータ）を記憶する。ｅＮＢ２００及びＵＥ１００は、データの送受信を開始する。この時点では、「ＳＲｗ／ＢＳＲ」の送信が有効化されていない状態（ｄｅａｃｔｉｖｅ）である。

ｅＮＢ２００は、「ＳＲｗ／ＢＳＲ」の送信を有効化する指示（ＳＲｗ／ＢＳＲＯＮ）をＵＥ１００に送信する（ステップＳ１０３）。「ＳＲｗ／ＢＳＲＯＮ」は、新たなＤＣＩフォーマットにより識別されてもよい。すなわち、ＵＥ１００は、新たなＤＣＩフォーマットが適用されたＤＣＩを「ＳＲｗ／ＢＳＲＯＮ」と解釈する。或いは、「ＳＲｗ／ＢＳＲＯＮ」は、ＤＣＩ中のビットフィールドに含まれるフラグであってもよい。ＵＥ１００は、「ＳＲｗ／ＢＳＲＯＮ」の受信に応じて、「ＳＲｗ／ＢＳＲ」の送信を有効化する。

その後、ｅＮＢ２００は、「ＳＲｗ／ＢＳＲ」の送信を無効化する指示（ＳＲｗ／ＢＳＲＯＦＦ）をＵＥ１００に送信する（ステップＳ１０４）。「ＳＲｗ／ＢＳＲＯＦＦ」は、新たなＤＣＩフォーマットにより識別されてもよい。すなわち、ＵＥ１００は、「ＳＲｗ／ＢＳＲ」の送信を有効化した後において、新たなＤＣＩフォーマットが適用されたＤＣＩを受信すると、当該ＤＣＩを「ＳＲｗ／ＢＳＲＯＦＦ」と解釈する。或いは、「ＳＲｗ／ＢＳＲＯＦＦ」は、ＤＣＩ中のビットフィールドに含まれるフラグであってもよい。ＵＥ１００は、「ＳＲｗ／ＢＳＲＯＦＦ」の受信に応じて、「ＳＲｗ／ＢＳＲ」の送信を無効化（ｄｅａｃｔｉｖａｔｅ）する。その後、ＵＥ１００は、「ＳＲｗ／ＢＳＲ」の設定に関するパラメータを保持してもよい。

［実施形態の変更例２］
上述した実施形態の変更例１において、ＵＥ１００は、ｅＮＢ２００からの指示に応じて、「ＳＲｗ／ＢＳＲ」の送信を有効化又は無効化していた。

これに対し、本変更例において、ＵＥ１００は、自身の送信バッファ状態に応じて、「ＳＲｗ／ＢＳＲ」の送信を有効化又は無効化する。例えば、ＵＥ１００は、ＢＳＲの送信トリガと同様に、バッファ量の増加をトリガとして「ＳＲｗ／ＢＳＲ」の送信を有効化してもよい。或いは、ＵＥ１００は、元々ＵＥ１００の送信バッファにデータがなかった状態から、データが発生した状態に変化した際に、「ＳＲｗ／ＢＳＲ」の送信を有効化してもよい。

［実施形態の変更例３］
上述した実施形態において、「ＳＲｗ／ＢＳＲ」について「ＬＣＧＩＤ」を特に考慮していなかった。本変更例において、「ＳＲｗ／ＢＳＲ」に「ＬＣＧＩＤ」を関連付ける方法について説明する。

第１の方法は、単純に「ＬＣＧＩＤ」も通知する方法である。ＵＥ１００は、既存のＢＳＲと同様に、「ＳＲｗ／ＢＳＲ」を「ＬＣＧＩＤ」と紐づけて送信する。しかしながら、第１の方法は、オーバーヘッドの観点から好ましくない。

第２の方法は、「ＳＲｗ／ＢＳＲ」に４つ分のバッファ情報（バッファサイズ）を含める。ＵＥ１００は、既存の「ＬｏｎｇＢＳＲ」と同様に、４つ分のバッファ情報をまとめて送信する。第２の方法も、オーバーヘッドの観点から好ましくない。

第３の方法は、４つのＬＣＧの全体量（トータル値）を示すバッファ情報を「ＳＲｗ／ＢＳＲ」に含めて送信する方法である。この方法であれば、オーバーヘッドの増大を抑制することができる。また、ＳＲを送信するまではバッファは空であるため、上りリンクデータを早く送信するという主旨に照らせば、ＬＣＧ（ＬＣＧＩＤ）ごとにバッファ情報を分ける必要性は低いと考えられる。

第４の方法は、予め決められた１つのＬＣＧ（ＬＣＧＩＤ）のみ「ＳＲｗ／ＢＳＲ」の送信を許可する方法である。例えば、「ＬＣＧ＃０」と予め決められる。或いは、ＲＲＣ設定でｅＮＢ２００がＵＥ１００に当該１つのＬＣＧ（ＬＣＧＩＤ）を指定する。この場合、オプションとして、複数のＬＣＧ（ＬＣＧＩＤ）が指定された際に、第３の方法に切り替えてトータル値を報告してもよい。

［その他の実施形態］
「ＳＲｗ／ＢＳＲ」に含まれるバッファ情報は、ＵＥ１００における送信待ちの「ＴＣＰＡＣＫ」の数を表すインデックスであってもよい。例えば、インデックス「００」は１つのＴＣＰＡＣＫに相当するデータ量を表し、インデックス「０１」は２つのＴＣＰＡＣＫに相当するデータ量を表し、インデックス「０１」は２つのＴＣＰＡＣＫに相当するデータ量を表し、インデックス「１１」は３つのＴＣＰＡＣＫに相当するデータ量を表す。このような対応関係は、ＬＴＥシステムの仕様により予め規定されていてもよい。或いは、このような対応関係をｅＮＢ２００からＵＥ１００に対してＲＲＣシグナリング等により指定してもよい。

上述した実施形態において、主にＴＣＰＡＣＫの高速アクセス技術の例を説明したが、これに限定されない。上述した実施形態に係る「ＳＲｗ／ＢＳＲ」をＴＣＰＡＣＫ以外の用途に適用することが可能である。例えば、高速アクセスや高い信頼性を要求する通信に「ＳＲｗ／ＢＳＲ」を適用することが可能である。

また、上述した実施形態において、主に上りリンクのリソース割当について例示していたが、これに限定されない。例えば、「ＳＲｗ／ＢＳＲ」をサイドリンク（例えばＤ２Ｄ通信）のリソース割当に適用する事が可能である。この場合、ＰＤＣＣＨ（もしくはＲＲＣシグナリング）によって、サイドリンクリソースの割り当てを行う際に、「ＳＲｗ／ＢＳＲ」を適用することが可能である。

上述した実施形態において、ＵＥ１００からネットワークに通知されるＵＥ能力情報（ＵＥｃａｐａｂｉｌｉｔｙ）について特に触れなかった。しかしながら、「ＳＲｗｉｔｈＢＳＲ」を適用するＵＥは、「ＳＲｗｉｔｈＢＳＲ」の能力を有することを直接示すｃａｐａｂｉｌｉｔｙで特定される以外に、例えばＶ２Ｘサービス対応ＵＥやＶ２Ｘサービス実行中ＵＥに対して「ＳＲｗｉｔｈＢＳＲ」を適用してもよい。

上述した実施形態において、ＵＥ１００が「ＳＲｗｉｔｈＢＳＲ」を送信するトリガとして、ＤＬＴＣＰパケットの受信に触れていた。しかしながら、これは必須ではなく、純粋にＵＥ内で生成されたパケットをトリガとしてもよい。また、送信パケットが生成される前にＵＥがパケットの生成タイミングを予測してトリガしてもよい。このような予測は、例えば、ＩＴＳ分野でのＣＡＭ（ＣｏｏｐｅｒａｔｉｖｅＡｗａｒｅｎｅｓｓＭｅｓｓａｇｅ）メッセージのように、車両速度に応じて送信周期が決まるようなメッセージ等に好適である。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Claims

ＰＵＳＣＨリソースを用いて上りリンクデータを基地局に送信する無線端末であって、
前記ＰＵＳＣＨリソースの割り当てを要求するためのスケジューリング要求を、ＰＵＣＣＨリソースを用いて前記基地局に送信する処理を行う制御部を備え、
前記スケジューリング要求は、前記無線端末の送信バッファ内の前記上りリンクデータの量を示すバッファ情報を含む、
無線端末。
前記バッファ情報は、前記送信バッファ内の前記上りリンクデータの大凡の量を示すインデックスである、
請求項１に記載の無線端末。
前記インデックスは、ＰＵＳＣＨリソースを用いて送信される他のバッファ情報のビット長とは異なるビット長を有する、
請求項２に記載の無線端末。
前記インデックスと前記大凡の量との対応関係は、前記基地局から設定される、
請求項２に記載の無線端末。
前記バッファ情報を含む前記スケジューリング要求は、前記バッファ情報を含まないスケジューリング要求の送信に用いられるＰＵＣＣＨフォーマットとは異なる特定のＰＵＣＣＨフォーマットを用いて送信される、
請求項１に記載の無線端末。
前記バッファ情報は、複数の論理チャネルグループの全体の上りリンクデータ量を示す、
請求項１に記載の無線端末。
前記バッファ情報は、複数の論理チャネルグループのうち特定の論理チャネルグループにおける上りリンクデータ量を示す、
請求項１に記載の無線端末。
ＰＵＳＣＨリソースを用いて上りリンクデータを無線端末から受信する基地局であって、
前記ＰＵＳＣＨリソースの割り当てを要求するためのスケジューリング要求を、ＰＵＣＣＨリソースを用いて前記無線端末から受信する処理を行う制御部を備え、
前記スケジューリング要求は、前記無線端末の送信バッファ内の前記上りリンクデータの量を示すバッファ情報を含む、
基地局。
ＰＵＳＣＨリソースを用いて上りリンクデータを基地局に送信する無線端末を制御するプロセッサであって、
前記ＰＵＳＣＨリソースの割り当てを要求するためのスケジューリング要求を、ＰＵＣＣＨリソースを用いて前記基地局に送信する処理を実行し、
前記スケジューリング要求は、前記無線端末の送信バッファ内の前記上りリンクデータの量を示すバッファ情報を含む、
プロセッサ。