JP2017500805A - ピアツーピアワイヤレスディスプレイシステムにおけるシンクデバイスの複数のグループをサポートするためのセッション管理および制御プロシージャ - Google Patents

Abstract

ピアツーピアワイヤレスディスプレイシステムにおけるシンクデバイスの複数のグループをサポートするためのセッション管理および制御プロシージャのための装置および方法について説明する。一実装形態は、複数のシンクデバイスにマルチメディアコンテンツを送信するように構成された装置を含み得る。本装置は、Ｗｉ−Ｆｉピアツーピア接続を用いてシンクデバイスの各々に接続するように構成されたプロセッサを備え得る。上記プロセッサは、シンクデバイスの各々から能力情報を受信するようにさらに構成され得る。上記プロセッサは、グループセッションＩＤとトランスポートポート番号とを含む制御メッセージを生成するようにさらに構成され得る。上記プロセッサは、シンクデバイスのためのストリーミングパラメータのセットを決定するようにさらに構成され得る。上記プロセッサは、トランスポートポート番号を使用して、およびストリーミングパラメータのセットに従って、Ｗｉ−Ｆｉピアツーピア接続されたシンクデバイスの各々に特定のマルチメディアコンテンツを送信するようにさらに構成され得る。

Description

[0001]説明する技術は、一般にマルチメディアコンテンツのワイヤレスストリーミングに関する。より詳細には、本開示は、ピアツーピアワイヤレスディスプレイシステムにおけるシンクデバイスの複数のグループをサポートするためのセッション管理および制御プロシージャを対象とする。

[0002]あるワイヤレス通信対応デバイスから別のデバイスへの直接のビデオおよびオーディオの直接ストリーミングを可能にするための進歩が、最近なされている。１つのそのようなシステムは、「ミラキャスト」として知られている。ミラキャストは、Ｗｉ−Ｆｉ Ａｌｌｉａｎｃｅ（登録商標）によって公表されたワイヤレス（たとえば、ワイヤレスプロ
+レイプロトコルのための商標である。本明細書で使用するミラキャストという用語は、Ｗｉ−Ｆｉディスプレイ（ＷＦＤ：Wi-Fi Display）としても知られる、Ｗｉ−Ｆｉ Ａｌｌｉａｎｃｅのディスプレイ共有プロトコルの現在の形態を指す。ミラキャスト仕様は、ソースデバイスからシンクデバイスに任意のタイプのビデオビットストリームをストリーミングするために設計された。一例として、ソースはスマートフォンであり得、シンクはテレビ受像機であり得る。一般的なＩＥＥＥ８０２．１１ワイヤレスネットワークでは、クライアントデバイスはアクセスポイント（ＡＰ）デバイスを通して通信するが、直接デバイス通信をサポートする（Ｗｉ−Ｆｉ Ｄｉｒｅｃｔ（登録商標）などの）プロトコルが存在する。ミラキャストシステムは、スマートフォンからテレビジョンまたはコンピュータに、またはその逆など、あるデバイスから別のデバイスにディスプレイデータを送るために、そのようなプロトコルを使用する。ミラキャストシステムは、ソースデバイスのフレームバッファおよびスピーカーオーディオのコンテンツをＷｉ−Ｆｉ接続上でリモートディスプレイ／スピーカーデバイス（シンク）に共有することを伴う。

[0003]ミラキャストプロトコルは、ソースが、フレームバッファからのＲＧＢデータ、およびオーディオサブシステムからのＰＣＭ（パルスコード化変調）オーディオデータをキャプチャすることを伴う。フレームバッファのコンテンツは、ソース上で実行しているアプリケーションプログラムまたはメディアプレーヤから導出され得る。ソースは、次いで、ビデオおよびオーディオコンテンツを圧縮し、シンクデバイスにデータを送信する。ビットストリームを受信すると、シンクは、それのローカルディスプレイおよび／またはスピーカー上にビットストリームを復号およびレンダリングする。

[0004]現在のミラキャスト仕様は、１つのソースから１つのシンクデバイスへのマルチメディアストリーミングのためのセッション確立および制御を主に処理する。１つのソースデバイスからのメディアコンテンツをいくつかのシンクデバイスに共有することをサポートするために、Ｗｉ−Ｆｉディスプレイセッション管理は、シンクデバイスのグループへのメディアストリーミングの制御を可能にするための拡張を必要とする。

[0005]複数のシンクデバイスにマルチメディアコンテンツを送信するように構成された装置が提供される。本装置は、Ｗｉ−Ｆｉピアツーピア接続を用いて複数のシンクデバイスの各々に接続するように構成されたプロセッサを備える。上記プロセッサは、特定のマルチメディアコンテンツを要求するＷｉ−Ｆｉピアツーピア接続されたシンクデバイスの各々から能力情報を受信するようにさらに構成される。上記プロセッサは、グループセッションＩＤとトランスポートポート番号とを含む制御メッセージを生成するようにさらに構成され、トランスポートポート番号が、Ｗｉ−Ｆｉピアツーピア接続されたシンクデバイスの各々に、グループに関連付けられた特定のマルチメディアコンテンツを通信するために使用されるべきものである。上記プロセッサは、Ｗｉ−Ｆｉピアツーピア接続されたシンクデバイスの各々に制御メッセージを送信するようにさらに構成される。上記プロセッサは、グループセッションＩＤに関連付けられたＷｉ−Ｆｉピアツーピア接続されたシンクデバイスのためのストリーミングパラメータのセットを決定するようにさらに構成される。上記プロセッサは、トランスポートポート番号を使用して、およびストリーミングパラメータのセットに従って、Ｗｉ−Ｆｉピアツーピア接続されたシンクデバイスの各々に特定のマルチメディアコンテンツを送信するようにさらに構成される。

[0006]複数のシンクデバイスにマルチメディアコンテンツを送信する方法が提供される。本方法は、Ｗｉ−Ｆｉピアツーピア接続を用いて複数のシンクデバイスの各々に接続することを備える。本方法は、特定のマルチメディアコンテンツを要求するＷｉ−Ｆｉピアツーピア接続されたシンクデバイスの各々から能力情報を受信することをさらに備える。本方法は、グループセッションＩＤとトランスポートポート番号とを含む制御メッセージを生成することをさらに備え、トランスポートポート番号が、Ｗｉ−Ｆｉピアツーピア接続されたシンクデバイスの各々に、グループに関連付けられた特定のマルチメディアコンテンツを通信するために使用されるべきものである。本方法は、Ｗｉ−Ｆｉピアツーピア接続されたシンクデバイスの各々に制御メッセージを送信することをさらに備える。本方法は、グループセッションＩＤに関連付けられたＷｉ−Ｆｉピアツーピア接続されたシンクデバイスのためのストリーミングパラメータのセットを決定することをさらに備える。本方法は、トランスポートポート番号を使用して、およびストリーミングパラメータのセットに従って、Ｗｉ−Ｆｉピアツーピア接続されたシンクデバイスの各々に特定のマルチメディアコンテンツを送信することをさらに備える。

[0007]複数のシンクデバイスにマルチメディアコンテンツを送信するための装置が提供される。本装置は、Ｗｉ−Ｆｉピアツーピア接続を用いて複数のシンクデバイスの各々に接続するための手段を備える。本装置は、特定のマルチメディアコンテンツを要求するＷｉ−Ｆｉピアツーピア接続されたシンクデバイスの各々から能力情報を受信するための手段をさらに備える。本装置は、グループセッションＩＤとトランスポートポート番号とを含む制御メッセージを生成するための手段をさらに備え、トランスポートポート番号が、Ｗｉ−Ｆｉピアツーピア接続されたシンクデバイスの各々に、グループに関連付けられた特定のマルチメディアコンテンツを通信するために使用されるべきものである。本装置は、Ｗｉ−Ｆｉピアツーピア接続されたシンクデバイスの各々に制御メッセージを送信するための手段をさらに備える。本装置は、グループセッションＩＤに関連付けられたＷｉ−Ｆｉピアツーピア接続されたシンクデバイスのためのストリーミングパラメータのセットを決定するための手段をさらに備える。本装置は、トランスポートポート番号を使用して、およびストリーミングパラメータのセットに従って、Ｗｉ−Ｆｉピアツーピア接続されたシンクデバイスの各々に特定のマルチメディアコンテンツを送信するための手段をさらに備える。

[0008]実行されたとき、複数のシンクデバイスにマルチメディアコンテンツを送信することを装置に行わせるコードを備える非一時的コンピュータ可読媒体が提供される。本媒体は、実行されたとき、Ｗｉ−Ｆｉピアツーピア接続を用いて複数のシンクデバイスの各々に接続することを装置に行わせるコードをさらに備える。本媒体は、実行されたとき、特定のマルチメディアコンテンツを要求するＷｉ−Ｆｉピアツーピア接続されたシンクデバイスの各々から能力情報を受信することを装置に行わせるコードをさらに備える。本媒体は、実行されたとき、グループセッションＩＤとトランスポートポート番号とを含む制御メッセージを生成することを装置に行わせるコードをさらに備え、トランスポートポート番号が、Ｗｉ−Ｆｉピアツーピア接続されたシンクデバイスの各々に、グループに関連付けられた特定のマルチメディアコンテンツを通信するために使用されるべきものである。本媒体は、実行されたとき、Ｗｉ−Ｆｉピアツーピア接続されたシンクデバイスの各々に制御メッセージを送信することを装置に行わせるコードをさらに備える。本媒体は、実行されたとき、グループセッションＩＤに関連付けられたＷｉ−Ｆｉピアツーピア接続されたシンクデバイスのためのストリーミングパラメータのセットを決定することを装置に行わせるコードをさらに備える。本媒体は、実行されたとき、トランスポートポート番号を使用して、およびストリーミングパラメータのセットに従って、Ｗｉ−Ｆｉピアツーピア接続されたシンクデバイスの各々に特定のマルチメディアコンテンツを送信することを装置に行わせるコードをさらに備える。

[0009]ミラキャストマルチメディアストリーミングシステムの一実装形態におけるソースデバイスおよびシンクデバイスのブロック図。 [0010]図１Ａのミラキャストマルチメディアストリーミングシステムの一実装形態におけるソースデバイスのブロック図。 [0011]図１Ａのミラキャストマルチメディアストリーミングシステムの一実装形態におけるシンクデバイスのブロック図。 [0012]図１Ａのミラキャストマルチメディアストリーミングシステム内で採用され得るワイヤレスデバイスにおいて利用され得る様々な構成要素を示す図。 [0013]ソースデバイスからいくつかのシンクグループへのメディアストリーミングのためのトポロジーを示す図。 [0014]ソースデバイスから複数のシンクグループへのメディアストリーミングのためのグループ化例を示す図。 [0015]シンクデバイスがソース開始および制御グループセッションに加入するための例示的な一連のステップを示す図。 [0016]Ｗｉ−ＦｉディスプレイソースデバイスといくつかのＷｉ−Ｆｉディスプレイシンクデバイスとの間の、ソース中心ＲＴＳＰベース能力ネゴシエーションおよびグループセッション確立方法の１つの例示的な実装形態を示し、図６Ｂに続く図。 [0017]図６Ａの、Ｗｉ−ＦｉディスプレイソースデバイスといくつかのＷｉ−Ｆｉディスプレイシンクデバイスとの間の、ソース中心ＲＴＳＰベース能力ネゴシエーションおよびグループセッション確立方法の例示的な実装形態をさらに示す図。 [0018]Ｗｉ−ＦｉディスプレイソースデバイスといくつかのＷｉ−Ｆｉディスプレイシンクデバイスとの間の、ソース中心ＲＴＳＰベースグループセッション確立および能力ネゴシエーション方法の別の例示的な実装形態を示し、図７Ｂに続く図。 [0019]図７Ａの、Ｗｉ−ＦｉディスプレイソースデバイスといくつかのＷｉ−Ｆｉディスプレイシンクデバイスとの間の、ソース中心ＲＴＳＰベースグループセッション確立および能力ネゴシエーション方法の例示的な実装形態をさらに示す図。 [0020]Ｗｉ−ＦｉディスプレイソースデバイスといくつかのＷｉ−Ｆｉディスプレイシンクデバイスとの間の、ソース中心ＲＴＳＰベースグループセッション確立および能力ネゴシエーション方法の別の例示的な実装形態を示し、図８Ｂに続く図。 [0021]図８Ａの、Ｗｉ−ＦｉディスプレイソースデバイスといくつかのＷｉ−Ｆｉディスプレイシンクデバイスとの間の、ソース中心ＲＴＳＰベースグループセッション確立および能力ネゴシエーション方法の例示的な実装形態をさらに示す図。 [0022]Ｗｉ−ＦｉディスプレイソースデバイスといくつかのＷｉ−Ｆｉディスプレイシンクデバイスとの間の、ソース中心ＲＴＳＰベースグループセッション確立および能力ネゴシエーション方法の別の例示的な実装形態を示し、図９Ｂに続く図。 [0023]図９Ａの、Ｗｉ−ＦｉディスプレイソースデバイスといくつかのＷｉ−Ｆｉディスプレイシンクデバイスとの間の、ソース中心ＲＴＳＰベースグループセッション確立および能力ネゴシエーション方法の例示的な実装形態をさらに示す図。 [0024]Ｗｉ−Ｆｉディスプレイソースデバイスと、Ｗｉ−Ｆｉディスプレイマスタシンクデバイスと、いくつかの従属シンクデバイスとの間の、シンク中心ＲＴＳＰベースグループセッション管理方法の例示的な実装形態を示し、図１０Ｂに続く図。 [0025]図１０Ａの、Ｗｉ−Ｆｉディスプレイソースデバイスと、Ｗｉ−Ｆｉディスプレイマスタシンクデバイスと、いくつかの従属シンクデバイスとの間の、シンク中心ＲＴＳＰベースグループセッション管理方法の例示的な実装形態をさらに示す図。 [0026]Ｗｉ−Ｆｉディスプレイグループセッション管理のための例示的なサブエレメントコンテンツレイアウトを示し、図１１Ｂに続く図。 [0027]図１１Ａの、Ｗｉ−Ｆｉディスプレイグループセッション管理のための例示的なサブエレメントコンテンツレイアウトをさらに示す図。 [0028]グループセッションのためのマルチメディアコンテンツを配信するためのデータプレーンスタックの一例を示す図。

[0029]図面に示す様々な特徴は一定の縮尺で描かれていないことがある。したがって、様々な特徴の寸法は、明快のために恣意的に拡大または縮小されていることがある。さらに、図面のいくつかは、所与のシステム、方法またはデバイスの構成要素のすべてを示しているとは限らない。最後に、明細書および図の全体にわたって同様の特徴を示すために同様の参照番号が使用されることがある。

[0030]添付の図面に関して以下に示す発明を実施するための形態は、本発明のいくつかの実装形態を説明するものであり、本発明が実施され得る唯一の実装形態を表すものではない。この明細書全体にわたって使用する「例示的」という用語は、「例、事例、または例示の働きをすること」を意味し、必ずしも他の例示的な実装形態よりも好ましいまたは有利であると解釈すべきではない。発明を実施するための形態は、開示する実装形態の完全な理解を与えるための具体的な詳細を含む。いくつかの事例では、いくつかのデバイスをブロック図の形式で示す。

[0031]添付の図面を参照しながら、新規のシステム、装置、および方法の様々な態様について以下でより十分に説明する。ただし、開示する教示は、多くの異なる形態で実施され得、本開示全体にわたって提示されるいずれかの特定の構造または機能に限定されるものと解釈されるべきではない。むしろ、これらの態様は、本開示が周到で完全になり、本開示の範囲を当業者に十分に伝えるように与えられる。本明細書の教示に基づいて、本開示の範囲は、本発明の他の態様とは無関係に実装されるにせよ、本発明の他の態様と組み合わされるにせよ、本明細書で開示される新規のシステム、装置、および方法のいかなる態様をもカバーするものであることを、当業者なら諒解されたい。たとえば、本明細書に記載される態様をいくつ使用しても、装置は実装され得、または方法は実施され得る。さらに、本発明の範囲は、本明細書に記載される本発明の様々な態様に加えてまたはそれらの態様以外に、他の構造、機能、または構造および機能を使用して実施されるそのような装置または方法をカバーするものとする。本明細書で開示するどの態様も請求項の１つまたは複数の要素によって実施され得ることを理解されたい。

[0032]本明細書では特定の態様が説明されるが、これらの態様の多くの変形および置換は本開示の範囲内に入る。好適な態様のいくつかの利益および利点が説明されるが、本開示の範囲は特定の利益、使用、または目的に限定されるものではない。むしろ、本開示の態様は、様々なワイヤレス技術、システム構成、ネットワーク、および伝送プロトコルに広く適用可能であるものとし、それらのいくつかが例として、図および好適な態様についての以下の説明において示される。発明を実施するための形態および図面は、本開示を限定するものではなく説明するものにすぎず、本開示の範囲は添付の特許請求の範囲およびそれの均等物によって定義される。

