JP7032429B2 - セルラ通信システム - Google Patents

Description

本開示は、セルラ通信システムに関する。

近年、ドローン等の無人航空機（ＵＡＶ：Ｕｎｍａｎｎｅｄ Ａｅｒｉａｌ Ｖｅｈｉｃｌｅ）が実用化されている。無人航空機をセルラ通信に対応可能とすることにより、無人航空機の遠隔監視・制御等を実現するための研究開発が行われている。航空機向け又は飛行中のユーザ装置は航空ユーザ装置（Ａｅｒｉａｌ Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）と称されることがある。

一実施形態に係るセルラ通信システムは、セルラ通信ネットワークとの無線接続を確立し、前記無線接続を用いてセルラ通信を行うユーザ装置を有する。前記ユーザ装置は、前記セルラ通信ネットワークとの接続障害を検知した場合に、前記無線接続を再確立することを少なくとも要求する要求メッセージを前記セルラ通信ネットワークに送信する。前記セルラ通信ネットワークは、前記要求メッセージを受信する基地局を含む。前記基地局は、前記要求メッセージを送信した前記ユーザ装置に対応するＵＥコンテキストを前記基地局が利用可能でない場合であっても、前記要求メッセージを拒絶する拒絶メッセージを前記ユーザ装置に送信することなく、新たな無線接続を確立することを示す応答メッセージを前記ユーザ装置に送信する。

一実施形態に係るセルラ通信システムは、セルラ通信ネットワークとの無線接続を確立し、前記無線接続を用いてセルラ通信を行うユーザ装置を有する。前記ユーザ装置は、前記セルラ通信ネットワークの第１のセルとの接続障害を検知した場合に、前記ユーザ装置に関する情報であって前記無線接続を再確立するために必要なコンテキスト情報を利用可能な第２のセルを特定する制御部と、前記制御部によって特定された前記第２のセルに対して、前記無線接続を再確立することを要求する再確立要求メッセージを送信する送信部と、を備える。

一実施形態に係るセルラ通信システムは、セルラ通信ネットワークとの無線接続を確立し、前記無線接続を用いてセルラ通信を行うユーザ装置を有する。前記ユーザ装置は、前記セルラ通信ネットワークのセルに対して、前記無線接続を再確立又は復旧することを要求する第１の要求情報と新たに無線接続を確立することを要求する第２の要求情報とを含むメッセージを送信する送信部を備える。

一実施形態に係るセルラ通信システムは、ソース基地局からターゲット基地局に対してユーザ装置の条件付きハンドオーバを行うシステムである。前記ソース基地局は、前記ターゲット基地局に対して、前記ユーザ装置のコンテキスト情報を含むハンドオーバ要求を予め送信し、かつ、前記ユーザ装置に対してハンドオーバ指令を予め送信する。前記ターゲット基地局は、前記ハンドオーバ要求の受信に応じて、ハンドオーバ要求確認応答を前記ソース基地局に送信する。前記ユーザ装置は、前記ソース基地局から前記ハンドオーバ指令を受信した後、ハンドオーバ条件が満たされるまでハンドオーバを保留し、前記ハンドオーバ条件が満たされたときに前記ハンドオーバを実行する。前記ハンドオーバ要求、前記ハンドオーバ要求確認応答、及び前記ハンドオーバ指令の少なくとも１つには、前記ターゲット基地局が前記コンテキスト情報を保持すべき保持時間に対応するタイマ値が含まれる。

一実施形態に係るセルラ通信システムは、ソース基地局からターゲット基地局に対してユーザ装置の条件付きハンドオーバを行うセルラ通信システムである。前記ソース基地局は、複数のターゲット基地局に対して、前記ユーザ装置のコンテキスト情報を含むハンドオーバ要求を予め送信し、かつ、前記ユーザ装置に対してハンドオーバ指令を予め送信する。前記ユーザ装置は、前記ソース基地局から前記ハンドオーバ指令を受信した後、ハンドオーバ条件が満たされるまでハンドオーバを保留し、前記ハンドオーバ条件が満たされたときに前記複数のターゲット基地局のうち１つのターゲット基地局への前記ハンドオーバを実行する。前記１つのターゲット基地局は、前記ハンドオーバに応じて、前記ソース基地局に対して、前記ユーザ装置のコンテキスト情報を解放可能であることを示す第１のコンテキスト解放通知を送信する。前記ソース基地局は、前記第１のコンテキスト解放通知の受信に応じて、前記複数のターゲット基地局のうち前記１つのターゲット基地局以外のターゲット基地局に対して、前記ユーザ装置のコンテキスト情報を解放可能であることを示す第２のコンテキスト解放通知を送信する。

一実施形態に係るセルラ通信システムは、ソース基地局からターゲット基地局に対してユーザ装置の条件付きハンドオーバを行うセルラ通信システムである。前記ソース基地局は、複数のターゲット基地局に対して、前記ユーザ装置のコンテキスト情報と前記複数のターゲット基地局に関する基地局リストとを含むハンドオーバ要求を予め送信し、かつ、前記ユーザ装置に対してハンドオーバ指令を予め送信する。前記ユーザ装置は、前記ソース基地局から前記ハンドオーバ指令を受信した後、ハンドオーバ条件が満たされるまでハンドオーバを保留し、前記ハンドオーバ条件が満たされたときに前記複数のターゲット基地局のうち１つのターゲット基地局への前記ハンドオーバを実行する。前記１つのターゲット基地局は、前記ハンドオーバに応じて、前記ソース基地局と、前記基地局リストに対応する他のターゲット基地局とに対して、前記ユーザ装置のコンテキスト情報を解放可能であることを示すコンテキスト解放通知を送信する。

実施形態に係るＬＴＥシステム（セルラ通信システム）の構成を示す図である。 実施形態に係るＵＥ（ユーザ装置）の構成を示す図である。 実施形態に係るｅＮＢ（基地局）の構成を示す図である。 実施形態に係るＬＴＥシステムにおける無線インターフェイスのプロトコルスタックを示す図である。 実施形態に係るＬＴＥシステムの無線フレームの構成を示す図である。 実施形態に係るセルラ通信システムの適用シナリオの一例を示す図である。 第１実施形態におけるＵＥの動作の一例を示す図である。 第１実施形態の変更例における動作の一例を示す図である。 第２実施形態に係るメッセージ（ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｄｕａｌ Ｒｅｑｕｅｓｔ）の一例を示す図である。 第２実施形態における動作の一例を示す図である。 第３実施形態に係る動作例１を示す図である。 第３実施形態に係る動作例２を示す図である。 第３実施形態の変更例１を示す図である。 第３実施形態の変更例２を示す図である。 第４実施形態における動作の一例を示す図である。

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

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

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

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

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

図２は、ＵＥ１００（ユーザ装置）の構成を示す図である。ＵＥ１００は、受信部１１０、送信部１２０、及び制御部１３０を備える。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（適用シナリオ）
実施形態において、無人航空機向け又は飛行中のＵＥ１００がセルラ通信ネットワーク（Ｅ－ＵＴＲＡＮ１０）とのＲＲＣ接続を確立し、ＲＲＣ接続を用いてセルラ通信を行うシナリオを想定する。かかる場合、ＵＥ１００は、Ａｅｒｉａｌ ＵＥ又はＵＡＶ ＵＥと称されることがある。ＵＥ１００が無人航空機に設けられてもよいし、ＵＥ１００自身が無人航空機であってもよい。無人航空機は、図３に示す機能ブロックに加えて、バッテリ、ＧＮＳＳ（Ｇｌｏｂａｌ Ｎａｖｉｇａｔｉｏｎ Ｓａｔｅｌｌｉｔｅ Ｓｙｓｔｅｍ）受信機、及び飛行用機構（例えば、モータ及びプロペラ等）を備える。或いは、ＵＥ１００は、単に高度が高いところに位置するＵＥ（例えば、高層ビルの最上階に居るＵＥなど）であってもよい。

図６は、実施形態に係るセルラ通信システムの適用シナリオの一例を示す図である。

図６に示すように、セルラ通信システム（ＬＴＥシステム）は、複数のｅＮＢ２００ａ～２００ｆを備える。複数のｅＮＢ２００ａ～２００ｆのそれぞれは６角形状の通信エリアを形成する。各通信エリアは、１又は複数のセルによって構成される。隣接する通信エリアを管理する一対のｅＮＢ２００間には、基地局間インターフェイスであるＸ２インターフェイスが設定される。ＵＥ１００は、接続先のセルを介してｅＮＢ２００とのセルラ通信を行う。

現状のセルラ通信ネットワークは、Ａｅｒｉａｌ ＵＥ又はＵＡＶ ＵＥの存在を前提とせずにエリア設計がなされているため、Ａｅｒｉａｌ ＵＥ又はＵＡＶ ＵＥとセルラ通信ネットワークとの間で接続障害が発生しやすい。接続障害とは、無線リンク障害（ＲＬＦ）及びハンドオーバ障害（ＨＯＦ）等をいう。具体的には、通常のセルラ通信ネットワークは、地上（陸上）のＵＥに対してエリアを最適化している為、上空（高度が高い）ＵＥに対しては、エリアが最適化されていない。また、上空（高度が高い）のＵＥはｅＮＢに対して見通し内となり、アンテナゲインは高度が高いほど高くなるといった理由により、ｅＮＢの電波が上空では遠くまで飛びすぎる。

ＲＲＣコネクティッドモードにあるＵＥ１００がサービングセルとの接続障害を検知した場合、ＵＥ１００は、セルサーチによって、新たな接続先の候補となる候補セルを発見し、以下の動作を行う。

第１に、ＵＥ１００は、ＲＲＣ接続を再確立することを要求するＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ Ｒｅｑｕｅｓｔメッセージを候補セルに送信する。ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ Ｒｅｑｕｅｓｔメッセージは、再確立要求メッセージに相当する。この候補セルを管理するｅＮＢ２００は、このＵＥ１００のコンテキスト情報（ＵＥコンテキスト）を利用可能であれば、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ Ｒｅｑｕｅｓｔメッセージに対する肯定応答であるＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ ＲｅｅｓｔａｂｌｉｓｈｍｅｎｔメッセージをＵＥ１００に送信する。ＵＥコンテキストは、ＵＥ１００の識別情報及びＵＥ１００の設定情報等を含む。

一のｅＮＢは、他のｅＮＢからＸ２インターフェイス又はＳ１インターフェイスを介してＵＥコンテキストを取得することが可能である。しかしながら、一のｅＮＢがＵＥコンテキストを取得可能な他のｅＮＢの範囲は限定されると考えられる。以下においては、一のｅＮＢが他のｅＮＢからＸ２インターフェイスを介してＵＥコンテキストを取得する場合を主として想定する。かかる場合、Ｘ２インターフェイスを介して接続されていないｅＮＢ間ではＵＥコンテキストをやり取りすることができない。よって、接続障害発生時のセルを管理するｅＮＢと、セルサーチによって発見された候補セルを管理するｅＮＢとが隣接ｅＮＢの関係にあれば、この候補セルを管理するｅＮＢは、このＵＥ１００のＵＥコンテキストを利用可能である。

ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ ＲｅｅｓｔａｂｌｉｓｈｍｅｎｔメッセージをＵＥ１００が受信する場合、ＵＥ１００は、ＲＲＣアイドルモードに遷移することなくＲＲＣ接続を再確立し、ＲＲＣコネクティッドモードを維持する。一方、ＵＥコンテキストをｅＮＢ２００が利用可能ではない場合、ｅＮＢ２００は、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ Ｒｅｑｕｅｓｔメッセージに対する否定応答（拒絶）であるＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ ＲｅｊｅｃｔメッセージをＵＥ１００に送信する。

