JP5302400B2 - 無線通信ネットワークにおけるハンドオーバ方法およびハンドオーバ装置 - Google Patents

Description

本発明は、無線通信ネットワークにおけるハンドオーバのための方法および装置に関し、より詳細には、排他的にではなく、３ＧＰＰ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）のＥ−ＵＴＲＡＮ（ｅｖｏｌｖｅｄ Ｕｎｉｖｅｒｓａｌ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）規格およびＥ−ＵＴＲＡ（ｅｖｏｌｖｅｄ Ｕｎｉｖｅｒｓａｌ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ）規格に従って実施される方法および装置に関する。

現在、３ＧＰＰは、参照により本明細書に組み込まれている技術規格３ＧＰＰ ＴＳ３６．３００ｖ８．４．０（２００８年３月）、ならびに関連文書に記載されるＥ−ＵＴＲＡおよびＥ−ＵＴＲＡＮの開発を考慮している。３ＧＰＰ ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）は、例えば、効率およびサービスを向上させることによって、ＵＭＴＳ（Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｙｓｔｅｍ）標準を強化することを目指す。

Ｅ−ＵＴＲＡＮにおいて、ＵＥ（ユーザ機器）は、ネットワーク・ノード、ｅＮＢ（ノードＢ）と通信し、データは、ＵＥ、ネットワーク・ノード、およびｅＮＢの間で無線リンクを介してＲＢ（無線ベアラ）上で送信される。ｅＮＢは、Ｓ１と呼ばれるインタフェースを介してＭＭＥ（移動体管理エンティティ）とインタフェースをとる。Ｅ−ＵＴＲＡＮネットワークは、複数のｅＮＢおよびＭＭＥを含み、ＵＥは、例えば、フェージングチャネル条件下で、またはＵＥが１つのセルカバレッジエリアから別のセルカバレッジエリアに移動している場合に、最適なパフォーマンスを実現するように１つのｅＮＢから別のｅＮＢにハンドオーバされることが可能である。隣接するｅＮＢは、それらのｅＮＢ間のＸ２インタフェースを介して互いに通信することができる。

ＵＥと、ＵＥが接続されているソースｅＮＢの間の接続は、失われる可能性があり、このことは、ＲＬＦ（無線リンク障害）として知られている。ＲＬＦを経験しており、別のｅＮＢのセル内に再出現するＵＥは、アイドル状態、ＲＲＣ＿ＩＤＬＥを介して移行中として扱われることが以前に提案されている。この機構において、ソースｅＮＢにおいてＲＬＦが存在する場合、ＵＥは、ＩＤＬＥ状態に入り、新たなターゲットｅＮＢを選択する。ＵＥが新たなターゲットｅＮＢに接続され、ターゲットｅＮＢに関するシステム情報を受信すると、ＵＥは、ターゲットｅＮＢにおいてリソースを確立するアクセス手順を実行することができる。

ＲＬＦは、ソースｅＮＢからターゲットｅＮＢへのハンドオーバが差し迫っている可能性がある際の、フェージングチャネル条件中に特に高い可能性で生じ得る。ＩＤＬＥ条件を経ることを回避するのに、ハンドオーバ準備手順を使用することによって、新たなｅＮＢが、ＵＥを受け入れるように前もって準備されることも可能であることが示唆されている。Ｈａｎｄｏｖｅｒ＿Ｒｅｑｕｅｓｔメッセージが複数のｅＮＢに送信されることが可能であり、これらのｅＮＢは、そのため、そのＵＥを認識することができ、これらのｅＮＢのそれぞれがハンドオーバ候補として準備される。すると、ＵＥは、ＲＬＦの移動段階中、新たなターゲットｅＮＢを選択した後、ＵＥの前のコンテキストを続けることができる。

ＬＴＥハンドオーバに先立って、ＵＥは、測定を実行し、３ＧＰＰ ＲＲＣプロトコル規格３ＧＰＰ ＴＳ３６．３００ｖ８．４．０において指定され、さらに図１に例示されるとおり、ハンドオーバ・イベント作成のためのハンドオーバ・パラメータおよびハンドオーバ方程式を適用し、図１は、時間につれての信号強度変化と、ハンドオーバ・イベントの作成を生じさせるＨＯＭ（ハンドオーバ・マージン）、ＯＣＮ（セル個別オフセット）、およびＴＴＴＨ（ハンドオーバをトリガするまでの時間）の適用とを例示する。特定のネットワーク実施形態に応じて、例示されるパラメータ以外のパラメータが使用されてもよい。

