JP5650197B2 - マルチキャスト配信を通じてメディアを提供するシステムのための方法及び装置 - Google Patents

Description

本発明はマルチキャスト配信を通じたメディアの提供に関し、特にはスケーラブルな高速チャネル変更のための方法及び装置に関する。

今日のIPTVソリューションはチャンネル切換の時間が長い。つまり、エンドユーザがチャンネルをリモコンで変えてから、選択されたチャンネルの音声及び映像がＴＶ画面に現われるまでに時間がかかる。この遅延の原因は多いが、画質と要求される帯域とのバランスを得るために用いられる符号化技術が主な原因である。

最も一般的に用いられている符号化技術はMPEG2及びMPEG4である。これら技術はいずれも、符号化器が、Ｉフレームと呼ばれる完全な画像を定期的に送信し、Ｉフレームの間に、Ｂ及びＰフレームと呼ばれる、Ｉフレームから画像がどのように変化したかを記述する２種類の不完全な画像を送信する符号化手法を用いている。Ｐ及びＢフレームは対応するＩフレームなしには復号できない。Ｉフレームは送信するために多くの帯域を必要とする多数の情報を含んでいるため、Ｉフレームの間隔が長くなるほど、必要な全体の帯域が小さくなる。しかし、ＴＶやセットボックスにおける符号化器は、Ｉフレームを受信するまで復号を開始しないので、Ｉフレームの間隔（ＧＯＰ長（ピクチャグループ長）と呼ばれる）を延ばすと、平均復号遅延がより長くなる。統計的にはこの遅延は平均してＧＯＰ長の半分となるであろう。通常、符号化されたコンテンツは、同一のストリームを多数のユーザが共有可能なマルチキャストストリームとして送信され、それによってアクセスネットワークにおける帯域を節約している。

例えば米国特許出願公開2005/0081244A1に記載されるような従来技術においては、VQE（Video Quality Experience）サーバと呼ばれるバッファノードを形成することによって遅延を削減している。このVQEサーバは利用可能な全てのチャンネルからパケットを取得し、直近のＮ秒間の全パケットを保持しながら各チャンネル用の個別巡回バッファを維持する。バッファされるチャンネルは常にＩフレームで開始する。チャンネル要求があると、VQEサーバのバッファから、要求されたチャンネルの適切なメタデータとＩフレームを有するユニキャストストリームがクライアントに送信されるであろう。クライアントの復号器はVQEサーバのバッファからのユニキャストストリーム内のＩフレームを受信すると直ちに、コンテンツのバッファリングと復号を開始するであろう。チャンネルはVQEサーバ内にバッファされているので、チャンネルのタイミングは通常のマルチキャストストリームのタイミングより遅れている。従って、このユニキャストストリームは、通常のマルチキャストストリームに追いつくまで送信されるであろう。ユニキャストストリームが通常のマルチキャストストリームに追いつくと、クライアントはユニキャストコネクションを切断し、通常のマルチキャストストリームからコンテンツの受信を開始するであろう。

従来技術の主な問題は、秒あたりの帯域とサービスを受ける要求にスケーラビリティがないことである。個々のクライアント要求に対してVQEサーバから１つのユニキャストストリームが送信されることになるため、サービスを提供することの可能な同時要求数はアクセスネットワーク内で利用可能な帯域によって厳しく制限され、VQEサーバの出方向ポート上の利用可能帯域が主なボトルネックとなる。

上述した方法に関する別の問題は、穏やかな劣化(graceful degradation)の欠如である。すなわち高負荷状況においては新たな要求が拒否され、その結果高速なチャンネル変更が提供されず、非常に悪いエンドユーザ体験を与えてしまう。この問題を解決するための１つの考えられる方法は、例えばより多くのVQEサーバを追加することによってハードウェアを追加することである。残念ながら、この方法は必ずしも価格が手ごろとは限らない。

本発明の目的は、例えばIPTVシステム用の、スケーラブルな高速チャンネル切り替え手法を提供することにある。

この目的は、要求されたチャンネルを読み出すソースを、FCCサーバの現在の負荷に基づいて選択する本発明の実施形態によって達成される。一例として、要求されたチャネルは、通常のマルチキャストストリームを提供するストリーミングサーバか、要求されたチャネルのバッファ版を提供するFCCサーバのバッファから読み出すことができ、バッファ版はストリーミングサーバの元のストリームがトランスコード及び遅延されたものであってよい。

