JP6445549B2 - 直接通信システムにおけるデバイス探索方法及びそのための装置 - Google Patents

Description

以下の説明は、無線通信システムに関し、特に、直接通信システムにおいてデバイスを探索する方法及び装置に関する。

近年、情報通信技術の発展に伴って様々な無線通信技術が開発されている。その中でも無線ＬＡＮ（ＷＬＡＮ）は、無線周波数技術に基づいて個人携帯用情報端末機（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ；ＰＤＡ）、ラップトップコンピュータ、携帯用マルチメディアプレーヤー（Ｐｏｒｔａｂｌｅ Ｍｕｌｔｉｍｅｄｉａ Ｐｌａｙｅｒ；ＰＭＰ）などのような携帯用端末機を用いて家庭、企業又は特定サービス提供地域において無線でインターネットにアクセスできるようにする技術である。

既存の無線ＬＡＮシステムにおいて基本的に要求される無線アクセスポイント（ＡＰ）なしに、デバイス（ｄｅｖｉｃｅ）が互いに容易に接続できるようにする直接通信技術として、Ｗｉ−Ｆｉダイレクト（Ｗｉ−Ｆｉ Ｄｉｒｅｃｔ）またはＷｉ−Ｆｉ Ｐ２Ｐ（ｐｅｅｒ−ｔｏ−ｐｅｅｒ）の導入が議論されている。Ｗｉ−Ｆｉダイレクトによれば、複雑な設定過程を経ることなくデバイスが互いに接続可能であり、ユーザに様々なサービスを提供するために、一般的な無線ＬＡＮシステムの通信速度で互いにデータをやり取りする動作をサポートすることができる。

近年、様々なＷｉ−Ｆｉサポートデバイスが用いられており、特に、ＡＰ無しでＷｉ−Ｆｉデバイス間の通信が可能なＷｉ−Ｆｉダイレクトサポートデバイスの個数が増加している。ＷＦＡ（Ｗｉ−Ｆｉ Ａｌｌｉａｎｃｅ）ではＷｉ−Ｆｉダイレクトリンクを用いた様々なサービス（例えば、送信（Ｓｅｎｄ）、プレイ（Ｐｌａｙ）、ディスプレイ（Ｄｉｓｐｌａｙ）、プリント（Ｐｒｉｎｔ）など）をサポートするプラットホームを導入する技術が議論されている。これをＷｉ−Ｆｉダイレクトサービス（ＷＦＤＳ）と呼ぶことができる。

ＷＦＤＳのうち、ディスプレイサービスによれば、Ｗｉ−Ｆｉディスプレイ（ＷＦＤ、Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙ）ソース（Ｓｏｕｒｃｅ）及びＷｉ−Ｆｉディスプレイシンク（Ｓｉｎｋ）は、プローブ要求及び応答フレームに含まれたＷＦＤ情報要素（ＩＥ、Ｉｎｆｏｒｍａｔｉｏｎ Ｅｌｅｍｅｎｔ）を用いてお互いを探索することができる。

本発明は、ＷＦＤサービスにおいてデバイスを探索する方法を提供することを目的とする。具体的には、本発明では、ＷＦＤソースがＷＦＤシンクから受信する情報に基づいて、ＷＦＤシンクの接続しているＡＰ（Ａｃｃｅｓｓ Ｐｏｉｎｔ）を確認する方法を提供することを目的とする。

本発明で達成しようとする技術的課題は、以上に言及した技術的課題に制限されず、言及していない他の技術的課題は、以下の記載から、本発明の属する技術の分野における通常の知識を有する者に明確に理解されるであろう。

上記の技術的課題を解決するために、本発明の一実施例に係る、第１の無線デバイスのデバイス探索方法は、プローブ要求フレームを送信するステップと、前記プローブ要求フレームに対する応答として、第２の無線デバイスからプローブ応答フレームを受信するステップとを有することができる。このとき、前記プローブ応答フレームは、前記第２の無線デバイスが現在接続しているＡＰ（Ａｃｃｅｓｓ Ｐｏｉｎｔ）の情報を含むことができる。

上記の技術的課題を解決するために、本発明の一実施例に係る、第１の無線デバイスのデバイス探索時の応答方法は、第２の無線デバイスからプローブ要求フレームを受信するステップと、前記プローブ要求フレームに対する応答として、第２の無線デバイスにプローブ応答フレームを送信するステップとを有することができる。ここで、前記プローブ応答フレームは、前記第１の無線デバイスが現在接続しているＡＰ（Ａｃｃｅｓｓ Ｐｏｉｎｔ）の情報を含むことができる。

上記の技術的課題を解決するための本発明の一実施例に係る、デバイス探索を行う第１の無線デバイスは、送受信器と、プロセッサとを備えることができる。ここで、前記プロセッサは、プローブ要求フレームを送信するように前記送受信器を制御し、前記送受信器が第２の無線デバイスから前記プローブ要求フレームに対する応答としてプローブ応答フレームを受信すると、前記プローブ応答フレームから、前記第２の無線デバイスが現在接続しているＡＰ（Ａｃｃｅｓｓ Ｐｏｉｎｔ）の情報をデコーティングすることができる。

前記の技術的課題を解決するための本発明の一実施例に係る、デバイス探索に応答するための第１の無線デバイスは、送受信器と、プロセッサとを備えることができる。ここで、前記プロセッサは、前記送受信器が第２の無線デバイスからプローブ要求フレームを受信すると、前記第１の無線デバイスが現在接続しているＡＰ（ＡｃｃｅｓｓＰｏｉｎｔ）の情報を含むプローブ応答フレームが前記第２の無線デバイスに送信されるように制御することができる。

本発明について前述した一般的な説明と後述する詳細な説明は例示的なものであり、請求項に記載の発明に関する更なる説明のためのものである。

本発明によれば、ＷＦＤサービスにおいてデバイスを探索する方法及びそのための装置を提供することができる。具体的には、本発明では、ＷＦＤソースがＷＦＤシンクから受信する情報に基づいて、ＷＦＤシンクの接続しているＡＰを確認する方法及び装置を提供することができる。

本発明から得られる効果は、以上に言及した効果に制限されず、言及していない他の効果は、以下の記載から、本発明の属する技術の分野における通常の知識を有する者にとって明らかになるであろう。

本明細書に添付される図面は、本発明に関する理解を提供するためのものであり、本発明の様々な実施の形態を示し、明細書の記載と共に本発明の原理を説明する。
本発明を適用可能なＩＥＥＥ ８０２．１１システムの例示的な構造を示す図である。 Ｗｉ−Ｆｉダイレクトネットワークを例示する図である。 ＷＦＤネットワークを構成する過程を説明するための図である。 近隣発見過程を説明するための図である。 ＷＦＤネットワークの新しい様子を説明するための図である。 ＷＦＤ通信のためのリンクを設定する方法を説明するための図である。 ＷＦＤ通信をしている通信グループに参加（ａｓｓｏｃｉａｔｉｏｎ）する方法を説明するための図である。 ＷＦＤ通信のためのリンクを設定する方法を説明するための図である。 ＷＦＤ通信グループに参加するリンクを設定する方法を説明するための図である。 ＷＦＤＳフレームワーク構成要素を説明するための図である。 ＷＦＤソースとＷＦＤシンクとの間にＷＦＤセッションが構築される過程を説明するためのフローチャートである。 図１１に示した過程によって、ＷＦＤソースとＷＦＤシンクとの間にＷＦＤセッションが構築される場合のトポロジを図式化した図である。 ＷＦＤソースとＷＦＤシンクとの間に既にダイレクトリンクが存在する場合に、ＷＦＤセッションが構築されるトポロジを図式化した図である。 ＷＦＤソースがＡＰと接続されており、ＷＦＤシンクはＡＰと接続されていない時に、ＷＦＤセッションが構築されるトポロジを図式化した図である。 ＷＦＤソースがＡＰと接続されており、ＷＦＤソースとＷＦＤシンクとの間に既にダイレクトリンクが存在する場合に、ＷＦＤセッションが構築されるトポロジを図式化した図である。 ＷＦＤソース及びＷＦＤシンクが同一ＡＰと接続されている場合に、ＷＦＤセッションが構築されるトポロジを図式化した図である。 ＷＦＤソース及びＷＦＤシンクが同一ＡＰと接続されている場合に、ＷＦＤセッションが構築されるトポロジを図式化した図である。 ＷＦＤソース及びＷＦＤシンクが同一ＡＰと接続されている場合に、ＷＦＤセッションが構築されるトポロジを図式化した図である。 ＷＦＤソース及びＷＦＤシンクが同一ＡＰと接続されている場合に、ＷＦＤセッションが構築されるトポロジを図式化した図である。 ＷＦＤシンクがＡＰに接続されている場合に、ＷＦＤセッションが構築されるトポロジを図式化した図である。 ＷＦＤシンクがＡＰに接続されている場合に、ＷＦＤセッションが構築されるトポロジを図式化した図である。 ＷＦＤソース及びＷＦＤシンクが異なったＡＰに接続されている時に、ＷＦＤセッションが構築されるトポロジを図式化した図である。 ＷＦＤソース及びＷＦＤシンクが異なったＡＰに接続されている時、ＷＦＤセッションが構築されるトポロジを図式化した図である。 プローブ要求フレーム及びプローブ応答フレームのフォーマットを簡略に示す図である。 ＷＦＤシンクがＡＰに関連付けられているとき、ＷＦＤシンクが、関連付けられたＡＰに関する情報を、ＷＦＤソースに知らせる例を示す図である。 ＷＦＤソースがマルチタスクを実行しているとき、タスク別エンコーディングデータが異なったＷＦＤシンクにストリーミングされる例を示す図である。 ＷＦＤソースがマルチタスクを実行しているとき、タスク別エンコードされた複数のデータが単一のＷＦＤシンクにストリーミングされる例を示す図である。 ＷＦＤソースがフォアグラウンド状態であるタスクとバックグラウンド状態であるタスクを異なったＷＦＤシンクにストリーミングする例を示す図である。 ＷＦＤソースが複数のウィンドウをディスプレイしているとき、ウィンドウ別エンコーディングデータが異なったＷＦＤシンクにストリーミングされる例を示す図である。 タスクの属性に応じてデータがストリーミングされる例を示す図である。 ＷＦＤソースに保存された写真のスライドショーをエンコーディングしたデータがＷＦＤシンクにストリーミングされる例を説明するための図である。 ＷＦＤソースがマルチディスプレイ環境で動作しているとき、ディスプレイ別エンコーディングデータが異なったＷＦＤシンクにストリーミングされる例を示す図である。 ＷＦＤシンクが自身の実行しているタスクと共に、受信したデータを出力する例を示す図である。 ＷＦＤソースがＷＦＤシンクのディスプレイ別に異なるデータがストリーミングされるように制御する例を示す図である。 ＷＦＤソースがＷＦＤシンクのディスプレイ別に異なるデータがストリーミングされるように制御する例を示す図である。 本発明の一実施例に係る無線デバイスの構成を示すブロック図である。

以下、本発明の好適な実施形態を、添付の図面を参照して詳細に説明する。添付の図面と共に以下に開示される詳細な説明は、本発明の例示的な実施形態を説明するためのもので、本発明を実施できる唯一の実施形態を示すものではない。以下の詳細な説明は、本発明の完全な理解を提供するために具体的な細部の事項を含む。しかし、当業者には、本発明がそれらの具体的な細部の事項なしにも実施可能であるということが理解される。

以下の実施例は、本発明の構成要素及び特徴を所定の形態で結合したものである。各構成要素又は特徴は、特別の言及がない限り、選択的なものとして考慮することができる。各構成要素又は特徴は、他の構成要素や特徴と結合されない形態で実施可能である。また、一部の構成要素及び／又は特徴を結合して本発明の実施例を構成してもよい。本発明の実施例で説明される動作の順序は変更可能である。ある実施例の一部の構成や特徴は、別の実施例に含まれてもよく、別の実施例の対応する構成又は特徴に取り替えられてもよい。

以下の説明で使用される特定の用語は、本発明の理解を助けるために提供されたもので、これらの特定の用語の使用は、本発明の技術的思想から逸脱しない範囲で他の形態に変更可能である。

場合によっては、本発明の概念が曖昧になることを避けるために、公知の構造及び装置を省略したり、各構造及び装置の中核的な機能を中心にしたブロック図の形式で図示したりすることができる。また、本明細書全体にわたって同一の構成要素には同一の図面符号を付して説明する。

本発明の実施例は、無線アクセスシステムであるＩＥＥＥ ８０２システム、３ＧＰＰシステム、３ＧＰＰ ＬＴＥ及びＬＴＥ−Ａ（ＬＴＥ−Ａｄｖａｎｃｅｄ）システム、３ＧＰＰ２システム並びにＷｉ−Ｆｉ Ａｌｌｉａｎｃｅ（ＷＦＡ）システムのうち少なくとも１つに開示された標準文書によって裏付けることができる。すなわち、本発明の実施例において、本発明の技術的思想を明確にするために説明を省いた段階又は部分は、上記の文書によって裏付けることができる。また、本文書で開示している用語はいずれも上記の標準文書によって説明することができる。

