JP7538889B2 - 無線ネットワークのマルチイベント条件付きハンドオーバ実行に関するログ情報 - Google Patents

Description

本明細書は無線通信に関する。

通信システムは、固定通信機器や移動通信機器など、２つ以上のノードや機器間の通信を可能にする設備である場合がある。
信号は有線または無線のキャリアで伝送できる。

セルラー通信システムの例として、３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ（３ＧＰＰ）によって標準化されているアーキテクチャがある。
この分野の最近の開発は、ユニバーサルモバイルテレコミュニケーションズシステム（ＵＭＴＳ）無線アクセス技術のロングタームエボリューション（ＬＴＥ）と呼ばれることが多い。Ｅ－ＵＴＲＡ（進化型ＵＭＴＳ地上無線アクセス）は、モバイルネットワークのための３ＧＰＰのロングタームエボリューション（ＬＴＥ）アップグレード経路のエアインターフェースである。ＬＴＥでは、拡張型ノードＡＰ（ｅＮＢ）と呼ばれる基地局またはアクセスポイント（ＡＰ）は、カバレッジエリアまたはセル内の無線アクセスを提供する。ＬＴＥでは、モバイル機器、すなわち移動局をユーザ機器（ＵＥ）と呼ぶ。ＬＴＥには多くの改良や開発が含まれている。ＬＴＥの態様も改善され続けている。

５Ｇ Ｎｅｗ Ｒａｄｉｏ（ＮＲ）の開発は、３Ｇおよび４Ｇ無線ネットワークの以前の進化と同様に、５Ｇの要件を満たすための継続的なモバイルブロードバンド進化プロセスの一部である。５Ｇは、モバイルブロードバンドに加えて、新たに出現したユースケースも対象としている。５Ｇの目標は、新しいレベルのデータレート、遅延、信頼性、およびセキュリティを含む、ワイヤレスパフォーマンスの大幅な改善を提供することである。５Ｇ ＮＲは、大規模なモノのインターネット（ＩｏＴ）を効率的に接続するために拡張される可能性もあり、新しいタイプのミッションクリティカルなサービスを提供する可能性もある。たとえば、超信頼性と低遅延の通信（ＵＲＬＬＣ）デバイスは、高い信頼性と非常に低い遅延を必要とする場合がある。

一例の実施形態によれば、方法は、無線ネットワーク内のユーザデバイスによって、マルチイベント条件付きハンドオーバ実行に関連する情報をログ記録するステップであって、前記マルチイベント条件付きハンドオーバ実行は、前記ユーザデバイスによるマルチイベントの共同評価に基づいているステップと、前記ユーザデバイスによって、情報の少なくとも一部を含むレポートを送信するステップとを含む。

別の実施例によれば、方法は、ユーザデバイスによる条件付きハンドオーバ実行のために共同で評価されるマルチのイベントの構成を含む共同イベント構成情報を持つハンドオーバコマンドを、ネットワークノードによってユーザデバイスに送信するステップと、ユーザデバイスによるマルチイベント条件付きハンドオーバ実行の障害に関するユーザデバイスによって記録された情報を含むレポートをネットワークノードによって受信するステップとを含み、マルチイベント条件付きハンドオーバ実行は複数のイベントに基づく受信するステップ、および、レポートに基づいてネットワークノードによって、マルチイベント条件付きハンドオーバ実行のための一つ以上のイベントの構成に関連付けられた一つ以上のパラメータを変更するステップとを含む。

他の例示的な実施形態は、例示的な方法のそれぞれについて提供または説明され、例示的な方法のいずれかを実行するための手段、少なくとも１つのプロセッサによって実行されると、コンピューティングシステムに例示的な方法のいずれかを実行させるように構成された命令を記憶したコンピュータ可読記憶媒体、および、装置は、少なくとも１つのプロセッサと、コンピュータプログラムコードを含む少なくとも１つのメモリとを含み、少なくとも１つのメモリおよびコンピュータプログラムコードは、少なくとも１つのプロセッサを用いて、装置に少なくとも例示的な方法のいずれかを実行させるように構成される。

１つ以上の実施例の詳細は、添付の図面および以下の説明に記載されている。
他の特徴は、説明および図面、および請求の範囲から明らかになるだろう。

一実施例による無線ネットワークのブロック図である。 一実施例によるユーザデバイス（ＵＥ）の動作を示すフローチャートである。 一実施例によるネットワークノード（例：ＢＳやｇＮＢ）の動作を示すフローチャートである。 一実施例によるマルチイベント条件付きハンドオーバ（ＣＨＯ）を示す図である。 一実施例によるデュアルイベント条件付きハンドオーバ（ＣＨＯ）の実行を示す図である。 一実施例による無線ステーションまたは無線ノード（例：ＡＰ、ＢＳ、ｇＮＢ、ＲＡＮノード、中継ノード、ＵＥまたはユーザデバイス、またはその他のノード）のブロック図である。

図１は、一実施例による無線ネットワーク１３０のブロック図である。図１の無線ネットワーク１３０では、ユーザデバイス１３１、１３２、１３３および１３５は、移動局（ＭＳ）またはユーザ機器（ＵＥ）とも呼ばれ、基地局（ＢＳ）１３４と接続（および通信）することができ、基地局（ＢＳ）は、アクセスポイント（ＡＰ）、拡張型ノードＢ（ｅＮＢ）、ＢＳ、次世代ノードＢ（ｇＮＢ）、次世代拡張型ノードＢ（ｎｇ－ｅＮＢ）、またはネットワークノードとも呼ばれる。ユーザデバイスとユーザ機器（ＵＥ）という用語は、同じ意味で使用されることがある。ＢＳは、ＲＡＮノードを含むこともあれば、ＲＡＮ（無線アクセスネットワーク）ノードと呼ばれることもあり、ＢＳの一部またはＲＡＮノードの一部（例えば、分割ＢＳの場合の集中型ユニット（ＣＵ）や分散型ユニット（ＤＵ）など）を含むこともある。ＢＳの機能の少なくとも一部（例：アクセスポイント（ＡＰ）、基地局（ＢＳ）または（ｅ）ノードＢ（ｅＮＢ）、ＢＳ、ＲＡＮノード）は、リモートラジオヘッドなどのトランシーバに動作可能に結合される任意のノード、サーバまたはホストによっても実行される場合がある。ＢＳ（またはＡＰ）１３４は、セル１３６内で、ユーザデバイス（またはＵＥ）１３１、１３２、１３３および１３５を含む無線カバレッジを提供する。４つのユーザデバイス（またはＵＥ）のみがＢＳ１３４に接続または接続されているように表示されるが、任意の数のユーザデバイスを提供できる。ＢＳ１３４は、Ｓ１インターフェイスまたはＮＧインターフェイス１５１を介してコアネットワーク１５０にも接続される。これは無線ネットワークの単純な一例にすぎず、他のものを使用することもできる。

基地局（例：ＢＳ１３４）は、無線ネットワーク内の無線アクセスネットワーク（ＲＡＮ）ノードの一例である。ＢＳ（またはＲＡＮノード）は、アクセスポイント（ＡＰ）、ｇＮＢ、ｅＮＢ、またはその一部（分割されたＢＳまたは分割されたｇＮＢの場合の集中型ユニット（ＣＵ）および／または分散型ユニット（ＤＵ）など）、またはその他のネットワークノードである場合もあれば、これらを含む場合もある（または代わりにこれらで呼ばれる場合もある）。

例示的な例によると、ＢＳノード（例：ＢＳ、ｅＮＢ、ｇＮＢ、ＣＵ／ＤＵ、・・・）または無線アクセスネットワーク（ＲＡＮ）は、移動体通信システムの一部である場合がある。ＲＡＮ（無線アクセスネットワーク）は、例えば、１つ以上のＵＥがネットワークまたはコアネットワークにアクセスできるようにするために、無線アクセス技術を実装する１つ以上のＢＳまたはＲＡＮノードを含む場合がある。したがって、例えば、ＲＡＮ（ＲＡＮノード（ＢＳやｇＮＢなど））は、１つ以上のユーザデバイスまたはＵＥとコアネットワークの間に存在する場合がある。一例の実施形態によれば、各ＲＡＮノード（例：ＢＳ、ｅＮＢ、ｇＮＢ、ＣＵ／ＤＵ、・・・）またはＢＳは、例えば、ＵＥがＲＡＮノードを介してネットワークに無線アクセスできるようにするために、１つ以上のＵＥまたはユーザデバイスに対して１つ以上の無線通信サービスを提供する場合がある。各ＲＡＮノードまたはＢＳは、例えば、ＵＥまたはユーザデバイスがＲＡＮノードへの無線接続を確立できるようにしたり、１つ以上のＵＥに対してデータを送信および／または受信したりするような無線通信サービスを実行または提供する場合がある。例えば、ＵＥへの接続を確立した後、ＲＡＮノード（例：ＢＳ、ｅＮＢ、ｇＮＢ、ＣＵ／ＤＵ、・・・）は、ネットワークまたはコアネットワークから受信したデータをＵＥに転送したり、ＵＥから受信したデータをネットワークまたはコアネットワークに転送したりする場合がある。ＲＡＮノード（例：ＢＳ、ｅＮＢ、ｇＮＢ、ＣＵ／ＤＵ、・・・）は、制御情報（例えば、システム情報など）をＵＥにブロードキャストする、ＵＥに配信するデータがある場合にＵＥをページングする、ＵＥのセル間ハンドオーバを支援する、ＵＥからのアップリンクデータ送信およびＵＥへのダウンリンクデータ送信のためのリソースのスケジューリング、１つ以上のＵＥを構成するための制御情報の送信など、その他の多種多様な無線機能またはサービスを実行する場合がある。これらは、ＲＡＮノードまたはＢＳが実行する可能性のある１つ以上の機能のいくつかの例である。基地局は、ＩＡＢ（Ｉｎｔｅｇｒａｔｅｄ Ａｃｃｅｓｓ ａｎｄ Ｂａｃｋｈａｕｌ）ノードのＤＵ（Ｄｉｓｔｒｉｂｕｔｅｄ Ｕｎｉｔ）の一部である場合もある（別名中継ノード）。ＤＵは、ＩＡＢノードのアクセスリンク接続を容易にする。

ユーザデバイス（ユーザ端末、ユーザ機器（ＵＥ）、モバイル端末、携帯無線機器など）は、これに限定されないが、移動局（ＭＳ）、移動電話、携帯電話、スマートフォン、携帯情報端末（ＰＤＡ）、ハンドセット、無線モデム（警報または測定デバイスなど）を使用するデバイス、ラップトップおよび／またはタッチスクリーンコンピュータ、タブレット、ファブレット、ゲームコンソール、ノートブック、車両、センサ、およびマルチメディアデバイス、および、例として、または任意の他の無線デバイスを含む、加入者識別モジュール（ＳＩＭ）の有無にかかわらず動作する無線移動通信デバイスを含むポータブルコンピューティングデバイスを指す場合がある。ユーザデバイスは、ネットワークに画像またはビデオクリップをロードするカメラまたはビデオカメラを例とする、ほぼ排他的なアップリンク専用デバイスであり得る（または含むこともある）。ユーザデバイスは、ＩＡＢ（Ｉｎｔｅｇｒａｔｅｄ Ａｃｃｅｓｓ ａｎｄ Ｂａｃｋｈａｕｌ）ノードのＭＴ（Ｍｏｂｉｌｅ Ｔｅｒｍｉｎａｔｉｏｎ）部分である場合もある（別名中継ノード）。ＭＴは、ＩＡＢノードのバックホール接続を容易にする。

ＬＴＥでは（例示的な例として）、コアネットワーク１５０は進化したパケットコア（ＥＰＣ）と呼ばれることがあり、これには、ＢＳ間のユーザデバイスのモビリティ／ハンドオーバを処理または支援する可能性のあるモビリティ管理エンティティ（ＭＭＥ）、ＢＳとパケットデータネットワークまたはインターネットの間でデータおよび制御信号を転送する可能性のある１つ以上のゲートウェイ、およびその他の制御機能またはブロックが含まれる場合がある。５Ｇ（ＮｅｗＲａｄｉｏ（ＮＲ）と呼ばれる場合がある）などの他の種類の無線ネットワークにも、コアネットワークが含まれる場合がある。

さらに、説明例として、ここに記載されているさまざまな例の実施形態または技術は、さまざまな種類のユーザデバイスまたはデータサービスの種類に適用される場合もあれば、異なるデータサービスの種類である可能性のあるマルチのアプリケーションが実行されている可能性のあるユーザデバイスに適用される場合もある。Ｎｅｗ Ｒａｄｉｏ（５Ｇ）の開発では、マシンタイプ通信（ＭＴＣ）、拡張型マシンタイプ通信（ｅＭＴＣ）、モノのインターネット（ＩｏＴ）、および／またはナローバンドＩｏＴユーザデバイス、拡張型モバイルブロードバンド（ｅＭＢＢ）、および超信頼性と低遅延の通信（ＵＲＬＬＣ）など、多数の異なるアプリケーションまたは多数の異なるデータサービスタイプがサポートされる場合がある。これらの新しい５Ｇ（ＮＲ）関連アプリケーションの多くは、以前の無線ネットワークよりも一般的に高いパフォーマンスを必要とする場合がある。

