JP2016149648A - 通信装置、制御方法、及びプログラム - Google Patents

Abstract

【課題】チャネルの切り替えが行われることによる通信に関する品質の劣化を防ぐこと。
【解決手段】動作中に他のチャネルへ移る期間がある第１の動作モードと、動作中にその期間がない第２の動作モードとの、いずれかで動作できる通信装置は、一定期間にわたって連続的にデータ通信が行われるかを判定し、その判定の結果に基づいて、第１の動作モードと第２の動作モードとのいずれで動作するかを選択し、選択された動作モードでデータ通信を行う。
【選択図】 図３

Description

本発明は、通信制御技術に関する。

ＩＥＥＥ８０２．１１規格に代表される無線ＬＡＮによる無線通信システムが広く利用されるようになっている。無線ＬＡＮでは、多くの場合、アクセスポイント（以下、「ＡＰ」と呼ぶ。）と呼ばれる基地局が、無線ネットワークを制御する。ＡＰの電波到達範囲内に存在するとともに無線接続状態であるステーション（以下、「ＳＴＡ」と呼ぶ。）と、そのＡＰとによって無線ネットワークが構成される。ＡＰとＳＴＡとは、同じ無線チャネルを用いて通信を行う。

近年、無線ＬＡＮの高速化を図ったＩＥＥＥ８０２．１１ｎ規格の機器が広く利用されている。ＩＥＥＥ８０２．１１ｎ規格では、通信の高速化のため、従来の２０ＭＨｚの周波数帯域幅で動作するモード（以下、「ＨＴ２０モード」と呼ぶ。）だけでなく、２倍の４０ＭＨｚのチャネルモード（以下、「ＨＴ４０モード」と呼ぶ。）がサポートされる。しかし、ＨＴ４０モードが用いられる場合、ＩＥＥＥ８０２．１１ｎ規格に対応しない従来の無線装置がキャリアセンスできないため、フレームの衝突が頻発することがある。特に、２．４ＧＨｚ帯は、５ＧＨｚ帯と比較して、無線チャネルが重なり合っているため、周囲のＢＳＳの影響を受けやすい。これに対して、特許文献１には、例えば、ＡＰが接続するインターネット網の回線速度が遅い場合に、高速に通信する必要がないので周囲の無線ネットワークへの干渉が少ないＨＴ２０モードでＡＰが動作する技術が記載されている。なお、特許文献１では、インターネット網側の回線速度が速い場合には、網側の回線の速さを活かすためにＡＰがＨＴ４０モードで動作することも記載されている。また、特許文献２には、周囲の無線ネットワークとの干渉の有無に応じて、無線チャネルのチャネル幅を決定する方法が記載されている。

一方で、ＩＥＥＥ８０２．１１ｎ規格では、２．４ＧＨｚ帯のＨＴ４０モードで動作するＳＴＡに対するＯＢＳＳ（Ｏｖｅｒｌａｐｐｉｎｇ Ｂａｓｉｃ Ｓｅｒｖｉｃｅ Ｓｅｔ）スキャンが規定されている。ＯＢＳＳスキャンは、ＨＴ４０モードで動作しているＳＴＡが、定期的に周囲のネットワークを検索するものである。具体的には、ＯＢＳＳスキャンは、周囲の、８０２．１１ｎ規格に非対応の無線ネットワーク及びＨＴ４０モードを許容しない無線ネットワークを発見するために行われる。ＳＴＡは、これらの無線ネットワークが発見された場合には、参加している無線ネットワークのＡＰに対してレポートを送信する。そして、ＡＰは、必要に応じてＨＴ４０モードをサポートした無線ネットワークから、ＨＴ２０モードのみをサポートした無線ネットワークへの切り替えを行う。このＯＢＳＳスキャンは、２．４ＧＨｚ帯においてＨＴ４０モードで動作するＳＴＡにとっては実装が必須とされている。

一方で、無線ＬＡＮを利用した映像ストリーミング通信としてＷｉ−Ｆｉ Ｄｉｓｐｌａｙがある。Ｗｉ−Ｆｉ ＤｉｓｐｌａｙはＷｉ−Ｆｉ Ａｌｌｉａｎｃｅが規格化した無線ダイレクトストリーミング技術である。Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙは、映像ストリーミングを送信する側の装置をＳｏｕｒｃｅと呼び、映像ストリーミングを受信する側の装置はＳｉｎｋと呼ぶ。Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙによる映像ストリーミングは、主にＳｏｕｒｃｅ側で表示されている画面と同じ画面を、Ｓｉｎｋ側に表示する、すなわちミラーリングするために用いられる。

Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙでは、無線リンクレイヤ接続にＷｉ−Ｆｉ ＤｉｒｅｃｔまたはＴＤＬＳのいずれかを使用する。Ｗｉ−Ｆｉ Ｄｉｒｅｃｔは、ＳｉｎｋとＳｏｕｒｃｅのうちいずれか一方が、ＡＰのような基地局として動作するＰ２Ｐ Ｇｒｏｕｐ Ｏｗｎｅｒ（以下、「ＧＯ」と呼ぶ。）となる。そして、ＳｉｎｋとＳｏｕｒｃｅのうちのもう一方がＳＴＡのような端末局として動作するＰ２Ｐ Ｃｌｉｅｎｔ（以下、「Ｃｌｉｅｎｔ」と呼ぶ。）となり、ＳｉｎｋとＳｏｕｒｃｅとの間でダイレクトに映像ストリーミングが送受信される。ＴＤＬＳを使う場合には、ダイレクトリンクを確立することにより、ＡＰを介さずに映像ストリーミングを送受信することができる。

特開２０１３−１０２３４１号公報 特開２０１０−２７３３４９号公報

しかし、Ｓｉｎｋ又はＳｏｕｒｃｅが、Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙで映像伝送中に、参加中の無線ネットワークが用いる無線チャネル以外の無線チャネルへ一定期間だけ移ると、その期間、参加中の無線ネットワークにおけるデータの送受信ができなくなる。しかしながら、上述の通り、Ｓｉｎｋ及びＳｏｕｒｃｅが、２．４ＧＨｚ帯のＨＴ４０モードで動作するためにはＯＢＳＳスキャンを行う必要がある。そして、ＯＢＳＳ Ｓｃａｎは、隣接した無線チャネルの無線ネットワークを探索する必要があることから、異なる無線チャネルに一時的に移動することになる。そのため、映像ストリーミングが送受信されている場合にＯＢＳＳスキャンが実行されると、そのスキャンの間、映像データの送受信ができないため、Ｓｉｎｋ側において映像が乱れる場合があるという課題があった。また、この課題は、ＷｉＦｉ Ｄｉｓｐｌａｙに限らず、例えばリアルタイム性が求められる大容量データの送受信中にチャネルの切り替えが行われることによって、そのデータのリアルタイム性が損なわれる場合があるという課題があった。

本発明は上記課題に鑑みなされたものであり、チャネルの切り替えが行われることによる通信に関する品質の劣化を防ぐ技術を提供することを目的とする。

上記目的を達成するため、本発明による通信装置は、動作中に他のチャネルへ移る期間がある第１の動作モードと、動作中に前記期間がない第２の動作モードとの、いずれかで動作できる通信装置であって、一定期間にわたって連続的にデータ通信が行われるかを判定する判定手段と、前記判定の結果に基づいて、前記第１の動作モードと、前記第２の動作モードとのいずれで動作するかを選択する選択手段と、選択された動作モードでデータ通信を行う通信手段と、を有する。

本発明によれば、チャネルの切り替えが行われることによる通信に関する品質の劣化を防ぐことができる。

無線通信システムの構成例を示す図。 Ｓｉｎｋの第１の機能構成例を示すブロック図。 チャネル幅を決定する処理の第１の例を示すフローチャート。 無線通信システムにおいて実行される処理の流れの第１の例を示すシーケンス図。 Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙ Ｉｎｆｏｒｍａｔｉｏｎ ｅｌｅｍｅｎｔの構成例を示す図。 ＨＴ Ｃａｐａｂｉｌｉｔｉｅｓ Ｉｎｆｏｒｍａｔｉｏｎ ｅｌｅｍｅｎｔの構成例を示す図。 無線通信システムにおいて実行される処理の流れの第２の例を示すシーケンス図。 ＨＴ Ｏｐｅｒａｔｉｏｎ ｅｌｅｍｅｎｔの構成例を示す図。 Ｓｉｎｋの第２の機能構成例を示すブロック図。 チャネル幅を決定する処理の第２の例を示すフローチャート。 Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙ Ｉｎｆｏｒｍａｔｉｏｎ ｅｌｅｍｅｎｔの別の構成例を示す図。 ＯＢＳＳ Ｓｃａｎ Ｐａｒａｍｅｔｅｒｓ ＩＥの構成例を示す図。 Ｓｏｕｒｃｅの機能構成例を示すブロック図。 チャネル幅を決定する処理の第３の例で用いられる表を示す図。 無線通信システムにおいて実行される処理の流れの第３の例を示すシーケンス図。 Ｓｉｎｋの第３の機能構成例を示すブロック図。 無線通信システムにおいて実行される処理の流れの第４の例を示すシーケンス図。 チャネル幅を決定する処理の第４の例で用いられる表を示す図。 Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙ Ｉｎｆｏｒｍａｔｉｏｎ ｅｌｅｍｅｎｔの別の構成例を示す図。

