JP5214035B2 - ゲートウェイ装置、通信システムおよび通信方法 - Google Patents

Description

本発明は、セッション制御機能を備えない端末と、セッション制御を実施するネットワークと、前記端末および前記ネットワークに接続し、前記端末のセッション制御処理を代行するゲートウェイ装置と、を備える通信システムにおけるそのゲートウェイ装置および通信方法に関する。

近年、ベストエフォートを基本とするＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ：インターネットプロトコル）ネットワーク上で、セッションの概念を導入し通信帯域等のＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）を保証するネットワーク（以下、セッション制御ネットワークという）が構築されている。各端末は、このようなセッション制御ネットワークに接続してセッション制御による恩恵を受けるためには、セッション制御のためのプロトコルをサポートする必要がある。しかし、既存の端末は、セッション制御プロトコルに対応していない場合がある。

このため、セッション制御プロトコルに対応していない既存端末とセッション制御ネットワークとの間に存在するゲートウェイ装置が、既存端末とセッション制御ネットワークの間のセッション制御処理を代行する方法が提案されている（たとえば、下記特許文献１参照）。

また、ゲートウェイ装置がセッション制御処理を代行する場合、ゲートウェイ装置が、セッション制御時に対象の通信用にセッション制御ネットワークに申告する帯域情報を決定する必要がある。したがって、たとえば、下記特許文献１に記載の技術では、ゲートウェイ装置が、既存端末間の通信における送信元アドレス、宛先アドレス、プロトコル、送信元ポート番号、宛先ポート番号等に基づいて識別するフロー情報とセッション制御で申告する帯域情報との対応表を内に予め保持する。そして、ゲートウェイ装置は、セッション制御代行処理の対象となる通信を検出した際に、対応表を参照し、その通信のフロー情報に対応する帯域情報を検索することで、セッション制御ネットワークに申告する帯域情報を決定している。

国際公開第２００６／０５１５９４号

しかしながら、上記従来の技術によれば、ゲートウェイ装置は、セッション制御代行処理の対象となる通信を検出した際に、保持している対応表を参照してセッション制御ネットワークに申告する帯域情報を決定している。一方、通信に必要な帯域はアプリケーション毎に異なり、さらに同一のアプリケーションであっても必要な帯域は必ずしも同一とは限らない。そのため、従来の技術で示されているフロー情報に基づいて帯域を決定する方法では、最適な必要帯域の申告を行うことが困難である、という問題があった。

本発明は、上記に鑑みてなされたものであって、既存端末のセッション制御処理を代行する場合に、セッション制御の対象となる既存端末間の通信に必要な帯域値を呼制御ネットワークへ適切に申告することができるゲートウェイ装置、通信システムおよび通信方法を得ることを目的とする。

上述した課題を解決し、目的を達成するために、本発明は、呼制御を実施する呼制御ネットワークと、呼制御機能を備えない端末と、接続し、前記呼制御ネットワークと前記端末間の通信を中継するゲートウェイ装置であって、前記端末が前記呼制御ネットワーク経由で行なう通信である呼制御通信における呼制御処理を代行し、前記呼制御通信が必要とする帯域を前記呼制御ネットワークへ申告する呼制御手段と、前記端末から受信した前記呼制御通信の通信パケットに基づいて、前記呼制御通信の帯域の更新値を求める帯域調整手段と、前記通信パケットに含まれる所定の情報を抽出するパケット解析手段と、を備え、前記呼制御通信をＲＴＰおよびＲＴＣＰを用いた通信とし、前記呼制御手段は、前記更新値を前記呼制御通信が必要とする帯域として前記呼制御ネットワークへ申告し、前記パケット解析手段は、Ｒｅｃｅｉｖｅｒ ＲｅｐｏｒｔパケットまたはＳｅｎｄｅｒ Ｒｅｐｏｒｔパケットに含まれるパケット損失率を前記情報として抽出し、前記帯域調整手段は、前記パケット損失率が所定の上限しきい値より大きい場合、前記更新値を申告済みの帯域より増加させるよう求め、前記更新値を増加させた後、一定時間内に前記パケット損失率の減少が観測できない場合には、増加させる前の値に前記更新値を変更する、ことを特徴とする。

本発明にかかるゲートウェイ装置は、セッション制御の対象となる既存端末間の通信に必要な帯域値を適切に呼制御ネットワークへ申告することができる、という効果を奏する。

図１は、実施の形態１の通信システムの構成例を示す図である。 図２は、実施の形態１のゲートウェイ装置の機能構成例を示す図である。 図３は、セッション情報テーブルの一例を示す図である。 図４は、実施の形態１の通信手順の一例を示すシーケンス図である。 図５は、ＲＴＣＰのReceiver Reportパケットのフォーマットの一例を示す図である。 図６は、ＳＩＰのＵＰＤＡＴＥメッセージの一例を示す図である。 図７は、実施の形態１の申告帯域の更新方法の一例を示すフローチャートである。 図８は、実施の形態２の通信手順の一例を示すシーケンス図である。 図９は、“ＲＴＳＰ ＤＥＳＣＲＩＢＥ”メッセージの一例を示す図である。 図１０は、“ＲＴＳＰ ２００ ＯＫ”レスポンスの一例を示す図である。 図１１は、実施の形態３のゲートウェイ装置の機能構成例を示す図である。 図１２は、実施の形態３の通信手順の一例を示すシーケンス図である。 図１３は、ＴＣＰパケットのヘッダフォーマットの一例を示す図である。 図１４は、実施の形態３の申告帯域の更新方法の一例を示すフローチャートである。 図１５は、実施の形態４のゲートウェイ装置の機能構成例を示す図である。 図１６は、実施の形態４の通信手順の一例を示すシーケンス図である。

以下に、本発明にかかるゲートウェイ装置、通信システムおよび通信方法の実施の形態を図面に基づいて詳細に説明する。なお、この実施の形態によりこの発明が限定されるものではない。

実施の形態１．
図１は、本発明にかかる通信システムの実施の形態１の構成例を示す図である。図１に示すように、本実施の形態の通信システムは、図１に示すように、複数の優先クラスを用いた呼制御（セッション制御）および呼管理（セッション管理）を実施するネットワークである呼制御ネットワーク４と、呼制御を実施しない既存のＩＰネットワークであるユーザネットワーク５−１，５−２と、ユーザネットワーク５−１と呼制御ネットワーク４の間に存在するゲートーェイ装置２−１と、ユーザネットワーク５−２と呼制御ネットワーク４の間に存在するゲートーェイ装置２−２と、で構成される。

呼制御ネットワークには、呼制御および呼管理を行なうＳＩＰ（Session Initiation Protocol）サーバ１が接続している。また、ユーザネットワーク５−１には、呼制御機能を有しない端末である端末３−１が接続し、ユーザネットワーク５−２には、呼制御機能を有しない端末である端末３−２が接続している。なお、図１の構成は例示であり、ユーザネットワークの個数はこれに限らず、いくつでもよく、また各ユーザネットワークに接続する端末の台数もこれに限らず、何台でもよい。なお、ゲートウェイ装置は、ユーザネットワークごとにユーザネットワークと呼制御ネットワーク４間に備えることとする。

図２は、本実施の形態のゲートウェイ装置２（ゲートウェイ装置２−１またはゲートウェイ装置２−２）の機能構成例を示す図である。なお、図１に示したゲートウェイ装置２−１とゲートウェイ装置２−２は、同様の構成を有することとし、これらのゲートウェイ装置を、個別を識別せず代表して表記する場合はゲートウェイ装置２と表記する。

ゲートウェイ装置２は、パケット中継部２１と、セッション制御（呼制御）部２２と、パケット解析部２４と、帯域調整部２５と、を備えている。また、ゲートウェイ装置２は、セッション制御を行う対象となる通信フローの条件（フロー情報）とセッション制御のためのパラメータと保持するテーブルであるセッション情報テーブル２３を保持している。セッション情報テーブル２３を保持するための保持（記憶）手段は、セッション制御部２２が備えることとしてもよいし、セッション制御部２２とは別に記憶手段を保持するようにしてもよい。

