(57)【特許請求の範囲】
【請求項１】
第１の情報処理装置からネットワークを介して、パケットを単位としたプロトコルでデータを第２の情報処理装置に送信する情報処理システムにおいて、
前記第１の情報処理装置は、前記第２の情報処理装置からの受信レポートを受信し、前記受信レポートから前記受信レポートのシーケンス番号を取得し、取得された前記シーケンス番号に基づいて、前記受信レポートの損失率を計算し、計算された前記受信レポートの損失率に基づいて前記データの送信エラーの訂正を制御するとともに、前記受信レポートの損失率を送信レポートに付加して前記第２の情報処理装置に送信し、
前記第２の情報処理装置は、前記第１の情報処理装置からの前記データを受信し、前記データから損失パケットを特定する情報を取得し、前記第１の情報処理装置からの前記送信レポートに含まれる前記受信レポートの損失率に基づいて、前記第１の情報処理装置に対する前記損失パケットの再送要求を制御する
ことを特徴とする情報処理システム。
【請求項２】
第１の情報処理装置からネットワークを介して、パケットを単位としたプロトコルでデータを第２の情報処理装置に送信する情報処理システムの情報処理方法において、
前記第１の情報処理装置の情報処理方法は、前記第２の情報処理装置からの受信レポートを受信し、前記受信レポートから前記受信レポートのシーケンス番号を取得し、取得された前記シーケンス番号に基づいて、前記受信レポートの損失率を計算し、計算された前記受信レポートの損失率に基づいて前記データの送信エラーの訂正を制御するとともに、前記受信レポートの損失率を送信レポートに付加して前記第２の情報処理装置に送信し、
前記第２の情報処理装置の情報処理方法は、前記第１の情報処理装置からの前記データを受信し、前記データから損失パケットを特定する情報を取得し、前記第１の情報処理装置からの前記送信レポートに含まれる前記受信レポートの損失率に基づいて、前記第１の情報処理装置に対する前記損失パケットの再送要求を制御する
ことを特徴とする情報処理方法。
【請求項３】
ネットワークを介して他の情報処理装置に、パケットを単位としたプロトコルでデータを送信する情報処理装置において、
前記他の情報処理装置より送信された受信レポートから前記受信レポートのシーケンス番号を取得する取得手段と、
前記取得手段により取得された前記シーケンス番号に基づいて、前記受信レポートの損失率を計算する計算手段と、
前記計算手段により計算された前記受信レポートの損失率に基づいて、前記データの送信エラーの訂正を制御する制御手段と、
前記計算手段により計算された前記受信レポートの損失率を送信レポートに付加して前記他の情報処理装置に送信する送信手段と
を備えることを特徴とする情報処理装置。
【請求項４】
前記パケットを単位としたプロトコルは、ＲＴＰおよびＲＴＣＰである
ことを特徴とする請求項３に記載の情報処理装置。
【請求項５】
前記制御手段は、
前記計算手段により計算された前記受信レポートの損失率が第１の基準値よりも大きいか否かを判断する第１の判断手段と、
前記第１の判断手段による判断結果に基づいて、前記データの前記送信エラーの訂正方法を設定する設定手段と
を備えることを特徴とする請求項３に記載の情報処理装置。
【請求項６】
前記制御手段に、前記第１の判断手段により前記受信レポートの損失率が前記第１の基準値よりも小さいと判断された場合、前記受信レポートの損失率が第２の基準値よりも大きいか否かを判断する第２の判断手段をさらに備え、
前記設定手段は、前記第２の判断手段により前記受信レポートの損失率が前記第２の基準値よりも小さいと判断された場合、前記データの前記送信エラーの訂正を禁止する
ことを特徴とする請求項５に記載の情報処理装置。
【請求項７】
前記設定手段は、前記第１の判断手段により前記受信レポートの損失率が前記第１の基準値よりも大きいと判断された場合、前記データの前記送信エラーの訂正方法をＦＥＣに設定し、前記第１の判断手段により前記受信レポートの損失率が前記第１の基準値よりも小さいと判断され、かつ、前記第２の判断手段により前記受信レポートの損失率が前記第２の基準値よりも大きいと判断された場合、前記データの前記送信エラーの訂正方法をＡＲＱに設定する
ことを特徴とする請求項６に記載の情報処理装置。
【請求項８】
ネットワークを介して他の情報処理装置に、パケットを単位としたプロトコルでデータを送信する情報処理装置の情報処理方法において、
前記他の情報処理装置より送信された受信レポートから前記受信レポートのシーケンス番号を取得する取得ステップと、
前記取得ステップの処理により取得された前記シーケンス番号に基づいて、前記受信レポートの損失率を計算する計算ステップと、
前記計算ステップの処理により計算された前記受信レポートの損失率に基づいて、前記データの送信エラーの訂正を制御する制御ステップと、
前記計算ステップの処理により計算された前記受信レポートの損失率を送信レポートに付加して前記他の情報処理装置に送信する送信ステップと
を含むことを特徴とする情報処理方法。
【請求項９】
ネットワークを介して他の情報処理装置に、パケットを単位としたプロトコルでデータを送信する処理をコンピュータに行わせるプログラムであって、
前記他の情報処理装置より送信された受信レポートから前記受信レポートのシーケンス番号を取得する取得ステップと、
前記取得ステップの処理により取得された前記シーケンス番号に基づいて、前記受信レポートの損失率を計算する計算ステップと、
前記計算ステップの処理により計算された前記受信レポートの損失率に基づいて、前記データの送信の訂正を制御する制御ステップと、
前記計算ステップの処理により計算された前記受信レポートの損失率を送信レポートに付加して前記他の情報処理装置に送信する送信ステップと
を含むことを特徴とするコンピュータが読み取り可能なプログラムが記録されている記録媒体。
【請求項１０】
ネットワークを介して他の情報処理装置に、パケットを単位としたプロトコルでデータを送信する処理を制御するコンピュータが実行可能なプログラムであって、
前記他の情報処理装置より送信された受信レポートから前記受信レポートのシーケンス番号を取得する取得ステップと、
前記取得ステップの処理により取得された前記シーケンス番号に基づいて、前記受信レポートの損失率を計算する計算ステップと、
前記計算ステップにより計算された前記受信レポートの損失率に基づいて、前記データの送信の訂正を制御する制御ステップと、
前記計算ステップの処理により計算された前記受信レポートの損失率を送信レポートに付加して前記他の情報処理装置に送信する送信ステップと
を含むことを特徴とするプログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、情報処理システムおよび方法、情報処理装置および方法、記録媒体、並びにプログラムに関し、特に、双方向のネットワーク状況を把握できるようにした情報処理システムおよび方法、情報処理装置および方法、記録媒体、並びにプログラムに関する。
【０００２】
【従来の技術】
近年、インターネット上のデータ伝送サービスにおいて、従来から利用されているダウンロード型の伝送方式に加えて、ストリーム型の伝送方式によるサービスが増加している。ダウンロード型の伝送方式においては、送信側のサーバから映像データまたは音声データが、一旦、受信側の端末にダウンロードされ、その後、再生される。すなわち、ダウンロード型の伝送方式は、データが完全にダウンロードされるまでは再生できないため、映像データの長時間再生やリアルタイム再生には不向きである。
【０００３】
一方、ストリーム型の伝送方式では、送信側のサーバから受信側の端末にデータ転送が行われている間に、すでに受信されているデータが再生されるため、インターネット電話、遠隔テレビ会議、または、ビデオオンデマンドといったインターネットサービスに利用されている。
【０００４】
このようなストリーム型の伝送方式に適したインターネット技術に、IETF(Internet Engineering Task Force)  RFC(Request For Comments)1889で規定されているＲＴＰ(Real-time Transport Protocol)がある。
【０００５】
図１は、ＲＴＰパケットのＲＴＰヘッダの構成例を示す図である。図１の例において、ＲＴＰのバージョンを示すバージョン番号、パケットのサイズを調整するビットであるパディング、機能拡張時に指定される拡張ビット、リアルタイム転送に関わる送信元の数を示すカウンタ、データの境界を示すマーカービット、符号化の種類を示すペイロードタイプ、ＲＴＰパケットの順番を示すシーケンス番号、ＲＴＰパケットが送信された時刻を示すタイムスタンプ、メッセージの最初の送信元を識別する同期ソース識別子、および、メッセージに含まれるパケット群への準備を行った送信元を識別する貢献ソース識別子が順に配置されている。
【０００６】
ＲＴＰによるデータ転送においては、このタイムスタンプが付加されることにより、送信側と受信側の時間的関係が把握されるので、パケット転送の遅延ゆらぎ（ジッタ）等の影響が抑制され、同期をとってデータ再生が可能になる。
【０００７】
また、ＲＴＰは、実時間のデータ転送の保障、パケット配送の優先度の設定または管理などができないため、ＲＴＰパケットには、他のパケットと同様に、配送遅延、または、パケット損失等の問題が生じる恐れがある。このような問題が生じた場合でも、映像データまたは音声データは、多少のデータ破損があったとしてもある程度再生可能であるため、受信側の端末においては、定められた時間内に受信したパケットのみを利用して再生することができる。
【０００８】
しかしながら、遅延配送されたパケット、または、エラーの発生したパケットは、受信側の端末においてそのまま破棄されるため、送信側のサーバが高品質なデータを配信しても、受信側の端末において十分に高品位なデータが再生されない場合がある。特に、有線区間において、１０-5、または、無線区間で１０-3以上のエラーがある場合には、ＲＴＰをそのまま利用するだけでは、信頼性が低い。
【０００９】
このような問題に対応するため、ＲＴＰパケットのシーケンス番号を利用して、損失したパケットを検出し、送信側のサーバに再送要求を行うことにより、品質の高い転送を行うエラー訂正方式である、自動再送要求（ＡＲＱ：Automatic Repeat request）が実装されるようになってきた。この送信側のサーバへの再送要求は、ＲＴＣＰ、ＲＴＰまたはＴＣＰ等のプロトコルにより行われる。
【００１０】
また、上述したように、ＲＴＰは、実時間データを転送するプロトコルであって、通信状況を伝えたり、制御する機能を有しないため、ＲＴＰが単体で用いられた場合、ネットワークの状況に対応した輻輳制御、または、受信側の端末の能力に対応したデータ転送を行うことができない。そこで、ＲＴＰの情報を交換するための通信プロトコルＲＴＣＰ（Real Time Control Protocol）が用いられる。
【００１１】
このＲＴＣＰにおいては、一定の時間間隔で、受信側の端末より受信レポート（ＲＲ：Receiver Report）が送信側のサーバに送信され、送信側のサーバより送信レポート（ＳＲ：Sender Report）が受信側の端末に送信される。これにより、送信側のサーバおよび受信側の端末間において、ネットワークの状況、または、受信側の端末の状況に対応した動的なデータ転送を行うことができる。すなわち、ＲＴＣＰは、常にＲＴＰとペアで用いられ、ＲＴＰにない機能を補助するプロトコルである。
【００１２】
図２は、ＲＴＣＰの受信レポートの構成例を示す図である。ＲＴＣＰの受信レポートは、受信側の端末から送信側のサーバへ定期的に送信される情報である。また、このＲＴＣＰ受信レポートは、受信側の端末からマルチキャストに送信されている。図２においては、ＲＴＣＰの受信レポートは、ヘッダ、および、１以上の受信レポートブロック（図２の例では、受信レポートブロック１、受信レポートブロック２、……）により構成される。
【００１３】
ヘッダは、ＲＴＣＰのバージョンを示すバージョン情報、パケットのサイズを調整するビットであるパディング、リアルタイム転送に関わる送信元の数を示すカウンタ、パケットタイプ、メッセージ長、および、送信者（すなわち、この受信レポートを送信している受信側の端末）の同期ソース識別子により構成される。
【００１４】
受信レポートブロック１は、送信者ａ１（送信側のサーバａ１）から受信したパケットに基づいて、受信側の端末により生成される情報であり、そのパケットを送った送信元ａ１（送信側のサーバａ１）を識別する送信者ａ１の同期ソース識別子、送信側のサーバａ１から受信側の端末への転送におけるパケット損失率、累積損失パケット数、最大受信シーケンス番号、パケット間隔ジッタ、最新送信レポート時刻、および送信レポート経過時間により構成される。
【００１５】
同様に、受信レポートブロック２は、そのパケットを送った送信元ａ２（送信側のサーバａ２）を識別する送信者ａ２の同期ソース識別子、送信側のサーバａ２から受信側の端末への転送におけるパケット損失率、累積損失パケット数、最大受信シーケンス番号、パケット間隔ジッタ、最新送信レポート時刻、および送信レポート経過時間により構成される。
【００１６】
なお、受信レポートブロックは、受信側の端末により前回の受信レポートを送信してから、この受信レポートを送信するまでの間に、各送信者（各送信側のサーバ）から受信されたパケットの数（ヘッダのカウンタの数）だけ付加される。
【００１７】
図３は、ＲＴＣＰの送信レポートの構成例を示す図である。ＲＴＣＰの送信レポートは、送信側のサーバから受信側の端末へ定期的に送信される情報である。また、このＲＴＣＰ送信レポートは、送信側のサーバからマルチキャストに送信されている。図３の例においては、ＲＴＣＰの送信レポートは、ヘッダ、送信するデータの送信情報、および、１以上の受信レポートブロック（図３の例では、受信レポートブロック１、受信レポートブロック２、……）により構成される。
【００１８】
ヘッダは、図２の受信レポートと同様に、バージョン情報、パディング、カウンタ、パケットタイプ、メッセージ長、および、送信者（すなわち、この送信レポートを送信している送信側のサーバ）の同期ソース識別子により構成される。
【００１９】
送信情報は、送信レポートが送られた時刻であるＮＴＰ（Network Time Protocol）タイムスタンプ、ＮＴＰタイムスタンプに対応するＲＴＰタイムスタンプ、送信側のサーバにより前回の送信レポートを送ってからこの送信レポートを送るまでに送信された、送信パケット数および送信バイト数により構成される。このＮＴＰタイムスタンプおよびＲＴＰタイムスタンプにより、複数のパケットの時間軸を共通の時間軸（ＮＴＰ時間軸）に同期させることができる。
【００２０】
受信レポートブロック１は、送信者ｂ１（受信側の端末ｂ１）から受信した受信レポートの情報であり、その受信レポートを送った送信元ｂ１（受信側の端末ｂ１）を識別する送信者ｂ１の同期ソース識別子、送信側のサーバから受信側の端末ｂ１への転送におけるパケット損失率、累積損失パケット数、最大受信シーケンス番号、パケット間隔ジッタ、最新送信レポート時刻、および送信レポート経過時間により構成される。
【００２１】
同様に、受信レポートブロック２は、その受信レポートを送った送信元ｂ２（受信側の端末ｂ２）を識別する送信者ｂ２の同期ソース識別子、送信側のサーバから受信側の端末ｂ２への転送におけるパケット損失率、累積損失パケット数、最大受信シーケンス番号、パケット間隔ジッタ、最新送信レポート時刻、および送信レポート経過時間により構成される。
【００２２】
なお、この受信レポートブロックの数は、送信側のサーバにより前回の送信レポートを送ってからこの送信レポートを送るまでに受信された受信側の端末からの受信レポートの数（ヘッダのカウンタの数）だけ付加される。
【００２３】
以上のような受信レポートおよび送信レポートの交換により、送信側のサーバは、送信側のサーバから受信側の端末への転送のネットワークの状況が取得できるため、転送するデータのレート制御を行ったり、パケットを重層して送信するなどのＱｏＳ（Quality of Service）対策、または、エラー対策を行うことができる。
【００２４】
【発明が解決しようとする課題】
しかしながら、上述したように、受信レポートおよび送信レポートに付加されているパケット損失率または累積損失パケット数は、送信側のサーバから受信側の端末への転送時に関するデータであり、送信側のサーバから受信側の端末への下りのネットワークの状況しか把握することができないという課題があった。
【００２５】
その結果、上述したＡＲＱの再送要求は、受信側の端末から送信側のサーバへの上りのネットワークの状況に左右されるが、その状況を把握することができないため、ＡＲＱの再送要求を効率よく行うことができないという課題があった。
【００２６】
受信側の端末から送信側のサーバへの上りのネットワークの状況を把握するために、送信側のサーバから受信側の端末への下りのネットワークとは全く別のネットワークを、受信側の端末から送信側のサーバの上りのネットワークを介して行うフィードバック的なシステムを構築することもできるが、このようなシステムでは、ネットワークの状況が大きく異なってしまうため、上りと下りの両方に対応したネットワーク状況報告システムが必要となり、システムが複雑になってしまうという課題があった。
【００２７】
本発明はこのような状況に鑑みてなされたものであり、双方向のネットワーク状況を把握できるようにするものである。
【００２９】
【課題を解決するための手段】
本発明の情報処理システムは、第２の情報処理装置からの受信レポートを受信し、受信レポートから受信レポートのシーケンス番号を取得し、取得されたシーケンス番号に基づいて、受信レポートの損失率を計算し、計算された受信レポートの損失率に基づいてデータの送信の訂正を制御するとともに、受信レポートの損失率を送信レポートに付加して第２の情報処理装置に送信し、第２の情報処理装置は、第１の情報処理装置からのデータを受信し、データから損失パケットを特定する情報を取得し、第１の情報処理装置からの送信レポートに含まれる受信レポートの損失率に基づいて、第１の情報処理装置に対する損失パケットの再送要求を制御することを特徴とする。
【００３０】
本発明の情報処理システムの情報処理方法は、第１の情報処理装置の情報処理方法は、第２の情報処理装置からの受信レポートを受信し、受信レポートから受信レポートのシーケンス番号を取得し、取得されたシーケンス番号に基づいて、受信レポートの損失率を計算し、計算された受信レポートの損失率に基づいてデータの送信の訂正を制御するとともに、受信レポートの損失率を送信レポートに付加して第２の情報処理装置に送信し、第２の情報処理装置の情報処理方法は、第１の情報処理装置からのデータを受信し、データから損失パケットを特定する情報を取得し、第１の情報処理装置からの送信レポートに含まれる受信レポートの損失率に基づいて、第１の情報処理装置に対する損失パケットの再送要求を制御することを特徴とする。
【００３１】
本発明の情報処理装置は、他の情報処理装置より送信された受信レポートから受信レポートのシーケンス番号を取得する取得手段と、取得手段により取得されたシーケンス番号に基づいて、受信レポートの損失率を計算する計算手段と、計算手段により計算された受信レポートの損失率に基づいて、データの送信の訂正を制御する制御手段と、計算手段により計算された受信レポートの損失率を送信レポートに付加して他の情報処理装置に送信する送信手段とを備えることを特徴とする。
【００３２】
パケットを単位としたプロトコルは、ＲＴＰおよびＲＴＣＰであるようにすることができる。
【００３４】
制御手段は、計算手段により計算された受信レポートの損失率が第１の基準値よりも大きいか否かを判断する第１の判断手段と、第１の判断手段による判断結果に基づいて、データの送信エラーの訂正方法を設定する設定手段とを備えるようにすることができる。
【００３５】
制御手段に、第１の判断手段により受信レポートの損失率が第１の基準値よりも小さいと判断された場合、受信レポートの損失率が第２の基準値よりも大きいか否かを判断する第２の判断手段をさらに備え、設定手段は、第２の判断手段により受信レポートの損失率が第２の基準値よりも小さいと判断された場合、データの送信エラーの訂正を禁止するようにすることができる。
【００３６】
設定手段は、第１の判断手段により受信レポートの損失率が第１の基準値よりも大きいと判断された場合、データの送信エラーの訂正方法をＦＥＣに設定し、第１の判断手段により受信レポートの損失率が第１の基準値よりも小さいと判断され、かつ、第２の判断手段により受信レポートの損失率が第２の基準値よりも大きいと判断された場合、データの送信エラーの訂正方法をＡＲＱに設定するようにすることができる。
【００３７】
本発明の情報処理方法は、他の情報処理装置より送信された受信レポートから受信レポートのシーケンス番号を取得する取得ステップと、取得ステップの処理により取得されたシーケンス番号に基づいて、受信レポートの損失率を計算する計算ステップと、計算ステップの処理により計算された受信レポートの損失率に基づいて、データの送信の訂正を制御する制御ステップと、計算ステップの処理により計算された受信レポートの損失率を送信レポートに付加して他の情報処理装置に送信する送信ステップとを含むことを特徴とする。
【００３８】
本発明の記録媒体のプログラムは、他の情報処理装置より送信された受信レポートから受信レポートのシーケンス番号を取得する取得ステップと、取得ステップの処理により取得されたシーケンス番号に基づいて、受信レポートの損失率を計算する計算ステップと、計算ステップの処理により計算された受信レポートの損失率に基づいて、データの送信の訂正を制御する制御ステップと、計算ステップの処理により計算された受信レポートの損失率を送信レポートに付加して他の情報処理装置に送信する送信ステップとを含むことを特徴とする。
【００３９】
本発明のプログラムは、他の情報処理装置より送信された受信レポートから受信レポートのシーケンス番号を取得する取得ステップと、取得ステップの処理により取得されたシーケンス番号に基づいて、受信レポートの損失率を計算する計算ステップと、計算ステップの処理により計算された受信レポートの損失率に基づいて、データの送信の訂正を制御する制御ステップと、計算ステップの処理により計算された受信レポートの損失率を送信レポートに付加して他の情報処理装置に送信する送信ステップとを含むことを特徴とする。
【００４７】
本発明の情報処理システムおよび方法においては、第１の情報処理装置および方法により、第２の情報処理装置からの受信レポートが受信され、受信レポートから受信レポートのシーケンス番号が取得され、取得されたシーケンス番号に基づいて、受信レポートの損失率が計算され、計算された受信レポートの損失率に基づいてデータの送信の訂正が制御されるとともに、受信レポートの損失率が送信レポートに付加して第２の情報処理装置に送信される。そして、第２の情報処理装置および方法により、第１の情報処理装置からのデータが受信され、データから損失パケットを特定する情報が取得され、第１の情報処理装置からの送信レポートに含まれる受信レポートの損失率に基づいて、第１の情報処理装置に対する損失パケットの再送要求が制御される。
【００４８】
本発明の情報処理装置および方法、記録媒体、並びにプログラムにおいては、他の情報処理装置より送信された受信レポートから受信レポートのシーケンス番号が取得され、取得されたシーケンス番号に基づいて、受信レポートの損失率が計算され、計算された受信レポートの損失率に基づいて、データの送信の訂正が制御され、計算された受信レポートの損失率が送信レポートに付加して他の情報処理装置に送信される。
【００５０】
ネットワークとは、少なくとも２つの装置が接続され、ある装置から、他の装置に対して、情報の伝達をできるようにした仕組みをいう。ネットワークを介して通信する装置は、独立した装置どうしであってもよいし、１つの装置を構成している内部ブロックどうしであってもよい。
【００５１】
【発明の実施の形態】
以下、図を参照して本発明の実施の形態について説明する。
【００５２】
図４は、本発明を適用したストリーミングコンテンツ提供システムの構成例を表している。インターネットに代表されるネットワーク２には、ユーザ端末１−１，１−２（以下、これらのユーザ端末を個々に区別する必要がない場合、単にユーザ端末１と称する）が接続されている。この例においては、ユーザ端末が２台のみ示されているが、ネットワーク２には、任意の台数のユーザ端末が接続される。
【００５３】
また、ネットワーク２には、ユーザ端末１に対してストリーミングコンテンツ（以下、コンテンツと称する）を提供するサーバ３が接続されている。このサーバ３も任意の台数がネットワーク２に接続される。
【００５４】
図５はユーザ端末１の構成を表している。図５において、CPU（Central Processing Unit）１１は、ROM（Read Only Memory）１２に記憶されているプログラム、または記憶部１８からRAM（Random Access Memory）１３にロードされたプログラムに従って各種の処理を実行する。RAM１３にはまた、CPU１１が各種の処理を実行する上において必要なデータなども適宜記憶される。
【００５５】
CPU１１、ROM１２およびRAM１３は、バス１４を介して相互に接続されている。このバス１４にはまた、入出力インタフェース１５も接続されている。
【００５６】
入出力インタフェース１５には、キーボード、マウスなどよりなる入力部１６、CRT(Cathode Ray Tube)、LCD(Liquid Crystal Display)などよりなるディスプレイ、並びにスピーカなどよりなる出力部１７、ハードディスクなどより構成される記憶部１８、モデム、ターミナルアダプタなどより構成される通信部１９が接続されている。通信部１９は、ネットワーク２を介しての通信処理を行う。
【００５７】
入出力インタフェース１５にはまた、必要に応じてドライブ２０が接続され、磁気ディスク２１、光ディスク２２、光磁気ディスク２３、或いは半導体メモリ２４などが適宜装着され、それらから読み出されたコンピュータプログラムが、必要に応じて記憶部１８にインストールされる。
【００５８】
なお、サーバ３も、ユーザ端末１と基本的に同様に構成されている。したがって、以下の説明においては、図５のユーザ端末１の構成は、サーバ３の構成としても引用する。
【００５９】
図６は、ユーザ端末１の機能構成例を示すブロック図である。図６に示される機能ブロックは、ユーザ端末１のCPU１１により所定の制御プログラムが実行されることで実現される。
【００６０】
ユーザ端末１のＲＴＰポート４１は、サーバ３よりネットワーク２を介して、ＲＴＰパケット化されたコンテンツデータを受信し、ＲＴＰパケット解析部４２に出力する。ＲＴＰパケット解析部４２は、そのＲＴＰパケットをヘッダ部とデータ部に分解するとともに解析し、データ部のコンテンツデータをバッファ４３に蓄積する。なお、このコンテンツデータが蓄積されたバッファ４３の場所（アドレス）、およびヘッダに記述されていたヘッダ情報を、インデックスリスト４４に記憶するようにしてもよい。
【００６１】
復号部４５は、再生する時刻に応じて、バッファ４３に蓄積されたコンテンツデータを復号し、出力部１７を構成するディスプレイまたはスピーカに出力し、コンテンツデータが再生される。
【００６２】
ＲＴＣＰパケット生成部４６は、ＲＴＰポート４１によりコンテンツデータを受信している場合、予め設定された一定の時間間隔で、ＲＴＰパケット解析部４２により解析されたＲＴＰパケットのヘッダの情報に基づいて、受信レポートＲＲ（Receiver Report）を作成し、ＲＴＣＰポート４７に出力する。
【００６３】
図７は、ユーザ端末１−１よりサーバ３へ送信されるＲＴＣＰの受信レポートＲＲの構成例を示す図である。なお、図７の受信レポートＲＲは、受信レポートブロック１の送信者ｃ１の同期ソース識別子の後に、ＲＴＣＰシーケンス番号が追加されている点を除いて、その他の構成は、上述した図２の受信レポートＲＲと同様の構成である。したがって、図２に関する説明は、図７の説明としても引用する。
【００６４】
図７の例の場合、例えば、ヘッダの送信者の同期ソース識別子は、ユーザ端末１−１に対応し、受信レポートブロック１は、送信者ｃ１（サーバ３）から送信されたパケットに対応する情報とされ、受信レポートブロック２は、送信者ｃ２（図示せぬ他のサーバ）から送信されたパケットに対応する情報とされる。
【００６５】
すなわち、ＲＴＣＰパケット生成部４６は、受信レポートブロック１を、サーバ３より送信されたパケットに基づいて生成する。このとき、受信レポートブロック１の送信者ｃ１（サーバ３）の同期ソース識別子の後に、ＲＴＣＰシーケンス番号を付加して受信レポートＲＲが生成される。
【００６６】
ＲＴＣＰポート４７は、その受信レポートＲＲを、ネットワーク２を介してサーバ３に送信する。また、ＲＴＣＰポート４７は、ネットワーク２を介してサーバ３より、送信レポートＳＲ（Sender Report）、または、コンテンツデータの送信が終了したことを示すＥＯＤ（End of  Data）メッセージデータを受信する。
【００６７】
ＲＴＣＰパケット解析部４８は、受信された送信レポートＳＲを解析する。送信レポートＳＲ（図１０を参照して後述する）には、ＲＴＣＰパケットのＲＴＣＰシーケンス番号、および、ユーザ端末１からサーバ３への送信におけるパケット損失率が付加されている。
【００６８】
エラー判定部４９は、エラー訂正方式として、自動再送要求（ＡＲＱ：Automatic Repeat request）が用いられている場合、ＲＴＰパケット解析部４２により解析されたヘッダ情報に基づいて、サーバ３からユーザ端末１へ送信されたコンテンツデータの損失パケットを検出し、ＲＴＣＰパケット生成部４６に再送要求を指示する。このときに、エラー判定部４９は、ＲＴＣＰパケットのＲＴＣＰシーケンス番号、および、ユーザ端末１からサーバ３への送信におけるパケット損失率に基づいて、再送要求の方法の変更を制御し、ＲＴＣＰパケット生成部４６に指示する。
【００６９】
ＲＴＣＰパケット生成部４６は、その指示の再送要求の方法に基づいて、再送要求ＮＡＣＫ（Negative Knowledge）のパケットを生成し、ＲＴＣＰポート４７を介してサーバ３に送信する。
【００７０】
図８は、ユーザ端末１−１よりサーバ３へ送信されるＲＴＣＰの再送要求ＮＡＣＫのパケットの構成を示す図である。図８の例においては、再送要求ＮＡＣＫのパケットは、ヘッダ、フォーマットタイプ、パケットタイプ、パケット長、送信者（再送要求ＮＡＣＫのパケットを送信したユーザ端末１−１）の同期ソース識別子、ＲＴＣＰシーケンス番号、およびタイムスタンプにより構成されている。それらの意味は、基本的に、図７（したがって、図２）における対応する名称の要素と同様である。タイムスタンプの後には、ＲＴＰパケットのヘッダ情報に基づいて検出された損失パケットに対応した再送指定パケット個数および再送指定シーケンス番号が付加される。
【００７１】
図９は、サーバ３の機能構成例を示すブロック図である。図９に示される機能ブロックは、サーバ３のCPU１１により所定の制御プログラムが実行されることで実現される。
【００７２】
符号化部６１は、ユーザ端末１からの要求があった場合、撮像部９１が被写体を撮像して生成し、リアルタイムで出力するコンテンツデータ（映像データと音声データ）を符号化し、バッファ６２に蓄積する。
【００７３】
ＲＴＰパケット生成部６３は、バッファ６２に蓄積されたコンテンツデータをＲＴＰパケット化し、ＲＴＰポート６４に出力する。ＲＴＰポート６４は、ＲＴＰプロトコルによりネットワーク２を介してユーザ端末１に送信する。
【００７４】
ＲＴＣＰポート６５は、ユーザ端末１よりネットワーク２を介して、再送要求ＮＡＣＫのパケット（図８）、または、受信レポートＲＲ（図７）を受信し、ＲＴＣＰパケット解析部６６に出力する。再送要求ＮＡＣＫ、または、受信レポートＲＲは、ＲＴＣＰパケットにより構成されており、ＲＴＣＰシーケンス番号が付加されている。
【００７５】
ＲＴＣＰパケット解析部６６は、再送要求ＮＡＣＫのＲＴＣＰパケット、または、受信レポートＲＲのＲＴＣＰパケットを解析する。パケットロス検知部６７は、解析された受信レポートＲＲのＲＴＣＰパケットのＲＴＣＰシーケンス番号に基づいて、ユーザ端末１からサーバ３へのデータ転送のネットワーク２におけるパケット損失率を計算する。また、パケットロス検知部６７は、解析された再送要求ＮＡＣＫのＲＴＣＰパケットから、再送パケットの要求データをエラー処理部６８に出力する。
【００７６】
エラー処理部６８は、再送パケットの要求データに基づいて、再送パケットを含むデータをバッファ６２より抽出し、ＲＴＰパケット生成部６３およびＲＴＰポート６４を介してユーザ端末１に送信する。なお、エラー処理部６８は、必要に応じて、再送パケットを重複して送る場合もある。
【００７７】
ＲＴＣＰパケット生成部６９は、送信レポートＳＲに、パケットロス検知部６７により計算されたパケット損失率を付加して、予め設定された一定の時間間隔で、ＲＴＣＰポート６５よりネットワーク２を介してユーザ端末１に送信する。また、ＲＴＣＰパケット生成部６９は、ＲＴＰポート６４よりコンテンツデータの送信終了が検出されると、ＥＯＤメッセージデータを、ＲＴＣＰポート６５よりネットワーク２を介してユーザ端末１に送信する。
【００７８】
図１０は、サーバ３から送信されるＲＴＣＰの送信レポートＳＲの構成例を示す図である。なお、図１０の送信レポートＳＲは、ヘッダにおいて、送信者の同期ソース識別子の後に、ＲＴＣＰシーケンス番号が追加されている点、および、受信レポートブロック１において、その末尾に、送信者ｄ１から送信者（サーバ３）に対して転送されたデータのパケット損失率が追加されている点を除いて、その他の構成は、上述した図３の送信レポートＳＲと同様の構成である。したがって、上述した図３の説明は、図１０の説明としても引用する。
【００７９】
図１０の場合、例えば、受信レポートブロック１は、ユーザ端末１−１（送信者ｄ１）から送信された受信レポートに対応する情報とされ、受信レポートブロック２は、ユーザ端末１−２（送信者ｄ２）から送信された受信レポートに対応する情報とされる。
【００８０】
すなわち、受信レポートブロック１に記述されるのは、ユーザ端末１−１より送信された受信レポートに基づいた情報であり、ＲＴＣＰパケット生成部６９は、ヘッダの送信者（サーバ３）の同期ソース識別子の後に、ＲＴＣＰシーケンス番号を付加し、さらに、受信レポートブロック１の末尾に、送信者ｄ１（ユーザ端末１−１）から送信者（サーバ３）へのデータ転送のパケット損失率を付加して送信レポートＳＲを生成する。また、同様に、ユーザ端末１−２より送信された受信レポートにＲＴＣＰシーケンス番号が付加されている場合、受信レポートブロック２の末尾にも送信者ｄ２（ユーザ端末１−２）から送信者（サーバ３）へのデータ転送のパケット損失率が付加される。
【００８１】
なお、パケット損失率に加えて、ユーザ端末１からの転送途中に損失したＲＴＣＰパケットのＲＴＣＰシーケンス番号を記述したエラーＲＴＣＰシーケンス番号リストを付加するようにしてもよい。
【００８２】
次に、図１１のフローチャートを参照して、サーバ３のパケット損失率の計算処理を説明する。図１１の例において、サーバ３より送信される送信レポートＳＲの送信間隔が、ＲＴＣＰ基準時間Ｔｉとして設定され、このＲＴＣＰ基準時間内のパケット損失率が求められる。
【００８３】
サーバ３からネットワーク２を介して、ＲＴＰポート４１によりコンテンツデータを受信している場合、ユーザ端末１のＲＴＣＰパケット生成部４６は、予め設定された一定の時間間隔で、受信レポートＲＲを生成し、ＲＴＣＰポート４７よりネットワーク２を介してサーバ３に送信する。これに対応して、ステップＳ１において、サーバ３のＲＴＣＰポート６５は、受信レポートＲＲを受信する。
【００８４】
ＲＴＣＰパケット解析部６６は、ステップＳ２において、受信レポートＲＲからＲＴＣＰシーケンス番号を取得し、ステップＳ３において、そのＲＴＣＰシーケンス番号を、ＲＴＣＰシーケンス番号リストＡＬに追加する。なお、ＲＴＣＰシーケンス番号リストＡＬは、RAM１３などに記憶されており、送信レポートＳＲが送信された時点でリセットされ、その後、新たにＲＴＣＰシーケンス番号が追加される。
【００８５】
ＲＴＣＰパケット生成部６９は、内蔵するクロックで計時動作を行って、ユーザ端末１からのＲＴＣＰの受信レポートＲＲを、前回受信してからの経過時間Ｔ（以下、ＲＴＣＰ経過時間Ｔと称する）を計測している。そこで、ステップＳ４において、ＲＴＣＰパケット生成部６９は、そのＲＴＣＰ経過時間Ｔが、予め設定されたＲＴＣＰ基準時間Ｔｉ（送信レポートＳＲの送信間隔Ｔｉ）になったか否かを判断する。
【００８６】
ステップＳ４において、ＲＴＣＰ経過時間Ｔが、まだＲＴＣＰ基準時間Ｔｉになっていないと判断された場合、ステップＳ５乃至Ｓ９の処理はスキップされ、処理は終了される。
【００８７】
一方、ステップＳ４において、ＲＴＣＰ経過時間Ｔが、ＲＴＣＰ基準時間Ｔｉと等しいか、または、ＲＴＣＰ基準時間Ｔｉより大きくなったと判断された場合、ステップＳ５において、ＲＴＣＰパケット生成部６９は、ＲＴＣＰシーケンス番号リストＡＬのＲＴＣＰシーケンス番号の数ＡＮを取得し、また、同時に、ＲＴＣＰ基準時間Ｔｉに、ユーザ端末１からの受信レポートＲＲを全て正常受信したときのＲＴＣＰシーケンス番号の総数ＢＮを求める。
【００８８】
なお、ＲＴＣＰシーケンス番号の総数ＢＮは、次のようにして求められる。すなわち、いまの場合、ユーザ端末１より受信レポートＲＲが一定の時間間隔Ｔｕで送信されている。その一定の時間間隔Ｔｕの、設定されたＲＴＣＰ基準時間Ｔｉに対する割合（Ｔｕ／Ｔｉ）の値が１／１００であるとすると、ＲＴＣＰシーケンス番号の総数ＢＮは、１００であるとされる。
【００８９】
ステップＳ６において、パケットロス検知部６７は、ＲＴＣＰシーケンス番号の数ＡＮ、および、ＲＴＣＰシーケンス番号の総数ＢＮに基づいて、パケット損失率Ｅを以下の式（１）より求める。
【００９０】
パケット損失率  Ｅ  ＝  ＡＮ  ／  ＢＮ                  ・・・（１）
【００９１】
ステップＳ７において、パケットロス検知部６７は、エラーＲＴＣＰシーケンス番号リストＣＬを求める。エラーＲＴＣＰシーケンス番号リストＣＬは、ＲＴＣＰ基準時間Ｔｉに、ユーザ端末１からの受信レポートＲＲを全て正常に受信した場合のＲＴＣＰシーケンス番号リストから、実際に受信したＲＴＣＰシーケンス番号リストＡＬを除いて求められる。
【００９２】
ステップＳ８において、ＲＴＣＰパケット生成部６９は、ステップＳ６において求められたパケット損失率Ｅ、および、ステップＳ７において求められたエラーＲＴＣＰシーケンス番号リストＣＬを、送信レポートＳＲに付加し、ＲＴＣＰポート６５よりネットワーク２を介してユーザ端末１に送信する。
【００９３】
ステップＳ９において、ＲＴＣＰパケット生成部６９は、ＲＴＣＰ経過時間Ｔを０に初期化する。このとき、同時に、ＲＴＣＰシーケンス番号リストＡＬもリセットされる。
【００９４】
上記説明においては、ステップＳ４において、ＲＴＣＰ経過時間ＴとＲＴＣＰ基準時間Ｔｉを比較したが、ＲＴＣＰ経過時間Ｔが、ＲＴＣＰ基準時間Ｔｉと一致したときに、ステップＳ２，Ｓ３およびＳ５乃至Ｓ９の処理を実行させるようにしてもよい。
【００９５】
以上のように、受信レポートＲＲにＲＴＣＰシーケンス番号を付加することにより、サーバ３において、ユーザ端末１からサーバ３へのデータ転送のパケット損失率が求められ、ユーザ端末１からサーバ３へのデータ転送のネットワーク２の状況が把握される。
【００９６】
さらに、求められたユーザ端末１からサーバ３へのデータ転送のパケット損失率は、送信レポートＳＲに付加され、ユーザ端末１に送信されるので、ユーザ端末１においても、ユーザ端末１からサーバ３へのデータ転送のネットワーク２の状況を把握することができる。
【００９７】
以上のようにして、ユーザ端末１からサーバ３へのデータ転送のネットワーク２の状況が把握される場合の、ユーザ端末１の再送要求処理について、図１２のフローチャートを参照して説明する。なお、図１２の例においては、ユーザ端末１とサーバ３の間のデータ転送において、エラー訂正方式として、ＡＲＱ（自動再送要求：Automatic Repeat request）が用いられる。
【００９８】
サーバ３は、ユーザ端末１からの要求に基づいて、コンテンツデータをＲＴＰパケット化し、ＲＴＰプロトコルによりネットワーク２を介してユーザ端末１に送信してくる。そこで、ステップＳ３１において、ユーザ端末１のＲＴＰポート４１は、ＲＴＰパケット化されたコンテンツデータを受信する。
【００９９】
ステップＳ３２において、ＲＴＰパケット解析部４２は、ＲＴＰパケットをヘッダ部とデータ部に分解するとともに、ヘッダ部を解析し、データ部のコンテンツデータをバッファ４３に蓄積し、ヘッダ部のヘッダの情報をエラー判定部４９に出力する。
【０１００】
ステップＳ３３において、エラー判定部４９は、ＲＴＰパケット解析部４２により解析されたヘッダの情報に基づいて、ＲＴＰパケットの中に損失パケットがあるか否かを判断する。具体的には、ＲＴＰパケットのシーケンス番号（図１を参照に上述した）が、既に受信しているシーケンス番号に対して不連続になっているか否かが判定され、不連続であれば、受信していないパケットがある（損失パケットがある）と判断される。
【０１０１】
ステップＳ３３において、ＲＴＰパケットに損失パケットがあると判断された場合、ステップＳ３４において、エラー判定部４９は、ＲＴＣＰパケット解析部４８より解析された送信レポートＳＲ内の、ユーザ端末１からサーバ３へのデータ転送のパケット損失率に基づいて、再送要求ＮＡＣＫのパケットをＲＴＣＰパケット生成部４６を制御し、生成させる。ステップＳ３５において、ＲＴＣＰポート４７は、生成された再送要求ＮＡＣＫのＲＴＣＰパケットをサーバ３に送信する。
【０１０２】
ここで、上述したステップＳ３４およびＳ３５の処理の詳細について、図１３乃至図１６を参照して説明する。
【０１０３】
上述したように、図１１のステップＳ８の処理で生成された送信レポートＳＲは、、設定されたＲＴＣＰ基準時間（送信レポートＳＲの送信間隔）で、パケット損失率Ｅ、および、エラーＲＴＣＰシーケンス番号リストＣＬが付加されて、サーバ３よりネットワーク２を介して送信される。この送信レポートＳＲは、ユーザ端末１のＲＴＣＰポート４７により受信され、ＲＴＣＰパケット解析部４８により解析される。これにより、ユーザ端末において、ユーザ端末１からサーバ３へのデータ転送のパケット損失率、すなわち、ユーザ端末１からサーバ３へのデータ転送のネットワーク２の状況が把握される。
【０１０４】
このユーザ端末１からサーバ３へのデータ転送のネットワーク２の状況に応じて、ユーザ端末１において、図１３乃至図１６に示されるように、再送要求が制御される。図１３乃至図１６においては、横軸は、時間軸を示している。図１３に示されるように、サーバ３から、ＲＴＰのシーケンス番号１乃至８のパケットがユーザ端末１に送信され、転送途中に、シーケンス番号４乃至６のパケット（図中、２重にハッチングされた表示のパケット）が損失し、シーケンス番号１乃至３，７および８のパケットがユーザ端末１により正確に受信される。
【０１０５】
それに対応して、転送途中に損失したシーケンス番号４乃至６のパケットの再送を要求するために、図１３の例においては、ユーザ端末１から、シーケンス番号４乃至６のパケットに、それぞれ対応する再送要求ＮＡＣＫ４乃至ＮＡＣＫ６のパケット（図中ハッチングされた表示のパケット）が個別にサーバ３に向けて送信される。
【０１０６】
図１４の例においては、ユーザ端末１から、シーケンス番号４乃至６のパケットに対応する再送要求ＮＡＣＫ４，５，６が１つのパケットにまとめられ、サーバ３に向けて送信されている。
【０１０７】
また、図１５の例においては、ユーザ端末１から、シーケンス番号４乃至６のパケットにそれぞれ対応する再送要求ＮＡＣＫ４乃至ＮＡＣＫ６のパケット（図中ハッチングされた表示のパケット）が個別に複数個ずつ（例えば、２個ずつ）、サーバ３に向けて送信される。
【０１０８】
図１６の例においては、ユーザ端末１から、シーケンス番号４および５のパケットに対応する再送要求ＮＡＣＫ４，５が、１つのパケットにまとめられるとともに、そのパケットが、２個送信され、さらに、シーケンス番号６のパケットに対応する再送要求が再送要求ＮＡＣＫ６の３個のパケットがサーバ３に向けて送信されている。
【０１０９】
以上のように、エラー判定部４９は、ＲＴＣＰパケット解析部４８により解析された送信レポートＳＲ内の、ユーザ端末１からサーバ３へのデータ転送のパケット損失率により求められる、ユーザ端末１からサーバ３へのデータ転送のネットワーク２の状況に応じて、再送要求パケットの送信方法を変更する。例えば、パケット損失率が第１の基準値より大きい場合、図１５または図１６に示されるように、再送要求ＮＡＣＫのパケットに冗長性を持たせて送信する。これにより、再送要求ＮＡＣＫのパケットをサーバ３に確実に届けることができる。
【０１１０】
また、パケット損失率が第２の基準値（第１の基準値より小さい）より小さい場合には、図１４に示されるように、送信するパケットの数を少なくして、伝送路のトラフィック量を減少させる。パケット損失率が第１の基準値と第２の基準値の間の値である場合には、図１３に示されるように、標準的な方法でパケットを送信する。
【０１１１】
ステップＳ３３において、損失パケットが存在しないと判定された場合、ステップＳ３４，Ｓ３５の処理はスキップされる。
【０１１２】
ステップＳ３５の処理の後、またはステップＳ３３において、損失パケットが存在しないと判定された場合、ステップＳ３６において、復号部４５は、バッファ４３に蓄積されているコンテンツデータが再生時刻になったか否かを判定する。現在時刻がまだ再生時刻に達していない場合、処理はステップＳ３１に戻り、それ以降の処理が繰り返される。
【０１１３】
ステップＳ３６において、現在時刻が再生時刻に達したと判定された場合、ステップＳ３７に進み、復号部４５は、バッファ４３に蓄積されているコンテンツデータを読み出し、復号し、出力部１７に出力する。
【０１１４】
次に、ユーザ端末１からサーバ３へのデータ転送のネットワーク２の状況が把握されたサーバ３のエラー訂正方法の設定処理について、図１７のフローチャートを参照して説明する。
【０１１５】
ステップＳ６１において、サーバ３のCPU１１（ＲＴＣＰパケット解析部６６、ＲＴＣＰパケット生成部６９、パケットロス検知部６７など）は、図１１のフローチャートを参照して上述したパケット損失率Ｅの計算処理を実行する。これにより、ユーザ端末１からサーバ３へのデータ転送のパケット損失率Ｅが求められる。そこで、ステップＳ６２において、エラー処理部６８は、パケット損失率Ｅが予め設定された基準値σ１（０＜σ１）以上であるか否かを判断し、パケット損失率Ｅが基準値σ１以上であると判断した場合、ステップＳ６３において、エラー処理部６８は、エラー訂正方法を、ＦＥＣ（前方向誤り訂正：forward error correction）に設定する。すなわち、パケット損失率Ｅが、基準値σ１よりも大きい場合、エラー訂正方法を、サーバ３には再送要求を行わず、ユーザ端末１だけで誤りの場所を確定し、これを訂正するエラー訂正方法である、ＦＥＣに設定することにより、ＡＲＱを用いた場合よりも、ユーザ端末１とサーバ３の間のデータ転送が非効率になってしまうのを抑制できる。
【０１１６】
ステップＳ６２において、パケット損失率Ｅが基準値σ１より小さいと判断された場合、ステップＳ６４において、エラー処理部６８は、パケット損失率Ｅが、基準値σ２（０＜σ２＜σ１）より大きいか否かを判断する。ステップＳ６４において、パケット損失率Ｅが、基準値σ２より大きいと判断された場合（ステップＳ６２の処理により、いま、パケット損失率Ｅは、基準値σ１より小さいので、パケット損失率Ｅは，基準値σ２と基準値σ１の間の大きさの値ということになる）、ステップＳ６５において、エラー処理部６８は、エラー訂正方法を、ＡＲＱに設定する。
【０１１７】
ステップＳ６４において、パケット損失率Ｅが、基準値σ２より小さいと判断された場合、ステップＳ６６において、エラー処理部６８は、パケット損失率Ｅが、マイナス値であるか否かを判断する。ステップＳ６６において、パケット損失率Ｅが、マイナス値でないと判断された場合、ステップＳ６７において、エラー処理部６８は、エラー制御を解除し、エラー制御を行わないようにする。
【０１１８】
ステップＳ６６において、パケット損失率Ｅが、マイナス値であると判断された場合、ステップＳ６８において、エラー処理部６８は、その他のエラー処理を実行する。すなわち、パケット損失率Ｅが、取り得もしない値（この場合、マイナス値）である場合は、ユーザ端末１あるいはサーバ３において誤動作などが生じている恐れがあり、それに対するエラー処理が実行される。
【０１１９】
以上のように、ユーザ端末１からサーバ３へのデータ転送のパケット損失率により求められる、ユーザ端末１からサーバ３へのデータ転送のネットワーク２の状況に応じて、サーバ３側で、エラー訂正方法を変更できるようにしたので、ユーザ端末１とサーバ３の間において効率のよいデータ転送が可能になる。
【０１２０】
以上のように、ＲＴＰ伝送において、ＲＴＣＰパケットにＲＴＣＰシーケンス番号を付加したので、ユーザ端末１からサーバ３へのデータ転送のパケット損失率が求められ、このパケット損失率をＲＴＣＰの送信レポートに付加することにより、ユーザ端末１とサーバ３の両方で、ユーザ端末１からサーバ３へのデータ転送のパケット損失率が把握できる。
【０１２１】
これにより、ユーザ端末１においては、自動再送要求ＡＲＱをＲＴＰ伝送に用いた場合、ユーザ端末１からサーバ３へのデータ転送のパケット損失率に応じて、その再送要求を重複して要求したり、冗長要求するなどの選択が動的に実行できるようになり、より正確に、効率よく再送要求ができるようになる。さらに、サーバ３においては、ユーザ端末１からサーバ３へのパケット損失率に応じて、エラー訂正方法をＡＲＱからＦＥＣなどに変更できたり、データ転送のパケット損失率が非常に少ない場合には、エラー訂正方法を行わないようにすることもできる。
【０１２２】
すなわち、サーバ３からユーザ端末１へのパケット損失率だけでなく、ユーザ端末１からサーバ３へのパケット損失率を求め、その結果をサーバ３とユーザ端末１の両方で把握することができるので、より柔軟で、かつ、エラー耐性のある信頼性の高い伝送を動的に提供できる。
【０１２３】
以上により、ユーザ端末１のユーザは、満足するデータを取得することができる。
【０１２４】
上述した一連の処理は、ハードウェアにより実行させることもできるが、ソフトウェアにより実行させることもできる。一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、専用のハードウェアに組み込まれているコンピュータ、または、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどに、プログラム格納媒体からインストールされる。
【０１２５】
コンピュータにインストールされ、コンピュータによって実行可能な状態とされるプログラムを格納するプログラム格納媒体は、図５に示されるように、磁気ディスク２１（フレキシブルディスクを含む）、光ディスク２２（CD-ROM(Compact Disc-Read Only Memory)、DVD(Digital Versatile Disc)を含む）、光磁気ディスク２３（MD(Mini-Disc)（商標）を含む）、もしくは半導体メモリ２４などよりなるパッケージメディア、または、プログラムが一時的もしくは永続的に格納されるＲＯＭ１２や、記憶部１８などにより構成される。
【０１２６】
なお、本明細書において、記録媒体に記録されるプログラムを記述するステップは、記載された順序に従って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。
【０１２７】
なお、本明細書において、システムとは、複数の装置により構成される装置全体を表すものである。
【０１２８】
【発明の効果】
以上の如く、本発明によれば、双方向のネットワーク状況を把握できるシステムを構築できる。また、本発明によれば、より正確に、効率よく再送要求ができる。さらに、本発明によれば、ネットワーク状況に応じて、効率的なエラー訂正方法が提供される。
【図面の簡単な説明】
【図１】ＲＴＰパケットの構成例を示す図である。
【図２】ＲＴＣＰの受信レポートの構成例を示す図である。
【図３】ＲＴＣＰの送信レポートの構成例を示す図である。
【図４】本発明を適用したストリーミングコンテンツ提供システムの構成例を示す図である。
【図５】図４のユーザ端末の構成例を示すブロック図である。
【図６】図４のユーザ端末の機能構成例を示すブロック図である。
【図７】図４のユーザ端末から送信されるＲＴＣＰの受信レポートの構成例を示す図である。
【図８】図４のユーザ端末から送信されるＮＡＣＫのパケットの構成例を示す図である。
【図９】図４のサーバの機能構成例を示すブロック図である。
【図１０】図４のサーバから送信されるＲＴＣＰの送信レポートの構成例を示す図である。
【図１１】図４のサーバのパケット損失率計算処理を説明するフローチャートである。
【図１２】図４のユーザ端末の再送要求処理を説明するフローチャートである。
【図１３】図４のユーザ端末のから送信されるＮＡＣＫのパケットを説明する図である。
【図１４】図４のユーザ端末のから送信されるＮＡＣＫのパケットを説明する図である。
【図１５】図４のユーザ端末のから送信されるＮＡＣＫのパケットを説明する図である。
【図１６】図４のユーザ端末のから送信されるＮＡＣＫのパケットを説明する図である。
【図１７】図４のサーバのエラー設定方法の変更処理を説明するフローチャートである。
【符号の説明】
１−１，１−２  ユーザ端末，２  ネットワーク，３  サーバ，１１  CPU，４１  ＲＴＰポート，４２  ＲＴＰパケット解析部，４６  ＲＴＣＰパケット生成部，４７  ＲＴＣＰポート，４８  ＲＴＣＰパケット解析部，４９  エラー判定部，６２  バッファ，６３  ＲＴＰパケット生成部，６４  ＲＴＰポート，６５ＲＴＣＰポート，６６  ＲＴＣＰパケット解析部，  ６７  パケットロス検知部，６８  エラー処理部
【図１】
0004000905.tif 000002
【図２】
0004000905.tif 000003
【図３】
0004000905.tif 000004
【図４】
0004000905.tif 000005
【図５】
0004000905.tif 000006
【図６】
0004000905.tif 000007
【図７】
0004000905.tif 000008
【図８】
0004000905.tif 000009
【図９】
0004000905.tif 000010
【図１０】
0004000905.tif 000011
【図１１】
0004000905.tif 000012
【図１２】
0004000905.tif 000013
【図１３】
0004000905.tif 000014
【図１４】
0004000905.tif 000015
【図１５】
0004000905.tif 000016
【図１６】
0004000905.tif 000017
【図１７】
0004000905.tif 000018