一実施形態によれば、高速チャンネル切り替え（同一チャンネルに関するもの）がグループ化され、マルチキャスト上で一括して扱われる。そのようにすることで、複数のクライアントが同一のストリームを共有できるので、FCCサーバ及びネットワークの負荷を軽減することができる。

従って、本発明の第１の見地によれば、FCCサーバにおける方法が提供される。FCCサーバは、ストリーミングサーバからマルチキャスト配信を通じて送信されるメディアを配信するチャンネルの変更を処理する。この方法において、クライアントから、第１のチャンネルから第２のチャンネルへのチャンネル変更の要求が受信される。FCCサーバに関する負荷が判定され、判定された負荷に基づいて、第２のチャンネルを読み出すためのソースが判定される。従って、応答メッセージは選択されたソースから第２のチャンネルを読み出すために送信される。

本発明の第２の見地によれば、FCCサーバが提供される。FCCサーバは第１のチャンネルから第２のチャンネルへのチャンネル変更の要求をクライアントから受信する受信器と、FCCサーバに関する負荷を判定するとともに、第２のチャンネルを読み出すためのソースを判定された負荷に基づいて選択するプロセッサとを有する。また、選択されたソースから第２のチャンネルを読み出すための応答メッセージを送信する送信器がさらに含まれる。

本発明の第３の見地によれば、IPTVネットワークのクライアントにおける方法が提供される。クライアントは、ストリーミングサーバからマルチキャスト配信を通じて送信されるメディアを配信するチャンネルの変更を要求する。この方法において、第１のチャンネルから第２のチャンネルへのチャンネル変更の要求がFCCサーバに送信される。FCCサーバから応答メッセージが受信され、要求した第２のチャンネルを受信すべきソースの情報をクライアントが受信できるよう、応答メッセージが解釈される。ソースはFCCによって、負荷に応じて選択される。

本発明の第４の見地によれば、IPTVネットワークのクライアントが提供される。クライアントはストリーミングサーバからマルチキャスト配信を通じて送信されるメディアを配信するチャンネルの変更を要求し、従って第１のチャンネルから第２のチャンネルへのチャンネル変更の要求をFCCサーバに送信する送信器を有する。さらに、FCCサーバから応答メッセージを受信する受信器が設けられる。処理ユニットは、要求した第２のチャンネルを受信すべきソースの情報を受信できるように、応答メッセージを解釈する。ここで、ソースはFCCサーバによって負荷に応じて選択される。

負荷が低い場合、本発明に基づくシステムは現状の方法と同程度の速さで応答するであろう。

負荷がより高くなると、本発明に基づくシステムは、複数の要求をまとめてグループ化する小さな遅延を導入することで帯域を保護する。導入される遅延はGOP長によって与えられる平均遅延よりも遙かに短く、従ってシステムは従来技術の方法と比較して改善された性能を提供するであろう。

最悪の場合、つまり負荷が非常に高い場合、本発明に基づくシステムは本発明を含まないもののように振る舞うであろう。すなわち、チャンネル切り替え時間は、FCCサーバを有さないシステムと同一となるであろう。そのような方法の一例は、チャンネル変更要求が急激に混み合った状態である。

本発明の実施形態による利点は、帯域要求が非常にうまく変化することである。帯域要求は、負荷が増加するに従って、予め定められた閾値まで増加するであろう。負荷が閾値を超えると、帯域要求は負荷が増加するに従って減少するであろう。そして、最大負荷の状態（例えば、多数の人々が同じチャンネルを同時に変更しているような、急激な混雑の場合）では、ただ１つのマルチキャストストリームだけになるであろう。

従って、本発明の実施形態に基づくシステムは、穏やかな劣化を提供するであろう。チャンネル切り替え時間はシステム負荷の増加とともに緩やかに増加するが、本発明を実施しないシステムにおける最長時間を超えることは決してない。さらに、全てのクライアントがその時間内に処理されるであろう。

本発明の実施形態が実装されたIPTVシステムを示す図である。 本発明の実施形態が実装されたIPTVシステムを示す図である。 本発明の実施形態が実装されたIPTVシステムを示す図である。 本発明の実施形態のシーケンス図である。 本発明の実施形態のシーケンス図である。 本発明の実施形態のシーケンス図である。 本発明の実施形態に係る装置を示す図である。 本発明の実施形態に係るFCCサーバにおける方法のフローチャートである。 本発明の実施形態に係るFCCサーバにおける方法のフローチャートである。 本発明の実施形態に係るFCCサーバ負荷と閾値との関係を示す図である。 本発明の実施形態に係るクライアントを模式的に示す図である。 本発明の実施形態に係るクライアントにおける方法のフローチャートである。