パケット中継部２１は、呼制御ネットワーク４および自身が接続するユーザネットワーク（ユーザネットワーク５−１、ユーザネットワーク５−２等）から受信したパケットに対する所定の受信処理を行い、また呼制御ネットワーク４および自身が接続するユーザネットワークへ送信するパケットに対して所定の送信処理を行うことにより、呼制御ネットワーク４と自身が接続するユーザネットワークとの間のパケットを中継する。また、パケット中継部２１は、呼制御ネットワーク４と自身が接続するユーザネットワークとの間のトラフィックの監視を行う。

セッション制御部２２は、自身が接続するユーザネットワーク内の端末に代わり呼制御ネットワーク４との間のセッション制御処理を行う。セッション制御の方法はどのような方法を用いてもよいが、ここでは一例としてＳＩＰ（Session Initiation Protocol）を用いた制御を実施する。

図３は、セッション情報テーブル２３の一例を示す図である。図３に示すように、セッション情報テーブルは、フロー条件とセッション制御パラメータとで構成される。図中の＊は、その項目についてはどのような値でもよい（制約が無い）ことを示す。フロー条件は、送信元および宛先のＩＰアドレスと、プロトコルと、送信元および宛先のポート番号と、を含む。セッション制御パラメータは、ＳＩＰ上での宛先を示す宛先ＳＩＰ−ＵＲＩ（Uniform Resource Identifier）と、“ａｕｄｉｏ”，“ｖｉｄｅｏ”，“ａｐｐｌｉｃａｉｔｏｎ”等のメディアタイプと、トランスポートプロトコルと、メディアフォーマットと、メディア方向と、帯域初期値と、を含む。メディアフォーマットは、ＲＴＰ（Real-time Transport Protocol）／ＡＶＰ（Audio Video Profile）の場合のペイロード番号，ＴＣＰの場合のＭＩＭＥサブタイプなどをあらわす。メディア方向は、“ｓｅｎｄｒｅｃｖ（送受信）”，“ｓｅｎｄｏｎｌｙ（送信のみ）”，“ｒｅｃｖｏｎｌｙ（受信のみ）”等、通信の方向を示す。

なお、図３の構成は一例であり、セッション情報テーブル２３の構成は図３の構成に限定する必要はない。セッション情報テーブル２３のフロー条件としては、識別対象のフローを特定するための条件が含まれていればよく、また、セッション制御パラメータは、セッション制御で設定するために必要な制御パラメータを含むようにすればよい。

パケット解析部２４は、セッション制御の対象となるパケットのヘッダ等を参照して通信内容を解析し、その通信に必要な帯域値を求めるための情報として、パケット損失率を抽出し、帯域調整部２５へ出力する。帯域調整部２５は、パケット損失率に基づいて呼制御ネットワーク４へ申告する申告帯域を求め、求めた申告帯域をセッション制御部２２へ出力する。

つぎに、本実施の形態の動作を説明する。図４は、本実施の形態の通信手順の一例を示すシーケンス図である。図４を用いて、端末３−１が端末３−２宛のＲＴＰ通信を行う場合を例に本実施の形態の動作を説明する。

まず端末３−１は、端末３−２宛に、ＲＴＰ通信の最初のパケット（通信開始パケット）を送信する（ステップＳ１１）。なお、ＲＴＰ通信のパケットはＵＤＰ（User Datagram Protocol）パケットとして送信される。

ゲートウェイ装置２−１では、パケット中継部２１が端末３−１から通信開始パケットを受信すると、当該パケットの中継を保留し、そのパケットを保持するとともにセッション制御部２２に渡す。セッション制御部２２は、受信した通信開始パケットから送信元ＩＰアドレス、宛先ＩＰアドレス、プロトコル、送信元ポート番号、宛先ポート番号等フロー条件に対応する情報を抽出し、セッション情報テーブル２３に基づいて抽出した情報と一致するフロー条件を検索し、検索して得られたフロー条件に対応するセッション制御パラメータを取得する（ステップＳ１２）。

そして、ゲートウェイ装置２−１のセッション制御部２２は、取得したセッション制御パラメータに基づいて呼接続要求（セッション確立要求）であるＩＮＶＩＴＥメッセージを生成し、ＳＩＰサーバ１へ送信する（ステップＳ１３）。具体的には、呼制御ネットワーク４へ申告するＱｏＳパラメータとして、取得したセッション制御パラメータの値をＳＤＰ（Session Description Protocol）で記述したＳＤＰ情報を生成し、生成したＳＤＰ情報をＩＮＶＩＴＥメッセージに含めて送信する。

ＳＩＰサーバ１は、ＩＮＶＩＴＥメッセージを受信すると、セッション確立ための処理を実施中であること示す暫定応答“１００ Ｔｒｙｉｎｇ”をゲートウェイ装置２−１へ返信し（ステップＳ１４）、受信したＩＮＶＩＴＥメッセージを通信の宛先の端末３−２に接続するゲートウェイ装置２−２へ転送する（ステップＳ１５）。ゲートウェイ装置２−２は、“１００ Ｔｒｙｉｎｇ”をＳＩＰサーバ１へ返信する（ステップＳ１６）。

ゲートウェイ装置２−２は、セッション確立の処理が正常に終了すると“２００ ＯＫ”レスポンスをＳＩＰサーバ１に送信し（ステップＳ１７）、ＳＩＰサーバ１は、ゲートウェイ装置２−２から“２００ ＯＫ”レスポンスを受信すると“２００ ＯＫ”レスポンスをゲートウェイ装置２−１へ送信する（ステップＳ１８）。

ゲートウェイ装置２−１のセッション制御部２２は、ステップＳ１８で送信された“２００ ＯＫ”レスポンスをＳＩＰサーバ１から受信することにより通信路が確立されたことを検知すると、パケットの中継処理を再開するようパケット中継部２１に指示し、パケット中継部２１は、保留していたパケット（ステップＳ１１で送信されたパケット）を端末３−２に転送する（ステップＳ１９）。

その後、端末３−１と端末３−２の間で、ゲートウェイ装置２−１、ＳＩＰサーバ１およびゲートウェイ装置２−２を経由したＲＴＰおよびＲＴＣＰ（ＲＴＰ Control Protocol）通信が行われる（ステップＳ２０）。

ステップＳ２０の通信が行われている間、ゲートウェイ装置２−１では、パケット中継部２１が端末３−１から送信されたＲＴＰ／ＲＴＣＰの通信パケットを中継するが、パケット中継部２１は、端末３−１から受信した中継対象のＲＴＰ／ＲＴＣＰの通信パケットをパケット解析部２４に渡す。そして、パケット解析部２４は、そのパケットの解析を行い、受信したパケットがＲＴＣＰのSender ReportパケットまたはReceiver Reportパケットである場合に、そのパケットの対応するレポートブロックからパケット損失率を抽出して帯域調整部２５に渡し、帯域調整部２５が、後述の申告帯域の更新方法で示すようにパケット損失率に基づいて申告する帯域を求める（ステップＳ２１）。

図５は、ＲＴＣＰのReceiver Reportパケットのフォーマットの一例を示す図である。Receiver Reportパケットには、ＲＴＣＰヘッダ部の後に、０個以上のレポートブロックが格納される。図５に示すように、ＲＴＣＰヘッダ部は、プロトコルバージョンを表すＶ（Version number）と、パディングの有無を示すＰ（Padding）と、そのパケットに含まれるレポートブロック数を示すＲＣ（Reception Report Count）と、パケットの種別を示すＰＴ（Packet Type）と、パケット長と、送信者ＳＳＲＣ（synchronization source identifier）と、で構成される。Receiver Reportパケットの場合、ＰＴには、ＲＲ（Receiver Report）を示す２０１が格納される。

また、レポートブロック＃ｉ（ｉはレポートブロックの番号を示す１以上の整数）は、ＳＳＲＣ＿ｉ（ｉ番目のレポートブロックに対応するレポート対象のＳＳＲＣ）と、パケット損失率と、累積損失パケット数と、最新受信ＲＴＰシーケンス番号と、パケット受信間隔ジッタと、ＬＳＲ（Last ＳＲ（Sender Report） timestamp）と、ＤＬＳＲ（Delay since Last ＳＲ）と、で構成される。

ＲＴＣＰのSender Reportパケットは、Receiver Reportパケットと同様に０個以上のレポートブロックを含み、レポートブロックのフォーマットはReceiver Reportパケットのレポートブロックのフォーマットと同様である。

