JP5536769B2

JP5536769B2 - 通信ネットワークシステムにおける方法及び装置

Info

Publication number: JP5536769B2
Application number: JP2011516204A
Authority: JP
Inventors: ロベルトペテルセン，; ジョンパワー，; エドウィンツェー，
Original assignee: テレフオンアクチーボラゲットエルエムエリクソン（パブル）
Priority date: 2008-06-27
Filing date: 2008-06-27
Publication date: 2014-07-02
Anticipated expiration: 2028-06-27
Also published as: EP2292064A4; JP2011526119A; EP2292064A1; US8719394B2; US20110113132A1; WO2009157834A1

Description

本発明は、通信ネットワークシステムにおける方法及び装置に関するものであり、より詳しくは、通信ネットワークシステムの管理を容易にすることを可能にする装置及びその容易化のための方法に関するものである。

ネットワークは、ノード群とリンク群から構成される。大規模ネットワークは、数百万のノードとリンクを備え、これらの間で情報を転送し、かつネットワークのユーザ／加入者へのサービスのプロビジョニングを行う。このような要件を満足するために、ネットワークは、すべてのノードとリンクが、設計されたかつ計画された機能を実行するように管理される必要がある。

ネットワークにおいて、ノード群（例えば、図２のネットワークエレメント−１（ＮＥ−１）、ネットワークエレメント−Ａ（ＮＥ−Ａ））は、機能を実行するパケットデータスイッチ群（物理ノード群）あるいはソフトウェアプロセス群（アプリケーション群）群であり得る。リンク群（例えば、図２のＮＥ群）は、マイクロ波リンク群、サブマリンケーブル群、あるいはノード間の単なる論理接群の表現であり得る。セルラーネットワークでは、ノード群は、無線基地局群、ハンドセット群等であり得り、リンク群は、無線リンク群、仮想プライベートネットワーク群（ＶＰＮ群）の論理接続群等であり得る。

また、ネットワークでは、ネットワークのユーザ／加入者に情報を転送したり、サービスのプロビジョニングを行うことを担当しないノード群が存在する。これらのノード群（例えば、図２のネットワークマネージャ（ＮＭ）とドメインマネージャ（ＤＭ））はネットワークを管理する。これらは、ノード群とリンク群とを配備し、構成設定し、統括する。これらはネットワークを監視し、ネットワークパフォーマンスがある程度の計画された閾値を下回る場合、ネットワークは、リカバリー計画を開始する。このリカバリー計画には、例えば、ノード群の再構成設定、ユーザ呼ルート群の再構成設定、不良ノード群のデアクティベート、バックアップノード群のアクティベート等がある。

ネットワーク管理アーキテクチャ（即ち、ＮＭ群、ＤＭ群及びＮＥ群の構成は、ＩＴＵ−Ｔ、３ＧＰＰ、３ＧＰＰ２及びＩＥＴＦのような様々な国際規格化団体及び組織の対象となっている。これらのネットワーク管理アーキテクチャのすべては、（実）ノード群と（実）リンク群がソフトウェアモジュールによって現わされるという点で、１つの基本原理を共有している。ソフトウェアモジュール群の集合体は、管理情報ベース（ＭＩＢ）と呼ばれ、これは、ＤＭ群に記憶、保持される。各ソフトウェアモジュールは、実際のノードあるいはリンクを表わしていて、これは管理オブジェクトインスタンス（ＭＯＩ）群と呼ばれる。ＭＯＩ（即ち、ＭＩＤ）群の集合体は、バーチャルリアリティ（仮想現実）の管理下にある実ノード群と実リンク群である。ＮＭ群及びＤＭ群の少なくとも一方で動作するアプリケーション群は、ＭＯＩ群にアクセスして操作することによって、実ノード群と実リンク群を管理する（統括し、制御する）。

ＭＯＩ群の構成と、各ＭＯＩに含まれる情報は、スキーマに基づいている。様々な標準化団体は、いわゆるスキーマ、あるいはネットワークリソースモデルあるいはオブジェクトモデルを公表している。