ハンドオーバ・イベントが生成されるとすぐに、ＵＥは、このイベントをＭｅａｓｕｒｅｍｅｎｔＲｅｐｏｒｔメッセージの中に含め、そのメッセージをソースｅＮＢに転送する。ソースｅＮＢは、ハンドオーバするように、またはハンドオーバしないように判定する。ハンドオーバが選択されると、ソースｅＮＢは、Ｘ２インタフェースを介してターゲットｅＮＢにＨａｎｄｏｖｅｒＲｅｑｕｅｓｔメッセージを送信し、ターゲットｅＮＢからの、トランスペアレント・コンテナを含むＸ２ ＨａｎｄｏｖｅｒＲｅｑｕｅｓｔＡｃｋｎｏｗｌｅｄｇｅメッセージを待つ。

肯定応答の後、ソースｅＮＢは、そのトランスペアレント・コンテナをＨａｎｄｏｖｅｒＣｏｍｍａｎｄ（ＲＲＣＨａｎｄｏｖｅｒＲｅｃｏｎｆｉｇｕｒａｔｉｏｎ）メッセージの中に挿入し、そのメッセージをＵＥに転送する。このメッセージで、ＵＥは、ハンドオーバを実行するように命令される。

ＵＥは、ターゲットｅＮＢに同期し、ＨａｎｄｏｖｅｒＣｏｎｆｉｒｍ（ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎＣｏｍｐｌｅｔｅ）メッセージをターゲットｅＮＢに送信して、接続の成功を示す。パス切り換えの後、ターゲットｅＮＢは、Ｘ２インタフェースを介してソースｅＮＢにＵＥＣｏｎｔｅｘｔＲｅｌｅａｓｅメッセージを配信する。

ハンドオーバ手順の成功は、移動体システムに関する主要な基本のパフォーマンス指標の１つである。このため、ハンドオーバ手順中の、またはハンドオーバ手順と関係する障害は、望ましくない。ＬＴＥにおいて、ハンドオーバ手順中に、またはハンドオーバ手順と関係して以下の３種類の障害が生じる可能性がある。すなわち、ハンドオーバに先立つＲＬＦ（無線リンク障害）、ハンドオーバ・コマンド障害（ＲＬＦにつながる）、またはアクセス障害（ハンドオーバ失敗につながる）である。現在、ＬＴＥに関してＳＯＮ（自己組織化）機能が考慮されている。ＳＯＮ機能が適用され得る１つの可能性が、障害を減らそうと努めてハンドオーバ最適化において適用されることである。このことは、例えば、将来のハンドオーバ・イベント生成のために、ＴＴＴＨ（ハンドオーバをトリガするまでの時間）、ＨＯＭ（ハンドオーバ・マージン）フィルタリング係数、およびＯＣＮ（セル個別オフセット）などのハンドオーバ・パラメータを適合させることを含むことが可能である。また、ＭＣＳ（変調および符号化スキーム）および伝送電力が、後のＨａｎｄｏｖｅｒＣｏｍｍａｎｄ伝送事例のために適合させられることが可能である。別のアプローチは、障害の原因に応じて、複数のｅＮＢの準備のための判定パラメータを調整することであり得る。

現在、前述した３つの障害事例、つまり、ハンドオーバに先立つＲＬＦ、ハンドオーバ・コマンド障害、およびアクセス障害のいずれにおいても、ＵＥが、無線リンク障害手順の第２の段階に入るべきことが提案されている。この機構において、適切な「利用可能な最良の」セルにおけるＵＥによって制御された接続が存在し、そのセルは、ソースｅＮＢのセル、ターゲットｅＮＢのセル、または別の新たなｅＮＢからのセルであることが可能である。ＵＥがソースｅＮＢまたはターゲットｅＮＢのセルに接続される事例において、通信は維持される。ＵＥが新たなターゲットｅＮＢに接続される事例において、ＵＥコンテキストが知られていない場合、接続は切断される。

