JP2015527801A - データストリームをブロードキャストする少なくとも１つのサービスおよび少なくとも２つの端末を含むシステムにおいてデータストリームを割り当てる方法 - Google Patents

Abstract

本発明は、ブロードキャスティング・データストリームの少なくとも１つのサービスと、少なくとも１つのサーバと、少なくとも２つの端末とを含むシステムにおいてデータストリームを割り当てる方法に関する。この少なくとも２つの端末のうちの１つの端末は、少なくとも２つの異なるソースから同一のプログラムを受信可能である。この方法は、上記サーバによって、少なくとも１つの第１の端末によって送信されるメッセージを受信するステップであって、上記メッセージは、第１の端末がソースを識別した、リクエストによって求められた第１のプログラムと呼ばれるプログラムのデータストリームを受信できないことを示す情報を含む、この受信するステップと、上記サーバによって、上記複数の端末に対するプログラムの送信および上記リクエストの送信の間に上記ストリームの複数のソースのアービトレーションを行うステップと、上記第１の端末の第１のプログラムを求めるリクエストに応じるために、ブロードキャスティング・サービスが第２のプログラムと呼ばれるプログラムをブロードキャストする対象である少なくとも第２の端末に対してソースの変更を通知するステップと、を含む。【選択図】図１

Description

本発明は、帯域幅を共有する複数の端末を相互接続するネットワーク上でのプログラムまたはデータの受信に関する。より具体的には、本発明は、受信端末によるマルチメディアの選択に対してアービトレーションを行う方法に関する。

本発明は、限定するものではないが、特に、テレビジョンの領域に関し、より具体的には、ＩＰＴＶ（“Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｔｅｌｅｖｉｓｉｏｎ”「インターネット・プロトコル・テレビジョン」）および加入者のディジタル回線（「ｘＤＳＬ（ＤＳＬは、ディジタル加入者回線（Ｄｉｇｉｔａｌ Ｓｕｂｓｃｒｉｂｅｒ Ｌｉｎｅ）を指す）」上で利用可能な帯域幅の制約に関わるチャンネルの選択に関する。

十分な帯域幅が確保されていないチャンネルを表示する必要に応ずるため、ハイブリッド端末の登場により、上記制約が克服できるようになっている。

ＩＰＴＶネットワークにおいては、端末が、ローカル・ネットワークおよびゲートウェイを介して、ｘＤＳＬとも呼ばれる加入者のディジタル回線に接続される。ビデオ・ストリームを受信できるかどうかは、ｘＤＳＬ回線上で利用可能な帯域幅に依存する。一方では、ローカル・ネットワーク上に受信端末が複数存在することによって帯域幅に対する要求が増大し、他方では、高解像度（ＨＤ）ストリームによって要求されるビットレートの増加により、時折、ユーザによって選択されるストリームの端末への配信が阻止されることがある。

従来技術によれば、利用可能な帯域幅が不十分である場合にストリームが要求されている間におけるコンフリクトの解決を試行するために、ローカル・ネットワークに関わる機器内で幾つかの解決法が実施されている。第１の解決法は、受信端末内で、帯域幅が不十分である場合に、低品質でのサービス・プランにおいて選択されたチャンネルが、例えば、高解像度から標準解像度に移行することを求め、そして、解決法が存在しない場合のエラー・メッセージを提供することである。この機器内部の解決法は、ローカル・ネットワークの他の機器の状態を考慮していない。ＩＰ受信手段を内蔵し、さらに、地上ディジタルテレビ放送（ＤＴＴ：Ｄｉｇｉｔａｌ Ｔｅｒｒｅｓｔｒｉａｌ Ｔｅｌｅｖｉｓｉｏｎ）チューナーなどの他のタイプの受信手段を内蔵したハイブリッド機器も開発されている。これらの手段は、ｘＤＳＬ回線上の帯域幅が不十分である場合のＤＴＴサービス・プランによる代替的な解決法を提供するものである。しかしながら、この解決法は、全てのコンフリクトを解決するものではなく、ＩＰサービス・プランおよびＤＴＴサービス・プランの双方において利用可能なチャンネルに制限されている。この解決法は、ＤＴＴネットワークにおいて利用可能なチャンネルの数が少ないため、制限されている。ローカル・ネットワーク上で使用される相互運用可能な受信端末に基づく別の解決法も存在する。端末のうちの１つは、管理システムを統合している。ベース端末として識別されるこの端末の目的は、標準的な端末内部でコンフリクトを管理することにある。コンフリクトが存在する状況においては、インタフェースを通じて情報が提供されたユーザは、提案された複数の解決法のリストを用いてコンフリクトを解決しなければならない。

したがって、コンフリクトの解決に関わることがユーザに求められる。

本発明は、帯域幅が不十分である場合のチャンネルの選択によって生じたコンフリクトを処理する方法によって、従来技術の不都合の少なくとも１つを克服することを提案する。