以下、添付図面を用いて本発明に係る各実施形態について説明する。なお、以下では、Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙ規格に準拠した無線ＬＡＮシステムを用いた例について説明するが、これに限られない。また、通信装置の動作モードがＨＴ２０モードとＨＴ４０モードとのいずれかを選択可能であるものとするが、これにも限られない。すなわち、動作中にチャネルの移動を伴う動作モードと、動作中にチャネルの移動を伴わない動作モードとのいずれかを選択可能である場合に、以下の議論を適用しうる。なお、これ以外の動作モードが用いられてもよく、すなわち、動作中に通信が維持されない期間がある動作モードと、そのような期間がない動作モードとのいずれかが選択可能である場合に、以下の議論が適用されてもよい。

（無線通信システムの構成）
図１は、以下の各実施形態に係る無線通信システムの構成例を示す図である。本無線通信システムは、例えば、Ｓｉｎｋ１０１、Ｓｏｕｒｃｅ１０２、及び無線ネットワーク１０３を含んで構成される。Ｓｉｎｋ１０１は、Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙ規格に準拠したＳｉｎｋとして機能する通信装置である。Ｓｉｎｋ１０１はＳｏｕｒｃｅ１０２から映像ストリームを受信し、その映像ストリームを再生する。Ｓｏｕｒｃｅ１０２は、Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙ規格に準拠したＳｏｕｒｃｅとして機能する通信装置である。Ｓｉｎｋ１０１と、Ｓｏｕｒｃｅ１０２とは、互いを通信の相手装置として通信を行う。Ｓｏｕｒｃｅ１０２は、Ｓｏｕｒｃｅ１０２の不図示の画面に表示されている映像と同じ映像を、映像ストリームとして、Ｓｉｎｋ１０１に送信する。無線ネットワーク１０３は、Ｓｉｎｋ１０１及びＳｏｕｒｃｅ１０２が参加するＰ２Ｐ Ｇｒｏｕｐである。Ｓｉｎｋ１０１及びＳｏｕｒｃｅ１０２は、Ｗｉ−Ｆｉ Ｄｉｒｅｃｔによって接続してＰ２Ｐ Ｇｒｏｕｐを構成し、映像ストリーミング配信に係るデータ通信を行う。

＜＜実施形態１＞＞
本実施形態では、Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙによる映像ストリーミング中であるか否かに応じて、ＯＢＳＳスキャンが生じるＨＴ４０モードと、ＯＢＳＳスキャンが生じないＨＴ２０モードとのいずれでネットワークが動作するかが決定される。これにより、例えば、Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙによる映像ストリーミングが行われている場合はＨＴ２０モードで、ＯＢＳＳスキャンが生じないようにすることで、映像ストリーミングの映像の乱れが発生することを防ぐことができる。一方で、Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙによる映像ストリーミングが行われていない場合は、ＨＴ４０モードで高速通信を行うことができる。

なお、以下の手法は、Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙに限らず、一定期間にわたって連続的にデータ通信が行われるか否かに応じて、ＨＴ２０モードとＨＴ４０モードとのいずれが用いられるかを決定するようにすることができる。すなわち、一定期間にわたって連続的にデータ通信が行われる場合は、チャネルの変更（ＯＢＳＳスキャン）を伴わないＨＴ２０モードが選択され、一定期間にわたる連続的なデータ通信が行われない場合は、高速通信が可能なＨＴ４０モードが選択される。なお、単位時間当たりに送受信されるデータ量が所定量以下である場合は、一定期間にわたる連続的なデータ通信が行われるか否かによらず、ＨＴ２０モードが選択されてもよい。

（Ｓｉｎｋの構成）
図２は、Ｓｉｎｋ１０１の機能構成例を示すブロック図である。Ｓｉｎｋ１０１は、例えば、その機能構成として、無線ＬＡＮ制御部２０１、ストリーミング制御部２０２、ＷｉＦｉ Ｄｉｓｐｌａｙ管理部２０３、チャネル幅選択制御部２０４、ＵＩ制御部２０５、表示部２０６、及び記憶部２０７を有する。なお、Ｓｉｎｋ１０１は、ハードウェアとして、例えば、１つ以上のプロセッサ（又はＣＰＵ）と、ＲＯＭやＲＡＭ等のメモリ又は記憶装置とを有する。そして、メモリ又は記憶装置に記憶されたプログラムをプロセッサが実行することにより、上述の各機能の少なくとも一部が実現されうる。

無線ＬＡＮ制御部２０１は、他の無線ＬＡＮを用いる通信装置との間で無線信号の送受信を行う。無線ＬＡＮ制御部２０１は、例えば、無線通信を行うためのアンテナを含んで構成される。なお、無線ＬＡＮ制御部２０１は、後述のチャネル幅選択制御部２０４が決定したＨＴ２０モードとＨＴ４０モードとの少なくともいずれかで通信するための制御を行う。なお、ＨＴ２０モードはチャネルの切り替えが生じないが低速の通信モードであり、ＨＴ４０モードはＯＢＳＳ（Ｏｖｅｒｌａｐｐｉｎｇ Ｂａｓｉｃ Ｓｅｒｖｉｃｅ Ｓｅｔ）スキャンによるチャネルの切り替えが生じるが高速の通信モードである。ストリーミング制御部２０２は、無線ＬＡＮ制御部２０１がＳｏｕｒｃｅ１０２から受信した映像フレームを順次デコードし、表示部２０６に表示できる形式にする処理を行う。

Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙ管理部２０３は、無線ＬＡＮ制御部２０１を制御することにより、Ｐ２Ｐの接続及びコネクションの管理を行う。また、Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙ管理部２０３は、ストリーミング制御部２０２を制御することにより、実際に映像のストリーミングの再生、停止、中断等の処理を実行する。Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙ管理部２０３は、Ｓｏｕｒｃｅ１０２がＷｉ−Ｆｉ ＤｉｓｐｌａｙのＳｏｕｒｃｅとして動作するために無線ＬＡＮ制御部２０１の制御を実行する。Ｓｏｕｒｃｅ１０２がＷｉ−Ｆｉ Ｄｉｓｐｌａｙを用いずにアクセスポイントに接続する場合や、Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙによる映像ストリーミングを伴わないＰ２Ｐ接続をする場合、Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙ管理部２０３はこれらの制御に関与しない。この場合は、Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙ管理部２０３は、Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙが無効なモードとして動作する。

チャネル幅選択制御部２０４は、Ｓｏｕｒｃｅ１０２とＰ２Ｐ接続をする際に、ＨＴ２０モードで動作するか、又はＨＴ４０モードで動作するかを決定するための判断を行う。なお、チャネル幅選択制御部２０４が実行する処理の詳細については、図３を用いて後述する。

ＵＩ制御部２０５は、例えば、不図示のＳｉｎｋ１０１のユーザがＳｉｎｋ１０１を操作するためのボタンやキーボードを含んで構成され、操作を受け付けた結果を通信装置内の制御信号として形成するための処理を行う。表示部２０６は、例えば、Ｓｉｎｋ１０１のディスプレイであり、例えばＳｏｕｒｃｅ１０２から受信したストリーミング映像を受け付けて表示するための処理を行う。記憶部２０７は、Ｓｉｎｋ１０１が動作するために必要なＲＯＭ、ＲＡＭ又は他の記憶装置等である。

（チャネル幅決定処理）
図３は、Ｓｉｎｋ１０１のチャネル幅選択制御部２０４がＰ２Ｐ接続する際のチャネル幅を決定する処理の例を示すフローチャートである。本処理は、Ｗｉ−Ｆｉ ＤｉｒｅｃｔにおけるＧｒｏｕｐ Ｏｗｎｅｒ Ｎｅｇｏｔｉａｔｉｏｎが完了し、Ｓｉｎｋ１０１の役割がＧＯ（Ｐ２Ｐ Ｇｒｏｕｐ Ｏｗｎｅｒ）又はＣｌｉｅｎｔ（Ｐ２Ｐ Ｃｌｉｅｎｔ）に決定された後に行われる処理である。Ｓｉｎｋ１０１のチャネル幅選択制御部２０４は、決定された役割（ＧＯ又はＣｌｉｅｎｔ）における動作として、ＨＴ２０モードで動作するか、又は、ＨＴ４０モードで動作するかを決定する。

本処理では、チャネル幅選択制御部２０４は、まず、Ｓｉｎｋ１０１においてＷｉ−Ｆｉ Ｄｉｓｐｌａｙが有効であるかどうかを判定する（Ｓ３０１）。これは、Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙ管理部２０３が、無線ＬＡＮ制御部２０１を制御してＷｉ−Ｆｉ Ｄｉｓｐｌａｙによる映像ストリーミングを実行している場合には、Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙが有効であると判定される。一方で、Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙによる映像ストリーミングが実行されていない場合には、チャネル幅選択制御部２０４は、Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙが無効であると判定する。

そして、チャネル幅選択制御部２０４は、Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙが有効であると判定した場合（Ｓ３０１でＹＥＳ）は、ＨＴ２０モードで動作すると決定する（Ｓ３０２）。そして、無線ＬＡＮ制御部２０１は、Ｓｉｎｋ１０１がＧＯである場合にはＨＴ２０モードで無線ネットワークを生成し、Ｓｉｎｋ１０１がＣｌｉｅｎｔである場合にはＨＴ２０モードで無線ネットワークに参加する。

一方で、チャネル幅選択制御部２０４は、Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙが無効であると判定した場合（Ｓ３０１でＮＯ）は、ＨＴ４０モードで動作すると決定する（Ｓ３０３）。そして、無線ＬＡＮ制御部２０１は、Ｓｉｎｋ１０１がＧＯである場合にはＨＴ４０モードで無線ネットワークを生成し、Ｓｉｎｋ１０１がＣｌｉｅｎｔである場合にはＨＴ４０モードで無線ネットワークに参加する。

