JP6377624B2 - 直接通信システムにおいてサービス探索又は広告方法及びそのための装置 - Google Patents

Description

以下の説明は、無線通信システムに係り、より具体的には、直接通信システムにおいてサービスを探索又は広告する方法及び装置に関する。

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

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

近年、様々なＷｉ−Ｆｉ支援デバイスが用いられ、その中でも、ＡＰなしにＷｉ−Ｆｉデバイス間通信が可能なＷｉ−Ｆｉ Ｄｉｒｅｃｔ支援デバイスの数が増加している。ＷＦＡ（Ｗｉ−Ｆｉ Ａｌｌｉａｎｃｅ）では、Ｗｉ−Ｆｉ Ｄｉｒｅｃｔリンクを用いた様々なサービス（例えば、伝送（Ｓｅｎｄ）、プレー（Ｐｌａｙ）、ディスプレイ（Ｄｉｓｐｌａｙ）、プリント（Ｐｒｉｎｔ）など）を支援するプラットフォームを導入する技術が議論されている。これをＷｉ−Ｆｉダイレクトサービス（ＷＦＤＳ）と呼ぶことができる。ＷＦＤＳによれば、アプリケーション、サービスなどは、ＡＳＰ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｉｃｅ Ｐｌａｔｆｏｒｍ）というサービスプラットフォームによって制御又は管理され得る。

本発明は、ＷＦＤＳシステムにおいてサービスを探索又は広告する方法を提供することを目的とする。具体的に、本発明では、サービス探索又は広告のためのＷＦＤＳデバイスのＡＳＰ制御方案または管理方案を提供することを目的とする。

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

上記技術的課題を解決するために、本発明の一実施例に係る第１無線デバイスにおいてサービス探索を行う方法は、前記第１無線デバイスが望む所定のサービスを支援するデバイスを探索するために、プローブ要求フレームを伝送するステップと、前記所定のサービスを支援する第２無線デバイスからプローブ応答フレームを受信するステップと、前記第１無線デバイスが前記第２無線デバイスに、前記所定のサービスに対する第１サービス名を含むサービス探索要求フレームを伝送するステップと、前記第２無線デバイスからサービス探索応答フレームを受信するステップとを含むことができる。

上記技術的課題を解決するために、本発明の他の実施例に係る第１無線デバイスにおいてサービス広告を行う方法は、第２無線デバイスから、前記第２無線デバイスが望む所定のサービスを支援するか否かを問い合わせるプローブ要求フレームを受信するステップと、前記所定のサービスを支援する場合、前記第２無線デバイスにプローブ応答フレームを伝送するステップと、前記第２無線デバイスから、前記所定のサービスに対する第１サービス名を含むサービス探索要求フレームを受信するステップと、前記第２無線デバイスにサービス探索応答フレームを伝送するステップとを含むことができる。

上記技術的課題を解決するために、本発明の更に他の実施例に係るサービス探索を行う第１無線デバイスは、送受信器及びプロセッサを含み、

前記プロセッサは、前記第１無線デバイスが望む所定のサービスを支援するデバイスを探索するためのプローブ要求フレームを伝送するように前記送受信器を制御し、前記送受信器が、前記所定のサービスを支援する第２無線デバイスからプローブ応答フレームを受信すると、前記プロセッサは、前記第２無線デバイスに前記所定のサービスに対する第１サービス名を含むサービス探索要求フレームを伝送し、前記サービス探索要求フレームに対する応答として、前記第２無線デバイスからサービス探索応答フレームを受信するように前記送受信器を制御するように設定することができる。

上記技術的課題を解決するために、本発明の更に他の実施例に係るサービス広告を行う第１無線デバイスは、送受信器及びプロセッサを含み、前記送受信器が、第２無線デバイスから、前記第２無線デバイスが望む所定のサービスを支援するか否かを問い合わせるプローブ要求フレームを受信すると、前記プロセッサは、前記第１無線デバイスが前記所定のサービスを支援すれば、前記プローブ要求フレームに対する応答としてプローブ応答フレームが伝送されるように前記送受信器を制御し、前記送受信器が、前記第２無線デバイスから、前記所定のサービスに対する第１サービス名を含むサービス探索要求フレームを受信すると、前記プロセッサは、前記第２無線デバイスにサービス探索応答フレームが伝送されるように前記送受信器を制御することができる。

上記本発明に係る実施例において、前記サービス探索応答フレームは、前記第１無線デバイスまたは第２無線デバイスにおいて前記所定のサービスが利用可能であるか否かを指示するサービス状態情報を含むという技術的特徴を共通的に適用することができる。

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

本発明によれば、ＷＦＤＳシステムにおいてサービスを探索又は広告する方法及び装置を提供することができる。具体的に、本発明では、サービス探索又は広告のためのＷＦＤＳデバイスのＡＳＰ制御方案または管理方案を提供することができる。

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

本発明を適用できるＩＥＥＥ ８０２．１１システムの例示的な構造を示す図である。 ＷＦＤ（Ｗｉ−Ｆｉ Ｄｉｒｅｃｔ）ネットワークを例示する図である。 ＷＦＤネットワークを構成する過程を説明するための図である。 近隣発見過程を説明するための図である。 ＷＦＤネットワークの新しい様相を説明するための図である。 ＷＦＤ通信のためのリンクを設定する方法を説明するための図である。 ＷＦＤを行っている通信グループに参加（ａｓｓｏｃｉａｔｉｏｎ）する方法を説明するための図である。 ＷＦＤ通信のためのリンクを設定する方法を説明するための図である。 ＷＦＤ通信グループに参加するリンクを設定する方法を説明するための図である。 ＷＦＤＳフレームワーク構成要素を説明するための図である。 ＷＦＤＳの動作を説明するための図である。 ＡＳＰとサービスとの間のメソッド及びイベントの伝送例を示す図である。 サービス探索及びＡＳＰセッションセットアップ動作の流れ図である。 Ｗｉ−Ｆｉダイレクトファイル伝送サービスのアーキテクチャーを示す図である。 伝送トランスミッタと伝送レシーバとの間の動作を層別に簡略に図式化した図である。 ＦＴＳでのＬ２接続が確立される過程を説明するための図である。 Ｌ２接続及びＬ３接続を含むＦＴＳセッションの流れ図である。 それぞれサービス探索要求フレーム及びサービス探索応答フレームのフォーマットを例示した図である。 それぞれサービス探索要求フレーム及びサービス探索応答フレームのフォーマットを例示した図である。 本発明の一実施例に係る無線デバイスの構成を示すブロック図である。

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

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

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

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

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

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

ＷＬＡＮシステムの構造

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

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

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

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

層構造

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

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

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

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

無線ＬＡＮの進化

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

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

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

Ｗｉ−Ｆｉダイレクトネットワーク

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

デバイス間の直接接続を支援する技術として、Ｗｉ−Ｆｉダイレクト（Ｗｉ−Ｆｉ Ｄｉｒｅｃｔ）標準の制定が議論されている。

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

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

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

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

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

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

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

図５は、ＷＦＤネットワークの新しい様相を説明するための図である。

図５の例示は、新規Ｐ２Ｐ応用（例えば、ソーシャルチャット、位置−基盤のサービス提供、ゲーム連動など）が適用される場合のＷＦＤネットワークの様相として理解することができる。

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

図６は、ＷＦＤ通信のためのリンクを設定する方法を説明するための図である。

図６（ａ）に示すように、第１のＳＴＡ（６１０、以下、Ａという）は、既存のＷＦＤ通信においてグループオーナー（Ｇｒｏｕｐ Ｏｗｎｅｒ）として動作中にある。既存のＷＦＤ通信のグループクライアント６３０との通信中に、Ａ６１０が、新しいＷＦＤ通信対象である、ＷＦＤ通信をしていない、第２のＳＴＡ（６２０、以下、Ｂという）を発見した場合、Ａ６１０は、Ｂ６２０とのリンク設定を試みる。この場合、新しいＷＦＤ通信は、Ａ６１０とＢ６２０との間のＷＦＤ通信であり、Ａはグループオーナーであるので、既存のグループクライアント６３０の通信と別個に通信設定を進行することができる。１つのＷＦＤグループは、１つのグループオーナーと１つ以上のグループクライアントで構成することができるので、１つのグループオーナーであるＡ６１０を満足するので、図６（ｂ）に示すように、ＷＦＤリンクを設定することができる。この場合、Ａ６１０が既存のＷＦＤ通信グループにＢ６２０を招待（ｉｎｖｉｔａｔｉｏｎ）した場合であり、ＷＦＤ通信の特性上、Ａ６１０とＢ６２０との間、Ａ６１０と既存のグループクライアント６３０との間のＷＦＤ通信はそれぞれ可能であるが、Ｂ６２０と既存のグループクライアント６３０との間のＷＦＤ通信は支援されない。両方ともグループクライアントであるからである。

図７は、ＷＦＤを行っている通信グループに参加（ａｓｓｏｃｉａｔｉｏｎ）する方法を説明するための図である。

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

図８は、ＷＦＤ通信のためのリンクを設定する方法を説明するための図である。

図８（ａ）に示すように、第２のＳＴＡ（８２０、以下、Ｂという）は、既存のＷＦＤ通信においてグループオーナー（Ｇｒｏｕｐ Ｏｗｎｅｒ）として動作中にある。既存のＷＦＤ通信においてグループクライアント８３０とＷＦＤ通信中にある場合、Ｂ８２０を発見した、ＷＦＤ通信を行っていない第１のＳＴＡ（８１０、以下、Ａという）が、Ｂ８２０との新しいＷＦＤ通信のためにリンク設定を試みる。この場合、Ｂ８２０がリンク設定を受諾した場合、Ａ８１０とＢ８２０との間の新しいＷＦＤ通信リンクが設定され、Ａ８１０は、既存のＢ８２０のＷＦＤグループのクライアントとして動作することになる。このような場合、Ａ８１０がＢ８２０のＷＦＤ通信グループに参加（ａｓｓｏｃｉａｔｉｏｎ）した場合となる。Ａ８１０は、グループオーナーであるＢ８２０とのみＷＦＤ通信を行うことができ、Ａ８１０と既存のＷＦＤ通信のクライアント８３０とのＷＦＤ通信は支援されない。両方ともグループクライアントであるからである。

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

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

Ｗｉ−Ｆｉダイレクトサービス（ＷＦＤＳ）

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

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

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

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

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

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

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

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

図１１は、ＷＦＤＳの動作を説明するための図である。

図１１では、２つのピア（ｐｅｅｒ）デバイスＡ及びＢが存在するものと仮定する。

ＡＳＰは、サービスが必要とする共通の機能を具現する論理的な個体（ｌｏｇｉｃａｌ ｅｎｔｉｔｙ）である。このような機能は、デバイス発見（Ｄｅｖｉｃｅ Ｄｉｓｃｏｖｅｒｙ）、サービス発見（Ｓｅｒｖｉｃｅ Ｄｉｓｃｏｖｅｒｙ）、ＡＳＰ−セッション管理、接続トポロジ（ｔｏｐｏｌｏｇｙ）管理、保安などを含むことができる。

ＡＳＰ−セッションは、デバイスＡのＡＳＰとデバイスＢのＡＳＰとの間の論理的なリンクである。ＡＳＰ−セッションを開始するために、ピアデバイス間のＰ２Ｐ（Ｐｅｅｒ−ｔｏ−Ｐｅｅｒ）接続が必要である。ＡＳＰは、２つのデバイス間に複数個のＡＳＰ−セッションをセットアップすることができる。それぞれのＡＳＰ−セッションは、ＡＳＰ−セッションを要求するＡＳＰによって割り当てられるセッション識別子によって識別されてもよい。

サービスは、他のサービス又はアプリケーションにＡＳＰを用いて用途特定機能を提供する論理的な個体である。１つのデバイスのサービスは、１つ以上の他のデバイスの対応するサービス、及びサービス−特定プロトコル（これは、サービス標準及びＡＳＰプロトコルによって定義できる）を用いて通信することができる。

ＡＳＰとサービスとの間のインターフェースは、メソッド（Ｍｅｔｈｏｄ）及びイベント（Ｅｖｅｎｔ）で定義される。Ｍｅｔｈｏｄは、サービスによって開始される動作を示し、Ｍｅｔｈｏｄのパラメータ（又はフィールド）には、実行しようとする動作に関する情報が含まれてもよい。Ｅｖｅｎｔは、ＡＳＰからサービスに情報を提供する。

一例として、図１２は、ＡＳＰとサービスとの間のメソッド及びイベントの伝送例を示す図である。

サービスがメソッド呼び出しを行うと、メソッド呼び出し返却値として制限された情報がサービスに返却される。全てのメソッド呼び出しは、直ちに返却されることが原則である。これによって、サービスに返却される値は、メソッド呼び出し返却の遅延を引き起こすネットワークを介して獲得された情報またはユーザから獲得された情報に依存してはならない。

ＡＳＰは、イベントを介してサービスに情報を提供する。メソッドのように、イベントもパラメータでデータを伝送する。イベントは一方向に伝送されるので、サービスがイベントのコンテンツに基づいてアクションを取ろうとする場合、メソッド呼び出しが後続しなければならない。

ＡＳＰと通信する複数のサービスは、メソッド及びイベントを使用することができる。メソッドは、サービスからＡＳＰに伝搬され、イベントは、ＡＳＰから特定サービスに伝搬され得る。イベントは、メソッド呼び出しに対して直ちに応答される必要はない。

