JP4986892B2 - 通信制御方法およびゲートウエイ装置 - Google Patents

Description

本発明は、次世代通信ネットワークにおける通信制御方法に関し、特に、コネクション（呼）を確立するための通信制御方法およびこれを実現するゲートウエイ装置に関する。

現在ＩＴＵ（International Telecommunication Union）で検討が進められているＮＧＮ（次世代ネットワーク：Next Generation Network）は、主にＳＩＰ（Session Initiation Protocol）による通信開始手順を広くＩＰ通信に適用し、ＱｏＳなどの高度なサービスをＩＰ接続ごとに提供することが可能なネットワークである。このＮＧＮではＩＰ接続を確立するに当たり、通信開始手順を実施してネットワークに接続を行うという一定の手続きを経て初めてＮＧＮ固有のサービスが適用され、あるいはＩＰ接続そのものも、この手続きを経て初めて可能になる場合がある。このとき、通信開始手順のためのリソース、並びにＩＰ接続数のリソースは制限されることが十分に考えられる。サービス提供者にとっては、無制限にしてしまうと簡単に攻撃対象にもなり得るため、サービス内容に応じた制限を設けるのが最も一般的な提供条件となることは想像に難くない。

一方、通信開始手順そのものの接続（これ以降、呼、またはセッションと表記）と、通信開始手順によって実際に接続された通信（これ以降、接続、またはコネクションと表記）は、１対１の関係のみならず、１対多の関係になる場合もある。これは、１回の呼制御、つまり通信開始手順によって複数の接続を確立することが可能であることを意味しており、この点に関してはＳＩＰも例外ではない。実際、ＳＩＰを利用して接続を確立するアプリケーションとして、ＶｏＤ（Video on Demand、ＲＴＳＰ（Real-Time Streaming Protocol）を用いることが多い）や電話（いわゆるＩＰ電話，ＶｏＩＰ（Voice over IP）を利用する）、テレビ電話などが実用化されているが、これらは音声と映像の２つのコネクションを一回の通信開始手順によって確立する。実際には更に、メディアデータを転送するためのプロトコルであるＲＴＰ（Real-Time Protocol）を利用するに当たって、ＲＴＣＰ（Real-Time Control Protocol）のコネクションを伴うことが一般的であるため、コネクション数で見ると更にその倍以上となる。このような使われ方が最も多いと予想されるため、サービス提供時の制限として、同時確立可能セッション数の２倍から数倍程度のコネクション数が設定される（に制限される）と予想される。従って、一回の通信開始手順で複数のコネクションを確立可能にすることは、通信開始手順を制御する上で重要である。さらに課金についても、その管理負荷軽減のため、コネクションよりもセッション単位になることも考えられ、セッション数を節約することはこうした面でも有効になる可能性がある。

現在ＮＧＮへ適用されつつあるアプリケーションは、上述したＶｏＤや電話、テレビ電話が挙げられるが、ＳＩＰにおける基本的な規定である下記非特許文献１〜３に従い、以下に示す動作を実行する。なお、以下に示す手順では、下記非特許文献１に記載されているＳＩＰの基本規定の他、特にセッションの更新に関する規定のみを抜粋した。実際のＳＩＰ手順は、以下に示した文献のみで規定されるものではない。

ＶｏＤで最も一般的なＲＴＳＰにおける動作を示す。ＲＴＳＰは元々図８に示すような手順を取るが、図８に示したＲＴＳＰ制御コネクション（ＲＴＳＰセッション）の確立前、並びにメディアストリーム開始前に一回ずつ主なＳＩＰ手順が実施される。図９は、そのＳＩＰ手順を示したものであり、ＶｏＤ端末とＶｏＤサーバとの間で次の手順が実行される。

１．ＲＴＳＰ制御用のコネクションをＮＧＮで確立するためのＳＩＰ手順を実施する。
２．ＲＴＳＰ制御コネクション（ＴＣＰ／ＩＰ）を確立する。
３．ＲＴＳＰ制御情報をやりとりしてメディアストリームのコネクション情報を決定する。
４．決定したコネクション情報を元に、メディアストリームの情報を付加したＳＩＰ手順（ＵＰＤＡＴＥ）を実施する。
５．メディアストリーム（ＶｏＤサーバからＶｏＤ端末へのアプリケーションデータの配信）を開始する。

ここで、ＵＰＤＡＴＥは、基本的には通信開始手順によって確立されたセッションの維持通知に利用される手順であるが、このようにコネクション情報そのものを追加・更新することも可能である。このとき下記非特許文献３にて規定されたＳＤＰのOffer/Answerモデルが利用される。これ自体、複数のコネクションを１つのセッションに集約しており、セッションリソースの節約に寄与している。

また、テレビ電話においては、図９に示した手順からＲＴＳＰ制御コネクションの確立手順とＵＰＤＡＴＥ手順を削除した手順でセッションおよびコネクションが確立される。テレビ電話の場合、音声ストリームのコネクション情報の他に映像ストリームのコネクション情報も併せて最初のＳＩＰ手順でやりとりされ、１つのセッションで２つのメディアストリーム(コネクション)を確立している。これもセッションリソースの節約になっている。

ここで、上述したＶｏＤでのセッション制御においては、専用のアプリケーションを利用することによりセッションリソースの節約を実現している。すなわち、一連の動作がアプリケーションの動作として確立しているものである。そのため、例えばＲＴＳＰでは動作しているが、ＦＴＰ（File Transport Protocol）でも動作させようとすると、ＦＴＰの制御コネクションの中身からＵＰＤＡＴＥ手順を発行するための専用のＦＴＰクライアントを新たに構築しなければならない。さらにサーバ側の対応も必須である。同様に、テレビ電話の場合においては、ＰＣ同士のテレビ電話であれば、さらにホワイトボード情報をやりとりするためのコネクションを確立して、ホワイトボードを共有するようなことも可能であるが、このアプリケーションに更にその機能を追加する必要があり、セッションリソースを節約する手段としては、各アプリケーションで閉じていて、汎用的ではない。逆に専用であることが重要で、汎用性は不要な世界であるともいうことができる。

