JP5687351B2 - Ｍｄｔ情報ロギング及び報告方法 - Google Patents

Description

この出願は、２０１０年の１１月３日に出願された「Method of MDT Information Logging and Reporting」と題された米国特許仮特許出願番号第６１／４０９７３７号から、合衆国法典第３５編第１１９条の下、優先権を主張するものであり、その内容は引用によって本願に援用される。

本発明は、問題イベント報告およびドライブ試験の省力化（Minimization of Drive Test、ＭＤＴ）に関するものであって、特に、問題イベント報告とドライブ試験の省力化（ＭＤＴ）の情報ロギングと報告に関するものである。

３ＧＰＰリリース８として導入される第三世代パートナーシッププロジェクト（３ＧＰＰ）ロングタームエボリューション（ＬＴＥ）システムは、改善されたユニバーサルモバイルテレコミュニケーションシステム（ＵＭＴＳ）である。ＬＴＥシステムは、簡潔なネットワークアーキテクチャからもたらされる高ピークデータ速度（peak data rate）、低レイテンシー（latency）、改善されたシステムキャパシティ、および、低操作コスト（operating cost）を提供する。ＬＴＥシステムにおいて、進化型ユニバーサル地上無線通信アクセスネットワーク（Ｅ-ＵＴＲＡＮ）は、ユーザー装置（ＵＥ）と称される複数の移動局と通信する複数の進化型Node-Bs（ｅＮＢ）を含む。３ＧＰＰは新しい特徴を取り入れ、ＬＴＥシステムオペレーターが、さらに、コスト効率がよい方法で、ネットワーク計画を最適化するのを助ける。問題イベント報告およびＭＤＴは、ＵＥが、問題イベント、ログ測定を検出し、このような情報をそれらのサービングｅＮＢに伝送する二つの特徴である。同時に、ＭＤＴは、既に、過去のＵＭＴＳシステムに導入されており、将来、問題イベント報告が取り入れられることが期待される。

現在の３ＧＰＰ規格は、ある問題イベント、たとえば、無線リンク障害（Radio Link Failure、ＲＬＦ）報告等の報告をサポートし、モビリティーロバスト性最適化を支援し、ランダムアクセスチャネル（Random Access Channel、ＲＡＣＨ）は、失敗報告を試み、ＲＡＣＨ最適化を支援する。ネットワーク最適化に関する一般的な問題イベントは、ＲＬＦ、ＲＡＣＨ失敗、ハンドオーバ失敗、呼設定失敗（call setup failure）およびネットワーク計画問題に起因する別の失敗を含む。さらに、ＵＥアイドルモードで生じる問題イベント、たとえば、ＵＥがサービス停止状態（out-of-service state）に進入する、または、ＵＥがセル再選択失敗等を有する等は、オペレータが、可能なネットワーク計画問題を理解するのを助ける重要な情報である。

最適化目的のため、ネットワーク被覆問題または無線リソース管理（Radio Resource Management、ＲＲＭ）設定問題のために生じる問題を把握することが重要である。よって、ログされた問題イベント報告は、並行システム状態（concurrent system state）とネットワーク設定（network configuration）と関連付けられる必要がある。自動最適化（automatic optimization）が用いられる時、問題イベント報告と並行システムとネットワーク状態間の相互関係は、なおさら重要になり、問題を観察し、矯正設定（correctional configuratio）を変化させる間の時間が短縮される。重要性が高いある問題イベント、たとえば、ＲＬＦ、ハンドオーバ失敗および初期アクセス失敗は、作動中のネットワークではまれである。ＵＥは、それらの発生後すぐに、これらのイベントをログし、ログされた情報をネットワークに伝送することが望まれる。たとえば、３ＧＰＰリリース９において、ＵＥは、無線リソース制御（ＲＲＣ）再構築工程（re-establishment procedure）中、ＲＬＦ失敗とＲＡＣＨ報告についての情報を含むかどうか示す。ＵＥが別の接続を構築する前に、ネットワークは、ログされた情報をフェッチ（fetch）しなければならない。一般に、システムは、タイムスタンピングを手段として使用して、観察される問題、たとえば、異なるネットワークノード、たとえば、ｅＮＢとモビリティー管理エンティティ（Mobility Management Entity、ＭＭＥ）で観察される問題を関連付ける。今のところ、後処理（post-processing）失敗イベントの詳細は、まだ標準化されていないＵＥから報告する。現在の原理から、いずれにせよ、ネットワークは、タイムスタンプを用いて、問題イベント報告とネットワーク状態を関連付けると仮定される。タイムスタンピングは、問題イベント報告と並列ネットワーク状態を関連付ける重要な方法である。

現在のシステムにおいて、モバイル機器により行われるタイムスタンプ観察と測定は、主に二つの方法がある。第一の方法は、ネットワークにより、タイムスタンプを、報告される観察に追加するものである。問題イベント、たとえば、３ＧＰＰリリース８と９システムのＲＬＦ報告とＲＡＣＨ報告が発生後、すぐに、問題イベント報告が伝送される時、このような方法が問題イベントに用いられる。これらの場合、ＵＥの報告は、タイムスタンプをその問題イベント報告に追加しない。代わりに、これらの報告の受信時、ネットワークはタイムスタンプを追加する。この方法は、３ＧＰＰ規格で定義される即時ＭＤＴに類似する。第二の方法は、ログされたＭＤＴと同様、ＵＥにより、タイムスタンプを問題イベント報告に追加するものである。さらに、ログされたＭＤＴと同様に、ＵＥの無線接続層（radio connection layer）は、正確な絶対時間にアクセスしないと仮定される。ログされたＭＤＴのタイムスタンプを追加することができるようにするため、ＵＥは、ロギングのために設定される時、ネットワークから参照時間を受信する。その後、ＵＥは、自動的に、参照時間値を増加させ、問題イベント検出時、生じたタイムスタンプを問題イベント報告に追加する。この方法は、３ＧＰＰ規格中、ログされたＭＤＴに用いられる。問題イベント報告の前の設定がないので、問題イベント報告に用いられない。また、一般操作の問題イベントの低効率の問題、たとえば、すべて、または、ほぼ全てのＵＥは、その間ずっと、問題イベント情報を記録する準備をし、および、設定されるＵＥを維持しなければならず、ＵＥ時間更新の維持は、大量のシグナリングオーバーヘッド（signaling overhead）を生じるので、この方法は、このような配置の採用は適切ではない。両方のタイムスタンピング方法はそれらの制限を有し、進化中のＬＴＥシステムの要求に符合することができない。