以下の技術は、ＣＤＭＡ（Ｃｏｄｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）、ＦＤＭＡ（Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）、ＴＤＭＡ（Ｔｉｍｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）、ＯＦＤＭＡ（Ｏｒｔｈｏｇｏｎａｌ Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）、ＳＣ−ＦＤＭＡ（Ｓｉｎｇｌｅ Ｃａｒｒｉｅｒ Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）などのような様々な無線アクセスシステムに用いることができる。ＣＤＭＡは、ＵＴＲＡ（Ｕｎｉｖｅｒｓａｌ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ）やＣＤＭＡ２０００のような無線技術（ｒａｄｉｏ ｔｅｃｈｎｏｌｏｇｙ）によって実現することができる。ＴＤＭＡは、ＧＳＭ（Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）／ＧＰＲＳ（Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｅｒｖｉｃｅ）／ＥＤＧＥ（Ｅｎｈａｎｃｅｄ Ｄａｔａ Ｒａｔｅｓ ｆｏｒ ＧＳＭ Ｅｖｏｌｕｔｉｏｎ）のような無線技術によって実現することができる。ＯＦＤＭＡは、ＩＥＥＥ ８０２．１１（Ｗｉ−Ｆｉ）、ＩＥＥＥ ８０２．１６（ＷｉＭＡＸ）、ＩＥＥＥ８０２−２０、Ｅ−ＵＴＲＡ（Ｅｖｏｌｖｅｄ ＵＴＲＡ）などのような無線技術によって実現することができる。明確性のために、以下ではＩＥＥＥ ８０２．１１システムを中心に説明するが、本発明の技術的思想がこれに制限されるものではない。

ＷＬＡＮシステムの構造
図１は、本発明を適用できるＩＥＥＥ８０２．１１システムの例示的な構造を示す図である。

ＩＥＥＥ８０２．１１構造は複数個の構成要素を含むことができ、これらの相互作用によって上位層に対してトランスペアレントな移動性をサポートするＷＬＡＮを提供することができる。基本サービスセット（Ｂａｓｉｃ Ｓｅｒｖｉｃｅ Ｓｅｔ；ＢＳＳ）はＩＥＥＥ ８０２．１１ ＬＡＮにおける基本的な構成ブロックに該当し得る。図１では、２個のＢＳＳ（ＢＳＳ１及びＢＳＳ２）が存在し、それぞれのＢＳＳのメンバーとして２個のＳＴＡが含まれること（ＳＴＡ１及びＳＴＡ２はＢＳＳ１に含まれ、ＳＴＡ３及びＳＴＡ４はＢＳＳ２に含まれる）を例示的に示している。図１において、ＢＳＳを示す楕円は、当該ＢＳＳに含まれたＳＴＡが通信を維持するカバレッジ領域を示すものと理解してもよい。この領域をＢＳＡ（Ｂａｓｉｃ Ｓｅｒｖｉｃｅ Ａｒｅａ）と呼ぶことができる。ＳＴＡがＢＳＡの外へ移動すると、当該ＢＳＡ内の他のＳＴＡと直接通信できなくなる。

ＩＥＥＥ ８０２．１１ ＬＡＮにおいて最も基本的なタイプのＢＳＳは、独立したＢＳＳ（ＩｎｄｅｐｅｎｄｅｎｔＢＳＳ；ＩＢＳＳ）である。例えば、ＩＢＳＳは、２個のＳＴＡだけで構成された最小の形態を有することができる。また、最も単純な形態であるとともに他の構成要素が省略されている図１のＢＳＳ（ＢＳＳ１又はＢＳＳ２）がＩＢＳＳの代表的な例示に該当し得る。このような構成は、ＳＴＡ同士が直接通信できる場合に可能である。また、このような形態のＬＡＮは、予め計画して構成されるものではなく、ＬＡＮが必要な場合に構成され、これをアドホック（ａｄ−ｈｏｃ）ネットワークと呼ぶこともできる。

ＳＴＡの電源オン／オフ、ＳＴＡのＢＳＳ領域への出入りなどによって、ＢＳＳでのＳＴＡのメンバーシップが動的に変更され得る。ＢＳＳのメンバーになるためには、ＳＴＡは同期化過程を用いてＢＳＳにジョインすることができる。ＢＳＳ基盤構造の全てのサービスにアクセスするためには、ＳＴＡはＢＳＳに関連付けられて（ａｓｓｏｃｉａｔｅｄ）いなければならない。このような関連付け（ａｓｓｏｃｉａｔｉｏｎ）は動的に設定することができ、分配システムサービス（Ｄｉｓｔｒｉｂｕｔｉｏｎ Ｓｙｓｔｅｍ Ｓｅｒｖｉｃｅ；ＤＳＳ）の利用を含むことができる。

層構造
無線ＬＡＮシステムで動作するＳＴＡの動作は、層（ｌａｙｅｒ）構造の観点で説明することができる。装置構成の面で層構造はプロセッサによって実現することができる。ＳＴＡは複数の層の構造を有することができる。例えば、８０２．１１標準文書において扱う層構造は、主にＤＬＬ（Ｄａｔａ Ｌｉｎｋ Ｌａｙｅｒ）のＭＡＣ副層（ｓｕｂｌａｙｅｒ）及び物理（ＰＨＹ）層である。ＰＨＹは、ＰＬＣＰ（Ｐｈｙｓｉｃａｌ Ｌａｙｅｒ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｃｅｄｕｒｅ）エンティティ、ＰＭＤ（Ｐｈｙｓｉｃａｌ Ｍｅｄｉｕｍ Ｄｅｐｅｎｄｅｎｔ）エンティティなどを含むことができる。ＭＡＣ副層及びＰＨＹは、それぞれ、ＭＬＭＥ（ＭＡＣ ｓｕｂｌａｙｅｒ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ）及びＰＬＭＥ（Ｐｈｙｓｉｃａｌ Ｌａｙｅｒ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ）と呼ばれる管理エンティティを概念的に含む。このようなエンティティは、層管理機能が動作する層管理サービスインターフェースを提供する。

正確なＭＡＣ動作を提供するために、ＳＭＥ（Ｓｔａｔｉｏｎ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ）がそれぞれのＳＴＡ内に存在する。ＳＭＥは、別途の管理プレーン内に存在している、または別途に離れて（ｏｆｆ ｔｏ ｔｈｅ ｓｉｄｅ）いるように見られる、層から独立したエンティティである。ＳＭＥの正確な機能は、本文書で具体的に説明していないが、一般的には様々な層管理エンティティ（ＬＭＥ）から層に依存した状態を収集し、層特有のパラメータなどの値をほぼ同一に設定するなどの機能を担当するものと見られる。一般に、ＳＭＥは、一般のシステム管理エンティティを代表して（ｏｎ ｂｅｈａｌｆ ｏｆ）このような機能を行い、標準管理プロトコルを実現することができる。

前述したエンティティは、様々な方式で相互作用する。例えば、エンティティ間ではＧＥＴ／ＳＥＴプリミティブ（ｐｒｉｍｉｔｉｖｅ）を交換（ｅｘｃｈａｎｇｅ）することによって相互作用することができる。プリミティブは、特定の目的に関連した要素（ｅｌｅｍｅｎｔ）やパラメータのセットを意味する。ＸＸ−ＧＥＴ．ｒｅｑｕｅｓｔプリミティブは、与えられたＭＩＢ ａｔｔｒｉｂｕｔｅ（管理情報ベースの属性情報）の値を要求するために使用される。ＸＸ−ＧＥＴ．ｃｏｎｆｉｒｍプリミティブは、Ｓｔａｔｕｓが“成功”である場合には適切なＭＩＢ属性情報値をリターンし、そうでない場合には、Ｓｔａｔｕｓフィールドでエラー指示をリターンするために使用される。ＸＸ−ＳＥＴ．ｒｅｑｕｅｓｔプリミティブは、指示されたＭＩＢ属性が与えられた値に設定されるように要求するために使用される。前記ＭＩＢ属性が特定の動作を意味する場合、これは、該当動作が行われることを要求するものである。そして、ＸＸ−ＳＥＴ．ｃｏｎｆｉｒｍプリミティブは、ｓｔａｔｕｓが“成功”である場合に、指示されたＭＩＢ属性が要求された値に設定されたことを確認し、そうでない場合には、ｓｔａｔｕｓフィールドにエラー条件をリターンするために使用される。ＭＩＢ属性が特定の動作を意味する場合、これは、該当動作が行われたことを確認させる。

また、ＭＬＭＥ及びＳＭＥは、様々なＭＬＭＥ_ＧＥＴ／ＳＥＴプリミティブをＭＬＭＥ_ＳＡＰ（Ｓｅｒｖｉｃｅ Ａｃｃｅｓｓ Ｐｏｉｎｔ）を介して交換することができる。また、様々なＰＬＭＥ_ＧＥＴ／ＳＥＴプリミティブが、ＰＬＭＥ_ＳＡＰを介してＰＬＭＥとＳＭＥとの間で交換されてもよく、ＭＬＭＥ−ＰＬＭＥ_ＳＡＰを介してＭＬＭＥとＰＬＭＥとの間で交換されてもよい。

無線ＬＡＮの進化
無線ＬＡＮ（ＷＬＡＮ）技術に関する標準はＩＥＥＥ（Ｉｎｓｔｉｔｕｔｅ ｏｆ Ｅｌｅｃｔｒｉｃａｌ ａｎｄ Ｅｌｅｃｔｒｏｎｉｃｓ Ｅｎｇｉｎｅｅｒｓ）８０２．１１グループで開発している。ＩＥＥＥ ８０２．１１ａ及びｂは、２．４．ＧＨｚ又は５ＧＨｚで非免許帯域（ｕｎｌｉｃｅｎｓｅｄ ｂａｎｄ）を利用し、ＩＥＥＥ ８０２．１１ｂは１１Ｍｂｐｓの送信速度を提供し、ＩＥＥＥ ８０２．１１ａは５４Ｍｂｐｓの送信速度を提供する。ＩＥＥＥ ８０２．１１ｇは、２．４ＧＨｚで直交周波数分割多重化（Ｏｒｔｈｏｇｏｎａｌ Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅｘｉｎｇ、ＯＦＤＭ）を適用して５４Ｍｂｐｓの送信速度を提供する。ＩＥＥＥ ８０２．１１ｎは、複数入出力ＯＦＤＭ（Ｍｕｌｔｉｐｌｅ Ｉｎｐｕｔ Ｍｕｌｔｉｐｌｅ Ｏｕｔｐｕｔ−ＯＦＤＭ、ＭＩＭＯ−ＯＦＤＭ）を適用して３００Ｍｂｐｓの送信速度を提供する。ＩＥＥＥ ８０２．１１ｎはチャネル帯域幅（ｃｈａｎｎｅｌ ｂａｎｄｗｉｄｔｈ）を４０ＭＨｚまでサポートし、この場合、６００Ｍｂｐｓの送信速度を提供する。

ＩＥＥＥ ８０２．１１ｅに基づく無線ＬＡＮ環境におけるＤＬＳ（Ｄｉｒｅｃｔ Ｌｉｎｋ Ｓｅｔｕｐ）関連プロトコルは、ＢＳＳ（Ｂａｓｉｃ Ｓｅｒｖｉｃｅ Ｓｅｔ）がＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）をサポートするＱＢＳＳ（Ｑｕａｌｉｔｙ ＢＳＳ）であることを前提とする。ＱＢＳＳでは非ＡＰ（Ｎｏｎ−ＡＰ）ＳＴＡだけでなく、ＡＰもＱｏＳをサポートするＱＡＰ（Ｑｕａｌｉｔｙ ＡＰ）である。ところが、現在商用化されている無線ＬＡＮ環境（例えば、ＩＥＥＥ ８０２．１１ａ／ｂ／ｇなどに基づく無線ＬＡＮ環境）では、たとえＮｏｎ−ＡＰ ＳＴＡがＱｏＳをサポートするＱＳＴＡ（Ｑｕａｌｉｔｙ ＳＴＡ）であるとしても、ＡＰはＱｏＳをサポートできないレガシー（Ｌｅｇａｃｙ）ＡＰが殆どである。その結果、現在商用化されている無線ＬＡＮ環境ではＱＳＴＡであっても、ＤＬＳサービスを利用できないという限界がある。

トンネルダイレクトリンク設定（Ｔｕｎｎｅｌｅｄ Ｄｉｒｅｃｔ Ｌｉｎｋ Ｓｅｔｕｐ；ＴＤＬＳ）は、上記のような限界を克服するために新しく提案された無線通信プロトコルである。ＴＤＬＳは、ＱｏＳはサポートしないが、現在商用化されたＩＥＥＥ ８０２．１１ａ／ｂ／ｇなどの無線ＬＡＮ環境でもＱＳＴＡがダイレクトリンクを設定できるようにするとともに、パワーセーブモード（Ｐｏｗｅｒ Ｓａｖｅ Ｍｏｄｅ；ＰＳＭ）でもダイレクトリンクの設定を可能にする。このため、ＴＤＬＳは、レガシーＡＰが管理するＢＳＳにおいてもＱＳＴＡがダイレクトリンク設定可能な諸手順を規定する。以下、このようなＴＤＬＳをサポートする無線ネットワークをＴＤＬＳ無線ネットワークという。