ＩｏＴは、インターネットまたはネットワーク接続を持つ可能性のあるオブジェクトのグループを指す場合があり、そのため、これらのオブジェクトは他のネットワークデバイスと情報を送受信できる。たとえば、多くのセンサータイプのアプリケーションやデバイスは、物理的な状態や状態を監視し、イベントが発生したときなどにサーバや他のネットワークデバイスにレポートを送信する場合がある。マシンタイプ通信（ＭＴＣまたはＭａｃｈｉｎｅ ｔｏ Ｍａｃｈｉｎｅ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）は、たとえば、人間の介入の有無にかかわらず、インテリジェントマシン間で完全に自動のデータ生成、交換、処理、および作動を特徴とする場合がある。拡張型モバイルブロードバンド（ｅＭＢＢ）は、現在ＬＴＥで利用可能なものよりもはるかに高いデータレートをサポートする場合がある。

超高信頼かつ低遅延の通信（ＵＲＬＬＣ）は、新しいデータサービスの種類、または新しい使用シナリオであり、Ｎｅｗ Ｒａｄｉｏ（５Ｇ）システムでサポートされる場合がある。これにより、産業オートメーション、自動運転、車両安全、ｅ－ヘルスサービスなど、新しいアプリケーションやサービスが可能になる。３ＧＰＰは、ブロックエラー率（ＢＬＥＲ）１０－５と最大１ｍｓ Ｕ－Ｐｌａｎｅ（ユーザ／データプレーン）遅延に対応する信頼性のある接続性を提供することを目的としている。したがって、たとえば、ＵＲＬＬＣのユーザデバイス／ＵＥは、他の種類のユーザデバイス／ＵＥよりも大幅に低いブロックエラー率と、低い遅延（同時に高い信頼性を必要とするかどうかは問わない）を必要とする場合がある。したがって、たとえば、ＵＲＬＬＣ ＵＥ（またはＵＥ上のＵＲＬＬＣアプリケーション）は、ｅＭＢＢ ＵＥ（またはＵＥ上で実行されるｅＭＢＢアプリケーション）と比較して、はるかに短い遅延を必要とする場合がある。

さまざまな例の実施形態は、ＬＴＥ、ＬＴＥ－Ａ、５Ｇ（Ｎｅｗ Ｒａｄｉｏ（ＮＲ））、ｃｍＷａｖｅ、および／またはｍｍＷａｖｅバンドネットワーク、ＩｏＴ、ＭＴＣ、ｅＭＴＣ、ｅＭＢＢ、ＵＲＬＬＣなど、またはその他の任意の無線ネットワークまたは無線技術など、さまざまな無線技術または無線ネットワークに適用できる。これらの例のネットワーク、技術またはデータサービスの種類は、説明例としてのみ提供される。

ユーザ機器（ＵＥ）のハンドオーバは、接続されたコールまたはＵＥのデータセッションが、セッションを切断せずに１つのセル（または基地局）から別のセル（または基地局）に転送されるプロセスを指す場合がある。５Ｇ／Ｎｅｗ Ｒａｄｉｏ（ＮＲ）などの一部の無線技術では、より高い周波数で動作すると、より高い周波数での回折損失が障害物によって引き起こされる急速な信号の劣化につながる可能性があるため、さらなる移動性の課題が生じる可能性がある。したがって、ＵＥの移動性を確保するために、信頼性が高く効率的なハンドオーバを提供することが望ましい。

例の実施形態によると、条件付きハンドオーバ（ＣＨＯ）を使用して移動性の堅牢性を高めることができる。ＣＨＯの例では、ＣＨＯハンドオーバの準備とＣＨＯハンドオーバの実行を分離することができる。例えば、ＣＨＯの手順の例では、サービングセルによって、ターゲットセルへのＵＥのハンドオーバが事前に準備され、その後、ＵＥとターゲットセル間の無線リンクが十分であるとき、またはＣＨＯの実行条件を満たしたときに、ソースセルからターゲットセルへのＵＥのハンドオーバが実行されることがある。したがって、ＣＨＯは、サービングＢＳ／ｇＮＢ（現在ＵＥにサービスを提供しているソースセルに関連付けられているか、提供している）が可能なマルチのターゲットセルを準備することを可能にし、その後、ＵＥに対してターゲットセルの１つへのハンドオーバが実行されることがある。ＣＨＯの利点は、ＵＥと送信元セル間の無線リンクが良好な状態のまま、送信元セル（または送信元／サービングＢＳ／ネットワークノード）から事前にハンドオーバ（ＨＯ）コマンドがＵＥに送信され、その後、ＣＨＯ実行条件が実現された場合に、ＵＥがＣＨＯを実行できることである。前述のように、想定されるハンドオーバのために送信元セルによってターゲットセルが準備された後、送信元セル（サービングＢＳ／ネットワークノード）は、ターゲットセル構成（例えば、ＵＥのターゲットセル内のランダムアクセス／ＲＡＣＨリソースの表示を含む）、およびＣＨＯ実行の実行に使用されるイベント構成（イベントの１つ以上のパラメータを含む）を提供するハンドオーバ（ＨＯ）コマンドをＵＥに送信することができる。ＵＥは、ＣＨＯ実行条件が実現された場合にＣＨＯ実行を行うことができる。ＣＨＯ実行条件は、通常、１つ以上のイベントに基づいている。たとえば、単一のイベントを使用して、イベントの開始条件が少なくとも時間トリガ（Ｔｉｍｅ－Ｔｏ－Ｔｒｉｇｇｅｒ）の時間実現された場合、ＵＥはターゲットセルに対してＣＨＯ実行を実行（トリガー）することができる。

ＵＥは、ソースセルまたはソース／サービングネットワークノード（ｇＮＢ／ＢＳ）から、ターゲットセルの条件付きハンドオーバ（ＣＨＯ）実行条件の構成を受信することができ、これには、ＣＨＯ実行条件を定義するか、またはＵＥがＣＨＯ実行条件を判定するために使用する可能性のある１つ以上のパラメータが含まれる場合がある。たとえば、ＣＨＯ実行条件の構成には、イベントの開始条件または終了条件を定義する可能性のあるイベントの１つ以上のパラメータを含むイベント構成が含まれる場合がある。単一のイベントＣＨＯでは、イベントの開始条件が時間トリガ（Ｔｉｍｅ－ｔｏ－Ｔｒｉｇｇｅｒ（ＴＴＴ））と呼ばれる最小時間期間に対して実現された場合に、ＣＨＯ実行条件が実現されたり満たされたりすることがある）。たとえば、ＵＥは、ソースセル、および１つ以上の隣接（または潜在的なターゲット）セルから受信した信号の信号測定を随時実行することがある。ＵＥによる測定には、基準信号受信電力（ＲＳＲＰ）、基準信号受信品質（ＲＳＲＱ）、またはその他の信号測定が含まれる場合がある。たとえば、Ａ３イベントの場合、ＣＨＯ実行条件は、ターゲットセルの測定値が、指定された閾値またはオフセットよりも優れている（例えば、より大きい）必要があることを示す場合がある。たとえば、ＣＨＯ実行条件は、ソースＢＳ（ソースノード）からＵＥに送信される可能性のある再構成メッセージ（例：Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ（ＲＲＣ）再設定メッセージ、またはｈａｎｄｏｖｅｒコマンド）内のソースノード（ソースＢＳ／ｇＮＢ）によって構成される場合がある。

例示的な例として、Ａ３イベントの例は、ＣＨＯ実行条件のための例示的なイベントとして構成され得る。たとえば、ＵＥのＣＨＯ実行は、イベントＡ３についての（（式１）で示される）開始条件が特定の時間トリガ（ＴＴＴ）に対して実現された場合にトリガされる可能性がある。ここで、ＴＴＴは、イベントの開始条件が実現するか満たされてソースセルからターゲットセルへのＵＥのＣＨＯ実行をトリガするまたは引き起こす最小時間期間を指す場合がある。

ここで、Ｍｎはハンドオーバの隣接するターゲットセルの測定値、Ｍｐはサービングセルの測定値、Ｏｃｎはセル個別オフセット（ＣＩＯ）である。パラメータＯｆｎ、Ｏｆｐ、Ｏｃｐ、Ｏｆｆ、およびＨｙｓは、ネットワークによって構成される可能性のあるその他のオフセットである（また、条件付きハンドオーバ実行条件の構成で示される場合がある）。（（式１）においてＯｃｎとして示される）ＣＩＯは、そのような隣接セル測定を（たとえば、正のＣＩＯを介する）ＵＥハンドオーバにとってより魅力的にするために、または（たとえば、負のＣＩＯを介する）ＵＥハンドオーバにとってあまり魅力的ではなくするために、隣接セル測定に特に適用され得る（およびこのターゲット／隣接セルに固有であり得る）オフセットであり得る。

Ａ３イベントの終了条件は、以下の（式２）によって定義されてもよい。

Ａ３イベントは、イベントＡ３の開始条件が単一の閾値を採用しているので、単一の閾値イベント、または非デュアル閾値イベントの例である。したがって、Ａ３イベントの場合、開始条件は、ターゲット（または近隣）セルの測定値が、少なくともソースセルの測定値よりも優れた閾値になる必要がある。

別の例のイベントであるイベントＡ５は、Ａ５イベントが２つの閾値を採用して、イベントの開始条件（または終了条件）が実現されているかどうかを判定するので、デュアル閾値イベントの例である。Ａ５イベント（式は示されていない）の場合、開始条件では、ソースセルの測定値が第１の閾値よりも悪く（例えば、低い）、ターゲットセルが第２の閾値よりも良好（例えば、より強い、またはより大きい）である必要がある。Ａ３イベントとＡ５イベントはイベントの一例であり、他のイベントがＣＨＯの実行に使用されてもよい。

また、ＵＥ ＣＨＯの実行の信頼性やパフォーマンスを向上させるために、ＣＨＯの実行はマルチイベント（例：デュアルイベントＣＨＯ実行）に基づく場合がある。また、マルチイベントは、基準信号受信電力（ＲＳＲＰ）や基準信号受信品質（ＲＳＲＱ）など、異なる信号パラメータの測定に基づく場合がある。したがって、複数イベント条件付きハンドオーバは、異なるイベント（例：Ａ３イベント＋Ａ５イベント）を使用する場合もあれば、例えば、ＲＳＲＰに基づくＡ３イベント＋ＲＳＲＱに基づくＡ３イベント、ＲＳＲＰに基づくＡ３イベント＋ＲＳＲＱに基づくＡ５イベント、または、ＲＳＲＰに基づくＲＳＲＱ＋Ｒ５イベントに基づくＡ３イベントなど、同じイベントまたは異なるイベントに基づいて異なる信号パラメータを測定する場合もある。

ＵＥは、たとえば、ソースセルまたはサービングネットワークノードから、例えば、（例えば、ＵＥのためのランダムアクセス／ＲＡＣＨリソースを示す）ターゲットセル構成、ＣＨＯ実行条件、および（たとえば、イベントのイベント構成が、イベント（たとえば、Ａ３またはＡ５イベント）、測定される信号パラメータ（たとえば、ＲＳＲＰまたはＲＳＲＱ）、１つまたは複数のオフセット、イベントの入力条件に対するヒステリシス、および／またはイベントに対するＴＴＴ値のうちの１つまたは複数を含むかまたは識別することができる場合の）複数のイベントの内のイベントのためのイベント構成、のうちの１つまたは複数を含み得るハンドオーバコマンドとともに、複数イベントＣＨＯ構成を受信することができる。したがって、各イベントには、イベントの１つ以上のパラメータ、たとえば、イベントタイプの１つ以上（例：Ａ３イベント、Ａ５イベント）、測定される信号パラメータ（例：ＲＳＲＰまたはＲＳＲＱ）、開始条件についてのオフセット、ＴＴＴ値などを指定できる、独自のイベント構成を含めることができる。

複数イベントＣＨＯ実行条件は、事前にＵＥが知っている場合もあれば、複数イベントＣＨＯ構成の一部としてＵＥにシグナリングされる場合もあり、複数イベントの各イベントのステータスや条件、または複数イベントＣＨＯ実行に対するＣＨＯ実行条件が実現される（すなわち、ＣＨＯ実行をトリガする）ために発生する必要があるイベント間の関係を示す場合もある。たとえば、デュアルイベント（第１のイベントおよび第２のイベント）に基づくデュアルイベントＣＨＯ実行の場合、ＵＥは、第１のイベントおよび第２のイベントの両方を共同で評価して（ここで、ＵＥは、両方のイベントの態様を評価し、例えば、場合によっては、両方のイベントの態様を同時に評価する）、マルチイベントＣＨＯ実行は、第２のイベントに対する時間トリガ（ＴＴＴ）タイマが満了したときに、既に満了した時間トリガ（ＴＴＴ）タイマを有する第１のイベントが第１のイベントに対する終了条件を実現しない場合にＵＥによって実行されるという、複数イベントＣＨＯ実行条件が満たされたかどうかを判定することができる。これは複数イベントＣＨＯ実行条件の例であるが、他のものを用いてもよい。