３ＧＰＰ ＴＳ３６．３００ｖ８．４．０（２００８年３月）

本発明の或る態様によれば、無線通信ネットワークにおけるハンドオーバのための方法が、ターゲット・ネットワーク・ノードとソース・ネットワーク・ノードの間で、ソース・ネットワーク・ノードが、ハンドオーバと関係する障害のタイプを識別することを可能にする情報を通信するステップを含む。「ターゲット・ネットワーク・ノード」という用語は、本明細書では、選択されたネットワーク・ノードへのハンドオーバが実現された後に、そのノードを指すのにも使用される。

例えば、或る実施形態において、通信される情報は、ハンドオーバに先立って、ハンドオーバ中に、またはハンドオーバ後に生じたハンドオーバ障害タイプを識別し、区別することが可能である。例えば、通信される情報は、ハンドオーバに先立つＲＬＦに起因して、またはソース・セルにおいて経験されるハンドオーバ・コマンド障害に起因して、ハンドオーバ・コマンド・メッセージが移動端末装置によって受信されない「ＲＬＦ」と関係することが可能であり、あるいは通信される情報は、ハンドオーバ・コマンド・メッセージは受信されるが、その後にターゲット・セルにおけるアクセス障害が生じる「ハンドオーバ失敗」と関係することが可能である。或る実施形態は、これらの障害タイプの１つ、またはこれらのタイプの２つ以上についての情報を通信することを含むことが可能である。ハンドオーバ障害と関係するそのような情報を報告することにより、その情報を使用して、例えば、移動性の堅牢性を高め、将来のハンドオーバ・パフォーマンスを向上させるようにハンドオーバ・パラメータを適合させることが可能になる。これによって、不正確なハンドオーバ・パラメータ設定を検出するための機構を提供することができる。

本発明は、ＬＴＥに従って実施されるネットワークおよび方法に特に適用可能であるが、その他の規格または標準に準拠するネットワークにおいて有利に使用されることも可能である。ＬＴＥにおいて、移動端末装置は、ＵＥと呼ばれ、ネットワーク・ノードは、ｅＮＢと呼ばれる。通信される情報は、その無線アクセス技術タイプのための前もって指定されたメッセージ内に含められて、別の目的で提供されることも可能である。別の実施形態において、新たに導入されたメッセージが、この通信される情報を伝送することが可能である。例えば、ＬＴＥネットワークにおける一方法において、通信される情報は、ターゲットの、つまり、選択されたｅＮＢからソースｅＮＢに送信されるＸ２インタフェース・メッセージ「ＵＥＣｏｎｔｅｘｔＲｅｌｅａｓｅ」の拡張部分の中に含められることが可能である。他の実施形態において、様々な既存のメッセージが、この通信される情報を伝送するのに使用されることが可能である。本発明によるＬＴＥネットワークにおける或る方法において、通信される情報は、選択されたｅＮＢからソースｅＮＢに送信される、例えば、「ＵｎｓｕｃｃｅｓｓｆｕｌＲｅｅｓｔａｂｌｉｓｈｍｅｎｔ」と名付けられることが可能な、新たに定義されたメッセージの中に含められることが可能である。

別の態様によれば、無線ネットワークが、本発明による方法を使用して実施される。

次に、本発明のいくつかの方法および実施形態を、単に例として、添付の図面を参照して説明する。

ＵＥにおけるＬＴＥハンドオーバ・イベント作成を示す概略図である。 ＬＴＥハンドオーバに先立つＲＬＦを示す概略図である。 ＬＴＥハンドオーバ中のハンドオーバ・コマンド障害を示す概略図である。 ＬＴＥハンドオーバ中のアクセス障害を示す概略図である。

