JP2015511459A - 自己組織化ネットワークネットワーク（ｓｏｎ）機能における競合検出のための方法及びシステム - Google Patents

Abstract

自己組織化サブネットワークからなるネットワークにおいてアクタ間の協調又は競合を検出するためのシステム及び方法が、性能インジケータ及び構成パラメータといったパラメータを検査して、異なるアクタが協調的又は競合的な手法で構成パラメータを調整しているか否かを判定する。性能インジケータが期待域の外側にあると観測された場合、アクタに性能インジケータを調整しその値の期待域に復帰させる時間を与えるために、受け入れ可能な収束域を定義することができる。性能インジケータが非収束的であることが検出されると、モニタ部は、オペレータ又は他のノードへ、適切なアクションをとり得るように警報を発することができる。【選択図】図１１

Description

本開示は、一般的に、自己組織化ネットワークネットワーク機能の間の競合の検出に関する。

自己組織化ネットワーク（ＳＯＮ）機能及び自己修復（Self healing）機能は、コンピュータネットワーキングアーキテクチャの分野における既知の技術である。AbdelAziz氏らの“Method and apparatus for self-organizing node groups on a network”というタイトルの米国特許第７，４６１，１６０号、Zhou氏の“Self-organized network setup”というタイトルの米国特許第７，７８８，７０７号、及びGessner氏らの“Self-Organizing Communications Network And Method For The Operation Thereof”というタイトルの米国特許出願公開第２０１１／０１２２８５１号を含むいくつかの異なる参考文献が、この分野の原理を教示している。“Telecommunication management; Self-Organizing Networks (SON); Self-healing concepts and requirements”というタイトルの３ＧＰＰ ＴＳ３２．５４１において、さらなる情報を見出すことができる。

ＳＯＮ及び自己修復の技法は、ネットワーク内の観測される問題を克服するために、ネットワーク構成パラメータ（ＣＰ）を自動化されたやり方で調整することを可能とするように設計される。典型的には、この技法は、分散型の自律的なコンピューティング処理及び機能を用いて実行される。ネットワーク（又はサブネットワーク）のステータス及び（性能インジケータ（ＰＩ）として参照されることになる）性能が（グローバルに又は定義されるノード群で、のいずれかで）測定され及び観測され、ネットワークを最適化し及びエラーを修復し又は回復するために、ＣＰのセットが動的に調整される。典型的には、調整されるＣＰは、ネットワーク事業者により設定される何らかのポリシー目標を達成するために行われる。

モバイル通信ネットワークの複雑さが増加するにつれ、ＬＴＥ（Long Term Evolution）ベースのネットワークにおいて問題に対し修復を行うネットワークの能力が非常に望ましいものとなった。ＬＴＥネットワークにおけるＳＯＮケイパビリティのための要件は、３ＧＰＰリリース８技術仕様ＲＳ３６．９０２において定義されている。

典型的な大規模な通信ネットワークは、多様なベンダのネットワークセグメントから構成され得る。ノードベンダは、自身のセグメントについてＳＯＮ及び自己修復機能を提供するはずである。ネットワークセグメントは他の複数のセグメントと接続することから、異なるセグメントで協調無しに動作する多様なＳＯＮ及び自己修復機能がネットワークリソースを奪い合い、それらの個々の目標の達成に失敗するかもしれない。各機器ベンダは、多様な構成パラメータを調整することができ、多くの場合、問題を解決するためにそれらを調整するやり方は異なる。これは、同一問題を解く発散的なメカニズムに帰結し得る。

ＳＯＮ及び自己修復機能は、ネットワーク内の異なるセグメントの間の潜在的な競合（conflict）を解決し得る前に、競合が生じようとしており又は発生したと判定することができることがまず必要である。

上で注記したように、慣例では、ＳＯＮケイパビリティ又は自己修復ion（Ｆ）は、「システム」と呼ばれる管理されるノード及び／又はネットワーク（若しくはサブネットワークのステータスをモニタリングする。そして、Ｆは、システムのステータスが所与の目的（objective）又はポリシー目標（policy goal）を満足させるかを評価する。不満足であれば、Ｆは関係するシステムのパラメータを調整する。このとき、モニタリング、評価及び調整というサイクルが再度始まる。効率性、コスト及びエラー率の低さを含む様々な異なる理由で、このサイクルを人間のオペレータの介在無しに遂行することが、多くの事業者により好まれている。

大規模なシステムは、一度にアクティブとなる複数のＦを有するであろう。人間のオペレータ及び様々なＯＡＭ（operational and maintenance）アプリケーションは、Ｆ群がアクティブか否かには依存せずに、必要であればシステムパラメータを構成するであろう。

上で注記したように、異なる複数の問題が生じ得る。コーディネータの不在下では、多様なＦが競合する手法でシステムを構成することを試みかねない（例えば、多様なＦがシステムパラメータを異なる値を用いて構成しようと試みるなど）。これは、あるＦが別のＦが問題を解消しようとして既に調整したパラメータを修正することに帰結する。コーディネータの存在下でも、Ｆに与えられたポリシー若しくはガイドラインが競合する目標を内包し、又はＦがバグフリーでない場合には、多様なＦがシステムを競合する手法で構成しようと試みるかもしれない。例えばエネルギー節約のための指示といった、最初のＦにより計算される通りの（パラメータ調整のための）構成指示は、ネットワーク障害を修復することを優先する指示といった、他のＦにより発行される構成指示と競合し得る。システムを管理する人間のオペレータ又はＯＡＭアプリケーションが、これらＦにより発行された指示と競合する構成指示を発行するかもしれない。