場合によっては、ＣＨＯが障害することがあり得、たとえば、ＵＥの無線リンク障害（ＲＬＦ）またはハンドオーバ（ＨＯ）障害をもたらし得る。ＨＯ障害は、ＵＥがターゲットセルへのランダムアクセスの実行に失敗したときに発生し得る。無線リソース制御（ＲＲＣ）接続モード（たとえば、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤモード）では、ＵＥは、典型的には、無線リンク監視（ＲＬＭ）と呼ばれるサービングセル無線リンクを監視し得、ＲＬＭ測定を実行する。ＲＬＭ測定は、無線リンクを維持するのに充分な（例えば充分な）ダウンリンク（ＤＬ）無線リンク品質が良好であるかどうかを判定するために、および／または無線リンクの品質が定義された閾値（例えば、無線リンクがもはやデータ送信に充分な品質を提供できないことが予想されるとき）を下回るときを上位層に示すために、サービングセル無線リンク品質を評価することを支援する。ＲＬＭは、特定の状況下で無線リンク障害を検出または宣言するために、ＵＥまたはユーザデバイスが、ＵＥとサービングｇＮＢまたはサービングセルとの間の無線リンクを監視するプロセスを含み得る。

単一イベントＣＨＯの場合、ＵＥはＲＬＦまたはＨＯ障害の直前に情報を収集および／または格納し、ネットワークに報告する場合がある。しかしながら、この収集された情報は単一イベントＣＨＯ実行用であり、範囲は非常に限られている。例えば、ＲＬＦやＨＯの障害の原因となった可能性のあるイベントをＵＥが判定できるようにする、ＣＨＯの実行性能を向上させるためにパラメータをどのように調整できるかをＵＥが判定できるようにするなど、複数イベントのＣＨＯ実行に関連するより詳細な情報を提供する必要がある。

図２は、一実施例によるユーザデバイス（ＵＥ）の動作を示すフローチャートである。動作２１０は、無線ネットワーク内のユーザデバイス（ＵＥ）による、複数イベント条件付きハンドオーバ実行に関する情報のログ記録を含み、複数イベント条件付きハンドオーバ実行は、ユーザデバイスによる複数イベントの共同評価に基づいている。ログ記録には、ログまたはレコードの作成または保持が含まれる場合がある。ログ記録には、たとえば、条件付きハンドオーバの実行に関して、ユーザデバイスまたはＵＥのイベントまたはイベント関連条件に関連する情報を記録（または保存）できるログまたはレコードの作成が含まれる場合がある。たとえば、複数イベントの条件付きハンドオーバの実行に関連するログ情報には、たとえば、さまざまなイベント関連条件のログ記録または保存が含まれる場合がある。イベント関連条件には、たとえば、イベントの時間トリガタイマのステータス（開始されていない、開始された、開始後に停止された、または、満了した）、イベントの開始条件を実現するイベント、イベントの終了条件を実現するイベント、ユーザデバイスのハンドオーバ障害の発生、またはマルチイベント条件付きハンドオーバ実行の実行条件が実現されているか否か、のいずれかのステータスを含む）が１つ以上含まれる場合がある。例えば、イベント関連条件の発生のログ記録、イベント関連条件の発生時刻、イベント関連条件の発生回数、異なるイベント（例えば、特定のイベント関連条件が最初に発生したイベントはどれか）のイベント関連条件の発生の関係（例えば、順序やタイミング）など、複数イベントＣＨＯ実行のイベントに関連する情報が記録される。

複数イベント条件ハンドオーバ実行は、ユーザデバイスによる複数イベントの共同評価に基づく場合があり、例えば、複数イベントＣＨＯ実行条件が実現されたかどうかを判定するために、様々な時点（例えば、両方のイベントの状態関連イベントを同時にまたは同時に評価することが含まれる場合がある）での両方のイベントの（例えば、１つ以上の条件関連イベントなど）に関連する情報を評価するＵＥ／ユーザデバイスを含む場合がある。複数イベントＣＨＯ実行条件が満たされたか実現された場合、ＵＥはターゲットセルに対してＣＨＯ実行を実行する場合がある（または典型的には実行する）。

また、図２に関して、操作２２０は、ユーザデバイスまたはＵＥによって、情報の少なくとも一部を含むレポートを送信することを含む。したがって、レポートには、ＵＥによって記録された情報の少なくとも一部が含まれる場合がある。レポート（例えば、これにはログに記録された情報が含まれることがある）は、ＲＬＦまたはＨＯの障害の検出後（ＢＳ、ｇＮＢ）、またはネットワークノードからの要求に応答して、ＵＥによってネットワークノードまたはネットワークに送信される場合がある。たとえば、複数イベントＣＨＯ実行に関連する情報のログを記録してから、より詳細なログを送信することで、ネットワーク、送信元ネットワークノード（例：ソースＢＳ／ｇＮＢ）、またはその他のネットワークノードまたはネットワークが、ＣＨＯ実行条件の構成に関連付けられた１つ以上のパラメータを変更したり、複数イベントＣＨＯ実行の１つ以上のイベントの１つ以上のパラメータを変更したりできるようになり、たとえば、ＣＨＯ実行の信頼性とパフォーマンスを向上させることができる。例では、複数イベント条件付きハンドオーバ実行には、２つのイベントの共同評価に基づくデュアルイベント（２イベント）条件付きハンドオーバ実行が含まれる場合がある。

図２に関して、送信には、ユーザデバイスに対してハンドオーバ障害または無線リンク障害が発生した後に、ユーザデバイスがセルへの接続を再確立した後に、情報の少なくとも一部を含むレポートをユーザデバイスによって送信することが含まれる場合がある。

図２の方法に関して、送信には、無線リンク障害またはハンドオーバ障害に対応して、情報の少なくとも一部を含むレポートをユーザデバイスによって送信することが含まれる場合がある。または、ネットワークノードからの要求に対応して、情報の少なくとも一部を含むレポートをユーザデバイスによって送信することが含まれる場合がある。

図２の方法に関して、マルチイベント条件付きハンドオーバ実行は、複数のイベントに基づいてもよく、ここで、ログには、少なくとも、複数のイベントの１つ以上のイベントについて、イベント関連条件の発生のログ、イベント関連条件の発生回数、またはイベント関連条件の発生の時間またはタイミングを含めることができる。

図２の方法に関して、イベント関連条件は、イベントのための時間トリガの状態であって、開始されていない、開始された、開始後に停止された、または満了されたのいずれかの状態を含む状態、イベントの開始条件を満たすイベント、イベントの終了条件を満たすイベント、ユーザ装置に対するハンドオーバ障害の発生、または、マルチイベント条件付きハンドオーバ実行の実行条件が実現されているか否か、のうちの少なくとも１つを含み得る。

図２の方法に関して、ログ記録することは、複数のイベントのうちの１つ以上についてイベント関連条件が発生したかどうかを示すログ情報、複数のイベントのうちの１つ以上についてイベント関連条件が発生した回数を示すログ情報、複数のイベントのうちの少なくとも２つのイベントのイベント関連条件の時間関係またはそれらの間の時間差を記録するステップと、複数のイベントのうちの１つ以上についてイベント関連条件が発生した時間を示すログ情報、いずれのイベントについてイベント関連条件が最初に発生したかを示すログ情報、または、複数のイベントがマルチイベント条件付きハンドオーバ実行の実行条件を満たさないことに起因して、ユーザデバイスに対するハンドオーバの障害の回数を記録するログ情報、のうちの少なくとも１つを含み得る。

また、ログ記録することは、たとえば、もしあれば、いずれのイベントがイベントの開始条件を満たし、時間トリガタイマを開始したかを示すログ情報、もしあれば、いずれのイベントがイベントの開始条件を満たし、時間トリガタイマを開始し、時間トリガタイマが満了したかを示すログ情報、ユーザデバイスによるマルチイベントの共同評価に基づくマルチイベント条件付きハンドオーバ実行の実行条件の実現の有無を示すログ情報、既に満了した時間トリガタイマを有する第１イベントが、第２イベントの時間トリガタイマが満了したときに第１イベントの終了条件を満たすか否かを示すログ情報、または、もしあれば、いずれのイベントがイベントに対する開始条件を満たしたかを示し、タイム・トゥ・トリガ・タイマを開始し、イベントに対するタイム・トゥ・トリガ・タイマは、満了する前に停止されたかを示すログ情報のうちの１つまたは複数を含む、複数のイベントのうちの１つまたは複数についてイベント関連条件が発生したかどうかを示すログ情報を含むことができる。

図２の方法に関して、ログには、複数のイベントのうちの１つ以上に対してイベント関連の状態が発生した回数を示すログ情報が含まれる場合があり、例えば、もしあれば、各イベントが発生した場合に、その時間トリガタイマが何回開始したかを示すログ情報や、イベントの時間トリガタイマが満了する前に停止したことを示すログ情報が含まれる場合がある。

図２の方法に関して、ログは、第２イベントに対する第２イベント関連条件に関する第１イベントに対する第１イベント関連条件の関係を示す情報のログを少なくとも含み得、これは、第１イベントの第１イベント関連条件と第２イベントの第２イベント関連条件との順序、第１イベントに対する第１イベント関連条件の発生と第２イベントの第２イベント関連条件の発生との間の時間、または、第１イベントについての第１イベント関連条件の発生の時間および第２イベントについての第２イベント関連条件の発生の時間、のうちの少なくとも１つを含み得る。

図２の方法に関して、関係を示す情報のログは、第１イベントまたは第２イベントが最初に開始条件を実現したかどうかのログ、時間トリガタイマの内の１つが停止したまたは満了したときの第１イベントおよび第２イベントの時間トリガタイマの値を記録するログ、または、第１イベントおよび第２イベントの時間トリガタイマが並行して動作していた時間または期間を記録するログのうちの少なくとも１つを含み得る。

図２の方法に関して、ログは、例えば、イベントの時間トリガタイマが起動された時刻を示すログ情報、イベントに対する時間トリガタイマが満了した時刻を示すログ情報、イベントの時間トリガタイマが停止した時刻を示すロギング情報、または、第１イベントの時間トリガタイマと第２イベントの時間トリガタイマが並行して動作していた時刻を示すログ情報のうちの少なくとも１つを含む、複数のイベントのうちの１つまたは複数についてイベント関連条件が発生した時間を示すログ情報を含み得る。

図２の方法に関して、ログには、どのイベントに関連する条件が最初に発生したかを示すログ情報を含めることができ、例えば、もしあれば、いずれのイベントがイベントの開始条件を満たし、最初に時間トリガタイマを開始したかを示すログ情報、もしあれば、いずれのイベントが最初に時間トリガタイマを満了したかを示すログ情報、または、いずれのイベントがイベントの開始条件を満たし、時間トリガタイマを開始し、次いで時間トリガタイマを最初に停止したかを示すロギング情報、のうちの少なくとも１つを含み得る。

図２の方法に関して、ログに記録される情報には、さまざまなカウンタによってカウントまたは追跡される可能性のある多数の障害（例：ＨＯ障害やＲＬＦ）が含まれる場合がある。したがって、たとえば、マルチイベント条件付きハンドオーバ実行の実行条件を実現していない複数のイベントによるユーザデバイスの条件付きハンドオーバの障害数をカウントする障害カウンタのログがログに記録される場合がある。これは、第１イベントと第２イベントの両方が非デュアル閾値測定イベントである場合の、第１イベントに対する時間トリガタイマが満了しなかった場合の条件付きハンドオーバ障害の数、または、第２イベントに対する時間トリガタイマが満了しなかった場合の条件付きハンドオーバ障害の数、の情報の１つ以上を記録するログを含み得る。

障害カウンタをログ記録することは、第１イベントと第２イベントの両方がデュアル閾値測定イベントである場合の、ソースセル測定値が第１の閾値以下ではなかったため、第１イベントに対する時間トリガタイマが満了しなかったときの条件付きハンドオーバ障害の数、ターゲットセル測定値が第２の閾値よりも大きくなかったため、第２イベントに対する時間トリガタイマが満了しなかったときの条件付きハンドオーバ障害の数、ソースセル測定値が第１の閾値以下ではなかったため、第２イベントに対する時間トリガタイマが満了しなかったときの条件付きハンドオーバ障害の数、または、ターゲットセル測定値が第２の閾値よりも大きくなかったため、第１イベントに対する時間トリガタイマが満了しなかったときの条件付きハンドオーバ障害の数、の情報のうちの１つまたは複数をログ記録することを含み得る。

