(57)【要約】【課題】従来のストリーム通信装置においては、将来発生するパケット損失が生じるパケットを正確に推定することができないという課題がある。【解決手段】パケット交換ネットワーク上でルータを介してストリームの送信又は受信を行うストリーム通信装置１６０４であって、前記ストリームを小さく分割したパケットが送信されてから受信されるまでの時間である片方向伝送遅延を蓄積する蓄積部２０４と、前記蓄積部２０４に蓄積された片方向伝送遅延の増加傾向を判断することで、パケット損失につながる兆候を検出する検出部２０２と、前記兆候を検出した場合、前記蓄積部に蓄積された前記片方向伝送遅延の遅延量の増加の程度から、前記パケット損失が生じるパケットである損失推定パケットを推定する推定部２０３とを備える。【選択図】図３
2010016722.tif 000002
【特許請求の範囲】
【請求項１】
パケット交換ネットワーク上でルータを介してストリームの送信又は受信を行うストリーム通信装置であって、
前記ストリームを構成するパケットが送信されてから受信されるまでの時間である片方向伝送遅延を蓄積する蓄積手段と、
前記蓄積手段に蓄積された片方向伝送遅延の増加傾向を判断することで、パケット損失につながる兆候を検出する検出手段と、
前記兆候が検出された場合、前記蓄積手段に蓄積された前記片方向伝送遅延の増加の程度から、前記パケット損失が生じるパケットである損失推定パケットを推定する推定手段とを備える
ストリーム通信装置。
【請求項２】
前記ストリーム通信装置は、さらに、
前記パケットを受信するパケット受信手段と、
前記パケットの受信時刻と、パケットに含まれる送信時刻との差である前記片方向伝送遅延を算出するＯＷＤ算出手段とを備え、
前記蓄積手段は、前記ＯＷＤ算出手段により算出された前記片方向伝送遅延を蓄積する
請求項１記載のストリーム通信装置。
【請求項３】
前記蓄積手段は、さらに、前記送信時刻及び前記受信時刻のうち少なくとも一方を蓄積し、
前記兆候を検出した場合、前記蓄積手段によって蓄積された前記片方向伝送遅延の増加の程度と、前記送信時刻及び前記受信時刻のうち少なくとも一方とから、前記パケット損失が生じる時刻である損失推定時刻を推定することで、前記損失推定時刻に送信されるパケットを前記損失推定パケットとして推定する
請求項２記載のストリーム通信装置。
【請求項４】
前記蓄積手段は、さらに、前記パケットに対応するシーケンス番号を蓄積し、
前記推定手段は、前記蓄積手段によって蓄積された前記片方向伝送遅延の増加の程度と、前記シーケンス番号と、前記送信時刻及び前記受信時刻のうち少なくとも一方とから、前記パケット損失が発生するパケットに対応するシーケンス番号である損失推定シーケンス番号を推定することで、前記損失推定シーケンス番号に対応するパケットを前記損失推定パケットとして推定する
請求項２記載のストリーム通信装置。
【請求項５】
前記ストリーム通信装置は、さらに、
前記パケット損失が生じた場合に、パケット損失が生じたパケットに含まれるストリームの一部を回復するように、前記損失推定パケットを制御する制御手段を備える
請求項１記載のストリーム通信装置。
【請求項６】
前記蓄積手段は、さらに、前記パケットの受信時刻と、当該パケットが送信された時刻である送信時刻とのうち少なくとも一方を蓄積し、
前記推定手段は、前記兆候を検出した場合、前記蓄積手段によって蓄積された前記片方向伝送遅延の増加の程度と、前記送信時刻及び前記受信時刻のうち少なくとも一方とから、前記パケット損失が生じる時刻である損失推定時刻を推定することで、前記損失推定時刻に送信されるパケットを前記損失推定パケットとして推定する
請求項５記載のストリーム通信装置。
【請求項７】
前記制御手段は、前記損失推定時刻、又は、当該損失推定時刻を含む所定の期間に送信するパケットに含まれる冗長データの割合を、前記損失推定時刻を除く時刻、又は、前記損失推定時刻を含む所定の期間を除く時刻に送信するパケットに含まれる冗長データの割合より大きくする
請求項６記載のストリーム通信装置。
【請求項８】
前記制御手段は、前記損失推定時刻、又は、当該損失推定時刻を含む所定の期間に送信するパケットを重複して送信するよう制御する
請求項６記載のストリーム通信装置。
【請求項９】
前記推定手段は、前記片方向伝送遅延が、所定の割合で増加する場合に、以前にパケット損失が発生した場合の片方向伝送遅延に一致するまでの時間を前記送信時刻又は前記受信時刻に加えた時刻を、前記損失推定時刻として推定し、
前記所定の割合は、前記蓄積手段によって蓄積された前記片方向伝送遅延の増加の割合である
請求項３又は６記載のストリーム通信装置。
【請求項１０】
前記蓄積手段は、さらに、前記パケットに対応するシーケンス番号を蓄積し、
前記推定手段は、前記兆候を検出した場合、前記蓄積手段によって蓄積された前記シーケンス番号と、前記片方向伝送遅延の増加の程度と、前記送信時刻及び前記受信時刻のうち少なくとも一方とから、前記パケット損失が生じるパケットに対応するシーケンス番号である損失推定シーケンス番号を推定することで、前記損失推定シーケンス番号に対応するパケットを前記損失推定パケットとして推定する
請求項５記載のストリーム通信装置。
【請求項１１】
前記制御手段は、前記損失推定シーケンス番号に対応するパケットに含まれる冗長データの割合を、前記損失推定シーケンス番号を除くシーケンス番号に対応する当該パケットに含まれる冗長データの割合より大きくする
請求項１０記載のストリーム通信装置。
【請求項１２】
前記制御手段は、前記損失推定シーケンス番号に対応するパケットを重複して送信するよう制御する
請求項１０記載のストリーム通信装置。
【請求項１３】
前記検出手段は、前記片方向伝送遅延が連続して増加する区間が、予め定められた第１閾値以上である場合に、前記兆候を検出する
請求項１記載のストリーム通信装置。
【請求項１４】
前記検出手段は、前記パケットに関するパラメータの値に応じて、前記第１閾値を変更する
請求項１３記載のストリーム通信装置。
【請求項１５】
前記検出手段は、前記パケットを受信する間隔である受信間隔が短いほど、前記第１閾値を大きくなるように変更する
請求項１４記載のストリーム通信装置。
【請求項１６】
前記検出手段は、所定の期間内の前記片方向伝送遅延の増加量の平均値が予め定められた第２閾値以上であるかを判断し、前記増加量の平均値が前記第２閾値以上であると判断した場合に、前記兆候を検出する
請求項１記載のストリーム通信装置。
【請求項１７】
前記ストリーム通信装置は、複数のルータを介して前記ストリームの送信又は受信をし、
前記推定手段は、前記複数のルータのうち、過去にパケット損失を発生したルータについて、パケット損失発生時の片方向伝送遅延に基づいて、前記損失推定パケットを推定する
請求項１記載のストリーム通信装置。
【請求項１８】
パケット交換ネットワーク上でルータを介してストリームの送信又は受信を行うストリーム通信方法であって、
前記ストリームを小さく分割したパケットが送信されてから受信されるまでの時間である片方向伝送遅延を蓄積する蓄積ステップと、
前記蓄積ステップにおいて蓄積された片方向伝送遅延の増加傾向を判断することで、パケット損失につながる兆候を検出する検出ステップと、
前記兆候を検出した場合、前記蓄積ステップにおいて蓄積された前記片方向伝送遅延の増加の程度から、前記パケット損失が生じるパケットである損失推定パケットを推定する推定ステップとを含む
ストリーム通信方法。
【請求項１９】
パケット交換ネットワーク上でルータを介してストリームの送信又は受信を行う第１ストリーム通信装置及び第２ストリーム通信装置を備えるストリーム通信システムであって、
前記第１ストリーム通信装置は、
前記パケットの受信時刻と、当該パケットが送信された時刻である送信時刻との差である前記片方向伝送遅延を算出するＯＷＤ算出手段と、
前記片方向伝送遅延を蓄積する蓄積手段と、
前記蓄積手段に蓄積された片方向伝送遅延の増加傾向を判断することで、パケット損失につながる兆候を検出する検出手段と、
前記兆候を検出した場合、前記蓄積手段に蓄積された前記片方向伝送遅延の増加の程度から、前記パケット損失が生じるパケットである損失推定パケットを推定する推定手段とを備え、
前記第２ストリーム通信装置は、
前記パケット損失が生じた場合に、当該パケットに含まれるストリームを回復するように、前記損失推定パケットを制御する制御手段を備える
ストリーム通信システム。
【請求項２０】
パケット交換ネットワーク上でルータを介してストリームの送信又は受信を行う第１ストリーム通信装置及び第２ストリーム通信装置を備えるストリーム通信システムであって、
前記第１ストリーム通信装置は、
前記パケットの受信時刻と、当該パケットが送信された時刻である送信時刻との差である前記片方向伝送遅延を算出するＯＷＤ算出手段を備え、
前記第２ストリーム通信装置は、
前記片方向伝送遅延を蓄積する蓄積手段と、
前記蓄積手段によって蓄積された片方向伝送遅延の増加傾向を判断することで、パケット損失につながる兆候を検出する検出手段と、
前記兆候を検出した場合、前記蓄積手段によって蓄積された前記片方向伝送遅延の増加の程度から、前記パケット損失が生じるパケットである損失推定パケットを推定する推定手段と、
前記パケット損失が生じた場合に、当該パケットに含まれるストリームを回復するように、前記損失推定パケットを制御する制御手段とを備える
ストリーム通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、パケット交換ネットワーク上でルータを介してストリームの送信又は受信を行うストリーム通信装置等に関する。
【背景技術】
【０００２】
ＨＤ（Ｈｉｇｈ−Ｄｅｆｉｎｉｔｉｏｎ）という言葉に代表されるように映像コンテンツ（ｃｏｎｔｅｎｔｓ）は高解像度化・高画質化している。また、音声及び音楽コンテンツも高音質化している。これに伴い、パケット交換ネットワーク（以降、ネットワークと記載）上で配信されるコンテンツも高品質化している。
【０００３】
ネットワークにおいて、映像コンテンツや音声・音楽コンテンツなどを配信する場合、大きく３つの形態に区別することができる。１つ目は映像や音楽のファイルのダウンロードに代表される実時間的な配信が求められない形態である。２つ目はＶＯＤ（Ｖｉｄｅｏ  Ｏｎ  Ｄｅｍａｎｄ）に代表される半実時間的な配信が求められる形態である。３つ目はＴＶ会議システムなど双方向コミュニケーションやライブ映像配信に代表される実時間的な配信が求められる形態である。特に、実時間的なコンテンツ配信が求められるケースでは、コンテンツ配信からコンテンツ再生完了までに許容される遅延時間は著しく制限される。
【０００４】
次に、ベストエフォートのネットワーク上で高品質なコンテンツを実時間的に配信する形態について議論する。以降、コンテンツの配信側を送信ノード、コンテンツの再生側を受信ノードと記載する。
【０００５】
インターネットなどベストエフォートのネットワーク上では輻輳によるパケット損失が発生する。
【０００６】
ここで、ネットワーク上での輻輳によるパケット損失の発生について説明する。
ネットワークにおける通信では、ネットワーク上に設置されるパケット交換機（以降、ルータと記載）を経由して、パケットという単位に分割されたデータが送られる。
【０００７】
ルータは、流入するパケットを一時溜める有限のバッファ領域を持つ。
図２４は、バッファにパケットが溜まっていないことを示す図である。
【０００８】
パケット１７０３及び１７０４は、ルータ１７０１から出力される出力リンクの回線速度が十分速く、かつ、ルータ１７０１のパケット交換能力が十分な場合、ルータ上のバッファで待たされることなく出力リンクに送出される。このとき、パケット１７０３及び１７０４の伝送遅延は、ほぼネットワーク上の物理的な伝送遅延の合計とほぼ同等となる。
【０００９】
しかし、ルータ１７０１に流入するパケット１７０３及び１７０４が増加して、パケット１７０３及び１７０４が、出力リンクの回線速度やルータ１７０１のパケット交換能力を上回ると、パケット１７０３及び１７０４はルータ１７０１上のバッファ１７０２に溜まり始める。
【００１０】
図２５は、バッファ１７０２にパケットが溜まり始めたことを示す図である。
ルータ１７０１に流入するパケット１８０３及び１８０４が増加して、ルータ１７０１上のバッファ１７０２に溜まり始める。
【００１１】
図２６は、バッファ１７０２が満杯になったことを示す図である。
この時点で流入するパケット１９０３及び１９０４は、バッファ１７０２から溢れ、廃棄されることになる。パケット１９０３及び１９０４が廃棄される状況をパケット損失という。
【００１２】
パケット損失に対しては一般的に再送制御や前方誤り訂正（Ｆｏｒｗａｒｄｉｎｇ  Ｅｒｒｏｒ  Ｃｏｒｒｅｃｔｉｏｎ：ＦＥＣ）などの手法が使われる。
【００１３】
再送制御は損失したパケットを再び配送するので、パケット損失の検出と再送パケットの配送に最短でも送信ノードと受信ノードとの間のパケット往復遅延（Ｒｏｕｎｄ  Ｔｒｉｐ  Ｔｉｍｅ：ＲＴＴ）分の時間を消費する。このため、コンテンツの実時間的な配信が求められるケースでは使用できないことが多い。
【００１４】
一方、ＦＥＣは、損失に対する回復能力を示す冗長度から、元データであるコンテンツデータに対して冗長データを生成して、受信ノードにコンテンツデータと冗長データを送信するという手法である。ＦＥＣは、再送制御に比べて冗長データを送信するので余分なネットワーク帯域を消費するが、必要となる遅延時間は短く実時間的なコンテンツ配信が求められるケースに適している。
【００１５】
しかし、ＦＥＣは、パケット損失が発生した場合は冗長データから元のコンテンツデータを回復させることができるが、回復能力を超えるパケット損失が発生すると損失したコンテンツデータを回復させることができない。
【００１６】
高品質なコンテンツのデータが損失すると、元々のコンテンツが高品質な分、ノイズや映像・音途切れが目立ち易く、上記コンテンツの視聴者に与える不快感は相対的に大きくなることが考えられる。逆に上記冗長度が必要以上に大きいと、パケット損失が発生するもしくは発生しないに係らず、余分な冗長データ送信によるネットワーク帯域の消費が大きくなる。
【００１７】
このとき、ネットワークの空き帯域は限られているので、冗長データ送信に消費されるネットワーク帯域が増加すると、コンテンツデータ送信に使うことができるネットワーク帯域は減少する。映像や音声、音楽などのコンテンツソースを高品質に符号化しようとすると基本的に多くの情報量が必要となるが、コンテンツソースの符号化に使用できる情報のレート（以降、符号化レートと記述）が不足すると、ノイズ発生等のコンテンツの品質劣化が発生し、好ましくない。
【００１８】
そこで、元のコンテンツデータを回復させることができ、かつ、余分な冗長データの送信による無駄な帯域使用を防ぐことが必要である。
【００１９】
特許文献１では、損失に対する回復能力を示すＦＥＣの冗長度を、パケット損失率などある程度長期的な統計値により動的に決定する方法が開示されている。
【００２０】
また、輻輳情報通知機能（Ｅｘｐｌｉｃｉｔ  Ｃｏｎｇｅｓｔｉｏｎ  Ｎｏｔｉｆｉｃａｔｉｏｎ：ＥＣＮ）というネットワークが混んできたことを示す指標を利用し、パケット損失を予測することもできる。
【００２１】
特許文献２ではＥＣＮフィードバックと過去のパケット損失パターンを使ったパケット損失予測方法が開示されている。
【特許文献１】特開２００６−１０１２７５号公報
【特許文献２】特開２００２−１２４９９１号公報
【発明の開示】
【発明が解決しようとする課題】
【００２２】
しかしながら、上記従来技術では、パケット損失率などある程度長期的な統計値により動的に冗長度を決定するＦＥＣでは、冗長度が必要以上に小さいと、突発的に発生するパケット損失に対して回復能力が足りず、損失したコンテンツデータを回復することができない。
【００２３】
図２７は、パケット損失率を利用してＦＥＣの冗長度を変化させた場合のコンテンツデータ及び冗長データの消費帯域を示す図である。
【００２４】
図２７は縦軸に帯域の変化、横軸に時刻の変化を示す。ここでは、時刻Ｔ１及びＴ２でパケット損失が発生すると仮定する。また、送信レート（Ｓｅｎｄｉｎｇ  Ｒａｔｅ）１３００はコンテンツデータ及び冗長データを送信するための消費帯域である。送信レート１３００は単純化のために一定値にしている。
【００２５】
時刻Ｔ０から時刻Ｔ１までの区間はパケット損失が発生しないので、パケット損失率は徐々に低下する。これにより、パケット損失率を用いたＦＥＣの冗長度は段階的に減少し、コンテンツデータの符号化レートは増加することで、冗長データ送信による消費帯域１３０５は減少し、コンテンツデータ送信による消費帯域１３０４は増加する。
【００２６】
時刻Ｔ１でパケット損失が発生した時、ＦＥＣの冗長度は減少しているので、上記パケット損失を回復させる能力が不足し、損失したコンテンツデータを回復できない可能性が高い。
【００２７】
次に、時刻Ｔ１の直後では、一時的に増加したパケット損失率に応じてＦＥＣの冗長度が増加し、コンテンツデータの符号化レートは減少する。よって、冗長データ送信による消費帯域１３０５は増加し、コンテンツデータ送信による消費帯域１３０４は減少する。
【００２８】
時刻Ｔ１から時刻Ｔ２までの区間は、パケット損失が発生せず、パケット損失率は、時刻Ｔ０から時刻Ｔ１の区間と同様に、徐々に低下する。これにより、パケット損失率を用いたＦＥＣの冗長度は段階的に減少し、コンテンツデータの符号化レートは増加することで、冗長データ送信による消費帯域１３０５は減少し、コンテンツデータ送信による消費帯域１３０４は増加する。
【００２９】
時刻Ｔ２でパケット損失が発生した時、時刻Ｔ１と同様にＦＥＣの冗長度は減少しているので、上記パケット損失を回復させる能力が不足し、損失したコンテンツデータを回復できない可能性が高い。
【００３０】
以上のように、パケット損失率という長期的な統計情報を用いてＦＥＣの冗長度を決定する従来技術では、効果的にＦＥＣの冗長度を制御することはできない。
【００３１】
特許文献２ではＥＣＮフィードバックと過去のパケット損失パターンを使ったパケット損失予測方法が開示されている。しかしまた、ＥＣＮフィードバックを利用する方法では、ＥＣＮはネットワークが混んできたことは判明するが、パケット損失の発生する時刻を正確に予測することはできない。またＥＣＮに対応したルータも必要になる。加えて、過去のパケット損失パターンを使った損失予測は常に変化するネットワークに素早く対応できず、正確にパケット損失の発生を予測し、効果的にＦＥＣの冗長度を制御することはできない。
【００３２】
そこで、本発明では、将来発生するパケット損失が生じるパケットを正確に推定するストリーム通信装置を提供することを目的とする。
【課題を解決するための手段】
【００３３】
上記目的を達成するために、本発明のストリーム通信装置は、パケット交換ネットワーク上でルータを介してストリームの送信又は受信を行うストリーム通信装置であって、前記ストリームを構成するパケットが送信されてから受信されるまでの時間である片方向伝送遅延を蓄積する蓄積手段と、前記蓄積手段に蓄積された片方向伝送遅延の増加傾向を判断することで、パケット損失につながる兆候を検出する検出手段と、前記兆候が検出された場合、前記蓄積手段に蓄積された前記片方向伝送遅延の増加の程度から、前記パケット損失が生じるパケットである損失推定パケットを推定する推定手段とを備える。
【００３４】
パケット損失は、ネットワーク上のルータのバッファが一杯になった場合に発生する。片方向伝送遅延は、バッファに溜まるパケットの量に比例して大きくなり、パケット損失が発生するときの片方向伝送遅延は既知である。よって、片方向伝送遅延の増加の程度と既知のパケット損失発生時の片方向伝送遅延とから、現在の時刻よりどれだけ後の時間にパケット損失が発生するかを正確に推定でき、パケット損失が生じるパケットを推定できる。
【００３５】
また、前記ストリーム通信装置は、さらに、前記パケットを受信するパケット受信手段と、前記パケットの受信時刻と、パケットに含まれる送信時刻との差である前記片方向伝送遅延を算出するＯＷＤ算出手段とを備え、前記蓄積手段は、前記ＯＷＤ算出手段により算出された前記片方向伝送遅延を蓄積してもよい。
【００３６】
これにより、片方向伝送遅延を算出する。したがって、パケット損失が生じるパケットを正確に推定できる。
【００３７】
また、前記蓄積手段は、さらに、前記送信時刻及び前記受信時刻のうち少なくとも一方を蓄積し、前記兆候を検出した場合、前記蓄積手段によって蓄積された前記片方向伝送遅延の増加の程度と、前記送信時刻及び前記受信時刻のうち少なくとも一方とから、前記パケット損失が生じる時刻である損失推定時刻を推定することで、前記損失推定時刻に送信されるパケットを前記損失推定パケットとして推定してもよい。
【００３８】
これにより、パケット損失が生じる時刻を正確に推定する。したがって、推定した時刻からパケット損失が生じるパケットを正確に推定できる。
【００３９】
また、前記蓄積手段は、さらに、前記パケットに対応するシーケンス番号を蓄積し、前記推定手段は、前記蓄積手段によって蓄積された前記片方向伝送遅延の増加の程度と、前記シーケンス番号と、前記送信時刻及び前記受信時刻のうち少なくとも一方とから、前記パケット損失が発生するパケットに対応するシーケンス番号である損失推定シーケンス番号を推定することで、前記損失推定シーケンス番号に対応するパケットを前記損失推定パケットとして推定してもよい。
【００４０】
これにより、パケット損失が生じるパケットに対応するシーケンス番号である損失推定シーケンス番号を正確に推定する。したがって、損失推定シーケンス番号からパケット損失が生じるパケットを正確に推定できる。
【００４１】
また、前記ストリーム通信装置は、さらに、前記パケット損失が生じた場合に、パケット損失が生じたパケットに含まれるストリームの一部を回復するように、前記損失推定パケットを制御する制御手段を備えてもよい。
【００４２】
これにより、パケット損失が生じても、当該パケットに含まれるストリームを回復できる。
【００４３】
また、前記蓄積手段は、さらに、前記パケットの受信時刻と、当該パケットが送信された時刻である送信時刻とのうち少なくとも一方を蓄積し、前記推定手段は、前記兆候を検出した場合、前記蓄積手段によって蓄積された前記片方向伝送遅延の増加の程度と、前記送信時刻及び前記受信時刻のうち少なくとも一方とから、前記パケット損失が生じる時刻である損失推定時刻を推定することで、前記損失推定時刻に送信されるパケットを前記損失推定パケットとして推定してもよい。
【００４４】
これにより、パケット損失が生じるパケットを正確に推定できる。したがって、パケット損失が生じると推定された時刻にパケット損失が発生しても、当該パケットに含まれるストリームを回復できる。
【００４５】
また、前記制御手段は、前記損失推定時刻、又は、当該損失推定時刻を含む所定の期間に送信するパケットに含まれる冗長データの割合を、前記損失推定時刻を除く時刻、又は、前記損失推定時刻を含む所定の期間を除く時刻に送信するパケットに含まれる冗長データの割合より大きくしてもよい。
【００４６】
これにより、パケット損失が生じる時刻、又は、パケット損失が生じる時刻を含む所定の期間に送信するパケットに含まれる冗長データが当該パケットに占める割合を大きくできる。したがって、当該パケットにパケット損失が発生しても、当該パケットに含まれるストリームを回復できる。
【００４７】
また、前記制御手段は、前記損失推定時刻、又は、当該損失推定時刻を含む所定の期間に送信するパケットを重複して送信するよう制御してもよい。
【００４８】
これにより、パケット損失が生じる時刻、又は、パケット損失が生じる時刻を含む所定の期間に送信するパケットは、重複して送信できる。したがって、当該パケットにパケット損失が発生しても、重複して送信されたパケットによって当該パケットに含まれるストリームを回復できる。
【００４９】
また、前記推定手段は、前記片方向伝送遅延が、所定の割合で増加する場合に、以前にパケット損失が発生した場合の片方向伝送遅延に一致するまでの時間を前記送信時刻又は前記受信時刻に加えた時刻を、前記損失推定時刻として推定し、前記所定の割合は、前記蓄積手段によって蓄積された前記片方向伝送遅延の増加の割合であるとしてもよい。
【００５０】
これにより、損失推定時刻を推定できる。したがって、パケット損失が生じるパケットを正確に推定できる。
【００５１】
また、前記蓄積手段は、さらに、前記パケットに対応するシーケンス番号を蓄積し、前記推定手段は、前記兆候を検出した場合、前記蓄積手段によって蓄積された前記シーケンス番号と、前記片方向伝送遅延の増加の程度と、前記送信時刻及び前記受信時刻のうち少なくとも一方とから、前記パケット損失が生じるパケットに対応するシーケンス番号である損失推定シーケンス番号を推定することで、前記損失推定シーケンス番号に対応するパケットを前記損失推定パケットとして推定してもよい。
【００５２】
これにより、パケット損失が生じるパケットに対応するシーケンス番号である損失推定シーケンス番号を正確に推定できる。したがって、損失推定シーケンス番号に対応するパケットにパケット損失が発生しても、当該パケットに含まれるストリームを回復できる。
【００５３】
また、前記制御手段は、前記損失推定シーケンス番号に対応するパケットに含まれる冗長データの割合を、前記損失推定シーケンス番号を除くシーケンス番号に対応する当該パケットに含まれる冗長データの割合より大きくしてもよい。
【００５４】
これにより、損失推定シーケンス番号に対応するパケットに含まれる冗長データの占める割合を大きくできる。したがって、当該パケットにパケット損失が発生しても、当該パケットに含まれるストリームを回復できる。
【００５５】
また、前記制御手段は、前記損失推定シーケンス番号に対応するパケットを重複して送信するよう制御してもよい。
【００５６】
これにより、損失推定シーケンス番号に対応するパケットを重複して送信できる。したがって、当該パケットにパケット損失が発生しても、重複して送信されたパケットによって当該パケットに含まれるストリームを回復できる。
【００５７】
また、前記検出手段は、前記片方向伝送遅延が連続して増加する区間が、予め定められた第１閾値以上である場合に、前記兆候を検出してもよい。
【００５８】
これにより、パケット損失につながる兆候を検出できる。したがって、パケット損失が生じるパケットを正確に推定できる。
【００５９】
また、前記検出手段は、前記パケットに関するパラメータの値に応じて、前記第１閾値を変更してもよい。
【００６０】
これにより、パケット損失につながる兆候を正確に検出できる。したがって、パケット損失が生じるパケットを正確に推定できる。
【００６１】
また、前記検出手段は、前記パケットを受信する間隔である受信間隔が短いほど、前記第１閾値を大きくなるように変更してもよい。
【００６２】
これにより、パケット損失につながる兆候をより正確に検出できる。したがって、パケット損失が生じるパケットをより正確に推定できる。
【００６３】
また、前記検出手段は、所定の期間内の前記片方向伝送遅延の増加量の平均値が予め定められた第２閾値以上であるかを判断し、前記増加量の平均値が前記第２閾値以上であると判断した場合に、前記兆候を検出してもよい。
【００６４】
これにより、パケット損失につながる兆候を正確に検出できる。したがって、パケット損失が生じるパケットを正確に推定できる。
【００６５】
また、前記ストリーム通信装置は、複数のルータを介して前記ストリームの送信又は受信をし、前記推定手段は、前記複数のルータのうち、過去にパケット損失を発生したルータについて、パケット損失発生時の片方向伝送遅延に基づいて、前記損失推定パケットを推定してもよい。
【００６６】
これにより、複数のルータ毎に、パケットが送信されてから受信されるまでの時間である片方向伝送遅延の増加の程度から、パケット損失が発生するパケットを推定できる。
【００６７】
なお、本発明は、このようなストリーム通信装置として実現することができるだけでなく、ストリーム通信装置に含まれる特徴的な手段をステップとするストリーム通信方法として実現したりすることもできる。
【００６８】
また、本発明は、ストリーム通信システムであってもよく、本発明のストリーム通信システムは、パケット交換ネットワーク上でルータを介してストリームの送信又は受信を行う第１ストリーム通信装置及び第２ストリーム通信装置を備えるストリーム通信システムであって、前記第１ストリーム通信装置は、前記パケットの受信時刻と、当該パケットが送信された時刻である送信時刻との差である前記片方向伝送遅延を算出するＯＷＤ算出手段と、前記片方向伝送遅延を蓄積する蓄積手段と、前記蓄積手段に蓄積された片方向伝送遅延の増加傾向を判断することで、パケット損失につながる兆候を検出する検出手段と、前記兆候を検出した場合、前記蓄積手段に蓄積された前記片方向伝送遅延の増加の程度から、前記パケット損失が生じるパケットである損失推定パケットを推定する推定手段とを備え、前記第２ストリーム通信装置は、前記パケット損失が生じた場合に、当該パケットに含まれるストリームを回復するように、前記損失推定パケットを制御する制御手段を備えるストリーム通信システムである。
【００６９】
また、本発明は、他のストリーム通信システムであってよく、本発明のストリーム通信システムは、パケット交換ネットワーク上でルータを介してストリームの送信又は受信を行う第１ストリーム通信装置及び第２ストリーム通信装置を備えるストリーム通信システムであって、前記第１ストリーム通信装置は、前記パケットの受信時刻と、当該パケットが送信された時刻である送信時刻との差である前記片方向伝送遅延を算出するＯＷＤ算出手段を備え、前記第２ストリーム通信装置は、前記片方向伝送遅延を蓄積する蓄積手段と、前記蓄積手段によって蓄積された片方向伝送遅延の増加傾向を判断することで、パケット損失につながる兆候を検出する検出手段と、前記兆候を検出した場合、前記蓄積手段によって蓄積された前記片方向伝送遅延の増加の程度から、前記パケット損失が生じるパケットである損失推定パケットを推定する推定手段と、前記パケット損失が生じた場合に、当該パケットに含まれるストリームを回復するように、前記損失推定パケットを制御する制御手段とを備えるストリーム通信システムである。
【発明の効果】
【００７０】
以上より、本発明は、将来発生するパケット損失が生じるパケットを正確に推定するストリーム通信装置、ストリーム通信方法及びストリーム通信システムを提供できる。
【発明を実施するための最良の形態】
【００７１】
（実施の形態１）
本実施の形態のストリーム通信装置は、ネットワーク上でルータを介してストリームを送受信するストリーム通信装置であって、パケットの片方向伝送遅延を蓄積し、片方向伝送遅延の遅延量の増加傾向を判断することで、パケット損失につながる兆候を検出する。パケット損失につながる兆候を検出した場合、ストリーム通信装置は、片方向伝送遅延の遅延量の増加（延長）の程度から、パケット損失が生じる時刻である損失推定時刻を推定する。ここで、ストリーム通信装置は、推定時刻にパケット損失が生じないように、例えば冗長データの冗長度を大きくするといった、送信するパケットを制御することが望ましい。
【００７２】
以下、図面を参照しながら詳細に説明する。
図１は、本実施の形態１のストリーム通信システム１６１０のシステム構成図である。
【００７３】
ストリーム通信システム１６１０は、ストリームを配信するストリーム通信装置（以降、送信ノードと記載）１６００と、ルータ１６０１及び１６０３と、ストリームを受信するストリーム通信装置（以降、受信ノードと記載）１６０４とを備える。
【００７４】
送信ノード１６００と、ルータ１６０１及び１６０３と、受信ノード１６０４とは、ネットワーク１６０２を介して接続される。
【００７５】
送信ノード１６００は、例えば、映像といったコンテンツを、パケット単位のコンテンツデータに変換し、受信ノード１６０４へストリームとして配信する。送信ノード１６００は、例えば、コンピュータである。
【００７６】
ルータ１６０１及び１６０３は、ネットワーク上に設置されるパケット交換機であり、流入するパケットに付加されているアドレスを読み取り、対応する経路へ転送する。ルータ１６０１及び１６０３は、パケットを一時格納しておくためのバッファを備える。
【００７７】
ネットワーク１６０２は１つ以上のルータもしくはスイッチもしくはホストコンピュータで相互接続されたパケット交換ネットワークである。
【００７８】
受信ノード１６０４は、送信ノード１６００が配信するコンテンツデータを受信して復号し、コンテンツを出力する。例えば、受信ノード１６０４はパソコンである。
【００７９】
多くの場合、送信ノード１６００において時刻を管理する基準となる時計と、受信ノード１６０４において時刻を管理する基準となる時計との間では、同期が図られていない。
【００８０】
以下、本実施の形態の受信ノード１６０４及び送信ノード１６００の構成について説明する。
【００８１】
図２は、本実施の形態の受信ノード１６０４のブロック図である。
受信ノード１６０４は、送信ノード１６００が送信したコンテンツデータを含むパケットを受信し、復号してコンテンツを出力する。また、パケット損失が発生する時刻を予測し、送信ノードへパケット損失が発生すると予測された時刻である損失推定時刻を送信する。この受信ノード１６０４は、パケット受信部１０１と、受信バッファ１０２と、コンテンツ復号化処理部１０３と、ＦＥＣ復号化処理部１０４と、パケット送信部１０５と、パケット損失予測部１０６とを備える。
【００８２】
パケット受信部１０１は、ネットワークを介して送信ノードから送信されるパケットを任意の時間間隔で受信する。例えば、パケット受信部１０１はＬＡＮ  Ｉ／Ｆカード等である。
【００８３】
受信バッファ１０２は、パケット受信部１０１から受信したコンテンツデータ、冗長データ又はその両方を含むパケットを一旦蓄積する。例えば、受信バッファ１０２は半導体メモリ等である。
【００８４】
コンテンツ復号化処理部１０３は、受信バッファ１０２に蓄積されたパケットから符号化されたコンテンツデータを抽出して復号化を行う。また、コンテンツ復号化処理部１０３は、任意のタイミングでコンテンツを出力する。例えば、コンテンツ復号化処理部１０３はＣＰＵである。
【００８５】
ＦＥＣ復号化処理部１０４は、受信したパケットにパケット損失が発生した場合、任意のタイミングで、受信バッファ１０２に蓄積されたパケットに含まれる冗長データを使用して、損失したコンテンツデータを回復する。例えば、ＦＥＣ復号化処理部１０４はＣＰＵである。また、ＦＥＣ復号化処理部１０４は、パケット損失が発生していない場合は、損失パケットの回復処理を行わない。
【００８６】
パケット送信部１０５は、パケット損失予測部１０６が作成したレポートが含まれるパケットを介して送信ノードへネットワークを介して送信する。上記レポートには損失推定時刻が含まれる。例えば、パケット送信部１０５はＬＡＮ  Ｉ／Ｆカードである。
【００８７】
パケット損失予測部１０６は、パケット受信部１０１を介して受信した、送信時刻を含むパケットを使用して、損失推定時刻を推定する。例えば、パケット損失予測部１０６は、メモリを備えたＣＰＵである。
【００８８】
図３は、パケット損失予測部１０６の詳細な構成の一例を示すブロック図である。
パケット損失予測部１０６は、ＯＷＤ算出部２０１と、検出部２０２と、推定部２０３と、蓄積部２０４と、レポート作成部２０５とから構成される。
【００８９】
ＯＷＤ算出部２０１は、パケットに付加されている送信時刻と受信ノード１６０４がパケットを受信した時刻とから、パケットが送信されてから受信されるまでにかかった時間、すなわち片方向伝送遅延（Ｏｎｅ  Ｗａｙ  Ｄｅｌａｙ：以降、ＯＷＤとして記載）を算出し、算出したＯＷＤをＯＷＤ履歴として蓄積部２０４に格納する。
【００９０】
なお、送信時刻は、送信ノード１６００で管理されている時計を基準とした時刻であり、受信時刻は、受信ノード１６０４で管理されている時計を基準とした時刻である。前述のように、送信ノード１６００の時計と受信ノード１６０４の時計とでは、同期が図られていない点に注意を要する。
【００９１】
ここで、パケット損失とＯＷＤとの関連について説明する。
図４は、１台のルータ上で輻輳が発生する場合の、時間経過とＯＷＤとの関係を示すグラフである。
【００９２】
ルータのバッファにパケットがほとんど溜まっていない場合、ＯＷＤは、送信ノードから受信ノードまでの伝送路の距離及び種類、速度に依存する。このときのＯＷＤは、図４中のｔ１〜ｔ２のように、安定する。
【００９３】
次に、ルータのバッファにパケットが溜まり始めると、ＯＷＤはルータのバッファに格納されてから取り出されるまでの時間分、余計にかかる。これにより、ルータのバッファに溜まったパケット量に比例して、ＯＷＤは増加する（ｔ２〜ｔ３）。
【００９４】
そして、ルータのバッファが満杯になるまでパケットが蓄積されると、それ以上ＯＷＤは大きくならない。この状態でルータのバッファに入ろうとするパケットは廃棄され、図４中の×印の時刻に、パケット損失が発生する。
【００９５】
よって、ＯＷＤの増加からパケット損失が発生する兆候を検出することができる。
蓄積部２０４は、ＯＷＤ算出部２０１が算出したＯＷＤをＯＷＤ履歴として保持する。ＯＷＤ履歴は、受信したパケット毎のＯＷＤを格納する。例えば、蓄積部２０４はメモリである。
【００９６】
また、蓄積部２０４は、ＯＷＤ算出部２０１が算出したＯＷＤをＯＷＤ履歴として、また、受信したパケットに付加されていた送信時刻を時刻履歴として保持する。なお、蓄積部２０４は、時刻履歴として、パケットを受信した受信時刻を保持してもよく、また、パケットに付加されていた送信時刻と、パケットを受信した受信時刻とを保持してもよい。
【００９７】
検出部２０２は、蓄積部２０４が保持するＯＷＤ履歴からパケット損失が発生する兆候があるか否かを判断する。パケット損失が発生する兆候とは、ＯＷＤ履歴の所定の区間において、ＯＷＤが増加傾向を示すことである。
【００９８】
推定部２０３は、検出部２０２によりパケット損失の発生する兆候が検出した場合、蓄積部２０４が保持するＯＷＤ履歴と、時刻履歴と、過去に発生したパケット損失の直前又は直後のＯＷＤから、損失推定時刻を推定する。
【００９９】
推定部２０３は損失推定時刻を例えば最小二乗法を用いて算出する。パケット損失兆候検出の検出時において、連続した増加傾向を示した区間のＯＷＤ計測値をｙi、同じ区間における受信パケットの送信時刻をｘi、パケット損失直後のＯＷＤ計測値の平均値をＹ、ただし１≦ｉ≦ｎ、としたとき、損失推定時刻であるＸは以下の数１により算出される。
【０１００】
【数１】
2010016722.tif 000003
【０１０１】
レポート作成部２０５は、上記損失推定時刻を記述したレポートを作成する。
以上のように、本実施の形態の受信ノード１６０４は、ＯＷＤを算出して蓄積し、蓄積したＯＷＤからパケット損失が生じる時刻を正確に推定する。
【０１０２】
次に、送信ノード１６００の構成について説明する。
図５は、本実施の形態の送信ノード１６００のブロック図である。
【０１０３】
送信ノード１６００は、パケット受信部６０１と、符号化レート／ＦＥＣ冗長度決定部６０２と、コンテンツ符号化処理部６０３と、ＦＥＣ符号化処理部６０４と、送信バッファ６０５と、パケット送信部６０６と、損失予測保持部６０７とを備える。
【０１０４】
ここで、符号化レート／ＦＥＣ冗長度決定部６０２、ＦＥＣ符号化処理部６０４及び損失予測保持部６０７は、制御部６１０として機能する。
【０１０５】
パケット受信部６０１は、ネットワーク１６０２を介して受信ノード１６０４が作成するレポートが含まれるパケットを受信する。ここで、上記レポートには損失推定時刻が含まれる。例えば、パケット受信部６０１はＬＡＮ  Ｉ／Ｆカードである。また、パケット受信部６０１は、損失推定時刻を損失予測保持部６０７に書き込む。
【０１０６】
符号化レート／ＦＥＣ冗長度決定部６０２は、損失予測保持部６０７に記録された上記損失推定時刻からコンテンツの符号化レート及びＦＥＣ冗長度を決定する。例えば、符号化レート／ＦＥＣ冗長度決定部６０２はＣＰＵである。ＦＥＣ冗長度とは、パケットに含まれる冗長データの割合のことである。パケット損失が生じた場合に、当該パケットのＦＥＣ冗長度が大きいほどコンテンツデータを回復できる能力が高くなる。
【０１０７】
具体的には、符号化レート／ＦＥＣ冗長度決定部６０２は、上記損失推定時刻に送信するコンテンツデータに対してＦＥＣ冗長度を上げる。なお、逆に上記損失推定時刻以外の時刻に送信するコンテンツデータに対してＦＥＣ冗長度を下げる制御を行ってもよい。
【０１０８】
コンテンツ符号化処理部６０３は、符号化レート／ＦＥＣ冗長度決定部６０２が決定した符号化レートに従い、コンテンツソースを符号化し、符号化されたコンテンツデータを送信バッファ６０５に格納する。例えば、コンテンツ符号化処理部６０３は、ＣＰＵである。
【０１０９】
ＦＥＣ符号化処理部６０４は、符号化レート／ＦＥＣ冗長度決定部６０２が決定したＦＥＣ冗長度に従い、コンテンツデータに対して冗長データを生成し、生成した冗長データを送信バッファ６０５に格納する。例えば、ＦＥＣ符号化処理部６０４は、ＣＰＵである。
【０１１０】
送信バッファ６０５は、パケット化されたコンテンツデータと冗長データを一旦蓄積する。なお、上記パケットはＲＴＰ（Ｒｅａｌ−ｔｉｍｅ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ）パケットであってもよい。例えば、送信バッファ６０５はメモリである。
【０１１１】
パケット送信部６０６は、送信バッファ６０５に格納されたパケットを任意のレートで受信ノード１６０４にネットワーク１６０２を介して送信する。また、パケット送信部６０６は、パケットを送信するときに、パケットに送信時刻を付与する。例えば、パケット送信部６０６はＬＡＮ  Ｉ／Ｆカードである。
【０１１２】
損失予測保持部６０７は、受信ノードが推定した損失推定時刻を保持する。例えば、損失予測保持部６０７はメモリである。
【０１１３】
以上のように、本実施の形態の送信ノード１６００は、受信ノード１６０４で推定された損失推定時刻に基づいてＦＥＣ冗長度を制御することで、損失推定時刻にパケット損失が生じた場合に、受信ノード１６０４は、当該パケットに含まれるコンテンツデータを回復できる。
【０１１４】
次に、本実施の形態の受信ノード１６０４及び送信ノード１６００での処理の流れを説明する。
【０１１５】
図６は、本実施の形態の受信ノード１６０４での処理の流れを示すフローチャートである。
【０１１６】
パケット受信部１０１は、送信ノード１６００からパケットを受信したか否かを監視する（Ｓ１１）。パケットを受信しない場合（Ｓ１１でＮｏ）、パケット受信部１０１は、引き続き送信ノード１６００からのパケットの受信を監視する。
【０１１７】
パケットを受信した場合（Ｓ１１でＹｅｓ）、パケット受信部１０１は、受信したパケットを受信バッファ１０２に格納する。ＦＥＣ復号化処理部１０４は、受信バッファ１０２に格納されているパケットの冗長データを使用して、損失したコンテンツデータを回復する。また、ＦＥＣ復号化処理部１０４は、当該パケットにパケット損失が発生しなかった場合、処理を行わない。
【０１１８】
コンテンツ復号化処理部１０３は、回復されたパケットのコンテンツデータを抽出して復号し、コンテンツを出力する（Ｓ１２）。
【０１１９】
また、パケット受信部１０１は、受信したパケットをＯＷＤ算出部２０１へ出力する。
【０１２０】
ＯＷＤ算出部２０１は、パケットに付加された送信ノード１６００からの送信時刻と当該パケットを受信した受信時刻とから、ＯＷＤを算出する（Ｓ１３）。
【０１２１】
蓄積部２０４は、算出されたＯＷＤを蓄積する（Ｓ１４）。
検出部２０２は、蓄積部２０４が蓄積するＯＷＤ履歴からパケット損失につながる兆候があるか否かを判定する（Ｓ１５）。
【０１２２】
検出部２０２が、パケット損失につながる兆候があると判定した場合（Ｓ１５でＹｅｓ）、推定部２０３は、損失推定時刻を推定する（Ｓ１６）。
【０１２３】
レポート作成部２０５は、推定された損失推定時刻を記述したレポートを作成する（Ｓ１７）。
【０１２４】
パケット送信部１０５は、作成されたレポートを含むパケットを送信ノード１６０４へ送信する（Ｓ１８）。また、パケット送信部１０５は、パケット損失につながる兆候がない場合（Ｓ１５でＮｏ）、何も送信しない。
【０１２５】
図７Ａおよび図７Ｂは、本実施の形態の送信ノード１６００の処理の流れを示すフローチャートである。
【０１２６】
このうち、図７Ｂは、パケット受信部６０１と、損失予測保持部６０７との処理の流れを示すフローチャートである。
【０１２７】
パケット受信部６０１は、受信ノード１６０４からパケットを受信したか否かを判定する（Ｓ２５）。パケットを受信した場合（Ｓ２５でＹｅｓ）、パケット受信部６０１は、損失予測保持部６０７に格納されている損失推定時刻を更新する（Ｓ２６）。また、パケットを受信しなかった場合（Ｓ２５でＮｏ）、パケット受信部６０１は何もせず、処理を終了する。
【０１２８】
一方、図７Ａは、送信ノード１６００が備える各処理部のうち、パケット受信部６０１及び損失予測保持部６０７以外の処理部の処理の流れを示すフローチャートである。
【０１２９】
符号化レート／ＦＥＣ冗長度決定部６０２は、受信ノード１６０４から受信したレポートに記述された損失推定時刻に基づき、送信するコンテンツに対して、符号化レートおよびＦＥＣ冗長度の制御を行う（Ｓ２１）。ＦＥＣ冗長度の制御の具体的な説明は後述する。
【０１３０】
コンテンツ符号化処理部６０３は、コンテンツ信号の入力があった場合、符号化レート／ＦＥＣ冗長度決定部６０２で決定された符号化レートに従ってコンテンツを符号化して、コンテンツデータを含むパケットを生成した後、送信バッファ６０５に格納する（Ｓ２２）。
【０１３１】
次に、ＦＥＣ符号化処理部６０４は、符号化レート／ＦＥＣ冗長度決定部６０２によって決定されたＦＥＣ冗長度に従って、冗長データを生成し、送信バッファに格納する（Ｓ２３）。
【０１３２】
パケット送信部６０６は、送信バッファ６０５に格納されたパケットを、受信ノード１６０４へ送信する（Ｓ２４）。
【０１３３】
次に、送信ノード１６００のフローチャート内の、冗長度制御（Ｓ２１）の詳細な処理の流れを述べる。
【０１３４】
図８は、冗長度制御の詳細なフローチャートである。
符号化レート／ＦＥＣ冗長度決定部６０２は、コンテンツデータの送信時刻が損失推定時刻と一致するか否かを判定する（Ｓ３１）。
【０１３５】
送信時刻が損失推定時刻と一致する場合（Ｓ３１でＹｅｓ）、損失推定時刻に送信するコンテンツデータに対してＦＥＣ冗長度を上げる。なお、上記損失推定時刻以外に送信するコンテンツデータに対してＦＥＣ冗長度を下げる制御を行ってもよい。
【０１３６】
送信時刻が損失推定時刻と一致しない場合（Ｓ３１でＮｏ）、当該送信時刻に送信するコンテンツデータのＦＥＣ冗長度は所定値とする（Ｓ３３）。
【０１３７】
以上により、本実施の形態のストリーム通信装置は、ＯＷＤの増加傾向を判断することで、パケット損失につながる兆候を検出して、ＯＷＤの増加の程度（変化の割合）から、パケット損失が生じる時刻である損失推定時刻を正確に推定できる。
【０１３８】
また、ストリーム通信装置は、損失推定時刻にパケット損失が生じないように、損失推定時刻に送信するパケットのＦＥＣ冗長度を大きくする。
【０１３９】
図９は、本実施の形態のストリーム通信装置の送信ノード１６００が送信するコンテンツデータ送信による消費帯域（１４０４）及び冗長データ送信による消費帯域（１４０５）を示す図である。
【０１４０】
図９は、図２７と同様に縦軸に帯域の変化、横軸に時刻の変化を表す。ここで、時刻Ｔ１及び時刻Ｔ２の時点でパケット損失が発生すると仮定する。また、Ｓｅｎｄｉｎｇ  Ｒａｔｅ（１４００）はコンテンツデータ及び冗長データを送信するための消費帯域である。Ｓｅｎｄｉｎｇ  Ｒａｔｅ（１４００）は単純化のために一定値にしている。
【０１４１】
本実施の形態によると、時刻Ｔ０から時刻Ｔ１にかけての区間はほぼパケット損失が発生する兆候がないので、ＦＥＣ冗長度を減少させ、コンテンツデータの符号化レートは増加させる。これにより、消費帯域に占める冗長データ送信による消費帯域（１４０５）は少なく、コンテンツデータ送信による消費帯域（１４０４）は多くなる。
【０１４２】
このことからコンテンツデータに多くの帯域が割り当てられるので、コンテンツの品質を維持するのに十分な符号化レートが確保でき、コンテンツの品質の劣化を防止できる。
【０１４３】
次に、時刻Ｔ１に時刻が近付くと、受信ノード１６０４は、パケット損失が発生する兆候を検出する。そして、パケット損失が発生する可能性が高い時刻を予測することで、時刻Ｔ１付近のＦＥＣ冗長度を増加させ、コンテンツデータの符号化レートを減少させる。したがって、消費帯域に占める冗長データ送信による消費帯域（１４０５）は多くなり、コンテンツデータ送信による消費帯域（１４０４）は少なくなる。
【０１４４】
ここでは、パケット損失が発生する時刻Ｔ１付近において、ＦＥＣ冗長度は増加しているので、上記パケット損失を回復させる能力が十分に確保できる。よって、パケット損失が発生しても、損失したコンテンツデータを回復できる可能性が高い。
【０１４５】
同様に、本実施の形態のストリーム通信装置は、次のパケット損失が発生する時刻Ｔ２付近でも、時刻Ｔ１と同様にＦＥＣ冗長度を増加させ、コンテンツデータの符号化レートを減少させる。したがって、消費帯域に占める冗長データ送信による消費帯域（１４０５）は多くなり、コンテンツデータ送信による消費帯域（１４０４）は少なくなる。
【０１４６】
ここでは、パケット損失が発生する時刻Ｔ２付近において、ＦＥＣ冗長度は増加しているので、上記パケット損失を回復させる能力が十分に確保できる。よって、損失したコンテンツデータを回復できる可能性が高い。
【０１４７】
以上のように、本発明の実施の形態のストリーム通信装置は、パケット損失が発生する可能性が高い時刻には、ＦＥＣ冗長度を高める。これにより、パケット損失によるコンテンツデータの損失を防止することが可能となる。
【０１４８】
また、パケット損失が発生する可能性が低い時刻には、より多くのネットワークの空き帯域をコンテンツデータに割り当てることで符号化レートを上昇させ、配信コンテンツの高品質化することが可能となる。また、符号化レート不足によるコンテンツの歪みやノイズを防止できる。上記防止による効果は、コンテンツデータの損失によるノイズ及び映像・音途切れが目立ち易い高品質なコンテンツをネットワーク上で配信を行う場合に、より一層顕著である。
【０１４９】
なお、パケット送信部１０５は、ＲＴＴやパケット損失率などネットワークの状態に関する１つ以上のパラメータが含まれる制御用パケットを送信ノード１６００へネットワークを介して送信してもよい。また、上記制御用パケットに上記レポートが含まれてもよい。また、上記レポートを含むパケットはＲＴＣP（ＲＴＰ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）パケットであってもよい。
【０１５０】
また、パケット損失予測部１０６が作成するレポートはＴＶ会議システムなど双方向でコンテンツデータを送受信する場合には、相手側に送信するＲＴＰパケットなどコンテンツデータを含むパケットに記述してもよい。
【０１５１】
また、上記ＯＷＤの算出については、送受信ノード間での相対的なＯＷＤの増減を計測できればよく、必ずしも送受信ノード間での時刻は同期する必要はない。ただし、送受信ノード間でクロックのずれがある場合は、ＯＷＤ算出部２０１はクロックのずれによるＯＷＤ増減の影響を取り除いたＯＷＤの算出を行う。
【０１５２】
また、ＯＷＤ算出部２０１は、上記パケットの送信時刻もしくは受信時刻もしくはその両方を上記ＯＷＤ履歴と共に時刻履歴として蓄積部２０４に書き込んでもよい。
【０１５３】
また、検出部２０２は、明らかに一時的もしくは瞬間的なＯＷＤ履歴の変動は、パケット損失の兆候の検出対象から除外してもよい。
【０１５４】
図１０は、一時的なＯＷＤの増加を示すグラフである。
検出部２０２が、一時的なＯＷＤの増加２０００をパケット損失の兆候として検出した場合、推定部２０３は誤った損失推定時刻を推定する可能性が高くなる。
【０１５５】
パケット損失につながるＯＷＤの増加傾向２００１のみを検出するために、検出部２０２は、ＯＷＤ履歴を任意の複数の区間に分割し、１つ以上のＯＷＤを平均化した値が予め定められた値を超えた場合にパケット損失の兆候として検出してもよい。
【０１５６】
また、検出部２０２は、瞬間的なＯＷＤ履歴の変動と推定できる部分については、パケット損失兆候の監視から除外する手段を用いてもよい。例えば、検出部２０２は、予め定められた時間の間のＯＷＤの平均値を算出し、算出された平均値が予め定められた閾値を超えた場合に、パケット損失の兆候を検出してもよい。
【０１５７】
また、検出部２０２は、パケット損失の兆候を検出する条件を、１つのパケットと次のパケットとの間の時間間隔である送信間隔及び受信間隔、ＲＴＴ、ＯＷＤ及びパケット損失率などのうち、１つ以上のパラメータによって随時変更してもよい。
【０１５８】
例えば、パケットの受信間隔を使った場合のパケット損失の兆候を検出する方法を以下に示す。ここでは、直前に受信したパケットのＯＷＤと比較してＯＷＤが増加している区間が第１閾値以上である場合に、パケット損失の兆候を検出する。第１閾値は、パケットを受信する間隔が短いほど、大きくなるように設定する。以下に、検出部２０２がパケット損失の兆候を検出する一例を示す。
【０１５９】
if １０［ｍｓｅｃ］＜ 平均パケット受信間隔
第１閾値を８区間とする
else if ５［ｍｓｅｃ］＜ 平均パケット受信間隔 ≦１０［ｍｓｅｃ］
第１閾値を１５区間とする
else if １［ｍｓｅｃ］＜ 平均パケット受信間隔 ≦５［ｍｓｅｃ］
第１閾値を１８区間とする
else平均パケット受信間隔 ≦１［ｍｓｅｃ］
第１閾値を２０区間とする
【０１６０】
また、推定部２０３は、一時的もしくは瞬間的なＯＷＤの変動と推定できる部分については、損失推定に使用するＯＷＤ履歴から除外してもよい。
【０１６１】
また、推定部２０３は、ネットワーク上でパケット損失が発生するルータが複数存在する場合、ルータ毎に損失推定時刻を推定してもよい。
【０１６２】
図１１は、推定部２０３が保持するルータ毎のパケット損失発生時のＯＷＤを示す図である。
【０１６３】
推定部２０３は、ルータ毎にパケット損失の発生の有無と、発生時のＯＷＤを保持する。
【０１６４】
推定部２０３は、パケット損失発生時のＯＷＤに応じて、パケット損失が発生したルータの違いを判別し、ルータ毎に損失推定時刻を推定する。
【０１６５】
これにより、ネットワーク上でパケット損失が発生するルータが複数存在する場合も、損失推定時刻を正確に推定できる。
【０１６６】
また、推定部２０３は、ＯＷＤの増加の割合が、蓄積手段に蓄積されたＯＷＤの増加の割合で増加する場合に、以前にパケット損失が発生した場合のＯＷＤに一致するまでの時間を送信時刻、受信時刻又は送信時刻から受信時刻の間の時刻に加えた時刻を損失推定時刻として推定してもよい。
【０１６７】
また、符号化レート／ＦＥＣ冗長度決定部６０２はパケット損失率やＲＴＴなどネットワーク状態を示す１つ以上のパラメータから、ネットワークの空き帯域や送信可能な帯域を算出し、その値に応じてコンテンツの符号化レート及びＦＥＣ冗長度の割合を決定してもよい。
【０１６８】
また、パケット送信部６０６は、一定間隔もしくは任意のタイミングで制御用パケットに送信時刻を付与して受信ノードに対して送信してもよい。ここで、上記制御用パケットはＲＴＣPパケットでもよい。
【０１６９】
（変形例１）
次に、本実施の形態の変形例１について述べる。
【０１７０】
本変形例の受信ノード１６０４が備えるパケット損失予測部は、パケット損失が予測される時刻を含む所定の時間区間である損失推定時間区間を推定する。
【０１７１】
以下、本実施の形態のパケット損失予測部１０６と異なる点を中心に述べる。
図１２は、本変形例のパケット損失予測部３００の詳細な構成を示すブロック図である。
【０１７２】
パケット損失予測部３００は、パケット損失予測部１０６と比べて、損失時間区間推定部３０１をさらに備える点が異なる。
【０１７３】
損失時間区間推定部３０１は、推定部２０３が算出した損失推定時刻を基にパケット損失が発生する可能性の高い時間区間である損失推定時間区間を算出する。損失推定時間区間は、損失推定時刻より予め定められた第１の時間早い時刻から、損失推定時刻より予め定められた第２の時間遅い時刻までのことである。
【０１７４】
レポート作成部３０２は、損失推定時間区間の値を含むレポートを作成する。
また、送信ノード１６００の符号化レート／ＦＥＣ冗長度決定部６０２は、損失推定時間区間に送信するコンテンツデータに対してＦＥＣ冗長度を上げる。
【０１７５】
これにより、本変形例のストリーム通信装置は、パケット損失が発生する時刻を含む所定の時間を損失推定間区間として推定できる。よって、損失推定時間区間のいずれの時刻でも、パケット損失によるコンテンツデータの損失を防止することが可能となる。
【０１７６】
なお、符号化レート／ＦＥＣ冗長度決定部６０２は、損失推定時間区間以外の区間に送信するコンテンツデータに対してＦＥＣ冗長度を下げてもよい。
【０１７７】
また、蓄積部２０４は、受信したパケットに対応するシーケンス番号をシーケンス番号履歴として蓄積してもよい。
【０１７８】
また、損失時間区間推定部３０１は、損失推定時刻と、蓄積部２０４が保持するＯＷＤ履歴、時刻履歴及びシーケンス番号履歴のうち１つ以上とから、損失推定時間区間を推定してもよい。また、損失時間区間推定部３０１は、損失推定時刻と、ＯＷＤ履歴及び時刻履歴及びシーケンス番号履歴のうち１つ以上と、ＲＴＴなどのパラメータとを使って、損失推定時間区間を推定してもよい。
【０１７９】
（変形例２）
次に、本実施の形態の変形例２について述べる。
【０１８０】
本変形例の受信ノード１６０４が備えるパケット損失予測部は、パケット損失が予測されるパケットのシーケンス番号を推定する。
【０１８１】
以下、本実施の形態のパケット損失予測部１０６と異なる点を中心に述べる。
図１３は、本変形例のパケット損失予測部４００の詳細な構成を示すブロック部である。
【０１８２】
パケット損失予測部４００は、パケット損失予測部１０６と比べて、損失シーケンス番号推定部４０２をさらに備える点が異なる。また、蓄積部４０１は蓄積部２０４と比べて、さらに、受信したパケットに対応するシーケンス番号をシーケンス番号履歴として蓄積する点が異なる。
【０１８３】
損失シーケンス番号推定部４０２は、推定部２０３が推定した損失推定時刻と蓄積部４０１が保持するシーケンス番号履歴から、パケット損失が予測されるパケットである損失推定シーケンス番号を推定する。
【０１８４】
レポート作成部４０３は、上記損失推定シーケンス番号を含むレポートを作成する。
また、送信ノード１６００が備える符号化レート／ＦＥＣ冗長度決定部６０２は、損失推定シーケンス番号に対応するパケットに対してＦＥＣ冗長度を上げる。
【０１８５】
これにより、本変形例のストリーム通信装置は、パケット損失が発生するパケットに対応するシーケンス番号を推定することで、パケット損失が発生するパケットを推定する。また、パケット損失が予測されるシーケンス番号に対応するパケットのコンテンツデータの損失を防止できる。
【０１８６】
なお、符号化レート／ＦＥＣ冗長度決定部６０２は、損失推定シーケンス番号以外のシーケンス番号に対応するパケットのコンテンツデータに対してＦＥＣ冗長度を下げてもよい。
【０１８７】
また、損失シーケンス番号推定部４０２は、シーケンス番号履歴と、推定部２０３が推定した損失推定時刻、蓄積部４０１が保持するＯＷＤ履歴及び時刻履歴のうち２つ以上の組み合わせとから損失推定シーケンス番号を推定してもよい。
【０１８８】
また、損失シーケンス番号推定部４０２は、シーケンス番号履歴と、推定部２０３が推定した損失推定時刻、蓄積部４０１が保持するＯＷＤ履歴及び時刻履歴のうち２つ以上の組み合わせと、ＲＴＴなどのパラメータとを使って、損失推定シーケンス番号を推定してもよい。
【０１８９】
また、レポート作成部４０３は、さらに、損失推定時刻を含むレポートを作成してもよい。
【０１９０】
（変形例３）
次に、本実施の形態の変形例３について述べる。
【０１９１】
本変形例の受信ノード１６０４が備えるパケット損失予測部は、パケット損失が予測される複数のパケットに含まれる損失推定シーケンス番号群を推定する。
【０１９２】
以下、本実施の形態の変形例１と異なる点を中心に述べる。
図１４は、本変形例のパケット損失予測部５００の詳細な構成を示すブロック図である。
【０１９３】
パケット損失予測部５００は、パケット損失予測部３００と比べて、さらに、損失シーケンス番号推定部５０１を備える。
【０１９４】
損失シーケンス番号推定部５０１は、損失時間区間推定部３０１が推定した損失推定時間区間と、蓄積部４０１が保持するシーケンス番号履歴から、損失推定シーケンス番号群を推定する。
【０１９５】
レポート作成部５０２は、上記損失推定シーケンス番号群を含むレポートを作成する。また、送信ノード１６００が備える符号化レート／ＦＥＣ冗長度決定部６０２は、損失推定シーケンス番号群を含むパケットに対してＦＥＣ冗長度を上げる。
【０１９６】
これにより、本変形例のストリーム通信装置は、パケット損失が予測される複数のパケットに対応する複数のシーケンス番号を推定することで、パケット損失が発生する複数のパケットを推定する。また、推定された複数のパケットのコンテンツデータの損失を防止できる。
【０１９７】
なお、符号化レート／ＦＥＣ冗長度決定部６０２は、損失推定シーケンス番号群以外のシーケンス番号に対応するパケットのコンテンツデータに対してＦＥＣ冗長度を下げてもよい。
【０１９８】
また、損失シーケンス番号推定部５０１は、シーケンス番号履歴と、損失推定時間区間、蓄積部４０１が保持するＯＷＤ履歴及び時刻履歴のうち２つ以上の組み合わせとから損失推定シーケンス番号群を推定してもよい。
【０１９９】
また、損失シーケンス番号推定部５０１は、シーケンス番号履歴と、損失推定時間区間、ＯＷＤ履歴及び時刻履歴のうち２つ以上の組み合わせと、ＲＴＴなどのパラメータとを使って、損失推定シーケンス番号を推定してもよい。
【０２００】
また、レポート作成部５０２は、さらに、損失推定時刻と、損失推定時間区間と、損失推定シーケンス番号のうち、少なくとも１つを含むレポートを作成してもよい。
【０２０１】
（変形例４）
次に、本実施の形態の変形例４について述べる。
【０２０２】
本変形例の送信ノード１６００が備えるパケット送信部６０６は、受信ノード１６０４によって推定された損失推定時刻に送信されるパケットを重複して送信する。
【０２０３】
以下、本実施の形態と異なる点を中心に述べる。
図１５は、本変形例の送信ノードが備える処理部のうち、パケット受信部６０１及び損失予測保持部６０７以外の処理部での処理の流れを示すフローチャートである。
【０２０４】
なお、パケット送信部６０６及び損失予測保持部６０７での処理は、図７Ｂと同様である。
【０２０５】
図１５では、図７Ａに示したフローチャートと比較して、冗長データ生成（Ｓ２３）処理の後に、送信時刻が損失推定時刻か否かを判定し、パケットを重複送信する処理が加わる。以下、図７Ａと異なる点について述べる。
【０２０６】
パケット送信部６０６は、送信時刻が、損失予測保持部６０７に保持されている損失予測時刻であるか否かを判定する（Ｓ４１）。
【０２０７】
送信時刻が損失予測時刻である場合（Ｙｅｓ）、パケット送信部６０６は、当該パケットを重複して送信する。重複して送信とは、同じパケットを連続して２回送信することである（Ｓ４２）。
【０２０８】
送信時刻が損失予測時刻でない場合（Ｎｏ）、パケット送信部６０６は、通常通り、当該パケットを１回送信する（Ｓ４３）。
【０２０９】
これにより、本変形例のストリーム通信装置は、損失予測時刻にパケット損失が発生した場合、重複して送信されたコンテンツデータにより当該コンテンツデータを回復できる。
【０２１０】
なお、パケット送信部６０６は、損失推定時間区間に送信するパケットを重複して送信してもよい。
【０２１１】
また、パケット送信部６０６は、損失推定シーケンス番号、又は、損失推定シーケンス番号群に含まれるシーケンス番号に対応するパケットを重複して送信してもよい。
【０２１２】
（実施の形態２）
次に、本発明の実施の形態２について述べる。
【０２１３】
本実施の形態のストリーム通信装置は、実施の形態１のストリーム通信装置と比較して、送信ノードがパケット損失の発生する時刻を推定する点が異なる。
【０２１４】
以下、実施の形態１と異なる点を中心に述べる。
図１６は、本実施の形態の受信ノード７００のブロック図である。
【０２１５】
実施の形態１の受信ノード１６０４と比較して、受信ノード７００は、パケット損失予測部１０６がＯＷＤ算出部７０１となっている点が異なる。
【０２１６】
ＯＷＤ算出部７０１は、パケットに付加されている送信時刻と受信ノード７００がパケットを受信した時刻とから、ＯＷＤを算出する。さらに、ＯＷＤ算出部７０１は、算出したＯＷＤを含むレポートを作成し、パケット送信部１０５へ出力する。
【０２１７】
これにより、本実施の形態の受信ノード７００は、受信したパケットのＯＷＤを算出して送信ノードへ伝達できる。
【０２１８】
次に、本実施の形態の送信ノードについて述べる。
図１７は、本実施の形態の送信ノード８００のブロック図である。
【０２１９】
実施の形態１の送信ノード１６００と比較して、送信ノード８００は、さらに、パケット損失予測部８０１を備える点が異なる。
【０２２０】
以下、実施の形態１と異なる点を中心に述べる。
パケット損失予測部８０１は、パケット受信部６０１を介して受信したＯＷＤに関する情報を使って将来発生するパケット損失が発生すると予測される時刻を推定する。
【０２２１】
パケット受信部６０１は、受信ノード７００から受信したＯＷＤを含むレポートを受信して、ＯＷＤをパケット損失予測部８０１へ出力する。パケット損失予測部８０１は、ＯＷＤからパケット損失が発生する兆候を検出して、パケット損失が発生する損失推定時刻を推定し、損失推定時刻を制御部６１０へ出力する。
【０２２２】
図１８は、パケット損失予測部８０１の詳細な構成の一例を示すブロック図である。
パケット損失予測部８０１は、実施の形態１の受信ノード１６０４が備えるパケット損失予測部１０６と比較して、ＯＷＤ算出部２０１及びレポート作成部２０５を備えない点が異なる。
【０２２３】
パケット損失予測部８０１は、パケット受信部６０１が受信したＯＷＤから、パケット損失につながる兆候を検出し、パケット損失が発生すると予測される損失推定時刻を推定する。また、パケット損失予測部８０１は、推定された損失推定時刻を損失予測保持部６０７へ出力する。
【０２２４】
制御部６１０は、損失推定時刻に基づいて送信パケットを制御する。
このように、本実施の形態の送信ノード８００は、受信ノード７００で算出されたＯＷＤに基づいて、ＦＥＣ冗長度を制御し、パケット損失の発生を防止することができる。
【０２２５】
次に、本実施の形態のストリーム通信装置の処理の流れを説明する。
図１９は、本実施の形態の受信ノード７００の処理の流れを示すフローチャートである。
【０２２６】
本実施の形態の受信ノード７００のフローチャートでは、実施の形態１の受信ノード１６０４のフローチャートと比較して、パケット損失予測部１０６が行っていた処理がほぼなくなり、ＯＷＤ算出部７０１の処理のみが残っている。
【０２２７】
パケット受信部１０１は、送信ノード１６００からパケットを受信したか否かを監視する（Ｓ１１）。パケットを受信しない場合（Ｓ１１でＮｏ）、パケット受信部１０１は、引き続き送信ノード１６００からのパケットの受信を監視する。
【０２２８】
パケットを受信した場合（Ｓ１１でＹｅｓ）、パケット受信部１０１は、受信したパケットを受信バッファ１０２に格納する。ＦＥＣ復号化処理部１０４は、受信バッファ１０２に格納されているパケットの冗長データを使用して、損失したパケットを回復する。コンテンツ復号化処理部１０３は、回復されたパケットのコンテンツデータを抽出して復号し、コンテンツを出力する（Ｓ１２）。
【０２２９】
また、パケット受信部１０１は、受信したパケットをＯＷＤ算出部７０１へ出力する。
ＯＷＤ算出部７０１は、パケットに付加された送信ノード１６００からの送信時刻と当該パケットを受信した受信時刻とから、ＯＷＤを算出する（Ｓ１３）。さらに、ＯＷＤ算出部７０１は、ＯＷＤを含むレポートを作成する（Ｓ５１）。
【０２３０】
パケット送信部１０５は、作成されたレポートを含むパケットを送信ノード１６０４へ送信する。
【０２３１】
次に、送信ノード８００の処理の流れを説明する。
図２０は、本実施の形態の送信ノード８００が備えるパケット受信部６０１及びパケット損失予測部８０１、損失予測保持部６０７の処理の流れを示すフローチャートである。
【０２３２】
パケット受信部６０１は、受信ノード１６０４からパケットを受信したか否かを判定する（Ｓ２５）。パケットを受信した場合（Ｓ２５でＹｅｓ）、パケット受信部６０１はパケット損失予測部８０１が備える蓄積部２０４にＯＷＤを格納する（Ｓ１４）。
【０２３３】
検出部２０２は、蓄積部２０４に格納されているＯＷＤ履歴からパケット損失につながる兆候を検出する（Ｓ１５）。
【０２３４】
検出部２０２がパケット損失につながる兆候を検出した場合（Ｙｅｓ）、推定部２０３は、損失推定時刻を推定して（Ｓ１６）、損失予測保持部６０７に格納されている損失推定時刻を更新する（Ｓ２６）。
【０２３５】
パケット受信部６０１が、パケットを受信しなかった場合（Ｓ２５でＮｏ）及び検出部２０２が、パケット損失につながる兆候を検出しなかった場合（Ｓ１５でＮｏ）は、何もせず、処理を終了する。
【０２３６】
なお、送信ノード８００が備える処理部のうち、パケット受信部６０１及びパケット損失予測部８０１、損失予測保持部６０７以外の処理は、図７Ａと同様である。
【０２３７】
以上のように、本実施の形態の受信ノード７００は、ＯＷＤを算出する。また、送信ノード８００は、受信ノード７００が算出したＯＷＤを蓄積し、蓄積したＯＷＤからパケット損失が生じる時刻を正確に推定できる。また、受信ノード７００は、パケット損失が発生する可能性が高い時刻には、ＦＥＣ冗長度を高める。これにより、パケット損失によるコンテンツデータの損失を防止することが可能となる。
【０２３８】
（変形例１）
次に、本実施の形態の変形例１について述べる。
【０２３９】
本変形例の送信ノード８００が備えるパケット損失予測部は、パケット損失が予測される損失時間区間を推定する。
【０２４０】
以下、本実施の形態の受信ノード７００が備えるパケット損失予測部８０１と異なる点を中心に述べる。
【０２４１】
図２１は、本変形例のパケット損失予測部８０２の詳細な構成を示すブロック図である。
【０２４２】
パケット損失予測部８０２は、パケット損失予測部８０１と比べて、損失時間区間推定部３０１をさらに備える点が異なる。損失時間区間推定部３０１は、推定部２０３が算出した損失推定時刻を基に損失推定時間区間を算出する。
【０２４３】
符号化レート／ＦＥＣ冗長度決定部６０２は、損失推定時間区間に送信するコンテンツデータに対してＦＥＣ冗長度を上げる。
【０２４４】
これにより、本変形例のストリーム通信装置は、パケット損失が発生する時刻を含む所定の時間を損失推定間区間として推定できる。よって、損失推定時間区間のいずれの時刻でも、パケット損失によるコンテンツデータの損失を防止することが可能となる。
【０２４５】
（変形例２）
次に、本実施の形態の変形例２について述べる。
【０２４６】
本変形例の受信ノード７００が備えるパケット損失予測部は、パケット損失が予測されるパケットのシーケンス番号を推定する。
【０２４７】
以下、本実施の形態の受信ノード７００が備えるパケット損失予測部１０６と異なる点を中心に述べる。
【０２４８】
図２２は、本変形例のパケット損失予測部８０３の詳細な構成を示すブロック部である。
【０２４９】
パケット損失予測部８０３は、パケット損失予測部８０１と比べて、損失シーケンス番号推定部４０２をさらに備える点が異なる。
【０２５０】
また、蓄積部４０１は蓄積部２０４と比べて、さらに受信したパケットに対応するシーケンス番号をシーケンス番号履歴として蓄積する点が異なる。
【０２５１】
損失シーケンス番号推定部４０２は、推定部２０３が推定した損失推定時刻と蓄積部４０１が保持するシーケンス番号履歴から、損失推定シーケンス番号を推定する。
【０２５２】
符号化レート／ＦＥＣ冗長度決定部６０２は、損失推定シーケンス番号に対応するパケットに対してＦＥＣ冗長度を上げる。
【０２５３】
これにより、本変形例のストリーム通信装置は、パケット損失が予測されるシーケンス番号に対応するパケットのコンテンツデータの損失を防止できる。
【０２５４】
（変形例３）
次に、本実施の形態の変形例３について述べる。
【０２５５】
本変形例の受信ノード７００が備えるパケット損失予測部は、パケット損失が予測される複数のパケットに含まれる損失推定シーケンス番号群を推定する。
【０２５６】
以下、本実施の形態の変形例１と異なる点を中心に述べる。
図２３は、本変形例のパケット損失予測部８０４の詳細な構成を示すブロック図である。
【０２５７】
パケット損失予測部８０４は、パケット損失予測部８０２と比べて、さらに、損失シーケンス番号推定部５０１を備える。
【０２５８】
損失シーケンス番号推定部５０１は、損失時間区間推定部３０１が推定した損失推定時間区間と、蓄積部４０１が保持するシーケンス番号履歴から、損失推定シーケンス番号群を推定する。
【０２５９】
レポート作成部５０２は、上記損失推定シーケンス番号群を含むレポートを作成する。
符号化レート／ＦＥＣ冗長度決定部６０２は、損失推定シーケンス番号群を含むパケットに対してＦＥＣ冗長度を上げる。
【０２６０】
これにより、本変形例のストリーム通信装置は、パケット損失が発生するパケットに対応するシーケンス番号を推定することで、パケット損失が発生するパケットを推定する。また、パケット損失が予測されるシーケンス番号に対応するパケットのコンテンツデータの損失を防止できる。
【０２６１】
（変形例４）
次に、本実施の形態の変形例４について述べる。
【０２６２】
本変形例の送信ノード８００が備えるパケット送信部６０６は、パケット損失予測部８０１によって推定された損失推定時刻に送信されるパケットを重複して送信する。
【０２６３】
これにより、本変形例のストリーム通信装置は、損失予測時刻にパケット損失が発生した場合、重複して送信されたコンテンツデータにより当該コンテンツデータを回復できる。
【０２６４】
なお、パケット送信部６０６は、損失推定時間区間に送信するパケットを重複して送信してもよい。
【０２６５】
また、パケット送信部６０６は、損失推定シーケンス番号、又は、損失推定シーケンス番号群に含まれるシーケンス番号に対応するパケットを重複して送信してもよい。
【０２６６】
以上、本発明の実施の形態及び変形例に基づいて説明したが、本発明は、この実施の形態及び変形例に限定されるものではない。本発明の趣旨を逸脱しない限り、当業者が思いつく各種変形を本実施の形態に施したものや、異なる実施の形態における構成要素を組み合わせて構築される形態も、本発明の範囲内に含まれる。
【０２６７】
また、本発明は、装置として実現できるだけでなく、その装置を構成する処理部をステップとする方法として実現したり、その装置を備えたシステムとして実現したりすることもできる。
【０２６８】
例えば、パケット損失が生じると推定されたパケット以外のパケットは、冗長データを全く含まなくてもよい。
【０２６９】
また、送信ノードは、予め定められた時間間隔でパケットを送信し、受信ノードも予め定められた時間間隔でパケットを受信してもよい。この場合、パケット損失予測部は、時刻履歴を用いず、ＯＷＤ履歴のみからパケット損失の生じる時刻又はパケットを推定してもよい。
【産業上の利用可能性】
【０２７０】
以上のように、本発明にかかるストリーム通信装置は、ストリームを小さく分割したパケットが送信されてから受信されるまでの時間である片方向伝送遅延の増加傾向を判断することで、パケット損失につながる兆候を検出した場合、片方向伝送遅延の増加の程度から、前記パケット損失が生じるパケットである損失推定パケットを推定する機能を有し、双方向通信のテレビ電話及びストリーム配信装置として有用である。
【図面の簡単な説明】
【０２７１】
【図１】実施の形態１のストリーム通信システムのシステム構成図である。
【図２】実施の形態１のストリーム通信装置の受信ノードの構成を示すブロック図である。
【図３】実施の形態１のストリーム通信装置のパケット損失予測部の詳細な構成を示すブロック図である。
【図４】１台のルータ上で輻輳が発生する場合のＯＷＤの変化を示す図である。
【図５】実施の形態１のストリーム通信装置の送信ノードの構成を示すブロック図である。
【図６】実施の形態１のストリーム通信装置の受信ノードの処理の流れを示すフローチャートである。
【図７Ａ】実施の形態１のストリーム通信装置の送信ノードの処理の流れを示すフローチャートである。
【図７Ｂ】実施の形態１のストリーム通信装置の送信ノードの処理の流れを示すフローチャートである。
【図８】実施の形態１のストリーム通信装置の冗長度制御処理の処理の具体的な一例を示すフローチャートである。
【図９】実施の形態１のストリーム通信装置の送信パケットに占める冗長データを示す図である。
【図１０】一時的なＯＷＤの増加を示すグラフである。
【図１１】実施の形態１のストリーム通信装置の推定部が保持するルータ毎のパケット損失発生時のＯＷＤを示す図である。
【図１２】実施の形態１の変形例１のストリーム通信装置のパケット損失予測部の詳細な構成を示すブロック図である。
【図１３】実施の形態１の変形例２のストリーム通信装置のパケット損失予測部の詳細な構成を示すブロック図である。
【図１４】実施の形態１の変形例３のストリーム通信装置のパケット損失予測部の詳細な構成を示すブロック図である。
【図１５】実施の形態１の変形例４のストリーム通信装置の送信ノードが備える処理部のうち、パケット受信部及び損失予測保持部以外の処理部での処理の流れを示すフローチャートである。
【図１６】実施の形態２のストリーム通信装置の受信ノードの構成を示すブロック図である。
【図１７】実施の形態２のストリーム通信装置の送信ノードの構成を示すブロック図である。
【図１８】実施の形態２のストリーム通信装置のパケット損失予測部の詳細な構成を示すブロック図である。
【図１９】実施の形態２のストリーム通信装置の受信ノードの処理の流れを示すフローチャートである。
【図２０】実施の形態２のストリーム通信装置の送信ノードが備えるパケット受信部及びパケット損失予測部、損失予測保持部の処理の流れを示すフローチャートである。
【図２１】実施の形態２の変形例１のストリーム通信装置のパケット損失予測部の詳細な構成を示すブロック図である。
【図２２】実施の形態２の変形例２のストリーム通信装置のパケット損失予測部の詳細な構成を示すブロック図である。
【図２３】実施の形態２の変形例３のストリーム通信装置のパケット損失予測部の詳細な構成を示すブロック図である。
【図２４】ルータ上で輻輳が発生する様子の一例を示す図である。
【図２５】ルータ上で輻輳が発生する様子のその他の一例を示す図である。
【図２６】ルータ上で輻輳が発生する様子のさらにその他の一例を示す図である。
【図２７】従来のストリーム通信装置の送信パケットに占める冗長データを示す図である。
【符号の説明】
【０２７２】
Ｔ０、Ｔ１、Ｔ２  時刻
１０１、６０１  パケット受信部
１０２  受信バッファ
１０３  コンテンツ復号化処理部
１０４  ＦＥＣ復号化処理部
１０５、６０６  パケット送信部
１０６、３００、４００、５００、８０１、８０２、８０３、８０４  パケット損失予測部
２０１  ＯＷＤ算出部
２０２  検出部
２０３  推定部
２０４、４０１  蓄積部
２０５、３０２、４０３、５０２  レポート作成部
３０１  損失時間区間推定部
４０２、５０１  損失シーケンス番号推定部
６０２  符号化レート／ＦＥＣ冗長度決定部
６０３  コンテンツ符号化処理部
６０４  ＦＥＣ符号化処理部
６０５  送信バッファ
６０７  損失予測保持部
６１０  制御部
７００、１６０４  受信ノード
７０１  ＯＷＤ算出部
８００、１６００  送信ノード
１３０４、１４０４  コンテンツデータ送信による消費帯域
１３０５、１４０５  冗長データ送信による消費帯域
１６０１、１７０１  ルータ
１６０２  ネットワーク
１６１０  ストリーム通信システム
１７０２  バッファ
１７０３、１８０３、１９０３  パケット
【図１】
2010016722.tif 000004
【図２】
2010016722.tif 000005
【図３】
2010016722.tif 000006
【図４】
2010016722.tif 000007
【図５】
2010016722.tif 000008
【図６】
2010016722.tif 000009
【図７Ａ】
2010016722.tif 000010
【図７Ｂ】
2010016722.tif 000011
【図８】
2010016722.tif 000012
【図９】
2010016722.tif 000013
【図１０】
2010016722.tif 000014
【図１１】
2010016722.tif 000015
【図１２】
2010016722.tif 000016
【図１３】
2010016722.tif 000017
【図１４】
2010016722.tif 000018
【図１５】
2010016722.tif 000019
【図１６】
2010016722.tif 000020
【図１７】
2010016722.tif 000021
【図１８】
2010016722.tif 000022
【図１９】
2010016722.tif 000023
【図２０】
2010016722.tif 000024
【図２１】
2010016722.tif 000025
【図２２】
2010016722.tif 000026
【図２３】
2010016722.tif 000027
【図２４】
2010016722.tif 000028
【図２５】
2010016722.tif 000029
【図２６】
2010016722.tif 000030
【図２７】
2010016722.tif 000031