JP2018511958A

JP2018511958A - ＷｉＦｉＭｉｒａｃａｓｔにおけるスケーラブルマルチメディアデータ配信のためのピア支援アプリケーションレベルフィードバックを伴う集中型アプリケーションレベルマルチキャスティング

Info

Publication number: JP2018511958A
Application number: JP2017540861A
Authority: JP
Inventors: ホスロ・モハンメド・ラビ; ヴィジェイ・ナーイカル・スブラマニアム; パダム・ラル・カフレ; サニゲパリ・パラヴィーンクマール; ファワド・シャウカット; シヴァクマール・バラスブラマニヤム
Original assignee: クアルコム，インコーポレイテッド
Priority date: 2015-02-05
Filing date: 2015-11-23
Publication date: 2018-04-26
Also published as: WO2016126303A1; CN107211257A; BR112017016754A2; EP3254491B1; US20160234031A1; EP3254491A1; KR20170110621A; CA2972756A1

Abstract

WiFi Miracastにおけるスケーラブルデータサービス配信のための方法、デバイス、システム、および非一時的プロセス可読記憶媒体。WiFi Miracastネットワークの中のソースコンピューティングデバイスのプロセッサは、サービスのフレームまたはパケットを受信するようにスケジュールされたすべてのシンクコンピューティングデバイスを、単一のマルチキャストグループにグループ化し得、マルチキャストフレームまたはパケットをシンクコンピューティングデバイスへ送信し得る。WiFi Miracastネットワークの中の個々のシンクコンピューティングデバイスは、ソースコンピューティングデバイスとのそれらのそれぞれのワイヤレス接続の品質を示すエラーログを、ソースコンピューティングデバイスへ送るように構成され得る。ソースコンピューティングデバイスは、マルチキャストグループメンバーシンクコンピューティングデバイスからの欠落および/または受信済みエラーログに少なくとも部分的に基づいて、マルチキャストグループメンバーシンクコンピューティングデバイスをユニキャストグループに追加し得る。

Description

関連出願
本出願は、その内容全体が参照により本明細書に組み込まれる、2015年2月5日に出願された「Centralized Application Level Multicasting With Peer-Assisted Application Level Feedback For Scalable Multimedia Data Distribution In WiFi Miracast」と題する米国仮特許出願第62/112,574号の優先権の利益を主張する。

ムービングピクチャエキスパートグループ(MPEG)トランスポートストリームを使用して高精細度マルチメディアインターフェース(HDMI（登録商標）)メディアストリームをワイヤレスに模倣するために、従来のワイヤレスメディア配信プラットフォーム(たとえば、WiFi Miracast(登録商標)リビジョン1、Apple AirPlay(登録商標)、Wi-Diなど)が一般に考え出されている。たとえば、ユーザは、スマートフォン上のボタンを押して、近くで接続された1つまたは複数のモニタおよび/またはスピーカーにストリーミングMPEGフォーマットの像をワイヤレスに投影し得る。

WiFi Miracast(登録商標)などのワイヤレスメディア配信プラットフォームにおいて、ユニキャスト、ブロードキャスト、マルチキャスト、およびピアキャストのネットワークフィルタリングトポロジーが使用され得る。しかしながら、許容できるサービス品質(QoS)およびエクスペリエンス品質(QoE)に対してマルチメディアサーバから複数のクライアントにマルチメディアデータを配信することは、サービス基盤のスケーラビリティに完全に依存し、したがって、ワイヤレスメディア配信プラットフォームにおけるスケーラブルマルチメディアデータ配信は、マルチキャストを使用することを必要とする。WiFiの分散協調機能(DCF)、およびユニキャスト性能の不確かさのために、低レイテンシ/ほぼリアルタイムのレスポンスを求めるアプリケーション(たとえば、高品位7.1サラウンドサウンドなどのマルチチャネルオーディオ、マルチチャネルビデオなど)にとって、WiFi Miracast(登録商標)などのワイヤレスメディア配信プラットフォームにおける、多数の受信機へのユニキャスト配信は一般に不可能である。たとえば、非圧縮ベースバンドオーディオを複数の異なるスピーカーへWiFi Miracast(登録商標)を介して送るとき、各スピーカーへのユニキャスト送信を行うための帯域幅要件は、WiFi Miracast(登録商標)システムにおいて利用可能な、全利用可能帯域幅を上回ることがある。したがって、マルチキャスト送信レートが十分であるとき、低レイテンシ/ほぼリアルタイムのレスポンスを求めるアプリケーション(たとえば、高品位7.1サラウンドサウンドなどのマルチチャネルオーディオ、マルチチャネルビデオなど)の多数の受信デバイスへの送信にとって、マルチキャストは実用的な代案である。

コンテンツ配信ネットワーク(CDN)、ネットワーク層マルチキャスト、およびP2Pコンテンツ配信が、マルチメディアデータのグループ配信のために通常使用されるマルチキャスト方式である。しかしながら、そのようなワイヤレスメディア配信プラットフォームにおいてマルチキャストをサポートすることは、コンピューティングデバイスの高レベルオペレーティングシステムがマルチキャストルーティングプロトコルをサポートすることに依存し、または効果的なアクセス制御およびネットワーク管理を必要とし、それらは多くのコンピューティングデバイスが有しない機能である。追加として、ワイヤレスネットワークに固有の不信頼性のために、WiFi Miracast(登録商標)などのワイヤレスメディア配信プラットフォームにおけるグループ通信パケットを用いたリアルタイムマルチメディアデータ配信は、ワイヤレスメディア配信プラットフォーム用の現在のマルチキャスト方式が提供できない許容される品質を得るためのエラーレジリエンシー(error resiliency)を必要とする。

肯定応答は、WiFiがチャネルアクセスおよび接続容量を最適化するためのキャリア検知多重アクセス/衝突回避(CSMA/CA)の要である。ワイヤレスメディア配信プラットフォームはマルチキャストをサポートすべきであるが、メディアアクセス制御(MAC)の不公平さ、損失、および事実上の低チャネル帯域幅(BW)を伴う問題のために、現在の標準的なWiFiマルチキャストは、低レイテンシ/ほぼリアルタイムのレスポンスを求めるアプリケーション(たとえば、高品位7.1サラウンドサウンドなどのマルチチャネルオーディオ、マルチチャネルビデオなど)を、WiFi Miracast(登録商標)などの現在のワイヤレスメディア配信プラットフォームがサポートすることを可能にしない。高信頼マルチキャスト用の現在の802.11ワイヤレス規格プロトコル(すなわち、WiFi)は、アプリケーション層およびアプリケーション層のデータトランスポートプロトコルとは無関係に機能するように設計されており、低レイテンシ/ほぼリアルタイムのレスポンスを求めるアプリケーション(たとえば、高品位7.1サラウンドサウンドなどのマルチチャネルオーディオ、マルチチャネルビデオなど)を、現在のワイヤレスメディア配信プラットフォーム(たとえば、WiFi Miracast(登録商標))がサポートすることを可能にしない。チャネルひずみの発生源に応じて、高信頼マルチキャスト用の現在の802.11WiFiプロトコルは、ブルートフォース(brute force)を使用してフレームまたはパケットをやみくもに反復し、そのことはめったにWiFi送信の信頼性を高めない。追加として、高信頼マルチキャスト用の現在の802.11WiFiプロトコルは、しばしば、実際のマルチキャストサービスを提供するのではなく低い変調およびコーディング方式(MCS)のユニキャストを活用してコンテンツデータを送信し、マルチキャストを使用することによって達成されることが意図されるすべてのチャネル効率を低MCSのユニキャストがパージすることがあるので、そのことは同様に欠陥がある。

様々な実施形態は、WiFi Miracast(登録商標)におけるスケーラブルデータサービス配信のための方法、デバイス、システム、および非一時的プロセス可読記憶媒体を提供する。一実施形態では、WiFi Miracast(登録商標)ネットワークの中のソースコンピューティングデバイスのプロセッサは、サービスのフレームまたはパケットを受信するようにスケジュールされたすべてのシンクコンピューティングデバイスを、単一のマルチキャストグループにグループ化し得、マルチキャストフレームまたはパケットをシンクコンピューティングデバイスへ送信し得る。一実施形態では、WiFi Miracast(登録商標)ネットワークの中の個々のシンクコンピューティングデバイスは、ネットワークリソースを監視し、ソースコンピューティングデバイスとのそれらのそれぞれのワイヤレス接続の品質を決定するように構成され得る。一実施形態では、WiFi Miracast(登録商標)ネットワークの中の個々のシンクコンピューティングデバイスは、ソースコンピューティングデバイスから受信されるWiFi Miracast(登録商標)通信のサービス品質を示すエラーログまたは類似のメッセージを、ソースコンピューティングデバイスへ送るように構成され得る。一実施形態では、ソースコンピューティングデバイスは、マルチキャストグループメンバーシンクコンピューティングデバイスから受信されたかつ/または受信されなかったエラーログに少なくとも部分的に基づいて、マルチキャストグループメンバーシンクコンピューティングデバイスをユニキャストグループに追加し得る。

WiFi Miracastにおけるスケーラブルデータサービス配信のための具現化方法は、データサービスを受信すべきすべてのシンクコンピューティングデバイスをマルチキャストグループに、ソースコンピューティングデバイスによってグループ化することと、データサービスのフレームをWiFi Miracastマルチキャスト送信を介してマルチキャストグループの中のシンクコンピューティングデバイスへ、ソースコンピューティングデバイスから送ることと、すべてのマルチキャストグループメンバー用のエラーログが受信されているかどうかを、ソースコンピューティングデバイスによって決定することと、すべてのマルチキャストグループメンバー用のエラーログが受信されていないという決定に応答して、欠落エラーログに関連する任意のグループメンバーをユニキャストグループに、ソースコンピューティングデバイスによって追加することとを含み得る。

いくつかの実施形態では、方法は、任意のマルチキャストグループメンバーにとってのチャネル性能が許容できないことを受信エラーログが示すかどうかを、ソースコンピューティングデバイスによって決定することと、そのようなマルチキャストグループメンバーにとってのチャネル性能が許容できないことを受信エラーログが示すという決定に応答して、許容できないチャネル性能に関連する任意のマルチキャストグループメンバーをユニキャストグループに、ソースコンピューティングデバイスによって追加することとをさらに含み得る。

いくつかの実施形態では、方法は、任意のユニキャストグループメンバーにとってのチャネル性能が許容できることを受信エラーログが示すかどうかを、ソースコンピューティングデバイスによって決定することと、そのようなユニキャストグループメンバーにとってのチャネル性能が許容できることを受信エラーログが示すという決定に応答して、許容できるチャネル性能に関連する任意のユニキャストグループメンバーをユニキャストグループから、ソースコンピューティングデバイスによって除去することとをさらに含み得る。

いくつかの実施形態では、方法は、任意のマルチキャストグループメンバーにとってのチャネル状態が許容できないことを受信エラーログが示すかどうかを、ソースコンピューティングデバイスによって決定することと、そのマルチキャストグループメンバーにとってのチャネル状態が許容できないことを受信エラーログが示すという決定に応答して、そのようなマルチキャストグループメンバーに対してチャネルを解放かつ/またはデータサービスを格下げすることとをさらに含み得る。

いくつかの実施形態では、方法は、チャネル帯域幅がユニキャストグループの中のすべてのグループメンバーへのユニキャスト送信にとって利用可能であるかどうかを、ソースコンピューティングデバイスによって決定することと、チャネル帯域幅がユニキャストグループの中のすべてのグループメンバーへのユニキャスト送信にとって利用可能であるとは限らないという決定に応答して、チャネルを解放かつ/またはデータサービスを格下げすることとをさらに含み得る。いくつかの実施形態では、方法は、チャネル帯域幅がユニキャストグループの中のすべてのグループメンバーへのユニキャスト送信にとって利用可能であるという決定に応答して、データサービスの次のフレームの送信のための時間に到達しているかどうかを、ソースコンピューティングデバイスによって決定することと、データサービスのフレームをそれぞれのWiFi Miracastユニキャスト送信を介してユニキャストグループの中のシンクコンピューティングデバイスへ、ソースコンピューティングデバイスから再送信することとをさらに含み得る。いくつかの実施形態では、方法は、チャネル帯域幅がユニキャストグループの中のすべてのグループメンバーへのユニキャスト送信にとって利用可能であるという決定に応答して、データサービスの次のフレームを、WiFi Miracastマルチキャスト送信を介してマルチキャストグループの中のシンクコンピューティングデバイスへ、またそれぞれのWiFi Miracastユニキャスト送信を介してユニキャストグループの中のシンクコンピューティングデバイスへ、ソースコンピューティングデバイスから送ることをさらに含み得る。

いくつかの実施形態では、方法は、エラーログをソースコンピューティングデバイスへ送るようにシンクコンピューティングデバイスに指示する要求を、ソースコンピューティングデバイスからシンクコンピューティングデバイスへ送ることをさらに含み得る。

さらなる実施形態は、上記で説明した方法の動作を実行するためのプロセッサ実行可能命令を用いて構成されたプロセッサを含むソースコンピューティングデバイスを含む。さらなる実施形態は、上記で説明した方法の動作をソースコンピューティングデバイスに実行させるように構成されたプロセッサ実行可能命令が記憶されている、非一時的プロセッサ可読媒体を含む。さらなる実施形態は、上記で説明した方法の動作を実行するための手段を含むソースコンピューティングデバイスを含む。

