JP4969342B2 - 受信端末及び受信方法 - Google Patents

Description

本発明は、映像や音声といった実時間性のあるデータを、ネットワークを介して送信する場合において、他の受信端末から損失パケットを受信して補完を行う受信端末及び受信方法に関する。

ライブ放送やテレビ会議では、映像や音声といった実時間性のあるデータを連続的に送信するストリーミングを、１対複数（ライブ放送）又は複数対複数（テレビ会議）で行う。

インターネットや企業学校内のイントラネットといったネットワークにおいて複数の受信端末に対してストリーミングを行うための配送方法としては、（１）１対１のユニキャスト通信を複数用いる方法、（２）ＩＰマルチキャストを用いる方法、（３）ＸＣＡＳＴを用いる方法が知られている。

（１）ユニキャスト通信を複数用いる方法では、送信端末が、パケットを複数の受信端末へ送信するため、送信端末の負荷が高まったり、送信端末に近いネットワークの回線の負荷を高めたりすることがある。

（２）ＩＰマルチキャストを用いる方法では、送信端末が送信したパケットは、ネットワーク上の中継装置であるルータが複数の受信端末に対してパケットを複製して転送する。このため、送信端末の負荷が高まったり、送信端末に近いネットワークの回線の負荷を高めたりしない。しかしながら、ＩＰマルチキャストパケットは、ユニキャストしか扱えないルータを通過できない。ＩＰマルチキャストを用いるためには、ネットワーク上のすべてのルータがＩＰマルチキャストに対応していなくてはならないため、ＩＰマルチキャストに対応したルータをネットワークに導入する必要がある。

（３）非特許文献１にはＸＣＡＳＴが開示されている。ＸＣＡＳＴを用いる方法では、送信端末が送信したＸＣＡＳＴパケットは、ＸＣＡＳＴ対応ルータでは、ＩＰマルチキャストと同じように複製転送される。また、ＸＣＡＳＴパケットは、ＸＣＡＳＴ非対応ルータでも、ユニキャストパケットと同様に未配送の一つの宛先に転送される。ＸＣＡＳＴパケットには、送信する複数の宛先アドレスがすべて列挙されている。ＸＣＡＳＴパケットには、未配送の宛先が記載されている。受信端末は、未配送の宛先に対してＸＣＡＳＴパケットを送信する。このように動作するＸＣＡＳＴを用いた場合、送信端末の負荷が高まることはなく、送信端末に近いネットワークの回線の負荷を高めることもない。しかしながら、本方法では、複数の宛先アドレスをすべてパケット中に列挙する必要があるため、受信端末の数が多い場合の配送には適していない。

このように、複数の受信端末に対してストリーミングを行う場合、（１）１対１のユニキャスト通信を複数用いる方法、（２）ＩＰマルチキャストを用いる方法、（３）ＸＣＡＳＴを用いる方法のいずれかの方法を用いて複数の受信端末に対するストリーミングを実現することができる。

ネットワークでは、他の通信のパケットとの競合等により、送信中にパケットが損失することがある。パケット損失を補完する方法として、同一パケットを送信端末から再送する方法がある。ここで、再送とは、パケット損失を検知した受信端末が、送信端末に対して、損失したパケットの再送要求を送信することを意味する。送信端末は、受信した送信要求に応じたパケットを受信端末へ再送信する。受信端末は、再送信されたパケットを受信し、損失したパケットを補完する。

しかし、複数の受信端末に対してストリーミングを行う場合に、この再送処理が行なわれると、複数の受信端末が同時に再送要求を送信し、送信端末に再送要求が集中するため、送信端末の負荷が高まったり、送信端末付近のネットワークの回線の負荷を高めたりする。

特許文献１記載の技術では、このような問題を解決するため、受信端末の上流に位置する情報配信装置が再送要求を受け取ったときに、他の受信端末からの再送要求の送信を抑止するための情報を受信端末に同報通知する。受信端末は、再送要求を送信するタイミングに達する前にこの情報を受け取った場合、再送要求を送信しない。

このように動作することで、複数の受信端末からの再送要求の送信が抑止されるため、送信端末の負荷を高めたり、送信端末付近のネットワークの回線の負荷を高めたりすることはない。しかし、本方式は、同報通信が使えないネットワークでは利用できない。

また、ストリーミングにおいては、実時間性が重要となる。つまり、受信端末は、受け取った映像、音声などのデータを一定時間以内に再生する必要がある。

特許文献２は、複数の受信端末が連携して再送を行う場合に、互いに再送要求を抑止する動作を行うため、ストリーミングの再生時刻を考慮した再送要求送信タイミングを算出する方法を提示している。

すなわち、ＩＰマルチキャストを用いてストリーミング及び再送要求及び再送を行う場合、損失したパケットの再送要求を必ずしも送信端末に送信する必要がない。つまり、再送要求をＩＰマルチキャストで送信することで、他の受信端末に再送要求を送信することができ、他の受信端末が再送を行うことができる。このとき、受信端末は、再送要求の送信タイミングを乱数時間遅らせる。早いタイミングにＩＰマルチキャストで送信された再送要求に対する応答を他の受信端末から受信した受信端末は、同じ再送要求を送信しない。このように動作することで、全体として再送要求の送信が抑止されるので、複数の受信端末からの再送要求が送信端末に集中する問題は発生しない。