再び図１１を参照すると、ユーザがデバイスＡとデバイスＢとの間にサービスＸを利用しようとする場合、それぞれのデバイス上のＡＳＰは、サービスＸ専用のＡＳＰ−セッションをデバイス間に生成する。その後、ユーザがサービスＹを利用しようとする場合、当該サービスのための新しいＡＳＰ−セッションが確立（ｅｓｔａｂｌｉｓｈ）される。ピア機器間に複数のＡＳＰセッションが確立された（ｅｓｔａｂｌｉｓｈｅｄ）場合、複数のＡＳＰセッションのそれぞれは、ＡＳＰセッションの確立を要求したピアデバイス（具体的には、ＡＳＰセッションの確立を要求したピアデバイスのＡＳＰ）によって割り当てられるセッション識別子（Ｓｅｓｓｉｏｎ Ｉｄｅｎｔｉｆｉｅｒ）により識別することができる。

ＷＦＤＳでは、２つのピアデバイス間の動作を定義するにおいて、それらのうち一方のデバイスはサービス広告器（ａｄｖｅｒｔｉｓｅｒ）の役割を担い、他方のデバイスはサービス探索器（ｓｅｅｋｅｒ）の役割を担うことができる。サービス探索器は、サービス広告器を発見（ｄｉｓｃｏｖｅｒ）し、所望のサービスを見つけた場合、サービス広告器との接続を要求することもできる。

サービス探索器として設定されたピア機器は、サービス広告器として設定されたピア機器を探索し、サービス広告器として設定されたピア機器から所望のサービスを発見すると、サービス広告器として設定されたピア機器に接続を要求することができる。具体的に、サービス探索器側がサービス広告器側にＡＳＰサービスセッション確立を要求すると、サービス広告器側は、サービス探索器側のＡＳＰセッション確立要求に応答することができる。

サービス広告器とサービス探索器との関係は固定されたものではない。一例として、サービス広告器及びサービス探索器としての役割は、いずれか１つのＡＳＰセッションと次のＡＳＰセッションにおいて互いに変わってもよい。ピア機器がサービス広告器として動作するか、サービス探索器として動作するかは、どのピア機器がサービスの探索（ｓｅａｒｃｈ）を開始したか否かに基づいて決定され得る。すなわち、サービスの探索を要求するピア機器がサービス探索器として機能することができる。

また、いずれか１つのピア機器が同じサービスに対して、サービス広告器及びサービス探索器として同時に設定されてもよく、いずれか１つのピア機器が複数のサービス広告器を有するか、または複数のサービス探索器を有してもよい。一例として、いずれか１つのピア機器は、第１のＷｉ−Ｆｉダイレクトサービス及び第２のＷｉ−Ｆｉダイレクトサービスのサービスに対してはサービス広告器として設定されると同時に、第３のＷｉ−Ｆｉダイレクトサービス及び第４のＷｉ−Ｆｉダイレクトサービスに対してはサービス探索器として設定されてもよい。

以下では、サービス広告器及びサービス探索器についてより詳細に説明する。

サービス広告器及びサービス探索器

サービス広告器として設定されたピア機器はサービスを広告し、サービス探索器は広告されたサービスを発見（ｄｉｓｃｏｖｅｒ）することができる。サービス広告器として設定されたピア機器は、サービス広告中断メソッド（ＣａｎｃｅｌＡｄｖｅｒｔｉｓｅＳｅｒｖｉｃｅ ｍｅｔｈｏｄ）がコール（ｃａｌｌ）されるか、または広告状態が中断として設定される前まで（例えば、ＡｄｖｅｒｔｉｓｅＳｔａｔｕｓパラメータのｓｔａｔｕｓ値がＮｏｔＡｄｖｅｒｔｉｓｅｄを指示）サービスを広告することができる。サービス広告器がサービスを広告するには、後連携（ｐｏｓｔ ａｓｓｏｃｉａｔｉｏｎ）及び早期連携（ｐｒｅ−ａｓｓｏｃｉａｔｉｏｎ）のうち少なくとも１つを利用することができる。

サービス広告器が広告するサービスは、サービス名で識別することができる。具体的に、ピア機器は、サービス探索の間、各サービスがＵＴＦ−８サービス名文字列を含むように制御することができる。ここで、ＵＴＦ−８でエンコーディングされたサービス名の長さは、２５５バイト又はそれ以下であってもよい。サービス名の長さは、サービス探索要求フレーム及びサービス探索応答フレームで利用可能な空間によって決定されてもよい。

“ｏｒｇ．ｗｉ−ｆｉ”という文字列は、ＷＦＡサービスを識別するために予約されたものであってもよい。具体的に、ＷＦＡサービス名は、次の通りである。

ｏｒｇ．ｗｉ−ｆｉ．ｗｆｄｓ．ｓｅｎｄ．ｔｘ

ｏｒｇ．ｗｉ−ｆｉ．ｗｆｄｓ．ｓｅｎｄ．ｒｘ

ｏｒｇ．ｗｉ−ｆｉ．ｗｆｄｓ．ｐｌａｙ．ｔｘ

ｏｒｇ．ｗｉ−ｆｉ．ｗｆｄｓ．ｐｌａｙ．ｒｘ

ｏｒｇ．ｗｉ−ｆｉ．ｗｆｄｓ．ｄｉｓｐｌａｙ．ｔｘ

ｏｒｇ．ｗｉ−ｆｉ．ｗｆｄｓ．ｄｉｓｐｌａｙ．ｒｘ

ｏｒｇ．ｗｉ−ｆｉ．ｗｆｄｓ．ｐｒｉｎｔ．ｔｘ

ｏｒｇ．ｗｉ−ｆｉ．ｗｆｄｓ．ｐｒｉｎｔ．ｒｘ

もし、イネーブルサービスがｏｒｇ．ｗｉ−ｆｉで始まるサービス名を用いて広告又は探索することを試みる（ａｔｔｅｍｐｔ）場合、ＡＳＰは、広告又は探索に対するイネーブルサービスの試み（ａｔｔｅｍｐｔ）を拒絶することができる。イネーブルサービスのためには、逆ドメイン名表記法（Ｒｅｓｅｒｖｅ ｄｏｍａｉｎ ｎａｍｅ ｎｏｔａｔｉｏｎ）を用いることができる。この表記法によれば、アプリケーション製作者（ａｕｔｈｏｒ）によって所有されたＤＮＳ名（例えば、ｅｘａｍｐｌｅ．ｃｏｍ）における各要素（例えば、ｅｘａｍｐｌｅ及びｃｏｍ）の順序を変えて配置したもの（例えば、ｃｏｍ．ｅｘａｍｐｌｅ）をイネーブルサービスのサービス名のプレフィックス（ｐｒｅｆｉｘ）として用いることができる。

これによって、イネーブルサービス名は、次の例のように定義することができる。

ｃｏｍ．ｅｘａｍｐｌｅ．ｓｅｒｖｉｃｅＸ

ｃｏｍ．ｅｘａｍｐｌｅ．ｐｒｏｄｕｃｔＹ

ｃｏｍ．ｅｘａｍｐｌｅ．０４ｃｆ７５ｄｂ−１９ｄ１−４ｄ８４−ｂｅｆ３−ｂ１３ｂ３３ｆｃｆａ５ａ

イネーブルサービスは、１つのアプリケーションのために定義されてもよく、様々なアプリケーションにおいて一般的に実行されるために定義されてもよい。

サービスは、サービス名で識別されると同時に、サービス情報で定義される。これによって、サービス名が同じサービスであるとしても、サービス情報が異なる場合、互いに異なるサービスであるものと取り扱いされ得る。

サービスを広告するにおいて、サービス広告器は、広告されるそれぞれのサービスに広告ＩＤ（ａｄｖｅｒｔｉｓｅｍｅｎｔ ＩＤ）を割り当てることができる。サービス広告器は、サービス別に、互いに異なる広告ＩＤが割り当てられるように制御することができる。

サービス広告（Ｓｅｒｖｉｃｅ Ａｄｖｅｒｔｉｓｅｍｅｎｔ）は後連携（ｐｏｓｔ ａｓｓｏｃｉａｔｉｏｎ）でも利用することができる。そのために、ピア機器は、Ｐ２Ｐグループが形成された（ｆｏｒｍｅｄ）後、追加的なＡＳＰセッションの確立を許容することができる。

サービス探索手順は、サービス探索器がＡＳＰセッションを開始するのに必ず必要なものではない。サービス探索器は、サービス探索手順のために、アウトオブバンド（ｏｕｔ ｏｆ ｂａｎｄ）メカニズムを許容することもできる。なお、サービス探索器は、ピアデバイスの既発見のサービスをキャッシング（ｃａｃｈｉｎｇ）することもできる。

サービス探索手順では、ワイルドカードサーチ（又はネームサーチ）を支援することができる。ワイルドカードサーチとは、プレフィックスサーチが支援されることを意味することができる。プレフィックスサーチは、プレフィックスを含む全てのサービスの検索が可能であることを意味することができる。一例として、全てのＷＦＡサービス（即ち、Ｓｅｎｄ、Ｐｌａｙ、Ｄｉｓｐｌａｙ、Ｐｒｉｎｔ）を探索するために、‘ｏｒｇ．ｗｉ−ｆｉ．ｗｆｄｓ．＊’（又は‘ｏｒｇ．ｗｉ−ｆｉ．ｗｆｄｓ＊）という検索語を含むワイルドカードサーチが許容可能である。この場合、ワイルドカード検索の結果として、‘ｏｒｇ．ｗｉ−ｆｉ．ｗｆｄｓ’というプレフィックスを含む全てのサービスリストが返却され得る。

特定のＷＦＡサービスを探索するためには、‘ｏｒｇ．ｗｉ−ｆｉ．ｗｆｄｓ．ｓｅｒｖｉｃｅｎａｍｅ．＊’（又は‘ｏｒｇ．ｗｉ−ｆｉ．ｗｆｄｓ．ｓｅｒｖｉｃｅｎａｍｅ＊’）（ここで、ｓｅｒｖｉｃｅｎａｍｅは、Ｓｅｎｄ、Ｐｌａｙ、Ｄｉｓｐｌａｙ、Ｐｒｉｎｔのいずれか１つであってもよい）という検索語を含むワイルドカードサーチが許容可能である。この場合、ワイルドカード検索の結果として、‘ｏｒｇ．ｗｉ−ｆｉ．ｗｆｄｓ．ｓｅｒｖｉｃｅｎａｍｅ’というプレフィックスを含む全てのサービスリストが返却され得る。イネーブルサービスの場合もワイルドカードが許容されてもよいことは勿論である。

ワイルドカードサーチは、ｄｏｔ（‘．’）で分離される単語に限って許容可能である。例えば、イネーブルサービス名が“ｃｏｍ．ｅｘａｍｐｌｅ．ｓｅｒｖｉｃｅＸ”であれば、‘ｃｏｍ．＊’（又は‘ｃｏｍ＊’）、‘ｃｏｍ．ｅｘａｍｐｌｅ．＊’（又は‘ｃｏｍ．ｅｘａｍｐｌｅ＊’）に限って、ワイルドカードサーチが許容可能である。

以下、サービス広告器及びサービス探索器で取り扱われるメソッド及びイベントについて詳細に説明する。

サービス広告器のメソッド

サービス広告器は、サービスの広告のためにサービス広告メソッド（Ａｄｖｅｒｔｉｓｅ Ｓｅｒｖｉｃｅ Ｍｅｔｈｏｄ）をコール（Ｃａｌｌ）することができる。これによって、サービス探索器は、広告されるサービスの検索、発見及びＡＳＰセッションを開始することができる。サービス広告メソッドには、サービス名パラメータ（又はサービス名のリストパラメータ）、ポートパラメータ、プロトコルパラメータ、共有パラメータ、自動受諾パラメータ及びサービス情報パラメータのうち少なくとも１つを含むことができる。各パラメータについての説明は、次の通りである。

ｉ）サービス名（又はサービス名のリスト）

サービス名は、サービス探索を要求する（例えば、ＳｅｅｋＳｅｒｖｉｃｅ Ｍｅｔｈｏｄコールを実行）サービス探索器によって検索が可能なサービスの特徴を識別する。サービス名とサービス探索器からの問い合わせ（ｑｕｅｒｙ）に含まれた文字列との対照を通じてサービス名マッチングを行うことができる。

マッチングされるサービスが複数個である場合、サービス広告メソッドには、複数個のサービス名を含むサービス名リストが含まれてもよい。一例として、サービスが同じポートで伝送及び受信を支援すれば、伝送のためのサービス名（例えば、ｓｅｒｖｉｃｅ．ｔｘ）及び受信のためのサービス名（ｓｅｒｖｉｃｅ．ｒｘ）の全てがサービス名リストに含まれてもよい。例えば、検索が要求されるサービス名がｏｒｇ．ｗｉ−ｆｉ．ｗｆｄｓ．ｓｅｎｄであり、サービスがｏｒｇ．ｗｉ−ｆｉ．ｗｆｄｓ．ｓｅｎｄ．ｒｘ及びｏｒｇ．ｗｉ−ｆｉ．ｗｆｄｓ．ｓｅｎｄ．ｔｘを全て支援すれば、サービス名リストには、“ｏｒｇ．ｗｉ−ｆｉ．ｗｆｄｓ．ｓｅｎｄ”、“ｏｒｇ．ｗｉ−ｆｉ．ｗｆｄｓ．ｓｅｎｄ．ｒｘ”及び“ｏｒｇ．ｗｉ−ｆｉ．ｗｆｄｓ．ｓｅｎｄ．ｔｘ”が全て含まれてもよい。

