(57)【特許請求の範囲】
【請求項１】
サーバーにより、端末から高速チャンネル変更（ＦＣＣ）要求を受け取ることと、
サーバーにより、前記端末のマルチキャスト遅れを得ることであって、前記端末のマルチキャスト遅れは、前記端末がマルチキャストストリームを受け取るためのマルチキャスト要求メッセージをマルチキャスト応答点に送る時間と、前記端末が最初のマルチキャストパケット（ＦＭＰ）を受け取る時間の間隔である、ことと、
前記サーバーにより、前記端末のマルチキャスト遅れ、前記端末がユニキャストストリームをデコーディングするためのデコーディング速度、ユニキャストストリーム送信速度、及び前記端末がユニキャストストリームをデコーディングするために必要な前記端末の最低バッファーデータ量に従って、前記ＦＣＣ要求を受信した前記サーバーがビデオ平均ビット速度よりも速いビット速度で高速送信されるユニキャストストリームを送信するときの前記サーバーの最小バッファーデータ量の値を決定することと、
前記サーバーにより、前記サーバー上のパケットバッファー状態に従って最新のＩフレームの全てが到着したかどうかを判断することと、
前記最新のＩフレームの全てが到着し、前記最新のＩフレームから始まる到着したデータ量が前記最小バッファーデータ量の値以上である場合、前記高速送信されるユニキャストストリームの前記高速送信を前記最新のＩフレームから始めることと、
を含むことを特徴とするＦＣＣにおけるユニキャストストリームの高速送信方法。
【請求項２】
前記端末の前記マルチキャスト遅れを得ることが、
前記サーバーにより、前記端末によって送られた実時間伝送制御プロトコル拡張レポート（ＲＴＣＰＸＲ）拡張メッセージを受け取ることを含み、前記ＲＴＣＰＸＲ拡張メッセージは前記端末の前記マルチキャスト遅れの関連情報を保持し、前記関連情報が、
前記端末による前記マルチキャスト要求メッセージを送る時間と前記端末による最初のＦＭＰを受け取る時間の間隔、または、
前記端末による前記マルチキャスト要求メッセージを送る時間と前記端末による前記ＦＭＰを受け取る前記時間、または、
前記マルチキャスト遅れ、前記端末による前記マルチキャスト要求メッセージを送る前記時間、および前記端末による前記ＦＭＰを受け取る前記時間を含むことを特徴とする、請求項１に記載の方法。
【請求項３】
前記サーバーにより、前記端末の前記マルチキャスト遅れ、前記端末がユニキャストストリームをデコーディングするための前記デコーディング速度、前記ユニキャスト送信速度、および前記端末がユニキャストストリームをデコーディングするために必要な前記端末の前記最低バッファーデータ量に従って、前記ＦＣＣ要求を受信した前記サーバーがビデオ平均ビット速度よりも速いビット速度で高速送信されるユニキャストストリームを送信するときの前記サーバーの前記最小バッファーデータ量の値を決定することが、
前記サーバーにより、Ｖｉ（ｍｉｎ）＝（ｎＸ−ｓＸ）×Ｔ３＋ｃＢにより、前記ＦＣＣ要求を受信した前記サーバーがビデオ平均ビット速度よりも速いビット速度で高速送信されるユニキャストストリームを送信するときの前記サーバーの前記最小バッファーデータ量の値を決定することを含み、
Ｖｉ（ｍｉｎ）は前記ＦＣＣ要求を受信した前記サーバーがビデオ平均ビット速度よりも速いビット速度で高速送信されるユニキャストストリームを送信するときの前記サーバーの前記最小バッファーデータ量の値であり、
ｎＸは前記デコーディング速度であり、ｎはデコーディング倍率であり、Ｘは前記ビデオ平均ビット速度であり、
ｓＸは前記ユニキャストストリーム送信速度であり、ｓは送信倍率であり、
Ｔ３は端末のマルチキャスト遅れであり、
ｃＢは前記端末の前記デコーディングのために必要な最低バッファーデータ量であり、ｃはバッファー係数であり、Ｂはビデオバッファリング検証（ＶＢＶ）がバッファーできる最大データ量であることを特徴とする、請求項１または２に記載の方法。
【請求項４】
前記サーバーにより、前記パケットバッファー状態に従って前記最新のＩフレームの全てが到着したかどうかを判断した後、
前記サーバーにより、前記最新のＩフレームの全てが到着し、前記最新のＩフレームから始まる前記到着したデータ量が前記最小バッファーデータ量の値より小さい場合、前記高速送信されるユニキャストストリームの前記高速送信を前のＩフレームから始めることをさらに含むことを特徴とする、請求項１から３のいずれか一項に記載の方法。
【請求項５】
前記サーバーにより、前記パケットバッファー状態に従って前記最新のＩフレームの全てが到着したかどうかを判断した後、
前記最新のＩフレームの全てが到着していない場合、前記高速送信されるユニキャストストリームの前記高速送信を前記最新のＩフレームの前のＩフレームから始めることをさらに含むことを特徴とする、請求項１から３のいずれか一項に記載の方法。
【請求項６】
高速チャンネル変更（ＦＣＣ）におけるユニキャストストリームの高速送信のための装置であって、
端末から高速チャンネル変更（ＦＣＣ）要求を受け取った後に、前記端末がマルチキャストストリームを受け取るためのマルチキャスト要求メッセージをマルチキャスト応答点に送る時間と、前記端末が最初のマルチキャストパケット（ＦＭＰ）を受け取る時間の間隔である前記端末のマルチキャスト遅れを得るように構成される獲得モジュールと、
前記端末の前記マルチキャスト遅れ、前記端末がユニキャストストリームをデコーディングするためのデコーディング速度、ユニキャストストリーム送信速度、及び前記端末がユニキャストストリームをデコーディングするために必要な前記端末の最低バッファーデータ量に従って、前記ＦＣＣ要求を受信した前記サーバーがビデオ平均ビット速度よりも速いビット速度で高速送信されるユニキャストストリームを送信するときの前記サーバーの最小バッファーデータ量の値を決定するように構成される決定モジュールと、
前記装置上のパケットバッファー状態に従って最新のＩフレームの全てが到着したかどうかを判断するように構成された判断モジュールと、
前記最新のＩフレームの全てが到着し、前記最新のＩフレームから始まる到着した前記データ量が前記最小バッファーデータ量の値以上である場合、前記高速送信されるユニキャストストリームの前記高速送信を前記最新のＩフレームから開始するように構成される送信モジュールとを含むことを特徴とする装置。
【請求項７】
前記獲得モジュールが、前記端末によって送られた実時間伝送制御プロトコル拡張レポート（ＲＴＣＰＸＲ）拡張メッセージを受け取るように構成され、前記ＲＴＣＰＸＲ拡張メッセージが前記端末の前記マルチキャスト結合遅れの関連情報を保持し、
前記関連情報がマルチキャスト遅れを含み、前記マルチキャスト遅れが、前記端末によるマルチキャスト要求メッセージを送る時間と前記端末による最初のマルチキャストパケットを受け取る時間の間隔、または、
前記端末による前記マルチキャスト要求メッセージを送る時間と前記端末による前記ＦＭＰを受け取る時間、または、
前記マルチキャスト遅れ、前記端末による前記マルチキャスト要求メッセージを送る前記時間、および前記端末による前記ＦＭＰを受け取る前記時間を含むことを特徴とする、請求項６に記載の装置。
【請求項８】
前記決定モジュールが、
Ｖｉ（ｍｉｎ）＝（ｎＸ−ｓＸ）×Ｔ３＋ｃＢに従って前記ＦＣＣ要求を受信した前記サーバーがビデオ平均ビット速度よりも速いビット速度で高速送信されるユニキャストストリームを送信するときの前記サーバーの前記最小バッファーデータ量の値を決定するように構成され、
Ｖｉ（ｍｉｎ）は前記ＦＣＣ要求を受信した前記サーバーがビデオ平均ビット速度よりも速いビット速度で高速送信されるユニキャストストリームを送信するときの前記サーバーの前記最小バッファーデータ量の値であり、
ｎＸは前記デコーディング速度であり、ｎはデコーディング倍率であり、Ｘは前記ビデオ平均ビット速度であり、
ｓＸは前記ユニキャストストリーム送信速度であり、ｓは送信倍率であり、
Ｔ３は前記端末の前記マルチキャスト遅れであり、
ｃＢは前記端末のデコーディングのために必要な前記最低バッファーデータ量であり、ｃはバッファー係数であり、Ｂはビデオバッファリング検証（ＶＢＶ）がバッファーできる最大データ量であることを特徴とする、請求項６または７に記載の装置。
【請求項９】
前記送信モジュールがさらに、
前記最新のＩフレームの全てが到着し、前記最新のＩフレームから始まる到着したデータ量が前記最小バッファーデータ量の値より小さい場合、前記最新のＩフレームの前のＩフレームから前記高速送信されるユニキャストストリームの前記高速送信を開始するように構成されることを特徴とする、請求項６から８のいずれか一項に記載の装置。
【請求項１０】
前記送信モジュールがさらに、
前記最新のＩフレームの全てが到着していない場合、前記最新のＩフレームの前のＩフレームＩから前記高速送信されるユニキャストストリームの前記高速送信を開始するように構成されることを特徴とする、請求項６から８のいずれか一項に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はインターネット・プロトコル・テレビジョン（ＩＰＴＶ）の高速チャンネル変更（ＦＣＣ）に関し、詳細にはＦＣＣにおける高速ユニキャストストリーム送信の方法および装置に関する。
【背景技術】
【０００２】
従来のデジタルテレビジョンと比較して、ＩＰＴＶはチャンネル変更が長いという欠点を有する。ＦＣＣ方法はチャンネル変更の遅れを短縮することができる。
【０００３】
ＦＣＣのプロセス中に、セット・トップ・ボックス（ＳＴＢ）から送られたＦＣＣの要求を受けた後、サーバーは最新のＩフレームの前のＩフレーム（イントラピクチャー）から始まるユニキャストストリームの高速送信を行う。
【０００４】
先行技術において、ユニキャストストリームは最新のＩフレームの前のＩフレームから始まる高速送信が行われ、バーストトラフィックは大きく、必要な帯域幅は増大する。さらに、ＳＴＢは、像コンテントが最新のチャンネルコンテントよりも早期のものであるように、すなわち、最新のチャンネルコンテントと比較してＦＣＣ後のコンテントが遅くなるように、最新のＩフレームの前のＩフレームから始まるデコーディングを行う。ＳＴＢによって実行されるチャンネコンテントを最新のＩフレームの前のＩフレームから最新のチャンネルコンテントに同期させる必要があり、これは同期プロセス時間を増加させる。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
バーストトラフィックおよびチャンネルコンテントの同期プロセス時間を低減するために、本発明の実施形態はＦＣＣにおけるユニキャストストリームの高速送信の方法および装置を提供する。技術的な解決は以下の通りである。
【課題を解決するための手段】
【０００６】
本発明の一態様によれば、ＦＣＣにおけるユニキャストストリームの高速送信の方法は、
【０００７】
端末のマルチキャスト結合遅れを得ることと、
【０００８】
高速ユニキャストストリームの開始位置と端末のマルチキャスト結合遅れ、デコーディング速度、ユニキャスト送信速度、デコーディングに必要な最低バッファーデータ量に従って最新のパケット位置の間のデータ量の最小値を決定することと、
【０００９】
パケットバッファー状態によって最新のＩフレームが完全に到着したかどうかを判断することと、
【００１０】
最新のＩフレームが完全に到着し、最新のＩフレームから始まる到着したデータ量が最小値以上である場合、最新のＩフレームから始まるユニキャストストリームの高速送信を行うことと、を含む。
【００１１】
本発明の他の態様によれば、ＦＣＣにおけるユニキャストストリームの高速送信の装置は、
【００１２】
端末のマルチキャスト結合遅れを得るように構成される獲得モジュールと、
【００１３】
端末のマルチキャスト結合遅れ、デコーディング速度、ユニキャスト送信速度、デコーディングに必要な最低バッファーデータ量に従って高速ユニキャストストリームの開始位置と最新のパケット位置の間のデータ量の最小値を決定するように構成される決定モジュールと、
【００１４】
パケットバッファー状態に従って最新のＩフレームが完全に到着したかどうかを判断する判断モジュールと、
【００１５】
最新のＩフレームが完全に到着し、最新のＩフレームから始まる到着したデータ量が最小値以上である場合、最新のＩフレームから始まるユニキャストストリームの高速送信を行うように構成される送信モジュールと、を含む。
【００１６】
本発明の実施形態に提供された技術的解決によりもたらされる有益な効果は、
【００１７】
高速ユニキャストストリームの開始位置と最新のパケット位置の間のデータ量の最小値が、端末のマルチキャスト結合遅れ、デコーディング速度、ユニキャスト送信速度、デコーディングに必要な最低バッファーデータ量に従って決定され、最新のＩフレームが完全に到着し、最新のＩフレームから始まる到着したデータ量が最小値以上である場合、最新のＩフレームから始まるユニキャストストリームの高速送信が行われる。最新のＩフレームの前のＩフレームからユニキャストストリームを固定して高速割り込むのに比較して、バーストトラフィックが低減され、同時に、長いマルチキャスト結合遅れに起因する端末のバッファーのアンダーフローを確実に防止し、したがって、端末で実行される像の品質を確保しながら、必要な帯域幅およびチャンネルコンテントのための同期プロセス時間を低減する。
【００１８】
本発明の実施形態による技術的な解決をより明確に説明するために、実施形態または先行技術を説明するのに必要な添付図面が以下で簡単に紹介される。明らかに、以下の説明における添付図面は本発明のいくつかの実施形態のみであり、当業者であれば、創造努力なしに添付図面に従って他の図面を得ることができる。
【図面の簡単な説明】
【００１９】
【図１】本発明の第１実施形態によるＦＣＣにおけるユニキャストストリームの高速送信の方法のフローチャートである。
【図２】本発明の第２実施形態によるＦＣＣにおけるユニキャストストリームの高速送信の方法のフローチャートである。
【図３】本発明の第２実施形態による実時間伝送制御プロトコル（ＲＴＣＰ）拡張レポート（ＸＲ）拡張メッセージの概要図である。
【図４】本発明の第２実施形態によるＦＣＣの情報対話の図である。
【図５】本発明の第２実施形態によるパケットバッファー状態の概要図である。
【図６】本発明の第３実施形態によるＦＣＣにおけるユニキャスト高速送信の装置の構造図である。
【発明を実施するための形態】
【００２０】
本発明の目的、技術的解決、および利点の理解をより容易にするために、以下に添付図面を参照して本発明を詳細に説明する。
【００２１】
（実施形態１）
【００２２】
図１を参照すると、この実施形態はＦＣＣにおけるユニキャストの高速送信の方法を提供する。方法は、以下を含む。
【００２３】
１０１：端末のマルチキャスト結合遅れを得る。
【００２４】
端末はＳＴＢ、パーソナルコンピュータ、テレビジョン、または携帯電話、タブレットコンピュータなどの携帯端末とすることができ、この実施形態に制限されない。
【００２５】
１０２：端末のマルチキャスト結合遅れ、デコーディング速度、ユニキャスト送信速度、およびデコーディングに必要な最低バッファーデータ量に従って高速ユニキャストストリームの開始位置と最新パケット位置の間のデータ量の最小値を決定する。
【００２６】
高速ユニキャストストリームの開始位置と最新パケット位置の間のデータ量の最小値は、端末のバッファーのデータ量がマルチキャスト結合遅れ後のデコーディングのために必要な最低バッファーデータ量よりもまだ大きいことを確実にするために用いられる。デコーディングに必要な最低バッファーデータ量はゼロとすることができる。
【００２７】
１０３：パケットバッファー状態に従って最新のＩフレームが完全に到着したかどうかを判断する。
【００２８】
１０４：最新のＩフレームが完全に到着し、最新のＩフレームから始まる到着したデータ量が最小値以上である場合、最新のＩフレームから始まるユニキャストストリームの高速送信を行う。
【００２９】
端末から送られたＦＣＣを受け取った後、ＦＣＣのプロセス中に、サーバーはユニキャストストリームの高速送信を行う。いわゆるユニキャストストリームの高速送信は、ユニキャストの送信速度が元の速度よりも大きい、例えば元の速度の１．３倍の速度であることを指す。端末はユニキャストストリームを受け取り、ユニキャストストリームのデコーディングを行い、デコーディング速度は基本的に元の速度に等しい。ユニキャストストリームがマルチキャストストリームを捕捉したことが判明するとき、サーバーはユニキャストストリームの低速送信を開始し、マルチキャストパケット同期メッセージを端末に送る。いわゆるユニキャストの低速送信は、ユニキャストストリームの送信速度が元の速度よりも小さい、例えば元の速度の０．３倍であることを指す。サーバーがユニキャストストリームの低速送信を行う理由は、ユニキャストストリームの低速送信速度が、通常ユニキャストの高速送信から元の速度を差し引いた速度であるように、端末によって受け取られるマルチキャストストリーム用に十分な帯域幅を確保するためである。無論、他の速度および方法、例えばユニキャストの高速送信を継続することも許される。マルチキャストパケット同期メッセージを受け取った後、端末はインターネットグループ管理プロトコル（ＩＧＭＰ）結合メッセージをマルチキャスト応答点に送り、マルチキャストへの結合およびマルチキャストストリームを受け取る準備を求める。端末がデコードを行って画像を再生するとき、デコーディング速度はユニキャストストリームの低速送信速度よりも大きいので、バッファー中のデータは連続的に消費される。ＩＧＭＰ結合メッセージを送る時間（ユニキャストストリームの低速送信を開始するとき、サーバーはマルチキャストパケット同期メッセージを送るので、端末によるＩＧＭＰ結合メッセージを送る時間は、端末がマルチキャストストリームの低速送信の受け取りを開始する時間でもある）と端末によるマルチキャストストリームを受け取る時間の間の遅れ、すなわちマルチキャストストリーム結合遅れが長い場合、バッファー中のデータ量はアンダーフローする、すなわちデータ量は閾値以下まで低減され、または消去されて、デコーダーがデコーディングのための十分なデータを持たなくなり、これは再生される画像の停止または不鮮明なスクリーン現象を招く。
【００３０】
この実施形態において、高速ユニキャストストリームの開始位置と最新のパケット位置の間のデータ量の最小値は、端末のマルチキャスト結合遅れ、デコーディング速度、ユニキャスト送信速度、およびデコーディングに必要な最低バッファーデータ量に従って決定され、最新のＩフレームが完全に到着し、到着した最新のＩフレームから始まるデータ量が最小値以上である場合、ユニキャストストリームは最新のＩフレームから始まる高速送信が行われる。最新のＩフレームの前のフレームからユニキャストストリームを固定して高速割り込むのに比較して、バーストトラフィックは低減され、同時に端末のバッファーは長いマルチキャスト結合遅れに起因するアンダーフローが確実に防止され、したがって、端末で実行される像の品質を確保しながら、帯域幅の要求およびチャンネルコンテントのための同期プロセス時間が減少する。
【００３１】
（実施形態２）
【００３２】
この実施形態は第１の実施形態に基づく改善である。図２を参照すると、ＦＣＣにおけるユニキャストストリームの高速送信の方法は以下を含む。
【００３３】
２０１：サーバーが端末のマルチキャスト結合遅れを得る。
【００３４】
詳細には、端末によって送られたＲＴＣＰＸＲ拡張メッセージが受け取られ、ＲＴＣＰＸＲ拡張メッセージは端末のマルチキャスト結合遅れの関連情報を保持する。端末のマルチキャスト結合遅れの関連情報はマルチキャスト結合遅れ、または端末によるマルチキャスト結合メッセージを送る時間および端末による最初のマルチキャストパケット（ＦＭＰ）を受け取る時間とすることができ、マルチキャスト結合遅れは、端末がマルチキャスト結合メッセージを送る時間と端末がＦＭＰを受け取る時間によって計算して得られ、すなわち、端末がマルチキャスト結合メッセージを送る時間と端末がＦＭＰを受け取る時間の間隔はマルチキャスト結合遅れである。端末のマルチキャスト結合遅れは、端末のヒストリーデータによって得られる。
【００３５】
図３は、ＲＴＣＰＸＲ拡張メッセージの一例を示し、拡張フィールドはＩＧＭＰ結合遅れ、すなわちマルチキャスト結合遅れを含み、または拡張フィールドはｉｇｍｐ結合送信時間および最初のマルチキャストバースト時間、すなわち、端末によるマルチキャスト結合メッセージを送る時間および端末によるＦＭＰを受け取る時間を含む。あるいは、拡張フィールドは前述の３つの拡張フィールドを含むこともできる。
【００３６】
２０２：サーバーは端末のマルチキャスト結合遅れ、デコーディング速度、ユニキャスト送信速度、およびデコーディングに必要な最低バッファーデータ量に従って、高速ユニキャストストリームの開始位置と最新のパケット位置の間のデータ量の最小値を決定する。
【００３７】
詳細には、Ｖｉ（ｍｉｎ）＝（ｎＸ−ｓＸ）×Ｔ３＋ｃＢにより、高速ユニキャストストリームの開始位置と最新のパケット位置の間のデータ量の最小値Ｖｉ（ｍｉｎ）が決定される。
【００３８】
Ｖｉ（ｍｉｎ）は高速ユニキャストストリームの開始位置と最新のパケット位置の間のデータ量の最小値であり、ｎＸはデコーディング速度であり、Ｘはビデオ平均速度であり、ｎはデコーディング倍率であり、ｓＸはユニキャスト送信速度であり、ｓは送信倍率である。詳細には、ユニキャストストリームがマルチキャストストリームを捕捉するとき、サーバーがユニキャストストリームの低速送信を行う状況の下で、ｓは低速送信倍率（ｂに設定される）、すなわちｂ＜１である。詳細には、ユニキャストストリームがマルチキャストストリームを捕捉するときの状況下で、マルチキャスト応答点がマルチキャストストリームを送るまでサーバーはやはりユニキャストの高速送信を行い、ｓは高速送信倍率（ａに設定される）、すなわちａ＞１である。Ｔ３は端末のマルチキャスト結合遅れであり、ｃＢは端末のデコーディングに必要な最低バッファーデータ量であり、ｃはバッファー係数であり、Ｂはビデオバッファー検証（ＶＢＶ）がバッファリングすることのできる最大データ量である。
【００３９】
図４はＦＣＣの情報対話の図であり、情報対話は以下を含む。
【００４０】
３０１：端末が時点１でサーバーにＦＣＣ要求を送信する。
【００４１】
３０２：サーバーは時点２でＦＣＣ要求を受け取り、端末にユニキャストの高速送信を開始する。ユニキャストストリームがマルチキャストストリームを捕捉するとき、すなわち、時点３でサーバーはユニキャストストリームの低速送信を開始し、マルチキャストパケット同期メッセージを端末に送る。
【００４２】
サーバーによってユニキャストの高速送信が行われる、時点２から時点３までの間の時間をＴ１とする。この実施形態において、サーバーがユニキャストパケットの低速送信を開始する時点はサーバーがマルチキャストパケット同期メッセージを送る時点に設定される。
【００４３】
３０３：端末は同期メッセージを受け取り、時点４でマルチキャスト結合要求を送る。
【００４４】
端末は、マルチキャスト結合遅れがマルチキャスト応答点のレベル、リンク状態、アクセス状況、およびクライエント状況などの要因によって影響を受けるように、対応するマルチキャスト応答点にマルチキャスト結合メッセージを送る。一例として、展開されるネットワークのためのマルチキャスト応答点のレベルを取り上げると、マルチキャスト応答点のレベルは固定され、マルチキャスト応答点の各レベルは固定されたマルチキャスト結合遅れを有し、ユーザーの結合を要求するチャンネルのデータが最も近いマルチキャスト応答点に到着する場合、上位レベルのマルチキャスト応答点からのチャンネルデータを要求する必要はなく、マルチキャスト結合遅れは比較的短い。最も近いマルチキャスト応答点がユーザーの要求するチャンネルデータを持たない場合、上位レベルまたはさらに上位レベルのマルチキャスト応答点からチャンネルデータを要求する必要はなく、マルチキャスト結合遅れは比較的長い。
【００４５】
時点４での端末によるバッファリングされたデータ量はＶ１、すなわち高速ユニキャストストリームがマルチキャストを捕捉するときに端末によってバッファリングされるデータ量である。
【００４６】
３０４：端末は時点５でＦＭＰを受け取る。
【００４７】
時点３から時点５までの間の時間である、サーバーがユニキャストパケットの低速送信を開始するときから端末がＦＭＰを受け取るときまでの時間間隔をＴ２とし、時点４から時点５までの間の時間である、マルチキャスト結合遅れをＴ３とする。
【００４８】
時点５で端末によってバッファリングされるデータ量はＶ２、すなわち端末がＦＭＰを受け取るときのバッファリングされたデータ量である。
【００４９】
３０５：端末はＦＭＰ識別を保持する同期メッセージ応答をサーバーに戻す。
【００５０】
３０６：同期メッセージ応答を受け取った後、サーバーは時点６でユニキャストストリームの低速送信を停止する。
【００５１】
時点３から時点６までの間の時間である、ユニキャストストリームが低速送信される時間間隔をＴ４とする。
【００５２】
この実施形態において、以下のように設定される。ビデオ平均速度（元の速度）はＸ Ｍｂｐｓであり、デコーディング速度はｎＸ Ｍｂｐｓであり、ｎはデコーディング倍率、通常ｎ＝１であり、高速ユニキャスト送信速度はａＸであり、ａは高速送信倍率、現在ａは通常１．３であり、ユニキャスト低速送信速度はｂＸであり、ｂは低速送信倍率であり、現在ｂは通常０．３であり、通常端末のＶＢＶがバッファリングできる最大データ量はＢ＝７９９５３９２ビット＝０．９５Ｍバイトであり、端末のデコーディングに必要な最低バッファーデータ量はｃＢであり、ｃはバッファー係数であり、現在、それは通常ｃ＝１／２に制御され、ＶＢＶによってバッファリングされるデータ量がｃＢより小さいとき、デコーディングは開始することができない。端末が他の値を有する他の態様で評価するとき、例えば、端末のバッファーが完全に消去された簡略化した状態で決定されるとき、端末はデコーディングを実行することができない。Ｖｉはユニキャストストリームの高速送信開始位置と最新パケット位置の間のデータ量であり、Ｖｉ（ｍｉｎ）はユニキャストストリームの高速送信開始位置と最新パケット位置の間のデータ量の最小値である。
【００５３】
時点３で、ユニキャスト送信のデータ量はマルチキャスト送信のデータ量よりもＶｉ多く、増加したデータ量と端末がＦＭＰを受け取る前に受け取ったデータ量ｂＸＴ３の和は時点Ｔ３で端末がデコーディングを行ったデータ量ｎＸＴ３よりも大きい。すなわち、Ｖｉ−ｃＢ＋ｂＸＴ３＞＝ｎＸＴ３およびＶｉ＞＝（ｎＸ−ｂＸ）×Ｔ３＋ｃＢである。したがって、像品質の劣化を防止するためのＶｉの最小値はＶｉ（ｍｉｎ）＝（ｎＸ−ｂＸ）×Ｔ３＋ｃＢである。
【００５４】
当業者であれば、原理に従って、他のユニキャスト態様、例えば、時点３の後に、マルチキャスト応答点がマルチキャストストリームを送るまでユニキャストはまだ高速送信が行われ、または時点３の後にユニキャストは所定時間まだ高速送信が行われ、次いでユニキャストの低速送信が行われ、高速ユニキャストストリームの開始位置と最新のパケット位置の間の対応するデータ量の最小値を得ることもできる態様を理解する。例えば、時点３の後に、マルチキャスト応答点がマルチキャストストリームを送るまでユニキャストの高速送信がまだ行われる態様については、Ｖｉ＞＝（ｎＸ−ａＸ）×Ｔ３＋ｃＢである。ａＸはユニキャストの送信速度であり、詳細には、ユニキャストストリームがマルチキャストストリームを捕捉するとき、マルチキャストの応答点がマルチキャストストリームを送るまでサーバーがまだユニキャストの高速送信を行う状況下で、ａは高速送信倍率、すなわちａ＞１である。ここで、像品質の劣化の主な理由はデコーディングに必要なバッファリングされたデータ量が大きいことである。同様に、時点３の後ユニキャストが所定時間やはり高速送信が行われ、次いでユニキャストの低速送信が行われる態様については、Ｖｉ（ｍｉｎ）＝（ｎＸ−ｓＸ）×Ｔ３＋ｃＢであり、ここでｂ＜ｓ＜ａである。
【００５５】
２０３：サーバーは、最新のＩフレームがパケットバッファー状態に従って完全に到着するかどうかを判断する。
【００５６】
図５に示すサーバーのパケットバッファー状態の概要図を参照すると、点線部分は最新のＩフレームを表し、サーバーのパケットバッファー状態は概略２つの状態に分割され、１つは最新のＩフレームが完全に到着し（状態１）、他は最新のＩフレームが完全に到着しない（状態２）。最新のＩフレームが完全に到着する状態はさらに定義することができ、すなわち、最新のＩフレームから始まるデータ量は最新のＩフレームによって形成され（状態１−１）または最新のＩフレームと後続のフレームによって形成される（状態１−２）。
【００５７】
２０４：サーバーは最新のＩフレームが完全に到着するかどうかに従って、対応するＩフレームから始まるユニキャストストリームの高速送信を行う。
【００５８】
詳細には、最新のＩフレームが完全に到着し、最新のＩフレームから始まるデータ量が最小値Ｖｉ（ｍｉｎ）以上である場合、ユニキャストストリームは最新のＩフレームから高速送信が行われる。
【００５９】
最新のＩフレームが完全に到着し、最新のＩフレームから始まるデータ量が最小値よりも小さい場合、最新のＩフレームの前のＩフレームからユニキャストストリームの高速送信が始まり、最新のＩフレームの前のＩフレームは最新のＩフレームの前のＩフレーム、またはより早期のＩフレームであってもよい。さらに、マルチキャスト結合遅れが長くなるのを防止するために、デコーダーがデコーディングのための十分なデータを持たないようにバッファー中のデータ量をアンダーフローしてもよく、これは実行される像の停止または不鮮明なスクリーン現象を招く。最新のＩフレームの前のＩフレームからユニキャストストリームの高速送信が行われる前に、最新のＩフレームの前のＩフレームから始まる到着したデータ量が最小値Ｖｉ（ｍｉｎ）以上である条件を満足するかどうかを判断し、データ量が条件を満足する場合、ユニキャストストリームは最新のＩフレームの前のＩフレームから高速送信が行われ、データ量が条件を満たさない場合、条件を満たす最新のＩフレームよりも早期のＩフレームからユニキャストストリームの高速送信が行われる。
【００６０】
最新のＩフレームが完全に到着しない場合、最新のＩフレームの前のＩフレームからユニキャストストリームの高速送信が行われ、最新のＩフレームの前のＩフレームは最新のＩフレームの前のＩフレーム、またはより早期のＩフレームであってもよい。さらに、マルチキャスト結合遅れが長くなるのを防止するために、デコーダーがデコーディングのための十分なデータを持たないようにバッファー中のデータ量をアンダーフローしてもよく、これは実行される像の停止または不鮮明なスクリーン現象を招く。最新のＩフレームの前のＩフレームからユニキャストストリームの高速送信が行われる前に、最新のＩフレームの前のＩフレームから始まる到着したデータ量が最小値Ｖｉ（ｍｉｎ）以上である条件を満足するかどうかを判断し、データ量が条件を満足する場合、ユニキャストストリームは最新のＩフレームの前のＩフレームから高速送信が行われ、データ量が条件を満たさない場合、条件を満たす最新のＩフレームよりも早期のＩフレームからユニキャストストリームの高速送信が行われる。
【００６１】
最新のＩフレームの前のＩフレームは最新のＩフレームの前のＩフレーム、または早期のＩフレームであってもよい。
【００６２】
この実施形態において、ユニキャストストリームの高速送信の開始位置と最新パケット位置の間のデータ量の最小値は、端末のマルチキャスト結合遅れ、デコーディング速度、ユニキャスト送信速度、およびデコーディングに必要な最低バッファーデータ量に従って決定される。ユニキャストストリームは、最新のＩフレームが完全に到着し、最新のＩフレームからの到着したデータ量が最小値以上である場合、最新のＩフレームから始まる高速送信である。最新のＩフレームの前のＩフレームからユニキャストの固定された高速送信に比較して、バーストトラフィックは低減され、同時に、端末のバッファーは長いマルチキャスト結合遅れに起因するアンダーフローが確実に防止され、したがって、端末で実行される像の品質を確保しながら、チャンネルコンテントのための帯域幅の要求および同期プロセス時間が減少する。
【００６３】
（実施形態３）
【００６４】
図６を参照すると、この実施形態はＦＣＣにおけるユニキャストの高速送信の装置を提供し、装置は、以下を含む。
【００６５】
獲得モジュール４０１は端末のマルチキャスト結合遅れを得るように構成される。
【００６６】
決定モジュール４０２は、高速ユニキャストストリームの開始位置と最新のパケット位置の間のデータ量の最小値を端末のマルチキャスト結合遅れ、デコーディング速度、ユニキャスト送信速度、およびデコーディングに必要な最低バッファーデータ量に従って決定するように構成される。
【００６７】
判断モジュール４０３はパケットバッファー速度に従って最新のＩフレームが完全に到着するかどうかを判断するように構成される。
【００６８】
図５に示したサーバーのパケットバッファー状態の概要図を参照すると、点線部分は最新のＩフレームを表し、サーバーのパケットバッファー状態は概略２つの状態に分割され、１つは最新のＩフレームが完全に到着し（状態１）、他は最新のＩフレームが完全に到着しない（状態２）。最新のＩフレームが完全に到着する状態はさらに定義することができ、すなわち、最新のＩフレームから始まるデータ量は最新のＩフレームによって形成され（状態１−１）または最新のＩフレームと後続のフレームによって形成される（状態１−２）。
【００６９】
送信モジュール４０４は、最新のＩフレームが完全に到着し、最新のＩフレームから到着したデータ量が最小値以上である場合、最新のＩフレームから始まるユニキャストストリームの高速送信を行うように構成される。
【００７０】
獲得モジュール４０１は端末によって送られたＲＴＣＰＸＲ拡張メッセージを受け取るように構成され、ＲＴＣＰＸＲ拡張メッセージは端末のマルチキャスト結合遅れの関連情報を保持する。関連情報は、以下を含む。
【００７１】
マルチキャスト結合遅れ、ここで、マルチキャスト結合遅れは端末によるマルチキャスト結合メッセージを送る時間と端末によるＦＭＰを受け取る時間の間隔であり、または、
【００７２】
端末によるマルチキャスト結合メッセージを送る時間および端末によるＦＭＰを受け取る時間であり、または、
【００７３】
マルチキャスト結合遅れ、端末によるマルチキャスト結合メッセージを送る時間、および端末によるＦＭＰを受け取る時間である。
【００７４】
図３は、ＲＴＣＰＸＲ拡張メッセージの一例を示し、拡張フィールドはＩＧＭＰ結合遅れ、すなわちマルチキャスト結合遅れを含み、または拡張フィールドはｉｇｍｐ結合送信時間および最初のマルチキャストバースト時間、すなわち、端末によるマルチキャスト結合メッセージを送る時間および端末によるＦＭＰを受け取る時間を含む。あるいは、拡張フィールドは前述の３つの拡張フィールドを含むこともできる。
【００７５】
決定モジュール４０２は、詳細には、
【００７６】
Ｖｉ（ｍｉｎ）＝（ｎＸ−ｓＸ）×Ｔ３＋ｃＢに従って高速ユニキャストストリームの開始位置と最新のパケット位置の間のデータ量の最小値Ｖｉ（ｍｉｎ）を決定するように構成され、
【００７７】
Ｖｉ（ｍｉｎ）は高速ユニキャストストリームの開始位置と最新のパケット位置の間のデータ量の最小値であり、
【００７８】
ｎＸはデコーディング速度であり、ｎはデコーディング倍率であり、Ｘはビデオ平均速度であり、
【００７９】
ｓＸはユニキャスト送信速度であり、ｓは送信倍率であり、
【００８０】
Ｔ３は端末のマルチキャスト結合遅れであり、
【００８１】
ｃＢは端末のデコーディングに必要な最低バッファーデータ量であり、ｃはバッファー係数であり、ＢはＶＢＶがバッファリングすることのできる最大データ量である。
【００８２】
図４に示したＦＣＣの情報対話の図に基づいて、この実施形態において、以下のように設定される。ビデオ平均速度（元の速度）はＸ Ｍｂｐｓであり、デコーディング速度はｎＸ Ｍｂｐｓであり、ｎはデコーディング倍率、通常ｎ＝１であり、高速ユニキャスト送信速度はａＸであり、ａは高速送信倍率、現在ａは通常１．３であり、ユニキャスト低速送信速度はｂＸであり、ｂは低速送信倍率であり、現在ｂは通常０．３であり、端末のＶＢＶがバッファリングできる最大データ量はＢ＝７９９５３９２ビット＝０．９５Ｍバイトであり、端末のデコーディングに必要な最低バッファーデータ量はｃＢであり、ｃはバッファー係数であり、現在、それは通常ｃ＝１／２に制御され、ＶＢＶによってバッファリングされるデータ量がｃＢより小さいとき、デコーディングは開始することができない。端末が他の値を有する他の態様で評価するとき、例えば、端末のバッファーが完全に消去された簡略化した状態で決定されるとき、端末はデコーディングを実行することができない。Ｖｉはユニキャストストリームの高速送信開始位置と最新パケット位置の間のデータ量であり、Ｖｉ（ｍｉｎ）はユニキャストストリームの高速送信開始位置と最新パケット位置の間のデータ量の最小値である。
【００８３】
時点３で、ユニキャスト送信のデータ量はマルチキャスト送信のデータ量よりもＶｉ多く、増加したデータ量と端末がＦＭＰを受け取る前に受け取ったデータ量ｂＸＴ３の和は時点Ｔ３で端末がデコーディングを行ったデータ量ｎＸＴ３よりも大きい。すなわち、Ｖｉ−ｃＢ＋ｂＸＴ３＞＝ｎＸＴ３およびＶｉ＞＝（ｎＸ−ｂＸ）×Ｔ３＋ｃＢである。したがって、像品質の劣化を防止するために、Ｖｉの最小値はＶｉ（ｍｉｎ）＝（ｎＸ−ｂＸ）×Ｔ３＋ｃＢである。
【００８４】
当業者であれば、原理に従って、他のユニキャスト態様、例えば、時点３の後にマルチキャスト応答点がマルチキャストストリームを送るまでまだユニキャストの高速送信が行われ、または時点３の後にまだ所定時間ユニキャストの高速送信が行われ、次いでユニキャストの低速送信が行われ、高速ユニキャストストリームの開始位置と最新のパケット位置の間の対応するデータ量の最小値を得ることもできる態様を理解する。例えば、時点３の後に、マルチキャスト応答点がマルチキャストストリームを送るまでまだユニキャストの高速送信が行われる態様については、Ｖｉ＞＝（ｎＸ−ａＸ）×Ｔ３＋ｃＢである。ａＸはユニキャストの送信速度であり、詳細には、ユニキャストストリームがマルチキャストストリームを捕捉するとき、マルチキャストの応答点がマルチキャストストリームを送るまでまだサーバーがユニキャストの高速送信を行う状況下で、ａは高速送信倍率、すなわちａ＞１である。ここで、像品質の劣化の主な理由はデコーディングに必要なバッファリングされたデータ量が大きいことである。同様に、時点３の後ユニキャストが所定時間やはり高速送信が行われ、次いでユニキャストの低速送信が行われる態様については、Ｖｉ（ｍｉｎ）＝（ｎＸ−ｓＸ）×Ｔ３＋ｃＢであり、ここでｂ＜ｓ＜ａである。
【００８５】
さらに、送信モジュール４０４は、最新のＩフレームが完全に到着し、最近のＩクレームから到着したデータ量が最小値よりも小さい場合、最新のＩフレームの前のＩフレームから始まるユニキャストストリームの高速送信が行われるように構成され、最新のＩフレームの前のＩフレームは最新のＩフレームの前のＩフレーム、またはより早期のＩフレームであってもよい。さらに、マルチキャスト結合遅れが長くなるのを防止するために、デコーダーがデコーディングのための十分なデータを持たないようにバッファー中のデータ量をアンダーフローしてもよく、これは実行される像の停止または不鮮明なスクリーン現象を招く。最新のＩフレームの前のＩフレームから始まるユニキャストストリームの高速送信が行われる前に、最新のＩフレームの前のＩフレームから始まる到着したデータ量が最小値Ｖｉ（ｍｉｎ）以上である条件を満足するかどうかを判断し、データ量が条件を満足する場合、ユニキャストストリームは最新のＩフレームの前のＩフレームから高速送信が行われ、データ量が条件を満たさない場合、条件を満たす最新のＩフレームよりも早期のＩフレームから始まるユニキャストストリームの高速送信が行われる。
【００８６】
さらに、送信モジュール４０４は、最新のＩフレームが完全に到着しない場合、最新のＩフレームの前のＩフレームからユニキャストストリームの高速送信が行われるように構成され、最新のＩフレームの前のＩフレームは最新のＩフレームの前のＩフレーム、またはより早期のＩフレームであってもよい。さらに、マルチキャスト結合遅れが長くなるのを防止するために、デコーダーがデコーディングのための十分なデータを持たないようにバッファー中のデータ量をアンダーフローしてもよく、これは実行される像の停止または不鮮明なスクリーン現象を招く。最新のＩフレームの前のＩフレームからユニキャストストリームの高速送信が始まる前に、最新のＩフレームの前のＩフレームから始まる到着したデータ量が最小値Ｖｉ（ｍｉｎ）以上である条件を満足するかどうかを判断し、データ量が条件を満足する場合、ユニキャストストリームは最新のＩフレームの前のＩフレームから高速送信が行われ、データ量が条件を満たさない場合、条件を満たす最新のＩフレームよりも早期のＩフレームからユニキャストストリームの高速送信が始まる。
【００８７】
この実施形態に提供される装置および方法実施形態のサーバーは同じ概念に属し、特定の実施プロセスについてはここには繰り返して説明されない方法の実施形態を参照されたい。
【００８８】
この実施形態において、高速ユニキャストストリームの開始位置と最新のパケット位置の間のデータ量の最小値は、端末のマルチスキャン結合遅れ、デコーディング速度、ユニキャスト送信速度、デコーディングに必要な最低バッファーデータ量に従って決定される。最新のＩフレームが完全に到着し、最新のＩフレームから到着したデータ量が最小値以上である場合、ユニキャストストリームは最新のＩフレームから始まる高速送信が行われる。最新のＩフレームの前のフレームから始まるユニキャストストリームを固定して高速割り込むのに比較して、バーストトラフィックは低減され、同時に端末のバッファーは長いマルチキャスト結合遅れに起因するアンダーフローが確実に防止され、したがって、端末で実行される像の品質を確保しながら、帯域幅の要求およびチャンネルコンテントのための同期プロセス時間が減少する。
【００８９】
実施形態によって提供される技術的解決における内容の全てまたは一部分は、ソフトウェアプログラミングによって実施することができ、ソフトウェアプログラムは読み取り可能な記憶媒体、例えばコンピュータ中のハードディスク、光ディスク、またはフロッピー（登録商標）ディスクに保存することができる。
【００９０】
前述の説明は単に本発明のいくつかの例示的実施形態であるが、本発明の保護範囲を制限するものではない。本発明に開示された技術範囲における当業者であれば容易に想起することのできるさまざまな修正および変更は本発明の保護範囲に含まれる。したがって、本発明の保護範囲は請求項の保護範囲に従属する。
【符号の説明】
【００９１】
４０１ 獲得モジュール
４０２ 決定モジュール
４０３ 判断モジュール
４０４ 送信モジュール
【図１】
0005421346.tif 000002
【図２】
0005421346.tif 000003
【図３】
0005421346.tif 000004
【図４】
0005421346.tif 000005
【図５】
0005421346.tif 000006
【図６】
0005421346.tif 000007