JP7731472B2 - 通信制御方法、ユーザ装置、プロセッサ及びプログラム - Google Patents

Description

本発明は、移動通信システムに用いる通信制御方法に関する。

移動通信システムの標準化プロジェクトである３ＧＰＰ（Ｔｈｉｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）（登録商標。以下同じ）の規格において、ランダムアクセスプロシージャ中にデータの送信や受信を行うアーリーデータ伝送（ＥＤＴ）が規定されている（例えば、非特許文献１参照）。

ＥＤＴには、ＭＯ－ＥＤＴ（Ｍｏｂｉｌｌｅ Ｏｒｉｇｉｎａｔｅｄ－ＥＤＴ）と、ＭＴ－ＥＤＴ（Ｍｏｂｉｌｅ Ｔｅｒｍｉｎａｔｅｄ－ＥＤＴ）とがある。

ＭＯ－ＥＤＴは、上りリンクデータを送信するためのＥＤＴである。ＭＯ－ＥＤＴでは、ユーザ装置の上位レイヤがユーザ装置起点のデータのためのＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）接続の確立又は再開を要求し、且つ、上りリンクデータのサイズがシステム情報で示されたトランスポートブロック（ＴＢ）サイズ以下になると、開始される。なお、ＭＯ－ＥＤＴでは、ランダムアクセスプロシージャ中に、上りリンクデータ送信に続く下りリンクデータ送信も可能である。

他方、ＭＴ－ＥＤＴは、下りリンクデータ送信を行うためのＥＤＴである。ＭＴ－ＥＤＴでは、ユーザ装置がＭＴ－ＥＤＴ指示を含むページングメッセージを基地局から受信すると、ランダムアクセスプロシージャを行い、ＭＯ－ＥＤＴにおける下りリンクデータを受信するタイミングで基地局から下りリンクデータを受信する。

また、３ＧＰＰでは、ＰＵＲ（Ｐｒｅｃｏｎｆｉｇｕｒｅｄ Ｕｐｌｉｎｋ Ｒｅｓｏｕｒｃｅ）も規定されている。ＰＵＲでは、ランダムアクセスプロシージャを行うことなく、予め設定された（ｐｒｅｃｏｎｆｉｇｕｒｅｄ）上りリンクリソースを用いて、ＲＲＣアイドル（ＲＲＣ＿ＩＤＬＥ）状態から上りリンク送信が行われる。

ＲＲＣコネクティッド（ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ）状態にあるユーザ装置は、ＰＵＲ設定要求（ＰＵＲ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｒｅｑｕｅｓｔ）メッセージを基地局へ送信し、ＰＵＲリソースを含むＲＲＣ接続解放（ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｌｅａｓｅ）メッセージを基地局から受信する。ＲＲＣ接続解放メッセージには、データ送信に用いるリソース（以下、「ＰＵＲリソース」という場合がある。）など、ＰＵＲ設定に必要な情報が含まれている。

ＲＲＣアイドル状態にあるユーザ装置は、ＰＵＲリソースを用いて、ＲＲＣ接続再開（ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｓｕｍｅ Ｒｅｑｕｅｓｔ）メッセージとともにデータを、基地局へ送信することができる。また、ＲＲＣアイドル状態にあるユーザ装置は、オプションとして、ＲＲＣ接続再開メッセージ後のＲＲＣ接続解放（ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｌｅａｓｅ）メッセージとともに下りデータを受信することも可能である。

３ＧＰＰ ＴＳ ３８．３００ Ｖ１６．２．０ （２０２０－０７）

第１の態様に係る通信制御方法は、ユーザ装置と基地局装置との間で無線通信が行われる移動通信システムにおける通信制御方法である。前記通信制御方法は、ＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）コネクティッド状態にある前記ユーザ装置が、第１のプレファレンス情報を前記基地局装置へ送信することと、前記基地局装置が、前記第１のプレファレンス情報を受信すること、とを有する。前記第１のプレファレンス情報は、ＲＲＣインアクティブ状態にある前記ユーザ装置が、ランダムアクセスプロシージャのメッセージを用いてデータを送信する第１データ送信と、及び予め設定された無線リソースを用いてデータを送信する第２データ送信とのうち少なくともいずれか１つを希望する情報である。

第２の態様に係る通信制御方法は、第１の複数のセルを有する基地局装置とユーザ装置、又は各々少なくとも１つのセルを有する前記基地局装置及び他の基地局装置により第２の複数のセルが構成された前記基地局装置及び前記他の基地局装置と前記ユーザ装置との間で無線通信が行われる移動通信システムにおける通信制御方法である。前記通信制御方法は、前記基地局装置が、ＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）コネクティッド状態にある前記ユーザ装置へ設定情報を送信することと、ＲＲＣコネクティッド状態にある前記ユーザ装置が、前記設定情報を受信することと、ＲＲＣインアクティブ状態にある前記ユーザ装置が、前記設定情報に基づいて、前記第１又は第２の複数のセルにおいて、予め設定された無線リソースを用いてデータを送信することと、を有する。前記設定情報は、ＲＲＣインアクティブ状態にある前記ユーザ装置が、前記第１又は第２の複数のセルにおいて、予め設定された前記無線リソースを用いて前記データを送信するための情報である。

第３の態様に係る通信制御方法は、基地局装置とユーザ装置との間で無線通信が行われる移動通信システムにおける通信制御方法である。前記通信制御方法は、前記基地局装置が、ＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）コネクティッド状態にある前記ユーザ装置へ設定情報を送信することと、ＲＲＣコネクティッド状態にある前記ユーザ装置が、前記設定情報を受信することと、を有する。また、前記通信制御方法は、ＲＲＣインアクティブ状態である前記ユーザ装置が、前記設定情報に基づいて、ランダムアクセスプロシージャのメッセージを用いてデータを送信する第１データ送信及び予め設定された無線リソースを用いてデータを送信する第２データ送信のうち少なくともいずれか１つを、キャリアアグリゲーション、デュアルコネクティビティ、及びＰＤＣＰ（Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ）デュプリケーションのうち少なくともいずれか１つにより行うことを有する。

第４の態様に係る通信制御方法は、基地局装置と無線通信を行うユーザ装置における通信制御方法である。前記通信制御方法は、ＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）インアクティブ状態である前記ユーザ装置が、ランダムアクセスプロシージャのメッセージを用いてデータを送信、又は予め設定された無線リソースを用いてデータを送信することを失敗したとき、失敗に関する情報を前記ユーザ装置のメモリに記憶することと、ＲＲＣインアクティブ状態にある前記ユーザ装置又はＲＲＣコネクティッド状態にある前記ユーザ装置が、前記メモリに記憶した前記失敗に関する情報を前記基地局装置へ送信することと、を有する。

一実施形態に係る移動通信システムの構成を示す図である。 一実施形態に係るユーザ装置の構成を示す図である。 一実施形態に係る基地局の構成を示す図である。 ユーザプレーンのプロトコルスタックの構成例を示す図である。 制御プレーンのプロトコルスタックの構成例を示す図である。 実施例１の動作例を表す図である。 ＵＥアシスタンス情報の例を表す図である。 図８（Ａ）はＥＤＴ、図８（Ｂ）はＰＵＲの動作例をそれぞれ表す図である。 図９（Ａ）と図９（Ｂ）はＵＥコンテキスト取得メッセージを用いた動作例を表す図である。 図１０はハンドオーバ要求メッセージを用いた動作例を表す図である。 図１１（Ａ）は１つのｇＮＢに２つのセルが存在する場合の例、図１１（Ｂ）は各ｇＮＢに各々１つのセルが存在する場合の例をそれぞれ表す図である。 図１２（Ａ）と図１２（Ｂ）はＰＵＲエリアの例を表す図である。 図１３は実施例２の動作例を表す図である。 図１４（Ａ）と図１４（Ｂ）はＣＡの例を表す図である。 図１５（Ａ）はＤＣ、図１５（Ｂ）はＰＤＣＰデュプリケーションの例をそれぞれ表す図である。 図１６は実施例３の動作例を表す図である。 図１７（Ａ）と図１７（Ｂ）はＳＤプロシージャ失敗の動作例を表す図である。 図１８は、実施例４の動作例を表す図である。

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

（移動通信システムの構成）
まず、一実施形態に係る移動通信システムの構成について説明する。一実施形態に係る移動通信システムは３ＧＰＰの５Ｇシステムであるが、移動通信システムには、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）が少なくとも部分的に適用されてもよい。

図１は、一実施形態に係る移動通信システムの構成を示す図である。

図１に示すように、移動通信システムは、ユーザ装置（ＵＥ：Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）１００と、５Ｇの無線アクセスネットワーク（ＮＧ－ＲＡＮ：Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）１０と、５Ｇのコアネットワーク（５ＧＣ：５Ｇ Ｃｏｒｅ Ｎｅｔｗｏｒｋ）２０とを有する。

ＵＥ１００は、移動可能な装置である。ＵＥ１００は、ユーザにより利用される装置であればどのような装置であっても構わないが、例えば、ＵＥ１００は、携帯電話端末（スマートフォンを含む）やタブレット端末、ノートＰＣ、通信モジュール（通信カード又はチップセットを含む）、センサ若しくはセンサに設けられる装置、車両若しくは車両に設けられる装置（Ｖｅｈｉｃｌｅ ＵＥ）、飛行体若しくは飛行体に設けられる装置（Ａｅｒｉａｌ ＵＥ）など、無線通信が可能な装置である。

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

なお、ｇＮＢ２００がＬＴＥのコアネットワークであるＥＰＣ（Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｃｏｒｅ）に接続されてもよいし、ＬＴＥの基地局が５ＧＣ２０に接続されてもよい。また、ＬＴＥの基地局（ＬＴＥシステムでは「ｅＮＢ」と呼ばれる）とｇＮＢとが基地局間インターフェイスを介して接続されてもよい。

５ＧＣ２０は、ＡＭＦ（Ａｃｃｅｓｓ ａｎｄ Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｆｕｎｃｔｉｏｎ）及びＵＰＦ（Ｕｓｅｒ Ｐｌａｎｅ Ｆｕｎｃｔｉｏｎ）３００－１，３００－２を含む。ＡＭＦは、ＵＥ１００に対する各種モビリティ制御等を行う。ＡＭＦは、ＮＡＳ（Ｎｏｎ－Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ）シグナリングを用いてＵＥ１００と通信することにより、ＵＥ１００が在圏するエリアの情報を管理する。ＵＰＦは、データの転送制御を行う。ＡＭＦ及びＵＰＦは、基地局－コアネットワーク間インターフェイスであるＮＧインターフェイスを介してｇＮＢ２００と接続される。

図２は、一実施形態に係るＵＥ１００（ユーザ装置）の構成を示す図である。

図２に示すように、ＵＥ１００は、受信部１１０、送信部１２０、及び制御部１３０を備える。

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

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

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

図３は、一実施形態に係るｇＮＢ２００（基地局）の構成を示す図である。

図３に示すように、ｇＮＢ２００は、送信部２１０、受信部２２０、制御部２３０、及びバックホール通信部２４０を備える。

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

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