または、障害カウンタのログには、第１イベントの時間トリガタイマが満了し、第２イベントの時間トリガタイマが満了したが、第２イベントの時間トリガタイマが満了したときに第１イベントの終了条件が実現されたことに基づく条件付きハンドオーバの障害数のログが含まれる場合がある。

図２に関して、ログは、例えば、第１イベントの構成及び／又は第２イベントの構成を記録すること、もしあれば、いずれのイベントがイベントの開始条件を実現し、時間トリガタイマを開始したかを示すログ情報、もしあれば、いずれのイベントがイベントの開始条件を実現し、時間トリガタイマを開始し、イベントの時間トリガタイマが満了したかを示すログ情報、マルチイベント条件付きハンドオーバ実行の実行条件の実現の有無を示すログ情報、既に満了した時間トリガタイマを有する第１のイベントが、第２のイベントの時間トリガタイマが満了したときに第１のイベントの離脱条件を実現するか否かを示すログ情報、もしあれば、いずれのイベントが時間トリガタイマを開始し、イベントについての時間トリガタイマが満了する前に停止されたかを示すログ情報、もしあれば、いずれのイベントが時間トリガタイマを開始したかを示し、イベントについての時間トリガタイマが満了する前に停止されたことを示すログ情報、第１イベントまたは第２イベントが最初に開始条件を実現するかどうかを記録することと、時間トリガタイマのうちの１つが停止または満了したときに、第１イベントおよび第２イベントの時間トリガタイマの値を記録すること、第１イベント及び第２イベントの時間トリガタイマが並行して動作していた時間又は期間を記録すること、イベントの時間トリガタイマが起動された時刻を示すログ情報、イベントに対する時間トリガタイマが満了した時間を示すログ情報、イベントの時間トリガタイマが停止した時刻を示すログ情報、第１イベントに対する時間トリガタイマが、第２イベントに対する時間トリガタイマと並行して動作していた時間を示すログ情報、もしあれば、いずれのイベントがイベントの開始条件を満たし、最初に時間トリガタイマを開始したかを示すログ情報、もしあれば、いずれのイベントが時間トリガタイマを最初に満了したかを示すログ情報、もしあれば、いずれのイベントがイベントの開始条件を実現し、時間トリガタイマを開始し、次いで時間トリガタイマを最初に停止したかを示す情報を記録すること、または、複数イベントがマルチイベント条件付きハンドオーバ実行の実行条件を実現しないことによるユーザデバイスの条件付きハンドオーバの障害の回数をカウントする障害カウンタを記録すること、のうちの１つまたは複数を含み得る。

図２の方法に関して、この方法は、少なくとも第１のイベントの構成と第２イベントの構成を含むマルチイベントのそれぞれの構成と、条件付きハンドオーバ実行を行うかどうかを判定するためにユーザデバイスによるマルチイベントの共同評価を構成する共同評価構成を含む、条件付きハンドオーバの一部として、ユーザデバイスが前記ネットワークノードから、ハンドオーバコマンドを受信することをさらに含むことができる。

図２の方法に関して、この方法は、さらに、ソースネットワークノードからターゲットネットワークノードへのユーザデバイスの条件付きハンドオーバ実行を実行するかどうかを判定するために、ユーザデバイスによって複数のイベントを共同で評価することを含むことができる。

図３は、一例の実施形態によるネットワークノード（例：ＢＳ、ｇＮＢまたはその他のネットワークノード）の動作を示すフローチャートである。動作３１０は、ユーザデバイスによる条件付きハンドオーバ実行のために共同で評価されるマルチイベントの構成を含む共同イベント構成情報を持つハンドオーバコマンドを、ネットワークノードによってユーザデバイスに送信することを含む。動作３２０は、ユーザデバイスによるマルチイベント条件付きハンドオーバ実行の障害に関するユーザデバイスによって記録された情報を含むレポートをネットワークノードによって受信することを含み、マルチイベント条件付きハンドオーバ実行は複数のイベントに基づいている。また、動作３３０は、レポートに基づいてネットワークノードによって、マルチイベント条件付きハンドオーバ実行のための一つ以上のイベントの構成に関連付けられた一つ以上のパラメータを変更することを含む。

図３の方法について、共同イベント構成情報は、条件付きハンドオーバ実行を行うかどうかを判定するために、ユーザデバイスによるマルチイベントの共同評価を構成する共同評価構成を含む。共同イベント構成情報には、ＣＨＯ実行条件、マルチイベントのそれぞれの構成などを記述する情報が含まれる場合がある。

図３の方法について、ユーザデバイスが記録する情報には、複数のイベントのうち１つ以上のイベント関連条件の発生、イベント関連条件の発生回数、イベント関連条件の発生時刻や発生タイミングなどが含まれる場合がある。前述のように、イベント関連の条件は、例えば、イベントのための時間トリガタイマの状態であって、開始されていない、開始された、開始後に停止された、または満了したのいずれかの状態を含む状態、イベントの開始条件を実現するイベント、イベントの終了条件を満たすイベント、ユーザデバイスに対するハンドオーバ障害の発生、または、マルチイベント条件付きハンドオーバ実行の実行条件が実現されているか否か、のうちの少なくとも１つを含んでもよい。

図３の方法に関して、ユーザデバイスによって記録された情報は、複数のイベントのうちの１つ以上についてイベント関連条件が発生したかどうかを示す情報、複数のイベントのうちの１つ以上についてイベント関連条件が発生した回数を示す情報、複数のイベントのうちの少なくとも２つのイベントのイベント関連条件の間の時間関係又は時間差、複数のイベントのうちの１つ以上についてイベント関連条件が発生した時間を示す情報、どのイベントについてイベント関連条件が最初に発生したかを示す情報、または、複数のイベントが複数イベント条件付きハンドオーバ実行の実行条件を実現しないことによるユーザデバイスのハンドオーバの障害の回数、のうちの少なくとも１つを含み得る。

図４は、一実施例によるマルチイベント条件付き引き継ぎ（ＣＨＯ）を示す図である。図４に示すように、ＵＥ１３２、ソースセルに対応付けられたサービングノード２１０（例：ＢＳへのサービス提供）、ターゲットセルに対応付けられたターゲットノード２１４を示す。また、例えば、サービングゲートウェイ／ユーザプレーン機能（Ｓ－ＧＷ／ＵＰＦ）、モビリティ管理エンティティ／アクセスおよびモビリティ管理機能（ＭＭＥ／ＡＭＦ）機能を含むコアネットワークエンティティも示す。操作１～１６を図４に示す。たとえば、処理１～６をＣＨＯ準備に関連付け、処理７～１６をＣＨＯ実行に関連付けることができる。処理１では、測定レポート（複数可）がサービングノード２１０に送信され、たとえば、ソースセルと１つ以上のターゲットセルのＲＳＲＰ（またはその他の信号測定）を示し、サービングノード２１０がＵＥのハンドオーバの可能性がある１つ以上のターゲットセルを判定できるようにする。

図４の処理２では、サービングノード２１０は、たとえば、１つ以上の（可能な）ターゲットセルへのＵＥの条件付きハンドオーバを実行するようにＣＨＯ決定を行うことができる。処理３では、ＣＨＯ要求がターゲットセルに関連付けられているターゲットノード２１４に送信される。表示されていないＣＨＯ要求は、他のターゲットノードに送信される場合がある。処理４で、ターゲットノード２１４は、要求されたＵＥ１３２のハンドオーバを受け入れる決定を行うためにアドミッション制御を実行する。処理５で、ターゲットノード２１４はＣＨＯ要求確認応答を送信し、ＵＥ１３２の要求されたＣＨＯをターゲットセルに受け入れまたは確認し、ターゲットセルのターゲットセル構成を提供する。

図４の処理６で、ＵＥはハンドオーバ（ＨＯ）コマンドによる再構成メッセージ（例：ＲＲＣの再構成）を受信する。ＲＲＣメッセージには、例えば、マルチイベントＣＨＯ構成も含まれ、これには、ターゲットセル構成（例えば、ランダムアクセスプリアンブル伝送／ＲＡＣＨのターゲットリソースを含む）、マルチイベントＣＨＯ実行条件の表示（例えば、マルチイベントに対して、どのような特定の条件またはイベント関連の条件が存在するか、または発生したかを示して、ＣＨＯの実行をターゲットセルにトリガすることができる。）、およびマルチイベントのイベント構成のうちの１つ以上が含まれる場合がある。たとえば、イベント構成には、イベントの開始条件の１つ以上のパラメータ（例：ｔｈｒｅｓｈｏｌｄ、ｈｙｓｔ、ＣＩＯ、Ｏｆｆまたはｏｆｆｓｅｔ、またはイベントの開始条件のその他のパラメータ、ＴＴＴ値）が含まれる場合がある。マルチイベントＣＨＯ実行条件の表示には、たとえば、複数の可能なＣＨＯ実行条件の中から、特定のマルチイベントＣＨＯ実行条件を示すフィールドまたはパラメータが含まれる場合がある。たとえば、２つのイベント（第１のイベントと第２のイベント）に基づくデュアルイベントＣＨＯ実行の場合、第２イベントの時間トリガ（ＴＴＴ）タイマが満了になったときに、すでに満了になっている時間トリガ（ＴＴＴ）タイマを持つ第１イベントが第１イベントの終了条件を実現しなかった場合、マルチイベントＣＨＯ実行がＵＥによって実行されるという例が挙げられる。これはマルチイベントＣＨＯ実行条件の一例であり、他のものを使用できる。場合によっては、マルチイベントＣＨＯ実行条件が事前に構成されているか、またはＵＥによって事前に知られていることがある。

図４の処理７では、マルチイベントＣＨＯ実行に関連する情報のログ記録を実行し、マルチイベントの共同評価（例えば、マルチイベントの評価や、マルチイベントの様々な事象関連の状態を、様々な時点で同時に評価すること）を実行して、ＣＨＯ実行条件が実現されたかどうかを判定する場合がある。

図４の処理８では、ＵＥはマルチイベントＣＨＯ実行条件が実現されたと判定する（例えば、マルチイベントの共同評価に基づいて、ＣＨＯ実行をターゲットセル／ターゲットノードにトリガし、ＵＥ１３２をソースノードから切り離して、ソースノードとの送受信を停止する。

ＣＨＯ実行中に障害（例：ＲＬＦやＨＯの障害）が発生した場合、ＵＥは（例えば、セルに再接続した後）、マルチイベントＣＨＯ実行に関連するログに記録された情報のすべてまたは一部を含むレポートをネットワークノードに送信することができる。または、マルチイベントＣＨＯ実行に関連するログに記録された情報のすべてまたは一部を含むレポートを、要求に応じてネットワークノードに送信することができる。マルチイベントＣＨＯ実行に関連するログに記録された情報（例：障害）を含むレポートは、ネットワークおよび／またはソースノードがモビリティ堅牢性最適化（ＭＲＯ：Ｍｏｂｉｌｉｔｙ Ｒｏｂｕｓｔｎｅｓｓ Ｏｐｔｉｍｉｚａｔｉｏｎ）を実行できるように、たとえば、ソースノードまたはネットワークが障害の原因となったイベントを判定し、その後、マルチイベントＣＨＯ実行の信頼性および／または動作を向上させるために調整する必要がある（例：障害の原因となった可能性のあるイベントのＴＴＴまたはオフセットの調整）マルチイベントＣＨＯ実行に関連する１つ以上のパラメータまたは機能を判定するために、ソースノードに転送される場合がある。

図４の残りの処理９～１６は、障害がないことを前提としたＣＨＯ実行の一部である（例えば、ＲＬＦやＨＯの障害がないと仮定する）。

図４の９で、サービングノード２１０／ソースセルは、ＵＥ１３２とのデータの送受信を停止し、ＵＥのＤＬデータをターゲットノード２１４に転送し始める。ソースノード２１０がターゲットノード２１４に転送するＤＬデータには、ソースノード２１０がＵＥ１３２に送信したが、ＵＥが確認応答していないＤＬ（ダウンリンク）データ、およびソースノード２１０が受信したが、まだＵＥ１３２に送信されていない（コアネットワークからの）新規受信ＤＬデータが含まれる場合がある。

図４の処理１０、１１では、１０でのシーケンス番号ステータス転送、処理１１でのデータ転送を含むデータ転送が行われる。一例の実施例では、送信元セルは、ＵＥとの送受信を停止した直後にデータ転送を開始する。さらに、送信元セルは、ＤＬおよびＵＬの次の欠落ＰＤＣＰ ＣＯＵＮＴ値、すなわち、ターゲットセルがＤＬで送信またはＵＬで受信すべき次の欠落パケットを定義する、ハンドオーバ「ＳＮステータス転送」メッセージのターゲットセルに送信する。