以下、本発明の好ましい実施形態が示される添付図面を参照して、本発明をより詳細に説明する。しかし、本発明は、様々な形態で実施可能であり、ここで説明する実施形態に限定されるものと解釈されるべきではない。むしろ、これら実施形態は本明細書の開示が十分且つ完全となるように、そして本発明の範囲が本技術分野の当業者に十分伝わるように提供されるものである。図において、同様の参照数字は同様の要素を示す。

さらに、本技術分野に属する当業者は、以下に説明する手段及び機能が、プログラムされたマイクロプロセッサ又は汎用コンピュータとともにソフトウェア機能を用いて、及び／又は特定用途向け集積回路(ASIC)を用いて実施されて良いことを理解するであろう。さらに、本発明を方法及び装置の形態で主に説明するが、本発明はコンピュータプログラムや、コンピュータプロセッサと、ここで説明する機能を実行しうる１つ以上のプログラムが設けられ、プロセッサに接続されたメモリとを有するシステムにおいても実施することができることが理解されるであろう。

実施形態では一貫してIPTVシステムに関して説明される。しかし、本発明はIPTVに限定されず、サーバからのデータ群の中から大量のデータの一部をクライアント群が要求するような全ての実施形態に対して適用可能である。そのようなシステムの一例はOSのパッチ配信である。

図１ａは、本発明を適用可能なＩＰＴＶシステムを模式的に示している。クライアント１００はアクセスノード１３０を介してゲートウェイ１４０に接続されている。クライアント１００はセットトップボックス１２０及び住居ゲートウェイ又はホームネットワークゲートウェイ１１０を有する。IPネットワークは例えば複数のルータを有し、エッジルータ１５０から、メディアコンテンツ（例えば複数のTVチャンネル）を提供するストリーミングサーバ１７０がIPネットワーク１４０に接続されている。ストリーミングサーバに加え、高速チャンネル変更(FCC)サーバ１６０が例えばエッジルータを介してIPネットワークに接続されている。FCCサーバ１６０はチャンネル変更要求を管理し、例えば通常のマルチキャスト通信を通じて送信される複数のTVチャンネルである複数のメディアストリームをバッファリングするためのバッファが関連付けられている。メディアストリームはバッファリングされるので、バッファに保存されているメディアストリームのタイミングは通常のマルチキャストストリームのメディアストリームのタイミングよりも遅れているであろう。FCCサーバは、ストリーミングサーバから通常のマルチキャストストリームを用いて送信されるメディアストリームのレートより速いレートでクライアントデコーディングバッファを満たさなければならない。さらに、バッファリングされたメディアストリームの各々は、高速な復号が可能なようにIフレームで開始する。ストリーミングサーバはコンテンツプロバイダに配置されてよい。TVチャンネルのメディアストリームはIPネットワーク１４０のルータ１５０及びアクセスノード１３０を介し、マルチキャスト配信によってクライアントに提供される。このマルチキャスト配信を、正規(regular)マルチキャスト配信と呼ぶ。

図４に示すように、本発明の実施形態によれば、FCC４００はクライアントの送信器から、第１のチャンネルから第２のチャンネルへのチャンネル変更の要求を受信するための受信器４０２を有している。FCCサーバのプロセッサ４０４はその要求を評価し、FCCサーバに関する負荷を判定するように構成されている。判定した負荷に基づいて、プロセッサ４０４は第２のチャンネルを読み出すためのソース及び配信方法（ユニキャスト又はマルチキャスト）を選択する。すなわち、FCCサーバはクライアントの受信器に、要求されたチャンネルをクライアントが読み出し可能なアドレスを含んだメッセージによって応答するであろう。負荷は、FCCサーバが現在処理している要求の数や、FCCサーバの利用可能帯域に基づいて判定することができる。さらに、ソースはFCCサーバのバッファ４０８であっても、例えば正規マルチキャストストリームを提供するストリーミングサーバであってもよい。FCCサーバはさらに、選択されたソースから第２のチャンネルを読み出させるためにクライアントに応答するための送信器４０６を有する。