制御部２３０は、ｇＮＢ２００における各種の制御を行う。制御部２３０は、少なくとも１つのプロセッサと、プロセッサと電気的に接続された少なくとも１つのメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサと、ＣＰＵと、を含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。ＣＰＵは、メモリに記憶されるプログラムを実行して各種の処理を行う。ＣＰＵに代えて、ＤＳＰ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｏｒ）やＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）などのプロセッサやコントローラであってもよい。

バックホール通信部２４０は、基地局間インターフェイスを介して隣接基地局と接続される。バックホール通信部２４０は、基地局－コアネットワーク間インターフェイスを介してＡＭＦ／ＵＰＦ３００－１，３００－２と接続される。なお、ｇＮＢ２００は、ＣＵ（Ｃｅｎｔｒａｌ Ｕｎｉｔ）とＤＵ（Ｄｉｓｔｒｉｂｕｔｅｄ Ｕｎｉｔ）とで構成され（すなわち、機能分割され）、両ユニット間がＦ１インターフェイスで接続されてもよい。

（プロトコルスタックについて）
図４は、データを取り扱うユーザプレーンの無線インターフェイスのプロトコルスタックの構成を示す図である。

図４に示すように、ユーザプレーンの無線インターフェイスプロトコルは、物理（ＰＨＹ）レイヤと、ＭＡＣ（Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）レイヤと、ＲＬＣ（Ｒａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌ）レイヤと、ＰＤＣＰ（Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ）レイヤと、ＳＤＡＰ（Ｓｅｒｖｉｃｅ Ｄａｔａ Ａｄａｐｔａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）レイヤとを有する。

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

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

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

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

ＳＤＡＰレイヤは、コアネットワークがＱｏＳ制御を行う単位であるＩＰフローとＡＳ（Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ）がＱｏＳ制御を行う単位である無線ベアラとのマッピングを行う。なお、ＲＡＮがＥＰＣに接続される場合は、ＳＤＡＰが無くてもよい。

図５は、シグナリング（制御信号）を取り扱う制御プレーンの無線インターフェイスのプロトコルスタックの構成を示す図である。

図５に示すように、制御プレーンの無線インターフェイスのプロトコルスタックは、図４に示したＳＤＡＰレイヤに代えて、ＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）レイヤ及びＮＡＳ（Ｎｏｎ－Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ）レイヤを有する。

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

ＲＲＣレイヤの上位に位置するＮＡＳレイヤは、セッション管理及びモビリティ管理等を行う。ＵＥ１００のＮＡＳレイヤとＡＭＦ３００－１，３００－２のＮＡＳレイヤとの間では、ＮＡＳシグナリングが伝送される。

なお、ＵＥ１００は、無線インターフェイスのプロトコル以外にアプリケーションレイヤ等を有する。

（ＥＤＴについて）
次に、ＥＤＴについて説明する。以下において、ＬＴＥのＥＤＴを５Ｇシステム（ＮＲ）に導入する実施形態について説明する。

ＥＤＴでは、ＲＲＣアイドル状態にあるＵＥ１００が、ランダムアクセスプロシージャのメッセージを利用して、データを送信したり、受信したりすることができる。上述したように、ＥＤＴには、ＭＯ－ＥＤＴとＭＴ－ＥＤＴがある。

ＭＯ－ＥＤＴでは、上りリンクデータ送信が行われる。また、ＭＯ－ＥＤＴでは、ランダムアクセスプロシージャ中に、上りリンクデータ送信に続く下りリンクデータ送信も可能である。ＵＥ１００の上位レイヤがＵＥ起点（ＭＯ：Ｍｏｂｉｌｅ Ｏｒｉｇｉｎａｔｅｄ）のデータのためのＲＲＣ接続の確立又は再開を要求し、且つ、上りリンクデータのサイズがシステム情報で示されたトランスポートブロック（ＴＢ）サイズ以下になると、ＥＤＴが開始される。ＭＯ－ＥＤＴでは、ＵＥ１００は、ランダムアクセスプロシージャにおけるＭｓｇ３を利用して上りリンクデータを送信する。

一方、ＭＴ－ＥＤＴでは、下りリンクデータ送信が行われる。ＵＥ１００は、ｅＮＢ（ｅｖｏｌｖｅｄ ＮｏｄｅＢ：ＬＴＥ基地局）から、ＭＴ－ＥＤＴの指示を含むページングメッセージを受信すると、ランダムアクセスプロシージャを実行する。そして、ＵＥ１００は、ランダムアクセスプロシージャのＭｓｇ４を利用して、下りデータを受信することができる。

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

Ｕｓｅｒ Ｐｌａｎｅ Ｏｐｔｉｍｉｓａｔｉｏｎは、ＵＥ１００がＲＲＣインアクティブ状態である場合に適用可能である。ＲＲＣインアクティブ状態では、ＵＥ１００のコンテキスト情報がｇＮＢ２００において維持される。Ｕｓｅｒ Ｐｌａｎｅ Ｏｐｔｉｍｉｓａｔｉｏｎでは、Ｍｓｇ３を構成するＲＲＣメッセージがＲＲＣ接続再開要求（ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｓｕｍｅ Ｒｅｑｕｅｓｔ）メッセージであり、Ｍｓｇ４を構成するＲＲＣメッセージが基本的にはＲＲＣ接続解放（ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｌｅａｓｅ）メッセージである。ＵＥ１００は、ＲＲＣ接続解放メッセージを受信すると、ＲＲＣインアクティブ状態を維持したままランダムアクセスプロシージャを終了する。本実施の形態では、Ｕｓｅｒ Ｐｌａｎｅ Ｏｐｔｉｍｉｓａｔｉｏｎを例にして説明する。

（ＰＵＲについて）
ＰＵＲは、ランダムアクセスプロシージャを用いることなく、予め設定された上りリンクの無線リソース（以下では、「ＰＵＲリソース」という場合がある。）を用いて、ＲＲＣアイドル状態から上りリンク送信を行う通信方法である。ＰＵＲにおける一連の処理は、例えば、以下となる。

すなわち、ＵＥ１００は、ＲＲＣコネクティッド状態にあるときに、ＰＵＲ設定要求（ＰＵＲ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｒｅｑｕｅｓｔ）メッセージを、ｇＮＢ２００へ送信する。ＰＵＲ設定要求メッセージには、ＰＵＲ機会の回数、ＰＵＲ機会の周期と最初のＰＵＲ機会までのオフセット時間、トランスポートブロックサイズ、ＡＣＫ要否などを含む。

ｇＮＢ２００は、ＰＵＲ設定要求メッセージを受信すると、ＵＥ１００をＲＲＣアイドル状態へ移行させることを決定し、ＰＵＲリソースをＵＥ１００のために供給する。そして、ｇＮＢ２００は、ＲＲＣ接続解放（ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｌｅａｓｅ）メッセージをＵＥ１００へ送信する。ＲＲＣ接続解放メッセージには、ＰＵＲリソースなど、ＰＵＲ設定（ＰＵＲ Ｃｏｎｆｉｇｕｒａｔｉｏｎ）の詳細を表す情報が含まれる。

ＵＥ１００は、ＲＲＣ接続解放メッセージを受信して、ＲＲＣアイドル状態に移行する。ＲＲＣアイドル状態にあるＵＥ１００は、ＲＲＣ接続解放メッセージに含まれる、予め設定された上りリンクのリソースを用いて、データをｇＮＢ２００へ送信する。このとき、ＵＥ１００は、ＲＲＣ接続要求（ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｑｕｅｓｔ）メッセージと上りデータとを多重化して、ｇＮＢ２００へ送信する。なお、本実施の形態では、後述するように、ＲＲＣインアクティブ状態からのＰＵＲ送信が可能である。上記のＲＲＣアイドル状態に代えて、ＲＲＣインアクティブ状態に移行したＵＥ１００は、ＲＲＣ接続再開要求（ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｓｕｍｅ Ｒｅｑｕｅｓｔ）メッセージと上りデータとを多重化して、ｇＮＢ２００へ送信することもできる。また、ＵＥ１００は、ＲＲＣ接続再開要求メッセージに代えて、ＣＰ－ＥＤＴ（Ｃｏｎｔｒｏｌ Ｐｌａｎｅ－Ｅａｒｌｙ Ｄａｔａ Ｔｒａｎｓｆｅｒ）用のメッセージである、ＲＲＣアーリーデータ要求（ＲＲＣ Ｅａｒｌｙ Ｄａｔａ Ｒｅｑｕｅｓｔ）メッセージと上りデータとを多重化して、ｇＮＢ２００へ送信することもできる。

なお、ＰＵＲは、オプションとして下りデータの送信も可能である。すなわち、ＲＲＣ接続再開要求メッセージの後、ｇＮＢ２００から送信されるＲＲＣ接続解放（ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｌｅａｓｅ）メッセージ（又はＲＲＣアーリーデータ完了（ＲＲＣ Ｅａｒｌｙ Ｄａｔａ Ｃｏｍｐｌｅｔｅ）メッセージ）に下りデータが多重化されており、ＲＲＣアイドル状態にあるＵＥ１００は、ＲＲＣ接続解放メッセージとともに下りデータを受信する。

また、ＲＲＣアイドル状態にあるＵＥ１００は、ＰＵＲリソースを用いて送信するには大きすぎるデータを送信する場合、ＲＲＣ接続再開要求メッセージとデータのセグメントとをＰＵＲリソースを用いてｇＮＢ２００へ送信する。以後、ｇＮＢ２００はＵＥ１００との間で接続再開プロシージャを実行して、ＵＥ１００は、ＲＲＣコネクティッド状態へ移行し、送信できなかった上りデータを送信する。

上述した処理は、ＵＥ１００がＲＲＣアイドル状態の場合の例である。本実施の形態では、ＵＥ１００がＲＲＣインアクティブ状態においても、ＰＵＲ送信が可能である。上述した例において、ＲＲＣアイドル状態を、ＲＲＣインアクティブ状態に代えて、実施することが可能である。

（ＳＤＴについて）
本実施形態においては、ＥＤＴとＰＵＲとをまとめてＳＤＴ（Ｓｍａｌｌ Ｄａｔａ Ｔｒａｎｓｍｉｓｓｉｏｎ）と称する場合がある。ＳＤＴを利用して送信されるデータは、所定サイズ以下のデータ（又はスモールデータ、或いは小データ）であればよく、ＥＤＴ又はＰＵＲを利用して送信されるデータにおいて送信可能なサイズであればよい。

なお、以下では、ＥＤＴを利用したデータ送信をＥＤＴ送信（第１データ送信）、ＰＵＲを利用したデータ送信をＰＵＲ送信（第２データ送信）、ＳＤＴを利用したデータ送信をＳＤＴ送信という場合がある。

