JP2007214755A - データ通信方法 - Google Patents

Abstract

【課題】通信処理能力の低減化及びトータルスループット向上を行い、高信頼性の通信を行うことができるデータ通信方法を得る。
【解決手段】受信サーバ２０から送信サーバ１０に、データパケットの送信を要求し、これに応じて、送信サーバ１０では、予め分割しておいた複数のデータパケットを、連続して送信し、これを受信した受信サーバ２０で、受信できなかったデータパケットを判断し、受信できなかったデータパケットを再送要求し、これに応じて送信サーバ１０が、再送要求されたデータパケットを連続して送信するようにし、各通信のトランスポートプロトコルとしてＵＤＰを使用したものである。
【選択図】図１

Description

この発明は、送信側から受信側へ、通信回線（無線回線及び有線回線）を使用して高速に大容量のデータを送信するデータ通信方法に関するものである。

例えば、インターネット上で画像データ等を送受信するために、ＴＣＰ／ＩＰ通信でトランスポート層の機能を果たすプロトコルとして、ＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）とＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）が、従来から用いられている。

ＵＤＰは、相手方におけるデータ受信状況を確認せずに通信を行うコネクションレス型のプロトコルである。そのため、ＵＤＰによる通信は、送受信時の負荷が小さく、処理を高速にできるが、データの信頼性が低いという問題がある。

ＴＣＰは、ＵＤＰと異なり、コネクション型のプロトコルであり、送信側と受信側でセッションを張り、受信側がデータを受信すると、受信応答（ＡＣＫ）を返信し、送信側は、ウィンドウ・コントロールの論理のもと受信応答を待って、次のパケットを送信する（非特許文献１参照）。
また、受信状況に応じて、送信速度を制御するフローコントロール機能も有している。そのため、ＴＣＰは、ユーザーデータを順序正しく確実に伝送でき、信頼性が高いが、その反面、プロトコル内で再送間隔を調整するため、速度的な制約のある通信では問題点がある。

したがって、信頼性の高い通信を行う場合は、ＴＣＰを利用し、高速性を追及する場合は、ＵＤＰを利用することが多い。
また、信頼性と高速性の両方が同時に求められる制御システムなどのネットワークの場合は、ＵＤＰを利用し、１パケットずつ応答データにより送信完了を確認する方式が一般的である。移動体に対する通信についても、このような方式を取ることが多い。
さらに、連続した複数のＵＤＰパケットの応答データをまとめて１つのタイマで監視し、限られた通信時間内にデータ通信を行い、送信処理を始めてから一定時間経っても送信が完了しない場合は、その送信処理を打ち切り、次の通信に対応できるデータ通信方式も提案されている（特許文献１）。

特開２００１−３３９４３４号公報（第３〜４頁、図１） ＲＦＣ６７５，７６１，７９３：Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ

近年のデータ伝送は、従来に比べてデータサイズが増大し、１パケットずつ応答データを返し、送信完了を確認する方式は、伝送効率が低下する難点がある。ＴＣＰを用いれば、伝送効率の高い通信が行えるが、プロトコル内で再送間隔を調整するため、再送タイマ値が変動し、限定された時間内にデータを送るのには適さない。再送タイマ値が長くなり、限定された時間内に通信が完了できなくなるからである。

また、特許文献１で提案されている方法は、限られた通信時間内に、信頼性の高いデータ通信ができ、かつ送信処理を始めてから一定時間たっても送信が完了しない場合は、その送信処理を打ち切り、次の通信に対応できるデータ通信方法であり、具体的には次の方法を取っている。（ａ）トランスポートプロトコルとしてＵＤＰを使用し、（ｂ）通信データを最適なパケット長に分割して送信し、（ｃ）連続した複数のパケットの応答データをまとめて１つのタイマで監視し、（ｄ）タイマの設定時間経過後、返信のない未受理のパケットを再送し、（ｅ）一方、受信側では受信した正しいパケットの応答データを返信する。
この特許文献１の方法は、受信側は、受信した正しいパケットの応答データを送信側に返信し、送信側はタイマを使用して、タイマの設定時間が経過したことをトリガに未受信のパケットを再送する方式であり、複雑な送受信処理を同時に行う必要があるため、比較的高い通信処理能力が送信及び受信の装置に要求される問題がある。
また、タイマがタイムアウトして初めて再送制御を行うため、再送制御を開始するまでのタイムディレイが発生し、そのタイムディレイがトータルスループットを低下させる原因となってしまうという問題があった。