本明細書に組み込まれ、本明細書の一部を構成する添付の図面は、特許請求の範囲の例示的な実施形態を示し、上記に与えた一般的な説明および下記の発明を実施するための形態とともに、特許請求の範囲の特徴を説明するのに役立つ。

様々な実施形態とともに使用するのに好適なワイヤレスメディア配信プラットフォームまたはシステムのシステムブロック図である。一実施形態による、集中型アプリケーション層マルチキャスト(ALM:application-layer-multicast)グループを確立するためにソースコンピューティングデバイスとシンクコンピューティングデバイスとの間で交換されるメッセージを示すコールフロー図である。一実施形態による、WiFi Miracast(登録商標)プロトコルスタックにおけるALMソケットインターフェースを示すデータ構造図である。一実施形態による、ALMを有するWiFi Miracast(登録商標)プロトコルスタックを示すデータ構造図である。アプリケーションレベルチャネル品質推定のための具現化方法を示すプロセスフロー図である。グループベースチャネル誤り訂正用の適応ユニキャスト反復/再送信のための具現化方法を示すプロセスフロー図である。グループベースチャネル品質問合せのためにソースコンピューティングデバイスとシンクコンピューティングデバイスとの間で交換されるメッセージを示すコールフロー図である。エラーログを生成し送るための具現化方法を示すプロセスフロー図である。図8Aの具現化方法を実施する具現化シンクコンピューティングデバイスを示すブロック図である。 WiFi Miracast(登録商標)におけるスケーラブルデータサービス配信のための具現化方法を示すプロセスフロー図である。 WiFi Miracast(登録商標)におけるスケーラブルデータサービス配信のための具現化方法を示すプロセスフロー図である。様々な実施形態における使用にとって好適なモバイルコンピューティングデバイスの構成要素ブロック図である。様々な実施形態における使用にとって好適なスピーカーユニットの構成要素ブロック図である。

添付の図面を参照しながら、様々な実施形態が詳細に説明される。可能な場合はいつでも、同じまた同様の部分を指すために、図面全体を通して同じ参照番号が使用される。特定の例および実装形態になされる参照は、説明のためであり、特許請求の範囲を限定することを意図していない。

「例示的」という単語は、本明細書では「例、事例、または例示として働くこと」を意味するために使用される。本明細書で「例示的」として説明するいかなる実装形態も、必ずしも他の実装形態よりも好ましいか、または有利であると解釈されるべきではない。

本明細書では「コンピューティングデバイス」という用語は、セルラー電話、スマートフォン、ウェブパッド、タブレットコンピュータ、インターネット対応セルラー電話、WiFi対応電子デバイス、携帯情報端末(PDA)、ラップトップコンピュータ、パーソナルコンピュータ、スピーカー、ホームシアターレシーバ、セットトップボックス、テレビ、メディアプレーヤ、プリンタ、ヘッドレストマウントビデオディスプレイ、カメラ、プリンタ、装着型デバイス、および少なくともプロセッサを装備した類似の電子デバイスのうちのいずれか1つまたはすべてを指すために使用される。様々な実施形態では、そのようなコンピューティングデバイスは、ワイドエリアネットワーク(WAN)またはローカルエリアネットワーク(LAN)などを介したワイヤレス接続を確立するために、トランシーバ(たとえば、LTE、3G、4G、Bluetooth（登録商標）、WiFiなど、ワイヤレスネットワークトランシーバ)を用いてさらに構成され得る。

様々な実施形態では、WiFi Miracast(登録商標)ネットワークなどのワイヤレスネットワークの中のコンピューティングデバイスは、それらがコンテンツデータを送信しているのか、それとも受信しているのかに応じて、ソースおよび/またはシンクとして分類され得る。ソースは、コンテンツフレームまたはパケットを1つまたは複数の他のコンピューティングデバイス(すなわち、シンクデバイス)へ送るコンピューティングデバイスであり得、たとえば、フレームまたはパケットをワイヤレスネットワークの中の他のコンピューティングデバイスに提供するサーバとして動作する。シンクは、1つまたは複数の他のコンピューティングデバイスからコンテンツフレームまたはパケットを受信するコンピューティングデバイスであり得る。コンピューティングデバイスは、WiFi Miracast(登録商標)ネットワークなどのワイヤレスネットワークにおいて、排他的にソースとして動作してよく、排他的にシンクとして動作してよく、かつ/またはシンクとソースの両方として動作してよい。一例として、シンクとして働く一連のスピーカーに高品位7.1サラウンドサウンドなどのマルチチャネルオーディオをワイヤレスに提供するソースとして働くホームシアターレシーバを含む、家庭内サラウンドサウンドシアターシステムが、WiFi Miracast(登録商標)ネットワークにおいて実施され得る。別の例として、WiFi Miracast(登録商標)ネットワークは、1つまたは複数のソースとして働く近くで接続された1つまたは複数のモニタに、ストリーミングMPEGフォーマットの像をワイヤレスに投影するソースとして働く、スマートフォンを含み得る。

異なるワイヤレス接続、ワイヤレスネットワーク、およびワイヤレスメディア配信プラットフォームの様々な例、特に、WiFi Miracast(登録商標)の接続、ネットワーク、およびメディア配信プラットフォームが、本明細書で説明される。WiFi Miracast(登録商標)の説明は、様々な実施形態の態様をより良く示すための例として提供されるにすぎず、特に記載されない限り特許請求の範囲をWiFi Miracast(登録商標)に限定することを意図しない。他のワイヤレス接続、ワイヤレスネットワーク、およびワイヤレスメディア配信プラットフォーム(たとえば、Apple AirPlay(登録商標)、Wi-Diなど)が、様々な実施形態を使用してよく、または様々な実施形態とともに使用されてよく、他のワイヤレス接続、ワイヤレスネットワーク、およびワイヤレスメディア配信プラットフォームが、本明細書で説明する様々な例において置き換えられてよい。

一実施形態では、WiFi Miracast(登録商標)における複数の構造化ピアツーピア(P2P)接続を用いたソースコンピューティングデバイス(たとえば、モバイルフォンまたはタブレット)は、シンクコンピューティングデバイスのグループへのマルチメディアデータのスケーラブル配信用の、アプリケーション依存かつアプリケーション制御のワンホップフォールトトレラント集中型アプリケーション層マルチキャスト(ALM)グループを自己編成し得る。たとえば、WiFi Miracast(登録商標)シンクコンピューティングデバイスの集中型ALMグループは、ソースコンピューティングデバイスからオーバーレイ上で配信されるマルチキャストペイロードを直接受信するために、仮想オーバーレイネットワークを協働的に形成し得る。アプリケーション配信モデルに基づいて、複数のWiFi Miracast(登録商標)シンクコンピューティングデバイスは、WiFi Miracast(登録商標)におけるソケットからアプリケーションデータを同時に受信するためにグループ化され得る。一実施形態では、シンクコンピューティングデバイスのピアクライアントの中のソケットオブジェクトと直接送信請求および通信して事前にマルチキャストグループを編成する、ソースコンピューティングデバイスの中のマルチキャストソケットインターフェースを用いて集中型ALMが実施され得る。コアソケットオブジェクトサービスは、接続開放、接続受諾、データ送信、およびデータ受信を含み得る。サービス管理は、サービスディスカバリフレームワークを使用して集中型ALMを介してサポートされ得る。

一実施形態では、WiFi Miracast(登録商標)ネットワークの中のソースコンピューティングデバイスのプロセッサは、サービスのフレームまたはパケットを受信するようにスケジュールされたすべてのシンクコンピューティングデバイスを、単一のマルチキャストグループにグループ化し得、マルチキャストフレームまたはパケットをシンクコンピューティングデバイスへ送信し得る。一実施形態では、マルチキャストフレームまたはパケットは、エラーログ(または、チャネル統計値の任意の他のタイプの表示)を生成しソースコンピューティングデバイスへ返送するように、任意の受信シンクコンピューティングデバイスに指示する表示を含み得る。ソースコンピューティングデバイスは、着信エラーログを収集し得、エラーログの受信および/または受信の欠如に基づいて、特定のシンクコンピューティングデバイスがマルチキャストフレームまたはパケットを受信したか否かを決定し得る。一実施形態では、マルチキャストフレームまたはパケットを受信していないとソースコンピューティングデバイスのプロセッサによって決定された任意のシンクコンピューティングデバイスは、ユニキャストグループへ移動されてよく、マルチキャストフレームまたはパケットは、ユニキャストグループの中の各それぞれのシンクコンピューティングデバイスへユニキャスト送信を介して直接再送信され得る。理想的にはすべてのシンクコンピューティングデバイスが元のマルチキャスト送信を介してマルチキャストフレームまたはパケットを受信することができ、ユニキャスト再送信のいかなる必要性も排除し得るが、単一のマルチキャストグループの中のシンクコンピューティングデバイスの少なくとも一部分が元のマルチキャスト送信を介してマルチキャストフレームまたはパケットを受信するものと思われ、別個のユニキャスト送信を介してすべてのメンバーシンクコンピューティングデバイスへフレームまたはパケットを送ることと比較してユニキャスト送信の必要性を低減する。適応ユニキャスト再送信は、元のマルチキャスト送信を受信しなかったシンクコンピューティングデバイスのサブセットの各々に届くように使用され得る。このようにして、元の送信を受信した、単一のマルチキャストグループの中のシンクコンピューティングデバイスにとって、フレームまたはパケットのユニキャスト送信が回避され得るので、より小さい帯域幅がユニキャスト送信に専用であってよい。

いくつかの実施形態では、フラグ付けされていないフレームまたはパケットが、送信されていないものとしてソースコンピューティングデバイスのプロセッサによって再び識別され得るように、フレームまたはパケットの再送信は、ソースコンピューティングデバイスのメモリの中にバッファリングされている、前に送信されたフレームまたはパケットに関連するフラグを設定解除することを含み得る。このことは、ソースコンピューティングデバイスのプロセッサに、フラグ付けされていないフレームまたはパケットをバッファから再送信させ得る。

さらなる実施形態では、ソースコンピューティングデバイスのプロセッサは、次のフレームまたはパケットの送信のための時間に到達しているかどうかを決定し得る。たとえば、各フレームまたはパケットは送信時間に関連付けられてよく、ソースコンピューティングデバイスにおけるクロック時間に基づいて、ソースコンピューティングデバイスのプロセッサは次のフレームまたはパケットの送信のための時間に到達したかどうかを決定し得る。次のフレームまたはパケットの送信のための時間に到達していないという決定に応答して、ソースコンピューティングデバイスのプロセッサは、ユニキャスト送信を介してユニキャストグループの中の各それぞれのシンクコンピューティングデバイスへ前のフレームまたはパケットを直接再送信してよい。次のフレームまたはパケットの送信のための時間に到達しているという決定に応答して、ソースコンピューティングデバイスのプロセッサは、前のフレームまたはパケットを再送信せずに次のフレームまたはパケットを送ってよい。このようにして、次のフレームまたはパケットの送信のための時間に到達していることによって示されるようにフレームまたはパケットのための送信ウィンドウが閉じられているとき、ソースコンピューティングデバイスのプロセッサは、再送信においてリソースを消耗することを回避し得、マルチキャスト送信を介してマルチキャストグループの中のそれぞれのシンクコンピューティングデバイスへ、またユニキャスト送信を介してユニキャストグループの中の各それぞれのシンクコンピューティングデバイスへ、次のフレームまたはパケットを送ることに直ちに進んでよい。

一実施形態では、エラーログ(または、チャネル統計値の任意の他のタイプの表示)を求める要求が、制御プレーンメッセージなどによる、マルチキャストフレームまたはパケットとは別個のメッセージによって、ソースコンピューティングデバイスから送られ得る。たとえば、WiFi Miracast(登録商標)は、マルチキャスト送信に関連するエラーログを要求するメッセージを送るために、リアルタイムストリーミングプロトコル(RTSP)シグナリングを使用し得る。一実施形態では、ソースコンピューティングデバイスは、エラーログ(または、チャネル統計値の任意の他のタイプの表示)を生成しシンクコンピューティングデバイスへ送ることを求める要求を、RTSP SET_PARAMETER要求などの任意の制御メッセージを使用することによって送り得る。一実施形態では、エラーログを求める要求はまた、ソースコンピューティングデバイスからシンクコンピューティングデバイスへサービスディスカバリフレームワークを通じて送られ得る。

様々な実施形態では、エラーログ(または、チャネル統計値の任意の他のタイプの表示)を求める要求は、シンクコンピューティングデバイスによるエラーログの1回限りの送信を求める要求であってよく、または要求は、シンクコンピューティングデバイスによる連続するエラーログの周期的な送信を求める要求であってもよい。たとえば、ソースコンピューティングデバイスから送られる、エラーログを求める要求は、シンクコンピューティングデバイスが単一のエラーログを生成し送るべきであることを示し得る。別の例として、ソースコンピューティングデバイスから送られる、エラーログを求める要求は、シンクコンピューティングデバイスが規定された周期で(たとえば、少なくとも50msごとに)エラーログを生成し送るべきであることを示し得る。