帯域調整部２５は、ステップＳ２１で求めた帯域をセッション制御部２２へ渡し、セッション制御部２２は、申告する帯域を帯域調整部２５が求めた帯域に変更するためのＵＰＤＡＴＥメッセージをＳＩＰサーバ１へ送信する（ステップＳ２２）。図６は、ＳＩＰのＵＰＤＡＴＥメッセージの一例を示す図である。図６に示したＵＰＤＡＴＥメッセージでは、最下段の“ｂ＝ＡＳ：２００”が変更後の申告帯域を示しており、この例では２００ｋｂｐｓへの変更を要求している。

このように本実施の形態ではパケット損失率に基づいて、動的に呼制御ネットワーク４に対する申告帯域を変更する。したがって、パケット損失率が上昇しても、当該ＲＴＰ通信用に確保された通信路の帯域を拡大することができるため、呼制御ネットワーク４内での当該ＲＴＰ通信のパケットの廃棄を回避することができる。

ＳＩＰサーバ１は、ＵＰＤＡＴＥメッセージを受信すると、ＵＰＤＡＴＥメッセージに基づいて要求された帯域を確保し、ＵＰＤＡＴＥメッセージをゲートウェイ装置２−２へ転送する（ステップＳ２３）。ゲートウェイ装置２−２は、ＵＰＤＡＴＥメッセージに基づいて要求された帯域を確保し、“２００ ＯＫ”レスポンスをＳＩＰサーバ１に送信する（ステップＳ２４）。ＳＩＰサーバ１は、ゲートウェイ装置２−２から“２００ ＯＫ”レスポンスを受信すると、“２００ ＯＫ”レスポンスをゲートウェイ装置２−１へ送信する（ステップＳ２５）。

その後、端末３−１と端末３−２の間で、ゲートウェイ装置２−１、ＳＩＰサーバ１およびゲートウェイ装置２−２を経由したＲＴＰおよびＲＴＣＰ（ＲＴＰ Control Protocol）通信が再び行われる（ステップＳ２６）。その際、ゲートウェイ装置２−１は、ステップＳ２１と同様に中継するパケットに含まれるパケット損失率に基づいて申告する帯域を求め、ステップＳ２２と同様にＵＰＤＡＴＥメッセージを用いて、求めた帯域への変更を要求する。なお、パケット損失率の値によっては、申告帯域を変更しない場合もある。

図７は、本実施の形態の申告帯域の更新方法の一例を示すフローチャートである。まず、パケット解析部２４は、ＲＴＣＰのSender ReportパケットまたはReceiver Reportパケットの受信を待機する（ステップＳ３１）。そして、パケット解析部２４は、ＲＴＣＰのSender ReportパケットまたはReceiver Reportパケットをすると、受信したＲＴＣＰパケットからパケット損失率を抽出し（ステップＳ３２）、抽出したパケット損失率を帯域調整部２５へ出力する。

帯域調整部２５は、パケット損失率が、一定値Ａより大きいな否かを判断する（ステップＳ３３）。帯域調整部２５は、パケット損失率がＡより大きいと判断した場合（ステップＳ３３ Ｙｅｓ）は、申告帯域を増加させ（ステップＳ３４）、ステップＳ３１へ戻る。具体的には、帯域調整部２５は、現在申告している帯域より増加させた帯域を変更後の帯域として求め、求めた帯域をセッション制御部２２へ通知し、セッション制御部２２は通知された帯域に基づいてＵＰＤＡＴＥメッセージを生成してＳＩＰサーバ１へ送信する。なお、申告帯域を増加させる方法は、どのような方法でもよいが、たとえば、現在申告している帯域の値に対して所定の比率で増加させる方法や、所定の値を現在申告している帯域に加えることにより増加させる方法等がある。

パケット損失率がＡ以下であると判断した場合（ステップＳ３４ Ｎｏ）、帯域調整部２５は、一定時間の間パケット損失率が一定値Ｂより小さいか否かを判断する（ステップＳ３５）。一定時間の間パケット損失率が一定値Ｂより小さいと判断した場合（ステップＳ３５ Ｙｅｓ）、帯域調整部２５は申告帯域を減少させ（ステップＳ３６）ステップＳ３１へ戻る。具体的には、帯域調整部２５は、現在申告している帯域より減少させた帯域を変更後の帯域として求め、求めた帯域をセッション制御部２２へ通知し、セッション制御部２２は通知された帯域に基づいてＵＰＤＡＴＥメッセージを生成してＳＩＰサーバ１へ送信する。なお、申告帯域を減少させる方法は、どのような方法でもよいが、たとえば、現在申告している帯域の値に対して所定の比率で減少させる方法や、所定の値を現在申告している帯域から減ずることにより減少させる方法等がある。

一定時間の間パケット損失率が一定値Ｂより小さくない（パケット損失率が一定値Ｂより小さい期間が一定時間より小さい）と判断した場合（ステップＳ３５ Ｎｏ）、申告帯域は変更せずにステップＳ３１へ戻る。

なお、図７に示した例では、ＲＴＣＰのReceiver ReportパケットまたはSender Reportパケットを受信するたびにパケット損失率を抽出して、ステップＳ３２以降の処理を行うようにしたが、Receiver ReportパケットまたはSender Reportパケットの送信頻度が高い場合等には、所定の時間ごとにステップＳ３１以降の処理を行ってもよい。

また、パケット損失率の短期的な変動が大きい場合や頻繁に帯域の変更を行うことが好ましくない場合等には、パケット解析部２４は、Receiver ReportパケットまたはSender Reportパケットを受信するたびにパケット損失率を抽出して保持し、保持しているパケット損失率が所定の個数になった場合に、保持しているパケット損失率を用いて平均化処理等の統計処理を行って、処理後のパケット損失率を帯域調整部２５に出力するようにしてもよい。

また、本実施の形態では、一定時間の間パケット損失率が一定値Ｂより小さいと判断した場合に、申告する帯域を減少させるようにしているが、使用するアプリケーションやシステムの要求により、帯域を減少させることが望ましくない場合には、申告する帯域を減少させる処理を実施しないようにしてもよい。

なお、本実施の形態では、ＲＴＣＰのSender ReportパケットおよびReceiver Reportパケットにおけるパケット損失率が一定値以上の場合に、呼制御ネットワーク４に申告する帯域値を増加させるようにした。しかし、呼制御ネットワーク４外でのパケット損失等の影響により、一定時間内にパケット損失率の減少が観測できない場合がある。そのため、このように、申告帯域を増加させた後、一定時間内にパケット損失率の減少が観測できない場合には、呼制御ネットワーク４外でのパケット損失であると判定し、呼制御ネットワーク４に申告する帯域値を増加させる前の値に再申告するようにしてもよい。

なお、本実施の形態では、ＲＴＰ通信の帯域値の過不足を検出するためにＲＴＣＰのSender ReportパケットおよびReceiver Reportパケットに格納されているパケット損失率を用いる例を示したが、これに限らずＲＴＣＰのSender Reportパケットに格納されている送信オクテット数を用いて申告する帯域を求めるようにしてもよい。たとえば、複数のSender Reportパケットを用いて、所定の単位時間内の送信オクテット数を算出することにより必要となる帯域値を決定し、その値をＵＰＤＡＴＥメッセージにより呼制御ネットワーク４へ申告するようにしてもよい。

また、本実施の形態では、端末３−１と端末３−２間の通信が、ＲＴＰおよびＲＴＣＰ通信である場合を例に説明したが、本実施の形態を適用する通信はＲＴＰおよびＲＴＣＰ通信に限らない。たとえば、NetFlow（登録商標）により通知されるセッション制御代行の対象となる通信フローの統計情報等のセッション制御代行の対象となる通信フローの帯域値の過不足に関連した情報を、ゲートウェイ装置２が中継パケットの内容を解析することで取得できる通信であれば、ゲートウェイ装置２は、その取得した情報に基づいて変更する帯域を求め、本実施の形態と同様に申告帯域を変更することができる。