本発明の目的は、複数の異なる端末によって行われるリクエスト間で、サーバによって行われるアービトレーションの自動化された、トランスペアレントな方法であり、利用可能なソースは、リクエストされたプログラムを配信し、プログラムを配信可能であるかどうかを伝達する。このアービトレーションの結果として、クライアント側のローカル・ネットワーク上の端末のためのソースが変更されることがある。

この目的のため、本発明は、ブロードキャスティング・データストリームの少なくとも１つのサービスと、少なくとも１つのサーバと、少なくとも２つの端末からなる複数の端末を含むシステムにおいてデータストリームを割り当てる方法であって、上記少なくとも２つの端末のうちの１つの端末が少なくとも２つの異なるソースから同一のプログラムを受信可能である、この方法に関する。

本発明によれば、この方法は、
上記サーバによって、少なくとも１つの第１の端末によって送信されるメッセージを受信するステップであって、上記メッセージは、上記第１の端末がソースを識別した、リクエストによって求められた第１のプログラムと呼ばれるプログラムのデータストリームを受信できないことを示す情報を含む、この受信するステップと、
上記サーバによって、上記端末に対するプログラムの送信および上記リクエストの送信の間に上記ストリームの複数のソースのアービトレーションを行うステップと、
上記第１の端末の上記第１のプログラムを求めるリクエストに応じるために、ブロードキャスティング・サービスが第２のプログラムと呼ばれるプログラムをブロードキャストする対象である少なくとも第２の端末に対してソースの変更を通知するステップと、を含む。

本発明は、さらに、データストリームをブロードキャストするサービスと少なくとも２つの端末からなる複数の端末とに接続された装置であって、上記少なくとも２つの端末のうちの１つの端末は、少なくとも２つの異なるソースから同一のプログラムを受信可能である、この装置に関する。

本発明によれば、この装置は、
少なくとも１つの第１の端末によって送信されるメッセージを受信するステップであって、上記メッセージは、上記第１の端末がソースを識別した、リクエストによって求められた第１のプログラムと呼ばれるプログラムのデータストリームを受信できないことを示す情報を含む、この受信する手段と、
上記端末に対するプログラムの送信および上記リクエストの送信の間に上記ストリームの複数のソースのアービトレーションを行う手段と、
上記第１の端末のリクエストに応じるために、ブロードキャスティング・サービスが第２のプログラムと呼ばれるプログラムをブロードキャストする対象である少なくとも第２の端末に対してソースの変更を通知する手段と、を含む。

本発明は、添付図面を参照して、決して限定するものではないが、実施形態および実施態様による有益な手段によって、詳細な説明を通じてより良好に理解され、例示されるであろう。

典型的なＩＰシステムのアーキテクチャを模式的に示す図である。 図１のシステムのサーバの例を模式的に例示する図である。 ＩＰＴＶシステムの複数の異なる構成要素間でのチャンネルの選択ステップを示す図である。 本発明の好ましい実施形態に係るシステムの複数の構成要素およびモジュールの間でのインタラクションの時系列な順序を示す図である。 影響が最小限となることに優先度を置いたアービトレーション処理を示す図である。 サービスまたは端末に優先度を置いたアービトレーション処理を示す図である。

以下の説明は、ＡＤＳＬ回線上でのＩＰＴＶタイプのネットワークに基づくものである。これは、非限定的な例として与えられたものであり、他のタイプのネットワークも使用できることが理解されよう。したがって、本発明は、このタイプのネットワークに限定されるものではない。同様に、図示したハイブリッド端末は、ＩＰストリームおよびＤＴＴからのストリームを受信することが可能である。これもまた、非限定的な例として与えられており、２つ以上のタイプのストリームを受信可能な他のハイブリッド端末も本発明の範囲に包含される。

図１を参照すると、ディジタル加入者回線ｘＤＳＬまたはローカル・ループ１１０を介して加入者２００に接続された、クラウド１００における機器からなる典型的なＩＰＴＶネットワークが示されている。

クラウド１００においては、ＩＰＴＶ機能を確保するために、特に、サーバ１０１と、ＩＰＴＶオーディオ／ビデオ・ストリームのためのブロードキャスティング・サービス１０２とを利用可能である。

加入者の側で、ｘＤＳＬ回線は、ゲートウェイ２０１に接続されている。このゲートウェイは、ｘＤＳＬ回線とのインタフェースに加え、例えば、有線ローカル・ネットワーク２０２または無線ローカル・ネットワーク２０３との接続を可能にするインタフェースなど、加入者の通信に必要な複数のネットワーク・インタフェースを含む。ローカル・ネットワーク上２０２で、少なくとも２つのＩＰ受信端末２１０、２２０が接続される。携帯可能な機器２３０が無線ネットワーク２０３に接続される。

