JP7297811B2 - 通信制御方法、無線端末、及び基地局 - Google Patents

Description

本発明は、移動通信システムにおける通信制御方法、無線端末、及び基地局に関する。

近年、人が介在することなく通信を行うＭＴＣ（Ｍａｃｈｉｎｅ Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）及びＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）サービスを対象とした無線端末が注目されている。このような無線端末は、低コスト化、カバレッジ拡張、及び低消費電力化を実現することが求められる。このため、３ＧＰＰ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）において、システム送受信帯域の一部のみに送受信帯域幅を制限した新たな無線端末のカテゴリが仕様化されている。

ＭＴＣやＩｏＴを対象とした無線端末は、一般的な無線端末に比べて、送受信すべきデータの量が少なく、データの送受信を行う頻度も少ない。よって、ＭＴＣやＩｏＴを対象とした無線端末が効率的に通信を行うために、ランダムアクセスプロシージャ中に所定メッセージを利用してユーザデータを送信するアーリーデータ伝送（ｅａｒｌｙ ｄａｔａ ｔｒａｎｓｍｉｓｓｉｏｎ）が検討されている。

しかしながら、現状の移動通信システムはランダムアクセスプロシージャ中にユーザデータを送信することを想定しておらず、アーリーデータ伝送を実現可能とする仕組みが存在しない。

一実施形態に係る通信制御方法は、ランダムアクセスプロシージャ中にユーザデータの送受信を行うアーリーデータ伝送を制御するための方法である。前記通信制御方法は、無線端末が、前記ランダムアクセスプロシージャ中に前記無線端末がＭｓｇ３を送信してからＭｓｇ４を受信するまでの最大待ち時間を設定するためのタイマ値を基地局から受信するステップＡと、前記無線端末が、前記無線端末が前記Ｍｓｇ３を送信してから前記Ｍｓｇ４と共にユーザデータを受信するまでの所要時間の予測値を導出するステップＢと、前記無線端末が、前記ステップＡにおいて受信した前記タイマ値と前記ステップＢにおいて導出した前記予測値とに基づいて、前記アーリーデータ伝送を伴う前記ランダムアクセスプロシージャを開始するか否かを判断するステップＣと、を備える。

一実施形態に係る通信制御方法は、ランダムアクセスプロシージャ中にユーザデータの送受信を行うアーリーデータ伝送を制御するための方法である。前記通信制御方法は、無線端末が、前記アーリーデータ伝送を確率的に規制するための規制信号を基地局から受信するステップＡと、前記無線端末が、前記ステップＡにおいて受信した前記規制信号に基づいて、前記無線端末が前記アーリーデータ伝送を利用可能か否か判断するステップＢと、前記無線端末が、前記ステップＢにおいて前記アーリーデータ伝送を利用可能であると判断したことに応じて、前記アーリーデータ伝送を伴う前記ランダムアクセスプロシージャを開始するステップＣと、を備える。

実施形態に係るＬＴＥシステム（移動通信システム）の構成を示す図である。 実施形態に係るＵＥ（無線端末）の構成を示す図である。 実施形態に係るｅＮＢ（基地局）の構成を示す図である。 実施形態に係るＬＴＥシステムにおける無線インターフェイスのプロトコルスタックを示す図である。 実施形態に係るＬＴＥシステムの無線フレームの構成を示す図である。 ｅＭＴＣ ＵＥ及びＮＢ－ＩｏＴ ＵＥが取り扱う周波数チャネルの一例を示す図である。 ｅＭＴＣ ＵＥ及びＮＢ－ＩｏＴ ＵＥ向けのランダムアクセスプロシージャの一例を示す図である。 第１実施形態に係るＵＥの動作の一例を示す図である。 第２実施形態に係るＵＥの動作の一例を示す図である。

一実施形態に係る移動通信システムについて図面を参照しながら説明する。以下の図面の記載において、同一又は類似の部分には、同一又は類似の符号を付している。

［第１実施形態］
（移動通信システム）
本実施形態に係る移動通信システムの構成について説明する。図１は、本実施形態に係る移動通信システムであるＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）システムの構成を示す図である。ＬＴＥシステムは、３ＧＰＰ規格に基づく移動通信システムである。

ＬＴＥシステムは、無線端末（ＵＥ：Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）１００、無線アクセスネットワーク（Ｅ－ＵＴＲＡＮ：Ｅｖｏｌｖｅｄ－ＵＭＴＳ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）１０、及びコアネットワーク（ＥＰＣ：Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｃｏｒｅ）２０を備える。

ＵＥ１００は、移動型の通信装置である。ＵＥ１００は、自身が在圏するセル（サービングセル）を管理するｅＮＢ２００との無線通信を行う。

Ｅ－ＵＴＲＡＮ１０は、基地局（ｅＮＢ：ｅｖｏｌｖｅｄ Ｎｏｄｅ－Ｂ）２００を含む。ｅＮＢ２００は、Ｘ２インターフェイスを介して相互に接続される。ｅＮＢ２００は、１又は複数のセルを管理する。ｅＮＢ２００は、自セルとの接続を確立したＵＥ１００との無線通信を行う。ｅＮＢ２００は、無線リソース管理（ＲＲＭ）機能、ユーザデータ（以下、適宜「データ」という）のルーティング機能、モビリティ制御・スケジューリングのための測定制御機能等を有する。「セル」は、無線通信エリアの最小単位を示す用語として用いられる。「セル」は、ＵＥ１００との無線通信を行う機能又はリソースを示す用語としても用いられる。１つのセルは１つのキャリア周波数に属する。

ＥＰＣ２０は、モビリティ管理エンティティ（ＭＭＥ）及びサービングゲートウェイ（Ｓ－ＧＷ）３００を含む。ＭＭＥは、ＵＥ１００に対する各種モビリティ制御等を行う。ＭＭＥは、ＮＡＳ（Ｎｏｎ－Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ）シグナリングを用いてＵＥ１００と通信することにより、ＵＥ１００が在圏するトラッキングエリア（ＴＡ）の情報を管理する。トラッキングエリアは、複数のセルからなるエリアである。Ｓ－ＧＷは、データの転送制御を行う。ＭＭＥ及びＳ－ＧＷは、Ｓ１インターフェイスを介してｅＮＢ２００と接続される。

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

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

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

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

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

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

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

制御部２３０は、ｅＮＢ２００における各種の制御を行う。制御部２３０は、少なくとも１つのプロセッサ及びメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサと、ＣＰＵと、を含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。ＣＰＵは、メモリに記憶されるプログラムを実行して各種の処理を行う。プロセッサは、後述する処理を実行する。

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

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

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

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

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

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

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

ＲＲＣレイヤの上位に位置するＮＡＳレイヤは、セッション管理及びモビリティ管理等を行う。ＵＥ１００のＮＡＳレイヤとＭＭＥ３００ＣのＮＡＳレイヤとの間では、ＮＡＳシグナリングが伝送される。ＵＥ１００は、無線インターフェイスのプロトコル以外にアプリケーションレイヤ等の機能を有する。

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

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

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

（ｅＭＴＣ及びＮＢ－ＩｏＴの概要）
ｅＭＴＣ及びＮＢ－ＩｏＴの概要について説明する。本実施形態において、ＭＴＣ及びＩｏＴサービスを対象とした新たなカテゴリのＵＥ１００が存在するシナリオを想定する。新たなカテゴリのＵＥ１００は、システム送受信帯域（ＬＴＥ送受信帯域幅）の一部のみに送受信帯域幅が制限されるＵＥ１００である。新たなＵＥカテゴリは、例えば、カテゴリＭ１及びカテゴリＮＢ（Ｎａｒｒｏｗ Ｂａｎｄ）－ＩｏＴと称される。カテゴリＭ１は、ｅＭＴＣ（ｅｎｈａｎｃｅｄ Ｍａｃｈｉｎｅ Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）ＵＥが属するカテゴリである。カテゴリＮＢ－ＩｏＴ（カテゴリＮＢ１）は、ＮＢ－ＩｏＴ ＵＥが属するカテゴリである。カテゴリＭ１は、ＵＥ１００（ｅＭＴＣ ＵＥ）の送受信帯域幅を例えば１．０８ＭＨｚ（すなわち、６リソースブロックの帯域幅）に制限する。カテゴリＮＢ－ＩｏＴ（カテゴリＮＢ１）は、ＵＥ１００（ＮＢ－ＩｏＴ ＵＥ）の送受信帯域幅を１８０ｋＨｚ（すなわち、１リソースブロックの帯域幅）にさらに制限する。このような狭帯域化により、ｅＭＴＣ ＵＥ及びＮＢ－ＩｏＴ ＵＥに要求される低コスト化及び低消費電力化が実現可能となる。

図６は、ｅＭＴＣ ＵＥ及びＮＢ－ＩｏＴ ＵＥが取り扱う周波数チャネルを示す図である。図６に示すように、ＬＴＥシステムのシステム周波数帯域の周波数帯域幅は１０ＭＨｚであり得る。システム送受信帯域の帯域幅は、例えば、５０リソースブロック＝９ＭＨｚである。ｅＭＴＣ ＵＥが対応可能な周波数チャネルの帯域幅は、６リソースブロック＝１．０８ＭＨｚ以内である。ｅＭＴＣ ＵＥが対応可能な６リソースブロック以内の周波数チャネルは、「狭帯域（ＮＢ：Ｎａｒｒｏｗ Ｂａｎｄ）」と称される。ＮＢ－ＩｏＴ ＵＥが対応可能な周波数チャネルの帯域幅は、１リソースブロック＝１８０ｋＨｚである。ＮＢ－ＩｏＴ ＵＥが対応可能な１リソースブロックの周波数チャネルは、「キャリア（ｃａｒｒｉｅｒ）」と称される。

ｅＭＴＣ ＵＥは、ＬＴＥ送受信帯域幅内で運用される。ＮＢ－ＩｏＴ ＵＥは、ＬＴＥ送受信帯域幅内で運用される形態、ＬＴＥ送受信帯域幅外のガードバンドで運用される形態、及びＮＢ－ＩｏＴ専用の周波数帯域内で運用される形態をサポートする。