上述のように、Ｓｉｎｋ１０１は、ＨＴ４０モードで動作する場合には、ＯＢＳＳスキャンを定期的に実行する必要がある。しかしながら、以上の処理により、Ｓｉｎｋ１０１はＷｉ−Ｆｉ Ｄｉｓｐｌａｙが有効な場合にはＨＴ２０モードで動作するため、ＯＢＳＳスキャンを実行する必要がない。このため、Ｓｉｎｋ１０１が、ＯＢＳＳスキャンで他の無線チャネルに一時的に移動することによって、映像ストリーミングを受信できなくなる期間において生じ得る映像の乱れを防ぐことができる。

（無線通信システムにおける処理の流れ）
続いて、本実施形態に係る無線通信システムにおける処理の流れについて図４を用いて説明する。図４は、Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙにより、Ｓｏｕｒｃｅ１０２の画面をＳｉｎｋ１０１でミラーリングするための一連の処理の流れの例を示すシーケンス図である。図４では、Ｓｉｎｋ１０１が、Ｐ２ＰのＣｌｉｅｎｔの役割で動作する。

まず、Ｓｉｎｋ１０１のユーザがＳｉｎｋ１０１を操作することによって、Ｗｉ−Ｆｉ ＤｉｓｐｌａｙによるＳｏｕｒｃｅ１０２からのミラーリングを開始する。これによって、Ｓｉｎｋ１０１におけるＷｉ−Ｆｉ Ｄｉｓｐｌａｙが有効となる（Ｓ４０１）。また、Ｓｏｕｒｃｅ１０２においても、ユーザがＷｉ−Ｆｉ Ｄｉｓｐｌａｙによる接続を開始する。

Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙが有効となると、Ｓｉｎｋ１０１及びＳｏｕｒｃｅ１０２は、Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙの規格に従って互いを発見するためにＤｅｖｉｃｅ Ｄｉｓｃｏｖｅｒｙを行う（Ｓ４０２）。これは、Ｗｉ−Ｆｉ Ｄｉｒｅｃｔ規格のＰ２Ｐ Ｄｅｖｉｃｅ Ｄｉｓｃｏｖｅｒｙを拡張したものである。Ｄｅｖｉｃｅ Ｄｉｓｃｏｖｅｒｙでは、Ｐ２Ｐ Ｄｅｖｉｃｅ Ｄｉｓｃｏｖｅｒｙで交換される情報に加えて、さらに、映像ストリーミングをするために必要なパラメータ情報等が付加的に送受信される。このパラメータ情報等は、Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙ Ｉｎｆｏｒｍａｔｉｏｎ ｅｌｅｍｅｎｔ（以下、「ＷＦＤ ＩＥ」と呼ぶ。）として送受信される。

図５は、Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙで規定されるＷＦＤ ＩＥを示す。例えば、ＷＦＤ ＩＥの情報要素であるＯＵＩが０ｘ５０−０ｘ６Ｆ−０ｘ９Ａであり、ＯＵＩ Ｔｙｐｅが０ｘ０Ａである場合、Ｓｉｎｋ１０１及びＳｏｕｒｃｅ１０２は、Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙによる端末の探索が開始されたと判定することができる。

Ｓｉｎｋ１０１及びＳｏｕｒｃｅ１０２は、Ｄｅｖｉｃｅ Ｄｉｓｃｏｖｅｒｙで互いを発見すると、Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙの規格に従って、Ｇｒｏｕｐ Ｆｏｒｍａｔｉｏｎを行い、どちらがＧＯの役割を決定するかどうかを決定する（Ｓ４０３）。なお、Ｇｒｏｕｐ Ｆｏｒｍａｔｉｏｎでは、ＣｌｉｅｎｔがＧＯに接続するための無線パラメータ交換をも実行される。図４では、Ｓｉｎｋ１０１がＣｌｉｅｎｔとなり、Ｓｏｕｒｃｅ１０２がＧＯとなるものとする。Ｓｉｎｋ１０１がＧＯとなり、Ｓｏｕｒｃｅ１０２がＣｌｉｅｎｔとなる場合については、図７で説明する。

Ｇｒｏｕｐ Ｆｏｒｍａｔｉｏｎが完了すると、ＧＯの役割に決まったＳｏｕｒｃｅ１０２は、ＧＯの役割を起動する（Ｓ４０４）。Ｓｏｕｒｃｅ１０２は、例えば、Ｂｅａｃｏｎの送信を開始し（Ｓ４０５）、無線ネットワーク１０３を生成する。このとき、無線ネットワーク１０３は、２．４ＧＨｚ帯の周波数を用いてＨＴ４０モードのネットワークとして動作する。また、このときのＢｅａｃｏｎには、ＩＥＥＥ８０２．１１ｎで規定されるＯＢＳＳ Ｓｃａｎ Ｐａｒａｍｔｅｒｓ Ｉｎｆｏｒｍａｔｉｏｎ Ｅｌｅｍｅｎｔ（以下、「ＯＢＳＳ Ｓｃａｎ ＩＥ」と呼ぶ。）が付与される。ＯＢＳＳ Ｓｃａｎ ＩＥがＢｅａｃｏｎに付与された無線ネットワークにＨＴ４０モードのＣｌｉｅｎｔとして参加した装置は、ＯＢＳＳスキャンを定期的に実行する必要がある。

Ｓｉｎｋ１０１は、Ｇｒｏｕｐ Ｆｏｒｍａｔｉｏｎが完了すると、無線ネットワーク１０３に参加する前にチャネル幅選択処理を行う（Ｓ４０６）。チャネル幅選択処理は、図３を用いて説明した処理である。このとき、Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙを有効としているため、チャネル幅はＨＴ２０モードと決定される。

Ｓｉｎｋ１０１は、チャネル幅を選択すると、無線ネットワーク１０３に参加するために、Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔを送信する。このとき、Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔの情報要素として、ＨＴ Ｃａｐａｂｉｌｉｔｉｅｓ Ｉｎｆｏｒｍａｔｉｏｎ ｅｌｅｍｅｎｔ（以下、「ＨＴ Ｃａｐ ＩＥ」と呼ぶ。）が付与される。このときのＨＴ Ｃａｐ ＩＥは、チャネル幅選択処理の結果としてＨＴ２０モードで無線ネットワークに参加することを示す値に設定される。

図６は、ＨＴ Ｃａｐ ＩＥの構成例を示す図である。ＨＴ２０モードとして無線ネットワークに参加する場合は、ＨＴ Ｃａｐ ＩＥのＨＴ Ｃａｐａｂｉｌｉｔｉｅｓ ＩｎｆｏのＳｕｐｐｏｒｔｅｄ Ｃｈａｎｎｅｌ Ｗｉｄｔｈ Ｓｅｔが０に設定される。一方で、ＨＴ４０モードとして無線ネットワークに参加する場合は、Ｓｕｐｐｏｒｔｅｄ Ｃｈａｎｎｅｌ Ｗｉｄｔｈ Ｓｅｔは１に設定される。Ｓ４０７では、Ｓｉｎｋ１０１は、Ｓ４０６でＨＴ２０モードを選択しているため、Ｓｕｐｐｏｒｔｅｄ Ｃｈａｎｎｅｌ Ｗｉｄｔｈを０に設定する。

Ｓｉｎｋ１０１がＡｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔを送信すると、Ｓｏｕｒｃｅ１０２は、その応答として、Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅを送信する（Ｓ４０８）。また、Ｓｉｎｋ１０１及びＳｏｕｒｃｅ１０２は、Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅの後に、ＷＰＡ２−ＰＳＫ ＡＥＳ方式の鍵交換を行ってもよい（不図示）。

Ｓｉｎｋ１０１及びＳｏｕｒｃｅ１０２は、無線ネットワーク１０３を確立すると、Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙの規格に従って、ＷＦＤ Ｃａｐａｂｉｌｉｔｙ Ｎｅｇｏｔｉａｔｉｏｎを行う（Ｓ４０９）。この処理は、Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙとして動作するＳｉｎｋとＳｏｕｒｃｅとの能力交換によって、Ｓｉｎｋ１０１及びＳｏｕｒｃｅ１０２の互いにとって適した解像度、フレームレートなどを決定するための処理である。

Ｓｉｎｋ１０１及びＳｏｕｒｃｅ１０２は、ＷＦＤ Ｃａｐａｂｉｌｉｔｙ Ｎｅｇｏｔｉａｔｉｏｎを行うと、Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙ規格に従ってＷＦＤ Ｓｅｓｓｉｏｎ Ｅｓｔａｂｌｉｓｈｍｅｎｔを行う（Ｓ４１０）。ＷＦＤ Ｓｅｓｓｉｏｎ Ｅｓｔａｂｌｉｓｈｍｅｎｔでは、映像ストリーミングを開始するためのセッションが確立される。そして、Ｓｏｕｒｃｅが映像フレームの送信を開始するためのトリガとなるフレームであるＲＴＳＰ Ｍ７（ＰＬＡＹ）メッセージが送信されて、映像ストリーミングが開始される。

Ｓｏｕｒｃｅ１０２は、ＷＦＤ Ｓｅｓｓｉｏｎ Ｅｓｔａｂｌｉｓｈｍｅｎｔを完了すると、Ｓｉｎｋ１０１に対して映像フレームをＲＴＰで送信する（Ｓ４１１）。これは、Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙの仕様に従ったフレームで送信される。Ｓｉｎｋ１０１は、ＲＴＰフレームを受信すると、デコード、逆多重化を行い、受信した映像をＳｉｎｋ１０１上に表示する。

