(57)【特許請求の範囲】
【請求項１】
データ送信装置およびデータ受信装置からなり、ストリーム型データ転送を実行するデータ通信システムであり、
データ送信装置は、
送信データを格納したデータパケットを送信するパケット送信処理部と、
データ受信装置から受信する再送要求メッセージパケットに従って再送すべきデータパケットの抽出処理を実行する再送制御部とを有し、
データ受信装置は、
前記データ送信装置から受信するデータパケットを受信するパケット受信処理部と、
前記データ送信装置から受信するデータパケットのエラーまたはロスト・データパケットの検出に基づいて、前記データ送信装置に対するデータパケット再送要求としての再送要求メッセージパケットの送信可否を判定する再送要求処理制御部とを有し、
前記再送要求処理制御部は、
再送要求に基づく再送データパケット受信が、再送データパケット格納データの再生に伴う処理開始時間前に可能か否かを判定し、可能であるとの判定を条件として、前記再送要求メッセージの送信処理を実行すると共に、
再送データパケット受信が、再送データパケット格納データの再生に伴う処理開始時間前に可能となる予め計測済みの最終期限において、最終的なロスト・データパケットの検出処理を実行し、前記最終期限においてロスト・データパケットの検出がなされた場合には、最終的な前記再送要求メッセージの送信処理を実行する構成を有することを特徴とするデータ通信システム。
【請求項２】
ストリーム型データ受信を実行するデータ受信装置であり、
データ送信装置から受信するデータパケットを受信するパケット受信処理部と、
前記データ送信装置から受信するデータパケットのエラーまたはロスト・データパケットの検出に基づいて、前記データ送信装置に対するデータパケット再送要求としての再送要求メッセージパケットの送信可否を判定する再送要求処理制御部とを有し、
前記再送要求処理制御部は、
再送要求に基づく再送データパケット受信が、再送データパケット格納データの再生に伴う処理開始時間前に可能か否かを判定し、可能であるとの判定を条件として、前記再送要求メッセージの送信処理を実行すると共に、
再送データパケット受信が、再送データパケット格納データの再生に伴う処理開始時間前に可能となる予め計測済みの最終期限において、最終的なロスト・データパケットの検出処理を実行し、前記最終期限においてロスト・データパケットの検出がなされた場合には、最終的な前記再送要求メッセージの送信処理を実行する構成を有することを特徴とするデータ受信装置。
【請求項３】
前記データパケットの格納データは、符号化データであり、
前記再送要求処理制御部は、
再送要求に基づく再送データパケット受信が、再送データパケット格納データの復号処理を含む再生に伴う処理開始時間前に可能か否かを判定する構成であることを特徴とする請求項２に記載のデータ受信装置。
【請求項４】
前記データ受信装置は、
再送要求データパケットの識別データとしてのシーケンス番号と、該シーケンス番号に対応するデータパケットの重複再送の指定回数データを格納した再送要求メッセージパケットを生成して前記データ送信装置に送信する構成を有することを特徴とする請求項２に記載のデータ受信装置。
【請求項５】
前記データ受信装置の受信するデータパケットは、動画像データであり、
前記再送要求処理制御部は、
動画像データの１画像フレームの構成データを格納した複数のデータパケットの終端データパケットの受信に応じて、該終端データパケットの属する画像フレームの構成データを格納した複数のデータパケット中のエラーまたはロスト・データパケットの検出処理を実行する構成であることを特徴とする請求項２に記載のデータ受信装置。
【請求項６】
前記データ受信装置の受信するデータパケットは、動画像データであり、
前記再送要求処理制御部は、
動画像データの１画像フレームの構成データを格納した複数のデータパケットの先頭データパケットの受信に応じて、該先頭データパケットの属する画像フレームの前フレームの構成データを格納した複数のデータパケット中のエラーまたはロスト・データパケットの検出処理を実行する構成であることを特徴とする請求項２に記載のデータ受信装置。
【請求項７】
前記再送要求処理制御部は、
データパケット格納データの再生処理開始時間に間に合うための再送要求最終期限に基づいて、受信データパケット中のエラーまたはロスト・データパケットの検出処理を実行する構成であることを特徴とする請求項２に記載のデータ受信装置。
【請求項８】
前記再送要求処理制御部は、
定期的な時間間隔に基づいて、受信データパケット中のエラーまたはロスト・データパケットの検出処理を実行する構成であることを特徴とする請求項２に記載のデータ受信装置。
【請求項９】
前記再送要求処理制御部は、
前記データ送信装置とデータ受信装置における往復伝播遅延（ＲＴＴ）の計測処理のために前記データ送信装置に対するエコーパケットの送信および該エコーパケットに対するエコーリプライパケットの受信処理制御を実行し、
該エコーパケットに基づいて算出する往復伝播遅延（ＲＴＴ）に基づいて、再送要求に基づく再送データパケット受信が、再送データパケット格納データの再生処理開始時間前に可能か否かを判定する構成を有することを特徴とする請求項２に記載のデータ受信装置。
【請求項１０】
前記データ受信装置は、
再送要求データパケットの識別データとしてのシーケンス番号、またはパケットの属するタイムスタンプ指定データの少なくともいずれかと、再送要求範囲を指定するオプションを格納した再送要求メッセージパケットを生成して前記データ送信装置に送信する構成を有することを特徴とする請求項２に記載のデータ受信装置。
【請求項１１】
前記データパケットは、データ転送プロトコルとしてのＲＴＰに従ったフォーマットを有し、前記再送要求は、制御プロトコルとしてのＲＴＣＰに従ったフォーマットを有することを特徴とする請求項２に記載のデータ受信装置。
【請求項１２】
前記データ受信装置は、
複数のデータパケットに関する再送要求を１つの再送要求メッセージパケットとしてデータ送信装置に対して送信する構成であることを特徴とする請求項２に記載のデータ受信装置。
【請求項１３】
前記データ受信装置は、
複数のデータパケットに関する受信確認を１つの受信確認メッセージパケットとしてデータ送信装置に対して送信する構成であることを特徴とする請求項２に記載のデータ受信装置。
【請求項１４】
ストリーム型データ受信を実行するデータ受信装置であり、
データ送信装置から受信するデータパケットを受信するパケット受信処理部と、
前記データ送信装置から受信するデータパケットのエラーまたはロスト・データパケットの検出に基づいて、前記データ送信装置に対するデータパケット再送要求としての再送要求メッセージパケットの送信可否を判定する再送要求処理制御部とを有し、
前記再送要求処理制御部は、
再送要求に基づく再送データパケット受信が、再送データパケット格納データの再生に伴う処理開始時間前に可能か否かを判定し、可能であるとの判定を条件として、前記再送要求メッセージパケットの送信処理を実行し、当該送信処理に際して、前記データパケット受信時におけるパケットロス率に基づいて前記再送要求メッセージパケットの送信回数を変化させ、パケットロス率が一定値以上になった場合は、前記再送要求メッセージパケットの送信回数を増加させる処理を行なう構成を有すると共に、
データパケット格納データの再生処理開始時間に間に合うための再送要求最終期限に基づいて、受信データパケット中のエラーまたはロスト・データパケットの検出処理を実行する構成を有することを特徴とするデータ受信装置。
【請求項１５】
ストリーム型データ受信を実行するデータ受信装置であり、
データ送信装置から受信するデータパケットを受信するパケット受信処理部と、
前記データ送信装置から受信するデータパケットのエラーまたはロスト・データパケットの検出に基づいて、前記データ送信装置に対するデータパケット再送要求としての再送要求メッセージパケットの送信可否を判定する再送要求処理制御部とを有し、
前記再送要求処理制御部は、
再送要求に基づく再送データパケット受信が、再送データパケット格納データの再生に伴う処理開始時間前に可能か否かを判定し、可能であるとの判定を条件として、再送要求送信を決定すると共に、前記再送要求メッセージパケットに対して該再送要求メッセージパケットの再送回数を記述する構成を有するとともに、
データパケット格納データの再生処理開始時間に間に合うための再送要求最終期限に基づいて、受信データパケット中のエラーまたはロスト・データパケットの検出処理を実行する構成を有することを特徴とするデータ受信装置。
【請求項１６】
ストリーム型データ受信を実行するデータ受信方法であり、
データ送信装置から受信するデータパケットを受信するパケット受信処理ステップと、
前記データ送信装置から受信するデータパケットのエラーまたはロスト・データパケットの検出に基づいて、前記データ送信装置に対するデータパケット再送要求としての再送要求メッセージパケットの送信可否を判定する再送要求処理制御ステップとを有し、
前記再送要求処理制御ステップは、
再送要求に基づく再送データパケット受信が、再送データパケット格納データの再生に伴う処理開始時間前に可能か否かを判定し、可能であるとの判定を条件として、前記再送要求メッセージの送信処理を実行すると共に、
再送データパケット受信が、再送データパケット格納データの再生に伴う処理開始時間前に可能となる予め計測済みの最終期限において、最終的なロスト・データパケットの検出処理を実行し、前記最終期限においてロスト・データパケットの検出がなされた場合には、最終的な前記再送要求メッセージの送信処理を実行するステップを有することを特徴とするデータ受信方法。
【請求項１７】
データ受信装置において、ストリーム型データ受信処理を実行させるコンピュータ・プログラムであって、
データ送信装置から受信するデータパケットを受信するパケット受信処理ステップと、
前記データ送信装置から受信するデータパケットのエラーまたはロスト・データパケットの検出に基づいて、前記データ送信装置に対するデータパケット再送要求としての再送要求メッセージパケットの送信可否を判定する再送要求処理制御ステップとを有し、
前記再送要求処理制御ステップは、
再送要求に基づく再送データパケット受信が、再送データパケット格納データの再生に伴う処理開始時間前に可能か否かを判定し、可能であるとの判定を条件として、前記再送要求メッセージの送信処理を実行すると共に、
再送データパケット受信が、再送データパケット格納データの再生に伴う処理開始時間前に可能となる予め計測済みの最終期限において、最終的なロスト・データパケットの検出処理を実行し、前記最終期限においてロスト・データパケットの検出がなされた場合には、最終的な前記再送要求メッセージの送信処理を実行させるステップを有することを特徴とするコンピュータ・プログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラムに関する。さらに詳細には、ストリーミングデータ転送におけるエラー耐性を高めたパケット送信構成を持つデータ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラムに関する。
【０００２】
【従来の技術】
昨今、インターネット通信など、様々な通信媒体を介した画像、音声データ等のデータ転送が盛んに行われている。特に、近年においては、インターネット上のデータ転送において、従来から利用されているダウンロード型伝送方式に加えて、ストリーム型伝送方式によるサービスが増加してきている。ダウンロード型伝送方式においては、映像ファイルや音声ファイルといったマルチメディアデータを伝送する場合、配信サーバからデータファイルを一旦受信側端末の記憶媒体にダウンロードして、その後、記憶媒体から再生することになる。よって、この方式ではファイルを完全に転送が終わるまでは再生できず、長時間再生やリアルタイム再生などには不向きである。
【０００３】
一方、後者のストリーム型伝送方式では、送信側から受信端末にデータ転送が行われている間に、並列して受信データの再生処理を実行するものであり、インターネット電話・遠隔テレビ会議・ビデオオンデマンドといったインターネットサービスに利用されている。
【０００４】
ストリーム型伝送方式は、例えば画像データのＭＰＥＧ圧縮処理により生成されるＭＰＥＧストリームをＩＰ（Internet Protocol）パケットに格納してインターネット上を転送させて、ＰＣやＰＤＡ、携帯電話等の各通信端末において受信するシステム等において使用され、開発が進んでいる。このような技術は、ビデオオンデマンドやライブ映像のストリーミング配信、あるいはビデオ会議、テレビ電話などのリアルタイム通信において有効となる。
【０００５】
このようなストリーム型伝送方式に適したインターネット技術に、IETF RFC1889で規定されているプロトコル：ＲＴＰ(Realtime Transport Protocol)がある。ＲＴＰに従ったデータ転送では、時間情報としてパケットにタイムスタンプを付加し、タイムスタンプの参照により送信側と受信側の時間的関係の把握を行ない、データ受信側において、パケット転送の遅延ゆらぎ（ジッター）などの影響を受けずに同期をとった再生を可能としている。
【０００６】
ただし、ＲＴＰは実時間のデータ転送を保証しているものではない。パケット配送の優先度や設定、管理などはＲＴＰが提供するトランスポートサービスの範疇ではないため、ＲＴＰパケットは、他のパケットと同様、ネットワーク上での配送遅延やパケット損失がおきる可能性がある。しかし、このような事態が起こっても、受信側は期待する時間内に到着したパケットだけを利用してデータを再生することが可能である。これは、映像や音声データが多少のデータ欠損があったとしても、データ品質を落とした再生、あるいはデータ補正処理による再生が可能となるからである。
【０００７】
なお、再生に間に合わず遅延配送されたパケットやエラーの発生したパケットは、受信側でそのまま破棄される。つまり、パケット損失やエラーが発生した場合は、高品質なデータ配信処理を行なっている場合でも、受信側で品質を保持した再生が実行されないという問題点がある。特に、有線区間で１０−５、無線区間で１０−３以上のエラーがあるといわれている中では、配信するメディアの品質保持を考慮すると、ＲＴＰをそのまま利用したデータ転送には問題がある。
【０００８】
このようなＲＴＰに従ったデータ転送における問題点を解決する１つの案としては、データ転送に信頼性が高いデータ転送プロトコルであるＴＣＰに従ってパケットの再送要求および再送パケット送信を行わせる方法が考えられる。しかし、ＴＣＰはエラーには強いが、スループットが低く、遅延が大きいため、再送しても再生時間に間に合わない可能性があり、リアルタイム通信の実現を困難とするという問題がある。
【０００９】
さらに、パケットエラー等に対応するエラー訂正手法として、例えばＦＥＣ（Forward Error Correction）という手段が考えられている。これは誤り訂正を行うためのＦＥＣデータを冗長データとして送信して、エラーが発生した場合には、データ受信側において、このＦＥＣデータをもとにエラーの修復を実行しようとするものである。先のＡＲＱによるパケット再送処理に比べると再送にかかる遅延がない分、遅延時間を低く抑えられるが、冗長データを付加するためにスループットが低下するという問題がある。また、ネットワーク状況に合わせた最適な付加ＦＥＣデータを決定するのは難しく、処理時間のオーバーヘッドが常につきまとうなどの問題が存在する。
【００１０】
【発明が解決しようとする課題】
本発明は、上述の問題点に鑑みてなされたものであり、ビデオオンデマンドや、遠隔テレビ会議のような、リアルタイム再生が望まれるデータ転送処理を効率的に実行可能とかるとともに、パケット損失等のエラー発生時にも品質の低下を抑えて高品質なデータ再生を実現するデータ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラムを提供することを目的とする。
【００１１】
【課題を解決するための手段】
本発明の第１の側面は、
データ送信装置およびデータ受信装置からなり、ストリーム型データ転送を実行するデータ通信システムであり、
データ送信装置は、
送信データを格納したデータパケットを送信するパケット送信処理部と、
データ受信装置から受信する再送要求メッセージパケットに従って再送すべきデータパケットの抽出処理を実行する再送制御部とを有し、
データ受信装置は、
前記データ送信装置から受信するデータパケットを受信するパケット受信処理部と、
前記データ送信装置から受信するデータパケットのエラーまたはロスト・データパケットの検出に基づいて、前記データ送信装置に対するデータパケット再送要求としての再送要求メッセージパケットの送信可否を判定する再送要求処理制御部とを有し、
前記再送要求処理制御部は、
再送要求に基づく再送データパケット受信が、再送データパケット格納データの再生に伴う処理開始時間前に可能か否かを判定し、可能であるとの判定を条件として、前記再送要求メッセージの送信処理を実行すると共に、
再送データパケット受信が、再送データパケット格納データの再生に伴う処理開始時間前に可能となる予め計測済みの最終期限において、最終的なロスト・データパケットの検出処理を実行し、前記最終期限においてロスト・データパケットの検出がなされた場合には、最終的な前記再送要求メッセージの送信処理を実行する構成を有することを特徴とするデータ通信システムにある。
【００２５】
さらに、本発明の第２の側面は、
ストリーム型データ受信を実行するデータ受信装置であり、
データ送信装置から受信するデータパケットを受信するパケット受信処理部と、
前記データ送信装置から受信するデータパケットのエラーまたはロスト・データパケットの検出に基づいて、前記データ送信装置に対するデータパケット再送要求としての再送要求メッセージパケットの送信可否を判定する再送要求処理制御部とを有し、
前記再送要求処理制御部は、
再送要求に基づく再送データパケット受信が、再送データパケット格納データの再生に伴う処理開始時間前に可能か否かを判定し、可能であるとの判定を条件として、前記再送要求メッセージの送信処理を実行すると共に、
再送データパケット受信が、再送データパケット格納データの再生に伴う処理開始時間前に可能となる予め計測済みの最終期限において、最終的なロスト・データパケットの検出処理を実行し、前記最終期限においてロスト・データパケットの検出がなされた場合には、最終的な前記再送要求メッセージの送信処理を実行する構成を有することを特徴とするデータ受信装置にある。
【００２６】
さらに、本発明のデータ受信装置の一実施態様において、前記データ・パケットの格納データは、符号化データであり、前記再送要求処理制御部は、再送要求に基づく再送データパケット受信が、再送データパケット格納データの復号処理を含む再生に伴う処理開始時間前に可能か否かを判定する構成であることを特徴とする。
【００２７】
さらに、本発明のデータ受信装置の一実施態様において、前記データ受信装置は、再送要求データパケットの識別データとしてのシーケンス番号と、該シーケンス番号に対応するデータパケットの重複再送の指定回数データを格納した再送要求メッセージパケットを生成して前記データ送信装置に送信する構成を有することを特徴とする。
【００２８】
さらに、本発明のデータ受信装置の一実施態様において、前記データ受信装置の受信するデータパケットは、動画像データであり、前記再送要求処理制御部は、動画像データの１画像フレームの構成データを格納した複数のデータパケットの終端データパケットの受信に応じて、該終端データパケットの属する画像フレームの構成データを格納した複数のデータパケット中のエラーまたはロスト・データパケットの検出処理を実行する構成であることを特徴とする。
【００２９】
さらに、本発明のデータ受信装置の一実施態様において、前記データ受信装置の受信するデータパケットは、動画像データであり、前記再送要求処理制御部は、動画像データの１画像フレームの構成データを格納した複数のデータパケットの先頭データパケットの受信に応じて、該先頭データパケットの属する画像フレームの前フレームの構成データを格納した複数のデータパケット中のエラーまたはロスト・データパケットの検出処理を実行する構成であることを特徴とする。
【００３０】
さらに、本発明のデータ受信装置の一実施態様において、前記再送要求処理制御部は、データパケット格納データの再生処理開始時間に間に合うための再送要求最終期限に基づいて、受信データパケット中のエラーまたはロスト・データパケットの検出処理を実行する構成であることを特徴とする。
【００３１】
さらに、本発明のデータ受信装置の一実施態様において、前記再送要求処理制御部は、定期的な時間間隔に基づいて、受信データパケット中のエラーまたはロスト・データパケットの検出処理を実行する構成であることを特徴とする。
【００３２】
さらに、本発明のデータ受信装置の一実施態様において、前記再送要求処理制御部は、前記データ送信装置とデータ受信装置における往復伝播遅延（ＲＴＴ）の計測処理のために前記データ送信装置に対するエコーパケットの送信および該エコーパケットに対するエコーリプライパケットの受信処理制御を実行し、該エコーパケットに基づいて算出する往復伝播遅延（ＲＴＴ）に基づいて、再送要求に基づく再送データパケット受信が、再送データパケット格納データの再生処理開始時間前に可能か否かを判定する構成を有することを特徴とする。
【００３３】
さらに、本発明のデータ受信装置の一実施態様において、前記データ受信装置は、再送要求データパケットの識別データとしてのシーケンス番号、またはパケットの属するタイムスタンプ指定データの少なくともいずれかと、再送要求範囲を指定するオプションを格納した再送要求メッセージパケットを生成して前記データ送信装置に送信する構成を有することを特徴とする。
【００３４】
さらに、本発明のデータ受信装置の一実施態様において、前記データパケットは、データ転送プロトコルとしてのＲＴＰに従ったフォーマットを有し、前記再送要求は、制御プロトコルとしてのＲＴＣＰに従ったフォーマットを有することを特徴とする。
【００３５】
さらに、本発明のデータ受信装置の一実施態様において、前記データ受信装置は、複数のデータパケットに関する再送要求を１つの再送要求メッセージパケットとしてデータ送信装置に対して送信する構成であることを特徴とする。
【００３６】
さらに、本発明のデータ受信装置の一実施態様において、前記データ受信装置は、複数のデータパケットに関する受信確認を１つの受信確認メッセージパケットとしてデータ送信装置に対して送信する構成であることを特徴とする。
さらに、本発明の第３の側面は、
ストリーム型データ受信を実行するデータ受信装置であり、
データ送信装置から受信するデータパケットを受信するパケット受信処理部と、
前記データ送信装置から受信するデータパケットのエラーまたはロスト・データパケットの検出に基づいて、前記データ送信装置に対するデータパケット再送要求としての再送要求メッセージパケットの送信可否を判定する再送要求処理制御部とを有し、
前記再送要求処理制御部は、
再送要求に基づく再送データパケット受信が、再送データパケット格納データの再生に伴う処理開始時間前に可能か否かを判定し、可能であるとの判定を条件として、前記再送要求メッセージパケットの送信処理を実行し、当該送信処理に際して、前記データパケット受信時におけるパケットロス率に基づいて前記再送要求メッセージパケットの送信回数を変化させ、パケットロス率が一定値以上になった場合は、前記再送要求メッセージパケットの送信回数を増加させる処理を行なう構成を有すると共に、
データパケット格納データの再生処理開始時間に間に合うための再送要求最終期限に基づいて、受信データパケット中のエラーまたはロスト・データパケットの検出処理を実行する構成を有することを特徴とするデータ受信装置にある。
さらに、本発明の第４の側面は、
ストリーム型データ受信を実行するデータ受信装置であり、
データ送信装置から受信するデータパケットを受信するパケット受信処理部と、
前記データ送信装置から受信するデータパケットのエラーまたはロスト・データパケットの検出に基づいて、前記データ送信装置に対するデータパケット再送要求としての再送要求メッセージパケットの送信可否を判定する再送要求処理制御部とを有し、
前記再送要求処理制御部は、
再送要求に基づく再送データパケット受信が、再送データパケット格納データの再生に伴う処理開始時間前に可能か否かを判定し、可能であるとの判定を条件として、再送要求送信を決定すると共に、前記再送要求メッセージパケットに対して該再送要求メッセージパケットの再送回数を記述する構成を有するとともに、
データパケット格納データの再生処理開始時間に間に合うための再送要求最終期限に基づいて、受信データパケット中のエラーまたはロスト・データパケットの検出処理を実行する構成を有することを特徴とするデータ受信装置にある。
【００３７】
さらに、本発明の第５の側面は、
ストリーム型データ受信を実行するデータ受信方法であり、
データ送信装置から受信するデータパケットを受信するパケット受信処理ステップと、
前記データ送信装置から受信するデータパケットのエラーまたはロスト・データパケットの検出に基づいて、前記データ送信装置に対するデータパケット再送要求としての再送要求メッセージパケットの送信可否を判定する再送要求処理制御ステップとを有し、
前記再送要求処理制御ステップは、
再送要求に基づく再送データパケット受信が、再送データパケット格納データの再生に伴う処理開始時間前に可能か否かを判定し、可能であるとの判定を条件として、前記再送要求メッセージの送信処理を実行すると共に、
再送データパケット受信が、再送データパケット格納データの再生に伴う処理開始時間前に可能となる予め計測済みの最終期限において、最終的なロスト・データパケットの検出処理を実行し、前記最終期限においてロスト・データパケットの検出がなされた場合には、最終的な前記再送要求メッセージの送信処理を実行するステップを有することを特徴とするデータ受信方法にある。
【００４９】
さらに、本発明の第６の側面は、
データ受信装置において、ストリーム型データ受信処理を実行させるコンピュータ・プログラムであって、
データ送信装置から受信するデータパケットを受信するパケット受信処理ステップと、
前記データ送信装置から受信するデータパケットのエラーまたはロスト・データパケットの検出に基づいて、前記データ送信装置に対するデータパケット再送要求としての再送要求メッセージパケットの送信可否を判定する再送要求処理制御ステップとを有し、
前記再送要求処理制御ステップは、
再送要求に基づく再送データパケット受信が、再送データパケット格納データの再生に伴う処理開始時間前に可能か否かを判定し、可能であるとの判定を条件として、前記再送要求メッセージの送信処理を実行すると共に、
再送データパケット受信が、再送データパケット格納データの再生に伴う処理開始時間前に可能となる予め計測済みの最終期限において、最終的なロスト・データパケットの検出処理を実行し、前記最終期限においてロスト・データパケットの検出がなされた場合には、最終的な前記再送要求メッセージの送信処理を実行させるステップを有することを特徴とするコンピュータ・プログラムにある。
【００５０】
なお、本発明のコンピュータ・プログラムは、例えば、様々なプログラム・コードを実行可能な汎用コンピュータ・システムに対して、コンピュータ可読な形式で提供する記憶媒体、通信媒体、例えば、ＣＤやＦＤ、ＭＯなどの記録媒体、あるいは、ネットワークなどの通信媒体によって提供可能なコンピュータ・プログラムである。このようなプログラムをコンピュータ可読な形式で提供することにより、コンピュータ・システム上でプログラムに応じた処理が実現される。
【００５１】
本発明のさらに他の目的、特徴や利点は、後述する本発明の実施例や添付する図面に基づくより詳細な説明によって明らかになるであろう。なお、本明細書においてシステムとは、複数の装置の論理的集合構成であり、各構成の装置が同一筐体内にあるものには限らない。
【００５２】
【発明の実施の形態】
［システム及びデータ送受信概要］
まず、図１を参照して、本発明のシステム概要及びデータ送受信処理の概要について説明する。
【００５３】
図１のデータ通信システムにおいて、送信側端末１０４は受信側端末１２１に対して画像、音声等のデータをパケット化して送信する。転送データは、例えばビデオカメラ１０１によって取得された画像、音声データである。なお、転送データは、ＣＤ，ＤＶＤ等の記憶媒体から入力されるデータ、あるいは外部ネットワーク、衛星等から受信するデータ等であってもよい。なお、以下の説明では、１つの例として送信側端末１０４から受信側端末１２１へビデオカメラ１０１によって取得された動画像データを転送する構成を中心として説明する。
【００５４】
ビデオカメラ１０１によって取得された動画像データは、送信側端末１０４の符号化装置１０２により符号化、例えばＭＰＥＧ圧縮処理等による符号化がなされて、バッファ１０３に蓄積される。バッファ１０３に蓄積された符号化データは、リアルタイム・トランスポート・プロトコル：ＲＴＰ（Real-time Transport Protocol）に従ったデータ・パケット（以下パケットと称する）を生成するＲＴＰパケット作成部１０６に出力され、符号化データを格納したＲＴＰパケットのパケット生成処理が実行される。ＲＴＰパケット作成部１０６において生成された符号化データを格納したＲＴＰパケットは、ＲＴＰプロトコルを通じてＲＴＰパケット出力ポート１１０からＩＰネットワーク１１１に送出される。送信側端末１０４のＲＴＰパケット作成部１０６およびＲＴＰパケット出力ポートによってパケット送信処理部が構成される。
【００５５】
ＲＴＰパケット作成部１０６は、符号化データをペイロードとしたパケットを生成する処理を実行する。ペイロードデータに対して、ＲＴＰヘッダを付加しパケット化する。ＲＴＰパケット構成を図２に示す。ＲＴＰヘッダには、バージョン番号（ｖ）、パディング（Ｐ）、拡張ヘッダ（Ｘ）の有無、送信元数（Ｃｏｕｎｔｅｒ）、マーカ情報（ｍａｒｋｅｒ  ｂｉｔ）、ペイロードタイプ（Ｐａｙｌｏａｄ  ｔｙｐｅ）、シーケンス番号、タイムスタンプ、同期ソース（送信元）識別子（ＳＳＲＣ）および貢献ソース（送信元）識別子（ＣＳＲＣ）の各フィールドが設けられている。データ受信側において、ＲＴＰヘッダに付与されたタイムスタンプによりＲＴＰパケットの展開時に処理時間の制御が実行され、リアルタイム画像、または音声の再生制御が可能となる。なお、例えば動画像データの符号化データを格納したＲＴＰパケットにおいては、１つの画像フレームに属する複数のＲＴＰパケットに共通のタイムスタンプが設定され、各フレームを構成する終端パケットには、終端であることを示す識別フラグがＲＴＰヘッダに格納される。
【００５６】
ＲＴＰヘッダを付加されたパケットはさらにＩＰヘッダが付与される。図３にＩＰパケットの構成中のＩＰヘッダの詳細を示す。ＩＰｖ４、ＩＰｖ６等のバージョンを示すバージョン、ヘッダ長、さらに、優先度情報を格納したＴＯＳ（Type of Service）フィールド、パケットの長さ、パケットの識別子、ＩＰ層でのデータ分割（フラグメント）に関する制御情報としてのフラグ、分割（フラグメント）されたデータの場所を示す断片オフセット、データの破棄までの時間情報を示すＴＴＬ（Time to Live）、上位層で利用されるプロトコル（４：ＩＰ，ＴＣＰ：７，ＵＤＰ：１７…）ヘッダのチェックサム、送信元ＩＰアドレス、宛て先ＩＰアドレスを有する。
【００５７】
図１に戻り、データ受信処理について説明する。受信側端末１２１のＲＴＰパケット入力ポート１１２は、ＩＰネットワーク１１１を介して送信側端末１０４からのＲＴＰパケットを受信する。受信したＲＴＰパケットは、パケット解析部１１４においてパケットの解析が実行される。受信側端末１２１のＲＴＰパケット入力ポート１１２および、パケット解析部１１４によってパケット受信処理部が構成される。パケット解析部１１４は、具体的にはパケット内のヘッダ部、データ部についての解析が実行される。パケットから取り出されたペイロードとしてのデータ、すなわち、符号化データは、バッファ１１７に蓄積される。また、パケットから抽出されたデータのバッファの蓄積位置を示す位置データや、各データに対応するパケットのヘッダ情報は、インデックスリスト１１８として蓄積される。
【００５８】
バッファ１１７に蓄積された符号化データは、インデックスリスト１１８に蓄積されたヘッダ情報に基づく時間制御の下にデコーダ１２０に渡され、デコーダ１２０によって復号処理が実行される。例えば動画像を構成する各画像フレームは、複数のパケットに格納されたデータによって構成され、１つの画像フレームを構成するデータを格納した複数のＲＴＰパケットのヘッダには、同一のタイムスタンプが格納されるので、インデックスリスト１１８に蓄積されたヘッダ情報のタイムスタンプを参照して同一タイムスタンプを持つパケットを１つの画像フレームを構成する符号化データの集合として、デコーダ１２０に渡すことが可能となり、デコーダ１２０は、フレーム毎に復号処理を実行することができる。デコーダ１２０において復号されたデータは、再生装置としてのディスプレイ１２３、またはスピーカ１２２へ渡され、出力再生される。
【００５９】
送信側端末１０４から受信側端末１２１へ転送されるパケットが全て滞りなく、また、エラーのない状態で送信されれば、受信側端末１２１におけるリアルタイムデータ再生は問題なく実行される。しかし、実際は、ネットワーク上でのパケット損失の発生、遅延、転送パケットのデータエラー等、様々な要因に基づく再生エラーあるいは再生データの品質低下が発生し得る。
【００６０】
本発明のシステムにおいては、受信側端末１２１のＲＴＰパケット解析部１１４においてパケット損失等のエラーの発生を検出し、パケット損失等のエラー発生が検出された際には、ＡＲＱ（Auto Repeat reQuest）判定部１１９において、リアルタイム再生シーケンスを考慮したパケット再送要求の可否判定処理を実行する。ＡＲＱ（Auto Repeat reQuest）判定部１１９は、データ送信装置から受信するデータパケットのエラーまたはロスト・データパケットの検出に基づいて、データ送信装置に対するデータパケット再送要求としての再送要求メッセージパケットの送信可否を判定する再送要求処理制御部として機能する。ＡＲＱ判定部１１９における具体的な処理については後述する。
【００６１】
ＡＲＱ判定部１１９において、再送要求を実行するとの判定がなされた場合、受信側端末１２１は、再送要求パケットを識別するデータを格納した再送要求ＮＡＣＫ（Negative ACKnowledge)−ＲＴＣＰ（Real-time Transport Control Protocol）パケットをＲＴＣＰパケット作成装置１１６にて作成し、ＲＴＣＰパケット入出力ポート１１３を介して、送信側端末１０４に対して出力する。
【００６２】
送信側端末１０４のＲＴＣＰパケット入出力ポート１０９において、受信側端末１２１からの再送要求を示すＮＡＣＫ−ＲＴＣＰパケットを受信すると、受信したＮＡＣＫ−ＲＴＣＰパケットをＲＴＣＰパケット解析部１０８において解析し、解析結果をＡＲＱ処理部１０５へ渡す。ＡＲＱ処理部１０５では、再送要求に応じたパケットの再送を実行するため、ＮＡＣＫ−ＲＴＣＰパケットにおいて指定されたパケットをバッファ１０３から抽出し、抽出したパケットを、ＲＴＰパケット出力ポート１１０を介して再送する制御処理を実行する。ＡＲＱ処理部１０５は、データ受信端末装置から受信する再送要求メッセージパケットに従って再送すべきデータパケットの抽出処理を実行する再送制御部として機能する。なお、ＮＡＣＫ−ＲＴＣＰパケットに基づく再送要求に応じたパケット再送処理において、送信側端末１０４は、ＮＡＣＫ−ＲＴＣＰパケットに重複送信の指定がある場合等、必要に応じてＡＲＱ処理部１０５の判断により再送パケットを重複して送る場合もある。これらの処理の詳細については、後述する。
【００６３】
送信側端末１０４において送信すべきストリームデータが終了したのを検知した場合には、送信側端末１０４のＲＴＣＰパケット作成部１０７の生成したＥＯＳ（End Of Stream）メッセージを持つＲＴＣＰパケットを受信側端末１２１へ送り、データストリームの終了を明示する。
【００６４】
本発明のシステムにおいては、ＡＲＱ処理部１０５において、リアルタイム再生を考慮して、ロストパケットに関する再送要求の実行／非実行の処理を決定する。データ転送における自動再送要求方式であるＡＲＱ（Automatic Repeat reQuest）は非常に有効な誤り訂正機能として知られている。ＡＲＱの具体的方式としては、例えばＳＡＷ（Stop And Wait）方式、ＧＢＮ（Go Back N）方式、ＳＲ（Selective Repeat）方式など種々の方法が提案され実現されている。本実施例においては、ＡＲＱ基本アルゴリズムとして、スループット特性が高い選択再送ＳＲ（Selective Repeat）方式エラー訂正機能として使用する例について説明する。
【００６５】
ＳＲ方式の場合、理想的には送信側と受信側で無限のバッファを用意する必要がある。そのため、受信側のバッファオーバーフローが起こった時点または起こりそうな時点でＳＲ方式から別の再送方式に変更する方法やパケットのコピー伝送を通常から行いオーバーフローを回避する方法などが提案されている。しかしながら、本実施例におけるエラー訂正機能においては、ＰＨＳ、ＴＣＰ、データリンク層などに代表される完全にデータを送信することを第一優先にしているＡＲＱと異なり、データ受信側で実行される受信データの再生処理時間から想定されるパケット受信最終許容時間までに、できるだけ必要なデータの受信を実現する事を優先している。よって、ＳＲ方式からＳＴ方式やＧＢＮ方式には移行せず、ＳＲ方式のままＡＲＱを行う構成としている。また、バッファフローオーバーにならないよう受信側はバッファ制御を行い効率よくデータを送信する構成とする。
【００６６】
本発明の１つの実施例では、送信中にロストしてしまったパケットの再送要求は、RFC1889 で規定されているＲＴＣＰ（Real-time Transport Control Protocol）に従って、ＮＡＣＫ（Negative ACKnowledge)を送ることで実現する。RFC1889ではＲＴＣＰパケットの連続送信間隔を５秒以上あける事を推奨している。ここで再送要求を５秒以上間隔を空けたとすると、受信側のバッファ溢れが生じるだけでなく、そもそもメディアの再生時間に間に合うように再送することができない。ストリーミングはリアルタイム性が強い分、
＊できるだけ早く再送要求を出す
＊再送要求を受信したらできるだけ早いうちに再送する
という動作を可能な時間内に実施しなければならない。そのために、ＡＲＱに用いるＮＡＣＫパケットは、データ受信側において能動的に随時必要に応じてデータ送信側に対して送信することが必要となり、推奨値を本発明の場合は適用せず、任意タイミングでのＮＡＣＫパケット送信を実行するものとする。
【００６７】
また、RFC1889ではＲＴＣＰのバンド幅を５％以内になるよう規定している。本発明の実施例に係る構成の再送パケットは最小単位で１６ｂｙｔｅと小さいため、再送要求によって帯域を圧迫するほどのものではないと考えられる。なお、画像データ等の実データ自体の伝送には、RFC1889で規定されているＲＴＰ（パケットフォーマットは図２参照）を用いる例について説明するが、パケット毎にシーケンス番号を記述しておけば、ＵＤＰ（User Datagram Protocol）等、他のプロトコルに従った処理も可能である。
【００６８】
リアルタイム再生を実現するデータ転送では、処理時間が限定されるため、送信と受信における往復伝播遅延（ＲＴＴ）が重要なパラメータとなる。往復伝播遅延（ＲＴＴ）が大きい場合、データ受信端末からデータ送信端末に対して再送要求を出しても、再送要求パケットがデータ送信端末側に到着するまでの時間、データ送信端末において指定データを格納した再送パケットを抽出して再送処理を実行するまでの時間、再送パケットをデータ受信端末が受信するまでの時間、これらの処理に時間を要すると、その後、データ受信端末において、デコーダに受信データを渡して復号を行なっても、リアルタイム再生に間に合わない場合が発生する。無論、間に合う間に合わないかかわらず再送要求を出しておく方が、訂正率の向上が達成される可能性は大となるが、再送要求パケットの送信、再送パケットの再送によるネットワークトラフィックの混雑が発生することになり、これらの冗長データの伝送によるオーバーヘッドの問題が発生することになる。
【００６９】
また、送信と受信における往復伝播遅延（ＲＴＴ）をデータ受信端末において、あらかじめ把握することにより、データ受信端末において、再送要求を行なってから再送パケットを受信するまでの時間の把握が可能となり、データ受信端末においてリアルタイム再生を行なうために必要な最終再送要求時間を割り出すことが可能なる。本発明のシステムでは、受信端末のＡＲＱ判定部において、往復伝播遅延（ＲＴＴ）に基づく最終再送要求時間を判定し、判定に基づいて、再送要求としてのＮＡＣＫ−ＲＴＣＰの送信を実行する。
【００７０】
このように、ＡＲＱにおいてリアルタイム性を保持するためには、常に送信と受信における往復伝播遅延（ＲＴＴ）を計測しておく必要がある。本発明のシステムでは、データ受信側端末は、能動的にＲＴＴを計測し、ネットワーク状況等において変化する送信と受信における往復伝播遅延（ＲＴＴ）の更新を実行し、最新のＲＴＴに基づいて再送要求としてのＮＡＣＫ−ＲＴＣＰの送信の実行可否を判定する。
【００７１】
なお、ＲＴＣＰに規定されたＳＲ（Sender Report）とＲＲ（Receiver Report）により送信側はＲＴＴの算出が可能となるが、リアルタイム再生の進行状況に基づいて、再送要求としてのＮＡＣＫ−ＲＴＣＰパケットを送出するかしないかを判定するのは、データ受信側端末であり、データ受信側端末において、逐次、ネットワーク状況を反映したＲＴＴ情報を取得可能とする構成が好ましい。従って、本発明のシステムにおいては、データ受信端末側から能動的にＲＴＴを算出可能な構成としている。具体的には、データ受信端末におけるＥＣＨＯパケットの送信、ＥＣＨＯ−ＲＥＰＬＹパケットの受信により、ＲＴＴの算出を行なう。これらの処理については、後段で詳細に説明する。
【００７２】
データ送信端末は、データ受信端末からのパケット再送要求としてのＮＡＣＫ−ＲＴＣＰパケットを受信すると、ＮＡＣＫ−ＲＴＣＰパケットに指定された再送要求パケットを、現在配信中のパケットと共に送信する。ただし、データ送信端末は、プライオリティを用いた配信スケジューリング機能を実行し、パケットの再送は、配信スケジューリングに従って実行される。
【００７３】
受信端末側から送信端末への応答パケットとして、パケット再送要求としてのＮＡＣＫ−ＲＴＣＰパケットのみを使用する構成としても、自動再送要求方式としてのＡＲＱ（Automatic Repeat reQuest）を有効に活用することができるが、本実施例においては、受信端末側からのパケット受信確認応答としてのＡＣＫ（ACKnowledge）メッセージもデータ送信端末に対する応答パケットとして送信する。このＡＣＫ送信により、再送要求に対応してパケットを保持する送信側のバッファを能動的に早めにクリアすることが可能となり、バッファ溢れの恐れを低下させることが可能となる。
【００７４】
また、ストリーミング配信されるデータが終了したことを明示的に示すＥＯＳ（End Of Stream）メッセージを送信端末側は利用できる。ＥＯＳメッセージを使うことにより、受信側がストリーミング配信データの終了を認識可能となる。従って、受信側が最終フレームを受け取っているにもかかわらず、次のフレームが到着しないことによるＮＡＣＫ送出動作を防ぐことができる。
【００７５】
受信端末側は、受信端末側で保持するタイマーにより、データ受信間隔、ＮＡＣＫ送出後の経過時間等を計測可能であり、タイマーによる計測時間が閾値以上となったことにより、データ終了と判定する処理が可能であるが、ＥＯＳメッセージの受信により、ストリーミング配信データの終了確認が可能となる。従って、タイマーより先に受信完了状態とすることができる。逆に、ＥＯＳメッセージを利用しない、またはＥＯＳがロストしてしまった場合は、ＮＡＣＫを送出しても送信側から再送パケットが送られてこないため、タイマーによって受信完了状態に移ることになる。
【００７６】
［データ送信端末における処理］
以下、図面を参照しながら、データ送信端末における処理の詳細について説明する。
【００７７】
データ送信端末の処理手順を図４に示すフローチャートを参照して説明する。図４に示す処理は、図１の送信側端末１０４において実行される処理を説明したフローである。送信側端末は、例えばビデオカメラ、あるいはＤＶＤ、ＣＤ、ハードディスク等の記憶媒体から撮り込んだデータをエンコーダにおいてＭＰＥＧ圧縮等の符号化処理を実行し、その後、符号化データをペイロードとしたパケットを生成する。図４に示すフローは、このパケット生成処理以降の処理を示している。
【００７８】
データ送信端末は、ステップＳ２０１において、送信データをペイロードとしたＲＴＰパケット生成処理を実行する。ＲＴＰパケットは、先に図２を参照して説明した構成を有しタイムスタンプをヘッダ中に持つ。例えば動画像データを送信する場合は、同一画像フレームに属する符号化データを格納したパケットには同一のタイムスタンプが設定され、後続フレームに進むに従って、増分されたタイムスタンプが設定される。
【００７９】
図５に示すパケット送信に係るタイムシーケンス図を参照して、タイムスタンプの設定例を説明する。データ送信側（Ｓｅｎｄｅｒ）に示すタイムスタンプ１２０００は、１つの画像フレームを構成する符号化データをペイロードとして格納した複数のＲＴＰパケット（シーケンス番号＝１〜６）に付与されるタイムスタンプである。その後のタイムスタンプ１５０００は、後続画像フレームを構成するＲＴＰパケット（シーケンス番号＝７〜１２）と、データ受信側からＮＡＣＫ−ＲＴＣＰパケットによる再送要求があり、再送するパケット（シーケンス番号＝４，５）とに設定されるタイムスタンプである。このように、データ送信端末では、例えば画像フレームを構成するパケットの集合に１つのタイムスタンプを設定してＲＴＰパケットを生成する。
【００８０】
図４に戻り、データ送信端末の処理について説明を続ける。ステップＳ２０１で生成したＲＴＰパケットは、ステップＳ２０２において、ＲＴＰパケット出力ポートを介して受信端末に向けてＩＰネットワークに出力される。なお、ＲＴＰパケットはさらに、先に図３を用いて説明したＩＰヘッダが付与され、ＩＰヘッダに設定されたアドレスに向けて配信されることになる。ステップＳ２０１、Ｓ２０２のパケット生成、パケット送信処理は、ストリーミング配信されるデータが終了したことを明示的に示すＥＯＳ（End Of Stream）を配信し、予め設定した時間をタイマーで計測して、タイマーでの計測時間が設定時間を超えた場合に、処理を終了する。
【００８１】
図４に示すステップＳ２０３のパケット再送要求としてのＮＡＣＫ−ＲＴＣＰパケットの受信判定処理、ステップＳ２０４のパケット受信確認応答としてのＡＣＫ−ＲＴＣＰパケットの受信判定処理、ステップＳ２０５のＲＴＴ時間計測用のＥＣＨＯ−ＲＴＣＰパケットの受信判定処理は、ＲＴＰパケットによる実データ送信中の割込み処理としてＲＴＰパケットによる実データ送信に並行して逐次実行される処理である。
【００８２】
ステップＳ２０３の処理は、データ受信端末からのパケット再送要求であるＮＡＣＫ−ＲＴＣＰパケットの受信判定処理である。データ受信端末からのパケット再送要求であるＮＡＣＫ−ＲＴＣＰパケットを受信した場合は、ステップＳ２１１〜Ｓ２１５の処理を実行する。このステップＳ２１１〜Ｓ２１５の処理は、図１に示すＡＲＱ処理部１０５における処理として実行される。
【００８３】
ステップＳ２１１においては、データ送信装置は、ＮＡＣＫ−ＲＴＣＰパケットを受信する。図６にデータ受信端末において生成し、データ送信端末の受信するパケット再送要求であるＮＡＣＫ−ＲＴＣＰパケットの構成を示す。
【００８４】
ＮＡＣＫ−ＲＴＣＰパケットは、図６に示すようにヘッダ（ＨＥＡＤ）、フォーマット（ＦＯＲＭＡＴ）、パケットタイプ、パケット長、送信同期ソース識別子（ＲＴＣＰ）、タイムスタンプの情報に加えて、再送要求対象となるパケットの識別子としての再送指定シーケンス番号、さらに、各再送指定シーケンス番号に対応するデータとして、「再送回数」、「オプション」、「重複指定回数」が設定可能である。
【００８５】
前述したように、本発明の提案するＡＲＱを適用したシステムでは、ＲＴＣＰに従ったコントロール・パケットとして再送要求としてのＮＡＣＫ、受信確認としてのＡＣＫ、ストリーミング配信されるデータが終了したことを明示的に示すＥＯＳ、送信と受信における往復伝播遅延（ＲＴＴ）を計測する際に使用されるＥＣＨＯ、およびＥＣＨＯ−ＲＥＰＬＹのパケットが利用される。これらの各ＲＴＣＰパケットそれぞれのフォーマットタイプを一制御メッセージとして、すなわちＲＴＣＰヘッダのＰＴ（Payload Type）として区別をするのは汎用的ではない。よって、制御メッセージとしては、フィードバックメッセージ（FM：Feedback Message）として定義しＰＴ（Payload Type）に指定する。かつ、ＲＴＣＰヘッダ内の［フォーマット］フィールドであるＦＭＴ (Feedback Message Format)にそのパケットフォーマットの指定をすることで、どのようなフィードバックメッセージかを決定できる構成とする。
【００８６】
図６に示すように、１つのＮＡＣＫパケットには１つ以上の再送要求対象となるパケットの識別子としてのシーケンス番号を付与することができる構成を持つ。つまり一度のＮＡＣＫパケットの送信処理で複数のパケットについての再送要求が可能になる。また、再送要求パケットのシーケンス番号各々に対して付加される「再送回数」は、何回目の再送要求かを明記するフィールドであり、「重複指定回数」は、再送する場合の多重回数の指定を明記するフィールドであり、「オプション」はその他の任意の情報を格納するフィールドとして使用される。
【００８７】
例えば、「重複指定回数」に［３］をいれておけば、ＮＡＣＫを受信したデータ送信側は、同じデータを格納した再送パケットを［３］つ連続で送る処理を実行する。重要データを格納したパケットについては、重複再送を要求することで、再送パケットの受信の確実性を高めることが可能となる。また、繰り返し、同一パケットについての再送要求としてのＮＡＣＫを送信しているにもかかわらず、受信に成功しない場合や、リアルタイム再生に間に合うための再送可能最終時間に出されるＮＡＣＫにおいて、「重複指定回数」の設定数を増加させてデータ送信側に送信することにより、再送パケットの受信の確実性を高めることが可能となり、データ再生品質を向上させることが可能となる。データ受信側は、このようなＮＡＣＫ−ＲＴＣＰパケットを送信して、データ送信側は、受信したＮＡＣＫ−ＲＴＣＰパケットに基づくパケット再送処理を実行する。
【００８８】
なお、ＲＴＰパケットフォーマットやペイロードフォーマット、または受信端末の利用者が意図的に指定した場合など、パケットに優先度が与えられている場合、優先度が高いパケットやデータに関しての再送は多重再送処理を行なうことで、再送パケットの受信確率を高めるようコントロール可能である。また、「再送回数」フィールドにおいて何回目の再送要求かを明記することで、ＮＡＣＫ自身が損失したことを送信側が検知できる。
【００８９】
「オプション」フィールドには、フィールド設定値に従って、例えば図７に示す処理指定を行なうことが可能となる。すなわち、
オプション設定値＝０
指定シーケンス番号を持つパケットのみの再送要求（デフォルト）
オプション設定値＝１
フレーム先頭パケットから指定シーケンス番号を持つパケットまでの一括再送要求
オプション設定値＝２
指定シーケンス番号からフレーム最後尾までのパケットの一括再送要求
オプション設定値＝３
指定タイムスタンプの付与されたパケットの一括再送要求
オプション設定値＝４
タイムスタンプを無視してシーケンス番号のみで検索して検索結果のパケットの再送を要求
【００９０】
画像データ等の符号化データは、先に図２を参照して説明したように、タイムスタンプとシーケンス番号をセットとしたヘッダを持つ１つのＲＴＰパケットに格納した構成を有するが、データ転送処理において、タイムスタンプの変わり目を含んた連続的なエラーとしてのバーストエラーが起こった場合、あるいは、バーストエラーの発生により、フレーム単位でパケットの損失が発生した場合などにおいては、受信端末側では、パケット損失の発生したパケットに対応するタイムスタンプとシーケンス番号のセットを特定できない場合が発生する。このような場合において、特定可能なタイムスタンプ、あるいはシーケンス番号のいずれか一方のみを指定して、上記のオプション設定値を設定することにより、フレキシブルな態様で再送の必要な１以上のパケット指定が可能となる。
【００９１】
このように、データ受信端末では、様々な態様での再送要求パケットの指定が可能であり、ＮＡＣＫ−ＲＴＣＰパケットを受信したデータ送信端末のＡＲＱ処理部１０５は、オプションフィールドの設定値に従って、バッファ１０３に格納済みのパケットから指定パケットを抽出して、再送処理を実行する。
【００９２】
図４に戻り、データ送信端末の処理について説明する。ステップＳ２１２では、ステップＳ２１１で受信したＮＡＣＫ−ＲＴＣＰパケットに指定された再送要求パケットに対応するシーケンス番号を抽出し、ステップＳ２１３では、オプション指定の抽出を実行する。上述したように再送要求パケットの指定態様は、シーケンス番号の直接指定のみならず、タイムスタンプ等による指定等、様々であり、データ送信端末装置のＡＲＱ処理部１０５では、受信したＮＡＣＫ−ＲＴＣＰパケットに指定されたオプション指定、およびタイムスタンプ、シーケンス番号を参照して、再送要求パケットを特定する処理を実行する。
【００９３】
ステップＳ２１４では、特定された再送要求パケットをバッファ１０３から抽出する。バッファ１０３には、再送要求に備えて所定時間、送信済みのパケットが保持格納されており、これらの格納パケットから再送指定のあったパケットを抽出する処理を実行する。ステップＳ２１５で、ＲＴＰパケット出力ポートから抽出パケットが送信される。
【００９４】
ステップＳ２０３において、ＮＡＣＫ−ＲＴＣＰパケットを受信しない場合は、ステップＳ２０４でパケット受信応答としてのＡＣＫ−ＲＴＣＰパケットの受信確認を行ない、ＡＣＫ−ＲＴＣＰパケットの受信に基づいて、ステップＳ２０８で、受信の確認されたパケットをバッファ１０３からクリア（削除）する。このＡＣＫにより、再送要求に対応してパケットを保持する送信側のバッファを能動的に早めにクリアすることが可能となり、バッファ溢れの恐れを低下させることが可能となる。
【００９５】
図８にデータ受信端末において生成し、データ送信端末の受信するパケット受信確認応答であるＡＣＫ−ＲＴＣＰパケットの構成を示す。
【００９６】
ＡＣＫ−ＲＴＣＰパケットは、図８に示すようにヘッダ（ＨＥＡＤ）、フォーマット（ＦＯＲＭＡＴ）、パケットタイプ、パケット長、送信同期ソース識別子（ＲＴＣＰ）、タイムスタンプの情報に加えて、受信パケットの識別子としての受信済みシーケンス番号が格納される。
【００９７】
なお、シーケンス番号を指定せず、タイムスタンプ（TIMESTAMP）のみ指定する構成とすることも可能であり、この場合には、そのタイムスタンプ（TIMESTAMP）の設定されたパケットすべてを受け取った事を示す。よってこのような場合にはシーケンス番号をすべて指定する必要はないため、ＡＣＫ−ＲＴＣＰパケットサイズを小さくすることが可能となり、ネットワークトラフィックの増大を低減できる。
【００９８】
図４に戻り、データ送信端末の処理の説明を続ける。データ送信端末は、ステップＳ２０５において、ＥＣＨＯ−ＲＴＣＰパケットの受信確認を行ない、データ受信端末からＥＣＨＯ−ＲＴＣＰパケットを受信した場合は、ステップＳ２０９において、ＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットをＥＣＨＯ−ＲＴＣＰパケットを送信してきたデータ受信端末に対して送信する処理を実行する。
【００９９】
ＥＣＨＯ−ＲＴＣＰパケットと、ＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットは、送信端末と受信端末における往復伝播遅延（ＲＴＴ）をデータ受信端末において把握するために用いるＲＴＣＰパケットである。このパケットの送受信によって、データ受信端末において、再送要求を行なってから再送パケットを受信するまでの時間の把握が可能となり、データ受信端末においてリアルタイム再生を行なうために必要な最終再送要求時間を割り出すことが可能なる。
【０１００】
本発明のシステムでは、受信端末のＡＲＱ判定部において、往復伝播遅延（ＲＴＴ）に基づく最終再送要求時間を判定し、判定に基づいて、再送要求としてのＮＡＣＫ−ＲＴＣＰの送信の実行可否を決定する。この判定処理に必要な送信端末と受信端末における往復伝播遅延（ＲＴＴ）の最新情報を取得するため、データ受信端末側は、任意タイミングで、能動的にＥＣＨＯ−ＲＴＣＰパケットをデータ送信端末に送信し、データ送信端末は、ＥＣＨＯ−ＲＴＣＰパケットの受信に応答してＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットをＥＣＨＯ−ＲＴＣＰパケットを送信してきたデータ受信端末に対して送信する。
【０１０１】
データ受信端末では、データ送信端末からの応答として受信するＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットを解析することによって、送信端末と受信端末における往復伝播遅延（ＲＴＴ）を算出する。このＲＴＴ算出処理については、後段のデータ受信端末の処理の項目で説明する。
【０１０２】
図９にデータ受信端末において生成し、データ送信端末の受信するＥＣＨＯ−ＲＴＣＰパケットの構成、および、データ送信端末において生成し、データ受信端末に対して送信するＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットの構成を示す。
【０１０３】
ＥＣＨＯ−ＲＴＣＰパケットは、図９（ａ）に示すようにヘッダ（ＨＥＡＤ）、フォーマット（ＦＯＲＭＡＴ）、パケットタイプ、パケット長、送信同期ソース識別子（ＲＴＣＰ）、およびＥＣＨＯパケットの識別データとしてのＥＣＨＯ−ＩＤが格納される。ＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットは、図９（ｂ）に示すようにヘッダ（ＨＥＡＤ）、フォーマット（ＦＯＲＭＡＴ）、パケットタイプ、パケット長、送信同期ソース識別子（ＲＴＣＰ）、およびＥＣＨＯ−ＲＴＣＰパケットに対応するＥＣＨＯ−ＩＤ、および、サーバ処理時間が格納される。
【０１０４】
ＥＣＨＯ−ＩＤをＥＣＨＯ−ＲＴＣＰパケットとＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットに入れることにより、データ受信端末側がＥＣＨＯ−ＲＥＰＬＹを受け取った際に、いつ送信したＥＣＨＯ−ＲＴＣＰパケットに対応する返事（ＥＣＨＯ−ＲＥＰＬＹ）かを識別することが可能となる。ＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットに格納されるサーバ処理時間は、データ送信端末がデータ受信端末からの再送要求（ＮＡＣＫ−ＲＴＣＰ）を受信してからパケットをデータ送信端末から出力するまでに要する処理時間に相当する時間である。このサーバ処理時間は、ＥＣＨＯ−ＲＴＣＰパケットを受信した時間からＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットを送信するまでの時間として設定するか、あるいは、予めデータ送信端末において過去の履歴データとして、実際に、データ送信端末がデータ受信端末からの再送要求（ＮＡＣＫ−ＲＴＣＰ）を受信してからパケットをデータ送信端末から出力するまでに要した時間をメモリに格納し、この格納データを適用してもよいし、あるいは、ＥＣＨＯ−ＲＴＣＰパケットを受信した時点におけるサーバ（データ送信端末）における処理負荷を算出して、処理負荷に基づいて算出される予測処理時間をサーバ処理時間として設定する構成としてもよい。
【０１０５】
データ受信端末は、ＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットに格納されたサーバ処理時間と、ＥＣＨＯ−ＲＴＣＰパケット送信からＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰの受信までの時間とに基づいて、送信端末と受信端末における往復伝播遅延（ＲＴＴ）を算出する。このＲＴＴ算出処理については、後段のデータ受信端末の処理の項目で説明する。
【０１０６】
図４に戻り、データ送信端末の処理の説明を続ける。データ送信端末は、ステップＳ２０６において、送信対象となるストリーミングデータのパケット送信がすべて終了したかを判定し、終了と判定した場合は、ステップＳ２１０において、データストリームの終了を明示するＥＯＳ（End Of Stream）メッセージを持つＲＴＣＰパケットを受信側端末へ送信する処理を実行する。
【０１０７】
図１０にデータ送信端末において生成し、データ受信端末の受信するＥＯＳ−ＲＴＣＰパケットの構成を示す。
【０１０８】
ＥＯＳ−ＲＴＣＰパケットは、図１０に示すようにヘッダ（ＨＥＡＤ）、フォーマット（ＦＯＲＭＡＴ）、パケットタイプ、パケット長、送信同期ソース識別子（ＲＴＣＰ）、およびタイムスタンプ（ＴＩＭＥＳＴＡＭＰ）が格納される。データ受信端末は、ＥＯＳ−ＲＴＣＰパケットをデータ送信端末から受信することにより、ストリーミング配信されるデータの終了を認識する。受信端末はこの認識処理により、次フレームが到着しないことによる誤ったＮＡＣＫ送出動作を防ぐことができる。
【０１０９】
図４に戻り、データ送信端末の処理の説明を続ける。データ送信端末は、ステップＳ２０７において、予め設定した時間を計測するタイマーでの計測時間が設定時間を超えたか否かを判定して、タイマーが設定時間を超えていない場合は、ステップＳ２０３以下の処理、すなわち、ステップＳ２０３のパケット再送要求としてのＮＡＣＫ−ＲＴＣＰパケットの受信判定処理以下の処理を継続して実行する。これは、全パケット送出後においても、一定時間は、データ受信側からのパケット再送要求としてのＮＡＣＫ−ＲＴＣＰパケット、または、受信確認応答としてのＡＣＫ−ＲＴＣＰパケット、または、ＥＣＨＯ−ＲＴＣＰパケットを受信する可能性があり、これらのパケット受信に対する処理を実行するためである。タイマーにおいて、予め設定した時間が経過した時点で、データ送信を終了する。
【０１１０】
［データ受信端末における処理］
次に、データ受信端末の処理手順を図１１に示すフローチャートを参照して説明する。図１１に示す処理は、図１の受信側端末１２１において実行される処理を説明したフローである。
【０１１１】
データ受信端末は、ステップＳ３００において、データ送信端末からの送信開始通知を受信後、ステップＳ３０１において、データ送信端末からの送信パケット、すなわち符号化データをペイロードとして格納したＲＴＰパケットを順次、受信する。ＲＴＰパケットは、先に、図２を参照して説明したように、タイムスタンプがヘッダ情報中に格納されている。データ受信端末は、タイムスタンプに基づいて受信するパケットに含まれるフレームを判別することができる。先に説明したように、動画像データをＲＴＰパケットに符号化データとして格納して送信する場合、同一の画像フレームに属する複数のＲＴＰパケットには同一のタイムスタンプが設定され、データ受信側端末は、タイムスタンプを参照して、フレームの判別が可能となる。
【０１１２】
データ受信端末は、ステップＳ３０２において、受信したパケットが、ｎフレーム目（ｎ=１，２...）の終端パケットであるか否かを判定する。また、ステップＳ３０３において、受信したパケットが、ｎ＋１フレーム目の先頭パケットであるか否かを判定する。受信したパケットが、ｎフレーム目（ｎ=１，２...）の終端パケットである場合、または、ｎ＋１フレーム目の先頭パケットである場合には、ステップＳ３０９に進む。
【０１１３】
ステップＳ３０９においては、ｎフレーム内に未受信のパケット、すなわちロストパケット、あるいはエラーパケットがあるか否かを判定する。図５を参照して、ステップＳ３０９におけるエラーパケットまたはロストパケットの検出処理について説明する。
【０１１４】
図５は、送信側と受信側で実際にＲＴＰ、ＲＴＣＰパケットのデータ転送が行われている例である。図の右方向に時間が流れているとする。ここでは、９０ＫＨｚクロックで、動画像データについて、３０ｆｐｓ（フレーム／秒）のレートでサンプリングして符号化データをＲＴＰパケットに格納して送信すると仮定している。この場合、ＲＴＰパケットのタイムスタンプの値は、同一画像フレーム内の場合には同じ値になり、９０Ｋ/３０＝３００００ずつカウントアップされる。受信側は、最小刻みタイマτを実装する。この例では、当画像データの圧縮フォーマットとして、MOTION JPEG2000に従った符号化データを伝送しているものとし、フレームにおける最終端パケットが、データ受信端末のＲＴＰパケット解析部１１４にて検知できる。
【０１１５】
図５において、タイムスタンプ１２０００の設定されたパケットは、パケットのシーケンス番号１〜６であり、これらが同一フレーム、例えばフレームｎに属するパケットである。データ受信端末では、シーケンス番号６のパケットを受信した時点で、ステップＳ３０２の判定がＹｅｓとなり、ステップＳ３０９のロストパケット検出処理を実行することになる。この時点で、データ受信端末は、図５に示すようにシーケンス番号１〜３，６のパケットを受信しており、シーケンス番号４，５のロストパケットがあると判定する。なお、ここでは、ロストパケットについてのみ記載しているが、受信したパケットについてのエラーパケットとして範囲された場合についても、ロストパケットと同様の処理、すなわち再送要求を実行することが可能である。
【０１１６】
ロスとパケットまたはエラーパケットが検出されると、ステップＳ３１２以下の処理に進み、再送要求処理としてのＮＡＣＫ−ＲＴＣＰパケットの送信判定処理、および判定に基づくＮＡＣＫ−ＲＴＣＰパケットの送信処理が実行される。これらの判定処理の詳細については、後述する。ここでは、シーケンス番号４，５のロストパケットに関するＮＡＣＫ−ＲＴＣＰパケットが生成され、先に図６を参照して説明したＮＡＣＫ−ＲＴＣＰパケットの再送指定シーケンス番号として４，５を設定したパケットを再送要求パケットとしてデータ送信端末に対して送信する。図５におけるＮＡＣＫ−ＲＴＣＰパケット送信処理５０１がこれに相当する。
【０１１７】
ＮＡＣＫ−ＲＴＣＰパケット送信の際にタイムスタンプ（TIMESTAMP）とシーケンス番号の組み合わせがはっきりしない場合には、先に図７を参照して説明したオプションを指定して送信する。データ受信端末では、パケットの送受信情報を随時記録することで、パケットロス率の割り出しが可能となる。このロス率が一定値以上になった場合には、ＮＡＣＫ−ＲＴＣＰパケット自体の損失の可能性が考えられるため、おなじＮＡＣＫ−ＲＴＣＰパケットを複数回、重ねて送信する処理を行なうことで、再送成功率を高めることが可能となる。あるいは、ＮＡＣＫ−ＲＴＣＰパケットに重複指定回数を増分して設定する。
【０１１８】
データ送信端末は、ＮＡＣＫ−ＲＴＣＰパケットを受信すると、次のタイムスタンプを設定したフレームデータに併せて、再送パケットを送信する。ここでは、タイムスタンプ：１５０００のフレームデータ（シーケンス番号７〜１２）に併せて再送パケット（シーケンス番号４，５）を送信する。なお、再送タイミングは、このように次のフレームデータになるとは限らず、処理タイミングによっては、さらに次のあるいはさらに遅れたフレームデータとともになる場合もある。これらの再送処理タイミングについては、データ受信端末側がＥＣＨＯ−ＲＴＣＰパケット、およびＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰの送受信を実行することにより、送信端末と受信端末における往復伝播遅延（ＲＴＴ）を算出して推測可能となる。この処理については、後述する。
【０１１９】
図５において、各フレーム、すなわち、タイムスタンプ＝１２０００〜２４０００…において、その最終パケットまたは先頭パケットをデータ受信端末が受信した場合において、図１１のステップＳ３０２またはステップＳ３０３の判定が、Ｙｅｓとなり、ステップＳ３０９のロストパケット検出処理を実行し、ステップＳ３１２以下の処理に進み、再送要求処理としてのＮＡＣＫ−ＲＴＣＰパケットの送信判定処理、および判定に基づくＮＡＣＫ−ＲＴＣＰパケットの送信処理が実行される。
【０１２０】
ステップＳ３１２の再送要求処理としてのＮＡＣＫ−ＲＴＣＰパケットの送信判定処理について説明する。リアルタイム再生処理を実現するためには、再生タイミングに間に合うように、再送要求パケットが受信端末に届くことが必要となる。ステップＳ３１２の再送要求処理としてのＮＡＣＫ−ＲＴＣＰパケットの送信判定処理は、ＮＡＣＫ−ＲＴＣＰパケットを送信した場合、リアルタイム再生処理に間に合うタイミングで、再送パケットが受信可能か否かを判定するものである。
【０１２１】
この判定のためには、前述したように、送信端末と受信端末間における往復伝播遅延（ＲＴＴ）が重要なパラメータとなる。往復伝播遅延（ＲＴＴ）が大きい場合、データ受信端末からデータ送信端末に対して再送要求を出しても、再送要求を発信して、再送パケットがデータ送信端末から再送され、データ受信端末において受信するまでに時間を要すると、その後デコーダに渡して復号を行なってリアルタイム再生に間に合わない場合が発生する。本発明のシステムでは、データ受信端末において、往復伝播遅延（ＲＴＴ）をあらかじめ把握し、往復伝播遅延（ＲＴＴ）に基づいて、ＮＡＣＫ−ＲＴＣＰパケットの送信判定処理を行なう。
【０１２２】
本発明のシステムにおいては、データ受信端末側が、任意タイミングで、往復伝播遅延（ＲＴＴ）の計測を実行することを可能な構成としている。具体的には、データ受信端末から、先に説明した図９に示すＥＣＨＯ−ＲＴＣＰパケットを送信し、ＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットを受信して、ＲＴＴの算出を行なう。
【０１２３】
図１２を参照して、データ受信端末で実行するＥＣＨＯ−ＲＴＣＰパケットの送信、ＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットの受信、往復伝播遅延（ＲＴＴ）の算出処理について説明する。
【０１２４】
図１２（ａ）は、ＥＣＨＯ−ＲＴＣＰパケットの送信処理フローである。ＥＣＨＯ−ＲＴＣＰパケットの送信は、データ受信端末が任意タイミングで能動的に実行することが可能である。
【０１２５】
ステップＳ５０１における、ＲＴＣＰパケットの送信待機状態において、ＲＴＴの計測要請が発生した場合、ステップＳ５０２のＥＣＨＯ−ＲＴＣＰパケットの生成処理に移行する。ＲＴＴの計測は、データ受信が開始された後、例えば図１１の処理フローにおいて、ステップＳ３００の送信開始通知を受信した以降、定期的に実行する等の設定が可能であり、データ受信側端末に保有するタイマーで予め定めた計測間隔が経過したか否かを計測し、予め定めた計測間隔に対応する時間が経過した場合に、ＡＲＱ判定部１１９が、ＥＣＨＯ−ＲＴＣＰパケットの生成要求をパケット作成部１１６に出力し、パケット作成部１１６がステップＳ５０２のＥＣＨＯ−ＲＴＣＰパケットの生成処理を実行するなどの設定が可能である。この他にも、パケットのロスト状況を解析し、ロスト状況に応じてＥＣＨＯ−ＲＴＣＰパケットの生成、送信を実行する構成としてもよく、いずれにしても、データ受信端末は、任意タイミングで、ＥＣＨＯ−ＲＴＣＰパケットの生成、送信が可能であり、常に最新の往復伝播遅延（ＲＴＴ）の算出が可能となる。
【０１２６】
ステップＳ５０２で生成するＥＣＨＯ−ＲＴＣＰパケットは、先に図９（ａ）を参照して説明した構成を有する。パケットには、各パケット固有の識別子としてのＥＣＨＯ−ＩＤが設定される。ステップＳ５０３で、生成したＥＣＨＯ−ＲＴＣＰパケットが、ＲＴＣＰ入出力ポート１１３を介して、データ送信端末１０４に対して送信される。ステップＳ５０４では、ＥＣＨＯ−ＲＴＣＰパケットを送信した送信時間、および、パケットに設定されたＥＣＨＯ−ＩＤがメモリに記録される。
【０１２７】
図１２（ｂ）は、ＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットの受信およびＲＴＴ算出処理フローである。ステップＳ６０１における、ＲＴＣＰパケットの送信待機状態において、ＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットが受信されたと判定（ステップＳ６０２でＹｅｓ）されると、ステップＳ６０３において、ＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットの受信時刻がメモリに記録される。受信するＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットは、先に図９（ｂ）を参照して説明した構成を有する。パケットには、応答対象となった対応するＥＣＨＯ−ＲＴＣＰパケットと同一の識別子としてのＥＣＨＯ−ＩＤが設定され、さらに、データ送信端末において算出したサーバ処理時間が格納される。
【０１２８】
ステップＳ６０４では、受信したＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットからサーバ処理時間が抽出され、ステップＳ６０５において、受信したＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットに設定されたＥＣＨＯ−ＩＤから対応するＥＣＨＯ−ＲＴＣＰパケットの送信時間が検索される。
【０１２９】
ステップＳ６０６では、ステップＳ６０３において取得したＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットの受信時刻、ステップＳ６０４において取得したサーバ処理時間、ステップＳ６０３において取得したＥＣＨＯ−ＲＴＣＰパケットの送信時間に基づいて、往復伝播遅延（ＲＴＴ）の算出処理が実行される。往復伝播遅延（ＲＴＴ）の算出は、下式に基づいて実行される。
往復伝播遅延（ＲＴＴ）＝(ECHO-REPLAY受信時刻)-(ECHO送信時刻)-(サーバ処理時間)
【０１３０】
なお、ＲＴＴの計測を実行する際に送受信するＥＣＨＯ，ＥＣＨＯ−ＲＥＰＬＹパケットも損失することが考えられる。またＲＴＴもネットワークの状況により常に変動するため、データ受信端末は一定間隔でＥＣＨＯ，ＥＣＨＯ−ＲＥＰＬＹパケットの送受信処理を実行してＲＴＴを計測する。
【０１３１】
図１１のフローに戻り、データ受信端末側の処理について説明を続ける。図１１のフローにおいて、ステップＳ３１２では、再送要求としてのＮＡＣＫ−ＲＴＣＰを出力した場合、リアルタイム再生処理に間に合うタイミングで再送要求パケットの受信が可能か否かを判定する。上述したＥＣＨＯ，ＥＣＨＯ−ＲＥＰＬＹパケットの送受信処理により計測されたＲＴＴ値と、各フレームの処理タイミングを計測しているタイマーの期限に基づいて、再送要求としてのＮＡＣＫ−ＲＴＣＰパケットを出しても間に合わないと判断した場合（Ｓ３１２でＮｏ）には、ＮＡＣＫ−ＲＴＣＰパケットの送信処理は実行しない。
【０１３２】
たとえば、パケット損失の存在する該当フレームの符号化データの処理開始までの時間Ｔａ＝１００ｍｍｓｅｃである場合、すなわち１００ｍｍｓｅｃ後にデコーダにデータを渡して復号処理が開始されることがタイマーの計測により明らかとなっている場合、計測された最新のＲＴＴ値が、該当フレームの符号化データの処理開始までの時間Ｔａより大きい値であった場合、すなわち、１００ｍｍｓｅｃ以上であった場合には、再送要求としてのＮＡＣＫ−ＲＴＣＰパケットを送信しても、再送パケットの受信が、デコード処理開始タイミングに間に合わないものと判断して、ＮＡＣＫ−ＲＴＣＰパケットの送信処理を実行しない。ただし、ＲＴＴ値が処理開始までの時間Ｔａ以上であっても、ＲＴＴ値と時間：Ｔａの非常に近い値を持つ場合には、ぎりぎり間に合う可能性もあるためＮＡＣＫを送出する構成としてもよい。このＮＡＣＫ送出判定の閾値は実装依存である。
【０１３３】
一方、計測された最新のＲＴＴ値が、パケット損失の存在する該当フレームの符号化データの処理開始までの時間Ｔａ以下であった場合には、再送要求としてのＮＡＣＫ−ＲＴＣＰパケットを送信して再送パケットを受信するまでの時間が、デコード処理開始タイミングまでの時間以下であるので、再送パケット受信が処理に間に合うものと判断して、ステップＳ３１３において、ＮＡＣＫ−ＲＴＣＰパケットの送信処理を実行する。
【０１３４】
ステップＳ３０９のロストパケットの検出処理は、ステップＳ３０２の各フレームの終端パケット受信、ステップＳ３０３の各フレームの先頭パケット受信時のみではなく、ステップＳ３０４の各フレームの最終再送時間の判定でＹｅｓの場合、およびステップＳ３０５のタイマーの最小計測時間τの経過判定でＹｅｓの場合に実行される。
【０１３５】
図５を参照して、ステップＳ３０４の各フレームの最終再送時間の判定処理、およびステップＳ３０５のタイマーの最小計測時間τの経過判定処理について説明する。
【０１３６】
ステップＳ３０４の各フレームの最終再送時間の判定処理は、再送要求としてのＮＡＣＫ−ＲＴＣＰを出力した場合、リアルタイム再生処理に間に合う最終時間判定処理である。各フレームについて、各フレームの符号化データの処理開始までの時間Ｔａが計測されているＲＴＴ値と等しくなったとき、すなわち、Ｔａ＝ＲＴＴとなった場合に、ステップＳ３０４の判定がＹｅｓとなり、ステップＳ３０９の該当フレームに対するロストパケットの検出処理が実行される。これは、最後の再送要求可能タイミングにロストパケットを検出して、検出された場合に最後の再送要求を送信するための処理である。
【０１３７】
図５において、右下部に示してあるように、タイムスタンプ＝１２０００の処理開始までの時間Ｔａ＝ＲＴＴとなったとき、ステップＳ３０４において、タイムスタンプ＝１２０００に対応するフレームについての最終再送時間の判定処理がＹｅｓと判定され、ステップＳ３０９において、タイムスタンプ＝１２０００のフレームに対するロストパケットの検出処理が実行され、ロストパケットが検出された場合に、ステップＳ３１３において最後の再送要求を送信する。図５におけるＮＡＣＫ−ＲＴＣＰパケット送信処理５０５がこれに相当する。
【０１３８】
ステップＳ３０５のタイマーの最小計測時間τの経過判定処理は、データ受信端末の有するタイマーの計測最小時間：τ毎に、ステップＳ３０５の判定がＹｅｓとなり、ステップＳ３０９の該当フレームに対するロストパケットの検出処理が実行される。これは、各計測最小時間：τに対応する受信フレームについて、各フレームの先頭パケット、最終パケットの検出がなされない場合でもロストパケットを確実に検出して、再送要求を実行しようとするための処理である。図５におけるＮＡＣＫ−ＲＴＣＰパケット送信処理５０２，５０３がこれに相当する。
【０１３９】
図５におけるＮＡＣＫ−ＲＴＣＰパケット送信処理５０２は、そのタイミングまでに受信済みのタイムスタンプのフレームを構成するパケット中のロストパケットとして、パケット（シーケンス番号＝５，１２）を抽出し、シーケンス番号５，１２のロストパケットに関するＮＡＣＫ−ＲＴＣＰパケットが生成され、先に図６を参照して説明したＮＡＣＫ−ＲＴＣＰパケットの再送指定シーケンス番号として５，１２を設定したパケットを再送要求パケットとしてデータ送信端末に対して送信する。なお、シーケンス番号５の再送要求は、２回目となるので、ＮＡＣＫ−ＲＴＣＰパケットのシーケンス番号５に対応する「再送回数」フィールドには、［２］が設定される。
【０１４０】
図５におけるＮＡＣＫ−ＲＴＣＰパケット送信処理５０３は、そのタイミングまでに受信済みのタイムスタンプのフレームを構成するパケット中のロストパケットとして、パケット（シーケンス番号＝５）を抽出し、シーケンス番号５のロストパケットに関するＮＡＣＫ−ＲＴＣＰパケットを生成して送信する。なお、シーケンス番号５の再送要求は、３回目となるので、ＮＡＣＫ−ＲＴＣＰパケットのシーケンス番号５に対応する「再送回数」フィールドには、［３］が設定される。
【０１４１】
このように、データ受信端末では、ステップＳ３０２の各フレームの終端パケット受信、ステップＳ３０３の各フレームの先頭パケット受信時、ステップＳ３０４の各フレームの最終再送時間の判定、およびステップＳ３０５のタイマーの最小計測時間τの経過判定の各タイミングにおいて、ステップＳ３０９のロストパケットの検出処理を実行する。なお、これらステップＳ３０２〜Ｓ３０５の４種類のタイミングのいずれかのみを実行する構成としてもよい。
【０１４２】
ステップＳ３０９の各フレームのロストパケット検出処理において、ロストパケットが検出されなかった場合は、各パケットに格納された符号化データのデコード（復号）処理がデコーダ１２０において実行される。ステップＳ３１１では、受信済みパケットについての受信確認パケットとしてのＡＣＫ−ＲＴＣＰパケットの生成、送信が行われる。ＡＣＫ−ＲＴＣＰパケットは、先に図８を参照して説明した通り、受信済みシーケンス番号を格納したパケットである。このＡＣＫ−ＲＴＣＰパケットを受信したデータ送信端末は、ＡＣＫ−ＲＴＣＰパケットに記録された受信済みシーケンス番号に対応するパケットをバッファ１０３からクリアする。
【０１４３】
図５のタイムシーケンス図では、受信端末から送信端末へのＡＣＫ−ＲＴＣＰパケットの送信は、タイムスタンプ＝１５０００のフレームデータに関しては、ＡＣＫ−ＲＴＣＰパケット送信処理５１１において実行され、タイムスタンプ＝１８０００のフレームデータに関しては、ＡＣＫ−ＲＴＣＰパケット送信処理５１２において実行され、タイムスタンプ＝２１０００のフレームデータに関しては、ＡＣＫ−ＲＴＣＰパケット送信処理５１３において実行されている。
【０１４４】
図１１に示すフローのステップＳ３０６では、各フレームのタイマー期限切れを確認する。このタイマー期限は、リアルタイム再生処理の開始期限を計測するタイマーによって設定される期限であり、各フレーム毎にそのタイミングが設定される。ｎフレームのタイマー期限切れであると判定された場合には、ロストパケットがあった場合であっても、ステップＳ３１０のデコード処理に移行することになる。
【０１４５】
ステップＳ３０７では、データ送信端末から、データストリームの終了を明示するＥＯＳ（End Of Stream）メッセージを持つＲＴＣＰパケットを受信したか否かを判定し、ＥＯＳ−ＲＴＣＰパケット受信でない場合は、ステップＳ３０１以下の処理を繰り返す。
【０１４６】
ＥＯＳ−ＲＴＣＰパケット受信である場合は、ステップＳ３０８において、各フレームのタイマー期限切れを確認する。このタイマー期限は、リアルタイム再生処理の開始期限を計測するタイマーによって設定される期限であり、各フレーム毎にそのタイミングが設定される。タイマー期限切れでない場合は、ステップＳ３１４に進み、再送要求されているロストパケットに関する再送パケットを受信待機状態であるか否かを判定して、待機状態である場合は、ステップＳ３１５に進み、再送パケットの受信待機状態として、ステップＳ３０１のパケット受信以下の処理を実行する。
【０１４７】
ステップＳ３０８における各フレームのタイマー期限切れの確認処理において、Ｙｅｓと判定された場合、および、ステップＳ３１４において、再送パケット受信待機状態でないと判定された場合は、デコード、再生処理へ移行すべき未受信のパケットデータは存在しないと判定され、受信処理を完了する。
【０１４８】
このように、本発明のシステムにおいては、リアルタイム配信に適するものの信頼性を保証しないＲＴＰ等のデータ通信プロトコルに従ったパケット伝送において、ＡＲＱ機能を付加することで、エラー耐性のある信頼性の高いデータ伝送、リアルタイム再生が可能となる。なお、上述の実施例では、ＲＴＰパケットに符号化データを格納する構成例を中心として説明したが、ＲＴＰパケットフォーマットに限らず、ＵＤＰ等、他のデータ通信プロトコルフォーマットに従ったパケットを用いたデータ通信構成においても、上述の実施例と同様の各種のコントロールパケットを用いた再送要求処理を行なうことにより、上述の実施例と同様の構成を実現可能である。
【０１４９】
上述したように本発明の構成では、再送要求の処理タイミングとして、各フレームの先頭パケットの受信時、各フレームの最終パケットの受信時、最終処理期限、および一定間隔（τ）毎等の各種タイミングでロストパケットの検出処理を実行する構成としたので、確実なロストパケットの検出が可能となる。
【０１５０】
また、データ受信端末は、再生処理時間、伝播遅延時間ＲＴＴを考慮したデータ再送要求処理を実行するので、無駄な再送要求パケットおよび再送パケットを出すことを防ぐ事ができ、ネットワークの帯域を再送によって狭めることがない。また、データ受信端末が、パケットの送受信情報を随時記録し、パケットロス率の割り出しにより、ロス率が一定値以上になった場合、おなじＮＡＣＫ−ＲＴＣＰパケットを複数回、重ねて送信することで、再送成功率を高めることが可能となる。
【０１５１】
また、受信端末において送信する再送要求としてのＮＡＣＫ−ＲＴＣＰパケットに重複指定回数の設定を可能としたので、ネットワーク状況に応じて、また受信側の要求に応じて再送パケットの重複送信を要求することが可能となり、重要データの受信成功率を高めることが可能となる。例えば、再生に間に合うための最終的な再送パケットについて重複再送を要求することで、高品質なデータ再生が可能となる。
【０１５２】
また、データ受信端末側から受信パケットに関するＡＣＫメッセージを、例えば画像のフレーム毎、またはあるブロック毎に応じて送信側に送信する構成としたので、パケット毎のＡＣＫ送信による帯域の寡占状態の発生が防止され、また、データ送信側は、データ受信側から受信するＡＣＫパケットに基づいて、再送処理のためのパケット格納バッファから、該当パケットを能動的に破棄でき、バッファ溢れ、バッファ欠如を防ぐことができる。
【０１５３】
［データ送受信端末装置構成例］
上述の実施例で述べた一連の処理は、ハードウェア、またはソフトウェア、あるいは両者の複合構成によって実行することが可能である。ソフトウェアによる処理を実行する場合は、処理シーケンスを記録したプログラムを、専用のハードウェアに組み込まれたデータ処理装置内のメモリにインストールして実行させるか、あるいは、各種処理が実行可能な汎用コンピュータにプログラムをインストールして実行させることが可能である。一連の処理をソフトウェアによって行う場合には、そのソフトウェアを構成するプログラムが、例えば汎用のコンピュータやマイクロコンピュータ等にインストールされる。
【０１５４】
図１３に、上述の実施例で述べた一連の処理を実行するデータ送信端末装置、データ受信端末装置のシステム構成例を示す。本発明のシステムで送受信されるデータは、符号化データであり、データ送信装置ではエンコード（符号化）処理が実行され、データ受信装置ではデコード（復号）処理が実行される。符号化されたデータはパケットとしてネットワークを介して送受信する。そのため、データ送信側では、パケット生成（パケタイズ処理）を実行し、データ受信側ではパケット展開（デパケタイズ処理）を実行する。
【０１５５】
図１３に示すデータ送受信装置（ｅｘ．ＰＣ）８５０は、エンコード（符号化）処理、デコード（復号）処理を実行するとともにパケット生成、展開処理を実行するコーデック８５１、通信ネットワークとのインタフェースとして機能するネットワークインタフェース８５２、マウス８３７、キーボード８３６等の入力機器との入出力インタフェース８５３、ビデオカメラ８３３、マイク８３４、スピーカ８３５等のＡＶデータ入出力機器からのデータ入出力を行なうＡＶインタフェース８５４、ディスプレイ８３２に対するデータ出力インタフェースとしてのディスプレイ・インタフェース８５５、各データ入出力インタフェース、コーデック８５１、ネットワークインタフェース８５２間のデータ転送制御、その他各種プログラム制御を実行するＣＰＵ８５６、ＣＰＵ８５６により制御実行される各種プログラムの格納、データの格納、ＣＰＵ８５６のワークエリアとして機能するＲＡＭ、ＲＯＭからなるメモリ８５７、データ格納、プログラム格納用の記憶媒体としてのＨＤＤ８５８を有し、それぞれＰＣＩバス８５９に接続され、相互のデータ送受信が可能な構成を持つ。
【０１５６】
コーデック８５１は、図１３に示すように、例えばビデオカメラ８３３からの画像データ、マイク８３４からの音声データを入力し、符号化処理、パケット生成処理（パケタイズ）を実行し、最終的に符号化データをペイロードとしたパケットを生成する。生成されたパケットは、ＰＣＩバス８５９上に出力され、ネットワークインタフェース８５２を介してネットワークに出力され、パケットのヘッダに設定された宛先アドレスに配信される。
【０１５７】
また、ＨＤＤ８５８またはメモリ８５７に格納されたソフトウェアエンコードプログラムに従ってＣＰＵ８５６の制御により、ビデオカメラ８３３からの画像データ、マイク８３４からの音声データを符号化してネットワークインタフェース８５２を介してネットワークに出力する処理も実行する構成としてもよい。
【０１５８】
一方、ネットワークを介して入力するＩＰパケット化されたデータは、ネットワークインタフェース８５２を介して、バス８５６上に出力されて、コーデック８５１に入力される。コーデック８５１では入力データのパケット展開処理（デパケタイズ）を実行し、ペイロードとして格納された符号化データを抽出後、復号処理を実行して、ディスプレイ８３２、スピーカ８３５において再生、出力する。
【０１５９】
上述の実施例における処理対象となる画像等のデータは、カメラ他の入力機器、例えばスキャナ等のデータ入力装置、あるいはフロッピーディスク、ＣＤ−ＲＯＭ(Compact Disc Read Only Memory)，ＭＯ(Magneto optical)ディスク，ＤＶＤ(Digital Versatile Disc)、磁気ディスク、半導体メモリなどのリムーバブル記録媒体から入力可能である。
【０１６０】
また、ＣＰＵ８５６は、ＲＯＭ格納プログラムに限らず、ハードディスクに格納されているプログラム、衛星若しくはネットワークから転送され、受信されてインストールされたプログラム等を、ＲＡＭ(Random Access Memory)等のメモリにロードして実行することも可能である。
【０１６１】
ここで、本明細書において、プログラムは、１つのコンピュータにより処理されるものであっても良いし、複数のコンピュータによって分散処理されるものであっても良い。さらに、プログラムは、遠方のコンピュータに転送されて実行されるものであっても良い。
【０１６２】
以上、特定の実施例を参照しながら、本発明について詳解してきた。しかしながら、本発明の要旨を逸脱しない範囲で当業者が該実施例の修正や代用を成し得ることは自明である。すなわち、例示という形態で本発明を開示してきたのであり、限定的に解釈されるべきではない。本発明の要旨を判断するためには、冒頭に記載した特許請求の範囲の欄を参酌すべきである。
【０１６３】
【発明の効果】
以上、説明してきたように、本発明の構成によれば、ＲＴＰ、ＵＤＰ等のデータ通信プロトコルに従ったパケット送信において、ＡＲＱ機能を付加し、再送要求の処理タイミングとして、各フレームの先頭パケットの受信時、各フレームの最終パケットの受信時、最終処理期限、および一定間隔（τ）毎等の各種タイミングでロストパケットの検出処理を実行し、再送要求を実行する構成としたので、確実なロストパケットの検出が可能となり、エラー耐性のある信頼性の高いデータ伝送、リアルタイム再生が可能となる。
【０１６４】
また、本発明の構成によれば、データ受信端末において、再生処理時間、伝播遅延時間ＲＴＴを考慮し、デコード処理等を含む再生処理に間に合わない場合には、再生要求パケットの送信を実行しない構成としたので、無駄な再送要求パケットおよび再送パケットを出すことを防ぐ事ができ、ネットワークの帯域を再送処理の多発によって狭めてしまうことを防止することが可能となる。
【０１６５】
また、本発明の構成において、データ受信端末でパケットの送受信情報を随時記録しパケットロス率の割り出しを可能とした構成においては、データ受信端末の検出したロス率が一定値以上になった場合に、データ受信端末が能動的におなじＮＡＣＫパケットを複数回、重ねて送信する処理を行なうことで、再送成功率を高めることが可能となる。
【０１６６】
また、本発明の構成において、受信端末において送信する再送要求としてのＮＡＣＫパケットに重複指定回数の設定を可能としたため、ネットワーク状況に応じて、また受信側の要求に応じて再送パケットの重複送信を要求することが可能となり、重要データの受信成功率を高めることが可能となる。特に、再生時間に間に合うための最終的な再送パケットにおいては、そのパケットが万が一損失した場合には、データ不完全のまま再生することになるため、受信側から重複再送を要求し、再送成功率を高めることで高品質なデータ再生が可能となる。
【０１６７】
また、本発明の構成において、データ受信端末側から受信パケットに関するＡＣＫメッセージを、画像のフレーム毎、ブロック毎等、パケット単位ではなく複数パケット毎に送信する構成とすることで、ＡＣＫパケットによる帯域の寡占状態の発生を防止し、また、データ送信側では、データ受信側から受信するＡＣＫパケットに基づいて、再送処理のためのパケット格納バッファから、該当パケットを能動的に破棄でき、バッファ溢れ、バッファ欠如を防ぐことが可能となる。
【図面の簡単な説明】
【図１】本発明のデータ通信システムの構成を示す図である。
【図２】本発明のデータ通信システムにおいて転送されるＲＴＰパケットフォーマットを示す図である。
【図３】本発明のデータ通信システムにおいて転送されるＩＰパケットヘッダフォーマットを示す図である。
【図４】本発明のデータ通信システムにおけるデータ送信端末の処理フローを示す図である。
【図５】本発明のデータ通信システムにおけるデータ送信端末およびデータ受信端末のデータ通信処理を説明するタイムシーケンス図である。
【図６】本発明のデータ通信システムにおいて転送されるＮＡＣＫ−ＲＴＣＰパケットフォーマットを示す図である。
【図７】本発明のデータ通信システムにおいて転送されるＮＡＣＫ−ＲＴＣＰパケットにおけるオプション値の機能について説明する図である。
【図８】本発明のデータ通信システムにおいて転送されるＡＣＫ−ＲＴＣＰパケットフォーマットを示す図である。
【図９】本発明のデータ通信システムにおいて転送されるＥＣＨＯ−ＲＴＣＰ、およびＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットフォーマットを示す図である。
【図１０】本発明のデータ通信システムにおいて転送されるＥＯＳ−ＲＴＣＰパケットフォーマットを示す図である。
【図１１】本発明のデータ通信システムにおけるデータ受信端末の処理フローを示す図である。
【図１２】本発明のデータ通信システムにおけるデータ受信端末のＥＣＨＯ−ＲＴＣＰ、およびＥＣＨＯ−ＲＥＰＬＹ−ＲＴＣＰパケットを適用したＲＴＴ計測処理フローを示す図である。
【図１３】データ送信端末装置およびデータ受信端末装置のシステム構成例を示す図である。
【符号の説明】
１０１  ビデオカメラ
１０２  エンコーダ
１０３  バッファ
１０４  送信側端末
１０５  ＡＲＱ処理部
１０６  ＲＴＰパケット作成部
１０７  ＲＴＣＰパケット作成部
１０８  ＲＴＣＰパケット解析部
１０９  ＲＴＣＰ入出力ポート
１１０  ＲＴＰパケット出力ポート
１１１  ＩＰネットワーク
１１２  ＲＴＰパケット入力ポート
１１３  ＲＴＣＰ入出力ポート
１１４  ＲＴＰパケット解析部
１１５  ＲＴＣＰパケット解析部
１１６  ＲＴＣＰパケット作成部
１１６  ＡＲＱ判定部
１１７  バッファ
１１８  インデックスリスト
１１９  ＡＲＱ判定部
１２０  デコーダ
８０９  ＰＣＩバス
８３２  ディスプレイ
８３３  ビデオカメラ
８３４  マイク
８３５  スピーカ
８３７  マウス
８３８  キーボード
８５０  データ送受信装置
８５１  コーデック
８５２  ネットワークインタフェース
８５３  入出力インタフェース
８５４  ＡＶインタフェース
８５５  ディスプレイインタフェース
８５６  ＣＰＵ
８５７  メモリ
８５８  ＨＤＤ
【図１】
0003912091.tif 000002
【図２】
0003912091.tif 000003
【図３】
0003912091.tif 000004
【図４】
0003912091.tif 000005
【図５】
0003912091.tif 000006
【図６】
0003912091.tif 000007
【図７】
0003912091.tif 000008
【図８】
0003912091.tif 000009
【図９】
0003912091.tif 000010
【図１０】
0003912091.tif 000011
【図１１】
0003912091.tif 000012
【図１２】
0003912091.tif 000013
【図１３】
0003912091.tif 000014