[0033]上述のように、現在のミラキャスト仕様は、１つのソースから１つのシンクデバイスへのマルチメディアストリーミングのためのセッション確立および制御を主に処理する。ソースから複数のシンクデバイスの各々への個々のＷｉ−Ｆｉディスプレイ（ＷＦＤ）セッションを確立し、各シンクにマルチメディアコンテンツをストリーミングするために、いくつかの実装形態を拡張することが可能であり得る。しかしながら、セッション確立、セッション制御、およびメディアペイロード処理は、別個のプロトコルスタックおよびネットワークリソース（たとえば、ＴＣＰ／ＵＤＰポート）を維持することを必要とし、それは現在のミラキャスト仕様の範囲を越えている。さらに、この手法の複雑さおよび帯域幅要件は、そのような実装形態を少数のシンクデバイスに、または低品質メディアフォーマットに制限し得る。（たとえば、マルチキャストまたはブロードキャストとしての）複数セッション処理のための制御およびフレキシビリティの欠如により、この手法は、個々のシンクデバイスが同期外れになることをも生じ得る。さらに、そのような実装形態は、様々な製品の間で相互運用可能でないことがある。１つのソースデバイスからのメディアコンテンツをいくつかのシンクデバイスに共有することをサポートするために、Ｗｉ−Ｆｉディスプレイセッション管理は、シンクデバイスのグループへのメディアストリーミングの制御を可能にするための拡張を必要とする。この拡張は、複数デバイス（１：Ｎ）トポロジーのためのセッション確立、セッション制御、およびデータプレーン処理のための新しい構成の形態でもたらされ得る。

[0034]本開示は、本明細書ではシンクと呼ぶ第２のデバイス上での表示のために、本明細書ではソースと呼ぶ第１のデバイスが１つまたは複数の第２のデバイスにマルチメディアコンテンツを配信することを可能にするシステムおよび方法を対象とする。いくつかの実装形態では、各デバイスは、本明細書では「Ｗｉ−Ｆｉ」と呼ぶことがある、ワイヤレス通信プロトコルのＩＥＥＥ８０２．１１ファミリーのうちの１つまたは複数に従ってワイヤレス通信することが可能である。そのようなデバイスは、一般に、直接ではなく、アクセスポイント（ＡＰ）を通して通信するが、ソースデバイスが、いかなるＡＰまたは他の媒介をも使用せずに、直接シンクデバイスにマルチメディアコンテンツを送信することを可能にするプロトコルが開発されている。上記で説明したように、１つのそのようなプロトコルはミラキャストとして知られている。このプロトコルの拡張（enhancement）および拡大（extension）を以下に記載する。これらの拡張および拡大は、ミラキャストへの適用だけでなく、ローカル環境においてワイヤレスに接続されたデバイス上での、およびそれらの間でのディスプレイデータの送信、受信、およびプレゼンテーションを可能にするディスプレイ共有デバイスまたはプロトコル、システム、あるいは方法への適用をも有し、ここで、「ローカル」は、一般に、部屋、建築物内など、ワイヤレスＬＡＮ接続の範囲を指す。

[0035]ミラキャスト仕様の現在の状態では、シンクのグループにマルチメディアコンテンツをストリーミングすることはサポートされていない。能力ネゴシエーションおよびセッション確立は、１つのソースおよび１つのシンクデバイスに限定される。さらに、コンテンツのマルチキャスト／グループキャストのためのストリーミング制御がサポートされていないことがある。少なくともこれらの問題に対処するために、ピアツーピアストリーミング制御のためにミラキャストにおいて現在使用されているＲＴＳＰ（リアルタイムストリーミングプロトコル）制御プレーンが、シンクデバイスのグループを管理するために拡張され得る。さらに、ＰＥＳ（パケット化エレメンタリーストリーム）、ＭＰＥＧ２−ＴＳトランスポート、およびＲＴＰパケット化は、シンクデバイスのグループの能力に基づいてグループごとに行われ得る。ＭＰＥＧ２−ＴＳ多重化は、複数のプログラムのためのコンテンツを含み得る。さらに、ＲＴＳＰ制御スタックおよびコンテンツ処理データプレーンによるグループアドレス指定されたフレーム配信のためのＭＡＣレイヤ能力の知識が、セッションパラメータの効率的な設定を可能にし得る。

[0036]次に図１Ａ〜図１Ｃを参照すると、ミラキャストシステムにおいて、追加の制御通信および転送プロトコルネゴシエーションが、ソースデバイス３０とシンクデバイス３２との間で行われることがある。図１Ａに示されているように、ソース３０において、ディスプレイデータ３４がエンコーダ３６にルーティングされる。従来のミラキャストシステムでは、エンコーダ３６およびデコーダ３８は、それぞれ、ビデオの符号化および復号のためのＨ．２６４プロトコルを使用する。このデータは、次いで、従来のミラキャストシステムにおけるリアルタイムトランスポートプロトコル（ＲＴＳＰ）メッセージングを用いたＭＰＥＧ２トランスポートストリームを使用して、シンク３２にワイヤレスに送信される。シンク３２において受信されたとき、データは、対応するデコーダ３８にルーティングされ、シンク３２上のディスプレイ４０に送られる。制御信号はまた、ソース３０とシンク３２との間でパスされる。従来のミラキャストシステムでは、１つのピアツーピアセッションセットアップおよびセッション維持のための制御信号が利用される。

[0037]次に図１Ｂを参照すると、図１のソースデバイス３０の一実装形態のブロック図が示されている。図１Ｂでは、ソースデバイスは、グラフィックス処理ユニット（ＧＰＵ）５０と、ディスプレイプロセッサ／ブレンダ５２と、フレームバッファ５４と、ディスプレイ５６とを含む。ソースは、ユーザへのプレゼンテーションのためのディスプレイデータを与え得る、アプリケーション１ ６２およびアプリケーション２ ６４など、いくつかのアプリケーションを実行していることがある。ソースオペレーティングシステムの制御下で、ＧＰＵ５０およびディスプレイプロセッサ／ブレンダ５２は、ディスプレイ５６にフォワーディングするために、ディスプレイデータを準備し、フレームバッファ５４を充填する。ソースは、それもビデオデコーダを通してディスプレイプロセッサ／ブレンダ５２にコンテンツをルーティングする、メディアプレーヤ６６をも含み得る。

[0038]１つのソースと１つのシンクデバイスとの間のミラーリングモードでの従来のミラキャストマルチメディアストリーミングにおけるデータフローが、図１Ｂによって示されている。ミラキャストミラーリングが実行されているとき、フレームバッファ５４中のピクセルデータの連続フレームは、データ経路８０に沿ってビデオエンコーダ７２にルーティングされ、符号化されたデータは、モジュール７４によってＭＰＥＧ２トランスポートストリーム中に集められ、モジュール７５によってＲＴＰメッセージングデータと組み合わせられ、シンクデバイス３２への送信のためにソケット７７にルーティングされる。従来のミラキャストでは、エンコーダ７２はＨ．２６４エンコーダであり、ソケットはＵＤＰ（ユーザデータグラムプロトコル）ソケットであり、他のオプションはサポートされていない。

[0039]シンクデバイス３２を図１Ｃに示す。シンクでは、ソケット９２が着信データストリームを受信し、ＲＴＰヘッダ情報がモジュール９４を用いて抽出され、ディスプレイデータがモジュール９６を用いて抽出される。ディスプレイデータは、ビデオデコーダ９８にルーティングされ、次いで、ディスプレイプロセッサ／ブレンダ１０２にルーティングされ得、これにより、ディスプレイ１０６上でのプレゼンテーションのためにフレームバッファ１０４が充填される。従来のミラキャストでは、ビデオデコーダ９８は、ミラキャスト規格に適合するシンクデバイスにおいて必要とされるＨ．２６４デコーダである。

[0040]図２に、上記で説明したミラキャストマルチメディアストリーミングシステム内で採用され得るワイヤレスデバイス１８０において利用され得る様々な構成要素を示す。ワイヤレスデバイス１８０は、本明細書で説明する様々な方法を実装するように構成され得るデバイスの一例である。

[0041]ワイヤレスデバイス１８０は、ワイヤレスデバイス１８０の動作を制御するプロセッサ１８４を含み得る。プロセッサ１８４は中央処理ユニット（ＣＰＵ）と呼ばれることもある。読取り専用メモリ（ＲＯＭ）とランダムアクセスメモリ（ＲＡＭ）の両方を含み得るメモリ１８６は、命令とデータとをプロセッサ１８４に与える。メモリ１８６の一部は不揮発性ランダムアクセスメモリ（ＮＶＲＡＭ）をも含み得る。プロセッサ１８４は、一般に、メモリ１８６内に記憶されたプログラム命令に基づいて論理演算および算術演算を実行する。メモリ１８６中の命令は、本明細書で説明する方法を実装するために実行可能であり得る。たとえば、デバイスがソース３０であるのか、シンク３２であるのか、その両方であるのかに応じて、図１Ａ、図１Ｂ、および図１Ｃのブロックは、プロセッサ１８４およびメモリ１８６を用いて実装され得る。プロセッサ１８４は、１つまたは複数のプロセッサとともに実装された処理システムを備えるか、またはそれの構成要素であり得る。１つまたは複数のプロセッサは、汎用マイクロプロセッサ、マイクロコントローラ、デジタル信号プロセッサ（ＤＳＰ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、プログラマブル論理デバイス（ＰＬＤ）、コントローラ、状態機械、ゲート論理、個別ハードウェア構成要素、専用ハードウェア有限状態機械、あるいは情報の計算または他の操作を実行することができる任意の他の好適なエンティティの任意の組合せを用いて実装され得る。

[0042]処理システムは、ソフトウェアを記憶するための機械可読媒体をも含み得る。ソフトウェアは、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語などの名称にかかわらず、任意のタイプの命令を意味すると広く解釈されたい。命令は、（たとえば、ソースコード形式、バイナリコード形式、実行可能コード形式、または任意の他の好適なコード形式の）コードを含み得る。命令は、１つまたは複数のプロセッサによって実行されたとき、本明細書で説明する様々な機能を処理システムに実行させる。

[0043]ワイヤレスデバイス１８０はまた、ワイヤレスデバイス１８０と遠隔ロケーションとの間のデータの送信および受信を可能にするために送信機１９０と受信機１９２とを含み得るハウジング１８８を含み得る。送信機１９０と受信機１９２とは組み合わせられてトランシーバ１９４になり得る。アンテナ１９６が与えられ、トランシーバ１９４に電気的に結合され得る。ワイヤレスデバイス１８０はまた、複数の送信機、複数の受信機、複数のトランシーバ、および／または複数のアンテナを含み得る（図示せず）。

[0044]ワイヤレスデバイス１８０はまた、トランシーバ１９４によって受信された信号のレベルを検出し、定量化するために使用され得る信号検出器２００を含み得る。信号検出器２００は、そのような信号を、総エネルギー、シンボルごとのサブキャリア当たりのエネルギー、電力スペクトル密度、および他の信号として検出し得る。ワイヤレスデバイス１８０は、信号を処理する際に使用するデジタル信号プロセッサ（ＤＳＰ）２０２をも含み得る。ＤＳＰ２０２は、送信のためのデータユニットを生成するように構成され得る。ワイヤレスデバイス１８０は、ディスプレイ２０４とユーザインターフェース２０６とをさらに備え得る。ユーザインターフェース２０６は、タッチスクリーン、キーパッド、マイクロフォン、および／またはスピーカーを含み得る。ユーザインターフェース２０６は、ワイヤレスデバイス１８０のユーザに情報を伝達し、および／またはユーザからの入力を受信する、任意の要素または構成要素を含み得る。

[0045]ワイヤレスデバイス１８０の様々な構成要素は、１つまたは複数のバスシステム２０８によって互いに結合され得る。バスシステム２０８は、たとえば、データバス、ならびに、データバスに加えて、電力バスと、制御信号バスと、ステータス信号バスとを含み得る。ワイヤレスデバイス１８０の構成要素は、何らかの他の機構を使用して、互いに結合されるか、または互いに入力を受け付け、または与え得ることを当業者は諒解されよう。

[0046]いくつかの別個の構成要素が図２に示されているが、それらの構成要素のうちの１つまたは複数は、組み合わせられるかまたは共通に実装され得る。たとえば、プロセッサ１８４は、プロセッサ１８５に関して上記で説明した機能を実装するためだけでなく、信号検出器２００および／またはＤＳＰ２０２に関して上記で説明した機能を実装するためにも使用され得る。さらに、図７に示す構成要素の各々は、複数の別個の要素を使用して実装され得る。さらに、プロセッサ１８４は、以下で説明される構成要素、モジュール、回路などのいずれかを実装するために使用され得、または各々が複数の別個の要素を使用して実装され得る。

[0047]図３に、ソースデバイス３００からＫ個のシンクグループ３０５〜３０５Ｋへのメディアストリーミングのためのトポロジーを示す。このＷＦＤセッションは１：Ｎトポロジーを説明する。Ｎ個のシンクデバイス（３１０〜３１０Ｎ）は、Ｋ個のシンクグループ３０５〜３０５Ｋにグループ化され得る。各グループ（Ｇ（ｋ），ｋ＝１，．．．，Ｋ）は、ソースデバイス３００から複数の送信（たとえば、ユニキャスト、単一のマルチキャスト、グループキャストなど）を使用してメディアストリームを送るために、

のようなＰ_k個のシンクデバイスを有し得る。ソースデバイス３００およびＮ個のシンクデバイス３１０〜３１０Ｎは、Ｐ２Ｐ接続（たとえば、ピアツーピア、Ｗｉ−Ｆｉ Ｄｉｒｅｃｔなど）を使用し得る。また、これらのプロシージャは、たとえば、ＴＤＬＳ（トンネルドダイレクトリンクセットアップ）接続を使用するときに実装され得る。さらに、ソースデバイス３００はまた、通常Ｗｉ−Ｆｉ ＳＴＡとして構成された関連付けられたシンクデバイスをもつソフトＡＰとして構成され得る。一実装形態では、Ｋ個のシンクグループ３０５〜３０５Ｋのうちの１つ中のＮ個のシンクデバイス３１０〜３１０Ｎは、Ｐ２Ｐグループの一部であり得る。

[0048]このトポロジーについての例示的な使用事例は、（ソースデバイス３００としての）スマートフォンまたはタブレットが、（Ｎ個のシンクデバイス３１０〜３１０Ｎとしての）複数のラップトップまたはタブレットにマルチメディアクリップをストリーミングすることを含む。この例は、グループに対するプレゼンテーションなど、教室共有を含み得る。別の例は、（ソースデバイス３００としての）タブレットが、１つのウィンドウからのコンテンツをＮ個のシンクデバイス３１０〜３１０Ｎのセットに共有することを含み得る。シンクデバイスの複数のグループ（３０５〜３０５Ｋ）があり得、各グループは、ソースデバイス３００から別個のコンテンツストリームを受信し得る。たとえば、マルチメディアコンテンツが（Ｎ個のシンクデバイス３１０〜３１０Ｎとしての）タブレットのグループにストリーミングされ得、オーディオが共通オーディオシステムにストリーミングされ得る。別の例は、３Ｇ／４Ｇデータ接続をもつ（ソースデバイス３００としての）自動車ヘッドセットユニットが、インターネットからのマルチメディアコンテンツを助手席にある（Ｎ個のシンクデバイス３１０〜３１０Ｎとしての）タブレットまたはワイヤレスヘッドセットに共有することを含み得る。シンクの各グループ３０５〜３０５Ｋに送られるコンテンツは互いに異なり得、たとえば、あるデバイス上ではムービークリップをレンダリングし、他のデバイス上では音楽のみをレンダリングする。

[0049]図４に、ソースデバイス４００（たとえば、図３のソースデバイス３００）から複数のシンクグループ４０５Ａおよび４０５Ｂ（たとえば、図３のＫ個のシンクグループ３０５〜３０５Ｋのいずれか）へのメディアストリーミングのためのグループ化例を示す。一例では、シンクグループ４０５Ａは２つのシンクデバイス４１０Ａおよび４１０Ｂ（たとえば、Ｎ個のシンクデバイス３１０〜３１０Ｎのいずれか）を含み、シンクグループ４０５Ｂは３つのシンクデバイス４１０Ｃ、４１０Ｄ、および４１０Ｅ（たとえば、Ｎ個のシンクデバイス３１０〜３１０Ｎのいずれか）を含む。一例では、ソースデバイス４００はセルフォンであり得、シンクグループ４０５Ａは、たとえば、シンクデバイス４１０ＡのウルトラＨＤ（４Ｋ ２１６０ｐ）またはフルＨＤ（１０２０ｐ）ＤＴＶディスプレイ能力と、シンクデバイス４１０ＢにおけるＨＤ（７２０ｐ）ＤＴＶディスプレイ能力とを含み得るシンクデバイス４１０Ａおよび４１０Ｂに、７２０ｐ高精細度フォーマットビデオをもつマルチキャストビデオを送信するために使用され得る。さらに、シンクグループ４０５Ｂは、たとえば、異なる最大解像度（たとえば、８００×４８０ ｐ６０、１０２４×７６８ ｐ６０など）が可能な２つのタブレットディスプレイと、１２８０×９６０ ｐ６０解像度をもつラップトップディスプレイとを含み得るシンクデバイス４１０Ｃ、４１０Ｄ、および４１０Ｅに、ＷＶＧＡ（８００×４８０）フォーマットをもつマルチキャストプレゼンテーションを送信するために使用され得る。