一実施形態では、WiFi Miracast(登録商標)ネットワークの中の個々のシンクコンピューティングデバイスは、ソースコンピューティングデバイスとのそれらのそれぞれのワイヤレス接続の品質を監視および決定するように構成され得る。一実施形態では、シンクコンピューティングデバイスのプロセッサは、フレームまたはパケットが受信されるとき、MPEGフレームまたはパケットなどのマルチメディアコンテンツフレームまたはパケットの中に含まれる1つまたは複数のデータ要素を監視し得る。データ要素は、マルチメディアコンテンツに対応する時間および/またはシーケンス情報を含み得る。フレームまたはパケットの中のデータ要素に基づいて、シンクコンピューティングデバイスのプロセッサは、フレーム損失レートまたはパケット損失レートなどのチャネル状態推定を行って、ソースコンピューティングデバイスとシンクコンピューティングデバイスとの間のワイヤレス接続の品質を決定し得る。時間およびシーケンス情報の例は、マルチメディアコンテンツを含むMPEGトランスポートストリームのプログラムクロック基準(PCR:program clock reference)および連続性カウンタ(CC:continuity counter)を含み得る。別の例は、MPEGトランスポートストリームを含むリアルタイムトランスポートプロトコル(RTP)のシーケンス番号(SEQ_NUM)を含み得る。

一実施形態では、シンクコンピューティングデバイスのプロセッサは、連続的に受信される2つ以上のフレームまたはパケットの中で示されるMPEGプログラムクロック基準(PCR)を比較してPCRスキップまたは欠落レートを計算し得る。一実施形態では、シンクコンピューティングデバイスのメモリの中に記憶されているしきい値を超えるPCRスキップまたは欠落レートは、PCRエラーが発生していることを示し得る。一実施形態では、PCRスキップまたは欠落レートおよび/あるいはPCRエラー発生の表示は、パケット損失レートなどのチャネル品質(または、チャネル状態)推定を行うために、シンクコンピューティングデバイスのプロセッサによって使用され得る。

一実施形態では、シンクコンピューティングデバイスのプロセッサは、連続的に受信される2つ以上のフレームまたはパケットの中で示されるMPEG連続性カウンタ(CC)を比較して連続性カウンタスキップまたは欠落レート(すなわち、シーケンスの中の1つまたは複数のフレームが受信されないレート)を計算し得る。一実施形態では、シンクコンピューティングデバイスのメモリの中に記憶されているしきい値を超える連続性カウンタスキップまたは欠落レートは、連続性カウンタエラーが発生していることを示し得る。一実施形態では、連続性カウンタスキップまたは欠落レートおよび/あるいは連続性カウンタエラー発生の表示は、パケット損失レートなどのチャネル状態推定を行うために、シンクコンピューティングデバイスのプロセッサによって使用され得る。

一実施形態では、シンクコンピューティングデバイスのプロセッサは、連続的に受信される2つ以上のフレームまたはパケットの中で示されるRTPシーケンス番号(SEQ_NUM)を比較してRTP SEQ_NUMスキップまたは欠落レートを計算し得る。一実施形態では、シンクコンピューティングデバイスのメモリの中に記憶されているしきい値を超えるRTP SEQ_NUMスキップまたは欠落レートは、RTP SEQエラーが発生していることを示し得る。一実施形態では、RTP SEQ_NUMスキップまたは欠落レートおよび/あるいはRTP SEQエラー発生の表示は、パケット損失レートなどのチャネル状態推定を行うために、シンクコンピューティングデバイスのプロセッサによって使用され得る。

さらなる実施形態では、PCRスキップまたは欠落レートおよび/あるいはPCRエラー発生の表示、連続性カウンタスキップまたは欠落レートおよび/あるいは連続性カウンタエラー発生の表示、ならびにRTP SEQ_NUMスキップまたは欠落レートおよび/あるいはRTP SEQエラー発生の表示のうちの2つ以上の様々な組合せが、パケット損失レートなどのチャネル状態推定を行うために、シンクコンピューティングデバイスのプロセッサによって一緒に使用され得る。

一実施形態では、シンクコンピューティングデバイスは、パケット損失レートなどのチャネル状態推定値をメモリの中に記憶されているしきい値と比較し得、チャネル状態推定値がしきい値を上回ることに応答して、エラーログ(たとえば、CQEログ)またはチャネル統計値の任意の他のタイプの表示を生成し得る。一実施形態では、エラーログは、パケット損失レートなどのチャネル状態推定値を示し得る。さらなる実施形態では、エラーログは、アプリケーション性能推定値(たとえば、QoS推定値、QoE推定値など)などの、シンクコンピューティングデバイスに関する他のメトリックを含み得る。一実施形態では、シンクコンピューティングデバイスは、ソースコンピューティングデバイスからシンクコンピューティングデバイスへ送られたフレームまたはパケットの中で示されるエラーログ要求などの、ソースデバイスからのエラーログを求める要求に応答して、エラーログ(たとえば、CQEログ)を生成し得る。様々な実施形態では、パケット損失レートがメモリの中に記憶されているパケット損失しきい値を上回ることなどの、チャネル状態推定値がしきい値を上回ることに応答して、かつ/またはソースデバイスからのエラーログを求める要求に応答して、シンクコンピューティングデバイスは、生成されたエラーログ(たとえば、CQEログ)をソースコンピューティングデバイスへ送り得る。一実施形態では、エラーログは、別個のワイヤレスアップリンクチャネルを介したユニキャスト送信の中で、シンクデバイスからソースコンピューティングデバイスへ送られ得る。

一実施形態では、マルチキャストグループメンバーシンクコンピューティングデバイスから受信されたエラーログ内に含まれる情報に少なくとも部分的に基づいて、ならびにマルチキャストグループのメンバーからのエラーログがない(すなわち、欠落エラーログ)場合に、ソースコンピューティングデバイスは、マルチキャストグループメンバーシンクコンピューティングデバイスをユニキャストグループに追加し得る。たとえば、マルチキャストグループのメンバーである特定のシンクコンピューティングデバイスからソースコンピューティングデバイスによってエラーログが受信されていないという決定に応答して、ソースコンピューティングデバイスは、コンピューティングデバイスがマルチキャスト送信を受信していないと推定して、そのコンピューティングデバイスをユニキャストグループまたはリストに追加し得る。別の例として、マルチキャストグループメンバーシンクコンピューティングデバイスにとってのチャネル性能が許容できるレベルを下回ることを示すエラーログを受信することに応答して、ソースコンピューティングは、コンテンツデータの高信頼配信を確実にするために、そのマルチキャストグループメンバーシンクコンピューティングデバイスをユニキャストグループまたはリストに追加し得る。

様々な実施形態では、マルチキャスト送信を介してマルチキャストグループメンバーシンクコンピューティングデバイスへフレームまたはパケットを送信した後、ソースコンピューティングデバイスは、やはりユニキャストグループの中またはユニキャストリスト上のシンクコンピューティングデバイスへ、ユニキャストを介して同じフレームまたはパケットを再送信し得る。このようにして、ソースコンピューティングデバイスは、ユニキャストグループメンバーへの送信を二度、すなわち、第1にフレームまたはパケットのマルチキャスト送信を介して、第2に各ユニキャストグループメンバーへのユニキャスト送信を介して試み得る。一実施形態では、ソースコンピューティングデバイスは、現在のチャネル上で利用可能な帯域幅をチェックし得、利用可能な帯域幅が必要なユニキャスト送信をサポートするのに十分大きいことに応答して、ユニキャストグループメンバーへのユニキャスト再送信が行われ得る。帯域幅が十分に大きくないことに応答して、ソースコンピューティングデバイスはチャネルを解放し得る。

一実施形態では、ソースコンピューティングデバイスによって受信されたそれらのそれぞれのエラーログが、そのシンクコンピューティングデバイスにとってのチャネル性能が許容できるレベルを達成していることを示すことに応答して、シンクコンピューティングデバイスは、ユニキャストグループまたはリストから除去され得る。このようにして、それらがマルチキャスト送信からサービス信頼性を受けているとき、シンクコンピューティングデバイスは、ユニキャストグループから除去され得、それによって、さらなるフレームまたはパケットがユニキャストを介してそのようなシンクコンピューティングデバイスへ再送信されないので、ユニキャスト帯域幅における需要を低減し得る。

一実施形態では、ソースコンピューティングデバイスは、1つまたは複数の受信エラーログに基づいて、チャネル状態が許容できるかどうかを決定し得る。チャネル状態が許容できないことに応答して、ソースコンピューティングデバイスは、チャネルを解放かつ/またはサービスを格下げし得る。このようにして、チャネルがマルチキャストをサポートできないとき、リソースは、ユニキャストを介して試みられた再送信において浪費されなくてすむ。たとえば、チャネル状態が許容できないという決定に応答して、ソースコンピューティングデバイスは、7.1サラウンドサウンドサービスから5.1サラウンドサウンドサービスへサービスを格下げし得る。

図1は、WiFi LAN190に接続されかつ/またはWiFi通信を利用することができる様々なコンピューティングデバイス102〜118を含む、WiFi Miracast(登録商標)プラットフォームまたはシステムなどのワイヤレスメディア配信プラットフォームまたはシステム100の一例を示す。このシステム100において、コンピューティングデバイスは、フレームまたはパケット、メッセージ、ログなどのデータを、ワイヤレス接続120および/または122を介して互いに交換し得る。たとえば、スマートフォン102は、ビデオカメラ118(たとえば、インターネットカメラまたはウェブカムなど)、装着型デバイス116(たとえば、スマートウォッチなど)、パーソナルコンピューもしくはデスクトップコンピュータ114、および/またはデジタルカメラ112から、ワイヤレス接続120(たとえば、LAN190を介したWiFi接続など)を介してMPEGストリームを受信し得る。そのような例では、ビデオカメラ118、装着型デバイス116、パーソナルコンピュータもしくはデスクトップコンピュータ114、および/またはデジタルカメラ112は、シンクコンピューティングデバイスとして動作するスマートフォン102にフレームまたはパケットを提供する、ソースコンピューティングデバイスとして動作し得る。シンクコンピューティングデバイスとして動作するスマートフォン102は、確認応答メッセージなどのメッセージおよび/またはエラーログ(または、チャネル統計値の任意の他のタイプの表示)などのログを、ソースコンピューティングデバイスとして動作するビデオカメラ118、装着型デバイス116、パーソナルコンピュータもしくはデスクトップコンピュータ114、および/またはデジタルカメラ112に提供し得る。

さらなる例として、スマートフォン102は、スピーカーデバイス104、プリンタデバイス106、モニタデバイス108、および/またはヘッドマウントディスプレイ(HMD)デバイス110へ、ワイヤレス接続122(たとえば、LAN190を介したWiFi接続など)を介してMPEGストリームを送信し得る。そのような1対多の機能を用いて、WiFi Miracast(登録商標)および類似のワイヤレスメディア配信プラットフォームは、サービス全体を複数のデバイスを介して可能にさせるデバイス間接続性を提供し得る。たとえば、動画を描画するために、スマートフォン102は、ビデオMPEGストリームをヘッドマウントディスプレイデバイス110に、またオーディオMPEGストリームをスピーカーデバイス104に提供し得る。そのような例では、スマートフォン102は、シンクコンピューティングデバイスとして動作するスピーカーデバイス104、プリンタデバイス106、モニタデバイス108、および/またはHMDデバイス110に、フレームまたはパケットを提供するソースコンピューティングデバイスとして動作し得る。シンクコンピューティングデバイスとして動作するスピーカーデバイス104、プリンタデバイス106、モニタデバイス108、および/またはHMDデバイス110は、確認応答メッセージなどのメッセージおよび/またはエラーログ(または、チャネル統計値の任意の他のタイプの表示)などのログを、ソースコンピューティングデバイスとして動作するスマートフォン102に提供し得る。

図2は、一実施形態による、集中型ALMグループを確立するためにソースコンピューティングデバイスとシンクコンピューティングデバイスとの間で交換されるメッセージを示すコールフロー図である。図2は、ソースコンピューティングデバイスのプロセッサ上で実行しているソーススタックタスク層202およびソースWiFi層204(たとえば、サプリカント層および/またはMAC層など)と、シンクコンピューティングデバイスのプロセッサ上で実行しているシンクWiFi層206(たとえば、サプリカント層および/またはMAC層など)およびシンクスタックタスク層208との間で、ワイヤレスWiFi Miracast(登録商標)チャネルなどのユーザチャネル205を介して送られるメッセージを示す。一実施形態では、対応するピアクライアントの中の多くのソケットオブジェクトと直接送信請求および通信して事前にマルチキャストグループを編成するための、ホストMobil-PH/Padピアサーバの中のマルチキャストソケットインターフェースを用いて、集中型ALMが実施され得る。したがって、コアソケットオブジェクトサービスは、接続開放、接続受諾、データ送信、およびデータ受信を含み得る。サービス管理は、サービスディスカバリフレームワークを使用して集中型ALMを介してサポートされ得る。

図2に示すように、シンクコンピューティングデバイスによって接続開放および接続受諾メッセージが受信されると、WiFi確認応答がシンクWiFi層206とソースWiFi MAC層204との間で(たとえば、WiFi MAC層の間で)ユーザチャネル205を介して交換される。追加として、ソースコンピューティングデバイスのソーススタックタスク層202は、マルチキャストチャネルステータス推定照会(たとえば、エラーログを求める要求)をマルチキャストグループのシンクコンピューティングデバイスへ、リモートマルチキャストポートへの書込みメッセージおよび/または読取りメッセージを介して送り得る。シンクコンピューティングデバイスのシンクスタックタスク層208は、ユーザチャネル205を介してソースアドレスおよびポートへ送られる読取り応答/書込みメッセージ(たとえば、要求されたエラーログ)を用いて応答し得る。