従来では、ＭＩＢは、ＤＭ（図２のＤＭ−１のＭＩＢ参照）によって管理される管理ネットワークリソースを表わしているソフトウェアオブジェクトの集合体であるＭＯＩであり、このＭＩＢは、所定のスキーマの定義に基づいている。このスキーマ（あるいはスキーマ定義）は、ランタイム（run time）で変更することはできない。あるいは別の方法においては、ＭＩＢは、スキーマの定義に基づいてインスタンス化（生成）されているＭＯＩ群の集合体である。このような種類のＭＩＢは大規模である。より小規模のＭＩＢと比較した場合、大規模のＭＩＢは、以下のことを維持することがより難しい。

・実際のネットワークステータスに、ＭＩＢ内で保持される情報を同期させるための時間がより多くかかる。

・ＭＩＢユーザ群からの、ＭＩＢデータの取得、ＭＩＢデータの変更、及びＭＩＢ情報サーチリクエストを満足するための処理能力をより多く必要とする。

・ユーザが望まない情報を含んでいるので、ＭＩＢから取得される情報にフィルタを適用する必要がある。フィルタ処理は時間がかかる。

スキーマは、管理情報ベース（ＭＩＢ）のデータ定義である。この定義は、すべてのＮＥ群のクラスおよびそれらの関係に対するものである。この定義は、すべての動作コンテキストおよびユーザ（この分野のエンジニア、ネットワークプランナー、ヘッドオフィス管理スタッフ等）をサポートしなければならない。従来のスキーマは、ランタイムで変更することができない。その結果として、スキーマ定義に基づく、管理ネットワークのすべてのＮＥ群のインスタンス化されたものであるＭＩＢは大規模なものとなるであろう。なぜなら、週に７日、かつ２４時間の可用性を以下のことについてサポートしているからである。

・様々な種類のユーザを満足するためのあらゆる種類のネットワーク管理データ
・ネットワーク全体
従って、本発明の目的の１つは、通信ネットワークシステム管理を容易にする改良された方法及び装置を提供することである。この通信ネットワークシステム管理では、ネットワーク管理アーキテクチャがバーチャルリアリティの管理下にあるネットワークノード群及びネットワークリンク群を表すモジュール群を備えている。モジュールの構成と、該モジュールに含まれる情報は、所定のネットワーク管理スキーマに基づいていて、これよって、ネットワークノード群と、ネットワークリンク群は、モジュール群にアクセスして操作することによって管理される。

本発明の第１の構成に従えば、この目的は、請求項１の特徴的な構成で定義される方法を通じて達成される。この特徴的な構成は、モジュール群内の情報の量を削減することによって、ネットワーク管理スキーマを修正するステップと、通信ネットワークシステムを管理するために、修正されたネットワーク管理スキーマを使用するステップとを実行する方法によって、通信ネットワークシステム管理が容易になることを特定している。

本発明の第２の構成に従えば、請求項９の特徴的な構成で定義される装置を通じて達成される。この特徴的な構成は、モジュール群内の情報の量を削減することによって、ネットワーク管理スキーマを修正するインタフェースと、通信ネットワークシステムを管理するために、修正されたネットワーク管理スキーマを使用するドメインマネージャとを備える装置によって、通信ネットワークシステム管理が容易になることを特定している。

更なる実施形態は、従属請求項で示されている。

ランタイムでスキーマを修正するためのメカニズムを提供する方法及び装置の提供のおかげで、マネージャに対して明らかなＭＩＢのサイズがより小さくなる、つまり、通信ネットワークシステム管理を容易にする。

本発明の別の目的及び構成は、図面とともに考慮される以下の詳細説明から明らかとなろう。しかしながら、これらの図面は、単なる例示の目的で、また、添付の請求項で参照されるべき本発明の定義を制限するものではないことが理解されるべきである。図面は、示されない限り、縮尺通りに示される必要はなく、これらの図は単に、本明細書で記載される構成及び手順を概念的に示すことが意図されている。