また、本実施の形態では、セッション制御プロトコルとしてＳＩＰを用いた場合を示したが、これに限らず、たとえばＨ．３２３やＭＥＧＡＣＯ（MEdia GAteway COntrol）等のように、ＳＩＰと同様にＩＰネットワーク上でセッション制御およびセッション管理ができる制御プロトコルであればよい。ＳＩＰ以外の制御プロトコルを用いる場合、本実施の形態と同様に、変更する帯域を求め、用いる制御プロトコルに対応した申告帯域の更新処理により、申告帯域を変更すればよい。

以上のように、本実施の形態では、セッション制御に対応していない端末３−１のセッション制御処理を代行するゲートウェイ装置２−１が、セッション制御の代行対象のパケットを中継する際に、パケット解析部２４が中継するパケットから抽出したパケット損失率を抽出し、帯域調整部２５がパケット損失率に基づいて申告する帯域の更新値を求めるようにした。そのため、セッション制御の対象となる既存端末間の通信に必要な帯域値を適切に呼制御ネットワーク４へ申告することができる。

実施の形態２．
図８は、本発明にかかる通信システムの実施の形態２の通信手順の一例を示すシーケンス図である。本実施の形態の通信システムの構成は、実施の形態１の通信システムの構成と同様であり、本実施の形態のゲートウェイ装置の構成も実施の形態１のゲートウェイ装置と同様である。以下の説明では、実施の形態１と同様の機能を有する要素は、実施の形態１と同一の符号を付すこととする。ただし、本実施の形態のセッション情報テーブル２３は、実施の形態１のセッション情報テーブル２３と一部異なる。本実施の形態のセッション情報テーブル２３については後述する。

実施の形態１では、端末３−１と端末３−２の間で、ＲＴＰおよびＲＴＣＰ通信を行う場合について説明した。一方、ＲＴＰおよびＲＴＣＰ通信に先立ってＲＴＳＰ（Real Time Streaming Protocol）通信が行われ、ＲＴＳＰ通信によって通信路が確立された後に、ＲＴＰおよびＲＴＣＰ通信が行われる場合がある。本実施の形態では、このようにＲＴＳＰ通信によって通信路が確立された後にＲＴＰおよびＲＴＣＰ通信が行われる場合について説明する。

まず、端末３−１から端末３−２に宛ててＲＴＳＰによる通信（ＲＴＳＰ通信）の開始を表すＴＣＰ−ＳＹＮパケット（通信開始パケット）を送信する（ステップＳ４１）。ゲートウェイ装置２−１のパケット中継部２１は、端末３−１からＴＣＰ−ＳＹＮパケット（通信開始パケット）を受信すると、そのパケットの中継を保留し、そのパケットをセッション制御部２２に渡す。セッション制御部２２は、通信開始パケットから送信元ＩＰアドレス、宛先ＩＰアドレス、プロトコル、送信元ポート番号、宛先ポート番号等のフロー情報を抽出し、セッション情報テーブル２３を参照して、抽出したフロー情報に対応するセッション制御パラメータを取得する（ステップＳ４２）。セッション制御部２２は、取得したセッション制御パラメータに基づいて、呼接続要求であるＩＮＶＩＴＥメッセージを生成し、生成したＩＮＶＩＴＥメッセージをＳＩＰサーバ１に送信する（ステップＳ４３）。

ＳＩＰサーバ１は、ＩＮＶＩＴＥメッセージを受信すると、セッション確立ための処理を実施中であること示す暫定応答“１００ Ｔｒｙｉｎｇ”をゲートウェイ装置２−１へ返信し（ステップＳ４４）、受信したＩＮＶＩＴＥメッセージを通信の宛先の端末３−２に接続するゲートウェイ装置２−２へ転送する（ステップＳ４５）。ゲートウェイ装置２−２は、“１００ Ｔｒｙｉｎｇ”をＳＩＰサーバ１へ返信する（ステップＳ４６）。

ゲートウェイ装置２−２は、セッション確立の処理が正常に終了すると“２００ ＯＫ”レスポンスをＳＩＰサーバ１に送信し（ステップＳ４７）、ＳＩＰサーバ１は、ゲートウェイ装置２−２から“２００ ＯＫ”レスポンスを受信すると“２００ ＯＫ”レスポンスをゲートウェイ装置２−１へ送信する（ステップＳ４８）。

ゲートウェイ装置２−１のセッション制御部２２は、ステップＳ４７で送信された“２００ ＯＫ”レスポンスをＳＩＰサーバ１から受信することにより通信路が確立されたことを検知すると、パケットの中継処理を再開するようパケット中継部２１に指示し、パケット中継部２１は、保留していたＴＣＰ−ＳＹＮパケットを端末３−２に転送する（ステップＳ４９）。

端末３−２は、ＴＣＰ−ＳＹＮパケットを受信すると、その応答であるＴＣＰ−ＳＹＮ／ＡＣＫを端末３−１へ返信する（ステップＳ５０）。端末３−１は、ＴＣＰ−ＳＹＮ／ＡＣＫを受信するとＴＣＰ−ＡＣＫを返信する（ステップＳ５１）。以上の手順により、端末３−１と端末３−２の間で、ＲＴＳＰ制御チャネルのためのＴＣＰコネクションが確立される。

ＲＴＳＰ制御チャネルのためのＴＣＰコネクションが確立されると、端末３−１は、端末３−２が送信するデータについてのメディア種別や帯域等の情報取得を要求する“ＲＴＳＰ ＤＥＳＣＲＩＢＥ”メッセージを送信する（ステップＳ５２）。端末３−２は、“ＲＴＳＰ ＤＥＳＣＲＩＢＥ”メッセージを受信すると、ＳＤＰにより記述されたメディア種別や帯域等の情報を含む“ＲＴＳＰ ２００ ＯＫ”レスポンスを送信する（ステップＳ５３）。

ステップＳ５３では、ゲートウェイ装置２−１のパケット中継部２１が“ＲＴＳＰ ２００ ＯＫ”レスポンスを中継する。この際、パケット中継部２１は中継する“ＲＴＳＰ ２００ ＯＫ”レスポンスのパケットをパケット解析部２４へ渡す。パケット解析部２４は、“ＲＴＳＰ ２００ ＯＫ”レスポンスのパケットに含まれるＳＤＰにより記載された情報から、セッション制御で必要となるＱｏＳパラメータを抽出し、保持する（ステップＳ５４）。セッション制御で必要となるＱｏＳパラメータは、たとえば、帯域情報、メディア種別、属性等である。

図９は、“ＲＴＳＰ ＤＥＳＣＲＩＢＥ”メッセージの一例を示す図であり、図１０は、その応答である“ＲＴＳＰ ２００ ＯＫ”レスポンスの一例を示す図である。図１０に示した“ｂ＝”を含む行は帯域を示し、“ｍ＝”を含む行はメディア種別を示し、“ａ＝”を含む行は属性を示している。

端末３−１は、“ＲＴＳＰ ２００ ＯＫ”レスポンスを受信すると、“ＲＴＳＰ ＳＥＴＵＰ”メッセージを送信する（ステップＳ５５）。端末３−２は、“ＲＴＳＰ ＳＥＴＵＰ”メッセージを受信すると、ＳＤＰで記述された情報を含む“ＲＴＳＰ ２００ ＯＫ”レスポンスを端末３−１に宛てて送信する（ステップＳ５６）。

ゲートウェイ装置２−１のパケット中継部２１は、“ＲＴＳＰ ２００ ＯＫ”レスポンスを受信すると中継を保留し、そのＲＴＳＰ ２００ ＯＫ”レスポンスをパケット解析部２４へ渡す。パケット解析部２４は、“ＲＴＳＰ ２００ ＯＫ”レスポンスのＳＤＰ記述部分から、保持しているＱｏＳパラメータのうち、ステップＳ４１の“ＲＴＳＰ ＳＥＴＵＰ”メッセージで設定が要求された通信に対応するＱｏＳパラメータを抽出し、抽出したＱｏＳパラメータをセッション制御部２３へ渡す。セッション制御部２３は、パケット解析部２４から受け取ったＱｏＳパラメータに基づいてＵＰＤＡＴＥメッセージを生成し、生成したＵＰＤＡＴＥメッセージをＳＩＰサーバ１へ送信する（ステップＳ５７）。

