JP2007208570A - ネットワーク、メディア・ゲートウェイ装置及びそれらに用いる内部リソース管理方法 - Google Patents

Abstract

【課題】 ＭＧＷの内部リソースの分割損をなくし、ＭＧＷの内部リソースを有効活用可能なメディア・ゲートウェイ装置を提供する。
【解決手段】 ＭＧＷ２のサービス開始時及びリスタート時に、呼制御管理部２１はＭＧＣ（＃０）１−０〜ＭＧＣ（＃ｎ）１−ｎに対して、サービス登録要求信号を送信する。サービス登録要求信号を受信したＭＧＣ（＃０）１−０〜ＭＧＣ（＃ｎ）１−ｎは、その応答としてサービス登録要求応答信号を返送する。呼制御管理部２１は正常に応答を受信したＭＧＣを対象に、呼処理の実施対象のＭＧＣとして登録を行う。少なくとも１つのＭＧＣからサービス登録要求応答信号を受信した場合、呼制御管理部２１はサービス中となる。呼制御管理部２１は正常に応答を受信できなかったＭＧＣのみを対象に、サービス登録要求信号の再送を一定周期で繰り返す。
【選択図】 図１

Description

本発明はネットワーク、メディア・ゲートウェイ装置及びそれらに用いる内部リソース管理方法に関し、特に複数のＭＧＣ（Ｍｅｄｉａ Ｇｅｔｗａｙ Ｃｏｎｔｒｏｌｌｅｒ：メディア・ゲートウェイ・コントローラ）から制御されるＭＧＷ（Ｍｅｄｉａ ＧｅｔＷａｙ：メディア・ゲートウェイ）の内部リソースの管理方法に関する。

近年、ＶｏＩＰ（Ｖｏｉｃｅ ｏｖｅｒ Ｉｎｔｅｒｅｎｔ Ｐｒｏｔｏｃｏｌ）用のＤＳＰ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｏｒ）の処理能力が向上してきており、１個のＤＳＰで処理できるチャネル数が増えてきている。それに伴い、ＭＧＷについても多数のチャネルを収容する、大規模ネットワーク用のものが登場してきている。

しかしながら、ＭＧＷを制御するＭＧＣが、ＭＧＷの収容するチャネルを全て制御することができる程の処理能力を持っていない場合がある。ＭＧＣはＭＧＷをＩＴＵ−Ｔ（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｕｎｉｏｎ−Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｔａｎｄａｒｄｉｚａｔｉｏｎ Ｓｅｃｔｏｒ）やＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）で標準化されているＭｅｇａｃｏ（Ｍｅｄｉａ Ｇａｔｅｗａｙ Ｃｏｎｔｒｏｌ）／Ｈ．２４８プロトコル（ＩＴＵ−Ｔ Ｈ．２４８）（例えば、非特許文献１参照）にて制御している。

しかしながら、このＭｅｇａｃｏにおいては、マスタ（Ｍａｓｔｅｒ）／スレーブ（Ｓｌａｖｅ）の関係なので、基本的にはＭＧＣとＭＧＷとが１対１の関係となり、ＭＧＷの能力をフルに発揮できない場合がある。

"Ｍｅｇａｃｏ Ｐｒｏｔｏｃｏｌ Ｖｅｒｓｉｏｎ １．０ １１．ＭＧ−ＭＧＣ ＣＯＮＴＲＯＬ ＩＮＴＥＲＦＡＣＥ"［ＲＦＣ（Ｒｅｑｕｅｓｔ Ｆｏｒ Ｃｏｍｍｅｎｔｓ）３０１５，Ｎｏｖｅｍｂｅｒ ２０００，ｐｐ．７１〜７５］

上述した従来のＭＧＣによるＭＧＷ制御では、ＭＧＣとＭＧＷとが１対１の関係である必要があるので、ＭＧＷにおいてリソースの分割損が発生し、リソースを有効活用することができないという問題がある。

つまり、従来のＭＧＣによるＭＧＷ制御では、ＭＧＣ各々のために、ＭＧＷ内部のリソースをＭＧＣ単位毎に固定で分割し、各ＭＧＣと仮想的に分割されたＭＧＷとが仮想的かつ固定的に１対１の関係となり、呼処理を実施しているため、ＭＧＷにおいてリソースの分割損が発生し、リソースを有効活用することができない。

そこで、本発明の目的は上記の問題点を解消し、ＭＧＷの内部リソースの分割損をなくし、ＭＧＷの内部リソースを有効活用することができるネットワーク、メディア・ゲートウェイ装置及びそれらに用いる内部リソース管理方法を提供することにある。