通信ネットワークアーキテクチャの例を示す図である。本発明に従うコンテキスト図である。本発明に従うクラス図である。ａｃｔｉｖａｔｅＭａｐ（．．．）を使用する例における、マネージャに対して提供される１つの動作の使用を示すフローチャートである。ｃｒｅａｔｅＭａｐＩｎＳｔｏｒａｇｅ（．．．）を使用する例である、マネージャに対して提供される１つの動作の使用を示すフローチャートである。本発明の実施形態に従う本発明の方法のフローチャートである。

図１は、無線アクセスネットワーク（ＲＡＮ）を含む通信ネットワークシステムを示している。この無線ネットワーク（ＲＡＮ）は、例えば、ＵＭＴＳ陸上無線アクセスネットワーク（ＵＴＲＡＮ）アーキテクチャがあり、これは、１つ以上の無線ネットワークコントローラ（ＲＮＣ）に接続されている少なくとも１つの無線基地局（ＲＢＳ）（あるいはノードＢ）１５（図１では２つ示されている）を備えている。ＲＡＮは、コアネットワーク（ＣＮ）１２に接続されている。ＲＡＮとＣＮ１２は、複数のユーザ機器（ＵＥ）１８に対する通信及び制御を提供していて、ユーザ機器（ＵＥ）１８のそれぞれは、ダウンリンク（ＤＬ）チャネル１６とアップリンク（ＵＬ）チャネル１７を使用する。明確化のために、１つのアップリンクチャネルだけが１７で示され、また、１つのダウンリンクチャネルだけが１６で示されている。ダウンリンクチャネル１６において、ＲＢＳ１５は、各電力レベルでデータを各ユーザ機器１８へ送信する。アップリンクチャネル１７において、ユーザ機器１８は、各電力レベルでデータをＲＢＳ１５へ送信する。

本発明の実施形態に従えば、通信ネットワークシステムは、本明細書では、ＷＣＤＭＡ通信システムとして示される。しかしながら、当業者には、同様のネットワーク管理を使用する他の通信システムにおいても、本発明の方法及び装置で動作することが理解されるであろう。

通信システムは、さらに、図２に示されるネットワークの管理を担当するノード群を備えるネットワークアーキテクチャを備えている。これらのノード群は、上述しているように、通信システムのノード群及びリンク群を配備し、構成設定し、及び統括する。

図２に示されるように、ネットワーク管理アーキテクチャは、ネットワークエレメント（ＮＥ）２４群を備え、このネットワークエレメント（ＮＥ）２４群は、図１で示されるＲＮＣ１０及び無線基地局１５のような、通信ネットワークシステムのノード群（ネットワークリソース）群である。ＮＥ群２４は、ドメインマネージャ（ＤＭ−１）２２によってインタフェース２３を介して管理される。このドメインマネージャ（ＤＭ−１）２２は、管理オブジェクトインスタンス（ＭＯＩ）群と呼ばれるソフトウェアオブジェクト群の集合体である管理情報ベース（ＭＩＢ）２５を保持する。管理オブジェクトインスタンス（ＭＯＩ）群は、それぞれ、ＮＥ−１、ＮＥ−Ｙのような管理ネットワークリソース２４群の表現である。明確化のために、図２ではＤＭが１つだけしか示されていないが、当業者は、このアーキテクチャが１つ以上のＤＭを備えても良いことを理解するであろう。ＭＩＢのユーザ群であるＮＭ２０群は、ＮＭ−１、ＮＭ−２及びＮＭ−３で表わされている。ＭＩＢ２５、より正確には、ＭＩＢ２５のソフトウェアオブジェクト群は、図２のインタフェース２１を介してＮＭ２０群によってアクセス可能である。

ＭＯＩ群の構成と、各ＭＯＩに含まれる情報は、ネットワークモデルあるいはスキーマに基づいている。従来技術としては、図２のＭＩＢ２５に対するスキーマは固定である、即ち、スキーマは変更されない。ＭＩＢのスキーマは、実際のネットワーク内のオブジェクトを表わす様々なオブジェクトクラスを定義している。オブジェクトクラスの一例は、セル群、即ち、無線ネットワークのセル群がある。各クラスは属性を有していて、これは、クラスを記述するデータである。属性の例には、ＩＤ、即ち、クラスの識別情報や、周波数、即ち、クラスが使用する周波数や、最大電力、即ち、使用するための最大許容電力等がある。

