JP5503560B2 - 負荷分散信号分配を行う方法および装置 - Google Patents

Description

（関連出願の相互参照）
本願は、２００８年２月２９日に米国特許商標庁に出願された米国仮特許出願第６１／０６７５８５号に対する優先権を主張し、そこから生じる特典を請求するものである。

本発明は、一般に、ディジタル・ホーム・ネットワークなどのネットワークにおける信号分配に関し、より詳細には、そのようなネットワークにおいてクライアント・デバイスに対する負荷分散信号分配を実現する方法および装置に関する。

現代社会では、ディジタル・ホーム・ネットワークなどの信号分配ネットワークがますます普及してきている。例えば、衛星などの信号源から音声信号および／または映像信号を受信するディジタル・ホーム・ネットワークでは、「ゲートウェイ」と呼ばれるデバイス／装置を使用して、例えばセット・トップ・ボックス（ＳＴＢ）などのクライアント・デバイスに信号を分配することが多い。

従来の衛星ゲートウェイ・システムに関する問題の１つは、これらのシステムが、衛星ネットワーク・フィードを複数のゲートウェイ間で分割することに対応していないことである。すなわち、所与のネットワークは、１度に１つのゲートウェイしかソースにすることができない。さらに、ビット・レートが比較的高く（例えばＡ３など）、コンテンツが高精細度コンテンツである場合を想定すると、従来のシステムでは、ゲートウェイの出力インタフェースで、そのゲートウェイの総出力帯域幅を超えてしまうことが容易に起こりうる。例えば、ピーク・ストリーム・ビット・レートを毎秒１８メガビットと仮定すると、ＧＥＩ０（ギガビット・イーサネット（登録商標）・インタフェース・ポート０）インタフェースで毎秒７００〜８００メガビットの集合体を消費するのに、４０の異なるＨ．２６４ストリームで足りる。さらに、スポット・ビームを含むときには、一部の衛星ネットワークは３２を超えるトランスポンダを有し、１つのトランスポンダがいくつかの映像および音声チャネルをサポートすることができる。このようなネットワークを複数のゲートウェイ間で分割できないということは、つまり、従来のシステムが全てのトランスポンダを同時に同調させることができないということである。

本明細書に記載の本発明は、前述の問題および／またはその他の問題に対処するものであり、具体的には、とりわけゲートウェイの出力インタフェースのオーバサブスクリプションを防止することができ、且つ新しいネットワーク、衛星トランスポンダの増加、クライアント・デバイスの増加、およびゲートウェイの冗長性に対応する柔軟性を提供することができる、新しいアーキテクチャを提供するものである。

本発明の特徴によれば、方法が開示される。例示的な実施例によれば、この方法は、複数の映像ソースの１つの映像をダウンロードすることを求める要求をクライアント・デバイスから受信するステップと、前記複数の映像ソースを受信することができる第１の映像受信側デバイスおよび第２の映像受信側デバイスからそれぞれの負荷指標を受信するステップと、前記負荷指標に従って、前記第１の映像受信側デバイスおよび前記第２の映像受信側デバイスの一方を選択するステップと、前記選択した映像受信側デバイスに、前記複数の映像ソースの１つの前記映像を、前記クライアント・デバイスが知っているアドレスを使用して伝送するように命令するステップとを含む。

本発明の別の特徴によれば、装置が開示される。例示的な実施例によれば、この装置は、複数の映像ソースの１つの映像をダウンロードすることを求める要求をクライアント・デバイスから受信する第１の入力などの手段と、前記複数の映像ソースを受信することができる第１の映像受信側デバイスおよび第２の映像受信側デバイスからそれぞれの負荷指標を受信する第２の入力などの手段と、前記負荷指標に従って、前記第１の映像受信側デバイスおよび前記第２の映像受信側デバイスの一方を選択する第１の制御論理などの手段と、前記選択した映像受信側デバイスに、前記複数の映像ソースの１つの前記映像を、前記クライアント・デバイスが知っているアドレスを使用して伝送するように命令する第２の制御論理などの手段とを備える。

本発明のさらに別の特徴によれば、別の方法が開示される。例示的な実施例によれば、この方法は、複数の映像ソースを受信することができる映像受信側デバイスから要求サーバ・デバイスに、前記映像受信側デバイスに関連する負荷を示す負荷指標を送信するステップと、要求されたプログラムおよび前記要求されたプログラムに関連するクライアント・デバイスの宛先アドレスを示すデータを、前記要求サーバ・デバイスから受信するステップと、前記要求されたプログラムを前記宛先アドレスに伝送するステップとを含む。

本発明のさらに別の特徴によれば、別の装置が開示される。例示的な実施例によれば、この装置は、当該装置に関連する負荷を示す負荷指標を決定する制御論理などの手段と、前記負荷指標を要求サーバ・デバイスに送信するインタフェースなどの手段とを備え、前記負荷指標に応じて、要求されたプログラムおよび前記要求されたプログラムに関連するクライアント・デバイスの宛先アドレスを示すデータが、前記要求サーバ・デバイスから受信され、この装置は、前記要求されたプログラムを前記宛先アドレスに伝送する。

本発明のさらに別の特徴によれば、別の方法が開示される。例示的な実施例によれば、この方法は、プログラムを求める要求をクライアント・デバイスから要求サーバ・デバイスに送信するステップと、前記要求に応答して、前記クライアント・デバイスが前記要求サーバ・デバイスからアドレスを受信するステップと、前記アドレスを使用して、選択された映像受信側デバイスを介して、前記クライアント・デバイスが前記要求したプログラムを受信するステップとを含み、前記要求サーバ・デバイスは、前記選択された映像受信側デバイスを、複数の映像受信側デバイスの中から、前記複数の映像受信側デバイスからのそれぞれの負荷指標に基づいて選択する。

本発明のさらに別の特徴によれば、別の装置が開示される。例示的な実施例によれば、この装置は、プログラムを求める要求を要求サーバ・デバイスに送信する出力などの手段と、前記要求に応答して、前記要求サーバ・デバイスからアドレスを受信し、前記アドレスを使用して、選択された映像受信側デバイスを介して、前記要求したプログラムを受信する入力などの手段とを備え、前記要求サーバ・デバイスは、前記選択された映像受信側デバイスを、複数の映像受信側デバイスの中から、前記複数の映像受信側デバイスからのそれぞれの負荷指標に基づいて選択する。

以下の本発明の実施例の説明を添付の図面と関連付けて読めば、本発明の上述およびその他の特色および利点、ならびにそれらを実現する方法がさらに明らかになり、本発明はさらに良く理解されるであろう。

本発明の例示的な実施例による、負荷分散を実行するシステム・レベル・アーキテクチャを示す図である。 本発明の例示的な実施例による、図１のプロキシ・サーバ・ゲートウェイおよびストリーマ・ゲートウェイをさらに詳細に示す図である。 本発明の例示的な実施例による、図１のプロキシ・サーバ・ゲートウェイが要求を処理する方法を示す図である。 本発明の例示的な実施例による、図１のプロキシ・サーバ・ゲートウェイがストリーマ・ゲートウェイを選択する方法を示す図である。 本発明の例示的な実施例による、図１のプロキシ・サーバ・ゲートウェイを動作させるステップを示す流れ図である。 本発明の例示的な実施例による、図１のストリーマ・ゲートウェイの１つを動作させるステップを示す流れ図である。 本発明の例示的な実施例による、図１のＳＴＢの１つを動作させるステップを示す流れ図である。

本明細書に記載の例示は、本発明の好ましい実施例を説明するものであり、これらの例示は、いかなる意味においても本発明の範囲を限定するものとして解釈すべきものではない。

図面、特に図１を参照すると、本発明の例示的な実施例による負荷分散を実行するシステム・レベル・アーキテクチャを示す図が示してある。図１のアーキテクチャは、複数のストリーマ・ゲートウェイ（映像受信側デバイス）１０と、ローカル・バス・スイッチ１５（任意選択でよい）と、プロキシ・サーバ・ゲートウェイ（要求サーバ）２０と、主配線盤（ＭＤＦ）スイッチ２５と、映像ネットワーク３０と、ＳＴＢ３５として実施される複数のクライアント・デバイスとを備える。例示および説明のために、本明細書では、図１のゲートウェイは、衛星ゲートウェイとして図示および説明する。しかし、本明細書に記載の本発明の原理は、衛星ゲートウェイに限定されるものではなく、例えばケーブル・ゲートウェイ、地上ゲートウェイ、セット・トップ・ボックス、コンピュータ、および／またはその他のデバイス／装置などに適用することもできることは、当業者なら直感的に分かるであろう。同様に、図１の各要素も、ケーブル・ネットワーク、イーサネット（登録商標）・スイッチ・ネットワーク、光ファイバ・ネットワーク、および／またはその他のタイプのネットワークなど（ただしこれらに限定されない）、任意のタイプの適当なネットワークに実装することができる。

図１の負荷分散アーキテクチャは、論理的には、プロキシ・サーバ機能と、データ（例えば音声および／または映像のテレビジョン・チャネルなど）ストリーミング機能とに分割される。図１では、プロキシ・サーバ機能は、プロキシ・サーバ・ゲートウェイ２０が提供し、データ・ストリーミング機能は、ストリーマ・ゲートウェイ１０が提供する。例示的な実施例によれば、ストリーマ・ゲートウェイ１０は、プロキシ・サーバ・ゲートウェイ２０と同じゲートウェイ内に存在するが、プロキシ・サーバ機能への影響を最小限に抑えるために、そのデータ負荷が制限されることもある。あるいは、図１に示すように、プロキシ・サーバ・ゲートウェイ２０を、データ・ストリーミング機能を実行しない独立型マシンとすることもできる。各ストリーマ・ゲートウェイ１０は、複数のテレビジョン・チャネルを同調させ、それらのチャネルのコンテンツを複数のクライアント・デバイスＳＴＢ３５に同時に伝送する（すなわちストリーミングする）ことができる。説明を分かり易くするために、図１には、管理（例えばＩＸＥ０−１０／１００ＢａｓｅＴイーサネット（登録商標）管理インタフェースまたは１００ＢａｓｅＴポート０）接続性は示していない。ただし、図１の全てのゲートウェイ１０および２０は、インターネットにアクセスすることができ、ＳＮＭＰ（簡易ネットワーク管理プロトコル）やテルネットなどを介して遠隔構成が可能であるものと考えられる。

図１のアーキテクチャが提供する負荷分散法は、衛星ネットワーク・フィードを複数のストリーマ・ゲートウェイ１０の間で分割して、全体のデータ負荷がＧＥＩ０インタフェース間で分配されるようにすることに対応している。設計の選択に応じてストリーマ・ゲートウェイ１０を追加することにより、システムの容量および／または冗長性を高めることができる。

本発明の原理による負荷分散は、シームレスな障害再構成および回復をサポートする。図１の負荷分散システムでは、例示として、ストリーマ・ゲートウェイ１０を並列に配線して、全てのストリーマ・ゲートウェイ１０が全てのネットワーク・フィードを受信するように示してある。この構成では、システムの再構成で、ストリーマ・ゲートウェイ１０で障害が起きた後に物理的なケーブル布線の変更を行う必要がない。さらに、ストリーマ・ゲートウェイ１０で障害が起きた場合に、システムは、障害の起きたストリーマ・ゲートウェイ１０の現在のストリームを、その他のストリーマ・ゲートウェイ１０に自動的に割り付けし直して、サービスの中断を最小限に抑えることができる。

本発明の原理による負荷分散では、ＲＴＳＰ（リアルタイム・ストリーミング・プロトコル）プロキシ・サーバ・ゲートウェイ２０をストリーマ・ゲートウェイ１０から切り離し、ネットワーク同調およびデータ・ストリーミング機能をプロキシ・サーバ・ゲートウェイ２０から切り離す。従って、本発明の原理の下で構築されたストリーマ・ゲートウェイ１０またはプロキシ・サーバ・ゲートウェイ２０は、それほど複雑でなく、それほどコストもかからない。例えば、Ｌｉｎｕｘ ＰＣをプロキシ・サーバ・ゲートウェイ２０として使用し、チューナ、ＦＰＧＡ（フィールド・プログラマブル・ゲート・アレイ）、およびギガビット・コントローラも含むストリーマ・ゲートウェイ１０では低コストなマイクロプロセッサを使用することもできる。

例示的な実施例によれば、負荷分散システムを設計する際に、以下の考慮事項を考慮に入れればよい。
１．従来のＳＴＢクライアント・デバイスは、ＲＴＳＰリダイレクトに対応していないことがある。
２．衛星ネットワーク・フィードは、複数のゲートウェイ間で共有しなければならない。例えば、複数のゲートウェイを並列に配線して、全てのゲートウェイ・シャーシ（ｇａｔｅｗａｙ ｃｈａｓｓｉｓ）が全ての衛星ネットワークを受信するようにすることができる。
３．負荷分散は、構成ファイル・パラメータを使用してイネーブルすることができ、リブートの後に有効になる。
４．ストリーマ・ゲートウェイ・ネットワーク、チューナ、および偏波構成は、構成ファイル・パラメータとして設定しなければならない。さらに、ネットワークの自動検出／構成を追加することもできる。
５．トリプレット（ｔｒｉｐｌｅｔ）（ネットワーク番号、トランスポンダ周波数、偏波設定）は、ストリーマ・ゲートウェイ間で一意的でなければならない。
６．補助（ＩＸＥ０）インタフェースを、ゲートウェイ間通信に使用してもよい。
７．衛星ケーブル・フィードおよび／またはチューナ動作のトラブルシューティングおよび妥当性検査には、静的同調を使用しなければならない。静的同調の使用中には、システム動作が最適以下であってもよい。

図２を参照すると、本発明の例示的な実施例による図１のプロキシ・サーバ・ゲートウェイ２０およびストリーマ・ゲートウェイ１０をさらに詳細に示す図が示してある。図２に示すように、プロキシ・サーバ・ゲートウェイ２０は、フロント・エンド・モジュール２１、バック・エンド・モジュール２２、およびストリーマ・データベース２３を備える。各ストリーマ・ゲートウェイ１０は、ソケット・インタフェース１１、ＲＴＰ（リアルタイム・プロトコル）ライブラリ１２、チャネル取得モジュール１３、ＤＳＦＥ（ディジタル・シグナリング・フロント・エンド）デバイス・モジュール１４（チューナ・モジュールとして動作する）、およびＡ３チューナ・デバイス・モジュール１６を備える。

図２では、プロキシ・サーバ・ゲートウェイ２０のバック・エンド・モジュール２２は、ローカル・バスを介して、外部のストリーマ・ゲートウェイ１０のソケット・インタフェース１１と通信する。例示的な実施例によれば、ローカル・バス通信は、ＧＥＩ０インタフェースを用いて実施することができる。ローカル通信にＧＥＩ０インタフェースを使用することの利点は、全てのクライアントＲＴＳＰおよびゲートウェイ間のメッセージ・トラフィックを捉えるのに１つのネットワーク・パケット・スニファを使用するだけで済むので、デバッギング機能を簡略にすることができる点である。その他のタイプのインタフェース（例えばＵＳＢなど）を使用することもできる。

プロキシ・サーバ・ゲートウェイ２０は、単一のプロキシ・サーバＩＰアドレスに隠れたストリーマ・ゲートウェイ１０に一部が転送されることになるインバウンド・クライアントＲＴＳＰトラフィックのプロキシとして作用するので、実際にはリバース・プロキシである。反対に、フォワード・プロキシは、アウトバウンド・トラフィックのプロキシとして作用する。