上述したＦ群、人間のオペレータ及びＯＡＭアプリケーションを、“アクタ（Actors）”と呼ぶことができる。目標の競合する複数のアクタが使用される場合、ＣＰ又はＰＩの値は発振するであろう。１つのアクタが使用される場合、ＣＰ又はＰＩの値はやはり発振し得る（例えば、Ｆが最初にアクティブになった時にシステムのＣＰを過補償又は補償不足のいずれかにし得ることで、ＣＰ又はＰＩの値の発振に帰結する）。これは通常の状況である。

問題は、システム上で目標の競合する複数のアクタが一度に動作していることに起因してＣＰ又はＰＩの値が発振しているかを知得するための信頼できる手法を事業者が有しないことである。アクタはバグ若しくはエラーを有し、又はアクタは正常に動作している。

従って、上述した問題を軽減し又は緩和するシステム及び方法を提供することが望ましいであろう。

本発明の目的は、従来技術の少なくとも１つの欠点を軽減し又は緩和することである。

本発明の第１の観点では、自己組織化ネットワーク内のネットワークエレメントに関連付けられる性能インジケータがその通常の期待域に向けて収束していないことをレポートするための方法が提供される。性能インジケータはモニタリングされ、プロセッサにより、第１の性能インジケータ値が上記性能インジケータに関連付けられる値の期待域の外側にあると判定される。上記性能インジケータが値の上記期待域に復帰すべき時間ピリオド、及び上記第１の性能インジケータ値からの許容可能な変動分に従って、受け入れ可能な値の収束域が上記性能インジケータのために定義される。第２の性能インジケータ値が定義された受け入れ可能な上記収束域の外側にあると判定することに応じて、レポートが生成される。

本発明の第１の観点の一実施形態では、上記第２の性能インジケータ値が上記第１の性能インジケータ値と上記許容可能な変動分との和よりも大きいことが判定される。代替的な実施形態では、上記時間ピリオドの満了の後に、上記第２の性能インジケータ値が上記性能インジケータに関連付けられる上記期待域の外側にあることが判定される。

他の実施形態では、上記方法は、第３の性能インジケータ値が上記性能インジケータに関連付けられる上記期待域の内側にあると判定することに応じて、上記性能インジケータのモニタリングを継続すること、を含み得る。代替的な実施形態では、上記方法は、第３の性能インジケータ値が定義された受け入れ可能な上記収束域の内側にあると判定することに応じて、上記性能インジケータのモニタリングを継続すること、を含み得る。

他の実施形態では、上記許容可能な変動分は、可変値である。上記許容可能な変動分の値を、上記時間ピリオドにわたって減少させることができる。

他の実施形態では、定義される受け入れ可能な上記収束域は、上記時間ピリオドの満了の後に上記性能インジケータに関連付けられる上記期待域へと収束するように、定義され得る。

他の実施形態では、上記モニタリングするステップは、モニタリング機能に関連付けられる通信インタフェースにより、上記第１の性能インジケータ値の測定結果を受信すること、を含み得る。

本発明の第２の観点では、通信インタフェースと処理エンジンとを備えるモニタリングノードが提供される。通信インタフェースは、第１の性能インジケータ値及び後続する第２の性能インジケータ値を受信するために構成される。処理エンジンは、第１の性能インジケータ値が上記性能インジケータに関連付けられる値の期待域の外側にあると判定する、ために構成される。処理エンジンは、上記期待域に復帰するための時間ピリオド、及び上記第１の性能インジケータ値からの許容可能な変動分に従って、受け入れ可能な値の収束域を定義する。処理エンジンは、第２の性能インジケータ値が定義された受け入れ可能な上記収束域の外側にあると判定することに応じて、レポートを送信するように上記通信インタフェースへ指示する、ように構成される。

本発明の第２の観点の一実施形態では、上記処理エンジンは、上記第２の性能インジケータ値が上記第１の性能インジケータ値と上記許容可能な変動分との和よりも大きいと判定することに応じて、レポートを送信するように上記通信インタフェースに指示する。代替的な実施形態では、上記処理エンジンは、上記時間ピリオドの満了の後に、上記第２の性能インジケータ値が上記性能インジケータに関連付けられる上記期待域の外側にあると判定することに応じて、レポートを送信するように上記通信インタフェースに指示する。

他の実施形態では、上記許容可能な変動分は、可変値である。上記許容可能な変動分の値を、上記時間ピリオドにわたって減少させることができる。

他の実施形態では、上記処理エンジンは、上記時間ピリオドの満了の後に、上記性能インジケータに関連付けられる上記期待域へと収束するように、受け入れ可能な上記収束域を定義する。

他の実施形態では、上記モニタリングノードは、上記性能インジケータに関連付けられる値の上記期待域と、定義される受け入れ可能な値の上記収束域と、を記憶するためのメモリ、をさらに含むことができる。

添付図面と併せて本発明の固有の実施形態の以下の説明を検討すれば、本発明の他の観点及び特徴が当業者に明らかとなるであろう。

次に、添付図面を参照しながら、単に例示の手法によって、本発明の実施形態について説明する。