[0050]図５に、シンクデバイスがソース開始および制御グループセッションに加入するための例示的な一連のステップを示す。このタイプのグループセッションは「ソース中心グループ」と呼ばれることもある。

[0051]ステップ１において、ピアツーピア接続が、ソースデバイス５００（たとえば、図３のソースデバイス３００）と、シンクデバイス５１０Ａ〜５１０Ｄのグループ（たとえば、Ｎ個のシンクデバイス３１０〜３１０Ｎのいずれか）との間で確立され得る。ピアツーピア接続はグループセッションと呼ばれることもある。接続を開始するために、ユーザは、シンクデバイスのグループへのマルチメディアストリーミングを処理するためのＷｉ−Ｆｉディスプレイ（ＷＦＤ）アプリケーションをソースデバイス５００からローンチし得、これにより、ソースデバイス５００は、シンクデバイス５１０Ａ〜５１０Ｄにそれのサービスおよびグループセッション能力を告知（たとえば、広告）することになり得る。告知のこの期間はＰ２Ｐデバイス発見段階と呼ばれることもある。マルチキャストデータ配信が、マルチキャストトラフィック（たとえば、８０２．１１ダイレクテッドマルチキャストサービス（ＤＭＳ）、またはリトライを用いるグループキャスト（ＧＣＲ：Group-cast with Retries））のためにＭＡＣレイヤによってサポートされるかまたは必要とされるとき、ソースデバイス５００は、グループオーナーになるというそれの意図をすでに広告していることがある。一実施形態では、ソースデバイス５００およびシンクデバイス５１０Ａ〜５１０Ｄは、グループメンバーシップを確立するためのＬ３ ＩＧＭＰプロトコル（インターネットグループ管理プロトコル−ＲＦＣ３３７６）を使用し得る。

[0052]Ｗｉ−Ｆｉディスプレイグループ動作をサポートするために、ＲＴＳＰメッセージングが、メッセージ交換におけるそれの信頼性、ならびに多数のシンクデバイスのそれの処理により、グループセッションのために使用され得る。グループ中のシンクデバイスの数に応じて、異なるＲＴＳＰシグナリングおよびストリーミング制御オプションが、ソースデバイス５００によって使用および広告され得る。たとえば、多数のシンクデバイス（図示せず）がある場合、ソースデバイス５００は、それのグループセッション（たとえば、共通セッション）開始要求メッセージのための、ＵＤＰを用いるＲＴＳＰ（ＲＴＳＰＵ：RTSP with UDP）方式（ＩＥＴＦ ＲＦＣ２３２６）（たとえば、ＡＮＮＯＵＮＣＥまたはＳＥＴＵＰなどの方法）を使用し得る。この方法および他のＲＴＳＰベース方法に関するさらなる詳細について、図６〜図９に関して以下で説明する。

[0053]使用されるＲＴＳＰ方法にかかわらず、ＲＴＳＰメッセージは、シンクデバイスがグループセッションに加入するための必要とされる能力、たとえば、共通マルチメディアコーデック、共通マルチメディアフォーマット、最小レイテンシまたはバッファ能力、またはサポートされるマルチキャスト機構（たとえば、ＤＭＳまたはＧＣＲ）に関する情報を含み得る。場合によっては、ＲＴＳＰメッセージは、ソースデバイス５００が、それがサービスしようとするシンクデバイスの最大数に基づいて設定し得る、キープアライブタイムアウトおよび応答時間制限情報をも含み得る。ソースデバイス５００はまた、ユニキャスト、非ＧＣＲマルチキャスト、ＤＭＳ、またはＧＣＲマルチキャストなど、適切なＭＡＣレイヤ送信方式に基づいてそのような情報を設定し得る。必要とされる能力をサポートするシンクデバイス（たとえば、５１０Ａ〜５１０Ｄ、および図示されていない何らかの追加のシンクデバイス）の各々は、ブロードキャストされたＲＴＳＰメッセージに応答し得る。ソースデバイス５００は、ブロードキャストされたＲＴＳＰメッセージを周期的に再送信し得る。これは、範囲内のすべてのシンクデバイスがＲＴＳＰメッセージを受信すること、および／または新たに発見されたいかなるシンクデバイスも、グループセッションに加入するための機会を有することを保証する。

[0054]発見期間中に、デバイスは、プローブ要求、プローブ応答、またはビーコンフレームなど、１つまたは複数のＭＡＣフレームを交換し得る（図示せず）。サポートされるグループタイプを含むグループセッション管理情報、何らかの事前構成されたコーデックおよび他のパラメータ、ならびにセッション管理制御のためのポート情報が、ピアツーピアデバイス発見のためのこれらのフレーム中に含まれる。交換された情報に基づいて、シンクデバイス５１０Ａ〜５１０Ｇのうちの１つまたは複数は、ソースデバイス５００と接続することを拒絶し得る。この例では、シンクデバイス５１０Ｄは、ソースデバイス５００と接続することを拒絶する。ソースデバイス５００は、次いで、ＵＤＰポートを作成し、ポート情報と他のセッション制御データ（たとえば、マルチキャストグループ）とを残りのシンクに送り得る。その情報およびデータを使用して、デバイスは、次いで、ピアツーピア接続またはグループセッションを形成し得る。

[0055]ステップ２において、ソースデバイス５００は、たとえば、マルチメディアコンテンツフォーマッティングと、マルチキャストグループ情報と、ＵＤＰポート情報とを含み得る、データプレーンに関する情報をもつＲＴＳＰメッセージを使用して、それのグループセッション構成を告知し得る。データプレーンのためのそれのグループセッション構成を告知することによって、ソースデバイス５００は、既存のグループセッションに加入するように他のシンクデバイスを効果的に勧誘する。マルチメディアフォーマット要件の最小セットが、グループセッションのためのデフォルト必須パラメータとして設定され得る。一実施形態では、グループセッションのための共通マルチメディアフォーマットは固定であり、たとえば、ＣＥＡ １２８０×７２０ｐ、２４ＦＰＳ解像度であり得る。いくつかの実装形態では、同じマルチメディアコンテンツが、シンクデバイスのあるグループに、ある共通フォーマットでストリーミングされ、シンクデバイスの別のグループに、別の共通フォーマットでストリーミングされ得る。この例では、グループセッション５０５Ａがシンクデバイス５１０Ａ〜５１０Ｃからなり、グループセッション５０５Ｂがシンクデバイス５１０Ｆ〜５１０Ｇからなる。シンクデバイス５１０Ｄは、それがステップ１において接続要求を拒絶したので、いずれのグループセッションにも現れない。ソースデバイス５００は、グループ化すべき、同じ能力をもつ少なくとも２つのシンクデバイスがあるとき、グループセッションを確立し得る。

[0056]効率を高め、処理を最小限に抑えるために、ソースデバイス５００は、「アクティブシンクデバイス」であるべき各グループ中のあらかじめ決定された数のシンクデバイスを選択し得る。グループセッション管理データ中でアクティブシンクデバイスに関する情報が更新され得る。アクティブシンクデバイスは、ソースデバイス５００によって送られたＲＴＳＰ要求メッセージに応答し得る。「パッシブシンクデバイス」と呼ばれる、シンクデバイスの残りは、ＲＴＳＰ要求メッセージに応答しないことがあり、ソースデバイス５００からマルチメディアコンテンツを受信し、非要請様式でそれらの能力情報を交換し得、たとえば、パッシブシンクデバイスは、アクティブシンクデバイスと比較して、ソースデバイス５００から、グループセッションにおけるストリーミングのために使用されるコンテンツフォーマットと、ポート情報とのみを受信し得る。

[0057]ステップ３において、ソースデバイス５００は、グループセッション５０５Ａにおけるシンクデバイス５１０Ａ〜５１０Ｃにマルチメディアコンテンツを送信（たとえば、ストリーミング）することを開始し得る。送信中の任意の時間において、マルチメディアコンテンツは、メディアコンテンツのネイティブフォーマットに基づいて異なるコーデックまたはフォーマット要件を有し得る、異なるマルチメディアコンテンツに切り替えられ得る。シンクデバイスがコンテンツのネイティブフォーマットをサポートすることができないとき、何らかの他のフォーマットへのトランスコーディングが必要とされ得る。一実装形態では、ソースデバイス５００は、グループセッション５０５Ａにおけるシンクデバイス５１０Ａ〜５１０Ｃのすべてに共通のフォーマットにコンテンツを再符号化し得る。グループセッション中に、ソースデバイス５００はまた、ステップ２の場合のようにＲＴＳＰメッセージを使用することによってグループセッション構成を周期的に告知し得る。ソースデバイス５００は、「一時停止」、「早送り」、「巻戻し」、フォーマット変更など、ストリーミング制御の大部分を処理し得る。

[0058]ステップ４において、新しいシンクデバイス５１０Ｅが、ステップ２またはステップ３中に送信されたグループセッション構成告知メッセージを受信し、グループセッション５０５Ａに加入し得る。新しいシンクデバイス５１０Ｅがグループセッション５０５Ａに加入すると、それも、ソースデバイス５００からグループセッション５０５Ａに送信されているマルチメディアコンテンツを受信することになる。新しいシンクデバイスは、任意の時間にグループセッションに加入することを要求し得る。同様に、現在グループセッションにあるシンクデバイスは、任意の時間にグループを出ることを要求し得る。

[0059]（たとえば、１つの継続する図として解釈される図６Ａおよび図６Ｂによって示される）図６に、Ｗｉ−ＦｉディスプレイソースデバイスといくつかのＷｉ−Ｆｉディスプレイシンクデバイスとの間の、ソース中心ＲＴＳＰベース能力ネゴシエーションおよびグループセッション確立方法の１つの例示的な実装形態を示す。図示の例では、シンクデバイスのすべてが同じグループ中にあると仮定される。この方法は、グループセッション確立および制御のためのメッセージおよびパラメータの追加によって、ＴＣＰポートを介した上記で説明したユニキャストＲＴＳＰメッセージングの効率を改善する。概して、この方法では、ソースは、信頼できる制御のための個々のＲＴＳＰ接続を確立し、グループ内でのストリーミング中にメディアデータのためのマルチキャストを可能にし得、これは、少数のシンクデバイスの場合に好適である。さらに、ステップ６７０に記載されているように、ソースは、シンクからＳＥＴＵＰ要求を受信することなしにグループセッションを自律的に開始するためのグループセッションＩＤを生成し得る。

[0060]ステップ６６１において、Ｗｉ−Ｆｉディスプレイソース６００は、Ｗｉ−Ｆｉディスプレイシンク６１０のうちの少なくとも１つとともに（この例では、シンク６１０Ａとともに）発見段階を開始する。発見段階中に交換される発見情報は、図５に関して上記で説明したように、グループセッション管理およびデバイス能力情報を含み得る。発見段階は、チャネル上のトラフィックの量に基づいて、選定されたチャネル（たとえば、チャネル１、６、または１１）上で行われ得る。さらに、発見情報は、プローブ要求およびプローブ応答フレームを介してソース６００とシンク６１０との間で交換され得る。

[0061]ステップ６６２において、シンク６１０のうちの１つまたは複数は、サービス発見情報をもソース６００と交換し得る。

[0062]ステップ６６３において、ソース６００は、ステップ６６１およびステップ６６２が行われたことをユーザ６５０に示し、いずれの１つまたは複数のシンク６１０が発見段階中に発見されたかをユーザ６５０に通知し得る（この例では、シンク６１０Ａが選択された）。

[0063]ステップ６６４において、ソース６００は、発見段階中に選択された１つまたは複数のシンク６１０との接続セットアップを完了し得る。場合によっては、接続セットアップはＷｉ−Ｆｉピアツーピアリンクであり得る。

[0064]ステップ６６５において、ソース６００は、それ自体と、発見段階中に選択された１つまたは複数のシンク６１０との間で能力情報を交換し得る。そのような能力情報は、特に、マルチメディアコーデック、マルチメディアフォーマット、最小レイテンシまたはバッファ能力、あるいはサポートされるマルチキャスト機構（たとえば、ＤＭＳまたはＧＣＲ）を含み得る。ソース６００は、能力情報を交換および設定するために、グループセッション管理情報を含めることによって、ＲＴＳＰ ＯＰＴＩＯＮＳと後続のＧＥＴ＿ＰＡＲＡＭＥＴＥＲコマンドとを使用し得る。

[0065]ステップ６６６において、ソース６００は、追加のシンク６１０とともに（この例では、シンク６１０Ｂおよび６１０Ｃとともに）、継続する発見段階を開始し得る。発見段階中に交換される発見情報は、グループセッション管理およびデバイス能力情報を含み得る。継続する発見段階中の情報の交換は、１つのシンクずつ行われ得、たとえば、ソース６００は、発見情報をシンク６１０Ｂと交換し、次いで、発見情報をシンク６１０Ｃと交換し得る。

[0066]ステップ６６７において、追加のシンク６１０のうちの１つまたは複数（ここでは、６１０Ｂおよび６１０Ｃ）は、ソース６００からのサービス発見情報をも交換し得る。

[0067]ステップ６６８において、ソース６００は、ステップ６６６および６６７が行われたことをユーザ６５０に示し、存在する、能力要件を満たすいくつかのシンク６１０（ここでは、シンク６１０Ａ、６１０Ｂ、および６１０Ｃ）が、発見段階中に選択されたことをユーザ６５０に通知し得る。

[0068]ステップ６６９において、ソース６００は、それ自体と、継続する発見段階中に選択された追加の１つまたは複数のシンク６１０（ここでは、６１０Ｂおよび６１０Ｃ）との間で能力情報を交換し得る。そのような能力情報は、特に、マルチメディアコーデック、マルチメディアフォーマット、最小レイテンシまたはバッファ能力、あるいはサポートされるマルチキャスト機構（たとえば、ＤＭＳまたはＧＣＲ）を含み得る。ソース６００は、能力情報を交換および設定するために、グループセッション管理情報とともに、ＲＴＳＰ ＯＰＴＩＯＮＳと後続のＧＥＴ＿ＰＡＲＡＭＥＴＥＲコマンドとを使用し得る。この段階中の情報の交換は、１つのシンクずつ行われ得、たとえば、ソース６００は、能力情報をシンク６１０Ｂと交換し、次いで、能力情報をシンク６１０Ｃと交換し得る。

[0069]ステップ６７０において、ソース６００は、グループセッションを確立する準備ができていることがある。グループセッションのそれの確立において、ソース６００は、上記のステップにおいて選択された１つまたは複数のシンクとの間での能力情報交換に基づいて、グループセッションのための最適パラメータを決定し得る。ソース６００はグループセッションのためのセッションＩＤをさらに生成し得る。

[0070]ステップ６７１において、ソース６００は告知段階に入り得、その間、それは、シンク６１０のうちの１つ（この場合、シンク６１０Ａ）にＲＴＳＰグループセッション情報の告知を送り得る。ソース６００は、告知を送るためにＲＴＳＰ ＡＮＮＯＵＮＣＥコマンドを使用し得る。告知は、特に、プレゼンテーションＵＲＬと、コーデックパラメータと、グループＩＰアドレスと、ＲＴＰポート番号と、特定のシンク６１０（ここでは、シンク６１０Ａ）とシンクするためのセッションＩＤとに関する情報を含み得る。告知段階中に、ソース６００はＷＦＤ−ＴＲＩＧＧＥＲ−ＭＥＴＨＯＤ＝ＷＡＩＴコマンドの下で動作し得、その間、それは、マルチメディアコンテンツを再生することを待つことになる。

[0071]ステップ６７２において、シンク６１０（ここでは、シンク６１０Ａ）は、それがステップ６７１の告知を受信したこと、およびそれがマルチメディアコンテンツを受信する準備ができていることを示すＲＴＳＰ ＯＫメッセージをソース６００に送り得る。

[0072]ステップ６７３において、ソース６００は継続する告知段階に入り得、その間、それは、追加のシンク６１０（この場合、シンク６１０Ｂおよび６１０Ｃ）にＲＴＳＰグループセッション情報の告知を送り得る。ソース６００は、再び、継続する告知を送るために、ＲＴＳＰ ＡＮＮＯＵＮＣＥコマンドを使用し得る。継続する告知は、特に、プレゼンテーションＵＲＬと、コーデックパラメータと、グループＩＰアドレスと、ＲＴＰポート番号と、特定の追加のシンク６１０（この場合、シンク６１０Ｂおよび６１０Ｃ）とシンクするためのセッションＩＤとに関する情報を含み得る。継続する告知段階中に、ソース６００は、ＷＦＤ−ＴＲＩＧＧＥＲ−ＭＥＴＨＯＤ＝ＰＬＡＹコマンドの下で動作し得、その間、ソース６００は、接続されたシンク６１０（ここでは、シンク６１０Ａ、６１０Ｂ、および６１０Ｃ）に対してマルチメディアコンテンツを再生する準備ができていることがある。