この発明は、上述のような課題を解決するためになされたものであり、通信処理能力の低減化及びトータルスループット向上を行いながら、信頼性の高い通信を行うことができるデータ通信方法を得ることを目的にしている。

この発明に係わるデータ通信方法においては、送信側から受信側にデータを送信するデータ通信方法において、受信側から送信側に、データパケットの送信を要求する送信要求パケットを送信する第一の手順、送信側では、予めデータを分割することにより形成され、それぞれシーケンス番号を有する複数のデータパケットを、送信要求パケットの受信に応じて連続して送信する第二の手順、この第二の手順により送信側から連続して送信されるデータパケットを受信側で受信し、最後のデータパケットを受信したとき、受信したシーケンス番号から受信できなかったデータパケットを判断し、受信できなかったデータパケットのシーケンス番号を用いて再送要求するリトライ要求パケットを送信側に連続して送信する第三の手順、及びリトライ要求パケットの受信に応じて、送信側は、再送要求されたデータパケットを受信側に連続して送信する第四の手順を含み、各手順は、トランスポートプロトコルとしてＵＤＰを使用するものである。

この発明は、以上説明したように、送信側から受信側にデータを送信するデータ通信方法において、受信側から送信側に、データパケットの送信を要求する送信要求パケットを送信する第一の手順、送信側では、予めデータを分割することにより形成され、それぞれシーケンス番号を有する複数のデータパケットを、送信要求パケットの受信に応じて連続して送信する第二の手順、この第二の手順により送信側から連続して送信されるデータパケットを受信側で受信し、最後のデータパケットを受信したとき、受信したシーケンス番号から受信できなかったデータパケットを判断し、受信できなかったデータパケットのシーケンス番号を用いて再送要求するリトライ要求パケットを送信側に連続して送信する第三の手順、及びリトライ要求パケットの受信に応じて、送信側は、再送要求されたデータパケットを受信側に連続して送信する第四の手順を含み、各手順は、トランスポートプロトコルとしてＵＤＰを使用するので、ＴＣＰを用いる場合と比較して処理を高速にでき、かつ、複雑な送受信処理を同時に行う必要がなく、送信側及び受信側に要求される通信処理能力を軽減することができる。

実施の形態１．
以下、実施の形態１を図を参照して説明する。
図１は、この発明の実施の形態１によるデータ通信方法を示す模式図である。
図１において、送信側を構成する送信サーバ１０から、通信エリア３０、４０、５０内の受信側を構成する受信サーバ２０にパケットを送信する。受信サーバ２０は、移動可能であり、通信エリア３０、４０、５０内に移動したとき、送信サーバ１０からのパケットを受信できる。
図２は、この発明の実施の形態１によるデータ通信方法の送信側と受信側とで送受するパケットのフローを示すフロー図である。

次に、動作について図２に基づき説明する。
送信サーバ１０は、予め送信すべきデータを最適なパケット長に分割し、それぞれのＵＤＰデータグラムの中にデータであることを明示し、さらに一連のシーケンス番号を付与した「データパケット」を生成しておく。

受信サーバ２０は、ＵＤＰの「送信要求パケット」を送信しつづけ（ステップＳ１）（第一の手順）ながら、通信エリア３０に進入してくる。
送信サーバ１０と受信サーバ２０の無線通信リンクが確立すると、受信サーバ２０の送信する「送信要求パケット」が送信サーバ１０に届き、それを受けた送信サーバ１０は、予め生成しておいた「データパケット」を受信サーバ２０へ連続して送信する（ステップＳ２）（第二の手順）。
受信サーバ２０は、送信サーバ１０から連続して送信される「データパケット」をひたすら受信し、最後のパケットを受信すると、受信した複数パケット中のシーケンス番号から、受信できなかった「データパケット」を判断し、ＵＤＰデータグラムの中に再送要求であることを明示し、さらに送信サーバ１０に再送要求するパケットのシーケンス番号を埋めた「リトライ要求パケット」を生成し、送信サーバ１０へ連続して送信する（ステップＳ３）（第三の手順）。