プロキシ・サーバ・ゲートウェイ２０およびストリーマ・ゲートウェイ１０の機能性とは関係なく、全てのゲートウェイ１０および２０は、以下を提供する。
・ＤＨＣＰ（動的ホスト構成プロトコル）サーバ、
・ＭＴＦＴＰ（マルチキャスト・トリビアル・ファイル転送プロトコル）サーバ、
・プロキシ・モデム・サーバ、
・ＩＣＭＰ（インターネット制御メッセージプロトコル）「Ｐｉｎｇ」クライアント。

マルチ・ゲートウェイ・システムは、ＤＨＣＰ、ＭＴＦＴＰまたはプロキシ・モデム・サーバのうちの１つしか、１度にアクティブにしないものとする。

プロキシ・サーバ・ゲートウェイ２０の機能性
プロキシ・サーバ・ゲートウェイ２０は、以下のサービスを提供するものとする。
・クライアントの状態の収集および監視を含む、プロキシＲＴＳＰサーバ。
・ＳＮＭＰエージェントＭＩＢ（管理情報ベース）サポート。厳密には、ＤＳＦＥ（ディジタル・シグナリング・フロント・エンド）ＭＩＢがストリーマ・ゲートウェイ１０と関連付けられ、プロキシ・サーバ・ゲートウェイ２０の外部で扱われる。
・サービスが盗用されている可能性がないか検出するためのネットワーク・プロービング。

プロキシ・サーバ・ゲートウェイ２０は、ネットワーク上の全てのクライアント・デバイス（例えばＳＴＢ３５）からＲＴＳＰ要求を受信し、処理する（図１参照）。既存のＲＴＰ（リアルタイム・プロトコル）セッションを求める要求は、ストリーマ・ゲートウェイ１０を介在させずに直接処理される。新たなセッションについては、プロキシ・サーバ・ゲートウェイ２０が、１つまたは複数のＲＴＰセッション・メッセージ（付録Ａ参照）を生成し、これらを選択したストリーマ・ゲートウェイ１０に送信する。プロキシ・サーバ・ゲートウェイ２０は、好ましくは、ストリーマ・データベース２３（図２参照）などのデータベースを保持し、ストリーマ・ゲートウェイ１０間でのトリプレットの割当ておよびＲＴＰセッションをトラッキングして、ストリーマ・ゲートウェイ１０間で負荷を分散し、トリプレットの設定が重複するのを防止する。

ストリーマ・ゲートウェイ１０の機能性
ストリーマ・ゲートウェイ１０は、チューナ管理および映像データ・ポンプ機能を提供する。ストリーマ・ゲートウェイ１０は、ネットワーク（図１参照）上のクライアント・デバイス（例えばＳＴＢ３５）に対するＲＴＳＰサーバ・サポートを提供しないものとする。従って、ストリーマ・ゲートウェイ１０は、ＲＴＳＰ特有の派生クラスを実施しないものとし、また必ずしもＲＩＤ（受信者識別）やＲＩＤリストなどを使用または考慮しないものとする。

ストリーマ・ゲートウェイ１０は、プロキシ・サーバ・ゲートウェイ２０と通信して、以下の情報を交換するものとする。
・ＲＴＰセッションの制御および状態
・ハイレベル・チューナ状態
・例えばローカル・バスＳＡＰ（セッション・アナウンスメント・プロトコル）アナウンスメントを介した、ストリーマ・ネットワークの構成および状態

プロキシ・サーバ・ゲートウェイ２０がストリーマ・ゲートウェイ１０上でイネーブルされていない場合には、プロキシ・サーバ特定ＭＩＢ（ｍｘｕＲｔｓｐＳｅｒｖｅｒＣｏｎｆｉｇ、ｍｘｕＣｌｉｅｎｔＳｔａｔｕｓなど）が、「ｎｏ ｓｕｃｈ ｉｎｓｔａｎｃｅ」メッセージをＳＮＭＰクエリに戻すものとする。ここで、ｍｘｕＲｔｓｐＳｅｒｖｅｒＣｏｎｆｉｇ、およびｍｘｕＣｌｉｅｎｔＳｔａｔｕｓは、プロキシ・サーバ・ゲートウェイ２０の構成、およびそのクライアント・デバイスの状態を、それぞれ表している。

プロキシ・サーバ・ゲートウェイ２０の機能分割
プロキシ・サーバ・ゲートウェイ２０のＲＴＳＰソフトウェア・スタックは、以下のソフトウェア・モジュールを含む。

プロキシＲＴＳＰサーバの機能性の分配は、図２に示すようなものとすることが好ましい。プロキシ・サーバ・ゲートウェイ２０では、モジュール／クラスＳｔｒｅａｍｅｒおよびＲｔｓｐＳｔｒｅａｍｅｒＭｅｄｉａを作成して、複数のストリーマ・ゲートウェイ１０をモデル化して、任意のネットワーク・セット（＝メディア）を提供するものとする。各Ｓｔｒｅａｍｅｒインスタンスは、ストリーマ・ネットワークあたり１つずつ、ＰｒｏｘｙＲｔｓｐＤｓｆｅＭｅｄｉａインスタンスのリストを保持するものとする。ストリーマ・ゲートウェイ１０では、プロキシ・サーバ・ゲートウェイ２０からのローカル・バス・メッセージを処理するモジュールが設けられ、ＲＴＰライブラリ１２の１バージョン（例えば必要最低バージョンが好ましい）が、同調およびセッション情報を、チャネル取得モジュール１３を介してＤＳＦＥデバイス・モジュール１４に渡すものとする。

図３を参照すると、本発明の例示的な実施例による、図１のプロキシ・サーバ・ゲートウェイ２０が要求を処理する方法を示す図が示してある。図３では、プロキシ・サーバ・ゲートウェイ２０のＲｔｓｐＳｔｒｅａｍｅｒＭｅｄｉａモジュール３００が、クライアント要求を解析し、ストリーマ・データベース２３（図２参照）を参照して一致する要求パラメータ（ネットワーク、チューナ・パラメータ、およびＰＩＤ）を探す。一致がある場合には、プロキシ・サーバ・ゲートウェイ２０が、既存のマルチキャスト・グループＩＰアドレスを調べ、これを要求側クライアント・デバイス３５に戻す。また、プロキシ・サーバ・ゲートウェイ２０は、データベースのＲＴＰ Ｓｅｓｓｉｏｎユーザ・カウントを増分する。一致が存在しない場合には、ＲｔｓｐＳｔｒｅａｍｅｒＭｅｄｉａモジュール３００が、ストリーマ・ゲートウェイ１０を選択し、１つまたは複数のＲＴＰ Ｓｅｓｓｉｏｎコマンド（付録Ａ．１参照）を定式化し、これをローカル・バスを介して送信する。実行時ストリーマ選択では、利用可能な資源および構成設定に応じて、全てのストリーマ・ゲートウェイ１０の間でデータ負荷を分散することを試みる。プロキシ・サーバ・ゲートウェイ２０は、新たなセッションのマルチキャストＩＰアドレスを割当て、そのセットアップ応答をクライアント・デバイス３５に戻す。クライアントＲＴＳＰティアダウン（ｔｅａｒｄｏｗｎ）要求時には、ＲＴＰ Ｓｅｓｓｉｏｎユーザ・カウントを減分する。ゼロの場合には、プロキシ・サーバ・ゲートウェイ２０は、ＳｅｓｓｉｏｎＤｅｌｅｔｅメッセージを適当なストリーマ・ゲートウェイ１０に送信する。

負荷のかかったシステムでは、ストリーマ・データベース２３の大部分が一致（ヒット）して、ローカル・バスを介したＲＴＰ Ｓｅｓｓｉｏｎのメッセージングが最小限になる。プロキシ・サーバ・ゲートウェイ２０のＲＴＳＰサーバ・モジュールは、シングル・スレッドであり、要求があってから応答する間、１度に１つのクライアント要求を処理することが好ましい。ＲＴＳＰサーバ・モジュールは、ストリーマ・ゲートウェイ１０（図２参照）のＤＳＦＥデバイス・モジュール１４に同調／ＲＴＰ Ｓｅｓｓｉｏｎ要求が送信されるまで、閉鎖される。ＲＴＳＰサーバ・モジュールは、その様々な管理リストおよびマップを保護するのに、ミューテックス（相互排除）保護を必要としない、または使用しないものとする。プロキシ・サーバ・ゲートウェイ２０は、ＲＴＰセッション要求メッセージがストリーマ・ゲートウェイ１０に送信されるとすぐに、クライアント・セットアップ応答を生成する。

ストリーマ・ゲートウェイ１０は、それ自体のチューナ・プールを管理する。プロキシ・サーバ・ゲートウェイ２０は、ストリーマ・チューナ割当てを微細管理しないものとする。プロキシ・サーバ・ゲートウェイ２０は、付録Ａ．２に詳述する状態コマンドを使用して、ストリーマ・トリプレットおよびＲＴＰセッションを定期的に照会する。

上述した分割例は、チャネル取得モジュール１３およびＤＳＦＥデバイス・モジュール１４がストリーマ・ゲートウェイ１０上でのみ実行され、１０００を超えるユーザをサポートすることができる高性能で低コストのプラットフォーム（Ｌｉｎｕｘなど）にプロキシ・サーバ・ゲートウェイ２０の機能性を移植することを可能にしていることを意味している。

プロキシ・サーバ・ゲートウェイ２０は、ローカル・バスを通して送信される定期ストリーマＳＡＰアナウンスメントを介して、ストリーマ・ゲートウェイ１０の存在および動作状態を監視するものとする。

動作
・プロキシＲＴＳＰサーバＳＡＰリスナ・モジュール
プロキシ・サーバ・ゲートウェイ２０は、ストリーマ・ゲートウェイ１０のネットワークＳＡＰアナウンスメントを監視するリスナ・モジュールを提供する。リスナは、２３９．２５５．２５５．２５５ポート１９８７５など、特定のマルチキャスト・グループに加わるものとする。ストリーマ・ゲートウェイ１０が最初のＳＡＰアナウンスメントを受信すると、リスナ・モジュールは、新たなアプリケーション・タイマ（ＡｐｐＴｉｍｅｒ）インスタンスを作成し、ｋＲｔｓｐＮｅｗＳｔｒｅａｍｅｒＤｅｔｅｃｔｅｄメッセージをプロキシ・サーバ・ゲートウェイ２０に送信して、新たなストリーマ・ゲートウェイ１０が検出されたことを示す。ＡｐｐＴｉｍｅｒのコールバック機能を使用して、ストリーマＳＡＰアナウンスメントの失敗を検出する。このタイマは、次のストリーマＳＡＰアナウンスメントを受信したときに、リロードされる。タイマが満期になった場合には、リスナ・モジュールは、ｋＲｔｓｐＳｔｒｅａｍｅｒＦａｉｌｅｄメッセージをプロキシ・サーバ・ゲートウェイ２０に送信して、ストリーマ・ゲートウェイ１０が失敗し、ＡｐｐＴｉｍｅｒインスタンスを削除しなければならないことを示す。リスナ・モジュールは、オンラインに戻った失敗したストリーマ・ゲートウェイ１０を検出し、ｋＲｔｓｐＮｅｗＳｔｒｅａｍｅｒＤｅｔｅｃｔｅｄメッセージをプロキシ・サーバ・ゲートウェイ２０に送信するものとする。

・プロキシＲＴＳＰサーバ・モジュール
プロキシＲＴＳＰサーバ・モジュールは、シングル・スレッドである。プロキシＲＴＳＰサーバ・モジュールは、サービス・クライアントＳＴＢ３５へのｓｅｌｅｃｔ（）コール、ならびに内部要求およびローカル・バス要求に依存している。例示的な実施例によれば、プロキシＲＴＳＰサーバ・モジュールは、ＳＡＰアナウンスメント・モジュールを実装し、クライアントＲＴＳＰプロトコル要求を処理し、プロキシ・サーバ・データベースを管理し、１つまたは複数のストリーマ・ゲートウェイ１０との間でメッセージを送信および受信し、ＳＡＰアナウンスメント・モジュールからメッセージを受信して処理する。

ｉ．ＳＡＰリスナ・モジュールのメッセージ処理
ｋＲｔｓｐＮｅｗＳｔｒｅａｍｅｒＤｅｔｅｃｔｅｄメッセージを受信すると、プロキシ・サーバ・ゲートウェイ２０は、新たなＳｔｒｅａｍｅｒクラス／モジュール・インスタンスを作成し、適用可能なＲｔｓｐＳｔｒｅａｍｅｒＭｅｄｉａインスタンスにそのネットワークを追加するものとする。プロキシ・サーバ・ゲートウェイ２０は、Ｓｔｒｅａｍｅｒインスタンスに、アナウンスされたネットワークあたり１つのＰｒｏｘｙＲｔｓｐＤｓｆｅＭｅｄｉａインスタンスを追加する。

ｋＲｔｓｐＳｔｒｅａｍｅｒＦａｉｌｅｄメッセージを受信すると、プロキシ・サーバ・ゲートウェイ２０は、ｍｘｕＦａｉｌＤｅｔｅｃｔＧａｔｅｗａｙＳｅｒｖｉｃｅＦａｉｌｕｒｅトラップを発行し、Ｓｔｒｅａｍｅｒインスタンス、ならびにＲｔｓｐＳｔｒｅａｍｅｒＭｅｄｉａインスタンス内のそれに対応するエントリを削除する。

ｉｉ．集合体映像ネットワークＳＡＰアナウンスメント
プロキシ・サーバ・ゲートウェイ２０は、最新の集合体ネットワークＳＡＰアナウンスメントを保持し、これを定期的に映像ネットワークにマルチキャストするものとする。アナウンスメントは、２３９．２５５．２５５．２５５ポート９８７５など、既定のマルチキャスト・グループに送信しなければならない。

ブート時には、プロキシ・サーバ・ゲートウェイ２０は、どのストリーマ・ゲートウェイ１０が存在し、且つ機能しているかを判定するために、ＳＡＰアナウンスメントに一意的なｍｘｕＢａｓｅＳｔｒｅａｍｅｒＣｏｕｎｔ（システム内のストリーマの予想数を示す）を受信するまで、または２分など既定の間隔が経過するまで、その集合体ネットワークＳＡＰアナウンスメントを遅延させるものとする。システム内でローカル・コンテンツの挿入がイネーブルされている場合には、集合体アナウンスメントはネットワーク０ｘＦＦＦＥのエントリを含むものとする。

ｉｉｉ．ストリーマ選択論理
ストリーマ・ゲートウェイ１０の選択は、きめ細かく行うものとする。プロキシ・サーバ・ゲートウェイ２０は、要求されたトリプレットと一致するアクティブなトリプレットがないか、全てのＳｔｒｅａｍｅｒインスタンスを探索する。見つからない場合には、プロキシ・サーバ・ゲートウェイ２０は、例えば下記のように計算される負荷率が最低であるストリーマ・ゲートウェイ１０を認定して選択する。
ストリーマ・ゲートウェイ１０の負荷率＝現在の負荷／負荷設定点

絶対負荷値ではなく負荷率値を用いることにより、負荷担持能力の異なるストリーマ・ゲートウェイ１０の共存および／またはシステムへのシームレスな追加が可能になる。

この選択論理では、クライアント要求および現在の負荷率統計値に基づいて、認定ストリーマ・ゲートウェイ１０の順序付きリストを作成する。負荷の軽いストリーマ・ゲートウェイ１０の方が、負荷の重いストリーマ・ゲートウェイ１０より優先される。プロキシ・サーバおよびストリーマの両方の機能性を有するゲートウェイへの負荷を制限するために、負荷設定点は、最大負荷設定の何分の１かに設定することができる。その結果、外部のストリーマ・ゲートウェイ１０の方が負荷率が低いので、プロキシ・サーバ・ゲートウェイ２０は、外部のストリーマ・ゲートウェイ１０を優先する傾向がある。