一方、こうしたアプローチで各種アプリケーションをＮＧＮへ適用可能にしていくには、膨大なソフトウエア開発コストがかかることが予想される。オープンソース等での実施に期待することもできるが、ＮＧＮが一般化し、価格的にもリーズナブルになってこない限り適用は進まないと予想される。一方、それを避けて既存のアプリケーションでもＮＧＮで利用可能にするためのアプローチが検討されている（たとえば、下記特許文献１参照）。下記特許文献１では、ＮＧＮにおける通信開始手順と端末に実装されている通信開始手順が異なるシステム構成において、端末を収容し、ＮＧＮに接続するためのゲートウエイ装置が、ＮＧＮの通信開始手順と呼制御の通信開始手順の差異を吸収することにより収容している端末のＮＧＮを介した通信を実現している。

国際公開第０６／０５１５９４号パンフレット ＳＩＰ：Session Initiation Protocol, RFC（Request for Comments）3261, IETF(Internet Engineering Task Force), http://www.ietf.org/rfc/rfc3261.txt An Offer/Answer Model with the Session Description Protocol（ＳＤＰ）, RFC3264， IETF, http://www.ietf.org/rfc/rfc3264.txt The Session Initiation Protocol(ＳＩＰ) UPDATE Method, RFC3311, IETF, http://www.ietf.org/rfc/rfc3311.txt

たとえば、ＨＴＴＰ（Hyper Text Transfer Protocol）によるＷＷＷ（World Wide Web）などのアプリケーションでは、１つのページに複数の表示要素（画像、アイコンなど）があると、それぞれＨＴＴＰ／ＴＣＰコネクションを並行して確立し、サーバから取得する。そのため、１つのＴＣＰコネクションに対して１つの通信開始手順のセッションが必要となり、場合によっては同時セッション数制限にかかってコネクションを確立できず、また全てのコネクション１つ１つの確立／切断に通信開始手順を伴うため、ホームページを表示するまでの時間がＮＧＮを利用しているにも拘わらずかえって増大してしまう、という問題があった。

その他、場合によっては複数のＲＴＳＰのリクエストによるセッションが、同一の端末とサーバの間で確立される場合もあるが（ある家庭内の２つのテレビから同じＶｏＤサービスを利用するような場合）、従来、各ＲＴＳＰセッションを１つのセッションにまとめるような制御は行われておらず、セッション毎にリソースを必要としていた。すなわち、セッションリソースの効率的な利用が実現できていない、という問題があった。

本発明は、上記に鑑みてなされたものであって、セッションリソースの効率的な利用を実現する通信制御方法およびゲートウエイ装置を得ることを目的とする。

上述した課題を解決し、目的を達成するために、本発明は、単一のキャリアネットワークと、当該キャリアネットワークに接続された複数のゲートウエイ装置と、を含んだ通信システムにおいて、互いに異なるゲートウエイ装置に収容された通信装置同士がコネクションを確立した上で通信を行う場合の通信制御方法であって、前記複数のゲートウエイ装置の中の１つである第１のゲートウエイ装置が、配下の通信装置から発行された、自身とは異なる第２のゲートウエイ装置配下の通信装置宛の呼制御用のメッセージ、を複数検出した場合、当該検出した複数の呼制御用メッセージの一部または全部を集約して新たな呼制御用メッセージを生成し、さらに、当該生成した呼制御用メッセージを当該第２のゲートウエイ装置宛に送信するメッセージ送信ステップと、前記第２のゲートウエイ装置が、前記第１のゲートウエイ装置から自装置宛に送信された前記呼制御用メッセージに基づいて、前記第１のゲートウエイ装置により集約される前の各呼制御用メッセージを復元し、当該復元した各呼制御用メッセージをその宛先通信装置へ配信するメッセージ受信ステップと、を含み、前記第１のゲートウエイ装置と前記第２のゲートウエイ装置との間で１回の呼制御動作を実行することにより、前記新たな呼制御用メッセージに集約された呼制御用メッセージの数と同数のコネクションを、前記第１のゲートウエイ装置配下の通信装置と前記第２のゲートウエイ装置配下の通信装置との間で確立させることを特徴とする。

この発明によれば、複数のアクセスが発生した場合、それらの制御のためにほぼ同じタイミングで発行される同じ種類のメッセージを送信側のゲートウエイ装置が集約して対向するゲートウエイ装置宛に送信し、集約されたメッセージを受け取ったゲートウエイ装置は、集約される前の各メッセージを復元して宛先の通信装置へ配信することとしたので、各ゲートウエイ装置の間（すなわち次世代通信ネットワーク）におけるセッション接続数を節約することができ、セッションリソースの効率的な利用が実現できる、という効果を奏する。

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

実施の形態１．
本実施の形態では、メディアストリームを提供するＶｏＤサーバとメディアストリームの提供を受けるクライアント（ＶｏＤ端末）との間におけるセッション制御動作の例について説明する。

図１は、本発明にかかる通信制御方法を適用した通信システムの実施の形態１の構成例を示す図である。この通信システムは、ゲートウエイ装置１２、１３および１４と、ＶｏＤ端末２１、２２、３１および３２と、ＶｏＤサーバ４１と、を含んでいる。各ゲートウエイ装置は、自身が管理するネットワークとＮＧＮ（キャリアネットワーク）１００とを接続する。具体的には、ゲートウエイ装置１２は、自身が管理するネットワーク２００とＮＧＮ１００とを接続し、ゲートウエイ装置１３は、自身が管理するネットワーク３００とＮＧＮ１００とを接続し、ゲートウエイ装置１４は自身が管理するネットワーク４００とＮＧＮ１００とを接続する。また、ＶｏＤ端末２１および２２はゲートウエイ装置１２に管理されたネットワーク２００に属し、ＶｏＤ端末３１および３２はゲートウエイ装置１３に管理されたネットワーク３００に属している。ＶｏＤサーバ４１はネットワーク４００に属している。

図１に示した通信システムでは、各ＶｏＤ端末（ＶｏＤ端末２１，２２，３１，３２）およびＶｏＤサーバ４１がＳＩＰ制御機能を有しており、各通信装置（ＶｏＤ端末，ＶｏＤサーバ）間の通信開始手順はどれもＳＩＰで行うものとする。また、各ゲートウエイ装置（ゲートウエイ装置１２、１３および１４）は、配下の各通信装置（ＶｏＤ端末やＶｏＤサーバなど）から発行されたＮＧＮ（ＮＧＮ内に存在する図示していないＳＩＰサーバ）への端末登録手順（ＲＥＧＩＳＴＥＲ手順）を捕捉し、登録情報（ＲＥＧＩＳＴＥＲ情報）を保持しておく機能を有しているものとする。なお、図１では各ＶｏＤ端末がＰＣのイメージになっているが、一般的にはＳＴＢ（Set-top Box）とテレビの組合せである。