本発明によるネットワークは、複数のメディア・ゲートウェイ・コントローラがメディア・ゲートウェイ装置を制御するネットワークであって、
前記メディア・ゲートウェイ装置は、前記複数のメディア・ゲートウェイ・コントローラ全てにサービス登録要求を送信する手段と、このサービス登録要求に対して正常に応答を返信したメディア・ゲートウェイ・コントローラを自装置に登録する手段と、前記複数のメディア・ゲートウェイ・コントローラのうちのいずれかから自装置内部のリソース情報を要求するリソース情報要求を受信した時に前記複数のメディア・ゲートウェイ・コントローラ全てに自装置内部のリソース情報を通知する手段とを備え、
前記メディア・ゲートウェイ装置は、自装置に登録したメディア・ゲートウェイ・コントローラによる内部リソースの使用を可能としている。

本発明によるメディア・ゲートウェイ装置は、複数のメディア・ゲートウェイ・コントローラにて制御されるメディア・ゲートウェイ装置であって、
前記複数のメディア・ゲートウェイ・コントローラ全てにサービス登録要求を送信する手段と、このサービス登録要求に対して正常に応答を返信したメディア・ゲートウェイ・コントローラを自装置に登録する手段と、前記複数のメディア・ゲートウェイ・コントローラのうちのいずれかから自装置内部のリソース情報を要求するリソース情報要求を受信した時に前記複数のメディア・ゲートウェイ・コントローラ全てに自装置内部のリソース情報を通知する手段とを備え、
自装置に登録したメディア・ゲートウェイ・コントローラによる内部リソースの使用を可能としている。

本発明による内部リソース管理方法は、複数のメディア・ゲートウェイ・コントローラがメディア・ゲートウェイ装置を制御するネットワークにおいて前記メディア・ゲートウェイ装置の内部リソースを管理する内部リソース管理方法であって、
前記メディア・ゲートウェイ装置が、前記複数のメディア・ゲートウェイ・コントローラ全てにサービス登録要求を送信する処理と、このサービス登録要求に対して正常に応答を返信したメディア・ゲートウェイ・コントローラを自装置に登録する処理と、前記複数のメディア・ゲートウェイ・コントローラのうちのいずれかから自装置内部のリソース情報を要求するリソース情報要求を受信した時に前記複数のメディア・ゲートウェイ・コントローラ全てに自装置内部のリソース情報を通知する処理とを実行し、
前記メディア・ゲートウェイ装置が、自装置に登録したメディア・ゲートウェイ・コントローラによる内部リソースの使用を可能としている。

すなわち、本発明のネットワークは、複数のＭＧＣ（Ｍｅｄｉａ Ｇｅｔｗａｙ Ｃｏｎｔｒｏｌｌｅｒ：メディア・ゲートウェイ・コントローラ）がＭＧＷ（Ｍｅｄｉａ ＧｅｔＷａｙ：メディア・ゲートウェイ）を制御するネットワークにおいて、ＭＧＷに、複数のＭＧＣ全てにサービス登録要求を送信する手段と、このサービス登録要求に対して正常に応答を返信したＭＧＣを自装置に登録する手段と、複数のＭＧＣのうちのいずれかから自装置内部のリソース情報を要求するリソース情報要求を受信した時に複数のＭＧＣ全てに自装置内部のリソース情報を通知する手段とを備えている。

これによって、本発明のネットワークでは、ＭＧＷが通信する複数のＭＧＣを登録（ｒｅｇｉｓｔｒａｔｉｏｎ）し、全てのＭＧＣに対してＭＧＷのリソース情報の変化を適宜通知することで、ＭＧＷのリソースの分割損の発生をなくし、ＭＧＷ内部のリソースを有効活用することが可能となる。

ＩＥＴＦ ＲＦＣ３５２５［“Ｇｅｔｗａｙ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ Ｖｅｒｓｉｏｎ １”（Ｊｕｎｅ ２００３）：非特許文献２］で定義されている通常のＭｕｌｔｉｐｌｅ Ｖｉｒｔｕａｌ ＭＧＷでは、各々のＭＧＣのために、ＭＧＷ内部のリソースを各々のＭＧＣ単位毎に分割し、各々のＭＧＣと仮想的に分割されたＭＧＷとが、仮想的に１対１の関係となり、呼処理を実施している。

これに対し、本発明のネットワークでは、複数のＭＧＣ各々のためにＭＧＷ内部のリソース分割を実施することなく、ＭＧＷと接続する全てのＭＧＣがＭＧＷ内部のリソースをフレキシブルに使用することが可能となる。

より具体的に説明すると、本発明のネットワークでは、ＭＧＣ＃０のリソースを「１０００ｃｈ」とした場合、ＭＧＷの内部リソースのうち、ＭＧＣ＃０用のために内部リソースを分割し、その内部リソース＃０を「１０００ｃｈ」とする。この時、ＭＧＣ＃０はＭＧＷの内部リソースのうち、内部リソース＃０のみを使用することが可能となる。しかしながら、ＭＧＣ＃１、ＭＧＣ＃ｎは、ＭＧＷの内部リソース＃０を使用することができない。