端末２１０は、第２のタイプのメディアからのストリームを受信する手段を含む、ハイブリッド端末である。端末２１０は、ＳＴＢ ＨＥ「セットトップ・ボックス・ハイエンド（ｓｅｔ ｔｏｐ ｂｏｘ ｈｉｇｈ ｅｎｄ）」タイプである。ＳＴＢ ＨＥは、一般的には、復号器と呼ばれる。

ＳＴＢ ＨＥは、高解像度ＨＤおよび標準解像度ＳＤのストリームを受信する。ＳＴＢ ＨＥは、ハイエンド端末であるため、録画手段を含み、パーソナル・ビデオ・レコーダＰＶＲ（Ｐｅｒｓｏｎａｌ Ｖｉｄｅｏ Ｒｅｃｏｒｄｅｒ）とも呼ばれる。例として、図示されている媒体２０４は、ＤＴＴ媒体である。しかしながら、この例は、限定的なものではなく、衛星ＳＡＴ媒体であってもよいし、ＣＡＢケーブルであることさえある。ハイブリッド端末は、受信手段をどのように組み合わせたものであってもよい。ハイブリッド端末は、ネットワーク２０５の媒介を通じて媒体２０４に接続される。

端末２２０は、ＬＥ「ローエンド（ｌｏｗ ｅｎｄ）」端末である。端末２２０は、ＳＴＢ ＬＥ「ローエンド（ｌｏｗ ｅｎｄ）」端末である。端末２２０は、一般的には、復号器とも呼ばれる。

端末は、ＳＤストリームを受信し、場合によっては、ＨＤストリームを受信することさえある。端末２２０は、非限定的な例として与えられており、勿論、端末ＳＴＢ ＨＥ２１０と同一のハイエンド端末であってもよい。

端末２３０は、携帯用ローカル・ネットワークとの接続を可能にする特性を有する携帯機器であり、さらに、このネットワークを介してＩＰＴＶ携帯端末として機能する端末２３０としては、非限定的な例として、ＩＰネットワークから受信されるマルチキャスト・ストリームまたはユニキャスト・ストリームを復号可能なタブレット、携帯可能なコンピュータ、ノートブックが挙げられる。

この機器の特性に従って、ユーザは、複数の異なるサービスのプログラム、ＬＩＶＥプログラム、録画されたプログラム、または、ＶＯＤと呼ばれるビデオ・オンデマンドからのプログラムを表示できる。

図１Ａに示されているように、サーバ１０１には、以下のものが含まれることがある。
少なくとも１つの端末２１０、２２０、２３０によって送信されるメッセージを受信するためのモジュール１
このメッセージには、上記第１の端末がソースを識別した、リクエストによって求められていた第１のプログラムと呼ばれるプログラムのデータストリームを受信できないことを示す情報が含まれる。
上記端末に対するプログラムの送信および上記リクエストの送信の間に上記ストリームの複数のソースのアービトレーションを行うモジュール２
上記第１の端末の上記リクエストに応じるために、ブロードキャスティング・サービスが第２のプログラムと呼ばれる、プログラムをブロードキャストする対象である少なくとも第２の端末２１０、２２０、２３０に対してソースの変更を通知するモジュール３

なお、図１Ａのモジュール１、２、および３は、機能的なものであり、これらは、必ずしも物理的に別個のものに対応するものではない。換言すれば、モジュール１、２、および３は、ソフトウェアの形態で開発されてもよく、ハードウェアの形態で開発されてもよく、１つまたは幾つかのプロセッサを含む、１つまたは幾つかの集積回路として実施されることさえある。

図２は、チャンネルの選択ステップを示している。受信端末の処理に従って、ユーザ２１１、２２１、２３１は、自己の各々の端末２１０、２２０、２３０を通じて各自が利用可能なチャンネルのリストから表示したいと望むチャンネルを選択する。ユーザは、ステップＥ０で、受信することを自己が望んでいるプログラムを選択する。端末は、ステップＥ１で、このプログラムのためのサービス・プランにおいて利用可能な複数のソースから、最も高い優先度の、端末の性能に適した特性を有するソースを選択する。以下の表１は、本願で例示する端末の性能の概要を示したものである。

表１：端末の性能

ソースに対する優先度に関して言えば、その媒体の発生元（ＩＰ、ＤＴＴ、ＳＡＴ、ＣＡＢなど）、さらに、その解像度に従って、優先度が異なると考えられる。

以下の表２は、ソースに対する優先度の例を示している。最も優先度が高いものはＰ０であり、最も優先度が低いものはＰ３であることを理解すべきである。操作者の必要に応じてこの例が変更される場合があることが理解できる。

表２：ソースに対する優先度

選択されたチャンネルがＩＰ媒体上で利用可能であると、端末は、ステップＥ２で、ｘＤＳＬ回線上で十分な帯域幅が利用可能となるようにする。ユーザは、ソースではなく、チャンネルを選択し、端末は、本発明に従ってソースを選択する。