３ＧＰＰリリース１０規格の発展に伴い、上述の従来のタイムスタンピング方法は、発展中のＬＴＥシステムで、効果的に作用しない。ある状況において、これらの方法は少しも機能しない。たとえば、上述の方法は、インターテクノロジーモビリティー（inter-technology mobility）を有する環境中の作用に問題がある。３ＧＰＰは、インターラット（ｉｎｔｅｒ-ＲＡＴ）（無線アクセス技術）モビリティーおよびインターテクノロジーモビリティーを定義する。前者はＬＴＥと早期の３ＧＰＰ技術間のモビリティーを参照する。後者は３ＧＰＰ技術と非３ＧＰＰ技術間のモビリティーを参照する。ＬＴＥ規格の下、ＵＥは異なるＲＡＴ間で移動することができる。第一ＲＡＴが不十分なサービスエリアを提供し、第二ＲＡＴがサービスエリア全体を提供するネットワーク展開において、第一から第二ＲＡＴのインターラットモビリティーの失敗イベントは普通である。通常、異なるＲＡＴは、異なる操作、管理、メンテナンス（Operations Administration and Maintenance、ＯＡＭ）システムを有する。これにより、ＵＥは、問題が発生するものと異なるＲＡＴで、問題イベント情報を報告しない。このような状況で、ＵＥは、別のＲＡＴに接続される時に、問題イベント情報を保存しなければならないので、問題イベント情報は、問題が発生した元のＲＡＴ中のシステムにより回収される。しかし、このような特徴は、遅延した問題イベント報告とその並列ネットワーク状態を関連付ける改善された時間情報を必要とする。

問題イベント報告に加え、３ＧＰＰは、ＭＤＴも導入して、ネットワーク最適化を支援する。ＭＤＴ特徴は、ＵＥが、ＯＡＭアクティビティ、たとえば、近傍検出（neighborhood detection）、測定、ＲＲＭおよび最適化目的を含むＯＡＭ目的のロギングと記録を実行することができるようにする。ＭＤＴは、従来のコストが高いドライブテスト（drive testing）により実行されるネットワーク最適化を支援する。現在のシステムにおいて、ＭＤＴは、問題イベント報告のように、同じタイムスタンピング問題を有する。さらに、ＭＤＴロギングのバッテリー消耗が高いので、バッテリー状態ハンドリング中の問題をもたらす。

制限された電源、たとえば、バッテリーで動くＵＥは、ＭＤＴロギングが有効時、バッテリー状態ハンドリングを気にかける必要がある。ＭＤＴロギングは、高いバッテリー消耗である。ＭＤＴ特徴は、ＵＥが、ＭＤＴをサポートするネットワークのある部分で、ＭＤＴを実行すると仮定し、および、ネットワークの一部が、ＭＤＴをサポートしない時、ＭＤＴ測定を実行する。ＭＤＴは、ＭＤＴをサポートしないネットワークの一部で再設定できないので、ＭＤＴロギング設置中のロギング期間は長く設定され、よって、ＭＤＴ-サポート領域外であっても、ＵＥは、ＭＤＴ測定およびＭＤＴロギングを実行することができる。さらに、ＭＤＴ測定とＵＥ位置をうまく関連付けるため、ネットワークは、相当量の電力を消耗する全地球的航法衛星システム（ＧＮＳＳ）により、ＵＥ位置決定を初期化する。

バッテリー状態は利用者の知覚に強い影響がある。アクティブモード下の電力消耗は、常に、アイドルモードよりも高い。一般に理解できることは、彼らがバッテリーを節約したい場合、ユーザーは、バッテリー使用のコントロールを有し、アクティブセッションを短く維持し、アクティブアプリケーションを休止する。これにより、ユーザーは、必要だと感じる時に、その電話で動くＭＤＴアプリケーションのコントロールを有し、別のアプリケーションと同様に、アプリケーションをシャットダウンすることが必要である。よって、利用者の知覚をうまくサポートするために、ＵＥは、アクティブまたはアイドルモードで行われるＭＤＴロギングおよび測定のために、バッテリーハンドリングを実施する必要がある。ネットワークにより命令されるよりはむしろ、バッテリー状態に基づいて、自主的な動作により、アイドルモードで初期化されるほとんどのアプリケーション工程の原理に従わなければならない。現在のシステムにおいて、３ＧＰＰ ＵＥがオフになる時、ＵＥは、保存された全ＭＤＴ情報を損失すると仮定する。じっくりと低バッテリー状態を検出する時、ＵＥは、自動的にオフになる。よって、このように高い電力消耗アクティビティに対し、ＭＤＴロギングのように、低バッテリー状態をうまく処理するような改善が必要とされる。さらに、このようなバッテリー状態ハンドリングは、状態がテスト可能であるように、測定可能な方法を有することが必要ある。