従って、図６に示すように、クライアント６００は第１のチャンネルから第２のチャンネルへのチャンネル変更の要求６０４をFCCサーバに送信するための送信器６０１を有している。あるいは、この要求６０４はさらに、このクライアントがリダイレクトコマンドを受信可能であることをＦＣＣサーバに知らせてもよい。さらに、クライアント６００は、FCCサーバから受信器６０３が受信した応答メッセージ６０５を解釈するように構成された処理部６０２を有する。応答メッセージ６０５はIPリダイレクトコマンドを有することができ、その場合クライアントは、要求したチャンネルを受信するためにどのマルチキャストIPアドレスに参加すべきなんかを通知される。IPアドレスは要求されたチャンネルに対する専用IPアドレスであっても、IPアドレスのプールから選択されたものであってもよい。この場合、所定時間時間がシフトされた、要求されたチャンネルのコピーが各IPアドレス上で送信される。

図１ａは、選択されたソースが、正規マルチキャストストリーミングを介してメディアを提供するストリーミングサーバである場合のシナリオを示している。このソースは負荷が高いことが検出された場合に選択される。

図１ｂ及び図１ｃは、選択されたソースがFCCサーバに関連付けられたバッファである場合のシナリオを示している。バッファはFCCサーバ内に位置していてもよいし、FCCサーバに接続された別個のノードであってもよい。バッファリングされたTVチャンネルはユニキャスト又はマルチキャストを介してクライアントに送信されてよい。ユニキャスト又はマルチキャストの選択の決定は、各要求ごとに個別に実施され、FCCサーバの負荷に依存してもよい。図１ｂは、バッファリングされたTVチャンネルがユニキャストを介して送信される場合を、図１ｃはバッファリングされたTVチャンネルがマルチキャストを通じて送信される場合をそれぞれ示している。これら２つの代替物は図２ａ、２ｂ，及び３とともに以下でさらに説明する。

低負荷状況においては、要求されたTVチャンネルをユニキャストで送信するためのリソースは十分存在するであろう。FCCサーバは、自身の負荷が低いと判別される場合、例えば、少数のチャンネル要求が受信されている場合には、図２ｂに示すように、バッファリングされたコンテンツを、FCCサーバでRequest FCCメッセージが受信された後で、クライアントへ直接ストリーミングし始めてもよい。あるいはFCCサーバは、図２ａに示すように、FCCサーバに関連付けられたバッファへのアドレスを含んだメッセージを送信してもよい。負荷状況を判定するための前提条件の例は、FCCサーバ内の利用可能メモリ、FCCサーバ上で利用可能な帯域、サービスを提供しているクライアントの数などを含む。バッファリングされたメディアをユニキャストで送信する場合と、割り当てられたマルチキャストで送信する場合の両方で同一のバッファを用いることができることに留意されたい。本明細書において、割り当てられたマルチキャストは、FCCサーバに関連付けられたバッファからの、メディアストリームのバッファ版のマルチキャスト送信を暗示する。例えば、バッファはユニキャストストリームを用いて１つのクライアントにサービスを提供することができ、また同じバッファから他の複数のクライアントにコンテンツをマルチキャストストリームとして送信し始めてもよい。

低負荷状況におけるユニキャストシナリオを図２ａのシーケンス図に示す。クライアントは２０１で、チャネル変更要求をFCCサーバに送信する。FCCサーバは、自身が低負荷状況にあることを判定し、チャンネル変更はユニキャストを通じて提供されるであろう。２０２でFCCサーバは、ユニキャスト送信を提供するノード（例えばこの場合FCCサーバのバッファ）へのアドレスを有する、クライアントへのメッセージを送信する。２０３でクライアントはメッセージを解釈し、受信したメッセージに示されたFCCサーバのバッファにメディアストリームを要求する。２０４で、要求されたメディアはFCCサーバのバッファから、バッファが空になるまでクライアントに配信され、そしてバッファからのメディアストリームが、ストリーミングサーバからの正規マルチキャストストリームに同期される。同期が完了すると、クライアントはストリーミングサーバからの正規マルチキャストストリームに参加するため、ユニキャストストリームから離れる。

上述の例より負荷がいくぶん高いか、負荷が増加しようとしているとの通知を受信した場合、本発明の実施形態によってさらなる戦略が導入される。