Ｗｉ−Ｆｉダイレクトネットワーク
従来の無線ＬＡＮは、無線アクセスポイント（ＡＰ）がハブとして機能するインフラストラクチャー（ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）ＢＳＳに関する動作を主に扱ってきた。ＡＰは、無線／有線接続のための物理層サポート機能、ネットワーク上のデバイスに対するルーティング機能、及びデバイスをネットワークに追加／ネットワークから除去するためのサービス提供などを担当する。この場合、ネットワーク内のデバイスはＡＰを介して接続されるもので、互いに直接接続されるものではない。

デバイスの間の直接接続をサポートする技術としてＷｉ−Ｆｉダイレクト（Ｗｉ−Ｆｉ Ｄｉｒｅｃｔ）標準の制定が完了した。

図２には、Ｗｉ−Ｆｉダイレクト（Ｗｉ−Ｆｉ Ｄｉｒｅｃｔ）ネットワークを例示する。Ｗｉ−Ｆｉダイレクトネットワークは、Ｗｉ−Ｆｉ装置がホームネットワーク、オフィスネットワーク及びホットスポットネットワークに参加しなくても、互いにデバイス対デバイス（Ｄｅｖｉｃｅ ｔｏ Ｄｅｖｉｃｅ；Ｄ２Ｄ）（或いは、Ｐｅｅｒ−ｔｏ−Ｐｅｅｒ；Ｐ２Ｐ）通信が可能なネットワークであり、Ｗｉ−Ｆｉアライアンス（Ａｌｌｉａｎｃｅ）によって提案された。以下、Ｗｉ−Ｆｉダイレクトベースの通信を、Ｗｉ−ＦｉダイレクトＤ２Ｄ通信（単に、Ｄ２Ｄ通信）或いはＷｉ−ＦｉダイレクトＰ２Ｐ通信（単に、Ｐ２Ｐ通信）と呼ぶ。また、Ｗｉ−ＦｉダイレクトＰ２Ｐ実行デバイスを、Ｗｉ−ＦｉダイレクトＰ２Ｐデバイス、単に、Ｐ２Ｐデバイス又はピア（Ｐｅｅｒ）デバイスと呼ぶ。

Ｗｉ−Ｆｉダイレクトネットワーク２００は、図２に示すように、第１のＰ２Ｐデバイス２０２及び第２のＰ２Ｐデバイス２０４のように、少なくとも一つのＷｉ−Ｆｉデバイスを含むことができる。Ｐ２Ｐデバイスとしては、ディスプレイ装置、プリンタ、デジタルカメラ、プロジェクター及びスマートフォンなどの、Ｗｉ−Ｆｉをサポートするデバイスを含む。また、Ｐ２Ｐデバイスは、Ｎｏｎ−ＡＰ ＳＴＡ及びＡＰ ＳＴＡを含む。図の例示では、第１のＰ２Ｐデバイス２０２は携帯電話であり、第２のＰ２Ｐデバイス２０４はディスプレイ装置である。Ｗｉ−Ｆｉダイレクトネットワーク内のＰ２Ｐデバイスは互いに直接接続することができる。具体的には、Ｐ２Ｐ通信は、２つのＰ２Ｐデバイス間の信号送信経路が、第３のデバイス（例えば、ＡＰ）又は既存ネットワーク（例えば、ＡＰを経てＷＬＡＮに接続）を経由せずに当該Ｐ２Ｐデバイスの間に直接設定された場合を意味することができる。ここで、両Ｐ２Ｐデバイスの間に直接設定された信号送信経路は、データ送信経路に制限されてもよい。例えば、Ｐ２Ｐ通信は、複数のＮｏｎ−ＳＴＡがＡＰの介入無しでデータ（例、音声／画像／文字情報など）を送信する場合を意味することができる。制御情報（例、Ｐ２Ｐ設定のためのリソース割り当て情報、無線デバイス識別情報など）のための信号送信経路は、Ｐ２Ｐデバイス（例えば、Ｎｏｎ−ＡＰ ＳＴＡ対Ｎｏｎ−ＡＰ ＳＴＡ、Ｎｏｎ−ＡＰ ＳＴＡ対ＡＰ）間に直接設定されたり、ＡＰを経由して両Ｐ２Ｐデバイス（例えば、Ｎｏｎ−ＡＰ ＳＴＡ対Ｎｏｎ−ＡＰ ＳＴＡ）間に設定されたり、又はＡＰと当該Ｐ２Ｐデバイス（例えば、ＡＰ対Ｎｏｎ−ＡＰ ＳＴＡ＃１、ＡＰ対Ｎｏｎ−ＡＰ ＳＴＡ＃２）との間に設定されてもよい。

図３は、Ｗｉ−Ｆｉダイレクトネットワークを構成する過程を説明するための図である。

図３を参照すると、Ｗｉ−Ｆｉダイレクトネットワーク構成過程は、２つの過程に大別できる。第一の過程は、近隣発見過程（Ｎｅｉｇｈｂｏｒ Ｄｉｓｃｏｖｅｒｙ（ＮＤ）ｐｒｏｃｅｄｕｒｅ）であり（Ｓ３０２ａ）、第二の過程は、Ｐ２Ｐリンク設定及び通信過程である（Ｓ３０４）。近隣発見過程で、Ｐ２Ｐデバイス（例えば、図２の２０２）は（自身の無線）カバレッジ内の他の近隣Ｐ２Ｐデバイス（例えば、図２の２０４）を探し、当該Ｐ２Ｐデバイスとの関連付け（ａｓｓｏｃｉａｔｉｏｎ）、例えば、事前関連付け（ｐｒｅ−ａｓｓｏｃｉａｔｉｏｎ）に必要な情報を取得することができる。ここで、事前関連付けは、無線プロトコルにおける第２層の事前関連付けを意味することができる。事前関連付けに必要な情報は、例えば、近隣Ｐ２Ｐデバイスに関する識別情報などを含むことができる。近隣発見過程は、使用可能な無線チャネル別に行うことができる（Ｓ３０２ｂ）。その後、Ｐ２Ｐデバイス２０２は、他のＰ２Ｐデバイス２０４とＷｉ−ＦｉダイレクトＰ２Ｐリンク設定／通信のための過程を行うことができる。例えば、Ｐ２Ｐデバイス２０２は周辺Ｐ２Ｐデバイス２０４に関連付けられた後、当該Ｐ２Ｐデバイス２０４がユーザのサービス要求事項を満たさないＰ２Ｐデバイスであるか否か判断することができる。そのために、Ｐ２Ｐデバイス２０２は、周辺Ｐ２Ｐデバイス２０４と第２層の事前関連付け後に、当該Ｐ２Ｐデバイス２０４を検索することができる。仮に、当該Ｐ２Ｐデバイス２０４がユーザのサービス要求事項を満たさない場合、Ｐ２Ｐデバイス２０２は、当該Ｐ２Ｐデバイス２０４に対して設定された第２層の関連付けを切断して、他のＰ２Ｐデバイスと第２層の関連付けを設定することができる。一方、当該Ｐ２Ｐデバイス２０４がユーザのサービス要求事項を満たす場合には、両Ｐ２Ｐデバイス２０２及び２０４はＰ２Ｐリンクを介して信号を送受信することができる。

図４は、近隣発見過程を説明するための図である。図４の例示は、図３におけるＰ２Ｐデバイス２０２とＰ２Ｐデバイス２０４との間の動作と理解してもよい。

図４を参照すると、図３の近隣発見過程は、ＳＭＥ（Ｓｔａｔｉｏｎ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ）／アプリケーション／ユーザ／ベンダーの指示によって開始され（Ｓ４１０）、スキャン段階（ｓｃａｎ ｐｈａｓｅ）Ｓ４１２と検索段階（ｆｉｎｄ ｐｈａｓｅ）Ｓ４１４〜Ｓ４１６とに区別できる。スキャン段階Ｓ４１２は、使用可能な全ての無線チャネルに対して８０２．１１方式によってスキャンする動作を含む。これによって、Ｐ２Ｐデバイスは最も良い動作チャネルを確認することができる。検索段階Ｓ４１４〜Ｓ４１６は、聴取（ｌｉｓｔｅｎ）モードＳ４１４及び検索（ｓｅａｒｃｈ）モードＳ４１６を含み、Ｐ２Ｐデバイスは、聴取モードＳ４１４と検索モードＳ４１６を交互に反復する。Ｐ２Ｐデバイス２０２，２０４は、検索モードＳ４１６でプローブ要求フレーム（Ｐｒｏｂｅ ｒｅｑｕｅｓｔ ｆｒａｍｅ）を用いてアクティブ検索を行い、高速な検索のために検索範囲をチャネル１、６、１１（例えば、２４１２、２４３７、２４６２ＭＨｚ）のソーシャルチャネル（ｓｏｃｉａｌ ｃｈａｎｎｅｌ）に限定することができる。また、Ｐ２Ｐデバイス２０２，２０４は、聴取モードＳ４１４で３個のソーシャルチャネルから一つのチャネルのみを選択して受信状態に維持する。このとき、他のＰ２Ｐデバイス（例、２０２）が検索モードで送信したプローブ要求フレームが受信された場合、Ｐ２Ｐデバイス（例えば、２０４）は、プローブ応答フレーム（ｐｒｏｂｅ ｒｅｓｐｏｎｓｅ ｆｒａｍｅ）で応答する。聴取モードＳ４１４の時間はランダムに与えられてもよい（例えば、１００、２００、３００ＴＵ（Ｔｉｍｅ Ｕｎｉｔ））。Ｐ２Ｐデバイスは、検索モードと受信モードを繰り返してお互いの共通チャネルに到達することができる。Ｐ２Ｐデバイスは他のＰ２Ｐデバイスを発見した後、当該Ｐ２Ｐデバイスに選択的に結合するために、プローブ要求フレームとプローブ応答フレームを用いてデバイスタイプ、メーカー又は親しみのあるデバイス名（ｎａｍｅ）を発見／交換することができる。近隣発見過程で周辺Ｐ２Ｐデバイスを発見し、必要な情報を得た場合、Ｐ２Ｐデバイス（例えば、２０２）は、ＳＭＥ／アプリケーション／ユーザ／ベンダーにＰ２Ｐデバイス発見を知らせることができる（Ｓ４１８）。

現在、Ｐ２Ｐは主に、遠隔プリント、写真共有などのような半静的（ｓｅｍｉ−ｓｔａｔｉｃ）な通信のために用いられている。しかし、Ｗｉ−Ｆｉデバイスの一般化と位置ベースのサービスなどによって、Ｐ２Ｐの活用は拡大の一路にある。例えば、ソーシャルチャット（例えば、ＳＮＳ（Ｓｏｃｉａｌ Ｎｅｔｗｏｒｋ Ｓｅｒｖｉｃｅ）に加入した無線デバイスが位置ベースサービスに基づいて近接地域の無線デバイスを認識して情報を送受信）、位置ベースの広告提供、位置ベースのニュース放送、無線デバイス間のゲーム連動などにＰ２Ｐが盛んに用いられると予想される。便宜上、このようなＰ２Ｐ応用を、新規Ｐ２Ｐ応用と呼ぶ。

図５は、Ｗｉ−Ｆｉダイレクトネットワークの新しい様子を説明するための図である。

図５の例示は、新規Ｐ２Ｐ応用（例えば、ソーシャルチャット、位置ベースのサービス提供、ゲーム連動など）が適用される場合のＷｉ−Ｆｉダイレクトネットワークの様子と理解してもよい。

図５を参照すると、Ｗｉ−Ｆｉダイレクトネットワークにおいて多数のＰ２Ｐデバイス５０２ａ〜５０２ｄがＰ２Ｐ通信５１０を行っており、Ｐ２Ｐデバイスの移動によってＷｉ−Ｆｉダイレクトネットワークを構成するＰ２Ｐデバイスが随時変更されたり、Ｗｉ−Ｆｉダイレクトネットワーク自体が動的に／短時間で新しく生成されたり消滅したりする。このように、新規Ｐ２Ｐ応用部分の特徴は、密集（ｄｅｎｓｅ）ネットワーク環境において相当数のＰ２Ｐデバイス間で動的に／短時間にＰ２Ｐ通信がなされ、終了し得るという点である。

図６は、Ｗｉ−Ｆｉダイレクト通信のためのリンクを設定する方法を説明するための図である。

図６ａに示すように、第１のＳＴＡ（６１０、以下、Ａと称する。）は、既存のＷｉ−Ｆｉダイレクト通信においてグループオーナー（Ｇｒｏｕｐ Ｏｗｎｅｒ）として動作している。既存Ｗｉ−Ｆｉダイレクト通信のグループクライアント６３０との通信中にＡ（６１０）が、新しいＷｉ−Ｆｉダイレクト通信対象である、Ｗｉ−Ｆｉダイレクト通信をしていない、第２のＳＴＡ（６２０、以下、Ｂと称する。）を発見した場合、Ａ（６１０）はＢ（６２０）とのリンク設定を試みる。この場合、新しいＷｉ−Ｆｉダイレクト通信は、Ａ（６１０）とＢ（６２０）との間のＷｉ−Ｆｉダイレクト通信であり、Ａはグループオーナーであるから、既存のグループクライアント６３０との通信とは別に通信設定を行うことができる。一つのＷｉ−Ｆｉダイレクトグループは一つのグループオーナーと一つ以上のグループクライアントとで構成でき、ここでは、一つのグループオーナーであるＡ（６１０）を満たすので、図６ｂに示すように、Ｗｉ−Ｆｉダイレクトリンクを設定することができる。これは、Ａ（６１０）が既存のＷｉ−Ｆｉダイレクト通信グループにＢ（６２０）を招待（ｉｎｖｉｔａｔｉｏｎ）した場合であり、Ｗｉ−Ｆｉダイレクト通信の特性上、Ａ（６１０）とＢ（６２０）との間、Ａ（６１０）と既存のグループクライアント６３０との間のＷｉ−Ｆｉダイレクト通信が可能である。なお、Ｂ（６２０）と既存のグループクライアント６３０との間のＷｉ−Ｆｉダイレクト通信も、デバイスの能力（ｃａｐａｂｉｌｉｔｙ）に応じて選択的にサポート可能である。