[0073]ステップ６７４において、追加のシンク６１０（ここでは、シンク６１０Ｂおよび６１０Ｃ）は、それらがステップ６７３の告知を受信したこと、およびそれらがマルチメディアコンテンツを受信する準備ができていることを示すＲＴＳＰ ＯＫメッセージをソース６００に送り得る。

[0074]ステップ６７５において、接続されたシンク６１０のうちの１つまたは複数は、ＲＴＳＰプレゼンテーションＵＲＬを介してソース６００に再生要求（たとえば、ＲＴＳＰ ＰＬＡＹ要求）を送り得る。

[0075]ステップ６７６において、ステップ６７５の再生要求に応答して、ソース６００は、たとえば、「ＰＬＡＹ応答ＯＫ」メッセージを介して、再生が始まることを要求元シンク６１０に通知し得る。

[0076]ステップ６７７において、ソース６００は、要求元シンク６１０にグループセッション上でマルチメディアコンテンツをストリーミングすることを開始し得る。この時間中に、ソース６００は「ＰＬＡＹＩＮＧ」のステータスを示し得る。

[0077]ステップ６７８において、要求元シンク６１０は、ソース６００からストリーミングマルチメディアコンテンツを受信し得る。

[0078]一実装形態では、ソース６００は、（上記のステップ６６５および６６９において説明した）個々のシンク６１０能力交換をスキップし、マルチメディアコンテンツパラメータのあらかじめ決定されたセット（たとえば、コンテンツのフォーマット）を用いてグループセッションを開始することを選択し得る。代わりに、マルチメディアコンテンツパラメータのあらかじめ決定されたセットは、（上記のステップ６６２および６６７において説明した）デバイスまたはサービス発見段階中にシンク６１０から取得され得る。

[0079]（たとえば、１つの継続する図として解釈される図７Ａおよび図７Ｂによって示される）図７に、Ｗｉ−ＦｉディスプレイソースデバイスといくつかのＷｉ−Ｆｉディスプレイシンクデバイスとの間の、ソース中心ＲＴＳＰベースグループセッション確立および能力ネゴシエーション方法の別の例示的な実装形態を示す。図示の例では、シンクデバイスのすべてが同じグループ中にあると仮定される。この方法は、この場合も、グループセッション確立および制御のためのメッセージおよびパラメータの追加によって、上記で説明したＴＣＰユニキャストＲＴＳＰの効率を改善する。概して、この方法では、ソースは、信頼できる制御のための個々のＲＴＳＰ接続を確立し、グループ内でのストリーミング中にメディアデータのためのマルチキャストを可能にし得、これは、少数のシンクデバイスの場合に好適である。さらに、以下で説明するように、および図６で説明した方法と比較して、ソースは、選択されたシンクデバイスのうちの１つとのセットアップ交換を実行し得る。

[0080]ステップ７６１において、Ｗｉ−Ｆｉディスプレイソース７００は、Ｗｉ−Ｆｉディスプレイシンク７１０のうちの少なくとも１つとともに（この例では、シンク７１０Ａとともに）発見段階を開始する。発見段階中に交換される発見情報は、図５に関して上記で説明したように、グループセッション管理およびデバイス能力情報を含み得る。発見段階は、チャネル上のトラフィックの量に基づいて、選定されたチャネル（たとえば、チャネル１、６、または１１）上で行われ得る。さらに、発見情報は、プローブ要求およびプローブ応答フレームを介してソース７００とシンク７１０との間で交換され得る。

[0081]ステップ７６２において、シンク７１０のうちの１つまたは複数は、サービス発見情報をもソース７００と交換し得る。

[0082]ステップ７６３において、ソース７００は、ステップ７６１およびステップ７６２が行われたことをユーザ７５０に示し、いずれの１つまたは複数のシンク７１０が発見段階中に発見されたかをユーザ７５０に通知し得る（この例では、シンク７１０Ａが選択された）。

[0083]ステップ７６４において、ソース７００は、発見段階中に選択された１つまたは複数のシンク７１０との接続セットアップを完了し得る。場合によっては、接続セットアップはＷｉ−Ｆｉピアツーピアリンクであり得る。

[0084]ステップ７６５において、ソース７００は、それ自体と、発見段階中に選択された１つまたは複数のシンク７１０との間で能力情報を交換し得る。そのような能力情報は、特に、マルチメディアコーデック、マルチメディアフォーマット、最小レイテンシまたはバッファ能力、あるいはサポートされるマルチキャスト機構（たとえば、ＤＭＳまたはＧＣＲ）を含み得る。ソース７００は、能力情報を交換および設定するために、グループセッション管理情報とともに、ＲＴＳＰ ＯＰＴＩＯＮＳおよびＧＥＴ＿ＰＡＲＡＭＥＴＥＲコマンドを使用し得る。

[0085]ステップ７６６において、ソース７００は、追加のシンク７１０とともに（この例では、シンク７１０Ｂおよび７１０Ｃとともに）、継続する発見段階を開始し得る。発見段階中に交換される発見情報は、グループセッション管理およびデバイス能力情報を含み得る。継続する発見段階中の情報の交換は、１つのシンクずつ行われ得、たとえば、ソース７００は、発見情報をシンク７１０Ｂと交換し、次いで、発見情報をシンク７１０Ｃと交換し得る。

[0086]ステップ７６７において、追加のシンク７１０のうちの１つまたは複数（ここでは、７１０Ｂおよび７１０Ｃ）は、ソース７００からのサービス発見情報をも交換し得る。

[0087]ステップ７６８において、ソース７００は、ステップ７６６および７６７が行われたことをユーザ７５０に示し、存在する、能力要件を満たすいくつかのシンク７１０（ここでは、シンク７１０Ａ、７１０Ｂ、および７１０Ｃ）が、発見段階中に選択されたことをユーザ７５０に通知し得る。

[0088]ステップ７６９において、ソース７００は、それ自体と、継続する発見段階中に選択された追加の１つまたは複数のシンク７１０（ここでは、７１０Ｂおよび７１０Ｃ）との間で能力情報を交換し得る。そのような能力情報は、特に、マルチメディアコーデック、マルチメディアフォーマット、最小レイテンシまたはバッファ能力、あるいはサポートされるマルチキャスト機構（たとえば、ＤＭＳまたはＧＣＲ）を含み得る。ソース７００は、能力情報を交換および設定するために、グループセッション管理情報とともに、ＲＴＳＰ ＯＰＴＩＯＮＳおよびＧＥＴ＿ＰＡＲＡＭＥＴＥＲコマンドを使用し得る。この段階中の情報の交換は、１つのシンクずつ行われ得、たとえば、ソース７００は、能力情報をシンク７１０Ｂと交換し、次いで、能力情報をシンク７１０Ｃと交換し得る。

[0089]ステップ７７０において、ソース７００は、グループセッションを確立する準備ができていることがある。グループセッションのそれの確立において、ソース７００は、上記のステップにおいて選択された１つまたは複数のシンクとの間での能力情報交換に基づいて、グループセッションのための最適パラメータを決定し得る。図６で説明した方法と比較して、ソース７００は、この時点でグループセッションのためのセッションＩＤを生成しないことがある。

[0090]ステップ７７１において、ソース７００は告知段階に入り得、その間、それは、シンク７１０のうちの１つ（この場合、シンク７１０Ａ）にＲＴＳＰグループセッション情報の告知を送り得る。ソース７００は、告知を送るためにＲＴＳＰ ＡＮＮＯＵＮＣＥコマンドを使用し得る。告知は、特に、プレゼンテーションＵＲＬと、コーデックパラメータと、グループＩＰアドレスと、ＲＴＰポート番号と、特定のシンク７１０（ここでは、シンク７１０Ａ）とシンクするためのセッションＩＤとに関する情報を含み得る。告知段階中に、ソース７００はＷＦＤ−ＴＲＩＧＧＥＲ−ＭＥＴＨＯＤ＝ＳＥＴＵＰコマンドの下で動作し得、その間、それは、個々のシンク７１０（ここでは、シンク７１０Ａ）からのセットアップ要求を待つことになる。

[0091]ステップ７７２において、シンク７１０（ここでは、シンク７１０Ａ）は、それがステップ７７１の告知を受信したことを示すＲＴＳＰ ＯＫメッセージをソース７００に送り得る。

[0092]ステップ７７３において、個々のシンク７１０（ここでは、シンク７１０Ａ）は、ＲＴＳＰプレゼンテーションＵＲＬを介してソース７００にＲＴＳＰセットアップ要求を送り得る。

[0093]ステップ７７４において、ソース７００は、ＲＴＳＰセットアップ要求のそれの確認および承認を個々のシンク７１０（ここでは、シンク７１０Ａ）に送り得る。図６に反して、ソース７００は、この時点でグループセッションＩＤを送り得る。

[0094]ステップ７７５において、ソース７００は継続する告知段階に入り得、その間、それは、追加のシンク７１０（この場合、シンク７１０Ｂおよび７１０Ｃ）にＲＴＳＰグループセッション情報の告知を送り得る。ソース７００は、再び、継続する告知を送るために、ＲＴＳＰ ＡＮＮＯＵＮＣＥコマンドを使用し得る。継続する告知は、特に、プレゼンテーションＵＲＬと、コーデックパラメータと、グループＩＰアドレスと、ＲＴＰポート番号と、特定の追加のシンク７１０（この場合、シンク７１０Ｂおよび７１０Ｃ）とシンクするためのセッションＩＤとに関する情報を含み得る。継続する告知段階中に、ソース７００はＷＦＤ−ＴＲＩＧＧＥＲ−ＭＥＴＨＯＤ＝ＳＥＴＵＰコマンドの下で動作し続け得、その間、ソース７００は、追加の接続されたシンク７１０（ここでは、シンク７１０Ｂおよび７１０Ｃ）からのセットアップ要求を待ち得る。

[0095]ステップ７７６において、追加のシンク７１０（ここでは、シンク７１０Ｂおよび７１０Ｃ）は、それらがステップ７７５の告知を受信したことを示すＲＴＳＰ ＯＫメッセージをソース７００に送り得る。

[0096]ステップ７７７において、追加のシンク７１０（ここでは、シンク７１０Ｂおよび７１０Ｃ）は、ＲＴＳＰプレゼンテーションＵＲＬを介してソース７００にＲＴＳＰセットアップ要求を送り得る。

[0097]ステップ７７８において、セットアップ要求に応答して、ソース７００は、ＲＴＳＰセットアップ要求のそれの確認および承認を追加のシンク７１０（ここでは、シンク７１０Ｂおよび７１０Ｃ）に送り得る。ソース７００は、この時点でグループセッションＩＤをも送り得る。

[0098]ステップ７７９において、接続されたシンク７１０のうちの１つまたは複数は、ＲＴＳＰプレゼンテーションＵＲＬを介してソース７００に再生要求（たとえば、ＲＴＳＰ ＰＬＡＹ要求）を送り得る。再生要求は、グループセッションＩＤに従って送られ得る。

[0099]ステップ７８０において、ステップ７７９の再生要求に応答して、ソース７００は、たとえば、「ＰＬＡＹ応答ＯＫ」メッセージを介して、再生が始まることを要求元シンク７１０に通知し得る。

[00100]ステップ７８１において、ソース７００は、要求元シンク７１０にグループセッション上でマルチメディアコンテンツをストリーミングすることを開始し得る。この時間中に、ソース７００は「ＰＬＡＹＩＮＧ」のステータスを示し得る。

[00101]ステップ７８２において、要求元シンク７１０は、ソース７００からストリーミングマルチメディアコンテンツを受信し得る。

[00102]一実装形態では、ソース７００は、（上記のステップ７６５および７６９において説明した）個々のシンク７１０能力交換をスキップし、マルチメディアコンテンツパラメータのあらかじめ決定されたセット（たとえば、コンテンツのフォーマット）を用いてグループセッションを開始することを選択し得る。代わりに、マルチメディアコンテンツパラメータのあらかじめ決定されたセットは、（上記のステップ７６２および７６７において説明した）デバイスまたはサービス発見段階中にシンク７１０から取得され得る。

[00103]（たとえば、１つの継続する図として解釈される図８Ａおよび図８Ｂによって示される）図８に、Ｗｉ−ＦｉディスプレイソースデバイスといくつかのＷｉ−Ｆｉディスプレイシンクデバイスとの間の、ソース中心ＲＴＳＰベースグループセッション確立および能力ネゴシエーション方法の別の例示的な実装形態を示す。図示の例では、シンクデバイスのすべてが同じグループ中にあると仮定される。この方法は、図６および図７のＴＣＰベース方法と比較して、（たとえば、信頼性を維持するために）フィードバックのための複数再試行機能および機会を使用し得る、より効率的にＷｉ−Ｆｉディスプレイグループセッションを確立するためのＵＤＰベース「ＲＴＳＰＵ」方式である。

[00104]ステップ８６１において、Ｗｉ−Ｆｉディスプレイソース８００は、Ｗｉ−Ｆｉディスプレイシンク８１０のうちの少なくとも１つとともに（この例では、シンク８１０Ａとともに）発見段階を開始する。発見段階中に交換される発見情報は、図５に関して上記で説明したように、グループセッション管理情報を含み得る。一実装形態では、ソース８００は、それが下記のいくつかの能力交換ステップ（たとえば、ステップ８６９、８７０、および／または８７１）をスキップし得るようにマルチメディアフォーマットおよびパラメータのセットをあらかじめ決定するために、発見情報を使用し得る。発見段階は、チャネル上のトラフィックの量に基づいて、選定されたチャネル（たとえば、チャネル１、６、または１１）上で行われ得る。さらに、発見情報は、プローブ要求およびプローブ応答フレームを介してソース８００とシンク８１０との間で交換され得る。

[00105]ステップ８６２において、シンク８１０のうちの１つまたは複数は、サービス発見情報をもソース８００と交換し得る。一実装形態では、ソース８００は、それが下記のいくつかの能力交換ステップ（たとえば、ステップ８６９、８７０、および／または８７１）をスキップし得るようにマルチメディアフォーマットおよびパラメータのセットをあらかじめ決定するために、サービス発見情報を使用し得る。

[00106]ステップ８６３において、ソース８００は、ステップ８６１およびステップ８６２が行われたことをユーザ８５０に示し、いずれの１つまたは複数のシンク８１０が発見段階中に選択されたかをユーザ８５０に通知し得る（この例では、シンク８１０Ａが選択された）。

[00107]ステップ８６４において、ソース８００は、発見段階中に選択された１つまたは複数のシンク８１０との接続セットアップを完了し得る。場合によっては、接続セットアップはＷｉ−Ｆｉピアツーピアリンクであり得る。

[00108]ステップ８６５において、ソース８００は、追加のシンク８１０とともに（この例では、シンク８１０Ｂおよび８１０Ｃとともに）、継続する発見段階を開始し得る。発見段階中に交換される発見情報は、グループセッション管理およびデバイス能力情報を含み得る。継続する発見段階中の情報の交換は、１つのシンクずつ行われ得、たとえば、ソース８００は、発見情報をシンク８１０Ｂと交換し、次いで、発見情報をシンク８１０Ｃと交換し得る。一実装形態では、ソース８００は、それが下記のいくつかの能力交換ステップ（たとえば、ステップ８６９、８７０、および／または８７１）をスキップし得るようにマルチメディアフォーマットおよびパラメータのセットをあらかじめ決定するために、発見情報を使用し得る。

[00109]ステップ８６６において、追加のシンク８１０のうちの１つまたは複数（ここでは、８１０Ｂおよび８１０Ｃ）は、ソース８００からのサービス発見情報をも交換し得る。一実装形態では、ソース８００は、それが下記のいくつかの能力交換ステップ（たとえば、ステップ８６９、８７０、および／または８７１）をスキップし得るようにマルチメディアフォーマットおよびパラメータのセットをあらかじめ決定するために、サービス発見情報を使用し得る。

[00110]ステップ８６７において、ソース８００は、継続する発見段階中に選択された追加のシンク８１０との接続セットアップを完了し得る。場合によっては、接続セットアップはＷｉ−Ｆｉピアツーピアリンクであり得る。

[00111]ステップ８６８において、ソース８００は、ステップ８６５〜８６７が行われたことをユーザ８５０に示し、存在する、能力要件を満たすいくつかのシンク８１０（ここでは、シンク８１０Ａ、８１０Ｂ、および８１０Ｃ）が、発見段階中に選択されたことをユーザ８５０に通知し得る。一実装形態では、ソース８００が、能力交換をスキップするのに必要なマルチメディアフォーマットおよびパラメータのセットをあらかじめ決定した場合、ソース８００またはユーザ８５０は、この時点で、ステップ８６９、８７０、および８７１をスキップすることを選択し得る。