そこで、特許文献２は、この方式に対して、再生時刻を考慮して、再送要求の送信タイミングを遅らせる時間を調整する方法を提案している。特許文献２の方式を用いることで、すべての受信端末が長い時間、再送要求の送信タイミングを遅らせてしまうことによって、再生時刻に再送パケットが間に合わないという問題の発生確率を下げることができる。しかしながら、これらの方式はＩＰマルチキャストを前提とした方式であり、ＩＰマルチキャストが利用できないネットワークでは用いることができない。

一方、非特許文献２は、ストリーミングを行う際に、送信端末と受信端末の間の利用可能な帯域を推定する方式として、ＴＦＲＣ（TCP Friendly Rate Control）を開示する。ＴＦＲＣでは、送信端末と受信端末の間の往復時間（ＲＴＴ：Round Trip Time）と損失イベント率から、利用可能な帯域を推定する。ストリーミングにおいて、ＴＦＲＣが算出する利用可能な帯域にあわせて、データを送信するとパケットが損失する確率を抑えた通信が可能となる。しかしながら、ＴＦＲＣを用いてデータを送信しているストリーミングに対して、再送を適用した場合、再送要求や再送パケットを送信することで帯域を消費してしまう。このためパケットが損失する確率が高くなってしまう問題がある。この問題は、複数の受信端末に対してストリーミングを行う場合、より大きくなる。また、再送要求や再送パケットが損失することに備えて、複数の受信端末に対して再送要求を行うことが可能である。しかし、この場合、再送要求の集中によって受信端末の近くのネットワーク負荷が高まり、再送要求が損失する問題があった。
特開２００２−１２４９３５号公報 特開２００３−２０９５７６号公報 Y. Imai, M. Shin and Y. Kim, "XCAST6: eXplictMulticast on IPv6", IEEE/IPSJ SAINT2003 Workshop 4, IPv6 and Applications, Orland, Jan. 2003. M. Handley et al., "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 3448、インターネット＜ＵＲＬ：http://www.faqs.org/rfcs/rfc3448.html＞

すなわち、上記した従来の技術では、ＩＰマルチキャストが使えない環境においては、複数の受信端末への再送要求を行う場合、ユニキャストで複数の再送要求を繰り返し送信する必要がある。そのため、複数の再送要求が集中することによる受信端末付近のネットワークの回線の負荷が高まり、結果として再送要求が欠落するので、再送によって損失パケットを補完できる確率が低下するという課題があった。

本発明は、かかる点に鑑みてなされたものであり、他の複数の受信端末に対して再送要求を行う場合に、受信端末付近のネットワーク回線の負荷が集中することを防ぎ、再送パケットにより損失パケットを補完できる確率を高めることができる受信端末及び受信方法を提供することを目的とする。

本発明の受信端末は、ネットワーク上で損失した損失パケットを補完するために再送要求を送信する受信端末であって、前記受信端末と他の複数の受信端末との間のネットワーク上の距離に対応する時間を計測する計測手段と、再送されるパケットが再生される再生時刻から現在時刻と前記計測手段によって計測された時間によって求められる余裕時間を前記受信端末毎に算出する算出手段と、算出された余裕時間に基づいて、再送要求の送信タイミングおよび再送要求の送信先を決定する決定手段と、を具備する構成を採る。

本発明によれば、他の複数の受信端末に対して再送要求を行う場合に、受信端末付近のネットワークの負荷が集中するのを防ぎ、再送要求の欠落を防止し、損失パケットによる補完できる確率を高めることができる。

以下、本発明の実施の形態について、図面を参照して説明する。

（実施の形態１）
図１は、本発明の実施の形態１に係る受信端末がネットワーク上に配置された構成例を示す概略図である。図１は、複数の受信端末がネットワーク上に配置され、運用されている様子を示している。図１において、１０１は送信端末、１０２ａ〜１０２ｅはそれぞれ受信端末、１０７はネットワークを示している。ネットワーク１０７は複数の中継装置（ルータ）により構成されている。

送信端末１０１は、受信端末１０２ａ〜１０２ｅに対して、ネットワーク１０７を介して映像送信を行う。送信端末１０１は、１対１のユニキャスト通信を複数用いて、映像を受信端末１０２ａ〜１０２ｅに配信する。受信端末１０２ａ〜１０２ｅには、予め他の受信端末が同一の映像配信に参加していることが通知されている。通知方法としては、次の方法がある。始めに、それぞれの受信端末がサービスを受けることを登録（サブスクライブ）する際に、映像配信サービスへの加入を管理するサーバ（図示せず）に受信端末のＩＰアドレスを登録する。次に、サーバが、映像配信の開始示時に複数の受信端末のＩＰアドレスをそれぞれの受信端末に通知する。

送信端末１０１が１対１のユニキャスト通信により複数の受信端末１０２ａ〜１０２ｅに映像を配信する場合に、ネットワーク１０７上で、受信端末１０２ａ〜１０２ｅに対するパケットが損失すると、受信端末１０２ａ〜１０２ｅは、パケット中に記載されているシーケンシャル番号の隔たりでパケット損失を検知する。

また、映像を配信する場合、ネットワーク送信時間に揺らぎ（ジッタ）が発生することがあるため、受信端末１０２では、この揺らぎを吸収するためのバッファが設けられている。受信端末１０２は、受信した映像のデータを一定時間バッファリングする。受信端末１０２は、このバッファリングされている間に損失したパケットを再送受信できれば映像の再生に間に合うため、乱れなく映像を再生できる。この受信処理及び再生処理を、図２を用いて説明する。

