JP5050908B2 - メディアゲートウェイ装置及びそれに用いるイベント送信方法 - Google Patents

Description

本発明はメディアゲートウェイ装置及びそれに用いるイベント送信方法に関し、特にＨ．２４８／ＭＥＧＡＣＯプロトコルを使用したＭＧ（Ｍｅｄｉａ Ｇａｔｅｗａｙ：メディアゲートウェイ）のイベント送信方式に関する。

ＩＴＵ−Ｔ（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｕｎｉｏｎ−Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｔａｎｄａｒｄｉｚａｔｉｏｎ Ｓｅｃｔｏｒ）勧告Ｈ．２４８に規定されるイベントバッファディスクリプタ（Ｅｖｅｎｔ Ｂｕｆｆｅｒ Ｄｅｓｃｒｉｐｔｏｒ）をＭＧに実装する場合の機能要件を以下に示す。

１、ターミネーション（Ｔｅｒｍｉｎａｔｉｏｎ）単位にイベントバッファ（Ｅｖｅｎｔ Ｂｕｆｆｅｒ）を持ち、イベント（Ｅｖｅｎｔ）が発生時に、イベントをイベントバッファに追加し、同時にｎｏｔｉｆｙを送信する。

２、イベントバッファに追加したイベントは、該当ターミネーションのイベントディスクリプタ（Ｅｖｅｎｔｓ Ｄｅｓｃｒｉｐｔｏｒ）がＭｏｄｉｆｙによって状態変更されるか、そのターミネーション自体が削除されるまで保持し続ける。

本発明に関連するＭＧでは、上記で示した機能要件を満たすために、Ｈ．２４８に規定されているとおりに発生したイベントをリスト化して格納するＦＩＦＯ（Ｆｉｒｓｔ Ｉｎ Ｆｉｒｓｔ Ｏｕｔ）バッファを用意する必要がある。

ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）電話をはじめとしたＶｏＩＰ（Ｖｏｉｃｅ ｏｖｅｒ ＩＰ）サービスにおいて、異なるポリシーをもつネットワーク間での通信を行う場合、加入者単位でサービス品質を保障するＮＧＮ（Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ Ｎｅｔｗｏｒｋ）の観点からＭＧやＭＧに実装するイベント監視機能が必要とされている。

尚、下記の特許文献１には、ＭＧで予めセットされたイベントを監視し、その監視結果をＭＧＣ（Ｍｅｄｉａ Ｇａｔｅｗａｙ Ｃｏｎｔｒｏｌｌｅｒ：メディアゲートウェイコントローラ）に報告する技術が記載されている。
特開２００６−３０４２９８号公報

本発明に関連するＭＧでは、Ｈ．２４８に規定されているとおりに発生したイベントをリスト化して格納するＦＩＦＯバッファを用意する必要があるため、ターミネーションが増加すると、発生するイベント数も増加し、これを管理するＦＩＦＯバッファサイズの増大によるメモリ使用量の増加、検索処理の遅延といった問題が発生する。これによって、大規模なターミネーション情報を収容するようなＭＧの実現が困難である。

また、ＦＩＦＯバッファを用いず、イベントが発生した契機でｎｏｔｉｆｙを送信する実装とした場合には、セッション断中に発生したイベントを保持することができないため、セッション断中に発生したイベントをＭＧＣに通知できない等の問題が発生する。特許文献１に記載の技術では、予めセットされたイベントの監視結果をＭＧＣに報告しているだけなので、上記の問題を解決することはできない。

そこで、本発明の目的は上記の問題点を解消し、加入者収容数が増加することによって取り扱う呼情報が増加するような大規模加入者収容を想定した場合でも、通話品質等のサービスレベルを監視するために用いられるイベントバッファ機能を実装することができるメディアゲートウェイ装置及びそれに用いるイベント送信方法を提供することにある。