その後、ＵＥは、ターゲットノード／ターゲットセルとの同期を実行し（例えば、ターゲットノード／ターゲットセルからＰＳＳとＳＳＳを受信する）、その後、ターゲットノード／ターゲットセルとランダムアクセスを実行して、処理１２でＲＡＣＨ（ランダムアクセス）プリアンブルを送信し、処理１３でランダムアクセス（ＲＡＣＨ）応答を受信するなど、ターゲットノード／ターゲットセルとの接続を確立できる。ＵＥがターゲットノード／ターゲットセルへの接続を確立すると、処理１４で、ＵＥ１３２はＲＲＣ再構成完了メッセージ／指示をターゲットノード／ターゲットセルに送信し、処理１５のターゲットノードは、ハンドオーバ成功の指示をサービングノード／ソースセルに応答し、コアネットワークとソースノードおよびターゲットノード間でＵＥトラフィックのパススイッチが処理１６で実行される。

図５は、一実施例によるデュアルイベント条件付きハンドオーバ（ＣＨＯ）の実行を示す図である。図５に示すように、Ａ３イベントを含むマルチ（またはデュアル）イベントＣＨＯの実行と、Ａ５イベントの２つのイベントが用意されている。Ｔ１の時点で、ＣＨＯ（またはハンドオーバ）コマンドは、例えば、ＣＨＯ実行条件を含むマルチイベントＣＨＯ構成、および／または各イベントのイベント構成を含むＵＥによって受信される。したがって、Ｔ１の時点で、この例では、イベントＡ３およびＡ５のイベント構成がＵＥによって受信される。Ｔ２の時点で、ＵＥはイベントＡ３が初めて開始条件を実現したと判定する（つまり、イベントＡ３のＴＴＴタイマを開始する）。Ｔ３の時点で、イベントＡ５が初めてイベントの開始条件を実現したため、Ａ５イベントのＴＴＴタイマを開始する。Ｔ４の時点で、イベントＡ３がトリガされる（Ａ３のＴＴＴタイマが期限切れになる）。Ｔ５の時点で、イベントＡ５がトリガされる（イベントＡ５のＴＴＴタイマが期限切れになる）。５１０で示される時刻Ｔ５（およびその他のさまざまな可能性のある時刻）に、ＵＥは、マルチイベントＣＨＯ実行条件が実現されているかどうかを判定するために、イベントＡ３とＡ５の両方を共同で評価することができる。したがって、Ｔ５でＡ３イベント終了条件がＴ５で真でない場合、ＣＨＯ実行が行われる。マルチイベントＣＨＯ実行に関連する情報のログの一部として記録される可能性のある情報要素（ＩＥ）の例。図５に示された時間とイベントは、記録される可能性のあるＩＥの例のいくつかを説明するのに役立つかもしれない。

イベント１（Ａ３イベント）とイベント２（Ａ５イベント）の両方が、ＣＨＯ実行条件のイベントとしてＵＥに構成され、（マルチイベントに基づく）ＣＨＯ実行条件が実現されたかどうかを判定するなど、１つ以上の時点で同時に評価され、それによってＣＨＯ実行がトリガされるとする。２つのイベントの考えられるタイムラインとその評価を図５に示す。どのイベントが最初にトリガされるか、トリガされるイベント間の時間、１つ以上のポイントでの２つのイベントの共同評価（例えば同時に）がＣＨＯ実行をトリガするかどうかなどがわからないため、記述されたタイムラインには多くの組み合わせ（またはさまざまなイベントに対してさまざまなシナリオやさまざまなイベント関連条件のさまざまな発生）がある可能性があることに注意されたい。図５に示すデュアルイベントのタイムラインは、例として１つの考えられるタイムラインにすぎず、成功したＣＨＯまたは成功したＣＨＯ実行のベストケースシナリオについてさえ説明している。ただし、一般に、Ｔ１とＴ５の間の任意のポイントなど、任意のポイントにＲＬＦが存在する場合がある。

Ｔ１とＴ５の間で何らかの問題（例：ＲＬＦやＨＯ障害などの障害）が発生した場合、ＵＥは通常、（試行された）マルチイベントＣＨＯ実行に関連する情報をログに記録し続け（例えば、マルチイベントの各イベントのイベント関連条件をログに記録する）、ＵＥはネットワークまたはサービングノードにレポート（例えば、ログに記録された情報の全部または一部を含む）を送信する場合がある。ＲＬＦがあった場合、ＵＥは一時的に切断された後、（ランダムアクセスを行うことで）セルに接続または再接続する。

図５には示されていないが、ＵＥに対してはすでにＣＨＯの準備が行われており、Ａ３とＡ５（例）の２つのイベントが構成されており、１つのイベントが最初にトリガされ（Ａ３イベントが開始条件を満たす）、ＴＴＴが開始される。第１イベント（Ａ３）が実行中に、第２イベント（Ａ５）が開始条件を実現する。第１イベント（Ａ３）ＴＴＴは有効期限が切れ、第２イベント（Ａ５）ＴＴＴは実行を継続する。この例では、２つのイベントの（または例）共同評価ポイントはＴ５にあり、たとえば、両方のイベントの有効期限が切れた後（この成功したＣＨＯ実行例による）。Ｔ５の時点で、この例では第２イベントの有効期限が切れた時点で、Ａ３終了条件がｔｒｕｅでない場合はＣＨＯが実行される。

現在、ＲＬＦおよびＭＲＯ（モビリティ堅牢性最適化）ＫＰＩ（Ｋｅｙ Ｐｅｒｆｏｒｍａｎｃｅ Ｉｎｄｉｃａｔｏｒｓ）でのＵＥログは、マルチイベント（例：デュアルイベント）を使用してＣＨＯを実行した場合に、ネットワーク／ＭＲＯがＲＬＦの根本原因（またはその他の障害）を特定するのを支援しない。そのため、現在、ネットワークは、特にマルチイベントＣＨＯを実行した場合に、パフォーマンスを向上させるモビリティパラメータの調整について、正確または正確な決定を行うことができない。

前述のように、各イベントには、Ｏｆｆｓｅｔ、Ｈｙｓｔ（ヒステリシス値）、ＴＴＴなど、多数の設定可能な（または可変の）モビリティ関連パラメータが存在する可能性がある。測定イベントのモビリティ関連パラメータが誤って構成されている場合、ＵＥがＣＨＯを適切に実行できず、代わりにＲＬＦが発生する可能性がある。したがって、マルチイベントＣＨＯ実行のためのマルチイベントのモビリティパラメータは、適切に構成されているか、最適化されている場合でも、効率的かつ正しくＣＨＯを実行するために望ましいものだ。ネットワーク内の接続障害（無線リンク障害およびハンドオーバ障害）の数を減らすことを目的としたモビリティ堅牢性最適化（ＭＲＯ）は、情報またはレポートに基づいてモビリティパラメータを調整することで、この問題に対応できる。イベントパラメータの調整は、ＵＥがログに記録し、ＵＥがネットワーク（またはネットワークノード）に報告する可能性のある情報（例えば、マルチイベントのＣＨＯ実行に関連するログ情報）、例えば、ＲＬＦレポート、ログに記録された測定レポート、またはその他のレポートに基づいて行うことができる。ＲＬＦレポートの情報は、ＭＤＴ機能によって評価されるログに記録された測定レポートに追加することもできる。

マルチイベントＣＨＯ実行に関連する情報など、さまざまな情報がＵＥによってログに記録されることがあり、それらはＵＥによって報告され、後にネットワーク（例：送信元ネットワークノード）によって１つ以上のパラメータを調整してＣＨＯ実行のパフォーマンスや信頼性を向上させるために使用されることがある。以下は、マルチイベントＣＨＯ実行の１つ以上のイベントに対してＵＥによってログ／収集される可能性があるいくつかの情報要素（ＩＥ）の例のリストである。この情報またはＩＥは、マルチイベントに対して、ＵＥによってネットワークまたはネットワークノードに報告される可能性がある。例えば、ＲＬＦまたはＨＯの障害などの障害が発生した場合、例えば、ネットワークまたはネットワークノードが根本原因分析を実行して障害の根本原因（例：ＲＬＦやＨＯの障害）を判定するのを支援したり、将来的にＣＨＯ実行を改善するのを支援したりするために使用される。ネットワークノードなどのネットワークによって実行される根本原因分析は、ログに記録された情報／ＩＥに基づいて、例えば、マルチイベントのうち、いずれのイベントが障害の原因であるかを判定するために実行される可能性があり、ＣＨＯ実行のパフォーマンスおよび／または信頼性を向上させるために、どのような可能性のあるパラメータ調整が必要であるか、または実行される可能性があるかを特定するために実行される可能性がある。次に、ログに記録される可能性のあるいくつかのＩＥの例（例えば、ＲＬＦやＨＯの障害を減らすように設計されたパラメータ調整）と、ＣＨＯ実行のパフォーマンスおよび／または信頼性を向上させるために実行される可能性のあるいくつかの根本原因分析および可能性のあるパラメータ調整について説明する。

ＩＥ（情報要素）１：イベント１（Ａ３）およびイベント２（この例ではＡ５）の構成を識別する（発行セルは構成を長時間保持しない可能性があり、ネットワークからの信号値はＵＥ側でスケーリングされる可能性がある）。イベント構成は、例えば、イベントタイプ（例：Ａ３またはＡ５）、測定される信号パラメータ、および関連するヒステリシス、オフセット、ＴＴＴ（ＵＥ速度に基づいてＵＥによってスケーリングされる可能性がある）、またはその他のイベント関連パラメータの１つ以上を示すことができる。

ＩＥ２：ＴＴＴ期間の開始条件を実現した、つまり、ＴＴＴを開始し、（存在する場合）ＴＴＴが満了したイベントはどれか－イベント１、イベント２、両方、またはなし。両方のイベントに関する情報を提供する。ＣＨＯのデュアルイベント設定の場合。

ＩＥ３：イベントのＴＴＴが満了したときのタイムスタンプ（または時刻）、例えば図５のＴ４／Ｔ５。

ＩＥ４：第１のイベント（ＴＴＴがすでに満了している）が終了条件を満たしていないか、第２のイベントのＴＴＴが満了したときに満たしていないかの表示－Ｔ５での評価結果。

ＩＥ５：Ｅｖｅｎｔ１および／またはＥｖｅｎｔ２が開始条件を実現し、ＴＴＴが開始された。

ＩＥ６：イベントのＴＴＴが開始されたときのタイムスタンプ（または時刻）－図５のＴ２およびＴ３。

ＩＥ７：開始条件ＴＴＴを実現する第１のイベントの開始から、開始条件ＴＴＴを実現する第２のイベントの開始までの時間差－図５の（Ｔ３－Ｔ２）。

ＩＥ８：２つのイベントＴＴＴが並行して実行されていた時間－図５の（Ｔ４－Ｔ３）。

ＩＥ９：開始条件を実現し、最初にＴＴＴを開始したイベント－イベント１またはイベント２、両方同時。図５の例では、Ｔ２で第１のイベント（Ａ３）が開始条件を満たし、最初にＴＴＴを開始した。

ＩＥ１０：イベント１／イベント２ ＴＴＴを開始したが、期限切れになる前に停止した。

ＩＥ１１：失効前に停止した場合のイベント１／イベント２のＴＴＴの値。

ＩＥ１２：失効前にイベント１／イベント２のＴＴＴが開始され、停止された時間の数。

次に、この情報をモビリティ堅牢性最適化（ＭＲＯ）の目的（例えば、情報要素の組み合わせに基づくことができる）にさらに使用する方法の例をいくつか説明する。ＣＨＯ最適化とは、ＣＨＯの信頼性とパフォーマンスを向上させるなど、安定性を維持しながらＣＨＯがトリガされる回数を増やすことである。図５は、成功したＣＨＯの実行を示すタイムラインを示しており、Ｔ５でＵＥがＣＨＯの実行をトリガする（２つのイベントのＴ５での共同評価に基づく）ことに注意されたい。ただし、図５には示されていないが、問題や障害はいつでも発生する可能性がある。たとえば、ＲＬＦ ＨＯ障害のような障害は、そのタイムラインのどこでも発生する可能性がある。したがって、Ｔ５より前のどこかで障害が発生した場合、他のさまざまなイベント関連の状態（図５には示されていない）が発生し、さまざまなＩＥを使用してログに記録される可能性がある。したがって、たとえば、障害やその他の状態によってＴＴＴタイマが期限切れになる前に停止した場合、第２のイベントがトリガされないかＴＴＴタイマを開始しない場合、イベントがまったく重複しない場合など、図５に示されていないその他のさまざまなイベント関連の状態が発生したり、記録されたりする可能性がある。

