(57)【特許請求の範囲】
【請求項１】
ＩＰ端末が収容される呼制御機能を前提としない複数の第１のＩＰネットワークと、前記複数の第１のＩＰネットワーク間にあって呼制御／呼管理機能を有する第２のＩＰネットワークと、前記第１のＩＰネットワークと第２のＩＰネットワークとを連結するゲートウエイ装置とを備える通信ネットワークにおけるＩＰパケット中継方法において、
送信元ＩＰ端末を収容する第１のＩＰネットワークに接続される送信元側ゲートウエイ装置が、送信元ＩＰ端末が発行するＴＣＰセッション確立要求パケットを捉え、該ＴＣＰセッション確立要求パケットをＩＰフレームごと呼接続要求パケット内部に展開することにより、ＴＣＰセッション確立要求パケットに対応した呼接続要求パケットを生成して発行する第１ステップと、
宛先ＩＰ端末を収容する第１のＩＰネットワークに接続される宛先側ゲートウエイ装置が、受信した呼接続要求パケット内に含まれるＴＣＰセッション確立要求パケットを取り出して宛先ＩＰ端末に送信する第２ステップと、
前記宛先側ゲートウエイ装置が、前記宛先ＩＰ端末が発行するＴＣＰセッション確立応答パケットを捉え、該ＴＣＰセッション確立応答パケットをＩＰフレームごと呼接続応答パケット内部に展開することにより、ＴＣＰセッション確立応答パケットに対応した呼接続応答パケットを生成して発行する第３ステップと、
送信元側ゲートウエイ装置が、受信した呼接続応答パケット内に含まれるＴＣＰセッション確立応答パケットを取り出して送信元ＩＰ端末に送信する第４ステップと、
を備え、ＩＰ端末間でＴＣＰセッションを確立するのと同時に第２のＩＰネットワークにおける呼も確立することを特徴とする通信ネットワークにおけるＩＰパケット中継方法。
【請求項２】
ＴＣＰセッションをＴＣＰセッション終了パケットによって切断する場合、
前記送信元側ゲートウエイ装置が、送信元ＩＰ端末および宛先ＩＰ端末から送信される２つのＴＣＰセッション終了パケットを検出することに基づいて呼切断要求パケットを生成して発行することにより、ＴＣＰセッションの終了と同時に第２のＩＰネットワークにおける呼も切断するようにしたことを特徴とする請求項１に記載の通信ネットワークにおけるＩＰパケット中継方法。
【請求項３】
ＴＣＰセッションをＴＣＰ-ＲＳＴパケットによって切断する場合、
ＴＣＰ-ＲＳＴパケットを発行したＩＰ端末側のＧＷ装置が、前記ＴＣＰ-ＲＳＴパケットを捉え、このＴＣＰ-ＲＳＴパケットはそのまま転送するとともに、呼切断要求パケットを生成して発行することにより、ＴＣＰセッションを中断するのと同時に第２のＩＰネットワークにおける呼接続も切断することを特徴とする請求項１に記載の通信ネットワークにおけるＩＰパケット中継方法。
【請求項４】
ＩＰ端末が収容される呼制御機能を前提としない複数の第１のＩＰネットワークと、前記複数の第１のＩＰネットワーク間にあって呼制御／呼管理機能を有する第２のＩＰネットワークと、前記第１のＩＰネットワークと第２のＩＰネットワークとを連結するゲートウエイ装置とを備える通信ネットワークにおけるＩＰパケット中継方法において、
送信元ＩＰ端末を収容する第１のＩＰネットワークに接続される送信元側ゲートウエイ装置が、送信元ＩＰ端末が発行するＴＣＰセッション確立要求パケットを捉え、このＴＣＰセッション確立要求パケットをそのまま転送するとともに呼接続要求パケットを生成して発行する第１ステップと、
宛先ＩＰ端末を収容する第１のＩＰネットワークに接続される宛先側ゲートウエイ装置が、受信した前記ＴＣＰセッション確立要求パケットをそのまま宛先ＩＰ端末に送信するとともに、受信した前記宛先ＩＰ端末が発行するＴＣＰセッション確立応答パケットをそのまま転送し、呼接続要求パケットを受信すると送信元ＩＰ端末に呼接続応答パケットを返信する第２ステップと、
前記送信元ゲートウエイ装置が、前記ＴＣＰセッション確立応答パケットおよび前記呼接続応答パケットを捉え、これらの同期を取った後にＴＣＰセッション確立応答パケットを送信元ＩＰ端末へ転送する第３ステップと、
を備え、ＴＣＰセッションと呼接続を同時に確立するようにしたことを特徴とする請求項１に記載の通信ネットワークにおけるＩＰパケット中継方法。
【請求項５】
ＩＰ端末が収容される呼制御機能を前提としない複数の第１のＩＰネットワークと、前記複数の第１のＩＰネットワーク間にあって呼制御／呼管理機能を有する第２のＩＰネットワークと、前記第１のＩＰネットワークと第２のＩＰネットワークとを連結するゲートウエイ装置とを備える通信ネットワークにおけるＩＰパケット中継方法において、
送信元ＩＰ端末を収容する第１のＩＰネットワークに接続される送信元側ゲートウエイ装置は、送信元ＩＰ端末からの新しいＵＤＰセッションにおける最初のＵＤＰパケットを受信したときのみ呼接続要求パケットを生成して発行するとともに、受信した各ＵＤＰパケットをそのまま転送し、
宛先ＩＰ端末を収容する第１のＩＰネットワークに接続される宛先側ゲートウエイ装置は、前記呼接続要求パケットに対して呼接続応答パケットを返信し、
新しいＵＤＰセッションにおける最初の段階で第２のＩＰネットワークにおける呼接続を確立するようにしたことを特徴とする通信ネットワークにおけるＩＰパケット中継方法。
【請求項６】
前記送信元側ゲートウエイ装置は、所定時間の間、呼にパケットが流れないことを検出した場合、呼接続を切断してリソースを解放することを特徴とする請求項５に記載の通信ネットワークにおけるＩＰパケット中継方法。
【請求項７】
ＩＰ端末が収容される呼制御機能を前提としない複数の第１のＩＰネットワークと、前記複数の第１のＩＰネットワーク間にあって呼制御／呼管理機能を有する第２のＩＰネットワークと、前記第１のＩＰネットワークと第２のＩＰネットワークとを連結するゲートウエイ装置とを備える通信ネットワークにおけるＩＰパケット中継方法において、
ゲートウエイ装置に、前記ＩＰ端末から発行されるＩＰ通信セッションを特徴づけるセッション情報と、当該ＩＰ通信セッションを第２のＩＰネットワークに通すに当たって第２のＩＰネットワーク上に確保したいリソース情報とを対応づけたテーブルを予め用意し、
前記ゲートウエイ装置が、第１のＩＰネットワークが発行する通信要求パケットあるいは最初に送信されるデータパケットを捉えてこれを解析することにより前記第２のＩＰネットワーク内に所要の呼を確立して、ＩＰパケットを前記第２のＩＰネットワーク内を通過させるとき、ゲートウエイ装置は、前記第１のＩＰネットワークが発行する通信要求パケットあるいは最初に送信されるデータパケットが受信されると、当該パケットから抽出されるセッション情報で前記テーブルを検索し、ヒットした場合に対応するリソース情報および当該パケットを含む呼接続要求パケットを発行することを特徴とする通信ネットワークにおけるＩＰパケット中継方法。
【請求項８】
前記テーブル検索がヒットしなかった場合、リソース確保を伴わないセッションとみなして呼接続を行うことを特徴とする請求項７に記載の通信ネットワークにおけるＩＰパケット中継方法。
【請求項９】
ＩＰ端末が収容される呼制御機能を前提としない複数の第１のＩＰネットワークと、前記複数の第１のＩＰネットワーク間にあって呼制御／呼管理機能を有する第２のＩＰネットワークと、前記第１のＩＰネットワークと第２のＩＰネットワークとを連結するゲートウエイ装置とを備える通信ネットワークにおけるＩＰパケット中継方法において、
前記第２のＩＰネットワークがＱｏＳサーバを備え、
前記ゲートウエイ装置が、第１のＩＰネットワークが発行する通信要求パケットあるいは最初に送信されるデータパケットを捉えてこれを解析することにより前記第２のＩＰネットワーク内に所要の呼を確立して、ＩＰパケットを前記第２のＩＰネットワーク内を通過させるとき、該ＱｏＳサーバが制御対象となる呼制御ネットワークのＩＰルート情報および各経路上のリソースの状況を全て把握し、更に第２のＩＰネットワークの各ノードに対してリソース確保を行うための設定変更を促すことにより、リソースを伴う呼制御を受け付け、受入可否を判断することを特徴とする通信ネットワークにおけるＩＰパケット中継方法。
【請求項１０】
前記ＱｏＳサーバが複数個備えられ、
各ＱｏＳサーバは、それぞれの呼制御担当範囲における前記受入可否の判断および実際のリソース確保を行うための設定変更を呼制御担当範囲のノードに対して要求することを特徴とする請求項９に記載の通信ネットワークにおけるＩＰパケット中継方法。
【請求項１１】
呼接続要求パケットを前記複数のＱｏＳサーバ間を順次転送させ、各ＱｏＳサーバは、リソース確保を伴う呼接続要求の受入可否を判断し、受入が可能であれば次のＱｏＳサーバへ転送し、不可能であれば途中でエラーとして応答することにより、要求のあった呼接続の受入可否を判断していくことを特徴とする請求項１０に記載の通信ネットワークにおけるＩＰパケット中継方法。
【請求項１２】
第２のＩＰネッワークの各ノードが、第２のＩＰネットワーク内をＴＣＰパケットが流れるときに、呼のルートをＱｏＳサーバで判断させるための情報および各ノードにおけるリソースの空き状況に関する情報をＱｏＳサーバへ通知し、
ＱｏＳサーバが、この通知された情報に基づいて呼のルート及び該ルート上の各ノードのリソースの空き状況を判断することを特徴とする請求項９に記載の通信ネットワークにおけるＩＰパケット中継方法。
【請求項１３】
送信元ＩＰ端末を収容する第１のＩＰネットワークに接続される送信元側ゲートウエイ装置が、最初のＵＤＰパケットを受信すると、データ部以外は検出した最初のＵＤＰパケットと同じで大きさが０あるいは所定のデータパターンのデータ部を有する独自のＵＤＰパケットを生成して、受信した最初のＵＤＰパケットとともに転送し、
第２のＩＰネッワークの各ノードが、この独自のＵＤＰパケットが第２のＩＰネットワーク内を流れるときに、呼のルートをＱｏＳサーバで判断させるための情報および各ノードにおけるリソースの空き状況に関する情報をＱｏＳサーバへ通知し、
ＱｏＳサーバが、この通知された情報に基づいて呼のルート及び該ルート上の各ノードのリソースの空き状況を判断することを特徴とする請求項９に記載の通信ネットワークにおけるＩＰパケット中継方法。
【請求項１４】
ＩＰ端末が収容される呼制御機能を前提としない複数の第１のＩＰネットワークと、前記複数の第１のＩＰネットワーク間にあって呼制御／呼管理機能を有する第２のＩＰネットワークと、前記第１のＩＰネットワークと第２のＩＰネットワークとを連結するゲートウエイ装置とを備える通信ネットワークにおけるＩＰパケット中継方法において、
制御セッションを確立してその中で別のセッションを確立するためのネゴシエーションを行うプロトコルが、第２のＩＰネットワークを介してＩＰ端末間で実行される場合、
送信元ＩＰ端末を収容する第１のＩＰネットワークに接続される送信元側ゲートウエイ装置は、前記ネゴシエーションプロトコルパケットを捉えて中継するのと同時に、ネゴシエーションパケットの中を解析し、該ネゴシエーションプロトコルによって今後利用されるセッション情報を抽出して、当該ネゴシエーションプロトコルに規定されたセッション確立コマンドに相当するものが発行されるのと同時に、該セッションを通すための呼を確立することを特徴とする通信ネットワークにおけるＩＰパケット中継方法。
【請求項１５】
制御セッションを確立してからのネゴシエーションによって確立されるセッションが、その記述を解析した結果ネットワークリソース確保を要求するとき、あるいはそのセッションを流れるアプリケーションデータ量の特性が一定の規定から算出されるような場合、  前記送信元側ゲートウエイ装置は、その内容も合わせて解析し、当該セッションを確立する要求が発行された場合には、ネットワークリソース確保も同時に行いつつ、呼制御ネットワークにおける呼の確立も行うことを特徴とする請求項１４に記載の通信ネットワークにおけるＩＰパケット中継方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＩＰ(インターネットプロトコル)ネットワークと、これをベースとした呼制御ネットワークと、それらを接続するためのゲートウエイ装置とを備える通信ネットワークにおけるＩＰパケット中継方法およびゲートウエイ装置に関するものである。
【背景技術】
【０００２】
ゲートウエイと呼ばれる位置づけの機能あるいは装置としては、各種の定義がなされている。まず、ゲートウエイと同様の位置づけにあるものとして、イーサネット（登録商標）を収容可能なＡＴＭ(Asynchronous  Transfer  Mode)ルータ、あるいはＡＴＭ-ＬＡＮスイッチなどのＡＴＭ通信装置が挙げられる。また、既存のアナログ電話、ＰＳＴＮ(Public  Switched  Telephone  Network：公衆交換電話網)あるいはＰＢＸ(Private  Branch  Exchange)等とＩＰネットワークを連結することに現状多く適用されているＭＧＣＰ(Media  Gateway  Control  Protocol:    IETF  RFC3435)ゲートウエイ、ＳＩＰ(Session  Initiation  Protocol:    IETF  RFC3261)ゲートウエイなどがある。さらに、マルチメディア通信を実現するための呼制御プロトコルとしてＨ.３２３(ITU-T勧告  H.323)も利用されている。これらのゲートウエイあるいはゲートウエイに相当する装置は、以下のようなネットワーク構成において、プロトコル変換あるいはメディア変換に利用される。【０００３】
図１０は、ＡＴＭスイッチあるいはＡＴＭルータが、既存のイーサネット（登録商標）によるＩＰネットワークとＡＴＭネットワークとの間のゲートウエイとして利用されている場合の例を示すものである。一般にＡＴＭルータはつぎのように動作する。
１.イーサネット（登録商標）からパケットが入力されと、その宛先ＭＡＣアドレスを検索して送信すべきＡＴＭコネクションを特定し、入力されたパケットをＡＡＬパケットにカプセル化してそのコネクション上に転送する。
２.ＡＴＭネットワークからパケットが入力した場合も同様であり、その宛先ＭＡＣアドレスから送信すべきイーサネット（登録商標）ポートを特定してイーサネット（登録商標）上に転送する。
ここでは、ＡＴＭルータが、イーサネット（登録商標）と、コネクションオリエンテッドのＡＴＭという全く性質の異なるネットワーク方式のＡＴＭネットワークとの間を中継するゲートウエイとして機能している。【０００４】
図１１は、ＰＳＴＮ（公衆交換電話網）とＩＰネットワークのＨ.３２３ゲートウエイによる一般的な接続構成を示す図である。Ｈ.３２３ゲートウエイ（ＧＷ）では、アナログ電話における電気信号がそのまま利用されているシグナリングプロトコルと、既存ＩＰネットワーク上を流れるＨ.３２３との間のプロトコル変換を行う。Ｈ.３２３ゲートウエイにおける基本的な手順は以下のようになる。
１.受話器が取られたことを示すオフフック信号をＨ.３２３ＧＷが受ける。
２.電話番号を入力すると、それをＨ.３２３  ＧＷで解析して、当該電話番号に対応した対向のＨ.３２３ＧＷとの間で、Ｈ.２２５.０Ｑ.９３１呼設定を行う。
３.Ｈ.２４５ロジカルチャネルを設定する。
４.ＵＤＰセッションにおいて、ＲＴＰ(Real-time  Protocol)音声信号が転送される。
すなわち、アナログ電話の出す信号をＨ.３２３ＧＷが受けて、Ｈ.３２３プロトコルに展開して対向のＨ.３２３ゲートウエイと音声データをやりとりするためのＵＤＰ/ＩＰセッションを確立し、音声データのやりとり(通話)を開始する。なお、音声データをやりとりするためのＵＤＰ/ＩＰセッションを確立するための制御に、ＴＣＰ/ＩＰセッションが確立され、そこで上記のＱ.９３１やＨ.２４５がやりとりされる。ここでも、Ｈ.３２３ゲートウエイは、結果的にアナログ電話という仮想回線でさえないコネクションオリエンテッドな端末をＩＰネットワークというコネクションレスの通信方式へ中継している。【０００５】
また、特許文献１においては、Ｈ.３２３とＳＩＰとのプロトコル変換を行うゲートウエイが提案されている。この特許文献１のゲートウエイは、少なくとも１つのＳＩＰエージェントに対するＨ.３２３エイリアスを格納するためのＳＩＰエージェントエイリアステーブルを有し、このゲートウエイは少なくとも１つのＨ.３２３クライアントエンドポイントと少なくとも１つのＳＩＰエージェントとの間でシグナリング変換を実施する。【０００６】
そして、近年ではもともとＩＰ電話のために開発されたプロトコルであるＳＩＰなどのＩＰネットワークにおける呼制御プロトコルを利用して、ＩＰネットワークにおける、特にキャリアなどが提供するＩＰ-ＷＡＮサービスにおいて、呼制御および呼管理を実現するネットワークが有望視されている。更に、呼制御および呼管理を実現するということは、呼毎のサービス品質管理あるいはネットワークリソース確保などのＱｏＳを実現することも可能となる。インターネットのインフラとして最も世界に普及したＩＰネットワークにおいても、コネクションオリエンテッドの時代に入りつつある。そして、その候補として既に利用されていて、普及しつつあるＭＰＬＳ(Multi-protocol  Label  Switching)がある。【０００７】
【特許文献１】特開２００１-３５８７７８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
ところで、これまでの歴史を見ても明らかなように、ＷＡＮの世界の発展とＬＡＮの世界の発展は異なるものとなる。まず基本的に、
ＷＡＮの帯域は細く、高価であり、
ＬＡＮの帯域は太く、安価である。
したがって、ＬＡＮにおいては厳密な帯域制御が必ずしも必要とは限らない。もちろんそうしたことを実現可能なシステムがより安価に手にはいるようになれば普及するかもしれない。また一方で、そうしたシステムを必須とするビジネス上のキラーアプリーションが開発されることがあれば、多少高価でも普及の可能性は十分ある。しかしそうしたことがなければＬＡＮは帯域が太く安価なものが選択されていく可能性が高い。【０００９】
一方、ＷＡＮが呼制御化されて、ＩＰネットワークでＱｏＳを提供するようになったとしても、そこへ接続されるユーザ端末は現状のままとなる可能性が高い。なぜならば、ＷＡＮに出るときは呼制御が必要でも、恐らく通信の大半を占めるＬＡＮ内の通信には既存の方式が利用されるからである。【００１０】
そこで、前述のようなゲートウエイ装置、つまり既存ＩＰ通信と呼制御ＩＰネットワークとの間を中継するための変換装置が必要となる。このゲートウエイ装置が従前のゲートウエイ装置と大きく趣を異にするのは、当該ゲートウエイ装置の適用されるべき注目点が、ＩＰネットワークとＩＰネットワークの接続点に過ぎず、セキュリティ云々の問題を除けばそのままつなげてしまっても通信することは可能なことである。従来技術としての前述のＡＴＭルータやＨ.３２３ゲートウエイなどは、これらのゲートウエイがなければ通信することは全く不可能である。つまり、これまでのゲートウエイとは厳密には異なる位置づけのゲートウエイ機能/装置が必要になるのである。【００１１】
こうした位置づけにあるもの、すなわち既存ＩＰ通信プロトコルを呼制御ＩＰネットワークに当該呼制御の正規の手順に従いながら中継することを可能にする機能および装置は従来存在していなかった。【００１２】
ちなみに現在のインターネット接続サービスに多く利用されているアクセスルータは、既存ＩＰネットワーク同士(ＬＡＮとＷＡＮ)を接続するものでもあるので上記と同じに見えるが、ＷＡＮ側のＩＰネットワークもあくまで「既存」ＩＰネットワークであり、呼制御/呼管理は行っていない。つまり、本発明でいうところのゲートウエイの機能あるいは装置は、従前のゲートウエイとアクセスルータの中間に位置づけられるものである。【００１３】
本発明は、上記に鑑みてなされたものであって、既存のＩＰ通信を呼制御ネットワークへ効率よく適用するとともに、呼制御対象としての呼制御ネットワークを確実に管理することができる通信ネットワークにおけるＩＰパケット中継方法およびゲートウエイ装置を得ることを目的とする。
【課題を解決するための手段】
【００１４】
上述した課題を解決し、目的を達成するために、本発明は、ＩＰ端末が収容される呼制御機能を前提としない複数の第１のＩＰネットワークと、前記複数の第１のＩＰネットワーク間にあって呼制御／呼管理機能を有する第２のＩＰネットワークと、前記第１のＩＰネットワークと第２のＩＰネットワークとを連結するゲートウエイ装置とを備える通信ネットワークにおけるＩＰパケット中継方法において、前記ゲートウエイ装置が、第１のＩＰネットワークが発行する通信要求パケットあるいは最初に送信されるデータパケットを捉えてこれを解析することにより前記第２のＩＰネットワーク内に所要の呼を確立して、ＩＰパケットを前記第２のＩＰネットワーク内を通過させることを特徴とする。
【発明の効果】
【００１５】
本発明は、これまでの一般に認識されてきたゲートウエイ装置とアクセスルータの中間に位置づけられるゲートウエイ装置を既存ＩＰネットワークと呼制御ネットワークの接続点に配置し、このゲートウエイ装置が、ＩＰ通信における最も一般的な転送プロトコルであるＴＣＰ、およびＵＤＰなどの通過を監視して内部に蓄え、呼制御手順によって必要な呼を確立してからパケットを転送していくようにしているので、既存のＩＰ通信を呼制御ネットワークへ適用する際、呼制御対象としての呼制御ネットワークを確実に管理できるようになる。
【図面の簡単な説明】
【００１６】
【図１】図１は、本発明における最も基本的なネットワーク構成を示す図である。
【図２】図２は、ゲートウエイ装置の内部構成例を示す図である。
【図３】図３は、ＴＣＰ通信収容シーケンス例を示す図である。
【図４】図４は、ＩＮＶＩＴＥメッセージへのＴＣＰパケットの展開例を示す図である。
【図５】図５は、ＴＣＰ通信収容シーケンスの他の例を示す図である。
【図６】図６は、ＵＤＰ通信収容シーケンス例を示す図である。
【図７】図７は、ＱｏＳを伴う既存ＩＰ通信収容のためのゲートウエイ装置の内部構成を示す図である。
【図８】図８は、ＱｏＳサーバを伴う既存ＩＰ通信を収容する呼制御ネットワーク構成を示す図である。
【図９】図９は、ＲＴＳＰにおけるデータセッションの呼制御ネットワークへの適用手順を示す図である。
【図１０】図１０は、ＡＴＭ-ＬＡＮとＷＡＮの一般的な接続構成を示す図である。
【図１１】図１１は、ＰＳＴＮとＩＰネットワークのＨ.３２３ゲートウエイによる一般的な接続構成を示す図である。
【符号の説明】
【００１７】
１１，１２  ゲートウエイ装置（ＧＷ装置）
２０  ＬＡＮポート
２１  ＷＡＮポート
２２  フィルタリング機能部
２３  ルーティング機能部
２４  ＴＣＰ／ＵＤＰ機能部
２５  アプリケーション機能部
２６  ＳＩＰ適応機能部
２７  ＱｏＳテーブル
１０１，１０２  ユーザネットワーク
２０１  コアネットワーク（呼制御ネットワーク）
３０１，３０２，３０３  コアネットワークノード
４０１  プロキシサーバ
５０１  ＱｏＳサーバ
９０１，９０２  ＩＰ端末。
【発明を実施するための最良の形態】
【００１８】
以下に、本発明にかかる通信ネットワークにおけるＩＰパケット中継方法およびゲートウエイ装置の実施の形態を図面に基づいて詳細に説明する。なお、この実施の形態によりこの発明が限定されるものではない。【００１９】
実施の形態１．
実施の形態１では、今後ＩＰネットワークにおける呼制御プロトコルとして広く適用されていく可能性の高い、ＳＩＰ(Session  Initiation  Protocol)を例にとって説明する。図１は、実施の形態１を適用する基本的なネットワーク構成を示すものである。図１のネットワーク構成においては、本発明の機能を実装したゲートウエイ装置(以下ＧＷ装置と呼ぶ）１１，１２を、ＩＰルータによって実現している。もちろん、本ＧＷ装置をレイヤ２のブリッジによって構成することも可能である。【００２０】
図１において、ユーザネットワーク１０１，１０２は、既存のＩＰネットワークであり、呼制御は伴わない。コアネットワーク２０１は、呼制御／呼管理を伴うネットワークであり、コアネットワークノード３０１，３０２，３０３を含んでいる。ＳＩＰサーバ４０１は、コアネットワーク２０１に接続されており、基本機能としてＳＩＰプロキシサーバを実装している。９０１，９０２は、ユーザネットワーク１０１上にある既存のＩＰ端末あるいはサーバであり、ｔｅｌｎｅｔ，ｆｔｐ，あるいはｔｆｔｐなどのクライアントおよびサーバとなり得る。【００２１】
図２は、ＧＷ装置１１，１２の内部機能構成例を示すものである。図２に示すＧＷ装置の場合は、２つのＬＡＮポート２０と、１つのＷＡＮポート２１と、フィルタリング機能部２２と、ルーティング機能部２３と、ＴＣＰ／ＵＤＰ機能部２４と、アプリケーション機能部２５と、ＳＩＰ適応機能部（SIP-Adaptation）２６とを有している。図１において、矢印はＳＩＰ適応機能部２６を経由するもの以外は全て双方向である。【００２２】
ＬＡＮポート２０は、ＬＡＮに接続するためのポートであり、この図の場合は、ＭＡＣ(Media  Access  Control)層はこの中に含まれている。ＷＡＮポート２１は、ＷＡＮに接続するためのポートであり、この図の場合は、ＭＡＣ(Media  Access  Control)層はこの中に含まれている。【００２３】
フィルタリング機能部２２は、当該ＧＷの特徴的な処理のためのきっかけとなるＩＰパケット（ＵＤＰの最初のパケット、あるいはＴＣＰ-ＳＹＮ，ＴＣＰ-ＳＹＮ-ＡＣＫパケットなど）を検出し、この検出に基づいてパケットを、ルーティング機能部２３およびＳＩＰ適応機能部２６のいずれかに振り分ける。【００２４】
ルーティング機能部２３は、ＩＰパケットをルーティングするための機能ブロックであり、各パケットの宛先ＩＰアドレスでルーティングテーブルを検索して、その結果に従って適切なポート、あるいはＧＷ内の上位機能ブロックへパケットを転送する。一般に、ＬＩＮＵＸなどのＯＳ(オペレーティングシステム)がその機能を果たすことになる。【００２５】
ＴＣＰ/ＵＤＰ機能部２４は、トランスポート層の機能ブロックであり、特別な機能を持ち合わせているわけではなくあくまで一般的な機能しか有していない。これも基本的にはＯＳの機能として実装される。アプリケーション機能部２５は、ネットワーク機器としての当該ＧＷ装置を遠隔管理したりするためのアプリケーション機能ブロックであり、特にこの場合はサーバ機能(telnetサーバなど)も含んでいる。【００２６】
ＳＩＰ適応機能部２６は、ＴＣＰ-ＳＹＮパケットなどを受けてＳＩＰメッセージパケットに展開し、ＳＩＰ手順を開始するなどのＳＩＰ手順と関係するＧＷ機能が実装された機能ブロックである。【００２７】
本ＧＷ装置においては、以下の（ａ）〜（ｅ）に示すパケットを次のように処理する。
（ａ）ＴＣＰ-ＳＹＮ，ＴＣＰ-ＳＹＮ-ＡＣＫパケット
（ｂ）ＵＤＰパケット
（ｃ）ＳＩＰメッセージパケット
（ｄ）ＧＷ装置宛パケット
（ｅ）その他のパケット【００２８】
上記のパケットのうち（ａ）および（ｃ）のパケットの全て、および（ｂ）一部のパケット(セッションの最初のパケット)は、フィルタリング機能部２２によってＳＩＰ適応機能部２６へ振り分けられる。また、（ｄ）および（ｅ）のパケットはフィルタリング機能部２２によってルーティング機能部２３へ転送されて、当該ＧＷ装置が持つＩＰアドレス宛のものであれば更にＴＣＰ/ＵＤＰ機能部２４、アプリケーション機能部２５へと転送される。当該ＧＷ装置宛のものでなければ、ルーティング機能部２３によって適当な宛先(ポート)へフォワードされる。なお、図１において、ＧＷ装置１１，１２以外の構成要素(ネットワークノードなど)は一般的なもので、本発明に特化された機能や構成は必要ない。【００２９】
図１に示す構成において、ＴＣＰセッションが端末９０１からの要求で開始される場合の動作について図３に従って説明する。図３は、ＴＣＰセッションを実行する場合のネットワークの各構成要素に関するメッセージシーケンスを示すものである。【００３０】
まず、ＴＣＰセッション確立要求としてのＴＣＰ-ＳＹＮパケットがＩＰ端末９０１より発行される。この場合、ＴＣＰ-ＳＹＮパケットの宛先はＴＣＰサーバとしてのＩＰ端末９０２であるとする。【００３１】
ＧＷ装置１１は、ＴＣＰ-ＳＹＮパケットをキャプチャする。ＧＷ装置１１のフィルタリング機能部２２は、入力されたパケットがＴＣＰ-ＳＹＮであるので、入力されたＴＣＰ-ＳＹＮパケットをＳＩＰ適応機能部２６に転送する。ＳＩＰ適応機能部２６は、ＴＣＰ-ＳＹＮパケットのアドレスおよびポート番号等を解析して、それに対応した呼接続要求パケットとしてのＳＩＰ  ＩＮＶＩＴＥパケットを生成し、生成したＳＩＰ  ＩＮＶＩＴＥパケット（ＩＮＶＩＴＥメッセージ）をＳＩＰプロキシサーバ４０１へ転送する。なお、ＴＣＰ-ＳＹＮパケットはＩＮＶＩＴＥメッセージの中に組み込む方式と、ＩＮＶＩＴＥメッセージを生成した後そのまま転送する方式とが可能である。実施の形態１の場合は、ＩＮＶＩＴＥメッセージ中に組み込む方式を示している。また、このＩＮＶＩＴＥメッセージの送信元はＩＰ端末９０１であり、最終的な宛先はＩＰ端末９０２である。それは、ＴＣＰ-ＳＹＮパケットが来た段階では、宛先のＧＷ装置１２のアドレスを、ＧＷ装置１１が知る手段がないからである。対称性を保つために、送信元もＩＰ端末９０１とするのが望ましい。【００３２】
図４はＴＣＰ-ＳＹＮパケットをＳＩＰ  ＩＮＶＩＴＥメッセージ内に展開する場合を例示するものである。この場合、ＳＩＰにおける各種のデータを格納できるボディ領域に、複数のエンコーディング方式によってＴＣＰパケットを埋め込んでいる。１つはＳＤＰ(Session  Description  Protocol:  IETF  RFC2327)で、もう一つがＴＣＰの生のパケットデータである。図４では、x-raw-ip-packetというＭＩＭＥフォーマットを規定して展開している。この例では、テキストで１６進数を４バイトごとに記述する方式となっている。「４５００  ００３０  ……」となっているが、これはＩＰパケットをそのまま展開していることを示している。ＴＣＰではシーケンス番号、チェックサム、その他パケットを生成する際に埋めなければならないフィールドがいくつかあるが、ＴＣＰ自体に干渉するのは目的外であるので、ＩＰパケットごとマッピングするのがもっとも簡単である。【００３３】
ＳＩＰプロキシサーバ４０１は、ＧＷ装置１１からＩＮＶＩＴＥメッセージを受信すると、このＩＮＶＩＴＥメッセージを宛先のＴＣＰサーバとしてのＩＰ端末９０２へ転送する。このとき、ＳＩＰプロキシサーバ４０１は、ＧＷ装置１１に１００Ｔｒｙｉｎｇなどの準備応答メッセージを返す。【００３４】
ＧＷ装置１２は、ＩＮＶＩＴＥメッセージを受け取ると、ＳＩＰプロキシサーバ４０１に１００Ｔｒｙｉｎｇなどの準備応答メッセージを返すとともに、ＴＣＰ-ＳＹＮパケットを再度ＩＮＶＩＴＥメッセージから抽出し、抽出したＴＣＰ-ＳＹＮパケットをＩＰ端末（ＴＣＰサーバ）９０２へ転送する。このように、ＳＩＰ手順としては、ＧＷ装置１１，１２間で閉じることになり、ＩＰ端末には見えない。なお、ＧＷ装置１２において、ＩＮＶＩＴＥメッセージを処理するのは、ＳＩＰ適応機能部２６である。ＴＣＰ-ＳＹＮパケットは、ＩＰフレームのままＩＮＶＩＴＥメッセージ内に展開されてくるので、ＳＩＰ適応機能部２６においてＴＣＰ-ＳＹＮパケットがＩＮＶＩＴＥメッセージから抽出され、抽出されたＴＣＰ-ＳＹＮパケットがＳＩＰ適応機能部２６からルーティング機能部２３へ転送され、ルーティング機能部２３でのルーティング処理によってＴＣＰ-ＳＹＮパケットは、結果的にＩＰ端末９０２へ到達する。【００３５】
ＩＰ端末９０２は、ＴＣＰ-ＳＹＮパケットを受け取ると、該当するサーバデーモンが立ち上がっていればリクエストを受け付け、その後ＴＣＰセッション確立応答パケットとしてのＴＣＰ-ＳＹＮ-ＡＣＫパケットをＩＰ端末９０１宛に返す。【００３６】
ＧＷ装置１２では、前記と同様にして、ＴＣＰ-ＳＹＮ-ＡＣＫパケットをキャプチャし、このＴＣＰ-ＳＹＮ-ＡＣＫパケットを先ほどのＩＮＶＩＴＥメッセージの受け付け応答である呼接続応答パケット（２００  ＯＫメッセージ）の内部に展開してＳＩＰプロキシサーバ４０１宛に送付する。ＳＩＰプロキシサーバ４０１では、特に問題なければ、このＩＮＶＩＴＥメッセージを含む２００  ＯＫメッセージをＧＷ装置１１へ転送する。【００３７】
ＧＷ装置１１では、２００  ＯＫメッセージを受け取ると、前述のＧＷ装置１２と同様にして、２００  ＯＫメッセージからＴＣＰ-ＳＹＮ-ＡＣＫパケットを抽出し、抽出したＴＣＰ-ＳＹＮ-ＡＣＫパケットをＩＰ端末９０１へ転送すると同時に、ＳＩＰ-ＡＣＫメッセージをＳＩＰプロキシサーバ４０１宛に送付する。この時点でＴＣＰセッションはＩＰ端末９０１，９０２間で確立され、ＳＩＰプロトコルレベルにおいてもセッションが確立されたことになる。ＳＩＰ-ＡＣＫメッセージは、ＳＩＰプロキシサーバ４０１を経由してＧＷ装置１２で受け取られる。このようにして、ＡＣＫまで含めたＳＩＰによるセッション確立手順が完了する。ただしあくまでも、ＳＩＰ手順上の送信元（Fromヘッダ）および宛先(Toヘッダ)は、それぞれＩＰ端末９０１およびＩＰ端末９０２のアドレスである。【００３８】
ＩＰ端末９０１は、ＴＣＰ-ＳＹＮ-ＡＣＫパケットを受信すると、ＴＣＰ−ＡＣＫパケットをＩＰ端末９０２に送信する。このＴＣＰ-ＡＣＫパケット、その後送信されるデータパケットはＧＷ装置では特に捉えられることもなくそのままコアネットワーク２０１内を転送される。すなわち、ＧＷ装置１１，１２では、これらのパケットは全てフィルタリング機能部２２からルーティング機能部２３へ転送され、ＧＷ装置１１，１２は、ルーティング機能部２３によるルーティング処理によって通常のルータとしての役割を果たす。このように、ＴＣＰ-ＡＣＫパケットの送信以降は、確立されたＴＣＰセッションでの通信がＩＰ端末９０１,９０２間で行われる。【００３９】
通信が完了してＴＣＰセッションを切断するとき、ＴＣＰセッション終了パケットとしてのＴＣＰ-ＦＩＮパケットがＩＰ端末９０１，９０２からそれぞれ相手ＩＰ端末に発行される。ＴＣＰ-ＦＩＮパケットを受信したＩＰ端末９０１，９０２は、ＴＣＰ−ＡＣＫメッセージを相手ＩＰ端末に返送する。この場合は、ＩＮＶＩＴＥメッセージの起点となったＧＷ装置１１がＩＰ端末９０１，９０２から送付されるＴＣＰ-ＦＩＮパケットを検出し、ＩＰ端末９０１，９０２から送付される２つのＴＣＰ-ＦＩＮパケットを検出した時点で呼切断要求パケットとしてのＢＹＥリクエストを生成してＳＩＰプロキシサーバ４０１へ送信する。ＧＷ装置１１において、ＴＣＰ-ＦＩＮパケットを検出し、ＢＹＥリクエストを発行するのは、ＳＩＰ適応機能部２６である。なお、この場合、ＴＣＰ-ＦＩＮパケットおよびＴＣＰ-ＡＣＫパケットは、呼切断要求パケットとしてのＢＹＥリクエスト内に展開することなくそのまま中継するようにしており、これにより手順の簡略化を図っている。【００４０】
ＢＹＥリクエストを受信すると、ＳＩＰプロキシサーバ４０１はこのＢＹＥリクエストをＧＷ装置１２宛に転送する。ＧＷ装置１２ではＢＹＥリクエストに対して２００  ＯＫ応答メッセージをＳＩＰプロキシサーバ４０１を経由してＧＷ装置１１へ転送する。このようにして一連のセッションに関する手順が完了する。【００４１】
この実施の形態１においては、ＴＣＰ-ＳＹＮおよびＴＣＰ-ＳＹＮ-ＡＣＫパケットをそれぞれＩＮＶＩＴＥメッセージおよび２００  ＯＫメッセージ内に展開して送信する用にしており、これによりＳＩＰでのセッション確立とＴＣＰでのセッション確立の同期が取れ、ＴＣＰのデータが流れ始めたときにはＳＩＰでのセッションが間違いなく確立されていることになる。特にこの方式はＱｏＳ設定をコアネットワーク内に伴う場合に有効となる。なぜならば、最初のデータについても確実にＱｏＳ処理を施せるからである。【００４２】
なお、ＴＣＰセッションをＴＣＰ-ＲＳＴパケットによって切断する場合は、ＴＣＰ-ＲＳＴパケットを発行したＩＰ端末側のＧＷ装置が、ＴＣＰ-ＲＳＴパケットを捉え、このＴＣＰ-ＲＳＴパケットはそのまま転送するとともに、呼切断要求パケットを生成して発行することにより、ＴＣＰセッションを中断するのと同時に第２のＩＰネットワークにおける呼接続も切断するようにすればよい。【００４３】
このように実施の形態１によれば、ＴＣＰのセッション制御パケットを呼接続要求/応答パケット内部に展開しつつＩＰ端末間を転送し、ＩＰ端末間でＴＣＰセッションを確立するのと同時に呼制御ネットワークにおける呼も確立するようにしているので、既存ＩＰ通信のＴＣＰセッションを呼制御ネットワークで中継することが可能となる。【００４４】
実施の形態２．
つぎに、図５に従ってこの発明の実施の形態２について説明する。この実施の形態２においては、ＧＷ装置１１，１２において、ＴＣＰパケットは全てそのまま転送することを基本とし、入口側のＧＷ装置１１で、ＧＷ装置１２からのＴＣＰ-ＳＹＮ-ＡＣＫパケットをキャプチャして、ＳＩＰの２００  ＯＫメッセージと同期を取ってからＴＣＰ-ＳＹＮ-ＡＣＫパケットをＩＰ端末９０１へ転送するようにしている。【００４５】
ＴＣＰセッション確立要求としてのＴＣＰ-ＳＹＮパケットがＩＰ端末９０１より発行されたとすると、ＧＷ装置１１は、このＴＣＰ-ＳＹＮパケットをキャプチャする。そして、ＧＷ装置１１は、このＴＣＰ-ＳＹＮパケットをそのまま転送する。これと共に、ＧＷ装置１２は呼接続要求パケットとしてのＳＩＰ  ＩＮＶＩＴＥパケットを生成し、生成したＳＩＰ  ＩＮＶＩＴＥパケット（ＩＮＶＩＴＥメッセージ）をＳＩＰプロキシサーバ４０１へ転送する。ＳＩＰプロキシサーバ４０１は、ＧＷ装置１１からＩＮＶＩＴＥメッセージを受信すると、このＩＮＶＩＴＥメッセージを宛先のＩＰ端末に対応するＧＷ装置１２に転送する。このとき、ＳＩＰプロキシサーバ４０１は、ＧＷ装置１１に１００Ｔｒｙｉｎｇなどの準備応答メッセージを返す。【００４６】
ＧＷ装置１２においても、ＴＣＰ-ＳＹＮパケットはキャプチャされるが、このＴＣＰ-ＳＹＮパケットはそのままＩＰ端末９０２に送信される。また、ＧＷ装置１２は、ＩＮＶＩＴＥメッセージを受信すると、ＳＩＰプロキシサーバ４０１に１００Ｔｒｙｉｎｇなどの準備応答メッセージを返す。【００４７】
ＩＰ端末９０２は、ＴＣＰ-ＳＹＮパケットを受け取ると、該当するサーバデーモンが立ち上がっていればリクエストを受け付け、その後ＴＣＰ-ＳＹＮ-ＡＣＫパケットをＩＰ端末９０１宛に返す。ＧＷ装置１２は、このＴＣＰ-ＳＹＮ-ＡＣＫパケットをキャプチャして、このＴＣＰ-ＳＹＮ-ＡＣＫパケットをそのまま転送するとともに、呼接続応答パケットである２００  ＯＫメッセージをＳＩＰプロキシサーバ４０１宛に送付する。ＳＩＰプロキシサーバ４０１では、特に問題なければ、この２００  ＯＫメッセージをＧＷ装置１１へ転送する。【００４８】
ＧＷ装置１１では、ＴＣＰ-ＳＹＮ-ＡＣＫパケットおよび２００  ＯＫメッセージを受信すると、これらをキャプチャし、これら２信号の同期を取ってからＴＣＰ-ＳＹＮ-ＡＣＫパケットをＩＰ端末９０１へ転送する。ＩＰ端末９０１は、ＴＣＰ-ＳＹＮ-ＡＣＫパケットを受信すると、ＴＣＰ−ＡＣＫパケットをＩＰ端末９０２に送信する。このように、ＴＣＰ-ＡＣＫパケットの送信以降は、確立されたＴＣＰセッションでの通信がＩＰ端末９０１,９０２間で行われる。【００４９】
このように実施の形態２においては、呼制御ネットワークにおける呼制御パケットおよびＴＣＰセッション確立パケットをそれぞれ個別に転送しながら、送信元のＧＷ装置１１が主体的にこれらの要求/応答の同期をとって、ＴＣＰセッションと呼接続が同時に確立できるようにしている。【００５０】
実施の形態３．
つぎに、図６に従ってこの発明の実施の形態３について説明する。この実施の形態３においては、ＵＤＰ通信を収容する実装例について説明する。図６は、図１に示す構成において、ＵＤＰセッションが実行される場合のネットワークの各構成要素に関するメッセージシーケンスを示すものである。【００５１】
まず、ＧＷ装置１１のフィルタリング機能部２２は、ＩＰ端末９０１から送信されたＵＤＰの最初のパケットを検出する。フィルタリング機能部２２は、この検出と同時にＵＤＰパケットを図２のルーティング機能部２３およびＳＩＰ適応機能部２６へコピーして転送する。ルーティング機能部２３へ転送されたパケットはそのままＷＡＮポート２１を介してＷＡＮ内へ転送される。ＳＩＰ適応機能部２６に転送されたパケットはＩＮＶＩＴＥメッセージを生成するためのセッション情報を抽出するために利用される。生成されたＩＮＶＩＴＥメッセージは、ＳＩＰプロキシサーバ４０１を経由してＧＷ装置１２へ送信される。【００５２】
図６において、□(四角)で示している部分は、フィルタリング機能部２２において、フィルタリングに利用するフィルタリングテーブルを仮定義していることを表している。つまり当該セッションについてＵＤＰの最初のパケットを確認したので、その後はこれと同じセッションのデータパケットはＳＩＰ適応機能部２６には転送しない。仮定義としているのは、まだセッション自体が完全にＳＩＰ手順上、言い換えると呼制御ネットワークのセッション管理上受け入れられていないからである。【００５３】
すなわち、フィルタリング機能部２２には、現在確立されているＵＤＰセッションリストが記憶されているフィルタリングテーブルを有しており、ＵＤＰパケットを受信した場合は、ＵＤＰセッションリストを参照して、ヒットしなかった場合に新しいセッションとみなしてこのＵＤＰパケットをＳＩＰ適応機能部２６に転送して呼接続要求パケットを生成して発行させるとともにそのパケットをルーティング機能部２３に転送してそのまま呼制御ネットワーク内部へ転送する。一方、受信したＵＤＰパケットがＵＤＰセッションリストでヒットした場合には、このパケットはＳＩＰ適応機能部２６には転送せずにルーティング機能部２３にのみ転送してそのまま呼制御ネットワーク内部へ転送する。【００５４】
ＳＩＰ手順は基本的にＴＣＰの場合と同様である。ただし、ＴＣＰ-ＳＹＮパケットやＴＣＰ-ＳＹＮ-ＡＣＫパケットに相当するものをＩＮＶＩＴＥメッセージに展開あるいは抽出する処理は行わない。ＧＷ装置１１とＧＷ装置１２との間で通常のＳＩＰ手順が実施されるだけである。【００５５】
すなわち、ＳＩＰプロキシサーバ４０１は、ＧＷ装置１１からＩＮＶＩＴＥメッセージを受信すると、このＩＮＶＩＴＥメッセージを宛先のＩＰ端末に対応するＧＷ装置１２に転送する。このとき、ＳＩＰプロキシサーバ４０１は、ＧＷ装置１１に１００Ｔｒｙｉｎｇを返す。ＧＷ装置１２は、ＩＮＶＩＴＥメッセージを受信すると、ＳＩＰプロキシサーバ４０１に１００Ｔｒｙｉｎｇおよび呼接続応答パケットである２００  ＯＫメッセージをＳＩＰプロキシサーバ４０１宛に送付する。ＳＩＰプロキシサーバ４０１では、特に問題なければ、この２００  ＯＫメッセージをＧＷ装置１１へ転送する。【００５６】
なお、このようなＳＩＰ手順実施中にも、ＵＤＰパケットは順次送信されてくる。これらはコアネットワーク２０１の通常のルーティングによって宛先であるＩＰ端末９０２まで転送される。【００５７】
図６において、○(楕円)で示しているのは、フィルタリング機能部２２におけるフィルタリングテーブルへの登録を仮から正式に移行することを表している。ＳＩＰ手順によって無事にこのＵＤＰセッションが呼制御ネットワークの管理上も認識されたことになる。【００５８】
その後、このＵＤＰセッションが利用されなくなると、明示的にセッションを切断する手段はないため、エイジング機能によって呼接続を切断してリソースを解放するようにしている。すなわち、所定時間の間、呼にパケットが流れないことを検出した場合、呼接続を切断してリソースを解放する。エイジングは、ＳＩＰ手順の起点となったＧＷ装置１１が行い、タイムアウトと同時にＢＹＥリクエストを発行して当該セッションを切断する。【００５９】
図６における△（三角）のタイミング、すなわちＧＷ装置１２からの２００  ＯＫメッセージを受信した時点で、フィルタリングテーブルへの登録を削除する。ＵＤＰそのものには制御パケットは伴わないため、このような手順となる。【００６０】
このように実施の形態３においては、呼制御手順によって呼制御ネットワークにコネクションを設定している段階において流れてしまうＵＤＰパケットについて、敢えてケアしないようにしている。そのことによってネットワークノード装置の実現性が極めて大きくなる。ＵＤＰ通信自体は最初のＵＤＰパケット以降、呼接続の確立に関係なく進んでいくが、それとは直接同期しない形でできるだけ早急に、すなわち新しいＵＤＰセッションの最初の段階で呼制御ネットワークにおける呼接続を確立することによって、簡単にＵＤＰ通信への適用を実現している。【００６１】
実施の形態４．
つぎに、図７，図８に従ってこの発明の実施の形態４について説明する。この実施の形態４においては、リソース確保を伴う呼接続機能を実行する場合の手順について説明する。図７は最も基本的なＱｏＳ制御を伴う場合のＧＷ装置の内部構成を示すものである。図７においては、図２に示した構成にＱｏＳテーブル２７が追加されている。ＱｏＳテーブル２７は、ＩＰ端末から発行されるＴＣＰ、ＵＤＰなどの個別のＩＰ通信セッションを特徴づけるセッション情報(プロトコル番号、ＩＰアドレス、プロトコルに対応したポート番号、TOS(Type  of  Service)値など)と、当該セッションを呼制御ネットワークに通すに当たって呼制御ネットワーク上に確保したいリソース情報としてのＱｏＳ情報(ピークレート、平均レート、バーストサイズ、遅延レベルなど)との対応を定義したものである。【００６２】
リソース確保を伴う呼接続機能を実行する場合、ＳＩＰ適応機能部２６は、ＩＮＶＩＴＥリクエストメッセージを生成する際に、一度きっかけとなったパケットのセッション情報でこのＱｏＳテーブル２７を検索して、
・ヒットした場合は、ＱｏＳテーブル２７に記載されている対応するＱｏＳ情報をＩＮＶＩＴＥメッセージ内に展開し、
・ヒットしなかった場合は、ＱｏＳ情報なしあるいはリソースを実質要求しないＱｏＳ情報としてＩＮＶＩＴＥメッセージ内に展開する。【００６３】
すなわち、ＴＣＰのＴＣＰ−ＳＹＮパケットあるいはＵＤＰの最初のパケットが受信されると、ＳＩＰ適応機能部２６は、当該パケットから抽出されるセッション情報でＱｏＳテーブル２７を検索し、ヒットした場合には、対応するリソース情報および当該パケットを含むＩＮＶＩＴＥリクエストメッセージを発行し、テーブル検索がヒットしなかった場合は、リソース確保を伴わないセッションとみなして呼接続を行うようにしており、これにより、ＱｏＳとの対応付けが困難な既存のＩＰ通信セッションにもＱｏＳを適用して一定の品質保証を伴う通信をさせることが可能となる。【００６４】
ＳＩＰの場合には、ＳＤＰにＱｏＳ情報を展開するなどの方法がある。展開可能なＱｏＳ情報としては、例えば以下のようなものがある。
１.ｂパラメータ：帯域幅を表す
２.Audio/Video  RTPプロファイル(IETF  RFC3551)
ＲＴＰプロファイルは、基本的にそこに記述されている内容と帯域幅などをほぼ固定で結びつけることができる。これもプロファイルとネットワークのリソース情報を結びつけたテーブルを用意して検索することで、対応付けが可能となる。図４に示したＩＮＶＩＴＥメッセージではｂ＝０に指定されているが、これを例えばｂ＝２０００などとすることによって、帯域を要求するＩＮＶＩＴＥメッセージとすることが可能である。また、ＳＤＰの場合は今後各種のパラメータを記述できるように拡張させていくことも可能である。【００６５】
つぎに、ＱｏＳの設定手順について述べる。図８は、ＳＩＰサーバ４０１の他にＱｏＳサーバ５０１が図１に示したネットワーク上に構成されている例を示している。ＳＩＰサーバ４０１とＱｏＳサーバ５０１との間はインターフェースが規定されていて、例えばＳＩＰ-ＣＧＩ(IETF  RFC3050)などのインターフェースが適用可能である。ＱｏＳサーバ５０１は、制御対象となる呼制御ネットワークであるコアネットワーク２０１におけるＩＰルート情報を全て把握していて、各経路上のリソースの状況を全て把握でき、更にその結果として各ノード３０１〜３０３に対してリソース確保を行うための設定変更を促す機能を有している。【００６６】
また、他のシステム形態として、ＳＩＰサーバ４０１およびＱｏＳサーバ５０１をそれぞれ複数台設け、コアネットワーク２０１内において各サーバ４０１，５０１の呼制御担当範囲を予め設定することが考えられる。この場合は、各サーバ４０１，５０１の呼制御担当のネットワークノードが指定されることになる。このような場合においても、各ＱｏＳサーバ５０１には、ＱｏＳ要求と、現在新たに利用可能なリソース情報を照らし合わせ、受入可能かどうかを判定する機能が要求される。すなわち、各ＱｏＳサーバ５０１は、要求のあったセッションが、どのルートを通り、どのノードのどのポートでのリソースを必要としているかを判定できなければならない。図８の場合は、ＱｏＳサーバ５０１はコアネットワーク２０１内に１個しかないので、この１個のＱｏＳサーバ５０１が３つのコアネットワークノード３０１〜３０３について、要求のあったセッションが、どのルートを通り、どのノードのどのポートでのリソースを必要としているかを判定できなければならない。図３に示したようなＴＣＰセッションにおいて、ＱｏＳ要求を伴う場合には、これらのネットワークのルートテーブルおよび各ノードの全てのポートのリソース情報をＱｏＳサーバ５０１が管理することになる。【００６７】
このように、ＱｏＳサーバ５０１が複数個備えられる場合は、各ＱｏＳサーバ５０１は、それぞれの呼制御担当範囲におけるリソースを伴う呼制御の受入可否の判断および実際のリソース確保を行うための設定変更を呼制御担当範囲のノードに対して要求することになる。具体的には、呼接続要求パケットとしてのＳＩＰ  ＩＮＶＩＴＥパケットを複数のＱｏＳサーバ５０１間を順次転送させる際に、各ＱｏＳサーバ５０１は、リソース確保を伴う呼接続要求の受入可否を判断し、受入が可能であれば次のＱｏＳサーバ５０１へ転送し、不可能であれば途中でエラーとして応答することにより、要求のあった呼接続の受入可否を判断していくことになる。【００６８】
つぎに、これらの情報管理をＱｏＳサーバ５０１に集中させないための２つの手法について述べる。【００６９】
ＴＣＰを収容する場合は、図６で示したように、ＴＣＰ-ＳＹＮあるいはＴＣＰ-ＳＹＮ-ＡＣＫパケットなどのＴＣＰパケットをＩＮＶＩＴＥメッセージに展開しない方式をとる。各ネットワークノード３０１〜３０３では、これらＴＣＰ-ＳＹＮあるいはＴＣＰ-ＳＹＮ-ＡＣＫパケットなどのＴＣＰパケットがコアネットワーク内を流れるときにそれらの通過を検出し、この検出に基づいて呼のルートをＱｏＳサーバ５０１で判断させるための情報（当該ノードの識別情報および前記ＴＣＰパケットが通過したポートのポート番号）と、当該ポートのリソースの空き状況に関する情報とを、前記ＴＣＰパケットが通過したことと併せてＱｏＳサーバ５０１へ通知する。ＱｏＳサーバ５０１では、各ネットワークノード３０１〜３０３から受信したノードの識別情報およびポート番号に基づいて弧のルートを把握し、さらに各ネットワークノード３０１〜３０３から受信したリソースの空き状況に関する情報に基づいて前記ルート上におけるリソースの状況を把握することができる。ＱｏＳサーバ５０１では、把握したルート上の各ノードにおけるリソースの空き状況に関する情報とＳＩＰ  ＩＮＶＩＴＥパケット内のリソース値とを比較して呼受入可否判断を行うことになる。【００７０】
ＵＤＰを収容する場合は、当該呼制御ネットワークの入口のＧＷ装置が、最初のＵＤＰパケットを検出すると、このＧＷ装置は、ＩＰヘッダおよびＵＤＰヘッダまでは同じで大きさが０あるいは専用の所定のデータパターンのパケットを生成し、該生成した独自のデータパターンのＵＤＰパケットを通常の最初のＵＤＰパケットと共に同時に転送する。コアネットワーク２０１の各ノード３０１〜３０３では、この独自のＵＤＰパケットを検出し、この検出に基づいて呼のルートをＱｏＳサーバ５０１で判断させるための情報（当該ノードの識別情報および独自のＵＤＰパケットが通過したポートのポート番号）と、当該ポートのリソースの空き状況に関する情報とを、独自のＵＤＰパケットが通過したことと併せてＱｏＳサーバ５０１へ通知する。これによって、ＱｏＳサーバ５０１では、前記と同様にして、呼のルートとルート上の各ノードにおけるリソースの空き状況を把握することができる。ＱｏＳサーバ５０１では、前記同様、ルート上の各ノードにおけるリソースの空き状況に関する情報とＳＩＰ  ＩＮＶＩＴＥパケット内のリソース値とを比較して呼受入可否判断を行う。なお、この独自のＵＤＰパケットは、出口側のＧＷ装置で廃棄する。【００７１】
次に、制御セッションを確立してその中で別のセッションを確立するためのネゴシエーションを行うプロトコルが呼制御ネットワークとしてのコアネットワーク２０１を介して既存ＩＰ端末間で実行される場合について説明する。このようなプロトコルにおいては、制御セッションをＴＣＰでまず立ち上げ、その中でセッションの情報やＱｏＳ情報などを交渉（ネゴシエーション）して、制御セッションとは別にＴＣＰあるいはＵＤＰのセッションを確立してデータ転送を行う。このようなプロトコルには、前述のＳＩＰ、ＲＴＳＰ、Ｈ.３２３、ｆｔｐがある。ただしｆｔｐの場合はデータ転送セッションもＴＣＰであるため、呼制御対象とすることは容易である。【００７２】
図９を用いてＲＴＳＰの場合について説明する。図９は、図１に示したような基本ネットワーク構成で、ＲＴＳＰのデータ転送セッションを呼制御対象として認識していくための手順を示している。【００７３】
ＩＰ端末９０１がＲＴＳＰのためのＴＣＰセッションを確立する際、ＧＷ装置１１では、通常のＴＣＰセッション適用手順を取ると共に、それがＲＴＳＰセッションであることを認識する。【００７４】
ＧＷ装置１１は、ＲＴＳＰセッション上でＲＴＳＰ制御データがやりとりされるのを全てのぞき見して、解析する。特にＤＥＳＣＲＩＢＥメッセージに対する２００  ＯＫメッセージにはメディアセッションの情報の全てが記述されているので、ここでほぼ全ての情報を集めることができる。この例ではセッション確立コマンドに相当するＳＥＴＵＰメッセージがtrackID=１，trackID=２として２回発行されており、メディアセッションが２本あることを示している。従ってこの場合は、２つのＳＥＴＵＰメッセージに同期して呼制御ネットワークにおける呼制御リクエスト、ここではＳＩＰ  ＩＮＶＩＴＥメッセージを生成するようにしている。なお、trackIDとセッションのポート番号およびＱｏＳ情報との対応は、ＤＥＳＣＲＩＢＥメッセージに対する２００  ＯＫ応答メッセージ中に全て記述されている。【００７５】
メディアセッション確立の後、ＰＬＡＹメッセージで実際にメディアデータが流れ始める。この場合、ＳＩＰでのセッション確立が完了するまでＰＬＡＹメッセージをＧＷ装置１１で保持しておくのが最も望ましい。前記の各プロトコルは、全て上記のようなやり方でデータセッションの情報を捉えることが可能である。Ｈ.３２３、また端末が直接ＳＩＰメッセージを送付してきた場合も同様の手順で対処可能である。【００７６】
このように、ＳＩＰ、ＲＴＳＰ、Ｈ.３２３、ｆｔｐなどの制御セッションを確立してその中で別のセッションを確立するためのネゴシエーションを行うプロトコルが、呼制御ネットワークを介して既存ＩＰ端末間で実施されるとき、入口側のＧＷ装置では、そのネゴシエーションパケットを捉えて中継するのと同時に、ネゴシエーションパケットの中を解析して、それらプロトコルによって今後利用されるセッション情報を抽出して、各プロトコル毎に規定されたセッション確立コマンドに相当するものが発行されるのと同時に、当該呼制御ネットワーク上にもそれらのセッションを通すための呼を確立するようにしている。【００７７】
次に、ｆｔｐの場合について説明する。ｆｔｐでは、データ転送セッションもＴＣＰであるので、呼制御開始のきっかけについては特別の考慮は必要としない。しかし、ＱｏＳ設定を伴う場合には例えば以下のような手順を適用する必要がある。【００７８】
ｆｔｐの制御セッションが立ち上がった時点で、その間のデータ転送セッションに対して適用すべきＱｏＳ情報が確定できるようにしておく。つまり、図７に示したＱｏＳテーブル２７には、ｆｔｐの制御セッション情報(送受ＩＰアドレスと宛先ポート番号“２０”)から要求されるＱｏＳ情報が検索できるようにデータ登録を行っておく。その際、パッシブモードであれば、ｆｔｐ制御上でやりとりされた内容を解析して宛先のポート番号を捉え、パッシブモードでなければ宛先ポート番号を“２０”として認識する。そして、ＧＷ装置１１が、上記条件に一致するＴＣＰ-ＳＹＮパケットを捉えたら、送受ＩＰアドレスと、宛先ポート番号“２０”で検索して得られたＱｏＳ情報をＳＩＰ  ＩＮＶＩＴＥメッセージ内に展開してＱｏＳを伴うセッション確立を実施する。【００７９】
このようにすることで、特にポート番号の確定しないｆｔｐパッシブモードでも、ｆｔｐデータセッションとして捉え、望ましいＱｏＳを伴ったセッションパスをコアネットワーク内に確保することができる。【００８０】
なお、制御セッションを確立してからのネゴシエーションによって確立されるセッションが、その記述を解析した結果、ネットワークリソース確保を要求するとき、あるいはそのセッションを流れるアプリケーションデータ量の特性が一定の規定から算出されるような場合(ＲＴＰ  Profile(:RFC3551)など)、入口のＧＷ装置では、その内容も合わせて解析し、当該セッションを確立する要求が発行された場合には、ネットワークリソース確保も同時に行いつつ、呼制御ネットワークにおける呼の確立も行うようにする。【００８１】
また、ＩＰ端末が呼接続要求パケットとしてのＳＩＰ  ＩＮＶＩＴＥパケットを直接発行する場合、ＧＷ装置では、ＳＩＰ  ＩＮＶＩＴＥパケットの要求内容自体が問題ない限りそのまま素通しすることによって、呼接続制御をＧＷ装置の外部からの要求にも対応可能とするようにしてもよい。
【産業上の利用可能性】
【００８２】
以上のように、本発明にかかる通信ネットワークにおけるＩＰパケット中継方法は、ＩＰ(インターネットプロトコル)ネットワークと、これをベースとした呼制御ネットワークと、それらを接続するためのゲートウエイ装置とを備える通信ネットワークに有用である。
【図１】
0004392029.tif 000002
【図２】
0004392029.tif 000003
【図３】
0004392029.tif 000004
【図４】
0004392029.tif 000005
【図５】
0004392029.tif 000006
【図６】
0004392029.tif 000007
【図７】
0004392029.tif 000008
【図８】
0004392029.tif 000009
【図９】
0004392029.tif 000010
【図１０】
0004392029.tif 000011
【図１１】
0004392029.tif 000012