本発明によるメディアゲートウェイ装置は、メディアゲートウェイコントローラとの間のセッションが切断されている状態において検出したイベント状態を格納する手段と、前記セッションが再確立した状態においてターミネーション単位に保持していたイベントの検索処理を行いかつその検索結果を自律的に前記メディアゲートウェイコントローラに送信する手段とを備え、
運用ポリシーが異なるネットワーク境界に設置され、少なくともプロトコルの変換を行い、
自装置に登録されているターミネーション情報に基づいて前記異なるネットワーク間への運用ポリシーの変換を行い、
前記ターミネーション情報を格納するターミネーション管理テーブルを含み、
前記ターミネーション管理テーブルに、前記ターミネーション情報毎にイベントバッファ情報を格納する領域を設けている。

本発明によるイベント送信方法は、メディアゲートウェイ装置が、メディアゲートウェイコントローラとの間のセッションが切断されている状態において検出したイベント状態を格納するステップと、前記セッションが再確立した状態においてターミネーション単位に保持していたイベントの検索処理を行いかつその検索結果を自律的に前記メディアゲートウェイコントローラに送信するステップとを実行し、
前記メディアゲートウェイ装置が、運用ポリシーが異なるネットワーク境界に設置され、少なくともプロトコルの変換を行い、
前記メディアゲートウェイ装置が、自装置に登録されているターミネーション情報に基づいて前記異なるネットワーク間への運用ポリシーの変換を行い、
前記メディアゲートウェイ装置に、前記ターミネーション情報を格納するターミネーション管理テーブルを設け、
前記ターミネーション管理テーブルに、前記ターミネーション情報毎にイベントバッファ情報を格納する領域を設けている。

本発明は、上記のような構成及び動作とすることで、加入者収容数が増加することによって取り扱う呼情報が増加するような大規模加入者収容を想定した場合でも、通話品質等のサービスレベルを監視するために用いられるイベントバッファ機能を実装することができるという効果が得られる。

次に、本発明の実施の形態について図面を参照して説明する。まず、本発明によるメディアゲートウェイ装置［以下、ＭＧ（Ｍｅｄｉａ Ｇａｔｅｗａｙ）とする］について図１を参照して説明する。図１は本発明によるＭＧの構成例を示すブロック図である。図１において、ＭＧ１は、ＭＧＣ（Ｍｅｄｉａ Ｇａｔｅｗａｙ Ｃｏｎｔｒｏｌｌｅｒ：メディアゲートウェイコントローラ）送受信部１１と、呼情報管理部１２と、パケット転送部１３とを備えている。

本発明は、運用ポリシーが異なるネットワーク境界に設置されるプロトコル等の変換を行うＭＧを、ＭＧＣからＩＴＵ−Ｔ（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｕｎｉｏｎ−Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｔａｎｄａｒｄｉｚａｔｉｏｎ Ｓｅｃｔｏｒ）勧告Ｈ．２４８／ＭＥＧＡＣＯを用いて制御する場合に関するものである。

本発明によるＭＧ１は、呼情報管理部１２にてセッションが切断されている状態において検出したイベント（Ｅｖｅｎｔ）状態を格納し、ＭＧＣ送受信部１１にてセッションが再確立した状態において、ターミネーション（Ｔｅｒｍｉｎａｔｉｏｎ）単位に保持していたイベントの検索処理を高速化し、自律的に送信する。

これによって、本発明によるＭＧ１では、ＭＧＣへのｎｏｔｉｆｙによるイベント送信を高速化かつ確実に行っている。また、本発明によるＭＧ１では、ネットワーク障害等を素早く検出し、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）電話の通話品質、映像配信等のサービスレベルを維持することを可能としている。

本発明で用いるＭＧとは、運用ポリシーの異なるネットワーク境界で用いられるメディアゲートウェイを総称し、加入者単位、フロー単位の伝送資源の割り当てを行う機能、帯域制御及びトラヒックマーキング制御機能、ＮＡＴ（Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｏｒ）／ＮＡＰＴ（Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ−Ｐｏｒｔ Ｔｒａｎｓｌａｔｏｒ）制御機能、不正なトラヒックがコアネットワークへ流入することを防ぐピンホール制御機能、パケットの転送レートを監視することでネットワークの状態を監視する品質監視機能、特定のフローを指定された宛先にコピー転送を行うモニタ機能等、ＳＢＣ（Ｓｅｓｓｉｏｎ Ｂｏｒｄｅｒ Ｃｏｎｔｒｏｌｌｅｒ：セッションボーダコントローラ）の機能を持つものとする。