第２に、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ Ｒｅｊｅｃｔメッセージを受信したＵＥ１００は、ＲＲＣアイドルモードに遷移し、セルサーチによって候補セルを改めて探索する。

第３に、ＲＲＣアイドルモードに遷移したＵＥ１００は、新たにＲＲＣ接続を確立することを要求するＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｑｕｅｓｔメッセージを候補セルに送信する。ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｑｕｅｓｔメッセージは、接続要求メッセージに相当する。この候補セルを管理するｅＮＢ２００は、ＵＥコンテキストの有無にかかわらず、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｑｕｅｓｔメッセージに対する肯定応答であるＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ ＳｅｔｕｐメッセージをＵＥ１００に送信する。ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ ＳｅｔｕｐメッセージをＵＥ１００が受信する場合、ＵＥ１００は、ＲＲＣアイドルモードからＲＲＣコネクティッドモードに遷移する。また、ｅＮＢ２００は、ＵＥコンテキストを新たに取得（生成）する。

このように、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ Ｒｅｑｕｅｓｔメッセージの送信先のセルがＵＥコンテキストを利用可能であれば、ＵＥ１００は、接続障害が生じてもＲＲＣコネクティッドモードを維持しつつ速やかにセルラ通信を再開することができる。一方、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ Ｒｅｑｕｅｓｔメッセージの送信先のセルがＵＥコンテキストを利用可能ではない場合、ＵＥ１００は、新たな候補セルのサーチ、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｑｕｅｓｔの送信、及びＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｓｅｔｕｐメッセージの受信を行わなければセルラ通信を再開することができないため、セルラ通信の中断時間が長くなる。よって、ＵＥ１００は、ＵＥコンテキストを利用可能なセルに対してＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ Ｒｅｑｕｅｓｔメッセージを送信することが望まれる。

図６に示す例において、ＵＥ１００は、ｅＮＢ２００ａ、ｅＮＢ２００ｃ、及びｅＮＢ２００ｅのそれぞれの通信エリアの境界付近の上空に位置する。ここで、ＵＥ１００がｅＮＢ２００ａとのセルラ通信中にＲＬＦを検知した場合を想定する。かかる場合、ＵＥ１００は、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ ＲｅｑｕｅｓｔメッセージをｅＮＢ２００ｃ又はｅＮＢ２００ｅに送信すれば、ｅＮＢ２００ｃ及びｅＮＢ２００ｅのいずれもｅＮＢ２００ａとの間にＸ２インターフェイスを有しているため、Ｘ２インターフェイスを介してｅＮＢ２００ａからＵＥコンテキストを取得可能である。

しかしながら、ＵＥ１００が上空に位置する場合、各ｅＮＢ２００の送信ビームのサイドローブが上空に飛び交い、遠くのｅＮＢ２００（例えば、ｅＮＢ２００ｄ）からの電波をＵＥ１００が強い強度で受信し得る。このため、ＵＥ１００は、例えば、ｅＮＢ２００ｄのセルを選択してＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ Ｒｅｑｕｅｓｔメッセージを送信し得る。かかる場合、ｅＮＢ２００ｄはｅＮＢ２００ａとの間にＸ２インターフェイスを有していないため、Ｘ２インターフェイスを介してｅＮＢ２００ａからＵＥコンテキストを取得することができない。その結果、ＵＥ１００は、ＲＲＣ接続の再確立に失敗し、ＲＲＣアイドルモードに遷移する。そして、ＵＥ１００は、セルラ通信を再開するためには、新たな候補セルのサーチ、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｑｕｅｓｔの送信、及びＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｓｅｔｕｐメッセージの受信を行わななければならない。

（第１実施形態に係る動作）
上述したように、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ Ｒｅｑｕｅｓｔメッセージが拒絶されることに起因して、セルラ通信の中断時間が長くなるという問題がある。第１実施形態においては、以下の動作によって、かかる問題を解決可能とする。

第１実施形態に係るＵＥ１００は、セルラ通信ネットワークとの無線接続を確立し、ＲＲＣ接続を用いてセルラ通信を行う。ＵＥ１００は、Ａｅｒｉａｌ ＵＥ又はＵＡＶ ＵＥであってもよい。例えば、ＵＥ１００には、自身のカテゴリ又は属性がＡｅｒｉａｌ ＵＥ又はＵＡＶ ＵＥであることを示す情報が事前設定されており、かかる情報を有するＵＥ１００が以下の動作を行ってもよい。或いは、ＵＥ１００は、Ａｅｒｉａｌ ＵＥ又はＵＡＶ ＵＥであるか否かにかかわらず、飛行中であることを示す条件が満たされた場合に以下の動作を行ってもよい。飛行中であることを示す条件は、例えば、ＵＥ１００の高度及び移動速度、並びにそれらの変動量等に応じて定められてもよいし、ＵＥ１００の実行中のアプリケーションの種別（例えば、遠隔監視・制御アプリケーション）に応じて定められてもよい。

ＵＥ１００の制御部１３０は、セルラ通信ネットワークの第１のセルとの接続障害を検知した場合に、ＵＥ１００に関する情報であってＲＲＣ接続を再確立するために必要なコンテキスト情報（ＵＥコンテキスト）を利用可能な第２のセルを特定する。ＵＥ１００の送信部１２０は、制御部１３０によって特定された第２のセルに対して、ＲＲＣ接続を再確立することを要求するＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ Ｒｅｑｕｅｓｔメッセージを送信する。これにより、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ Ｒｅｑｕｅｓｔメッセージが拒絶されることを防止することができるため、セルラ通信の中断時間が長くなるという問題を解決することができる。

第２のセルを特定するために、ＵＥ１００は、自律的に第２のセルを特定する。ＵＥ１００の制御部１３０は、接続障害が検知された第１のセルとＵＥ１００との間の距離を示す第１の値と、ＵＥ１００が利用可能な他のセル（候補セル）とＵＥ１００との間の距離を示す第２の値とを算出する。第１の値及び第２の値としてはパスロスを用いることができる。パスロスは、参照信号の既知の送信電力と、この参照信号の受信電力との間の差に相当する。或いは、ＵＥ１００の制御部１３０は、第１のセルの位置情報を第１のセルから受信し、第２のセルの位置情報を第２のセルから受信し、受信した位置情報とＵＥ１００の位置情報（例えば、ＧＮＳＳ位置情報）とに基づいて第１の値及び第２の値を算出してもよい。位置情報は、経度、緯度、及び高度を含む。そして、ＵＥ１００の制御部１３０は、第１の値と第２の値との差が所定値（閾値）以下である場合に、他のセル（候補セル）を、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ Ｒｅｑｕｅｓｔメッセージの送信先とする第２のセルとして特定する。なお、ＵＥ１００からの距離（パスロス）が同等である２つのセルは隣接関係にあると仮定している。図６の例において、ＵＥ１００は、例えば、ｅＮＢ２００ａのセル（第１のセル）との接続障害を検知すると、ｅＮＢ２００ａのセルとパスロスが同等であるｅＮＢ２００ｃ又はｅＮＢ２００ｅのセルを第２のセルとして特定し、ｅＮＢ２００ｃ又はｅＮＢ２００ｅのセルに対してＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ Ｒｅｑｕｅｓｔメッセージを送信することができる。

但し、ＵＥ１００は、ＵＥコンテキストを利用可能な第２のセルを常に発見できるとは限らない。このため、ＵＥ１００の制御部１３０は、第１のセルとの接続障害を検知し、かつ、ＵＥ１００が利用可能な他のセルが第２のセルではない場合に、当該他のセルに対するＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ Ｒｅｑｕｅｓｔメッセージの送信をスキップすると判断してもよい。ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ Ｒｅｑｕｅｓｔメッセージの送信をスキップする場合、ＵＥ１００の送信部１２０は、当該他のセルに対して、新たにＲＲＣ接続を確立することを要求するＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｑｕｅｓｔメッセージを送信する。これにより、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ Ｒｅｑｕｅｓｔメッセージが拒絶されることが想定される場合に、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ Ｒｅｑｕｅｓｔメッセージに代えて、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｑｕｅｓｔメッセージを送信することができるため、セルラ通信の中断時間が長くなることを回避することができる。

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

図７に示すように、ステップＳ１０１において、ＵＥ１００は、第１のセルとの接続障害を検知する。

ステップＳ１０２において、ＵＥ１００は、セルサーチを行って候補セルを発見する。候補セルは、１つであってもよいし、複数であってもよい。

ステップＳ１０３において、ＵＥ１００は、ＵＥ１００と第１のセルとの間のパスロス１と、ＵＥ１００と候補セルとの間のパスロス２とを算出する。

ステップＳ１０４において、ＵＥ１００は、パスロス１とパスロス２との間の差を閾値と比較する。この閾値は、セルラ通信ネットワークからＵＥ１００に設定されてもよい。例えば、閾値は、第１のセルからＳＩＢによってブロードキャストされたものであってもよい。

パスロス１とパスロス２との間の差が閾値以下である場合（ステップＳ１０４：ＹＥＳ）、ステップＳ１０５において、ＵＥ１００は、パスロス２に対応する候補セルを第２のセルとして特定し、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ Ｒｅｑｕｅｓｔメッセージを送信する。

一方、パスロス１とパスロス２との間の差が閾値を超える場合（ステップＳ１０４：ＮＯ）、ステップＳ１０６において、ＵＥ１００は、他に候補セルがあるか否かを判断する。

他に候補セルがある場合（ステップＳ１０６：ＹＥＳ）、ＵＥ１００は、当該他の候補セルについてパスロス２を算出し（ステップＳ１０３）、ステップＳ１０４の判断を行う。

他に候補セルがない場合（ステップＳ１０６：ＮＯ）、ＵＥ１００は、ＵＥコンテキストを利用可能な第２のセルを発見できなかったことになる。かかる場合、ステップＳ１０７において、ＵＥ１００は、発見された候補セルに対してＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｑｕｅｓｔメッセージを送信する。

