装置接続形態における音声／ビデオ・ストリーミングのためのメッセージを送る構成
【課題】 装置接続形態における音声／ビデオ・ストリーミングのためのメッセージを送る構成を提供する。
【解決手段】 資源は、音声／ビデオ・ストリーミングのためのトポロジ内で管理されてもよい。トポロジは、音声／ビデオ・ソース及びシンク、並びに仲介のブランチ装置を有する。これらソース、シンク及びブランチ装置の間のメッセージは、資源管理のために用いられてもよい。
【解決手段】 資源は、音声／ビデオ・ストリーミングのためのトポロジ内で管理されてもよい。トポロジは、音声／ビデオ・ソース及びシンク、並びに仲介のブランチ装置を有する。これらソース、シンク及びブランチ装置の間のメッセージは、資源管理のために用いられてもよい。
【発明の詳細な説明】
【技術分野】
【０００１】
本願明細書は、概して、ビデオ及び音声データを発信及び受信する装置に関する。
【背景技術】
【０００２】
ＤｉｓｐｌａｙＰｏｒｔは、Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃ Ｓｔａｎｄａｒｄｓ Ａｓｓｏｃｉａｔｉｏｎ（ＶＥＳＡ）のデジタル音声／ビデオ相互接続規格である。該規格は、ビデオ及び音声をコンピュータからビデオ・ディスプレイ又は音声再生システムに結合することを可能にする。ＤｉｓｐｌａｙＰｏｒｔのコネクタは、クロック及び１．６２、２．７又は５．４ギガビット毎秒のシンボル・レートで任意の音声信号も伝達する主リンク内の１、２又は４個のデータ対に対応する。１．１規格は２００６年５月に承認され、２００９年にはデータ・レートが増大した１．２規格が公表された。ＤｉｓｐｌａｙＰｏｒｔ１．２規格は、１．１規格の帯域幅を２倍にした。
【０００３】
ＤｉｓｐｌａｙＰｏｒｔ１．２規格では、２つのＷＱＸＧＡモニタが音声／ビデオ・データを単一の送信リンクから受信するか、又は４個のＷＵＸＧＡモニタが単一の送信リンクからデータを受信してもよい。更に、１．２規格は、ユニバーサル・シリアル・バス（ＵＳＢ）周辺機器データ転送、マイクロホン音声転送又はカメラのビデオ転送に用いられうる更に速い速度のＡＵＸを可能にし、幾つかの用途に言及している。
【０００４】
ディスプレイ又は受信装置は、パーソナル・コンピュータ又は消費者電子機器のような送信装置に、直接に又は所謂ブランチ装置を通じて接続されうる。音声又はビデオ情報を中継するリピータ、音声又はビデオ情報をある形式から別の形式に変換する変換器、データを再生する複製器、及び２以上の送信装置からのストリームを入力として受け取りダウンストリーム・リンクに送信するコンセントレータを含む多くの種類のブランチ装置が存在する。ＤｉｓｐｌａｙＰｏｒｔ１．２のようなインタフェース規格は、１つのリンクに複数のストリームを許容する。このような場合に、これらの２以上の入力ストリームは、単一のダウンストリーム・リンクで送信されてもよい。幾つかのコンセントレータは、切り替え式に動作してもよい。つまり、１つの選択されたソースのみが同時に送信されてもよい。
【０００５】
同時に、送信装置、受信装置及びブランチ装置は、所与のソース（送信装置）がゼロ以上のブランチ装置を通じて１以上のシンク（受信装置）へビデオをストリーミングしうるトポロジを形成する。アクティブなビデオ・データは、種々の種類の装置を接続するリンクを通じて流れる。各リンクは、帯域幅及び対応するストリームの数により制約される。シンクは、ストリームを再生するための限られた数の音声及びビデオ・エンド・ポイントを有する。従って、トポロジに基づき、利用可能なビデオ又は音声資源に対する競争が存在しうる。
【０００６】
このようなトポロジの１つは、図１に示され、２個のソース及び５個のシンクを有しうる。ソース番号１は、シンク１にビデオをストリーミングすることを望み、ソース２は、シンク２にビデオをストリーミングすることを望み、ブランチ２とブランチ３との間のリンクは両方の経路に共通である。従って、ソースにおいて、この競争に関して、どれだけ多くの帯域幅が該リンク又は経路に沿った任意の他のリンクで利用可能であるかということを含む問題が生じうる。別の問題は、どのように資源が経路上に予約できるかということである。更に別の問題は、どれだけ多くのオーディオ／ビジュアル・ストリームが引き出せるかということである。他の問題は、どのように共有資源へのアクセスが管理されうるか、及びどのように誤りが伝達できるかということを含む。
【発明の概要】
【発明が解決しようとする課題】
【０００７】
本発明は、ビデオ及び音声データを発信及び受信する装置を提供する。
【図面の簡単な説明】
【０００８】
【図１】一実施形態による音声／ビデオ配信の概略図である。
【図２】一実施形態によるエニュメレーション、コミット及びリリースのシーケンス図である。
【図３】ブランチ装置一実施形態の概略図である。
【図４】一実施形態によるエニュメレーション・ソフトウェアのフローチャートである。
【図５】一実施形態によるメッセージ・シーケンス図である。
【図６】一実施形態による経路資源のエニュメレーションのシーケンス図である。
【図７】図６に示されたトポロジのために如何に種々のディスプレイ構成が構築されうるかを示すシーケンス図である。
【図８】一実施形態による２つのソースと２つのシンクとの間の可能なマッピングの図である。
【図９】一実施形態のフローチャートである。
【図１０】一実施形態のフローチャートである。
【図１１】一実施形態によるメッセージ・シーケンスを示す。
【図１２】一実施形態による上り動作経路のメッセージ・シーケンス図である。
【図１３】一実施形態による宛先のマッピングのシーケンスである。
【図１４】一実施形態による上りリンク動作経路メッセージのメッセージ・シーケンス図である。
【図１５】一実施形態によるソース装置とブランチ装置との間の接続の説明である。
【図１６】一実施形態による複数のソース装置とブランチ装置の説明である。
【図１７】一実施形態による２つのビデオ・エンド・ポイントを有するトポロジの説明である。
【図１８】一実施形態のフローチャートである。
【発明を実施するための形態】
【０００９】
幾つかの実施形態によると、特定のメッセージが、ビデオ及び音声データを送信及び受信する装置間で交換されてもよい。協調的な動作が、該メッセージに応答して、ソース装置とシンク装置との間の経路に沿った装置により行われてもよい。メッセージは、宛先アドレスにより特定される目標の宛先へ送信されてもよい。図２に示されるように、メッセージＥＮＵＭ＿ＰＡＴＨ＿ＲＥＳＯＵＲＣＥＳ、ＣＯＭＭＩＴ＿ＰＡＴＨ＿ＲＥＳＯＵＲＣＥＳ、及びＲＥＬＥＡＳＥ＿ＰＡＴＨ＿ＲＥＳＯＵＲＣＥＳが用いられてもよい。これらのメッセージは、例えば、ＤｉｓｐｌａｙＰｏｒｔ仕様のＡＵＸチャネルで送信されうる。
【００１０】
アドレス空間は、メッセージ送信の前に生成される。各ソース１０は、ＥＮＵＭ＿ＰＡＴＨ＿ＲＥＳＯＵＲＣＥメッセージ１８を所望のシンク１６へ送信し、主要リンク帯域幅とストリーム数をエニュメレートする。２０で示されるように、所望のシンク１６の直ぐ上流にあるブランチ装置１４は、利用可能な帯域幅（ＢＷ＝ｘ）及びストリーム数（＃ ＳＴＲＥＡＭＳ＝ｓ）で応答する。この応答が更に上流に伝搬される前に、２２に示されるように、上流のブランチ１２は、下流のブランチ１４からの利用可能な帯域幅（ＢＷ＝ｘ’）及びストリーム数（＃ ＳＴＲＥＡＭＳ＝ｓ’）を変更して、下流の経路から何が達成可能であるかを反映させる。
【００１１】
結局、ソース１０は、経路資源を得る。メッセージは（ＤｉｓｐｌａｙＰｏｒｔのＡＵＸのような）制御バスで送信されるが、クエリは主要リンクの資源のためのものである。制御バスの帯域幅には如何なる予約もなく、制御メッセージは、主要リンクの資源が１又は２つのソースにより完全に予約済みのときでも、トポロジ内の装置間で交換される。
【００１２】
メッセージ処理の一部として、各装置は、下流リンクとして利用可能な帯域幅の量を決定するために、主要リンクを特定の経路に沿ってトレーニングする必要があってよい。また、音声資源は、この手続の一部としてエニュメレートされる。これは、任意の所与の時点でストリーミングに利用可能なエンド・ポイントの数を決定するためである。
【００１３】
リンク帯域幅のエニュメレーションは、ビデオ・モード・エニュメレーションのようなオペレーティング・システムの動作に供給される。送り出されるべきビデオ・モードのエンドユーザによるこの及び非同期の選択に基づき、コミット手順は、次のようにＣＯＭＭＩＴ＿ＰＡＴＨ＿ＲＥＳＯＵＲＣＥＳメッセージ２４を用いて達成されてもよい。エニュメレートされた帯域幅は、コミット時間で利用可能でないかもしれない。例えば、異なるソースが異なるＥＮＵＭ＿ＰＡＴＨ＿ＲＥＳＯＵＲＣＥＳメッセージを任意の所与の時間に同一のシンクへ送信するかもしれない。それらは、共通のリンクを有する経路を有する異なるシンク宛てかもしれない。例として、ソース１のエニュメレーションのシーケンスの次に、ソース２のエニュメレーションが続き、その次にソース１のコミットが続く。ソース１のエニュメレーションのシーケンスの次に、例えば前のソース１のコミットのために失敗したソース２のコミットが続く。
【００１４】
ソース１０は、ＣＯＭＭＩＴ＿ＰＡＴＨ＿ＲＥＳＯＵＲＣＥメッセージ２４をシンク１６へ送信する。メッセージは、所望の帯域幅及びストリーム数を有する。特定の経路に沿った全ての装置（例えば、ブランチ１２及び１４）は、このソースのために資源を予約する。応答２６及び２８は、成功又は失敗を示してもよい。
【００１５】
各装置は、所望の資源のコミットに成功できるときにのみＣＯＭＭＩＴ＿ＰＡＴＨ＿ＲＥＳＯＵＲＣＥＳ２４を伝達する。異なるソース装置からの独立した資源のコミットに加え、経路に沿った中間リンクは、低い帯域幅を維持し、失敗の別の理由を提供してもよい。リンク・トレーニングは、送信機又は受信機を電気的構成に同意させるハンドシェイクである。装置のトポロジを説明するため、この概念は経路全体に拡張される。ここで、経路上の各リンクは、協調型と称される経路トレーニングでトレーニングされる必要がある。
【００１６】
幾つかの装置は、下流装置がコミットに失敗する前に、ビデオ・ストリームのコミットに成功した資源を有することが可能である。これらの資源をリリースするために、ソース装置は、ＣＯＭＭＩＴ＿ＰＡＴＨ＿ＲＥＳＯＵＲＣＥＳの受信に失敗した後に、ＲＥＬＥＡＳＥ＿ＰＡＴＨ＿ＲＥＳＯＵＲＣＥＳ３０メッセージを送出してもよい。
【００１７】
ＣＯＭＭＩＴ＿ＰＡＴＨ＿ＲＥＳＯＵＲＣＥＳの完了が成功した後に、アクティブ・ビデオが開始する。反対に、ストリームが終了するとき、ソースはＲＥＬＥＡＳＥ＿ＰＡＴＨ＿ＲＥＳＯＵＲＣＥＳ３２を発行し、経路に沿った装置でコミットされた資源のリリースを可能にする。
【００１８】
図３を参照すると、図３に３４として示されるように、ソース１０、シンク１６及び各ブランチ装置１２又は１４は、プロセッサ３６を有する。プロセッサは、受信機３８及び送信機４０に結合されてもよい。一実施形態では、プロセッサ３６は、エニュメレート・ソフトウェア４４を含むソフトウェアを格納する記憶装置４２に結合されてもよい。従って、記憶装置４２は、プロセッサ３６により実行される命令を格納するコンピュータ可読媒体であってもよい。記憶装置４２は、半導体、光学又は磁気メモリであってもよい。
【００１９】
図４に示されるエニュメレート・シーケンス４４は、一実施形態ではソフトウェアであってもよいが、ハードウェア又はファームウェアで実施されてもよい。菱形４６でのチェックは、エニュメレート・メッセージがブランチ装置により受信されているか否かを決定する。受信されている場合、メッセージを受信したブランチ装置は、上流のブランチ装置に対して、該受信した装置の利用可能な帯域幅及び利用可能なストリーム数で応答する。
【００２０】
受信した装置が、ある時間の後にエニュメレート・メッセージを受信しない場合、菱形５０でのチェックは、受信していない装置が、帯域幅及びストリーム数を指定する下流装置からのメッセージを受信する上流装置かどうかを決定する。下流装置からのメッセージを受信する上流装置である場合、上流装置は、該上流装置の能力を反映するために、受信した帯域幅及びストリーム数を変更する。次に、ブロック５４に示されるように、該上流装置は、元の帯域幅とストリーム数又は変更された数の何れかを必要に応じて次のブランチ又はソースへ送信する。
【００２１】
図５を参照すると、ストリームの追加及び削除のためのメッセージ・シーケンス図は、適切なストリーム識別子と共に、ソース６０及び２つのシンク６２、６４を有する。シンク１ ６２の識別子は「１」であり、シンク２ ６４の識別子は１．２である。各装置は、「１」又は「２」でラベル付けされたポートを有する。
【００２２】
次に、図６を参照すると、ソース１ ６０、ブランチ及びシンク１ ６２、並びにシンク２ ６４の間のシーケンス図が示される。ＡＵＸは制御チャネルを表し、主要リンクはデータ・チャネルを表す。
【００２３】
図５に示されたような、トポロジ内の各リンクは例えば独立した制御及びデータ・チャネルを有してもよく、接続はポイント・ツー・ポイントである。アドレッシング及びルーティング機構を用いて、任意の装置へ制御チャネルでメッセージを送信する機能がある。図６に示されるように、手順は、ソースにおいてストリームのためのローカル一意識別子、マッピング・テーブルの保守及びコンセントレータを含む。
【００２４】
アドレス生成段階中、アドレスは、アドレス生成メッセージを送信することにより、トポロジ内の各装置に同意される。次に、ソースは、ＥＮＵＭ＿ＰＡＴＨ＿ＲＥＳＯＵＲＣＥＳ６８をＡＵＸとして示される制御チャネルを介してブランチ及びシンク１ ６２へ送信する。また、ソースは、ＣＯＭＭＩＴ＿ＰＡＴＨ＿ＲＥＳＯＵＲＣＥＳメッセージ７０も制御経路を介してブランチ及びシンク１ ６２へ送信する。
【００２５】
バインディングは、トポロジ内の装置が次のストリームの宛先について同意するための手順である。バインディング手順は、エニュメレーションの後に、新たなストリームを送信したいソースで開始し、ＡＤＤ＿ＳＴＲＥＡＭメッセージ７２をローカル一意ストリーム識別子（例えば、シンク２の１．２）で識別される所望の宛先シンク装置へ送出する。ソース６０からシンク装置６４への経路に沿った全ての装置は、ストリーム識別子及びストリームが受信された入力ポート（例えば、１又は２）をマッピング・テーブル内に記憶している。
【００２６】
各ブランチ装置は、入力ストリーム識別子（該ブランチ装置のＩＤ１）の出力ストリーム識別子（シンク２ ６４の１．２）へのマッピングを実行する。複数のソースがない場合、入力ストリーム識別子は、出力ストリーム識別子と同一である。各ブランチ装置は、出力ストリーム識別子及び出力ポート番号も、自身のマッピング・テーブル内に記憶している。
【００２７】
最後に、７４で示されるように、ブランチ装置に如何なる他の資源の制約も存在しないならば、該ブランチ装置は、メッセージに含まれる経路／アドレスにより示される宛先へ該メッセージを転送する。このような資源の制約がある場合、ブランチ装置は、単に否定応答をソースへ送信する。メッセージは、所望の宛先で終端する。シンク装置がストリームを受信可能な場合、該シンク装置は確認応答７６でソースに応答する。その他の場合、シンク装置は、否定応答を送信する。次に、シンクは、データ・チャネルにある次の新たなストリームを消費する必要があることを知る。全てのブランチ装置は、確認応答７８をソースに返す。
【００２８】
確認応答を受信すると、ソース装置は、所望の宛先に至る自身のリンクのデータ・チャネルで新たなストリーム８０を送出する。８２で示されるように、ブランチ装置は、自身のマッピング・テーブルに記憶されている新たなストリームのための経路に沿ってストリームを転送する。シンク装置は、前に受信したメッセージに基づき、新たなストリームを消費する必要があることを知り、該ストリームをディスプレイで提示する。
【００２９】
バインディング解除又は削除は、同一のストリーム識別子を有する目的の宛先へ送信されるストリーム削除メッセージ８４、８６を通じて実行される。これは、シンク装置にストリームの停止を予期させ、ブランチ装置に該ブランチ装置のマッピング・テーブルを相応して変更させる。ストリーム削除メッセージに対する確認応答メッセージの受信は、ソースにデータ・チャネルでストリームを送信するのを停止させる。
【００３０】
図７に、図４に示されたトポロジのために構築されうる種々のディスプレイ構成が示される。「単一ディスプレイ」の構成は、音声ビデオ・データを提示する単に１つのディスプレイ装置である。該構成は、既に説明したメッセージ７２、７４、８０、８２、８４及び８６を用いる。「クローン・モード」構成は、同一のコンテンツ９２が送信され、２つのモニタ又はディスプレイ装置に表示される構成である。「拡張デスクトップ」は、異なる画像９４、９６が両方のモニタに示される代替のデュアル・ディスプレイ構成である。
【００３１】
図８に示されるように、複数のソース、つまりソース１ ９８及びソース２ １００が提示されるとき、各ソースは、重複する経路で同時に、同一のストリーム識別子を有する（例＃１の場合）ＡＤＤ＿ＳＴＲＥＡＭメッセージを発行してもよい。この場合、これらの新たなストリームのための重複する経路上にあるコンセントレータ・ブランチ装置１０２は、１つのソース（本例ではソース１）宛にＡＤＤ＿ＳＴＲＥＡＭメッセージを送信するだけであり、他をブロックする。つまり、１つの新たなストリームのみが一度に追加できる。ブロックされないソースのメッセージがデータ・チャネルを伝達した後に、更なるＡＤＤ＿ＳＴＲＥＡＭメッセージがブロックされたソースのために伝達される。
【００３２】
ブランチ装置１０４に複数の入力ポートが存在する場合、次に利用可能なストリーム識別子が割り当てられ、ブランチ装置は、自身の出力ストリーム識別子及びポート番号に対する入力ストリーム識別子及びポート番号を自身のマッピング・テーブル１０８に記憶する。
【００３３】
ある使用例として、新たなストリームが追加されてもよい。コンセントレータ・ブランチ装置は、アクティブでない識別子を有するストリーム追加メッセージを知ったとき、新たなエントリを自身のマッピング・テーブルに追加する。必要ならば、コンセントレータ・ブランチ装置は、該ストリームのための新たな出力識別子を生成し、ＡＤＤ＿ＳＴＲＥＡＭメッセージを伝達する間、該出力識別子を使用する。コンセントレータ・ブランチ装置は、この識別子のための宛先アドレスを自身のマッピング・テーブルに追加してもよい。別の使用例は、既存ストリームの拡張である。同一のソース装置が、別のＡＤＤ＿ＳＴＲＥＡＭメッセージを通じて既にアクティブなストリームに第２のシンクを追加する場合、コンセントレータ・ブランチ装置は、新たなエントリを自身のマッピング・テーブルに追加しない。何故なら、コンセントレータ・ブランチ装置が既に作成したマッピングは、依然として有効であるからである。しかしながら、コンセントレータは、自身の入力識別子への第２の宛先アドレスを自身のマッピング・テーブルに追加する。
【００３４】
更に別の使用例は、ストリームからのシンクの除去である。コンセントレータは、アクティブな識別子のシンクのアドレスを有するストリーム削除メッセージを受信したとき、宛先装置のリストから削除するためにシンクのアドレスをマーク付けする。次に、コンセントレータは、ストリーム削除確認応答メッセージをシンク装置から受信したとき、マッピング・テーブルを用いて該メッセージをソースへ返し、ソースにより認識されるべき識別子を変更する。次に、コンセントレータは、該ストリームのためのシンクのアドレスを自身のマッピング・テーブルから削除する。その識別子を有するストリームを受信する最後のシンクであった場合、コンセントレータは、自身のマッピング・テーブルからエントリを削除する。その他の場合、その識別子を有するストリームを消費する少なくとも１つのシンクが存在する場合、マッピング・テーブル内のエントリは削除されない。
【００３５】
図９を参照すると、上述のバインディングを実施する一実施形態によるシーケンス１１０が示される。このシーケンスはソフトウェア、ハードウェア又はファームウェアで実施されてもよい。ソフトウェアの実施形態では、シーケンスは、ブランチ装置３４の図３に示されるプロセッサ３６のようなプロセッサにより実行される命令により実施されてもよい。このような場合、シーケンスは、記憶装置４２に格納されてもよい。
【００３６】
最初に、ブロック１１２に示されるように、ブランチ装置は、ＡＤＤ＿ＳＴＲＥＡＭメッセージを受信する。ブロック１１４に示されるように、ブランチ装置は、該メッセージからのＳＴＲＥＡＭ＿ＩＤ及び入力ポートを自身のマッピング・テーブルに格納する。次に、ブロック１１６に示されるように、ブランチ装置は、入力ＳＴＲＥＡＭ＿ＩＤを出力ＳＴＲＥＡＭ＿ＩＤにマッピングする。ブロック１１８に示されるように、ブランチ装置は、出力ＳＴＲＥＡＭ＿ＩＤ及び出力ポート番号を自身のマッピング・テーブルに格納する。次に、ブロック１２０に示されるように、ブランチ装置はメッセージを転送する。最後に、ブロック１２２に示されるように、メッセージの配信が成功した場合、確認応答メッセージが下流装置から受信され、ブランチ装置は確認応答メッセージを上流へ転送する。
【００３７】
幾つかの実施形態では、図１０に示されるメッセージを送るフレームワーク１２４は、経路に沿った全ての装置による動作又は宛先装置のみによる動作を可能にしうる。メッセージは識別子を有し、新たな識別子は、新たなメッセージが定められる度に割り当てられる。メッセージを定めることは、経路メッセージか宛先メッセージかを決定することを含む。経路メッセージは、動作が実行される方向に依存して２種類ある。シンクへ向かう下り方向の場合、下り動作経路メッセージである。ソース装置へ向かう上り方向の場合、上り動作経路メッセージである。メッセージは、トポロジ内の任意の装置により開始されてもよい。各メッセージは、宛先アドレス及び関連経路情報を有する。
【００３８】
図１０に示されるメッセージを送るフレームワーク１２４は、ソフトウェア、ハードウェア又はファームウェアで実施されてもよい。例えば、フレームワーク１２４は、例えばブランチ装置又はシンク装置であってよい装置３４内の、図３に示された記憶装置４２のようなコンピュータ可読媒体に格納された命令の形式のソフトウェアで実施されてもよい。
【００３９】
一実施形態によると、図１０に示されるシーケンスは、ブロック１２６に示されるように、上流装置からメッセージを受信することにより開始する。メッセージを受信する装置は、２つの例として、ブランチ装置又はシンク装置であってもよい。ブロック１２８に示されるように、受信する装置は、最終的な宛先か否かに拘わらず、メッセージ定義を得る。次に、菱形１３０で、装置は、上り動作メッセージがメッセージ定義により示されるか否かを決定するために調べる。上り動作メッセージが示される場合、ブロック１３２に示されるように、装置は、該メッセージを受信すると、該メッセージ内で要求された動作を実行する。
【００４０】
その他の場合、上り動作メッセージでない場合、菱形１３４でのチェックは、下り動作メッセージか否かを決定する。下り動作メッセージの場合、ブロック１３６に示されるように、メッセージの受信とは対照的に、確認応答に対して動作が実行される。
【００４１】
反対に、下り動作メッセージでない場合、菱形１３８で決定されるように宛先メッセージの場合、ブロック１４０に示されるようにメッセージを受信する装置が最終的な宛先である場合にのみ、動作が実行される。
【００４２】
メッセージを送るフレームワークは、接続されたオーディオ・ビジュアル・ソース、ブランチ及びシンク装置のポイント・ツー・ポイント・トポロジ内の特定の経路上で、装置に協調した動作を実行させる。このフレームワークは、トポロジの発見、アドレス生成、ルーティング、バインディング及びストリーム管理、資源管理及び電力管理を含む種々の動作のために用いられうる。
【００４３】
図１１に示されるように、下り動作メッセージは、次のように動作する。メッセージの送信に先立ち、ソース１１０は、必要な任意のメッセージ固有の動作１１９を実行する。メッセージ１１２は、ソースの動作が成功した場合にのみ送信される。ソース装置は、アドレス／経路情報に基づき決定されたように、メッセージをダウンストリーム・ポートで送信することにより、該メッセージを宛先装置へ送信する。メッセージを受信する各ブランチ装置１１４若しくは１１６、又はシンク装置１１８は、該メッセージ種類により要求される動作１１９を実行する。宛先（例えば、シンク１１８）で動作の完了に成功すると、宛先は、確認応答（ＡＣＫ）１２０で応答する。この確認応答は、ソースに返送される。
【００４４】
図１２に示されるように、上り動作メッセージ１１２は、次のように動作する。ここで、動作１１９は、確認応答１２０の一部として行われる。
【００４５】
図１３に示されるように、宛先メッセージは動作する。動作１１９は、宛先、本例ではシンク１１８によってのみ行われる。経路内の他の装置は、メッセージ及び確認応答を単に転送する。
【００４６】
図１４に、経路上の全てのリンクをトレーニングする経路トレーニングのための下り動作メッセージの使用が示される。図１３で、各装置における動作１１９はリンク・トレーニングである。使用されるメッセージはＴＲＡＩＮ＿ＬＩＮＫＳ＿ＯＮ＿ＰＡＴＨであるが、如何なる他のメッセージも用いられうる。図１３で、メッセージはブランチ１１６へ向けられる。
【００４７】
図１５は、上り動作メッセージとして実施されるときの、ＴＲＡＩＮ＿ＬＩＮＫＳ＿ＯＮ＿ＰＡＴＨのメッセージ・シーケンス図である。ここで、全ての動作１１９は、確認応答１２０の一部として生じる。
【００４８】
インタフェース固有のフレームワークは、異なる経路を通じてエニュメレートされた機能が同一の装置の一部であることを、ソース装置に決定させてもよい。ＤｉｓｐｌａｙＰｏｒｔ規格は、「インタフェース」の例である。エニュメレーションのための異なる経路は、（ａ）異なるインタフェース種類を特徴付ける経路、又は（ｂ）同一のインタフェース種類の中の単に異なる経路、でありうる。フレームワークは、Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｗｉｎｄｏｗｓ（登録商標）及びユニバーサル・シリアル・バス（ＵＳＢ）のような他の技術の対応するコンテナ識別子と関連して装置を使用させ、接続された装置のために機能中心のユーザ・インタフェースというより装置中心のユーザ・インタフェースを実現させる。
【００４９】
フレームワークは、（ＤｉｓｐｌａｙＰｏｒｔの場合にはＤｉｓｐｌａｙＰｏｒｔコンフィグレーション・データ（ＤＰＣＤ）でありうる）一式のｃｏｎｔａｉｎｅｒ＿ＩＤと通じて公表されるレジスタ１６種類のグローバル一意識別子（ＧＵＩＤ）を有してもよい。ＤＰＣＤは、基本的に、状態チェック、コマンド通信、及び割り込みの状況を提供するために用いられる一式のレジスタである。ｃｏｎｔａｉｎｅｒ＿ＩＤレジスタは、ブランチ装置、複合シンク装置及び複数のトランスポートを有する如何なる装置でも対応されてよい。
【００５０】
所与の数のビデオ・エンド・ポイントを有するシンク装置は、その数の拡張ディスプレイ識別データ（Ｅｘｔｅｎｄｅｄ Ｄｉｓｐｌａｙ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ Ｄａｔａ：ＥＤＩＤ）構造で応答することを期待される。ＥＤＩＤデータ構造は、ソースに、モニタの能力に関して教える。ＥＤＩＤは、ＶＥＳＡ規格である。シンク装置が統合ユニバーサル・シリアル・バス（ＵＳＢ）又はハブ装置を有するとき、シンクのグローバル一意識別子は、該ＵＳＢ装置又はハブのコンテナ記述子内のグローバル一意識別子と一致する。装置に統合された全ての機能は、同一のグローバル一意識別子が通過するインタフェース種類に関係なく、該同一のグローバル一意識別子を通知（アドバタイズ）する。複数のビデオ・エンド・ポイントを有するシンクでは、各アドレスからのｃｏｎｔａｉｎｅｒ＿ＩＤレジスタは、同一のグローバル一意識別子を返す。トポロジ内の各装置では、ソース装置は、トポロジ発見処理の一部としてグローバル一意識別子を読み出す。装置がグローバル一意識別子を有する場合、ソース装置は、該グローバル一意識別子を読み出し、同一の装置が複数の経路又は複数のインタフェースを通じてアクセスされているかどうかを決定する。
【００５１】
その他の場合、ソース装置は、特定のインタフェース特定手段を通じて、同一の物理装置内にある機能を推測する。インタフェースがＤｉｓｐｌａｙＰｏｒｔ規格である場合、これは、下流装置の相対アドレス（ＲＡＤ）に基づきうる。装置のトポロジに直面するとき、通信を開始する各装置は、ネットワーク内で有効な宛先装置のアドレスを生成する必要がある。このアドレスは、相対アドレスと称される。何故なら、各装置により生成されたアドレスは有効であるが、同一の宛先のために別のソースで生成されたものとは異なりうるからである。次に、ソースは各相対アドレスからＥＤＩＤを読み出す。グローバル一意識別子が生成され、ＥＤＩＤを通じて識別されるように装置に関連付けられる。この生成されたグローバル一意識別子は、オペレーティング・システム内のコンテナ識別子のフレームワークと共に用いられる。
【００５２】
従って、幾つかの実施形態では、ＥＤＩＤは、ユニークなシリアル番号を有する。これが有効でない場合、複数のＥＤＩＤに関連付けられている同一のグローバル一意識別子が変更され、結果として粗悪なユーザ経験をもたらす。
【００５３】
図１６に、ソース装置とブランチ装置との間の複数の接続が示される。本例では、シンクへの２つの経路が存在するので、ソースは、該シンク装置のために２つのアドレスを生成する。ソースは、両方の経路を通じて同一のグローバル一意識別子を読み出すので、両方の経路が同一のシンク装置を読み出すと推測できる。グローバル一意識別子が失われてしまうと、ソースは同一であってよい両方の経路からＥＤＩＤを読み出し、グローバル一意識別子を生成し、そして該グローバル一意識別子をシンク装置に関連付ける。この識別子は、次に、オペレーティング・システムに返される。
【００５４】
図１７は、２つのビデオ・エンド・ポイントを有する例を示す。このソースのシーケンスは以下の通りである。ソースは、再び、シンク装置内の各エンド・ポイントに対して１つずつ、２つのアドレスを生成する。ソースは、各ビデオ・エンド・ポイントのアドレスからレジスタのコンテナ識別子を読み出す。シンクは自身の中に２つのインタフェースを有するので、フレームワークは、グローバル一意識別子がシンク装置内に存在することを要求し、グローバル一意識別子が両方のインタフェースで同一であることを要求する。ソースは、グローバル一意識別子が同一であることを検出し、２つのビデオ・エンド・ポイントが同一の物理装置の一部であると推定する。
【００５５】
図１８を参照すると、一実施形態によると、シーケンス１５０は、図３に示された形式でソースにより実施されてもよい。幾つかの実施形態では、図１８に示されるシーケンスは、ソフトウェア、ハードウェア又はファームウェアで実施されてもよい。ソフトウェアの実施形態では、シーケンスは、プロセッサ３６のようなプロセッサにより実行され記憶装置４２に格納される命令により実施されてもよい。
【００５６】
初期エニュメレーション又はトポロジ発見段階中に、識別子は、トポロジ内の装置毎に読み出される（ブロック１５２）。言い換えると、ソースは、トポロジ内の装置の識別子を得る。該識別子は、本願明細書で上述した如何なる識別子であってもよい。次に、ブロック１５４に示されるように、ソースは、経路を介してソースの下流の宛先へのコネクションを確立する。次に、ブロック１５６に示されるように、ソースは、コネクション経路内の装置の識別子を比較する。ブロック１５８で決定されるように、識別子が一致する場合、ソースは、一致する識別子を有する経路装置が同一のブランチ又はシンク装置の一部であると結論づける。従って、幾つかの実施形態では、２つの装置が同一の識別子を有するときに生じうる不明確さは、容易に対処されうる。
【００５７】
本願明細書を通じて「一実施形態」又は「ある実施形態」のような記載は、実施形態に関連して記載された特定の機能、構造、又は特徴が本発明に包含される少なくとも１つの実施形態に含まれることを意味する。従って、「一実施形態」又は「ある実施形態」のような記載は、必ずしも同一の実施形態を参照しない。更に、特定の機能、構造又は特徴は、図示された特定の実施形態以外の他の適切な形式で設けられてもよい。また、全てのこのような形式は、本願の特許請求の範囲内に包含されうる。
【００５８】
本発明は限られた数の実施形態に関して説明されたが、当業者はこれらの実施形態の多数の変形及び変更を理解するだろう。このような全ての代替、変更及び変形は本発明の真の精神と範囲に包含される。
【符号の説明】
【００５９】
１０ ソース
１２、１４ ブランチ
１６ シンク
３６ プロセッサ
４２ 記憶装置
６０ ソース
６０ ソース
６２ ブランチ＋シンク１
６４ シンク２
９８ ソース１
１００ ソース２
１１０ ソース
１１４ ブランチ
１１６ ブランチ
１１８ シンク
【技術分野】
【０００１】
本願明細書は、概して、ビデオ及び音声データを発信及び受信する装置に関する。
【背景技術】
【０００２】
ＤｉｓｐｌａｙＰｏｒｔは、Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃ Ｓｔａｎｄａｒｄｓ Ａｓｓｏｃｉａｔｉｏｎ（ＶＥＳＡ）のデジタル音声／ビデオ相互接続規格である。該規格は、ビデオ及び音声をコンピュータからビデオ・ディスプレイ又は音声再生システムに結合することを可能にする。ＤｉｓｐｌａｙＰｏｒｔのコネクタは、クロック及び１．６２、２．７又は５．４ギガビット毎秒のシンボル・レートで任意の音声信号も伝達する主リンク内の１、２又は４個のデータ対に対応する。１．１規格は２００６年５月に承認され、２００９年にはデータ・レートが増大した１．２規格が公表された。ＤｉｓｐｌａｙＰｏｒｔ１．２規格は、１．１規格の帯域幅を２倍にした。
【０００３】
ＤｉｓｐｌａｙＰｏｒｔ１．２規格では、２つのＷＱＸＧＡモニタが音声／ビデオ・データを単一の送信リンクから受信するか、又は４個のＷＵＸＧＡモニタが単一の送信リンクからデータを受信してもよい。更に、１．２規格は、ユニバーサル・シリアル・バス（ＵＳＢ）周辺機器データ転送、マイクロホン音声転送又はカメラのビデオ転送に用いられうる更に速い速度のＡＵＸを可能にし、幾つかの用途に言及している。
【０００４】
ディスプレイ又は受信装置は、パーソナル・コンピュータ又は消費者電子機器のような送信装置に、直接に又は所謂ブランチ装置を通じて接続されうる。音声又はビデオ情報を中継するリピータ、音声又はビデオ情報をある形式から別の形式に変換する変換器、データを再生する複製器、及び２以上の送信装置からのストリームを入力として受け取りダウンストリーム・リンクに送信するコンセントレータを含む多くの種類のブランチ装置が存在する。ＤｉｓｐｌａｙＰｏｒｔ１．２のようなインタフェース規格は、１つのリンクに複数のストリームを許容する。このような場合に、これらの２以上の入力ストリームは、単一のダウンストリーム・リンクで送信されてもよい。幾つかのコンセントレータは、切り替え式に動作してもよい。つまり、１つの選択されたソースのみが同時に送信されてもよい。
【０００５】
同時に、送信装置、受信装置及びブランチ装置は、所与のソース（送信装置）がゼロ以上のブランチ装置を通じて１以上のシンク（受信装置）へビデオをストリーミングしうるトポロジを形成する。アクティブなビデオ・データは、種々の種類の装置を接続するリンクを通じて流れる。各リンクは、帯域幅及び対応するストリームの数により制約される。シンクは、ストリームを再生するための限られた数の音声及びビデオ・エンド・ポイントを有する。従って、トポロジに基づき、利用可能なビデオ又は音声資源に対する競争が存在しうる。
【０００６】
このようなトポロジの１つは、図１に示され、２個のソース及び５個のシンクを有しうる。ソース番号１は、シンク１にビデオをストリーミングすることを望み、ソース２は、シンク２にビデオをストリーミングすることを望み、ブランチ２とブランチ３との間のリンクは両方の経路に共通である。従って、ソースにおいて、この競争に関して、どれだけ多くの帯域幅が該リンク又は経路に沿った任意の他のリンクで利用可能であるかということを含む問題が生じうる。別の問題は、どのように資源が経路上に予約できるかということである。更に別の問題は、どれだけ多くのオーディオ／ビジュアル・ストリームが引き出せるかということである。他の問題は、どのように共有資源へのアクセスが管理されうるか、及びどのように誤りが伝達できるかということを含む。
【発明の概要】
【発明が解決しようとする課題】
【０００７】
本発明は、ビデオ及び音声データを発信及び受信する装置を提供する。
【図面の簡単な説明】
【０００８】
【図１】一実施形態による音声／ビデオ配信の概略図である。
【図２】一実施形態によるエニュメレーション、コミット及びリリースのシーケンス図である。
【図３】ブランチ装置一実施形態の概略図である。
【図４】一実施形態によるエニュメレーション・ソフトウェアのフローチャートである。
【図５】一実施形態によるメッセージ・シーケンス図である。
【図６】一実施形態による経路資源のエニュメレーションのシーケンス図である。
【図７】図６に示されたトポロジのために如何に種々のディスプレイ構成が構築されうるかを示すシーケンス図である。
【図８】一実施形態による２つのソースと２つのシンクとの間の可能なマッピングの図である。
【図９】一実施形態のフローチャートである。
【図１０】一実施形態のフローチャートである。
【図１１】一実施形態によるメッセージ・シーケンスを示す。
【図１２】一実施形態による上り動作経路のメッセージ・シーケンス図である。
【図１３】一実施形態による宛先のマッピングのシーケンスである。
【図１４】一実施形態による上りリンク動作経路メッセージのメッセージ・シーケンス図である。
【図１５】一実施形態によるソース装置とブランチ装置との間の接続の説明である。
【図１６】一実施形態による複数のソース装置とブランチ装置の説明である。
【図１７】一実施形態による２つのビデオ・エンド・ポイントを有するトポロジの説明である。
【図１８】一実施形態のフローチャートである。
【発明を実施するための形態】
【０００９】
幾つかの実施形態によると、特定のメッセージが、ビデオ及び音声データを送信及び受信する装置間で交換されてもよい。協調的な動作が、該メッセージに応答して、ソース装置とシンク装置との間の経路に沿った装置により行われてもよい。メッセージは、宛先アドレスにより特定される目標の宛先へ送信されてもよい。図２に示されるように、メッセージＥＮＵＭ＿ＰＡＴＨ＿ＲＥＳＯＵＲＣＥＳ、ＣＯＭＭＩＴ＿ＰＡＴＨ＿ＲＥＳＯＵＲＣＥＳ、及びＲＥＬＥＡＳＥ＿ＰＡＴＨ＿ＲＥＳＯＵＲＣＥＳが用いられてもよい。これらのメッセージは、例えば、ＤｉｓｐｌａｙＰｏｒｔ仕様のＡＵＸチャネルで送信されうる。
【００１０】
アドレス空間は、メッセージ送信の前に生成される。各ソース１０は、ＥＮＵＭ＿ＰＡＴＨ＿ＲＥＳＯＵＲＣＥメッセージ１８を所望のシンク１６へ送信し、主要リンク帯域幅とストリーム数をエニュメレートする。２０で示されるように、所望のシンク１６の直ぐ上流にあるブランチ装置１４は、利用可能な帯域幅（ＢＷ＝ｘ）及びストリーム数（＃ ＳＴＲＥＡＭＳ＝ｓ）で応答する。この応答が更に上流に伝搬される前に、２２に示されるように、上流のブランチ１２は、下流のブランチ１４からの利用可能な帯域幅（ＢＷ＝ｘ’）及びストリーム数（＃ ＳＴＲＥＡＭＳ＝ｓ’）を変更して、下流の経路から何が達成可能であるかを反映させる。
【００１１】
結局、ソース１０は、経路資源を得る。メッセージは（ＤｉｓｐｌａｙＰｏｒｔのＡＵＸのような）制御バスで送信されるが、クエリは主要リンクの資源のためのものである。制御バスの帯域幅には如何なる予約もなく、制御メッセージは、主要リンクの資源が１又は２つのソースにより完全に予約済みのときでも、トポロジ内の装置間で交換される。
【００１２】
メッセージ処理の一部として、各装置は、下流リンクとして利用可能な帯域幅の量を決定するために、主要リンクを特定の経路に沿ってトレーニングする必要があってよい。また、音声資源は、この手続の一部としてエニュメレートされる。これは、任意の所与の時点でストリーミングに利用可能なエンド・ポイントの数を決定するためである。
【００１３】
リンク帯域幅のエニュメレーションは、ビデオ・モード・エニュメレーションのようなオペレーティング・システムの動作に供給される。送り出されるべきビデオ・モードのエンドユーザによるこの及び非同期の選択に基づき、コミット手順は、次のようにＣＯＭＭＩＴ＿ＰＡＴＨ＿ＲＥＳＯＵＲＣＥＳメッセージ２４を用いて達成されてもよい。エニュメレートされた帯域幅は、コミット時間で利用可能でないかもしれない。例えば、異なるソースが異なるＥＮＵＭ＿ＰＡＴＨ＿ＲＥＳＯＵＲＣＥＳメッセージを任意の所与の時間に同一のシンクへ送信するかもしれない。それらは、共通のリンクを有する経路を有する異なるシンク宛てかもしれない。例として、ソース１のエニュメレーションのシーケンスの次に、ソース２のエニュメレーションが続き、その次にソース１のコミットが続く。ソース１のエニュメレーションのシーケンスの次に、例えば前のソース１のコミットのために失敗したソース２のコミットが続く。
【００１４】
ソース１０は、ＣＯＭＭＩＴ＿ＰＡＴＨ＿ＲＥＳＯＵＲＣＥメッセージ２４をシンク１６へ送信する。メッセージは、所望の帯域幅及びストリーム数を有する。特定の経路に沿った全ての装置（例えば、ブランチ１２及び１４）は、このソースのために資源を予約する。応答２６及び２８は、成功又は失敗を示してもよい。
【００１５】
各装置は、所望の資源のコミットに成功できるときにのみＣＯＭＭＩＴ＿ＰＡＴＨ＿ＲＥＳＯＵＲＣＥＳ２４を伝達する。異なるソース装置からの独立した資源のコミットに加え、経路に沿った中間リンクは、低い帯域幅を維持し、失敗の別の理由を提供してもよい。リンク・トレーニングは、送信機又は受信機を電気的構成に同意させるハンドシェイクである。装置のトポロジを説明するため、この概念は経路全体に拡張される。ここで、経路上の各リンクは、協調型と称される経路トレーニングでトレーニングされる必要がある。
【００１６】
幾つかの装置は、下流装置がコミットに失敗する前に、ビデオ・ストリームのコミットに成功した資源を有することが可能である。これらの資源をリリースするために、ソース装置は、ＣＯＭＭＩＴ＿ＰＡＴＨ＿ＲＥＳＯＵＲＣＥＳの受信に失敗した後に、ＲＥＬＥＡＳＥ＿ＰＡＴＨ＿ＲＥＳＯＵＲＣＥＳ３０メッセージを送出してもよい。
【００１７】
ＣＯＭＭＩＴ＿ＰＡＴＨ＿ＲＥＳＯＵＲＣＥＳの完了が成功した後に、アクティブ・ビデオが開始する。反対に、ストリームが終了するとき、ソースはＲＥＬＥＡＳＥ＿ＰＡＴＨ＿ＲＥＳＯＵＲＣＥＳ３２を発行し、経路に沿った装置でコミットされた資源のリリースを可能にする。
【００１８】
図３を参照すると、図３に３４として示されるように、ソース１０、シンク１６及び各ブランチ装置１２又は１４は、プロセッサ３６を有する。プロセッサは、受信機３８及び送信機４０に結合されてもよい。一実施形態では、プロセッサ３６は、エニュメレート・ソフトウェア４４を含むソフトウェアを格納する記憶装置４２に結合されてもよい。従って、記憶装置４２は、プロセッサ３６により実行される命令を格納するコンピュータ可読媒体であってもよい。記憶装置４２は、半導体、光学又は磁気メモリであってもよい。
【００１９】
図４に示されるエニュメレート・シーケンス４４は、一実施形態ではソフトウェアであってもよいが、ハードウェア又はファームウェアで実施されてもよい。菱形４６でのチェックは、エニュメレート・メッセージがブランチ装置により受信されているか否かを決定する。受信されている場合、メッセージを受信したブランチ装置は、上流のブランチ装置に対して、該受信した装置の利用可能な帯域幅及び利用可能なストリーム数で応答する。
【００２０】
受信した装置が、ある時間の後にエニュメレート・メッセージを受信しない場合、菱形５０でのチェックは、受信していない装置が、帯域幅及びストリーム数を指定する下流装置からのメッセージを受信する上流装置かどうかを決定する。下流装置からのメッセージを受信する上流装置である場合、上流装置は、該上流装置の能力を反映するために、受信した帯域幅及びストリーム数を変更する。次に、ブロック５４に示されるように、該上流装置は、元の帯域幅とストリーム数又は変更された数の何れかを必要に応じて次のブランチ又はソースへ送信する。
【００２１】
図５を参照すると、ストリームの追加及び削除のためのメッセージ・シーケンス図は、適切なストリーム識別子と共に、ソース６０及び２つのシンク６２、６４を有する。シンク１ ６２の識別子は「１」であり、シンク２ ６４の識別子は１．２である。各装置は、「１」又は「２」でラベル付けされたポートを有する。
【００２２】
次に、図６を参照すると、ソース１ ６０、ブランチ及びシンク１ ６２、並びにシンク２ ６４の間のシーケンス図が示される。ＡＵＸは制御チャネルを表し、主要リンクはデータ・チャネルを表す。
【００２３】
図５に示されたような、トポロジ内の各リンクは例えば独立した制御及びデータ・チャネルを有してもよく、接続はポイント・ツー・ポイントである。アドレッシング及びルーティング機構を用いて、任意の装置へ制御チャネルでメッセージを送信する機能がある。図６に示されるように、手順は、ソースにおいてストリームのためのローカル一意識別子、マッピング・テーブルの保守及びコンセントレータを含む。
【００２４】
アドレス生成段階中、アドレスは、アドレス生成メッセージを送信することにより、トポロジ内の各装置に同意される。次に、ソースは、ＥＮＵＭ＿ＰＡＴＨ＿ＲＥＳＯＵＲＣＥＳ６８をＡＵＸとして示される制御チャネルを介してブランチ及びシンク１ ６２へ送信する。また、ソースは、ＣＯＭＭＩＴ＿ＰＡＴＨ＿ＲＥＳＯＵＲＣＥＳメッセージ７０も制御経路を介してブランチ及びシンク１ ６２へ送信する。
【００２５】
バインディングは、トポロジ内の装置が次のストリームの宛先について同意するための手順である。バインディング手順は、エニュメレーションの後に、新たなストリームを送信したいソースで開始し、ＡＤＤ＿ＳＴＲＥＡＭメッセージ７２をローカル一意ストリーム識別子（例えば、シンク２の１．２）で識別される所望の宛先シンク装置へ送出する。ソース６０からシンク装置６４への経路に沿った全ての装置は、ストリーム識別子及びストリームが受信された入力ポート（例えば、１又は２）をマッピング・テーブル内に記憶している。
【００２６】
各ブランチ装置は、入力ストリーム識別子（該ブランチ装置のＩＤ１）の出力ストリーム識別子（シンク２ ６４の１．２）へのマッピングを実行する。複数のソースがない場合、入力ストリーム識別子は、出力ストリーム識別子と同一である。各ブランチ装置は、出力ストリーム識別子及び出力ポート番号も、自身のマッピング・テーブル内に記憶している。
【００２７】
最後に、７４で示されるように、ブランチ装置に如何なる他の資源の制約も存在しないならば、該ブランチ装置は、メッセージに含まれる経路／アドレスにより示される宛先へ該メッセージを転送する。このような資源の制約がある場合、ブランチ装置は、単に否定応答をソースへ送信する。メッセージは、所望の宛先で終端する。シンク装置がストリームを受信可能な場合、該シンク装置は確認応答７６でソースに応答する。その他の場合、シンク装置は、否定応答を送信する。次に、シンクは、データ・チャネルにある次の新たなストリームを消費する必要があることを知る。全てのブランチ装置は、確認応答７８をソースに返す。
【００２８】
確認応答を受信すると、ソース装置は、所望の宛先に至る自身のリンクのデータ・チャネルで新たなストリーム８０を送出する。８２で示されるように、ブランチ装置は、自身のマッピング・テーブルに記憶されている新たなストリームのための経路に沿ってストリームを転送する。シンク装置は、前に受信したメッセージに基づき、新たなストリームを消費する必要があることを知り、該ストリームをディスプレイで提示する。
【００２９】
バインディング解除又は削除は、同一のストリーム識別子を有する目的の宛先へ送信されるストリーム削除メッセージ８４、８６を通じて実行される。これは、シンク装置にストリームの停止を予期させ、ブランチ装置に該ブランチ装置のマッピング・テーブルを相応して変更させる。ストリーム削除メッセージに対する確認応答メッセージの受信は、ソースにデータ・チャネルでストリームを送信するのを停止させる。
【００３０】
図７に、図４に示されたトポロジのために構築されうる種々のディスプレイ構成が示される。「単一ディスプレイ」の構成は、音声ビデオ・データを提示する単に１つのディスプレイ装置である。該構成は、既に説明したメッセージ７２、７４、８０、８２、８４及び８６を用いる。「クローン・モード」構成は、同一のコンテンツ９２が送信され、２つのモニタ又はディスプレイ装置に表示される構成である。「拡張デスクトップ」は、異なる画像９４、９６が両方のモニタに示される代替のデュアル・ディスプレイ構成である。
【００３１】
図８に示されるように、複数のソース、つまりソース１ ９８及びソース２ １００が提示されるとき、各ソースは、重複する経路で同時に、同一のストリーム識別子を有する（例＃１の場合）ＡＤＤ＿ＳＴＲＥＡＭメッセージを発行してもよい。この場合、これらの新たなストリームのための重複する経路上にあるコンセントレータ・ブランチ装置１０２は、１つのソース（本例ではソース１）宛にＡＤＤ＿ＳＴＲＥＡＭメッセージを送信するだけであり、他をブロックする。つまり、１つの新たなストリームのみが一度に追加できる。ブロックされないソースのメッセージがデータ・チャネルを伝達した後に、更なるＡＤＤ＿ＳＴＲＥＡＭメッセージがブロックされたソースのために伝達される。
【００３２】
ブランチ装置１０４に複数の入力ポートが存在する場合、次に利用可能なストリーム識別子が割り当てられ、ブランチ装置は、自身の出力ストリーム識別子及びポート番号に対する入力ストリーム識別子及びポート番号を自身のマッピング・テーブル１０８に記憶する。
【００３３】
ある使用例として、新たなストリームが追加されてもよい。コンセントレータ・ブランチ装置は、アクティブでない識別子を有するストリーム追加メッセージを知ったとき、新たなエントリを自身のマッピング・テーブルに追加する。必要ならば、コンセントレータ・ブランチ装置は、該ストリームのための新たな出力識別子を生成し、ＡＤＤ＿ＳＴＲＥＡＭメッセージを伝達する間、該出力識別子を使用する。コンセントレータ・ブランチ装置は、この識別子のための宛先アドレスを自身のマッピング・テーブルに追加してもよい。別の使用例は、既存ストリームの拡張である。同一のソース装置が、別のＡＤＤ＿ＳＴＲＥＡＭメッセージを通じて既にアクティブなストリームに第２のシンクを追加する場合、コンセントレータ・ブランチ装置は、新たなエントリを自身のマッピング・テーブルに追加しない。何故なら、コンセントレータ・ブランチ装置が既に作成したマッピングは、依然として有効であるからである。しかしながら、コンセントレータは、自身の入力識別子への第２の宛先アドレスを自身のマッピング・テーブルに追加する。
【００３４】
更に別の使用例は、ストリームからのシンクの除去である。コンセントレータは、アクティブな識別子のシンクのアドレスを有するストリーム削除メッセージを受信したとき、宛先装置のリストから削除するためにシンクのアドレスをマーク付けする。次に、コンセントレータは、ストリーム削除確認応答メッセージをシンク装置から受信したとき、マッピング・テーブルを用いて該メッセージをソースへ返し、ソースにより認識されるべき識別子を変更する。次に、コンセントレータは、該ストリームのためのシンクのアドレスを自身のマッピング・テーブルから削除する。その識別子を有するストリームを受信する最後のシンクであった場合、コンセントレータは、自身のマッピング・テーブルからエントリを削除する。その他の場合、その識別子を有するストリームを消費する少なくとも１つのシンクが存在する場合、マッピング・テーブル内のエントリは削除されない。
【００３５】
図９を参照すると、上述のバインディングを実施する一実施形態によるシーケンス１１０が示される。このシーケンスはソフトウェア、ハードウェア又はファームウェアで実施されてもよい。ソフトウェアの実施形態では、シーケンスは、ブランチ装置３４の図３に示されるプロセッサ３６のようなプロセッサにより実行される命令により実施されてもよい。このような場合、シーケンスは、記憶装置４２に格納されてもよい。
【００３６】
最初に、ブロック１１２に示されるように、ブランチ装置は、ＡＤＤ＿ＳＴＲＥＡＭメッセージを受信する。ブロック１１４に示されるように、ブランチ装置は、該メッセージからのＳＴＲＥＡＭ＿ＩＤ及び入力ポートを自身のマッピング・テーブルに格納する。次に、ブロック１１６に示されるように、ブランチ装置は、入力ＳＴＲＥＡＭ＿ＩＤを出力ＳＴＲＥＡＭ＿ＩＤにマッピングする。ブロック１１８に示されるように、ブランチ装置は、出力ＳＴＲＥＡＭ＿ＩＤ及び出力ポート番号を自身のマッピング・テーブルに格納する。次に、ブロック１２０に示されるように、ブランチ装置はメッセージを転送する。最後に、ブロック１２２に示されるように、メッセージの配信が成功した場合、確認応答メッセージが下流装置から受信され、ブランチ装置は確認応答メッセージを上流へ転送する。
【００３７】
幾つかの実施形態では、図１０に示されるメッセージを送るフレームワーク１２４は、経路に沿った全ての装置による動作又は宛先装置のみによる動作を可能にしうる。メッセージは識別子を有し、新たな識別子は、新たなメッセージが定められる度に割り当てられる。メッセージを定めることは、経路メッセージか宛先メッセージかを決定することを含む。経路メッセージは、動作が実行される方向に依存して２種類ある。シンクへ向かう下り方向の場合、下り動作経路メッセージである。ソース装置へ向かう上り方向の場合、上り動作経路メッセージである。メッセージは、トポロジ内の任意の装置により開始されてもよい。各メッセージは、宛先アドレス及び関連経路情報を有する。
【００３８】
図１０に示されるメッセージを送るフレームワーク１２４は、ソフトウェア、ハードウェア又はファームウェアで実施されてもよい。例えば、フレームワーク１２４は、例えばブランチ装置又はシンク装置であってよい装置３４内の、図３に示された記憶装置４２のようなコンピュータ可読媒体に格納された命令の形式のソフトウェアで実施されてもよい。
【００３９】
一実施形態によると、図１０に示されるシーケンスは、ブロック１２６に示されるように、上流装置からメッセージを受信することにより開始する。メッセージを受信する装置は、２つの例として、ブランチ装置又はシンク装置であってもよい。ブロック１２８に示されるように、受信する装置は、最終的な宛先か否かに拘わらず、メッセージ定義を得る。次に、菱形１３０で、装置は、上り動作メッセージがメッセージ定義により示されるか否かを決定するために調べる。上り動作メッセージが示される場合、ブロック１３２に示されるように、装置は、該メッセージを受信すると、該メッセージ内で要求された動作を実行する。
【００４０】
その他の場合、上り動作メッセージでない場合、菱形１３４でのチェックは、下り動作メッセージか否かを決定する。下り動作メッセージの場合、ブロック１３６に示されるように、メッセージの受信とは対照的に、確認応答に対して動作が実行される。
【００４１】
反対に、下り動作メッセージでない場合、菱形１３８で決定されるように宛先メッセージの場合、ブロック１４０に示されるようにメッセージを受信する装置が最終的な宛先である場合にのみ、動作が実行される。
【００４２】
メッセージを送るフレームワークは、接続されたオーディオ・ビジュアル・ソース、ブランチ及びシンク装置のポイント・ツー・ポイント・トポロジ内の特定の経路上で、装置に協調した動作を実行させる。このフレームワークは、トポロジの発見、アドレス生成、ルーティング、バインディング及びストリーム管理、資源管理及び電力管理を含む種々の動作のために用いられうる。
【００４３】
図１１に示されるように、下り動作メッセージは、次のように動作する。メッセージの送信に先立ち、ソース１１０は、必要な任意のメッセージ固有の動作１１９を実行する。メッセージ１１２は、ソースの動作が成功した場合にのみ送信される。ソース装置は、アドレス／経路情報に基づき決定されたように、メッセージをダウンストリーム・ポートで送信することにより、該メッセージを宛先装置へ送信する。メッセージを受信する各ブランチ装置１１４若しくは１１６、又はシンク装置１１８は、該メッセージ種類により要求される動作１１９を実行する。宛先（例えば、シンク１１８）で動作の完了に成功すると、宛先は、確認応答（ＡＣＫ）１２０で応答する。この確認応答は、ソースに返送される。
【００４４】
図１２に示されるように、上り動作メッセージ１１２は、次のように動作する。ここで、動作１１９は、確認応答１２０の一部として行われる。
【００４５】
図１３に示されるように、宛先メッセージは動作する。動作１１９は、宛先、本例ではシンク１１８によってのみ行われる。経路内の他の装置は、メッセージ及び確認応答を単に転送する。
【００４６】
図１４に、経路上の全てのリンクをトレーニングする経路トレーニングのための下り動作メッセージの使用が示される。図１３で、各装置における動作１１９はリンク・トレーニングである。使用されるメッセージはＴＲＡＩＮ＿ＬＩＮＫＳ＿ＯＮ＿ＰＡＴＨであるが、如何なる他のメッセージも用いられうる。図１３で、メッセージはブランチ１１６へ向けられる。
【００４７】
図１５は、上り動作メッセージとして実施されるときの、ＴＲＡＩＮ＿ＬＩＮＫＳ＿ＯＮ＿ＰＡＴＨのメッセージ・シーケンス図である。ここで、全ての動作１１９は、確認応答１２０の一部として生じる。
【００４８】
インタフェース固有のフレームワークは、異なる経路を通じてエニュメレートされた機能が同一の装置の一部であることを、ソース装置に決定させてもよい。ＤｉｓｐｌａｙＰｏｒｔ規格は、「インタフェース」の例である。エニュメレーションのための異なる経路は、（ａ）異なるインタフェース種類を特徴付ける経路、又は（ｂ）同一のインタフェース種類の中の単に異なる経路、でありうる。フレームワークは、Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｗｉｎｄｏｗｓ（登録商標）及びユニバーサル・シリアル・バス（ＵＳＢ）のような他の技術の対応するコンテナ識別子と関連して装置を使用させ、接続された装置のために機能中心のユーザ・インタフェースというより装置中心のユーザ・インタフェースを実現させる。
【００４９】
フレームワークは、（ＤｉｓｐｌａｙＰｏｒｔの場合にはＤｉｓｐｌａｙＰｏｒｔコンフィグレーション・データ（ＤＰＣＤ）でありうる）一式のｃｏｎｔａｉｎｅｒ＿ＩＤと通じて公表されるレジスタ１６種類のグローバル一意識別子（ＧＵＩＤ）を有してもよい。ＤＰＣＤは、基本的に、状態チェック、コマンド通信、及び割り込みの状況を提供するために用いられる一式のレジスタである。ｃｏｎｔａｉｎｅｒ＿ＩＤレジスタは、ブランチ装置、複合シンク装置及び複数のトランスポートを有する如何なる装置でも対応されてよい。
【００５０】
所与の数のビデオ・エンド・ポイントを有するシンク装置は、その数の拡張ディスプレイ識別データ（Ｅｘｔｅｎｄｅｄ Ｄｉｓｐｌａｙ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ Ｄａｔａ：ＥＤＩＤ）構造で応答することを期待される。ＥＤＩＤデータ構造は、ソースに、モニタの能力に関して教える。ＥＤＩＤは、ＶＥＳＡ規格である。シンク装置が統合ユニバーサル・シリアル・バス（ＵＳＢ）又はハブ装置を有するとき、シンクのグローバル一意識別子は、該ＵＳＢ装置又はハブのコンテナ記述子内のグローバル一意識別子と一致する。装置に統合された全ての機能は、同一のグローバル一意識別子が通過するインタフェース種類に関係なく、該同一のグローバル一意識別子を通知（アドバタイズ）する。複数のビデオ・エンド・ポイントを有するシンクでは、各アドレスからのｃｏｎｔａｉｎｅｒ＿ＩＤレジスタは、同一のグローバル一意識別子を返す。トポロジ内の各装置では、ソース装置は、トポロジ発見処理の一部としてグローバル一意識別子を読み出す。装置がグローバル一意識別子を有する場合、ソース装置は、該グローバル一意識別子を読み出し、同一の装置が複数の経路又は複数のインタフェースを通じてアクセスされているかどうかを決定する。
【００５１】
その他の場合、ソース装置は、特定のインタフェース特定手段を通じて、同一の物理装置内にある機能を推測する。インタフェースがＤｉｓｐｌａｙＰｏｒｔ規格である場合、これは、下流装置の相対アドレス（ＲＡＤ）に基づきうる。装置のトポロジに直面するとき、通信を開始する各装置は、ネットワーク内で有効な宛先装置のアドレスを生成する必要がある。このアドレスは、相対アドレスと称される。何故なら、各装置により生成されたアドレスは有効であるが、同一の宛先のために別のソースで生成されたものとは異なりうるからである。次に、ソースは各相対アドレスからＥＤＩＤを読み出す。グローバル一意識別子が生成され、ＥＤＩＤを通じて識別されるように装置に関連付けられる。この生成されたグローバル一意識別子は、オペレーティング・システム内のコンテナ識別子のフレームワークと共に用いられる。
【００５２】
従って、幾つかの実施形態では、ＥＤＩＤは、ユニークなシリアル番号を有する。これが有効でない場合、複数のＥＤＩＤに関連付けられている同一のグローバル一意識別子が変更され、結果として粗悪なユーザ経験をもたらす。
【００５３】
図１６に、ソース装置とブランチ装置との間の複数の接続が示される。本例では、シンクへの２つの経路が存在するので、ソースは、該シンク装置のために２つのアドレスを生成する。ソースは、両方の経路を通じて同一のグローバル一意識別子を読み出すので、両方の経路が同一のシンク装置を読み出すと推測できる。グローバル一意識別子が失われてしまうと、ソースは同一であってよい両方の経路からＥＤＩＤを読み出し、グローバル一意識別子を生成し、そして該グローバル一意識別子をシンク装置に関連付ける。この識別子は、次に、オペレーティング・システムに返される。
【００５４】
図１７は、２つのビデオ・エンド・ポイントを有する例を示す。このソースのシーケンスは以下の通りである。ソースは、再び、シンク装置内の各エンド・ポイントに対して１つずつ、２つのアドレスを生成する。ソースは、各ビデオ・エンド・ポイントのアドレスからレジスタのコンテナ識別子を読み出す。シンクは自身の中に２つのインタフェースを有するので、フレームワークは、グローバル一意識別子がシンク装置内に存在することを要求し、グローバル一意識別子が両方のインタフェースで同一であることを要求する。ソースは、グローバル一意識別子が同一であることを検出し、２つのビデオ・エンド・ポイントが同一の物理装置の一部であると推定する。
【００５５】
図１８を参照すると、一実施形態によると、シーケンス１５０は、図３に示された形式でソースにより実施されてもよい。幾つかの実施形態では、図１８に示されるシーケンスは、ソフトウェア、ハードウェア又はファームウェアで実施されてもよい。ソフトウェアの実施形態では、シーケンスは、プロセッサ３６のようなプロセッサにより実行され記憶装置４２に格納される命令により実施されてもよい。
【００５６】
初期エニュメレーション又はトポロジ発見段階中に、識別子は、トポロジ内の装置毎に読み出される（ブロック１５２）。言い換えると、ソースは、トポロジ内の装置の識別子を得る。該識別子は、本願明細書で上述した如何なる識別子であってもよい。次に、ブロック１５４に示されるように、ソースは、経路を介してソースの下流の宛先へのコネクションを確立する。次に、ブロック１５６に示されるように、ソースは、コネクション経路内の装置の識別子を比較する。ブロック１５８で決定されるように、識別子が一致する場合、ソースは、一致する識別子を有する経路装置が同一のブランチ又はシンク装置の一部であると結論づける。従って、幾つかの実施形態では、２つの装置が同一の識別子を有するときに生じうる不明確さは、容易に対処されうる。
【００５７】
本願明細書を通じて「一実施形態」又は「ある実施形態」のような記載は、実施形態に関連して記載された特定の機能、構造、又は特徴が本発明に包含される少なくとも１つの実施形態に含まれることを意味する。従って、「一実施形態」又は「ある実施形態」のような記載は、必ずしも同一の実施形態を参照しない。更に、特定の機能、構造又は特徴は、図示された特定の実施形態以外の他の適切な形式で設けられてもよい。また、全てのこのような形式は、本願の特許請求の範囲内に包含されうる。
【００５８】
本発明は限られた数の実施形態に関して説明されたが、当業者はこれらの実施形態の多数の変形及び変更を理解するだろう。このような全ての代替、変更及び変形は本発明の真の精神と範囲に包含される。
【符号の説明】
【００５９】
１０ ソース
１２、１４ ブランチ
１６ シンク
３６ プロセッサ
４２ 記憶装置
６０ ソース
６０ ソース
６２ ブランチ＋シンク１
６４ シンク２
９８ ソース１
１００ ソース２
１１０ ソース
１１４ ブランチ
１１６ ブランチ
１１８ シンク
【特許請求の範囲】
【請求項１】
ビデオ・データを送信及び受信する装置を有する装置のトポロジ内の任意の装置に、メッセージ内の種類識別子に応じて該メッセージ内で指定された動作を行わせる段階、
を有する方法。
【請求項２】
前記トポロジ内の、ソースからシンクへ送信されたメッセージを受信する各装置に、該メッセージ内の識別子の特性に応じて動作を行わせる段階、
を有する請求項１に記載の方法。
【請求項３】
前記メッセージ識別子が、動作は宛先に向かう途中で行われると示すか否かを決定する段階、
前記メッセージ識別子が動作は宛先に向かう途中で行われると示す場合、前記メッセージを受信すると、要求された動作を実行する段階、
を有する請求項１に記載の方法。
【請求項４】
前記メッセージ識別子が、動作は最終的な宛先からの確認応答に対してのみ行われると示すか否かを決定する段階、
前記メッセージ識別子が動作は最終的な宛先からの確認応答に対してのみ行われると示す場合、確認応答を受信したときのみ、動作を実行する段階、
を有する請求項１に記載の方法。
【請求項５】
前記メッセージの識別子が、宛先のみが動作を実行すると示すか否かを決定する段階、
前記メッセージの識別子が宛先のみが動作を実行すると示す場合、受信装置が宛先装置であるかどうかを決定する段階、
受信装置が宛先装置である場合、及び受信装置が宛先装置である場合のみ、前記メッセージ内の動作を実行する段階、
を有する請求項１に記載の方法。
【請求項６】
装置が前記メッセージの宛先でない場合、前記メッセージを前記宛先への経路に沿って転送する段階、
を有する請求項５に記載の方法。
【請求項７】
前記メッセージ内の動作が完了すると、前記ソースへ確認応答を返す段階、
を有する請求項１に記載の方法。
【請求項８】
前記メッセージを受信すると、動作を要求するメッセージに応答して経路トレーニングを実施する段階、
を有する請求項１に記載の方法。
【請求項９】
前記メッセージの宛先から確認応答を受信したときのみ、動作を要求するメッセージを用いて経路トレーニングを実施する段階、
を有する請求項１に記載の方法。
【請求項１０】
メッセージの種類及び装置が該メッセージの宛先か否かに依存して、音声及びビデオ・データを送信及び受信する装置のトポロジ内の装置により、動作を要求するメッセージを受信する段階、
を有する請求項１に記載の方法。
【請求項１１】
コンピュータ可読媒体であって、ビデオ・データのソース及びシンクを有する装置のトポロジ内の装置のプロセッサにより実行されるための命令を格納し、
該命令は、
実行されるべき命令を有するメッセージを受信し、
メッセージの種類を決定し、
該メッセージの種類に基づき、該メッセージ内で指定された動作を実行する、
ためのものである、
ことを特徴とする媒体。
【請求項１２】
前記メッセージの種類が、動作は宛先に向かう途中で行われる種類のものである否かを決定し、
前記メッセージの種類が動作は宛先に向かう途中で行われる種類のものである場合、前記メッセージを受信すると、要求された動作を実行する、
ための命令を更に格納する請求項１１に記載の媒体。
【請求項１３】
前記メッセージが、動作は最終的な宛先からの確認応答に対してのみ実行される種類のものか否かを決定し、
前記メッセージが動作は最終的な宛先からの確認応答に対してのみ実行される種類のものである場合、確認応答を受信したときのみ、動作を実行する、
ための命令を更に格納する請求項１１に記載の媒体。
【請求項１４】
前記メッセージの種類が、宛先のみが動作を実行する種類のものか否かを決定し、
前記メッセージの種類が宛先のみが動作を実行する種類のものである場合、受信装置が宛先装置であるかどうかを決定し、
受信装置が宛先装置である場合、及び受信装置が宛先装置である場合のみ、前記メッセージ内に示された動作を実行する、
ための命令を更に格納する請求項１１に記載の媒体。
【請求項１５】
装置が前記メッセージの宛先でない場合、前記メッセージを前記宛先への経路に沿って転送する、
ための命令を更に格納する請求項１４に記載の媒体。
【請求項１６】
前記メッセージ内に示された動作が完了すると、前記ソースへ確認応答を返す、
ための命令を更に格納する請求項１１に記載の媒体。
【請求項１７】
前記メッセージを受信すると、動作を要求するメッセージに応答して経路トレーニングを実施する、
ための命令を更に格納する請求項１１に記載の媒体。
【請求項１８】
前記メッセージの宛先から確認応答を受信したときのみ、動作を要求するメッセージを用いて経路トレーニングを実施する、
ための命令を更に格納する請求項１１に記載の媒体。
【請求項１９】
メッセージの種類及び前記受信装置が該メッセージの宛先か否かに依存して、ビデオ・データを送信及び受信する装置のトポロジ内の装置により、動作を要求するメッセージを受信する、
ための命令を更に格納する請求項１１に記載の媒体。
【請求項２０】
前記メッセージのソースと宛先との間の該メッセージの経路に沿った装置により、該メッセージを行わせる、
ための命令を更に格納する請求項１１に記載の媒体。
【請求項２１】
装置のトポロジ内のビデオ・データを送信するソースから、該トポロジ内のシンクへのメッセージを受信する受信機、
ビデオ・データを前記シンクへ送信する送信機、
実行されるべき動作を有するソースからのメッセージを受信し、該メッセージの種類を決定し、該メッセージを受信すると、該メッセージの宛先から確認応答を受信すると、該メッセージ内に指定された動作を実行するか又は該動作を全く実行しないかを決定するユニット、
を有する装置。
【請求項２２】
前記ユニットは、
前記メッセージの種類が、動作は宛先に向かう途中で行われるものであるか否かを決定し、
前記メッセージの種類が動作は宛先に向かう途中で行われるものである場合、前記メッセージを受信すると、前記メッセージ内の動作を実行する、
ことを特徴とする請求項２１に記載の装置。
【請求項２３】
前記ユニットは、
前記メッセージが、動作は最終的な宛先からの確認応答に対してのみ実行される種類のものか否かを決定し、
前記メッセージが動作は最終的な宛先からの確認応答に対してのみ実行される種類のものである場合、確認応答を受信したときのみ、動作を実行する、
ことを特徴とする請求項２１に記載の装置。
【請求項２４】
前記ユニットは、
前記メッセージの種類が、前記メッセージの宛先のみが動作を実行する種類のものか否かを決定し、
前記メッセージの種類が前記メッセージの宛先のみが動作を実行する種類のものである場合、当該装置が宛先装置であるかどうかを決定し、
当該装置が宛先装置である場合、及び当該装置が宛先装置である場合のみ、前記メッセージ内に示された動作を実行する、
ことを特徴とする請求項２１に記載の装置。
【請求項１】
ビデオ・データを送信及び受信する装置を有する装置のトポロジ内の任意の装置に、メッセージ内の種類識別子に応じて該メッセージ内で指定された動作を行わせる段階、
を有する方法。
【請求項２】
前記トポロジ内の、ソースからシンクへ送信されたメッセージを受信する各装置に、該メッセージ内の識別子の特性に応じて動作を行わせる段階、
を有する請求項１に記載の方法。
【請求項３】
前記メッセージ識別子が、動作は宛先に向かう途中で行われると示すか否かを決定する段階、
前記メッセージ識別子が動作は宛先に向かう途中で行われると示す場合、前記メッセージを受信すると、要求された動作を実行する段階、
を有する請求項１に記載の方法。
【請求項４】
前記メッセージ識別子が、動作は最終的な宛先からの確認応答に対してのみ行われると示すか否かを決定する段階、
前記メッセージ識別子が動作は最終的な宛先からの確認応答に対してのみ行われると示す場合、確認応答を受信したときのみ、動作を実行する段階、
を有する請求項１に記載の方法。
【請求項５】
前記メッセージの識別子が、宛先のみが動作を実行すると示すか否かを決定する段階、
前記メッセージの識別子が宛先のみが動作を実行すると示す場合、受信装置が宛先装置であるかどうかを決定する段階、
受信装置が宛先装置である場合、及び受信装置が宛先装置である場合のみ、前記メッセージ内の動作を実行する段階、
を有する請求項１に記載の方法。
【請求項６】
装置が前記メッセージの宛先でない場合、前記メッセージを前記宛先への経路に沿って転送する段階、
を有する請求項５に記載の方法。
【請求項７】
前記メッセージ内の動作が完了すると、前記ソースへ確認応答を返す段階、
を有する請求項１に記載の方法。
【請求項８】
前記メッセージを受信すると、動作を要求するメッセージに応答して経路トレーニングを実施する段階、
を有する請求項１に記載の方法。
【請求項９】
前記メッセージの宛先から確認応答を受信したときのみ、動作を要求するメッセージを用いて経路トレーニングを実施する段階、
を有する請求項１に記載の方法。
【請求項１０】
メッセージの種類及び装置が該メッセージの宛先か否かに依存して、音声及びビデオ・データを送信及び受信する装置のトポロジ内の装置により、動作を要求するメッセージを受信する段階、
を有する請求項１に記載の方法。
【請求項１１】
コンピュータ可読媒体であって、ビデオ・データのソース及びシンクを有する装置のトポロジ内の装置のプロセッサにより実行されるための命令を格納し、
該命令は、
実行されるべき命令を有するメッセージを受信し、
メッセージの種類を決定し、
該メッセージの種類に基づき、該メッセージ内で指定された動作を実行する、
ためのものである、
ことを特徴とする媒体。
【請求項１２】
前記メッセージの種類が、動作は宛先に向かう途中で行われる種類のものである否かを決定し、
前記メッセージの種類が動作は宛先に向かう途中で行われる種類のものである場合、前記メッセージを受信すると、要求された動作を実行する、
ための命令を更に格納する請求項１１に記載の媒体。
【請求項１３】
前記メッセージが、動作は最終的な宛先からの確認応答に対してのみ実行される種類のものか否かを決定し、
前記メッセージが動作は最終的な宛先からの確認応答に対してのみ実行される種類のものである場合、確認応答を受信したときのみ、動作を実行する、
ための命令を更に格納する請求項１１に記載の媒体。
【請求項１４】
前記メッセージの種類が、宛先のみが動作を実行する種類のものか否かを決定し、
前記メッセージの種類が宛先のみが動作を実行する種類のものである場合、受信装置が宛先装置であるかどうかを決定し、
受信装置が宛先装置である場合、及び受信装置が宛先装置である場合のみ、前記メッセージ内に示された動作を実行する、
ための命令を更に格納する請求項１１に記載の媒体。
【請求項１５】
装置が前記メッセージの宛先でない場合、前記メッセージを前記宛先への経路に沿って転送する、
ための命令を更に格納する請求項１４に記載の媒体。
【請求項１６】
前記メッセージ内に示された動作が完了すると、前記ソースへ確認応答を返す、
ための命令を更に格納する請求項１１に記載の媒体。
【請求項１７】
前記メッセージを受信すると、動作を要求するメッセージに応答して経路トレーニングを実施する、
ための命令を更に格納する請求項１１に記載の媒体。
【請求項１８】
前記メッセージの宛先から確認応答を受信したときのみ、動作を要求するメッセージを用いて経路トレーニングを実施する、
ための命令を更に格納する請求項１１に記載の媒体。
【請求項１９】
メッセージの種類及び前記受信装置が該メッセージの宛先か否かに依存して、ビデオ・データを送信及び受信する装置のトポロジ内の装置により、動作を要求するメッセージを受信する、
ための命令を更に格納する請求項１１に記載の媒体。
【請求項２０】
前記メッセージのソースと宛先との間の該メッセージの経路に沿った装置により、該メッセージを行わせる、
ための命令を更に格納する請求項１１に記載の媒体。
【請求項２１】
装置のトポロジ内のビデオ・データを送信するソースから、該トポロジ内のシンクへのメッセージを受信する受信機、
ビデオ・データを前記シンクへ送信する送信機、
実行されるべき動作を有するソースからのメッセージを受信し、該メッセージの種類を決定し、該メッセージを受信すると、該メッセージの宛先から確認応答を受信すると、該メッセージ内に指定された動作を実行するか又は該動作を全く実行しないかを決定するユニット、
を有する装置。
【請求項２２】
前記ユニットは、
前記メッセージの種類が、動作は宛先に向かう途中で行われるものであるか否かを決定し、
前記メッセージの種類が動作は宛先に向かう途中で行われるものである場合、前記メッセージを受信すると、前記メッセージ内の動作を実行する、
ことを特徴とする請求項２１に記載の装置。
【請求項２３】
前記ユニットは、
前記メッセージが、動作は最終的な宛先からの確認応答に対してのみ実行される種類のものか否かを決定し、
前記メッセージが動作は最終的な宛先からの確認応答に対してのみ実行される種類のものである場合、確認応答を受信したときのみ、動作を実行する、
ことを特徴とする請求項２１に記載の装置。
【請求項２４】
前記ユニットは、
前記メッセージの種類が、前記メッセージの宛先のみが動作を実行する種類のものか否かを決定し、
前記メッセージの種類が前記メッセージの宛先のみが動作を実行する種類のものである場合、当該装置が宛先装置であるかどうかを決定し、
当該装置が宛先装置である場合、及び当該装置が宛先装置である場合のみ、前記メッセージ内に示された動作を実行する、
ことを特徴とする請求項２１に記載の装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【公開番号】特開２０１１−１６０４２２（Ｐ２０１１−１６０４２２Ａ）
【公開日】平成２３年８月１８日（２０１１．８．１８）
【国際特許分類】
【出願番号】特願２０１１−１４０５８（Ｐ２０１１−１４０５８）
【出願日】平成２３年１月２６日（２０１１．１．２６）
【出願人】（５９３０９６７１２）インテル コーポレイション (931)
【Ｆターム（参考）】
【公開日】平成２３年８月１８日（２０１１．８．１８）
【国際特許分類】
【出願日】平成２３年１月２６日（２０１１．１．２６）
【出願人】（５９３０９６７１２）インテル コーポレイション (931)
【Ｆターム（参考）】
[ Back to top ]