図７は、Ｗｉ−Ｆｉダイレクト通信をしている通信グループに参加（ａｓｓｏｃｉａｔｉｏｎ）する方法を説明するための図である。

図７ａに示すように、第１のＳＴＡ（７１０、以下、Ａと称する。）は、グループクライアント７３０に対してグループオーナーとして通信中であり、第２のＳＴＡ（７２０、以下、Ｂと称する。）は、グループクライアント７４０に対してグループオーナーとして通信中である。図７ｂに示すように、Ａ（７１０）は、既存のＷｉ−Ｆｉダイレクト通信を終了（ｔｅｒｍｉｎａｔｉｏｎ）し、Ｂ（７２０）の属したＷｉ−Ｆｉダイレクト通信グループに参加（ａｓｓｏｃｉａｔｉｏｎ）することができる。Ａ（７１０）は、Ｂ（７２０）がグループオーナーであるから、Ｂのグループクライアントとなる。Ａ（７１０）は、Ｂ（７２０）に関連付けを要求する前に、既存のＷｉ−Ｆｉダイレクト通信を終了することが好ましい。

図８は、Ｗｉ−Ｆｉダイレクト通信のためのリンクを設定する方法を説明するための図である。

図８ａに示すように、第２のＳＴＡ（８２０、以下、Ｂと称する。）は、既存のＷｉ−Ｆｉダイレクト通信においてグループオーナー（Ｇｒｏｕｐ Ｏｗｎｅｒ）として動作中である。既存のＷｉ−Ｆｉダイレクト通信においてグループクライアント８３０とＷｉ−Ｆｉダイレクト通信中である場合、Ｂ（８２０）を発見した、Ｗｉ−Ｆｉダイレクト通信をしていない第１のＳＴＡ（８１０、以下、Ａと称する。）がＢ（８２０）との新しいＷｉ−Ｆｉダイレクト通信のためにリンク設定を試みる。この場合、Ｂ（８２０）がリンク設定を受諾すると、Ａ（８１０）とＢ（８２０）との間の新しいＷｉ−Ｆｉダイレクト通信リンクが設定され、Ａ（８１０）は既存のＢ（８２０）のＷｉ−Ｆｉダイレクトグループのクライアントとして動作するようになる。これは、Ａ（８１０）がＢ（８２０）のＷｉ−Ｆｉダイレクト通信グループに参加（ａｓｓｏｃｉａｔｉｏｎ）した場合となる。Ａ（８１０）はグループオーナーであるＢ（８２０）のみとＷｉ−Ｆｉダイレクト通信することができる。なお、Ａ（８１０）と既存のＷｉ−Ｆｉダイレクト通信のクライアント８３０との間のＷｉ−Ｆｉダイレクト通信は、デバイスの能力に応じて選択的に可能である。

図９は、Ｗｉ−Ｆｉダイレクト通信グループに参加するリンクを設定する方法を説明するための図である。

図９ａに示すように、第１のＳＴＡ（９１０、以下、Ａと称する。）は、グループオーナー９３０に対してグループクライアントとしてＷｉ−Ｆｉダイレクト通信中である。このとき、他のＷｉ−Ｆｉダイレクト通信のグループクライアント９４０に対してグループオーナーとして通信中である第２のＳＴＡ（９２０、以下、Ｂと称する。）を発見したＡ（９１０）は、グループオーナー９３０とのリンクを終了（ｔｅｒｍｉｎａｔｉｏｎ）し、Ｂ（９２０）のＷｉ−Ｆｉダイレクト通信グループに参加することができる。

Ｗｉ−Ｆｉダイレクトサービス（ＷＦＤＳ）
Ｗｉ−Ｆｉダイレクトは、リンク層（Ｌｉｎｋ ｌａｙｅｒ）の動作まで定義するネットワーク接続標準技術である。Ｗｉ−Ｆｉダイレクトによって構成されたリンクの上位層で動作するアプリケーションに対する標準が定義されていないことから、Ｗｉ−Ｆｉダイレクトをサポートするデバイスが相互接続された後にアプリケーションを駆動する場合の互換性をサポートすることが難しかった。このような問題を解決するために、Ｗｉ−Ｆｉダイレクトサービス（ＷＦＤＳ）という上位層アプリケーションの動作に対する標準化がＷｉ−Ｆｉアライアンス（ＷＦＡ）で議論されている。

図１０は、ＷＦＤＳフレームワーク構成要素を説明するための図である。

図１０のＷｉ−Ｆｉダイレクト層は、Ｗｉ−Ｆｉダイレクト標準によって定義されるＭＡＣ層を意味する。Ｗｉ−Ｆｉダイレクト層は、Ｗｉ−Ｆｉダイレクト標準と互換性のあるソフトウェアとして構成することができる。Ｗｉ−Ｆｉダイレクト層の下位には、Ｗｉ−Ｆｉ ＰＨＹと互換性のある物理層（図示せず）によって無線接続が構成されてもよい。Ｗｉ−Ｆｉダイレクト層の上位にＡＳＰ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｉｃｅ Ｐｌａｔｆｏｒｍ）というプラットホームが定義される。

ＡＳＰは、サービスが必要とする機能を実行する論理エンティティである。ＡＳＰは共通共有プラットホーム（ｃｏｍｍｏｎ ｓｈａｒｅｄ ｐｌａｔｆｏｒｍ）であり、上位のアプリケーション（Ａｐｐｌｉｃａｔｉｏｎ）層と下位のＷｉ−Ｆｉダイレクト層との間においてデバイス探索（Ｄｅｖｉｃｅ Ｄｉｓｃｏｖｅｒｙ）、サービス探索（Ｓｅｒｖｉｃｅ Ｄｉｓｃｏｖｅｒｙ）、ＡＳＰセッション管理（ＡＳＰ Ｓｅｓｓｉｏｎ ｍａｎａｇｅｍｅｎｔ）、接続トポロジ管理（Ｃｏｎｎｅｃｔｉｏｎ ｔｏｐｏｌｏｇｙ ｍａｎａｇｅｍｅｎｔ）及びセキュリティ（Ｓｅｃｕｒｉｔｙ）などのタスクを処理することができる。

ＡＳＰの上位にはサービス（Ｓｅｒｖｉｃｅ）層が定義される。サービス層は、用途（ｕｓｅ ｃａｓｅ）特有のサービスを含む。ＷＦＤＳでは、４個の基本サービスである送信（Ｓｅｎｄ）、プレイ（Ｐｌａｙ）、ディスプレイ（Ｄｉｓｐｌａｙ）、プリント（Ｐｒｉｎｔ）サービスを定義する。ＷＦＤＳで定義する４個の基本サービスを簡略に説明すると、まず、Ｓｅｎｄは、両ＷＦＤＳデバイス間でファイル伝送が可能なサービス及びアプリケーションを意味する。送信サービスは、ピア機器間のファイルを伝送するためのものである点で、ファイル伝送サービス（Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｓｅｒｖｉｃｅ、ＦＴＳ）と呼ぶこともできる。Ｐｌａｙは、ＤＬＮＡ（Ｄｉｇｉｔａｌ Ｌｉｖｉｎｇ Ｎｅｔｗｏｒｋ Ａｌｌｉａｎｃｅ）に基づき、２つのＷＦＤＳデバイス間でオーディオ／ビデオ（Ａ／Ｖ）、写真、音楽などを共有又はストリーミングするサービス及びアプリケーションを意味する。Ｐｒｉｎｔは、文書、写真などのコンテンツを有するデバイスとプリンタとの間で文書、写真の出力を可能にするサービス及びアプリケーションを意味する。Ｄｉｓｐｌａｙは、ＷＦＡのミラキャスト（Ｍｉｒａｃａｓｔ）ソースとシンクとの間に画面共有を可能にするサービス及びアプリケーションを意味する。

図１０に示すイネーブル（Ｅｎａｂｌｅ）ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）は、ＷＦＤＳで定める基本サービスの他にサードパーティー（３ｒｄ ｐａｒｔｙ）アプリケーションをサポートする場合にＡＳＰ共通プラットホームを利用可能にするために定義される。サードパーティーアプリケーションのために定義されるサービスは、一つのアプリケーションでのみ利用されてもよく、様々なアプリケーションで一般に（又は共通に）利用されてもよい。

説明の便宜のために、ＷＦＤＳによって定義されたサービスはＷＦＤＳサービス、ＷＦＡ以外のサードパーティーによって新しく定義されるサービスはイネーブルサービスと呼ぶものとする。

アプリケーション層はユーザインターフェース（ＵＩ）を提供することができ、情報を人にとって認識可能な形態で表現し、ユーザの入力を下位層に伝達するなどの機能を果たす。

上述した説明に基づいて、ＷＦＤＳのうちディスプレイ（Ｄｉｓｐｌａｙ）サービスについてより詳しく説明する。

Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙ
ＷＦＤＳのうち、ディスプレイサービスは、Ｐ２Ｐデバイス間に画面共有を可能にするサービス及びアプリケーションを意味する。ディスプレイサービスを利用するＰ２Ｐデバイスを、ＷＦＤデバイスと呼ぶことができ、ＷＦＤデバイスのうち、Ｐ２Ｐリンクを介してマルチメディアコンテンツのストリーミングをサポートする機器をＷｉ−Ｆｉディスプレイ（ＷＦＤ）ソース（Ｓｏｕｒｃｅ）、Ｐ２Ｐリンクを介してＷＦＤソース機器から受信してレンダリングする機器をＷＦＤシンク（Ｓｉｎｋ）と呼ぶことができる。

図１１は、ＷＦＤソースとＷＦＤシンクとの間にＷＦＤセッションが構築される過程を説明するためのフローチャートである。ＷＦＤソース及びＷＦＤシンクはまず、ＷＦＤデバイス探索（ＷＦＤ Ｄｅｖｉｃｅ Ｄｉｓｃｏｖｅｒｙ）によって、ＷＦＤ接続セットアップに先立ってお互いの存在を探索することができる。具体的には、ＷＦＤデバイスは、ＷＦＤ情報要素（ＷＦＤ ＩＥ）を含むプローブ要求フレーム及びプローブ応答フレームを用いてお互いの存在を認識できる。ＷＦＤ情報要素は、デバイスタイプ及びデバイス状態などの、ＷＦＤデバイス間の最適な接続を構築するための基本情報を含むことができる。ＷＦＤデバイスが、ＷＦＤ ＩＥを含むプローブ要求フレームを受信すると、それに対する応答として、自身のＷＦＤ ＩＥを含むプローブ応答フレームを送信することができる。

仮にＷＦＤデバイスがＡＰと関連付けられており、Ｗｉ−Ｆｉ Ｐ２Ｐデバイスとして動作する場合、物理的な一つのデバイスに２個以上のＷｉ−Ｆｉ送受信機が論理的に動作するようになる。このとき、ＷＦＤデバイス探索のためには、このうちの、Ｗｉ−Ｆｉダイレクト送受信機を使用するようになる。ＷＦＤデバイスの探索のためのプローブ要求フレームには、ＷＦＤ ＩＥの他、Ｐ２Ｐ情報要素（ＩＥ）が含まれてもよく、これは、Ｗｉ−Ｆｉダイレクト送受信機によってデコーディング可能である。

その後、ＷＦＤソース及びＷＦＤシンクは、ＷＦＤ接続セットアップに先立ってお互いのサービス能力を探索することができる。具体的には、いずれか一つのＷＦＤデバイスが、ＷＦＤ能力が情報副要素（ｉｎｆｏｒｍａｔｉｏｎ ｓｕｂｅｌｅｍｅｎｔ）として含まれるサービス探索要求フレームを送信すると、他のＷＦＤデバイスはそれに対する応答として、自身のＷＦＤ能力が情報副要素として含まれるサービス探索応答フレームを送信することができる。サービス探索手順は選択的な手順であり、サービス探索手順をサポートするＷＦＤデバイスは、サービス探索手順をサポートする探索されたＷＦＤデバイスとサービス探索手順を行うことができる。サービス探索手順を行うために、デバイス探索手順に用いられるプローブ要求フレーム及び応答フレームには、ＷＦＤデバイスがサービス探索手順をサポートする能力を有するか否かを示す情報が含まれてもよい。

その後、ＷＦＤソース又はＷＦＤシンクは、ＷＦＤ接続セットアップのためのピアＷＦＤデバイスを選択することができる。ユーザの入力によってＷＦＤ接続セットアップを行うピアＷＦＤデバイスが選択されてもよく、ポリシー（ｐｏｌｉｃｙ）によって自動でＷＦＤ接続セットアップを行うピアＷＦＤデバイスが選択されてもよい。