つまり、ＭＧＷの内部リソース＃０は、ＭＧＣ＃０にのみ使用されるが、ＭＧＣ＃１、ＭＧＣ＃ｎが使用することはできない。この関係を、上述している１対１の関係と呼ぶ。同様に、ＭＧＣ＃１が使用可能なＭＧＷの内部リソースは、内部リソース＃１のみであり、１対１の関係である。また、ＭＧＣ＃ｎが使用可能なＭＧＷの内部リソースは、内部リソース＃ｎのみであり、１対１の関係である。

上述の１対１の関係をなくし、ＭＧＣ＃０〜ＭＧＣ＃ｎ各々が、ＭＧＷの内部リソースを処理能力以内であれば自由に使用することが可能となる。簡単に説明すると、ＭＧＷの内部リソースを最大「３０００ｃｈ」とした場合に、既にＭＧＣ＃０とＭＧＣ＃１とによって合計「１０００ｃｈ」のＭＧＷの内部リソースが使用されているので、残りの「２０００ｃｈ」はＭＧＣ＃０及びＭＧＣ＃１以外のＭＧＣ＃ｎが自由に使用することが可能となる。これによって、ＭＧＷの内部リソースが使用されていない場合でも、特定のＭＧＣ以外の別のＭＧＣが自由にＭＧＷの内部リソースを使用することが可能となり、分割損が発生しないため、ＭＧＷの内部リソースを有効活用することが可能となる。また、本発明のネットワークでは、ＭＧＷにおけるＭＧＣのための制御処理が軽くなる。

本発明は、上記のような構成及び動作とすることで、ＭＧＷの内部リソースの分割損をなくし、ＭＧＷの内部リソースを有効活用することができるという効果が得られる。

次に、本発明の実施例について図面を参照して説明する。図１〜図３は本発明の一実施例によるＭＧＷ（Ｍｅｄｉａ ＧｅｔＷａｙ：メディア・ゲートウェイ）の動作を説明するための図である。図１〜図３において、本発明の一実施例によるネットワークはＭＧＷ２と、ＭＧＣ（Ｍｅｄｉａ Ｇｅｔｗａｙ Ｃｏｎｔｒｏｌｌｅｒ：メディア・ゲートウェイ・コントローラ）（＃０〜＃ｎ）１−０〜１−ｎとから構成されている。

図１において、ＭＧＣ＃０（１−１）のリソースを「１０００ｃｈ」とした場合、ＭＧＷ２の内部リソースのうち、ＭＧＣ（＃０）１−０用のために内部リソースを分割し、その内部リソース２０−０を「１０００ｃｈ」とする。この時、ＭＧＣ（＃０）１−０は、ＭＧＷ２の内部リソース２０−０〜２０−ｎのうち、内部リソース２０−０のみを使用することができる。しかしながら、ＭＧＣ（＃１）１−１〜ＭＧＣ（＃ｎ）１−ｎは、ＭＧＷ２の内部リソース２０−０を使用することができない。

つまり、ＭＧＷ２の内部リソース２０−０は、ＭＧＣ（＃０）１−０にのみ使用されるが、ＭＧＣ（＃１）１−１〜ＭＧＣ（＃ｎ）１−ｎが使用することはできない。この関係を、上述している１対１の関係と呼ぶ。同様に、ＭＧＣ（＃１）１−１が使用可能なＭＧＷ２の内部リソースは、内部リソース２０−１のみであり、１対１の関係である。また、ＭＧＣ（＃ｎ）１−ｎが使用可能なＭＧＷ２の内部リソースは、内部リソース２０−ｎのみであり、１対１の関係である。

本実施例では、上述の１対１の関係をなくし、図２に示す通り、ＭＧＣ（＃０）１−０〜ＭＧＣ（＃ｎ）１−ｎ各々がＭＧＷ２の内部リソースを処理能力以内であれば自由に使用することが可能となる。

これを図３を用いて簡単に説明すると、ＭＧＷ２の内部リソースを最大「３０００ｃｈ」とした場合には、既にＭＧＣ（＃０）１−０とＭＧＣ（＃１）１−１とによって合計「１０００ｃｈ」のＭＧＷ２の内部リソース２０が使用されているので、残りの「２０００ｃｈ」はＭＧＣ（＃０）１−０及びＭＧＣ（＃１）１−１以外のＭＧＣ（＃２）１−２〜ＭＧＣ（＃ｎ）１−ｎが自由に使用することが可能となる。

これによって、ＭＧＷ２の内部リソース２０が使用されていない場合でも、特定のＭＧＣ以外の別のＭＧＣが自由にＭＧＷ内部リソースを使用することができ、分割損が発生しないため、ＭＧＷ２の内部リソース２０を有効活用することができる。また、本実施例では、ＭＧＷ２におけるＭＧＣ（＃０）１−０〜ＭＧＣ（＃ｎ）１−ｎのための制御処理が軽くなる。