送信サーバ１０は、受信サーバ２０から連続して送信される「リトライ要求パケット」をひたすら受信し、最後のパケットを受信すると、再送要求された「データパケット」を受信サーバ２０へ連続して送信する（ステップＳ４）（第四の手順）。

受信サーバ２０は、送信サーバ１０から連続して送信される「データパケット」をひたすら受信し、最後のパケットを受信すると、受信した複数パケット中のシーケンス番号から、受信できなかった「データパケット」を判断し、送信サーバ１０に再度、再送要求するパケットのシーケンス番号を埋めた「リトライ要求パケット」を生成し、送信サーバ１０へ連続して送信する（ステップＳ３）。
送信サーバ１０は、受信サーバ２０から連続して送信される「リトライ要求パケット」をひたすら受信し、最後のパケットを受信すると、再送要求された「データパケット」を受信サーバ２０へ連続して送信する（ステップＳ４）。

このステップＳ３とステップＳ４の繰り返しにより、受信サーバ２０は、全ての「データパケット」を受信すると、全ての「データパケット」を受信したことを送信サーバ１０に報告するためのＵＤＰデータグラム中にデータ受信完了のフラグを設けた「データ受信完了パケット」を送信サーバ１０に送信し、一連のデータ通信を終了させる（ステップＳ５）。

上述した一連のシーケンスは、通信エリア３０においてのみ、全てのデータ通信が完了した場合の例であるが、受信サーバ２０の移動速度が速い場合や通信エリア３０が狭い場合などにより、送信サーバ１０と受信サーバ２０との間の通信時間が短い場合は、全てのデータパケットの送信が完了する前に、受信サーバ２０が通信エリア３０を抜けてしまうことになる。
この場合のデータ通信再開方法について、次に説明する。

送信サーバ１０及び受信サーバ２０は、それぞれタイマを持っており、通信が開始され、相手からのパケットの受信を待つことになったタイミングで、そのタイマをスタートさせ、ある一定時間相手からのパケットを受信しなかった場合は、相手が通信可能エリアにいないと判断し、タイムアウト処理にて、送信サーバ１０及び受信サーバ２０は、それぞれ初期状態に戻る（ステップＳ６）。
つまり、受信サーバ２０は、「送信要求パケット」を連続送信し、送信サーバ１０は、受信サーバ２０からの「送信要求パケット」の受信待ちの状態に入る。

受信サーバ２０が次の通信エリア４０に進入すると、受信サーバ２０が送信し続けている「送信要求パケット」（ステップＳ７）が送信サーバ１０に届き、送信サーバ１０は、データ通信が途中で終了したことを、受信サーバ２０に知らせ、受信サーバ２０が欲している「データパケット」が何なのかを報告させるために、ＵＤＰデータグラムの中に再開通知であることを明示した「再開通知パケット」を受信サーバ２０へ送信し続ける（ステップＳ８）。
受信サーバ２０は、「再開通知パケット」を受信すると、再送を要求すべき「データパケット」のシーケンス番号を埋めた「リトライ要求パケット」を送信サーバ１０に送信することにより、データ通信が再開される（ステップＳ９）。
送信サーバ１０は、「リトライ要求パケット」の受信に応じて、「データパケット」を受信サーバ２０へ連続して送信する（ステップＳ１０）。
ステップＳ９とステップＳ１０を繰り返すことにより、受信サーバ２０で、全ての「データパケット」が受信されれば、「データ受信完了パケット」を送信サーバ１０へ送信して、一連のデータ通信を終了させる（ステップＳ５）。

このデータ通信方法は、送信サーバ１０が全ての「データパケット」を投げ終えてから、受信サーバ２０からの再送要求を受け付ける、という方法であるため、無線回線品質の悪い通信エリアで、本方式によりデータ通信を行うと、何度も再送要求シーケンスが実施されることになり、トータルスループットは、極端に劣化する。逆に、無線回線品質が非常に優れた通信エリアでは、再送要求シーケンスの発生は、極小に抑えられ、極めて高いトータルスループットを得ることが可能となる。