ＭＤＴ情報ロギングおよび問題イベント報告の方法が提供される。本方法は、リファレンスイベント（reference event）のプロビジョニングをサポートして、システム時間と問題発生の相互関係を有効にする。一態様において、問題イベント報告は、リファレンスイベントに直接または間接的に関連する時間情報を含む。バッテリー状態のハンドリング方法も提供される。本方法は、所定のバッテリー状態に基づいて、自立的（autonomously）に、ＭＤＴ中、ＯＡＭアクティビティの一時停止（サスペンド）または再開（レジューム）をサポートする。一態様において、テスト可能なバッテリー状態ハンドリングがＭＤＴロギングのために設計される。

本発明の態様は、リファレンスイベントを用いて、問題イベント報告中、関連時間情報を提供する方法を提供し、ユーザー装置（ＵＥ）により、イベント設定情報を獲得し、イベント設定情報は、無線ネットワーク中で、複数のリファレンスイベントと関連する工程と、問題イベントを検出する工程と、問題イベントをロギングし、これにより、問題イベント報告を生成する工程と、問題イベント報告を伝送し、問題イベント報告が、設定されたリファレンスイベントの発生に関連する関連時間情報を提供する工程、を含む。関連時間情報に基づいて、ネットワークは、問題イベントの絶対時間を推定することができる。関連時間情報は、問題イベント報告の工程を単純化する。

本発明の別の態様において、バッテリー状態を用いて、ＯＡＭアクティビティを管理する方法は、ユーザー装置（ＵＥ）のバッテリーの状態を監視する工程と、低バッテリー状態を検出する工程と、低バッテリー状態を検出時、操作、管理およびメンテナンス（ＯＡＭ）アクティビティに、自立的に、一時停止動作を実行する工程、および、ＵＥが低バッテリー状態を終了する時、自立的に、ＯＡＭアクティビティに再開動作を実行する工程、を含む。改善されたバッテリー状態ハンドリング、および、バッテリー状態に基づいたＯＡＭアクティビティを一時停止および再開する革新ステップは、ＭＤＴをうまく利用して、ネットワーク計画および利用者の知覚を改善するのを助ける。
他の実施の形態及び利点が以下の詳細な説明に述べられる。この概要は、本発明を定めるものではない。本発明は、請求項によって定められる。

図１は、一新規態様による無線通信システムとＵＥのブロック図である。 図２は、相対時間を用いた問題イベント報告の方法とフローチャートである。 図３は、両ユーザー装置とネットワークに知られるコモンイベントをリファレンスイベントとする本発明の一態様を示す図である。 図４は、ＵＥからネットワークへの成功した接続がリファレンスイベントである本発明の一態様のフローチャートである。 図５は、問題イベント締め切りタイマーが設置される本発明の一態様のフローチャートである。 図６は、ＭＤＴロギングおよび報告が多重無線アクセス技術（ＲＡＴ）設定に用いられる無線通信ネットワークのアーキテクチャを示す図である。 図７は、ＭＤＴの低バッテリー状態を処理する本発明の一態様を示す図である。 図８は、本発明の一態様を用いて、ＭＤＴの低バッテリー状態を処理する方法のフローチャートである。 図９は、一時停止ＯＡＭ-アクティビティ動作が設定可能である本発明の一態様によるフローチャートである。

本発明の実施態様について詳細に述べる。その例は添付画面に示されている。
図１は、一新規態様による無線通信システム１００とＵＥ１０１のブロック図１２０を示す図である。図１は、ある本発明の態様をサポートするＵＥ１０１のブロック図１２０である。アンテナ１３４は、ＲＦ信号を送受信する。アンテナ１３４に結合されるトランシーバモジュール１３３は、アンテナ１３４からＲＦ信号を受信し、それらをベースバンド信号に転換し、プロセッサ１３２に伝送する。トランシーバ１３３は、プロセッサ１３２から、受信したベースバンド信号も受信し、それらをＲＦ信号に転換し、アンテナ１３４に伝送する。プロセッサ１３２は受信したベースバンド信号を処理し、異なる機能モジュールを起動して、ＵＥ１０１中の特徴を実行する。メモリ１３１は、プログラム命令とデータを保存し、ＵＥ１０１の操作を制御する。

図１は、本発明の態様を実施する３個の機能モジュール１４１、１５１および１５２も示す。イベント検出とロギングモジュール１４１は、設置されたまたは組み込まれたあるイベント、たとえば、システム中の問題イベントおよび設定情報からのリファレンスイベントを検出する。関連イベントを検出するモジュール１４１は、設定情報または組み込まれた命令に基づいて、このようなイベントおよび別の情報をログする。バッテリー検出モジュール１５１は、テスト可能なバッテリー状態を検出し、このような状況を処理して、バッテリー情報を生成する。このようなバッテリー情報は、ＯＡＭ制御モジュール１５２に流れ、バッテリー情報および別の関連情報に基づいて、ある所定のＯＡＭアクティビティを一時停止または再開する。ブロック図１２０中の機能モジュールは、本発明の態様を実施するように設計され、ネットワーク計画を最適化する。以下で、本発明の態様の詳細を討論する。

相対時間
図１に示されるように、ＬＴＥシステム１００は、複数のｅＮＢ１０２、１０３、１０４、１０５および１０６を含む。ＵＥ１０１はｅＮＢ１０２と接続され、設定情報をＵＥ１０１に伝送して、ＵＥ１０１から、問題イベント報告を受信する。ネットワーク１１０と通信中のｅＮＢは、ＵＥ問題イベント報告を、ネットワーク１１０に伝送または転送することができる。本発明の一態様において、関連時間情報は問題イベント報告に用いられる。この方法は図１に示される。問題イベントに関連する相対時間を使用し、これにより、ＵＥ１０１に、正確な参照時間を知ることを要求しない。代わりに、ネットワーク構成要素、たとえば、ｅＮＢ１０２またはネットワーク１１０は、ＵＥ１０１により設定される関連時間情報および一般に知られているリファレンスイベントに基づいて、問題イベントの絶対時間Ｂを推定することができる。