ｅＭＴＣ ＵＥ及びＮＢ－ＩｏＴ ＵＥは、カバレッジ拡張を実現するために、繰り返し送信等を用いた強化カバレッジ（ＥＣ：Ｅｎｈａｎｃｅｄ Ｃｏｖｅｒａｇｅ）機能をサポートする。強化カバレッジ機能は、複数のサブフレームを用いて同一信号を繰り返し送信する繰り返し送信（ｒｅｐｅｔｉｔｉｏｎ）を含んでもよい。繰り返し送信の回数が多いほど、カバレッジを拡張することができる。強化カバレッジ機能は、送信信号の電力密度を上げる電力ブースト（ｐｏｗｅｒ ｂｏｏｓｔｉｎｇ）を含んでもよい。一例として、送信信号の周波数帯域幅を狭くする狭帯域送信により電力密度を上げる。送信信号の電力密度を上げるほど、カバレッジを拡張することができる。強化カバレッジ機能は、送信信号に用いるＭＣＳを下げる低ＭＣＳ（ｌｏｗｅｒ ＭＣＳ）送信を含んでもよい。データレートが低く、誤り耐性の高いＭＣＳを用いて送信を行うことにより、カバレッジを拡張することができる。

（ランダムアクセスプロシージャの概要）
図７は、ｅＭＴＣ ＵＥ及びＮＢ－ＩｏＴ ＵＥ向けのランダムアクセスプロシージャを示す図である。初期状態において、ＵＥ１００は、ＲＲＣアイドルモードにある。ＵＥ１００は、ＲＲＣコネクティッドモードに遷移するためにランダムアクセスプロシージャを実行する。このようなケースは、初期接続（Ｉｎｉｔｉａｌ ａｃｃｅｓｓ ｆｒｏｍ ＲＲＣ＿ＩＤＬＥ）と称される。初期接続時には、競合ベース（ｃｏｎｔｅｎｔｉｏｎ ｂａｓｅｄ）のランダムアクセスプロシージャが適用される。

ＵＥ１００は、ｅＮＢ２００のセルをサービングセルとして選択している。ＵＥ１００は、通常のカバレッジのための第１のセル選択基準（第１のＳ－ｃｒｉｔｅｒｉａ）が満たされず、強化カバレッジのための第２のセル選択基準（第２のＳ－ｃｒｉｔｅｒｉａ）が満たされた場合、自身が強化カバレッジに居ると判断してもよい。「強化カバレッジに居るＵＥ」とは、セルにアクセスするために強化カバレッジ機能（強化カバレッジモード）を用いることが必要とされるＵＥを意味する。なお、ｅＭＴＣ ＵＥは、強化カバレッジモードを用いることが必須である。ここでは、ＵＥ１００が強化カバレッジに居ると仮定して説明を進める。

ステップＳ１００１において、ｅＮＢ２００は、ＰＲＡＣＨ（Ｐｈｙｓｉｃａｌ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｃｈａｎｎｅｌ）関連情報をブロードキャストシグナリング（例えば、ＳＩＢ）により送信する。ＰＲＡＣＨ関連情報は、強化カバレッジレベルごとに設けられた各種のパラメータを含む。一例として、強化カバレッジレベルは、強化カバレッジレベル０乃至３の合計４つのレベルが規定される。各種のパラメータは、ＲＳＲＰ（Ｒｅｆｅｒｅｎｃｅ Ｓｉｇｎａｌ Ｒｅｃｅｉｖｅｄ Ｐｏｗｅｒ）閾値、ＰＲＡＣＨリソース、及び最大プリアンブル送信回数を含む。ＰＲＡＣＨリソースは、無線リソース（時間・周波数リソース）及び信号系列（プリアンブル系列）を含む。ＵＥ１００は、受信したＰＲＡＣＨ関連情報を記憶する。

ステップＳ１００２において、ＵＥ１００は、ｅＮＢ２００から送信される参照信号に基づいてＲＳＲＰを測定する。

ステップＳ１００３において、ＵＥ１００は、測定したＲＳＲＰを強化カバレッジレベルごとのＲＳＲＰ閾値と比較することにより、自身の強化カバレッジレベル（ＣＥレベル）を決定する。強化カバレッジレベルは、ＵＥ１００に必要とされる強化カバレッジの度合いを示す。強化カバレッジレベルは、少なくとも繰り返し送信における送信回数（すなわち、Ｒｅｐｅｔｉｔｉｏｎ回数）と関連する。

ステップＳ１００４において、ＵＥ１００は、自身の強化カバレッジレベルに対応するＰＲＡＣＨリソースを選択する。

ステップＳ１００５～Ｓ１００８は、ランダムアクセスプロシージャを構成する。ステップＳ１００５において、ＵＥ１００は、選択したＰＲＡＣＨリソースを用いてＭｓｇ１（ランダムアクセスプリアンブル）をｅＮＢ２００に送信する。なお、「Ｍｓｇ」は、メッセージの略である。ｅＮＢ２００は、受信したＭｓｇ１に用いられたＰＲＡＣＨリソースに基づいて、ＵＥ１００の強化カバレッジレベルを特定する。

ステップＳ１００６において、ｅＮＢ２００は、ＵＥ１００に割り当てたＰＵＳＣＨリソースを示すスケジューリング情報を含むＭｓｇ２（ランダムアクセス応答）をＵＥ１００に送信する。ＵＥ１００は、Ｍｓｇ２を正常に受信するまで、自身の強化カバレッジレベルに対応する最大プリアンブル送信回数までＭｓｇ１を複数回送信し得る。

ステップＳ１００７において、ＵＥ１００は、スケジューリング情報に基づいて、Ｍｓｇ３をｅＮＢ２００に送信する。Ｍｓｇ３は、ＲＲＣ接続要求（ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｑｕｅｓｔ）メッセージであってもよい。

ステップＳ１００８において、ｅＮＢ２００は、Ｍｓｇ４をＵＥ１００に送信する。Ｍｓｇ４は、ＲＲＣ接続確立（ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｓｅｔｕｐ）メッセージであってもよい。

ステップＳ１００９において、ＵＥ１００は、Ｍｓｇ４の受信に応じてＲＲＣコネクティッドモードに遷移する。その際、ＵＥ１００は、Ｍｓｇ ５：ＲＲＣ接続確立完了（ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｓｅｔｕｐ Ｃｏｍｐｌｅｔｅ）メッセージをｅＮＢ２００に送信してもよい。その後、ｅＮＢ２００は、特定した強化カバレッジレベルに基づいて、ＵＥ１００への繰り返し送信等を制御する。

（アーリーデータ伝送の概要）
ｅＭＴＣ ＵＥやＮＢ－ＩｏＴ ＵＥは、送受信すべきデータの量が少なく、データの送受信を行う頻度も少ない。本実施形態において、ｅＭＴＣ ＵＥやＮＢ－ＩｏＴ ＵＥが、ランダムアクセスプロシージャ中に所定メッセージを利用してユーザデータを送受信するアーリーデータ伝送（ＥＤＴ：Ｅａｒｌｙ Ｄａｔａ Ｔｒａｎｓｍｉｓｓｉｏｎ）を行う一例について説明する。

ＥＤＴは、ランダムアクセスプロシージャにおけるＭｓｇ３を利用して上りリンクデータを送受信する上りリンクのＥＤＴと、ランダムアクセスプロシージャにおけるＭｓｇ４を利用して下りリンクデータを送受信する下りリンクのＥＤＴとを含む。具体的には、１つのランダムアクセスプロシージャにおいて、上りリンクのＥＤＴ及び下りリンクのＥＤＴの両方が行われる場合と、上りリンクのＥＤＴのみが行われる場合と、下りリンクのＥＤＴのみが行われる場合とがある。

ＥＤＴには、ＵＰ（Ｕｓｅｒ Ｐｌａｎｅ）ソリューション及びＣＰ（Ｃｏｎｔｒｏｌ Ｐｌａｎｅ）ソリューションの２種類がある。ＵＰソリューションでは、ＥＤＴにおいて、ユーザデータをＲＲＣメッセージに含めずに、ＭＡＣレイヤにおいてユーザデータ（ＤＴＣＨ）とＲＲＣメッセージ（ＣＣＣＨ）とを１つのＭＡＣ ＰＤＵに多重化して送信する。一方で、ＣＰソリューションでは、ＥＤＴにおいて、ユーザデータをＲＲＣメッセージに含める。

ＵＰソリューションは、ＵＥ１００がＲＲＣアイドルモードのサブ状態であるサスペンド状態である場合に適用される。サスペンド状態は、ＵＥ１００のコンテキスト情報がｅＮＢ２００において維持される、ＲＲＣアイドルモードのサブ状態である。ＵＰソリューションでは、Ｍｓｇ３を構成するＲＲＣメッセージがＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｓｕｍｅ Ｒｅｑｕｅｓｔメッセージであり、Ｍｓｇ４を構成するＲＲＣメッセージが基本的にはＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｌｅａｓｅメッセージ又はＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｊｅｃｔメッセージである。ＵＥ１００は、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｌｅａｓｅメッセージを受信すると、ＲＲＣアイドルモードを維持したままランダムアクセスプロシージャを終了する。但し、Ｍｓｇ４を構成するＲＲＣメッセージがＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｓｕｍｅメッセージであり得る。ＵＥ１００は、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｓｕｍｅメッセージを受信すると、ＲＲＣコネクティッドモードに遷移し、ＲＲＣコネクティッドモードにおいてユーザデータを送受信する。

ＣＰソリューションは、ＵＥ１００がＲＲＣアイドルモードであってサスペンド状態ではない場合に適用される。ＣＰソリューションでは、Ｍｓｇ３を構成するＲＲＣメッセージがＥａｒｌｙ Ｄａｔａ Ｒｅｑｕｅｓｔメッセージであり、Ｍｓｇ４を構成するＲＲＣメッセージが基本的にはＥａｒｌｙ Ｄａｔａ Ｃｏｍｐｌｅｔｅメッセージである。ＵＥ１００は、Ｅａｒｌｙ Ｄａｔａ Ｃｏｍｐｌｅｔｅメッセージを受信すると、ＲＲＣアイドルモードを維持したままランダムアクセスプロシージャを終了する。但し、Ｍｓｇ４を構成するＲＲＣメッセージがＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｓｅｔｕｐメッセージであり得る。ＵＥ１００は、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｓｅｔｕｐメッセージを受信すると、ＲＲＣコネクティッドモードに遷移し、ＲＲＣコネクティッドモードにおいてユーザデータを送受信する。