ｘＤＳＬ回線上で利用可能な帯域幅をチェックする技術は、当業者によって良く知られている。当業者によって知られている方法は、ディジタル加入者回線アクセス・マルチプレクサ（ＤＳＬＡＭ：Ｄｉｇｉｔａｌ Ｓｕｂｓｃｒｉｂｅｒ Ｌｉｎｅ Ａｃｃｅｓｓ Ｍｕｌｔｉｐｌｅｘｅｒ）とも呼ばれるＤＳＬアクセス・マルチプレクサと、ＩＰＴＶを取得するための利用可能な帯域幅プロファイルを更新する機能である呼受付制御システム（ＣＡＣ：Ｃａｌｌ Ａｄｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ ｓｙｓｔｅｍ）に依存している。このプロファイルは、特に、合計帯域幅と使用される帯域幅を含む。ローカル・ネットワーク２０２および２０３上で利用可能な端末２１０、２２０、２３０に対してこの情報を提供するために、複数の解決法を利用可能である。例えば、サーバ１０１は、各加入者に対し、一方では、合計帯域幅とＣＡＣからｘＤＳＬ上で利用可能な帯域幅とを含み、他方では、このｘＤＳＬ回線を使用して各端末によって使用される帯域幅を含む表（テーブル）を保持可能である。サーバ１０１は、したがって、どのように帯域幅の消費を分配し、その進行に伴って端末に利用可能な帯域幅を提供するかを把握している。よって、ユーザによるチャンネル選択の間、端末は、ｘＤＳＬ回線を通じてこのチャンネルを受信できるかどうかをチェックすることが可能である。このチェックは、ローカルで行うこともできるし、使用された帯域幅（サーバ上で保持された情報または端末レベルでの通知）のチェック方法に基づいて、サーバ上に処理を移して行うこともできる。

ソースが（ＤＴＴ媒体を通じた）帯域幅に依存していない場合には、端末は、ステップＥ４において、選択されたソースに合わせる。ソースがＩＰソースである場合、帯域幅が十分であれば、端末は、選択したソースに加入し、チャンネルを表示できるようにする。ソースは、マルチキャストであり、加入は、ＩＧＭＰ Ｊｏｉｎと呼ばれるインターネット・グループ・マネージメント・プロトコル（ＩＧＭＰ：Ｉｎｔｅｒｎｅｔ Ｇｒｏｕｐ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）のリクエストを使用して行われる。端末が帯域幅情報を含むローカル・テーブルを調べるか、アプリケーション・プロトコル・インタフェース（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ Ｉｎｔｅｒｆａｃｅ）を通じてサーバにポーリングを行うことによって、ｘＤＳＬ回線上での帯域幅の不足を見つけると、端末は、ユーザのリクエストに応ずることが不可能であることについてサーバ１０１に知らせる。サーバ１０１は、抱えている問題に対する解決法を見つけるために、アービトレーションＥ３、Ｅ３’に処理を進める。

アービトレーションについては、例えば、最終的なユーザ２１１、２２１、２３１に対する影響が最小限となることに優先度を置くことを求めて、サービスに優先度を置くか、端末に優先度を置くかで、様々な実施形態を想定可能である。複数の異なる変形例の実施態様が図４および図５に記載されている。

ステップＥ４において、リクエストされたプログラムに対応するストリームが見つけられないと、ステップＥ６において、リクエストされたストリームを受信するための帯域幅が不十分であること、さらに、リクエストに応じることができないことが端末に通知される。そうでない場合には、ストリームが見つかり、端末は、ステップＥ５において、リクエストされたチャンネルを受信できる。

この方法の結果は、よって、幾つかの事柄によって達成できる。
端末は、他の端末に影響を及ぼすことなく、選択されたチャンネルを表示できる。
端末は、プログラムを表示できるが、これによって別の端末に影響が及ぼされる。
さらに、最後に、所定の優先度基準を用いてアービトレーションの処理が進められる場合には、リクエストされたチャンネルに対応するストリームが見つけられない。

図２に示されたステップは、システムを構成する複数の異なる装置間のインタラクションを示している。これらのインタラクションは、図３に示されており、ユーザ２１１によって、チャンネルの変更を求めるリクエストが行われる。上述したように、端末２１０は、Ｅ１において、選択するステップを実行し、Ｅ２において、利用可能な帯域幅のチェックを行う。このシナリオにおいて、ローカル・ループの帯域幅は十分でなく、端末２１０は、サーバ１０１に対し、移行処理Ｔ２１の間にユーザのリクエストに応じることができないことを通知する（図３）。サーバは、この例において、アービトレーションのステップＥ３’に進む。端末２２０がソースを変更することで、ユーザ２１１によるリクエストによって求められた必要な帯域幅を開放し、プログラムの表示を継続できることが明らかにされる。サーバ１０１は、移行処理ＴＡ３０（図３）の間に、サーバ１０１は、端末２２０に対し、変更リクエストについての通知を行い、使用されるべき新たなソースを示す指示を与える。図示されているシナリオにおいて、移行処理ＴＡ３０（図３）の間に、変更リクエストは、端末２３０にも通知される。変更に関係のある端末に対してのみ、通知が行われる。