図２は、送信端末１０１及び受信端末１０２間の映像の送信フローを示す図である。図２において、４０１は送信端末１０１の時間軸、４０２は受信端末１０２中の受信バッファの時間軸、４０３は受信端末１０２中で映像を再生する再生部の時間軸を表している。図２では、軸の上方から下方に向けて時間が経過している。尚、パケットＰ１〜Ｐ４が一つのピクチャを構成する。また、パケットＰ５〜Ｐ８が次のピクチャを構成している。ここで、一つのピクチャが複数のパケットに分割されて送信されている。時刻ｔ１は受信バッファにパケットＰ４が到着した時刻を示す。受信端末１０２は時刻ｔ１でパケットＰ３の損失を検知する。時刻ｔ２はパケットＰ３が受信バッファに到着した時刻を示す。時刻ｔ３はパケットＰ３の再送パケットが受信バッファに到着すべき時刻であるパケットＰ３の再生時刻（再生タイミング）を示す。時刻ｔ４はパケットＰ４の再生時刻を示す。つまり、図２は、映像配信に対して、受信端末１０２が、（時刻ｔ４−時刻ｔ１）の時間だけ、ジッタ吸収のためのバッファリングを行っていることを示している。また、受信端末１０２では、パケットＰ３の損失を検知した時刻ｔ１においては、パケットＰ３の再生を開始するまでの時刻t３まで、時間の余裕（時刻ｔ３−時刻ｔ１）がある。ここで、パケットＰ３の再生時刻（時刻ｔ３）からパケットＰ３が再送される時刻ｔ２を引いた時間（時刻ｔ３−時刻ｔ２）を、「余裕時間」と呼ぶ。この余裕時間（時刻ｔ３−時刻ｔ２）の範囲内でパケットＰ３の再送が間に合えば、受信端末１０２は、パケットＰ１〜Ｐ４で構成されるピクチャを乱れることなく再生できる。

ここで、映像配信において、送信される映像データの構造を、図３を用いて説明する。

図３において、Ｉ、Ｐは、それぞれＭＰＥＧ４のＩピクチャ、Ｐピクチャを示している（１画面の画像のことをピクチャと呼ぶ）。Ｉピクチャは、他のピクチャに依存関係がないピクチャで、Ｉピクチャの画像データのみで１画面を再生することができる。しかし、Ｉピクチャの画像データは、データ量が多い。Ｐピクチャは、前の再生画像（Ｉピクチャ）との差分をエンコードしたものであり、前の再生画像がなければ、デコードできない。しかし、Ｐピクチャは、Ｉピクチャとの差分のみの画像データをエンコードしてあるため、データ量が少ない。図３は、１画面分のＩピクチャの後に２画面分のＰピクチャが続くという構造で、映像が配信されることを示している。

このような構成で映像を送信しているときに、Ｉピクチャを構成するパケットが損失した場合、その損失は、Ｉピクチャの再生のみならず、後続する２つのＰピクチャの再生に影響する。すなわち、Ｉピクチャを構成するパケットが損失した場合、損失パケットの再送を優先的に成功させ、後続する２つのＰピクチャの再生の乱れを防止することが望ましい。また、ＭＰＥＧ４では、一つの映像を複数の映像コンテンツに分けてエンコードし、再生する場合に、それらを組み合わせて再生させることができる。例えば、天気予報の番組において、背景画像として天気図の画像をエンコードし、天気図の説明をする解説員の画像を別の画像としてエンコードして、双方を利用して一つの映像として再生することが可能となる。このような映像の配信においては、天気図の画像を配信する際に発生したパケット損失を優先的に回復することが望ましい。

受信端末１０２は、Ｉピクチャや天気図の画像のように重要度が高いパケットが損失した場合、重要でないパケットよりも優先的に再送要求（再送要求パケット）を送信する。このとき、受信端末１０２は、再送要求がネットワーク上で損失してしまうと、損失パケットの再送が成功しないため、再生する画像が乱れてしまう。これを防止するために、受信端末１０２は、複数の再送要求を送信することが望まれる。しかし、受信端末１０２が、複数の再送要求を同時に送信すると、ネットワークの負荷が増大し再送要求が損失してしまう可能性が高まる。そこで、受信端末１０２は、複数の再送要求を同時ではなく時間的に分散させて複数の再送要求先へ順次送信するように構成されている。

図４は、受信端末１０２ａ〜１０２ｅの構成例を示す図である。図４において、１０２は受信端末、２０２は受信端末１０２における受信スタック、２０３は受信バッファ、２０４は再送要求先／再送要求時刻決定部、２０５は再送要求送信部、２０６は受信部、２０７は計測部、２０８は再生部を示す。受信部２０６は正常に受信した映像配信のパケットを受信バッファ２０３に引き渡す。

受信バッファ２０３は、再生時刻になると、ピクチャ単位又はパケット単位で、映像データを再生部２０８に引き渡す。再生部２０８は、映像をデコードするデコーダと映像を再生するディスプレイを備えている。再生部２０８は、ピクチャ単位又はパケット単位でデータをデコードし、画像をディスプレイに表示する。

