(57)【特許請求の範囲】
【請求項１】
高速チャネル変更（ＦＣＣ）トランザクションを処理する方法であって、
ユーザインターフェイスデバイスでチャネル変更要求に応じて、ＦＣＣ要求をＦＣＣサーバに送信するステップと、
ＦＣＣ要求に応じて、ユニキャストストリームをＦＣＣサーバからユーザインターフェイスデバイスに伝送するステップと、
ユニキャストストリームがユーザインターフェイスデバイスに伝送されるレートをＦＣＣサーバが減少させるステップと、
要求チャネルのマルチキャストに加入するために、ユーザインターフェイスデバイスからマルチキャスト加入要求を送信するステップと、
マルチキャストに対するシームレスハンドオーバを保証するための最大マルチキャスト加入時間をユーザインターフェイスデバイスまたはＦＣＣサーバで決定するステップと、
ユーザインターフェイスデバイスがマルチキャストに加入する前に、最大マルチキャスト加入時間が経過した場合に、再開メッセージをＦＣＣサーバに送信するステップと、
再開メッセージに応じて、ユニキャストストリームをＦＣＣサーバからユーザインターフェイスデバイスに伝送することを再開するステップとを含む、方法。
【請求項２】
最大マルチキャスト加入時間が、ユーザインターフェイスデバイスのバッファレベルの関数として決定される、請求項１に記載の方法。
【請求項３】
最大マルチキャスト加入時間が、ユーザインターフェイスデバイスがマルチキャストに加入する前に、繰返し決定される、請求項１に記載の方法。
【請求項４】
ユニキャストストリームの伝送を再開するステップが、ユニキャストストリームが伝送されるレートを増加させるステップを含んでいる、請求項１に記載の方法。
【請求項５】
ユーザインターフェイスデバイスがマルチキャストに加入すると、メッセージをＦＣＣサーバに送信するステップを含む、請求項１に記載の方法。
【請求項６】
ユニキャストストリームが、ＦＣＣサーバによって適応可能に決定される初期遅延で伝送される、請求項１に記載の方法。
【請求項７】
マルチキャスト加入要求をユーザインターフェイスデバイスから送信した後に、少なくとも最小加入時間間隔でユニキャストストリームがユーザインターフェイスデバイスに伝送されるレートを小さくするステップをさらに含む、請求項１に記載の方法。
【請求項８】
ユーザインターフェイスデバイスにおいて、高速チャネル変更（ＦＣＣ）トランザクションを処理する方法であって、
チャネル変更要求に応じて、ＦＣＣ要求をＦＣＣサーバに送信するステップと、
ユニキャストストリームをＦＣＣサーバから受信するステップと、
要求チャネルのマルチキャストに加入するために、マルチキャスト加入要求を送信するステップと、
マルチキャストに対するシームレスハンドオーバを保証するための最大マルチキャスト加入時間を決定するステップと、
ユーザインターフェイスデバイスがマルチキャストに加入する前に、最大マルチキャスト加入時間が経過した場合に、再開メッセージをＦＣＣサーバに送信するステップと、
ＦＣＣサーバから再開されたユニキャストストリームを受信するステップとを含む、方法。
【請求項９】
最大マルチキャスト加入時間が、ユーザインターフェイスデバイスのバッファレベルの関数として決定される、請求項８に記載の方法。
【請求項１０】
最大マルチキャスト加入時間が、ユーザインターフェイスデバイスがマルチキャストに加入する前に、繰返し決定される、請求項８に記載の方法。
【請求項１１】
ユーザインターフェイスデバイスがマルチキャストに加入すると、メッセージをＦＣＣサーバに送信するステップを含む、請求項８に記載の方法。
【請求項１２】
ユーザインターフェイスデバイスにおいて実行されたとき、請求項８に記載の方法を実施する実行可能なプログラムコードを含む、一時的でない、プロセッサ読取可能な記憶媒体。
【請求項１３】
高速チャネル変更（ＦＣＣ）サーバにおいて、ＦＣＣトランザクションを処理する方法であって、
ユーザインターフェイスデバイスでチャネル変更要求に応じて送信されるＦＣＣ要求を受信するステップと、
ＦＣＣ要求に応じて、ユニキャストストリームをユーザインターフェイスデバイスに伝送するステップと、
ユニキャストストリームがユーザインターフェイスデバイスに伝送されるレートを減少させるステップと、
要求チャネルのマルチキャストに加入するために、ユーザインターフェイスデバイスに信号を送るステップと、
ユーザインターフェイスデバイスがマルチキャストに加入する前に、シームレスハンドオーバを保証するための最大マルチキャスト加入時間が経過した場合に、再開メッセージをユーザインターフェイスデバイスから受信するステップと、
再開メッセージに応じて、ユニキャストストリームをユーザインターフェイスデバイスに伝送することを再開するステップとを含む、方法。
【請求項１４】
ユニキャストストリームの伝送を再開するステップが、ユニキャストストリームが伝送されるレートを増加させるステップを含んでいる、請求項１３に記載の方法。
【請求項１５】
ユーザインターフェイスデバイスがマルチキャストに加入したことを示すメッセージをユーザインターフェイスデバイスから受信するステップを含む、請求項１３に記載の方法。
【請求項１６】
ユニキャストストリームが、ＦＣＣサーバによって適応可能に決定される初期遅延で伝送される、請求項１３に記載の方法。
【請求項１７】
マルチキャスト加入要求をユーザインターフェイスデバイスから送信した後に、少なくとも最小加入時間間隔でユニキャストストリームがユーザインターフェイスデバイスに伝送されるレートをさらに小さくするステップを含む、請求項１３に記載の方法。
【請求項１８】
ＦＣＣサーバ内で実行されたとき、請求項１３に記載の方法を実施する実行可能プログラムコードを含む、一時的でない、プロセッサ読取可能な記憶媒体。
【請求項１９】
ユニキャストストリームの伝送を再開する前に、マルチキャストから出るためのメッセージをユーザインターフェイスデバイスから送信するステップを含む、請求項１に記載の方法。
【請求項２０】
再開されたユニキャストストリームを受信する前に、マルチキャストから出るためのメッセージをユーザインターフェイスデバイスから送信するステップを含む、請求項８に記載の方法。
【請求項２１】
ユーザインターフェイスデバイスがマルチキャストから出るメッセージを送信した後に、ＦＣＣサーバがユニキャストストリームの伝送を再開する、請求項１３に記載の方法。
【請求項２２】
ユニキャストストリームの伝送を再開するステップが、ユニキャストストリームの現在のポイントからより高い速度でユニキャストストリームを伝送するステップを含む、請求項１に記載の方法。
【請求項２３】
再開されたユニキャストストリームが、ユニキャストストリームの現在のポイントからより高い速度でＦＣＣサーバから伝送される、請求項８に記載の方法。
【請求項２４】
ユニキャストストリームの伝送を再開するステップが、ユニキャストストリームの現在のポイントからより高い速度でユニキャストストリームを伝送するステップを含む、請求項１３に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は概して、インターネットプロトコルテレビ（ＩＰＴＶ）に関し、より詳細には、高速チャネル変更（ＦＣＣ）方法および装置に関する。
【背景技術】
【０００２】
デジタル加入者線（ＤＳＬ）またはファイバ上でインターネットプロトコルテレビ（ＩＰＴＶ）を提供する典型的な信号分配システムでは、加入者またはユーザは、セットトップボックス（ＳＴＢ）または受信機などのインターフェイスデバイスを、例えばＤＳＬアクセスマルチプレクサ（ＤＳＬＡＭ）を備えることができるネットワーク機器と通信するために備えている。インターフェイスデバイスは、テレビジョンなどで表示するために、ユーザによって選択されたチャネルに対応するコンテンツストリームを受信および処理するように構成されている。
【０００３】
ＩＰＴＶシステム内で所与の選択チャネルを受信するために、加入者インターフェイスデバイスは一般に、選択チャネルに対応するマルチキャストストリームに加入する。これは、チャネル変更コマンドのユーザ入力と新しいチャネル用の復号化可能なマルチキャストデータの受信の間に、約数秒の実質的な遅延がある可能性がある点において問題である。映像ストリームを復号化することは一般に機能的プロセスである、すなわち、フレームを復号化することは、前に復号化したフレームに左右されるので、復号化は前のフレームが必要ない「エントリポイント」で開始しなければならない。したがって、ＳＴＢが新しいチャネルのマルチキャストに加入すると、復号化を開始するために、ストリーム内で次のエントリポイントを待たなければならない。しかし、このようなエントリポイント間の間隔は、数百ミリ秒または秒である可能性がある。これは、チャネル変更の際の遅延の主な原因である。このようなチャネル変更遅延期間中に、表示デバイスのスクリーンは通常、空白またはフリーズしており、これはチャネルサーフィンのときに視聴者を特に悩ます可能性がある。
【０００４】
チャネル変更遅延の問題に対処するためのＩＰＴＶ内で使用される１つの解決法は、分配システム内に高速チャネル変更（ＦＣＣ）サーバを展開することであった。ＦＣＣサーバは、各チャネル用のコンテンツストリームの最後の数秒をキャッシュに格納する。チャネル変更コマンドの加入者入力に応じて、加入者のＳＴＢはＦＣＣ要求をＦＣＣサーバに送信する。ＦＣＣサーバは、ユニキャストでＳＴＢに、過去に（現在のマルチキャストパケットの背後で）いくつかのエントリポイントで開始する、即時再生用の新しいチャネルから映像の短いストリームを送信する。ＦＣＣサーバは、チャネルのデータレートより速いデータレートでＳＴＢにデータを送信し、この場合、数秒後に、そのチャネル用のマルチキャストストリームに「追いつく」。ＳＴＢは、第１のユニキャストパケットを受信したすぐ後に新しいチャネルを再生し始め、したがって、チャネル変更が速いように見える。ＦＣＣサーバがマルチキャストに「追いつく」と、新しいチャネル用のマルチキャストストリームに加入するためにＳＴＢに信号を送る。ＳＴＢはマルチキャストに加入し、マルチキャストストリームから再生し続ける。この従来の解決法の例示的実施の説明を、「高速チャネル変化」という名称の米国特許出願公開第２００５／００８１２４４号で見ることができる。
【０００５】
通常、（ＳＴＢとＤＳＬＡＭの間の）加入者のループは、限られた帯域幅である。ＦＣＣサーバがマルチキャストと並列でチャネルのデータレートでＦＣＣユニキャストをＳＴＢに送信する場合、パケット損失が生じることがある。このような発生を防ぐために、マルチキャストに加入するようにＳＴＢに信号を送ったすぐ後に、サーバはチャネルデータレートの何分の１かにユニキャストレートを落とす。したがって、マルチキャスト入力を受信し始めるまで「加入マルチキャスト」信号の受信からの時間の間に、ＳＴＢはデータを消費するレートよりかなり低いレートでデータを受信し、サーバユニキャストレートがチャネルデータレートより高い場合に、前に蓄積されたバッファから均衡が得られる。ＳＴＢ内のバッファがマルチキャストストリームの復号化が開始する前に、使い果たされるのを防ぐために、サーバは十分長い遅延で開始ポイントを選択しなければならない。
【０００６】
しかし、従来のＦＣＣ解決法の重大な欠陥は、ＦＣＣトランザクションあたりのデータ量は、マルチキャスト加入時間、すなわち、第１のマルチキャストパケットを受信するまで加入要求を送信してからの時間の変動性に極めて敏感である。この間隔は、数ミリ秒から数百ミリ秒まで変化することができる長い分布でランダム変数としてモデリングすることができる。このように、マルチキャスト加入時間の全ての場合に対して従来のＦＣＣシステムをプロビジョニングすることは、ＦＣＣトランザクション持続時間の大きな増加につながり、ほとんどの場合では、必要なく、より多くのＦＣＣトランザクションを処理するためにＦＣＣシステムを大きくするのがより難しくなる。
【０００７】
チャネル変更遅延問題に対する別の解決法は、加入者への高い帯域幅リンクに左右される。通常、より多くの帯域幅を使用することにより問題が緩和されるが、分配システム内の制限により、追加の帯域幅は利用可能でないまたは費用効率がよくない場合がある。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】米国特許出願公開第２００５／００８１２４４号明細書
【発明の概要】
【発明が解決しようとする課題】
【０００９】
加入者がＩＰネットワーク環境内で分配された映像用のチャネルを変更する場合に、ＦＣＣサーバによって送信されるユニキャストストリームの送信データの持続時間および量を適当に少なくする未解決の必要性がある。
【００１０】
本発明は例示的実施形態では、ＩＰＴＶシステム、または他のタイプの信号分配システムの高速チャネル変更のための改良技術を提供する。
【課題を解決するための手段】
【００１１】
本発明の高速チャネル変更（ＦＣＣ）処理の例示的な実施形態では、ＦＣＣサーバがセットトップボックス（ＳＴＢ）などのユーザインターフェイスデバイスへのユニキャスト伝送を終了し、ＳＴＢが新しいチャネル用のマルチキャストストリームに加入するように要求した後に、ＳＴＢは実際に起こる前に少なくともいくらかの間隔（例えば、数百ミリ秒）でパケットを使い果たすかどうかを予測するように構成されている。ＳＴＢが、使い果たされると予測した場合、マルチキャストから離れ、本明細書ではＲＥＳＴＡＲＴメッセージと呼ばれるメッセージをＦＣＣサーバに送信する。ＲＥＳＴＡＲＴメッセージに応えて、ＦＣＣサーバはその出力データレートを、マルチキャストレートより速いユニキャストレベルまで増加させる。ＦＣＣサーバがマルチキャストに追いついた場合、新しいチャネル用にマルチキャストに加入するようにＳＴＢに信号を送り、トランザクションが以前のように続く。
【００１２】
このような例示的な回復処理の実施により、最悪の場合ではなく大部分の一般的な場合に対するＦＣＣサーバを計画することが可能になる。マルチキャスト加入時間が設計加入時間を超えるいくつかの場合に、回復処理は、ＦＣＣトランザクションを再開して、ＦＣＣユニキャストからマルチキャストまでのハンドオーバ内のギャップを防止する。他の利点のうち、この解決法により、加入者へのより高い帯域幅を必要とすることなく、ＦＣＣユニキャストとマルチキャストストリームの間のより小さい初期遅延、より少ないＦＣＣトランザクションあたりの送信データ、より速いＦＣＣトランザクション、改善された拡張性が可能になる。
【００１３】
本発明の実施形態の上記および他の態様、特性および利点は、図面および以下の説明から明らかになるだろう。
【００１４】
次に、本発明の実施形態による装置および／または方法のいくつかの実施形態を、例としてのみ、添付の図面を参照して説明する。
【図面の簡単な説明】
【００１５】
【図１】本発明を完全にまたは部分的のいずれかで実施することができる、例示的な環境の略図である。
【図２】図１の環境でのＦＣＣトランザクションの進行を示すグラフプロットである。
【図３】マルチキャスト加入が、ＦＣＣユニキャストからマルチキャストまでのシームレスハンドオーバを保証する時間に起こらない、ＦＣＣトランザクションを処理するための例示的な回復処理のフローチャートである。
【図４】図３の例示的な回復処理が引き起こされた、ＦＣＣトランザクションの進行を示すグラフプロットである。
【図５】マルチキャスト加入が、ＦＣＣユニキャストからマルチキャストまでのシームレスハンドオーバを保証する時間に起こらない、ＦＣＣトランザクションを処理するための別の例示的な回復処理のフローチャートである。
【００１６】
この説明では、読者は、ビデオオーバＩＰネットワークなどのデジタル分配システムの基本的操作原理およびアーキテクチャに精通していると仮定する。本発明について、信号分配システムおよび関連する高速チャネル変更（ＦＣＣ）処理技術の例示的実施形態に関連して、本明細書で述べる。しかし、本発明は記載された特定のシステムおよび技術での使用に限るものではなく、代わりに、ＦＣＣ要求のより改善された処理を行なうのが望ましい任意の信号分配システムにより通常に適用可能であることを理解されたい。例えば、主にＩＰＴＶシステムの文脈で本明細書に記載されているが、本発明の技術を、例えば携帯システムを含む他のタイプの信号分配システムに直接的な方法で適応させることもできる。さらに、主に映像の文脈で本明細書に記載されているが、本発明の技術を、例えば音声または音声と映像を含む、あらゆるタイプのストリーミングコンテンツに適用することができる。
【００１７】
図１は、本発明を完全にまたは部分的のいずれかで実施することができる、例示的な環境１００の略図である。環境１００は、本実施形態では、ブロードバンドオーバインターネットプロトコル（ＩＰ）ネットワークである、コンテンツ分配ネットワーク１１０を含んでいる。例えば、コンテンツ分配ネットワーク１１０は、ケーブル、衛星、デジタル加入者線（ＤＳＬ）、家庭への光ファイバ、データ、および／または上記タイプのコンテンツ分配ネットワークのいずれかの組み合わせであってもよい。ネットワーク１１０の一部は無線または有線であってもよく、あらゆる適切なトポロジを有することができる。コンテンツ分配ネットワーク１１０はまた、インターネットまたはイントラネットなどの他のネットワークを含む、またはこれに結合させることができる。ネットワーク１１０は、テレビジョンサービスの提供に関連する信号を伝送するのに適切なあらゆるタイプの通信ネットワークを含むことができ、本発明はこの点で限定されるものではない。例えば、ネットワーク１１０の一部は、ローカルネットワーク、広域ネットワーク、インターネットなどを含むことができる。当業者には明らかなように、多くの代替配置が可能である。
【００１８】
ネットワーク１１０では、符号化されたコンテンツを含むマルチキャスト映像ストリームが通常、例えばヘッドエンドシステム、衛星、サーバなどを含めて、従来の他のサービスプロバイダ機器を含めることができる１つまたは複数のコンテンツソース１１５から分配される。ネットワーク１１０は、ルータおよびスイッチ１２０、１３０などのネットワーク要素の組み合わせ、およびセットトップボックス（ＳＴＢ）１５０などの複数の加入者インターフェイスデバイスに映像ストリームを分配させるためのデジタル加入者線アクセスマルチプレクサ（ＤＳＬＡＭ）１４０などの複数のノードを含んでいる。単純化のために、１つのコンテンツソース１１５からの１つの経路、１つのＤＳＬＡＭ１４０、および１つのＳＴＢ１５０が図１に示されている。太い矢印はダウンリンクデータの流れを示しており、薄い矢印は、チャネル変更要求などのアップリンク制御メッセージを示している。
【００１９】
例示的な実施形態の目的で、加入者インターフェイスデバイス１５０は、セットトップボックス（ＳＴＢ）であると仮定されるが、他の実施形態では、例えば、受信機、コンピュータ、携帯手持ち式端末または他のプロセッサベースデバイスをあらゆる組み合わせで備えることができる。このようなデバイスはまた、本明細書ではユーザインターフェイスデバイスまたは「クライアント」と呼ばれ、ＳＴＢ、衛星受信機（図示せず）、モデム（図示せず）、またはＴＶなどの表示デバイス１６０に接続された他のデバイスなどの、別個のデバイスとして実施することができる。ユーザインターフェイスデバイス１５０はまた、コンテンツ（音声および／または映像コンテンツ）をレンダリングおよび表示するためのスクリーンを有する、ＴＶ、コンピュータ（図示せず）またはモニタ（図示せず）などの表示デバイスと一体化させることができる、またはその一部であってもよい。このタイプの所与のデバイスにより、１人または複数人のユーザが信号分配システムを介してデバイスに運ばれるコンテンツストリームにアクセスすることが可能になる。ＳＴＢ１５０は、例えば、メモリに結合されたプロセッサ、およびデバイス１６０による表示に適切な形に受信コンテンツストリームを変換させる復号器１５２を含む、従来のハードウェアの実装を有することができる。メモリは、電子ランダムアクセスメモリ（ＲＡＭ）、読取専用メモリ（ＲＯＭ）、または他のタイプの記憶デバイスと、このようなデバイスの部分または組合せを含むことができる。メモリの一部は、分配ネットワーク１１０から受信されたコンテンツストリームを記憶する、好ましくは一定のビットレートで復号器１５２を供給するための入力バッファ１５１を備えることができる。プロセッサおよびメモリは、本明細書で開示された高速チャネル変更処理技術のインターフェイスデバイス部を実施するために、１つまたは複数のソフトウェアプログラムの記憶および実行の際に使用される。メモリは、本明細書ではコンピュータ読取可能な記憶媒体とも呼ばれるものの一例として考えることができる。
【００２０】
ネットワーク１１０はまた、コンテンツソース１１５とＤＳＬＡＭ１４０の間のいくつかの中間点に配置された、少なくとも１つの高速チャネル変更（ＦＣＣ）サーバを備えている。以下により詳細に記載するように、ＦＣＣサーバ１２５は、ＤＳＬＡＭ１４０を介してＳＴＢ１５０にユニキャスト映像ストリームを提供する。ＦＣＣサーバ１２５は、マルチキャストストリームをコンテンツソース１１５から受信し、必要に応じて、ユニキャストストリームとして提供するためにこれをキャッシュに格納する。典型的なシステムでは、単一のＦＣＣサーバ１２５は、しばしば同時に、多数のＳＴＢで多数のＦＣＣトランザクションに係合する。説明を簡単にするために、１つのＦＣＣサーバと１つのＳＴＢの間のＦＣＣトランザクションを本明細書に記載する。
【００２１】
図１の略図では、ルータ１２０は、ＳＴＢ１５０およびＦＣＣサーバ１２５へのマルチキャストルート内の最後の共通のルータを示している。ルータ１３０は、ＳＴＢ１５０へのマルチキャストルートおよびＦＣＣユニキャストルート内の最初の共通のルートを示している。ルータ１２０および１３０は、同じネットワーク要素であってもよい。破線または点線の矢印は、図１に示していない、中間ネットワーク要素（ルータ、スイッチ）が間にあることを示している。
【００２２】
別の独立型デバイスとして示されているが、ＦＣＣサーバ１２５は、システムの１つまたは複数の他のサーバと共通の処理プラットフォームで実施することができる、または多数のこのような処理プラットフォームにわたって分配させることができる。また、図１は単一のＤＳＬＡＭ１４０だけ、１対のルータ／スイッチ１２０、１３０、および単一のＦＣＣサーバ１２５を示しているが、所与の実施形態はもちろん、多数のこのような要素を含むことができる。システム１００はさらに、スイッチ、コンテンツサーバ、アドサーバなどのこのようなシステムの従来の実施で見られるタイプの追加の要素を備えることができる。
【００２３】
本明細書の実施形態がＤＳＬＡＭを参照して説明され、記載されているが、当業者は、本発明をサーバ、ルータ、スイッチ、衛星伝送装置を含むあらゆるタイプのエッジノード、およびネットワークのエッジからエンドユーザまでコンテンツを分配するための他の適切なノードと合わせて使用するように適合させることができることが簡単に分かるだろう。本実施形態では、ＤＳＬＡＭ１４０は、ＳＴＢ１５０へのコンテンツ分配ネットワーク１１０のインターフェイスを示すネットワーク要素であり、従来の方法で実施することができる。
【００２４】
ＳＴＢ１５０は、ＤＳＬ、ケーブル、光ファイバまたは無線リンク、またはあらゆる他の適切な接続であってもよい、ポイント間双方向性接続１４５を介してＤＳＬＡＭ１４０に結合される。ネットワーク１１０からのコンテンツストリームは、ＳＴＢ１５０上にＤＳＬＡＭ１４０によって通過される。ＳＴＢ１５０は、チャネル変更要求メッセージなどの制御メッセージをＤＳＬＡＭ１４０に伝送する。ＳＴＢ１５０からのチャネル変更に対する要求は、ＤＳＬＡＭ１４０まで進み、ＦＣＣサーバ１２５上まで通過させる。
【００２５】
ＦＣＣサーバ１２５がチャネル変更要求を受信すると、数秒間ユニキャストでＳＴＢ１５０に要求チャネルデータをストリーミングし始める。最初、これはＳＴＢ１５０によって受信された唯一のデータストリームであり、したがって、ＦＣＣサーバ１２５はＳＴＢに利用可能な全帯域幅を利用することができる。いくつかの点で、ＦＣＣサーバ１２５は、新しいチャネル用のマルチキャストストリームに加入するようにＳＴＢ１５０に命令し、時々その後に、ＦＣＣサーバ１２５はユニキャストストリームを終了する。ＳＴＢ１５０がマルチキャストストリームを受信した後に、またはそれ以前のある時点に、接続１４５に負荷をかけすぎることおよびパケット損失を生じさせることを回避するために、ユニキャストストリームのビットレートをそれに応じて落とさなければならない。これは、ユニキャストＦＣＣストリーミングの２段階、利用可能な全帯域幅を使用する最初の段階、およびユニキャストストリームがマルチキャストストリームと帯域幅を共有している後の段階を示す。さらに最適化するために、本発明者らは、ユニキャストデータレートがチャネルデータレートと等しい、マルチキャストストリームがＳＴＢ１５０に到達し始めるまで、マルチキャストストリームに加入する指示がＦＣＣサーバ１２５から送信されるときから経過した間隔の最小持続時間を示す中間段階を導入する。
【００２６】
図２は、ＳＴＢ１５０とＦＣＣサーバ１２５の間のＦＣＣトランザクションのストリーミングの上記段階を示している。破線２０１は、ＦＣＣサーバ１２５での所与のコンテンツストリームのマルチキャストパケットの到達を示している。これらのマルチキャストパケットは、ＦＣＣサーバに連続して到達する。任意の所与の時点で、ＦＣＣサーバは、マルチキャスト伝送の最後の数秒をキャッシュ格納させる、すなわちメモリ内に記憶させる。実線プロット２０２は、ＦＣＣサーバ１２５からＳＴＢ１５０までのユニキャストパケット伝送を示している。点線２０３は、バッファ１５１からＳＴＢ１５０の復号器１５２までのパケットの出力を示している。図２では、入力バッファ１５１からＳＴＢ１５０の復号器１５２までのデータレート（線２０３）と同様に、マルチキャストデータレートが（線２０１で示すように）１となるように、データレートが標準化されている。加えて、例示を簡単にするために、以下の単純化仮定が行なわれる：あらゆるジッタなしでデータストリーム全てが一定のビットレートであり、データストリームが離散パケットからなるということが無視され、各データストリームが連続ビットストリームフローとして処理され（データストリーム内の特定のポイントを示すために「パケット」などの用語が使用される）、減少（サーバによるユニキャストストリーム内のフレームのスキッピング）が行なわれず、ＳＴＢ１５０がマルチキャストに加入すると、マルチキャストパケットが、ＳＴＢおよびＦＣＣサーバ１２５に同時に到達し、ＦＣＣサーバからＳＴＢまでのユニキャストの伝送遅延がごくわずかで無視され、ＦＣＣサーバおよびＳＴＢでの処理時間はごくわずかで無視され、ＳＴＢはＦＣＣサーバから第１のユニキャストパケットを受信するとすぐに新しいチャネルを復号化し始める。
【００２７】
図２に示すように、段階１は、ＦＣＣサーバ１２５でのＦＣＣ要求の受信で時間Ｔ１で始まる。ＦＣＣサーバ１２５での遅延処理は、ごく僅かであると仮定されるので、ＦＣＣサーバ１２５がＦＣＣ要求を受信するとすぐに、要求チャネルデータをＳＴＢ１５０にユニキャストストリーミングを始める。ユニキャストによって送信されるパケットは、時間Ｔ０でサーバによって受信されるパケットで始まるＦＣＣサーバのキャッシュから取られる（時間Ｔ０でのサーバによって受信されるパケットがエントリポイントでなければならないことに留意されたい）。Ｔ１とＴ０の間の差ＤＳは、入力マルチキャストパケットと出力ユニキャストパケットの間の初期時間間隔である。この間隔の決定を、以下により詳細に説明する。
【００２８】
段階１中のユニキャストストリーミングのレートは、１＋Ｅであり、Ｅはバースト因数である（Ｅ＞０）。ＦＣＣサーバでのマルチキャスト受信の後の期間ＤＳであるポイントで送信が開始するので、１より高いレートでＦＣＣ１２５からデータを送信することが可能である。Ｅは、１＋ＥがデータをＳＴＢ１５０にストリーミングするための利用可能な帯域幅であるように選択されることが好ましい。ＦＣＣサーバ出力データレート１＋Ｅが入力レート１より高いので、入力マルチキャストパケットと出力ユニキャストパケットの間の間隔は、段階１中に小さくなっている。典型的には、段階１の持続時間は数秒である可能性がある。
【００２９】
ＦＣＣサーバ１２５に到達するマルチキャストストリームとサーバから出るユニキャストストリームの間の時間間隔がゼロになった場合、すなわち基本的にＦＣＣサーバによって受信されるとすぐに入力パケットがＦＣＣサーバからＳＴＢ１５０まで送信される場合、ＦＣＣサーバ１２５はマルチキャストに加入するようにＳＴＢに指示する。ＳＴＢ１５０はその後、時間Ｔ２でＤＳＬＡＭ１４０にインターネットグループ管理プロトコル（ＩＧＭＰ）加入要求を送信する。これは、段階２の開始を示す。時間Ｔ２でのＳＴＢ１５０によるＩＧＭＰ加入要求の送信から、ＳＴＢ１５０によって第１のマルチキャストパケットが受信されるときまでに間隔ＴＪがある。マルチキャスト加入時間と呼ばれる間隔ＴＪは、要求ごとに変わるランダム変数である。最小値ＴＪｍｉｎを有するが、その分布は長い尾部を有し、ＴＪは高い最大値を有することができる。ＦＣＣトランザクションにおけるマルチキャスト加入時間の重要性、およびその変動性を以下により詳細に説明する。
【００３０】
段階２は、時間Ｔ２で開始し、ＴＪｍｉｎまで続く間隔である。段階２の間、ＦＣＣサーバ１２５は、マルチキャストと帯域幅を共有する必要はないが、１より速いレートでデータを送信することができない。というのは、マルチキャストに追いついた後に、サーバは受信するレートより速いレートでパケットを送信することができないからである。したがって、ＦＣＣサーバ１２５は、典型的には数十ミリ秒を超えない、ＴＪｍｉｎより短い期間だけレート１でＳＴＢ１５０にデータを送信し続ける。図２では、ＴＪｍｉｎの相対サイズは図示を明確にするために誇張されている。
【００３１】
図２に示すように、期間ＴＪｍｉｎの終了の際に、ＳＴＢは実際はいくらか後の時間Ｔ２＋ＴＪまでマルチキャストストリームを受信し始めない可能性があるが、ＦＣＣサーバ１２５はＳＴＢ１５０へのユニキャストストリームのレートを下げる。時間Ｔ２＋ＴＪｍｉｎでのユニキャストレートのこの減少は、段階３の開始を示す。時間Ｔ２＋ＴＪで始まり、ＳＴＢ１５０は、ＦＣＣサーバ１２５からユニキャストストリーム、およびマルチキャストストリームの両方を受信する。マルチキャストストリームおよびユニキャストストリームの合計ビットレートが、１＋Ｅの利用可能な帯域幅を超えないように、ＦＣＣサーバ１２５は、段階３の間にユニキャストレートをＥまで落とすことが好ましい。ＦＣＣサーバ１２５は、（もしあっても）その事実の後までＳＴＢ１５０がいつマルチキャストストリームを受信し始めるかが正確に分からないことに留意されたい。したがって、ＳＴＢがマルチキャストを受信し始めることができる最も早い時間、すなわちＴ２＋ＴＪｍｉｎでレートを落とすことが好ましい。
【００３２】
図２のグラフ内の各時点では、プロット２０２と線２０３の間の水平方向差は、ＳＴＢ１５０でのユニキャストパケットの受信とＳＴＢ復号器１５２へのパケットの提供の間の時間間隔である。時間Ｔ３では、プロット２０２および線２０３が交わり、この時間間隔はほぼゼロである。図２から分かるように以下の通りである：
【数１】
0005420759.tif 000002
ユニキャストストリームがこの時点を超えて続くと、ユニキャストパケットは、復号器１５２が必要とする時間の後にＳＴＢ１５０に到達する、すなわち、遅すぎて有用ではない。最も有用ではないユニキャストパケットは、プロット２０２および線２０３の交差点に対応する点２１２によって示される。ＦＣＣサーバ１２５は、式１を使用してＴ３を計算することができ、段階３の終了を示す、時間Ｔ３より早くユニキャストストリームを止める。通常、段階３の持続時間は数百ミリ秒である。十分設計されたシステムでは、ＦＣＣサーバ１２５は典型的には、時間Ｔ３までユニキャストを続けないことに留意されたい。通常、ＳＴＢ１５０は、第１のマルチキャストパケットを受信し、ＦＣＣサーバ１２５に第１のマルチキャストパケットに対応する時間を報告する。サーバは、同じパケットをユニキャストで送信するまでストリーミングを続け、その後に停止する。
【００３３】
ＳＴＢ１５０によって復号化されるデータのストリーム内のあらゆる間隔を防ぐために、ユニキャストからマルチキャストストリームへのシームレスハンドオーバが起きる必要がある。分かるように、シームレスハンドオーバが起こるかどうかに関する重要な決定要因は、マルチキャスト加入時間ＴＪである。次に、シームレスハンドオーバに対する条件を説明する。
【００３４】
Ｄ１およびＢ１を、それぞれ、段階１で送信されるデータの持続時間および量とする。データレートは、マルチキャストデータレートが１であるように標準化されるので、Ｂ１が時間単位で与えられ、その長さの時間でマルチキャストによって伝送されるデータの量を示している。段階１は、ＤＳの（ＦＣＣサーバ１２５へのマルチキャスト到達とそこからのパケットユニキャストの間の）初期時間間隔で始まり、この時間間隔がゼロまで減少した場合に終了する。段階１の間に、ＦＣＣサーバ１２５はレート１＋Ｅでデータを送信し、レート１でデータを受信するので、Ｄ１およびＢ１は以下の通りに決定することができる：
【数２】
0005420759.tif 000003
【００３５】
時間Ｔ１では、ＳＴＢ１５０は、時間Ｔ０でのマルチキャストデータに対応するユニキャストデータを復号化し始め、ＳＴＢはレート１でデータを復号化するので、所与の時点でマルチキャストストリームに遅れてＤＳであるデータを一定で復号化する。（図２では、線２０３は線２０１に平行であり、間隔ＤＳだけ時間がずれていることに留意されたい）。したがって、ユニキャストストリームがマルチキャストストリームに追いついて、段階１が終了する時間Ｔ２までに、ＳＴＢバッファ１５１はデータ量ＤＳを蓄積している。バッファ１５１は段階２の間にこのレベルを維持し、この間、バッファ内への入力レートは復号器１５２への出力レートと等しい。しかし、段階３の間、ユニキャストデータはレートＥに到達するが、レート１でＳＴＢによって復号化される。したがって、０＜Ｅ＜１と仮定すると、ＳＴＢバッファ１５１は段階３の開始後
【数３】
0005420759.tif 000004
の時間に使い果たされることになる。
バッファ１５１が使い果たされた場合に復号化されるユニキャストパケットは、その前のＤＳのマルチキャストパケット、すなわち、段階３の開始後
【数４】
0005420759.tif 000005
の時間にＦＣＣサーバ１２５によって受信されるマルチキャストパケットに対応する。したがって、ユニキャストストリームからマルチキャストストリームまでのＳＴＢ１５０でのシームレス遷移を行なうために、段階３の開始後にＶより前に、マルチキャスト加入を完了させるべきである（すなわち、第１のマルチキャストパケットをＳＴＢによって受信すべきである）。換言すると、ＳＴＢの復号器でのＦＣＣトランザクション内の間隔を避けるために、マルチキャスト加入時間ＴＪは、以下の条件を満たすべきである：
【数５】
0005420759.tif 000006
【００３６】
この不等式では、ＴＪおよびＥは、容易に変更可能ではない、またはＦＣＣシステムデザイナの管理を超えるものである可能性があるネットワークパラメータであり、この場合、間隔が生じないことを保証するための唯一の方法は典型的には、ＤＳを増やすことによるものであり、それによって式４の条件がＴＪの可能な最大値でさえも満たされる。式２および３から分かるように、これは、段階１の持続時間、およびこの段階中に送信されるデータ量の比例した増加につながる。
【００３７】
上に記載したように、マルチキャスト加入時間ＴＪは、長い尾部の分布を備えたランダム変数であり、場合に応じて、大きな最大値を有することができる。このように、ＴＪの可能な最大値に対して、すなわち、式４の条件が常に満たすために、ユニキャストからマルチキャストまでのシームレスハンドオーバを必要とすることは不可能または非実用的である可能性がある。そのようにすることにより、ユニキャストストリームの持続時間およびユニキャストで送信されるデータ量が大規模操作には大きすぎるようになる（すなわち、並列で多くのＦＣＣセッションが実行される）可能性がある。
【００３８】
例示的なシステムでは、ハンドオーバが所与の好ましくは高い可能性でシームレスであることが予測されるＴＪの最大値が特定され、本明細書ではＨＪと示されている。すなわち、ＤＳは、加入時間ＴＪがＨＪを超えない場合に、ユニキャストからマルチキャストへのハンドオーバは所与の可能性でシームレスである。ＨＪは、ＴＪ＞ＨＪの可能性が小さい（たとえば、５％未満である）ように選択されることが好ましい。しかし、加入時間ＴＪがＨＪを超えた場合、以下に説明するように実施される例示的な手順は、シームレスハンドオーバを行なうようにこのようなケースを処理することができる。例示的な実施形態では、ＨＪは数百ミリ秒の値を有する。
【００３９】
図３は、ＦＣＣトランザクションを処理するために、ＳＴＢ１５０によって実行されるような、手順の例示的な実施形態のフローチャートである。３０１では、ＳＴＢ１５０でのチャネル変更コマンドに応じて、ＦＣＣ要求がＤＳＬＡＭ１４０を介してＦＣＣサーバ１２５に送信される。ＦＣＣサーバ１２５は、いくらかの初期時間間隔ＤＳでＳＴＢ１５０にデータをそれに応答してユニキャストし、３０２では、ＳＴＢはレート１＋Ｅでこのユニキャストストリームを受信する。図２を参照して上に記載したように、これは段階１で起こる。３０３では、ＦＣＣトランザクションは段階２に進み、ＳＴＢがＦＣＣサーバからのメッセージに応答して、時間Ｔ２でマルチキャスト加入要求を送信し始める。
【００４０】
ＳＴＢ１５０がマルチキャスト加入要求を送信した後で、時間Ｔ２＋Ｊｍａｘがあることになり、それまでに、ＳＴＢが第１のマルチキャストパケットを受信しなかった場合、ＦＣＣユニキャストが時間Ｔ３で終了するときデータを使い果たすことになると予測することができる。すなわち、マルチキャスト加入時間ＴＪがＪｍａｘを超えた場合、ＳＴＢ復号器１５２に与えられるストリーム内に間隔がある。図２に示すように、Ｊｍａｘ＝ＴＪｍａｘ＋Ｖおよび「優先警告」時間Ｗは、問題があることが明らかになった場合にＴ２＋Ｊｍａｘで始まり、データが使い果たされた場合に時間Ｔ３で終了する間隔の長さである。警告時間Ｗは実質的にはデータレートとは無関係であり、典型的には、数百ミリ秒の長さである。上記で行われた単純化仮定では、Ｗ＝ＤＳであることに留意されたい。図２に示すように、時間Ｔ２＋Ｊｍａｘは、上に説明した最も有用でないユニキャストパケット（ポイント２１２で示される）のＦＣＣサーバ１２５へのマルチキャスト到達に対応する。
【００４１】
３０４では、ＳＴＢ１５０は、以下の式にしたがって、Ｂ（Ｔ２）で示された時間Ｔ２でのそのバッファ１５１のレベル、およびバーストレートＥに基づいてＪｍａｘを決定する：
【数６】
0005420759.tif 000007
上に説明したように、ＳＴＢバッファ１５１のレベルは段階２を通して実質的に一定であり、段階３で使い果たされ始め、それによって段階３の開始後
【数７】
0005420759.tif 000008
の数式の時間で空になる。
【００４２】
Ｊｍａｘを計算するためにＳＴＢ１５０によって使用される式５のパラメータは、様々な適切な手段によって得ることができる。時間Ｔ２でのＳＴＢバッファレベルは段階２を通して実質的に一定であると予測することができるので、例えば、ＳＴＢ１５０が、段階２内で後半に、または段階３の開始直後にマルチキャストに加入し、段階２の間にバッファレベルの変化がある場合により正確なレベルを表面上は得るために、ＳＴＢ１５０がＦＣＣサーバ１２５からメッセージを受信するとすぐに、バッファレベルを決定することができる。（段階３まで待つことによって、バーストレートＥの更新推量も得ることができ、Ｊｍａｘを決定する際に使用することができることに留意されたい）。パラメータＴＪｍｉｎをＳＴＢ１５０に用意することができる、またはＳＴＢは、マルチキャストに加入するために信号を受信した時からユニキャストデータレートが１より下に十分落ちるまで、間隔を追跡することによって推測することができる。バーストレートＥは、用意を介してＳＴＢに知らせることができる、または段階３において時間Ｔ２＋ＴＪｍｉｎの後に入力データレート、またはバッファ１５１の使い果たしレートのいずれかから予測することができる。別の方法では、パラメータＤＳ、ＴＪｍｉｎ、Ｅのいずれかまたはすべてを、ＦＣＣサーバによって通信することができる。例えば、これらの値は、マルチキャストに加入するようにＳＴＢに信号を与えるＦＣＣサーバからのメッセージ内に含めることができる。
【００４３】
３０５では、ＳＴＢ１５０がＦＣＣサーバ１２５からユニキャストストリームを受信し続けるので、マルチキャストに加入するために待機する、すなわち、第１のマルチキャストストリームパケットの受信を待ち受ける。３０６では、マルチキャストに加入するために待機しながら、ＳＴＢ１５０は、加入要求が送信されてから経過した時間を監視する。この時間が３０４で決定したＪｍａｘを超えない場合、ＳＴＢは、ＦＣＣユニキャストストリームを受信し続けるので、マルチキャストストリームを待ち続ける。経過時間がＪｍａｘを超える前にマルチキャストストリームが開始する場合、動作は通常、３０７に示すように段階３内に進む。段階３はその後、ＦＣＣサーバ１２５からのユニキャストストリームが終了すると、３０８で終了する。
【００４４】
しかし、加入要求が送信されてからの経過時間がＪｍａｘを超え、マルチキャストストリームの受信がまだ開始されていないと３０６で決定された場合、動作は３０９に進む。この時点では、ＳＴＢ１５０は、ＦＣＣユニキャストが終了する時間までにデータを使い果たすことがわかり、これに応じて、このようなことが生じるのを防ぐために先制的動作をとる。このようなシナリオが図４に示されている。３０９では、ＳＴＢは、ＩＧＭＰ「出発」メッセージをＤＳＬＡＭ１４０に送信し、好ましくは短い時間（例えば、約１００ミリ秒まで）待機して、マルチキャストストリームが停止したこと、すなわち、ＩＧＭＰ「出発」メッセージを送信した後にマルチキャストパケットが到達しないことを検証することによって、マルチキャストグループを離れる。したがって、３１１では、ＳＴＢはＦＣＣサーバ１２５にＲＥＳＴＡＲＴメッセージを送信する。図４を参照すると、これはＴ２＋Ｊｍａｘ［Ｂ（Ｔ２）］時間で、またはそのあたりで起こる。（例示を簡単にするために、図４はマルチキャストを離れるのとＲＥＳＴＡＲＴメッセージを送信する間の上記待機時間を示していない）。ＲＥＳＴＡＲＴメッセージは、同じチャネルに加入するための追加の要求として働く。ＲＥＳＴＡＲＴメッセージをＳＴＢ１５０から受信すると、ＦＣＣサーバ１２５は、図４で段階１ａと示された新しい「段階１」に戻るが、後退するのではなく、単に有効データレートを１＋Ｅまで増加させ、現在ユニキャストストリームにあるポイントからＳＴＢ（図３、ステップ３０２）にユニキャストストリーミングデータを保持する。
【００４５】
ＲＥＳＴＡＲＴメッセージおよびその実施は、たとえば、現在のまたは新しいＦＣＣプロトコルまたは標準の改善として、または所有スキームの一部として組み込むことができる。
【００４６】
マルチキャストとユニキャストの間の間隔が（再び）閉じられると、ＦＣＣサーバは、マルチキャストに加入するようにＳＴＢに指示し、今回は第１のマルチキャストパケットがより早く到達するようにと望んで、第１の試みと同じ手順にしたがい続ける。図４に示すように、ＳＴＢは時間Ｔ２ａでマルチキャスト加入要求を送信する（図３、ステップ３０３）。これは、図４で段階２ａと示された、新しい「段階２」の開始を示す。段階２と同様に、段階２ａの間、間隔ＴＪｍｉｎが時間Ｔ２ａ＋ＴＪｍｉｎで経過するまで、ユニキャストレートは１に落ちる。
【００４７】
前と同様に、段階２ａのいつか、または段階３ａの始めに、ＳＴＢ１５０は、式５にしたがって時間Ｔ２ａでそのバッファ１５１のレベルに基づいて、Ｊｍａｘの新しい値を決定する（図３、３０４）。この新しい値は、図４ではＪｍａｘ［Ｂ（Ｔ２ａ）］と示されている。時間Ｔ２ａ＋Ｊｍａｘ［Ｂ（Ｔ２ａ）］は、ポイント２１２ａで示すように、最も有用でないユニキャストパケットのＦＣＣサーバへのマルチキャスト到達に対応することに留意されたい。ＳＴＢ１５０はその後、再び、マルチキャストが開始するのを待つ（３０５、３０６）。この間、段階２ａは、Ｔ２ａ＋ＴＪｍｉｎで終了となり、段階３ａと示された新しい「段階３」が始まる。段階３と同様に、段階３ａのユニキャストレートはＥまで落ちる。
【００４８】
図４に示すシナリオでは、ＳＴＢ１５０は、時間Ｔ２ａ＋ＴＪに、時間間隔Ｊｍａｘ［Ｂ（Ｔ２ａ）］の終了の前にマルチキャストストリームを受信し始める。上に記載したように、ＳＴＢは、ユニキャストが時間Ｔ３ａで終了するまで（３０８）、段階３ａでマルチキャストおよびユニキャストストリーム（図３、３０７）の両方を受信する。
【００４９】
極めて長いマルチキャスト加入時間が極めて通常ではないので、マルチキャスト加入時間が、連続して２倍より多く、または多くとも３倍、予測した加入時間を超えるという可能性は実質的に無視してよいものである。
【００５０】
例示的な回復手順を実施することにより、パラメータＨＪをより低く設定することが可能になる、すなわち、マルチキャスト加入時間ＴＪのより小さい変更のためにＦＣＣシステムを設計することが可能になる。上に説明したように、シームレスハンドオーバを有するために、式４の条件を満たさなければならない。式４の項を並べ替えると：
【数８】
0005420759.tif 000009
式６によって示されるように、ＴＪの加入時間に対するシームレスハンドオーバに必要なＤＳの最小値は、差ＴＪ−ＴＪｍｉｎに直接関連している。従来のシステムでは、上記のように再開手順なしで、許容可能なＦＣＣ性能を与えるために、ＤＳをＴＪの分布のより広い範囲（例えば、９９．５％）を含むように設定しなければならない。ＴＪの分布のより小さい範囲（例えば、９５％）に対応することができるので、上に記載したような再開手順を実施することにより、ＤＳをより低い値に設定することが可能になる。加入時間がこの範囲（例えば、トランザクションの残りの５％）を超えるＦＣＣトランザクションを、回復手順を使用して処理することができる。したがって、要件ＨＪを少なくすることにより、各ＦＣＣトランザクションの持続時間、およびＦＣＣユニキャストで必要とされるデータ量を実質的に小さくすることが可能になる。これにより、各ＦＣＣトランザクションがあまり要求されなくなり、それによって、所与のＦＣＣサーバによってサポートすることができるＦＣＣ要求の利用可能性および数が大きくなり、またしたがって、ＦＣＣ機能を有するシステムの実施に関連する費用が少なくなる。
【００５１】
図５は、マルチキャストに加入するために待機する時に（３０４、３０５および３０６）ＳＴＢがＪｍａｘの推定値を繰返し更新する、ＦＣＣトランザクションの別の例示的な実施形態のフローチャートである。これにより、時間の経過と共にＳＴＢバッファを使い果たすレートを観察することによって重要な時点Ｔ２ａ＋Ｊｍａｘ［Ｂ（Ｔ２ａ）］をより正確に推定することが可能になり、減少がないなどの上記の単純化仮定のいくつかが適用されない状況で特に有用である。これらの状況では、プロット２０２はちょうど区分的に直線ではない可能性があり、重要な時点に近づけば近づくほど、よりよく推測することができる。
【００５２】
本発明の一実施形態の所望の目的は、ＦＣＣトランザクションの段階１での、段階１の持続時間の平均、Ｄ１、および伝送されたユニキャストデータ量の平均、Ｂ１を小さくすることである。マルチキャスト加入時間の実際の分布にしたがって、パラメータＨＪ（通常の動作に対する最大可能マルチキャスト加入時間）の選択を最適化することにより、この目的を達成するのを助ける。ＨＪを高く選択しすぎた結果、ＤＳ、またしたがってＤ１およびＢ１（式２および３で）が不必要に大きくなり、ＨＪを低く選択しすぎた結果、上記再開手順などの回復手順を通して進む多すぎるＦＣＣトランザクション、およびこれに関連するオーバーヘッドを招くことにつながる。しかし、ＩＧＭＰが動作する方法により、よくあるチャネルは、あまり通常見られないチャネルより短いマルチキャスト加入時間を有する可能性が高い。さらに、ＩＧＭＰ加入要求が処理される前に待ち行列で長く遅延される可能性があるので、ピーク利用の期間中、マルチキャスト加入時間は長くなる可能性が高い。したがって、本発明の例示的な実施形態によると、ＨＪはチャネル、時間および／または利用に順応することが好ましい。すなわち、ＨＪ、したがってＤＳの値は、チャネル、時間および／または利用にしたがって選択される。
【００５３】
例示的な実施形態では、上に記載したように、再開手順を用いるＦＣＣトランザクションの可能性は、所与の時間ｔにＦＣＣサーバでＰ４として推定される。可能性Ｐ１は、例えば、固定持続時間の時間間隔（例えば、１０秒）を考慮し、各間隔で、その間隔にＦＣＣトランザクションの合計数に対する再開手順を使用して、ＦＣＣトランザクションの数の間の割合を計算することによって推定することができる。Ｐ１がある予め設定された目標可能性Ｐｄ（例えば、５％）を超える場合、ＨＪ（およびＤＳ）が大きくなり、Ｐｔ＜Ｐｄの場合、ＨＪ（およびＤＳ）が小さくなる。
【００５４】
上記手順は、ＦＣＣトランザクション中に伝送されるデータの平均持続時間または平均量を最小限に抑える、目標可能性Ｐｄが知られており、Ｐｄが時間の経過で変わらない場合に、うまくいくべきである。しかし、これが当てはまらない場合、ＦＣＣトランザクション中に伝送されるデータの平均持続時間または平均量を最小限に抑えるために、以下に記載されたような手順を代わりに使用することができる。
【００５５】
最初に、サーバはマルチキャスト加入時間の分布を直接予測することができる。上に記載したように、クライアントは典型的には、サーバが各ＦＣＣトランザクションに対するマルチキャスト加入時間を決定することを可能にする、各ＦＣＣトランザクション内に第１のマルチキャストパケットを受信した場合に、ＦＣＣサーバに報告する。ＦＣＣサーバは、例えば、所与の時間間隔で（例えば、最後の６０秒）特定のチャネルに対する全てのマルチキャスト加入時間のヒストグラムを生成することによって、特定のチャネル用のマルチキャスト加入時間の現在の分布を予測するためにこれらの値を使用することができる。
【００５６】
予測したマルチキャスト加入時間分布を使用して、サーバはこの分布にしたがった値にＴＪｍｉｎを設定することができる。ＤＳのあらゆる値で
【数９】
0005420759.tif 000010
およびＪｍａｘ＝ＴＪｍｉｎ＋Ｖの対応する値を決定することができる。
このＪｍａｘおよびマルチキャスト加入時間の分布を使用して、ＤＳのこの特定の値に対してＰｄ、再開の可能性を決定することができる。
【００５７】
図４に示すように、段階３中に、ＳＴＢバッファ１５１内のユニキャストレートはＥであり、復号器１５２への出力レートは１である。クライアントがＲＥＳＴＡＲＴメッセージを送信する場合、段階３の開始後の時間Ｖでそうする。段階３が始まると、入力ユニキャストとマルチキャストの間の間隔はゼロであり、段階３が開始した後に、ユニキャストはレートＥで受信され、マルチキャストはレート１で前進する。したがって、Ｖの時間間隔の間、入力ユニキャストとマルチキャストの間の間隔はＶ（１−Ｅ）＝ＤＳＥである。これは、段階１ａの始めのマルチキャストに対するユニキャストの遅延であり、段階１の始めの初期遅延ＤＳに対応する。式２および３を導き出すために使用される同じ論法を使用するが、ＤＳの代わりにＤＳＥを置き換えて、段階１ａ中に伝送されるデータの持続時間および量はそれぞれ、以下の式によって与えられる：
【数１０】
0005420759.tif 000011
【００５８】
より多くのＲＥＳＴＡＲＴ要求が必要である場合、各ＲＥＳＴＡＲＴ要求の後の第１の段階中に伝送されるデータの持続時間および量はまた、それぞれＤ１ａおよびＢ１ａである。持続時間は典型的には、段階１および１ａよりはるかに短いので、ユニキャストで伝送されたデータの合計持続時間および量を推測するために、初期段階２および３、および各ＲＥＳＴＡＲＴ後の段階２ａおよび３ａは無視することができる。（これらの段階の持続時間は、例示する目的で図２および４で誇張されている）。さらに、段階２、２ａおよび３、３ａでのより低いデータレートにより、これらの段階で伝送されるデータの量は段階１、１ａと比べてさらに低い。これらの単純化仮定に基づいて、予測合計持続時間Ｄｅｘｐ、および送信データの予測合計量Ｂｅｘｐが以下の式によって与えられる：
【数１１】
0005420759.tif 000012
したがって、ＤＳのあらゆる値では、ＦＣＣサーバは、それぞれ式９および１０にしたがって、ＤｅｘｐおよびＢｅｘｐを決定することができる。ＦＣＣサーバが特定のチャネルに対するＦＣＣ要求を受信した場合、キャッシュ内のエントリポイントと考える。典型的には、このようなエントリポイントの数は極めて小さく、しばしば１０未満である。このような各エントリポイントは、ＤＳの値に対応する。ＦＣＣサーバは、各エントリポイントに対するＤｅｘｐおよび／またはＢｅｘｐを計算し、（１つまたは複数の）最低値を生じるエントリポイントを選択することができる。
【００５９】
特定の実施形態では、より高い精度が必要であるまたは望まれる場合、全ての段階の貢献の主な原因である、ＤｅｘｐおよびＢｅｘｐに対するより正確な推定値を計算することが可能である。この場合、式９および１０におけるＤ１およびＢ１は、段階１、２および３の合計持続時間およびユニキャストデータ量に対する対応する式と置き換えられ、Ｄ１ａおよびＢ１ａは、段階１ａ、２ａおよび３ａの合計持続時間およびユニキャストデータ量に対する対応する式と置き換えられる。
【００６０】
上に記載した特定の例、および対応する仮定は、本発明を限定するものではないことを理解されたい。例えば、他の実施形態では、上で行なった仮定が適用される必要はない。また、上に記載されたようなＦＣＣ処理の特定の段階、パラメータおよび他の特徴を、代替実施形態では変更することができる。本発明は、他の特定の装置および／または方法で実施することができる。記載した実施形態は、全ての点において、単に例示的ものであり、限定的なものと考えられるものではない。特に、本発明の範囲は、本明細書の説明および図によってではなく、添付の特許請求の範囲によって示される。特許請求の範囲の同等物の意味および範囲内にある全ての変更は、その範囲内に含まれるものである。
【図１】
0005420759.tif 000013
【図２】
0005420759.tif 000014
【図３】
0005420759.tif 000015
【図４】
0005420759.tif 000016
【図５】
0005420759.tif 000017