(57)【要約】【課題】   アクセスネットワークとメトロネットワークのように互いに異なるネットワークを制御、管理するための統合ネットワーク制御システム及びその方法を提供する。【解決手段】第１端末が第２端末とのＶｏＩＰ通話のために呼設定を要請する段階と、第１、第２端末が各々属するアクセスネットワークの可用帯域幅情報と、アクセスネットワークに連結（link）されたメトロネットワークの可用帯域幅情報と、を収集する段階と、アクセスネットワーク及びメトロネットワークの可用帯域幅が前記ＶｏＩＰ通話のための帯域幅よりも大きい場合に、前記呼設定要請を許可する段階と、を備えるＶｏＩＰ通話制御方法を提供することによって、複合ネットワークの資源状態及び性能状態を持続的に制御することができ、ユーザに高品質且つ大容量のサービスのＱｏＳを保証できる。【選択図】  図３
2007195181.tif 000002
【特許請求の範囲】
【請求項１】
異種ネットワークに属する第１、第２端末間のＶｏＩＰ（Voice over Internet Protocol）通話を制御する方法であって、
第１端末が第２端末とのＶｏＩＰ通話のために呼設定を要請する段階と、
前記第１、第２端末が各々属するアクセスネットワークの可用帯域幅情報と、前記アクセスネットワークに連結（link）されたメトロネットワークの可用帯域幅情報と、を収集する段階と、
前記アクセスネットワーク及びメトロネットワークの可用帯域幅が前記ＶｏＩＰ通話のための帯域幅よりも大きい場合に、前記呼設定要請を許可する段階と、
を備えることを特徴とするＶｏＩＰ通話制御方法。
【請求項２】
前記可用帯域幅情報を用いて前記異種アクセスネットワーク間を相互に連結（link）する最適の仮想経路（Virtual Path）を把握し、当該仮想経路を用いて前記第１、第２端末間に呼を接続する段階をさらに備えることを特徴とする請求項１に記載のＶｏＩＰ通話制御方法。
【請求項３】
前記呼設定要請による呼設定が完了した後に、前記第１、第２端末が属するアクセスネットワーク及び前記メトロネットワークの可用帯域幅情報をアップデートする段階をさらに備えることを特徴とする請求項１に記載のＶｏＩＰ通話制御方法。
【請求項４】
前記ネットワークの可用帯域幅が不足した場合に、可用帯域幅が不足したネットワークの個々の複数のクラスに帯域幅を再割当する段階をさらに備えることを特徴とする請求項１に記載のＶｏＩＰ通話制御方法。
【請求項５】
少なくとも一つのアクセスネットワークとメトロネットワークとを含む複合ネットワークの管理システムであって、
前記複合ネットワークの資源情報を収集して管理するための資源管理モジュールと、
前記アクセスネットワークまたはメトロネットワークへ転送される呼を認証する限界ネットワーク資源と該限界ネットワーク資源に関しての政策とを決定するための政策決定モジュールと、
前記複合ネットワークの資源情報と限界ネットワーク資源とを比較し、複合ネットワークへ転送される呼認証要請を許可すべきか否かを判断する呼処理モジュールと、
を備えることを特徴とする複合ネットワーク管理システム。
【請求項６】
前記ネットワーク資源は、ネットワークのトポロジー（Topology）、帯域幅（Bandwidth）、遅延時間（Delay Time）、遅延分散（Delay Variance）のうち少なくとも一つを含む
ことを特徴とする請求項５に記載の複合ネットワーク管理システム。
【請求項７】
前記アクセスネットワークは、ＡＯＮ（Active Optical Network）タイプＦＴＴＨ（Fiber to the Home）、ＰＯＮ（Passive Optical Network）タイプＦＴＴＨ、ワイブロ（Wibro）ネットワーク、無線ラン（ＷＬＡＮ）のうち少なくとも一つを含む
ことを特徴とする請求項５に記載の複合ネットワーク管理システム。
【請求項８】
前記政策決定モジュールから受信した政策を前記各ネットワーク別に解析可能なプロトコルに変換し、該変換されたプロトコルを各ネットワークへ転送する政策インタフェースモジュールをさらに備える
ことを特徴とする請求項５に記載の複合ネットワーク管理システム。
【請求項９】
前記政策インタフェースモジュールは、管理情報ベース（ＭＩＢ：Management Information Base）を用いて政策を適用する対象となる対象ネットワークを把握し、当該対象ネットワークにより解析可能なＣＬＩ（Command Line Interface）命令語またはＳＮＭＰオブジェクト（Simple Network Management Protocol Object）を生成する
ことを特徴とする請求項８に記載の複合ネットワーク管理システム。
【請求項１０】
前記複合ネットワークのトラフィック状態を測定し、該測定されたトラフィックが限界ネットワーク資源を超過する場合に、これを前記政策決定モジュールに通知するトラフィック監視モジュールをさらに備える
ことを特徴とする請求項５に記載の複合ネットワーク管理システム。
【請求項１１】
前記複合ネットワークを構成する装置のエラー発生の有無を監視し、エラーが発生した場合に、これを政策決定モジュールに通知するエラー管理モジュールをさらに備える
ことを特徴とする請求項５に記載の複合ネットワーク管理システム。
【請求項１２】
前記複合ネットワークを構成する各装置の性能情報を収集し、前記装置の性能にエラーが発生した場合に、これを政策決定モジュールに通知する性能管理モジュールをさらに備える
ことを特徴とする請求項５に記載の複合ネットワーク管理システム。
【請求項１３】
前記政策決定モジュールは、前記各ネットワークからトラフィック超過、エラー発生、装置性能エラー発生に関するイベントのうち少なくとも一つのイベントを受信した場合に、これを運用者にディスプレイし、当該イベントに対応するための政策を前記政策インタフェースモジュールに伝達するイベント政策モジュールをさらに備える
ことを特徴とする請求項５に記載の複合ネットワーク管理システム。
【請求項１４】
前記資源管理モジュールは、前記メトロネットワークの資源情報を用いて異種アクセスネットワーク同士を連結（link）する最適の仮想経路を決定する仮想経路管理モジュールを備える
ことを特徴とする請求項５に記載の複合ネットワーク管理システム。
【請求項１５】
前記資源管理モジュールは、前記複合ネットワークの資源状態情報をリスト構造で格納し、前記ネットワークの資源情報が変更された場合に、前記資源状態情報をアップデートする資源管理テーブルを備える
ことを特徴とする請求項５に記載の複合ネットワーク管理システム。
【請求項１６】
少なくとも一つのアクセスネットワークとメトロネットワークとで構成された複合ネットワークを管理するネットワーク管理方法において、
前記複合ネットワークの資源情報を収集し管理する段階と、
前記アクセスネットワークまたはメトロネットワークへ転送される呼を認証する限界ネットワーク資源及び該限界ネットワーク資源に関しての政策を決定する段階と、
前記複合ネットワークの資源情報と限界ネットワーク資源とを比較し、複合ネットワークへ転送される呼認証要請を許可すべきか否かを判断する段階と、
を備えることを特徴とする複合ネットワーク管理方法。
【請求項１７】
前記決定された政策を前記各ネットワーク別に解析可能なプロトコルに各々変換し、該変換されたプロトコルを各ネットワークへ転送する段階をさらに備える
ことを特徴とする請求項１６に記載の複合ネットワーク管理方法。
【請求項１８】
前記ネットワーク資源は、ネットワークのトポロジー、帯域幅、遅延時間、遅延分散のうち少なくとも一つを含む
ことを特徴とする請求項１６に記載の複合ネットワーク管理方法。
【請求項１９】
前記アクセスネットワークは、ＡＯＮタイプＦＴＴＨ、ＰＯＮタイプＦＴＴＨ、ワイブロネットワーク、無線ランのうち少なくとも一つを含む
ことを特徴とする請求項１６に記載の複合ネットワーク管理方法。
【請求項２０】
前記複合ネットワークのトラフィック状態を測定し、該測定されたトラフィックが限界ネットワーク資源を超過する場合に、これを運用者にディスプレイする段階をさらに備える
ことを特徴とする請求項１６に記載の複合ネットワーク管理方法。
【請求項２１】
前記複合ネットワークを構成する装置のエラー発生の有無を監視し、エラーが発生した場合に、これを運用者にディスプレイする段階をさらに備える
ことを特徴とする請求項１６に記載の複合ネットワーク管理方法。
【請求項２２】
前記複合ネットワークを構成する各装置の性能情報を収集し、いずれかの装置の性能にエラーが発生した場合に、これを運用者にディスプレイする段階をさらに備える
ことを特徴とする請求項１６に記載の複合ネットワーク管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、アクセスネットワークとメトロネットワークのような相互に異なるネットワークを制御、管理するための、統合ネットワーク制御システム及び統合ネットワーク制御方法に関する。
【背景技術】
【０００２】
図１は、一般的なアクセスネットワークとメトロネットワークの構成を示すブロック図である。
【０００３】
一般的に、音声、データ、放送サービスは、それぞれ、音声網、データ網、放送網などの別途の網を介してユーザに提供されてきた。しかしながら、現在、有線・無線統合、放送／通信統合などの傾向に応じてユーザに音声、データ、放送などのサービスを単一の統合網で提供しようという次世代ネットワーク（ＮＧＮ：Next Generation Network）構築に、多くの研究や開発が行われている。
ＮＧＮにおいて、コアネットワーク（Core Network）１１は、図１に示すように、ＭＰＬＳ（Multi Protocol Label Switching）基盤として構築される見込みである。メトロネットワーク（Metro Network）１２は、ＩＰ基盤パケットネットワークとして構築される見込みである。これに対し、アクセスネットワーク１３は、様々な有線及び／又は無線のネットワークなどで構成されることが予想される。そのため、かかる多様な形態のネットワークが融合される次世代ネットワークを介して、加入者に品質保証型サービスを提供するためには、アクセス及びメトロネットワークにＱｏＳ制御管理メカニズムが導入されなければならない。
【０００４】
従来、ＩＰ基盤のアクセス及びメトロネットワークは、最大効率の概念（理念）に基づいて動作したので、ユーザにＱｏＳを保証しつつサービスを提供することができないという問題点がある。かかる問題を解決するために、例えば、ディフサーブ（Ｄｉｆｆｓｅｒｖ）や８０２．１ｐ／ｑなどのようなクラス基盤のＱｏＳメカニズムが導入されたが、初期設定後の持続的な制御管理メカニズムは反映されていない。それに加えて、多様なアクセスネットワークが各々の（互いに異なる）制御方式によって管理されるので、異種網間の通信時において、持続的なＱｏｓの保証が不可能であることが現状である。
【特許文献１】大韓民国特許出願第１９９８−７００４５９４号明細書
【発明の開示】
【発明が解決しようとする課題】
【０００５】
従って、本発明は、前述のような従来技術の問題点を解決するためになされたものであり、アクセスネットワークとメトロネットワークのように互いに異なるネットワークを制御、管理するための統合ネットワーク制御システム及びその方法を提供することにある。
【課題を解決するための手段】
【０００６】
本発明の第一の態様は、異種ネットワークに属する第１、第２端末間のＶｏＩＰ（Voice over Internet Protocol）通話を制御する方法であって、第１端末が第２端末とのＶｏＩＰ通話のために呼設定を要請する段階と、前記第１、第２端末が各々属するアクセスネットワークの可用帯域幅情報と、前記アクセスネットワークに連結（link）されたメトロネットワークの可用帯域幅情報と、を収集する段階と、前記アクセスネットワーク及びメトロネットワークの可用帯域幅が前記ＶｏＩＰ通話のための帯域幅よりも大きい場合に、前記呼設定要請を許可する段階と、を備える。
【０００７】
この場合、ＶｏＩＰ通話制御方法は、前記可用帯域幅情報を用いて前記異種アクセスネットワークを相互に連結（link）する最適の仮想経路（Virtual Path）を把握し、当該仮想経路を用いて前記第１、第２端末間に呼を接続する段階をさらに備えることができる。
【０００８】
また、ＶｏＩＰ通話制御方法は、前記呼設定要請による呼設定が完了した後に、前記第１、第２端末が属するアクセスネットワーク及び前記メトロネットワークの可用帯域幅情報をアップデートする段階、又は前記ネットワークの可用帯域幅が不足した場合に、可用帯域幅が不足したネットワークの個々の複数のクラスに帯域幅を再割当する段階をさらに備えることができる。
【０００９】
また、本発明の他の態様は、少なくとも一つのアクセスネットワークとメトロネットワークとを含む複合ネットワークの管理システムであって、前記複合ネットワークの資源情報を収集して管理するための資源管理モジュールと、前記アクセスネットワークまたはメトロネットワークへ転送される呼を認証する限界ネットワーク資源と該限界ネットワーク資源に関しての政策とを決定するための政策決定モジュールと、前記複合ネットワークの資源情報と限界ネットワーク資源とを比較し、複合ネットワークへ転送される呼認証要請を許可すべきか否かを判断する呼処理モジュールと、を備える。
【００１０】
この場合、前記ネットワーク資源は、ネットワークのトポロジー（Topology）、帯域幅（Bandwidth）、遅延時間（Delay Time）、遅延分散（Delay Variance）などを意味し、前記アクセスネットワークは、ＡＯＮ（Active Optical Network）タイプのＦＴＴＨ（Fiber to the Home）、ＰＯＮ（Passive Optical Network）タイプのＦＴＴＨ、ワイブロ（Wibro）ネットワーク、無線ラン（ＷＬＡＮ）などを含む。
【００１１】
この場合、前記政策決定モジュールから受信した政策を前記各ネットワーク別に解析可能なプロトコルに変換し、該変換されたプロトコルを各ネットワークへ転送する政策インタフェースモジュールをさらに備えることができ、この場合、前記政策インタフェースモジュールは、管理情報ベース（ＭＩＢ：Management Information Base）を用いて政策を適用する対象となる対象ネットワークを把握し、当該対象ネットワークにより解析可能なＣＬＩ（Command Line Interface）命令語またはＳＮＭＰオブジェクト（Simple Network Management Protocol Object）を生成する構成にするとよい。
【００１２】
また、ネットワーク管理システムは、前記複合ネットワークのトラフィック状態を測定し、該測定されたトラフィックが限界ネットワーク資源を超過する場合に、これを前記政策決定モジュールに通知するトラフィック監視モジュール、前記複合ネットワークを構成する装置のエラー発生可否を監視し、エラーが発生した場合、これを政策決定モジュールに通知するエラー管理モジュール、或いは、前記複合ネットワークを構成する各装置の性能情報を収集し、前記装置の性能にエラーが発生した場合に、これを政策決定モジュールに通知する性能管理モジュール、などをさらに備えることができる。
【００１３】
前記政策決定モジュールは、前記各ネットワークからトラフィック超過、エラー発生、装置性能エラー発生に関するイベントのうち少なくとも一つのイベントを受信した場合に、これを運用者にディスプレイし、当該イベントに対応するための政策を前記政策インタフェースモジュールに伝達するイベント政策モジュールをさらに備えることができる。
【００１４】
また、前記資源管理モジュールは、前記メトロネットワークの資源情報を用いて異種アクセスネットワーク同士を連結（link）する最適の仮想経路を決定する仮想経路管理モジュールを備えることができる。或いは、前記資源管理モジュールは、前記複合ネットワークの資源状態情報をリスト構造で格納し、前記ネットワークの資源情報が変更された場合に、前記資源状態情報をアップデートする資源管理テーブルを備えることができる。
【００１５】
また、本発明のさらに他の態様は、少なくとも一つのアクセスネットワークとメトロネットワークとで構成された複合ネットワークを管理するネットワーク管理方法において、前記複合ネットワークの資源情報を収集し管理する段階と、前記アクセスネットワークまたはメトロネットワークへ転送される呼を認証する限界ネットワーク資源及び該限界ネットワーク資源に関しての政策を決定する段階と、前記複合ネットワークの資源情報と限界ネットワーク資源とを比較し、複合ネットワークへ転送される呼認証要請を許可すべきか否かを判断する段階と、を備える。
【００１６】
前記ネットワーク管理方法は、前記決定された政策を前記各ネットワーク別に解析可能なプロトコルに各々変換し、該変換されたプロトコルを各ネットワークへ転送する段階をさらに備えることができる。
【００１７】
前記ネットワーク資源は、ネットワークのトポロジー、帯域幅、遅延時間、遅延分散などを意味し、前記アクセスネットワークは、ＡＯＮタイプＦＴＴＨ、ＰＯＮタイプＦＴＴＨ、ワイブロネットワーク、無線ランなどを含む。
【００１８】
本発明に係るネットワーク管理方法は、前記複合ネットワークのトラフィック状態を測定し、該測定されたトラフィックが限界ネットワーク資源を超過する場合に、これを運用者にディスプレイする段階、前記複合ネットワークを構成する装置のエラー発生の有無を監視し、エラーが発生した場合に該エラーを運用者にディスプレイする段階、或いは、前記複合ネットワークを構成する装置に対する性能情報を収集し、いずれかの装置の性能にエラーが発生した場合に該エラーを運用者にディスプレイする段階をさらに備えることができる。
【発明の効果】
【００１９】
本発明による異種アクセスネットワーク及びメトロネットワークを制御、管理するシステム及びその方法によれば、アクセスネットワーク及びメトロネットワークの資源状態及び性能状態を持続的に制御、管理することができ、ユーザに高品質且つ大容量のサービスのＱｏＳを保証することができると共に、異種網間の通信時にも持続的なＱｏＳ（Seamless Ｑｏｓ）を保証することができる。
【発明を実施するための最良の形態】
【００２０】
以下、添付の図面を参照して、本発明によるアクセスネットワークとメトロネットワークのように互いに異なるネットワークを制御、管理するための統合ネットワーク制御システム及びその方法について詳細に説明する。
【００２１】
図２は、本発明の一実施形態による統合ネットワーク制御システムを備えたネットワークの構成を示すブロック図である。
【００２２】
図２に示されたように、広域ネットワークは、アクセスネットワーク２３、ＩＰ基盤のメトロネットワーク２２、ＭＰＬＳ基盤のコアネットワーク２１などで構成されることができる。もちろん、このようなネットワークの種類及びトポロジー（Network Topology）などは、必要に応じて変更されることができる。
【００２３】
これらのうち、異種アクセスネットワーク２３の例としては、ＡＯＮ（Active Optical Network）タイプのＦＴＴＨ（Fiber To The Home）２４、ＰＯＮ（Passive Optical Network）タイプＦＴＴＨ２５、ワイブロネットワーク（Wibro Network）２６、無線ランネットワーク（ＷＬＡＮ Network）２７、などが挙げられる。ＡＯＮタイプＦＴＴＨネットワーク２４は、Ｌ２／Ｌ３スイッチ（Ｌ２／Ｌ３ Switch）と、これに接続される複数のＬ２スイッチ（Ｌ２ Switch）などからなり、ＰＯＮタイプのＦＴＴＨネットワーク２５は、ＰＯＮ  ＯＬＴ（Optical Line Termination）及びこれに接続される複数のＰＯＮ  ＯＮＴ（Optical Network Termination）で構成されることができる。また、ワイブロネットワークネットワーク２６は、制御局（ＡＣＲ：Access Route Control）と、これに接続される複数の基地局（ＲＡＳ：Radio Access Station）などからなり、無線ランネットワーク（ＷＬＡＮ）２７は、Ｌ２／Ｌ３スイッチと、これに接続される複数のアクセスポイント（Access Point）で構成される。
【００２４】
メトロネットワーク２２は、ＩＰ基盤（ＩＰ Based）のバックボーン（Backbone）網であり、一つ以上のＬ３スイッチ（Ｌ３ Switch）で構成されることができる。コアネットワーク２１は、複数のＭＰＬＳ（Multi Protocol Label Switch)スイッチで構成される。また、制御及び応用階層を担当する装置には、ソフトスイッチ５０、サーバー群６０などが挙げられる。応用階層を担当するサーバー群は、提供サービス別に各々のサーバーが存在し、図２のサーバー群６０では、ＶｏＤ（Video on Demand）サーバー、ウェブサーバー、ＤＨＣＰ（Dynamic Host Configuration Protocol）サーバー、認証サーバー(AAA: Authentication、Authorization、Accounting)などが含まれたものとなっている。
【００２５】
統合ネットワーク制御システム（ＩＮＣＰ：Integrated Network Control Platform）３０は、前述したアクセスネットワーク２３、メトロネットワーク２２などを統合的に制御、管理する本発明の核心となるシステムである。このような統合ネットワーク制御システム３０は、コアネットワーク制御プラットホーム（Core Network Control Platform）７０に連動し、コアネットワーク２１を制御する動作を行うことができる。
【００２６】
図３は、本発明の一実施形態による統合ネットワーク制御システムの内部構造を示すブロック図である。
【００２７】
統合ネットワーク制御システム３０は、政策決定モジュール（ＰＲＤ：Policy Rule Decision Module）３１、資源管理モジュール（ＴＲＭ：Topology/Resource Management Module）３２、呼処理モジュール（ＣＡＭ：Connection Admission Control Module）３４、政策インタフェースモジュール（ＰＩＭ：Policy Interface Module）３３、トラフィック監視モジュール（ＴＭ：Traffic Monitoring Module）３５、エラー管理モジュール（ＦＭ：Fault Management Module）３６、性能管理モジュール（ＰＭ：Performance Management Module）３７、ＣＬＩ（Command Line Interface）モジュール４０、ＳＮＭＰ（Simple Network Management Protocol）モジュール３９、データベース４１、コアネットワーク連動モジュール３８などで構成されることができる。
【００２８】
政策決定モジュール（ＰＲＤ）３１は、アクセスネットワーク２３及びメトロネットワーク２２を制御、管理する政策を決定し反映する機能を遂行する。特に、政策決定モジュール３１は、複合ネットワークから転送される呼に対する認証をするための限界ネットワーク資源を設定する。すなわち、政策決定モジュール３１は、限界ネットワーク資源を設定し、可用限界ネットワーク資源が限界ネットワーク資源よりも大きい場合にのみ、転送された呼を認定（許可）する、という方式で政策を決定することができる。
【００２９】
このような政策決定モジュール３１は、アクセスネットワーク政策モジュール（Access Network Policy Module）３１Ａ、メトロネットワーク政策モジュール（Metro Network Policy Module）３１Ｂ、イベント政策モジュール（Event Policy Module）３１Ｃ、内部政策モジュール３１Ｄで構成されることができる。
【００３０】
このうち、アクセスネットワーク政策モジュール３１Ａは、さらに、ＡＯＮ政策モジュール、Ｅ／Ｇ／ＷＤＭ−ＰＯＮ政策モジュール、ワイブロ政策モジュール、無線ラン政策モジュールで構成されるが、各モジュールは、対応するアクセスネットワークの政策を決定する。
【００３１】
また、メトロネットワーク政策モジュール３１Ｂは、Ｌ２／Ｌ３スイッチ政策モジュールを含む。イベント政策モジュール３１Ｃは、ＣＡＭイベント政策モジュール，ＴＲＭイベント政策モジュール，ＴＭイベント政策モジュール，ＦＭイベント政策モジュール，ＰＭイベント政策モジュールなどで構成されることができ、これらモジュールはそれぞれ、呼処理モジュール３４，資源管理モジュール３２，トラフィック監視モジュール３５，エラー管理モジュール３６，性能管理モジュール３７から通知されるイベントに対する政策を決定する。
【００３２】
内部政策モジュール３１Ｄは、運用者から入力された政策を、対応する政策モジュールに伝達する。例えば、ユーザがワイブロネットワーク２６を制御するための政策を入力した場合、内部政策モジュール３１Ｄは、アクセスネットワーク政策モジュール３１Ａ内のワイブロ政策モジュールに、該当政策を伝達する機能を担当する。
【００３３】
資源管理モジュール（ＴＲＭ）３２は、各アクセスネットワーク２３及びメトロネットワーク２２の資源状態の情報を収集、管理する。資源管理モジュール３２は、政策決定モジュール３１の政策に従ってネットワーク構成を管理するものである。ネットワークの資源（Network Resource）とは、ネットワークトポロジー（Topology）、帯域幅（Bandwidth）、遅延時間（Delay Time）、遅延分散（Delay Variance)などを総称する用語である。この場合、ネットワークトポロジーとは、バス（Bus）型、スター（Star）型、ツリー（Tree）型、リング（Ring）型などのネットワーク構成形態を意味する。
【００３４】
資源管理モジュール３２内のトポロジー管理モジュール３２Ｂ、資源管理モジュール３２Ａは、それぞれ、ネットワークのトポロジー、資源を管理する。そして、資源管理モジュール３２では、ネットワーク資源の効率的な管理及び呼処理モジュール３４の呼認証（ＣＡＣ：Call Admission Control）機能のために、Ｌ２／Ｌ３スイッチ間に仮想経路（Virtual Path）を生成し管理するが、このような経路は、仮想経路管理モジュール（Virtual Path Management Module）３２Ｃで生成、管理する。このような仮想経路は、異種ネットワーク間のデータを最適に送受信するための経路に該当する。すなわち、資源管理モジュール３２は、最適の仮想経路を予め設定しておき、異種ネットワーク間の連結（link）が必要な場合、その仮想経路を用いて最適のサービスを提供する。
【００３５】
また、資源管理モジュール３２は、アクセスネットワーク２３及びメトロネットワーク２２を構成する装置からネットワーク資源情報を収集し、資源管理テーブル（Ｔ／Ｒ Table）を生成する。このような資源管理テーブルは、リスト（List）形態のデータ構造で構成されることができ、ネットワーク資源が変更される毎に、該当情報が資源管理モジュール３２によってアップデートされる。
【００３６】
呼処理モジュール（ＣＡＭ）３４は、ＶｏＩＰなどの通話サービスやＶｏＤのような動映像サービスのための呼設定が許可されるか否かを決定する呼認証機能（ＣＡＣ）を担当する。呼処理モジュール３４は、ソフトスイッチ連動モジュール３４Ａと、マルチメディアサーバー連動モジュール３４Ｂとを含む。これらのモジュールは、それぞれ、ソフトスイッチ５０、マルチメディアサーバー６０から呼設定要請（ＣＡＣ Request）を受信する。かかる要請を受信した呼処理モジュール３４は、資源管理モジュール３２で生成した資源管理テーブル上の資源情報をデータベース４１を用いて確認した後、要請された呼設定要請について許可するか否かを決定する。
【００３７】
特に、呼処理モジュール３４は、政策決定モジュール３１により設定された限界ネットワーク資源と、データベース４１を用いて確認された現在の資源情報とを比較し、受信された呼に対して割り当てられるネットワーク資源が存在する場合に、当該呼を許可する。
【００３８】
政策インタフェースモジュール（ＰＩＭ）３３は、政策決定モジュール３１から伝送された政策をアクセスネットワーク２３及びメトロネットワーク２２の各装置に設定できるように命令語（command）を生成する。前記政策インタフェースモジュール３３は、設定された政策が適用される対象となる装置（対象装置）を把握した後に、当該対象装置を制御するためのＣＬＩ（Command Line Interface）命令語及びＳＮＭＰオブジェクト（Simple Network Management Protocol Object）を生成する。政策インタフェースモジュール３３は、ＣＬＩ及びＳＮＭＰの特性上、運用者が設定した一つの政策を多数の装置に同時に適用することができる。この理由は、政策インタフェースモジュール３３は、一つの政策に関して、装置別に命令語を各々変換して転送することができるからである。
【００３９】
トラフィック監視モジュール３５、エラー管理モジュール３６、性能管理モジュール３７は、それぞれ、ネットワークのトラフィック使用状態、エラー発生の有無及びネットワークの構成要素（network component）となる装置（以下、「ネットワーク装置」ないし単に「装置」という。）のメモリ、ＣＰＵの資源状態、を持続的に監視し管理する装置である。ＣＬＩモジュール４０、ＳＮＭＰモジュール３９は、ネットワーク装置に接続され、当該装置から情報を収集する機能を遂行する。これらの動作についてさらに詳細に説明する。
【００４０】
トラフィック監視モジュール（ＴＭ）３５は、ＳＮＭＰモジュール３９内のトラフィック収集（Traffic Gathering）モジュールを通じて各ネットワークの実際のトラフィック情報を収集することによって、各ネットワークの資源使用状態を把握する。そして、トラフィック監視モジュール（ＴＭ）３５は、当該各ネットワークの資源使用状態を資源管理モジュール３２が管理している理論的なネットワーク資源状態と比較し、問題が発生する場合にはそれを政策適用モジュール３１に通知して、ネットワーク資源割当を変更（調節）するようにする。
【００４１】
エラー管理モジュール（ＦＭ）３６は、ＣＬＩモジュール４０またはＳＮＭＰモジュール３９内のエラー発見（Fault Discovery）モジュール、ＳＮＭＰモジュール３９内のトラップ受信（Trap Reception）モジュールを通じて各ネットワークのエラー発生の有無をチェックし、エラーが発生した場合には、当該エラーの情報を資源管理モジュール３２及び政策適用モジュール３１に通知する。これにより、資源管理モジュール３２は、エラーが生じたネットワーク装置を削除するなどの作業を通じてネットワークのトポロジー及び資源情報をアップデートし、また、政策決定モジュール３１は、エラー発生事実を運用者に通知し、ネットワークエラー復旧政策を決定する。
【００４２】
性能管理モジュール（ＰＭ）３７は、ＳＮＭＰモジュール３９内に含まれた性能発見（Performance Discovery）モジュール及びトラップ受信（Trap Reception）モジュールを通じて、各ネットワーク装置の性能情報を収集する。各ネットワーク装置の性能に問題が発生した場合、性能管理モジュール（ＰＭ）３７は、当該問題（イベント）をエラー管理モジュール３６に通知し、エラー管理モジュール３６でエラー発生処理を行わせるようにする。このような過程を通じて、資源管理モジュール３２は、装置の性能状態をアップグレードし、政策決定モジュール３１は、当該アップグレードを運用者に通知し、装置の制御を行うことができるようにする。
【００４３】
ＳＮＭＰモジュール３９とＣＬＩモジュール４０は、アクセスネットワーク２３とメトロネットワーク２２の装置に接続し、かかる装置を制御するための命令語を転送し、様々な情報を送受信する装置である。通信する装置の名称に合わせて、ＳＮＭＰ３９モジュールは、ＳＮＭＰ命令を用いて通信を行い、ＣＬＩモジュール４０は、ＣＬＩ命令語を用いて通信を行う。
【００４４】
データベース４１は、統合ネットワーク管理システム３０で利用する全てのデータ、すなわち、政策情報、トポロジー及び資源情報、トラフィック情報、ログデータ、などのデータを格納する。
【００４５】
コアネットワーク連動モジュール３８は、コアネットワーク制御プラットホーム７０と連動する機能を遂行する。特に、コアネットワーク連動モジュール３８は、コアネットワーク制御プラットホーム７０を通じて呼認証機能を点対点（End to End）で処理する。
【００４６】
前述した統合ネットワーク制御システム３０を用いて帯域幅を使用したネットワーク制御、管理の例を説明する。
【００４７】
政策適用モジュール３１は、運用者により設定された政策に応じてネットワークの資源を制御するために、政策インタフェースモジュール３３に各アクセスネットワーク２３の資源分配命令を伝達する。例えば、特定のネットワーク内のリンク帯域幅が１００であり、サービスクラスが４である場合、運用者は、各サービス別に帯域幅を割り当てる政策を定義することができる。例えば、クラス０、１、２、３に、それぞれ、３０％、２０％、１５％、１０％の帯域幅を割り当てることができる。もちろん、このような帯域幅比率は、ユーザの政策によって変えることができる。
【００４８】
政策適用モジュール３１から政策（すなわちクラス別の帯域幅割当命令）を受信した政策インタフェースモジュール３３は、当該帯域幅割当命令を、ＣＬＩモジュール４０及びＳＮＭＰモジュール３９を通じて、アクセスネットワーク２３及びメトロネットワーク２２の各構成要素（装置）に伝達し、各装置により、割り当てられた帯域幅情報を修正するようになる。
【００４９】
制御しようとするネットワーク装置の帯域幅割当が完了した後、資源管理モジュール３２は、政策決定モジュール３１から帯域幅割当情報を受信したり、ＣＬＩモジュール４０またはＳＮＭＰモジュール３９を通じて帯域幅割当情報を再収集することによって、ネットワークの資源管理テーブルを完成する。また、仮想経路管理モジュール３２Ｃは、設定された帯域幅情報を用いて異種ネットワーク間における最適の仮想経路をチェックすることができる。
【００５０】
仮に、ネットワーク上に新たな装置、新たなリンクなどが生成された場合、資源管理モジュール３２は、政策決定モジュール３１にこれを通知し、また、政策決定モジュール３１は、既設定された政策によって新たな装置、新たなリンクなどの帯域幅を制御することができる。同様に、最適の仮想経路が変更された場合、これを修正し、さらに格納することができる。
【００５１】
呼処理モジュール３４は、呼設定の要請を受信し、余分（余剰）の帯域幅資源に従って、当該呼設定要請を許可するか否かを判断する。仮に、受信した呼設定要請を拒絶する場合が多くなる場合には、呼処理モジュール３４は、当該拒絶の情報を政策決定モジュール３１内のイベント政策モジュール３１Ｃに通知し、当該呼が属するクラスの帯域幅を増加させることによって、解決することができる。  
【００５２】
以下、統合ネットワーク制御システム３０の各構成要素の具体的な動作を具体的に説明する。
【００５３】
図４は、本発明の他の実施形態による政策決定モジュールの動作を示すフロー図である。
【００５４】
まず、政策決定モジュール（ＰＲＤ）３１は、運用者が入力したネットワーク政策によってアクセスネットワーク２３またはメトロネットワーク２２の構成要素(ネットワーク装置)を制御するための政策を決定する。
【００５５】
運用者は、運用者インタフェース（ＧＵＩ）４２を用いてネットワーク運用政策を入力する（ステップＳ４０１）。このように入力された政策は、データベース４１に格納され（ステップＳ４０２）、同時に政策決定モジュール（ＰＲＤ）３１に伝達される（ステップＳ４０３）。政策決定モジュール３１は、入力された運用政策を政策インタフェースモジュール（ＰＩＭ）３３に伝達する（ステップＳ４０４）。政策インタフェースモジュール３３は、データベース４１を用いて当該運用政策を行うための変数と対象装置を検索し（ステップＳ４０５）、該検索結果に応じた命令を生成する（ステップＳ４０６）。この場合、命令は、ＣＬＩまたはＳＮＭＰ  ＭＩＢを用いて生成される。生成された命令は、ＳＮＭＰモジュール３９またはＣＬＩモジュール４０へ転送され（ステップＳ４０７）、次にこれらモジュールがアクセスネットワーク２３及びメトロネットワーク２２の構成要素(装置)に当該命令を伝達する（ステップＳ４０８）。さらに、ＳＮＭＰモジュール３９またはＣＬＩモジュール４０は、政策インタフェースモジュール（ＰＩＭ）３３及び政策決定モジュール３１を通じて、運用者インタフェース４２に政策の処理結果を伝達する（ステップＳ４０９〜Ｓ４１１）。仮に、政策設定過程でエラーが発生したならば、運用者は、エラーの原因を把握した後、修正した政策をＧＵＩで入力することで、該入力された政策に従って政策決定モジュール３１が命令を検索して各ネットワーク装置に伝達することで、ネットワーク運用政策設定を再び試みることができる（ステップＳ４１２）。このように伝達された命令を通じて、運用者により入力された政策が、各ネットワークの個々の構成要素(装置)に適用されることができる。
【００５６】
また、政策決定モジュール（ＰＲＤ）３１は、運用者の政策によって統合ネットワーク制御システム３０の内部モジュールを制御、管理する役割を担う。
【００５７】
運用者は、運用者インタフェース４２を用いて、統合ネットワーク制御システム３０の内部モジュールを制御するための内部政策を設定する（ステップＳ４１３）。設定された内部政策は、データベース（ＤＢ）４１に格納され（ステップＳ４１４）、政策決定モジュール３１にも伝達される（ステップＳ４１５）。内部政策の設定過程では、ＳＮＭＰ、ＣＬＬ命令語の生成が不要なので、政策決定モジュール３１は、直接データベース４１から政策実行のための変数及び対象装置を検索する（ステップＳ４１６）。続いて、政策決定モジュール３１は、検索した対象装置に政策を伝達する（ステップＳ４１７）。例えば、政策決定モジュール３１は、呼処理モジュール（ＣＡＭ）３４、資源管理モジュール（ＴＲＭ）３２、トラフィック監視モジュール（ＴＭ）３５、エラー管理モジュール（ＦＭ）３６、性能管理モジュール（ＰＭ）３７などへ転送することができる（ステップＳ４１７Ａ〜Ｓ４１７Ｅ）。なお、ネットワーク運用政策は、全てのモジュールへ転送される必要はなく、政策が適用されるモジュールにのみ転送されることができる。
【００５８】
図５は、本発明のさらに他の実施形態による資源管理モジュールの動作を示すフロー図である。
【００５９】
資源管理モジュール（ＴＲＭ）３２の動作は、大きく、資源管理テーブルの生成及びアップデートと、仮想経路の生成及びアップデートとに区分される。
【００６０】
図４に示されたように、政策決定モジュール３１は、ネットワーク構成要素（network component）に対して政策を設定する処理（ステップＳ４０１〜Ｓ４０８）を行う。この場合、ＳＮＭＰモジュール３９またはＣＬＩモジュール４０は、上述のステップＳ４０９の伝達を行うが、この際に、アクセスネットワーク２３及びメトロネットワーク２２の構成要素(装置)からネットワークトポロジー及び資源情報を収集し（ステップＳ５０１）、該収集した情報を資源管理モジュール３２に伝達する（ステップＳ５０２）。資源管理モジュール３２は、収集されたネットワークトポロジー及び資源情報を用いて資源管理テーブル（Ｔ／Ｒ Table）を生成する（ステップＳ５０３）。このように生成された資源管理テーブルは、データベース４１に格納されることができる（ステップＳ５０４）。
【００６１】
仮に、アクセスネットワーク２３及びメトロネットワーク２２の構成要素(装置)に障害が発生した場合、該障害発生の事実が、ＳＮＭＰモジュール３９／ＣＬＩモジュール４０、資源管理モジュール３２、政策決定モジュール３１を通じて運用者インタフェース４２へ転送される（ステップＳ５０５）。この際、資源管理モジュール３１は、当該障害事実を反映するように、資源管理テーブルをアップデートする（ステップＳ５０６）。そして、資源管理モジュール３２は、アップデートされた資源管理テーブルをデータベース４１に格納する（ステップＳ５０７）。このように、障害が発生した場合には、資源管理モジュール３２は、ステップＳ５０５乃至Ｓ５０７の処理を実行し、政策決定モジュール３１は、上述したステップＳ４１２の処理を実行するものである。
【００６２】
また、ＳＮＭＰモジュール３９またはＣＬＩモジュール４０は、アクセス、メトロネットワーク２３、２２の構成要素(装置)からＩＰルーティングテーブルを収集し（ステップＳ５０８）、収集されたＩＰルーティングテーブルを資源管理モジュール３２に伝達する（ステップＳ５０９）。資源管理モジュール３２は、かかるＩＰルーティングテーブルを用いて仮想経路を生成し（ステップＳ５１０）、当該仮想経路のデータをデータベース４１に格納する（ステップＳ５１１）。このような仮想経路は、複合ネットワーク間のデータを最適に送受信するための経路情報である。仮に、ネットワーク上のＩＰルーティングテーブルが変更された場合（ステップＳ５１２）、ＳＮＭＰモジュール３９及びＣＬＩモジュール４０は、変更されたＩＰルーティングテーブルを再収集し（ステップＳ５１３）、再収集されたＩＰルーティングテーブルを資源管理モジュール３２に伝達する（ステップＳ５１４）。そして、資源管理モジュール３２は、再収集されたＩＰルーティングテーブルを用いて仮想経路を修正し（ステップＳ５１５）、該アップデートされた仮想経路をデータベース（４１）に格納する（ステップＳ５１６）。また、資源管理モジュール３２は、アップデート以前の仮想経路を利用する呼処理モジュール３４に、アップデートされた仮想経路の情報を通知する（ステップＳ５１７）。
【００６３】
図６は、本発明のさらに他の実施形態による呼処理モジュールの動作を示すフロー図である。
【００６４】
呼サーバーまたはマルチメディアサーバーは、呼処理モジュール３４に呼認証要請（ＣＡＣ Request）を行う（ステップＳ６０１）。呼処理モジュール３４は、データベース４１に、呼を設定しようとするアクセスネットワーク２３の資源照会を要請する（ステップＳ６０２）。続いて、呼処理モジュール３４は、データベース４１内のアクセスネットワーク２３の資源情報を検索し（ステップＳ６０３）、該検索結果として、データベース４１からアクセスネットワーク２３の資源情報を受信する（ステップＳ６０４）。そして、アクセスネットワーク２３の資源情報を受信した呼処理モジュール３４は、アクセスネットワーク２３の資源が不足している場合には、呼認証要請をした呼サーバーまたはマルチメディアサーバーに通話中の信号（Busy Signal）を伝達する（ステップＳ６０５）。
【００６５】
一方、必要なアクセスネットワーク資源が存在する場合には、呼処理モジュール３４は、資源管理モジュール３２に仮想経路の照会を要請する（ステップＳ６０６）。資源管理モジュール３２は、仮想経路を照会し（ステップＳ６０７）、該照会結果を呼処理モジュール３４に応答する（ステップＳ６０８）。従って、呼処理モジュール３４は、このような仮想経路を用いてメトロネットワークのどの構成要素を経由してパケットを転送することが最適であるかを把握できるようになる。
【００６６】
次に、ステップＳ６０６〜Ｓ６０８で把握した最適の仮想経路を利用できるかについての資源照会をしなければならない。呼処理モジュール３４は、当該仮想経路に従ってメトロネットワーク２２の資源を検索する。検索された資源は、仮想経路（ＶＲ）基盤のメトロネットワーク資源照会として表示される。メトロネットワーク２２の資源検索過程（ステップＳ６０９〜Ｓ６１１）は、上述したステップＳ６０２乃至Ｓ６０４の過程とほぼ同じであることから、その説明を省略する。
【００６７】
呼処理モジュール３４は、メトロネットワークの資源状態をソフトスイッチまたはマルチメディアサーバーへ送信する（ステップＳ６１２）。より具体的には、呼処理モジュール３４は、メトロネットワーク資源が不足した場合には、通話中信号（Busy Signal）を返還し、メトロネットワーク資源が充分である場合には、ＯＫ信号（ＯＫ Signal）を返還する。ＯＫ信号が返還された場合、ソフトスイッチまたはマルチメディアサーバーは、新しい呼を連結（link）するようになるので、ネットワークのトポロジー及び資源状態が変更される。したがって、呼処理モジュール３４は、データベース４１に資源をアップデートすべき旨の命令を発信し（ステップＳ６１３）、データベース４１は、新規呼設定によるネットワークの資源状態変化をアップデートする（ステップＳ６１４）。
【００６８】
ステップＳ６１４のアップデート過程で最適の仮想経路が変更される場合、資源管理モジュール３２は、最適の仮想経路を再び判断し、該判断結果を呼処理モジュール３４に伝達する（ステップＳ６１５）。この場合、呼処理モジュール３４は、呼処理手続をしばらく中止し（ステップＳ６１６）、また、変更された仮想経路情報をデータベース４１に伝達する（ステップＳ６１７）。データベース４１は、変更された仮想経路情報によって資源状態をアップデートし（ステップＳ６１８）、その後、呼処理モジュール３４は、中止された呼処理手続を再開する（ステップＳ６１９）。このような過程を通じて、マルチメディアサーバーと受信端末との間の呼が設定されるものである。
【００６９】
このように新しい呼が設定される場合には、ネットワークの呼設定限界値を超過することがあり得る。このような状況が発生すると、呼処理モジュール３４は、ユーザーインタフェース４１を通じて運用者に呼遮断限界値（Call Block Ratio Threshold）超過を通知する（ステップＳ６２０）。
【００７０】
さらに、呼処理モジュール３４は、新たな呼が設定されたこと（すなわちＣＡＣ基盤のネットワーク資源状態が変更されたこと）をトラフィック監視モジュール３５に通知する（ステップＳ６２１）。
【００７１】
図７は、本発明のさらに他の実施形態によるトラフィック監視モジュールの動作を示すフロー図である。
【００７２】
図５の場合と同様に、ＳＮＭＰモジュール３９またはＣＬＩモジュール４０は、アクセスネットワーク２３またはメトロネットワーク２２の構成要素(装置)と周期的に通信を行い、ネットワーク資源使用状態の情報を収集する（ステップＳ７０１）。このような方法で収集されたネットワーク資源使用状態情報は、トラフィック監視モジュール３５へ転送される（ステップＳ７０２）。トラフィック監視モジュール３５は、収集されたネットワーク資源使用状態情報をデータベース４１に格納し（ステップＳ７０３）、運用者インタフェース４２を通じて運用者にネットワーク資源使用状態情報を提供することができる（ステップＳ７０４）。これにより、運用者は、各ネットワークのトラフィック状態を監視できるようになる（ステップＳ７０５）。トラフィック監視モジュール３５は、ネットワーク資源状態を分析し（ステップＳ７０６）、使用中のネットワークのトラフィックがトラフィック限界値（Threshold）を超過する場合、これを政策決定モジュール３１と運用者インタフェース４２に通知する（ステップＳ７０７）。
【００７３】
一方、図６のステップＳ６２１の過程により、トラフィック監視モジュール３５が呼処理モジュール３４からＣＡＣ基盤のネットワーク資源状態の変更を通知された場合（ステップＳ７０８）、トラフィック監視モジュール３５は、リアルタイムで収集されたトラフィック情報と変更されたネットワーク資源情報とを比較する（ステップＳ７０９）。このような過程は、ステップＳ７０６の過程と類似の方法で行われる。同様に、上記比較の結果、使用中の資源が呼処理モジュール３４から通知された限界値（Threshold）を超過する場合、トラフィック監視モジュール３５は、これを政策決定モジュール３１と運用者インタフェース４２に通知する（ステップＳ７１０）。
【００７４】
図８は、本発明のさらに他の実施形態による政策決定モジュールのイベント発生時の動作を示すフロー図である。
【００７５】
政策決定モジュール３１が資源管理モジュール３２からネットワーク障害発生を通知された場合（ステップＳ８０１）に、政策決定モジュール３１は、まず、運用者インタフェース４２を用いて障害発生状況をディスプレイし（ステップＳ８０２）、続いて、運用者からそれに対する政策を入力される（ステップＳ８０３）。このように入力された政策は、データベース４１に格納される（ステップＳ８０４）と共に、政策決定モジュール３１で受信され政策インタフェースモジュール３３へと転送される（ステップＳ８０５）。続いて、政策インタフェースモジュール３３は、政策を行うための変数または対象をデータベース４１を用いて検索し（ステップＳ８０６）、政策を設定するための命令を生成する（ステップＳ８０７）。このような命令は、ＣＬＩまたはＳＮＭＰ  ＭＩＢを用いて生成されることができる。このように生成された命令は、ＳＮＭＰモジュール３９及びＣＬＩモジュール４０を通じて、アクセスネットワーク２３またはメトロネットワーク２２の構成要素(装置)に伝達される（ステップＳ８０８）。また、ＳＮＭＰモジュール３９、ＣＬＩモジュール４０は、前記構成要素(装置)から政策の設定結果を収集し、該収集した情報を政策インタフェースモジュール３３、政策決定モジュール３１、及び運用者インタフェース４１に伝達する（ステップＳ８０９、Ｓ８１０）。仮に、政策設定の過程でエラーが発生した場合、運用者は、原因を把握した後に、修正された政策をさらに入力する（ステップＳ８１１）。続いて行われる政策の再設定過程は、前述したステップＳ８０４乃至ステップＳ８１０の過程と同様である。このようにして政策が設定された後に、政策決定モジュール３１は、ネットワーク障害処理結果を資源管理モジュール３２に通知する（ステップＳ８１２）。
【００７６】
次に、図６のステップＳ６２０の過程で政策決定モジュール３１が呼処理モジュール３４から呼遮断限界値（Call Block Ratio Threshold）超過を通知された場合、政策決定モジュール３１は、運用者インタフェース４２により当該イベントをディスプレイするようにする（ステップＳ８１３）。これに対して、運用者は、当該イベントに対処するための政策を作成し、入力する。この政策実行過程中、ステップＳ８１４〜Ｓ８１７の過程は、ステップＳ８０３〜Ｓ８０６の過程と類似している。但し、呼処理モジュール３４は、統合ネットワーク制御システム３０内部のモジュールであるから、入力された政策は、図８に示すように、ＳＮＭＰモジュール３９、ＣＬＩモジュール４０を経由せず、直接呼処理モジュール３４に伝達される。呼処理モジュール３４は、上述したステップＳ８０３乃至Ｓ８０６と類似したステップＳ８１４乃至Ｓ８１７の過程を経て、発生した障害を処理するための政策について通知を受ける（ステップＳ８１８）。
【００７７】
最後に、ステップＳ７０１の過程によりトラフィック監視モジュール３５から使用トラフィックが閾値（Threshold）を超過したという通知を受けた場合（ステップＳ８１９）、政策決定モジュール３１は、ステップＳ８０３乃至Ｓ８１２で説明した方法と同じ方法（ステップＳ８２０〜Ｓ８２９）で、アクセスネットワーク及びメトロネットワーク２３、２２の構成要素(装置)を管理する。
【００７８】
図９Ａは、本発明のさらに他の実施形態によるＰＯＮユーザとワイブロユーザ間のＶｏＩＰ通話のためのネットワーク構成を示すブロック図である。また、図９Ｂは、図９Ａの統合ネットワーク制御システムの動作を示すフロー図である。
【００７９】
図９Ａに示されたように、ＰＯＮネットワークを利用する第１加入者端末７０とワイブロネットワークを利用する第２加入者端末８０は、アクセスネットワークであるＰＯＮ２５と、ＩＰ基盤のメトロネットワーク２２と、ワイブロネットワーク２６と、を通じてＶｏＩＰ通話を行う。
【００８０】
この場合、統合ネットワーク制御システム３０は、ＰＯＮネットワーク２５に含まれたＰＯＮ  ＥＭＳ、ワイブロネットワーク２６に含まれたワイブロＥＭＳ、メトロネットワーク２２のＬ３スイッチ、などを制御する。以下、図９Ｂを参照して、統合ネットワーク制御システム３０の制御動作を説明する。
【００８１】
まず、ＰＯＮネットワークのユーザの第１加入者端末７０は、呼設定を要請する。この第１加入者端末７０の呼設定要請（ＣＡＣ Request）は、ＰＯＮネットワーク２５を通じて、最初に呼サーバーまたはマルチメディアサーバーに転送される（ステップＳ９０１）。この呼設定要請を受信した呼サーバーまたはマルチメディアサーバーは、統合ネットワーク制御システム３０の呼処理モジュール３４に、当該呼を認証すること（呼認証）を要請する（ステップＳ９０２）。
【００８２】
そして、呼処理モジュール３４は、アクセスネットワークの資源をチェックすること（資源照会）をデータベース４１に要請する（ステップＳ９０３）。この場合、呼処理モジュール３４は、第１，第２加入者端末７０，８０が属するアクセスネットワーク２３の情報及びチェックしようとするネットワーク資源の目録（リスト）をデータベース４１に伝達することによって、所要のアクセスネットワークだけを資源照会することができる。本実施形態では、呼処理モジュール３４は、Ｅ−ＰＯＮネットワーク２５のＬＬＩＤ帯域幅とワイブロネットワーク２６のＣＩＤ帯域幅に関する資源の照会（チェック）を、データベース４１に要請する。続いて、呼処理モジュール３４は、データベース４１内のアクセスネットワークの資源情報を検索し（ステップＳ９０４）、この検索結果として、データベース４１からアクセスネットワークの資源情報を受信する（ステップＳ９０５）。本実施形態では、データベース４１から呼処理モジュール３４に、資源が存在する旨の応答が転送されたことが分かる。この場合、次に呼処理モジュール３４が資源管理モジュール３２に、仮想経路の照会を要請する（ステップＳ９０６）。資源管理モジュール３２は、ＰＯＮネットワーク２５とワイブロネットワーク２６間の最適の転送経路である仮想経路について照会し（ステップＳ９０７）、その結果を呼処理モジュール３４に報告する（ステップＳ９０８）。
【００８３】
一方、呼処理モジュールは、仮想経路によって通信を行う場合には、経由すべきメトロネットワーク２２の資源の照会を、データベース４１に要請する（ステップＳ９０９）。同様に、呼処理モジュール３４は、データベース４１内のメトロネットワークの資源情報を検索し（ステップＳ９１０）、この検索結果として、データベース４１から「資源が存在する」旨の応答が転送される（ステップＳ９１１）。
【００８４】
この例では、ＰＯＮネットワーク２５、ワイブロネットワーク２６及びメトロネットワーク２２の資源が充分なので、呼処理モジュール３４は、（充分な）資源が存在する旨の応答メッセージを、呼サーバーまたはマルチメディアサーバーに転送する（ステップＳ９１２）。一方、呼処理モジュール３４は、データベース４１に資源状態情報を更新（アップデート）せよとの命令を発信し（ステップＳ９１３）、これにより、データベース４１は、資源状態をアップデートする（ステップＳ９１４）。ここで、ネットワーク資源が不足した場合（すなわち不充分な場合）には、統合ネットワーク制御システム３０は、呼設定が可能になるように、資源が不足したネットワークに対する政策を再設定することができる。例えば、ネットワーク資源が不足した場合に、サービスクラス別に割り当てられている帯域幅を変更することによって、ＶｏＩＰ通話のための充分な帯域幅を確保する政策などが存在する。
【００８５】
続いて、呼サーバーまたはマルチメディアサーバーは、第２加入者端末８０のアドレス情報を含む呼設定認証メッセージ（Call Admission）を、第１加入者端末７０へ送信する（ステップＳ９１５）。第１加入者端末７０は、この呼設定認証メッセージを用いてワイブロネットワーク２６に存在する第２加入者端末８０と呼を設定し、ＶｏＩＰ通話を遂行する（ステップＳ９１６）。
【００８６】
ＶｏＩＰ通話が終了する場合、第１加入者端末７０は、呼解除要請（Call End Request）を呼サーバーまたはマルチメディアサーバーへ送信する（ステップＳ９１７）。この呼解除要請を受信した呼サーバーまたはマルチメディアサーバーは、第２加入者端末８０に呼解除を通知する（ステップＳ９１８）。そして、呼サーバーは、第２加入者端末８０から呼解除に対する応答を受信する（ステップＳ９１９）と、第１加入者端末７０に呼解除を通知する（ステップＳ９２０）。続いて、前記呼サーバーは、呼処理モジュール３４に第１，第２加入者端末間の呼解除を通知し（ステップＳ９２１）、かかる通知を受信した呼処理モジュール３４は、データベース４１に資源状態情報の更新（アップデート）命令を発信し（ステップＳ９２２）、データベース４１で資源状態情報のアップデートを実行する（ステップＳ９２３）。
【００８７】
以上説明した本発明は、本発明が属する技術の分野における通常の知識を有する者であれば、本発明の技術的思想を逸脱しない範囲内で、様々な置換、変形及び変更が可能であるので、上述した実施形態及び添付された図面に限定されるものではない。
【図面の簡単な説明】
【００８８】
【図１】一般的なアクセスネットワークとメトロネットワークの構成を示すブロック図である。
【図２】本発明の一実施形態による統合ネットワーク制御システムを備えるネットワークの構成を示すブロック図である。
【図３】本発明の一実施形態による統合ネットワーク制御システムの内部構造を示すブロック図である。
【図４】本発明の他の実施形態による政策決定モジュールの動作を示す流れ図である。
【図５】本発明のさらに他の実施形態による資源管理モジュールの動作を示す流れ図である。
【図６】本発明のさらに他の実施形態による呼処理モジュールの動作を示す流れ図である。
【図７】本発明のさらに他の実施形態によるトラフィック監視モジュールの動作を示す流れ図である。
【図８】本発明のさらに他の実施形態による政策決定モジュールのイベント発生時の動作を示す流れ図である。
【図９Ａ】本発明のさらに他の実施形態によるＰＯＮユーザとワイブロユーザ間のＶｏＩＰ通話のためのネットワーク構成を示すブロック図である。
【図９Ｂ】図９Ａの統合ネットワーク制御システムの動作を示す流れ図である。
【符号の説明】
【００８９】
２１  コアネットワーク
２２  メトロネットワーク
２３  アクセスネットワーク
３０  統合ネットワーク制御システム（ＩＮＣＰ）
３１  政策決定モジュール（ＰＲＤ）
３２  資源管理モジュール（ＴＲＭ）
３３  政策インタフェースモジュール（ＰＩＭ）
３４  呼処理モジュール（ＣＡＭ）
３５  トラフィック監視モジュール（ＴＭ）
３６  エラー管理モジュール（ＦＭ）
３７  性能管理モジュール
４２  運用者インタフェース
【図１】
2007195181.tif 000003
【図２】
2007195181.tif 000004
【図３】
2007195181.tif 000005
【図４】
2007195181.tif 000006
【図５】
2007195181.tif 000007
【図６】
2007195181.tif 000008
【図７】
2007195181.tif 000009
【図８】
2007195181.tif 000010
【図９Ａ】
2007195181.tif 000011
【図９Ｂ】
2007195181.tif 000012