ＩＥ８：Ｔ４－Ｔ３が０（２つのイベントのＴＴＴが重複していない）であり、前述のＩＥ４＝ＦＡＬＳＥの値（開始条件を満たす第１のイベントで、ＴＴＴが期限切れになったものは、第２のイベントのＴＴＴが期限切れになったときに終了条件を実現している）。したがって、２つのイベントの全体的な評価に時間がかかりすぎたため、イベント２がより早く開始条件を実現する（およびＴＴＴを開始する）ように、第２のイベントのＴＴＴまたはその開始条件を制御するオフセットを緩和できた（または緩和する必要がある）ことを意味し、第２のイベントのＴＴＴが期限切れになったときに、第１のイベントが終了条件を実現しない可能性が高くなる。

ＩＥ１０はＴｒｕｅ（ＴＴＴが期限切れになる前に停止）であり、ＩＥ１１＜＜ＴＴＴの値は、イベントの設定が控えめすぎることを意味する場合がある。
これは図５には示されていないが、発生する可能性がある。

ＩＥ２の値：別の例（図５には示されていない）では、イベント１のＴＴＴだけが期限切れになっている。これは、ＣＨＯが実行される機会がなかったことを意味する。
イベント２の設定を変更する必要がある。

ＩＥ２の値：別の例（図５には示されていない）では、いずれのイベントもＴＴＴの有効期限が切れていなかった（ＴＴＴはいずれのイベントでも有効期限が切れなかった）。これは、両方のイベント設定を変更する必要があることを示している。

ＩＥ６（ＴＴＴがイベントに対して開始されたときのタイムスタンプ）の値は、時刻Ｔ１にＣＨＯ実行がＵＥに提供されてからかなり後に発生する。これは、両方のイベントの設定を緩和できることを示す。

また、障害をカウントしたり、マルチイベントのＣＨＯ実行に関連するログ情報に格納したりすることもできる。そこで、上記の二重イベントＣＨＯ実行条件を実現していないことによる障害（遅すぎるハンドオーバ）を、デュアルイベントＣＨＯ実行用の新しいサブカウンタにカウントすることを提案する。

ここで説明する３つのケースは、デュアルイベントＣＨＯ実行の２つのイベントとして、非デュアル閾値測定イベント（例：Ａ３イベント）、デュアル閾値測定イベント（例：Ａ５イベント）、またはそれぞれの１つを使用するかどうかによって異なる。

１）次のサブカウンタは、イベント１および／またはイベント２がデュアル閾値測定イベントではない場合に使用できる。

イベント１はトリガされない（イベント１のＴＴＴは満了していない）。

ＣＨＯ．ＯｕｔＦａｉｌ．ＴｏｏＬａｔｅＥｖｅｎｔ１ＮｏｔＴｒｉｇｇｅｒｅｄ障害カウンタがインクリメントされる。

イベント２はトリガされない（イベント２のＴＴＴは満了しなかった）。

ＣＨＯ．ＯｕｔＦａｉｌ．ＴｏｏＬａｔｅＥｖｅｎｔ２ＮｏｔＴｒｉｇｇｅｒｅｄ障害カウンタがインクリメントされる。

２）イベント１および／または２がデュアル閾値測定イベント（例：Ａ５）である場合、特定のタイプの障害が発生したときにインクリメントされる次のサブカウンタを持つことができる。

イベント１はトリガされない。

Ｓｏｕｒｃｅ ｍｅａｓｕｒｅｍｅｎｔがＴｈｒｅｓｈｏｌｄ１（Ｔｈ１）を下回っていないため、イベント１はトリガされない。

ＣＨＯ．ＯｕｔＦａｉｌ．ＴｏｏＬａｔｅＥｖｅｎｔ １ ＯｗｎＮｏｔＣｒｏｓｓｅｄ障害カウンタがインクリメントされる。

Ｔａｒｇｅｔ測定が閾値２（Ｔｈ２）を超えることがないため、イベント１がトリガされることはない。

ＣＨＯ．ＯｕｔＦａｉｌ．ＴｏｏＬａｔｅＥｖｅｎｔ １ ＮｅｉｇｈｂｏｕｒＮｏｔＣｒｏｓｓｅｄ障害カウンタがインクリメントされる。

イベント２はトリガされない。

Ｓｏｕｒｃｅ測定がＴｈ１の下にないため、イベント２はトリガされない。

ＣＨＯ．ＯｕｔＦａｉｌ．ＴｏｏＬａｔｅＥｖｅｎｔ２ＯｗｎＮｏｔＣｒｏｓｓｅｄ障害カウンタがインクリメントされる。

Ｔａｒｇｅｔ測定がＴｈ２を超えていないため、イベント２がトリガされることはない。

ＣＨＯ．ＯｕｔＦａｉｌ．ＴｏｏＬａｔｅＥｖｅｎｔ２ＮｅｉｇｈｂｏｕｒＮｏｔＣｒｏｓｓｅｄ障害カウンタがインクリメントされる。

３）Ａ３イベントとＡ５イベントの両方：イベント１とイベント２がトリガされるが、最初にトリガされたイベントの終了条件は、第２のイベントのＴＴＴが期限切れになったときに実現された。ＣＨＯ．ＯｕｔＦａｉｌ．ＴｏｏＬａｔｅＥｖｅｎｔ １２ ＣｏｍｂｉｎａｔｏｎＮｏｔＴｒｉｇｇｅｒｅｄ障害カウンタがインクリメントされる。

いくつかの例について説明する。

［例１］
無線ネットワーク内のユーザデバイスによって、マルチイベント条件付きハンドオーバ実行に関連する情報をログ記録するステップであって、前記マルチイベント条件付きハンドオーバ実行は、前記ユーザデバイスによるマルチイベントの共同評価に基づいているステップと、前記ユーザデバイスによって、情報の少なくとも一部を含むレポートを送信するステップとを含む方法。

［例２］
前記マルチイベント条件付きハンドオーバ実行が、２つのイベントの共同評価に基づいているデュアルイベント条件付きハンドオーバ実行を含む、例１の方法。

［例３］
前記送信するステップは、前記ユーザデバイスでハンドオーバ障害または無線リンク障害が発生した後、ユーザデバイスはセルへの接続を再確立した後に、前記ユーザデバイスによって、前記情報の少なくとも一部を含むレポートを送信するステップを含む、例１－２のいずれかの方法。

［例４］
前記送信するステップは、無線リンク障害またはハンドオーバ障害に応答する前記ユーザデバイスによって、前記情報の少なくとも一部を含むレポートを送信するステップ、または、ネットワークノードからの要求に応答する前記ユーザデバイスによって、前記情報の少なくとも一部を含むレポートを送信するステップ
を含む、請求項３に記載の方法。

［例５］
前記マルチイベント条件付きハンドオーバ実行は複数のイベントに基づいており、前記ログ記録するステップは、複数のイベントのうちの１つ以上のイベントについて、イベント関連条件の発生、イベント関連条件の発生回数、またはイベント関連条件の発生の時間またはタイミングを少なくともログ記録するステップを含む、例１－４のいずれかの方法。

［例６］
イベント関連条件が、開始されていない、開始された、開始後に停止された、または、満了した内のいずれかのステータスを含む、イベントの時間トリガタイマのステータス、前記イベントの開始条件を実現するイベント、前記イベントの開始条件を実現するイベント、前記ユーザデバイスのハンドオーバ障害の発生、または、前記マルチイベント条件付きハンドオーバ実行についての実行条件を実現したか否か、のうちの少なくとも１つを含む、例５の方法。

［例７］
前記マルチイベント条件付きハンドオーバ実行は複数のイベントに基づいており、前記ログ記録するステップが、複数のイベントのうちの１つ以上についてイベント関連条件が発生したかどうかを示す情報をログ記録するステップ、複数のイベントのうちの１つ以上についてイベント関連条件が発生した回数を示す情報をログ記録するステップ、複数のイベントのうちの少なくとも２つのイベントのイベント関連条件の時間関係またはそれらの間の時間差をログ記録するステップと、複数のイベントのうちの１つ以上についてイベント関連条件が発生した時間を示す情報をログ記録するステップ、どのイベントについてイベント関連条件が最初に発生したかを示す情報をログ記録するステップ、または、複数のイベントがマルチイベント条件付きハンドオーバ実行の実行条件を実現しないことに起因して、ユーザデバイスに対するハンドオーバの障害の回数をログ記録するステップ、のうちの少なくとも１つを含む、例１－６のいずれかの方法。

［例８］
前記マルチイベント条件付きハンドオーバ実行は複数のイベントに基づいており、前記ログ記録するステップが、前記複数のイベントのうちの１つ以上についてイベント関連条件が発生したかどうかを示す情報をログ記録するステップを含む、上記例のうちのいずれかの方法。

［例９］
前記複数のイベントのうちの１つ以上についてイベント関連条件が発生したかどうかを示す情報をログ記録するステップが、もしあれば、いずれのイベントが前記イベントの開始条件を満たし、時間トリガタイマを開始したかを示す情報をログ記録するステップ、もしあれば、いずれのイベントが前記イベントの開始条件を満たし、時間トリガタイマを開始し、前記イベントについての時間トリガタイマが満了したかを示す情報をログ記録するステップ、前記ユーザデバイスによるマルチイベントの共同評価に基づく前記マルチイベント条件付きハンドオーバ実行の実行条件が実現しているか否かを示す情報をログ記録するステップ、既に満了した時間トリガタイマを有する第１イベントが、第２イベントの時間トリガタイマが満了したときに前記第１イベントの終了条件を満たすか否かを示す情報をログ記録するステップ、または、もしあれば、いずれのイベントが前記イベントに対する開始条件を実現し、時間トリガタイマを開始し、前記イベントに対する時間トリガタイマは、満了する前に停止されたかを示す情報をログ記録するステップのうちの少なくとも１つを含む、例８の方法。

［例１０］
前記マルチイベント条件付きハンドオーバ実行は複数のイベントに基づいており、前記ログ記録するステップは、前記複数のイベントのうちの１つ以上についてイベント関連条件が発生した回数を示すログ情報をログ記録するステップを含む、例１～９のうちのいずれかの方法。

［例１１］
前記ログ記録するステップは、各イベントが、もしあれば、前記時間トリガタイマが何回開始したか、および、前記イベントの前記時間トリガタイマが満了する前に停止したことを示す情報をログ記録するステップを少なくとも含む前記複数のイベントのうちの１つ以上についてイベント関連条件が発生した回数を示すログ情報をログ記録するステップを含む、例１０の方法。

［例１２］
前記マルチイベント条件付きハンドオーバ実行は少なくとも第１イベントおよび第２イベントを含む複数のイベントに基づいており、前記ログ記録するステップは、前記第２イベントに対する第２イベント関連条件に関する前記第１イベントに対する第１イベント関連条件の関係を示す情報をログ記録するステップを含む、例１－７のいずれかの方法。

［例１３］
関係を示す前記情報は、第１イベントの第１イベント関連条件と第２イベントの第２イベント関連条件との順序、第１イベントに対する第１イベント関連条件の発生と第２イベントの第２イベント関連条件の発生との間の時間、または、前記第１イベントについての第１イベント関連条件の発生の時間および第２イベントについての第２イベント関連条件の発生の時間、のうちの少なくとも１つを含む、例１２の方法。

［例１４］
関係を示す情報を前記ログ記録するステップは、第１イベントまたは第２イベントが最初に開始条件を実現したかどうかをログ記録するステップ、時間トリガタイマのうちの１つが停止または満了したときの前記第１イベントおよび前記第２イベントの時間トリガタイマの値をログ記録するステップ、または、前記第１イベントおよび前記第２イベントの時間トリガタイマが並行して動作していた時間または期間をログ記録するステップ、の内の少なくとも１つを含む、例１２－１３のいずれかの方法。

［例１５］
前記マルチイベント条件付きハンドオーバ実行は複数のイベントに基づき、前記ログ記録するステップは、前記複数のイベントのうちの１つまたは複数についてイベント関連条件が発生した時間を示す情報をログ記録するステップを含む、例１－７のいずれかの方法。

［例１６］
前記ログ記録するステップは、イベントの時間トリガタイマが開始した時刻を示す情報をログ記録するステップ、イベントの時間トリガタイマが満了した時刻を示す情報をログ記録するステップ、イベントの時間トリガタイマが停止した時刻を示す情報をログ記録するステップ、または、第１イベントの時間トリガタイマと第２イベントの時間トリガタイマが並行して動作していた時刻を示す情報をログ記録するステップのうちの少なくとも１つを含む前記複数のイベントのうちの１つまたは複数についてイベント関連条件が発生した時間を示す情報をログ記録するステップを含む、例１５の方法。

［例１７］
前記マルチイベント条件付きハンドオーバ実行は複数のイベントに基づき、前記ログ記録するステップは、どのイベントに関連する条件が最初に発生したかを示す情報をログ記録するステップを含む、例１－７のいずれかの方法。