つづいて、図１に示した通信システムにおけるセッション制御動作について図２を参照しながら説明する。なお、図２は、実施の形態１における通信制御手順の一例を示すシーケンス図である。また、ＶｏＤ端末を収容しているゲートウエイ装置１２および１３では、ＶｏＤサーバ４１へのアクセスを集約対象としているものとする。

図２に示したように、ＶｏＤ端末２１および２２からほぼ同時にＶｏＤサーバ４１へのアクセスが発生した場合（発生時刻の差が規定の範囲内にある場合）、これらの端末を収容しているゲートウエイ装置１２は、受信した各通信開始手順メッセージ（ＩＮＶＩＴＥメッセージ）を集約し、新たなＩＮＶＩＴＥメッセージを生成してＮＧＮ１００に含まれるＳＩＰサーバ（図示せず）へ送信する。たとえば、ゲートウエイ装置１２は、ＩＮＶＩＴＥメッセージを最初に検出してから一定時間が経過するまでの間、配下のＶｏＤ端末から他のＩＮＶＩＴＥメッセージが発行されたかどうかを監視し、一定時間が経過した時点で最初に検出したものを含む複数のＩＮＶＩＴＥメッセージを検出した場合、検出した各ＩＮＶＩＴＥメッセージを集約して新たなＩＮＶＩＴＥメッセージを生成する。

ＩＮＶＩＴＥメッセージを集約するにあたって、厳密な実装にはＳＩＰの多くのヘッダ情報の処理が課題となるが、ＶｏＤでは特別な機能は必要なく、またどちらの通信も同一のネットワークにアクセスに行くことから、そうした問題を起こすようなヘッダは適用されていないものとする。ここで、ＳＩＰ／ＳＤＰにおいては、ゲートウエイ装置１２は以下の処理を実行する。

（１−１）受信した各ＩＮＶＩＴＥメッセージからＴｏヘッダ情報（メッセージの宛先の情報）を抽出し、新たに生成するメッセージのＳＤＰへ展開する。
（１−２）各ヘッダを一本化して、新たに生成するメッセージのヘッダに記述する。また、記述しないヘッダについては記憶しておく。具体的には、Via，Max-Forwards，Call-ID，From，CSeq，Contact，Allow等の情報を記憶する。なお、ヘッダを一本化するにあたっては、最初に検出したＩＮＶＩＴＥメッセージのヘッダをそのまま利用し、後から検出したＩＮＶＩＴＥメッセージのヘッダを記憶するようにしてもよい。
（１−３）各ＩＮＶＩＴＥメッセージからＳＤＰを抽出し、新たに生成するメッセージのＳＤＰ内の先頭部分に設定するパラメータ群（具体的には、ｖ値，ｏ値，ｓ値，ｃ値，ｔ値）を一本化する。たとえば、抽出したＳＤＰの中のいずれか一つについての上記パラメータ群を新たに生成するメッセージのパラメータ群として採用する。また、一本化するにあたって採用しなかったＳＤＰのパラメータ群については記憶しておく。
（１−４）上記抽出した各ＳＤＰ内のｍ値とこれに続いて設定されているパラメータであるｃ値，ａ値，ｂ値などを、検出した順番通りに、新たに生成するメッセージのＳＤＰへ記述する。ここで、ｍ値毎に「a=x-aggregation-to-hdr:<sip:xxxxxx@melco.co.jp>」というパラメータを追加し、宛先との対応付けを行っている。なお、このａ値はあくまでも一例である。

ここで、上述した処理を実行して新たに生成したＩＮＶＩＴＥメッセージ（集約されたＩＮＶＩＴＥメッセージ）のＳＤＰの記述例を図３に示す。

ＶｏＤ端末２１および２２から発行されたＩＮＶＩＴＥメッセージに基づいてゲートウエイ装置１２により新たに生成されたＩＮＶＩＴＥメッセージ（集約されたＩＮＶＩＴＥメッセージ）は、ＮＧＮ１００のＳＩＰサーバを経由して、最終的にゲートウエイ装置１４に到達する。ゲートウエイ装置１４は、集約されたＩＮＶＩＴＥメッセージを受け取ると、その内容に基づいて、送信側のゲートウエイ装置１２で集約される前の各ＩＮＶＩＴＥメッセージ（ＶｏＤ端末２１および２２から発行されたＩＮＶＩＴＥメッセージ）を復元し、それぞれの宛先へ配信する。

ここで、上述したように、ゲートウエイ装置１４は、配下のＶｏＤサーバ４１が発行するＮＧＮへの端末登録手順（ＲＥＧＩＳＴＥＲ手順）を捕捉し、登録情報を保持しておく機能を有している。そのため、集約されたＩＮＶＩＴＥメッセージを受信した際、そのＳＤＰに記述されたパラメータ「a=x-aggregation-to-hdr:<sip:xxxxxx@melco.co.jp>」から、復元した各ＩＮＶＩＴＥメッセージをどのＶｏＤサーバに振り分ければよいかを把握できる。すなわち、当該電話番号（上記パラメータの“xxxxxx”部分に相当）をキーとしてＲＥＧＩＳＴＥＲ情報（登録情報）を検索することにより、ＶｏＤサーバのContact先およびＩＰアドレスを取得できる。また、その他のヘッダ情報は、受信側（SIP-UAS側）ではCall-IDと各種のセッションIDを示す値（tag，transactionなど）を除いてそのままコピーして振り分けることが可能である。この例では、振分け先のＶｏＤサーバが１つであるため、２つのＳＩＰ手順（ＶｏＤ端末２１および２２に対応する２つの手順）に振り分けられるものの、復元されたＩＮＶＩＴＥメッセージの宛先は同一となる。したがって、対応が取れるよう保持しておき、ユニークになるようにすれば、これらの値（上記Call-IDと各種のセッションIDを示す値を除いた、その他のヘッダ情報）はゲートウエイ装置１４で適当に決めることが可能である。

