(57)【要約】【課題】ＴＣＰおよびＵＤＰの課題を同時に解決し、通信端末数や処理能力に応じて柔軟に対応することができるネットワークを実現する。【解決手段】データパケットの送信側の端末がデータパケットをデータパケットの受信側の端末に送信し、このデータパケットの受信側の端末がデータパケットを受信すると、所定の確率に従って受信確認パケットをデータパケットの送信側の端末に送信し、このデータパケットの送信側の端末が所定の時間内に受信確認パケットを受信しなければデータパケットをデータパケットの受信側の端末に再送信する。また、データパケットの送信側の端末が受信確認パケットを受信しなければ、再送信は所定の上限回数を超えない範囲で複数回行われるようにする。【選択図】図２
2008072466.tif 000002
【特許請求の範囲】
【請求項１】
複数の端末が相互通信可能なネットワークに接続され、第１の端末から第２の端末にデータパケットを送信する通信システムにおいて、
前記第２の端末は、データパケットを受信すると所定の確率に従って受信確認パケットを前記第１の端末に送信する手段を備え、
前記第１の端末は、所定の時間内に受信確認パケットを受信しなければ、データパケットを前記第２の端末に再送信する手段を備えた
ことを特徴とする通信システム。
【請求項２】
前記再送信する手段は、受信確認パケットを受信しなければ、データパケットを前記第２の端末に所定の上限回数を超えない範囲で複数回再送信する手段を備えた請求項１記載の通信システム。
【請求項３】
複数の端末が相互通信可能なネットワークに接続され、第１の端末から第２の端末にデータパケットを送信する通信システムの前記第２の端末において、
データパケットを受信すると所定の確率に従って受信確認パケットを前記送信側の端末に送信する手段を備えた
ことを特徴とする端末。
【請求項４】
複数の端末が相互通信可能なネットワークに接続され、第１の端末から第２の端末にデータパケットを送信する通信システムの前記第１の端末において、
所定の時間内に受信確認パケットを受信しなければ、データパケットを前記第２の端末に再送信する手段を備え、
この再送信する手段は、受信確認パケットを受信しなければ、データパケットを前記第２の端末に所定の上限回数を超えない範囲で複数回再送信する手段を備えた
ことを特徴とする端末。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークを介して接続される複数の端末間の通信に利用する。特に、データパケットの再送信制御技術に関する。
【背景技術】
【０００２】
インターネットでは、信頼性のある通信を行うために、非特許文献１が定めるＴＣＰ(Transmission
Control Protocol)という通信方式が広く用いられている。この方式では、データパケットを受信した端末は、受信確認パケットを必ず送信する。非特許文献１のｐ．４「Ｒｅｌｉａｂｉｌｉｔｙ」には「受信側のＴＣＰプロセスから、受信した旨（ｐｏｓｉｔｉｖｅ）を表すＡＣＫ信号を要求する（ｒｅｑｕｉｒｉｎｇ  ａ  ｐｏｓｉｔｉｖｅ  ａｃｋｎｏｗｌｅｄｇｍｅｎｔ（ＡＣＫ）ｆｒｏｍ  ｔｈｅ  ｒｅｃｅｉｖｉｎｇ  ＴＣＰ．）」ことが記載されている。
【０００３】
一方、非特許文献２が定めるＵＤＰ(User Datagram Protocol)という通信方式は、受信確認を全く行わない。
【０００４】
ここで、従来のＴＣＰについて図７および図８を参照して簡単に説明する。図７は通信システムの構成例を示す図である。図８はＴＣＰの通信手順を示すシーケンス図である。
【０００５】
図７に示すように、端末１〜３がネットワーク４に接続されている。端末１から端末２、３にデータパケットを送信する状況を考える。図８に示すように、端末１が端末２、３にデータパケットを送信する（Ｓ４０、Ｓ４１）。端末２、３は、データパケットを受信すると、受信確認パケットを送信する（Ｓ４２、Ｓ４３）。端末１は、端末２、３から受信確認パケットを受信する。
【０００６】
次に、端末１が二つ目のデータパケットを送信する（Ｓ４４、Ｓ４５）。今度は、端末２へのパケットが何らかの理由で届かなかったとする。すると、端末３は、端末１に対して受信確認パケットを送信（Ｓ４６）するが、端末２は、端末１に対して受信確認パケットを送信しないので、端末１は、端末２から受信確認パケットを受信できない。
【０００７】
ある定められた時間を待機しても受信確認パケットが届かない場合には、端末１は、端末２に対してデータパケットを再送信する（Ｓ４７）。今度は、端末２はデータパケットを受信したので端末１に対して受信確認パケットを送信する（Ｓ４８）。このように、再送信は、受信確認パケットを受信するまで、繰り返し行われる。
【０００８】
ＴＣＰでは、送信した全てのデータパケットに対する受信確認パケットを受信しなければならない（実際には、複数のデータパケットに対してまとめて受信確認を送信する方式も提案されているが、受信確認パケットの受信が必須であることに変わりはない）。
【０００９】
なお、実際には、通信開始および終了時に特別な処理が行われるが、それについては説明を省略した。
【００１０】
次に、従来のＵＤＰについて図９を参照して簡単に説明する。図９はＵＤＰの通信手順を示すシーケンス図である。図９では、端末１が端末２、３にデータパケットを送信する。
【００１１】
図９に示すように、端末１が送信した二つのデータパケットが（Ｓ５０〜Ｓ５３）、端末２に届かなかったとする（Ｓ５２）。ＵＤＰでは、このように消失してしまったパケットを復旧することができない。
【００１２】
【非特許文献１】ＩＥＴＦ  Ｒｅｑｕｅｓｔ  ｆｏｒ  Ｃｏｍｍｅｎｔｓ  ７９３
【非特許文献２】ＩＥＴＦ  Ｒｅｑｕｅｓｔ  ｆｏｒ  Ｃｏｍｍｅｎｔｓ  ７６８
【発明の開示】
【発明が解決しようとする課題】
【００１３】
ＴＣＰでは、多くの端末に対してデータパケットを送信した端末は、多くの受信確認パケットを受信することになる。この受信負荷により、同時に通信できる端末数が制限されることになる。
【００１４】
一方、ＵＤＰでは、同時に通信できる端末数は多くなるが、信頼性のある通信を行うことはできない。
【００１５】
また、この二つの通信方式は異なる方式として実装されなければならない。
【００１６】
本発明は、このような背景の下に行われたものであって、ＴＣＰおよびＵＤＰの課題を同時に解決し、通信端末数や処理能力に応じて柔軟に対応することができるネットワークを実現できる通信システムを提供することを目的とする。
【課題を解決するための手段】
【００１７】
本発明は、第１の端末がデータパケットを第２の端末に送信し、この第２の端末がデータパケットを受信すると、所定の確率に従って受信確認パケットを第１の端末に送信し、この第１の端末が所定の時間内に受信確認パケットを受信しなければデータパケットを第２の端末に再送信することを特徴とする。また、第１の端末が受信確認パケットを受信しなければ、再送信は所定の上限回数を超えない範囲で複数回行われるようにすることができる。
【００１８】
これにより、通信の信頼性を保ちつつ、第１の端末における受信確認パケットを受信する負荷を軽減することができる。ただし、データパケットの送信負荷は増加するので、送信負荷よりも受信負荷の方が大きい場合に適する。
【００１９】
また、受信確認パケットの送信確率を０〜１００％の間で変化させることにより、ＵＤＰおよびＴＣＰの双方に対応することができる。
【００２０】
すなわち、本発明は、複数の端末が相互通信可能なネットワークに接続され、第１の端末から第２の端末にデータパケットを送信する通信システムであって、本発明の特徴とするところは、前記第２の端末は、データパケットを受信すると所定の確率に従って受信確認パケットを前記第１の端末に送信する手段を備え、前記第１の端末は、所定の時間内に受信確認パケットを受信しなければ、データパケットを前記第２の端末に再送信する手段を備えたところにある。
【００２１】
さらに、前記再送信する手段は、受信確認パケットを受信しなければ、データパケットを前記第２の端末に所定の上限回数を超えない範囲で複数回再送信する手段を備えることができる。
【００２２】
また、本発明を前記第２の端末の観点から観ると、本発明は、複数の端末が相互通信可能なネットワークに接続され、第１の端末から第２の端末にデータパケットを送信する通信システムの前記第２の端末であって、データパケットを受信すると所定の確率に従って受信確認パケットを前記第１の端末に送信する手段を備えたことを特徴とする。
【００２３】
また、本発明を第１の端末の観点から観ると、本発明は、複数の端末が相互通信可能なネットワークに接続され、第１の端末から第２の端末にデータパケットを送信する通信システムの前記第１の端末であって、所定の時間内に受信確認パケットを受信しなければ、データパケットを前記第２の端末に再送信する手段を備え、この再送信する手段は、受信確認パケットを受信しなければ、データパケットを前記第２の端末に所定の上限回数を超えない範囲で複数回再送信する手段を備えたことを特徴とする。
【発明の効果】
【００２４】
本発明によれば、単一の通信方式でありながら、パラメータを調整することにより、ＴＣＰおよびＵＤＰへの要求を満たすことができる。これにより、通信端末数や処理能力に応じて柔軟に対応することができるネットワークを実現できる。
【発明を実施するための最良の形態】
【００２５】
本発明の通信システムにおける通信手順の実施例を図１のシーケンス図を用いて説明する。この例では、受信確認パケットを送信する確率を５０％とする。例えば、データパケットを受信する端末は０．０〜１．０の乱数を発生し、０．５未満であれば受信確認パケットを送信する。
【００２６】
５０％という確率値は、事前に設定しておいてもよいし、データパケットによって指示してもよい。この方式では、ごく稀に、いつまで経っても受信確認パケットを送信しないことがある。そのような場合に備えて、データパケットを送信する端末には、再送信回数の上限値を定めておく。この例では“２”とする。
【００２７】
図１に示すように、端末１が端末２、３にデータパケットを送信する（Ｓ１、Ｓ２）。端末２、３は、データパケットを受信すると乱数を発生させ、受信確認パケットを送信するか否かを決定する。この例では、端末２、３ともに受信確認パケットを送信している（Ｓ３、Ｓ４）。端末１は、端末２、３から受信確認パケットを受信したので再送信を行わない。
【００２８】
次に、端末１が二つ目のデータパケットを送信する（Ｓ５、Ｓ６）。端末２はデータパケットを受信し、乱数を発生し「受信確認パケットを送信しない」と決定したとする。すると、端末１はＴＣＰのようにしばらく待ってからデータパケットを再送信する（Ｓ８）。端末２は再びデータパケットを受信し、乱数を発生し、再び「受信確認パケットを送信しない」と決定したとする。端末１はデータパケットを再送信する（Ｓ９）。ここで再送信回数が上限の“２”に達したため、データパケットの再送信を停止する。
【００２９】
なお、端末３はデータパケットを受信し、乱数を発生し「受信確認パケットを送信する」と決定して端末１に対して受信確認パケットを送信する（Ｓ７）。これにより、端末１から端末３へのデータパケットの再送信は行われない。
【００３０】
ＴＣＰの例に比べて、受信確認パケットの数が減り、再送信されたデータパケットの数が増えている。このことにより、端末１の受信負荷が送信負荷より大きいときには、本実施例の通信手順が有効であることがわかる。
【００３１】
ユーザ空間への割込み処理を伴う受信処理は、送信処理より重いことがある。また、受信についてはタイミングを選べない（いつパケットが送られてくるかわからない）のに対し、送信については送信タイミングを選べることから、送信処理は余裕のあるときに行うことができる。また、端末１に向かう回線容量が小さいときにも、本実施例の通信手順は有効となる。
【００３２】
さらに、本実施例の通信手順を映像音声会議システムに適用した場合には、大きな効果が期待できる。すなわち、映像音声会議システムでは、一人の発言者のメッセージを多数の会議参加者に送信する。このときの送信負荷は、マルチキャストアドレス等を利用すれば、さほど大きくはない。
【００３３】
一方、発言者からのメッセージを受信した多数の会議参加者の端末から送信される受信確認パケットを一人の発言者の端末が全て受信処理することになるので、発言者の端末の受信負荷が著しく増加してしまう。
【００３４】
本実施例の通信手順を映像音声会議システムに適用した場合には、このような受信負荷の増加を抑えつつ、ＵＤＰと比較して信頼性の高い通信を実現することができる。
【００３５】
なお、ＴＣＰと異なり、本実施例の通信手順にはデータパケットが届かない状況が発生し得る。これは、ＴＣＰが１００％受信確認パケットを要求するのに対し、本実施例の通信手順では要求しないため、受信確認パケットを返さなかった理由が「乱数の結果」なのか「データパケットが届かなかったから」なのか分からないためである。できる限り確実にデータを届けたいが、同時に通信負荷も抑えたいような状況に、本実施例の通信手順は有効である。
【００３６】
以下の説明では、データパケットの送信側の端末を単に「送信側の端末」と呼び、データパケットの受信側の端末を単に「受信側の端末」と呼ぶことにする。
【００３７】
図２に送信側の端末１のブロック図を示し、図３に送信側の端末１におけるデータパケット記憶部１４の処理手順のフローチャートを示し、図４に送信側の端末１における受信確認チェックリスト保持部１５の処理手順のフローチャートを示す。
【００３８】
データパケット生成部１１によってパケットが生成されると、生成されたパケットは、いったん、データパケット記憶部１４に記憶される。データパケット記憶部１４は、受信確認チェックリスト保持部１５から受信確認を受け取っていない受信側の端末に対し、送信部１６からデータパケットを送信する（Ｓ１０）。
【００３９】
受信確認チェックリスト保持部１５は、受信部１７から受信確認パケットを受信すると（Ｓ２０）、受信確認パケットを送信した受信側の端末をチェックする（Ｓ２１）。このチェックの結果は、データパケット記憶部１４に通知される（Ｓ２２）。受信確認チェックリスト保持部１５が保持する受信確認チェックリスト１８は、端末の識別情報（端末ＩＤ）に対応して状態が記録される。図２の例では、受信確認パケットを受信した場合には状態が「済」となり、受信確認パケットを未受信の場合には状態が「未」となっている。
【００４０】
データパケット記憶部１４は、受信確認チェックリスト保持部１５から受信確認を受け取っていない受信側の端末に対し、送信部１６からデータパケットを送信（Ｓ１０）した後、再送信回数カウンタ１３に対し、送信結果を通知する。
【００４１】
再送信回数カウンタ１３は、この通知を受け取ると、当該受信側の端末に対応するカウント値を“１”加算し、タイマ１２は、再送信回数カウンタ１３のカウント値が“１”加算された受信側の端末に対し、その時点から計時を開始し、設定時間経過後に、当該受信側の端末に対する再送信タイミングが到来した旨をデータパケット記憶部１４に通知する。
【００４２】
データパケット記憶部１４は、タイマ１２からの通知を受け取った時点で（Ｓ１２）、受信確認チェックリスト保持部１５からの通知を確認し、当該受信側の端末からの受信確認を受け取っていない場合には、送信部１６から当該受信側の端末に向けてデータパケットを再送信する（Ｓ１０）。
【００４３】
再送信が行われるとその結果は再送信回数カウンタ１３に通知され、再送信回数カウンタ１３は当該受信側の端末に対するカウント値をさらに“１”加算し、タイマ１２は計時を開始する。
【００４４】
ステップＳ１０〜Ｓ１２の手順は繰り返し実行されるが、再送信カウント値には上限が設けられており、カウント値が上限に達したときには（Ｓ１１）、受信確認が行われていなくても当該受信側の端末に対する再送信を打ち切る（Ｓ１３）。
【００４５】
図５に、受信側の端末２、３のブロック図を示し、図６に、受信側の端末２、３の処理手順のフローチャートを示す。受信側の端末２、３の受信部２３がデータパケットを受信すると（Ｓ３０）、乱数発生部２４は乱数を発生させ（Ｓ３１）、乱数が０．５未満であれば（Ｓ３２）、受信確認パケット生成部２１は受信確認パケットを生成し、送信部２２から受信確認パケットを送信する（Ｓ３３）。乱数が０．５以上であれば（Ｓ３２）、受信確認パケットの生成は行わない。
【００４６】
本実施例では、説明を分り易くするために、送信側の端末１と受信側の端末２、３とを異なる構成として説明したが、実際には、一つの端末が送信側の端末１および受信側の端末２、３の構成を併せて有し、一つの端末が、あるときには送信側の端末となり、また、あるときには受信側の端末となる。
【産業上の利用可能性】
【００４７】
本発明によれば、通信端末数や処理能力に応じて柔軟に対応することができるネットワークを構成することができるため、ネットワークユーザおよび管理者の双方の利便性を向上させることができる。例えば、前述したような映像音声会議システムのように、端末の送信負荷よりも受信負荷の方が大きくなる通信に利用するのに適する。
【図面の簡単な説明】
【００４８】
【図１】本発明の通信システムにおける通信手順の実施例を示すシーケンス図。
【図２】本発明の通信システムにおける送信側の端末のブロック図。
【図３】本発明の通信システムにおける送信側の端末のデータパケット記憶部の処理手順を示すフローチャート。
【図４】本発明の通信システムにおける送信側の端末の受信確認チェックリスト保持部の処理手順を示すフローチャート。
【図５】本発明の通信システムにおける受信側の端末のブロック図。
【図６】本発明の通信システムにおける受信側の端末の処理手順を示すフローチャート。
【図７】ネットワーク構成を示す図。
【図８】ＴＣＰの通信手順を示すシーケンス図。
【図９】ＵＤＰの通信手順を示すシーケンス図。
【符号の説明】
【００４９】
１〜３  端末
４  ネットワーク
１１  データパケット生成部
１２  タイマ
１３  再送信回数カウンタ
１４  データパケット記憶部
１５  受信確認チェックリスト保持部
１６、２２  送信部
１７、２３  受信部
１８  受信確認チェックリスト
２１  受信確認パケット生成部
２４  乱数発生部
【図１】
2008072466.tif 000003
【図２】
2008072466.tif 000004
【図３】
2008072466.tif 000005
【図４】
2008072466.tif 000006
【図５】
2008072466.tif 000007
【図６】
2008072466.tif 000008
【図７】
2008072466.tif 000009
【図８】
2008072466.tif 000010
【図９】
2008072466.tif 000011