中継通信装置および通信制御方法
【課題】
呼制御プロトコルに対応したグローバル網でエラーが発生した場合に、呼制御プロトコルに対応していない端末又はサーバにおいても、グローバル網からのエラー通知を解釈できるようにすることを目的とする。
【解決手段】
呼制御プロトコルに対応するグローバル網と、呼制御プロトコルに対応していない端末またはサーバを含むプライベート網とを連結する中継通信装置であって、端末またはサーバから通信要求を受け、グローバル網内に呼を確立するセッション制御部５０３と、グローバル網から呼制御プロトコルによるエラー通知を受け取った場合、端末またはサーバが解釈可能な通信プロトコルのエラー通知に変換し、端末又はサーバに送信するエラー応答部５０６と、を備える。
呼制御プロトコルに対応したグローバル網でエラーが発生した場合に、呼制御プロトコルに対応していない端末又はサーバにおいても、グローバル網からのエラー通知を解釈できるようにすることを目的とする。
【解決手段】
呼制御プロトコルに対応するグローバル網と、呼制御プロトコルに対応していない端末またはサーバを含むプライベート網とを連結する中継通信装置であって、端末またはサーバから通信要求を受け、グローバル網内に呼を確立するセッション制御部５０３と、グローバル網から呼制御プロトコルによるエラー通知を受け取った場合、端末またはサーバが解釈可能な通信プロトコルのエラー通知に変換し、端末又はサーバに送信するエラー応答部５０６と、を備える。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、異なるネットワーク間を連結する中継通信装置、および、その中継通信装置を用いた通信制御方法に関する。
【背景技術】
【０００２】
一般に、端末が所属するプライベート網では、高速かつ安価な通信が可能であるが、プライベート網間を接続するグローバル網における通信は、低速かつ高価なものとなる。そのため、グローバル網においては、呼制御プロトコルなどのさまざまなシステムを用いて高速化を図っている。一方、プライベート網では、厳密な帯域制御を必ずしも必要としないため、呼制御プロトコルに対応していない通信方式が採用される場合がある。したがって、プライベート網とグローバル網において、異なる通信方式が採用されることが多く、異なる通信方式間を中継するための変換装置が必要となる。そこで、従来の通信装置では、呼制御未対応の端末からの通信、例えばＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）／ＵＤＰ（Ｕｓｅｒ Ｄａｔａ Ｐｒｏｔｏｃｏｌ）による接続要求がゲートウェイ装置に届くと、ゲートウェイ装置がその通信が呼制御を行うべきものであるかの判断をし、呼制御を行うべき通信であると判断した場合、端末からその通信に適した呼制御セッションを張り、呼制御で確立したサービス（帯域や優先度）を付加することにより、呼制御プロトコルに未対応な端末であっても呼制御ネットワークへ適用可能としている。（例えば、特許文献１参照）
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】国際公開第２００６／０５１５９４号パンフレット（図１、第８頁〜第１１頁）
【発明の概要】
【発明が解決しようとする課題】
【０００４】
従来の通信装置を用いて端末側からグローバル網への通信が行われた場合、通常であればそのまま帯域の確保や優先度制御が呼制御プロトコルにより実施されるが、グローバル網のエラーにより、帯域の確保、優先度制御が実施されずにエラーがゲートウェイ装置などの中継通信装置に返ってきた場合、中継通信装置ではそのエラーを解釈することができるが、呼制御プロトコルに未対応の端末では、エラーを解釈することができない。そのため、グローバル網において未だエラーが生じているにもかかわらず、再送タイマによる再送が何度も繰り返され、無用な通信の再要求が生じることとなり、ネットワーク上のトラフィックの混雑を引き起こす恐れがある。
【０００５】
この発明は上記のような問題点を解決するためになされたものであり、呼制御プロトコルに対応したグローバル網でエラーが発生した場合に、呼制御プロトコルに対応していない端末又はサーバにおいても、グローバル網からのエラー通知を解釈できるようにすることを目的とする。
【課題を解決するための手段】
【０００６】
この発明に係る中継通信装置は、呼制御プロトコルに対応するグローバル網と、呼制御プロトコルに対応していない端末またはサーバを含むプライベート網とを連結する中継通信装置であって、端末またはサーバから通信要求を受け、グローバル網内に呼を確立するセッション制御部と、グローバル網から呼制御プロトコルによるエラー通知を受け取った場合、端末またはサーバが解釈可能な通信プロトコルのエラー通知に変換し、端末又はサーバに送信するエラー応答部と、を備えるものである。
【０００７】
また、この発明に係る中継通信装置は、呼制御プロトコルに対応するグローバル網と、呼制御プロトコルに対応していない端末またはサーバを含むプライベート網と、を連結する中継通信装置であって、端末またはサーバから通信要求信号を受け、グローバル網側への呼を確立して通信を行うセッション制御部と、グローバル網から呼制御プロトコルによるエラー通知を受け取った場合、端末又はサーバとのリンクをダウンさせるエラー応答部とを備えるものである。
【０００８】
また、この発明に係る通信制御方法は、中継通信装置が呼制御プロトコルに対応していない端末またはサーバから通信要求を受け、呼制御プロトコルに対応するグローバル網内に呼を確立するセッション制御ステップと、中継通信装置がグローバル網からの呼制御プロトコルによるエラー通知を受け取った場合、端末またはサーバが解釈可能な通信プロトコルのエラー通知を生成し、端末またはサーバへ送信するエラー応答ステップと、を備えることを特徴とするものである。
【発明の効果】
【０００９】
この発明によれば、グローバル網においてエラーが生じた場合でも、呼制御プロトコルに未対応の端末またはサーバにおいて、グローバル網からのエラー通知を解釈することができる。
【図面の簡単な説明】
【００１０】
【図１】本発明の実施の形態１に係るゲートウェイ装置を用いたネットワークの基本構成図である。
【図２】本発明の実施の形態１に係るゲートウェイ装置の構成図である。
【図３】本発明の実施の形態１に示す申請成功時のシーケンス図である。
【図４】本発明の実施の形態１に示す従来のゲートウェイ装置を用いた場合におけるエラー発生時のシーケンス図である。
【図５】本発明の実施の形態１に示す従来のゲートウェイ装置の構成図である。
【図６】本発明の実施の形態１に示すクライアント端末に行うエラー通知の例を示すシーケンス図である。
【図７】本発明の実施の形態１に示すクライアント端末に行うエラー通知の例を示すシーケンス図である。
【図８】従来のゲートウェイ装置を用いた場合におけるエラー発生時のシーケンス図である。
【図９】本発明の実施の形態２に示すサーバに行うエラー通知の例を示すシーケンス図である。
【図１０】本発明の実施の形態３に係るゲートウェイ装置の構成図である。
【図１１】本発明の実施の形態３に係るゲートウェイ装置の動作を表すフローチャートである。
【図１２】本発明の実施の形態３に示すクライアント端末に行うエラー通知の例を示すシーケンス図である。
【図１３】本発明の実施の形態３に示すクライアント端末に行うエラー通知の例を示すシーケンス図である。
【図１４】本発明の実施の形態３に示すクライアント端末に行うエラー通知の例を示すシーケンス図である。
【図１５】本発明の実施の形態３に示すエラー通知に記述する再送可能時間の計算例を示すシーケンス図である。
【図１６】本発明の実施の形態４に係るゲートウェイ装置の動作を表すフローチャートである。
【図１７】本発明の実施の形態４に示すサーバに行うエラー通知の例を示すシーケンス図である。
【図１８】本発明の実施の形態４に示すサーバに行うエラー通知の例を示すシーケンス図である。
【図１９】本発明の実施の形態４に示すサーバに行うエラー通知の例を示すシーケンス図である。
【図２０】本発明の実施の形態４に示すサーバに行うエラー通知の例を示すシーケンス図である。
【図２１】本発明の実施の形態４に示すサーバに行うエラー通知の例を示すシーケンス図である。
【図２２】本発明の実施の形態４に示すエラー通知に記述する再送可能時間の計算例を示すシーケンス図である。
【図２３】本発明の実施の形態５に示すリンクダウンによりクライアント端末に再送を停止させる場合のシーケンス図である。
【図２４】本発明の実施の形態６に示す無線通信を用いた場合におけるエラー通知の例を示すシーケンス図である。
【発明を実施するための形態】
【００１１】
実施の形態１．
図１に、本発明の実施の形態１に係る中継通信装置を用いたＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）ネットワークの基本構成図を示す。図１において、プライベート網１０、２０、３０がそれぞれグローバル網４０により接続されており、また、それぞれのプライベート網とグローバル網との間にはゲートウェイ装置５０、５１、５２が設置されている。また、プライベート網１０にはクライアント端末１１、１２、プライベート網２０にはサーバ２１、プライベート網３０にはサーバ３１がそれぞれ配置されている。ここで、クライアント端末１１およびサーバ３１は呼制御プロトコルであるＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）に対応していない。グローバル網４０には、ＳＩＰを経由するサーバとしてＳＩＰサーバ４１が設けられている。
【００１２】
図２に、本発明の実施の形態１に係るゲートウェイ装置の構成図を示す。図２において、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）インタフェース５０１はプライベート網であるＬＡＮに接続するためのインタフェースであり、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）インタフェース５０２はグローバル網であるＷＡＮに接続するためのインタフェースである。セッション制御部５０３はＮＧＮ（Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ Ｎｅｔｗｏｒｋ）等により構成されるグローバル網４０に対して、帯域申請等を行い、呼接続の確立を行う。通信プロトコル解析部５０４は、端末やサーバからの通信に用いられるプロトコルの解析を行う。エラー解析部５０５はグローバル網４０からのエラー通知の解析を行う。エラー応答部５０６はプライベート網側のクライアント端末やサーバへのエラー通知を行う。
【００１３】
次に、ゲートウェイ装置の動作についてシーケンス図を用いて説明する。図３に、グローバル網においてエラーが発生せず、通常の通信が行われる場合のシーケンス図を示す。ゲートウェイ装置５０は、クライアント端末１１から送信された通信要求としてのＴＣＰ ＳＹＮパケットを受信した場合、通信プロトコル解析部５０４により、送信元のＩＰアドレス、ポート番号、宛先のＩＰアドレス、ポート番号等を確認し、セッション制御部５０３により、アプリケーションに合わせた帯域の申請、優先度制御の申請をＳＩＰによる呼接続要求パケットとしてのＩＮＶＩＴＥパケットをグローバル網に対し送信する。グローバル網４０に設けられたＳＩＰサーバ４１は、ゲートウェイ装置５０からＩＮＶＩＴＥパケットを受信すると、このＩＮＶＩＴＥパケットを宛先のゲートウェイ装置５１へ転送する。このとき、ＳＩＰサーバ４１は、ゲートウェイ装置５０に準備応答メッセージ１００ Ｔｒｙｉｎｇメッセージを返す。ＳＩＰサーバ４０から転送されたＩＮＶＩＴＥパケットを受信したゲートウェイ装置５１は、ＩＮＶＩＴＥパケットを受信したことを示す１００ ＴｒｙｉｎｇおよびＩＮＶＩＴＥパケットの受付応答である２００ ＯＫをＳＩＰサーバ４１に送付する。ＳＩＰによる申請が終了したら、ゲートウェイ装置５０で待機させていたＴＣＰ ＳＹＮパケットをＳＩＰで確保された帯域、優先度制御を活用して相手先のサーバ２１まで転送し、ＴＣＰ ＳＹＮを受け取ったサーバ２１はＳＹＮ／ＡＣＫを返す。ＳＹＮ／ＡＣＫを受け取ったクライアント端末１１は、ＡＣＫを返し、ＴＣＰセッションがクライアント端末１１、サーバ２１間で確立される。一度ＳＩＰのセッションにより申請が完了すれば、通常の通信と同様の動作となり、クライアント端末１１はＨＴＴＰ ＧＥＴなどの通信を開始する。
【００１４】
次に、グローバル網において、エラーが発生した場合のゲートウェイ装置の動作について示す。ここで、グローバル網におけるエラーとは何らかの理由により、プライベート網から送信された信号が宛先のゲートウェイ装置に到達しない場合をいい、例えば、グローバル網の故障や、通信フローが一時的に増加し、セッションの同時申請が制限され、プライベート網からグローバル網への通信要求が拒否されるような場合をいう。
【００１５】
図４は、従来のゲートウェイ装置を用いた場合のシーケンス図である。また、図５に従来のゲートウェイ装置の構成を示す。図５において、図２と同一の符号は同一または同様の部分を示している。クライアント端末１１からＴＣＰの通信要求としてのＴＣＰ ＳＹＮパケットがゲートウェイ装置５０に到着し、ゲートウェイ装置５０は通信プロトコル解析部５０４により通信要求を解析する。解析結果に基づいて、セッション制御部５０３によりグローバル網４０に対してＳＩＰによる呼接続要求としてのＩＮＶＩＴＥパケットを送信し、帯域、優先制御の申請を行う。しかし、グローバル網４０においてエラーが発生したため申請が失敗し、ゲートウェイ装置５０にＳＩＰのエラー通知である４ｘｘ リクエストエラーが返っている。ゲートウェイ装置では、ＳＩＰのエラー通知を解釈することができるが、クライアント端末はＳＩＰに対応していないためこのエラー通知を解釈することができない。そのため、クライアント端末に対してエラー通知は行われず、再送タイマによる通信要求の再送が何度も行われており、無用な通信要求が発生している。
【００１６】
図６は、本発明の実施の形態１に係るゲートウェイ装置を用いた場合における、グローバル網のエラー発生時のシーケンス図である。図４に示す従来のゲートウェイ装置を用いた場合と同様に、ゲートウェイ装置５０から送信されたＳＩＰによる申請に対し、グローバル網４０からＳＩＰのエラー通知が返ってきている。実施の形態１に係るゲートウェイ装置では、エラー解析部５０５により、受け取ったＳＩＰのエラー通知を読み取ってその内容、例えば、エラー通知に含まれる応答コードやＲｅｔｒｙ Ａｆｔｅｒ等のメッセージを読み取り、グローバル網におけるエラーの発生をエラー応答部５０６に通知する。通知を受けたエラー応答部５０６では、グローバル網から受け取ったＳＩＰのエラー通知をＴＣＰ ＲＳＴに変換し、クライアント端末１１にエラー通知として送信する。ＴＣＰ ＲＳＴはＳＩＰに対応していないクライアント端末でも解釈できるため、ＴＣＰ ＲＳＴを受け取ったクライアント端末１１は通信を停止させ、再送を発生させないようにしている。
【００１７】
実施の形態１に係るゲートウェイ装置では、以上のような構成をしているため、通信の要求を行うクライアント端末が呼制御プロトコルに対応していない場合であっても、グローバル網側のエラー通知を認識することができるようになり、無用な通信の再要求が発生しないという効果が得られる。
【００１８】
ここでは、ゲートウェイ装置４０がクライアント端末１１に対し、ＴＣＰ ＲＳＴを返すようにした場合について示したが、図７に示すように、ＩＰによるエラーメッセージであるＩＣＭＰ（Ｉｎｔｅｒｎｅｔ Ｃｏｎｔｒｏｌ Ｍｅｓｓａｇｅ Ｐｒｏｔｏｃｏｌ） Ｎｅｔｗｗｏｒｋ Ｕｎｒｅａｃｈａｂｌｅを返答し、クライアント端末１１からの通信を停止させ、通信要求の再送を発生させないようにすることもできる。
【００１９】
また、中継通信装置としてゲートウェイ装置を用いた場合について示したが、ゲートウェイ装置のほか、ＩＰパケットを中継できる装置（例えばルータ等）であっても同様の効果が得られる。さらに、呼制御プロトコルとしてＳＩＰを用いた場合について示したが、Ｈ．３２３、ＭＧＣＰ等のプロトコルを用いてもよい。また、クライアント端末に対し通信要求の再送を停止させるためのエラー通知を行う場合について示したが、クライアント端末が複数のネットワークに接続されている場合には、異なるネットワーク（例えば無線通信網）などによる通信に変更させるエラー通知としてもよい。
【００２０】
実施の形態２．
実施の形態１では、クライアント端末から通信要求が送信された場合について示したが、実施の形態２ではサーバ側から通信要求が送信された場合について示す。本発明の実施の形態２に係るゲートウェイ装置を用いたＩＰネットワークの基本構成図は、実施の形態１と同様であり、図１に示すとおりである。また、本発明の実施の形態２に係るゲートウェイ装置の構成は、実施の形態１に係るゲートウェイ装置と同様であり、図２に示す通りである。
【００２１】
図８に、従来のゲートウェイ装置を用いた場合のシーケンス図を示す。サーバ３１から、クライアント端末１２に対して、動画などで利用されるＲＴＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）パケットが送信され、ゲートウェイ装置５２に到達すると、ゲートウェイ装置５２は実施の形態１の場合と同様に送信元、宛先のＩＰアドレスとポート番号を解析し、グローバル網４０にＳＩＰの呼接続要求としてのＩＮＶＩＴＥパケットを送信する。しかし、グローバル網でエラーがあり、ゲートウェイ装置にＳＩＰのエラー通知４ｘｘ リクエストエラーが返されている。ゲートウェイ装置５２では、ＳＩＰのエラー通知を解釈することができるが、サーバ３１はＳＩＰに対応していないため、このエラー通知を解釈することができない。そのため、サーバ３１に対してエラー通知が行われず、サーバからは常にＲＴＰパケットが送信され続けている。
【００２２】
図９は、本発明の実施の形態２に係るゲートウェイ装置を用いた場合における、グローバル網のエラー発生時のシーケンス図である。図８に示す場合と同様に、通信要求および呼接続要求が送信され、グローバル網のエラーにより、エラー通知４ｘｘ リクエストエラーが返されている。エラー通知を受信したゲートウェイ装置５２は、エラー解析部５０５により受信したエラー通知を解析し、解析結果に基づいてエラー応答部５０６によりサーバ３１に対してＩＰによるエラー通知であるＮｅｔｗｗｏｒｋ Ｕｎｒｅａｃｈａｂｌｅを返す。このエラー通知はＳＩＰに未対応のサーバ３１でも解釈可能なエラー通知であり、エラー通知を受け取ったサーバ３１は、サーバからの通信を停止させている。
【００２３】
実施の形態２に係るゲートウェイ装置では、以上のような構成をしているため、通信の要求を行うサーバが呼制御プロトコルに対応していない場合であっても、グローバル網側のエラーを認識することができるようになり、通常の通信と同様のエラー時の判断をすることができる。従って、無用な通信の再要求を実施しないという効果が得られる。
【００２４】
ここでは、中継通信装置としてゲートウェイ装置を用いた場合について示したが、ゲートウェイ装置のほか、ＩＰパケットを中継できる装置（例えばルータ等）であっても同様の効果が得られる。また、呼制御プロトコルとしてＳＩＰを用いた場合について示したが、Ｈ．３２３、ＭＧＣＰ等のプロトコルを用いてもよい。さらに、サーバに対し通信要求の再送を停止させるためのエラー通知を行う場合について示したが、サーバが複数のネットワークに接続されている場合には、異なるネットワーク（例えば無線通信網）などによる通信に変更させるエラー通知としてもよい。
【００２５】
実施の形態３．
実施の形態１では、ゲートウェイ装置がエラー通知を受け取った場合、クライアント端末の通信方式に関わらず同じエラー通知を返す方式について示したが、実施の形態３では、クライアント端末の通信方式に応じてエラー通知の種類を変更させる方式について示す。本発明の実施の形態３に係るゲートウェイ装置を用いたＩＰネットワークの基本構成図は、実施の形態１と同様であり、図１に示すとおりである。
【００２６】
実施の形態３に係るゲートウェイ装置の構成を図１０に示す。図１０において、タイマ計算部５０７は、エラー応答により通信を停止させた後、通信要求の再送可能時間の計算を行う。なお、図２と同一の符号については同一または同様の部分を示す。
【００２７】
図１１は、本発明の実施の形態３に係るゲートウェイ装置の動作を示すフローチャートである。クライアント端末１１によりＴＣＰによる通信要求が発生し（ステップＳ１）、プライベート網とグローバル網との間に存在する中継通信装置であるゲートウェイ装置５０において、この通信要求を受信する（ステップＳ２）。通信要求を受信したゲートウェイ装置５０は、通信プロトコル解析部５０４により、この通信要求の内容を解釈するとともに、この通信要求をトリガとして、セッション制御部５０３によりグローバル網４０に対してＳＩＰによる帯域申請、優先度申請等を行う（ステップＳ３）。ステップＳ４では、セッション制御部５０３によりＳＩＰによる申請が成功したかの判定を行い、ＳＩＰによる申請が成功した場合には、ステップＳ５へと進む。ステップＳ５では、図３に示す場合と同様に通信要求をグローバル網側に転送し、申請したサービスを適用した状態での通常通りの通信を開始する。
【００２８】
一方、グローバル網においてエラーが発生した場合、ＳＩＰによる申請が失敗し、グローバル網側よりエラー通知が返されると、ゲートウェイ装置５０はクライアント端末１１に通信要求に対する暫定応答を返す（ステップＳ６）。暫定応答を受けたクライアント端末１１は、その後ＨＴＴＰなどのアプリケーションの通信を開始する（ステップＳ７）。ゲートウェイ装置ではこのアプリケーションの通信を受信し（ステップＳ８）、プロトコル解析部５０４により受け取った通信の種別の解析を行う（ステップＳ９）。解析の結果に基づいて、エラー応答部５０６によりそれぞれの通信方式に合わせて応答の種別を変更し、通信要求を行ったクライアント端末１１にエラー通知を返す。これにより、クライアント端末からの通信方式に応じた通知することができ、再送可能時間などの詳細なエラー通知を行うことが可能となる。ここでは、エラー通知を行う際に応答時間についてグローバル網より通知が来ている場合には、エラー通知にその時間も追加して応答する（ステップＳ１０〜Ｓ１３）。
【００２９】
図１２は、クライアント端末１１からサーバ２１に対し、通信方式としてＨＴＴＰを利用してアクセスを行った場合のシーケンス図である。クライアント端末１１から通信要求としてのＴＣＰ ＳＹＮパケットがゲートウェイ装置５０に到着すると、それを受けてゲートウェイ装置５０はグローバル網４０に対してＳＩＰの呼接続要求としてのＩＮＶＩＴＥパケットを送信し、帯域等の申請を行う。グローバル網４０において何らかのエラーが発生し、グローバル網４０からＳＩＰのエラー通知４ｘｘ リクエストエラーが返されると、ゲートウェイ装置５０は、エラー解析部５０５によりエラー通知の内容、例えば、エラー通知に含まれる応答コードやＲｅｔｒｙ Ａｆｔｅｒ等のメッセージを読み取り、読み取った内容をエラー応答部５０６に通知する。通知を受け取ったエラー応答部５０６は、クライアント端末１１に対して、暫定応答としてＴＣＰ ＳＹＮ／ＡＣＫを返す。暫定応答を受信したクライアント端末１１は、ＨＴＴＰ ＧＥＴなどのＨＴＴＰによる通信を開始し、ゲートウェイ装置５０がこの通信を受信する。ゲートウェイ装置５０は、通信プロトコル解析部５０４により、クライアント端末１１からの通信の通信方式を解析し、解析した通信方式をエラー応答部５０７に通知する。通信方式がＨＴＴＰである場合には、クライアント端末１１からのＨＴＴＰによる通信をグローバル網４０へとは通さず、その応答として、エラー応答部５０７により、ＳＩＰのエラー通知をＨＴＴＰによるエラー通知（５０３ Ｓｅｒｖｉｃｅ Ｕｎａｖａｉｌａｂｌｅ）に変換し、クライアント端末１１に返す。
【００３０】
ここで、エラー解析部５０５は、グローバル網４０からのエラー通知にＳＩＰの受付時間の記載がある場合にはその時間をエラー応答部５０６に通知する。エラー応答部５０６では、ＨＴＴＰによるエラー通知にその時間を記述し、クライアント端末１１にエラー通知を返す。一方、ＳＩＰの受付時間の記載がない場合にはタイマ計算部５０７にグローバル網４０からのエラー通知の内容を通知し、タイマ計算部５０７ではグローバル網４０からのエラー通知の内容に基づいて計算した再接続要求可能な時間をエラー通知に記述し、クライアント端末１１にエラー通知を返す（ステップＳ１０ｂ〜Ｓ１３ｂ）。ここでは、５０３ Ｓｅｒｖｉｃｅ Ｕｎａｖａｉｌａｂｌｅのメッセージに再接続要求の時間を設定するＲｅｔｒｙ−Ａｆｔｅｒを記述することにより、再接続要求可能な時間が設定されたエラー通知を行うことができる。また、エラー通知の内容とはＳＩＰの応答コードであり、例えば４００ Ｂａｄ Ｒｅｑｕｅｓｔのように定められているものである。エラー通知の内容に応じて、再接続までの時間を設定することもできる。これにより、グローバル網において生じたエラーの内容に応じた再接続要求時間をクライアント端末に通知することができ、効率的な通信を行うことができる。
【００３１】
クライアント端末１１はこのＨＴＴＰのエラー通知を解釈することができ、ＦＩＮパケットを送信しゲートウェイ装置５０との通信の切断を行う。そして、Ｒｅｔｒｙ−Ａｆｔｅｒに記述されている時間後に再接続を試みる。図１２においては、ＨＴＴＰによるエラー通知にＲｅｔｒｙ−Ａｆｔｅｒ ３０を設定し、エラー通知を受け取ったクライアント端末１１はエラー通知を受信後３０秒後に、通信要求を再送する。通信要求の再送時には、グローバル網におけるエラーは解消されており、実施の形態１の図３に示す場合と同様にＴＣＰセッションが確立されＨＴＴＰによる通信を行うことができる。
【００３２】
図１２では、ゲートウェイ装置４０からの５０３ Ｓｅｒｖｉｃｅ ＵｎａｖａｉｌａｂｌｅのＲｅｔｒｙ−Ａｆｔｅｒに再接続を行うまでの時間を記述した場合について示したが、図１３に示すように、ＧＭＴ（Ｇｒｅｅｎｗｉｃｈ Ｍｅａｎ Ｔｉｍｅ）時間を記述してもよい。ＧＭＴ時間を記述することにより、クライアント端末はその時間に再接続を試みる。
【００３３】
次に、通信方式としてＦＴＰ（Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）を利用した場合について示す。クライアント端末１１からサーバ２１に対し、通信方式としてＦＴＰを利用してアクセスを行った場合のシーケンス図を図１４に示す。図１４において、クライアント端末１１からＦＴＰによる通信要求が発生すると、図１２に示すＨＴＴＰによる通信の場合と同様に、ゲートウェイ装置５０はグローバル網４０に対してＳＩＰの呼接続要求としてＩＮＶＩＴＥパケットを送信し、帯域および優先度制御等の申請を行う。グローバル網４０よりエラー通知があると、ゲートウェイ装置５０より、ＴＣＰによる暫定応答としてＴＣＰ ＳＹＮ／ＡＣＫをクライアント端末に返す。ゲートウェイ端末５０から暫定応答を受け取ったクライアント端末１１はＦＴＰによる通信を行う。ゲートウェイ装置５０は、通信プロトコル解析部５０４において、クライアント端末１１からの通信を解析する（ステップＳ９）。クライアント端末１１からの通信が、ＦＴＰによるものであると認識した場合には、ＦＴＰによる通信に対してＲｅｓｐｏｎｓｅコード１２０をクライアント端末１１に返す（ステップＳ１３ａ）。ここで、グローバル網からのエラー通知にＳＩＰの受付時間の記載がある場合にはその時間を、ない場合にはタイマ計算部５０７により計算を行った再送可能時間をＲｅｓｐｏｎｓｅコード１２０に指定し（ステップＳ１１ａ、Ｓ１２ａ）、クライアント端末１１に対して何分後にサーバが準備できるかを通知することで、同時にクライアント端末からの要求を停止させることが可能となる。図１４においては、Ｓｅｒｖｉｃｅ ｒｅａｄｙ ｉｎ ５ ｍｉｎｕｔｅｓを設定し、Ｒｅｓｐｏｎｓｅコード１２０の受信から５分後に、通信要求を再送させている。通信要求の再送時にはグローバル網４０におけるエラーは解消されており、実施の形態１の図３に示す場合と同様にＴＣＰセッションを確立させ、ＦＴＰによる通信を行う。
【００３４】
また、ＦＴＰおよびＨＴＴＰ以外の通信方式による通信を受けた場合、実施の形態１で示した場合と同様に、ＳＩＰに対応していない端末においても解釈可能なＴＣＰ ＲＳＴを返す構成としている（ステップＳ１３ｃ）。
【００３５】
図１５は、タイマ計算部５０７における、再接続までの時間（Ｒｅｔｒｙ−Ａｆｔｅｒ）の計算方法の例である。ＳＩＰを用いたシステムでは、通信が終了してからＳＩＰによる接続を切断するまでの時間は、即時ではなく、一定時間待ってから終了させる場合がある。ここで、グローバル網側の制限として、一定数までのＳＩＰによる申請までしか受け付けていない状態を前提とする。クライアント端末１１からＴＣＰ ＦＩＮパケットを送信し、ゲートウェイ装置５０およびクライアント端末１１からそれぞれ応答メッセージであるＴＣＰ ＦＩＮ／ＡＣＫおよびＡＣＫパケットが返されることにより、既存の通信が終了する。そして、一定時間経過後にゲートウェイ装置５０によりＢＹＥが送信され、ＳＩＰサーバ４１により宛先のゲートウェイ装置５２に転送される。ゲートウェイ装置５２およびＳＩＰサーバ４１により２００ ＯＫが返されることにより、ＳＩＰによる接続が切断される。その間に、他の新しい通信が発生した場合、グローバル網４０により新しい通信は拒否され、エラー通知が返される。エラー通知を受け取ったゲートウェイ装置５０は、Ｒｅｔｒｙ−Ａｆｔｅｒ等でクライアント端末１１に対して、既存の通信のＳＩＰによる申請が切断されるまでの時間を計算し、それを通知する。図１５における再送までの時間は、予め設定されている通信の終了を表すＦＩＮパケットの送信から実際にＳＩＰの申請を切断するＢＹＥまでの設定時間（図１５中でＹ）と、それまでに実際に行われた通信におけるＦＩＮパケットの送信から、ゲートウェイ装置がクライアント端末に対してエラー通知を返すまでの経過時間（図１５中でＸ）から計算しており、通信要求の再送までの時間（図１５中でＺ）はＺ＝Ｙ−Ｘで求められる。求めた時間Ｚをクライアント端末１１に通知することにより、その時間後に通信要求の再送を行わせることができる。なお、多少の処理差を考慮し、Ｒｅｔｒｙ−Ａｆｔｅｒで通知する時間を数秒ずらすことも可能である。
【００３６】
なお、クライアント端末のユーザがブラウザ（ＨＴＴＰ）を利用した通信を行い、グローバル網よりエラーが返された場合、自動的に再接続をさせる方法とは別に、ブラウザに現在の状況（エラーの状態や何秒後に復帰するというＲｅｔｒｙ−Ａｆｔｅｒの情報など）を表示させ、ユーザ自身に再接続させる方法をとってもよい。
【００３７】
本発明の実施の形態３に係るゲートウェイ装置では、以上のような構成をしているため、呼制御プロトコルに対応していないクライアント端末に対しても、その通信方式に応じたエラー通知を行うことができ、また、通信要求の再送可能時間を通知することができる。これにより、無用な通信の再要求を実施させず、効率的な通信が可能となる。
【００３８】
ここでは、中継通信装置としてゲートウェイ装置を用いた場合について示したが、ゲートウェイ装置のほか、ＩＰパケットを中継できる装置（例えばルータ等）であっても同様の効果が得られる。また、呼制御プロトコルとしてＳＩＰを用いた場合について示したが、Ｈ．３２３、ＭＧＣＰ等のプロトコルを用いてもよい。
【００３９】
また、ここでは、エラー通知を受け取ったゲートウェイ装置から暫定応答をクライアント端末に返す方式について示したが、通信方式をクライアント端末からの通信要求から読み取り、エラー通知を返す方法、すなわち、図１１に示すフローチャートのうちステップＳ６〜ステップＳ８を省略することもできる。これにより、クライアント端末からの通信の詳細な内容は解析できないものの、クライアント端末からの通信を減少させることができる。
【００４０】
実施の形態４．
実施の形態３では、クライアント端末からの通信要求を送信した場合について示したが、実施の形態４では、サーバから通信要求が発生する場合について示す。本発明の実施の形態３に係る中継通信装置を用いたＩＰネットワークの基本構成図は、実施の形態１と同様であり、図１に示すとおりである。また、ゲートウェイ装置の構成は、実施の形態３と同様であり、図１０に示すとおりである。
【００４１】
図１６は、サーバ３１からクライアント端末１２に対してＵＤＰによる通信が発生した場合のフローチャートである。プライベート網３０に収容されているサーバ３１よりＵＤＰによる新規の通信要求が発生する（ステップＳ１）と、プライベート網３０とグローバル網４０の間に存在するゲートウェイ装置５２において、この通信を受信する（ステップＳ２）。この新規の通信を受信したゲートウェイ装置は通信の内容（宛先ＩＰアドレス、宛先ポート番号、送信元ＩＰアドレス、送信元ポート番号等）を解釈すると共に、グローバル網４０に対してＳＩＰによる帯域申請、優先度申請などを行う（ステップＳ３）。ステップＳ４において、ＳＩＰによる申請が成功したかの判定を行い、ＳＩＰによる申請が成功した場合には、ステップＳ５に進み、新規の通信を申請したサービスを適用した状態での通信を通常通り行う。
【００４２】
一方、ＳＩＰによる申請が失敗し、グローバル網側よりエラーが返されると、ゲートウェイはサーバにＲＴＳＰ（Ｒｅａｌ Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）メッセージ／ＲＴＣＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）応答等を返す。その際に、ＳＩＰの受付時間についてグローバル網４０より通知されている場合には、メッセージにその時間を追加し、通知されていない場合には再送応答時間を計算し、メッセージに計算した時間を追加して応答する（ステップＳ１０ｄ〜Ｓ１３ｄ）。
【００４３】
図１７に、サーバ３１よりクライアント端末１２に対してＲＴＰによる通信が行われた場合のシーケンス図である。サーバ３１よりＲＴＰパケットがゲートウェイ装置５２に到着すると、それを受けてゲートウェイ装置５２はＳＩＰの呼接続要求としてＩＮＶＩＴＥパケットを送信し、帯域等の申請を行う。グローバル網においてエラーが発生し、エラー通知が返されると、図１２に示す場合と同様に、ゲートウェイ装置５２のエラー解析部５０５によりエラーの内容を解析し、エラー応答部５０６にエラーの内容を通知する。エラー応答部５０６は、サーバ３１に対して、ＲＴＳＰのＡＮＮＯＵＮＣＥメソッドを返す。ここで、エラー解析部５０５は、グローバル網４０からのエラー通知にＳＩＰの受付時間の記載がある場合にはその時間をエラー応答部５０６に通知し、エラー応答部５０６では、エラー通知にその時間を記述して、サーバ３１に対してエラー通知を行う。一方、ＳＩＰの受付時間の記載がない場合にはタイマ計算部５０７にグローバル網４０からのエラー通知の内容を通知し、タイマ計算部５０７ではグローバル網４０からのエラー通知の内容に基づいて計算した再接続要求可能な時間をエラー通知に記述して、サーバ３１に対してエラー通知を行う（ステップＳ１０ｂ〜Ｓ１３ｂ）。再送応答時間の記述は、ＲＴＳＰのＡＮＮＯＵＮＣＥメソッドのＳＤＰ（Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ）にｔ行を指定し、開始時間（ｓｔａｒｔ ｔｉｍｅ）を指定することにより行う。このエラー通知は、ＳＩＰに対応していないサーバであっても解釈可能であり、ＲＴＰによる通信を停止させ、ｓｔａｒｔ ｔｉｍｅの時間にサーバからの再通信が開始されるようになる。この際ＡＮＮＯＵＮＣＥメソッドでは、サーバのＲＴＰパケットを送信しているポート番号を指定することにより、目的のＲＴＰパケットを停止させるようにする。この例ではＡＮＮＯＵＮＣＥメソッドを利用したが、ＳＤＰのｔ行を指定できるＲＴＳＰのメッセージであればなんでも良い。
【００４４】
図１７ではエラー通知として、ＲＴＳＰのＡＮＮＯＵＮＣＥメソッドを返す場合について示したが、図１８では、サーバからクライアント端末１１に対してＲＴＰによる通信が行われた際に、ＲＴＳＰのＰＡＵＳＥメソッドを使用して、通信を停止させる方式について示す。グローバル網４０よりエラーがゲートウェイ装置５１に返されたときに、ＲＴＳＰのＰＡＵＳＥメソッドをサーバ３１に対して送信することにより、サーバからのＲＴＰパケットを停止させ、グローバル網４０に対しての申請が可能となったときにＲＴＳＰのＰＬＡＹメソッドを利用してサーバ３１からの通信を再開させる。この際もＲＴＳＰのポート番号の指定は、サーバ３１のＲＴＰを流しているポート番号とする。
【００４５】
図１９は図１７と同様に、エラー通知としてＲＴＳＰのＡＮＮＯＵＮＣＥを利用している。図１９においては、ＲＴＳＰのＡＮＮＯＵＮＣＥメソッドのＳＤＰにｂ行を指定し、利用帯域を０．０とすることで（ｂ＝０．０）、サーバに対して利用帯域幅が少ないことを示し、サーバ３１からの通信の停止を促す。再開時にはＡＮＮＯＵＮＣＥのＳＤＰのｂ行に０よりも大きい数値を入れることにより、再度通信の再開を促す。図１９では、再開時のＡＮＮＯＵＮＣＥのＳＤＰのｂ行を１．０とした場合について示す。なお、この例ではＡＮＮＯＵＮＣＥメソッドを利用したが、ＳＤＰのｂ行を指定できるＲＴＳＰのメッセージであればよい。
【００４６】
ＲＴＳＰのメッセージでは、Ｃｓｅｑ番号によって、どのメッセージに対する応答かどうかを判断する。ゲートウェイ装置５２が独自にサーバ３１に対してＲＴＳＰのメッセージを送信すると、クライアント端末１２とサーバ３１の間でのＣｓｅｑ番号にずれが生じる可能性がある。そのため、ゲートウェイ装置５０もしくは５２においてＲＴＳＰメッセージを一度終端し、Ｃｓｅｑ番号を付け替えてからサーバ３１に送るようにすることにより、Ｃｓｅｑ番号にずれが生じた場合にも問題なく通信を行うことができる。図２０に、ゲートウェイ装置５２により、Ｃｓｅｑ番号を付け替える場合のシーケンス図を示す。図２０では、図１９に示す場合と同様に、ＲＴＰの再送によりＵＤＰによる接続を確立し、クライアント端末１２からＲＴＳＰのメッセージがＣｓｅｑ＝１と設定されて送信されている。ＲＴＳＰのメッセージを受け取ったゲートウェイ装置５２は、このメッセージを終端し、Ｃｓｅｑ＝１００と付け替えてからサーバ３１に対して送信している。サーバ３１からの応答を受け取ったゲートウェイ装置は、このメッセージを終端し、Ｃｓｅｑ＝１００と付け替えてからクライアント装置１２に対して送信している。
【００４７】
図２１は、ゲートウェイ装置からＲＴＰの標準的な応答であるＲＴＣＰのＲＲ（Ｒｅｃｅｉｖｅ Ｒｅｐｏｒｔ）によりエラー通知を返す場合のシーケンス図を示す。サーバ３１よりＲＴＰの通信が発生し、グローバル網４０よりエラー通知があった場合に、ゲートウェイ装置５２はサーバ３１に対してＲＴＰの標準的な応答であるＲＴＣＰのＲＲにより、欠落率１００％を通知する。これにより、サーバ３１にグローバル網側にパケットが届かない旨を示唆し、サーバ側からのＲＴＰの通信を抑制する。通信の再開時には、ＲＴＣＰのＲＲにより、欠落率０％を通知することにより、サーバ３１にグローバル網側へのパケット送信が可能である旨を示唆する。
【００４８】
図２２は、サーバ３１に対して再接続までの時間（図２２では、ＲＴＳＰメッセージのｔ行を利用）の設定方法の例である。図１５に示す場合と同様に、サーバ３１からの既存の通信が終了し、実際にＳＩＰによる申請が切断されるまでの一定時間に、他の新しい通信要求が発生した場合、グローバル網４０により新しい通信は拒否され、エラー通知が返される。エラー通知を受け取ったゲートウェイ装置５２は、サーバに対して通知するＲＴＳＰメッセージのｔ行等の設定時間は、他の通信の最後のＲＴＰパケット到着時間から現在時刻までの経過時間（図２２中でＸ）と、予め設定されているゲートウェイ装置のＲＴＰの最終パケットからＢＹＥ送信までの時間（図２２中でＹ）とから計算され、ｓｔａｒｔ ｔｉｍｅへの設定時間を 現在時刻＋（Ｙ−Ｘ） と設定し、それを通知する。なお、多少の処理差を考慮し、ｔ行等で通知する時間を数秒ずらしてもよい。
【００４９】
本発明の実施の形態４に係るゲートウェイ装置では、以上のような構成をしているため、呼制御プロトコルに対応していないサーバに対しても、その通信方式に応じたエラー通知を行うことができ、また、通信要求の再送可能時間を通知することにより、無用な通信の再要求を実施させず効率的な通信が可能となる。
【００５０】
ここでは、中継通信装置としてゲートウェイ装置を用いた場合について示したが、ゲートウェイ装置のほか、ＩＰパケットを中継できる装置（例えばルータ等）であっても同様の効果が得られる。また、呼制御プロトコルとしてＳＩＰを用いた場合について示したが、Ｈ．３２３、ＭＧＣＰ等のプロトコルを用いてもよい。
【００５１】
実施の形態５．
実施の形態３では、エラー通知を受け取ったゲートウェイ装置がクライアント端末に対して、クライアント端末の解釈可能なエラー通知を行う方式について示したが、実施の形態５では、エラー通知を受け取ったゲートウェイ装置が、クライアント端末とのリンクをダウンさせる方式について示す。本発明の実施の形態３に係るゲートウェイ装置を用いたＩＰネットワークの基本構成図は、実施の形態１と同様であり、図１に示すとおりである。また、実施の形態５に係るゲートウェイ装置の構成は、実施の形態１と同様であり、図２に示すとおりである。
【００５２】
図２３は、エラー通知を受け取ったゲートウェイ装置が、クライアント端末とのリンクをダウンさせる場合のシーケンス図である。図２３において、ゲートウェイ装置５０は、実施の形態１において図６に示す場合と同様に、グローバル網からのエラー通知に対応して、ゲートウェイ装置５０がクライアント端末１１に対してＴＣＰ ＲＳＴを送信する。ゲートウェイ装置５０は、ＴＣＰ ＲＳＴを送信後、エラー応答部５０６により、クライアント端末１１に対応する物理ポートをリンクダウンさせる。リンクダウン中であるため、クライアント端末１１からの通信は発生しない。グローバル網４０に対してＳＩＰによる申請が可能になった場合、ゲートウェイ装置５０はリンクダウンしていたリンクをアップすることにより、クライアント端末４０からの要求を再度受け付けるようにし、図３に示すようにＴＣＰによる接続を確立し通信を行う。この方法はクライアント端末側だけでなく、サーバ３１とゲートウェイ装置５２間においても同様に行うことができる。
【００５３】
本発明の実施の形態５に係るゲートウェイ装置では、以上のような構成をしているためクライアント端末が呼制御プロトコルに対応していない場合であっても、無用な通信の再要求を実施しないという効果が得られる。
【００５４】
ここでは、中継通信装置としてゲートウェイ装置を用いた場合について示したが、ゲートウェイ装置のほか、ＩＰパケットを中継できる装置（例えばルータ等）であっても同様の効果が得られる。また、呼制御プロトコルとしてＳＩＰを用いた場合について示したが、Ｈ．３２３、ＭＧＣＰ等のプロトコルを用いてもよい。
【００５５】
実施の形態６．
実施の形態５では、有線による通信を利用した場合について示したが、本発明の実施の形態６では、無線通信を利用する方式について示す。実施の形態６に係るゲートウェイ装置の構成は、実施の形態１と同様であり、図２に示すとおりである。
【００５６】
図２４は、クライアント端末１１とゲートウェイ装置５０間において、無線通信が利用された場合の例である。図２３と同様にリンクダウンを行う意味で、無線ＬＡＮにおけるアクセスポイントの識別子であるＳＳＩＤ（Ｓｅｒｖｉｃｅ Ｓｅｔ Ｉｄｅｎｔｉｆｉｅｒ）を変更などすることにより、クライアント端末からの通信を拒否し、クライアント端末からの通信を発生させないようにする。再度グローバル網４０に対して申請が可能となる状態となった後に、クライアント端末１１からのＳＳＩＤを元に戻す変更を行い、クライアント端末１１からの要求を再度受け付けるようにする。そして、図３に示す場合と同様にＴＣＰによる接続を確立し、通信を行う。この方法はクライアント側だけでなくサーバ側３１とゲートウェイ装置５２間においても同様となる。
【００５７】
本発明の実施の形態６に係るゲートウェイ装置では、以上のような構成をしているため無線通信を用いるネットワークにおいて、クライアント端末が呼制御プロトコルに対応していない場合であっても、無用な通信の再要求を実施しないという効果が得られる。
【００５８】
ここでは、中継通信装置としてゲートウェイ装置を用いた場合について示したが、ゲートウェイ装置のほか、ＩＰパケットを中継できる装置（例えばルータ等）であっても同様の効果が得られる。また、呼制御プロトコルとしてＳＩＰを用いた場合について示したが、Ｈ．３２３、ＭＧＣＰ等のプロトコルを用いてもよい。
【符号の説明】
【００５９】
１０ プライベート網、１１，１２ クライアント端末、２０ プライベート網、２１ サーバ端末、３０ プライベート網、３１ サーバ端末、４０ グローバル網、４１ ＳＩＰサーバ、５０〜５２ ゲートウェイ装置、５０１ ＬＡＮインタフェース、５０２ ＷＡＮインタフェース、５０３ セッション制御部、５０４ 通信プロトコル解析部、５０５ エラー解析部、５０６ エラー応答部、５０７ タイマ計算部
【技術分野】
【０００１】
この発明は、異なるネットワーク間を連結する中継通信装置、および、その中継通信装置を用いた通信制御方法に関する。
【背景技術】
【０００２】
一般に、端末が所属するプライベート網では、高速かつ安価な通信が可能であるが、プライベート網間を接続するグローバル網における通信は、低速かつ高価なものとなる。そのため、グローバル網においては、呼制御プロトコルなどのさまざまなシステムを用いて高速化を図っている。一方、プライベート網では、厳密な帯域制御を必ずしも必要としないため、呼制御プロトコルに対応していない通信方式が採用される場合がある。したがって、プライベート網とグローバル網において、異なる通信方式が採用されることが多く、異なる通信方式間を中継するための変換装置が必要となる。そこで、従来の通信装置では、呼制御未対応の端末からの通信、例えばＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）／ＵＤＰ（Ｕｓｅｒ Ｄａｔａ Ｐｒｏｔｏｃｏｌ）による接続要求がゲートウェイ装置に届くと、ゲートウェイ装置がその通信が呼制御を行うべきものであるかの判断をし、呼制御を行うべき通信であると判断した場合、端末からその通信に適した呼制御セッションを張り、呼制御で確立したサービス（帯域や優先度）を付加することにより、呼制御プロトコルに未対応な端末であっても呼制御ネットワークへ適用可能としている。（例えば、特許文献１参照）
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】国際公開第２００６／０５１５９４号パンフレット（図１、第８頁〜第１１頁）
【発明の概要】
【発明が解決しようとする課題】
【０００４】
従来の通信装置を用いて端末側からグローバル網への通信が行われた場合、通常であればそのまま帯域の確保や優先度制御が呼制御プロトコルにより実施されるが、グローバル網のエラーにより、帯域の確保、優先度制御が実施されずにエラーがゲートウェイ装置などの中継通信装置に返ってきた場合、中継通信装置ではそのエラーを解釈することができるが、呼制御プロトコルに未対応の端末では、エラーを解釈することができない。そのため、グローバル網において未だエラーが生じているにもかかわらず、再送タイマによる再送が何度も繰り返され、無用な通信の再要求が生じることとなり、ネットワーク上のトラフィックの混雑を引き起こす恐れがある。
【０００５】
この発明は上記のような問題点を解決するためになされたものであり、呼制御プロトコルに対応したグローバル網でエラーが発生した場合に、呼制御プロトコルに対応していない端末又はサーバにおいても、グローバル網からのエラー通知を解釈できるようにすることを目的とする。
【課題を解決するための手段】
【０００６】
この発明に係る中継通信装置は、呼制御プロトコルに対応するグローバル網と、呼制御プロトコルに対応していない端末またはサーバを含むプライベート網とを連結する中継通信装置であって、端末またはサーバから通信要求を受け、グローバル網内に呼を確立するセッション制御部と、グローバル網から呼制御プロトコルによるエラー通知を受け取った場合、端末またはサーバが解釈可能な通信プロトコルのエラー通知に変換し、端末又はサーバに送信するエラー応答部と、を備えるものである。
【０００７】
また、この発明に係る中継通信装置は、呼制御プロトコルに対応するグローバル網と、呼制御プロトコルに対応していない端末またはサーバを含むプライベート網と、を連結する中継通信装置であって、端末またはサーバから通信要求信号を受け、グローバル網側への呼を確立して通信を行うセッション制御部と、グローバル網から呼制御プロトコルによるエラー通知を受け取った場合、端末又はサーバとのリンクをダウンさせるエラー応答部とを備えるものである。
【０００８】
また、この発明に係る通信制御方法は、中継通信装置が呼制御プロトコルに対応していない端末またはサーバから通信要求を受け、呼制御プロトコルに対応するグローバル網内に呼を確立するセッション制御ステップと、中継通信装置がグローバル網からの呼制御プロトコルによるエラー通知を受け取った場合、端末またはサーバが解釈可能な通信プロトコルのエラー通知を生成し、端末またはサーバへ送信するエラー応答ステップと、を備えることを特徴とするものである。
【発明の効果】
【０００９】
この発明によれば、グローバル網においてエラーが生じた場合でも、呼制御プロトコルに未対応の端末またはサーバにおいて、グローバル網からのエラー通知を解釈することができる。
【図面の簡単な説明】
【００１０】
【図１】本発明の実施の形態１に係るゲートウェイ装置を用いたネットワークの基本構成図である。
【図２】本発明の実施の形態１に係るゲートウェイ装置の構成図である。
【図３】本発明の実施の形態１に示す申請成功時のシーケンス図である。
【図４】本発明の実施の形態１に示す従来のゲートウェイ装置を用いた場合におけるエラー発生時のシーケンス図である。
【図５】本発明の実施の形態１に示す従来のゲートウェイ装置の構成図である。
【図６】本発明の実施の形態１に示すクライアント端末に行うエラー通知の例を示すシーケンス図である。
【図７】本発明の実施の形態１に示すクライアント端末に行うエラー通知の例を示すシーケンス図である。
【図８】従来のゲートウェイ装置を用いた場合におけるエラー発生時のシーケンス図である。
【図９】本発明の実施の形態２に示すサーバに行うエラー通知の例を示すシーケンス図である。
【図１０】本発明の実施の形態３に係るゲートウェイ装置の構成図である。
【図１１】本発明の実施の形態３に係るゲートウェイ装置の動作を表すフローチャートである。
【図１２】本発明の実施の形態３に示すクライアント端末に行うエラー通知の例を示すシーケンス図である。
【図１３】本発明の実施の形態３に示すクライアント端末に行うエラー通知の例を示すシーケンス図である。
【図１４】本発明の実施の形態３に示すクライアント端末に行うエラー通知の例を示すシーケンス図である。
【図１５】本発明の実施の形態３に示すエラー通知に記述する再送可能時間の計算例を示すシーケンス図である。
【図１６】本発明の実施の形態４に係るゲートウェイ装置の動作を表すフローチャートである。
【図１７】本発明の実施の形態４に示すサーバに行うエラー通知の例を示すシーケンス図である。
【図１８】本発明の実施の形態４に示すサーバに行うエラー通知の例を示すシーケンス図である。
【図１９】本発明の実施の形態４に示すサーバに行うエラー通知の例を示すシーケンス図である。
【図２０】本発明の実施の形態４に示すサーバに行うエラー通知の例を示すシーケンス図である。
【図２１】本発明の実施の形態４に示すサーバに行うエラー通知の例を示すシーケンス図である。
【図２２】本発明の実施の形態４に示すエラー通知に記述する再送可能時間の計算例を示すシーケンス図である。
【図２３】本発明の実施の形態５に示すリンクダウンによりクライアント端末に再送を停止させる場合のシーケンス図である。
【図２４】本発明の実施の形態６に示す無線通信を用いた場合におけるエラー通知の例を示すシーケンス図である。
【発明を実施するための形態】
【００１１】
実施の形態１．
図１に、本発明の実施の形態１に係る中継通信装置を用いたＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）ネットワークの基本構成図を示す。図１において、プライベート網１０、２０、３０がそれぞれグローバル網４０により接続されており、また、それぞれのプライベート網とグローバル網との間にはゲートウェイ装置５０、５１、５２が設置されている。また、プライベート網１０にはクライアント端末１１、１２、プライベート網２０にはサーバ２１、プライベート網３０にはサーバ３１がそれぞれ配置されている。ここで、クライアント端末１１およびサーバ３１は呼制御プロトコルであるＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）に対応していない。グローバル網４０には、ＳＩＰを経由するサーバとしてＳＩＰサーバ４１が設けられている。
【００１２】
図２に、本発明の実施の形態１に係るゲートウェイ装置の構成図を示す。図２において、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）インタフェース５０１はプライベート網であるＬＡＮに接続するためのインタフェースであり、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）インタフェース５０２はグローバル網であるＷＡＮに接続するためのインタフェースである。セッション制御部５０３はＮＧＮ（Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ Ｎｅｔｗｏｒｋ）等により構成されるグローバル網４０に対して、帯域申請等を行い、呼接続の確立を行う。通信プロトコル解析部５０４は、端末やサーバからの通信に用いられるプロトコルの解析を行う。エラー解析部５０５はグローバル網４０からのエラー通知の解析を行う。エラー応答部５０６はプライベート網側のクライアント端末やサーバへのエラー通知を行う。
【００１３】
次に、ゲートウェイ装置の動作についてシーケンス図を用いて説明する。図３に、グローバル網においてエラーが発生せず、通常の通信が行われる場合のシーケンス図を示す。ゲートウェイ装置５０は、クライアント端末１１から送信された通信要求としてのＴＣＰ ＳＹＮパケットを受信した場合、通信プロトコル解析部５０４により、送信元のＩＰアドレス、ポート番号、宛先のＩＰアドレス、ポート番号等を確認し、セッション制御部５０３により、アプリケーションに合わせた帯域の申請、優先度制御の申請をＳＩＰによる呼接続要求パケットとしてのＩＮＶＩＴＥパケットをグローバル網に対し送信する。グローバル網４０に設けられたＳＩＰサーバ４１は、ゲートウェイ装置５０からＩＮＶＩＴＥパケットを受信すると、このＩＮＶＩＴＥパケットを宛先のゲートウェイ装置５１へ転送する。このとき、ＳＩＰサーバ４１は、ゲートウェイ装置５０に準備応答メッセージ１００ Ｔｒｙｉｎｇメッセージを返す。ＳＩＰサーバ４０から転送されたＩＮＶＩＴＥパケットを受信したゲートウェイ装置５１は、ＩＮＶＩＴＥパケットを受信したことを示す１００ ＴｒｙｉｎｇおよびＩＮＶＩＴＥパケットの受付応答である２００ ＯＫをＳＩＰサーバ４１に送付する。ＳＩＰによる申請が終了したら、ゲートウェイ装置５０で待機させていたＴＣＰ ＳＹＮパケットをＳＩＰで確保された帯域、優先度制御を活用して相手先のサーバ２１まで転送し、ＴＣＰ ＳＹＮを受け取ったサーバ２１はＳＹＮ／ＡＣＫを返す。ＳＹＮ／ＡＣＫを受け取ったクライアント端末１１は、ＡＣＫを返し、ＴＣＰセッションがクライアント端末１１、サーバ２１間で確立される。一度ＳＩＰのセッションにより申請が完了すれば、通常の通信と同様の動作となり、クライアント端末１１はＨＴＴＰ ＧＥＴなどの通信を開始する。
【００１４】
次に、グローバル網において、エラーが発生した場合のゲートウェイ装置の動作について示す。ここで、グローバル網におけるエラーとは何らかの理由により、プライベート網から送信された信号が宛先のゲートウェイ装置に到達しない場合をいい、例えば、グローバル網の故障や、通信フローが一時的に増加し、セッションの同時申請が制限され、プライベート網からグローバル網への通信要求が拒否されるような場合をいう。
【００１５】
図４は、従来のゲートウェイ装置を用いた場合のシーケンス図である。また、図５に従来のゲートウェイ装置の構成を示す。図５において、図２と同一の符号は同一または同様の部分を示している。クライアント端末１１からＴＣＰの通信要求としてのＴＣＰ ＳＹＮパケットがゲートウェイ装置５０に到着し、ゲートウェイ装置５０は通信プロトコル解析部５０４により通信要求を解析する。解析結果に基づいて、セッション制御部５０３によりグローバル網４０に対してＳＩＰによる呼接続要求としてのＩＮＶＩＴＥパケットを送信し、帯域、優先制御の申請を行う。しかし、グローバル網４０においてエラーが発生したため申請が失敗し、ゲートウェイ装置５０にＳＩＰのエラー通知である４ｘｘ リクエストエラーが返っている。ゲートウェイ装置では、ＳＩＰのエラー通知を解釈することができるが、クライアント端末はＳＩＰに対応していないためこのエラー通知を解釈することができない。そのため、クライアント端末に対してエラー通知は行われず、再送タイマによる通信要求の再送が何度も行われており、無用な通信要求が発生している。
【００１６】
図６は、本発明の実施の形態１に係るゲートウェイ装置を用いた場合における、グローバル網のエラー発生時のシーケンス図である。図４に示す従来のゲートウェイ装置を用いた場合と同様に、ゲートウェイ装置５０から送信されたＳＩＰによる申請に対し、グローバル網４０からＳＩＰのエラー通知が返ってきている。実施の形態１に係るゲートウェイ装置では、エラー解析部５０５により、受け取ったＳＩＰのエラー通知を読み取ってその内容、例えば、エラー通知に含まれる応答コードやＲｅｔｒｙ Ａｆｔｅｒ等のメッセージを読み取り、グローバル網におけるエラーの発生をエラー応答部５０６に通知する。通知を受けたエラー応答部５０６では、グローバル網から受け取ったＳＩＰのエラー通知をＴＣＰ ＲＳＴに変換し、クライアント端末１１にエラー通知として送信する。ＴＣＰ ＲＳＴはＳＩＰに対応していないクライアント端末でも解釈できるため、ＴＣＰ ＲＳＴを受け取ったクライアント端末１１は通信を停止させ、再送を発生させないようにしている。
【００１７】
実施の形態１に係るゲートウェイ装置では、以上のような構成をしているため、通信の要求を行うクライアント端末が呼制御プロトコルに対応していない場合であっても、グローバル網側のエラー通知を認識することができるようになり、無用な通信の再要求が発生しないという効果が得られる。
【００１８】
ここでは、ゲートウェイ装置４０がクライアント端末１１に対し、ＴＣＰ ＲＳＴを返すようにした場合について示したが、図７に示すように、ＩＰによるエラーメッセージであるＩＣＭＰ（Ｉｎｔｅｒｎｅｔ Ｃｏｎｔｒｏｌ Ｍｅｓｓａｇｅ Ｐｒｏｔｏｃｏｌ） Ｎｅｔｗｗｏｒｋ Ｕｎｒｅａｃｈａｂｌｅを返答し、クライアント端末１１からの通信を停止させ、通信要求の再送を発生させないようにすることもできる。
【００１９】
また、中継通信装置としてゲートウェイ装置を用いた場合について示したが、ゲートウェイ装置のほか、ＩＰパケットを中継できる装置（例えばルータ等）であっても同様の効果が得られる。さらに、呼制御プロトコルとしてＳＩＰを用いた場合について示したが、Ｈ．３２３、ＭＧＣＰ等のプロトコルを用いてもよい。また、クライアント端末に対し通信要求の再送を停止させるためのエラー通知を行う場合について示したが、クライアント端末が複数のネットワークに接続されている場合には、異なるネットワーク（例えば無線通信網）などによる通信に変更させるエラー通知としてもよい。
【００２０】
実施の形態２．
実施の形態１では、クライアント端末から通信要求が送信された場合について示したが、実施の形態２ではサーバ側から通信要求が送信された場合について示す。本発明の実施の形態２に係るゲートウェイ装置を用いたＩＰネットワークの基本構成図は、実施の形態１と同様であり、図１に示すとおりである。また、本発明の実施の形態２に係るゲートウェイ装置の構成は、実施の形態１に係るゲートウェイ装置と同様であり、図２に示す通りである。
【００２１】
図８に、従来のゲートウェイ装置を用いた場合のシーケンス図を示す。サーバ３１から、クライアント端末１２に対して、動画などで利用されるＲＴＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）パケットが送信され、ゲートウェイ装置５２に到達すると、ゲートウェイ装置５２は実施の形態１の場合と同様に送信元、宛先のＩＰアドレスとポート番号を解析し、グローバル網４０にＳＩＰの呼接続要求としてのＩＮＶＩＴＥパケットを送信する。しかし、グローバル網でエラーがあり、ゲートウェイ装置にＳＩＰのエラー通知４ｘｘ リクエストエラーが返されている。ゲートウェイ装置５２では、ＳＩＰのエラー通知を解釈することができるが、サーバ３１はＳＩＰに対応していないため、このエラー通知を解釈することができない。そのため、サーバ３１に対してエラー通知が行われず、サーバからは常にＲＴＰパケットが送信され続けている。
【００２２】
図９は、本発明の実施の形態２に係るゲートウェイ装置を用いた場合における、グローバル網のエラー発生時のシーケンス図である。図８に示す場合と同様に、通信要求および呼接続要求が送信され、グローバル網のエラーにより、エラー通知４ｘｘ リクエストエラーが返されている。エラー通知を受信したゲートウェイ装置５２は、エラー解析部５０５により受信したエラー通知を解析し、解析結果に基づいてエラー応答部５０６によりサーバ３１に対してＩＰによるエラー通知であるＮｅｔｗｗｏｒｋ Ｕｎｒｅａｃｈａｂｌｅを返す。このエラー通知はＳＩＰに未対応のサーバ３１でも解釈可能なエラー通知であり、エラー通知を受け取ったサーバ３１は、サーバからの通信を停止させている。
【００２３】
実施の形態２に係るゲートウェイ装置では、以上のような構成をしているため、通信の要求を行うサーバが呼制御プロトコルに対応していない場合であっても、グローバル網側のエラーを認識することができるようになり、通常の通信と同様のエラー時の判断をすることができる。従って、無用な通信の再要求を実施しないという効果が得られる。
【００２４】
ここでは、中継通信装置としてゲートウェイ装置を用いた場合について示したが、ゲートウェイ装置のほか、ＩＰパケットを中継できる装置（例えばルータ等）であっても同様の効果が得られる。また、呼制御プロトコルとしてＳＩＰを用いた場合について示したが、Ｈ．３２３、ＭＧＣＰ等のプロトコルを用いてもよい。さらに、サーバに対し通信要求の再送を停止させるためのエラー通知を行う場合について示したが、サーバが複数のネットワークに接続されている場合には、異なるネットワーク（例えば無線通信網）などによる通信に変更させるエラー通知としてもよい。
【００２５】
実施の形態３．
実施の形態１では、ゲートウェイ装置がエラー通知を受け取った場合、クライアント端末の通信方式に関わらず同じエラー通知を返す方式について示したが、実施の形態３では、クライアント端末の通信方式に応じてエラー通知の種類を変更させる方式について示す。本発明の実施の形態３に係るゲートウェイ装置を用いたＩＰネットワークの基本構成図は、実施の形態１と同様であり、図１に示すとおりである。
【００２６】
実施の形態３に係るゲートウェイ装置の構成を図１０に示す。図１０において、タイマ計算部５０７は、エラー応答により通信を停止させた後、通信要求の再送可能時間の計算を行う。なお、図２と同一の符号については同一または同様の部分を示す。
【００２７】
図１１は、本発明の実施の形態３に係るゲートウェイ装置の動作を示すフローチャートである。クライアント端末１１によりＴＣＰによる通信要求が発生し（ステップＳ１）、プライベート網とグローバル網との間に存在する中継通信装置であるゲートウェイ装置５０において、この通信要求を受信する（ステップＳ２）。通信要求を受信したゲートウェイ装置５０は、通信プロトコル解析部５０４により、この通信要求の内容を解釈するとともに、この通信要求をトリガとして、セッション制御部５０３によりグローバル網４０に対してＳＩＰによる帯域申請、優先度申請等を行う（ステップＳ３）。ステップＳ４では、セッション制御部５０３によりＳＩＰによる申請が成功したかの判定を行い、ＳＩＰによる申請が成功した場合には、ステップＳ５へと進む。ステップＳ５では、図３に示す場合と同様に通信要求をグローバル網側に転送し、申請したサービスを適用した状態での通常通りの通信を開始する。
【００２８】
一方、グローバル網においてエラーが発生した場合、ＳＩＰによる申請が失敗し、グローバル網側よりエラー通知が返されると、ゲートウェイ装置５０はクライアント端末１１に通信要求に対する暫定応答を返す（ステップＳ６）。暫定応答を受けたクライアント端末１１は、その後ＨＴＴＰなどのアプリケーションの通信を開始する（ステップＳ７）。ゲートウェイ装置ではこのアプリケーションの通信を受信し（ステップＳ８）、プロトコル解析部５０４により受け取った通信の種別の解析を行う（ステップＳ９）。解析の結果に基づいて、エラー応答部５０６によりそれぞれの通信方式に合わせて応答の種別を変更し、通信要求を行ったクライアント端末１１にエラー通知を返す。これにより、クライアント端末からの通信方式に応じた通知することができ、再送可能時間などの詳細なエラー通知を行うことが可能となる。ここでは、エラー通知を行う際に応答時間についてグローバル網より通知が来ている場合には、エラー通知にその時間も追加して応答する（ステップＳ１０〜Ｓ１３）。
【００２９】
図１２は、クライアント端末１１からサーバ２１に対し、通信方式としてＨＴＴＰを利用してアクセスを行った場合のシーケンス図である。クライアント端末１１から通信要求としてのＴＣＰ ＳＹＮパケットがゲートウェイ装置５０に到着すると、それを受けてゲートウェイ装置５０はグローバル網４０に対してＳＩＰの呼接続要求としてのＩＮＶＩＴＥパケットを送信し、帯域等の申請を行う。グローバル網４０において何らかのエラーが発生し、グローバル網４０からＳＩＰのエラー通知４ｘｘ リクエストエラーが返されると、ゲートウェイ装置５０は、エラー解析部５０５によりエラー通知の内容、例えば、エラー通知に含まれる応答コードやＲｅｔｒｙ Ａｆｔｅｒ等のメッセージを読み取り、読み取った内容をエラー応答部５０６に通知する。通知を受け取ったエラー応答部５０６は、クライアント端末１１に対して、暫定応答としてＴＣＰ ＳＹＮ／ＡＣＫを返す。暫定応答を受信したクライアント端末１１は、ＨＴＴＰ ＧＥＴなどのＨＴＴＰによる通信を開始し、ゲートウェイ装置５０がこの通信を受信する。ゲートウェイ装置５０は、通信プロトコル解析部５０４により、クライアント端末１１からの通信の通信方式を解析し、解析した通信方式をエラー応答部５０７に通知する。通信方式がＨＴＴＰである場合には、クライアント端末１１からのＨＴＴＰによる通信をグローバル網４０へとは通さず、その応答として、エラー応答部５０７により、ＳＩＰのエラー通知をＨＴＴＰによるエラー通知（５０３ Ｓｅｒｖｉｃｅ Ｕｎａｖａｉｌａｂｌｅ）に変換し、クライアント端末１１に返す。
【００３０】
ここで、エラー解析部５０５は、グローバル網４０からのエラー通知にＳＩＰの受付時間の記載がある場合にはその時間をエラー応答部５０６に通知する。エラー応答部５０６では、ＨＴＴＰによるエラー通知にその時間を記述し、クライアント端末１１にエラー通知を返す。一方、ＳＩＰの受付時間の記載がない場合にはタイマ計算部５０７にグローバル網４０からのエラー通知の内容を通知し、タイマ計算部５０７ではグローバル網４０からのエラー通知の内容に基づいて計算した再接続要求可能な時間をエラー通知に記述し、クライアント端末１１にエラー通知を返す（ステップＳ１０ｂ〜Ｓ１３ｂ）。ここでは、５０３ Ｓｅｒｖｉｃｅ Ｕｎａｖａｉｌａｂｌｅのメッセージに再接続要求の時間を設定するＲｅｔｒｙ−Ａｆｔｅｒを記述することにより、再接続要求可能な時間が設定されたエラー通知を行うことができる。また、エラー通知の内容とはＳＩＰの応答コードであり、例えば４００ Ｂａｄ Ｒｅｑｕｅｓｔのように定められているものである。エラー通知の内容に応じて、再接続までの時間を設定することもできる。これにより、グローバル網において生じたエラーの内容に応じた再接続要求時間をクライアント端末に通知することができ、効率的な通信を行うことができる。
【００３１】
クライアント端末１１はこのＨＴＴＰのエラー通知を解釈することができ、ＦＩＮパケットを送信しゲートウェイ装置５０との通信の切断を行う。そして、Ｒｅｔｒｙ−Ａｆｔｅｒに記述されている時間後に再接続を試みる。図１２においては、ＨＴＴＰによるエラー通知にＲｅｔｒｙ−Ａｆｔｅｒ ３０を設定し、エラー通知を受け取ったクライアント端末１１はエラー通知を受信後３０秒後に、通信要求を再送する。通信要求の再送時には、グローバル網におけるエラーは解消されており、実施の形態１の図３に示す場合と同様にＴＣＰセッションが確立されＨＴＴＰによる通信を行うことができる。
【００３２】
図１２では、ゲートウェイ装置４０からの５０３ Ｓｅｒｖｉｃｅ ＵｎａｖａｉｌａｂｌｅのＲｅｔｒｙ−Ａｆｔｅｒに再接続を行うまでの時間を記述した場合について示したが、図１３に示すように、ＧＭＴ（Ｇｒｅｅｎｗｉｃｈ Ｍｅａｎ Ｔｉｍｅ）時間を記述してもよい。ＧＭＴ時間を記述することにより、クライアント端末はその時間に再接続を試みる。
【００３３】
次に、通信方式としてＦＴＰ（Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）を利用した場合について示す。クライアント端末１１からサーバ２１に対し、通信方式としてＦＴＰを利用してアクセスを行った場合のシーケンス図を図１４に示す。図１４において、クライアント端末１１からＦＴＰによる通信要求が発生すると、図１２に示すＨＴＴＰによる通信の場合と同様に、ゲートウェイ装置５０はグローバル網４０に対してＳＩＰの呼接続要求としてＩＮＶＩＴＥパケットを送信し、帯域および優先度制御等の申請を行う。グローバル網４０よりエラー通知があると、ゲートウェイ装置５０より、ＴＣＰによる暫定応答としてＴＣＰ ＳＹＮ／ＡＣＫをクライアント端末に返す。ゲートウェイ端末５０から暫定応答を受け取ったクライアント端末１１はＦＴＰによる通信を行う。ゲートウェイ装置５０は、通信プロトコル解析部５０４において、クライアント端末１１からの通信を解析する（ステップＳ９）。クライアント端末１１からの通信が、ＦＴＰによるものであると認識した場合には、ＦＴＰによる通信に対してＲｅｓｐｏｎｓｅコード１２０をクライアント端末１１に返す（ステップＳ１３ａ）。ここで、グローバル網からのエラー通知にＳＩＰの受付時間の記載がある場合にはその時間を、ない場合にはタイマ計算部５０７により計算を行った再送可能時間をＲｅｓｐｏｎｓｅコード１２０に指定し（ステップＳ１１ａ、Ｓ１２ａ）、クライアント端末１１に対して何分後にサーバが準備できるかを通知することで、同時にクライアント端末からの要求を停止させることが可能となる。図１４においては、Ｓｅｒｖｉｃｅ ｒｅａｄｙ ｉｎ ５ ｍｉｎｕｔｅｓを設定し、Ｒｅｓｐｏｎｓｅコード１２０の受信から５分後に、通信要求を再送させている。通信要求の再送時にはグローバル網４０におけるエラーは解消されており、実施の形態１の図３に示す場合と同様にＴＣＰセッションを確立させ、ＦＴＰによる通信を行う。
【００３４】
また、ＦＴＰおよびＨＴＴＰ以外の通信方式による通信を受けた場合、実施の形態１で示した場合と同様に、ＳＩＰに対応していない端末においても解釈可能なＴＣＰ ＲＳＴを返す構成としている（ステップＳ１３ｃ）。
【００３５】
図１５は、タイマ計算部５０７における、再接続までの時間（Ｒｅｔｒｙ−Ａｆｔｅｒ）の計算方法の例である。ＳＩＰを用いたシステムでは、通信が終了してからＳＩＰによる接続を切断するまでの時間は、即時ではなく、一定時間待ってから終了させる場合がある。ここで、グローバル網側の制限として、一定数までのＳＩＰによる申請までしか受け付けていない状態を前提とする。クライアント端末１１からＴＣＰ ＦＩＮパケットを送信し、ゲートウェイ装置５０およびクライアント端末１１からそれぞれ応答メッセージであるＴＣＰ ＦＩＮ／ＡＣＫおよびＡＣＫパケットが返されることにより、既存の通信が終了する。そして、一定時間経過後にゲートウェイ装置５０によりＢＹＥが送信され、ＳＩＰサーバ４１により宛先のゲートウェイ装置５２に転送される。ゲートウェイ装置５２およびＳＩＰサーバ４１により２００ ＯＫが返されることにより、ＳＩＰによる接続が切断される。その間に、他の新しい通信が発生した場合、グローバル網４０により新しい通信は拒否され、エラー通知が返される。エラー通知を受け取ったゲートウェイ装置５０は、Ｒｅｔｒｙ−Ａｆｔｅｒ等でクライアント端末１１に対して、既存の通信のＳＩＰによる申請が切断されるまでの時間を計算し、それを通知する。図１５における再送までの時間は、予め設定されている通信の終了を表すＦＩＮパケットの送信から実際にＳＩＰの申請を切断するＢＹＥまでの設定時間（図１５中でＹ）と、それまでに実際に行われた通信におけるＦＩＮパケットの送信から、ゲートウェイ装置がクライアント端末に対してエラー通知を返すまでの経過時間（図１５中でＸ）から計算しており、通信要求の再送までの時間（図１５中でＺ）はＺ＝Ｙ−Ｘで求められる。求めた時間Ｚをクライアント端末１１に通知することにより、その時間後に通信要求の再送を行わせることができる。なお、多少の処理差を考慮し、Ｒｅｔｒｙ−Ａｆｔｅｒで通知する時間を数秒ずらすことも可能である。
【００３６】
なお、クライアント端末のユーザがブラウザ（ＨＴＴＰ）を利用した通信を行い、グローバル網よりエラーが返された場合、自動的に再接続をさせる方法とは別に、ブラウザに現在の状況（エラーの状態や何秒後に復帰するというＲｅｔｒｙ−Ａｆｔｅｒの情報など）を表示させ、ユーザ自身に再接続させる方法をとってもよい。
【００３７】
本発明の実施の形態３に係るゲートウェイ装置では、以上のような構成をしているため、呼制御プロトコルに対応していないクライアント端末に対しても、その通信方式に応じたエラー通知を行うことができ、また、通信要求の再送可能時間を通知することができる。これにより、無用な通信の再要求を実施させず、効率的な通信が可能となる。
【００３８】
ここでは、中継通信装置としてゲートウェイ装置を用いた場合について示したが、ゲートウェイ装置のほか、ＩＰパケットを中継できる装置（例えばルータ等）であっても同様の効果が得られる。また、呼制御プロトコルとしてＳＩＰを用いた場合について示したが、Ｈ．３２３、ＭＧＣＰ等のプロトコルを用いてもよい。
【００３９】
また、ここでは、エラー通知を受け取ったゲートウェイ装置から暫定応答をクライアント端末に返す方式について示したが、通信方式をクライアント端末からの通信要求から読み取り、エラー通知を返す方法、すなわち、図１１に示すフローチャートのうちステップＳ６〜ステップＳ８を省略することもできる。これにより、クライアント端末からの通信の詳細な内容は解析できないものの、クライアント端末からの通信を減少させることができる。
【００４０】
実施の形態４．
実施の形態３では、クライアント端末からの通信要求を送信した場合について示したが、実施の形態４では、サーバから通信要求が発生する場合について示す。本発明の実施の形態３に係る中継通信装置を用いたＩＰネットワークの基本構成図は、実施の形態１と同様であり、図１に示すとおりである。また、ゲートウェイ装置の構成は、実施の形態３と同様であり、図１０に示すとおりである。
【００４１】
図１６は、サーバ３１からクライアント端末１２に対してＵＤＰによる通信が発生した場合のフローチャートである。プライベート網３０に収容されているサーバ３１よりＵＤＰによる新規の通信要求が発生する（ステップＳ１）と、プライベート網３０とグローバル網４０の間に存在するゲートウェイ装置５２において、この通信を受信する（ステップＳ２）。この新規の通信を受信したゲートウェイ装置は通信の内容（宛先ＩＰアドレス、宛先ポート番号、送信元ＩＰアドレス、送信元ポート番号等）を解釈すると共に、グローバル網４０に対してＳＩＰによる帯域申請、優先度申請などを行う（ステップＳ３）。ステップＳ４において、ＳＩＰによる申請が成功したかの判定を行い、ＳＩＰによる申請が成功した場合には、ステップＳ５に進み、新規の通信を申請したサービスを適用した状態での通信を通常通り行う。
【００４２】
一方、ＳＩＰによる申請が失敗し、グローバル網側よりエラーが返されると、ゲートウェイはサーバにＲＴＳＰ（Ｒｅａｌ Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）メッセージ／ＲＴＣＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）応答等を返す。その際に、ＳＩＰの受付時間についてグローバル網４０より通知されている場合には、メッセージにその時間を追加し、通知されていない場合には再送応答時間を計算し、メッセージに計算した時間を追加して応答する（ステップＳ１０ｄ〜Ｓ１３ｄ）。
【００４３】
図１７に、サーバ３１よりクライアント端末１２に対してＲＴＰによる通信が行われた場合のシーケンス図である。サーバ３１よりＲＴＰパケットがゲートウェイ装置５２に到着すると、それを受けてゲートウェイ装置５２はＳＩＰの呼接続要求としてＩＮＶＩＴＥパケットを送信し、帯域等の申請を行う。グローバル網においてエラーが発生し、エラー通知が返されると、図１２に示す場合と同様に、ゲートウェイ装置５２のエラー解析部５０５によりエラーの内容を解析し、エラー応答部５０６にエラーの内容を通知する。エラー応答部５０６は、サーバ３１に対して、ＲＴＳＰのＡＮＮＯＵＮＣＥメソッドを返す。ここで、エラー解析部５０５は、グローバル網４０からのエラー通知にＳＩＰの受付時間の記載がある場合にはその時間をエラー応答部５０６に通知し、エラー応答部５０６では、エラー通知にその時間を記述して、サーバ３１に対してエラー通知を行う。一方、ＳＩＰの受付時間の記載がない場合にはタイマ計算部５０７にグローバル網４０からのエラー通知の内容を通知し、タイマ計算部５０７ではグローバル網４０からのエラー通知の内容に基づいて計算した再接続要求可能な時間をエラー通知に記述して、サーバ３１に対してエラー通知を行う（ステップＳ１０ｂ〜Ｓ１３ｂ）。再送応答時間の記述は、ＲＴＳＰのＡＮＮＯＵＮＣＥメソッドのＳＤＰ（Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ）にｔ行を指定し、開始時間（ｓｔａｒｔ ｔｉｍｅ）を指定することにより行う。このエラー通知は、ＳＩＰに対応していないサーバであっても解釈可能であり、ＲＴＰによる通信を停止させ、ｓｔａｒｔ ｔｉｍｅの時間にサーバからの再通信が開始されるようになる。この際ＡＮＮＯＵＮＣＥメソッドでは、サーバのＲＴＰパケットを送信しているポート番号を指定することにより、目的のＲＴＰパケットを停止させるようにする。この例ではＡＮＮＯＵＮＣＥメソッドを利用したが、ＳＤＰのｔ行を指定できるＲＴＳＰのメッセージであればなんでも良い。
【００４４】
図１７ではエラー通知として、ＲＴＳＰのＡＮＮＯＵＮＣＥメソッドを返す場合について示したが、図１８では、サーバからクライアント端末１１に対してＲＴＰによる通信が行われた際に、ＲＴＳＰのＰＡＵＳＥメソッドを使用して、通信を停止させる方式について示す。グローバル網４０よりエラーがゲートウェイ装置５１に返されたときに、ＲＴＳＰのＰＡＵＳＥメソッドをサーバ３１に対して送信することにより、サーバからのＲＴＰパケットを停止させ、グローバル網４０に対しての申請が可能となったときにＲＴＳＰのＰＬＡＹメソッドを利用してサーバ３１からの通信を再開させる。この際もＲＴＳＰのポート番号の指定は、サーバ３１のＲＴＰを流しているポート番号とする。
【００４５】
図１９は図１７と同様に、エラー通知としてＲＴＳＰのＡＮＮＯＵＮＣＥを利用している。図１９においては、ＲＴＳＰのＡＮＮＯＵＮＣＥメソッドのＳＤＰにｂ行を指定し、利用帯域を０．０とすることで（ｂ＝０．０）、サーバに対して利用帯域幅が少ないことを示し、サーバ３１からの通信の停止を促す。再開時にはＡＮＮＯＵＮＣＥのＳＤＰのｂ行に０よりも大きい数値を入れることにより、再度通信の再開を促す。図１９では、再開時のＡＮＮＯＵＮＣＥのＳＤＰのｂ行を１．０とした場合について示す。なお、この例ではＡＮＮＯＵＮＣＥメソッドを利用したが、ＳＤＰのｂ行を指定できるＲＴＳＰのメッセージであればよい。
【００４６】
ＲＴＳＰのメッセージでは、Ｃｓｅｑ番号によって、どのメッセージに対する応答かどうかを判断する。ゲートウェイ装置５２が独自にサーバ３１に対してＲＴＳＰのメッセージを送信すると、クライアント端末１２とサーバ３１の間でのＣｓｅｑ番号にずれが生じる可能性がある。そのため、ゲートウェイ装置５０もしくは５２においてＲＴＳＰメッセージを一度終端し、Ｃｓｅｑ番号を付け替えてからサーバ３１に送るようにすることにより、Ｃｓｅｑ番号にずれが生じた場合にも問題なく通信を行うことができる。図２０に、ゲートウェイ装置５２により、Ｃｓｅｑ番号を付け替える場合のシーケンス図を示す。図２０では、図１９に示す場合と同様に、ＲＴＰの再送によりＵＤＰによる接続を確立し、クライアント端末１２からＲＴＳＰのメッセージがＣｓｅｑ＝１と設定されて送信されている。ＲＴＳＰのメッセージを受け取ったゲートウェイ装置５２は、このメッセージを終端し、Ｃｓｅｑ＝１００と付け替えてからサーバ３１に対して送信している。サーバ３１からの応答を受け取ったゲートウェイ装置は、このメッセージを終端し、Ｃｓｅｑ＝１００と付け替えてからクライアント装置１２に対して送信している。
【００４７】
図２１は、ゲートウェイ装置からＲＴＰの標準的な応答であるＲＴＣＰのＲＲ（Ｒｅｃｅｉｖｅ Ｒｅｐｏｒｔ）によりエラー通知を返す場合のシーケンス図を示す。サーバ３１よりＲＴＰの通信が発生し、グローバル網４０よりエラー通知があった場合に、ゲートウェイ装置５２はサーバ３１に対してＲＴＰの標準的な応答であるＲＴＣＰのＲＲにより、欠落率１００％を通知する。これにより、サーバ３１にグローバル網側にパケットが届かない旨を示唆し、サーバ側からのＲＴＰの通信を抑制する。通信の再開時には、ＲＴＣＰのＲＲにより、欠落率０％を通知することにより、サーバ３１にグローバル網側へのパケット送信が可能である旨を示唆する。
【００４８】
図２２は、サーバ３１に対して再接続までの時間（図２２では、ＲＴＳＰメッセージのｔ行を利用）の設定方法の例である。図１５に示す場合と同様に、サーバ３１からの既存の通信が終了し、実際にＳＩＰによる申請が切断されるまでの一定時間に、他の新しい通信要求が発生した場合、グローバル網４０により新しい通信は拒否され、エラー通知が返される。エラー通知を受け取ったゲートウェイ装置５２は、サーバに対して通知するＲＴＳＰメッセージのｔ行等の設定時間は、他の通信の最後のＲＴＰパケット到着時間から現在時刻までの経過時間（図２２中でＸ）と、予め設定されているゲートウェイ装置のＲＴＰの最終パケットからＢＹＥ送信までの時間（図２２中でＹ）とから計算され、ｓｔａｒｔ ｔｉｍｅへの設定時間を 現在時刻＋（Ｙ−Ｘ） と設定し、それを通知する。なお、多少の処理差を考慮し、ｔ行等で通知する時間を数秒ずらしてもよい。
【００４９】
本発明の実施の形態４に係るゲートウェイ装置では、以上のような構成をしているため、呼制御プロトコルに対応していないサーバに対しても、その通信方式に応じたエラー通知を行うことができ、また、通信要求の再送可能時間を通知することにより、無用な通信の再要求を実施させず効率的な通信が可能となる。
【００５０】
ここでは、中継通信装置としてゲートウェイ装置を用いた場合について示したが、ゲートウェイ装置のほか、ＩＰパケットを中継できる装置（例えばルータ等）であっても同様の効果が得られる。また、呼制御プロトコルとしてＳＩＰを用いた場合について示したが、Ｈ．３２３、ＭＧＣＰ等のプロトコルを用いてもよい。
【００５１】
実施の形態５．
実施の形態３では、エラー通知を受け取ったゲートウェイ装置がクライアント端末に対して、クライアント端末の解釈可能なエラー通知を行う方式について示したが、実施の形態５では、エラー通知を受け取ったゲートウェイ装置が、クライアント端末とのリンクをダウンさせる方式について示す。本発明の実施の形態３に係るゲートウェイ装置を用いたＩＰネットワークの基本構成図は、実施の形態１と同様であり、図１に示すとおりである。また、実施の形態５に係るゲートウェイ装置の構成は、実施の形態１と同様であり、図２に示すとおりである。
【００５２】
図２３は、エラー通知を受け取ったゲートウェイ装置が、クライアント端末とのリンクをダウンさせる場合のシーケンス図である。図２３において、ゲートウェイ装置５０は、実施の形態１において図６に示す場合と同様に、グローバル網からのエラー通知に対応して、ゲートウェイ装置５０がクライアント端末１１に対してＴＣＰ ＲＳＴを送信する。ゲートウェイ装置５０は、ＴＣＰ ＲＳＴを送信後、エラー応答部５０６により、クライアント端末１１に対応する物理ポートをリンクダウンさせる。リンクダウン中であるため、クライアント端末１１からの通信は発生しない。グローバル網４０に対してＳＩＰによる申請が可能になった場合、ゲートウェイ装置５０はリンクダウンしていたリンクをアップすることにより、クライアント端末４０からの要求を再度受け付けるようにし、図３に示すようにＴＣＰによる接続を確立し通信を行う。この方法はクライアント端末側だけでなく、サーバ３１とゲートウェイ装置５２間においても同様に行うことができる。
【００５３】
本発明の実施の形態５に係るゲートウェイ装置では、以上のような構成をしているためクライアント端末が呼制御プロトコルに対応していない場合であっても、無用な通信の再要求を実施しないという効果が得られる。
【００５４】
ここでは、中継通信装置としてゲートウェイ装置を用いた場合について示したが、ゲートウェイ装置のほか、ＩＰパケットを中継できる装置（例えばルータ等）であっても同様の効果が得られる。また、呼制御プロトコルとしてＳＩＰを用いた場合について示したが、Ｈ．３２３、ＭＧＣＰ等のプロトコルを用いてもよい。
【００５５】
実施の形態６．
実施の形態５では、有線による通信を利用した場合について示したが、本発明の実施の形態６では、無線通信を利用する方式について示す。実施の形態６に係るゲートウェイ装置の構成は、実施の形態１と同様であり、図２に示すとおりである。
【００５６】
図２４は、クライアント端末１１とゲートウェイ装置５０間において、無線通信が利用された場合の例である。図２３と同様にリンクダウンを行う意味で、無線ＬＡＮにおけるアクセスポイントの識別子であるＳＳＩＤ（Ｓｅｒｖｉｃｅ Ｓｅｔ Ｉｄｅｎｔｉｆｉｅｒ）を変更などすることにより、クライアント端末からの通信を拒否し、クライアント端末からの通信を発生させないようにする。再度グローバル網４０に対して申請が可能となる状態となった後に、クライアント端末１１からのＳＳＩＤを元に戻す変更を行い、クライアント端末１１からの要求を再度受け付けるようにする。そして、図３に示す場合と同様にＴＣＰによる接続を確立し、通信を行う。この方法はクライアント側だけでなくサーバ側３１とゲートウェイ装置５２間においても同様となる。
【００５７】
本発明の実施の形態６に係るゲートウェイ装置では、以上のような構成をしているため無線通信を用いるネットワークにおいて、クライアント端末が呼制御プロトコルに対応していない場合であっても、無用な通信の再要求を実施しないという効果が得られる。
【００５８】
ここでは、中継通信装置としてゲートウェイ装置を用いた場合について示したが、ゲートウェイ装置のほか、ＩＰパケットを中継できる装置（例えばルータ等）であっても同様の効果が得られる。また、呼制御プロトコルとしてＳＩＰを用いた場合について示したが、Ｈ．３２３、ＭＧＣＰ等のプロトコルを用いてもよい。
【符号の説明】
【００５９】
１０ プライベート網、１１，１２ クライアント端末、２０ プライベート網、２１ サーバ端末、３０ プライベート網、３１ サーバ端末、４０ グローバル網、４１ ＳＩＰサーバ、５０〜５２ ゲートウェイ装置、５０１ ＬＡＮインタフェース、５０２ ＷＡＮインタフェース、５０３ セッション制御部、５０４ 通信プロトコル解析部、５０５ エラー解析部、５０６ エラー応答部、５０７ タイマ計算部
【特許請求の範囲】
【請求項１】
呼制御プロトコルに対応するグローバル網と、前記呼制御プロトコルに対応していない端末またはサーバを含むプライベート網とを連結する中継通信装置であって、
前記端末またはサーバから通信要求を受け、前記グローバル網内に呼を確立するセッション制御部と、
前記グローバル網から前記呼制御プロトコルによるエラー通知を受け取った場合、前記端末またはサーバが解釈可能な通信プロトコルのエラー通知に変換し、前記端末又はサーバに送信するエラー応答部と、
を備えることを特徴とする中継通信装置。
【請求項２】
前記エラー応答部は、前記端末またはサーバに対し、通信要求信号の再送を止めるためのエラー通知を行うことを特徴とする請求項１記載の中継通信装置。
【請求項３】
前記エラー応答部は、前記端末またはサーバに対し、通信要求信号の再送可能な時間を通知することを特徴とする請求項２記載の中継通信装置。
【請求項４】
予め設定された、前記端末またはサーバの通信終了から、前記グローバル網内の呼切断要求が発生するまでの時間と、
前記端末またはサーバの通信終了から、前記エラー応答部が前記グローバル網からのエラー通知を受け取るまでの時間とから、
前記再送可能な時間を算出するタイマ計算部を備えることを特徴とする請求項３記載の中継通信装置。
【請求項５】
前記グローバル網からのエラー通知は、エラーの内容を示すエラー情報を含み、
前記エラー応答部は、前記エラー情報に基づいて前記再送可能な時間を通知すること、
を特徴とする請求項３記載の中継通信装置。
【請求項６】
呼制御プロトコルに対応するグローバル網と、前記呼制御プロトコルに対応していない端末またはサーバを含むプライベート網と、を連結する中継通信装置であって、
前記端末またはサーバから通信要求信号を受け、前記グローバル網側への呼を確立して通信を行うセッション制御部と、
前記グローバル網から呼制御プロトコルによるエラー通知を受け取った場合、前記端末又はサーバとのリンクをダウンさせるエラー応答部と、
を備えることを特徴とする中継通信装置。
【請求項７】
中継通信装置が呼制御プロトコルに対応していない端末またはサーバから通信要求を受け、呼制御プロトコルに対応するグローバル網内に呼を確立するセッション制御ステップと、
前記中継通信装置が前記グローバル網からの呼制御プロトコルによるエラー通知を受け取った場合、前記端末またはサーバが解釈可能な通信プロトコルのエラー通知を生成し、前記端末またはサーバへ送信するエラー応答ステップと、
を備えることを特徴とする通信制御方法。
【請求項１】
呼制御プロトコルに対応するグローバル網と、前記呼制御プロトコルに対応していない端末またはサーバを含むプライベート網とを連結する中継通信装置であって、
前記端末またはサーバから通信要求を受け、前記グローバル網内に呼を確立するセッション制御部と、
前記グローバル網から前記呼制御プロトコルによるエラー通知を受け取った場合、前記端末またはサーバが解釈可能な通信プロトコルのエラー通知に変換し、前記端末又はサーバに送信するエラー応答部と、
を備えることを特徴とする中継通信装置。
【請求項２】
前記エラー応答部は、前記端末またはサーバに対し、通信要求信号の再送を止めるためのエラー通知を行うことを特徴とする請求項１記載の中継通信装置。
【請求項３】
前記エラー応答部は、前記端末またはサーバに対し、通信要求信号の再送可能な時間を通知することを特徴とする請求項２記載の中継通信装置。
【請求項４】
予め設定された、前記端末またはサーバの通信終了から、前記グローバル網内の呼切断要求が発生するまでの時間と、
前記端末またはサーバの通信終了から、前記エラー応答部が前記グローバル網からのエラー通知を受け取るまでの時間とから、
前記再送可能な時間を算出するタイマ計算部を備えることを特徴とする請求項３記載の中継通信装置。
【請求項５】
前記グローバル網からのエラー通知は、エラーの内容を示すエラー情報を含み、
前記エラー応答部は、前記エラー情報に基づいて前記再送可能な時間を通知すること、
を特徴とする請求項３記載の中継通信装置。
【請求項６】
呼制御プロトコルに対応するグローバル網と、前記呼制御プロトコルに対応していない端末またはサーバを含むプライベート網と、を連結する中継通信装置であって、
前記端末またはサーバから通信要求信号を受け、前記グローバル網側への呼を確立して通信を行うセッション制御部と、
前記グローバル網から呼制御プロトコルによるエラー通知を受け取った場合、前記端末又はサーバとのリンクをダウンさせるエラー応答部と、
を備えることを特徴とする中継通信装置。
【請求項７】
中継通信装置が呼制御プロトコルに対応していない端末またはサーバから通信要求を受け、呼制御プロトコルに対応するグローバル網内に呼を確立するセッション制御ステップと、
前記中継通信装置が前記グローバル網からの呼制御プロトコルによるエラー通知を受け取った場合、前記端末またはサーバが解釈可能な通信プロトコルのエラー通知を生成し、前記端末またはサーバへ送信するエラー応答ステップと、
を備えることを特徴とする通信制御方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【公開番号】特開２０１１−１４７０６１（Ｐ２０１１−１４７０６１Ａ）
【公開日】平成２３年７月２８日（２０１１．７．２８）
【国際特許分類】
【出願番号】特願２０１０−７９８５（Ｐ２０１０−７９８５）
【出願日】平成２２年１月１８日（２０１０．１．１８）
【出願人】（０００００６０１３）三菱電機株式会社 (33,312)
【Ｆターム（参考）】
【公開日】平成２３年７月２８日（２０１１．７．２８）
【国際特許分類】
【出願日】平成２２年１月１８日（２０１０．１．１８）
【出願人】（０００００６０１３）三菱電機株式会社 (33,312)
【Ｆターム（参考）】
[ Back to top ]