ホーム > 特許ランキング > 財團法人工業技術研究院
知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】特開2015-122735(P2015-122735A)
(43)【公開日】2015年7月2日
(54)【発明の名称】無線リンク障害に対処する方法
(51)【国際特許分類】
H04W 76/04 20090101AFI20150605BHJP
H04W 16/32 20090101ALI20150605BHJP
H04W 72/04 20090101ALI20150605BHJP
【ＦＩ】
H04W76/04
H04W16/32
H04W72/04 111
【審査請求】有
【請求項の数】16
【出願形態】ＯＬ
【外国語出願】
【全頁数】25
(21)【出願番号】特願2014-225773(P2014-225773)
(22)【出願日】2014年11月6日
(31)【優先権主張番号】61/901,449
(32)【優先日】2013年11月8日
(33)【優先権主張国】US
(31)【優先権主張番号】14/530,841
(32)【優先日】2014年11月3日
(33)【優先権主張国】US
(71)【出願人】
【識別番号】390023582
【氏名又は名称】財團法人工業技術研究院
【氏名又は名称原語表記】ＩＮＤＵＳＴＲＩＡＬ ＴＥＣＨＮＯＬＯＧＹ ＲＥＳＥＡＲＣＨ ＩＮＳＴＩＴＵＴＥ
(74)【代理人】
【識別番号】100107766
【弁理士】
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100070150
【弁理士】
【氏名又は名称】伊東 忠彦
(74)【代理人】
【識別番号】100091214
【弁理士】
【氏名又は名称】大貫 進介
(72)【発明者】
【氏名】陳 宏鎮
(57)【要約】 （修正有）
【課題】無線通信システム内の通信デバイスにより無線リンク障害（Radio Link Failure：ＲＬＦ）に対処する方法を提供する。【解決手段】プロセス５０は、通信デバイスがデュアル接続でのＲＬＦに対処する場合に用いられる。プロセス５０は、第１の基地局（ｅＮＢ）及び第２の基地局を含む少なくとも２つの基地局に接続するステップ５１０と、第１の基地局に関するＲＬＦを検出するステップ５２０と、第１の基地局に関連するＲＬＦ原因レポートを第２の基地局へ送信するステップ５３０とを含む。
【選択図】図５
【特許請求の範囲】
【請求項1】
無線通信システム内の通信デバイスにより無線リンク障害（Radio Link Failure：ＲＬＦ）に対処する方法であって、
前記無線通信システムに含まれる第１の基地局及び第２の基地局を含む少なくとも２つの基地局に接続するステップと、
前記第１の基地局に関するＲＬＦを検出するステップと、
前記第１の基地局に関連するＲＬＦ原因レポートを前記第２の基地局へ送信するステップと、
を含む方法。
前記無線通信システムに含まれる第１の基地局及び第２の基地局を含む少なくとも２つの基地局に接続するステップと、
前記第１の基地局に関するＲＬＦを検出するステップと、
前記第１の基地局に関連するＲＬＦ原因レポートを前記第２の基地局へ送信するステップと、
を含む方法。
【請求項2】
前記ＲＬＦ原因レポートを送信した後に、前記第１の基地局とのデータの送信及び／又は受信を停止するステップ、又は、
前記ＲＬＦ原因レポートを送信した後に、前記第１の基地局への信号伝送を停止するステップ、又は、
前記第１の基地局に関する構成をリリースするステップ、
を更に含む、請求項１に記載の方法。
前記ＲＬＦ原因レポートを送信した後に、前記第１の基地局への信号伝送を停止するステップ、又は、
前記第１の基地局に関する構成をリリースするステップ、
を更に含む、請求項１に記載の方法。
【請求項3】
前記第１の基地局との無線リンクを再開するステップ、又は、
無線リソース制御（Radio Resource Control：ＲＲＣ）接続再確立プロシージャを実行するステップ、又は、
前記第１の基地局がモビリティ・マネジメント・エンティティ（ＭＭＥ）に対してインターフェースを確立しない場合に、前記第１の基地局の無効化を実行するステップ、
を更に含む、請求項１に記載の方法。
無線リソース制御（Radio Resource Control：ＲＲＣ）接続再確立プロシージャを実行するステップ、又は、
前記第１の基地局がモビリティ・マネジメント・エンティティ（ＭＭＥ）に対してインターフェースを確立しない場合に、前記第１の基地局の無効化を実行するステップ、
を更に含む、請求項１に記載の方法。
【請求項4】
前記第１の基地局との無線リンクを再開する前記ステップが更に含まれる場合に、
前記第２の基地局からコマンド又は構成を受信するステップと、
前記コマンド又は前記構成に応答して、前記第１の基地局との前記無線リンクを再開するステップと、
を含む、請求項３に記載の方法。
前記第２の基地局からコマンド又は構成を受信するステップと、
前記コマンド又は前記構成に応答して、前記第１の基地局との前記無線リンクを再開するステップと、
を含む、請求項３に記載の方法。
【請求項5】
ＲＲＣ接続再確立プロシージャを実行する前記ステップが更に含まれる場合に、
前記第１の基地局と前記第２の基地局の両方に関するＲＬＦを検出した場合、又は、モビリティ・マネジメント・エンティティ（ＭＭＥ）とのインターフェースを確立する前記第１の基地局に関するＲＬＦが検出され、後に前記第２の基地局が無効化される場合、又は、前記ＭＭＥとのインターフェースを有さない前記第１の基地局に関するＲＬＦが検出され、前記ＭＭＥに対するインターフェースを確立する前記第２の基地局が後に前記通信デバイスのＲＲＣ接続をリリースする場合、又は、ＲＬＦによりトリガされたタイマーが満了した場合、前記ＲＲＣ接続再確立プロシージャを実行するステップ、
を含む、請求項３に記載の方法。
前記第１の基地局と前記第２の基地局の両方に関するＲＬＦを検出した場合、又は、モビリティ・マネジメント・エンティティ（ＭＭＥ）とのインターフェースを確立する前記第１の基地局に関するＲＬＦが検出され、後に前記第２の基地局が無効化される場合、又は、前記ＭＭＥとのインターフェースを有さない前記第１の基地局に関するＲＬＦが検出され、前記ＭＭＥに対するインターフェースを確立する前記第２の基地局が後に前記通信デバイスのＲＲＣ接続をリリースする場合、又は、ＲＬＦによりトリガされたタイマーが満了した場合、前記ＲＲＣ接続再確立プロシージャを実行するステップ、
を含む、請求項３に記載の方法。
【請求項6】
前記第１の基地局がＭＭＥに対してインターフェースを確立しない場合に前記第１の基地局の無効化を実行する前記ステップが含まれる場合に、
前記第２の基地局からコマンド又は構成を受信するステップと、
前記コマンド又は前記構成に応答して、前記第１の基地局の無効化を実行するステップと、
を含む、請求項３に記載の方法。
前記第２の基地局からコマンド又は構成を受信するステップと、
前記コマンド又は前記構成に応答して、前記第１の基地局の無効化を実行するステップと、
を含む、請求項３に記載の方法。
【請求項7】
前記ＲＬＦ原因レポートは、前記ＲＬＦが物理的な無線リンク問題により発生したという情報、又は、ＲＬＣ再送信回数が最大再送信閾値を超えたという情報、又は、ランダムアクセスプロシージャが失敗したという情報を含む、
請求項１乃至６のいずれか一項に記載の方法。
請求項１乃至６のいずれか一項に記載の方法。
【請求項8】
無線通信システム内の第１の基地局により無線リンク障害（Radio Link Failure：ＲＬＦ）に対処する方法であって、
前記無線通信システムにおいて前記第１の基地局及び第２の基地局に接続される通信デバイスから、前記第２の基地局に関連するＲＬＦ原因レポートを受信するステップ、
を含む方法。
前記無線通信システムにおいて前記第１の基地局及び第２の基地局に接続される通信デバイスから、前記第２の基地局に関連するＲＬＦ原因レポートを受信するステップ、
を含む方法。
【請求項9】
前記ＲＬＦ原因レポートを前記第２の基地局へ転送するステップ、
を更に含む、請求項８に記載の方法。
を更に含む、請求項８に記載の方法。
【請求項10】
前記第１の基地局が前記無線通信システムのモビリティ・マネジメント・エンティティ（Mobility Management Entity：ＭＭＥ）に対するインターフェースを確立し、前記第２の基地局が前記ＭＭＥへのインターフェースを確立しない場合に、前記第２の基地局を介する前記通信デバイスへのデータ転送を停止するステップ、又は、
前記第１の基地局が前記無線通信システムのモビリティ・マネジメント・エンティティ（Mobility Management Entity：ＭＭＥ）へのインターフェースを確立し、前記第２の基地局が前記ＭＭＥへのインターフェースを確立しない場合に、別の基地局を介してデータ転送を実行するステップ、
を更に含む、請求項８又は９に記載の方法。
前記第１の基地局が前記無線通信システムのモビリティ・マネジメント・エンティティ（Mobility Management Entity：ＭＭＥ）へのインターフェースを確立し、前記第２の基地局が前記ＭＭＥへのインターフェースを確立しない場合に、別の基地局を介してデータ転送を実行するステップ、
を更に含む、請求項８又は９に記載の方法。
【請求項11】
前記第２の基地局と前記通信デバイスとの間の無線リンクを再開するように、前記通信デバイスを構成するステップ、
を更に含む、請求項８乃至１０のいずれか一項に記載の方法。
を更に含む、請求項８乃至１０のいずれか一項に記載の方法。
【請求項12】
無線リソース制御（Radio Resource Control：ＲＲＣ）接続再確立プロシージャを実行するように、前記通信デバイスを構成するステップ、又は、
前記第１の基地局が前記無線通信システムのモビリティ・マネジメント・エンティティ（Mobility Management Entity：ＭＭＥ）へのインターフェースを確立する場合に、前記第２の基地局を無効化するステップ、又は、
前記第１の基地局が前記ＭＭＥへのインターフェースを確立する場合に、無線ベアラを前記第２の基地局から前記第１の基地局へ移動するために、Ｓ１−Ｕインターフェースを切り替えるステップ、
を更に含む、請求項８乃至１０のいずれか一項に記載の方法。
前記第１の基地局が前記無線通信システムのモビリティ・マネジメント・エンティティ（Mobility Management Entity：ＭＭＥ）へのインターフェースを確立する場合に、前記第２の基地局を無効化するステップ、又は、
前記第１の基地局が前記ＭＭＥへのインターフェースを確立する場合に、無線ベアラを前記第２の基地局から前記第１の基地局へ移動するために、Ｓ１−Ｕインターフェースを切り替えるステップ、
を更に含む、請求項８乃至１０のいずれか一項に記載の方法。
【請求項13】
無線通信システム内の第１の基地局により無線リンク障害（Radio Link Failure：ＲＬＦ）に対処する方法であって、
第２の基地局から、前記第１の基地局に関連するＲＬＦ原因レポートを受信するステップ、
を含み、
前記第１の基地局及び前記第２の基地局は、前記無線通信システムの同じ通信デバイスに接続される、
方法。
第２の基地局から、前記第１の基地局に関連するＲＬＦ原因レポートを受信するステップ、
を含み、
前記第１の基地局及び前記第２の基地局は、前記無線通信システムの同じ通信デバイスに接続される、
方法。
【請求項14】
前記第１の基地局が前記無線通信システムのモビリティ・マネジメント・エンティティ（Mobility Management Entity：ＭＭＥ）に対するインターフェースを確立する場合に、前記第２の基地局を介して前記通信デバイスへデータ送信を実行するステップ、又は、
前記通信デバイスへのデータ送信を停止するステップ、
を更に含む、請求項１３に記載の方法。
前記通信デバイスへのデータ送信を停止するステップ、
を更に含む、請求項１３に記載の方法。
【請求項15】
前記通信デバイスと前記第１の基地局との間の無線リンクを再開するように、前記通信デバイスを構成するステップ、
を更に含む、請求項１３又は１４に記載の方法。
を更に含む、請求項１３又は１４に記載の方法。
【請求項16】
無線ベアラを前記第１の基地局から前記第２の基地局へ移動するために、Ｓ１−Ｕインターフェースを切り替えるステップ、又は、
Ｓ１−ＭＭＥインターフェースを前記第１の基地局から前記第２の基地局へ切り替えるステップ、又は、
無線リソース制御（Radio Resource Control：ＲＲＣ）接続再確立プロシージャを実行するように、前記通信デバイスを構成するステップ、
を更に含む、請求項１３乃至１５のいずれか一項に記載の方法。
Ｓ１−ＭＭＥインターフェースを前記第１の基地局から前記第２の基地局へ切り替えるステップ、又は、
無線リソース制御（Radio Resource Control：ＲＲＣ）接続再確立プロシージャを実行するように、前記通信デバイスを構成するステップ、
を更に含む、請求項１３乃至１５のいずれか一項に記載の方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、無線通信システム内の通信デバイスに用いられる方法に関し、より詳細には、デュアル接続における無線リンク障害に対処する方法に関する。
【背景技術】
【0002】
３ＧＰＰのリリース１２では、ユーザーのスループットを向上するためにデュアル接続が提案されている。少なくとも２つのセルへのデュアル接続は、非理想的バックホールに接続される異なるｅＮＢ（evolved Node B）により提供され、１つのｅＮＢがセルの集合を管理する場合がある。したがって、ユーザーイクイップメント（ＵＥ）は、デュアル接続モードであるときは複数のｅＮＢによりサービスを提供され得る。
【0003】
デュアル接続の枠組みのもとでは、各トラフィックタイプ、負荷状況、チャネル状況及びそれらの組合わせから成るＱｏＳ要件に応じて、トラフィック流は１つのｅＮＢにより供されることもあり、１以上のｅＮＢに分割（split）されることもある。無線ベアラの無線プロトコルがマスターｅＮＢ（以下ＭｅＮＢ）のみに位置付けられ、よってＭｅＮＢリソースしか利用できない場合、そのような無線ベアラはＭｅＮＢ固有ベアラと定義される。ＭｅＮＢ固有ベアラに関して、ＭｅＮＢは、Ｓ１−Ｕを介してＳ−ＧＷ（Serving Gateway）に接続されるＵ−ｐｌａｎｅ（ユーザープレーン）である。無線ベアラの無線プロトコルがセカンダリーｅＮＢ（以下ＳｅＮＢ）のみに位置付けられ、よってＳｅＮＢリソースしか利用できない場合、そのような無線ベアラはＳｅＮＢ固有ベアラと定義される。ＳｅＮＢ固有ベアラに関して、ＳｅＮＢは、Ｓ１−Ｕを介してＳ−ＧＷに直接的に接続される。無線ベアラの無線プロトコルがＭｅＮＢとＳｅＮＢの両方に位置付けられ、よってＭｅＮＢとＳｅＮＢの提供する無線リソースを両方とも利用できる場合、そのような無線ベアラは分割（split）（無線）ベアラと定義される。分割ベアラに関して、ＭｅＮＢは、Ｓ１−Ｕを介してＳ−ＧＷに接続されるＵ−ｐｌａｎｅである。詳細には、図１に、無線ベアラがＭｅＮＢとＳｅＮＢとに分割される構成を示す。図１は、ＭｅＮＢ及びＳｅＮＢのユーザープレーンのプロトコル階層を示す。図１では、無線ベアラＲＢのユーザープレーン・データがＭｅＮＢへ送信される。そして、共用されるＭｅＮＢのＰＤＣＰ（packet data convergence protocol）エンティティが、ユーザープレーン・データのＰＤＣＰ ＰＤＵを、ＵＥへの送信のためにＭｅＮＢの無線リンク制御（Radio Link Control：ＲＬＣ）エンティティとＳｅＮＢのＲＬＣエンティティとに送る。以上のように、分割無線ベアラを用いると、ＵＥはＭｅＮＢとＳｅＮＢの両方を介して無線ベアラのユーザープレーン・データを受信することができ、ユーザースループットが向上する。また、ＵＥは、ＭｅＮＢとＳｅＮＢの両方を介して無線ベアラのユーザープレーン・データを送信することができる。
【0004】
図２は、分割無線ベアラを用いる場合のデュアル接続のユーザープレーン・アーキテクチャを示す。図２に示すように、ＭｅＮＢはＳ１−Ｕを介してＳ−ＧＷ（serving gateway）に接続され、Ｘ２を介してＳｅＮＢに接続され、Ｕｕを介してＵＥに接続され、Ｓ１−ＭＭＥを介してＭＭＥ（mobility management entity）に接続される。デュアル接続のＭｅＮＢはＳ１−ＭＭＥインターフェースの終点であり、したがって、コアネットワーク（ＣＮ）へのモビリティ・アンカーとして機能する。デュアル接続に関与するＭｅＮＢとＳｅＮＢとの間のＸ２インターフェースは、分割無線ベアラのユーザープレーン・データのＰＤＣＰ ＰＤＵの送信を提供する。詳細には、ユーザープレーン・データは、Ｓ−ＧＷからＳ１−Ｕを介してＭｅＮＢへ送信され、ＭｅＮＢはユーザープレーン・データを、Ｘ２を介してＳｅＮＢへ分割する。このように、ＭｅＮＢとＳｅＮＢは、分割無線ベアラのユーザープレーン・データを、Ｕｕを介してＵＥへ同時に送信することができる。同様に、ＵＥは、分割無線ベアラのユーザープレーン・データをＭｅＮＢとＳｅＮＢとに同時に送信することができる。ＭＭＥ及びＳ−ＧＷの機能は当該技術分野において周知であるので、ここでは省略する。
【0005】
ＵＥとｅＮＢとの間では、無線リンク障害（Radio Link Failure：ＲＬＦ）が発生するおそれがある。ＵＥは、Ｔ３１０が満了した場合、Ｔ３００、Ｔ３０１、Ｔ３０４及びＴ３１１のいずれも動作していない間にＭＡＣからランダムアクセス障害の指摘があった場合、或いは、再送信回数が最大値に達したとＲＬＣから指摘があった場合に、ＲＬＦが検出されたと認識し得る。要するにＵＥは、物理的な無線リンク障害と、ＲＡＣＨプロシージャ障害と、再送信閾値を超えるＲＬＣ再送信とが発生した場合に、ＲＬＦが検出されたと認識する。ＵＥは、ＲＬＦを検出した後、ＡＳセキュリティが有効化されていない場合は無線リソース制御（Radio Resource Control：ＲＲＣ）接続モードを維持し、そうでない場合は、ＲＲＣ接続再確立プロシージャを開始する。
【0006】
現在の仕様によれば、ｅＮＢに関するＲＬＦが検出された場合、ＵＥはｅＮＢに対してＲＲＣ接続再確立を実行する。再確立が失敗した場合、ＵＥはＲＲＣ接続要求に対してセル（再）選択プロシージャを実行し（これにより不通が生じるおそれがある）、インターフェースＳ１−ＭＭＥはその後再確立される。しかしながら、デュアル接続では、まだ別のｅＮＢとＵＥとの間に利用可能な無線リンクが存在する可能性がある。よって、ＲＲＣ接続再確立やＳ１−ＭＭＥ再確立、Ｓ１シグナリング（Ｓ１−ＭＭＥ再確立により生じる）は不要である場合があり、不通を回避できる可能性がある。
【発明の概要】
【発明が解決しようとする課題】
【0007】
本願は、上記の課題を解決するために、デュアル接続における無線リンク障害（Radio Link Failure：ＲＬＦ）に対処する方法を提供することを目的とする。
【課題を解決するための手段】
【0008】
この目的は、請求項１，８及び１３に係る、デュアル接続における無線リンク障害（Radio Link Failure：ＲＬＦ）に対処する方法により達成される。それらの従属請求項は、対応する更なる発展及び改善に関連する。
【0009】
以下に記載する詳細な説明からより明確に理解されるように、特許請求の範囲に記載の、無線通信システムに含まれる通信デバイスにより無線リンク障害（Radio Link Failure：ＲＬＦ）に対処する方法は、無線通信システムに含まれる第１の基地局及び第２の基地局を含む少なくとも２つの基地局に接続するステップと、該第１の基地局に関するＲＬＦを検出するステップと、該第１の基地局に関連するＲＬＦ原因レポートを該第２の基地局へ送信するステップと、を含む。
【図面の簡単な説明】
【0010】
【図1】分割無線ベアラを用いる場合のＭｅＮＢ及びＳｅＮＢのユーザープレーン・プロトコル階層を示す概略図である。
【図2】分割無線ベアラを用いる場合のデュアル接続のユーザープレーン・アーキテクチャを示す概略図である。
【図3】無線通信システムの概略図である。
【図4】例示的な通信デバイスの概略図である。
【図5】本開示に係る例示的プロセスを示すフローチャートである。
【図6】本開示に係る例示的プロセスを示すフローチャートである。
【図7】本開示に係る例示的プロセスを示すフローチャートである。
【図8】例示的な実施形態の概略図である。
【図9】例示的な実施形態の概略図である。
【図10】例示的な実施形態の概略図である。
【図11】例示的な実施形態の概略図である。
【図12】例示的な実施形態の概略図である。
【図13】例示的な実施形態の概略図である。
【図14】例示的な実施形態の概略図である。
【図15】例示的な実施形態の概略図である。
【図16】例示的な実施形態の概略図である。
【図17】例示的な実施形態の概略図である。
【図18】例示的な実施形態の概略図である。
【図19】例示的な実施形態の概略図である。
【図20】例示的な実施形態の概略図である。
【図21】例示的な実施形態の概略図である。
【図22】例示的な実施形態の概略図である。
【図23】例示的な実施形態の概略図である。
【図24】例示的な実施形態の概略図である。
【図25】例示的な実施形態の概略図である。
【図26】例示的な実施形態の概略図である。
【図27】例示的な実施形態の概略図である。
【図28】例示的な実施形態の概略図である。
【図29】例示的な実施形態の概略図である。
【図30】例示的な実施形態の概略図である。
【図31】例示的な実施形態の概略図である。
【図32】例示的な実施形態の概略図である。
【図33】例示的な実施形態の概略図である。
【図34】例示的な実施形態の概略図である。
【図35】例示的な実施形態の概略図である。
【発明を実施するための形態】
【0011】
図３は、無線通信システム３０の概略図である。無線通信システム３０は、ＬＴＥ／ＬＴＥ−Ａｄｖａｎｃｅｄシステム等のモバイル通信システムであり、簡潔に言えば、少なくとも２つのネットワークノード、すなわちマスターｅＮＢ（以下ＭｅＮＢ）及びセカンダリーｅＮＢ（以下ＳｅＮＢ）と、ユーザーイクイップメント（ＵＥ）とを含む。図３は、無線通信システム３０の構造を説明するのに用いられるに過ぎず、ＵＥ及びｅＮＢの数はこれに限定されない。ＵＥは、携帯電話、コンピューターシステム、マシン型デバイス等のデバイスであってよい。ネットワークノードすなわちｅＮＢは、基地局とみなされてよい。更に、ネットワークノード及びＵＥは、送信方向に従って送信機とみなすことも受信機とみなすこともできる。例えば、アップリンク（ＵＬ）では、ＵＥが送信機であり、ネットワークノードが受信機である。ダウンリンク（ＤＬ）では、ネットワークノードが送信機であり、ＵＥが受信機である。
【0012】
図４は、例示的な通信デバイス４０の概略図である。通信デバイス４０は、図３に示されるＵＥ、ＭｅＮＢ又はＳｅＮＢであってよい。通信デバイス４０は、マイクロプロセッサや特定用途向け集積回路（Application Specific Integrated Circuit：ＡＳＩＣ）等の処理手段４００と、記憶ユニット４１０と、通信インターフェースユニット４２０とを有してよい。記憶ユニット４１０は、プログラムコード４１４を記憶可能であり処理手段４００によりアクセスされる任意のデータ記憶デバイスであってよい。記憶ユニット４１０の例としては、加入者識別モジュール（Subscriber Identity Module：ＳＩＭ）、読み出し専用メモリ（read-only memory：ＲＯＭ）、フラッシュメモリ、ランダムアクセスメモリ（random-access memory：ＲＡＭ）、ＣＤ−ＲＯＭ、磁気テープ、ハードディスク、光学データ記憶デバイスが挙げられる。通信インターフェースユニット４２０は、好ましくは無線送受信機であり、処理手段４００の処理結果に従って、ネットワーク（すなわちＥ−ＵＴＲＡＮ）と無線信号を交換することができる。
【0013】
図５は、本開示の一実施例に係るプロセス５０のフローチャートである。プロセス５０は、図３のＵＥがデュアル接続での無線リンク障害（Radio Link Failure：ＲＬＦ）に対処する場合に用いられる。プロセス５０は、プログラムコード４１４にコンパイルされて、記憶ユニット４１０に記憶されてよい。また、プロセス５０は以下のステップを含んでよい。
【0014】
ステップ５００：開始。
【0015】
ステップ５１０：第１のｅＮＢ及び第２のｅＮＢを含む少なくとも２つのｅＮＢに接続する。
【0016】
ステップ５２０：第１のｅＮＢに関するＲＬＦを検出する。
【0017】
ステップ５３０：第１のｅＮＢに関連するＲＬＦ原因レポートを第２のｅＮＢへ送信する。
【0018】
ステップ５４０：終了。
【0019】
プロセス５０によれば、信号品質の低さを要因とするＲＬＦ又はネットワーク輻輳を要因とするＲＡＣＨプロシージャ障害を、デュアル接続に関与するｅＮＢのうち１つに検出した場合、ＵＥはすぐには無線リソース制御（Radio Resource Control：ＲＲＣ）接続再確立を実行せずに、ＲＬＦを有するｅＮＢに関連するＲＬＦ原因レポートを送信して、ＲＬＦを有さない他のｅＮＢに通知する。すなわち本発明が提案するのは、デュアル接続に含まれるＵＥを対象とする新しいＲＬＦ対処プロセスであり、ＵＥとの間で利用可能な無線リンクを有するｅＮＢがひとつでもある場合は、不通を引き起こすおそれのあるＲＲＣ接続再確立のトリガを回避する。
【0020】
ＲＬＦ原因レポートは、例えば以下の情報を含んでよい。
【0021】
ＲＬＦ原因Ａは、物理的な無線リンク問題を示す。
【0022】
ＲＬＦ原因Ｂは、ＲＬＣ再送信が最大再送信閾値を超えたことを示す。
【0023】
ＲＬＦ原因Ｃは、ＲＡＣＨプロシージャの失敗を示す。
【0024】
ＵＥがＲＲＣ接続再確立プロシージャを実行するのは、デュアル接続に関与する全てのｅＮＢに関してＲＬＦが検出された場合、ＭｅＮＢに関するＲＬＦが検出されその後ＳｅＮＢが無効化された場合、ＳｅＮＢに関するＲＬＦが検出されその後ＭｅＮＢがＵＥとのＲＲＣ接続をリリースした場合、或いは、ＲＬＦによりトリガされたタイマーが満了した場合のみである。
【0025】
更に、ＵＥは、ＲＬＦ原因レポートをＲＬＦを有さないｅＮＢへ通知した後、ＲＬＦを有するｅＮＢとのデータ／信号（すなわちＳＲＳ（sounding reference signal））の送受信を停止し、ＲＬＦを有するｅＮＢに関連する構成（すなわちＳＲＳ構成又はＣＳＩ構成）をリリースしてよい。代替的に、ＵＥは、ＲＬＦを有するｅＮＢの測定を実行して、ＲＬＦを有するｅＮＢとの無線リンクを再開するか否かを決定してよい。
【0026】
図６は、本開示の一実施例に係るプロセス６０のフローチャートである。プロセス６０は、第１のｅＮＢ（すなわち図３のＭｅＮＢ又はＳｅＮＢ）がデュアル接続での無線リンク障害（Radio Link Failure：ＲＬＦ）に対処する場合に用いられる。プロセス６０はプログラムコード４１４にコンパイルされて、記憶ユニット４１０に記憶されてよい。また、プロセス６０は、以下のステップを含んでよい。
【0027】
ステップ６００：開始。
【0028】
ステップ６１０：デュアル接続に関与する第２のｅＮＢに関連するＲＬＦ原因レポートをＵＥから受信する。
【0029】
ステップ６２０：終了。
【0030】
プロセス６０によれば、ＲＬＦを有さない第１のｅＮＢは、ＲＬＦを有する第２のｅＮＢに関連するＲＬＦ原因レポートをＵＥから受信する。更に、第１のｅＮＢは、ＲＬＦ原因レポートを第２のｅＮＢへ（すなわち、図２のＸ２インターフェースを介して）転送してよい。
【0031】
第２のｅＮＢが図２のＭＭＥに対するＳ１−ＭＭＥインターフェースを確立するＭｅＮＢでなく、第１のｅＮＢがＭｅＮＢである場合、第１のｅＮＢは、第２のｅＮＢを介するデータ転送を停止してよい。更に、第１のｅＮＢは、第２のｅＮＢを測定しＲＬＦ原因が消失したか否かを決定するために、測定コマンドをＵＥへ送信して、第２の基地局とＵＥとの間の無線リンクを回復してよい。代替的に、第１のｅＮＢは、ＱｏＳ要件、システム付加及び／又は第１のｅＮＢのバックホール待ち時間に基づいて、無線ベアラを第２のｅＮＢから第１のｅＮＢへ切り替えてもよいし、ＲＲＣ接続再確立を実行するようにＵＥを構成してもよいし、第２のｅＮＢを無効化してもよい。
【0032】
図７は、本開示の一実施例に係るプロセス７０のフローチャートである。プロセス７０は、第１のｅＮＢ（すなわち図３のＭｅＮＢ又はＳｅＮＢ）がデュアル接続での無線リンク障害（ＲＬＦ）に対処する場合に用いられる。プロセス７０は、プログラムコード４１４にコンパイルされて、記憶ユニット４１０に記憶されてよい。また、プロセス７０は以下のステップを含んでよい。
【0033】
ステップ７００：開始。
【0034】
ステップ７１０：第１のｅＮＢに関連するＲＬＦ原因レポートを、デュアル接続に関与する第２のｅＮＢから受信する。
【0035】
ステップ７２０：終了。
【0036】
プロセス７０によれば、第１のｅＮＢは、第１のｅＮＢに関連するＲＬＦ原因レポートを第２のｅＮＢから受信する。第１のｅＮＢがＭｅＮＢである場合、第１のｅＮＢは第２のｅＮＢを介してデータを送信してよい。更に、第１のｅＮＢは、ＱｏＳ要件、システム付加及び／又は第１のｅＮＢのバックホール待ち時間に基づいて、ＵＥとの無線リンクを回復してもよいし、第１のｅＮＢの無線ベアラのＳ１−Ｕ及びＳ１−ＭＭＥを第１のｅＮＢから第２のｅＮＢへ切り替えてもよいし、ＲＲＣ接続再確立を実行するようにＵＥを構成してもよい。代替的に、第１のｅＮＢがＳｅＮＢである場合、第１のｅＮＢは、ＵＥへのデータ送信を停止してよい。
【0037】
図８〜３５は、デュアル接続に関与するＵＥ、ＭｅＮＢ及びＳｅＮＢのＲＬＦオペレーションの詳細を示す。なお、本発明は、デュアル接続におけるＲＬＦに対処する最適化された方法を開示し、分割無線ベアラ又は非分割無線ベアラをサポートするｅＮＢに適用可能である。更に、ＭｅＮＢ及びＳｅＮＢには２つの制御プレーンオプションがある。第１の制御プレーンオプションでは、ＭｅＮＢのみが、ＭｅＮＢとＳｅＮＢとの無線リソース管理（Radio Resource Management：ＲＲＭ）機能の連携の後に、ＵＥへ送信される最終的なＲＲＣメッセージを生成する。ＵＥのＲＲＣエンティティは、（ＭｅＮＢの）１つのエンティティのみから来るメッセージを全て確認し、ＵＥは当該エンティティのみに対して返信を行う。第２の制御プレーンオプションでは、ＭｅＮＢ及びＳｅＮＢが、ＭｅＮＢとＳｅＮＢとのＲＲＭ機能の連携の後に、ＵＥへ送信される最終的なＲＲＣメッセージを生成することができる。ＲＲＣメッセージはＵＥへ直接的に送信されてよく、また、ＵＥはそれに従って返信を行ってよい。
【0038】
第１の実施形態において、ＭｅＮＢは分割無線ベアラをサポートする。アーキテクチャについては、図１〜２を参照することができる。以下の実施形態では、ＭｅＮＢ及びＳｅＮＢの第２の制御プレーンオプションが採用される。詳細には、図８に、デュアル接続におけるＲＬＦオペレーションの実施形態を示す。図８では、ＵＥはＭｅＮＢ側に。その後、ＭｅＮＢはＵＥに対してＳｅＮＢを追加して、ＵＥをデュアル接続状態とする。デュアル接続において、ＭｅＮＢとＳｅＮＢは、ＵＥにサービスを提供するために、連携して情報交換を行う必要がある。ＵＥは、ＭｅＮＢに関するＲＬＦを検出すると、ＭｅＮＢとの送受信を停止し、上述のＲＬＦ原因Ａ又はＢ（すなわち、物理的な無線リンク問題、又は、最大再送信閾値を超えるＲＬＣ再送信を示す）を含むＲＬＦ原因レポート（RLF Cause Report）をＳｅＮＢへ送信してよい。ＳｅＮＢは、ＲＬＦ原因レポートの情報をＭｅＮＢへ転送する。ＭｅＮＢは、ＲＬＦが信号品質の低さを原因として発生したのか否かを確認する。そうであれば、ＭｅＮＢとＵＥとの間のデータ／信号は、ＳｅＮＢを介して送信される。更にＳｅＮＢは、ＭｅＮＢを測定するために、測定コマンド（Measurement Command）をＵＥへ送信する。ＭｅＮＢの測定結果がレポート閾値を超えることをＵＥが検出した場合、ＵＥは測定レポート（Measurement Report）をＳｅＮＢへ送信し、ＳｅＮＢは、無線リンク回復（Radio Link Recovery：ＲＬＲ）メッセージによりＭｅＮＢに通知する。ＭｅＮＢは、ＳｅＮＢからＲＬＲメッセージを受信した後、ＵＥへのＤＬ送信を再開することを決定した場合、ＳｅＮＢを介して再開コマンド（Resume Command）をＵＥへ送信して、ＵＥとの無線リンクを回復する。
【0039】
図９に示されるような実施形態では、ＭｅＮＢは、ＳｅＮＢからＲＬＲメッセージを受信した後、ＵＥへのＤＬ送信を再開することを決定した場合、ＵＥの構成の一部が変更される必要があれば、ＳｅＮＢを介して当該ＭｅＮＢの再構成をＵＥへ送信して、ＵＥとの無線リンクを回復する。
【0040】
図９の実施形態とは異なり、図１０の実施形態では、ＵＥがＭｅＮＢに関するＲＬＦを検出すると、ＭｅＮＢとの送受信を停止し、ＭｅＮＢの一部の構成（例えば、ＳＲＳ構成及びＣＳＩ構成）をリリースする。
【0041】
図１１に示される実施形態において、ＭｅＮＢがＳｅＮＢからＲＬＦ原因レポートを受信した後、ＵＥへのＤＬ送信を再開することを決定した場合、まずＭｅＮＢが再開指示（Resume Indication）をＳｅＮＢへ送信し、それからＳｅＮＢが測定コマンドをＵＥへ送信する。
【0042】
上述した図８〜１１の実施形態とは異なり、第１の制御プレーンオプションが適用されると、ＭｅＮＢがＵＥとの間で送受信される全てのＲＲＣメッセージを理解し生成する。詳細には、図１２に示すように、ＵＥはＭｅＮＢに関するＲＬＦを検出した場合、ＭｅＮＢへの送信を停止し、ＲＬＦ原因レポートをＳｅＮＢへ送信してよい。ＳｅＮＢは、このＲＬＦ原因レポートをＭｅＮＢへ直接転送する。ＲＬＦ原因レポートがＲＬＦ原因Ａ又はＢを含むとすると、ＭｅＮＢは、ＲＬＦが信号品質の低さを原因として発生したのか否かを確認する。そうである場合、ＭｅＮＢとＵＥとの間のデータ及び信号は、ＳｅＮＢを介して送信される。更に、ＭｅＮＢは、ＳｅＮＢを介して測定コマンドをＵＥへ送信して、ＵＥにＭｅＮＢ自体を測定させる。ＭｅＮＢの測定結果がレポート閾値を超えることをＵＥが検出した場合、ＵＥは測定レポートをＳｅＮＢへ送信し、ＳｅＮＢは、この測定レポートをＭｅＮＢへ直接転送する。図１２に示される後続のＭｅＮＢ、ＳｅＮＢ及びＵＥの動作については、上記を参照することができるので、ここでは省略する。
【0043】
図１３の実施形態において、ＵＥがＭｅＮＢに関するＲＬＦを検出した後、更にＳｅＮＢに関するＲＬＦを検出した（すなわち、ＭｅＮＢとＳｅＮＢの両方に関してＲＬＦが検出された）場合、ＵＥは、ＲＲＣ接続再確立プロシージャを実行する。
【0044】
図１４の実施形態において、ＵＥは、ＲＬＦ原因レポートを送信した後に、ＲＲＣ接続再確立プロシージャに向けたタイマーを開始してよい。ＲＲＣ接続再確立プロシージャに向けたタイマーが満了した（すなわち、タイムアップした）場合、ＵＥは、ＲＲＣ接続再確立プロシージャを実行する。タイマーは予め定められてもよいし、ＭｅＮＢ又はＳｅＮＢにより専用のメッセージから割り当てられてもよいし、ＭｅＮＢ又はＳｅＮＢによりブロードキャストされてもよい。
【0045】
上述した図８〜１４の実施形態とは異なり、図１５の実施形態では、ＲＬＦ原因レポートはＲＬＦ原因Ｃ（すなわち、ＲＡＣＨプロシージャの失敗を示す）を含む。ＭｅＮＢは、ＲＬＦがネットワーク輻輳により発生したのか否かを確認する。そうである場合、ＭｅＮＢとＵＥとの間のデータ及び信号は、ＳｅＮＢを介して送信される。また、ＭｅＮＢの輻輳が緩和された場合、ＭｅＮＢはＭｅＮＢ有効化指示（MeNB Activation Indication）をＳｅＮＢへ送信し、ＳｅＮＢはこのＭｅＮＢ有効化指示をＵＥへ転送する。ＵＥは、ＭｅＮＢ有効化指示を受信した後、ＭｅＮＢに対して有効化プロシージャを実行する。
【0046】
図１６の実施形態において、ＵＥは、ＲＬＦ原因レポートを送信した後、更にＳｅＮＢに関するＲＬＦを検出した（すなわち、ＭｅＮＢとＳｅＮＢの両方に関してＲＬＦが発生する）場合、ＲＲＣ接続再確立プロシージャを実行する。
【0047】
上述した図８〜１６の実施形態とは異なり、ＲＬＦは、ＭｅＮＢではなくＳｅＮＢで検出されてよい。詳細には、図１７に示すように、ＵＥはＳｅＮＢに関するＲＬＦを検出した場合、ＳｅＮＢとの送受信を停止し、ＲＬＦ原因Ａ又はＢを含むＲＬＦ原因レポートをＭｅＮＢへ送信してよい。ＭｅＮＢは、ＲＬＦ原因レポートの情報をＳｅＮＢへ転送してよい。更に、ＭｅＮＢは、ＳｅＮＢを介したＵＥへのデータ及び信号の送信を停止する。ＳｅＮＢはまた、ＵＥへのＤＬデータ送信を停止する。ＭｅＮＢはまた、ＳｅＮＢを測定するために、測定コマンドをＵＥへ送信する。ＳｅＮＢの測定結果がレポート閾値を超えることをＵＥが検出した場合、ＵＥは測定レポートをＭｅＮＢへ送信し、ＭｅＮＢはＲＬＲ指示によりＳｅＮＢに通知する。ＳｅＮＢは、ＵＥへのＤＬ送信を再開することを決定した場合、ＲＬＲ ＡＣＫをＭｅＮＢへ送信する。ＭｅＮＢは、ＳｅＮＢからＲＬＲ ＡＣＫを受信した後、再開コマンドをＵＥへ送信して、無線リンクを回復する。
【0048】
代替的に、図１８では、ＵＥはＳｅＮＢに関するＲＬＦを検出すると、ＳｅＮＢとの送受信を停止し、ＲＬＦ原因レポートをＭｅＮＢへ送信する。ＭｅＮＢは、ＳｅＮＢ排除コマンド（SeNB Removal Command）を送信して、ＳｅＮＢを無効化してよい。
【0049】
第２の実施形態において、ＭｅＮＢは、図１９に示す分割無線ベアラＲＢ１及びＭｅＮＢ固有ベアラＲＢ２をサポートする。また、第２の制御プレーンオプションが適用される。詳細には、図２０に示すように、ＵＥはＭｅＮＢに関するＲＬＦを検出した場合、ＭｅＮＢへの送信を停止し、ＲＬＦ原因Ａ又はＢを含むＲＬＦ原因レポートをＳｅＮＢへ送信してよい。ＳｅＮＢは、ＲＬＦ原因レポートの情報をＭｅＮＢへ転送する。ＭｅＮＢは、ＲＬＦが信号品質の低さを原因として発生したのか否かを確認し、また、ＭｅＮＢ固有ベアラの要件がＳｅＮＢを介するデータ送信中に満たされ得るかを確認する。ＭｅＮＢ固有ベアラの要件がＳｅＮＢを介するデータ送信中に満たされ得る場合、ＭｅＮＢは、ベアラ・ハンドオーバー要求（Bearer HO Request）をＳｅＮＢへ送信する。ＳｅＮＢによりベアラ・ハンドオーバーＡＣＫ（Bearer HO ACK）が返されると、ＭｅＮＢとＵＥとの間のデータ及び信号は、ＳｅＮＢを介して送信される。また、ＭｅＮＢを測定するために、ＳｅＮＢは測定コマンドをＵＥへ送信する。ＭｅＮＢの測定結果がレポート閾値を超えることをＵＥが検出した場合、ＵＥは測定レポートをＳｅＮＢへ送信し、ＳｅＮＢはＲＬＲメッセージによりＭｅＮＢに通知する。ＭｅＮＢは、ＳｅＮＢからＲＬＲメッセージを受信した後、ＵＥへのＤＬ送信を再開することを決定した場合、再構成をＳｅＮＢを介してＵＥへ送信して、無線リンクを回復する。更に、ＭｅＮＢは、別のベアラ・ハンドオーバー要求（Bearer HO Request）をＳｅＮＢへ送信して、一部の無線ベアラを自身に切替復帰させてよい。
【0050】
代替的に、図２１に示すように、ＭｅＮＢ固有ベアラの要件がＳｅＮＢを介するデータ送信中に満たされ得る場合であっても、ＳｅＮＢはベアラ・ハンドオーバーＮＡＣＫ（Bearer HO NACK）を返してよい。その場合、ＭｅＮＢはＳｅＮＢ排除コマンドをＳｅＮＢへ送信する。ＳｅＮＢは、このＳｅＮＢ排除コマンドを受信した後、それに応じてＲＲＣ接続リリース（RRC Connection Release）を送信する。ＵＥは、ＭｅＮＢにまだＲＬＦが存在する間にＳｅＮＢからＲＲＣ接続リリースを受信した場合、ＲＲＣ接続再確立プロシージャを実行する。
【0051】
図２２の実施形態において、ＳｅＮＢがベアラ・ハンドオーバーＮＡＣＫ（Bearer HO NACK）を返す場合、ＭｅＮＢは経路切替プロシージャを実行して、Ｓ１−ＭＭＥをＭｅＮＢからＳｅＮＢに切り替える（すなわち、ＭｅＮＢとＵＥとの間のＳ１−ＭＭＥを除去し、新しいＳ１−ＭＭＥをＳｅＮＢとＵＥとの間で確立する）。
【0052】
図２３の実施形態において、ＭｅＮＢ固有ベアラの要件がＳｅＮＢを介するデータ送信中に満たされ得ない場合、ＭｅＮＢはＳｅＮＢ排除コマンドをＳｅＮＢへ送信する。ＳｅＮＢは、このＳｅＮＢ排除コマンドを受信した後、それに応じてＲＲＣ接続リリースを送信する。ＵＥは、ＭｅＮＢにまだＲＬＦが存在する間にＳｅＮＢからＲＲＣ接続リリースを受信した場合、ＲＲＣ接続再確立プロシージャを実行する。
【0053】
図２４の実施形態において、ＭｅＮＢ固有ベアラの要件がＳｅＮＢを介するデータ送信中に満たされ得ない場合、ＭｅＮＢは経路切替プロシージャを実行して、Ｓ１−ＭＭＥをＭｅＮＢからＳｅＮＢに切り替える（すなわち、ＭｅＮＢとＵＥとの間のＳ１−ＭＭＥを除去し、新しいＳ１−ＭＭＥをＳｅＮＢとＵＥとの間で確立する）。
【0054】
図２０〜２４の実施形態とは異なり、図２５の実施形態では、ＲＬＦ原因レポートはＲＬＦ原因Ｃを含む。ＭｅＮＢは、ＲＬＦがネットワーク輻輳により発生したのか否かを確認し、また、ＭｅＮＢ固有ベアラの要件がＳｅＮＢを介するデータ送信中に満たされ得るかを確認する。ＭｅＮＢ固有ベアラの要件がＳｅＮＢを介するデータ送信中に満たされ得る場合、ＭｅＮＢは、ベアラ・ハンドオーバー要求（Bearer HO Request）をＳｅＮＢへ送信する。ＳｅＮＢによりベアラ・ハンドオーバーＡＣＫ（Bearer HO ACK）が返されると、ＭｅＮＢとＵＥとの間のデータ及び信号は、ＳｅＮＢを介して送信される。一方、ＭｅＮＢの輻輳が緩和された場合、ＭｅＮＢはＭｅＮＢ有効化指示を送信し、ＳｅＮＢはこのＭｅＮＢ有効化指示をＵＥへ転送する。ＵＥは、ＭｅＮＢ有効化指示を受信した後、ＭｅＮＢに対して有効化プロシージャを実行する。
【0055】
一方、図２６では、ＳｅＮＢがベアラ・ハンドオーバーＮＡＣＫ（Bearer HO NACK）を返した場合、ＭｅＮＢはＳｅＮＢ排除コマンドをＳｅＮＢへ送信する。ＳｅＮＢは、このＳｅＮＢ排除コマンドを受信した後、それに応じてＲＲＣ接続リリースを送信する。ＵＥは、ＭｅＮＢにまだＲＬＦが存在する間にＳｅＮＢからＲＲＣ接続リリースを受信した場合、ＲＲＣ接続再確立プロシージャを実行する。
【0056】
図２７の実施形態において、ＭｅＮＢは、ＭｅＮＢ固有ベアラの要件がＳｅＮＢを介するデータ送信中に満たされ得るか否かを確認してよい。ＭｅＮＢ固有ベアラの要件がＳｅＮＢを介するデータ送信中に満たされ得る場合、ＭｅＮＢは、ベアラ・ハンドオーバー要求（Bearer HO Request）をＳｅＮＢへ送信する。ＳｅＮＢがベアラ・ハンドオーバーＮＡＣＫ（Bearer HO NACK）を返した場合、ＭｅＮＢは経路切替プロシージャを実行して、Ｓ１−ＭＭＥをＭｅＮＢからＳｅＮＢに切り替える（すなわち、Ｓ１−ＭＭＥはＳｅＮＢとＵＥとの間に確立される）。
【0057】
代替的に、図２８では、ＭｅＮＢ固有ベアラの要件がＳｅＮＢを介するデータ送信中に満たされ得ない場合、ＭｅＮＢはＳｅＮＢ排除コマンドをＳｅＮＢへ送信する。ＳｅＮＢは、このＳｅＮＢ排除コマンドを受信した後、それに応じてＲＲＣ接続リリースを送信する。ＵＥは、ＭｅＮＢにまだＲＬＦが存在する間にＳｅＮＢからＲＲＣ接続リリースを受信した場合、ＲＲＣ接続再確立プロシージャを実行する。
【0058】
図２９の実施形態において、ＭｅＮＢ固有ベアラの要件がＳｅＮＢを介するデータ送信中に満たされ得ない場合、ＭｅＮＢは経路切替プロシージャを実行して、Ｓ１−ＭＭＥをＭｅＮＢからＳｅＮＢに切り替える（すなわち、Ｓ１−ＭＭＥはＳｅＮＢとＵＥとの間に確立される）。
【0059】
図３０に示す第３の実施形態では、ｅＮＢはＭｅＮＢ固有ベアラ及びＳｅＮＢ固有ベアラのみをサポートし、分割無線ベアラをサポートしない。また、第２の制御プレーンオプションが適用される。詳細には、図３１に示すように、ＵＥはＭｅＮＢに関するＲＬＦを検出した場合、ＭｅＮＢへの送信を停止し、ＲＬＦ原因Ａ又はＢを含むＲＬＦ原因レポートをＳｅＮＢへ送信してよい。ＳｅＮＢは、ＲＬＦ原因レポートの情報をＭｅＮＢへ転送する。ＭｅＮＢは、ＲＬＦが信号品質の低さを原因として発生したのか否かを確認する。そうである場合、ＭｅＮＢは、ベアラ・ハンドオーバー要求（Bearer HO Request）をＳｅＮＢへ送信する。ＳｅＮＢによりベアラ・ハンドオーバーＡＣＫ（Bearer HO ACK）が返されると、経路切替プロシージャ（ＭｅＮＢからＭＭＥへのベアラ経路切替要求（ベアラ経路をＭｅＮＢからＳｅＮＢへ変更することをＳ−ＧＷに通知するため）と、ＭＭＥからＭｅＮＢへのベアラ経路切替ＡＣＫと、ＭｅＮＢからＳｅＮＢへのベアラ経路切替ＡＣＫの転送（ベアラ経路切替の完了を通知するため）とを含む）が実行されて、無線ベアラをＭｅＮＢからＳｅＮＢへ移動するＳ−ＧＷに通知される。更に、ＭｅＮＢを測定するために、ＳｅＮＢは測定コマンドをＵＥへ送信する。ＭｅＮＢの測定結果がレポート閾値を超えることをＵＥが検出した場合、ＵＥは測定レポートをＳｅＮＢへ送信し、ＳｅＮＢはＲＬＲメッセージによりＭｅＮＢに通知する。ＭｅＮＢは、ＳｅＮＢからＲＬＲメッセージを受信した後、ＵＥへのＤＬ送信を再開することを決定した場合、再構成をＳｅＮＢを介してＵＥへ送信して、無線リンクを回復する。
【0060】
代替的に、図３２では、ＳｅＮＢがベアラ・ハンドオーバーＮＡＣＫ（Bearer HO NACK）を返した場合、ＭｅＮＢはＳｅＮＢ排除コマンドをＳｅＮＢへ送信する。ＳｅＮＢは、このＳｅＮＢ排除コマンドを受信した後、それに応じてＲＲＣ接続リリースを送信する。ＵＥは、ＭｅＮＢにまだＲＬＦが存在する間にＳｅＮＢからＲＲＣ接続リリースを受信した場合、ＲＲＣ接続再確立プロシージャを実行する。
【0061】
図３１及び３２の実施形態とは異なり、図３３に示すように、ＲＬＦ原因レポートはＲＬＦ原因Ｃを含む。ＭｅＮＢは、ＲＬＦがネットワーク輻輳により発生したのか否かを確認する。そうである場合、ＭｅＮＢはベアラ・ハンドオーバー要求をＳｅＮＢへ送信する。ＳｅＮＢによりベアラ・ハンドオーバーＡＣＫ（Bearer HO ACK）が返されると、経路切替プロシージャ（ＭｅＮＢからＭＭＥへのベアラ経路切替要求（ベアラ経路をＭｅＮＢからＳｅＮＢへ変更することをＳ−ＧＷに通知するため）と、ＭＭＥからＭｅＮＢへのベアラ経路切替ＡＣＫと、ＭｅＮＢからＳｅＮＢへのベアラ経路切替ＡＣＫの転送（ベアラ経路切替の完了を通知するため）とを含む）が実行されて、ベアラをＭｅＮＢからＳｅＮＢへ移動させるＳ−ＧＷに通知する。また、ＭｅＮＢの輻輳が緩和された場合、ＭｅＮＢはＭｅＮＢ有効化指示を送信し、ＳｅＮＢはこのＭｅＮＢ有効化指示をＵＥへ転送する。ＵＥは、ＭｅＮＢ有効化指示を受信した後、ＭｅＮＢに対して有効化プロシージャを実行する。
【0062】
一方、図３４に示すように、ＳｅＮＢがベアラ・ハンドオーバーＮＡＣＫ（Bearer HO NACK）を返した場合、ＭｅＮＢはＳｅＮＢ排除コマンドをＳｅＮＢへ送信する。ＳｅＮＢは、このＳｅＮＢ排除コマンドを受信した後、それに応じてＲＲＣ接続リリースを送信する。ＵＥは、ＭｅＮＢにまだＲＬＦが存在する間にＳｅＮＢからＲＲＣ接続リリースを受信した場合、ＲＲＣ接続再確立プロシージャを実行する。
【0063】
図３５の実施形態において、ＭｅＮＢは、ＲＬＦ原因レポートを受信した後、ベアラをＳｅＮＢへ切り替えないと決定した場合、ＳｅＮＢ排除コマンドをＳｅＮＢへ送信する。ＳｅＮＢは、このＳｅＮＢ排除コマンドを受信した後、それに応じてＲＲＣ接続リリースを送信する。ＵＥは、ＭｅＮＢにまだＲＬＦが存在する間にＳｅＮＢからＲＲＣ接続リリースを受信した場合、ＲＲＣ接続再確立プロシージャを実行する。
【0064】
上述のプロセスのステップ（示唆されるステップを含む）は、ハードウェア、ファームウェア（ハードウェアデバイスと、読み出し専用ソフトウェアとしてハードウェアデバイス上に存在するコンピューター命令及びデータとの組み合わせとして知られる）、電子システム等の手段により実現することができる。ハードウェアの例としては、超小型回路、マイクロチップ又はシリコンチップとして知られるアナログ回路、デジタル回路、混合回路が挙げられる。電子システムの例としては、システム・オン・チップ（ＳｏＣ）、システム・イン・パッケージ（ＳｉＰ）、コンピューター・オン・モジュール（ＣｏＭ）、通信デバイス４０が挙げられる。
【0065】
結論として、本発明は、デュアル接続システムのＲＬＦに関する不便な点に対処する。ＵＥは、ＵＥとデュアル接続に関与するｅＮＢとの間にまだ利用可能な無線リンクが存在する場合に、不要なＲＲＣ接続再確立プロシージャの実行を回避し、Ｓ１シグナリング及び不通を低減するものである。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26】
【図27】
【図28】
【図29】
【図30】
【図31】
【図32】
【図33】
【図34】
【図35】
【外国語明細書】