ｅＮＢ１０２およびＵＥ１０１は、一組の所定の一般に理解されたリファレンスイベントを有する。リファレンスは、設定プロセスまたは組み込まれた命令により得られる。リファレンスイベントは、ＵＥ１０１とネットワーク構成要素、たとえば、ｅＮＢ１０２とネットワーク１１０間の問題イベントの送信や受信の時間上で共通認識を与える一般によく知られたイベントである。たとえば、ハイブリッドＡＲＱ（ＨＡＲＱ）伝送の自動再送要求（Automatic Repeat Request、ＡＲＱ）の例において、ＵＥ１０１およびｅＮＢ１０２に知られるコモンイベントは、伝送の開始となるか、または、問題イベント報告、または、問題イベントや問題イベント報告に関連するその他の指示を実行する伝送の時、アップリンク（ＵＬ）リソースの要求または許可の時間となる。リファレンスイベントの別の例は、ＵＥ１０１とｅＮＢ１０２間で構築される成功した接続である。

ステップ（１）で、図１に示されるように、設定された、または、一般によく知られたリファレンスイベントが発生する。ＵＥ１０１は相対時間の測定を開始する。ステップ（２）で、ＵＥ１０１は問題イベントを検出する。その後、ＵＥ１０１は、リファレンスイベントの時間および問題イベントの時間からの期間を、相対時間としてログする。ＵＥ１０１は、直接、この相対時間を時間情報とするか、または、その他の方式で、相対時間を用いて、時間情報を生成する。本発明のある態様において、ＵＥは、まず、問題イベントを検出し、その後、リファレンスイベントを検出する。リファレンスイベントと問題イベントの発生は任意の順序である。

ステップ（３）で、ＵＥ１０１は、問題イベント報告中にこの時間情報を含み、問題イベント報告をｅＮＢ１０２に伝送する。ステップ（４）で、ｅＮＢ１０２は、問題イベント報告をネットワーク１１０に伝送する。問題イベント報告中の時間情報およびリファレンスイベントの絶対時間の情報に基づいて、ｅＮＢ１０２またはネットワーク１１０は、問題イベントの絶対時間を推定することができる。この関連時間情報は、問題イベント報告の工程を単純化することができる。このような特徴は、既にＵＥチップセットによりサポートされているので、ＵＥ１０１にとって、相対時間の測定は非常に容易である。また、ＵＥ問題イベント報告中、ネットワークは、時間情報から、絶対時間スタンプを容易に推定することができるので、ネットワークプロセスを単純化する。

図１中、問題イベント報告の相対時間方法の特定の例しか示されていないが、当業者なら理解できるように、このような方法は、別の類似するスキーム、たとえば、ログされたＭＤＴに用いることができる。

図２は、無線通信システム中、相対時間を用いた問題イベント報告の方法のフローチャートである。ステップ２０１で、ＵＥはリファレンスイベントを検出する。このようなリファレンスイベントの例は、以下の討論で示される。ＵＥおよび少なくともひとつのネットワーク構成要素は、共に、リファレンスイベントを理解する。ネットワーク構成要素の例は、無線通信システム中のＵＥのサービングｅＮＢまたは別のネットワークノードである。このような相互理解は、設定メッセージを用いることにより達成されるか、または、ＵＥとネットワーク構成要素両方の機能モジュール中に組み込まれる。

ステップ２０１で、ＵＥは問題イベントを検出する。一般の問題イベントは、無線リンク障害、ＲＡＣＨ失敗、ハンドオーバ失敗または呼設定失敗である。それは、セル再選択失敗、または、別のアイドルモードイベントでもある。ＵＥは、追加の問題イベントの検出に適合できなければならない。

ステップ２０３で、問題イベントを検出するＵＥは、問題イベントをログし、問題イベント報告を生成する。この問題イベント報告は、リファレンスイベントに関連する時間情報を含む。本発明の一態様において、時間情報は、ＵＥとネットワーク構成要素両方に知られている問題イベントと設定されたリファレンスイベント間の時間間隔である。ステップ２０４で、ＵＥは、時間情報を提供する問題イベント報告を伝送し、時間情報は、検出されたリファレンスイベントの発生に関連する。それを受信するネットワークは、時間情報と既知のリファレンスイベントを関連付けることにより、問題イベントの絶対時間を容易に推定することができる。

図３は、両ユーザー装置とネットワークに知られるコモンイベントが、リファレンスイベントとして設置されるまたは定義される本発明の一態様を示す図である。ステップ３１１で、ＵＥ３０１およびｅＮＢ３０２両方に知られるコモンイベントが発生する。ステップ３２１で、ＵＥ３０１は、相対タイマーをスタートさせ、経過時間の計数を開始する。当業者なら理解できるように、経過時間を計数する異なる方法がある。一例は、近頃、ＵＥチップセットに一般的に利用される組込関数（built-in function）を用い、たとえば、時間ユニット中の計数は、無線フレームまたは伝送時間間隔または割合またはそれらの組み合わせに対応する。リアルタイマーまたはタイムスタンピングのもうひとつの方法は、開始時間が用いられる。ＵＥ３０１は、任意の手段を用いて、同じように、コモンイベント発生時間を指摘する。同時に、ステップ３３１で、ｅＮＢ３０２は、コモンイベントに注目し、ステップ３３１で発生するコモンイベントの参照時間をマークする。一定期間後、ステップ３２２で、問題イベントが発生する。ステップ３２３で、この問題イベント検出時、ＵＥ３０１は、関連時間情報と共に、問題イベントをログし、関連時間情報は、コモンイベントと問題イベント間の期間である。ステップ３１２で、ＵＥ３０１は、関連時間情報と共に、問題イベント報告をｅＮＢ３０２に伝送する。ステップ３２３とステップ３１２間にギャップがある。ステップ３３２で、問題イベント報告の受信時、ｅＮＢ３０２は、問題イベント報告の関連時間情報およびコモンイベントの参照時間（ステップ３３１に示される）を関連付けることにより、問題イベントの絶対時間を推定する。これにより、問題イベントは、問題イベントが発生する時間、適切に、ネットワークの状態の役に立つ情報をタイムスタンプおよび表示する。

