(57)【要約】  【課題】メディアゲートウェイの輻輳状態を効果的に防止・抑制することができる輻輳制御装置を提供する。  【解決手段】ＶｏＩＰネットワークにおいて公衆交換電話網に対する網端ゲートウェイの輻輳を制御するメディアゲートウェイ制御サーバ１０は、メディアゲートウェイ２０へ呼処理に関するリクエストコマンドを発行するコマンド発行部１１と、コマンド発行部１１から発行される前記リクエストコマンドを利用してメディアゲートウェイ２０の輻輳状態を検出する輻輳監視部１３と、輻輳監視部１３の検出結果にしたがって、メディアゲートウェイ２０への新規呼を抑制する新規呼抑制部１４とを備える。【選択図】図８
2010178185.tif 000002
【特許請求の範囲】
【請求項１】
ＶｏＩＰネットワークにおいて公衆交換電話網に対する網端ゲートウェイの輻輳を制御する輻輳制御装置であって、
当該輻輳制御装置から前記網端ゲートウェイへ呼処理に関するリクエストコマンドを発行するコマンド発行部と、
前記コマンド発行部から発行される前記リクエストコマンドを利用して前記網端ゲートウェイの輻輳状態を検出する輻輳監視部と、
前記輻輳監視部の検出結果にしたがって、前記網端ゲートウェイへの新規呼を抑制する新規呼抑制部とを備えたことを特徴とする輻輳制御装置。
【請求項２】
前記リクエストコマンドに対するレスポンスを受信するレスポンス受信部をさらに備え、
前記輻輳監視部が、前記リクエストコマンドの発行から、当該リクエストコマンドへのレスポンスの受信までの経過時間を閾値と比較することにより、前記網端ゲートウェイの輻輳状態を検出する、請求項１に記載の輻輳制御装置。
【請求項３】
前記輻輳監視部が、前記コマンド発行部から前記網端ゲートウェイへの一定時間当たりのコマンド送信量を閾値と比較することにより、前記網端ゲートウェイの輻輳状態を検出する、請求項１に記載の輻輳制御装置。
【請求項４】
前記輻輳監視部が、前記網端ゲートウェイの輻輳状態を複数段階に分類して検出し、
前記新規呼抑制部が、前記輻輳監視部により検出された輻輳状態の段階に応じた抑制率で新規呼の抑制を行う、請求項１〜３のいずれか一項に記載の輻輳制御装置。
【請求項５】
前記輻輳監視部が、前記網端ゲートウェイの通信中呼数をさらに利用して前記網端ゲートウェイの輻輳状態を検出する、請求項１〜４のいずれか一項に記載の輻輳制御装置。
【請求項６】
ＶｏＩＰネットワークにおいて公衆交換電話網に対する網端ゲートウェイの輻輳を制御する輻輳制御プログラムであって、
前記輻輳制御プログラムは、コンピュータのプロセッサに、
当該輻輳制御装置から前記網端ゲートウェイへ呼処理に関するリクエストコマンドを発行するコマンド発行処理と、
前記コマンド発行処理で発行される前記リクエストコマンドを利用して前記網端ゲートウェイの輻輳状態を検出する輻輳監視処理と、
前記輻輳監視処理の検出結果にしたがって、前記網端ゲートウェイへの新規呼を抑制する新規呼抑制処理とを実行させることを特徴とする輻輳制御プログラム。
【請求項７】
ＶｏＩＰネットワークにおいて公衆交換電話網に対する網端ゲートウェイの輻輳を制御する輻輳制御方法であって、
コンピュータのプロセッサが、当該輻輳制御装置から前記網端ゲートウェイへ呼処理に関するリクエストコマンドを発行するコマンド発行ステップと、
前記プロセッサが、前記コマンド発行ステップで発行される前記リクエストコマンドを利用して前記網端ゲートウェイの輻輳状態を検出する輻輳監視ステップと、
前記プロセッサが、前記輻輳監視ステップの検出結果にしたがって、前記網端ゲートウェイへの新規呼を抑制する新規呼抑制ステップとを含むことを特徴とする輻輳制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＶｏＩＰ（ボイス・オーバー・インターネット・プロトコル）ネットワーク上の輻輳制御に関し、特に、ＩＰネットワークを既存の公衆交換電話網（ＰＳＴＮ：Public Switched Telephone Network）に接続するための網端ゲートウェイ（メディアゲートウェイ）の輻輳状態を解消するための技術に関する。
【背景技術】
【０００２】
近年、インターネットプロトコルで通信を行うＩＰネットワークと、既存の公衆交換電話網（ＰＳＴＮ）とを接続し、音声をディジタルデータに変換してさらにパケット化することにより、双方のネットワーク間で音声通話ができるＩＰテレフォニーが利用可能となっている。このＩＰテレフォニーにおいて、ＩＰネットワークにおいてＰＳＴＮに対する網端ゲートウェイとして機能する装置は、一般的にメディアゲートウェイ（またはＶｏＩＰゲートウェイと呼ばれることもある）と呼ばれている。
【０００３】
ＩＰテレフォニーにおける課題の一つとして、メディアゲートウェイの輻輳が認識されている（例えば特許文献１参照）。メディアゲートウェイの輻輳は、例えば、ＩＰテレフォニーへの加入者の増大や、多くの加入者が一斉に特定の接続相手先へ発呼（発信）することによって起こり得る。メディアゲートウェイの輻輳は、通信のボトルネックとなるため、輻輳が生じる可能性を迅速に検知し、輻輳を解消する措置を講ずることが必要である。
【０００４】
なお、上記の特許文献１における輻輳制御技術は、ＩＰネットワーク内の各パスごとのパケット流量に基づいて各パスが輻輳状態になっているかを判定し、輻輳状態となっているパスにつき蓄積されているトラフィック分布の中で、最大要素をなす網端ゲートウェイ間トラフィックを規制するものである。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００２−２６１９２５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、上記従来の輻輳制御技術では、ＩＰネットワーク内の各パスのパケット流量の実測値に基づいて輻輳状態を判定するが、複雑なトポロジを有するネットワークにおいては、あるパスの輻輳状態が網端ゲートウェイ間トラフィックにどのような影響を及ぼすのかが推測困難である可能性がある。また、上記従来の輻輳制御技術では、個別のメディアゲートウェイの能力（回線数等）や稼働状態（接続中の回線数等）は考慮されていない。
【０００７】
以下の開示は、上述した従来の課題を鑑み、メディアゲートウェイの輻輳状態を効果的に防止・抑制することができる輻輳制御装置を提供することを目的とする。
【課題を解決するための手段】
【０００８】
上記の目的を達成するために、以下に開示の輻輳制御装置は、ＶｏＩＰネットワークにおいて公衆交換電話網に対する網端ゲートウェイの輻輳を制御する輻輳制御装置であって、当該輻輳制御装置から前記網端ゲートウェイへ呼処理に関するリクエストコマンドを発行するコマンド発行部と、前記コマンド発行部から発行される前記リクエストコマンドを利用して前記網端ゲートウェイの輻輳状態を検出する輻輳監視部と、前記輻輳監視部の検出結果にしたがって、前記網端ゲートウェイへの新規呼を抑制する新規呼抑制部とを備えた構成である。
【発明の効果】
【０００９】
上記の構成によれば、呼処理に関するリクエストコマンドを利用して、メディアゲートウェイの輻輳状態を効果的に防止・抑制することが可能となる。
【図面の簡単な説明】
【００１０】
【図１】図１は、本実施形態にかかるＩＰテレフォニーシステムの全体の概略構成を示すブロック図である。
【図２】図２は、第１の実施形態にかかるメディアゲートウェイ制御サーバによるメディアゲートウェイの輻輳制御の動作手順の一例を示すフローチャートである。
【図３】図３は、新規呼抑制の解除手順の一例を示す模式図である。
【図４】図４は、新規呼抑制とその解除手順の一例を示す模式図である。
【図５】図５は、新規呼抑制の解除手順の一例を示す模式図である。
【図６】図６は、新規呼抑制の解除手順の一例を示す模式図である。
【図７】図７は、新規呼抑制の解除手順の一例を示す模式図である。
【図８】図８は、第１の実施形態にかかるメディアゲートウェイ制御サーバの機能的構成を示すブロック図である。
【図９】図９は、第２の実施形態にかかるメディアゲートウェイ制御サーバによるメディアゲートウェイの輻輳制御の動作手順の一例を示すフローチャートである。
【発明を実施するための形態】
【００１１】
本発明の一実施形態にかかる輻輳制御装置は、ＶｏＩＰネットワークにおいて公衆交換電話網に対する網端ゲートウェイの輻輳を制御する輻輳制御装置であって、当該輻輳制御装置から前記網端ゲートウェイへ呼処理に関するリクエストコマンドを発行するコマンド発行部と、前記コマンド発行部から発行される前記リクエストコマンドを利用して前記網端ゲートウェイの輻輳状態を検出する輻輳監視部と、前記輻輳監視部の検出結果にしたがって、前記網端ゲートウェイへの新規呼を抑制する新規呼抑制部とを備えている。
【００１２】
この構成によれば、呼処理に関するリクエストコマンドを利用することにより、網端ゲートウェイの輻輳状態を的確に検出することができる。また、その検出結果にしたがって新規呼を抑制するので、網端ゲートウェイの輻輳を効果的に防止・解消することが可能となる。
【００１３】
上記の輻輳制御装置は、前記リクエストコマンドに対するレスポンスを受信するレスポンス受信部をさらに備え、前記輻輳監視部が、前記リクエストコマンドの発行から、当該リクエストコマンドへのレスポンスの受信までの経過時間を閾値と比較することにより、前記網端ゲートウェイの輻輳状態を検出することが好ましい。あるいは、前記輻輳監視部が、前記コマンド発行部から前記網端ゲートウェイへの一定時間当たりのコマンド送信量を閾値と比較することにより、前記網端ゲートウェイの輻輳状態を検出する構成も同様に好ましい。
【００１４】
上記の輻輳制御装置において、前記輻輳監視部が、前記網端ゲートウェイの輻輳状態を複数段階に分類して検出し、前記新規呼抑制部が、前記輻輳監視部により検出された輻輳状態の段階に応じた抑制率で新規呼の抑制を行うことが好ましい。段階的に新規呼の抑制を行うことにより、重い輻輳が生じない限りは、できるだけ新規呼を生成できるようにすることが可能となり、ネットワーク資源を有効利用できるからである。
【００１５】
上記の輻輳制御装置において、前記輻輳監視部が、前記網端ゲートウェイの通信中呼数をさらに利用して前記網端ゲートウェイの輻輳状態を検出することが好ましい。これにより、網端ゲートウェイの能力や現状を加味した輻輳制御が可能となるからである。
【００１６】
上記の輻輳制御装置において、前記新規呼抑制部による新規呼の抑制が開始された後に、所定の条件が満たされると新規呼の抑制を解除する呼抑制解除部をさらに備えたことが好ましい。さらに、前記所定の条件が複数段階に設定され、前記呼抑制解除部が、満たされた条件の段階に応じた抑制率で新規呼の抑制を解除することが好ましい。段階的に新規呼の抑制を解除することにより、輻輳状態がすぐに再発してしまう事態を防止できるからである。
【００１７】
本発明にかかる輻輳制御技術は、輻輳制御プログラムまたは輻輳制御方法としても実施可能である。
【００１８】
以下、本発明のより具体的な実施形態について図面を参照しながら詳細に説明する。
【００１９】
［第１の実施形態］
図１は、本実施形態にかかるＩＰテレフォニーシステムの全体の概略構成を示すブロック図である。図１に示すように、本実施形態にかかるＩＰテレフォニーシステムにおいては、ＩＰネットワーク１と、公衆交換電話網（ＰＳＴＮ）２とが、メディアゲートウェイ（ＭＧ）２０を介して接続されている。なお、図１においては、メディアゲートウェイ２０を１台のみ図示したが、１つのＩＰネットワーク１に複数台のメディアゲートウェイ２０が設けられていてもよい。
【００２０】
メディアゲートウェイ２０は、公衆交換電話網２に対するＩＰネットワーク１の網端ゲートウェイであり、音声をインターネットプロトコルで取り扱い可能なディジタルデータ（パケット化されたデータ）に変換する。なお、メディアゲートウェイは、ＶｏＩＰゲートウェイと呼ばれることもある。メディアゲートウェイ２０は、スタンドアローン型の装置として実施することも可能であるが、ルータ等の既存のネットワーク周辺機器内にソフトウェアモジュールとして組み込まれることもある。
【００２１】
メディアゲートウェイ制御サーバ１０は、ＩＰネットワーク１においてメディアゲートウェイ２０に対する輻輳制御を行う。なお、本実施形態のメディアゲートウェイ制御サーバ１０は、公衆交換電話網２に対するコールエージェントとしても機能するが、メディアゲートウェイ制御サーバ１０の外部にコールエージェントが別途設けられた構成であっても良い。その場合は、メディアゲートウェイ制御サーバ１０が、外部のコールエージェントから公衆交換電話網２への発呼を制御することとなる。
【００２２】
ＩＰネットワーク１は、共通線網３との通信を制御するＳＧＣ（Signaling Gateway Control）サーバ４０と、ＩＰ電話６０との通信を制御するＳＩＰ（Session Initiation Protocol）サーバ３０とをさらに有している。ＳＩＰサーバ３０とメディアゲートウェイ制御サーバ１０との間のインタフェースとしては、例えば、ＳＩＰ／ＵＤＰ／ＩＰプロトコルが用いられる。メディアゲートウェイ制御サーバ１０とＳＧＣサーバ４０との間のインタフェースとしては、例えば、ＭＴＰ３／ＵＤＰ／ＩＰプロトコルが用いられる。ＳＧＣサーバ４０と共通線網３との間の通信は、例えばＮｏ７／ＩＳＵＰにしたがって制御される。メディアゲートウェイ制御サーバ１０とメディアゲートウェイ２０との間のインタフェースとしては、例えば、Ｈ．２４８／ＵＤＰ／ＩＰプロトコルが用いられる。
【００２３】
また、図１では図示を省略しているが、ＩＰネットワーク１には、ＮＴＰ（Network Protocol）サーバや、ネットワークオペレーションに必要な機能（ＳＮＭＰ，ＦＴＰ，ＴＥＬＮＥＴ等）を提供するＥＭインタフェース等の様々なインタフェースが組み込まれることが一般的である。
【００２４】
以上の構成を有することにより、ＩＰネットワーク１の加入者のＩＰ電話６０と、公衆交換電話網２の加入者の固定電話７０との間で音声通話を行うことが可能となる。
【００２５】
ここで、本実施形態にかかるメディアゲートウェイ制御サーバ１０によるメディアゲートウェイ２０の輻輳制御の動作手順の一例について、図２を参照しながら説明する。図２に示す例においては、メディアゲートウェイ制御サーバ１０は、最初に、輻輳状態を検出するための閾値として、所定の時間を設定する（Ｏｐ１ｏ１）。この閾値は、メディアゲートウェイ制御サーバ１０がメディアゲートウェイ２０へ呼処理に関するリクエストコマンドを送信してからレスポンスを受信するまでの時間であって、この閾値を超えた場合に、メディアゲートウェイ２０が輻輳していると判断するために用いられる。なお、輻輳状態を検出するための上記の閾値は、通常のＩＰプロトコルで、リクエストを出してからレスポンスを受信するまでのタイムアウト値として規定されている値よりも短い時間に設定することが好ましい。なお、このＯｐ１０１は必須ではなく、閾値は初期値として適切に設定されており、必要な場合のみ閾値の変更を行うようにすれば良い。
【００２６】
メディアゲートウェイ制御サーバ１０は、メディアゲートウェイ２０へ呼処理に関するリクエストコマンドを送信すると、それに対するレスポンスを受信するまでの時間を計測し、その時間が前記閾値を超えたかどうかを判断する（Ｏｐ１０２）。レスポンス受信までの時間が閾値を超えた場合（Ｏｐ１０２の判断結果がＹｅｓ）、メディアゲートウェイ制御サーバ１０は、メディアゲートウェイ２０に対する新規呼を抑制する（Ｏｐ１０３）。なお、上記のリクエストコマンドとしては、呼制御に関するリクエストコマンドであれば、任意のコマンドを用いることができる。例えば、ＶｏＩＰのプロトコルとして普及しているＭＥＧＡＣＯ（Ｈ．２４８）であれば、AddReqeustコマンド、ModifyRequestコマンド、SubtractRequestコマンド等をＯｐ１０２の判断に用いることができる。なお、呼制御に関するコマンドの全てを輻輳検出に利用しても良いし、輻輳検出に用いるコマンドを一部のコマンドのみに限定しても良い。
【００２７】
なお、図２の例では、コマンド送信からレスポンス受信までの時間が閾値を超えたことを検出したらすぐに新規呼を抑制することとしているが、以下のような変形例も考えられる。例えば、コマンド送信からレスポンス受信までの時間が閾値を超えたことを所定の回数以上検出したときに、新規呼の抑制を実行してもよい。あるいは、コマンド送信からレスポンス受信までの時間が閾値を超えたことを、所定の時間内に所定の回数以上検出したときに、新規呼の抑制を実行するようにしてもよい。このように、新規呼の抑制を開始するための条件を若干厳しくすれば、比較的重い輻輳が生じるまでは新規呼が抑制されないので、通信パフォーマンスを維持できるという利点がある。
【００２８】
また、Ｏｐ１０２の処理の変形例として、レスポンス受信までの経過時間だけでなく、接続中の呼の数を加味して輻輳状態を検出しても良い。例えば、レスポンス受信までの経過時間に、その時点においてメディアゲートウェイ２０で通信中の呼の数に所定の係数を乗じて得られた値を加算し、その結果を閾値と比較するようにしても良い。この検出手法によれば、新たに送られるリクエストコマンドの影響だけでなく、その時点にメディアゲートウェイ２０で既に確立されている呼による負荷も加味した輻輳状態が検出できるという利点がある。
【００２９】
Ｏｐ１０３において新規呼の抑制処理を行うと、メディアゲートウェイ制御サーバ１０は、新規呼の抑制を開始した時刻からの所定の時間が経過するまでウェイト状態となる（Ｏｐ１０４）。そして、新規呼の抑制を開始してから所定の時間が経過すると、新規呼の抑制を緩和する（Ｏｐ１０５）。このＯｐ１０５においては、所定時間が経過したときに、新規呼の抑制を一切行わない（すなわち全ての新規呼を許可する）ようにしても良いし、時間経過に伴って段階的に抑制を緩和するようにしても良い。
【００３０】
例えば、後者の例としては、一定時間が経過する毎に、抑制率を所定の割合だけ下げるようなアルゴリズムを採用してもよい。なお、新規呼の抑制率とは、呼のリクエストがあってもリクエストを出さずに破棄する率を意味するものとする。より具体的な例を示せば、例えば、図３に示すように、新規呼の抑制を開始した時点では、新規呼を一切出さない（抑制率１００％）ものとし、それから所定の時間（Ｔ秒）が経過する毎に、抑制率を２０％ずつ下げていくという方法がある。なお、Ｔの値も、抑制率を段階的に下げる割合も、この例に限定されず、任意に設定することができる。また、抑制率を段階的に下げている途中で再び輻輳状態を検出した場合は、抑制率を１００％に戻すようにしてもよい。このように、新規呼の抑制を開始した後に、抑制率を段階的に下げていくことによって新規呼の抑制を解除する手法によれば、輻輳状態が十分に解消されるまでは新規呼の抑制を少なくとも部分的に行うことにより、輻輳によるパフォーマンス劣化を効果的に防止することができる。
【００３１】
あるいは、Ｏｐ１０３の新規呼の抑制についても、いきなり新規呼を１００％抑制するのではなく、閾値との関係に応じて段階的な抑制を行うようにしてもよい。より具体的な例を示せば、例えば、図４に示すように、コマンド送信からレスポンス受信までの時間が所定の閾値の７０％〜９０％までの間を「一次輻輳状態」とし、この一次輻輳状態が検出されたら新規呼の一部（例えば３０％）を抑制する。また、コマンド送信からレスポンス受信までの時間が所定の閾値の９０％〜１００％までの間を「二次輻輳状態」とし、この二次輻輳状態が検出されたら、新規呼の抑制率を一次輻輳状態よりも高い割合（例えば８０％）とする。そして、コマンド送信からレスポンス受信までの時間が所定の閾値を超えたら、新規呼を１００％抑制する。なお、ここで挙げた一次輻輳状態および二次輻輳状態の基準値と、それぞれの状態における抑制率の数値もあくまでも一例であり、任意の値への変更が可能である。また、より細かい段階設定によって新規呼の抑制を行うようにしてもよい。
【００３２】
さらなる変形例として、新規呼の抑制を開始した後に、その後のメディアゲートウェイ２０における通信状況に応じて新規呼抑制の解除を行うようにすることも考えられる。この変形例の一つの具体例を、図５を参照しながら説明する。例えば、Ｏｐ１０３で新規呼抑制を開始した時点で、その時点におけるメディアゲートウェイ２０において通信中の回線数を検出する。そして、新規呼抑制を開始した後に時間が経過し、通信中の回線数が、抑制開始時に対して所定の割合（例えば７０％）を下回った時点で、新規呼の抑制率を所定の割合（例えば５０％）まで引き下げる。そして、さらに時間が経過し、通信中の回線数が、抑制開始時に対してさらに低い割合（例えば５０％）まで下がった時点で、新規呼の抑制を完全に解除する。なお、ここで挙げた通信中の回線数についての閾値およびそれぞれの時点における抑制率の数値もあくまでも一例であり、任意の値への変更が可能である。また、この変形例においても、より細かい段階設定によって新規呼抑制の解除を行うようにしてもよい。このように、新規呼の抑制を開始した後に、メディアゲートウェイ２０の通信状況に応じて新規呼抑制の解除を行うことにより、メディアゲートウェイ２０の能力や実際の通信状況に即した呼制御が可能となるので、ネットワーク資源の有効活用が図られるという利点がある。
【００３３】
また、上記の変形例のさらなる具体例としては、図６に示すような段階的な抑制解除の方法も考えられる。例えば、Ｏｐ１０３で新規呼抑制を開始した後に、メディアゲートウェイ２０における通信中の回線数の総回線数に対する比率を、適宜のタイミングで検出する。そして、上記の比率が所定の割合（例えば７０％）を下回った時点で、新規呼の抑制率を所定の割合（例えば５０％）まで引き下げる。そして、上記の比率がさらに低い値（例えば５０％）まで下がった時点で、新規呼の抑制を完全に解除する。なお、ここで挙げた上記比率についての閾値およびそれぞれの時点における抑制率の数値もあくまでも一例であり、任意の値への変更が可能である。また、この変形例においても、より細かい段階設定によって新規呼抑制の解除を行うようにしてもよい。
【００３４】
また、上記の変形例のさらなる具体例としては、図７に示すような段階的な抑制解除の方法も考えられる。例えば、Ｏｐ１０３で新規呼抑制を開始した後に、その時点におけるメディアゲートウェイ２０において通信中の回線数を検出する。そして、新規呼抑制を開始した後に通信が終了した回線数をカウントし、通信が終了した回線数が所定数（例えば５０回線）に到達した時点で、新規呼の抑制率を所定の割合（例えば５０％）まで引き下げる。そして、さらに時間が経過し、通信が終了した回線数がさらに増えて所定数（例えば１００回線）に達した時点で、新規呼の抑制を完全に解除する。なお、ここで挙げた、通信が終了した回線数についての閾値およびそれぞれの時点における抑制率の数値もあくまでも一例であり、任意の値への変更が可能である。また、この変形例においても、より細かい段階設定によって新規呼抑制の解除を行うようにしてもよい。
【００３５】
以上に説明したように、第１の実施形態にかかるメディアゲートウェイ制御サーバ１０は、メディアゲートウェイ２０に対して呼制御に関するリクエストコマンドを出したときに、それに対するレスポンスの受信までの時間に基づいて、メディアゲートウェイ２０の輻輳状態を判断する。そして、その判断結果に基づいてメディアゲートウェイ２０への新規呼を抑制することにより、メディアゲートウェイ２０の輻輳を効果的に防止し、かつ、輻輳が生じてもその輻輳を速やかに解消することができる。
【００３６】
ここで、図８を参照し、上記の機能を実現するためのメディアゲートウェイ制御サーバ１０の機能的構成例について説明する。図８に示すように、メディアゲートウェイ制御サーバ１０は、コマンド発行部１１と、レスポンス受信部１２と、輻輳監視部１３と、新規呼抑制部１４と、呼抑制解除部１５と、閾値記憶部１６とを備えている。
【００３７】
コマンド発行部１１は、メディアゲートウェイ２０、ＳＩＰサーバ３０、ＳＧＣサーバ４０に対する各種コマンドを生成し、これらのサーバへ送出する。コマンド発行部１１からメディアゲートウェイ２０へ発行されるコマンドには、前述したAddRequest等の、輻輳状態の検出に用いるリクエストコマンドが含まれる。
【００３８】
レスポンス受信部１２は、コマンド発行部１１が発行したコマンドに対するレスポンスを受信する。輻輳監視部１３は、コマンド発行部１１が発行したコマンドに対するレスポンスを監視することにより、輻輳状態を検出する。特に、本実施形態にかかる輻輳監視部１３は、Ｏｐ１０２の処理を行う点に特徴がある。すなわち、本実施形態にかかる輻輳監視部１３は、コマンド発行部１１がコマンドを発行してから、レスポンス受信部１２が当該コマンドへのレスポンスを受信するまでの時間を計測すると共に、計測された時間が所定の閾値以内であるか否かを判断することにより、メディアゲートウェイ２０で輻輳が起きているかどうかを判断する。
【００３９】
新規呼制御部１４は、図２のＯｐ１０３の処理を行う。すなわち、輻輳監視部１３により、メディアゲートウェイ２０の輻輳状態が検出されたときに、コマンド発行部１１を介した新規呼の生成を抑制する。
【００４０】
呼抑制解除部１５は、図２のＯｐ１０５の処理を行う。すなわち、新規呼抑制開始から所定の時間が経過した場合、あるいは、前記において各種変形例として説明したように、新規呼抑制を少なくとも部分的に解除して良いと判断された場合に、新規呼の抑制を解除する。
【００４１】
閾値記憶部１６は、メディアゲートウェイ制御サーバ１０の処理で参照される各種の閾値を記憶するメモリである。
【００４２】
なお、メディアゲートウェイ制御サーバ１０は、スタンドアローン型のサーバとしても実施可能であるが、前述したとおり、サーバやルータ等の既存のネットワーク周辺機器上のソフトウェアモジュール（プログラム）としても実施可能である。すなわち、プロセッサによってプログラムを実行することにより、サーバやルータ等に図２に示すような機能ブロック群が実現される態様も、本発明の一実施形態に相当する。また、そのようなプログラムを格納した記憶媒体も、本発明の一実施形態に相当する。
【００４３】
［第２の実施形態］
本発明の第２の実施形態について、以下に説明する。なお、第２の実施形態にかかる
メディアゲートウェイ制御サーバ１０は、図９に示すとおり、メディアゲートウェイ２０の輻輳状態の判断手法が異なる以外は、第１の実施形態と同様の処理を行い、その機能的構成も、第１の実施形態において図８に示した構成と同様である。
【００４４】
すなわち、図９に示すとおり、本実施形態におけるメディアゲートウェイ制御サーバ１０は、第１の実施形態において図２に示したＯｐ１０２の代わりに、一定時間当たりにメディアゲートウェイ２０へ送られるリクエストコマンドの量を所定の閾値と比較することにより、メディアゲートウェイ２０の輻輳状態を検出する（Ｏｐ２０２）。なお、Ｏｐ２０２以外の処理は、第１の実施形態と同様であるので、他の処理の説明は省略する。また、第１の実施形態において説明した各種の変形例も、第２の実施形態に適用することが可能である。
【００４５】
なお、Ｏｐ２０２において検出されるリクエストコマンドの量とは、一定時間当たりのリクエストコマンドの数であっても良いし、リクエストコマンドのデータ量であっても良い。
【００４６】
また、第２の実施形態の変形例として、リクエストコマンドの量だけでなく、接続中の呼の数を加味して輻輳状態を検出しても良い。例えば、一定時間当たりのリクエストコマンドの送信量に、その時点においてメディアゲートウェイ２０で通信中の呼の数に所定の係数を乗じて得られた値を加算し、その結果を閾値と比較するようにしても良い。この検出手法によれば、新たに送られるリクエストコマンドの影響だけでなく、その時点にメディアゲートウェイ２０で既に確立されている呼による負荷も加味した輻輳状態が検出できるという利点がある。
【００４７】
以上、具体的な実施形態を例示したが、上述の実施形態およびその変形例は本発明を限定するものではなく、発明の範囲内で種々の変更が可能である。
【００４８】
なお、上記の各実施形態に加えて、以下の付記を開示する。
【００４９】
（付記１）
ＶｏＩＰネットワークにおいて公衆交換電話網に対する網端ゲートウェイの輻輳を制御する輻輳制御装置であって、
当該輻輳制御装置から前記網端ゲートウェイへ呼処理に関するリクエストコマンドを発行するコマンド発行部と、
前記コマンド発行部から発行される前記リクエストコマンドを利用して前記網端ゲートウェイの輻輳状態を検出する輻輳監視部と、
前記輻輳監視部の検出結果にしたがって、前記網端ゲートウェイへの新規呼を抑制する新規呼抑制部とを備えたことを特徴とする輻輳制御装置。
【００５０】
（付記２）
前記リクエストコマンドに対するレスポンスを受信するレスポンス受信部をさらに備え、
前記輻輳監視部が、前記リクエストコマンドの発行から、当該リクエストコマンドへのレスポンスの受信までの経過時間を閾値と比較することにより、前記網端ゲートウェイの輻輳状態を検出する、付記１に記載の輻輳制御装置。
【００５１】
（付記３）
前記輻輳監視部が、前記コマンド発行部から前記網端ゲートウェイへの一定時間当たりのコマンド送信量を閾値と比較することにより、前記網端ゲートウェイの輻輳状態を検出する、付記１に記載の輻輳制御装置。
【００５２】
（付記４）
前記輻輳監視部が、前記網端ゲートウェイの輻輳状態を複数段階に分類して検出し、
前記新規呼抑制部が、前記輻輳監視部により検出された輻輳状態の段階に応じた抑制率で新規呼の抑制を行う、付記１〜３のいずれか一項に記載の輻輳制御装置。
【００５３】
（付記５）
前記輻輳監視部が、前記網端ゲートウェイの通信中呼数をさらに利用して前記網端ゲートウェイの輻輳状態を検出する、付記１〜４のいずれか一項に記載の輻輳制御装置。
【００５４】
（付記６）
前記新規呼抑制部による新規呼の抑制が開始された後に、所定の条件が満たされると新規呼の抑制を解除する呼抑制解除部をさらに備えた、付記１〜５のいずれか一項に記載の輻輳制御装置。
【００５５】
（付記７）
前記所定の条件が複数段階に設定され、
前記呼抑制解除部が、満たされた条件の段階に応じた抑制率で新規呼の抑制を解除する、付記６に記載の輻輳制御装置。
【００５６】
（付記８）
ＶｏＩＰネットワークにおいて公衆交換電話網に対する網端ゲートウェイの輻輳を制御する輻輳制御プログラムであって、
前記輻輳制御プログラムは、コンピュータのプロセッサに、
当該輻輳制御装置から前記網端ゲートウェイへ呼処理に関するリクエストコマンドを発行するコマンド発行処理と、
前記コマンド発行処理で発行される前記リクエストコマンドを利用して前記網端ゲートウェイの輻輳状態を検出する輻輳監視処理と、
前記輻輳監視処理の検出結果にしたがって、前記網端ゲートウェイへの新規呼を抑制する新規呼抑制処理とを実行させることを特徴とする輻輳制御プログラム。
【００５７】
（付記９）
ＶｏＩＰネットワークにおいて公衆交換電話網に対する網端ゲートウェイの輻輳を制御する輻輳制御方法であって、
コンピュータのプロセッサが、当該輻輳制御装置から前記網端ゲートウェイへ呼処理に関するリクエストコマンドを発行するコマンド発行ステップと、
前記プロセッサが、前記コマンド発行ステップで発行される前記リクエストコマンドを利用して前記網端ゲートウェイの輻輳状態を検出する輻輳監視ステップと、
前記プロセッサが、前記輻輳監視ステップの検出結果にしたがって、前記網端ゲートウェイへの新規呼を抑制する新規呼抑制ステップとを含むことを特徴とする輻輳制御方法。
【産業上の利用可能性】
【００５８】
本発明は、メディアゲートウェイの輻輳制御装置および輻輳制御プログラムならびに輻輳制御方法として、産業上の利用が可能である。
【符号の説明】
【００５９】
１      ＩＰネットワーク
２      公衆交換電話網（ＰＳＴＮ）
３      共通線網
１０    メディアゲートウェイ制御サーバ（輻輳制御装置）
１１    コマンド発行部
１２    レスポンス受信部
１３    輻輳監視部
１４    新規呼抑制部
１５    呼抑制解除部
１６    閾値記憶部
２０    メディアゲートウェイ（網端ゲートウェイ）
３０    ＳＩＰサーバ
４０    ＳＧＣサーバ
６０    ＩＰ電話
７０    固定電話
【図１】
2010178185.tif 000003
【図２】
2010178185.tif 000004
【図３】
2010178185.tif 000005
【図４】
2010178185.tif 000006
【図５】
2010178185.tif 000007
【図６】
2010178185.tif 000008
【図７】
2010178185.tif 000009
【図８】
2010178185.tif 000010
【図９】
2010178185.tif 000011