[00112]ステップ８６９において、上記のようにスキップされない限り、ソース８００は、それ自体と、ステップ８６１〜８６７において発見段階中に選択された１つまたは複数のシンク８１０との間で、能力情報についての要求を送り得る。能力情報は、特に、マルチメディアコーデック、マルチメディアフォーマット、最小レイテンシまたはバッファ能力、あるいはサポートされるマルチキャスト機構（たとえば、ＤＭＳまたはＧＣＲ）を含み得る。ソース８００は、能力情報を交換および設定するために、グループセッション管理情報とともに、ＲＴＳＰ ＧＥＴ＿ＰＡＲＡＭＥＴＥＲコマンドを使用し得る。一実装形態では、ソース８００は、図５に関して説明したように、シンク８１０からの応答のためのタイムアウトを指定し得る。ソース８００は、応答のためのタイムアウトを、予想されるネットワークラウンドトリップ時間に基づかせ得る（たとえば、ラウンドトリップ時間は、Ｗｉ−Ｆｉチャネルアクセスの場合、５０ｍｓ〜５００ｍｓであり得る）。ソース８００から送られた各ＵＤＰベースＲＴＳＰメッセージ要求は、少なくとも応答のためのタイムアウトに基づく、「応答時間制限」と、「再試行の回数」と、「次送信間隔」とを含み得る。ＵＤＰベースＲＴＳＰメッセージ要求の各々は、メッセージ信頼性および明瞭性を改善するために、一意のシーケンス番号（たとえば、ＣＳｅｑヘッダ）をも含み得る。

[00113]ステップ８７０および８７１において、上記のようにスキップされない限り、ソース８００は、ステップ８６９において１つまたは複数のシンク８１０から要求されたシンクパラメータ（たとえば、能力情報）を取り出し得る。この段階中の情報の交換は、１つのシンクずつ行われ得、たとえば、ソース８００は、（ステップ８７０の場合のように）能力情報をシンク８１０Ａと交換し、次いで、（ステップ８７１の場合のように）能力情報をシンク８１０Ｂまたは８１０Ｃと交換し得る。

[00114]ステップ８７２において、ソース８００は、グループセッションを確立する準備ができていることがある。グループセッションのそれの確立において、ソース８００は、上記のステップにおいて選択された１つまたは複数のシンクとの間での能力情報交換に基づいて、グループセッションのための最適パラメータを決定し得る。ソース８００は、この時点でグループセッションＩＤをも生成し得る。

[00115]ステップ８７３において、ソース８００は告知段階に入り得、その間、それは、接続されたシンク８１０（たとえば、ここでは、シンク８１０Ａ、８１０Ｂ、および８１０Ｃ）にＲＴＳＰグループセッション情報の告知を送り得る。ソース８００は、告知を送るためにＲＴＳＰ ＡＮＮＯＵＮＣＥコマンドを使用し得る。告知は、特に、マルチキャストプレゼンテーションＵＲＬと、コーデックパラメータと、グループＩＰアドレスと、ＲＴＰポート番号と、グループセッション中のシンクのすべてのための共通セッションＩＤとに関する情報を含み得る。告知段階中に、ソース８００はＷＦＤ−ＴＲＩＧＧＥＲ−ＭＥＴＨＯＤ＝ＷＡＩＴコマンドの下で動作し得、その間、それは、マルチメディアコンテンツを再生することを待つことになる。告知はまた、ステップ８６９において確立された場合、応答タイムアウトおよび再試行カウントパラメータに従い得る。そうである場合、ソース８００は、次のメッセージを送信することに進む前に、１つまたは複数のシンクからの応答のためのあらかじめ決定された待機時間の間、「待機のみ」を設定し得る。さらに、ＵＤＰ上でのマルチキャストがプロトコル処理負荷を低減し得るので、告知中のＲＴＳＰマルチキャストプレゼンテーションＵＲＬは、フォーマット「ｒｔｓｐｕ：／／＜ｈｏｓｔ［“：”ｐｏｒｔ］［ｐａｔｈ］」を有し得る。以下でさらに説明するように、ソース８００は、新しいシンクにグループセッションに加入するように要請するために告知を送信し続け得る。告知は、あらかじめ決定された時間間隔において周期的に繰り返され得る。繰り返される告知は、ステップ８８２においてさらに説明するように、マルチメディアストリーミングが（ステップ８８０において）開始した後でも行われ得る。

[00116]ステップ８７４において、シンク８１０（ここでは、シンク８１０Ａ）は、それがステップ８７３の告知を受信したことを示すＲＴＳＰ ＯＫメッセージをソース８００に送り得る。

[00117]ステップ８７５において、追加のシンク８１０（ここでは、シンク８１０Ｃ）は、それらがステップ８７３の告知を受信したことを示すＲＴＳＰ ＯＫメッセージをソース８００に送り得る。いくつかの実装形態では、このステップは、上記で説明したタイムアウトおよび再試行によりスキップされ得る。

[00118]ステップ８７６において、ステップ８７３に関して上記で説明したように、ソース８００は、新しいシンクにグループセッションに加入するように要請するために告知を送信し続け得る。告知は、あらかじめ決定された時間間隔において周期的に繰り返され得る。繰り返される告知は、ステップ８８２においてさらに説明するように、マルチメディアストリーミングが（ステップ８８０において）開始した後でも行われ得る。いくつかの実装形態では、本方法においてこの段階で送られる告知は、ＵＤＰ上でのユニキャストを介して送られ得る。この告知段階中に、ソース８００はＷＦＤ−ＴＲＩＧＧＥＲ−ＭＥＴＨＯＤ＝ＰＬＡＹコマンドの下で動作し得、その間、ソース８００は、接続されたシンク８１０（ここでは、シンク８１０Ａ、８１０Ｂ、および８１０Ｃ）に対してマルチメディアコンテンツを再生する準備ができていることがある。

[00119]ステップ８７７において、いずれかの追加のシンク８１０（ここでは、シンク８１０Ｂ）は、それらがステップ８７６の告知を受信したことを示すＲＴＳＰ ＯＫメッセージをソース８００に送り得る。

[00120]ステップ８７８において、接続されたシンク８１０のうちの１つまたは複数は、ＲＴＳＰプレゼンテーションＵＲＬを介してソース８００に再生要求（たとえば、ＲＴＳＰ ＰＬＡＹ要求）を送り得る。再生要求は、グループセッションＩＤに従って送られ得る。

[00121]ステップ８７９において、ステップ８７９の再生要求に応答して、ソース８００は、たとえば、「ＰＬＡＹ応答ＯＫ」メッセージを介して、再生が始まることを要求元シンク８１０に通知し得る。

[00122]ステップ８８０において、ソース８００は、要求元シンク８１０にグループセッション上でマルチメディアコンテンツをストリーミングすることを開始し得る。この時間中に、ソース８００は「ＰＬＡＹＩＮＧ」のステータスを示し得る。

[00123]ステップ８８１において、要求元シンク８１０は、ソース８００からストリーミングマルチメディアコンテンツを受信し得る。

[00124]ステップ８８２において、ステップ８７３に関して上記で説明したように、ソース８００は、新しいシンクにグループセッションに加入するように要請するために告知を送信し続け得る。告知は、あらかじめ決定された時間間隔において周期的に繰り返され得る。いくつかの実装形態では、本方法においてこの段階で送られる告知は、マルチキャストプレゼンテーションＵＲＬを介して送られ得る。告知段階中に、ソース８００はＷＦＤ−ＴＲＩＧＧＥＲ−ＭＥＴＨＯＤ＝ＷＡＩＴコマンドの下で動作し得、その後、受信シンクデバイスは、任意の時間にコンテンツを受信する準備ができていることがある。

[00125]（たとえば、１つの継続する図として解釈される図９Ａおよび図９Ｂによって示される）図９に、Ｗｉ−ＦｉディスプレイソースデバイスといくつかのＷｉ−Ｆｉディスプレイシンクデバイスとの間の、ソース中心ＲＴＳＰベースグループセッション確立および能力ネゴシエーション方法の別の例示的な実装形態を示す。図示の例では、シンクデバイスのすべてが同じグループ中にあると仮定される。この方法は、図６および図７のＴＣＰベースのみの方法と比較して、ならびに図８のＵＤＰベースのみの方法と比較して、ＴＣＰベースＲＴＳＰメッセージング方式とＵＤＰベースＲＴＳＰＵメッセージング方式の両方のハイブリッドを利用する。（ステップ９７３、９７５、および９７９に関して）以下でさらに説明するように、ソースは、限られた数の「アクティブ」シンクデバイスへのＴＣＰベースＲＴＳＰ接続を維持する。ソースはまた、グループに加入する資格がある任意の他の「パッシブ」シンクデバイスにグループセッションを広告するためのＵＤＰベースＲＴＳＰメッセージング方式を確立する。

[00126]ステップ９６１において、Ｗｉ−Ｆｉディスプレイソース９００は、Ｗｉ−Ｆｉディスプレイシンク９１０のうちの少なくとも１つとともに（この例では、シンク９１０Ａとともに）発見段階を開始する。発見段階中に交換される発見情報は、図５に関して上記で説明したように、グループセッション管理およびデバイス能力情報を含み得る。発見段階は、チャネル上のトラフィックの量に基づいて、選定されたチャネル（たとえば、チャネル１、６、または１１）上で行われ得る。さらに、発見情報は、プローブ要求およびプローブ応答フレームを介してソース９００とシンク９１０との間で交換され得る。

[00127]ステップ９６２において、シンク９１０のうちの１つまたは複数は、サービス発見情報をもソース９００と交換し得る。

[00128]ステップ９６３において、ソース９００は、ステップ９６１およびステップ９６２が行われたことをユーザ９５０に示し、いずれの１つまたは複数のシンク９１０が発見段階中に発見されたかをユーザ９５０に通知し得る（この例では、シンク９１０Ａが選択された）。

[00129]ステップ９６４において、ソース９００は、発見段階中に選択された１つまたは複数のシンク９１０との接続セットアップを完了し得る。場合によっては、接続セットアップはＷｉ−Ｆｉピアツーピアリンクであり得る。

[00130]ステップ９６５において、ソース９００は、それ自体と、発見段階中に選択された１つまたは複数のシンク９１０との間で能力情報を交換し得る。そのような能力情報は、特に、マルチメディアコーデック、マルチメディアフォーマット、最小レイテンシまたはバッファ能力、あるいはサポートされるマルチキャスト機構（たとえば、ＤＭＳまたはＧＣＲ）を含み得る。ソース９００は、能力情報を交換および設定するために、グループセッション管理情報とともに、ＲＴＳＰ ＯＰＴＩＯＮＳおよびＧＥＴ＿ＰＡＲＡＭＥＴＥＲコマンドを使用し得る。

[00131]ステップ９６６において、ソース９００は、追加のシンク９１０とともに（この例では、シンク９１０Ｂとともに）、継続する発見段階を開始し得る。発見段階中に交換される発見情報は、グループセッション管理およびデバイス能力情報を含み得る。

[00132]ステップ９６７において、接続されたシンク９１０のうちの１つまたは複数（ここでは、９１０Ａおよび９１０Ｂ）は、ソース９００からのサービス発見情報をも交換し得る。

[00133]ステップ９６８において、ソース９００は、ステップ９６５〜９６７が行われたことをユーザ９５０に示し、存在する、能力要件を満たすいくつかのシンク９１０（ここでは、シンク９１０Ａおよび９１０Ｂ）が、発見段階中に選択されたことをユーザ９５０に通知し得る。

[00134]ステップ９６９において、ソース９００は、再び、それ自体と、継続する発見段階中に選択された追加のシンク９１０（ここでは、シンク９１０Ｂ）との間で能力情報を交換し得る。そのような能力情報は、特に、マルチメディアコーデック、マルチメディアフォーマット、最小レイテンシまたはバッファ能力、あるいはサポートされるマルチキャスト機構（たとえば、ＤＭＳまたはＧＣＲ）を含み得る。ソース９００は、能力情報を交換および設定するために、グループセッション管理情報とともに、ＲＴＳＰ ＯＰＴＩＯＮＳおよびＧＥＴ＿ＰＡＲＡＭＥＴＥＲコマンドを使用し得る。

[00135]ステップ９７０および９７１において、ソース９００は、追加のシンク９１０とともに（この例では、シンク９１０Ｃおよび９１０Ｄとともに）、第２の継続する発見段階を開始し得る。発見段階中に交換される発見情報は、グループセッション管理およびデバイス能力情報を含み得る。継続する発見段階中の情報の交換は、１つのシンクずつ行われ得、たとえば、ソース９００は、（ステップ９７０の場合のように）発見情報をシンク９１０Ｃと交換し、次いで、（ステップ９７１の場合のように）発見情報をシンク９１０Ｄと交換し得る。

[00136]ステップ９７２において、ソース９００は、グループセッションを確立する準備ができていることがある。グループセッションのそれの確立において、ソース９００は、上記のステップにおいて選択された１つまたは複数のシンクとの間での能力情報交換に基づいて、グループセッションのための最適パラメータを決定し得る。ソース９００は、この時点でグループセッションＩＤをも生成し得る。さらに、ソース９００は、「パッシブ」シンクデバイス（ここでは、シンク９１０Ｃおよび９１０Ｄ）がグループに加入し得るように、ＵＤＰベースマルチキャストポートを介してそれのグループセッションＩＤを広告し得る。アクティブおよびパッシブシンクの数は、あらかじめ決定されるか、またはソース９００の計算に基づき得る。一実施形態では、アクティブシンクデバイスがより多くのソース９００コンピューティングリソースを必要とするので、アクティブシンクデバイスの数は、パッシブシンクデバイスの数よりも小さくなることになる。上記で説明したように、ソース９００は、ソース９００が限られた数のアクティブシンクデバイス（ここでは、シンク９１０Ａおよび９１０Ｂ）上での信頼できるＲＴＳＰ制御を維持し得るように、限られた数のアクティブシンクデバイスへのＴＣＰベースＲＴＳＰ接続を維持し得る。

[00137]ステップ９７３および９７５において、ソース９００はユニキャスト告知段階に入り得、その間、それは、アクティブシンク９１０（ここでは、シンク９１０Ａおよび９１０Ｂ）にＲＴＳＰグループセッション情報の告知を送り得る。ソース９００は、アクティブシンクに告知を送るためにＲＴＳＰ ＡＮＮＯＵＮＣＥコマンドを使用し得る。告知は、特に、プレゼンテーションＵＲＬと、コーデックパラメータと、グループＩＰアドレスと、ＲＴＰポート番号と、グループセッション中の個々のアクティブシンクのためのセッションＩＤとに関する情報を含み得る。いくつかの実装形態では、ソース９００は、アクティブシンク１つずつに告知を送り得る。たとえば、ステップ９７３の場合のように、ソース９００はアクティブシンク９１０Ａに告知を送り得、この時間中に、ソース９００はＷＦＤ−ＴＲＩＧＧＥＲ−ＭＥＴＨＯＤ＝ＷＡＩＴコマンドの下で動作し得、その間、それは、マルチメディアコンテンツを再生することを待つことになる。後に、ステップ９７５の場合のように、ソース９００はアクティブシンク９１０Ｂに告知を送り得、この時間中に、ソース９００はＷＦＤ−ＴＲＩＧＧＥＲ−ＭＥＴＨＯＤ＝ＰＬＡＹコマンドの下で動作し得、その間、ソース９００は、アクティブシンク９１０に対してマルチメディアコンテンツを再生する準備ができていることがある。告知はまた、図８ステップ８６９に関して上記で説明したように、応答タイムアウトおよび再試行カウントパラメータに従い得る。

[00138]ステップ９７４および９７６において、それぞれ、ステップ９７３または９７５の告知を受信したアクティブシンク９１０（ここでは、それぞれ、シンク９１０Ａおよび９１０Ｂ）は、それらが、それぞれ、ステップ９７３および９７５の告知を受信したことを示すＲＴＳＰ ＯＫメッセージをソース９００に送り得る。

[00139]ステップ９７７において、アクティブシンク９１０のうちの１つまたは複数は、ＲＴＳＰプレゼンテーションＵＲＬを介してソース９００に再生要求（たとえば、ＲＴＳＰ ＰＬＡＹ要求）を送り得る。再生要求は、グループセッションＩＤに従って送られ得る。

[00140]ステップ９７８において、ステップ９７７の再生要求に応答して、ソース９００は、たとえば、「ＰＬＡＹ応答ＯＫ」メッセージを介して、再生が始まることを要求元アクティブシンク９１０に通知し得る。

[00141]ステップ９７９において、ステップ９７２、９７３、および９７５に関して上記で説明したように、ソース９００は、新しいパッシブシンクにグループセッションに加入するように要請するためにＵＤＰベースＲＴＳＰＵマルチキャスト告知を送信し続け得る。この告知段階中に、ソース９００はＷＦＤ−ＴＲＩＧＧＥＲ−ＭＥＴＨＯＤ＝ＲＥＡＤＹコマンドの下で動作し得、その間、ソース９００は、グループに加入し得る任意のパッシブシンク９１０（ここでは、シンク９１０Ｃおよび９１０Ｄ）に対してマルチメディアコンテンツを再生する準備ができていることがある。一実装形態では、ソース９００は、ＡＣＫ応答を、パッシブシンクのいずれかに要求しないまたはそれらのいずれかから受信しないことがある。たとえば、ソース９００はパッシブシンクデバイスを追跡しないことがある。代わりに、ソース９００は、パッシブシンクが情報を要請するか否かにかかわらず、ＵＤＰベース告知内で、マルチメディアコーデックパラメータおよび他の重要なグループセッションストリーミング変更のみを送り得る。一実装形態では、ＵＤＰベースＲＴＳＰＵマルチキャスト告知内で行われる能力交換およびセッション広告は、Ｗｉ−Ｆｉディスプレイアクションフレームまたはサービス発見プロシージャを使用することによってレイヤ２によって実行され得る。パッシブシンクデバイスがＷｉ−Ｆｉディスプレイサービス発見（ＷＦＤＳ）プロトコルをサポートする場合、それらは、ピアツーピア発見および接続が確立された後、ソース９００からグループセッション能力を取得するために、アプリケーションサービスプラットフォーム（ＡＳＰ）セッションを使用し得る。

