(57)【要約】【課題】無線通信により画像の送信または受信を行っている通信装置が他の通信装置の探索を行ったことにより生じる画像の乱れを低減することを目的とする。【解決手段】無線通信を利用して対向装置に動画データを送信する通信装置は、対向装置に動画データをストリーミングにより送信する。通信装置は、記対向装置が他の無線通信装置の探索を実行中か否かを判定し、対向装置が探索を実行中であると判定した場合に、送信している動画データの通信量を抑制する。【選択図】  図３
2019033444.tif 000002
【特許請求の範囲】
【請求項１】
無線通信を利用して対向装置に動画データを送信する通信装置であって、
前記対向装置に動画データをストリーミングにより送信する送信手段と、
前記対向装置が他の無線通信装置の探索を実行中か否かを判定する判定手段と、
前記対向装置が前記探索を実行中であると判定した場合に、前記送信手段が送信する動画データの通信量を抑制する抑制手段と、を備えることを特徴とする通信装置。
【請求項２】
前記抑制手段は、前記判定手段により前記探索が終了したと判定された場合に、前記送信手段が送信する動画データの通信量が抑制された状態を抑制前の状態に戻すことを特徴とする請求項１に記載の通信装置。
【請求項３】
前記送信手段は、
基準フレームと差分フレームに符号化された動画データを送信し、
前記判定手段により前記探索が実行中であると判定されている間、前記基準フレームの送信を禁止する、ことを特徴とする請求項１または２に記載の通信装置。
【請求項４】
前記送信手段は、
前記探索が終了したとの判定により動画データの通信量が抑制された状態が抑制前の状態に戻されたことに応じて、前記基準フレームを送信する、ことを特徴とする請求項３に記載の通信装置。
【請求項５】
無線通信を利用して対向装置から動画データを受信する通信装置であって、
前記対向装置から動画データをストリーミングにより受信する受信手段と、
前記対向装置が他の無線通信装置の探索を実行中か否かを判定する判定手段と、
前記対向装置が前記探索を実行中であると判定した場合に、前記対向装置が送信する動画データの通信量を抑制するように、前記対向装置に要求する要求手段と、を備えることを特徴とする通信装置。
【請求項６】
前記要求手段は、前記判定手段により前記探索が終了したと判定された場合に、前記対向装置が送信する動画データの通信量が抑制された状態を抑制前の状態に戻すように、前記対向装置に要求することを特徴とする請求項５に記載の通信装置。
【請求項７】
前記動画データは基準フレームと差分フレームに符号化されており、
前記判定手段により前記探索が実行中であると判定されている間、前記基準フレームの要求の送信を禁止する、ことを特徴とする請求項５または６に記載の通信装置。
【請求項８】
前記要求手段は、前記判定手段により前記探索が終了したと判定されたことに応じて、前記基準フレームの送信を前記対向装置に要求する、ことを特徴とする請求項７に記載の通信装置。
【請求項９】
前記判定手段は、前記対向装置から前記探索の間に発行される所定の信号を受信したことに応じて前記探索が開始したと判定することを特徴とする請求項１乃至８のいずれか１項に記載の通信装置。
【請求項１０】
前記判定手段は、前記探索が開始したと判定した後、前回の所定の信号の受信から所定時間内に次の所定の信号を受信しなかったことに応じて前記探索の終了と判定する、ことを特徴とする請求項９に記載の通信装置。
【請求項１１】
前記所定の信号は、ＩＥＥＥ８０２．１１シリーズで規定されたＰｒｏｂｅ  Ｒｅｑｕｅｓｔであることを特徴とする請求項９または１０に記載の通信装置。
【請求項１２】
無線通信を利用して対向装置から動画データを受信する通信装置であって、
前記対向装置から動画データをストリーミングにより受信する受信手段と、
前記対向装置が他の無線通信装置の探索を実行中か否かを判定する判定手段と、
複数のチャネルを切り換えながら他の無線装置を探索するための信号を送信することにより他の無線通信装置を探索する探索手段と、
前記探索手段による探索の実行中、前記対向装置が送信する動画データの通信量を抑制するように、前記対向装置に要求する要求手段と、を備えることを特徴とする通信装置。
【請求項１３】
前記要求手段は、前記探索が終了したことに応じて、前記対向装置が送信する動画データの通信量が抑制された状態を抑制前の状態に戻すように、前記対向装置に要求することを特徴とする請求項１２に記載の通信装置。
【請求項１４】
前記動画データは基準フレームと差分フレームに符号化されており、
前記探索の実行中は、前記基準フレームの要求の送信を禁止する、ことを特徴とする請求項１２または１３に記載の通信装置。
【請求項１５】
前記要求手段は、前記探索が終了したことに応じて、前記基準フレームの送信を前記対向装置に要求する、ことを特徴とする請求項１４に記載の通信装置。
【請求項１６】
無線通信を利用して対向装置に動画データを送信する通信装置であって、
前記対向装置に動画データをストリーミングにより送信する送信手段と、
複数のチャネルを切り換えながら他の無線装置を探索するための信号を送信することにより他の無線通信装置を探索する探索手段と、
前記探索の実行中、前記送信手段が送信する動画データの通信量を抑制する抑制手段と、を備えることを特徴とする通信装置。
【請求項１７】
前記抑制手段は、前記探索が終了したことに応じて、前記送信手段が送信する動画データの通信量が抑制された状態を抑制前の状態に戻すことを特徴とする請求項１６に記載の通信装置。
【請求項１８】
前記送信手段は、
基準フレームと差分フレームに符号化された動画データを送信し、
前記探索手段による前記探索の実行中、前記基準フレームの送信を禁止する、ことを特徴とする請求項１６または１７に記載の通信装置。
【請求項１９】
前記送信手段は、
動画データの通信量が抑制された状態が抑制前の状態に戻されたことに応じて前記基準フレームを送信する、ことを特徴とする請求項１８に記載の通信装置。
【請求項２０】
前記動画データの通信量の抑制は、動画データの解像度、ビットレート、フレームレートの少なくとも１つを下げることによりなされることを特徴とする請求項１乃至１９のいずれか１項に記載の通信装置。
【請求項２１】
無線通信により接続された第１の通信装置と第２の通信装置を備える通信システムであって、
前記第１の通信装置から前記第２の通信装置へ無線通信により動画データをストリーミングにより送信する送信手段と、
前記第１または第２の通信装置において複数のチャネルを切り換えながら他の無線装置を探索するための信号を送信することにより他の無線通信装置を探索する探索手段と、
前記探索手段による探索の実行中、前記送信手段により送信される前記動画データの通信量を抑制する抑制手段と、を備えることを特徴とする通信システム。
【請求項２２】
無線通信を利用して対向装置に動画データを送信する通信装置の制御方法であって、
前記対向装置に動画データをストリーミングにより送信する送信工程と、
前記対向装置が他の無線通信装置の探索を実行中か否かを判定する判定工程と、
前記対向装置が前記探索を実行中であると判定した場合に、前記送信工程で送信される動画データの通信量を抑制する抑制工程と、を備えることを特徴とする通信装置の制御方法。
【請求項２３】
無線通信を利用して対向装置から動画データを受信する通信装置の制御方法であって、
前記対向装置から動画データをストリーミングにより受信する受信工程と、
前記対向装置が他の無線通信装置の探索を実行中か否かを判定する判定工程と、
前記対向装置が前記探索を実行中であると判定した場合に、前記対向装置が送信する動画データの通信量を抑制するように、前記対向装置に要求する要求工程と、を備えることを特徴とする通信装置の制御方法。
【請求項２４】
無線通信を利用して対向装置から動画データを受信する通信装置の制御方法であって、
前記対向装置から動画データをストリーミングにより受信する受信工程と、
前記対向装置が他の無線通信装置の探索を実行中か否かを判定する判定工程と、
複数のチャネルを切り換えながら他の無線装置を探索するための信号を送信することにより他の無線通信装置を探索する探索工程と、
前記探索工程による探索の実行中、前記対向装置が送信する動画データの通信量を抑制するように、前記対向装置に要求する要求工程と、を備えることを特徴とする通信装置の制御方法。
【請求項２５】
無線通信を利用して対向装置に動画データを送信する通信装置の制御方法であって、
前記対向装置に動画データをストリーミングにより送信する送信工程と、
複数のチャネルを切り換えながら他の無線装置を探索するための信号を送信することにより他の無線通信装置を探索する探索工程と、
前記探索の実行中、前記送信工程で送信される動画データの通信量を抑制する抑制工程と、を備えることを特徴とする通信装置の制御方法。
【請求項２６】
無線通信により接続された第１の通信装置と第２の通信装置を備える通信システムの制御方法であって、
前記第１の通信装置から前記第２の通信装置へ無線通信により動画データをストリーミングにより送信する送信工程と、
前記第１または第２の通信装置において複数のチャネルを切り換えながら他の無線装置を探索するための信号を送信することにより他の無線通信装置を探索する探索工程と、
前記探索工程による探索の実行中、前記送信工程により送信される前記動画データの通信量を抑制する抑制工程と、を備えることを特徴とする通信システムの制御方法。
【請求項２７】
請求項２２乃至２５のいずれか１項に記載の通信装置の制御方法の各工程をコンピュータに実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、無線通信装置間で無線通信を行うための無線通信装置、無線通信方法および無線通信システムに関する。
【背景技術】
【０００２】
無線通信によりディスプレイ画面を他のディスプレイにミラーリング表示する技術がＭｉｒａｃａｓｔ（登録商標）（Ｗｉ−Ｆｉ  Ｄｉｓｐｌａｙ）として標準化されている。Ｍｉｒａｃａｓｔ（登録商標）では、表示画面の画像データを送信する側のデバイスをＳｏｕｒｃｅと呼び、画像データを受信し表示する側のデバイスをＳｉｎｋと呼ぶ。Ｍｉｒａｃａｓｔでは、ＳｏｕｒｃｅとＳｉｎｋの間の無線通信技術としてＷｉ−Ｆｉ  Ｄｉｒｅｃｔ（登録商標）が使用されている。Ｗｉ−Ｆｉ  Ｄｉｒｅｃｔでは、ＡＰ（Ａｃｃｅｓｓ  Ｐｏｉｎｔ）としての役割を担う１台のデバイス（Ｇｒｏｕｐ  Ｏｗｎｅｒ（ＧＯ））と、ＳＴＡ（Ｓｔａｔｉｏｎ）として動作する１台以上のＣｌｉｅｎｔでグループ（Ｐ２Ｐ  Ｇｒｏｕｐ）が構成される。Ｍｉｒａｃａｓｔでは、ＳｏｕｒｃｅがＧＯとＣｌａｉｅｎｔのいずれか一方の役割で動作し、Ｓｉｎｋが他方の役割で動作する。
【０００３】
Ｐ２Ｐ  Ｇｒｏｕｐ内の通信はＧＯが指定するオペレーティングチャネルで行われる。すなわち、Ｍｉｒａｃａｓｔにおいて、ＳｏｕｒｃｅとＳｉｎｋは、オペレーティングチャネルで画像データの送受信を行う。また、Ｐ２Ｐ  Ｇｒｏｕｐ形成後のＧＯまたはＣｌｉｅｎｔはＰ２Ｐ  Ｇｒｏｕｐに参加していない周辺デバイスを探索（スキャン）することが可能である。探索において、ＧＯまたはＣｌｉｅｎｔは、オペレーティングチャネルを含めた全チャネルを遷移しながら無線パケット（Ｐｒｏｂｅ  Ｒｅｑｕｅｓｔ）を送信する。このＰｒｏｂｅ  Ｒｅｑｕｅｓｔを受け取った周辺デバイスが返送するＰｒｏｂｅ  Ｒｅｓｐｏｎｓｅを受信することで、ＧＯまたはＣｌｉｅｎｔは周辺デバイスを探索する。
【０００４】
通信インターフェースの物理層（ＰＨＹ：Ｐｈｙｓｉｃａｌ  Ｌａｙｅｒ）が１つのＳｏｕｒｃｅまたはＳｉｎｋではオペレーティングチャネルと異なるチャネルに遷移している間、Ｐ２Ｐ  Ｇｒｏｕｐ内の通信は出来ない。このため、Ｍｉｒａｃａｓｔによる画像データの送受信中にＳｏｕｒｃｅまたはＳｉｎｋが探索を行うと、オペレーティングチャネル以外のチャネルで動画データの送受信ができなくなる。例えば、Ｓｏｕｒｃｅが動画データ送信中に周辺の無線デバイスの探索を実施すると、チャネルがオペレーティングチャネル以外に遷移している間は画像データをＳｉｎｋへ送信することが出来ない。他方、ＳｉｎｋがＳｏｕｒｃｅから動画データを受信中に探索を実施すると、チャネルがオペレーティングチャネル以外に遷移している間はＳｏｕｒｃｅからの画像データを受信することが出来ない。
【０００５】
ディスプレイ画面のミラーリングでは、Ｓｏｕｒｃｅが動画データ（画面データ）を符号化してＳｉｎｋに送信し、Ｓｉｎｋが符号化データを動画データに復号して表示する。Ｈ．２６４などで規定される符号化処理では、前後のフレーム間差分を用いない基準フレーム（Ｉフレーム）と、前後のフレーム間差分を利用した差分フレーム（Ｐフレーム、Ｂフレーム）を送信する。上述のように、探索により画像データの送受信ができなくなり基準フレームまたは差分フレームの一部が欠落すると、Ｓｉｎｋは正常に画像を復号できなくなり、画像が乱れてしまう。そして、一度発生した画像の乱れは、参照元のフレームデータが損失しているため、次の基準フレームを受信するまで継続してしまう。
【０００６】
画像データの送受信中（ストリーミング中）のチャネル切り替えにより画像データの送受信が出来なくなることに対して、特許文献１では、無線通信装置のチャネル切り替え自体を制限している。また、特許文献２では、１つのチャネルのスキャンが終了するごとにチャネルを元のチャネル（オペレーティングチャネル）に戻すことを提案している。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２０１６−１４９６４８号公報
【特許文献２】特開２００７−３０６３７５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかしながら、特許文献１では、無線通信装置のチャネル切り替え自体を制限しているため、ＧＯまたはＣｌｉｅｎｔによる探索はできなくなる。また、特許文献２では、１つのチャネルのスキャンが終わるごとにチャネルをオペレーティングチャネルに戻すことで通信不能となる時間を短縮することができるが、画像データの通信帯域の低下は避けられず、通信帯域を超えた分の画像データが消失する。
【０００９】
上記課題を鑑み、本発明は、無線通信により画像の送信または受信を行っている通信装置が他の通信装置の探索を行ったことにより生じる画像の乱れを低減する。
【課題を解決するための手段】
【００１０】
上記の目的を達成するための、本発明の一態様による無線通信装置は以下の構成を備える。すなわち、
無線通信を利用して対向装置に動画データを送信する通信装置であって、
前記対向装置に動画データをストリーミングにより送信する送信手段と、
前記対向装置が他の無線通信装置の探索を実行中か否かを判定する判定手段と、
前記対向装置が前記探索を実行中であると判定した場合に、前記送信手段が送信する動画データの通信量を抑制する抑制手段と、を備える。
【発明の効果】
【００１１】
本発明によれば、無線通信により画像の送信または受信を行っている通信装置が他の通信装置の探索を行ったことにより生じる画像の乱れが低減する。
【図面の簡単な説明】
【００１２】
【図１】実施形態による無線通信システムの構成例を示す図。
【図２】第１実施形態〜第４実施形態に係る無線通信装置の構成例を示すブロック図。
【図３】第１実施形態における、動画データのストリーミングのシーケンス図。
【図４】第１実施形態における、Ｐｒｏｂｅ  Ｒｅｑｕｅｓｔ受信判定処理のフローチャートである。
【図５】第１実施形態における、動画データ抑制開始処理のフローチャート。
【図６】第１実施形態における、Ｐｒｏｂｅ  Ｒｅｑｕｅｓｔ停止判定処理のフローチャート。
【図７】第１実施形態における、動画データ抑制終了処理のフローチャート。
【図８】第２実施形態における、動画データのストリーミングのシーケンス図。
【図９】（ａ）は第２実施形態における、Ｐｒｏｂｅ  Ｒｅｑｕｅｓｔ受信判定処理のフローチャート、（ｂ）は動画データ抑制開始処理のフローチャート。
【図１０】（ａ）は第２実施形態における、Ｐｒｏｂｅ  Ｒｅｑｕｅｓｔ停止判定処理のフローチャート、（ｂ）は動画データ抑制終了処理のフローチャート。
【図１１】第３実施形態における、動画データのストリーミングのシーケンス図。
【図１２】第４実施形態における、動画データのストリーミングのシーケンス図。
【発明を実施するための形態】
【００１３】
＜第１実施形態＞
図１は、以下の各実施形態に係る無線通信システムの構成例を示す図である。本無線通信システムは、例えば、Ｓｏｕｒｃｅ１０１、Ｓｉｎｋ１０２、周辺デバイス１０３を含む複数の無線通信装置と無線ネットワーク１０４とを含んで構成される。Ｓｏｕｒｃｅ１０１と、Ｓｉｎｋ１０２とは、無線ネットワーク１０４により接続され、互いを通信の対向装置として通信を行う。
【００１４】
Ｓｏｕｒｃｅ１０１は、Ｗｉ−Ｆｉ  Ｄｉｓｐｌａｙ規格に準拠したＳｏｕｒｃｅとして機能する無線通信装置である。Ｓｉｎｋ１０２は、Ｗｉ−Ｆｉ  Ｄｉｓｐｌａｙ規格に準拠したＳｉｎｋとして機能する無線通信装置である。ディスプレイ画面のミラーリングにおいて、Ｓｏｕｒｃｅ１０１は、後述する表示部３０（画面）に表示されている画像と同じ画像を、動画データ（動画ストリーム）として、Ｓｉｎｋ１０２に送信する。Ｓｉｎｋ１０２はＳｏｕｒｃｅ１０１から動画データを受信し、その動画データを表示する。なお、以下では、動画データは、音声を含む動画データとして説明するが、音声を含まない動画データでも良いし、音声のみのデータであっても良い。
【００１５】
無線ネットワーク１０４は、Ｓｏｕｒｃｅ１０１およびＳｉｎｋ１０２が参加するＰ２Ｐ  Ｇｒｏｕｐである。Ｓｏｕｒｃｅ１０１およびＳｉｎｋ１０２は、Ｗｉ−Ｆｉ  Ｄｉｒｅｃｔによって接続してＰ２Ｐ  Ｇｒｏｕｐを構成し、動画データのストリーミングに係るデータ通信を行う。周辺デバイス１０３は、無線ネットワーク１０４（Ｐ２Ｐ  Ｇｒｏｕｐ）に未参加の無線通信装置である。なお、図１に示す無線通信システムにおいては、Ｓｏｕｒｃｅ１０１、Ｓｉｎｋ１０２、および周辺デバイス１０３をそれぞれ１台のみとしているが、Ｓｏｕｒｃｅ１０１、Ｓｉｎｋ１０２、および周辺デバイス１０３の台数は図示の例に限定されるものではない。なお、無線ネットワーク１０４において、Ｓｏｕｒｃｅ１０１とＳｉｎｋ１０２のいずれがＧＯであってもよい。
【００１６】
次に、第１実施形態に係るＳｏｕｒｃｅ１０１、Ｓｉｎｋ１０２、および周辺デバイス１０３の構成例について図２を用いて説明する。なお、図２では、Ｓｏｕｒｃｅ１０１、Ｓｉｎｋ１０２、および周辺デバイス１０３として利用可能な無線通信装置１００の構成を示している。無線通信装置１００は、ハードウェア構成として、ＣＰＵ１０、入力部２０、表示部３０、メモリ４０、通信部５０、および記憶部６０等を備え、これらハードウェアは内部バスで相互に接続されている。
【００１７】
ＣＰＵ１０は無線通信装置１００における全体の制御を司る。入力部２０は、例えば、キーボード、マウス、タッチパネル等を備え、ユーザからの各種入力を受け付ける。表示部３０は、例えば、液晶モニタを具備し、ＣＰＵ１０の制御下で各種の表示を行う。メモリ４０はＲＡＭおよびＲＯＭ等で構成される。なお、図２の無線通信装置１００は表示部３０を内蔵する構成であるが、これに限られるものではなく、表示部３０を備えず、外部接続された表示装置に画像などを表示するようにしても良い。通信部５０は無線通信を行うためのインターフェースであって、他の無線通信装置とデータ送受信を行う。
【００１８】
記憶部６０には、ソフトウェアであるオペレーティングシステム（ＯＳ）１１０、無線通信制御部１２０、情報管理部１３０、コーデック制御部１４０、画像通信制御部１５０、表示制御部１６０を記憶している。なお、これらのソフトウェアはメモリ４０に読み出されて、ＣＰＵ１０により実行されることで、各機能部が実現される。
【００１９】
無線通信制御部１２０は他の無線通信装置との無線通信の接続を管理し、また、他の無線通信装置に対するコマンドの送受信を制御する。探索信号送受信部１２１は、他のデバイスを探索するための信号（例えば、Ｐｒｏｂｅ  Ｒｅｑｕｅｓｔ）やその探索信号に対する応答（例えば、Ｐｒｏｂｅ  Ｒｅｓｐｏｎｓｅ）を送受信する。Ｐｒｏｂｅ  Ｒｅｑｕｅｓｔ、Ｐｒｏｂｅ  Ｒｅｓｐｏｎｓｅは、それぞれ、ＩＥＥＥ８０２．１１シリーズで規定された信号である。情報管理部１３０は、他の無線通信装置とのネゴシエーションまたは探索信号送受信部１２１によって探索した他の無線通信装置に関する情報（無線通信装置識別情報、解像度に関する情報など）を管理する。なお、探索に関わる信号においてＷｉ−Ｆｉ  Ｄｉｒｅｃｔで規定された情報要素が用いられてもよい
【００２０】
コーデック制御部１４０は、無線通信装置１００がＳｏｕｒｃｅ１０１として動作している場合、表示制御部１６０またはその他の記憶部６０から非符号化画像および／または非符号化音声情報を取得し情報の符号化を行う。この符号化によって生成された基準フレームと差分フレームは画像通信制御部１５０に渡される。また、無線通信装置１００がＳｉｎｋとして動作している場合、Ｓｏｕｒｃｅ１０１から無線通信制御部１２０により受信した符号化画像および／または符号化音声情報を取得し情報の復号を行い、表示制御部１６０へ渡す。
【００２１】
画像通信制御部１５０は上記の符号化画像および／または符号化音声情報の対向装置との通信（動画データにおける基準フレームや差分フレームの送受信）を制御する。表示制御部１６０は、表示部３０（表示デバイス）を制御する。
【００２２】
図３は、第１実施形態に係る無線通信システムにおいてＳｏｕｒｃｅ１０１からＳｉｎｋ１０２に動画データのストリーミング（ミラーリング）を行う場合のシーケンス図である。なお、第１実施形態では、Ｓｏｕｒｃｅ１０１とＳｉｎｋ１０２による１対１のストリーミングにおいて、Ｓｉｎｋ１０２がＳｏｕｒｃｅ１０１から動画データを受信している間に他の無線通信装置を探索する場合について説明する。
【００２３】
初めに、Ｓｏｕｒｃｅ１０１とＳｉｎｋ１０２は、Ｗｉ−Ｆｉ  Ｄｉｒｅｃｔにより無線接続処理を行う（ステップＳ３０１）。次に、Ｓｏｕｒｃｅ１０１とＳｉｎｋ１０２は、Ｗｉ−Ｆｉ  Ｍｉｒａｃａｓｔ接続処理を行う（ステップＳ３０２）。なお、これ以降、特に指定しない場合にはＷｉ−Ｆｉ  Ｄｉｓｐｌａｙ規格に準拠する接続処理が実行されるものとして説明する。また、ステップ３０２において、Ｓｏｕｒｃｅ１０１とＳｉｎｋ１０２がネゴシエーションによって決定した動画の解像度およびビットレートは通常解像度および通常ビットレートである。なお、本実施形態では、通常解像度とは、フルＨＤ（Ｈｉｇｈ  Ｄｉｆｉｎｉｔｉｏｎ、１９２０×１０８０ピクセル）であって、通常ビットレートとは、１５Ｍｂｐｓである。
【００２４】
その後、Ｓｏｕｒｃｅ１０１はＳｉｎｋ１０２に対して動画データの送信を開始する。Ｓｏｕｒｃｅ１０１はＳｉｎｋ１０２に対して、通常解像度および通常ビットレートの動画データを送信し、Ｓｉｎｋ１０２は、Ｓｏｕｒｃｅ１０１から受信した動画データを表示する（ステップＳ３１０）。なお、後述する動画データ抑制開始処理（ステップＳ３４０）を行う前の動画データは、解像度を通常解像度とし、ビットレートを通常ビットレートとする。
【００２５】
Ｓｏｕｒｃｅ１０１から動画データの受信中にＳｉｎｋ１０２が周辺デバイス群（周辺デバイス１０３およびＳｏｕｒｃｅ１０１）の探索（スキャン）を開始する（ステップＳ３２０）。ここでの探索は、例えば、ユーザ操作に基づいて行われ、Ｓｏｕｒｃｅ１０１とは異なるＳｏｕｒｃｅ機器からの画像受信を追加したい場合などが考えられる。探索において、Ｓｉｎｋ１０２は、チャネルを遷移しながら所定の期間にわたってＰｒｏｂｅ  Ｒｅｑｕｅｓｔを送信し続ける（ステップＳ３２１）。なお、Ｓｉｎｋ１０２がオペレーティングチャネル以外のチャネルに遷移している間は、動画データを受信できない。そのため、Ｓｉｎｋ１０２ではＳｏｕｒｃｅ１０１からの動画データを正しく復号することができず、表示部３０に表示される画像が乱れる可能性がある。
【００２６】
周辺デバイス１０３は、ステップＳ３２１で送信されたＰｒｏｂｅ  Ｒｅｑｕｅｓｔを受信した場合、Ｓｉｎｋ１０２へＰｒｏｂｅ  Ｒｅｓｐｏｎｓｅで応答する（ステップＳ３２２）。なお、図３では省略しているが、周辺デバイス１０３は、Ｓｉｎｋ１０２からＰｒｏｂｅ  Ｒｅｑｕｅｓｔを受信する毎にＰｒｏｂｅ  Ｒｅｓｐｏｎｓｅを応答し続ける。
【００２７】
Ｓｏｕｒｃｅ１０１も周辺デバイス１０３と同様にＳｉｎｋ１０２からＰｒｏｂｅ  Ｒｅｑｕｅｓｔを受信する（ステップＳ３２１）。これによりＳｏｕｒｃｅ１０１は、Ｓｉｎｋ１０２における周辺デバイスの探索の開始を検知する（ステップＳ３３０）。なお、ステップＳ３３０におけるＰｒｏｂｅ  Ｒｅｑｕｅｓｔ受信判定処理の詳細は、図４を用いて説明する。Ｓｉｎｋ１０２における探索の開始を検知したＳｏｕｒｃｅ１０１は、動画データ抑制開始処理を開始し、動画データのビットレートおよび／または解像度を下げることで動画データの通信量を抑制する（ステップＳ３４０）。なお、動画データ抑制開始処理の詳細は、図５を用いて説明する。
【００２８】
動画データ抑制開始処理において、Ｓｏｕｒｃｅ１０１は、送信する動画データのビットレートおよび／または解像度が変化したことをＳｉｎｋ１０２に通知する（ステップＳ３４１）。通知の方法としては、例えば、ＲＴＳＰ（Ｒｅａｌ  Ｔｉｍｅ  Ｓｔｒｅａｍｉｎｇ  Ｐｒｏｔｏｃｏｌ）プロトコルを用いてＡＶ  Ｆｏｒｍａｔ  Ｃｈａｎｇｅメッセージを送信する方法がある。Ｓｏｕｒｃｅ１０１は、ステップＳ３４１で送信した通知に対する変更承諾応答をＳｉｎｋ１０２から受信すると、送信中の動画データの解像度および／またはビットレートを低下させる。すなわち、Ｓｏｕｒｃｅ１０１は、ステップＳ３１０で送信した動画データより低解像度および／または低ビットレートの動画データをＳｉｎｋ１０２に送信する（ステップＳ３４２）。以降、Ｐｒｏｂｅ  Ｒｅｑｕｅｓｔ停止判定処理（ステップＳ３６０）によりＰｒｏｂｅ  Ｒｅｑｕｅｓｔの送信が停止したと判定されるまでは、探索の実行中であるとして、低解像度および／または低ビットレートで動画データを送信する。
【００２９】
Ｓｉｎｋ１０２は他の無線通信装置の探索の終了に伴いＰｒｏｂｅ  Ｒｅｑｕｅｓｔの送信を停止し、周辺デバイス群の探索を終了する（ステップＳ３５０）。なお、Ｐｒｏｂｅ  Ｒｅｑｕｅｓｔの送信は、あらかじめ設定した所定の期間経過後、または、ユーザ操作に応じて、終了する。Ｓｏｕｒｃｅ１０１はＳｉｎｋ１０２の探索の終了により、前回のＰｒｏｂｅ  Ｒｅｑｕｅｓｔの受信からＰｒｏｂｅ  Ｒｅｑｕｅｓｔを所定時間受信しなかった場合、Ｓｉｎｋ１０２の探索が停止したと判定する（Ｐｒｏｂｅ  Ｒｅｑｕｅｓｔ停止判定処理）（ステップＳ３６０）。なお、Ｐｒｏｂｅ  Ｒｅｑｕｅｓｔ停止判定処理の詳細は、図６を用いて説明する。
【００３０】
Ｐｒｏｂｅ  Ｒｅｑｕｅｓｔの停止の検出により探索が終了したと判定した場合、Ｓｏｕｒｃｅ１０１は動画データ抑制を終了する処理（動画データ抑制終了処理）を行う（ステップＳ３７０）。なお、動画データ抑制終了処理の詳細は、図７を用いて説明する。動画データ抑制終了処理により、Ｓｏｕｒｃｅ１０１は、動画データのビットレートと解像度を動画データ抑制前のビットレートと解像度（ステップＳ３１０）と同等のビットレートと解像度）に戻す。そして、Ｓｏｕｒｃｅ１０１は、動画データのビットレートや解像度が変化したことをＳｉｎｋ１０２に通知するため、ＲＴＳＰプロトコルを用いたＡＶ  Ｆｏｒｍａｔ  Ｃｈａｎｇｅメッセージを送信する（ステップＳ３７１）。
【００３１】
Ｓｏｕｒｃｅ１０１は、Ｓｉｎｋ１０２に対して、ステップＳ３１０で送信したのと同等の通常解像度および通常ビットレートの動画データを送信する（ステップＳ３７２）。このとき、Ｓｉｎｋ１０２に表示される画像の乱れを早急に復帰させるために、Ｓｏｕｒｃｅ１０１は、Ｓｉｎｋ１０２に対して、動画データの基準フレームを送信し、動画データのリフレッシュを行う。その後、動画データにおける基準フレームおよび／または差分フレームを送信する。なお、Ｓｏｕｒｃｅ１０１は、Ｓｉｎｋ１０２に対して、動画データの基準フレームを送信すると説明したが、動画データのリフレッシュが不要な場合には、動画データの通信量を抑制するため、動画データにおける基準フレームを送信しなくても良い。
【００３２】
図４は、第１実施形態に係る無線通信システムにおいて、Ｓｏｕｒｃｅ１０１が行うＰｒｏｂｅ  Ｒｅｑｕｅｓｔ受信判定処理（図３のＳ３３０）を説明するためのフローチャートである。なお、Ｐｒｏｂｅ  Ｒｅｑｕｅｓｔ受信判定処理は主として探索信号送受信部１２１が行う。
【００３３】
Ｓｏｕｒｃｅ１０１は、受信したＰｒｏｂｅ  Ｒｅｑｕｅｓｔの送信元を判定する（ステップＳ４０１）。なお、Ｓｏｕｒｃｅ１０１は、動画データの送信先に指定したＳｉｎｋ１０２の識別情報と、Ｓｉｎｋ１０２から受信したＰｒｏｂｅ  Ｒｅｑｕｅｓｔ内に含まれる送信元の識別情報を比較する。なお、識別情報は、無線通信装置を識別（特定）するための情報である。例えば、ＩＰアドレス、ＭＡＣアドレス、無線通信装置名などを識別情報として用いることができるが、これらに限定されるものではない。さらに、識別情報はこれらの情報を組み合わせたものであってもよい。
【００３４】
Ｓｏｕｒｃｅ１０１は、識別情報の比較により、受信したＰｒｏｂｅ  Ｒｅｑｕｅｓｔの送信元が動画データの送信先デバイスと同じである判定した場合（ステップＳ４０１でＹＥＳ）、動画データ抑制開始処理を開始する（ステップＳ４０２）。動画データ抑制開始処理は、主としてコーデック制御部と画像通信制御部１５０により実行される。なお、動画データ抑制開始処理については、図５を用いて詳述する。一方、受信したＰｒｏｂｅ  Ｒｅｑｕｅｓｔの送信元が動画データの送信先デバイスと異なると判定された場合（ステップＳ４０１でＮＯ）、Ｓｏｕｒｃｅ１０１は、Ｐｒｏｂｅ  Ｒｅｑｕｅｓｔ受信判定処理（ステップＳ４０１の処理）を継続する。
【００３５】
図５は、第１実施形態に係る無線通信システムにおいて、Ｓｏｕｒｃｅ１０１が行う動画データ抑制開始処理を説明するためのフローチャートである。
【００３６】
まず、Ｓｏｕｒｃｅ１０１は、現在の解像度（動画データ抑制開始時点の解像度）よりも低く、Ｓｏｕｒｃｅ１０１およびＳｉｎｋ１０２ともに使用可能な解像度の有無を判定する（ステップＳ５０１）。なお、ステップＳ３０２で説明したＷｉ−Ｆｉ  Ｍｉｒａｃａｓｔ接続処理において、Ｓｏｕｒｃｅ１０１とＳｉｎｋ１０２は、解像度に関する情報をお互いに通知する。Ｓｏｕｒｃｅ１０１とＳｉｎｋ１０２は、情報管理部１３０に対向装置の解像度とビットレートに関する情報を記憶する。そのため、Ｓｏｕｒｃｅ１０１は、情報管理部１３０の情報に基づいて、現在の解像度よりも低くＳｏｕｒｃｅ１０１自身およびＳｉｎｋ１０２で使用可能な解像度の有無を判定することができる。
【００３７】
現在の解像度よりも低く使用可能な解像度が有る場合（ステップＳ５０１でＹＥＳ）、Ｓｏｕｒｃｅ１０１は、Ｓｉｎｋ１０２へ送信する動画データの解像度を変更する（通常解像度から低解像度に変更する）（ステップＳ５０２）。一方、現在の解像度（動画データ抑制開始時点の解像度）よりも低く使用可能な解像度がない場合（ステップＳ５０１でＮＯ）、ステップＳ５０２はスキップされ、処理はステップＳ５０３に進む。
【００３８】
Ｓｏｕｒｃｅ１０１は、現在のビットレート（動画データ抑制開始時点のビットレート）よりも低く、Ｓｏｕｒｃｅ１０１およびＳｉｎｋ１０２ともに使用可能なビットレートが利用可能か否かを情報管理部１３０の情報に基づいて判定する（ステップＳ５０３）。現在のビットレートよりも低いビットレートが利用可能な場合（ステップＳ５０３でＹＥＳ）、Ｓｏｕｒｃｅ１０１は、Ｓｉｎｋ１０２に対して送信する動画データのビットレートを変更する（通常ビットレートから低ビットレートに変更する）（ステップＳ５０４）。一方、現在のビットレートよりも低いビットレートが利用不可能な場合（ステップＳ５０３でＮＯ）、処理はステップＳ５０４をスキップしてステップＳ５０５に進む。
【００３９】
Ｓｏｕｒｃｅ１０１は、ステップＳ５０２において動画データの解像度変更を行った、または、ステップＳ５０４において動画データのビットレート変更を行ったか判定する（ステップＳ５０５）。動画データの解像度変更、または、動画データのビットレート変更を行ったと判定された場合（ステップＳ５０５でＹＥＳ）、Ｓｏｕｒｃｅ１０１は、解像度変更またはビットレート変更をＳｉｎｋ１０２に通知する（ステップＳ５０６）。その後、本処理を終了する。一方、ステップＳ５０２における動画データの解像度変更もステップＳ５０４における動画データのビットレート変更も行っていないと判定された場合（ステップＳ５０５でＮＯ）、そのまま本処理を終了する。なお、本処理の終了後、Ｓｏｕｒｃｅ１０１は、Ｓｉｎｋ１０２から基準フレーム送信要求を受信したとしてもその要求を無視するなどの制御を行っても良い。
【００４０】
以上のように動画データの抑制処理を行うことで探索の実行中におけるＳｏｕｒｃｅ１０１の送信バッファにおける溢れを防止し、画像の乱れを抑制することができる。なお、動画データ抑制処理を行うことで、無線通信時にノイズなどによるデータ破損に起因した画像の乱れも抑制することができる。また、無線通信において、通常は正常なデータが受信できたかをデータ受信ごとにチェックしており、異常が認められた場合、データの再送を行う仕組みがある。このデータ再送処理により通信帯域が圧迫され、逆に画像の乱れを誘発する懸念がある場合、上述した動画データ抑制の処理はノイズ対策としても有効である。
【００４１】
図６は、第１実施形態に係る無線通信システムにおいて、Ｓｏｕｒｃｅ１０１が行うＰｒｏｂｅ  Ｒｅｑｕｅｓｔ停止判定処理を説明するためのフローチャートである。Ｐｒｏｂｅ  Ｒｅｑｕｅｓｔ停止判定処理は主として探索信号送受信部１２１が行う。
【００４２】
Ｓｏｕｒｃｅ１０１は、動画データの送信先デバイスから所定時間Ｐｒｏｂｅ  Ｒｅｑｕｅｓｔを受信していないか判定する（ステップＳ６０１）。動画データの送信先デバイスから所定時間Ｐｒｏｂｅ  Ｒｅｑｕｅｓｔを受信していない場合（ステップＳ６０１でＹＥＳ）、Ｓｏｕｒｃｅ１０１は、動画データ抑制終了処理を開始する（ステップＳ６０２）。なお、動画データ抑制終了処理については、図７を用いて詳述する。一方、動画データの送信先デバイスから、前回のＰｒｏｂｅ  Ｒｅｑｕｅｓｔの受信から所定時間内にＰｒｏｂｅ  Ｒｅｑｕｅｓｔを受信した場合（ステップＳ６０１でＮＯ）、Ｐｒｏｂｅ  Ｒｅｑｕｅｓｔ停止判定処理（ステップＳ６０１の処理）を継続する。
【００４３】
図７は、第１実施形態に係る無線通信システムにおいて、Ｓｏｕｒｃｅ１０１が行う動画データ抑制終了処理を説明するためのフローチャートである。
【００４４】
Ｓｏｕｒｃｅ１０１は、図５を用いて説明した動画データ抑制開始処理において動画データの解像度を変更したか判定する（ステップＳ７０１）。なお、動画データ抑制開始処理前における動画データの解像度や動画データのビットレートはメモリ４０などに記憶されているものとする。これにより、動画データ抑制開始処理前後の動画データの解像度や動画データのビットレートの変更有無を判断することができる。動画データ抑制開始処理で動画データの解像度を変更した場合（ステップＳ７０１でＹＥＳ）、Ｓｏｕｒｃｅ１０１は、Ｓｉｎｋ１０２に送信する動画データの解像度を低解像から動画データ抑制処理前の解像度（通常解像度）へ戻す（ステップＳ７０２）。一方、Ｓｏｕｒｃｅ１０１は、動画データ抑制処理において動画データの解像度を変更していない場合（ステップＳ７０１でＮＯ）、処理はステップＳ７０２をスキップしてステップＳ７０３に進む。
【００４５】
Ｓｏｕｒｃｅ１０１は、動画データ抑制処理において動画データのビットレートを変更したか判定する（ステップＳ７０３）。動画データ抑制処理で動画データのビットレートを変更した場合（ステップＳ７０３でＹＥＳ）、Ｓｏｕｒｃｅ１０１はＳｉｎｋ１０２に送信する動画データのビットレートを低ビットレートから動画データ抑制開始前のビットレート（通常ビットレート）へ戻す（ステップＳ７０４）。一方、動画データ抑制処理において動画データのビットレートが変更されていない場合（ステップＳ７０３でＮＯ）、処理はステップＳ７０４をスキップしてステップＳ７０５に進む。
【００４６】
Ｓｏｕｒｃｅ１０１は、ステップＳ７０２において動画データの解像度変更、または、ステップＳ７０４において動画データのビットレート変更を行ったか判定する（ステップＳ７０５）。動画データの解像度変更、または、動画データのビットレート変更を行ったと判定した場合（ステップＳ７０５でＹＥＳ）、Ｓｏｕｒｃｅ１０１は、Ｓｉｎｋ１０２に対して、これを通知する（ステップＳ７０６）。すなわち、ステップＳ７０６において、Ｓｏｕｒｃｅ１０１は、低解像度から通常解像度への解像度変更および／または低ビットレートから通常ビットレートへのビットレート変更を通知する。その後、本制御フローを終了する。なお、ステップＳ７０６の通知の方法としては例えば、Ｓｏｕｒｃｅ１０１は、ＲＴＳＰプロトコルを用いたＡＶ  Ｆｏｒｍａｔ  Ｃｈａｎｇｅメッセージを送信する方法がある。一方、ステップＳ７０２における解像度変更もステップＳ７０４におけるビットレート変更も行っていないと判定された場合（ステップＳ７０５でＮＯ）、そのまま本処理を終了する。
【００４７】
以上のように、第１実施形態では、Ｓｏｕｒｃｅ１０１がＳｉｎｋ１０２に対し動画データを送信しているときに、Ｓｉｎｋ１０２はチャネルを切り替えながらＰｒｏｂｅ  Ｒｅｑｕｅｓｔを発行し、周辺デバイス１０３を探索する。このとき、Ｓｏｕｒｃｅ１０１もＳｉｎｋ１０２によって発行されたＰｒｏｂｅ  Ｒｅｑｕｅｓｔを受信するため、Ｓｏｕｒｃｅ１０１は、Ｓｉｎｋ１０２における周辺デバイス１０３の探索状況を判定することができる。その判定が探索の実行中を示す場合、Ｓｏｕｒｃｅ１０１は、動画データ抑制の処理を行う。これにより、Ｓｉｎｋ１０２のスキャン実施中の画像の乱れを抑制することができる。また、Ｓｉｎｋ１０２のスキャン終了後における画像の乱れからの復帰を早めることができる。
【００４８】
＜第２実施形態＞
第１実施形態では、Ｓｏｕｒｃｅ１０１がＳｉｎｋ１０２へ動画データを送信しているときに、周辺デバイス１０３への追加の接続やＰ２Ｐ  Ｇｒｏｕｐへの招待のため、Ｓｉｎｋ１０２が他の無線通信装置を探索する場合について説明した。第２実施形態では、Ｓｉｎｋ１０２がＳｏｕｒｃｅ１０１から動画データを受信しているときに、Ｓｏｕｒｃｅ１０１が他の無線通信装置を探索する場合について説明する。なお、第２実施形態において、無線通信システムの構成および無線通信装置の構成は第１実施形態（図１、図２）で説明したとおりである。
【００４９】
図８は、第２実施形態に係る無線通信システムにおいてＳｏｕｒｃｅ１０１からＳｉｎｋ１０２に動画データのストリーミングを行う場合のシーケンス図である。ステップＳ８０１〜ステップＳ８０２の処理およびステップＳ８１０の処理は、第１実施形態で説明したステップＳ１０１〜ステップＳ１０２の処理およびステップＳ１１０の処理と同様である。
【００５０】
Ｓｏｕｒｃｅ１０１が周辺デバイス群（Ｓｉｎｋ１０２や周辺デバイス１０３）の探索を開始すると（ステップＳ８２０）、チャネルを遷移しながら所定の期間にわたってＰｒｏｂｅ  Ｒｅｑｕｅｓｔを送信し続ける（ステップＳ８２１）。ここでの探索は、例えばユーザ操作に基づいて行われ、Ｓｉｎｋ１０２とは異なるＳｉｎｋ機器への画像送信を追加したい場合などが考えられる。周辺デバイス１０３は、ステップＳ８２０で送信されたＰｒｏｂｅ  Ｒｅｑｕｅｓｔを受信した場合、Ｓｏｕｒｃｅ１０１へＰｒｏｂｅ  Ｒｅｓｐｏｎｓｅで応答する（ステップＳ８２２）。なお、図示では省略しているが、周辺デバイス１０３は、Ｓｏｕｒｃｅ１０１からＰｒｏｂｅ  Ｒｅｑｕｅｓｔを受信する毎にＰｒｏｂｅ  Ｒｅｓｐｏｎｓｅを応答し続ける。
【００５１】
この探索において、Ｓｉｎｋ１０２も周辺デバイス１０３と同様にＳｏｕｒｃｅ１０１からＰｒｏｂｅ  Ｒｅｑｕｅｓｔを受信する。Ｓｉｎｋ１０２は、Ｐｒｏｂｅ  Ｒｅｑｕｅｓｔ受信判定処理により、Ｓｏｕｒｃｅ１０１において探索が開始したことを検出する（ステップＳ８３０）。なお、Ｓｉｎｋ１０２におけるＰｒｏｂｅ  Ｒｅｑｕｅｓｔ受信判定処理の詳細は、図９（ａ）を用いて説明する。Ｓｉｎｋ１０２は、探索の開始を検出すると、Ｓｏｕｒｃｅ１０１から受信する動画データの通信量を抑制するために動画データ抑制開始処理を実行する（ステップＳ８４０）。なお、Ｓｉｎｋ１０２における動画データ抑制開始処理の詳細は、図９（ｂ）を用いて説明する。
【００５２】
また、ステップＳ８４０において、Ｓｉｎｋ１０２は、Ｓｏｕｒｃｅ１０１による探索の終了まで動画データの通信量を抑制するため、Ｓｏｕｒｃｅ１０１に対して動画データの基準フレームの送信を要求するためのリフレッシュ要求の発行を制止する。これは、Ｓｏｕｒｃｅ１０１に対してリフレッシュ要求を行うと、Ｓｏｕｒｃｅ１０１は差分フレームよりもデータ量の大きい基準フレームをＳｉｎｋ１０２へ送信しようとするためである。このリフレッシュ要求の発行の制止により、探索の実行中における動画データの通信量増加を抑制することができる。
【００５３】
Ｓｉｎｋ１０２は、動画データのビットレートおよび／または解像度の変化要求をＳｏｕｒｃｅ１０１に通知するため、ＲＴＳＰプロトコルを用いたＡＶ  Ｆｏｒｍａｔ  Ｃｈａｎｇｅメッセージを送信する（ステップＳ８４１）。Ｓｏｕｒｃｅ１０１は、この要求に応じて、Ｓｉｎｋ１０２に対してステップＳ８１０で送信したよりも低解像度および／または低ビットレートの動画データを送信する（ステップＳ８４２）。なお、ステップＳ８４２において、Ｓｏｕｒｃｅ１０１からＳｉｎｋ１０２に対して送信される動画データの解像度および／またはビットレートは、Ｓｏｕｒｃｅ１０１またはＳｉｎｋ１０２のいずれか一方が決定する。また、探索が実行中であると判定されている間、Ｓｉｎｋ１０２は、基準フレームの送信を禁止する。
【００５４】
その後、Ｓｏｕｒｃｅ１０１が、周辺デバイス群の探索を終了すると、Ｐｒｏｂｅ  Ｒｅｑｕｅｓｔの送信を停止する（ステップＳ８５０）。Ｓｉｎｋ１０２は、所定時間Ｐｒｏｂｅ  Ｒｅｑｕｅｓｔを受信しなかった場合に、Ｐｒｏｂｅ  Ｒｅｑｕｅｓｔ停止判定処理によりＳｏｕｒｃｅ１０１のスキャン停止と判定する。なお、Ｓｉｎｋ１０２におけるＰｒｏｂｅ  Ｒｅｑｕｅｓｔ停止判定処理の詳細は、図１０（ａ）を用いて説明する。
【００５５】
Ｓｉｎｋ１０２は、Ｐｒｏｂｅ  Ｒｅｑｕｅｓｔの停止の検出により、Ｓｏｕｒｃｅ１０１における探索が終了したと判定すると、動画データ抑制終了処理を行う（ステップＳ８７０）。なお、Ｓｉｎｋ１０２における動画データ抑制終了処理の詳細は、図１０（ｂ）を用いて説明する。Ｓｉｎｋ１０２は、動画データのビットレートと解像度を通常解像度および通常ビットレートに戻す（抑制前の状態に戻す）旨をＳｏｕｒｃｅ１０１に通知するため、ＲＴＳＰプロトコルを用いたＡＶ  Ｆｏｒｍａｔ  Ｃｈａｎｇｅメッセージを送信する（ステップＳ８７１）。そして、Ｓｉｎｋ１０２は、Ｓｏｕｒｃｅ１０１に対して、基準フレームの送信を要求する（ステップＳ８７２）。この要求に応じて、Ｓｏｕｒｃｅ１０１は、Ｓｉｎｋ１０２に対して、ステップＳ８１０で送信したのと同等の通常解像度および通常ビットレートの動画データを送信する（ステップＳ８７３）。ステップＳ８７３の処理は、第１実施形態で説明したステップＳ３７２の処理と同様である。
【００５６】
なお、Ｓｉｎｋ１０２は、ステップＳ８７１の処理後にＳｏｕｒｃｅ１０１から基準フレームを受信している場合は、Ｓｏｕｒｃｅ１０１に対して、基準フレームの送信を要求しなくても良い。また、ステップ８７２以降、定期的に、または画像の乱れを検出した場合など任意のタイミングで基準フレーム送信要求を送信するようにしてもよい。また、Ｓｉｎｋ１０２は、動画データ抑制開始処理中にＳｏｕｒｃｅ１０１から動画データを正しく受信できなかった場合に、動画データ抑制開始処理の終了後に基準フレームの送信要求を送信するようにしても良い。
【００５７】
図９（ａ）は、第２実施形態に係る無線通信システムにおいて、Ｓｉｎｋ１０２が行うＰｒｏｂｅ  Ｒｅｑｕｅｓｔ受信判定処理を説明するためのフローチャートである。Ｐｒｏｂｅ  Ｒｅｑｕｅｓｔ受信判定処理は主として探索信号送受信部１２１が行う。
【００５８】
Ｓｉｎｋ１０２は、受信したＰｒｏｂｅ  Ｒｅｑｕｅｓｔの送信元が動画データの送信元（Ｓｏｕｒｃｅ１０１）と同じか否かを判定する（ステップＳ９０１）。この判定は、例えば、ステップＳ４０１と同様に、識別情報を用いて行われる。Ｓｉｎｋ１０２は、受信したＰｒｏｂｅ  Ｒｅｑｕｅｓｔの送信元が動画データの送信元と同じと判定した場合（ステップＳ９０１でＹＥＳ）、動画データ抑制開始処理を開始する（ステップＳ９０２）。なお、Ｓｉｎｋ１０２における動画データ抑制開始処理については、図９（ｂ）を用いて詳述する。一方、Ｓｉｎｋ１０２は、受信したＰｒｏｂｅ  Ｒｅｑｕｅｓｔの送信元が動画データの送信元と異なると判定した場合（ステップＳ９０１でＮＯ）、Ｐｒｏｂｅ  Ｒｅｑｕｅｓｔ受信判定処理（ステップＳ９０１の処理）を継続する。
【００５９】
図９（ｂ）は、第２実施形態に係る無線通信システムにおいて、Ｓｉｎｋ１０２が行う動画データ抑制処理を開始するための処理を説明するフローチャートである。動画データ抑制開始処理は、主としてコーデック制御部１４０と画像通信制御部１５０により実行される。
【００６０】
Ｓｉｎｋ１０２は、動画データの通信量を抑制するため、Ｓｏｕｒｃｅ１０１に対してＡＶ  Ｆｏｒｍａｔ  Ｃｈａｎｇｅメッセージにより送信中の動画データの解像度／ビットレートの抑制を要求する（ステップＳ１００１）。この要求を受け付けたＳｏｕｒｃｅ１０１は、図５に示すステップＳ５０１〜Ｓ５０４を実行して、送信中の動画データの解像度および／またはビットレートを抑制する。また、Ｓｉｎｋ１０２は、Ｓｏｕｒｃｅ１０１に対する動画データの基準フレームの送信要求（リフレッシュ要求）の発行を制止する（ステップＳ１００２）。その後、本処理を終了する。なお、Ｓｉｎｋ１０２は、基準フレームの送信要求を制止すると説明したが、基準フレーム送信要求の送信回数を減らす、または、送信周期を広げるなどの制御を行っても良い。
【００６１】
図１０（ａ）は、第２実施形態に係る無線通信システムにおいて、Ｓｉｎｋ１０２が行うＰｒｏｂｅ  Ｒｅｑｕｅｓｔ停止判定処理を説明するためのフローチャートである。Ｐｒｏｂｅ  Ｒｅｑｕｅｓｔ停止判定処理は主として探索信号送受信部１２１が行う。
【００６２】
Ｓｉｎｋ１０２は、動画データの送信元デバイスから所定時間Ｐｒｏｂｅ  Ｒｅｑｕｅｓｔを受信していないか判定する（ステップＳ１１０１）。Ｓｉｎｋ１０２は、動画データの送信元デバイスから所定時間にわたってＰｒｏｂｅ  Ｒｅｑｕｅｓｔを受信していない場合（ステップＳ１１０１でＹＥＳ）、動画データ抑制の終了処理を開始する（ステップＳ１１０２）。なお、動画データ抑制の終了処理については、図１０（ｂ）を用いて詳述する。一方、Ｓｉｎｋ１０２は、前回のＰｒｏｂｅ  Ｒｅｑｕｅｓｔの受信から所定時間内に次のＰｒｏｂｅ  Ｒｅｑｕｅｓｔを受信した場合（ステップＳ１１０１でＮＯ）、Ｐｒｏｂｅ  Ｒｅｑｕｅｓｔ停止判定処理（ステップＳ１１０１の処理）を継続する。
【００６３】
図１０（ｂ）は、第２実施形態に係る無線通信システムにおいて、Ｓｉｎｋ１０２が行う動画データ抑制終了処理を説明するためのフローチャートである。動画データ抑制終了処理は、主としてコーデック制御部１４０と画像通信制御部１５０により実行される。
【００６４】
Ｓｉｎｋ１０２は、Ｓｏｕｒｃｅ１０１に対して、ＡＶ  Ｆｏｒｍａｔ  Ｃｈａｎｇｅメッセージにより送信中の動画データの解像度およびビットレートを通常解像度および通常ビットレートへ戻すよう要求する（ステップＳ１２０１）。この要求を受け付けたＳｏｕｒｃｅ１０１は、図７に示すステップＳ７０１〜Ｓ７０４を実行して、送信中の動画データの解像度およびビットレートを通常解像度および通常ビットレートに戻す。また、Ｓｉｎｋ１０２は、基準フレームの送信要求の発行の制止を解除し、Ｓｏｕｒｃｅ１０１に対して基準フレームの送信要求を送信する（Ｓ１２０２）。その後、本制御フローを終了する。また、Ｓｉｎｋ１０２は、基準フレームの送信要求後、定期的に、または画像の乱れを検出した場合など任意のタイミングで、基準フレーム送信要求を送信するようにしてもよい。
【００６５】
上述のように、第２実施形態では、Ｓｉｎｋ１０２がＳｏｕｒｃｅ１０１から動画データを受信しているときに、Ｓｏｕｒｃｅ１０１はチャネルを切り替えながらＰｒｏｂｅ  Ｒｅｑｕｅｓｔを発行し、周辺デバイス１０３を探索する。このとき、Ｓｉｎｋ１０２もＳｏｕｒｃｅ１０１によって発行されたＰｒｏｂｅ  Ｒｅｑｕｅｓｔを受信するため、Ｓｉｎｋ１０２は、Ｓｏｕｒｃｅ１０１における周辺デバイス１０３の探索状況を判定することができる。Ｓｉｎｋ１０２は、Ｓｏｕｒｃｅ１０１が探索を実施していると判定される間はＳｏｕｒｃｅ１０１へ動画データのビットレートおよび／または解像度を減少する様に指示を行う。これにより、Ｓｏｕｒｃｅ１０１における探索の実行による画像の乱れを抑制することができる。また、Ｓｏｕｒｃｅ１０１における探索の終了後における画像の乱れからの復帰を早めることができる。
【００６６】
＜第３実施形態＞
第１、第２実施形態では、Ｓｏｕｒｃｅ１０１とＳｉｎｋ１０２が動画データのストリーミングを行っているときに、探索を行うデバイスと動画データの抑制処理（動画データの抑制開始処理と動画データの抑制終了処理）を行うデバイスが異なる場合について第１〜第２実施形態で説明した。すなわち、第１実施形態は、動画データのストリーミング中にＳｉｎｋ１０２が他の無線通信装置の探索を実行し、Ｓｏｕｒｃｅ１０１が動画データ抑制処理を行う場合である。また、第２実施形態は、動画データのストリーミング中にＳｏｕｒｃｅ１０１が他の無線通信装置の探索を実行し、Ｓｉｎｋ１０２が動画データ抑制処理を行う場合である。第３実施形態では、Ｓｉｎｋ１０２がＳｏｕｒｃｅ１０１から動画データのストリーミングを受信しているときに、他の無線通信装置を探索し、さらに、動画データ抑制処理を行う。なお、第３実施形態における無線通信システムの構成および無線通信装置の構成は第１実施形態（図１、図２）と同様である。
【００６７】
図１１は、第３実施形態に係る無線通信システムにおいてＳｏｕｒｃｅ１０１からＳｉｎｋ１０２に動画データのストリーミングを行う場合のシーケンス図である。ステップＳ１３０１〜ステップＳ１３１０の処理は、第１実施形態（図３）で説明したステップＳ３０１〜ステップＳ３１０と同様である。
【００６８】
Ｓｉｎｋ１０２が周辺デバイス群（周辺デバイス１０３およびＳｏｕｒｃｅ１０１）の探索を開始すると（ステップＳ１３２０）、チャネルを遷移しながら所定期間にわたってＰｒｏｂｅ  Ｒｅｑｕｅｓｔを送信し続ける（ステップＳ１３２１）。周辺デバイス１０３は、ステップＳ１３２１で送信されたＰｒｏｂｅ  Ｒｅｑｕｅｓｔを受信した場合、Ｓｉｎｋ１０２へＰｒｏｂｅ  Ｒｅｓｐｏｎｓｅで応答する（ステップＳ１３２２）。なお、図では省略しているが、周辺デバイス１０３は、Ｓｉｎｋ１０２からＰｒｏｂｅ  Ｒｅｑｕｅｓｔを受信する毎にＰｒｏｂｅ  Ｒｅｓｐｏｎｓｅを応答し続ける。
【００６９】
Ｓｉｎｋ１０２は、探索の実行中における動画データの通信量を抑制するため、動画データ抑制開始処理を行うとともに、動画データの基準フレームの送信を要求するためのリフレッシュ要求の発行を制止する（ステップＳ１３３０）。なお、動画データ抑制開始処理は、第２実施形態で説明した動画データ抑制開始処理（図９（ｂ））と同様である。Ｓｉｎｋ１０２は、動画データのビットレートや解像度を変化させる旨をＳｏｕｒｃｅ１０１に通知するため、ＲＴＳＰプロトコルを用いたＡＶ  Ｆｏｒｍａｔ  Ｃｈａｎｇｅメッセージを送信する（ステップＳ１３３１）。このメッセージを受信したＳｏｕｒｃｅ１０１は、Ｓｉｎｋ１０２に対して、ステップＳ１３１０で送信したよりも低解像度および／または低ビットレートの動画データを送信する（ステップＳ１３３２）。また、探索が実行中であると判定されている間、Ｓｉｎｋ１０２は、基準フレームの送信を禁止する。
【００７０】
Ｓｉｎｋ１０２は、周辺デバイス群の探索を終了するとＰｒｏｂｅ  Ｒｅｑｕｅｓｔの送信を停止し（ステップＳ１３４０）、動画データ抑制終了処理を行う（ステップＳ１３５０）。なお、動画データ抑制終了処理は、第２実施形態で説明した動画データ抑制終了処理（図１０（ｂ））と同様である。すなわち、Ｓｉｎｋ１０２は、動画データのビットレートや解像度を変化させる（抑制前の状態に戻す）旨をＳｏｕｒｃｅ１０１に通知するため、ＲＴＳＰプロトコルを用いたＡＶ  Ｆｏｒｍａｔ  Ｃｈａｎｇｅメッセージを送信する（ステップＳ１３５１）。そして、Ｓｉｎｋ１０２は、Ｓｏｕｒｃｅ１０１に対して、基準フレームの送信を要求する（ステップＳ１３５２）。その後、Ｓｏｕｒｃｅ１０１は、Ｓｉｎｋ１０２に対して、ステップＳ１３１０で送信したのと同等の通常解像度および通常ビットレートの動画データを送信する（ステップＳ１３５３）。ステップＳ１３５３の処理は、第１実施形態で説明したステップＳ３７２の処理と同様である。
【００７１】
なお、Ｓｉｎｋ１０２は、Ｓｏｕｒｃｅ１０１から動画データを受信していて、かつ、他の無線通信装置の探索処理を行っている間は、動画データの送信元のＳｏｕｒｃｅ１０１に対して基準フレームの送信要求を送信しない。また、Ｓｉｎｋ１０２は、動画データ抑制開始処理中にＳｏｕｒｃｅ１０１から動画データを正しく受信できなかった場合に、動画データ抑制終了処理後に基準フレームの送信要求を送信するようにしても良い。
【００７２】
以上のように、第３実施形態では、Ｓｉｎｋ１０２がＳｏｕｒｃｅ１０１から動画データを受信しているときに、Ｓｉｎｋ１０２はチャネルを切り替えながらＰｒｏｂｅ  Ｒｅｑｕｅｓｔを発行し、周辺デバイス１０３をスキャンする。さらにＳｉｎｋ１０２は、Ｓｏｕｒｃｅ１０１へ動画データのビットレートや解像度を減少する様に指示を行うことによってスキャンの実施による画像の乱れを抑制し、スキャンの終了後における画像の乱れからの復帰を早めることができる。
【００７３】
＜第４実施形態＞
第３実施形態では、Ｓｉｎｋ１０２がＳｏｕｒｃｅ１０１から動画データを受信しているときに他の無線通信装置を探索し、さらに、動画データ抑制処理を行う場合について説明した。第４実施形態では、Ｓｏｕｒｃｅ１０１がＳｉｎｋ１０２に動画データを送信しているときに、Ｓｏｕｒｃｅ１０１が他の無線通信装置を探索し、さらに、動画データ抑制処理を行う場合について説明する。なお、第４実施形態における無線通信システムの構成および無線通信装置は、第１実施形態（図１、図２）と同様である。
【００７４】
図１２は、第４実施形態に係る無線通信システムにおいてＳｏｕｒｃｅ１０１からＳｉｎｋ１０２に動画データのストリーミングを行う場合のシーケンス図である。ステップＳ１４０１〜ステップＳ１４１０の処理は、第１実施形態（図３）で説明したステップＳ３０１〜ステップＳ３１０の処理と同様である。
【００７５】
Ｓｏｕｒｃｅ１０１は、周辺デバイス群（Ｓｉｎｋ１０２や周辺デバイス１０３）の探索を開始すると（ステップＳ１４２０）、所定の期間にわたってチャネルを遷移しながらＰｒｏｂｅ  Ｒｅｑｕｅｓｔを送信し続ける（ステップＳ１４２１）。周辺デバイス１０３は、ステップＳ１４２０で送信されたＰｒｏｂｅ  Ｒｅｑｕｅｓｔを受信した場合、Ｓｏｕｒｃｅ１０１へＰｒｏｂｅ  Ｒｅｓｐｏｎｓｅで応答する（ステップＳ１４２２）。なお、図１２では省略しているが、周辺デバイス１０３は、Ｓｏｕｒｃｅ１０１からＰｒｏｂｅ  Ｒｅｑｕｅｓｔを受信する毎にＰｒｏｂｅ  Ｒｅｓｐｏｎｓｅを応答し続ける。
【００７６】
Ｓｏｕｒｃｅ１０１は、周辺デバイス群の探索を開始すると、動画データのビットレートおよび／または解像度を下げることで動画データの通信量を抑制する（ステップＳ１４３０）。なお、動画データ抑制開始処理は、第１実施形態で説明した動画データ抑制開始処理（図５）と同様である。Ｓｏｕｒｃｅ１０１は、動画データ抑制処理により動画データのビットレートおよび／または解像度が変化したことをＳｉｎｋ１０２に通知する（ステップＳ１４３１）。このとき、Ｓｏｕｒｃｅ１０１は、ＲＴＳＰプロトコルを用いたＡＶ  Ｆｏｒｍａｔ  Ｃｈａｎｇｅメッセージを送信する。続いて、Ｓｏｕｒｃｅ１０１は、Ｓｉｎｋ１０２に対して、ステップＳ１４１０で送信した動画データよりも低解像度および／または低ビットレートの動画データを送信する（ステップＳ１４３２）。この、抑制された動画データの送信中、すなわち探索の実行中において、Ｓｏｕｒｃｅ１０１は、Ｓｉｎｋ１０２からの基準フレームの要求を受け付けない。
【００７７】
その後、周辺デバイス群の探索が終了すると、Ｓｏｕｒｃｅ１０１はＰｒｏｂｅ  Ｒｅｑｕｅｓｔの送信を停止する（ステップＳ１４４０）。そして、Ｓｏｕｒｃｅ１０１は動画データ抑制終了処理を行う（ステップＳ１４５０）。なお、動画データ抑制終了処理は、第１実施形態で説明した動画データ抑制終了処理（図７）と同様である。動画データ抑制終了処理において、Ｓｏｕｒｃｅ１０１は、動画データのビットレートおよび解像度を動画データ抑制開始処理前の（ステップＳ１４１０と同等の）ビットレートおよび解像度に戻す。その後、Ｓｏｕｒｃｅ１０１は、動画データのビットレートや解像度が変化したこと（抑制前の状態に戻ったこと）をＳｉｎｋ１０２に通知するため、ＲＴＳＰプロトコルを用いたＡＶ  Ｆｏｒｍａｔ  Ｃｈａｎｇｅメッセージを送信する（ステップＳ１４５１）。そして、Ｓｏｕｒｃｅ１０１は、Ｓｉｎｋ１０２に対して、ステップＳ１４１０で送信したのと同等の通常解像度および通常ビットレートの動画データを送信する（ステップＳ１３５３）。なお、ステップＳ１３５３の処理は、第１実施形態で説明したステップＳ３７２の処理と同様である。また、探索の終了後は、Ｓｉｎｋ１０２からの基準フレームの要求を受け付ける。また、探索の終了に応じて基準フレームを送信するようにしてもよい。
【００７８】
以上のように、第４実施形態では、Ｓｏｕｒｃｅ１０１がＳｉｎｋ１０２に対し動画データを送信しているときに、Ｓｏｕｒｃｅ１０１はチャネルを切り替えながらＰｒｏｂｅ  Ｒｅｑｕｅｓｔを発行し、周辺デバイス１０３をスキャンする。さらにＳｏｕｒｃｅ１０１は、スキャンの実施による画像の乱れを抑制する。また、スキャンの終了後における画像の乱れからの復帰を早めることができる。
【００７９】
なお、上記第１〜第４実施形態では、探索中における動画データの通信量を抑制するために、動画データの解像度および／またはビットレートを下げている。しかしながら、動画データの通信量を抑制するための処理はこれに限られるものではない。例えば、動画データのフレームレートを下げることにより動画データの通信量が抑制されてもよい。したがって、動画データの通信量の抑制は、解像度、ビットレート、フレームレートの少なくとも１つを下げることにより実現され得る。
【００８０】
（その他の実施形態）
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
【符号の説明】
【００８１】
１００：無線通信装置、１０１：Ｓｏｕｒｃｅ、１０２：Ｓｉｎｋ、１０３：周辺デバイス、１０４：無線ネットワーク、１１０：ＯＳ、１２０：無線通信制御部、１２１：探索信号送受信部、１３０：情報管理部、１４０：コーデック制御部、１５０：画像通信制御部、１６０：表示制御部
【図１】
2019033444.tif 000003
【図２】
2019033444.tif 000004
【図３】
2019033444.tif 000005
【図４】
2019033444.tif 000006
【図５】
2019033444.tif 000007
【図６】
2019033444.tif 000008
【図７】
2019033444.tif 000009
【図８】
2019033444.tif 000010
【図９】
2019033444.tif 000011
【図１０】
2019033444.tif 000012
【図１１】
2019033444.tif 000013
【図１２】
2019033444.tif 000014