Ｓｉｎｋ１０１は、この場合、映像フレームを受信している間にＯＢＳＳスキャンを実行することはない。これは、Ｓ４０７において無線ネットワーク１０３にＨＴ２０モードで参加しているためである。そのため、ＯＢＳＳスキャンを行うことによって一時的に他の無線チャネルに移動することがなくなり、その間に映像フレームが送信できなくなってしまうことを防ぐことができる。これによって、映像の乱れを防ぐことができる。

Ｓｉｎｋ１０１は、映像のストリーミングを終了すると、Ｓｏｕｒｃｅ１０２に対してＲＴＳＰ Ｔｅａｒｄｏｗｎを送信する（Ｓ４１２）。これは、Ｓｉｎｋ１０１またはＳｏｕｒｃｅ１０２において、ユーザがミラーリングの停止を指示した場合、又は所定の映像のストリーミングが完了した場合等に行われる。ＲＴＳＰ Ｔｅａｒｄｏｗｎにより、映像のストリーミングが終了される。なお、ここでは、Ｓｉｎｋ１０１は、Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙによるミラーリングを停止して、Ｐ２Ｐの接続を維持する場合について説明するが、これに限られない。例えば、Ｓｉｎｋ１０１は、映像ストリーミングが完了した後、ＩＥＥＥ８０２．１１で規定されるＤｅａｕｔｈｅｎｔｉｃａｔｉｏｎによって無線ネットワーク１０３から離脱してもよい。Ｓｉｎｋ１０１は、ＲＴＳＰ Ｔｅａｒｄｏｗｎを送信すると、Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙによるミラーリングが終了するため、Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙを無効にする（Ｓ４１３）。

Ｓｉｎｋ１０１は、Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙを無効にすると、再びチャネル幅選択処理を行う（Ｓ４１４）。このときは、Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙは有効ではないため、Ｓｉｎｋ１０１は、ＨＴ４０モードにすると決定する。Ｓｉｎｋ１０１は、ＨＴ４０モードにすると決定すると、現在はＨＴ２０モードで接続しているため、ＨＴ４０モードで無線ネットワーク１０３に参加し直すためにＲｅａｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔを送信する（Ｓ４１５）。このとき、ＨＴ Ｃａｐ ＩＥのＳｕｐｐｏｒｔｅｄ Ｃｈａｎｎｅｌ Ｗｉｄｔｈ Ｓｅｔは、１に設定される。Ｓｏｕｒｃｅ１０２は、Ｒｅａｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔを受信すると、その応答としてＲｅａｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅを送信する（Ｓ４１６）。これにより、Ｓｉｎｋ１０１及びＳｏｕｒｃｅ１０２は、Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙによる映像ストリーミングをしていない場合には、より高速な通信ができるＨＴ４０モードで通信することができる。

図７は、Ｓｉｎｋ１０１がＰ２ＰのＧＯの役割で動作する場合の無線通信システムの処理の流れを示すシーケンス図である。Ｓ７０１〜Ｓ７０３は、図４のＳ４０１〜Ｓ４０３と同様であるので、説明を省略する。ただし、Ｓ７０３の処理の結果、Ｓｉｎｋ１０１がＧＯの役割で、Ｓｏｕｒｃｅ１０２がＣｌｉｅｎｔの役割で、それぞれ動作するように決定されたものとする。

Ｓｉｎｋ１０１は、ＧＯの役割で動作することを決定すると、チャネル幅選択処理を行う（Ｓ７０４）。Ｓｉｎｋ１０１は、Ｓ７０１でＷｉ−Ｆｉ Ｄｉｓｐｌａｙが有効に設定されているため、ここではチャネル幅をＨＴ２０モードと決定する。Ｓｉｎｋ１０１は、チャネル幅を決定すると、ＨＴ２０モードとしてＧＯの役割で起動して、無線ネットワーク１０３を生成する（Ｓ７０５）。そして、Ｓｉｎｋ１０１は、定期的にＢｅａｃｏｎを送信する（Ｓ７０６）。このときのＢｅａｃｏｎは、ＨＴ４０モードで動作する能力があることを示すように、ＨＴ Ｃａｐ ＩＥのＳｕｐｐｏｒｔｅｄ Ｃｈａｎｎｅｌ Ｗｉｄｔｈ Ｓｅｔが１に設定される。ただし、Ｂｅａｃｏｎに含めるＨＴ Ｏｐｅｒａｔｉｏｎ ｅｌｅｍｅｎｔは、チャネル幅選択処理の結果として無線ネットワーク１０３がＨＴ２０モードで動作していることを示すように設定される。

図８は、ＨＴ Ｏｐｅｒａｔｉｏｎ ｅｌｅｍｅｎｔの構成例を示す図である。ＨＴ２０モードで動作していることを示すためには、例えば、ＨＴ Ｏｐｅｒａｔｉｏｎ ｅｌｅｍｅｎｔのＨＴ Ｏｐｅｒａｔｉｏｎ ＩｎｆｏｒｍａｔｉｏｎのＳｅｃｏｎｄａｒｙ Ｃｈａｎｎｅｌ Ｏｆｆｓｅｔが０に設定される。また、ＳＴＡ Ｃｈａｎｎｅｌ Ｗｉｄｔｈも０に設定される。これにより、Ｓｉｎｋ１０１は、ＨＴ４０モードの能力を持ってはいるが、現在、無線ネットワーク１０３はＨＴ２０モードで稼働していることを示すことができる。

Ｓｉｎｋ１０１がＧＯとして起動し、Ｂｅａｃｏｎを送信し始めると、Ｓｏｕｒｃｅ１０２は、Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔを送信する（Ｓ７０７）。Ｓｉｎｋ１０１はＡｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔを受信すると、その応答としてＡｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅを送信する（Ｓ７０８）。この後、Ｓｉｎｋ１０１及びＳｏｕｒｃｅ１０２との間においてＷＰＡ２−ＡＥＳで鍵交換が行われる（不図示）。

Ｓ７０９〜Ｓ７１４はＳ４０９〜Ｓ４１４と同様であるので説明を省略する。Ｓｉｎｋ１０１は、Ｓ７１４のチャネル幅選択処理においてＨＴ４０モードと決定すると、Ｂｅａｃｏｎで、無線ネットワーク１０３がＨＴ４０モードであることを示す。すなわち、例えば、ＨＴ Ｏｐｅｒａｔｉｏｎ ｅｌｅｍｅｎｔのＳｅｃｏｎｄａｒｙ Ｃｈａｎｎｅｌ Ｏｆｆｓｅｔが１または３に設定されることにより、無線ネットワーク１０３がＨＴ４０モードで動作していることが示される。

以上のように、Ｓｉｎｋ１０１は、Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙを起動している場合に、無線ネットワーク１０３をＨＴ２０モードで動作させることにより、ＣｌｉｅｎｔであるＳｏｕｒｃｅ１０２がＯＢＳＳスキャンをする必要がなくなる。これによって、Ｓｏｕｒｃｅ１０２がＯＢＳＳスキャンすることによって、Ｓｏｕｒｃｅ１０２が一時的に映像フレームを送信できなくなり、Ｓｉｎｋ１０１において映像再生が乱れることを防ぐことができる。

Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙのようにリアルタイムで映像を送信している場合には、一時的に映像フレームの送受信ができなくなってしまうと、その間はＳｉｎｋにおいて映像が表示されないため、ユーザエクスペリエンスを大きく低下させてしまう場合がある。そのため、上述の処理によってＨＴ２０モードで動作することで、帯域幅が小さくなってしまうが、大きな映像の乱れを防ぐことができる。

一方で、Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙによる映像ストリーミングが終了した場合等には帯域幅の大きいＨＴ４０モードを使用することによって、高速通信を行うことができる。例えば、大きなファイル転送等では、帯域幅の大きなＨＴ４０モードでデータを送信することによって、ＯＢＳＳスキャンによって一時的にファイルの転送が停止しても、全体として短時間でのファイル転送の完了を期待できる。

本実施形態では、Ｓｉｎｋ１０１がチャネル幅を決定する処理を行うものとして説明したが、Ｓｏｕｒｃｅがこの処理を行ってもよい。例えば、図４と図７において、それぞれＳ４１１とＳ７１１の映像フレームの送信の方向が変わるだけである。

＜＜実施形態２＞＞
本実施形態では、映像の許容遅延時間に応じて、無線ネットワークをＨＴ２０モードとＨＴ４０モードとのいずれで動作させるかが決定される。実施形態１と同様の点については説明を省略する。本実施形態は、Ｓｉｎｋ１０１の機能ブロックとチャネル幅選択処理とが、実施形態１と異なる。これらについて、それぞれ図９及び図１０を用いて説明する。

図９は、本実施形態に係るＳｉｎｋ１０１の機能構成例を示すブロック図である。９０１〜９０３及び９０５〜９０７については、図２の２０１〜２０３及び２０５〜２０７と同様であるため、説明を省略する。チャネル幅選択制御部９０４は、実施形態１のチャネル幅選択制御部２０４と同様にチャネル幅を選択する処理を行うが、このときの処理は、図３に示される処理ではなく、図１０に示される処理である。

バッファリング制御部９０８は、無線ＬＡＮ制御部９０１が受信したデータのうち、映像フレームを一時的に蓄積（バッファリング）するためのメモリなどのハードウェア及びそれらを制御するプログラムを含んで構成される。ストリーミング制御部９０２は、バッファリング制御部９０８から映像フレームを取得して、デコードする処理を行う。映像フレームは、バッファリング制御部９０８で一時的に蓄積された上で、ストリーミング制御部９０２によってデコード処理が施され、デコード結果が表示部９０６に渡される。これにより、Ｓｉｎｋ１０１は、受信したストリーミング映像を表示することができる。