（実施例１）
本実施例１における通信制御方法では、ＲＲＣコネクティッド状態にあるＵＥ１００が、プレファレンス情報をｇＮＢ２００へ送信する。ここでいうプレファレンス情報は、ＲＲＣインアクティブ状態にあるＵＥ１００が、ランダムアクセスプロシージャのメッセージを用いてデータを送信すること、及び予め設定された上りリンクのリソースを用いてデータを送信することのうち少なくとも一方を希望するプレファレンス情報である。以下では、このようなプレファレンス情報を、ＳＤＴプレファレンス情報と称する場合がある。ＵＥ１００が、ＳＤＴプレファレンス情報をｇＮＢ２００へ送信することにより、ｇＮＢ２００では、ＵＥ１００をＲＲＣインアクティブ状態に移行させるとき、ＰＵＲ送信又はＥＤＴ送信に必要な情報などを把握することができ、その後の処理の効率化を図ることが可能となる。

次に、本実施例１における動作例について説明する。図６は、本実施例１における動作例を表す図である。

図６に示すように、ステップＳ１０１において、ＵＥ１００は、ｇＮＢ２００とＲＲＣコネクティッド状態にある。

ステップＳ１０２において、ＵＥ１００は、ｇＮＢ２００へデータを送信し、ｇＮＢ２００から送信されたデータを受信する。

ステップＳ１０３において、ＵＥ１００は、ＥＤＴ又はＰＵＲによるデータ送信を希望する場合、ＳＤＴプレファレンス情報をｇＮＢ２００へ送信する。例えば、制御部１３０はこのような希望があると判断すると、ＳＤＴプレファレンス情報を生成し、送信部１２０を介してｇＮＢ２００へ送信する。

ＳＤＴプレファレンス情報は、例えば、ＵＥアシスタンス情報（ＵＥ Ａｓｓｉｓｔａｎｃｅ Ｉｎｆｏｒｍａｔｉｏｎ）メッセージに含まれて送信されてもよい。ＵＥアシスタンス情報メッセージは、例えば、ＲＲＣコネクティッド状態にあるＵＥ１００が、自身のＲＲＣ接続の設定に関する希望又は要求を伝えるためのメッセージである。ＵＥアシスタンス情報メッセージには、例えば、ＵＥ１００のパワーセービングのプレファレンス、及びＳＰＳ（Ｓｅｍｉ Ｐｅｒｓｉｓｔｅｎｔ Ｓｃｈｅｄｕｌｉｎｇ）補助情報などが含まれる。

図７は、ＳＤＴプレファレンス情報を含むＵＥアシスタンス情報メッセージの例を表す図である。図７に示すように、ＵＥアシスタンス情報メッセージには、ＳＤＴプレファレンス情報が含まれることを示す情報要素（「ｓｄｔＰｒｅｆｅｒｅｎｃｅ－ｒ１７」、図７の（Ｙ））が含まれる。そして、その情報要素には、「ＥＤＴ」、「ＭＯ－ＥＤＴ－Ｏｎｌｙ」、「ＭＴ－ＥＤＴ－Ｏｎｌｙ」、「ＰＵＲ」、及び「ＥＤＴ－ａｎｄ－ＰＵＲ」の各項目が含まれる（図７の（Ｚ））。

すなわち、ＵＥ１００がＥＤＴを希望する場合は「ＥＤＴ」が、図７の（Ｙ）に示す情報要素に含まれることになる。また、ＵＥ１００が、ＭＯ－ＥＤＴ（のみ）を希望する場合は、「ＭＯ－ＥＤＴ－Ｏｎｌｙ」、ＭＴ－ＥＤＴ（のみ）を希望する場合は、「ＭＴ－ＥＤＴ－Ｏｎｌｙ」、ＰＵＲを希望する場合は「ＰＵＲ」がそれぞれ図７の（Ｙ）に含まれることになる。さらに、ＥＤＴとＰＵＲを希望する場合は、「ＥＤＴ－ａｎｄ－ＰＵＲ」が図７の（Ｙ）に示す情報要素に含まれることになる。ＵＥ１００がＥＤＴもしくはＰＵＲを希望する場合、「ＥＤＴ－ｏｒ－ＰＵＲ」の情報要素で示されてもよく、もしくは、「ＳＤＴ設定希望」のみが情報要素に含まれて通知されてもよい。

なお、ＳＤＴプレファレンス情報は、図７に示すＵＥアシスタンス情報メッセージの情報要素「ｒｅｌｅａｓｅＰｒｅｆｅｒｅｎｃｅ－ｒ１６」と連動してもよい。「ｒｅｌｅａｓｅＰｒｅｆｅｒｅｎｃｅ－ｒ１６」は、例えば、ＵＥ１００がＲＲＣ接続の解放を希望する場合に利用される情報要素である。「ｒｅｌｅａｓｅＰｒｅｆｅｒｅｎｃｅ－ｒ１６」には、「Ｉｄｌｅ」、「Ｉｎａｃｔｉｖｅ」、「Ｃｏｎｎｅｃｔｅｄ」の各要素が含まれる。例えば、以下のように連動してもよい。

すなわち、ＵＥ１００は、「ｒｅｌｅａｓｅＰｒｅｆｅｒｅｎｃｅ－ｒ１６」に「Ｉｎａｃｔｉｖｅ」が含まれる場合（のみ）、ＳＤＴプレファレンス情報を通知（又は送信）してもよい。または、ＵＥ１００は、「ｒｅｌｅａｓｅＰｒｅｆｅｒｅｎｃｅ－ｒ１６」に「Ｉｄｌｅ」が含まれる場合、ＳＤＴプレファレンス情報を送信してはいけないようしてもよい。または、ＵＥ１００が「ｒｅｌｅａｓｅＰｒｅｆｅｒｅｎｃｅ－ｒ１６」に「Ｉｄｌｅ」が含まれる場合でもＳＤＴプレファレンス情報を含めてＵＥアシスタンス情報メッセージを送信しても、ｇＮＢ２００は、ＵＥアシスタンス情報メッセージに含まれるＳＤＴプレファレンス情報を無視してもよい。

上述した例は、ＳＤＴプレファレンス情報がＵＥアシスタンス情報メッセージに含まれる例を説明した。ＳＤＴプレファレンス情報は、他の（ＲＲＣ）メッセージに含まれてもよい。

また、ＵＥ１００は、ＳＤＴプレファレンス情報とともに、パケット情報を、ｇＮＢ２００へ送信してもよい。パケット情報には、例えば、ＵＥ１００がＳＤＴにより送信するデータが含まれるパケットのサイズ、パケットの周期及び／又は発生タイミングなどが含まれもよい。また、パケット情報には、サービス種別が含まれてもよい。サービス種別としては、例えば、「ｄｅｌａｙ ｔｏｌｅｒａｎｔ」（遅延耐性）、「ｍｉｓｓｉｏｎ ｃｒｉｔｉｃａｌ」（ミッションクリティカル）、「ｎｏｒｍａｌ ｄａｔａ」（データ）、「ｓｉｇｎａｌｌｉｎｇ」（シグナリング）などがある。このようなサービス種別が、ＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）、５ＱＩ（５Ｇ ＱｏＳ Ｉｎｄｉｃａｔｏｒ）、又はＮＳＳＡＩ（Ｎｅｔｗｏｒｋ Ｓｌｉｃｅ Ｓｅｌｅｃｔｉｏｎ Ａｓｓｉｓｔａｎｃｅ Ｉｎｆｏｒｍａｔｉｏｎ）で表されてもよい。また、ＵＥ１００においては、このようなサービス種別に関する情報がＮＡＳ（Ｎｏｎ Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ）層又はアプリケーション層から通知されてもよい。もしくは、サービス種別は、ＵＥ１００における送信履歴などをベースにして、ＡＳ（Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ）層で推定されてもよい。

さらに、ＵＥ１００は、ＳＤＴプレファレンス情報に、周波数のプレファレンス情報（以下、「周波数プレファレンス情報」という。）を追加して送信してもよい。周波数プレファレンス情報は、例えば、ＵＥ１００がデータ送信（又はＳＤＴ送信）する際に用いることを希望する周波数に関するプレファレンス情報である。周波数プレファレンス情報としては、例えば、ＵＥ１００が希望するキャリア番号、ＢＷＰ（Ｂａｎｄｗｉｄｔｈ Ｐａｒｔ）、又は帯域幅などであってもよい。

さらに、ＵＥ１００は、ＳＤＴプレファレンス情報に、マルチセルＰＵＲを希望するか否かの情報を追加して、ｇＮＢ２００へ送信してもよい。マルチセルＰＵＲについては、（実施例２）において説明する。さらに、ＵＥ１００は、ＳＤＴプレファレンス情報に、ＵＥ１００自身の移動状態に関する情報を含ませて送信してもよい。このような移動状態に関する情報には、現在の移動状態（地理的に固定、低速移動、高速移動など）に関する情報が含まれてもよく、ＵＥ１００の今後の移動の予測値が含まれてもよい。さらに、ＵＥ１００は、将来的に現在のサービングセル（又はサービングｇＮＢ２００）内に留まるか否かの情報をＳＤＴプレファレンス情報に含めて送信してもよい。

以上説明したＳＤＴプレファレンス情報、追加情報、及びＵＥアシスタンス情報メッセージなどなどは、制御部１３０において生成され、送信部１２０を介して、ｇＮＢ２００へ送信されてもよい。

図６に戻り、ｇＮＢ２００は、ＳＤＴプレファレンス情報を受信すると、ステップＳ１０４において、設定判断を行う。すなわち、ｇＮＢ２００は、ＳＤＴプレファレンス情報に基づいて、ＵＥ１００に対する設定を行う。例えば、ｇＮＢ２００は、以下のような設定を行う。

すなわち、ｇＮＢ２００は、ＰＤＣＰレイヤにおけるヘッダ圧縮技術であるＲＯＨＣ（Ｒｏｂｕｓｔ Ｈｅａｄｅｒ Ｃｏｍｐｒｅｓｓｉｏｎ）のＯＮ又はＯＦＦの設定、又はデータの暗号化などに用いられるＮＣＣ（Ｎｅｘｔ Ｈｏｐ Ｃｈａｎｇｉｎｇ Ｃｏｕｎｔｅｒ）値などを、ＳＤＴ（すなわち、ＥＤＴもしくはＰＵＲ送信）のために設定してもよい。また、ｇＮＢ２００は、適切なサイズの上りリンクの無線リソースを設定してもよい。このような無線リソースは、とくにＰＵＲリソースとして用いられる。ｇＮＢ２００は、ＰＵＲリソース以外にも、ＵＥ１００がＳＤＴによる送信を行う場合に必要な情報を設定してもよい。以上のような設定判断は、制御部２３０で行われてもよい。

ステップＳ１０５において、ｇＮＢ２００は、ＲＲＣ接続解放メッセージをＵＥ１００へ送信する。この場合、ｇＮＢ２００は、ステップＳ１０４で設定した情報をＲＲＣ接続解放メッセージに含めて送信する。また、当該ＲＲＣ接続解放メッセージは、Ｓｕｓｐｅｎｄ Ｃｏｎｆｉｇ．を含んでもよい。すなわち、ＲＲＣ接続解放メッセージには、ＲＲＣインアクティブ状態にあるＵＥ１００がＳＤＴ送信を行う際に利用される、ＳＤＴ送信のための設定情報が含まれてもよい。この場合、例えば、設定情報には、ＵＥ１００においてＥＤＴが行われる場合とＰＵＲが行われる場合の双方の設定情報が含まれてもよい。そして、双方の設定情報を受信したＵＥ１００では、例えば、以下のような処理が行われてもよい。