ＭＧの一例としては、ＥＴＳＩ（Ｅｕｒｏｐｅａｎ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｔａｎｄａｒｄｓ Ｉｎｓｔｉｔｕｔｅ）の標準化団体の一つであるＴＩＳＰＡＮ（Ｔｈｅ Ｔｅｌｅｃｏｍｓ ＆ Ｉｎｔｅｒｎｅｔ ｃｏｎｖｅｒｇｅｄ Ｓｅｒｖｉｃｅｓ ＆ Ｐｒｏｔｏｃｏｌｓ ｆｏｒ Ａｄｖａｎｃｅｄ Ｎｅｔｗｏｒｋｓ）で議論されているＮＧＮ（Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ Ｎｅｔｗｏｒｋ）アーキテクチャのうち、ＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）機能を実現するためのＲＡＣＳ（Ｒｅｓｏｕｒｃｅ ａｎｄ Ａｄｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｓｕｂｓｙｓｔｅｍ）アーキテクチャに準拠するＢＧＦ（Ｂｏｒｄｅｒ Ｇａｔｅｗａｙ Ｆｕｎｃｔｉｏｎ）及びＲＣＥＦ（Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ Ｅｎｆｏｒｃｅｍｅｎｔ Ｆｕｎｃｔｉｏｎ）の機能に相当するものである。

本発明で用いるＭＧＣとは、ＩＴＵ−Ｔ勧告Ｈ．２４８／ＭＥＧＡＣＯを用いて、上記のＭＧに対してターミネーションやコンテキスト（Ｃｏｎｔｅｘｔ）等の呼情報の設定を行うものとする。ここで、ＩＴＵ−Ｔ勧告Ｈ．２４８／ＭＥＧＡＣＯでは、コンテキストと呼ばれる論理上の要素を制御対象のベースとし、コンテキストに対してターミネーションを結び付けて制御している。

ＭＧＣの一例としては、上記のＲＡＣＳアーキテクチャにおけるＡ−ＲＡＣＦ（Ａｃｃｅｓｓ −Ｒｅｓｏｕｒｃｅ ａｎｄ Ａｄｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｆｕｎｃｔｉｏｎ）の機能、またはＳＰＤＦ（Ｓｅｒｖｉｃｅ Ｐｏｌｉｃｙ Ｄｅｃｉｓｉｏｎ Ｆｕｎｃｔｉｏｎ）を具備した制御装置に相当するものである。

本発明で用いるセッションとは、ＭＧＣとＭＧとの間の通信状態を表し、正常に通信が行える場合においてはセッションが確立され、通信経路障害もしくはＭＧＣの故障等によって通信が行えない場合においてはセッションが切断されているものとする。

本発明によるネットワーク構成においては、第１のＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）クライアントから第２のＳＩＰクライアントに対して第１のネットワーク、ＭＧ、第２のネットワークを介してＳＩＰ等のシグナリングプロトコルやＲＴＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）等のメディア通信プロトコルを使用した通信を可能にするために、ＭＧに登録されているターミネーション情報に基づき、第１のネットワークから第２のネットワークへの運用ポリシーの変換が行われるものとする。また、ターミネーションの設定は、第３のネットワークを介してＭＧＣからＭＧに対して行われるものとする。

本発明で発生するイベントの一例としては、Ｈ．２４８に規定されるターミネーションに通話品質を監視するためにＱｕａｌｉｔｙ Ａｌｅｒｔ（ｎｔ／ｑｕａｌｅｒｔ）イベントを設定し、ターミネーションに適合するフローの通信状態が設定した閾値を下回った場合にＭＧＣに対してｎｏｔｉｆｙを送信する仕組みがある。