（第１実施形態に係る動作）
ＥＤＴにおいて、ＵＥ１００は、Ｍｓｇ３を利用して上りリンクデータを送信した後、Ｍｓｇ４を利用して下りリンクデータを受信し、ＲＲＣアイドルモードを維持したままランダムアクセスプロシージャを終了し得る。これにより、ＵＥ１００は、ＲＲＣコネクティッドモードに遷移することなくユーザデータの送受信を行うことができるため、ＵＥ１００の消費電力を削減できる。

しかしながら、Ｍｓｇ４を利用して下りリンクのＥＤＴを行う場合、ｅＮＢ２００は、下りリンクデータをコアネットワーク側から受信するまではＭｓｇ４をＵＥ１００に送信できない。その結果、ＵＥ１００においてＭｓｇ４の最大受信待ち時間を規定するタイマが満了し、ＵＥ１００がランダムアクセスプロシージャ失敗と判断し得る。ＵＥ１００は、ランダムアクセスプロシージャ失敗と判断した場合には、ランダムアクセスプロシージャを最初からやり直す。かかる場合、ＵＥ１００の消費電力が増加する。

Ｍｓｇ４の最大受信待ち時間を規定するタイマは、ＵＥ１００のＲＲＣレイヤにおいて管理されるＴ３００であってもよいし、ＵＥ１００のＭＡＣレイヤにおいて管理するコンテンションリゾリューションタイマであってもよい。本実施形態において、かかるタイマがＴ３００である一例について説明するが、かかるタイマがコンテンションレゾリューションタイマであってもよい。

ＵＥ１００は、Ｍｓｇ３の送信時にＴ３００を開始させる。Ｔ３００の値（タイマ値）は、ｅＮＢ２００からＳＩＢによりＵＥ１００に設定される。ＵＥ１００は、自身宛のＭｓｇ４を受信することなくＴ３００が満了すると、ランダムアクセスプロシージャ失敗と判断する。

第１実施形態において、ＵＥ１００は、ランダムアクセスプロシージャを開始するよりも前において、ＵＥ１００がＭｓｇ３を送信してからＭｓｇ４と共にユーザデータを受信するまでの所要時間の予測値を導出する。具体的には、ＵＥ１００は、下りリンクのＥＤＴを行ったと仮定した場合に、Ｍｓｇ３を送信してからＭｓｇ４を受信するまでにどの程度の時間（所要時間）を要するかを判断する。

ＵＥ１００は、ｅＮＢ２００から受信したＴ３００のタイマ値と、導出した予測値とに基づいて、ＥＤＴ（具体的には、下りリンクのＥＤＴ）を伴うランダムアクセスプロシージャを開始するか否かを判断する。例えば、ＵＥ１００は、ｅＮＢ２００から受信したＴ３００のタイマ値よりも、導出した予測値が大きい場合には、ＥＤＴを伴うランダムアクセスプロシージャを開始しないと判断する。これにより、ＵＥ１００が自身宛のＭｓｇ４を受信することなくＴ３００が満了する可能性を低減できるため、ＵＥ１００の消費電力の増大を抑制できる。

図８は、第１実施形態に係るＵＥ１００の動作の一例を示す図である。

図８に示すように、ステップＳ１０１において、ＲＲＣアイドルモードにあるＵＥ１００は、下記の１）～３）の情報をｅＮＢ２００からＳＩＢにより受信する。または、ＵＥ１００は、ＲＲＣアイドルモードになる前のＲＲＣコネクティッドモードにおいて、下記の１）～３）の情報をｅＮＢ２００からＲＲＣメッセージにより受信し、それをＲＲＣアイドルモードに遷移した後も保持しておいてもよい。

１）ＰＲＡＣＨリソース情報：
ｅＮＢ２００のセルにおいて利用可能なＰＲＡＣＨリソースのうち一部がＥＤＴインディケーション用のＰＲＡＣＨリソースとして確保される。例えば、ｅＮＢ２００のセルにおいてＰＲＡＣＨリソースとして利用可能な時間・周波数リソースのうち一部がＥＤＴインディケーション用の時間・周波数リソースとして確保される。ｅＮＢ２００は、ＥＤＴインディケーション用のＰＲＡＣＨリソース（時間・周波数リソース）を示す情報をＳＩＢによりブロードキャストする。ＵＥ１００は、ＥＤＴインディケーション用のＰＲＡＣＨリソースが提供されている場合に、ＥＤＴを利用可能であると判断する。一方、ＵＥ１００は、ＥＤＴインディケーション用のＰＲＡＣＨリソースが提供されていない場合に、ＥＤＴを利用不能であると判断する。ここでは、ＥＤＴインディケーション用のＰＲＡＣＨリソースが提供されていると仮定して説明を進める。

２）ＥＤＴにおけるユーザデータの最大トランスポートブロックサイズ：
ｅＮＢ２００は、上りリンクのＥＤＴにおいてＵＥ１００が送信可能な最大上りリンクデータ量（最大トランスポートブロックサイズ）を示す情報をＳＩＢによりブロードキャストする。ｅＮＢ２００は、下りリンクのＥＤＴにおいてＵＥ１００が送信可能な最大下りリンクデータ量（最大トランスポートブロックサイズ）を示す情報をＳＩＢによりブロードキャストしてもよい。

３）Ｔ３００の設定値（タイマ値）：
Ｔ３００の値（タイマ値）は、ｅＮＢ２００からＳＩＢによりＵＥ１００に設定される。ｅＮＢ２００は、ＥＤＴを伴わないランダムアクセスプロシージャ用のＴ３００のタイマ値（以下、「第１のタイマ値」という）と、ＥＤＴを伴うランダムアクセスプロシージャ用のＴ３００のタイマ値（以下、「第２のタイマ値」という）とを別々にＵＥ１００に設定する。

ステップＳ１０２において、ＵＥ１００は、ランダムアクセスプロシージャの開始トリガを検知する。例えば、ＵＥ１００は、送信すべき上りリンクデータがＵＥ１００において発生したこと、又はＵＥ１００がページングメッセージを受信したこと等に応じて、ランダムアクセスプロシージャを開始すると判断する。なお、ステップＳ１０２の処理は、ステップＳ１０１の前に行われてもよい。なお、ステップＳ１０２の処理をステップＳ１０１の処理よりも前に行う場合には、ＵＥ１００は、ランダムアクセスプロシージャの開始トリガを検知した後に、上記の１）～３）の情報をｅＮＢ２００からＳＩＢにより受信するまでステップＳ１０３の処理の開始を待ってもよい。

ステップＳ１０３において、ＵＥ１００は、自身がｅＮＢ２００に送信しようとする上りリンクデータ量が最大上りリンクデータ量以下であるか否かを判断する。ＵＥ１００は、自身がｅＮＢ２００から受信しようとする下りリンクデータ量が最大下りリンクデータ量以下であるか否かを判断してもよい。ステップＳ１０３において「ＮＯ」である場合、ステップＳ１０８において、ＵＥ１００は、ＥＤＴを伴わないランダムアクセスプロシージャを開始する。具体的には、ＵＥ１００は、ランダムアクセスプロシージャにおけるＭｓｇ１送信時にＥＤＴインディケーションを送信しない。なお、ステップＳ１０３において「ＮＯ」である場合であっても、下りリンクのＥＤＴのみを実行する可能性があるため、ステップＳ１０４に進んでもよい。

ステップＳ１０３において「ＹＥＳ」である場合、ステップＳ１０４において、ＵＥ１００は、下りリンクのＥＤＴを行うか否かを判断する。例えば、ＵＥ１００は、Ｍｓｇ３送信時に、ＡＣＫを必要としない上りリンクユーザデータ（ＵＤＰデータ等）を送信する場合には、下りリンクのＥＤＴを行わないと判断する。ＵＥ１００は、Ｍｓｇ３送信時に、ＡＣＫを必要とする上りリンクユーザデータ（ＴＣＰデータ等）を送信する場合には、下りリンクのＥＤＴを行うと判断する。ステップＳ１０４において「ＮＯ」である場合には、ステップＳ１０５及びＳ１０６の処理が省略されてステップＳ１０７の処理に進む。例えば、ＵＥ１００は、ＵＤＰでの送信を行うことや、アプリケーションの種別に基づいて、上りリンクのＥＤＴに対するサーバからのレスポンス（ＡＣＫ等の下りリンクデータ）が無いと予想した場合に、下りリンクのＥＤＴを行わないと判断し、ステップＳ１０７において上りリンクのＥＤＴを行う。なお、ＵＥ１００は、上りリンクのＥＤＴに対するサーバからのレスポンスが無いと予想した場合には、Ｍｓｇ３送信時にＥＤＴを伴うランダムアクセスプロシージャ用のＴ３００の開始をしなくてもよい。

ステップＳ１０４において「ＹＥＳ」である場合、ステップＳ１０５において、ＵＥ１００は、Ｍｓｇ３を送信してから、Ｍｓｇ４と共にユーザデータを受信するまでの所要時間の予測値を導出する。具体的には、ＵＥ１００は、下りリンクのＥＤＴを行ったと仮定した場合に、Ｍｓｇ３を送信してからＭｓｇ４を受信するまでにどの程度の時間（所要時間）を要するかを判断する。例えば、ＵＥ１００は、下記のａ）～ｄ）の少なくとも１つに基づいて、かかる所要時間の予測値を導出する。