計測部２０７は、受信端末間のネットワーク上の距離に対応する時間（ＲＴＴ：Round Trip Time）を計測する。ＲＴＴは、受信端末間のネットワーク上の往復時間に相当する。例えば、具体的には、受信端末１０２ａが送信タイムスタンプを計測パケットに刻印して他の受信端末１０２ｂ〜１０２ｅに送信する。他の受信端末１０２ｂ〜１０２ｅは、受信した計測パケットの送信タイムスタンプをピギーバック処理して、受信端末１０２ａにそれぞれ返送する。この処理により、受信端末１０２は、複数の受信端末間の距離に応じた時間（ＲＴＴ）を計測することができる。計測部２０７は、計測した受信端末間の距離に応じた時間（ＲＴＴ）を再送要求先／再送要求時刻決定部２０４に通知する。この計測及び通知は、映像配信の開始時に行ってもよいし、映像配信の途中に繰り返し行ってもよい。また、計測部２０７は、複数の計測時間の平均を再送要求先／再送要求時刻決定部２０４に通知してもよい。計測部２０７は、過去の計測時間を加重平均したものを再送要求先／再送要求時刻決定部２０４に通知してもよい。また、計測部２０７は、各受信端末にパケットを送信する際に経由する一段上流のルータのアドレスを特定し、再送要求先／再送要求時刻決定部２０４に通知する機能を有する。

受信部２０６は、映像のパケットを受信し、（１）受信バッファ２０３に格納する機能、（２）シーケンシャル番号の隔たりで損失を検知する機能、（３）再送パケットを受信し、受信バッファにシーケンシャル番号順に格納する機能を有する。また、受信部２０６は、パケット損失を検知した場合、再送要求先／再送要求時刻決定部２０４にパケット損失を示すイベントを再送要求イベントとして通知する。このとき、受信部２０６は、損失したパケットのシーケンシャル番号、再生時刻、及び重要度を再送要求先／再送要求時刻決定部２０４に通知する。重要度は、受信データを元に予め設定された表を参照することで判定される。

図５は、本実施の形態における再送要求すべきパケット、すなわち損失したパケットの重要度を示す重要度判定表の１例である。具体的には、６０１はパケットタイプ欄、６０２は重要度欄を示す。受信部２０６は、パケット中の特定項目であるパケットタイプをキーとして検索し、パケットの重要度を得る。受信部２０６は、この重要度を再送要求先／再送要求時刻決定部２０４に通知する。再送要求先／再送要求時刻決定部２０４は、重要度を参照して再送要求の送信先を判定する。パケットタイプは、ＲＴＰ（Real-time Transport Protocol）のパケットタイプを参照することにより得る。例えば、パケットタイプは、ピクチャの種類（Ｉ、Ｐ）等を示す。尚、パケットの重要度を得るためには、パケットタイプを参照することのみに限定されない。具体的には、Ｉピクチャかどうかを判定するには、パケットタイプだけではなく、ＲＴＰパケットのペイロードにあるスライスヘッダを参照する。即ち、重要度を付与する対象に適切な重要度判定表を予め作成すればよい。

図６は、文献ＲＦＣ３５５０"RTP: A Transport Protocol for Real-Time Applications"に記載のＲＴＰヘッダを示す。５０１は、ＲＴＰのパケットタイプ（ＰＴ）を示す。映像配信では、このＲＴＰヘッダをパケット中に含めて映像データが送信されている。このとき、受信部２０６は、ＲＴＰのパケットタイプ５０１及び重要度判定表６００を参照して重要度を判定する機能（判定手段）を有する。なお、受信部２０６は、重要度を判定する際に、ＵＤＰポート番号やＳＳＲＣ、マーカービットの有無を用いるように構成してもよい。特に、再送要求先／再送要求時刻決定部２０４は、パケットのパケットタイプ（種類）に応じた重要度を判定する。

また、受信部２０６は、再生時刻として、再生時刻を正確に通知してもよいし、受信部２０６で予測できるパケット到着のジッタ分を再生時刻から引いたものを通知してもよい。

再送要求先／再送要求時刻決定部２０４（算出手段、決定手段）は、損失したパケットが再生される再生時刻から現在時刻と往復時間（ＲＴＴ）とを差し引いて求められる余裕時間を端末毎に算出する。次に、再送要求先／再送要求時刻決定部２０４は、算出された余裕時間に基づいて、再送要求の送信タイミングおよび再送要求の再送要求先（送信先）である受信端末とを決定する。そして、再送要求送信部２０５は、少なくとも一つの受信端末に少なくとも一つの再送要求を送信する。再送要求先／再送要求時刻決定部２０４は、受信部２０６から通知された再送要求イベントから、損失したパケットのシーケンシャル番号、再生時刻、及び重要度を得る。

図７は、再送要求先／再送要求時刻決定部２０４が再送要求先及び再送要求時刻を決定するための動作フローを示す。

ステップ１０００では、再送要求先／再送要求時刻決定部２０４が、計測部２０７から映像配信の開始時又は映像配信中に受信端末と複数の受信端末間の往復時間（ＲＴＴ）を取得する。

ステップ１００１では、再送要求先／再送要求時刻決定部２０４は、再生要求イベントを受信部２０６から受信する際に、受信部２０６から損失パケット（再送されるパケット）の再生時刻及び重要度が通知される。例えば、受信部２０６は、損失パケットがＩフレームの場合重要度が高いため、３段階のうち重要度３を再送要求先／再送要求時刻決定部２０４に通知する。

ステップ１００２では、再送要求先／再送要求時刻決定部２０４が、損失したパケットが再生される再生時刻から現在時刻と往復時間（ＲＴＴ）とを差し引いて求まる余裕時間を求める。言い換えると、余裕時間とは、次の式、
余裕時間＝（再生時刻を示す時間）−（現在時間）−（端末間の距離に対応する時間（ＲＴＴ））
で計算される時間であり、現在時間から再送要求を送信するまでの時間を表す。

ステップ１００３では、再送要求先／再送要求時刻決定部２０４が、全ての再送要求先Ｒｉ（ｉ＝１〜ｎ：ｎは整数）について余裕時間の計算が完了したかを判定する。全ての再送要求先について、余裕時間の計算が完了していない場合（ＮＯ）はステップ１００２に戻り、余裕時間の計算が完了している場合（ＹＥＳ）はステップ１００４に進む。