すなわち、ＵＥ１００は、所定の条件に従って、ＥＤＴ又はＰＵＲのいずれかを実行することを決定し、決定したＥＤＴ又はＰＵＲについての設定情報を用いてＥＤＴ又はＰＵＲを実行してもよい。所定の条件としては、例えば、Ａ）ＵＥ１００がＳＤＴプレファレンス情報で通知したＳＤＴを実行する、Ｂ）ＵＥ１００が同一セル内に在圏する場合はＰＵＲを実行し、他のセルへ移動した場合はＥＤＴを実行する、Ｃ）ＴＡ（Ｔｉｍｉｎｇ Ａｄｖａｎｃｅ）が有効な場合はＰＵＲを実行し、無効になったらＵＥ１００がＥＤＴを実行する、Ｄ）無線状態によって判断する（閾値はｇＮＢ２００から設定されてもよい）、又は、Ｅ）ＵＥ１００の実装依存、がある。

なお、上記Ｄ）の「無線状態」とは、受信信号品質であり、例えば、ＲＳＲＰ（Ｒｅｆｅｒｅｎｃｅ Ｓｉｇｎａｌ Ｒｅｃｅｉｖｅｄ Ｐｏｗｅｒ）、ＲＳＲＱ（Ｒｅｆｅｒｅｎｃｅ Ｓｉｇｎａｌ Ｒｅｃｅｉｖｅｄ Ｑｕａｌｉｔｙ）、ＳＩＮＲ（Ｓｉｇｎａｌ ｔｏ Ｉｎｔｅｒｆｅｒｅｎｃｅ ｐｌｕｓ Ｎｏｉｓｅ Ｒａｔｉｏ）などである。

また、ＵＥ１００は、ＥＤＴとＰＵＲとの双方の設定情報を受信していた場合、ＰＵＲ送信の実行を優先的に行ってもよい。例えば、ＵＥ１００は、ＰＵＲ送信が実行可能である場合（上記したＢ）、Ｃ）、又はＤ）による判定を行ってもよい）、ＰＵＲ送信を実行する。ＵＥ１００は、ＰＵＲ送信が実行不可である場合、ＥＤＴを実行する。

或いは、ＵＥ１００は、ＥＤＴとＰＵＲとの双方の設定情報を受信しており、かつ、ＰＵＲ送信を実行した場合であって、当該ＰＵＲ送信が失敗した場合、ＥＤＴを実行してもよい。例えば、ＵＥ１００は、パケット送信をＰＵＲで試みたが、ｇＮＢ２００から応答がなかった場合、ＥＤＴ実行へフォールバックを行い、Ｍｓｇ３もしくはＭｓｇＡにおいて当該パケットを送信する。

或いは、ＵＥ１００は、ＥＤＴとＰＵＲとの双方の設定情報を受信しており、ＥＤＴもしくはＰＵＲ送信のいずれか一方が成功した場合、当該ＥＤＴ及び／又はＰＵＲ設定を破棄してもよい。

なお、以下では、ＵＥ１００は、所定の条件を考慮して、ＥＤＴ又はＰＵＲを実行するものとして説明する。

例えば、制御部２３０においてＲＲＣ接続解放メッセージを生成して、送信部２１０を介して送信してもよい。また、上記のような決定や実行などは、ｇＮＢ２００においては制御部２３０、ＵＥ１００においては制御部１３０でそれぞれ行われてもよい。

ステップＳ１０６において、ＵＥ１００は、ＲＲＣインアクティブ状態へ遷移する。例えば、制御部１３０は、受信部１１０を介してＲＲＣ接続解放メッセージを受信すると、当該メッセージに含まれる情報に従って、ＵＥ１００をＲＲＣインアクティブ状態へ遷移させる。

ＲＲＣインアクティブ状態とは、例えば、ＵＥ１００のＲＲＣとｇＮＢ２００のＲＲＣとの接続が中断（サスペンド）されている状態である。ＲＲＣインアクティブ状態では、ＵＥ１００、ｇＮＢ２００、ネットワークにおいてＵＥコンテキストが保持される。このため、ＵＥ１００は、ＲＲＣインアクティブ状態からＲＲＣコネクティッド状態へ復帰するための手順にかかる信号数の削減を図ることができる。また、ＲＲＣインアクティブ状態のＵＥ１００は、ＲＲＣアイドル状態と同様であるため、ＵＥ１００の省電力化を図ることも可能である。ＲＲＣインアクティブ状態により、例えば、ＩｏＴ（Ｉｎｔｅｒｎｅｔ Ｏｆ Ｔｈｉｎｇｓ）のシナリオが考慮され、ＳＤＴ通信に適したＲＲＣ接続状態を設定することが可能となる。

ステップＳ１０７において、ＵＥ１００は、ｇＮＢ２００による設定（ステップＳ１０５）に従って、ＳＤＴによるデータ送信を行う。

図８（Ａ）は、ＥＤＴによるデータ送信の動作例を表す図である。

ステップＳ１０７０において、ＵＥ１００は、データが発生すると（Ｓ１０７０）、ランダムアクセスプロシージャによる一連のメッセージを送受信する（ステップＳ１０７１～Ｓ１０７４）。

すなわち、ステップＳ１０７１において、ＵＥ１００は、Ｍｓｇ１（ランダムアクセスプリアンブル）をｇＮＢ２００へ送信する。なお、「Ｍｓｇ」はメッセージの略である。

ステップＳ１０７２において、ｇＮＢ２００は、ＵＥ１００に割り当てた上りリンクにおけるリソースを示すスケジューリング情報を含むＭｓｇ２（ランダムアクセス応答）をＵＥ１００へ送信する。

ステップＳ１０７３において、ＵＥ１００は、スケジューリング情報に従って、Ｍｓｇ３をｇＮＢ２００へ送信する。Ｍｓｇ３は、例えば、ＲＲＣ接続再開要求（ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｓｕｍｅ Ｒｅｑｕｅｓｔ）メッセージである。ＵＥ１００は、ＭＡＣレイヤにおいて、ＲＲＣ接続再開要求メッセージとデータ（ＤＴＣＨ）とを１つのＭＡＣ ＰＤＵに多重化して送信する。これにより、上りリンクのＥＤＴが行われる。もしくは、ＵＥ１００は、ＲＲＣレイヤにおいて、ＲＲＣ接続再開要求メッセージの中にデータをカプセル化してもよい。

ステップＳ１０７４において、ｇＮＢ２００は、Ｍｓｇ４をＵＥ１００へ送信する。Ｍｓｇ４は、例えば、ＲＲＣ接続解放（ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｌｅａｓｅ）メッセージである。ｇＮＢ２００は、下りリンクのデータをＭｓｇ４に多重化もしくはカプセル化して送信してもよい。これにより、下りリンクのＥＤＴが行われる。ＵＥ１００は、ＲＲＣ接続解放メッセージを受信すると、ＲＲＣインアクティブ状態を維持したまま、ランダムアクセスプロシージャを終了する。

例えば、Ｍｓｇ１とＭｓｇ３の生成やデータの多重化などは、制御部１３０で行われ、Ｍｓｇ２とＭｓｇ４の生成やデータの多重化などは制御部２３０で行われてもよい。２－ｓｔｅｐ ＲＡＣＨの場合は、例えば、ＭｓｇＡの生成などが制御部１３０で行われ、ＭｓｇＢの生成などは制御部２３０で行われてもよい。

図８（Ｂ）は、ＰＵＲによるデータ送信の例を表す図である。

ステップＳ１０７０において、データが発生すると、ステップＳ１０７５において、ＵＥ１００は設定されたＰＵＲリソースを用いて、例えば、ＲＲＣ接続再開要求（ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｓｕｍｅ Ｒｅｑｕｅｓｔ）メッセージをｇＮＢ２００へ送信する。ＥＤＴの場合と同様に、ＵＥ１００は、ＭＡＣレイヤにおいて、ＲＲＣ接続再開要求メッセージとデータとを１つのＭＡＣ ＰＤＵに多重化して送信する。これにより、上りリンクのＰＵＲが行われる。もしくは、ＵＥ１００は、ＲＲＣレイヤにおいて、ＲＲＣ接続再開要求メッセージの中にデータをカプセル化してもよい。

なお、ＵＥ１００では、ＰＵＲリソースを用いて送信するにはデータが大きすぎる場合、ＲＲＣ接続解放要求メッセージとユーザデータのセグメントとをＰＵＲリソースを用いてｇＮＢ２００へ送信する。以後、レガシーＲＲＣ接続再開プロシージャが開始され、ＲＲＣ接続後にデータ送信が行われる。

ステップＳ１０７６において、ｇＮＢ２００は、ＲＲＣ接続解放メッセージをＵＥ１００へ送信する。ｇＮＢ２００は、ＥＤＴの場合と同様に、下りリンクのデータをＲＲＣ接続解放メッセージに多重化もしくはカプセル化して送信してもよい、これにより、下りリンクのＰＵＲが行われる。

なお、実施例１においては、ＥＤＴとＰＵＲの双方を実施することも可能である。例えば、図８（Ａ）に示すプロシージャを行った後、図８（Ｂ）に示すプロシージャを行うこともできるし、その逆も可能である。例えば、図７に示すＵＥアシスタンス情報メッセージに情報要素「ｓｄｔＰｒｅｆｅｒｅｎｃｅ－ｒ１７」に「ＥＤＴ－ａｎｄ－ＰＵＲ」が含まれる場合は、このようなプロシージャが行われてもよい。

（実施例１－１）
次に、実施例１－１について説明する。実施例１－１は、プレファレンス情報を受信したｇＮＢ２００がＵＥコンテキストと紐づけして、ＳＤＴプレファレンス情報を他のｇＮＢへ送信する例である。

ＲＲＣインアクティブ状態にあるＵＥ１００は、ＲＲＣアイドル状態と同様に、セル選択やセル再選択を行うことができる。例えば、ＵＥ１００は、ＳＤＴプレファレンス情報を送信したｇＮＢ２００とは異なる他のｇＮＢのセルを選択して、そのようなｇＮＢへデータを送信することも可能である。この場合、他のｇＮＢにＵＥ１００のＳＤＴプレファレンス情報がないと、ＵＥ１００は、他のｇＮＢへ改めてＳＤＴプレファレンス情報を送信することになる。これでは、ＵＥ１００の省電力化を図ることができず、また、処理の効率化を図ることもできない。

そこで、本実施例１－１では、プレファレンス情報を受信したｇＮＢ２００が他のｇＮＢへ受信したＳＤＴプレファレンス情報を送信することで、ＵＥ１００の省電力化と処理の効率化を図るようにしている。

具体的には、ＸｎインターフェイスのＵＥコンテキスト取得（ＵＥ Ｃｏｎｔｅｘｔ Ｒｅｔｒｉｅｖａｌ）メッセージを利用した場合と、ハンドオーバ要求（Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ）メッセージを利用した場合との、２つの場合がある。

