(57)【要約】【課題】  高速で、かつ、安定的な通信を実現できるようにする。【解決手段】  Multi Flow RTP８３は、送信しようとする１のRTPセッションのデータをUDPポート８７乃至８９のそれぞれで送信できるように分割し、UDPポート８７乃至８９に供給する。RTCP８３は、UDPポート８７乃至８９を制御して、送信すると共に、TCPポート８６を制御して、これら分割したデータを再構築するための制御情報を送信する。UDPポート６７乃至６９は、分割されたデータを受信し、Multi Flow RTP６３に供給する。また、RTCP６４は、TCPポート６６より制御情報を取得して、Multi Flow RTP６３に供給する。Multi Flow RTP６３は、分割されたデータを制御情報に基づいて再構築し、プレイヤ６１に供給し、プレイヤ６１は、再構築されたデータを再生する。本発明のは、ストリームデータ配信システムに適用することができる。【選択図】  図４
2005244929.tif 000002
【特許請求の範囲】
【請求項１】
トランスポート層の第１のプロトコルによりデータを送信する複数の第１の送信手段と、
前記第１の送信手段のポート番号、および、利用ポート数を含む、前記データを再生するための制御情報を生成する生成手段と、
前記生成手段により生成された前記制御情報をトランスポート層の第２のプロトコルで送信する第２の送信手段と、
セッション層のプロトコルにより送信するデータを前記複数の第１の送信手段のそれぞれの動作状態に応じて割振って送信するように制御する制御手段と
を備えることを特徴とする送信装置。
【請求項２】
前記制御手段は、セッション層のプロトコルにより送信するデータを前記複数の第１の送信手段のそれぞれの動作状態に応じて、ラウンドロビン方式により割振って送信するように制御する
ことを特徴とする請求項１に記載の送信装置。
【請求項３】
前記制御手段は、セッション層のプロトコルにより送信するデータを前記複数の第１の送信手段のそれぞれの動作状態に応じて、送信可能なものに割振って送信するように制御する
ことを特徴とする請求項１に記載の送信装置。
【請求項４】
前記セッション層のプロトコルにより送信するデータを複数のデータに分割する分割手段をさらに備え、
前記制御手段は、前記分割手段により分割された複数のデータを、それぞれ複数の第１の送信手段のそれぞれの動作状態に応じて割振ってトランスポート層の第１のプロトコルで送信するように制御する
ことを特徴とする請求項１に記載の送信装置。
【請求項５】
前記生成手段は、前記第１の送信手段のポート番号、および、利用ポート数を含む、前記分割手段により前記データが分割される際、分割されたデータを結合して再生させるための制御情報を生成する
ことを特徴とする請求項１に記載の送信装置。
【請求項６】
前記制御手段は、前記セッション層のプロトコルにより送信する同一のデータを、それぞれ複数の第１の送信手段によりトランスポート層の第１のプロトコルで送信するように制御する
ことを特徴とする請求項１に記載の送信装置。
【請求項７】
前記生成手段は、前記第１の送信手段のポート番号、および、利用ポート数を含む、前記セッション層のプロトコルにより送信するデータを識別して、前記データを再生するための制御情報を生成する
ことを特徴とする請求項６に記載の送信装置。
【請求項８】
前記第２のプロトコルはTCPである
ことを特徴とする請求項１に記載の送信装置。
【請求項９】
前記セッション層のプロトコルはRTPである
ことを特徴とする請求項１に記載の送信装置。
【請求項１０】
前記トランスポート層の第１のプロトコルは、送信したデータの着信確認をしないプロトコルである
ことを特徴とする請求項１に記載の送信装置。
【請求項１１】
前記送信したデータの着信確認をしない、前記トランスポート層の第１のプロトコルは、UDPである
ことを特徴とする請求項１０に記載の送信装置。
【請求項１２】
前記トランスポート層の第１のプロトコルは、TCPである
ことを特徴とする請求項１に記載の送信装置。
【請求項１３】
トランスポート層の第１のプロトコルによりデータを送信する複数の第１の送信ステップと、
前記第１の送信ステップの処理でのポート番号、および、利用ポート数を含む、前記データを再生するための制御情報を生成する生成ステップと、
前記生成ステップの処理で生成された前記制御情報をトランスポート層の第２のプロトコルで送信する第２の送信ステップと、
セッション層のプロトコルにより送信するデータを前記複数の第１の送信手段のそれぞれの動作状態に応じて送信するように制御する制御ステップと
を含むことを特徴とする送信方法。
【請求項１４】
トランスポート層の第１のプロトコルによりデータの送信を制御する複数の第１の送信制御ステップと、
前記第１の送信ステップの処理でのポート番号、および、利用ポート数を含む、前記データを再生するための制御情報の生成を制御する生成制御ステップと、
前記生成制御ステップの処理で生成された前記制御情報をトランスポート層の第２のプロトコルでの送信を制御する第２の送信制御ステップと、
セッション層のプロトコルにより送信するデータを前記複数の第１の送信制御ステップの処理のそれぞれの動作状態に応じて送信するように制御する動作制御ステップと
を含むことを特徴とするコンピュータが読み取り可能なプログラムが記録されている記録媒体。
【請求項１５】
トランスポート層の第１のプロトコルによりデータの送信を制御する複数の第１の送信制御ステップと、
前記第１の送信ステップの処理でのポート番号、および、利用ポート数を含む、前記データを再生するための制御情報の生成を制御する生成制御ステップと、
前記生成制御ステップの処理で生成された前記制御情報をトランスポート層の第２のプロトコルでの送信を制御する第２の送信制御ステップと、
セッション層のプロトコルにより送信するデータを前記複数の第１の送信制御ステップの処理のそれぞれの動作状態に応じて送信するように制御する動作制御ステップと
をコンピュータに実行させることを特徴とするプログラム。
【請求項１６】
トランスポート層の第１のプロトコルによりデータを受信する複数の第１の受信手段と、
前記第１の受信手段のポート番号、および、利用ポート数を含む、前記データを再生するための制御情報をトランスポート層の第２のプロトコルで受信する第２の受信手段と、
セッション層のプロトコルによる受信データとして、前記データを前記制御情報に基づいて再生する再生手段と
を備えることを特徴とする受信装置。
【請求項１７】
前記データは、分割された複数のデータであり、
前記複数の第１の受信手段は、それぞれ分割されたデータを受信し、
前記再生手段は、前記第２の受信手段により受信された、前記ポート番号、および、利用ポート数に加えて、分割されたデータを結合して再生させるための情報を含む、前記制御情報に基づいて、セッション層のプロトコルによる受信データとして、前記複数のデータを結合して再生する
ことを特徴とする請求項１６に記載の受信装置。
【請求項１８】
前記データは、同一の複数のデータであり、
前記複数の第１の受信手段は、それぞれ同一のデータを受信し、
前記再生手段は、前記第２の受信手段により受信された、前記ポート番号、および、利用ポート数に加えて、前記データを識別する情報を含む、前記制御情報に基づいて、複数の第１の受信手段のうち、セッション層のプロトコルによる受信データとして、最初に受信されるデータを再生する
ことを特徴とする請求項１６に記載の受信装置。
【請求項１９】
前記第２のプロトコルはTCPである
ことを特徴とする請求項１６に記載の受信装置。
【請求項２０】
前記セッション層のプロトコルはRTPである
ことを特徴とする請求項１６に記載の受信装置。
【請求項２１】
前記トランスポート層の第１のプロトコルは、送信したデータの着信確認をしないプロトコルである
ことを特徴とする請求項１６に記載の受信装置。
【請求項２２】
前記送信したデータの着信確認をしない、前記トランスポート層の第１のプロトコルは、UDPである
ことを特徴とする請求項２１に記載の受信装置。
【請求項２３】
前記トランスポート層の第１のプロトコルは、TCPである
ことを特徴とする請求項１６に記載の受信装置。
【請求項２４】
トランスポート層の第１のプロトコルによりデータを受信する複数の第１の受信ステップと、
前記第１の受信ステップの処理でのポート番号、および、利用ポート数を含む、前記データを再生するための制御情報をトランスポート層の第２のプロトコルで受信する第２の受信ステップと、
セッション層のプロトコルによる受信データとして、前記データを前記制御情報に基づいて再生する再生ステップと
を含むことを特徴とする受信方法。
【請求項２５】
トランスポート層の第１のプロトコルによりデータの受信を制御する複数の第１の受信制御ステップと、
前記第１の受信制御ステップの処理でのポート番号、および、利用ポート数を含む、前記データを再生するための制御情報のトランスポート層の第２のプロトコルでの受信を制御する第２の受信制御ステップと、
セッション層のプロトコルによる受信データとして、前記データの前記制御情報に基づいた再生を制御する再生制御ステップと
を含むことを特徴とするコンピュータが読み取り可能なプログラムが記録されている記録媒体。
【請求項２６】
トランスポート層の第１のプロトコルによりデータの受信を制御する複数の第１の受信制御ステップと、
前記第１の受信制御ステップの処理でのポート番号、および、利用ポート数を含む、前記データを再生するための制御情報のトランスポート層の第２のプロトコルでの受信を制御する第２の受信制御ステップと、
セッション層のプロトコルによる受信データとして、前記データの前記制御情報に基づいた再生を制御する再生制御ステップと
をコンピュータに実行させることを特徴とするプログラム。
【請求項２７】
送信装置と受信装置からなる通信システムにおいて、
前記送信装置は、
トランスポート層のプロトコルによりデータを送信する複数の送信手段と、
前記第１の送信手段のポート番号、および、利用ポート数を含む、前記データを再生するための制御情報を生成する生成手段と、
前記生成手段により生成された前記制御情報をトランスポート層の第２のプロトコルで送信する第２の送信手段と、
セッション層のプロトコルにより送信するデータを前記複数の第１の送信手段のそれぞれの動作状態に応じて割振って送信するように制御する制御手段と
を備え、
前記受信装置は、
前記トランスポート層のプロトコルによりデータを受信する受信手段と、
前記第１の受信手段のポート番号、および、利用ポート数を含む、前記データを再生するための制御情報をトランスポート層の第２のプロトコルで受信する第２の受信手段と、
セッション層のプロトコルによる受信データとして、前記データを前記制御情報に基づいて再生する再生手段と
を備える
ことを特徴とする通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、送信装置および方法、受信装置および方法、通信システム、記録媒体、並びにプログラムに関し、特に、データの通信におけるデータの遅延を抑制し、安定した通信を実現できるようにした送信装置および方法、受信装置および方法、通信システム、記録媒体、並びにプログラムに関する。
【背景技術】
【０００２】
大容量のストリーミングデータなどの再生時刻を保障してデータを配信する技術が一般に普及しつつある。
【０００３】
インターネット上のルータでは、フォワード（転送）するデータのフローが監視され、大量データの送信が行われているフローのフォワード優先度を下げるといったフロー制御が行われることがある。一般的なルータにおいて、データのフローは、送信元および送信先のIPアドレス、トランスポートプロトコル、並びに、送信元および送信先のポート番号によって識別される。
【０００４】
以上の通信の一例として、RTP（Real Time Protocol）方式がある。RTP方式の場合、配信サーバとクライアントPC（Personal Computer）との間で、ストリーミングデータの通信が行われるとき、ストリーミング制御は、RTSP（Real Time Streaming Protocol）によって行われる。また、データの送信制御はRTCP（RTP Control Protocol）が利用され、動画の転送はRTPによって行われる。従来のRTPを利用した動画転送技術の場合、１つのRTPセッションについて、１つのポートを利用する事で、動画転送が実現されている。
【０００５】
また、ビットストリームを分割し、異なるポートで送受信することが提案されている（例えば、特許文献１参照）。
【０００６】
さらに、端末の能力に応じた最適なパケット通信処理を実現させるものが提案されている（例えば、特許文献２参照）。
【特許文献１】特開２００２−０１７６３７号公報
【特許文献２】特開２００３−１５２５４４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
ところで、従来のRTP方式による動画転送を行う場合、インターネット上のルータは、フォワードするデータのフローを監視しおり、大量データの送信を行っているフローのフォワード優先度を下げるといったフロー制御によって、通信が過大に帯域を占有しないように制御している。
【０００８】
また、例えば、ルータは、過負荷の状態になって、さらにバッファがいっぱいになると、受信したパケットを破棄するように制御している。
【０００９】
これに対応するため、TCP（Transmission Control Protocol）においては、ルータ上でパケットが破棄される等の理由によって、輻輳が発生した場合、一旦速度を落とし、パケット長の倍数にあたるウィンドウサイズ（通信可能なデータ量）を徐々に引き上げながら最適な通信速度を模索する（スロースタート）。
【００１０】
ここで、輻輳について説明する。例えば、TCPなどにおいて、通信経路上でデータが欠落した場合、再送要求が送信先から送信元に送信されることになるが、連続的にデータが欠落したような場合、再送要求も連続的に発生することになり、結果として、さらに通信経路が込み合って、通信経路上でのデータの欠落をさらに悪化させてしまい、データの転送が安定的にできない状態となる。このように安定的にデータの転送ができない状態を輻輳と言う。例えば、図１で示されるように、輻輳は、通信が開始されてから、多少遅れて生じる。尚、図１においては、横軸が時間であり、縦軸が単位時間あたりに送信先で受信されるデータの量（byte）を示したものである。
【００１１】
すなわち、図１で示されるように、通信が開始された当初は、データの転送量によるフロー制御がないため通信速度がある程度維持されるが、通信経路上の各所に存在するルータによりデータの破棄などが発生することにより、通信の開始からある程度の時間が経過すると、再送要求が頻繁に送信先から送られてくるため、再送するデータや、再送要求が通信経路をさらに混雑させて、最終的には、図１中のAで示されるように輻輳が生じる結果となる。
【００１２】
このため、２重３重に輻輳が発生すると、最適な通信速度を見つけ出すまでに、非常に時間がかかってしまい、伝送速度の遅い通信となってしまうことがあり、さらに、このような状況により、例えば、ストリーミングデータのバッファリングが不足すると、ストリーミングデータの再生が中断され、スムーズなストリーミングデータの再生ができない状態となることがあった。
【００１３】
また、このような状況を回避するため、例えば、TCPの代わりにUDPを利用することも考えられるが、UDP（User Datagram Protocol）においては、TCPのようなフロー制御や、輻輳制御が行われないため、高速に通信することが可能とはなるが、送信データが確実に送られているかが確認されないので、データの到着には保障がなされないといった問題があった。
【００１４】
本発明はこのような状況に鑑みてなされたものであり、特に、セッション層における１セッションの通信データを複数のトランスポート層のポートを利用して送信することにより、高速で、かつ、安定的なストリーミングデータの通信を実現できるようにするものである。
【課題を解決するための手段】
【００１５】
本発明の送信装置は、トランスポート層の第１のプロトコルによりデータを送信する複数の第１の送信手段と、第１の送信手段のポート番号、および、利用ポート数を含む、データを再生するための制御情報を生成する生成手段と、生成手段により生成された制御情報をトランスポート層の第２のプロトコルで送信する第２の送信手段と、セッション層のプロトコルにより送信するデータを複数の第１の送信手段のそれぞれの動作状態に応じて割振って送信するように制御する制御手段とを備えることを特徴とする。
【００１６】
前記制御手段には、セッション層のプロトコルにより送信するデータを複数の第１の送信手段のそれぞれの動作状態に応じて、ラウンドロビン方式により割振って送信するように制御させるようにすることができる。
【００１７】
前記制御手段には、セッション層のプロトコルにより送信するデータを複数の第１の送信手段のそれぞれの動作状態に応じて、送信可能なものに割振って送信するように制御させるようにすることができる。
【００１８】
前記セッション層のプロトコルにより送信するデータを複数のデータに分割する分割手段をさらに設けるようにさせることができ、制御手段には、分割手段により分割された複数のデータを、それぞれ複数の第１の送信手段によりトランスポート層の第１のプロトコルで送信するように制御させるようにすることができる。
【００１９】
前記生成手段には、第１の送信手段のポート番号、および、利用ポート数を含む、分割手段によりデータが分割される際、分割されたデータを結合して再生させるための制御情報を生成させるようにすることができる。
【００２０】
前記制御手段には、セッション層のプロトコルにより送信する同一のデータを、それぞれ複数の第１の送信手段によりトランスポート層の第１のプロトコルで送信するように制御させるようにすることができる。
【００２１】
前記生成手段には、第１の送信手段のポート番号、および、利用ポート数を含む、セッション層のプロトコルにより送信するデータを識別して、データを再生するための制御情報を生成させるようにすることができる。
【００２２】
前記第２のプロトコルはTCPとするようにすることができる。
【００２３】
前記セッション層のプロトコルはRTPとするようにすることができる。
【００２４】
前記トランスポート層の第１のプロトコルは、送信したデータの着信確認をしないプロトコルとするようにすることができる。
【００２５】
前記送信したデータの着信確認をしない、トランスポート層の第１のプロトコルは、UDPとするようにすることができる。
【００２６】
前記トランスポート層の第１のプロトコルは、TCPとするようにすることができる。
【００２７】
本発明の送信方法は、トランスポート層の第１のプロトコルによりデータを送信する複数の第１の送信ステップと、第１の送信ステップの処理でのポート番号、および、利用ポート数を含む、データを再生するための制御情報を生成する生成ステップと、生成ステップの処理で生成された制御情報をトランスポート層の第２のプロトコルで送信する第２の送信ステップと、セッション層のプロトコルにより送信するデータを複数の第１の送信ステップの処理のそれぞれの動作状態に応じて割振って送信するように制御する制御ステップとを含むことを特徴とする。
【００２８】
本発明の第１の記録媒体のプログラムは、トランスポート層の第１のプロトコルによりデータの送信を制御する複数の第１の送信制御ステップと、第１の送信ステップの処理でのポート番号、および、利用ポート数を含む、データを再生するための制御情報の生成を制御する生成制御ステップと、生成制御ステップの処理で生成された制御情報をトランスポート層の第２のプロトコルでの送信を制御する第２の送信制御ステップと、セッション層のプロトコルにより送信するデータを複数の第１の送信制御ステップの処理のそれぞれの動作状態に応じて割振って送信するように制御する動作制御ステップとを含むことを特徴とする。
【００２９】
本発明の第１のプログラムは、トランスポート層の第１のプロトコルによりデータの送信を制御する複数の第１の送信制御ステップと、第１の送信ステップの処理でのポート番号、および、利用ポート数を含む、データを再生するための制御情報の生成を制御する生成制御ステップと、生成制御ステップの処理で生成された制御情報をトランスポート層の第２のプロトコルでの送信を制御する第２の送信制御ステップと、セッション層のプロトコルにより送信するデータを複数の第１の送信制御ステップの処理のそれぞれの動作状態に応じて割振って送信するように制御する動作制御ステップとをコンピュータに実行させることを特徴とする。
【００３０】
本発明の受信装置は、トランスポート層の第１のプロトコルによりデータを受信する複数の第１の受信手段と、第１の受信手段のポート番号、および、利用ポート数を含む、データを再生するための制御情報をトランスポート層の第２のプロトコルで受信する第２の受信手段と、セッション層のプロトコルによる受信データとして、データを制御情報に基づいて再生する再生手段とを備えることを特徴とする。
【００３１】
前記データは、分割された複数のデータとするようにすることができ、複数の第１の受信手段には、それぞれ分割されたデータを受信させるようにすることができ、再生手段には、第２の受信手段により受信された、ポート番号、および、利用ポート数に加えて、分割されたデータを結合して再生させるための情報を含む、制御情報に基づいて、セッション層のプロトコルによる受信データとして、複数のデータを結合して再生させるようにすることができる。
【００３２】
前記データは、同一の複数のデータとするようにすることができ、複数の第１の受信手段には、それぞれ同一のデータを受信させるようにすることができ、再生手段には、第２の受信手段により受信された、ポート番号、および、利用ポート数に加えて、データを識別する情報を含む、制御情報に基づいて、複数の第１の受信手段のうち、セッション層のプロトコルによる受信データとして、最初に受信されるデータを再生させるようにすることができる。
【００３３】
前記第２のプロトコルはTCPとするようにすることができる。
【００３４】
前記セッション層のプロトコルはRTPとするようにすることができる。
【００３５】
前記トランスポート層の第１のプロトコルは、送信したデータの着信確認をしないプロトコルとするようにすることができる。
【００３６】
前記送信したデータの着信確認をしない、トランスポート層の第１のプロトコルは、UDPとするようにすることができる。
【００３７】
前記トランスポート層の第１のプロトコルは、TCPとするようにすることができる。
【００３８】
本発明の受信方法は、トランスポート層の第１のプロトコルによりデータを受信する複数の第１の受信ステップと、第１の受信ステップの処理でのポート番号、および、利用ポート数を含む、データを再生するための制御情報をトランスポート層の第２のプロトコルで受信する第２の受信ステップと、セッション層のプロトコルによる受信データとして、データを制御情報に基づいて再生する再生ステップとを含むことを特徴とする。
【００３９】
本発明の第２の記録媒体のプログラムは、トランスポート層の第１のプロトコルによりデータの受信を制御する複数の第１の受信制御ステップと、第１の受信制御ステップの処理でのポート番号、および、利用ポート数を含む、データを再生するための制御情報のトランスポート層の第２のプロトコルでの受信を制御する第２の受信制御ステップと、セッション層のプロトコルによる受信データとして、データの制御情報に基づいた再生を制御する再生制御ステップとを含むことを特徴とする。
【００４０】
本発明の第２のプログラムは、トランスポート層の第１のプロトコルによりデータの受信を制御する複数の第１の受信制御ステップと、第１の受信制御ステップの処理でのポート番号、および、利用ポート数を含む、データを再生するための制御情報のトランスポート層の第２のプロトコルでの受信を制御する第２の受信制御ステップと、セッション層のプロトコルによる受信データとして、データの制御情報に基づいた再生を制御する再生制御ステップとをコンピュータに実行させることを特徴とする。
【００４１】
本発明の通信システムは、送信装置が、トランスポート層のプロトコルによりデータを送信する複数の送信手段と、第１の送信手段のポート番号、および、利用ポート数を含む、データを再生するための制御情報を生成する生成手段と、生成手段により生成された制御情報をトランスポート層の第２のプロトコルで送信する第２の送信手段と、セッション層のプロトコルにより送信するデータを複数の第１の送信手段のそれぞれの動作状態に応じて割振って送信するように制御する制御手段とを備え、受信装置が、トランスポート層のプロトコルによりデータを受信する受信手段と、第１の受信手段のポート番号、および、利用ポート数を含む、データを再生するための制御情報をトランスポート層の第２のプロトコルで受信する第２の受信手段と、セッション層のプロトコルによる受信データとして、データを制御情報に基づいて再生する再生手段とを備えることを特徴とする。
【００４２】
本発明の送信装置および方法、並びにプログラムにおいては、トランスポート層の第１のプロトコルによりデータが複数の通信経路で送信され、ポート番号、および、利用ポート数を含む、データを再生するための制御情報が生成され、生成された制御情報がトランスポート層の第２のプロトコルで送信され、セッション層のプロトコルにより送信するデータが複数の通信経路のそれぞれの動作状態に応じて割振られて送信されるように制御される。
【００４３】
本発明の受信装置および方法、並びにプログラムにおいては、トランスポート層の第１のプロトコルによりデータが複数の通信経路で受信され、ポート番号、および、利用ポート数を含む、データを再生するための制御情報がトランスポート層の第２のプロトコルで受信され、セッション層のプロトコルによる受信データとして、データが制御情報に基づいて再生される。
【００４４】
本発明の通信システムにおいては、送信装置により、トランスポート層のプロトコルによりデータが複数の通信経路で送信され、ポート番号、および、利用ポート数を含む、データを再生するための制御情報が生成され、生成された制御情報がトランスポート層の第２のプロトコルで送信され、セッション層のプロトコルにより送信するデータが複数の通信経路のそれぞれの動作状態に応じて割振られて送信されるように制御され、受信装置により、トランスポート層のプロトコルによりデータが受信され、ポート番号、および、利用ポート数を含む、データを再生するための制御情報がトランスポート層の第２のプロトコルで受信され、セッション層のプロトコルによる受信データとして、データが制御情報に基づいて再生される。
【００４５】
本発明の送信装置、受信装置、または、通信システムは、独立した装置であっても良いし、送信処理または受信処理を行うブロックであっても良い。
【発明の効果】
【００４６】
本発明によれば、高速で、かつ、安定的な通信を実現させるようにすることができる。
【発明を実施するための最良の形態】
【００４７】
以下に本発明の実施の形態を説明するが、本明細書に記載の発明と、発明の実施の形態との対応関係を例示すると、次のようになる。この記載は、本明細書に記載されている発明をサポートする実施の形態が本明細書に記載されていることを確認するためのものである。従って、発明の実施の形態中には記載されているが、発明に対応するものとして、ここには記載されていない実施の形態があったとしても、そのことは、その実施の形態が、その発明に対応するものではないことを意味するものではない。逆に、実施の形態が発明に対応するものとしてここに記載されていたとしても、そのことは、その実施の形態が、その発明以外の発明には対応しないものであることを意味するものでもない。
【００４８】
さらに、この記載は、本明細書に記載されている発明の全てを意味するものではない。換言すれば、この記載は、本明細書に記載されている発明であって、この出願では請求されていない発明の存在、すなわち、将来、分割出願されたり、補正により出現、追加される発明の存在を否定するものではない。
【００４９】
即ち、本発明の送信装置は、トランスポート層の第１のプロトコルによりデータを送信する複数の第１の送信手段（例えば、図４のUDPポート８７乃至８９）と、第１の送信手段のポート番号、および、利用ポート数を含む、データを再生するための制御情報を生成する生成手段（例えば、図４のMulti Flow RTP８３）と、生成手段により生成された制御情報をトランスポート層の第２のプロトコルで送信する第２の送信手段（例えば、図４のTCPポート８６）と、セッション層のプロトコルにより送信するデータを複数の第１の送信手段のそれぞれの動作状態に応じて割振って送信するように制御する制御手段（例えば、図４のRTCP８４）とを備えることを特徴とする。
【００５０】
前記セッション層のプロトコルにより送信するデータを複数のデータに分割する分割手段（例えば、図４のMulti Flow RTP８３）をさらに設けるようにさせることができ、制御手段には、分割手段により分割された複数のデータを、それぞれ複数の第１の送信手段のそれぞれの動作状態に応じて割振ってトランスポート層の第１のプロトコルで送信するように制御させるようにすることができる。
【００５１】
本発明の送信方法は、トランスポート層の第１のプロトコルによりデータを送信する複数の第１の送信ステップ（例えば、図７のフローチャートのステップＳ１６の処理）と、第１の送信ステップの処理でのポート番号、および、利用ポート数を含む、データを再生するための制御情報を生成する生成ステップ（例えば、図７のフローチャートのステップＳ１４の処理）と、生成ステップの処理で生成された制御情報をトランスポート層の第２のプロトコルで送信する第２の送信ステップ（例えば、図７のフローチャートのステップＳ１５の処理）と、セッション層のプロトコルにより送信するデータを複数の第１の送信ステップの処理のそれぞれの動作状態に応じて割振って送信するように制御する制御ステップ（例えば、図７のフローチャートのステップＳ１６の処理）とを含むことを特徴とする。
【００５２】
本発明の受信装置は、トランスポート層の第１のプロトコルによりデータを受信する複数の第１の受信手段（例えば、図４のUDPポート６７乃至６９）と、第１の受信手段のポート番号、および、利用ポート数を含む、データを再生するための制御情報をトランスポート層の第２のプロトコルで受信する第２の受信手段（例えば、図４のTCPポート６６）と、セッション層のプロトコルによる受信データとして、データを制御情報に基づいて再生する再生手段（例えば、図４のMulti Flow RTP６３）とを備えることを特徴とする。
【００５３】
本発明の受信方法は、トランスポート層の第１のプロトコルによりデータを受信する複数の第１の受信ステップ（例えば、図７のフローチャートのステップＳ６の処理）と、第１の受信ステップの処理でのポート番号、および、利用ポート数を含む、データを再生するための制御情報をトランスポート層の第２のプロトコルで受信する第２の受信ステップ（例えば、図７のフローチャートのステップＳ４の処理）と、セッション層のプロトコルによる受信データとして、データを制御情報に基づいて再生する再生ステップ（例えば、図７のフローチャートのステップＳ７の処理）とを含むことを特徴とする。
【００５４】
尚、記録媒体、プログラム、および、通信システムの対応関係については、上述した送信装置および方法、並びに、受信装置および方法と同様であるので、その説明は省略する。
【００５５】
図２は、本発明を適用した配信システムの一実施の形態の構成を示す図である。
【００５６】
図２で示されている本発明の配信システムは、クライアントPC１より、ストリームデータの配信要求があると、配信サーバ７から要求のあったストリームデータをクライアントPC１に配信するシステムである。
【００５７】
クライアントPC１は、家庭用のルータ２を介して、最寄のインターネットサービスプロバイダサーバ３に対して、URL（Universal Resource Locator）などによりアドレスを指定して、配信サーバ７にストリームデータの配信を要求する。また、クライアントPC１は、ストリームデータの配信があった場合、インターネットサービスプロバイダサーバ３より送信されてくるストリームデータを家庭用ルータ２を介して取得し、再生する。
【００５８】
家庭用のルータ２（以下、単にルータ２とも称する）は、異なるネットワーク同士を相互接続するものである。より詳細には、ルータ２は、通信経路が記述されたルーティングテーブルに従って、送信先のネットワークまでの通信経路を中継する。ルータ２は、OSI（Open Systems Interconnection）参照モデル（OSI階層モデルとも称される）のネットワーク層以上で動作するため、ネットワークプロトコルに動作が依存する。ルータ２には、様々な形式があり、TCP/IP（Transmission Control Protocol/Internet Protocol）、IPX/SPX（Internetwork Packet Exchange/Sequenced Packet Exchange）、AppleTalk（商標）、および、SNA（Systems Network Architecture）などに様々なプロトコル対応するタイプのものがあり、これらは、一般に「マルチプロトコルルータ」と称されている。また、ルータ２は、上述したように、フロー制御や輻輳制御を行う。
【００５９】
インターネットサービスプロバイダサーバ３は、インターネット接続サービスを提供する通信事業者により管理運営されるサーバである。インターネットサービスプロバイダは、サーバを所有している教育機関や団体、企業などに所属していればLAN経由でインターネットを利用できるが、サーバを持たない企業や個人でもインターネットを利用できるよう、公共のサーバを提供する通信事業者である。
【００６０】
インターネットサービスプロバイダサーバ３は、クライアントPC１からの要求に基づいて、インターネットに代表されるネットワーク５を介して、URLで指定される配信サーバ７にストリームデータを要求する。また、インターネットサービルプロバイダサーバ３は、この要求に応じてネットワーク５を介して配信サーバ７より配信されてくるストリームデータを、ルータ４を介して取得し、クライアントPC１に供給する。
【００６１】
ルータ４，６は、ルータ２と同様のものであり、ルータ４は、主に、インターネットサービスプロバイダサーバ３とネットワーク５とを、また、ルータ６は、配信サーバ７とネットワーク５とをそれぞれ接続し、通信経路を形成している。
【００６２】
ネットワーク５は、複数のルータ１１ａ乃至１１ｆにより構成され、それぞれのルータ１１ａ乃至１１ｆが相互に通信経路を構成する。このルータ１１ａ乃至１１ｆについても、ルータ２と基本的には同様のものである。尚、図２においては、ルータ１１ａと１１ｂ、ルータ１１ａと１１ｃ、ルータ１１ａと１１ｄ、ルータ１１ｂと１１ｃ、ルータ１１ｂと１１ｆ、ルータ１１ｃと１１ｄ、ルータ１１ｃと１１ｆ、ルータ１１ｄと１１ｅ、および、ルータ１１ｅと１１ｆが相互に接続されて、通信経路が形成されている場合について示されているが、ルータ１１ａ乃至１１ｆは、これ以外の組み合わせで接続され、通信経路が形成されるようにしてもよいし、また、これらの数以外の数のルータによりネットワーク５が形成されるようにしても良い。さらに、ルータ１１ａ乃至１１ｆを特に区別する必要がない場合、単に、ルータ１１と称するものとし、その他の構成についても同様とする。
【００６３】
配信サーバ７は、インターネットサービスプロバイダサーバ３、および、ネットワーク５を介してクライアントPC１より要求のあったストリームデータを、要求のあったクライアントPC１に配信する。
【００６４】
次に、図３を参照して、クライアントPC１の構成について説明する。
【００６５】
CPU（Central Processing Unit）２１は、ROM（Read Only Memory）２２、または記憶部２８に記憶されているプログラムに従って各種の処理を実行する。RAM（Random Access Memory）２３には、CPU２１が実行するプログラムやデータなどが適宜記憶される。これらのCPU２１、ROM２２、およびRＡM２３は、バス２４により相互に接続されている。
【００６６】
CPU２１には、バス２４を介して入出力インタフェース２５が接続されている。入出力インタフェース２５には、キーボード、マウス、マイクロフォンなどよりなる入力部２６、ディスプレイ、スピーカなどよりなる出力部６７が接続されている。CPU２１は、入力部２６から入力される指令に対応して各種の処理を実行する。
【００６７】
入出力インタフェース２５に接続されている記憶部２８は、例えばハードディスクなどで構成され、CPU２１が実行するプログラムや各種のデータを記憶する。通信部２９は、例えば、モデムのようなものであり、図示せぬネットワークを介して通信機能を有する装置と各種のデータの授受を行う。
【００６８】
入出力インタフェース２５に接続されているドライブ３０は、磁気ディスク４１、光ディスク４２、光磁気ディスク４３、或いは半導体メモリ４４などが装着されたとき、それらを駆動し、そこに記録されているプログラムやデータなどを取得する。取得されたプログラムやデータは、必要に応じて記憶部２８に転送され、記憶される。
【００６９】
尚、インターネットサービスプロバイダサーバ３、および、配信サーバ７の構成は、基本的に、クライアントPC１と同様の構成であるので、その説明は省略するが、ROM２２、および、記憶部２８、並びに、ドライブ３０に装着された磁気ディスク４１、光ディスク４２、光磁気ディスク４３、或いは半導体メモリ４４に記憶されるプログラムは、後述する機能を実現させるために、インターネットサービスプロバイダサーバ３、および、配信サーバ７においては、それぞれクライアントPC１とは異なるものが記憶されるようにしてもよいし、また、処理に応じてCPU２１の処理速度や、RAM２３、および、記憶部２８の容量を変更させるようにしても良い。
【００７０】
次に、図３を参照して説明したクライアントPC１、および、同様の構成からなる配信サーバ７により実現される機能について説明する。尚、図４においては、ルータ２，４，６，１１、インターネットサービスプロバイダサーバ３、および、ネットワーク５の図示は省略するが、いずれも通信経路上に存在するものとする。
【００７１】
プレイヤ６１は、ストリームデータの再生を制御するプログラムであり、GUI（Graphical User Interface）などにより所定のストリームデータの再生を指示するとき、または、ストリームデータの再生を停止させるときなどに操作され、操作内容に応じた、再生、または、停止といったコマンドを、RTSP（Real Time Streaming Protocol）６２に供給し、TCP（Transmission Control Protocol）ポート６５により配信サーバ７に対して送信させると共に、上述したコマンドに応じてMulti Flow RTP６３より受信される配信されてきたストリームデータを必要に応じて一時的に記憶し、再生する（キャッシュ機能により必要に応じて受信したデータを一時的に記憶したのち、再生に適したビットレートで読み出して再生する）。
【００７２】
RTSPは、リアルタイムストリームデータの配信を制御し、プレイヤ６１より供給された再生、または、停止といったストリームデータの制御コマンドを、TCPポート６５を介して配信サーバ７に供給する。
【００７３】
また、RTSP６２は、SETUPメソッド（配信サーバ７とクライアントPC１の間でストリームデータ送信のために必要なネゴシエーションを行う手順）中のTransportヘッダフィールド（SETUPメソッドにおいて、データ送信プロトコルのネゴシエーションに利用されるフィールド）によってストリームデータ送信プロトコルのネゴシエーションを実行する。このとき、RTSP６２は、送信プロトコルにRTP/UDPを指定するが、その際client_portパラメータおよびserver_portパラメータにはMulti Flow RTP６３およびRTCP６４で使用するUDPポート（図４においては、UDPポート６７乃至６９）の範囲を指定する。
【００７４】
Multi flow RTP６３は、複数のフローによってストリームデータ送信を行うプロトコルである。ここで、フローとは、送信元、送信先のIPアドレス、トランスポートプロトコル、および、ポートの組み合わせによって定義されるデータ送信単位である。また、フローは、一般的なルータがフォワード優先度の制御を行う際の単位である。
【００７５】
Multi flow RTP６３は、RTSP６２により指定されたUDPポート６７乃至６９を制御して、各UDPポート６７乃至６９に分割して送信されてきたストリームデータを取得する。また、Multi flow RTP６３は、RTCP６４よりTCPポート６６を介して配信サーバ７より供給される分割されたストリームデータの送信順序や、配置などの、分割されているデータを組み立てて（結合させて）再構築するための制御情報を取得する。さらに、Multi flow RTP６３は、分割された状態で受信したストリームデータを、RTCP６４より取得した制御情報に基づいて結合させ、元のストリームデータを再構築してプレイヤ６１に供給する。
【００７６】
配信サーバ７の配信プログラム８１は、TCPポート８５を介してクライアントPC１より指定されたストリームデータの再生、または、停止といった指令を受け取ると、これに対応する指示をRTSP８２に供給する。
【００７７】
RTSP８２は、基本的には、クライアントPC１のRTSP６２と対応するものであるが、配信サーバ７においては、配信プログラム８１より指示のあったストリームデータの再生、または、停止の指示に基づいて、再生、または、停止が指示されたストリームデータのアドレスを指定し、Multi Flow RTP８３に供給する。また、RTSP８２は、送信プロトコルにRTP/UDPを指定するが、その際client_portパラメータおよびserver_portパラメータにはMulti Flow RTP８３およびRTCP８４で使用するUDPポート（図４においては、UDPポート６７乃至６９）の範囲を指定する。
【００７８】
Multi Flow RTP８３は、基本的には、クライアントPC１のMulti Flow RTP６３と対応するものであるが、RTSP８２によりアドレスが指定されたストリームデータを読み出し、これを指定されたUDPポート８７乃至８９で送信できるように分割し、各UDPポート８７乃至８９に供給すると共に、その際、分割されたストリームデータを再構築するための情報と、UDPポート８７乃至８９のうち通信に利用するポートを識別するポート番号および利用ポート数の情報とを含む制御情報を生成して、RTCP８４に供給する。
【００７９】
より詳細には、１つのRTPセッションで送信されるべきストリームデータがUDPポート８７乃至８９に対応するように分割される場合、制御情報は、分割された個々のデータに付されるシーケンス番号（Sequence Number）に基づいて、各シーケンス番号のデータをどのような順序で分割したか、すなわち、どのような順序で再構築するかを示した情報と、通信に利用されるUDPポート８７乃至８９のうちの通信に利用されるUDPポートを識別するためのポート番号と利用ポート数を含む情報となる。
【００８０】
また、Multi Flow RTP８３は、複数のUDPポート８７乃至８９を使ってデータを実際に送信する際、各UDPポートの動作状態（ソケットへの書き込み状態）を監視し、動作状態に応じて、分割されたデータを割振って、それぞれに送信させる。割振り方法には、ラウンドロビン方式や即時方式などがある。ラウンドロビン方式は、分割されたデータを複数のUDPポートに対して所定の順序で割振って送信させる方式である。また、即時方式は、複数のUDPポートに対して、順序とは無関係に書き込み可能であれば、即時に送信すべきデータを割振って送信させる方式である。割振り方法については、ラウンドロビン方式または即時方式のいずれであってもよいが、例えば、モードとして切替えて使用できるようにしてもよいし、それ以外の割振り方法であってもよい。
【００８１】
RTCP８４は、基本的には、クライアントPC１のRTCP６４と同様のものであるが、Multi Flow RTP６３より供給された制御情報に基づいて、UDPポート８７乃至８９を制御して、クライアントPC１にストリームデータを供給させると共に、供給された制御情報を、TCPポート８６を制御してクライアントPC１に送信する。
【００８２】
図４に示したプレイヤ６１、RTSP６２、Multi Flow RTP６３、RTCP６４、TCP６５，６６、および、UDP６７乃至６９、並びに、配信プログラム８１、RTSP８２、Multi Flow RTP８３、RTCP８４、TCP８５，８６、および、UDP８７乃至８９は、いずれもプロトコルであるが、図５で示されるように、それぞれは、OSI参照モデルにより、以下のように分類される。
【００８３】
すなわち、プレイヤ６１、および、配信プログラム８１は、アプリケーション層であり、クライアントPC１や配信サーバ７を操作するユーザより見えるアプリケーションを規定する。このとき、ストリームデータが、例えば、動画データである場合、その動画データに大生する動画フォーマットが、プレゼンテーション層となり、通信におけるフォーマットやコードを規定する。
【００８４】
RTSP６２，８２、Multi Flow RTP６３，８３、RTCP６４，８４は、セッション層であり、通信の手順を規定するプロトコルである。TCPポート６５，６６，８５，８６、並びに、UDPポート６７乃至６９、８７乃至８９は、トランスポート層であり、論理的な通信路を規定する。
【００８５】
以上の元で、TCP/IPにおけるプロトコルであるIP（Internet Protocol）は、ネットワークを介した通信経路を規定するネットワーク層となり、各機器の物理的なアドレスであるMACアドレス（Media Access Control Address）が、物理的に隣り合った機器間の論理信号手順（例えば、パケット化の手順など）を規定するデータ層となり、さらに、LANなどの物理的な電気的接続の規定である物理層となる。
【００８６】
図６は、図４の機能を、図５を参照して説明したOSI参照モデルに基づいて、各層毎に配置したものである。図６において、各ブロックの重なり合っている部分、または、接触している部分は、図中の上部のブロックが下部のブロックを制御していることを示し、各矢印は、データの伝送方向を示している。
【００８７】
すなわち、RTSP６２，８２は、同じセッション層のMulti Flow RTP６３，８３をそれぞれ制御すると共に、トランスポート層のTCPポート６５，８５をそれぞれ制御する。また、Multi Flow RTP６３，８３が、同じセッション層におけるRTCP６４，８４をそれぞれ制御する。また、セッション層のRTCP６４，８４は、トランスポート層のUDP６７乃至６９、８７乃至８９、および、トランスポート層のTCP６６，８６をそれぞれ制御する。このとき、配信サーバ７のUDPポートと、クライアントPC１のUDPポートは、それぞれ１対１でペアを組んでデータの授受を行う。すなわち、図６においては、UDP６７と８７、UDP６８と８８、および、UDP６９と８９が、それぞれペアを形成し、データがそれぞれのペア毎に授受される。
【００８８】
以上の機能により、1つのセッションにより送信されるストリームデータの送信が複数のポートで行われる。ここで、Multi-Flow RTP６３，８３によるストリーミング送信の最大単位を、「RTPセッション」と定義し、あるRTPセッションに属する一対の送信先・送信元UDPポートのペア（例えば、図６においては、UDPポート６７と８７、UDPポート６８と８８、または、UDPポート６９と８９）により授受されるデータの単位を、「RTPデータフロー」と定義するものとする。
【００８９】
この場合、Multi Flow RTP６３，８３における各RTPデータフローは、RFC1889のRTPデータ送信規定に従うが、RTCP６４，８４は、各UDPポートのペアで授受されるRTPデータフロー単位で制御を行わず、UDPポート６７乃至６９、および、UDPポート８７乃至８９を１つとして捉え、RTPセッション全体を制御する。
【００９０】
このとき、Multi Flow RTP６３，８３は、RTPデータパケットのシーケンス番号（sequence number）をRTPデータフロー単位ではなくRTPセッション単位で付与し、異なるRTPデータフローによって送信されたデータパケットであっても、シーケンス番号によって一意に管理する。
【００９１】
また、通常のRTPでは、SSRC（Synchronization Source：RTPにおいてストリームデータパケットのソース識別を行うための32bitのフィールド）によってストリームデータソースが識別されるが、Multi-Flow RTP８３は、SSRCをRTPセッションと1対1に対応させる。これにより、Multi-Flow RTP６３は、複数のRTPデータフローを１つのRTPセッションとしてまとめることが容易になり、また複数のRTPセッションに属するデータを同一UDPポートで受信した場合であっても適正に仕分けることができる。
【００９２】
尚、RTPデータフローの各UDPポートは、原則として連続したポート範囲で割り当てるものとするが、RFC1889の規定に従い連続したポート範囲のうち偶数ポートのみを割り当てるようにしてもよい。
【００９３】
次に、図７のフローチャートを参照して、図４のクライアントPC１と配信サーバ７によるストリームデータの配信処理について説明する。
【００９４】
ステップＳ１において、プレイヤ６１は、入力部２６が操作されて、所定のストリームデータの配信を要求する操作がなされたか否かを判定し、所定のストリームデータの配信を要求する操作がなされるまで、その処理を繰り返す。そして、ユーザが、入力部２６を操作して、データの配信を要求したと判定した場合、その処理は、ステップＳ２に進む。
【００９５】
ステップＳ２において、プレイヤ６１は、ストリームデータの配信を要求する操作指示をRTSP６２に供給して、TCPポート６５を介して配信サーバ７に送信させる。このとき、当然のことながら、図１で示したように、ルータ２、インターネットサービスプロバイダサーバ３、ルータ４、ネットワーク５、および、ルータ６を介した経路を経て、ストリームデータの配信を要求する情報が配信サーバ７に送信される。尚、以降においては、同様の経路を経てクライアントPC１と配信サーバ７のデータが授受されるものとする事を前提とするので、ルータ２、インターネットサービスプロバイダサーバ３、ルータ４、ネットワーク５、および、ルータ６におけるデータの授受に関する説明は適宜省略する。
【００９６】
ステップＳ１１において、配信プログラム８１は、RTSP８２よりTCPポート８５を介して、ストリームデータの配信がクライアントPC１より要求されたか否かを判定し、ストリームデータの配信がクライアントPC１より要求されたと判定されるまで、その処理を繰り返す。ステップＳ１１において、例えば、ステップＳ２の処理により、ストリームデータの配信がクライアントPC１より要求されたと判定された場合、配信プログラム８１は、RTSP８２を制御して、送信すべきストリームデータが格納されているアドレスを指定する情報をMulti Flow RTP８３に供給させる。
【００９７】
ステップＳ１３において、Multi Flow RTP８３は、RTSP８２より供給されたアドレスの情報に基づいて、送信すべきストリームデータを読み出して、UDPポート８７乃至８９に対応する数に分割し、UDPポート８７乃至８９に供給すると共に、このときの分割したストリームデータを再構築するために必要な制御情報を生成してRTCP８４に供給する。
【００９８】
ステップＳ１４において、Multi Flow RTP８３は、分割したストリームデータを再構築するために必要な情報と、通信に使用するUDPポートのポート番号と利用ポート数の情報とを含む制御情報を生成する。
【００９９】
ステップＳ１５において、RTCP８４は、TCPポート８６を制御して、制御情報をクライアントPC１に送信させる。
【０１００】
ステップＳ１６において、複数UDPポート送信処理が実行され、RTCP８４により、UDPポート８７乃至８９が制御されて、Multi Flow RTP８３により分割された状態で個々に供給されたストリームデータがクライアントPC１に送信される。尚、複数UDPポート送信処理については、図１８乃至図２２を参照して後述する。
【０１０１】
ステップＳ３において、Multi Flow RTP６３は、RTCP６４を制御して、TCPポート６６に問い合わせて、分割されて各UDPポート６７乃至６９に受信されるストリームデータを再構築するために必要な情報（例えば、データを再構築するための順序の情報）と、通信に利用されるUDPポート６７乃至６９を特定するポート番号、および、利用ポート数の情報とを含む制御情報が送信されているかを判定し、送信されてくるまで、その処理を繰り返す。そして、例えば、ステップＳ３において、ステップＳ１５の処理によりデータが送信されてきていると判定された場合、その処理は、ステップＳ４に進む。
【０１０２】
ステップＳ４において、RTCP６４は、制御情報をTCPポート６６を制御して受信させて、さらに、Multi Flow RTP６３に供給する。
【０１０３】
ステップＳ５において、RTCP６４は、制御情報の通信に使用されるポート番号と利用するポート数の情報に基づいて、UDPポート６７乃至６９に問い合わせて、それぞれ対応するUDPポート８７乃至８９よりデータが送信されてきているか否かを確認し、データが送信されてくるまで、その処理を繰り返す。ステップＳ５において、例えば、ステップＳ１６の処理によりデータが送信されてきていると判定された場合、その処理は、ステップＳ６に進む。
【０１０４】
ステップＳ６において、複数UDPポート受信処理が実行され、RTCP６４により、制御情報に含まれている通信に利用されるUDPポート６７乃至６９を特定するポート番号、および、利用ポート数の情報に基づいて、UDPポート６７乃至６９が制御されて、送信されてきた分割されているストリームデータが受信され、Multi Flow RTP６３に供給される。尚、複数UDPポート受信処理については、図１８乃至図２２を参照して後述する。
【０１０５】
ステップＳ７において、Multi Flow RTP６３は、各UDPポートより受信された分割されているストリームデータを、制御情報に含まれているストリームデータを再構築するために必要な情報に基づいて組み立てることにより、再構築し、プレイヤ６１に供給する。
【０１０６】
ステップＳ８において、プレイヤ６１は、Multi Flow RTP６３より供給された組み立てられて、再構築されている元のストリームデータを所定時間だけバッファリングした後、再生する。
【０１０７】
以上の処理により、ストリームデータが分割された状態で複数のUDPポートによって送信されることになるので、例えば、図８で示されるように、複数の通信経路により分割されてストリームデータが配信されるので、図８で示されるように、これまで輻輳が発生する以前のタイミングで全てのデータを送信することが可能となる。
【０１０８】
尚、図８においては、例えば、図６のUDPポートのペアであるUDPポート６７と８７、UDPポート６８と８８、または、UDPポート６９と８９によるRTPデータフローをそれぞれ、実線の太線、点線の太線、および、１点鎖線の太線で示している。すなわち、例えば、UDPポート６７と８７のRTPデータフローは、ルータ６，１１ｆ，１１ｅ，１１ｄ，４、インターネットサービスプロバイダサーバ３、ルータ２を介したものであり、UDPポート６８と８８のRTPデータフローは、ルータ６，１１ｆ，１１ｂ，１１ｃ，１１ｄ，４、インターネットサービスプロバイダサーバ３、ルータ２を介したものであり、さらに、UDPポート６９と８９のRTPデータフローは、ルータ６，１１ｆ，１１ｃ，１１ｄ，４、インターネットサービスプロバイダサーバ３、ルータ２を介したものであり、それぞれが異なる通信路を使うことにより、帯域を広く使うことができ、高速でデータを送信することが可能となるので、図９で示されるように、これまで、輻輳が発生していた時刻ｔ１付近までの間に、送信を完了させることができ、遅延などを抑制して高速の通信を実現させることができる。尚、図９においては、点線が、これまでの通信であり、実線が、図４の配信システムによるデータの転送状況を示したものであり、これまでの通信においては、図９における時刻ｔ１を越えた付近において、輻輳が発生している。
【０１０９】
以上においては、ストリームデータのうち１のRTPセッションにより配信するデータを分割し、複数のRTPデータフローにより送信する例について説明してきたが、以上の通信においては、UDPポートによる通信であるため、通信経路上のルータのいずれかがフロー制御などによりパケットを破棄した場合、送信したデータが着信しているか否かの確認がなされず、Multi Flow RTP１０１が、ストリームデータを再構築することができない恐れがある。そこで、通信経路上でパケットが破棄された場合、欠落したパケットを再送要求するようにさせても良い。
【０１１０】
図１０は、欠落したパケットを再送要求できるようにしたクライアントPC１と配信サーバ７により実現される機能を説明する図である。尚、図４で示されるクライアントPC１と配信サーバ７により実現される機能と同様の機能については、同一の符号を付してあり、その説明は適宜省略する。
【０１１１】
図１０のクライアントPC１と配信サーバ７において、図４のクライアントPC１と配信サーバ７と異なる機能は、Multi Flow RTP６３，８３に代えて、再送処理機能付Multi Flow RTP１０１，１１１を設けた点である。再送処理機能付Multi Flow RTP１０１は、基本的にMulti Flow RTP６３と同様の機能を備えているが、さらに、制御情報に含まれている、ストリームデータを再構築するために必要とされる情報に基づいて、UDPポート６７乃至６９により供給された、分割されているストリームデータのうち、データの欠落の有無を確認し、欠落を検出した場合、RTCP６４を制御してTCPポート６６より、欠落したデータの再送を要求する。また、再送処理機能付Multi Flow RTP１１１は、RTCP８４を制御して、TCPポート８６より再送処理機能付Multi Flow RTP１０１からの再送要求を受信すると、再送要求のあったデータ（パケット）を複数のUDPポート８７乃至８９を制御して送信する。
【０１１２】
次に、図１１のフローチャートを参照して、図１０のクライアントPC１と配信サーバ７による配信システムによる配信処理について説明する。尚、図１１のフローチャートのステップＳ３１乃至Ｓ３６，Ｓ３８，Ｓ３９の処理、および、ステップＳ５１乃至Ｓ５６の処理は、図７のフローチャートのステップＳ１乃至Ｓ８およびＳ１１乃至Ｓ１６の処理と同様であるので、その説明は省略する。
【０１１３】
ステップＳ３７において、再送処理機能付Multi Flow RTP１０１は、RTCP６４より供給された制御情報に基づいて、UDPポート６７乃至６９より供給されたデータに欠落がなく全て受信されているか否かを判定する。例えば、図１２で示されるように、UDPポート６８と８８のペアで送信されてくるべきデータがルータ１１ｃにより破棄されてしまったような場合、データが欠落し、全てのデータが受信されていないと判定され、その処理は、ステップＳ４０に進む。
【０１１４】
ステップＳ４０において、再送処理機能付Multi Flow RTP１０１は、遅延許容時間内であるか否かを判定し、遅延許容時間内であると判定した場合、その処理は、ステップＳ３７に戻る。すなわち、全てのデータが受信されていないと判定された状態でも、遅延許容時間内では、ステップＳ３７，Ｓ４０の処理が繰り返される。そして、遅延許容時間内ではないと判定された場合、ステップＳ４１において、再送処理機能付Multi Flow RTP１０１は、RTCP６４を制御して、TCPポート６６より欠落しているデータの再送要求を配信サーバ７に送信させ、その処理は、ステップＳ３３に戻り、それ以降の処理が繰り替えされる。より詳細には、欠落しているRTPデータパケットのシーケンス番号が指定されて、再送が要求される。
【０１１５】
ステップＳ５７において、再送処理機能付Multi Flow RTP１１１は、RTCP８４を制御して、TCPポート８６に再送要求が送信されてきているか否かを判定し、例えば、ステップＳ４１の処理により再送要求があったと判定された場合、その処理は、ステップＳ５８に進む。
【０１１６】
ステップＳ５８において、再送処理機能付Multi Flow RTP１１１は、再送要求のあったデータのアドレス（再送の要求があったデータのシーケンス番号に対応するデータのアドレス）を指定し、その処理は、ステップＳ５３に戻り、それ以降の処理が繰り返される。
【０１１７】
ステップＳ３７において、全てのデータが受信されていると判定された場合、その処理は、ステップＳ３８に進む。また、ステップＳ５７において、再送要求がなかったと判定された場合、その処理は、終了する。
【０１１８】
すなわち、図１３で示されるように、RTPデータフロー１２１が、複数のUDPポートのペア（例えば、図６のUDPポートのペアであるUDPポート６７と８７、UDPポート６８と８８、または、UDPポート６９と８９）を介して、配信サーバ７から送信されてくると図１１のフローチャートのステップＳ３８の処理により、プレイヤ６１が、データ１３１を再生する（所定時間だけバッファリングしてから再生する）。同様にして、クライアントPC１においては、RTPデータフロー１２２が、同様に複数のUDPポートペアにより送信されてくることにより、データ１３２が再生される。
【０１１９】
ところが、図１３で示されるように、RTPデータフロー１２３が、例えば、図１２で示される点線の通信経路上のルータ１１ｃにより、破棄されてしまったような場合、その分のデータが欠落することになる。従って、この場合、対応するデータはプレイヤ６１に供給されないことになる。図１３においては、その後に送信されてくるRTPデータフロー１２４が、受信され、対応するデータ１３５がバッファリングされる。この間、データ１２３が欠落してから、遅延許容時間が経過すると、上述したステップＳ４１の処理により、RTCP６４がTCPポート６６を制御して再送を要求する。
【０１２０】
すると、この再送要求に基づいて、RTPデータフロー１２６が配信サーバ７より送信されてきて、対応する欠落したデータ１３４がバッファリングされた後、ストリームデータが再生される。図１３においては、その後、RTPデータフロー１２７，１２８が、配信サーバ７より引き続き送信されてきて、対応するデータ１３６，１３７がバッファリングされて、再生される様子が示されている。尚、この遅延許容時間は、バッファリング時間から予測される再送レスポンス時間（再送要求に基づいてデータ送信されてくるまでの予測時間）を減じた時間よりも短くする必要がある。
【０１２１】
以上の処理により、複数のUDPポートにより分割された状態でストリームデータ送信されることになるので、これまで輻輳が発生する以前のタイミングで全てのデータを送信することが可能となると共に、通信経路上でデータの欠落が発生したような場合にでも、再送要求によってデータの欠落を抑制し、安定したストリームデータの再生を実現させることが可能となる。
【０１２２】
尚、以上においては、１のRTPセッションについて、複数のRTPデータフロー（複数のUDPポート）を使用して送受信する例について説明してきたが、例えば、図１４で示されるように、RTSP６２，８２−よりも上位の層にRTPセッションそのものを分割するセッション分割プログラム１４１、および、分割されたセッションを結合するセッション結合プログラム１４２をそれぞれ設けるようにしても良い。
【０１２３】
さらに、以上においては、１のRTPセッションからなるデータを複数のRTPデータフロー（複数のUDPポート）に分割して同時に送受信する例について説明してきたが、例えば、図１５で示されるように、UDPポート６７乃至６９，８７乃至８９に代えて、TCPポート１５１乃至１５３，１６１乃至１６３を設けるようにしても良い。この場合、UDPポートの場合よりも通信速度の低下が見られる可能性があるが、TCPはデータの着信を確認する機能を備えているので、より安定したストリームデータの配信を実現することができる。
【０１２４】
尚、図１４，図１５において、Multi Flow RTP６３，８３は、図１０で示したMulti Flow RTP１０１，１１１に置き換えるようにして、再送処理機能を備えるようにさせても良い。また、UDPポート６７乃至６９、および、８７乃至８９は、いずれも３個で構成される例について説明してきたが、これに限るものではなく、それ以外の数のUDPポート、または、TCPポートにより構成されるようにしても良い。
【０１２５】
以上においては、１のRTPセッションからなるデータを分割して送信する例について説明してきてきたが、１のRTPセッションからなるデータを、同時に複数のUDPポートから送信するようにしてもよい。
【０１２６】
図１６は、１のRTPセッションからなるデータを、同時に複数のUDPポートから送信するようにしたクライアントPC１と配信サーバ７により実現される機能を説明する図である。尚、図４で示されるクライアントPC１と配信サーバ７により実現される機能と同様の機能については、同一の符号を付してあり、その説明は適宜省略する。
【０１２７】
図１６のクライアントPC１と配信サーバ７において、図４のクライアントPC１と配信サーバ７と異なる機能は、Multi Flow RTP６３，８３、および、RTCP６４，８４に代えて、並列Multi Flow RTP１７１，１８１、および、RTCP１７２，１８２を設けた点である。並列Multi Flow RTP１７１は、基本的にMulti Flow RTP６３と同様の機能を備えているが、送信するデータを分割せずに、UDPポート８７乃至８９に供給すると共に、送信しようとするデータを識別する情報である制御信号をRTCP１７２に供給する。RTCP１７２は、基本的に、RTCP８４と同様のものであるが、ストリームデータが分割されないので、分割されたデータを再構築するための制御情報ではなく、送信しようとするデータを識別する情報である制御信号を、TCPポート８６を制御して、クライアントPC１に送信させると共に、UDPポート８７乃至８９を制御して、それぞれからデータをクライアントPC１に送信させる。
【０１２８】
また、並列Multi Flow RTP１８１は、RTCP１８２を制御して、TCPポート６６により配信サーバ７からの送信されてくるデータを識別する情報である制御情報を受信し、UDPポート６７乃至６９のいずれかで、その制御情報に基づいて識別されるデータ（パケット）が受信されると、その他のUDPポート６７乃至６９で受信されるデータを破棄すると共に、最初受信されたデータをプレイヤ６１に供給して再生させる。
【０１２９】
次に、図１７のフローチャートを参照して、図１６のクライアントPC１と配信サーバ７からなる配信システムによる配信処理について説明する。尚、図１７のフローチャートのステップＳ７１，Ｓ７２の処理、および、ステップＳ９１，Ｓ９２の処理は、図７のフローチャートのステップＳ１，Ｓ２およびＳ９１，Ｓ９２の処理と同様であるので、その説明は省略する。
【０１３０】
ステップＳ９３において、並列Multi Flow RTP１７１は、RTSP８２より供給されたアドレスの情報に基づいて、送信すべきストリームデータを読み出し、そのストリームデータを識別する情報と、UDPポート８７乃至８９のうちの通信に使用するポート番号と利用ポート数の情報を含む制御情報を生成する。
【０１３１】
ステップＳ９４において、並列Multi Flow RTP１７１は、RTCP８４を制御して、TCPポート８６より、生成した送信しようとするストリームデータを識別する情報と、UDPポート８７乃至８９のうちの通信に使用するポート番号と利用ポート数の情報を含む制御情報をクライアントPC１に送信させる。
【０１３２】
ステップＳ９５において、複数UDPポート送信処理が実行され、並列Multi Flow RTP１７１により、送信しようとするストリームデータがUDPポート８７乃至８９に、それぞれ供給され、クライアントPC１に送信される。すなわち、この処理により、送信すべき同一のストリームデータが同時に複数のUDPポート８７乃至８９よりクライアントPC１に送信される。尚、ステップＳ９５の処理においては、ステップＳ１６，Ｓ５６の処理と異なり、送信されるデータが分割されていない状態であるが、複数のUDPポート８７乃至８９を使用した複数UDPポート送信処理そのものは同様である。
【０１３３】
ステップＳ７３において、RTCP１８２は、TCPポート６６を制御して、配信サーバ７より制御情報が送信されてきたか否かを判定し、送信されてくるまでその処理を繰り返す。例えば、ステップＳ９３の処理により制御情報が送信されてきた場合、その処理は、ステップＳ７４に進む。
【０１３４】
ステップＳ７４において、複数UDPポート受信処理が実行され、RTCP１８２により、TCPポート６６が制御されて制御情報が受信され、さらに、受信された制御情報が並列Multi Flow RTP１８１に供給される。尚、ステップＳ７４の処理においては、ステップＳ６，Ｓ３６の処理と異なり、受信されるデータが分割されていない状態であるが、複数のUDPポート６７乃至６９を使用した複数UDPポート受信処理そのものは同様である。
【０１３５】
ステップＳ７５において、並列Multi Flow RTP１７１は、制御情報に基づいて、UDPポート６７乃至６９のいずれかにおいて、送信されてきたストリームデータが受信されたか否かを判定し、受信されるまで、その処理を繰り返す。例えば、ステップＳ９４の処理により、ステップＳ７６において、複数UDPポート受信処理が実行され、UDPポート８７乃至８９のいずれかから送信されてきたストリームデータが受信された場合、その処理は、ステップＳ７７に進む。
【０１３６】
ステップＳ７７において、並列Multi Flow RTP１７１は、UDPポート６７乃至６９のいずれかにより受信されたストリームデータと、受信されている制御情報を比較し、既に受信済みのストリームデータであるか否かを判定する。より詳細には、並列Multi Flow RTP１７１は、受信されたストリームデータを識別する情報と、制御情報に含まれている送信されてくるべきストリームデータを識別する情報とを比較し、受信したストリームデータが、送信されてくるべきストリームデータであるか否かを識別し、送信されてくるべきストリームデータであった場合で、かつ、既に受信されているものであるか否かを判定する。例えば、ステップＳ７６において、受信されたストリームデータが、まだ、受信されていない最初のストリームデータであると判定した場合、その処理は、ステップＳ７７に進む。
【０１３７】
ステップＳ７８において、並列Multi Flow RTP１７１は、受信したストリームデータをプレイヤ６１に供給し、再生させる。
【０１３８】
ステップＳ７７において、既に、受信済みのストリームデータであると判定された場合、すなわち、ステップＳ９４の処理により、ストリームデータは、複数のUDPポートにより同時に並列に送信されてくるので、そのうちのいずれか複数の経路上でパケットが破棄されることなく、複数のストリームデータが、複数のUDPポートで受信された場合、ステップＳ７９において、並列Multi Flow RTP１７１は、２番目以降に受信されたストリームデータのパケットを破棄する。
【０１３９】
このため、従来UDPパケットによるデータ転送では、パケットが通信路上のいずれかのルータで破棄された場合、例えば、ストリームデータが動画であるとき、データが到達しないまま再生が進む事で、画質の劣化が生じてしまうので、画質を下げることによって対応することしかできなかったが、以上の処理により、同一のストリームデータを複数ポートで並列的に転送する事が可能となり、結果として、並列に送信されたストリームデータのうちの１つでも届けば、ストリームデータが届かないといった事体を回避することができるので、通信の信頼性を高めることが可能となる。また、正しいパケットが１つでも到達した時点で、他のパケットの破棄処理を行う事で、確認応答がないためにTCP方式の通信に比べて高速なUDP方式の通信の特徴を活かしたままで、UDP方式による通信における弱点であった信頼性の高いデータ転送を実現することが可能となる。
【０１４０】
また、単一のTCPコネクションやUDPパケットでは、単一のコネクション内や単一のパケットにおける送信できるデータ容量の限界があり、さらに、TCP方式の場合、フロー制御等で、単一のコネクションでは、利用可能帯域を一杯まで利用する事が難しいといった問題があったが、以上のような処理により、複数のポートを利用した転送を、TCP方式、または、UDP方式で行う事で、帯域を限界近くまで利用することが可能となり、転送容量を高めることが可能となる。
【０１４１】
すなわち、送信しようとするストリームデータを分割し、連続データとして複数のポートで同時送受信する事で、より高速でデータを転送させることができる。また、同一データを複数のポートを用いて送信する場合、パケットが破棄されてしまうといった状況を意識した同一データの複数ポートでの受信を行うことにより、通信の信頼性を向上させつつ、従来の単一ポートでの送受信と変わらない速度での転送が可能になる。
【０１４２】
さらに、以上のように複数ポートを利用して転送することで、クライアントPC側にキャッシュ機能を設ける事によって、必要なデータを高速で転送することができ、また、ネットワークの利用率を複数転送で高める事で、一般的な通信が単一ポート利用したときに生じる、フロー制御による通信速度が低下する現象や、長時間の利用や通信頻度の低下によって引き起こされる、ルータの優先制御によって通信速度が下がる等の現象を回避する事が可能になる。
【０１４３】
次に、図１８のフローチャートを参照して、ラウンドロビン方式を用いた複数UDPポート送信処理、および、複数UDPポート受信処理について説明する。図１８のフローチャートにおいては、複数UDPポート送信処理、および、複数UDPポート受信処理を図７のフローチャートにおけるステップＳ６，Ｓ１６の詳細な処理として説明するが、図１１のフローチャートにおけるステップＳ３６，Ｓ５６、および、図１７のフローチャートにおけるステップＳ７６，Ｓ９５の処理も同様である。
【０１４４】
ステップＳ１１１において、Multi Flow RTP８３は、UDPポート８７乃至８９を識別するためのカウンタｐを１に初期化する。尚、以下の説明においては、カウンタｐ＝１は、UDPポート８７に、カウンタｐ＝２は、UDPポート８８に、カウンタｐ＝３は、UDPポート８９にそれぞれ対応するものとし、UDPポートが３個であるため、カウンタｐの上限Pは３であるものとするが、もちろん、それ以外の数であってもよい。
【０１４５】
ステップＳ１１２において、Multi Flow RTP８３は、カウンタｐに対応するUDPポートの検査処理を実行する。すなわち、カウンタｐに対応するUDPポートとは、例えば、最初の処理においては、カウンタｐ＝１に対応するUDPポートの検査処理が実行される。
【０１４６】
ここで、図１９のフローチャートを参照して、UDPポート検査処理について説明する。
【０１４７】
ステップＳ１５１において、Multi Flow RTP８３は、検査対象となるUDPポートを指定する。より詳細には、例えば、UNIX（登録商標）系のSystemV（商標）をOSとして使用した場合、Multi Flow RTP８３は、FD-SET（OS（＝SystemV）の標準マクロ）を実行することにより、検査対象となるカウンタｐに対応するUDPポートを特定するディスクリプタを指定する。
【０１４８】
ステップＳ１５２において、Multi Flow RTP８３は、検査対象となるUDPポートが通信可能であるか否かを検査する。すなわち、より詳細には、Multi Flow RTP８３は、例えば、select（）関数（OS（＝SystemVなど）の標準関数）を実行することによりFD-SETで指定されたディスクリプタの動作状態を検査する（より具体的には、検査対象となるUDPポートのソケットが書き込み可能であるか否かが検査される）。
【０１４９】
ステップＳ１５３において、Multi Flow RTP８３は、検査対象となるUDPポートが通信可能であるか否かの検査結果を確認する。すなわち、より詳細には、Multi Flow RTP８３は、例えば、select（）関数の結果を、FD-ISSET（OS（＝SystemV）の標準関数）を実行することにより確認する。
【０１５０】
以上のように、ステップＳ１５１乃至Ｓ１５３の処理により、カウンタｐで指定される１個の検査対象となるUDPポートが送信可能であるか否かが検査される。
【０１５１】
ここで、図１８のフローチャートに戻る。
【０１５２】
ステップＳ１１３において、Multi Flow RTP８３は、検査対象となったカウンタｐに対応するUDPポートが送信可能であるか否かを判定する。例えば、送信可能ではない、すなわち、例えば、別のデータを送信中などの状態で、送信できない状態である場合、その処理は、ステップＳ１１２に戻る。すなわち、送信可能であると判定されるまで、ステップＳ１１２，Ｓ１１３の処理が繰り返される。
【０１５３】
そして、ステップＳ１１３において、送信可能であると判定された場合、その処理は、ステップＳ１１４に進む。
【０１５４】
ステップＳ１１４において、RTCP８４は、カウンタｐに対応するUDPポートを制御して、Multi Flow RTP８３により分割されたストリームデータをクライアントPC１に送信させる。
【０１５５】
ステップＳ１３１において、RTCP６４は、制御情報に含まれている通信に利用されるUDPポート６７乃至６９を特定するポート番号、および、利用ポート数の情報に基づいて、UDPポート６７乃至６９を制御して、送信されてきた分割されているストリームデータを受信させ、Multi Flow RTP６３に供給させる。すなわち、UDPポート６７乃至６９のうち、上述したカウンタｐに対応するUDPポート８７乃至８９のいずれかで分割されているストリームデータが受信される。
【０１５６】
一方、ステップＳ１１５において、Multi Flow RTP８３は、送信すべきストリームデータがあるか、すなわち、分割したストリームデータのうち、送信されずに残っているものがあるか否かを判定し、送信すべきストリームデータが存在しない場合、その処理は終了する。
【０１５７】
ステップＳ１１５において、送信すべき、分割されているストリームデータがあると判定された場合、ステップＳ１１６において、Multi Flow RTP８３は、カウンタｐを１インクリメントする。
【０１５８】
ステップＳ１１７において、Multi Flow RTP８３は、カウンタｐが上限であるＰよりも大きいか否かを判定し、例えば、大きくないと判定された場合、その処理は、ステップＳ１１２に戻る。
【０１５９】
また、ステップＳ１１７において、カウンタｐが上限であるＰよりも大きいと判定された場合、その処理は、ステップＳ１１１に戻る。
【０１６０】
すなわち、以上の処理により、各UDPポートについて、UDPポート８７，８８，８９の順番に送信可能であるか否かが判定され、UDPポート８９の検査が終了すると、再びUDPポート８７が送信可能であるかが判定され、その処理が繰り返される。さらに、送信不能である場合、送信可能となるまで待ち、送信可能となった時点で、そのUDPポートからストリームデータを送信した後に、次のUDPポートの検査を実行しているため、分割されたストリームデータは、必ずUDPポート８７，８８，８９，８７，８８，８９・・の順番に割振られる（ラウンドロビン方式で割振られる）。従って、クライアントPC１は、UDPポート６７，６８，６９，６７，６８，６９・・の順番に受信されることになる。
【０１６１】
結果として、複数のUDPポートにより分割されたストリームデータが効率よく送信されることになる。尚、図１７においては、複数のUDPポート８７，８８，８９から並列に同じストリームデータが送信されることが想定されているが、上述したように同時タイミングではない。
【０１６２】
次に、図１９のフローチャートを参照して、即時方式による複数UDPポート送信処理および複数UDPポート受信処理について説明する。尚、図１９のフローチャートにおけるステップＳ１７１乃至Ｓ１７７，Ｓ１９１の処理は、図１７のフローチャートにおけるステップＳ１１１乃至Ｓ１１７，Ｓ１３１の処理と同様であるので、その説明は省略する。
【０１６３】
すなわち、図１９のフローチャートの各処理と図１７のフローチャートの各処理は、全く同一である。しかしながら、図１７においては、ステップＳ１７４において、送信不能であると判定された場合、ステップＳ１７４の処理がスキップされて、その処理は、ステップＳ１７５に進む。
【０１６４】
従って、送信不能と判定されたUDPポートが送信可能と判定されるまでの待ち状態がなくなる。このため、複数のUDPポート８７乃至８９の送信順序は、一定とはならないが、UDPポートが送信不能であると判定された場合、即時、別のUDPポートを検査し、送信可能なUDPポートに対して優先的に分割されているストリームデータの送信が割振られる。
【０１６５】
結果として、即時方式による複数UDPポート送信処理および複数UDPポート受信処理は、ラウンドロビン方式による複数UDPポート送信処理および複数UDPポート受信処理よりも高速でストリームデータを送信することが可能となる。
【０１６６】
尚、以上の説明においては、複数のポートの使用例として複数のUDPポートを使用した場合の例について説明してきたが、上述した処理は、プロトコルに依存しない処理であるため、複数のポートは、必ずしもUDPポートである必要が無く、例えば、複数のUDPポートの代わりに複数のTCPポートを使用しても同様の効果が得られる。
【０１６７】
図２１，図２２は、それぞれラウンドロビン方式と即時方式による複数のTCPポートによる送信処理および複数のTCPポートによる受信処理におけるTCPポート数とスループットの関係を示している。尚、図２１，図２２においては、実線が、50Mbpsまで、点線が30Mbpsまで、１点鎖線が10Mbpsまでのそれぞれ使用可能な帯域の通信経路を示している。また、縦軸は、スループット（Mbps）を示し、横軸はTCPポート数を示している。
【０１６８】
図２１で示されるように、ラウンドロビン方式を採用した場合、帯域が最大50Mbpsのとき、ポート数が2個で、帯域が最大30Mbpsのとき、ポート数が3個で、帯域が最大10Mbpsのとき、ポート数が６個で、それぞれ急激にスループットが低下することが示されている。
【０１６９】
一方、図２２で示されるように、即時方式を採用した場合、帯域が最大50Mbpsのとき、帯域が最大30Mbpsのとき、帯域が最大10Mbpsのときのいずれにおいても、TCPポート数に関わらず帯域幅を十分に使うことができる事が示されている。
【０１７０】
結果として、図２１，図２２からもわかるように、ラウンドロビン方式よりも即時方式の方が、複数のTCPポートを使用して通信した場合、帯域を十分に使用することができ、高速で、データを送受信できることが示されている。尚、当然のことながら、複数のUDPポートを使用した場合についても、図２１，図２２を参照して説明した効果と同様な効果を得ることが可能であることは言うまでもない。
【０１７１】
以上によれば、セッション層における１セッションの通信データを複数のトランスポート層のポートを利用して送信することにより、高速通信と安定的な通信を実現することが可能となる。
【０１７２】
上述した一連の処理は、ハードウェアにより実行させることもできるが、ソフトウェアにより実行させることもできる。一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、専用のハードウェアに組み込まれているコンピュータ、または、各種のプログラムをインストールすることで、各種の機能を実行させることが可能な、例えば汎用のパーソナルコンピュータなどに記録媒体からインストールされる。
【０１７３】
プログラムが記録されている記録媒体は、図３に示すように、コンピュータとは別に、ユーザにプログラムを提供するために配布される、プログラムが記録されている磁気ディスク２１（フレキシブルディスクを含む）、光ディスク２２（CD-ROM(Compact Disc-Read Only Memory)，DVD（Digital Versatile Disk）を含む）、光磁気ディスク２３（MD（Mini-Disc）を含む）、もしくは半導体メモリ２４などよりなるパッケージメディアにより構成されるだけでなく、コンピュータに予め組み込まれた状態でユーザに提供される、プログラムが記録されているROM２２や、記憶部２８に含まれるハードディスクなどで構成される。
【０１７４】
尚、本明細書において、記録媒体に記録されるプログラムを記述するステップは、記載された順序に沿って時系列的に行われる処理は、もちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理を含むものである。
【０１７５】
また、本明細書において、システムとは、複数の装置により構成される装置全体を表すものである。
【図面の簡単な説明】
【０１７６】
【図１】輻輳を説明する図である。
【図２】本発明を適用した配信システムの一実施の形態の構成を示す図である。
【図３】図２のクライアントPCの構成を示す図である。
【図４】図２のクライアントPCと配信サーバ７により実現される機能を示す図である。
【図５】OSI参考モデルを説明する図である。
【図６】図４で示されるクライアントPCと配信サーバ７により実現される機能をOSI参考モデルに対応させた図である。
【図７】図４の機能による配信処理を説明するフローチャートである。
【図８】配信処理を説明する図である。
【図９】データの転送速度を説明する図である。
【図１０】図２のクライアントPCと配信サーバ７により実現されるその他の機能を示す図である。
【図１１】図１０の機能による配信処理を説明するフローチャートである。
【図１２】図１０の機能による配信処理を説明する図である。
【図１３】図１０の機能による配信処理を説明する図である。
【図１４】図２のクライアントPCと配信サーバ７により実現されるさらにその他の機能を示す図である。
【図１５】図２のクライアントPCと配信サーバ７により実現されるさらにその他の機能を示す図である。
【図１６】図２のクライアントPCと配信サーバ７により実現されるさらにその他の機能を示す図である。
【図１７】図１６の機能による配信処理を説明するフローチャートである。
【図１８】ラウンドロビン方式による複数UDPポート送信処理および複数UDPポート受信処理を説明するフローチャートである。
【図１９】UDPポート検査処理を説明するフローチャートである。
【図２０】即時方式による複数UDPポート送信処理および複数UDPポート受信処理を説明するフローチャートである。
【図２１】ラウンドロビン方式による複数UDPポート送信処理および複数UDPポート受信処理におけるスループットとUDPポート数の関係を説明する図である。
【図２２】即時方式による複数UDPポート送信処理および複数UDPポート受信処理におけるスループットとUDPポート数の関係を説明する図である。
【符号の説明】
【０１７７】
１  クライアントPC，  ２  ルータ，  ３  インターネットサービスプロバイダサーバ，  ４  ルータ，  ５  ネットワーク，  ６  ルータ，  ７  配信サーバ，  １１，１１ａ乃至１１ｆ  ルータ，  ６１  プレイヤ，  ６２  RTSP，  ６３  Multi  Flow  RTP，  ６４  RTCP，  ６５，６６  TCP，  ６７乃至６９  UDP，  ８１  プレイヤ，  ８２  RTSP，  ８３  Multi  Flow  RTP，  ８４  RTCP，  ８５，８６  TCP，  ８７乃至８９  UDP，  １０１，１１１  再送処理機能付Multi  Flow  RTP，  １７１  再送処理機能付Multi  Flow  RTP，  １７２  RTSP，  １８１  並列Multi  Flow  RTP，  １８２  RTSP
【図１】
2005244929.tif 000003
【図２】
2005244929.tif 000004
【図３】
2005244929.tif 000005
【図４】
2005244929.tif 000006
【図５】
2005244929.tif 000007
【図６】
2005244929.tif 000008
【図７】
2005244929.tif 000009
【図８】
2005244929.tif 000010
【図９】
2005244929.tif 000011
【図１０】
2005244929.tif 000012
【図１１】
2005244929.tif 000013
【図１２】
2005244929.tif 000014
【図１３】
2005244929.tif 000015
【図１４】
2005244929.tif 000016
【図１５】
2005244929.tif 000017
【図１６】
2005244929.tif 000018
【図１７】
2005244929.tif 000019
【図１８】
2005244929.tif 000020
【図１９】
2005244929.tif 000021
【図２０】
2005244929.tif 000022
【図２１】
2005244929.tif 000023
【図２２】
2005244929.tif 000024