図3は、一実施形態による、WiFi Miracast(登録商標)プロトコルスタック300におけるALMソケットインターフェースを示すデータ構造図である。アプリケーション層のサービス管理モジュール302との間で流れる様々な矢印によって示されるように、アプリケーションセッションおよびアクセス制御管理メッセージが、必要に応じてユニキャストまたはブロードキャストされ得る。一実施形態では、ワイヤレスチャネル送信は、サービス管理モジュール302からマルチチャネルオーディオパケッタイザモジュール304およびマルチキャストルーティングモジュール306を通じて、マルチキャストとして配送され得る。追加として、ソースコンピューティングデバイスの設定済みローカルポートをアドレス指定することによってシンクコンピューティングデバイスがマルチキャスト送信に応答し得るように、接続開放モジュール308がソースコンピューティングデバイス用のローカルポートを設定することによって、マルチキャスト送信のための接続マッピングが制御され得る。

図4は、一実施形態による、ALMを有するWiFi Miracast(登録商標)プロトコルスタック400を示すデータ構造図である。一実施形態では、複数のシンクコンピューティングデバイスが、WiFi Miracast(登録商標)における単一のソースソケットからアプリケーションデータを受信するためのマルチキャストグループにグループ化され得る。図4における一点鎖線のマルチキャスト線によって示すように、パケット受信部モジュールおよび着信パケットルータモジュールからの着信マルチキャストフレームまたはパケットは、シンクコンピューティングデバイスのプロセッサ上で実行しているオーバーレイパケットコンストラクタのALMモジュール402へルーティングされ得る。追加として、発信パケット検査およびルータモジュールからの発信フレームまたはパケットは、シンクコンピューティングデバイスのプロセッサ上で実行しているオーバーレイパケットコンストラクタのALMモジュール402へルーティングされ得る。このようにして、マルチキャストグループのシンクコンピューティングデバイスは、パケットを受信することと、ソースコンピューティングデバイスにおけるアプリケーションサーバに(たとえば、FEC nags経由で)届くことの両方のために、マルチキャストソケットを使用し得る。

図5は、アプリケーションレベルチャネル状態推定のための具現化方法500を示すプロセスフロー図である。一実施形態では、方法500の動作は、シンクコンピューティングデバイスのプロセッサによって実行され得る。ブロック502において、シンクコンピューティングデバイスのプロセッサは、アプリケーション性能メトリックを計算し得る。ブロック504において、シンクコンピューティングデバイスのプロセッサは、PCRスキップ/欠落レートを計算し得る。ブロック506において、シンクコンピューティングデバイスのプロセッサは、連続性カウンタスキップ/欠落レートを計算し得る。ブロック508において、シンクコンピューティングデバイスのプロセッサは、RTPシーケンス番号スキップ/欠落レートを計算し得る。ブロック510において、シンクコンピューティングデバイスのプロセッサは、ブロック502、504、506、および508における計算の結果のうちの1つまたは複数に基づいて、チャネル状態推定値を決定し得る。たとえば、チャネル状態推定値は、パケット損失レートであり得る。

決定ブロック512において、シンクコンピューティングデバイスのプロセッサは、パケット損失レートがしきい値よりも大きいかどうかを決定し得る。パケット損失レートがしきい値を超えるという決定に応答して(すなわち、決定ブロック512=「Yes」)、シンクコンピューティングデバイスのプロセッサは、ブロック514において、エラーログをソースコンピューティングデバイスへ、別個のワイヤレスアップリンクチャネルを介したユニキャスト送信の中で送り得る。パケット損失レートがしきい値を越えないという決定に応答して(すなわち、決定ブロック512=「No」)、シンクコンピューティングデバイスのプロセッサは、ワイヤレス接続の変化を検出し、それに対して調整するために、ブロック502、504、506、および508における性能メトリックを計算する動作を反復し得る。

図6は、グループベースチャネル誤り訂正用の適応ユニキャスト反復/再送信のための具現化方法を示すプロセスフロー図である。一実施形態では、方法600の動作は、ソースコンピューティングデバイスのプロセッサによって実行され得る。決定ブロック602において、ソースコンピューティングデバイスのプロセッサは、マルチキャストフレームが準備できているかどうかを決定し得る。マルチキャストフレームが準備できているという決定に応答して(すなわち、決定ブロック602=「Yes」)、ソースコンピューティングデバイスのプロセッサは、決定ブロック604において、チャネルがクリアであるかどうかを決定し得る。チャネルがクリアであるという決定に応答して(すなわち、決定ブロック604=「Yes」)、ソースコンピューティングデバイスのプロセッサは、ブロック606において、分散協調機能(DCF)フレーム間スペース(DIFS)持続時間などの、必要とされるフレーム間スペース(IFS)持続時間を待ち得、決定ブロック610において、チャネルがクリアであるかどうかを決定し得る。ソースコンピューティングデバイスは、DIFSであり得る必要とされるIFS持続時間を待つものとして説明されるが、DIFSは1つの例示的なIFS時間にすぎず、必要とされるIFS持続時間は、アービトレーションフレーム間隔(AIFS)アクセスカテゴリー(AC)AIFS[AC]持続時間などの1つまたは複数の他の時間期間によって表されてよい。

チャネルがクリアでないという決定に応答して(すなわち、決定ブロック604=「No」または決定ブロック610=「No」)、ソースコンピューティングデバイスのプロセッサは、決定ブロック612において、バックオフ期間がタイムアウトしているかどうかを決定し得る。バックオフ期間がタイムアウトしているという決定に応答して(すなわち、決定ブロック612=「Yes」)、ソースコンピューティングデバイスのプロセッサは、ブロック614において、DIFS持続時間を待ち得、ブロック616において、チャネルがクリアであるかどうかを決定し得る。チャネルがクリアでないという決定に応答して(すなわち、決定ブロック616=「No」)、ソースコンピューティングデバイスのプロセッサは、ブロック618において、バックオフ期間を再計算し得る。

ブロック618においてバックオフ期間を再計算すると、またはバックオフ期間がタイムアウトしていないという決定に応答して(すなわち、決定ブロック612=「No」)、ソースコンピューティングデバイスのプロセッサは、ブロック608において、着信エラーログ(たとえば、CQEログ)を収集し得、決定ブロック612において、バックオフ期間がタイムアウトしているかどうかを再び決定し得る。

チャネルがクリアであるという決定に応答して(すなわち、決定ブロック610または616=「Yes」)、ソースコンピューティングデバイスのプロセッサは、ブロック620において、マルチキャストフレームを送信し得る。ブロック621において、ソースコンピューティングデバイスのプロセッサは、グループメンバーごとにCQEを計算し得、マルチキャストアプリケーションQoS/QoEを測定し得る。決定ブロック622において、ソースコンピューティングデバイスのプロセッサは、グループメンバーごとのCQE、およびマルチキャストアプリケーションQoS/QoEに少なくとも部分的に基づいて、チャネルが利用可能であるかどうかを決定し得る。チャネルが利用可能でないという決定に応答して(すなわち、決定ブロック622=「No」)、ソースコンピューティングデバイスのプロセッサは、ブロック624において、チャネルを解放し得る。

チャネルが利用可能であるという決定に応答して(すなわち、決定ブロック622=「Yes」)、ソースコンピューティングデバイスのプロセッサは、決定ブロック626において、すべてのグループメンバーに届いているかどうかを決定し得る。たとえば、ソースコンピューティングデバイスのプロセッサは、各グループメンバーに届いたかどうかを決定するために、各グループメンバーからCQEログが受信されたかどうか、および/または各グループメンバーからいくつかのタイプの確認応答メッセージが受信されたかどうかを決定し得る。少なくとも1つのグループメンバーに届かなかったという決定に応答して(すなわち、決定ブロック626=「No」)、ソースコンピューティングデバイスのプロセッサは、ブロック630において、ミュートされているノード(たとえば、届いていないシンクコンピューティングデバイス)へ、ユニキャストを用いてマルチキャストアプリケーションフレームを送り得る。

すべてのグループメンバーに届いているという決定に応答して(すなわち、決定ブロック626=「Yes」)、ソースコンピューティングデバイスのプロセッサは、決定ブロック628において、チャネル性能またはマルチキャストアプリケーションQoSが劣悪であるかどうかを決定し得る。チャネル性能またはマルチキャストアプリケーションQoSが劣悪であるという決定に応答して(すなわち、決定ブロック628=「Yes」)、ソースコンピューティングデバイスのプロセッサは、ブロック624において、チャネルを解放し得る。チャネル性能またはマルチキャストアプリケーションQoSが劣悪でないという決定に応答して(すなわち、決定ブロック628=「No」)、ソースコンピューティングデバイスのプロセッサは、ブロック632において、レート異常問題を有するノードへ、ユニキャストを用いてマルチキャストアプリケーションフレームを反復/再送信し得る。プロセッサは、ブロック602において、次のマルチキャストフレームが準備できているかどうかを決定することによって、方法602の動作をループ状に実行し得る。

図7は、グループベースチャネル品質問合せのためにソースコンピューティングデバイスとシンクコンピューティングデバイスとの間で交換されるメッセージを示すコールフロー図である。図7は、上記で説明したユーザチャネル205を横断する、層202、204、206、および208の間のさらなる交換を示すという点で、上記で説明した図2と類似である。図7は、すべてのグループメンバーにそれらのそれぞれのCQEおよび/またはアプリケーションQoS/QoEについて照会するために、マルチキャストがどのように使用され得るのかを示す。一実施形態では、ヘルスインタロゲーション(health interrogation)に反応していないノード(たとえば、シンクコンピューティングデバイス)または劣悪なリンク性能を報告しているそれらのノードは、ユニキャスト再送信のためにリストに記載され得る。

図8Aは、エラーログを生成し送るための具現化方法800を示すプロセスフロー図である。一実施形態では、方法800の動作は、シンクコンピューティングデバイスのプロセッサによって実行され得る。ブロック802において、シンクコンピューティングデバイスのプロセッサは、フレームまたはパケットを受信し得る。たとえば、フレームまたはパケットは、ソースコンピューティングデバイスからのマルチキャスト送信および/またはソースコンピューティングデバイスからのユニキャスト送信を介して受信されるフレームまたはパケットであり得る。

ブロック804において、シンクコンピューティングデバイスのプロセッサは、受信されたフレームまたはパケットの中の1つまたは複数のデータ要素の、前に受信されたフレームまたはパケットの中の1つまたは複数のデータ要素との比較に少なくとも部分的に基づいて、チャネル状態を推定し得る。一実施形態では、シンクコンピューティングデバイスのプロセッサは、フレームまたはパケットが受信されるとき、MPEGフレームまたはパケットなどのコンテンツフレームまたはパケットを監視し得る。RTP SEQ_NUM、MPEG-TS、およびPCRなどの、フレームまたはパケットの中のデータ要素に基づいて、シンクコンピューティングデバイスのプロセッサは、現在受信されたフレームまたはパケットを前に受信されたフレームまたはパケットと比較することによって、チャネル状態を推定し得る。一実施形態では、シンクコンピューティングデバイスのプロセッサは、連続的に受信される2つ以上のフレームまたはパケットの中で示されるプログラムクロック基準(PCR)を比較してPCRスキップまたは欠落レートを計算し得る。一実施形態では、シンクコンピューティングデバイスのメモリの中に記憶されているしきい値を超えるPCRスキップまたは欠落レートは、PCRエラーが発生していることを示し得る。一実施形態では、PCRスキップまたは欠落レートおよび/あるいはPCRエラー発生の表示は、チャネルにとってのパケット損失レートなどのチャネル状態を推定するために、シンクコンピューティングデバイスのプロセッサによって使用され得る。一実施形態では、シンクコンピューティングデバイスのプロセッサは、連続的に受信される2つ以上のフレームまたはパケットの中で示されるMPEGタイムスタンプ(TS)および連続性カウンタ(CC)を比較して連続性カウンタスキップまたは欠落レートを計算し得る。一実施形態では、シンクコンピューティングデバイスのメモリの中に記憶されているしきい値を超える連続性カウンタスキップまたは欠落レートは、連続性カウンタエラーが発生していることを示し得る。一実施形態では、連続性カウンタスキップまたは欠落レートおよび/あるいは連続性カウンタエラー発生の表示は、チャネルにとってのパケット損失レートなどのチャネル状態を推定するために、シンクコンピューティングデバイスのプロセッサによって使用され得る。一実施形態では、シンクコンピューティングデバイスのプロセッサは、連続的に受信される2つ以上のフレームまたはパケットの中で示されるリアルタイムトランスポートプロトコル(RTP)シーケンス番号(SEQ_NUM)を比較してRTP SEQ_NUMスキップまたは欠落レートを計算し得る。一実施形態では、シンクコンピューティングデバイスのメモリの中に記憶されているしきい値を超えるRTP SEQ_NUMスキップまたは欠落レートは、RTP SEQエラーが発生していることを示し得る。一実施形態では、RTP SEQ_NUMスキップまたは欠落レートおよび/あるいはRTP SEQエラー発生の表示は、チャネルにとってのパケット損失レートなどのチャネル状態を推定するために、シンクコンピューティングデバイスのプロセッサによって使用され得る。さらなる実施形態では、PCRスキップまたは欠落レートおよび/あるいはPCRエラー発生の表示、連続性カウンタスキップまたは欠落レートおよび/あるいは連続性カウンタエラー発生の表示、ならびにRTP SEQ_NUMスキップまたは欠落レートおよび/あるいはRTP SEQエラー発生の表示のうちの2つ以上の様々な組合せが、チャネルにとってのパケット損失レートなどのチャネル状態を推定するために、シンクコンピューティングデバイスのプロセッサによって一緒に使用され得る。