前述したとおり、ＬＴＥハンドオーバに先立って、ＵＥは、ハンドオーバ・イベント作成のための測定を実行する。しかし、いくつかの状況において、ＵＥは、ＭｅａｓｕｒｅｍｅｎｔＲｅｐｏｒｔを間に合うように生成することができずに、受信された信号強度の突然の低下を経験する可能性がある。さらに、ＵＥは、ソース・セルにおいて回復することができない可能性があり、ソース・セルにおいてＲＬＦ（無線リンク障害）を検出する。図２に例示される別のシナリオにおいて、ＵＥは、ハンドオーバ・イベントを含むＭｅａｓｕｒｅｍｅｎｔＲｅｐｏｒｔを作成するが、ＵＥ ＭｅａｓｕｒｅｍｅｎｔＲｅｐｏｒｔの送信に関して問題が生じる。ハンドオーバ・イベントがソースｅＮＢによって受信されない場合、ソースｅＮＢからハンドオーバは開始され得ない。また、このことは、ＬＴＥハンドオーバに先立って、このＵＥに関してソース・セルにおけるＲＬＦをもたらす可能性もある。

ＵＥハンドオーバ・イベントの報告の後にＨａｎｄｏｖｅｒＣｏｍｍａｎｄ障害が生じることが、図３に例示される。ＵＥが、ソースｅＮＢによって受信される測定レポートを送信する。ソースｅＮＢは、ハンドオーバが要求されていると判定し、ＵＥにハンドオーバ・コマンドを送信する。このＨａｎｄｏｖｅｒＣｏｍｍａｎｄメッセージは、劣悪な無線信号品質条件下でＵＥによって受信されている可能性が高い。その結果、相当な数のＨａｎｄｏｖｅｒＣｏｍｍａｎｄメッセージが受信されないことが可能である。ＵＥは、ＨａｎｄｏｖｅｒＣｏｍｍａｎｄメッセージを受信しないため、ハンドオーバを実行するように命令されないので、ＵＥがターゲット・セルに即時にアクセスすることはない。多くの事例において、ＵＥは、無線リンク問題を経験し、ソース・セルにおいてＲＬＦ（無線リンク障害）を検出し、ＨａｎｄｏｖｅｒＣｏｍｍａｎｄ障害が生じる。

ＬＴＥハンドオーバ中のアクセス障害が図４に例示される。このシナリオでは、ソース・セルにおいてＵＥによるＨａｎｄｏｖｅｒＣｏｍｍａｎｄ（ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎ）メッセージの受信の成功があり、ＵＥがタイマＴ３０４を開始する。次に、ＵＥは、ターゲット・セルにアクセスしようと試みる。タイマＴ３０４が、ターゲット・セルへのアクセスの成功なしに満了した場合、ＵＥは、逸せられたアクセスに起因するハンドオーバ失敗を検出する。

前述した障害事例のそれぞれにおいて、ＵＥは、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤモードに留まり、適切な「利用可能な最良の」セルを選択する。障害が生じた後、ＵＥは、ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｅｓｔａｂｌｉｓｈｍｅｎｔＲｅｑｕｅｓｔメッセージから始めて、ＲＲＣ接続再確立手順を実行する。ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｅｓｔａｂｌｉｓｈｍｅｎｔＲｅｑｕｅｓｔメッセージは、ソース・セルにおいて使用されるｃ−ＲＮＴＩと、ソース・セルのｃｅｌｌＩｄｅｎｔｉｔｙと、ａｕｔｈｅｎｔｉｃａｔｏｎＣｏｄｅと、前もって定義されてはいない、４つの可能な値を有するＲｅｅｓｔａｂｌｉｓｈｍｅｎｔＣａｕｓｅとを伴う、ｕｅ−Ｉｄｅｎｔｉｔｙを含む。ａｕｔｈｅｎｔｉｃａｔｏｎＣｏｄｅは、ソース・セルにおいて使用されるｃ−ＲＮＴＩ、ソース・セルのｃｅｌｌＩｄｅｎｔｉｔｙ、および「ターゲット」セルＩＤ（「ターゲット」セルＩＤが、選択されたセルのセルＩＤを示すものと想定して）を対象にして計算されたＭＡＣ−Ｉである。

選択されたｅＮＢが、ｕｅ−Ｉｄｅｎｔｉｔｙと合致するコンテキストを見出した場合、接続は再開されることが可能である。このＵＥコンテキストは、先に実行された準備段階中にＵＥを受け入れたｅＮＢにおいてしか利用可能でないので、ＲＲＣ再確立は、準備されたｅＮＢに関してしか成功しない。