ａ）ＵＥ１００のアクセス層よりも上位の上位層において用いるアプリケーションの種類及び／又はプロトコルの種類：
例えば、ＵＥ１００は、アプリケーションの要求ＱｏＳが高い場合（すなわち、低遅延の場合）は応答（Ｍｓｇ４）が速い（すなわち、ＵＥ１００がＭｓｇ３をｅＮＢ２００へ送信してからｅＮＢ２００から応答（Ｍｓｇ４）を受信するまでに掛かる時間（所用時間）が短い）、アプリケーションの要求ＱｏＳが低い（すなわち、高遅延）の場合は応答（Ｍｓｇ４）が遅い（すなわち、ＵＥ１００がＭｓｇ３をｅＮＢ２００へ送信してからｅＮＢ２００から応答（Ｍｓｇ４）を受信するまでに掛かる時間（所要時間）が長い）と判断してもよい。或いは、アプリケーションの種類及び／又はプロトコルの種類に対応する所要時間の予測値が予めＵＥ１００に設定されており、かかる事前設定された所要時間の予測値を取得してもよい。かかる処理は、ＵＥ１００のＡＳレイヤ（具体的には、ＲＲＣレイヤ以下のレイヤ）において行われてもよいし、ＵＥ１００の上位レイヤ（具体的には、ＲＲＣよりも上のレイヤ）において行われてもよい。

ｂ）ＵＥ１００のアクセス層（ＡＳレイヤ）において用いるベアラの種類及び／又は論理チャネルの種類：
例えば、ＵＥ１００は、ベアラの種類及び／又は論理チャネルの種類に対応する所要時間の予測値（すなわち、Ｍｓｇ３を送信してからＭｓｇ４を受信するまでにかかる時間（所用時間）の予測値）が予めＵＥ１００に設定されており、かかる事前設定された所用時間の予測値を取得する。かかる判断は、ＵＥ１００のＡＳレイヤにおいて行われてもよい。なお、ベアラは要求ＱｏＳと関連付けられており、論理チャネルはベアラと関連付けられている。

ｃ）過去の所要時間の履歴を用いた統計：
ＵＥ１００は、過去の所要時間（具体的には、Ｍｓｇ３を送信してから、Ｍｓｇ４と共にユーザデータを受信するまでに実際に掛かった時間）の履歴を記憶し、この履歴に対する統計処理を行うことにより、今回の所要時間の予測値を算出する。かかる判断は、ＵＥ１００のＡＳレイヤにおいて行われてもよい。

ｄ）ＵＥ１００がＥＤＴによりｅＮＢ２００に送信する上りリンクユーザデータの量及び／又はＵＥ１００がＥＤＴによりｅＮＢ２００から受信する下りリンクユーザデータの量：
例えば、上りリンクのユーザデータ量に応じてサーバ側の処理時間が変わるため、ＵＥ１００は、上りリンクのユーザデータ量が多いほど応答（Ｍｓｇ４）が遅い（すなわち、ＵＥ１００がＭｓｇ３をｅＮＢ２００へ送信してからｅＮＢ２００から応答（Ｍｓｇ４）を受信するまでに掛かる時間（所用時間）が長い）と判断してもよい。或いは、ＵＥ１００のＡＳレイヤは、上りリンクのユーザデータ量に応じてアプリケーションを推測し、上記ａ）と同様な処理を行ってもよい。ＵＥ１００は、下りリンクのユーザデータ量が多いほど応答（Ｍｓｇ４）が遅い（すなわち、ＵＥ１００がＭｓｇ３をｅＮＢ２００へ送信してからｅＮＢ２００から応答（Ｍｓｇ４）を受信するまでに掛かる時間（所用時間）が長い）と判断してもよい。

ステップＳ１０６において、ＵＥ１００は、ステップＳ１０５において導出した所用時間の予測値が、ステップＳ１０１において受信したタイマ値（第２のタイマ値）以下であるか否かを判断する。

ステップＳ１０６において「ＹＥＳ」である場合、ステップＳ１０７において、ＵＥ１００は、ＥＤＴ（少なくとも下りリンクのＥＤＴ）を伴うランダムアクセスプロシージャを開始する。具体的には、ＵＥ１００は、ランダムアクセスプロシージャにおけるＭｓｇ１送信時にＥＤＴインディケーションを送信する。なお、ステップＳ１０４において、下りリンクのＥＤＴを行わないとＵＥ１００が判断した場合、ＵＥ１００は、下りリンクのＥＤＴを行わない旨をＭｓｇ３又はＭｓｇ１送信時にｅＮＢ２００に通知してもよい。これにより、ｅＮＢ２００は、Ｍｓｇ４を素早く送信することができるため、処理の遅延による負荷増大を防ぐことができると共に、ＵＥ１００は、待ち受け消費電力を最小化することができる。下りリンクのＥＤＴを行わない旨の情報は、ＲＲＣメッセージに含められるフラグ（例えば、「ｎｏ ＤＬ ｄａｔａ ｅｘｐｅｃｔｅｄ」など）であってもよいし、ＭＡＣ ＣＥ（Ｃｏｎｔｒｏｌ Ｅｌｅｍｅｎｔ）におけるＭＡＣサブヘッダで当該情報を伝えてもよい。

ステップＳ１０６において「ＮＯ」である場合、ステップＳ１０８において、ＵＥ１００は、ＥＤＴを伴わないランダムアクセスプロシージャを開始する。具体的には、ＵＥ１００は、ランダムアクセスプロシージャにおけるＭｓｇ１送信時にＥＤＴインディケーションを送信しない。

（第１実施形態のまとめ）
上述した第１実施形態に係る動作は、以下のように要約できる。

ランダムアクセスプロシージャ中にユーザデータの送受信を行うＥＤＴを制御するための通信制御方法は、ＵＥ１００が、ランダムアクセスプロシージャ中にＵＥ１００がＭｓｇ３を送信してからＭｓｇ４を受信するまでの最大待ち時間を設定するためのタイマ値をｅＮＢ２００から受信するステップＡ（ステップＳ１０１）と、ＵＥ１００が、ＵＥ１００がＭｓｇ３を送信してからＭｓｇ４を受信するまでの所要時間の予測値を導出するステップＢ（ステップＳ１０５）と、ＵＥ１００が、ステップＡにおいて受信したタイマ値とステップＢにおいて導出した予測値とに基づいて、ＥＤＴを伴うランダムアクセスプロシージャを開始するか否かを判断するステップＣ（ステップＳ１０６）と、を備える。

ステップＣにおいて、ＵＥ１００は、ステップＡにおいて受信したタイマ値よりも、ステップＢにおいて導出した予測値が大きい場合（ステップＳ１０６：ＮＯ）に、ＥＤＴを伴うランダムアクセスプロシージャを開始しないと判断する。

ＵＥ１００は、ステップＣにおいてＥＤＴを伴うランダムアクセスプロシージャを開始しないと判断したことに応じて、ＥＤＴを伴わないランダムアクセスプロシージャを開始する（ステップＳ１０８）。

ステップＢにおいて、ＵＥ１００は、ａ）ＵＥ１００のアクセス層よりも上位の上位層において用いるアプリケーションの種類及び／又はプロトコルの種類、ｂ）ＵＥ１００のアクセス層において用いるベアラの種類及び／又は論理チャネルの種類、ｃ）過去の前記所要時間の履歴を用いた統計、ｄ）ＵＥ１００がＥＤＴによりｅＮＢ２００に送信する上りリンクユーザデータの量及び／又はＵＥ１００がＥＤＴによりｅＮＢ２００から受信する下りリンクユーザデータの量、のうち少なくとも１つに基づいて、予測値を導出する。

ＵＥ１００は、Ｍｓｇ４と共に下りリンクのユーザデータをｅＮＢ２００から受信する下りリンクのＥＤＴを行うか否かを判断する（ステップＳ１０４）。ＵＥ１００は、下りリンクのＥＤＴを行うと判断した場合（ステップＳ１０４：ＹＥＳ）に限りステップＣを行う。

［第１実施形態の変更例１］
上述した第１実施形態において、下りリンクのＥＤＴを行わないとＵＥ１００が判断した場合に、ＵＥ１００が、下りリンクのＥＤＴを行わない旨をｅＮＢ２００に通知する一例について説明した。本変更例において、かかる動作の詳細について説明する。

具体的には、ＵＥ１００は、上りリンクのＥＤＴを伴うランダムアクセスプロシージャを開始する。かかるランダムアクセスプロシージャにおいて下りリンクのＥＤＴを行わないとＵＥ１００が判断した場合には、ＵＥ１００は、下りリンクのＥＤＴを行わないことを示す通知をランダムアクセスプロシージャ中にｅＮＢ２００に対して行う。

ここで、「下りリンクのＥＤＴを行わない」とは、上りリンクのＥＤＴにおいて送信されたデータに対する上位レイヤの応答が無いことを意味する。なお、上位レイヤとは、ＲＲＣレイヤよりも上位のレイヤを意味する。ＵＥ１００は、上りリンクのＥＤＴにおいてＵＤＰ送信を行う場合（つまり、ＴＣＰ ＡＣＫが無い場合）、下りリンクのＥＤＴを行わないと判断してもよい。ＵＥ１００は、上位レイヤの応答が無いと上位レイヤ（例えばアプリケーションレイヤ）から知らされた場合に、下りリンクのＥＤＴを行わないと判断してもよい。ＵＥ１００は、過去のアプリケーションレイヤの挙動（データ送受信履歴等）に基づいて（ＡＳレイヤ又はＮＡＳレイヤにて）応答が無いと判断された場合に、下りリンクのＥＤＴを行わないと判断してもよい。

ＵＥ１００は、下りリンクのＥＤＴを行わないことを示す通知をＭｓｇ３により行ってもよい。ＵＥ１００は、Ｍｓｇ３送信時にｅＮＢ２００に送信するバッファ状態報告（ＢＳＲ）として、利用可能な上りリンクデータがゼロであることを示すＢＳＲ（ＢＳＲ＝０）を送信してもよい。ｅＮＢ２００は、かかるＢＳＲを、ＵＥ１００が下りリンクのＥＤＴを行わないことを示す通知と解釈する。或いは、ＵＥ１００は、下りリンクのＥＤＴを行わないことをＭＡＣ ＣＥでｅＮＢ２００に通知してもよいし、ＭＡＣ ｓｕｂｈｅａｄｅｒのみ（ＭＡＣ ＣＥ部無し）で通知してもよい。或いは、ＵＥ１００は、Ｍｓｇ３を構成するＲＲＣメッセージ（ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｑｕｅｓｔ／Ｒｅｓｕｍｅ Ｒｅｑｕｅｓｔ）に、下りリンクのＥＤＴを行わないことを示すフラグを追加することによりｅＮＢ２００に通知してもよい。