図４を参照すると、本発明の例示的な実施例による、図１のプロキシ・サーバ・ゲートウェイ２０がストリーマ・ゲートウェイ１０を選択する方法をさらに詳細に示す図が示してある。具体的には、一例としてＣ＋＋クラスを用いて、図４では、ストリーマ・ゲートウェイ１０の選択、ならびにストリーマ・ゲートウェイ１０が複数あるシステムにおいてクライアントＲＴＳＰセットアップ要求がどのように処理されるかを示している。選択論理の擬似コードは、以下の通りである。
ストリーマ選択：
既存のトリプレット一致を探す
ｆｏｒ全てのストリーマの全てのＰｒｏｘｙＲｔｓｐＤｓｆｅＭｅｄｉａインスタンス
ｆｏｒ要求されたネットワークおよび偏波に一致する全てのメディア
ｉｆ既存のスロットがトリプレット一致を含む
ストリーマＩＤを返す
ｅｎｄ
ｅｎｄ
既存のトリプレットがアクティブでなく、ストリーマを選択する必要がある
認定ストリーマの作成されたリスト
ｆｏｒ全てのストリーマの全てのＰｒｏｘｙＲｔｓｐＤｓｆｅＭｅｄｉａインスタンス
ｆｏｒ要求されたネットワークおよび偏波に一致する全てのメディア
ｉｆストリーマ負荷が所定最大帯域幅限界を超える
ストリーマをリストに含めない
ｉｆメディアが既にＦａｉｌｅｄとマークされている
その失敗のタイムスタンプに基づいて（失敗の古いものから先に）ストリーマを順序付ける
ｅｌｓｅ
小さなディザを現在の負荷統計値に付加する
その現在の負荷率統計値に基づいて（負荷の小さいものから先に）ストリーマを順序付ける
ｅｎｄ
ｅｎｄ
リストの最初のストリーマＩＤを返す

ｉｖ．最大クライアント制限
プロキシ・サーバ・ゲートウェイ２０は、ＴＣＰ接続数などのメトリクスに基づいて、クライアント・デバイス（例えばＳＴＢ３５）の最大数を施行するものとする。好ましいデフォルト最大数は、クライアント・デバイスの接続数で５００である。最大数に達すると、新たなＴＣＰ接続要求をサイレントに拒絶することができる。クライアント・デバイス数は、有効なＳＷ Ｌｉｃｅｎｓｅ Ｋｅｙから抽出した設定で置き換えることもできる。

最大接続数がアクティブであって、新たな接続要求を受信した場合には、プロキシ・サーバ・ゲートウェイ２０は、ＳＮＭＰトラップを送信するものとする。トラップは、この状況が最初に発生したときに送信され、その後は所定の発生回数ごとに送信されるものとする。プロキシ・サーバ・ゲートウェイ２０は、ＲＩＤに基づいて最大クライアント数を施行することもできる。プロキシ・サーバ・ゲートウェイ２０は、例えば、最大数のＲＴＳＰクライアント・デバイスにサービスを行っているときに、新たなＲＩＤからＲＴＳＰセットアップ要求を受信した場合には、５０３：ＳｅｒｖｉｃｅＵｎａｖａｉｌａｂｌｅ応答を送信することもできる。

・ゲートウェイ間通信
プロキシ・サーバ・ゲートウェイ２０とストリーマ・ゲートウェイ１０の間のローカル・バス通信は、ＵＤＰを介して行うものとする（図２参照）。メッセージのタイプおよびフォーマットは、付録Ａに列挙するが、コマンド文字列と、その後に続く１つまたは複数のパラメータ要求フィールドまたはパラメータ設定フィールドとからなるＡＳＣＩＩ可読フィールドを含むものとする。パラメータ・フィールドは、＜ＣＲ＞＜ＬＦ＞によって区切られている。各メッセージは、コマンド・シーケンス番号（ＣＳｅｑ）フィールドおよびコンテンツ長（Ｃｏｎｔｅｎｔ−ｌｅｎｇｔｈ）フィールドを含むものとする。

プロキシ・サーバ・ゲートウェイ２０は、ストリーマ・ゲートウェイ１０との全ての通信を開始するものとする。例えば、プロキシ・サーバ・ゲートウェイ２０がクライアント（マスタ）であり、ストリーマ・ゲートウェイ１０がサーバ（スレーブ）である。ストリーマ・ゲートウェイ１０のサーバ・ソケットは、ポート１５５４など、特定のＵＤＰポートに束縛されるものとする（図２参照）。プロキシ・サーバ・ゲートウェイ２０は、１５５５など特定のポートにおいて単一のＵＤＰソケットを作成して、全てのストリーマ・ゲートウェイ１０と通信する。

プロキシ・サーバ・ゲートウェイ２０は、送信カウンタおよび受信カウンタを用いて、メッセージ送達の成功を監視するものとする。送信カウンタは、プロキシ・サーバ・ゲートウェイ２０がストリーマ・ゲートウェイ１０にメッセージを送信したときに増分されるものとする。受信カウンタは、プロキシ・サーバ・ゲートウェイ２０がストリーマ・ゲートウェイ１０から確認を受信したときに増分されるものとする。各メッセージは、確認に含めて戻される一意的な送信順序番号を有するものとする。とりわけ、負荷のかかったシステムからのデータが許容不可能な量のメッセージ損失を示す場合には、ＴＣＰメッセージングも使用することができる。各メッセージのフォーマットの詳細については、付録Ａを参照されたい。

ｖ．ＲＴＰセッション・メッセージ
プロキシ・サーバ・ゲートウェイ２０は、３つのタイプのＲＴＰ Ｓｅｓｓｉｏｎメッセージをストリーマ・ゲートウェイ１０に送信する。
プロキシ・サーバからストリーマへのメッセージ 用途
ＳｅｓｓｉｏｎＡｄｄ ｒｅｑｕｅｓｔ ストリームを開始する
ＳｅｓｓｉｏｎＵｐｄａｔｅ ｒｅｑｕｅｓｔ ストリームを更新する
ＳｅｓｓｉｏｎＤｅｌｅｔｅ ｒｅｑｕｅｓｔ ストリームを停止する
ストリーマからプロキシ・サーバへのメッセージ 用途
Ｓｅｓｓｉｏｎ ｒｅｑｕｅｓｔ ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ
メッセージの成功をトラッキングする

ｖｉ．状態要求メッセージ
プロキシ・サーバ・ゲートウェイ２０は、２つのタイプの状態要求メッセージをストリーマ・ゲートウェイ１０に送信する。
プロキシ・サーバからストリーマへのメッセージ 用途
Ｓｔｒｅａｍｅｒ Ｓｔａｔｕｓ ｒｅｑｕｅｓｔ ストリーマの負荷統計値およびトリプレットの状態を要求する
Ｓｅｓｓｉｏｎ Ｓｔａｔｕｓ ｒｅｑｕｅｓｔ トリプレットのＲＴＰセッション状態を要求する
ストリーマからプロキシ・サーバへのメッセージ 用途
Ｓｔｒｅａｍｅｒ Ｓｔａｔｕｓ ｒｅｑｕｅｓｔ ｒｅｓｐｏｎｓｅ
プロキシ・サーバのストリーマ・データベースを更新する
Ｓｅｓｓｉｏｎ Ｓｔａｔｕｓ ｒｅｑｕｅｓｔ ｒｅｓｐｏｎｓｅ
プロキシ・サーバのストリーマ・データベースを更新する

Ｓｔａｔｕｓ Ｒｅｑｕｅｓｔのポーリング間隔は、２秒とする。これは、ＭＩＢ設定可能ではない。

・ストリーマ・ゲートウェイ１０の状態報告
ストリーマ・ゲートウェイ１０は、アクティブなトリプレットのリストを保持し、この情報を、Ｓｔａｔｕｓ Ｒｅｑｕｅｓｔ応答メッセージに含めて戻す。割り当てられたトリプレットは、良好（Ｓｔ：Ｄ１）または失敗（Ｓｔ：Ｄ０）として報告される。チューナがロックを失ったとき、またはチューナを同調させることができないときには、ストリーマ・ゲートウェイ１０は、自動的に別の空いているチューナを使用して、同調要求に応えようとするものとする。ストリーマ・ゲートウェイ１０が全ての利用可能なチューナを試して失敗に終わった場合には、このトリプレットのＳｔａｔｕｓ Ｒｅｑｕｅｓｔエントリは、「失敗」（Ｓｔ：Ｄ０）を示すことになる。

プロキシ・サーバ・ゲートウェイ２０は、トリプレットの状態を使用して、そのデータベース中のチューナを表す対応する（１つまたは複数の）ＤｓｆｅＳｅｔｔｉｎｇスロットを調べるものとする。トリプレットの状態が「失敗」を示している場合には、プロキシ・サーバ・ゲートウェイ２０は、そのデータベースを更新し、当該スロットを「失敗」としてマークするものとする。スロット失敗時間は、現在の時間に設定されるものとする。プロキシ・サーバ・ゲートウェイ２０は、失敗したトリプレットに関連する全てのＲＴＰセッションをティアダウンし、クライアントＲＴＳＰクッキーをリセットするものとする。これらのクッキーは、クライアントＲＴＳＰセッションを、要求されたプログラムを担持するその下のＲＴＰセッションと関係付けるものである。

ｖｉｉ．プロキシ・サーバのエラー処理
各スロット資源は、監視カウンタを保持するものとする。このカウンタは、対応するトリプレットの状態をストリーマ・ゲートウェイ１０から受信したときに、例えば３などの既定の数にリセットされる。ストリーマ・ゲートウェイ１０がプロキシ・サーバ・ゲートウェイ２０が以前に追加したトリプレットを肯定応答しない場合には、このカウンタは減分される。カウンタがゼロになると、スロットはタイムアウトし、以下の措置がとられるものとする。
・動的スロットの場合（すなわち関連するチューナが動的に同調される場合）には、プロキシ・サーバ・ゲートウェイ２０は、ＳｅｓｓｉｏｎＵｐｄａｔｅメッセージをストリーマ・ゲートウェイ１０に送信して、全ての関連するＲＴＰセッションのセッション更新を示すものとする。
・静的スロットの場合（関連するチューナが静的に同調される場合）には、プロキシ・サーバ・ゲートウェイ２０は、このトリプレットについての全てのＲＴＰセッションを内部で削除し、スロットを削除するものとする。

プロキシ・サーバ・ゲートウェイ２０は、未知のトリプレットを含むトリプレット状態メッセージを受信した場合には、セッションが削除されることになることを示すＳｅｓｓｉｏｎＤｅｌｅｔｅメッセージを、２５５．２５５．２５５．２５５など既定の宛先ＩＰアドレスとともに、その未知のトリプレットを含むストリーマ・ゲートウェイ１０に送信するものとする。ストリーマ・ゲートウェイ１０は、このトリプレットに関連する全てのＲＴＰセッションをティアダウンし、チューナ資源を解放するものとする。

静的同調サポート
静的同調は、衛星ケーブル・フィードおよび／またはチューナ動作を妥当性検査するために使用されるトラブルシューティング・モードである。スロットのタイプ（静的／動的）およびトリプレットの状態を除けば、プロキシ・サーバ・ゲートウェイ２０は、静的か動的かに係わらず、ストリーマ・ゲートウェイ１０のチューナ割当てを管理またはトラッキングしないものとする。

静的チューナは、ストリーマ・ゲートウェイ１０の状態応答メッセージ（Ｓｔ：Ｓ１からＳｔ：Ｓ３２）中に示される。ストリーマ・ゲートウェイ１０が既存の（動的）ＲＴＰセッションを空いているチューナに移動させることができない場合には、ストリーマ・ゲートウェイ１０は、既存のトリプレットについて動的同調が失敗である（Ｓｔ：Ｄ０）ことを示し、プロキシ・サーバ・ゲートウェイ２０は、ストリーマ・ゲートウェイ１０にティアダウンを送信するものとする。静的同調の変化に関連するＲＴＰセッション上に見られる映像のグリッチは、許容範囲であるものとする。

ストリーマ・ゲートウェイ１０のＳＡＰアナウンサ
ストリーマ・ゲートウェイ１０のネットワーク・アナウンスメントは、２３９．２５５．２５５．２５５ポート１９８７５など、既定のローカル・バス・マルチキャスト・グループに送信されるものとする。負荷分散をサポートするために、以下のストリーマ・ゲートウェイ１０のＳＡＰアナウンスメント機能が必要になることがある。

ＳＤＰセッション帯域幅
ストリーマ・アナウンスメントは、以下の新たなＳＤＰセッション帯域幅属性を提供するものとする。

設定点および最大負荷の情報は、ＭＩＢ要素ｍｘｕＳｔｒｅａｍｅｒＣｏｎｆｉｇＭａｘＬｏａｄおよびｍｘｕＳｔｒｅａｍｅｒＣｏｎｆｉｇＬｏａｄＳｅｔｐｏｉｎｔによって設定される。

ＳＤＰセッション接続情報
ストリーマ・メディア接続情報（ｃ）は、実際には、ネットワークごとではなくストリーマごとに設定されるので、ネットワークＳＡＰアナウンスメントＳＤＰメディア属性接続情報（ｃ）は、単一のＳＤＰセッション属性となるものとする。マルチキャストの開始および範囲の情報は、ＭＩＢ要素、ｍｘｕｌｐＳｅｒｖｉｃｅｓＡｄｄｒＭｃａｓｔＳｔａｒｔおよびｍｘｕｌｐＳｅｒｖｉｃｅｓＡｄｄｒＭｃａｓｔＥｎｄによって設定される。

ＳＤＰメディア情報Ｘ−ｄｓｆｅ−ｃｏｕｎｔ
アナウンスメントは、サポートされているネットワークと、所与の偏波設定でのチューナ数とを示すものとする。ネットワークＳＡＰアナウンスメントＳＤＰメディア属性Ｘ−ｄｓｆｅ−ｃｏｕｎｔは、以下のようなものとする。

代表的なストリーマＳＡＰアナウンスメント
例１：ストリーマ・ゲートウェイ１０が、以下のように、（ＮＷ０Ｌ、ＮＷ１５Ｌ＋Ｒ、およびＮＷ１Ｈ）用に構成される。
ＮＷ０Ｌ： チューナ１〜１２。
ＮＷ１５Ｌ： チューナ１〜１２。チューナ数を２で割る（レガシー・チューナはカウントしない）。
ＮＷ１５Ｒ： チューナ１３〜２４。チューナ数を２で割る（レガシー・チューナはカウントしない）。
ＮＷ１Ｈ： チューナ２４〜３２。