図４は、ＵＥからネットワークノードへの成功した接続がリファレンスイベントである本発明の一態様のフローチャートである。この態様において、ＵＥは、ＵＥが、問題イベントが発生する前に最後にうまく接続されるセルに知られている時間基準、および、問題イベントの時間の間の期間を提供する。図４に示されるように、ステップ４１１で、ＵＥ４０１は、ｅＮＢ４０２により供（served）されるセルにうまく接続される。ステップ４２１で、ＵＥ４０１は、相対タイマーをスタートして、ｅＮＢ４０２により供されるセル中のそのドエリングタイム（dwelling time）を計数する。上記と同様、当業者なら分かるように、経過時間を計数する方法には、豊富な選択の幅がある;それらすべてが適当に実行される場合、ドエリングタイム情報を得ることができる。ステップ４３１で、ｅＮＢ４０２は、ＵＥ４０１からの成功した接続の時間にも注意する。ステップ４２２で、問題イベントが発生する。問題イベントが、ＵＥ４０１で、ｅＮＢ４０２から離れる、または、異なるｅＮＢにより供される別のセルに進入するとき発生すると仮定する。別の場合、ステップ４２３で、ＵＥ４０１は、ｅＮＢ４０２と共に、そのドエリングタイム分の関連時間情報を含む問題イベントをログする。ステップ４１２で、ＵＥ４０１は、関連するドエリングタイムにより、問題イベント報告を、ｅＮＢ４０２（図示されている）または前記の異なるｅＮＢに伝送する。問題イベント報告受信時、ステップ４３２で、ｅＮＢ４０２、または、前記の異なるｅＮＢとｅＮＢ４０２は、協力して、最後に成功した接続時間の一般によく知られたイベントおよび問題イベント報告中の関連時間情報に基づいて、問題イベントの絶対時間を推定する。

本発明のこの特定の態様の長所は、各ｅＮＢまたは基地局は、その最適化目的に関与する分散型アーキテクチャによく表れている。このようなアーキテクチャにおいて、問題イベント報告は、この問題にもっとも関与するｅＮＢにフィードバックされなければならない。多くの場合、このようなｅＮＢは、問題が発生する前、最後に成功して接続されるｅＮＢである。ここで、ＵＥが、ｅＮＢとドエリング（dwelling）する時間を提供することができると仮定する。ドエリングタイムは、ＵＥがセルに進入してから離れるまでの期間である。通常、問題イベントは時間が非常に迫り、Ａ）ＵＥが最後に知られたセルから離れる、または、Ｂ）ＵＥが別のセルに進入することに関連する。このような原理を用いる一般特徴は、自己組織ネットワーク（Self Organizing Networks、SON）のモビリティーロバスト性最適化（MOR）である。実際の実施において、ＵＥは自身を識別する必要があるので、最後に接続された前のセル中、既知のコモンイベントに関連付けることが可能である。たとえば、ＬＴＥにおいて、ＲＡＮは、前のセルで用いられるＵＥ識別子を知らない。注意すべきことは、問題イベントの前、ＵＥがうまく接続したセルは、別のＲＡＮノードにより制御され、ＲＡＮノードが、ＵＥが問題イベント報告をするノードと異なることである。これにより、ＵＥは、アドレス指定情報（addressing information）を提供し、セル中で、それ自身を識別する必要があり、ＵＥは、問題イベント発生前、たとえば、ＣＲＮＴＩまたは再構築認証コード（re-establishment authentication code）により、最後にうまく接続される。

保存された問題イベント報告を含む別の問題は、保存された報告がメモリリソースを受け入れ（take up）、一定時間後、報告は、古すぎて提供できないことである。本発明の別の態様において、この問題を解決するため、締め切りタイマーが用いられる。本発明の一態様において、この特定の問題イベントの締め切りタイマーが期限切れ（時間満了、期限終了）になった後、ＵＥは保存された問題イベント報告を報告しない。本発明の別の態様において、ＵＥは、問題イベント報告を残すか放棄するかを選択することができる。

図５は、問題イベント締め切りタイマーが用いられる本発明の一態様のフローチャートである。本発明のこの態様において、ＵＥは、締め切りタイマーを用いて、問題イベントを報告し、締め切りタイマーは、問題イベントの発生に関連する。図５は、この態様の例を示す。ステップ５１１で、ＵＥ５０１は問題イベントＡを検出する。ステップ５１２で、ＵＥ５０１は締め切りタイマーをスタートする。ステップ５１３で、ＵＥ５０１は、この問題イベントＡをログする。それから、ステップ５１４で、締め切りタイマーは期限切れ（満了）で、問題イベントＡはまだ伝送されない。

締め切りタイマーの期限切れは、未送信のログされた問題イベントの陳腐化（stale）を示す。本発明の一態様において、ＵＥ５０１は、陳腐化した問題イベント全てを放棄する。本発明の別の態様において、ＵＥ５０１は、ログされた問題イベントを保留するか放棄するかを選択するように構成される。図５に示されるように、ステップ５１５で、ＵＥ５０１は、問題イベントが放棄されるべきか確認する。ＵＥ５０１で、放棄されるべきであると判断される場合、ステップ５１７で、問題イベントＡが放棄される。ＵＥ５０１が問題イベントの保持に適する場合、ステップ５１６で、問題イベントＡが保持される。