この戦略の基本的なアイデアは、上述したように、所定の（短い）時間ウインドウの間、ある特定のチャンネルを要求している全てのクライアントによって共有されるであろうマルチキャストアドレスによって応答することにより、同一チャンネルについての要求をグループ化することである。各クライアントはこの応答を、マルチキャストストリームに参加し、ストリームを待つことを要求するものと解釈するであろう。時間ウインドウが経過すると、FCCサーバはバッファリングされたコンテンツの送信を開始するであろう。時間ウインドウは、FCCサーバ負荷が十分高いと判別されるか、FCCサーバ負荷が増加中であるという通知が受信されていると判別されていることを条件として、特定のチャンネルに対する第１の要求が受信された際に始まるであろう。同一マルチキャストストリームをいくつかのクライアントが共有するようになるので、マルチキャストストリームを共有するクライアントの数が増えるほど必要な帯域は減少するであろう。この戦略は、正規マルチキャストとは対照的に、割り当てられたマルチキャストと呼ぶ。

クライアント１００はチャンネル変更に対する要求を生成するエンティティである。クライアントはSTB自身であっても、RGW又はDSLAMであってもよい。例えば、（例えばFCCサーバに高速チャンネル変更を要求するとともに、FCCサーバからのメッセージを解釈してそれによって振る舞う能力を有する、FCCサーバと通信する機能によって拡張されたIGMPプロキシである。拡張された機能はまた、割り当てられたマルチキャストから正規のマルチキャストへの同期を暗示してもよい。IGMPプロキシの場合において、STBはFCCサーバハンドリングを処理可能である必要はなく、代わりに全てのFCCハンドリングが拡張されたIGMPプロキシによって処理されてよい。

図３は、本発明の実施形態に係る、FCCサーバ負荷が所定の閾値を超える場合の要求のグループ化を説明するシーケンス図である。複数のクライアント、例えばクライアント１及びクライアントNは、”ABC”と示される特定のチャンネルについてのチャンネル変更要求３０１，３０３をFCCサーバに送信する。これらのチャンネル変更要求は図６において６０４で示される要求に対応している。受信した要求の各々に応答して、FCCサーバは３０２，３０４で、チャンネル変更が、FCCサーバのバッファからのマルチキャスト送信であろうアドレス225.0.1.1のマルチキャストを通じて提供されるであろうことをクライアントに応答する。なお、この応答３０２，３０４は図６において６０５で示される応答メッセージに対応するものであることに留意されたい。同一チャンネルが要求されていることは、その要求元が同一の割り当てられたマルチキャストを共有可能であることを暗示しているので、チャンネル変更要求３０１，３０３は３０５でグループ化されてよい。クライアントが応答を受信し、その応答から自身がマルチキャストアドレスにリダイレクトされなければならないことを解釈すると、クライアントはIGMP REPORTコマンド（以下単にJOINコマンドと呼ぶ）３０６，３０７をそのマルチキャストアドレスに送信する。図３に示すケースにおいては、バッファリングされたマルチメディアストリームがFCCサーバのバッファから配信されるので、マルチキャストアドレス225.0.0.1はFCCサーバをそのソースとして有する。スケーラブルな解決方法を達成するために、すなわち同一チャンネルのより多くの要求をグループ化できるようにするために、本発明の実施形態によれば、FCCサーバは、要求されたメディアを割り当てられたマルチキャストを通じて３０８で送信するまで所定時間３３０待機する。所定時間待機できるようにするため、FCCサーバの負荷が所定の閾値を超えていると判断されていることを条件として、最初のチャンネル要求３０１が受信された際にタイマを開始させることができる。

例えば、50msもしくはGOP長よりもずっと短い時間内に到来した、ある所定のチャンネル（例えばチャンネル”ABC”）に対する全ての要求が、グループ化されるであろう。クライアントはFCCサーバから、コンテンツの配信に用いられるであろうマルチキャストチャンネルを示すメッセージを受信するであろう。全てのクライアントが行う必要があるであろうことは、そのマルチキャストチャンネルに参加し、コンテンツの受信を待機することである。FCCサーバ上の負荷が増加している場合、FCCサーバは負荷が増加するにつれて線形的に時間ウインドウを増加させるであろう方式を採用してもよい。