ＵＥ１００は、下りリンクのＥＤＴを行わないことを示す通知をＭｓｇ１により行ってもよい。例えば、ＵＥ１００は、上りリンクのみのＥＤＴを通知するために確保されているＰＲＡＣＨリソースを用いてランダムアクセスプリアンブル（ＥＤＴインディケーション）を送信する。

このように、ＵＥ１００が、下りリンクのＥＤＴを行わないことをｅＮＢ２００に通知することにより、上述したように、ｅＮＢ２００は、ＵＥ１００を迅速にリリースすることができる。これにより、ｅＮＢ２００は、リソース（ｅＮＢの計算処理リソース、無線リソース）を早期に解放できる。また、ＵＥ１００は、消費電力を最小限に抑えることができる（待ち受けに伴う消費電力を最小化できる）。

［第１実施形態の変更例２］
上述した第１実施形態において、ＵＥ１００は、Ｍｓｇ３を送信してからＭｓｇ４と共にユーザデータを受信するまでの所要時間の予測値を導出し、ｅＮＢ２００から受信したＴ３００のタイマ値と、導出した予測値とに基づいて、ＥＤＴ（具体的には、下りリンクのＥＤＴ）を伴うランダムアクセスプロシージャを開始するか否かを判断していた。ここで、ｅＮＢ２００から設定されるＴ３００のタイマ値が基本的に固定であることを想定している。

しかしながら、ｅＮＢ２００が設定するＴ３００のタイマ値が短すぎる可能性がある。一方で、ｅＮＢ２００が設定するＴ３００のタイマ値が長すぎると、ランダムアクセス失敗の判定を適切に行うことができない懸念がある。そこで、本変更例では、ＵＥ１００がｅＮＢ２００に情報を提供することにより、ｅＮＢ２００がＴ３００のタイマ値を適切に設定可能とする。

本変更例において、ＵＥ１００は、ランダムアクセスプロシージャ中にＵＥ１００がＭｓｇ３を送信してからＭｓｇ４を受信するまでの最大待ち時間を設定するためのタイマ値として推奨する値（推奨タイマ値）を決定する。タイマ値とは、ＥＤＴ用のＴ３００の値である。或いは、タイマ値は、コンテンションレゾリューションタイマのタイマ値であってもよい。ＵＥ１００は、上述した第１実施形態と同様な予測に基づいて推奨タイマ値を決定してもよいし、過去の実績（履歴）に基づいて推奨タイマ値を決定してもよい。

そして、ＵＥ１００は、自身がＲＲＣコネクティッドモードにある間に、推奨タイマ値を示す情報をｅＮＢ２００に送信する。ＵＥ１００は、例えば、ｅＮＢ２００に送信するＲＲＣメッセージに推奨タイマ値を含める。ｅＮＢ２００は、複数のＵＥ１００から推奨タイマ値を収集し、収集した推奨タイマ値に対して統計処理を行うことにより適切なＴ３００の値を決定し、決定したＴ３００の値をＳＩＢにより送信する。

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

（第２実施形態に係る動作）
ｅＮＢ２００の配下に多数のＵＥ１００（特に、ｅＭＴＣ ＵＥやＮＢ－ＩｏＴ ＵＥ）が存在する場合、ｅＮＢ２００における負荷（特に、無線リソース負荷）が大きくなる。かかる状況下においては、ＥＤＴインディケーション用のＰＲＡＣＨリソースを用いるＵＥ１００の数が多くなり、同一のＰＲＡＣＨリソースを複数のＵＥ１００が選択することによりＵＥ１００間の衝突（コンテンション）が発生する。

かかる衝突は、ランダムアクセスプロシージャにおける衝突解消（コンテンションレゾリューション）の仕組みを用いてＭｓｇ４により解消されるが、ＰＲＡＣＨリソースが衝突した一部のＵＥ１００はランダムアクセスプロシージャを最初からやり直す必要があるため、ＵＥ１００の消費電力が増加する。特に、かかる一部のＵＥ１００が上りリンクのＥＤＴにより上りリンクユーザデータを送信していた場合、かかる上りリンクユーザデータの送信が無駄になる。

第２実施形態において、ｅＮＢ２００は、自身の負荷状態に基づいて、ＥＤＴを確率的に規制するための規制信号（以下、「ＥＤＴ規制信号」という）を送信する。ｅＮＢ２００は、ＥＤＴ規制信号をＳＩＢにより送信（ブロードキャスト）してもよい。これにより、ＥＤＴを利用するＵＥ１００間の衝突（具体的には、ＰＲＡＣＨリソースの衝突）が生じる確率を低減できる。ｅＮＢ２００は、自身が高負荷状態にある間は、ＥＤＴ規制信号を周期的に送信してもよい。また、ｅＮＢ２００は、ＥＤＴを規制したいＵＥ１００（データの送信量が比較的多いＵＥ１００又は優先度の低いＵＥ１００）に対してのみ、個別的にＥＤＴ規制信号を送信してもよい。また、ｅＮＢ２００は、個別的にＥＤＴ規制信号を送信すると共に、ＳＩＢによりＥＤＴ規制信号を送信（ブロードキャスト）してもよい。その場合、それぞれのＥＤＴ規制信号に関連付けられているＥＤＴを利用可能とする条件（ＥＤＴ利用可能条件）を同じくしてもよいし、異ならせてもよい。例えば、個別的に送信したＥＤＴ規制信号に関連付けられているＥＤＴ利用可能条件が、ＳＩＢにより送信されたＥＤＴ規制信号に関連付けられているＥＤＴ利用可能条件に比べて、より高確率でＵＥ１００によるＥＤＴが規制される条件であってもよい。

ここで、ｅＮＢ２００の負荷状態とは、リソース負荷の状態であってもよいし、ハードウェア負荷の状態であってもよい。また、リソース負荷の状態は、ＰＲＡＣＨリソース（Ｍｓｇ１）におけるＵＥ間の衝突発生の頻度を含む。ｅＮＢ２００は、かかる衝突発生の頻度を次のようにして判断する。基本的には、ｅＮＢ２００は、Ｍｓｇ１の衝突有無を衝突解消（Ｃｏｎｔｅｎｔｉｏｎ Ｒｅｓｏｌｕｔｉｏｎ）が完了したか否かに応じて判断する。例えば、２つのＵＥが同一のランダムアクセスプリアンブル（ＥＤＴインディケーション）を送信し、ｅＮＢ２００がそれらの受信に成功し、Ｍｓｇ２を返す。かかる場合、当該２つのＵＥは、別のランダムＩＤを含んだＭｓｇ３をＰＵＳＣＨで送信する。この時、ｅＮＢ２００は、ＵＬ ｇｒａｎｔ（Ｍｓｇ２）で指定したリソースでＰＵＳＣＨを受信できなければ、ランダムアクセスプリアンブル（ＥＤＴインディケーション）が衝突したと判断できる。但し、ｅＮＢ２００は、一方のＵＥが送信したＭｓｇ３だけ受信が成功することもあり得る。この場合、当該一方のＵＥに対してｅＮＢ２００が送信するＭｓｇ４によりｃｏｎｔｅｎｔｉｏｎ ｒｅｓｏｌｕｔｉｏｎされるため、衝突したかどうかは分からない。しかしながら、ｅＮＢ２００は、ランダムアクセスプリアンブルの設定を把握しており、例えば同時に受信したＭｓｇ１に基づいて、ＰＲＡＣＨ空間（ＰＲＡＣＨリソース）が逼迫していることは分かるため、衝突が起こっている可能性が高いと推測することは可能である。

なお、確率的に規制するとは、全てのＵＥ１００に対して一律にＥＤＴを規制するのではなく、ランダムに決定される一部のＵＥ１００に対してのみＥＤＴを規制することをいう。かかる一部のＵＥ１００は、ＥＤＴが規制されるだけであり、ランダムアクセスプロシージャ自体は規制されないため、ＥＤＴを伴わないランダムアクセスプロシージャを行うことが可能である。

ＥＤＴを伴わないランダムアクセスプロシージャを行うＵＥ１００は、ランダムアクセスプロシージャによりＲＲＣコネクティッドモードに遷移する。一方、ＥＤＴを伴うランダムアクセスプロシージャを行うＵＥ１００は、ＲＲＣアイドルモードを維持したままランダムアクセスプロシージャを終了することが可能であるため、ＵＥ１００の消費電力が少なくて済む。

ＵＥ１００は、ｅＮＢ２００から受信したＥＤＴ規制信号に基づいて、ＵＥ１００がＥＤＴを利用可能か否か判断する。ＵＥ１００は、ＥＤＴを利用可能であると判断したことに応じて、ＥＤＴを伴うランダムアクセスプロシージャを開始する。一方、ＵＥ１００は、ＥＤＴを利用可能でないと判断したことに応じて、ＥＤＴを伴わないランダムアクセスプロシージャを開始してもよい。

図９は、第２実施形態に係るＵＥ１００の動作の一例を示す図である。図８に示したＵＥ１００の動作と重複する動作については説明を省略する。

図９に示すように、ステップＳ２０１～Ｓ２０３の処理は、図８に示したＵＥ１００の動作と同様である。

ステップＳ２０３において「ＹＥＳ」である場合、ステップＳ２０４において、ＵＥ１００は、ｅＮＢ２００からＥＤＴ規制信号を受信したか否かを判断する。ステップＳ２０４において「ＮＯ」である場合、ステップＳ２０７において、ＵＥ１００は、ＥＤＴを伴うランダムアクセスプロシージャを開始する。具体的には、ＵＥ１００は、ランダムアクセスプロシージャにおけるＭｓｇ１送信時にＥＤＴインディケーションを送信する。