サービスが同じポートナンバーで全てのＷＦＡサービスを支援すれば、サービス名リストには、全てのＷＦＡサービス名及び全てのＷＦＡサービスでの伝送のためのサービス名が含まれてもよい。例えば、サービスが全てのＷＦＡサービスを支援すれば、サービス名リストには、“ｏｒｇ．ｗｉ−ｆｉ．ｗｆｄｓ．ｓｅｎｄ．ｔｘ、ｏｒｇ．ｗｉ−ｆｉ．ｗｆｄｓ．ｓｅｎｄ．ｒｘ、ｏｒｇ．ｗｉ−ｆｉ．ｗｆｄｓ．ｓｅｎｄ、ｏｒｇ．ｗｉ−ｆｉ．ｗｆｄｓ．ｐｌａｙ．ｔｘ、ｏｒｇ．ｗｉ−ｆｉ．ｗｆｄｓ．ｐｌａｙ．ｒｘ、ｏｒｇ．ｗｉ−ｆｉ．ｗｆｄｓ．ｐｌａｙ、ｏｒｇ．ｗｉ−ｆｉ．ｗｆｄｓ．ｄｉｓｐｌａｙ．ｔｘ、ｏｒｇ．ｗｉ−ｆｉ．ｗｆｄｓ．ｄｉｓｐｌａｙ．ｒｘ、ｏｒｇ．ｗｉ−ｆｉ．ｗｆｄｓ．ｄｉｓｐｌａｙ、ｏｒｇ．ｗｉ−ｆｉ．ｗｆｄｓ．ｐｒｉｎｔ．ｔｘ、ｏｒｇ．ｗｉ−ｆｉ．ｗｆｄｓ．ｐｒｉｎｔ．ｒｘ、ｏｒｇ．ｗｉ−ｆｉ．ｗｆｄｓ．ｐｒｉｎｔ”が含まれてもよい。

ｉｉ）サービスポート

サービスポートは、登録されたサービスを聴取し、サービス探索器から受信される接続のためのＩＰポートである。サービス広告器は、サービス名検索の結果パラメータとしてサービスポートをサービス探索器に知らせることができる。ただし、サービスポートは、サービス名のようにサービス探索器によって検索可能なものではない。サービスポートは予約されたものであるので、サービスポートを共有するように設定されていない限り（例えば、共有パラメータが“ｔｒｕｅ”に設定されていない限り）、他のサービス又は他のアクティブＡＳＰセッションが同じポートを使用することができない。

もし、サービス広告を要求するメソッド（ＡｄｖｅｒｔｉｓｅＳｅｒｖｉｃｅ ｍｅｔｈｏｄ）が呼び出されるとき、サービスポートが利用可能でなければ、サービス広告が失敗したことを知らせるイベント（例えば、Ａｄｖｅｒｔｉｓｅ Ｆａｉｌｅｄ Ｅｖｅｎｔ）がＡＳＰからサービスに伝送されてもよい。

サービスのためのＡＳＰセッションが生成され、ネットワークインターフェースが知られている状態のとき、サービスポートは、アプリケーションによって縛られていてもよい。

ｉｉｉ）プロトコル

プロトコルは、ＩＡＮＡ（Ｉｎｔｅｒｎｅｔ Ａｓｓｉｇｎｅｄ Ｎｕｍｂｅｒ Ａｕｔｈｏｒｉｔｙ）で定義された整数として定義することができる。例えば、ＴＣＰは数字６として定義し、ＵＤＰは数字１７として定義することができる。

ｉｖ）共有

共有パラメータは、他のサービスとサービスポートを許容するか否かを指示する。一例として、共有パラメータの値が“Ｔｒｕｅ”である場合、サービスポートは、他の広告及びＡＳＰセッションによって再使用可能である。サービスポートを共有するＡＳＰセッションはサービスポートを独占的に制御してはならない。これとは異なり、共有パラメータの値が“Ｓｅｒｖｉｃｅ”である場合、サービスポートは、同じサービス名を有する他のサービスの広告によって再使用可能である。共有パラメータの値が“Ｆａｌｓｅ”である場合、１つのサービスがサービスポートを独占的に制御することができる。

サービスが、現在広告中のサービスによって使用されるサービスポートの独占的使用を要求する場合、ＡＳＰは、サービスに広告が失敗したことを知らせるイベント（ＡｄｖｅｒｔｉｓｅＦａｉｌｅｄ Ｅｖｅｎｔ）を伝送することができる。サービスが、独占的使用が予約された（ｒｅｓｅｒｖｅｄ）サービスポートの共有を要求した場合にも、ＡＳＰは、サービスに広告が失敗したことを知らせるイベントを伝送することができる。なお、サービスが既に他のサービス広告メソッド（Ａｄｖｅｒｔｉｓｅ Ｓｅｒｖｉｃｅ Ｍｅｔｈｏｄ）と共有されているサービスポートを非共有（ｎｏｎ−ｓｈａｒｅ）サービスポートとして設定することを要求する場合にも、ＡＳＰは、サービスに広告が失敗したことを知らせるイベントを伝送することができる。

ｖ）自動受諾

サービス広告器のＡＳＰは、ＡＳＰセッションのセットアップのために、セッション要求イベント（ＳｅｓｓｉｏｎＲｅｑｕｅｓｔ Ｅｖｅｎｔ）をサービス層に伝送することができる。このとき、もし、自動受諾パラメータの値が“Ｔｒｕｅ”であれば、サービス広告器は、サービ層でセッション要求イベントに対する応答としてセッション確認メソッド（ＣｏｎｆｉｒｍＳｅｓｓｉｏｎ Ｍｅｔｈｏｄ）が呼び出されなくても、サービス探索器からの全てのＡＳＰセッション要求（ＡＳＰ−ｓｅｓｓｉｏｎ ｒｅｑｕｅｓｔ）を受諾することができる。

ただし、セッション要求イベント（ＳｅｓｓｉｏｎＲｅｑｕｅｓｔ Ｅｖｅｎｔ）でｇｅｔ_ｎｅｔｗｏｒｋ_ｃｏｎｆｉｇ_ＰＩＮパラメータがＴｒｕｅに設定されていれば、サービス層からＡＳＰ層に伝送されるサービス確認メソッド（又はセッション確認メソッド）として伝送される必要がある。

もし、自動受諾パラメータの値が“Ｆａｌｓｅ”である場合、サービス広告器のＡＳＰは、サービスからのセッション確認メソッドの受信を待ち、ＡＳＰセッション要求を受諾するか否かを決定することができる。ＡＳＰセッションセットアップのためのセッション要求イベントは、自動受諾パラメータの値と関係なく、ＡＳＰからサービスに伝送可能である。

ｖｉ）サービス情報

サービス情報は、サービス探索手順で使用されるサービスに関する具体的な情報を意味する。サービス情報の内容（ｃｏｎｔｅｎｔ）は、自由な形式であり（ｆｒｅｅ−ｆｏｒｍ）、選択的なパラメータである。もし、サービス情報が存在すれば、サービス探索応答フレーム内で１つの応答としてサービス情報がサービス探索器に伝達されてもよい。

サービス探索器は、サービス探索メソッド（ＳｅｅｋＳｅｒｖｉｃｅ Ｍｅｔｈｏｄ）内のサービス情報要求を具体化することによって、サービス情報の内容に基づいて検索を行うことができる。

ｖｉｉ）サービス状態

サービス状態は、サービス広告メソッドが呼び出される時点のサービスの状態を指示する。一例として、サービス状態パラメータの値が‘１’であることは、サービスが利用可能であることを指示するもので、サービス状態パラメータの値が‘０’であることは、サービスが利用不可能であることを指示するものであってもよい。ただし、サービスが利用不可能な状態であるとしても、サービス広告器は、プローブ要求フレームまたはサービス探索要求フレームに対する応答として、機器が当該サービスを支援することを指示することができる。

サービス状態パラメータが‘０’である場合（即ち、サービスが利用不可能な状態である場合）、ＡＳＰは、ＡＳＰセッションセットアップのための要求を拒絶することができる。

ｖｉｉｉ）ネットワークロール（ｎｅｔｗｏｒｋ ｒｏｌｅ）

ネットワークロールは、サービス広告器がＰ２Ｐグループでグループオーナー（ＧＯ）に設定されなければならないか否かを指示する。一例として、ネットワークロールパラメータが‘１’であることは、Ｐ２Ｐグループ内でサービス広告器がＧＯに設定されなければならないことを示し、ネットワークロールパラメータが‘０’であることは、サービス広告器の地位の如何は問わないことを意味してもよい。

ｉｘ）ネットワーク設定

ネットワーク設定パラメータは、接続のための好みのＷＳＣ設定メソッド（ＷＳＣ Ｃｏｎｆｉｇ．Ｍｅｔｈｏｄ）を指示する。一例として、ネットワーク設定パラメータが‘１’であることは、ＷＦＤＳデフォルト設定メソッドまたはＷＳＣ ＰＩＮメソッドを指示するものであってもよく、ネットワーク設定パラメータが‘２’であることは、ＷＳＣ ＰＩＮメソッドのみを指示するものであってもよい。

ｘ）遅延セッション応答

明示的な特定サービスではない限り、基本的に、遅延セッション応答パラメータの値はＮｕｌｌであってもよい。なお、遅延セッション応答パラメータは、自動受諾パラメータの値が“Ｆａｌｓｅ”である場合にのみ存在し得る。

遅延セッションパラメータの値が存在する場合、遅延セッションパラメータは、サービス広告器の自動受諾パラメータの値がＦａｌｓｅに設定されており、サービス探索器がＡＳＰセッションを生成しようとする時に、サービス広告器からサービス探索器に伝送されるメッセージフレームと見なされてもよい。

一例として、もし、サービス探索器がＡＳＰセッションを生成するためにプロビジョン探索要求フレームを伝送する場合、遅延セッションパラメータは、サービス広告器から伝送されるプロビジョン探索応答フレームにセッション情報フィールドとして含まれてもよい。

他の例として、もし、サービス探索器がＡＳＰセッションを生成するために、セッション要求メッセージ（Ｒｅｑｕｅｓｔ_Ｓｅｓｓｉｏｎ ｍｅｓｓａｇｅ）を伝送する場合、遅延セッション応答パラメータは、遅延セッションＡＳＰコーディネーションプロトコルメッセージ（Ｄｅｆｆｅｒｒｅｄ_Ｓｅｓｓｉｏｎ ＡＳＰ ｃｏｏｒｄｉｎａｔｉｏｎ ｐｒｏｔｏｃｏｌ ｍｅｓｓａｇｅ）の遅延セッション応答フィールドとして含まれてもよい。

ＡＳＰは、サービス広告メソッドに対して、広告ＩＤを返却することができる。広告ＩＤは、ＡＳＰによって割り当てられ、広告が要求されるサービスによって操作される機器上で固有に広告を識別する。そして、広告ＩＤは、広告されたサービスのＡＳＰセッションの確立のために、サービス探索器に伝送されてもよい。

サービス広告器は、既に存在する（ｅｘｉｓｔｉｎｇ）広告の状態が変更された場合、サービス状態変更を知らせる、サービス状態変更メソッド（ＳｅｒｖｉｃｅＳｔａｔｕｓＣｈａｎｇｅ Ｍｅｔｈｏｄ）を呼び出すことができる。サービス状態変更メソッドには、広告ＩＤ及びサービス状態パラメータが含まれてもよい。各パラメータについての説明は、次の通りである。

ｉ）広告ＩＤ

サービス広告メソッドによって返却される本来の（ｏｒｉｇｉｎａｌｌｙ）広告ＩＤが含まれてもよい。

ｉｉ）サービス状態

サービスが利用可能な状態である場合、サービス状態パラメータの値は“Ａｖａｉｌａｂｌｅ”に設定することができる。サービス広告器によって支持されるサービスがその瞬間利用不可能な状態である場合、サービス状態パラメータの値は“Ｕｎａｖａｉｌａｂｌｅ”に設定することができる。サービス状態パラメータ値は、プローブ応答フレームまたはサービス探索応答フレームに含まれてもよい。

サービス広告器は、既に存在している広告を取り消すために、サービス広告取り消しメソッド（ＣａｎｃｅｌＡｄｖｅｒｔｉｓｅＳｅｒｖｉｃｅ Ｍｅｔｈｏｄ）を呼び出すことができる。サービス広告器がサービス広告取り消しメソッドを呼び出すと、サービス名及び関連情報（ａｓｓｏｃｉａｔｅｄ ｉｎｆｏｒｍａｔｉｏｎ）はこれ以上広告されず、サービスポートに対する予約（ｒｅｓｅｒｖａｔｉｏｎ）も解除される。

サービスがＡＳＰからセッション要求イベントを受信すると、サービス広告器は、ＡＳＰセッションセットアップ（ｓｅｔｕｐ）を許容するか否かを決定するために、セッション確認メソッド（ＳｅｓｓｉｏｎＣｏｒｆｉｒｍ Ｍｅｔｈｏｄ）を呼び出すことができる。セッション確認メソッドは、特定サービスに対するセッションセットアップを許容するか否かを指示するという点で、サービス確認メソッド（ＣｏｎｆｉｒｍＳｅｒｖｉｃｅ Ｍｅｔｈｏｄ）と呼ぶこともできる。ただし、広告が自動で始まった場合（例えば、サービス広告メソッド（ＡｄｖｅｒｔｉｓｅＳｅｒｖｉｃｅ Ｍｅｔｈｏｄ）の自動受諾パラメータの値が“Ｔｒｕｅ”である場合）にはＡＳＰセッションセットアップが自動で受諾されるので、セッション確認メソッドが呼び出されなくてもよい。