最後に、移行処理ＴＡ３０（図３）の間に、サーバ１１０は、リクエストを行っている端末２１０にチャンネルを受信できることを通知し、端末２１０は、このチャンネルを選択する。

サーバは、チャンネルを選択できることを端末２１０に通知した後、クライアントに対応するｘＤＳＬ回線上で利用可能な、または、使用されている帯域幅についての情報を可能な限り更新する。

影響が最小限となるソースの変更による、図２のステップＥ３のアービトレーション処理は、図４に示されている。アービトレーション処理は、別のソースにソースを変更することによって及ぼされる影響のレベルを記録した表３に基づく。例えば、変更前のソースがＩＰ ＨＤであり、アービトレーションが別の変更後のソースＤＴＴ ＳＤに切り替えを行うための解決法を取り扱うものである場合には、影響は、６となる。説明を簡略化すると、影響は、使用されている値に比例する。表３は、影響表の例である。勿論、この影響表の登録に、想定されるソースの全て含めることができる。さらに、各組み合わせに対する影響のレベルは、非限定的な例として提供されている。これは、最小二乗法に従って適切なものに決めることができるが、他の方法を適用することもできる。

表３：変更前のソースから変更後への変更による影響値

ステップＥ３のアービトレーションは、端末によって十分な表示を行うことができないプログラムを表示するリクエストによって開始され、これは、サーバ１０１に通知される。このアービトレーションは、表３に従って影響が最小限となるソースの変更をサーチすることによって開始される。これにより、想定される変更、特に、関連する変更前のソースを識別することが可能となる。ここで考慮される影響は、変更前のその時点で流れている既存のストリームから変更後の端末の性能に適合した想定されるストリームへの影響である（表１）。

例えば、レベル０の影響では、変更は、変更前のＩＰ ＳＤのストリームから変更後のＤＴＴ ＨＤのストリームへの移行に対応する。表３を参照すると、影響値「０」の選択では不十分である場合、「１」の影響である、ＩＰ ＳＤストリームをＤＴＴ ＨＤストリームに切り替えることも計画され（１番目の影響が「０」となり、２番目の影響が「１」となる）、開放される帯域幅が依然として十分でない場合には、より高い影響値、または、同等の影響値に変更するストリームの切り替えも計画される。したがって、端末のリクエストに応ずるために、関連する複数の端末がストリームを変更することとなる。

全ての影響の組み合わせを実行しても十分な帯域幅が開放されない場合には、ステップＭ１において、利用可能な解決法が存在しない。ステップＭ２において、端末に対し、この端末がリクエストしたストリームを受信できないことが通知される。しかしながら、開放された帯域幅が十分である場合には、ステップＥ３において識別された端末は、ソースを変更し、リクエストを行っている端末は、リクエストしたストリームを受信する。

ｘＤＳＬ回線上の帯域幅が１０ＭＢ／ｓに固定されている例によって、影響が最小限となるアービトレーションに本実施形態が基づくことを示すことができる。このシナリオにおいては、概要が以下の表４に示されているように、２人のユーザＡおよびＣがライブ・プログラムを視聴し、録画が実行中となっている。ユーザＡは、端末２１０を使用するが、この同じ端末２１０によって録画が行われている。ユーザＣは、携帯端末２３０を使用する。ユーザＢは、ステップＥ０において、端末２２０上でＡＢＣチャンネルを視聴することを望む。

表４：最小限の影響のシナリオでの状況

ストリームの可用性、さらに、必要な帯域幅は、以下の通りである。

表５：最小限の影響のシナリオでの利用可能なソース

端末２２０は、ステップＥ１において、表１上で参照されている、自己の性能に基づいて、２つのＳＤおよびＨＤの解像度で、ＩＰ媒体からストリームを受信できる。端末２２０は、ＬＩＶＥサービスに対する最も高い優先度のソースを選択する。これは、ＩＰ ＨＤである。

端末２２０は、ステップＥ２において、リクエストされたチャンネルＡＢＣ ＩＰ ＨＤに必要な帯域幅と現在利用可能な帯域幅との適合性をチェックする。端末２２０は、全ての帯域幅が使用されていることを把握する。したがって、端末２２０がソースＩＰ ＨＤを選択してＡＢＣを視聴することを求めるユーザＢのリクエストに応ずることができない。よって、端末２２０は、サーバ１０１に問題を通知し、これをきっかけとして、アービトレーションＥ３の処理が行われる。

