(57)【要約】【課題】エラー伝播を防ぐために、必要に応じて、送信するデータにＩフレームを挿入する。【解決手段】ステップＳ７１で、ＲＲパケット、または、ＡＰＰパケットを受信したか否かが判断される。ＲＲパケット、または、ＡＰＰパケットを受信したと判断された場合、ステップＳ７２において、受信したＲＲパケット、またはＡＰＰパケットに、リフレッシュ命令が含まれているか否かが判断される。リフレッシュ命令が含まれていると判断された場合、ステップＳ７３において、エンコードが制御されて、Ｉフレームが生成される。そして、ＲＴＰパケットでＩフレームが送信され、処理は、ステップＳ７１に戻り、それ以降の処理が繰り返される。本発明は、データ送信装置に適用できる。【選択図】      図１１
2004215201.tif 000002
【特許請求の範囲】
【請求項１】
他の情報処理装置に、ネットワークを介して、データを送信する情報処理装置において、
供給されたデータを、フレーム間相関を用いて符号化する符号化手段と、
前記他の情報処理装置から、前記ネットワークにおけるデータ通信状況に関する所定の情報を受信する受信手段と、
前記受信手段により受信された前記所定の情報を基に、前記符号化手段を制御して、フレーム内符号化を実行させる制御手段と、
前記符号化手段によりフレーム間相関を用いて符号化された前記データを、前記ネットワークを介して、前記他の情報処理装置に送信する送信手段と
を備えることを特徴とする情報処理装置。
【請求項２】
前記所定の情報は、前記フレーム内符号化により生成されるイントラフレームの送出を指令する情報であり、
前記制御手段は、前記受信手段により、前記所定の情報が受信された場合、前記符号化手段を制御して、フレーム内符号化を実行させる
ことを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記所定の情報は、前記送信手段による前記データの送信レートを制御する制御情報であり、
前記制御手段は、前記受信手段により、前記所定の情報が受信され、前記所定の情報が、前記データの送信レートを下げることを指令していた場合、前記符号化手段を制御して、フレーム内符号化を実行させる
ことを特徴とする請求項１に記載の情報処理装置。
【請求項４】
前記データは、ＲＦＣ１８８９に準拠するＲＴＰパケットであり、
前記所定の情報は、ＲＦＣ１８８９に準拠するＲＴＣＰ  ＲＲパケットである
ことを特徴とする請求項１に記載の情報処理装置。
【請求項５】
前記制御手段は、前記受信手段により受信された前記所定の情報を基に、パケットロス率を算出して、その結果に基づいて、前記符号化手段にフレーム内符号化を実行させるか否かを判断する
ことを特徴とする請求項４に記載の情報処理装置。
【請求項６】
前記制御手段は、前記受信手段により受信された前記所定の情報を基に、前記データの遅延の変動を算出して、その結果に基づいて、前記符号化手段にフレーム内符号化を実行させるか否かを判断する
ことを特徴とする請求項４に記載の情報処理装置。
【請求項７】
前記データは、ＲＦＣ１８８９に準拠するＲＴＰパケットであり、
前記所定の情報は、ＲＦＣ１８８９に準拠するＲＴＣＰ  ＡＰＰパケットである
ことを特徴とする請求項１に記載の情報処理装置。
【請求項８】
供給されたデータを、フレーム間相関を用いて符号化する符号化手段を備え、前記符号化手段により符号化されたデータを、ネットワークを介して、他の情報処理装置に送信する情報処理装置の情報処理方法において、
前記他の情報処理装置から、前記ネットワークにおけるデータ通信状況に関する所定の情報の受信を制御する受信制御ステップと、
前記受信制御ステップの処理により受信が制御された前記所定の情報を基に、前記符号化手段を制御して、フレーム内符号化を実行させる符号化制御ステップと
を含むことを特徴とする情報処理方法。
【請求項９】
供給されたデータを、フレーム間相関を用いて符号化する符号化手段を用いて、前記符号化手段により符号化されたデータを、ネットワークを介して、他の情報処理装置に送信する処理をコンピュータに実行させるプログラムであって、
前記他の情報処理装置から、前記ネットワークにおけるデータ通信状況に関する所定の情報の受信を制御する受信制御ステップと、
前記受信制御ステップの処理により受信が制御された前記所定の情報を基に、前記符号化手段を制御して、フレーム内符号化を実行させる符号化制御ステップと
を含むことを特徴とするコンピュータが読み取り可能なプログラムが記録されている記録媒体。
【請求項１０】
供給されたデータを、フレーム間相関を用いて符号化する符号化手段を用いて、前記符号化手段により符号化されたデータを、ネットワークを介して、他の情報処理装置に送信する処理をコンピュータに実行させるプログラムであって、
前記他の情報処理装置から、前記ネットワークにおけるデータ通信状況に関する所定の情報の受信を制御する受信制御ステップと、
前記受信制御ステップの処理により受信が制御された前記所定の情報を基に、前記符号化手段を制御して、フレーム内符号化を実行させる符号化制御ステップと
を含むことを特徴とするプログラム。
【請求項１１】
他の情報処理装置から、ネットワークを介して、フレーム間相関を用いて符号化されたデータを受信する情報処理装置において、
前記他の情報処理装置から送信された、前記データの伝送状況を含む所定の情報を受信する受信手段と、
前記受信手段により受信された前記所定の情報を基に、前記他の情報処理装置に、フレーム内符号化により生成されるイントラフレームの送出を指令する情報を生成する生成手段と、
前記生成手段により生成された前記イントラフレームの送出を指令する情報を、前記ネットワークを介して、前記他の情報処理装置に送信する送信手段と
を備えることを特徴とする情報処理装置。
【請求項１２】
前記データは、ＲＦＣ１８８９に準拠するＲＴＰパケットであり、
前記イントラフレームの送出を指令する情報は、ＲＦＣ１８８９に準拠するＲＴＣＰ
ＲＲパケットである
ことを特徴とする請求項１１に記載の情報処理装置。
【請求項１３】
前記データは、ＲＦＣ１８８９に準拠するＲＴＰパケットであり、
前記イントラフレームの送出を指令する情報は、ＲＦＣ１８８９に準拠するＲＴＣＰＡＰＰパケットである
ことを特徴とする請求項１１に記載の情報処理装置。
【請求項１４】
前記データは、ＲＦＣ１８８９に準拠するＲＴＰパケットであり、
前記送信手段は、ＲＦＣ１８８９に準拠するＲＴＣＰ  ＲＲパケットの次の送出時刻までの時間が所定の時間より長かった場合、ＲＦＣ１８８９に準拠するＲＴＣＰ  ＡＰＰパケットにより、前記イントラフレームの送出を指令する情報を送信し、前記ＲＴＣＰ  ＲＲパケットの次の送出時刻までの時間が所定の時間より短かった場合、前記ＲＴＣＰ  ＲＲパケットにより、前記イントラフレームの送出を指令する情報を送信する
ことを特徴とする請求項１１に記載の情報処理装置。
【請求項１５】
前記データは、ＲＦＣ１８８９に準拠するＲＴＰパケットであり、
前記送信手段は、ＲＦＣ１８８９に準拠するＲＴＣＰ  ＲＲパケット送出時刻を変更することが可能であり、前記ＲＴＣＰ  ＲＲパケットの次の送出予定時刻までの時間が所定の時間より長かった場合、前記ＲＴＣＰ  ＲＲパケットの送出時刻を早めて、前記イントラフレームの送出を指令する情報を送信する
ことを特徴とする請求項１１に記載の情報処理装置。
【請求項１６】
他の情報処理装置から、ネットワークを介して、フレーム間相関を用いて符号化されたデータを受信する情報処理装置の情報処理方法において、
前記他の情報処理装置から送信された、前記データの伝送状況を含む所定の情報の受信を制御する受信制御ステップと、
前記受信制御ステップの処理により受信が制御された前記所定の情報を基に、前記他の情報処理装置に、フレーム内符号化により生成されるイントラフレームの送出を指令する情報を生成する生成ステップと
を含むことを特徴とする情報処理方法。
【請求項１７】
他の情報処理装置から、ネットワークを介して送信される、フレーム間相関を用いて符号化されたデータの受信を制御する処理を実行するプログラムであって、
前記他の情報処理装置から送信された、前記データの伝送状況を含む所定の情報の受信を制御する受信制御ステップと、
前記受信制御ステップの処理により受信が制御された前記所定の情報を基に、前記他の情報処理装置に、フレーム内符号化により生成されるイントラフレームの送出を指令する情報を生成する生成ステップと
を含むことを特徴とするコンピュータが読み取り可能なプログラムが記録されている記録媒体。
【請求項１８】
他の情報処理装置から、ネットワークを介して送信される、フレーム間相関を用いて符号化されたデータの受信を制御する処理を実行するプログラムであって、
前記他の情報処理装置から送信された、前記データの伝送状況を含む所定の情報の受信を制御する受信制御ステップと、
前記受信制御ステップの処理により受信が制御された前記所定の情報を基に、前記他の情報処理装置に、フレーム内符号化により生成されるイントラフレームの送出を指令する情報を生成する生成ステップと
を含むことを特徴とするプログラム。
【請求項１９】
他の情報処理装置から、ネットワークを介して、データを受信する第１の情報処理装置と、
前記ネットワークを介して、他の情報処理装置にデータを送信する第２の情報処理装置と
で構成されるデータ通信システムにおいて、
前記第１の情報処理装置は、
前記第２の情報処理装置から送信された、前記データの伝送状況を含む第１
の情報を受信する第１の受信手段と、
前記第１の受信手段により受信された前記第１の情報を基に、前記第２の情報処理装置に、フレーム内符号化により生成されるイントラフレームの送出を
指令する第２の情報を生成する生成手段と、
前記生成手段により生成された前記第２の情報を、前記ネットワークを介して、前記第２の情報処理装置に送信する第１の送信手段と
を備え、
前記第２の情報処理装置は、
供給されたデータを、フレーム間相関を用いて符号化する符号化手段と、
前記第１の情報処理装置から、前記第２の情報を受信する第２の受信手段と、
前記第２の受信手段により受信された前記第２の情報を基に、前記符号化手
段を制御して、フレーム内符号化を実行させる制御手段と、
前記符号化手段によりフレーム間相関を用いて符号化された前記データ、および、前記データの伝送状況を含む前記第１の情報を、前記ネットワークを介
して、前記第１の情報処理装置に送信する第２の送信手段と
を備えることを特徴とするデータ通信システム。
【請求項２０】
他の情報処理装置から、ネットワークを介して、データを受信する第１の情報処理装置と、
前記ネットワークを介して、他の情報処理装置にデータを送信する第２の情報処理装置と
で構成されるデータ通信システムにおいて、
前記第１の情報処理装置は、
前記第２の情報処理装置から送信された、前記データを受信する第１の受信
手段と、
前記第２の情報処理装置に、前記ネットワークにおけるデータ通信状況に関
する情報を送信する第１の送信手段と
を備え、
前記第２の情報処理装置は、
供給されたデータを、フレーム間相関を用いて符号化する符号化手段と、
前記第１の情報処理装置から、前記データ通信状況に関する情報を受信する
第２の受信手段と、
前記第２の受信手段により受信された前記データ通信状況に関する情報を基に、前記符号化手段を制御して、フレーム内符号化を実行させる制御手段と、前記符号化手段によりフレーム間相関を用いて符号化された前記データを、前記ネットワークを介して、前記第１の情報処理装置に送信する第２の送信手
段と
を備えることを特徴とするデータ通信システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、情報処理装置および情報処理方法、データ通信システム、記録媒体、並びにプログラムに関し、特に、フレーム間相関を用いて符号化されたデータを送受信する場合に用いて好適な、情報処理装置および情報処理方法、データ通信システム、記録媒体、並びにプログラムに関する。
【０００２】
【従来の技術】
ＲＴＰ（Ｒｅａｌ  Ｔｉｍｅ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）／ＲＴＣＰ（ＲＴＰ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）を用いたデータの送受信における適応的レート制御方法としては、例えば、データ受信側の装置が、データ送信側の装置に対してパケット損失率やジッタなどを通知するＲＴＣＰのＲＲ（Ｒｅｃｅｉｖｅｒ  Ｒｅｐｏｒｔ）パケットに記載されている情報を基に、送信側の装置でデータの伝送状態を推定し、送信レートを制御するという方法が提案されている（例えば、特許文献１参照）。
【０００３】
【特許文献１】
特開平２００２−２０４２７８号公報
【０００４】
この方法によると、ＲＲパケットに含まれるパケット損失率やジッタなどの値を用いて、パケットが損失したときや、ネットワークの輻輳によりジッタが大きくなったときに、データ伝送レートを下げることが可能となる。
【０００５】
【発明が解決しようとする課題】
例えば、ＭＰＥＧ（Ｍｏｖｉｎｇ  Ｐｉｃｔｕｒｅ  Ｃｏｄｉｎｇ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐ／Ｍｏｖｉｎｇ  Ｐｉｃｔｕｒｅ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐ）などのように、フレーム間相関を用いた圧縮処理を行っているデータを伝送する場合においては、パケットロスのためにマクロブロックのエラーが数フレームにわたって伝播してしまう恐れがある。
【０００６】
一般に、パケットロスが発生したマクロブロックが、参照フレームとして参照されていた場合、そのマクロブロックのために発生したエラーが回復するためにかかる時間は、フレーム内符号化により生成され、他のフレームを参照せずに復号可能な、いわゆるイントラフレーム（Ｉフレームとも称する）の間隔に依存する。
【０００７】
例えば、図１に示されるように、ＭＰＥＧ２において、ＧＯＰ（Ｇｒｏｕｐ  Ｏｆ  Ｐｉｃｔｕｒｅｓ）は、圧縮前のデータをブロックごとにＤＣＴ演算したＩフレームと、既に符号化された現在のフレームよりも前のＩフレームおよびＰフレームの動き補償フレーム間予測誤差信号と動きベクトルを符号化したＰフレーム、並びに、既に符号化された現在のフレームよりも前と後の両方のＩフレームピおよびＰフレームの動き補償フレーム間予測誤差信号と動きベクトルを符号化したＢフレームで構成されている。
【０００８】
そのうち、Ｉフレームは、フレーム内符号化のため以、復号時に前のフレームの情報を必要としない唯一のフレームである。したがって、パケットロスによりマクロブロックのエラーが発生しても、次のＩフレームで、エラーの伝播が終了する。
【０００９】
このＩフレームの間隔は、例えば、ＭＰＥＧ１およびＭＰＥＧ２においては、０．５秒、ＭＰＥＧ４においては、１秒乃至数秒である。すなわち、Ｉフレーム内のマクロブロックでパケットロスが発生した場合、エラーが回復するために、Ｉフレーム間隔と同じだけの時間が必要となってしまう。
【００１０】
この問題に対応するために、例えば、エラーが発生したマクロブロックの情報を再送する方法も考えられるが、この方法を実現するためには、データ受信側が、必要なマクロブロックを送信側に要求したり、送信側が、パケットロスしたマクロブロックを再送することができるような構成を有する必要があるため、制御が複雑になり、また、コストが高くなる。
【００１１】
また、この問題に対応するために、Ｉフレームの発生間隔を短くする方法も考えられるが、Ｉフレームは、ＰフレームおよびＢフレームより、発生符号量が多いため、限られたネットワーク帯域を効率的に使用できなくなるという問題が発生する。
【００１２】
本発明はこのような状況に鑑みてなされたものであり、複雑な構成を設けることなく、できるだけ少ないＩフレームの発生量で、効果的に、パケットロスなどによるエラーの発生を防止したり、エラーが発生した場合には、早期に回復することが可能なようにするものである。
【００１３】
【課題を解決するための手段】
本発明の第１の情報処理装置は、供給されたデータを、フレーム間相関を用いて符号化する符号化手段と、他の情報処理装置から、ネットワークにおけるデータ通信状況に関する所定の情報を受信する受信手段と、受信手段により受信された所定の情報を基に、符号化手段を制御して、フレーム内符号化を実行させる制御手段と、符号化手段によりフレーム間相関を用いて符号化されたデータを、ネットワークを介して、他の情報処理装置に送信する送信手段とを備えることを特徴とする。
【００１４】
所定の情報は、フレーム内符号化により生成されるイントラフレームの送出を指令する情報であるものとすることができ、制御手段には、受信手段により、所定の情報が受信された場合、符号化手段を制御して、フレーム内符号化を実行させるようにすることができる。
【００１５】
所定の情報は、送信手段によるデータの送信レートを制御する制御情報であるものとすることができ、制御手段には、受信手段により、所定の情報が受信され、所定の情報が、データの送信レートを下げることを指令していた場合、符号化手段を制御して、フレーム内符号化を実行させるようにすることができる。
【００１６】
データは、ＲＦＣ１８８９に準拠するＲＴＰパケットであるものとすることができ、所定の情報は、ＲＦＣ１８８９に準拠するＲＴＣＰ  ＲＲパケットであるものとすることができる。
【００１７】
制御手段には、受信手段により受信された所定の情報を基に、パケットロス率を算出させて、その結果に基づいて、符号化手段にフレーム内符号化を実行させるか否かを判断させるようにすることができる。
【００１８】
制御手段には、受信手段により受信された所定の情報を基に、データの遅延の変動を算出させて、その結果に基づいて、符号化手段にフレーム内符号化を実行させるか否かを判断させるようにすることができる。
【００１９】
データは、ＲＦＣ１８８９に準拠するＲＴＰパケットであるものとすることができ、所定の情報は、ＲＦＣ１８８９に準拠するＲＴＣＰ  ＡＰＰパケットであるものとすることができる。
【００２０】
本発明の第１の情報処理方法は、他の情報処理装置から、ネットワークにおけるデータ通信状況に関する所定の情報の受信を制御する受信制御ステップと、受信制御ステップの処理により受信が制御された所定の情報を基に、符号化手段を制御して、フレーム内符号化を実行させる符号化制御ステップとを含むことを特徴とする。
【００２１】
本発明の第１の記録媒体に記録されているプログラムは、他の情報処理装置から、ネットワークにおけるデータ通信状況に関する所定の情報の受信を制御する受信制御ステップと、受信制御ステップの処理により受信が制御された所定の情報を基に、符号化手段を制御して、フレーム内符号化を実行させる符号化制御ステップとを含むことを特徴とする。
【００２２】
本発明の第１のプログラムは、他の情報処理装置から、ネットワークにおけるデータ通信状況に関する所定の情報の受信を制御する受信制御ステップと、受信制御ステップの処理により受信が制御された所定の情報を基に、符号化手段を制御して、フレーム内符号化を実行させる符号化制御ステップとを含むことを特徴とする。
【００２３】
本発明の第１の情報処理装置および情報処理方法、並びにプログラムにおいては、供給されたデータがフレーム間相関を用いて符号化され、他の情報処理装置から、ネットワークにおけるデータ通信状況に関する所定の情報が受信され、受信された所定の情報を基に、フレーム内符号化が実行される。
【００２４】
本発明の第２の情報処理装置は、他の情報処理装置から送信された、データの伝送状況を含む所定の情報を受信する受信手段と、受信手段により受信された所定の情報を基に、他の情報処理装置に、フレーム内符号化により生成されるイントラフレームの送出を指令する情報を生成する生成手段と、生成手段により生成されたイントラフレームの送出を指令する情報を、ネットワークを介して、他の情報処理装置に送信する送信手段とを備えることを特徴とする。
【００２５】
データは、ＲＦＣ１８８９に準拠するＲＴＰパケットであるものとすることができ、イントラフレームの送出を指令する情報は、ＲＦＣ１８８９に準拠するＲＴＣＰ  ＲＲパケットであるものとすることができる。
【００２６】
データは、ＲＦＣ１８８９に準拠するＲＴＰパケットであるものとすることができ、イントラフレームの送出を指令する情報は、ＲＦＣ１８８９に準拠するＲＴＣＰ  ＡＰＰパケットであるものとすることができる。
【００２７】
データは、ＲＦＣ１８８９に準拠するＲＴＰパケットであるものとすることができ、送信手段には、ＲＦＣ１８８９に準拠するＲＴＣＰ  ＲＲパケットの次の送出時刻までの時間が所定の時間より長かった場合、ＲＦＣ１８８９に準拠するＲＴＣＰ  ＡＰＰパケットにより、イントラフレームの送出を指令する情報を送信させるようにすることができ、ＲＴＣＰ  ＲＲパケットの次の送出時刻までの時間が所定の時間より短かった場合、ＲＴＣＰ  ＲＲパケットにより、イントラフレームの送出を指令する情報を送信させるようにすることができる。
【００２８】
データは、ＲＦＣ１８８９に準拠するＲＴＰパケットであるものとすることができ、送信手段には、ＲＦＣ１８８９に準拠するＲＴＣＰ  ＲＲパケット送出時刻を変更することが可能であるようにすることができ、ＲＴＣＰ  ＲＲパケットの次の送出予定時刻までの時間が所定の時間より長かった場合、ＲＴＣＰ  ＲＲパケットの送出時刻を早めて、イントラフレームの送出を指令する情報を送信させるようにすることができる。
【００２９】
本発明の第２の情報処理方法は、他の情報処理装置から送信された、データの伝送状況を含む所定の情報の受信を制御する受信制御ステップと、受信制御ステップの処理により受信が制御された所定の情報を基に、他の情報処理装置に、フレーム内符号化により生成されるイントラフレームの送出を指令する情報を生成する生成ステップとを含むことを特徴とする。
【００３０】
本発明の第２の記録媒体に記録されているプログラムは、他の情報処理装置から送信された、データの伝送状況を含む所定の情報の受信を制御する受信制御ステップと、受信制御ステップの処理により受信が制御された所定の情報を基に、他の情報処理装置に、フレーム内符号化により生成されるイントラフレームの送出を指令する情報を生成する生成ステップとを含むことを特徴とする。
【００３１】
本発明の第２のプログラムは、他の情報処理装置から送信された、データの伝送状況を含む所定の情報の受信を制御する受信制御ステップと、受信制御ステップの処理により受信が制御された所定の情報を基に、他の情報処理装置に、フレーム内符号化により生成されるイントラフレームの送出を指令する情報を生成する生成ステップとを含むことを特徴とする。
【００３２】
本発明の第２の情報処理装置および情報処理方法、並びに、プログラムにおいては、データの伝送状況を含む所定の情報が受信され、所定の情報を基に、他の情報処理装置に、フレーム内符号化により生成されるイントラフレームの送出を指令する情報が生成されて、送信される。
【００３３】
本発明の第１のデータ通信システムは、第１の情報処理装置が、第２の情報処理装置から送信された、データの伝送状況を含む第１の情報を受信する第１の受信手段と、第１の受信手段により受信された第１の情報を基に、第２の情報処理装置に、フレーム内符号化により生成されるイントラフレームの送出を指令する第２の情報を生成する生成手段と、生成手段により生成された第２の情報を、ネットワークを介して、第２の情報処理装置に送信する第１の送信手段とを備え、第２の情報処理装置が、供給されたデータを、フレーム間相関を用いて符号化する符号化手段と、第１の情報処理装置から、第２の情報を受信する第２の受信手段と、第２の受信手段により受信された第２の情報を基に、符号化手段を制御して、フレーム内符号化を実行させる制御手段と、符号化手段によりフレーム間相関を用いて符号化されたデータ、および、データの伝送状況を含む第１の情報を、ネットワークを介して、第１の情報処理装置に送信する第２の送信手段とを備えることを特徴とする。
【００３４】
本発明の第１のデータ通信システムにおいては、第１の情報処理装置で、第２の情報処理装置から送信された、データの伝送状況を含む第１の情報が受信され、受信された第１の情報を基に、第２の情報処理装置に、フレーム内符号化により生成されるイントラフレームの送出を指令する第２の情報が生成され、生成された第２の情報が、ネットワークを介して、第２の情報処理装置に送信され、第２の情報処理装置で、供給されたデータが、フレーム間相関を用いて符号化され、第１の情報処理装置から、第２の情報が受信され、受信された第２の情報を基に、フレーム内符号化が実行され、符号化されたデータ、および、データの伝送状況を含む第１の情報が、ネットワークを介して、第１の情報処理装置に送信される。
【００３５】
本発明の第２のデータ通信システムは、第１の情報処理装置が、第２の情報処理装置から送信された、データを受信する第１の受信手段と、第２の情報処理装置に、ネットワークにおけるデータ通信状況に関する情報を送信する第１の送信手段とを備え、第２の情報処理装置が、供給されたデータを、フレーム間相関を用いて符号化する符号化手段と、第１の情報処理装置から、データ通信状況に関する情報を受信する第２の受信手段と、第２の受信手段により受信されたデータ通信状況に関する情報を基に、符号化手段を制御して、フレーム内符号化を実行させる制御手段と、符号化手段によりフレーム間相関を用いて符号化されたデータを、ネットワークを介して、第１の情報処理装置に送信する第２の送信手段とを備えることを特徴とする。
【００３６】
本発明の第２のデータ通信システムにおいては、第１の情報処理装置で、第２の情報処理装置から送信されたデータが受信され、第２の情報処理装置に、ネットワークにおけるデータ通信状況に関する情報が送信され、第２の情報処理装置で、供給されたデータが、フレーム間相関を用いて符号化され、第１の情報処理装置から、データ通信状況に関する情報が受信され、受信されたデータ通信状況に関する情報を基に、フレーム内符号化が実行され、符号化されたデータが、ネットワークを介して、第１の情報処理装置に送信される。
【００３７】
【発明の実施の形態】
以下、図を参照して、本発明の実施の形態について説明する。
【００３８】
図２は、本発明を適用したデータ通信システムの第１の実施の形態における、データ送信装置３１およびデータ受信装置３２の構成を示すブロック図である。
【００３９】
データ送信装置３１およびデータ受信装置３２は、リアルタイム・データ転送プロトコルであるＲＴＰ（Ｒｅａｌ−ｔｉｍｅ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ）にしたがって、データの授受を行う。ＲＴＰは、例えば、映像と音声データを利用して遠隔会議を行うアプリケーションなどで利用されることを想定し、映像や音声データをリアルタイムに適した形で転送することを目的に設計されている。ＲＴＰにおいては、データが時間単位でパケットに分割されて送信される。また、ＲＴＰは、パケットロス対策や伝送時間保証などは行われていないＵＤＰ（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ）タイプのプロトコルで、通常は、ＲＴＣＰ（ＲＴＰ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）による通信状態レポートとセットで用いられる。
【００４０】
また、ネットワーク３３は、例えば、組織内で運営されているＬＡＮ（Ｌｏｃａｌ  Ａｒｉａ  Ｎｅｔｗｏｒｋ）であってもよいし、いわゆるインターネットのような不特定多数のネットワークが結合した、大規模なネットワークであってもよいし、または、所定の送信装置と受信装置を接続する専用回線であっても良い。
【００４１】
データ送信装置３１のエンコーダ４１は、例えば、音声、画像、映像、または、これらの混合したデータを、例えば、ＭＰＥＧ１，ＭＰＥＧ２、または、ＭＰＥＧ４などの、フレーム間相関を用いた圧縮符号化（フレーム内符号化、およびフレーム間符号化）を用いてエンコードして、図１を用いて説明したＩフレームを含むフレームを生成し、データ送信部４２に供給する。また、エンコーダ４１は、エンコード制御部４４から制御信号の供給を受けた場合、通常のエンコードにより生成されるフレームの順序によらず、Ｉフレームを生成し、データ送信部４２に供給する。
【００４２】
また、エンコーダ４１によりエンコードされて生成される符号化データのデータ量は、送信レート制御部４５により制御される。すなわち、送信されるデータのデータ量が制限されるので、データ送信レートが制御される。
【００４３】
データ送信部４２は、エンコーダ４１から供給されたデータをＲＴＰパケットとして送信する場合、例えば、５秒間などの所定の時間ごとに、ＲＴＣＰのＳＲ（Ｓｅｎｄｅｒ  Ｒｅｐｏｒｔ）パケットを付加して、ネットワーク３３を介して、データ受信装置３２に送信する。ＳＲパケットとは、データ送信側の送受信統計のためのレポートであり、データ伝送の状況を示す情報が記載されている。
【００４４】
図３にＳＲパケットのフォーマットを示す。
【００４５】
ヘッダは、ＲＴＰのバージョンを識別するための２ビットの情報であるバージョン情報（Ｖ）、このパケットが１以上のパディングオクテットを含んでいるか否かを示す情報である１ビットのパディングビット（Ｐ）、このパケットに含まれるレセプションレポートブロックの数を示す５ビットのレセプションレポートカウント（ＲＣ（ｒｅｃｅｐｔｉｏｎ  ｒｅｐｏｒｔ  ｃｏｕｎｔ））、ＳＲパケットとＲＲパケットを識別するために、ＳＲパケットであることを示す定数２００が記載されている８ビットのパケットタイプ（ＰＴ（ｐａｃｋｅｔ  ｔｙｐｅ））、このＲＴＣＰパケットの長さを示す１６ビットの情報であるパケット長（ｌｅｎｇｔｈ）、および、送信元ＳＳＲＣ識別子（ＳＳＲＣ  ｏｆ  ｓｅｎｄｅｒ）で構成されている。
【００４６】
そして、送信者情報（Ｓｅｎｄｅｒ  Ｉｎｆｏ）は、６４ビットのＮＴＰタイムスタンプ（Ｎｅｔｗｏｒｋ  Ｔｉｍｅ  Ｐｒｏｔｏｃｏｌ  ｔｉｍｅｓｔａｍｐ）、３２ビットのＲＴＰタイムスタンプ（Ｒｅａｌ−ｔｉｍｅ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ  ｔｉｍｅｓｔａｍｐ）、３２ビットの送出パケット数情報（ｓｅｎｄｅｒ’ｓ  ｐａｃｋｅｔ  ｃｏｕｎｔ）、および、３２ビットの送出データ量情報（ｓｅｎｄｅｒ’ｓ  ｏｃｔｅｔ  ｃｏｕｎｔ）で構成されている。
【００４７】
レポートブロックは、３２ビットのＳＳＲＣ識別子番号（ＳＳＲＣ＿ｎ  （ｓｏｕｒｃｅ  ｉｄｅｎｔｉｆｉｅｒ））、パケットロス率を示すフラクションロスト（ｆｒａｃｔｉｏｎ  ｌｏｓｔ）、累積パケットロス数（ｃｕｍｕｌａｔｉｖｅ  ｎｕｍｂｅｒ  ｏｆ  ｐａｃｋｅｔｓ  ｌｏｓｔ）、シーケンスナンバーの最大値（ｅｘｔｅｎｄｅｄ  ｈｉｇｈｅｓｔ  ｓｅｑｕｅｎｃｅ  ｎｕｍｂｅｒ  ｒｅｃｅｉｖｅｄ）、ＲＴＰパケットの到着時間間隔の変動を示すインターアライバルジッタ（ｉｎｔｅｒａｒｒｉｖａｌ  ｊｉｔｔｅｒ）、最新のＳＲパケット受信時のタイムスタンプの情報であるＬＳＲ（ｌａｓｔ  ＳＲ）、および、ＬＳＲからの遅延を示すＤＬＳＲ（ｄｅｌａｙ  ｓｉｎｃｅ  ｌａｓｔ  ＳＲ（ＤＬＳＲ））で構成されている。
【００４８】
また、ＳＲパケットには、更に、特別拡張領域（ｐｒｏｆｉｌｅ−ｓｐｅｃｉｆｉｃ  ｅｘｔｅｎｓｉｏｎｓ）が設けられている。
【００４９】
このように、ＳＲパケットには、ＮＴＰタイムスタンプ、および、ＲＴＰタイムスタンプが含まれている。
【００５０】
データ受信部４３は、データ受信装置３２から送信される、ＲＴＣＰにおけるＲＲ（Ｒｅｃｅｉｖｅｒ  Ｒｅｐｏｒｔ）パケット、または、ＡＰＰ（Ａｐｐｌｉｃａｔｉｏｎ  ｄｅｆｉｎｅｄ  ＲＴＣＰ）パケットを受信する。ＲＲパケットは、データ受信側からの受信統計のためのレポートである。ＡＰＰパケットとは、アプリケーション拡張用のパケットである。データ受信部４３は、ＲＴＣＰにおけるＲＲパケット、または、ＡＰＰパケットに、リフレッシュ命令が含まれていた場合、リフレッシュ命令を、エンコード制御部４４に供給する。
【００５１】
図４に、ＲＲパケットのフォーマットを示す。
【００５２】
ＲＲパケットのフォーマットは、パケットタイプ（ＰＴ（ｐａｃｋｅｔ  ｔｙｐｅ））に、ＲＲパケットであることを示す定数２０１が記載され、送信元ＳＳＲＣ識別子（ＳＳＲＣ  ｏｆ  ｓｅｎｄｅｒ）に代わって、受信したＲＴＰパケットの送信元ＳＳＲＣ識別子（ＳＳＲＣ  ｏｆ  ｐａｃｋｅｔ  ｓｅｎｄｅｒ）が記載されている以外は、ＳＲパケットと同一のヘッダ構造を有しており、ＳＲパケットに含まれていた送信者情報を含んでいないが、ＳＲパケットと同様のレポートブロックと、特別拡張領域を有している。
【００５３】
図５にＡＰＰパケットのフォーマットを示す。
【００５４】
ＡＰＰパケットは、ＲＴＰのバージョンを識別するための２ビットの情報であるバージョン情報（Ｖ）、このパケットが１以上のパディングオクテットを含んでいるか否かを示す情報である１ビットのパディングビット（Ｐ）、このパケットの定義を識別するためのサブタイプ（ｓｕｂｔｙｐｅ）、このパケットがＡＰＰパケットであることを示す定数２０４が記載されている８ビットのパケットタイプ（ＰＴ（ｐａｃｋｅｔ  ｔｙｐｅ））、このＲＴＣＰパケットの長さを示す１６ビットの情報であるパケット長（ｌｅｎｇｔｈ）、ＳＳＲＣ識別子、または、送信関係者（ミキサーによってミックスされた場合の元の送信者ＩＤ）であるＣＳＲＣ（Ｃｏｎｔｒｉｂｕｔｉｎｇｓｏｕｒｃｅ）識別子、ＡＳＣＩＩコードで記載されるＡＰＰパケットに固有に付けられた名称（ｎａｍｅ）、および、アプリケーションに依存する情報（ａｐｐｌｉｃａｔｉｏｎ  ｄｅｐｅｎｄｅｎｔ  ｄａｔａ）で構成される。
【００５５】
エンコード制御部４４は、データ受信部４３から供給されるリフレッシュ命令を基に、Ｉフレームを生成して送信させるための制御信号を生成し、エンコーダ４１に供給する。
【００５６】
送信レート制御部４５は、データ受信部４３から供給された情報を基に、送信レート制御信号を生成し、エンコーダ４１に供給して、データの発生量を制御することにより、送信されるデータの送信レートを制御する。
【００５７】
ここでは、一般的なＭＰＥＧ２やＭＰＥＧ４の場合の送信レート制御を行う場合について説明したが、例えば、階層符号化を用いた符号化処理が行われている場合、送信レート制御部４５は、データ送信部４２を制御して、送信レートを制御する。
【００５８】
データ受信装置３２のデータ受信部５１は、ネットワーク３３を介して、データ送信装置３１から、ＳＲパケットおよびＲＴＰパケットを受信し、ＲＴＰパケットの、例えば、映像、音声、テキストなどのデータを、データ処理部５２に供給する。また、データ受信部５１は、ＲＴＰパケットの受信時刻、特に、ＲＴＰパケットがＩフレームである場合、Ｉフレームを受信した時刻を示す情報を、リフレッシュ命令生成部５３に供給するとともに、ＲＴＰパケットに記載されているタイムスタンプ、パケットサイズ、シーケンス番号、ＳＲパケットに記載されている時間情報など、リフレッシュ命令を生成するか否かの判断、または、リフレッシュ命令の生成に必要な情報を、リフレッシュ命令生成部５３に供給する。
【００５９】
データ処理部５２は、データ受信部５１から供給されたデータに対する処理を実行する。具体的には、データ処理部５２は、供給されたデータに対して、例えば、復号処理、デスクランブル処理、表示処理、または、音声再生処理などを実行する。
【００６０】
データ送信部５４は、データ送信装置３１から送信されたＲＴＰパケットに対して、図４を用いて説明したＲＲパケット（リフレッシュ命令を含まないＲＲパケット）を生成し、ネットワーク３３を介して、データ送信装置３１に送信する。
【００６１】
リフレッシュ命令生成部５３は、データ受信部５１から供給された情報を基に、フレッシュ命令を生成するか否かを判断し、必要に応じてリフレッシュ命令を生成し、リフレッシュ命令送信部５５に供給する。
【００６２】
リフレッシュ命令送信部５５は、リフレッシュ命令生成部５３から供給されたリフレッシュ命令を、ＲＴＣＰのＡＰＰパケット、または、ＲＲパケットとして、ネットワーク３３を介して、データ送信装置３１に送信する。
【００６３】
図２のデータ送信装置３１およびデータ受信装置３２においては、データの送受信を、複数のブロックにおいて実行するものとして説明したが、データ送信装置３１は、データ送信部４２、および、データ受信部４３が実行する処理を、１つの送受信機能により実行することができるようにしても良いし、データ受信装置３２は、データ受信部５１、データ送信部５４、および、リフレッシュ命令送信部５５が実行する処理を、１つ、または２つの送受信機能により実行することができるようにしても良い。
【００６４】
次に、データ送信装置３１およびデータ受信装置３２の動作について説明する。
【００６５】
データ送信装置３１のエンコーダ４１は、図示しないデータ入力部から、例えば、音声、画像、映像、テキストデータ、または、これらの混合したデータの入力を受けて、例えば、ＭＰＥＧ２やＭＰＥＧ４などの方法でエンコードし、データ送信部４２に供給する。
【００６６】
データ送信部４２は、エンコーダ４１から供給されたデータを時間単位でパケットに分割し、所定の時間ごとにＳＲパケットを付加して、ネットワーク３３を介して、データ受信装置３２に送信する。
【００６７】
データ受信装置３２のデータ受信部５１は、ネットワーク３３を介して、データ送信装置３１から、ＲＴＰパケットおよびＲＴＣＰ  ＳＲパケットを受信する。データ受信部５１は、データ処理部５２に、例えば、映像、音声、テキストなどのデータを供給するとともに、ＲＴＰパケットの受信時刻、特に、ＲＴＰパケットがＩフレームである場合は、Ｉフレームの受信時刻を示す情報、タイムスタンプ、シーケンス番号、ＳＲパケットに記載されている時間情報などを、リフレッシュ命令生成部５３に供給する。
【００６８】
また、データ受信部５１は、受信したパケットに、例えば、アクセスラインのビット誤りによるフレームの破棄や、ボトルネックリンクにおけるパケットの破棄などのパケットロスが発生した場合、パケットロスに関する情報を、リフレッシュ命令生成部５３に供給する。
【００６９】
図６は、リフレッシュ命令生成部５３の機能を示す機能ブロック図である。
【００７０】
データ取得部８１は、データ受信部５１から、ＳＲパケットに含まれている時間情報や、ＲＴＰパケットの受信時刻、タイムスタンプ、パケットサイズ、シーケンス番号などの、データの遅延やパケットロス率を求めるために必要な情報を取得して、パケットロス率演算部８２、および、片方向遅延演算部８４に供給するとともに、特に、ＲＴＰパケットがＩフレームである場合は、Ｉフレームの受信時刻を示す情報を取得し、Ｉフレーム間隔測定部８６に供給する。また、データ取得部８１は、Ｉフレームの受信時刻を、Ｉフレーム受信時刻予測部８９に供給する。
【００７１】
パケットロス率演算部８２は、例えば、所定の時間（例えば、数１００ｍｓｅｃ乃至１ｓｅｃ）における受信パケット数とパケットロス数を累積し、次の式（１）より、パケットロス率を演算する。
【００７２】
パケットロス率Ｌ＝パケットロス数／（受信パケット数＋パケットロス数）・・・（１）
【００７３】
パケットロス率記録部８３は、パケットロス率演算部８２により演算されたパケットロス率の供給を受けて、記録する。
【００７４】
片方向遅延演算部８４は、ＳＲパケットのＮＴＰの値を基に、または、Ｉフレーム間隔を基に、片方向遅延（ＯＷＤ：Ｏｎｅ  Ｗａｙ  Ｄｅｌａｙ）を求める。片方向遅延記録部８５は、片方向遅延演算部８４により演算された片方向遅延の値の供給を受けて、記録する。
【００７５】
Ｉフレーム間隔測定部８６は、供給されたＩフレームの受信時刻を基に、Ｉフレーム間隔を測定する。Ｉフレーム間隔記録部８７は、Ｉフレーム間隔測定部８６が測定したＩフレーム間隔の値の供給を受けて、例えば、最新から２０などの所定数のＩフレーム間隔を記録する。
【００７６】
リフレッシュ命令発行部８８は、タイマ９０を参照し、所定のタイミングで、パケットロス率記録部８３に記録されているパケットロス率を、所定の閾値と比較し、パケットロス率が所定の閾値より大きい場合、Ｉフレーム間隔記録部８７に記録されているＩフレーム間隔の値を、Ｉフレーム受信時刻予測部８９に供給する。そして、Ｉフレーム受信時刻予測部８９の処理により得られた予測Ｉフレーム受信時刻までの時間が、片方向遅延記録部８５に記録されている片方向遅延時間より長かった場合、リフレッシュ命令を生成し、リフレッシュ命令送信部５５に供給する。
【００７７】
Ｉフレーム受信時刻予測部８９は、供給されたＩフレーム受信時刻、およびＩフレーム間隔の情報を基に、リフレッシュ命令が発行されなかった場合において、次にＩフレームを受信する時刻を予測し、リフレッシュ命令発行部８８に供給する。
【００７８】
このようにして、リフレッシュ命令生成部５３において、受信されたＩフレームの受信時刻、並びに、ＲＴＰパケットおよびＳＲパケットに含まれる情報に基づいて、リフレッシュ命令が生成される。
【００７９】
リフレッシュ命令送信部５５は、リフレッシュ命令生成部５３からリフレッシュ命令の供給を受けると、次のＲＲパケットの送出タイミングを求め、次のＲＲパケットの送出タイミングまでの時間が、例えば、１秒などの、所定の時間以上である場合、ＡＰＰパケットを用いて、リフレッシュ命令をデータ送信装置３１に送信し、次のＲＲパケットの送出タイミングまでの時間が、例えば、２００ｍｓなどの、所定の時間以内である場合、ＲＲパケットを用いて、リフレッシュ命令をデータ送信装置３１に送信する。
【００８０】
データ送信装置３１のデータ受信部４３は、ＲＲパケット、または、ＡＰＰパケットを受信し、受信したＲＲパケット、または、ＡＰＰパケットにリフレッシュ命令が含まれている場合、エンコード制御部４４に供給する。また、データ受信部４３は、受信したＲＲパケット、または、ＡＰＰパケットに含まれる、タイムスタンプの情報や、パケットロス率、ジッタなどの情報を、送信レート制御部４５に供給する。
【００８１】
送信レート制御部４５は、データ受信部４３から供給された情報を基に、送信レート制御信号を生成し、エンコーダ４１に供給する。
【００８２】
エンコード制御部４４は、データ受信部４３から、リフレッシュ命令の入力を受けた場合、通常のフレーム順（例えば、ＭＰＥＧ２によれば、ＩＢＢＰＢＢＰ・・・の順番）にかかわらず、次にエンコードして生成されるフレームがＩフレームとなるようにエンコードを制御するための制御信号を生成し、エンコーダ４１に供給する。
【００８３】
エンコーダ４１は、エンコード制御部４４から供給された制御信号に基づいて、リフレッシュ命令が発行された場合は、フレーム内符号化を行ってＩフレームを生成し、それ以外の場合は、予め定められたエンコード方式に基づいて、エンコードを行い、エンコードされた符号化データを、データ送信部４２に供給する。また、エンコーダ４１は、送信レート制御部４５の制御に基づいて、符号化データの生成量を決定する。
【００８４】
データ送信部４２は、供給された符号化データを、時間ごとに分割してＲＴＰパケットを生成し、ＲＴＰパケットを、ネットワーク３３を介して、データ受信装置３２に送信する。また、データ送信部４２は、例えば、５秒などの所定の時間ごとに、上述したＳＲパケットを生成し、ネットワーク３３を介して、データ受信装置３２に送信する。
【００８５】
このようにして、データ送信装置３１は、ネットワーク３３の負荷にならないように、できるだけ少ない頻度で、かつ、データ受信装置３２において、パケットロスによるエラーが発生しにくい、または、発生しても、エラー伝播時間が短くなるように、Ｉフレームを、通常のエンコード処理におけるフレーム順にかかわらずに生成して、データ受信装置３２に送信することができる。
【００８６】
次に、図７および図８のフローチャートを参照して、データ受信装置３２が実行するリフレッシュ命令発行処理１について説明する。
【００８７】
ステップＳ１１において、データ受信装置３２のデータ受信部５１は、ネットワーク３３を介して、データ送信装置３１から送信されたＲＴＰパケットおよびＲＴＣＰのＳＲパケットを受信し、ＲＴＰパケットに含まれている、例えば、ＭＰＥＧ２などによる動画データなどをデータ処理部５２に供給し、ＲＴＰパケット、および、ＲＴＣＰのＳＲパケットに含まれている情報のうち、リフレッシュ命令を生成するか否かを判断するために必要な情報を、リフレッシュ命令生成部５３に供給する。リフレッシュ命令生成部５３のデータ取得部８１は、パケットロス率演算部８２、片方向遅延演算部８４、Ｉフレーム間隔測定部８６、および、Ｉフレーム受信時刻予測部８９の処理に必要な情報を、それぞれ供給する。
【００８８】
ステップＳ１２において、片方向遅延演算部８４は、ＳＲパケットのＮＴＰが利用可能であるか否かを判断する。例えば、ＳＲパケットのＮＴＰが明らかにずれていたり、ＳＲパケットを受信することができなかった場合などに、ＳＲパケットのＮＴＰが利用可能ではないと判断される。
【００８９】
ステップＳ１２において、ＳＲパケットのＮＴＰが利用可能であると判断された場合、ステップＳ１３において、片方向遅延演算部８４は、ＲＴＰタイムスタンプを基に、片方向遅延を求め、片方向遅延記録部８５に供給する。片方向遅延記録部８５は、供給された片方向遅延を記録する。
【００９０】
ステップＳ１２において、ＳＲパケットのＮＴＰが利用可能ではないと判断された場合、片方向遅延演算部８４は、ＳＲパケットのＮＴＰが利用可能ではないことを、リフレッシュ命令発行部８８に通知するので、ステップＳ１４において、リフレッシュ命令発行部８８は、リフレッシュ命令が、まだ１度も発行されていないか否かを判断する。
【００９１】
ステップＳ１４において、リフレッシュ命令がすでに発行されていると判断された場合、処理は、後述するステップＳ１８に進む。ステップＳ１４において、リフレッシュ命令が、まだ１度も発行されていないと判断された場合、リフレッシュ命令を発行する必要があるので、ステップＳ１５において、リフレッシュ命令発行部８８は、リフレッシュ命令を発行し、リフレッシュ命令送信部５５に供給する。リフレッシュ命令送信部５５は、次のＲＲパケットの送信タイミングが、例えば、２００ｍｓなど、通常のＲＲパケットの送信間隔よりも十分短い所定の時間以内であるか否かを判断する。
【００９２】
ステップＳ１５において、次のＲＲパケットの送信タイミングは、所定の時間以内であると判断された場合、ステップＳ１６において、リフレッシュ命令送信部５５は、供給されたリフレッシュ命令を、次のＲＲパケットにより、ネットワーク３３を介して、データ送信装置３１に送信し、リフレッシュ命令の送信時刻を内部の記録部に記録する。
【００９３】
ステップＳ１５において、次のＲＲパケットの送信タイミングは、所定の時間以内ではないと判断された場合、ステップＳ１７において、リフレッシュ命令送信部５５は、予め送信タイミングが規制されていないＡＰＰパケットでリフレッシュ命令を発行するものとし、供給されたリフレッシュ命令をＡＰＰパケットとして、ネットワーク３３を介して、データ送信装置３１に送信し、リフレッシュ命令の送信時刻を内部の記録部に記録する。
【００９４】
ステップＳ１３、ステップＳ１６、または、ステップＳ１７の処理の終了後、ステップＳ１８において、Ｉフレーム間隔測定部８６は、受信したデータは、Ｉフレームであるか否かを判断する。
【００９５】
ステップＳ１８において、受信したデータは、Ｉフレームであると判断された場合、ステップＳ１９において、Ｉフレーム間隔測定部８６は、１つ前のＩフレームの受信時刻を基に、Ｉフレーム間隔を測定して、Ｉフレーム間隔記録部８７に供給する。Ｉフレーム間隔記録部８７は、供給された新たなＩフレーム間隔の測定値を記録する。
【００９６】
ステップＳ２０において、片方向遅延演算部８４は、ステップＳ１２において、ＳＲパケットのＮＴＰが利用可能であったか否かを判断する。ステップＳ２０において、ＳＲパケットのＮＴＰが利用可能であったと判断された場合、ステップＳ１３において、ＲＴＰタイムスタンプを基に、片方向遅延が求められているので、ステップＳ２１の処理はスキップされ、処理は、ステップＳ２２に進む。
【００９７】
ステップＳ２０において、ＳＲパケットのＮＴＰが利用可能ではなかったと判断された場合、まだ、片方向遅延が求められていないので、ステップＳ２１において、片方向遅延演算部８４は、ステップＳ１９においてＩフレーム間隔測定部８６により算出され、Ｉフレーム間隔記録部８７に記録されているＩフレーム間隔を基に、片方向遅延を求める。
【００９８】
すなわち、ＳＲパケットのＮＴＰが利用可能ではなかったと判断された場合、リフレッシュ命令がデータ送信装置３１に送信されているので、データ送信装置３１から、Ｉフレームが送信される。したがって、Ｉフレーム間隔が、通常の値と異なっていた場合、そのＩフレームは、リフレッシュ命令を受けて発行されたＩフレームであると判断できるので、見かけ上のＲＴＴ（Ｒｏｕｎｄ  Ｔｒｉｐ  Ｔｉｍｅ）を求めることができる。したがって、ステップＳ２１においては、この見かけ上のＲＴＴを２で割ることにより、片方向遅延を求めることができる。
【００９９】
ステップＳ２２において、パケットロス率演算部８２は、供給された情報を基に、上述した式（１）を用いて、パケットロス率を演算し、パケットロス率記録部８３に供給する。パケットロス率記録部８３は、供給されたパケットロス率を記録する。
【０１００】
ステップＳ２３において、リフレッシュ命令発行部８８は、パケットロス率記録部８３に記録されているパケットロス率が、予め定められている所定の閾値以上であるか否かを判断する。ここで、所定の閾値は、データ受信装置３２において、パケットロスによるデコードのエラーが発生し、場合によっては、エラーが伝播してしまう恐れがあると考えられるパケットロス率を基に、予め定められて、設定される。ステップＳ２３において、パケットロス率が所定の閾値以上ではないと判断された場合、処理は、ステップＳ１１に戻り、それ以降の処理が繰り返される。
【０１０１】
ステップＳ２３において、パケットロス率が所定の閾値以上であると判断された場合、ステップＳ２４において、リフレッシュ命令発行部８８は、Ｉフレーム間隔記録部８７に記録されているＩフレーム間隔の値を、Ｉフレーム受信時刻予測部８９に供給し、Ｉフレーム受信時刻予測部８９を制御して、次のＩフレームの受信時刻を予測させる。Ｉフレーム受信時刻予測部８９は、データ取得部８１から供給された供給されたＩフレーム受信時刻、および、リフレッシュ命令発行部８８から供給されたＩフレーム間隔を基に、リフレッシュ命令が発行されなかった場合に次に受信されるＩフレームの受信時刻を予測する。
【０１０２】
ステップＳ２５において、リフレッシュ命令発行部８８は、片方向遅延記録部８５に記録されている片方向遅延、Ｉフレーム間隔記録部８７に記録されているＩフレーム間隔、パケットロス率記録部８３に記録されているパケットロス率、および、ステップＳ２４においてＩフレーム受信時刻予測部８９により予測された、リフレッシュ命令が発行されない場合における次のＩフレームの到着時刻を、それぞれ読み出す。
【０１０３】
ステップＳ２６において、リフレッシュ命令発行部８８は、ステップＳ２５において読み出された値を基に、リフレッシュ命令を送信するか否かを判断する。リフレッシュ命令発行部８８は、パケットロス率が所定の値以上であり、次のＩフレームの予測受信時刻までの時間が、片方向遅延よりも長かった場合、リフレッシュ命令を送信すると判断する。
【０１０４】
ステップＳ２６において、リフレッシュ命令を送信しないと判断された場合、処理は、ステップＳ１１に戻り、それ以降の処理が繰り返される。ステップＳ２６において、リフレッシュ命令を送信すると判断された場合、ステップＳ２７において、リフレッシュ命令発行部８８は、リフレッシュ命令を発行し、リフレッシュ命令送信部５５は、次のＲＲパケットの送信タイミングは、例えば、２００ｍｓなど、通常のＲＲパケットの送信間隔よりも十分短い所定の時間以内であるか否かを判断する。
【０１０５】
ステップＳ２７において、次のＲＲパケットの送信タイミングは、所定の時間以内であると判断された場合、ステップＳ２８において、リフレッシュ命令送信部５５は、供給されたリフレッシュ命令を次のＲＲパケットとして、ネットワーク３３を介して、データ送信装置３１に送信し、リフレッシュ命令の送信時刻を内部の記録部に記録して、処理は、ステップＳ１１に戻り、それ以降の処理が繰り返される。
【０１０６】
ステップＳ２７において、次のＲＲパケットの送信タイミングは、所定の時間以内ではないと判断された場合、ステップＳ２９において、リフレッシュ命令送信部５５は、予め送信タイミングが規定されていないＡＰＰパケットでリフレッシュ命令を発行するものとし、供給されたリフレッシュ命令をＡＰＰパケットとして、ネットワーク３３を介して、データ送信装置３１に送信し、リフレッシュ命令の送信時刻を内部の記録部に記録して、処理は、ステップＳ１１に戻り、それ以降の処理が繰り返される。
【０１０７】
このような処理により、リフレッシュ命令が生成されて、ＲＲパケット、または、ＡＰＰパケットのうちの、適するパケットを用いて、データ送信装置３１に送信される。
【０１０８】
また、図７および図８を用いて説明した処理においては、ＲＲパケットの送信タイミングまで時間がある場合、ＡＰＰパケットを用いて、リフレッシュ命令を送信するものとして説明したが、ＲＲパケットの送信時刻を制御することにより、リフレッシュ命令を、従来のＲＲパケットの送信間隔と異なるタイミングでデータ送信装置３１に送信することができるようにしても良い。
【０１０９】
図９および図１０を用いて、ＲＲパケットの送信時刻を制御する場合の、リフレッシュ命令発行処理２について説明する。
【０１１０】
ステップＳ４１乃至ステップＳ４５において、図７を用いて説明したステップＳ１１乃至ステップＳ１５と、同様の処理が実行される。
【０１１１】
すなわち、データ送信装置３１から送信されたＲＴＰパケットおよびＲＴＣＰのＳＲパケットが受信され、ＳＲパケットのＮＴＰが利用可能であるか否かが判断される。ＳＲパケットのＮＴＰが利用可能であると判断された場合、ＲＴＰタイムスタンプを基に、片方向遅延が求められ、ＳＲパケットのＮＴＰが利用可能ではないと判断された場合、リフレッシュ命令が、まだ１度も発行されていないか否が判断される。そして、リフレッシュ命令がすでに発行されていると判断された場合、処理は、後述するステップＳ４８に進み、リフレッシュ命令が、まだ１度も発行されていないと判断された場合、リフレッシュ命令を発行する必要があるので、次のＲＲパケットの送信タイミングは、例えば、２００ｍｓなど、通常のＲＲパケットの送信間隔よりも十分短い所定の時間以内であるか否かが判断される。
【０１１２】
ステップＳ４５において、次のＲＲパケットの送信タイミングは、所定の時間以内であると判断された場合、ステップＳ４６において、リフレッシュ命令送信部５５は、供給されたリフレッシュ命令を、次のＲＲパケットとして、ネットワーク３３を介して、データ送信装置３１に送信し、リフレッシュ命令の送信時刻を内部の記録部に記録する。
【０１１３】
ステップＳ４５において、次のＲＲパケットの送信タイミングは、所定の時間以内ではないと判断された場合、ステップＳ４７において、リフレッシュ命令送信部５５は、ＲＲパケットの発行タイミングを変更して、ＲＲパケットでリフレッシュ命令を発行するものとし、供給されたリフレッシュ命令をＲＲパケットとして、ネットワーク３３を介して、データ送信装置３１に送信し、リフレッシュ命令の送信時刻を内部の記録部に記録する。
【０１１４】
ステップＳ４３、ステップＳ４６、または、ステップＳ４７の処理の終了後、ステップＳ４８乃至ステップＳ５７において、図７および図８を用いて説明した、ステップＳ１８乃至ステップＳ２７と同様の処理が実行される。
【０１１５】
すなわち、受信したデータが、Ｉフレームであるか否かが判断されて、Ｉフレームであると判断された場合、１つ前のＩフレームの受信時刻を基に、Ｉフレーム間隔が測定されて、ＳＲパケットのＮＴＰが利用可能であったか否かが判断される。ＳＲパケットのＮＴＰが利用可能ではなかったと判断された場合、まだ、片方向遅延が求められていないので、Ｉフレーム間隔を基に、見かけ上のＲＴＴから片方向遅延が求められる。
【０１１６】
そして、パケットロス率が演算されて、パケットロス率が、予め定められている所定の閾値以上であるか否かが判断される。パケットロス率が所定の閾値以上ではないと判断された場合、処理は、ステップＳ４１に戻り、それ以降の処理が繰り返される。パケットロス率が所定の閾値以上であると判断された場合、次のＩフレームの受信時刻が予測され、片方向遅延、フレーム間隔、パケットロス率、および、次のＩフレームの到着時刻が読み出されて、リフレッシュ命令を送信するか否かが判断される。リフレッシュ命令を送信しないと判断された場合、処理は、ステップＳ４１に戻り、それ以降の処理が繰り返される。リフレッシュ命令を送信すると判断された場合、次のＲＲパケットの送信タイミングは、例えば、２００ｍｓなど、通常のＲＲパケットの送信間隔よりも十分短い所定の時間以内であるか否かが判断される。
【０１１７】
ステップＳ５７において、次のＲＲパケットの送信タイミングは、所定の時間以内であると判断された場合、ステップＳ５８において、リフレッシュ命令送信部５５は、供給されたリフレッシュ命令を、次のＲＲパケットとして、ネットワーク３３を介して、データ送信装置３１に送信し、リフレッシュ命令の送信時刻を内部の記録部に記録して、処理は、ステップＳ４１に戻り、それ以降の処理が繰り返される。
【０１１８】
ステップＳ５７において、次のＲＲパケットの送信タイミングは、所定の時間以内ではないと判断された場合、ステップＳ５９において、リフレッシュ命令送信部５５は、ＲＲパケットの発行タイミングを変更して、ＲＲパケットでリフレッシュ命令を発行するものとし、供給されたリフレッシュ命令をＲＲパケットとして、ネットワーク３３を介して、データ送信装置３１に送信し、リフレッシュ命令の送信時刻を内部の記録部に記録して、処理は、ステップＳ４１に戻り、それ以降の処理が繰り返される。
【０１１９】
このような処理により、データ受信装置３２は、ＡＰＰパケットを用いず、ＲＲパケットの送出タイミングを制御することにより、エラー伝播が長時間続かないようなタイミングで、データ送信装置３１にリフレッシュ命令を送信することができる。
【０１２０】
次に、図１１のフローチャートを参照して、図７および図８を用いて説明したリフレッシュ命令発行処理１、または、図９および図１０を用いて説明したリフレッシュ命令発行処理２において発行されたリフレッシュ命令を受信する、データ送信装置３１が実行するＩフレーム挿入処理１について説明する。
【０１２１】
ステップＳ７１において、データ送信装置３１のデータ受信部４３は、ＲＲパケット、または、ＡＰＰパケットを受信したか否かを判断する。ステップＳ７１において、ＲＲパケット、または、ＡＰＰパケットを受信していないと判断された場合、受信したと判断されるまで、ステップＳ７１の処理が繰り返される。
【０１２２】
ステップＳ７１において、ＲＲパケット、または、ＡＰＰパケットを受信したと判断された場合、ステップＳ７２において、データ受信部４３は、受信したＲＲパケット、またはＡＰＰパケットに、リフレッシュ命令が含まれているか否かを判断する。例えば、データ受信装置３２が実行する処理が、図７および図８を用いて説明したリフレッシュ命令発行処理１であった場合、データ受信部４３が受信するＲＲパケットおよびＡＰＰパケットのいずれにも、リフレッシュ命令が含まれている可能性があるが、データ受信装置３２が実行する処理が、図９および図１０を用いて説明したリフレッシュ命令発行処理２であった場合、データ受信部４３が受信するＲＲパケットにのみ、リフレッシュ命令が含まれている可能性がある。ステップＳ７２において、リフレッシュ命令が含まれていないと判断された場合、処理は、ステップＳ７１に戻り、それ以降の処理が繰り返される。
【０１２３】
ステップＳ７２において、リフレッシュ命令が含まれていると判断された場合、ステップＳ７３において、データ受信部４３は、エンコード制御部４４にリフレッシュ命令を供給する。エンコード制御部４４は、エンコーダ４１によるエンコードを制御し、Ｉフレームを生成させて、データ送信部４２に供給させる。そして、データ送信部４２は、データ受信装置３２に、ネットワーク３３を介して、ＲＴＰパケットでＩフレームを送信し、処理は、ステップＳ７１に戻り、それ以降の処理が繰り返される。
【０１２４】
なお、送信するＲＴＰパケットに、Ｉフレームが挿入される制御が行われているとき以外は、通常のデコードタイミングにより生成されたフレーム（例えば、ＭＰＥＧ２であれば、ＩＢＢＰＢＢＰＢＢＰ・・・の順で生成されるフレーム）のＲＴＰパケットが、ネットワーク３３を介して、データ受信装置３２に送信される。
【０１２５】
このような処理により、データ送信装置３１では、リフレッシュ命令を基に、デコードが制御されて、必要に応じて、Ｉフレームが生成されて、ＲＴＰパケットとして、データ受信装置３２に送信されるので、例えば、送信するデータを全てＩフレームとしたり、Ｉフレームの発生頻度を高くするなどして、ネットワークに負荷をかけることなく、パケットロスなどによるエラー伝播を未然に防ぐ、または、エラー伝播時間を短くすることが可能となる。
【０１２６】
次に、図１２は、本発明を適用したデータ通信システムの第２の実施の形態における、データ送信装置１０１およびデータ受信装置１０２の構成を示すブロック図である。
【０１２７】
なお、図２における場合と対応する部分には同一の符号を付してあり、その説明は適宜省略する。
【０１２８】
すなわち、図１２のデータ送信装置１０１は、図２のエンコード制御部４４に代わって、エンコード制御部１１１が設けられている以外は、図２を用いて説明したデータ送信装置３１と同様の構成を有するものである。エンコード制御部１１１は、データ受信装置１０２において生成され、送信されるレート制御命令に基づいて、Ｉフレームの挿入が必要か否かを判断し、エンコーダ４１によるエンコード処理を制御する制御信号を生成する。
【０１２９】
また、図１２のデータ受信装置１０２は、図２のリフレッシュ命令生成部５３およびリフレッシュ命令送信部５５に代わって、ネットワーク３３の輻輳を予測し、必要に応じて、レート制御命令を生成する輻輳予測部１２１と、輻輳予測部１２１により生成されたレート制御命令を、ネットワーク３３を介して、データ送信装置１０１に送信する、レート制御命令送信部１２２が設けられている以外は、図２を用いて説明したデータ受信装置３２と同様の構成を有するものである。
【０１３０】
次に、データ送信装置１０１およびデータ受信装置１０２の動作について説明する。
【０１３１】
データ送信装置１０１のエンコーダ４１は、図示しないデータ入力部から、例えば、音声、画像、映像、テキストデータ、または、これらの混合したデータの入力を受け、エンコード制御部１１１の制御に基づいて、これらのデータをエンコードし、データ送信部４２に供給する。このとき生成されるデータ量は、送信レート制御部４５によって制御される。
【０１３２】
データ送信部４２は、エンコーダ４１から供給されたデータを時間単位でパケットに分割し、所定の時間ごとにＳＲパケットを付加して、ネットワーク３３を介して、データ受信装置１０２に送信する。
【０１３３】
データ受信装置１０２のデータ受信部５１は、ネットワーク３３を介して、データ送信装置１０１から、ＲＴＰパケットおよびＲＴＣＰ  ＳＲパケットを受信する。データ受信部５１は、データ処理部５２に、例えば、映像、音声、テキストなどのデータを供給するとともに、ＲＴＰパケットの受信時刻、タイムスタンプ、シーケンス番号、ＳＲパケットに含まれている時間情報などを、輻輳予測部１２１に供給する。
【０１３４】
また、データ受信部５１は、受信したパケットに、例えば、アクセスラインのビット誤りによるフレームの破棄や、ボトルネックリンクにおけるパケットの破棄などのパケットロスが発生した場合、パケットロスに関する情報を、輻輳予測部１２１に供給する。
【０１３５】
輻輳予測部１２１は、データ受信部５１から供給された情報を基に、データの遅延やパケットロス率を求め、必要に応じて、レート制御命令を生成する。
【０１３６】
図１３に、輻輳予測部１２１の機能ブロック図を示す。
【０１３７】
データ取得部１３１は、データ受信部５１から、ＳＲパケットに含まれている時間情報や、ＲＴＰパケットの受信時刻、タイムスタンプ、パケットサイズ、シーケンス番号などの、データの遅延やパケットロス率を求めるために必要な情報を取得し、データ演算部１３２に供給する。
【０１３８】
データ演算部１３２は、タイマ１３３から供給される時間情報を参照し、例えば、５秒間や１０秒間などの所定時間において、データ送信装置１０１からデータ受信装置１０２へのデータ伝送における片方向遅延、パケットロス数、受信パケット数、および受信データのバイト数の総和を演算し、統計情報を生成する。
【０１３９】
データ送信装置１０１およびデータ受信装置１０２の、ＮＴＰによる時刻が合致している場合、ＲＴＣＰのＳＲパケットに含まれるＲＴＰのタイムスタンプからＮＴＰへのマッピングを行うことにより、絶対遅延時間をＮＴＰの時間精度で求めることが可能である。しかしながら、実際には、ＮＴＰを使えない環境も多い。
【０１４０】
次に、ＮＴＰが使えない場合、すなわち、データ送信装置１０１およびデータ受信装置１０２の、ＮＴＰによる時刻が合致していない場合の遅延の測定方法について説明する。
【０１４１】
まず、パケットごとの絶対遅延は、次の式（２）で求めることができる。
【０１４２】
2004215201.tif 000003
【０１４３】
ここで、括弧［］内は、その時刻が、どの時計を参照しているかを示すものである（以下、同様）。
【０１４４】
データ送信装置１０１およびデータ受信装置１０２のＮＴＰによる時刻が同期しており、ＲＴＣＰのＳＲパケットにＮＴＰ情報が正しく入っている場合、次の式（３）が成立する。
【０１４５】
2004215201.tif 000004
【０１４６】
そして、ＳＲパケット内のタイムスタンプとＮＴＰのマッピング情報より、式（４）に示されるように、ＲＴＰパケットの送信時刻とタイムスタンプを関連付けるＮＴＰからＲＴＰタイムスタンプへの写像関数ｆ１を求め、式（３）のＲＴＰタイムスタンプと置き換えた式（５）により、ＲＴＰパケットの遅延を求めることが可能となる。
【０１４７】
ＲＴＰタイムスタンプ＝ｆ１［ＮＴＰ］・・・（４）
2004215201.tif 000005
【０１４８】
これに対して、例えば、ＳＲパケットのＮＴＰが明らかにずれていたり、ＳＲパケットを受信することができなかったなどの理由により、ＲＴＰのタイムスタンプからＮＴＰへのマッピングができず、式（４）が得られない場合、データ受信装置１０２内部の時計で遅延を計測する必要がある。この場合、実際には、あるＲＴＰパケットの到着時刻を基点として、相対的な遅延を測定することにより、ＲＴＰパケットの遅延が求められる。
【０１４９】
例えば、第１のＲＴＰパケットのタイムスタンプをＴＳ１、第１のＲＴＰパケットの受信時刻（単位は、ｍｓ）をＴＲ１とする。第１のＲＴＰパケットのタイムスタンプも、第１のＲＴＰパケットの受信時刻も、ＮＴＰとは異なる基準で計測される時刻である。ここで、第１のＲＴＰパケットのタイムスタンプと第１のＲＴＰパケットの受信時刻との時刻の単位をあわせるために、受信時刻にＲＴＰのリファレンスクロックを乗じることにする。ＲＴＰ  Ｐａｙｌｏａｄ  ｆｏｒｍａｔ  ｆｏｒ  ＭＰＥＧ４  Ｅｌｅｍｅｎｔａｒｙ  Ｓｔｒｅａｍ（ＲＦＣ３０１６）によるデータ通信においては、リファレンスクロックとして、９０ＫＨｚのクロックが用いられている。したがって、受信時刻の単位がｍｓであった場合、タイムスタンプのリファレンスクロックに変換するためには、次の式（６）を用いればよい。
【０１５０】
受信時刻［リファレンスクロック］＝ＴＲ１（ｍｓ）×９０・・・（６）
【０１５１】
ここで、第１のＲＴＰパケット乃至第ｎのＲＴＰパケットを、ＲＴＰ１乃至ＲＴＰｎとし、それぞれのタイムスタンプをＴＳ１乃至ＴＳｎとした場合、ネットワーク中の輻輳やパケットロスがなかったとすると、次の式（７）は、ほぼ定数となる。
【０１５２】
2004215201.tif 000006
【０１５３】
式（７）で示されるＴＳｎ−（ＴＲｎ×９０）が、データ受信装置１０２が内部に有する時計を用いて、ＲＴＰのリファレンスクロックで計測した場合の、データ送信装置１０１とデータ受信装置１０２との時間差である。ただし、ジッタ、および、送受信間のクロックずれは、式（７）においては無視されている。
【０１５４】
しかしながら、この時間差が、絶対時刻において、どの程度の時間差に相当するのかはわからない。つまり、式（７）の値が０だったとしても、パケットの遅延の大きさを求めることができない。したがって、データ演算部１３２は、ある時刻におけるパケットの遅延を含むデータ送信装置１０１とデータ受信装置１０２との時間差を、初期端末間時間差とし、これを基に、式（８）によって、相対的な遅延を測定する。
【０１５５】
2004215201.tif 000007
【０１５６】
ただし、ＴＲはＲＴＰパケットの受信時刻（単位はｍｓ）、ＴＳはＲＴＰのタイムスタンプである。
【０１５７】
ところで、上述したように、式（７）において、ジッタ、および、送受信間のクロックずれは無視され、式（７）から求められる送受信間タイムスタンプの差は一定であると仮定されているが、実際には、式（７）に示される端末間の時間差とパケットの遅延との和は、データ送信装置１０１とデータ受信装置１０２との基本クロックのずれにより、ゆっくりと単調減少するか、もしくは、単調増加するかのいずれか一方の傾向を示す。例えば、図１４に示されるように、受信時刻に対して、遅延がゆっくりと減少していく状況が発生する。
【０１５８】
このような場合、式（８）を用いて算出された初期時間差を、初期の値のまま使い続けると、得られる相対遅延も、単調減少、もしくは単調増加してしまう。そこで、式（８）を用いて算出される初期時間差は、定期的に更新する必要がある。
【０１５９】
また、データ演算部１３２は、更に、パケットロス数、受信パケット数、および受信データ量（受信バイト数）の供給を受けるので、タイマ１３３を参照し、例えば、５秒や１０秒などの所定の時間における、ＲＴＰパケットの相対遅延の総和、パケットロス数、受信パケット数、および受信データ量（受信バイト数）の総和を求める。
【０１６０】
次に、相対遅延増加率演算部１３４は、データ演算部１３２から供給された、所定時間内の受信パケット数およびＲＴＰパケットの相対遅延の総和を基に、次の式（９）を用いて、所定の期間（時刻ｔ１から時刻ｔ２の間）のＲＴＰパケットの平均相対遅延を演算する。
【０１６１】
【数１】
2004215201.tif 000008
【０１６２】
更に、相対遅延増加率演算部１３４は、式（９）を用いて算出した、ＲＴＰパケットの平均相対遅延と、１つ前の区間の平均相対遅延とを比較し、平均相対遅延増加率Ｄを算出する。
【０１６３】
そして、パケットロス率演算部１３５は、データ演算部１３２から供給された情報から、パケットロス率Ｌを求める。
【０１６４】
一般的に、ＲＴＰパケットのパケットロスは、アクセスラインのビット誤りによるフレームの破棄、または、ボトルネックリンクにおけるパケットの破棄により発生する。アクセスラインのビット誤りに関しては、誤り訂正や、リンクレイヤーでの再送（特に無線リンクの場合）などにより、ある程度防ぐことが可能ではあるが、実際の無線リンクにおいては、電波の状況により、ある程度のパケットロスが発生してしまう。また、ボトルネックリンクにおけるパケットの破棄が発生した場合、ボトルネックリンクのＱｕｅｕｅがあふれていることによりパケットロスが発生するので、例えば、ＦＩＦＯ（Ｆｉｒｓｔ  Ｉｎ  Ｆｉｒｓｔ  Ｏｕｔ）型のＱｕｅｕｅを用いている状況では、あふれた分だけパケットロスが発生することになる。
【０１６５】
つまり、アクセスラインのビット誤りによるパケットロスは、ある程度の確率で発生することが想定されるので、送信側のレートを下ることにより、パケットロス率が低くなるとは限らない。しかしながら、ボトルネックリンクにおけるパケットの破棄が発生した場合は、送信側のレートを下げない限り、パケットロスが発生しつづけることになる。
【０１６６】
ここで、パケットロス率演算部１３５は、上述した図６のパケットロス率演算部８２と同様にして、式（１）を用いて、パケットロス率Ｌを演算する。
【０１６７】
状態遷移制御部１３６は、相対遅延増加率演算部１３４およびパケットロス率演算部１３５から供給された、ＲＴＰパケットの平均相対遅延増加率Ｄ、および、パケットロス率Ｌを基に、受信レートの制御状態を遷移するか否かを判断する。
【０１６８】
状態遷移制御部１３６は、式（１０）を用いて、平均相対遅延増加率と所定の閾値Ｈ１とを定期的に比較し、平均相対遅延増加率が閾値Ｈ１より大きい場合、受信レートを下げるように制御状態を遷移する。
【０１６９】
平均相対遅延増加率Ｄ＞閾値Ｈ１  ・・・（１０）
【０１７０】
更に、状態遷移制御部１３６は、式（１１）を用いて、所定の短い時間（例えば、数１００ｍｓｅｃ乃至１ｓｅｃの、平均相対遅延増加率を求める場合よりも充分短い時間）内のパケットロス率と、所定の閾値Ｈ２とを定期的に比較し、パケットロス率が閾値Ｈ２より大きい場合、受信レートを下げるように制御状態を遷移する。
【０１７１】
パケットロス率Ｌ＞閾値Ｈ２・・・（１１）
【０１７２】
データ送信装置１０１とデータ受信装置１０２とのデータ伝送経路の伝送帯域がある程度の大きさを有するときは、ネットワーク中のＱｕｅｕｅの長さが相対的に短くなるため、データ伝送経路の状態が不安定になることにより、パケットロス率が増加しやすくなるので、式（１０）と式（１１）とにおいて、式（１１）が成立しやすい。それに対して、データ送信装置１０１とデータ受信装置１０２とのデータ伝送経路の伝送帯域がある比較的小さいとき、ネットワーク中のＱｕｅｕｅの長さが相対的に長くなるため、データ伝送経路の状態が不安定になることにより、平均相対遅延増加率Ｄが増加しやすくなるので、式（１０）と式（１１）とにおいて、式（１０）が成立しやすい。
【０１７３】
このように、式（１０）と式（１１）との２つの評価式により、受信レートを下げる必要があるか否かを判断するようにすることにより、データ伝送帯域が大きな場合においても、小さな場合においても、データ伝送路の状態に最適なデータ受信レートの制御が可能となる。
【０１７４】
また、状態遷移制御部１３６は、式（１０）および式（１１）による比較結果を基に、データ伝送状態が安定している場合、受信レートを一定に保ったり、受信レートを上げるように状態を遷移する場合がある。
【０１７５】
状態遷移制御部１３６による状態遷移図を図１５に示す。
【０１７６】
状態には、データ受信レートを上げるように制御するＵＰ状態、データ受信レートを下げるように制御するＤｏｗｎ状態、および、データ受信レートを変更しないように制御するＨｏｌｄの３状態がある。
【０１７７】
制御のはじめにおいて、状態はＨｏｌｄ状態である。状態遷移制御部１３６は、Ｈｏｌｄ状態を一定時間Ｔだけ保っている間の、式（１０）および式（１１）による比較結果を基に、平均相対遅延増加率Ｄ≦閾値Ｈ１かつパケットロス率Ｌ≦閾値Ｈ２である場合、状態をＵＰ状態に遷移し、平均相対遅延増加率Ｄ＞閾値Ｈ１、または、パケットロス率Ｌ＞閾値Ｈ２である場合、状態をＤｏｗｎ状態に遷移する。
【０１７８】
ＵＰ状態において、状態遷移制御部１３６は、式（１０）および式（１１）による比較結果を基に、平均相対遅延増加率Ｄ≦閾値Ｈ１かつパケットロス率Ｌ≦閾値Ｈ２である場合、状態をＵＰ状態のまま保持し、平均相対遅延増加率Ｄ＞閾値Ｈ１、または、パケットロス率Ｌ＞閾値Ｈ２である場合、状態をＤｏｗｎ状態に遷移する。
【０１７９】
また、Ｄｏｗｎ状態において、状態遷移制御部１３６は、式（１０）および式（１１）による比較結果を基に、平均相対遅延増加率Ｄ≦閾値Ｈ１かつパケットロス率Ｌ≦閾値Ｈ２である場合、状態をＨｏｌｄ状態に遷移し、平均相対遅延増加率Ｄ＞閾値Ｈ１、または、パケットロス率Ｌ＞閾値Ｈ２である場合、状態をＤｏｗｎ状態のまま保持する。
【０１８０】
状態遷移制御部１３６は、現在の状態を示す状態遷信号を、受信レート設定部１３７に出力する。
【０１８１】
受信レート設定部１３７は、状態遷移制御部から供給された状態遷移信号に基づいて、受信レートを設定し、レート制御命令を生成する。
【０１８２】
状態がＤｏｗｎ状態である場合、受信レート設定部１３７は、次の式（１２）により、再設定レートＲを算出する。
【０１８３】
再設定レートＲ＝受信レート×Ｃ１・・・（１２）
【０１８４】
ここで、式（１２）のＣ１は、予め定められている１以下の定数か、もしくは、別途、平均相対遅延増加率の逆数を演算することなどにより求められた１以下の値である。
【０１８５】
そして、状態がＵＰ状態である場合、受信レート設定部１３７は、次の式（１３）により、再設定レートＲを算出する。
【０１８６】
再設定レートＲ＝受信レート×Ｃ２・・・（１３）
【０１８７】
ただし、Ｃ２は、予め定められている１以上の定数か、パケットロス率Ｌの逆数を求めることなどより算出される１以上の値である。
【０１８８】
なお、受信レートの上限に関しては、予め、ＨＴＴＰやパケットペアなどを用いてボトルネックリンクのリンクスピード（パケットロスや、遅延の増加が発生しないネットワーク状況におけるデータ伝送スピード）を測定しておき、これを上限としてもよいし、上限を設けないようにしてもよい。
【０１８９】
このようにして、図１５の状態遷移図に示される状態に基づいて、データ受信レートが制御されることにより、データ受信レートは、そのときのデータ伝送路の条件により、最適に制御される。図１６は、図１５の状態遷移図に示される状態とデータ受信レートの関係を示す図である。
【０１９０】
データ伝送路の状態は、その時刻によって変動する場合がある。本発明を適応したデータ受信装置１０２によるデータ受信レート制御によると、データ受信レートは一定の値に収束するように制御されるのではなく、データ伝送路の状況が良好で、遅延やパケットロスが発生しない状態においては、状態がＵＰ状態となり、データ転送レートは増加するように制御される。
【０１９１】
このようにして、輻輳予測部１２１は、必要に応じて、レート制御命令を生成する。輻輳予測部１２１は、生成したレート制御命令を、レート制御命令送信部１２２に出力する。
【０１９２】
レート制御命令送信部１２２は、レート制御命令を、ＲＴＣＰのＡＰＰパケットとして、データ送信装置１０１に送信する。
【０１９３】
データ送信装置１０１のデータ受信部４３は、レート制御命令を受信し、エンコード制御部１１１および送信レート制御部４５に供給する。
【０１９４】
エンコード制御部１１１は、データ受信部４３からレート制御命令の供給を受け、そのレート制御命令が、レートを下げることを命令している場合、パケットロスなどにより、データ受信側においてエラーが発生する可能性があるため、エンコーダ４１のエンコードを制御して、Ｉフレームを生成させる。
【０１９５】
送信レート制御部４５は、データ受信部４３から供給されたレート制御命令を基に、送信レート制御信号を生成し、データ生成部４１に供給する。
【０１９６】
データ生成部４１は、送信レート制御部４５の制御に基づいて、データの生成量を必要に応じて変更する。したがって、データ送信部４２により送信されるデータのデータレートが制御される。また、データ生成部４１は、エンコード制御部１１１の制御に基づいて、必要に応じて、通常のエンコード順にかかわらず、Ｉフレームを生成する。このようにして、データ生成部４１で生成されたデータは、データ送信部４２に供給され、パケットに分割されて、送信される。
【０１９７】
このようにして、データ送信装置１０１は、ネットワークの状態に応じた、最適な送信レートで、パケットデータを送信し、かつ、必要に応じて、送信するデータにＩフレームを挿入することができる。ここでは、データ受信装置１０２は、レート制御命令を、ＲＴＣＰのＡＰＰパケットとして、データ送信装置１０１に送信するものとして説明したが、レート制御命令を、ＲＴＣＰのＲＲパケットを用いて、データ送信装置１０１に送信することができるようにしても良いことは言うまでもない。
【０１９８】
次に、図１７のフローチャートを参照して、データ受信装置１０２で実行される統計情報生成処理について説明する。
【０１９９】
ステップＳ１１１において、データ受信部５１は、ネットワーク３３を介して、データ送信装置１０１から送信されたパケットが受信されたか否かを判断する。ステップＳ１１１において、パケットが受信されていないと判断された場合、パケットが受信されたと判断されるまで、ステップＳ１１１の処理が繰り返される。
【０２００】
ステップＳ１１１において、パケットが受信されたと判断された場合、データ受信部５１は、受信したＲＴＰパケットの受信時刻、タイムスタンプ、パケットサイズ、シーケンス番号、および、受信したＲＴＣＰのＳＲパケットのＮＴＰ情報など、データの遅延やパケットロス率を求めるために必要な情報を輻輳予測部１２１に供給し、ステップＳ１１２において、輻輳予測部１２１のデータ演算部１３２は、受信したＲＴＰパケットの受信時刻を内部のメモリに記録する。
【０２０１】
輻輳予測部１２１のデータ演算部１３２は、ステップＳ１１３において、上述したように、データ送信装置１０１からデータ受信装置１０２へのデータ伝送における片方向遅延時間、パケットロス数、受信パケット数、および、受信バイト数を計算し、ステップＳ１１４において、片方向遅延時間、パケットロス数、受信パケット数、および、受信バイト数のそれぞれの総和を更新する。ステップＳ１１４の処理の終了後、処理は、ステップＳ１１１に戻り、それ以降の処理が繰り返される。
【０２０２】
このような処理により、輻輳予測部１２１のデータ演算部１３２において、統計情報が生成される。
【０２０３】
次に、図１８のフローチャートを参照して、図１７を用いて説明した統計情報生成処理において生成された統計情報を基に実行されるレート制御処理について説明する。
【０２０４】
ステップＳ１３１において、状態遷移制御部１３６は、制御の状態を、Ｈｏｌｄ状態にセットする。
【０２０５】
ステップＳ１３２において、パケットロス率演算部１３５は、データ演算部１３２から、統計情報のうち、パケットロス数および受信パケット数を取得し、式（１）を用いて、パケットロス率Ｌを算出する。
【０２０６】
ステップＳ１３３において、相対遅延増加率演算部１３４は、データ演算部１３２から、統計情報のうち、ＲＴＰパケットの相対遅延の所定時間内の総和を取得し、式（９）を用いてＲＴＰパケットの平均相対遅延を算出し、ＲＴＰパケットの平均相対遅延と、１つ前の区間の平均相対遅延とを比較して、平均相対遅延増加率Ｄを算出する。
【０２０７】
ステップＳ１３４において、状態遷移制御部１３６は、同一状態で一定時間が経過したか否かを判断する。ステップＳ１３４において、同一状態で一定時間が経過していないと判断された場合、処理は、ステップＳ１３２に戻り、それ以降の処理が繰り返される。
【０２０８】
ステップＳ１３４において、同一状態で一定時間が経過したと判断された場合、ステップＳ１３５において、状態遷移制御部１３６は、ステップＳ１３２において算出されたパケットロス率ＬおよびステップＳ１３３において算出された平均相対遅延増加率Ｄを基に、図１５を用いて説明したように、必要に応じて、制御状態を遷移し、受信レート設定部１３７に、状態遷移信号を供給する。
【０２０９】
ステップＳ１３６において、受信レート設定部１３７は、状態遷移制御部１３６から供給される状態遷移信号に基づいて、受信ビットレートを変更するか否かを判断する。状態遷移信号がＨｏｌｄ状態を示し、ステップＳ１３６において、受信ビットレートを変更しないと判断された場合、処理は、ステップＳ１３２に戻り、それ以降の処理が繰り返される。
【０２１０】
状態遷移信号がＵＰ状態、または、Ｄｏｗｎ状態を示し、ステップＳ１３６において、受信ビットレートを変更すると判断された場合、ステップＳ１３７において、受信レート設定部１３７は、上述した式（１２）または式（１３）を用いて、ビットレートを演算し、レート制御命令を生成して、レート制御命令送信部１２２に供給する。レート制御命令送信部１２２は、ネットワーク３３を介して、レート制御命令をデータ送信装置１０１に送信する。
【０２１１】
ステップＳ１３７の処理の終了後、処理は、ステップＳ１３２に戻り、それ以降の処理が繰り返される。
【０２１２】
このような処理により、データ受信装置１０２において、データ伝送路（ネットワーク３３）の状態に応じたレート制御命令が生成されて、データ送信装置１０１に送信される。
【０２１３】
次に、図１９のフローチャートを参照して、レート制御命令を受信したデータ送信装置１０１が実行するＩフレーム挿入処理２について説明する。
【０２１４】
ステップＳ１５１において、データ送信装置１０１のデータ受信部４３は、ネットワーク３３を介して、データ受信装置１０２から、ＲＲパケット、または、ＡＰＰパケットを受信したか否かを判断する。ステップＳ１５１において、ＲＲパケット、または、ＡＰＰパケットを受信していないと判断された場合、ＲＲパケット、または、ＡＰＰパケットを受信したと判断されるまで、ステップＳ１５１の処理が繰り返される。
【０２１５】
ステップＳ１５１において、ＲＲパケット、または、ＡＰＰパケットを受信したと判断された場合、ステップＳ１５２において、データ受信部４３は、受信したＲＲパケット、または、ＡＰＰパケットに、レート制御命令が含まれているか否かを判断する。ステップＳ１５２において、受信したＲＲパケット、または、ＡＰＰパケットに、レート制御命令が含まれていないと判断された場合、処理は、ステップＳ１５１に戻り、それ以降の処理が繰り返される。
【０２１６】
ステップＳ１５２において、受信したＲＲパケット、または、ＡＰＰパケットに、レート制御命令が含まれていると判断された場合、データ受信部４３は、レート制御命令を、送信レート制御部４５およびエンコード制御部１１１に供給するので、ステップＳ１５３において、送信レート制御部４５は、レート制御命令に基づいて、エンコーダ４１を制御して、生成されるデータ量を減少または増加させることにより、データ送信部４２から送信されるデータの送信ビットレートを変更する。
【０２１７】
エンコード制御部１１１は、ステップＳ１５４において、エンコーダ４１から、通常のエンコード順による次のＩフレームの送信時刻を取得し、ステップＳ１５５において、レート制御命令がレートを下げることを指令しているか否か、および、通常のエンコード順によるＩフレームの送信時刻までの時間が、例えば、１秒などの、所定の時間より長いか否かを基に、Ｉフレーム挿入処理を実行するか否かを判断する。
【０２１８】
エンコード制御部１１１は、通常のエンコード順によるＩフレームの送信時刻までの時間が、例えば、１秒などの、所定の時間より長く、かつ、レート制御命令がレートを下げることを指令している場合、Ｉフレーム挿入処理を実行すると判断する。ステップＳ１５５において、Ｉフレーム挿入処理を実行しないと判断された場合、処理は、ステップＳ１５１に戻り、それ以降の処理が繰り返される。
【０２１９】
ステップＳ１５５において、Ｉフレーム挿入処理を実行すると判断された場合、ステップＳ１５６において、エンコード制御部１１１は、エンコーダ４１を制御して、通常のエンコード順にかかわらず、Ｉフレームを生成させ、データ送信部４２に供給させて、送信するＲＴＰパケットに、Ｉフレームを挿入させる。ステップＳ１５６の処理の終了後、処理は、ステップＳ１５１に戻り、それ以降の処理が繰り返される。
【０２２０】
このような処理により、レート制御命令を受信したデータ送信装置１０１は、送信されるデータのレートを制御するとともに、通常のエンコード順において、次のＩフレームの送信までの時間が、所定の時間より長く、かつ、レート制御命令がレートを下げることを指令している場合、Ｉフレームを生成して、データ受信装置１０２に送信するようにしたので、データ受信装置１０２において、パケットロスなどによるデータエラーの伝播が長時間続くような状況の発生を防止することが可能となる。
【０２２１】
また、データ受信装置１０２によるレート制御命令の生成方法は、以上において説明した方法以外の方法であっても良いことは言うまでもない。データ送信装置１０１は、データ受信装置１０２が送信したレート制御命令の種類によらず、これを受信して、必要に応じて、送信するデータのレートを制御するとともに、Ｉフレームを生成して、送信することができる。
【０２２２】
第１の実施の形態では、データ受信装置３２において、リフレッシュ命令が生成されて、リフレッシュ命令を受信したデータ送信装置が、通常のエンコード順にかかわらず、必要に応じてＩフレームを生成して、データ受信装置３２に送信した。また、第２の実施の形態では、データ受信装置１０２において、レート制御命令が生成されて、レート制御命令を受信したデータ送信装置が、データ伝送レートを制御するのに加えて、通常のエンコード順にかかわらず、必要に応じてＩフレームを生成して、データ受信装置１０２に送信した。
【０２２３】
これに対して、データ受信側の装置でデータ送信側の装置に対する命令を生成するのではなく、データ受信側の装置が生成して送信するＲＲパケットを基に、データ送信側の装置が、Ｉフレームの挿入の必要があるか否かを判断して、必要に応じて、通常のエンコード順にかかわらず、Ｉフレームを生成して、送信するようにしても良い。
【０２２４】
図２０は、第３の実施の形態におけるデータ送信装置１６１およびデータ受信装置１６２の構成を示すブロック図である。
【０２２５】
なお、図２における場合と対応する部分には同一の符号を付してあり、その説明は適宜省略する。
【０２２６】
すなわち、図２０のデータ送信装置１６１は、エンコード制御部４４に代わって、ＲＲパケットに含まれている情報を基に、通常のエンコードの順番にかかわらず、Ｉフレームを生成して送信するか否かを判断し、必要に応じて、Ｉフレーム生成のための制御信号をエンコーダ４１に出力するエンコード制御部１７１が備えられている以外は、図２のデータ送信装置３１と同様の構成を有するものであり、図２０のデータ受信装置１６２は、リフレッシュ命令生成部５３およびリフレッシュ命令送信部５５が省略されている以外は、図２のデータ受信装置３２と同様の構成を有するものである。
【０２２７】
次に、データ送信装置１６１およびデータ受信装置１６２の動作について説明する。
【０２２８】
データ送信装置１６１のエンコーダ４１は、図示しないデータ入力部から、例えば、音声、画像、映像、テキストデータ、または、これらの混合したデータの入力を受けて、例えば、ＭＰＥＧ２やＭＰＥＧ４などの方法でエンコードし、データ送信部４２に供給する。エンコーダ４１は、送信レート制御部４５の制御に基づいて、生成するデータの量を決定する。生成されるデータの量を制御することにより、送信レートが制御される。
【０２２９】
データ送信部４２は、エンコーダ４１から供給されたデータを時間単位でパケットに分割し、所定の時間ごとにＳＲパケットを付加して、ネットワーク３３を介して、データ受信装置１６２に送信する。
【０２３０】
データ受信装置１６２のデータ受信部５１は、ネットワーク３３を介して、データ送信装置３１から、ＲＴＰパケットおよびＲＴＣＰ  ＳＲパケットを受信する。データ受信部５１は、データ処理部５２に、例えば、映像、音声、テキストなどのデータを供給する。
【０２３１】
データ送信部５４は、ＲＴＣＰ  ＲＲパケットを、ネットワーク３３を介して、データ送信装置１６１に送信する。
【０２３２】
データ送信装置１６１のデータ受信部４３は、ＲＲパケットを受信し、受信したＲＲパケットに含まれる、タイムスタンプの情報や、パケットロス、ジッタなどの情報を、エンコード制御部１７１に供給する。
【０２３３】
エンコード制御部１７１は、データ受信部４３から供給された情報を基に、パケットロス率やジッタなどの値と、所定の閾値とを比較し、その比較結果に基づいて、通常のフレーム順にかかわらず、次にエンコードして生成されるフレームをＩフレームとするか否かを判断し、必要に応じて、次にエンコードして生成されるフレームがＩフレームとなるようにエンコードを制御するための制御信号を生成し、エンコーダ４１に供給する。また、エンコード制御部１７１は、パケットロス率やジッタなどの値と、所定の閾値との比較結果を、送信レート制御部４５に供給する。
【０２３４】
送信レート制御部４５は、エンコード制御部１７１から供給された情報を基に、送信レートを変更する必要があるか否かを判断し、送信レートの変更が必要である場合、データ生成量を制御するための制御信号を生成し、エンコーダ４１に供給する。
【０２３５】
エンコーダ４１は、エンコード制御部４４から供給された制御信号に基づいて、必要に応じて、Ｉフレームを挿入するようにしながら、供給されるデータのエンコードを行い、それ以外の場合は、予め定められたエンコード方式に基づいて、エンコードを行い、エンコードされた符号化データを、データ送信部４２に供給する。
【０２３６】
データ送信部４２は、供給された符号化データを、時間ごとに分割してＲＴＰパケットを生成し、ＲＴＰパケットを、ネットワーク３３を介して、データ受信装置１６２に送信する。また、データ送信部４２は、例えば、５秒などの所定の時間ごとに、上述したＳＲパケットを生成し、ネットワーク３３を介して、データ受信装置１６２に送信する。
【０２３７】
このようにして、データ送信装置１６１は、データ受信装置１６２において、パケットロスによるエラーが発生しにくい、または、発生しても、エラー伝播時間が短くなるように、通常のエンコード処理により生成されるフレームの順序にかかわらず、Ｉフレームを適宜生成して、データ受信装置３２に送信することができる。
【０２３８】
次に、図２１のフローチャートを参照して、ＲＲパケットに含まれる情報を基に、データ送信装置１６１が実行する、Ｉフレーム挿入処理３について説明する。
【０２３９】
ステップＳ１８１において、データ送信装置１６１のデータ受信部４３は、データ受信装置１６２から送信されるＲＲパケットを受信したか否かを判断する。ステップＳ１８１において、ＲＲパケットを受信していないと判断された場合、受信したと判断されるまで、ステップＳ１８１の処理が繰り返される。
【０２４０】
ステップＳ１８１において、ＲＲパケットを受信したと判断された場合、データ受信部４３は、ＲＲパケットに記載されている情報を、エンコード制御部１７１に供給するので、ステップＳ１８２において、エンコード制御部１７１は、供給されたデータを基に、例えば、上述した式（１）を用いて、パケットロス率を演算し、パケットロス率が、所定の閾値以上であるか否かを判断する。ステップＳ１８２において、パケットロス率が、所定の閾値以上であると判断された場合、処理は、ステップＳ１８４に進む。
【０２４１】
ステップＳ１８２において、パケットロス率が、所定の閾値以下であると判断された場合、ステップＳ１８３において、エンコード制御部１７１は、ジッタが、所定の閾値以上であるか否かを判断する。ステップＳ１８３において、ジッタが所定の閾値以下であると判断された場合、処理は、ステップＳ１８１に戻り、それ以降の処理が繰り返される。
【０２４２】
ステップＳ１８２において、パケットロス率が所定の閾値以上であると判断された場合、または、ステップＳ１８３において、ジッタが所定の閾値以上であると判断された場合、ステップＳ１８４において、エンコード制御部１７１は、送信レート制御部４５に、パケットロス率が所定の閾値以上である、または、ジッタが所定の閾値以上であることを通知する。送信レート制御部４５は、エンコーダ４１による処理を制御して、生成されるデータ量を減少させることにより、データ送信部４２から送信されるデータの送信ビットレートを下げる。
【０２４３】
なお、ここでは、エンコード制御部１７１が、送信レート制御部４５に、パケットロス率が所定の閾値以上である、または、ジッタが所定の閾値以上であることを通知するものとして説明したが、送信レート制御部４５が、ステップＳ１８２およびステップＳ１８３と同様の処理を実行するようにして、その結果、必要に応じて、送信レートを下げることができるようにしても良いことはもちろんである。
【０２４４】
ステップＳ１８５において、エンコード制御部１７１は、データ送信部４２から送信される次のＩフレームの送信時刻を取得する。
【０２４５】
ステップＳ１８６において、エンコード制御部１７１は、パケットロス率、ジッタ、および、次のＩフレームの送信時刻までの時間を基に、Ｉフレーム挿入処理を実行するか否かを判断する。エンコード制御部１７１は、パケットロス率またはジッタのうちのいずれか一方が所定の閾値以上であり、かつ、次のＩフレームの送信時刻までの時間が、例えば、１秒などの、所定の時間よりも長かった場合に、Ｉフレーム挿入処理を実行する。ステップＳ１８６において、Ｉフレーム挿入処理を実行しないと判断された場合、処理は、ステップＳ１８１に戻り、それ以降の処理が繰り返される。
【０２４６】
また、エンコード制御部１７１は、例えば、パケットロス率およびジッタが、いずれも所定の閾値以上であり、かつ、次のＩフレームの送信時刻までの時間が、例えば、１秒などの、所定の時間よりも長かった場合に、Ｉフレーム挿入処理を実行するものとしても良い。
【０２４７】
ステップＳ１８６において、Ｉフレーム挿入処理を実行すると判断された場合、ステップＳ１８７において、エンコード制御部１７１は、エンコーダ４１を制御して、フレーム内符号化を実行させて、データ送信部４２から送信させるデータにＩフレームを挿入して、処理は、ステップＳ１８１に戻り、それ以降の処理が繰り返される。
【０２４８】
このような処理により、データ送信装置１６１は、データ受信装置１６２において、パケットロスによるエラーが発生しにくい、または、発生しても、エラー伝播時間が短くなるように、通常のエンコード処理により生成されるフレームの順序にかかわらず、Ｉフレームを適宜生成して、データ受信装置１６２に送信することができる。
【０２４９】
また、ここでは、データ受信装置１６２がデータ送信装置１６１に送信するＲＴＣＰ  ＲＲパケットに記載されている情報を基に、データ送信装置１６１において、送信されるデータにＩフレームを挿入するか否かが判断されるものとして説明したが、データ受信装置１６２が、データ送信装置１６１に対して、ＲＴＣＰ  ＲＲパケット以外のデータ（例えば、ＲＴＣＰ  ＡＰＰパケットなど）にＩフレームを挿入するか否かを判断するために必要な情報を記載して送信するようにしてもよい。
【０２５０】
以上においては、パケットデータを送信するデータ送信装置３１、データ送信装置１０１、または、データ送信装置１６１と、パケットデータを受信するデータ受信装置３２、データ受信装置１０２、または、データ受信装置１６２における場合について説明したが、パケットデータの送受信が可能なデータ送受信装置間で、パケットデータを送受信する場合においても、本発明は適用可能である。
【０２５１】
上述した一連の処理は、ソフトウェアにより実行することもできる。そのソフトウェアは、そのソフトウェアを構成するプログラムが、専用のハードウェアに組み込まれているコンピュータ、または、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどに、記録媒体からインストールされる。
【０２５２】
この記録媒体は、図２２に示すように、コンピュータとは別に、ユーザにプログラムを提供するために配布される、プログラムが記録されている磁気ディスク２２１（フレキシブルディスクを含む）、光ディスク２２２（ＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ  Ｄｉｓｋ−Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ），ＤＶＤ（Ｄｉｇｉｔａｌ  Ｖｅｒｓａｔｉｌｅ  Ｄｉｓｋ）を含む）、光磁気ディスク２２３（ＭＤ（Ｍｉｎｉ−Ｄｉｓｋ）（商標）を含む）、もしくは半導体メモリ２２４などよりなるパッケージメディアなどにより構成される。
【０２５３】
図２２は、上記処理を実行するパーソナルコンピュータ２０１の構成例を表している。パーソナルコンピュータ２０１のＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）２１１は、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）２１２に記憶されているプログラム、またはＨＤＤ（Ｈａｒｄ  Ｄｉｓｃ  Ｄｒｉｖｅ）２１８から、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）２１３にロードされたプログラムにしたがって各種の処理を実行する。ＲＡＭ２１３にはまた、ＣＰＵ２１１が各種の処理を実行する上において必要なデータなども適宜記憶される。
【０２５４】
ＣＰＵ２１１、ＲＯＭ２１２、およびＲＡＭ２１３は、内部バス２１４を介して相互に接続されている。この内部バス２１４にはまた、入出力インタフェース２１５も接続されている。
【０２５５】
入出力インタフェース２１５には、キーボード、マウスなどよりなる入力部２１６、ＣＲＴ（Ｃａｔｈｏｄｅ  Ｒａｙ  Ｔｕｂｅ）、およびＬＣＤ（Ｌｉｑｕｉｄ  Ｃｒｙｓｔａｌ  Ｄｉｓｐｌａｙ）などよりなるディスプレイ、並びにスピーカなどよりなる出力部２１７、ハードディスクにより構成されるＨＤＤ２１８、モデム、ターミナルアダプタなどより構成されるネットワークインターフェース２２０が接続されている。ネットワークインターフェース２２０は、例えば、インターネットなどのネットワークを介しての通信処理を行う。
【０２５６】
入出力インタフェース２１５にはまた、必要に応じてドライブ２１９が接続され、磁気ディスク２２１、光ディスク２２２、光磁気ディスク２２３、または、半導体メモリ２２４などが適宜装着され、それらから読み出されたコンピュータプログラムが、必要に応じてＨＤＤ２１８にインストールされる。
【０２５７】
また、本明細書において、記録媒体に記録されるプログラムを記述するステップは、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的または個別に実行される処理をも含むものである。
【０２５８】
なお、本明細書において、システムとは、複数の装置により構成される装置全体を表すものである。
【０２５９】
【発明の効果】
このように、本発明によれば、符号化フレームを送信することができる。特に、データ通信状況に対応して、フレーム内符号化により生成されたイントラフレームを送信することができる。
【０２６０】
また、他の本発明によれば、データを受信することができる他、データ通信状況を基に、フレーム内符号化により生成されるイントラフレームの送信を指令する情報を生成し、データ送信元に送信することができる。
【図面の簡単な説明】
【図１】Ｉフレーム間隔について説明するための図である。
【図２】本発明を適用した第１のデータ通信システムのデータ送信装置およびデータ受信装置の構成を示すブロック図である。
【図３】ＳＲパケットについて説明する図である。
【図４】ＲＲパケットについて説明する図である。
【図５】ＡＰＰパケットについて説明する図である。
【図６】図２のリフレッシュ命令生成部の構成を示すブロック図である。
【図７】リフレッシュ命令発行処理１について説明するフローチャートである。
【図８】リフレッシュ命令発行処理１について説明するフローチャートである。
【図９】リフレッシュ命令発行処理２について説明するフローチャートである。
【図１０】リフレッシュ命令発行処理２について説明するフローチャートである。
【図１１】Ｉフレーム挿入処理１について説明するフローチャートである。
【図１２】本発明を適用した第２のデータ通信システムのデータ送信装置およびデータ受信装置の構成を示すブロック図である。
【図１３】図１２の輻輳予測部の構成を示すブロック図である。
【図１４】受信時刻による、遅延の単純減少について説明する図である。
【図１５】状態遷移について説明する図である。
【図１６】状態遷移とデータ送信レートについて説明する図である。
【図１７】統計情報生成処理について説明するフローチャートである。
【図１８】レート制御処理について説明するフローチャートである。
【図１９】Ｉフレーム挿入処理２について説明するフローチャートである。
【図２０】本発明を適用した第３のデータ通信システムのデータ送信装置およびデータ受信装置の構成を示すブロック図である。
【図２１】Ｉフレーム挿入処理３について説明するフローチャートである。
【図２２】パーソナルコンピュータの構成を示すブロック図である。
【符号の説明】
３１  データ送信装置，  ３２  データ受信装置，  ３３  ネットワーク，  ４１  エンコーダ，  ４２  データ送信部，  ４３  データ受信部，  ４４  エンコード制御部，  ４５  送信レート制御部，  ５１  データ受信部，  ５２  データ処理部，  ５３  リフレッシュ命令生成部，  ５４  データ送信部，  ５５  リフレッシュ命令送信部，  ８１  データ取得部，  ８２  パケットロス率演算部，  ８４  片方向遅延演算部，  ８６  Ｉフレーム間隔測定部，  ８９  リフレッシュ命令発行部，  ８９  Ｉフレーム受信時刻予測部，  １０１  データ送信装置，  １０２  データ受信装置，  １１１  エンコード制御部，  １２１  輻輳予測部，  １２２  レート制御命令送信部，  １３２  データ演算部，１３４  相対遅延増加率演算部，  １３５  パケットロス率演算部，  １３６状態遷移制御部，  １３７  受信レート設定部，  １６１  データ送信装置，１６２  データ受信装置，  １７１  エンコード制御部
【図１】
2004215201.tif 000009
【図２】
2004215201.tif 000010
【図３】
2004215201.tif 000011
【図４】
2004215201.tif 000012
【図５】
2004215201.tif 000013
【図６】
2004215201.tif 000014
【図７】
2004215201.tif 000015
【図８】
2004215201.tif 000016
【図９】
2004215201.tif 000017
【図１０】
2004215201.tif 000018
【図１１】
2004215201.tif 000019
【図１２】
2004215201.tif 000020
【図１３】
2004215201.tif 000021
【図１４】
2004215201.tif 000022
【図１５】
2004215201.tif 000023
【図１６】
2004215201.tif 000024
【図１７】
2004215201.tif 000025
【図１８】
2004215201.tif 000026
【図１９】
2004215201.tif 000027
【図２０】
2004215201.tif 000028
【図２１】
2004215201.tif 000029
【図２２】
2004215201.tif 000030