ステップ５２１で、ＵＥ５０１は、別の問題イベントＢを検出する。ステップ５２２で、ＵＥ５０１は、問題イベントＢの締め切りタイマーをスタートする。ＵＥは、各問題イベントに対し、一つの締め切りタイマーを使用する、または、複数の問題イベントに対し、一つの締め切りタイマーを使用するように設定または構成される。ステップ５２３で、ＵＥ５０１は、この問題イベントＢをログする。ステップ５３０で、問題イベントＢの締め切りタイマーの期限切れの前、ＵＥ５０１は、問題イベント報告をｅＮＢ５０２に伝送する。

ＵＥ５０１が、陳腐化した報告を放棄するように設定または構成される場合、問題イベント報告は、問題イベントＢだけを含み、問題イベントＡは含まない。問題イベント報告は、締め切りタイマーの時間情報も含む。このような締め切り時間情報は予め定義され、ＵＥ５０１およびｅＮＢ５０２として知られている。問題イベント報告の受信時、ｅＮＢ５０２は、ＵＥ５１０から、締め切り時間情報からの時間基準を推定することができる。ｅＮＢ５０２は、問題イベントＢの正確な時間を得ないが、ｅＮＢ５０２は、締め切りタイマーの期限切れであるような問題イベントの発生の時間の上界を推定することができる。

本発明のこの態様は、ネットワークに、そうたいてきに正確なタイムスタンプを増加させることができる。この態様の方法は、特に、関連設定が少し変化するネットワークに応用するのに有利で、相対的に正確なタイムスタンプの使用はこの状況に十分に応用される。このアプローチの長所は簡単であることである。追加のシグナリング要求がない。

本発明の別の態様において、インジケーターが加えられて、ネットワーク追加時間情報が正確かどうかフラグ（flag）する。一例は、現在の即時ＭＤＴ報告で、インジケーターが追加されて、非正確タイムスタンピングを信号で伝える。図６は、ＭＤＴロギングおよび報告が多重無線アクセス技術（ＲＡＴ）設定に用いられる無線通信ネットワーク６００のアークテクチャを示す図である。ステップ６２１で、ネットワークデバイス６１０は、測定データ入手要求（get-measurement-data request）をｅＮＢ６０５に伝送し、これは、ＭＤＴをサポートするＲＡＴ中にある。ステップ６２２で、ｅＮＢ６０５は、ＭＤＴ設定メッセージをＵＥ６０１に伝送し、これは、ｅＮＢ６０５に接続されている。ＵＥ６０１は、ＭＤＴ測定とロギングを開始する。ステップ６２３で、ＵＥ６０１が移動し、ｅＮＢ６０２により供され、これは、ＭＤＴをサポートしない異なるＲＡＴにある。これらの場合、ＵＥ６０１は、新しいセルに接続されるか、ここに位置（camped）する。しかし、ＵＥ６０１は、ＭＤＴロギングを続行する。ステップ６２４で、ＵＥ６０１はｅＮＢ６０５と再接続される。ステップ６２５で、ＵＥ６０１は、ＭＤＴ報告をｅＮＢ６０５に送り戻す。このＭＤＴ報告は、報告が遅延したインジケーターを含む。図６は、遅延-インジケーターをＭＤＴに追加する例を示す図である。遅延-インジケーターを含む始動（trigger）は、異なる公衆陸上移動網（ＰＬＡＮ）により供されるＵＥ６０１のイベントでもある。始動は、問題イベント発生後、報告を伝送するときのある程度の時間の遅延である。このような遅延-インジケーターの追加の決定も設定可能である。ＵＥ６０１は、そのロギングと報告中に、新しく定義される始動イベント（triggering event）を含み、この遅延-インジケーターを追加することに適応するように設計される。

上述で討論される本発明の態様は、ネットワークが、問題イベントとその並列ネットワーク状態をうまく関連付けることができるようにする。

バッテリー状態ハンドリング
時間情報と問題イベントまたはＭＤＴ報告の効果的な関連付けは、ネットワーク最適化を改善する重要な態様である。ＭＤＴが３ＧＰＰ規格で発展して、サービスエリアおよび別のネットワーク計画情報を入手するのを助ける時、どのようにして、ＭＤＴのバッテリー状態を効果的に処理するかが重要になっている。ＭＤＴは高いエネルギー消耗なので、ＭＤＴのバッテリーハンドリングの改善が必要とされる。

バッテリーハンドリングを導入する別の主要な理由は、利用者の知覚である。正常なＵＥと正常なユーザーにとって、利用者の知覚は、ＯＡＭ目的のＵＥアクティビティより高い優先度を有すると仮定される。よいバッテリー状態にあるＵＥのロギングと報告は、ユーザー体験にわずかな影響があるまたは影響がないと仮定される。ユーザーは、とにかく、ＵＥバッテリーを頻繁にチャージしそうである。しかし、悪いバッテリー状態でのＵＥのロギングおよび記録は、ユーザー体験に顕著な影響があると仮定される。ＵＥバッテリーのチャージを忘れた、または、旅行／移動で充電できないユーザーは、バッテリーパフォーマンスを管理し、電量を制限することができる。ＯＡＭロギングを追加する場合、バッテリー寿命への影響は大きいと認識される。これにより、よい利用者の知覚をサポートするため、ＵＥは、バッテリーハンドリングを長期的に実施して、一般に、ロギングを含む測定およびデータ収集する必要がある。ＵＥは、バッテリー状態に基づいて、ネットワークにより命令されるのではなく、自主的な動作を採取しなければならない。ＵＥは、低バッテリー状態で、ＯＡＭ目的のアクティビティを停止すべきである。本発明の以下の態様は、バッテリー状態ハンドリングをテスト可能に、さらに効率的にする方法を提供する。