ＰＩタイプ１について期待される値を例示するグラフである。 ＰＩタイプ２について期待される値を例示するグラフである。 ＰＩタイプ３について期待される値を例示するグラフである。 ＰＩタイプ１についてのＡＯＰを例示するグラフである。 ＰＩタイプ２についてのＡＯＰを例示するグラフである。 ＰＩタイプ３についてのＡＯＰを例示するグラフである。 ＰＩタイプ１についての放物線状ＡＯＰを例示するグラフである。 競合を検出するための方法の例示的な実施形態を示すフローチャートである。 競合を検出するための方法の例示的な実施形態を示すフローチャートである。 図９の方法の例示的な動作を示すグラフである。 本発明のシステムの複数のエレメントのインタラクションを例示するブロック図である。 単一の値について争う複数のアクタのインタラクションを例示するグラフである。 単一の値について争う複数のアクタのインタラクションを例示するグラフである。 単一の値について争う複数のアクタのインタラクションを例示するグラフである。 単一の値について争う複数のアクタのインタラクションを例示するグラフである。 例示的なＡＯＰにおける放物線間の水平対称軸を例示している。 例示的なＡＯＰにおける放物線間の垂直対称軸を例示している。 本発明の一実施形態を例示するフローチャートである。 例示的なモニタリングノードを示すブロック図である。

本発明は、２つ以上の異なる自己組織化及び自己修復ネットワーク機能の間の競合を検出するためのシステム及び方法を対象とする。

添付図面に従って付番された特定のエレメントへの参照が以下でなされ得る。以下の議論は、その性質上例示的であって、本発明の範囲の限定として受け取られるべきではない。本発明の範囲は、特許請求の範囲において定義されており、以下に説明する実装の詳細により限定されるものと見なされるべきではなく、当業者には理解されるように、エレメントを等価の機能エレメントに置き換えることにより、実装の詳細を修正することができる。

“システム”は、概して、その構成パラメータ（ＣＰ）及び性能インジケータ（ＰＩ）により特徴付けられることができる。ＣＰのいくつかの例は、ハンドオーバ閾値、電力設定、無線リソース管理（ＲＲＭ）処理に影響するパラメータ、物理チャネル（ＰＣＨ）リソース設定、無線アクセスチャネル（ＲＡＣＨ）関連パラメータ、周波数（例えば、ＥＡＲＦＣＮ（E-UTRA Absolute Radio Frequency Channel Number））、物理セルＩＤ（ｐｃｉ）、公衆地上モバイルネットワークＩＤ（plmnIdList）、トラッキングエリアコード（ＴＡＣ）を含む。ＬＴＥについてのＰＩの例は、アクセス可能性（Accessibility）、維持力（Retainability）、完全性（Integrity）、可用性（Availability）及び移動性（Mobility）を含む。ＰＩのいくつかの例は、様々なインタフェース上での接続確立試行及び接続確立成功、セル利用不能時間、ハンドオーバ試行及びハンドオーバ成功、などを含む。

ポリシー目標を、ＰＩ値のセットとして表現することができる。前提として、ネットワーク事業者は所望のＰＩ値のセットを有し、又は、ネットワーク事業者は所与の各ＰＩについて適切な若しくは正確な値を知得している。事業者は、それら期待されるＰＩ値が達成されるようにアクタが動作してシステムを構成するであろうことを前提とする。それが当てはまることを保証するために、モニタリング機能（モニタ部Ｍ）を導入して事業者の前提が正確であるか否かを判定することができる。

複数の異なるＰＩ及び複数の異なるアクタを有するネットワーク事業者は、モニタ部（Ｍ）を導入して、Ｍのクライアント（これ以降、クライアントという）から、特定のシステムＰＩの通常期待される複数の値を経時的に受け取ることができる。これを、ＰＩの期待域（expected range）と称する。追加的に、Ｍを用いて、識別されるＰＩの値をモニタリングし、それらが期待域により定義される境界の外側にあるかを判定することができる。観測されるＰＩの値が期待域の外側にある場合、Ｍは、そのクライアントへ（例えば、警告（warning）又は警報（alert）を送信することにより）状況を通知することになる。

当業者は、警告に対するクライアントからの応答が、複数の様々な手法で決定され得るものであり、警告が生成されるやり方には密接に関連しないことを理解するであろう。Ｍはスタンドアローンのエンティティとして議論されるが、当業者は、Ｍを双方のＦを含む複数の異なるノードに組込み、又はＯＡＭシステム内に組み込むことができることを理解するであろう。期待域の使用は、考慮されるパラメータの値の見込みを事業者が有している限り、ここで議論されるようなＰＩとは別の、他のタイプのパラメータにも適用されることができる。

また、ネットワーク事業者は、ＰＩについて受け入れ可能な発振パターン（ＡＯＰ）を定義することができる。ＡＯＰは、ＰＩ及びＣＰの値に作用するアクタが協調的に動作しているか又は互いに競合しているかを判定することを可能とする。ＰＩ及びＣＰの値をモニタリングして、受け入れ可能な値のセットへの収束が進行中であるかを判定することができる。典型的には、事業者は、アクタがシステムを適切に構成するであろうと想定し得る。ＣＰが構成されるべき正確な値をモニタ部及び／又は事業者が知得することを要する代わりに、モニタ部は、ＡＯＰを用いて、アクタがＣＰを適切に構成するであろうという前提が正しいか否かを判定することができる。

モニタ部（Ｍ）を用いて、（観測されるＣＰ値の）発振の大きさを、クライアントの所与の最大値に対して測定することができる。前者が後者よりも大きければ、Ｍはクライアントに状況を通知する（例えば、ＣＰを適切な値に設定することに関してアクタ群が協調的に働いていなそうである、など）。