ＳＩＰサーバ１は、ＵＰＤＡＴＥメッセージを受信すると、ＵＰＤＡＴＥメッセージに基づいて要求された帯域を確保し、ＵＰＤＡＴＥメッセージをゲートウェイ装置２−２へ転送する（ステップＳ５８）。ゲートウェイ装置２−２は、ＵＰＤＡＴＥメッセージに基づいて要求された帯域を確保し、“２００ ＯＫ”レスポンスをＳＩＰサーバ１に送信する（ステップＳ５９）。ＳＩＰサーバ１は、ゲートウェイ装置２−２から“２００ ＯＫ”レスポンスを受信すると、“２００ ＯＫ”レスポンスをゲートウェイ装置２−１へ送信する（ステップＳ６０）。

ゲートウェイ装置２−１のパケット中継部２１は、２００ ＯＫ”レスポンスを受信すると、中継を保留していた“ＲＴＳＰ ２００ ＯＫ”レスポンスを端末３−１へ送信する（ステップＳ６１）。そして、端末３−１は、ステップＳ５５でＳＥＴＵＰを要求した通信の開始として“ＲＴＳＰ ＰＬＡＹ”メッセージを送信し（ステップＳ６２）、端末３−２は“ＲＴＳＰ ２００ ＯＫ”を返信する（ステップＳ６３）。以降、端末３−１と端末３−２の間でストリーミングによる通信を行うことができるようになる。

ここでは、端末３−１と端末３−２の間のストリーミング通信がＲＴＰ／ＲＴＣＰにより行われることとし、ステップＳ６３の後に、ストリーミング通信が行われる。ストリーミング通信の際の本実施の形態の動作は、実施の形態１のステップＳ２０〜ステップＳ２６と同様である。以上述べた以外の本実施の形態の動作は実施の形態１と同様である。

実施の形態１では、ゲートウェイ装置２−１は、セッション情報テーブルのセッション制御パラメータとしてＲＴＰ／ＲＴＣＰ通信に関する帯域情報の初期値を保持する必要があった。これに対し本実施の形態では、ＲＴＰ／ＲＴＣＰ通信の開始前に、ＲＴＳＰ制御チャネルを用いた“ＲＴＳＰ ２００ ＯＫ”レスポンスに含まれる帯域情報に基づいてＵＰＤＡＴＥメッセージが送信されるため、セッション情報テーブル２３ではＲＴＰ／ＲＴＣＰ通信に関する帯域情報の初期値を保持する必要がない。ただし、ゲートウェイ装置２−１は、ＲＴＳＰ通信の制御チャネルに関する帯域情報の初期値は保持する。

以上のように、本実施の形態では、セッション制御に対応していない端末３−１のセッション制御処理を代行するゲートウェイ装置２−１が、“ＲＴＳＰ ＤＥＳＣＲＩＢＥ”メッセージの応答の“ＲＴＳＰ ２００ ＯＫ”レスポンスに含まれる帯域情報に基づいて、ＵＰＤＡＴＥメッセージを生成し、ＲＴＳＰ通信用の用の帯域を確保するようにした。そのため、実施の形態１と同様の効果が得られるとともに、ゲートウェイ装置２−１がＲＴＰ／ＲＴＣＰ通信が、従来に比べセッション制御パラメータとして保持する情報量を削減することができる。

実施の形態３．
図１１は、本発明にかかるゲートウェイ装置２ａの実施の形態３の機能構成例を示す図である。本実施の形態のゲートウェイ装置２ａは、実施の形態１のパケット解析部２４おおよび帯域調整部２５の代わりに、ＴＣＰ観測部２６および帯域調整部２７を備える以外は、実施の形態１のゲートウェイ装置２と同様である。本実施の形態の通信システムの構成は、ゲートウェイ装置２−１，ゲートウェイ装置２−２を、それぞれ図１１に示した構成を有するゲートウェイ装置２ａ−１，ゲートウェイ装置２ａ−２に換える以外は、実施の形態１の通信システム（図１参照）と同様である。

ＴＣＰ観測部２６は、セッション制御の対象となるＴＣＰ通信を観測し、ＴＣＰパケットから受信ウィンドウサイズの抽出を行うとともに、ＲＴＴ（Round Trip Time）の測定を行う。帯域調整部２７は、受信ウィンドウサイズとＲＴＴに基づいて、セッション制御の対象となるＴＣＰ通信に必要な帯域を求める。

つぎに、本実施の形態の動作を説明する。図１２は、本実施の形態の通信システムの通信手順の一例を示すシーケンス図である。ここでは、端末３−１が端末３−２との間で、ＴＣＰ通信を行う場合について説明する。

端末３−１は、ＴＣＰ−ＳＹＮパケットを送信する（ステップＳ７１）。ゲートウェイ装置２ａ−１のパケット中継部２１は、受信したＴＣＰ−ＳＹＮパケットの中継を保留し、ＴＣＰ−ＳＹＮパケットをセッション制御部２２へ渡す。セッション制御部２２は、ＴＣＰ−ＳＹＮパケットから送信元ＩＰアドレス、宛先ＩＰアドレス、プロトコル、送信元ポート番号、宛先ポート番号等のフロー情報を抽出し、セッション情報テーブル２３を参照して、抽出したフロー情報に対応するセッション制御パラメータを取得する（ステップＳ７２）。セッション制御部２２は、取得したセッション制御パラメータに基づいて、呼接続要求であるＩＮＶＩＴＥメッセージを生成し、生成したＩＮＶＩＴＥメッセージをＳＩＰサーバ１に送信する（ステップＳ７３）。

以降のステップＳ７４〜ステップＳ８０は、実施の形態２のステップＳ４４〜ステップＳ５０と同様である。ゲートウェイ装置２ａ−１のパケット中継部２１は、ステップＳ８０でＴＣＰ−ＳＹＮ／ＡＣＫパケットを中継するとともに、ＴＣＰ−ＳＹＮ／ＡＣＫパケットをＴＣＰ観測部２６へ渡す。ＴＣＰ観測部２６は、ＴＣＰ−ＳＹＮ／ＡＣＫパケットからＴＣＰ受信ウィンドウサイズおよびウィンドウスケールオプションを抽出して保持する（ステップＳ８１）。

図１３は、ＴＣＰパケットのヘッダフォーマットの一例を示す図である。図１３の例は、ＩＥＴＦ（Internet Engineering Task Force）のＲＦＣ（Request For Comments）１３２３で規定されているウィンドウスケールオプションを用いる場合を示している。図１３の先頭から、緊急ポインタまでは標準のヘッダであり、“Ｋｉｎｄ＝２”以降はオプションのフィールドを示している。図１３の最後から３番目の“Ｋｉｎｄ＝３”以降の部分が、ウィンドウスケールオプションを示し、“Ｌｅｎｇｔｈ＝３”はそのオプションフィールド長さを示し、“シフトカウント”がウィンドウサイズの値をビットシフトする値を示している。

標準のＴＣＰパケットヘッダでは、ウィンドウサイズは最大で６５５３５バイトまでしか表現できないため、ＲＦＣ１３２３ではウィンドウスケールオプションとしてウィンドウサイズの値をビットシフトさせることにより、最大のウィンドウサイズを６５５３５バイトより大きい値に設定できるようにしている。したがって、標準のヘッダ部分に含まれるウィンドウサイズ（ＴＣＰ受信ウィンドウサイズ）と、このシフトカウントと、を用いて実際のウィンドウサイズを求めることができる。なお、ウィンドウスケールオプションを用いない場合には、ＴＣＰパケットのヘッダに含まれるウィンドウサイズの値に基づいてＴＣＰ受信ウィンドウサイズを求めればよい。

図１２を用いた説明に戻る。端末３−１は、ＴＣＰ−ＳＹＮ／ＡＣＫパケットを受信するとＴＣＰ−ＡＣＫパケットを端末３−２へ送信する（ステップＳ８２）。以上により、端末３−１と端末３−２の間のＴＣＰ ３ｗａｙハンドシェイクが終了し、端末３−１と端末３−２の間でデータの送受信が行なわれる（ステップＳ８３）。