本発明の実施形態に従えば、ランタイムでスキーマを修正するためのメカニズムが提供され、また、スキーマの定義を変更するために、マネージャ２０によって使用することができる対話／操作が提供される。このスキーマは、例えば、後述するディメンジョン（次元）を変更する必要があるとマネージャが考える場合に変更される。

スキーマの修正は、その変更がスキーマのケイパビリティを削減することだけ、つまり、マネージャに認識されるＭＩＢをより小さくすることだけであるという意味で限定的である。一例として、ＭＩＢのスキーマは、１６個の属性を有するオブジェクトのクラスを定義している。ランタイムで、ＭＩＢのスキーマ定義は、本来定義されている１６個の属性に変えて、９個の属性を有するオブジェクトのクラスとなるように変更することができる。これは、スキーマでは、ＭＯＩのクラスの定義から属性を無効にするあるいは削除することによって達成される。別の例では、ＭＩＢのスキーマは、１００個のＭＯＩのクラスを定義している。ランタイムで、ＭＩＢのスキーマ定義は、１００個のＭＯＩのクラスの内、７個を使用されないように変更することができる。この修正は、拡張すること、例えば、新規のＭＯＩのクラスをスキーマに追加すること、あるいは新規の属性をＭＯＩのクラスに追加することはできない。

すべてのＭＩＢユーザ（即ち、マネージャ２０）は、すべてのＭＩＢの情報を使用することができない、即ち、スキーマは、ＭＩＢのユーザによって要求されないＭＩＢの情報に対して要求されるメンテナンスがなされないように調整することができる。このスキーマの修正は、以下のディメンジョンに従って達成される。

・時間：ネットワークのいくつかの部分のトラフィック量は、時刻に高く相関している。このような場合、あるネットワーク部分を表わすＭＩＢの部分は、「忙しい」時間に対しては完全なスキーマを使用し、他の時間に対してはその削減したものを使用することで、忙しい時間の間のネットワーク動作の異常をより早く検出し、かつ診断するようにする。

・ロケーション（位置）：ネットワークのいくつかの部分（例えば、新規にインストールされたネットワークセグメント）は、集中モニタリングを要求することができ、一方で、別の部分、例えば、何ヶ月も稼動していて、かつ計画に従って完全に動作可能な部分が、それよりはあまり集中的でないモニタリングを要求することができる。そのような場合、ネットワークの前者の部分を表すＭＩＢの部分は、完全なスキーマ定義となり、後者の部分を表すＭＩＢの部分は、「削減されたスキーマ」を使用することになる。即ち、完全なスキーマをサブネットワーク−Ａに適用し、一方で、スキーマの一部をサブネットワーク−Ｂに適用する。

・クラスベース：例えば、ＭＳＣ機能のＩＯＣ（MSCFunction IOC）の属性−１、属性−６の使用を無効にする。ＥＵＴＲＡＮ機能のＩＯＣ（EUTRANFunction IOC）からの通知−７及び通知−２の使用を無効にする。修正が「クラスベース（class based）」で適用される場合、このクラスのすべてのインスタンスが修正される。

・インスタンスベース：例えば、あるＭＳＣ機能に対するＶｓＤａｔａＣｏｎｔａｉｎｅｒ（Ｖｓデータコンテナ）の属性の使用を無効にする。ある無線基地局群からのカウンタ−５、ＫＰＩ−ｘｙｚ生成を無効にする。修正が「インスタンスベース（instance based）」で適用される場合、特定のインスタンスが修正される。

・上述の例の様々な組み合わせ
スキーマを修正するためのリクエストは、マネージャ２０によって開始される。即ち、マネージャ２０が、上述のディメンジョンのために、必要であると考える場合に開始される。

本発明の実施形態に従えば、ＭＩＢのマネージャのすべてのユーザ（例えば、オペレータ、ネットワークオペレータのプランナー）が、どのようにしてＭＩＢを構成設定するかについての同意済の計画を有している。マネージャはＭＩＢを変更する場合、変更されたＭＩＢは、すべての他のマネージャにサービスを提供することになる。