観測されるＰＩ値が期待域の外側にあって、但し定義されるＡＯＰレンジの内側にあれば、モニタ部は、クライアントへ通報することを要しない。これにより、ネットワークに自己修復又は自己組織化のための十分な時間を許容することができ、事業者の介入を要することなく、ＰＩが受け入れ可能な値のレンジへと収束することが可能となる。

カウンタ又はキー性能インジケータとして知られることもある、システムのＰＩを用いて、システムの振る舞いのある様相を明らかにすることができる。システムが手動で管理され、Ｆにより管理され又はその２つの組合せにより管理されているかによらず、事業者は、ＰＩの値に関して２通りの見込み（expectation）を有することができる。第一に、ＰＩは正確なシステムの振る舞いを反映する定義される期待域（Ｅ＿ＰＩという）の内側に入るという見込みがある。第二に、ＰＩ値がＥ＿ＰＩから逸脱し始めた（例えば、その期待域の外側に出た）場合に、事業者は、対象のＰＩ値が特定の時間ピリオドの間にＥ＿ＰＩのレンジ内へと戻るようにＦ又は人間のオペレータがシステム構成値に対する修復のためのアクションをとること、を見込むことができる。

例示的な３つのタイプのＰＩが存在し、それらが図１、図２及び図３に描かれている。観測されるＰＩ値（即ち、ドット）がグラフ上にプロットされており、グラフは、時間を測る横軸１００と、ＰＩ値を測る縦軸１０２とを有する。

図１は、ＰＩの第１のタイプ（ＰＩタイプ１）についての値の期待域を例示するグラフである。ＰＩタイプ１についての事業者の見込みは、全ての観測されるＰＩ値が時間にわたって上界１０４及び下界１０６の内側にあるべきということである。図２は、ＰＩの第２のタイプ（ＰＩタイプ２）についての値の期待域を例示するグラフである。ＰＩタイプ２についての事業者の見込みは、全ての観測されるＰＩ値が時間にわたって下界１０８の上側にあるべきということである。図３は、ＰＩの第３のタイプ（ＰＩタイプ３）についての値の期待域を例示するグラフである。ＰＩタイプ３についての見込みは、全ての観測されるＰＩ値が時間にわたって上界１１０の下側にあるべきということである。

ＳＯＮの動作及びＦが収束を引き起こすであろう尤度の解析の実行において、Ｍのクライアントは、ＰＩのリストを識別することができる。そのＰＩは、経時的に変化し、収束があれば変化量は受け入れ可能域又はＡＯＰの範囲内に収まるであろう。識別された各ＰＩについて、クライアントはＰＩタイプに従ってそのＡＯＰを定義する。１つの実施形態では、ＡＯＰは、ＰＩ値の第１の観測される変動分（deviation）で開始する。上で注記したように、事業者は、受け入れ可能な若しくは正確なＰＩ値を、知得し又は定義済みとなるであろう。

図４は、ＰＩタイプ１についての例示的なＡＯＰを示している。ＰＩについての事業者の期待値であるＥ２０４、及びＥの上下の許容可能な変動分であるＤ１ ２０６により、上界２００及び下界２０２が定義される。値Ｔ１ ２０８は、ＰＩ値が当該ＰＩについての期待域の内側へ再び収まることを許容する時間である。Ｄ２ ２１０は、第１の観測される変動分２１２に対して相対的な、受け入れ可能であると見なされる追加の変動分である。このＡＯＰの境界２００及び２０２は、時間ピリオドＴ１ ２０８の間に観測される変動分がＰＩの期待域へと収束することを許容する。この例示的なＡＯＰは、Ｅ２０４により定義される軸に関して対称的である。

図５は、ＰＩタイプ２についての例示的なＡＯＰを示している。期待値Ｅ２１６により下界２１４が定義されている。Ｄ２ ２１８は、第１の観測される変動分２２０に対して相対的な、受け入れ可能であると見なされる追加の変動分である。値Ｔ１ ２２２は、ＰＩ値が下界２１４の上側へ収束することを許容する時間である。

図６は、ＰＩタイプ３についての例示的なＡＯＰを示している。期待値Ｅ２２６により上界２２４が定義されている。Ｄ２ ２２８は、第１の観測される変動分２３０に対して相対的な、受け入れ可能であると見なされる追加の変動分である。値Ｔ１ ２３２は、ＰＩ値が上界２２４の下側へ収束することを許容する時間である。

図４〜図６に関連して上で議論した３つの例示的なＡＯＰは、時間ピリオドＴ１にわたってＰＩ値が線形的に改善する（変動した値から適切な値へと移る）ことをクライアントが見込むようなＰＩにとって適切である。その代わりに、ＰＩ値の非線形的な改善をクライアントが見込むようなＰＩも存在する。図１に反映されたＰＩ値の例をとり、但しクライアントは改善が放物型の方程式に従うであろうとの見込みを表現する。図７は、放物型の方程式の１つの例示的な形式を示している。図４に関して議論したのと同様に、上界２３４及び下界２３６は、期待値Ｅ２３８及び許容可能な変動分Ｄ１ ２４０により定義される。Ｄ２ ２４２は、第１の観測される変動分２４４に対して相対的な、受け入れ可能であると見なされる追加の変動分である。値Ｔ１ ２４６は、ＰＩ値が当該ＰＩについての期待域の内側へ再び収まることを許容する時間である。この形式は、Ｔ１ ２４６の開始時に改善が大きいという見込みを表現している。

ＰＩ値の改善の見込みを表現する放物型の方程式の使用は、ここで説明したＰＩの３つのタイプ全てに適用可能である。放物型の境界のさらなる図示は、簡潔な議論の目的のために省略されているが、当業者によって良好に理解されるであろう