ステップＳ８３のデータの送受信の間、ゲートウェイ装置２ａ−１では、パケット中継部２１は受信したデータを伝送するが、同時に受信したデータをＴＣＰ観測部２６に渡し、ＴＣＰ観測部２６が当該ＴＣＰトラフィックの観測を行なう（ステップＳ８４）。具体的には、ＴＣＰ観測部２６は、当該ＴＣＰトラフィックのうち、端末３−２から端末３−１へ送信されるＴＣＰ−ＡＣＫパケットから端末３−２側のＴＣＰ受信ウィンドウサイズを抽出する。また、ＴＣＰ観測部２６は、当該ＴＣＰトラフィックのうち、端末３−１から端末３−２へ送信されるＴＣＰパケットとそれに対する応答として端末３−２から端末３−１へ送信されるＴＣＰ ＡＣＫパケットとに基づいて、ＲＴＴの測定を行なう。ＴＣＰ観測部２６は、保持しているウィンドウスケールオプションと抽出したＴＣＰ受信ウィンドウサイズと測定したＲＴＴとを帯域調整部２７へ渡す。

そして、ゲートウェイ装置２ａ−１では、帯域調整部２７が、ウィンドウスケールオプションとＴＣＰ受信ウィンドウサイズおよびＲＴＴに基づいて最大帯域を求め、最大帯域がステップＳ７３で申告済みの帯域より大きい場合に、変更後の帯域値として申告済みの帯域値を増加させた値を求める。また帯域調整部２７は、申告済みの帯域より最大帯域が小さくかつ申告済みの帯域と最大帯域の差が所定の値Ｘより大きい場合に、変更後の帯域値として申告済みの帯域値を減少させた値を求める。そして、帯域調整部２７は、変更後の帯域値をセッション制御部２２へ渡す。セッション制御部２２は、帯域調整部２７から受け取った変更後の帯域値を申告する帯域として反映させたＵＰＤＡＴＥメッセージを生成し、生成したＵＰＤＡＴＥメッセージをＳＩＰサーバ１へ送信する（ステップＳ８５）。以降のステップＳ８６〜ステップＳ８８の処理は、実施の形態１のステップＳ２３〜ステップＳ２５と同様である。

ステップＳ８８の後、データの送受信を継続し（ステップＳ８９）、ゲートウェイ装置２ａ−１では、ステップ８４と同様にＴＣＰトラフィックを観測し、最大帯域が申告済みの帯域より大きい場合に、または申告済みの帯域より最大帯域が小さく申告済みの帯域と最大帯域の差が所定の値Ｘより大きい場合に、ステップＳ８５〜ステップＳ８８と同様の処理を行い申告する帯域を変更する。以上述べた以外の本実施の形態の動作は実施の形態１と同様である。

つぎに、ゲートウェイ装置２ａ−１の申告帯域の更新方法について詳細に説明する。図１４は、本実施の形態の申告帯域の更新方法の一例を示すフローチャートである。ＴＣＰ観測部２６は、端末３−１と端末３−２間のＴＣＰコネクション確立時のＴＣＰ−ＳＹＮ／ＡＣＫパケットをパケット中継部２１から受け取り、ＴＣＰ−ＳＹＮ／ＡＣＫパケットからウィンドウスケールオプションの値を抽出し、内部に保持する（ステップＳ９１）。

そして、ＴＣＰ観測部２６は、当該ＴＣＰコネクションで端末３−１から端末３−２へ送信されるＴＣＰパケットとそのＴＣＰパケットに対する応答として端末３−２から端末３−１へ送信されるＴＣＰ ＡＣＫパケットに基づいてＲＴＴを測定する（ステップＳ９２）。また、その際、端末３−２から送信されるＴＣＰ ＡＣＫパケットに含まれるウィンドウサイズ値を抽出する（ステップＳ９２）。

ＴＣＰ観測部２６は、保持しているウィンドウスケールオプションの値と抽出したウィンドウサイズ値と測定したＲＴＴとに基づいて、最大帯域を算出する（ステップＳ９３）。具体的には、ウィンドウスケールオプションの値とウィンドウサイズ値に基づいてを求め、最大帯域＝ＴＣＰ受信ウィンドウサイズ／ＲＴＴとして最大帯域を求める。

ＴＣＰ観測部２６は、最大帯域が、呼制御ネットワーク４へ申告済みの帯域より大きいか否かを判断する（ステップＳ９４）。なお、ＴＣＰ観測部２６は、呼制御ネットワーク４へ申告済みの帯域をセッション制御部２２から取得して保持していることとする。最大帯域が申告済みの帯域より大きい場合（ステップＳ９４ Ｙｅｓ）、ＴＣＰ観測部２６は、変更後の帯域として申告済みの帯域を増加させた値を求め、変更後の帯域をセッション制御部２２へ渡す（ステップＳ９５）。セッション制御部２２は変更後の帯域に基づいてＵＰＤＡＴＥメッセージを生成し、生成したＵＰＤＡＴＥメッセージをＳＩＰサーバ１へ送信し（ステップＳ９５）、ステップＳ９２に戻る。

最大帯域が申告済みの帯域以下の場合（ステップＳ９４ Ｎｏ）、ＴＣＰ観測部２６は、申告済みの帯域と最大帯域の差が所定の値Ｘより大きいか否かを判断する（ステップＳ９６）。申告済みの帯域と最大帯域の差が所定の値Ｘより大きい場合（ステップＳ９６ Ｙｅｓ）、ＴＣＰ観測部２６は、変更後の帯域として申告済みの帯域を減少させた値を求め、変更後の帯域をセッション制御部２２へ渡す（ステップＳ９７）。セッション制御部２２は変更後の帯域に基づいてＵＰＤＡＴＥメッセージを生成し、生成したＵＰＤＡＴＥメッセージをＳＩＰサーバ１へ送信し（ステップＳ９７）、ステップＳ９２に戻る。

また、申告済みの帯域と最大帯域の差が所定の値Ｘより大きくない場合（ステップＳ９６ Ｎｏ）、申告する帯域は変更せず、ステップＳ９２に戻る。

ステップＳ９５およびステップＳ９７での変更後の帯域の求め方としては、どのような方法を用いてもよいが、たとえば、求めた最大帯域を変更後の帯域とする方法がある。これに限らず、一定割合で増加（ステップＳ９７の場合は減少）させる、申告済みの帯域に一定値を加算する（ステップＳ９７の場合は減算）ことにより変更後の帯域を求めてもよい。

なお、本実施の形態では申告済みの帯域と最大帯域の差が所定の値Ｘより大きい場合に、申告する帯域を減少させるようにしているが、使用するアプリケーションやシステムの要求により、帯域を減少させることが望ましくない場合には、申告する帯域を減少させる処理を実施しないようにしてもよい。

なお、上記の例では、ＴＣＰコネクション生成側（ゲートウェイ装置２ａ−１）での帯域値の更新方法を示したが、ＴＣＰコネクションの受信側（ゲートウェイ装置２ａ−２）でも同様に、対向ＴＣＰノード（端末３−１）のＴＣＰ受信ウィンドウサイズおよびＲＴＴに基づいて、申告する帯域を変更するようにしてもよい。ＴＣＰコネクションの受信側でも同様の処理を行うことにより、双方向でそれぞれ適切な最大帯域に応じた帯域が確保された通信路を確立することができる。

また、さらに最初に呼制御ネットワーク４に申告する帯域値をフロー情報によらず固定値とすると、ゲートウェイ装置が、保持するセッション情報テーブルの帯域値に関する情報を削減することができる。

以上のように、本実施の形態では、ＴＣＰ観測部２６が、ＴＣＰコネクション確立時のＴＣＰ−ＳＹＮ／ＡＣＫパケットからウィンドウスケールオプションを抽出し、端末３−２から送信されたＴＣＰ ＡＣＫパケットに含まれるウィンドウサイズ値を抽出し、また、端末３−１と端末３−２の間で送信されるパケットに基づいてＲＴＴを測定する。そして、ＴＣＰ観測部２６は、ウィンドウスケールオプションとウィンドウサイズ値とＲＴＴとに基づいて求めた最大帯域に基づいて変更後の帯域を算出し、セッション制御部２２が、変更後の帯域を呼制御ネットワーク４へ申告するようにした。そのため、ＴＣＰを用いた通信を行なう場合に、セッション制御の対象となる既存端末間の通信に必要な帯域値を適切に呼制御ネットワーク４へ申告することができる。

