(57)【要約】  ネットワークパフォーマンスを最適化する方法を提供する。ネットワークは１個以上のネットワークノード（１）を備え、前記ネットワークノード（１）のパフォーマンスパラメータが専用の最適化モジュール（３）によって制御される。各最適化モジュール（３）は、該最適化モジュール（３）が関連づけられているネットワークノード（１）の少なくとも１つのパフォーマンスパラメータを監視し、所定のルールに基づいて前記パフォーマンスパラメータの現在値に対する変更要求を生成する。本方法は、前記ネットワークノード（１）の相異なる最適化モジュール（３）によって生成された前記変更要求が共通制御要素（２）へ転送され、該共通制御要素（２）が、設定可能なアルゴリズムに基づいて、受信した変更要求の調整を実施することを特徴とする。また、対応するシステムも開示される。
2010539760.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークパフォーマンスを最適化する方法において、
ネットワークは１個以上のネットワークノード（１）を備え、前記ネットワークノード（１）のパフォーマンスパラメータが専用の最適化モジュール（３）によって制御され、
各最適化モジュール（３）は、該最適化モジュール（３）が関連づけられているネットワークノード（１）の少なくとも１つのパフォーマンスパラメータを監視し、所定のルールに基づいて前記パフォーマンスパラメータの現在値に対する変更要求を生成し、
前記ネットワークノード（１）の相異なる最適化モジュール（３）によって生成された前記変更要求が共通制御要素（２）へ転送され、該共通制御要素（２）が、設定可能なアルゴリズムに基づいて、受信した変更要求の調整を実施することを特徴とする、ネットワークパフォーマンスを最適化する方法。
【請求項２】
前記制御要素（２）が、ネットワークノード（１）の相異なる最適化モジュール（３）から同時に受信される変更要求の衝突を解決することを特徴とする請求項１に記載の方法。
【請求項３】
相異なる最適化モジュール（３）間のトレードオフを規定する最適化目標が、前記制御要素（２）に渡され、調整プロセスにおいて考慮されることを特徴とする請求項１または２に記載の方法。
【請求項４】
前記制御要素（２）が、使用されるアルゴリズムに従って、最適化モジュール（３）から受信される変更要求の平均を生成することを特徴とする請求項１ないし３のいずれか１項に記載の方法。
【請求項５】
前記アルゴリズムが、変更要求の重み付けを実行するルーチンを含み、前記平均が、重み付けされた変更要求に基づいて生成されることを特徴とする請求項４に記載の方法。
【請求項６】
制御対象のパフォーマンスパラメータに対する費用関数が前記制御要素（２）に渡され、調整プロセスにおいて考慮されることを特徴とする請求項１ないし５のいずれか１項に記載の方法。
【請求項７】
１つ以上の前記最適化モジュール（３）から受信される変更要求が、前記制御要素（２）によって選択的に阻止されることを特徴とする請求項１ないし６のいずれか１項に記載の方法。
【請求項８】
前記制御要素（２）が、制御対象のパフォーマンスパラメータに対する新しい設定値を出力することを特徴とする請求項１ないし７のいずれか１項に記載の方法。
【請求項９】
前記制御要素（２）が、最適化モジュール（３）と、被制御ネットワークノード（１）のリソース（７）へのアクセスとの間に位置することを特徴とする請求項１ないし８のいずれか１項に記載の方法。
【請求項１０】
前記制御要素（２）の出力が、前記ネットワークノード（１）のリソース（７）における被制御パフォーマンスパラメータの値の更新を実行するために用いられることを特徴とする請求項１ないし９のいずれか１項に記載の方法。
【請求項１１】
前記制御要素（２）が、パフォーマンスパラメータの変更が実施されるタイミングを変更することを特徴とする請求項１ないし１０のいずれか１項に記載の方法。
【請求項１２】
関与するエンティティ間のインタラクションフローが、パフォーマンスパラメータおよび該パフォーマンスパラメータの設定値を含むタプルを用いることによって実行されることを特徴とする請求項１ないし１１のいずれか１項に記載の方法。
【請求項１３】
各変更要求が要求側の最適化モジュール（３）に関連づけられることを特徴とする請求項１ないし１２のいずれか１項に記載の方法。
【請求項１４】
変更要求を対応する要求側エンティティに関連づけることは、要求側の最適化モジュール（３）の名前によって、および／または要求側の最適化モジュール（３）に関連づけられた識別子によって、実行されることを特徴とする請求項１３に記載の方法。
【請求項１５】
制御されるパフォーマンスパラメータが、基地局のパイロットチャネルの電力、ハンドオーバーにおけるガードチャネルの帯域幅、および／またはネットワーク起因のハンドオーバーに対する受信信号しきい値を含むことを特徴とする請求項１ないし１４のいずれか１項に記載の方法。
【請求項１６】
ネットワークパフォーマンスを最適化するシステムにおいて、特に請求項１ないし１５のいずれか１項に記載の方法を実行するシステムにおいて、該システムは、ネットワークのネットワークノード（１）のパフォーマンスパラメータを制御する専用の最適化モジュール（３）を備え、各最適化モジュール（３）は、該最適化モジュール（３）が関連づけられているネットワークノード（１）の少なくとも１つのパフォーマンスパラメータを監視し、所定のルールに基づいて前記パフォーマンスパラメータの現在値に対する変更要求を生成するように構成され、
該システムが共通制御要素（２）をさらに備え、前記ネットワークノード（１）の相異なる最適化モジュール（３）によって生成された前記変更要求が該共通制御要素（２）へ転送され、該共通制御要素（２）が、設定可能なアルゴリズムに基づいて、受信した変更要求の調整を実施するように構成されることを特徴とする、ネットワークパフォーマンスを最適化するシステム。
【請求項１７】
前記制御要素（２）が、ネットワークノード（１）の相異なる最適化モジュール（３）から同時に受信される変更要求の衝突を解決するように構成されることを特徴とする請求項１６に記載のシステム。
【請求項１８】
前記制御要素（２）が、制御対象のパフォーマンスパラメータに対する費用関数を受信するように構成され、該費用関数が調整プロセスにおいて考慮されることを特徴とする請求項１６または１７に記載のシステム。
【請求項１９】
前記制御要素（２）が、１つ以上の前記最適化モジュール（３）から受信される変更要求を選択的に阻止することが可能とされることを特徴とする請求項１６ないし１８のいずれか１項に記載のシステム。
【請求項２０】
前記制御要素（２）が、変更要求に関して前記最適化モジュール（３）から受信される設定値を上書きすることが可能とされることを特徴とする請求項１６ないし１９のいずれか１項に記載のシステム。
【請求項２１】
前記制御要素（２）が、制御対象のパフォーマンスパラメータに対する新しい設定値を出力することを特徴とする請求項１６ないし２０のいずれか１項に記載のシステム。
【請求項２２】
前記制御要素（２）が、最適化モジュール（３）と、被制御ネットワークノード（１）のリソース（７）へのアクセスとの間に位置することを特徴とする請求項１６ないし２１のいずれか１項に記載のシステム。
【請求項２３】
前記制御要素（２）によって実行される調整プロセスの固有の制御点が設けられることを特徴とする請求項１６ないし２２のいずれか１項に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークパフォーマンスを最適化する方法に関する。ここで、ネットワークは１個以上のネットワークノードを備え、前記ネットワークノードのパフォーマンスパラメータが専用の最適化モジュールによって制御され、各最適化モジュールは、該最適化モジュールが関連づけられているネットワークノードの少なくとも１つのパフォーマンスパラメータを監視し、所定のルールに基づいて前記パフォーマンスパラメータの現在値に対する変更要求を生成する。
【０００２】
また、本発明は、ネットワークパフォーマンスを最適化するシステムに関する。該システムは、ネットワークのネットワークノードのパフォーマンスパラメータを制御する専用の最適化モジュールを備え、各最適化モジュールは、該最適化モジュールが関連づけられているネットワークノードの少なくとも１つのパフォーマンスパラメータを監視し、所定のルールに基づいて前記パフォーマンスパラメータの現在値に対する変更要求を生成するように構成される。
【背景技術】
【０００３】
ネットワークの保守は連続的なプロセスを伴い、パフォーマンスデータが分析され、設定パラメータが変更されて、ネットワークパフォーマンスが維持あるいは最適化される。これは通常、ネットワークの「最適化プロセス」と呼ばれる。
【０００４】
現在のネットワークにおける最適化プロセスは通常、非常に特殊化されている。すなわち、最適化モジュールと呼ばれ、特定のパフォーマンスパラメータを最適化することを委ねられた特定の機能モジュールが存在する。ブラックボックスとして見ると、最適化モジュールは、パフォーマンスデータを読み出し、ネットワークに対する新たな設定を生成する。決定は、ネットワーク管理者によって、および付加的な制約（「外形条件（contour condition）」）によって課された目標に基づく。このような最適化プロセスを図１に例示する。
【０００５】
ネットワークノード上で監視すべきパフォーマンスパラメータの一例として、平均負荷や、平均サービス要求拒否数（例えば、電話呼やネットワーク接続）が考えられる。後者の場合、サービス要求拒否数が連続的に監視され、その数があるしきい値を超えると（例えば１時間に１０回を超える要求拒否）、最適化プロセスが開始される。無線ネットワークの場合、基地局間の負荷の配分を調節するため、通常、基地局の「パイロットチャネル」の電力が調整される。すなわち、この電力が高いほど、カバーされるエリアが広くなり、その基地局によって受信される平均負荷が高くなる。したがって、所定の目標値に対して基地局の負荷が高すぎる場合、最適化プロセスは、外形条件に従いつつ（例えば、１つの条件として、フルカバレッジエリアを要求することが考えられる）、パイロットチャネルの電力を低下させようとする。
【０００６】
現在、運用中のネットワークにおいて、上記のような最適化プロセスは、中央管理ステーション上で実行される。中央管理ステーションは、被管理ネットワークノードへ新しい設定パラメータを送る。さらに、通常、最適化プロセスは、人間、例えばネットワーク管理者が設定値を送ることによって手動で実行される。上記の例に関していえば、アラームが管理者に報告された後にはじめて、基地局のパイロットチャネルの電力に対する値が手動で設定されるのが一般的である。例えば、負荷に対するある所定しきい値を超過した場合、アラームが管理ステーションに報告され、管理者は、パイロットチャネルの電力に対する新しい値を規定する責任を負う。この方法を、関連するデータフロートともに図２に例示する。この方法は、明らかに時間がかかり、誤りを起こしやすく、非効率的である。
【０００７】
しかし、スクリプトを用いることで、ある程度の自動化が採用されることがあり、これも図２に例示している。例として、スクリプトは、ネットワークノードのパフォーマンスパラメータ、例えば携帯電話通信ネットワークの基地局のパイロットチャネルの電力、の値を自動的に変更することができる。ただいずれにしても、これが適用されるのは通常、限られた場合だけである。というのは、このようなスクリプトの実行は、適切な設計と、専用の計算リソースを必要とするからである。さらに、スクリプトは単一の中央管理ステーション上で実行されるので、この自動化方法は、大規模なネットワークに拡張できない。
【０００８】
最近のネットワークアーキテクチャには、自己組織化原理をできるだけ利用しようとするものがある。最適化プロセスは、できるだけ自動化して、被管理ネットワークノードに委ね、別々のモジュール（例えば、特定の最適化アルゴリズムを実装したプログラム）がローカルに実行されて、多くのパラメータを変更する。各モジュールは特定の機能のために設計され、特定の領域の設定パラメータを制御することが期待される。ノードは、相互に情報やコマンドを交換することによって協働する。このようなアーキテクチャの利点として、スケーラビリティ、介入の即時性、および手動操作の必要性の低減がある。このような自己最適化ネットワークアーキテクチャの一例を図３に示す。
【０００９】
この手法の問題点の１つとして、同一ネットワークノード内、および異なるノード間での、異なる最適化プロセスの協調がある。自己最適化モジュールが独立に設計・実装されることが問題となる。結果として、各モジュールは、他のモジュールの機能の存在を知らない状態となる。これには、技術的および実用的の両方の理由がある。技術的には、独立型の最適化アルゴリズムおよびモジュールの設計のほうが、結合型の問題よりもはるかに容易である。実用的には、各モジュールは相異なる問題に対処するように設計されるので、相異なるモジュールが、製品開発の後期の統合段階で、さらに悪い場合にはネットワークの配備中に、組み合わされる。
【００１０】
進化型ＵＴＲＡＮにおける自己最適化ノードの使用例として、隣接セルの動作条件に応じたセルのセルカバレッジの適応がある。より詳細には、セルが動作していない場合、あるいは省エネルギーのために（例えば夜間）オフになっている場合に、その隣接セルが自己のカバレッジエリアを拡大して、以前のエリアにわたるフルカバレッジを維持すべきである。カバレッジエリアは、セルのパイロットチャネルの電力を変更することによって適応させる。問題となるのは、パイロットチャネルの電力は、負荷平準化メカニズムによっても制御されることである。２つの自己最適化メカニズムが同じパフォーマンスパラメータに同時並行的にアクセスすると、パラメータ変更頻度の上昇（例えば、パイロットチャネルの電力が毎分数回変化する）やパラメータの振動（例えば、パイロットチャネルの電力が高低２つの値の間で振動する）のような望ましくない影響が生じるおそれがある。
【００１１】
これらの問題を解決するため、各モジュール内に追加的なロジックを実装して他のモジュールとのインタラクションを協調させることがすでに提案されている。しかし、このような手法の欠点として、オペレータのポリシーを入力するための複数の接続点（point of attachment）が生じること、および、確実に複雑さが増大し、追加的なコストが発生することがある。さらに、この手法は、どの追加的モジュールについても一般的ではない。新しい最適化モジュールがネットワークエンティティに導入されて既存のモジュールと干渉する場合、新モジュールの干渉を考慮に入れて、既存のモジュールを再実装しなければならない。最終的に「重いモジュール」となり、各モジュールに必要な同期ロジックのコストは結局、導入した自動化の利益を相殺してしまいかねない。
【００１２】
要約すると、ローカルな自動化された最適化プロセスを備えた新しいアーキテクチャは、以下の３つの側面に関して、同時設定変更の問題を生じる。第１に、同じ設定パラメータに対する同時の変更要求が相異なるモジュールから到来する。例えば、負荷平準化モジュールおよびセル停止モジュールが、パイロットチャネルの電力を同時に変更する可能性がある。同時並行的なモジュールが逆の値を設定しようとする（例えば、一方のモジュールが値を増大させ、他方のモジュールが値を減少させる）場合に、問題は明白となる。第２に、同時変更要求が相異なるノードから到来する。そして第３に、同じ設定パラメータに対して変更要求が繰り返される。例えば、変更要求があまりに頻繁に発生し、一部の要求をフィルタリングしなければならないことがある。この効果は、相異なるモジュールが関与する際にさらに明瞭となる。これらの同時変更の副作用として、望ましくない設定（すなわち不適切な値）や、ノードの設定の望ましくない挙動（例えば、あまりに頻繁な変更）がある。
【発明の概要】
【発明が解決しようとする課題】
【００１３】
したがって、本発明の目的は、頭書のようなネットワークパフォーマンスを最適化する方法およびシステムにおいて、実施の容易な、しかもあまり追加的な複雑さを必要としないメカニズムを使用することにより、ネットワークノードの相異なる最適化モジュールの同時並行的な衝突する変更要求によって引き起こされるネットワークパフォーマンスに対する悪影響を大幅に低減するような改良を行うことである。
【課題を解決するための手段】
【００１４】
本発明によれば、上記の目的は、請求項１の構成を備えた方法によって達成される。この請求項に記載の通り、本方法は、前記ネットワークノードの相異なる最適化モジュールによって生成された前記変更要求が共通制御要素へ転送され、該共通制御要素が、設定可能なアルゴリズムに基づいて、受信した変更要求の調整を実施することを特徴とする。
【００１５】
また、上記の目的は、請求項１６の構成を備えたシステムによって達成される。この請求項に記載の通り、ネットワークパフォーマンスを最適化する本システムは、共通制御要素をさらに備え、前記ネットワークノードの相異なる最適化モジュールによって生成された前記変更要求が該共通制御要素へ転送され、該共通制御要素が、設定可能なアルゴリズムに基づいて、受信した変更要求の調整を実施するように構成されることを特徴とする。
【００１６】
本発明によって初めて認識されたことであるが、衝突する変更要求を解決するための追加的なロジックを各最適化モジュール内に実装することは、さまざまな側面で欠点があることがわかる。さらに認識されたこととして、ネットワークノードの個々の最適化モジュールとは別個に動作する追加的なエンティティを実装することによって、非常に効率的な調整プロセスが可能となる。この追加的エンティティは、ネットワークノードの相異なる最適化モジュールによって生成された変更要求が転送される共通の制御要素として実装される。これにより、制御要素は、最適化モジュールから見て中央エンティティを構成する。最適化モジュールから変更要求を受信すると、調整モジュールは、同時変更要求の調整を実施する。調整プロセスは、例えばネットワーク管理者が容易に実施することが可能な、設定可能なアルゴリズムに基づく。さらに、制御要素は相異なる最適化モジュール間で共通なので、自己最適化プロセスの完全なモジュール化が可能である。
【００１７】
好ましい実施形態によれば、制御要素は、ネットワークノードの相異なる最適化モジュールから同時に受信される変更要求の衝突を解決するように構成される。このために、相異なる最適化モジュール間のトレードオフを規定する最適化目標が、例えばネットワーク管理者によって提供されてもよい。このような最適化目標を、制御要素に渡し、調整プロセスにおいて考慮してもよい。
【００１８】
より詳細には、調整プロセスにおいて用いられる特定のアルゴリズムに従って、制御要素が、最適化モジュールから受信される変更要求の平均を生成してもよい。好ましい実施形態では、加重平均が計算される。各最適化モジュールに相異なる重みを対応させることによって、モジュール間目標、すなわち、最適化モジュールどうしの間の衝突する目標を考慮することができる。例えば、パイロットチャネル（例えば基地局の）の電力のパフォーマンスパラメータに対する同時変更目標の調整は、誤り制御を担当する最適化モジュールに高い重みを与え、負荷平準化処理を担当する最適化モジュールに低い重みを与え、最適化モジュールによって与えられる値をこれらの重み付きで平均することによって、実行してもよい。
【００１９】
別法として、あるいはこれに加えて、制御対象のパフォーマンスパラメータに対する費用関数を制御要素に渡し、調整プロセスにおいて考慮してもよい。「費用関数」という用語は、広義に理解すべきであり、ネットワークノードのリソースにおけるパフォーマンスパラメータの設定によって引き起こされる、ネットワークパフォーマンスに対する悪影響の評価を与えるものである。このような悪影響としては、サービス中断やＣＰＵパワーの消費が挙げられるが、これらには限定されない。調整プロセスにおいてこのような費用関数を考慮することにより、パフォーマンスパラメータの変更を（最適化目標だけを考慮する際には合理的かもしれないが）しないと決定する場合が起こり得る。というのは、このようなパフォーマンスパラメータ変更の悪影響が、そのパフォーマンスパラメータの変更から生じる利益を上回って相殺してしまう可能性があるからである。
【００２０】
さらに別の好ましい実施形態として、制御要素は、フィルタとして機能するように構成されてもよい。すなわち、１つ以上の最適化モジュールから受信される変更要求が、制御要素によって阻止されてもよい。有利な点として、阻止は、ネットワーク管理者によって指定されることが可能な個々の最適化モジュールによって選択的に実行されてもよい。例えば、ネットワークオペレータがポリシーを規定して、サービス要求拒否の回避が高い優先度で許可されるようにしている場合、このようなサービス要求拒否の監視を担当する最適化モジュールの変更要求のみが調整モジュールによって考慮され、当該ネットワークノードの他のすべての最適化モジュールからの変更要求は阻止してもよい。また、制御要素は、最適化モジュールによって要求される値を選択的に上書きするように構成されてもよい。
【００２１】
言うまでもなく、阻止機能は、最適化モジュールの変更要求の（加重）平均の生成と組み合わせてもよい。例えば、ある最適化モジュールが阻止される一方、平均値が他のモジュールに対して生成されてもよい。時々、例えば設定可能な長さの時間間隔において、阻止された最適化モジュールの現在の変更要求を、平均生成のために考慮してもよい。これにより、制御対象のパフォーマンスパラメータの値が、阻止された最適化モジュールが担当している最適化処理に関する範囲の外部に出ないようにすることができる。
【００２２】
制御対象のネットワークノードの最適化モジュールから受信される変更要求の調整を実行した後に、制御要素は、制御対象のパフォーマンスパラメータに対する新しい設定値を出力してもよい。有利な態様として、制御要素は、インタラクションフローに関して、最適化モジュールと、被制御ネットワークノードのリソースへのアクセスとの間に位置してもよい。「リソース」という用語は、ネットワークノードのパフォーマンスパラメータの完全なセットを指す。そして、制御要素の出力は、ネットワークノードのリソースにおける被制御パフォーマンスパラメータの値の更新を実行するために用いてもよい。
【００２３】
なお、調整モジュールの機能は、ある特定のパフォーマンスパラメータに対する新しい値の生成に限定されないことに注意すべきである。また、調整モジュールは、ネットワークノードのリソースにおいて変更が実施されるタイミングを変更することも可能である。例えば、パフォーマンスパラメータのあまりに頻繁な変更を避けるために、変更を時間的に遅延させてもよい。これは、構成要素の再設定がある一定の時間、例えば数秒ないし場合によっては数分、を要する際に重要な応用となる。このような場合、再設定の頻度を制限することが重要である。
【００２４】
インタラクションフローに関して、タプルを用いてもよい。タプルは、一方でパフォーマンスパラメータを含み、他方で該パフォーマンスパラメータの設定値を含む。これにより、非常にシンプルで扱いやすいインタラクションフローが実現される。変更要求を扱いやすくするため、各変更要求を要求側エンティティに関連づけてもよい。特に、変更要求を対応する要求側エンティティに関連づけることは、要求側エンティティの名前によって実行してもよい。また、要求側エンティティに関連づけられた識別子の使用も可能である。
【００２５】
有利な態様として、制御要素によって実行される調整プロセスには、固有の制御点が設けられる。すなわち、調整モジュールは、受信される変更要求の調整のために調整モジュールによって用いられるアルゴリズムを、例えばネットワーク管理者が設定できるようにする特定の入力インタフェースを備えてもよい。
【００２６】
なお、ネットワークノードのいかなるパフォーマンスパラメータも、上記のように最適化可能であることに注意すべきである。特に、ネットワークノードごとに複数のパフォーマンスパラメータが最適化可能であることに注目すべきである。このような場合、最適化すべき各パフォーマンスパラメータごとに別々の調整要素を設けてもよい。ネットワークノードの調整モジュールどうしの間の協働も可能である。ここでは、基地局のパイロットチャネルの電力を単に例示的に挙げたが、ハンドオーバーにおけるガードチャネルの帯域幅や、ネットワーク起因のハンドオーバーに対する受信信号しきい値を、パフォーマンスパラメータとして制御・最適化してもよい。
【００２７】
本発明を好適な態様で実施するにはいくつもの可能性がある。このためには、一方で請求項１および１６に従属する諸請求項を参照しつつ、他方で図面により例示された本発明の好ましい実施形態についての以下の説明を参照されたい。図面を用いて本発明の好ましい実施形態を説明する際には、本発明の教示による好ましい実施形態一般およびその変形例について説明する。
【図面の簡単な説明】
【００２８】
【図１】従来技術による最適化モジュールによって実行される最適化プロセスにおける情報フローの模式図である。
【図２】手動で、またはスクリプト支援で中央プロセスとして実行される従来技術による最適化プロセスの模式図である。
【図３】自己最適化ネットワークにおける従来技術による最適化プロセスを示す。
【図４】本発明によるネットワークパフォーマンスを最適化するシステムの実施形態を模式的に示す。
【図５】特定のパフォーマンスパラメータに対する２つの相異なる最適化モジュールからの同時変更要求において、本発明による方法を用いない例を示す図である。
【図６】特定のパフォーマンスパラメータに対する２つの相異なる最適化モジュールからの同時変更要求において、本発明による方法の実施形態を用いた例を示す図である。
【発明を実施するための形態】
【００２９】
図１は、従来技術において実行されるネットワークの最適化プロセスの原理を示す模式図である。例えばサービス拒否数や基地局のパイロットチャネルの電力等の特定のパフォーマンスパラメータを連続的に監視する最適化モジュールが設けられる。最適化プロセスにおいて、最適化モジュールは、ある特定の制約を含むいわゆる「外形条件（contour condition）」を考慮する。このような外形条件は、例えば、フルカバレッジエリアを要求することが考えられる。また、最適化プロセスは、例えばネットワーク管理者によって課される目標に基づく。最適化モジュールは、制御対象のパフォーマンスパラメータに対する新しい設定値を出力する。これは、一般には、変更要求の形で出力される。
【００３０】
図２は、図１に関して説明した最適化プロセスを実行するために運用中のネットワークで用いられるアーキテクチャを例示している。最適化モジュールは、監視対象のネットワークノードからパフォーマンスデータを読み出す中央管理ステーション上に実装される。これは実線矢印で示されている。今日、変更要求は、監視結果に基づいてネットワーク管理者によって手動で生成されることが非常に一般的である。また、従来技術においては、特定のパフォーマンスパラメータの値を自動的に変更することができるスクリプトを用いることによって、ある程度の自動化を導入することも知られている。最適化プロセスの結果として生じる設定変更は、中央管理ステーションから個々のノードへ送信される。これは点線矢印で示されている。
【００３１】
図３は、自己最適化ネットワークの場合を例示している。このネットワークアーキテクチャにおいて、最適化プロセスは大幅に自動化され、被管理ネットワークノードに委ねられている。図３から分かるように、相異なる最適化モジュール（例えばスクリプト）が、被監視ネットワークノード（そのうちの２つを例として図示）上でローカルに実行されて、多数のパフォーマンスパラメータを変更する。各最適化モジュールは、特定の機能のために設計され、特定の領域の設定パラメータを制御する。
【００３２】
図３に示した例において、右側のネットワークノードは基地局であり、その基地局に関連づけられた３つの自己最適化モジュールが、基地局のパイロットチャネルの電力を制御することを担当している。「設定例」と題する小さいダイヤグラムは、個々の最適化モジュールの変更要求を示す。具体的には、パイロットチャネルの電力を時間の関数として図示している。相異なるモジュールの変更要求が、被監視ネットワークノードのリソースへ転送される。これもまた点線矢印で示されている。従来技術によれば、相異なるモジュールの変更要求は個別に処理される。その結果、パイロットチャネルの電力は頻繁な変更を受ける。これは、リソースに関連づけられた小さいダイヤグラム「設定例」に示されている。このダイヤグラムにおいて、パイロットチャネルの電力は時間に関して強く振動している。
【００３３】
図４は、本発明によるシステムの実施形態を例示している。明確にするため、ネットワークノード１は１つだけ示している。本発明によれば、調整モジュール２が設けられ、ネットワークノード１の最適化モジュール３によって生成される変更要求が調整モジュール２へ転送される。調整モジュール２は、特定の入力インタフェース４を備え、これにより、受信される変更要求を調整モジュール２が処理するために用いるアルゴリズムの設定が可能となる。こうして、例えばネットワークオペレータ５に対して、調整プロセスの固有の制御点が与えられる。入力インタフェース４を通じて、費用関数を規定し、モジュール間目標を指定し、ある特定の変更要求を阻止するためのフィルタを入力することが可能である。
【００３４】
すでに上記で述べたように、調整モジュール２は、相異なる最適化モジュール３から変更要求を受信し、指定されたアルゴリズムに従ってそれらを処理する。例えば、調整モジュール２は、同時変更要求の衝突を解決し、モジュール間最適化目標を課することが可能である。最適化プロセスの結果として、調整モジュール２は、制御対象のパフォーマンスパラメータに対する新しい設定値を出力する。この新しい設定値は、調整モジュールの特定の出力インタフェース６を通じて提供される。
【００３５】
インタラクションフローにおいて、調整モジュール２は、最適化モジュール３と、被管理ネットワークノード１の被制御リソース７へのアクセスとの間に位置する。パフォーマンスパラメータの新しい設定値は、点線矢印で示すようにリソース７へ転送され、対応する変更が実行される。
【００３６】
なお、図４には最適化モジュール３が調整モジュール２とともにローカルに、すなわち被管理ネットワークノード１内に実装されているように示されているが、これらのモジュールは中央管理ステーションに実装されてもよいことに注意すべきである。この場合、最適化アルゴリズムは、通常、ローカルリソースに対して適用されるのではなく、被管理ネットワークノード上に位置するリモートリソースに対して適用されることになる。
【００３７】
中央および右側の最適化モジュール２に対しても、「設定例」と題するダイヤグラムが図示されている。これらにおいても、パイロットチャネルの電力を時間の関数として示している。関数は、図３に示したものと同一である。しかし、それらの結果として得られる関数、すなわち調整プロセスの実行後の関数は、図３において結果として得られる関数よりもはるかに滑らかである。その結果、パフォーマンスパラメータの変更を実行する必要が少なくなり、最適化されたネットワークパフォーマンスが得られる。というのは、さもなければ実際には、ネットワークノード１のリソース７における変更の実行は、常にサービス中断等の悪影響を伴うからである。
【００３８】
この側面は、図５および図６に示す図によってさらに明らかとなる。これらの図は、２０秒間にわたるパイロットチャネルの電力に対する変更要求を例示している。縦軸の電力は任意単位、例えばｄＢｍあるいはワットで表している。実線の棒線は、誤り制御を担当する最適化モジュールによって生成された変更要求を表す。他方、破線の棒線は、負荷平準化処理を担当する最適化モジュールによって生成された変更要求を表す。
【００３９】
図５は、本発明を適用しない場合を示している。２つの最適化モジュールのうちの１つによって生成される各変更要求が、被管理ネットワークノードのリソースへ転送され、パフォーマンスパラメータのそれぞれの変更が実行されている。
【００４０】
他方、図６は、本発明を適用した場合、すなわち、調整モジュールが設けられ、２つの最適化モジュールの変更要求が調整モジュールへ転送され、指定されたアルゴリズムに従って調整モジュールが同時変更要求を処理する場合を示している。図６に示す実施形態では、単純な加重平均を用いて、制御対象のパフォーマンスパラメータに対する一連の新しい値を生成している。具体的には、各最適化モジュールに、それらの目標に従って、相異なる重みを割り当てる。この例では、パイロットチャネルの電力に対する同時変更要求の調整は、「誤り制御」モジュールに高い重みを与え、「負荷平準化」モジュールに低い重みを与えることによって達成される。これらの値は平均される。図６は、例示した２０秒の時間間隔内のすべての変更要求にわたってとった平均値を示している。見てとれるように、出力平均値は、「誤り制御」モジュールによって生成される値のほうに近い。というのは、こちらのほうが重みが高いからである。
【００４１】
図６では、平均ウィンドウによって必然的に導入される遅延を示していないが、これは重要な点である。というのは、調整モジュールの効果は、新しい値の生成に限定されないからである。実際、調整モジュールは、変更が実施されるタイミングも変更することができる。例えば、パフォーマンスパラメータのあまりに頻繁な変更を避けるために、変更を時間的に遅延させてもよい。これは、構成要素の再設定がある一定の時間、例えば数秒ないし場合によっては数分、を要する際に重要な応用となる。このような場合、再設定の頻度を制限することが重要である。
【００４２】
上記の説明および添付図面の記載に基づいて、当業者は本発明の多くの変形例および他の実施形態に想到し得るであろう。したがって、本発明は、開示した具体的実施形態に限定されるものではなく、変形例および他の実施形態も、添付の特許請求の範囲内に含まれるものと理解すべきである。本明細書では特定の用語を用いているが、それらは総称的・説明的意味でのみ用いられており、限定を目的としたものではない。
【図１】
2010539760.tif 000003
【図２】
2010539760.tif 000004
【図３】
2010539760.tif 000005
【図４】
2010539760.tif 000006
【図５】
2010539760.tif 000007
【図６】
2010539760.tif 000008
【国際調査報告】
2010539760.tif 000009
2010539760.tif 000010