［第１実施形態の変更例］
第１実施形態において、第２のセルを管理する第２のｅＮＢが、第１セルを管理する第１のｅＮＢからＵＥコンテキストを取得する処理の詳細について説明しなかった。通常、第２のｅＮＢは、ＵＥ１００からＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ Ｒｅｑｕｅｓｔメッセージを受信すると、このメッセージに基づいて第１のｅＮＢを特定し、特定した第１のｅＮＢに対してＸ２インターフェイス上で通知を行う。第１のｅＮＢは、当該通知に応じて、第２のｅＮＢに対して、Ｘ２インターフェイスでＵＥコンテキストを転送する。かかるプロシージャは、ＵＥコンテキストを取得する時間に起因して、第２のｅＮＢがＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ Ｒｅｑｕｅｓｔメッセージを受信してからＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔメッセージを送信するまでの遅延時間が長くなる。第１実施形態の変更例において、かかる遅延時間を短縮可能とする動作について説明する。

第１実施形態の変更例において、第１のｅＮＢは、接続障害が発生するよりも前において、ＵＥコンテキストを第２のｅＮＢに転送する。すなわち、第１のｅＮＢは、ＵＥコンテキストを予め第２のｅＮＢと共有する。例えば、第１のｅＮＢは、ＵＥコンテキストを取得した際に、自身との間にＸ２インターフェイスを有する他のｅＮＢに当該ＵＥコンテキストを転送する。これにより、第２のｅＮＢは、ＵＥ１００からＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ Ｒｅｑｕｅｓｔメッセージを受信するとすぐにＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔメッセージを送信することができる。

図８は、第１実施形態の変更例における動作の一例を示す図である。

図８に示すように、ステップＳ３０１において、ＵＥ１００は、ｅＮＢ２００ａとＲＲＣ接続を確立する。ステップＳ３０２において、ｅＮＢ２００ａは、ＵＥコンテキストを取得する。ステップＳ３０３及びＳ３０４において、ｅＮＢ２００ａは、ＵＥコンテキストをＸ２インターフェイス上でｅＮＢ２００ｂ及び２００ｃに転送する。

ステップＳ３０５及びＳ３０６において、ｅＮＢ２００ｂ及び２００ｃは、ＵＥコンテキストの取得時にタイマを開始させる。タイマの値は、ｅＮＢ２００ａから指定された値であってもよいし、ＭＭＥから指定された値であってもよいし、ＯＡＭ（Ｏｐｅｒａｔｉｏｎｓ Ａｄｍｉｎｉｓｔｒａｔｉｏｎ ａｎｄ Ｍａｉｎｔｅｎａｎｃｅ）から指定された値であってもよい。ｅＮＢ２００ｂ及び２００ｃは、タイマが動作中は、転送されたＵＥコンテキストを保持する。

ステップＳ３０７において、ＵＥ１００とｅＮＢ２００ａとの間で接続障害が発生し、ＵＥ１００は、第１実施形態に係る動作によってｅＮＢ２００ｂのセルを第２のセルとして特定する。ステップＳ３０８において、ＵＥ１００は、ｅＮＢ２００ｂに対してＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ Ｒｅｑｕｅｓｔメッセージを送信する。ｅＮＢ２００ｂは、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ Ｒｅｑｕｅｓｔメッセージの受信に応じてタイマを停止させる。ステップＳ３０９において、ｅＮＢ２００ｂは、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ ＲｅｅｓｔａｂｌｉｓｈｍｅｎｔメッセージをＵＥ１００に送信する。ステップＳ３０１においてＵＥ１００のＲＲＣ接続が再確立される。

一方、ステップＳ３１１において、ｅＮＢ２００ｃにおけるタイマが満了する。ステップＳ３１２において、ｅＮＢ２００ｃは、保持していたＵＥコンテキストを破棄する。

なお、ｅＮＢ２００ｂは、ＵＥ１００との通信中はＵＥコンテキストを保持する。ｅＮＢ２００ｂは、ＵＥ１００との通信終了に応じて、ＲＲＣ接続を解放させるＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ ＲｅｌｅａｓｅメッセージをＵＥ１００に送信し、保持していたＵＥコンテキストを破棄してもよい。そして、ｅＮＢ２００ｂは、その旨をＸ２インターフェイス上で他のｅＮＢに通知することにより、他のｅＮＢがＵＥコンテキストを破棄可能としてもよい。

第１実施形態の変更例における動作を、第３実施形態における条件付きハンドオーバ（ｃｏｎｄｉｔｉｏｎａｌ ｈａｎｄｏｖｅｒ）と組み合わせてもよい。例えば、ステップＳ３０３及びＳ３０４において送信されるＵＥコンテキストは、ハンドオーバ要求に含まれていてもよい。ｅＮＢ２００ａは、ハンドオーバ要求に対するハンドオーバ要求確認応答を受信した場合に、ステップＳ３０７よりも前に、条件付きハンドオーバのためのハンドオーバ指令をＵＥ１００に送信してもよい。ＵＥ１００は、ＲＬＦを検出（ステップＳ３０７）した場合に、ハンドオーバ指令で指定されたセルを優先して、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔメッセージを送信してもよい。

［第２実施形態］
第２実施形態について、第１実施形態との相違点を主として説明する。第１実施形態においては、ＵＥ１００は、発見された候補セルが第２のセルであるか否かに応じて、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ Ｒｅｑｕｅｓｔメッセージを送信するか又はＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｑｕｅｓｔメッセージを送信するかを選択することにより、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ Ｒｅｑｕｅｓｔメッセージが拒絶されることを回避する一例を説明した。

これに対し、第２実施形態においては、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ Ｒｅｑｕｅｓｔメッセージ及びＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｑｕｅｓｔメッセージの両方の機能を有する新たなメッセージを導入する。このメッセージは、少なくともＲＲＣ接続を再確立することを要求する要求メッセージである。第２実施形態において、ＵＥ１００の送信部１２０は、セルラ通信ネットワークのセルに対して、ＲＲＣ接続を再確立することを要求する第１の要求情報と新たにＲＲＣ接続を確立することを要求する第２の要求情報とを含むメッセージを送信する。

ｅＮＢ２００（セル）は、かかるメッセージの送信を許可するか否かをＳＩＢ（所定のシステム情報）によってＵＥ１００に通知してもよい。ＵＥ１００は、かかるメッセージの送信が許可されている場合に限り、かかるメッセージの送信を当該セルに対して行ってもよい。ＳＩＢは、エアリアルＵＥ向けのＳＩＢであってもよい。ＵＥ１００は、あるセルからエアリアルＵＥ向けのＳＩＢを受信した場合に、当該セルに対してＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｄｕａｌ Ｒｅｑｕｅｓｔメッセージの送信が許可されていると判断してもよい。

図９は、第２実施形態に係るメッセージ（ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｄｕａｌ Ｒｅｑｕｅｓｔ）の一例を示す図である。

図９に示すように、第２実施形態に係るＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｄｕａｌ Ｒｅｑｕｅｓｔメッセージは、情報要素として、ＲＲＣ接続を再確立することを要求する第１の要求情報（ｒｒｃＣｏｎｎｅｃｔｉｏｎＲｅｅｓｔａｂｌｉｓｈｍｅｎｔ－ｒ８）と新たにＲＲＣ接続を確立することを要求する第２の要求情報（ｒｒｃＣｏｎｎｅｃｔｉｏｎＲｅｑｕｅｓｔ－ｒ８）とを含む。第１の要求情報は、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ Ｒｅｑｕｅｓｔメッセージ中の全ての情報要素を含んでもよい。第２の要求情報は、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｑｕｅｓｔメッセージ中の全ての情報要素を含んでもよい。

ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｄｕａｌ Ｒｅｑｕｅｓｔメッセージは、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｄｕａｌ Ｒｅｑｕｅｓｔメッセージを送信する１又は複数の原因を示す情報要素（Ｄｕａｌ Ｒｅｑｕｅｓｔ Ｃａｕｓｅ）をさらに含んでもよい。ＵＥ１００は、かかる原因に基づいてＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｄｕａｌ Ｒｅｑｕｅｓｔメッセージを送信する場合に、かかる原因をＤｕａｌ Ｒｅｑｕｅｓｔ ＣａｕｓｅとしてＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｄｕａｌ Ｒｅｑｕｅｓｔメッセージに含める。例えば、ＵＥ１００は、次の情報要素の中から少なくとも１つを選択してＤｕａｌ Ｒｅｑｕｅｓｔ Ｃａｕｓｅに含める。Ｄｕａｌ Ｒｅｑｕｅｓｔ Ｃａｕｓｅに含める情報要素の数（上限等）はｅＮＢ２００からＵＥ１００に通知されてもよい。ＡｅｒｉａｌＵＥであること（ＡｅｒｉａｌＵＥ）。高度が高いこと（ＨｉｇｈＡｌｔｉｔｕｄｅ）。飛行中であること（ＯｎＦｌｙｉｎｇ）。高速移動中であること（ＨｉｇｈＳｐｅｅｄ）。自律運転中であること（ＡｕｔｏｍｏｕｓＭｏｄｅ）。Ｘ２インターフェイス（ＵＥコンテキスト）を利用可能か不明であること（ＡｖａｉｌａｂｉｌｉｔｙＵｎｋｎｏｗｎ）。通信中断時間を短くすることが必要とされること（ＬｏｗＩｎｔｒｒｕｐｔｉｏｎＴｉｍｅＲｅｑｕｉｒｅｄ）。アプリケーションの要求（ＡｐｐｌｉｃａｔｉｏｎＲｅｑｕｅｓｔ）。通話中であること（ＶｏｉｃｅＩｎＰｒｏｇｒｅｓｓ）。消費電力削減が必要とされること（ＰｏｗｅｒＳａｖｉｎｇＰｒｅｆｅｒｅｎｃｅ）。地理的位置（ＧｅｏＬｏｃａｔｉｏｎ）。移動履歴（ＭｏｂｉｌｉｔｙＨｉｓｔｏｒｙ）。加入者クラス（ＳｕｂｓｃｒｉｐｔｉｏｎＬｅｖｅｌＧｏｌｄ、ＳｕｂｓｃｒｉｐｔｉｏｎＬｅｖｅｌＳｉｌｖｅｒ）。

第２実施形態において、ｅＮＢ２００の受信部２２０は、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｄｕａｌ ＲｅｑｕｅｓｔメッセージをＵＥ１００から受信する。ｅＮＢ２００の制御部２３０は、このＵＥ１００のＵＥコンテキストをｅＮＢ２００が利用可能であるか否かを判断する。かかる判断の基準は、第１実施形態と同様である。ｅＮＢ２００の制御部２３０は、ＵＥコンテキストをｅＮＢ２００が利用可能である場合に、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｄｕａｌ Ｒｅｑｕｅｓｔメッセージに対する応答として、ＲＲＣ接続を再確立することを許可する旨をＵＥ１００に通知する。一方、ｅＮＢ２００の制御部２３０は、ＵＥコンテキストをｅＮＢ２００が利用可能ではない場合には、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｄｕａｌ Ｒｅｑｕｅｓｔメッセージに対する応答として、新たにＲＲＣ接続を確立することを許可する旨をＵＥ１００に通知する。このように、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｄｕａｌ ＲｅｑｕｅｓｔメッセージはｅＮＢ２００によって拒絶されることがない。

図１０は、第２実施形態における動作の一例を示す図である。

図１０に示すように、ステップＳ４０１において、ＵＥ１００は、ｅＮＢ２００ａとＲＲＣ接続を確立する。