対応するＳＡＰアナウンスメントは、以下の通りである。
セッション・アナウンスメント・プロトコル
発信ソース：１０．０．３０．７
ペイロード・タイプ：アプリケーション／ｓｄｐ
セッション記述プロトコル
セッション記述プロトコル・バージョン（ｖ）：０
所有者／作成者、セッションＩｄ（ｏ）：−０ １ ＩＮ ＩＰ４ １０．０．３０．７
セッション名（ｓ）：ＳＥＲＶＩＣＥＰＲＯＶＩＤＥＲＮＡＭＥ
セッション情報（ｉ）：ＳＥＲＶＩＣＥＰＲＯＶＩＤＥＲＮＡＭＥコンテンツ
接続情報（ｃ）：ＩＮ ＩＰ４ ２３９．２５５．０．０／１２８／２０４８
帯域幅情報（ｂ）：Ｘ−ｌｏａｄ：１００／８００
メディア記述、名称およびアドレス（ｍ）：データ １０２４ ＲＴＰ／ＡＶＰ ９６
メディア・タイトル（ｉ）：ネットワーク０
メディア属性（ａ）：ｃｏｎｔｒｏｌ：ｒｔｓｐ：／／１０．０．３０．７／ＳＥＲＶＩＣＥＰＲＯＶＩＤＥＲＮＡＭＥ／ネットワーク０
メディア属性（ａ）：Ｘ−ｄｓｆｅ−ｃｏｕｎｔ：１２／０
メディア記述、名称およびアドレス（ｍ）：データ １０２４ ＲＴＰ／ＡＶＰ ３３
メディア・タイトル（ｉ）：ネットワーク１５
メディア属性（ａ）：ｃｏｎｔｒｏｌ：ｒｔｓｐ：／／１０．０．３０．７／ＳＥＲＶＩＣＥＰＲＯＶＩＤＥＲＮＡＭＥ／ネットワーク１５
メディア属性（ａ）：Ｘ−ｄｓｆｅ−ｃｏｕｎｔ：６／６
メディア記述、名称およびアドレス（ｍ）：データ １０２４ ＲＴＰ／ＡＶＰ ９６
メディア・タイトル（ｉ）：ネットワーク１
メディア属性（ａ）：ｃｏｎｔｒｏｌ：ｒｔｓｐ：／／１０．０．３０．７／ＳＥＲＶＩＣＥＰＲＯＶＩＤＥＲＮＡＭＥ／ネットワーク１
メディア属性（ａ）：Ｘ−ｄｓｆｅ−ｃｏｕｎｔ：８／０

例２：ＩＰアドレス１０．０．３０．３に位置する１０ＧＢＰＳが可能（８０００ＭＢＰＳ使用可能）なＬＣＩストリーマ・ゲートウェイ１０が、以下のように、ネットワークＦＦＦＥ（＝６５５３４（１０進））用に構成される。
ＮＷ ＦＦＦＥ：４つのローカル・チャネルが利用可能であり、加えてプログラム・ガイド・チャネルがある。ストリーマ・ゲートウェイ１０は、ベース・マルチキャストＩＰアドレス２３９．２５５．１００．０を使用する。

対応するＳＡＰアナウンスメントは、以下の通りである。
セッション・アナウンスメント・プロトコル
発信ソース：１０．０．３０．３
ペイロード・タイプ：アプリケーション／ｓｄｐ
セッション記述プロトコル
セッション記述プロトコル・バージョン（ｖ）：０
所有者／作成者、セッションＩｄ（ｏ）：−０ １ ＩＮ ＩＰ４ １０．０．３０．３
セッション名（ｓ）：ＳＥＲＶＩＣＥＰＲＯＶＩＤＥＲＮＡＭＥ
セッション情報（ｉ）：ＬＯＣＡＬコンテンツ
接続情報（ｃ）：ＩＮ ＩＰ４ ２３９．２５５．１００．０／１２８／５
帯域幅情報（ｂ）：Ｘ−ｌｏａｄ：８０００／８０００
メディア記述、名称およびアドレス（ｍ）：データ １０２４ ＲＴＰ／ＡＶＰ ３３
メディア・タイトル（ｉ）：ネットワーク６５５３４
メディア属性（ａ）：ｃｏｎｔｒｏｌ：ｒｔｓｐ：／／１０．０．３０．３／ＳＥＲＶＩＣＥＰＲＯＶＩＤＥＲＮＡＭＥ／ネットワーク６５５３４
メディア属性（ａ）：Ｘ−ｄｓｆｅ−ｃｏｕｎｔ：５／０

動的アナウンスメント
ストリーマ・ゲートウェイ１０は、そのＳＡＰアナウンスメント・コンテンツを定期的に更新して、失敗チューナ情報または変更を帯域幅設定点に組み込むこともできる。プロキシ・サーバ・ゲートウェイ２０は、それに応じてそのデータベースを更新することになる。

ゲートウェイ・リブート・シナリオ
ゲートウェイ・リブートは、３つのカテゴリに分類される。
・全てのゲートウェイ１０および２０のリブート
・１つまたは複数のストリーマ・ゲートウェイ１０のリブート
・プロキシ・サーバ・ゲートウェイ２０のみのリブート

ここで関係があるのは、以下のように最後の２つのケースである。

ストリーマのみのリブート
プロキシ・サーバ・ゲートウェイ２０は、ｋＲｔｓｐＳｔｒｅａｍｅｒＦａｉｌｅｄメッセージおよびｋＲｔｓｐＮｅｗＳｔｒｅａｍｅｒＤｅｔｅｃｔｅｄメッセージを使用して、ストリーマ・ゲートウェイ１０の失敗および／またはリブートを示す。失敗ストリーマ・ゲートウェイ１０は、ストリーマ・データベースから除去され、残りのストリーマ・ゲートウェイ１０の間でデータ負荷が再分配されるものとする。同様に、新たに動作状態になったストリーマは、シームレスにデータベースに追加され、時間経過とともに、映像負荷がストリーマ・ゲートウェイ１０の集団の中で再分配されるものとする。

プロキシ・サーバのみのリブート
設計目標は、プロキシ・サーバ・ゲートウェイ２０のリブートによる映像の破壊を最小限に抑えることである。プロキシ・サーバ・ゲートウェイ２０のブート・シーケンスは、以下の通りである。
１．ストリーマＳＡＰアナウンスメントを検出する
２．検出された各ストリーマ・ゲートウェイ１０について、
２．１ ＳＥＳＳＩＯＮＤＥＬＥＴＥ（Ａｌｌ）要求を送信し、全ての既存のストリーマセッションをティアダウンする

ブートアップに続いて、プロキシ・サーバ・ゲートウェイ２０は、既知の全てのストリーマ・ゲートウェイ１０に対して、ストリーマ・トリプレットおよびＲＴＰセッション状態を要求するものとする。プロキシ・サーバ・ゲートウェイ２０は、任意のクライアントＲＴＳＰ要求を処理する前に、そのデータベースを再構築しなければならない。

プロキシ・サーバのブート・シーケンスは、以下のようなものでもよい。
１．ストリーマ・ゲートウェイ１０のＳＡＰアナウンスメントを検出する
２．検出された各ストリーマ・ゲートウェイ１０について、
２．１ ＳＴＲＥＡＭＥＲＳＴＡＴＵＳ要求を送信して、どのトリプレットがアクティブであるかを把握する
２．１．１ アクティブなトリプレットのそれぞれについて、ＳＥＳＳＩＯＮＳＴＡＴＵＳ要求を送信して、どのＲＴＰセッションがアクティブであるかを把握する
３．プロキシ・サーバ・フロント・エンド（サービス・クライアント要求）をイネーブルする

ローカル・コンテンツの挿入
（１つまたは複数の）ＬＣＩ（ローカル・コンテンツ挿入）ストリーマ・ゲートウェイ１０は、１つまたは複数の独立型ＰＣおよび／またはダム（ｄｕｍｂ）ＩＰカメラであるものとする。予約ＰＩＤ（０ｘＦＦ０−０ｘＦＦＦ）を含む任意のネットワークのクライアント・セットアップ要求は、通常のＲＴＳＰプロキシ・サーバ／ストリーマ動作をバイパスする。プロキシ・サーバ・ゲートウェイ２０は、要求されたＰＩＤおよびトランスポンダ番号に基づいてマルチキャスト・グループ・オフセットを決定するものとする。各ストリーマ・ゲートウェイ１０（それぞれについてＰＩＤが１つ予約される）は、トランスポンダの周波数設定あたり１つずつ、チャネル（マルチキャスト・グループ）を１６個までサポートすることもできる。

ダムＩＰカメラ
プロキシ・サーバ・ゲートウェイ２０は、イネーブルされるとローカル・コンテンツ・プログラム・ガイドを生成し、ストリーミングする、分離したアプリケーション・モジュールを提供するものとする。このアプリケーションは、ローカル・バス上のネットワークＦＦＦＥ ＳＡＰアナウンスメントも生成して、ローカル・コンテンツ・ベース・マルチキャストＩＰアドレスを示すものとする。ＳＡＰアナウンスメント接続情報は、全てのストリーマ・ゲートウェイ１０のローカル・コンテンツ・ベース・マルチキャストＩＰアドレスを示す。また、ＳＡＰアナウンスメント接続情報は、利用可能なローカル・チャネル数を示すこともできる。

ＰＣストリーマ・ゲートウェイ１０
ＰＣストリーマ・ゲートウェイ１０は、ネットワークＦＦＦＥ用の、それ自体のストリーマＳＡＰアナウンスメントを生成することになる。また、ＰＣストリーマ・ゲートウェイ１０は、ストリーマのマルチキャストの範囲内で、１つまたは複数のマルチキャスト・グループの最小のプログラム・ガイドも生成することになる。

クラス例（プロキシ・サーバ・ゲートウェイ２０）

・ＲｔｓｐＳｔｒｅａｍｅｒＭｅｄｉａクラス
ネットワークあたり１つのインスタンスが作成される。
プライベート・データ：
−ネットワーク・パス（セッション名およびメディア・タイトル）
−当該ネットワークをサポートするストリーマ・ゲートウェイ・インスタンスのリスト
−当該ネットワークとともに使用中のメディア・クッキーのマップ
−その他

・ストリーマ・ゲートウェイ１０クラス
ストリーマ・ゲートウェイ１０あたり１つのインスタンスが作成される。
プライベート・データ：
−ストリーマ・ゲートウェイ１０のＩＰアドレスおよびサーバ・ポート
−帯域幅設定および現在の負荷統計値
−ストリーマ・ゲートウェイ１０のキープアライブ・タイマ
−マルチキャスト・アドレス・ファクトリ・インスタンスｐｔｒ
−ストリーマ・ネットワークあたり１つのＰｒｏｘｙＲｔｓｐＤｓｆｅＭｅｄｉａインスタンスのリスト
−ポート１５５４に束縛されたストリーマＵＤＰソケットのファイル記述子
−その他

・ＰｒｏｘｙＲｔｓｐＤｓｆｅＭｅｄｉａクラス
ネットワークあたりのストリーマ・ゲートウェイ１０あたり１つのインスタンスが作成される。
プライベート・データ：
−メディア・タイトルおよびネットワーク番号
−ＲＴＳＰ統計値（数値設定、解析エラーなど）
−当該メディア・インスタンスのｐｒｏｘｙＲｔｐＬｉｂｒａｒｙインスタンスｐｔｒ
−その他

・ＴｒｉｐｌｅｔＭｅｄｉａＣｏｏｋｉｅクラス
クライアントＲＴＳＰセッションあたり１つのインスタンスが作成され、ＲｔｓｐＳｅｒｖｅｒＣｏｎｎｅｃｔｉｏｎインスタンスに格納される。
プライベート・データ：
−ストリーマ・インスタンスｐｔｒ
−Ｔｒｉｐｌｅｔ
−ＰｉｄＬｉｓｔ

・スロット・クラス
ストリーマ・ゲートウェイ１０のトリプレットあたり１つのインスタンスが作成される。
プライベート・データ：
−当該スロットのＤＳＦＥ設定
−Ｔｒｉｐｌｅｔ
−スロット監視カウンタ
−ＴｒｉｐｌｅｔＲｔｐＳｅｓｓｉｏｎリスト
−スロット・タイプ（静的／動的）
−その他

・ＴｒｉｐｌｅｔＲｔｐＳｅｓｓｉｏｎクラス
ストリーマＲＴＰセッションあたり１つのインスタンスが作成され、ストリーマ・スロット・リストに格納される。
プライベート・データ：
−関連するスロットのＤＳＦＥ設定へのｐｔｒ
−Ｔｒｉｐｌｅｔ
−ＰｉｄＬｉｓｔ
−マルチキャスト宛先アドレスおよびポート
−その他

・ＡｐｐＴｉｍｅｒクラス
ストリーマ・ゲートウェイ１０あたり１つのインスタンスが作成される。
プライベート・データ：
−Ｏ／Ｓタイマ・インスタンス
−タイマ・リロード値

・ＳＡＰＡｎｎｏｕｎｃｅｍｅｎｔクラス
検出されたストリーマ・ゲートウェイ１０あたり１つのインスタンスが作成される。
プライベート・データ：
−データ・バッファ、ストリーマ・ゲートウェイ１０からの最も最近のＳＡＰアナウンスメントを保持する

モジュール例

１．プロキシ・サーバ・ゲートウェイ２０

ＳＡＰリスナ・モジュール：
プロキシ・サーバ・ゲートウェイ２０は、ＳＡＰリスナ・モジュールを実施しなければならない。このモジュールは、以下の新たなメッセージ・タイプを、プロキシＲＴＳＰサーバ・モジュールに送信する。
・ストリーマ・ゲートウェイ１０ＳＡＰアナウンスメント受信
・ストリーマ・ゲートウェイ１０ＳＡＰアナウンスメント・タイムアウト

プロキシＲＴＳＰサーバ・モジュール：
前述のように、プロキシＲＴＳＰサーバ・モジュールは、１．ｘＲｔｓｐＤｓｆｅＭｅｄｉａクラスの代わりに、新たなＳｔｒｅａｍｅｒクラス、ＲｔｓｐＳｔｒｅａｍｅｒＭｅｄｉａクラス、およびＰｒｏｘｙＲｔｓｐＤｓｆｅＭｅｄｉａクラスを使用しなければならない。
・ＳＡＰリスナ・モジュール・メッセージのサポートを提供しなければならない
・集合体ネットワークＳＡＰアナウンスメントを生成しなければならない
・ストリーマ・ゲートウェイ１０のメッセージを送受信するためのメッセージング機能を実施しなければならない
・その他

ストリーマ・ゲートウェイ１０およびプロキシ・サーバ・ゲートウェイ２０が同じゲートウェイ・シャーシ内に存在するときには、プロキシ・サーバ・ゲートウェイ２０の開始コードは、ストリーマ・ゲートウェイ１０の開始コードとは無関係である。

プロキシ・サーバ・モジュールは、ＲＴＳＰ統計値を戻し、ＲＴＳＰ ＳｅｔｕｐＰａｒｓｅＥｒｒｏｒ（解析エラーを示す）トラップおよびＳｅｒｖｅｒＴｅｒｍｉｎａｔｅｄＳｅｓｓｉｏｎ（セッション終了を示す）トラップを発行するものとする。ＤｓｆｅＡｌｌｏｃａｔｉｏｎＥｒｒｏｒトラップおよびＭｃａｓｔＡｌｌｏｃａｔｉｏｎＥｒｒｏｒトラップは、ストリーマ・ゲートウェイ１０のＲＴＰライブラリ１２（図２参照）によって処理されるものとする。

２．ストリーマ・ゲートウェイ１０
各ストリーマ・ゲートウェイ１０は、ローカル・バス・ソケットを監視するモジュールを実施する。このモジュールは、一般に、以下のようにＲＴＳＰスタックをエミュレートする。
・存在する各ネットワークについて、ＲｔｓｐＤｓｆｅＭｅｄｉａおよびＲＴＰＬｉｂｒａｒｙインスタンスを作成する
・ＲｔｓｐＳｅｓｓｉｏｎおよびＲｔｓｐＤｓｆｅＭｅｄｉａ構成ファイル設定に基づいて、ローカル・バス上のネットワークＳＡＰアナウンスメントを生成する
・例えばポート１５５４のローカル・バスＵＤＰソケットを作成する
・プロキシ・サーバ・ゲートウェイ２０のメッセージを送受信するメッセージング機能を実施する
・プロキシ・サーバＲＴＰセッション要求をフィールディング（ｆｉｅｌｄ）する
・チューナおよびＦＰＧＡ／データ・ポンプの機能性を管理する