図４は図３のＭＧＷ２の構成を示すブロック図である。図４において、ＭＧＷ２は呼制御管理部（プロキシ：ｐｒｏｘｙ）２１と、内部スイッチ２２と、メディア（Ｍｅｄｉａ）処理部２３〜２５と、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）インタフェース部２６と、ＡＴＭ（Ａｓｙｎｃｈｒｏｎｏｕｓ Ｔｒａｎｓｆｅｒ Ｍｏｄｅ）／ＳＴＭ（Ｓｙｎｃｈｒｏｎｏｕｓ Ｔｒａｎｓｆｅｒ Ｍｏｄｅ）回線部２７と、ＴＤＭ（Ｔｉｍｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅｘｉｎｇ）回線部２８とを含んで構成されている。

ＭＧＣ（＃０）１−０〜ＭＧＣ（＃ｎ）１−ｎは呼処理を司り、ＭＧＷ２の呼制御管理部２１はＭＧＣ（＃０）１−０〜ＭＧＣ（＃ｎ）１−ｎとの呼処理［Ｈ．２４８／ＭＥＧＡＣＯ（Ｍｅｄｉａ Ｇａｔｅｗａｙ Ｃｏｎｔｒｏｌ）終端機能］を司る。ここで、呼制御管理部２１は信号線１００〜１０ｎを介してＭＧＣ（＃０）１−０〜ＭＧＣ（＃ｎ）１−ｎに接続されている。

内部スイッチ２２は呼制御情報のメディア処理部２３〜２５への転送及びメディア処理部２３〜２５で処理した音声データ、音声パケットを転送する。ＩＰインタフェース部２６は外部ネットワーク２００との間の音声パケットの送受信を司る。ＡＴＭ／ＳＴＭ回線部２７及びＴＤＭ回線部２８は外部ネットワーク２００との間の音声データの送受信を行う。

メディア処理部２３はＩＰインタフェース部２６から受信した音声パケットを音声データに変換する。メディア処理部２４，２５はＡＴＭ／ＳＴＭ回線部２７及びＴＤＭ回線部２８から受信した音声データを音声パケットに変換する。

図５は本発明の一実施例によるネットワークの動作を説明するための図であり、図６は図５の呼処理制御部２１によるサービス登録処理を示すフローチャートであり、図７は図５の呼処理制御部２１によるリソース情報通知処理を示すフローチャートである。これら図５〜図７を参照して本発明の一実施例によるネットワークの動作について説明する。

ＭＧＷ２の呼処理制御部２１は、ＭＧＣ（＃０）１−０〜ＭＧＣ（＃ｎ）１−ｎとの間で呼処理制御情報（Ｈ．２４８／ＭＥＧＡＣＯ）の送受信を実施するために、ＭＧＣ（＃０）１−０〜ＭＧＣ（＃ｎ）１−ｎの情報を登録する。本実施例では、ＭＧＣ（＃０）１−０〜ＭＧＣ（＃ｎ）１−ｎの情報をＩＰアドレス情報として登録しておく（例えば、「ＭＧＣ＃０：１９２．１６８．１０．１／２４」，「ＭＧＣ＃１：１９２．１６８．１０．２／２４」，「ＭＧＣ＃２：１９２．１６８．１０．３／２４」，「ＭＧＣ＃ｎ：１９２．１６８．１０．４／２４」）。呼制御情報管理部２１はこのＩＰアドレス宛にサービス要求信号を送信し、その応答を受信することによって呼処理を実施するＭＧＣを特定する。

まず、ＭＧＷ２のサービス開始時及びリスタート時に、呼制御管理部２１はＭＧＣ（＃０）１−０〜ＭＧＣ（＃ｎ）１−ｎに対して、サービス登録要求信号１１０〜１１ｎを送信する（図６ステップＳ１）。サービス登録要求信号１１０〜１１ｎを受信したＭＧＣ（＃０）１−０〜ＭＧＣ（＃ｎ）１−ｎは、その応答としてサービス登録要求応答信号１２０〜１２ｎを返送する。

呼制御管理部２１は正常に応答を受信したＭＧＣを対象に、呼処理の実施対象のＭＧＣとして登録を行う（図６ステップＳ２〜Ｓ４）。少なくとも１つのＭＧＣからサービス登録要求応答信号を受信した場合、呼制御管理部２１はサービス中となる（図６ステップＳ５）。また、正常に応答を受信できなかったＭＧＣのみを対象に、呼制御管理部２１はサービス登録要求信号１１０〜１１ｎの再送を一定周期で繰り返す（図６ステップＳ６，Ｓ７）。

これによって、ＭＧＷ２はサービス中であっても、サービス登録要求応答信号１２０〜１２ｎが正常に受信さえできれば、そのＭＧＣを呼処理対象のＭＧＣとして追加登録することが可能となる。この手順によって、ＭＧＷ２は呼処理実施対象のＭＧＣを特定させることができる。

尚、サービス登録要求信号１１０〜１１ｎ／サービス登録要求応答信号１２０〜１２ｎには、何のプロトコルを使用しても構わないが、本実施例ではＨ．２４８／ＭＥＧＡＣＯプロトコルを使用することによって、マルチベンダー環境においても、ＭＧＷ２とＭＧＣ（＃０）１−０〜ＭＧＣ（＃ｎ）１−ｎとの間の信号送受信が可能となり、より汎用性のあるものとなる。