決定ブロック806において、シンクコンピューティングデバイスのプロセッサは、推定チャネル状態がしきい値を超えるかどうかを決定し得る。たとえば、シンクコンピューティングデバイスのプロセッサは、推定チャネル状態をメモリの中に記憶されているしきい値と比較し得る。具体例として、シンクコンピューティングデバイスのプロセッサは、推定パケット損失レートをメモリの中に記憶されている最大パケット損失レートと比較し得る。推定チャネル状態がしきい値以下であるという決定に応答して(すなわち、決定ブロック806=「No」)、シンクコンピューティングデバイスのプロセッサは、決定ブロック808において、エラーログがソースコンピューティングデバイスによって要求されているかどうかを決定し得る。たとえば、シンクコンピューティングデバイスのプロセッサは、ソースコンピューティングデバイスから受信されたフレームまたはパケットの中にエラーログ要求表示が含まれていたかどうかを決定し得る。

エラーログが要求されていないという決定に応答して(すなわち、決定ブロック808=「No」)、シンクコンピューティングデバイスのプロセッサは、ブロック802において、次のフレームまたはパケットを受信し得る。

エラーログがソースコンピューティングデバイスによって要求されているか(すなわち、決定ブロック808=「Yes」)、または推定チャネル状態がしきい値を超える(すなわち、決定ブロック806=「Yes」)という決定に応答して、シンクコンピューティングデバイスのプロセッサは、ブロック810において、推定チャネル状態を含むエラーログを生成し送り得る。たとえば、エラーログは、ユニキャストを介してソースコンピューティングデバイスへ送られるCQEログであり得る。プロセッサは、ブロック802において、次のフレームまたはパケットを受信することによって方法800を反復し得る。

図8Bは、図8Aの具現化方法800を実施する具現化シンクコンピューティングデバイス850aを示すブロック図である。具現化シンクコンピューティングデバイス850a、850b、850c、および850d(一括して、850)の各々は、ワイヤレスネットワーク870(たとえば、WiFi Miracast(登録商標))を介してソースコンピューティングデバイス880(たとえば、WiFi Miracast(登録商標)サーバデバイス880)と通信するWiFi Miracast(登録商標)クライアントデバイスであり得る。

一実施形態では、ソースコンピューティングデバイス880は、マルチメディアまたは他のリアルタイムコンテンツを、ワイヤレスマルチキャストチャネルを介してWiFi Miracast(登録商標)クライアントデバイス850へマルチキャストし得、シンクコンピューティングデバイスは、エラーログ、またはマルチキャストチャネル品質または状態の他の表示を、ソースコンピューティングデバイス880へ戻して通信し得る。エラーログは、エラーしきい値を満たすことに応答して、またはソースコンピューティングデバイス880による要求に応じて、周期的に(たとえば、少なくとも50msごとに)通信され得る。一例として、WiFi Miracast(登録商標)サーバデバイスは、メディアプレーヤを具現化し得、WiFi Miracast(登録商標)クライアントデバイスは、マルチチャネルサラウンドサウンドシステムの様々なオーディオスピーカー構成要素を具現化し得る。

具現化シンクコンピューティングデバイス850aは、コントローラモジュール852、フローモニタ854、フローアナライザ856、およびリソースマネージャ858を含み得る。コントローラモジュール852、フローモニタ854、およびフローアナライザ856の機能は、改善されたリアルタイム処理のための回路機構または回路モジュールとしてハードウェアで実装され得る。

シンクコンピューティングデバイス850aはまた、1つまたは複数のアプリケーションモジュール860および1つまたは複数の通信モジュール862を含み得る。アプリケーションモジュール860は、データへの低レイテンシアクセスを求める、マルチメディアまたは他のリアルタイムアプリケーションを実施し得る。たとえば、アプリケーションモジュール860は、オーディオ、ビデオ、またはオーディオとビデオの両方を出力するマルチメディアアプリケーションを実施し得る。1つまたは複数の通信モジュール862は、ワイヤレスネットワーク870を介して通信するための通信プロトコルのセットを実施し得る。たとえば、通信モジュール862は、WiFi Miracast(登録商標)ネットワークを介して通信するために、トランスポート層、ネットワーク層、および物理層の通信プロトコルのセットを実施し得る。1つまたは複数のアプリケーションモジュール860および1つまたは複数の通信モジュール862は、回路機構もしくは回路モジュールとしてハードウェアで、またはプロセッサ上で実行するソフトウェアモジュールとして実装され得る。

動作において、マルチキャストグループのメンバーであるシンクコンピューティングデバイス850は、ソースコンピューティングデバイス880からワイヤレスネットワーク870を介してマルチキャストデータストリーム882を受信する。マルチキャストデータストリーム882は、シンクコンピューティングデバイス850による再生または他の出力表示のために、マルチメディアまたは他のリアルタイムコンテンツを搬送し得る。たとえば、WiFi Miracast(登録商標)オーディオスピーカー(シンクコンピューティングデバイス850の一例)のセットは、WiFi Miracast(登録商標)サラウンドサウンドメディアプレーヤからマルチチャネルオーディオデータのマルチキャストデータストリームを受信し得る。メディアプレーヤは、固定型のコンピューティングデバイス(たとえば、セットトップボックス)、または移動可能なコンピューティングデバイス(たとえば、ポータブル音楽プレーヤ)であってよい。

シンクコンピューティングデバイス850aは、様々な物理層、ネットワーク層、およびトランスポート層のプロトコルによる処理のために、1つまたは複数の通信モジュール862を通じて受信マルチキャストデータストリーム882を通信し得る。たとえば、通信モジュール862は、WiFi物理層モジュール、インターネットプロトコル(IP)ネットワークモジュール、およびユーザデータグラムプロトコル(UDP)トランスポートモジュールを含み得る。マルチキャストデータストリーム882は、アプリケーション層特有の処理がマルチメディアまたはリアルタイムコンテンツに対して実行されるアプリケーションモジュール860へ、バスまたは他のハードウェアインターフェースを介してさらに通信され得る。たとえば、WiFi Miracast(登録商標)オーディオスピーカーのアプリケーションモジュール860は、特定のオーディオチャネル(たとえば、前方左、中央、前方右、サラウンド左、サラウンド後部、サラウンド右、サブウーファー)用のマルチチャネルオーディオデータの復号および再生を制御し得る。

通信モジュール862からアプリケーションモジュール860まで間で通信されるマルチキャストデータストリーム882は、パケット、フレーム、または他のユニットにセグメント化され得る。たとえば、マルチキャストデータストリーム882は、いくつかのアプリケーション層プロトコル、たとえば、リアルタイムトランスポートプロトコル(RTP)に従ってフォーマットされたパケットにセグメント化され得る。各RTPパケットは、RTPヘッダおよびペイロードを含み得る。RTPパケットのヘッダは、RTPパケットごとにインクリメントされるシーケンス番号(RTP_SEQ_NUM)を含む、いくつかのアプリケーション層(または、アプリケーション特有)の時間および/またはシーケンス情報を表すデータ要素を含み得る。RTPパケットのペイロードは、マルチメディアもしくは他のリアルタイムコンテンツを搬送し得、または1つもしくは複数のサブパケットを含み得る。たとえば、いくつかの実施形態では、RTPパケットのペイロードは、オーディオおよび/またはビデオデータのエレメンタリストリームを搬送するMPEG-2トランスポートストリーム(TS)パケットを含み得る。MPEG-2 TSパケットのヘッダはまた、アプリケーション層(または、アプリケーション特有)の時間および/またはシーケンス情報を表すデータ要素を含み得る。

マルチメディアまたは他のリアルタイムコンテンツの場合では、アプリケーションモジュール850がマルチキャストデータストリームを良好に、たとえば、最低限のパケット損失しか伴わずに受信することが好ましくあり得る。シンクコンピューティングデバイス850のうちの1つまたは複数がパケットを欠落またはスキップしている(すなわち、すべてのパケットが受信および復号されているとは限らない)場合、対応する再生または出力は、悪影響を受けることがある。クライアントデバイス850がどれほど良好にマルチキャストデータを受信しているのかを決定するために、シンクコンピューティングデバイス850の各々は、マルチキャストデータストリーム882の中の受信パケットのいくつかのアプリケーション層データ要素(たとえば、時間および/またはシーケンス情報)を監視および分析し、そのような分析の結果をエラーログまたはチャネル品質の他の表示の形態で、必要に応じて救済措置のためにソースコンピューティングデバイス880へ戻して通信するように構成され得る。

いくつかの実施形態では、コントローラモジュール852は、受信マルチキャストデータストリーム882のパケットを検出および監視するために、ソースコンピューティングデバイス880からの情報を用いて構成され得る。たとえば、コントローラモジュール852は、マルチキャストアドレスおよびポート番号を含み得る宛先ソケット識別子を用いて構成され得る。コントローラモジュール852は、マルチキャストデータストリーム882内で多重化され得るエレメンタリストリーム(たとえば、オーディオ、ビデオなど)のうちの1つを識別するためのパケット識別子を用いてさらに構成され得る。ソースコンピューティングデバイス880は、そのような構成情報を各シンクコンピューティングデバイス850へ、リソースマネージャ858によって受信および使用される別個のマルチキャストまたはユニキャストメッセージの中で通信して、受信マルチキャストストリームのパケットを検出するためにコントローラモジュール852を構成し得る。

マルチキャストデータストリーム882のパケットが通信モジュール862からアプリケーションモジュール860へ通信されるとき、コントローラモジュール852は、監視されているマルチキャストデータストリーム882に対応するパケットを検出するために、構成されたソケット識別子および/またはパケット識別子を使用し得る。マルチキャストデータストリーム882のパケットが検出されるたびに、コントローラモジュール852は、検出されたパケットの存在を示す割込みまたは他の警報をフローモニタ854へ送り得る。

フローモニタ854は、検出されたパケットの中に含まれる1つまたは複数のデータ要素を監視するように構成され得る。一実施形態では、1つまたは複数のデータ要素は、パケットの中で搬送されるマルチメディアコンテンツに対応する時間またはシーケンス情報を含み得る。たとえば、パケットがRTPパケットである実装形態では、フローモニタ854は、RTPパケットのヘッダの中のシーケンス番号(RTP_SEQ_NUM)の値を読み取り、または抽出するように構成され得る。別の例として、RTPのペイロードは、MPEG-2トランスポートストリーム(TS)パケットをさらに含み得、したがって、フローモニタ854は、MPEG-2 TSパケットの中のプログラムクロック基準(PCR)および/もしくは連続性カウンタ(CC)の値を読み取り、または抽出するように構成され得る。

フローモニタ854は、検出されたパケットの中の監視されるデータ要素を、前に受信されたパケットの中のデータ要素と比較するようにさらに構成され得る。検出されたパケットの中の監視されるデータ要素の値が期待値と異なるという決定に応答して、フローモニタは、受信エラーが発生していると決定し得る。たとえば、RTPパケットのヘッダの中のシーケンス番号(RTP_SEQ_NUM)は、RTPデータパケットごとに1だけインクリメントされる。したがって、連続するRTPパケットのシーケンス番号の差が1よりも大きいという決定に応答して、フローモニタ854は、RTP_SEQ_NUMエラーが存在すると決定し得る。RTP_SEQ_NUMエラーは、概して、1つまたは複数の失われた(すなわち、受信されなかった)RTPパケットを示す。同様に、MPEG-2 TSパケットのプログラムクロック基準(PCR)および連続性カウンタ(CC)の値も、いくつかのレートおよび間隔でインクリメントするものと予期される。したがって、連続的に受信される2つのPCR値の間の実際の間隔が、予期される間隔(たとえば、100ミリ秒ごとに1回)と異なるという決定に応答して、プログラムクロック基準(PCR)エラーが検出され得る。同様に、連続的に監視される連続性カウンタ(CC)の値の間の差が1よりも大きいという決定に応答して、連続性カウンタ(CC)エラーが検出され得る。

フローモニタ854は、受信エラーが存在する(たとえば、RTP_SEQ_NUM PCRおよび/またはCCエラー)という決定に応答して、受信エラーおよび関係する追加のメタデータをフローアナライザ856に通信するように構成され得る。フローアナライザ856は、様々な受信エラーの記録を保持し、そのようなエラーのレート(たとえば、RTP_SEQ_NUM、PCR、および/またはCCスキップ/欠落エラーレート)を経時的に追跡するように構成され得る。フローアナライザ856は、受信エラーレートのうちの1つまたは複数に基づいて、ワイヤレスチャネルの状態または品質の推定値を計算するようにさらに構成され得る。一実施形態では、推定チャネル状態は、パケット損失レートであり得る。たとえば、パケット損失レートの推定値は、RTP_SEQ_NUM、PCR、および/またはCCスキップ/欠落エラーレートのうちの1つまたは複数に基づき得る。