影響表は、値が小さいものから順番に実行される。このため、影響が最も小さい変更が表３においてサーチされる。影響表によれば、最小の影響値は、ソースＩＰ ＳＤのストリームからＤＴＴ ＨＤへのストリームの変更の場合であり、零である。これは、携帯端末２３０上にユーザＣによって表示されるＣａｎａｌ＋ストリームの場合に該当する。残念ながら携帯端末２３０は、性能表１によれば、ＤＴＴ ＨＤのストリームを受信する性能を有していない。

この処理では、表３上で利用可能となっている影響が高いものを選択し、前に行ったサーチを繰り返す。したがって、影響値が１であると識別される解決法が３つ存在する。ソースをＩＰ ＨＤからＤＴＴ ＨＤに切り替えることが可能である。ＣＮＮ、ＴｖＢｒｅｉｚｈ、およびＡＢＣストリームがこれに該当する。

ＴｖＢｒｅｉｚｈは、表１によれば、ＤＴＴ ＨＤソースを受信可能である端末２１０によって受信されるが、ＤＴＴ
ＨＤではこのチャンネルは利用可能でないため、録画をこのソースに切り替えることは不可能である。

端末２２０によってＡＢＣがリクエストされている。しかしながら、この端末２２０は、ＤＴＴを受信することはできない。

最後に、ＤＴＴ ＨＤソースを受信可能な端末２１０によって受信されるＣＮＮは、ＨＤの媒体ＤＴＴ上で利用可能である。ＤＴＴ ＨＤに切り替えることによって、この解決法は、４ＭＢ／ｓの帯域幅を開放する。

次に、ＣＮＮにより開放された帯域幅とＡＢＣに必要な帯域幅とが比較される。ＡＢＣの帯域幅は、十分に確保されている。端末２１０に通知が行われ、端末２１０は、ＤＴＴ ＨＤのＣＮＮチャンネルに、自動的に、さらに、トランスペアレントに、ソースを変更する。

サービスまたは端末に対する優先度によるアービトレーションの処理は、全体として同じであり、図５に示されている。この処理は、２つの分類基準に基づく。これらは、サービスに対する優先度と端末に対する優先度である。アービトレーション処理によれば、優先度をサーチするステップＡ１では、一方の基準が他方の基準より優先される。

このアービトレーションの説明は、サービスに対する優先度に基づいている。通知を受信したときの、第１のステップＡ１は、複数の異なるの端末２１０、２２０、２３０による表示のために現在流れている既存のストリームを分類することからなる。このため、サービスにリンクされた優先度基準が当初適用される。複数の異なる利用可能なサービスは、例えば、ＬＩＶＥ、ＰＶＲであり、ＶＯＤとなることさえある。表６は、サービスに対する優先度の概要を示している。最も高い優先度がＰＶＲ機能に割り当てられるが、他のどのような分類も有効である。

表６：サービスに対する優先度

次に、第２の分類基準が適用される。この基準は、端末にリンクされ、その概要が表７に示されている。

表７：端末に対する優先度

表８：ソースに対する優先度とサービスに対する優先度の組み合わせ

ステップＡ１において、まず、最も低い優先度のサービスが選択され、次に、選択されたサービスを受信する複数の端末からの選択が行われ、最も低い優先度のものが選択される。幾つかの端末に対してこれが当てはまる場合には、これらの端末のうち、最も低い優先度のストリームを受信している端末がサーチされる（表８）。次に、リクエストされたプログラムを受信するために、リクエストされたプログラムを配信し、十分な帯域幅が開放されているストリームがサーチされる（ステップＡ２）。ステップＡ４において、一方で、端末の性能不足という理由で、他方で、リクエストされたチャンネルを搬送するストリーム（例えば、ＤＴＴ）を受信しないという理由で、該当するストリームが存在しない場合には、より高い優先度の端末、または同等の優先度の端末であるが、より高い優先度のストリームを受信する次の端末がサーチされる。全ての端末が調べられると、次の優先度のサービスが続けられる。

ステップＡ２において、開放された帯域幅が十分である場合には、その後に、ステップＡ３により、アービトレーションが行われ、ここでの処理により、ステップＡ１において選択された端末に対し、ソースを変更し、与えられたものに切り替える必要がある旨が通知される。次に、アービトレーション処理により、リクエストを行っている端末に対し、リクエストされたチャンネルを表示可能であることが通知される。

代替的な方法によれば、リクエストを行っている端末は、アービトレーション処理からの通知を受信しないが、利用可能な帯域幅の進行についての情報のみを与えられ、したがって、利用可能な帯域幅をチェックすることができ、リクエストされたチャンネルの表示を始めることができる。

このリストにストリームが残っていない場合には、リクエストを行っている端末に対し、このプログラムのためのより優先度の低いソースを選択することが求められる。この処理は、ステップＥ１で再開する。利用可能な他のソースが存在しない場合には、ユーザのリクエストに応じることができず、ステップＥ５において、処理が完了する。