ステップＳ４０２において、ＵＥ１００とｅＮＢ２００ａとの間で接続障害が発生し、セルサーチを行ってｅＮＢ２００ｂのセルを候補セルとして発見する。

ステップＳ４０３において、ＵＥ１００は、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｄｕａｌ ＲｅｑｕｅｓｔメッセージをｅＮＢ２００ｂに送信する。

ステップＳ４０４において、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｄｕａｌ Ｒｅｑｕｅｓｔメッセージを受信したｅＮＢ２００ｂは、ＵＥ１００のＵＥコンテキストを利用可能であるか否かを判断する。

ＵＥコンテキストをｅＮＢ２００ｂが利用可能である場合（ステップＳ４０４：ＹＥＳ）、ステップＳ４０５において、ｅＮＢ２００ｂは、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ ＲｅｅｓｔａｂｌｉｓｈｍｅｎｔメッセージをＵＥ１００に送信する。

一方、ＵＥコンテキストをｅＮＢ２００ｂが利用可能ではない場合（ステップＳ４０４：ＮＯ）、ステップＳ４０６において、ｅＮＢ２００ｂは、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ ＳｅｔｕｐメッセージをＵＥ１００に送信する。

ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔメッセージ及びＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｓｅｔｕｐメッセージに代えて、共通化されたメッセージを用いてもよい。共通化されたメッセージは、例えばＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｄｕａｌ Ｒｅｑｕｅｓｔ Ａｃｋｎｏｗｌｅｄｇｅメッセージであってもよい。ｅＮＢ２００は、共通化されたメッセージに、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔメッセージに対応する情報要素及びＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｓｅｔｕｐメッセージに対応する情報要素のいずれか一方を含める。

［第２実施形態の変更例１］
第２実施形態において、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｄｕａｌ Ｒｅｑｕｅｓｔメッセージを送信するＵＥ１００がＲＲＣコネクティッドモードであることを想定していた。第２実施形態の変更例においては、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｄｕａｌ Ｒｅｑｕｅｓｔメッセージを送信するＵＥ１００がＲＲＣアイドルモードであることを想定する。具体的には、かかるＵＥ１００は、ＲＲＣサスペンド状態にある。ＲＲＣサスペンド状態は、ＲＲＣアイドルモードの一状態であって、ＵＥコンテキストがセルラ通信ネットワークに維持される特殊な状態である。

第２実施形態の変更例１に係るＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｄｕａｌ Ｒｅｑｕｅｓｔメッセージは、情報要素として、ＲＲＣ接続を復旧することを要求する第１の要求情報と新たにＲＲＣ接続を確立することを要求する第２の要求情報とを含む。第２の要求情報は、上述した第２実施形態と同様に、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｑｕｅｓｔメッセージ中の全ての情報要素を含んでもよい。

第２実施形態の変更例１において、第１の要求情報は、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｓｕｍｅ Ｒｅｑｕｅｓｔメッセージ中の全ての情報要素を含んでもよい。ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｓｕｍｅ Ｒｅｑｕｅｓｔメッセージは、ＲＲＣサスペンド状態のＵＥ１００がＲＲＣ接続の復旧を要求するためのメッセージである。

［第２実施形態の変更例２］
第２実施形態において特に記載していないが、ＵＥ１００は、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｄｕａｌ Ｒｅｑｕｅｓｔメッセージをランダムアクセスプロシージャ中に送信する。具体的には、図１０に示すステップＳ４０２とＳ４０３との間において、ＵＥ１００からｅＮＢ２００ｂにランダムアクセス信号（ランダムアクセスプリアンブル）を送信し、ｅＮＢ２００ｂは、ランダムアクセス信号の受信に応じてランダムアクセス応答をＵＥ１００に送信する。

ランダムアクセス応答は、上りリンク無線リソースの割り当てを示す上りリンクグラントを含む。そして、図１０に示すＳ４０３において、ＵＥ１００は、上りリンクグラントにより割り当てられた上りリンク無線リソースを用いてＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｄｕａｌ ＲｅｑｕｅｓｔメッセージをｅＮＢ２００ｂに送信する。

ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｄｕａｌ Ｒｅｑｕｅｓｔメッセージは、一般的なＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｑｕｅｓｔメッセージに比べて情報量が多い。よって、ｅＮＢ２００ｂは、上りリンクグラントにより、多くの上りリンク無線リソース（すなわち、大きいデータサイズ）をＵＥ１００に割り当てる必要がある。

第２実施形態の変更例２において、ＵＥ１００は、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｄｕａｌ Ｒｅｑｕｅｓｔメッセージを送信する意図を通知するランダムアクセス信号を送信する。ｅＮＢ２００ｂは、ランダムアクセス信号に対する応答として、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｄｕａｌ Ｒｅｑｕｅｓｔメッセージの送信に用いる上りリンク無線リソースを示す割り当て情報（上りリンクグラント）を含むランダムアクセス応答をＵＥ１００に送信する。ＵＥ１００は、上りリンクグラントにより割り当てられた上りリンク無線リソースを用いてＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｄｕａｌ ＲｅｑｕｅｓｔメッセージをｅＮＢ２００ｂに送信する。

このように、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｄｕａｌ Ｒｅｑｕｅｓｔメッセージを送信する意図を通知するランダムアクセス信号を送信することにより、ｅＮＢ２００ｂは、ランダムアクセス信号に基づいて、適切な量の上りリンク無線リソースをＵＥ１００に割り当てることができる。具体的には、ｅＮＢ２００ｂは、一般的なＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｑｕｅｓｔメッセージの送信に用いる上りリンク無線リソース量よりも多い上りリンク無線リソースをＵＥ１００に割り当てる。

ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｄｕａｌ Ｒｅｑｕｅｓｔメッセージを送信する意図を通知するランダムアクセス信号とは、特定のプリアンブル系列（信号系列）及び／又は特定の時間・周波数リソースを用いて送信されるランダムアクセス信号をいう。

例えば、ｅＮＢ２００ｂは、特定のプリアンブル系列の候補（プリアンブル系列プール）及び／又は特定の時間・周波数リソースの候補（リソースプール）を示す情報をＳＩＢにより自セル内にブロードキャストする。ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｄｕａｌ Ｒｅｑｕｅｓｔメッセージを送信する意図を有するＵＥ１００は、ＳＩＢに基づいて特定のプリアンブル系列のプール及び／又は特定の時間・周波数リソースのプールを把握し、特定のプリアンブル系列及び／又は特定の時間・周波数リソースを選択してランダムアクセス信号を送信する。ランダムアクセス信号を受信したｅＮＢ２００は、当該ランダムアクセス信号に適用されているプリアンブル系列及び／又は時間・周波数リソースに基づいて、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｄｕａｌ Ｒｅｑｕｅｓｔメッセージを送信する意図をＵＥ１００が有することを把握する。

［第３実施形態］
第３実施形態について、第１及び第２実施形態との相違点を主として説明する。第３実施形態は、条件付きハンドオーバ（ｃｏｎｄｉｔｉｏｎａｌ ｈａｎｄｏｖｅｒ）に関する実施形態である。

一般的なハンドオーバプロシージャにおいて、ＵＥ１００のハンドオーバをｅＮＢ２００が決定する。例えば、ＵＥ１００は、ＵＥ１００とｅＮＢ２００（ソースｅＮＢ）との間の無線状態が悪化したこと、及び／又はＵＥ１００とターゲットｅＮＢとの間の無線状態が良化したことに応じて、無線状態に関する測定報告をｅＮＢ２００（ソースｅＮＢ）に送信する。ｅＮＢ２００は、ＵＥ１００から送信される測定報告に基づいてＵＥ１００のハンドオーバを決定し、その後、ターゲットｅＮＢに対して、ＵＥコンテキストを含むハンドオーバ要求を送信する。そして、ｅＮＢ２００（ソースｅＮＢ）は、ターゲットｅＮＢからハンドオーバ要求確認応答を受信すると、ＵＥ１００に対してハンドオーバ指令を送信する。ＵＥ１００は、ハンドオーバ指令を受信すると、ターゲットｅＮＢへのハンドオーバを実行し、ターゲットｅＮＢに対してランダムアクセス信号を送信する。

これに対し、条件付きハンドオーバのプロシージャにおいて、ＵＥ１００のハンドオーバをＵＥ１００自身が決定する。具体的には、ｅＮＢ２００は、ターゲットｅＮＢに対してハンドオーバ要求を予め送信する。ここで、ターゲットｅＮＢは、１つに限らず、複数であってもよい。よって、複数のターゲットｅＮＢがハンドオーバ要求を受信し得る。また、ｅＮＢ２００（ソースｅＮＢ）は、ＵＥ１００に対してハンドオーバ指令を予め送信する。ＵＥ１００は、ハンドオーバ指令を受信した後、ハンドオーバ条件が満たされるまでハンドオーバを保留し、ハンドオーバ条件が満たされたときにハンドオーバを実行して１つのターゲットｅＮＢに対してランダムアクセス信号を送信する。ハンドオーバ条件は、例えば、ＵＥ１００とｅＮＢ２００（ソースｅＮＢ）との間の無線状態が悪化したこと、及び／又はＵＥ１００とターゲットｅＮＢとの間の無線状態が良化したことである。当該ハンドオーバ条件は、ｅＮＢ２００から設定されてもよく、当該設定は受信参照信号品質（ＲＳＲＰ、ＲＳＲＱ、ＲＳ－ＳＩＮＲ等）の閾値であってもよく、パケット再送回数（ＲＬＣ再送回数）の閾値であってもよい。もしくは、当該ハンドオーバ条件は、無線リンク異常（Ｒａｄｉｏ Ｌｉｎｋ Ｆａｉｌｕｒｅ）であってもよい。すなわち、ＲＬＦを検出したＵＥは、ＲＬＦ状態であると認識するのではなく、ターゲットｅＮＢへのハンドオーバをトリガ（具体的にはランダムアクセスプロシージャを開始）する。

かかる条件付きハンドオーバは、ｅＮＢ２００（ソースｅＮＢ）が測定報告に基づくハンドオーバ決定を行わずに、ＵＥ１００自身でハンドオーバを決定するため、ＵＥ１００とｅＮＢ２００（ソースｅＮＢ）との間の無線状態が不安定である場合に好適である。第３実施形態において、ＵＥ１００が航空ユーザ装置（エアリアルＵＥ）であり、エアリアルＵＥに対して条件付きハンドオーバが適用される場合について説明する。なお、以下においてソースｅＮＢを「ソースｅＮＢ２００Ｓ」と表記し、ターゲットｅＮＢを「ターゲットｅＮＢ２００Ｔ」と表記する。