セッション確認メソッドには、セッションＭＡＣパラメータ、セッションＩＤパラメータ及び確認（Ｃｏｎｆｉｒｍｅｄ）パラメータのうち少なくとも１つが含まれてもよい。各パラメータについての詳細な説明は、次の通りである。

ｉ）セッションＭＡＣ

セッションＩＤが割り当てられた機器のＭＡＣアドレスを指示する。

ｉｉ）セッションＩＤ

ＡＳＰセッションの識別子（Ｉｄｅｎｔｉｆｉｅｒ）を指示する。

ｉｉｉ）確認（Ｃｏｎｆｉｒｍｅｄ）

確認パラメータの値がＴｒｕｅであれば、ＡＳＰセッションセットアップを進行することができる。なお、Ｐ２Ｐグループが存在しなければ、グループの形成（ｆｏｒｍ）も行うことができる。これとは異なり、確認パラメータの値がＦａｌｓｅである場合、要求されたＡＳＰセッションは終了（ｃｌｏｓｅｄ）し得る。

サービス探索器のメソッド

サービス探索器は、サービス広告器として機能するピアデバイスが有するサービスを検索するためのサービス探索を要求する、サービス探索メソッド（ＳｅｅｋＳｅｒｖｉｃｅ Ｍｅｔｈｏｄ）を呼び出すことができる。検索の範囲は、選択的にＭＡＣアドレスによって制限されてもよい。サービス探索メソッドは、サービス名、正確な検索（ｅｘａｃｔ ｓｅａｒｃｈ）、ＭＡＣアドレス及びサービス情報要求パラメータのうち少なくとも１つを含むことができる。各パラメータについての具体的な説明は、次の通りである。

ｉ）サービス名

サービス名パラメータは、検索しなければならないサービスの名を指示する。サービス名パラメータに含まれる文字列は、検索されなければならないサービス名の正確な名であってもよく、検索されなければならないサービス名のプレフィックスであってもよい。

プレフィックスサーチの一例として、特定サービスに対する受信サービス及び送信サービスを検索するために、受信サービス及び送信サービスの両方の名を含ませずに、特定サービスの名のみを含ませることができる。例えば、Ｓｅｎｄサービスに対して、サービスがｏｒｇ．ｗｉ−ｆｉ．ｗｆｄｓ．ｓｅｎｄ．ｒｘ及びｏｒｇ．ｗｉ−ｆｉ．ｗｆｄｓ．ｓｅｎｄ．ｔｘを検索するためには、両者が共通的に含むｏｒｇ．ｗｉ−ｆｉ．ｗｆｄｓ．ｓｅｎｄをサービス名パラメータに挿入することができる。

全てのＷＦＡサービスを検索するためには、全てのＷＦＡサービス名が共通的に含む文字列である“ｏｒｇ．ｗｉ−ｆｉ．ｗｆｄｓ”をサービス名パラメータに含ませることができる。

ｉｉ）正確な検索

正確な検索パラメータの値が“Ｔｒｕｅ”であれば、正確な検索が行われる。具体的に、プローブ要求及び応答フレームの交換を通じて、サービス名パラメータに含まれた文字列と正確に一致するサービスを検索することができる。

正確な検索パラメータの値が“Ｆａｌｓｅ”であれば、プレフィックス検索が行われる。具体的に、プレフィックス検索のために、プローブ要求／応答フレームの交換に加えて、サービス探索要求／応答フレームの交換を行うことができる。サービス探索／要求応答フレームの交換を通じて、サービス名パラメータに含まれた文字列をプレフィックスとして含む全てのサービスを検索することができる。

機器探索の間、サービス名パラメータに含まれた文字列と正確に一致する機器のみがプローブ要求に応答するはずなので、正確な検索はプレフィックスよりも速い。

ｉｉｉ）ＭＡＣアドレス

全てのピアＷｉ−Ｆｉダイレクト機器上のサービスを検索するためのものであるので、一般に、ＭＡＣアドレスパラメータはＮＵＬＬに設定することができる。ただし、ＭＡＣアドレスパラメータに特定のピア機器のＭＡＣアドレス値が含まれる場合、サービス検索は、明示されたＭＡＣアドレスに限って制限的に行われてもよい。ピアアドレスのＭＡＣアドレスは、コロン（：）により区分される正規フォーマット（ｃａｎｏｎｉｃａｌ ｆｏｒｍａｔ）（例えば、“００：１４：ｂｂ：１１：２２：３３”）で含まれてもよい。

ｉｖ）サービス情報要求

サービス情報要求パラメータには、サービス広告器とサービス探索要求／応答フレームが交換されるサービス情報探索の間に追加的な情報を要求するための文字列が含まれてもよい。

サービス情報要求を問い合わせ（ｑｕｅｒｙ）る文字列が、サービス広告メソッド（ＡｄｖｅｒｔｉｓｅＳｅｒｖｉｃｅ ｍｅｔｈｏｄ）に含まれたサービス情報セットの従属文字列（ｓｕｂｓｔｒｉｎｇ）である場合、検索結果イベント（ＳｅａｒｃｈＲｅｓｕｌｔ Ｅｖｅｎｔ）が呼び出されてもよい。例えば、“ＡＢＣ”の問い合わせ（ｑｕｅｒｙ）文字列は、多数のサービス情報のうち“ＡＢＣｐｄｑ”または“ＡＢＣ”として読まれるサービス情報とマッチングされ得る。

サービス探索要求メソッド（例えば、ＳｅｒｖｉｃｅＳｅｅｋ Ｍｅｔｈｏｄ）に対応して、サービス探索取り消しメソッド（例えば、ＣａｎｃｅｌＳｅｅｋＳｅｒｖｉｃｅ Ｍｅｔｈｏｄ）のために使用できるハンドル（ｈａｎｄｌｅ）パラメータが返却されてもよい。

サービス探索器は、サービス探索を取り消すサービス探索取り消しメソッド（ＣａｎｃｅｌＳｅｅｋ Ｍｅｔｈｏｄ）を呼び出すことができる。サービス探索取り消しメソッドには、サービス探索メソッドによって返却されるハンドルパラメータが含まれてもよい。

サービス広告器のイベント

遠隔デバイスが、広告されるサービスに対するＡＳＰセッションを始めようとする時に、サービス広告器のＡＳＰは、セッション要求イベント（ＳｅｓｓｉｏｎＲｅｑｕｅｓｔ Ｅｖｅｎｔ）をサービスに伝送することができる。このとき、セッション要求イベントは、サービスの始まりを開始するためのものであるという点で、サービス要求イベント（ＳｅｒｖｉｃｅＲｅｑｕｅｓｔ Ｅｖｅｎｔ）と呼ぶこともできる。具体的に、セッション要求イベントは、サービス広告器のＡＳＰがプロビジョン探索要求フレームを受信するか、またはＲＥＱＵＥＳＴ_ＳＥＳＳＩＯＮ ＡＳＰコーディネーションプロトコルメッセージを受信する場合にトリガーされてもよい。セッション要求イベントには、次のパラメータが含まれてもよい。

ｉ）広告ＩＤ

サービス広告メソッドが呼び出されるとき、ＡＳＰによって割り当てられた広告識別子が含まれてもよい。

ｉｉ）セッションＭＡＣ

セッションＩＤが割り当てられたＰ２Ｐ機器のＭＡＣアドレスが含まれてもよい。

ｉｉｉ）サービスデバイス名

遠隔デバイスのデバイス名（具体的には、ＷＳＣによって定義されたデバイス名）が含まれてもよい。

ｉｖ）セッションＩＤ

遠隔ＡＳＰによって割り当てられたセッション識別子が含まれてもよい。

ｖ）セッション情報

サービス特定データペイロードが含まれてもよい。セッション情報は、最大１４４バイトの長さを有することができる。

ｖｉ）ネットワーク設定ＰＩＮ獲得（ｇｅｔ_ｎｅｔｗｏｒｋ_ｃｏｎｆｉｇ_ＰＩＮ）

もし、サービス広告器が、サービス広告器でサービスネットワークをセットアップするためのＰＩＮ（Ｐｅｒｓｏｎａｌ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ Ｎｕｍｂｅｒ）を要求するＷＳＣ設定メソッド（ＷＳＣ Ｃｏｎｆｉｇ ｍｅｔｈｏｄ）と共に、プロビジョン探索要求フレームを受信する場合、ネットワーク設定ＰＩＮ獲得パラメータの値は“Ｔｒｕｅ”であり得る。ユーザによって入力されたＷＳＣ ＰＩＮは、セッション確認メソッドに含まれてＡＳＰに提供され得る。

もし、サービス広告器が、サービス広告器でサービスネットワークをセットアップするためのＰＩＮ（Ｐｅｒｓｏｎａｌ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ Ｎｕｍｂｅｒ）を要求しないＷＳＣ設定メソッド（ＷＳＣ Ｃｏｎｆｉｇ ｍｅｔｈｏｄ）と共に、プロビジョン探索要求フレームを受信するか、またはＲＥＱＵＥＳＴ_ＳＥＳＳＩＯＮ ＡＳＰコーディネーションプロトコルメッセージによってサービス要求イベントがトリガーされた場合、ネットワーク設定ＰＩＮ獲得パラメータの値は“Ｆａｌｓｅ”であり得る。

ｖｉｉ）ネットワーク設定ＰＩＮ

サービス広告器のＡＳＰが、サービスネットワークをセットアップするためにディスプレイされるＰＩＮを要求するＷＳＣ設定メソッドと共にプロビジョン探索要求を受信する場合、ＡＳＰは、ＷＳＣ ＰＩＮ値を生成し、生成されたＷＳＣ ＰＩＮ値をサービスに提供して、ＷＳＣ ＰＩＮ値がディスプレイされるようにすることができる。

サービス広告器のＡＳＰが、サービスネットワークをセットアップするためにディスプレイされるＰＩＮを要求しないＷＳＣ設定メソッドと共にプロビジョン探索要求を受信する場合、またはＲＥＱＵＥＳＴ_ＳＥＳＳＩＯＮ ＡＳＰコーディネーションプロトコルメッセージによってサービス要求イベントがトリガーされた場合、ネットワーク設定ＰＩＮパラメータの値は‘０’であり得る。

サービスをこれ以上広告できないか、またはサービスの広告を開始できない場合、広告失敗を知らせるイベント（例えば、ＡｄｖｅｒｔｉｓｅＦａｉｌｅｄ Ｅｖｅｎｔ）を伝送することができる。広告失敗を知らせるイベントには、広告ＩＤ及び失敗理由パラメータが含まれてもよい。各パラメータについて簡略に説明すると、次の通りである。

ｉ）広告ＩＤ

サービス広告メソッド（ＡｄｖｅｒｔｉｓｅＳｅｒｖｉｃｅ Ｍｅｔｈｏｄ）によって返却される広告ＩＤ値を指示することができる。

ｉｉ）理由

広告失敗の理由が含まれてもよい。広告失敗の理由は、サービスポートが既に共有中の場合（一例として、非共有サービスポートを要求したが、当該サービスポートが既に共有サービスポートとして利用される場合）、サービスポートが既に私的に用いられる場合（一例として、サービスポートを要求したが、サービスポートが既に私的な（専用の）サービスポートとして利用される場合）、またはその他の失敗事由のいずれか１つを指示することができる。

サービス探索器のイベント

検索が進行中のとき、ピア機器から発見されたそれぞれの広告されるサービスのために検索結果を知らせる、検索結果イベント（ＳｅａｒｃｈＲｅｓｕｌｔ Ｅｖｅｎｔ）が伝送されてもよい。検索結果イベントには、ハンドル、サービスＭＡＣ、広告ＩＤ、サービス名、サービス情報及びサービス状態パラメータのうち少なくとも１つが含まれてもよい。各パラメータについての説明は、次の通りである。

ｉ）ハンドル

サービス探索メソッドによって返却される値を指示する。

ｉｉ）サービスＭＡＣ

ピアデバイスのＭＡＣアドレスを指示する。

ｉｉｉ）広告ＩＤ

ピアデバイスによって定義された広告ＩＤを指示する。

ｉｖ）サービス名

ピアデバイスによって定義されたフル（ｆｕｌｌ）サービス名を指示する。

ｖ）サービス情報

サービス広告器とサービス検索器との間に定義された追加的なサービス（ベンダー（ｖｅｎｄｏｒ））特定パラメータまたはＮＵＬＬ文字列が含まれる。

ｖｉ）サービス状態

サービスが利用可能な状態である場合、サービス状態パラメータの値は“Ａｖａｉｌａｂｌｅ”に設定することができる。サービス広告器によって支持されるサービスがその瞬間利用不可能な状態である場合、サービス状態パラメータの値は“Ｕｎａｖａｉｌａｂｌｅ”に設定することができる。

サービス探索器は、サービス探索メソッド（ＳｅｅｋＳｅｒｖｉｃｅ Ｍｅｔｈｏｄ）によって開始された検索を中断するか、またはこれ以上の検索結果イベント（Ｓｅａｒｃｈｒｅｓｕｌｔ Ｅｖｅｎｔ）が生成されることを防止するための検索終了イベント（ＳｅａｒｃｈＴｅｒｍｉｎａｔｅｄ Ｅｖｅｎｔ）を伝送することができる。検索終了イベントには、ハンドル及び終了理由パラメータが含まれてもよい。各パラメータについての説明は、次の通りである。

ｉ）ハンドル

終了される検索を指示する。

ｉｉ）理由