本装置の使用例としては、ＭＧを経由する第１のＳＩＰクライアントと第２のＳＩＰクライアントとの間のメディア通信フローに対して、通話品質を監視するイベントを設定した場合、当該フローが設定されたレートの閾値を下回った際に、ＭＧから第３のネットワークを介してＭＧＣに対してｎｏｔｉｆｙが送信されるものとする。

本発明では、Ｈ．２４８に規定されるイベントバッファ（Ｅｖｅｎｔ Ｂｕｆｆｅｒ）機能をＭＧに実装するにあたり、ターミネーション管理テーブルのターミネーション情報毎にイベントバッファ情報を格納する領域を用意することによって、イベントバッファ機能を実現している。また、本発明では、上述した本発明に関連するＭＧに必要とするＦＩＦＯ（Ｆｉｒｓｔ Ｉｎ Ｆｉｒｓｔ Ｏｕｔ）バッファを実装せずに、当該機能をサポートすることが可能であり、実装を容易に行うことができる。さらに、本発明では、メモリ使用量を削減することができるため、リソースの有効活用を行うことができる。

セッション断中に発生したイベントに対しては、セッション確立後にイベントバッファ情報を持つターミネーションを検索することによって、ｎｏｔｉｆｙを作成する。本発明では、検索条件がターミネーションのみであるため、検索規模を少なくし、検索処理の高速化を可能としている。

また、本発明では、ＭＧＣとＭＧとの間の通信異常やＭＧＣの故障等でセッションが切断された後、通信状態が復旧し、セッションが再確立された時に、ＭＧから自律的にイベントバッファに存在するイベントを順次ｎｏｔｉｆｙを使用して送信することで、セッションの切断中に発生したイベントを取りこぼすことなく、ＭＧＣに送信することができる。

さらに、本発明では、ＭＧＣがイベントバッファディスクリプタ（Ｅｖｅｎｔ Ｂｕｆｆｅｒ Ｄｅｓｃｒｉｐｔｏｒ）に対応しているかどうかに関わらず、ｎｏｔｉｆｙの送信によってイベントを通知している。このため、本発明では、ＭＧＣがイベントバッファディスクリプタをサポートしていない場合のプロトコルのバージョン不一致や、プロトコルバージョンが異なる複数台のＭＧＣに対してＭＧがイベント通知を実施する状態においても、イベント送信が可能である。

上述したように、本発明は、ＭＧに対して通話品質等のサービスレベルを監視するために用いられるイベントバッファ機能（イベント監視機能）を、加入者収容数が増加することによって取り扱う呼情報が増加するような大規模加入者収容を想定したＭＧにおいても実装することができる。

図２は本発明の実施の形態によるネットワーク構成の一例を示すブロック図である。図２において、本発明の実施の形態によるネットワークは、ＭＧ１と、ＳＩＰクライアント２，３と、ＭＧＣ４と、ネットワーク１００，２００，３００とから構成されている。

ＭＧ１は、本発明の対象とするシステムであり、ＭＧＣ４からネットワーク３００を介してＨ．２４８のターミネーション情報等の呼情報を含むパケットを受信する。ＳＩＰクライアント２，３は、ネットワーク１００，２００及びＭＧ１を介して接続可能となっている。

図３は図２のＭＧ１の構成例を示すブロック図である。図３において、ＭＧ１は、ＭＧＣ送受信部１１と、呼情報管理部１２と、パケット転送部１３とからなるＳＢＣ１０を備えている。呼情報管理部１２はターミネーション登録部１２１と、ターミネーション管理テーブル１２２と、イベント送信制御部１２３とから構成されている。

ＭＧ１がＭＧＣ４から受信したターミネーション情報は、ＭＧＣ送受信部１１に転送される。ＭＧＣ送受信部１１は転送されてきたターミネーション情報を内部通信用のフォーマットに変換し、呼情報管理部１２に送信する。呼情報管理部１２は、送信されてきた呼情報をターミネーション登録部１２１を介してターミネーション管理テーブル１２２に登録する。

ネットワーク１００もしくはネットワーク２００からパケットフローを受信した場合、パケット転送部１３は、設定された呼情報に適合するかどうかを呼情報管理部１２にて検索し、適合した場合、そのパケットフローに対して設定されている処理を施し、対向するネットワーク２００もしくはネットワーク１００に転送する。適合するターミネーション情報が存在しない場合、パケット転送部１３は、そのパケットフローを廃棄する。