第３実施形態において、ソースｅＮＢ２００Ｓは、１又は複数のターゲットｅＮＢ２００Ｔに対して、ＵＥ１００のコンテキスト情報（ＵＥコンテキスト）を含むハンドオーバ要求を予め送信し、かつ、ＵＥ１００に対してハンドオーバ指令を予め送信する。ターゲットｅＮＢ２００Ｔは、ハンドオーバ要求の受信に応じて、ハンドオーバ要求確認応答をソースｅＮＢ２００Ｓに送信する。ＵＥ１００は、ソースｅＮＢ２００Ｓからハンドオーバ指令を受信した後、ハンドオーバ条件が満たされるまでハンドオーバを保留し、ハンドオーバ条件が満たされたときにハンドオーバを実行する。

ここで、ハンドオーバの実行タイミングをＵＥ１００が決定するため、各ターゲットｅＮＢ２００Ｔは、ＵＥ１００がいつハンドオーバを実行するかを把握していない。よって、複数のターゲットｅＮＢ２００Ｔが、ＵＥ１００が自セルにハンドオーバするまでＵＥコンテキストを保持する必要があり得る。しかしながら、ＵＥ１００により選択されなかったターゲットｅＮＢ２００Ｔは、ＵＥ１００が他のターゲットｅＮＢ２００Ｔにハンドオーバを行ったのにもかかわらず、ＵＥコンテキストを保持し続けてしまうという問題がある。

第３実施形態において、ハンドオーバ要求、ハンドオーバ要求確認応答、及びハンドオーバ指令の少なくとも１つには、ターゲットｅＮＢ２００Ｔがコンテキスト情報を保持すべき保持時間に対応するタイマ値が含まれる。これにより、ターゲットｅＮＢ２００Ｔがコンテキスト情報を保持すべき保持時間を適切に管理することができる。例えば、ターゲットｅＮＢ２００Ｔは、保持時間内にＵＥ１００が自セルにハンドオーバした場合には、保持しているＵＥコンテキストをＵＥ１００との通信に用いる。一方、ターゲットｅＮＢ２００Ｔは、保持時間内にＵＥ１００が自セルにハンドオーバしない場合には、保持しているＵＥコンテキストを破棄してもよい。

（１）動作例１
図１１は、第３実施形態に係る動作例１を示す図である。

図１１に示すように、ステップＳ５０１において、ＲＲＣコネクティッドモードのＵＥ１００（エアリアルＵＥ）は、ソースｅＮＢ２００Ｓのセルとの無線接続（ＲＲＣ接続）を確立している。

ステップＳ５０２において、ソースｅＮＢ２００Ｓは、条件付きハンドオーバのためのハンドオーバ要求メッセージを基地局間インターフェイス（Ｘ２インターフェイス）上でターゲットｅＮＢ２００Ｔに送信する。

ターゲットｅＮＢ２００Ｔは、ソースｅＮＢ２００Ｓに隣接する隣接ｅＮＢであってもよい。ソースｅＮＢ２００Ｓは、ＵＥ１００が自セルと接続した際にハンドオーバ要求をターゲットｅＮＢ２００Ｔに送信してもよい。ソースｅＮＢ２００Ｓは、複数のｅＮＢ（複数のターゲットｅＮＢ）に対してハンドオーバ要求を送信してもよい。

ハンドオーバ要求メッセージは、ＵＥコンテキストを含む。ハンドオーバ要求メッセージは、条件付きハンドオーバ専用の新たなメッセージであってもよい。或いは、ハンドオーバ要求メッセージは、条件付きハンドオーバを示す情報（情報要素）を含む既存のハンドオーバ要求メッセージであってもよい。

動作例１において、ソースｅＮＢ２００Ｓは、ターゲットｅＮＢ２００Ｔがコンテキスト情報を保持すべき保持時間を決定し、決定した保持時間に対応するタイマ値をハンドオーバ要求メッセージに含める。例えば、ソースｅＮＢ２００Ｓは、統計情報及び／又はＵＥ１００の移動速度に基づいて保持時間を決定する。

ソースｅＮＢ２００Ｓは、ＵＥ１００がエアリアルＵＥであることを示す情報をハンドオーバ要求メッセージに含めてもよい。例えば、カテゴリ又は属性がＡｅｒｉａｌ ＵＥであることを示す情報であってもよいし、飛行中であることを示す情報であってもよいし、ＵＥ１００の実行中のアプリケーションがエアリアルＵＥ向けの種別（例えば、遠隔監視・制御アプリケーション）であることを示す情報であってもよい。かかる場合、ターゲットｅＮＢ２００Ｔは、エアリアルＵＥ情報に基づいて、ＵＥ１００に割り当てるべき無線リソースを判断する。例えば、ターゲットｅＮＢ２００Ｔは、エアリアルＵＥ専用の周波数帯を割り当ててもよいし、１つの周波数帯を複数のサブバンドに分割し、エアリアルＵＥ専用のサブバンドを割り当ててもよい。

ターゲットｅＮＢ２００Ｔは、ハンドオーバ要求メッセージを受信すると、ステップＳ５０３において、ハンドオーバ要求メッセージに含まれるＵＥコンテキストを保持する。また、ハンドオーバ要求メッセージに含まれるタイマ値を設定したタイマを開始させる。

ステップＳ５０４において、ターゲットｅＮＢ２００Ｔは、ハンドオーバ要求確認応答（Ａｃｋ）メッセージをＸ２インターフェイス上でソースｅＮＢ２００Ｓに送信する。

ソースｅＮＢ２００Ｓは、ハンドオーバ要求確認応答メッセージを受信すると、ステップＳ５０５において、条件付きハンドオーバを示す情報（情報要素）を含むハンドオーバ指令（ＲＲＣ ｃｏｎｎｅｃｔｉｏｎ ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージ）をＵＥ１００に送信する。ハンドオーバ指令は、ＵＥ１００がハンドオーバを実行すべき条件であるハンドオーバ条件を指定する情報を含んでもよい。

ソースｅＮＢ２００Ｓは、保持時間に対応するタイマ値をハンドオーバ指令に含める。また、ソースｅＮＢ２００Ｓは、ハンドオーバ対象の複数のセル（すなわち、１又は複数のターゲットｅＮＢ２００Ｔのセル）を示すセルリストをハンドオーバ指令に含める。セルリスト中のセルごとにタイマ値が関連付けられていてもよい。かかる場合、セルリスト中のセルごとに異なるタイマ値を設定することができる。

ステップＳ５０６において、ソースｅＮＢ２００Ｓは、タイマ値を設定したタイマを開始させる。ステップＳ５０６の処理は、ステップＳ５０４とステップＳ５０５との間に行なわれてもよい。

ＵＥ１００は、ハンドオーバ指令を受信すると、条件付きハンドオーバが指示されたことを認識し、ステップＳ５０７において、ハンドオーバ指令に含まれるタイマ値を設定したタイマを開始させる。セルごとにタイマ値が提供される場合、ＵＥ１００は、セルごとにタイマ値（保持時間）を管理する。

ステップＳ５０８において、ＵＥ１００は、ハンドオーバ条件が満たされた否かを判定する。ＵＥ１００は、かかる判定をセルリスト中のセルに限定して行なってもよい。ここでは、ハンドオーバ条件が満たされたと仮定して説明を進める。

ＵＥ１００は、タイマ値に対応する保持時間内においてハンドオーバを実行する場合に、ステップＳ５０９において、ハンドオーバの実行を示す通知（ハンドオーバ実行通知）をソースｅＮＢ２００Ｓに送信する。ソースｅＮＢ２００Ｓは、ハンドオーバ実行通知に基づいて、ＵＥ１００がハンドオーバを実行することを把握する。ハンドオーバ実行通知は、ＵＥ１００がハンドオーバ先（すなわち、ランダムアクセス信号の送信先）として選択したセルを示す情報を含んでもよい。ソースｅＮＢ２００Ｓは、ハンドオーバ実行通知に対する応答をＵＥ１００に送信してもよい。

ステップＳ５１０において、ＵＥ１００は、ハンドオーバ先として選択したセル（ターゲットｅＮＢ２００Ｔ）に対してランダムアクセスプロシージャを開始し、当該セルに対してランダムアクセス信号を送信する。

ここでは保持時間内にハンドオーバが実行される一例を説明したが、保持時間内にハンドオーバが実行されずにタイマが満了（保持時間が経過）した場合、ＵＥ１００及びソースｅＮＢ２００Ｓは、条件付きハンドオーバから通常のハンドオーバ（ｅＮＢ主導のハンドオーバ）に切り替えてもよい。通常のハンドオーバに切り替える場合、ＵＥ１００は、測定報告プロシージャを開始してもよい。また、ターゲットｅＮＢ２００Ｔは、保持時間内にＵＥ１００が自セルにハンドオーバしない場合には、保持しているＵＥコンテキストを破棄する。

（２）動作例２
図１２は、第３実施形態に係る動作例２を示す図である。ここでは、第３実施形態に係る動作例１との相違点を説明する。動作例２では、タイマ値をソースｅＮＢ２００Ｓが決定することに代えて、タイマ値をターゲットｅＮＢ２００Ｔが決定する。

図１２に示すように、ステップＳ５１１において、ＲＲＣコネクティッドモードのＵＥ１００（エアリアルＵＥ）は、ソースｅＮＢ２００Ｓのセルとの無線接続（ＲＲＣ接続）を確立している。

ステップＳ５１２において、ソースｅＮＢ２００Ｓは、条件付きハンドオーバのためのハンドオーバ要求メッセージを基地局間インターフェイス（Ｘ２インターフェイス）上でターゲットｅＮＢ２００Ｔに送信する。ソースｅＮＢ２００Ｓは、複数のｅＮＢ（複数のターゲットｅＮＢ）に対してハンドオーバ要求を送信してもよい。ソースｅＮＢ２００Ｓは、ＵＥ１００がエアリアルＵＥであることを示す情報をハンドオーバ要求メッセージに含めてもよい。

ターゲットｅＮＢ２００Ｔは、ハンドオーバ要求メッセージを受信すると、ステップＳ５１３において、ハンドオーバ要求メッセージに含まれるＵＥコンテキストを保持する。また、ターゲットｅＮＢ２００Ｔは、自身がコンテキスト情報を保持すべき保持時間を決定する。

ステップＳ５１４において、ターゲットｅＮＢ２００Ｔは、ハンドオーバ要求確認応答（Ａｃｋ）メッセージをＸ２インターフェイス上でソースｅＮＢ２００Ｓに送信する。ターゲットｅＮＢ２００Ｔは、決定した保持時間に対応するタイマ値をハンドオーバ要求確認応答メッセージに含める。

ステップＳ５１５において、ターゲットｅＮＢ２００Ｔは、タイマ値を設定したタイマを開始させる。

ソースｅＮＢ２００Ｓは、ハンドオーバ要求確認応答メッセージを受信すると、ハンドオーバ要求確認応答メッセージに含まれるタイマ値を記憶する。ステップＳ５１６において、ソースｅＮＢ２００Ｓは、条件付きハンドオーバを示す情報（情報要素）を含むハンドオーバ指令（ＲＲＣ ｃｏｎｎｅｃｔｉｏｎ ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージ）をＵＥ１００に送信する。その後の動作（ステップＳ５１７～Ｓ５２１）については動作例１と同様である。