別の実施形態によれば、アービトレーションは、上述した端末に対する優先度を用いて生成される。この変形例の変更は、ステップＡ１において、端末にリンクされた優先度がまず、表示されるストリームの分類のために考慮され、このサービスにリンクされた優先度が考慮される点である。したがって、単純に、優先度の順序が逆になっており、その他のステップの動作は同じである。

当然のことながら、本発明は、端末にリンクされる優先度とサービスにリンクされる優先度との間で、考慮される優先度の順序が異なるものを包含する。

以下の例により、一実施形態を示すことができる。この例において、ｘＤＳＬ回線上で利用可能な合計の帯域幅は、１０ＭＢ／ｓである。２人のユーザＡおよびＢ２１１、２２１がライブな伝送を視聴している。ユーザＣは、端末２１０を使用して、ＴＶＢＲＥＩＺＨ上でのフィルムの録画をプログラムすることを望んでいる。ＴＶＢＲＥＩＺＨは、ＨＤおよびＳＤでＩＰネットワーク上で利用可能である。サーバ１０１に知られている、異なる端末の状態の概要が以下の表９に示されている。

表９：サービスに対する優先度のシナリオでの状況

ストリームの可用性および必要な帯域幅は、以下の通りである。

表１０：サービスに対する優先度のシナリオでの利用可能なストリーム

ステップＥ１において、端末は、最も高い優先度のチャンネルを選択する。録画は、表１に従って、特に、２つのＨＤ解像度およびＳＤ解像度でＩＰ媒体からのストリームを受信できる端末２１０を使用して行われる。表２に記載された媒体および解像度のうち、ＰＶＲサービスのための最も高い優先度は、ＩＰ ＨＤソースのＰ０である。結果として、端末２１０は、ＩＰ ＨＤソースを選択し、その後、帯域幅のチェックのための第２のステップＥ２に処理を続ける。

端末は、録画リクエストの受信の間に消費される帯域幅を計算する。これは、７ＭＢ／ｓであり、ＴＶＢＢＲＥＩＺＨの受信には、追加の４ＭＢ／ｓが必要である。受信に必要な１１ＭＢ／ｓは、最大の帯域幅（１０ＭＢ／ｓ）を超える。端末は、サーバに通知を行い、これをきっかけとして、アービトレーション処理Ｅ３’が行われる。

サーバ１０１によって開始されるアービトレーション処理は、ステップＡ１から始まる（表１１）。ここで、端末に対する優先度の前にサービスに対する優先度を考慮する。２つのサービス、ライブおよび録画が必要となる。録画の優先度がより高いため、端末２１０からの録画のリクエストは、より優先度が高い。よって、２つのＬＩＶＥサービスはより優先度が低いものと考えられる。その後、優先度が端末に与えられる。ここで、最も低い優先度を有するものは端末２２０である。端末２２０は、ＣＢＳチャンネルを視聴する。

表１１：サービスに対する優先度を考慮し、次に、端末に対する優先度を考慮する場合に従った分類例

次に、ステップＡ２において、ＣＢＳチャンネルに対し、より優先度の低いソースの可用性がチェックされる。この例によれば、ＣＢＳもまた、ＳＤで利用可能であり、これにより、１ＭＢ／ｓを開放することが可能となる。Ａ３において、開放された帯域幅は、ＴＶＢＲＥＩＺＨを受信するのに十分である。サーバ１０１は、したがって、表示されるプログラムのタイプの変更を端末２２０に対して通知する一方で、ＣＢＳ ＩＰ ＳＤマルチキャスト・アドレスへのシフトを支持する。これにより、帯域幅が開放され、リクエストを行っている端末は、リクエストされたチャンネルに加入できる。

上述したアービトレーション方法は、サーバによって実施される。このサーバは、クラウドにおける１つの機器１０１上で利用できる。また、サーバは、ゲートウェイ・タイプの装置２０１に組み込むことができる。この場合、ゲートウェイ２０１は、一方では、データストリームのブロードキャスティング・サービスに接続され、他方では、少なくとも２つの端末に接続されている。この２つの端末のうちの少なくとも一方は、少なくとも２つの異なるソースから同一のプログラムを受信できる。ゲートウェイ２０１は、端末２１０または端末２２０である、少なくとも第１の端末によって、ソースを識別し、第１のプログラムと呼ばれるプログラムのデータストリームを求めるリクエストを受信する。ゲートウェイ２０１は、このリクエストを受信した後、例えば、帯域幅が十分でないという理由で、このリクエストに対するサービスを提供できないことを把握する。この場合、ゲートウェイ２０１は、各端末に対し、利用可能な帯域幅または使用されている帯域幅、さらに、使用されているサービスを示す表（テーブル）を備える。したがって、ゲートウェイ２０１は、リクエストに対するサービスが提供されないことを識別する手段を含む。よって、例えば、図４および図５に記載されている実施形態に従って、ゲートウェイ２０１は、複数の異なる既存のリクエストおよびサービスのアービトレーションを行う。アービトレーションの後、アービトレーションによって、接続された端末のうちの１つの端末のためのソースの変更が生ずると、ゲートウェイは、第２のプログラムを第２のソースから第２の端末に送信するように、端末のリクエストに応ずるために、ブロードキャスティング・サービスが第２のプログラムと呼ばれるプログラムをブロードキャストする対象である少なくとも第２の端末にソースの変更を通知する。