ＲＴＰライブラリ・インタフェース・モジュールは、プロキシ・サーバのストリーマ状態要求メッセージへの応答に使用されるトリプレット状態コードを戻すように機能強化しなければならない。ストリーマ・サーバの開始コードは、プロキシＲＴＳＰサーバの開始コードとは無関係であるものとする。

構成パラメータ例
ブート時には、以下の構成ファイル／ＳＮＭＰ ＭＩＢパラメータを確認して、ゲートウェイを構成する。

ｍｘｕＲｔｓｐＳｅｒｖｅｒＣｏｎｆｉｇＰｒｏｘｙＥｎａｂｌｅが真である場合には、プロキシＲＴＳＰサーバ・モジュールが開始される。偽である場合には、構成設定は無視され、偽として扱われる。
・ｍｘｕＮｅｔｗｏｒｋＡｕｄｉｔＡｄｍｉｎＥｎａｂｌｅｄ
ｍｘｕＲｔｓｐＳｅｒｖｅｒＣｏｎｆｉｇＳｔｒｅａｍｅｒＣｏｕｎｔは、ブート時にプロキシ・サーバ・ゲートウェイ２０によって使用されて、システム内のストリーマ・ゲートウェイ１０の予想数を示す。プロキシ・サーバ・ゲートウェイ２０は、ｍｘｕＲｔｓｐＳｅｒｖｅｒＣｏｎｆｉｇＳｔｒｅａｍｅｒＣｏｕｎｔに一意的なＳＡＰアナウンスメントを受信するまで、または２分など既定の間隔が経過するまで、集合体ネットワークＳＡＰアナウンスメントを遅延させる。

ｍｘｕＳｔｒｅａｍｅｒＣｏｎｆｉｇＳｔｒｅａｍｅｒＥｎａｂｌｅが真である場合には、ストリーマ・ゲートウェイ１０のＳＡＰアナウンサがイネーブルされる。偽である場合には、ストリーマ・ゲートウェイ１０のＳＡＰアナウンスメントがディセーブルされ、プロキシ・サーバ・ゲートウェイ２０は、当該ストリーマ・ゲートウェイ１０に新たなＲＴＰセッション要求を送信しないものとする。

ＡＰＩ例
これらのＡＰＩは、大域的にアクセス可能なＡＰＩである。

ｂｏｏｌ ｉｓＰｒｏｘｙＳｅｒｖｅｒ（ｖｏｉｄ）
この機能は、構成ファイル・パラメータｍｘｕＲｔｓｐＳｅｒｖｅｒＣｏｎｆｉｇＰｒｏｘｙＥｎａｂｌｅのブート状態を戻す。

ｂｏｏｌ ｉｓＳｔｒｅａｍｅｒ（ｖｏｉｄ）
この機能は、ブート時に１つまたは複数のアクティブなｍｘｕＲｔｓｐＤｓｆｅＭｅｄｉａＣｏｎｆｉｇＲｏｗＳｔａｔｕｓ構成ファイル・エントリがある場合に、真を戻す。さらに、少なくとも１つのアクティブなｍｘｕＲｔｓｐＳｅｓｓｉｏｎＣｏｎｆｉｇＲｏｗＳｔａｔｕｓエントリが存在しなければならない。

使用例：ＳＮＭＰエージェントが、このＡＰＩを使用して、ＲＴＳＰサーバＭＩＢへのＭＩＢアクセスを調節する。

ｂｏｏｌ ｉｓＡｃｔｉｖｅＳｔｒｅａｍｅｒ（ｖｏｉｄ）
この機能は、ｍｘｕＳｔｒｅａｍｅｒＣｏｎｆｉｇＳｔｒｅａｍｅｒＥｎａｂｌｅおよびｉｓＳｔｒｅａｍｅｒ（）が両方とも真である場合に、真を戻す。

使用例：ストリーマ・ゲートウェイ１０が、このＡＰＩを使用して、ＳＡＰアナウンスメントを調節する。

本発明の原理によれば、プロキシ・サーバ・ゲートウェイ２０は、２０００超のクライアント・デバイス（例えばＳＴＢ３５）をサポートすることができるものとする。ＳＴＢクライアントの要求モジュールは、ポート５５４など既定のポートにおいてＵＤＰソケットを露出させ、ＵＤＰベースのＳＴＢクライアントをサポートするものとする。

次に、図５を参照すると、本発明の例示的な実施例による、図１のプロキシ・サーバ・ゲートウェイ２０を動作させるステップを示す流れ図５００が示してある。図５に示す各ステップは、単なる例示であり、いかなる意味においても本発明を限定するものではない。

ステップ５１０で、プロキシ・サーバ・ゲートウェイ２０は、クライアント・デバイスＳＴＢ３５から要求信号を受信する。例示的な実施例では、要求信号は、特定のプログラムを要求側クライアント・デバイスＳＴＢ３５にダウンロード（すなわちストリーミング）することを求める要求を示す。

ステップ５２０で、プロキシ・サーバ・ゲートウェイ２０は、ステップ５１０で受信した要求を受け入れるためにストリーマ・ゲートウェイ１０から新たなチューナを割り当てる必要があるかどうかを判定する。例えば、ストリーマ・ゲートウェイ１０の１つが、要求されたプログラムを担持する信号ソース（例えばトランスポンダ）に既に同調している場合には、新たなチューナは必要ない。あるいは、ストリーマ・ゲートウェイ１０の１つが、要求されたプログラムを担持する信号ソースにまだ同調していない場合には、新たなチューナが必要である。

ステップ５２０の判定結果が肯定である場合には、プロセス・フローはステップ５３２０に進み、プロキシ・サーバ・ゲートウェイ２０は、ストリーマ・ゲートウェイ１０からそれぞれの負荷指標を受信する。例示的な実施例によれば、負荷指標は、各ストリーマ・ゲートウェイ１０の負荷率設定点を示す。プロキシ・サーバ・ゲートウェイ２０が各ストリーマ・ゲートウェイ１０に関連する現在の負荷指標を常に把握しておくことができるように、ステップ５３０は定期的に実行される。

ステップ５４０で、プロキシ・サーバ・ゲートウェイ２０は、負荷指標に従って、ストリーマ・ゲートウェイ１０の１つを選択する。例示的な実施例によれば、ステップ５４０で、プロキシ・サーバ・ゲートウェイ２０は、ステップ５３０で受信した各負荷指標に従って、最も軽い負荷を有するストリーマ・ゲートウェイ１０を選択する。

ステップ５５０で、プロキシ・サーバ・ゲートウェイ２０は、ステップ５４０で選択した特定のストリーマ・ゲートウェイ１０に命令して、ステップ５１０で要求されたプログラムを、特定の宛先アドレスにある要求側クライアント・デバイスＳＴＢ３５に伝送させる。ステップ５５０から、プロセス・フローはステップ５８０に進み、プロキシ・サーバ・ゲートウェイ２０は、この宛先アドレスを要求側クライアント・デバイスＳＴＢ３５に戻して、要求側クライアント・デバイスＳＴＢ３５が、選択されたストリーマ・ゲートウェイ１０から伝送されている要求されたプログラムを受信できるようにする。例示的な実施例によれば、要求側クライアント・デバイスＳＴＢ３５は、ステップ５８０の実行前に、宛先アドレスを既に知っていてもよい。このようにして、ステップ５８０を実行して、要求側クライアント・デバイスＳＴＢ３５への宛先アドレスを簡単に確認することができる。

ステップ５２０に戻り、このステップの判定結果が否定である場合（例えば新たなチューナを割り当てる必要がない場合）には、プロセス・フローはステップ５６０に進み、プロキシ・サーバ・ゲートウェイ２０は、ＲＴＰセッションまたはプログラム識別子（ＰＩＤ）を作成または更新する必要があるかどうかを判定する。ステップ５６０の判定結果が否定である場合には、これは、ステップ５１０で要求されたプログラムが、ストリーマ・ゲートウェイ１０の１つによって既に提供されていることを示す。従って、この場合には、プロセス・フローはステップ５８０に進み、プロキシ・サーバ・ゲートウェイ２０は、適用可能な宛先アドレスを要求側クライアント・デバイスＳＴＢ３５に単純に提供して、要求側クライアント・デバイスＳＴＢ３５が、ストリーマ・ゲートウェイ１０の１つによって既に伝送されている要求されたプログラムを受信できるようにする。

あるいは、ステップ５６０の判定結果が肯定である場合には、プロセス・フローはステップ５７０に進み、プロキシ・サーバ・ゲートウェイ２０は、既存の同調したチューナを有する特定のストリーマ・ゲートウェイ１０（すなわち要求されたプログラムを担持する信号ソース（例えばトランスポンダ）に既に同調しているストリーマ・ゲートウェイ１０）を選択する。ステップ５７０から、プロセス・フローは、上述したステップ５５０に進む。

図６を参照すると、本発明の例示的な実施例による、図１のストリーマ・ゲートウェイ１０の１つを動作させるステップを示す流れ図６００が示してある。図６に示す各ステップは、単なる例示であり、いかなる意味においても本発明を限定するものではない。

ステップ６１０で、ストリーマ・ゲートウェイ１０は、その負荷指標をプロキシ・サーバ・ゲートウェイ２０に送信する。例示的な実施例では、各ストリーマ・ゲートウェイ１０は、ステップ６１０を定期的に実行して、プロキシ・サーバ・ゲートウェイ２０が、ストリーマ・ゲートウェイ１０に関連する現在の負荷指標を常に把握しておくことができるようにする。上述のように、ステップ６１０で送信される負荷指標は、特定のストリーマ・ゲートウェイ１０に関連する負荷率を示す。

ステップ６２０で、ストリーマ・ゲートウェイ１０は、プログラム要求および宛先アドレスを受信する。例示的な実施例では、ストリーマ・ゲートウェイ１０は、要求されたプログラムおよび当該要求されたプログラムに関連するクライアント・デバイスＳＴＢ３５の宛先アドレスを示すデータを、プロキシ・サーバ・デバイス２０から受信する。また、例示的な実施例によれば、ステップ６２０は、プロキシ・サーバ・デバイス２０が、プログラム要求および宛先アドレスを受信したストリーマ・ゲートウェイ１０が複数のストリーマ・ゲートウェイ１０の中で最低の負荷を有すると判定したのに応答して実行される。

ステップ６３０で、ストリーマ・ゲートウェイ１０は、要求されたチャネルを宛先アドレスに伝送する。例示的な実施例によれば、ストリーマ・ゲートウェイ１０は、要求されたプログラムを要求側クライアント・デバイスＳＴＢ３５の宛先アドレスに伝送することにより、クライアント・デバイスＳＴＢ３５のユーザが、要求したプログラムを聴く、且つ／または見ることができるようにする。

次に、図７を参照すると、本発明の例示的な実施例による、図１のＳＴＢ３５の１つを動作させるステップを示す流れ図７００が示してある。図７に示す各ステップは、単なる例示であり、いかなる意味においても本発明を限定するものではない。

ステップ７１０で、ＳＴＢ３５は、プロキシ・サーバ・ゲートウェイ２０に要求信号を送信する。例示的な実施例では、要求信号は、要求された特定のプログラムを、要求側クライアント・デバイスＳＴＢ３５にダウンロードすることを求める要求を示す。

ステップ７２０で、ＳＴＢ３５は、プロキシ・サーバ・ゲートウェイ２０から応答メッセージを受信し、応答メッセージ中に示されているマルチキャスト・グループに加わる。すなわち、要求されたプログラムがネットワーク上でストリーマ・ゲートウェイ１０の１つから既に入手可能であると仮定すると、プロキシ・サーバ・ゲートウェイ２０からの応答メッセージは、ＳＴＢ３５が要求したプログラムにアクセスするために使用することができるマルチキャスト・ネットワーク・アドレスを含むことができる。

ステップ７３０で、ＳＴＢ３５は、マルチキャスト・ネットワーク・アドレスを用いてプロキシ・サーバ・ゲートウェイ２０が選択したストリーマ・ゲートウェイ１０を介して、要求したプログラムを受信する。例示的な実施例では、クライアント・デバイスＳＴＢ３５は、複数のストリーマ・ゲートウェイ１０の中からそれぞれの負荷指標に基づいてプロキシ・サーバ・ゲートウェイ２０によって選択されたストリーマ・ゲートウェイ１０を介して、要求したプログラムを受信する。次いで、ＳＴＢ３５は、受信したプログラムを復号して、出力する。

別の例示的な実施例によれば、ストリーマ・ゲートウェイ１０の１つが、ユニキャストを使用して、要求された映像データを映像ソース（例えばテレビジョン・チャネル）から送信している場合には、プロキシ・サーバ・ゲートウェイ２０は、送信側のストリーマ・ゲートウェイ１０にユニキャストをマルチキャストに変換することを要求する信号を送信することができ、さらに、映像ソースを要求しているクライアント・デバイスＳＴＢ３５にマルチキャスト・ネットワーク・アドレスを送信して、当該クライアント・デバイスＳＴＢ３５がマルチキャスト・ネットワーク・アドレスを使用して映像ソースから映像データを受信できるようにすることができる。

上述した図５〜図７の原理は、それぞれ独立して実施してもよいし、任意の適当な方法で互いに組み合わせて使用してもよい。

付録Ａ プロキシ・サーバからストリーマへのメッセージのフォーマット

Ａ．１ ＲＴＰ Ｓｅｓｓｉｏｎメッセージ
Ｓｅｓｓｉｏｎメッセージは、以下のフォーマットで構成される。各行は、＜ＣＲ＞＜ＬＦ＞で終了する。
コマンド要求／応答識別子の行
ヘッダ・パラメータ、行あたり１つ
＜ＣＲ＞＜ＬＦ＞分離記号は、ヘッダの終了を示す
ペイロード・パラメータ、行あたり１つ
＜ＣＲ＞＜ＬＦ＞分離記号は、ペイロードの終了を示す

Ａ．１．１ ＳｅｓｓｉｏｎＡｄｄ Ｒｅｑｕｅｓｔメッセージ
この要求は、全てのフィールドを含んでいなければならない。順序は重要でない。全てのフィールドが、ＡＳＣＩＩテキストである。
ＳＥＳＳＩＯＮＡＤＤ／Ｒｅｑｕｅｓｔ
ＣＳｅｑ： ｉｎｔ
Ｃｏｎｔｅｎｔ−ｌｅｎｇｔｈ： ｉｎｔ
ＭｅｄｉａＰａｔｈ： ＲｔｓｐＳｅｓｓｉｏｎＮａｍｅ／ｎｅｔｗｏｒｋ＃＃＃
Ｔｒｉｐｌｅｔ： ３２ビット１６進数：０ｘｚｚｚｚｚｚｚｚ
Ｆｒｅｑｕｅｎｃｙ： ３２ビットｕｎｓｉｇｎｅｄ ｉｎｔ
Ｐｏｌａｒｉｚａｔｉｏｎ： ｌｈｃｐ、ｒｈｃｐ、水平、垂直
Ｓｔａｎｄａｒｄ： ｄｓｓ、ｄｖｂｓ、ｄｖｂｓ２、ａｍｃ
Ｍｏｄｕｌａｔｉｏｎ： ｑｐｓｋ、８ｐｓｋ
Ｓｙｍｂｏｌ−Ｒａｔｅ： ３２ビットｕｎｓｉｇｎｅｄ ｉｎｔ
Ｃｏｄｅ−Ｒａｔｅ： ２−３、６−７など
Ａｌｐｈａ： ｉｎｔ（０、１、または２）
Ｐｉｌｏｔ： 真、偽
Ｇｏｌｄ−Ｃｏｄｅ： ｉｎｔ
Ａｍｃ−Ｍｏｄｅ： ｉｎｔ
ＰＬＳ： １２の１６進数字 ０１０２０３０４０５０６０７０８０９１０１１１２
Ｘｐｏｒｔ−Ｐａｃｋｅｔｓ： ｉｎｔ
Ｌｏｗ−Ｊｉｔｔｅｒ： 真、偽
Ｐｉｄｓ： ｉｎｔ、ｉｎｔ、ｉｎｔ、…
Ｄｅｓｔｉｎａｔｉｏｎ−Ａｄｄｒｅｓｓ：ｘｘ．ｘｘ．ｘｘ．ｘｘ
Ｄｅｓｔｉｎａｔｉｏｎ−Ｐｏｒｔ： ｉｎｔ