一方、ステップＳ２０４において「ＹＥＳ」である場合、ステップＳ２０５において、ＵＥ１００は、自身がＥＤＴを利用可能か否か判断する。ＥＤＴ規制信号は、ＥＤＴを利用可能とする条件と関連付けられている。かかるＥＤＴ利用可能条件は、ＥＤＴ規制信号に含まれる情報であってもよいし、ＵＥ１００に事前設定されていてもよい。本実施形態において、ＥＤＴ利用可能条件がＥＤＴ規制信号に含まれている一例について説明する。

ＵＥ１００は、自身が発生させた乱数及び／又は自身に関する識別子（ＵＥ－ＩＤ）が条件を満たすか否かを判断する。ＵＥ１００に関する識別子（ＵＥ－ＩＤ）は、例えば、ＵＥ１００のＳＩＭに格納されたＩＭＳＩ（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｍｏｂｉｌｅ Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｔｙ）である。但し、ＵＥ１００に関する識別子であれば、ＩＭＳＩ以外の識別子を用いてもよい。

ＵＥ１００は、自身が発生させた乱数を、ｅＮＢ２００から指定された閾値と比較し、比較結果に応じてＥＤＴの利用可否を判断してもよい。例えば、ＵＥ１００は、発生させた乱数が閾値を超えた場合に限り、ＥＤＴが利用可能であると判断してもよい。

或いは、ＵＥ１００は、「ＵＥ－ＩＤ ｍｏｄ Ｎ」を計算し、この計算結果が、ある数値又はある数値範囲内にあるか否かに応じて、ＥＤＴの利用可否を判断してもよい。ここで「Ｎ」及び／又は「数値（又は数値範囲）」は、ｅＮＢ２００から指定されてもよい。「数値（又は数値範囲）」は、任意の固定値であってもよいし、無線フレーム番号等の変数であってもよい。

或いは、乱数又はＵＥ－ＩＤに代えて、ランダム性を有する値（すなわち、ＵＥ間で一致する可能性が低い値）に基づいてＥＤＴの利用可否を判断してもよい。例えば、ランダム性を有する値として、ＵＥ１００が上りリンクのＥＤＴで送信したい上りリンクデータのサイズ（トランスポートブロックサイズ）を用いてもよい。具体的には、ＵＥ１００は、「上りリンクデータサイズ ｍｏｄ Ｎ」を計算し、この計算結果が、ある数値又はある数値範囲内にあるか否かに応じて、ＥＤＴの利用可否を判断してもよい。或いは、上りリンクデータサイズが、ある閾値以上であること、ある閾値以下であること、２つの閾値の間（範囲内）にあることに基づいて、ＥＤＴが許可される又は規制されると判断してもよい。なお、当該閾値は、ＥＤＴ規制信号に関連付けられているか又は含まれていてもよい。

ステップＳ２０６において、ＵＥ１００は、ステップＳ２０５の結果に応じて自身がＥＤＴを利用可能か否か判断する。ステップＳ２０６において「ＹＥＳ」（ＥＤＴを利用可能）である場合、ステップＳ２０７において、ＵＥ１００は、ＥＤＴを伴うランダムアクセスプロシージャを開始する。具体的には、ＵＥ１００は、ランダムアクセスプロシージャにおけるＭｓｇ１送信時にＥＤＴインディケーションを送信する。

ステップＳ２０６において「ＮＯ」（ＥＤＴを利用不可）である場合、ステップＳ２０８において、ＵＥ１００は、ＥＤＴを伴わないランダムアクセスプロシージャを開始する。具体的には、ＵＥ１００は、ランダムアクセスプロシージャにおけるＭｓｇ１送信時にＥＤＴインディケーションを送信しない。

なお、ここでは、ＥＤＴ規制信号に関連付けられた条件は、主にＥＤＴを確率的に規制するためのものであったがこれには限られない。つまり、ＥＤＴ規制信号は、それを受信したＵＥ１００が、ＥＤＴの実行を禁止されるものであってもよい。つまり、ｅＮＢ２００は、ＵＥ１００によるＥＤＴを確実に規制したい場合には、その旨を示す信号を個別的に送信又はブロードキャストしてもよく、それを受信したＵＥ１００は、ＥＤＴの実行が禁止される。

（第２実施形態のまとめ）
上述した第２実施形態に係る動作は、以下のように要約できる。

ランダムアクセスプロシージャ中にユーザデータの送受信を行うＥＤＴを制御するための通信制御方法であって、ＵＥ１００が、ＥＤＴを確率的に規制するためのＥＤＴ規制信号をｅＮＢ２００から受信するステップＡ（ステップＳ２０４）と、ＵＥ１００が、ステップＡにおいて受信したＥＤＴ規制信号に基づいて、ＵＥ１００がＥＤＴを利用可能か否か判断するステップＢ（ステップＳ２０５）と、ＵＥ１００が、ステップＢにおいてＥＤＴを利用可能であると判断したことに応じて、ＥＤＴを伴うランダムアクセスプロシージャを開始するステップＣ（ステップＳ２０７）と、ＵＥ１００が、ステップＢにおいてＥＤＴを利用可能でないと判断したことに応じて、ＥＤＴを伴わないランダムアクセスプロシージャを開始するステップＤ（ステップＳ２０８）と、を備える。

ＥＤＴ規制信号は、ＥＤＴを利用可能とする条件と関連付けられている。ステップＢにおいて、ＵＥ１００は、ＵＥ１００が条件を満たすことに応じて、ＥＤＴを利用可能であると判断する。

ステップＢは、ＵＥ１００が発生させた乱数及び／又はＵＥ１００に関する識別子又はその他の情報が条件を満たすか否かを判断するステップを含む。

ｅＮＢ２００が、ｅＮＢ２００における負荷状態に基づいて、ＥＤＴ規制信号を送信するか否かを判断する。

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

上述したように、ＥＤＴには、ＵＰソリューション（すなわち、ユーザプレーンのＥＤＴ）及びＣＰソリューション（制御プレーンのＥＤＴ）の２種類がある。ＵＰソリューションは、ＵＥ１００がＲＲＣアイドルモードのサブ状態であるサスペンド状態である場合に適用される。具体的には、ＵＥ１００は、サスペンド状態を設定するＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ ＲｅｌｅａｓｅメッセージをｅＮＢ２００から受信すると、ＲＲＣアイドルモードのサブ状態であるサスペンド状態に遷移する。サスペンド状態では、ＵＥ１００のコンテキスト情報がｅＮＢ２００において維持されており、ｅＮＢ２００が保持するコンテキスト情報を利用して円滑にＲＲＣコネクティッドモードに復旧可能とする。

ここで、ユーザプレーンのＥＤＴを利用するためには、ＵＥ１００がサスペンド状態に設定される際に、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｌｅａｓｅメッセージにより、ＮＣＣ（Ｎｅｘｔ Ｈｏｐ Ｃｈａｉｎｉｎｇ Ｃｏｕｎｔ）がｅＮＢ２００から提供されている必要がある。ＮＣＣは、ユーザプレーンにおいてＰＤＣＰレイヤが暗号化に関する処理（復号処理を含む）を行うために用いられる暗号情報であって、ＰＤＣＰレイヤが管理するシーケンス番号に基づいてカウントされる値である。ＮＣＣが提供されていないＵＥ１００は、ユーザプレーンのＥＤＴを開始することができない。

一方、ＮＣＣが提供されているＵＥ１００であっても、上述したような事情（例えば、送信データ量が最大データ量を超える等）によりＥＤＴを行わないことがある。ＮＣＣが提供されているにもかかわらず、ＥＤＴを伴わないランダムアクセスプロシージャを繰り返すＵＥ１００は、ＥＤＴに適していないアプリケーションを実行している可能性がある。よって、そのようなＵＥ１００にＮＣＣを提供することは無駄になり得る。

具体的には、ｅＮＢ２００は、ユーザプレーンのＥＤＴに必要な情報であってユーザプレーンにおける暗号化に関する処理に用いる暗号情報であるＮＣＣをＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ ＲｅｌｅａｓｅメッセージによりＵＥ１００に提供する（１回目のＮＣＣの提供）。ＲＲＣアイドルモード（サスペンド状態）に遷移したＵＥ１００は、ＮＣＣの受信後、ＥＤＴを伴わないランダムアクセスプロシージャをｅＮＢ２００に対して行うことにより、ＲＲＣコネクティッドモードに遷移する。次に、ｅＮＢ２００は、ＮＣＣをＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ ＲｅｌｅａｓｅメッセージによりＵＥ１００に提供する（２回目のＮＣＣの提供）。ＲＲＣアイドルモード（サスペンド状態）に遷移したＵＥ１００は、ＮＣＣの受信後、ＥＤＴを伴わないランダムアクセスプロシージャをｅＮＢ２００に対して行うことにより、ＲＲＣコネクティッドモードに遷移する。このような動作がある回数Ｎだけ繰り返された場合、ｅＮＢ２００は、ＵＥ１００に対するＮＣＣの提供を停止する。ここで、Ｎは１以上の値であるが、２以上の値とすることが好ましい。ｅＮＢ２００は、ＮＣＣを提供したにもかかわらずＵＥ１００がＥＤＴを行わなかった回数をカウントし、カウント値がＮに達した場合に、ＵＥ１００に対するＮＣＣの提供を停止する。具体的には、ｅＮＢ２００は、ＮＣＣを含まないＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ ＲｅｌｅａｓｅメッセージをＵＥ１００に送信する。

ｅＮＢ２００は、Ｎの値を示す情報を例えばＳＩＢに含めて送信してもよい。ＵＥ１００は、Ｎの値を示す情報をｅＮＢ２００から受信する。例えば、ＵＥ１００は、ＮＣＣが提供されたにもかかわらずＥＤＴを行わなかった回数をカウントする。ＵＥ１００は、なおもＥＤＴを使用したい意図がある場合には、カウント値がＮに達する前に、ＥＤＴを使用したい意図をｅＮＢ２００に通知する。これにより、ｅＮＢ２００がＮＣＣの提供を停止することを防ぐことができる。ＥＤＴを使用したい意図の通知は、従来のＭｓｇ３により行われてもよい。具体的には、かかるＭｓｇ３を構成するＭＡＣ ＰＤＵは、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｓｕｍｅ Ｒｅｑｕｅｓｔ及びＢＳＲを含むが、データＰＤＵは多重化されない。