ステップ１００４では、再送要求先／再送要求時刻決定部２０４が、再送要求先を決定するためのアルゴリズムを重要度に応じて決定する。アルゴリズムは、余裕時間の順番（昇順又は降順）に従って、送信タイミング（再送要求時刻）及び再送要求先を決定する。再送要求先／再送要求時刻決定部２０４は、損失パケットの重要度が高い場合、余裕時間の昇順に従って送信タイミング（再送要求時刻）及び再送要求先を決定する。尚、アルゴリズムを重要度に応じて決定せずに特定のアルゴリズムを用いてもよい。

ステップ１００５では、再送要求先／再送要求時刻決定部２０４が、決定されたアルゴリズムに基づき再送要求の送信タイミング（再送要求時刻）及び再送要求先を決定する。ここで、再送要求先／再送要求時刻決定部２０４は、余裕時間をそのまま送信タイミングとして決定する。また、再送要求先／再送要求時刻決定部２０４は、余裕時間から適切な数値を減算して送信タイミングを算出してもよい。重要度が高い場合には、少なくとも２以上再送要求先の端末に対して再送要求を送信できるように再送要求先および送信タイミングを決定することが望ましい。

ステップ１００６では、再送要求先／再送要求時刻決定部２０４が、損失パケットのシーケンシャル番号及び再送要求先を用いて送信要求を生成する。

ステップ１００７では、再送要求先／再送要求時刻決定部２０４が、再送要求先毎に再送要求時刻を再送タイマに設定する。

再送要求送信部１２０５は、再送要求時刻になると再送要求を再送要求先に順次送信する。

図８及び図９を参照して、再送要求時刻をタイマに設定する手順（アルゴリズム）を詳細に説明する。ここでは、受信端末１１０３が再送要求を送信する例で説明する。

図８は、受信端末１１０３が再送要求を送信するときの再送要求先及び再送要求時刻を決定するためのアルゴリズムを説明するための図である。図８の７００は、受信端末１１０３の再送要求先である受信端末毎の余裕時間及び第一ルータの関係を示す経路表である。７０１は余裕時間欄、７０２は再送要求先である受信端末を示す欄、７０３は受信端末１１０３が接続されている第一ルータとの関係を示す欄である。７０７、７０８は、それぞれ再送要求先の決定アルゴリズムにより決定された順番の例Ａ１、Ａ２を示している。

図９は、図８で示す経路表に対応した受信端末の状態を説明するための図である。図９の１１０１〜１１０８は、それぞれ受信端末を示す。図９の１１０９〜１１１２は、ルータをそれぞれ示す。各受信端末は、ルータを介して接続されている。

図８の７０４〜７０６は、グループ化された再送要求先である複数の受信端末からなるグループをそれぞれ示している。例えば、グループは、余裕時間の昇順又は降順に所定数の受信端末毎にグループ化する。ここでは、６つの受信端末を２つの受信端末毎にグループ化している。

端末１１０３の一段上流の第一ルータのアドレスは、インターネットで特定端末間の経路を計測する手法であるトレースルート（traceroute）を用いて特定される。あるいは、一段上流の第一ルータのアドレスは、受信端末が保有している相手先毎の経路表に記載されている次ホップルータを参照することで取得することができる。例えば、この経路表は、受信端末１１０３のオペレーティングシステムがWindowsXP（登録商標）やLinux（登録商標）の場合、netstat -rnコマンドでディスプレイ上に表示されるネットワークに関する情報から構成される。つまり、経路表は、受信端末がパケットをどの相手先（ルータ）に対して送信すれば、最終的に宛先に届くかを示す情報を記述した表である。

先に述べたステップ１００２において再送要求先／再送要求時刻決定部２０４は、余裕時間の計算により、経路表７００に示す余裕時間欄７０１の計算を完了する。まず、受信部２０６は、重要度に基づいて再送要求先の数ｎを決定する。ここで、一例として、再送要求先の数ｎ＝３、つまり、３つの再送要求先に対して再送要求を送信することが決定されたとして説明する。次に、再送要求先／再送要求時刻決定部２０４は、再送要求先を決定する。

まず、「アルゴリズム１」では、再送要求先／再送要求時刻決定部２０４が再送要求先である複数の受信端末をｎ個のグループに分割する。分割のアルゴリズムとしては、余裕時間の昇順に再送要求先を並べ直し、これに基づき、昇順又は降順に分割していく。即ち、再送要求先／再送要求時刻決定部２０４は、余裕時間の順番に複数の受信端末を複数のグループに分割する。

図８における７０４〜７０６は、このアルゴリズムに従って、グループ化された再送要求先のグループである。次に、再送要求先／再送要求時刻決定部２０４は、各グループにおいて余裕時間の大きいものを再送要求先の受信端末（Ｉ〜ＩＩＩ）として決定する。再送要求先／再送要求時刻決定部２０４は、余裕時間の順番に従って、再送要求の送信タイミング及び再送要求の再送要求先である受信端末を決定する。図８の例では、再送要求先である受信端末として、受信端末１１０５，１１０７，１１０４が決定されたことを示している。