そして、各クライアントへのマルチキャストストリームは、３０９でバッファが空になると、正規マルチキャストストリームと個別に同期が取られる。３１４で同期が実現されると、３１１，３１３でクライアントは割り当てられたマルチキャストを離れ、３１０，３１２で正規マルチキャストに参加する。

負荷が非常に高い場合、すなわちFCCサーバ上で利用可能な帯域が少ない場合、サーバはクライアントに対し、図１ａに示したように、正規マルチキャストストリームを用いるように伝える応答を行うであろう。従って、FCCサーバ又は帯域にそれ以上の負荷が追加されることはないであろう。この場合、クライアントにおけるチャンネル変更時間は、FCC機能を持たないシステムと同等になるであろう。

従って、本発明は、FCCサーバの現在の負荷に従って新たなチャンネルについての要求を処理する手法を提供する。FCCサーバの負荷が低い場合、要求はユニキャストによって個別に処理されてよい。しかし、サーバにおける負荷が上昇を始めた場合もしくは負荷が所定の閾値を超えている場合、新たな動作モードが導入される。その動作モードにおいて、クライアントの要求はまとめてグループ化され、１つのグループとして取り扱われるであろう。要求がグループ化される際、それらはいくつかのユニキャストコネクションより遙かにスケーラブルな、一意に割り当てられたマルチキャスト上で処理されてよい。

本発明の実施形態に係る方法が、図５ａ，５ｂ，及び６のフローチャートに示されている。

第１の見地によれば、方法は、ストリーミングサーバからのマルチキャスト配信を通じて送信されるメディアを配信する複数チャンネルのチャンネル変更を処理するためのFCCサーバで実施される。方法は以下のステップを有する。
５０１． クライアントから、第１のチャンネルから第２のチャンネルへのチャンネル変更の要求を受信する。
５０２． FCCサーバに関する負荷を判定する。
５０３． 判定された負荷に基づき、第２のチャンネルを読み出すためのソースを選択する。
５０４． 選択されたソースから第２のチャンネルを読み出すための応答メッセージを送信する。

一実施形態によれば、ソースを選択するステップ５０３は、さらに以下のステップを有する。
５０３ａ．判定された負荷が第１の所定の閾値（高い閾値とも呼ぶ）未満であれば、第２のチャンネルのバッファ版を（ユニキャスト又は割り当てられたマルチキャストのいずれかによって）配信するソースを選択する。
５０３ｂ．判定された負荷が高い閾値以上であれば、マルチキャスト配信を通じて第２のチャンネルを配信するためのソースとして、ストリーミングサーバを選択する。

さらに、上述したように、FCCサーバの負荷に応じて、第２のチャンネルのバッファ版がユニキャスト又は割り当てられたマルチキャストのいずれかによって送信されてもよい。従って、以下のステップが実行されてもよい。
５０３ａ１． 判定された負荷が第２の所定の閾値（低い閾値とも呼ぶ）未満であれば、FCCサーバに関連付けられたバッファからユニキャストによって第２のチャンネルのバッファ版を配信するソースを選択する。
５０３ａ２． 判定された負荷が低い閾値以上高い閾値未満であるか、負荷が増加中であることが示されている場合には、FCCサーバに関連付けられたバッファからマルチキャストによって第２のチャンネルのバッファ版を配信するソースを選択する。さらに、同一チャンネルについての更なる要求をグループ化できるように、バッファは、要求された第２のチャンネルのクライアントへの送信を所定時間遅らせるように要求される。

第２の見地によれば、方法は図７のフローチャートに従ってクライアントで実施される。
方法は以下のステップを有する。
７０１． 第１のチャンネルから第２のチャンネルへのチャンネル変更の要求をFCCサーバに送信する。
７０２． FCCサーバから応答メッセージを受信する。
７０３． 要求した第２のチャンネルを受信すべきソースの情報を受信できるよう、応答メッセージを解釈する。ここで、ソースはFCCサーバによって負荷に応じて選択される。

上述したように、応答メッセージはマルチキャストアドレスへのリダイレクトコマンドを有するように解釈されてもよく、方法はさらに以下のステップを有する。
７０４． リダイレクトコマンドに示されたマルチキャストアドレスに参加する。

第１の（高い）閾値と、第２の（低い）閾値と、FCCサーバ負荷との関係を、図５ｃに模式的に示す。図５ｃは、第２の（低い）閾値未満であればユニキャストが用いられ、第２の（低い）閾値を超えるが第１の（高い）閾値未満であれば割り当てられたマルチキャストが用いられ、第１の（高い）閾値を超えていれば正規マルチキャストが用いられることを示している。従って、バッファリングされたストリームは、第１の（高い）閾値未満において用いられる。