Ｈ．２４８／ＭＥＧＡＣＯプロトコルの場合には、サービス登録要求信号１１０〜１１ｎ／サービス登録要求応答信号１２０〜１２ｎとして、「Ｓｅｒｖｉｃｅ Ｃｈａｎｇｅ（Ｒｅｓｔａｒｔ、Ｒｏｏｔ Ｔｅｒｍｉｎａｔｉｏｎ）」を送受信する。これによって、ＭＧＣ（＃０）１−０〜ＭＧＣ（＃ｎ）１−ｎはＭＧＷ２の全てのメディア処理部２３〜２５を使用することが可能となる。

また、メディア処理部２３〜２５のうち、障害等で使用することができなくなったメディア処理部が発生した場合には、使用することができなくなったメディア処理部の情報をＨ．２４８／ＭＥＧＡＣＯの「Ｓｅｒｖｉｃｅ Ｃｈａｎｇｅ（Ｆｏｒｃｅｄ）」を送信することによってＭＧＣ（＃０）１−０〜ＭＧＣ（＃ｎ）１−ｎに通知する。この情報を受信したＭＧＣ（＃０）１−０〜ＭＧＣ（＃ｎ）１−ｎは、ＭＧＷ２の全体のリソースが削減されたことを認識し、高負荷時の呼規制制御も可能となる。

以上の処理手順の一例をＨ．２４８／ＭＥＧＡＣＯプロトコルを使用する場合について述べる。まず、図５のメディア処理部２３，２４が利用できなくなった場合、呼制御管理部２１はＭＧＣ（＃０）１−０〜ＭＧＣ（＃ｎ）１−ｎの全てに対して、「Ｓｅｒｖｉｃｅ Ｃｈａｎｇｅ（Ｔｅｒｍｉｎａｔｉｏｎ ＩＤ＝ＲＯＯＴ、Ｍｅｔｈｏｄ＝Ｒｅｓｔａｒｔ）」のコマンドを送信する（手順１）。呼制御管理部２１は、上記の手順１で送信した信号に対する応答を受信し、呼処理対象のＭＧＣを登録する（手順２）。

呼制御管理部２１はメディア処理部２３，２４が使用できなくなったことを、「Ｓｅｒｖｉｃｅ Ｃｈａｎｇｅ（Ｔｅｒｍｉｎａｔｉｏｎ ＩＤ＝Ｍｅｄｉａ処理部２３、Ｍｅｔｈｏｄ＝Ｆｏｒｃｅｄ）」、「Ｓｅｒｖｉｃｅ Ｃｈａｎｇｅ（Ｔｅｒｍｉｎａｔｉｏｎ ＩＤ＝メディア処理部２４、Ｍｅｔｈｏｄ＝Ｆｏｒｃｅｄ）」のコマンドを使用してＭＧＣ（＃０）１−０〜ＭＧＣ（＃ｎ）１−ｎの全てに対して通知する（手順３）。

呼制御管理部２１は、メディア処理部２３，２４が復旧した場合、「Ｓｅｒｖｉｃｅ Ｃｈａｎｇｅ（Ｔｅｒｍｉｎａｔｉｏｎ ＩＤ＝メディア処理部２３、Ｍｅｔｈｏｄ＝Ｒｅｓｔａｒｔ）」、「Ｓｅｒｖｉｃｅ Ｃｈａｎｇｅ（Ｔｅｒｍｉｎａｔｉｏｎ ＩＤ＝メディア処理部２４、Ｍｅｔｈｏｄ＝Ｒｅｓｔａｒｔ）」のコマンドを使用して、ＭＧＣ（＃０）１−０〜ＭＧＣ（＃ｎ）１−ｎの全てに対して通知する（手順４）。

ＭＧＷ２においては、上述した手順１〜４によって、呼処理対象のＭＧＣ（＃０）１−０〜ＭＧＣ（＃ｎ）１−ｎの特定、メディア処理部２３〜２５の状態変化の通知を実施することが可能となる。

次に、複数のＭＧＣが１台のＭＧＷ２を制御するために、ＭＧＷ２は全てのＭＧＣ（＃０）１−０〜ＭＧＣ（＃ｎ）１−ｎに対して、ＭＧＷ２が使用しているリソース情報を通知する必要がある。これについて、図５及び図７を参照して説明する。

ＭＧＣ（＃０）１−０〜ＭＧＣ（＃ｎ）１−ｎの全ＭＧＣは、ＭＧＷ２の呼制御管理部２１に対して、リソース情報要求信号１２０〜１２ｎを送信する。ＭＧＷ２の呼制御管理部２１はそのリソース情報要求信号１２０〜１２ｎを受信すると（図７ステップＳ１１）、使用しているリソース情報を応答として、ＭＧＣ（＃０）１−０〜ＭＧＣ（＃ｎ）１−ｎの全てのＭＧＣに対してリソース情報応答信号１１０〜１１ｎ送信する（図７ステップＳ１２）。