Ａ．１．２ ＳｅｓｓｉｏｎＡｄｄ Ｒｅｓｐｏｎｓｅメッセージ
この応答は、任意選択であるＳｔａｔｕｓＲｅａｓｏｎを除く全てのフィールドを含んでいなければならない。
ＳＥＳＳＩＯＮＡＤＤ／Ｒｅｓｐｏｎｓｅ
ＣＳｅｑ： ｉｎｔ
Ｃｏｎｔｅｎｔ−ｌｅｎｇｔｈ：ｉｎｔ
Ｔｒｉｐｌｅｔ： ３２ビット１６進数：０ｘｚｚｚｚｚｚｚｚ
Ｓｔａｔｕｓ： ｉｎｔ（０＝成功）
ＳｔａｔｕｓＲｅａｓｏｎ： ＡＳＣＩＩ文字列
Ｅｒｒｏｒｓ： １００＝メッセージ解析エラーです
１０１＝基本パラメータが足りません
１０２＝メディアが利用できません
１０３＝セッション割当てに失敗しました

Ａ．１．３ ＳｅｓｓｉｏｎＵｐｄａｔｅ Ｒｅｑｕｅｓｔメッセージ
この要求は、トリプレットおよび宛先アドレス、ならびに更新すべきその他のｄｓｆｅ／セッション・フィールドを含むものとする。順序は重要でない。
ＳＥＳＳＩＯＮＵＰＤＡＴＥ／Ｒｅｑｕｅｓｔ
ＣＳｅｑ： ｉｎｔ
Ｃｏｎｔｅｎｔ−ｌｅｎｇｔｈ： ｉｎｔ
ＭｅｄｉａＰａｔｈ： ＲｔｓｐＳｅｓｓｉｏｎＮａｍｅ／ｎｅｔｗｏｒｋ＃＃＃
Ｔｒｉｐｌｅｔ： ３２ビット１６進数：０ｘｚｚｚｚｚｚｚｚ
Ｆｒｅｑｕｅｎｃｙ： ３２ビットｕｎｓｉｇｎｅｄ ｉｎｔ
Ｐｏｌａｒｉｚａｔｉｏｎ： ｌｈｃｐ、ｒｈｃｐ、水平、垂直
Ｓｔａｎｄａｒｄ： ｄｓｓ、ｄｖｂｓ、ｄｖｂｓ２、ａｍｃ
Ｍｏｄｕｌａｔｉｏｎ： ｑｐｓｋ、８ｐｓｋ
Ｓｙｍｂｏｌ−Ｒａｔｅ： ３２ビットｕｎｓｉｇｎｅｄ ｉｎｔ
Ｃｏｄｅ−Ｒａｔｅ： ２−３、６−７など
Ａｌｐｈａ： ｉｎｔ（０、１、または２）
Ｐｉｌｏｔ： 真、偽
Ｇｏｌｄ−Ｃｏｄｅ： ｉｎｔ
Ａｍｃ−Ｍｏｄｅ： ｉｎｔ
ＰＬＳ： １２の１６進数字 ０１０２０３０４０５０６０７０８０９１０１１１２
Ｘｐｏｒｔ−Ｐａｃｋｅｔｓ： ｉｎｔ
Ｌｏｗ−Ｊｉｔｔｅｒ： 真、偽
Ｐｉｄｓ： ｉｎｔ、ｉｎｔ、ｉｎｔ、…
Ｄｅｓｔｉｎａｔｉｏｎ−Ａｄｄｒｅｓｓ：ｘｘ．ｘｘ．ｘｘ．ｘｘ
Ｄｅｓｔｉｎａｔｉｏｎ−Ｐｏｒｔ： ｉｎｔ

Ａ．１．４ ＳｅｓｓｉｏｎＵｐｄａｔｅ Ｒｅｓｐｏｎｓｅメッセージ
この応答は、任意選択であるＳｔａｔｕｓＲｅａｓｏｎを除く全てのフィールドを含んでいなければならない。
ＳＥＳＳＩＯＮＵＰＤＡＴＥ／Ｒｅｓｐｏｎｓｅ
ＣＳｅｑ： ｉｎｔ
Ｃｏｎｔｅｎｔ−ｌｅｎｇｔｈ：ｉｎｔ
Ｔｒｉｐｌｅｔ： ３２ビット１６進数：０ｘｚｚｚｚｚｚｚｚ
Ｓｔａｔｕｓ： ｉｎｔ（０＝成功）
ＳｔａｔｕｓＲｅａｓｏｎ： ＡＳＣＩＩ文字列
Ｅｒｒｏｒｓ： １００＝メッセージ解析エラーです
１０１＝基本パラメータが足りません
１０２＝メディアが利用できません
１０３＝セッション割当てに失敗しました
１０４＝セッションが見つかりません

Ａ．１．５ ＳｅｓｓｉｏｎＤｅｌｅｔｅ Ｒｅｑｕｅｓｔメッセージ
この要求は、トリプレットおよび宛先アドレスを識別する。
宛先アドレスが２５５．２５５．２５５．２５５である場合には、ストリーマ・ゲートウェイ１０は、要求されたトリプレットに関連する全てのＲＴＰセッションを削除し、チューナ資源を解放しなければならない。
トリプレット値が０ｘＦＦＦＦＦＦＦＦであり、宛先アドレスが２５５．２５５．２５５．２５５である場合には、ストリーマ・ゲートウェイ１０は、全てのＲＴＰセッションを削除し、このストリーマ・ゲートウェイ１０上の全てのトリプレット（チューナ資源）を解放しなければならない。
ＳＥＳＳＩＯＮＤＥＬＥＴＥ／Ｒｅｑｕｅｓｔ
ＣＳｅｑ： ｉｎｔ
Ｃｏｎｔｅｎｔ−ｌｅｎｇｔｈ： ｉｎｔ
Ｔｒｉｐｌｅｔ： ３２ビット１６進数：０ｘｚｚｚｚｚｚｚｚ
Ｄｅｓｔｉｎａｔｉｏｎ−Ａｄｄｒｅｓｓ：ｘｘ．ｘｘ．ｘｘ．ｘｘ

Ａ．１．６ ＳｅｓｓｉｏｎＤｅｌｅｔｅ Ｒｅｓｐｏｎｓｅメッセージ
この応答は、任意選択であるＳｔａｔｕｓＲｅａｓｏｎを除く全てのフィールドを含んでいなければならない。
ＳＥＳＳＩＯＮＤＥＬＥＴＥ／Ｒｅｓｐｏｎｓｅ
ＣＳｅｑ： ｉｎｔ
Ｃｏｎｔｅｎｔ−ｌｅｎｇｔｈ：ｉｎｔ
Ｔｒｉｐｌｅｔ： ３２ビット１６進数：０ｘｚｚｚｚｚｚｚｚ
Ｓｔａｔｕｓ： ｉｎｔ（０＝成功）
ＳｔａｔｕｓＲｅａｓｏｎ： ＡＳＣＩＩ文字列
Ｅｒｒｏｒｓ： １００＝メッセージ解析エラーです
１０１＝基本パラメータが足りません
１０２＝メディアが利用できません
１０４＝セッションが見つかりません

Ａ．２ Ｓｔａｔｕｓメッセージ
Ｓｔａｔｕｓメッセージは、以下のフォーマットで構成される。各行は、＜ＣＲ＞＜ＬＦ＞で終了する。
コマンド要求／応答識別子の行
ヘッダ・パラメータ、行あたり１つ
＜ＣＲ＞＜ＬＦ＞分離記号は、ヘッダの終了を示す
ペイロード・パラメータ、行あたり１つ
＜ＣＲ＞＜ＬＦ＞分離記号は、ペイロードの終了を示す

Ａ．２．１ Ｓｔｒｅａｍｅｒ Ｓｔａｔｕｓ Ｒｅｑｕｅｓｔメッセージ
この要求は、関連のあるフィールドを識別する。
ＳＴＲＥＡＭＥＲＳＴＡＴＵＳ／Ｒｅｑｕｅｓｔ
ＣＳｅｑ： ｉｎｔ
Ｃｏｎｔｅｎｔ−ｌｅｎｇｔｈ：ｉｎｔ
ＬｏａｄＳｔａｔ：
ＮｕｍＴｒｉｐｌｅｔｓ：
Ｎｗ：
Ｐｏ：
Ｆｒ：
Ｓｔ：

Ａ．２．２ Ｓｔｒｅａｍｅｒ Ｓｔａｔｕｓ Ｒｅｓｐｏｎｓｅメッセージ
ストリーマ・ゲートウェイ１０は、要求された負荷統計値と、それに続くトリプレット状態エントリの配列とを含む応答メッセージを生成することになる。戻されるエントリの数は、ＮｕｍＴｒｉｐｌｅｔｓで指定される。

トリプレット状態（Ｓｔ）フィールドは、以下のように３文字以下である。
・１番目の文字は、静的同調を示すＳ、または動的同調を示すＤである。
・２番目／３番目の文字は、成功を示す１から３２、または失敗を示す０（ゼロ）である。

ストリーマ・ゲートウェイ１０は、失敗した静的チューナ（Ｓｔ：Ｓ０）は報告しない。また、ストリーマ・ゲートウェイ１０は、静的チューナへの同調を試行し続ける。複数のチューナを、同じトリプレット設定に静的に割り当てることができる。この場合には、状態フィールドは、いくつのチューナが当該トリプレット設定を使用しているかを示す。動的同調時には、状態フィールドは、１（良好）または０（失敗）チューナを示さなければならない。

以下は、ストリーマが３つのアクティブなトリプレットを有し、そのうちの１つが静的に同調されていると仮定した場合の、状態要求応答の一例である。
ＳＴＲＥＡＭＥＲＳＴＡＴＵＳ／Ｒｅｓｐｏｎｓｅ
ＣＳｅｑ： ｉｎｔ
Ｃｏｎｔｅｎｔ−ｌｅｎｇｔｈ：ｉｎｔ
ＬｏａｄＳｔａｔ： ２８３
ＮｕｍＴｒｉｐｌｅｔｓ： ３
Ｎｗ： ０
Ｐｏ： ２
Ｆｒ： ９８８
Ｓｔ： Ｄ１
Ｎｗ： ０
Ｐｏ： ３
Ｆｒ： ９７４
Ｓｔ： Ｄ１
Ｎｗ： ０
Ｐｏ： ２
Ｆｒ： １２６７
Ｓｔ： Ｓ５
メッセージ応答は、ストリーマが３２個の一意的なトリプレットについての状態を報告するときに、最大となる。

Ａ．２．３ Ｓｅｓｓｉｏｎ Ｓｔａｔｕｓ Ｒｅｑｕｅｓｔメッセージ
このメッセージは、メディア・パス値、トリプレット値、および少なくとも１つの追加要求フィールドを含んでいなければならない。
ＳＥＳＳＩＯＮＳＴＡＴＵＳ／Ｒｅｑｕｅｓｔ
ＣＳｅｑ： ｉｎｔ
Ｃｏｎｔｅｎｔ−ｌｅｎｇｔｈ：ｉｎｔ
ＭｅｄｉａＰａｔｈ： ＲｔｓｐＳｅｓｓｉｏｎＮａｍｅ／ｎｅｔｗｏｒｋ＃＃＃
Ｔｒｉｐｌｅｔ： ３２ビット１６進数：０ｘｚｚｚｚｚｚｚｚ
ＮｕｍＳｅｓｓｉｏｎｓ：
Ｆｒｅｑｕｅｎｃｙ：
Ｐｏｌａｒｉｚａｔｉｏｎ：
Ｓｔａｎｄａｒｄ：
Ｍｏｄｕｌａｔｉｏｎ：
Ｓｙｍｂｏｌ−Ｒａｔｅ：
Ｃｏｄｅ−Ｒａｔｅ：
Ａｌｐｈａ：
Ｐｉｌｏｔ：
Ｇｏｌｄ−Ｃｏｄｅ：
Ａｍｃ−Ｍｏｄｅ：
ＰＬＳ：
Ｘｐｏｒｔ−Ｐａｃｋｅｔｓ：
Ｌｏｗ−Ｊｉｔｔｅｒ：
Ｐｉｄｓ：
Ｄｅｓｔｉｎａｔｉｏｎ−Ａｄｄｒｅｓｓ：
Ｄｅｓｔｉｎａｔｉｏｎ−Ｐｏｒｔ：

Ａ．２．４ Ｓｅｓｓｉｏｎ Ｓｔａｔｕｓ Ｒｅｓｐｏｎｓｅメッセージ
セッション状態要求メッセージで要求されるフィールドは、応答メッセージに含まれていなければならない。要求されたトリプレットについての全てのセッションは、１つの応答メッセージで送信される。戻されるセッションの数は、ＮｕｍＳｅｓｓｉｏｎｓで指定される。セッションは、（ＰＩＤ、宛先アドレス、宛先ポート）の３つの要素でグループ化される。また、トリプレットがＡ３モードのチューナに関連する場合のみ、Ａ３パラメータ要求フィールド（ａｌｐｈａ、ｐｉｌｏｔ、ｇｏｌｄ−ｃｏｄｅ、ａｍｃ−ｍｏｄｅ、およびｐｌｓ）が戻されることにも留意されたい。
ＳＥＳＳＩＯＮＳＴＡＴＵＳ／Ｒｅｓｐｏｎｓｅ
ＣＳｅｑ： ｉｎｔ
Ｃｏｎｔｅｎｔ−ｌｅｎｇｔｈ： ｉｎｔ
ＭｅｄｉａＰａｔｈ： ＲｔｓｐＳｅｓｓｉｏｎＮａｍｅ／ｎｅｔｗｏｒｋ＃＃＃
Ｔｒｉｐｌｅｔ： ３２ビット１６進数：０ｘｚｚｚｚｚｚｚｚ
Ｆｒｅｑｕｅｎｃｙ： ３２ビットｕｎｓｉｇｎｅｄ ｉｎｔ
Ｐｏｌａｒｉｚａｔｉｏｎ： ｌｈｃｐ、ｒｈｃｐ、水平、垂直
Ｓｔａｎｄａｒｄ： ｄｓｓ、ｄｖｂｓ、ｄｖｂｓ２、ａｍｃ
Ｍｏｄｕｌａｔｉｏｎ： ｑｐｓｋ、８ｐｓｋ
Ｓｙｍｂｏｌ−Ｒａｔｅ： ３２ビットｕｎｓｉｇｎｅｄ ｉｎｔ
Ｃｏｄｅ−Ｒａｔｅ： ２−３、６−７など
Ａｌｐｈａ： ｉｎｔ（０、１、または２）
Ｐｉｌｏｔ： 真、偽
Ｇｏｌｄ−Ｃｏｄｅ： ｉｎｔ
Ａｍｃ−Ｍｏｄｅ： ｉｎｔ
ＰＬＳ： １２の１６進数字 ０１０２０３０４０５０６０７０８０９１０１１１２
Ｘｐｏｒｔ−Ｐａｃｋｅｔｓ： ｉｎｔ
Ｌｏｗ−Ｊｉｔｔｅｒ： 真、偽
ＮｕｍＳｅｓｓｉｏｎｓ： ３
Ｐｉｄｓ： ｉｎｔ、ｉｎｔ、ｉｎｔ
Ｄｅｓｔｉｎａｔｉｏｎ−Ａｄｄｒｅｓｓ：ｘｘ．ｘｘ．ｘｘ．ｘｘ
Ｄｅｓｔｉｎａｔｉｏｎ−Ｐｏｒｔ： ｉｎｔ

