JP4387599B2 - 電気通信ネットワーク・リソース取り扱い装置および方法 - Google Patents

Description

【０００１】
（技術分野）
本発明は、電気通信ネットワークを管理する動作支援構造において用いて、ネットワーク・リソースに関する情報を収容するサービスおよびリソース・データベース装置を備えたリソース・ハンドラに関する。また、本発明は、かかる動作支援構造において用いるリソース・ハンドラ・データベース装置において情報を構築する方法に関する。更に、本発明は、電気通信ネットワーク用動作支援構造において、サービス種別処方およびそれらの関係を作成し管理するサービス種別ハンドラのリソース・ハンドラの使用に関する。
【０００２】
（技術の現状）
電気通信用動作支援システムにおいては、この種のネットワークの規模および複雑性のため、リソース管理が困難である。通常、電気通信ネットワークは、新たなリソース／サービスが追加される毎に、そして古い余分なリソース／サービスを除去または交換する毎に、常に変化している。多くの場合、有用／冗長リソースに関する情報の欠如のため、特定のサービスまたはネットワークに対して幾重にも二重化するという無駄な処置が取られている。最新情報の欠如およびそのための二重化は、ネットワーク運営業者の管理コストを一層押し上げることになる。場合によっては、冗長なリソースが実際に利用可能な場合もあるので、リソースの投資が不要となることもある。もはや実際に用いられていない古いサービスや、他のリソースを用いる新しいサービスと既に交換された古いサービスで使用されているリソースもあり得ると考えられる。
【０００３】
例えば、米国特許第５，６４０，５０５号に電気通信ネットワーク用動作支援構造が記載されている。この支援構造は、一組のドメインに分割され、その各々がネットワークに特定の管理機能を設ける。この文献は、一般的な支援構造を教示するが、かかる構造を実施するための詳細については殆ど何も提示していない。したがって、二重化を回避するためにはネットワーク・リソースをいかに扱うかという問題に対する明確な解決策はない。
【０００４】
ＥＰ−Ａ−０８２０２０３は、電気通信ネットワークにおいてリソースを利用する方法および装置を示す。しなしながら、この装置／方法は、様々な理由で満足できるものではない。例えば、リソースが存在する時間を、例えば、満足に考慮していない。これを行なうためには、例えば、存在時間に関する情報を含む属性を追加しなければならない。しかしながら、行なう価値があるようにするには、あらゆるリソースに対して、これを行なわなければならず、著しい性能の低下を招く。
【０００５】
更に、これは、全く新しい属性を追加するという問題に対する解決策を与えていない。また、任意のプロセスが用いることができず、オブジェクト指向のＳＤＩ−プロセスを支援するように特定して設計されているという欠点もある。ＥＰ−Ａ−０８２０２０３の解決策には、十分な柔軟性がない。
【０００６】
理想的には、サービスおよびリソース・データベースは、電気通信機器およびネットワーク・トポロジについて、既存のあらゆる形式および今後のあらゆる形式を単純なデータ・モデルで表わすことができ、任意のネットワークのリソースを管理できるようにしなければならない。
【０００７】
（発明の概要）
本発明の目的の１つは、任意のプロセスが使用可能で柔軟性のあるリソース・ハンドラおよびこれに関係する方法を提供することである。別の目的は、動作時の新たな属性並びに新たなサービス種別および新たなリソース種別を容易に（好ましくは動的に）追加できるようにすることである。特に、透過的および非透過的な特性で機器のモデル化および取り扱いを可能にすることを目的とする。
【０００８】
本発明の第１の態様によれば、電気通信ネットワークを管理する動作支援構造において用い、ネットワーク・リソースに関する情報を収容するサービスおよびリソース・データベース装置を備えたリソース・ハンドラを提供する。データベース装置は、ネットワーク内の各リソースが存在時間および場所を親／子関係の階層状で有するように構築する。リソースは、以下のデータによって、即ち、
その機能の抽象的記述の形態で特性が関連付けられているポイント識別子と、
共に属すると見なされる一群のポイントの意味における共通ネットワーク・エレメントの抽象化と、
２つの接続したポイントにより規定する接続と、
によって定義する。
【０００９】
好ましくは、ポイント識別子は、ラベル／値対のリストという形態でも特性が関連付けられている。
本発明の有利な一実施形態によれば、エレメント上のポイントは、相互接続が可能であるという暗示的特性を有してエレメントは、ポイントのコンテナとして作用する。
データベース装置は、トポロジ・ビュー、即ち、どのようにリソース同士を接続するかについてモデル化を行うように構築するとよい。また、これは、時間ビュー、例えば、いつリソースが存在するかについてモデル化を行うように構築してもよい。
【００１０】
また、階層ビュー、即ち、リソースを親／子関係において、どのように関係付けるかについてモデル化を行うようにデータベース装置を構築してもよい。更に、データベース装置は、特性ビューを例えば、各リソースの特性のリストによってモデル化するように構築してもよい。更に、データベースは、使用ビュー、即ち、どのリソースを組合わせて完全なサービス・インスタンスを形成するか、および当該サービス・インスタンスが存在する時間についてモデル化するように構築してもよい。
【００１１】
好ましくは、トポロジ・ビュー、時間ビュー、階層ビュー、特性ビューおよび使用ビューをデータ・モデルに統合化し、各リソースの制御およびその使用をサービス・インスタンスにおいて可能とする。
好ましくは、データベース装置は、第１の別個のデータベースと第２の別個のデータベースとから成る。データベースの一方は、リソース種別およびリソース・インスタンスのために用いられ、データベースの他方は、サービス種別およびサービス・インスタンスのために用いられる。
【００１２】
本発明の第２の態様によれば、電気通信ネットワークを管理するために、動作支援構造において用いるリソース・ハンドラ・データベース装置における情報構築方法を提供する。この方法は、
ネットワークにおける各リソースに存在時間および場所を親／子関係の階層状に割当てるステップと
各リソースを、以下のデータにより、即ち、
その機能の抽象的記述の形態で特性が関連付けられているポインタ識別子と、
共に属すると見なされる一群のポイントの意味における共通ネットワーク・エレメントの抽象化と、
２つの接続したポイントで規定する接続と、
により定義するステップとから成る。
【００１３】
本発明の第３の態様によれば、電気通信ネットワーク用動作支援構造におけるサービス種別ハンドラに対して、サービス種別処方およびそれらの関係を作成し維持するリソース・ハンドラの使用を提供する。
【００１４】
好ましくは、サービス種別処方は、サービス種別に対するフレームワークと、サービス種別に関する動作と、サービス種別に関するパラメータと、サービス種別間の階層関係と、階層パラメータ関係と、サービス種別および関連するパラメータ値のリソース要件およびサービス種別要件への変換を与える。
【００１５】
サービス種別ハンドラは、異なる種別の要求サービス、異なる種別の要求リソースおよび異なるサービス・インスタンス間で選択を行うために用いることができる。
選択したリソース要件をリソース・ハンドラに転送し、実際のリソース割当てを行うと有利である。
【００１６】
（図面の簡単な説明）
以下に、添付図面を参照しながら非限定的に本発明について説明する。
【００１７】
（発明の詳細な説明）
電気通信システムには、多くの面があるので、情報の構造は、製品／サービス種別および製品／サービス・インスタンス間の相互作用に対して、細分化しなければならない。例えば、製品／サービス種別およびそれらの製品／サービス・インスタンスおよび／またはリソースに対する参照への変換を処理するシステムの一部分、製品／サービス種別および製品／サービス種別価格決定に関する情報を纏める第２部分、製品／サービス・インスタンスのための第３部分ならびにデータ操作のために全ての手順コードを追跡する第４部分を有することができる。
【００１８】
この基本的モデル化理念を図１に示す。これは、４つの基本エリア（ドメイン）、即ち、製品／サービス種別、製品／サービス・インスタンス、リソース種別およびリソース・インスタンスから成る。種別エリアは、図面および設計仕様を置いてあるところと見なし、インスタンス・エリアは、原料および完成した製品／サービスが位置するところと見なす。したがって、製品／サービスの種別および製品／サービスのインスタンス間ならびにリソース種別およびリソース・インスタンス間で明確に区別することは、非常に大切である。
【００１９】
各製品／サービス種別は、名称、パラメータ、改訂レベルおよび挙動によって定義される。したがって、製品／サービス種別は、製品／サービス・インスタンスに対するパラメータ化したテンプレートと見なすことができる。各製品／サービス種別には、１回以上の改訂が行われている。製品／サービス種別は、他の製品／サービス種別で構成される場合もあるので、一部の製品／サービス種別は、親／子関係の階層に置かれる。製品／サービス種別は、それが一部をなす製品種別について知識を有さないことは、至極、重要である。それが構成する製品／サービス種別に関するものを知っている場合はある。１つの親製品／サービス種別は、１つまたは数個の子製品種別に分岐する可能性を有する。
【００２０】
製品／サービス・インスタンスは、製品／サービスの実現であり、全てのパラメータ値がそれらの最終的な値にセットされている。製品／サービス種別は、階層を有するので、製品／サービス・インスタンスも階層を有していなければならない。製品／サービス・プロセスは、製品／サービス種別が参照する手順である。これは、製品／サービス・インスタンスをいかに操作するかについて正確で完全な命令を含む。
【００２１】
リソースの概念を用いるのは、システム内における「実際の」もの全てに対する概念を有するためである。２つのもの、リソースの作成、即ち、新たな電話回線の敷設およびリソースの割当て、即ち、例えば、既存の電話回線の状態を不使用から使用中に変更することの間で区別することは、非常に重要である。
【００２２】
リソース種別は、製品種別を実装するために必要なリソースの抽象的記述のアイデンティティである。子を有する製品／サービス種別は、リソース種別に対する参照を有することができる。子を有さない製品／サービス種別は、リソース種別に対する参照を有していなければならない。
【００２３】
リソース・インスタンスは、リソース種別の実際のインスタンス化である。子を有する製品／サービス・インスタンスは、リソース・インスタンスに対する参照を有することができる。子を有さない製品／サービス・インスタンスは、リソース・インスタンスに対する参照を有していなければならない。
【００２４】
エレメント、ポイントおよび接続間の関係を図２に示す。これは、電気通信ネットワークの抽象的模式図である。図２における各正方形は、エレメント１０を表わし、ドットは、ポイント１１であり、太線は、接続１２である。左下のエレメント内にある細線も接続であり、エレメント内に書き込むために線幅を狭くしただけである。これは、本発明によるリソース種別およびインスタンス・データベース（ＳＲＤＢ）において、リレーショナル・データベースのテーブルの形態で表わされている。
【００２５】
ＳＲＤＢを有することは、電気通信ネットワーク、その部品、それらの能力、部品の接続方法、部品を使用する人、部品を使用するとき等を記述する定型的かつ抽象的モデルを有することである。ＳＲＤＢ内に存在するのは、エレメント、これらのエレメント上のポイント、各ポイントの能力／属性およびポイントの接続方法のリストである。これらのリスト（データベース・テーブルの形態）には、どのような機器が存在するか（いつ存在するか）、何をすることができるか、誰かが用いているかに関する情報が満たされている。
【００２６】
ポイント１１は、実際の世界では、ポート、終点、外部アクセス・ポイント、結合ポスト等のような多くの名称で知られている。ＳＲＤＢでは、これらは１つの概念、即ち、本質的に識別子であるポイントに抽象化されている。異なる種別のポイント間で区別するために、各ポイントは、その能力の定型的抽象記述である種別を有していなければならない。ポイント種別は、１つまたは数個の機能を有することができる。ポイントは、常にあるエレメントに属していなければならず、それ自体だけで存在することはできない。
【００２７】
エレメント１０は、本質的に共に属すると考えられるポイントの集合である。エレメントになるには、それに付随するポイントは、互いに対して完全な接続性を有していなければならない。即ち、いずれのポイントでも、同じエレメント内にある他のあらゆるポイントに相互接続できなければならない。ポイントの機能／属性種別は、相互接続を可能にするために同じ機能／属性が双方のポイント上に存在しなければならないという要件を有するため、接続性が多少制限される場合もある。
【００２８】
接続は、あるポイントが他のポイントに接続されていることを通知する重要な情報である。実際には、これは一対のポイントである。基本的に２種類の接続、インフラストラクチャ接続、即ち、ワイヤおよび制御可能な相互接続がある。
【００２９】
機能は、属性の集合である。各属性は、本質的に、パラメータの名称およびパラメータの値から成る対である。これは、ポイント種別の特性を記述する規定の方法である。
【００３０】
サービス・インスタンスは、それが用いるリソースに関する共通データ全てをそれ自体の中に有するエンティティであり、これらのリソースに対する参照を有する。
【００３１】
特に、属性は、ポイントに接続されるだけであり、関係は、ポイントをエレメントに接続するため、およびポイントを接続に接続するために用いられる。しかしながら、エレメントおよび接続上には、いくつかの固定属性もある場合がある。これらは、非常に注意深く選択される。何故なら、存在時間、リソースの名称等のように、常に、そこになければならないからである。要点は、オプションのまたはいずれの属性も、エレメントまたは接続に接続する可能性が全くないということである。代わりに、全ての特徴的構造がポイント内にあり、任意の数の属性に対する接続を与えることができる。実際には、エレメントは、ポイントを接続することができる「プレース・ホルダ」として機能するに過ぎない。接続の機能も同様である。即ち、それらの機能は、２つのポイントが接続されていることを示すことである。
【００３２】
更に、本発明のデータベース装置では、あらゆるリソース（エレメント、ポイント、接続）が存在時間を有することが好ましく、時間の意味に関する意識を強く強調する。
【００３３】
特定的な実施態様の１つでは、データベース装置は、必要であれば、規則的なコード（例えば、Ｃ、ＪａｖａＴＭ）の使用を可能にするフィールドを設けることができ、これによって高い柔軟性が得られる。本発明によれば、あらゆるリソースが必ずしも（明示的な）接続を有する訳ではない。
【００３４】
本発明の最も有利な実施態様では、異なる種別の属性の間で区別することが可能であり、第１に、オブジェクトを「種別化」すること、第２に、前記種別の間で区別できることを意味する。少なくとも、種別「透過性」および種別「非透過性」の属性間で区別することが好ましい。非透過性属性を有するリソースの一例は、電子メールのアカウントである。これは、メモリを有するが、例えば、帯域幅のような透過性属性を有さない。属性の「種別化」によって、透過性および非透過性特性双方を有する機器、即ち、原則的にサーバのような電気通信ネットワークの一般的範囲に該当しない機器をモデル化し管理することが容易となる。
【００３５】
エレメント１０、ポイント１１および接続１２が子を有することができる、即ち、これらが内部構造を有することができる形態でＳＲＤＢにおける多くの場所で階層の概念が用いられている。これについて、テーブル内における親／子関係の形態で説明する。好ましくは、本発明によれば、モデルは、エレメント、ポイントおよび接続において親／子関係双方を有する明確な階層である。
【００３６】
図３は、システム環境を示し、サービス構成（ＳＣ）は、主に、実行エンジン１３、上流システム通信用サービス要求プロセッサ（ＳＲＰ）１４、下流システム通信用ネットワーク・エレメント・プロセッサ（ＮＥＰ）１５、ネットワーク・リソースに関する情報のためのリソース種別およびインスタンス・データベース（ＳＲＤＢ）１６ならびにサービス種別およびインスタンス階層のためのサービス種別およびインスタンス・データベース（ＳＴＤＢ）１７から成る。図５が参照される。内部的には、実行エンジン１３は、サービス実行要求マネージャ（ＳＡＲＭ）１８、自動サービス実行プログラム（ＡＳＡＰ）の一部ならびにサービスおよびリソース・インスタンス・マネージャ（ＳＲＩＭ）１９によって構成されている。
【００３７】
本発明の特に有利な実施態様では、データベース装置は、２つのデータベース（ＳＲＤＢおよびＳＴＤＢ）に分離され、その一方、ＳＲＤＢは、リソース種別およびリソース・インスタンスを収容し、その他方、ＳＴＤＢは、サービス種別およびサービス・インスタンスを収容する。
【００３８】
ＳＴＤＢおよびＳＲＤＢ間の接続は、データベース装置の外部使用のために、どの属性が求められているかについてのメッセージがサービス種別およびインスタンス部（ＳＴＤＢ）（ダウン）からリソース種別およびインスタンス部（ＳＲＤＢ）に送られるようにしている。したがって、これは非常に疎な結合である。このように疎な結合、即ち接続を用いる意図は、サービス種別に伴う複雑性がときとして望ましくない場合があるからである。代わりに、「生の」即ち「純粋な」リソース種別／インスタンスがデータベース装置のリソース部（ＳＲＤＢ）から直接得ることができる。
【００３９】
先に述べたようなデータベース装置の分離によって、リソース部では未だ定義されていないリソース種別（新たな属性を有する）を用いて、サービス種別を定義することが可能となる。
【００４０】
図５を参照すると、ＳＴＤＢ１７は、特定のサービス種別をリソースにどのように変換するかに関する全ての情報を収容しており、新たなサービス・インスタンスの作成が可能である。ＳＲＤＢ１６は、ＳＣの情報源および保管場所である。
【００４１】
情報の流れを簡略化して見ると、共通サービス記述レイヤ（ＣＳＤＬ）コマンドがＳＲＰ１４からＳＡＲＭ１８に送られ、ここで原子サービス記述レイヤＡＳＤＬコマンドに変換され、ＳＲＩＭ１９に送出される。すると、ＳＲＩＭは、ＳＴＤＢ１７およびＳＲＤＢ１６に追加の情報を要求し、これを用いて新たなＣＳＤＬコマンドを作成する。このコマンドは、ＡＳＤＬコマンドに変換され、ＮＥＰ１５に送出される。原則的に、ＮＥＰからの応答は、同じ道を逆方向に辿り、リターン・ステータスおよびデータを用いてＳＲＤＢ１６を更新する。
【００４２】
ここで、ＤｕｏＣｏｍインスタンスの作成をデータ構造において、どのように情報を用いるかという例として用いる。製品ＤｕｏＣｏｍは、副製品ＩＳＤＮアクセス、Ｅ−メール、個人ホーム・ページおよび０２０−接続から成ると想定する。これら５つの製品は、関連する全てのパラメータ、パラメータ値、リソース定義、リソースの位置、製品情報、製品種別コスト、改訂レベル等およびこれらに伴う供給制御と共に、製品種別データ構造に入れられると考えられる。
【００４３】
ステップ０は、イニシエータ、恐らく、顧客ケア・システムが（いずれかの都合のよいときに）、オペレータ製品ポートフォリオ（ＯＰＰ）にアクセスし、少なくとも利用可能な製品の名称を知る。エンド・ユーザが顧客ケア・システムと連絡を取ると、顧客には製品／サービス種別のリストが与えられ、ここから選択を行う。この場合、ＤｕｏＣｏｍ製品に関心があるため、製品／サービス種別に関するより多くの情報を要求する。
【００４４】
ステップ１において、ＯＰＰは、製品名および製品情報がパラメータとして求められているという事実を用いることによって、製品／サービス種別情報テーブルを調べ、情報の全内容およびどこでそれを見つけるかを突き止める。
【００４５】
ステップ２において、顧客がこの製品を望んでいると想定すると、続いて製品を引用するが、これがサービスもカバーしていることを明確にしなければならない。実現可能性チェックを行い、既存の条件で製品を実施可能か否か、即ち、全ての前提条件が満たされているか否かチェックする。ここで、このコードに対する「コール」を行う。実行が開始すると、このコードは、製品種別を用い、これを入力して製品種別階層を調べる。ここを調べることによって、ＤｕｏＣｏｍ製品がどのような（副）製品で構成されているか解明することができる。この場合、４つの製品種別、ＩＳＤＮアクセス、Ｅ−メール、個人ホーム・ページおよび０２０−接続が見つけられる。一方、これらが更に一層単純な製品で構成されている場合があるので、再度、製品種別階層を調べ、もはや別の製品種別が見つからなくなるまで、新たな製品が副製品を有するか否か見ていく。
【００４６】
（副）製品の一部はオプションである可能性もある、即ち、最終顧客に、（副）製品を望んでいるか尋ね、可能な選択について知らせなければならない。このため、双方向処理ループが形成され、その中で顧客は所望の（副）製品を選び出す。これらの（副）製品が選択されると、製品種別動作パラメータおよび製品種別パラメータ・テーブルを調べ、どのパラメータが必要か見つけ出す。この（副）製品の選択は、その性質上、動的であるので、製品種別関係テーブルを調べ、適合性のない製品種別の組合わせが偶然作成されていないことをチェックする。このループが終了したとき、製品種別前提条件および製品種別リソース前提条件テーブルを製品インスタンス・データおよびリソース・データに関して、十分な量のリソースおよび既存の製品インスタンスが入手可能か否か調べるので、この新たな製品インスタンスをインスタンス化することが可能となる。
【００４７】
ステップ３において、製品種別コストおよび製品種別階層テーブルを調べ、個々の（副）製品全てについてコストを求める。しかしながら、この情報を顧客のために解釈しカスタム化することは、顧客ケア・システムに委ねられる。この価格システムは、国内通貨の場合があり、顧客ケア・システムは、この通貨を現地通貨に換算することができる。
【００４８】
ステップ４において、実施が可能であるという現実可能性が示された場合、作成したインスタンス指令を発行することができる。即ち、実現可能性から全てのデータを取り込み、１つまたは数個の製品インスタンス化指令を作成する。これは、１つ以上の製品発注を製品発注テーブルに挿入し、製品インスタンス・テーブル内に製品インスタンスのツリーを形成する。
【００４９】
ステップ５において、配送時刻が来たときに、最終的に供給プロセッサにまかせて、製品を具体化する。即ち、製品インスタンス階層において製品インスタンスを詳細に調べ、全てのデータを読み出し、基盤のリソース・マネージャに命令を与え、予約したリソースを始動させる。
【００５０】
リレーショナル・データベースに全てのデータを格納する。図４を参照すると、これらに関係する各テーブルには、テーブル名およびフィールドのみが示されている。テーブルは、ＳＱＬコマンドを用いて標準的なテキスト・ファイルから読み出すことによって作成することができる。
【図面の簡単な説明】
【図１】 製品（サービス）インスタンス／種別およびリソース・インスタンス／種別間の概念の関係を模式的に示す図。
【図２】 エレメント、ポイントおよび接続間の関係を模式的に示す図。
【図３】 サービス構成のサービスおよびリソース・データベース装置のシステム環境を示す図。
【図４】 サービスおよびリソース・データベース装置の関係構造を示すブロック図。
【図５】 テーブル関係および製品種別定義を示す図。