[00142]ステップ９８０において、ソース９００は、任意の接続されたアクティブおよびパッシブシンク９１０（ここでは、シンク９１０Ａ、９１０Ｂ、９１０Ｃ、および９１０Ｄ）にグループセッション上でマルチメディアコンテンツをストリーミングすることを開始し得る。この時間中に、ソース９００は「ＰＬＡＹＩＮＧ」のステータスを示し得る。

[00143]ステップ９８１において、接続されたアクティブおよびパッシブシンク９１０は、ソース９００からストリーミングマルチメディアコンテンツを受信し得る。

[00144]（たとえば、１つの継続する図として解釈される図１０Ａおよび図１０Ｂによって示される）図１０に、Ｗｉ−Ｆｉディスプレイソースデバイスと、Ｗｉ−Ｆｉディスプレイマスタシンクデバイスと、いくつかの従属シンクデバイスとの間の、シンク中心ＲＴＳＰベースグループセッション管理方法の例示的な実装形態を示す。ソースが個々のシンクまたはシンクのグループとのグループセッションを開始した図６〜図９に反して、本方法では、１つの「マスタ」シンクが、ソースとのグループセッションを開始し、次いで、他の「従属」シンクをグループセッションに勧誘する。

[00145]ステップ１０６１において、Ｗｉ−Ｆｉディスプレイマスタシンク１０１０は、Ｗｉ−Ｆｉディスプレイソース１０００とともに発見段階を開始する。発見段階中に交換される発見情報は、図５に関して上記で説明したように、グループセッション管理情報およびデバイス能力情報を含み得る。発見段階は、チャネル上のトラフィックの量に基づいて、選定されたチャネル（たとえば、チャネル１、６、または１１）上で行われ得る。さらに、発見情報は、プローブ要求およびプローブ応答フレームを介してソース１０００とマスタシンク１０１０との間で交換され得る。

[00146]ステップ１０６２において、マスタシンク１０１０は、サービス発見情報をもソース１０００と交換し得る。

[00147]ステップ１０６３において、ソース１０００は、ステップ１０６１および１０６２が行われたことをユーザ１０５０に示し、マスタシンク１０１０が接続されたことをユーザ１０５０に通知し得る。

[00148]ステップ１０６４において、ソース１０００およびマスタシンク１０１０は接続セットアップを完了し得る。場合によっては、接続セットアップはＷｉ−Ｆｉピアツーピアリンクであり得る。

[00149]ステップ１０６５において、ソース１０００およびマスタシンク１０１０は、ＴＣＰベースＲＴＳＰメッセージ交換を使用して能力情報を交換し得る。そのような能力情報は、特に、マルチメディアコーデック、マルチメディアフォーマット、最小レイテンシまたはバッファ能力、あるいはサポートされるマルチキャスト機構（たとえば、ＤＭＳまたはＧＣＲ）を含み得る。ソース１０００は、能力情報を交換および設定するために、グループセッション管理情報とともに、ＲＴＳＰ ＯＰＴＩＯＮＳおよびＧＥＴ＿ＰＡＲＡＭＥＴＥＲコマンドを使用し得る。一実装形態では、ソース１０００は、それがシンクデバイスのグループを「シンク中心」グループとしてサービスすることを意図することをマスタシンク１０１０に通知し得る。この場合、同じく能力交換段階中に、マスタシンク１０１０は、応答し、マスタシンク（または「制御シンク」）の役割を呈し得る。

[00150]ステップ１０６６において、ソース１０００は、ユニキャストＲＴＳＰ告知またはパラメータ要求をマスタシンク１０１０に送り得る。ソース１０００は、告知を送るためにＲＴＳＰ ＡＮＮＯＵＮＣＥコマンドを使用するか、またはパラメータ要求を送るためにＳＥＴ＿ＰＡＲＡＭＥＴＥＲコマンドを使用し得る。告知は、特に、プレゼンテーションＵＲＬと、コーデックパラメータと、グループＩＰアドレスと、ＲＴＰポート番号と、マスタシンクのためのセッションＩＤとに関する情報を含み得る。この時間中に、ソース１０００はＷＦＤ−ＴＲＩＧＧＥＲ−ＭＥＴＨＯＤ＝ＷＡＩＴコマンドの下で動作し得、その間、それは、マルチメディアコンテンツを再生することを待つことになる。いくつかの実装形態では、グループセッションにおける多数のシンクデバイスのサポートが必要とされるとき、ソース１０００は、たとえば、ＡＮＮＯＵＮＣＥ方法を使用して、グループセッションストリーミング制御を管理するためのＵＤＰ上でのＲＴＳＰＵ方式（ＩＥＴＦ ＲＦＣ２３２６）を使用し得る。

[00151]ステップ１０６７において、ソース１０００およびマスタシンク１０１０は、マスタシンク１０１０が、グループセットアップのための要求をソース１０００に送り、次いで、ステップ１０６８に進むとき、通信を一時的に停止（たとえば、一時停止）し得る。

[00152]ステップ１０６８および１０６９において、マスタシンク１０１０は、従属シンク１０２０とともに（この例では、従属シンク１０２０Ａおよび従属シンク１０２０Ｂとともに）、継続する発見段階を開始し得る。発見段階中に交換される発見情報は、グループセッション管理情報とデバイス能力情報とを含み得る。マスタシンク１０１０は、ピアツーピアまたはサービス発見を介して従属シンク１０２０にグループ勧誘メッセージを送り得る。グループ勧誘メッセージは、現在のＷｉ−Ｆｉディスプレイグループセッションにおけるマルチメディアストリーミングのために使用されるマルチメディアフォーマットを含み得る。グループ勧誘メッセージは、シンクデバイスがソース１０００から受信し得るＲＴＰ／ＵＤＰパケットのためのＩＰアドレスおよびポート番号をも含み得る。継続する発見段階中の情報の交換は、１つのシンクずつ行われ得、たとえば、マスタシンク１０１０は、（ステップ１０６８の場合のように）発見情報を従属シンク１０２０Ａと交換し、次いで、（ステップ１０６９の場合のように）発見情報を従属シンク１０２０Ｂと交換し得る。この時間中に、マスタシンク１０１０はまた、従属シンクのグループに結合することを確立し、および／またはそれらに関する情報を集め得る。いくつかの実装形態では、グループセッションにおける多数のシンクデバイスのサポートが必要とされるとき、マスタシンク１０１０は、たとえば、ＡＮＮＯＵＮＣＥ方法を使用して、グループセッションストリーミング制御を管理するためのＵＤＰ上でのＲＴＳＰＵ方式（ＩＥＴＦ ＲＦＣ２３２６）を使用し得る。

[00153]ステップ１０７０および１０７１において、マスタシンク１０１０は、従属シンク１０２０（ここでは、従属シンク１０２０Ａおよび１０２０Ｂ）にＲＴＳＰ告知を送り得る。告知は、従属シンク１０２０に対する、グループセッションに加入するかまたは要求／応答プロセスに加入するようにとの勧誘を含み得る。告知は従属シンク１つずつに送られ得、たとえば、マスタシンク１０１０は、（ステップ１０７０の場合のように）従属シンク１０２０Ａに告知を送り、次いで、（ステップ１０７１の場合のように）従属シンク１０２０Ｂに告知を送り得る。

[00154]ステップ１０７２において、ソース１０００は、ステップ１０６４〜１０７１が行われたことをユーザ１０５０に示し、ユーザ１０５０がグループセッションのためのデバイス選択を行うことを可能にし得る。

[00155]ステップ１０７３において、マスタシンク１０１０は、ＲＴＳＰプレゼンテーションＵＲＬを介してソース７００にＲＴＳＰセットアップ要求を送り得る。ＲＴＳＰセットアップ要求は、グループセッションメンバーシップ情報、たとえば、従属シンクの数と識別情報とを含み得る。

[00156]ステップ１０７４において、ソース１０００は、それが、ステップ１０７３の要求を受信および承認したことを示すＲＴＳＰ ＯＫメッセージをマスタシンク１０１０に送り得る。

[00157]ステップ１０７５において、ソース１０００は、グループセッションを確立する準備ができていることがある。グループセッションのそれの確立において、ソース１０００は、グループセッションのための最適パラメータを決定し得る。ソース１０００は、この時点でグループセッションＩＤをも生成し得る。さらに、ソース１０００は、パッシブシンクデバイス（ここでは、従属シンク１０２０Ａおよび１０２０Ｂ）がグループに加入し得るように、ＵＤＰベースマルチキャストポートを介してそれのグループセッションＩＤを広告し得る。このプロセスについて、図９に関してさらに説明する。

[00158]ステップ１０７６において、ソース１０００はユニキャスト告知段階に入り得、その間、それは、マスタシンク１０１０にＲＴＳＰグループセッション情報の告知を送り得る。ソース１０００は、マスタシンク１０１０に告知を送るためにＲＴＳＰ ＡＮＮＯＵＮＣＥコマンドを使用し得る。この時間中に、ソース１０００はＷＦＤ−ＴＲＩＧＧＥＲ−ＭＥＴＨＯＤ＝ＰＬＡＹコマンドの下で動作し得、その間、ソース１０００は、マスタシンク１０１０に対してマルチメディアコンテンツを再生する準備ができていることがある。いくつかの実装形態では、グループセッションにおける多数のシンクデバイスのサポートが必要とされるとき、ソース１０００は、たとえば、ＡＮＮＯＵＮＣＥ方法を使用して、グループセッションストリーミング制御を管理するためのＵＤＰ上でのＲＴＳＰＵ方式（ＩＥＴＦ ＲＦＣ２３２６）を使用し得る。

[00159]ステップ１０７７において、マスタシンク１０１０は、それがステップ１０７６の告知を受信したことを示すＲＴＳＰ ＯＫメッセージをソース１０００に送り得る。

[00160]ステップ１０７８において、マスタシンク１０１０は、ＲＴＳＰプレゼンテーションＵＲＬを介してソース１０００に再生要求（たとえば、ＲＴＳＰ ＰＬＡＹ要求）を送り得る。再生要求は、グループセッションＩＤに従って送られ得る。

[00161]ステップ１０７９において、ステップ１０７８の再生要求に応答して、ソース１０００は、たとえば、「ＰＬＡＹ応答ＯＫ」メッセージを介して、再生が始まることをマスタシンク１０１０に通知し得る。

[00162]ステップ１０８０において、ソース１０００は、新しいパッシブシンク（たとえば、従属シンク１０２０Ａおよび１０２０Ｂ）にグループセッションに加入するように要請するために、（ステップ１０７５に記載されているように）ＵＤＰベースＲＴＳＰＵマルチキャスト告知を送信し続け得る。この時間中に、ソース１０００はＷＦＤ−ＴＲＩＧＧＥＲ−ＭＥＴＨＯＤ＝ＰＬＡＹコマンドの下で動作し得、その間、ソース１０００は、グループに加入し得る任意のパッシブシンク１０１０（ここでは、シンク１０２０Ａおよび１０２０Ｂ）に対してマルチメディアコンテンツを再生する準備ができていることがある。告知は、特に、マルチキャストプレゼンテーションＵＲＬと、コーデックパラメータと、グループＩＰアドレスと、ＲＴＰポート番号と、グループセッション中のシンクのすべてのための共通セッションＩＤとに関する情報を含み得る。告知はまた、図８に関して説明したように、応答タイムアウトおよび再試行カウントパラメータに従い得る。いくつかの実装形態では、グループセッションにおける多数のシンクデバイスのサポートが必要とされるとき、ソース１０００は、たとえば、ＡＮＮＯＵＮＣＥ方法を使用して、グループセッションストリーミング制御を管理するためのＵＤＰ上でのＲＴＳＰＵ方式（ＩＥＴＦ ＲＦＣ２３２６）を使用し得る。

[00163]ステップ１０８０の告知に続いて、他のシンクデバイスは、この時間の後、グループに加入したいとの要求をマスタシンク１０１０に送り得る。要求元シンクデバイスが、（グループセッションによって決定された）必要とされるパラメータを満たす場合、マスタシンク１０１０は、要求元シンクデバイスに肯定応答を送り、グループに加入するようにとの勧誘を要求元シンクデバイスに送り得る。要求元シンクデバイスが勧誘を受け入れた場合、それはソース１０００にシンク情報を送り得る。ソース１０００は、次いで、グループセッションパラメータ情報を更新し、マルチキャストＵＤＰベースポートにマルチメディアコンテンツをストリーミングすることを開始し得る。ソース１０００はまた、ユーザのグループのための他のＭＡＣレイヤデータ配信にマルチメディアコンテンツをストリーミングすることを開始し得る。いくつかの実装形態では、ソース１０００は、マルチキャストデータ配信が、マルチキャストトラフィック、たとえば、８０２．１１ＤＭＳまたはＧＣＲプロシージャのためにＭＡＣレイヤによって必要とされるとき、グループオーナーになるというそれの意図を広告し得る。

[00164]ステップ１０８１および１０８２において、ステップ１０８０の告知を受信した従属シンク１０２０（ここでは、それぞれ、シンク１０１０Ａおよび１０１０Ｂ）は、それらが、告知を受信したことを示すＲＴＳＰ ＯＫメッセージをソース１０００に送り得る。ＲＴＳＰ ＯＫメッセージは従属シンク１つずつから受信され得、たとえば、（ステップ１０８１の場合のように）従属シンク１０２０Ａがソース１０００にＲＴＳＰ ＯＫメッセージを送り、次いで、（ステップ１０８２の場合のように）従属シンク１０２０Ｂがソース１０００にＲＴＳＰ ＯＫメッセージを送り得る。

[00165]ステップ１０８３において、ソース１０００は、マスタシンク１０１０および任意の接続された従属シンク１０１０（ここでは、従属シンク１０２０Ａおよび１０２０Ｂ）にグループセッション上でマルチメディアコンテンツをストリーミングすることを開始し得る。この時間中に、ソース１０００は「ＰＬＡＹＩＮＧ」のステータスを示し得る。

[00166]ステップ１０８４において、接続されたシンクは、ソース１０００からストリーミングマルチメディアコンテンツを受信し得る。マスタシンク１０１０は、ストリーミング制御機能、たとえば、再生、一時停止、または他のユーザ入力を管理し得る。ユーザ１０５０によるこの制御を可能にするために、マスタシンク１０１０は、それのＴＣＰ接続上でのユーザ入力バックチャネル（ＵＩＢＣ）能力を有し得る。

[00167]（たとえば、１つの継続する図として解釈される図１１Ａおよび図１１Ｂによって示される）図１１に、Ｗｉ−Ｆｉディスプレイグループセッション管理情報のための例示的なサブエレメントコンテンツレイアウトを示す。サブエレメントは、ソースまたはシンクが、デバイス発見のために（図４〜図１０に関して説明したグループセッションなど）グループセッション情報を広告する（たとえば、いくつかのシンクデバイスを発見する）という目的で、Ｗｉ−Ｆｉディスプレイ情報要素内に含まれ得る。サブエレメントは、デバイスがデバイス発見中に交換すべきである最小量の情報を含み得る。

[00168]プロセスに参加するデバイスは、図４〜図１０に関して説明したようなピアツーピアＷｉ−Ｆｉディスプレイグループサービスデバイス、たとえば、グループセッション対応ソース、グループセッション対応マスタシンクおよび他のシンクデバイスを含み得る。デバイスのうちの１つまたは複数は、以下で行１１４０、１１６０および、１１８０に関してより十分に説明するように、特に、グループセッションのための能力、グループセッションのタイプ、グループセッション管理ポート情報、および（もしあれば）マルチキャストパケットの配信のためのＭＡＣレイヤによるグループアドレス指定フレームのためのサポートを示し得る、図示されたサブエレメントを含み得る。ソースが一度に２つ以上のグループセッションを有する場合、ソースは、各グループについて１つの複数グループセッション管理情報サブエレメントを含み得る。

[00169]一実装形態では、ソースまたはシンクデバイスは、Ｗｉ−Ｆｉ Ｄｉｒｅｃｔサービス規格からのサービス発見プロシージャをサポートし得、サブエレメント情報は、（たとえば、ディスプレイＳｅｅｋＳｅｒｖｉｃｅのためのｓｅｒｖｉｃｅ＿ｉｎｆｏｒｍａｔｉｏｎ＿ｒｅｑｕｅｓｔ中に含まれる）サービス発見のためのディスプレイ能力パラメータとして含まれ得る。図１１中のテーブルに、この実装形態の一例を示す。