［第３実施形態の変更例１］
第３実施形態において、条件付きハンドオーバにおいて、ＵＥ１００により選択されなかったターゲットｅＮＢ２００ＴがＵＥコンテキストを保持し続けてしまうという問題点を、タイマを用いて解決する一例を説明した。第３実施形態の変更例１及び２は、かかる問題点を、基地局間メッセージであるコンテキスト解放通知（ＵＥ Ｃｏｎｔｅｘｔ Ｒｅｌｅａｓｅ）を用いて解決するものである。

第３実施形態の変更例１において、ソースｅＮＢ２００Ｓは、複数のターゲットｅＮＢ２００Ｔに対して、ＵＥ１００のコンテキスト情報を含むハンドオーバ要求を予め送信し、かつ、ＵＥ１００に対してハンドオーバ指令を予め送信する。ＵＥ１００は、ソースｅＮＢ２００Ｓからハンドオーバ指令を受信した後、ハンドオーバ条件が満たされるまでハンドオーバを保留し、ハンドオーバ条件が満たされたときに複数のターゲットｅＮＢ２００Ｔのうち１つのターゲットｅＮＢ２００Ｔへのハンドオーバを実行する。この１つのターゲットｅＮＢ２００Ｔは、かかるハンドオーバに応じて、ソースｅＮＢ２００Ｓに対して、ＵＥ１００のコンテキスト情報を解放可能であることを示す第１のコンテキスト解放通知を送信する。ソースｅＮＢ２００Ｓは、第１のコンテキスト解放通知の受信に応じて、複数のターゲットｅＮＢ２００Ｔのうち１つのターゲットｅＮＢ２００Ｔ以外のターゲットｅＮＢ２００Ｔに対して、ＵＥ１００のコンテキスト情報を解放可能であることを示す第２のコンテキスト解放通知を送信する。

図１３は、第３実施形態の変更例１を示す図である。ここでは、第３実施形態に係る動作（図１１及び図１２参照）との相違点を主として説明する。

図１３に示すように、ステップＳ５３１において、ＲＲＣコネクティッドモードのＵＥ１００（エアリアルＵＥ）は、ソースｅＮＢ２００Ｓのセルとの無線接続（ＲＲＣ接続）を確立している。

ステップＳ５３２及びＳ５３３において、ソースｅＮＢ２００Ｓは、条件付きハンドオーバのためのハンドオーバ要求メッセージを基地局間インターフェイス（Ｘ２インターフェイス）上で複数のターゲットｅＮＢ２００Ｔ（２００Ｔ１、２００Ｔ２、・・・）に送信する。ハンドオーバ要求メッセージは、ＵＥコンテキストを含む。ハンドオーバ要求メッセージは、条件付きハンドオーバ専用の新たなメッセージであってもよい。或いは、ハンドオーバ要求メッセージは、条件付きハンドオーバを示す情報（情報要素）を含む既存のハンドオーバ要求メッセージであってもよい。ソースｅＮＢ２００Ｓは、ＵＥ１００がエアリアルＵＥであることを示す情報をハンドオーバ要求メッセージに含めてもよい。各ターゲットｅＮＢ２００Ｔは、ハンドオーバ要求メッセージを受信すると、ハンドオーバ要求メッセージに含まれるＵＥコンテキストを保持する。

ステップＳ５３４及びＳ５３５において、各ターゲットｅＮＢ２００Ｔは、ハンドオーバ要求確認応答（Ａｃｋ）メッセージをＸ２インターフェイス上でソースｅＮＢ２００Ｓに送信する。

ソースｅＮＢ２００Ｓは、各ターゲットｅＮＢ２００Ｔからハンドオーバ要求確認応答メッセージを受信すると、ステップＳ５３６において、条件付きハンドオーバを示す情報（情報要素）を含むハンドオーバ指令（ＲＲＣ ｃｏｎｎｅｃｔｉｏｎ ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージ）をＵＥ１００に送信する。ハンドオーバ指令は、ＵＥ１００がハンドオーバを実行すべき条件であるハンドオーバ条件を指定する情報を含んでもよい。ソースｅＮＢ２００Ｓは、ハンドオーバ対象の複数のセル（すなわち、複数のターゲットｅＮＢ２００Ｔのセル）を示すセルリストをハンドオーバ指令に含める。

ＵＥ１００は、ハンドオーバ指令を受信した後、ハンドオーバ条件が満たされた否かを判定する。ＵＥ１００は、かかる判定をセルリスト中のセルに限定して行なってもよい。ここでは、ターゲットｅＮＢ２００Ｔ１についてハンドオーバ条件が満たされたと仮定して説明を進める。ＵＥ１００は、ハンドオーバを実行する場合に、ステップＳ５３８において、ハンドオーバの実行を示す通知（ハンドオーバ実行通知）をソースｅＮＢ２００Ｓに送信する。

ステップＳ５３９において、ＵＥ１００は、ハンドオーバ先として選択したセル（ターゲットｅＮＢ２００Ｔ１）に対してランダムアクセスプロシージャを開始し、当該セルに対してランダムアクセス信号を送信する。

ランダムアクセスプロシージャが完了すると、ステップＳ５４０において、ＵＥ１００は、ターゲットｅＮＢ２００Ｔ１とのＲＲＣ接続を確立する。かかるハンドオーバの実行に応じて、ターゲットｅＮＢ２００Ｔ１は、ステップＳ５４１において、ソースｅＮＢ２００Ｓに対して、ＵＥ１００のコンテキスト情報（ＵＥコンテキスト）を解放可能であることを示す第１のコンテキスト解放通知をＸ２インターフェイス上で送信する。

ソースｅＮＢ２００Ｓは、第１のコンテキスト解放通知を受信した後、ソースｅＮＢ２００Ｓで保持しているＵＥコンテキストを破棄する前に、ステップＳ５４２において、第１のコンテキスト解放通知の送信元のターゲットｅＮＢ２００Ｔ１以外のターゲットｅＮＢ２００Ｔ２に対して、ＵＥコンテキストを解放可能であることを示す第２のコンテキスト解放通知を送信する。そして、ソースｅＮＢ２００Ｓは、ソースｅＮＢ２００Ｓで保持しているＵＥコンテキストを破棄する。ターゲットｅＮＢ２００Ｔ２は、第２のコンテキスト解放通知の受信に応じて、ターゲットｅＮＢ２００Ｔ２で保持しているＵＥコンテキストを破棄する。

［第３実施形態の変更例２］
第３実施形態の変更例２において、ソースｅＮＢ２００Ｓは、複数のターゲットｅＮＢ２００Ｔに対して、ＵＥ１００のコンテキスト情報と複数のターゲットｅＮＢ２００Ｔに関するｅＮＢリスト（基地局リスト）とを含むハンドオーバ要求を予め送信し、かつ、ＵＥ１００に対してハンドオーバ指令を予め送信する。ＵＥ１００は、ソースｅＮＢ２００Ｓからハンドオーバ指令を受信した後、ハンドオーバ条件が満たされるまでハンドオーバを保留し、ハンドオーバ条件が満たされたときに複数のターゲットｅＮＢ２００Ｔのうち１つのターゲットｅＮＢ２００Ｔへのハンドオーバを実行する。１つのターゲットｅＮＢ２００Ｔは、ハンドオーバに応じて、ソースｅＮＢ２００Ｓと、ｅＮＢリストに対応する他のターゲットｅＮＢ２００Ｔとに対して、ＵＥ１００のコンテキスト情報を解放可能であることを示すコンテキスト解放通知を送信する。

図１４は、第３実施形態の変更例２を示す図である。ここでは、第３実施形態の変更例１（図１３参照）との相違点を主として説明する。

図１４に示すように、ステップＳ５５１において、ＲＲＣコネクティッドモードのＵＥ１００（エアリアルＵＥ）は、ソースｅＮＢ２００Ｓのセルとの無線接続（ＲＲＣ接続）を確立している。

ステップＳ５５２及びＳ５５３において、ソースｅＮＢ２００Ｓは、条件付きハンドオーバのためのハンドオーバ要求メッセージを基地局間インターフェイス（Ｘ２インターフェイス）上で複数のターゲットｅＮＢ２００Ｔ（２００Ｔ１、２００Ｔ２、・・・）に送信する。ハンドオーバ要求メッセージは、ＵＥコンテキストを含む。第３実施形態の変更例２において、ハンドオーバ要求メッセージは、複数のターゲットｅＮＢ２００Ｔのそれぞれの識別子を含むｅＮＢリストを含む。但し、あるターゲットｅＮＢ２００Ｔに送信されるｅＮＢリストは、当該ターゲットｅＮＢ２００Ｔの識別子を含まなくてもよい。各ターゲットｅＮＢ２００Ｔは、ハンドオーバ要求メッセージを受信すると、ハンドオーバ要求メッセージに含まれるＵＥコンテキスト及びｅＮＢリストを保持する。

ステップＳ５５４～Ｓ５６０の各処理は、図１３のステップＳ５３４～５４０の各処理と同様である。

ＵＥ１００がターゲットｅＮＢ２００Ｔ１とのＲＲＣ接続を確立した後、ターゲットｅＮＢ２００Ｔ１は、ステップＳ５６１において、ソースｅＮＢ２００Ｓに対して、ＵＥ１００のコンテキスト情報（ＵＥコンテキスト）を解放可能であることを示すコンテキスト解放通知をＸ２インターフェイス上で送信する。また、ターゲットｅＮＢ２００Ｔ１は、ステップＳ５６２において、ターゲットｅＮＢ２００Ｔ１で保持しているｅＮＢリストに基づいて、ターゲットｅＮＢ２００Ｔ２に対して、ＵＥコンテキストを解放可能であることを示すコンテキスト解放通知を送信する。そして、ソースｅＮＢ２００Ｓ及びターゲットｅＮＢ２００Ｔ２は、自身で保持しているＵＥコンテキストを破棄する。

［第４実施形態］
ＵＥ１００は、ハンドオーバ失敗（Ｈａｎｄｏｖｅｒ Ｆａｉｌｕｒｅ）の発生等により、ターゲットセル（ターゲットｅＮＢ）２００－２とのＲＲＣ接続の確立に失敗した場合に、ターゲットセル２００－２とのＲＲＣ接続の確立をするために、ターゲットセル２００－２とのＲＲＣ接続の再確立のための手順（ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ Ｐｒｏｃｅｄｕｒｅ）を実行する。

ここで、ＵＥ１００は、ＵＡＶ（Ｕｎｍａｎｎｅｄ ａｅｒｉａｌ ｖｅｈｉｃｌｅ）であると想定するが、ＵＡＶに限られない。

ＵＥ１００はＵＡＶであることから、ＵＥ１００は、ハンドオーバ失敗後、ＲＲＣアイドルモードにおいて、ハンドオーバ失敗前に接続していたサービングセル２００－１から遠くはなれたセルを再選択した後に、当該セルをターゲットセル２００－２として、ＲＲＣ接続の再確立のための手順を実行することが考えられる。