フローアナライザ856はまた、パケット損失レートなどの推定チャネル状態を、最大パケット損失レートなどのエラーしきい値に対して比較するように構成され得る。ワイヤレスチャネルの推定チャネル状態がエラーしきい値を満たすか、または上回るという決定に応答して、フローアナライザ856は、推定チャネル状態を警報または割込みの形態でリソースマネージャ858へ通信し得る。警報に応答して、リソースマネージャ858は、推定チャネル状態を含むエラーログを生成しソースコンピューティングデバイス880へ戻して送信し得る。いくつかの実施形態では、リソースマネージャ858は、ログが生成された直後にエラーログをソースコンピューティングデバイス880へ送り得る。所定の時間において(たとえば、50msごとに)、またはソースコンピューティングデバイス880による要求に応じて、シンクコンピューティングデバイス850がエラーログを送信するように構成される他の実施形態では、リソースマネージャ858は、経時的に統合された推定チャネル状態の複数のタイムスタンプ付けされたエントリを含むエラーログを生成し得る。シンクコンピューティングデバイス850のリソースマネージャ858は、エラーログをユニキャストメッセージの中で、別個のWiFi Miracast(登録商標)チャネル接続を介してソースコンピューティングデバイス880へ戻して送信し得る。

いくつかの実施形態では、リソースマネージャ858はまた、推定チャネル状態を有するか、または有しない警報を、アプリケーションモジュール860へ通信するように構成され得る。推定チャネル状態が、クライアントデバイスがマルチキャストデータストリームを良好に受信していないことを示すとき、警報は、マルチメディアまたはリアルタイムコンテンツの再生または他の出力表示を中止するためのコマンドの形態で通信され得る。クライアントデバイスがマルチキャストデータストリームを良好に受信していないことに基づいてアプリケーションモジュール860がコンテンツの再生または他の出力表示を中止すべきかどうかを決定することを可能にするために、警報はまた、推定チャネル状態を含む通知メッセージの形態で通信され得る。

いくつかの実施形態では、ソースコンピューティングデバイス880およびシンクコンピューティングデバイス850は、サービス仲介およびアドレス指定制御を含み得る拡張ピア支援リソース管理を伴う統合サービスディスカバリフレームワークを実施し得る。サービス仲介は、ピアクライアントデバイス850へのサービスのレベルを交渉および/または格下げすることを含み得る(たとえば、7.1マルチチャネルサラウンドサウンドから5.1マルチチャネルサラウンドサウンドへ)。サービス仲介はまた、シンクコンピューティングデバイス850にとってのワイヤレスチャネル品質が許容できるときにサービスのレベルを交渉および格上げすることを含み得る。アドレス指定制御は、許容できるワイヤレスチャネル品質に遭遇するピアシンクコンピューティングデバイス850へデータをマルチキャストすることと、許容できないワイヤレスチャネル品質に遭遇する1つまたは複数のクライアントデバイス850へ同じデータをユニキャストすることとを含み得る。ソースコンピューティングデバイス880は、サービスディスカバリフレームワークの新たなチャネルまたは既存のチャネルを介して通信され得るエラーログに基づいて、1つまたは複数のクライアントデバイス850が許容できないワイヤレスチャネル品質に遭遇しているかどうかを決定し得る。ソースコンピューティングデバイス880とシンクコンピューティングデバイス850との間の構成情報および/またはエラーログの通信は、サービスディスカバリフレームワークの既存のチャネルを介したメッセージの送信を通じて実施され得る。

図9Aおよび図9Bは、WiFi Miracast(登録商標)におけるスケーラブルデータサービス(たとえば、マルチメディアデータサービス)配信のための具現化方法900を示すプロセスフロー図である。一実施形態では、方法900の動作は、ソースコンピューティングデバイスのプロセッサによって実行され得る。ブロック902(図9A)において、プロセッサまたはソースコンピューティングデバイスは、マルチメディアデータサービス(たとえば、高品位オーディオ、ビデオなど)などのデータサービスを受信すべきすべてのシンクコンピューティングデバイスを、マルチキャストグループにグループ化し得る。ブロック904において、プロセッサまたはソースコンピューティングデバイスは、データサービスのフレームまたはパケットを、マルチキャスト送信を介して(たとえば、WiFi Miracast(登録商標)マルチキャスト送信を介して)送り得る。一実施形態では、送られるフレームまたはパケットは、状態表示および/または性能表示を含むエラーログを生成しソースコンピューティングデバイスへ返送するための、任意の受信シンクコンピューティングデバイスへの表示を含み得る。

ブロック906において、プロセッサまたはソースコンピューティングデバイスは、受信エラーログをチェックし得る。たとえば、プロセッサまたはソースコンピューティングデバイスは、任意の受信エラーログが、シンクコンピューティングデバイスから受信されるエラーログの記憶のために指定されたメモリ位置に記憶されているかどうかを決定し得る。

決定ブロック908において、プロセッサまたはソースコンピューティングデバイスは、すべてのマルチキャストグループメンバー用のエラーログが受信されているかどうかを決定し得る。マルチキャストグループメンバーからエラーログを受信していないことは、グループメンバーがエラーログを用いて応答しなかったので、マルチキャストフレームまたはパケットがグループメンバーに届かなかったことを示し得る。すべてのマルチキャストグループメンバー用のエラーログが受信されていないという決定に応答して(すなわち、決定ブロック908=「Yes」)、プロセッサまたはソースコンピューティングデバイスは、ブロック910において、欠落エラーログに関連するマルチキャストグループメンバーをユニキャストグループに追加し得る。このようにして、エラーログが受信されなかったシンクコンピューティングデバイスは、マルチキャストグループとユニキャストグループの両方のメンバーになり得る。

すべてのマルチキャストグループメンバー用のエラーログが受信されているという決定に応答して(すなわち、決定ブロック908=「Yes」)、またはブロック910においてマルチキャストグループメンバーをユニキャストグループに追加することに応答して、プロセッサまたはソースコンピューティングデバイスは、決定ブロック912において、チャネル状態が許容できることを受信エラーログが示すかどうかを決定し得る。たとえば、プロセッサまたはソースコンピューティングデバイスは、パケット損失レートが最大パケット損失レートを下回ることを、受信エラーログの全部または一部分(たとえば、大部分、平均など)が示すかどうかを決定し得る。

チャネル状態が許容できることを受信エラーログが示すという決定に応答して(すなわち、決定ブロック912=「Yes」)、プロセッサまたはソースコンピューティングデバイスは、決定ブロック914において、すべてのマルチキャストグループメンバーにとってのチャネル性能が許容できることを任意の受信エラーログが示すかどうかを決定し得る。すべてのマルチキャストグループメンバーにとってのチャネル性能が許容できないという決定に応答して(すなわち、決定ブロック914=「No」)、プロセッサまたはソースコンピューティングデバイスは、ブロック916において、チャネル性能が許容できない任意のマルチキャストグループメンバーをユニキャストグループに追加し得る。このようにして、その特定のシンクコンピューティングデバイスにとってのチャネル性能が許容できないことをエラーログが示すシンクコンピューティングデバイスは、マルチキャストグループとユニキャストグループの両方のメンバーになり得る。

すべてのマルチキャストグループメンバーにとってのチャネル性能が許容できるという決定に応答して(すなわち、決定ブロック914=「Yes」)、またはブロック916においてチャネル性能が許容できないマルチキャストグループメンバーをユニキャストグループに追加することに応答して、プロセッサまたはソースコンピューティングデバイスは、決定ブロック918(図9B)において、任意のユニキャストグループメンバーにとってのチャネル性能が許容できることを受信エラーログが示すかどうかを決定し得る。上記で説明したように、フレームまたはパケットは、受信時のエラーログを生成し送るための表示を含み得、再送信されたフレームまたはパケットをユニキャスト送信(たとえば、WiFi Miracast(登録商標)ユニキャスト送信)を介して受信すると、シンクコンピューティングデバイスは、エラーログをソースコンピューティングデバイスへ、たとえば、WiFi Miracast(登録商標)ユニキャストを介して送り得る。ユニキャストグループメンバーによって示されるチャネル性能は、ユニキャストグループメンバーに、ユニキャストグループから除去されるとともにフレームまたはパケットがソースコンピューティングデバイスからマルチキャストのみを介して受信されるように復帰する資格を与え得る。このようにして、シンクコンピューティングデバイスにとってのチャネル性能は(たとえば、干渉発生源の除去などにより)改善するはずであり、ユニキャストリソースは、もはやそのシンクコンピューティングデバイスへの送信に専用でなくてよい。

任意のユニキャストグループメンバーにとってのチャネル性能が許容できることを受信エラーログが示すという決定に応答して(たとえば、決定ブロック918=「Yes」)、ソースコンピューティングデバイスのプロセッサは、ブロック920において、チャネル性能が許容できるユニキャストグループメンバーをユニキャストグループから除去し得る。このようにして、除去されたグループメンバーは、もはやマルチキャストフレームまたはパケットのユニキャスト再送信を受信しない。

任意のユニキャストグループメンバーにとってのチャネル性能が許容できることを受信エラーログが示さないという決定に応答して(たとえば、決定ブロック918=「No」)、またはブロック920においてユニキャストグループメンバーをユニキャストグループから除去することに応答して、ソースコンピューティングデバイスのプロセッサは、決定ブロック922において、チャネル帯域幅がユニキャストグループの中のグループメンバーへのユニキャスト送信にとって利用可能であるかどうかを決定し得る。このようにして、ソースコンピューティングデバイスは、必要な帯域幅がユニキャストグループの現在のすべてのメンバーへのユニキャスト送信を完了するために利用可能であるかどうかをチェックし得る。

帯域幅がユニキャスト送信にとって利用可能であるという決定に応答して(すなわち、決定ブロック922=「Yes」)、ソースコンピューティングデバイスのプロセッサは、決定ブロック923において、次のフレームまたはパケットの送信のための時間に到達しているかどうかを決定し得る。たとえば、各フレームまたはパケットは、送信時間に関連付けられてよく、ソースコンピューティングデバイスにおけるクロック時間に基づいて、ソースコンピューティングデバイスのプロセッサは、次のフレームまたはパケットの送信のための時間に到達しているかどうかを決定し得る。

次のフレームまたはパケットの送信のための時間でないという決定に応答して(すなわち、決定ブロック923=「No」)、ソースコンピューティングデバイスのプロセッサは、ブロック924において、フレームまたはパケットをユニキャスト送信(たとえば、WiFi Miracast(登録商標)ユニキャスト送信)を介してユニキャストグループの中のグループメンバーへ再送信し得る。たとえば、フレームまたはパケットの再送信は、ソースコンピューティングデバイスのメモリの中にバッファリングされている、前に送信されたフレームまたはパケットに関連するフラグを設定解除することを含み得る。そのようなフラグ付けされていないフレームまたはパケットは、送信されていないものとしてソースコンピューティングデバイスのプロセッサによって再び識別され得、ソースコンピューティングデバイスのプロセッサは、フラグ付けされていないフレームまたはパケットをバッファから再送信し得る。ブロック924におけるフレームまたはパケットの再送信を通って、ブロック904(図9A)における元のマルチキャスト送信を越えたフレームまたはパケットを提供するためのさらなる試みがソースコンピューティングデバイスによって着手されて、ユニキャストグループメンバーがフレームまたはパケットを受信したことを確実にしようとし得る。

ブロック924(図9B)においてフレームもしくはパケットをユニキャストを介して再送信することに応答して、または次のフレームもしくはパケットの送信のための時間であるという決定に応答して(すなわち、決定ブロック923=「Yes」)、ソースコンピューティングデバイスのプロセッサは、ブロック905(図9A)において、次のフレームまたはパケットをマルチキャストを介してマルチキャストグループへ、またユニキャストを介してユニキャストグループへ送り得る。

チャネル状態が許容できないことを受信エラーログが示すという決定に応答して(すなわち、決定ブロック912=「No」)、または帯域幅がユニキャスト送信にとって利用可能でないという決定に応答して(すなわち、決定ブロック922=「No」)、ソースコンピューティングデバイスのプロセッサは、ブロック926(図9B)において、チャネルを解放かつ/またはサービスを格下げし得る。たとえば、マルチキャストを介した許容できる送信をチャネルがサポートし得ないので、またはシンクコンピューティングデバイスによってマルチキャストを介して受信されなかったフレームもしくはパケットに対して訂正するのに必要とされるユニキャスト送信をチャネルがサポートし得ないので、ソースコンピューティングデバイスのプロセッサは、サービスの低品質描写に切り替え得る。

様々な実施形態は、様々なワイヤレスコンピューティングデバイスにおいて実施され得、モバイルデバイス1000の形態でのその一例が図10に示される。様々な実施形態では、モバイルデバイス1000は、タッチスクリーンコントローラ1004および内部メモリ1002に結合されたプロセッサ1001を含み得る。プロセッサ1001は、汎用または特定の処理タスクのために指定された1つまたは複数のマルチコア集積回路(IC)であり得る。内部メモリ1002は、揮発性メモリまたは不揮発性メモリであってよく、また、セキュアおよび/もしくは暗号化メモリであってよく、または非セキュアおよび/もしくは非暗号化メモリであってよく、あるいはそれらの任意の組合せであってもよい。タッチスクリーンコントローラ1004およびプロセッサ1001はまた、抵抗感知タッチスクリーン、静電容量感知タッチスクリーン、赤外線感知タッチスクリーンなどの、タッチスクリーンパネル1012に結合され得る。