[00170]例示的なサブエレメントはいくつかのフィールドを含み得る。フィールド列１１００は例示的なフィールドをリストする。いくつかのフィールドは、サイズ列１１０２にリストされている、示唆されたオクテットサイズを有し得る。フィールドが示唆された値を有する場合、それは値列１１０４にリストされている。説明列１１０６は、以下でさらに詳細に説明する、各フィールドの概要を与える。

[00171]行１１１０に示されているように、サブエレメントは、１オクテットサイズおよびあらかじめ決定された値をもつ「サブエレメントＩＤ」フィールドを含み得る。サブエレメントＩＤフィールドは、Ｗｉ−Ｆｉディスプレイサブエレメントの対応するタイプを識別し得る。

[00172]行１１２０に示されているように、サブエレメントはまた、２オクテットサイズおよび値「６」をもつ「長さ」フィールドを含み得る。長さフィールドは、サブエレメント中の後続のフィールドの長さを示し得る。

[00173]行１１３０に示されているように、サブエレメントはまた、４オクテットサイズをもつ「ＷＦＤグループセッション識別子」フィールドを含み得る。ＷＦＤグループセッション識別子フィールドは、グループＷｉ−ＦｉディスプレイセッションのためのＲＴＳＰセッション確立中にソースデバイス（たとえば、図４〜図１０に関して説明したソース）によって割り当てられた一意のグループセッション識別子を含み得る。グループセッションがまだ開始していない場合、ＷＦＤグループセッション識別子フィールドはすべて０の値を有し得る。

[00174]行１１４０に示されているように、サブエレメントはまた、１オクテットサイズをもつ「ＷＦＤグループセッションタイプ」フィールドを含み得る。ＷＦＤグループセッションタイプフィールドは、グループセッションのタイプを指定するビットマップを含み得る。場合によっては、グループセッションは、図４〜図９に関して説明したように、ソース中心タイプであり得る。他の場合には、グループセッションは、図１０に関して説明したように、マスタシンク中心タイプであり得る。グループセッションは他のタイプでもあり得る。グループセッションのタイプは、ビットマップの最初の４ビットにおいて示され得る。ビットマップはまた、グループセッションを管理するＲＴＳＰプロトコルポートのタイプ、たとえば、（すべて図４〜図１０に関して説明したＴＣＰポート、ＵＤＰポート、またはハイブリッドを示し得る。ＲＴＳＰプロトコルポートのタイプは、ビットマップの最後の４ビットにおいて示され得る。

[00175]行１１５０に示されているように、サブエレメントはまた、２オクテットサイズをもつ「グループセッション管理制御ポート情報」フィールドを含み得る。グループセッション管理制御ポート情報フィールドは、Ｗｉ−ＦｉディスプレイデバイスがグループセッションのためのＲＴＳＰメッセージをそこでリッスンし得るＴＣＰまたはＵＤＰポートを含み得る。グループセッション管理制御ポート情報の値は、任意の有効なＵＤＰまたはＴＣＰポート値であり得る。

[00176]行１１６０に示されているように、サブエレメントはまた、７オクテットサイズをもつ「サポート対象グループマルチキャスト方法（Supported Group Multicast Method）」フィールドを含み得る。サポート対象グループマルチキャスト方法フィールドは、ＭＡＣレイヤによるグループアドレス指定フレーム配信のサポートを示すビットマップを含み得る。設定され得るサポートシステムの例としては、ＤＭＳのみ、ブロックＡＣＫを用いるＧＣＲ（グループコード記録）、非要請再試行を用いるＧＣＲなどがある。ビットマップはまた、グループアドレス指定配信サポートが実装されないことを示し得る。グループアドレス指定フレーム配信サポートは、ビットマップの最初の８ビットにおいて示され得る。ビットマップが、ブロックＡＣＫを用いるＧＣＲまたは非要請再試行を用いるＧＣＲを設定する場合、サポート対象グループマルチキャスト方法フィールドの次の６バイトは、ＧＣＲグループアドレスを含み得る。ビットマップが、ブロックＡＣＫを用いるＧＣＲまたは非要請再試行を用いるＧＣＲ以外のサポートシステムを設定する場合、ＧＣＲグループアドレス情報サブフィールドは、予約済みのままにされ得る。

[00177]行１１７０に示されているように、サブエレメントはまた、「グループのための必須パラメータ（Mandatory Parameters for Group）」フィールドを含み得る。グループのための必須パラメータフィールドは、共通マルチメディアフォーマットの最小の必要なサポートに関する情報、レイテンシまたはバッファ能力情報、および／またはソースが１つまたは複数のシンクにマルチメディアコンテンツをストリーミングするのに必要な他のパラメータを含み得る。場合によっては、グループのための必須パラメータフィールドの値は随意であり得る。一実装形態では、ソースは、グループのための必須パラメータフィールドにおいて示される、最小レイテンシ、バッファ能力、および／またはトランスコーディングなしにストリーミングするためのコンテンツの共通マルチメディアフォーマットのサポートを必要とし得る。ソースが（たとえば、図８に関して説明した方法の一実装形態の場合のように）個々のシンク能力を要請しない場合、またはシンクデバイスがコンテンツのネイティブフォーマットをサポートしない場合、ソースまたはシンクは、グループセッション中にストリーミングのために使用されるべきである必須のマルチメディアフォーマットおよびパラメータ（たとえば、１２８０×７２０ｐ、２４ｆｐｓ解像度）にコンテンツを再符号化および／またはトランスコーディングし得る。

[00178]行１１８０に示されているように、サブエレメントは、グループメンバーのすべての和（たとえば、グループメンバーの数）を表す、７オクテットサイズをもつ「ＷＦＤグループメンバー情報記述子」フィールドをも含み得る。ＷＦＤグループメンバー情報記述子フィールドは、それの最初のオクテットにおいて各メンバーデバイスのタイプおよびステータスを示し得る。メンバーデバイスのタイプおよびステータスの例は、図４〜図１０に関して説明したような、マスタシンク、通常シンク、マルチキャスト対応、ユニキャストのみなどのタイプを含み得る。ＷＦＤグループメンバー情報記述子フィールドは、各デバイスのＭＡＣアドレスまたは他の一意の識別子をも含み得る。ＭＡＣアドレスまたは一意の識別子は、ＷＦＤグループメンバー情報記述子フィールドの最後の６オクテットに位置し得る。ＷＦＤグループメンバー情報記述子フィールドが単一のエントリ（たとえば、７バイト）を保持する場合、ＭＡＣアドレスフィールドはすべて０を含んでいることがあり、最初のオクテットはグループ中のアクティブなデバイスまたはメンバーの数のみを示し得る。一実装形態では、ソースおよび／またはマスタシンクは、グループに加入するために、最新のメンバーデバイスに関する情報に基づいてＷＦＤグループメンバー情報記述子フィールドを更新し得る。

[00179]いくつかの実装形態では、サブエレメントは追加のフィールドをも含み得る（図示せず）。追加のフィールドの例としては、デバイスカテゴリー（たとえば、グループセッション対応ソース、グループサービス対応マスタシンクなど）、または各デバイスのための好ましいモード（たとえば、ピアツーピアＧＯ、ソフトＡＰ、役割についての選好なしなど）に関する情報に関係するフィールドがあり得る。

[00180]図１２に、グループセッションのためのマルチメディアコンテンツを配信するためのデータプレーンスタックの一例を示す。一実施形態では、サポートされるべき各グループセッションについてコンテンツ処理を実行するために、データプレーンスタックの１つのインスタンスが必要であり得る。下記の方法を使用して、シンクデバイスのグループ（たとえば、図４〜図１０に関して説明したシンクデバイス）へのフレーム配信を処理するためのシステムＭＡＣレイヤ能力をデータプレーンスタックに通知すること（すなわち、ＲＴＳＰストリーミング制御プロトコルを使用することによって）が可能であり得る。図１２におけるデータプレーンスタック図は、いくつかのセッショングループと、グループＡコンテンツ１２００ＡおよびグループＫコンテンツ１２００Ｋなど、それらのコンテンツとを含む。各グループは、すべてが、同じ必要とされるマルチメディアフォーマットを受信すること、および／または最大レイテンシ要件を満たすことが可能であるシンクを含み得る。データプレーンスタックはまた、共通ＲＴＳＰ制御１２０５およびＴＣＰ／ＵＤＰ情報１２１０など、１つのグループに固有でないリソースおよび制御シグナリングを利用する。１つまたは複数のデータプレーンスタックはまた、ＩＰソケット１２１５ならびにＷｉ−Ｆｉピアツーピア／ＴＬＤＳおよびＷｉ−Ｆｉ保護セットアップ処理ユニット１２２０など、システムおよびすべてのグループにわたって共通構成要素を使用し得る。シンクグループの各々に専用のデータプレーンは、ビデオコーデック１２３０、オーディオコーデック１２３５、パケット化された基本システム（ＰＥＳ）情報１２４０、ＨＤＣＰ２．０／２．１情報１２４５、ＭＰＥＧ２−ＴＳ情報１２５０、ＲＴＰ情報１２５５、およびＵＤＰ情報１２６０など、個々の構成要素またはリソースを含み得る。データプレーンスタックは、１２２５のように、フレームをそれらのそれぞれのグループアドレスにスケジュールし得る。

[00181]シンクのグループ（たとえば、図１２中の上側に表示したグループ）内のメディアコンテンツ配信の場合、ＭＡＣレイヤ信頼性およびロバストなマルチメディアストリーミングを保証するために、８０２．１１ａａからのダイレクテッドマルチキャストサービス（ＤＭＳ）または再試行を用いるグループキャスト（ＧＣＲ）プロシージャが使用され得る。ＤＭＳまたはＧＣＲ配信方法のための厳密な再送信プロシージャは、特に、グループ中のソースおよびシンクの能力、グループ中のデバイスの数、チャネル状態、帯域幅要件などに依存し得る。これらのパラメータの様々な状態を鑑みて、マルチメディア配信方法のためのいくつかのオプションが使用され得る。ソースは、下記の例に基づいて、グループセッション配信方法が、ＤＭＳのみ、非要請ＧＣＲのみ、ブロックＡＣＫを用いるＧＣＲ、ＤＭＳとＧＣＲの両方、非ＧＣＲなどであることを告知し得る。

[00182]マルチメディア配信のための１つの例示的な方法は、ソースが、シンクデバイスとの初期セットアップのための１つのＭＰＥＧ２−ＴＳおよびＲＴＰ／ＵＤＰフローを用いて送信することを含み得る。その後、ソースは、マルチキャストＩＰパケットを使用し、ＤＭＳを使用するユニキャストＭＡＣフレームに変換し得る。この方法は、複数のユニキャストＭＡＣ送信の信頼性を提供する。

[00183]マルチメディア配信のための別の例示的な方法は、非要請再試行を用いるＧＣＲを含む。本方法では、ソースは、（図１１に関して説明した）Ｗｉ−Ｆｉディスプレイ情報要素中で、およびＲＴＳＰメッセージ中で広告され得る、ＧＣＲアドレスにデータフレームを送信し得る。ソースはまた、個々のデータフレームを、それらがシンクデバイスによって受信されることを保証するために、再送信し得る。ソースがフレームを再送信する場合、それはシンクデバイスにそれの再送信ポリシーを広告し得る。

[00184]マルチメディア配信のための別の例示的な方法は、ブロックＡＣＫを用いるＧＣＲを含む。本方法では、データフレームは、マルチキャストを介してＧＣＲアドレスに送られ得る。さらに、ソースは、ＭＡＣフレームのブロックの終わりにブロックＡＣＫ要求フレームを送り得る。シンクデバイスのグループは、次いで、タイムアウト期間内にブロックＡＣＫを返し得る。

[00185]マルチメディア配信方法のための上記の例示的な方法のいずれも（たとえば、ソースまたはシンクデバイスの限られた能力により）サポートされない場合、グループストリーミングは、非ＧＣＲマルチキャスト方法を使用し得る。非ＧＣＲマルチキャスト方法は、ＡＣＫ要求または再試行を含まないことがある。本方法では、ソースおよび／または多数のシンクデバイスは、いかなるグループアドレス指定フレーム配信をもサポートしないことがある。ソースはピアツーピアＧＯまたはソフトＡＰとして動作し得、ＵＤＰスタックからマルチキャストＩＰパケットを受信した後にデータフレームを送信するために通常マルチキャストを使用し得る。コンテンツビットストリームは、データプレーンスタックの１つのインスタンス（たとえば、コーデック、ＰＥＳ、ＨＤＣＰ、ＭＰＥＧ２−ＴＳ／ＲＴＰ／ＵＤＰなど）によって生成され得、ＭＡＣレイヤは、配信トラフィック指示メッセージ（ＤＴＩＭ）中に示されている特定の時刻においてこれらのフレームを送信し得る。この方法は、マルチキャストフレームのための低いデータレートと高いパケットロスとを生じ得る。その結果、シンクが接続されること、および他のフィードバック機構（たとえば、ＲＴＳＰ）も使用され得ることを保証するために、ＲＴＳＰキープアライブタイムアウトが設定され得る。

[00186]上記で説明した方法の様々な動作は、様々な（１つまたは複数の）ハードウェアおよび／またはソフトウェア構成要素、回路、および／または（１つまたは複数の）モジュールなど、それらの動作を実行することが可能な任意の好適な手段によって実行され得る。概して、図に示したどの動作も、その動作を実行することが可能な対応する機能的手段によって実行され得る。たとえば、制御電圧に応答して電流を選択的に可能にするための手段は、第１のトランジスタを備え得る。さらに、開回路を選択的に与えるための手段を備える制御電圧の量を制限するための手段は、第２のトランジスタを備え得る。

[00187]情報および信号は、様々な異なる技術および技法のうちのいずれかを使用して表され得る。たとえば、上記の説明全体にわたって言及され得るデータ、命令、コマンド、情報、信号、ビット、シンボル、およびチップは、電圧、電流、電磁波、磁界または磁性粒子、光場または光学粒子、あるいはそれらの任意の組合せによって表され得る。

[00188]本明細書で開示した実施形態に関して説明した様々な例示的な論理ブロック、モジュール、回路、およびアルゴリズムステップは、電子ハードウェア、コンピュータソフトウェア、またはその両方の組合せとして実装され得る。ハードウェアとソフトウェアのこの互換性を明確に示すために、様々な例示的な構成要素、ブロック、モジュール、回路、およびステップについて、概してそれらの機能に関して上記で説明した。そのような機能がハードウェアとして実装されるか、ソフトウェアとして実装されるかは、特定の適用例および全体的なシステムに課せられた設計制約に依存する。説明した機能は、特定の適用例ごとに様々な方法で実装され得るが、そのような実装の決定は、本発明の実施形態の範囲からの逸脱を生じるものと解釈されないことがある。

[00189]本明細書で開示した実施形態に関して説明した様々な例示的なブロック、モジュール、および回路は、汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）または他のプログラマブル論理デバイス、個別ゲートまたはトランジスタ論理、個別ハードウェア構成要素、あるいは本明細書で説明した機能を実施するように設計されたそれらの任意の組合せを用いて実装または実施され得る。汎用プロセッサはマイクロプロセッサであり得るが、代替として、プロセッサは任意の従来のプロセッサ、コントローラ、マイクロコントローラ、または状態機械であり得る。プロセッサはまた、計算デバイスの組合せ、たとえば、ＤＳＰとマイクロプロセッサとの組合せ、複数のマイクロプロセッサ、ＤＳＰコアと連携する１つまたは複数のマイクロプロセッサ、あるいは任意の他のそのような構成として実装され得る。

[00190]本明細書で開示した実施形態に関して説明した方法またはアルゴリズムのステップおよび機能は、直接ハードウェアで実施されるか、プロセッサによって実行されるソフトウェアモジュールで実施されるか、またはその２つの組合せで実施され得る。ソフトウェアで実装した場合、機能は、１つまたは複数の命令またはコードとして有形の非一時的コンピュータ可読媒体上に記憶されるか、あるいは有形の非一時的コンピュータ可読媒体を介して送信され得る。ソフトウェアモジュールは、ランダムアクセスメモリ（ＲＡＭ）、フラッシュメモリ、読取り専用メモリ（ＲＯＭ）、電気的プログラマブルＲＯＭ（ＥＰＲＯＭ）、電気的消去可能プログラマブルＲＯＭ（ＥＥＰＲＯＭ（登録商標））、レジスタ、ハードディスク、リムーバブルディスク、ＣＤ ＲＯＭ、または当技術分野で知られている任意の他の形態の記憶媒体中に常駐し得る。記憶媒体は、プロセッサがその記憶媒体から情報を読み取り、その記憶媒体に情報を書き込み得るように、プロセッサに結合される。代替として、記憶媒体はプロセッサと一体であり得る。本明細書で使用するディスク（disk）およびディスク（disc）は、コンパクトディスク（disc）（ＣＤ）、レーザーディスク（登録商標）（disc）、光ディスク（disc）、デジタル多用途ディスク（disc）（ＤＶＤ）、フロッピー（登録商標）ディスク（disk）、およびｂｌｕ−ｒａｙ（登録商標）ディスク（disc）を含み、ディスク（disk）は、通常、データを磁気的に再生し、ディスク（disc）は、データをレーザーで光学的に再生する。上記の組合せもコンピュータ可読媒体の範囲内に含まれ得る。プロセッサおよび記憶媒体はＡＳＩＣ中に存在し得る。ＡＳＩＣはユーザ端末中に存在し得る。代替として、プロセッサおよび記憶媒体はユーザ端末中に個別構成要素として存在し得る。