実施の形態４．
図１５は、本発明にかかるゲートウェイ装置２ｂの実施の形態４の機能構成例を示す図である。本実施の形態のゲートウェイ装置２ｂは、実施の形態１のパケット解析部２４おおよび帯域調整部２５の代わりに、帯域測定部２８を備える以外は、実施の形態１のゲートウェイ装置２と同様である。本実施の形態の通信システムの構成は、ゲートウェイ装置２−１，ゲートウェイ装置２−２を、それぞれ図１５に示した構成を有するゲートウェイ装置２ｂ−１，ゲートウェイ装置２ｂ−２に換える以外は、実施の形態１の通信システム（図１参照）と同様である。

帯域測定部２８は、セッション制御の対象となる通信の通信帯域（送信帯域）を測定する。送信帯域の測定方法はどのような方法でもよいが、たとえば、帯域測定部２８は、所定の単位時間内に中継パケット２１が中継したセッション制御代行処理の対象通信のデータ量を積算し、積算したデータ量を単位時間で割ることにより送信帯域を測定する方法等がある。帯域測定部２８は、このように測定した送信帯域を、呼制御ネットワーク４に申告する帯域の更新値として求めるため、実施の形態１の帯域調整部２５等と同様に帯域調整手段としての機能を有する。

つぎに、本実施の形態の動作を説明する。図１６は、本実施の形態の通信システムの通信手順の一例を示すシーケンス図である。ここでは、端末３−１が通信を開始し、端末３−２との間で通信を行なう場合を例に説明する。なお、この通信は、以下のフロー情報などを含むパケットを送信する通信であればどのような種類の通信でもよく、たとえばＴＣＰの通信であってもよく、またＵＤＰの通信であってもよい。

まず、端末３−１は、端末３−２との間の通信の最初のパケットである通信開始パケットを送信する（ステップＳ１０１）。ゲートウェイ装置２ｂ−１では、パケット中継部２１が端末３−１から通信開始パケットを受信すると、当該パケットの中継を保留し、そのパケットを保持するとともにセッション制御部２２に渡す。セッション制御部２２は、受信した通信開始パケットから送信元ＩＰアドレス、宛先ＩＰアドレス、プロトコル、送信元ポート番号、宛先ポート番号等フロー条件に対応する情報を抽出し、セッション情報テーブル２３に基づいて抽出した情報と一致するフロー条件を検索し、検索して得られたフロー条件に対応するセッション制御パラメータを取得する（ステップＳ１０２）。

以降、実施の形態１のステップＳ１３〜ステップＳ１８と同様に、ステップＳ１０３〜ステップＳ１０８の処理を行う。ゲートウェイ装置２ｂ−１のセッション制御部２２は、ステップＳ１０８で送信された“２００ ＯＫ”レスポンスをＳＩＰサーバ１から受信することにより通信路が確立されたことを検知すると、パケットの中継処理を再開するようパケット中継部２１に指示し、パケット中継部２１は、保留していたパケット（ステップＳ１０１で送信されたパケット）を端末３−２に転送する（ステップＳ１０９）。

その後、端末３−１と端末３−２の間で通信が行なわれる（ステップＳ１１０）。その際、ゲートウェイ装置２ｂ−１では、パケット中継部２１が、端末３−１と端末３−２の間で通信パケットを中継するとともに、帯域測定部２８が、通信パケットに基づいて、送信（端末３−１からの送信）帯域の測定を行い、セッション制御部２２へ通知する（ステップＳ１１１）。

ゲートウェイ装置２ｂ−１のセッション制御部２２は、帯域測定部２８から通知された送信帯域を申告する帯域として用いたＵＰＤＡＴＥメッセージを生成し、生成したＵＰＤＡＴＥメッセージをＳＩＰサーバ１に送信する（ステップＳ１１２）。以降、実施の形態１のステップＳ２３〜ステップＳ２５と同様に、ステップＳ１１３〜ステップＳ１１５を実施する。これにより、呼制御ネットワーク４上に当該通信に応じた帯域が確保された通信路を確立する。端末３−１と端末３−２は、通信を継続し（ステップＳ１１６）、その間、帯域測定部２８は上記と同様に、通信パケットに基づいて、送信帯域の測定を行い、セッション制御部２２が、送信帯域に基づいてＵＰＤＡＴＥメッセージを送信する。以上述べた以外の本実施の形態の動作は実施の形態１と同様である。

なお、測定した送信帯域が申告済みの帯域と変わらない場合、または、測定した送信帯域と申告済みの帯域との差が所定の範囲内である場合には、送信帯域に基づくＵＰＤＡＴＥメッセージの送信を実施しないようにしてもよい。

また、帯域測定部２８は、所定の時間間隔ごとに送信帯域を測定するようにしてもよい。また、帯域測定部２８は、複数の測定した送信帯域を用いて平均化処理等の統計処理等を行い、処理後の送信帯域をセッション制御部２２へ渡すようにしてもよい。

また、上記の例では、通信開始側（ゲートウェイ装置２ｂ−１）が送信帯域を測定し、帯域を更新する方法を示したが、当該通信の受信側（ゲートウェイ装置２ｂ−２）でも、同様に送信（端末３−２からの送信）帯域の測定を行い、送信帯域に基づいて申告する帯域を更新するようにしてもよい。受信側でも同様の処理を行うことにより、双方向でそれぞれ適切な最大帯域に応じた帯域が確保された通信路を確立することができる。

また、さらに最初に呼制御ネットワーク４に申告する帯域値をフロー情報によらず固定値とすると、ゲートウェイ装置が、保持するセッション情報テーブルの帯域値に関する情報を削減することができる。

以上のように、本実施の形態では、ゲートウェイ装置２ｂ−１の帯域測定部２８が、中継する通信パケットに基づいて送信帯域を測定し、セッション制御部２２が送信帯域に基づいて呼制御ネットワーク４へ申告する帯域を更新するためのＵＰＤＡＴＥメッセージを送信するようにした。そのため、通信パケットの内容を解析することなく、実施の形態１と同様の効果を得ることができる。

以上のように、本発明にかかるゲートウェイ装置、通信システムおよび通信方法は、端末のセッション制御処理を代行するゲートウェイ装置を備える通信システムに有用であり、特に、多様なフロー条件の通信を扱う通信システムに適している。

１ ＳＩＰサーバ
２，２−１，２−２，２ａ，２ａ−１，２ａ−２，２ｂ−１，２ｂ−２ ゲートウェイ装置
３−１，３−２ 端末
４ 呼制御ネットワーク
５−１，５−２ ユーザネットワーク
２１ パケット中継部
２２ セッション制御部
２３ セッション情報テーブル
２４ パケット解析部
２５，２７ 帯域調整部
２６ ＴＣＰ観測部
２８ 帯域測定部

Claims (10)

1. 呼制御を実施する呼制御ネットワークと、呼制御機能を備えない端末と、接続し、前記呼制御ネットワークと前記端末間の通信を中継するゲートウェイ装置であって、
   前記端末が前記呼制御ネットワーク経由で行なう通信である呼制御通信における呼制御処理を代行し、前記呼制御通信が必要とする帯域を前記呼制御ネットワークへ申告する呼制御手段と、
   前記端末から受信した前記呼制御通信の通信パケットに基づいて、前記呼制御通信の帯域の更新値を求める帯域調整手段と、
   前記通信パケットに含まれる所定の情報を抽出するパケット解析手段と、
   を備え、
   前記呼制御通信をＲＴＰおよびＲＴＣＰを用いた通信とし、
   前記呼制御手段は、前記更新値を前記呼制御通信が必要とする帯域として前記呼制御ネットワークへ申告し、
   前記パケット解析手段は、Ｒｅｃｅｉｖｅｒ ＲｅｐｏｒｔパケットまたはＳｅｎｄｅｒ Ｒｅｐｏｒｔパケットに含まれるパケット損失率を前記情報として抽出し、
   前記帯域調整手段は、前記パケット損失率が所定の上限しきい値より大きい場合、前記更新値を申告済みの帯域より増加させるよう求め、前記更新値を増加させた後、一定時間内に前記パケット損失率の減少が観測できない場合には、増加させる前の値に前記更新値を変更する、
   ことを特徴とするゲートウェイ装置。