図８は、上で議論したようなＡＯＰ及びＰＩを用いたＳＯＮ間の競合を検出する例示的な方法を示すフローチャートである。処理は、モニタ部Ｍの初期化で開始される（ブロック３００）。クライアントは、モニタリングされるべきＰＩ、ＰＩのタイプ、及びＡＯＰを生成するために要する任意のパラメータを識別する（ブロック３１０）。クライアントは、ＰＩタイプ１についてパラメータＴ１、Ｅ、Ｄ１及びＤ２を供給し、ＰＩタイプ２及びＰＩタイプ３についてパラメータＴ１、Ｅ及びＤ２を供給し得る。そして、モニタ部Ｍは、ミニＭのセットを生み出し、各ミニＭは識別された１つのＰＩのモニタリングに責任を有する（ブロック３２０）。代替的な実施形態では、単一のＭのプロセスがＰＩのセットをモニタリングするが、開示されるやり方との動作におけるその相違は当業者には明らかであろう。そして、インスタンス化されたミニＭは、ＰＩ値を読み取る（ブロック３３０）。ブロック３４０において、ＡＯＰが不在であり且つＰＩの値が通常の境界（例えば、図１に例示したデータ点：ＰＩタイプ１についての期待値、図２：ＰＩタイプ２についての期待値、図３：ＰＩタイプ３についての期待値）の外側にある場合には、Ｍは、当該ＰＩについてのＡＯＰを生成し（ブロック３５０）、処理はＰＩ値の読み取りへと戻る（ブロック３３０）。ＡＯＰが不在であって値が通常の境界の内側にあれば（ブロック３６０）、プロセスはやはりＰＩ値の読み取りへと戻る（ブロック３３０）。

ブロック３７０において、ＡＯＰが生成済みであり上記ＰＩのために存在し、且つＡＯＰ境界（例えば、図４に示したデータ点：ＰＩタイプ１についてのＡＯＰ、図５：ＰＩタイプ２についてのＡＯＰ、図６：ＰＩタイプ３についてのＡＯＰ）の外側に値があると判定され、状況がクライアントへレポートされる（ブロック３８０）。処理は、オプションとして（図示したように）この時点で終了してもよく、又はＰＩの読み取りへと戻ることもできる（図示せず）。ＡＯＰが存在し値がＡＯＰ境界の内側にある場合（ブロック３９０）、処理は適切に動作していると想定することができ、ＰＩの読み取りへと戻る（ブロック３３０）。

当業者は、システムの構成パラメータ（例えば、アンテナの傾き、送信電力及びアンテナベアリング）の値の設定によってシステムの振る舞いが制御されることを理解するであろう。それら値の設定の間の競合を検出するために、図９に例示したような以下の処理に取り組むことができる。初めに、モニタ部Ｍがインスタンス化される（ブロック４００）。クライアントは、ＣＰを識別する（ブロック４１０）。この例のために、ＣＰはスカラー値であろう。クライアントは、当該ＣＰの値の、時間単位ＴのＮ個のインターバルとして定義される特定された時間ピリオドの間の、Ｍａｘという許容最大変化を供給する。そして、モニタ部Ｍは、ミニＭのセットを生み出し、１つのミニＭは識別された１つのＣＰのモニタリングに責任を有する（ブロック４２０）。当業者は、上で議論したように、ミニＭの使用が設計上の選択であって、様々な数のＭを使用することが等しく可能であることを理解するであろう。ミニＭは、関連するＣＰの値を読み取る（ブロック４３０）。次の時間インターバルにおいて、それは新たなＣＰの値を読み取る（ブロック４４０）。そして、新たなＣＰ値と前回のものとの間の差分が計算される（ブロック４５０）。Ｎ個のインターバルにわたって計算された全ての差分の合計がＭａｘ値を上回る場合（ブロック４６０）、状況がクライアントへレポートされる（ブロック４７０）。オプションとして、処理はこの時点で停止する。インターバルの数がＮ個を上回ると（ブロック４８０）、モニタ部は、最古のインターバルの差分を破棄し（ブロック４９０）、新たなＣＰ値の読み取りへと戻る（ブロック４４０）。

図１０は、図９の方法の例示的な動作を示すグラフである。この例において、Ｎ＝７である。観測されるＣＰ値５００は、時間軸に対してプロットされている。７個のインターバルの各々において観測される差分は、１０、２０、１０、２５、２０、５及び５であり、合計で９５となる。Ｍａｘが９５よりも大きい場合、モニタ部は最古の差分、即ち１０を破棄し、インターバル９において読み取りを行い、差分の和を再び集計し、そしてＭａｘに対するチェックを行うことになる。Ｍａｘが９５よりも小さい場合、モニタ部はクライアントへレポートを行うことになる。