ゲートウエイ装置１４からＩＮＶＩＴＥメッセージを受け取ったＶｏＤサーバ４１は、受信した各セッションに対する応答を返す。すべてのセッションについてＯＫであれば、コネクション情報を記述したＳＤＰと共に「２００ ＯＫメッセージ」（以下、単に「ＯＫメッセージ」と記載）を返す。ＯＫでなければ各種のエラーを返す。そして、ＶｏＤサーバ４１から応答を受け取ったゲートウエイ装置１４は、以下の動作を実行する。

（２−１）各ＩＮＶＩＴＥメッセージに対する応答メッセージがすべてＯＫメッセージであった場合、各応答メッセージのＳＤＰを集約して網から受け取ったＳＩＰメッセージ（上記ＳＩＰサーバを介してゲートウエイ装置１２から受け取った集約されたＩＮＶＩＴＥメッセージ）のヘッダ情報を適用したＯＫメッセージを生成し、ＳＩＰサーバ経由でゲートウエイ装置１２へ送信する。
（２−２）各ＩＮＶＩＴＥメッセージに対する応答メッセージの一方がエラーメッセージで、他方がＯＫメッセージだった場合、エラーだった方のＳＤＰ記述において、ポート番号（ｍ値パラメータの２番目の数値）を‘０’に設定したＯＫメッセージを生成し、ＳＩＰサーバ経由でゲートウエイ装置１２へ送信する。なお、セッションを３つ以上集約した場合であって、その中の一部がエラーの場合、エラーとなったセッションに対応するＳＤＰ記述のポート番号を‘０’に設定する。
（２−３）各応答メッセージがすべてエラーだった場合、例えば重要度の高いエラーコードを選択してエラーメッセージを生成し、ＳＩＰサーバ経由でゲートウエイ装置１２へ送信する。なお、エラーコードの伝達についても、先の宛先情報の伝達において、新たに「x-aggregation-to-hdr」というパラメータを追加することによって対応付けを行ったのと同様に、例えば「x-aggregation-response」というパラメータを追加し、ｍ値毎に「a=x-aggregation-response:404 Not Found」などと記述することで、各応答メッセージに記載されたエラーコードを発呼元へそれぞれ伝達することが可能になる。もちろん、本パラメータを上記手順（２−２）にて生成するＯＫ応答メッセージにおいて、エラーとなった方のＳＤＰ記述に含めるようにしてもよい。

以上の動作により、ＲＴＳＰ制御セッションをどちらが受け入れ可能で、あるいはどちらも受け入れ可能でないかを発呼側（ゲートウエイ装置１２側）に伝えることができる。

そして、応答メッセージを受け取った発呼側のゲートウエイ装置１２では、受け取った応答メッセージを適切に正しいＶｏＤ端末に振り分ける。応答メッセージの振り分けを行うにあたっては、受け取った応答メッセージ内の情報と、上述したＩＮＶＩＴＥメッセージを集約する処理にて記憶しておいた情報とを利用して各ＶｏＤ端末に対応する応答メッセージを復元する。このとき、応答メッセージ内のＳＤＰに含まれるｍ値のポート番号が‘０’でエラーであればエラーメッセージを生成し、一方、有効な値であればＯＫメッセージを生成し、それぞれの宛先（ＶｏＤ端末）へ送信する。この時点で、正確にＲＴＳＰコネクションの確立可否がＶｏＤ端末に伝えられる。ＳＩＰ手順としては、それぞれの端末がさらにＡＣＫメッセージを返すので、上述したＩＮＶＩＴＥメッセージを受信した場合と同様に、送信側のゲートウエイ装置１２が各ＡＣＫメッセージを集約して送信し、受信側のゲートウエイ装置１４が受け取った集約されたＡＣＫメッセージから元のＡＣＫメッセージを復元してＶｏＤサーバに分配する。なお、一般に、ＡＣＫメッセージにはＳＤＰが存在しないため、ＩＮＶＩＴＥメッセージの集約処理に含まれるＳＤＰに関する処理はＡＣＫメッセージの集約処理において実施しない。

こうして、本来ならＮＧＮからみて複数（上述した例では２つ）のセッションになるはずのＶｏＤセッションが１つのセッションに集約される。この後は、以下の手順が実行される。

（３−１）それぞれのＲＴＳＰ制御コネクションが確立され、メディアストリームの各種情報がやりとりされる。
（３−２）ＰＬＡＹ等のコマンドが実行されると、それ以前に収集したメディアストリーム情報をＵＰＤＡＴＥメッセージのＳＤＰに展開してリクエストを送信する。ＵＰＤＡＴＥはクライアントから発行される場合もサーバから発行される場合もある。ここではクライアントから発行された場合について説明する。ＵＰＤＡＴＥ手順は、各クライアントから任意のタイミングで発行されるが、ＵＰＤＡＴＥは更新手順なので２つのＶｏＤ端末からのＵＰＤＡＴＥを集約する必要はない。網側のヘッダ情報、セッション情報に正しく置き換えつつ、それぞれのタイミングでＵＰＤＡＴＥのリクエストを行えばよい。
（３−３）切断も各クライアントから任意のタイミングで発行される。従って、切断時の実装の仕方はいくつかのパターンが考えられる。たとえば、以下の実装が考えられる。なお、以下の方法は、２つのＶｏＤ端末とも無事にＶｏＤサービスを受けている場合であり、このときのシーケンスは図２の下の方に示されている。
（３−３ａ）最初のＢＹＥメッセージを受け取ると、ＵＰＤＡＴＥによって該当するＲＴＳＰおよびメディアコネクションを切断する。具体的には、ゲートウエイ装置１２が、受け取ったＢＹＥメッセージに含まれる情報をＵＰＤＡＴＥメッセージのＳＤＰに展開して送信する。そしてＵＰＤＡＴＥメッセージを受け取ったゲートウエイ装置１４がその中に含まれる情報に基づいて元のＢＹＥメッセージを復元して宛先のＶｏＤサーバへ配信する。
（３−３ｂ）次のＢＹＥメッセージを受け取り、残りがそれ自身のコネクション（残っていた最後のコネクション）だと判定すると、通常通りに、ＮＧＮに対してもＢＹＥを発行して、セッションを切断する。