検索の終了理由が指示されてもよい。検索の終了理由として、タイムアウト（Ｔｉｍｅｏｕｔ）またはシステム誤り（Ｓｙｓｔｅｍ Ｆａｉｌｕｒｅ）が指示されてもよい。

サービス探索器は、広告されるサービスのＡＳＰセッションを開始するために、サービス要求イベント（ＳｅｒｖｉｃｅＲｅｑｕｅｓｔ Ｅｖｅｎｔ）を伝送することができる。サービス要求イベントには、広告ＩＤ、セッションＭＡＣ、セッションＩＤ及びセッション情報パラメータのうち少なくとも１つが含まれてもよい。各パラメータについての説明は、次の通りである。

ｉ）広告ＩＤ

ピア機器によって定義された広告識別子が含まれてもよい。

ｉｉ）セッションＭＡＣ

セッションＩＤが割り当てられたピアデバイスのＭＡＣアドレスが含まれてもよい。

ｉｉｉ）セッションＩＤ

ＡＳＰセッション識別子が含まれてもよい。

ｉｖ）セッション情報

アプリケーション特定データペイロード（ｐａｙｌｏａｄ）が含まれてもよい。

サービス探索及びＡＳＰセッションセットアップ

上述した説明に基づいて、本発明に係るサービス探索及びＡＳＰセッションセットアップ過程について詳細に説明する。

図１３は、サービス探索及びＡＳＰセッションセットアップ動作の流れ図である。図１３に示したＡＳＰセッションセットアップ動作は、あるＰ２Ｐデバイスの特定のサービスが他のＰ２Ｐデバイス及びサービスを探索し、サービスを要求して、Ｗｉ−Ｆｉダイレクト接続を確立し、アプリケーションが動作する過程を意味する。

説明の便宜のため、図１３において、デバイスＡは、自身のサービスを広告するサービス広告器として動作し、デバイスＢは、サービスを探索するサービス探索器として動作するものと仮定する。

デバイスＡのサービス層がＡＳＰにサービス広告メソッドを伝送すると、デバイスＡのＡＳＰは、サービス広告メソッドに含まれた情報に基づいて自身のサービスを広告し、他のデバイスが当該サービスを見つけることができるように待機することができる。

デバイスＢのサービス層がＡＳＰにサービス探索メソッドを伝送すると、デバイスＢのＡＳＰは、受信されたサービス探索メソッドに含まれた情報に基づいて上位アプリケーションまたはユーザの所望のサービスを支援するデバイスを探索することができる。一例として、デバイスＢのサービス層が、アプリケーション層からサービスを使用する旨（Ｕｓｅ Ｓｅｒｖｉｃｅ）の意図を示す情報を受信すると、検索が必要なサービスに対する情報を含むサービス探索メソッドをＡＳＰに伝達することができる。

サービス探索メソッドを受信したデバイスＢのＡＳＰは、所望のサービスを支援するデバイスを探索するために、プローブ要求フレームを伝送することができる。このとき、プローブ要求フレームには、見つけようとするまたは自身が支援可能なサービスのサービス名（ｓｅｒｖｉｃｅ ｎａｍｅ）をハッシュ（ｈａｓｈ）形態に変換したハッシュ値が含まれてもよい。ハッシュ値は、ＡＳＰがサービス名またはサービス名のプレフィックス（ｐｒｅｆｉｘ）をハッシュ形態に変換したものであって、６オクテットの長さを有することができる。プローブ要求フレームはブロードキャスト伝送されてもよく、特定の機器に対してユニキャスト伝送されてもよい。

プローブ要求フレームを受信したデバイスＡは、ハッシュマッチング（ｈａｓｈ ｍａｔｃｈｉｎｇ）を試み、プローブ要求フレームに含まれたハッシュ値にマッチングされるサービスを支援するものと判断される場合、プローブ応答フレーム（Ｐｒｏｂｅ Ｒｅｓｐｏｎｓｅ ｆｒａｍｅ）をデバイスＢに伝送することができる。このとき、プローブ応答フレームには、ハッシュ値、広告ＩＤフィールド及びサービス通知情報フィールドのうち少なくとも１つが含まれてもよい。ハッシュ値は、プローブ要求フレームを介して要求されるハッシュ値にマッチングされるサービスのハッシュ値を指示するもので、広告ＩＤフィールドは、ＡＳＰの内部で各サービスに対する広告を固有に識別するために、ＡＳＰによって割り当てられた値であってもよい。広告ＩＤは、ＡＳＰセッション確立を要求するのに利用されてもよい。サービス通知情報フィールドは、サービス情報指示フィールド（ｓｅｒｖｉｃｅ_ｉｎｆｏｒｍａｔｉｏｎ_ｉｎｄｉｃａｔｉｏｎ_ｆｉｅｌｄ）及びサービス状態フィールド（ｓｅｒｖｉｃｅ_ｓｔａｔｕｓ_ｆｉｅｌｄ）を含むことができる。サービス情報指示フィールドは、プローブ応答に含まれている各サービス別にサービス情報が存在するか否かを指示することができる。サービス状態フィールドは、プローブ応答フレームを伝送する瞬間にサービスが利用可能であるか否かを指示するのに利用することができる。

デバイスＡからデバイスＢが見つけようとするサービスの利用が可能であることを知らせるプローブ要求フレームを受信すると、デバイスＢのＡＳＰは、見つけようとするサービスを支援する機器が発見されたことを報告するために、検索結果イベントをサービス層に伝送することができる。このとき、検索結果イベントには、サービス名、広告ＩＤ、サービス状態及びサービス情報パラメータのうち少なくとも１つが含まれてもよい。

デバイスＢが見つけようとするサービスを支援する機器が見つからなかった場合、サービス探索要求フレームの伝送は省略することができる。図示していないが、デバイスＢのＡＳＰは、見つけようとするサービスを支援する機器が発見されなかったことを知らせる、検索結果イベントをサービス層に伝送することができる。このとき、検索結果イベントには、サービス名、広告ＩＤ、サービス状態及びＮＵＬＬサービス情報パラメータが含まれてもよい。

デバイスＡから、利用可能なサービスがあることを知らせるプローブ要求フレームを受信すると、デバイスＢは、デバイスＡのサービス情報を探索するために、サービス探索要求フレームをトリガーすることができる。このとき、サービス探索要求フレームにはサービス名フィールドが含まれてもよい。サービス名フィールドは、検索しようとする完全な（ｃｏｍｐｌｅｔｅ）サービス名または検索しようとするサービス名のプレフィックスを含むことができる。

これに対して、デバイスＡは、サービス名マッチングを行って、デバイスＢが見つけようとするサービスを提供するか否かを知らせるサービス探索応答フレームをデバイスＢに伝送することができる。サービス探索応答フレームには、サービス名、サービス状態、広告ＩＤ及びサービス情報が含まれてもよい。

サービス名は、広告されるサービスのサービス名を指示する文字列を含むことができる。

デバイスＡが、デバイスＢが見つけようとするサービスを支援するとしても、サービス探索応答フレームを伝送する時点に、デバイスＢが、デバイスＡが提供するサービスを利用できない場合が発生し得る。例えば、デバイスＡが、デバイスＡが検索するプリント（Ｐｒｉｎｔ）サービスを支援するが、サービス探索応答フレームを伝送する時点に、最大利用可能デバイスと連携中であるので、これ以上のピアデバイスとの連携を許容できなければ、デバイスＡは、デバイスＢが検索しようとするサービスを支援するにもかかわらず、デバイスＢは、デバイスＡが提供するサービスを利用できなくなる。これによって、本発明に係るデバイスＡは、サービス探索応答フレームが伝送される瞬間に当該サービスを利用可能であるか否かを指示するサービス状態情報をサービス探索応答フレームに含ませることができる。

すなわち、サービス探索応答フレームが伝送される時点に当該サービスの利用が不可能であれば、サービス状態情報は、当該サービスが利用不可能であることを指示する一方、サービス探索応答フレームが伝送される時点に当該サービスの利用が可能であれば、サービス状態情報は、当該サービスを利用できることを指示することができる。サービス状態情報は、１ビットの指示子（ｉｎｄｉｃａｔｏｒ）であってもよい。

広告ＩＤフィールドは、ＡＳＰの内部で各サービスに対する広告を固有に識別するためのものであってもよい。

サービス情報フィールドは、サービス広告器であるデバイスＡがサービス探索器であるデバイスＢと共有できる選択的な（ｏｐｔｉｏｎａｌ）情報を含むことができる。与えられたサービス（即ち、デバイスＢが見つけようとするサービス）に対するサービス情報が存在する場合、サービス情報フィールドには、与えられたサービスとマッチングされるプローブ応答フレームを介して伝送されたハッシュ値が含まれてもよい。

ただし、サービス情報を獲得するためには、サービス探索要求フレームを伝送するデバイスＢが正確なサービス名及びサービス情報の問い合わせのために、ＷＦＤＳサービスプロトコルタイプ（整数５として正義）を使用する必要がある。デバイスＢは、サービス層でサービス探索メソッドが呼び出されるとき、サービス探索メソッドに含まれるサービス情報要求パラメータを具体化することによって、サービス情報の内容に基づいてサービスを検索することができる。

上述したサービス探索要求及び応答フレームは、ＩＥＥＥ ８０２．１１ｕシステムで定義するＧＡＳ（Ｇｅｎｅｒｉｃ Ａｄｖｅｒｔｉｓｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）を用いて行われてもよい。

デバイスＢのＡＳＰは、サービス層が要求したサービス探索メソッドによって要求された動作が完了すると、検索結果イベントを介して、その結果をサービスを介してアプリケーション及びユーザに知らせることができる。

この時点まではＷｉ−Ｆｉ Ｄｉｒｅｃｔのグループは形成されていない状態である。デバイスＡで提供するサービスが利用可能であり、ユーザがデバイスＡのサービスを選択して、サービスがセッション接続メソッド（ＣｏｎｎｅｃｔＳｅｓｓｉｏｎ Ｍｅｔｈｏｄ）を呼び出す場合、Ｐ２Ｐグループ形成（ｇｒｏｕｐ ｆｏｒｍａｔｉｏｎ）が進行し得る。このとき、プロビジョン発見要求（Ｐｒｏｖｉｓｉｏｎ Ｄｉｓｃｏｖｅｒｙ Ｒｅｑｕｅｓｔ）及びプロビジョン発見応答（Ｐｒｏｖｉｓｉｏｎ Ｄｉｓｃｏｖｅｒｙ Ｒｅｓｐｏｎｓｅ）を介して、セッション情報と接続能力（ｃｏｎｎｅｃｔｉｏｎ ｃａｐａｂｉｌｉｔｙ）情報が交換される。

セッション情報は、サービスを要求するデバイスが要求するサービスの概略的な情報を知らせるヒント（ｈｉｎｔ）情報である。セッション情報は、例えば、ファイル伝送サービスを要求しようとする場合には、ファイルの数、サイズなどを知らせることで、相手がサービス要求に対する収容／拒絶（ａｃｃｅｐｔ／ｒｅｊｅｃｔ）を決定できるようにする情報である。接続能力は、ＧＯ交渉（Ｇｒｏｕｐ Ｏｗｎｅｒ ｎｅｇｏｔｉａｔｉｏｎ）及びＰ２Ｐ招待（ｉｎｖｉｔａｔｉｏｎ）過程でグループを生成するための情報として利用することができる。

デバイスＢがデバイスＡにプロビジョン発見要求メッセージを伝達すると、デバイスＡのＡＳＰは、サービス情報などを含むセッション要求（ＳｅｓｓｉｏｎＲｅｑｕｅｓｔ）をサービス層に伝達し、サービス層は、サービス情報をアプリケーション／ユーザに伝達する。アプリケーション／ユーザが、セッション情報に基づいて当該セッションを収容すると決定すると、サービス層を介してサービス確認メソッドがＡＳＰに伝達される。

その間、デバイスＡのＡＳＰは、デバイスＢにプロビジョン発見応答メッセージを伝達し、その状態情報は‘延期（ｄｅｆｅｒｒｅｄ）’に設定することができる。これは、当該サービスが即時には収容されないことを示し、ユーザの入力を待っていることを知らせるためである。これによって、デバイスＢのＡＳＰは、サービス層にＣｏｎｎｅｃｔＳｔａｔｕｓイベントを伝達しながら、サービス要求が延期されたことを知らせることができる。

デバイスＡのＡＳＰがサービス確認メソッド（ＣｏｎｆｉｒｍＳｅｒｖｉｃｅ Ｍｅｔｈｏｄ）を受信すると、後続（ｆｏｌｌｏｗ−ｏｎ）プロビジョン発見過程を行うことができる。すなわち、デバイスＡはデバイスＢにプロビジョン発見要求メッセージを伝達することができる。これを、ｆｏｌｌｏｗ−ｏｎプロビジョン発見過程と呼ぶことができる。このメッセージには、当該サービスに対する状態が成功（ｓｕｃｃｅｓｓ）であることを示す情報と共に、サービス情報が含まれてもよい。これによって、デバイスＢのＡＳＰは、サービス層にＣｏｎｅｃｔＳｔａｔｕｓイベントを伝達しながら、サービス要求が収容されたことを知らせることができる。また、デバイスＢのＡＳＰは、プロビジョン発見応答メッセージをデバイスＡに伝達することができ、ここには、接続能力情報が含まれてもよい。