図１１は、例示的なシステムのブロック図である。システムは、ネットワーク又はサブネットワークということのできる、管理下にあるノードの集合である。一例は、無線アクセスネットワークである。モニタ部Ｍ５１０は、ネットワーク内の単一のノードに物理的に位置することができ、又はネットワーク内で地理的に分散されることのできる、モニタリング機能又は論理的なエンティティである。クライアント５２０は、モニタ部５１０とのインタラクションを行うエンティティ（例えば、ネットワーク事業者）である。ミニＭ５３０ａ、５３０ｂ、５３０ｃは、前に説明したように、固有のＰＩについてモニタ部５１０により生成されるモニタリング機能を表現する。ノード５４０ａ及び５４０ｂは、モニタ部５１０及び／又はミニＭ５３０ａ〜ｃによりモニタリングされるシステムエレメントである。ノードの例は、無線基地局又はスイッチを含む。各ノード５４０ａ及び５４０ｂは、構成パラメータＣＰと性能インジケータＰＩとを有することができる。クライアント２０は、特定のＣＰ及び／又はＰＩを観測するリクエストをモニタ部５１０へ送信する。モニタ部５１０は、責任を有するＣＰ又はＰＩの値を読み取る複数のミニＭ５３０ａ〜ｃを生成し得る。ミニＭ５３０ａ〜ｃは、エラー（例えば、観測されたＰＩ値がＡＯＰ境界の外側にある）を検出した場合に、クライアント５２０へ通知を行うであろう。

上述した方法及び対応するシステムの実装は、マルチベンダ環境で使用されることができる。モニタ部Ｍのサービスを提供するエンティティは、ＳＯＮネットワークサブセットのいずれかのプロバイダのうちの１つでなくてもよい（即ち、システムは、ＳＯＮケイパビリティのベンダでなくてもよく、関与する管理下ノードのベンダでなくてもよい）。また、理解されるべきこととして、モニタ部Ｍの機能性を、ＳＯＮネットワークのうちの１つの内部のノード内に、複数の異なるＳＯＮネットワークの支配下のノード内に、又はＳＯＮネットワークセグメントのいずれかの外部に組み込むことができる。

次に、競合する自動化されたアクタにより制御されるシステムにおいて生じ得る予期される発振パターンを説明するために、例示的なグラフのセットが議論される。図１２は、２つのアクタが同じパラメータ５５０を調整しようと試行している典型的なシナリオを示している。このケースでは、１つのアクタはパラメータを値「４」に設定することを希望し、他のアクタは当該パラメータを値「５」に設定することを希望する。

図１３は、２つのアクタが同じパラメータ５６０を調整しようと試行しているシナリオを示しており、定義される境界５７０（例えば、設定することを許容される最大値）が存在する。このケースでは、１つのアクタはパラメータを値「６」に設定することを希望し、他のアクタは当該パラメータを値「１０」に設定することを希望する。

図１４は、２つのアクタが同じパラメータ５８０を調整しようと試行し、異なるタイムスケールで動作しているシナリオを示している。このケースでは、１つの機能はパラメータを値「１０」に設定することを希望して１０秒ごとに値を増分し、他のアクタは当該パラメータを値「３」に設定することを希望して値を１時間に１回設定し得る。

図１５は、あるアクタがパラメータ５９０を制御しており、外部影響がパラメータ５９０の値を変化させるシナリオを示している。このケースでは、アクタはパラメータを値「６」に設定することを希望し、一方で人間のオペレータが当該パラメータを値「０」に設定する。

次に、最初に図７に関して説明した放物線関数について、より詳細に説明する。放物線の標準的な定義では、焦点と呼ばれる所与の点と準線（平面上の対応する直線）とが必要とされる。焦点及び準線から等距離にある平面上の点の軌跡が、放物線として定義される。図７に基づいて、図１６は２つの放物線である放物線１ ６００及び放物線２ ６０２を識別している。

放物線１ ６００について、第１の観測される変動分２４４と許容可能なＤ２変動分２４２との和が、（０，Ｋ）にある。そして、交点６０４は、（０，２Ｅ Ｋ）にある。クライアントは、Ｄ２、Ｅ、Ｄ１、及びＸ軸の単位の観点での焦点半径６０６を、放物線１ ６００の定義を完全なものとするためにＭに提供し得る。クライアントは、Ｔ１ ２４６を提供しなくてよい（その値は、放物線１と軸Ｅ−Ｄ１との切片である）。放物線２ ６０２は、放物線１ ６００の鏡映（reflection）であり、放物線１ ６００及び放物線２ ６０２についての焦点半径は同一である。従って、クライアントは、１つの焦点半径のみを提供すればよい。

上の形式の放物型方程式は、Ｔ１ ２４６の初期において改善が大きいという自身の見込みをクライアントが表現することを可能とする。この形式を、“水平対称軸（horizontal axis of symmetry）”と呼ぶ。交点６０４及び焦点６０６は、水平線を形成する。

“垂直対称軸（vertical axis of symmetry）”と呼ばれる他の形式は、Ｔ１ ２４６の初期において改善が小さいという自身の見込みをクライアントが表現することを可能とする。垂直対称軸のそうした１つの例が図１７に示されている。

放物線３ ６０８について、同じサンプルを用いて、第１の観測される変動分２４４と許容可能なＤ２変動分２４２との和が、（０，Ｋ）にある。そして、交点６１２は、（０，２Ｅ−Ｋ）にある。クライアントは、Ｄ２、Ｅ、Ｄ１、及びＹ軸の単位の観点での焦点半径６１４をＭに提供する。クライアントは、Ｔ１ ２４６を提供しなくてよい（その値は、放物線３ ６０８と軸Ｅ−Ｄ１との切片である）。この形式では、交点６１２及び焦点６１４が垂直線を形成する。放物線４ ６１０は、放物線３ ６０８の鏡映であり、放物線３ ６０８及び放物線４ ６１０についての焦点半径は同一である。従って、クライアントは、１つの焦点半径６１４のみを提供すればよい。