［第３実施形態の変更例１］
上述した第３実施形態において、ＮＣＣが提供されていないＵＥ１００はユーザプレーンのＥＤＴを利用することができないと説明したが、かかるＵＥ１００であっても制御プレーンのＥＤＴを利用可能であると考えられる。制御プレーンのＥＤＴにおいては、Ｍｓｇ３を構成するＲＲＣメッセージ（Ｅａｒｌｙ Ｄａｔａ Ｒｅｑｕｅｓｔメッセージ）にユーザデータを含めるが、かかるＲＲＣメッセージは制御プレーンのメッセージであり、ＰＤＣＰレイヤの暗号化処理を必要としないため、ＮＣＣが不要である。

よって、ＵＥ１００は、ＮＣＣをｅＮＢ２００から受信していない場合には、ユーザプレーンのＥＤＴではなく、制御プレーンのＥＤＴを開始する。ＵＥ１００は、ネットワークが制御プレーンのＥＤＴに対応している場合（ＭＭＥがデータ送受信機能を有している場合）であって、且つＵＥ１００のアプリケーションレイヤが制御プレーンのＥＤＴに対応している場合（ＭＭＥ経由でアプリケーションサーバへの接続が可能な場合）に限り、制御プレーンのＥＤＴを開始してもよい。

かかる制御プレーンのＥＤＴにおいて、ＵＥ１００は、ＲＲＣメッセージにユーザデータを含めてｅＮＢ２００に送信する。これにより、ＮＣＣがｅＮＢ２００から提供されていないＵＥ１００であってもＥＤＴを利用可能にすることができる。一方、ＵＥ１００は、ＮＣＣをｅＮＢ２００から受信している場合には、制御プレーンのＥＤＴではなく、ユーザプレーンのＥＤＴを開始する。

［第３実施形態の変更例２］
ＮＣＣをＵＥ１００に提供することを促すことができれば、ＵＥ１００がユーザプレーンのＥＤＴを利用できる可能性を高めることができる。また、ＮＣＣをＵＥ１００に提供するか否かをｅＮＢ２００が判断するための情報をＵＥ１００から得ることができれば、ｅＮＢ２００が適切にＮＣＣをＵＥ１００に提供できる。

そこで、本変更例では、ＵＥ１００は、自身がＲＲＣコネクティッドモードにある間に、ＲＲＣアイドルモードに遷移した後にＥＤＴを行う意図を有することを示す通知をｅＮＢ２００に送信する。かかる通知は、例えばＲＲＣメッセージにより行われる。かかる通知は、ユーザプレーンのＥＤＴを行う意図を有することを示す通知であってもよい。

ｅＮＢ２００は、ＵＥ１００からの通知を、ＮＣＣをＵＥ１００に提供することを促すための情報、又はＮＣＣをＵＥ１００に提供するか否かを判断するための情報として用いる。ｅＮＢ２００は、かかる通知に基づいてＮＣＣをＵＥ１００に提供する。

［その他の実施形態］
上述した各実施形態を別個独立に実施してもよいし、２以上の実施形態を併用して実施してもよい。

上述した実施形態において、ＭＴＣやＩｏＴを対象とした無線端末（ｅＭＴＣ ＵＥ及びＮＢ－ＩｏＴ ＵＥ）を用いる一例を説明した。しかしながら、本開示はｅＭＴＣ ＵＥ及びＮＢ－ＩｏＴ ＵＥに限定されない。一般的なＵＥに対して、上述した実施形態に係る動作を適用してもよい。

上述した実施形態では、主にＲＲＣアイドル、サスペンド、コネクテッドを例に挙げて説明したが、これに限らない。ＲＲＣライトコネクションやＩＮＡＣＴＩＶＥの状態に適用してもよい。ＲＲＣライトコネクションは、ＲＲＣコネクティッドモードの一状態であって、ＲＲＣアイドルモードのプロシージャの一部が適用される特殊な状態である。ＩＮＡＣＴＩＶＥは、第５世代移動通信システムにおいて導入されることが想定されており、ＲＲＣコネクティッドモード及びＲＲＣアイドルモードとは異なるＲＲＣ状態である。上述した実施形態における「ＲＲＣアイドルモード」を「ＩＮＡＣＴＩＶＥモード」と読み替えてもよい。

上述した実施形態では強化カバレッジに居るＵＥを例に挙げて説明したが、これに限らない。ノーマルカバレッジに居るＵＥに対して、上述した実施形態に係る動作を適用してもよい。具体的には、ＲＡＣＨプロシージャにおいて、ＲＳＲＰ測定に基づくＣＥレベル判断を行わなくてもよい。

上述した実施形態において、移動通信システムとしてＬＴＥシステムを例示した。しかしながら、本開示はＬＴＥシステムに限定されない。ＬＴＥシステム以外の移動通信システム（例えば、第５世代移動通信システム）に対して、上述した実施形態に係る動作を適用してもよい。

ＵＥ１００及びｅＮＢ２００が行う各処理をコンピュータに実行させるプログラムが提供されてもよい。また、プログラムは、コンピュータ読取り可能媒体に記録されていてもよい。コンピュータ読取り可能媒体を用いれば、コンピュータにプログラムをインストールすることが可能である。ここで、プログラムが記録されたコンピュータ読取り可能媒体は、非一過性の記録媒体であってもよい。非一過性の記録媒体は、特に限定されるものではないが、例えば、ＣＤ－ＲＯＭやＤＶＤ－ＲＯＭ等の記録媒体であってもよい。ＵＥ１００及びｅＮＢ２００が行う各処理を実行するためのプログラムを記憶するメモリ及びメモリに記憶されたプログラムを実行するプロセッサによって構成されるチップセットが提供されてもよい。

（付記）
（１．はじめに）
この付記では、ＥＤＴ機能を完成させるための残りの問題について検討する。
（２．検討）
（２．１．Ｍｓｇ ３における暗黙（Ｉｍｐｌｉｃｉｔ）の「ＢＳＲ＝０」）
以下の事項が合意された。

－ ＥＤＴがトリガされた場合、ＵＥはＭｓｇ３でＢＳＲを送信してはならない、すなわち、ｅＮＢはＵＬにおいて次に来るデータがないと仮定することができる。これはＢＳＲが暗黙的に０に等しいことを意味する。

意図が、（少なくとも）ＵＬ送信に関して、ＥＤＴ後の送信に利用可能なデータがないことであることは当然に理解され得る。言い換えれば、ＵＬデータサイズがブロードキャストされた最大ＴＢＳを超える場合、ＵＥがＥＤＴを開始できないようにする。

一方、「ＢＳＲ＝０」をトリガすることの定義（すなわち、ＮＢ-ＩｏＴおよびＢＬ ＵＥのための解放支援インディケーション（Ｒｅｌｅａｓｅ Ａｓｓｉｓｔａｎｃｅ Ｉｎｄｉｃａｔｉｏｎ）を実現するためにゼロバイトＢＳＲをキャンセルしないための条件）は、次のように、送信されるデータがないことと、近い将来に受信されるデータがないことと、を考慮する。

ＮＢ－ＩｏＴまたはＢＬ ＵＥの場合：
－ ｒａｉ－Ａｃｔｉｖａｔｉｏｎが設定されており、かつ、ＢＳＲに対してゼロバイトのバッファサイズがトリガされており、かつ、近い将来にＵＥが送信または受信するデータがもっとある可能性がある場合：
－ ペンディングのＢＳＲをキャンセルする。

ＥＤＴの典型的なユースケースは、ＲＲＣ Ｃｏｎｎｅｃｔｅｄに移行することなく、Ｍｓｇ３およびＭｓｇ４においてデータ送信／受信を完了すること、例えば、ＵＬ ＥＤＴ上でのセンサデータの報告、及び、ＤＬ ＥＤＴ上でのＵＥの上位層のＡＣＫ、が想定される。しかし、「ＢＳＲが暗黙的に０に等しいことを意味する」という最近の合意では、そのケースを十分に説明できない可能性がある。

考察１：「ＢＳＲが０に暗黙的に等しいことを意味する」という最近の合意が、ＵＬのみ、またはＵＬとＤＬの両方についてこれ以上データがない（Ｎｏ ｍｏｒｅ ｄａｔａ）ことを意図するか否かは明確ではない。

ＵＬバッファステータスのみを意図している場合、ＲＡＮ２は、「ＢＳＲが０に等しい」という用語を使用せずに、仕様書において「これ以上データがない（Ｎｏ ｍｏｒｅ ｄａｔａ）」をキャプチャする方法を特定する必要がある。

それが予想されるＤＬ受信も意図している場合、ＲＡＮ２は、例えば、ＤＬがないケース合（例えば、ＵＬ ＥＤＴにおけるＵＤＰタイプ）、１つのＤＬケース（例えば、ＤＬ ＥＤＴにおけるＴＣＰ ＡＣＫ）、無線リソース（ＤＬ ＴＢＳによる）およびラウンドトリップ時間（Ｔ３００－ＥＤＴによる）の観点からＤＬ ＥＤＴ内に収まる一つのＤＬをどのように識別する方法、などについて議論する必要がある。

提案１：ＲＡＮ２は、仕様書において「ＢＳＲが暗黙的に０に等しいことを意味する」という合意をどのようにキャプチャするかを明確にすべきである。

（２．２．フォールバックのシナリオ）
ＮＷ主導のフォールバックシナリオは何度も議論されており、Ｍｓｇ４ではＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｓｅｔｕｐ（ＣＰ ＥＤＴ用）又はＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｓｕｍｅ（ＵＰ ＥＤＴ用）のいずれかで実現されている。ＮＷ主導のフォールバックは、例えば、利用可能なＤＬリソースよりも大きいサイズ及び／又はＴ３００－ＥＤＴ満了後のデータ到着に起因して、Ｍｓｇ４ ＤＬ ＥＤＴにおいてＤＬデータを送信することができないときに実行されることになる。

考察２：ＮＷ主導のフォールバックは、ｅＮＢ実装及び／又はｅＮＢ外部の上位層問題のために常に許可される。

