JP4805072B2

JP4805072B2 - 通信システム

Info

Publication number: JP4805072B2
Application number: JP2006249511A
Authority: JP
Inventors: 武井上; 鑑豊島; 仁上松
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 2006-09-14
Filing date: 2006-09-14
Publication date: 2011-11-02
Anticipated expiration: 2026-09-14
Also published as: JP2008072466A

Description

本発明は、ネットワークを介して接続される複数の端末間の通信に利用する。特に、データパケットの再送信制御技術に関する。

インターネットでは、信頼性のある通信を行うために、非特許文献１が定めるＴＣＰ(Transmission
Control Protocol)という通信方式が広く用いられている。この方式では、データパケットを受信した端末は、受信確認パケットを必ず送信する。非特許文献１のｐ．４「Ｒｅｌｉａｂｉｌｉｔｙ」には「受信側のＴＣＰプロセスから、受信した旨（ｐｏｓｉｔｉｖｅ）を表すＡＣＫ信号を要求する（ｒｅｑｕｉｒｉｎｇａｐｏｓｉｔｉｖｅａｃｋｎｏｗｌｅｄｇｍｅｎｔ（ＡＣＫ）ｆｒｏｍｔｈｅｒｅｃｅｉｖｉｎｇＴＣＰ．）」ことが記載されている。

一方、非特許文献２が定めるＵＤＰ(User Datagram Protocol)という通信方式は、受信確認を全く行わない。

ここで、従来のＴＣＰについて図７および図８を参照して簡単に説明する。図７は通信システムの構成例を示す図である。図８はＴＣＰの通信手順を示すシーケンス図である。

図７に示すように、端末１〜３がネットワーク４に接続されている。端末１から端末２、３にデータパケットを送信する状況を考える。図８に示すように、端末１が端末２、３にデータパケットを送信する（Ｓ４０、Ｓ４１）。端末２、３は、データパケットを受信すると、受信確認パケットを送信する（Ｓ４２、Ｓ４３）。端末１は、端末２、３から受信確認パケットを受信する。

次に、端末１が二つ目のデータパケットを送信する（Ｓ４４、Ｓ４５）。今度は、端末２へのパケットが何らかの理由で届かなかったとする。すると、端末３は、端末１に対して受信確認パケットを送信（Ｓ４６）するが、端末２は、端末１に対して受信確認パケットを送信しないので、端末１は、端末２から受信確認パケットを受信できない。

ある定められた時間を待機しても受信確認パケットが届かない場合には、端末１は、端末２に対してデータパケットを再送信する（Ｓ４７）。今度は、端末２はデータパケットを受信したので端末１に対して受信確認パケットを送信する（Ｓ４８）。このように、再送信は、受信確認パケットを受信するまで、繰り返し行われる。

ＴＣＰでは、送信した全てのデータパケットに対する受信確認パケットを受信しなければならない（実際には、複数のデータパケットに対してまとめて受信確認を送信する方式も提案されているが、受信確認パケットの受信が必須であることに変わりはない）。

なお、実際には、通信開始および終了時に特別な処理が行われるが、それについては説明を省略した。

次に、従来のＵＤＰについて図９を参照して簡単に説明する。図９はＵＤＰの通信手順を示すシーケンス図である。図９では、端末１が端末２、３にデータパケットを送信する。

図９に示すように、端末１が送信した二つのデータパケットが（Ｓ５０〜Ｓ５３）、端末２に届かなかったとする（Ｓ５２）。ＵＤＰでは、このように消失してしまったパケットを復旧することができない。

ＩＥＴＦＲｅｑｕｅｓｔｆｏｒＣｏｍｍｅｎｔｓ７９３ＩＥＴＦＲｅｑｕｅｓｔｆｏｒＣｏｍｍｅｎｔｓ７６８

ＴＣＰでは、多くの端末に対してデータパケットを送信した端末は、多くの受信確認パケットを受信することになる。この受信負荷により、同時に通信できる端末数が制限されることになる。

一方、ＵＤＰでは、同時に通信できる端末数は多くなるが、信頼性のある通信を行うことはできない。

また、この二つの通信方式は異なる方式として実装されなければならない。