図３は、本発明の主要な機能コンポーネントの例を示している。エージェント３１は、様々なマネージャ（図３では不図示）とインタフェースで接続するエンティティであり、また、マネージャとエージェント３１との通信に介在するインタフェースを提供する。エージェントは、２つの機能コンポーネントとして、記憶装置３３とＭＩＢ２５を保持している。

記憶装置３３は、マネージャによって設計／生成されているすべてのマップを保持している。記憶装置３３に含まれるマップには、２種類のマップとして、ロケーションマップ（ＬｏｃａｔｉｏｎＭａｐ）３６とスキーママップ（ＳｃｈｅｍａＭａｐ）３５がある。

識別子マップＩＤによって識別されるロケーションマップ３６は、以下の情報を所有している。

・マップＩＤ：これは、そのマップインスタンスと、記憶装置３３内部の他のすべてのマップインスタンスから固有に識別する。

・ロケーション：これは、ＭＩＢ２５のＭＯＩの識別名（ＤＮ）である。スキーマ（第３の属性）は、このＤＮ属性によって識別されるサブツリーに関連する。

・スキーマ：これは、スキーマ、クラス定義の集合体、及び第２の属性のＤＮによって識別されるサブツリーに適用可能なそれらの関係である。

スキーママップ３５は、ロケーションパラメータが存在しないこと以外は、ロケーションマップ３６と同一である。エージェント３１は、この不在情報、即ち、スキーマが提供可能であるロケーションを保持する。エージェント３１は、以下で説明する、ａｔｔａｃｈＭａｐ（）に応じて、特定のロケーションに対するスキーママップ３５を使用する場合に、この不在情報を把握している。

エージェント３１は、更に、管理情報ベース（ＭＩＢ）２５を保持している。上述のように、ＭＩＢ２５はソフトウェアインスタンス（モジュール）群を保持する。これらはそれぞれ、管理ネットワークリソースの表現である。ランタイムでＭＩＢ２５によって使用される（かつ、「使用」関係が３８で示される）１つ以上のスキーマが、図３の３７で示されるように、記憶装置３３に記憶される（あるいは含められる）。

エージェント３１は、インタフェース３９を介して６つの動作をサポートする：
１．ｑｕｅｒｙＭａｐＳｔｏｒａｇｅ（）
この動作は、マネージャに、記憶装置３３内の現在のロケーションマップ（群）とスキーママップ（群）のリスティングを問い合わせることを可能にする。このリスティングは、すべてのマネージャ（群）によって生成されるマップ群を含んでいる。リスティングは、ステータス（例えば、ある時点で使用される／アクティブにされる場合）を含んでいる。

・入力パラメータ１：なし（ｎｏｎｅ）
・出力パラメータ１：ロケーションマップのリスト
・出力パラメータ２：スキーママップのリスト

２．ｃｒｅａｔｅＭａｐＩｎＳｔｏｒａｇｅ（）
この動作は、マネージャに、新規のロケーションマップあるいはスキーママップを生成することを可能にする。

エージェントは、新規に生成されたマップを記憶装置に記憶する。

・入力パラメータ１：ロケーションマップあるいはスキーママップ
・出力パラメータ１：２つの値を有する。成功は、マップが生成されたことを意味する。失敗は、マップが生成されないことを意味する。失敗の理由も提供される。

３．ｄｅｌｅｔｅＭａｐＩｎＳｔｏｒａｇｅ（）
この動作は、マネージャに、記憶装置からマップを削除することを可能にする。

・入力パラメータ１：ロケーションマップのマップＩＤのリスト、スキーママップのマップＩＤのリスト
・出力パラメータ１：２つの値を有する。成功は、すべての識別されているマップ群が記憶装置から除去されるあるいは削除されることを意味する。失敗は、少なくとも１つの識別されたマップが依然として記憶装置に存在することを意味する。失敗の理由と記憶装置に依然として存在するマップ（群）が提供される。