図４は図３のターミネーション管理テーブル１２２の詳細な構成を示す図である。図４において、ターミネーション管理テーブル１２２は、ターミネーション情報（“ＴｅｒｍｉｎａｔｉｏｎＡ”，“ＴｅｒｍｉｎａｔｉｏｎＢ”，“ＴｅｒｍｉｎａｔｉｏｎＣ”，“ＴｅｒｍｉｎａｔｉｏｎＤ”，“ＴｅｒｍｉｎａｔｉｏｎＥ”，“ＴｅｒｍｉｎａｔｉｏｎＦ”，“ＴｅｒｍｉｎａｔｉｏｎＧ”）、イベントディスクリプタ（Ｅｖｅｎｔ Ｄｅｓｃｒｉｐｔｏｒ）情報（“ＥｖｅｎｔＡ”，“ＥｖｅｎｔＢ”，“ｎｏｎｅ”，“ＥｖｅｎｔＤ”，“ＥｖｅｎｔＥ”，“ｎｏｎｅ”，“ＥｖｅｎｔＡ”）、イベントバッファ情報（“ｎｏｎｅ”，“Ｅｖｅｎｔ ＢｕｆｆｅｒＢ”，“Ｅｖｅｎｔ ＢｕｆｆｅｒＣ”，“ｎｏｎｅ”，“Ｅｖｅｎｔ ＢｕｆｆｅｒＥ”，“ｎｏｎｅ”，“ｎｏｎｅ”）から構成されている。

イベントバッファ情報は、イベントディスクリプタ情報に対応するリクエスト（Ｒｅｑｕｅｓｔ）ＩＤ、イベント種別を表すイベントＩＤ、パケットフローを特定するストリーム（Ｓｔｒｅａｍ）ＩＤ、イベントに情報を表すイベントパラメータ（Ｅｖｅｎｔ Ｐａｒａｍ）、発生時刻を表すタイムスタンプ（Ｔｉｍｅ Ｓｔａｍｐ）から構成されている。

ここで、図４における“ＴｅｒｍｉｎａｔｉｏｎＡ”のように、ターミネーションにイベントディスクリプタ情報が設定されており、該当するターミネーションにイベントが発生した場合、パケット転送部１３は呼情報管理部１２にイベント発生通知を行う。

呼情報管理部１２がイベント発生通知を受け取った場合、そのイベント発生通知は、イベント送信制御部１２３に転送される。イベント送信制御部１２３は、ＭＧ１の装置本体のサービス状態を確認し、装置状態がインサービスであれば、処理対象のターミネーションを検索する。イベント送信制御部１２３は、装置状態がアウトオブサービスであれば、通知されたイベントを廃棄する。

装置状態がインサービスで、処理対象のターミネーションが存在する場合には、そのターミネーション情報のイベントバッファ項目に情報を追加する。この時、既にイベントバッファに同一のイベント（イベントＩＤとストリームＩＤとが一致）が存在した場合には、元のデータを優先し、新しく発生したイベントを廃棄する。

ターミネーション管理テーブル１２２のイベントバッファ項目に、上記で示したイベントバッファ情報を追加した後、装置のサービス状態がインサービスであれば、イベントバッファ情報からｎｏｔｉｆｙを作成して送信を行う。

図５は本発明の実施の形態におけるイベント発生時の動作を示すフローチャートである。これら図２〜図５を参照して本発明の実施の形態におけるイベント発生時の動作について説明する。

図４における“ＴｅｒｍｉｎａｔｉｏｎＡ”のように、イベントディスクリプタ情報が設定されてあるターミネーションにイベントが発生した場合、呼情報管理部１２は、イベント検出を行った後（図５ステップＳ１）、装置状態確認を行う（図５ステップＳ２）。