なお、本実施の形態１では、送信サーバ１０と受信サーバ２０が無線回線にてリンクされることを前提として記述したが、有線回線にて固定的にリンクさせるときも同様にデータ通信することができる。

上述の中で、パケットを送信し続ける旨、記載しているが、通信回線が特に無線回線の場合は、パケット１回の送信では、それが相手に届かないことが往々にしてあるため、パケットを送信し続ける必要があるためである。
また、ステップＳ１、Ｓ７で、受信サーバ２０から「送信要求パケット」を送信し続けるのは、不要な電波を出しつづけることになるため、外部装置が電界強度を測定する等、何らかの方法で通信エリアに侵入したことを検知し、その検知をトリガに「送信要求パケット」を送信し始める、という方法をとることも考えられる。

実施の形態１の方法では、ステップＳ２、Ｓ４、Ｓ１０の「データパケット」の最後、及びステップＳ３、Ｓ９の「リトライ要求パケット」の最後、つまり、「データパケット」を一度全て投げ終えたこと、及び「リトライ要求パケット」を一度全て投げ終えたことを、それぞれ、受信サーバ２０及び送信サーバ１０に報告する必要がある。なぜなら、受信サーバ２０及び送信サーバ１０が送信を開始するタイミングを得る必要があるからである。
その方法としては、「データパケット」及び「リトライ要求パケット」中に、最後のパケットであることを明示するフラグを設けておき、最後のパケットは、そのフラグを立てておく方法や、「データパケット」及び「リトライ要求パケット」を投げ終えた後に続けて、「データパケット送信終了パケット」及び「リトライ要求パケット送信終了パケット」を送信する方法などがある。

また、通信回線が特に無線回線の場合は、パケット１回の送信では、それが相手に届かないことが往々にしてあるため、その最後のパケットを送信し続ける必要がある。
あるいは、この最後のパケットを送信し続けることに代えて、全てのパケットを送信し続ける方法によってもよく、この場合は、「データパケット」及び「リトライ要求パケット」を一度全て投げ終えたことを相手に報告する方法として、「データパケット」及び「リトライ要求パケット」中に、一度送信したことを明示するフラグを設けておき、２度目以降の送信では、そのフラグを立てて、「データパケット」及び「リトライ要求パケット」を繰り返し送信する。

また、受信サーバ２０が全ての「データパケット」を受信したことを送信サーバ１０に報告する方法としては、シーケンス番号が埋まっていない「リトライ要求パケット」を送信する方法や、「リトライ要求パケット送信終了パケット」のみを送信する方法や、あるいは、全ての「データパケット」を受信したことを送信サーバ１０に報告するためのＵＤＰデータグラム中にデータ受信完了のフラグを設けた「データ受信完了パケット」を送信サーバ１０に送信する方法などがある。
なお、受信サーバ２０が全ての「データパケット」を受信してしまえば、以降パケットの送受信を行う必要がないため、パケット送信を止めれば、相手は自動的にタイムアウトにより、データ通信が終了するため、受信サーバ２０が全ての「データパケット」を受信したことを送信サーバ１０に敢えて報告しない、という方法もある。

実施の形態１によれば、トランスポートプロトコルとしてＵＤＰを使用して、通信データを最適なパケット長に分割して送信するので、ＴＣＰを用いる場合と比較して処理を高速にでき、かつ、複雑な送受信処理を同時に行う必要がなく、送受信の装置に要求される通信処理能力を軽減でき、また、受信側から送信されるパケット再送要求に即応答できるため、限られた通信時間内のトータルスループットを高めることが可能となる。
また、「送信要求パケット」、「データパケット」、「リトライ要求パケット」及び「データ受信完了パケット」を送信し続け、かつ送信サーバ及び受信サーバが相手からのパケットを一定時間全く受信しなかったことをトリガに、データ通信を中断し初期状態に戻る、という方法を取ることにより、例えば、受信サーバが送信サーバからの無線通信可能区間に進入した瞬間からデータ通信を開始し、無線通信可能区間から抜けたときにそのデータ通信を中断し、また次の無線通信可能区間に進入したときデータ通信を行うことで、高速で高効率なデータ通信が可能となる。