本発明は、このような背景の下に行われたものであって、ＴＣＰおよびＵＤＰの課題を同時に解決し、通信端末数や処理能力に応じて柔軟に対応することができるネットワークを実現できる通信システムを提供することを目的とする。

本発明は、第１の端末がデータパケットを第２の端末に送信し、この第２の端末がデータパケットを受信すると、所定の確率に従って受信確認パケットを第１の端末に送信し、この第１の端末が所定の時間内に受信確認パケットを受信しなければデータパケットを第２の端末に再送信することを特徴とする。また、第１の端末が受信確認パケットを受信しなければ、再送信は所定の上限回数を超えない範囲で複数回行われるようにすることができる。

これにより、通信の信頼性を保ちつつ、第１の端末における受信確認パケットを受信する負荷を軽減することができる。ただし、データパケットの送信負荷は増加するので、送信負荷よりも受信負荷の方が大きい場合に適する。

また、受信確認パケットの送信確率を０〜１００％の間で変化させることにより、ＵＤＰおよびＴＣＰの双方に対応することができる。

すなわち、本発明は、複数の端末が相互通信可能なネットワークに接続され、第１の端末から第２の端末にデータパケットを送信する通信システムであって、本発明の特徴とするところは、前記第２の端末は、データパケットを受信すると所定の確率に従って受信確認パケットを前記第１の端末に送信する手段を備え、前記第１の端末は、所定の時間内に受信確認パケットを受信しなければ、データパケットを前記第２の端末に再送信する手段を備えたところにある。

さらに、前記再送信する手段は、受信確認パケットを受信しなければ、データパケットを前記第２の端末に所定の上限回数を超えない範囲で複数回再送信する手段を備えることができる。

また、本発明を前記第２の端末の観点から観ると、本発明は、複数の端末が相互通信可能なネットワークに接続され、第１の端末から第２の端末にデータパケットを送信する通信システムの前記第２の端末であって、データパケットを受信すると所定の確率に従って受信確認パケットを前記第１の端末に送信する手段を備えたことを特徴とする。

また、本発明を第１の端末の観点から観ると、本発明は、複数の端末が相互通信可能なネットワークに接続され、第１の端末から第２の端末にデータパケットを送信する通信システムの前記第１の端末であって、所定の時間内に受信確認パケットを受信しなければ、データパケットを前記第２の端末に再送信する手段を備え、この再送信する手段は、受信確認パケットを受信しなければ、データパケットを前記第２の端末に所定の上限回数を超えない範囲で複数回再送信する手段を備えたことを特徴とする。

本発明によれば、単一の通信方式でありながら、パラメータを調整することにより、ＴＣＰおよびＵＤＰへの要求を満たすことができる。これにより、通信端末数や処理能力に応じて柔軟に対応することができるネットワークを実現できる。

本発明の通信システムにおける通信手順の実施例を図１のシーケンス図を用いて説明する。この例では、受信確認パケットを送信する確率を５０％とする。例えば、データパケットを受信する端末は０．０〜１．０の乱数を発生し、０．５未満であれば受信確認パケットを送信する。

５０％という確率値は、事前に設定しておいてもよいし、データパケットによって指示してもよい。この方式では、ごく稀に、いつまで経っても受信確認パケットを送信しないことがある。そのような場合に備えて、データパケットを送信する端末には、再送信回数の上限値を定めておく。この例では“２”とする。

図１に示すように、端末１が端末２、３にデータパケットを送信する（Ｓ１、Ｓ２）。端末２、３は、データパケットを受信すると乱数を発生させ、受信確認パケットを送信するか否かを決定する。この例では、端末２、３ともに受信確認パケットを送信している（Ｓ３、Ｓ４）。端末１は、端末２、３から受信確認パケットを受信したので再送信を行わない。

次に、端末１が二つ目のデータパケットを送信する（Ｓ５、Ｓ６）。端末２はデータパケットを受信し、乱数を発生し「受信確認パケットを送信しない」と決定したとする。すると、端末１はＴＣＰのようにしばらく待ってからデータパケットを再送信する（Ｓ８）。端末２は再びデータパケットを受信し、乱数を発生し、再び「受信確認パケットを送信しない」と決定したとする。端末１はデータパケットを再送信する（Ｓ９）。ここで再送信回数が上限の“２”に達したため、データパケットの再送信を停止する。