図７は、ＭＤＴの低バッテリー状態をハンドルする本発明の一態様を用いた方法のフローチャートである。ステップ７０１で、ＯＡＭアクティビティを実行するＵＥは、このＵＥのバッテリーの状況を監視する。一般のＯＡＭアクティビティは、ネットワーク操作目的の情報装置でロギングする工程、たとえば、ＭＤＴまたは装置の観察と測定報告を含む。ステップ７０２で、ＵＥは、低バッテリー状態または非低バッテリー状態を検出する。ステップ７０３で、低バッテリー状態の検出時、ＵＥは、ＯＡＭアクティビティに、自立的一時停止動作を実行する。ステップ７０４で、ＵＥが低バッテリー状態を終了する時、ＵＥは、ＯＡＭアクティビティに、自立的再開動作を実行する。

本発明の一態様において、ＯＡＭアクティビティを一時停止または再開するＵＥは、計画的な不連続（deliberate discontinuity）の情報をログして、ログ中のギャップが計画的なものであるか示す。このような情報は、さらに、計画的な不連続、たとえば、リソース問題やバッテリー問題の原因を含む。このような情報は、含まれたＯＡＭアクティビティログで、且つ、別のＯＡＭアクティビティログ情報と共に、持続型メモリ（persistent memory）に書き込まれる。

図８は、ＭＤＴの低バッテリー状態をハンドルする本発明の一態様のブロック図である。ステップ８１１で、ネットワークデバイス８１０は、シグナリングメッセージをｅＮＢ８０２に伝送して、ＯＡＭアクティビティを開始する。ステップ８１２で、ｅＮＢ８０２は、ＯＡＭ設定メッセージをＵＥ８０１に伝送する。ステップ８２１で、ＵＥ８０１がＯＡＭアクティビティを開始後、ステップ８２２で、ＵＥ８０１は、ＵＥ８０１が、低バッテリー状態で動いているかを確認することにより、バッテリー状態を監視する。低バッテリー状態を実施するため、テスト可能でなければならない。一般に、低バッテリー状態は、幾つかの態様の情報の組み合わせにより決定される。ＵＥが、“制限のない”電源、たとえば、チャージャーから電力を供給される場合、バッテリーレベルにかかわらず、ＵＥは、非低バッテリー状態であると判断される。一方、ＵＥが制限された電源、たとえば、バッテリーで電力を供給される場合、低バッテリー状態は、残りのスタンバイバッテリー寿命に関連する。低バッテリー状態も利用者の知覚に関連する。残りのバッテリー寿命が低くなるまで、重大な利用者の知覚影響は発生しないと仮定する。一態様において、残りのスタンバイバッテリー寿命は、絶対時間により、バッテリーが使い果たされる前に残っているスタンバイ時間で示される（たとえば、スタンバイ時間残り４時間）。本発明の別の態様において、残りのバッテリー寿命は、相対時間、たとえば、フルに充電された時のスタンバイバッテリー寿命のパーセンテージである（たとえば、スタンバイ時間残り10%）。

ステップ８２２で、ＵＥ８０１は、バッテリーが低バッテリー状態でないと判断する場合、ステップ８２３で、ＯＡＭアクティビティを続行し、ステップ８２２に戻って、バッテリー状態の監視を継続する。しかし、ステップ８２２で、ＵＥ８０１が低バッテリー状態を検出する場合、ステップ８２４で、ＯＡＭアクティビティを一時停止する。ＯＡＭアクティビティの一時停止後、ＵＥ８０１は、バッテリー状態の監視を継続する。ステップ８２５で、ＵＥ８０１はバッテリー状態を確認する。バッテリー状態が低い場合、ＵＥ８０１はステップ８２４で留まり、ＯＡＭアクティビティを一時停止する。ＵＥ８０１が低バッテリー状態を終了する場合、ステップ８２６で、ＯＡＭアクティビティを再開して、その後、ステップ８２２に戻り、全体のプロセスを繰り返す。

本発明の一態様において、低バッテリー状態に進入した時、ＵＥ８０１は、集まったデータの損失の防止を試みる。これは、特に、シグナルＵＥが追跡され、トラブルシューティングの問題の測定を収集する場合に有利である。たとえば、ＵＥ８０１が、ロギングデータによりすでにＭＴＤログを形成している場合、ネットワークへの接続を初期化し、ＭＤＴログがあることを示し、ネットワークが、低バッテリー状態、つまり、ＵＥがパワーオフになる前の劣悪条件下で、ログをフェッチできるようにする。別の態様において、ＵＥ８０１で、このようなロギングデータが存在する場合、そのロギングデータを持続型メモリに保存する。さらに別の態様において、低バッテリー状態が検出される時、ＵＥ８０１は、ＯＡＭアクティビティログとロギングデータを一緒に持続型メモリに保存する。