ローカル・ネットワーク上で利用可能な受信端末の数は、非限定的な例として挙げている。ハイブリッド端末は、受信端末をどのように組み合わせたものにも対応できる。

Claims (15)

1. ブロードキャスティング・データストリームの少なくとも１つのサービスと、少なくとも１つのサーバと、少なくとも２つの端末を含むシステムにおいてデータストリームを割り当てる方法であって、前記少なくとも２つの端末のうちの１つの端末が少なくとも２つの異なるソースから同一のプログラムを受信可能であり、
   前記サーバによって、少なくとも１つの第１の端末によって送信されるメッセージを受信するステップであって、前記メッセージは、前記第１の端末がソースを識別した、リクエストによって求められた第１のプログラムと呼ばれるプログラムのデータストリームを受信できないことを示す情報を含む、前記受信するステップと、
   前記サーバによって、前記複数の端末に対するプログラムの送信および前記リクエストの送信の間に前記ストリームの複数のソースのアービトレーションを行うステップと、
   前記第１の端末の前記第１のプログラムを求めるリクエストに応じるために、ブロードキャスティング・サービスが第２のプログラムと呼ばれるプログラムをブロードキャストする対象である少なくとも第２の端末に対してソースの変更を通知するステップと、を含む、前記方法。
2. 前記アービトレーションを行うステップにおいて、前記複数の端末を接続するネットワーク上で利用可能な帯域幅が考慮される、請求項１に記載の方法。
3. 優先度が各ソースに関連付けられる、請求項１または２に記載の方法。
4. 優先度が各端末に関連付けられる、請求項１〜３のいずれか１項に記載の方法。
5. 前記リクエストは、さらに、関連するサービスを求めるリクエストを含み、優先度が各サービスに関連付けられる、請求項１〜４のいずれか１項に記載の方法。
6. 他のソースのうちの各々に対するソースの変更に関連付けられたコストを考慮して、各ソースに対し、影響値が決定される、請求項１〜５のいずれか１項に記載の方法。
7. 前記アービトレーションを行うステップにおいて、最も高い優先度を有するソースが優先される、請求項３に記載の方法。
8. 前記アービトレーションを行うステップにおいて、最も高い優先度を有する端末が優先される、請求項４に記載の方法。
9. 前記アービトレーションを行うステップにおいて、最も高い優先度を有するサービスに関連付けられたストリームが優先される、請求項５に記載の方法。
10. 前記アービトレーションを行うステップにおいて、前記影響値が最小にされる、請求項６に記載の方法。
11. 前記リクエストで求められているストリームによって前記ネットワーク上で利用可能な帯域幅にオーバーフローが生じたとき、前記複数の端末に割り当てられる合計ストリームにより利用可能な合計帯域幅にオーバーフローが生じないように、より少ない帯域幅を消費するストリームが少なくとも前記第２の端末に割り当てられる、請求項２〜１０のいずれか１項に記載の方法。
12. 前記第２の端末が、
    前記ソースの変更による前記影響が最小限となる端末であるか、
    最も低い優先度の端末であるか、
    最も低い優先度のソースからのストリームを受信する端末であるか、
    最も低い優先度のサービスを受信する端末である、請求項３〜６のいずれか１項に記載の方法。
13. 前記アービトレーションを行うステップにおいて、優先度が考慮される順番は、サービスに対する優先度、次に、ソースに対する優先度、次に、ソースに対する優先度である、請求項３〜５のいずれか１項に記載の方法。
14. ソースからストリームを受信する各端末の性能が考慮される、請求項１〜１３のいずれか１項に記載の方法。
15. データストリームをブロードキャストするサービスと少なくとも２つの端末とに接続された装置であって、前記少なくとも２つの端末のうちの１つの端末が少なくとも２つの異なるソースから同一のプログラムを受信可能であり、
    少なくとも１つの第１の端末によって送信されるメッセージを受信する手段であって、前記メッセージは、前記第１の端末がソースを識別した、リクエストによって求められた第１のプログラムと呼ばれるプログラムのデータストリームを受信できないことを示す情報を含む、前記受信する手段と、
    前記複数の端末に対するプログラムの送信および前記リクエストの送信の間に前記ストリームの複数のソースのアービトレーションを行う手段と、
    前記第１の端末の前記リクエストに応じるために、ブロードキャスティング・サービスが第２のプログラムと呼ばれるプログラムをブロードキャストする対象である少なくとも第２の端末に対してソースの変更を通知する手段と、を含む、前記装置。

Images