以下は、レガシー・チューナであり、ストリーマが３つのアクティブなセッションを有すると仮定した場合の、セッション要求応答の一例である。
ＳＥＳＳＩＯＮＳＴＡＴＵＳ／Ｒｅｓｐｏｎｓｅ
ＣＳｅｑ： ｘｘｘ
Ｃｏｎｔｅｎｔ−ｌｅｎｇｔｈ： ｙｙｙ
ＭｅｄｉａＰａｔｈ： ＳＥＲＶＩＣＥＰＲＯＶＩＤＥＲＮＡＭＥ／ｎｅｔｗｏｒｋ０
Ｔｒｉｐｌｅｔ： ０ｘ０００２０５４９
ＮｕｍＳｅｓｓｉｏｎｓ： ３
Ｆｒｅｑｕｅｎｃｙ： １３５３０８００００
Ｐｏｌａｒｉｚａｔｉｏｎ： ｒｈｃｐ
Ｓｔａｎｄａｒｄ： ｄｓｓ
Ｍｏｄｕｌａｔｉｏｎ： ｑｐｓｋ
Ｓｙｍｂｏｌ−Ｒａｔｅ： ２０００００００
Ｃｏｄｅ−Ｒａｔｅ： ６−７
Ｘｐｏｒｔ−Ｐａｃｋｅｔｓ： １０
Ｌｏｗ−Ｊｉｔｔｅｒ： 偽
Ｐｉｄｓ： １０、１１
Ｄｅｓｔｉｎａｔｉｏｎ−Ａｄｄｒｅｓｓ：２３９．２５５．０．１７
Ｄｅｓｔｉｎａｔｉｏｎ−Ｐｏｒｔ： １０２４
Ｐｉｄｓ： ３０、３１
Ｄｅｓｔｉｎａｔｉｏｎ−Ａｄｄｒｅｓｓ：２３９．２５５．２．１３８
Ｄｅｓｔｉｎａｔｉｏｎ−Ｐｏｒｔ： １０２４
Ｐｉｄｓ： ９０、９１、９２
Ｄｅｓｔｉｎａｔｉｏｎ−Ａｄｄｒｅｓｓ：２３９．２５５．０．４８
Ｄｅｓｔｉｎａｔｉｏｎ−Ｐｏｒｔ： １０２４

付録Ｂ 興味深い用途の場合

Ａ．１ 降雨減衰
Ａ．１．１ 一部のチューナが影響を受ける場合
ストリーマ・ゲートウェイ１０がチューナのロック解除を検出し、空いているチューナが利用可能である場合には、ストリーマ・ゲートウェイ１０は、そのシャーシ内の空いているチューナにＲＴＰセッションを移動させることになる。プロキシ・サーバ・ゲートウェイ２０は、この移動を知る必要はない。シャーシ内に利用可能な空いているチューナがない、または空いているチューナ全てを試して失敗した場合には、ストリーマは、次のＳＴＲＥＡＭＥＲＳＴＡＴＵＳ応答メッセージでトリプレット失敗を示す。ストリーマ・ゲートウェイ１０は、失敗であることを示したら、セッションの移動の試行を停止しなければならない。ストリーマ・ゲートウェイ１０がトリプレット同調失敗を示したら、プロキシ・サーバ・ゲートウェイ２０は、そのトリプレットを別のストリーマにリダイレクトすることになる。

Ａ．１．２ 全てのチューナが影響を受ける場合
全てのチューナが降雨減衰でロック解除する可能性もある。これは、全てのストリーマ・ゲートウェイ１０の間で起こる可能性がある。ＳＴＲＥＡＭＥＲＳＴＡＴＵＳ応答に基づいて、プロキシ・サーバ・ゲートウェイ２０は、ストリーマ・ゲートウェイ１０のトリプレット（スロット）をエラーとマークし、スロットの時間を現在の時間に更新する。ストリーマの間で空いているスロットがない場合には、プロキシは、新たなセットアップ要求を、最も古いエラー・スロットを有するストリーマ・ゲートウェイ１０に転送することになる。プロキシ・サーバ・ゲートウェイ２０が全てのエラー・スロットを試し、それでもなおＳＴＲＥＡＭＥＲＳＴＡＴＵＳが失敗を示し続ける場合には、プロキシ・サーバ・ゲートウェイ２０は、５０３：Ｓｅｒｖｉｃｅ Ｕｎａｖａｉｌａｂｌｅメッセージを、クライアント・デバイス（例えばＳＴＢ３５）に送信することができる。現在のＳＴＢソフトウェアは、５０３：ＳｅｒｖｉｃｅＵｎａｖａｉｌａｂｌｅ応答の受信時にその挙動が変化しない。そうなるまでは、ここで提案する動作は、新たな価値を付加しない。

Ａ．２ 静的同調失敗
静的同調チューナがロックできない、またはロックを失った場合には、ストリーマは、ＳＴＲＥＡＭＥＲＳＴＡＴＵＳ応答メッセージ中でＳｔ：Ｓ０失敗を示さない。ストリーマは、引き続きＳｔ：Ｓ１を示し続ける。ストリーマは、引き続き、当該静的同調チューナの回復を試行し続けなければならない。

Ａ．３ プロキシ・サーバ・リブート
プロキシ・サーバ・ゲートウェイ２０のリブート中には、全てのクライアントＳＴＢクッキーが失われる。リブートに続いて、プロキシ・サーバ・ゲートウェイ２０は、４５４：Ｓｅｓｓｉｏｎ Ｎｏｔ Ｆｏｕｎｄを送って、以前の（且つ現在は未知の）ＲＴＳＰセッション番号を含むＳｅｔｕｐ要求を発行したＳＴＢに応答する。しかし、実際の動作では、これは問題にならないものと考えられる。プロキシ・サーバ・ゲートウェイ２０がダウンしている間に、ＳＴＢ ＴＣＰ接続がリセットされ、ＳＴＢが、ＲＴＳＰセッション番号を含まない新たなセットアップ要求を発行するからである。

付録Ｃ 設計注

ストリーマ・ゲートウェイ１０
１．静的チューナが解放された場合
ａ．当該チューナのＲＴＰセッションが存在しない場合には、当該チューナはサイレントにプールに戻される。ストリーマ・ゲートウェイ１０は、Ｓｔ：Ｓ１の報告を停止する。解放された静的チューナを検出し、静的スロットを削除する以外には、プロキシ・サーバ・ゲートウェイ２０が動作を起こす必要はない。
ｂ．ＲＴＰセッションが存在する場合には、ストリーマ・ゲートウェイ１０は、動的チューナが利用可能であれば、トリプレットおよびセッションを動的チューナにサイレントに移動させる。プロキシ・サーバ・ゲートウェイ２０は、以前の静的スロットを動的スロットとしてマークしなければならない。
ｃ．ＲＴＰセッションが存在するが、移動に失敗した場合には、ストリーマ・ゲートウェイ１０は、トリプレット失敗（Ｄ０）エントリを含むＳｔｒｅａｍｅｒＳｔａｔｕｓ／Ｒｅｓｐｏｎｓｅメッセージを、プロキシ・サーバ・ゲートウェイ２０に送信しなければならない。

２．ＲＴＰセッションを有する動的同調チューナが異なるトランスポンダに静的に同調された場合
ａ．トリプレット状態は、新たに静的に同調されたチューナを示すようになる。プロキシ・サーバ・ゲートウェイ２０は、以前の動的スロットを静的スロットとしてマークしなければならない。
ｂ．利用可能であれば、ストリーマ・ゲートウェイ１０は、動的ＲＴＰセッションを空いているチューナにサイレントに移動させる。トリプレット状態は、引き続き、動的同調チューナを示し続ける。
ｃ．空いているチューナが利用可能でない場合には、ストリーマ・ゲートウェイ１０は、移動させることができない動的トリプレットについて「Ｄ０」状態を戻す。プロキシ・サーバ・ゲートウェイ２０は、このトリプレットに関する全てのＲＴＳＰセッションをティアダウンする。

３．プロキシ・サーバ・ゲートウェイ２０が新たなトリプレットについてのＳｅｓｓｉｏｎＡｄｄ要求を送信し、全てのチューナが割り当てられている場合には、ストリーマ・ゲートウェイ１０は、当該トリプレットおよび非ゼロの失敗コード（状態コード＝０は成功を示す）を含むＳｅｓｓｉｏｎＡｄｄ／Ｒｅｓｐｏｎｓｅメッセージを戻す。

４．プロキシ・サーバ・ゲートウェイ２０が、未知のトリプレットについてＳｅｓｓｉｏｎＵｐｄａｔｅまたはＳｅｓｓｉｏｎＤｅｌｅｔｅ要求を送信した場合には、ストリーマ・ゲートウェイ１０は、当該トリプレットおよび非ゼロの失敗コードを含むＳｅｓｓｉｏｎＵｐｄａｔｅ／Ｄｅｌｅｔｅ Ｒｅｓｐｏｎｓｅメッセージを戻す。

プロキシ・サーバ・ゲートウェイ２０
１．ストリーマ・ゲートウェイ１０が、プロキシ・サーバ・ゲートウェイ２０には未知のトリプレットの失敗を状態応答の中で報告した場合には、プロキシ・サーバ・ゲートウェイ２０は、当該トリプレットに関連する全てのセッションをティアダウンする。（プロキシは、当該トリプレットおよびＤｅｓｔｉｎａｔｉｏｎＡｄｄｒｅｓｓ＝２５５．２５５．２５５．２５５を有するＳｅｓｓｉｏｎＤｅｌｅｔｅメッセージを送信する。）

２．ストリーマ・ゲートウェイ１０が、失敗を示すＳｅｓｓｉｏｎＡｄｄ Ｒｅｓｐｏｎｓｅを報告した場合には、プロキシ・サーバ・ゲートウェイ２０は、当該トリプレットおよびセッションを内部でティアダウンする。

３．ストリーマ・ゲートウェイ１０が、失敗を示すＳｅｓｓｉｏｎＡｄｄ／Ｕｐｄａｔｅ／Ｄｅｌｅｔｅ Ｒｅｓｐｏｎｓｅを報告した場合には、プロキシ・サーバ・ゲートウェイ２０は、当該トリプレットをティアダウンする。