これによって、ＭＧＣ（＃０）１−０〜ＭＧＣ（＃ｎ）１−ｎの全てのＭＧＣは、ＭＧＷ２で使用しているリソース情報を得ることが可能となる。この場合、ＭＧＣ（＃０）１−０〜ＭＧＣ（＃ｎ）１−ｎとＭＧＷ２とは１対１の関係ではなく、ｎ対１の関係をとることが可能となる。

リソース情報要求信号１２０〜１２ｎ／リソース情報応答信号１１０〜１１ｎには、何のプロトコルを使用しても構わないが、本実施例ではＨ．２４８／ＭＥＧＡＣＯプロトコルを使用することによって、マルチベンダー環境においても、ＭＧＷ２とＭＧＣ（＃０）１−０〜ＭＧＣ（＃ｎ）１−ｎとの間の信号送受信が可能となり、より汎用性のあるものとなる。

Ｈ．２４８／ＭＥＧＡＣＯプロトコルの場合には、リソース情報要求信号１２０〜１２ｎ／リソース情報応答信号１１０〜１１ｎとして、「Ａｕｄｉｔ Ｖａｌｕｅ（ｆｏｒ ＲＯＯＴ Ｔｅｒｍｉｎａｔｉｏｎ）」、または「Ａｕｄｉｔ Ｖａｌｕｅ（ｆｏｒ メディア処理部２３〜２５）」を送受信する。つまり、リソース情報要求信号１２０〜１２ｎを送信する方法としては、メディア処理部２３〜２５を束ねた「ＲＯＯＴ Ｔｅｒｍｉｎａｔｉｏｎ」を指定して「Ａｕｄｉｔ Ｖａｌｕｅ」を送信する方法と、メディア処理部２３〜２５各々を指定して「Ａｕｄｉｔ Ｖａｌｕｅ」を送信する方法との２種類がある。

以下、メディア処理部２３〜２５を束ねた「ＲＯＯＴ Ｔｅｒｍｉｎａｔｉｏｎ」を指定して「Ａｕｄｉｔ Ｖａｌｕｅ」を送信する方法について、その手順を説明する。

ＭＧＣ（＃０）１−０〜ＭＧＣ（＃ｎ）１−ｎは、ＭＧＷ２の呼制御管理部２１に対して「Ａｕｄｉｔ Ｖａｌｕｅ（ｆｏｒ ＲＯＯＴ Ｔｅｒｍｉｎａｔｉｏｎ）」を送信する（手順１）。

ＭＧＷ２の呼制御管理部２１は、上記の手順１の「Ａｕｄｉｔ Ｖａｌｕｅ（ｆｏｒ ＲＯＯＴ Ｔｅｒｍｉｎａｔｉｏｎ）」を受信した後、ＭＧＷ２全体で使用しているリソース情報を応答信号として、ＭＧＣ（＃０）１−０〜ＭＧＣ（＃ｎ）１−ｎの全ＭＧＣに対して送信する（手順２）。

以上の手順によって、ＭＧＣ（＃０）１−０〜ＭＧＣ（＃ｎ）１−ｎは、ＭＧＣ同士で互いに連携する必要なしに、ＭＧＷ２の全体で使用しているリソース情報を共有することが可能となる。

次に、メディア処理部２３〜２５各々を指定して「Ａｕｄｉｔ Ｖａｌｕｅ」を送信する方法について、その手順を説明する。

ＭＧＣ（＃０）１−０〜ＭＧＣ（＃ｎ）１−ｎは、ＭＧＷ２の呼制御管理部２１に対して「Ａｕｄｉｔ Ｖａｌｕｅ（ｆｏｒ メディア処理部２３〜２５）」を送信する（手順１）。

ＭＧＷ２の呼制御管理部２１は、上記の手順１の「Ａｕｄｉｔ Ｖａｌｕｅ（ｆｏｒ メディア処理部２３〜２５）」を受信した後、メディア処理部２３〜２５各々で使用しているリソース情報を応答信号として、ＭＧＣ（＃０）１−０〜ＭＧＣ（＃ｎ）１−ｎの全ＭＧＣに対して送信する（手順２）。

以上の手順によって、ＭＧＣ（＃０）１−０〜ＭＧＣ（＃ｎ）１−ｎは、ＭＧＣ同士で互いに連携する必要なしに、ＭＧＷ２の全体で使用しているリソース情報を共有することが可能となる。

上述した動作によって、ＭＧＣ（＃０）１−０〜ＭＧＣ（＃ｎ）１−ｎは、ＭＧＷ２の内部リソースと１対１の関係ではなく、ｎ：１の関係を持つことが可能となる。また、ＭＧＣ（＃０）１−０〜ＭＧＣ（＃ｎ）１−ｎは、互いに使用しているリソース情報を連携することなく、ＭＧＷ２から得た情報のみでＭＧＷ２の全体で使用しているリソース情報を取得することが可能となる。これによって、本実施例では、緊急呼、呼規制制御等のリソース制御機能が可能となる。