その後、ＷＦＤデバイスは、選択されたピアＷＦＤデバイスとＷＦＤ接続セットアップ方法を選択することができる。具体的には、ＷＦＤデバイスは、Ｗｉ−Ｆｉ Ｐ２Ｐ又はＴＤＬＳのいずれかの接続スキーム（Ｃｏｎｎｅｃｔｉｖｉｔｙ Ｓｃｈｅｍｅ）でＷＦＤ接続を構築することができる。ＷＦＤデバイスは、好ましい接続（Ｐｒｅｆｅｒｒｅｄ Ｃｏｎｎｅｃｔｉｖｉｔｙ）情報と、ＷＦＤ情報要素と併せて伝達される関連付けられたＢＳＳＩＤ副要素とに基づいて、接続スキームを決定することができる。

ＷＦＤデバイスの間に、Ｗｉ−Ｆｉ Ｐ２Ｐ又はＴＤＬＳを用いて正常にＷＦＤセットアップが行われると、ＷＦＤデバイスはＷＦＤ能力交渉（ＷＦＤ ｃａｐａｂｉｌｉｔｙ ｎｅｇｏｔｉａｔｉｏｎ）を行うことができる。具体的には、ＷＦＤソース及びＷＦＤシンクは、ＲＴＳＰ（Ｒｅａｌ−Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）プロトコルを用いてメッセージを交換することによって、ＷＦＤセッションにおけるオーディオ／ビデオペイロード（ｐａｙｌｏａｄ）を定義するパラメータセットを決定することができる。

ＷＦＤ能力交渉段階が正常に終了すると、ＷＦＤソースとＷＦＤシンクとの間にＷＦＤセッション（又はミラキャストセッション）が構築され、ＷＦＤソースからＷＦＤシンクにオーディオ／ビデオコンテンツをストリーミングすることができる。

図１２は、図１１に示した過程によって、ＷＦＤソースとＷＦＤシンクとの間にＷＦＤセッションが構築される場合のトポロジを図式化した図である。図１２の例示のように、ＷＦＤソース及びＷＦＤシンクは、ＷＦＤデバイス探索／サービス探索を行った後、ダイレクトリンク（例えば、Ｗｉ−Ｆｉ Ｐ２Ｐリンク又はＴＤＬＳリンク）を構築することができる。その後、ＷＦＤセッション（又はミラキャストセッション）が構築されると、ＷＦＤソースからＷＦＤシンクにコンテンツをストリーミングすることができる。

この例示とは違い、ＷＦＤソースとＷＦＤシンクとの間に既にダイレクトリンク（例えば、Ｗｉ−Ｆｉ Ｐ２Ｐリンク又はＴＤＬＳリンク）が構築されていてもよい。この場合、ＷＦＤソース及びＷＦＤシンクは、既に構築されたダイレクトリンクを解除し、新しくダイレクトリンクを構築する代わりに、既存のダイレクトリンクを用いてＷＦＤセッションを構築することもできる。

一例として、図１３は、ＷＦＤソースとＷＦＤシンクとの間に既にダイレクトリンクが存在する場合に、ＷＦＤセッションが構築されるトポロジを図式化した図である。ＷＦＤソースとＷＦＤシンクとの間に既にダイレクトリンクが存在すると、該ダイレクトリンクをミラキャストに再使用することができる。

図１３に示す例のように、ＷＦＤデバイス間に既にＩＰ接続が構築されている状態では、ＷＦＤデバイス間のＷＦＤデバイス探索／サービス探索はＩＰパケットによって行われてもよく、図１１で説明したとおり、プローブ要求及び応答フレーム、サービス要求及び応答フレームによって行われてもよい。

なお、ＷＦＤセッションは、ＩＰパケット又はＬａｙｅｒ２フレーム（例えば、ＭＡＣフレーム）を用いて既存のダイレクトリンク上で接続が開始されてもよい。

次に、ＷＦＤソースがＡＰと接続された状態でＷＦＤセッションが構築される過程について説明する。図１４は、ＷＦＤソースがＡＰと接続されており、ＷＦＤシンクはＡＰと接続されていないときに、ＷＦＤセッションが構築されるトポロジを図式化した図である。ＷＦＤソースが複数のＰ２Ｐリンクを有してもよいＰ２Ｐ同時サポートモード（Ｐ２Ｐ Ｃｏｎｃｕｒｒｅｎｔ Ｍｏｄｅ）をサポートするなら、ＷＦＤソースはＡＰとの接続を維持した状態でＷＦＤデバイス探索／サービス探索を行った後、既存ＡＰとの接続を維持しながら、ＷＦＤシンクとダイレクトリンクを生成することができる。

これと違い、ＷＦＤソースがＰ２Ｐ同時サポートモードをサポートしないなら、ＷＦＤソースは、既存ＡＰとのインフラストラクチャーリンクを解除した後、ＷＦＤデバイス探索／サービス探索を行うことができる。これによって、ＷＦＤソースはＡＰとの接続が解除された状態で、ＷＦＤシンクとダイレクトリンクを生成することができる。

ＷＦＤソースとＷＦＤシンクとの間にダイレクトリンクが生成されると、ＷＦＤソース及びＷＦＤシンクはダイレクトリンクを介してＷＦＤセッションを開始し、コンテンツをストリーミングすることができる。

ＷＦＤソースがＡＰと接続されており、ＷＦＤソースとＷＦＤシンクとの間に既にダイレクトリンクも存在する場合には、ＷＦＤソースとＷＦＤシンクとの間のダイレクトリンクをミラキャストに再使用することができる。一例として、図１５は、ＷＦＤソースがＡＰと接続されており、ＷＦＤソースとＷＦＤシンクとの間に既にダイレクトリンクが存在する場合に、ＷＦＤセッションが構築されるトポロジを図式化した図である。

図１５に示す例のように、ＷＦＤデバイス間に既にＩＰ接続が構築されている状態では、ＷＦＤデバイス間のＷＦＤデバイス探索／サービス探索は、ＩＰパケットによって行われてもよく、図１１で説明したとおり、プローブ要求及び応答フレーム、サービス要求及び応答フレームによって行われてもよい。

なお、ＷＦＤセッションは、ＩＰパケット又はＬａｙｅｒ２フレーム（例えば、ＭＡＣフレーム）を用いて既存のダイレクトリンク上で接続が開始されてもよい。

次に、ＷＦＤソース及びＷＦＤシンクが同一のＡＰと接続されている場合に、ＷＦＤセッションが構築されるトポロジについて詳しく説明する。

図１６乃至図１９は、ＷＦＤソース及びＷＦＤシンクが同一のＡＰと接続されている場合に、ＷＦＤセッションが構築されるトポロジを図式化した図である。

ＷＦＤソースとＷＦＤシンクが同一のＡＰに接続された状態では、ＷＦＤデバイスはＡＰを経由するＩＰパケットを用いてＷＦＤデバイス探索／サービス探索を行ってもよく、図１１の例示のように、プローブ要求及び応答フレーム、サービス要求及び応答フレームを用いてＷＦＤデバイス探索／サービス探索を行ってもよい。

一例として、図１６及び図１７では、ＷＦＤソース及びＷＦＤシンクがＡＰを経由しないプローブ要求及び応答フレーム、サービス要求及び応答フレームを用いてＷＦＤデバイス探索／サービス探索を行うことを示しており、図１８及び図１９では、ＷＦＤソース及びＷＦＤシンクがＡＰを経由するデバイス／サービス探索要求パケットとデバイス／サービス探索応答パケットを用いてＷＦＤデバイス探索／サービス探索を行うことを示している。

ＷＦＤデバイス探索／サービス探索の後、ＷＦＤソース及びＷＦＤシンクは、図１６及び図１９の例示のように、ＷＦＤセッションの接続のためにダイレクトリンクを生成することができる。ＷＦＤソースとＷＦＤシンクとの間にダイレクトリンクが生成されると、ＷＦＤソース及びＷＦＤシンクは、図１６及び図１９の例示のように、ダイレクトリンクを介してＷＦＤセッションを開始し、コンテンツをストリーミングすることができる。

これと違い、ＷＦＤソース及びＷＦＤシンクは、図１７及び図１８の例示のように、両者間にダイレクトリンクを生成せず、既存ＡＰとの接続（すなわち、インフラストラクチャーリンク）を再使用してＷＦＤセッションを開始することもできる。ただし、この場合、ＷＦＤソース及びＷＦＤシンクは互いに同一のＡＰに接続されていることを事前に認識する必要がある。ＷＦＤソースとＷＦＤシンクとの間の離隔距離が長いため、Ｗｉ−Ｆｉダイレクト通信を行うには不適であるが、ＷＦＤソース及びＷＦＤシンクが同一のＡＰと接続されているなら、既存ＡＰとの接続を再使用する方が、ＷＦＤセッションの構築には効果的であろう。

次に、ＷＦＤソース及びＷＦＤシンクのうちＷＦＤシンクのみがＡＰに接続されている場合に、ＷＦＤセッションが構築される過程について説明する。

図２０及び図２１は、ＷＦＤシンクがＡＰに接続されている場合に、ＷＦＤセッションが構築されるトポロジを図式化した図である。まず、ＷＦＤソースはプローブ要求フレーム及び応答フレームの送受信によってＷＦＤシンクを探索することができる。

その後、ＷＦＤソース及びＷＦＤシンクは、図２０の例示のように、ＷＦＤセッションを生成するためのダイレクトリンクを生成し、生成されたダイレクトリンクを介してＷＦＤセッションを開始することができる。ＷＦＤソースは、ＷＦＤセッションを介してＷＦＤシンクにコンテンツをストリーミングすることができる。

仮に、ＷＦＤソースがＷＦＤシンクの接続しているＡＰを知っていると、ＷＦＤソースは、ＷＦＤシンクとダイレクトリンクを生成する代わりに、図２１の例示のように、ＷＦＤシンクが接続しているＡＰに接続した後、ＡＰとの接続を用いてＷＦＤセッションを構築することもできる。ＷＦＤソースはＷＦＤセッションを介してＷＦＤシンクにコンテンツをストリーミングすることができる。

図２２及び図２３は、ＷＦＤソース及びＷＦＤシンクが異なったＡＰに接続されているときに、ＷＦＤセッションが構築されるトポロジを図式化した図である。ＷＦＤソースとＷＦＤシンクが異なったＡＰに接続している場合、ＷＦＤシンクは、プローブ要求フレーム及び応答フレームの送受信を用いてＷＦＤシンクを探索することができる。

その後、ＷＦＤソース及びＷＦＤシンクは、図２２の例示のように、ＷＦＤセッションを生成するためのダイレクトリンクを生成し、生成されたダイレクトリンクを介してＷＦＤセッションを開始することができる。ＷＦＤソースはＷＦＤセッションを介してＷＦＤシンクにコンテンツをストリーミングすることができる。

これと違い、ＷＦＤソースは、図２３の例示のように、ＷＦＤシンクが接続しているＡＰに接続した後、ＷＦＤソースとＷＦＤシンクとが共通に接続しているＡＰとの接続を用いてＷＦＤセッションを構築することもできる。一例として、ＷＦＤソースがＡＰ１に接続している状態で、ＷＦＤシンクがＡＰ２に接続していると、ＷＦＤソースは、ＡＰ１との接続を切ってＡＰ２に接続した後、ＷＦＤソース及びＷＦＤシンクとが共通に接続しているＡＰ２との接続を用いてＷＦＤセッションを構築することができる。これによって、ＷＦＤソースは、ＡＰ２を経由するようにして生成されたＷＦＤセッションを用いて、ＷＦＤシンクにコンテンツをストリーミングすることができる。

図１２乃至図２３に示す種々のトポロジの例において、基本的に、ＷＦＤソース及びＷＦＤシンクはダイレクトリンクを構築した後、ダイレクトリンクを用いてコンテンツストリーミングのためのＷＦＤセッションを開始することができる。これと違い、ＷＦＤソースとＷＦＤシンクが同一のＡＰに接続している状態であるか、ＷＦＤソースがＷＦＤシンクの接続しているＡＰに接続可能な場合には、ダイレクトリンクを構築せず、ＡＰとの接続を用いてコンテンツストリーミングのためのＷＦＤセッションを開始することもできる。図示してはいないが、ＷＦＤシンクがＷＦＤソースの接続しているＡＰに接続可能であると、この場合にもダイレクトリンクを構築せず、ＡＰとの接続を用いてコンテンツストリーミングのためのＷＦＤセッションを開始することができる。

ただし、共通に接続しているＡＰを介してＷＦＤセッションを開始するとき、ＷＦＤソースは、ＷＦＤシンクが接続中であるＡＰに関する情報を取得する必要がある。ＷＦＤソースがＡＰに接続中であれば、ＷＦＤシンクを探索するためのデバイス／サービス探索要求パケットのブロードキャスティング範囲を自身の属したサブネット（ｓｕｂｎｅｔ）に限定することによって、同一のＡＰに接続しているＷＦＤシンクを探索できるが、ＷＦＤシンクがＷＦＤソースと異なるＡＰに接続している場合、又はＷＦＤソースがＡＰに接続していない状態なら、デバイス／サービス探索要求パケットのブロードキャスティングを用いてはＷＦＤシンク或いはＷＦＤシンクの接続しているＡＰ情報が取得し難い。

