(57)【要約】【課題】適時にマルチユーザ通信を行うこと。【解決手段】通信装置は、継続的に通信装置に対する送信対象データが発生する動作状態で他の装置が動作しているかを判定し、複数の他の装置がその動作状態で動作している場合に、複数の他の装置からの複数の信号を、少なくとも一部の期間がオーバーラップした状態で受信するマルチユーザ通信を行うことを決定し、マルチユーザ通信を行うことを決定したことに応じて、マルチユーザ通信を行わせるために複数の他の装置を制御する。【選択図】  図１
2018195884.tif 000002
【特許請求の範囲】
【請求項１】
通信装置であって、
継続的に前記通信装置に対する送信対象データが発生する動作状態で他の装置が動作しているかを判定する判定手段と、
複数の他の装置が前記動作状態で動作している場合に、当該複数の他の装置からの複数の信号を、少なくとも一部の期間がオーバーラップした状態で受信するマルチユーザ通信を行うことを決定する決定手段と、
前記決定手段が前記マルチユーザ通信を行うことを決定したことに応じて、前記マルチユーザ通信を行わせるために前記複数の他の装置を制御する制御手段と、
を有することを特徴とする通信装置。
【請求項２】
前記判定手段は、オーディオ・ビデオを前記通信装置に再生させるためにオーディオ・ビデオ信号を前記通信装置に継続的に送信する状態で他の装置が動作している場合に、当該他の装置が前記動作状態で動作していると判定する、
ことを特徴とする請求項１に記載の通信装置。
【請求項３】
前記判定手段は、前記通信装置に再生させているオーディオ・ビデオが一時停止された場合に、当該他の装置が前記動作状態で動作していないと判定する、
ことを特徴とする請求項１又は２に記載の通信装置。
【請求項４】
前記判定手段は、ＲＴＳＰ（Ｒｅａｌ  Ｔｉｍｅ  Ｓｔｒｅａｍｉｎｇ  Ｐｒｏｔｏｃｏｌ）の状態または前記通信装置におけるオーディオ・ビデオ信号の復号の状態に基づいて、他の装置が前記動作状態で動作しているか否かを判定する、
ことを特徴とする請求項２又は３に記載の通信装置。
【請求項５】
前記決定手段は、前記マルチユーザ通信が行われている状態において、前記動作状態で動作する他の装置が１つになった場合に、前記動作状態で動作しなくなった他の装置との接続が確立されている状態であっても、当該マルチユーザ通信を停止することを決定する、
ことを特徴とする請求項１から４のいずれか１項に記載の通信装置。
【請求項６】
前記決定手段は、他の装置が前記動作状態で動作している場合、当該他の装置のバッファ状態報告によらずに、前記決定を行う、
ことを特徴とする請求項１から５のいずれか１項に記載の通信装置。
【請求項７】
前記制御手段は、前記複数の他の装置に対して、応答の形式で信号を送信させるためのフレームを送信することによって、前記複数の他の装置に前記マルチユーザ通信を行わせる、
ことを特徴とする請求項１から６のいずれか１項に記載の通信装置。
【請求項８】
前記フレームは、ＩＥＥＥ８０２．１１ａｘ規格におけるトリガフレームである、
ことを特徴とする請求項７に記載の通信装置。
【請求項９】
通信装置が実行する方法であって、
継続的に前記通信装置に対する送信対象データが発生する動作状態で他の装置が動作しているかを判定する判定工程と、
複数の他の装置が前記動作状態で動作している場合に、当該複数の他の装置からの複数の信号を、少なくとも一部の期間がオーバーラップした状態で受信するマルチユーザ通信を行うことを決定する決定工程と、
前記決定工程によって前記マルチユーザ通信を行うことが決定されたことに応じて、前記マルチユーザ通信を行わせるために前記複数の他の装置を制御する制御工程と、
を有することを特徴とする方法。
【請求項１０】
通信装置に備えられたコンピュータに、
継続的に前記通信装置に対する送信対象データが発生する動作状態で他の装置が動作しているかを判定させ、
複数の他の装置が前記動作状態で動作している場合に、当該複数の他の装置からの複数の信号を、少なくとも一部の期間がオーバーラップした状態で受信するマルチユーザ通信を行うことを決定させ、
前記マルチユーザ通信を行うことを決定したことに応じて、前記マルチユーザ通信を行わせるために前記複数の他の装置を制御させる、
ためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、マルチユーザ通信における通信制御技術に関する。
【背景技術】
【０００２】
近年、無線媒体の有効利用を目指す無線ＬＡＮの規格として、ＩＥＥＥ８０２．１１ａｘ規格がドラフト規格として発行されており、本規格では、複数の端末からの１つのアクセスポイントに対する信号の同時送信を規定している。以下では、この通信のことを、ＵＬ  ＭＵ（Ｕｐｌｉｎｋ  Ｍｕｌｔｉ−Ｕｓｅｒ）通信と呼ぶ。ＩＥＥＥ８０２．１１ａｘ規格では、ＵＬ  ＭＵ通信について、アクセスポイントがＭＵ−ＲＴＳを送信してＣＴＳを受信した後に、ＴＦ（トリガフレーム）を送信し、ＵＬ  ＭＵ  ＰＰＤＵを受信し、Ａｃｋを送信することを規定している。なお、ＴＦは、端末に信号の送信を行わせるための信号であり、複数の端末が、ＴＦに応答する形式で信号（ＵＬ  ＭＵ  ＰＰＤＵ）を送信するように規定されている。なお、ＰＰＤＵは、ＰＬＣＰ  Ｐｒｏｔｏｃｏｌ  Ｄａｔａ  Ｕｎｉｔの頭字語であり、ＰＬＣＰは、Ｐｈｙｓｉｃａｌ  Ｌａｙｅｒ  Ｃｏｎｖｅｒｇｅｎｃｅ  Ｐｒｏｔｏｃｏｌの頭字語である。また、ＩＥＥＥ８０２．１１ａｘ規格では、端末に送信データがどの程度バッファリングされているかを確認するためのバッファステータスレポート（ＢＳＲ）を端末がアクセスポイントへ送信することを規定している。上述の各手順によれば、ＩＥＥＥ  ８０２．１１ａｘに準拠していない端末からの信号とＭＵ信号とが衝突することを回避し、さらに、ＩＥＥＥ  ８０２．１１ａｘに準拠する各端末に対して適切にリソースユニット（ＲＵ）を割り当てることが可能となる。
【０００３】
また、特許文献１には、アクセスポイントが、端末との間で送受信されるデータフレームの平均データサイズが一定値を超える状態が所定時間継続した場合に、通信制御を、分散制御から集中制御に切り替えることが記載されている。これによれば、衝突が発生する確率が高い環境において、ある装置が信号を送信するタイミングで、他の装置が信号を送信してしまうことを防ぐことが可能となる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００３−１９８５６４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
規格上、ＵＬ  ＭＵ通信を実行するべき端末の選択や、ＵＬ  ＭＵ通信を実行すべき条件についての規定は存在しない。しかしながら、ＵＬ  ＭＵ通信を適時に実行できないと、無線リソースを十分に効率的に使用することができず、また、多数の端末が自律的に送信した信号が互いに干渉してしまいうる。また、特許文献１に記載の技術は、干渉を防ぐことができるが、時間ごとに、通信可能なのは１つの端末のみであるような制御を行うため、マルチユーザ通信の効果的な適用ができないという課題があった。
【０００６】
本発明は上記課題に鑑みなされたものであり、適時にマルチユーザ通信を行うための通信制御を提供することを目的とする。
【課題を解決するための手段】
【０００７】
本発明の一実施形態に係る通信装置は、継続的に前記通信装置に対する送信対象データが発生する動作状態で他の装置が動作しているかを判定する判定手段と、複数の他の装置が前記動作状態で動作している場合に、当該複数の他の装置からの複数の信号を、少なくとも一部の期間がオーバーラップした状態で受信するマルチユーザ通信を行うことを決定する決定手段と、前記決定手段が前記マルチユーザ通信を行うことを決定したことに応じて、前記マルチユーザ通信を行わせるために前記複数の他の装置を制御する制御手段と、を有する。
【発明の効果】
【０００８】
本発明によれば、適時にマルチユーザ通信を行うことが可能となる。
【図面の簡単な説明】
【０００９】
【図１】無線通信システムの構成例を示す図である。
【図２】通信装置のハードウェア構成例を示す図である。
【図３】通信装置の機能構成例を示す図である。
【図４】トリガフレームの構成を示す図である。
【図５】通信装置が実行する処理の流れの例を示すフローチャートである。
【図６】無線通信システムで実行される処理の流れの第１の例を示す図。
【図７】無線通信システムで実行される処理の流れの第２の例を示す図。
【図８】無線通信システムで実行される処理の流れの第３の例を示す図。
【発明を実施するための形態】
【００１０】
以下、図面を参照しながら本発明の実施の形態について説明する。
【００１１】
（システム構成）
図１は、本実施形態に係る無線通信ネットワーク１００の構成例を示す図である。図１の無線通信ネットワーク１００は、一例として、Ｗｉ−Ｆｉ（登録商標）  ＣＥＲＴＩＦＩＥＤ  Ｍｉｒａｃａｓｔ等の規格に従って、複数の通信装置が、１つの別の通信装置に対してオーディオとビデオとの少なくともいずれかを含んだデータを送信するシステムを示している。ここで、動画データの送信側の通信装置１０２〜１０４をソース（Ｓｏｕｒｃｅ）装置、受信側の通信装置１０１をシンク（Ｓｉｎｋ）装置と呼ぶ。なお、通信装置１０１は、Ｗｉ−Ｆｉ（登録商標）  Ｐ２Ｐ（Ｗｉ−Ｆｉ  Ｄｉｒｅｃｔ）のグループオーナー（ＧＯ）である。ただしこれに限られず、通信装置１０１は、ＩＥＥＥ８０２．１１規格シリーズに準拠したアクセスポイントであってもよい。通信装置１０１は、後述の制御を実行する装置である。また、シンク装置である通信装置１０１は、一例において、受信した動画データを再生するための、テレビ、ディスプレイ、プロジェクタ等のビデオ再生装置やスピーカといったオーディオ再生装置を含み、又はそれらの再生装置へ信号を出力する機能を有する。また、ソース装置である通信装置１０２〜１０４は、カメラやビデオカメラ等の撮像装置、マイク等の録音装置、又は、スキャナ等の画像入力装置としての機能を有しうる。なお、通信装置１０２〜１０４は、ハードディスク装置やメモリ装置などの記憶装置であってもよいし、パーソナルコンピュータ（ＰＣ）やスマートフォンなどの情報処理装置であってもよい。
【００１２】
（装置構成）
図２は、本実施形態に係るシンク装置である通信装置１０１のハードウェア構成例を示す図である。なお、ソース装置である通信装置１０２〜１０４についても同様の構成を有しうるが、ここでは説明しない。通信装置１０１は、そのハードウェア構成として、例えば、記憶部２０１、制御部２０２、機能部２０３、入力部２０４、出力部２０５、通信部２０６及びアンテナ２０７を含む。
【００１３】
記憶部２０１は、ＲＯＭ、ＲＡＭの両方、または、それらのいずれか一方により構成され、後述する各種動作を行うためのプログラムや、無線通信のための通信パラメータ等の各種情報を記憶する。ここで、ＲＯＭは、Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙの頭字語であり、ＲＡＭは、Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙの頭字語である。なお、記憶部２０１として、ＲＯＭ、ＲＡＭ等のメモリの他に、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＤＶＤなどの記憶媒体が用いられてもよい。また、記憶部２０１は、複数のメモリ等によって構成されてもよい。
【００１４】
制御部２０２は、ＣＰＵ、または、ＭＰＵにより構成され、記憶部２０１に記憶されたプログラムを実行することにより、通信装置１０１全体を制御する。ここで、ＣＰＵはＣｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔの頭字語であり、ＭＰＵはＭｉｃｒｏ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔの頭字語である。なお、制御部２０２は、記憶部２０１に記憶されたプログラムとＯＳとの協働により通信装置１０１全体を制御するようにしてもよい。ここで、ＯＳはＯｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍの頭字語である。また、制御部２０２は、マルチコア等の複数のプロセッサによって構成されてもよい。また、制御部２０２として、ＦＰＧＡ（フィールドプログラマブルゲートアレイ）、ＤＳＰ（デジタルシグナルプロセッサ）、ＡＳＩＣ（特定用途向け集積回路）等が用いられてもよい。また、制御部２０２は、機能部２０３を制御して、アクセスポイント機能、撮像や印刷、映像表示機能や音声再生機能を含んだ投影等の所定の処理を実行する。
【００１５】
機能部２０３は、通信装置１０１が所定の処理を実行するためのハードウェアである。例えば、通信装置１０１が、ディスプレイ機能やプロジェクタ機能を有する場合、機能部２０３は画像復号機能や、必要に応じて投影機能を有する。通信装置１０１が、カメラ機能を有する場合、機能部２０３は、撮像処理や画像符号化を行う機能を有する。また、例えば、通信装置１０１が、プリンタ機能を有する場合、機能部２０３は印刷処理機能を有する。機能部２０３が処理するデータは、記憶部２０１に記憶されているデータであってもよいし、後述する通信部２０６を介して他の装置と通信したデータであってもよい。
【００１６】
入力部２０４は、ユーザからの各種操作の受付を行う。出力部２０５は、ユーザに対して各種出力を行う。ここで、出力部２０５による出力とは、画面上への表示や、スピーカによる音声出力、振動出力等の少なくとも１つを含む。なお、タッチパネルのように入力部２０４と出力部２０５の両方を１つのモジュールで実現するようにしてもよい。
【００１７】
通信部２０６は、（Ｗｉ−Ｆｉ規格等の）ＩＥＥＥ８０２．１１シリーズに準拠した無線通信の制御や、ＩＰ通信の制御を行う。ＩＰはＩｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌの頭字語である。また、通信部２０６はアンテナ２０７を制御して、無線通信のための無線信号の送受信を行う。通信装置１０１は通信部２０６を介して、画像データや文書データ、映像データ等のコンテンツを他の通信装置との間で通信することができる。
【００１８】
図３は、通信装置１０１の機能構成例を示す図である。通信装置１０１は、例示の機能構成おいて、通信制御部３０１、動作状態判定部３０２、及びＭＵ通信制御部３０３を有する。通信制御部３０１は、通信装置１０１が行うべき通信制御を実行する。例えば、複数の他の装置との間での上りリンク／下りリンクの、シングルユーザ／マルチユーザによる通信を可能とするための各種制御を実行する。動作状態判定部３０２は、通信装置１０１の通信相手装置である他の装置の動作状態を判定する。動作状態判定部３０２は、例えば、他の装置がストリーミングデータの送信中である状態や送信停止中である状態等の、例えばバッファの状態によらず送信対象データが定常的に発生する状態であるか否かの判定を行う。ＭＵ通信制御部３０３は、動作状態判定部３０２による判定結果に基づいて、複数の他の装置との間で通信を行う場合に、マルチユーザ通信によって少なくとも一部の期間がオーバーラップした形式でそれらの通信を実行するかを決定する。そして、ＭＵ通信制御部３０３は、マルチユーザ通信を実行すると決定した場合に、マルチユーザ通信のための通信制御を行うように通信制御部３０１を制御する。
【００１９】
図４は、通信装置１０１が、他の通信装置１０２〜１０４に対して、上りリンクマルチユーザ（ＵＬ  ＭＵ）通信を実行させるためのトリガフレーム（ＴＦ）の構造を示す。ここでは、ＩＥＥＥ８０２．１１ａｘ規格において規定されているフレーム構造のうち、以下で説明する特徴に関連する部分についてのみ、説明を行う。Ｆｒａｍｅ  Ｃｏｎｔｒｏｌフィールド４０１とＤｕｒａｉｏｎフィールド４０２は、ＩＥＥＥ８０２．１１規格シリーズのフレーム形式に準じた構成を有し、従来の規格と同様の情報が格納される。ＲＡフィールド４０３は、このＴＦの宛先の装置（通信装置１０２〜１０４）のアドレスを示すＲｅｃｅｉｖｅｒ  Ａｄｄｒｅｓｓが格納されるフィールドであり、このフィールドによって複数のアドレス宛先が指定される。ＴＡフィールド４０４は、このＴＦの送信元の装置（通信装置１０１）のアドレスを示すＴｒａｎｓｍｉｔｔｅｒ  Ａｄｄｒｅｓｓが格納されるフィールドである。Ｃｏｍｍｏｎ  Ｉｎｆｏフィールド４０５は、このＴＦに共通の情報を示すもので、少なくとも、このＴＦの用途を示すトリガタイプの情報を含む。トリガタイプは、例えばこのＴＦがデータ用である場合「Ｂａｓｉｃ」に設定される。Ｐｅｒ  Ｕｓｅｒ  Ｉｎｆｏフィールド４０６は、このＴＦを受信する装置個別の情報が格納されるフィールドである。Ｕｓｅｒ  ＩＤフィールド４１１は、ＡＩＤ（Ａｓｓｏｃｉａｔｉｏｎ  Ｉｄｅｎｔｉｆｉｅｒ）などの相手装置を指定する識別子が格納されるフィールドである。ＲＵ  Ａｌｌｏｃａｔｉｏｎフィールド４１２は、ＲＵの割り当てを示す情報として、ＯＦＤＭＡのチャネルのインデックスが格納されるフィールドである。ＭＣＳフィールド４１３は、変調及び符号化方式（Ｍｏｄｕｌａｔｉｏｎ  ａｎｄ  Ｃｏｄｉｎｇ  Ｓｃｈｅｍｅ）を指定する情報が格納されるフィールドである。
【００２０】
（処理の流れ）
以下では、上述の構成を有する通信装置１０１が実行する処理の流れの例について図５を用いて説明する。本処理は、例えば通信装置１０１のユーザ操作に応じて又は他の通信装置１０２〜１０４のいずれかからオーディオ・ビデオ信号の伝送を開始することを指示する信号を受信したことに応じて、所定のアプリケーションを起動することにより開始される。なお、本実施形態及び添付の特許請求の範囲において、「オーディオ・ビデオ」は、オーディオとビデオとの少なくともいずれかに関し、オーディオのみ、又はビデオのみの概念を含む。また、本処理は、制御部２０２が、記憶部２０１に記憶されたプログラムを実行することによって実現されうる。
【００２１】
本処理において、通信装置１０１は、まずシンク装置としての動作を開始し（Ｓ５０１）、Ｗｉ−Ｆｉ  Ｐ２Ｐのグループオーナー（ＧＯ）としての動作を開始する（Ｓ５０２）。そして、通信装置１０１は、新たなソース装置との接続処理が行われたかを判定する（Ｓ５０３）。通信装置１０１は、新たなソース装置との接続処理が行われた場合（Ｓ５０３でＹＥＳ）、そのソース装置から送信されるＡＶ（オーディオ・ビデオ）について、能力情報の交換と、実際の通信で用いるべき符号化方式／解像度の設定とを行う。この処理には、例えば、ＲＴＳＰのＧＥＴ＿ＰＡＲＡＭＥＴＥＲとＳＥＴ＿ＰＡＲＡＭＥＴＥＲとが使用される。ここで、ＲＴＳＰは、Ｒｅａｌ  Ｔｉｍｅ  Ｓｔｒｅａｍｉｎｇ  Ｐｒｏｔｏｃｏｌの頭字語であり、ストリーミングデータの配信について、マルチメディアデータの再生、停止等の制御を行うことを可能とするプロトコルのことを指す。この処理において、通信装置１０１は、例えば、ソース装置からのＡＶデータの符号化方式が固定ビットレートであることを認識することができ、これにより、トランスポートレートが８Ｍｂｐｓ等の一定数値になることを特定することができる。通信装置１０１は、この数値を特定することによって、ソース装置にどのようなリソースユニット（ＲＵ）を割り当てるべきかを算出することができる。通信装置１０１は、このようにして取得した情報を、記憶部２０１に保持する（Ｓ５０４）。Ｓ５０４の処理によって、新たな情報が保持され又はそれまで保持していた情報が更新されるが、これらをまとめて「ＡＶ情報更新」と呼ぶ。
【００２２】
通信装置１０１は、続いて、上りリンクマルチユーザ（ＵＬ  ＭＵ）通信に対応可能で、かつ、オーディオ・ビデオをＰＬＡＹ中の、複数のソース装置と接続しているかを判定する（Ｓ５０５）。なお、ここで、ソース装置がＵＬ  ＭＵ通信に対応可能であるか否かは、ＩＥＥＥ８０２．１１規格シリーズで規定されているＭＡＣ層のフレーム形式での、ＨＴ  Ｃｏｎｔｒｏｌ  ｆｉｅｌｄの値によって判定可能である。この値には、ＩＥＥＥ８０２．１１規格シリーズで規定されている、端末管理情報のｄｏｔ１１ＵＬＭＵＯＦＤＭＡＯｐｔｉｏｎＩｍｐｌｅｍｅｎｔｅｄまたはｄｏｔ１１ＵＬＭＵＭＩＭＯＯｐｔｉｏｎＩｍｐｌｅｍｅｎｔｅｄが反映される。すなわち、通信装置１０１は、それぞれのソース装置から受信したフレームの内容を解析することにより、そのソース装置がＵＬ  ＭＵ通信に対応しているか否かを判定することができる。なお、これは一例であり、例えば所定の問い合わせを行う等の他の方法によってＵＬ  ＭＵ通信に対応可能であるかが判定されてもよい。Ｓ５０５において、上述の条件を満たすソース装置が複数存在すると判定した場合（Ｓ５０５でＹＥＳ）、通信装置１０１は、それらの複数のソース装置との間でＵＬ  ＭＵ通信を実行し（Ｓ５０６）、処理をＳ５０３へと戻す。通信装置１０１は、ＵＬ  ＭＵ通信を行う場合、ＴＦを送信して、複数のソース装置が一斉に信号を送信するように制御を行う。一方、上述の条件を満たすソース装置が１つまたは存在しないと判定した場合（Ｓ５０５でＮＯ）は、通信装置１０１は、Ｓ５０３で接続したソース装置との間で上りリンクシングルユーザ（ＵＬ  ＳＵ）通信を実行し（Ｓ５０７）、処理をＳ５０３へと戻す。
【００２３】
Ｓ５０３において、通信装置１０１は、新たなソース装置との接続処理が行われていないと判定した場合（Ｓ５０３でＮＯ）、オーディオ・ビデオ（ＡＶ）の伝送状態に変化があったか否かを判定する（Ｓ５０８）。ここで、ＡＶの伝送状態に変化があったか否かは、例えば、ＲＴＳＰによるＰＬＡＹ状態やＰＡＵＳＥ状態からの変化、オーディオ・ビデオの解像度や符号化レートの変更があったか否かに応じて判定されうる。
【００２４】
通信装置１０１は、ＡＶの伝送状態に変化があったと判定した場合（Ｓ５０８でＹＥＳ）、処理をＳ５０４へ移して、ＡＶ情報を更新し、その後、Ｓ５０５の判定を行う。例えば、２つのソース装置がＵＬ  ＭＵ通信に対応可能で、かつ、ＰＬＡＹ状態であったときに、Ｓ５０８で、これらのソース装置のうちの１つのソース装置がＰＬＡＹ状態からＰＡＵＳＥ状態へ移行したと判定されたものとする。この場合、Ｓ５０５では、ＰＬＡＹ状態のソース装置が１つのみとなるため、通信装置１０１は、それまで行われていたＵＬ  ＭＵ通信を停止し、ＵＬ  ＳＵ通信を開始するようにしうる。同様に、例えば、２つのソース装置がＵＬ  ＭＵ通信に対応可能であるが、これらの装置の一方がＰＬＡＹ状態であり他方がＰＡＵＳＥ状態であったときに、ＰＡＵＳＥ状態のソース装置がＰＬＡＹ状態へと移行したものとする。この場合、Ｓ５０５では、ＰＬＡＹ状態のソース装置が１つから２つ（複数）となるため、通信装置１０１は、それまで行われていたＵＬ  ＳＵ通信を停止し、ＵＬ  ＭＵ通信を開始するようにしうる。
【００２５】
一方、通信装置１０１は、Ｓ５０８において、ＡＶの伝送状態に変化がないと判定した場合（Ｓ５０８でＮＯ）、接続していたソース装置との間で接続が切断されたかを判定する（Ｓ５０９）。接続が切断されていない場合（Ｓ５０９でＮＯ）は、処理はＳ５０３へと戻る。一方、接続が切断された場合（Ｓ５０９でＹＥＳ）は、通信装置１０１は、続いて、全てのソース装置との接続が切断されたかを判定する（Ｓ５１０）。そして、通信装置１０１は、全てのソース装置との接続が切断された場合（Ｓ５１０でＹＥＳ）、シンク装置としての動作を停止して（Ｓ５１１）、処理を終了する。一方、一部のソース装置との接続が維持されている場合（Ｓ５１０でＮＯ）は、処理はＳ５０５へ進む。Ｓ５０５では、例えば、通信装置１０１は、２つのソース装置とＵＬ  ＭＵ通信を実行していた場合に１つのソース装置との接続が切断されると、１つのソース装置との接続のみが残ることとなるため、ＵＬ  ＭＵ通信を終了してＵＬ  ＳＵ通信を開始する。
【００２６】
なお、上述のＳ５０５又はＳ５０８では、機能部２０３の画像復号（ＣＯＤＥＣ）機能の状態変化に基づいて判定が行われてもよい。すなわち、ＲＴＳＰによる制御の有無ではなく、復号画像の符号量やその変化によって、ＡＶ伝送の有無やＡＶ伝送状態の変化が判定されうる。
【００２７】
また、上述の処理の少なくとも一部は、ハードウェアにより実現されてもよい。ハードウェアによって少なくとも一部の処理を実現する場合、例えば、所定のコンパイラを用いて、処理を実現するためのプログラムからＦＰＧＡ上に自動的に専用回路を生成することができる。また、ＦＰＧＡと同様にしてＧａｔｅ  Ａｒｒａｙ回路を形成し、ハードウェアとして少なくとも一部の機能が実現されてもよい。また、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ  Ｓｐｅｃｉｆｉｃ  Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ）によって、少なくとも一部の機能が実現されてもよい。
【００２８】
このように、本実施形態に係る通信装置１０１は、複数のＵＬ  ＭＵ通信に対応可能なソース装置がＰＬＡＹ状態である場合にＵＬ  ＭＵ通信を行うことを決定する。これによれば、通信装置１０１は、例えば、上りリンク通信が発生する確率が高い状態となったことに応じて、各ソース装置におけるバッファ状態を確認することなくＵＬ  ＭＵ通信を開始することができる。このため、不必要なバッファ状態報告がなくなり、この報告による通信の遅延も発生しなくなる。このため、ストリーミング等のリアルタイム性が高いデータに関して品質劣化を低減することができ、また、一定期間にわたって送信データが発生し続ける場合に、バッファ状態報告による無線リソースの消費を抑えることもできる。
【００２９】
なお、本実施形態では、通信装置１０１と他の通信装置１０２〜１０４とが、オーディオ・ビデオ信号の通信を行う例について説明しているが、これに限られない。すなわち、ＰＬＡＹ状態のように、通信対象データが継続的に発生する動作状態で複数の通信装置１０２〜１０４が動作している場合に、通信装置１０１が、ＵＬ  ＭＵ通信を実行するように制御を行う。このときの通信対象データはオーディオ・ビデオ信号に限られない。
【００３０】
続いて、図５のような処理が実行される場合のシステムにおける処理の流れの例について説明する。なお、以下では、通信装置１０１をシンク装置、通信装置１０２〜１０４を、それぞれソース装置Ａ〜Ｃと呼ぶ。
【００３１】
＜処理例１＞
図６に、本実施形態に係る、シンク装置と、２台のソース装置Ａ及びソース装置Ｂにおける処理の流れの例を示すシーケンス図である。本処理例では、通信装置１０１は、２台のソース装置がＲＴＳＰのＰＬＡＹ（再生）状態になったのを契機に、上りリンクマルチユーザ（ＵＬ  ＭＵ）通信を開始する。
【００３２】
本処理では、まず、シンク装置が、オーディオ・ビデオ（ＡＶ）伝送のシンク機能を開始し（Ｓ６０１）、ソース装置Ａがソース機能を開始する（Ｓ６０２）。そして、シンク装置とソース装置Ａとの間で、例えばＷｉ−Ｆｉ  Ｄｉｒｅｃｔによる直接接続のための接続手順が実行される（Ｓ６０３）。なお、ここでは、上述のように、シンク装置が、グループオーナー（ＧＯ）として動作するものとする。このとき、シンク装置とソース装置Ａとの間でＧＯネゴシエーションが行われてもよいし、ネゴシエーションを行うことなく、シンク装置がＧＯとして動作することが事前設定されていてもよい。
【００３３】
直接接続の確立後、シンク装置とソース装置Ａとの間で、ソース装置Ａからシンク装置へ送信されるＡＶ（オーディオ・ビデオ）について、能力情報の交換と、実際の通信で用いるべき符号化方式／解像度の設定とが行われる（Ｓ６０４）。シンク装置は、Ｓ６０４で取得した情報を、記憶部２０１に保持してＡＶ情報を更新する（Ｓ６０５）。そして、シンク装置とソース装置Ａは、一連のＰＬＡＹ手順を実行する（Ｓ６０６）。まず、ソース装置Ａは、ＲＴＳＰのＰＬＡＹ要求を送信し、シンク装置は、ＰＬＡＹ要求を受信した場合に、ＲＴＳＰ手順における肯定応答をソース装置Ａへ送信する。ソース装置Ａは、この肯定応答を受信したことに応じて、Ｓ６０４で決定された符号化方式で符号化されたオーディオ・ビデオ信号を、シンク装置へ送信する。シンク装置は、受信したオーディオ・ビデオ信号を、機能部２０３の復号機能を用いて復号して、動画として再生するための処理を実行する。なお、この時点では、シンク装置は、ソース装置Ａのみからオーディオ・ビデオ信号を受信することとなるため、上りリンク（ＵＬ）のシングルユーザ（ＳＵ）通信を用いて、ソース装置Ａとの間での上りリンクの通信を行う（Ｓ６０７）。なお、ＳＵ通信では、無線の送信機会において使用可能な２０／４０／８０／１６０ＭＨｚの無線帯域を１つの端末が占有する。その後、ソース装置Ｂが、シンク装置と接続する。ここで、Ｓ６０８からＳ６１２までは、Ｓ６０２からＳ６０６までの処理と同様であるため、詳細な説明については省略する。
【００３４】
Ｓ６１３において、シンク装置は、ソース装置Ａ及びソース装置Ｂの２つの装置からオーディオ・ビデオ信号を受信することとなるため、上りリンクマルチユーザ（ＵＬ  ＭＵ）通信のための制御動作を開始する。例えば、シンク装置は、ＴＦを周期的に送信するためのタイマを起動し、タイマの満了に応じて、ソース装置Ａ及びソース装置Ｂに対してＴＦをブロードキャスト送信する（Ｓ６１４）。ここで、ＴＦフレームには、図４を用いて説明したように、複数の端末にそれぞれ割り当てられる使用無線チャネル（ＲＵ  Ａｌｌｏｃａｔｉｏｎ）、及び使用すべき変調及び符号化方式（ＭＣＳ）を指定する情報が含められる。なお、使用無線チャネルを特定するＲＵは、ＩＥＥＥ８０２．１１ａｘでは、ＯＦＤＭＡ（直交周波数分割多元接続）の無線チャネルによって表現される。なお、シンク装置は、このＲＵを、Ｓ６０５及びＳ６１１において更新されたＡＶ情報に基づいて算出することができる。例えば、ソース装置Ａ及びＢの転送速度が互いに一致している場合、同じ帯域幅に対応するＲＵが、これらのソース装置Ａ及びＢのそれぞれに割り当てられる。なお、シンク装置と各ソース装置との無線媒体の状況によっては、転送速度が同じであっても、ＭＣＳとＲＵのチャネル幅とが異なりうる。例えば、通信品質が良好な状況においては、単位周波数帯域幅当たりの伝送速度が高速なＭＣＳが用いられ、相対的に少ない割り当て帯域幅によって所定の転送速度を達成することができる。一方、通信品質が良好でない状況においては、単位周波数帯域幅当たりの伝送速度が低速なＭＣＳが用いられ、上述の所定の転送速度を達成するために必要な帯域幅が大きくなる。各ソース装置は、シンク装置がＳ６１４で送信したＴＦを受信すると、そのＴＦに応答する形式で個別に指定された無線チャネル及びＭＣＳを用いて、並行して（すなわち、ＵＬ  ＭＵ通信で）、ＴＦで指定されたタイプのデータを送信する（Ｓ６１５）。なお、各ソース装置は、ＴＦを受信した直後に、送信対象データをシンク装置へ送信する。このため、各ソース装置は、時間的にオーバーラップした信号を送信することとなる。ただし、この場合、ＲＵがそれぞれオーバーラップしないように割り当てられることにより、これらの信号が干渉することなく、シンク装置は、これらの信号を別個に受信することが可能となる。なお、シンク装置は、各ソース装置からの信号を受信成功すると、肯定応答を送信する（不図示）。その後、シンク装置は、Ｓ６１３において起動したタイマの周期に基づいて、Ｓ６１４におけるＴＦの送信とＳ６１５における各ソース装置からのＵＬ  ＭＵ通信での信号の受信とを繰り返す。
【００３５】
このように、複数のソース装置から１つのシンク装置へのオーディオ・ビデオが再生される状態となったことに応じて、シンク装置は、ＵＬ  ＭＵ通信を開始する。これにより、バッファ状態の報告が行われなくても、送信対象データが継続的に発生する動作状態にソース装置がある場合に、ＵＬ  ＭＵ通信を開始することができる。この結果、バッファ状態報告の送信が不要となり、又はそのような報告を解析する前にＵＬ  ＭＵ通信を開始し、それを継続することができるため、リアルタイムデータの遅延を低く抑えることが可能となる。
【００３６】
＜処理例２＞
本処理例では、処理例１のようにして、ソース装置Ａ及びソース装置Ｂとシンク装置との間でのＵＬ  ＭＵ通信が開始された後に、１つのソース装置（ソース装置Ｂ）が動作を一時停止する場合の例について、図７を用いて説明する。本処理では、ＵＬ  ＭＵ通信（Ｓ６１５）が行われている状態で、ソース装置Ｂが、一時停止のユーザ操作を受け付けたものとする（Ｓ７０１）。この一時停止のユーザ操作が受け付けられると、シンク装置とソース装置Ｂとの間で、ＲＴＳＰにおけるＰＡＵＳＥ手順が実行される（Ｓ７０２）。そして、シンク装置は、Ｓ６０５又はＳ６１１と同様にＡＶ情報を更新する（Ｓ７０３）。このとき、シンク装置は、ＡＶ伝送におけるＰＬＡＹ状態の装置がソース装置Ａの１台のみとなったため、ＵＬ  ＭＵ制御動作を停止する（Ｓ７０４）。例えば、シンク装置は、上述の周期タイマを無効にすることにより、ＴＦの周期的な送信を停止する。これにより、ソース装置Ａからのオーディオ・ビデオ信号は、シングルユーザ通信によって行われる（Ｓ７０５）。
【００３７】
その後、ソース装置Ｂが、解像度変更のユーザ操作を受け付けたものとする（Ｓ７０６）。この場合、Ｓ６０４と同様に、シンク装置とソース装置Ｂとの間で、ＡＶ情報ネゴシエーションが実行され（Ｓ７０７）、これに基づいて、シンク装置は、ＡＶ情報を更新する（Ｓ７０８）。その後、Ｓ７０９からＳ７１２において、上述のＳ６１２からＳ６１５と同様の処理が実行される。なお、Ｓ７１０において、シンク装置は、ＵＬ  ＭＵ伝送を制御するためのＴＦ送信用の周期タイマを再起動する。なお、解像度変更に基づいて、ＵＬ  ＭＵ通信で割り当てられるＲＵの量が適応的に変更されうる。これにより、不必要に多くのリソースが割り当てられることや、必要な量のリソースが割り当てられないことを防ぐことができる。なお、シンク装置は、各ソース装置における伝送レートに応じて、ＴＦの送信間隔を適応的に制御することができる。すなわち、全体としての伝送レートが高い場合、ＴＦの送信間隔が短く設定されてもよく、また、伝送レートが低い場合にはＴＦの送信間隔が長く設定されうる。また、例えば、必要な帯域幅が非常に大きく、ＵＬ  ＭＵ通信が行われている環境下では必要量のリソースを確保できない場合などでは、シンク装置は、ソース装置Ｂの再生が再開された場合であっても、ＵＬ  ＭＵを再開しないと判定してもよい。
【００３８】
このように、本処理例では、通信装置１０１は、ソース装置のオーディオ・ビデオ伝送の一時停止や解像度変更に応じて、ＭＵ通信とＳＵ通信との切り替えや、リソース割り当てを調整する。これにより、通信装置１０１は、バッファ状態報告の送受信が行われなくても、ＵＬ  ＭＵ伝送の要否や適切な量のリソースの割り当てを行うことができる。
【００３９】
＜処理例３＞
続いて、処理例１のようにして、ソース装置Ａ及びソース装置Ｂとシンク装置との間でのＵＬ  ＭＵ通信を行っている間に、さらにソース装置Ｃが再生状態へと移行した場合の処理について、図８を用いて説明する。本処理では、ＵＬ  ＭＵ通信（Ｓ６１５）が行われている状態で、ソース装置Ｃがソース装置としての動作を開始し（Ｓ８０１）、Ｓ６０９〜Ｓ６１３と同様にして、ソース装置Ｃが、シンク装置との間でのＵＬ  ＭＵ通信に加わる（Ｓ８０２〜Ｓ８０６）。その後、シンク装置は、ソース装置Ａ及びソース装置Ｂに対してのみならず、ソース装置ＣへのＲＵ  Ａｌｌｏｃａｔｉｏｎを含めたＴＦを送信する（Ｓ８０７）。そして、シンク装置は、３台のソース装置Ａ〜Ｃから、ＵＬ  ＭＵ通信の信号を、それぞれに割り当てられた無線リソースにおいて受信する（Ｓ８０８）。その後、ソース装置Ｂが、ユーザによる切断操作を受け付けたものとする（Ｓ８０９）と、シンク装置とソース装置Ｂとの間で無線接続の切断処理が実行される（Ｓ８１０）。そして、シンク装置は、ソース装置Ｂとの間での接続が切断されたことを反映させるために、ＡＶ情報を更新する（Ｓ８１１）。そして、シンク装置は、ＵＬ  ＭＵ制御のためのタイマ間隔等、制御のための設定を更新する（Ｓ８１２）。これにより、例えば、ソース装置Ｂからの伝送がなくなったことに対応して、ＴＦ送信の繰り返し間隔が長く設定されうる。なお、同様に、Ｓ８０６において、ソース装置Ｃからの伝送が開始されたことに対応して、ＴＦ送信の繰り返し間隔が短く設定されていてもよい。その後は、ソース装置Ａ及びソース装置Ｃと、シンク装置との間でのＵＬ  ＭＵ通信が実行される（Ｓ８１３、Ｓ８１４）。
【００４０】
このように、シンク装置は、３台以上の複数のソース装置との接続や、無線接続の切断のようなＲＴＳＰに関連しない事象にも対応して、ＵＬ  ＭＵ伝送を実行するように制御することができる。これにより、様々な利用形態において、無線リソースの利用効率を高めることができる。
【００４１】
なお、上述の動作は一例であり、例えば、上述の例ではソース装置Ｂが再生の一時停止、解像度変更、又は無線接続の切断を行う場合について説明したが、他のソース装置がこれらの動作を行った場合も、同様の制御が実行されうる。また、上述の例では、オーディオ・ビデオ信号の送受信の場合について説明したが、継続的に通信装置１０１に対する送信対象データが発生する動作状態で端末が動作している間に、上述の処理を適用することができ、送受信される信号の種類は特に限定されない。どのような種類のデータが送受信される場合であっても、バッファ状態報告によらず、端末の動作状態によって上りリンクマルチユーザ通信を行うか否かが決定されることによって、無線リソースの高い利用効率を達成することができる。
【００４２】
また、上述の例では、通信装置１０１が、無線ＬＡＮのアクセスポイントの機能を実行する場合について説明したが、無線ＬＡＮ以外の構成においても、上述の議論を適用することができる。すなわち、複数の他の装置からの複数の信号を同時並行的に（すなわち、複数の信号の少なくとも一部の期間がオーバーラップして）受信可能な任意の通信装置が、そのような同時並行的な受信を行うための手順として、上述の議論を適用することができる。すなわち、任意の通信装置は、継続的にその通信装置に対する送信対象データが発生する動作状態で他の装置が動作しているかの情報を取得し、複数の他の装置がそのような動作状態で動作している場合に、同時並行的な信号の送信を行わせうる。なお、このとき、通信装置は、ＴＦ以外の信号によって、複数の他の装置に対して同時並行的な信号の送信を行わせるように制御を行ってもよい。すなわち、複数の他の装置に対して、任意の形式で、信号を送信すべきタイミングと使用すべきリソースを通知することができる限りにおいて、任意の制御が行われうる。また、上述の説明では、周波数リソースを他の装置のそれぞれに対して割り当てることで複数の他の装置からの信号を分離することを前提として説明したが、これに限られない。例えば空間リソースや符号リソース等、他の無線リソースによって複数の他の装置からの信号が分離されるように、システムが構成されてもよい。この場合であっても、複数の他の装置に対して同時に信号を送信させることによって周波数利用効率を高めることができる。
【００４３】
また、上述の例では、オーディオ・ビデオを再生中のソース装置が複数存在する場合にマルチユーザ通信を実行し、そのような装置が１つ以下である場合にはマルチユーザ通信を行わないとしたが、これに限られない。例えば、バッファ状態報告に基づいて送信対象データが所定量以上存在する装置と、オーディオ・ビデオを再生中のソース装置とが、同時に信号を送信するように制御が行われてもよい。この場合、オーディオ・ビデオを再生中のソース装置は１つであっても、マルチユーザ通信が行われうる。すなわち、通信装置は、オーディオ・ビデオを再生中等の継続的に送信対象データが発生する動作状態で動作している装置を、バッファ状態報告によらずにマルチユーザ通信を行わせる候補としておくことができる。そして、通信装置は、例えばそのような候補となる装置の他に、バッファ状態報告に基づいて送信対象データが所定量以上存在する装置が存在する場合は、これらの装置にマルチユーザ通信を行わせうる。このように、バッファ状態報告によって送信対象データが現に存在している装置と、バッファ状態報告によらずに送信対象データが発生することが予定されている装置とが混在する環境において、マルチユーザ通信を行わせることもできる。なお、動作状態に基づいてマルチユーザ通信を行う装置と、バッファ状態に基づいてマルチユーザ通信を行う装置とを、同時に通信しないようにしてもよい。すなわち、バッファ状態に基づいてマルチユーザ通信を行う装置は、バッファ状態に基づいてマルチユーザ通信を行う他の装置とのみ、マルチユーザ通信を行うようにしてもよい。同様に、動作状態に基づいてマルチユーザ通信を行う装置は、動作状態に基づいてマルチユーザ通信を行う他の装置とのみ、マルチユーザ通信を行うようにしうる。これによれば、マルチユーザ通信を実行するか否かを複数の装置に対して共通の基準を用いて判定することができるため、制御を簡素化することができる。
【００４４】
＜＜その他の実施形態＞＞
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
【符号の説明】
【００４５】
３０１：通信制御部、３０２：動作状態判定部、３０３：ＭＵ通信制御部
【図１】
2018195884.tif 000003
【図２】
2018195884.tif 000004
【図３】
2018195884.tif 000005
【図４】
2018195884.tif 000006
【図５】
2018195884.tif 000007
【図６】
2018195884.tif 000008
【図７】
2018195884.tif 000009
【図８】
2018195884.tif 000010