呼情報管理部１２は、装置状態が故障中やアウトオブサービス等でＮＧだった場合、そのイベントを廃棄する（図５ステップＳ３）。呼情報管理部１２は、装置状態がインサービス等でＯＫだった場合、ターミネーション管理テーブル１２２の検索を行う（図５ステップＳ４）。

呼情報管理部１２は、発生したイベントが設定されているターミネーションに適合するか否かを、図４に示すターミネーション管理テーブル１２２のターミネーション情報欄に対して線形検索のターミネーション情報検索を実施する（図５ステップＳ５）。呼情報管理部１２は、すべてのターミネーションに対して適合しない場合、そのイベントを廃棄する（図５ステップＳ６）。

呼情報管理部１２は、発生したイベントに適合するターミネーションが存在する場合、そのターミネーションのイベントバッファ情報の検索を行う（図５ステップＳ７）。呼情報管理部１２は、検索した結果、既にイベントバッファ情報が書込まれており、イベントバッファに同一のイベント（イベントＩＤとストリームＩＤとが一致）が存在した場合、元のデータを優先し、新しく発生したイベントを廃棄する（図５ステップＳ８）。

呼情報管理部１２は、イベントバッファ情報の検索の結果、図４における“ＴｅｒｍｉｎａｔｉｏｎＡ”のように、イベントバッファ情報が書込まれておらず、“ｎｏｎｅ”の場合、イベントバッファ情報の書込みを行う（図５ステップＳ９）。その後、呼情報管理部１２は、その情報を基にｎｏｔｉｆｙを作成して送信するｎｏｔｉｆｙ送信処理を行う（図５ステップＳ１０）。

そして、呼情報管理部１２は、当該ターミネーションのイベントが終了したこと示すために、図４におけるイベントディスクリプタ情報欄を削除する（イベントディスクリプタ情報削除）（図５ステップＳ１１）。

ターミネーション情報に、新たにイベントディスクリプタ情報を含むＭｏｄｉｆｙ Ｒｅｑｕｅｓｔを受信した場合、呼情報管理部１２は、その内容に関わらずに、該当するターミネーションのイベントバッファ情報をクリアする。この時、ｎｏｔｉｆｙは送信しない。また、イベントバッファ情報をもつターミネーションをＳｕｂｔｒａｃｔする場合も、ｎｏｔｉｆｙは送信しない。

ＭＧＣ４とＭＧ１との間のセッション切断後、セッションが再確立した場合、呼情報管理部１２は、一定時間のタイマを起動し、タイマ満了後に、ターミネーションのイベントバッファ項目を線形検索してイベントバッファ情報が存在するものについて、ｎｏｔｉｆｙを作成してＭＧＣ４に送信する。

イベント送信制御部１２３は、イベントバッファ情報をｎｏｔｉｆｙ送信してから、次のターミネーションに対する検索処理をするまでの時間、タイマを起動して待ち時間を置き、タイマが満了してからターミネーション検索とｎｏｔｉｆｙ送信とを行う。この場合には、ｎｏｔｉｆｙの送信間隔を調整することによって、ＭＧＣ４の輻輳を防止することが可能である。

図６は本発明の実施の形態におけるセッション再確立時の処理を示すフローチャートである。これら図２〜図４と図６とを参照して本発明の実施の形態におけるセッション再確立時の処理について説明する。

呼情報管理部１２は、セッションの再確立の検出した場合（セッション再確立検出）（図６ステップＳ２１）、タイマを起動し、装置起動直後に処理を実施しないように待ち時間（Ｗａｉｔ）をおく（起動タイマ処理）（図６ステップＳ２２）。

呼情報管理部１２は、起動タイマ処理のタイマが満了すると、ターミネーション管理テーブル１２２の検索を行う（図６ステップＳ２３）。図４におけるターミネーション情報欄を線形検索し（ターミネーション検索）（図６ステップＳ２４）、ターミネーションが存在した場合、イベントバッファ情報を検索する（イベントバッファ検索）（図６ステップＳ２５）。

