(57)【要約】【課題】  通信網の状態に応じて、冗長データを含むデータの送信をより効率的に行う。【解決手段】  輻輳／非輻輳判定部１０５は、通信網が輻輳状態であるか否かを判定する。FECパケット生成部８４は、送信パケットに格納されているストリーミングデータの誤りを訂正するための誤り訂正データが格納されている誤り訂正パケットを生成する。FEC送信制御部８６は、輻輳状態でない旨の判定結果から輻輳状態である旨の判定結果に変化した場合、誤り訂正パケットの数を変更するように、誤り訂正パケットの生成を制御する。本発明は、遠隔テレビ会議システムに適用できる。【選択図】  図６
2005175837.tif 000002
【特許請求の範囲】
【請求項１】
通信網を介して、ストリーミングデータが格納されている送信パケットを送信する送信装置において、
前記通信網が輻輳状態であるか否かを判定する判定手段と、
前記送信パケットに格納されている前記ストリーミングデータの誤りを訂正するための誤り訂正データが格納されている誤り訂正パケットを生成する生成手段と、
輻輳状態でない旨の判定結果から輻輳状態である旨の判定結果に変化した場合、前記誤り訂正パケットの数を変更するように、前記生成手段における前記誤り訂正パケットの生成を制御する制御手段と
を備えることを特徴とする送信装置。
【請求項２】
前記制御手段は、輻輳状態であると判定された場合、前記生成手段に所定の数の前記誤り訂正パケットを生成させ、輻輳状態でないと判定された場合、前記生成手段の前記誤り訂正パケットの生成を抑制するように、前記生成手段における前記誤り訂正パケットの生成を制御する
ことを特徴とする請求項１に記載の送信装置。
【請求項３】
前記制御手段は、輻輳状態でない旨の判定結果から輻輳状態である旨の判定結果に変化した場合、直前の輻輳状態における前記送信パケットの受信の状態を基に、前記誤り訂正パケットの数を変更するように、前記生成手段における前記誤り訂正パケットの生成を制御する
ことを特徴とする請求項１に記載の送信装置。
【請求項４】
前記制御手段は、所定の期間における１または複数の前記送信パケットからなる誤り訂正の単位であって、所定の期間における１または複数の誤り訂正の単位の受信状態を基に、前記期間における１または複数の前記誤り訂正の単位のいずれかにおいて、前記誤り訂正パケットの数が不足している場合、前記誤り訂正パケットの数を増加させるように、前記生成手段における前記誤り訂正パケットの生成を制御する
ことを特徴とする請求項１の記載の送信装置。
【請求項５】
前記判定手段は、第１の時刻から現在時刻までの期間における前記送信パケットの相手への伝送に要する遅延時間に依存する短期依存遅延時間と、前記第１の時刻より過去の第２の時刻から現在時刻までの期間における前記遅延時間に依存する長期依存遅延時間とを基に、輻輳状態であるか否かを判定する
ことを特徴とする請求項１に記載の送信装置。
【請求項６】
通信網を介して、ストリーミングデータが格納されている送信パケットを送信する送信方法において、
前記通信網が輻輳状態であるか否かを判定する判定ステップと、
前記送信パケットに格納されている前記ストリーミングデータの誤りを訂正するための誤り訂正データが格納されている誤り訂正パケットを生成する生成ステップと、
輻輳状態でない旨の判定結果から輻輳状態である旨の判定結果に変化した場合、前記誤り訂正パケットの数を変更するように、前記生成ステップにおける前記誤り訂正パケットの生成を制御する制御ステップと
を含むことを特徴とする送信方法。
【請求項７】
通信網を介して、ストリーミングデータが格納されている送信パケットを送信する送信処理用のプログラムであって、
前記通信網が輻輳状態であるか否かを判定する判定ステップと、
前記送信パケットに格納されている前記ストリーミングデータの誤りを訂正するための誤り訂正データが格納されている誤り訂正パケットを生成する生成ステップと、
輻輳状態でない旨の判定結果から輻輳状態である旨の判定結果に変化した場合、前記誤り訂正パケットの数を変更するように、前記生成ステップにおける前記誤り訂正パケットの生成を制御する制御ステップと
を含むことを特徴とするコンピュータが読み取り可能なプログラムが記録されている記録媒体。
【請求項８】
通信網を介して、ストリーミングデータが格納されている送信パケットを送信する送信処理をコンピュータに行わせるプログラムにおいて、
前記通信網が輻輳状態であるか否かを判定する判定ステップと、
前記送信パケットに格納されている前記ストリーミングデータの誤りを訂正するための誤り訂正データが格納されている誤り訂正パケットを生成する生成ステップと、
輻輳状態でない旨の判定結果から輻輳状態である旨の判定結果に変化した場合、前記誤り訂正パケットの数を変更するように、前記生成ステップにおける前記誤り訂正パケットの生成を制御する制御ステップと
を含むことを特徴とするプログラム。
【請求項９】
通信網を介して、ストリーミングデータが格納されている送信パケットを受信する受信装置において、
前記送信パケットに格納されている前記ストリーミングデータの誤りを訂正するための誤り訂正データが格納されている誤り訂正パケットを受信する受信制御手段と、
受信された誤り訂正パケットの数が、前記ストリーミングデータの誤りを訂正するのに適正であるか否かを判定する判定手段と
を備えることを特徴とする受信装置。
【請求項１０】
前記判定手段は、受信された誤り訂正パケットの数が、前記ストリーミングデータの誤りを訂正するのに不足であるか、適正であるか、および過多であるかの何れであるかを判定する
ことを特徴とする請求項９に記載の受信装置。
【請求項１１】
前記判定手段は、１または複数の前記送信パケットからなる誤り訂正の単位ごとに、受信された前記誤り訂正パケットの数が、前記ストリーミングデータの誤りを訂正するのに不足であるか、適正であるか、および過多であるかの何れであるかを判定し、
所定の期間における１または複数の前記誤り訂正の単位に対する前記判定結果を基に、前記期間における１または複数の前記誤り訂正の単位のいずれかにおいて、前記誤り訂正パケットの数が不足していると判定された場合、相手への通知に前記誤り訂正パケットの数が不足している旨を設定する設定手段をさらに備える
ことを特徴とする請求項９に記載の受信装置。
【請求項１２】
前記判定結果に基づく通知を格納するフィードバックパケットを生成する生成手段と、
前記生成手段によって、生成された前記フィードバックパケットの相手への送信を制御する送信制御手段とをさらに備える
ことを特徴とする請求項９に記載の受信装置。
【請求項１３】
通信網を介して、ストリーミングデータが格納されている送信パケットを受信する受信方法において、
前記送信パケットに格納されている前記ストリーミングデータの誤りを訂正するための誤り訂正データが格納されている誤り訂正パケットを受信する受信制御ステップと、
前記受信制御ステップにおいて受信された誤り訂正パケットの数が、前記ストリーミングデータの誤りを訂正するのに適正であるか否かを判定する判定ステップと
を含むことを特徴とする受信方法。
【請求項１４】
通信網を介して、ストリーミングデータが格納されている送信パケットを受信する受信処理用のプログラムであって、
前記送信パケットに格納されている前記ストリーミングデータの誤りを訂正するための誤り訂正データが格納されている誤り訂正パケットを受信する受信制御ステップと、
前記受信制御ステップにおいて受信された誤り訂正パケットの数が、前記ストリーミングデータの誤りを訂正するのに適正であるか否かを判定する判定ステップと
を含むことを特徴とするコンピュータが読み取り可能なプログラムが記録されている記録媒体。
【請求項１５】
通信網を介して、ストリーミングデータが格納されている送信パケットを受信する受信処理をコンピュータに行わせるプログラムにおいて、
前記送信パケットに格納されている前記ストリーミングデータの誤りを訂正するための誤り訂正データが格納されている誤り訂正パケットを受信する受信制御ステップと、
前記受信制御ステップにおいて受信された誤り訂正パケットの数が、前記ストリーミングデータの誤りを訂正するのに適正であるか否かを判定する判定ステップと
を含むことを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は送信装置および方法、受信装置および方法、記録媒体、並びにプログラムに関し、特に、通信網の状態に応じて、冗長データを含むデータの送信をより効率的に行うことができるようにした送信装置および方法、受信装置および方法、記録媒体、並びにプログラムに関する。
【背景技術】
【０００２】
昨今、インターネットなど、種々の通信媒体を介して、画像データまたは音声データを伝送して提供するサービスが一般に行われている。特に、近年、ダウンロード型の伝送方式のサービスに加えて、ストリーム型の伝送方式のサービスがより多く提供されるようになってきた。
【０００３】
ストリーム型の伝送方式のサービスにおいては、送信装置が、データを順次送信し、受信装置が、送信装置から送信されてくるデータを受信するとともに、これに並行して、受信されたデータを基に画像または音声を再生する。ストリーム型の伝送方式は、インターネット電話、遠隔テレビ会議、またはビデオオンデマンドなどのインターネットサービスに利用されている。
【０００４】
ストリーム型の伝送方式において、送信装置から送信されてくるデータを、一般に、ストリーミングデータと称する。
【０００５】
しかしながら、インターネットなどのデータの到達が保証されない伝送路を介して、動画像または音声のストリーミングデータを伝送すると、伝送負荷の増大により、パケットロスが生じる場合がある。
【０００６】
パケットロスが生じると、受信側において、再生される動画像が乱れたり、音声が途切れたりしてしまう。
【０００７】
この問題を解決するために、ストリーミングデータと共に冗長データを送信し、受信側でロスしたパケットのエラーを訂正する方法が用いられている。その一例として、FEC（Forward Error Correction）方式がある。FEC方式においては、複数のパケットからなる集合に対して、冗長パケットを複数生成して、集合と共に冗長パケットが送信される。受信側においては、集合に属するパケットにパケットロスが生じた場合、冗長パケットを用いて、ロスしたパケットのエラーが訂正される。
【０００８】
例えば、図１で示されるように、送信側は、データパケット１−１乃至データパケット１−５の５つのパケットからなる集合に、FECパケット２−１およびFECパケット２−２の２つの冗長パケットを付加して、受信側に送信する。FECパケット２−１およびFECパケット２−２は、データパケット１−１乃至データパケット１−５の所定の組み合わせに対して排他的論理和（exclusive-OR）の演算を適用することにより生成される。
【０００９】
例えば、伝送路において、データパケット１−２がロスされた場合、受信側において、データパケット１−１とFECパケット２−１とに排他的論理和の演算が適用されることにより、データパケット１−２が復元される。
【００１０】
図１で示される例において、FECパケット２−１およびFECパケット２−２の数と同じ数のロスしたパケットのエラーを訂正することができる。すなわち、データパケット１−１乃至データパケット１−５のうち、１つまたは２つがロスされても、そのパケットを回復することができる。
【００１１】
FEC方式によって、１フレームの集合に対して、冗長データを生成することが考えられるが、冗長データの生成をソフトウェアで行うと、非常に負荷の高い処理になってしまうという問題がある。
【００１２】
図２は、データパケット１−１乃至データパケット１−５からなる集合、およびFECパケット２−１およびFECパケット２−２の冗長パケットの送信の順序を説明する図である。図２の横方向は、時間を示す。
【００１３】
データパケット１−１乃至データパケット１−５の集合、およびFECパケット２−１およびFECパケット２−２の冗長パケットの送信において、最初に、データパケット１−１乃至データパケット１−５が順に送信され、その後、FECパケット２−１およびFECパケット２−２が順に送信される。
【００１４】
図３は、従来のFECパケットを付加した送信の処理を説明するフローチャートである。ステップＳ１１において、送信装置は、内蔵しているタイマを初期化する。
【００１５】
ステップＳ１２において、送信装置は、タイマの値を基に、タイマが終了したか否かを判定し、タイマが終了していない場合、ステップＳ１２に戻り、タイマが終了するまで、判定の処理を繰り返す。
【００１６】
ステップＳ１２において、タイマが終了したと判定された場合、１つのフレームに対応する期間が経過したので、ステップＳ１３に進み、送信装置は、供給された画像データをキャプチャする。ステップＳ１４において、送信装置は、キャプチャされた画像データを、エンコード（符号化）する。
【００１７】
ステップＳ１５において、送信装置は、符号化された画像データを格納するデータパケットであるRTP（Real-time Transport Protocol）パケットを生成する。ステップＳ１６において、送信装置は、RTPパケットを相手に送信する。
【００１８】
ステップＳ１７において、送信装置は、RTPパケットを基に、FECパケットを生成する。
ステップＳ１８において、送信装置は、FECパケットを相手に送信する。
【００１９】
ステップＳ１９において、送信装置は、RTPパケットに付加するタイムスタンプを更新する。ステップＳ２０において、送信装置は、内蔵しているタイマをセットして、ステップＳ１２に戻り、上述した処理を繰り返す。
【００２０】
また、送信側では、各パケットの情報ブロックを、先行パケットおよび後続パケットの情報ブロックとの共通部分を持つように構成し、誤り訂正符号にて符号化して送信し、共通部分の大きさは伝送路状態に応じて変化させ、一方、受信側では、その情報ブロックを復号および誤り訂正符号の機能によって誤り訂正し、復号に失敗した場合には、情報ブロックの共通部分を先行パケットのものと置換して、この共通部分が置換された情報ブロックを、再度、復号および誤り訂正するようにしているものもある（特許文献１参照）。
【００２１】
さらに、パケット伝送において、ネットワーク監視部によって監視されるネットワーク状況に基づいてエラー訂正制御を行うシステムもある（特許文献２参照）。このシステムにおいては、FECによるエラー制御、再送要求処理（ARQ）に基づくエラー制御等の態様をネットワークにおけるパケット損失、エラー発生状況に応じて動的に変更してパケット転送を実行し、RTT（Round-Trip Time）が短いならば、ARQによるエラー訂正選択、RTTが長い状況である場合には、ARQではなくFECによるエラー訂正を選択するといった動的なエラー訂正制御が可能となる。
【００２２】
【特許文献１】特開２０００−２２４２２６号公報
【００２３】
【特許文献２】特開２００３−１７９５８０号公報
【発明の開示】
【発明が解決しようとする課題】
【００２４】
しかしながら、常にストリーミングデータと共に冗長パケットを送信すると、無駄なデータを送信してしまうことになる。
【００２５】
また、通信網において、パケットロスがどの程度発生しているかが分からないので、冗長パケットをいくつ送信してよいか分からないという問題があった。
【課題を解決するための手段】
【００２６】
本発明の送信装置は、通信網が輻輳状態であるか否かを判定する判定手段と、送信パケットに格納されているストリーミングデータの誤りを訂正するための誤り訂正データが格納されている誤り訂正パケットを生成する生成手段と、輻輳状態でない旨の判定結果から輻輳状態である旨の判定結果に変化した場合、誤り訂正パケットの数を変更するように、生成手段における誤り訂正パケットの生成を制御する制御手段とを備えることを特徴とする。
【００２７】
制御手段は、輻輳状態であると判定された場合、生成手段に所定の数の誤り訂正パケットを生成させ、輻輳状態でないと判定された場合、生成手段の誤り訂正パケットの生成を抑制するように、生成手段における誤り訂正パケットの生成を制御するようにすることができる。
【００２８】
制御手段は、輻輳状態でない旨の判定結果から輻輳状態である旨の判定結果に変化した場合、直前の輻輳状態における送信パケットの受信の状態を基に、誤り訂正パケットの数を変更するように、生成手段における誤り訂正パケットの生成を制御するようにすることができる。
【００２９】
制御手段は、所定の期間における１または複数の送信パケットからなる誤り訂正の単位であって、所定の期間における１または複数の誤り訂正の単位の受信状態を基に、所定の期間における１または複数の誤り訂正の単位のいずれかにおいて、誤り訂正パケットの数が不足している場合、誤り訂正パケットの数を増加させるように、生成手段における誤り訂正パケットの生成を制御するようにすることができる。
【００３０】
判定手段は、第１の時刻から現在時刻までの期間における送信パケットの相手への伝送に要する遅延時間に依存する短期依存遅延時間と、第１の時刻より過去の第２の時刻から現在時刻までの期間における遅延時間に依存する長期依存遅延時間とを基に、輻輳状態であるか否かを判定するようにすることができる。
【００３１】
本発明の送信方法は、通信網が輻輳状態であるか否かを判定する判定ステップと、送信パケットに格納されているストリーミングデータの誤りを訂正するための誤り訂正データが格納されている誤り訂正パケットを生成する生成ステップと、輻輳状態でない旨の判定結果から輻輳状態である旨の判定結果に変化した場合、誤り訂正パケットの数を変更するように、生成ステップにおける誤り訂正パケットの生成を制御する制御ステップとを含むことを特徴とする。
【００３２】
本発明の記録媒体のプログラムは、通信網が輻輳状態であるか否かを判定する判定ステップと、送信パケットに格納されているストリーミングデータの誤りを訂正するための誤り訂正データが格納されている誤り訂正パケットを生成する生成ステップと、輻輳状態でない旨の判定結果から輻輳状態である旨の判定結果に変化した場合、誤り訂正パケットの数を変更するように、生成ステップにおける誤り訂正パケットの生成を制御する制御ステップとを含むことを特徴とする。
【００３３】
本発明のプログラムは、通信網が輻輳状態であるか否かを判定する判定ステップと、送信パケットに格納されているストリーミングデータの誤りを訂正するための誤り訂正データが格納されている誤り訂正パケットを生成する生成ステップと、輻輳状態でない旨の判定結果から輻輳状態である旨の判定結果に変化した場合、誤り訂正パケットの数を変更するように、生成ステップにおける誤り訂正パケットの生成を制御する制御ステップとをコンピュータに実行させることを特徴とする。
【００３４】
送信装置は、独立した装置であってもよいし、通信装置の送信処理を行うブロックであってもよい。
【００３５】
本発明の受信装置は、送信パケットに格納されているストリーミングデータの誤りを訂正するための誤り訂正データが格納されている誤り訂正パケットを受信する受信制御手段と、受信された誤り訂正パケットの数が、ストリーミングデータの誤りを訂正するのに適正であるか否かを判定する判定手段とを備えることを特徴とする。
【００３６】
判定手段は、受信された誤り訂正パケットの数が、ストリーミングデータの誤りを訂正するのに不足であるか、適正であるか、および過多であるかの何れであるかを判定するようにすることができる。
【００３７】
判定手段は、１または複数の送信パケットからなる誤り訂正の単位ごとに、受信された誤り訂正パケットの数が、ストリーミングデータの誤りを訂正するのに不足であるか、適正であるか、および過多であるかの何れであるかを判定し、所定の期間における１または複数の誤り訂正の単位に対する判定結果を基に、所定の期間における１または複数の誤り訂正の単位のいずれかにおいて、誤り訂正パケットの数が不足していると判定された場合、相手への通知に誤り訂正パケットの数が不足している旨を設定する設定手段をさらに設けることができる。
【００３８】
受信装置は、判定結果に基づく通知を格納するフィードバックパケットを生成する生成手段と、生成手段によって、生成されたフィードバックパケットの相手への送信を制御する送信制御手段とをさらに設けることができる。
【００３９】
本発明の受信方法は、送信パケットに格納されているストリーミングデータの誤りを訂正するための誤り訂正データが格納されている誤り訂正パケットを受信する受信制御ステップと、受信制御ステップにおいて受信された誤り訂正パケットの数が、ストリーミングデータの誤りを訂正するのに適正であるか否かを判定する判定ステップとを含むことを特徴とする。
【００４０】
本発明の記録媒体のプログラムは、送信パケットに格納されているストリーミングデータの誤りを訂正するための誤り訂正データが格納されている誤り訂正パケットを受信する受信制御ステップと、受信制御ステップにおいて受信された誤り訂正パケットの数が、ストリーミングデータの誤りを訂正するのに適正であるか否かを判定する判定ステップとを含むことを特徴とする。
【００４１】
本発明のプログラムは、送信パケットに格納されているストリーミングデータの誤りを訂正するための誤り訂正データが格納されている誤り訂正パケットを受信する受信制御ステップと、受信制御ステップにおいて受信された誤り訂正パケットの数が、ストリーミングデータの誤りを訂正するのに適正であるか否かを判定する判定ステップとをコンピュータに実行させることを特徴とする。
【００４２】
受信装置は、独立した装置であってもよいし、通信装置の受信処理を行うブロックであってもよい。
【００４３】
本発明の送信装置および方法、記録媒体、並びにプログラムにおいては、通信網が輻輳状態であるか否かが判定され、送信パケットに格納されているストリーミングデータの誤りを訂正するための誤り訂正データが格納されている誤り訂正パケットが生成され、輻輳状態でない旨の判定結果から輻輳状態である旨の判定結果に変化した場合、誤り訂正パケットの数を変更するように、誤り訂正パケットの生成が制御される。
【００４４】
本発明の受信装置および方法、記録媒体、並びにプログラムにおいては、送信パケットに格納されているストリーミングデータの誤りを訂正するための誤り訂正データが格納されている誤り訂正パケットが受信され、受信された誤り訂正パケットの数が、ストリーミングデータの誤りを訂正するのに適正であるか否かが判定される。
【発明の効果】
【００４５】
第１の本発明によれば、誤り訂正のための冗長データを送信することができる。また、第１の本発明によれば、通信網の状態に応じて、冗長データを含むデータの送信をより効率的に行うことができる。
【００４６】
第２の本発明によれば、受信したデータの誤りを訂正することができる。また、第２の本発明によれば、送信側において、通信網の状態に応じて、冗長データを含むデータの送信をより効率的に行うことができる。
【発明を実施するための最良の形態】
【００４７】
以下に本発明の実施の形態を説明するが、本明細書に記載の発明と、発明の実施の形態との対応関係を例示すると、次のようになる。この記載は、本明細書に記載されている発明をサポートする実施の形態が本明細書に記載されていることを確認するためのものである。従って、発明の実施の形態中には記載されているが、発明に対応するものとして、ここには記載されていない実施の形態があったとしても、そのことは、その実施の形態が、その発明に対応するものではないことを意味するものではない。逆に、実施の形態が発明に対応するものとしてここに記載されていたとしても、そのことは、その実施の形態が、その発明以外の発明には対応しないものであることを意味するものでもない。
【００４８】
さらに、この記載は、本明細書に記載されている発明の全てを意味するものではない。換言すれば、この記載は、本明細書に記載されている発明であって、この出願では請求されていない発明の存在、すなわち、将来、分割出願されたり、補正により出現、追加される発明の存在を否定するものではない。
【００４９】
本発明によれば、送信装置が提供される。この送信装置（例えば、図４のサーバ１２）は、通信網が輻輳状態であるか否かを判定する判定手段（例えば、図６の輻輳／非輻輳判定部１０５）と、送信パケット（例えば、図８のRTPパケット集合１８１−１）に格納されているストリーミングデータの誤りを訂正するための誤り訂正データが格納されている誤り訂正パケット（例えば、図８のFECパケット集合１８２−１）を生成する生成手段（例えば、図６のFECパケット生成部８４）と、輻輳状態でない旨の判定結果から輻輳状態である旨の判定結果に変化した場合、誤り訂正パケットの数を変更するように、生成手段における誤り訂正パケットの生成を制御する制御手段（例えば、図６のFEC送信制御部８６）とを備える。
【００５０】
この送信装置は、制御手段（例えば、図６のFEC送信制御部８６）が、輻輳状態であると判定された場合、生成手段（例えば、図６のFECパケット生成部８４）に所定の数の誤り訂正パケット（例えば、図８のFECパケット集合１８２−１）を生成させ、輻輳状態でないと判定された場合、生成手段の誤り訂正パケットの生成を抑制するように、生成手段における誤り訂正パケットの生成を制御するようにすることができる。
【００５１】
この送信装置は、制御手段（例えば、図６のFEC送信制御部８６）が、輻輳状態でない旨の判定結果から輻輳状態である旨の判定結果に変化した場合、直前の輻輳状態における送信パケットの受信の状態を基に、誤り訂正パケットの数を変更するように、生成手段（例えば、図６のFECパケット生成部８４）における誤り訂正パケットの生成を制御するようにすることができる。
【００５２】
この送信装置は、制御手段（例えば、図６のFEC送信制御部８６）が、所定の期間における１または複数の送信パケットからなる誤り訂正の単位（例えば、図８のFECブロック１７１−１）であって、所定の期間における１または複数の誤り訂正の単位の受信状態を基に、所定の期間における１または複数の誤り訂正の単位のいずれかにおいて、誤り訂正パケットの数が不足している場合、誤り訂正パケットの数を増加させるように、生成手段（例えば、図６のFECパケット生成部８４）における誤り訂正パケットの生成を制御するようにすることができる。
【００５３】
この送信装置は、判定手段（例えば、図６の輻輳／非輻輳判定部１０５）が、第１の時刻から現在時刻までの期間における送信パケットの相手への伝送に要する遅延時間に依存する短期依存遅延時間と、第１の時刻より過去の第２の時刻から現在時刻までの期間における遅延時間に依存する長期依存遅延時間とを基に、輻輳状態であるか否かを判定するようにすることができる。
【００５４】
また、本発明によれば、送信方法が提供される。この送信方法は、通信網が輻輳状態であるか否かを判定する判定ステップ（例えば、図１２のステップＳ８７の処理）と、送信パケットに格納されているストリーミングデータの誤りを訂正するための誤り訂正データが格納されている誤り訂正パケットを生成する生成ステップ（例えば、図１０のステップＳ５９の処理）と、輻輳状態でない旨の判定結果から輻輳状態である旨の判定結果に変化した場合、誤り訂正パケットの数を変更するように、生成ステップにおける誤り訂正パケットの生成を制御する制御ステップ（例えば、図１２のステップＳ９１の処理）とを含む。
【００５５】
また、本発明によれば、プログラムが提供される。このプログラムは、通信網が輻輳状態であるか否かを判定する判定ステップ（例えば、図１２のステップＳ８７の処理）と、送信パケットに格納されているストリーミングデータの誤りを訂正するための誤り訂正データが格納されている誤り訂正パケットを生成する生成ステップ（例えば、図１０のステップＳ５９の処理）と、輻輳状態でない旨の判定結果から輻輳状態である旨の判定結果に変化した場合、誤り訂正パケットの数を変更するように、生成ステップにおける誤り訂正パケットの生成を制御する制御ステップ（例えば、図１２のステップＳ９１の処理）とをコンピュータに実行させる。
【００５６】
このプログラムは、記録媒体（例えば、図５の磁気ディスク５１）に記録することができる。
【００５７】
本発明によれば、受信装置が提供される。この受信装置（例えば、図４のクライアント１４）は、送信パケット（例えば、図８のRTPパケット集合１８１−１）に格納されているストリーミングデータの誤りを訂正するための誤り訂正データが格納されている誤り訂正パケット（例えば、図８のFECパケット集合１８２−１）を受信する受信制御手段（例えば、図７の受信部１５２）と、受信された誤り訂正パケットの数が、ストリーミングデータの誤りを訂正するのに適正であるか否かを判定する判定手段（例えば、図７のFEC処理部１３５）とを備える。
【００５８】
この受信装置は、判定手段（例えば、図７のFEC処理部１３５）が、受信された誤り訂正パケットの数が、ストリーミングデータの誤りを訂正するのに不足であるか、適正であるか、および過多であるかの何れであるかを判定するようにすることができる。
【００５９】
この受信装置は、判定手段（例えば、図７のFEC処理部１３５）が、１または複数の送信パケットからなる誤り訂正の単位（例えば、図８のFECブロック１７１−１）ごとに、受信された誤り訂正パケット（例えば、図８のFECパケット集合１８２−１）の数が、ストリーミングデータの誤りを訂正するのに不足であるか、適正であるか、および過多であるかの何れであるかを判定し、所定の期間における１または複数の誤り訂正の単位に対する判定結果を基に、所定の期間における１または複数の誤り訂正の単位のいずれかにおいて、誤り訂正パケットの数が不足していると判定された場合、相手への通知に誤り訂正パケットの数が不足している旨を設定する設定手段（例えば、図７の通知FEC状態保持部１３７）を設けることができる。
【００６０】
この受信装置は、判定結果に基づく通知を格納するフィードバックパケットを生成する生成手段（例えば、図７のFECフィードバックパケット生成部１５３）と、生成手段によって、生成されたフィードバックパケットの相手への送信を制御する送信制御手段（例えば、図７の送信部１５１）とをさらに設けることができる。
【００６１】
また、本発明によれば、受信方法が提供される。この受信方法は、送信パケットに格納されているストリーミングデータの誤りを訂正するための誤り訂正データが格納されている誤り訂正パケットを受信する受信制御ステップ（例えば、図１８のステップＳ１７２の処理）と、受信制御ステップにおいて受信された誤り訂正パケットの数が、ストリーミングデータの誤りを訂正するのに適正であるか否かを判定する判定ステップ（例えば、図２２のステップＳ２２１の処理）とを含む。
【００６２】
また、本発明によれば、プログラムが提供される。このプログラムは、送信パケットに格納されているストリーミングデータの誤りを訂正するための誤り訂正データが格納されている誤り訂正パケットを受信する受信制御ステップ（例えば、図１８のステップＳ１７２の処理）と、受信制御ステップにおいて受信された誤り訂正パケットの数が、ストリーミングデータの誤りを訂正するのに適正であるか否かを判定する判定ステップ（例えば、図２２のステップＳ２２１の処理）とをコンピュータに実行させる。
【００６３】
このプログラムは、記録媒体（例えば、図５の磁気ディスク５１）に記録することができる。
【００６４】
本発明は、例えば、インターネット電話、遠隔テレビ会議システム、ライブ映像ストリーミング配信システム、またはテレビ電話などのリアルタイムにストリーミングデータを伝送する通信システムに適用できる。
【００６５】
図４は、本発明に係る通信システムの一実施の形態を示す図である。カメラ１１は、画像を撮像して、撮像した画像に対応する画像データをサーバ１２に供給する。例えば、カメラ１１は、動画像を撮像して、動画像に対応する画像データをサーバ１２に供給する。
【００６６】
画像データは、ストリーミングデータの一例である。ストリーミングデータは、音声のデータ、またはリアルタイム制御データなど、時間の経過に対応して順次送信または受信が要求されるデータであればよい。
【００６７】
サーバ１２は、カメラ１１から供給された画像データをパケットに格納して、パケットを通信網１３を介して、クライアント１４に送信する。サーバ１２は、画像を格納したパケットを訂正するための冗長データを生成して、冗長データを格納したパケットを通信網１３を介して、クライアント１４に送信する。
【００６８】
通信網１３は、有線または無線の、通信回線、ネットワーク、またはインターネットなどからなる伝送路であり、サーバ１２から送信されたパケットをクライアント１４まで伝送する。
【００６９】
クライアント１４は、通信網１３を介してサーバ１２から送信されてきた各種のパケットを受信する。
【００７０】
クライアント１４は、ストリーミングデータが格納されているパケットを正常に受信できなかった場合、冗長データを格納したパケットを基に、正常に受信できなかった画像データを格納するパケットのエラーを訂正する。
【００７１】
クライアント１４は、サーバ１２から通信網１３を介して送信されてきたパケットの受信状態をサーバ１２に通知する。サーバ１２は、通信網１３の伝送状態を取得する。例えば、サーバ１２は、往復遅延時間（RTT）を基に、通信網１３の輻輳状態を取得する。サーバ１２は、クライアント１４からの通知および通信網１３の伝送状態に基づいて、クライアント１４に送信する冗長データを格納したパケット数を変更する。
【００７２】
図５は、サーバ１２の構成の例を示すブロック図である。CPU（Central Processing Unit）３１は、ROM（Read Only Memory）３２、または記録部３８に記録されているプログラムに従って各種の処理を実行する。RAM（Random Access Memory）３３には、CPU３１が実行するプログラムやデータなどが適宜記憶される。これらのCPU３１、ROM３２、およびRAM３３は、バス３４により相互に接続されている。
【００７３】
CPU３１にはまた、バス３４を介して入出力インタフェース３５が接続されている。入出力インタフェース３５には、キーボード、マウス、スイッチなどよりなる入力部３６、ディスプレイ、スピーカ、ランプなどよりなる出力部３７が接続されている。CPU３１は、入力部３６から入力される指令に対応して各種の処理を実行する。
【００７４】
入出力インタフェース３５に接続されている記録部３８は、例えばハードディスクなどで構成され、CPU３１が実行するプログラムや各種のデータを記録する。通信部３９は、インターネット、その他のネットワークなどの通信網１３を介して、クライアント１４などの外部の装置と通信する。
【００７５】
また、通信部３９を介してプログラムを取得し、記録部３８に記録してもよい。
【００７６】
入出力インタフェース３５に接続されているドライブ４０は、磁気ディスク５１、光ディスク５２、光磁気ディスク５３、或いは半導体メモリ５４などが装着されたとき、それらを駆動し、そこに記録されているプログラムやデータなどを取得する。取得されたプログラムやデータは、必要に応じて記録部３８に転送され、記録される。
【００７７】
なお、クライアント１４は、サーバ１２と同様に構成されるので、その説明は省略する。
【００７８】
図６は、本発明に係るサーバ１２の一実施の形態の構成を示すブロック図である。
【００７９】
サーバ１２は、通信部３９、エンコーダ８１、バッファ８２、RTPパケット生成部８３、FECパケット生成部８４、RTT計測部８５、FEC送信制御部８６、FECパケット数増減状態保持部８７、FEC送信モード記憶部８８、およびFECパケット数保持部８９を含むように構成される。
【００８０】
エンコーダ８１は、カメラ１１から供給されたストリーミングデータの一例である画像データをエンコード（符号化）し、エンコードされた画像データをバッファ８２に供給する。
【００８１】
バッファ８２は、エンコーダ８１から供給された画像データを一時的に記憶する。
【００８２】
RTPパケット生成部８３は、バッファ８２からエンコードされた画像データを取得する。RTPパケット生成部８３は、取得した画像データをRTP方式のパケットに格納することにより、RTPパケットを生成し、生成したRTPパケットを通信部３９に供給する。
【００８３】
RTPパケットは、IETF RFC（Internet Engineering Task Force Request For Comments）１８８９で規定されているプロトコルであるRTPに基づく方式のパケットである。
【００８４】
また、RTPパケット生成部８３は、生成されたRTPパケットに格納されているRTPパケットのデータをFECパケット生成部８４に供給する。
【００８５】
FECパケット生成部８４は、FEC送信モード記憶部８８に記憶されているFEC送信モードフラグを参照し、FEC送信モードである場合、RTPパケット生成部８３から供給されたRTPパケットのデータを基に、所定の誤り訂正方式により、FECパケット数保持部８９から供給されたFECパケット数で示される数のFECパケットを生成する。FECパケット生成部８４は、生成したFECパケットを通信部３９に供給する。
【００８６】
FECパケット生成部８４は、FEC送信モードでない場合、FECパケットを生成しない。
【００８７】
通信部３９は、各種のパケットを送信する送信部１０１をよび各種のパケットを受信する受信部１０２を備えており、通信網１３を介してパケットの送受信を行う。
【００８８】
通信部３９の送信部１０１は、RTPパケット生成部８３から供給されたRTPパケットおよびFECパケット生成部８４から供給されたFECパケットを、通信網１３を介して、クライアント１４に送信する。
【００８９】
より詳細には、通信部３９の送信部１０１は、RTPパケット生成部８３から供給されたRTPパケットおよびFECパケット生成部８４から供給されたFECパケットを一時的に保持し、同一のFECブロックＩＤを含むRTPパケットおよびFECパケットを１つのFECブロックとして、例えば、バースト転送方式などの所定の方式により通信網１３を介して、クライアント１４に送信する。FECブロックを特定するFECブロックＩＤの詳細は後述する。
【００９０】
また、通信部３９の送信部１０１は、RTT計測部８５から供給されたRTT計測パケットを、通信網１３を介して、クライアント１４あてに送信する。
【００９１】
通信部３９の受信部１０２は、通信網１３を介して、クライアント１４から送信されてきたRTT計測パケットをRTT計測部８５に供給する。また、通信部３９の受信部１０２は、通信網１３を介して、クライアント１４から送信されてきたFECフィードバックパケットをFEC送信制御部８６に供給する。
【００９２】
RTT計測部８５は、RTT計測パケットを生成し、生成したRTT計測パケットを通信部３９に供給する。RTT計測部８５は、通信部３９に受信され、通信部３９から供給されたRTT計測パケットを基に、遅延時間（RTT）を計算する。
【００９３】
RTT計測部８５は、長期依存RTTを計算する長期依存RTT演算部１０３および短期依存RTTを計算する短期依存RTT演算部１０４を備えている。RTT計測部８５の長期依存RTT演算部１０３は、RTT計測部８５によって計算された遅延時間を基に、長期依存RTTを計算する。RTT計測部８５の短期依存RTT演算部１０４は、RTT計測部８５によって計算された遅延時間を基に、短期依存RTTを計算する。長期依存RTTおよび短期依存RTTの詳細は、後述する。
【００９４】
さらに、RTT計測部８５は、長期依存RTT演算部１０３によって計算された長期依存RTTおよび短期依存RTT演算部１０４によって計算された短期依存RTTをFEC送信制御部８６に供給する。
【００９５】
FEC送信制御部８６は、FECパケット生成部８４のFECパケットの生成を制御する。FEC送信制御部８６は、通信網１３が、輻輳状態であるか否かを判定する輻輳／非輻輳判定部１０５を備えている。
【００９６】
FEC送信制御部８６の輻輳／非輻輳判定部１０５は、RTT計測部８５から供給された長期依存RTTおよび短期依存RTTを基に、通信網１３が輻輳状態であるか否かを判定し、輻輳状態であるか否かの判定結果を記憶する。FEC送信制御部８６は、判定結果が、輻輳状態である旨の判定結果であった場合、FEC送信モード記憶部８８のFEC送信モードフラグをセットし（例えば、“１”を設定する）、輻輳状態でない旨の判定結果であった場合、すなわち非輻輳状態である旨の判定結果であった場合、FEC送信モード記憶部８８のFEC送信モードフラグをリセットする（例えば、“０”を設定する）。
【００９７】
また、FEC送信制御部８６は、通信部３９が受信し、通信部３９から供給されたFECフィードバックパケットを基に、FECパケット数増減状態保持部８７に保持されているFECパケット数増減状態を更新する。ここで、FECパケット数増減状態は、FECパケットの数を増加させるか、減少させるか、または維持するかを示す状態である。FECパケット数増減状態の変更の処理の詳細は、後述する。
【００９８】
さらに、FEC送信制御部８６は、FECパケット数増減状態保持部８７に保持されているFECパケット数増減状態を読み込み、FECパケット数保持部８９に保持されているFECパケット数を変更する。FECパケット数の変更の処理の詳細は、後述する。
【００９９】
FECパケット数増減状態保持部８７は、FEC送信制御部８６から供給されたFECパケット数増減状態を保持（記憶）する。
【０１００】
FEC送信モード記憶部８８は、FEC送信モードであるか否かを示すFEC送信モードフラグを記憶する。セットされている（例えば、“１”が設定されている）FEC送信モードフラグは、FEC送信モードであることを示し、リセットされている（例えば、“０”が設定されている）FEC送信モードフラグは、FEC送信モードでないことを示す。FEC送信モードである場合、FECパケット生成部８４は、FECパケットを生成し、FEC送信モードでない場合、FECパケット生成部８４は、FECパケットを生成しない。
【０１０１】
FEC送信モード記憶部８８に記憶されているFEC送信モードフラグは、通信網１３が輻輳状態である場合、FEC送信制御部８６によって、セットされる。また、通信網１３が非輻輳状態である場合、FEC送信モード記憶部８８に記憶されているFEC送信モードフラグは、FEC送信制御部８６によって、リセットされる。
【０１０２】
すなわち、通信網１３が輻輳状態である場合、FEC送信モードになるので、FECパケットが生成されて、FECパケットが送信され、通信網１３が輻輳状態でない場合、FEC送信モードではないので、FECパケットは生成されず、FECパケットは送信されない。
【０１０３】
FECパケット数保持部８９は、FEC送信制御部８６から供給されたFECパケット数を保持する。FECパケット数保持部８９は、FEC送信制御部８６からFECパケット数を供給されると、供給されたFECパケット数をFECパケット生成部８４に供給する。
【０１０４】
なお、FECパケット数増減状態保持部８７、FEC送信モード記憶部８８、およびFECパケット数保持部８９が、FECパケット生成部８４に含まれる構成とすることも可能である。
【０１０５】
図７は、本発明に係るクライアント１４の一実施の形態の構成を示すブロック図である。
【０１０６】
クライアント１４は、通信部１３１、RTP処理部１３２、バッファ１３３、デコーダ１３４、FEC処理部１３５、FECブロック情報保持部１３６、通知FEC状態保持部１３７、およびRTT計測部１３８を含むように構成される。
【０１０７】
通信部１３１は、クライアント１４の通信部３９に対応し、パケットの受信を制御する受信部１５１およびパケットの送信を制御する送信部１５２を備えている。通信部１３１の受信部１５１は、通信網１３を介して送信されてきた各種のパケットを受信し、受信したパケットをRTP処理部１３２またはRTT計測部１３８に供給する。通信部１３１の送信部１５２は、通信網１３を介して、各種のパケットを送信する。
【０１０８】
RTP処理部１３２は、通信部１３１に受信され、通信部１３１から供給されたRTPパケットおよびFECパケットを検査する。RTP処理部１３２は、正常なFECパケットが受信された場合、受信されたFECパケットをFEC処理部１３５に供給するとともに、FECヘッダ情報をFECブロック情報保持部１３６に供給する。RTP処理部１３２は、正常ではないFECパケットが受信された場合、受信されたFECパケットを破棄する。
【０１０９】
また、RTP処理部１３２は、正常なRTPパケットが受信された場合、受信されたRTPパケットを一時的に保持すると共に、RTPヘッダ情報をFECブロック情報保持部１３６に供給する。RTP処理部１３２は、正常ではないRTPパケットが受信された場合、受信したRTPパケットに含まれるFECブロックＩＤと同一のFECブロックＩＤを含むFECパケットを受信したとき、正常ではないRTPパケットの復元を指示する信号をFEC処理部１３５に供給する。
【０１１０】
RTP処理部１３２は、正常ではないRTPパケットが受信された場合、受信したRTPパケットに含まれるFECブロックＩＤと同一のFECブロックＩＤを含むFECパケットを受信していないとき、RTPパケットを破棄する。
【０１１１】
RTP処理部１３２は、RTPパケットの復元を指示する信号をFEC処理部１３５に供給しなかった場合、パケットの受信が完了すると、一時的に保持しているRTPパケットをバッファ１３３に供給する。
【０１１２】
また、RTP処理部１３２は、RTPパケットの復元を指示する信号をFEC処理部１３５に供給した場合、パケットの受信が完了し、FEC処理部１３５から復元されたRTPパケットが供給されてから、保持しているRTPパケットおよび復元されたRTPパケットをバッファ１３３に供給する。
【０１１３】
さらに、RTP処理部１３２は、RTPパケットまたはFECパケットが正常に受信された場合、FECブロック情報保持部１３６に保持されているFECブロック情報であるFECブロック情報テーブルの受信パケット数をインクリメントする。RTP処理部１３６は、受信されたRTPパケットまたはFECパケットに含まれるFECブロックＩＤが変化した場合、FECブロック情報保持部１３６に保持されているFECブロック情報を更新する。FECブロック情報テーブルの詳細およびFECブロック情報更新の処理の詳細は後述する。
【０１１４】
バッファ１３３は、RTP処理部１３２から供給されたRTPパケットを一時的に記憶する。
【０１１５】
デコーダ１３４は、バッファ１３３に記憶されているRTPパケットを順に取得して、取得したRTPパケットから画像データを抽出する。そして、デコーダ１３４は、エンコーダ８１に対応する復号方式で、抽出された画像データをデコード（復号）して、デコードされた画像データを出力する。
【０１１６】
FEC処理部１３５は、FECフィードバックパケットを生成するFECフィードバックパケット生成部１５３を備えている。
【０１１７】
FEC処理部１３５は、RTP処理部１３２から供給されたFECパケットを一時的に保持する。FEC処理部１３５は、正常ではないRTPパケットの復元を指示する信号がRTP処理部１３２から供給された場合、FECパケットを基に、RTPパケットを復元し、復元したRTPパケットをRTP処理部１３２に供給する。
【０１１８】
より具体的には、例えば、FEC処理部１３５は、RTP処理部１３２に一時的に記憶されている正常に受信されたRTPパケットであって復元の処理に要するRTPパケットをRTP処理部１３２から取得して、取得したRTPパケットおよびFECパケットを基に、正常に受信されなかったRTPパケットを復元する。
【０１１９】
また、FEC処理部１３５は、正常ではないRTPパケットの復元を指示する信号がRTP処理部１３２から供給されなかった場合、パケットの受信が完了すると、保持しているFECパケットを破棄する。
【０１２０】
なお、RTP処理部１３２がRTPパケットの復元を行うような構成としてもよい。
【０１２１】
FEC処理部１３５は、FECブロック情報保持部１３６に保持されているFECブロック情報テーブルに記録されているFECブロックＩＤが変化した場合、FECブロック情報を基に、FECブロック情報保持部１３６に保持（記録）されている、FECパケットの数が適正であるか否かを示すFECブロック状態を更新する。FEC処理部１３５は、FECブロック情報保持部１３６に保持されているFECブロック情報を読み込み、通知FEC状態保持部１３７に保持されている通知FEC状態を更新する。FECブロック状態更新の処理および通知FEC状態更新の処理の詳細は後述する。
【０１２２】
また、FEC処理部１３５のFECフィードバックパケット生成部１５３は、通知FEC状態保持部１３７に保持されている通知FEC状態を基に、FECフィードバックパケットを生成し、FEC処理部１３５は、生成されたFECフィードバックパケットを通信部１３１に供給する。FECフィードバックパケットの詳細は後述する。
【０１２３】
FECブロック情報保持部１３６は、RTP処理部１３２およびFEC処理部１３５によって更新されるFECブロック情報を保持（記録）している。
【０１２４】
通知FEC状態保持部１３７は、FEC処理部１３５によって更新される通知FEC状態を保持している。
【０１２５】
RTT計測部１３８は、通信部１３１に受信され、通信部１３１から供給されたRTT計測パケットを取得する。RTT計測部１３８は、取得したRTT計測パケットのデータ部と同じデータ部を含むRTT計測パケットを生成し、生成したRTT計測パケットを通信部１３１に供給する。
【０１２６】
なお、図６または図７で示されるサーバ１２またはクライアント１４の機能は、ハードウェアにより実現するようにしてもよく、ソフトウェア（プログラム）により実現するようにしてもよい。
【０１２７】
次に、図８のタイムチャートを参照して、サーバ１２によるFECブロック送信の処理を説明する。
【０１２８】
図８における横方向は、時間を示す。図８において、時刻ｔ１から時刻ｔ２までの期間D１および時刻ｔ３から時刻ｔ４までの期間D３は、通信網１３が輻輳状態である期間を示す。また、時刻ｔ２から時刻ｔ３までの期間D２は、通信網１３が非輻輳状態である期間を示す。
【０１２９】
サーバ１２は、通信網１３が輻輳状態である場合、FECパケット集合を含むFECブロックを送信し、通信網１３が非輻輳状態である場合には、FECパケット集合を含まないFECブロックを送信する。さらに、サーバ１２は、通信網１３を介して、クライアント１４から受信したFECフィードバックパケットを基に、FECパケット集合に含まれるFECパケットの数を変更する。すなわち、時刻ｔ１１において、通信網１３が輻輳状態であるため、サーバ１２は、同一のFECブロックＩＤを含むRTPパケットおよびFECパケットを１つのFECブロックとしてクライアント１４あてに送信する。
【０１３０】
より詳細に説明すれば、サーバ１２は、例えば、図８において、１つのフレームを再生するための画像データであるストリーミングデータをFECブロック１７１−１の４つのRTPパケットに格納する。また、サーバ１２は、そのフレームを再生するためのストリーミングデータの冗長データをFECブロック１７１−１の２つのFECパケットに格納する。そして、サーバ１２は、そのフレームを再生するためのストリーミングデータが格納された、４つのRTPパケットからなるRTPパケット集合１８１−１および２つのFECパケットからなるFECパケット集合１８２−１をFECブロック１７１−１として通信網１３を介してクライアント１４あてに送信する。
【０１３１】
クライアント１４は、通信網１３を介して、サーバ１２から送信されてきたFECブロック１７１−１を時刻ｔ２１に受信する。
【０１３２】
同様に、サーバ１２は、次の１つのフレームを再生するための画像データであるストリーミングデータをFECブロック１７１−２の４つのRTPパケットに格納する。また、サーバ１２は、そのフレームを再生するためのストリーミングデータの冗長データをFECブロック１７１−２の２つのFECパケットに格納する。そして、サーバ１２は、そのフレームを再生するためのストリーミングデータが格納された、４つのRTPパケットからなるRTPパケット集合１８１−２および２つのFECパケットからなるFECパケット集合１８２−２をFECブロック１７１−２として通信網１３を介してクライアント１４あてに送信する。
【０１３３】
サーバ１２は、さらに次の１つのフレームを再生するための画像データであるストリーミングデータをFECブロック１７１−３の４つのRTPパケットに格納する。また、サーバ１２は、そのフレームを再生するためのストリーミングデータの冗長データをFECブロック１７１−３の２つのFECパケットに格納する。そして、サーバ１２は、そのフレームを再生するためのストリーミングデータが格納された、４つのRTPパケットからなるRTPパケット集合１８１−３および２つのFECパケットからなるFECパケット集合１８２−３をFECブロック１７１−３として通信網１３を介してクライアント１４あてに送信する。
【０１３４】
時刻ｔ２において、通信網１３が輻輳状態から非輻輳状態に変化したので、時刻ｔ２以降において、サーバ１２は、通信網１３を介して、クライアント１４あてにFECパケットを含まないFECブロックを送信する。
【０１３５】
サーバ１２は、FECブロック１７１−３のフレームの次の１つのフレームを再生するための画像データであるストリーミングデータをFECブロック１７１−４の４つのRTPパケットに格納し、４つのRTPパケットからなるRTPパケット集合１８１−４をFECブロック１７１−４として通信網１３を介してクライアント１４あてに送信する。サーバ１２は、さらに次の１つのフレームを再生するための画像データであるストリーミングデータをFECブロック１７１−５の４つのRTPパケットに格納し、４つのRTPパケットからなるRTPパケット集合１８１−５をFECブロック１７１−５として、通信網１３を介してクライアント１４あてに送信する。サーバ１２は、さらに次の１つのフレームを再生するための画像データであるストリーミングデータをFECブロック１７１−６の４つのRTPパケットに格納し、４つのRTPパケットからなるRTPパケット集合１８１−６をFECブロック１７１−６として、通信網１３を介してクライアント１４あてに送信する。
【０１３６】
時刻ｔ３において、通信網１３が非輻輳状態から輻輳状態に変化したので、時刻ｔ３以降において、サーバ１２は、通信網１３を介して、ストリーミングデータとともに冗長データをクライアント１４あてに送信する。
【０１３７】
すなわち、サーバ１２は、FECブロック１７１−６のフレームの次の１つのフレームを再生するための画像データであるストリーミングデータをFECブロック１７１−７の４つのRTPパケットに格納する。また、サーバ１２は、そのフレームを再生するためのストリーミングデータの冗長データをFECブロック１７１−７の２つのFECパケットに格納する。そして、サーバ１２は、そのフレームを再生するためのストリーミングデータが格納された、４つのRTPパケットからなるRTPパケット集合１８１−７および２つのFECパケットからなるFECパケット集合１８２−４をFECブロック１７１−７として通信網１３を介してクライアント１４あてに送信する。
【０１３８】
時刻ｔ２１から時刻ｔ２３までの期間Ｔ１、時刻ｔ２３から時刻ｔ２４までの期間Ｔ２、時刻ｔ２４から時刻ｔ２５までの期間Ｔ３、および時刻ｔ２５から時刻ｔ２６までの期間Ｔ４のそれぞれは、クライアント１４におけるFECフィードバックパケット送信処理を実行する時間間隔であり、タイマで定まる。すなわち、クライアント１４は、タイマが終了する時刻である時刻ｔ２３、時刻ｔ２４、時刻ｔ２５、および時刻ｔ２６のそれぞれの時刻にFECフィードバックパケットを生成し、生成したFECフィードバックパケットを、通信網１３を介して、サーバ１２あてに送信する。
【０１３９】
以下、FECブロック１７１−１乃至FECブロック１７１−７を個々に区別する必要がないとき、単にFECブロック１７１と称する。同様に、以下、RTPパケット集合１８１−１乃至RTPパケット集合１８１−７を個々に区別する必要がないとき、単にRTPパケット集合１８１と称し、FECパケット集合１８２−１乃至FECパケット集合１８２−４を個々に区別する必要がないとき、単にFECパケット集合１８２と称する。
【０１４０】
クライアント１４は、通信網１３を介して、サーバ１２から送信されてきたFECブロック１７１を受信すると、FECブロック情報を記録する。FECブロック情報は、例えば、図９で示すFECブロック情報テーブルに記録される。
【０１４１】
クライアント１４は、FECブロック１７１を受信すると、FECブロック１７１に固有の識別番号であるFECブロックＩＤ、FECブロック１７１に含まれるRTPパケットの数を示すオリジナルデータパケット数、FECブロック１７１に含まれるRTPパケット数およびFECパケット数の合計である総パケット数、正常に受信されたパケット数を示す受信パケット数、並びに受信されたFECパケットの数がロスパケットを復元する場合に、不足であるか、適正であるか、あるいは過多であるかを表すFECブロック状態をそれぞれFECブロック情報テーブルに記録する。
【０１４２】
図９は、FECブロック情報テーブルの例を示す図である。
【０１４３】
ここで、例えば、図９において、FECブロックＩＤ１のFECブロック１７１は、総パケット数が６であるのに対して、受信パケット数が４であり、２つのパケットをロスしている。また、FECブロックＩＤ１のFECブロック１７１の総パケット数が６であるのに対して、オリジナルパケット数は４であるから、FECブロックＩＤ１のFECブロック１７１には、２つのFECパケットが含まれることが分かる。
【０１４４】
FECパケット１つにつきRTPパケット１つを復元できるので、FECブロックＩＤ１のFECブロック１７１に含まれる２つのFECパケットを用いることにより、２つのロスパケットを回復することができる。したがって、FECブロックＩＤ１に含まれるFECパケットの数は、過多でもなく、不足でもないので、FECブロック状態は、適正状態に設定される。
【０１４５】
同様に、FECブロックＩＤ２のFECブロック１７１においては、FECブロック１７１に含まれるFECパケットが２つであるのに対して、ロスパケットは３つであるから、３つのロスパケットのうち、１つのロスパケットは回復することができない。すなわち、FECパケットが１つ不足しているので、FECブロック状態は、不足状態に設定される。
【０１４６】
また、FECブロックＩＤ３のFECブロック１７１においては、FECブロック１７１に含まれるFECパケットが、２つであるのに対して、ロスパケットは０であるから、２つのFECパケットが用いられずに破棄されることになる。したがって、FECパケットが２つ過多であるので、FECブロック状態は、過多状態に設定される。
【０１４７】
図８のタイムチャートの説明に戻り、例えば、時刻ｔ２２において、クライアント１４は、FECブロック１７１−２において３つのパケットのパケットロスを検知する。そして、クライアント１４は、FECブロック１７１−２のFECブロック状態を不足状態に設定する。時刻ｔ２３に期間Ｔ１が経過したので（タイマが終了したので）、クライアント１４は、時刻ｔ２１から時刻ｔ２３までに受信されたFECブロック１７１のそれぞれのFECブロック状態を基に、例えば、FECパケットが不足している旨のFECフィードバックパケットを生成し、生成されたFECフィードバックパケットを、通信網１３を介して、サーバ１２あてに送信する。FECフィードバックパケットの詳細は、後述する。
【０１４８】
また、クライアント１４は、期間Ｔ２および期間Ｔ３のそれぞれの終了時刻ｔ２４および時刻ｔ２５のそれぞれにおいて、通信網１３を介して、サーバ１２あてにFECフィードバックパケットを送信する。
【０１４９】
時刻ｔ３において、通信網１３が非輻輳状態から輻輳状態に変化したので、サーバ１２は、時刻ｔ１から時刻ｔ３までに、通信網１３を介して、クライアント１４から受信されたフィードバックパケットを基に、FECブロック１７１に含まれるFECパケットの数を変更し、例えば、時刻ｔ１２に３つのFECパケットが含まれるFECブロック１７１−７を、通信網１３を介して、クライアント１４あてに送信する。
【０１５０】
このように、サーバ１２は、通信網１３における輻輳状態およびクライアント１４から送信されてきたFECフィードバックパケットを基に、FECブロック１７１に含まれるFECパケットの数を変更し、FECブロック１７１を送信する。
【０１５１】
次に、図１０のフローチャートを参照して、サーバプログラムを実行するサーバ１２によるデータ送信の処理を説明する。
【０１５２】
ステップＳ５１において、サーバ１２は、送信の処理に必要なデータを初期化する。例えば、ステップＳ５１において、エンコーダ８１は、内蔵しているタイマの値を0msにセットし、RTPパケット生成部８３は、タイムスタンプおよびシーケンス番号を初期化し、FECブロックＩＤの値を１に設定する。
【０１５３】
ステップＳ５２において、エンコーダ８１は、内蔵しているタイマの値を基に、タイマが終了したか否かを判定し、タイマが終了していない場合、ステップＳ５２に戻り、タイマが終了したと判定されるまで、判定の処理を繰り返す。
【０１５４】
ステップＳ５２において、タイマが終了したと判定された場合、処理はステップＳ５３に進む。
【０１５５】
例えば、画像データのフレームの数が１秒当たり３０である場合、タイマが時間の経過に対応して値を増加させるとき、ステップＳ５２において、エンコーダ８１は、33msなどの所定の値とタイマの値を比較することによりタイマが終了したか否かを判定する。
【０１５６】
例えば、ステップＳ５１において、タイマの値を33msにセットし、タイマの値が時間の経過に対応して値を減少させるとき、エンコーダ８１は、タイマの値と、0msとを比較することによりタイマが終了したか否かを判定する。
【０１５７】
この場合における、タイマの値と比較される0msまたは33msは、フレームの数が１秒当たり３０である場合の例であり、本発明を限定するものではない。
【０１５８】
以下に説明するタイマに関する処理において、同様である。
【０１５９】
ステップＳ５３において、エンコーダ８１は、カメラ１１から供給された画像データを１フレーム分キャプチャする。例えば、ステップＳ５３において、エンコーダ８１は、カメラ１１から供給された画像データを順次取得して、取得した画像データのうち、１フレーム分をキャプチャする。
【０１６０】
ステップＳ５４において、エンコーダ８１は、キャプチャされた画像データをエンコードする。例えば、ステップＳ５４において、エンコーダ８１は、キャプチャされた画像データをMPEG（Moving Picture Experts Group）１、２、４、７、もしくは２１、JPEG（Joint Photographic Experts Group）、JPEG２０００、またはモーションJPEGなどの方式によりエンコードする。
【０１６１】
ステップＳ５５において、エンコーダ８１は、エンコードされた画像データをバッファ８２に供給して、バッファ８２にエンコードされた画像データを格納（記憶）させる。
【０１６２】
ステップＳ５６において、RTPパケット生成部８３は、デコードされた画像データをバッファ８２から取得し、取得した画像データを格納するRTPパケットを生成する。
【０１６３】
図１１は、RTPパケットを説明する図である。RTPパケットの先頭には、図１１において“Ｖ”で表される、２ビットのバージョン情報が配置される。バージョン情報は、RTPパケットのバージョンを示す。
【０１６４】
バージョン情報の次に図１１中の“Ｐ”で表される１ビットのパディングが配置され、パディングに続いて、１ビットの拡張情報がRTPパケットに配置される。拡張情報は、図１１において、“Ｘ”で表される。拡張情報は、RTPパケットに拡張ヘッダを配置する場合に、所定の値に設定される。
【０１６５】
拡張情報に続いて、CSRC（Contributing Source）カウントがRTPパケットに配置される。CSRCカウントは、図１１中において、“ＣＣ”で表される。CSRCカウントは、CSRC識別子の数を表す。
【０１６６】
CSRCカウントに続いて配置される、１ビットのメーカー情報は、プロファイルによって定義される。メーカー情報は、図１１中において“ｍ”で表される。
【０１６７】
メーカー情報に続いて配置される、７ビットのペイロードタイプは、RTPパケットのフォーマットを定義するための情報である。ペイロードタイプは、図１１中において、“ＰＴ”で表される。RTPパケットにおいて、ペイロードタイプは、３３とされる。
【０１６８】
シーケンス番号は、ペイロードタイプの次に配置される、１６ビットの情報である。シーケンス番号は、RTPパケットの再生の順番を示す番号であり、送信の度に、１ずつ増える。
【０１６９】
シーケンス番号の次に配置される、３２ビットのタイムスタンプは、そのRTPパケットに格納されているストリーミングデータの最初のオクテットがサンプルされた時刻を示す情報である。また、タイムスタンプにより、受信側においてRTPパケットの展開時に処理時間の制御が実行され、リアルタイム画像、または音声の再生制御を行うことが可能となる。タイムスタンプは、１つの画像フレームに属する複数のRTPパケットに共通のタイムスタンプが設定される。
【０１７０】
SSRC（Synchronization Source）識別子は、タイムスタンプの次に配置される３２ビットの情報であって、RTPパケットに格納されるストリーミングデータのソースを示す。
【０１７１】
RTPパケットにおいて、SSRC識別子の次には、FECブロックＩＤが配置される。FECブロックＩＤは、サーバ１２が通信網１３を介して、クライアント１４あてに送信するRTPパケットおよびFECパケットの集合であるFECブロック１７１を識別する番号である。例えば、図８において、RTPパケット集合１８１に属するRTPパケットには、同一のFECブロックＩＤが付与される。なお、１つのFECブロック１７１のFECパケット集合１８２に属するFECパケットには、そのFECブロック１７１のRTPパケット集合１８１に属するRTPパケットのFECブロックＩＤと同一のFECブロックＩＤが格納される。
【０１７２】
FECブロックＩＤに続いて、総パケット数がRTPパケットに配置される。総パケット数は、図１１において“Ｎ”で表され、１つのFECブロック１７１に含まれるRTPパケット数およびFECパケット数の合計である。
【０１７３】
RTPパケットにおいて、総パケット数の次には、オリジナルデータパケット数が配置される。オリジナルデータパケット数は、図１１において、“Ｋ”で表され、１つのFECブロック１７１に含まれるRTPパケットの数である。
【０１７４】
オリジナルデータパケット数の次に、図１１中の“Ｒ”で表される冗長パケット数が配置される。冗長パケット数は、１つのFECブロックに含まれるFECパケットの数を表す。
【０１７５】
冗長パケット数に続いて、データ量を調整するための、図１１中の“Ｐ”で表されるパディングが配置される。パディングに続いてストリーミングデータが格納される。図１１において、“Original Data”は、ストリーミングデータを示す。
【０１７６】
なお、FECパケットは、RTPパケットと同様に構成することができる。この場合、FECパケットのペイロードタイプは、例えば、３４とされる。
【０１７７】
図１０に戻り、ステップＳ５７において、RTPパケット生成部８３は、生成されたRTPパケットを通信部３９に供給し、通信部３９は、供給されたRTPパケットを、通信網１３を介してクライアント１４あてに送信する。
【０１７８】
ステップＳ５８において、FECパケット生成部８４は、FEC送信モードであるか否かを判定する。例えば、ステップＳ５８において、FECパケット生成部８４は、FEC送信モード記憶部８８のFEC送信モードフラグのセットまたはリセットの設定を基に、FEC送信モードであるか否かを判定する。
【０１７９】
ステップＳ５８において、FEC送信モードであると判定された場合、通信網１３は輻輳状態であるため、パケットロスが発生する可能性が高い。そこで、FECパケットをクライアント１４あてに送信するため、処理は、ステップＳ５９に進む。
【０１８０】
ステップＳ５９において、FECパケット生成部８４は、RTPパケット生成部８３から供給されたRTPパケットのデータを基に、FECパケット数保持部８９から供給されたFECパケット数で示される数のFECパケットを生成する。
【０１８１】
例えば、ステップＳ５９において、FECパケット生成部８４は、RTPパケット生成部８３から供給されたRTPパケットに格納されるデータに排他的論理和の演算を適用することにより、FECパケットのデータを生成し、生成したデータに所定のヘッダを付加することにより、FECパケットを生成する。
【０１８２】
ここで、FECパケットに付加されるヘッダは、例えば、図１１で示されるRTPパケットのヘッダと同じフォーマットのヘッダが付加される。RTPパケットおよびFECパケットの識別は、FECパケットのヘッダにおいて、例えば、図１１中の“Ｘ”で表される拡張情報を１にすることで、RTPパケットおよびFECパケットが識別される。また、例えば、FECパケットにおいて、ペイロードタイプは、３４とされ、FECパケットにおいて、図１１中の“Original Data”で表される領域には、誤り訂正のための冗長データが格納される。
【０１８３】
なお、FECパケット生成部８４によって生成されるFECパケットの誤り訂正方式（冗長データの方式）は、排他的論理和の演算によるものに限らず、例えば、ハミング符号などの線形符号、巡回符号、BCH（Bose‐Chaudhuri‐Hocquenghem）符号もしくはリードソロモン（Reed Solomon）符号などの代数的符号、または多数決論理符号などいずれの方式であってもよい。
【０１８４】
ステップＳ６０において、FECパケット生成部８４は、生成されたFECパケットを通信部３９に供給し、通信部３９は、通信網１３を介して、供給されたFECパケットをクライアント１４あてに送信し、手続は、ステップＳ６１に進む。
【０１８５】
より詳細には、通信部３９は、ステップＳ５７において、RTPパケット生成部８３から供給されたRTPパケットを一時的に保持する。そして、ステップＳ６０において、通信部３９は、保持しているRTPパケットに含まれるFECブロックＩＤと同一のFECブロックＩＤを含むFECパケットがFECパケット生成部８４から供給されると、保持しているRTPパケットおよびFECパケット生成部８４から供給されたFECパケットを１つのFECブロック１７１として、通信網１３を介して、クライアント１４あてに送信する。
【０１８６】
例えば、図８の時刻ｔ１から時刻ｔ２において、サーバ１２は、通信網１３が輻輳状態（FECパケット送信モード）であるので、RTPパケットとともにFECパケットを、通信網１３を介して、クライアント１４あてに送信する。
【０１８７】
一方、ステップＳ５８において、FEC送信モードでないと判定された場合、通信網１３は、非輻輳状態であるため、パケットロスが発生する可能性は低い。そこで、FECパケットのクライアント１４への送信を抑制するため、ステップＳ５９およびステップＳ６０の処理はスキップされ、手続は、ステップＳ６１に進む。
【０１８８】
なお、ステップＳ５８において、FEC送信モードでないと判定された場合、FECパケットの送信は、抑制されるので、通信部３９は、ステップＳ５７において、RTPパケット生成部８３から供給されたRTPパケットを１つのFECブロック１７１として、通信網１３を介して、クライアント１４あてに送信する。
【０１８９】
例えば、図８の時刻ｔ２から時刻ｔ３において、サーバ１２は、通信網１３が非輻輳状態であるので、RTPパケット集合１８１を１つのFECブロック１７１として、通信網１３を介して、クライアント１４あてに送信する。換言すれば、サーバ１２は、FECパケット送信モードでないので、FECパケットのクライアント１４への送信を抑制する。
【０１９０】
ステップＳ６１において、RTPパケット生成部８３は、FECブロックＩＤを更新する。例えば、ステップＳ６１において、RTPパケット生成部８３は、パケットに格納されるFECブロックＩＤをインクリメントする。
【０１９１】
ステップＳ６２において、RTPパケット生成部８３は、タイムスタンプを更新する。
【０１９２】
なお、FECパケット生成部８４は、RTPパケット生成部８３から供給されるRTPヘッダ情報に含まれるFECブロックＩＤおよびタイムスタンプを基に、FECパケットを生成するようにしてもよく、自分自身が、RTPタイムスタンプおよびFECブロックＩＤを保持し、更新するようにしてもよい。
【０１９３】
ステップＳ６３において、エンコーダ８１は、内蔵しているタイマをセットして、ステップＳ５２に戻り、データ送信の処理を繰り返す。
【０１９４】
例えば、ステップＳ６３において、エンコーダ８１は、タイマの値を0msにセットする。
【０１９５】
このようにして、サーバ１２は、FECブロック１７１ごとにFECブロックＩＤを付加し、通信網１３が輻輳状態の場合、通信網１３を介して、RTPパケットおよびFECパケットをクライアント１４あてに送信し、通信網１３が非輻輳状態の場合、通信網１３を介して、RTPパケットをクライアント１４あてに送信し、FECパケットの送信は抑制する。
【０１９６】
図１２のフローチャートを参照して、サーバプログラムを実行するサーバ１２によるFECパケットの送信の制御の処理を説明する。
【０１９７】
ステップＳ８１において、サーバ１２は、FECパケットの送信の制御の処理に必要なデータを初期化する。例えば、ステップＳ８１において、RTT計測部８５は、内蔵しているタイマの値を0msにセットする。
【０１９８】
ステップＳ８２において、FEC送信制御部８６は、FECフィードバックパケットを受信したか否かを判定し、FECフィードバックパケットを受信したと判定された場合、ステップＳ８３に進み、FEC送信制御部８６は、FECパケット数増減状態の更新の処理を行い、FECパケット数増減状態保持部８７に保持されているFECパケット数増減状態を更新する。FECパケット数増減状態の更新の処理が終了すると、ステップＳ８２に戻り、FECパケットの送信の制御の処理を繰り返す。
【０１９９】
なお、FECパケット数増減状態の更新の処理の詳細は後述する。
【０２００】
一方、ステップＳ８２において、FECフィードバックパケットが受信されなかったと判定された場合、ステップＳ８４に進み、RTT計測部８５は、RTT計測パケットを受信したか否かを判定する。
【０２０１】
ステップＳ８４において、RTT計測パケットが受信されたと判定された場合、ステップＳ８５に進み、RTT計測部８５は、受信されたRTT計測パケットを基に、遅延時間（RTT）を計算する。そして、計算された遅延時間を基に、RTT計測部８５の長期依存RTT演算部１０３は、長期依存RTTを計算し、RTT計測部８５の短期依存RTT演算部１０４は、短期依存RTTを計算する。RTT計測部８５は、計算された長期依存RTTおよび短期依存RTTをFEC送信制御部８６の輻輳／非輻輳判定部１０５に供給する。
【０２０２】
例えば、ステップＳ８５において、RTT計測部８５は、式（１）により遅延時間を計算する。
【０２０３】
遅延時間＝
（RTT計測パケットの受信時刻）−（RTT計測パケットの送信時刻）    ・・・（１）
【０２０４】
ここで、RTT計測パケットの受信時刻は、RTT計測部８５がRTT計測パケットを受信したときに、内蔵しているRTC（Real Time Clock）から取得した時刻である。また、RTT計測パケットの送信時刻は、受信されたRTT計測パケットに格納されているRTT計測パケットの送信時刻である。
【０２０５】
また、例えば、ステップＳ８５において、RTT計測部８５の長期依存RTT演算部１０３は、式（２）により長期依存RTTを計算する。
【０２０６】
長期依存RTT＝
０．９×（前回計算された長期依存RTT）＋０．１×（遅延時間）  ・・・（２）
【０２０７】
ここで、前回計算された長期依存RTTは、前回のステップＳ８５の処理により計算された長期依存RTTである。また、遅延時間は、RTT計測部８５により計算された遅延時間である。
【０２０８】
また、例えば、ステップＳ８５において、RTT計測部８５の短期依存RTT演算部１０４は、式（３）により短期依存RTTを計算する。
【０２０９】
短期依存RTT＝
０．５×（前回計算された短期依存RTT）＋０．５×（遅延時間）  ・・・（３）
【０２１０】
ここで、前回計算された短期依存RTTは、前回のステップＳ８５の処理により計算された短期依存RTTである。また、遅延時間は、RTT計測部８５により計算された遅延時間である。
【０２１１】
例えば、RTT計測部８５の長期依存RTT演算部１０３および短期依存RTT演算部１０４は、それぞれステップＳ８５の処理において、計算された長期依存RTTおよび短期依存RTTを記憶し、次回のステップＳ８５の処理において、記憶されている長期依存RTTおよび短期依存RTTを利用することにより、次の長期依存RTTおよび短期依存RTTを計算する。
【０２１２】
なお、長期依存RTTは、例えば、５秒間の平均遅延時間としてもよい。また、短期依存RTTは、例えば、１秒間の平均遅延時間としてもよい。
【０２１３】
ステップＳ８６において、FEC送信制御部８６の輻輳／非輻輳判定部１０５は、RTT計測部８５から供給された長期依存RTTと短期依存RTTとを比較する。
【０２１４】
例えば、ステップＳ８６において、輻輳／非輻輳判定部１０５は、RTT計測部８５から供給された長期依存RTTおよび短期依存RTTを基に、式（４）で示す計算をすることによって、長期依存RTTと短期依存RTTとを比較する。
【０２１５】
（短期依存RTT）／（長期依存RTT）＞１                            ・・・（４）
【０２１６】
ステップＳ８７において、輻輳／非輻輳判定部１０５は、ステップＳ８６において計算された式（４）の計算結果を基に、通信網１３が輻輳状態であるか否かを判定する。
【０２１７】
例えば、ステップＳ８７において、輻輳／非輻輳判定部１０５は、RTT計測部８５から供給された長期依存RTTおよび短期依存RTTが式（４）を満たす場合、通信網１３が輻輳状態であると判定し、RTT計測部８５から供給された長期依存RTTおよび短期依存RTTが式（４）を満たさない場合、通信網１３が輻輳状態でないと判定する。
【０２１８】
ここで、輻輳状態とは、通信網１３のトラフィックが増加して、パケットの伝送に支障が生ずる状態をいう。例えば、輻輳状態においては、正常にパケットの伝送ができなくなる場合がある。輻輳状態であるか否かの通信網１３の状態は、例えば、通信網１３のノードにおけるバッファのキュー長によって示すことができる。例えば、ノードにおけるバッファのキュー長が長い場合、伝送されずに伝送を待機しているパケットが多いので、通信網１３は込みあっているといえる。逆に、ノードにおけるキュー長が短い場合、伝送を待機するパケットが少ないので、通信網１３は込んでいないと言える。
【０２１９】
例えば、バッファのキュー長に対して、所定の閾値を設け、バッファにおけるキュー長が閾値よりも大きい場合、輻輳状態であると判定し、バッファにおけるキュー長が閾値よりも小さい場合、非輻輳状態であると判定することができる。
【０２２０】
通信網１３におけるノードのキュー長は、例えば、SNMP（Simple Network Management Protocol）などを用いて観測することができる。
【０２２１】
本出願人が、ノードにおけるキュー長、長期依存RTT、および短期依存RTTの測定を行った結果、ノードにおけるキュー長、長期依存RTT、および短期依存RTTの間には、一定の関係が満たされることが認められた。
【０２２２】
図１３は、ノードにおけるキュー長、長期依存RTT、および短期依存RTTの関係を説明する図である。
【０２２３】
図１３において、横方向は、時間を示す。図１３において、実線は、長期依存RTTを表し、点線は、短期依存RTTを表し、一点鎖線は、ノードにおけるキュー長を表す。
【０２２４】
図１３で示すように、短期依存RTTが長期依存RTTより大きい状態から、長期依存RTTが短期依存RTTより大きい状態に変化したとき、ノードにおけるキュー長が、急激に小さくなっていることが分かる。例えば、図１３の時刻ｔ５２において、短期依存RTTが長期依存RTTより大きい状態から、長期依存RTTが短期依存RTTより大きい状態に変化し、ノードにおけるキュー長が急激に小さくなっていることが分かる。
【０２２５】
逆に短期依存RTTが長期依存RTTより小さい状態から、短期依存RTTが長期依存RTTより大きい状態に変化したとき、ノードにおけるキュー長が大きくなっていることが分かる。例えば、図１３の時刻ｔ５３において、短期依存RTTが長期依存RTTより小さい状態から、短期依存RTTが長期依存RTTより大きい状態に変化したとき、ノードにおけるキュー長が大きくなっていることが分かる。
【０２２６】
したがって、短期依存RTTが長期依存RTTより大きいか否かで、通信網１３が輻輳状態であるか否かを判定することができる。換言すれば、長期依存RTTおよび短期依存RTTによって式（４）が満たされる場合、通信網１３は輻輳状態であると判定し、式（４）が満たされない場合、通信網１３は、非輻輳状態であると判定することができる。
【０２２７】
例えば、図１３において、時刻ｔ５１から時刻ｔ５２までの期間は、通信網１３が輻輳状態であると判定し、時刻ｔ５２から時刻ｔ５３までの期間は、通信網１３が非輻輳状態であると判定することができる。
【０２２８】
図１２のフローチャートに戻り、ステップＳ８７において、通信網１３が輻輳状態であると判定された場合、ステップＳ８８に進み、輻輳／非輻輳判定部１０５は、通信網１３が輻輳状態である旨を輻輳／非輻輳状態として記憶し、FEC送信制御部８６に通信網１３が輻輳状態である旨の信号を供給する。
【０２２９】
なお、ステップＳ８７における判定の処理は、長期依存RTTおよび短期依存RTTに基づくものに限らず、例えば、通信網１３のトラフィック状態を観測するSNMP、ジッタ、あるいはパケットのロス率などを用いて、輻輳状態であるか否かを判定するようにしてもよい。
【０２３０】
ステップＳ８９において、FEC送信制御部８６は、輻輳／非輻輳判定部１０５から通信網１３が輻輳状態である旨の信号を取得すると、FEC送信モード記憶部８８に記憶されているFEC送信モードフラグをセットする。
【０２３１】
ここで、FEC送信モードとは、FECパケットを送信するモードである。すなわち、FEC送信制御部８６は、ステップＳ８７において、通信網１３が輻輳状態であると判定された場合、FEC送信モード記憶部８８に記憶されているFEC送信モードフラグをセットすることにより、FEC送信モードとされ、FECブロック１７１の送信において、FECパケットが送信される。
【０２３２】
ステップＳ９０において、FEC送信制御部８６は、通信網１３が非輻輳状態から輻輳状態に変化したか否かを判定する。
【０２３３】
例えば、ステップＳ９０において、FEC送信制御部８６は、輻輳／非輻輳判定部１０５に記憶されている輻輳／非輻輳状態を参照することにより、通信網１３が非輻輳状態から輻輳状態に変化したか否かを判定する。
【０２３４】
また、例えば、ステップＳ９０において、FEC送信制御部８６は、FEC送信モード記憶部８８に記憶されているFEC送信モードフラグを基に、通信網１３が非輻輳状態から輻輳状態に変化したか否かを判定するようにしてもよい。
【０２３５】
ステップＳ９０において、非輻輳状態から輻輳状態に変化したと判定された場合、ステップＳ９１に進み、FEC送信制御部８６は、ステップＳ８３の処理によって更新され、FECパケット数増減状態保持部８７に保持されているFECパケット数増減状態を読み出す。
【０２３６】
例えば、FECパケット数増減状態保持部８７には、FECパケット数増減状態としての増加状態、維持状態、および削減状態の３つの状態のうち、いずれかの状態が保持されている。すなわち、増加状態は、サーバ１２が、通信網１３を介して、クライアント１４あてに送信するFECブロック１７１に含まれるFECパケットの数を増加させることを表し、維持状態は、サーバ１２が、通信網１３を介して、クライアント１４あてに送信するFECブロック１７１に含まれるFECパケットの数を維持させる（変化させない）ことを表し、削減状態は、サーバ１２が、通信網１３を介して、クライアント１４あてに送信するFECブロック１７１に含まれるFECパケットの数を削減させることを表す。
【０２３７】
なお、FECパケット数増減状態保持部８７に保持されているFECパケット数増減状態は、通信網１３を介して、クライアント１４からFECフィードバックパケットを受信する度に更新される。
【０２３８】
ステップＳ９２において、FEC送信制御部８６は、読み出したFECパケット数増減状態を基に、FECパケット数変更の処理を行う。FECパケット数変更の処理の詳細は後述する。
【０２３９】
ここで、FECパケット数とは、サーバ１２が、通信網１３を介して、クライアント１４あてに送信する１つのFECブロック１７１に含まれるFECパケットの数である。例えば、図８において、時刻ｔ１から時刻ｔ２までの期間におけるサーバ１２のFECパケット数は、２である。
【０２４０】
ステップＳ９３において、FEC送信制御部８６は、FECパケット数増減状態保持部８７に保持されているFECパケット数状態を初期化し、処理は、ステップＳ８２に戻り、FECパケットの送信の制御の処理を繰り返す。
【０２４１】
例えば、ステップＳ９３において、FEC送信制御部８６は、FECパケット数増減状態保持部８７に保持されているFECパケット数増減状態に維持状態を設定することによりFECパケット数状態を初期化する。
【０２４２】
一方、ステップＳ９０において、非輻輳状態から輻輳状態に変化したと判定されなかった場合、ステップＳ９１乃至ステップＳ９３の処理はスキップされ、処理はステップＳ８２に戻り、FECパケットの送信の制御の処理を繰り返す。
【０２４３】
また、ステップＳ８７において、通信網１３が輻輳状態でないと判定された場合、ステップＳ９４に進み、輻輳／非輻輳判定部１０５は、通信網１３が非輻輳状態である旨を輻輳／非輻輳状態として記憶し、FEC送信制御部８６に通信網１３が非輻輳状態である旨の信号を供給する。
【０２４４】
ステップＳ９５において、FEC送信制御部８６は、輻輳／非輻輳判定部１０５から通信網１３が非輻輳状態である旨の信号を取得すると、FEC送信モード記憶部８８に記憶されているFEC送信モードフラグをリセットする。FEC送信モード記憶部８８のFEC送信モードフラグがリセットされることにより、FEC送信モードではなくなり、FECブロック１７１の送信において、FECパケットは送信されなくなる。
【０２４５】
FEC送信制御部８６がFEC送信モードフラグをリセットすると、処理は、ステップＳ８２に戻り、FECパケットの送信の制御の処理を繰り返す。
【０２４６】
ステップＳ８４において、RTT計測部８５がRTT計測パケットを受信しなかったと判定された場合、ステップＳ９６に進み、RTT計測部８５は、内蔵しているタイマが終了したか否かを判定する。
【０２４７】
例えば、ステップＳ９６において、RTT計測部８５は、タイマの値と10sなどの所定の値とを比較することによって、タイマが終了したか否かを判定する。
【０２４８】
ステップＳ９６において、タイマが終了していないと判定された場合、ステップＳ８２に戻り、FECパケットの送信の制御の処理を繰り返す。
【０２４９】
一方、ステップＳ９６において、タイマが終了したと判定された場合、ステップＳ９７に進み、RTT計測部８５は、RTT計測パケットを生成し、生成したRTT計測パケットを、通信網１３を介して、クライアント１４あてに送信する。
【０２５０】
例えば、ステップＳ９７において、RTT計測部８５は、内蔵しているRTCから現在時刻を取得し、図１４で示されるRTT計測パケットを生成する。
【０２５１】
図１４は、RTT計測パケットを説明する図である。バージョン情報、パディング、およびSSRCは、図で示されるRTPパケットの場合と同様であるので、その説明は、省略する。
【０２５２】
RTT計測パケットにおいて、パディングに続いて５ビットのサブタイプが配置される。
【０２５３】
RTT計測パケットにおいて、ペイロードタイプは２０５とされる。ペイロードタイプの次に配置される、１６ビットのメッセージ長は、RTT計測パケットの長さ（サイズ）を示す情報である。
【０２５４】
３２ビットのSSRCに続いて、３２ビットの名前が配置される。名前は、例えば、RTT計測パケットを取り扱うアプリケーションプログラムの名前である。
【０２５５】
RTT計測パケットにいおいて、名前の次に配置される送信時刻は、サーバ１２がクライアント１４に、そのRTT計測パケットを送信した時刻を示す。例えば、送信時刻には、ステップＳ９７において、RTT計測部８５が内蔵しているRTCから取得した時刻が格納される。
【０２５６】
図１２のフローチャートに戻り、ステップＳ９８において、RTT計測部８５は、内蔵しているタイマをセットして、処理は、ステップＳ８２に戻り、上述した処理を繰り返す。
【０２５７】
例えば、ステップＳ９８において、RTT計測部８５は、内蔵しているタイマの値を0sにセットする。
【０２５８】
このようにして、サーバ１２は、FECパケットの送信の制御の処理を行う。
【０２５９】
次に、図１５のフローチャートを参照して、図１２のステップＳ８３の処理に対応するFECパケット数増減状態の更新の処理について説明する。
【０２６０】
ステップＳ１１１において、FEC送信制御部８６は、FECパケット数増減状態保持部８７に保持されているFECパケット数増減状態が増加状態であるか否かを判定する。
【０２６１】
ステップＳ１１１において、FECパケット数増減状態が増加状態であると判定された場合、FEC送信制御部８６は、FECパケット数増減状態保持部８７に保持されているFECパケット数増減状態の設定を更新せずに、FECパケット数増減状態の更新の処理は、終了する。
【０２６２】
一方、ステップＳ１１１において、増加状態でないと判定された場合、ステップＳ１１２に進み、FEC送信制御部８６は、FECパケットの不足状態を示すFECフィードバックパケットを受信したか否かを判定する。
【０２６３】
ここで、FECフィードバックパケットは、通信網１３を介して、クライアント１４から送信されてくるパケットである。例えば、図８において、クライアント１４は、時刻ｔ２３、時刻ｔ２４、時刻ｔ２５、および時刻ｔ２６のそれぞれにおいて、通信網１３を介して、サーバ１２あてにFECフィードバックパケットを送信する。
【０２６４】
また、FECフィードバックパケットには、クライアント１４において、受信されたFECパケットが、ロスパケットを復元するのに不足状態であるか、適正状態であるか、および過多状態であるかのいずれであるかを示す通知FEC状態が格納されている。
【０２６５】
ステップＳ１１２において、FECパケットの不足状態を示すFECフィードバックパケットを受信したと判定された場合、ステップＳ１１３に進み、クライアント１４において、FECパケットが不足しているので、FEC送信制御部８７は、FECパケット数増減状態保持部８７に保持されているFECパケット数増減状態に増加状態を設定し、処理は、終了する。
【０２６６】
ステップＳ１１２において、FECパケットの不足状態を示すFECフィードバックパケットを受信していないと判定された場合、ステップＳ１１４に進み、FEC送信制御部８６は、FECパケットの過多状態を示すFECフィードバックパケットを受信したか否かを判定する。
【０２６７】
ステップＳ１１４において、FECパケットの過多状態を示すFECフィードバックパケットを受信したと判定された場合、ステップＳ１１５において、FEC送信制御部８６は、クライアント１４において、受信されたFECパケットが過多であるので、FECパケット数増減状態に削減状態を設定し、処理は終了する。
【０２６８】
また、ステップＳ１１４において、FECパケットの過多状態を示すFECフィードバックパケットを受信していないと判定された場合、FEC送信制御部８６は、FECパケット数増減状態の更新を行わず、処理は終了する。
【０２６９】
すなわち、FEC送信制御部８６は、図１２のステップＳ９３の処理において、FECパケット数増減状態の初期化を行ってから、RTT計測パケットが受信されるまでの期間において、１度でもFECの不足状態を示すFECフィードバックパケットを受信した場合、FECパケット数状態を増加状態に設定し、FECの適正状態を示すFECフィードバックパケットだけを受信した場合、FECパケット数状態を維持状態に設定し、FECの適正状態を示すFECフィードバックパケットおよびFECの過多状態を示すFECフィードバックパケットを受信した場合、FECパケット数状態を削減状態に設定する。
【０２７０】
このようにして、FEC送信制御部８６は、クライアント１４からFECフィードバックパケットを受信するごとに、FECパケット数増減状態の更新を行う。
【０２７１】
次に、図１６のフローチャートを参照して、図１２のステップＳ９２の処理に対応するFECパケット数変更の処理について説明する。
【０２７２】
ステップＳ１３１において、FEC送信制御部８６は、FECパケット数増減状態保持部８７に記憶されているFECパケット数増減状態が維持状態であるか否かを判定し、維持状態であると判定された場合、FEC送信制御部８６は、FECパケット数の変更をせず、処理は終了する。
【０２７３】
一方、ステップＳ１３１において、FECパケット数増減状態保持部８７に記憶されているFECパケット数増減状態が維持状態でないと判定された場合、ステップＳ１３２に進み、FEC送信制御部８６は、FECパケット数増減状態保持部８７に記憶されているFECパケット数増減状態が増加状態であるか否かを判定する。
【０２７４】
ステップＳ１３２において、増加状態であると判定された場合、ステップＳ１３３に進み、FEC送信制御部８６は、FECパケット数保持部８９に保持されているFECパケット数が上限値であるか否かを判定する。
【０２７５】
ステップＳ１３３において、FECパケット数が、上限値でないと判定された場合、ステップＳ１３４に進み、FEC送信制御部８６は、FECパケット数をインクリメントする。
【０２７６】
また、ステップＳ１３３において、FECパケット数保持部８９に保持されているFECパケット数が上限値であると判定された場合、FECパケット数をこれ以上増加させることができないので、FEC送信制御部８６は、FECパケット数の変更をせず、処理は終了する。
【０２７７】
ステップＳ１３２において、FECパケット数増減状態保持部８７に記憶されているFECパケット数増減状態が増加状態でないと判定された場合、ステップＳ１３５に進み、FEC送信制御部８６は、FECパケット数増減状態保持部８７に記憶されているFECパケット数増減状態が削減状態であるか否かを判定する。
【０２７８】
ステップＳ１３５において、削減状態であると判定された場合、ステップＳ１３６に進み、FEC送信制御部８６は、FECパケット数保持部８９に保持されているFECパケット数が０であるか否かを判定する。
【０２７９】
ステップＳ１３６において、FECパケット数が０でないと判定された場合、ステップＳ１３７に進み、FEC送信制御部８６は、FECパケット数をデクリメントし、処理は終了する。
【０２８０】
一方、ステップＳ１３６において、FECパケット数が０であると判定された場合、FEC送信制御部８６は、これ以上FECパケット数を削減することができないので、FECパケット数を変更せず、処理は終了する。
【０２８１】
また、ステップＳ１３５において、FECパケット数増減状態保持部８７に記憶されているFECパケット数増減状態が削減状態でないと判定された場合、FEC送信制御部８６は、FECパケット数の変更をせず、処理は終了する。
【０２８２】
このようにして、FEC送信制御部８６は、FECパケット数保持部８９に保持されているFECパケット数を変更する。
【０２８３】
図１７のフローチャートを参照して、クライアントプログラムを実行するクライアント１４によるデコードの処理について説明する。
【０２８４】
ステップＳ１５１において、デコーダ１３４は、デコードの処理に必要なデータを初期化する。例えば、ステップＳ１５１において、デコーダ１３４は、500msの期間、待ち状態となって待機して、バッファ１３３が、所定の量の画像データを記憶するまで待つ。
【０２８５】
また、例えば、画像データのフレームの数が１秒当たり３０である場合、ステップＳ１５１において、デコーダ１３４は、内蔵しているタイマの値を0msにセットし、33msなどの所定の値と比較することによりタイマが終了したか否かを判定する。
【０２８６】
ステップＳ１５２において、デコーダ１３４は、タイマの値を基に、タイマが終了したか否かを判定し、タイマが終了したと判定された場合、ステップＳ１５３に進み、デコーダ１３４は、バッファ１３３から１フレーム分のデータを取得する。ステップＳ１５４において、デコーダ１３４は、ステップＳ１５３の処理で取得したデータをデコードして、デコードにより得られた画像データを出力する。
【０２８７】
ステップＳ１５５において、デコーダ１３４は、内蔵しているタイマをセットして、ステップＳ１５１に戻り、デコードの処理を繰り返す。例えば、ステップＳ１５５において、デコーダ１３４は、タイマの値を0msにセットする。
【０２８８】
一方、ステップＳ１５２において、タイマが終了していないと判定された場合、ステップＳ１５６に進み、RTP処理部１３２は、RTPパケットを受信したか否かを判定する。
【０２８９】
ステップＳ１５６において、RTPパケットを受信したと判定されなかった場合、ステップＳ１５２に戻り、デコードの処理を繰り返す。
【０２９０】
ステップＳ１５６において、RTPパケットを受信したと判定された場合、ステップＳ１５７に進み、RTP処理部１３２は、受信されたRTPパケットを検査することにより、パケットロスが発生したか否かを判定する。
【０２９１】
ステップＳ１５７において、パケットロスが発生したと判定された場合、ステップＳ１５８に進み、FEC処理部１３５は、ロスパケットを復元する。
【０２９２】
例えば、ステップＳ１５８において、FEC処理部１３５は、ロスしたパケットのFECブロックＩＤと同じFECブロックＩＤを含むFECパケットをRTP処理部１３２から供給された場合、供給されたFECパケットを基に、ロスパケットを復元し、復元されたRTPパケットをRTP処理部１３２に供給する。
【０２９３】
また、ステップＳ１５８において、FECパケットが供給されなかった場合および供給されたFECパケットの数がロスパケットの数に対して、不足している場合は、ロスパケットを復元することができないので、FECパケットが不足している分のロスパケットの復元は行わない。
【０２９４】
ステップＳ１５７において、パケットロスが発生していないと判定された場合、RTPパケットを復元する必要がないので、ステップＳ１５８の処理をスキップし、ステップＳ１５９に進む。
【０２９５】
ステップＳ１５９において、RTP処理部１３２は、受信されたRTPパケットおよび復元されたRTPパケットをバッファ１３３に供給して、ステップＳ１５２に戻り、上述した処理を繰り返す。
【０２９６】
このようにして、デコーダ１３４は、デコードの処理を行う。
【０２９７】
次に、図１８のフローチャートを参照して、クライアントプログラムを実行するクライアント１４によるFECフィードバックパケット送信の処理を説明する。
【０２９８】
ステップＳ１７１において、クライアント１４は、FECフィードバックパケット送信の処理に必要なデータの初期化を行う。例えば、ステップＳ１７１において、FEC処理部１３５は、後述するFECブロック情報を初期化し、内蔵しているタイマの値を0msに設定する。
【０２９９】
ステップＳ１７２において、RTP処理部１３２は、パケットを受信したか否かを判定する。
【０３００】
ステップＳ１７２において、パケットが受信されたと判定された場合、ステップＳ１７３に進み、RTP処理部１３２は、受信したパケットのFECブロックＩＤが変化したか否かを判定する。ステップＳ１７３において、受信したパケットのFECブロックＩＤが変化したと判定された場合、ステップＳ１７４に進み、FEC処理部１３５は、受信が完了したFECブロック１７１に対するFECブロック状態の更新の処理を行う。
【０３０１】
ここで、受信が完了したFECブロック１７１とは、ステップＳ１７４において、変化したと判定されたFECブロックＩＤの１つ前のFECブロックＩＤを含むFECブロック１７１である。FECブロック状態更新の処理は、通信網１３を介してサーバ１２から送信されてきた１つのFECブロック１７１に含まれるパケットの数と正常に受信されたパケットの数とを基に、処理が行われるため、FECブロック１７１に含まれる全てのパケットの受信が完了したとき、処理が実行できる。
【０３０２】
従って、例えば、ステップＳ１７３において、受信したパケットのFECブロックＩＤが変化したか否かを基に、FECブロック１７１に含まれる全てのパケットの受信が、完了したか否かを判定する。
【０３０３】
なお、ステップＳ１７４におけるFECブロック状態更新の処理の詳細は、後述する。
【０３０４】
ステップＳ１７５において、RTP処理部１３２は、受信されたパケットに含まれるFECブロックＩＤ、オリジナルデータパケット数、および総パケット数をFECブロック情報として、FECブロック情報保持部１３６に記録する。
【０３０５】
ここで、例えば、オリジナルデータパケット数は、図１１で示されるRTPパケットの“Ｋ”に対応し、総パケット数は、図１１で示されるRTPパケットの“Ｎ”に対応する。また、FECブロック情報は、例えば、図９で示すFECブロック情報テーブルに記録される。
【０３０６】
図１１において、“Ｋ”で示されるRTPパケットのオリジナルデータパケット数が、FECブロックＩＤと対応して、図９で示されるFECブロック情報のオリジナルデータパケット数として格納される。図１１で示されるRTPパケットのFECブロックＩＤが図９のFECブロック情報のFECブロックＩＤとして格納される。また、図１１において、“Ｎ”で示される総パケット数が、FECブロックＩＤと対応して、図９で示されるFECブロック情報の総パケット数として格納される。
【０３０７】
ステップＳ１７５の処理において、処理の対象となる受信されたパケットは、ステップＳ１７３の処理において、FECブロックＩＤが変化したと判定されたパケットである。すなわち、ステップＳ１７４の処理の対象となるFECブロックＩＤと、ステップＳ１７５の処理の対象となるFECブロックのFECブロックＩＤとは異なる。
【０３０８】
ステップＳ１７６において、RTP処理部１３２は、FECブロック情報保持部１３６に記録されているFECブロック情報テーブルの受信パケット数に０を設定する。
【０３０９】
また、ステップＳ１７３において、FECブロックＩＤが変化していないと判定された場合、ステップＳ１７４乃至ステップＳ１７６の処理はスキップされ、ステップＳ１７７に進む。
【０３１０】
ステップＳ１７７において、RTP処理部１３２は、FECブロック情報保持部１３６に記録されているFECブロック情報テーブルの受信パケット数をインクリメントし、ステップＳ１７２に戻り、FECフィードバックパケット送信の処理を繰り返す。
【０３１１】
また、ステップＳ１７２において、パケットが受信されていないと判定された場合、ステップＳ１７８に進み、FEC処理部１３５は、内蔵しているタイマが終了したか否かを判定する。
【０３１２】
例えば、ステップＳ１７８において、FEC処理部１３５は、内蔵しているタイマの値と100msなどの所定の値とを比較することによって、タイマが終了したか否かを判定する。
【０３１３】
ステップＳ１７８において、タイマが終了していないと判定された場合、ステップＳ１７２に戻り、FECフィードバックパケット送信の処理を繰り返す。
【０３１４】
ステップＳ１７８において、タイマが終了したと判定された場合、ステップＳ１７９に進み、FEC処理部１３５は、サーバ１２に通知するFEC状態である通知FEC状態設定の処理を行う。
【０３１５】
例えば、ステップＳ１７９において、FEC処理部１３５は、FECブロック情報保持部１３６に保持されているFECブロック情報テーブルに記録されている全てのFECブロック状態を基に、通知FEC状態設定の処理を行う。通知FEC状態設定の処理の詳細は、後述する。
【０３１６】
ステップＳ１８０において、FEC処理部１３５のFECフィードバックパケット生成部１５３は、ステップＳ１７９において、設定されている通知FEC状態を基に、FECフィードバックパケットを生成する。
【０３１７】
図１９は、FECフィードバックパケットを説明する図である。バージョン情報、パディング、サブタイプ、メッセージ長、SSRC、および名前は、図１４で示されるRTT計測パケットの場合と同様であるので、その説明は、省略する。
【０３１８】
FECフィードバックパケットにおいて、ペイロードタイプは、２０４とされる。
【０３１９】
FECフィードバックパケットにおいて、名前の次に配置される通知FEC状態は、相手に通知する通知FEC状態である。通知FEC状態には、例えば、図１８のステップＳ１７９の処理において、適正状態、過多状態、および不足状態のいずれかの設定された通知FEC状態が格納される。
【０３２０】
図１８の説明に戻り、ステップＳ１８１において、FECフィードバックパケット生成部１５３は、生成されたFECフィードバックパケットを通信部１３１に供給し、通信部１３１は、FECフィードバックパケット生成部１５３から供給されたFECフィードバックパケットを、通信網１３を介して、サーバ１２あてに送信する。
【０３２１】
ステップＳ１８２において、FEC処理部１３５は、内蔵しているタイマを更新し、ステップＳ１７２に戻り、上述した処理を繰り返す。
【０３２２】
例えば、ステップＳ１８２において、FEC処理部１３５は、内蔵しているタイマを0msにセットする。
【０３２３】
このようにして、FEC処理部１３５は、所定の期間ごとに通信網１３を介して、サーバ１２あてにFECフィードバックパケットを送信する。なお、ステップＳ１７８において、タイマの値と比較される100msは、図８におけるＴ１、Ｔ２、Ｔ３、およびＴ４に対応する期間の一例であり、本発明を限定するものではない。
【０３２４】
次に、図２０のフローチャートを参照して、図１８のステップＳ１７４の処理に対応する受信完了FECブロック１７１に対するFECブロック状態更新の処理について説明する。
【０３２５】
ステップＳ２０１において、RTP処理部１３２は、FECブロック情報保持部１３６に保持されているFECブロック情報テーブルに、受信が完了したFECブロック１７１の受信パケット数を格納（記録）する。
【０３２６】
ステップＳ２０２において、FEC処理部１３５は、FECブロック情報保持部１３６に保持されているFECブロック情報テーブルを基に、受信が完了したFECブロック１７１の受信パケット数が、オリジナルデータパケット数と等しいか否かを判定する。
【０３２７】
ステップＳ２０２において、受信パケット数が、オリジナルデータパケット数と等しいと判定された場合、RTPパケットを復元するFECパケットの数は、不足でもなく、過多でもないので、ステップＳ２０３に進み、FEC処理部１３５は、FECブロック情報保持部１３６に保持されているFECブロック情報テーブルのFECブロック状態に適正状態を設定し、処理は終了する。
【０３２８】
ステップＳ２０２において、受信パケット数がオリジナルデータパケット数と等しくないと判定された場合、ステップＳ２０４に進み、FEC処理部１３５は、受信パケット数がオリジナルパケット数より多いか否かを判定する。
【０３２９】
ステップＳ２０４において、受信パケット数がオリジナルデータパケット数より多いと判定された場合、RTPパケットを復元するFECパケットの数が過多であるので、ステップＳ２０５に進み、FEC処理部１３５は、FECブロック情報保持部１３６に保持されているFECブロック情報テーブルのFECブロック状態に過多状態を設定し、処理は終了する。
【０３３０】
ステップＳ２０４において、受信パケット数がオリジナルデータパケット数より多いと判定されなかった場合、ステップＳ２０６に進み、FEC処理部１３５は、受信パケット数がオリジナルパケット数より少ないか否かを判定する。
【０３３１】
ステップＳ２０６において、受信パケット数がオリジナルデータパケット数より少ないと判定された場合、RTPパケットを復元するFECパケットの数が不足しているので、ステップＳ２０７に進み、FEC処理部１３５は、FECブロック情報保持部１３６に保持されているFECブロック情報テーブルのFECブロック状態に不足状態を設定し、処理は終了する。
【０３３２】
一方、ステップＳ２０６において、受信パケット数がオリジナルデータパケット数より少ないと判定されなかった場合、ステップＳ２０８に進み、FEC処理部１３５は、FECブロック情報保持部１３６に保持されているFECブロック情報テーブルのFECブロック状態に適正状態を設定し、処理は終了する。
【０３３３】
このようにして、FEC処理部１３５は、FECブロック１７１の受信が完了するごとにFECブロック情報保持部１３６に保持されているFECブロック状態を更新する。
【０３３４】
なお、ステップＳ２０６の判定の処理を省略して、FECブロック状態を不足状態と設定するようにしてもよい。
【０３３５】
次に、図２１のフローチャートを参照して、図１８のステップＳ１７９の処理に対応する通知FECブロック状態設定の処理について説明する。
【０３３６】
ステップＳ２２１において、FEC処理部１３５は、FECブロック情報保持部１３６に保持されているFECブロック情報テーブルに記録されているFECブロックＩＤごとのFEC状態のなかに、不足状態であるFECブロック１７１があるか否かを判定する。
【０３３７】
ステップＳ２２１において、不足状態であるFECブロック１７１があると判定された場合、ステップＳ２２２に進み、FEC処理部１３５は、通知FEC状態保持部１３７に保持されている通知FEC状態に不足状態を設定する。ステップＳ２２３において、FECブロック情報を初期化し、処理は終了する。
【０３３８】
例えば、ステップＳ２２３において、FEC処理部１３５は、FEC情報テーブルに記録されているFECブロック情報の全てをクリアすることにより初期化を行う。
【０３３９】
また、ステップＳ２２１において、FECブロック情報保持部１３６に保持されているFECブロック情報テーブルに記録されているFECブロックＩＤごとのFEC状態のなかに、不足状態であるFECブロック１７１がないと判定された場合、ステップＳ２２４に進み、FEC処理部１３５は、FECブロックＩＤごとのFEC状態のなかに、過多状態であるFECブロック１７１があるか否かを判定する。
【０３４０】
ステップＳ２２４において、過多状態であるFECブロック１７１があると判定された場合、ステップＳ２２５に進み、FEC処理部１３５は、通知FEC状態保持部１３７に保持されている通知FEC状態に過多状態を設定し、ステップＳ２２３に進む。
【０３４１】
ステップＳ２２４において、過多状態であるFECブロック１７１がないと判定された場合、ステップＳ２２６に進み、FEC処理部１３５は、通知FEC状態保持部１３７に保持されている通知FEC状態に適正状態を設定し、ステップＳ２２３に進む。
【０３４２】
すなわち、FEC処理部１３５は、FECブロック情報保持部１３６に保持されているFECブロック情報テーブルに記録されているFECブロック状態の中に、１つでも不足状態であるFECブロック１７１がある場合、通知FEC状態を不足状態に設定し、全てのFECブロック１７１が、適正状態である場合、通知FEC状態を適正状態に設定し、不足状態であるFECブロック１７１がなく、過多状態であるFECブロック１７１がある場合、通知FEC状態を過多状態に設定する。
【０３４３】
このようにして、FEC処理部１３５は、所定の期間ごとに、FECブロック情報保持部１３６に保持されているFECブロックＩＤごとのFECブロック状態を基に、サーバ１２に通知する通知FEC状態を設定する。
【０３４４】
図２２のフローチャートを参照して、RTT計測パケットの返信の処理を説明する。ステップＳ２４１において、RTT計測部１３８は、通信部１３１がパケットを受信した場合に、通信部１３１から供給されたパケットを基に、RTT計測パケットを受信したか否かを判定し、RTT計測パケットを受信していないと判定された場合、ステップＳ２４１に戻り、RTT計測パケットが受信されるまで、判定の処理を繰り返す。
【０３４５】
ステップＳ２４１において、RTT計測パケットを受信したと判定された場合、ステップＳ２４２に進み、RTT計測部１３８は、直ちに、受信したRTT計測パケットのデータ部と同様のデータ部のRTT計測パケットを生成して、生成したRTT計測パケットを通信部１３１に供給する。そして、RTT計測部１３８は、通信部１３１に、通信網１３を介して、RTT計測パケットをサーバ１２あてに直ちに送信させて、ステップＳ２４１に戻り、上述した処理を繰り返す。
【０３４６】
このように、クライアント１４は、RTT計測パケットを受信すると、直ちに、サーバ１２にRTT計測パケットを返送する。
【０３４７】
以上のように、サーバ１２は、クライアント１４から送信されてきたFECフィードバックパケットを基に、クライアント１４に送信するFECパケットの数を変更し、さらに、通信網１３が輻輳状態である場合、FECパケットをクライアント１４に送信し、通信網１３が輻輳状態でない場合、FECパケットのクライアント１４への送信を抑制することで、より効率的にデータの送信を行うことができる。
【０３４８】
第１の本発明によれば、誤り訂正パケットを生成するようにしたので、誤り訂正のための冗長データを送信することができる。また、第１の本発明によれば、通信網が輻輳状態であるか否かを判定し、誤り訂正パケットを生成し、輻輳状態でない旨の判定結果から輻輳状態である旨の判定結果に変化した場合、誤り訂正パケットの数を変更するように、生成を制御するようにしたので、通信網の状態に応じて、冗長データを含むデータの送信をより効率的に行うことができる。
【０３４９】
第２の本発明によれば、誤り訂正パケットを受信するようにしたので、受信したデータの誤りを訂正することができる。また、第２の本発明によれば、誤り訂正パケットを受信し、受信した誤り訂正パケットの数が、ストリーミングデータの誤りを訂正するのに適正であるか否かを判定するようにしたので、送信側において、通信網の状態に応じて、冗長データを含むデータの送信をより効率的に行うことができる。
【０３５０】
上述した一連の処理は、ハードウェアにより実行させることもできるが、ソフトウェアにより実行させることもできる。一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、専用のハードウェアに組み込まれているコンピュータ、または、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどに、記録媒体からインストールされる。
【０３５１】
この記録媒体は、図５に示すように、コンピュータとは別に、ユーザにプログラムを提供するために配布される、プログラムが記録されている磁気ディスク５１（フレキシブルディスクを含む）、光ディスク５２（CD-ROM(Compact Disc-Read Only Memory)、ＤＶＤ(Digital Versatile Disc)を含む）、光磁気ディスク５３（ＭＤ(Mini-Disc)（商標）を含む）、若しくは半導体メモリ５４などよりなるパッケージメディアにより構成されるだけでなく、コンピュータに予め組み込まれた状態でユーザに提供される、プログラムが記録されているROM３２や、記録部３８に含まれるハードディスクなどで構成される。
【０３５２】
なお、上述した一連の処理を実行させるプログラムは、必要に応じてルータ、モデムなどのインタフェースを介して、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線または無線の通信媒体を介してコンピュータにインストールされるようにしてもよい。
【０３５３】
また、本明細書において、記録媒体に格納されるプログラムを記述するステップは、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。
【０３５４】
なお、本明細書において、システムとは、複数の装置により構成される装置全体を表すものである。
【図面の簡単な説明】
【０３５５】
【図１】従来のFECパケットの送信を説明する図である。
【図２】従来のFECパケットの送信の順序を説明する図である。
【図３】従来のFECパケットを付加した送信の処理を説明するフローチャートである。
【図４】本発明に係る通信システムの一実施の形態を示す図である。
【図５】サーバの構成の例を示すブロック図である。
【図６】サーバの機能の構成を示すブロック図である。
【図７】クライアントの機能の構成を示すブロック図である。
【図８】FECパケットの送信を説明するタイムチャートである。
【図９】FECブロック情報を説明する図である。
【図１０】データ送信の処理を説明するフローチャートである。
【図１１】RTPパケットを説明する図である。
【図１２】FECパケットの送信の制御の処理を説明するフローチャートである。
【図１３】輻輳状態、長期依存RTTおよび短期依存RTTの関係を説明する図である。
【図１４】RTT計測パケットを説明する図である。
【図１５】FECパケット数増減状態の更新の処理を説明するフローチャートである。
【図１６】FECパケット数変更の処理を説明するフローチャートである。
【図１７】デコードの処理を説明するフローチャートである。
【図１８】FECフィードバックパケット送信の処理を説明するフローチャートである。
【図１９】FECフィードバックパケットを説明する図である。
【図２０】受信完了ブロックに対するFECブロック状態更新の処理を説明するフローチャートである。
【図２１】通知FEC状態設定の処理を説明するフローチャートである。
【図２２】RTT計測パケットの返信の処理を説明するフローチャートである。
【符号の説明】
【０３５６】
３１  ＣＰＵ，  ３２  ＲＯＭ，  ３３  ＲＡＭ，  ３８  記録部，  ５１  磁気ディスク，  ５２  光ディスク，  ５３  光磁気ディスク，  ５４  半導体メモリ，  ８３  RTTパケット生成部，  ８４  FECパケット生成部，  ８５  RTT計測部，  ８６  FEC送信制御部，  ８７  FECパケット数増減状態保持部，  ８８  FEC送信モード記憶部，  ８９  FECパケット数保持部，  １３２  RTP処理部，  １３５  FEC処理部，  １３６  FECブロック情報保持部，  １３７  通知FEC状態保持部
【図１】
2005175837.tif 000003
【図２】
2005175837.tif 000004
【図３】
2005175837.tif 000005
【図４】
2005175837.tif 000006
【図５】
2005175837.tif 000007
【図６】
2005175837.tif 000008
【図７】
2005175837.tif 000009
【図８】
2005175837.tif 000010
【図９】
2005175837.tif 000011
【図１０】
2005175837.tif 000012
【図１１】
2005175837.tif 000013
【図１２】
2005175837.tif 000014
【図１３】
2005175837.tif 000015
【図１４】
2005175837.tif 000016
【図１５】
2005175837.tif 000017
【図１６】
2005175837.tif 000018
【図１７】
2005175837.tif 000019
【図１８】
2005175837.tif 000020
【図１９】
2005175837.tif 000021
【図２０】
2005175837.tif 000022
【図２１】
2005175837.tif 000023
【図２２】
2005175837.tif 000024