また、ＭＧＣ（＃０）１−０〜ＭＧＣ（＃ｎ）１−ｎ各々は、ＭＧＷ２の全てのリソース情報を制御することも可能となる。一例として、図８及び図９のシーケンスを用いて説明する。

図８及び図９は本発明の一実施例によるネットワークの動作を示すシーケンスチャートである。図８において、ＭＧＣ（＃０）１−１とＭＧＷ２との間において、呼接続要求信号（リソースＡ）／呼接続応答信号（リソースＡ）のやり取りを実施し（図８のａ１，ａ２参照）、ＭＧＣ（＃０）１−０によってＭＧＷ２のリソースＡが使用されている。

この状態の場合において、ＭＧＣ（＃１）１−１が呼接続要求信号（リソースＡ）をＭＧＷ２に対して送信した場合、ＭＧＷ２は呼接続応答信号（Ｅｒｒｏｒ：リソースＡ使用中）をＭＧＣ（＃１）１−１に対して返送する（図８のａ３，ａ４参照）。

また、図９において、ＭＧＣ（＃０）１−０がＭＧＷ２に対して、呼接続要求信号（リソースＡ）／呼接続応答信号（リソースＡ）の実施後（図９のｂ１，ｂ２参照）、そのリソースＡが不要となった場合、ＭＧＣ（＃１）１−１がＭＧＷ２との間でリソースＡ削除要求信号／リソースＡ削除応答信号を送受信することによって（図９のｂ３，ｂ４参照）、リソースＡを削除することができる。

従来は、ＭＧＣ各々のために、ＭＧＷ内部のリソースを各ＭＧＣ単位毎に固定で分割し、ＭＧＣ各々と仮想的に分割されたＭＧＷ内部のリソースとが、仮想的かつ固定的に１対１の関係となり、呼処理を実施している。これに対し、本実施例では、ＭＧＷ２内部のリソースを分割して管理する必要がなく、各ＭＧＣ（＃０）１−０〜ＭＧＣ（＃ｎ）１−ｎが自由にＭＧＷ２の内部リソースを制御することが可能となり、ＭＧＣ（＃０）１−０〜ＭＧＣ（＃ｎ）１−ｎとＭＧＷ２との呼処理負荷軽減・管理負荷軽減、及びＭＧＣ（＃０）１−０〜ＭＧＣ（＃ｎ）１−ｎ間にて使用しているリソース情報を互いに連携する必要もなく、緊急呼用のリソース制御機能、呼規制制御も可能となる。

また、本実施例では、各ＭＧＣ（＃０）１−０〜ＭＧＣ（＃ｎ）１−ｎがＭＧＷ２の内部リソースを自由に制御することが可能となるため、ＭＧＣ（＃０）１−０〜ＭＧＣ（＃ｎ）１−ｎとＭＧＷ２との各処理能力が向上した場合においても、ＭＧＷ２のリソースの分割損もなく、有効に活用することが可能となる。

本実施例では、Ｃ−ｐｌａｎｅをＭＧＣ、Ｕ−ｐｌａｎｅをＭＧＷとして記載しているが、Ｃ−ｐｌａｎｅとＵ−ｐｌａｎｅとで連携して呼制御を実施している別システムにおいても同様に実施することが可能である。

本発明の一実施例によるＭＧＷの動作を説明するための図である。 本発明の一実施例によるＭＧＷの動作を説明するための図である。 本発明の一実施例によるＭＧＷの動作を説明するための図である。 図３のＭＧＷの構成を示すブロック図である。 本発明の一実施例によるネットワークの動作を説明するための図である。 図５の呼処理制御部によるサービス登録処理を示すフローチャートである。 図５の呼処理制御部によるリソース情報通知処理を示すフローチャートである。 本発明の一実施例によるネットワークの動作を示すシーケンスチャートである。 本発明の一実施例によるネットワークの動作を示すシーケンスチャートである。

符号の説明

１−０〜１−ｎ ＭＧＣ（＃０〜＃ｎ）
２ ＭＧＷ
２０ 内部リソース
２１ 呼制御管理部
２２ 内部スイッチ
２３〜２５ メディア処理部
２６ ＩＰインタフェース部
２７ ＡＴＭ／ＳＴＭ回線部
２８ ＴＤＭ回線部
１００〜１０ｎ 信号線
２００ 外部ネットワーク

Claims (12)

1. 複数のメディア・ゲートウェイ・コントローラがメディア・ゲートウェイ装置を制御するネットワークであって、
   前記メディア・ゲートウェイ装置は、前記複数のメディア・ゲートウェイ・コントローラ全てにサービス登録要求を送信する手段と、このサービス登録要求に対して正常に応答を返信したメディア・ゲートウェイ・コントローラを自装置に登録する手段と、前記複数のメディア・ゲートウェイ・コントローラのうちのいずれかから自装置内部のリソース情報を要求するリソース情報要求を受信した時に前記複数のメディア・ゲートウェイ・コントローラ全てに自装置内部のリソース情報を通知する手段とを有し、
   前記メディア・ゲートウェイ装置は、自装置に登録したメディア・ゲートウェイ・コントローラによる内部リソースの使用を可能とすることを特徴とするネットワーク。