モバイルデバイス1000は、互いに結合され、かつ/またはプロセッサ1001に結合された、送信および受信のための1つまたは複数の無線信号トランシーバ1008(たとえば、Bluetooth(登録商標)、ZigBee(登録商標)、WiFi(登録商標)、RF無線)およびアンテナ1010を有し得る。トランシーバ1008およびアンテナ1010は、様々なワイヤレス伝送プロトコルスタックおよびインターフェースを実装するために、上述の回路構成とともに使用され得る。いくつかの実施形態では、モバイルデバイス1000は、セルラーネットワークを介した通信を可能にしプロセッサに結合されている、セルラーネットワークワイヤレスモデムチップ1016を含み得る。

モバイルデバイス1000は、プロセッサ1001に結合された周辺デバイス接続インターフェース1018を含み得る。周辺デバイス接続インターフェース1018は、1つのタイプの接続を受け入れるように単独で構成されてよく、またはユニバーサルシリアルバス(USB)、FireWire、Thunderbolt、もしくはPCIeなどの、一般的もしくはプロプライエタリな様々なタイプの物理接続および通信接続を受け入れるように多様に構成されてもよい。周辺デバイス接続インターフェース1018はまた、同様に構成された周辺デバイス接続ポート(図示せず)に結合され得る。

モバイルデバイス1000はまた、音声出力を提供するためのスピーカー1014を含み得る。モバイルデバイス1000はまた、プラスチック、金属、または材料の組合せで構築された、本明細書で説明する構成要素の全部または一部を収容するためのハウジング1020を含み得る。モバイルデバイス1000は、使い捨てバッテリーまたは充電式バッテリーなどの、プロセッサ1001に結合された電源1022を含み得る。充電式バッテリーはまた、モバイルデバイス1000の外部にある電源から充電電流を受けるために、周辺デバイス接続ポートに結合され得る。

上記で説明した様々な実施形態はまた、図11に示すスピーカーユニット1100などの様々なコンピューティングデバイス内に実装され得る。スピーカーユニット1100は、メモリ1104に結合されたプロセッサ1102を含み得る。スピーカーユニット1100は、プロセッサに接続され得るとともに音を出力するように構成され得るスピーカー1106を含み得る。スピーカーユニット1100はまた、互いに結合され、かつ/またはプロセッサ1102に結合された、送信および受信のための1つまたは複数の無線信号トランシーバ1110(たとえば、Bluetooth(登録商標)、ZigBee(登録商標)、WiFi(登録商標)、RF無線など)およびアンテナを含み得る。トランシーバ1110およびアンテナは、様々なワイヤレス伝送プロトコルスタックおよびインターフェースを実装するために、上述の回路構成とともに使用され得る。スピーカーユニット1100はまた、すべてがプロセッサ1102に結合されたタッチパッド1108およびディスプレイ1112を含み得る。

本明細書で説明する様々なプロセッサは、任意のプログラマブルマイクロプロセッサ、マイクロコンピュータ、または本明細書で説明する様々な実施形態の機能を含む様々な機能を実行するようにソフトウェア命令(アプリケーション)によって構成され得る、1つもしくは複数の多重プロセッサチップであり得る。様々なデバイスでは、ワイヤレス通信機能に専用の1つのプロセッサおよび他のアプリケーションを実行するのに専用の1つのプロセッサなどの、複数のプロセッサが設けられ得る。一般に、ソフトウェアアプリケーションは、それらがアクセスされプロセッサにロードされる前に、内部メモリに記憶され得る。プロセッサは、アプリケーションソフトウェア命令を記憶するのに十分な内部メモリを含み得る。多くのデバイスでは、内部メモリは、揮発性メモリ、もしくはフラッシュメモリなどの不揮発性メモリ、または両方の混合物であり得る。この説明の目的で、メモリへの一般的な言及は、内部メモリまたは様々なデバイスの中に差し込まれるリムーバブルメモリと、プロセッサ内のメモリとを含む、プロセッサによってアクセス可能なメモリを指す。

上記の方法の説明およびプロセスフロー図は、単に説明のための例として提供されており、様々な実施形態の動作が提示された順序で実行されなければならないことを要求または暗示するものではない。当業者によって諒解されるように、上記の実施形態における動作の順序は、任意の順序で実行されてよい。「その後」、「次いで」、「次に」などの単語は、動作の順序を限定するものではなく、これらの単語は単に、方法の説明を通じて読者を導くために使用される。さらに、たとえば、冠詞「a」、「an」、または「the」を使用する単数形でのクレーム要素へのいかなる参照も、要素を単数形に限定するものとして解釈すべきではない。

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

本明細書で開示する実施形態に関して説明した様々な例示的な論理、論理ブロック、モジュール、および回路を実装するために使用されるハードウェアは、汎用プロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)もしくは他のプログラマブル論理デバイス、個別ゲートもしくはトランジスタ論理、個別ハードウェア構成要素、または本明細書で説明した機能を実行するように設計されたそれらの任意の組合せを用いて実装または実行されてよい。汎用プロセッサはマイクロプロセッサであってよいが、代替として、プロセッサは、任意の従来のプロセッサ、コントローラ、マイクロコントローラ、またはステートマシンであってもよい。プロセッサはまた、コンピューティングデバイスの組合せ、たとえば、DSPとマイクロプロセッサの組合せ、複数のマイクロプロセッサ、DSPコアと連携した1つもしくは複数のマイクロプロセッサ、または任意の他のそのような構成として実装されてよい。代替的に、いくつかの動作または方法は、所与の機能に固有の回路によって実行されてもよい。

1つまたは複数の例示的な実施形態では、説明した機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装され得る。ソフトウェアで実装される場合、機能は、1つまたは複数の命令またはコードとして、非一時的プロセッサ可読、コンピュータ可読、もしくはサーバ可読媒体、または非一時的プロセッサ可読記憶媒体上に記憶され、またはそれを介して送信され得る。本明細書で開示する方法またはアルゴリズムの動作は、非一時的コンピュータ可読記憶媒体、非一時的サーバ可読記憶媒体、および/または非一時的プロセッサ可読記憶媒体上に存在し得る、プロセッサ実行可能ソフトウェアモジュールまたはプロセッサ実行可能ソフトウェア命令において具現化され得る。様々な実施形態では、そのような命令は、記憶されたプロセッサ実行可能命令または記憶されたプロセッサ実行可能ソフトウェア命令であり得る。有形の非一時的コンピュータ可読記憶媒体は、コンピュータによってアクセスされ得る任意の利用可能な媒体であり得る。限定ではなく例として、そのような非一時的コンピュータ可読媒体は、RAM、ROM、EEPROM、CD-ROMもしくは他の光ディスクストレージ、磁気ディスクストレージもしくは他の磁気記憶デバイス、または命令もしくはデータ構造の形態で所望のプログラムコードを記憶するために使用され得るとともにコンピュータによってアクセスされ得る任意の他の媒体を備え得る。本明細書で使用するディスク(disk)およびディスク(disc)は、コンパクトディスク(disc)(CD)、レーザーディスク（登録商標）(disc)、光ディスク(disc)、デジタル多用途ディスク(disc)(DVD)、フロッピーディスク(disk)、およびブルーレイディスク(disc)を含み、ディスク(disk)は通常、データを磁気的に再生し、ディスク(disc)は、レーザーを用いてデータを光学的に再生する。上記の組合せも、非一時的コンピュータ可読媒体の範囲内に含まれるべきである。加えて、方法またはアルゴリズムの動作は、コンピュータプログラム製品に組み込まれ得る、有形の非一時的プロセッサ可読記憶媒体および/またはコンピュータ可読媒体上のコードおよび/または命令の、1つまたは任意の組合せまたはセットとして存在し得る。

開示した実施形態の前述の説明は、任意の当業者が特許請求の範囲を製作または使用することを可能にするために提供される。これらの実施形態への様々な修正は、当業者には容易に明らかであり、本明細書で定義する一般原理は、特許請求の範囲から逸脱することなく他の実施形態に適用されてよい。したがって、本発明は、本明細書で示した実施形態に限定されるものではなく、以下の特許請求の範囲、ならびに本明細書で開示する原理および新規の特徴と一致する最も広い範囲が与えられるべきである。

100 ワイヤレスメディア配信プラットフォームまたはシステム
102 スマートフォン
104 スピーカーデバイス
106 プリンタデバイス
108 モニタデバイス
110 ヘッドマウントディスプレイ(HMD)デバイス
112 デジタルカメラ
114 パーソナルコンピュータまたはデスクトップコンピュータ
116 装着型デバイス
118 ビデオカメラ
120 ワイヤレス接続
122 ワイヤレス接続
190 WiFi LAN
202 ソーススタックタスク層
204 ソースWiFi層
205 ユーザチャネル
206 シンクWiFi層
208 シンクスタックタスク層
300 WiFi Miracastプロトコルスタック
302 サービス管理モジュール
304 マルチチャネルオーディオパケッタイザモジュール
306 マルチキャストルーティングモジュール
308 接続開放モジュール
400 WiFi Miracastプロトコルスタック
402 ALMモジュール
850 シンクコンピューティングデバイス
852 コントローラモジュール
854 フローモニタ
856 フローアナライザ
858 リソースマネージャ
860 アプリケーションモジュール
862 通信モジュール
870 ワイヤレスネットワーク
880 ソースコンピューティングデバイス
882 マルチキャストデータストリーム
1000 モバイルデバイス
1001 プロセッサ
1002 内部メモリ
1004 タッチスクリーンコントローラ
1008 トランシーバ
1010 アンテナ
1012 タッチスクリーンパネル
1014 スピーカー
1016 セルラーネットワークワイヤレスモデムチップ
1018 周辺デバイス接続インターフェース
1020 ハウジング
1022 電源
1100 スピーカーユニット
1102 プロセッサ
1104 メモリ
1106 スピーカー
1108 タッチパッド
1110 トランシーバ
1112 ディスプレイ

Claims