選択されたｅＮＢがＵＥコンテキストを見出さなかった場合、ＲＲＣ接続は解放され、ＵＥは、ＲＲＣ＿ＩＤＬＥに「プッシュ」される。

障害事例（ｉ）ハンドオーバに先立つＲＬＦ、（ｉｉ）ハンドオーバ・コマンド障害（ＲＬＦにつながる）、および（ｉｉｉ）アクセス障害（ハンドオーバ失敗につながる）を区別するために、ＲｅｅｓｔａｂｌｉｓｈｍｅｎｔＣａｕｓｅは、ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｅｓｔａｂｌｉｓｈｍｅｎｔＲｅｑｕｅｓｔメッセージの中で、（ａ）ＵＥがソース・セルにおいてハンドオーバ・コマンドを受信しなかったことを示す「ＲＬＦ」、または（ｂ）ＵＥがソース・セルにおいてハンドオーバ・コマンドを受信したことを示す「ハンドオーバ失敗」に設定される。

選択されたｅＮＢは、ｕｅ−Ｉｄｅｎｔｉｔｙと、ＲｅｅｓｔａｂｌｉｓｈｍｅｎｔＣａｕｓｅとを含むＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｅｓｔａｂｌｉｓｈｍｅｎｔＲｅｑｕｅｓｔを受信する。ＲＲＣ接続再確立は、選択されたｅＮＢが、先に実行された準備段階中に準備されている場合、成功する。再確立の成功の後、ＲｅｅｓｔａｂｌｉｓｈｍｅｎｔＣａｕｓｅは、選択されたｅＮＢによってソースｅＮＢに送信されるＸ２ ＵＥＣｏｎｔｅｘｔＲｅｌｅａｓｅメッセージの中に含まれる。このことは、ソースｅＮＢが、生じた特定のタイプの障害の知識を使用して、ハンドオーバ・イベント生成のためのパラメータ、ならびにハンドオーバ準備のためのソースｅＮＢの振舞いを適合させることを可能にする。

ソースｅＮＢが、例えば、ＲｅｅｓｔａｂｌｉｓｈｍｅｎｔＣａｕｓｅ値、「ＲＬＦ」を有するＸ２ ＵＥＣｏｎｔｅｘｔＲｅｌｅａｓｅメッセージを受信し、ＵＥへの先行するＨａｎｄｏｖｅｒＣｏｍｍａｎｄ送信についての知識を有すると、ソースｅＮＢは、このＵＥに関して、ハンドオーバ・コマンド障害に起因するＲＬＦが生じたことを識別することができる。すると、ソースｅＮＢは、将来のハンドオーバ・イベント生成のためのソースｅＮＢのハンドオーバ・パラメータ、例えば、ＴＴＴＨ、ＨＯＭ、フィルタリング係数、およびＯＣＮ、あるいは後のＨａｎｄｏｖｅｒＣｏｍｍａｎｄ送信事例のためのＭＣＳ選択および電力を適合させることができる。

ソースｅＮＢが、ＵＥへの先行するＨａｎｄｏｖｅｒＣｏｍｍａｎｄ送信なしに、ＲｅｅｓｔａｂｌｉｓｈｍｅｎｔＣａｕｓｅ値、「ＲＬＦ」を有するＸ２ ＵＥＣｏｎｔｅｘｔＲｅｌｅａｓｅメッセージを受信した場合、ソースｅＮＢは、ソース・セルにおいてハンドオーバに先立つＲＬＦが生じたことを識別することができる。しかし、ＵＥの回復、ソース・セルの一義的な識別、およびＸ２ ＵＥＣｏｎｔｅｘｔＲｅｌｅａｓｅを介する情報交換は、選択されたｅＮＢが前もって準備されている場合だけしか可能でない。

ソースｅＮＢが、ＲｅｅｓｔａｂｌｉｓｈｍｅｎｔＣａｕｓｅ値、「ハンドオーバ失敗」を有するＸ２ ＵＥＣｏｎｔｅｘｔＲｅｌｅａｓｅメッセージを受信した場合、ソースｅＮＢは、そのＵＥに関してターゲット・セルにおいてアクセス障害が生じたことを識別することができる。アクセス障害が、全般的に、またはいくつかのターゲット・セルに関して繰り返し生じる場合、ソースｅＮＢは、例えば、ハンドオーバ・イベント生成のためのパラメータ、または多重準備のための判定パラメータを適合させることができる。