実施の形態２．
図３は、この発明の実施の形態２によるデータ通信方法を示す模式図である。
図３においては、送信側を構成する複数の送信サーバ１１、１２、１３が地上ネットワーク７０を介して管理サーバ６０に接続されている構成である。各送信サーバ１１、１２、１３は、それぞれ図１のような通信エリアを有し、この通信エリアに移動した受信サーバ２０にパケットを送信する。

次に、動作について説明する。
通信エリアが多数になると、それを１つの送信サーバ１０でカバーするのは、現実的に不可能となるため、図１のような送信サーバとその通信エリアの構成を多数並べて、それらを管理する管理サーバ６０を上位に設け、地上ネットワーク７０を介して管理サーバ６０とそれぞれの送信サーバ１１、１２、１３とを接続する方法を取る。

管理サーバ６０では、受信サーバ２０に送信すべき複数のファイルを１つの送信サーバで管理している複数の通信エリア内で十分に転送可能な小サイズのファイルに分割し、その小ファイル群を各送信サーバ１１、１２、１３へ送信しておく。

受信サーバ２０が送信サーバ１１管理下の通信エリア内に入ると、実施の形態１で説明した手順により、送信サーバ１１から小ファイル群が受信サーバ２０に送信される。送信サーバ１１管理下の通信エリアを受信サーバ２０が抜けると、送るべき全ての小ファイル群のうち、送信完了できなかった小ファイルの情報を送信サーバ１１が管理サーバ６０へ報告する。
管理サーバ６０は、報告を受けた内容を他の送信サーバ１２、１３に伝達し、受信サーバ２０の次の通信エリア進入に備える。

次に、受信サーバ２０が送信サーバ１２管理下の通信エリアに入ると、送信サーバ１２は、受信サーバ２０が未受信の小ファイル群を受信サーバ２０へ送信する。
以降、同様の手順を踏んで、送るべき全ての小ファイル群を受信サーバ２０へ送信する。
受信サーバ２０は、受信した小ファイル群を合成し、適当なタイミングで元のファイルに復元する。

もし、受信サーバ２０が鉄道車両のような、或る決まったところを１方向で走行するようなものであれば、受信サーバ２０が次に入る送信サーバの通信エリアは決まってくるので、管理サーバ６０が未受信の小ファイル情報を伝達する送信サーバは、報告を受けた送信サーバの次の送信サーバのみとしてもよい。

実施の形態２によれば、複数の送信サーバにより、通信エリアを多くしたので、受信サーバが移動できる範囲が広くなる。

この発明の実施の形態１によるデータ通信方法を示す模式図である。 この発明の実施の形態１によるデータ通信方法の送信側と受信側とで送受するパケットのフローを示すフロー図である。 この発明の実施の形態２によるデータ通信方法を示す模式図である。

符号の説明

１０ 送信サーバ
１１ 送信サーバ１
１２ 送信サーバ２
１３ 送信サーバＮ
２０ 受信サーバ
３０ 通信エリア１
４０ 通信エリア２
５０ 通信エリアＮ
６０ 管理サーバ
７０ 地上ネットワーク

Claims (19)

