データ伝送方式、及び、複数拠点データ配信方式
【課題】データ伝送中にパケットロスや遅延のゆらぎが起こっても、データ伝送速度が大きく低下することのない高速なデータ伝送方式を提供する。
【解決手段】一実施形態に係るデータ伝送方法は、受信先に対して複数のパケットを連続的に送出する第一のステップと、受信先から送出された、受信先が複数のパケットのうち少なくとも一部を受領したことを示す受領確認を受信する第二のステップと、受領確認によって受信先による受領が確認されたパケットよりも前に送出されたパケットであり、かつ、受領確認を受信していないパケットを再送する第三のステップと、を備える。また、このデータ伝送方法を利用して、複数拠点にデータを略同時に配信する配信方式を提供する。
【解決手段】一実施形態に係るデータ伝送方法は、受信先に対して複数のパケットを連続的に送出する第一のステップと、受信先から送出された、受信先が複数のパケットのうち少なくとも一部を受領したことを示す受領確認を受信する第二のステップと、受領確認によって受信先による受領が確認されたパケットよりも前に送出されたパケットであり、かつ、受領確認を受信していないパケットを再送する第三のステップと、を備える。また、このデータ伝送方法を利用して、複数拠点にデータを略同時に配信する配信方式を提供する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データを高速に伝送する通信制御方式に関する。また、当該通信制御方式を利用した複数拠点データ配信方式に関する。
【背景技術】
【０００２】
従来、ファイルの伝送にはＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）が一般的であるが、ＴＣＰでは一定量のパケットを投げたあと、応答パケットを待つため、拠点間の往復遅延（ＲＴＴ）が通信速度に非常に影響する。標準的な６４ＫＢのウィンドウサイズで、東京−大阪間（ＲＴＴが２０ｍｓと仮定）の場合、理論上、どんなに速い回線を用意したとしても、２５．６Ｍｂｐｓまでしか速度がでない。ウィンドウサイズを大きくすれば、一度に送信できるデータのサイズが増えるため理論上の通信速度は上がるが、パケットロスが発生した場合には、再送に時間がかかり転送速度が遅くなるなど、かえって転送効率が落ちてしまう場合もある。
【０００３】
一方、ＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）を用いてデータ転送を行う技術自体は既存の技術が存在するが、利用する回線に対して最適なパラメータを設定しなければならないものや、パケットロスや遅延のゆらぎが発生すると転送速度が低下してしまうもの、回線のキャパシティいっぱいまでは使いきれないものなど、従来では解決できていない課題が多い。
【０００４】
また従来、複数拠点に同時伝送を行うには、中央にサーバを置き各拠点に配信する方式が知られている。また、マルチキャストというプロトコルも存在するが、一般的なインターネットでの適応は難しく、または、パケットロスに対する制御などが別途必要になる（特許文献１参照）。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００８−８５９３２号公報
【特許文献２】特開２０００−２０７２９８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
従来のデータ伝送方式の多くは、パケットロスを輻輳と定義し、パケットロスが発生した場合には、輻輳が起きているものとみなしている。そして、パケットロスが発生しないように制御したり、また、パケットロスが発生した場合には、輻輳が抑止されるように転送レートやパケット転送間隔を制御したりすることが一般的である。
【０００７】
このため、従来のデータ伝送方式は、パケットロスが生じると通信速度が大幅に低下してしまうという課題を有している。他にも、従来のデータ伝送方式は、パケット遅延のゆらぎにより通信速度が低下する、通信開始当初の通信速度が遅い、ＲＴＴが大きいと通信速度が影響を受けてしまう、といった点が指摘されている。
【０００８】
また、複数拠点にデータをほぼ同時に伝送する配信方式においては、中央サーバをおく方式では、複数拠点同時配信に耐えうる高性能な中央サーバと、配信先の数に応じた広帯域な回線が必要である。マルチキャスト配信を用いる場合、特別な回線が必要となり、かつ、パケットロスに対応するためサーバから個別に再送などを制御しなければならない。
【０００９】
本発明はかかる実情に鑑みてなされたものであり、データ伝送中にパケットロスや遅延のゆらぎが発生することを前提とし、パケットロス等が生じても、データ伝送速度が大きく低下することのない高速なデータ伝送方式を提供しようとするものである。また、このようなデータ伝送方式を利用して、複数拠点にデータをほぼ同時に配信する配信方式を提供しようとするものである。
【課題を解決するための手段】
【００１０】
本発明の一実施形態に係るデータ伝送方法は、送信側装置から受信側装置に対してパケット通信網を介してデータを伝送する方法であって、送信側装置が、受信側装置に対して複数のパケットを連続的に送出する第一のステップと、受信側装置から送出された、受信側装置が複数のパケットのうち少なくとも一部を受領したことを示す受領確認を受信する第二のステップと、受領確認によって受信先による受領が確認されたパケットよりも前に送出されたパケットであり、かつ、受領確認を受信していないパケットを再送する第三のステップと、を備える。すなわち、本発明の一実施形態においては、パケットを連続送信後、受領確認（Ａｃｋ）が返って来たパケットより前に送信したパケットをパケットロスとみなすことにより、従来のデータ伝送方式とは異なり、送信後一定時間経過する前に受領が確認されなくても、パケットの再送を行わずに、そのままパケットを送信し続ける。ネットワークスイッチ等はパケットをバッファに受信してから処理を行うため、パケットを送り込む間隔を短くすればするほど、バッファにそのパケットが入る確率を上げることが出来る。本発明は、回線のキャパシティよりも速い速度でパケットを送り込むことで、より高速なデータ転送を可能としている。回線のキャパシティを溢れた分はパケットロスとなるが、本発明においては、パケットロスが起こることを前提としているため、データ伝送上の問題は生じない。
【００１１】
近年、ＩＰ網を構成している装置はほとんどがスイッチであり、装置内部にバッファを備えている。装置間は全二重で任意のタイミングで通信可能であり、送られてきたパケットはスイッチ内部のバッファに一旦溜められ、そのバッファから送るべき通信相手にパケット送信される。バッファがいっぱいにならない限り、同じ機器に対するパケットが複数個所から送られてきたとしても、順番に処理されるだけでパケットロスは発生しない。ただし、遅延時間は変化する。バッファがいっぱいになると、バッファに空きができるまで、その後に届いたパケットは破棄されてしまう（パケットロス）が、バッファに入った分のパケットについては正しく処理される。したがって、従来の通信制御方式が前提としている「輻輳」は、誰も正常な通信をできないような状況のことを指すが、そのような状況は、現在の装置間では発生しにくい。
【００１２】
好適には、第三のステップは、受領確認によって受信先による受領が確認されたパケットのうち最も直近に送出されたパケットの送出時刻よりも所定時間以上前に送出されたパケットを再送する。パケットがリオーダーで届く場合もあるので、パケットロスと判定する時刻に若干の遊びを持たせることにより、受信側ですでに受信済みのパケットを再度受信してしまうことがほぼなくなり、効率の良いデータ伝送が可能となる。
【００１３】
第一のステップは、パケットを送出する際に、当該パケットを識別可能な識別情報と当該パケットの送出時刻とを対応付けて記録するステップを含むことが好ましい。好適には、受領確認は、受信先が受領したパケットの識別情報を含む。さらに、受領確認は、過去所定回分の受領確認に含まれていた識別情報を含むことが好ましい。過去数回分の受領確認情報を、受領確認パケットに入れて送付することにより、受領確認パケットのパケットロスも考慮したデータ伝送方式を提供することができる。
【００１４】
また、本発明の一実施形態に係るデータ配信方法は、上述のデータ伝送方法によるデータ送受信が可能な複数の送受信装置の間で、数珠つなぎにデータ伝送を行うことによって、複数の送受信装置間で略同時にデータ伝送を行う。すなわち、上述のデータ伝送方法を基本技術として利用して、Ａ拠点からＢ拠点に投げたパケットを、Ｂ拠点はＣ拠点に中継する、といった処理を繰り返す。基本的には１対１の通信のため、中央サーバは必要ない。また、特別な広帯域回線は必要なく、一般的なＢフレッツに代表される上下対称な光ファイバーブロードバンド回線を利用可能である。さらに、パケット単位で中継されるため、最小単位でデータ配信が行われる。これにより、ファイル全体が転送完了するのを待つことなく、パケット単位でデータ転送できるため、１対１で通信するのとほぼ同等な時間で、複数拠点への同時伝送が可能である。
【発明の効果】
【００１５】
本発明のデータ伝送方式によれば、データ伝送中にパケットロスや遅延のゆらぎが起こっても、データ伝送速度が大きく低下することがなく、高速にデータを伝送可能なデータ伝送方式を提供することができる。また、このようなデータ伝送方式を利用して、複数拠点にデータを略同時に配信する配信方式を提供することが可能である。
【００１６】
より具体的には、本発明の所定の実施形態によれば、インターネット等のＩＰ通信網を用いて、回線のキャパシティいっぱいまで活用して高速に拠点から拠点へデータを転送するためのプロトコルおよび制御方式を提供できる。パケットロスが頻発するような回線であっても、ほとんど影響を受けずに安定したデータ転送が可能である。また、回線速度、回線品質にほとんど影響されず、ユーザが回線にあわせた特別な設定を行うこともなく、回線のキャパシティいっぱいまで利用して高速なデータ転送が可能である。
【００１７】
また、本発明の所定の実施形態によれば、上述のデータ伝送方式を応用し、ある拠点から複数拠点を数珠つなぎにパケットを中継し、データの同時伝送を可能としている。特別な回線は必要なく、一般的なＢフレッツに代表される光ファイバーブロードバンドを用いて回線のキャパシティいっぱいまで利用した上で、複数拠点への高速な同時転送を可能としている。
【図面の簡単な説明】
【００１８】
【図１】本発明の一実施形態に係るデータ伝送システム１のアーキテクチャを示す図である。
【図２】本発明の一実施形態に係る送信側装置１０及び受信側装置２０の機能構成を示すブロック図である。
【図３】本発明の一実施形態におけるデータ伝送処理の制御プロトコルを示すフローチャートである。
【図４】本発明の一実施形態におけるデータ伝送の概略を示す概念図である。
【図５】本発明の一実施形態に係るデータ伝送方式のアルゴリズムを説明するための模式図である。
【図６】本発明の一実施形態に係るデータ伝送方式のアルゴリズムを説明するための模式図である。
【図７】本発明の一実施形態に係るデータ伝送方式を利用した複数拠点配信システムのアーキテクチャを示す図である。
【図８】本発明の一実施形態に係る送信側装置１０、受信側装置２０、及びこれらを含む送受信装置７０の機能構成を示すブロック図である。
【図９】本発明の一実施形態における複数拠点配信処理の概略を示すフローチャートである。
【発明を実施するための形態】
【００１９】
以下、本発明の実施の形態について図面を参照しつつ詳細に説明する。なお、同一の要素には同一の符号を付し、重複する説明を省略する。また、以下の実施の形態は、本発明を説明するための例示であり、本発明をその実施の形態のみに限定する趣旨ではない。さらに、本発明は、その要旨を逸脱しない限り、さまざまな変形が可能である。
【００２０】
図１は、本発明の一実施形態に係るデータ伝送システム１のアーキテクチャを示す図である。データ伝送システム１は、送信側装置１０と受信側装置２０とがネットワークＮを介して接続されて構成される。
【００２１】
送信側装置１０は、ネットワークＮを介して受信側装置２０に向けてデータを送信するための装置である。受信側装置２０は、送信側装置１０から送信されたデータを受信するための装置である。送信側装置１０と受信側装置２０はそれぞれ、専用の装置により構成してもよいし、汎用のコンピュータが送信側装置１０及び／又は受信側装置２０の機能を備えるよう構成してもよい。
【００２２】
ネットワークＮは、送信側装置１０と受信側装置２０との間でデータを伝送するための通信回線である。これはＬＡＮやインターネット網に代表されるパケット通信網（またはその組み合わせ）であればよく、物理層には左右されない。よって、物理層としては、イーサネット（登録商標）、無線通信網、公衆電話通信網、一般電話回線網、その他の通信回線、それらの組み合わせ等のいずれであってもよい。また、各通信網間を接続するためのゲートウェイや各種基地局、交換機などもネットワークＮに含まれ得る。
【００２３】
図２は、本発明の一実施形態に係る送信側装置１０及び受信側装置２０の機能構成を示すブロック図である。
【００２４】
送信側装置１０は、送出時刻記録モジュール１１と、パケット送出モジュール１２と、送出レート調整モジュール１３と、受領確認（Ａｃｋ）受信モジュール１４と、再送判定モジュール１５とを含んで構成される。
【００２５】
送出時刻記録モジュール１１は、パケット単位で、パケットを識別するためのパケット番号と、当該パケットを送出した日時に関する送信時刻情報とを対応付けて記録する。なお、パケット番号に換えて、パケットを識別可能な任意の情報を利用可能である。パケット送出モジュール１２は、送信するデータをパケットに分けて、ネットワークＮに送出する。送出レート調整モジュール１３は、ネットワークＮに送信するビットレート等、パケットの送出レートを調整する。受領確認（Ａｃｋ）受信モジュール１４は、受信側装置２０から受領確認（Ａｃｋ）を受信して、受信側装置２０がパケットを受信したか否かをパケット番号毎に管理する。再送判定モジュール１５は、所定の条件を満たすパケットを受信側装置２０に再送する。
【００２６】
受信側装置２０は、パケット受信モジュール２１と、受信パケット番号記録モジュール２２と、受領確認（Ａｃｋ）送信モジュール２３と、過去分受領確認（Ａｃｋ）情報記憶モジュール２４と、ソート処理モジュール２５と、受信レート計算モジュール２６と、タイマー２７とを含んで構成される。
【００２７】
パケット受信モジュール２１は、送信側装置１０から送出されたパケットを受信する。受信パケット番号記録モジュール２２は、受信したパケットのパケット番号を記録する。受領確認（Ａｃｋ）送信モジュール２３は、パケットを受領したときに、受領したパケットの受領確認を送信側装置１０に向けて送信する。このとき、受領したパケットを一定個数分まとめて、又は、所定時間が経過した場合にそれまでに受領したパケットをまとめて、受領確認を返送することが好ましい。過去分受領確認（Ａｃｋ）情報記憶モジュール２４は、過去に送出した受領確認を、パケット番号と対応付けて記憶する。ソート処理モジュール２５は、受信したパケットを結合してデータを読み出すためのものである。受信レート計算モジュール２６は、受信したパケットに基づいて、受信レートを計算する。タイマー２７は、受領時間等を測定し、また、受領確認を送信するタイミングを計るためのものである。
【００２８】
次に、上記のように構成されるデータ伝送システム１の動作の概要について説明する。
【００２９】
図３は、本発明の一実施形態におけるデータ伝送処理の制御プロトコルを示すフローチャートである。本実施形態では、データの伝送及び制御にＵＤＰプロトコルのみを用いるものとする。そのため、特許文献２にあるようなＴＣＰを制御、ＵＤＰをデータ転送に用いるようなプロトコルと比較して、ＴＣＰ分の帯域を確保する必要はなく、回線キャパシティをフルに利用できる。なお、コネクションレスのデータグラム型プロトコルであれば、ＵＤＰプロトコルに限らず適用可能である。送信データのパケットは、ＵＤＰパケットのヘッダを除いた先頭４バイトをパケット番号とする。先頭４バイトを除いた残りのデータを、転送すべきデータの一部（ペイロード）とする。ペイロードのサイズは、送るべきデータの最終パケットを除き、固定の大きさとする。しかし、パケット番号やペイロードのサイズ等は、これらに限定されない。
【００３０】
送信側装置１０のパケット送出モジュール１２は、送信側装置１０から受信側装置２０に転送するデータをペイロードサイズごとに分け、パケット番号を付加した上で、受信側装置２０にパケット送出する（Ｓ４１）。その際、送出時刻記録モジュール１１は、パケット送信をした時刻をパケット番号毎に記録しておく。
【００３１】
データ転送開始当初、送信側装置１０から受信側装置２０までの回線がどの程度のキャパシティがあるのか不明であるため、送信側装置１０は可能な限り速い速度で次々にパケットを送出する。なお、ネットワークＮのキャパシティを超えた分のパケットは、ネットワークＮ上で破棄されることになる。
【００３２】
受信側装置２０のパケット受信モジュール２１がパケットを受信すると、送信側装置１０から届いたパケットをソート処理モジュール２５がパケット番号順にソートし、パケット番号が連続して受信できた部分について、ディスク装置や後の処理系にデータを出力する（Ｓ４２）。ただし、受信パケットのパケット番号がすでに受信済みのパケット番号だった場合は、この処理を行わない。
【００３３】
受信側装置２０の受信パケット番号記録モジュール２２は、届いたパケットのパケット番号を記録する。受領確認送信モジュール２３は、前回の受領確認パケット送付から、一定個数（例えば６４個）パケットが届いた場合、または、直近の通信速度から換算して一定個数のパケットが届くはずの時間に所定時間を加えた時間が経過した場合に、送信側装置１０に対し受領確認（Ａｃｋ）を送付する（Ｓ４３）。送付した受領確認のログは、過去分受領確認情報記憶モジュール２４に記録される。なお、届いたパケットのパケット番号を記録する際、過去に受信済みのパケット番号も処理対象とする。
【００３４】
受領確認（Ａｃｋ）パケットは、ＵＤＰパケットのヘッダを除いた先頭４バイトを受領確認パケット番号とし、その後ろに、直近の一定時間（例えば、１／３秒をタイマー２７で計測）で算出したビットレートの情報を付加する。そして、その後ろに、届いたパケット番号（４バイト）を列挙する。パケット番号が連続している場合は、連続しているパケット番号の先頭と最終のパケット番号に連続フラグをつけて、受領確認パケットのサイズを圧縮する。また、受領確認パケットがパケットロスになる可能性を考慮し、過去Ｎ回分（例えば、Ｎ＝１）の受領確認パケットに列挙したパケット番号情報を付加する。これにより、受領確認パケットが連続で（Ｎ＋１）回パケットロスしない限り、受領確認情報は正しく送信側装置１０に伝わる。ビットレートの情報は、受信レート計算モジュール２６が、一定時間に受信したパケット数（重複パケットを含む）を用いて算出する。過去の受領確認は過去分受領確認情報記憶モジュール２４から取得される。
【００３５】
なお、本実施形態においては、データ伝送中にパケットロスが発生することを前提としているため、受信されたデータは歯抜け状態となることが多い。しかし、ソート処理モジュール２５からディスク装置等にデータを出力する際には、シーケンシャルにデータを書き出さないと性能が劣化してしまう。そのため、受信側装置２０は適切な量のバッファを持ち、歯抜け状態が解消された部分までをシーケンシャルデータとして、ディスク装置に書き出したり、後の処理系に出力したりする。
【００３６】
送信側装置１０は、受領確認パケットが届くと、受領確認受信モジュール１４が受領確認パケットを受信する（Ｓ４４）。そして、再送判定モジュール１５は、受領確認パケットに列挙された受信済みパケット番号について、それぞれのパケットを送信側装置１０が元々送付した時刻のうち最も直近の時刻を、「応答済み最終パケット送信時刻」（Ｔ）とし、まだ受領確認が返ってきていないパケットの送信時刻（Ｓ）との差（Ｔ−Ｓ）が、所定の閾値β（例えば、β＝２００ミリ秒）以上になった場合に、その受領確認が返ってきていないパケットについて、次に新規に送るべきパケットに割り込む形で、再送を行う（Ｓ４５）。なお、再送時にも、そのパケットを再送した時刻を記録しておく。
【００３７】
送信側装置１０の送出レート調整モジュール１３は、受領確認パケットに記載された直近のビットレート情報をもとに、次以降、パケットを送出する時間間隔を制御する（Ｓ４６）。具体的には、転送開始からのビットレート情報で最も高い数値（最大値）に対し、θ倍（例えば、θ＝１．２）の速度でパケットを送出する。本発明においては、パケットロスは発生することが前提であるため、回線のキャパシティを超えてパケットを送信し、パケットロスが発生してもデータ伝送上の問題は生じない。また、通信開始当初、回線が過度に混雑していてあまり高いレートが出なかった場合でも、回線が空けば速度は回復する。逆に、通信開始当初、回線が空いていて、次第に混雑した場合でも、混雑した分の実転送速度は落ちるが、パケットロスが多めに発生するようになるだけであり、通信の信頼性には影響しない。仮に通信中に回線が混雑したとしても、本来、ビットレート情報の最大値までのキャパシティはあるはずであるため、転送速度を遅くすることはしない。
【００３８】
送信側装置１０は、送信すべきデータのパケットがまだ残っている場合（Ｓ４７：Ｎｏ）、上記Ｓ４１〜Ｓ４６の処理を繰り返してパケットを送信する。送信すべきデータの最後のパケットまで送信した場合（Ｓ４７：Ｙｅｓ）、送信データの終わりを示すパケットを送信し、さらに、受領確認がまだ返ってきていない（と送信側装置１０が認識している）パケットについて強制的に再送を行う（Ｓ４８）。この強制再送モードでは、受領確認が返ってきていないパケットを未送信と同じ状態として扱い、Ｓ４１〜Ｓ４７の処理を行う。転送をやめたり、一時停止したりすることはしない。なお、この送信データの終わりを示すパケットもパケットロス時は再送対象となる。
【００３９】
受信側装置２０は、全てのパケットを受信した場合、受信完了のステータスとするが、まだ送信側装置１０からパケットがまだ送られてくる場合は、受領確認パケットを返す処理は続行する。
【００４０】
送信側装置１０は、受領確認パケットを受信するまで、Ｓ４８の処理を繰り返す（Ｓ４９：Ｎｏ）。そして、受領確認パケットにより、受信側装置２０が全てのパケットを受信したことを検出した時点で送信処理を完了する（Ｓ４９：Ｙｅｓ）。
【００４１】
図４は、本発明の一実施形態におけるデータ伝送の概略を示す概念図である。同図に示すように、本実施形態では、送信側装置１０から受信側装置２０に対して、データパケットを、回線速度を超えて連続的に送信する。ネットワークＮ上のルータ等のバッファ３０で処理しきれないパケットは捨てられる（矢印３２）が、送信側装置１０からルータ等のバッファ３０に絶え間なくパケットが来るため、この速度が速ければ速いほど、送信側装置１０から送信されたパケットがルータ等のバッファ３０に入る確率が上がる（矢印３４）。受信側装置２０は、パケットを受信すると、受領確認（Ａｃｋ）パケットを返送するが、このとき、複数個分のデータパケットの受領確認を、１つの受領確認パケットにまとめて送信側装置１０に返送する。
【００４２】
図５及び図６は、本発明の一実施形態に係るデータ伝送方式のアルゴリズムを説明するための模式図である。
【００４３】
図５は、送信側装置１０からのデータの転送速度が８．１９２Ｍｂｐｓ、ペイロードのサイズは１０２４バイト、すなわち１ミリ秒毎に絶えずデータパケットが送信され続けるものとし、ＲＴＴ＝０ミリ秒と仮定している。例えば、パケット番号１のデータパケットは送信時刻１ミリ秒に送信され、パケット番号２のデータパケットは送信時刻２ミリ秒に送信され、以降、パケット番号２５９のデータパケットまで１ミリ秒毎に送信されている。送信されたデータパケットは、パケット番号と送信時刻とが対応付けて記録される。また、送信時刻に閾値β（本実施例では、β＝２００ミリ秒とする。）を足した値が、再送判定時刻である。なお、説明の便宜上、図５では、送信時刻と再送判定時刻とを併記している。
【００４４】
一方、受信側装置２０は、送信側装置１０から送信されたデータパケットを受信する。同図では、パケット番号１のデータパケットが受信時刻１ミリ秒に受信され、パケット番号３のデータパケットが受信時刻３ミリ秒に受信され、以降、データ伝送の遅延が生じることなく、パケット番号２５９のデータパケットまで１ミリ秒毎にパケットを受信している。しかし、パケット番号２のデータパケットは、パケットロスのため、受信側装置２０に受信されていない。
【００４５】
このとき、受信側装置２０は、６４個のデータパケットを受信するたびに、この６４個のデータパケットの受領確認を１つの受領確認パケットにまとめて、送信側装置１０に返送する。受領確認パケット５１は、パケット番号１及び３〜６５のデータパケットの受領確認が１つにまとめられている。パケット番号６５のデータパケットは、受信時刻６５ミリ秒に受信され、このパケットの受信後に、この場合は処理に１ミリ秒かかったと仮定して、時刻６６ミリ秒に受領確認パケット５１が送信側装置１０に返送される。
【００４６】
送信側装置１０は、受領確認パケット５１を受信すると、当該パケットに含まれるパケット番号に基づいて、受信側装置２０で受信されたデータパケットを特定し、パケット番号に対応付けて受信の済または未済を表すフラグを立てる。図５の例では、パケット番号１及び３〜６５に受信「済」フラグを立てる。これにより、受信側装置２０が受信したデータパケット及び受信していないデータパケットが管理される。
【００４７】
続けて、受領確認パケットに含まれる受領済みパケットのうち最終のパケット（最も直近に送信されたパケット）の送信時刻と、受信が未済のパケットの再送判定時刻とが比較される。受領確認パケット５１から得られる応答済み最終パケット送信時刻は６５ミリ秒であり、受信が未済のパケット番号２の再送判定時刻は２０２ミリ秒である。応答済み最終パケット送信時刻（６５ミリ秒）がパケット番号２の再送判定時刻（２０２ミリ秒）を超えていないので、パケット２はまだ再送不要と判断される。
【００４８】
この間も、送信側装置１０から受信側装置２０へのデータパケットの送信は絶えず続き、時刻１２９ミリ秒のときパケット番号１２９のデータパケットが受信され、これにより、受領確認を未送信のものがパケット番号６６からパケット番号１２９までの計６４個たまった状態になる。そこで、時刻１３０ミリ秒のときに受領確認パケット５２が受信側装置２０から送信側装置１０に送信される。この受領確認パケット５２は、今回新たに発生したパケット番号６６〜１２９の６４個のデータパケットの受領確認のみならず、前回送信したパケット番号１及び３〜６５の受領確認も含む。送信側装置１０は、受領確認パケット５２を受信すると、このパケットに含まれるパケット番号に基づいて、パケット番号６６〜１２９の受信「済」フラグをたてる。その後、応答済み最終パケット送信時刻の１２９ミリ秒と、まだ受信されていないパケット番号２の再送判定時刻２０２ミリ秒とが比較され、応答済み最終パケット送信時刻（１２９ミリ秒）がパケット番号２の再送判定時刻（２０２ミリ秒）を超えていないので、パケット２はまだ再送不要と判断される。
【００４９】
その後も同様に処理が続けられ、データパケットの送信は引き続き絶えず行われ、パケット番号１３０〜１９３の受領確認を含む受領確認パケット５３が受信側装置２０から送信側装置１０に送信される。この受領確認パケット５３を受信した送信側装置１０では、パケット番号１３０〜１９３が受信済みと判断される。また、応答済み最終パケット送信時刻（１９３ミリ秒）がパケット番号２の再送判定時刻（２０２ミリ秒）を超えていないので、パケット２はまだ再送不要と判断される。
【００５０】
その後、パケット番号１９４〜２５７の受領確認を含む受領確認パケット５４が受信側装置２０から送信される。送信側装置１０が受領確認パケット５４を受信して、パケット番号１９４〜２５７の受信「済」フラグを立てた後、応答済み最終パケット送信時刻と、受信が未済のパケット番号２の再送判定時刻とが比較される。このとき、応答済み最終パケット送信時刻（２５７ミリ秒）がパケット番号２の再送判定時刻（２０２ミリ秒）を超えているので、再送が必要と判断される。つまり、パケット番号２のパケットが送信されてから２００ミリ秒後に送信されたデータパケットですら既に受信されているので、パケット２はパケットロスしたものと判断され、再送されることになる。再送処理を受領確認パケット５４の受信直後に行ったとしても、すでに送信しようとするパケットデータが送信側装置１０のバッファにたまっているので、実際にパケット番号２のデータパケットが再送されるのは、この例では、時刻３００ミリ秒である。
【００５１】
再送処理の間、及び、再送処理の後も、送信側装置１０はデータパケットを送信し続け、受信側装置２０はパケット番号２５８〜３２１の受領確認を含む受領確認パケット５５を送信する。送信側装置１０は受領確認パケット５５を受信して、受信「済」パケットの管理と再送判定処理を実施する。
【００５２】
図６は、図５と同様のセッティングの実施例において、途中で、データ伝送の遅延が発生した場合の実施例である。同図の例では、時刻１２９ミリ秒までは、図５と同じ処理が行われる。すなわち、送信側装置１０からは１ミリ秒ごとにデータパケットが送信され続ける。受信側装置２０は、受領確認パケット６１と６２を返している。そして、パケット番号２のデータパケットがパケットロスしている。
【００５３】
このような状況で、図６の例では、パケット番号１２９のパケットを受信した後、データ伝送の遅延が発生し、パケット番号１３０のデータパケットを受信したのは５００ミリ秒後、すなわち時刻６３０ミリ秒であり、その後、１ミリ秒毎に１つのデータパケットが受信されている。
【００５４】
このとき、受領確認パケット６３は、時刻６９４ミリ秒で受信側装置２０から送信されている。送信側装置１０は受領確認パケット６３を受信すると、受領確認パケット６３に含まれるパケット番号に基づいて、パケット番号１３０〜１９３が受信済みと判断される。また、応答済み最終パケット送信時刻（１９３ミリ秒）がパケット番号２の再送判定時刻（２０２ミリ秒）を超えていないので、パケット２はまだ再送不要と判断される。
【００５５】
その後、パケット番号１９４〜２５７の受領確認を含む受領確認パケット６４が、時刻７５８ミリ秒に、受信側装置２０から送信される。送信側装置１０が受領確認パケット６４を受信して、パケット番号１９４〜２５７の受信「済」フラグを立てた後、応答済み最終パケット送信時刻と、受信が未済のパケット番号２の再送判定時刻とが比較される。このとき、応答済み最終パケット送信時刻（２５７ミリ秒）がパケット番号２の再送判定時刻（２０２ミリ秒）を超えているので、再送が必要と判断される。そして、例えば時刻８００ミリ秒に、パケット番号２のデータパケットが再送される。
【００５６】
図５と図６を比較すると明らかなように、本実施形態では、仮にネットワークが混雑して大幅な遅延が発生しても、比較対象が変わらないので、問題にならない。これに対し、通常のデータ伝送方式では、ネットワークにデータ転送の遅延が生じた時点で、データパケットの送信が中断され、輻輳を回避するためにデータ伝送速度を落として、パケットの再送処理が行われることになるため、データの伝送時間が遅くなる。
【００５７】
このように、本発明においては、パケットロスや遅延のゆらぎは発生するものという前提に立ち、回線のキャパシティよりも速い速度でパケットを送り込む。これにより、スイッチのバッファに空きが出た際に自分のパケットがバッファに入る確率を上げることが出来る。
【００５８】
実際にパケットロスが発生した場合、そのことを素早く検知し、再送を行わなければならないが、「パケットを送信後一定時間を経過しても受領確認（Ａｃｋ）が来ない場合にパケットロスとする」といった従来のＴＣＰなどにおける制御方式だと、遅延に揺らぎが発生した場合に実際はパケットロスしていなかったのに待ち時間の閾値を越えてしまう場合がある。実際、スイッチのバッファがいっぱいになると、遅延量が数百ミリ秒以上、酷いときには１秒を超えることもあり、それだけの揺らぎが発生することを考慮しなければならない。また、従来の技術では、「遅延の発生」＝「回線混雑度の増加」＝「パケットロスの発生確率の上昇」と考え、遅延が発生しないように制御するものがほとんどであった。
【００５９】
これに対し、本発明では、パケットロスや遅延は発生するものという前提で通信が制御され、どれだけ揺らぎや遅延が発生しても問題が発生しない方式として、「パケットを連続送信後、受領確認（Ａｃｋ）が返って来たパケットより前に送信したが受領確認が返ってきていないパケットをパケットロスとする」という制御方式を採用している。パケットの受領確認が返ってくる時間を予定していないという点で、従来の制御方式とは異なる制御方式である。ただし、実際には、パケットがリオーダーで届く場合もあるので、パケットロスと判定する時刻に若干の遊びを持たせることが好ましい。これにより、受信側ですでに受信済みのパケットを再度受信してしまうことがほぼなくなり、非常に効率の良い転送が可能となる。
【００６０】
また、本高速転送プロトコルは、回線のキャパシティをほとんど使い切ってしまうため、自分が専有して良い回線であれば問題ないが、他者と共有する回線の場合、問題が発生する場合がありうる。そのため、転送効率指定を可能とすることが好ましい。これは、例えば、７０％と指定した場合、回線のキャパシティの７０％まで使用して転送する方式である。
【００６１】
そのためには、定期的かつ瞬間的に（例えば１０秒に１秒間）、回線のキャパシティを計るため、速い速度でパケットを投げ、そこで得られたレート情報に転送効率を掛けたレートを通常の上限レートとして制御する。これは、瞬間的に回線を圧迫するが、他の時間は回線に空きがあるため、他の通信が途切れてしまうことはない。
【００６２】
さらに、サーバに対し、ＵＤＰの１ポートのみで、データ転送および制御を行うことが好ましい。これにより、クライアントやサーバがＮＡＴ環境であっても問題なくデータ転送が可能である。
【００６３】
次に、本発明の一実施形態によるデータ伝送方式を利用した複数拠点配信処理について説明する。
【００６４】
図７は、本発明の一実施形態に係るデータ伝送方式を利用した複数拠点配信システム８０のアーキテクチャを示す図である。複数拠点配信システムは、送信側装置１０と受信側装置２０と複数の送受信装置７０とがネットワークＮを介して接続されて構成される。
【００６５】
送信側装置１０、受信側装置２０、及びネットワークＮは上述の例と同じ構成であるので詳細を省略する。送受信装置７０は、送信側装置１０の機能と受信側装置２０の機能を含んで構成される。そして、送信側装置１０（送受信装置７０に含まれる送信側装置１０を含む）と受信側装置２０（送受信装置７０に含まれる受信側装置２０を含む）の間を本発明による高速データ伝送方式で通信を制御し、これらを数珠繋ぎに直列的に繋ぎ合わせることによって複数拠点配信処理を実現している。
【００６６】
図８は、本発明の一実施形態に係る送信側装置１０、受信側装置２０、及びこれらを含む送受信装置７０の機能構成を示すブロック図である。
【００６７】
同図に示すように、送受信装置７０は受信側装置２０と送信側装置１０とが一つの機器に納められている。そして、受信側装置２０のパケット受信モジュール２１で受信したデータパケットが、そのまま同一の機器内にある送信側装置１０のパケット送出モジュール１２に渡される。その他、送信側装置１０及び受信側装置２０の機能構成は上述の実施形態と同様である。
【００６８】
図９は、本発明の一実施形態における複数拠点配信処理の概略を示すフローチャートである。なお、本実施例では、Ａ拠点から、Ｂ拠点を経由して、Ｃ拠点に配信する場合を想定している。なお、同図は一例にすぎず、実際は拠点数に制限はない。
【００６９】
まず、Ａ拠点はＢ拠点に対し、上述の高速データ転送プロトコルを用い、データ転送を開始する（Ｓ９１）。
【００７０】
Ｂ拠点は、上述の高速データ伝送における受信側装置２０と同様の処理を行いつつ、送信側装置１０としても機能し、Ａ拠点から受信したデータパケットをＣ拠点に転送する（Ｓ９２）。ただし、Ｂ拠点がすでに受信済みのパケットを再度受信した場合は、Ｃ拠点への転送は行わない。Ｂ拠点とＣ拠点間では、上述の高速データ伝送における送信側装置１０と受信側装置２０と同様に、経路中でパケットロスが発生した場合は、Ｂ拠点から再送処理を行う。拠点数が多い場合でも、上記のＢ拠点に相当する拠点が増えるだけで、全体の効率としてはほとんど変わらない。
【００７１】
このように、上述の受信側装置２０と送信側装置１０の機能を備え、上述のデータ伝送方式による受信と送信をほぼ同時に行うことのできる送受信装置７０を前提に、これらの拠点間を数珠つなぎにデータ転送することで、複数拠点に高速略同時データ伝送を可能としている。なお、光ファイバー等の全二重で上下対象の回線網であれば、上下の両方の帯域が活用できる。従来の技術や製品では、転送をファイル単位で扱うため、ひとつのファイルの転送が終らないと、次の転送が行えなかったり、ＴＣＰを用いているため、パケットロスや遅延のゆらぎにより転送レートが劣化するものがほとんどであったところ、本複数拠点配信方式では、上述の高速データ伝送の制御プロトコル、および、各拠点が同程度の回線に接続されていることを前提とし、サーバは、パケット単位で受信したデータを、次のサーバにそのまま転送する。上下対称の回線であれば、受信と送信は同時に行えるため、効率はほとんど落ちない。これにより、複数の拠点に対し、１対向のみで転送する場合と比べて、ほとんど同じ時間で複数の拠点に高速で転送が可能である。
【００７２】
以上、詳述したとおり、本発明は、インターネット等のＩＰ通信網を用いて、回線のキャパシティいっぱいまで活用して高速に拠点から拠点へデータを転送するためのプロトコルおよび制御方式に関する。本発明によれば、パケットロスが頻発するような回線であっても、ほとんど影響を受けずに安定したデータ伝送が可能である。
【００７３】
具体的には、ＵＤＰのようなＡｃｋ応答を要しないプロトコルを用いて、信頼性を確保しつつ、高速なデータ伝送を可能とする制御方式であり、本発明の実施形態はさらにその効率を高め、回線速度、回線品質にほとんど影響されず、ユーザが回線にあわせた特別な設定を行うこともなく、回線のキャパシティいっぱいまで利用して高速なデータ伝送を可能とする制御方式である。
【００７４】
また、このデータ伝送システムを応用し、ある拠点から複数拠点を数珠つなぎにパケットを中継し、データの同時伝送を可能とする。本実施形態によれば、特別な回線は必要なく、一般的なＢフレッツに代表される光ファイバーブロードバンドを用いて回線のキャパシティいっぱいまで利用した上で、複数拠点への高速な同時転送を可能としている。
【００７５】
なお、本発明は、上記した実施の形態に限定されるものではなく、本発明の要旨を逸脱しない範囲内において、他の様々な形で実施することができる。このため、上記実施形態はあらゆる点で単なる例示にすぎず、限定的に解釈されるものではない。例えば、上述の各処理ステップは処理内容に矛盾を生じない範囲で任意に順番を変更して又は並列に実行することができる。
【符号の説明】
【００７６】
１…データ伝送システム、１０…送信側装置、１１…送出時刻記録モジュール、１２…パケット送出モジュール、１３…送出レート調整モジュール、１４…受領確認受信モジュール、１５…再送判定モジュール、２０…受信側装置、２１…パケット受信モジュール、２２…受信パケット番号記録モジュール、２３…受領確認送信モジュール、２４…過去分受領確認情報記憶モジュール、２５…ソート処理モジュール、２６…受信レート計算モジュール、２７…タイマー、７０…送受信装置、８０…複数拠点配信システム
【技術分野】
【０００１】
本発明は、データを高速に伝送する通信制御方式に関する。また、当該通信制御方式を利用した複数拠点データ配信方式に関する。
【背景技術】
【０００２】
従来、ファイルの伝送にはＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）が一般的であるが、ＴＣＰでは一定量のパケットを投げたあと、応答パケットを待つため、拠点間の往復遅延（ＲＴＴ）が通信速度に非常に影響する。標準的な６４ＫＢのウィンドウサイズで、東京−大阪間（ＲＴＴが２０ｍｓと仮定）の場合、理論上、どんなに速い回線を用意したとしても、２５．６Ｍｂｐｓまでしか速度がでない。ウィンドウサイズを大きくすれば、一度に送信できるデータのサイズが増えるため理論上の通信速度は上がるが、パケットロスが発生した場合には、再送に時間がかかり転送速度が遅くなるなど、かえって転送効率が落ちてしまう場合もある。
【０００３】
一方、ＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）を用いてデータ転送を行う技術自体は既存の技術が存在するが、利用する回線に対して最適なパラメータを設定しなければならないものや、パケットロスや遅延のゆらぎが発生すると転送速度が低下してしまうもの、回線のキャパシティいっぱいまでは使いきれないものなど、従来では解決できていない課題が多い。
【０００４】
また従来、複数拠点に同時伝送を行うには、中央にサーバを置き各拠点に配信する方式が知られている。また、マルチキャストというプロトコルも存在するが、一般的なインターネットでの適応は難しく、または、パケットロスに対する制御などが別途必要になる（特許文献１参照）。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００８−８５９３２号公報
【特許文献２】特開２０００−２０７２９８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
従来のデータ伝送方式の多くは、パケットロスを輻輳と定義し、パケットロスが発生した場合には、輻輳が起きているものとみなしている。そして、パケットロスが発生しないように制御したり、また、パケットロスが発生した場合には、輻輳が抑止されるように転送レートやパケット転送間隔を制御したりすることが一般的である。
【０００７】
このため、従来のデータ伝送方式は、パケットロスが生じると通信速度が大幅に低下してしまうという課題を有している。他にも、従来のデータ伝送方式は、パケット遅延のゆらぎにより通信速度が低下する、通信開始当初の通信速度が遅い、ＲＴＴが大きいと通信速度が影響を受けてしまう、といった点が指摘されている。
【０００８】
また、複数拠点にデータをほぼ同時に伝送する配信方式においては、中央サーバをおく方式では、複数拠点同時配信に耐えうる高性能な中央サーバと、配信先の数に応じた広帯域な回線が必要である。マルチキャスト配信を用いる場合、特別な回線が必要となり、かつ、パケットロスに対応するためサーバから個別に再送などを制御しなければならない。
【０００９】
本発明はかかる実情に鑑みてなされたものであり、データ伝送中にパケットロスや遅延のゆらぎが発生することを前提とし、パケットロス等が生じても、データ伝送速度が大きく低下することのない高速なデータ伝送方式を提供しようとするものである。また、このようなデータ伝送方式を利用して、複数拠点にデータをほぼ同時に配信する配信方式を提供しようとするものである。
【課題を解決するための手段】
【００１０】
本発明の一実施形態に係るデータ伝送方法は、送信側装置から受信側装置に対してパケット通信網を介してデータを伝送する方法であって、送信側装置が、受信側装置に対して複数のパケットを連続的に送出する第一のステップと、受信側装置から送出された、受信側装置が複数のパケットのうち少なくとも一部を受領したことを示す受領確認を受信する第二のステップと、受領確認によって受信先による受領が確認されたパケットよりも前に送出されたパケットであり、かつ、受領確認を受信していないパケットを再送する第三のステップと、を備える。すなわち、本発明の一実施形態においては、パケットを連続送信後、受領確認（Ａｃｋ）が返って来たパケットより前に送信したパケットをパケットロスとみなすことにより、従来のデータ伝送方式とは異なり、送信後一定時間経過する前に受領が確認されなくても、パケットの再送を行わずに、そのままパケットを送信し続ける。ネットワークスイッチ等はパケットをバッファに受信してから処理を行うため、パケットを送り込む間隔を短くすればするほど、バッファにそのパケットが入る確率を上げることが出来る。本発明は、回線のキャパシティよりも速い速度でパケットを送り込むことで、より高速なデータ転送を可能としている。回線のキャパシティを溢れた分はパケットロスとなるが、本発明においては、パケットロスが起こることを前提としているため、データ伝送上の問題は生じない。
【００１１】
近年、ＩＰ網を構成している装置はほとんどがスイッチであり、装置内部にバッファを備えている。装置間は全二重で任意のタイミングで通信可能であり、送られてきたパケットはスイッチ内部のバッファに一旦溜められ、そのバッファから送るべき通信相手にパケット送信される。バッファがいっぱいにならない限り、同じ機器に対するパケットが複数個所から送られてきたとしても、順番に処理されるだけでパケットロスは発生しない。ただし、遅延時間は変化する。バッファがいっぱいになると、バッファに空きができるまで、その後に届いたパケットは破棄されてしまう（パケットロス）が、バッファに入った分のパケットについては正しく処理される。したがって、従来の通信制御方式が前提としている「輻輳」は、誰も正常な通信をできないような状況のことを指すが、そのような状況は、現在の装置間では発生しにくい。
【００１２】
好適には、第三のステップは、受領確認によって受信先による受領が確認されたパケットのうち最も直近に送出されたパケットの送出時刻よりも所定時間以上前に送出されたパケットを再送する。パケットがリオーダーで届く場合もあるので、パケットロスと判定する時刻に若干の遊びを持たせることにより、受信側ですでに受信済みのパケットを再度受信してしまうことがほぼなくなり、効率の良いデータ伝送が可能となる。
【００１３】
第一のステップは、パケットを送出する際に、当該パケットを識別可能な識別情報と当該パケットの送出時刻とを対応付けて記録するステップを含むことが好ましい。好適には、受領確認は、受信先が受領したパケットの識別情報を含む。さらに、受領確認は、過去所定回分の受領確認に含まれていた識別情報を含むことが好ましい。過去数回分の受領確認情報を、受領確認パケットに入れて送付することにより、受領確認パケットのパケットロスも考慮したデータ伝送方式を提供することができる。
【００１４】
また、本発明の一実施形態に係るデータ配信方法は、上述のデータ伝送方法によるデータ送受信が可能な複数の送受信装置の間で、数珠つなぎにデータ伝送を行うことによって、複数の送受信装置間で略同時にデータ伝送を行う。すなわち、上述のデータ伝送方法を基本技術として利用して、Ａ拠点からＢ拠点に投げたパケットを、Ｂ拠点はＣ拠点に中継する、といった処理を繰り返す。基本的には１対１の通信のため、中央サーバは必要ない。また、特別な広帯域回線は必要なく、一般的なＢフレッツに代表される上下対称な光ファイバーブロードバンド回線を利用可能である。さらに、パケット単位で中継されるため、最小単位でデータ配信が行われる。これにより、ファイル全体が転送完了するのを待つことなく、パケット単位でデータ転送できるため、１対１で通信するのとほぼ同等な時間で、複数拠点への同時伝送が可能である。
【発明の効果】
【００１５】
本発明のデータ伝送方式によれば、データ伝送中にパケットロスや遅延のゆらぎが起こっても、データ伝送速度が大きく低下することがなく、高速にデータを伝送可能なデータ伝送方式を提供することができる。また、このようなデータ伝送方式を利用して、複数拠点にデータを略同時に配信する配信方式を提供することが可能である。
【００１６】
より具体的には、本発明の所定の実施形態によれば、インターネット等のＩＰ通信網を用いて、回線のキャパシティいっぱいまで活用して高速に拠点から拠点へデータを転送するためのプロトコルおよび制御方式を提供できる。パケットロスが頻発するような回線であっても、ほとんど影響を受けずに安定したデータ転送が可能である。また、回線速度、回線品質にほとんど影響されず、ユーザが回線にあわせた特別な設定を行うこともなく、回線のキャパシティいっぱいまで利用して高速なデータ転送が可能である。
【００１７】
また、本発明の所定の実施形態によれば、上述のデータ伝送方式を応用し、ある拠点から複数拠点を数珠つなぎにパケットを中継し、データの同時伝送を可能としている。特別な回線は必要なく、一般的なＢフレッツに代表される光ファイバーブロードバンドを用いて回線のキャパシティいっぱいまで利用した上で、複数拠点への高速な同時転送を可能としている。
【図面の簡単な説明】
【００１８】
【図１】本発明の一実施形態に係るデータ伝送システム１のアーキテクチャを示す図である。
【図２】本発明の一実施形態に係る送信側装置１０及び受信側装置２０の機能構成を示すブロック図である。
【図３】本発明の一実施形態におけるデータ伝送処理の制御プロトコルを示すフローチャートである。
【図４】本発明の一実施形態におけるデータ伝送の概略を示す概念図である。
【図５】本発明の一実施形態に係るデータ伝送方式のアルゴリズムを説明するための模式図である。
【図６】本発明の一実施形態に係るデータ伝送方式のアルゴリズムを説明するための模式図である。
【図７】本発明の一実施形態に係るデータ伝送方式を利用した複数拠点配信システムのアーキテクチャを示す図である。
【図８】本発明の一実施形態に係る送信側装置１０、受信側装置２０、及びこれらを含む送受信装置７０の機能構成を示すブロック図である。
【図９】本発明の一実施形態における複数拠点配信処理の概略を示すフローチャートである。
【発明を実施するための形態】
【００１９】
以下、本発明の実施の形態について図面を参照しつつ詳細に説明する。なお、同一の要素には同一の符号を付し、重複する説明を省略する。また、以下の実施の形態は、本発明を説明するための例示であり、本発明をその実施の形態のみに限定する趣旨ではない。さらに、本発明は、その要旨を逸脱しない限り、さまざまな変形が可能である。
【００２０】
図１は、本発明の一実施形態に係るデータ伝送システム１のアーキテクチャを示す図である。データ伝送システム１は、送信側装置１０と受信側装置２０とがネットワークＮを介して接続されて構成される。
【００２１】
送信側装置１０は、ネットワークＮを介して受信側装置２０に向けてデータを送信するための装置である。受信側装置２０は、送信側装置１０から送信されたデータを受信するための装置である。送信側装置１０と受信側装置２０はそれぞれ、専用の装置により構成してもよいし、汎用のコンピュータが送信側装置１０及び／又は受信側装置２０の機能を備えるよう構成してもよい。
【００２２】
ネットワークＮは、送信側装置１０と受信側装置２０との間でデータを伝送するための通信回線である。これはＬＡＮやインターネット網に代表されるパケット通信網（またはその組み合わせ）であればよく、物理層には左右されない。よって、物理層としては、イーサネット（登録商標）、無線通信網、公衆電話通信網、一般電話回線網、その他の通信回線、それらの組み合わせ等のいずれであってもよい。また、各通信網間を接続するためのゲートウェイや各種基地局、交換機などもネットワークＮに含まれ得る。
【００２３】
図２は、本発明の一実施形態に係る送信側装置１０及び受信側装置２０の機能構成を示すブロック図である。
【００２４】
送信側装置１０は、送出時刻記録モジュール１１と、パケット送出モジュール１２と、送出レート調整モジュール１３と、受領確認（Ａｃｋ）受信モジュール１４と、再送判定モジュール１５とを含んで構成される。
【００２５】
送出時刻記録モジュール１１は、パケット単位で、パケットを識別するためのパケット番号と、当該パケットを送出した日時に関する送信時刻情報とを対応付けて記録する。なお、パケット番号に換えて、パケットを識別可能な任意の情報を利用可能である。パケット送出モジュール１２は、送信するデータをパケットに分けて、ネットワークＮに送出する。送出レート調整モジュール１３は、ネットワークＮに送信するビットレート等、パケットの送出レートを調整する。受領確認（Ａｃｋ）受信モジュール１４は、受信側装置２０から受領確認（Ａｃｋ）を受信して、受信側装置２０がパケットを受信したか否かをパケット番号毎に管理する。再送判定モジュール１５は、所定の条件を満たすパケットを受信側装置２０に再送する。
【００２６】
受信側装置２０は、パケット受信モジュール２１と、受信パケット番号記録モジュール２２と、受領確認（Ａｃｋ）送信モジュール２３と、過去分受領確認（Ａｃｋ）情報記憶モジュール２４と、ソート処理モジュール２５と、受信レート計算モジュール２６と、タイマー２７とを含んで構成される。
【００２７】
パケット受信モジュール２１は、送信側装置１０から送出されたパケットを受信する。受信パケット番号記録モジュール２２は、受信したパケットのパケット番号を記録する。受領確認（Ａｃｋ）送信モジュール２３は、パケットを受領したときに、受領したパケットの受領確認を送信側装置１０に向けて送信する。このとき、受領したパケットを一定個数分まとめて、又は、所定時間が経過した場合にそれまでに受領したパケットをまとめて、受領確認を返送することが好ましい。過去分受領確認（Ａｃｋ）情報記憶モジュール２４は、過去に送出した受領確認を、パケット番号と対応付けて記憶する。ソート処理モジュール２５は、受信したパケットを結合してデータを読み出すためのものである。受信レート計算モジュール２６は、受信したパケットに基づいて、受信レートを計算する。タイマー２７は、受領時間等を測定し、また、受領確認を送信するタイミングを計るためのものである。
【００２８】
次に、上記のように構成されるデータ伝送システム１の動作の概要について説明する。
【００２９】
図３は、本発明の一実施形態におけるデータ伝送処理の制御プロトコルを示すフローチャートである。本実施形態では、データの伝送及び制御にＵＤＰプロトコルのみを用いるものとする。そのため、特許文献２にあるようなＴＣＰを制御、ＵＤＰをデータ転送に用いるようなプロトコルと比較して、ＴＣＰ分の帯域を確保する必要はなく、回線キャパシティをフルに利用できる。なお、コネクションレスのデータグラム型プロトコルであれば、ＵＤＰプロトコルに限らず適用可能である。送信データのパケットは、ＵＤＰパケットのヘッダを除いた先頭４バイトをパケット番号とする。先頭４バイトを除いた残りのデータを、転送すべきデータの一部（ペイロード）とする。ペイロードのサイズは、送るべきデータの最終パケットを除き、固定の大きさとする。しかし、パケット番号やペイロードのサイズ等は、これらに限定されない。
【００３０】
送信側装置１０のパケット送出モジュール１２は、送信側装置１０から受信側装置２０に転送するデータをペイロードサイズごとに分け、パケット番号を付加した上で、受信側装置２０にパケット送出する（Ｓ４１）。その際、送出時刻記録モジュール１１は、パケット送信をした時刻をパケット番号毎に記録しておく。
【００３１】
データ転送開始当初、送信側装置１０から受信側装置２０までの回線がどの程度のキャパシティがあるのか不明であるため、送信側装置１０は可能な限り速い速度で次々にパケットを送出する。なお、ネットワークＮのキャパシティを超えた分のパケットは、ネットワークＮ上で破棄されることになる。
【００３２】
受信側装置２０のパケット受信モジュール２１がパケットを受信すると、送信側装置１０から届いたパケットをソート処理モジュール２５がパケット番号順にソートし、パケット番号が連続して受信できた部分について、ディスク装置や後の処理系にデータを出力する（Ｓ４２）。ただし、受信パケットのパケット番号がすでに受信済みのパケット番号だった場合は、この処理を行わない。
【００３３】
受信側装置２０の受信パケット番号記録モジュール２２は、届いたパケットのパケット番号を記録する。受領確認送信モジュール２３は、前回の受領確認パケット送付から、一定個数（例えば６４個）パケットが届いた場合、または、直近の通信速度から換算して一定個数のパケットが届くはずの時間に所定時間を加えた時間が経過した場合に、送信側装置１０に対し受領確認（Ａｃｋ）を送付する（Ｓ４３）。送付した受領確認のログは、過去分受領確認情報記憶モジュール２４に記録される。なお、届いたパケットのパケット番号を記録する際、過去に受信済みのパケット番号も処理対象とする。
【００３４】
受領確認（Ａｃｋ）パケットは、ＵＤＰパケットのヘッダを除いた先頭４バイトを受領確認パケット番号とし、その後ろに、直近の一定時間（例えば、１／３秒をタイマー２７で計測）で算出したビットレートの情報を付加する。そして、その後ろに、届いたパケット番号（４バイト）を列挙する。パケット番号が連続している場合は、連続しているパケット番号の先頭と最終のパケット番号に連続フラグをつけて、受領確認パケットのサイズを圧縮する。また、受領確認パケットがパケットロスになる可能性を考慮し、過去Ｎ回分（例えば、Ｎ＝１）の受領確認パケットに列挙したパケット番号情報を付加する。これにより、受領確認パケットが連続で（Ｎ＋１）回パケットロスしない限り、受領確認情報は正しく送信側装置１０に伝わる。ビットレートの情報は、受信レート計算モジュール２６が、一定時間に受信したパケット数（重複パケットを含む）を用いて算出する。過去の受領確認は過去分受領確認情報記憶モジュール２４から取得される。
【００３５】
なお、本実施形態においては、データ伝送中にパケットロスが発生することを前提としているため、受信されたデータは歯抜け状態となることが多い。しかし、ソート処理モジュール２５からディスク装置等にデータを出力する際には、シーケンシャルにデータを書き出さないと性能が劣化してしまう。そのため、受信側装置２０は適切な量のバッファを持ち、歯抜け状態が解消された部分までをシーケンシャルデータとして、ディスク装置に書き出したり、後の処理系に出力したりする。
【００３６】
送信側装置１０は、受領確認パケットが届くと、受領確認受信モジュール１４が受領確認パケットを受信する（Ｓ４４）。そして、再送判定モジュール１５は、受領確認パケットに列挙された受信済みパケット番号について、それぞれのパケットを送信側装置１０が元々送付した時刻のうち最も直近の時刻を、「応答済み最終パケット送信時刻」（Ｔ）とし、まだ受領確認が返ってきていないパケットの送信時刻（Ｓ）との差（Ｔ−Ｓ）が、所定の閾値β（例えば、β＝２００ミリ秒）以上になった場合に、その受領確認が返ってきていないパケットについて、次に新規に送るべきパケットに割り込む形で、再送を行う（Ｓ４５）。なお、再送時にも、そのパケットを再送した時刻を記録しておく。
【００３７】
送信側装置１０の送出レート調整モジュール１３は、受領確認パケットに記載された直近のビットレート情報をもとに、次以降、パケットを送出する時間間隔を制御する（Ｓ４６）。具体的には、転送開始からのビットレート情報で最も高い数値（最大値）に対し、θ倍（例えば、θ＝１．２）の速度でパケットを送出する。本発明においては、パケットロスは発生することが前提であるため、回線のキャパシティを超えてパケットを送信し、パケットロスが発生してもデータ伝送上の問題は生じない。また、通信開始当初、回線が過度に混雑していてあまり高いレートが出なかった場合でも、回線が空けば速度は回復する。逆に、通信開始当初、回線が空いていて、次第に混雑した場合でも、混雑した分の実転送速度は落ちるが、パケットロスが多めに発生するようになるだけであり、通信の信頼性には影響しない。仮に通信中に回線が混雑したとしても、本来、ビットレート情報の最大値までのキャパシティはあるはずであるため、転送速度を遅くすることはしない。
【００３８】
送信側装置１０は、送信すべきデータのパケットがまだ残っている場合（Ｓ４７：Ｎｏ）、上記Ｓ４１〜Ｓ４６の処理を繰り返してパケットを送信する。送信すべきデータの最後のパケットまで送信した場合（Ｓ４７：Ｙｅｓ）、送信データの終わりを示すパケットを送信し、さらに、受領確認がまだ返ってきていない（と送信側装置１０が認識している）パケットについて強制的に再送を行う（Ｓ４８）。この強制再送モードでは、受領確認が返ってきていないパケットを未送信と同じ状態として扱い、Ｓ４１〜Ｓ４７の処理を行う。転送をやめたり、一時停止したりすることはしない。なお、この送信データの終わりを示すパケットもパケットロス時は再送対象となる。
【００３９】
受信側装置２０は、全てのパケットを受信した場合、受信完了のステータスとするが、まだ送信側装置１０からパケットがまだ送られてくる場合は、受領確認パケットを返す処理は続行する。
【００４０】
送信側装置１０は、受領確認パケットを受信するまで、Ｓ４８の処理を繰り返す（Ｓ４９：Ｎｏ）。そして、受領確認パケットにより、受信側装置２０が全てのパケットを受信したことを検出した時点で送信処理を完了する（Ｓ４９：Ｙｅｓ）。
【００４１】
図４は、本発明の一実施形態におけるデータ伝送の概略を示す概念図である。同図に示すように、本実施形態では、送信側装置１０から受信側装置２０に対して、データパケットを、回線速度を超えて連続的に送信する。ネットワークＮ上のルータ等のバッファ３０で処理しきれないパケットは捨てられる（矢印３２）が、送信側装置１０からルータ等のバッファ３０に絶え間なくパケットが来るため、この速度が速ければ速いほど、送信側装置１０から送信されたパケットがルータ等のバッファ３０に入る確率が上がる（矢印３４）。受信側装置２０は、パケットを受信すると、受領確認（Ａｃｋ）パケットを返送するが、このとき、複数個分のデータパケットの受領確認を、１つの受領確認パケットにまとめて送信側装置１０に返送する。
【００４２】
図５及び図６は、本発明の一実施形態に係るデータ伝送方式のアルゴリズムを説明するための模式図である。
【００４３】
図５は、送信側装置１０からのデータの転送速度が８．１９２Ｍｂｐｓ、ペイロードのサイズは１０２４バイト、すなわち１ミリ秒毎に絶えずデータパケットが送信され続けるものとし、ＲＴＴ＝０ミリ秒と仮定している。例えば、パケット番号１のデータパケットは送信時刻１ミリ秒に送信され、パケット番号２のデータパケットは送信時刻２ミリ秒に送信され、以降、パケット番号２５９のデータパケットまで１ミリ秒毎に送信されている。送信されたデータパケットは、パケット番号と送信時刻とが対応付けて記録される。また、送信時刻に閾値β（本実施例では、β＝２００ミリ秒とする。）を足した値が、再送判定時刻である。なお、説明の便宜上、図５では、送信時刻と再送判定時刻とを併記している。
【００４４】
一方、受信側装置２０は、送信側装置１０から送信されたデータパケットを受信する。同図では、パケット番号１のデータパケットが受信時刻１ミリ秒に受信され、パケット番号３のデータパケットが受信時刻３ミリ秒に受信され、以降、データ伝送の遅延が生じることなく、パケット番号２５９のデータパケットまで１ミリ秒毎にパケットを受信している。しかし、パケット番号２のデータパケットは、パケットロスのため、受信側装置２０に受信されていない。
【００４５】
このとき、受信側装置２０は、６４個のデータパケットを受信するたびに、この６４個のデータパケットの受領確認を１つの受領確認パケットにまとめて、送信側装置１０に返送する。受領確認パケット５１は、パケット番号１及び３〜６５のデータパケットの受領確認が１つにまとめられている。パケット番号６５のデータパケットは、受信時刻６５ミリ秒に受信され、このパケットの受信後に、この場合は処理に１ミリ秒かかったと仮定して、時刻６６ミリ秒に受領確認パケット５１が送信側装置１０に返送される。
【００４６】
送信側装置１０は、受領確認パケット５１を受信すると、当該パケットに含まれるパケット番号に基づいて、受信側装置２０で受信されたデータパケットを特定し、パケット番号に対応付けて受信の済または未済を表すフラグを立てる。図５の例では、パケット番号１及び３〜６５に受信「済」フラグを立てる。これにより、受信側装置２０が受信したデータパケット及び受信していないデータパケットが管理される。
【００４７】
続けて、受領確認パケットに含まれる受領済みパケットのうち最終のパケット（最も直近に送信されたパケット）の送信時刻と、受信が未済のパケットの再送判定時刻とが比較される。受領確認パケット５１から得られる応答済み最終パケット送信時刻は６５ミリ秒であり、受信が未済のパケット番号２の再送判定時刻は２０２ミリ秒である。応答済み最終パケット送信時刻（６５ミリ秒）がパケット番号２の再送判定時刻（２０２ミリ秒）を超えていないので、パケット２はまだ再送不要と判断される。
【００４８】
この間も、送信側装置１０から受信側装置２０へのデータパケットの送信は絶えず続き、時刻１２９ミリ秒のときパケット番号１２９のデータパケットが受信され、これにより、受領確認を未送信のものがパケット番号６６からパケット番号１２９までの計６４個たまった状態になる。そこで、時刻１３０ミリ秒のときに受領確認パケット５２が受信側装置２０から送信側装置１０に送信される。この受領確認パケット５２は、今回新たに発生したパケット番号６６〜１２９の６４個のデータパケットの受領確認のみならず、前回送信したパケット番号１及び３〜６５の受領確認も含む。送信側装置１０は、受領確認パケット５２を受信すると、このパケットに含まれるパケット番号に基づいて、パケット番号６６〜１２９の受信「済」フラグをたてる。その後、応答済み最終パケット送信時刻の１２９ミリ秒と、まだ受信されていないパケット番号２の再送判定時刻２０２ミリ秒とが比較され、応答済み最終パケット送信時刻（１２９ミリ秒）がパケット番号２の再送判定時刻（２０２ミリ秒）を超えていないので、パケット２はまだ再送不要と判断される。
【００４９】
その後も同様に処理が続けられ、データパケットの送信は引き続き絶えず行われ、パケット番号１３０〜１９３の受領確認を含む受領確認パケット５３が受信側装置２０から送信側装置１０に送信される。この受領確認パケット５３を受信した送信側装置１０では、パケット番号１３０〜１９３が受信済みと判断される。また、応答済み最終パケット送信時刻（１９３ミリ秒）がパケット番号２の再送判定時刻（２０２ミリ秒）を超えていないので、パケット２はまだ再送不要と判断される。
【００５０】
その後、パケット番号１９４〜２５７の受領確認を含む受領確認パケット５４が受信側装置２０から送信される。送信側装置１０が受領確認パケット５４を受信して、パケット番号１９４〜２５７の受信「済」フラグを立てた後、応答済み最終パケット送信時刻と、受信が未済のパケット番号２の再送判定時刻とが比較される。このとき、応答済み最終パケット送信時刻（２５７ミリ秒）がパケット番号２の再送判定時刻（２０２ミリ秒）を超えているので、再送が必要と判断される。つまり、パケット番号２のパケットが送信されてから２００ミリ秒後に送信されたデータパケットですら既に受信されているので、パケット２はパケットロスしたものと判断され、再送されることになる。再送処理を受領確認パケット５４の受信直後に行ったとしても、すでに送信しようとするパケットデータが送信側装置１０のバッファにたまっているので、実際にパケット番号２のデータパケットが再送されるのは、この例では、時刻３００ミリ秒である。
【００５１】
再送処理の間、及び、再送処理の後も、送信側装置１０はデータパケットを送信し続け、受信側装置２０はパケット番号２５８〜３２１の受領確認を含む受領確認パケット５５を送信する。送信側装置１０は受領確認パケット５５を受信して、受信「済」パケットの管理と再送判定処理を実施する。
【００５２】
図６は、図５と同様のセッティングの実施例において、途中で、データ伝送の遅延が発生した場合の実施例である。同図の例では、時刻１２９ミリ秒までは、図５と同じ処理が行われる。すなわち、送信側装置１０からは１ミリ秒ごとにデータパケットが送信され続ける。受信側装置２０は、受領確認パケット６１と６２を返している。そして、パケット番号２のデータパケットがパケットロスしている。
【００５３】
このような状況で、図６の例では、パケット番号１２９のパケットを受信した後、データ伝送の遅延が発生し、パケット番号１３０のデータパケットを受信したのは５００ミリ秒後、すなわち時刻６３０ミリ秒であり、その後、１ミリ秒毎に１つのデータパケットが受信されている。
【００５４】
このとき、受領確認パケット６３は、時刻６９４ミリ秒で受信側装置２０から送信されている。送信側装置１０は受領確認パケット６３を受信すると、受領確認パケット６３に含まれるパケット番号に基づいて、パケット番号１３０〜１９３が受信済みと判断される。また、応答済み最終パケット送信時刻（１９３ミリ秒）がパケット番号２の再送判定時刻（２０２ミリ秒）を超えていないので、パケット２はまだ再送不要と判断される。
【００５５】
その後、パケット番号１９４〜２５７の受領確認を含む受領確認パケット６４が、時刻７５８ミリ秒に、受信側装置２０から送信される。送信側装置１０が受領確認パケット６４を受信して、パケット番号１９４〜２５７の受信「済」フラグを立てた後、応答済み最終パケット送信時刻と、受信が未済のパケット番号２の再送判定時刻とが比較される。このとき、応答済み最終パケット送信時刻（２５７ミリ秒）がパケット番号２の再送判定時刻（２０２ミリ秒）を超えているので、再送が必要と判断される。そして、例えば時刻８００ミリ秒に、パケット番号２のデータパケットが再送される。
【００５６】
図５と図６を比較すると明らかなように、本実施形態では、仮にネットワークが混雑して大幅な遅延が発生しても、比較対象が変わらないので、問題にならない。これに対し、通常のデータ伝送方式では、ネットワークにデータ転送の遅延が生じた時点で、データパケットの送信が中断され、輻輳を回避するためにデータ伝送速度を落として、パケットの再送処理が行われることになるため、データの伝送時間が遅くなる。
【００５７】
このように、本発明においては、パケットロスや遅延のゆらぎは発生するものという前提に立ち、回線のキャパシティよりも速い速度でパケットを送り込む。これにより、スイッチのバッファに空きが出た際に自分のパケットがバッファに入る確率を上げることが出来る。
【００５８】
実際にパケットロスが発生した場合、そのことを素早く検知し、再送を行わなければならないが、「パケットを送信後一定時間を経過しても受領確認（Ａｃｋ）が来ない場合にパケットロスとする」といった従来のＴＣＰなどにおける制御方式だと、遅延に揺らぎが発生した場合に実際はパケットロスしていなかったのに待ち時間の閾値を越えてしまう場合がある。実際、スイッチのバッファがいっぱいになると、遅延量が数百ミリ秒以上、酷いときには１秒を超えることもあり、それだけの揺らぎが発生することを考慮しなければならない。また、従来の技術では、「遅延の発生」＝「回線混雑度の増加」＝「パケットロスの発生確率の上昇」と考え、遅延が発生しないように制御するものがほとんどであった。
【００５９】
これに対し、本発明では、パケットロスや遅延は発生するものという前提で通信が制御され、どれだけ揺らぎや遅延が発生しても問題が発生しない方式として、「パケットを連続送信後、受領確認（Ａｃｋ）が返って来たパケットより前に送信したが受領確認が返ってきていないパケットをパケットロスとする」という制御方式を採用している。パケットの受領確認が返ってくる時間を予定していないという点で、従来の制御方式とは異なる制御方式である。ただし、実際には、パケットがリオーダーで届く場合もあるので、パケットロスと判定する時刻に若干の遊びを持たせることが好ましい。これにより、受信側ですでに受信済みのパケットを再度受信してしまうことがほぼなくなり、非常に効率の良い転送が可能となる。
【００６０】
また、本高速転送プロトコルは、回線のキャパシティをほとんど使い切ってしまうため、自分が専有して良い回線であれば問題ないが、他者と共有する回線の場合、問題が発生する場合がありうる。そのため、転送効率指定を可能とすることが好ましい。これは、例えば、７０％と指定した場合、回線のキャパシティの７０％まで使用して転送する方式である。
【００６１】
そのためには、定期的かつ瞬間的に（例えば１０秒に１秒間）、回線のキャパシティを計るため、速い速度でパケットを投げ、そこで得られたレート情報に転送効率を掛けたレートを通常の上限レートとして制御する。これは、瞬間的に回線を圧迫するが、他の時間は回線に空きがあるため、他の通信が途切れてしまうことはない。
【００６２】
さらに、サーバに対し、ＵＤＰの１ポートのみで、データ転送および制御を行うことが好ましい。これにより、クライアントやサーバがＮＡＴ環境であっても問題なくデータ転送が可能である。
【００６３】
次に、本発明の一実施形態によるデータ伝送方式を利用した複数拠点配信処理について説明する。
【００６４】
図７は、本発明の一実施形態に係るデータ伝送方式を利用した複数拠点配信システム８０のアーキテクチャを示す図である。複数拠点配信システムは、送信側装置１０と受信側装置２０と複数の送受信装置７０とがネットワークＮを介して接続されて構成される。
【００６５】
送信側装置１０、受信側装置２０、及びネットワークＮは上述の例と同じ構成であるので詳細を省略する。送受信装置７０は、送信側装置１０の機能と受信側装置２０の機能を含んで構成される。そして、送信側装置１０（送受信装置７０に含まれる送信側装置１０を含む）と受信側装置２０（送受信装置７０に含まれる受信側装置２０を含む）の間を本発明による高速データ伝送方式で通信を制御し、これらを数珠繋ぎに直列的に繋ぎ合わせることによって複数拠点配信処理を実現している。
【００６６】
図８は、本発明の一実施形態に係る送信側装置１０、受信側装置２０、及びこれらを含む送受信装置７０の機能構成を示すブロック図である。
【００６７】
同図に示すように、送受信装置７０は受信側装置２０と送信側装置１０とが一つの機器に納められている。そして、受信側装置２０のパケット受信モジュール２１で受信したデータパケットが、そのまま同一の機器内にある送信側装置１０のパケット送出モジュール１２に渡される。その他、送信側装置１０及び受信側装置２０の機能構成は上述の実施形態と同様である。
【００６８】
図９は、本発明の一実施形態における複数拠点配信処理の概略を示すフローチャートである。なお、本実施例では、Ａ拠点から、Ｂ拠点を経由して、Ｃ拠点に配信する場合を想定している。なお、同図は一例にすぎず、実際は拠点数に制限はない。
【００６９】
まず、Ａ拠点はＢ拠点に対し、上述の高速データ転送プロトコルを用い、データ転送を開始する（Ｓ９１）。
【００７０】
Ｂ拠点は、上述の高速データ伝送における受信側装置２０と同様の処理を行いつつ、送信側装置１０としても機能し、Ａ拠点から受信したデータパケットをＣ拠点に転送する（Ｓ９２）。ただし、Ｂ拠点がすでに受信済みのパケットを再度受信した場合は、Ｃ拠点への転送は行わない。Ｂ拠点とＣ拠点間では、上述の高速データ伝送における送信側装置１０と受信側装置２０と同様に、経路中でパケットロスが発生した場合は、Ｂ拠点から再送処理を行う。拠点数が多い場合でも、上記のＢ拠点に相当する拠点が増えるだけで、全体の効率としてはほとんど変わらない。
【００７１】
このように、上述の受信側装置２０と送信側装置１０の機能を備え、上述のデータ伝送方式による受信と送信をほぼ同時に行うことのできる送受信装置７０を前提に、これらの拠点間を数珠つなぎにデータ転送することで、複数拠点に高速略同時データ伝送を可能としている。なお、光ファイバー等の全二重で上下対象の回線網であれば、上下の両方の帯域が活用できる。従来の技術や製品では、転送をファイル単位で扱うため、ひとつのファイルの転送が終らないと、次の転送が行えなかったり、ＴＣＰを用いているため、パケットロスや遅延のゆらぎにより転送レートが劣化するものがほとんどであったところ、本複数拠点配信方式では、上述の高速データ伝送の制御プロトコル、および、各拠点が同程度の回線に接続されていることを前提とし、サーバは、パケット単位で受信したデータを、次のサーバにそのまま転送する。上下対称の回線であれば、受信と送信は同時に行えるため、効率はほとんど落ちない。これにより、複数の拠点に対し、１対向のみで転送する場合と比べて、ほとんど同じ時間で複数の拠点に高速で転送が可能である。
【００７２】
以上、詳述したとおり、本発明は、インターネット等のＩＰ通信網を用いて、回線のキャパシティいっぱいまで活用して高速に拠点から拠点へデータを転送するためのプロトコルおよび制御方式に関する。本発明によれば、パケットロスが頻発するような回線であっても、ほとんど影響を受けずに安定したデータ伝送が可能である。
【００７３】
具体的には、ＵＤＰのようなＡｃｋ応答を要しないプロトコルを用いて、信頼性を確保しつつ、高速なデータ伝送を可能とする制御方式であり、本発明の実施形態はさらにその効率を高め、回線速度、回線品質にほとんど影響されず、ユーザが回線にあわせた特別な設定を行うこともなく、回線のキャパシティいっぱいまで利用して高速なデータ伝送を可能とする制御方式である。
【００７４】
また、このデータ伝送システムを応用し、ある拠点から複数拠点を数珠つなぎにパケットを中継し、データの同時伝送を可能とする。本実施形態によれば、特別な回線は必要なく、一般的なＢフレッツに代表される光ファイバーブロードバンドを用いて回線のキャパシティいっぱいまで利用した上で、複数拠点への高速な同時転送を可能としている。
【００７５】
なお、本発明は、上記した実施の形態に限定されるものではなく、本発明の要旨を逸脱しない範囲内において、他の様々な形で実施することができる。このため、上記実施形態はあらゆる点で単なる例示にすぎず、限定的に解釈されるものではない。例えば、上述の各処理ステップは処理内容に矛盾を生じない範囲で任意に順番を変更して又は並列に実行することができる。
【符号の説明】
【００７６】
１…データ伝送システム、１０…送信側装置、１１…送出時刻記録モジュール、１２…パケット送出モジュール、１３…送出レート調整モジュール、１４…受領確認受信モジュール、１５…再送判定モジュール、２０…受信側装置、２１…パケット受信モジュール、２２…受信パケット番号記録モジュール、２３…受領確認送信モジュール、２４…過去分受領確認情報記憶モジュール、２５…ソート処理モジュール、２６…受信レート計算モジュール、２７…タイマー、７０…送受信装置、８０…複数拠点配信システム
【特許請求の範囲】
【請求項１】
送信側装置から受信側装置に対してパケット通信網を介してデータを伝送する方法であって、前記送信側装置が、
前記受信側装置に対して複数のパケットを連続的に送出する第一のステップと、
前記受信側装置から送出された、前記受信側装置が前記複数のパケットのうち少なくとも一部を受領したことを示す受領確認を受信する第二のステップと、
前記受領確認によって前記受信側装置による受領が確認されたパケットよりも前に送出されたパケットであり、かつ、受領確認を受信していないパケットを再送する第三のステップと、
を備えるデータ伝送方法。
【請求項２】
前記第三のステップは、前記受領確認によって前記受信側装置による受領が確認されたパケットのうち最も直近に送出されたパケットの送出時刻よりも所定時間以上前に送出されたパケットであり、かつ、受領確認を受信していないパケットを再送することを特徴とする請求項１に記載のデータ伝送方法。
【請求項３】
前記第一のステップは、パケットを送出する際に、当該パケットを識別可能な識別情報と当該パケットの送出時刻とを対応付けて記録するステップを含むことを特徴とする請求項１又は２に記載のデータ伝送方法。
【請求項４】
前記受領確認は、前記受信側装置が受領したパケットの識別情報を含むことを特徴とする請求項３記載のデータ伝送方法。
【請求項５】
前記受領確認は、過去の受領確認に含まれていた識別情報を含むことを特徴とする請求項４記載のデータ伝送方法。
【請求項６】
前記第一のステップは、回線キャパシティより速くパケットを送出することを特徴とする請求項１乃至５のいずれかに記載のデータ伝送方法。
【請求項７】
受信側装置に対してパケット通信網を介してデータを伝送する送信側装置であって、
受信側装置に対して複数のパケットを連続的に送出するパケット送出モジュールと、
前記受信側装置から送出された、前記受信側装置が前記複数のパケットのうち少なくとも一部を受領したことを示す受領確認を受信する受領確認受信モジュールと、
前記受領確認によって前記受信側装置による受領が確認されたパケットよりも前に送出されたパケットであり、かつ、受領確認を受信していないパケットを再送する再送判定モジュールと、
を備える送信側装置。
【請求項８】
前記再送判定モジュールは、前記受領確認によって前記受信側装置による受領が確認されたパケットのうち最も直近に送出されたパケットの送出時刻よりも所定時間以上前に送出されたパケットであり、かつ、受領確認を受信していないパケットを再送することを特徴とする請求項７に記載の送信側装置。
【請求項９】
前記パケット送出モジュールは、回線キャパシティより速くパケットを送出することを特徴とする請求項７又は８に記載の送信側装置。
【請求項１０】
送信側装置と受信側装置とを備え、パケット通信網を介してデータを伝送するデータ伝送システムにおいて、
前記送信側装置は、
受信側装置に対して複数のパケットを連続的に送出するパケット送出モジュールと、
前記受信側装置から送出された、前記受信側装置が前記複数のパケットのうち少なくとも一部を受領したことを示す受領確認を受信する受領確認受信モジュールと、
前記受領確認によって前記受信側装置による受領が確認されたパケットよりも前に送出されたパケットであり、かつ、受領確認を受信していないパケットを再送する再送判定モジュールと、
を備え、
前記受信側装置は、
前記送信側装置から受信したパケットの受領確認を送信する受領確認送信モジュールを備える、
ことを特徴とするデータ伝送システム。
【請求項１１】
前記再送判定モジュールは、前記受領確認によって前記受信側装置による受領が確認されたパケットのうち最も直近に送出されたパケットの送出時刻よりも所定時間以上前に送出されたパケットであり、かつ、受領確認を受信していないパケットを再送することを特徴とする請求項１０に記載のデータ伝送システム。
【請求項１２】
前記パケット送出モジュールは、回線キャパシティより速くパケットを送出することを特徴とする請求項１０又は１１に記載のデータ伝送システム。
【請求項１３】
請求項１乃至６のいずれかに記載のデータ伝送方法をコンピュータに実行させるためのプログラム。
【請求項１４】
請求項１３に記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。
【請求項１５】
前記請求項１乃至６のいずれかに記載のデータ伝送方法によるデータ送受信が可能な複数の送受信装置の間で、数珠つなぎにデータ伝送を行うことによって、前記複数の送受信装置間で略同時にデータ伝送を行うことを特徴とするデータ転送方法。
【請求項１６】
パケット通信網を介して、一の装置から受信したデータを他の装置に転送する方法であって、
前記一の装置から複数のパケットを受信する第一のステップと、
前記他の装置に対して、前記受信した複数のパケットを送出する第二のステップと、
前記他の装置から送出された、前記他の装置が前記複数のパケットのうち少なくとも一部を受領したことを示す受領確認を受信する第三のステップと、
前記受領確認によって前記他の装置による受領が確認されたパケットよりも前に送出されたパケットであり、かつ、受領確認を受信していないパケットを再送する第四のステップと、
を備えるデータ転送方法。
【請求項１７】
前記一の装置から受信したパケットの受領確認を送信する第五のステップをさらに備えることを特徴とする請求項１６に記載のデータ転送方法。
【請求項１８】
前記第四のステップは、前記受領確認によって前記他の装置による受領が確認されたパケットのうち最も直近に送出されたパケットの送出時刻よりも所定時間以上前に送出されたパケットであり、かつ、受領確認を受信していないパケットを再送することを特徴とする請求項１６又は１７に記載のデータ転送方法。
【請求項１９】
前記第二のステップは、回線キャパシティより速くパケットを送出することを特徴とする請求項１６乃至１８のいずれかに記載のデータ転送方法。
【請求項２０】
パケット通信網を介して、一の装置から受信したデータを他の装置に転送する送受信装置であって、
前記一の装置からパケットを受信するパケット受信モジュールと、
前記他の装置に対して、前記受信したパケットを送出するパケット送出モジュールと、
前記他の装置から送出された、前記他の装置が前記送出したパケットのうち少なくとも一部を受領したことを示す受領確認を受信する受領確認受信モジュールと、
前記受領確認によって前記他の装置による受領が確認されたパケットよりも前に送出されたパケットであり、かつ、受領確認を受信していないパケットを再送する再送判定モジュールと、
を備える送受信装置。
【請求項２１】
前記一の装置から受信したパケットの受領確認を送信する受領確認送信モジュールを更に備えることを特徴とする請求項２０に記載の送受信装置。
【請求項２２】
前記再送判定モジュールは、前記受領確認によって前記他の装置による受領が確認されたパケットのうち最も直近に送出されたパケットの送出時刻よりも所定時間以上前に送出されたパケットであり、かつ、受領確認を受信していないパケットを再送することを特徴とする請求項２０又は２１に記載の送受信装置。
【請求項２３】
前記パケット送出モジュールは、回線キャパシティより速くパケットを送出することを特徴とする請求項２０乃至２２のいずれかに記載の送受信装置。
【請求項２４】
前記請求項２０乃至２３のいずれかに記載された送受信装置を複数備え、当該複数の送受信装置の間で、数珠つなぎにデータ伝送を行うことによって、前記複数の送受信装置間で略同時にデータ伝送を行うことを特徴とするデータ転送システム。
【請求項２５】
請求項１６乃至１９のいずれかに記載のデータ転送方法をコンピュータに実行させるためのプログラム。
【請求項２６】
請求項２５に記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。
【請求項１】
送信側装置から受信側装置に対してパケット通信網を介してデータを伝送する方法であって、前記送信側装置が、
前記受信側装置に対して複数のパケットを連続的に送出する第一のステップと、
前記受信側装置から送出された、前記受信側装置が前記複数のパケットのうち少なくとも一部を受領したことを示す受領確認を受信する第二のステップと、
前記受領確認によって前記受信側装置による受領が確認されたパケットよりも前に送出されたパケットであり、かつ、受領確認を受信していないパケットを再送する第三のステップと、
を備えるデータ伝送方法。
【請求項２】
前記第三のステップは、前記受領確認によって前記受信側装置による受領が確認されたパケットのうち最も直近に送出されたパケットの送出時刻よりも所定時間以上前に送出されたパケットであり、かつ、受領確認を受信していないパケットを再送することを特徴とする請求項１に記載のデータ伝送方法。
【請求項３】
前記第一のステップは、パケットを送出する際に、当該パケットを識別可能な識別情報と当該パケットの送出時刻とを対応付けて記録するステップを含むことを特徴とする請求項１又は２に記載のデータ伝送方法。
【請求項４】
前記受領確認は、前記受信側装置が受領したパケットの識別情報を含むことを特徴とする請求項３記載のデータ伝送方法。
【請求項５】
前記受領確認は、過去の受領確認に含まれていた識別情報を含むことを特徴とする請求項４記載のデータ伝送方法。
【請求項６】
前記第一のステップは、回線キャパシティより速くパケットを送出することを特徴とする請求項１乃至５のいずれかに記載のデータ伝送方法。
【請求項７】
受信側装置に対してパケット通信網を介してデータを伝送する送信側装置であって、
受信側装置に対して複数のパケットを連続的に送出するパケット送出モジュールと、
前記受信側装置から送出された、前記受信側装置が前記複数のパケットのうち少なくとも一部を受領したことを示す受領確認を受信する受領確認受信モジュールと、
前記受領確認によって前記受信側装置による受領が確認されたパケットよりも前に送出されたパケットであり、かつ、受領確認を受信していないパケットを再送する再送判定モジュールと、
を備える送信側装置。
【請求項８】
前記再送判定モジュールは、前記受領確認によって前記受信側装置による受領が確認されたパケットのうち最も直近に送出されたパケットの送出時刻よりも所定時間以上前に送出されたパケットであり、かつ、受領確認を受信していないパケットを再送することを特徴とする請求項７に記載の送信側装置。
【請求項９】
前記パケット送出モジュールは、回線キャパシティより速くパケットを送出することを特徴とする請求項７又は８に記載の送信側装置。
【請求項１０】
送信側装置と受信側装置とを備え、パケット通信網を介してデータを伝送するデータ伝送システムにおいて、
前記送信側装置は、
受信側装置に対して複数のパケットを連続的に送出するパケット送出モジュールと、
前記受信側装置から送出された、前記受信側装置が前記複数のパケットのうち少なくとも一部を受領したことを示す受領確認を受信する受領確認受信モジュールと、
前記受領確認によって前記受信側装置による受領が確認されたパケットよりも前に送出されたパケットであり、かつ、受領確認を受信していないパケットを再送する再送判定モジュールと、
を備え、
前記受信側装置は、
前記送信側装置から受信したパケットの受領確認を送信する受領確認送信モジュールを備える、
ことを特徴とするデータ伝送システム。
【請求項１１】
前記再送判定モジュールは、前記受領確認によって前記受信側装置による受領が確認されたパケットのうち最も直近に送出されたパケットの送出時刻よりも所定時間以上前に送出されたパケットであり、かつ、受領確認を受信していないパケットを再送することを特徴とする請求項１０に記載のデータ伝送システム。
【請求項１２】
前記パケット送出モジュールは、回線キャパシティより速くパケットを送出することを特徴とする請求項１０又は１１に記載のデータ伝送システム。
【請求項１３】
請求項１乃至６のいずれかに記載のデータ伝送方法をコンピュータに実行させるためのプログラム。
【請求項１４】
請求項１３に記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。
【請求項１５】
前記請求項１乃至６のいずれかに記載のデータ伝送方法によるデータ送受信が可能な複数の送受信装置の間で、数珠つなぎにデータ伝送を行うことによって、前記複数の送受信装置間で略同時にデータ伝送を行うことを特徴とするデータ転送方法。
【請求項１６】
パケット通信網を介して、一の装置から受信したデータを他の装置に転送する方法であって、
前記一の装置から複数のパケットを受信する第一のステップと、
前記他の装置に対して、前記受信した複数のパケットを送出する第二のステップと、
前記他の装置から送出された、前記他の装置が前記複数のパケットのうち少なくとも一部を受領したことを示す受領確認を受信する第三のステップと、
前記受領確認によって前記他の装置による受領が確認されたパケットよりも前に送出されたパケットであり、かつ、受領確認を受信していないパケットを再送する第四のステップと、
を備えるデータ転送方法。
【請求項１７】
前記一の装置から受信したパケットの受領確認を送信する第五のステップをさらに備えることを特徴とする請求項１６に記載のデータ転送方法。
【請求項１８】
前記第四のステップは、前記受領確認によって前記他の装置による受領が確認されたパケットのうち最も直近に送出されたパケットの送出時刻よりも所定時間以上前に送出されたパケットであり、かつ、受領確認を受信していないパケットを再送することを特徴とする請求項１６又は１７に記載のデータ転送方法。
【請求項１９】
前記第二のステップは、回線キャパシティより速くパケットを送出することを特徴とする請求項１６乃至１８のいずれかに記載のデータ転送方法。
【請求項２０】
パケット通信網を介して、一の装置から受信したデータを他の装置に転送する送受信装置であって、
前記一の装置からパケットを受信するパケット受信モジュールと、
前記他の装置に対して、前記受信したパケットを送出するパケット送出モジュールと、
前記他の装置から送出された、前記他の装置が前記送出したパケットのうち少なくとも一部を受領したことを示す受領確認を受信する受領確認受信モジュールと、
前記受領確認によって前記他の装置による受領が確認されたパケットよりも前に送出されたパケットであり、かつ、受領確認を受信していないパケットを再送する再送判定モジュールと、
を備える送受信装置。
【請求項２１】
前記一の装置から受信したパケットの受領確認を送信する受領確認送信モジュールを更に備えることを特徴とする請求項２０に記載の送受信装置。
【請求項２２】
前記再送判定モジュールは、前記受領確認によって前記他の装置による受領が確認されたパケットのうち最も直近に送出されたパケットの送出時刻よりも所定時間以上前に送出されたパケットであり、かつ、受領確認を受信していないパケットを再送することを特徴とする請求項２０又は２１に記載の送受信装置。
【請求項２３】
前記パケット送出モジュールは、回線キャパシティより速くパケットを送出することを特徴とする請求項２０乃至２２のいずれかに記載の送受信装置。
【請求項２４】
前記請求項２０乃至２３のいずれかに記載された送受信装置を複数備え、当該複数の送受信装置の間で、数珠つなぎにデータ伝送を行うことによって、前記複数の送受信装置間で略同時にデータ伝送を行うことを特徴とするデータ転送システム。
【請求項２５】
請求項１６乃至１９のいずれかに記載のデータ転送方法をコンピュータに実行させるためのプログラム。
【請求項２６】
請求項２５に記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【公開番号】特開２０１２−１００１６５（Ｐ２０１２−１００１６５Ａ）
【公開日】平成２４年５月２４日（２０１２．５．２４）
【国際特許分類】
【出願番号】特願２０１０−２４７７２７（Ｐ２０１０−２４７７２７）
【出願日】平成２２年１１月４日（２０１０．１１．４）
【出願人】（５０９１３７０８７）株式会社ＴＢＳテレビ (3)
【Ｆターム（参考）】
【公開日】平成２４年５月２４日（２０１２．５．２４）
【国際特許分類】
【出願日】平成２２年１１月４日（２０１０．１１．４）
【出願人】（５０９１３７０８７）株式会社ＴＢＳテレビ (3)
【Ｆターム（参考）】
[ Back to top ]