図９（Ａ）と図９（Ｂ）は、ＵＥコンテキスト取得メッセージを用いた場合における動作例を表す。このうち、図９（Ａ）は、ＵＥ１００トリガーのＲＲＣインアクティブ状態からＲＲＣコネクティッド状態への移行（ＵＥ ｔｒｉｇｇｅｒｅｄ ｔｒａｎｓｉｔｉｏｎ ｆｒｏｍ ＲＲＣ＿ＩＮＡＣＴＩＶＥ ｔｏ ＲＲＣ ＣＯＮＮＥＣＴＥＤ）プロシージャの例である。一方、図９（Ｂ）は、ＲＲＣ再確立（Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ）プロシージャの例である。

図９（Ａ）の例では、ＵＥ１００からＳＤＴプレファレンス情報を受信したｇＮＢは、ラストサービングｇＮＢ２００－２として表されている。

ステップＳ２０１において、ＲＲＣインアクティブ状態にあるＵＥ１００は、ステップＳ２０２において、ＳＤＴプレファレンス情報を送信したｇＮＢ２００－２とは異なるｇＮＢ２００－１へ、ＲＲＣ接続再開要求メッセージを送信する。当該メッセージには、ＵＥ１００がラストサービングｇＮＢ２００－２から供給されたＩ－ＲＮＴＩ（Ｉｎａｃｔｉｖｅ－Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｔｅｍｐｏｒａｒｙ Ｉｄｅｎｔｉｆｉｅｒ）が含まれる。ステップＳ２０３において、ｇＮＢ２００－１は、Ｉ－ＲＮＴＩに含まれるｇＮＢの識別情報を解くことができると、そのｇＮＢ、すなわち、ラストサービングｇＮＢ２００－２へ、ＵＥコンテキスト取得要求（Ｒｅｔｒｉｅｖｅ ＵＥ Ｃｏｎｔｅｘｔ Ｒｅｑｕｅｓｔ）メッセージを送信する。ステップＳ２０４において、ラストサービングｇＮＢ２００－２は、ＵＥコンテキスト取得応答（Ｒｅｔｒｉｅｖｅ ＵＥ Ｃｏｎｔｅｘｔ Ｒｅｓｐｏｎｓｅ）メッセージをｇＮＢ２００－１へ送信する。ＵＥコンテキスト取得応答メッセージには、ＵＥコンテキストデータとともに、ＵＥ１００から受信したＳＤＴプレファレンス情報が含まれる。これにより、ＵＥ１００からＲＲＣ接続要求を受けたｇＮＢ２００－１は、ラストサービングｇＮＢ２００－２からＳＤＴプレファレンス情報を取得できる。以後、ステップＳ２０５とＳ２０６において、一連の移行手順が行われる。なお、図９（Ａ）の例では、ステップＳ２０５において、ＲＲＣ接続再開メッセージに加え、ＲＲＣ接続解放メッセージが送信されてもよい。

図９（Ｂ）の例も、図９（Ａ）と同様に、ラストサービングｇＮＢ２００－２がＵＥ１００からＳＤＴプレファレンス情報を受信したｇＮＢである。

ステップＳ２１０において、ＲＲＣコネクティッド状態にあるＵＥ１００は、ステップＳ２１１において、ＲＲＣ再設定要求（ＲＲＣ Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ Ｒｅｑｕｅｓｔ）メッセージを、ｇＮＢ２００－１へ送信する。ＲＲＣ再設定要求メッセージには、ＵＥの識別情報（ＰＣＩ（Ｐｈｙｓｉｃａｌ Ｃｅｌｌ Ｉｄｅｎｔｉｆｉｅｒ）とＣ－ＲＮＴＩ（Ｃｅｌｌ－ＲＮＴＩ））が含まれる。ステップＳ２１２において、ｇＮＢ２００－１は、ＵＥコンテキストがローカルに利用できない場合、ラストサービングｇＮＢ２００－２へ、ＵＥコンテキスト取得要求（Ｒｅｔｒｉｅｖｅ ＵＥ Ｃｏｎｔｅｘｔ Ｒｅｑｕｅｓｔ）メッセージを送信する。ステップＳ２１３において、ラストサービングｇＮＢ２００－２は、ＵＥコンテキスト取得応答（Ｒｅｔｒｉｅｖｅ ＵＥ Ｃｏｎｔｅｘｔ Ｒｅｓｐｏｎｓｅ）メッセージをｇＮＢ２００－１へ送信する。ＵＥコンテキスト取得応答メッセージには、ＵＥ１００のＵＥコンテキストとともに、ＵＥ１００から取得したＳＤＴプレファレンス情報が含まれる。以後、ステップＳ２１４において、一連の再設定手順が行われる。

図１０は、ハンドオーバ要求メッセージを利用して、ＳＤＴプレファレンス情報が送信される動作例を表す図である。図１０の例では、ソースｇＮＢ２００－１がＵＥ１００からＳＤＴプレファレンス情報を受信したｇＮＢとなる。

ステップＳ２２０において、ＵＥ１００とソースｇＮＢ２００－１は、測定制御及び測定報告を行う。ステップＳ２２１において、ソースｇＮＢ２００－１は、ハンドオーバを行うことを決定する。ステップＳ２２２において、ソースｇＮＢ２００－１は、ハンドオーバ要求（ＨＯ Ｒｅｑｕｅｓｔ）メッセージをターゲットｇＮＢ２００－２へ送信する（Ｓ２２２）。このとき、ソースｇＮＢ２００－１は、ＵＥ１００のＵＥコンテキストとともに、ＵＥ１００から受信したＳＤＴプレファレンス情報をハンドオーバ要求メッセージに含めて、ターゲットｇＮＢ２００－２へ送信する。以後は、ステップＳ２２３とＳ２２４において、ハンドオーバの一連の処理が行われる。

図９（Ａ）から図１０に示す一連の処理は、例えば、制御部２３０で行われ、バックホール通信部２４０を介して、他のｇＮＢへ送信してもよい。

（実施例２）
実施例２は、複数のセルにおいてＰＵＲがサポートされる例である。このようなＰＵＲのことを、「マルチセルＰＵＲ」という場合がある。

現状の３ＧＰＰでは、ＵＥ１００があるセルにおいて基地局からＰＵＲ設定を受け、そのセルとは異なる他のセルにおいてＵＥ１００がアクセスしたとき、ＵＥ１００と（ｎｇ－）ｅＮＢにおいて、ＰＵＲ設定（ＰＵＲ Ｃｏｎｆｉｇｕｒａｔｉｏｎ）が解放（ｒｅｌｅａｓｅ）される（３ＧＰＰ ＴＳ ３６．３００ Ｖ１６．２．０（２０２０－０７））。

図１１（Ａ）と図１１（Ｂ）では、そのような状況の例を説明するための図である。このうち、図１１（Ａ）は、１つのｇＮＢ２００が２つのセルを有する場合の例であり、図１１（Ｂ）は、各ｇＮＢ２００－１，２００－２が各々１つずつのセルを有する場合の例である。いずれの場合も、ＵＥ１００は、セル＃１において、ｇＮＢ２００又はｇＮＢ２００－１に対して、ＰＵＲ設定要求（ＰＵＲ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｒｅｑｕｅｓｔ）メッセージを送信し、ｇＮＢ２００又はｇＮＢ２００－１から、ＰＵＲ設定（ＰＵＲ Ｃｏｎｆｉｇｕｒａｔｉｏｎ）メッセージを受信している。そして、図１１（Ａ）と図１１（Ｂ）に示すように、ＵＥ１００がセル＃２へ移動して、セル＃２において、ｇＮＢ２００又はｇＮＢ２００－２へアクセスすると、ＰＵＲ設定メッセージに含まれるＰＵＲ設定が解放される。

本実施例２では、ＰＵＲ設定が複数のセル（又はマルチセル。以下、「マルチセル」という場合がある。）でサポートされるようにする例である。すなわち、マルチセルＰＵＲでは、予め設定された上りリンクの無線リソースを用いてデータを送信する場合に用いられる設定情報が複数のセルで利用することができる。これにより、ＵＥ１００は、ＰＵＲ設定メッセージを受信したセル以外の他のセルへ移動しても、そのＰＵＲ設定メッセージに含まれるＰＵＲ設定をそのまま使用して、他のセルにおいて、ＰＵＲによるデータ送信を行うことが可能となる。したがって、ＵＥ１００は、セルを移動する度にＰＵＲ設定に関する一連のプロシージャを行う場合と比較して、消費電力の削減を図るとともに、ネットワーク側でも処理の効率化を図ることができる。

本実施例２では、マルチセルＰＵＲを実現するために、ＰＵＲ設定が有効なエリア（以下では、「ＰＵＲエリア」という場合がある。）が設定される。

図１２（Ａ）と図１２（Ｂ）は、ＰＵＲエリアの例を表す図である。図１２（Ａ）の例は、１つのｇＮＢ２００に２つのセル＃１，＃２が存在し、２つのセル＃１，＃２に対してＰＵＲエリアが設定される例である。

また、図１２（Ｂ）の例は、２つのｇＮＢ２００－１，２００－２に各々、１つずつセル＃１，＃２が存在する例である。

いずれの場合も、ＵＥ１００は、セル＃１でＰＵＲ設定を受けて、セル＃２へ移動する例を表している。そして、いずれの場合も、ＵＥ１００は、セル＃２において、セル＃１で設定されたＰＵＲ設定を用いて、ＰＵＲ送信が可能である。すなわち、ＵＥ１００は、ＰＵＲエリア内であればどのセルからも同一のＰＵＲ設定でＰＵＲ送信が可能となる。このように、ＰＵＲエリアの情報は、例えば、１つのｇＮＢ２００で複数セルが存在する場合でも、複数のｇＮＢ２００－１，２００－２の各々で少なくとも１つずつのセルが存在して複数のセルが構成される場合でも、複数のセルにおいて、ＰＵＲの設定情報が有効なエリアを示すエリア情報が含まれていればよい。

図１３は、本実施例２の動作例を表す図である。図１３の例は、２つのｇＮＢ２００－１，２００－２に各々１つずつセル＃１，＃２が存在する場合の例である。

図１３に示すように、ステップＳ３００において、ＵＥ１００は、ｇＮＢ２００－１とＲＲＣコネクティッド状態となっている。

ステップＳ３０１において、ＵＥ１００は、ＰＵＲ設定要求（ＰＵＲ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｒｅｑｕｅｓｔ）メッセージをｇＮＢ２００－１へ送信する。

ステップＳ３０２において、ｇＮＢ２００－１は、ＰＵＲ設定（ＰＵＲ Ｃｏｎｆｉｇｕｒａｔｉｏｎ）に関する情報を含むＲＲＣ接続解放（ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｌｅａｓｅ）メッセージをＵＥ１００へ送信する。このとき、ｇＮＢ２００－１は、ＰＵＲエリアの情報をＰＵＲ設定に関する情報に含ませて、ＰＵＲエリアの情報をＵＥ１００へ送信する。ＰＵＲエリアの情報としては、具体的には、例えば、以下のようなものがある。