[00191]本開示を要約するために、本発明のいくつかの態様、利点および新規の特徴について、本明細書で説明してきた。本発明の特定の実施形態に従って、必ずしもすべてのそのような利点が達成されるとは限らないことを理解されたい。したがって、本発明は、必ずしも、本明細書で教示されるか、または示唆され得る他の利点を達成する必要なしに、本明細書で教示する１つの利点または利点のグループを達成するか、または最適化する形で実施されるか、または行われ得る。

[00192]上記で説明した実施形態の様々な変更は容易に明らかになるものであり、本明細書で定義した一般原理は、本発明の趣旨または範囲から逸脱することなく他の実施形態に適用され得る。したがって、本発明は、本明細書で示した実施形態に限定されるものではなく、本明細書で開示する原理および新規の特徴に合致する最も広い範囲を与えられるべきである。

Claims (30)

1. 複数のシンクデバイスにマルチメディアコンテンツを送信するように構成された装置であって、
   Ｗｉ−Ｆｉピアツーピア接続を用いて前記複数のシンクデバイスの各々に接続することと、
   特定のマルチメディアコンテンツを要求する前記Ｗｉ−Ｆｉピアツーピア接続されたシンクデバイスの各々から能力情報を受信することと、
   グループセッションＩＤとトランスポートポート番号とを含む制御メッセージを生成することと、前記トランスポートポート番号が、前記Ｗｉ−Ｆｉピアツーピア接続されたシンクデバイスの各々に、グループに関連付けられた前記特定のマルチメディアコンテンツを通信するために使用されるべきものである、
   前記Ｗｉ−Ｆｉピアツーピア接続されたシンクデバイスの各々に前記制御メッセージを送信することと、
   前記グループセッションＩＤに関連付けられた前記Ｗｉ−Ｆｉピアツーピア接続されたシンクデバイスのためのストリーミングパラメータのセットを決定することと、
   前記トランスポートポート番号を使用して、およびストリーミングパラメータの前記セットに従って、前記Ｗｉ−Ｆｉピアツーピア接続されたシンクデバイスの各々に前記特定のマルチメディアコンテンツを送信することと
   を行うように構成されたプロセッサを備える、装置。
2. ストリーミングパラメータの前記セットが、コーデック情報、ディスプレイ解像度、ビデオフォーマット、およびオーディオフォーマットのうちの少なくとも１つを含む、請求項１に記載の装置。
3. 前記制御メッセージが、マルチキャスト構成、ユニキャスト構成、およびコンテンツストリーミングのためのグループＭＡＣアドレスを含む信頼できるグループキャスト構成のうちの少なくとも１つをも含む、請求項１に記載の装置。
4. 前記特定のマルチメディアコンテンツの前記送信が、ロバストなマルチキャストフレーム配信技法を使用することによって行われる、請求項１に記載の装置。
5. 前記ロバストなマルチキャストフレーム配信技法が、８０２．１１ａａ規格の肯定応答および再試行プロシージャに基づく、請求項４に記載の装置。
6. 前記プロセッサは、
   前記複数のシンクデバイスのうちのいくつかへの前記Ｗｉ−Ｆｉピアツーピア接続上でグループセッションを確立および維持することと、
   接続されていないシンクデバイスが前記グループセッションＩＤに関連付けられることを可能にするために、前記接続されていないシンクデバイスに、前記グループセッションＩＤ、ポート情報、およびスチーミングパラメータのセットをブロードキャストするための制御メッセージング方式を確立することと
   を行うようにさらに構成された、請求項１に記載の装置。
7. 前記プロセッサが、あらかじめ決定された時間間隔で、前記グループセッションＩＤ、ポート情報、およびスチーミングパラメータの前記セットを周期的にブロードキャストするようにさらに構成された、請求項１に記載の装置。
8. 前記プロセッサが、前記制御メッセージまたは後続の制御メッセージを送信する前に、あらかじめ決定された時間量の間、前記Ｗｉ−Ｆｉピアツーピア接続されたシンクデバイスの各々から前記能力情報を受信することを待つようにさらに構成された、請求項１に記載の装置。
9. 前記プロセッサが、
   前記Ｗｉ−Ｆｉピアツーピア接続されたシンクデバイスの各々からの能力情報の前記受信することをバイパスすることと、
   コンテンツストリーミングのためのグループセッションパラメータのあらかじめ決定されたセットを用いて前記制御メッセージを直ちに生成することと
   を行うようにさらに構成された、請求項１に記載の装置。
10. 前記プロセッサが、前記装置において開始された要求、前記シンクデバイスにおいて開始された要求、および前記シンクデバイスの不十分な能力のうちの少なくとも１つに基づいて、前記関連付けられたグループセッションＩＤから前記Ｗｉ−Ｆｉピアツーピア接続されたシンクデバイスのうちの１つまたは複数を追加または削除するようにさらに構成された、請求項１に記載の装置。
11. 前記シンクデバイスの前記不十分な能力は、少なくとも、それがセッションタイプをサポートすることができないこと、またはコンテンツストリーミングのために使用されるべき前記ストリーミングパラメータのうちの少なくとも１つをサポートすることができないことを含む、請求項１０に記載の装置。
12. 前記プロセッサが、デバイスの複数のグループとのＷｉ−Ｆｉピアツーピア接続を確立するようにさらに構成され、ここにおいて、前記特定のマルチメディアコンテンツ、前記グループセッションＩＤ、セッションタイプ、ポート情報、およびストリーミングパラメータの前記セットのうちの少なくとも１つが、デバイスの前記グループの各々について異なる、請求項１に記載の装置。
13. 前記Ｗｉ−Ｆｉピアツーピア接続を確立することが、Ｗｉ−Ｆｉディスプレイデバイス発見情報の交換を含み、ここにおいて、前記Ｗｉ−Ｆｉディスプレイデバイス発見情報が、少なくとも、前記装置のグループセッション能力の指示、グループセッション管理制御ポートデータのセット、グループセッションタイプ、およびコンテンツストリーミングのために使用されるべきストリーミングパラメータのセットを備える、請求項１に記載の装置。
14. 少なくとも前記Ｗｉ−Ｆｉディスプレイデバイス発見情報のサブセットが、あらかじめ確立されたＷｉ−Ｆｉピアツーピア接続上で、Ｗｉ−Ｆｉ Ｄｉｒｅｃｔサービス規格のアプリケーションサービスプラットフォームを通してさらに交換される、請求項１３に記載の装置。
15. 複数のシンクデバイスにマルチメディアコンテンツを送信する方法であって、
    Ｗｉ−Ｆｉピアツーピア接続を用いて前記複数のシンクデバイスの各々に接続することと、
    特定のマルチメディアコンテンツを要求する前記Ｗｉ−Ｆｉピアツーピア接続されたシンクデバイスの各々から能力情報を受信することと、
    グループセッションＩＤとトランスポートポート番号とを含む制御メッセージを生成することと、前記トランスポートポート番号が、前記Ｗｉ−Ｆｉピアツーピア接続されたシンクデバイスの各々に、グループに関連付けられた前記特定のマルチメディアコンテンツを通信するために使用されるべきものである、
    前記Ｗｉ−Ｆｉピアツーピア接続されたシンクデバイスの各々に前記制御メッセージを送信することと、
    前記グループセッションＩＤに関連付けられた前記Ｗｉ−Ｆｉピアツーピア接続されたシンクデバイスのためのストリーミングパラメータのセットを決定することと、
    前記トランスポートポート番号を使用して、およびストリーミングパラメータの前記セットに従って、前記Ｗｉ−Ｆｉピアツーピア接続されたシンクデバイスの各々に前記特定のマルチメディアコンテンツを送信することと
    を備える、方法。
16. 前記複数のシンクデバイスのうちのいくつかへの前記Ｗｉ−Ｆｉピアツーピア接続上でグループセッションを確立および維持することと、
    接続されていないシンクデバイスが前記グループセッションＩＤに関連付けられることを可能にするために、前記接続されていないシンクデバイスに、前記グループセッションＩＤ、ポート情報、およびストリーミングパラメータのセットをブロードキャストするための制御メッセージング方式を確立することと
    をさらに備える、請求項１５に記載の方法。
17. 前記装置において開始された要求、前記シンクデバイスにおいて開始された要求、および前記シンクデバイスの不十分な能力のうちの少なくとも１つに基づいて、前記関連付けられたグループセッションＩＤから前記Ｗｉ−Ｆｉピアツーピア接続されたシンクデバイスのうちの１つまたは複数を追加または削除することをさらに備え、ここにおいて、前記シンクデバイスの前記不十分な能力は、少なくとも、それがセッションタイプをサポートすることができないこと、またはコンテンツストリーミングのために使用されるべき前記ストリーミングパラメータのうちの少なくとも１つをサポートすることができないことを含む、請求項１５に記載の方法。
18. デバイスの複数のグループとのＷｉ−Ｆｉピアツーピア接続を確立することをさらに備え、ここにおいて、前記特定のマルチメディアコンテンツ、前記グループセッションＩＤ、セッションタイプ、ポート情報、およびストリーミングパラメータの前記セットのうちの少なくとも１つが、デバイスの前記グループの各々について異なる、請求項１５に記載の方法。
19. 前記Ｗｉ−Ｆｉピアツーピア接続を確立することが、Ｗｉ−Ｆｉディスプレイデバイス発見情報の交換を含み、ここにおいて、前記Ｗｉ−Ｆｉディスプレイデバイス発見情報が、少なくとも、前記装置のグループセッション能力の指示、グループセッション管理制御ポートデータのセット、グループセッションタイプ、およびコンテンツストリーミングのために使用されるべきストリーミングパラメータのセットを備える、請求項１５に記載の方法。
20. 少なくとも前記Ｗｉ−Ｆｉディスプレイデバイス発見情報のサブセットが、あらかじめ確立されたＷｉ−Ｆｉピアツーピア接続上で、Ｗｉ−Ｆｉ Ｄｉｒｅｃｔサービス規格のアプリケーションサービスプラットフォームを通してさらに交換される、請求項１９に記載の方法。
21. 複数のシンクデバイスにマルチメディアコンテンツを送信するための装置であって、
    Ｗｉ−Ｆｉピアツーピア接続を用いて前記複数のシンクデバイスの各々に接続するための手段と、
    特定のマルチメディアコンテンツを要求する前記Ｗｉ−Ｆｉピアツーピア接続されたシンクデバイスの各々から能力情報を受信するための手段と、
    グループセッションＩＤとトランスポートポート番号とを含む制御メッセージを生成するための手段と、前記トランスポートポート番号が、前記Ｗｉ−Ｆｉピアツーピア接続されたシンクデバイスの各々に、グループに関連付けられた前記特定のマルチメディアコンテンツを通信するために使用されるべきものである、
    前記Ｗｉ−Ｆｉピアツーピア接続されたシンクデバイスの各々に前記制御メッセージを送信するための手段と、
    前記グループセッションＩＤに関連付けられた前記Ｗｉ−Ｆｉピアツーピア接続されたシンクデバイスのためのストリーミングパラメータのセットを決定するための手段と、
    前記トランスポートポート番号を使用して、およびストリーミングパラメータの前記セットに従って、前記Ｗｉ−Ｆｉピアツーピア接続されたシンクデバイスの各々に前記特定のマルチメディアコンテンツを送信するための手段と
    を備える、装置。
22. 前記複数のシンクデバイスのうちのいくつかへの前記Ｗｉ−Ｆｉピアツーピア接続上でグループセッションを確立および維持するための手段と、
    接続されていないシンクデバイスが前記グループセッションＩＤに関連付けられることを可能にするために、前記接続されていないシンクデバイスに、前記グループセッションＩＤ、ポート情報、およびストリーミングパラメータのセットをブロードキャストするための制御メッセージング方式を確立するための手段と
    をさらに備える、請求項２１に記載の装置。
23. 前記装置において開始された要求、前記シンクデバイスにおいて開始された要求、および前記シンクデバイスの不十分な能力のうちの少なくとも１つに基づいて、前記関連付けられたグループセッションＩＤから前記Ｗｉ−Ｆｉピアツーピア接続されたシンクデバイスのうちの１つまたは複数を追加または削除するための手段をさらに備え、ここにおいて、前記シンクデバイスの前記不十分な能力は、少なくとも、それがセッションタイプをサポートすることができないこと、またはコンテンツストリーミングのために使用されるべき前記ストリーミングパラメータのうちの少なくとも１つをサポートすることができないことを含む、請求項２１に記載の装置。
24. デバイスの複数のグループとのＷｉ−Ｆｉピアツーピア接続を確立するための手段をさらに備え、ここにおいて、前記特定のマルチメディアコンテンツ、前記グループセッションＩＤ、セッションタイプ、ポート情報、およびストリーミングパラメータの前記セットのうちの少なくとも１つが、デバイスの前記グループの各々について異なる、請求項２１に記載の装置。
25. 前記Ｗｉ−Ｆｉピアツーピア接続を確立することが、Ｗｉ−Ｆｉディスプレイデバイス発見情報の交換を含み、ここにおいて、前記Ｗｉ−Ｆｉディスプレイデバイス発見情報が、少なくとも、前記装置のグループセッション能力の指示、グループセッション管理制御ポートデータのセット、グループセッションタイプ、およびコンテンツストリーミングのために使用されるべきストリーミングパラメータのセットを備える、請求項２１に記載の装置。
26. 少なくとも前記Ｗｉ−Ｆｉディスプレイデバイス発見情報のサブセットが、あらかじめ確立されたＷｉ−Ｆｉピアツーピア接続上で、Ｗｉ−Ｆｉ Ｄｉｒｅｃｔサービス規格のアプリケーションサービスプラットフォームを通してさらに交換される、請求項２５に記載の装置。
27. 実行されたとき、複数のシンクデバイスにマルチメディアコンテンツを送信することと、
    Ｗｉ−Ｆｉピアツーピア接続を用いて前記複数のシンクデバイスの各々に接続することと、
    特定のマルチメディアコンテンツを要求する前記Ｗｉ−Ｆｉピアツーピア接続されたシンクデバイスの各々から能力情報を受信することと、
    グループセッションＩＤとトランスポートポート番号とを含む制御メッセージを生成することと、前記トランスポートポート番号が、前記Ｗｉ−Ｆｉピアツーピア接続されたシンクデバイスの各々に、グループに関連付けられた前記特定のマルチメディアコンテンツを通信するために使用されるべきものである、
    前記Ｗｉ−Ｆｉピアツーピア接続されたシンクデバイスの各々に前記制御メッセージを送信することと、
    前記グループセッションＩＤに関連付けられた前記Ｗｉ−Ｆｉピアツーピア接続されたシンクデバイスのためのストリーミングパラメータのセットを決定することと、
    前記トランスポートポート番号を使用して、およびストリーミングパラメータの前記セットに従って、前記Ｗｉ−Ｆｉピアツーピア接続されたシンクデバイスの各々に前記特定のマルチメディアコンテンツを送信することと
    を装置に行わせるコードを備える非一時的コンピュータ可読媒体。
28. 実行されたとき、前記装置において開始された要求、前記シンクデバイスにおいて開始された要求、および前記シンクデバイスの不十分な能力のうちの少なくとも１つに基づいて、前記関連付けられたグループセッションＩＤから前記Ｗｉ−Ｆｉピアツーピア接続されたシンクデバイスのうちの１つまたは複数を追加または削除することを装置に行わせるコードをさらに備え、ここにおいて、前記シンクデバイスの前記不十分な能力は、少なくとも、それがセッションタイプをサポートすることができないこと、またはコンテンツストリーミングのために使用されるべき前記ストリーミングパラメータのうちの少なくとも１つをサポートすることができないことを含む、請求項２７に記載の媒体。
29. 前記Ｗｉ−Ｆｉピアツーピア接続を確立することが、Ｗｉ−Ｆｉディスプレイデバイス発見情報の交換を含み、ここにおいて、前記Ｗｉ−Ｆｉディスプレイデバイス発見情報が、少なくとも、前記装置のグループセッション能力の指示、グループセッション管理制御ポートデータのセット、グループセッションタイプ、およびコンテンツストリーミングのために使用されるべきストリーミングパラメータのセットを備える、請求項２７に記載の媒体。
30. 少なくとも前記Ｗｉ−Ｆｉディスプレイデバイス発見情報のサブセットが、あらかじめ確立されたＷｉ−Ｆｉピアツーピア接続上で、Ｗｉ−Ｆｉ Ｄｉｒｅｃｔサービス規格のアプリケーションサービスプラットフォームを通してさらに交換される、請求項２９に記載の媒体。

Images