1. 送信側から受信側にデータを送信するデータ通信方法において、上記受信側から上記送信側に、データパケットの送信を要求する送信要求パケットを送信する第一の手順、上記送信側では、予め上記データを分割することにより形成され、それぞれシーケンス番号を有する複数のデータパケットを、上記送信要求パケットの受信に応じて連続して送信する第二の手順、この第二の手順により上記送信側から連続して送信されるデータパケットを上記受信側で受信し、最後のデータパケットを受信したとき、受信した上記シーケンス番号から受信できなかったデータパケットを判断し、上記受信できなかったデータパケットのシーケンス番号を用いて再送要求するリトライ要求パケットを上記送信側に連続して送信する第三の手順、及び上記リトライ要求パケットの受信に応じて、上記送信側は、上記再送要求されたデータパケットを上記受信側に連続して送信する第四の手順を含み、上記各手順は、トランスポートプロトコルとしてＵＤＰを使用することを特徴とするデータ通信方法。
2. 上記第一の手順で、上記受信側から上記送信側に送信される送信要求パケットは、同じ送信要求パケットが連続して送信されることを特徴とする請求項１記載のデータ通信方法。
3. 上記第二の手順で送信されるデータパケットの最後のデータパケットには、最後のデータパケットであることを示すフラグを立てることを特徴とする請求項１記載のデータ通信方法。
4. 上記第二の手順で送信されるデータパケットの最後のデータパケットであることを上記受信側で判断できるように、データパケット送信終了パケットを、上記最後のデータパケットの次に送信することを特徴とする請求項１記載のデータ通信方法。
5. 上記第二の手順で、上記最後のデータパケットを連続して送信することを特徴とする請求項３記載のデータ通信方法。
6. 上記第二の手順で、上記データパケット送信終了パケットを連続して送信することを特徴とする請求項４記載のデータ通信方法。
7. 上記第二の手順では、データパケットの送信を繰り返し行い、二回目以降のデータパケットの送信に当たっては、上記データパケットに一度送信したことを示すフラグを設けることを特徴とする請求項１記載のデータ通信方法。
8. 上記第三の手順によって送信される上記リトライ要求パケットの最後のリトライ要求パケットには、最後のリトライ要求パケットであることを示すフラグを立てることを特徴とする請求項１に記載のデータ通信方法。
9. 上記第三の手順によって送信される上記リトライ要求パケットの最後のリトライ要求パケットを送信側で判断できるように、リトライ要求パケット送信終了パケットを、上記最後のリトライ要求パケットの次に送信することを特徴とする請求項１記載のデータ通信方法。
10. 上記第三の手順で、上記最後のリトライ要求パケットを連続して送信することを特徴とする請求項８記載のデータ通信方法。
11. 上記第三の手順で、上記リトライ要求パケット送信終了パケットを連続して送信することを特徴とする請求項９記載のデータ通信方法。
12. 上記第三の手順では、リトライ要求パケットの送信を繰り返し行い、二回目以降のリトライ要求パケットの送信に当たっては、上記リトライ要求パケットに一度送信したことを示すフラグを設けることを特徴とする請求項１記載のデータ通信方法。
13. 上記第二の手順及び第四の手順により、上記受信側が全てのデータパケットを受信したときは、上記受信側は、シーケンス番号を持たないリトライ要求パケットを上記送信側に送信することを特徴とする請求項１記載のデータ通信方法。
14. 上記第二の手順及び第四の手順により、上記受信側が全てのデータパケットを受信したときは、上記受信側は、上記リトライ要求パケット送信終了パケットのみを上記送信側に送信することを特徴とする請求項９記載のデータ通信方法。
15. 上記第二の手順及び第四の手順により、上記受信側が全てのデータパケットを受信したときは、上記受信側は、データ受信完了を示すフラグを有するデータ受信完了パケットを上記送信側に送信することを特徴とする請求項１記載のデータ通信方法。
16. 上記送信側及び受信側が、相手からのパケットを一定時間受信しない場合には、上記送信側は、パケットの送信を停止すると共に、上記受信側は、上記送信要求パケットを上記送信側へ送信し、この送信要求パケットを上記送信側が受信することにより、上記送信側及び受信側間のデータ通信が再開されることを特徴とする請求項１記載のデータ通信方法。
17. 上記送信側及び受信側間のデータ通信の再開に当っては、上記送信要求パケットを受信した送信側は、再開通知である再開通知パケットを上記受信側に送信し、上記受信側は、上記再開通知パケットの受信に応じて、上記リトライ要求パケットを上記送信側に送信することにより、データ通信が再開されることを特徴とする請求項１６記載のデータ通信方法。
18. 上記送信側は、上記再開通知パケットを連続して送信することを特徴とする請求項１７記載のデータ通信方法。
19. 上記送信側を構成する複数の送信サーバとネットワークを介して接続された管理サーバの管理により、上記受信側が移動する場合にも、上記受信側の移動に応じて上記受信側とデータ通信する送信サーバが切換わるようにしたことを特徴とする請求項１〜請求項１８のいずれかに記載のデータ通信方法。

Images