図１８は、本発明の一実施形態を例示するフローチャートである。処理は、ステップ７００において、性能インジケータをモニタリングすることにより開始する。ステップ７００は、マネージャ又はクライアントからのリクエストの受信に応じて実行され得る。リクエストは、オプションとして、モニタリングのための特定のノード及び／又はパラメータを示すことができる。ステップ７１０において、第１の観測される性能インジケータ値が期待域の外側にあることが判定される。性能インジケータに関連付けられる値の期待域は、予め設定されてもよく、又はクライアントから受信されてもよい。

ステップ７２０において、上記性能インジケータについての受け入れ可能な値の収束域が定義される。受け入れ可能な収束域は、性能インジケータ値が期待域に復帰するための時間ピリオド、及び、当該時間ピリオドの期間中の第１の観測される性能インジケータ値からの許容可能な変動分に従って定義され得る。収束域は、線形関数として、又は放物線関数として定義され得る。受け入れ可能な収束域は、上記時間ピリオドの満了の後に上記性能インジケータに関連付けられる通常の期待域への収束がなされるように定義され得る。オプションとしての実施形態では、許容可能な変動分は、可変値として設定されることができ、上記時間ピリオドの持続期間を通じて減少させられ得る。

ステップ７３０において、第２の観測される性能インジケータ値が受け入れ可能な収束域の外側にあることが判定される。これは、第２のＰＩ値が第１のＰＩ値と許容可能な変動分との和よりも大きいと判定することを含んでもよい。また、これは、第２のＰＩ値が時間ピリオドの満了の後に性能インジケータに関連付けられる期待域の外側にあると判定することを含んでもよい。

第２のＰＩ値が定義される受け入れ可能な収束域の外側にあるという判定に応じて、ステップ７４０においてレポートが生成される。生成されたレポートは、クライアントへ送信され得る。

図１８には示されていないオプションとしての実施形態では、第３のＰＩ値が観測され得る。第３のＰＩ値が性能インジケータに関連付けられる期待域の内側にあるという判定に応じて、処理はステップ７００へ戻り、性能インジケータのモニタリングが継続される。また、処理は、第３のＰＩ値が定義される受け入れ可能な収束域の内側にあるという判定に応じてステップ７００へ戻り、性能インジケータのモニタリングを継続してもよい。

当業者は、モニタ部Ｍを、分散コンピューティングプラットフォームを含む汎用コンピュータのプラットフォーム上で実行される機能として提供し得ることを理解するであろう。モニタ部Ｍは、上で議論した機能群を実行するために使用可能な複数の機能エレメントを含んでよく、それは、値を測定し又は読み取るエレメント、読み取った値が境界の内側に入るのかを判定するエレメント、さらには境界を設定する機能エレメント及び読み取った値の関数として値を判定する機能エレメントを含む。上述した機能エレメントの動作に基づいてレポーティング機能エレメント及びアラート機能エレメントが起動され得る。当業者は、汎用のハードウェア上で実行されるソフトウェア、上記目的のために具体的に設計された特殊目的のハードウェア、ハードウェアにより実行されるファームウェア、及び上の任意のものの組合せ、を用いてこれら機能エレメントが実装され得ることを理解するであろう。

図１９は、例示的なモニタリングノード８００を示すブロック図である。モニタリングノード８００は、プロセッサあるいは処理エンジン８１０、メモリ８２０、及び通信インタフェース８３０を含む。ノード８００は、専用の基礎となるハードウェアを用いて実装されてもよく、その代わりに、仮想マシンとして実装されてもよい。ノード８００は、ここで説明されるような、受け入れ可能な運用のレンジの外側の構成パラメータ又は性能インジケータをレポートすることに関連する多様な実施形態を実行することができる。ノード８００は、それら動作を、メモリ８２０といったデータリポジトリ内に記憶される命令を処理エンジン８１０が実行することに応じて実行し得る。命令はソフトウェア命令であってよく、データリポジトリは任意の論理的な又は物理的なコンピュータ読取可能な媒体であってよい。ノード８００は、図１９では単一のエンティティとして示されているものの、地理的に分散される複数の異なるデバイスによって実装されてもよい。

通信インタフェース８３０は、少なくとも１つの外部ネットワークノード又はエレメントからＰＩ値を受信するように構成される。処理エンジン８１０は、受信されるＰＩ値をモニタリングし、それらを性能インジケータに関連付けられる期待される値と比較し、その比較に基づいて適切なアクションを取るように構成される。

処理エンジン８１０は、第１の観測されるＰＩ値が性能インジケータに関連付けられる値の期待域の外側にあることを判定する。性能インジケータについての値の期待域は、メモリ８２０内に記憶され得る。処理エンジン８１０は、性能インジケータについての値の受け入れ可能な収束域を定義する。受け入れ可能なレンジは、期待域へ復帰するための時間ピリオドと、第１の性能インジケータ値からの許容可能な変動分とに従って定義され得る。通信インタフェース８３０が後続の第２のＰＩ値を受信すると、処理エンジン８１０は、第２のＰＩ値が定義された受け入れ可能な収束域の外側にあるかを判定する。第２のＰＩ値が外側にある場合、処理エンジン８１０は、第２のＰＩ値が受け入れ可能なレンジから外れていることを示すレポートを送信するように通信インタフェース８３０に指示する。

処理エンジン８１０は、第２の性能インジケータ値が第１の性能インジケータ値及び許容可能な変動分の和よりも大きいと判定すること、又は第２の性能インジケータ値が時間ピリオドの満了の後に性能インジケータに関連付けられる期待域の外側にあると判定すること、のうちの１つに応じて、レポートを送信することを通信インタフェース８３０に指示し得る。