すなわち、ＰＵＲエリアの情報として、ＰＵＲ設定が有効なセルをリスト化した情報であってもよい。例えば、図１２（Ａ）の例では、ＰＵＲエリアの情報は、「セル＃１」と「セル＃２」とがリスト化された情報となる。

または、ＰＵＲエリアの情報として、ＰＵＲエリアを識別するＩＤ（Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）であってもよい。このようなＩＤは、どのＰＵＲエリアでどのＩＤとなっているかが予め定義され、ＵＥ１００とｇＮＢ２００－１，２００－２で情報が共有されているものとする。例えば、図１２（Ａ）に示すＰＵＲエリアが「ＰＵＲエリア＃１」というＩＤの場合、この「ＰＵＲエリア＃１」がＰＵＲエリアの情報となる。

または、ＰＵＲエリアがＲＮＡ（ＲＡＮ－ｂａｓｅｄ Ｎｏｔｉｆｉｃａｔｉｏｎ Ａｒｅａ）と同一であってもよい。この場合、例えば、そのような定義がなされ、ＵＥ１００とｇＮＢ２００－１，２００－２で共有されていればよい。そして、この場合、ｇＮＢ２００－１は、明示的にＰＵＲエリアを設定しなくてもよく、ＰＵＲエリアの情報がＰＵＲ設定に含まれなくてもよい。あるいは、ｇＮＢ２００－１は、ＰＵＲエリアがＲＮＡと同一であることをＵＥ１００に通知してもよい。

なお、ＰＵＲ設定については、ＰＵＲエリアの情報以外については、セル毎に異なる設定がなされてもよい。例えば、図１２（Ａ）の例では、セル＃１とセル＃２とでは、セル毎に異なる設定情報となっていてもよい。そして、そのような場合、ｇＮＢ２００－１は、セル毎に異なるＰＵＲ設定に関する情報を含むＲＲＣ接続解放メッセージをＵＥ１００へ送信する。

図１３に戻り、ステップＳ３０３において、ｇＮＢ２００－１は、ｇＮＢ２００－２へ、ＰＵＲ設定を含むＰＵＲ設定通知メッセージを送信してもよい。例えば、ｇＮＢ２００－１は、Ｘｎインターフェイスを利用してＰＵＲ設定通知メッセージを送信してもよいし、ＡＭＦ３００－１，３００－２経由で、ＮＧインターフェイスを利用して、当該メッセージをｇＮＢ２００－２へ送信してもよい。ｇＮＢ２００－２は、当該ＰＵＲ設定通知メッセージに対して、応答メッセージをｇＮＢ２００－１へ返送してもよい。当該応答メッセージには、ステップＳ３０３のＰＵＲ設定通知メッセージが受け入れ可能であるか否かの情報を含んでもよい。すなわち、ｇＮＢ２００－２は、受け入れ可能である場合は肯定応答（ＡＣＫ）メッセージ、受け入れ不可である場合は否定応答（ＮＡＣＫ）メッセージをそれぞれ返送する。

なお、図１３の例では、ｇＮＢ２００－１は、ＲＲＣ接続解放メッセージを送信した後に、ＰＵＲ設定通知メッセージを送信しているが、ＲＲＣ接続解放メッセージを送信する前（又はＰＵＲ設定を行う前）に、ＰＵＲ設定通知メッセージをｇＮＢ２００－２へ送信してもよい。

ステップＳ３０４において、ＵＥ１００は、ＲＲＣインアクティブ状態へ遷移し、ステップＳ３０５において、セル＃１からセル＃２へ移動する。そして、ステップＳ３０６において、ＵＥ１００は、セル＃２を有するｇＮＢ２００－２に対して、ＰＵＲ設定に従って、ＰＵＲ送信を行う。具体的には、例えば、以下のような動作を行う。

すなわち、ＵＥ１００は、ＰＵＲ設定に含まれるＰＵＲエリアの情報に基づいて、在圏するセルがＰＵＲエリアに含まれるセルか否かを判断する。そして、ＵＥ１００は、ＰＵＲエリアの情報に含まれる有効なエリア内のセルであると判断すると、ステップＳ３０６において、ＰＵＲ送信を行う。一方、ＵＥ１００は、在圏するエリアがＰＵＲエリアに含まれるセルではないと判断すると、ＰＵＲ送信は行わない。このとき、ＵＥ１００は、ステップＳ３０２で受信したＰＵＲ設定に関する情報を破棄してもよい。

なお、上述した例では、ＰＵＲエリアに関する情報は、ＰＵＲ設定に関する情報に含まれて、ＲＲＣ接続解放メッセージを利用してＵＥ１００へ送信されるものとして説明した。例えば、ｇＮＢ２００－１，２００－２は、ＰＵＲエリアＩＤなどのＰＵＲエリアに関する情報を、ＳＩＢ（Ｓｙｓｔｅｍ Ｉｎｆｏｒｍａｔｉｏｎ Ｂｌｏｃｋ）を用いて報知してもよい。または、ｇＮＢ２００－１，２００－２は、マルチセルによるＰＵＲをサポートしている旨を示す情報を、ＳＩＢを用いて報知してもよい。

また、上述した例において、セル＃１とセル＃２とが隣接する場合、ｇＮＢ２００－１は、隣接するセル＃２において適用されるＴＡ（Ｔｉｍｉｎｇ Ａｄｖａｎｃｅ）値を報知してもよい。ＵＥ１００は、例えば、セル＃２においてｇＮＢ２００－２（又はｇＮＢ２００－１）とアクセスする場合、このようなＴＡ値を用いて、タイミングを補正して、ステップＳ３０６において、ＰＵＲ送信を行ってもよい。或いは、ｇＮＢ２００－１は、セル＃２においても、ＵＥ１００がセル＃１で適用しているＴＡ値をそのまま適用する旨、又は、ＴＡ＝０（又は許容可能なＴＡ値）を適用する旨に関する情報を報知してもよい。

上述した例は、図１２（Ｂ）を例にした動作例であるが、例えば、図１２（Ａ）に示すように、１つのｇＮＢ２００に２つのセルが存在する場合でも適用可能である。また、上述した例は、１つのｇＮＢ２００に３つ以上のセルが存在する場合でも適用可能である。さらに、上述した例は、各ｇＮＢ２００－１，２００－２に各々複数のセルが存在する場合でも適用可能である。

（実施例３）
次に実施例３について説明する。実施例３は、キャリアアグリゲーション（以下、「ＣＡ」という場合がある。）、デュアルコネクティビティ（以下、「ＤＣ」という場合がある）、及びＰＤＣＰデュプリケーション（ｄｕｐｌｉｃａｔｉｏｎ）のうち少なくとも１つを利用して、ＳＤＴ送信が行われる例である。

５Ｇでは、超高速（ＥｅＭＢＢ（Ｅｎｈａｎｃｅｄ Ｍｏｂｉｌｅ Ｂｒｏａｄ Ｂａｎｄ））、多数同時接続（ｍＭＴＣ（Ｍａｓｓｉｖｅ Ｍａｃｈｉｎｅ Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ））、低遅延及び高信頼性（ＵＲＬＬＣ（Ｕｌｔｒａ－Ｒｅｌｉａｂｌｅ ａｎｄ Ｌｏｗ Ｌａｔｅｎｃｙ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ））など、様々なユースケースが想定されている。他方、ＳＤＴは、例えば、所定サイズ以外のデータ送信を行うものであって、各種センサを用いたＩｏＴ分野でのユースケースが想定される。しかし、ＳＤＴであっても、ＣＡ、ＤＣ、又はＰＤＣＰデュプリケーションを利用することで、低遅延及び高信頼性の要求など、５Ｇで想定される様々なユースケースの要件に合致させることも可能である。

図１４（Ａ）と図１４（Ｂ）はＣＡの例を表す図である。ＣＡは、例えば、複数の周波数帯域を用いた無線通信のことである。

図１４（Ａ）の例は、ＵＥ１００は、ＣＣ（Ｃｏｍｐｏｎｅｎｔ Ｃａｒｒｉｅｒ）＃１とＣＣ＃２とを用いて、１つのｇＮＢ２００に対して、データ送信を行っている例を表している。ＣＣごとにセルが構成されてもよい。この場合、ＵＥ１００はセル＃１においてＣＣ＃１、セル＃２においてＣＣ＃２を用いて、ｇＮＢ２００と無線通信を行うことになる。

図１４（Ｂ）は、ｇＮＢ２００－１がＰＣｅｌｌ（Ｐｒｉｍａｒｙ Ｃｅｌｌ）を有し、ｇＮＢ２００－２がＳＣｅｌｌ（Ｓｅｃｏｎｄａｒｙ Ｃｅｌｌ）を有している例である。この例では、ＵＥ１００は、ＰｃｅｌｌにおいてＣＣ＃１を利用してｇＮＢ２００－１と、ＳＣｅｌｌにおいてＣＣ＃２を利用してｇＮＢ２００－２と無線通信を行っている例を表す。

図１４（Ａ）と図１４（Ｂ）のいずれの場合でも、本実施例３では、ＵＥ１００はＳＤＴによるデータ送信が可能である。詳細は後述する。

図１５（Ａ）はＤＣの例を表す図である。例えば、ＵＥ１００が２つのｇＮＢ２００－１，２００－２と同時に無線通信を行うことがＤＣである。ｇＮＢ２００－１は、ＵＥ１００とネットワークとの通信の接続を維持するＭＮ（Ｍａｓｔｅｒ Ｎｏｄｅ）、ｇＮＢ２００－２は、さらにＵＥ１００に対して無線リソースを提供するＳＮ（Ｓｅｃｏｎｄａｒｙ Ｎｏｄｅ）であってもよい。この場合、ＭｅＮＢ（ｇＮＢ２００－１）のサービングセル（セル＃１）を含むグループがマスターセルグループ（ＭＣＧ）、ＳｅＮＢ（ｇＮＢ２００－２）のサービングセル（セル＃２）を含むグループがセカンダリセルグループ（ＳＣＧ）となる。なお、図１５（Ａ）の例ではｇＮＢは２つであるが、３つ以上あってもよい。

図１５（Ｂ）はＰＤＣＰデュプリケーションの例を表す図である。ＲＲＣによってＰＤＣＰデュプリケーション用の無線ベアラが設定されると、複製されたＰＤＣＰ ＰＤＵをハンドルするために少なくとも１つのセカンダリＲＬＣエンティティが無線ベアラに追加される。プライマリＲＬＣエンティティに対応する論理チャネルがプライマリ論理チャネル（Ｐｒｉｍａｒｙ ＬＣＨ）、セカンダリＲＬＣエンティティに対応する論理チャネルがセカンダリ論理チャネル（Ｓｅｃｏｎｄａｒｙ ＬＣＨ）となる。ＰＤＣＰでの複製によって、同一のＰＤＣＰ ＰＤＵが複数回送信されることで、その信頼性が向上する。セカンダリ論理チャネルは、ＭＡＣ ＣＥ（ＭＡＣ Ｃｏｎｔｒｏｌ Ｅｌｅｍｅｎｔ）によって、アクティブにさせたり、非アクティブにさせることが可能で、これにより、ＰＤＣＰの複製を行ったり、複製をしなかったりすることが可能となる。図１５（Ｂ）の例では、ＵＥ１００は、同一のＰＤＣＰ ＰＤＵ＃１を２つのｇＮＢ２００－１，２００－２へ送信している例を表している。