なお、端末３はデータパケットを受信し、乱数を発生し「受信確認パケットを送信する」と決定して端末１に対して受信確認パケットを送信する（Ｓ７）。これにより、端末１から端末３へのデータパケットの再送信は行われない。

ＴＣＰの例に比べて、受信確認パケットの数が減り、再送信されたデータパケットの数が増えている。このことにより、端末１の受信負荷が送信負荷より大きいときには、本実施例の通信手順が有効であることがわかる。

ユーザ空間への割込み処理を伴う受信処理は、送信処理より重いことがある。また、受信についてはタイミングを選べない（いつパケットが送られてくるかわからない）のに対し、送信については送信タイミングを選べることから、送信処理は余裕のあるときに行うことができる。また、端末１に向かう回線容量が小さいときにも、本実施例の通信手順は有効となる。

さらに、本実施例の通信手順を映像音声会議システムに適用した場合には、大きな効果が期待できる。すなわち、映像音声会議システムでは、一人の発言者のメッセージを多数の会議参加者に送信する。このときの送信負荷は、マルチキャストアドレス等を利用すれば、さほど大きくはない。

一方、発言者からのメッセージを受信した多数の会議参加者の端末から送信される受信確認パケットを一人の発言者の端末が全て受信処理することになるので、発言者の端末の受信負荷が著しく増加してしまう。

本実施例の通信手順を映像音声会議システムに適用した場合には、このような受信負荷の増加を抑えつつ、ＵＤＰと比較して信頼性の高い通信を実現することができる。

なお、ＴＣＰと異なり、本実施例の通信手順にはデータパケットが届かない状況が発生し得る。これは、ＴＣＰが１００％受信確認パケットを要求するのに対し、本実施例の通信手順では要求しないため、受信確認パケットを返さなかった理由が「乱数の結果」なのか「データパケットが届かなかったから」なのか分からないためである。できる限り確実にデータを届けたいが、同時に通信負荷も抑えたいような状況に、本実施例の通信手順は有効である。

以下の説明では、データパケットの送信側の端末を単に「送信側の端末」と呼び、データパケットの受信側の端末を単に「受信側の端末」と呼ぶことにする。

図２に送信側の端末１のブロック図を示し、図３に送信側の端末１におけるデータパケット記憶部１４の処理手順のフローチャートを示し、図４に送信側の端末１における受信確認チェックリスト保持部１５の処理手順のフローチャートを示す。

データパケット生成部１１によってパケットが生成されると、生成されたパケットは、いったん、データパケット記憶部１４に記憶される。データパケット記憶部１４は、受信確認チェックリスト保持部１５から受信確認を受け取っていない受信側の端末に対し、送信部１６からデータパケットを送信する（Ｓ１０）。

受信確認チェックリスト保持部１５は、受信部１７から受信確認パケットを受信すると（Ｓ２０）、受信確認パケットを送信した受信側の端末をチェックする（Ｓ２１）。このチェックの結果は、データパケット記憶部１４に通知される（Ｓ２２）。受信確認チェックリスト保持部１５が保持する受信確認チェックリスト１８は、端末の識別情報（端末ＩＤ）に対応して状態が記録される。図２の例では、受信確認パケットを受信した場合には状態が「済」となり、受信確認パケットを未受信の場合には状態が「未」となっている。

データパケット記憶部１４は、受信確認チェックリスト保持部１５から受信確認を受け取っていない受信側の端末に対し、送信部１６からデータパケットを送信（Ｓ１０）した後、再送信回数カウンタ１３に対し、送信結果を通知する。

再送信回数カウンタ１３は、この通知を受け取ると、当該受信側の端末に対応するカウント値を“１”加算し、タイマ１２は、再送信回数カウンタ１３のカウント値が“１”加算された受信側の端末に対し、その時点から計時を開始し、設定時間経過後に、当該受信側の端末に対する再送信タイミングが到来した旨をデータパケット記憶部１４に通知する。