2. 前記帯域調整手段は、一定期間の間前記パケット損失率が所定の下限しきい値より小さい場合、前記更新値を申告済みの帯域より小さい値となるよう求める、
   ことを特徴とする請求項１に記載のゲートウェイ装置。
3. 前記呼制御通信としてさらにＲＴＳＰを用いた通信を含み、ＲＴＰおよびＲＴＣＰを用いた通信の前にＲＴＳＰを用いてＲＴＰおよびＲＴＳＰの通信路を確立することとし、
   前記パケット解析手段は、さらに、ＲＴＳＰの通信パケットに含まれる帯域情報を抽出し、
   前記帯域調整手段は、さらに前記帯域情報を前記更新値とする、
   ことを特徴とする請求項２に記載のゲートウェイ装置。
4. 呼制御を実施する呼制御ネットワークと、呼制御機能を備えない端末と、接続し、前記
   呼制御ネットワークと前記端末間の通信を中継するゲートウェイ装置であって、
   前記端末が前記呼制御ネットワーク経由で行なう通信である呼制御通信における呼制御処理を代行し、前記呼制御通信が必要とする帯域を前記呼制御ネットワークへ申告する呼制御手段と、
   前記端末から受信した前記呼制御通信の通信パケットに基づいて、前記呼制御通信の帯
   域の更新値を求める帯域調整手段と、
   前記呼制御通信を、ＴＣＰを用いた通信とし、前記呼制御通信のＴＣＰパケットとそのＴＣＰパケットに対する応答パケットとに基づいて、往復遅延時間を測定し、また、前記応答パケットから受信側ウィンドウサイズを抽出するＴＣＰ観測手段と、
   を備え、
   前記呼制御手段は、前記更新値を前記呼制御通信が必要とする帯域として前記呼制御ネ
   ットワークへ申告し、
   前記帯域調整手段は、前記往復遅延時間および前記受信側ウィンドウサイズに基づいて最大帯域を求め、前記最大帯域に基づいて前記更新値を求める、
   ことを特徴とするゲートウェイ装置。
5. 前記ＴＣＰ観測手段は、前記呼制御通信のＴＣＰコネクション確立の際に送信されるＴＣＰパケットからウィンドウスケールオプション情報を抽出し、
   さらに前記ウィンドウスケールオプション情報に基づいて前記最大帯域を求める、
   ことを特徴とする請求項４に記載のゲートウェイ装置。
6. 前記呼制御処理を、ＳＩＰを用いた処理とし、
   前記呼制御手段は、ＵＰＤＡＴＥメッセージを用いて前記更新値を前記呼制御通信が必要とする帯域として前記呼制御ネットワークへ申告する、
   ことを特徴とする請求項１〜５のいずれか１つに記載のゲートウェイ装置。
7. 呼制御を実施する呼制御ネットワークと、呼制御機能を備えない端末と、前記呼制御ネットワークと前記端末間の通信を中継するゲートウェイ装置と、を備える通信システムであって、
   ゲートウェイ装置は、
   前記端末が前記呼制御ネットワーク経由で行なう通信である呼制御通信における呼制御処理を代行し、前記呼制御通信が必要とする帯域を前記呼制御ネットワークへ申告する呼制御手段と、
   前記端末から受信した前記呼制御通信の通信パケットに基づいて、前記呼制御通信の帯域の更新値を求める帯域調整手段と、
   前記通信パケットに含まれる所定の情報を抽出するパケット解析手段と、
   を備え、
   前記呼制御通信をＲＴＰおよびＲＴＣＰを用いた通信とし、
   前記呼制御手段は、前記更新値を前記呼制御通信が必要とする帯域として前記呼制御ネットワークへ申告し、
   前記パケット解析手段は、Ｒｅｃｅｉｖｅｒ ＲｅｐｏｒｔパケットまたはＳｅｎｄｅｒ Ｒｅｐｏｒｔパケットに含まれるパケット損失率を前記情報として抽出し、
   前記帯域調整手段は、前記パケット損失率が所定の上限しきい値より大きい場合、前記更新値を申告済みの帯域より増加させるよう求め、前記更新値を増加させた後、一定時間内に前記パケット損失率の減少が観測できない場合には、増加させる前の値に前記更新値を変更する、
   ことを特徴とする通信システム。
8. 呼制御を実施する呼制御ネットワークと、呼制御機能を備えない端末と、前記呼制御ネットワークと前記端末間の通信を中継するゲートウェイ装置と、を備える通信システムであって、
   ゲートウェイ装置は、
   前記端末が前記呼制御ネットワーク経由で行なう通信である呼制御通信における呼制御処理を代行し、前記呼制御通信が必要とする帯域を前記呼制御ネットワークへ申告する呼制御手段と、
   前記端末から受信した前記呼制御通信の通信パケットに基づいて、前記呼制御通信の帯
   域の更新値を求める帯域調整手段と、
   前記呼制御通信を、ＴＣＰを用いた通信とし、前記呼制御通信のＴＣＰパケットとそのＴＣＰパケットに対する応答パケットとに基づいて、往復遅延時間を測定し、また、前記応答パケットから受信側ウィンドウサイズを抽出するＴＣＰ観測手段と、
   を備え、
   前記呼制御手段は、前記更新値を前記呼制御通信が必要とする帯域として前記呼制御ネ
   ットワークへ申告し、
   前記帯域調整手段は、前記往復遅延時間および前記受信側ウィンドウサイズに基づいて最大帯域を求め、前記最大帯域に基づいて前記更新値を求める、
   ことを特徴とする通信システム。
9. 呼制御を実施する呼制御ネットワークと、呼制御機能を備えない端末と、接続し、前記呼制御ネットワークと前記端末間の通信を中継するゲートウェイ装置における通信方法であって、
   前記端末が前記呼制御ネットワーク経由で行なう通信である呼制御通信における呼制御処理を代行し、前記呼制御通信が必要とする帯域を前記呼制御ネットワークへ申告する呼制御ステップと、
   前記端末から受信した前記呼制御通信の通信パケットに含まれる所定の情報を抽出するパケット解析ステップと、
   前記情報に基づいて、前記呼制御通信の帯域の更新値を求める帯域調整ステップと、
   前記更新値を前記呼制御通信が必要とする帯域として前記呼制御ネットワークへ申告する帯域更新ステップと、
   前記呼制御通信をＲＴＰおよびＲＴＣＰを用いた通信とし、
   前記パケット解析ステップでは、Ｒｅｃｅｉｖｅｒ ＲｅｐｏｒｔパケットまたはＳｅｎｄｅｒ Ｒｅｐｏｒｔパケットに含まれるパケット損失率を前記情報として抽出し、
   前記帯域調整ステップでは、前記パケット損失率が所定の上限しきい値より大きい場合、前記更新値を申告済みの帯域より増加させるよう求め、前記更新値を増加させた後、一定時間内に前記パケット損失率の減少が観測できない場合には、増加させる前の値に前記 更新値を変更する、
   ことを特徴とする通信方法。
10. 呼制御を実施する呼制御ネットワークと、呼制御機能を備えない端末と、接続し、前記呼制御ネットワークと前記端末間の通信を中継するゲートウェイ装置における通信方法であって、
    前記端末が前記呼制御ネットワーク経由で行なう通信である呼制御通信における呼制御処理を代行し、前記呼制御通信が必要とする帯域を前記呼制御ネットワークへ申告する呼制御ステップと、
    前記端末から受信した前記呼制御通信の通信パケットに含まれる所定の情報を抽出するパケット解析ステップと、
    前記情報に基づいて、前記呼制御通信の帯域の更新値を求める帯域調整ステップと、
    前記呼制御通信を、ＴＣＰを用いた通信とし、前記呼制御通信のＴＣＰパケットとそのＴＣＰパケットに対する応答パケットとに基づいて、往復遅延時間を測定し、また、前記応答パケットから受信側ウィンドウサイズを抽出するＴＣＰ観測ステップと、
    前記更新値を前記呼制御通信が必要とする帯域として前記呼制御ネットワークへ申告する帯域更新ステップと、
    を含み、
    帯域調整ステップでは、前記往復遅延時間および前記受信側ウィンドウサイズに基づいて最大帯域を求め、前記最大帯域に基づいて前記更新値を求める、
    ことを特徴とする通信方法。

Images