そのような場合には、サービングセル２００－１とターゲットセル２００－２との間でＸ２接続が無い場合もある。その場合には、ターゲットセル２００－２は、Ｘ２インターフェイスを介したＵＥ Ｃｏｎｔｅｘｔ Ｆｅｔｃｈを利用して、サービングセル２００－１からＵＥ Ｃｏｎｔｅｘｔを取得することができないため、ＵＥ１００とターゲットセル２００－２とのＲＲＣ接続の再確立の失敗（ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ Ｆａｉｌｕｒｅ）が起こる怖れがある。その場合、ＵＥ１００の通信が切断されている時間が増えるという課題が存在する。

なお、ＵＥ Ｃｏｎｔｅｘｔ（移動局情報）は、ＲＲＣ接続の再確立（すなわち、再接続）時に、再接続先の基地局が移動局を特定するために必要な情報である。

ＵＥ Ｃｏｎｔｅｘｔ Ｆｅｔｃｈとは、再接続先の基地局が、再接続手順の際に移動局から取得したＵＥ Ｃｏｎｔｅｘｔを、移動局が無線リンク障害前に通信をしていた基地局に照会し、当該移動局を特定することである。

上記の課題を解決し得る実施形態を、図１５に沿って、以下に説明する。

ＵＥ１００とＲＲＣ接続中のサービングセル２００－２は、ＵＥ１００のサービングセル２００－１からターゲットセル２００－２へのハンドオーバ手順の開始前又は実行中に、ＵＥ１００に対して、ＵＥ１００のＵＥ Ｃｏｎｔｅｘｔを送信する（ステップＳ６０１）。

なお、ステップＳ６０１において送信されるＵＥ Ｃｏｎｔｅｘｔは、カプセル化されていてもよい。具体的には、カプセル化されたＵＥ Ｃｏｎｔｅｘｔは、ＲＲＣメッセージ（ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージ等）内の専用のコンテナ（Ｃｏｎｔａｉｎｅｒ）に格納されてサービングセル２００－１から送信されてもよい。なお、カプセル化されたＵＥ Ｃｏｎｔｅｘｔは、暗号化されていてもよい。当該暗号化の鍵及び方式等の情報は、ステップＳ６０１よりも前に、所定のノードからサービングセル２００－２及びターゲットセル２００－１へ送信されていてもよい。当該暗号化の鍵及び方式等の情報は、ＭＭＥからＳ１インターフェイスを介してサービングセル２００－２及びターゲットセル２００－１へ送信されてもよいし、ＯＡＭによってサービングセル２００－２及びターゲットセル２００－１に設定されてもよい。

なお、ステップＳ６０１において送信されるＵＥ Ｃｏｎｔｅｘｔは、サービングセル２００－１のグローバルセルＩＤ（Ｇｌｏｂａｌ Ｃｅｌｌ ＩＤ）を含んでもよい。

ＵＥ１００は、ＵＥ１００のＵＥ Ｃｏｎｔｅｘｔを受信した後、サービングセル２００－１からターゲットセル２００－２へのハンドオーバに失敗した場合に、ターゲットセル２００－１とのＲＲＣ接続を確立するために、ＲＲＣ接続の再確立のための手順を開始する（ステップＳ６０２）。

ＵＥ１００は、ＲＲＣ接続の再確立要求（ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ Ｒｅｑｕｅｓｔ）をターゲットセル２００－２に対して送信する（ステップＳ６０３）。ＵＥ１００は、送信するＲＲＣ接続の再確立要求に、ＵＥ１００がＵＥ Ｃｏｎｔｅｘｔを保持することを示す情報（Ｉｎｄｉｃａｔｉｏｎ）を含める。

ターゲットセル２００－２は、サービングセル２００－１との間でＸ２接続が無いためにＵＥ Ｃｏｎｔｅｘｔ Ｆｅｔｃｈに失敗したこと等により、サービングセル２００－１からＵＥ１００のＵＥ Ｃｏｎｔｅｘｔを取得できなかった場合、ＵＥ１００に対して、ＵＥ１００のＵＥ Ｃｏｎｔｅｘｔの送信を要求する（ステップＳ６０４）。なお、ターゲットセル２００－２は、ＵＥ Ｃｏｎｔｅｘｔ Ｆｅｔｃｈによりサービングセル２００－１からＵＥ１００のＵＥ Ｃｏｎｔｅｘｔを取得できた場合には、ＵＥ１００に対して、ＵＥ１００のＵＥ Ｃｏｎｔｅｘｔの送信を要求しなくてもよい。

ＵＥ１００は、ステップＳ６０４において、ターゲットセル２００－２からＵＥ Ｃｏｎｔｅｘｔの送信の要求を受信した場合、ターゲットセル２００－２に対して、ＵＥ Ｃｏｎｔｅｘｔを送信する（ステップＳ６０５）。

なお、ステップＳ６０１において、ＵＥ１００は、カプセル化されたＵＥ Ｃｏｎｔｅｘｔを受信した場合、ステップＳ６０５において、当該カプセル化されたＵＥ Ｃｏｎｔｅｘｔをそのままターゲットセル２００－１に対して送信してもよい。

また、ＵＥ１００は、ステップＳ６０１において受信したＵＥ Ｃｏｎｔｅｘｔにサービングセル２００－１のグローバルセルＩＤ（Ｇｌｏｂａｌ Ｃｅｌｌ ＩＤ）が含まれていた場合、ステップＳ６０５において、ターゲットセル２００－２に対して、ＵＥ１００のＵＥ Ｃｏｎｔｅｘｔに加えてサービングセル２００－１のグローバルセルＩＤを送信する。

なお、他の実施形態として、ＵＥ１００は、ＵＡＶである場合には、複数の基地局間のリレーポイントとして機能してもよい。つまり、通常、Ｘ２インターフェイスを使用して基地局間で送受信しているメッセージ又は情報（各基地局の負荷情報（Ｌｏａｄ ｉｎｆｏｒｍａｔｉｏｎ）、ＲＬＦ Ｉｎｄｉｃａｔｉｏｎ（Ｒａｄｉｏ Ｌｉｎｋ Ｆａｉｌｕｒｅ Ｉｎｄｉｃａｔｉｏｎ）等））を、ＵＥ１００を介して、Ｘ２インターフェイスを使用する代わりに、複数の基地局間で送受信することとしてもよい。

［その他の実施形態］
上述した実施形態において、Ａｅｒｉａｌ ＵＥ又はＵＡＶ ＵＥを用いる一例を説明した。しかしながら、本開示はＡｅｒｉａｌ ＵＥ又はＵＡＶ ＵＥに限定されない。Ａｅｒｉａｌ ＵＥ又はＵＡＶ ＵＥ以外のＵＥに対して、上述した実施形態に係る動作を適用してもよい。例えば、車両向けのＵＥ（Ｖｅｈｉｃｌｅ ＵＥ）は高速移動中に接続障害を頻発し得るため、Ｖｅｈｉｃｌｅ ＵＥに対して、上述した実施形態に係る動作を適用してもよい。

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

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

［付記］
（はじめに）
本付記において、モビリティ管理の重要な機能の１つと考えられる接続再確立の問題を検討する。

（接続再確立に関する問題）
ほとんどの場合、特に高い高度及び高い速度で、地上ＵＥよりも航空ハンドオーバ失敗率が高い。航空ＵＥが異なるハンドオーバ特性、例えば、遠方のハンドオーバターゲットセルを有することも指摘されており、ＵＡＶで観測された隣接セルの数に基づいてＤＬ干渉及びＵＬ干渉に関連する測定報告をトリガするための移動度向上が検討されている。

大きなハンドオーバ失敗の影響と、ＵＡＶがハンドオーバのために遠方のターゲットセルを考慮する可能性を組み合わせると、起こりうる１つの潜在的な問題は、接続再確立失敗の可能性である。ハンドオーバ失敗の場合、ＵＥは接続再確立を実行し、再確立プロセスの一部として、ＵＥはセル選択を実行する。隣接セルの数及び強度に依存して、既存のセル選択手順は、選択されたセルが準備されたセルではない（すなわち、有効なＵＥコンテキストを有しない）ことがあり、接続再確立を成功させずに、ＵＥがＲＬＦを宣言する可能性がある。

観察１：多数の観測されるセルのために、ＵＡＶは、接続再確立中に、準備ができていないセルを選択しうる。

（干渉の問題を解決することによる問題解決）
Ｘ２インターフェイスがない場合、Ｓ１ハンドオーバが想定され、問題はない。

干渉問題を解決することはハンドオーバ失敗を減少させる可能性があるが、これまでの議論から、ハンドオーバ失敗を排除することは期待できない。ハンドオーバ失敗が現実的に地上ＵＥが経験するレベルまで削減できるかどうかは疑問である。ハンドオーバ失敗率が地上ＵＥのそれと同様であっても、ＵＡＶは考察１に記載された問題のために、より多くのＲＬＦを経験する可能性が高い。

考察２：干渉問題を解決することはハンドオーバ失敗を緩和することができるが、これまで導入されたメカニズムのどれも、ハンドオーバ失敗を地上ＵＥが経験するものよりも下げることは期待できない。

Ｘ２インターフェイスが利用可能でない場合、ターゲットセルが接続再確立手順の間にＵＥコンテキストを持たず、現在Ｓ１インターフェイスを介してＵＥコンテキストフェッチがサポートされていないので、Ｓ１ハンドオーバは使用できない。

考察３：現在、Ｓ１インターフェイスはＵＥコンテキストフェッチをサポートしていない。

Ｓ１上のＵＥコンテキストフェッチのサポートがなければ、ターゲットセルは接続再確立要求を拒絶する必要があり、ＵＥはその後ＮＡＳリカバリーを実行し始める。ＮＡＳリカバリー手順の一部として、ＵＥはアイドル状態に移行し、ＲＬＦハンドオーバ手順に対して追加の遅延を招き、その結果、サービスのより長い中断が生じる。さらに、データ転送及び順序通りの配信は実行できない。したがって、ソースｅＮＢにバッファされたデータはすべて失われる。

考察４：ＮＡＳリカバリーは、サービスの過度な遅延と中断を引き起こす可能性がある。

（潜在的な解決策）
改善されたモビリティ性能及び干渉検出をサポートするための拡張を仕様化するためには、接続再確立の失敗の問題も解決する必要がある。ＵＡＶが過度の接続再確立失敗を経験する場合、モビリティパフォーマンスの改善には限界がある。以下の候補の解決策を慎重に検討する必要がある。

ａ）サービングセルは、サービングセルとのＸ２インターフェイス接続を有する隣接セルのリストを提供する。

ｂ）サービングセルは、ＵＥコンテキストを受信することができる隣接セルのリストを提供する。

ｃ）ＵＡＶは、二重の再確立の理由を再確立要求で示すことができる。第１の理由は通常の再確立要求であり、準備されたターゲットセルはＵＡＶの再確立要求（レガシー）を受け入れることができる。第２の理由は、ターゲットセルによって新たな接続要求として解釈される可能性がある。ターゲットセルが（Ｘ２インターフェイスの不足のために）ＵＡＶのコンテキストをフェッチできない場合、ターゲットセルは再確立要求を拒絶する必要はなく、単にこれを新たな接続要求とみなす。