図８における７０７は、再送要求先の決定例Ａ１を示す。Ａ１は、この「アルゴリズム１」に従って決定された再送要求先を示している。このようにして、再送要求先／再送要求時刻決定部２０４は、決定された再送要求先の受信端末それぞれに対して、余裕時間内又は余裕時間後に再送要求を送信するようにタイマを設定する。このとき、設定するタイミングを余裕時間そのまま適用してもよいし、再送パケットが再送要求を送信した受信端末に集中して届くことを防ぐため、余裕時間から乱数時間分引いたタイミングでスケジュールしてもよい。乱数時間の最大値としては、例えば、余裕時間の１０％程度を採用してもよいし、再送要求を送信した受信端末の上流のネットワークの帯域Ｗが予め分かっている場合は、このＷ（ｂｙｔｅ／ｓｅｃ）と再送要求先の数ｎと再送パケットのサイズＳ（ｂｙｔｅ）を用いて式「ｎ＊ｓ／Ｗ」を用いて計算してもよい。また、各グループの中から余裕時間の少ないものを再送要求先として選定してもよい。

次に、「アルゴリズム２」による再送要求先及び再送要求時刻を決定するためのアルゴリズムを説明する。「アルゴリズム２」では、余裕時間の少ないものからｎ個の受信端末（Ａ２のＩ〜ＩＩＩ）を再送要求先として決定する。即ち、再送要求先／再送要求時刻決定部２０４は、余裕時間の昇順に再送要求の再送要求先である受信端末１１０１，１１０４，１１０８を決定する。「アルゴリズム２」は、損失パケットの重要度が高い場合に選択されるアルゴリズムである。再送要求先／再送要求時刻決定部２０４は、重要度が規定の値（例えば、図５の「３」）以上に高いとき、余裕時間の昇順に再送要求の送信先である受信端末を決定する。決定された再送要求先の受信端末それぞれに対して、余裕時間内又は余裕時間後に再送要求を送信するようにタイマに設定する方法は、「アルゴリズム１」で決定した再送要求先の受信端末に対するものと同様である。「アルゴリズム２」の利点は、再送要求がすべて失敗した場合でも、再度再送要求をスケジュールできることである。例えば、再送要求先の決定例Ａ２の最後の再送要求は余裕時間「１００」後に受信端末１１０８へ送信される。「１００」の時間単位は限定されるものではないが、ミリ秒、すなわち１００ミリ秒後としてよい。さらに受信端末１１０８との距離に対応する時間が経過した後に再送パケットが送信されてこない場合、ｎ個すべての再送要求が失敗した可能性がある。この場合、再送要求先／再送要求時刻決定部２０４は、余裕時間７０１を、現在時刻を用いて再計算する（ステップ１００２、１００３）。再送要求先／再送要求時刻決定部２０４は、再度、再送要求先の決定及び再送要求の送信を実行する。

次に、「アルゴリズム３」による再送要求先及び再送要求時刻を決定するためのアルゴリズムを説明する。「アルゴリズム３」では、第一ルータが異なり、かつ余裕時間の小さいものから順にｎ個を再送要求先として決定する。受信端末１１０３の第一ルータは、ルータ１１０９とルータ１１１０である。「アルゴリズム３」では、再送要求先／再送要求時刻決定部２０４が再送要求先を決定する際に、第一ルータ欄７０３を用いて、まず、第一ルータ毎に受信端末を分類してから、再送要求先を決定する。図８の例で説明すると、ルータ１１０９を第一ルータとするグループ（受信端末１１０４、１１０７、１１０５）から、余裕時間の最も小さい受信端末１１０４を第１の再送要求先として決定する。次に、再送要求先／再送要求時刻決定部２０４は、ルータ１１１０を第一ルータとするグループ（受信端末１１０１、１１０８、１１０２）から２番目に余裕時間が小さい１１０７を第２の再送要求先として決定する。次に、再送要求先／再送要求時刻決定部２０４は、ルータ１１０９を第一ルータとするグループ（受信端末１１０４、１１０７、１１０５）から、余裕時間の３番目に小さい受信端末１１０５を第３の再送要求先として決定する。決定された再送要求先の受信端末それぞれに対して、余裕時間内又は余裕時間後に再送要求を送信するようにタイマに設定する方法は、「アルゴリズム１」で決定した再送要求先の受信端末に対するものと同様である。

このように、本実施の形態によれば、再送要求先を決定し、再送要求をタイマに設定しスケジュールするため、ネットワーク上の再送要求による負荷が高まることを防止することができ、結果として、再送要求が欠落する可能性を低減することが可能となる。これにより、高品質な映像配信を行うことができる。

なお、本実施の形態では、再送要求の送信方法として、ユニキャストを用いる方法を述べてきたが、複数の再送要求先を一つのＸＣＡＳＴパケットの宛先リストに記載して、タイマにスケジュールしてもよい。このとき、再送要求先／再送要求時刻決定部２０４は、再送要求時刻を、最も余裕時間の少ないものにあわせて設定してもよいし、ＸＣＡＳＴパケットが数珠繋ぎ的に受信端末間を送信する時間を見込んだ時間に設定してもよい。ＸＣＡＳＴパケットが数珠繋ぎ的に受信端末間を送信する時間は、具体的には、再送要求先の候補の中から、受信端末間の往復時間を最大のものをｍ倍したものを用いてもよい。また、それぞれの受信端末間の往復時間を予め計測し、この情報を受信端末間で共有しておき、数珠繋ぎ的に受信端末間を転送されるそれぞれの往復時間を足したものを用いてもよい。

また、同様に再送要求をアプリケーションレベルマルチキャストにより送信してもよい。

ＸＣＡＳＴパケットやアプリケーションレベルマルチキャストを用いることで、受信端末付近のネットワークの負荷をさらに削減することができ、結果として再送要求が損失する可能性が減る。これにより、高品質な映像配信を行うことができるようになる。