［例１８］
いずれのイベントに関連する条件が最初に発生したかを示す情報を前記ログ記録するステップは、もしあれば、いずれのイベントが前記イベントの開始条件を実現し、最初に時間トリガタイマを開始したかを示す情報をログ記録するステップ、もしあれば、いずれのイベントが最初に時間トリガタイマを満了したかを示す情報をログ記録するステップ、または、どのイベントがイベントの開始条件を満たし、時間トリガタイマを開始し、次いで時間トリガタイマを最初に停止したかを示す情報をログ記録するステップ、のうちの少なくとも１つを含む、例１７の方法。

［例１９］
前記マルチイベント条件付きハンドオーバ実行は少なくとも第１イベントおよび第２イベントを含む複数のイベントに基づいており、前記ログ記録するステップは、前記マルチイベント条件付きハンドオーバ実行の実行条件を実現していない前記複数のイベントによる前記ユーザデバイスの条件付きハンドオーバの障害数をカウントする障害カウンタをログ記録するステップを含む、例１－１８のいずれかの方法。

［例２０］
前記第１イベントおよび前記第２イベントの両方が非デュアル閾値測定イベントである場合に、障害カウンタを前記ログ記録するステップが、前記第１イベントに対する時間トリガタイマが満了しなかった場合の条件付きハンドオーバ障害の数、または、前記第２イベントに対する時間トリガタイマが満了しなかった場合の条件付きハンドオーバ障害の数、の情報のうちの１つ以上をログ記録するステップを含む、例１９の方法。

［例２１］
前記第１イベントおよび前記第２イベントの両方がデュアル閾値測定イベントである場合に、障害カウンタを前記ログ記録するステップが、ソースセル測定値が第１の閾値以下ではないため、前記第１イベントに対する時間トリガタイマが満了しないときの条件付きハンドオーバ障害の数、ターゲットセル測定値が第２の閾値よりも大きくないため、前記第２イベントに対する時間トリガタイマが満了しないときの条件付きハンドオーバ障害の数、ソースセル測定値が第１の閾値以下ではないため、前記第２イベントに対する時間トリガタイマが満了しないときの条件付きハンドオーバ障害の数、または、ターゲットセル測定値が第２の閾値よりも大きくないため、前記第１イベントに対する時間トリガタイマが満了しないときの条件付きハンドオーバ障害の数、の情報のうちの１つ以上をログ記録するステップを含む、例１９の方法。

［例２２］
前記障害カウンタをログ記録するステップは、
前記第１イベントの時間トリガタイマが満了し前記第２イベントの時間トリガタイマが満了したが、第２イベントの時間トリガタイマが満了したときに第１イベントの終了条件が実現されたことに基づく条件付きハンドオーバの障害の数をログ記録するステップを含む、例１９の方法。

［例２３］
前記マルチイベント条件付きハンドオーバ実行は少なくとも第１イベントおよび第２イベントを含む複数のイベントに基づいており、前記ログ記録するステップは、第１イベントの構成および／または第２イベントの構成をログ記録するステップ、もしあれば、いずれのイベントがイベントの開始条件を実現し、時間トリガタイマを開始したかを示す情報をログ記録するステップ、もしあれば、いずれのイベントがイベントの開始条件を実現し、時間トリガタイマを開始し、イベントの時間トリガタイマが満了したかを示す情報をログ記録するステップ、前記マルチイベント条件付きハンドオーバ実行の実行条件が実現したか否かを示す情報をログ記録するステップ、既に満了した時間トリガタイマを有する第１のイベントが、前記第２のイベントの時間トリガタイマが満了したときに前記第１のイベントの終了条件を実現するか否かを示す情報をログ記録するステップ、もしあれば、いずれのイベントが自身の時間トリガタイマを開始し、前記イベントについての前記時間トリガタイマが満了する前に停止されたかを示す情報をログ記録するステップ、もしあれば、各イベントが自身の時間トリガタイマを開始し、前記イベントについての時間トリガタイマが満了する前に停止された回数を示す情報をログ記録するステップ、第１イベントまたは第２イベントが最初に開始条件を実現するかどうかの情報をログ記録するステップ、時間トリガタイマのうちの１つが停止または満了したときに、前記第１イベントおよび前記第２イベントの時間トリガタイマの値をログ記録するステップ、前記第１イベントおよび前記第２イベントの時間トリガタイマが並行して動作していた時間または期間をログ記録するステップ、イベントの時間トリガタイマが起動された時刻を示す情報をログ記録するステップ、イベントに対する時間トリガタイマが満了した時間を示す情報をログ記録するステップ、イベントの時間トリガタイマが停止した時刻を示す情報をログ記録するステップ、第１イベントに対する時間トリガタイマが、第２イベントに対する時間トリガタイマと並行して動作していた時間を示す情報をログ記録するステップ、もしあれば、いずれのイベントがイベントの開始条件を実現し、最初に時間トリガタイマを開始したかを示す情報をログ記録するステップ、もしあれば、いずれのイベントが時間トリガタイマを最初に満了したかを示す情報をログ記録するステップ、もしあれば、どのイベントが前記イベントの開始条件を実現し、時間トリガタイマを開始し、次いで時間トリガタイマを最初に停止したかを示す情報をログ記録するステップ、または、複数イベントが前記マルチイベント条件付きハンドオーバ実行の実行条件を実現しないことによる前記ユーザデバイスの条件付きハンドオーバの障害の回数をカウントする障害カウンタをログ記録するステップ、のうちの少なくとも１つを含む、例１－２２のいずれかの方法。

［例２４］
少なくとも第１のイベントの構成および第２イベントの構成を含むマルチイベントのそれぞれの構成と、条件付きハンドオーバ実行を行うかどうかを判定するために前記ユーザデバイスによるマルチイベントの共同評価を構成する共同評価構成を含む、条件付きハンドオーバの一部として、前記ユーザデバイスによってネットワークノードから、ハンドオーバコマンドを受信することをさらに含む、例１から例２３のいずれかの方法。

［例２５］
ソースネットワークノードからターゲットネットワークノードへの前記ユーザデバイスの条件付きハンドオーバ実行を行うかどうかを判定するために、ユーザデバイスによって複数のイベントを共同で評価するステップをさらに含む、例１－２４のいずれかの方法。

［例２６］
例１から例２５のいずれかの方法を実行する手段を含む装置。

［例２７］
少なくとも１つのプロセッサによって実行されたときに、コンピューティングシステムに例１から２５のいずれか１項に記載の方法を実行させるように構成された命令が格納された非一時的なコンピュータ可読記憶媒体。

［例２８］
少なくとも１つのプロセッサと、コンピュータプログラムコードを含む少なくとも１つのメモリとを含む装置であって、前記少なくとも１つのメモリおよび前記コンピュータプログラムコードは、前記少なくとも１つのプロセッサとともに、前記装置に、例１－２５の方法を少なくとも行わせるように構成された装置。

［例２９］
少なくとも１つのプロセッサと、コンピュータプログラムコードを含む少なくとも１つのメモリとを含む装置であって、前記少なくとも１つのメモリおよび前記コンピュータプログラムコードは、前記少なくとも１つのプロセッサとともに、無線ネットワーク内のユーザデバイスが、マルチイベント条件付きハンドオーバ実行に関連する情報をログ記録するステップであって、前記マルチイベント条件付きハンドオーバ実行は、前記ユーザデバイスによるマルチイベントの共同評価に基づいているログ記録するステップと、前記ユーザデバイスが、情報の少なくとも一部を含むレポートを送信するステップとを、前記装置に実行させる、装置。

［例３０］
ユーザデバイスによる条件付きハンドオーバ実行のために共同で評価されるマルチイベントの構成を含む共同イベント構成情報を持つハンドオーバコマンドを、ネットワークノードによって前記ユーザデバイスに送信するステップと、前記ユーザデバイスによるマルチイベント条件付きハンドオーバ実行の障害に関する前記ユーザデバイスによって記録された情報を含むレポートを前記ネットワークノードによって受信するステップであって、前記マルチイベント条件付きハンドオーバ実行が複数のイベントに基づいているステップと、前記レポートに基づいて前記ネットワークノードによって、マルチイベント条件付きハンドオーバ実行のための一つ以上のイベントの構成に関連付けられた一つ以上のパラメータを変更するステップとを含む、方法。

［例３１］
前記共同イベント構成情報は、条件付きハンドオーバ実行を行うかどうかを判定するために、前記ユーザデバイスによるマルチイベントの共同評価を構成する共同評価構成を含む、例３０の方法。

［例３２］
前記マルチイベント条件付きハンドオーバ実行が、２つのイベントに基づくデュアルイベント条件付きハンドオーバ実行を含む、例３０または３１の方法。

［例３３］
前記マルチイベント条件付きハンドオーバ実行は複数のイベントに基づいており、前記ユーザデバイスによってログ記録される情報には、前記複数のイベントのうち１つ以上のイベント関連条件の発生、イベント関連条件の発生回数、イベント関連条件の発生時刻や発生タイミングの内の少なくとも１つを含む、例３０－３２のいずれかの方法。

［例３４］
イベント関連条件は、開始されていない、開始された、開始後に停止された、または、満了したいずれかのステータスを含むイベントの時間トリガタイマのステータス、前記イベントの開始条件を実現するイベント、前記イベントの終了条件を実現するイベント、前記ユーザデバイスのハンドオーバ障害の発生、または前記マルチイベント条件付きハンドオーバ実行の実行条件が実現されているか否か、のうちの少なくとも１つを含む、例３３の方法。

［例３５］
前記マルチイベント条件付きハンドオーバ実行は複数のイベントに基づいており、前記ユーザデバイスによってログ記録される前記情報は、前記複数のイベントのうちの１つ以上についてイベント関連条件が発生したかどうかを示す情報、複数のイベントのうちの１つ以上についてイベント関連条件が発生した回数を示す情報、複数のイベントのうちの少なくとも２つのイベントのイベント関連条件の時間関係またはそれらの間の時間差、複数のイベントのうちの１つ以上についてイベント関連条件が発生した時間を示す情報、どのイベントについてイベント関連条件が最初に発生したかを示す情報、または、前記複数のイベントが前記マルチイベント条件付きハンドオーバ実行の実行条件を実現しないことにより、前記ユーザデバイスに対するハンドオーバの障害の回数、のうちの少なくとも１つを含む、例３０－３４のいずれかの方法。

［例３６］
前記マルチイベント条件付きハンドオーバ実行は少なくとも第１イベントおよび第２イベントを含む複数のイベントに基づいており、前記ユーザデバイスによってログ記録される前記情報は、第１イベントの構成および／または第２イベントの構成、もしあれば、いずれのイベントがイベントの開始条件を実現し、時間トリガタイマを開始したかを示す情報、もしあれば、いずれのイベントがイベントの開始条件を実現し、時間トリガタイマを開始し、イベントの時間トリガタイマが満了したかを示す情報、前記マルチイベント条件付きハンドオーバ実行の実行条件が実現したか否かを示す情報、既に満了した時間トリガタイマを有する第１のイベントが、前記第２のイベントの時間トリガタイマが満了したときに前記第１のイベントの終了条件を実現するか否かを示す情報、もしあれば、いずれのイベントが自身の時間トリガタイマを開始し、前記イベントについての前記時間トリガタイマが満了する前に停止されたかを示す情報、もしあれば、各イベントが自身の時間トリガタイマを開始し、前記イベントについての時間トリガタイマが満了する前に停止された回数を示す情報、第１イベントまたは第２イベントが最初に開始条件を実現するかどうかの情報、時間トリガタイマのうちの１つが停止または満了したときの、前記第１イベントおよび前記第２イベントの時間トリガタイマの値、前記第１イベントおよび前記第２イベントの時間トリガタイマが並行して動作していた時間または期間、イベントの時間トリガタイマが開始された時刻を示す情報、イベントに対する時間トリガタイマが満了した時間を示す情報、イベントの時間トリガタイマが停止した時刻を示す情報、第１イベントに対する時間トリガタイマが、第２イベントに対する時間トリガタイマと並行して動作していた時間を示す情報、もしあれば、いずれのイベントがイベントの開始条件を実現し、最初に時間トリガタイマを開始したかを示す情報、もしあれば、いずれのイベントが時間トリガタイマを最初に満了したかを示す情報、もしあれば、いずれのイベントが前記イベントの開始条件を実現し、時間トリガタイマを開始し、次いで時間トリガタイマを最初に停止したかを示す情報、または、複数イベントが前記マルチイベント条件付きハンドオーバ実行の実行条件を実現しないことによる前記ユーザデバイスの条件付きハンドオーバの障害の回数をカウントする障害カウンタ、のうちの少なくとも１つを含む、例３０－３５のいずれかの方法。

［例３７］
例３０－３６のいずれかの方法を実行する手段を含む装置。

［例３８］
少なくとも１つのプロセッサによって実行されたときに、コンピューティングシステムに例３０－３６のいずれかの方法を実行させるように構成された命令が格納された非一時的なコンピュータ可読記憶媒体。