ストリーミング映像は、無線ＬＡＮが一時的に混雑した場合、又はＳｏｕｒｃｅ側の処理負荷が一時的に変わって送信するタイミングがずれた場合などに、一部のフレームが遅延して到達する場合がある。しかしながら、このような場合であっても、バッファリング制御部９０８を設けることによって、Ｓｉｎｋ１０１は、バッファリングしている映像フレームの分だけ、映像を途切れさせることなく再生を継続することができる。バッファリングする映像フレーム数を増やせば増やすほど、映像フレームの受信遅延による映像の途切れを抑制することができる。その一方で、バッファのサイズを増やすと、Ｓｏｕｒｃｅ側で表示されている映像がバッファリングされる分だけ遅れて表示されることになるため、リアルタイム性が落ちる場合がある。このため、バッファのサイズは、必要に応じて変更されてもよい。すなわち、リアルタイム性と、映像の途切れの抑制とのいずれを優先するかに応じて、バッファのサイズが変更されうる。なお、この優先度の設定は、Ｓｉｎｋ１０１のユーザによる操作で行われてもよいし、例えばＳｏｕｒｃｅ１０２からの指示により、又は、送受信されるデータ（例えばデータの属性）に応じて定められうる。これについて、一部の例を後述する。

続いて、図１０を用いて、チャネル幅選択処理の流れについて説明する。本実施形態では、チャネル幅選択制御部９０４は、まず、実施形態１と同様に、Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙが有効であるかを判定する（Ｓ１００１）。このとき、チャネル幅選択制御部９０４は、Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙが無効である場合（Ｓ１００１でＮＯ）、ＨＴ４０モードを選択する（Ｓ１００７）。また、この場合、映像ストリーミングを行わないため、バッファサイズの制御は行わない。

一方で、チャネル幅選択制御部９０４は、Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙが有効であった場合（Ｓ１００１でＹＥＳ）、次に、Ｓｏｕｒｃｅ１０２から送信される映像の許容遅延時間と、ＯＢＳＳスキャンにかかる時間とを比較する（Ｓ１００２）。本実施形態では、Ｓｏｕｒｃｅ１０２は、ＷＦＤ ＩＥを拡張することによって、Ｓｉｎｋ１０１に映像の許容遅延時間を通知するものとする。拡張したＷＦＤ ＩＥの構成例を図１１に示す。図１１のＷＦＤ ＩＥは、実施形態１におけるＷＦＤ ＩＥに、ＷＦＤ Ｃｏｎｔｅｎｔｓ Ｍｉｎｉｍｕｍ Ｄｅｌａｙ Ｔｉｍｅが追加された構成となっている。この情報は、Ｓｏｕｒｃｅ１０２から送信される映像が表示されるまでの許容遅延時間を含む。

例えば、Ｓｏｕｒｃｅ１０２がリアルタイム性の高いゲームなどの映像をＳｉｎｋ１０１に送信する場合は、ＷＦＤ Ｃｏｎｔｅｎｔｓ Ｍｉｎｉｍｕｍ Ｄｅｌａｙ Ｔｉｍｅは、１００ｍｓｅｃと指定されうる。一方で、Ｓｏｕｒｃｅ１０２がリアルタイム性の低い映画などの映像データをＳｉｎｋ１０１に送信する場合には、ＷＦＤ Ｃｏｎｔｅｎｔｓ Ｍｉｎｉｍｕｍ Ｄｅｌａｙ Ｔｉｍｅは、１０００ｍｓｅｃと指定されうる。ここでは、ＷＦＤ Ｃｏｎｔｅｎｔｓ Ｍｉｎｉｍｕｍ Ｄｅｌａｙ Ｔｉｍｅは、Ｓｉｎｋ１０１側でバッファを設けることを前提にして、５０ミリ秒以上の値であるとする。

Ｓｏｕｒｃｅ１０２は、Ｄｅｖｉｃｅ Ｄｉｓｃｏｖｅｒｙ又はＧｒｏｕｐ Ｆｏｒｍａｔｉｏｎ等で送信するＰｒｏｂｅ Ｒｅｑｕｅｓｔ、Ｐｒｏｂｅ Ｒｅｓｐｏｎｓｅ、Ａｃｔｉｏｎ Ｆｒａｍｅ、Ｂｅａｃｏｎなどに、拡張したＷＦＤ ＩＥを付与する。Ｓｉｎｋ１０１は、その拡張したＷＦＤ ＩＥが付与された信号を受信することによって、Ｓｏｕｒｃｅ１０２が送信する映像の許容遅延時間を知ることができる。また、ＯＢＳＳスキャンにかかる時間はＧＯの役割を担った無線ＬＡＮ装置が送信するＢｅａｃｏｎに付与されるＯＢＳＳ Ｓｃａｎ Ｐａｒａｍｅｔｅｒｓ ｅｌｅｍｅｎｔの情報を用いて判断されうる。

図１２に、ＯＢＳＳ Ｓｃａｎ Ｐａｒａｍｅｔｅｒｓ ＩＥの構成例を示す。ＯＢＳＳ Ｓｃａｎ Ｐａｒａｍｅｔｅｒｓ ＩＥは、ＩＥＥＥ８０２．１１ｎの仕様に従うものである。ＯＢＳＳ Ｓｃａｎ Ｐａｒａｍｅｔｅｒｓ ＩＥには、スキャンの時間に関する情報が含められる。ＯＢＳＳ Ｓｃａｎ Ｐａｒａｍｅｔｅｒｓ ＩＥに含まれる情報のうち、本実施形態では、Ｓ１００２の判定処理に関係する情報要素について説明する。

ＯＢＳＳ Ｓｃａｎ Ｐａｓｓｉｖｅ Ｔｏｔａｌ Ｐｅｒ Ｃｈａｎｎｅｌには、各チャネルをパッシブ・スキャンするための最小の合計時間を示す情報が含まれる。ＯＢＳＳ Ｓｃａｎ Ａｃｔｉｖｅ Ｔｏｔａｌ Ｐｅｒ Ｃｈａｎｎｅｌには、各チャネルをアクティブ・スキャンするための最小の合計時間を示す情報が含まれる。ＢＳＳ Ｃｈａｎｎｅｌ Ｗｉｄｔｈ Ｔｒｉｇｇｅｒ Ｓｃａｎ ＩｎｔｅｒｖａｌにはＯＢＳＳ Ｓｃａｎが実行される間隔を示す情報が含まれる。

１つのチャネルをＯＢＳＳスキャンするのにかかる時間は、（ＯＢＳＳ Ｓｃａｎ Ｐａｓｓｉｖｅ Ｔｏｔａｌ Ｐｅｒ Ｃｈａｎｎｅｌ ＋ ＯＢＳＳ Ｓｃａｎ Ａｃｔｉｖｅ Ｔｏｔａｌ Ｐｅｒ Ｃｈａｎｎｅｌ）×１．０２４ミリ秒である。この時間がスキャンするチャネルの数だけかかる。すなわち、ＯＢＳＳスキャンに要する合計時間は上述の時間にスキャンするチャネル数を乗じた長さとなる。したがって、Ｓｉｎｋ１０１は、そのバッファのサイズとして、このＯＢＳＳスキャンに要する合計時間分のフレームを保持できるだけのサイズを確保する。なお、Ｓｉｎｋ１０１は、さらに、デコード処理、又はＯＢＳＳスキャン以外の要因による無線でのパケットロスが発生した場合等のために、バッファサイズをさらに余裕をとってもよい。すなわち、スキャン分の時間に等しい所定時間又はそのスキャン分の時間を超える所定時間を、許容遅延時間との比較対象の時間としてもよい。ここでは、その余裕分として、５０ミリ秒だけ確保されるものとする。このとき、チャネル幅選択制御部９０４は、Ｓ１００２において、許容遅延時間と、ＯＢＳＳスキャンに要する合計時間＋５０ミリ秒との比較をする。

ここで、チャネル幅選択制御部９０４は、許容遅延時間の方が小さいと判断した場合（Ｓ１００２でＹＥＳ）、ＯＢＳＳスキャンをした場合に映像の乱れを軽減しながら許容遅延時間を満たすことができないため、ＨＴ２０モードを選択する（Ｓ１００３）。そして、バッファリング制御部９０８は、バッファサイズを５０ミリ秒分の映像フレームと設定する（Ｓ１００４）。

一方で、許容遅延時間の方が大きい場合、ＯＢＳＳスキャンにかかる時間分だけバッファサイズを大きくすることで、映像の乱れを防ぎながら許容遅延時間を守ることができる。このため、チャネル幅選択制御部９０４は、許容遅延時間の方が大きいと判定した場合（Ｓ１００２でＮＯ）、ＨＴ４０モードを選択する（Ｓ１００５）。そして、バッファリング制御部９０８は、バッファサイズを５０ミリ秒＋ＯＢＳＳスキャンにかかる時間と設定する。

以上により、Ｓｏｕｒｃｅ１０２がＣｌｉｅｎｔの場合にＯＢＳＳスキャンしたとしても、その間はバッファに格納された映像フレームをＳｉｎｋ１０１が再生することにより、映像の乱れが発生する可能性を抑制することができる。一方で、Ｓｉｎｋ１０１がＣｌｉｅｎｔの場合でも、同様に、ＯＢＳＳスキャン中はバッファに格納された映像フレームをＳｉｎｋ１０１が再生することにより、映像の乱れが発生する可能性を抑制することができる。