WiFi Miracastにおけるスケーラブルデータサービス配信のための方法であって、
データサービスを受信すべきシンクコンピューティングデバイスをマルチキャストグループに、ソースコンピューティングデバイスによってグループ化するステップと、
前記データサービスのフレームをWiFi Miracastマルチキャスト送信を介して前記マルチキャストグループの中の前記シンクコンピューティングデバイスへ、前記ソースコンピューティングデバイスから送るステップと、
すべてのマルチキャストグループメンバー用のエラーログが受信されているかどうかを、前記ソースコンピューティングデバイスによって決定するステップと、
すべてのマルチキャストグループメンバー用のエラーログが受信されていないという決定に応答して、欠落エラーログに関連する任意のグループメンバーをユニキャストグループに、前記ソースコンピューティングデバイスによって追加するステップと
を備える方法。
任意のマルチキャストグループメンバーにとってのチャネル性能が許容できないことを受信エラーログが示すかどうかを、前記ソースコンピューティングデバイスによって決定するステップと、
そのようなマルチキャストグループメンバーにとってのチャネル性能が許容できないことを前記受信エラーログが示すという決定に応答して、許容できないチャネル性能に関連する任意のマルチキャストグループメンバーを前記ユニキャストグループに、前記ソースコンピューティングデバイスによって追加するステップと
をさらに備える、請求項1に記載の方法。
任意のユニキャストグループメンバーにとってのチャネル性能が許容できることを受信エラーログが示すかどうかを、前記ソースコンピューティングデバイスによって決定するステップと、
そのようなユニキャストグループメンバーにとってのチャネル性能が許容できることを前記受信エラーログが示すという決定に応答して、許容できるチャネル性能に関連する任意のグループメンバーを前記ユニキャストグループから、前記ソースコンピューティングデバイスによって除去するステップと
をさらに備える、請求項1に記載の方法。
任意のマルチキャストグループメンバー用のチャネルのチャネル状態が許容できないことを受信エラーログが示すかどうかを、前記ソースコンピューティングデバイスによって決定するステップと、
そのマルチキャストグループメンバーにとっての前記チャネル状態が許容できないことを受信エラーログが示すという決定に応答して、そのようなマルチキャストグループメンバーに対して前記チャネルを解放かつ/または前記データサービスを格下げするステップと
をさらに備える、請求項1に記載の方法。
チャネル帯域幅が前記ユニキャストグループの中のすべてのグループメンバーへのユニキャスト送信にとって利用可能であるかどうかを、前記ソースコンピューティングデバイスによって決定するステップと、
前記チャネル帯域幅が前記ユニキャストグループの中のすべてのグループメンバーへのユニキャスト送信にとって利用可能であるとは限らないという決定に応答して、チャネルを解放かつ/または前記データサービスを格下げするステップと
をさらに備える、請求項1に記載の方法。
前記チャネル帯域幅が前記ユニキャストグループの中のすべてのグループメンバーへのユニキャスト送信にとって利用可能であるという決定に応答して、前記データサービスの次のフレームの送信のための時間に到達しているかどうかを、前記ソースコンピューティングデバイスによって決定するステップと、
前記データサービスの前記フレームをそれぞれのWiFi Miracastユニキャスト送信を介して前記ユニキャストグループの中の前記シンクコンピューティングデバイスへ、前記ソースコンピューティングデバイスから再送信するステップと
をさらに備える、請求項5に記載の方法。
前記チャネル帯域幅が前記ユニキャストグループの中のすべてのグループメンバーへのユニキャスト送信にとって利用可能であるという決定に応答して、前記データサービスの次のフレームを、WiFi Miracastマルチキャスト送信を介して前記マルチキャストグループの中の前記シンクコンピューティングデバイスへ、またそれぞれのWiFi Miracastユニキャスト送信を介して前記ユニキャストグループの中の前記シンクコンピューティングデバイスへ、前記ソースコンピューティングデバイスから送るステップ
をさらに備える、請求項5に記載の方法。
エラーログを前記ソースコンピューティングデバイスへ送るように前記シンクコンピューティングデバイスに指示する要求を、前記ソースコンピューティングデバイスから前記シンクコンピューティングデバイスへ送るステップ
をさらに備える、請求項1に記載の方法。
ソースコンピューティングデバイスであって、
WiFiトランシーバと、
前記WiFiトランシーバに結合されたプロセッサとを備え、前記プロセッサが、動作を実行するようにプロセッサ実行可能命令を用いて構成され、前記動作が、
データサービスを受信すべきシンクコンピューティングデバイスをマルチキャストグループにグループ化することと、
前記データサービスのフレームを前記WiFiトランシーバからWiFi Miracastマルチキャスト送信を介して前記マルチキャストグループの中の前記シンクコンピューティングデバイスへ送ることと、
すべてのマルチキャストグループメンバー用のエラーログが前記WiFiトランシーバを介して受信されているかどうかを決定することと、
すべてのマルチキャストグループメンバー用のエラーログが受信されていないという決定に応答して、欠落エラーログに関連する任意のグループメンバーをユニキャストグループに追加することと
を備える、ソースコンピューティングデバイス。
前記プロセッサが、
任意のマルチキャストグループメンバーにとってのチャネル性能が許容できないことを受信エラーログが示すかどうかを決定することと、
そのようなマルチキャストグループメンバーにとってのチャネル性能が許容できないことを前記受信エラーログが示すという決定に応答して、許容できないチャネル性能に関連する任意のマルチキャストグループメンバーを前記ユニキャストグループに追加することと
をさらに備える動作を実行するようにプロセッサ実行可能命令を用いて構成される、請求項9に記載のソースコンピューティングデバイス。
前記プロセッサが、
任意のユニキャストグループメンバーにとってのチャネル性能が許容できることを受信エラーログが示すかどうかを決定することと、
そのようなユニキャストグループメンバーにとってのチャネル性能が許容できることを前記受信エラーログが示すという決定に応答して、許容できるチャネル性能に関連する任意のユニキャストグループメンバーを前記ユニキャストグループから除去することと
をさらに備える動作を実行するようにプロセッサ実行可能命令を用いて構成される、請求項9に記載のソースコンピューティングデバイス。
前記プロセッサが、
任意のマルチキャストグループメンバー用のチャネルのチャネル状態が許容できないことを受信エラーログが示すかどうかを決定することと、
そのマルチキャストグループメンバーにとっての前記チャネル状態が許容できないことを受信エラーログが示すという決定に応答して、そのようなマルチキャストグループメンバーに対して前記チャネルを解放かつ/または前記データサービスを格下げすることと
をさらに備える動作を実行するようにプロセッサ実行可能命令を用いて構成される、請求項9に記載のソースコンピューティングデバイス。
前記プロセッサが、
チャネル帯域幅が前記ユニキャストグループの中のすべてのグループメンバーへのユニキャスト送信にとって利用可能であるかどうかを決定することと、
前記チャネル帯域幅が前記ユニキャストグループの中のすべてのグループメンバーへのユニキャスト送信にとって利用可能であるとは限らないという決定に応答して、チャネルを解放かつ/または前記データサービスを格下げすることと
をさらに備える動作を実行するようにプロセッサ実行可能命令を用いて構成される、請求項9に記載のソースコンピューティングデバイス。
前記プロセッサが、
前記チャネル帯域幅が前記ユニキャストグループの中のすべてのグループメンバーへのユニキャスト送信にとって利用可能であるという決定に応答して、前記データサービスの次のフレームの送信のための時間に到達しているかどうかを決定することと、
前記データサービスの前記フレームを前記WiFiトランシーバからそれぞれのWiFi Miracastユニキャスト送信を介して前記ユニキャストグループの中の前記シンクコンピューティングデバイスへ再送信することと
をさらに備える動作を実行するようにプロセッサ実行可能命令を用いて構成される、請求項13に記載のソースコンピューティングデバイス。
前記プロセッサが、
前記チャネル帯域幅が前記ユニキャストグループの中のすべてのグループメンバーへのユニキャスト送信にとって利用可能であるという決定に応答して、前記データサービスの次のフレームを、WiFi Miracastマルチキャスト送信を介して前記マルチキャストグループの中の前記シンクコンピューティングデバイスへ、またそれぞれのWiFi Miracastユニキャスト送信を介して前記ユニキャストグループの中の前記シンクコンピューティングデバイスへ、前記WiFiトランシーバを介して送ること
をさらに備える動作を実行するようにプロセッサ実行可能命令を用いて構成される、請求項13に記載のソースコンピューティングデバイス。
前記プロセッサが、
エラーログを前記ソースコンピューティングデバイスへ送るように前記シンクコンピューティングデバイスに指示する要求を、前記WiFiトランシーバを介して前記シンクコンピューティングデバイスへ送ること
をさらに備える動作を実行するようにプロセッサ実行可能命令を用いて構成される、請求項9に記載のソースコンピューティングデバイス。
ソースコンピューティングデバイスのプロセッサに動作を実行させるように構成されたプロセッサ実行可能命令を記憶した非一時的プロセッサ可読記憶媒体であって、前記動作が、
データサービスを受信すべきシンクコンピューティングデバイスをマルチキャストグループにグループ化することと、
前記データサービスのフレームをWiFi Miracastマルチキャスト送信を介して前記マルチキャストグループの中の前記シンクコンピューティングデバイスへ送ることと、
すべてのマルチキャストグループメンバー用のエラーログが受信されているかどうかを決定することと、
すべてのマルチキャストグループメンバー用のエラーログが受信されていないという決定に応答して、欠落エラーログに関連する任意のグループメンバーをユニキャストグループに追加することと
を備える、非一時的プロセッサ可読記憶媒体。
前記記憶されたプロセッサ実行可能命令が、ソースコンピューティングデバイスのプロセッサに、
任意のマルチキャストグループメンバーにとってのチャネル性能が許容できないことを受信エラーログが示すかどうかを決定することと、
そのようなマルチキャストグループメンバーにとってのチャネル性能が許容できないことを前記受信エラーログが示すという決定に応答して、許容できないチャネル性能に関連する任意のマルチキャストグループメンバーを前記ユニキャストグループに追加することと
をさらに備える動作を実行させるように構成される、請求項17に記載の非一時的プロセッサ可読記憶媒体。
前記記憶されたプロセッサ実行可能命令が、ソースコンピューティングデバイスのプロセッサに、
任意のユニキャストグループメンバーにとってのチャネル性能が許容できることを受信エラーログが示すかどうかを決定することと、
そのようなユニキャストグループメンバーにとってのチャネル性能が許容できることを前記受信エラーログが示すという決定に応答して、許容できるチャネル性能に関連する任意のユニキャストグループメンバーを前記ユニキャストグループから除去することと
をさらに備える動作を実行させるように構成される、請求項17に記載の非一時的プロセッサ可読記憶媒体。
前記記憶されたプロセッサ実行可能命令が、ソースコンピューティングデバイスのプロセッサに、
任意のマルチキャストグループメンバー用のチャネルのチャネル状態が許容できないことを受信エラーログが示すかどうかを決定することと、
そのマルチキャストグループメンバーにとっての前記チャネル状態が許容できないことを受信エラーログが示すという決定に応答して、そのようなマルチキャストグループメンバーに対して前記チャネルを解放かつ/または前記データサービスを格下げすることと
をさらに備える動作を実行させるように構成される、請求項17に記載の非一時的プロセッサ可読記憶媒体。
前記記憶されたプロセッサ実行可能命令が、ソースコンピューティングデバイスのプロセッサに、
チャネル帯域幅が前記ユニキャストグループの中のすべてのグループメンバーへのユニキャスト送信にとって利用可能であるかどうかを決定することと、
前記チャネル帯域幅が前記ユニキャストグループの中のすべてのグループメンバーへのユニキャスト送信にとって利用可能であるとは限らないという決定に応答して、チャネルを解放かつ/または前記データサービスを格下げすることと
をさらに備える動作を実行させるように構成される、請求項17に記載の非一時的プロセッサ可読記憶媒体。
前記記憶されたプロセッサ実行可能命令が、ソースコンピューティングデバイスのプロセッサに、
前記チャネル帯域幅が前記ユニキャストグループの中のすべてのグループメンバーへのユニキャスト送信にとって利用可能であるという決定に応答して、前記データサービスの次のフレームの送信のための時間に到達しているかどうかを決定することと、
前記データサービスの前記フレームをそれぞれのWiFi Miracastユニキャスト送信を介して前記ユニキャストグループの中の前記シンクコンピューティングデバイスへ再送信することと
をさらに備える動作を実行させるように構成される、請求項21に記載の非一時的プロセッサ可読記憶媒体。
前記記憶されたプロセッサ実行可能命令が、ソースコンピューティングデバイスのプロセッサに、
前記チャネル帯域幅が前記ユニキャストグループの中のすべてのグループメンバーへのユニキャスト送信にとって利用可能であるという決定に応答して、前記データサービスの次のフレームを、WiFi Miracastマルチキャスト送信を介して前記マルチキャストグループの中の前記シンクコンピューティングデバイスへ、またそれぞれのWiFi Miracastユニキャスト送信を介して前記ユニキャストグループの中の前記シンクコンピューティングデバイスへ送ること
をさらに備える動作を実行させるように構成される、請求項21に記載の非一時的プロセッサ可読記憶媒体。
前記記憶されたプロセッサ実行可能命令が、ソースコンピューティングデバイスのプロセッサに、
エラーログを前記ソースコンピューティングデバイスへ送るように前記シンクコンピューティングデバイスに指示する要求を、前記シンクコンピューティングデバイスへ送ること
をさらに備える動作を実行させるように構成される、請求項17に記載の非一時的プロセッサ可読記憶媒体。
ソースコンピューティングデバイスであって、
データサービスを受信すべきシンクコンピューティングデバイスをマルチキャストグループにグループ化するための手段と、
前記データサービスのフレームをWiFi Miracastマルチキャスト送信を介して前記マルチキャストグループの中の前記シンクコンピューティングデバイスへ送るための手段と、
すべてのマルチキャストグループメンバー用のエラーログが受信されているかどうかを決定するための手段と、
すべてのマルチキャストグループメンバー用のエラーログが受信されていないという決定に応答して、欠落エラーログに関連する任意のグループメンバーをユニキャストグループに追加するための手段と
を備えるソースコンピューティングデバイス。
任意のマルチキャストグループメンバーにとってのチャネル性能が許容できないことを受信エラーログが示すかどうかを決定するための手段と、
そのようなマルチキャストグループメンバーにとってのチャネル性能が許容できないことを前記受信エラーログが示すという決定に応答して、許容できないチャネル性能に関連する任意のマルチキャストグループメンバーを前記ユニキャストグループに追加するための手段と
をさらに備える、請求項25に記載のソースコンピューティングデバイス。
任意のユニキャストグループメンバーにとってのチャネル性能が許容できることを受信エラーログが示すかどうかを決定するための手段と、
そのようなユニキャストグループメンバーにとってのチャネル性能が許容できることを前記受信エラーログが示すという決定に応答して、許容できるチャネル性能に関連する任意のユニキャストグループメンバーを前記ユニキャストグループから除去するための手段と
をさらに備える、請求項25に記載のソースコンピューティングデバイス。
任意のマルチキャストグループメンバー用のチャネルのチャネル状態が許容できないことを受信エラーログが示すかどうかを決定するための手段と、
そのマルチキャストグループメンバーにとっての前記チャネル状態が許容できないことを受信エラーログが示すという決定に応答して、そのようなマルチキャストグループメンバーに対して前記チャネルを解放かつ/または前記データサービスを格下げするための手段と
をさらに備える、請求項25に記載のソースコンピューティングデバイス。
チャネル帯域幅が前記ユニキャストグループの中のすべてのグループメンバーへのユニキャスト送信にとって利用可能であるかどうかを決定するための手段と、
前記チャネル帯域幅が前記ユニキャストグループの中のすべてのグループメンバーへのユニキャスト送信にとって利用可能であるとは限らないという決定に応答して、チャネルを解放かつ/または前記データサービスを格下げするための手段と
をさらに備える、請求項25に記載のソースコンピューティングデバイス。
エラーログを前記ソースコンピューティングデバイスへ送るように前記シンクコンピューティングデバイスに指示する要求を、前記シンクコンピューティングデバイスへ送るための手段
をさらに備える、請求項25に記載のソースコンピューティングデバイス。