４．ｑｕｅｒｙＡｃｔｉｖｅＭａｐｓ（）
この動作は、マネージャに、アクティブなマップ群の識別情報のリスティングを問い合わせることを可能にする。この動作の応答には、（定義群）実際のスキーマの定義を含むのではなく、単なる、マップ（群）の識別情報だけである。エージェントは、アクティブなロケーションマップ（群）とスキーママップ（群）のリストを返信する。即ち、図３の「使用」３８の関係を有する。スキーママップ（群）の場合、エージェントも、識別される各スキーママップに対して、そのスキーママップが使用される／適用される場所を示すロケーション情報を供給する。

・入力パラメータ１：なし
・出力パラメータ１：ロケーションマップのマップＩＤ（群）（ＬｏｃａｔｉｏｎＭａｐ．ｍａｐＩＤ（ｓ））のリスト、｛スキーママップのマップＩＤ、ロケーション（ＳｃｈｅｍａＭａｐ．ｍａｐＩＤ，ｌｏｃａｔｉｏｎ）｝

５．ａｃｔｉｖａｔｅＭａｐ（）
この動作は、マネージャに、マップ群（ロケーションマップ（群）及びスキーママップ（群）の少なくとも一方）のセットをアクティベートすることを可能にする。スキーママップの場合、マネージャは、ロケーション情報も供給する。

・入力パラメータ１：ロケーションマップリスト：これは、マップＩＤ（群）（マップの識別子）のセットを搬送する。

・入力パラメータ２：スキーママップリスト：これは、｛マップＩＤ、ロケーション｝のセットを搬送する。

・出力パラメータ１：２つの値を有する。成功は、すべての動作が成功し、またすべてのマップがアクティブであることを意味する。失敗は、供給されるマップ群にアクティブなものがないことを意味する。この失敗の理由も提供される。「部分的な成功」の状況が存在する場合があり、その上、想定されるＮＭが全く変更されてない、より単純でより「フェイルセーフ」なソリューションの状況があってもよい。そして、ＮＭは再度試行することができる。サーバは、マップリストの取り得るメンバー群の内部依存状態を把握していない。そのため、あるものをアクティブにして、他のものをアクティブにしないこと（部分的な成功の状況）は、サーバに対しては「安全でない」といえる。

６．ｄｅａｃｔｉｖａｔｅＭａｐ（）
この動作は、マネージャに、アクティブなマップ（群）をデアクティブにすることを可能にする。

・入力パラメータ１：マップリスト：これは、マップＩＤ（群）のセットを搬送する。

・出力パラメータ１：これは、２つの値を有する。成功は、動作の前にアクティブであったか否かに関わらず、識別されたマップが現在アクティブでないことを意味する。失敗は、識別されたマップがわからない、あるいは識別されたマップがアクティブであった、かつ依然としてアクティブであることを意味する。失敗の理由も提供される。

図４は、マネージャがマップ群のセットをアクティベートすることを要望する場合に、どのようにしてａｃｔｉｖａｔｅＭａｐ（．．．）動作が使用されるかの例示のフローチャートを示している。

・ａｃｔｉｖａｔｅＭａｐが有効であり（あるいはマップ群が記憶装置に存在し）、かつアクティベート対象がスキーママップである場合、スキーママップにアクティブであることをマークする（ステップ４１）
・次に、アクティベート対象がロケーションマップである場合、ＭＩＢ内に必要なＭＯＩ群を生成する（ステップ４２）
・更に、ａｃｔｉｖａｔｅＭａｐが有効であり（あるいはマップ群が記憶装置に存在し）、かつアクティベート対象がスキーママップでなくロケーションマップである場合、必要なＭＯＩ群をＭＩＢに生成する（ステップ４２）
図５は、マネージャが新規のロケーションマップあるいはスキーママップを生成することを要望する場合に、どのようにしてｃｒｅａｔｅＭａｐＩｎＳｔｏｒａｇｅ（．．．）動作が使用されるかについての別の例のフローチャートを示している。