以上により、本実施形態では、連続的なデータ通信が行われる場合に、映像許容遅延時間に応じて、ＨＴ２０モードとＨＴ４０モードとのいずれかが選択される。これにより、遅延が許されない場合には、ＯＢＳＳスキャンで一時的に映像の乱れを防ぐためにバッファサイズを大きくするのではなく、ＨＴ２０モードで動作することで映像の遅延を少なくする。一方で、遅延が許される場合には、ＨＴ４０モードで接続することによって帯域幅を広くして、より高画質な映像を送信するようにする。そして、ＯＢＳＳスキャンにかかる時間の分以上にバッファサイズを設けることによって、ＯＢＳＳスキャン中にフレームが受信でいなくても映像が乱れることなく再生することができる。

なお、Ｓｉｎｋ１０１は、映像許容遅延時間を、Ｓｏｕｒｃｅ１０２から取得するのではなく、受信した映像フレームから判断するようにしてもよい。または、Ｓｉｎｋ１０１のユーザが、Ｓｉｎｋ１０１に対して、映像許容遅延時間を設定できるようにしてもよい。いずれにせよ、Ｓｉｎｋ１０１は、映像許容遅延時間を取得して、それをもとにＨＴ２０モードかＨＴ４０モードかを決定するようにしてもよい。

なお、本実施形態であっても、映像のみならず、任意の連続的なデータ通信について、許容遅延時間に基づいて、ＨＴ２０モードとＨＴ４０モードとのいずれかが選択されるようにしてもよい。

＜＜実施形態３＞＞
本実施形態では、映像の種別に応じてＨＴ２０モードにするかＨＴ４０モードにするかが決定される。実施形態１又は２と同様である点については説明を省略する。上述の各実施形態では、Ｓｉｎｋ１０１が、チャネル幅の判定処理を行ったが、本実施形態では、Ｓｏｕｒｃｅ１０２が当該処理を行う。

図１３は、本実施形態に係るＳｏｕｒｃｅ１０２の機能構成例を示すブロック図である。１３０１、１３０３、１３０５〜１３０７は実施形態１の図２の２０１、２０３、２０５〜２０７と同様であるため説明を省略する。Ｓｏｕｒｃｅ１０２は、ハードウェアとして、例えば、１つ以上のプロセッサ（又はＣＰＵ）と、ＲＯＭやＲＡＭ等のメモリ又は記憶装置とを有する。そして、メモリ又は記憶装置に記憶されたプログラムをプロセッサが実行することにより、図１３の各機能の少なくとも一部が実現されうる。

ストリーミング制御部１３０２は、Ｓｏｕｒｃｅ１０２がＳｉｎｋ１０１に映像ストリーミングをするための制御を行う。例えば、ストリーミング制御部１３０２は、映像をエンコード及びパケット化することによって生成される各映像フレームを、無線ＬＡＮ制御部１３０１に送信する。チャネル幅選択制御部１３０４は、無線ネットワーク１０３にＨＴ２０モードで参加するか、ＨＴ４０モードで参加するかを決定するための判定を行う。本実施形態では、チャネル幅選択制御部１３０４は、図１４に示す表に基づいて、モードを決定する。

チャネル幅選択制御部１３０４は、表示部１３０６に表示している映像種別、すなわちＳｉｎｋ１０１に送信する映像種別からチャネル幅を決定する。例えば、実施形態２と同様に、リアルタイム性が求められないような場合にはＨＴ４０モードで動作して帯域幅を広くして高画質な映像を送信できるようにする。その代わりに、Ｓｉｎｋ１０１が大きめのバッファを設けることで、ＯＢＳＳスキャンが発生し、映像フレームが一時的に受信できない場合でも、バッファに格納された映像フレームを再生することで映像の乱れを防ぐことができる。一方で、リアルタイム性が求められるような場合には、ＨＴ２０モードで動作することにより、ＯＢＳＳスキャンが行われないようにして、バッファサイズを小さくしてもＯＢＳＳスキャンによる映像の乱れが発生しないようにすることができる。

本実施形態において、映像種別は、記録済み映像再生、録画中画面、メニュー画面の３種類であるものとする。記録済み映像再生は、記憶部１３０７に記憶されている映像データを再生するものであり、リアルタイム性は求められないものとする。したがって、チャネル幅選択制御部１３０４は、表示部１３０６に表示している（すなわち、Ｓｉｎｋ１０１へ送信する）映像種別が記録済み映像再生である場合は、ＨＴ４０モードで動作することを決定する。録画中画面は、撮像制御部１３１０で録画している動画を表示するものであり、リアルタイム性が求められるものとする。カメラで録画している映像をリアルタイムにＳｉｎｋ１０１で確認したいような場合が、これに該当する。したがって、チャネル幅選択制御部１３０４は、表示部１３０６に表示している（すなわち、Ｓｉｎｋ１０１へ送信する）映像種別が録画中画面である場合は、ＨＴ２０モードで動作することを決定する。メニュー画面は、記録済み映像を再生するか、又は録画を開始するかを、ユーザが選択できるようなメニュー画面である。ユーザがＵＩ制御部１３０５を操作した時に、すぐに反応して画面が切り替わることを可能とするために、メニュー画面はリアルタイム性が求められるものとする。そのため、チャネル幅選択制御部１３０４は、表示部１３０６に表示している（すなわち、Ｓｉｎｋ１０１へ送信する）映像種別がメニュー画面である場合は、ＨＴ２０モードで動作することを決定する。

映像種別判断部１３０８は、図１４に示すような映像種別のうち、現在、いずれの映像種別の映像を表示しているかを判断する。映像種別判断部１３０８は、Ｓｏｕｒｃｅ１０２で表示している映像が変化した場合に、映像種別を判断してチャネル幅選択制御部１３０４に通知し、チャネル幅（動作モード）を選択する。なお、撮像制御部１３１０は、レンズや撮像素子など、動画を録画するためのハードウェアおよびソフトウェアを含んで構成される。

続いて、本実施形態に係る無線通信システムにおける処理の流れについて図１５を用いて説明する。図１５は、Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙにより、Ｓｏｕｒｃｅ１０２の画面をＳｉｎｋ１０１でミラーリングするための一連の処理の流れの例を示すシーケンス図である。図１５では、Ｓｏｕｒｃｅ１０２が、Ｐ２ＰのＧＯの役割で動作する。

まず、Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙを開始する前に、Ｓｏｕｒｃｅ１０２において、メニュー画面が表示されているものとする（Ｓ１５０１）。Ｓ１５０２〜Ｓ１５０４はＳ４０１〜Ｓ４０３と同様であるため説明を省略する。Ｓｏｕｒｃｅ１０２は、Ｓ１５０４で役割を決定すると、無線ネットワーク１０３を生成する前に、チャネル幅選択処理を実行する（Ｓ１５０５）。このとき、Ｓｏｕｒｃｅ１０２は、メニュー画面を表示しているため、図１４に示されるように、ＨＴ２０モードを選択する。

Ｓｏｕｒｃｅ１０２は、ＨＴ２０モードを選択すると、無線ネットワーク１０３をＨＴ２０モードで稼働する無線ネットワークとして生成してＧＯとして起動し（Ｓ１５０６）、定期的にＢｅａｃｏｎを送信する（Ｓ１５０７）。このときのＢｅａｃｏｎではＨＴ Ｃａｐ ＩＥのＳｕｐｐｏｒｔｅｄ Ｃｈａｎｎｅｌ Ｗｉｄｔｈ Ｓｅｔは、４０ＭＨｚをサポートすることを示す、１が設定されている。また、ＨＴ Ｏｐｅｒａｔｉｏｎ ｅｌｅｍｅｎｔのＳｅｃｏｎｄａｒｙ Ｃｈａｎｎｅｌ Ｏｆｆｓｅｔは、実際に２０ＭＨｚで稼働していることを示す、０が設定されている。

ＧＯが起動してミラーリングが開始されてからの処理はＳ１５０７〜Ｓ１５１０であるが、これは上述の各実施形態と同様であるため、説明を省略する。ＷＦＤ Ｃａｐａｂｉｌｉｔｙ ＮｅｇｏｔｉａｔｉｏｎとＷＦＤ Ｓｅｓｓｉｏｎ Ｅｓｔａｂｌｉｓｈｍｅｎｔは、図示していないが、上述の各実施形態と同様に実行される。

次に、Ｓｏｕｒｃｅ１０２のユーザがメニュー画面から録画済み映像の再生の開始を選択したとする（Ｓ１５１１）。すると、Ｓｏｕｒｃｅ１０２は、映像種別が変更となるため、チャネル幅選択処理を実行する（Ｓ１５１２）。図１４より、Ｓｏｕｒｃｅ１０２は、記録済み映像の再生中は、ＨＴ４０モードを選択する。Ｓｏｕｒｃｅ１０２は、ＨＴ４０モードを選択すると、８０２．１１ｎで規定されているＮｏｔｉｆｙ Ｃｈａｎｎｅｌ Ｗｉｄｔｈ Ａｃｔｉｏｎ ｆｒａｍｅをＳｉｎｋ１０１に送信する。これにより、Ｓｏｕｒｃｅ１０２は、ＨＴ４０モードでの動作を開始したことをＳｉｎｋ１０１に通知する（Ｓ１５１３）。また、Ｓｏｕｒｃｅ１０２は、Ｂｅａｃｏｎの送信においてもＨＴ Ｏｐｅｒａｔｉｏｎ ｅｌｅｍｅｎｔのＳｅｃｏｎｄａｒｙ Ｃｈａｎｎｅｌ Ｏｆｆｓｅｔを１または３に設定することで、ＨＴ４０モードで稼働していることを報知する。