図１６は、本実施例３の動作例を表す図である。図１６に示す例は、ｇＮＢ２００－１がセル＃１、ｇＮＢ２００－２がセル＃２を有する例である。また、ＵＥ１００が、ＣＡ、ＤＣ、及びＰＤＣＰデュプリケーションのうち少なくとも１つを用いて、ＳＤＴ送信を行う例である。

図１６に示すように、ステップＳ４００において、ＵＥ１００は、ｇＮＢ２００－１とＲＲＣコネクティッド状態にある。ステップＳ４０１において、ｇＮＢ２００－１は、ＲＲＣ接続解放（ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｌｅａｓｅ）メッセージをＵＥ１００へ送信する。このとき、ｇＮＢ２００－１は、ＳＤＴ送信に必要な設定情報（以下、「ＳＤＴ設定情報」という場合がある。）を含むＲＲＣ接続解放メッセージを送信する。ただし、ｇＮＢ２００－１は、ＳＤＴ設定情報を他のメッセージに含めて送信してもよい。ＳＤＴ設定情報としては、例えば、以下のような情報がある。

すなわち、ＳＤＴ設定情報には、セル毎のＰＵＲ設定情報が含まれてもよい。具体的には、セル毎に、ＰＵＲ送信で用いる無線リソース、ＰＵＲ送信の周期及び／又は時間、各ＰＵＲの識別情報であるＰＵＲ－ＲＮＴＩ、ＰＵＲ送信を行うか否かの判断に用いるＲＳＲＰ閾値などが含まれてもよい。この場合、ＰＵＲ設定情報は、セル毎にリスト形状となっていてもよい。例えば、セル＃１における無線リソース等と、セル＃２における無線リソース等がリスト形状となっている場合である。

また、ＳＤＴ設定情報には、セル毎のＥＤＴ設定情報が含まれてもよい。具体的には、セル毎に、ＲＯＨＣ設定又はＮＣＣ値が含まれてもよい。この場合も、セル毎にリスト形状となっていてもよい。

さらに、ＳＤＴ設定情報には、セルと紐づけられた設定情報が含まれてもよい。具体的には、ＵＥ１００においてＣＡが行われる場合、どのセルを用いて行われるのか、又は、ＤＣが行われる場合、どのセルを用いて行われるのかなどである。用いられるセルは、図１４（Ｂ）又は図１５（Ａ）の場合、２つのセルとなるが、３つ以上であってもよい。

さらに、ＳＤＴ設定情報には、対応するベアラＩＤ（又は論理チャネルＩＤ（ＬＣＩＤ））が含まれてもよい。例えば、ＰＤＣＰデュプリケーションでは、プライマリ論理チャネルとセカンダリ論理チャネルの２つのチャネル（又は２つのベアラ）が設定されるが、そのように設定された各論理チャネルのＩＤ（又は各ベアラのＩＤ）がＳＤＴ設定情報に含まれてもよい。

さらに、ＳＤＴ設定情報には、ＰＤＣＰデュプリケーションを行うか否かの設定情報が含まれてもよい。この場合、既に、ＰＤＣＰデュプリケーション設定に利用されるベアラ（論理チャネル）があれば、この設定を参照してもよい。すなわち、ＰＤＣＰデュプリケーションに利用されるベアラＩＤ又は論理チャネルＩＤを参照するようにしてもよく、その旨がＳＤＴ設定情報に含まれてもよい。

さらに、ＳＤＴ設定情報には、実施例２で説明したＰＵＲエリアに関する情報が含まれてもよい。例えば、ＰＵＲエリアに複数のセル（図１４（Ａ）から図１５（Ｂ）における複数のセル）が含まれる場合、ＵＥ１００は、当該複数のセルにおいて、同一のＰＵＲ設定を用い、ＣＡ、ＤＣ、及びＰＤＣＰデュプリケーションのうち少なくともいずれか１つを利用して、ＰＵＲ送信を行うことも可能である。

さらに、ｇＮＢ２００－１は、実施例１で説明したプレファレンス情報に基づいて、ＳＤＴ設定情報を生成し、ＵＥ１００へ送信してもよい。

以上のようなＳＤＴ設定情報の生成は、制御部２３０で行われ、送信部２１０から送信されてもよい。

ステップＳ４０２において、ＵＥ１００は、ＲＲＣインアクティブ状態へ遷移する。

ステップＳ４０３とステップＳ４０４において、ＵＥ１００は、複数セルを用いたＳＤＴを実行する。なお、図１６において、ステップＳ４０３とステップＳ４０４は同じタイミングで行われてよい。また、ステップＳ４０３とステップＳ４０４は、同じデータが送信されてもよいし、異なるデータが送信されてもよい。同じデータが送信される場合は、ＰＤＣＰデュプリケーションが用いられるが、ＰＤＣＰデュプリケーションとＣＡ又はＤＣとが組み合わされてもよい。異なるデータが送信される場合は、ＣＡ又はＤＣであってもよいし、ＣＡとＤＣの組み合わされてもよい。

ステップＳ４０３においては、ＵＥ１００は、データ以外にも、例えば、以下のような情報をｇＮＢ２００－１へ送信してもよい。

すなわち、ＵＥ１００は、セル＃１（ＭＣＧ又はＰＣｅｌｌ）において、複数セルを用いていることを示す情報を送信してもよい。これにより、例えば、ＣＡやＤＣにおいて異なるデータを受信したｇＮＢ２００において、このような情報を用いて、データの合成に利用することができる。

複数セルを用いていることを示す情報としては、例えば、使用しているセルのＩＤ、ベアラＩＤ、論理チャネルＩＤ（ＬＣＩＤ）、上記ＳＤＴ設定情報のエントリ番号などであってもよい。この場合、ＵＥ１００は、複数セルを用いていることを示す情報を、データ＃１に含めて送信してもよいし、別途、シグナリング（制御信号）に含めて送信してもよい。或いは、ＵＥ１００は、ＲＲＣを利用して送信してもよいし、ＭＡＣ ＣＥを利用して送信してもよい。

また、ＵＥ１００は、ＰＤＣＰデュプリケーションを行っているか否かの情報を送信してもよい。

なお、図１６の例では、ＵＥ１００は、ＲＲＣインアクティブ状態へ遷移後、とくに判断することなく、ステップＳ４０３とＳ４０４において、ＳＤＴ送信を行っている例を表している。例えば、ＵＥ１００は、特定の判断を行って、ＳＤＴ送信を行うか否かを判断してもよい。

例えば、ＵＥ１００は、送信データ量、サービス種別（ｄｅｌａｙ ｓｅｎｓｉｔｉｖｅ等）、ＵＥ１００とｇＮＢ２００－１（又はｇＮＢ２００－２）との間の無線状況などに基づいて、複数セル（図１５（Ａ）の例ではセル＃１とセル＃２）を用いたＳＤＴを実行するか、複数セル内における単一セル（図１５（Ａ）の例ではセル＃１）を用いたＳＤＴを実行するかを判断してもよい。このような判断のために、ＵＥ１００は、ｇＮＢ２００－１から送信された閾値を用いてもよい。

ＵＥ１００におけるこのようなＳＤＴ送信の実行制御やｇＮＢ２００－１へ送信する情報の生成は、例えば、制御部１３０で行われてもよく、そのような制御に従って、送信部１２０からデータや各種情報などが送信されてもよい。

ステップＳ４０５において、ｇＮＢ２００－１は、ＵＥ１００から送信されたデータ（又はシグナリング）の受信に成功した場合、応答（ＡＣＫ）信号（又はメッセージ）をＵＥ１００へ送信する。また、ステップＳ４０６において、ｇＮＢ２００－２も、データ（又はシグナリング）の受信に成功した場合、応答（ＡＣＫ）信号を送信する。いずれも場合も、ｇＮＢ２００－１，２００－２は、受信に成功しなかった場合、応答（ＮＡＣＫ）信号（又はメッセージ）を送信してもよい。

なお、ＵＥ１００は、ＰＤＣＰデュプリケーションを行った場合、複数のセル（セル＃１，＃２）のうち、少なくとも１つのセル（を有するｇＮＢ２００－１（又は２００－２））から応答（ＡＣＫ）信号を受信した場合、対応するデータ（又はシグナリング）の送信に成功したと判定する。他方、ＵＥ１００は、いずれのセル（又はｇＮＢ２００－１，２００－２）からも応答（ＡＣＫ）を受信しなかった場合、データ送信に失敗したと判定する。ＵＥ１００は、このように判定した場合、再度、ＳＤＴを実施する、又はＲＲＣ接続再開要求メッセージを送信してＲＲＣコネクティッド状態へ遷移してデータの再送信を試みることになる。

（実施例４）
次に、実施例４について説明する。実施例４は、ＳＤＴによる送信に失敗したＵＥ１００が、失敗したことを示すＳＤＴ Ｆａｉｌｕｒｅをネットワークに報告する例である。

例えば、ＥＤＴ又はＰＵＲを問わず、ＲＲＣ接続再開メッセージの送信によって、ＲＲＣコネクティッド状態へ遷移した場合を考える。この場合、ＳＤＴ送信のプロシージャに失敗して、その後、ＵＥ１００がＲＲＣ接続再開メッセージを送信したのか、或いは、ＳＤＴ送信のプロシージャを行うことなくＵＥ１００がＲＲＣ接続再開メッセージを送信したのか、ネットワーク側はわからない場合がある。

このように、ネットワーク側からみて、状況がわからない場合、情報を収集及び分析し、自律的にネットワークを最適化するＳＯＮ（Ｓｅｌｆ Ｏｒｇａｎｉｚｉｎｇ Ｎｅｔｗｏｒｋｓ）を実現することが困難な場合がある。

そこで、本実施例４では、ＵＥ１００がＳＤＴ Ｆａｉｌｕｒｅをネットワーク側へ報告するようにしている。これにより、例えば、ネットワーク側は、ＵＥ１００においてＳＤＴ送信が失敗したことを把握することができ、そのような情報を収集等することで、ＳＯＮの実現を図ることが可能となる。

図１７（Ａ）と図１７（Ｂ）は、ＥＤＴの場合においてプロシージャが失敗するパターンの例を表している。図１７（Ａ）と図１７（Ｂ）は、ともに、ＵＥ１００がＲＲＣインアクティブ状態にある。また、ランダムアクセスプロシージャが４－ｓｔｅｐの場合と２－ｓｔｅｐの場合が含まれる。なお、ＳＤＴ送信において行われる一連のプロシージャ（例えば図８（Ａ）又は図８（Ｂ））のことを、以下では、「ＳＤＴプロシージャ」という場合がある。