・ｃｒｅａｔｅＭａｐＩｎＳｔｏｒａｇｅが有効である場合、マップ群を記憶装置に記憶する（ステップ５１）
本発明の実施形態に従えば、上述の手順は、ネットワーク管理アーキテクチャがバーチャルリアリティの管理下にあるネットワークノード群及びネットワークリンク群を表すモジュール群を備える場合の通信ネットワークシステム管理を容易にする。ここで、このモジュール群の構成と、そのモジュール群に含まれる情報は、所定のネットワーク管理スキーマに基づいている。これよって、ネットワークノード群と、ネットワークリンク群は、図６に示されるモジュール群を、以下のように、アクセスして操作することによって管理される：
・ネットワーク管理スキーマを修正するためのリクエストを受信する（ステップ６１）。このリクエストは、マネージャによって開始される。

・リクエストのフォーマットを判定する（ステップ６２）、即ち、取り得る動作群（エージェントによってサポートされる）とその属性群を判定する。

・受信したフォーマットに基づいてスキーマを修正する（ステップ６３）、即ち、例えば、無効ないくつかの属性によってＭＩＢのサイズを削減する。

・ネットワーク管理に対し、修正されたスキーマを使用する（ステップ６４）。

このように、実施形態に適用される本発明の基本的な新規の特徴が示され、記載され、かつ指摘される一方で、図示されるデバイス群及びそれらの動作の形式及び詳細が、本発明の範囲から逸脱することなく当業者によって様々な省略、置換及び変更がなされても良いことが理解されるであろう。例えば、同一の結果をもたらす実質的に同一の方法で実質的に同一の機能を実行する、これらの要素群及び方法のステップ群の少なくとも一方のあらゆる組み合わせが本発明の範囲に入ることが意図されることは明らかである。また、本発明の任意の開示の形式あるいは実施形態とともに示されかつ記載される構造群、要素群及び方法のステップ群が、設計の選択の一般的な事項として、任意の他の開示される、あるいは記載される、あるいは提案される形式あるいは実施形態に組み込まれても良いことが認識されるべきである。それゆえ、本発明は、添付の請求項の範囲によって示される内容だけに制限されることが意図されるものである。

本発明を記載しかつ定義するために使用される、「含んでいる」、「備えている」、「組み込まれている」、「からなる」、「有する」、「である」のような表現は、非排他的な方法で、即ち、明示的に記載されていないアイテム群、コンポーネント群あるいは要素群が存在することを許容していることが解釈されることが意図されるものである。単数形への参照は、複数のもの及び単数のものの両方に関連するものと解釈されるべきである。

請求項内で、括弧書に含まれる数字は、請求項の理解を助けるために意図されており、これらの請求項によって定義される特徴事項を制限するためのものであると解釈されるべきでない。

Claims