Claims (26)

1. 電気通信ネットワークを管理する動作支援構造において用い、ネットワーク・リソースに関する情報を収容するサービスおよびリソース・データベース装置を備えたリソース・ハンドラであって、
   前記電気通信ネットワーク内の各リソースが存在時間および場所を親／子関係の階層状で有するように前記リソース・データベース装置を構築し、
   前記リソースを以下のデータによって、即ち、
   その機能の抽象的記述の形態で特性が関連付けられているポイント（１１）識別子と、
   共に属すると見なされる一群のポイント（１１）の意味における共通ネットワーク・エレメント（１０）の抽象化と、
   ２つの接続したポイント（１１）により規定する接続（１２）と、によって定義することを特徴とするリソース・ハンドラ。
2. 請求項１記載のリソース・ハンドラにおいて、前記ポイント（１１）識別子は、ラベル／値対のリストという形態でも特性が関連付けられていることを特徴とするリソース・ハンドラ。
3. 請求項１または２記載のリソース・ハンドラにおいて、前記エレメント（１０）は、ポイント（１１）のコンテナとして作用し、エレメント（１０）上のポイント（１１）は、相互接続が可能であるという暗示的特性を有することを特徴とするリソース・ハンドラ。
4. 請求項１から３のいずれか１項に記載のリソース・ハンドラにおいて、前記リソース・データベース装置をトポロジ・ビュー、例えば、どのようにリソース同士を接続するかについてモデル化を行うように構築することを特徴とするリソース・ハンドラ。
5. 請求項１から４のいずれか１項に記載のリソース・ハンドラにおいて、前記リソース・データベース装置を時間ビュー、例えば、いつ前記リソースが存在するかについてモデル化を行うように構築することを特徴とするリソース・ハンドラ。
6. 請求項１から５のいずれか１項に記載のリソース・ハンドラにおいて、前記リソース・データベース装置を階層ビュー、例えば、リソースを親／子関係において、どのように関係付けるかについてモデル化を行うように構築することを特徴とするリソース・ハンドラ。
7. 請求項１から６記載のいずれか１項に記載のリソース・ハンドラにおいて、特性ビューを例えば、各リソースの特性のリストによってモデル化するように前記リソース・データベース装置を構築することを特徴とするリソース・ハンドラ。
8. 請求項１から７のいずれか１項に記載のリソース・ハンドラにおいて、前記リソース・データベース装置を使用ビュー、即ち、どのリソースを組合わせて完全なサービス・インスタンスを形成するか、および当該サービス・インスタンスが存在する時間についてモデル化するように構築することを特徴とするリソース・ハンドラ。
9. 請求項４から８記載のリソース・ハンドラにおいて、前記トポロジ・ビュー、前記時間ビュー、前記階層ビュー、前記特性ビューおよび前記使用ビューをデータ・モデルに統合化し、各リソースの制御およびその使用をサービス・インスタンスにおいて可能とすることを特徴とするリソース・ハンドラ。
10. 請求項１から９のいずれか１項に記載のリソース・ハンドラにおいて、前記リソース・データベース装置をリソース種別およびリソース・インスタンスを収容する第１のデータベースと、サービス種別およびサービス・インスタンスを収容する第２のデータベースとに分離することを特徴とするリソース・ハンドラ。
11. 請求項１から１０のいずれか１項に記載のリソース・ハンドラにおいて、リソースおよび／サービス属性を種別化し、前記種別化によって属性種別間の区別を可能とすることを特徴とするリソース・ハンドラ。
12. 電気通信ネットワークを管理するためにネットワーク・リソースに関する情報を収容するサービスおよびリソース・データベース装置を備える動作支援構造において用いるリソース・ハンドラ・データベースにおける情報構築方法であって、
    前記電気通信ネットワークにおける各リソースに存在時間および場所を親／子関係の階層状に割り当てるステップと、
    前記各リソースを以下のデータによって、即ち、
    その機能の抽象的記述の形態で特性が関連付けられているポイント（１１）識別子と、
    共に属すると見なされる一群のポイント（１１）の意味における共通ネットワーク・エレメント（１０）の抽象化と、
    ２つの接続したポイント（１１）により規定する接続（１２）と、によって定義するステップと、を特徴とする方法。