呼情報管理部１２は、図４における“ＴｅｒｍｉｎａｉｔｏｎＢ”のようにイベントバッファ情報が存在する場合、イベントバッファ情報からｎｏｔｉｆｙを作成してＭＧＣ４に対してｎｏｔｉｆｙ送信を行う（ｎｏｔｉｆｙ送信処理）（図６ステップＳ２６）。その後、呼情報管理部１２は、イベントディスクリプタ情報削除を行う（図６ステップＳ２７）。

呼情報管理部１２は、イベントディスクリプタ情報を削除した結果、ターミネーション管理テーブル１２２において、図４における“ＴｅｒｍｉｎａｔｉｏｎＣ”のように、イベントディスクリプタ欄が“ｎｏｎｅ”となる。そして、呼情報管理部１２は、送信タイマを起動し、次のターミネーション検索を行うまでの時間を待ち時間（Ｗａｉｔ）とする（送信タイマ処理）（図６ステップＳ２８）。

図７は本発明の実施の形態におけるイベント発生時のＭＧ１とＭＧＣ４との間のメッセージシーケンスを示すシーケンスチャートである。この図７を参照して本発明の実施の形態におけるイベント発生時のＭＧ１とＭＧＣ４との間のメッセージのやりとりについて説明する。

図７に示すように、ＭＧ１とＭＧＣ４との間にセッションが正常に確立されている状態において（図７のａ１）、ＭＧ１でイベントが発生した場合（図７のａ２）、ＭＧ１は、その内部でイベントバッファ作成処理を行い（図７のａ３）、ＭＧＣ４に対してｎｏｔｉｆｙを送信する（図７のａ４）。ＭＧＣ４はその通知に対して、ｎｏｔｉｆｙ応答をＭＧ１に送信する（図７のａ５）。

ＭＧＣ４とＭＧ１との間に障害が発生し、セッション断が発生した場合において（図７のａ６）、さらにＭＧ１にイベントが発生すると（図７のａ７）、ＭＧ１はその内部でイベントバッファ作成処理を実施するが、ｎｏｔｉｆｙ通知を行わない（図７のａ８）。

ＭＧＣ４とＭＧ１との間の通信が回復し、セッションが再確立した場合に（図７のａ９）、ＭＧ１はイベントバッファ検索処理を実施し（図７のａ１０）、該当するターミネーションのｎｏｔｉｆｙ通知を送信する（図７のａ１１）。ＭＧＣ４は、ｎｏｔｉｆｙ通知に対してｎｏｔｉｆｙ応答をＭＧ１に送信する（図７のａ１２）。

このように、本実施の形態では、Ｈ．２４８で規定されているイベントバッファディスクリプタの機能要件を、上述した本発明に関連するＭＧに必要とするＦＩＦＯバッファを用いずに、ターミネーション管理情報にイベントバッファディスクリプタを用いるので、実装が容易になり、開発工数を削減することができる。

また、本実施の形態では、ＭＧＣ４とＭＧ１との間のセッションが切断している間に発生したイベントを保持し、セッションの切断回復後にＭＧ１から自律的にＭＧＣ４にイベント通知を行っているので、セッション断中のイベント情報を取りこぼすことなく、送信することができ、セッション確立後すぐにＭＧＣ４がネットワーク障害等を検出することができる。これによって、本実施の形態では、通話品質等のサービスレベルの維持を保つことが可能となる。

さらに、本実施の形態では、ＭＥＧＡＣＯ電文におけるイベントバッファディスクリプタを実装せずに、ｎｏｔｉｆｙ送信によってイベントを通知しているため、ＭＧＣ４とＭＧ１とのＨ．２４８プロトコルのバージョン不一致の場合や、プロトコルバージョンが異なる複数台のＭＧＣに対してもイベント通知の実施が可能である。

図１は本発明によるメディアゲートウェイの構成例を示すブロック図である。 本発明の実施の形態によるネットワーク構成の一例を示すブロック図である。 図２のメディアゲートウェイの構成例を示すブロック図である。 図３のターミネーション管理テーブルの詳細な構成を示す図である。 本発明の実施の形態におけるイベント発生時の動作を示すフローチャートである。 本発明の実施の形態におけるセッション再確立時の処理を示すフローチャートである。 本発明の実施の形態におけるイベント発生時のメディアゲートウェイとメディアゲートウェイコントローラとの間のメッセージシーケンスを示すシーケンスチャートである。