Ｐ２Ｐプロビジョン発見過程が行われた後、ＧＯ交渉または招待過程を通じてＰ２Ｐグループが生成され、第２層（Ｌ２）接続及びＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）接続が行われる。ＧＯ交渉のために、ピアデバイス間にＧＯ交渉要求フレーム及びＧＯ交渉応答フレームを交換することができる。ＧＯ交渉過程についての詳細な説明は省略する。

ＧＯ交渉が完了してＰ２Ｐ接続又はＩＰ接続が生成された後、デバイスＡとＢは、ＡＳＰコーディネーションプロトコル（ｃｏｏｒｄｉｎａｔｉｏｎ ｐｒｏｔｏｃｏｌ）を介してセッションを要求するＲＥＱＵＥＳＴ_ＳＥＳＳＩＯＮメッセージを伝達する。ＲＥＱＵＥＳＴ_ＳＥＳＳＩＯＮメッセージには、広告ＩＤ、ＭＡＣアドレス（ｍａｃ_ａｄｄｒ）、セッション識別子（ｓｅｓｓｉｏｎ ＩＤ）などが含まれてもよい。ＭＡＣアドレスは、Ｐ２Ｐデバイスのアドレスを意味する。ＲＥＱＵＥＳＴ_ＳＥＳＳＩＯＮメッセージに応答して、デバイスＡはデバイスＢにＡＣＫメッセージを伝達することができる。

これを受けたデバイスＡは、セッションが接続されたことを上位サービス／アプリケーションに知らせ、サービス層は、当該セッションに対するポート（ｐｏｒｔ）情報を要求し、当該セッションとポートをバインディング（ｂｉｎｄｉｎｇ）させることができる。これによって、ＡＳＰは、当該ポートを開いて（ＡＳＰは、ポートをファイアウォール（ｆｉｒｅｗａｌｌ）内で開くことができる）、ポートが準備されたことをサービス層に知らせることができる。サービス層は、セッションが準備されたことを知らせるセッション準備メソッド（ＳｅｓｓｉｏｎＲｅａｄｙ Ｍｅｔｈｏｄ）をＡＳＰに知らせることができる。

これによって、デバイスＡのＡＳＰは、ＡＤＤＥＤ_ＳＥＳＳＩＯＮメッセージを相手デバイスに伝送する。このとき、ＡＤＤＥＤ_ＳＥＳＳＩＯＮメッセージには、セッション識別子（ｓｅｓｓｉｏｎ ＩＤ）、ＭＡＣアドレス情報などが含まれてもよく、これによってサービスを固有に（ｕｎｉｑｕｅ）区分することができる。ＡＤＤＥＤ_ＳＥＳＳＩＯＮメッセージを受信したデバイスＢのＡＳＰは、セッション接続をサービス層に知らせ、ポート要求、ポートバインディングなどを経てポートが準備されたこと（ＰｏｒｔＲｅａｄｙ（））をサービス層に知らせることができる。ＡＳＰは、ポートをファイアウォール（ｆｉｒｅｗａｌｌ）内で開くことができる。

その後、デバイスＡとデバイスＢのサービス層間にアプリケーションソケット（ｓｏｃｋｅｔ）接続を知らせ、アプリケーション層によってアプリケーションデータの伝送のためのリンクが形成され、これを介してアプリケーションデータを送受信することができる。

デバイスＢのアプリケーション／ユーザによって当該アプリケーションの終了（Ｃｌｏｓｅ Ａｐｐｌｉｃａｔｉｏｎ）がサービス層に指示され得る。これによって、サービス層は、ＡＳＰにセッション終了メソッド（ＣｌｏｓｅｄＳｅｓｓｉｏｎ Ｍｅｔｈｏｄ）を伝達し、当該ポートが解除（ｒｅｌｅａｓｅ）されることを知らせることができる。

これによって、デバイスＢのＡＳＰは、デバイスＡに、ＲＥＭＯＶＥ_ＳＥＳＳＩＯＮメッセージを介して、接続されたサービスの終了を要求することができる。ＲＥＭＯＶＥ_ＳＥＳＳＩＯＮメッセージには、広告ＩＤ、ＭＡＣアドレス、セッションＩＤなどが含まれてもよい。

デバイスＡのＡＳＰは、サービス層を介してアプリケーション／ユーザにセッション終了を知らせ、サービス層はＡＳＰにポート解除を知らせることができる。これによって、ＡＳＰは、当該サービスに対してアクティブであるセッションが存在しない場合に、ファイアウォール内でインカミング（ｉｎｃｏｍｉｎｇ）ポートを閉じることができる。デバイスＡは、デバイスＢにＲＥＭＯＶＥ_ＳＥＳＳＩＯＮメッセージに対するＡＣＫメッセージを伝達することができ、デバイスＢのＡＳＰにおいても、当該サービスに対してアクティブであるセッションが存在しない場合に、ファイアウォール内でインカミングポートを閉じることができる。

その後、デバイスＡ及びデバイスＢは、連携解除（Ｄｉａｓｓｏｃｉａｔｉｏｎ）要求／応答を介してＰ２Ｐ接続及び相互連携（ａｓｓｏｃｉａｔｉｏｎ）を終了することができる。

図１３の例示を参照して、サービス要求がＰ２Ｐプロビジョン発見過程を用いて開始された場合に、サービス探索器（Ｓｅｒｖｉｃｅ Ｓｅｅｋｅｒ）とサービス広告器（Ｓｅｒｖｉｃｅ Ａｄｖｅｒｔｉｓｅｒ）との間のメッセージシーケンスについて説明した。図１３の例示では、自動受諾パラメータがＦＡＬＳＥに設定される場合を仮定した。もし、自動受諾パラメータがＴＲＵＥに設定されれば、ＡＳＰは、サービスからのセッション確認メソッドがなくても、すべてのＡＳＰ−セッションサービス要求を収容するように動作することができる。また、それぞれのＡＳＰは、現在の状態をＳｅｓｓｉｏｎＳｔａｔｕｓイベント及びＣｏｎｎｅｃｔｉｏｎＳｔａｔｕｓイベントを用いてサービスに知らせることができる。

以下では、ＷＦＡサービスでのサービス探索手順について具体的に説明する。説明の便宜のため、ＷＦＡサービスにおいて伝送（Ｓｅｎｄ）サービスを例に挙げて説明する。ただし、後述する実施例は、伝送サービス以外のＷＦＡサービス及びイネーブルサービスにも適用できることは勿論である。

伝送サービスでのサービス探索手順

図１４は、Ｗｉ−Ｆｉダイレクトファイル伝送サービスのアーキテクチャーを示す図である。図１４に示したＡＳＰ層及びＷｉ−Ｆｉダイレクト層は、ピアデバイスのＬ２接続を提供する役割を担うことができる。

Ｗｉ−Ｆｉダイレクトサービス探索ステップにおいて、ピアデバイスは、他のピアデバイスとサービス能力（Ｓｅｒｖｉｃｅ ｃａｐａｂｉｌｉｔｉｅｓ）に対する情報を交換することができる。具体的に、ピアデバイスは、他のピアデバイスとファイル伝送サービスを支援するか否かに対する情報を交換することができる。ファイル伝送サービスが可能な他のピアデバイスが検索されると、ピアデバイスのＡＳＰは、検索された機器との連携（ａｓｓｏｃｉａｔｉｏｎ）を行うことができる。

制御平面は、ピアデバイス間にＷｉ−Ｆｉダイレクトファイル伝送サービスセッションを確立するのに活用することができる。制御平面は、ＵＰｎＰを使用することができるＷＦＤファイル伝送制御点（ＵＰｎＰ ｅｎａｂｌｅｄ Ｗｉ−Ｆｉ Ｄｉｒｅｃｔ ＦＴＳ Ｃｏｎｔｒｏｌ Ｐｏｉｎｔ）及びＵＰｎＰを使用することができるＰ２Ｐファイル伝送サービス要素（ＵＰｎＰ ｅｎａｂｌｅｄ Ｐ２Ｐ ＦＴＳ ｃｏｍｐｏｎｅｎｔ）を含むことができる。

データ平面は、実際のファイルデータの伝送のための伝送経路を提供することができる。ファイル伝送のためにＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）を利用することができる。

ＦＴＳを利用するピアデバイスのいずれか一方は、伝送トランスミッタ（Ｓｅｎｄ Ｔｒａｎｓｍｉｔｔｅｒ）として動作し、他方は、伝送レシーバ（Ｓｅｎｄ Ｒｅｃｅｉｖｅｒ）として動作することができる。一例として、図１５は、伝送トランスミッタと伝送レシーバとの間の動作を層別に簡略に図式化した図である。

伝送トランスミッタ及び伝送レシーバは、Ｗｉ−Ｆｉダイレクト層及びＡＳＰ層を介して、デバイス探索、サービス探索及びサービス連携を行うことができる。

伝送トランスミッタと伝送レシーバとの間のサービス連携が完了すると、伝送トランスミッタは、他のピアデバイス（即ち、伝送レシーバ）とのファイル伝送セッションを開始し、上位層であるトランスポート層で、ＨＴＴＰを用いてファイル伝送を行うことができる。

トランスポート層でファイルデータを伝送するにおいて、伝送トランスミッタはＨＴＴＰクライアントの役割を担い、伝送レシーバはＨＴＴＰサーバーの役割を担うことができる。伝送トランスミッタは、ＨＴＴＰ ＰＵＴメソッドを用いてＨＴＴＰサーバー（即ち、伝送レシーバ）にファイルを伝送し、伝送レシーバは、伝送トランスミッタからファイルデータを受信することができる。

ＨＴＴＰサーバーとして機能する伝送レシーバは、伝送されるファイルを受信するために、特定のＴＣＰポートをオープンすることができる。

伝送レシーバは、ファイル伝送のためのＵＰｎＰサービスを主催（ｈｏｓｔ）することができる。伝送トランスミッタは、ＵＰｎＰ制御点を介して、伝送レシーバによって主催される（ｈｏｓｔｅｄ）ＷＦＤＳ上のＵＰｎＰアクションを発動（ｉｎｖｏｋｅ）することができる。

図１６は、ＦＴＳでのＬ２接続が確立される過程を説明するための図である。図１５を参照すると、まず、伝送トランスミッタは、ＦＴＳセッションを確立する伝送レシーバを検索するためのＷｉ−Ｆｉダイレクト機器探索手順を行うことができる。

その後、伝送トランスミッタは、ファイル伝送サービスの探索を要求するためのサービス探索要求フレームを伝送することができる。サービス探索要求フレームは、ブロードキャスト伝送されてもよく、特定のピアデバイスにユニキャスト伝送されてもよい。

サービス探索要求フレームには、伝送トランスミッタが見つけようとするサービスバージョン情報が含まれてもよい。一例として、サービスバージョン情報が０ｘ０１であることは、Ｗｉ−Ｆｉダイレクトファイル伝送サービスバージョン１を指示することができる。

サービス探索要求フレームを受信した伝送レシーバは、これに対する応答としてサービス探索応答フレームを伝送することができる。

伝送レシーバが、伝送トランスミッタが見つけようとする所望のサービス及びサービスバージョンを支援する場合、伝送レシーバと伝送トランスミッタとの間でＬ２サービス連携を進行することができる。

具体的に、伝送トランスミッタは伝送レシーバにサービス連携要求フレームを伝送し、これに対する応答として、伝送レシーバは伝送トランスミッタにサービス連携応答フレームを伝送することができる。このとき、サービス連携要求フレーム及び応答フレームは、ＩＥＥＥ ８０２．１１ｕシステムで定義するＧＡＳ（Ｇｅｎｅｒｉｃ Ａｄｖｅｒｔｉｓｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）を用いて行われてもよい。

サービス連携要求フレーム及びサービス連携応答フレームにはベンダー特定（Ｖｅｎｄｏｒ−Ｓｐｅｃｉｆｉｃ）コンテンツが含まれてもよい。一例として、表１は、ベンダー特定コンテンツに挿入できるフィールドを列挙した図表である。

表１に記述したように、サービス連携要求フレーム及びサービス連携応答フレームには共通的に、ＯＵＩ（Ｏｒｇａｎｉｚａｔｉｏｎａｌｌｙ Ｕｎｉｑｕｅ Ｉｄｅｎｔｉｆｉｅｒ）サブタイプフィールド、サービス連携アップデートインジケーターフィールド及びサービス連携ＴＬＶ（Ｔｙｐｅ、Ｌｅｎｇｔｈ、Ｖａｌｕｅ）フィールドを含むことができる。

ＯＵＩサブタイプフィールドは、当該フレームがサービス連携フレームであることを指示することができる。

サービス連携アップデート指示子は、サービス連携要求フレームまたはサービス連携応答フレームを伝送する機器のサービス情報が変更される毎に１ずつ増加するカウンターである。伝送トランスミッタ及び伝送レシーバは、相手から受信するアップデート指示子値を格納し、格納された値と以降のサービス連携要求フレームまたはサービス連携応答フレームを受信したときのアップデート指示子値とを比較して、相手のサービス情報がアップデートされたか否かを判断することができる。

サービス連携ＴＬＶ（Ｔｙｐｅ、Ｌｅｎｇｔｈ、Ｖａｌｕｅ）フィールドは、それがサービス連携要求フレームに含まれるか、またはサービス連携応答フレームに含まれるかによって、サービス要求ＴＬＶまたはサービス応答ＴＬＶと呼ぶことができる。表２は、そのうち、サービス連携要求フレームのサービス要求ＴＬＶを説明するための図表である。

表２に記述した例のように、サービス要求フレームに含まれるサービス要求ＴＬＶには、長さフィールド、サービスプロトコルタイプフィールド、サービストランザクションＩＤフィールド、ＴＣＰポートフィールド及び伝送サービスメタ情報フィールドを含むことができる。