このように、本実施の形態では、ＳＩＰ制御機能を有する通信装置（ＶｏＤ端末，ＶｏＤサーバなど）を収容したゲートウエイ装置の間で複数のアクセスが発生した場合、それらの制御のためにほぼ同じタイミングで発行される同じ種類のメッセージを送信側のゲートウエイ装置が集約して対向する（受信側の）ゲートウエイ装置宛に送信し、集約されたメッセージを受け取ったゲートウエイ装置は、集約される前の各メッセージを復元して宛先の通信装置へ配信することとした。これにより、各ゲートウエイ装置の間におけるセッション接続数を節約することができ、特に、ＶｏＤサービスのセッション接続数を節約することができる。たとえば、企業における教育などでＶｏＤを利用する場合、「多くの人が合図と共に一斉に見始める」という特性を考えただけでも効果が大きいことが想像される。したがって、セッション数ごとに課金が発生するサービスの提供を受ける場合において、セッション数を抑えた契約とし、経費を節約することができる。

なお、上記説明では、予め集約対象として選択されていたＶｏＤサーバ４１へのアクセスのみを検出した場合について説明したが、実際には、他のアクセスも検出される。したがって、ゲートウエイ装置は、配下の通信装置から通信開始手順メッセージであるＩＮＶＩＴＥメッセージを検出した場合、その中に含まれるメッセージごとの個別情報（プロトコル情報、宛先端末（通信装置）のアドレス情報、送信元端末（通信装置）のアドレス情報、宛先アプリケーション情報など）を利用して、検出したメッセージが集約対象のメッセージかどうかを判定し、集約対象と判定した場合、それらの集約処理を実行する。集約対象かどうかの判定を行うにあたっては、上記個別情報に含まれるすべてを利用してもよいし一部を利用してもよい。

実施の形態２．
つづいて、実施の形態２の通信制御方法について説明する。上述した実施の形態１で示した通信制御方法は、ＩＰ電話アプリケーションへの適用を考えた場合、あまり現実的ではない。すなわち、ＳＩＰ手順がいわゆる接続確立に徹していないアプリケーションでは現実的ではない。そこで、本実施の形態では、ＮＧＮ経由で通信を行う通信装置（端末）の通信開始手順とＮＧＮの通信開始手順が異なり、ゲートウエイ装置がそれを吸収しているような環境における通信制御方法について説明する。ここでは、上述した特許文献１に記載されたＳＩＰアダプテーション機能を各ゲートウエイ装置が有している（各ゲートウエイ装置が配下の装置に代わってＳＩＰ制御を行う）ものとする。

図４は、実施の形態２の通信制御方法を適用した通信システムの構成例を示す図である。この通信システムは、実施の形態１の通信システム（図１参照）と同じネットワークおよびゲートウエイ装置を含み、各ゲートウエイ装置に収容された通信装置の構成が実施の形態１の通信システムと異なる。具体的には、ネットワーク２００が映像サーバ（ネットワークカメラ）２３〜２５を収容し、ネットワーク３００が映像サーバ（ネットワークカメラ）３３〜３５を収容している。また、ネットワーク４００が映像表示端末４２を収容している。なお、ＮＧＮ１００ではＳＩＰによるセッション制御が要求され、一方ネットワーク２００、３００および４００では、ＩＰベースのセッション制御が要求される。

上記各ネットワークカメラは、電源が入り、自らのセットアップが終了すると、あらかじめ設定されている内容に従って動作を開始する。ここではその動作はＵＤＰユニキャストパケットに含まれる制御情報に従い、カメラ映像ストリーム（ＲＴＰ）を送信するものとする。具体的には、制御情報が示すＩＰアドレス、ポート番号へカメラ映像ストリームを送信するものとする。

また、ゲートウエイ装置１２および１３には、以下のようなグループエントリが設定されているものとする。
○ゲートウエイ装置１２に設定されたグループエントリ
宛先ＩＰアドレス／ポート 集約番号 タイムアウト
ａ．映像表示端末４２／９０１１ １２ ５
ｂ．映像表示端末４２／９０２１ １２ ５
ｃ．映像表示端末４２／９０３１ １２ ５
○ゲートウエイ装置１３に設定されたグループエントリ
宛先ＩＰアドレス／ポート 集約番号 タイムアウト
ａ．映像表示端末４２／９０１２ １３ ３
ｂ．映像表示端末４２／９０２２ １３ ３
ｃ．映像表示端末４２／９０３２ １３ ３

ここで、グループエントリ内の集約番号は各セッションをグループ分けしたものであり、ゲートウエイ装置は、この番号に基づいて、ほぼ同じタイミングで発生したセッション同士を集約できるかどうかを判定する。すなわち、異なるエントリであっても同一の番号であればセッション集約の対象とすること示す。またタイムアウトは、当該エントリに一致するコネクション要求（コネクションの確立を要求する情報）を最初に検出した場合、当該コネクション要求と同一の通信開始手順に集約するコネクション要求をここに指定した時間まで待つということを表す。たとえば、ゲートウエイ装置１２では、各エントリにヒットする最初のコネクション要求があってから５秒間は他の集約すべきコネクション要求を待つようにしている。５秒間待っても何も来なかった（集約すべきコネクション要求すなわち集約番号が同じコネクション要求を受け取らなかった）場合は、最初に検出したコネクション要求１つで通信開始手順１つ分のリソースを占有する。

なお、各カメラのＱｏＳ情報は、上記特許文献１で示したＱｏＳテーブルにエントリとして設定されているものとする。ここで、ＱｏＳテーブルとは、ゲートウエイ装置が収容している通信装置から発行されるＴＣＰ、ＵＤＰなどの個別のＩＰ通信セッションを特徴づけるセッション情報（プロトコル番号、ＩＰアドレス、プロトコルに対応したポート番号、ＴＯＳ(Type of Service)値など）と、当該セッションを呼制御ネットワークに通すに当たって呼制御ネットワーク上に確保したいリソース情報としてのＱｏＳ情報（ピークレート、平均レート、バーストサイズ、遅延レベルなど）との対応を定義したものであり、ゲートウエイ装置が保持している情報テーブルである。実装時、グループ設定エントリはＱｏＳテーブルに取り込んでいくのが望ましい。本実施の形態の通信制御方法は、ＱｏＳテーブルに集約番号とタイムアウトの項目を追加するだけでとりあえず実現可能である。