そこで、本発明では、ＷＦＤソースがＷＦＤデバイスの探索過程及びサービス探索過程でＷＦＤソースの接続しているＡＰ情報をＷＦＤシンクに知らせたり、ＷＦＤソースがＷＦＤシンクの接続しているＡＰ情報を取得したりする方法について提案する。

ＷＦＤソース及びＷＦＤシンクは、プローブ要求フレーム及びプローブ応答フレームを用いてお互いを探索することができる。具体的には、プローブ要求フレーム及びプローブ応答フレームは、Ｐ２Ｐ情報要素及びＷＦＤ情報要素の少なくとも一つを含むことができる。

表１には、ＷＦＤ情報要素のフォーマットを示す。

要素ＩＤフィールドは、プローブ要求フレーム及びプローブ応答フレーム内のＷＦＤ情報要素を識別する役割を担う。長さフィールドは、ＷＦＤ情報要素の長さ又は長さフィールドに続く残りのフィールドの長さを示すことができる。

ＯＵＩ（Ｏｒｇａｎｉｚａｔｉｏｎａｌｌｙ Ｕｎｉｑｕｅ ｉｄｅｎｔｉｆｉｅｒ）フィールドは、ＷＦＡ（Ｗｉ−Ｆｉ Ａｌｌｉａｎｃｅ）で定めた値を有することができる。ＯＵＩタイプフィールドは、ＷＦＤ情報要素のバージョンを示す。一例として、ＯＵＩタイプフィールドの値が０ｘ０Ａであれば、これはＷＦＤ ｖ１．０を示すことができる。

ＷＦＤ情報要素には、ＷＦＤ副要素が含まれてもよい。表２に、ＷＦＤ情報要素に含まれるＷＦＤ副要素のフォーマットを説明する。

表２の副要素ＩＤフィールドは、ＷＦＤ副要素のタイプを識別し、長さフィールドは、ＷＦＤ副要素の長さ又は長さフィールドに続く残りのフィールドの長さを示すことができる。

副要素ボディーフィールドには、副要素に応じた適切な値を挿入することができる。

ＷＦＤ副要素として使用可能な情報は、表３のとおりである。

表３に列挙されたとおり、ＷＦＤ情報要素は、ＷＦＤデバイス情報、ＷＦＤデバイスと関連付けられたＢＳＳＩＤ、ＷＦＤオーディオフォーマット、ＷＦＤビデオフォーマット、ＷＦＤ３Ｄビデオフォーマット、ＷＦＤコンテンツ保護、接続されたシンク情報、拡張されたＷＦＤセッション能力、ＷＦＤセッション情報、代替ＭＡＣアドレスなどを含むことができる。

ここで、ＷＦＤデバイス情報は、ＷＦＤデバイス情報及びセッション管理制御ポートに関する情報を含むことができ、関連付けられたＢＳＳＩＤ情報は、ＷＦＤデバイスが関連付けられたＢＳＳＩＤの情報を含むことができる。

ＷＦＤオーディオフォーマット、ＷＦＤビデオフォーマット及びＷＦＤ３Ｄビデオフォーマットは、ＷＦＤデバイスがサポートするビデオ／オーディオフォーマット及び３Ｄビデオフォーマットの情報を含むことができる。また、ＷＦＤコンテンツ保護フィールドは、コンテンツ保護方法に関する情報を含むことができ、接続されたシンク情報は、ＷＦＤシンクがＷＦＤソースを探索する場合、ＷＦＤシンクが接続されたシンクモードをサポートする場合に含まれてもよい。拡張されたＷＦＤ能力は、ＷＦＤデバイスがＴＤＬＳ持続能力（ＴＤＬＳ ｐｅｒｓｉｓｔｅｎｃｅ ｃａｐａｂｉｌｉｔｙ）をサポートする場合に含まれてもよい。

次に、表４は、Ｐ２Ｐ情報要素のフォーマットを説明するためのものである。

表４に列挙されたとおり、Ｐ２Ｐ情報要素は、デバイスのＰ２Ｐ能力、Ｐ２Ｐデバイス情報、Ｐ２ＰグループＩＤ、意図したＰ２Ｐインターフェースアドレス、デバイス状態、動作チャネル、チャネルリスト、セッション情報データ情報、接続能力情報、広告ＩＤ情報、タイムアウト設定情報、聴取チャネル、セッションＩＤ情報、特定能力、永続的なグループ情報などの、ＷＦＤソースとＷＦＤシンクとの間に既に構築されたダイレクトリンクを用いるための情報を含むことができる。

プローブ要求フレーム及びプローブ応答フレームがＰ２Ｐ情報要素及びＷＦＤ情報要素の両方を含む場合、ＷＦＤソース及びＷＦＤシンクは、Ｐ２Ｐ情報要素を用いてＰ２Ｐ接続を構築することができ、ＷＦＤ情報要素を用いてＷＦＤセッション（又はミラキャストセッション）接続を構築することができる。

プローブ要求フレーム及びプローブ応答フレームには、ＷＳＣ（Ｗｉ−Ｆｉ Ｓｉｍｐｌｅ Ｃｏｎｆｉｇｕｒａｔｉｏｎ）情報要素がさらに含まれてもよい。ＷＳＣ情報要素としては、ＷＳＣ又はＷＰＳ（Ｗｉ−Ｆｉ Ｐｒｏｔｅｃｔｅｄ Ｓｅｔｕｐ）のための情報を含むことができるが、具体的には、ＷＳＣ情報要素としては、ＵＵＩＤ−Ｅ、メーカー、モデル名、モデル番号、シリアル番号、主デバイスタイプ（Ｐｒｉｍａｒｙ Ｄｅｖｉｃｅ Ｔｙｐｅ）、デバイス名、設定方法などの情報を含むことができる。

図２４は、プローブ要求フレーム及びプローブ応答フレームのフォーマットを簡略に示す図である。

ここで、ＷＦＤソース又はＷＦＤシンクがＡＰと関連付けられた状態であれば、ＡＰと関連付けられたＷＦＤデバイスは、プローブ要求フレーム又はプローブ応答フレームを用いて、自身が関連付けられたＡＰの情報を他のＷＦＤデバイスに知らせることができる。

具体的には、ＷＦＤデバイスは、プローブ要求フレーム及びプローブ応答フレームのＰ２Ｐ情報要素及びＷＦＤ情報要素の少なくとも一つに、自身が関連付けられたＡＰに関する情報を含めることによって、関連付けられたＡＰに関する情報を他のＷＦＤデバイスに伝達することができる。ここで、ＡＰに関する情報は、インフラストラクチャーＢＳＳ属性情報と呼ぶことができるが、この名称に限定されるものではない。

インフラストラクチャーＢＳＳ属性情報は、Ｐ２Ｐ情報要素に含まれてもよく、ＷＦＤ情報要素に含まれてもよく、Ｐ２Ｐ情報要素及びＷＦＤ情報要素の両方に含まれてもよい。

インフラストラクチャーＢＳＳ属性情報を受信したＷＦＤデバイスは、インフラストラクチャーＢＳＳ属性情報をデコーティングし、相手ＷＦＤデバイスが関連付けられたＡＰの情報及び相手ＷＦＤデバイスにＡＰから割り当てられたＩＰアドレスなどを認識することができる。

一例として、表５は、インフラストラクチャーＢＳＳ属性情報のフォーマットを説明するためのものである。

表５に列挙された項目のうち、属性ＩＤフィールドは、Ｐ２Ｐ情報要素又はＷＦＤ情報要素内のインフラストラクチャーＢＳＳ属性情報を識別する役割を担う。なお、長さフィールドは、インフラストラクチャーＢＳＳ属性情報の長さ又は長さフィールドに続く残りのフィールドの長さを示すことができる。

ＭＡＣアドレスフィールドは、ＡＰのＢＳＳＩＤを示すことができる。

国文字列フィールドは、動作クラス及びチャネルナンバーフィールドが有効な国コードを明示する。

動作クラスフィールドは、ＡＰが動作する周波数帯域（ｆｒｅｑｕｅｎｃｙ ｂａｎｄ）を示し、チャネル番号フィールドは、ＡＰが動作するチャネル番号を示す。動作クラスフィールド及びチャネル番号フィールドを用いて、ＷＦＤデバイスは、自身と関連付けられたＡＰの周波数帯域及びチャネル番号に関する情報を相手ＷＦＤデバイスに知らせることができる。

ＳＳＩＤ長フィールドは、ＡＰのＳＳＩＤの長さを示し、ＳＳＩＤフィールドは、ＡＰのＳＳＩＤを示す。ＷＦＤデバイスは、ＳＳＩＤ長フィールド及びＳＳＩＤフィールドを用いて相手ＷＦＤデバイスに自身が関連しているＡＰのＳＳＩＤを知らせることができる。

ＩＰバージョンフィールドは、ＩＰバージョンを示す。一例として、ＩＰバージョンフィールドの値が０ｘ０４であると、ＩＰ ｖ４が用いられることを示し、０ｘ０６であると、ＩＰ ｖ６が用いられることを示すことができる。

ＩＰアドレスフィールドは、ＡＰに接続されたＷｉ−ＦｉインターフェースのＩＰアドレスを示す。ＷＦＤデバイスは、ＩＰアドレスフィールドを用いて相手ＷＦＤデバイスに自身のＩＰアドレスを知らせることができる。

ＷＦＤソースがインフラストラクチャーＢＳＳ属性情報を含むプローブ要求フレームをブロードキャストすると、ＷＦＤシンクは、インフラストラクチャーＢＳＳ属性情報から、ＷＦＤソースと同じＡＰに関連付けられているか確認したり、ＷＦＤソースが関連付けられたＡＰへの接続を試みたりすることができる。

逆に、ＷＦＤシンクがインフラストラクチャーＢＳＳ属性情報を含むプローブ応答フレームをＷＦＤソースに送信すると、ＷＦＤソースは、インフラストラクチャーＢＳＳ属性情報から、ＷＦＤシンクが関連付けられたＡＰと同じＡＰに関連付けられているか確認したり、ＷＦＤシンクが関連付けられたＡＰへの接続を試みたりすることができる。

ＷＦＤデバイスは、サービス探索要求フレーム及びサービス探索応答フレームを用いて、自身が関連しているＡＰに関する情報を知らせることもできる。この場合、インフラストラクチャーＢＳＳ属性情報は、属性フレームフォーマット又はＵＴＦ−８文字列の形態でサービス探索要求フレーム及びサービス探索応答フレームに含まれてもよい。

インフラストラクチャーＢＳＳ属性情報は、サービス探索手順において、サービス探索要求フレーム及びサービス探索応答フレームに含まれてもよい。この場合、インフラストラクチャーＢＳＳ属性情報は、属性フレームフォーマット又はＵＴＦ−８文字列の形態でサービス探索要求フレーム及びサービス探索応答フレームに含まれてもよい。

ＷＦＤソースが、インフラストラクチャーＢＳＳ属性情報を含むサービス探索要求フレームをＷＦＤシンクに送信すると、ＷＦＤシンクは、インフラストラクチャーＢＳＳ属性情報から、ＷＦＤソースと同じＡＰに関連付けられているか確認したり、ＷＦＤソースが関連付けられたＡＰへの接続を試みたりすることができる。

逆に、ＷＦＤシンクが、インフラストラクチャーＢＳＳ属性情報を含むサービス探索応答フレームをＷＦＤソースに送信すると、ＷＦＤソースは、インフラストラクチャーＢＳＳ属性情報から、ＷＦＤシンクが関連付けられたＡＰと同じＡＰに関連付けられているか確認したり、ＷＦＤシンクが関連付けられたＡＰへの接続を試みたりすることができる。

一例として、図２５は、ＷＦＤシンクがＡＰに関連付けられたとき、ＷＦＤシンクが関連付けられたＡＰに関する情報をＷＦＤソースに知らせる例を示す図である。図２５の例示のように、ＷＦＤシンクは、プローブ要求フレームに対する応答として、ＡＰ情報（具体的には、インフラストラクチャーＢＳＳ属性情報）を含むプローブ応答フレームをＷＦＤソースに送信することもでき、サービス探索要求フレームに対する応答として、ＡＰ情報（具体的には、インフラストラクチャーＢＳＳ属性情報）を含むサービス探索応答フレームをＷＦＤソースに送信することもできる。

図２５の例示のように、インフラストラクチャーＢＳＳ属性情報は、プローブ応答フレーム及びサービス探索応答フレームの両方に含まれてもよいが、プローブ応答フレーム及びサービス探索応答フレームのいずれか一方にのみ含まれてもよい。ただし、サービス探索手順が行われるか否かは、ＷＦＤデバイス能力に応じて選択的に決定されるため、サービス探索応答フレームよりはプローブ応答フレームにインフラストラクチャーＢＳＳ属性情報を含めることが好ましいだろう。