13. 請求項１２記載の方法において、ラベル／値対のリストという形態で前記ポイント（１１）識別子を特性と関連付けるステップを特徴とする方法。
14. 請求項１２または１３記載の方法において、エレメント（１０）上のポイント（１１）は、相互接続が可能であるという暗示的特性を有して前記エレメント（１０）をポインタ（１１）のコンテナとして作用させるステップを特徴とする方法。
15. 請求項１２から１４のいずれか１項に記載の方法において、トポロジ・ビュー、例えば、どのようにリソース同士を接続するかについてモデル化を行うように前記リソース・データベース装置を構築するステップを特徴とする方法。
16. 請求項１２から１５のいずれか１項に記載の方法において、時間ビュー、例えば、いつ前記リソースが存在するかについてモデル化を行うように前記リソース・データベース装置を構築するステップを特徴とする方法。
17. 請求項１２から１６のいずれか１項に記載の方法において、階層ビュー、即ちリソースを親／子関係において、どのように関係付けるかについてモデル化を行うように前記リソース・データベース装置を構築するステップを特徴とする方法。
18. 請求項１２から１７記載のいずれか１項に記載の方法において、特性ビューを、例えば、各リソースの特性のリストによってモデル化するように前記リソース・データベース装置を構築するステップを特徴とする方法。
19. 請求項１２から１８のいずれか１項に記載の方法において、使用ビュー、即ち、どのリソースを組合わせて完全なサービス・インスタンスを形成するかについて、および当該サービス・インスタンスが存在する時間についてモデル化するように前記リソース・データベース装置を構成するステップを特徴とする方法。
20. 請求項１５から１９記載の方法において、前記トポロジ・ビュー、前記時間ビュー、前記階層ビュー、前記特性ビューおよび前記使用ビューをデータ・モデルに統合化し、各リソースの制御およびその使用をサービス・インスタンスにおいて可能とするステップを特徴とする方法。
21. 請求項１２から２０のいずれか１項に記載の方法において、
    前記リソース・データベース装置を２つの別個のデータベースに分離するステップと、
    前記別個のデータベースの一方にリソース種別データおよびリソース・インスタンス・データを収容するステップと、
    前記別個のデータベースの他方にサービス種別データおよびサービス・インスタンス・データを収容するステップと、を含むことを特徴とする方法。
22. 請求項１２から２０のいずれか１項に記載の方法において、
    リソースおよび／またはサービス属性に種別を割り当てるステップと、
    前記属性種別を用いて異なる属性種別間の区別を行うステップと、を含むことを特徴とする方法。
23. 電気通信ネットワーク用動作支援構造におけるサービス種別ハンドラに対してサービス種別処方およびそれらの関係を作成し維持する請求項１から１１のいずれか１項に記載のリソース・ハンドラの使用。
24. 請求項２３記載の使用において、前記サービス種別処方は、サービス種別に対するフレームワークと、サービス種別に関する動作と、サービス種別に関するパラメータと、サービス種別間の階層関係と、階層パラメータ関係と、サービス種別および関連するパラメータ値のリソース要件およびサービス種別要件への変換を与える使用。
25. 請求項２３および２４のいずれか１項に記載の使用であって、異なる種別の要求サービス、異なる種別の要求リソースおよび異なるサービス・インスタンス間で選択を行うための使用。
26. 請求項２５記載の使用において、前記選択したリソース要件をリソース・ハンドラに転送し、実際のリソース割当てを行う使用。

Images