（実施の形態２）
本実施の形態における受信端末は、他の受信端末との間で利用可能な帯域を時々刻々と推定し、利用可能な帯域に余裕が生まれた時点で再送要求を行う点が、実施の形態１と異なる。

図１０は、本発明の実施の形態２に係る受信端末がネットワーク上に配置された構成例を示す概略図である。図１０は、本実施の形態に係る受信端末がネットワーク上に配置され、運用されている様子を示している。図１０において、８０１〜８０４は受信端末であり、８０５〜８０７はネットワークを構成するルータである。８０８は時刻ｔ1に受信端末８０３が観測、推定した帯域と往復時間（ＲＴＴ）である。

受信端末８０１〜８０４は、互いに、映像音声のストリーミングを双方向で送信しながら、テレビ会議を行っている。受信端末８０１と受信端末８０２との間は、ルータを介さず直接通信している。具体的には、無線ＬＡＮやｂｌｕｅｔｏｏｔｈ（登録商標）などの無線接続を用いて通信する方法がある。これとは別に受信端末８０１、受信端末８０２は、それぞれルータ８０５、ルータ８０６に接続されている。また、受信端末８０３、受信端末８０４は、それぞれルータ８０７、ルータ８０６に、それぞれ接続されている。

受信端末８０１〜８０４は、映像音声のデータを、ユニキャストを用いて、それぞれの相手先受信端末に送信する際に、ＴＦＲＣを用いて利用可能な帯域を推定している。

受信端末８０１から受信端末８０３宛ての映像のストリーミングのパケットが損失した場合、受信端末８０３は、実施の形態１で説明した方法を用いて、再送要求先を決定し、再送要求を送信する。ここで、受信端末８０３の再送要求先／再送要求時刻決定部２０４は、余裕時間だけでなく、帯域の空き状況を考慮しながら再送要求を送信するタイミングを設定する。

図１１は、ＴＦＲＣを用いて利用可能な帯域を推定する帯域推定部を有する受信端末の構成例を示す図である。図１１の受信端末１２０１は、図４の受信端末１０２に帯域推定部１２０９を付加して構成される。図１１で１２０２〜１２０８で示す構成要素は、それぞれ図４の２０２〜２０８で示す構成要素と同じである。
帯域推定部１２０９は、受信端末１２０１が他の受信端末に対して送信するストリームの送信状況に関するフィードバックを受信し、利用可能な帯域を推定する機能を有する。具体的には、帯域推定部１２０９は、非特許文献２に記載されたＴＦＲＣのアルゴリズムを用いて、損失イベント率と受信端末間の往復時間（ＲＴＴ）から、帯域を推定する機能を有する。帯域推定部１２０９は、時々刻々と帯域を推定し、推定した帯域を再送要求先／再送要求時刻決定部１２０４に通知する。

図１２は、受信端末８０３が再送要求を送信する再送要求時刻とこのＴＦＲＣを用いて推定した帯域と映像配信に利用している帯域とを示す図である。図１２で９０１は、受信端末８０３がＴＦＲＣを用いて推定した帯域の時間推移を示す。９０２は、受信端末８０３が映像配信に利用している帯域を示す。時刻ｔ１は、受信端末８０３がパケットの損失を検知した時刻である。時刻ｔ２は、損失パケット係る映像の再生時刻、時刻ｔ３〜時刻ｔ５はそれぞれ、受信端末８０４、受信端末８０２、受信端末８０１との間の往復時間分を再生時刻から引いた時刻を示している。時刻ｔ６、時刻ｔ７は、送信候補時刻である。時刻ｔ６は、空き帯域発生時刻である。受信端末８０４、受信端末８０２、受信端末８０１の余裕時間は、それぞれ、時刻ｔ３−時刻ｔ１、時刻ｔ４−時刻ｔ１、時刻ｔ５−時刻ｔ１となる。実施の形態１に記載した「アルゴリズム１」で再送要求の送信タイミングを決定した場合、受信端末８０１への送信時刻は、時刻ｔ５となる。しかし、本実施の形態２で説明する「アルゴリズム４」では、受信端末８０１への再送要求を送信候補時刻ｔ７で送信する。

つまり、「アルゴリズム４」では、再送要求先／再送要求時刻決定部１２０４が「アルゴリズム１」での再送要求の送信タイミングに達するまでの間に、再送要求を送信するために帯域に十分な空きが生じた時点である時刻ｔ７に再送要求を送信する。具体的には、最も早い時間に再送要求を送信する必要がある順番に、以下の２つの条件が満たされたタイミングで再送要求を送信する。
条件１．帯域推定部１２０９が、推定帯域９０１が送信に利用する利用帯域９０２を所定量α上回った時刻Ｔ（図１２のｔ６）を再送要求先／再送要求時刻決定部１２０４に記録する。
条件２．再送要求先／再送要求時刻決定部１２０４が時刻Ｔ（図１２のｔ６）から時間（Ｓ／α）経過する間、推定帯域９０１が常に、送信に利用する利用帯域９０２を超えていることを判定する（ただし、Ｓは、再送要求のパケットサイズ）。

上記２つの条件が最初に満たされたタイミング（Ｔ＋（Ｓ／α））を再送要求の送信をする再送要求時刻（図１２のｔ７）とする。再送要求先／再送要求時刻決定部１２０４は、再送要求を一旦送信するとその時刻を再度時刻Ｔと記録し直して、次の再送要求の送信タイミングを上記２つの条件が満たされるタイミングに設定する。即ち、帯域推定部１２０９により推定された帯域が、受信端末が送信に利用している帯域を所定時間超える時刻を、再送要求の送信タイミングと決定する。