ｄ）ＵＥ支援のＵＥコンテキスト転送。ハンドオーバの準備中、サービングセルは、ＵＥコンテキスト情報をＵＡＶに提供することができる。ＵＡＶは、再確立要求において、必要なＵＥコンテキスト情報を有することを示すことができる。再確立手順中に、ターゲットセルがソースセルからＵＥコンテキストを取得できない場合、ターゲットセルはＵＡＶからＵＥコンテキスト情報を直接要求することができる（ターゲットセルが再確立要求を受け入れた後）。

ｅ）ＲＲＣ接続再開手順を再利用して、接続再確立失敗によって引き起こされる中断時間を減らす。

ｆ）位置ベースの測定構成及び報告がＵＡＶについて導入され、ＵＡＶが実行及び報告するための基準が、ＵＡＶと候補セルとの間の距離に基づいて構成され得る。

解決策ａ）は、ソースセルから（例えば、Ｘ２インターフェイスを介して）ＵＥコンテキストをフェッチすることができる隣接セルのＵＡＶに知らせる簡単な方法である。情報は、ブロードキャストまたは専用シグナリングを介してＵＥに提供されてもよい。この解決策では、ＵＥは、最も高いランク付けされたセルを選択する必要はない。なぜなら、最も高いランク付けされたセルは、ＵＥのコンテキストをフェッチする能力を有する隣接セルのリストにないからである。その代わりに、リストに載っているセルの中で最も高いランクのセルが考慮される可能性がある。

解決策ｂ）は解決策ａ）と同様であるが、ソースセルへのＸ２インターフェイスを有する隣接セルに加えて、ソースセルは、ハンドオーバ準備フェーズの一部としてＵＥコンテキストを隣接セルに転送するオプションを有することができるＵＡＶからの測定報告に基づいて隣接セルに送信する。ソースセルは、ＵＡＶに、ＵＥのコンテキスト情報も有する可能性のある追加のセルを専用シグナリングを介して通知することができる。

解決策ｃ）は、２段階のレガシーアプローチ（再確立拒否に続く新しい接続要求）と比較して、再確立の待ち時間を短縮するための方法であり、ネットワーク調整を必要としない。ターゲットセルがソースセルからＵＥコンテキストを取り出すことができない場合、ソースｅＮＢ内にバッファリングされたデータはすべて失われ、これは従来の場合と変わらない。

解決策ｄ）では、ＵＡＶは、ターゲットセルとの自身のコンテキスト情報のリレーとして動作しているが、ＵＥコンテキストをソースセルからフェッチできない場合にのみ動作する。

解決策ｅ）では、ターゲットｅＮＢがＲＲＣ接続再開要求からＲｅｓｕｍｅ ＩＤとＳｈｏｒｔＲｅｓｕｍｅＭＡＣ－Ｉを抽出することが考えられる。ターゲットｅＮＢは、ＡＳセキュリティコンテキストを含むＵＥコンテキストを検索するために、Ｒｅｓｕｍｅ ＩＤ、ＴａｒｇｅｔＲｅｓｕｍｅＭＡＣ－Ｉ及びＣｅｌｌ－ＩＤを含むＲｅｔｒｉｅｖｅ ＵＥ Ｃｏｎｔｅｘｔ ＲｅｑｕｅｓｔメッセージをＸ２インターフェイス上で送信することによって、Ｒｅｓｕｍｅ ＩＤの情報に基づいてソースｅＮＢにコンタクトする。しかし、ターゲットｅＮＢがソースｅＮＢとのＸ２インターフェイスを持たない場合、これがどのように達成されるかは明確ではない。

解決策ｆ）では、近くの隣接セルがソースセルとＸ２インターフェイスを持つ可能性が高いという考えがある。Ｘ２インターフェイスを使用したネットワーク展開が厳密に距離ベースであるかどうかは不明である。これにより、Ｘ２インターフェイスを備えた特定の隣接セルが遠く離れてしまう可能性がある。

上記のすべての解決策の中で、解決策ｃ）と解決策ｆ）は、ネットワークコーディネーションに与える影響は最小限で、影響は最小限であると考えられる。解決策ｆ）は、ターゲットセルを、地上ＵＥに適用可能なターゲットセルにおそらく制限し、ＵＡＶにサービスするためにより良い候補である可能性があるＵＡＶから遠くに潜在的なターゲットセルを制限することができる（例えば、ＵＡＶに適したアンテナ構成に基づく）。ＲＡＮ２が（例えば、Ｘ２インターフェイスを用いて）拡張隣接セルリストを考慮し、ＵＡＶの再選択規則に対するいくつかの変更が接続再確立失敗を避けるために妥当である場合には、解決策ａ）またはｂ）を考慮することもできる。解決策ｅ）は、概念的にはＵＥコンテキスト転送のための最も非従来的なアプローチであるが、再確立失敗（例えば、ＵＬ干渉を回避するための調整）を処理するための使用を超えてネットワーク調整を低減する上で重要な役割を果たすと考えられる。

提案：ＲＡＮ２は、上記の解決策の１つを採用して、接続の再確立の失敗に対処するべきである。

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

Claims (5)

1. セルラ通信ネットワークとの無線接続を確立し、前記無線接続を用いてセルラ通信を行うユーザ装置を有するセルラ通信システムであって、
   前記ユーザ装置は、前記無線接続がサスペンドされる所定状態において、前記無線接続を復旧することを要求する第１の要求情報と、新たに無線接続を確立することを要求する第２の要求情報とを含む要求メッセージを前記セルラ通信ネットワークに送信し、
   前記セルラ通信ネットワークは、前記要求メッセージを受信する基地局を含み、
   前記基地局は、
   前記要求メッセージを送信した前記ユーザ装置に対応するＵＥコンテキストを前記基地局が利用可能でない場合であっても、前記要求メッセージを拒絶する拒絶メッセージを前記ユーザ装置に送信することなく、新たな無線接続を確立することを示す応答メッセージを前記ユーザ装置に送信し、
   前記ユーザ装置は、前記基地局から、前記第１の要求情報及び前記第２の要求情報を含む前記要求メッセージの送信を許可することを示す所定のシステム情報がブロードキャストされているか否かを判断し、
   前記ユーザ装置は、前記所定のシステム情報が前記基地局からブロードキャストされている場合に限り、前記要求メッセージを前記基地局に送信する、セルラ通信システム。
2. セルラ通信ネットワークとの無線接続を確立し、前記無線接続を用いてセルラ通信を行うユーザ装置を有するセルラ通信システムであって、
   前記ユーザ装置は、前記無線接続がサスペンドされる所定状態において、前記無線接続を復旧することを要求する第１の要求情報と、新たに無線接続を確立することを要求する第２の要求情報とを含む要求メッセージを前記セルラ通信ネットワークに送信し、
   前記セルラ通信ネットワークは、前記要求メッセージを受信する基地局を含み、
   前記基地局は、
   前記要求メッセージを送信した前記ユーザ装置に対応するＵＥコンテキストを前記基地局が利用可能でない場合であっても、前記要求メッセージを拒絶する拒絶メッセージを前記ユーザ装置に送信することなく、新たな無線接続を確立することを示す応答メッセージを前記ユーザ装置に送信し、
   前記ユーザ装置は、前記基地局に対して、前記第１の要求情報及び前記第２の要求情報を含む前記要求メッセージを送信する意図を通知するランダムアクセス信号を送信し、
   前記ユーザ装置は、前記ランダムアクセス信号に対する応答として、前記第１の要求情報及び前記第２の要求情報を含む前記要求メッセージの送信に用いる上りリンク無線リソースを示す割り当て情報を前記基地局から受信する、セルラ通信システム。
3. セルラ通信ネットワークとの無線接続を確立し、前記無線接続を用いてセルラ通信を行うユーザ装置であって、
   前記無線接続がサスペンドされる所定状態において、前記無線接続を復旧することを要求する第１の要求情報と、新たに無線接続を確立することを要求する第２の要求情報とを含む要求メッセージを前記セルラ通信ネットワークに含まれる基地局に送信する送信部と、
   前記ユーザ装置に対応するＵＥコンテキストを前記基地局が利用可能でない場合であっても、前記要求メッセージを拒絶する拒絶メッセージを前記ユーザ装置に受信することなく、新たな無線接続を確立することを示す応答メッセージを前記基地局から受信する受信部と、
   前記基地局から、前記第１の要求情報及び前記第２の要求情報を含む前記要求メッセージの送信を許可することを示す所定のシステム情報がブロードキャストされているか否かを判断する制御部と、を備え、
   前記送信部は、前記所定のシステム情報が前記基地局からブロードキャストされている場合に限り、前記要求メッセージを前記基地局に送信する、
   ユーザ装置。
4. セルラ通信ネットワークとの無線接続を確立し、前記無線接続を用いてセルラ通信を行うユーザ装置であって、
   前記無線接続がサスペンドされる所定状態において、前記無線接続を復旧することを要求する第１の要求情報と、新たに無線接続を確立することを要求する第２の要求情報とを含む要求メッセージを前記セルラ通信ネットワークに含まれる基地局に送信する送信部と、
   前記ユーザ装置に対応するＵＥコンテキストを前記基地局が利用可能でない場合であっても、前記要求メッセージを拒絶する拒絶メッセージを前記ユーザ装置に受信することなく、新たな無線接続を確立することを示す応答メッセージを前記基地局から受信する受信部と、を備え、
   前記送信部は、前記基地局に対して、前記第１の要求情報及び前記第２の要求情報を含む前記要求メッセージを送信する意図を通知するランダムアクセス信号を送信し、
   前記受信部は、前記ランダムアクセス信号に対する応答として、前記第１の要求情報及び前記第２の要求情報を含む前記要求メッセージの送信に用いる上りリンク無線リソースを示す割り当て情報を前記基地局から受信する、
   ユーザ装置。
5. ユーザ装置との無線接続を確立し、前記無線接続を用いてセルラ通信を行うセルラ通信ネットワークに含まれる基地局であって、
   前記無線接続がサスペンドされる所定状態において、前記無線接続を復旧することを要求する第１の要求情報と、新たに無線接続を確立することを要求する第２の要求情報とを含む要求メッセージを前記ユーザ装置から受信する受信部と、
   前記要求メッセージを送信した前記ユーザ装置に対応するＵＥコンテキストを前記基地局が利用可能でない場合であっても、前記要求メッセージを拒絶する拒絶メッセージを送信することなく、新たな無線接続を確立することを示す応答メッセージを前記ユーザ装置に送信する送信部と、を備え、
   前記受信部は、前記第１の要求情報及び前記第２の要求情報を含む前記要求メッセージを送信する意図を通知するランダムアクセス信号を前記ユーザ装置から受信し、
   前記送信部は、前記ランダムアクセス信号に対する応答として、前記第１の要求情報及び前記第２の要求情報を含む前記要求メッセージの送信に用いる上りリンク無線リソースを示す割り当て情報を前記ユーザ装置に送信する、基地局。

Images