またここで、各カメラには以下の映像ストリームの宛先（宛先ＩＰアドレス／ポート番号）設定および映像帯域設定が適用されているものとする。
カメラ（映像サーバ）２３：映像表示端末４２／９０１１，８０００Ｋｂ／ｓ
カメラ（映像サーバ）２４：映像表示端末４２／９０２１，２４００Ｋｂ／ｓ
カメラ（映像サーバ）２５：映像表示端末４２／９０３１，４０００Ｋｂ／ｓ
カメラ（映像サーバ）３３：映像表示端末４２／９０１２，４０００Ｋｂ／ｓ
カメラ（映像サーバ）３４：映像表示端末４２／９０２２，２４００Ｋｂ／ｓ
カメラ（映像サーバ）３５：映像表示端末４２／９０３２，４０００Ｋｂ／ｓ

カメラはいくつか種類があり、図５に示したタイミングでＵＤＰストリームメディア（映像ストリーム）を流し始めたとすると、各ゲートウエイ装置はカメラからの映像ストリーム（ＵＤＰパケット）受信する。このとき、上記設定に従った動作を行うことにより、各ゲートウエイ装置では、それぞれ以下の集約結果となる。
○ゲートウエイ装置１２での集約結果
映像サーバ３台を１つのＳＩＰセッションに集約する。
○ゲートウエイ装置１３での集約結果
映像サーバ３３の集約は行わずに単独で１つのＳＩＰセッションを使用し、
また、映像サーバ３４および３５を１つのセッションに集約する。

図６は、実施の形態２のゲートウエイ装置１２におけるＳＩＰシーケンスの一例を示す図である。本実施の形態のシーケンスでは、ゲートウエイ装置１２は、基本的に、各映像サーバからＵＤＰストリームメディアが流されてくるのを待つだけであり、ＲＴＳＰと比較して、非常にシンプルな手順となっている。また、図７は、本実施の形態のセッション制御におけるＳＤＰ記述例（集約されたＩＮＶＩＴＥメッセージのＳＤＰの記述例）を示す図である。この記述例では、到着したＵＤＰメッセージ順に従い各パラメータ（ｍ値からａ値まで）が設定されている。また、ＳＩＰアダプテーション環境では、集約されたＳＤＰで直接宛先のアドレス情報を伝達する必要がある。そのため以下の拡張パラメータを追加している。
a=x-dest-host:1.0.0.1
a=x-dest-port:9021

上記パラメータは、名前の通り、一方は宛先ＩＰアドレス、もう一方はポート番号を示している。ＦＷ（Fire Wall）等があれば、受信側ゲートウエイ装置ではこのポート、アドレスについてＦＷに穴を開けるなどの処理が必要になる。また、ＳＤＰのｍ値に適用されているポート番号（２番目の数値）は、ストリームパケットのＵＤＰソースポート番号に相当する。

なお、上記はグローバルアドレスの場合についての例であるが、近年もっとも適用が進んでいるＮＡＰＴ（Network Address Port Translation）環境での例を以下に示す。このＮＡＰＴ環境においては、上述したグローバルアドレスの場合と比較して、以下の違いが生ずる。

（Ｉ）発呼側のゲートウエイ装置では、ｍ値に指定するポート番号は、ゲートウエイ装置が動的ＮＡＰＴで決定した、ＮＡＰＴ変換後のポート番号を適用する。
（ＩＩ）着呼側のゲートウエイ装置では、以下の２種類の動作が可能となる。
（ａ）x-dest-hostパラメータおよびx-dest-portパラメータを利用する。
この場合、着呼側のゲートウエイ装置は、これらのパラメータを利用して、空きのグローバルポート番号を自動的に算出し、そのグローバルポート番号と当該情報に示された宛先アドレスで静的ＮＡＰＴを設定する。ＯＫメッセージのＳＤＰに載せるｍ値のポート番号には、ここで算出したグローバルポート番号を適用する。
（ｂ）あらかじめＮＡＰＴ設定を行っておく。
この場合、着呼側のゲートウエイ装置は、あらかじめＮＡＰＴ設定を行っておき、x-dest-portパラメータのみを利用する。この動作を適用した場合、ＮＡＰＴ設定がない場合にはエラーとして受け付けないようにすることで、セキュリティを高められる。

なお、上記（ａ）では、着呼側端末におけるアプリケーションのポート番号だけでなくローカルＩＰアドレスを発呼側であらかじめ知っておく必要があるため、上記（ｂ）の方がより現実的である。上記（ｂ）では、アプリケーションがＵＰｎＰ等と連係することにより、発呼側が着呼側端末のローカルＩＰアドレスを知らなくても、ポート番号だけを知っていれば接続が可能である。

また、上記（ｂ）では、isubパラメータを利用するようにして、拡張を伴わない（x-dest-hostパラメータのみならずx-dest-portパラメータも利用しない）実施を実現することも可能である。isubは一般に１９桁までの数値のみ指定可能であるため、特にグループ化を伴う場合はポート番号の指定範囲に制限が生じてしまうが、それでも拡張の必要性がないというのは大きなメリットである。

isubパラメータを利用する場合の一例として、ＳＤＰに記述した各コネクションと同じ順番で各ポート番号を集約し、４桁ずつを１つのポート番号とする場合を示す。たとえば、図６に示したシーケンスにおけるＩＮＶＩＴＥメッセージに対してisubパラメータを利用する方式を適用した場合、isub値は「isub=902190119031」となる。

そして、isubパラメータを利用する場合、着呼側のゲートウエイ装置は、記述されたＳＤＰのｍ値毎に、isub値の先頭から４桁ずつを抽出してグローバルポート番号として扱う。その対応関係は以下のようになる。
１）ｍ＝ｖｉｄｅｏ ３８０２１ ＲＴＰ／ＡＶＰ ２６ に対しては ９０２１
２）ｍ＝ｖｉｄｅｏ ３８０１１ ＲＴＰ／ＡＶＰ ２６ に対しては ９０１１
３）ｍ＝ｖｉｄｅｏ ３８０３１ ＲＴＰ／ＡＶＰ ２６ に対しては ９０３１

なお、この例ではｍ値指定のポート番号がきれいにそろっているが、実際には動的ＮＡＰＴで自動算出するため無作為な値となる。