ＷＦＤソースは、プローブ応答フレーム（又は、サービス探索応答フレーム）に含まれたＡＰ情報に基づいて、ＷＦＤシンクが接続しているＡＰに接続することができる。これと同様に、ＷＦＤシンクは、プローブ要求フレーム（又は、サービス探索要求フレーム）に含まれたＡＰ情報に基づいて、ＷＦＤソースが接続しているＡＰに接続することができる。ＷＦＤソース及びＷＦＤシンクが同一のＡＰに接続すると、図１６乃至図１９で説明したとおり、ＡＰとの接続を用いてＷＦＤセッションを構築することができる。

プローブ要求フレーム及びプローブ応答フレーム（又は、サービス探索要求フレーム及びサービス探索応答フレーム）の交換の結果、ＷＦＤソース及びＷＦＤシンクが同一のＡＰに接続していると確認される場合にも、図１６乃至図１９で説明したとおり、ＡＰとの接続を用いてＷＦＤセッションを構築することができる。

なお、図１２乃至図２５では、Ｗｉ−Ｆｉダイレクトサービスのうち、ディスプレイサービス或いはＷｉ−Ｆｉディスプレイ（Ｍｉｒａｃａｓｔ）のみを対象にして説明したが、デバイス探索手順又はサービス探索手順においてＰ２ＰデバイスがＡＰ情報を送信又は受信する特徴は、ディスプレイサービス以外のサービス（例えば、プレイ、プリント、送信及びイネーブルサービスなど）にも適用可能であることはいうまでもない。

タスク単位の画像／音声ストリーミング
ＷＦＤセッションが構築されると、ＷＦＤソースは、自身の出力している音声及び画像データ（以下、ＡＶ（Ａｕｄｉｏ／Ｖｉｄｅｏ）データという。）を実時間でエンコーディングした後、ＷＦＤセッションを介してＷＦＤシンクに、エンコードされたデータをストリーミングすることができる。すなわち、ＷＦＤソースは、自身の出力している音声と画像全体をエンコーディングし、ＷＦＤシンクは、受信したストリームをデコーティングして全体画面として出力することによって、ディスプレイサービスを行うことができる。しかし、このように、ＷＦＤソースが自身の出力している画像全体をエンコーディングしたり、ＷＦＤシンクが、受信したストリームを全体画面として出力したりすると、ディスプレイサービス中にＷＦＤソース及びＷＦＤシンクで他のタスク（ｔａｓｋ）が処理し難いという問題点がある。

そこで、本発明では、ＷＦＤソースが、ディスプレイされている映像全体ではなくタスク（ｔａｓｋ）単位でＡＶデータをエンコーディングしてストリーミングする方法を提案する。

一例として、図２６は、ＷＦＤソースがマルチタスクを実行しているとき、タスク別のエンコーディングデータが異なったＷＦＤシンクにストリーミングされる例を示す図である。図２６の例示のように、ＷＦＤソースがマルチタスクを実行している間に、第１のＷＦＤシンク及び第２のＷＦＤシンクとＷＦＤセッションを構築した場合には、ＷＦＤソースは、実行中の複数のタスクのいずれか一つのＡＶデータに対応するエンコーディングデータを第１のＷＦＤシンクにストリーミングし、他のＡＶデータに対応するエンコーディングデータを第２のＷＦＤシンクにストリーミングすることができる。一例として、図２６の例示のように、第１のＷＦＤシンクがＴＶであり、第２のＷＦＤシンクがラップトップであれば、ＷＦＤソースはＴＶに、第１のタスクのＡＶデータをエンコーディングした第１のデータをストリーミングし、ラップトップに、第２のタスクのＡＶデータをエンコーディングした第２のデータをストリーミングすることができる。

第１のデータ及び第２のデータはＷＦＤソースによってディスプレイされている画像や出力される音声ではなくタスク別のＲＡＷ画像及び音声をエンコーディング対象にして生成されたものであるため、ＷＦＤソースが第１のタスク及び第２のタスクをディスプレイするとき、図２６に示す例のように、第２のタスクの一部が第１のタスクによって隠されていても、第２の画像は第２のタスクを正常に表現することができる。これと同様に、ＷＦＤソース上で第１のタスクが活性化状態にあり、第２のタスクが非活性化状態にあり、第２のタスクが半透明表示されている状態であっても、第２の画像は第２のタスクを正常に表現することができる。

なお、ＷＦＤソースが第１のタスクの音声及び第２のタスクの音声を同時に出力する場合であっても、第１のＷＦＤシンクは第１のタスクの音声のみをストリーミングし、第２のＷＦＤシンクは第２のタスクの音声のみをストリーミングすることができる。

第１のデータを第１のＷＦＤシンクにストリーミングし、第２のデータを第２のＷＦＤシンクにストリーミングするために、ＷＦＤソースは、第１のＷＦＤシンク及び第２のＷＦＤシンクと個別にＷＦＤセッションを構築しなければならない。ただし、ＷＦＤセッション別にタスクの特性（例えば、動画解像度、オーディオ又はビデオコーデックなど）は独立していてもよい。

複数のタスクのうちのいずれをＷＦＤシンクデバイスにストリーミングするかは、ユーザ入力によって選択されてもよく、既に設定された値によって自動で選択されてもよい。

他の例として、図２７は、ＷＦＤソースがマルチタスクを実行しているとき、タスク別にエンコードされた複数のデータが単一のＷＦＤシンクにストリーミングされる例を示す図である。ＷＦＤソースが複数のタスクを実行している間にＷＦＤシンクとＷＦＤセッションが構築されると、ＷＦＤソースは、実行中の複数のタスクの一部に対してエンコーディングを行った後、エンコードされたデータを別個のストリームとしてＷＦＤシンクに送信することができる。一例として、図２７に示すように、第１のタスク及び第２のタスクに対して２個のエンコーディングデータが生成された場合には、ＷＦＤソースは２個のエンコーディングデータを別々のストリームとしてＷＦＤシンクに送信することができる。

２個のエンコーディングデータを受信したＷＦＤシンクは、ユーザの好み又は既に設定された値によって適切に２個のデータを配置してディスプレイすることができる。一例として、ＷＦＤソースでは第１のタスクを背景にして第２のタスクがディスプレイされている状態であるとしでも、ＷＦＤシンクは、第１のタスクを対象にした第１の画像及び第２のタスクを対象にした第２の画像を別個のストリームとして受信するので、ＷＦＤソースとは異なるように第１のタスク及び第２のタスクを配置することもできる。図２７では、ＷＦＤソースは第１のタスクを背景にして第２のタスクをディスプレイしているが、ＷＦＤシンクは第２のタスクを背景にして第１のタスクをディスプレイしている。

ＷＦＤソースは、バックグラウンド状態として実行されているタスクをＷＦＤシンクにストリーミングすることもできる。一例として、図２８は、ＷＦＤソースがフォアグラウンド状態であるタスクとバックグラウンド状態であるタスクを別々のＷＦＤシンクにストリーミングする例を示している。説明の便宜のために、ＷＦＤソースは、図２８の例示のように、文書作成プログラムをフォアグラウンド状態として実行し、動画再生プログラムをバックグラウンド状態として実行していると仮定する。この場合、ＷＦＤソースは、フォアグラウンド状態として実行中の文書作成プログラムを対象にしてエンコードされた第１のデータ、及びバックグラウンド状態として実行中の動画再生プログラムを対象にしてエンコードされた第２のデータを、それぞれ、第１のＷＦＤシンク及び第２のＷＦＤシンクにストリーミングすることができる。

これによって、現在ＷＦＤソースが第２のタスクに対する画像（及び音声）を出力していなくても、ＷＦＤシンクは第２のタスクに対する画像（及び音声）を出力可能になる。

ＷＦＤソースは、ウィンドウ単位でＡＶデータをエンコーディングし、ＷＦＤシンクにストリーミングすることもできる。

一例として、図２９は、ＷＦＤソースが複数のウィンドウをディスプレイしているときに、ウィンドウ別エンコーディングデータが異なったＷＦＤシンクにストリーミングされる例を示す図である。図２９の例示のように、ＷＦＤソースが複数のウィンドウをディスプレイしている間に、第１のＷＦＤシンク及び第２のＷＦＤシンクとＷＦＤセッションを構築した場合には、ＷＦＤソースは、ディスプレイされている複数のウィンドウのうちいずれか一つのＡＶデータに対するエンコーディングデータを第１のＷＦＤシンクにストリーミングし、いずれか他のＡＶデータに対するエンコーディングデータを第２のＷＦＤシンクにストリーミングすることができる。

一例として、図２９の例示のように、第１のＷＦＤシンクがＴＶであり、第２のＷＦＤシンクがプロジェクターであれば、ＷＦＤソースはＴＶに、第１のウィンドウのＡＶデータをエンコーディングした第１のデータをストリーミングし、プロジェクターに、第２のウィンドウのＡＶデータをエンコーディングした第２のデータをストリーミングすることができる。

ＷＦＤソースが実行しているタスクが音声再生と関連したものであれば、ＷＦＤソースは音声機器タイプのＷＦＤシンクに、当該タスクに対するエンコーディングデータをストリーミングし、実行しているタスクが画像の表示が必要なものであれば、ＷＦＤソースは画像機器タイプのＷＦＤシンクに、当該タスクに対するエンコーディングデータをストリーミングすることができる。

一例として、図３０は、タスクの属性によってデータがストリーミングされる例を示す図である。説明の便宜のために、ＷＦＤソースは、動画再生プログラム及び音声再生プログラムを実行中であり、ＷＦＤソースは、ＴＶ及びオーディオとＷＦＤセッションを生成した状態であると仮定する。

この場合、ＷＦＤソースは、動画再生プログラムのＡＶデータをエンコーディングしたデータはＴＶにストリーミングし、音声再生プログラムの音声データをエンコーディングしたデータはオーディオにストリーミングすることができる。

ＷＦＤソースに写真が保存されていると、ＷＦＤソースは、保存された写真をスライドショーとして構成した画像をエンコーディングしたデータがＷＦＤシンクに送信されるように制御することができる。なお、ＷＦＤシンクは、スライドショーの再生時に再生するように設定されたバックグラウンドミュージックもＷＦＤシンクにストリーミングすることができる。

一例として、図３１は、ＷＦＤソースに保存された写真のスライドショーをエンコーディングしたデータがＷＦＤシンクにストリーミングされる例を説明するための図である。ＷＦＤソースに写真が保存されていると、ＷＦＤソースは、保存されている写真がスライドショーとしてディスプレイされていなくても、保存されている写真をスライドショーとして構成した時に予想される画像をエンコーディングすることができる。なお、スライドショーの再生時に再生されるように設定されたバックグラウンドミュージックが存在すると、ＷＦＤソースは、バックグラウンドミュージックをエンコーディングしたデータを生成することができる。

ＷＦＤソースは、エンコーディングしたデータをＷＦＤシンクにストリーミングすることができる。この時、エンコードされた画像及び音声は、同じＷＦＤシンク（例えば、ＴＶ）に送信されてもよく、エンコードされた画像は第１のＷＦＤシンク（例えば、ＴＶ）に、エンコードされた音声は第２のＷＦＤシンク（例えば、オーディオ）に送信されてもよい。

ＷＦＤソースがマルチディスプレイ環境で動作する場合には、ＷＦＤソースは、ディスプレイ別エンコーディングデータを異なったＷＦＤシンクにストリーミングすることもできる。

一例として、図３２は、ＷＦＤソースがマルチディスプレイ環境で動作しているとき、ディスプレイ別エンコーディングデータが別々のＷＦＤシンクにストリーミングされる例を示す図である。図３２の例示のように、ＷＦＤソースは、ラップトップであり、自身のディスプレイ及びモニタを用いたマルチディスプレイ環境を構築した状態であると仮定する。

この場合、ＷＦＤソースは、自身のディスプレイ部から出力される画像をエンコーディングした第１のデータは第１のＷＦＤシンクに送信し、追加のモニタから出力される画像をエンコーディングした第２のデータは第２のＷＦＤシンクに送信することができる。

第１のＷＦＤシンクがＴＶであり、第２のＷＦＤシンクがプロジェクターであれば、第１のデータを受信したＴＶは、ラップトップのディスプレイ部と同じ画面を出力することができ、第２のデータを受信したプロジェクターは、ラップトップに接続されたモニタと同じ画面を出力することができる。

ＷＦＤソースからデータを受信したＷＦＤシンクは、受信したデータをデコーティングして出力することができる。この時、ＷＦＤシンクは、ＷＦＤソースから受信したデータを画面全体に出力する代わりに、自身が実行している既存タスクと共に、受信したデータを出力することもできる。

一例として、図３３は、ＷＦＤシンクが、自身が実行しているタスクと共に、受信したデータを出力する例を示す図である。ＷＦＤシンクは、ＷＦＤシンクから受信したデータ（すなわち、ＷＦＤストリーム）を、自身が実行していた既存タスク（例えば、アプリケーション又は放送など）と共に出力することができる。このとき、ＷＦＤシンクは、受信したデータが自身の実行していた既存タスクを隠すことを防止するために、受信したデータを半透明にディスプレイすることもできる。なお、ＷＦＤシンクは、受信したデータの透明度を調節するための透明度調節バーなどがディスプレイされるように制御してもよい。

さらに、ＷＦＤシンクは、受信したデータを全体画面にディスプレイするか否かを調節するためのボタン、受信したデータを最小化するか否かを調節するためのボタン、受信したデータを終了するか否かを決定するためのボタンなどをディスプレイしてもよい。受信したデータがディスプレイされる位置及び大きさは、ユーザ入力によって変化してもよいことはいうまでもない。