長さフィールドは、サービス要求ＴＬＶの長さを指示する。

サービスプロトコルタイプフィールドは、ＷＦＤＳのサービスプロトコルタイプを指示する。一例として、表３は、サービスプロトコルタイプ別値（ｖａｌｕｅ）を説明するための図表である。

表３に列挙した例において、サービスプロトコルタイプフィールドの値が０ｘ０５であることは、ＦＴＳのためのプロトコルタイプであることを指示することができる。

サービストランザクションＩＤフィールドは、サービス連携要求フレームとサービス連携応答フレームとのマッチングのために発給される識別子である。一例として、サービス連携要求フレームを伝送した伝送トランスミッタは、伝送されたサービス連携要求フレームのトランザクションＩＤと同じトランザクションＩＤを有するサービス連携応答フレームを受信して、サービス連携を進行することができる。

ＴＣＰポートフィールドは、ファイル伝送に必要なＴＣＰポートの値を指示する。

伝送サービスメタ情報フィールドはサービス特定情報を含むことができる。ここで、サービス特定情報とは、ピアデバイスにヒントを提供するために要求されるものであってもよい。一例として、表４は、伝送サービスメタ情報を説明するための図表である。

表４に記述したように、サービスメタ情報フィールドは、ノートフィールド、サイズフィールド、アイテムの数フィールド（ＮｏｏｆＩｔｅｍｓ（Ｎｕｍｂｅｒ ｏｆ Ｉｔｅｍｓ）フィールド）及びＩｔｅｍフィールドを含むことができる。

ノートフィールドには、ＡＳＣＩＩ形式の自由なテキストが入力されてもよい。

サイズフィールドは、伝送サービスメタ情報フィールドの総サイズ（Ｋｂ単位）を指示する。

アイテムの数フィールドは、伝送サービスメタ情報に含まれたアイテムの数を指示することができる。

アイテムフィールドは、伝送されるファイルの情報を示す。具体的に、アイテムフィールドは、伝送されるファイルの名、伝送されるファイルのサイズ及び伝送されるファイルのタイプに関する情報のうち少なくとも１つを含むことができる。一例として、表５は、アイテムフィールドを説明するための図表である。アイテムフィールドのサイズは、伝送されるファイルの数に比例して線形的に増加することができる。

表６は、サービス連携応答フレームのサービス応答ＴＬＶを説明するための図表である。

表６に記述したように、サービス応答ＴＬＶは、長さフィールド、サービスプロトコルタイプフィールド、サービストランザクションＩＤフィールド、状態コードフィールド及びＴＣＰポートフィールドを含むことができる。

長さフィールドは、サービス応答ＴＬＶの長さを指示する。

サービスプロトコルタイプフィールドは、ＷＦＤＳのサービスプロトコルタイプを指示する。一例として、サービスプロトコルタイプフィールドの値が０ｘ０５であることは、ＦＴＳのためのプロトコルタイプであることを指示することができる。

サービストランザクションＩＤフィールドは、サービス連携要求フレームとサービス連携応答フレームのマッチングのために発給される識別子である。一例として、サービス連携要求フレームを受信した伝送レシーバは、サービストランスミッタに、伝送されたサービス連携要求フレームのトランザクションＩＤと同じトランザクションＩＤを有するサービス連携応答フレームを伝送することができる。

状態コードフィールドは、要求されるサービス情報の状態を指示する。一例として、サービス情報の状態は、表７のように定義することができる。

表７に記述された例でのように、サービス状態コードフィールドを介して伝送トランスミッタとのサービス連携が成功したか否かが、一例として、状態コードフィールドの値が０である場合、伝送トランスミッタと伝送レシーバとの間のサービス連携が成功したことを指示するが、状態コードフィールドの値が１〜４である場合には、伝送トランスミッタと伝送レシーバとの間の連携は失敗したことを指示することができる。

表６に記述したＴＣＰポートフィールドは、ファイル伝送に必要なＴＣＰポートの値を指示する。

再び図１６を参照すると、伝送トランスミッタが、伝送されるファイルに関する伝送サービスメタ情報を含むサービス連携要求フレームを伝送レシーバに伝送すると、伝送レシーバは、ＦＴＳ連携が要求されたことを知らせる情報をディスプレイし、ユーザにＦＴＳ連携を許容するか否かを問い合わせることができる。ユーザから、ＦＴＳ連携を受諾するか否かに対する入力を受信すると、伝送レシーバのＡＳＰは、サービス連携要求フレームに対して応答することができる。具体的に、伝送レシーバは、状態コードを含むサービス連携応答フレームを伝送トランスミッタに伝送することができる。ユーザがＦＴＳ連携を受諾する場合、先に表７に記述したように、状態コードの値は０に設定され得る。

成功的なＦＴＳ連携手順が進行すると、伝送トランスミッタと伝送レシーバは、Ｐ２Ｐグループ形成（ｆｏｒｍａｔｉｏｎ）プロセスを行うことができる。グループ形成プロセスを介して伝送トランスミッタ及び伝送レシーバのいずれか一方はグループクライアント（Ｃｌｉｅｎｔ）に設定され、他方はグループオーナー（Ｏｗｎｅｒ）に設定されてもよい。

Ｐ２Ｐグループが形成されると、伝送トランスミッタはＦＴＳセッションを開始し、ファイル伝送を開始することができる。

ＦＴＳセッションは、ピアデバイス間に構築されるＵＰｎＰセッションである。伝送トランスミッタは、伝送レシーバがＵＰｎＰデバイスアーキテクチャーを用いて主催したＷＦＤ ＦＴＳを探索することができる。

伝送トランスミッタは、伝送レシーバによって主催されるＷＦＤ ＦＴＳによって提供されるサービスを管理するために、ＵＰｎＰ制御点個体を用いることができる。ＵＰｎＰ制御点は、ファイル伝送セッションを管理するために、Ｗｉ−Ｆｉダイレクトサービスによって提供されるアクションを発動（ｉｎｖｏｋｅ）する。

Ｗｉ−Ｆｉダイレクトファイル伝送サービスは、ファイル伝送セッションの管理及び制御のためのＬ３メカニズムとしてＵＰｎＰサービスを利用することができる。ＵＰｎＰサービスは、機器によって支援される細部サービス特徴を探索するための選択的なサービス探索手順を提供することができる。ＵＰｎＰサービスは、伝送トランスミッタによって発動されるＵＰｎＰアクションを定義し、伝送レシーバがＦＴＳセッションを管理できるようにする。

図１７は、Ｌ２接続及びＬ３接続を含むＦＴＳセッションの流れ図である。

Ｌ２接続の確立過程については図１６を通じて説明したので、これについての詳細な説明は省略する。

伝送トランスミッタと伝送レシーバとの間に成功裏にＰ２Ｐ接続が行われると、伝送トランスミッタは、ＵＰｎＰデバイスアーキテクチャー別にサービス説明ドキュメントを検索することができる（ｒｅｔｒｉｅｖｅ）。伝送トランスミッタのＵＰｎＰデバイスアーキテクチャー制御点個体は、伝送レシーバによって主催される（ｈｏｓｔｅｄ）サービス（例えば、ＷＦＤＳ上のＵＰｎＰアクション）に加入（ｓｕｂｓｃｒｉｂｅ）することができる。

その後、伝送トランスミッタは、自身の識別情報及び伝送されるファイルのメタ情報を含むセッション生成アクション（ＣｒｅａｔｅＳｅｓｓｉｏｎ）を発動することができる。

セッション生成アクションを受信した伝送レシーバは、ユーザにセッション生成アクションが受信されたことを知らせるための情報をディスプレイすることができる。ユーザがセッション生成を受諾すると、伝送レシーバは、セッションを識別するための固有の（ｕｎｉｑｕｅ）識別子を生成し、セッション生成アクションに対する応答として、セッションＩＤを伝送トランスミッタに伝送することができる。

なお、伝送レシーバは、生成されたセッションに割り当てられたセッションＩＤ及び生成されたセッションの状態情報を含む伝送状態可変イベント（Ｔｒａｎｓｐｏｒｔｓｔａｔｕｓ ｖａｒｉａｂｌｅ ｅｖｅｎｔ）を伝送トランスミッタに伝送することができる。伝送レシーバがセッション生成要求を受諾した場合、生成されたセッションの状態は伝送準備完了（Ｒｅａｄｙ_ｆｏｒ_ｔｒａｎｓｐｏｒｔ）に設定することができる。

伝送レシーバから、生成されたセッションが伝送準備完了の状態であることを知らせる伝送状態可変イベントを受信した伝送トランスミッタは、トランスポートチャネル構築を開始することができる。

その後、トランスポートチャネルが成功的に構築されると、伝送レシーバは、セッション状態を‘伝送中（ｔｒａｎｓｐｏｒｔｉｎｇ）’に変更して伝送状態可変イベントを伝送することができる。セッション状態が‘伝送中’であることを知らせる伝送状態可変イベントを受信した伝送トランスミッタは、ＨＴＴＰ ＰＵＴ要求を用いてファイルデータを伝送することができる。

サービス探索要求フレーム及びサービス探索応答フレームのフォーマット

サービス探索手順に用いられるサービス探索要求フレーム及びサービス探索応答フレームは、それぞれＡＮＱＰ（Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ Ｑｕｅｒｙ Ｐｒｏｔｏｃｏｌ）クエリ要求情報及びＡＮＱＰクエリ応答情報を含むことができる。

一例として、図１８及び図１９は、それぞれサービス探索要求フレーム及びサービス探索応答フレームのフォーマットを例示した図である。

図１８に例示したように、サービス探索要求フレームにはクエリデータがさらに含まれてもよい。このとき、クエリデータは、伝送トランスミッタの能力（ｃａｐａｂｉｌｉｔｉｅｓ）を代表するサービス情報要素を含むことができる。

図１９に例示したように、サービス探索応答フレームは応答データを含むことができる。応答フレームにはサービス情報が含まれてもよい。応答データに含まれ得るサービス情報の一例が、表８に記載されている。

表８を参照すると、応答データは、サービスプロトコルタイプフィールド、長さフィールド及びサービス情報フィールドを含むことができる。

応答データに含まれるサービス情報フィールドには、ＦＴＳのための様々な情報が含まれてもよい。一例として、表９は、サービス情報フィールドに含まれ得るフィールドを説明するための図表である。

表９に記述したように、サービス情報フィールドは、サービスバージョンフィールド、ＵＵＩＤフィールド、サービス状態フィールド、フレンドリ名フィールド、セッションＩＤフィールド及びサービスビットマップフィールドを含むことができる。

サービスバージョンフィールドは、伝送レシーバが支援するＦＴＳのバージョンを指示することができる。ＵＵＩＤフィールドは、伝送レシーバとして設定された機器のＵＵＩＤ（Ｕｎｉｖｅｒｓａｌｌｙ Ｕｎｉｑｕｅ Ｉｄｅｎｔｉｆｉｅｒ）を指示することができる。

サービス状態フィールドは、伝送サービスの現状態を指示する。一例として、表１０は、サービス状態フィールドの値に基づいた伝送サービスの状態を説明するための図表である。

フレンドリ名フィールドは、ユーザが伝送サービスを容易に識別するための文字列が含まれてもよい。伝送トランスミッタは、フレンドリ名フィールドで指示する文字列をディスプレイすることで、ユーザがファイル伝送対象となる伝送レシーバを識別できるようにすることができる。

セッションＩＤフィールドは、伝送サービスのために割り当てられたセッションＩＤを指示する。

サービスビットマップフィールドは、ＦＴＳを利用する機器のタイプ及び当該機器でのＦＴＳ利用可能性を指示することができる。表１１は、サービスビットマップフィールドを説明するための図表である。

表１０に記述したように、サービスビットマップフィールドの２ビットは、ＦＴＳを利用する機器のタイプを指示することができる。２ビットのいずれか一方は、当該機器が伝送トランスミッタであるか否かを指示し、他方は、当該機器が伝送レシーバであるか否かを指示することができる。一例として、２ビットの値がすべて１である場合、当該機器は伝送トランスミッタ及び伝送レシーバの両方として動作できることを指示するもので、２ビットの値がすべて０である場合、当該機器は、伝送トランスミッタ及び伝送レシーバとして動作できない、ＦＴＳを支援できない機器であることを指示するものであってもよい。

サービスビットマップフィールドの１ビットは、当該機器でのＦＴＳ利用可能性を指示するのに利用することができる。一例として、サービス探索応答フレームを伝送する時点にＦＴＳが利用不可能な場合、当該ビットは０に設定され、サービス探索応答フレームを伝送する時点にＦＴＳを利用できる場合、当該ビットは１に設定されてもよい。

再び図１９を参照すると、サービス探索応答フレームには状態コードフィールドも含まれてもよい。サービス探索要求フレームのクエリデータが指示するサービス情報が発見されない場合、状態コードフィールド（Ｓｔａｔｕｓ Ｃｏｄｅ ｆｉｅｌｄ）は、要求されたサービス情報を当該機器で利用できないことが指示され、応答値（Ｒｅｓｐｏｎｓｅ ｖａｌｕｅ）は空欄（ｅｍｐｔｙ）となり得る。

状態コードフィールドについての詳細な説明は、先に表７を参照して詳細に説明したので、これについての詳細な説明は省略する。

状態属性（Ｓｔａｔｕｓ Ａｔｔｒｉｂｕｔｅ）