FCCサーバが入来する制御メッセージ（すなわち要求メッセージ）を処理することができない状況では、タイムアウトの仕組みをクライアントで用いることができる。タイムアウトが発生した場合、クライアントは正規マルチキャストに参加し、それによってFCCサーバを解放するであろう。

メディアストリームをIフレームからバッファリングするバッファがFCCサーバに配置されているが、バッファはFCCサーバに接続された他のノードに配置されていてもよいことが理解されよう。そしてFCCサーバは、例えばリダイレクトメッセージにおいて、クライアントにそのノードからバッファリングされたメディアを読み出すように応答し、チャンネル変更要求への応答にそのノードを示すアドレスを含めるであろう。

本発明は上述した好適な実施形態に限定されない。様々な代替物、変形物及び等価物を用いることができる。従って、上述した実施形態は、特許請求の範囲によって規定される本発明の範囲を限定するものとして解釈されるべきでない。

Claims (21)

1. ストリーミングサーバからマルチキャスト配信を通じて送信されるメディアを配信するチャンネルのチャンネル変更を処理するための、高速チャンネル変更(FCC)サーバにおける方法であって、
   -第１のチャンネルから第２のチャンネルへのチャンネル変更要求を受信するステップ(501)と、
   -前記FCCサーバに関する負荷を判定するステップ(502)と、
   -前記判定された負荷に基づいて、前記第２のチャンネルを読み出すためのソースを選択するステップ(503)と、
   -前記選択されたソースから前記第２のチャンネルを読み出すための応答を送信するステップ(504)と、を有することを特徴とする方法。
2. 前記ソースを選択するステップ(503)が、
   -前記判定された負荷が第１の予め定められた閾値未満である場合に、前記第２のチャンネルのバッファ版を配信するソースを選択するステップ(503a)と、
   -前記判定された負荷が前記第１の予め定められた閾値以上である場合に、マルチキャスト配信を通じて前記第２のチャンネルを配信するための前記ソースとして前記ストリーミングサーバを選択するステップ(503b)と、を有することを特徴とする請求項１記載の方法。
3. 前記第２のチャンネルのバッファ版が前記FCCサーバに関連付けられたバッファからユニキャストによって配信されることを特徴とする請求項２記載の方法。
4. 前記第２のチャンネルのバッファ版が前記FCCサーバに関連付けられたバッファからマルチキャストによって配信されることを特徴とする請求項２記載の方法。
5. 前記第２のチャンネルのバッファ版を配信するソースを選択するステップ(503a)が、
   -前記判定された負荷が第２の予め定められた閾値未満である場合に、前記FCCサーバに関連付けられたバッファからユニキャストによって前記第２のチャンネルのバッファ版を配信するソースを選択するステップ(503a1)と、
   -前記判定された負荷が第２の予め定められた閾値以上であるか、前記負荷が増加中であることが示される場合に、前記FCCサーバに関連付けられたバッファからマルチキャストによって前記第２のチャンネルのバッファ版を配信するソースを選択するステップ(503a2)と、を有することを特徴とする請求項２記載の方法。
6. 前記FCCサーバに関連付けられたバッファからマルチキャストによって前記第２のチャンネルのバッファ版を配信するソースを選択するステップ(503a2)が、
   -前記バッファに、前記要求された第２のチャンネルをクライアントに送信するのを所定時間遅らせるよう要求するステップ(503a3)、をさらに有することを特徴とする請求項５記載の方法。