本発明の一態様において、ステップ８２４で、ＯＡＭアクティビティサスペンション動作は設定可能（configurable）である。図９は、ＯＡＭアクティビティ一時停止動作が設定可能であるこの具体例のフローチャートである。ステップ９０１で、ＵＥが低バッテリー状態を検出する時、ＯＡＭアクティビティ一時停止動作に進入する。ステップ９０２で、ＵＥが、無分別に、全ＯＡＭアクティビティを一時停止する前、ＵＥは一組の設定データを入手する。この設定情報は、ネットワークから伝えられる、または、ＵＥ命令に組み込まれる／定義される。ＵＥは、ネットワークコマンドか内部ロジック決定かにより、この設定情報を動的に更新するように設定される。ステップ９０２で、一旦、ＵＥが、設定データを入手すると、任意のＯＡＭアクティビティを一時停止するために設定されるかを確認する。本発明の一態様において、低バッテリー状態であっても、ＵＥは、ＯＡＭアクティビティを全く一時停止しないように設定することができる。このような場合、ステップ９０４で、ＵＥはＯＡＭアクティビティを続ける。ステップ９０３で、ＵＥが、ＯＡＭアクティビティの一部または全てを一時停止することが必要であると判断する場合、ＵＥは、それに応じて作用する。よって、ステップ９０５で、ＵＥは、各ＯＡＭアクティビティが一時停止されるか判断する。ステップ９０５で、アクティビティが一時停止されると判断する場合、ステップ９０７で、このＯＡＭアクティビティを一時停止する。ステップ９０５で、ＯＡＭアクティビティを一時停止しないと判断する場合、ＵＥは、ステップ９０６で、ＯＡＭアクティビティを続行する。

本発明の別の態様において、一時停止動作は、あるＯＡＭアクティビティを一時停止するが、別のＯＡＭアクティビティを作動し続けるように設定することができる。たとえば、ＯＡＭ設定が維持され、ＯＡＭロギングが一時停止される。本発明の別の態様において、ＵＥ８０１は、複数のＯＡＭアクティビティ設定タイマーの作動を維持し、ＯＡＭロギングアクティビティが一時停止される。上述の態様の一方で、ＵＥ８０１は、アクティビティの別の組み合わせを一時停止するように設定され、残りは作動を維持する。一態様において、ＯＡＭアクティビティを再開するステップ８２６も同様に設定可能である。ＵＥは、同様のステップを実行して、設定または所定の状態に基づいて、全てまたは一部のＯＡＭアクティビティを再開する。

バッテリー状態に基づいた、改善されたバッテリー状態ハンドリング、および、ＯＡＭアクティビティを一時停止および再開する革新ステップは、ネットワーク計画のＭＤＴをうまく活用して、利用者の知覚を改善するのを助ける。本発明は、ユーザーやオペレーターにフレキシブル性を与え、設置により、低バッテリー状態を設定する。このような設定はＵＥ仕様で、オペレータにさらなるフレキシブル性を与える。さらに、自立的に、ＯＡＭアクティビティを再開する革新ステップは、ネットワークが、効果的な設定計画を実行するのを簡単にする。ＵＥが、ＯＡＭアクティビティ期間全体のＯＡＭアクティビティを実行することが信用できる時、ネットワークは、期間の始まりとただ待っている時、ＵＥを設置する。ネットワークは、ＯＡＭアクティビティを再配置して、再開を保証する必要がなく、ＵＥは、それ自身のバッテリー状態ハンドリングにより、自立的に、ＯＡＭアクティビティを再開する。これは、単一の特定のＵＥが追跡され、測定およびデータ収集の実行を求められるときに、特に重要である。注意すべきことは、テストＵＥおよびテストユーザーは、バッテリーハンドリングが免除されることである。

本発明では好ましい実施例を前述の通り開示したが、これらは決して本発明に限定するものではなく、当該技術を熟知する者なら誰でも、本発明の精神と領域を脱しない範囲内で各種の変動や潤色を加えることができ、従って本発明の保護範囲は、特許請求の範囲で指定した内容を基準とする。

Claims (8)

1. ＭＤＴ情報ロギング及び報告の方法であって、
   ユーザー装置（ＵＥ）により、前記ＵＥとネットワークデバイスに共通に理解されるイベントであるリファレンスイベントを設定する工程と、
   無線ネットワーク中、前記ＵＥにより、前記リファレンスイベントを検出する工程と、
   前記ＵＥにより、問題イベントを検出する工程と、
   前記問題イベントをロギングし、これにより、前記検出されたリファレンスイベントに基づいて、問題イベント報告を生成する工程、および
   前記問題イベント報告を前記リファレンスイベントの絶対時間情報を有する前記ネットワークデバイスに伝送し、前記問題イベント報告は、前記問題イベントの発生と前記リファレンスイベントの発生との関連時間情報を提供する工程、
   を含むことを特徴とするＭＤＴ情報ロギング及び報告方法。
2. 前記問題イベントは、無線リンク障害（ＲＬＦ）、ハンドオーバ（ＨＯ）失敗、ランダムアクセスチャネル（random access channel、ＲＡＣＨ）失敗、初期接続設定失敗、セル再選択失敗、および、ＵＥがサービス停止状態に進入したことから構成される群から選択されることを特徴とする請求項１に記載のＭＤＴ情報ロギング及び報告方法。
3. 前記リファレンスイベントは、前記問題イベント報告の要求であることを特徴とする請求項１に記載のＭＤＴ情報ロギング及び報告方法。
4. 前記時間情報は、前記問題イベント報告および前記問題イベントの前記要求の間の期間を含むことを特徴とする請求項３に記載のＭＤＴ情報ロギング及び報告方法。
5. 前記リファレンスイベントは、前記問題イベントが発生する前の前記ＵＥと基地局の成功した接続であることを特徴とする請求項１に記載のＭＤＴ情報ロギング及び報告方法。
6. 前記時間情報は、前記ＵＥと基地局の前記成功した接続と前記問題イベント間の期間を含むことを特徴とする請求項５に記載のＭＤＴ情報ロギング及び報告方法。
7. 前記リファレンスイベントは、異なる無線アクセス技術（ＲＡＴ）または異なる公衆陸上移動網（ＰＬＡＮ）により供される前記ＵＥのイベントであることを特徴とする請求項１に記載のＭＤＴ情報ロギング及び報告方法。
8. 前記時間情報は、遅延報告インジケーターを含むことを特徴とする請求項７に記載のＭＤＴ情報ロギング及び報告方法。

Images