ＷＦＤシンク自身が行っていたタスクが音声出力であれば、ＷＦＤシンクは、図３３の例示のように、ＷＦＤソースからビデオだけを受信して出力することもできる。これと違い、ＷＦＤシンクは、自身が行っていたタスクの音声出力を中止し、ＷＦＤソースからビデオ及びオーディオを受信して出力することもできる。

１つのＷＦＤシンクが複数のディスプレイ装置と物理的又は論理的に接続されていてもよい。例えば、図３２に例示したとおり、マルチディスプレイ環境で動作しているコンピュータがＷＦＤシンクとして動作する場合は、ＷＦＤシンクが物理的に複数のディスプレイ装置に接続されている場合と仮定することができ、車両のシートに取り付けられたヘッドユニット及びセンターフェイシアディスプレイを制御するための制御装置がＷＦＤシンクとして動作すると、ＷＦＤシンクが複数のディスプレイ装置（すなわち、ヘッドユニット及びセンターフェイシアディスプレイ）と物理的に接続されている場合と仮定することができる。

このように、ＷＦＤシンクが複数のディスプレイ装置と接続されている状態では、ＷＦＤソースは、ＷＦＤシンクが接続されている複数のディスプレイ装置別に異なるデータがストリーミングされるように制御してもよい。一例として、図３４及び図３５は、ＷＦＤソースが、ＷＦＤシンクのディスプレイ別に異なるデータがストリーミングされるように制御する例を示す図である。図３４の例示では、ＷＦＤシンクの第１のディスプレイ部にはＷＦＤソースの第１のタスクがストリーミングされており、第２のディスプレイ部にはＷＦＤソースの第２のタスクがストリーミングされており、第３ディスプレイ部にはＷＦＤソースの第３タスクがストリーミングされている。

そのために、ＷＦＤソース及びＷＦＤシンクは複数個のＷＦＤセッションを生成しなければならず、ＷＦＤソース及びＷＦＤシンクの少なくとも一つがデータ別にストリーミングするディスプレイを指定しなければならない。なお、ＷＦＤソースは、ＷＦＤ機器探索／サービス探索手順又はＷＦＤ能力交渉手順において、ＷＦＤシンクと接続されているディスプレイ装置の個数を取得することができる。

ＷＦＤシンクが複数のＷＦＤソースとＷＦＤセッションを構築した場合には、ディスプレイ別に異なるＷＦＤソースのＡＶデータが出力されるように制御することができる。一例として、図３５では、ＷＦＤシンクの第１のディスプレイ部には第１のＷＦＤソースのＡＶデータがストリーミングされており、第２のディスプレイ部には第２のＷＦＤソースのＡＶデータがストリーミングされており、第３のディスプレイ部には第３のＷＦＤソースのＡＶデータがストリーミングされている。

図３６は、本発明の一実施例に係る無線デバイスの構成を示すブロック図である。

無線デバイス１０は、プロセッサ１１、メモリ１２、送受信器１３を備えることができる。送受信器１３は、無線信号を送信／受信することができ、例えば、ＩＥＥＥ ８０２システムに基づく物理層を実現することができる。プロセッサ１１は、送受信器１３と電気的に接続されて、ＩＥＥＥ ８０２システムに基づく物理層及び／又はＭＡＣ層を実現することができる。また、プロセッサ１１は、ＷＦＤサービスのためのオーディオ／ビデオのエンコーディング及びデコーディングの動作を行うように構成されてもよい。また、前述した本発明の様々な実施例に係る無線デバイスの動作を実現するモジュールがメモリ１２に格納され、プロセッサ１１によって実行されてもよい。メモリ１２は、プロセッサ１１の内部に含まれたり、又はプロセッサ１１の外部に設けられて、プロセッサ１１と公知の手段によって接続されたりしてもよい。図示してはいないが、無線デバイス１０は、画像及び音声を出力するためのディスプレイ部及び音声出力部をさらに備えることができる。

図３６の無線デバイス１０の具体的な構成は、前述した本発明の様々な実施例で説明した事項が独立して適用されたり、又は２つ以上の実施例が同時に適用されたりするように実現されてもよく、重複する内容は明確性のために説明を省略する。

上述した本発明の実施例は、様々な手段によって実現することができる。例えば、本発明の実施例は、ハードウェア、ファームウェア（ｆｉｒｍｗａｒｅ）、ソフトウェア又はそれらの結合などによって実現することができる。

ハードウェアによる実現の場合、本発明の実施例に係る方法は、１つ又はそれ以上のＡＳＩＣｓ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔｓ）、ＤＳＰｓ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｏｒｓ）、ＤＳＰＤｓ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｄｅｖｉｃｅｓ）、ＰＬＤｓ（Ｐｒｏｇｒａｍｍａｂｌｅ Ｌｏｇｉｃ Ｄｅｖｉｃｅｓ）、ＦＰＧＡｓ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙｓ）、プロセッサ、コントローラ、マイクロコントローラ、マイクロプロセッサなどによって実現することができる。

ファームウェアやソフトウェアによる実現の場合、本発明の実施例に係る方法は、以上で説明された機能又は動作を実行するモジュール、手順又は関数などの形態として実現することができる。ソフトウェアコードはメモリユニットに格納され、プロセッサによって駆動されてもよい。メモリユニットは、プロセッサの内部又は外部に設けられ、既に公知である様々な手段によってプロセッサとデータを交換することができる。

以上開示された本発明の好適な実施の形態に関する詳細な説明は、当業者が本発明を実現して実施できるように提供された。以上では本発明の好適な実施の形態を参照して説明したが、当該技術分野における熟練した当業者にとって、添付した特許請求の範囲に記載された本発明の思想及び領域から逸脱しない範囲内で本発明を様々に修正及び変更可能であることは明らかである。したがって、本発明は、ここに開示された実施の形態に制限しようとするものではなく、ここに開示された原理及び新規な特徴と一致する最も広い範囲を与えようとするものである。

上述した本発明の様々な実施の形態については、ＩＥＥＥ ８０２．１１システムを中心に説明したが、様々な移動通信システムに同様に適用可能である。

Claims (12)

1. Ｗｉ−Ｆｉダイレクトサービスをサポートする第１の無線デバイスでデバイス探索を行う方法であって、
   プローブ要求フレームを送信するステップと、
   前記プローブ要求フレームに対する応答として、第２の無線デバイスからプローブ応答フレームを受信するステップであって、前記プローブ応答フレームは、前記第２の無線デバイスが現在接続しているＡＰ（Ａｃｃｅｓｓ Ｐｏｉｎｔ）の情報を含む、ステップと、
   前記第１の無線デバイスに接続されたＡＰと前記第２の無線デバイスに接続されたＡＰとが同一の場合に、前記ＡＰの情報に基づいて選択された既存のインフラストラクチャー接続上で、前記第２の無線デバイスとセッションを構築するステップであって、前記構築されたセッションは、Ｐ２Ｐ（Ｐｅｅｒ ｔｏ Ｐｅｅｒ）接続上に構築されたセッション及びＴＤＬＳ（Ｔｕｎｎｅｌｅｄ Ｄｉｒｅｃｔ Ｌｉｎｋ Ｓｅｔｕｐ）ダイレクトリンク上に構築されたセッションとは異なる、ステップと、
   を有する、方法。
2. 前記ＡＰの情報は、
   前記第２の無線デバイスに接続された前記ＡＰの識別に関する情報、
   前記第２の無線デバイスに接続された前記ＡＰが動作する周波数帯域、
   前記第２の無線デバイスに接続された前記ＡＰが動作するチャネル、及び、
   前記第２の無線デバイスのＩＰアドレス、を含む、請求項１に記載の方法。
3. 前記プローブ要求フレームは、前記第１の無線デバイスが現在接続しているＡＰの情報を含む、請求項１に記載の方法。
4. 前記プローブ応答フレームは、ＷＦＤ（Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙ）情報要素及びＰ２Ｐ情報要素を含み、
   前記ＡＰの情報は、前記ＷＦＤ情報要素及び前記Ｐ２Ｐ情報要素のうち少なくとも一つの副要素として前記プローブ応答フレームに含まれる、請求項１に記載の方法。
5. 前記第１の無線デバイス及び前記第２の無線デバイスがサービス探索手順を行う能力を有する場合、
   前記第２の無線デバイスにサービス探索要求フレームを送信するステップと、
   前記サービス探索要求フレームに対する応答として、前記第２の無線デバイスからサービス探索応答フレームを受信するステップと、をさらに有する、請求項１に記載の方法。
6. 前記サービス探索要求フレームは、前記第１の無線デバイスが現在接続しているＡＰの情報を含み、
   前記サービス探索応答フレームは、前記第２の無線デバイスが現在接続しているＡＰの情報を含む、請求項５に記載の方法。
7. Ｗｉ−Ｆｉダイレクトサービスをサポートする第１の無線デバイスがデバイス探索に応答する方法であって、
   第２の無線デバイスからプローブ要求フレームを受信するステップと、
   前記プローブ要求フレームに対する応答として、前記第２の無線デバイスからプローブ応答フレームを送信するステップであって、前記プローブ応答フレームは、前記第１の無線デバイスが現在接続しているＡＰ（ＡｃｃｅｓｓＰｏｉｎｔ）の情報を含む、ステップと、
   前記第１の無線デバイスに接続されたＡＰと前記第２の無線デバイスに接続されたＡＰとが同一の場合に、前記ＡＰの情報に基づいて選択された既存のインフラストラクチャー接続上で、前記第２の無線デバイスとセッションを構築するステップであって、前記構築されたセッションは、Ｐ２Ｐ（Ｐｅｅｒ ｔｏ Ｐｅｅｒ）接続上に構築されたセッション及びＴＤＬＳ（Ｔｕｎｎｅｌｅｄ Ｄｉｒｅｃｔ Ｌｉｎｋ Ｓｅｔｕｐ）ダイレクトリンク上に構築されたセッションとは異なる、ステップと、
   を有する方法。
8. デバイス探索を行い、かつＷｉ−Ｆｉダイレクトサービスをサポートする第１の無線デバイスであって、
   送受信器と、
   プロセッサと、
   を備え、
   前記プロセッサは、
   プローブ要求フレームを第２の無線デバイスに送信するように前記送受信器を制御し、
   前記プローブ要求フレームに対する応答として、第２の無線デバイスからプローブ応答フレームを受信するように前記送受信器を制御し、前記プローブ応答フレームは、前記第２の無線デバイスが現在接続しているＡＰ（Ａｃｃｅｓｓ Ｐｏｉｎｔ）の情報を含み、
   前記第１の無線デバイスに接続されたＡＰと前記第２の無線デバイスに接続されたＡＰとが同一の場合に、前記ＡＰの情報に基づいて選択された既存のインフラストラクチャー接続上で、前記第２の無線デバイスとセッションを構築し、前記構築されたセッションは、Ｐ２Ｐ（Ｐｅｅｒ ｔｏ Ｐｅｅｒ）接続上に構築されたセッション及びＴＤＬＳ（Ｔｕｎｎｅｌｅｄ Ｄｉｒｅｃｔ Ｌｉｎｋ Ｓｅｔｕｐ）ダイレクトリンク上に構築されたセッションとは異なる、
   ように構成される、第１の無線デバイス。
9. デバイス探索に応答し、かつＷｉ−Ｆｉダイレクトサービスをサポートする第１の無線デバイスであって、
   送受信器と、
   プロセッサと、
   を備え、
   前記プロセッサは、
   第２の無線デバイスからプローブ要求フレームを受信するように前記送受信器を制御し、
   前記第１の無線デバイスが現在接続しているＡＰ（Ａｃｃｅｓｓ Ｐｏｉｎｔ）の情報を含むプローブ応答フレームを、前記第２の無線デバイスに送信するように前記送受信器を制御し、
   前記第１の無線デバイスに接続されたＡＰと前記第２の無線デバイスに接続されたＡＰとが同一の場合に、前記ＡＰの情報に基づいて選択された既存のインフラストラクチャー接続上で、前記第２の無線デバイスとセッションを構築し、前記構築されたセッションは、Ｐ２Ｐ（Ｐｅｅｒ ｔｏ Ｐｅｅｒ）接続上に構築されたセッション及びＴＤＬＳ（Ｔｕｎｎｅｌｅｄ Ｄｉｒｅｃｔ Ｌｉｎｋ Ｓｅｔｕｐ）ダイレクトリンク上に構築されたセッションとは異なる、
   ように構成される、第１の無線デバイス。
10. 探索要求フレームを送信するステップと、
    前記探索要求フレームに対する応答として、前記第２の無線デバイスから探索応答フレームを受信するステップと、を有し、
    前記探索応答フレームは、前記第２の無線デバイスが現在接続しているＡＰの情報を含む、請求項１に記載の方法。
11. 前記第２の無線デバイスが現在接続している前記ＡＰの情報は、前記プローブ応答フレーム及び前記探索応答フレームのうち一つに含まれる、請求項１０に記載の方法。
12. 前記第１の無線デバイス及び前記第２の無線デバイスは、前記接続されたＡＰを用いてサービスの探索を行う、請求項１に記載の方法。

Images