監視カメラの需要は近年急速に高まってきており、遠隔の拠点から映像を配信するとコストもかかるようになる。そして元々のＳＩＰアダプテーション機能では、１メディアストリームに１セッションを消費してしまう。そのため、本実施の形態で示したグループ化機能（セッションを集約する機能）によってコネクション数および予約帯域を維持していながらセッション数を減らすことが可能となり、品質を維持したままコスト削減に貢献することができる。

このように、本実施の形態では、ＳＩＰ制御機能を有していない通信装置（映像サーバ，映像表示装置など）を収容し、収容している通信装置に代わってＳＩＰによるセッション制御を実行するゲートウエイ装置を含んだ通信システムにおいて、第１のゲートウエイ装置から第２のゲートウエイ装置に向けた複数のアクセスがほぼ同じタイミングで発生した場合、第１のゲートウエイ装置では、これら複数のセッションに関する情報を１つのメッセージのＳＤＰへ集約して第２のゲートウエイ装置宛に送信し、集約された情報が搭載されたメッセージを受け取った第２のゲートウエイ装置は、受信した情報（集約された情報）に基づいて、上記の各アクセスを集約したセッションの制御を行うこととした。これにより、各ゲートウエイ装置の間におけるセッション接続数を節約することができる。この結果、同時に確立されるセッション数を削減して、規定のセッション数制限の中で提供されるサービスを最大限に利用することが可能となる。

以上のように、本発明にかかる通信制御方法は、次世代通信ネットワーク（ＮＧＮ）を介してサービス提供を受ける場合の通信制御に有用であり、特に、利用可能なセッション数が制限されたネットワークにおいて同時に確立するセッション数が増加するのを防止してセッションリソースの効率的な利用を実現する通信制御方法に適している。

本発明にかかる通信制御方法を適用した通信システムの実施の形態１の構成例を示す図である。 実施の形態１における通信制御手順の一例を示すシーケンス図である。 ＲＴＳＰ制御コネクションリクエストのＳＤＰ集約結果の一例を示す図である。 実施の形態２の通信制御方法を適用した通信システムの構成例を示す図である。 各映像サーバがＵＤＰストリームメディアを流し始めるタイミングの一例を示す図である。 実施の形態２のゲートウエイ措置におけるＳＩＰシーケンスの一例を示す図である。 実施の形態２のゲートウエイ措置への映像ストリームの入力タイミングの一例を示す図である。 従来技術を説明するための図である。 従来技術を説明するための図である。

符号の説明

１２、１３、１４ ゲートウエイ措置
２１、２２、３１、３２ ＶｏＤ端末
２３、２４、２５、３３、３４、３５ 映像サーバ（ネットワークカメラ）
４１ ＶｏＤサーバ
４２ 映像表示端末
１００ ＮＧＮ（キャリアネットワーク）
２００、３００、４００ ネットワーク

Claims (17)

1. 単一のキャリアネットワークと、当該キャリアネットワークに接続された複数のゲートウエイ装置と、を含んだ通信システムにおいて、互いに異なるゲートウエイ装置に収容された通信装置同士がコネクションを確立した上で通信を行う場合の通信制御方法であって、
   前記複数のゲートウエイ装置の中の１つである第１のゲートウエイ装置が、配下の通信装置から発行された、自身とは異なる第２のゲートウエイ装置配下の通信装置宛の呼制御用のメッセージ、を複数検出した場合、当該検出した複数の呼制御用メッセージの一部または全部を集約して新たな呼制御用メッセージを生成し、さらに、当該生成した呼制御用メッセージを当該第２のゲートウエイ装置宛に送信するメッセージ送信ステップと、
   前記第２のゲートウエイ装置が、前記第１のゲートウエイ装置から自装置宛に送信された前記呼制御用メッセージに基づいて、前記第１のゲートウエイ装置により集約される前の各呼制御用メッセージを復元し、当該復元した各呼制御用メッセージをその宛先通信装置へ配信するメッセージ受信ステップと、
   を含み、
   前記第１のゲートウエイ装置と前記第２のゲートウエイ装置との間で１回の呼制御動作を実行することにより、前記新たな呼制御用メッセージに集約された呼制御用メッセージの数と同数のコネクションを、前記第１のゲートウエイ装置配下の通信装置と前記第２のゲートウエイ装置配下の通信装置との間で確立させることを特徴とする通信制御方法。
2. 前記メッセージ送信ステップでは、最初に呼制御用メッセージを検出した時点から規定時間が経過し、かつその時点で複数の呼制御用メッセージを検出していた場合に、それまでに検出した呼制御用メッセージを集約して新たな呼制御用メッセージを生成することを特徴とする請求項１に記載の通信制御方法。
3. 前記メッセージ送信ステップでは、検出した呼制御用メッセージが規定数に達した場合、それまでに検出した呼制御用メッセージを集約して新たな呼制御用メッセージを生成することを特徴とする請求項１または２に記載の通信制御方法。
4. 前記メッセージ送信ステップでは、さらに、前記検出した各呼制御用メッセージに含まれるプロトコル情報、宛先通信装置アドレス情報、送信元端末アドレス情報および宛先アプリケーション情報の少なくともいずれか一つに基づいて、当該各呼制御用メッセージの中から集約対象とする呼制御メッセージを選択し、集約対象として選択した呼制御用メッセージに基づいて新たな呼制御用メッセージを生成することを特徴とする請求項１、２または３に記載の通信制御方法。
5. 前記新たに生成する呼制御用メッセージをＳＩＰによる呼制御で使用するメッセージとすることを特徴とする請求項１〜４のいずれか一つに記載の通信制御方法。
6. 前記第２のゲートウエイ装置は、配下の通信装置から前記キャリアネットワーク内のＳＩＰサーバ宛に発行されたＲＥＧＩＳＴＥＲメッセージを検出した場合、当該検出したＲＥＧＩＳＴＥＲメッセージ内の情報を保持しておき、
   前記メッセージ受信ステップでは、前記第１のゲートウエイ装置から受信した呼制御用メッセージおよび前記ＲＥＧＩＳＴＥＲメッセージを受信した際に保持しておいた情報に基づいて、当該第１のゲートウエイ装置により集約される前の各呼制御用メッセージを復元することを特徴とする請求項５に記載の通信制御方法。