サービス広告器及びサービス探索器で取り扱われる多数のフレームを区分するために、各フレームには状態属性フィールドが含まれてもよい。具体的に、ＧＯ交渉応答フレーム、ＧＯ交渉確認フレーム、Ｐ２Ｐ招待応答フレーム、Ｐ２Ｐ存在応答フレーム、（再）連携応答フレーム、プロビジョン探索要求フレーム及びプロビジョン探索応答フレームなどに状態属性フィールドが含まれてもよい。

一例として、表１２は、状態属性を説明するための図表である。

表１２に列挙した状態属性のうち探索サービスハッシュは、ＷＦＤＳを検索するためのプローブ要求フレームにおいて使用可能である。サービスハッシュ属性は、探索されなければならないサービス名の６オクテットの長さのハッシュアレイ（ａｒｒａｙ）を含む。サービスハッシュ属性の形式は表１３に記述している。ハッシュ値は、ＵＴＦ−８サービス名上にＳＨＡ−１の出力結果物から６オクテットのＬＳＢを抽出することによって構成可能である。

表１３に記述したように、プローブ要求フレームは、複数のサービスに対するハッシュ値を含むこともできる。ただし、プローブ要求フレームに複数のサービスに対するハッシュ値が含まれるといって、プローブ応答フレームにも複数のサービスに対する情報（例えば、サービス広告器が支援するサービスに対するハッシュ値又は広告ＩＤ）が含まれなければならないものではない。プローブ応答フレームには、プローブ要求フレームに含まれる複数のハッシュ値のうちサービス広告器で支援するサービスに対応するサービスの情報のみが含まれることで足りる。

表１２に列挙した状態属性のうちサービス事例データ情報は、プロビジョン探索要求フレームに含まれてもよい。サービス事例データ情報の属性は、ピアデバイス間に接続を確立するに先立ち、サービスの提案される事例（ｉｎｓｔａｎｃｅ）に関する具体的な情報を交換するために利用される。サービス事例データ情報の属性は表１４に記述している。

表１４に記述したサービス特定フィールドは、受信されるサービスセッションを受諾又は拒絶するか否かを決定しなければならないピアデバイスのための情報を含む。サービス特定フィールドは、サービス名に基づいて解釈されなければならない。

表１２に列挙した状態属性のうち接続能力情報は、プロビジョン探索要求フレーム及びプロビジョン探索応答フレームに含まれてもよい。接続能力情報の属性はＰ２Ｐデバイスの接続能力を含む。接続能力情報の属性に基づいて、Ｐ２Ｐグループでのグループオーナー及びグループクライアントが決定され得る。接続能力情報の属性は表１５に記述している。

表１５に記述した接続能力フィールドは、ピアデバイスがグループクライアントまたはグループオーナーとして設定可能であるか否かを指示することができる。表１６は、接続能力フィールドの値に基づいたピアデバイスの能力を記述した図表である。

表１６に記述したように、接続能力フィールドのいずれか１つのビットは、ピアデバイスがグループクライアント又はグループオーナーのいずれか一方として設定可能であることを指示し、他の１つのビットは、ピアデバイスがグループクライアントであるか、またはグループクライアントとしてのみ動作できることを指示することができる。さらに他の１つのビットは、ピアデバイスがグループオーナーであるか、またはグループオーナーとしてのみ動作できることを指示することができる。表１７は、列挙した３つのビットの値に基づいたマスキング結果を記述した図表である。

表１２に列挙した状態属性のうち広告ＩＤ情報属性は、ピアデバイスの特定のＷＦＤＳに対するＡＳＰセッション確立を要求するためにプロビジョン探索要求フレームにおいて使用可能である。広告ＩＤ情報属性は、プロビジョン探索応答フレームにおいても使用可能である。広告ＩＤ情報属性は表１８に記述している。

広告ＩＤ情報属性に含まれる広告ＩＤは、早期連携（ｐｒｅ−ａｓｓｏｃｉａｔｉｏｎ）探索の間に発見されるサービスのＵ３２値であり、サービス事例属性から獲得されるものであってもよい。

表１２に列挙した状態属性のうちの広告されたサービス情報属性は、ＷＦＤＳの特定の（ｐａｒｔｉｃｕｌａｒ）事例（ｉｎｓｔａｎｃｅ）であることを識別するために、プローブ応答フレームにおいて使用可能である。広告されたサービス情報属性は、サービスハッシュ属性を含むプローブ要求フレームの応答として伝送することができる。サービス情報属性は表１９に記述している。

表１９に記述した広告されたサービスデスクリプタのフォーマットは、表２０の通りである。

表２０に例示したように、広告されたサービスデスクリプタには広告ＩＤが含まれてもよい。サービス広告器は、サービスハッシュ値を含むプローブ要求フレームの受信に対する応答として、サービスハッシュ値にマッチングされるサービスの広告ＩＤを含むプローブ応答フレームを伝送することができる。

上述した実施例で説明する本発明の例示的な方法は、説明の簡明さのために動作のシリーズとして表現されているが、これは、段階が行われる順序を制限するためのものではなく、必要な場合には、それぞれの段階が同時にまたは異なる順序で行われてもよい。また、本発明で提案する方法を具現するために、図面で例示する全ての段階が必ず必要なものではない。

また、本発明に係る方法において、前述した本発明の様々な実施例で説明した事項は独立して適用されたり、又は２つ以上の実施例が同時に適用されるように具現されてもよい。

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

無線デバイス１０は、プロセッサ１１、メモリ１２、送受信器１３を備えることができる。送受信器１３は、無線信号を送信／受信することができ、例えば、ＩＥＥＥ ８０２システムに基づく物理層を具現することができる。プロセッサ１１は、送受信器１３と電気的に接続されて、ＩＥＥＥ ８０２システムに基づく物理層及び／又はＭＡＣ層を具現することができる。また、プロセッサ１１は、前述した本発明の様々な実施例に係るアプリケーション、サービス、ＡＳＰ層のうちの１つ以上の動作を行うように構成されてもよい。また、前述した本発明の様々な実施例に係る無線デバイスの動作を具現するモジュールがメモリ１２に格納され、プロセッサ１１によって実行されてもよい。メモリ１２は、プロセッサ１１の内部に含まれるか、またはプロセッサ１１の外部に設置されて、プロセッサ１１と公知の手段によって接続されてもよい。

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

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

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

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

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

上述したような本発明の様々な実施形態は、ＩＥＥＥ ８０２．１１システムを中心に説明したが、様々な移動通信システムに同じ方式で適用されてもよい。

Claims (15)

1. Ｗｉ−Ｆｉダイレクトサービスを支援する第１無線デバイスが行うサービス探索方法であって、
   前記第１無線デバイスが望む所定のサービスを支援するデバイスを探索するために、プローブ要求フレームを伝送するステップであって、前記プローブ要求フレームは、前記所定のサービスの第１サービス名をハッシュ形態へ変換することにより取得された第１ハッシュ値を含む、ステップと、
   前記第１ハッシュ値にマッチングしたサービスの広告識別子を含むプローブ応答フレームを第２無線デバイスから受信するステップと、
   前記所定のサービスの前記第１サービス名を含むサービス探索要求フレームを、前記第２無線デバイスに伝送するステップと、
   サービス状態情報を含むサービス探索応答フレームを前記第２無線デバイスから受信するステップと、
   を含み、
   前記サービス状態情報は、前記第２無線デバイスにおいて前記所定のサービスが利用可能であるか否かを指示するために利用される、サービス探索実行方法。
2. 前記サービス探索応答フレームは、前記第１サービス名と同一または前記第１サービス名をプレフィックスとして含む第２サービス名を含む、請求項１に記載のサービス探索実行方法。
3. 前記第２無線デバイスにおいて前記所定のサービスが利用可能な場合、
   前記第１無線デバイスから前記第２無線デバイスに、サービス連携を要求するサービス連携要求フレームを伝送するステップをさらに含む、請求項１に記載のサービス探索実行方法。
4. 前記所定のサービスが伝送サービスである場合、
   前記サービス連携要求フレームは、伝送されるファイルに対する伝送サービスメタ情報を含む、請求項３に記載のサービス探索実行方法。
5. 前記伝送サービスメタ情報は、伝送される前記ファイルの数、伝送されるファイルのサイズ、伝送されるファイルの名の少なくとも一つを含む、請求項４に記載のサービス検索実行方法。
6. 前記第２無線デバイスは、
   前記第２無線デバイスが前記第１無線デバイスのサービス要求を自動受諾（ａｕｔｏ ａｃｃｅｐｔ）するように設定されているか否かによって、サービス連携の進行においてユーザの受諾を待つか否かを決定する、請求項３に記載のサービス探索実行方法。
7. 前記プローブ応答フレームは、前記所定のサービスに対するサービス情報が存在するか否かを指示するサービス情報指示フィールド、及び前記プローブ応答フレームが伝送される時点で、前記第２無線デバイスにおいて、前記所定のサービスが利用可能であるか否かを指示するサービス状態フィールドのうち少なくとも１つを含む、請求項１に記載のサービス探索実行方法。
8. 前記プローブ要求フレームは、前記第１無線デバイスが検索しようとする複数のサービスのそれぞれの複数のハッシュ値を含み、
   前記プローブ応答フレームは、前記第２無線デバイスが支援するサービスのうち前記複数のハッシュ値とマッチングする少なくとも１つのサービスの広告識別子を含む、請求項１に記載のサービス探索実行方法。
9. 前記第１無線デバイスが、前記所定のサービスの検索結果を報告するための検索結果イベントを生成するステップを含み、
   前記検索結果イベントは、前記第２無線デバイスにおいて前記所定のサービスを利用できるか否かを指示するためのサービス状態パラメータを含む、請求項１に記載のサービス探索実行方法。
10. 前記第１無線デバイスはサービス探索器であり、前記第２無線デバイスはサービス広告器である、請求項１に記載のサービス探索実行方法。
11. Ｗｉ−Ｆｉダイレクトサービスを支援する第１無線デバイスが行うサービス広告方法であって、
    第２無線デバイスが望む所定のサービスを支援するか否かを問い合わせるプローブ要求フレームを前記第２無線デバイスから受信するステップであって、前記プローブ要求フレームは、前記所定のサービスの第１サービス名をハッシュ形態へ変換することにより取得された第１ハッシュ値を含む、ステップと、
    前記所定のサービスを支援する場合、前記第２無線デバイスにプローブ応答フレームを伝送するステップであって、前記プローブ応答フレームは前記第１ハッシュ値とマッチングしたサービスの広告識別子を含む、ステップと、
    前記所定のサービスの前記第１サービス名を含むサービス探索要求フレームを前記第２無線デバイスから受信するステップと、
    前記第２無線デバイスに、サービス状態情報を含むサービス探索応答フレームを伝送するステップと、
    を含み、
    前記サービス状態情報は、前記第１無線デバイスにおいて前記所定のサービスが利用可能であるか否かを指示するために利用される、サービス広告実行方法。
12. 前記第１無線デバイスは、前記第１無線デバイスにおいて前記所定のサービスの利用可能性が変更される場合、前記所定のサービスの利用可能性が変更されたことを示すサービス状態変更メソッドを呼び出す、請求項１１に記載のサービス広告実行方法。
13. 前記状態変更メソッドは、前記所定のサービスの広告識別子、及び前記所定のサービスの変更された利用可能性を示すサービス状態情報を含む、請求項１２に記載のサービス広告実行方法。
14. サービス探索器としてＷｉ−Ｆｉダイレクトサービス（ＷＦＤＳ）を支援する無線デバイスであって、
    送受信器と、
    プロセッサとを含み、
    前記プロセッサは、前記サービス探索器が望む所定のサービスを支援するデバイスを探索するためのプローブ要求フレームを伝送するように前記送受信器を制御し、
    前記プローブ要求フレームは、前記所定のサービスの第１サービス名をハッシュ形態へ変換することにより取得された第１ハッシュ値を含み、
    前記プロセッサは、前記第１ハッシュ値にマッチングしたサービスの広告識別子を含むプローブ応答フレームをサービス広告器から前記送受信器が受信するように制御し、
    前記プロセッサは、前記所定のサービスの前記第１サービス名を含むサービス検索要求フレームを前記サービス広告器に伝送するように前記送受信器を制御し、
    前記プロセッサは、サービス状態情報を含むサービス検索応答フレームを前記サービス広告器から受信するように前記送受信器を制御するようにさらに設定され、
    前記サービス状態情報は、前記サービス広告器において前記所定のサービスが利用可能であるか否かを指示するために利用される、無線デバイス。
15. サービス広告器としてＷｉ−Ｆｉダイレクトサービスを支援する無線デバイスであって、
    送受信器と、
    プロセッサとを含み、
    前記プロセッサは、サービス探索器が望む所定のサービスを支援するか否かを問い合わせるプローブ要求フレームを前記サービス探索器から受信するように前記送受信器を制御し、
    前記プローブ要求フレームは、前記所定のサービスの第１サービス名をハッシュ形態へ変換することにより取得された第１ハッシュ値を含み、
    前記プロセッサは、前記所定のサービスが支援される時、プローブ応答フレームを前記サービス検索器に伝送するように前記送受信器を制御し、
    前記プロセッサは、前記所定のサービスの前記第１サービス名を含むサービス探索要求フレームを前記サービス探索器から受信するように前記送受信器を制御し、
    前記プロセッサは、サービス状態情報を含むサービス探索応答フレームを前記第２無線デバイスに伝送するように前記送受信器を制御するように設定し、
    前記サービス状態情報は、前記サービス広告器において前記所定のサービスが利用可能であるか否かを指示するために利用される、無線デバイス。