ＨＴ４０モードにするとＳｉｎｋ１０１がＯＢＳＳスキャンを開始して、その間映像フレームを受信できずに映像が乱れてしまう場合がある。このため、これを防ぐために、Ｓｏｕｒｃｅ１０２は、バッファサイズ拡大要求をＳｉｎｋ１０１に送信する。Ｓｉｎｋ１０１はバッファサイズ拡大要求を受信したことに応じて、バッファサイズを拡大する（Ｓ１５１５）。

ＨＴ４０モードでは信号帯域幅が大きくなり、高画質の映像を送りやすくなる。このため、Ｓｏｕｒｃｅ１０２は、Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙで規定されているＡＶ Ｆｏｒｍａｔ Ｃｈａｎｇｅを送信し、より高画質なデータを送信することをＳｉｎｋ１０１に通知する（Ｓ１５１６）。これは高画質な映像を送信したい場合に行われるもので、必ずしも送信されなくてもよい。その後、Ｓｏｕｒｃｅ１０２は、映像フレームをＲＴＰデータとして引き続き送信する（Ｓ１５１７）。次に、Ｓｏｕｒｃｅ１０２のユーザがＳｏｕｒｃｅ１０２を操作し、録画を開始したとする（Ｓ１５１８）。すると、Ｓｏｕｒｃｅ１０２は、映像種別が変更となるため、チャネル幅選択処理を実行する（Ｓ１５１９）。図１４より、Ｓｏｕｒｃｅ１０２は、録画中は、ＨＴ２０モードを選択する。

Ｓｏｕｒｃｅ１０２は、ＨＴ２０モードを選択すると、８０２．１１ｎで規定されているＮｏｔｉｆｙ Ｃｈａｎｎｅｌ Ｗｉｄｔｈ Ａｃｔｉｏｎ ｆｒａｍｅをＳｉｎｋ１０１に送信する。これにより、Ｓｏｕｒｃｅ１０２は、ＨＴ２０モードでの動作を開始したことをＳｉｎｋ１０１に通知する（Ｓ１５２０）。また、Ｓｏｕｒｃｅ１０２は、Ｂｅａｃｏｎの送信においても、ＨＴ Ｏｐｅｒａｔｉｏｎ ｅｌｅｍｅｎｔのＳｅｃｏｎｄａｒｙ Ｃｈａｎｎｅｌ Ｏｆｆｓｅｔを０に設定することで、ＨＴ２０モードで稼働していることを報知する。

ＨＴ２０モードにすると、Ｓｉｎｋ１０１がＯＢＳＳスキャンを開始して、その間映像フレームを受信できずに映像が乱れることはない。このため、Ｓｏｕｒｃｅ１０２は、リアルタイム性を優先してバッファサイズ縮小要求をＳｉｎｋ１０１に送信する（Ｓ１５２１）。Ｓｉｎｋ１０１は、バッファサイズ拡大要求を受信すると、バッファサイズを拡大する（Ｓ１５２２）。ＨＴ２０モードになり信号帯域幅が小さくなるため、高画質の映像では帯域幅が足りない場合には、Ｓｏｕｒｃｅ１０２は、Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙで規定されているＡＶ Ｆｏｒｍａｔ Ｃｈａｎｇｅを送信する。これにより、Ｓｏｕｒｃｅ１０２は、画質を下げたデータを送信することをＳｉｎｋ１０１に通知する（Ｓ１５２３）。これは上述した通り、必ずしも送信されなくてもよい。その後、Ｓｏｕｒｃｅ１０２は、映像フレームをＲＴＰデータとして、引き続きＳｉｎｋ１０１へと送信する（Ｓ１５２４）。

本実施形態では、Ｓｏｕｒｃｅ１０２は、送信される映像種別に応じてＨＴ２０モードとＨＴ４０モードとを動的に選択する。そして、Ｓｏｕｒｃｅ１０２は、リアルタイム性が要求される場合にはＳｉｎｋ１０１のバッファサイズを小さくし、ＨＴ２０モードで動作することにより、ＯＢＳＳスキャンによる映像の乱れを防ぐ。一方で、Ｓｏｕｒｃｅ１０２は、リアルタイム性が要求されない場合にはＳｉｎｋ１０１のバッファサイズを大きくしてＨＴ４０モードで動作する。これにより、Ｓｉｎｋ１０１が、ＯＢＳＳスキャン中の映像フレームが一時的に受信できなくなることを防ぎ、映像が乱れてしまうことを防ぐことができる。

なお、図１５の説明では、Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙが起動されている際の、送信される映像種別に応じて、動作モードがＨＴ２０モードとＨＴ４０モードとのいずれかから選択される例について説明したが、これに限られない。例えば、連続的なデータ通信が行われる場合であれば、その通信されるデータの種別に応じて、動作モードが選択されるようにすることができる。

＜＜実施形態４＞＞
本実施形態では、映像の種別に応じてＨＴ２０モードにするかＨＴ４０モードにするかを決定するが、実施形態３と異なり、Ｓｉｎｋ１０１がチャネル幅選択処理を実行する。他の実施形態と同様の点については説明を省略する。図１６は、本実施形態におけるＳｉｎｋ１０１の機能構成例を示すブロック図である。図１６の１６０１、１６０２、１６０３、１６０５〜１６０７、及び１６０８は、それぞれ、図２、９及び１３の１３０１、２０２、１３０３、１３０５〜１３０７、９０８と同様であるため、説明を省略する。

チャネル幅選択制御部１６０４は、無線ネットワーク１０３にＨＴ２０モードで参加するか、ＨＴ４０モードで参加するかを決定するための判定を行う。本実施形態では、チャネル幅選択制御部１３０４は、図１８に示す表に基づいて、動作モードを決定する。映像種別は、Ｓｏｕｒｃｅ１０２からの、図１９で示される、拡張されたＷＦＤ ＩＥの情報を用いて決定される。拡張されたＷＦＤ ＩＥの情報については詳細な説明は後述する。

チャネル幅選択制御部１６０４は、映像種別がＨｉｇｈＱｕａｌｉｔｙの場合には、リアルタイム性よりも画質の方が重要であるため、信号帯域幅の大きいＨＴ４０モードを選択する。そして、バッファリング制御部１６０８は、ＯＢＳＳスキャンで映像フレームが受信できなくなった場合に一時的に映像が乱れることを防ぐため、ＯＢＳＳスキャンにかかる時間以上のバッファサイズを持つようにする。一方で、チャネル幅選択制御部１６０４は、映像種別がＲｅａｌｔｉｍｅの場合はリアルタイム性が重要であるため、信号帯域幅が小さいが、ＯＢＳＳスキャンをしないで済むＨＴ２０モードを選択する。そして、バッファリング制御部１６０８は、バッファサイズを小さくする。

続いて、本実施形態に係る無線通信システムにおける処理の流れについて図１７を用いて説明する。図１７はＷｉ−Ｆｉ Ｄｉｓｐｌａｙにより、Ｓｏｕｒｃｅ１０２の画面をＳｉｎｋ１０１でミラーリングするための一連の処理の流れを示すシーケンス図である。図１７では、Ｓｉｎｋ１０１が、Ｐ２ＰのＧＯの役割で動作する。なお、図１７の初期状態として、Ｓｏｕｒｃｅ１０２では、リアルタイム性が重要であるメニュー画面が表示されているものとする。

Ｓ１７０１〜Ｓ１７０３は、図１５のＳ１５０２〜Ｓ１５０４と同様であるため、説明を省略する。Ｓｏｕｒｃｅ１０２は、ＧＯを起動すると（Ｓ１７０４）、Ｂｅａｃｏｎを送信する（Ｓ１７０５）が、このとき、図１９に示す拡張されたＷＦＤ ＩＥの情報がＢｅａｃｏｎに付与される（Ｓ１７０５）。図１９に示す拡張ＷＦＤ ＩＥは、Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙで規定されているＷＦＤ ＩＥに、ＷＦＤ Ｃｏｎｔｅｎｔｓ ＩｎｆｏｒｍａｔｉｏｎとしてＷＦＤ Ｃｏｎｔｅｎｔｓ Ｃａｔｅｇｏｒｙが追加されたものである。この追加された情報は、送信される映像の種別を表わすものである。リアルタイム性が要求される場合には、この情報に、Ｒｅａｌｔｉｍｅとして１が設定される。リアルタイム性よりも高画質が要求される場合は、この情報に、ＨｉｇｈＱｕａｌｉｔｙとして２が設定される。なお、この情報には、それら以外の値は設定されないものとする。

Ｓ１７０５の時点では、メニュー画面が表示されているため、Ｂｅａｃｏｎの拡張ＷＦＤ ＩＥのＷＦＤ Ｃｏｎｔｅｎｔｓ ＣａｔｅｇｏｒｙではＲｅａｌｔｉｍｅが指定される。Ｓｉｎｋ１０１は、そのＢｅａｃｏｎを受信すると、チャネル幅選択処理を実行する（Ｓ１７０６）。Ｓｉｎｋ１０１は、図１８に示した通り、Ｒｅａｌｔｉｍｅの場合には、ＨＴ２０モードを選択する。Ｓ１７０７〜Ｓ１７０９は図１５のＳ１５０８〜Ｓ１５１０と同様であるため、説明を省略する。