ネットワーク管理アーキテクチャが、バーチャルリアリティ環境で論理的に管理されているネットワークノード群及びネットワークリンク群を表すモジュール群を備える場合の通信ネットワークシステム管理を容易にする方法であって、
前記モジュール群の構成と、該モジュール群に含まれる情報は、所定のネットワーク管理スキーマに基づいていて、これによって、前記ネットワークノード群と、前記ネットワークリンク群は、前記モジュール群にアクセスして操作することによって管理される方法であって、
前記方法は、
時間、ネットワークを構成する部分を示すロケーション、前記ネットワークにおける同一のタイプの前記モジュール群を示すクラス、及び前記ネットワークにおける前記モジュール群を示すインスタンスの少なくとも１つに依存して、前記モジュール群内の情報の量を削減することによって、前記ネットワーク管理スキーマを修正するステップと、
前記通信ネットワークシステムを管理するために、前記修正されたネットワーク管理スキーマを使用するステップと、
インタフェースを介して前記ネットワーク管理スキーマが修正される、前記インタフェースを提供するステップとを備え、
前記インタフェースは、
記憶装置と、
前記モジュール群を保持する管理情報ベース（ＭＩＢ）を備え、
前記記憶装置は、
前記管理情報ベースを管理するマネージャによって生成される２種類のマップとして、
マップインスタンスを識別するマップＩＤ、前記管理情報ベースの管理オブジェクトインスタンス（ＭＯＩ）の識別名、及びスキーマを管理するロケーションマップ群と、
マップインスタンスを識別するマップＩＤ、及びスキーマを管理するスキーママップ群を含み、
前記インタフェースは、
前記ロケーションマップ群と前記スキーママップ群のリストを問い合わせる動作、
新規の前記ロケーションマップあるいは前記スキーママップを生成する動作、
マップを削除する動作、
アクティブなマップのリストを問い合わせる動作、
マップ群のセットをアクティベートする動作、
アクティブなマップ群をデアクティベートする動作
の少なくとも１つをサポートする
ことを特徴とする方法。
前記ネットワーク管理スキーマは、時刻に依存して修正される
ことを特徴とする請求項１に記載の方法。
前記ネットワーク管理スキーマは、前記通信ネットワークシステム内で管理される前記ネットワークノード群のロケーションに依存して修正される
ことを特徴とする請求項１または２に記載の方法。
同一のタイプのモジュール群は、前記ネットワーク管理スキーマによって定義されるオブジェクトのクラスによって表され、
前記ネットワーク管理スキーマは、オブジェクトのクラスに依存して修正される
ことを特徴とする請求項１乃至３のいずれか１項に記載の方法。
前記ネットワーク管理スキーマは、前記モジュール群のそれぞれに依存して修正される
ことを特徴とする請求項１乃至４のいずれか１項に記載の方法。
ネットワーク管理アーキテクチャが、バーチャルリアリティ環境で論理的に管理されているネットワークノード（２４）群及びネットワークリンク群を表すモジュール群を備える場合の通信ネットワークシステム管理を容易にするための装置であって、
前記モジュール群の構成と、該モジュール群に含まれる情報は、所定のネットワーク管理スキーマに基づいていて、これによって、前記ネットワークノード（２４）群と、前記ネットワークリンク群は、前記モジュール群にアクセスして操作することによって管理される装置であって、
前記装置は、
時間、ネットワークを構成する部分を示すロケーション、前記ネットワークにおける同一のタイプの前記モジュール群を示すクラス、及び前記ネットワークにおける前記モジュール群を示すインスタンスの少なくとも１つに依存して、前記モジュール群内の情報の量を削減することによって、前記ネットワーク管理スキーマを修正するためのインタフェース（３９）と、
前記通信ネットワークシステムを管理するために、前記修正されたネットワーク管理スキーマを使用するためのドメインマネージャ（２２）とを備え、
前記インタフェース（３９）は、
記憶装置と、
前記モジュール群を保持する管理情報ベース（ＭＩＢ）を備え、
前記記憶装置は、
前記管理情報ベースを管理するマネージャによって生成される２種類のマップとして、
マップインスタンスを識別するマップＩＤ、前記管理情報ベースの管理オブジェクトインスタンス（ＭＯＩ）の識別名、及びスキーマを管理するロケーションマップ（３６）群と、
マップインスタンスを識別するマップＩＤ、及びスキーマを管理するスキーママップ（３５）群を含み、
前記インタフェース（３９）は、
前記ロケーションマップ（３６）群と前記スキーママップ（３５）群のリストを問い合わせる動作、
新規の前記ロケーションマップ（３６）あるいは前記スキーママップ（３５）を生成する動作、
マップを削除する動作、
アクティブなマップのリストを問い合わせる動作、
マップ群のセットをアクティベートする動作、
アクティブなマップ群をデアクティベートする動作
の少なくとも１つをサポートするように構成されている
ことを特徴とする装置。
前記ネットワーク管理スキーマは、時刻に依存して修正されるように構成されている
ことを特徴とする請求項６に記載の装置。
前記ネットワーク管理スキーマは、前記通信ネットワークシステム内で管理される前記ネットワークノード群のロケーションに依存して修正されるように構成されている
ことを特徴とする請求項６または７に記載の装置。
同一のタイプのモジュール群は、前記ネットワーク管理スキーマによって定義されるオブジェクトのクラスによって表され、
前記ネットワーク管理スキーマは、オブジェクトのクラスに依存して修正されるように構成されている
ことを特徴とする請求項６乃至８のいずれか１項に記載の装置。
前記ネットワーク管理スキーマは、前記モジュール群のそれぞれに依存して修正されるように構成されている
ことを特徴とする請求項６乃至９のいずれか１項に記載の装置。