2. 前記メディア・ゲートウェイ装置は、前記複数のメディア・ゲートウェイ・コントローラのうちのいずれかから前記サービス登録要求に対する応答を受信した時にサービス中とすることを特徴とする請求項１記載のネットワーク。
3. 前記メディア・ゲートウェイ装置は、前記サービス登録要求に対して正常に応答を受信できなかったメディア・ゲートウェイ・コントローラのみを対象に前記サービス登録要求の再送を一定周期で繰り返すことを特徴とする請求項１または請求項２記載のネットワーク。
4. 前記メディア・ゲートウェイ装置は、少なくとも音声データ及び音声パケットを処理する複数のメディア処理手段を含み、
   前記複数のメディア・ゲートウェイ・コントローラ各々は、前記リソース情報要求を、前記メディア処理手段全てを指定して送信する方法と、前記複数のメディア処理手段各々を指定して送信する方法とのいずれかにて送信することを特徴とする請求項１から請求項３のいずれか記載のネットワーク。
5. 複数のメディア・ゲートウェイ・コントローラにて制御されるメディア・ゲートウェイ装置であって、
   前記複数のメディア・ゲートウェイ・コントローラ全てにサービス登録要求を送信する手段と、このサービス登録要求に対して正常に応答を返信したメディア・ゲートウェイ・コントローラを自装置に登録する手段と、前記複数のメディア・ゲートウェイ・コントローラのうちのいずれかから自装置内部のリソース情報を要求するリソース情報要求を受信した時に前記複数のメディア・ゲートウェイ・コントローラ全てに自装置内部のリソース情報を通知する手段とを有し、
   自装置に登録したメディア・ゲートウェイ・コントローラによる内部リソースの使用を可能とすることを特徴とするメディア・ゲートウェイ装置。
6. 前記複数のメディア・ゲートウェイ・コントローラのうちのいずれかから前記サービス登録要求に対する応答を受信した時にサービス中とすることを特徴とする請求項５記載のメディア・ゲートウェイ装置。
7. 前記サービス登録要求に対して正常に応答を受信できなかったメディア・ゲートウェイ・コントローラのみを対象に前記サービス登録要求の再送を一定周期で繰り返すことを特徴とする請求項５または請求項６記載のメディア・ゲートウェイ装置。
8. 少なくとも音声データ及び音声パケットを処理する複数のメディア処理手段を含み、
   前記複数のメディア・ゲートウェイ・コントローラ各々から前記メディア処理手段全てを指定して送信する方法と、前記複数のメディア処理手段各々を指定して送信する方法とのいずれかにて送信されてきたリソース情報要求に応答して前記複数のメディア・ゲートウェイ・コントローラ全てに自装置内部のリソース情報を通知することを特徴とする請求項５から請求項７のいずれか記載のメディア・ゲートウェイ装置。
9. 複数のメディア・ゲートウェイ・コントローラがメディア・ゲートウェイ装置を制御するネットワークにおいて前記メディア・ゲートウェイ装置の内部リソースを管理する内部リソース管理方法であって、
   前記メディア・ゲートウェイ装置が、前記複数のメディア・ゲートウェイ・コントローラ全てにサービス登録要求を送信する処理と、このサービス登録要求に対して正常に応答を返信したメディア・ゲートウェイ・コントローラを自装置に登録する処理と、前記複数のメディア・ゲートウェイ・コントローラのうちのいずれかから自装置内部のリソース情報を要求するリソース情報要求を受信した時に前記複数のメディア・ゲートウェイ・コントローラ全てに自装置内部のリソース情報を通知する処理とを実行し、
   前記メディア・ゲートウェイ装置が、自装置に登録したメディア・ゲートウェイ・コントローラによる内部リソースの使用を可能とすることを特徴とする内部リソース管理方法。
10. 前記メディア・ゲートウェイ装置が、前記複数のメディア・ゲートウェイ・コントローラのうちのいずれかから前記サービス登録要求に対する応答を受信した時にサービス中とすることを特徴とする請求項９記載の内部リソース管理方法。
11. 前記メディア・ゲートウェイ装置が、前記サービス登録要求に対して正常に応答を受信できなかったメディア・ゲートウェイ・コントローラのみを対象に前記サービス登録要求の再送を一定周期で繰り返すことを特徴とする請求項９または請求項１０記載の内部リソース管理方法。
12. 前記メディア・ゲートウェイ装置に、少なくとも音声データ及び音声パケットを処理する複数のメディア処理手段を設け、
    前記複数のメディア・ゲートウェイ・コントローラ各々が、前記リソース情報要求を、前記メディア処理手段全てを指定して送信する方法と、前記複数のメディア処理手段各々を指定して送信する方法とのいずれかにて送信することを特徴とする請求項９から請求項１１のいずれか記載の内部リソース管理方法。

Images