次に、Ｓｏｕｒｃｅ１０２のユーザが、メニュー画面から録画済み映像の再生の開始を選択したとする（Ｓ１７１０）。Ｓｏｕｒｃｅ１０２は、録画済み映像の再生は、リアルタイム性よりも高画質を優先するため、拡張ＷＦＤ ＩＥのＷＦＤ Ｃｏｎｔｅｎｔｓ ＣａｔｅｇｏｒｙをＨｉｇｈＱｕａｌｉｔｙにする（Ｓ１７１１）。Ｓｉｎｋ１０１は、この設定がされたＢｅａｃｏｎを受信すると、チャネル幅選択処理を行う（Ｓ１７１２）。Ｓｉｎｋ１０１は、図１８に基づいて、ＨｉｇｈＱｕａｌｉｔｙの場合はＨＴ４０モードを選択する。そして、Ｓｉｎｋ１０１は、ＨＴ４０モードで再接続をするために、Ｓ４１５と同様にＲｅａｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔを送信する（Ｓ１７１３）。すると、Ｒｅａｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅが、Ｓｏｕｒｃｅ１０２からＳｉｎｋ１０１へ送信される（Ｓ１７１４）。さらに、Ｓｉｎｋ１０１は、ＯＢＳＳスキャン中に映像の乱れが発生することを防ぐために、バッファサイズを大きくする（Ｓ１７１５）。このとき、Ｓｉｎｋ１０１は、実施形態２と同様にＯＢＳＳスキャンにかかる時間を見積って、バッファサイズを決めることができる。

ＨＴ４０モードで接続した後は信号帯域幅が大きくなるため、高画質なデータの送信が容易になる。このため、Ｓｉｎｋ１０１は、より高画質な映像を送信することを要求する（Ｓ１７１６）。Ｓｏｕｒｃｅ１０２は、その要求を受信すると、より高画質な映像を送ることを通知し（Ｓ１７１７）、実際に高画質な映像データをＲＴＰとして送信する（Ｓ１７１８）。

次に、Ｓｏｕｒｃｅ１０２のユーザがＳｏｕｒｃｅ１０２を操作し、録画を開始したとする（Ｓ１７１９）。録画を開始すると、画質よりもリアルタイム性が重視されることとなる。そのため、Ｓｏｕｒｃｅ１０２は、拡張ＷＦＤ ＩＥのＷＦＤ Ｃｏｎｔｅｎｔｓ ＣａｔｅｇｏｒｙをＲｅａｌｔｉｍｅとしてＢｅａｃｏｎの送信を開始する（Ｓ１７２０）。Ｓｉｎｋ１０１は、受信したＢｅａｃｏｎにおいて、ＷＦＤ Ｃｏｎｔｅｎｔｓ Ｃａｔｅｇｏｒｙに変更があると、Ｓ１７０６及びＳ１７１２と同様に、チャネル幅選択処理を実行する（Ｓ１７２１）。図１８に示すようにＲｅａｌｔｉｍｅの場合はＨＴ２０モードが選択されるため、Ｓｉｎｋ１０１は、ＨＴ２０モードを通知するためにＲｅａｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔを送信する（Ｓ１７２２）。Ｓｏｕｒｃｅ１０２は、それを受信すると、Ｒｅａｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅを返す（Ｓ１７２３）。

Ｓｉｎｋ１０１は、ＨＴ２０モードにするとＯＢＳＳスキャンをする必要がなくなるため、バッファサイズを小さくする（Ｓ１７２４）。そして、Ｓｉｎｋ１０１は、信号帯域幅が小さくなった分、画質を落として送信してもらうための要求をＳｏｕｒｃｅ１０２に送信する（Ｓ１７２５）。すると、Ｓｏｕｒｃｅ１０２は、ＡＶ Ｆｏｒｍａｔ Ｃｈａｎｇｅを送信し、画質を下げたデータを送信することをＳｉｎｋ１０１に通知する（Ｓ１７２６）。その後、Ｓｏｕｒｃｅ１０２は、映像フレームをＲＴＰデータとして引き続き送信する（Ｓ１７２７）。

本実施形態では、送信される映像種別に応じてＨＴ２０モードとＨＴ４０モードとのいずれかがＳｉｎｋ１０１によって動的に選択される。Ｓｉｎｋ１０１は、リアルタイム性が要求される場合にはバッファサイズを小さくし、ＨＴ２０モードで動作することにより、ＯＢＳＳスキャンによる映像の乱れを防ぐ。一方で、Ｓｉｎｋ１０１は、リアルタイム性が要求されない場合にはバッファサイズを大きくしてＨＴ４０モードで動作することで、ＯＢＳＳスキャン中の映像フレームが一時的に受信できなくなり、映像が乱れてしまうことを防ぐ。

＜＜その他の実施形態＞＞
また上述の各実施形態では、Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙを例に説明したが、Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙではなく、他の方法により映像ストリーミングが配信される場合に、上述の閣議論を適用することもできる。

また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

１０１：Ｓｉｎｋ、１０２：Ｓｏｕｒｃｅ、１０３：無線ネットワーク、２０１：無線ＬＡＮ制御部、２０２：ストリーミング制御部、２０３：Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙ管理制御部、２０４：チャネル幅選択制御部、２０５：ＵＩ制御部、２０６：表示部、２０７：記憶部、９０８：バッファリング制御部、１３０８：映像種別判断部、１３０９：撮像制御部

Claims (15)

1. 動作中に他のチャネルへ移る期間がある第１の動作モードと、動作中に前記期間がない第２の動作モードとの、いずれかで動作できる通信装置であって、
   一定期間にわたって連続的にデータ通信が行われるかを判定する判定手段と、
   前記判定の結果に基づいて、前記第１の動作モードと、前記第２の動作モードとのいずれで動作するかを選択する選択手段と、
   選択された動作モードでデータ通信を行う通信手段と、
   を有することを特徴とする通信装置。
2. 前記選択手段は、一定期間にわたって連続的にデータ通信が行われると判定された場合に、前記第２の動作モードを選択する、
   ことを特徴とする請求項１に記載の通信装置。
3. 前記選択手段は、一定期間にわたって連続的にデータ通信が行われると判定されなかった場合に、前記第１の動作モードを選択する、
   ことを特徴とする請求項１又は２に記載の通信装置。
4. 前記判定手段は、一定期間にわたって連続的にデータ通信が行われると判定した場合、さらに、当該連続的なデータ通信における許容遅延時間が、前記第１の動作モードにおいて前記他のチャネルへ移っている前記期間に関する時間を超えるか否かを判定し、
   前記選択手段は、一定期間にわたって連続的にデータ通信が行われると判定されたか否か、及び、前記許容遅延時間が前記第１の動作モードにおいて前記他のチャネルへ移っている前記期間に関する時間を超えるか否かに基づいて、前記第１の動作モードと、前記第２の動作モードとのいずれで動作するかを選択する、
   ことを特徴とする請求項１から３のいずれか１項に記載の通信装置。
5. 前記選択手段は、一定期間にわたって連続的にデータ通信が行われると判定され、かつ、前記許容遅延時間が前記第１の動作モードにおいて前記他のチャネルへ移っている前記期間に関する時間を超える場合、前記第１の動作モードを選択する、
   ことを特徴とする請求項４に記載の通信装置。
6. 前記選択手段は、一定期間にわたって連続的にデータ通信が行われると判定され、かつ、前記許容遅延時間が前記第１の動作モードにおいて前記他のチャネルへ移っている前記期間に関する時間を超えない場合、前記第２の動作モードを選択する、
   ことを特徴とする請求項４又は５に記載の通信装置。
7. 前記許容遅延時間は、前記データ通信の相手の装置から通知される、
   ことを特徴とする請求項４から６のいずれか１項に記載の通信装置。
8. 前記許容遅延時間は、前記データ通信において通信されるデータから判定される、
   ことを特徴とする請求項４から６のいずれか１項に記載の通信装置。
9. 前記第１の動作モードにおいて前記他のチャネルへ移っている前記期間に関する時間は、前記第１の動作モードにおいて前記他のチャネルへ移っている前記期間に等しい又は当該期間を超える所定時間である、
   ことを特徴とする請求項４から８のいずれか１項に記載の通信装置。
10. 前記選択手段は、前記判定手段が一定期間にわたって連続的にデータ通信が行われると判定した場合、当該連続的なデータ通信において通信されるデータの種別に基づいて、前記第１の動作モードと、前記第２の動作モードとのいずれで動作するかを選択する、
    ことを特徴とする請求項１から３のいずれか１項に記載の通信装置。
11. 前記種別は、リアルタイム性が求められる種別を含み、
    前記選択手段は、リアルタイム性が求められる種別のデータに対しては、前記第２の動作モードを選択する、
    ことを特徴とする請求項１０に記載の通信装置。
12. 前記種別の情報は、前記データ通信の相手の装置から通知される、
    ことを特徴とする請求項１０又は１１に記載の通信装置。
13. 前記第１の動作モードは、前記第２の動作モードより高速通信が可能な動作モードである、
    ことを特徴とする請求項１から１２のいずれか１項に記載の通信装置。
14. 動作中に他のチャネルへ移る期間がある第１の動作モードと、動作中に前記期間がない第２の動作モードとの、いずれかで動作できる通信装置の制御方法であって、
    判定手段が、一定期間にわたって連続的にデータ通信が行われるかを判定する判定工程と、
    選択手段が、前記判定の結果に基づいて、前記第１の動作モードと、前記第２の動作モードとのいずれで動作するかを選択する選択工程と、
    通信手段が、選択された動作モードでデータ通信を行う通信工程と、
    を有することを特徴とする制御方法。
15. 動作中に他のチャネルへ移る期間がある第１の動作モードと、動作中に前記期間がない第２の動作モードとの、いずれかで動作できる通信装置に備えられたコンピュータに、
    一定期間にわたって連続的にデータ通信が行われるかを判定する判定工程と、
    前記判定の結果に基づいて、前記第１の動作モードと、前記第２の動作モードとのいずれで動作するかを選択する選択工程と、
    選択された動作モードでデータ通信を行う通信工程と、
    を実行させるためのプログラム。

Images