(57)【要約】無線通信ネットワークにおけるハンドオーバのための方法が、ターゲット・ネットワーク・ノードとソース・ネットワーク・ノードの間で、ソース・ネットワーク・ノードが、ハンドオーバに先立つ、ハンドオーバ中の、またはハンドオーバ後の障害のタイプを識別し、区別することを可能にする情報を通信するステップを含む。この情報は、ハンドオーバに先立つＲＬＦ、またはソース・セルにおいて経験されるハンドオーバ・コマンド障害に起因して「ハンドオーバ・コマンドが受信されない」こと、あるいは「ハンドオーバ・コマンドが受信された」後にターゲット・セルにおいてアクセス障害が生じたことと関係することが可能である。この方法は、例えば、ＬＴＥに準拠するネットワークに適用可能である。
2011530912.tif 000002
【特許請求の範囲】
【請求項１】
無線通信ネットワークにおけるハンドオーバのための方法であって、
ターゲット・ネットワーク・ノードとソース・ネットワーク・ノードの間で、前記ソース・ネットワーク・ノードが、ハンドオーバと関係する障害を識別することを可能にする情報を通信するステップを含む方法。
【請求項２】
ハンドオーバに先立って、ハンドオーバ中に、またはハンドオーバ後に生じたハンドオーバ障害タイプを識別し、区別する請求項１に記載の方法。
【請求項３】
前記情報は、予期されるハンドオーバに先立ってＵＥ（移動端末装置）によってハンドオーバ・コマンド・メッセージが受信されないＲＬＦ（無線リンク障害）と関係する請求項１または２に記載の方法。
【請求項４】
前記情報は、前記ソース・セルにおいて経験されるハンドオーバ・コマンド障害に起因するＲＬＦと関係する請求項１、２、または３のいずれか１項に記載の方法。
【請求項５】
前記情報は、ハンドオーバ・コマンド・メッセージがＵＥによって受信され、その後、前記ターゲット・セルにおけるアクセス障害が生じるハンドオーバ失敗と関係する請求項１、２、３、または４のいずれか１項に記載の方法。
【請求項６】
前記情報は、さらなる目的を有するメッセージの中に含められる請求項１乃至５のいずれか１項に記載の方法。
【請求項７】
前記情報は、選択されたネットワーク・ノードから前記ソース・ネットワーク・ノードに送信され、別の目的を果たさないメッセージによって通信される請求項１乃至５のいずれか１項に記載の方法。
【請求項８】
前記ネットワークは、ＬＴＥ標準に準拠して実施される請求項１乃至７のいずれか１項に記載の方法。
【請求項９】
前記情報は、Ｘ２インタフェース・メッセージの中に含められ、前記Ｘ２インタフェース・メッセージは、さらなる目的を有する請求項８に記載の方法。
【請求項１０】
前記情報は、Ｘ２インタフェースＵＥコンテキスト解放メッセージの拡張部分の中に含められる請求項９に記載の方法。
【請求項１１】
前記情報は、ハンドオーバ・パラメータを適合させるように使用される請求項１乃至１０のいずれか１項に記載の方法。
【請求項１２】
ＲＬＦが生じたセルと、前記無線リンクが再確立されるセルの少なくともいずれかを識別する識別データを、前記通信される情報と一緒に送信するステップを含む請求項１乃至１１のいずれか１項に記載の方法。
【請求項１３】
請求項１乃至１２のいずれか１項に記載の方法に従って実施される無線通信ネットワーク。
【請求項１４】
無線通信ネットワークのためのネットワーク・ノードであって、
ソース・ネットワーク・ノードからのハンドオーバ手順中にターゲット・ネットワーク・ノードである場合に、前記ソース・ネットワーク・ノードにハンドオーバ障害情報を通信するための手段を備えるネットワーク・ノード。
【請求項１５】
前記ハンドオーバ障害情報は、予期されるハンドオーバに先立ってＵＥ（移動端末装置）によってハンドオーバ・コマンド・メッセージが受信されないＲＬＦ（無線リンク障害）、前記ソース・セルにおいて経験されるハンドオーバ・コマンド障害に起因するＲＬＦ、およびハンドオーバ・コマンド・メッセージがＵＥによって受信され、その後、前記ターゲット・セルにおけるアクセス障害が生じるハンドオーバ失敗と関係する情報の少なくともいずれかを含む請求項１３に記載のネットワーク・ノード。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、無線通信ネットワークにおけるハンドオーバのための方法および装置に関し、より詳細には、排他的にではなく、３ＧＰＰ（３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ）のＥ−ＵＴＲＡＮ（ｅｖｏｌｖｅｄ  Ｕｎｉｖｅｒｓａｌ  Ｔｅｒｒｅｓｔｒｉａｌ  Ｒａｄｉｏ  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ）規格およびＥ−ＵＴＲＡ（ｅｖｏｌｖｅｄ  Ｕｎｉｖｅｒｓａｌ  Ｔｅｒｒｅｓｔｒｉａｌ  Ｒａｄｉｏ  Ａｃｃｅｓｓ）規格に従って実施される方法および装置に関する。
【背景技術】
【０００２】
現在、３ＧＰＰは、参照により本明細書に組み込まれている技術規格３ＧＰＰ  ＴＳ３６．３００ｖ８．４．０（２００８年３月）、ならびに関連文書に記載されるＥ−ＵＴＲＡおよびＥ−ＵＴＲＡＮの開発を考慮している。３ＧＰＰ  ＬＴＥ（Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ）は、例えば、効率およびサービスを向上させることによって、ＵＭＴＳ（Ｕｎｉｖｅｒｓａｌ  Ｍｏｂｉｌｅ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ｓｙｓｔｅｍ）標準を強化することを目指す。
【０００３】
Ｅ−ＵＴＲＡＮにおいて、ＵＥ（ユーザ機器）は、ネットワーク・ノード、ｅＮＢ（ノードＢ）と通信し、データは、ＵＥ、ネットワーク・ノード、およびｅＮＢの間で無線リンクを介してＲＢ（無線ベアラ）上で送信される。ｅＮＢは、Ｓ１と呼ばれるインタフェースを介してＭＭＥ（移動体管理エンティティ）とインタフェースをとる。Ｅ−ＵＴＲＡＮネットワークは、複数のｅＮＢおよびＭＭＥを含み、ＵＥは、例えば、フェージングチャネル条件下で、またはＵＥが１つのセルカバレッジエリアから別のセルカバレッジエリアに移動している場合に、最適なパフォーマンスを実現するように１つのｅＮＢから別のｅＮＢにハンドオーバされることが可能である。隣接するｅＮＢは、それらのｅＮＢ間のＸ２インタフェースを介して互いに通信することができる。
【０００４】
ＵＥと、ＵＥが接続されているソースｅＮＢの間の接続は、失われる可能性があり、このことは、ＲＬＦ（無線リンク障害）として知られている。ＲＬＦを経験しており、別のｅＮＢのセル内に再出現するＵＥは、アイドル状態、ＲＲＣ＿ＩＤＬＥを介して移行中として扱われることが以前に提案されている。この機構において、ソースｅＮＢにおいてＲＬＦが存在する場合、ＵＥは、ＩＤＬＥ状態に入り、新たなターゲットｅＮＢを選択する。ＵＥが新たなターゲットｅＮＢに接続され、ターゲットｅＮＢに関するシステム情報を受信すると、ＵＥは、ターゲットｅＮＢにおいてリソースを確立するアクセス手順を実行することができる。
【０００５】
ＲＬＦは、ソースｅＮＢからターゲットｅＮＢへのハンドオーバが差し迫っている可能性がある際の、フェージングチャネル条件中に特に高い可能性で生じ得る。ＩＤＬＥ条件を経ることを回避するのに、ハンドオーバ準備手順を使用することによって、新たなｅＮＢが、ＵＥを受け入れるように前もって準備されることも可能であることが示唆されている。Ｈａｎｄｏｖｅｒ＿Ｒｅｑｕｅｓｔメッセージが複数のｅＮＢに送信されることが可能であり、これらのｅＮＢは、そのため、そのＵＥを認識することができ、これらのｅＮＢのそれぞれがハンドオーバ候補として準備される。すると、ＵＥは、ＲＬＦの移動段階中、新たなターゲットｅＮＢを選択した後、ＵＥの前のコンテキストを続けることができる。
【０００６】
ＬＴＥハンドオーバに先立って、ＵＥは、測定を実行し、３ＧＰＰ  ＲＲＣプロトコル規格３ＧＰＰ  ＴＳ３６．３００ｖ８．４．０において指定され、さらに図１に例示されるとおり、ハンドオーバ・イベント作成のためのハンドオーバ・パラメータおよびハンドオーバ方程式を適用し、図１は、時間につれての信号強度変化と、ハンドオーバ・イベントの作成を生じさせるＨＯＭ（ハンドオーバ・マージン）、ＯＣＮ（セル個別オフセット）、およびＴＴＴＨ（ハンドオーバをトリガするまでの時間）の適用とを例示する。特定のネットワーク実施形態に応じて、例示されるパラメータ以外のパラメータが使用されてもよい。
【０００７】
ハンドオーバ・イベントが生成されるとすぐに、ＵＥは、このイベントをＭｅａｓｕｒｅｍｅｎｔＲｅｐｏｒｔメッセージの中に含め、そのメッセージをソースｅＮＢに転送する。ソースｅＮＢは、ハンドオーバするように、またはハンドオーバしないように判定する。ハンドオーバが選択されると、ソースｅＮＢは、Ｘ２インタフェースを介してターゲットｅＮＢにＨａｎｄｏｖｅｒＲｅｑｕｅｓｔメッセージを送信し、ターゲットｅＮＢからの、トランスペアレント・コンテナを含むＸ２  ＨａｎｄｏｖｅｒＲｅｑｕｅｓｔＡｃｋｎｏｗｌｅｄｇｅメッセージを待つ。
【０００８】
肯定応答の後、ソースｅＮＢは、そのトランスペアレント・コンテナをＨａｎｄｏｖｅｒＣｏｍｍａｎｄ（ＲＲＣＨａｎｄｏｖｅｒＲｅｃｏｎｆｉｇｕｒａｔｉｏｎ）メッセージの中に挿入し、そのメッセージをＵＥに転送する。このメッセージで、ＵＥは、ハンドオーバを実行するように命令される。
【０００９】
ＵＥは、ターゲットｅＮＢに同期し、ＨａｎｄｏｖｅｒＣｏｎｆｉｒｍ（ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎＣｏｍｐｌｅｔｅ）メッセージをターゲットｅＮＢに送信して、接続の成功を示す。パス切り換えの後、ターゲットｅＮＢは、Ｘ２インタフェースを介してソースｅＮＢにＵＥＣｏｎｔｅｘｔＲｅｌｅａｓｅメッセージを配信する。
【００１０】
ハンドオーバ手順の成功は、移動体システムに関する主要な基本のパフォーマンス指標の１つである。このため、ハンドオーバ手順中の、またはハンドオーバ手順と関係する障害は、望ましくない。ＬＴＥにおいて、ハンドオーバ手順中に、またはハンドオーバ手順と関係して以下の３種類の障害が生じる可能性がある。すなわち、ハンドオーバに先立つＲＬＦ（無線リンク障害）、ハンドオーバ・コマンド障害（ＲＬＦにつながる）、またはアクセス障害（ハンドオーバ失敗につながる）である。現在、ＬＴＥに関してＳＯＮ（自己組織化）機能が考慮されている。ＳＯＮ機能が適用され得る１つの可能性が、障害を減らそうと努めてハンドオーバ最適化において適用されることである。このことは、例えば、将来のハンドオーバ・イベント生成のために、ＴＴＴＨ（ハンドオーバをトリガするまでの時間）、ＨＯＭ（ハンドオーバ・マージン）フィルタリング係数、およびＯＣＮ（セル個別オフセット）などのハンドオーバ・パラメータを適合させることを含むことが可能である。また、ＭＣＳ（変調および符号化スキーム）および伝送電力が、後のＨａｎｄｏｖｅｒＣｏｍｍａｎｄ伝送事例のために適合させられることが可能である。別のアプローチは、障害の原因に応じて、複数のｅＮＢの準備のための判定パラメータを調整することであり得る。
【００１１】
現在、前述した３つの障害事例、つまり、ハンドオーバに先立つＲＬＦ、ハンドオーバ・コマンド障害、およびアクセス障害のいずれにおいても、ＵＥが、無線リンク障害手順の第２の段階に入るべきことが提案されている。この機構において、適切な「利用可能な最良の」セルにおけるＵＥによって制御された接続が存在し、そのセルは、ソースｅＮＢのセル、ターゲットｅＮＢのセル、または別の新たなｅＮＢからのセルであることが可能である。ＵＥがソースｅＮＢまたはターゲットｅＮＢのセルに接続される事例において、通信は維持される。ＵＥが新たなターゲットｅＮＢに接続される事例において、ＵＥコンテキストが知られていない場合、接続は切断される。
【先行技術文献】
【非特許文献】
【００１２】
【非特許文献１】３ＧＰＰ  ＴＳ３６．３００ｖ８．４．０（２００８年３月）
【発明の概要】
【課題を解決するための手段】
【００１３】
本発明の或る態様によれば、無線通信ネットワークにおけるハンドオーバのための方法が、ターゲット・ネットワーク・ノードとソース・ネットワーク・ノードの間で、ソース・ネットワーク・ノードが、ハンドオーバと関係する障害のタイプを識別することを可能にする情報を通信するステップを含む。「ターゲット・ネットワーク・ノード」という用語は、本明細書では、選択されたネットワーク・ノードへのハンドオーバが実現された後に、そのノードを指すのにも使用される。
【００１４】
例えば、或る実施形態において、通信される情報は、ハンドオーバに先立って、ハンドオーバ中に、またはハンドオーバ後に生じたハンドオーバ障害タイプを識別し、区別することが可能である。例えば、通信される情報は、ハンドオーバに先立つＲＬＦに起因して、またはソース・セルにおいて経験されるハンドオーバ・コマンド障害に起因して、ハンドオーバ・コマンド・メッセージが移動端末装置によって受信されない「ＲＬＦ」と関係することが可能であり、あるいは通信される情報は、ハンドオーバ・コマンド・メッセージは受信されるが、その後にターゲット・セルにおけるアクセス障害が生じる「ハンドオーバ失敗」と関係することが可能である。或る実施形態は、これらの障害タイプの１つ、またはこれらのタイプの２つ以上についての情報を通信することを含むことが可能である。ハンドオーバ障害と関係するそのような情報を報告することにより、その情報を使用して、例えば、移動性の堅牢性を高め、将来のハンドオーバ・パフォーマンスを向上させるようにハンドオーバ・パラメータを適合させることが可能になる。これによって、不正確なハンドオーバ・パラメータ設定を検出するための機構を提供することができる。
【００１５】
本発明は、ＬＴＥに従って実施されるネットワークおよび方法に特に適用可能であるが、その他の規格または標準に準拠するネットワークにおいて有利に使用されることも可能である。ＬＴＥにおいて、移動端末装置は、ＵＥと呼ばれ、ネットワーク・ノードは、ｅＮＢと呼ばれる。通信される情報は、その無線アクセス技術タイプのための前もって指定されたメッセージ内に含められて、別の目的で提供されることも可能である。別の実施形態において、新たに導入されたメッセージが、この通信される情報を伝送することが可能である。例えば、ＬＴＥネットワークにおける一方法において、通信される情報は、ターゲットの、つまり、選択されたｅＮＢからソースｅＮＢに送信されるＸ２インタフェース・メッセージ「ＵＥＣｏｎｔｅｘｔＲｅｌｅａｓｅ」の拡張部分の中に含められることが可能である。他の実施形態において、様々な既存のメッセージが、この通信される情報を伝送するのに使用されることが可能である。本発明によるＬＴＥネットワークにおける或る方法において、通信される情報は、選択されたｅＮＢからソースｅＮＢに送信される、例えば、「ＵｎｓｕｃｃｅｓｓｆｕｌＲｅｅｓｔａｂｌｉｓｈｍｅｎｔ」と名付けられることが可能な、新たに定義されたメッセージの中に含められることが可能である。
【００１６】
別の態様によれば、無線ネットワークが、本発明による方法を使用して実施される。
【００１７】
次に、本発明のいくつかの方法および実施形態を、単に例として、添付の図面を参照して説明する。
【図面の簡単な説明】
【００１８】
【図１】ＵＥにおけるＬＴＥハンドオーバ・イベント作成を示す概略図である。
【図２】ＬＴＥハンドオーバに先立つＲＬＦを示す概略図である。
【図３】ＬＴＥハンドオーバ中のハンドオーバ・コマンド障害を示す概略図である。
【図４】ＬＴＥハンドオーバ中のアクセス障害を示す概略図である。
【発明を実施するための形態】
【００１９】
前述したとおり、ＬＴＥハンドオーバに先立って、ＵＥは、ハンドオーバ・イベント作成のための測定を実行する。しかし、いくつかの状況において、ＵＥは、ＭｅａｓｕｒｅｍｅｎｔＲｅｐｏｒｔを間に合うように生成することができずに、受信された信号強度の突然の低下を経験する可能性がある。さらに、ＵＥは、ソース・セルにおいて回復することができない可能性があり、ソース・セルにおいてＲＬＦ（無線リンク障害）を検出する。図２に例示される別のシナリオにおいて、ＵＥは、ハンドオーバ・イベントを含むＭｅａｓｕｒｅｍｅｎｔＲｅｐｏｒｔを作成するが、ＵＥ  ＭｅａｓｕｒｅｍｅｎｔＲｅｐｏｒｔの送信に関して問題が生じる。ハンドオーバ・イベントがソースｅＮＢによって受信されない場合、ソースｅＮＢからハンドオーバは開始され得ない。また、このことは、ＬＴＥハンドオーバに先立って、このＵＥに関してソース・セルにおけるＲＬＦをもたらす可能性もある。
【００２０】
ＵＥハンドオーバ・イベントの報告の後にＨａｎｄｏｖｅｒＣｏｍｍａｎｄ障害が生じることが、図３に例示される。ＵＥが、ソースｅＮＢによって受信される測定レポートを送信する。ソースｅＮＢは、ハンドオーバが要求されていると判定し、ＵＥにハンドオーバ・コマンドを送信する。このＨａｎｄｏｖｅｒＣｏｍｍａｎｄメッセージは、劣悪な無線信号品質条件下でＵＥによって受信されている可能性が高い。その結果、相当な数のＨａｎｄｏｖｅｒＣｏｍｍａｎｄメッセージが受信されないことが可能である。ＵＥは、ＨａｎｄｏｖｅｒＣｏｍｍａｎｄメッセージを受信しないため、ハンドオーバを実行するように命令されないので、ＵＥがターゲット・セルに即時にアクセスすることはない。多くの事例において、ＵＥは、無線リンク問題を経験し、ソース・セルにおいてＲＬＦ（無線リンク障害）を検出し、ＨａｎｄｏｖｅｒＣｏｍｍａｎｄ障害が生じる。
【００２１】
ＬＴＥハンドオーバ中のアクセス障害が図４に例示される。このシナリオでは、ソース・セルにおいてＵＥによるＨａｎｄｏｖｅｒＣｏｍｍａｎｄ（ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎ）メッセージの受信の成功があり、ＵＥがタイマＴ３０４を開始する。次に、ＵＥは、ターゲット・セルにアクセスしようと試みる。タイマＴ３０４が、ターゲット・セルへのアクセスの成功なしに満了した場合、ＵＥは、逸せられたアクセスに起因するハンドオーバ失敗を検出する。
【００２２】
前述した障害事例のそれぞれにおいて、ＵＥは、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤモードに留まり、適切な「利用可能な最良の」セルを選択する。障害が生じた後、ＵＥは、ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｅｓｔａｂｌｉｓｈｍｅｎｔＲｅｑｕｅｓｔメッセージから始めて、ＲＲＣ接続再確立手順を実行する。ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｅｓｔａｂｌｉｓｈｍｅｎｔＲｅｑｕｅｓｔメッセージは、ソース・セルにおいて使用されるｃ−ＲＮＴＩと、ソース・セルのｃｅｌｌＩｄｅｎｔｉｔｙと、ａｕｔｈｅｎｔｉｃａｔｏｎＣｏｄｅと、前もって定義されてはいない、４つの可能な値を有するＲｅｅｓｔａｂｌｉｓｈｍｅｎｔＣａｕｓｅとを伴う、ｕｅ−Ｉｄｅｎｔｉｔｙを含む。ａｕｔｈｅｎｔｉｃａｔｏｎＣｏｄｅは、ソース・セルにおいて使用されるｃ−ＲＮＴＩ、ソース・セルのｃｅｌｌＩｄｅｎｔｉｔｙ、および「ターゲット」セルＩＤ（「ターゲット」セルＩＤが、選択されたセルのセルＩＤを示すものと想定して）を対象にして計算されたＭＡＣ−Ｉである。
【００２３】
選択されたｅＮＢが、ｕｅ−Ｉｄｅｎｔｉｔｙと合致するコンテキストを見出した場合、接続は再開されることが可能である。このＵＥコンテキストは、先に実行された準備段階中にＵＥを受け入れたｅＮＢにおいてしか利用可能でないので、ＲＲＣ再確立は、準備されたｅＮＢに関してしか成功しない。
【００２４】
選択されたｅＮＢがＵＥコンテキストを見出さなかった場合、ＲＲＣ接続は解放され、ＵＥは、ＲＲＣ＿ＩＤＬＥに「プッシュ」される。
【００２５】
障害事例（ｉ）ハンドオーバに先立つＲＬＦ、（ｉｉ）ハンドオーバ・コマンド障害（ＲＬＦにつながる）、および（ｉｉｉ）アクセス障害（ハンドオーバ失敗につながる）を区別するために、ＲｅｅｓｔａｂｌｉｓｈｍｅｎｔＣａｕｓｅは、ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｅｓｔａｂｌｉｓｈｍｅｎｔＲｅｑｕｅｓｔメッセージの中で、（ａ）ＵＥがソース・セルにおいてハンドオーバ・コマンドを受信しなかったことを示す「ＲＬＦ」、または（ｂ）ＵＥがソース・セルにおいてハンドオーバ・コマンドを受信したことを示す「ハンドオーバ失敗」に設定される。
【００２６】
選択されたｅＮＢは、ｕｅ−Ｉｄｅｎｔｉｔｙと、ＲｅｅｓｔａｂｌｉｓｈｍｅｎｔＣａｕｓｅとを含むＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｅｓｔａｂｌｉｓｈｍｅｎｔＲｅｑｕｅｓｔを受信する。ＲＲＣ接続再確立は、選択されたｅＮＢが、先に実行された準備段階中に準備されている場合、成功する。再確立の成功の後、ＲｅｅｓｔａｂｌｉｓｈｍｅｎｔＣａｕｓｅは、選択されたｅＮＢによってソースｅＮＢに送信されるＸ２  ＵＥＣｏｎｔｅｘｔＲｅｌｅａｓｅメッセージの中に含まれる。このことは、ソースｅＮＢが、生じた特定のタイプの障害の知識を使用して、ハンドオーバ・イベント生成のためのパラメータ、ならびにハンドオーバ準備のためのソースｅＮＢの振舞いを適合させることを可能にする。
【００２７】
ソースｅＮＢが、例えば、ＲｅｅｓｔａｂｌｉｓｈｍｅｎｔＣａｕｓｅ値、「ＲＬＦ」を有するＸ２  ＵＥＣｏｎｔｅｘｔＲｅｌｅａｓｅメッセージを受信し、ＵＥへの先行するＨａｎｄｏｖｅｒＣｏｍｍａｎｄ送信についての知識を有すると、ソースｅＮＢは、このＵＥに関して、ハンドオーバ・コマンド障害に起因するＲＬＦが生じたことを識別することができる。すると、ソースｅＮＢは、将来のハンドオーバ・イベント生成のためのソースｅＮＢのハンドオーバ・パラメータ、例えば、ＴＴＴＨ、ＨＯＭ、フィルタリング係数、およびＯＣＮ、あるいは後のＨａｎｄｏｖｅｒＣｏｍｍａｎｄ送信事例のためのＭＣＳ選択および電力を適合させることができる。
【００２８】
ソースｅＮＢが、ＵＥへの先行するＨａｎｄｏｖｅｒＣｏｍｍａｎｄ送信なしに、ＲｅｅｓｔａｂｌｉｓｈｍｅｎｔＣａｕｓｅ値、「ＲＬＦ」を有するＸ２  ＵＥＣｏｎｔｅｘｔＲｅｌｅａｓｅメッセージを受信した場合、ソースｅＮＢは、ソース・セルにおいてハンドオーバに先立つＲＬＦが生じたことを識別することができる。しかし、ＵＥの回復、ソース・セルの一義的な識別、およびＸ２  ＵＥＣｏｎｔｅｘｔＲｅｌｅａｓｅを介する情報交換は、選択されたｅＮＢが前もって準備されている場合だけしか可能でない。
【００２９】
ソースｅＮＢが、ＲｅｅｓｔａｂｌｉｓｈｍｅｎｔＣａｕｓｅ値、「ハンドオーバ失敗」を有するＸ２  ＵＥＣｏｎｔｅｘｔＲｅｌｅａｓｅメッセージを受信した場合、ソースｅＮＢは、そのＵＥに関してターゲット・セルにおいてアクセス障害が生じたことを識別することができる。アクセス障害が、全般的に、またはいくつかのターゲット・セルに関して繰り返し生じる場合、ソースｅＮＢは、例えば、ハンドオーバ・イベント生成のためのパラメータ、または多重準備のための判定パラメータを適合させることができる。
【００３０】
前段で与えられた実施例は、通信される情報をＸ２  ＵＥＣｏｎｔｅｘｔＲｅｌｅａｓｅメッセージの中に含めることを含むが、別の実施形態において、別のタイプのメッセージが代わりに使用されてもよい。
【００３１】
ＲＲＣ接続再確立は、選択されたｅＮＢが準備されていない場合、成功せず、すると、ＵＥは、ＲＲＣ＿ＩＤＬＥに「プッシュ」される。この場合、例えば、「ＵｎｓｕｃｃｅｓｓｆｕｌＲｅｅｓｔａｂｌｉｓｈｍｅｎｔ」と名付けられたＸ２メッセージが定義される。このメッセージは、ソース・セルにおいて使用されるｃ−ＲＮＴＩ、ソース・セルのｃｅｌｌＩｄｅｎｔｉｔｙ、選択されたセルのセルＩＤ、およびＲｅｅｓｔａｂｌｉｓｈｍｅｎｔＣａｕｓｅ値を含む。ターゲットｅＮＢは、ターゲットｅＮＢが、このメッセージを送信する先の１つまたは複数のソースｅＮＢを識別する。この識別は、ソース・セルのｃｅｌｌＩｄｅｎｔｉｔｙを使用することによって行われる。ソースｅＮＢが、Ｘ２  ＵｎｓｕｃｃｅｓｓｆｕｌＲｅｅｓｔａｂｌｉｓｈｍｅｎｔメッセージを受信すると、ソースｅＮＢは、そのｃ−ＲＮＴＩが、ｃｅｌｌＩｄｅｎｔｉｔｙによって識別されるソース・セル内の、以前に知られていたが、失われたＵＥに実際にマップされるかどうかを評価する。このことが肯定的な結果につながった場合、メッセージは、以下のとおり処理される。
【００３２】
Ｘ２  ＵｎｓｕｃｃｅｓｓｆｕｌＲｅｅｓｔａｂｌｉｓｈｍｅｎｔメッセージが、ＲｅｅｓｔａｂｌｉｓｈｍｅｎｔＣａｕｓｅ値、「ＲＬＦ」を含み、先行するＨａｎｄｏｖｅｒＣｏｍｍａｎｄ送信が、このＵＥに実行されていた場合、ソースｅＮＢは、ハンドオーバ・コマンド障害に起因するＲＬＦからもたらされた再確立の失敗が、このＵＥに関して生じたことを識別することができる。このことが、全般的に、またはいくつかのターゲット・セルに関して繰り返し生じる場合、ソースｅＮＢは、将来のハンドオーバ・イベント生成のためにソースｅＮＢのハンドオーバ・パラメータ（ＴＴＴＨ、ＨＯＭ、フィルタリング係数、およびＯＣＮなどの）を適合させる、あるいは後のＨａｎｄｏｖｅｒＣｏｍｍａｎｄ送信のためにＭＣＳ選択および送信電力のような伝送パラメータを変更することができる。Ｘ２  ＵｎｓｕｃｃｅｓｓｆｕｌＲｅｅｓｔａｂｌｉｓｈｍｅｎｔメッセージが、このＵＥへの先行するＨａｎｄｏｖｅｒＣｏｍｍａｎｄ送信なしに、ＲｅｅｓｔａｂｌｉｓｈｍｅｎｔＣａｕｓｅ値、「ＲＬＦ」を含む場合、ソースｅＮＢは、ハンドオーバに先立つＲＬＦからもたらされた再確立の失敗がソース・セルにおいて生じたことを識別することができる。
【００３３】
ハンドオーバに先立つＲＬＦに起因する再確立の失敗が、全般的に、またはいくつかのターゲット・セルに関して繰り返し生じる場合、ソースｅＮＢは、例えば、ハンドオーバ・イベント生成に関するパラメータ、または多重準備のための判定パラメータを適合させることができる。
【００３４】
Ｘ２  ＵｎｓｕｃｃｅｓｓｆｕｌＲｅｅｓｔａｂｌｉｓｈｍｅｎｔメッセージが、ＲｅｅｓｔａｂｌｉｓｈｍｅｎｔＣａｕｓｅ値、「ハンドオーバ失敗」を含む場合、ソースｅＮＢは、ターゲット・セルにおいてアクセス障害が生じたことを識別することができる。この情報で、ソースｅＮＢは、このＵＥに関するアクセス障害に起因して、ターゲット・セルにおいて問題が生じたことを識別することができる。アクセス障害が、いくつかのターゲット・セルに関して繰り返し生じる場合、ソースｅＮＢは、例えば、ハンドオーバ・イベント生成に関するパラメータ、または多重準備のための判定パラメータを適合させることができる。
【００３５】
本発明は、本発明の趣旨、または本発明の本質的な特徴を逸脱することなく、他の特定の形態で実施されることが可能であり、異なる方法を使用して実行されることが可能である。説明される実施形態および方法は、すべての点で単に例示的であり、制限的ではないものと考えられるべきである。したがって、本発明の範囲は、以上の説明によってではなく、添付の特許請求の範囲によって示される。特許請求の範囲の均等性の趣旨および範囲に含まれるすべての変更が、特許請求の範囲に包含されるものとする。
【図１】
2011530912.tif 000003
【図２】
2011530912.tif 000004
【図３】
2011530912.tif 000005
【図４】
2011530912.tif 000006
【国際調査報告】
2011530912.tif 000007
2011530912.tif 000008
2011530912.tif 000009
2011530912.tif 000010