7. 前記負荷が、受信したチャンネル変更要求の数に関連するものであることを特徴とする請求項１乃至請求項６のいずれか１項に記載の方法。
8. 前記負荷が前記FCCサーバの利用可能帯域に関するものであることを特徴とする請求項１乃至請求項７のいずれか１項に記載の方法。
9. ストリーミングサーバ(410)からマルチキャスト配信を通じて送信されるメディアを配信するチャンネルのチャンネル変更を処理するための高速チャンネル変更(FCC)サーバ(400)であって、第１のチャンネルから第２のチャンネルへのチャンネル変更要求を受信する受信器(402)と、前記FCCサーバに関する負荷を判定し、前記第２のチャンネルを読み出すためのソースを前記判定された負荷に基づいて選択するプロセッサ(404)と、クライアントが前記選択されたソースから前記第２のチャンネルを読み出すための応答を送信する送信器(406)と、を有することを特徴とするFCCサーバ(400)。
10. 前記プロセッサ(404)がさらに、前記判定された負荷が第１の予め定められた閾値未満である場合には、前記第２のチャンネルのバッファ版を配信するソースを選択し、前記判定された負荷が第１の予め定められた閾値以上である場合には、前記第２のチャンネルをマルチキャスト配信を通じて配信するソースとして前記ストリーミングサーバを選択するように構成されることを特徴とする請求項９記載のFCCサーバ(400)。
11. 前記FCCサーバが、前記FCCサーバに関連付けられたバッファに、前記第２のチャンネルのバッファ版をユニキャストによって配信するように要求するように構成されることを特徴とする請求項１０記載のFCCサーバ(400)。
12. 前記FCCサーバが、前記FCCサーバに関連付けられたバッファに、前記第２のチャンネルのバッファ版をマルチキャストによって配信するように要求するように構成されることを特徴とする請求項１０記載のFCCサーバ(400)。
13. 前記プロセッサ(404)がさらに、前記判定された負荷が第２の予め定められた閾値未満である場合は、前記FCCサーバに関連付けられたバッファからユニキャストによって前記第２のチャンネルのバッファ版を配信するソースを選択し、前記判定された負荷が第２の予め定められた閾値以上であるか、前記負荷が増加中であることが示される場合は、前記FCCサーバに関連付けられたバッファからマルチキャストによって前記第２のチャンネルのバッファ版を配信するソースを選択するように構成されることを特徴とする請求項１０記載のFCCサーバ(400)。
14. 前記プロセッサ(404)がさらに、クライアントへの前記要求された前記第２のチャンネルの送信を所定時間遅らせるよう前記バッファに要求するように構成されることを特徴とする請求項１３記載のFCCサーバ(400)。
15. 前記負荷が、受信したチャンネル変更要求の数に関連するものであることを特徴とする請求項９乃至請求項１４のいずれか１項に記載のFCCサーバ(400)。
16. 前記負荷が、前記FCCサーバの利用可能帯域に関連するものであることを特徴とする請求項９乃至請求項１４のいずれか１項に記載のFCCサーバ(400)。
17. ストリーミングサーバからマルチキャスト配信を通じて送信されるメディアを配信するチャンネルのチャンネル変更を行うための、IPTVネットワークのクライアントにおける方法であって、
    -第１のチャンネルから第２のチャンネルへのチャンネル変更要求をFCCサーバに送信するステップ(701)と、
    -前記FCCサーバから応答メッセージを受信するステップ(702)と、
    -前記要求した第２のチャンネルを受信すべきソースの情報を受信できるように、前記応答メッセージを解釈するステップ(703)とを有し、前記ソースが負荷に応じて前記FCCサーバによって選択されることを特徴とする方法。
18. 前記応答メッセージが、マルチキャストアドレスへのリダイレクトコマンドを含むように解釈され、前記方法がさらに、
    -前記リダイレクトコマンドに示される前記マルチキャストアドレスに参加するステップ(704)を有することを特徴とする請求項１７記載の方法。
19. 前記応答メッセージが、前記第２のチャンネルをどこから読み出すべきかを示すIPアドレスを有することを特徴とする請求項１７又は請求項１８に記載の方法。
20. ストリーミングサーバからマルチキャスト配信を通じて送信されるメディアを配信するチャンネルのチャンネル変更を行うための、IPTVネットワークのクライアントであって、第１のチャンネルから第２のチャンネルへのチャンネル変更要求(604)をFCCサーバに送信する送信器(601)と、前記FCCサーバから応答メッセージ(605)を受信する受信器(603)と、前記要求した第２のチャンネルを受信すべきソースの情報を受信できるように、前記応答メッセージを解釈する処理ユニット(602)とを有し、前記ソースが負荷に応じて前記FCCサーバによって選択されることを特徴とするクライアント。
21. 前記処理ユニット(602)が、前記応答メッセージを、マルチキャストアドレスへのリダイレクトコマンドを含むように解釈し、前記送信器(601)が、前記リダイレクトコマンドに示される前記マルチキャストアドレスに参加するための要求を送信するように構成されることを特徴とする請求項２０記載のクライアント。

Images