データパケット記憶部１４は、タイマ１２からの通知を受け取った時点で（Ｓ１２）、受信確認チェックリスト保持部１５からの通知を確認し、当該受信側の端末からの受信確認を受け取っていない場合には、送信部１６から当該受信側の端末に向けてデータパケットを再送信する（Ｓ１０）。

再送信が行われるとその結果は再送信回数カウンタ１３に通知され、再送信回数カウンタ１３は当該受信側の端末に対するカウント値をさらに“１”加算し、タイマ１２は計時を開始する。

ステップＳ１０〜Ｓ１２の手順は繰り返し実行されるが、再送信カウント値には上限が設けられており、カウント値が上限に達したときには（Ｓ１１）、受信確認が行われていなくても当該受信側の端末に対する再送信を打ち切る（Ｓ１３）。

図５に、受信側の端末２、３のブロック図を示し、図６に、受信側の端末２、３の処理手順のフローチャートを示す。受信側の端末２、３の受信部２３がデータパケットを受信すると（Ｓ３０）、乱数発生部２４は乱数を発生させ（Ｓ３１）、乱数が０．５未満であれば（Ｓ３２）、受信確認パケット生成部２１は受信確認パケットを生成し、送信部２２から受信確認パケットを送信する（Ｓ３３）。乱数が０．５以上であれば（Ｓ３２）、受信確認パケットの生成は行わない。

本実施例では、説明を分り易くするために、送信側の端末１と受信側の端末２、３とを異なる構成として説明したが、実際には、一つの端末が送信側の端末１および受信側の端末２、３の構成を併せて有し、一つの端末が、あるときには送信側の端末となり、また、あるときには受信側の端末となる。

本発明によれば、通信端末数や処理能力に応じて柔軟に対応することができるネットワークを構成することができるため、ネットワークユーザおよび管理者の双方の利便性を向上させることができる。例えば、前述したような映像音声会議システムのように、端末の送信負荷よりも受信負荷の方が大きくなる通信に利用するのに適する。

本発明の通信システムにおける通信手順の実施例を示すシーケンス図。本発明の通信システムにおける送信側の端末のブロック図。本発明の通信システムにおける送信側の端末のデータパケット記憶部の処理手順を示すフローチャート。本発明の通信システムにおける送信側の端末の受信確認チェックリスト保持部の処理手順を示すフローチャート。本発明の通信システムにおける受信側の端末のブロック図。本発明の通信システムにおける受信側の端末の処理手順を示すフローチャート。ネットワーク構成を示す図。ＴＣＰの通信手順を示すシーケンス図。ＵＤＰの通信手順を示すシーケンス図。

符号の説明

１〜３端末
４ネットワーク
１１データパケット生成部
１２タイマ
１３再送信回数カウンタ
１４データパケット記憶部
１５受信確認チェックリスト保持部
１６、２２送信部
１７、２３受信部
１８受信確認チェックリスト
２１受信確認パケット生成部
２４乱数発生部

Claims

複数の端末が相互通信可能なネットワークに接続され、第１の端末から複数の第２の端末にデータパケットを送信する通信システムにおいて、
前記第２の端末はそれぞれ、
データパケットを受信すると所定の確率に従って受信確認パケットを前記第１の端末に送信する手段を備え、
前記第１の端末は、
データパケットの宛先である複数の前記第２の端末毎に、前記受信確認パケットを受信したか否かの状態を記憶する受信確認チェックリストを保持する手段と、
データパケットの送信時には、当該データパケットを一旦記憶し、
データパケットの送信後、前記第２の端末からの受信確認パケットを受信したときには、前記受信確認チェックリストの当該端末に対応する状態を受信済に更新し、
データパケットの送信から所定の時間経過後に、前記受信確認チェックリストに記憶された状態が未受信である前記第２の端末に対して前記記憶したデータパケットを再送信する手段を備えた
ことを特徴とする通信システム。
前記再送信する手段は、前記受信確認チェックリストに記憶された状態が未受信である間、データパケットを前記第２の端末に所定の上限回数を超えない範囲で複数回、再送信を繰り返す手段を備えた
請求項１記載の通信システム。