(57)【要約】【課題】ＵＤＰパケットを用いるアプリケーション間でゲートウェイを介して通信する場合でも、通信遅延を抑制することのできる通信装置および通信プログラムを提供する。【解決手段】通信装置は、ローカルアプリケーションから送信されたＵＤＰパケットを取得する取得部と、ローカル端末とゲートウェイとの間に複数本のＴＣＰ接続を確立する接続部と、取得したＵＤＰパケットからＴＣＰパケットを生成し、ローカル端末からゲートウェイへＴＣＰパケットをＴＣＰ接続により送信する通信部とを備える。【選択図】図１
2014135653.tif 000002
【特許請求の範囲】
【請求項１】
ローカルエリアネットワークに接続されたローカル端末上のローカルアプリケーションをリモートネットワークに接続されたリモート端末上のリモートアプリケーションと、前記ローカルエリアネットワークと前記リモートネットワークとの間に配置されたゲートウェイを介して通信させるための通信装置であって、
前記ローカルアプリケーションから送信されたＵＤＰ（User Datagram Protocol）パケットを取得する取得部と、
前記ローカル端末と前記ゲートウェイとの間に複数本のＴＣＰ（Transmission Control Program）接続を確立する接続部と、
前記取得したＵＤＰパケットからＴＣＰパケットを生成し、前記ローカル端末から前記ゲートウェイへ前記ＴＣＰパケットを前記ＴＣＰ接続により送信する通信部と
を備える通信装置。
【請求項２】
前記接続部は、前記リモート端末の数より多くなるよう、確立するＴＣＰ接続の本数を決定する請求項１に記載の通信装置。
【請求項３】
前記接続部は、複数のリモート端末それぞれに対して、確立するＴＣＰ接続の本数を決定する請求項２に記載の通信装置。
【請求項４】
前記接続部は、前記リモート端末の数に２以上の正数を乗じることで、確立するＴＣＰ接続の本数を決定する請求項２に記載の通信装置。
【請求項５】
前記接続部は、前記ローカルアプリケーションの使用するＵＤＰポートの数に応じて、確立するＴＣＰ接続の本数を決定する請求項１〜請求項４のいずれか１項に記載の通信装置。
【請求項６】
前記接続部は、前記ローカルアプリケーションの使用するＵＤＰポートの種類に応じて、確立するＴＣＰ接続の本数を決定する請求項１〜請求項５のいずれか１項に記載の通信装置。
【請求項７】
前記接続部は、前記ローカルアプリケーションから送信されるＵＤＰパケットのパケット数に応じて、確立するＴＣＰ接続の本数を決定する請求項１〜請求項６のいずれか１項に記載の通信装置。
【請求項８】
前記接続部は、前記取得部により取得されＵＤＰパケットのうち、前記ＵＤＰパケットから生成された前記ＴＣＰパケットが前記通信部により送信されていないパケットの数に応じて、確立するＴＣＰ接続の本数を決定する請求項１〜請求項７のいずれか１項に記載の通信装置。
【請求項９】
請求項１〜請求項９のいずれか１項に記載の通信装置としてコンピュータを機能させるための通信プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ローカルエリアネットワークに接続された端末上のアプリケーションをリモートネットワークに接続された端末上のアプリケーションとゲートウェイを介して通信させるための通信装置、および通信プログラムに関する。
【背景技術】
【０００２】
ローカルエリアネットワークに接続された端末同士で通信することを前提としたアプリケーションでも、そのアプリケーションを利用して、リモートネットワークに接続された端末上のアプリケーションと通信したい場合がある。例えば社内用のテレビ会議アプリケーションを使用している場合に、出張者が社外でも同じアプリケーションを使ってテレビ会議に参加できれば便利である。社内ネットワークに接続された端末上のアプリケーションが、出張先にあるリモートネットワークに接続された端末上のアプリケーションと通信するために、社内ネットワークとリモートネットワークとの間にDeMilitarized Zone（ＤＭＺ）セグメントを設け、そのＤＭＺにゲートウェイを配置することができる。社内ネットワークに接続された端末とリモートネットワークに接続された端末とはゲートウェイを介して通信する。このとき、ゲートウェイと端末との間の通信には、Transmission Control Protocol（ＴＣＰ)接続が用いられる。
【０００３】
一方、テレビ会議用アプリケーションのようにリアルタイムに映像を伝送するアプリケーションは、遅延低減のためにUser Datagram Protocol（ＵＤＰ）を用いて通信することが多い。例えば特許文献１は、低遅延伝送が要求されるときにはＴＣＰよりもＵＤＰを用いることを記載している。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１０−１６６１９１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ＵＤＰパケットを用いるアプリケーション間の通信を、上記のようにゲートウェイを介してするとき、ＴＣＰ通信によるオーバーヘッドのために送信遅延が発生・蓄積し、通信品質が低下する可能性がある。
【０００６】
本発明は、このような課題に鑑みてなされたものであり、ＵＤＰパケットを用いるアプリケーション間でゲートウェイを介して通信する場合でも、通信遅延を抑制することのできる通信装置、および通信プログラムを提供する。
【課題を解決するための手段】
【０００７】
本発明の提供する通信装置は、ローカルエリアネットワークに接続されたローカル端末上のローカルアプリケーションをリモートネットワークに接続されたリモート端末上のリモートアプリケーションと、ローカルエリアネットワークとリモートネットワークとの間に配置されたゲートウェイを介して通信させるための通信装置であって、ローカルアプリケーションから送信されたＵＤＰパケットを取得する取得部と、ローカル端末とゲートウェイとの間に複数本のＴＣＰ接続を確立する接続部と、取得したＵＤＰパケットからＴＣＰパケットを生成し、ローカル端末からゲートウェイへＴＣＰパケットをＴＣＰ接続により送信する通信部とを備える。
【０００８】
他の態様において、本発明は、上記のような通信装置としてコンピュータを機能させるための通信プログラムを提供する。
【発明の効果】
【０００９】
本発明によれば、アプリケーションから送信されたＵＤＰパケットの通信において、ローカル端末とゲートウェイとの間に確立された複数本のＴＣＰ接続を用いることが可能であるため、通信遅延を低減することができる。
【図面の簡単な説明】
【００１０】
【図１】本発明の実施の形態に係る映像伝送システムの全体構成を示す図である。
【図２】本発明の実施の形態に係る通信装置の機能的構成を示す図である。
【図３】通信装置によるパケット変更をより詳細に説明するための図である。
【発明を実施するための形態】
【００１１】
図１は本発明の実施の形態に係るテレビ会議システムの全体構成を示す図である。テレビ会議システム１００において、ローカルエリアネットワーク１０１に接続されたローカル端末１０２および１０３、並びにリモートネットワーク１０４および１０５に接続されたリモート端末１０６及び１０７の間でテレビ会議のための映像や音声等のデータ伝送が行われる。これらの端末には、テレビ会議アプリケーション１０８および１０９が導入される。テレビ会議アプリケーション１０８および１０９は、映像データをＵＤＰパケットで他のテレビ会議アプリケーションに伝送する。ローカル端末上のテレビ会議アプリケーションが、リモート端末上のテレビ会議アプリケーションに映像データを伝送する場合、ローカル端末はゲートウェイ１１０を介してリモート端末と通信する。
【００１２】
ゲートウェイ１１０はＤＭＺセグメント１１１に設置されている。ＤＭＺはファイアウォール１１２および１１３で囲まれており、ゲートウェイ１１０は、ローカルエリアネットワーク１０１のセキュリティを確保しながら、ローカル端末とリモート端末が通信するのに用いられる。ローカル端末およびリモート端末はゲートウェイ１１０とＴＣＰ接続により通信する。ゲートウェイ１１０を介して、テレビ会議アプリケーションにより送信されるＵＤＰパケットを伝送するために通信プログラム１１４および１１５が用いられる。
【００１３】
図２は本発明の実施の形態に係る通信装置の機能的構成を示す図である。通信プログラムを端末の演算部に実行させることで端末は本発明の実施の形態に係る通信装置２００として機能する。図２はローカル端末１０２の通信装置２００を示す。この例では、ローカル端末１０２はリモート端末１０６とテレビ会議のために通信する。通信装置２００は、テレビ会議アプリケーション１０８からのＵＤＰパケットをＴＣＰパケットにカプセル化してゲートウェイ１１０に送信する。ＴＣＰパケットへのカプセル化に伴うオーバーヘッドによる送信遅延を低減するため、通信装置２００は、ゲートウェイ１１０との間に複数本のＴＣＰ接続を確立する。
【００１４】
通信装置２００は、取得部２０１と、接続部２０２と、通信部２０３とを備える。取得部２０１は、テレビ会議アプリケーション１０８から送信されたＵＤＰパケットを取得する。接続部２０２は、ローカル端末１０２とゲートウェイ１１０との間に複数本のＴＣＰ接続を確立する。通信部２０３は、取得したＵＤＰパケットからＴＣＰパケットを生成し、ローカル端末１０２からゲートウェイ１１０へＴＣＰパケットをＴＣＰ接続により送信する。
【００１５】
取得部２０１の機能は、端末に導入されたドライバソフトウェアにより実現することができる。取得部２０１は、テレビ会議アプリケーションから送信されたＵＤＰパケットをフックする。本実施の形態において、取得部２０１は、予め定められた宛先ポートを利用するＵＤＰパケットを検出すると、ＵＤＰパケットを取得する。ＵＤＰパケットの送信先アドレスはリモート端末１０６のＩＰアドレスであり、宛先ポートはテレビ会議アプリケーション１０９が利用するポートである。ＵＤＰパケットの送信元アドレスはローカル端末１０２のＩＰアドレスであり、送信元ポートはテレビ会議アプリケーション１０８が利用するポートである。
【００１６】
取得部２０１は、ＵＤＰパケットを取得すると、ＵＤＰパケットの送信先ＩＰアドレスおよびポート番号を、通信部２０３に割り当てたＩＰアドレスおよびポート番号に変更する。テレビ会議アプリケーション１０８自体は、相手のテレビ会議アプリケーション１０９を宛先とするＵＤＰパケットを送信すればよく、テレビ会議アプリケーション１０８が通信部２０３に割り当てたＩＰアドレスに宛先を設定する必要はない。取得部２０１は、ＵＤＰパケットの変更前の送信先ＩＰアドレスおよびポート番号を端末のメモリ等の記憶部に保持する。
【００１７】
接続部２０２は、本実施の形態では、宛先ポート８０番のＴＣＰパケットをゲートウェイ１１０に送信するにあたって、ゲートウェイ１１０に対して複数本のＴＣＰ接続を確立する。確立するＴＣＰ接続の本数は、種々の条件により接続部２０２が決定することができる。接続部２０２は、リモート端末の数より多くなるよう、確立するＴＣＰ接続の本数を決定することができる。ローカル端末１０２が映像データを伝送するリモート端末が図２のように一つであれば、接続部２０２は、２本以上のＴＣＰ接続を確立する。リモート端末が複数であれば、３本以上のＴＣＰ接続を確立する。例えばリモート端末の数に２以上の正数を乗じることで、確立するＴＣＰ接続の本数を接続部２０２は決定する。リモート端末が複数である場合、確立するＴＣＰ接続の本数は、端末ごとに同じであってもよいし、端末ごとに異なってもよい。接続部２０２は、複数のリモート端末それぞれに対して、確立するＴＣＰ接続の本数を決定することができる。
【００１８】
通信部２０３は、送信先ＩＰアドレスおよびポート番号を変更されたＵＤＰパケットを取得部２０１から受信する。通信部２０３は、取得部２０１により変更される前のＵＤＰパケットの送信先ＩＰアドレスおよびポート番号を復元するために、取得部２０１により保持されたＩＰアドレスおよびポート番号をApplication Programming Interface(ＡＰＩ)コールにより取得することができる。
【００１９】
通信部２０３は、送信先ＩＰアドレスおよびポート番号が復元されたＵＤＰパケット（ＩＰヘッダおよびＵＤＰヘッダを含む）をペイロードに格納したＴＣＰパケットを生成する。ＴＣＰパケットの送信先アドレスは、ゲートウェイ１０９のＩＰアドレスであり、ＴＣＰパケットの宛先ポートは、ここでは８０番である。
【００２０】
通信部２０３は、ゲートウェイ１１０に対して確立したＴＣＰ接続のいずれかにより、生成したＴＣＰパケットを送信する。通信部２０３は、一部のＴＣＰ接続が用いられていれば、他のＴＣＰ接続を用いてＴＣＰパケットを送信すればよい。これによって、ＴＣＰ通信に伴うオーバーヘッドによる伝送遅延を低減することができる。
【００２１】
ゲートウェイ１１０は、通信部２０３からＴＣＰパケットを受信すると、ＴＣＰパケットのペイロードからＵＤＰパケットを抽出する。そのＵＤＰパケットの送信先ＩＰアドレスを送信先ＩＰアドレスとし、そのＵＤＰパケットをペイロードに格納した別のＴＣＰパケットをゲートウェイ１１０は生成する。ゲートウェイ１１０は、生成した別のＴＣＰパケットを転送する。このＴＣＰパケットは、ここではリモート端末１０６によって受信される。
【００２２】
リモート端末１０６は、受信したＴＣＰパケットのペイロードに格納されたＵＤＰパケットを抽出し、抽出したＵＤＰパケットを当該リモート１０６端末上のテレビ会議アプリケーション１０９に送信する。テレビ会議アプリケーション１０９は、ＵＤＰパケットを受信する。これによって、ローカル端末１０２上のテレビ会議アプリケーション１０８とリモート１０６端末上のテレビ会議アプリケーション１０９とがゲートウェイ１１０を介して映像データを伝送する。
【００２３】
上述の実施の形態では、接続部は、リモート端末の数より多くなるよう、確立するＴＣＰ接続の本数を決定した。この場合、空いたＴＣＰ接続を使用して次々にパケットを転送するので遅延の発生・蓄積を低減できる。
【００２４】
テレビ会議アプリケーションの接続相手が複数ある場合、その数Ｎおよび正数ａを用いて、確立するＴＣＰ接続の本数は、ａ×Ｎと計算することができる。この場合、実際に会議を行っている相手の数に応じた数しか接続を確立しないのでリソースの無駄を低減できる。新しい接続先が発見された場合、新たにＴＣＰ接続を確立するまでの間、既存のＴＣＰ接続を利用する。これにより、接続待ち時間を抑制することができる。さらに接続部が接続相手ごとに接続数を決定し、係数ａを接続相手ごとに変えるようにしてもよい。相手のスペックやネットワーク状況に応じて接続数を細かく調整することが可能になる。
【００２５】
これらに代えてまたは加えて、テレビ会議アプリケーションの利用するポートに応じて、確立するＴＣＰ接続の本数を決定することができる。接続部は、例えば、テレビ会議アプリケーションから送信されるＵＤＰポートの数Ｕおよび係数ｂに応じて、ＴＣＰ接続の本数をｂ×Ｕのように決定する。これにより通信の種類が増えてもそれぞれに対して遅延の発生・蓄積を抑制することができる。係数ｂは、全ポート共通としてもよいし。ポートごとに設定してもよい。このとき一部の係数ｂは０であってもよい。ＵＤＰポートによっては利用頻度が少ない場合があり、無駄なＴＣＰ接続の確立を抑制するためである。
【００２６】
さらにアプリケーションから送信されるＵＤＰパケットの数に応じて、接続部は、確立するＴＣＰ接続の本数を決定することもできる。より具体的には、単位時間当たりのパケット数Ｔ、正数ｃ、ｄを用いて、ｃ＋ＤＴと決定する。このようにパケットの流量に応じてＴＣＰ接続の数を調整することで無駄なリソース消費を低減することができる。
【００２７】
さらに接続部は、取得されたＵＤＰパケットのうち、そのＵＤＰパケットに対するＴＣＰパケットが送信されていない数、すなわちＴＣＰパケット生成・送信待ちのＵＤＰパケットの数に応じて、確立するＴＣＰ接続の本数を決定するようにしてもよい。接続本数は、単位時間当たりの蓄積パケット数Ｌ、正数ｅ、ｆを用いて、ｅ＋ｆＬのように計算することができる。このようにＵＤＰパケットの処理滞留状況に応じて接続本数を調整することで、処理能力やネットワークの能力に応じて、リソースの無駄な消費を抑えつつ、遅延の発生・蓄積も低減することができる。
【００２８】
図３は通信装置によるパケット変更をより詳細に説明するための図である。この図は、ローカル端末ＰＣ１上のテレビ会議アプリケーションは、リモート端末ＰＣ２上のテレビ会議アプリケーション宛にＵＤＰパケット３０１を送信する例を示す。このＵＤＰパケット３０１において、送信元ＩＰアドレスは端末ＰＣ１のＩＰアドレスであり、送信先アドレスは端末ＰＣ２のＩＰアドレスであり、送信元ポートは送信元のテレビ会議アプリケーションが利用するポート「ＡＡＡ」であり、宛先ポートは相手のテレビ会議アプリケーションが利用するポート「ＢＢＢ」である。通信装置の取得部は、このＵＤＰパケット３０１を取得する。
【００２９】
取得部は、ＵＤＰパケット３０１の送信先ＩＰアドレス、宛先ポート、および送信元ポートを変更してＵＤＰパケット３０２を生成する。送信先ＩＰアドレスは通信部に割り当てたＩＰアドレス「ＸＸＸ」に、宛先ポートは通信部が利用するポート「ＬＬＬ」に、送信元ポートは、このパケット固有に接続部が定めた識別データ「ＩＤ１００１」にそれぞれ変更される。取得部は、識別データごとに変更前のデータ３０３を保持する。保持データ３０３は、識別データ「ＩＤ１００１」に、変更前の送信元ポート「ＡＡＡ」、送信先ＩＰアドレス「ＰＣ２」、宛先ポート「ＢＢＢ」を対応付けて保持する。取得部は、通信部宛のＵＤＰパケット３０２を送信する。
【００３０】
通信部は、ＵＤＰパケット３０２を受信すると、そのＵＤＰパケットからＴＣＰパケット３０４を生成する。通信部は、受信したＵＤＰパケット３０２の送信元パケットの値「ＩＤ１００１」を取得し、同じ値の識別データに対応する保持データ３０３から、変更前の送信元ポート、送信先ＩＰアドレス、および宛先ポートを取得する。これによって、通信部は、ＵＤＰパケット３０２からＵＤＰパケット３０１を復元する。通信部は、復元したＵＤＰパケットをペイロードに含むＴＣＰパケット３０４を生成する。ＴＣＰパケット３０４において、送信先ＩＰアドレスはゲートウェイのＩＰアドレスであり、宛先ポートは例えば「８０番」であり、送信元ＩＰアドレスはＰＣ１のＩＰアドレスであり、送信元ポートは通信部が利用するポートである。通信部は、ゲートウェイ宛のこのＴＣＰパケット３０４を送信する。
【００３１】
このように通信装置がパケット変更することで、ローカル端末上のテレビ会議アプリケーションはその動作を変更することなく、ゲートウェイを介して、リモート端末上のテレビ会議アプリケーションと通信することができる。この例では、ＵＤＰパケット３０２の送信元ポートに識別データの値を記述することで、各ＵＤＰパケットの復元を可能にしている。送信先ＩＰアドレスおよび送信先ポート番号は、相手先のテレビ会議アプリケーションが同じあれば、各パケットで同じになる。このため、これらの値では各パケットを識別できない。さらに送信元ＩＰアドレスも通常は同じになり、識別に使用できない。元々の送信元ポートを識別に利用できればよいが、相手先が異なる場合でも送信元ポート番号が同じになることがある。このため元々の送信元ポートも使用できない。そこで送信元ポートに識別データの値を記述することで、各パケットの識別を可能にしている。これによって復元を正確に行うことができ、テレビ会議アプリケーションは相手先アプリケーションと正しく通信することができる。しかしながら、識別データを各ＵＤＰパケット固有に定めると、保持データが増大するためメモリ消費量が多くなってしまう。そこで、ＵＤＰパケットごとではなく、送信先アドレスと宛先ポートの組合せごとに識別データを定め、その識別データを送信元ポートに記述するようにしてもよい。これによって、保持データの量を減らしながら、データ転送を正確にすることが可能となる。
【００３２】
上述の実施の形態では、テレビ会議システムに本発明を適用したが、これに限られるものではない。ＵＤＰパケットを送信するその他のアプリケーションに本発明を適用することも可能である。特にリアルタイム性があり転送レートが高いデータ、ストリームを授受するアプリケーションに有用である。
【００３３】
上述した実施の形態は本発明の技術的範囲を制限するものではなく、本発明の範囲内で種々の変形や応用が可能である。
【産業上の利用可能性】
【００３４】
本発明の通信装置および通信プログラムは、ＵＤＰパケットを用いるアプリケーション間でゲートウェイを介して通信する場合でも、通信遅延を抑制することができ、ＵＤＰパケットを利用した様々な通信に利用することができる。
【符号の説明】
【００３５】
１００  テレビ会議システム    １０１  ローカルエリアネットワーク
１０２、１０３  ローカル端末    １０４、１０５  リモートネットワーク
１０６、１０７  リモート端末    １０８、１０９  テレビ会議アプリケーション
１１０  ゲートウェイ    １１１  ＤＭＺセグメント
１１２、１１３  ファイアウォール    １１４、１１５  通信プログラム
【図１】
2014135653.tif 000003
【図２】
2014135653.tif 000004
【図３】
2014135653.tif 000005