(57)【要約】トラヒックネットワーク（１０）において、ネットワーク管理タスクをソースから複数のネットワークノードに分散するためのシステム、方法、およびネットワークノード（１４）。あるネットワークノード（１４）においてタスクが受信されると、ノードは、タスクが他のネットワークノードへ転送すべきかどうかを判定する。転送すべきであれば、受信側ネットワークノードは、各隣接ノードの機能性についてのアプリケーションレベルの知識情報を利用して、タスクを受信する必要がある１つ以上の隣接ノードを選択する。次いで、受信側ネットワークノードは、データ探索および分配（Ｄ３）レイヤとして知られる機能的管理オーバーレイレイヤ(１２)を利用して、選択された隣接ノードへタスクを通信により伝達する。ネットワークノードは、隣接ノードから応答を受信し、ローカル情報を使ってその応答を集約し、そして、集約された応答をソースへ送信する。
2010521093.tif 000002
【特許請求の範囲】
【請求項１】
アプリケーションレイヤ（１３）と機能管理オーバーレイレイヤ（１２）とを備えたトラフィックを転送するネットワーク（１０）において、ソースから複数のネットワークノード（１４）へネットワーク管理タスクを分配する方法であって、
ネットワークノード（１４）において前記ネットワーク管理タスクを受信するステップ（２１）と、
前記ネットワーク管理タスクによって必要とされるいずれかのローカルタスクを受信側の前記ネットワークノードにおいて実行するステップ（２２）と、
前記受信側のネットワークノードが少なくとも１つの隣接ノードを有している場合に、前記隣接ノードの機能に関するアプリケーションレイヤ情報を利用して、前記隣接ノードのいずれかが前記ネットワーク管理タスクを受信する必要があるかどうかを前記受信側のネットワークノードによって判定するステップ（２３）と、
前記隣接ノードのいずれかが前記ネットワーク管理タスクを受信する必要があると判定されると、前記機能管理オーバーレイレイヤ（１２）を利用して前記受信側のネットワークノードから前記隣接ノードへ前記ネットワーク管理タスクを分配するステップ（２４）と
を備えることを特徴とする方法。
【請求項２】
前記ネットワークノードは複数の隣接ノードへ前記ネットワーク管理タスクを分配するネットワークノードであり、
前記方法は、さらに、
前記複数の隣接ノードからの応答を前記ネットワークノードにおいて受信するステップと、
前記複数の隣接ノードから受信した複数の応答を集約して集約応答を作成するステップ（２５）と、
前記集約応答を前記ソースへ送信するステップ（２６）と
を備えることを特徴とする請求項１に記載の方法。
【請求項３】
前記複数のネットワークノードのそれぞれにおける前記機能管理オーバーレイレイヤのテーブルに複数の隣接ノードについてのネットワーク管理情報を記憶するステップ
をさらに備え、
前記ネットワーク管理情報は、前記複数のネットワークノードに複数のネットワーク管理タスクをルーティングさせることを可能ならしめる情報であることを特徴とする請求項１に記載の方法。
【請求項４】
前記ネットワークにおける構成の変化が発生したときに、前記複数のネットワークノードのそれぞれにおける前記機能管理オーバーレイレイヤのテーブルに記憶されている前記ネットワーク管理情報を更新するステップ
をさらに備えることを特徴とする請求項３に記載の方法。
【請求項５】
前記複数のネットワークノードから前記機能管理オーバーレイレイヤにおける複数の情報テーブルへのマッピングを提供することで、複数のオーバーレイレイヤを提供するステップ
をさらに備えることを特徴とする請求項３に記載の方法。
【請求項６】
前記ネットワーク管理タスクを受信した隣接ノードによって、該ネットワーク管理タスクを該隣接ノードによって実行すべきかどうかを判定するステップと、
前記ネットワーク管理タスクを前記隣接ノードによって実行すべきと判定すると、該ネットワーク管理タスクを該隣接ノードが備えるアプリケーションレイヤに送信するステップと
をさらに備えることを特徴とする請求項１に記載の方法。
【請求項７】
トラフィックを転送するネットワーク（１０）において、ソースから複数のネットワークノード（１４）へネットワーク管理タスクを分配するシステムであって、
前記ネットワーク管理タスクを受信する前記複数のネットワークノードのそれぞれに備えられ、前記ネットワーク管理タスクによって必要とされるいずれかのローカルタスクを実行する手段（１８）と、
前記ネットワーク管理タスクを受信する前記複数のネットワークノードのそれぞれに備えられ、前記ネットワークノードが少なくとも１つの隣接ノードを有している場合に、前記隣接ノードの機能に関するアプリケーションレイヤ情報を利用して、前記隣接ノードのいずれかが前記ネットワーク管理タスクを受信する必要があるかどうかを判定する手段（１６）と、
前記複数のネットワークノードのそれぞれと、該ネットワークノードの隣接ノードとの間で直接的に通信するための機能管理オーバーレイレイヤ（１２）と、
前記ネットワークノードにおいて前記機能管理オーバーレイレイヤ（１２）を利用して、該ネットワークノードから前記ネットワーク管理タスクを受信する必要がある前記隣接ノードへ、前記ネットワーク管理タスクを分配する手段（１７）と
を備えることを特徴とするシステム。
【請求項８】
前記ネットワークノードは複数の隣接ノードへ前記ネットワーク管理タスクを分配するネットワークノードであり、
前記システムは、さらに、
前記複数の隣接ノードのうち選択された複数の隣接ノードから送信されてきた複数の応答メッセージを前記ネットワークノードにおいて受信する手段と、
前記複数の隣接ノードから受信した前記複数の応答メッセージを集約して集約応答メッセージを作成する手段と、
前記集約応答メッセージを前記ソースへ送信する手段と
を備えることを特徴とする請求項７に記載のシステム。
【請求項９】
前記機能管理オーバーレイレイヤは分散化ハッシュテーブル（ＤＨＴ）を利用して実装されており、
前記アプリケーションレイヤ情報を利用して、前記隣接ノードのいずれかが前記ネットワーク管理タスクを受信する必要があるかどうかを判定する前記手段は、前記ネットワーク管理タスクの転送先となるべき少なくとも１つの隣接ノードを選択する手段を備え、
選択される前記隣接ノードは、前記ネットワーク管理タスクを最終的に受信するネットワークノードの１つ手前に位置している隣接ノードであることを特徴とする請求項７に記載のシステム。
【請求項１０】
前記ネットワーク管理タスクを受信する前記隣接ノードに備えられ、前記ネットワーク管理タスクを該隣接ノードにおいて実行すべきかどうかを判定する手段と、
前記ネットワーク管理タスクを該隣接ノードにおいて実行すべきと判定したことに応じて、該隣接ノードが備えるアプリケーションレイヤへ該ネットワーク管理タスクを送信する手段と
をさらに備えることを特徴とする請求項７に記載のシステム。
【請求項１１】
前記ネットワーク管理タスクを受信するネットワークノードと少なくとも１つの隣接ノードとが共に単一の物理ノード装置内に設けられていることを特徴とする請求項７に記載のシステム。
【請求項１２】
トラフィックを転送するネットワーク（１０）において複数の隣接ノードへネットワーク管理タスクを分配するネットワークノード（１４）であって、
前記ネットワークノードがいずれかの隣接ノードを有している場合に、前記隣接ノードの機能を示すアプリケーションレイヤ知識情報を利用して、前記ネットワーク管理タスクを受信すべき少なくとも１つの隣接ノードを選択する選択手段（１６）と、
前記ネットワーク管理タスクを探索して転送する中央のノードを使用することなく、前記ネットワークノードに隣接した前記隣接ノードと該ネットワークノードとの間でノード・ノード間通信を提供する機能管理オーバーレイレイヤ（１２）を利用する選択された前記少なくとも１つの隣接ノードへ前記ネットワーク管理タスクを分配する分配手段（１７）と
を備えることを特徴とするネットワークノード。
【請求項１３】
前記機能管理オーバーレイレイヤは分散化ハッシュテーブル（ＤＨＴ）を利用して実装されており、
前記選択手段は、前記ネットワーク管理タスクの転送先となるべき少なくとも１つの隣接ノードを選択する手段を備え、
選択される前記隣接ノードは、前記ネットワーク管理タスクを最終的に受信するネットワークノードの１つ手前に位置している隣接ノードであることを特徴とする請求項１２に記載のネットワークノード。
【請求項１４】
前記ネットワークノードは、選択された前記隣接ノードへ前記ネットワーク管理タスクを通信により伝達し、
前記ネットワークノードは、
前記複数の隣接ノードのうち選択された複数の隣接ノードから送信されてきた複数の応答メッセージを前記ネットワークノードにおいて受信する手段と、
前記複数の隣接ノードから受信した前記複数の応答メッセージを集約して集約応答メッセージを作成する手段と
をさらに備えることを特徴とする請求項１２に記載のネットワークノード。
【請求項１５】
前記ネットワークノードと少なくとも１つの隣接ノードとが共に単一の物理ノード装置内に設けられていることを特徴とする請求項１２に記載のネットワークノード。
【請求項１６】
発信側のノードから受信したネットワーク管理要求に応答して送信されるネットワーク管理情報であって、トラフィックを転送するネットワーク（１０）において複数の隣接ノードからの該ネットワーク管理情報を収集するネットワークノード（１４）であって、
前記ネットワーク管理要求に対して応答するために、ローカルの管理情報を決定する手段（１５）と、
前記複数の隣接ノードのそれぞれについての機能を示すアプリケーションレイヤ知識情報を利用して、リモートの管理情報が記憶配置されている隣接ノードを特定する手段（１６）と、
機能管理オーバーレイレイヤを利用して、特定された前記隣接ノードに対して前記リモートの管理情報を要求するための要求メッセージを送信する手段（１７）と、
前記特定された隣接ノードからの応答メッセージに含まれていた前記リモートの管理情報を受信する手段（１８）と、
前記リモートの管理情報と前記ローカルの管理情報とを集約して集約管理情報を作成し、該集約管理情報を前記発信側のノードへ送信する手段（１９）と
を備えることを特徴とするネットワークノード。
【請求項１７】
前記ネットワークノードと特定された前記少なくとも１つの隣接ノードとが共に単一の物理ノード装置内に設けられていることを特徴とする請求項１６に記載のネットワークノード。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信ネットワークにおけるネットワーク管理アクティビティに関する。詳細には、そして限定を目的とするのではなく、本発明は、ネットワーク管理タスクを、大規模で複雑で動的な通信ネットワーク群の中のネットワークノード群に分散して割り当て、この分散割り当て（分配）手法によってネットワーク管理タスクを解決するシステムおよび方法に関する。
【背景技術】
【０００２】
通信ネットワークにおいて現在利用されている管理アーキテクチャは、ＩＴＵ−Ｍシリーズの標準によって定められたアーキテクチャに基づいている。ネットワーク管理の分野において、影響力のあるこの標準化作業は、単純なクライアント・サーバ・アーキテクチャを根本としていた。標準規格書における説明では、これは「エージェント−マネージャ」関係と呼ばれている。この場合、「エージェント」は、管理対象となっているネットワーク機器上に常駐し、「マネージャ」は、管理情報の検索と設定タスクの調整とについてエージェントと対話する中央エンティティである。これは、現行の第３世代（３Ｇ）ネットワーク管理システム（ＮＭＳ）のソリューションが基礎としているパラダイムと基本的に同じパラダイムである。このアーキテクチャは、管理対象のデバイスからデータを収集し、データを集約し、そして状態情報をデバイス上に設定することに責任を持つ、中央要素すなわちサーバを利用する。このサーバの中で実現される機能性は、典型的には、ＩＴＵ−ＴによってＸ．７００仕様書群の中で定義されるＦＣＡＰＳ機能分類に従って分類される。
【０００３】
通信ネットワークの規模はますます拡大して複雑さも高まり続けており、その結果、個々のノードがオンライン化されたりオフライン化されたり、リンクが故障したり修復されたりするようなダイナミクス（動的な変化）が増加している。これらの要因は、現行の集中的ＮＭＳアーキテクチャに多数の難問をもたらす。これらの難問にある程度対応するため、ネットワーク管理システムの利用可能性、性能特性、スケーラビリティ、正確さの保証を強化する目的で、ネットワーク管理タスクが、ネットワークノード群およびその他のネットワークエンティティ自体に分散されてきている。
【０００４】
ネットワークの中央にルックアップテーブルを配置することなく情報を見つけることができるようにするのは、難しいタスクである。分散方式においてノードやデータが探索発見できるようにする１つの技術として、分散化ハッシュテーブル（ＤＨＴ）がある。ＤＨＴ（例えばＣｈｏｒｄ、Ｐａｓｔｒｙ、Ｔａｐｅｓｔｒｙ、ＣＡＮ、Ｂａｍｂｏｏ、Ｋａｄｅｍｌｉａ、Ｃｏｒａｌ、Ｖｉｃｅｒｏｙ）は、データを消費／提供することや分散されたタスクを解決することにすべてのノードが同等に参加するといった、いわゆるピアーツーピアシステムの構造を持つ。ＤＨＴは、物理ネットワークの上部にある論理的オーバーレイとして構築され、非常に正確なネーミングスキームに依存したルーティングメカニズムを提供する。結果として、数百万のピアノードへのスケーラビリティ、効率的なルックアップアルゴリズム、ロバスト性、ノード到着／出発の際の自動再構成、そして管理や配置の容易さなど、多くの利点をもたらす十分に分散されたシステムが完成する。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
本質的に、すべてのＤＨＴは同じ機能性（すなわち、ピア／データの位置）を提供するが、例えばルーティングする隣接先の数や、反復ルックアップか再帰的ルックアップかの選択や、ルーティングテーブル作成アルゴリズムの選択や、隣接先選択ストラテジーなどの特性については、若干差がある。また、時が経つにつれて異なるＤＨＴが同じストラテジーの方向へと進化してきており、既存のＤＨＴについての研究から生まれた最適な選択手法を実装している。このために、現行のＤＨＴの大半は、ネットワーク内のノードの数をＮとすると、ローカル情報がＯ（ｌｏｇ  Ｎ）の各ノードに記憶された状態で、いかなるノードであっても、Ｏ（ｌｏｇ  Ｎ）というオーバーレイホップの平均数で探索発見できることを保証しており、このようにして、この解決策のスケーラビリティを保証している。
【０００６】
しかし、ＤＨＴには、不利な点もいくつかある。ＤＨＴの不利な点は主として、物理的ネットワークノード群とオーバーレイとの間のマッピングが、マッピングされるノード群のいかなる機能性とも通常は無関係であるという事実にある。従って、管理タスクが分散される場合に非効率性が生じる。
【０００７】
ネットワーク管理タスクを分散するという状況において、アプリケーションレベルでは通常、各ネットワークノードが、割り当てられたタスクのうちの自分の部分を完成させるためにコンタクトをとるであろう、一定数の「隣接先」を識別できることが必要である。この隣接先のセットは、解決されることになるタスクに左右される。例えば、ＷＣＤＭＡを利用する無線ネットワークにおいて無線ネットワーク制御装置（ＲＮＣ）内における隣接した複数のセル間における諸関係の整合性を検証することがタスクである場合、各無線ネットワーク制御装置（ＲＮＣ）は、自分のセル群が隣接関係を持つような他のＲＮＣとのコンタクトを開始し、そして、セルの隣接関係がその隣接先の側でも対称的に定義されているかどうか判定するよう、他のＲＮＣに要求しなければならない。
【０００８】
一般に、管理対象のネットワーク内に存在するデータ（例えば複数のネットワークノード間の関係を示すデータ）は、通常、分散されたタスクに参加すべきすべてのノードへコンタクトが行われるまで１つのネットワーク要素から別のネットワーク要素へと処理要求を伝達するために、アプリケーションレベルで用いることができる有向グラフを定義する。このグラフが強連結している（すなわち、グラフ内の任意の２つのノード間に有向パスが存在する）場合には、任意のネットワークノードから発信された要求は、（ノードの探索発見とアドレス指定とを可能にする、何らかの基礎を成すレイヤを前提とすると）最後にはすべての他のネットワークノードに伝達されるであろう。
【０００９】
現行の中央集中的なネットワークマネージメント（ＮＭ）システムにおいては、管理タスクを処理する場合、管理している中央ノードによるネットワークのビューが用いられる。規模と複雑度とダイナミクスが拡大したネットワークという状況において、ネットワーク管理タスクの分散処理を求める要求がすべてのノードに達したかどうかを決定するために中央のナレッジ（知識情報）を用いることは、スケーラビリティ、性能、利用可能性、および整合性を確実に保証するとはいえない。
【００１０】
スケーラビリティに関しては、現行の解決策には、管理されるノードの数の増加を処理するという問題がある。管理されることになるデバイス／ネットワーク要素の数に比例して、管理されることになるデータ量も相応に増加するわけだから、データの収集、集約および相関のプロセスも非常に複雑になる。性能および利用可能性に関しては、現行の解決策における１対ｎ（１つのマネージャに対して多くのエージェント）の関係は、マネージャに不具合が発生した場合に問題を引き起こす。同様に、中央ノードは、ノード群からデータを収集し、収集したデータを処理することで過負荷状態となる可能性がある。もっと極端な事例として、管理タスクがネットワーク全体に関連する場合、例えば共有された状態情報（セルのパラメータ）が存在する場合にあるプロパティがネットワーク内のすべてのノード全体について正しいかどうかを判定する場合には、この作業負荷を１つの中心的な場所で効率よく処理するのは、困難となりうる。
【００１１】
最後に、現行の解決策には、中央管理ノードによって収集されたデータの整合性を維持しなければならないという問題がある。例えば、セル設計を支援するためネットワークから検索して抽出された情報のスナップショットまたはコピーについて作業する場合、中央ノードは、実データのローカルなコピーに関してすべてのデータ処理を行う。大規模な分散システムでは、管理されるノード上のデータとＯＳＳノード上のデータとの間の厳密な整合性を保証することは、極めて難しいかもしくは不可能である。
【００１２】
上記の諸問題は、ネットワークが進化し、管理対象のエンティティの量が、ますます拡大するにつれて、深刻かつ複雑な難問を提起する。当技術分野において必要なのは、もっと実行可能なネットワーク管理アーキテクチャと、上記で概説した争点に関連する諸問題を多少とも解決するために役立つ方法とである。そのようなアーキテクチャは、ネットワーク管理タスクを効率よくネットワーク全域のノード群に分散することを可能にし、また、アーキテクチャグラフの変更に容易に対応できるようにすべきである。本発明は、そのようなアーキテクチャおよび方法を提供する。
【課題を解決するための手段】
【００１３】
本発明は、電気通信ネットワークまたは同様のネットワークにおける複数のノード間の直接通信を可能にして、管理対象のネットワーク自身の範囲内でネットワーク管理タスクを分散して分配することができるようにする。本発明は、トラヒックネットワークからの意味情報を利用してＤａｔａ  Ｄｉｓｔｒｉｂｕｔｉｏｎ  ａｎｄ  Ｄｉｓｃｏｖｅｒｙ（Ｄ３）レイヤを構築し、動的に接続関係が変化しうる状況を効率よく処理して多様な管理タスクについての複数のオーバーレイを維持することによって、先行技術の不利な点を克服する。従って、本発明は、（オーバーレイＩＤを構築するためにハッシュされた情報の中で）マッピングを構築する場合に、機能的情報を利用し、そして、多様なネットワーク管理機能性を提供するために１対ｎマッピングを構築する。ネットワークノード群は、ネットワーク管理リクエスト（要求）に応じて協働してもよく、そのようにしてネットワーク管理負荷をネットワーク内における複数のノード間でバランスさせ、ネットワーク管理の解決策のスケーラビリティを高め、および／または、現行のネットワーク管理手法においてこれまでそうであったように中央ノード上でキャッシュされた、期限切れの恐れのあるコピー群ではなく、ノード上の実データを用いることになる。
【００１４】
一態様において、本発明は、ネットワーク管理タスクをソース（発信元）からアプリケーションレイヤおよび機能的管理オーバーレイレイヤを有するトラヒックネットワーク内の複数のネットワークノードに分散するための方法を対象とする。本方法には、ネットワークノード内でネットワーク管理タスクを受信するステップと、隣接ノード群の機能性に関するアプリケーションレイヤ情報を利用して、ネットワーク管理タスクを受信する必要がある少なくとも１つの隣接ノードを受信側ネットワークノードが選択するステップと、そして、機能的管理オーバーレイレイヤを利用して、ネットワーク管理タスクを受信側ネットワークノードから少なくとも１つの選択された隣接ノードに分散するステップとが含まれる。次いで、受信側ネットワークノードは、隣接ノード群から応答を受信し、応答を集約し、そして集約された応答をソースへ送信する。
【００１５】
別の態様において、本発明は、ネットワーク管理タスクをソースからトラヒックネットワーク内の複数のネットワークノードに分散するためのシステムを対象とする。システムには、ネットワーク管理タスクを受信する目的で少なくとも１つの隣接ノードを選択するための、各ネットワークノード内の手段が含まれる。ネットワークノードは、各隣接ノードの機能性に関するアプリケーションレイヤの知識を利用して、ネットワーク管理タスクを受信する必要がある隣接ノード群だけを選択する。また、システムには、各ネットワークノードとそのノードの隣接ノード群との間で直接通信するための機能的管理オーバーレイレイヤが含まれ、そして、その機能的管理オーバーレイレイヤを利用してネットワーク管理タスクをネットワークノードから少なくとも１つの選択された隣接ノードに分散するための各ネットワークノード内の手段も含まれる。次いで、ネットワークノードは、隣接ノードから応答を受信し、応答を集約し、そして集約された応答をソースへ送信する。
【００１６】
別の態様において、本発明は、ネットワーク管理タスクをトラヒックネットワーク内の複数の隣接ノードに分散するためのネットワークノードを対象とする。ネットワークノードには、ネットワークノードが各隣接ノードの機能性に関するアプリケーションレイヤの知識を利用して、ネットワーク管理タスクを受信する必要がある隣接ノード群だけを選択することを特徴とする、ネットワーク管理タスクを受信する目的で少なくとも１つの隣接ノードを選択するための手段と、各ネットワークノードとそのノードの隣接ノード群との間に直接通信を提供する機能的管理オーバーレイレイヤを利用して、タスクを少なくとも１つの選択された隣接するノード分散するための手段とが含まれる。
【００１７】
別の態様において、本発明は、発信側ノードから受信したネットワーク管理要求に応じてネットワーク管理情報をトラヒックネットワーク内の複数の隣接ノードから収集するためのネットワークノードを対象とする。ネットワークノードには、要求に応答するために必要なローカル管理情報を判定して、リモート情報を要求するための手段と、各隣接ノードの機能性に関するアプリケーションレイヤの知識を利用して、リモート管理情報が置かれている隣接ノード群を識別するための手段と、そして、リモート管理情報を要求する目的で、機能的管理オーバーレイレイヤを利用して要求メッセージを識別された隣接ノード群に送信するための手段とが含まれる。また、ネットワークノードには、識別された隣接ノード群からの応答メッセージの中で、要求されたリモート管理情報を受信するための手段と、リモート管理情報とローカル管理情報とを集約して、集約された情報を発信側ノードへ送信するための手段とが含まれる。
【００１８】
以下に、添付の図面を参照しながら好適実施形態を示すことによって、本発明の本質的な特徴について詳細に述べよう。
【図面の簡単な説明】
【００１９】
【図１】本発明を実装するために適したネットワークアーキテクチャを簡略化したブロック図である。
【図２】本発明の例示する実施形態におけるネットワークノードを簡略化したブロック図である。
【図３】本発明の方法の例示する実施形態の、アプリケーションレイヤのステップのフローチャートである。
【図４】本発明の方法の例示する実施形態の、分散レイヤのステップのフローチャートである。
【発明を実施するための形態】
【００２０】
本発明は、ネットワーク管理タスクを非集中的に分散して解決するためのアーキテクチャを提供する。本発明のアーキテクチャは、オーバーレイに基づいて管理タスクを分散する。オーバーレイの役割は、（１）異なる複数のノード間に直接のアドレス指定を提供する（すなわち、中央ノードを通してではなく）ことと、（２）アプリケーションレベルで定義された関係を超越してノード群に要求を到達させるための代替案を提供することである。このようにして、本発明は、ネットワーク管理タスクの分散処理を求める要求がすべてのノードに到達したかどうかを決定するときのスケーラビリティ、性能、利用可能性、および整合性を提供する。
【００２１】
本発明のアーキテクチャによって、管理されるネットワーク要素の数の大幅な増加が可能になる。アーキテクチャは、各ノードに小さなオーバヘッドを課すことによって、管理する側のシステムと管理される側のシステムとの間で管理機能を分散することに起因する、複雑度およびダイナミクスの増加に対処する。結果として、管理タスクを分散することは、管理システムにかかる負荷を軽減し、管理プロセスの効率を向上させ、そして、データ処理が、整合性に欠ける恐れのあるデータのコピーではなく、実データに対して行われることを保証するために役立つ。
【００２２】
ネットワーク管理タスクの分散を可能にすることを目的として、本発明のアーキテクチャは、管理するシステムと管理されるシステムの間だけでなく、そうすることがより適切なのであれば、管理されるシステム同士での管理タスクと要求との通信を可能にする。この新たなアーキテクチャの手法では、管理されるシステム同士が、必ずしも中央システムを仲介として用いることなく、相互に所在を突き止めて通信しなければならないことが、必要とされる。
【００２３】
信頼性の理由により、何千あるいは何万もの管理されるシステムを包含するネットワーク群という状況において、障害を回避するような自動ルーティングおよびノードへの到着／出発に際した自動再構成は、極めて重要である。上述のように、ネットワーク管理タスクの分散を可能にするため、管理されるシステム群は、中央集中の知識的情報を利用しなくても相互に所在確認したりアドレス指定したりすることができなければならない。管理アプリケーションに最大限役立つようにするためには、このディスカバリー（探索発見）プレーンは、拡張可能で再構成可能であるべきであり、しかも、既存のネットワーク構造と論理的に集約されているべきである。本発明の各種の実施形態において、探索発見プレーンで用いられる識別子は、管理されるネットワーク内で現在定義され使用されている一意の意味情報に論理的に関連付けられる。
【００２４】
本発明は、データ分配・探索発見（データ・ディストリビューション・ディスカバリー：Ｄ３）レイヤと呼ばれる新たな機能オーバーレイ（抽象概念）レイヤをトラヒックネットワークの中に導入する。Ｄ３レイヤは、トラヒックネットワークの管理を分散的にサポートするために必要な関連情報の動的な探索発見をサポートするようなフレームワークとアーキテクチャとを提供することによって、ネットワーク要素（管理されるシステム）の効果的な制御と管理とをサポートし、そして、自律的な管理システムを作成するために用いることができる分散管理アルゴリズムをサポートするために必要なインフラを提供する。本発明は、トラヒックネットワークおよびネットワーク管理タスクからの意味情報を用いてＤ３レイヤを構築し、ネットワーク構成または意味が変化する場合にはダイナミックにＤ３レイヤを維持し、そして、多様なネットワーク管理タスクに関してＤ３レイヤにおける複数のオーバーレイを維持する。
【００２５】
Ｄ３レイヤは、トラヒックネットワークの上で、かつ、従来の「ネットワーク管理『マネージャ』」レイヤの下に存在する、演算上の抽象レイヤである。Ｄ３レイヤを用いると、ネットワーク管理タスクをネットワーク要素全体に分散させることをサポートするために必要な、ノード群の探索発見処理およびアドレス指定処理の分散が可能になる。Ｄ３レイヤの主な目的は、中央ノードの必要性やサポートや中央集中的な知識情報がなくても、ノード同士が自律的に相互に所在確認し、直接通信して、要求を転送できるようにすることである。
【００２６】
本書で述べた方法論は、例えばピア・ツー・ピア・システムのような、既存の概念に基づいている。Ｄ３レイヤは、分散されたネットワークノード群と管理情報とを探索発見して、ネットワーク管理タスクをノード群に分散するために用いられる。これらのタスクは、特定のネットワーク管理タスクを遂行するためにノード群が相互に直接通信して協力して機能することができるようにする、何らかのかたちのピア・ツー・ピアのアーキテクチャを必要とする。ピア・ツー・ピア・システムでは、各ノードは、ネットワークの部分的な知識を有しており、従って、システム内のノード群の部分集合体にコンタクトをとることができる。また、本発明は、この知識を活用して、アプリケーションレベルでのネットワーク管理の関係によっては必ずしもカバーされていないようなネットワークの部分にも要求を伝達することができる。
【００２７】
図１は、本発明を実装するために適したネットワークアーキテクチャ１０を簡略化したブロック図である。一般に、アーキテクチャは、３つの明確なレイヤ、すなわち、物理レイヤ１１と、データ分配・探索発見（Ｄ３）レイヤ１２と、そして分散アプリケーションレイヤ１３とを備えている。物理レイヤ１１は、ネットワークノード１４間の同期および非同期通信を提供する。通信は有線でも無線でもよく、通信にＡＴＭ、イーサネット（登録商標）、ＴＣＰ／ＩＰ等の技術が含まれてもよいが、それらに限定されない。Ｄ３レイヤ１２は、アプリケーションレイヤ１３をサポートして、自動的に再構成可能なピア・ツー・ピアのノード探索発見レイヤを通して指標付与機能を提供する。本書では、Ｄ３レイヤ１２を、オーバーレイネットワークと呼ぶことがある。アプリケーションレイヤは、ネットワーク管理タスクがその上に構築される土台を提供する。アプリケーションレイヤは、ネットワークノード群を組織化して、ノード間のアプリケーションレベルの関係に基づく有向グラフを作成する。次に、この有向グラフは、ネットワーク管理タスクを遂行するためにネットワークノード群がどのようにして相互に共同作業を行ってもよいかを定義する。
【００２８】
簡単に言えば、アプリケーションレベルの有向グラフはリクエスト（要求）を伝達するために使用され、Ｄ３レイヤはノード群の所在確認をしてアドレス指定をするために使用され、そして、物理レイヤは実データの通信に使用されると認識されてもよい。
【００２９】
Ｄ３レイヤ１２では、ルーティングテーブルおよび／または隣接セットは、所定のアルゴリズムに従って作成され、それによって、ネットワークノード群１４とネットワークノード群に関連するデータの分散的な探索発見が可能になる。１つのネットワークから別のネットワークへとメッセージを送信する必要がある場合、オーバーレイノード内のルーティング情報（すなわちＤ３レイヤでのローカル情報）を利用して、目標ノードへのルートが探索発見される。ルーティングテーブルからのノードのプレフィクスを最終の宛先ノードと照合することによって、オーバーレイルーティングが機能する。
【００３０】
例示する一実施形態では、オーバーレイは、ＤＨＴ技術またはその変形を利用して実装される。Ｄ３レイヤにおけるノード数がＮであって、Ｏ（ｌｏｇ  Ｎ）の情報がローカルなルーティングテーブルに記憶されるとすれば、ＤＨＴの実装の大半は、平均してＯ（ｌｏｇ  Ｎ）回のステップで宛先ノードを探索発見することを保証するであろう。探索発見アルゴリズムの性能は、どのくらいの量の情報がルーティングテーブルに記憶されているかに関連し、記憶されている情報が多ければ多いほど、次のノードを見つけるのが容易になる。従って、Ｏ（ｌｏｇ  Ｎ）について平均的な性能が望ましい場合にはいつでも、ルーティングテーブルのサイズはＯ（ｌｏｇ  Ｎ）でなければならない。
【００３１】
ネットワークアーキテクチャ１０の設計は、下記の原則に基づく。
【００３２】
（１）ネットワーク要素のブートストラッピング―これは、オーバーレイネットワークの管理ネットワークの設定である。これによって、オーバーレイレイヤ（Ｄ３）レイヤのダイナミックな動作が可能になり、従って、オーバーレイネットワークの形成が容易になる。アーキテクチャは、本発明のプロセスとメカニズムとを利用して、トラヒックネットワークとオーバーレイとの間でデータを受け渡す。管理されるネットワークにノードがアタッチ（接続）すると、意味的に特定された情報または指標空間（インデックススペース）におけるドメイン（領域）固有の符号化を示す情報が、転送される（例えば、ＷＣＤＭＡ無線アクセスネットワーク（ＷＲＡＮ）内の無線ネットワーク制御装置（ＲＮＣ）の完全に識別された名称（Ｆｕｌｌｙ  Ｄｉｓｔｉｎｇｕｉｓｈｅｄ  Ｎａｍｅ：ＦＤＮ）。この情報によって、アプリケーションレベルにおいてネットワーク管理要求のルーティングが可能になる。
【００３３】
（２）オーバーレイネットワークの安定性―これは、オーバーレイネットワークを観測することと、Ｄ３レイヤのローカル情報を再構成することと、そしてトラヒックネットワークの変化に応じて隣接先からの要求に応答することとに関わる。この態様は、物理ネットワークの変化を処理するための、時間の経過に伴うルーティングテーブル再構成の必要性に言及する―これらのルーティングテーブルには、管理データおよび管理タスクもしくは機能の分散指標が含まれる。（計画されたアクティビティとしてかまたは故障または不具合が原因で）ネットワーク要素がトラヒックネットワークを離れ、従ってアプリケーションネットワークを離れると、オーバーレイレイヤ内のルーティングテーブルは、変化を考慮に入れるため再構成されなければならない。加えて、管理機能の状態または記述内容が変化すると、管理機能の意味の新たな記述内容を符号化する新たなノードがオーバーレイに追加される。
【００３４】
（３）オーバーレイネットワーク対トラヒックノード群の１対Ｎマッピングの構造をサポートする―これには、ネットワーク管理固有のルーティングを作成することが含まれる。これによって、そのトラヒックノードが複数のオーバーレイネットワーク内に存在する場合であろうと、意味的マッピングが保存されることが保証される。これによって、もしそれが有利であるかまたは必要である場合、複数のオーバーレイが単一のトラヒックネットワーク上に維持されることが可能になる。
【００３５】
（４）オーバーレイネットワークのアプリケーションロジックトラバーサルによって形成されるグラフ内の、および、Ｄ３レイヤのそれらの識別子の中に共通プレフィックスを共有するノード群によって形成されるグラフ内の、データ集約のサポート―第２の変形は、本質的にオーバーレイレイヤの管理機能であり、これを利用してデータ転送メッセージの数を抑制または制限することができる。
【００３６】
（５）メッセージ通信―これによって、分散された複数のエンティティ間で情報が転送可能になる。下記は、メッセージ内に含まれてもよい情報の一例である。
【００３７】
（ａ）メッセージタイプ―システムを通じて転送されるメッセージの多様なタイプを区別するために用いられる、
（ｂ）メッセージ発信側のアドレス―これは、発信側ノードのオーバーレイＩＤとして指定される、
（ｃ）シーケンス番号―二重のメッセージをフィルタで除去するために用いられる、
（ｄ）意味的な符号化されたハッシュ―これは、分散指標のルックアップを通じて、メッセージの宛先ノードの探索発見に用いられる目標ＩＤである、
（ｅ）ペイロードの符号化―ペイロードについての符号化のタイプ、そして、
（ｆ）実際のペイロード―これは、アプリケーション特有の情報である。
【００３８】
分散ネットワーク管理機能にとって複数のネットワークノード間の通信を開始することが必要になると、下記のような一連のアクティビティ（動作）が実行されてもよい。
【００３９】
（１）分散ネットワーク管理タスクの各要求について、アプリケーションレベルの各ネットワークノードで完了する動作のシーケンスは、以下のようである。
【００４０】
（ａ）要求のタイプに基づいて、タスクを完了するために必要なローカルデータおよびリモートデータを識別する。
【００４１】
（ｂ）必要なリモートデータが存在しているかまたは存在しうるネットワークノードを識別して、リモートなネットワークノードに必要な要求メッセージを作成する。
【００４２】
（ｃ）リモートなネットワークノードへ分配するため、必要なメッセージをＤ３レイヤに送信する。そして、
（ｄ）レスポンス（応答）メッセージを作成する。各ネットワークノードは、自分がタスク要求を転送した他のネットワークノード群の各々から応答メッセージを受信するのを待つ。次いで、ネットワークノードは、応答を集約して集約された応答メッセージを作成し、そのメッセージを、自分がタスク要求を受信したソースへ送信する。リモートのネットワークノード群からデータを受信し、次いで、集約された結果と共に要求発信側に返答するには、しばらく待機することが必要な場合がある。
【００４３】
（２）分散レイヤでは、メッセージを受信する場合にはいつも、宛先が現行の受信側ノードであるならば、メッセージはアプリケーションレベル上で転送される。そうでないならば、どのネットワークノードにメッセージが転送されるべきなのかを判定するために、ルーティングテーブル／隣接先のセット（集合体）が用いられる。
【００４４】
図２は、本発明の例示する実施形態におけるネットワークノード１４を簡略化したブロック図である。アプリケーションレイヤ１３において、ネットワーク管理要求受信機１５が、ソースまたは開始側ノードから要求を受信する。データ識別子１６が、要求を分析して、タスクを実行するために必要なデータを識別する。ノードは、この情報をＤ３レイヤにおいてデータローカライザ１７に渡す。データローカライザは、Ｄ３レイヤを用いて切断されているネットワークコンポーネントを見つけ出し、必要なデータをローカライズする（すなわち見つける）。次いで、データローカライザは、アプリケーションレイヤにおいてタスク処理ユニット１８にデータを送信する。集約応答送信機１９が、ダウンストリームのノード群から応答を収集し、集約応答をソースもしくは開始側ノードに送信する。
【００４５】
下記は、通信および探索発見のための基礎的な解決策として分散化されたハッシュテーブル（ＤＨＴ）を用いて、ＵＭＴＳまたはＬＴＥ無線ネットワークに適用された、上記で概説したアーキテクチャによる手法を示す一例である。物理ネットワークの上に構築されたＤ３分散オーバーレイは、ＤＨＴを用いて、ネットワークノード群が分散されたかたちで相互に探索発見し合うことができるようにする。各ノードは、ネットワークを部分的に眺めて、分散オーバーレイの中のいずれかのノードからの要求をいずれかの他のノードへ転送するための決定論的な方法をサポートする。ここで提示された例は、Ｂａｍｂｏｏアルゴリズムを用いるが、いずれかの同様の実装であっても、これと同じ基本的なサポートレベルを提供するであろう。Ｂａｍｂｏｏを利用した解決策において、各ノードは以下を維持する。
【００４６】
（１）現行ノードと共通するプレフィックスを共有するＩＤを有するようなネットワークノード群のＩＤおよびＩＰアドレスが含まれるルーティングテーブル。ルーティングプロトコルは、目標ノードのＩＤに対して整合率が最高となるものがネットワーク内で発見されるまで、長さを増やしながらプレフィックスを照合することによって機能することから、これは他のノード群のアドレス指定をする際に用いられる最も重要な情報である。
【００４７】
（２）ＬをＤＨＴのアーキテクチャのパラメータとすると、オーバーレイリング内にＬ個の隣接先を含むリーフセット（現行ノードのＩＤより大きいＩＤを持つ｜Ｌ｜／２個のノード群と、現行ノードのＩＤより小さいＩＤを持つ｜Ｌ｜／２個のノード群）。リーフセットの大きさＬ、すなわち現行ノードから１オーバーレイホップで到着されうるノードの数と、ノードが記憶すべきローカル情報の量との間に、トレードオフが存在する。通常の実装では、Ｌは、１６または３２という値に設定される。
【００４８】
（３）物理ネットワーク内の既知の隣接先、すなわち、物理レイヤ内で定義された測定基準（例えば地理的な距離、リンクのレイテンシ、またはそれらの組み合わせ）に基づいて現行のネットワークノードの近くに存在するネットワークノード群が含まれる、隣接先セット。ルーティングテーブルおよびリーフセットにデータを投入する際に複数の選択肢が存在する場合には、所定の測定基準に関して現行のネットワークノードに最も近いネットワークノードが選択されることを、ネットワークノードのこのセットを用いて保証する。また、ネットワークノードのこのセットは、オーバーレイの中の見込みパーティションを回避してルーティングを行うのに用いられる（すなわち、故障の結果としてオーバーレイの中にパーティションが作成される場合、物理ネットワーク内の隣接先についての情報を用いて他のパーティションに到達する）。
【００４９】
ルーティングテーブルとリーフセットと隣接先セットとは、あるノードがネットワークに加入すると、自動的に作成されるか、および／または更新され、また、ノードがネットワークを去る場合にも自動的に再構成される。
【００５０】
下記の各ステップは、前のセクションで概説したアーキテクチャの原則に対応する。
【００５１】
（１）ネットワーク要素のブートストラッピング―これは、各ネットワークノード上にある要素管理ロジックを介して達成される。管理機能の意味的な符号化は、「管理される要素」のＦＤＮを、ＳＨＡ−１アルゴリズムを用いてＢａｍｂｏｏハッシュへマッピングすることによってアーカイブされ、オーバーレイネームスペースの中で一意である１６０ビット長のＩＤを生成する。この符号化によって、分散指標を通じて他のノード群によってアクセスされるデータ／機能の分散管理が可能になる。次いで、ノードが、自分自身のルーティングテーブルをそのリーフセットおよび隣接先リストと共に更新し、この動作をその隣接先へ伝達する。
【００５２】
（２）オーバーレイネットワークの安定性―オーバーレイネットワークが形成されると、ネットワークノード上にある機能性が、下記のアルゴリズムに関するタスクを実行する。
【００５３】
（ａ）新たなノードがトラヒックネットワーク内に現れると、ブートストラッピング（非正規のコピー）が行われる。
【００５４】
（ｂ）ノードが消えると、ルーティングの失敗の結果としてか、または、隣接ノード間で送信されたハートビートメッセージが行方不明になったからかのいずれか一方であるとして、イベントが検出される。ノードがオーバーレイを離れたというこの指標によって、ルーティングテーブルの再構成がトリガ（それを契機として開始）される。これは、隣接ノード群に代わりのエントリを要求することによって遂行される。代わりのエントリが見つからない場合、ルーティングテーブルに空白のエントリが入力される。留意すべきだが、分散指標の中にいくつかの空白のエントリがあった場合でも、代替ルートが見つかるであろうから、ルーティングはやはり機能する。
【００５５】
（ｃ）オーバーレイ上の古いネットワークノードを置換しなければならない場合、古いノードが除去されて、前のステップに概説したのと同じ動作がトリガされる。次いで、ブートストラップ手順を用いて、新たなノードが分散指標に追加される。このタスクがうまく完了した時点で、新たな意味を符号化する新たなエントリが、ＤＨＴに挿入される。
【００５６】
（３）トラヒックノード群対オーバーレイネットワークノード群の１−ｎマッピングの構築。メッセージの初期ルーティングは、ルックアップの検索から受信されたＤＨＴ情報から達成され、次いで、メッセージは、対象ノードへルーティングされる。そこで、トラヒックノード上のメッセージを終了させる通信サポートがメッセージをデマーシャル（整列解除）し、意味的ハッシュを調べ、そして、メッセージを正しいプロセス（すなわち、意味的ハッシュに対応するロジックを実装するプロセス）へルーティングする。
【００５７】
（４）アプリケーションロジックによって形成されたグラフにおける、または、符号化において共通プレフィックスを共有するノード群によって形成されたグラフにおける、データ集約のサポート。これはＢａｍｂｏｏの特徴であるが、ＩＤの中の共通プレフィックスを共有するノード群への要求は、共通ルートに沿ってルーティングされ、そのようにしてオーバーレイ内でツリーが形成される。この特徴は、本質的に、メッセージの数や転送されるデータを停止／制限するためのオーバーレイの管理機能である。
【００５８】
（５）メッセージング。この特定の例について、メッセージ形式は下記のタイプでできている。
【００５９】
＜ｔｙｐｅ＞＜ｓｅｑ＿ｎｏ＞＜ｔａｒｇｅｔ＞＜ｔｙｐｅ  ｏｆ  ｅｎｃｏｄｉｎｇ＞＜ａｐｐｌｉｃａｔｉｏｎ−ｓｐｅｃｉｆｉｃ  ｐａｙｌｏａｄ＞
しかし、本発明の適用範囲内で、多くのタイプのメッセージ形式およびコンテンツが想定されうる。
【００６０】
図３は、本発明の方法を例示する実施形態の、アプリケーションレイヤのステップのフローチャートである。本方法は、ネットワークノード間の通信を開始することを分散ネットワーク管理機能が必要とする場合に実行される。ステップ２１で、受信側ネットワークノードにおいて要求発信側から送信された分散ネットワーク管理タスクリクエスト（要求）が受信される。ステップ２２で、受信側ノードが、タスク要求のタイプに基づいてタスクを完了するために必要となるローカルデータおよびリモートデータを識別する。ステップ２３で、受信側ノードは、必要とされるリモートデータが配置・記憶されているかまたは配置・記憶されている可能性があるネットワークノード群を識別・特定し、そして、リモートのネットワークノード群のために必要な要求メッセージを作成する。ステップ２４で、受信側ノードが、必要なメッセージをＤ３分散レイヤへ送信して、リモートのネットワークノード群に分配する。ステップ２５で、リモートのネットワークノード群からレスポンス（応答）が受信された後、受信側ノードは、集約応答メッセージを作成する。各ネットワークノードは、自分がタスク要求を転送した他のネットワークノード群の各々から応答メッセージを受信するのを待つ。次いで、ネットワークノードは、応答を集約して集約応答メッセージを作成する。ステップ２６で、集約応答メッセージが、要求発信側へ送信される。リモートのネットワークノード群からデータを受信し、次いで、集約された結果と共に要求発信側に返答するには、しばらく待機することが必要な場合がある。
【００６１】
図４は、本発明の方法の例示する実施形態の、分散レイヤのステップのフローチャートである。ステップ３１で、要求側ノードからのタスク要求メッセージが、リモートのネットワークノードにおいて分散レイヤで受信される。要求メッセージは、例えば図３で説明した受信側ノードのような、要求側ノードから受信されてもよい。ステップ３２で、リモートのネットワークノードが要求メッセージの宛先であるかどうか判定される。そうであれば、方法はステップ３３に進み、メッセージはアプリケーションレイヤへ転送されて処理される。そうでないならば、方法はステップ３４へ進み、リモートノードは、そのルーティングテーブル／隣接先を示す情報のセットを利用してメッセージがどのネットワークノードへ転送されるべきかを判定して、メッセージを転送する。
【００６２】
また、上記の記述から理解されるべきだが、発信側ノードと受信側ノードの役割は、同一のノード内に共存できる。従って、要求側ノードとリモートのネットワークノードとは、同一のノード内で物理的に同一の場所に配置されてもよい。
【００６３】
本発明はもちろん、本発明の本質的な特徴から逸脱することなく本書に述べたやり方とは別のやり方で実行されてもよい。従って、本書の諸実施形態は、あらゆる点で例示的であって限定的ではないと考えられるべきであり、添付の請求項および均等の範囲に入るすべての変形は、その中に包含されることが意図されている。
【００６４】
関連出願について
本願は、２００７年３月９日に提出された米国仮出願第６０／８９４，０８５号についての優先権を主張した出願である。
【図１】
2010521093.tif 000003
【図２】
2010521093.tif 000004
【図３】
2010521093.tif 000005
【図４】
2010521093.tif 000006
【国際調査報告】
2010521093.tif 000007
2010521093.tif 000008
2010521093.tif 000009