(57)【要約】【課題】機能追加時におけるリソース管理の処理能力低下を抑制すること。【解決手段】メディア帯域の帯域量を所定の帯域量に変化させて管理必要な機能が呼処理サーバ１に追加された場合に、その追加機能が開始された機能開始時刻を記録し、使用帯域の帯域量を機能開始時刻後の帯域量に変更し、メディア帯域に係る呼の生起時刻と機能開始時刻とを比較し、機能開始時刻後であって使用帯域の帯域量を変更する前から既に所定の帯域量を有していたメディア帯域が含まれている場合には、そのメディア帯域に係る機能開始時刻後の帯域量と機能開始時刻前の帯域量との差分帯域量を変更後の使用帯域から減算する。【選択図】図３
2011228850.tif 000002
【特許請求の範囲】
【請求項１】
ＳＩＰネゴシエーションの結果決定されるメディアを転送する転送系ネットワークを備え、前記転送系ネットワークに配備されたメディアゲートウェイで転送される呼を制御する呼処理サーバで動作するリソース管理装置により、
仮想パス上で各メディア通信にそれぞれ使用される各メディア帯域の総帯域量を使用帯域として記憶手段に記憶して管理するステップと、
前記メディア帯域の帯域量を所定の帯域量に変化させて管理必要な機能が前記呼処理サーバに追加された場合に、当該機能が開始された機能開始時刻を記録するステップと、
前記使用帯域を前記記憶手段から読み出して、各メディア帯域の前記所定の帯域量への変化の全体に対応するように当該使用帯域の帯域量を変更するステップと、
前記各メディア帯域に係る呼の生起時刻と前記機能開始時刻とを比較し、機能開始時刻後であって使用帯域の帯域量を変更する前から既に前記所定の帯域量を有していたメディア帯域が前記使用帯域に含まれている場合には、当該メディア帯域に係る機能開始時刻後の帯域量と機能開始時刻前の帯域量との差分帯域量を前記変更後の使用帯域の帯域量から減算するステップと、
を有することを特徴とするリソース管理方法。
【請求項２】
前記機能開始時刻後に新規メディア帯域の予約要求又は確保要求があった場合に、各メディア帯域の帯域量を用いて前記使用帯域を計算し、前記仮想パスの上限帯域と当該使用帯域との差分である残帯域に前記新規メディア帯域を許容できるか否かを判断し、許容可能な場合に、当該新規メディア帯域の帯域量を前記使用帯域に加算し、新規メディアに係る呼の流出入を許可するように前記メディアゲートウェイを制御することを特徴とする請求項１に記載のリソース管理方法。
【請求項３】
前記機能開始時刻後に既存メディア帯域の開放要求又は帯域変更要求があった場合に、各メディア帯域の帯域量を用いて前記使用帯域を計算し、前記既存メディア帯域の帯域量を当該使用帯域から減算することを特徴とする請求項１又は２に記載のリソース管理方法。
【請求項４】
ＳＩＰネゴシエーションの結果決定されるメディアを転送する転送系ネットワークを備え、前記転送系ネットワークに配備されたメディアゲートウェイで転送される呼を制御する呼処理サーバで動作するリソース管理装置において、
仮想パス上で各メディア通信にそれぞれ使用される各メディア帯域の総帯域量を使用帯域として記憶手段に記憶して管理するリソース管理手段と、
前記メディア帯域の帯域量を所定の帯域量に変化させて管理必要な機能が前記呼処理サーバに追加された場合に、当該機能が開始された機能開始時刻を記録する機能開始時刻記録手段と、
前記使用帯域を前記記憶手段から読み出して、各メディア帯域の前記所定の帯域量への変化の全体に対応するように当該使用帯域の帯域量を変更する使用帯域調整手段と、
前記各メディア帯域に係る呼の生起時刻と前記機能開始時刻とを比較し、機能開始時刻後であって使用帯域の帯域量を変更する前から既に前記所定の帯域量を有していたメディア帯域が前記使用帯域に含まれている場合には、当該メディア帯域に係る機能開始時刻後の帯域量と機能開始時刻前の帯域量との差分帯域量を前記変更後の使用帯域の帯域量から減算する使用帯域再調整手段と、
を有することを特徴とするリソース管理装置。
【請求項５】
前記機能開始時刻後に新規メディア帯域の予約要求又は確保要求があった場合に、各メディア帯域の帯域量を用いて前記使用帯域を計算し、前記仮想パスの上限帯域と当該使用帯域との差分である残帯域に前記新規メディア帯域を許容できるか否かを判断し、許容可能な場合に、当該新規メディア帯域の帯域量を前記使用帯域に加算し、新規メディアに係る呼の流出入を許可するように前記メディアゲートウェイを制御することを特徴とする請求項４に記載のリソース管理装置。
【請求項６】
前記機能開始時刻後に既存メディア帯域の開放要求又は帯域変更要求があった場合に、各メディア帯域の帯域量を用いて前記使用帯域を計算し、前記既存メディア帯域の帯域量を当該使用帯域から減算することを特徴とする請求項４又は５に記載のリソース管理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ノード間の仮想パスをリソースとして管理する技術に関する。
【背景技術】
【０００２】
図１０は、ＳＩＰを利用した呼処理制御を行うＳＩＰ通信ネットワークのシステム構成を概略的に示す図である。このＳＩＰ通信ネットワークは、ネットワークの加入者（以下、ユーザという）が利用する複数のエンド端末５と、エンド端末５から送信された呼接続要求等の呼処理を制御する複数の呼処理サーバ１と、呼処理サーバ１の指示に従って転送網内外のターミネーション（Termination）を結びつけるメディアゲートウェイ（ＭＧ：Media Gateway）３と、エンド端末５と呼処理サーバ１とメディアゲートウェイ３との間をそれぞれ通信可能に物理的に接続するルータ，スイッチ，ＰＯＮ（Passive Optical Network），ホームゲートウェイ（ＨＧＷ：Home Gateway）等の様々なネットワーク機器７とで構成されている。
【０００３】
そして、所望する相手に対して通話する場合には、エンド端末５から相手先のエンド端末（不図示）に対してＩＮＶＩＴＥ等の呼接続確立に要する要求信号（ＳＩＰを利用したＳＩＰ信号、以下同様）を送信し、相手先のエンド端末との間で行われるＳＩＰネゴシエーションの結果がＯＫである場合に、両者のエンド端末間でセッションが確立して通話が可能となる。
【０００４】
具体的には、エンド端末５ａからの要求信号が呼処理サーバ１に送信され、その要求信号を受信した呼処理サーバ１は、隣接接続された他の呼処理サーバ１ａや、その先の呼処理サーバ１ｂを経由して、当該要求信号に基づく呼の接続を相手先のエンド端末に要求する。そして、エンド端末間（詳細には、呼処理サーバ間や、呼処理サーバとエンド端末との間等）でＳＩＰネゴシエーションが行われ、その結果に基づいて音声通信や動画通信等のメディア通信のためのセッション情報が決定され、メディアセッションが確立して、メディア通信が可能となる。なお、図１０では、装置間又は機器間の物理的な接続状態，ＳＩＰのパケットやメディアのトラフィックが実際に流れる通信経路を実線で示し、ＳＩＰ信号の論理的な流れを破線で示している。
【０００５】
ここで、呼処理サーバ１の構成について説明する。呼処理サーバ１は、上述したようにエンド端末５から送信された呼接続要求等の呼処理を制御する呼処理機能部（ＣＳＣＦ：Call Session Control Function）１１と、ＳＩＰ通信ネットワークにおける装置間又は機器間の通信経路（具体的には、メディアゲートウェイとルータとの間や、ルータとスイッチとの間等の各ノード間のリンク又はパス）のリソースを管理するリソース管理装置（ＲＡＣＳ：Resource and Admission Control Subsystem）１２とで構成されている。
【０００６】
リソース管理装置１２は様々な機能部により構成されているが、特に、リソース管理機能部（Ａ−ＲＡＣＦ：Resource and Admission Control Function）と、ポリシー設定機能部（ＳＰＤＦ：Service Policy Decision Function）とで構成された機能部は、呼処理機能部１１からの要求に基づいてメディアゲートウェイ３を制御することから、メディアゲートウェイコントローラ（ＭＧＣ：Media Gateway Controller）１２１と呼ばれている。
【０００７】
メディアゲートウェイコントローラ１２１は、優先度や品質に応じて区分けされた上記通信経路の使用帯域や上限帯域等を仮想的なリソースや仮想パスとして予めメモリ等の記憶手段に記憶して管理している。そして、エンド端末５からの新たな呼処理要求に基づいて呼処理機能部１１から通信経路の新規確立要求が送信された場合に、上記ＳＩＰネゴシエーションの際に決定されるＳＤＰ（Session Description Protocol）情報の一部又は全部のメディア情報に従ってメディア帯域を確保し、現在の使用帯域に積上・積下（加算・減算）を行って、要求されたメディア帯域が仮想パスの上限帯域を超えるか否かの受付判定（例えば、ＳＩＰネゴシエーションによって確立する１以上のメディアのトラフィック同士が転送網を通過する際に干渉しあってパケットロスするか否かの判定）を行う。
【０００８】
そして、その判定の結果、上記新たな呼処理要求に基づくメディアセッションの確立が仮想パス上限帯域内で使用可能である場合には、メディアゲートウェイ３にエンド端末同士を結びつけるターミネーションを生成し、ＳＩＰネゴシエーションの結果毎に図１０に示したようなメディア情報（各メディア情報には、メディア種別、要求帯域、方向属性が含まれている）を含むセッション情報がメディアゲートウェイコントローラ１２１の記憶手段に保存される。
【０００９】
その後、メディアゲートウェイコントローラ１２１は、メディアゲートウェイ３に対してピンホール制御及びポリシー制御を行う（図１０に示す一点鎖線）。ピンホール制御するタイミングとしては、ＩＮＩ−ＩＮＶＩＴＥでの帯域予約時、２００ＯＫでの帯域確保時、ＢＹＥでの帯域開放時等であり、このような制御にはｍｅｇａｃｏプロトコルが用いられる（ｍｅｇａｃｏ制御）。帯域の予約要求・確保要求・変更要求の受付時には、各要求と要求内のメディア情報とを記録する。一方、帯域の削除要求の受付時には、受付済の要求情報と各メディア情報をメモリ等から削除する。
【００１０】
また、ポリシー制御においては、発ユーザ種別や着ユーザ種別、ＳＤＰ情報内のプライオリティや加入者情報の優先度を識別して、ＳＩＰ通信ネットワークに輻輳が発生した時に呼の優先度を識別してパケットの通信が規制される。
【００１１】
以上により、メディアゲートウェイコントローラ１２１は、ＳＩＰ通信ネットワークに流入出するパケットの制御を行っている。なお、このような従来のメディアゲートウェイコントローラについては、特許文献１に開示されている。
【００１２】
なお、ＳＤＰ情報には、各種のメディア通信に必要とされる要求帯域や転送品質クラス等の情報が記載されている。また、帯域の積上又は積下とは、リソース管理機能部が管理している全ての仮想パスからエンド端末間の経路を特定した後に、該当する１以上の仮想パスに対して、通話開始時は要求帯域を加算し、通話終了時は加算されている帯域を減算することを意味する。また、ピンホール制御とは、メディアゲートウェイ３に対して、エンド端末間や、エンド端末と呼処理サーバ１との間で通信するためのポートの開通・不通や番号の設定等を実際に行う制御を意味する。
【００１３】
一方、メディアゲートウェイ３は、メディアゲートウェイコントローラ１２１からの指示に従ってターミネーションを生成し、ポリシー設定に基づいてエンド端末間等の通信に必要なポートを設定する。メディアゲートウェイ３に確保されるセッション情報及びターミネーション情報は、メディアゲートウェイコントローラ１２１の各情報と一致している。なお、メディアゲートウェイ３は、通常、Ｃ−ＢＧＦ（Core Border Gateway Function）、Ｉ−ＢＧＦ（Interconnection Border Gateway Function）、ＲＣＥＦ（Resource Control Enforcement Function）と呼ばれる機能部で構成されている。
【００１４】
以上より、メディアゲートウェイコントローラ１２１で帯域確保され、メディアゲートウェイ３で物理的な通信経路が確保された各種メディアは、図１１に示すように、仮想パスの各メディア帯域内で通信可能となる。
【００１５】
ここで、上述した呼処理サーバ１に、メディア帯域の帯域量を所定の帯域量に変化させて管理する必要のある新たな機能が追加される場合がある。このようなメディア帯域の帯域量変動を伴う新機能が追加された際における、上記メディアゲートウェイコントローラ１２１を具備する従来のリソース管理装置１２の処理について説明する。
【００１６】
図１２は、新規メディア帯域を予約又は確保する場合の従来の処理フローを示す図である。リソース管理装置１２は、新規メディア帯域の予約要求又は確保要求を受け付けて、受付した情報をセッション情報として一時的に記憶手段に追加保存する（Ｓ７１，Ｓ７２）。
【００１７】
次いで、その新規メディア帯域を後々の開放処理に使用するため、新規メディア帯域の予約要求又は確保要求が機能追加後にされたことを把握可能となるように、機能追加後フラグのオンオフ枠をセッション情報に生成し、その新規メディア帯域に対して機能追加後フラグをオンに設定する（Ｓ７３）。
【００１８】
次いで、所定の帯域量に変化後の各メディア帯域の総帯域量を機能追加後の使用帯域の帯域量として計算する（Ｓ７４）。
【００１９】
次いで、仮想パスの上限帯域と使用帯域との差分である残帯域に新規メディア帯域を許容可能か否かを受付判定する（Ｓ７５）。なお、各メディア帯域は個別に判定閾値を保持している場合があり、その場合には各々判定を行う。
【００２０】
Ｓ７５の判定結果で受付可能と判定した場合には、新規メディア帯域の帯域量を上記使用帯域に加算して使用帯域を更新する（Ｓ７６）。
【００２１】
次いで、メディアゲートウェイ３に対してピンホール制御及びポリシー制御を行い（Ｓ７７）、双方の制御が成功した場合には、予約要求成功応答又は確保要求成功応答を要求元の呼処理機能部１１に送信する（Ｓ７８，Ｓ７９）。
【００２２】
一方、Ｓ７５の判定結果で受付不可能と判定した場合や、ピンホール制御及びポリシー制御が失敗した場合には、予約要求失敗応答又は確保要求失敗応答を要求元の呼処理機能部１１に送信し（Ｓ８０）、Ｓ７６で加算する前の状態に使用帯域をロールバックする（Ｓ８１）。
【００２３】
図１３は、既存メディア帯域を開放又は変更する場合の従来の処理フローを示す図である。リソース管理装置１２は、既存メディア帯域の開放要求又は変更要求を受け付けて、対象となる既存メディア帯域に係る機能追加後フラグがオンであるか否かを判定する（Ｓ９１，Ｓ９２）。
【００２４】
機能追加後フラグがオンの場合には、メディア情報内の各メディア帯域の帯域量を用いて機能追加後の使用帯域の帯域量を計算し、解放対象の既存メディア帯域を削除等するメディア帯域の加減算を行って、使用帯域を更新する（Ｓ９３，Ｓ９４）。
【００２５】
一方、機能追加後フラグがオフの場合には、メディア情報内の各メディア帯域の帯域量を用いて機能追加前の使用帯域の帯域量を計算し、解放対象の既存メディア帯域を削除等するメディア帯域を加減算を行って、使用帯域を更新する（Ｓ９５，Ｓ９６）。
【先行技術文献】
【特許文献】
【００２６】
【特許文献１】特開２００３−２５８８５５号公報
【発明の概要】
【発明が解決しようとする課題】
【００２７】
しかしながら、新規メディア帯域の予約要求時又は確保要求時にはフラグを設定し、既存メディア帯域の開放要求時又は変更要求時にはフラグのオンオフを判定するため、ユーザからのメディア要求頻度が高い場合にはリソース管理装置の処理能力が低下するという問題があった。
【００２８】
また、呼処理サーバに機能が追加（又は変更）されるに応じてフラグの種類や判定回数を変更する必要があるため、予約要求等の各要求に係る処理が複雑となり、実装が煩雑となるという問題があった。
【００２９】
本発明は、上記を鑑みてなされたものであり、機能追加時におけるリソース管理の処理能力低下を抑制することを課題とする。
【課題を解決するための手段】
【００３０】
請求項１に記載のリソース管理方法は、ＳＩＰネゴシエーションの結果決定されるメディアを転送する転送系ネットワークを備え、前記転送系ネットワークに配備されたメディアゲートウェイで転送される呼を制御する呼処理サーバで動作するリソース管理装置により、仮想パス上で各メディア通信にそれぞれ使用される各メディア帯域の総帯域量を使用帯域として記憶手段に記憶して管理するステップと、前記メディア帯域の帯域量を所定の帯域量に変化させて管理必要な機能が前記呼処理サーバに追加された場合に、当該機能が開始された機能開始時刻を記録するステップと、前記使用帯域を前記記憶手段から読み出して、各メディア帯域の前記所定の帯域量への変化の全体に対応するように当該使用帯域の帯域量を変更するステップと、前記各メディア帯域に係る呼の生起時刻と前記機能開始時刻とを比較し、機能開始時刻後であって使用帯域の帯域量を変更する前から既に前記所定の帯域量を有していたメディア帯域が前記使用帯域に含まれている場合には、当該メディア帯域に係る機能開始時刻後の帯域量と機能開始時刻前の帯域量との差分帯域量を前記変更後の使用帯域の帯域量から減算するステップと、を有することを特徴とする。
【００３１】
本発明によれば、ＳＩＰネゴシエーションの結果決定されるメディアを転送する転送系ネットワークを備え、転送系ネットワークに配備されたメディアゲートウェイで転送される呼を制御する呼処理サーバで動作するリソース管理装置により、仮想パス上で各メディア通信にそれぞれ使用される各メディア帯域の総帯域量を使用帯域として記憶手段に記憶して管理し、メディア帯域の帯域量を所定の帯域量に変化させて管理必要な機能が呼処理サーバに追加された場合に、その機能が開始された機能開始時刻を記録し、使用帯域を記憶手段から読み出して、各メディア帯域の所定の帯域量への変化の全体に対応するように当該使用帯域の帯域量を変更し、各メディア帯域に係る呼の生起時刻と機能開始時刻とを比較し、機能開始時刻後であって使用帯域の帯域量を変更する前から既に所定の帯域量を有していたメディア帯域が使用帯域に含まれている場合には、そのメディア帯域に係る機能開始時刻後の帯域量と機能開始時刻前の帯域量との差分帯域量を変更後の使用帯域の帯域量から減算するため、機能追加時におけるリソース管理の処理能力低下を抑制することができる。
【００３２】
請求項２に記載のリソース管理方法は、請求項１に記載のリソース管理方法において、前記機能開始時刻後に新規メディア帯域の予約要求又は確保要求があった場合に、各メディア帯域の帯域量を用いて前記使用帯域を計算し、前記仮想パスの上限帯域と当該使用帯域との差分である残帯域に前記新規メディア帯域を許容できるか否かを判断し、許容可能な場合に、当該新規メディア帯域の帯域量を前記使用帯域に加算し、新規メディアに係る呼の流出入を許可するように前記メディアゲートウェイを制御することを特徴とする。
【００３３】
請求項３に記載のリソース管理方法は、請求項１又は２に記載のリソース管理方法において、前記機能開始時刻後に既存メディア帯域の開放要求又は帯域変更要求があった場合に、各メディア帯域の帯域量を用いて前記使用帯域を計算し、前記既存メディア帯域の帯域量を当該使用帯域から減算することを特徴とする。
【００３４】
請求項４に記載のリソース管理装置は、ＳＩＰネゴシエーションの結果決定されるメディアを転送する転送系ネットワークを備え、前記転送系ネットワークに配備されたメディアゲートウェイで転送される呼を制御する呼処理サーバで動作するリソース管理装置において、仮想パス上で各メディア通信にそれぞれ使用される各メディア帯域の総帯域量を使用帯域として記憶手段に記憶して管理するリソース管理手段と、前記メディア帯域の帯域量を所定の帯域量に変化させて管理必要な機能が前記呼処理サーバに追加された場合に、当該機能が開始された機能開始時刻を記録する機能開始時刻記録手段と、前記使用帯域を前記記憶手段から読み出して、各メディア帯域の前記所定の帯域量への変化の全体に対応するように当該使用帯域の帯域量を変更する使用帯域調整手段と、前記各メディア帯域に係る呼の生起時刻と前記機能開始時刻とを比較し、機能開始時刻後であって使用帯域の帯域量を変更する前から既に前記所定の帯域量を有していたメディア帯域が前記使用帯域に含まれている場合には、当該メディア帯域に係る機能開始時刻後の帯域量と機能開始時刻前の帯域量との差分帯域量を前記変更後の使用帯域の帯域量から減算する使用帯域再調整手段と、を有することを特徴とする。
【００３５】
本発明によれば、ＳＩＰネゴシエーションの結果決定されるメディアを転送する転送系ネットワークを備え、転送系ネットワークに配備されたメディアゲートウェイで転送される呼を制御する呼処理サーバで動作するリソース管理装置により、仮想パス上で各メディア通信にそれぞれ使用される各メディア帯域の総帯域量を使用帯域として記憶手段に記憶して管理し、メディア帯域の帯域量を所定の帯域量に変化させて管理必要な機能が呼処理サーバに追加された場合に、その機能が開始された機能開始時刻を記録し、使用帯域を記憶手段から読み出して、各メディア帯域の所定の帯域量への変化の全体に対応するように当該使用帯域の帯域量を変更し、各メディア帯域に係る呼の生起時刻と機能開始時刻とを比較し、機能開始時刻後であって使用帯域の帯域量を変更する前から既に所定の帯域量を有していたメディア帯域が使用帯域に含まれている場合には、そのメディア帯域に係る機能開始時刻後の帯域量と機能開始時刻前の帯域量との差分帯域量を変更後の使用帯域の帯域量から減算するため、機能追加時におけるリソース管理の処理能力低下を抑制することができる。
【００３６】
請求項５に記載のリソース管理装置は、請求項４に記載のリソース管理装置において、前記機能開始時刻後に新規メディア帯域の予約要求又は確保要求があった場合に、各メディア帯域の帯域量を用いて前記使用帯域を計算し、前記仮想パスの上限帯域と当該使用帯域との差分である残帯域に前記新規メディア帯域を許容できるか否かを判断し、許容可能な場合に、当該新規メディア帯域の帯域量を前記使用帯域に加算し、新規メディアに係る呼の流出入を許可するように前記メディアゲートウェイを制御することを特徴とする。
【００３７】
請求項６に記載のリソース管理装置は、請求項４又は５に記載のリソース管理装置において、前記機能開始時刻後に既存メディア帯域の開放要求又は帯域変更要求があった場合に、各メディア帯域の帯域量を用いて前記使用帯域を計算し、前記既存メディア帯域の帯域量を当該使用帯域から減算することを特徴とする。
【発明の効果】
【００３８】
本発明によれば、機能追加時におけるリソース管理の処理能力低下を抑制することができる。
【図面の簡単な説明】
【００３９】
【図１】リソース管理装置の機能ブロック構成を示す図である。
【図２】リソース管理部で管理される仮想パスの上限帯域及び使用帯域を説明する図である。
【図３】使用帯域を調整又は再調整するまでの処理フローを示す図である。
【図４】新規メディア帯域の予約要求又は確保要求があった場合の処理フローを示す図である。
【図５】既存メディア帯域の開放要求又は変更要求があった場合の処理フローを示す図である。
【図６】実施例１におけるメディア帯域の調整・再調整を説明する図である。
【図７】実施例２におけるメディア帯域の調整・再調整を説明する図である。
【図８】実施例３におけるメディア帯域の調整・再調整を説明する図である。
【図９】リソース管理装置の適用例を説明する図である。
【図１０】ＳＩＰを利用した呼処理制御を行うＳＩＰ通信ネットワークのシステム構成を概略的に示す図である。
【図１１】メディア帯域と仮想パスとの関係性を説明する図である。
【図１２】新規メディア帯域を予約又は確保する場合の従来の処理フローを示す図である。
【図１３】既存メディア帯域を開放又は変更する場合の従来の処理フローを示す図である。
【発明を実施するための形態】
【００４０】
以下、一実施の形態について図面を用いて説明する。
【００４１】
最初に、本実施の形態に係るリソース管理装置の機能について説明する。図１は、リソース管理装置の機能ブロック構成を示す図である。このリソース管理装置１２は、リソース管理部１２ａと、機能開始時刻記録部１２ｂと、使用帯域調整部１２ｃと、使用帯域再調整部１２ｄと、使用帯域計算部１２ｅと、ＭＧ制御部１２ｆとで構成されている。以下、これら各機能部について詳細に説明し、処理フローを説明した後に、本実施の形態に係るリソース管理装置の効果について説明する。
【００４２】
なお、このリソース管理装置１２は、図１０に示したようにＳＩＰネゴシエーションの結果決定されるメディアを転送するＳＩＰ通信ネットワーク（転送系ネットワーク）内に配備され、そのＳＩＰ通信ネットワークに配備されたメディアゲートウェイ３で転送される呼を制御する呼処理サーバ１で動作するものである。従い、このリソース管理装置１２を呼処理サーバ１の一機能として動作させることも可能であるし、背景技術で説明したようなメディアゲートウェイコントローラの機能も処理することが可能であることは言うまでもない。
【００４３】
リソース管理部１２ａは、ＳＩＰ通信ネットワークを構成している経路上のノード間の各リンクや各ノードの処理能力を仮想パスとし、その仮想パス上で各メディア通信にそれぞれ使用される各メディア帯域及びその帯域量と、各メディア帯域の総帯域量である現在の使用帯域と、仮想パスの上限帯域とをメモリ等の記憶手段に記憶して管理する機能を有している。
【００４４】
具体的には、図２に示すように、エンド端末５からメディアゲートウェイ３までの通信経路にはコアネットワークに向かうに従って収容容量の大きなノード（ＰＯＮ、Ｌ２ＳＷ、ＭＧ、等）が複数配備されているため、ノード間の仮想パス毎に仮想識別子（アクセスライン仮想パス＃１、アクセスライン仮想パス＃２、ＰＯＮ仮想パス＃１、等）を付与し、仮想識別子毎に上限帯域や使用帯域をＳＩＰ通信ネットワークのリソース情報として管理している。
【００４５】
機能開始時刻記録部１２ｂは、メディア帯域の帯域量を所定の帯域量に変化させて管理必要な機能が呼処理サーバ１に追加された場合に、追加された機能が呼処理サーバ１で開始された機能開始時刻を記録する機能を有している。
【００４６】
例えば、ＳＩＰネゴシエーションで決定したメディア帯域を１．２倍して管理する必要が生じた場合に、そのメディア帯域に補正係数を乗算する機能プログラムが追加されたケースが一例として挙げられる。その他、メディア帯域を実効帯域値に補正する機能プログラムや、設定粒度を補正する機能プログラムや、メディア毎のトラヒック特性を考慮してメディア帯域を補正する機能プログラムが挙げられるが、前述したようにメディア帯域の帯域量を所定の帯域量に変化させて管理必要な機能であれば、どのような機能であってもよい。
【００４７】
使用帯域調整部１２ｃは、リソース管理部１２ａで記憶管理している上記記憶手段から使用帯域の帯域量を読み出して、その使用帯域の帯域量を機能開始時刻後の帯域量に変更する機能を有している。具体的には、各メディア帯域の上記所定の帯域量への変化の全体に対応するように使用帯域の帯域量を変更する。例えば、各メディア帯域の帯域量を所定倍に変化させて管理必要な機能が追加された場合には、記憶管理している使用帯域を同様に所定倍する。
【００４８】
使用帯域再調整部１２ｄは、各メディア帯域に係る呼の生起時刻と機能開始時刻記録部１２ｂで記録した機能開始時刻とをそれぞれ比較し、機能開始時刻後であって、且つ使用帯域調整部１２ｃにより使用帯域の帯域量が変更される前から既に変更後の帯域量を有していたメディア帯域が使用帯域に含まれている場合には、そのメディア帯域に係る機能開始時刻後の帯域量と機能開始時刻前の帯域量との差分帯域量を変更後の使用帯域の帯域量から減算することで、使用帯域調整部１２ｃにより変更調整された調整後の使用帯域を再調整する機能を有している。すなわち、変更後の帯域量を有していたメディア帯域が使用帯域に既に含まれている場合には、使用帯域調整部１２ｃにより更に所定倍されるため、過調整された当該所定倍の帯域量分を減算することにより、使用帯域を適正化している。
【００４９】
使用帯域計算部１２ｅは、リソース管理部１２ａと機能開始時刻記録部１２ｂと使用帯域調整部１２ｃと使用帯域再調整部１２ｄとによって、記憶手段に記憶管理されている使用帯域が調整（再調整を含む）された後に、新規メディア帯域の予約要求又は確保要求や、既存メディア帯域の開放要求又は帯域変更要求があった場合に、各メディア帯域の帯域量を用いて使用帯域を計算して、各要求に応じた処理を行う機能を有している。詳細機能については処理フロー内で説明する。
【００５０】
ＭＧ制御部１２ｆは、新規メディア帯域の予約要求又は確保要求があった場合に、新規メディアに係る呼の流出入を可能とするようにメディアゲートウェイ３を制御する機能を有している。
【００５１】
次に、リソース管理装置１２の処理フローについて説明する。図３は、使用帯域を調整又は再調整するまでの処理フローを示す図である。
【００５２】
最初に、呼処理サーバ１に上述した機能が追加されて開始された場合に、機能開始時刻記録部１２ｂにより、機能開始時刻が記録される（Ｓ１）。
【００５３】
次いで、使用帯域調整部１２ｃにより、仮想パス毎に、記憶管理されている使用帯域の帯域量が機能開始時刻後の帯域量に変更される（Ｓ２）。このとき、メディア毎に保存している要求帯域については変更しない。
【００５４】
この所定の帯域量は、全て又は一部のメディア帯域に対して一定の大きさである必要はなく、メディア帯域毎に異なるものであってもよい。例えば、メディア帯域の帯域量が均一なサービスを提供している場合において、メディア帯域の帯域量を一律変化させる必要のあるサービス提供のための機能が追加された場合には、複数のメディア帯域を一つの束として群処理（例えば、６４ｋｂｐｓの電話のみ利用している場合には、メディア帯域×メディア数×１．２倍して使用帯域を調整）をしてもよい。一方、メディアの種別が異なる場合には、個々にメディア帯域を計算した後に合算して使用帯域を調整するようにしてもよい。
【００５５】
次いで、使用帯域再調整部１２ｄにより、各メディア帯域に係る呼の生起時刻と機能開始時刻記録部１２ｂで記録した機能開始時刻とがそれぞれ比較される（Ｓ３）。
【００５６】
Ｓ３の比較の結果、機能開始時刻後であって、且つ帯域量の変更前から既に変更後の帯域量を有していたメディア帯域が含まれている場合には、使用帯域再調整部１２ｄにより、仮想パス毎に、そのメディアについて機能開始時刻後の帯域量と機能開始時刻前の帯域量との差分帯域量が計算され、Ｓ２で変更された使用帯域から差分帯域量が減算される（Ｓ４）。
【００５７】
一方、Ｓ３の比較の結果、機能開始時刻後であって、且つ帯域量の変更前から既に変更後の帯域量を有していたメディア帯域が含まれていない場合には、使用帯域を再調整する必要がないので、そのままフローを終了する。
【００５８】
次に、使用帯域を調整後又は再調整後に各要求を受け付けた際の処理フローについて説明する。図４は、新規メディア帯域の予約要求又は確保要求があった場合の処理フローを示す図である。
【００５９】
最初に、使用帯域計算部１２ｅにより、新規メディア帯域の予約要求又は確保要求が受け付けられ、受付した情報が、リソース管理部１２ａにより記憶管理されている記憶手段に一時的に追加保存される（Ｓ１１，Ｓ１２）。
【００６０】
次いで、使用帯域計算部１２ｅにより、仮想パス毎に、各メディア帯域の帯域量を用いて使用帯域が計算される（Ｓ１３）。
【００６１】
次いで、使用帯域計算部１２ｅにより、仮想パス毎に、仮想パスの上限帯域とＳ１３で計算された仮想パスの使用帯域との差分である残帯域に新規メディア帯域の帯域量を許容できるか否か（収容できるか否か）が判断される（Ｓ１４）。
【００６２】
Ｓ１４での判断の結果、許容可能（収容可能）な場合に、使用帯域計算部１２ｅにより、新規メディア帯域の帯域量が使用帯域に加算される（Ｓ１５）。
【００６３】
次いで、ＭＧ制御部１２ｆにより、新規メディアに係る呼の流出入を許可するようにメディアゲートウェイ３に対してピンホール制御及びポリシー制御が行われる（Ｓ１６）。
【００６４】
次いで、ＭＧ制御部１２ｆにより、Ｓ１６での各制御が成功したか失敗したかが確認される（Ｓ１７）。
【００６５】
Ｓ１７での確認の結果、Ｓ１６での各制御が成功した場合に、予約要求成功応答又は確保要求成功応答が要求元の呼処理機能部１１に送信される（Ｓ１８）。
【００６６】
一方、Ｓ１４での判断の結果、許容不能（収容不可）な場合や、Ｓ１７での確認の結果、Ｓ１６での各制御が成功した場合には、予約要求失敗応答又は確保要求失敗応答が要求元の呼処理機能部１１に送信され（Ｓ１９）、Ｓ１５で加算する前の状態に使用帯域がロールバックされる（Ｓ２０）。
【００６７】
図５は、既存メディア帯域の開放要求又は変更要求があった場合の処理フローを示す図である。
【００６８】
最初に、使用帯域計算部１２ｅにより、既存メディア帯域の開放要求又は変更要求が受け付けられる（Ｓ３１）。
【００６９】
次いで、使用帯域計算部１２ｅにより、仮想パス毎に、各メディア帯域の帯域量を用いて使用帯域が計算される（Ｓ３２）。
【００７０】
次いで、使用帯域計算部１２ｅにより、仮想パス毎に、Ｓ３２で計算された使用帯域から開放対象の既存メディア帯域の帯域量が減算される（Ｓ３３）。
【００７１】
以上より、本実施の形態によれば、メディア帯域の帯域量を所定の帯域量に変化させて管理必要な機能が呼処理サーバ１に追加された場合に、その追加機能が開始された機能開始時刻を記録し、使用帯域の帯域量を機能開始時刻後の帯域量に変更し、メディア帯域に係る呼の生起時刻と機能開始時刻とを比較し、機能開始時刻後であって変更する前から既に所定の帯域量を有していたメディア帯域が含まれている場合には、そのメディア帯域に係る機能開始時刻後の帯域量と機能開始時刻前の帯域量との差分帯域量を変更後の使用帯域から減算するので、呼処理サーバ１に機能（例えば、メディア帯域を１．２倍する機能）が追加された時点や、該機能が変更（例えば、１．２倍されたメディア帯域を１．５倍に変更）された時点で各仮想パスの使用帯域を予め調整又は再調整しておくことが可能となる。
【００７２】
また、既に調整又は再調整された帯域を利用して予約要求等の各処理が実行されるので、予約要求等を受け付けた時点で機能追加前後の判断が不要となり、機能追加時におけるリソース管理装置の処理能力低下を抑制することが可能となる。
【００７３】
すなわち、機能が連続して追加された場合や、所定条件でメディア帯域の帯域量を変更することが連続した場合であっても、帯域の予約要求等に係る各処理を簡易に保つことが可能となり、高品質なリソース管理装置を提供することが可能となる。また、機能追加後であっても同一条件で同量のメディア帯域の使用をユーザに提供可能となり、ユーザ由来の継続呼の帯域量変更が生じた場合であっても、既に機能追加後の帯域を確保しているので、メディア通信の成功確度を高くすることが可能となる。更に、全ての使用帯域を予め機能追加後の帯域まで変更しておくことが可能となるので、各要求受付時にメディア帯域を変更する再計算を行う従来技術に比べて新規受付を抑制し、リソース不足を抑止することが可能となる。また、呼処理サーバ１における通常の呼処理能力を向上するという効果も得ることができる。
【実施例１】
【００７４】
全メディアに対する帯域補正係数を１．２倍に変更して管理必要な機能が追加された場合について説明する。図６は、実施例１におけるメディア帯域の調整・再調整を説明する図である。上段は、メディア毎の要求帯域であり、上記Ｓ２で説明したように、この要求帯域の帯域量については変更しない。一方、下段は、仮想パス上の使用帯域であり、各メディア帯域の帯域量をマージした値が使用帯域として管理されている。
【００７５】
時点Ａから時点Ｂに移行する間に機能が追加して開始され、時点Ｂでメディア＃４が追加された場合、その時点Ｂにおいて、メディア＃４は既に１．２倍の帯域量として管理されている。ここで、リソース管理部１２ａは時点Ｂでの使用帯域を管理しているものとする。
【００７６】
使用帯域調整部１２ｃは、時点Ｃにおいて、上記機能追加に伴って、現在の使用帯域の帯域量（時点Ｂのメディア＃１〜＃４のマージ値）に１．２倍の乗算を行って使用帯域を調整する。これにより、機能追加後の新サービス開始後には、全てのユーザの端末が機能追加後の帯域を使用可能となる。使用帯域を機能追加後の帯域に調整することにより、残帯域（仮想パスの上限帯域と使用帯域との差分）を新規メディアの追加要求によって消費されることを防止することが可能となる。
【００７７】
ただし、メディア＃４については余分に乗算されている（１．２倍×１．２倍）ので、使用帯域再調整部１２ｄは、時点Ｄにおいて、その余分な帯域量を減算する。これにより、仮想パスの残帯域がより適正化されることになる。
【００７８】
その後、時点Ｅにおいて、既存メディア＃３の開放要求を受け付けた場合には、該当する既存メディア＃３の帯域のみを削除する。従来のように開放要求を受け付けた時点での機能追加前後の判断ロジックは不要となる。
【実施例２】
【００７９】
次に、上り帯域であってメディア種別がデータのみのメディアに対する帯域補正係数を３倍に変更して管理必要な機能が追加された場合について説明する。図７は、実施例２におけるメディア帯域の調整・再調整を説明する図である。上段は、メディア毎の要求帯域であり、上記Ｓ２で説明したように、この要求帯域の帯域量については変更しない。一方、下段は、仮想パス上の使用帯域であり、各メディア帯域の帯域量をマージした値が使用帯域として管理されている。
【００８０】
時点Ａから時点Ｂに移行する間に機能が追加して開始され、時点Ｂでメディア＃４が追加された場合、その時点Ｂにおいて、メディア＃４は既に３倍の帯域量として管理されている。ここで、リソース管理部１２ａは時点Ｂでの使用帯域を管理しているものとする。
【００８１】
使用帯域調整部１２ｃは、時点Ｃにおいて、上記機能追加に伴って、現在の使用帯域の帯域量（音声用のメディア帯域＃０を除く時点Ｂのメディア＃１〜＃４のマージ値）に３倍の乗算を行って使用帯域を調整する。これにより、機能追加後の新サービス開始後には、全てのユーザの端末が機能追加後の帯域を使用可能となる。使用帯域を機能追加後の帯域に調整することにより、残帯域（仮想パスの上限帯域と使用帯域との差分）を新規メディアの追加要求によって消費されることを防止することが可能となる。
【００８２】
ただし、メディア＃４については余分に乗算されている（３倍×３倍）ので、使用帯域再調整部１２ｄは、時点Ｄにおいて、その余分な帯域量を減算する。これにより、仮想パスの残帯域がより適正化されることになる。
【００８３】
その後、時点Ｅにおいて、既存メディア＃３の開放要求を受け付けた場合には、該当する既存メディア＃３の帯域のみを削除する。従来のように開放要求を受け付けた時点での機能追加前後の判断ロジックは不要となる。
【００８４】
すなわち、リソース管理装置１２は、メディア種別、仮想パス種別、更には帯域の上り又は下り等に基づいて、メディア帯域を変更して使用帯域を調整することも可能である。
【実施例３】
【００８５】
実施例１又は実施例２で説明した時点Ｂから時点Ｃに移行する際にメディア帯域＃４は１．２倍又は３倍に変更されるが、その際に仮想パスの上限帯域を超える場合がある。時点Ｃから時点Ｄへの移行時においてメディア＃４の帯域量は再調整され、その結果当該上限帯域を超えない可能性もあるが、使用実態との剥離を極力避けるために、本実施例３の使用帯域調整部１２ｃは予閉塞処理（予閉塞機能）を行う。図８は、実施例３におけるメディア帯域の調整・再調整を説明する図である。
【００８６】
すなわち、使用帯域調整部１２ｃは、機能追加によって所定倍した使用帯域が仮想パスの上限帯域を超える場合に、使用帯域が上限帯域を下回るまで新規メディアの追加利用を抑止する。図８に示す例で言えば、使用帯域（メディア＃１〜メディア＃４のマージ値）が仮想パス＃２の上限帯域を超えているため、時点Ｃにおいて、メディア＃５の追加を拒否する。時点Ｄにおいて、メディア＃４を削除した場合、時点Ｅのように、仮想パス＃２の上限帯域内で許容可能なメディア＃６については追加可能としている。
【実施例４】
【００８７】
次に、これまで説明したリソース管理装置１２が使用されるモデルケースの一例について説明する。図９は、リソース管理装置の適用例を説明する図である。
【００８８】
通常、呼処理サーバ１は、サーバのダウンを想定して現用系（ＡＣＴ系：０系）と予備系（ＳＴＢ系：１系）とで構成されており、呼処理サーバ１に機能が追加される前は、現用系であっても予備系であっても旧ファイルで運用されている（Ｓ５１ａ，Ｓ５１ｂ）。
【００８９】
なお、ここでいうファイルとは、リソース管理部１２ａが記憶手段に記憶管理している仮想パス毎の使用帯域や上限帯域等のデータをファイル化したものをいい、旧ファイルとは、機能追加前のプログラムで動作することをいう。また、後述する新ファイルとは、機能追加後のプログラムで動作することをいう。
【００９０】
その後、呼処理サーバ１に追加された機能が開始された場合には、予備系を一端ＯＵＳ（Out Of Service）化して、記憶手段であるデータベースをコンバートした後に、予備系の旧ファイルを新ファイルに置き換えてＳＴＢ状態に戻し、予備系を新ファイルに置き換えた後に現用系で受け付けた呼については、メモリをコンバートして系間で同期する（Ｓ５２ａ，Ｓ５２ｂ，Ｓ５３，Ｓ５４ａ，Ｓ５４ｂ，Ｓ５５）。なお、メモリコンバートする理由は、実際の使用帯域は仮想パス毎にメモリ上で管理されているためである。
【００９１】
その後、予備系をＡＣＴ状態に変更して新ファイルを用いて運用を開始する（Ｓ５６ａ，Ｓ５６ｂ）。
【符号の説明】
【００９２】
１…呼処理サーバ
１１…呼処理機能部
１２…リソース管理装置
１２ａ…リソース管理部
１２ｂ…機能開始時刻記録部
１２ｃ…使用帯域調整部
１２ｄ…使用帯域再調整部
１２ｅ…使用帯域計算部
３…メディアゲートウェイ
５…エンド端末
７…ネットワーク機器
Ｓ１〜Ｓ４…ステップ
Ｓ１１〜Ｓ２０…ステップ
Ｓ３１〜Ｓ３３…ステップ
Ｓ５１〜Ｓ５６…ステップ
Ｓ７１〜Ｓ８１…ステップ
Ｓ９１〜Ｓ９６…ステップ
【図１】
2011228850.tif 000003
【図２】
2011228850.tif 000004
【図３】
2011228850.tif 000005
【図４】
2011228850.tif 000006
【図５】
2011228850.tif 000007
【図６】
2011228850.tif 000008
【図７】
2011228850.tif 000009
【図８】
2011228850.tif 000010
【図９】
2011228850.tif 000011
【図１０】
2011228850.tif 000012
【図１１】
2011228850.tif 000013
【図１２】
2011228850.tif 000014
【図１３】
2011228850.tif 000015