7. 前記メッセージ送信ステップでは、呼制御用メッセージの１つであるＩＮＶＩＴＥメッセージを複数検出した場合、当該検出した複数のＩＮＶＩＴＥメッセージの一部または全部を集約して新たなＩＮＶＩＴＥメッセージを生成し、さらに、当該生成した新たなＩＮＶＩＴＥメッセージを前記第２の特定のゲートウエイ装置宛に送信し、
   前記メッセージ受信ステップでは、前記第１のゲートウエイ装置から自装置宛に送信された新たなＩＮＶＩＴＥメッセージに基づいて、当該第１のゲートウエイ装置により集約される前の各ＩＮＶＩＴＥメッセージを復元し、当該復元した各ＩＮＶＩＴＥメッセージをその宛先通信装置へ配信することを特徴とする請求項５または６に記載の通信制御方法。
8. さらに、
   前記第１のゲートウエイ装置または前記第２のゲートウエイ装置が、１回の呼制御動作を実行して確立させた複数のコネクションの中の１つを切断するためのＢＹＥメッセージを配下の通信装置から受信し、かつ当該ＢＹＥメッセージが切断対象とするコネクションが前記複数のコネクションの中で最後に切断するコネクションとは異なる場合、当該ＢＹＥメッセージの切断対象であるコネクションを切断対象としてＵＰＤＡＴＥメッセージの中に展開し、対向するゲートウエイ装置へ送信する第１の切断処理ステップと、
   前記ＢＹＥメッセージが展開されたＵＰＤＡＴＥメッセージを受信したゲートウエイ装置が、当該ＵＰＤＡＴＥメッセージに基づいて、当該ＵＰＤＡＴＥメッセージに展開される前のＢＹＥメッセージを復元し、当該復元したＢＹＥメッセージをその宛先通信装置へ配信する第２の切断処理ステップと、
   を含むことを特徴とする請求項７に記載の通信制御方法。
9. 第１の制御手順によりコネクションを確立した上での通信を必須とする第１のネットワークと、当該第１の制御手順とは異なる第２の制御手順によりコネクションを確立した上での通信またはコネクションを確立せずに行う通信が可能な複数の第２のネットワークと、当該第１のネットワークと当該第２のネットワークを接続する複数のゲートウエイ装置と、を含んだ通信システムにおける通信制御方法であって、
   前記複数のゲートウエイ装置の中の１つである第１のゲートウエイ装置が、配下の通信装置から発行された、自身とは異なる第２のゲートウエイ装置配下の通信装置との通信開始を示すメッセージ、を複数検出した場合、当該検出した複数のメッセージの一部または全部を選択し、選択した各メッセージに基づいて、前記第１のネットワーク上でコネクションを確立するため呼制御用メッセージを生成し、さらに、当該生成した呼制御用メッセージを当該第２のゲートウエイ装置宛に送信する呼制御用メッセージ送信ステップと、
   前記第２のゲートウエイ装置が、前記第１のゲートウエイ装置から自装置宛に送信された前記呼制御用メッセージに基づいて、前記第１のゲートウエイ装置に選択された各メッセージを一まとめにして通過させるためのコネクションを前記第１のネットワーク内で確立させるコネクション確立ステップと、
   を含み、
   前記コネクション確立ステップを実行後、前記第１のゲートウエイ装置により選択された各メッセージの送信元通信装置および宛先通信装置の間の通信では、前記確立させたコネクション経由でメッセージをやりとりすることを特徴とする通信制御方法。
10. 前記呼制御用メッセージ送信ステップでは、最初に通信開始を示すメッセージを検出した時点から規定時間が経過し、かつその時点で複数の通信開始を示すメッセージを検出していた場合に、それまでに検出した通信開始を示すメッセージに含まれる制御情報に基づいて、前記呼制御用メッセージを生成することを特徴とする請求項９に記載の通信制御方法。
11. 前記呼制御用メッセージ送信ステップでは、検出した通信開始を示すメッセージが規定数に達した場合、それまでに検出した通信開始を示すメッセージに含まれる制御情報に基づいて、前記呼制御用メッセージを生成することを特徴とする請求項９または１０に記載の通信制御方法。
12. 前記第１のゲートウエイ装置は、通信開始を示すメッセージをグループ分けするための情報であるグループ管理情報を保持し、
    前記呼制御用メッセージ送信ステップでは、通信開始を示すメッセージを検出した場合、前記グループ管理情報および検出したメッセージに含まれる制御情報に基づいて当該検出したメッセージのグループ分けを行い、次に、各グループ内のメッセージに基づいて各グループに対応する呼制御用メッセージを複数生成し、さらに、当該生成した各呼制御用メッセージを当該第２のゲートウエイ装置宛に送信し、
    前記コネクション確立ステップでは、前記第１のゲートウエイ装置から自装置宛に送信された呼制御用メッセージの数と同数の前記コネクションを前記第１のネットワーク内で確立させ、
    以降、前記各グループに属する各メッセージの送信元通信装置および宛先通信装置の間の通信では、前記グループ管理情報および処理対象のメッセージに含まれる制御情報に基づいて特定される、前記コネクションの中の一つを経由してメッセージをやりとりすることを特徴とする請求項９、１０または１１に記載の通信制御方法。
13. 前記第１の制御手順をＳＩＰによる制御手順とすることを特徴とする請求項９〜１２のいずれか一つに記載の通信制御方法。
14. 前記第２の制御手順をＴＣＰ／ＩＰによる制御手順とすることを特徴とする請求項１３に記載の通信制御方法。
15. 前記呼制御用メッセージ送信ステップでは、前記選択した各メッセージの宛先通信装置を示すアドレス情報と、ポート番号情報と、をＳＤＰに記述したＩＮＶＩＴＥメッセージを前記呼制御用メッセージとして生成することを特徴とする請求項１３または１４に記載の通信制御方法。
16. 前記呼制御用メッセージ送信ステップでは、前記選択した各メッセージの宛先通信装置が同一である場合、当該宛先通信装置の電話番号を「toヘッダ」情報内の「宛先パラメータ」に設定し、さらに各メッセージに含まれるポート番号情報を集約して生成した情報を「toヘッダ」情報内の「isubパラメータ」に設定したＩＮＶＩＴＥメッセージを前記呼制御用メッセージとして生成することを特徴とする請求項１３または１４に記載の通信制御方法。
17. 請求項１〜１６のいずれか一つに記載の通信制御方法を実現することを特徴とするゲートウエイ装置。

Images