前段で与えられた実施例は、通信される情報をＸ２ ＵＥＣｏｎｔｅｘｔＲｅｌｅａｓｅメッセージの中に含めることを含むが、別の実施形態において、別のタイプのメッセージが代わりに使用されてもよい。

ＲＲＣ接続再確立は、選択されたｅＮＢが準備されていない場合、成功せず、すると、ＵＥは、ＲＲＣ＿ＩＤＬＥに「プッシュ」される。この場合、例えば、「ＵｎｓｕｃｃｅｓｓｆｕｌＲｅｅｓｔａｂｌｉｓｈｍｅｎｔ」と名付けられたＸ２メッセージが定義される。このメッセージは、ソース・セルにおいて使用されるｃ−ＲＮＴＩ、ソース・セルのｃｅｌｌＩｄｅｎｔｉｔｙ、選択されたセルのセルＩＤ、およびＲｅｅｓｔａｂｌｉｓｈｍｅｎｔＣａｕｓｅ値を含む。ターゲットｅＮＢは、ターゲットｅＮＢが、このメッセージを送信する先の１つまたは複数のソースｅＮＢを識別する。この識別は、ソース・セルのｃｅｌｌＩｄｅｎｔｉｔｙを使用することによって行われる。ソースｅＮＢが、Ｘ２ ＵｎｓｕｃｃｅｓｓｆｕｌＲｅｅｓｔａｂｌｉｓｈｍｅｎｔメッセージを受信すると、ソースｅＮＢは、そのｃ−ＲＮＴＩが、ｃｅｌｌＩｄｅｎｔｉｔｙによって識別されるソース・セル内の、以前に知られていたが、失われたＵＥに実際にマップされるかどうかを評価する。このことが肯定的な結果につながった場合、メッセージは、以下のとおり処理される。

Ｘ２ ＵｎｓｕｃｃｅｓｓｆｕｌＲｅｅｓｔａｂｌｉｓｈｍｅｎｔメッセージが、ＲｅｅｓｔａｂｌｉｓｈｍｅｎｔＣａｕｓｅ値、「ＲＬＦ」を含み、先行するＨａｎｄｏｖｅｒＣｏｍｍａｎｄ送信が、このＵＥに実行されていた場合、ソースｅＮＢは、ハンドオーバ・コマンド障害に起因するＲＬＦからもたらされた再確立の失敗が、このＵＥに関して生じたことを識別することができる。このことが、全般的に、またはいくつかのターゲット・セルに関して繰り返し生じる場合、ソースｅＮＢは、将来のハンドオーバ・イベント生成のためにソースｅＮＢのハンドオーバ・パラメータ（ＴＴＴＨ、ＨＯＭ、フィルタリング係数、およびＯＣＮなどの）を適合させる、あるいは後のＨａｎｄｏｖｅｒＣｏｍｍａｎｄ送信のためにＭＣＳ選択および送信電力のような伝送パラメータを変更することができる。Ｘ２ ＵｎｓｕｃｃｅｓｓｆｕｌＲｅｅｓｔａｂｌｉｓｈｍｅｎｔメッセージが、このＵＥへの先行するＨａｎｄｏｖｅｒＣｏｍｍａｎｄ送信なしに、ＲｅｅｓｔａｂｌｉｓｈｍｅｎｔＣａｕｓｅ値、「ＲＬＦ」を含む場合、ソースｅＮＢは、ハンドオーバに先立つＲＬＦからもたらされた再確立の失敗がソース・セルにおいて生じたことを識別することができる。

ハンドオーバに先立つＲＬＦに起因する再確立の失敗が、全般的に、またはいくつかのターゲット・セルに関して繰り返し生じる場合、ソースｅＮＢは、例えば、ハンドオーバ・イベント生成に関するパラメータ、または多重準備のための判定パラメータを適合させることができる。