図１７（Ａ）に示すように、４－ｓｔｅｐの場合、ステップＳ５００において、ＵＥ１００はＭｓｇ１をｇＮＢ２００へ送信し、ステップＳ５０１において、ｇＮＢ２００は、ｆａｌｌ ｂａｃｋ情報を含むＭｓｇ２を送信する。ｆａｌｌ ｂａｃｋ情報は、例えば、ランダムアクセスプロシージャを最初からやり直すことを指示する情報である。ＵＥ１００は、ｆａｌｌ ｂａｃｋ情報を受信した場合、ステップＳ５０２において、ＳＤＴプロシージャが失敗したことを確認する。また、ステップＳ５０１において、ＵＥ１００は、Ｍｓｇ２を受信できなかった場合も、ステップＳ５０２でＳＤＴプロシージャの失敗を確認することができる。

また、図１７（Ａ）に示すように、２－ｓｔｅｐの場合、ステップＳ５００において、ＵＥ１００がＭｓｇＡを送信し、ステップＳ５０１において、ｇＮＢ２００が、ｆａｌｌ ｂａｃｋ情報を含むＭｓｇＢを送信する。この場合も、ステップＳ５０２において、ＵＥ１００は、ＳＤＴプロシージャの失敗を確認する。また、ステップＳ５０１において、ＵＥ１００が、ＭｓｇＢを受信できなかった場合も、ステップＳ５０２において、ＳＤＴプロシージャの失敗を確認する。

図１７（Ｂ）は、Ｍｓｇ１とＭｓｇ２（ステップＳ５１０とステップＳ５１１）の送信及び受信は成功し、Ｍｓｇ３において送信又は受信に失敗した場合の例である。すなわち、４－ｓｔｅｐの場合、ステップＳ５１２において、ＵＥ１００は、Ｍｓｇ３とデータとを送信するが、ｇＮＢ２００からＭｓｇ４を受信できなかった場合、ステップＳ５１３において、ＳＤＴプロシージャの失敗を確認する。２－ｓｔｅｐの場合も、ステップＳ５１２において、ＵＥ１００は、ＭｓｇＡとデータとを送信するが、ＭｓｇＢを受信できなかった場合、ステップＳ５１３において、ＳＤＴプロシージャの失敗を確認する。

一方、ＰＵＲにおけるＳＤＴプロシージャの失敗は、例えば、ＲＲＣインアクティブ状態にあるＵＥ１００が、ＰＵＲリソースを用いて、ｇＮＢ２００へデータを送信したものの、レスポンス（例えば、ＲＲＣ接続解放メッセージ）を受信しなかった場合である。

このように、本実施例４においては、ＵＥ１００は、ＳＤＴプロシージャに失敗した場合、失敗に関する情報を記録（又は保存）するようにしている。

図１８は、本実施例４における動作例を表す図である。ステップＳ５０２（図１７（Ａ））又はステップＳ５１３（図１７（Ｂ））で、ＵＥ１００は、ＳＤＴプロシージャ失敗を確認すると、ステップＳ５２０において、失敗した情報を記録する。例えば、制御部１３０は、失敗に関する情報を生成し、その情報を制御部１３０内のメモリに記録する。失敗に関する情報としては、例えば、以下がある。

すなわち、失敗に関する情報としては、通常のＭＤＴ（Ｍｉｎｉｍｉｚａｔｉｏｎ ｏｆ Ｄｒｉｖｅ Ｔｅｓｔｓ）に含まれる情報であってもよい。ＭＤＴヘッダに含まれる情報としては、タイムスタンプ、緯度経度高度、無線測定結果などがある。

また、失敗に関する情報としては、実行したプロシージャの種類であってもよい。実行したプロシージャの種類としては、例えば、ＥＤＴが行われたのか又はＰＵＲが行われたのか、或いは、４－ｓｔｅｐ ＲＡＣＨが行われたのか又は２－ｓｔｅｐ－ＲＡＣＨが行われたのか、などであってもよい。なお、プロシージャの種類として、４－ｓｔｅｐ ＲＡＣＨ又は２－ｓｔｅｐ ＲＡＣＨが示される場合、ＥＤＴ実施の有無に限らず、ＥＤＴではない通常のＲＡＣＨの場合でも適用可能である。この場合、既存のＲＡＣＨ Ｆａｉｌｕｒｅ ｒｅｐｏｒｔに対して、２－ｓｔｅｐであるか否かを区別することが可能である。

さらに、失敗に関する情報として、選択したリソースの情報であってもよい。このような情報としては、例えば、時間リソース、周波数リソース、ＰＲＢ（Ｐｈｙｓｉｃａｌ Ｒｅｓｏｕｒｃｅ Ｂｌｏｃｋ）、又はＢＷＰがある。

さらに、失敗に関する情報として、失敗の区別情報であってもよい。失敗の区別情報は、例えば、どのレスポンスが返信されなかったのかを示す情報である。図１７（Ａ）の例では、Ｍｓｇ２又はＭｓｇＢが返信されなかったので、この場合は、その情報の例として、「Ｍｓｇ２」または「ＭｓｇＢ」となる。また、失敗の区別情報には、失敗した特定の理由（又は特別な失敗の理由）が含まれてもよい。例えば、ＥＤＴやＰＵＲにおいて、セル再選択（ｃｅｌｌ ｒｅｓｅｌｅｃｔｉｏｎ）を行った、などである。

さらに、失敗に関する情報として、実行したＳＦＮ（Ｓｙｓｔｅｍ Ｆｒａｍｅ Ｎｕｍｂｅｒ）及び／又はサブフレーム情報であってもよい。すなわち、データ送信に失敗したとき、どのＳＦＮ又はサブフレームで失敗したのか、又は失敗したデータ送信に用いたＳＦＮ又はサブフレーム情報がこの情報により表されている。

さらに、失敗に関する情報として、失敗した回数、又、リトライカウント識別子であってもよい。例えば、失敗した回数には、同一データ送信に係るリトライ回数が含まれてもよい。

さらに、失敗に関する情報として、失敗したデータのデータサイズ情報であってもよい。さらに、失敗に関する情報として、データ発生からデータ送信完了までの遅延時間の情報であってもよい。

図１８に戻り、ステップＳ５２１において、ＵＥ１００は、失敗に関する情報をｇＮＢ２００へ送信する。ＵＥ１００は、図１８に示すように、Ｍｓｇ５（ＲＲＣ接続セットアップ完了（ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｓｅｔｕｐ Ｃｏｍｐｌｅｔｅ）メッセージ又はＲＲＣ接続再開完了（ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｓｕｍｅ Ｃｏｍｐｌｅｔｅ）メッセージ）に含めて送信してもよい。又は、ＵＥ１００は、ログが存在する旨を示す情報を含むＭｓｇ５をｇＮＢ２００へ送信し、その後のｇＮＢ２００からのログ取得要求に対して、失敗に関する情報をｇＮＢ２００へ送信してもよい。このようなメッセージ及び情報の生成は、例えば、制御部１３０で行われ、送信部１２０を介して送信される。

（その他の実施形態）
ＵＥ１００又はｇＮＢ２００が行う各処理をコンピュータに実行させるプログラムが提供されてもよい。プログラムは、コンピュータ読取り可能媒体に記録されていてもよい。コンピュータ読取り可能媒体を用いれば、コンピュータにプログラムをインストールすることが可能である。ここで、プログラムが記録されたコンピュータ読取り可能媒体は、非一過性の記録媒体であってもよい。非一過性の記録媒体は、特に限定されるものではないが、例えば、ＣＤ－ＲＯＭやＤＶＤ－ＲＯＭ等の記録媒体であってもよい。

また、ＵＥ１００又はｇＮＢ２００が行う各処理を実行する回路を集積化し、ＵＥ１００又はｇＮＢ２００の少なくとも一部を半導体集積回路（チップセット、ＳｏＣ）として構成してもよい。

以上、図面を参照して一実施形態について詳しく説明したが、具体的な構成は上述のものに限られることはなく、要旨を逸脱しない範囲内において様々な設計変更等をすることが可能である。また、矛盾しない範囲で、各実施例の全部又は一部を組み合わせることも可能である。

本願は、日本国特許出願第２０２０－１３３８５９号（２０２０年８月６日出願）の優先権を主張し、その内容の全てが本願明細書に組み込まれている。

Claims (5)

1. ユーザ装置によって実行される通信制御方法であって、
   ＲＲＣインアクティブ状態にある前記ユーザ装置がランダムアクセスプロシージャのメッセージを用いてデータを基地局に送信する第１データ送信と、前記ＲＲＣインアクティブ状態にある前記ユーザ装置が予め設定された無線リソースを用いてデータを前記基地局に送信する第２データ送信とのいずれかを実行することを含み、
   前記実行することは、
   前記第１データ送信のための第１設定情報と、前記第２データ送信のための第２設定情報との双方を前記基地局から前記ユーザ装置に設定された場合、前記第１データ送信を実行することに応じて、前記第２設定情報を破棄することと、を含む
   通信制御方法。
2. ユーザ装置であって、
   ＲＲＣインアクティブ状態にある前記ユーザ装置がランダムアクセスプロシージャのメッセージを用いてデータを基地局に送信する第１データ送信と、前記ＲＲＣインアクティブ状態にある前記ユーザ装置が予め設定された無線リソースを用いてデータを前記基地局に送信する第２データ送信とのいずれかを実行する制御部を備え、
   前記制御部は、前記第１データ送信のための第１設定情報と、前記第２データ送信のための第２設定情報との双方を前記基地局から前記ユーザ装置に設定された場合、前記第１データ送信を実行することに応じて、前記第２設定情報を破棄する
   ユーザ装置。
3. ユーザ装置を制御するプロセッサであって、
   ＲＲＣインアクティブ状態にある前記ユーザ装置がランダムアクセスプロシージャのメッセージを用いてデータを基地局に送信する第１データ送信と、前記ＲＲＣインアクティブ状態にある前記ユーザ装置が予め設定された無線リソースを用いてデータを前記基地局に送信する第２データ送信とのいずれかを実行する処理を行い、
   前記実行する処理は、前記第１データ送信のための第１設定情報と、前記第２データ送信のための第２設定情報との双方を前記基地局から前記ユーザ装置に設定された場合、前記第１データ送信を実行することに応じて、前記第２設定情報を破棄する処理を含む
   プロセッサ。
4. ユーザ装置を制御するためのプログラムであって、
   ＲＲＣインアクティブ状態にある前記ユーザ装置がランダムアクセスプロシージャのメッセージを用いてデータを基地局に送信する第１データ送信と、前記ＲＲＣインアクティブ状態にある前記ユーザ装置が予め設定された無線リソースを用いてデータを前記基地局に送信する第２データ送信とのいずれかを実行する処理を、前記ユーザ装置に実行させ、
   前記実行する処理は、前記第１データ送信のための第１設定情報と、前記第２データ送信のための第２設定情報との双方を前記基地局から前記ユーザ装置に設定された場合、前記第１データ送信を実行することに応じて、前記第２設定情報を破棄する処理を含む
   プログラム。
5. 請求項３に記載のユーザ装置を含む移動通信システム。