［例３９］
少なくとも１つのプロセッサと、コンピュータプログラムコードを含む少なくとも１つのメモリとを含む装置であって、前記少なくとも１つのメモリおよび前記コンピュータプログラムコードは、前記少なくとも１つのプロセッサとともに、前記装置に、少なくとも例３０－３６のいずれかの方法を装置に実行させるように構成された装置。

図６は、一実施例による無線ステーションまたはノード（例：ＡＰ、ＢＳ、ｇＮＢ、ｅＮＢ、中継ノードまたはその他のネットワークノード、ユーザデバイス／ＵＥ、またはその他のノード）１１００のブロック図である。無線ステーション１１００は、例えば、一つ以上の（例えば、図６に示すように２つの）ＲＦ（無線周波数）または無線トランシーバ１１０２Ａ、１１０２Ｂを含み、各無線トランシーバは、信号を送信するための送信機と信号を受信するための受信機を含む。無線ステーションはまた、命令またはソフトウェアを実行し、信号の送受信を制御するプロセッサまたは制御ユニット／エンティティ（コントローラ）１１０４と、データおよび／または命令を格納するメモリ１１０６を含む。

プロセッサ１１０４は、決定または判定を行い、送信のためのフレーム、パケットまたはメッセージを生成し、受信したフレームまたはメッセージをさらに処理するためにデコードし、およびここに記載されているその他のタスクまたは機能を実行することもできる。たとえば、ベースバンドプロセッサであるプロセッサ１１０４は、無線トランシーバ１１０２（１１０２Ａまたは１１０２Ｂ）を介して送信するためのメッセージ、パケット、フレームまたはその他の信号を生成することができる。プロセッサ１１０４は、無線ネットワークを介した信号またはメッセージの送信を制御することができ、無線ネットワークを介した信号またはメッセージの受信などを制御することができる（たとえば、無線トランシーバ１１０２によってダウンコンバートされた後など）。プロセッサ１１０４は、プログラム可能であり、メモリまたは他のコンピュータメディアに保存されているソフトウェアまたは他の命令を実行して、上記のさまざまなタスクや機能を実行することができる場合がある。プロセッサ１１０４は、たとえば、ハードウェア、プログラム可能なロジック、ソフトウェアまたはファームウェアを実行するプログラム可能なプロセッサ、および／またはこれらの任意の組み合わせである場合がある（または含む場合がある）。
他の用語を使用すると、プロセッサ１１０４とトランシーバ１１０２を一緒にして、たとえば無線送受信システムと見なすことができる。

さらに、図６を参照すると、コントローラ（またはプロセッサ）１１０８は、ソフトウェアと命令を実行し、ステーション１１００の全体的な制御を提供することができ、入力／出力デバイス（例：ディスプレイ、キーパッド）の制御など、図６に示されていない他のシステムの制御を提供することができ、および／または、たとえば、電子メールプログラム、オーディオ／ビデオアプリケーション、ワードプロセッサ、Ｖｏｉｃｅ ｏｖｅｒ ＩＰアプリケーション、またはその他のアプリケーションやソフトウェアなど、無線ステーション１１００で提供される可能性のある１つ以上のアプリケーションのソフトウェアを実行することができる。

さらに、記憶された命令を含む記憶媒体が提供されることがあり、コントローラまたはプロセッサによって実行されると、プロセッサ１１０４、またはその他のコントローラまたはプロセッサが、上記の機能またはタスクの１つ以上を実行することになる場合がある。

別の例の実施形態によると、ＲＦまたは無線トランシーバ１１０２Ａ／１１０２Ｂは、信号またはデータを受信したり、信号またはデータを送信または送信したりすることができる。プロセッサ１１０４（およびトランシーバ１１０２Ａ／１１０２Ｂ）は、ＲＦまたは無線トランシーバ１１０２Ａまたは１１０２Ｂを制御して、信号またはデータを受信、送信、ブロードキャスト、または送信することができる。

ただし、例示の実施形態は、例として示されているシステムに限定されるものではなく、当業者はこのソリューションを他の通信システムに適用することができる。適切な通信システムの別の例は、５Ｇシステムである。５Ｇのネットワークアーキテクチャは、ＬＴＥ－Ａｄｖａｎｃｅｄのものとかなり似ていると想定されている。５Ｇは、マルチインプット－マルチアウトプット（ＭＩＭＯ）アンテナを使用する可能性が高く、ＬＴＥよりもはるかに多くの基地局またはノード（いわゆるスモールセルの概念）を使用する。これには、小規模な局と協力して動作するマクロサイトや、おそらくカバレッジと拡張型データレートのためにさまざまな無線技術を採用することも含まれる。

将来のネットワークでは、ネットワークノード機能を「ビルディングブロック」またはサービスを提供するために運用上接続またはリンクされる可能性のあるエンティティに仮想化することを提案するネットワークアーキテクチャの概念であるネットワーク機能仮想化（ＮＦＶ）がおそらく利用されることを認識する必要がある。仮想化ネットワーク機能（ＶＮＦ）は、カスタマイズされたハードウェアの代わりに、標準または一般的なタイプのサーバを使用してコンピュータプログラムコードを実行する１つ以上の仮想マシンで構成される場合がある。クラウドコンピューティングやデータストレージを利用することもできる。無線通信では、これはノード操作が、少なくとも部分的に、リモートの無線ヘッドに操作的に結合されたサーバ、ホスト、またはノードで実行されることを意味する場合がある。また、ノード操作が複数のサーバ、ノード、またはホストに分散される可能性もある。また、コアネットワーク運用と基地局運用との間の労働力の配分がＬＴＥと異なる場合や、存在しない場合があることも理解しておく必要がある。

ここに記載されている様々な技術の実施例は、デジタル電子回路、またはコンピュータハードウェア、ファームウェア、ソフトウェア、またはそれらの組み合わせで実装することができる。実施例は、コンピュータプログラム製品として、すなわち、データ処理装置、例えばプログラマブルプロセッサ、コンピュータ、または複数のコンピュータによって実行またはその動作を制御するために、情報キャリア、例えば機械可読記憶装置または伝播された信号に有形的に具現化されたコンピュータプログラムとして実装することができる。また、実施例は、コンピュータ可読媒体またはコンピュータ可読記憶媒体で提供されることもあり、これは非遷移媒体であってもよい。様々な技術の実施例は、遷移信号または媒体を介して提供される実施例、および／またはインターネットまたは他のネットワーク（有線ネットワークおよび／または無線ネットワーク）を介してダウンロード可能なプログラムおよび／またはソフトウェアの実施例を含むこともできる。さらに、実施例は、マシンタイプ通信（ＭＴＣ）を介して提供される場合もあれば、モノのインターネット（ＩＯＴ）を介して提供される場合もある。

コンピュータプログラムは、ソースコード形式、オブジェクトコード形式、または何らかの中間形式であってもよく、プログラムを運ぶことができる任意の実体または装置である、何らかのキャリア、配布媒体、またはコンピュータ可読媒体に格納される場合もある。このようなキャリアには、例えば、記録媒体、コンピュータメモリ、読み取り専用メモリ、光電気および／または電気キャリア信号、電気通信信号、およびソフトウェア配布パッケージが含まれる。必要な処理能力に応じて、コンピュータプログラムは単一の電子デジタルコンピュータで実行される場合もあれば、複数のコンピュータに分散される場合もある。

さらに、ここに記載されている様々な技術の例示的な実施形態は、サイバーフィジカルシステム（ＣＰＳ）（物理的実体を制御する共同計算要素のシステム）を使用することができる。ＣＰＳは、異なる場所にある物理的オブジェクトに埋め込まれた大量の相互接続されたＩＣＴデバイス（センサ、アクチュエータ、プロセッサマイクロコントローラ、．．．）の具体化と活用を可能にするかもしれない。問題の物理システムが固有の移動性を持つモバイルサイバーフィジカルシステムは、サイバーフィジカルシステムのサブカテゴリである。モバイル物理システムの例としては、人間や動物によって輸送されるモバイルロボティクスや電子機器などがある。スマートフォンの人気の高まりにより、モバイルのサイバーフィジカルシステムの分野への関心が高まっている。したがって、ここで説明する技術のさまざまな実施形態は、これらの技術の１つ以上を介して提供される可能性がある。

上記のコンピュータプログラムのようなコンピュータプログラムは、コンパイル言語またはインタプリタ言語を含む任意の形式のプログラミング言語で記述することができ、スタンドアロンプログラムとして、またはコンピューティング環境での使用に適したモジュール、コンポーネント、サブルーチン、またはその他のユニットまたはその一部としてなど、任意の形式で展開することができる。コンピュータプログラムは、１つのコンピュータまたは１つのサイトの複数のコンピュータで実行されるように展開することも、複数のサイトに分散して通信ネットワークで相互接続されるように展開することもできる。

方法ステップは、入力データを操作して出力を生成することによって機能を実行するために、コンピュータプログラムまたはコンピュータプログラムの部分を実行する１つ以上のプログラム可能なプロセッサによって実行される場合がある。方法ステップは、ＦＰＧＡ（フィールドプログラマブルゲートアレイ）またはＡＳＩＣ（特定用途向け集積回路）などの特殊な目的の論理回路によって実行される場合もあり、装置はとして実装される場合もある。

コンピュータプログラムの実行に適したプロセッサには、例として、汎用と特殊目的の両方のマイクロプロセッサ、および任意の種類のデジタルコンピュータ、チップまたはチップセットの任意の１つ以上のプロセッサが含まれる。一般に、プロセッサは、読み取り専用メモリまたはランダムアクセスメモリ、またはその両方から命令とデータを受け取る。コンピュータの要素には、命令を実行するための少なくとも１つのプロセッサと、命令とデータを格納するための１つ以上のメモリデバイスを含めることができる。一般的に、コンピュータは、データを格納するための１つ以上の大容量記憶装置（例えば、磁気ディスク、光磁気ディスク、光ディスク）を含むか、またはそれらの両方からデータを受信したりデータを転送したりするために動作的に結合されることもある。コンピュータプログラム命令およびデータを具現化するのに適した情報キャリアは、例として、例えば、ＥＰＲＯＭ、ＥＥＰＲＯＭ、およびフラッシュメモリデバイスを含む、すべての形態の不揮発性メモリを含む半導体メモリデバイス、内蔵ハードディスクまたはリムーバブルディスクなどの磁気ディスク、光磁気ディスク、およびＣＤ－ＲＯＭおよびＤＶＤ－ＲＯＭディスクを含む。プロセッサとメモリは、特殊な目的の論理回路によって補完されたり、組み込まれたりすることがある。

ユーザとの対話を提供するために、ユーザに情報を表示するための、例えばブラウン管（ＣＲＴ）や液晶ディスプレイ（ＬＣＤ）モニターなどの表示装置と、ユーザがコンピュータに入力を提供できるキーボードやポインティングデバイス（例えばマウスやトラックボール）などのユーザーインターフェイスを備えたコンピュータ上に実施することができる。他の種類のデバイスを使用して、同様にユーザとの対話を提供することができる。たとえば、ユーザに提供されるフィードバックは、視覚フィードバック、聴覚フィードバック、触覚フィードバックなど、任意の形式の感覚フィードバックである可能性がある。また、ユーザからの入力は、音響、音声、触覚入力など、任意の形式で受け取ることができる。

例の実施形態は、例えばデータサーバとしてのバックエンドコンポーネントを含む、またはアプリケーションサーバのようなミドルウェアコンポーネントを含む、またはフロントエンドコンポーネントを含む、例えば、グラフィカルユーザーインターフェイスまたはユーザが実施形態と対話できるＷｅｂブラウザを持つクライアントコンピュータ、またはそのようなバックエンド、ミドルウェア、またはフロントエンドコンポーネントの任意の組み合わせで実装することができる。コンポーネントは、例えば通信ネットワークのような任意の形式またはデジタルデータ通信の媒体によって相互接続することができる。
通信ネットワークの例としては、ローカルエリアネットワーク（ＬＡＮ）やワイドエリアネットワーク（ＷＡＮ）、例えばインターネットなどがある。

ここに記載されているように、記載されている実施形態の特定の特徴が説明されているが、多くの変更、置換、変更および同等のものが当業者に生じることになるため、添付のクレームは、様々な実施形態の真の精神の範囲内にあるようなすべての変更および変更をカバーすることを意図していると理解される。

Claims (37)

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. 請求項２９～３４のいずれか１項に記載の方法を実行する手段を含む装置。
36. 少なくとも１つのプロセッサによって実行されたときに、コンピューティングシステムに請求項２９～３４のいずれか１項に記載の方法を実行させるように構成された命令が格納された非一時的なコンピュータ可読記憶媒体。
37. 少なくとも１つのプロセッサと、
    コンピュータプログラムコードを含む少なくとも１つのメモリとを含む装置であって、
    前記少なくとも１つのメモリおよび前記コンピュータプログラムコードは、前記少なくとも１つのプロセッサとともに、前記装置に、請求項２９～３４のいずれか１項に記載の方法を少なくとも実行させるように構成された装置。