Ｘ２ ＵｎｓｕｃｃｅｓｓｆｕｌＲｅｅｓｔａｂｌｉｓｈｍｅｎｔメッセージが、ＲｅｅｓｔａｂｌｉｓｈｍｅｎｔＣａｕｓｅ値、「ハンドオーバ失敗」を含む場合、ソースｅＮＢは、ターゲット・セルにおいてアクセス障害が生じたことを識別することができる。この情報で、ソースｅＮＢは、このＵＥに関するアクセス障害に起因して、ターゲット・セルにおいて問題が生じたことを識別することができる。アクセス障害が、いくつかのターゲット・セルに関して繰り返し生じる場合、ソースｅＮＢは、例えば、ハンドオーバ・イベント生成に関するパラメータ、または多重準備のための判定パラメータを適合させることができる。

本発明は、本発明の趣旨、または本発明の本質的な特徴を逸脱することなく、他の特定の形態で実施されることが可能であり、異なる方法を使用して実行されることが可能である。説明される実施形態および方法は、すべての点で単に例示的であり、制限的ではないものと考えられるべきである。したがって、本発明の範囲は、以上の説明によってではなく、添付の特許請求の範囲によって示される。特許請求の範囲の均等性の趣旨および範囲に含まれるすべての変更が、特許請求の範囲に包含されるものとする。

Claims (11)

1. 無線通信ネットワークにおけるハンドオーバのための方法であって、
   選択されたネットワーク・ノードにて、移動端末装置が該選択されたネットワーク・ノードとの接続再確立をする間に、該移動端末装置からＲｅｅｓｔａｂｌｉｓｈｍｅｎｔＣａｕｓｅを受信するステップと、
   選択されたネットワーク・ノードにて、ソース・ネットワーク・ノードが、ハンドオーバに関係する障害を識別することを可能にするために、該ソース・ネットワーク・ノードに前記ＲｅｅｓｔａｂｌｉｓｈｍｅｎｔＣａｕｓｅを送信するステップを含む方法。
2. 前記ハンドオーバに関係する障害は、ハンドオーバに先立つ無線リンク障害であるＲＬＦと関係する請求項１に記載の方法。
3. 前記ハンドオーバに関係する障害は、ソース・セルにおけるハンドオーバ・コマンド障害と関係する請求項１または２のいずれか１項に記載の方法。
4. 前記ハンドオーバに関係する障害は、ターゲット・セルにおけるアクセス障害と関係する請求項１、２または３のいずれか１項に記載の方法。
5. 前記ＲｅｅｓｔａｂｌｉｓｈｍｅｎｔＣａｕｓｅは、さらなる目的を有するメッセージの中に含められる請求項１乃至４のいずれか１項に記載の方法。
6. 前記ＲｅｅｓｔａｂｌｉｓｈｍｅｎｔＣａｕｓｅは、別の目的を果たさないメッセージの中に含まれる請求項１乃至４のいずれか１項に記載の方法。
7. 前記ネットワークは、ＬＴＥ標準に準拠して実施される請求項１乃至６のいずれか１項に記載の方法。
8. 前記ＲｅｅｓｔａｂｌｉｓｈｍｅｎｔＣａｕｓｅは、Ｘ２インタフェース・メッセージの中に含められ、前記Ｘ２インタフェース・メッセージは、さらなる目的を有する請求項７に記載の方法。
9. 前記ＲｅｅｓｔａｂｌｉｓｈｍｅｎｔＣａｕｓｅは、Ｘ２インタフェースＵＥコンテキスト解放メッセージの拡張部分の中に含められる請求項８に記載の方法。
10. 前記ＲｅｅｓｔａｂｌｉｓｈｍｅｎｔＣａｕｓｅは、ハンドオーバ・パラメータを適合させるように使用される請求項１乃至９のいずれか１項に記載の方法。
11. ネットワーク・ノードであって、
    移動端末装置が前記ネットワーク・ノードとの接続再確立をする間に、該移動端末装置からＲｅｅｓｔａｂｌｉｓｈｍｅｎｔＣａｕｓｅを受信する手段と、
    ソース・ネットワーク・ノードが、ハンドオーバに関係する障害を識別することを可能にするために、該ソース・ネットワーク・ノードに前記ＲｅｅｓｔａｂｌｉｓｈｍｅｎｔＣａｕｓｅを送信する手段と、
    を具備するネットワーク・ノード。

Images