なお、αの値としては、１往復時間に１つの再送要求を送信するのに必要な帯域を適用してよい。すなわち、再送要求先／再送要求時刻決定部１２０４は、再送要求を送信する相手先との間と自端末との間に浮遊するパケットが消費する帯域と、再送要求を送信することによって消費する帯域を加味し、１往復時間に１つの再送要求を送信できる帯域分だけ、利用可能な帯域に余裕が生じる場合に再送要求を送信する。例えば、１往復時間を３０ｍｓ、再送要求のパケットサイズを１００バイトとすると、α＝２６６６ｂｉｔ／ｓｅｃと求まる。

しかし、αの値は、２６６６ｂｉｔ／ｓｅｃに限定されるものではない。すなわち、２６６６ｂｉｔ／ｓｅｃ以上の値を採用してもよい。また、ネットワークの負荷が定常的な負荷状況である場合に、２６６６ｂｉｔ／ｓｅｃより小さい値を採用してもよい。即ち、αの値は、任意に設定可能である。

このように、本実施の形態によれば、帯域推定部１２０９により推定された帯域が、受信端末が送信に利用している帯域を所定時間超える時刻を、再送要求の送信タイミングと決定するため、再送要求を送信するために十分な空き帯域が確保できた時刻に再送要求を送信することが可能となる。また、複数の再送要求が同時に送信されることがなくなる。この結果、再送が成功する確率が高まり結果として、高品質な映像送信が可能となる。

以上のように、本発明に係る受信端末は、複数の受信端末へのライブ映像配信や多地点会議システムなど実時間性を保ちながら、パケットの損失を補完する必要がある用途に適している。

本発明の実施の形態１に係る受信端末がネットワーク上に配置された構成例を示す概略図 送信端末及び受信端末間の映像の送信時刻の一例を示す図 送信される映像データの構造例を説明するための図 本実施の形態に係る受信端末の構成を示すブロック図 損失したパケットの重要度を判定するための表の一例を示す図 ＲＴＰヘッダの一例を示す図 再送要求先及び再送要求時刻を決定するための処理手順を示すフロー図 再送要求先及び再送要求時刻を決定するためのアルゴリズムを説明するための図 図８に対応する受信端末の接続関係を示す図 本発明の実施の形態２に係る受信端末がネットワーク上に配置された構成例を示す概略図 本実施の形態に係る受信端末の構成を示すブロック図 再送要求を送信するタイミング、ＴＦＲＣを用いて推定した帯域、及び映像配信に利用している帯域を示す図

符号の説明

１０１ 送信端末
１０２ａ〜１０２ｅ、８０１〜８０４ 受信端末
１０７ ネットワーク
２０１、１２０１ 受信端末
２０２、１２０２ 受信スタック
２０３、１２０３ 受信バッファ
２０４、１２０４ 再送要求先／再送要求時刻決定部
２０５、１２０５ 再送要求送信部
２０６、１２０６ 受信部
２０７、１２０７ 計測部
２０８、１２０８ 再生部
８０５〜８０６ ルータ
１１０９〜１１１２ ルータ
１２０９ 帯域推定部

Claims (7)

1. ネットワーク上で損失した損失パケットを補完するために再送要求を送信する受信端末であって、
   前記受信端末と他の複数の受信端末との間のネットワーク上の距離に対応する時間を計測する計測手段と、
   再送されるパケットが再生される再生時刻から現在時刻と前記計測手段によって計測された時間によって求められる余裕時間を前記受信端末毎に算出する算出手段と、
   前記算出された余裕時間に基づいて、再送要求の送信タイミングおよび再送要求の送信先を前記受信端末毎に決定する決定手段と、
   を有する受信端末。
2. 前記決定手段は、
   前記余裕時間の順番に従って、再送要求のタイミングおよび再送要求の送信先を決定する、
   請求項１記載の受信端末。
3. 前記決定手段は、
   前記余裕時間の順番に従って、前記他の複数の受信端末を複数のグループに分割し、グループ毎に再送要求の送信先を決定する、
   請求項１または請求項２記載の受信端末。
4. 前記複数の受信端末との間の利用可能な帯域を推定する推定手段、を有し、
   前記決定手段は、
   前記推定手段によって推定された利用可能な帯域が、前記受信端末が送信に利用している帯域を所定時間超える時刻を、再送要求の送信タイミングとして決定する、
   請求項１から請求項３のいずれかに記載の受信端末。
5. 損失パケットのパケットタイプに応じて重要度を判定する判定手段、を有し、
   前記決定手段は、
   損失パケットの重要度が規定の値以上に高いとき、前記余裕時間の昇順に再送要求の送信先を決定する、
   請求項１から請求項４のいずれかに記載の受信端末。
6. 前記再送要求は、ＸＣＡＳＴパケットである、
   請求項１から請求項５のいずれかに記載の受信端末。
7. ネットワーク上で損失した損失パケットを補完するために再送要求を送信する受信端末における受信方法であって、
   前記受信端末と他の複数の受信端末との間のネットワーク上の距離に対応する時間を計測する計測ステップと、
   再送されるパケットが再生される再生時刻から現在時刻と前記計測ステップによって計測された時間によって求められる余裕時間を前記受信端末毎に算出する算出ステップと、
   前記算出された余裕時間に基づいて、再送要求の送信タイミングおよび再送要求の送信先を前記受信端末毎に決定する決定ステップと
   を備えた受信方法。

Images