符号の説明

１ メディアゲートウェイ
２，３ ＳＩＰクライアント
４ メディアゲートウェイコントローラ
１０ ＳＢＣ
１１ ＭＧＣ送受信部
１２ 呼情報管理部
１３ パケット転送部
１００，２００，３００ ネットワーク
１２１ ターミネーション登録部
１２２ ターミネーション管理テーブル
１２３ イベント送信制御部

Claims (8)

1. メディアゲートウェイコントローラとの間のセッションが切断されている状態において検出したイベント状態を格納する手段と、前記セッションが再確立した状態においてターミネーション単位に保持していたイベントの検索処理を行いかつその検索結果を自律的に前記メディアゲートウェイコントローラに送信する手段とを有し、
   運用ポリシーが異なるネットワーク境界に設置され、少なくともプロトコルの変換を行い、
   自装置に登録されているターミネーション情報に基づいて前記異なるネットワーク間への運用ポリシーの変換を行い、
   前記ターミネーション情報を格納するターミネーション管理テーブルを含み、
   前記ターミネーション管理テーブルに、前記ターミネーション情報毎にイベントバッファ情報を格納する領域を設けたことを特徴とするメディアゲートウェイ装置。
2. 前記セッションの切断中に発生したイベントに対して、前記セッション確立後にイベントバッファ情報を持つターミネーションを検索して前記メディアゲートウェイコントローラへのｎｏｔｉｆｙを作成することを特徴とする請求項１記載のメディアゲートウェイ装置。
3. 前記セッションが切断された後、通信状態が復旧して当該セッションが再確立した時に自律的にイベントバッファに存在するイベントを前記ｎｏｔｉｆｙを使用して前記メディアゲートウェイコントローラに順次送信することを特徴とする請求項２記載のメディアゲートウェイ装置。
4. 前記メディアゲートウェイコントローラからＩＴＵ−Ｔ勧告Ｈ．２４８／ＭＥＧＡＣＯを用いて制御されることを特徴とする請求項１から請求項３のいずれか記載のメディアゲートウェイ装置。
5. メディアゲートウェイ装置が、メディアゲートウェイコントローラとの間のセッションが切断されている状態において検出したイベント状態を格納するステップと、前記セッションが再確立した状態においてターミネーション単位に保持していたイベントの検索処理を行いかつその検索結果を自律的に前記メディアゲートウェイコントローラに送信するステップとを実行し、
   前記メディアゲートウェイ装置が、運用ポリシーが異なるネットワーク境界に設置され、少なくともプロトコルの変換を行い、
   前記メディアゲートウェイ装置が、自装置に登録されているターミネーション情報に基づいて前記異なるネットワーク間への運用ポリシーの変換を行い、
   前記メディアゲートウェイ装置に、前記ターミネーション情報を格納するターミネーション管理テーブルを設け、
   前記ターミネーション管理テーブルに、前記ターミネーション情報毎にイベントバッファ情報を格納する領域を設けたことを特徴とするイベント送信方法。
6. 前記メディアゲートウェイ装置が、前記セッションの切断中に発生したイベントに対して、前記セッション確立後にイベントバッファ情報を持つターミネーションを検索して前記メディアゲートウェイコントローラへのｎｏｔｉｆｙを作成することを特徴とする請求項５記載のイベント送信方法。
7. 前記メディアゲートウェイ装置が、前記セッションが切断された後、通信状態が復旧して当該セッションが再確立した時に自律的にイベントバッファに存在するイベントを前記ｎｏｔｉｆｙを使用して前記メディアゲートウェイコントローラに順次送信することを特徴とする請求項６記載のイベント送信方法。
8. 前記メディアゲートウェイ装置は、前記メディアゲートウェイコントローラからＩＴＵ−Ｔ勧告Ｈ．２４８／ＭＥＧＡＣＯを用いて制御されることを特徴とする請求項５から請求項７のいずれか記載のイベント送信方法。

Images