いくつかの実施形態において、メモリ８２０は、性能インジケータに関連付けられる値の期待域、及び定義される受け入れ可能な値の収束域を記憶し得る。また、メモリ８２０は、受信される第１の及び第２の性能インジケータ値を記憶するようにも構成され得る。

本発明の実施形態は、機械読取可能な媒体（具現化されるコンピュータ読取可能なプログラムコードを有する、コンピュータ読取可能な媒体、プロセッサ読取可能な媒体、又はコンピュータにより使用可能な媒体ともいう）に記憶されるソフトウェア製品として表現されてもよい。機械読取可能な媒体は、ディスケット、ＣＤ−ＲＯＭ（compact disk read only memory）、ＤＶＤ−ＲＯＭ（digital versatile disc read only memory）メモリデバイス（揮発性若しくは不揮発性）、又は同様の記憶メカニズムを含む、磁気的、光学的又は電気的な記憶媒体を含むいかなる適した有形の媒体であってもよい。機械読取可能な媒体には、実行された場合に本発明の一実施形態に係る方法内のステップ群をプロセッサに行わせる、命令、コードシーケンス、設定情報又は他のデータの様々なセットが格納され得る。当業者であれば、説明された発明を実装するために必要とされる他の命令及び動作が機械読取可能な媒体に記憶されてもよいことを理解するであろう。機械読取可能な媒体から実行されるソフトウェアは、説明されたタスクを実行するための回路とインタフェースされてもよい。

本発明の上述した実施形態は、単に例として意図される。ここに添付される特許請求の範囲によってのみ定義される本発明の範囲から外れることなく、当業者によって、変形例、修正例及びバリエーションが特定の実施形態に関してもたらされ得る。

Claims (16)

1. 自己組織化ネットワーク内のネットワークエレメントに関連付けられる性能インジケータがその通常の期待域に向けて収束していないことをレポートするための方法であって、
   性能インジケータをモニタリングすることと、
   プロセッサにより、第１の性能インジケータ値が前記性能インジケータに関連付けられる値の期待域の外側にあると判定することと、
   前記性能インジケータが値の前記期待域に復帰すべき時間ピリオド、及び前記第１の性能インジケータ値からの許容可能な変動分に従って、受け入れ可能な値の収束域を定義することと、
   第２の性能インジケータ値が定義された受け入れ可能な前記収束域の外側にあると判定することに応じて、レポートを生成することと、
   を含む方法。
2. 前記第２の性能インジケータ値が前記第１の性能インジケータ値と前記許容可能な変動分との和よりも大きいと判定すること、をさらに含む、請求項１の方法。
3. 前記時間ピリオドの満了の後に、前記第２の性能インジケータ値が前記性能インジケータに関連付けられる前記期待域の外側にあると判定すること、をさらに含む、請求項１の方法。
4. 第３の性能インジケータ値が前記性能インジケータに関連付けられる前記期待域の内側にあると判定することに応じて、前記性能インジケータのモニタリングを継続するステップ、をさらに含む、請求項１の方法。
5. 第３の性能インジケータ値が定義された受け入れ可能な前記収束域の内側にあると判定することに応じて、前記性能インジケータのモニタリングを継続するステップ、をさらに含む、請求項１の方法。
6. 前記許容可能な変動分は、可変値である、請求項１の方法。
7. 前記許容可能な変動分の値は、前記時間ピリオドにわたって減少させられる、請求項６の方法。
8. 前記時間ピリオドの満了の後に、定義された受け入れ可能な前記収束域は、前記性能インジケータに関連付けられる前記期待域へと収束する、請求項１の方法。
9. 前記モニタリングするステップは、モニタリング機能に関連付けられる通信インタフェースにより、前記第１の性能インジケータ値の測定結果を受信すること、を含む、請求項１の方法。
10. 第１の性能インジケータ値及び後続する第２の性能インジケータ値を受信するための通信インタフェースと、
    前記第１の性能インジケータ値が前記性能インジケータに関連付けられる値の期待域の外側にあると判定し、前記期待域に復帰するための時間ピリオド、及び前記第１の性能インジケータ値からの許容可能な変動分に従って、受け入れ可能な値の収束域を定義し、前記第２の性能インジケータ値が定義された受け入れ可能な前記収束域の外側にあると判定することに応じて、レポートを送信するように前記通信インタフェースへ指示する、ための処理エンジンと、
    を備えるモニタリングノード。
11. 前記処理エンジンは、前記第２の性能インジケータ値が前記第１の性能インジケータ値と前記許容可能な変動分との和よりも大きいと判定することに応じて、レポートを送信するように前記通信インタフェースに指示する、請求項１０のモニタリングノード。
12. 前記処理エンジンは、前記時間ピリオドの満了の後に、前記第２の性能インジケータ値が前記性能インジケータに関連付けられる前記期待域の外側にあると判定することに応じて、レポートを送信するように前記通信インタフェースに指示する、請求項１０のモニタリングノード。
13. 前記許容可能な変動分は、可変値である、請求項１０のモニタリングノード。
14. 前記許容可能な変動分の値は、前記時間ピリオドにわたって減少させられる、請求項１０のモニタリングノード。
15. 前記処理エンジンは、前記時間ピリオドの満了の後に、前記性能インジケータに関連付けられる前記期待域へと収束するように、受け入れ可能な前記収束域を定義する、請求項１０のモニタリングノード。
16. 前記性能インジケータに関連付けられる値の前記期待域と、定義される受け入れ可能な値の前記収束域と、を記憶するためのメモリ、をさらに備える、請求項１０のモニタリングノード。
    

Images