上述のように、本発明は、ネットワーク中のクライアント・デバイスに対する負荷分散信号分配を実現する方法および装置を提供する。好ましい設計を有するものとして本発明について説明したが、本発明は、本開示の趣旨および範囲内で、さらに修正することができる。従って、本願は、本発明の一般的原理を用いた本発明のいかなる変形、用途、または改変もカバーするものとする。さらに、本願は、本発明に関係し、添付の特許請求の範囲に含まれる当技術分野で既知の実施方法または慣習的な実施方法に含まれるような本開示からの逸脱も、カバーするものとする。
以下に、本発明の好ましい態様を示す。
付記１．複数の映像ソースの１つの映像をダウンロードすることを求める要求をクライアント・デバイスから受信するステップ（５１０）と、
前記複数の映像ソースを受信することができる第１の映像受信側デバイスおよび第２の映像受信側デバイスからそれぞれの負荷指標を受信するステップ（５３０）と、
前記負荷指標に従って、前記第１の映像受信側デバイスおよび前記第２の映像受信側デバイスの一方を選択するステップ（５４０）と、
前記選択した映像受信側デバイスに、前記複数の映像ソースの１つの前記映像を、前記クライアント・デバイスが知っているアドレスを使用して伝送するように命令するステップ（５５０）とを含む、方法（５００）。
付記２．前記選択した映像受信側デバイスに前記アドレスを提供するステップをさらに含む、付記１に記載の方法（５００）。
付記３．前記第１の映像受信側デバイスおよび前記第２の映像受信側デバイスの一方がマルチキャストを使用して前記複数の映像ソースの１つの映像を送信している場合に、前記クライアント・デバイスにマルチキャスト・ネットワーク・アドレスを送信して、前記クライアント・デバイスが前記マルチキャスト・ネットワーク・アドレスを使用して前記複数の映像ソースの前記１つの前記映像を受信することができるようにするステップをさらに含む、付記１に記載の方法（５００）。
付記４．前記第１の映像受信側デバイスおよび前記第２の映像受信側デバイスの一方がユニキャストを使用して前記複数の映像ソースの１つの映像を送信している場合に、前記送信している映像受信側デバイスに、ユニキャストをマルチキャストに変換するように要求し、前記クライアント・デバイスにマルチキャスト・ネットワーク・アドレスを送信して、前記クライアント・デバイスが前記マルチキャスト・ネットワーク・アドレスを使用して前記複数の映像ソースの１つの前記映像を受信することができるようにするステップをさらに含む、付記１に記載の方法（５００）。
付記５．それぞれの負荷指標を受信する前記ステップが、定期的に実行される、付記１に記載の方法（５００）。
付記６．前記それぞれの負荷指標が、前記第１の映像受信側デバイスおよび前記第２の映像受信側デバイスそれぞれの負荷率設定点を示す、付記１に記載の方法（５００）。
付記７．前記映像ソースがそれぞれ、テレビジョン・プログラムを提供する、付記１に記載の方法（５００）。
付記８．前記それぞれの負荷指標によれば、前記選択された映像受信側デバイスの方が負荷が軽い、付記１に記載の方法（５００）。
付記９．複数の映像ソースの１つの映像をダウンロードすることを求める要求をクライアント・デバイス（３５）から受信する手段（２１）と、
前記複数の映像ソースを受信することができる第１の映像受信側デバイス（１０）および第２の映像受信側デバイス（１０）からそれぞれの負荷指標を受信する手段（２２）と、
前記負荷指標に従って、前記第１の映像受信側デバイス（１０）および前記第２の映像受信側デバイス（１０）の一方を選択する手段と、
前記選択した映像受信側デバイス（１０）に、前記複数の映像ソースの１つの前記映像を、前記クライアント・デバイス（３５）が知っているアドレスを使用して伝送するように命令する手段とを備える、装置（２０）。
付記１０．前記選択した映像受信側デバイス（１０）に前記アドレスを提供する手段をさらに備える、付記９に記載の装置（２０）。
付記１１．前記第１の映像受信側デバイス（１０）および前記第２の映像受信側デバイス（１０）の一方がマルチキャストを使用して前記複数の映像ソースの１つの映像を送信している場合に、前記クライアント・デバイス（３５）にマルチキャスト・ネットワーク・アドレスが送信され、前記クライアント・デバイス（３５）が前記マルチキャスト・ネットワーク・アドレスを使用して前記複数の映像ソースの前記１つの前記映像を受信することができるようにする、付記９に記載の装置（２０）。
付記１２．前記第１の映像受信側デバイス（１０）および前記第２の映像受信側デバイス（１０）の一方がユニキャストを使用して前記複数の映像ソースの１つの映像を送信している場合に、前記送信している映像受信側デバイス（１０）が、前記ユニキャストをマルチキャストに変換し、前記クライアント・デバイス（３５）にマルチキャスト・ネットワーク・アドレスを送信して、前記クライアント・デバイス（３５）が前記マルチキャスト・ネットワーク・アドレスを使用して前記複数の映像ソースの１つの前記映像を受信することができるようにする、付記９に記載の装置（２０）。
付記１３．それぞれの負荷指標が、前記第１の映像受信側デバイス（１０）および前記第２の映像受信側デバイス（１０）から定期的に受信される、付記９に記載の装置（２０）。
付記１４．前記それぞれの負荷指標が、前記第１の映像受信側デバイス（１０）および前記第２の映像受信側デバイス（１０）それぞれの負荷率設定点を示す、付記９に記載の装置（２０）。
付記１５．前記映像ソースがそれぞれ、テレビジョン・プログラムを提供する、付記９に記載の装置（２０）。
付記１６．前記それぞれの負荷指標によれば、前記選択された映像受信側デバイス（１０）の方が負荷が軽い、付記９に記載の装置（２０）。
付記１７．複数の映像ソースの１つの映像をダウンロードすることを求める要求をクライアント・デバイス（３５）から受信するように動作可能な第１の入力（２１）と、
前記複数の映像ソースを受信することができる第１の映像受信側デバイス（１０）および第２の映像受信側デバイス（１０）からそれぞれの負荷指標を受信するように動作可能な第２の入力（２２）と、
前記負荷指標に従って、前記第１の映像受信側デバイス（１０）および前記第２の映像受信側デバイス（１０）の一方を選択するように動作可能な第１の制御論理と、
前記選択した映像受信側デバイス（１０）に、前記複数の映像ソースの１つの前記映像を、前記クライアント・デバイス（３５）が知っているアドレスを使用して伝送するように命令するように動作可能な第２の制御論理とを備える、装置（２０）。
付記１８．前記第１の映像受信側デバイス（１０）および前記第２の映像受信側デバイス（１０）の一方がマルチキャストを使用して前記複数の映像ソースの１つの映像を送信している場合に、前記クライアント・デバイス（３５）にマルチキャスト・ネットワーク・アドレスが送信され、前記クライアント・デバイス（３５）が前記マルチキャスト・ネットワーク・アドレスを使用して前記複数の映像ソースの前記１つの前記映像を受信することができるようにする、付記１７に記載の装置（２０）。
付記１９．前記第１の映像受信側デバイス（１０）および前記第２の映像受信側デバイス（１０）の一方がユニキャストを使用して前記複数の映像ソースの１つの映像を送信している場合に、前記送信している映像受信側デバイス（１０）が、ユニキャストをマルチキャストに変換し、前記クライアント・デバイス（３５）にマルチキャスト・ネットワーク・アドレスを送信して、前記クライアント・デバイス（３５）が前記マルチキャスト・ネットワーク・アドレスを使用して前記複数の映像ソースの１つの前記映像を受信することができるようにする、付記１７に記載の装置（２０）。
付記２０．前記それぞれの負荷指標が、前記第１の映像受信側デバイス（１０）および前記第２の映像受信側デバイス（１０）から定期的に受信される、付記１７に記載の装置（２０）。
付記２１．前記それぞれの負荷指標が、前記第１の映像受信側デバイス（１０）および前記第２の映像受信側デバイス（１０）それぞれの負荷率設定点を示す、付記１７に記載の装置（２０）。
付記２２．前記映像ソースがそれぞれ、テレビジョン・プログラムを提供する、付記１７に記載の装置（２０）。
付記２３．前記それぞれの負荷指標によれば、前記選択された映像受信側デバイス（１０）の方が負荷が軽い、付記１７に記載の装置（２０）。
付記２４．複数の映像ソースを受信することができる映像受信側デバイスから要求サーバ・デバイスに、前記映像受信側デバイスに関連する負荷を示す負荷指標を送信するステップ（６１０）と、
要求されたプログラムおよび前記要求されたプログラムに関連するクライアント・デバイスの宛先アドレスを示すデータを、前記要求サーバ・デバイスから受信するステップ（６２０）と、
前記要求されたプログラムを前記宛先アドレスに伝送するステップ（６３０）とを含む、方法（６００）。
付記２５．前記映像ソースがそれぞれ、テレビジョン・チャネルである、付記２４に記載の方法（６００）。
付記２６．前記負荷指標が、前記映像受信側デバイスに関連する負荷率を示す、付記２４に記載の方法（６００）。
付記２７．前記受信ステップが、前記映像受信側デバイスが複数の異なる映像受信側デバイスの中で最も低い負荷を有すると前記要求サーバ・デバイスが判定したのに応答して実行される、付記２４に記載の方法（６００）。
付記２８．前記送信ステップが、定期的に実行される、付記２４に記載の方法（６００）。
付記２９．装置（１０）に関連する負荷を示す負荷指標を決定する手段と、
前記負荷指標を要求サーバ・デバイス（２０）に送信する手段（１１）とを備え、
前記負荷指標に応じて、要求されたプログラムおよび前記要求されたプログラムに関連するクライアント・デバイス（３５）の宛先アドレスを示すデータが前記要求サーバ・デバイス（２０）から受信され、前記装置（１０）が前記要求されたプログラムを前記宛先アドレスに伝送する、装置（１０）。
付記３０．前記装置（１０）が、複数のテレビジョン・チャネルを受信することができる、付記２９に記載の装置（１０）。
付記３１．前記負荷指標が、前記装置（１０）に関連する負荷率を示す、付記２９に記載の装置（１０）。
付記３２．前記装置（１０）が複数の異なる装置（１０）の中で最も低い負荷を有すると前記要求サーバ・デバイス（２０）が判定したのに応答して、前記要求されたプログラムおよび前記要求されたプログラムに関連する前記クライアント・デバイス（３５）の宛先アドレスが前記要求サーバ・デバイス（２０）から受信される、付記２９に記載の装置（１０）。
付記３３．前記複数の異なる装置（１０）が、映像受信側デバイスである、付記３２に記載の装置（１０）。
付記３４．前記負荷指標が、定期的に前記要求サーバ・デバイス（２０）に送信される、付記２９に記載の装置（１０）。
付記３５．装置（１０）に関連する負荷を示す負荷指標を決定するように動作可能な制御論理と、
前記負荷指標を要求サーバ・デバイス（２０）に送信するように動作可能なインタフェース（１１）とを備え、
前記負荷指標に応じて、要求されたプログラムおよび前記要求されたプログラムに関連するクライアント・デバイス（３５）の宛先アドレスを示すデータが前記要求サーバ・デバイス（２０）から受信され、前記装置（１０）が前記要求されたプログラムを前記宛先アドレスに伝送する、装置（１０）。
付記３６．前記装置（１０）が、複数のテレビジョン・チャネルを受信することができる、付記３５に記載の装置（１０）。
付記３７．前記負荷指標が、前記装置（１０）に関連する負荷率を示す、付記３５に記載の装置（１０）。
付記３８．前記装置（１０）が複数の異なる装置（１０）の中で最も低い負荷を有すると前記要求サーバ・デバイス（２０）が判定したのに応答して、前記要求されたプログラムおよび前記要求されたプログラムに関連する前記クライアント・デバイス（３５）の宛先アドレスが前記要求サーバ・デバイス（２０）から受信される、付記３５に記載の装置（１０）。
付記３９．前記複数の異なる装置（１０）が、映像受信側デバイスである、付記３８に記載の装置（１０）。
付記４０．前記負荷指標が、定期的に前記要求サーバ・デバイス（２０）に送信される、付記３５に記載の装置（１０）。
付記４１．プログラムを求める要求をクライアント・デバイスから要求サーバ・デバイスに送信するステップ（７１０）と、
前記要求に応答して、前記クライアント・デバイスが前記要求サーバ・デバイスからアドレスを受信するステップ（７２０）と、
前記アドレスを使用して、選択された映像受信側デバイスを介して、前記クライアント・デバイスが前記要求したプログラムを受信するステップ（７３０）とを含み、
前記要求サーバ・デバイスが、前記選択された映像受信側デバイスを、複数の映像受信側デバイスの中から、前記複数の映像受信側デバイスからのそれぞれの負荷指標に基づいて選択する、方法（７００）。
付記４２．前記それぞれの負荷指標が、前記複数の映像受信側デバイスそれぞれの負荷率設定点を示す、付記４１に記載の方法（７００）。
付記４３．前記複数の映像受信側デバイスが、複数のテレビジョン・チャネルに同調することができる、付記４１に記載の方法（７００）。
付記４４．前記それぞれの負荷指標によれば、前記選択された映像受信側デバイスはより軽い負荷を有する、付記４１に記載の方法（７００）。
付記４５．プログラムを求める要求を要求サーバ・デバイス（２０）に送信する手段と、
前記要求に応答して、前記要求サーバ・デバイス（２０）からアドレスを受信する手段と、
前記アドレスを使用して、選択された映像受信側デバイス（１０）を介して、前記要求したプログラムを受信する手段とを備え、
前記要求サーバ・デバイス（２０）が、前記選択された映像受信側デバイス（１０）を、複数の映像受信側デバイス（１０）の中から、前記複数の映像受信側デバイスからのそれぞれの負荷指標に基づいて選択する、装置（３５）。
付記４６．前記それぞれの負荷指標が、前記複数の映像受信側デバイス（１０）それぞれの負荷率設定点を示す、付記４５に記載の装置（３５）。
付記４７．前記複数の映像受信側デバイス（１０）が、複数のテレビジョン・チャネルにそれぞれ同調することができる、付記４５に記載の装置（３５）。
付記４８．前記それぞれの負荷指標によれば、前記選択された映像受信側デバイス（１０）はより軽い負荷を有する、付記４５に記載の装置（３５）。
付記４９．プログラムを求める要求を要求サーバ・デバイス（２０）に送信するように動作可能な出力と、
前記要求に応答して、前記要求サーバ・デバイス（２０）からアドレスを受信し、前記アドレスを使用して、選択された映像受信側デバイス（１０）を介して、前記要求したプログラムを受信するように動作可能な入力とを備え、
前記要求サーバ・デバイス（２０）が、前記選択された映像受信側デバイス（１０）を、複数の映像受信側デバイス（１０）の中から、前記複数の映像受信側デバイスからのそれぞれの負荷指標に基づいて選択する、装置（３５）。
付記５０．前記それぞれの負荷指標が、前記複数の映像受信側デバイス（１０）それぞれの負荷率設定点を示す、付記４９に記載の装置（３５）。
付記５１．前記複数の映像受信側デバイス（１０）が、複数のテレビジョン・チャネルにそれぞれ同調することができる、付記４９に記載の装置（３５）。
付記５２．前記それぞれの負荷指標によれば、前記選択された映像受信側デバイス（１０）はより軽い負荷を有する、付記４９に記載の装置（３５）。

Claims (13)

1. プロキシ・サーバ・ゲートウェイである要求サーバ・デバイスにおいて、
   複数のチャネルの１つの映像をダウンロードすることを求める要求をクライアント・デバイスから受信するステップと、
   それぞれが前記複数のチャネルに同調することができる個別のチューナを有する第１の映像受信側デバイスおよび第２の映像受信側デバイスからそれぞれの負荷指標を受信するステップであって、前記第１の映像受信側デバイス及び前記第２の映像受信側デバイスは、前記クライアント・デバイスに前記映像を伝送する機能を提供するゲートウェイである、ステップと、
   前記負荷指標に従って、前記第１の映像受信側デバイスおよび前記第２の映像受信側デバイスの一方を選択するステップと、
   前記選択した映像受信側デバイスに、チャネルを同調して前記映像を受信するように要求するステップと、
   前記選択した映像受信側デバイスに、前記映像を、前記クライアント・デバイスが知っているアドレスを使用して伝送するように命令するステップであって、前記選択した映像受信側デバイスは、前記プロキシ・サーバ・ゲートウェイを回避して前記映像を前記クライアント・デバイスに伝送する、ステップと、を含む、前記方法。
2. 前記選択した映像受信側デバイスに前記アドレスを提供するステップをさらに含む、請求項１に記載の方法。
3. 前記第１の映像受信側デバイスおよび前記第２の映像受信側デバイスの一方がマルチキャストを使用して前記複数の映像ソースのうちの１つからの映像を送信している場合に、前記クライアント・デバイスにマルチキャスト・ネットワーク・アドレスを送信して、前記クライアント・デバイスが前記マルチキャスト・ネットワーク・アドレスを使用して前記複数の映像ソースのうちの前記１つからの前記映像を受信することができるようにするステップ、もしくは、
   前記第１の映像受信側デバイスおよび前記第２の映像受信側デバイスの一方がユニキャストを使用して前記複数の映像ソースのうちの１つからの映像を送信している場合に、前記送信している映像受信側デバイスに、ユニキャストをマルチキャストに変換するように要求し、前記クライアント・デバイスにマルチキャスト・ネットワーク・アドレスを送信して、前記クライアント・デバイスが前記マルチキャスト・ネットワーク・アドレスを使用して前記複数の映像ソースのうちの１つからの前記映像を受信することができるようにするステップ、をさらに含む、請求項１に記載の方法。
4. それぞれの負荷指標を受信する前記ステップが、定期的に実行される、請求項１に記載の方法。
5. 前記それぞれの負荷指標が、前記第１の映像受信側デバイスおよび前記第２の映像受信側デバイスそれぞれの負荷率設定点を示す、請求項１に記載の方法。
6. 前記それぞれの負荷指標によれば、前記選択された映像受信側デバイスの方が負荷が軽い、請求項１に記載の方法。
7. 請求項１乃至６のいずれか１項に記載の方法を行う、装置。
8. プロキシ・サーバ・ゲートウェイである要求サーバ・デバイスと、それぞれが複数のチャネルに同調することができる個別のチューナを有する複数の映像受信側デバイスとを備えるシステムにおいて、クライアント・デバイスにより行われる方法であって、前記複数の映像受信側デバイスは、前記クライアント・デバイスに前記映像を伝送するチューナ管理及び映像データ・ポンプ機能を提供するゲートウェイであり、前記要求サーバ・デバイスは、前記映像受信側デバイスのそれぞれの負荷指標に基づいて前記複数の映像受信側デバイスの一つを選択し、クライアント・デバイスからの要求を供給し、
   前記複数のチャネルのうちの１つにより伝送されたプログラムを求める要求をクライアント・デバイスから前記要求サーバ・デバイスに送信するステップと、
   前記要求に応答して、前記クライアント・デバイスが前記要求サーバ・デバイスからアドレスを受信するステップと、
   前記アドレスを使用して、選択された映像受信側デバイスを介して、前記クライアント・デバイスが前記要求したプログラムを受信するステップであって、前記選択した映像受信側デバイスは、前記プロキシ・サーバ・ゲートウェイを回避して前記映像を前記クライアント・デバイスに伝送する、ステップと、
   を含む、前記方法。
9. 前記それぞれの負荷指標が、前記複数の映像受信側デバイスそれぞれの負荷率設定点を示す、請求項８に記載の方法。
10. 前記複数の映像受信側デバイスが、それぞれ複数のテレビジョン・チャネルに同調することができる、請求項８に記載の方法。
11. 前記それぞれの負荷指標によれば、前記選択された映像受信側デバイスはより軽い負荷を有する、請求項８に記載の方法。
12. 前記アドレスは、マルチキャスト・ネットワーク・アドレスである、請求項８に記載の方法。
13. 請求項８乃至１２のいずれか１項に記載の方法を行う、装置。

Images