ＵＥ主導のフォールバックシナリオは明示的には議論されていないが、前回のオンラインディスカッションで多少指摘されている。すなわち、一部の会社は、Ｍｓｇ３のＥＤＴの前にＭｓｇ１のＥＤＴ インディケーションの後に新しいデータが到着すると考え、他の会社の一部は、これがセグメンテーションのサポートに関連するだけであると考える。

「ＮＡＳ層は、接続の確立／再開を要求するときにＥＤＴを使用する意思を示す必要はない。ＥＤＴを使用するという決定はＡＳ層によって行われる。」という合意事項にともない、ＥＤＴインディケーションが送信された後において追加のＵＬデータがＡＳレイヤに送達される可能性がある。特に、複数のアプリケーションをインストールするＭＴＣ ＵＥにとってこの可能性がある。

考察３：ＵＥ主導のフォールバックシナリオは、Ｍｓｇ１上のＥＤＴインディケーションとＭｓｇ３上のＵＬ ＥＤＴの間に別のＵＬデータが到着することによって、検討する価値があり得る。

ＵＥ主導のフォールバックは、Ｍｓｇ１上でＥＤＴ指示を送信した後でも、ＵＥがデータなしのＭｓｇ３、すなわちレガシーＭｓｇ３を送信すると考えられる。しかしながら、問題は、ＵＬリソース割り当てがＭｓｇ２上で既に行われている、すなわち、Ｍｓｇ３上のＵＬ ＥＤＴに対するより大きいＵＬグラントサイズである。ＵＥがより大きいＵＬグラントサイズでレガシーＭｓｇ３を送信したい場合、パディングの問題がこの場合に再び現れる。１つの可能な解決策は、Ｍｓｇ３に対するブラインド復号化オプションが常にレガシーＭｓｇ３サイズを許容する、すなわちＵＬ ＥＤＴに対する最小ＴＢＳが常にレガシーサイズと同じと仮定されることを考慮することができる。レガシーサイズが、約３２０ビットとする最小ＴＢＳで、４つのブラインドオプションに対する追加オプションとして考えられることが望まれる。

提案２：ＲＡＮ２は、合意された４つのオプションに加えて、ＥＤＴ ＵＬグラントがレガシーＭｓｇ３サイズのためのブラインド復号化オプションを常に許可すべきかどうかを議論すべきである。

（２．３．ＲＲＣ Ｃｏｎｎｅｃｔｅｄの支援情報）
（２．３．１．ＮＣＣ提供）
ＲＡＮ２は、ＮＣＣがＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｌｅａｓｅによって提供されていない場合、ＵＥはＵＰ ＥＤＴを開始しないことに合意した。

－ ＵＥがＮＣＣなしでサスペンドされている場合、ＵＥはＥＤＴを開始してはならない。

－ ＵＥがＥＤＴを使用しているとき、又はＵＥがＲＲＣ ＣＯＮＮＥＣＴＥＤにあるとき、ＮＣＣは任意選択でサスペンドととものＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｌｅａｓｅメッセージに提供される。

ＮＣＣがＥＤＴ手順内で提供される場合、ｅＮＢは、今回使用されるので、ＵＥが次回でＥＤＴを使用する可能性が高いことを知っている。例えば、ｅＮＢは、ＵＥがＮ回ＮＣＣを使用しない場合、すなわち、代わりにＲＲＣ接続要求を開始する場合、ＮＣＣの提供を停止することを決定してもよい。

しかしながら、ＵＥが接続されている場合（例えば、初めてＮＣＣを提供するとき）、ＵＥ能力（ＵＥ Ｃａｐａｂｉｌｉｔｙ）が、ＥＤＴを使用するというＵＥのプリファレンス（ＵＥ’ｓ ｐｒｅｆｅｒｅｎｃｅ）を伝えないので、ｅＮＢがＮＣＣをこのＵＥに提供すべきかどうかを決定する方法は依然として不明である。

考察４：ｅＮＢは、ＮＲＣがＲＲＣ ＣｏｎｎｅｃｔｅｄのＥＤＴ対応ＵＥに提供される必要があるかどうかを知らない可能性がある。

可能な解決策は次のように考えられる。

オプション１：ｅＮＢは、ＥＤＴ対応ＵＥを解放するときに常にＮＣＣを提供する。

オプション２：ｅＮＢは、ＵＥのプリファレンス（ＵＥ’ｓ ｐｒｅｆｅｒｅｎｃｅ）に基づいて、ＵＥごとにＮＣＣを提供するかどうかを決定する。

オプション１は単純で、仕様には影響を与えないが、オプション２はよりスマートな方法である。オプション２は、ＮＷが将来のＥＤＴ開始の可能性を確実にすることを可能にし、また、ＵＥがｅＮＢにＵＥのプリファレンスを通知すること、すなわち、他の様々なプリファレンス表示と同様にすることを可能にする。この意味で、追加のＵＥ支援情報としてＥＤＴプリファレンスインジケーションを導入することが好ましいである。

提案３：ＲＡＮ２は、例えば、ＲＲＣ ＣｏｎｎｅｃｔｅｄのＥＤＴ対応ＵＥにＮＣＣを提供するか否かをｅＮＢが決定するために、ＵＥ支援情報にＥＤＴプリファレンスインジケーションを導入すべきである。

（２．３．２．ＮＷ最適化）
ＥＤＴの最適な使用は、ＮＷとＵＥの両方の観点、例えば、キャパシティの増大と電力消費の改善などから有益であるが、ＥＤＴの有用性は、ＮＷ構成とＭＴＣアプリケーションの挙動の両方に依存する。したがって、ＮＷは、ＵＬ ＥＤＴに対する最大ＴＢＳ／ブラインド復号オプション、及び、タイマ（Ｔ３００－ＥＤＴ及び競合解決タイマ－ＥＤＴ）に関し、中期的にＮＷの構成を変更し、及び／又は長期的に最適化を必要とする可能性がある。

考察５：ＮＷ構成の変更／最適化は、ＥＤＴの利点を最大化するために必要になる。

いくつかのＮＷ実装は、例えばＲＲＣ ＣｏｎｎｅｃｔｅｄのＵＥの挙動を監視することによって、この種のＮＷ最適化のために有効であろう。しかしながら、データサイズ及び上位層のラウンドトリップ時間は、ＵＥに実装されたＭＴＣアプリケーションの要件からのものである。

考察６：ＥＤＴの設定は、ＭＴＣアプリケーションの要件に基づくべきである。

上記の考察を考慮して、ＵＥが意図したアプリケーション、特に、ＵＬデータサイズ、に関してフィードバックを提供すべきかどうかは、ＮＷ最適化の一部として考慮されるべきである。ＵＥがＲＲＣ ＩＤＬＥに戻る（例えば、ＲＡＩを送信する）前に、ＵＥは、支援情報として、ＥＤＴのためのＵＥの好ましいＴＢＳをｅＮＢに通知する機会を有することができる。そのような支援情報は、上記の提案３で提案されたＥＤＴプリファレンスインジケーションと統合されてもよい。

提案４：ＲＡＮ２は、ＵＥが、ＴＢＳ／タイマ構成最適化のための支援情報、例えば、ＵＥの好ましいＴＢＳ及びＵＥの好ましいＴ３００-ＥＤＴを送信することを可能にすることに同意すべきである。

［相互参照］
本願は、米国仮出願第６２／６６８８８９号（２０１８年５月９日出願）の優先権を主張し、その内容が、参照により、本願明細書に組み込まれている。

Claims (6)

1. ＲＲＣアイドル状態にある間にユーザデータを基地局に送信するデータ伝送を行うユーザ装置のための通信制御方法であって、
   前記データ伝送を行う前において、ＲＲＣコネクティッド状態にある前記ユーザ装置が、前記ＲＲＣコネクティッド状態から前記ＲＲＣアイドル状態に遷移した後に前記データ伝送を行う意図を有することを示す通知を前記基地局に送信するステップを有する
   通信制御方法。
2. 前記ユーザ装置が、前記通知を送信した後において、前記ユーザ装置を前記ＲＲＣアイドル状態に遷移させるＲＲＣ Ｒｅｌｅａｓｅメッセージを前記基地局から受信するステップをさらに有し、
   前記ＲＲＣ Ｒｅｌｅａｓｅ メッセージは、前記データ伝送を行うために必要なＮＣＣ（Ｎｅｘｔ Ｈｏｐ Ｃｈａｉｎｉｎｇ Ｃｏｕｎｔ）を示す情報を含む
   請求項１に記載の通信制御方法。
3. 前記ユーザ装置が、前記ＲＲＣアイドル状態にある間に、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｓｕｍｅ Ｒｅｑｕｅｓｔメッセージを用いて前記ユーザデータの送信を行うステップをさらに有する
   請求項１に記載の通信制御方法。
4. ＲＲＣアイドル状態にある間にユーザデータを基地局に送信するデータ伝送を行うユーザ装置であって、
   前記データ伝送を行う前において、前記ユーザ装置がＲＲＣコネクティッド状態にある場合、前記ＲＲＣコネクティッド状態から前記ＲＲＣアイドル状態に遷移した後に前記データ伝送を行う意図を有することを示す通知を前記基地局に送信する送信部を有する
   ユーザ装置。
5. ＲＲＣアイドル状態にある間にユーザデータを基地局に送信するデータ伝送を行うユーザ装置のためのプロセッサであって、
   前記データ伝送を行う前において、前記ユーザ装置がＲＲＣコネクティッド状態にある場合、前記ＲＲＣコネクティッド状態から前記ＲＲＣアイドル状態に遷移した後に前記データ伝送を行う意図を有することを示す通知を前記基地局に送信する処理を実行する
   プロセッサ。
6. ＲＲＣアイドル状態にある間にユーザデータを基地局に送信するデータ伝送を行うユーザ装置と通信する前記基地局であって、
   前記データ伝送が行われる前において、ＲＲＣコネクティッド状態にある前記ユーザ装置から、前記ＲＲＣコネクティッド状態からＲＲＣアイドル状態に遷移した後に前記データ伝送を行う意図を有することを示す通知を受信する受信部を有する
   基地局。

Images