JP6294351B2 - 無線通信システムにおけるサービス転換方法及び装置 - Google Patents

Description

以下の説明は、無線通信システムに関し、より具体的には、無線通信システムにおいてサービスを転換する方法及び装置に関する。

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

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

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

ＷＦＤＳの従来技術によると、各ＷＦＤＳ支援デバイス間でサービスを行う方案が設けられている。しかし、各ＷＦＤＳ支援デバイス間で多数のサービスが使用可能である場合、一つのサービスを行う途中で他のサービスに転換する方案は定義されていない。

本発明は、ＷＦＤＳシステムでサービスを途切れなく転換したり、元のサービスに復帰する方案を提供することを目的とする。具体的に、本発明では、途切れないサービス転換を提供するためのＷＦＤＳデバイスのＡＳＰ制御方案または管理方案を提供することを目的とする。

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

前記の技術的課題を解決するために、本発明の一実施例に係るＷｉ―Ｆｉダイレクトサービスを支援する第１の無線デバイスでセッションをセットアップする方法は、第１のサービスに対するセッションを生成（ｃｒｅａｔｅ）するために、前記第１の無線デバイスと第２の無線デバイスとの間のプロビジョン発見（ｐｒｏｖｉｓｉｏｎ ｄｉｓｃｏｖｅｒｙ）過程を含む、前記第１の無線デバイスと前記第２の無線デバイスとの間の連結（ｃｏｎｎｅｃｔｉｏｎ）をセットアップする段階と、及び第２のサービスに対するセッションを生成するために、前記第１の無線デバイスから前記第２の無線デバイスにセッション要求（ＲＥＱＵＥＳＴ＿ＳＥＳＳＩＯＮ）メッセージを伝送する段階と、を含むことができる。前記第２のサービスに対するセッション情報は、前記セッション要求要求メッセージに含ませることができる。

前記の技術的課題を解決するために、本発明の他の実施例に係るＷｉ―Ｆｉダイレクトサービスを支援する第２の無線デバイスでセッションをセットアップする方法は、第１のサービスに対するセッションを生成するために、前記第１の無線デバイスと第２の無線デバイスとの間のプロビジョン発見過程を含む、前記第１の無線デバイスと前記第２の無線デバイスとの間の連結をセットアップする段階と、及び第２のサービスに対するセッションを生成するために、前記第２の無線デバイスで前記第１の無線デバイスからセッション要求（ＲＥＱＵＥＳＴ＿ＳＥＳＳＩＯＮ）メッセージを受信する段階と、を含むことができる。前記第２のサービスに対するセッション情報は、前記セッション要求メッセージに含ませることができる。

前記の技術的課題を解決するために、本発明の更に他の実施例に係るＷｉ―Ｆｉダイレクトサービスを支援してセッションセットアップを行う第１の無線デバイスは、送受信機と、プロセッサと、を含むことができる。前記プロセッサは、第１のサービスに対するセッションを生成するために、前記第１の無線デバイスと第２の無線デバイスとの間のプロビジョン発見過程を含む、前記第１の無線デバイスと前記第２の無線デバイスとの間の連結をセットアップするように設定することができる。前記プロセッサは、第２のサービスに対するセッションを生成するために、前記第１の無線デバイスから前記第２の無線デバイスにセッション要求（ＲＥＱＵＥＳＴ＿ＳＥＳＳＩＯＮ）メッセージを伝送するように前記送受信機を制御するように設定することができる。前記第２のサービスに対するセッション情報は、前記セッション要求メッセージに含ませることができる。

前記の技術的課題を解決するために、本発明の更に他の実施例に係るＷｉ―Ｆｉダイレクトサービスを支援してセッションセットアップを行う第２の無線デバイスは、送受信機と、プロセッサと、を含むことができる。前記プロセッサは、第１のサービスに対するセッションを生成するために、前記第１の無線デバイスと第２の無線デバイスとの間のプロビジョン発見過程を含む、前記第１の無線デバイスと前記第２の無線デバイスとの間の連結をセットアップするように設定することができる。前記プロセッサは、第２のサービスに対するセッションを生成するために、前記第２の無線デバイスで前記第１の無線デバイスからセッション要求（ＲＥＱＵＥＳＴ＿ＳＥＳＳＩＯＮ）メッセージを受信するように前記送受信機を制御するように設定することができる。前記第２のサービスに対するセッション情報は、前記セッション要求メッセージに含ませることができる。

本発明に係る各実施例において、以下の事項を共通的に適用することができる。

前記第１の無線デバイスが第２の無線デバイスとの連結を有している場合、前記第２のサービスに対するセッション生成過程で、プロビジョン発見過程は省略可能である。

前記第１のサービスに対するセッション情報は、プロビジョン発見要求メッセージに含ませることができる。

前記連結をセットアップする前に、デバイス発見過程及びサービス発見過程のうち一つ以上を行うことができる。

前記デバイス発見過程は、前記第１の無線デバイスから前記第２の無線デバイスへのプローブ要求フレーム送信、及び前記第１の無線デバイスにおける前記第２の無線デバイスからのプローブ応答フレーム受信を含むことができる。前記プローブ要求フレーム及び前記プローブ応答フレームのうち一つ以上には、前記第１のサービス及び第２のサービスに対する複数のサービス名称及び複数のサービスハッシュ値のうち一つ以上を含ませることができる。

前記連結をセットアップする段階は、Ｐ２Ｐグループ形成過程をさらに含むことができる。

前記第１の無線デバイスのＡＳＰ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｉｃｅ Ｐｌａｔｆｏｒｍ）が前記第１の無線デバイスのサービス層からＣｏｎｎｅｃｔＳｅｓｓｉｏｎメソッド（Ｍｅｔｈｏｄ）を受信する場合、前記ＡＳＰは、サービスシーカー（ｓｅｅｋｅｒ）として新たなＡＳＰ―セッションを生成し、初期（Ｉｎｉｔｉａｔｅ）ステート（状態）に遷移することができる。

前記セッション要求（ＲＥＱＵＥＳＴＥＤ＿ＳＥＳＳＩＯＮ）メッセージに応答するセッション追加（ＡＤＤＥＤ＿ＳＥＳＳＩＯＮ）メッセージを前記第２の無線デバイスから受信する場合、前記第１の無線デバイスのＡＳＰは、前記初期ステートから開放（Ｏｐｅｎ）ステートに遷移することができる。

前記第１の無線デバイスと前記第２の無線デバイスとの間の連結が存在する場合、前記第１の無線デバイスのＡＳＰはグループ形成完了（ＧｒｏｕｐＦｏｒｍａｔｉｏｎＣｏｍｐｌｅｔｅ）ステート（状態）に遷移することができる。または、前記第１の無線デバイスと前記第２の無線デバイスとの間の連結が存在しない場合、前記第１の無線デバイスのＡＳＰは、サービス要求伝送（ＳｅｒｖｉｃｅＲｅｑｕｅｓｔＳｅｎｔ）ステート（状態）に遷移することができる。

前記セッション要求（ＲＥＱＵＥＳＴＥＤ＿ＳＥＳＳＩＯＮ）メッセージに応答するセッション拒絶（ＲＥＪＥＣＴＥＤ＿ＳＥＳＳＩＯＮ）メッセージを前記第２の無線デバイスから受信する場合、前記第１の無線デバイスのＡＳＰは、前記初期ステートから閉鎖（Ｃｌｏｓｅｄ）ステート（状態）に遷移することができる。

前記第２のサービスに対するセッションが生成される場合、前記第１のサービスに対するセッションに対して割り当てられたポートは解除され得る。

前記第１のサービスは、伝送、プレイ、ディスプレイ、プリント、及びサードパーティーアプリケーションを支援するためのサービスのうちいずれか一つであり得る。前記第２のサービスは、前記第１のサービス以外の他のサービスであり得る。

前記第１の無線デバイスはサービスシーカーで、前記第２の無線デバイスはサービスアドバタイザー（ａｄｖｅｒｔｉｓｅｒ）であり得る。

前記第１の無線デバイスと前記第２の無線デバイスとの間の連結は、Ｐ２Ｐ（Ｐｅｅｒ―ｔｏ―Ｐｅｅｒ）連結またはＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）連結であり得る。

前記第２の無線デバイスのＡＳＰが前記第１の無線デバイスから前記セッション要求（ＲＥＱＵＥＳＴ＿ＳＥＳＳＩＯＮ）メッセージを受信する場合、前記ＡＳＰは、サービスアドバタイザーとして新たなＡＳＰ―セッションを生成し、要求される（Ｒｅｑｕｅｓｔｅｄ）ステート（状態）に遷移することができる。

前記第１の無線デバイスと前記第２の無線デバイスとの間の連結が存在する場合、前記第２の無線デバイスのＡＳＰが前記第１の無線デバイスから前記セッション要求（ＲＥＱＵＥＳＴ＿ＳＥＳＳＩＯＮ）メッセージを受信すると、前記第２の無線デバイスのＡＳＰにより、前記第２の無線デバイスのユーザーまたはアプリケーションに前記セッション要求メッセージの受信を知らせることができる。また、前記セッション要求に対する受諾（ａｃｃｅｐｔ）または拒絶（Ｒｅｊｅｃｔ）を示す情報を前記ユーザーまたは前記アプリケーションから受信することができる。

前記第２の無線デバイスのＡＳＰが前記第１の無線デバイスから前記セッション要求（ＲＥＱＵＥＳＴ＿ＳＥＳＳＩＯＮ）メッセージを受信した場合、サービス要求受信（ＳｅｒｖｉｃｅＲｅｑｕｅｓｔＲｅｃｅｉｖｅｄ）状態に遷移することができる。ここで、前記第１の無線デバイスと前記第２の線デバイスとの間の連結が存在すると、前記第２の無線デバイスのＡＳＰは、前記サービス要求受信（ＳｅｒｖｉｃｅＲｅｑｕｅｓｔＲｅｃｅｉｖｅｄ）ステート（状態）から開放（Ｏｐｅｎ）ステート（状態）に遷移することができる。または、前記第１の無線デバイスと前記第２の無線デバイスとの間の連結が存在しない場合、前記第２の無線デバイスのＡＳＰは、前記サービス要求受信（ＳｅｒｖｉｃｅＲｅｑｕｅｓｔＲｅｃｅｉｖｅｄ）ステート（状態）からグループ形成開始（ＧｒｏｕｐＦｏｒｍａｔｉｏｎＳｔａｒｔｅｄ）ステート（状態）に遷移することができる。

上述した本発明に対する一般的な説明と後述する詳細な説明は、例示的なものであって、請求項に記載の発明に対する追加的な説明のためのものである。

本発明によると、ＷＦＤＳシステムでサービスを途切れなく転換したり、元のサービスに復帰する方法及び装置を提供することができる。具体的には、本発明では、途切れないサービス転換を提供するためのＷＦＤＳデバイスのＡＳＰ制御方案または管理方法及び装置を提供することができる。

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

ＩＥＥＥ ８０２．１１システムの例示的な構造を示す図である。 Ｗｉ―Ｆｉダイレクトネットワークを例示する図である。 Ｗｉ―Ｆｉダイレクトネットワークを構成する過程を説明するための図である。 近隣発見過程を説明するための図である。 Ｗｉ―Ｆｉダイレクトネットワークの新たな様相を説明するための図である。 Ｗｉ―Ｆｉダイレクト通信のためのリンクを設定する方法を説明するための図である。 Ｗｉ―Ｆｉダイレクトを行っている通信グループに参加（ａｓｓｏｃｉａｔｉｏｎ）する方法を説明するための図である。 Ｗｉ―Ｆｉダイレクト通信のためのリンクを設定する方法を説明するための図である。 Ｗｉ―Ｆｉダイレクト通信グループに参加するリンクを設定する方法を説明するための図である。 ＷＦＤＳフレームワーク構成要素を説明するための図である。 ＷＦＤＳの動作を説明するための図である。 ＷＦＤＳにおけるＡＳＰセッションセットアップシーケンスを説明するための図である。 本発明の一実施例に係るサービス転換を説明するための図である。 本発明の一実施例に係るサービス転換を説明するための図である。 本発明の一実施例に係るサービス転換を説明するための図である。 本発明の一実施例に係るサービス転換を説明するための図である。 本発明の追加的な実施例に係るサービス転換を説明するための図である。 本発明で提案するサービスハンドオーバーを説明するための図である。 本発明の追加的な実施例に係るサービスハンドオーバー過程を説明するための図である。 本発明の一実施例に係るサービスハンドオーバー過程を説明するための図である。 本発明に係るサービスハンドオーバーの追加的な例を説明するための図である。 本発明に係るＡＳＰ―セッションに対するステートマシンを説明するための図である。 サービスシーカーに対するサブ―ステートマシンを説明するための図である。 サービスアドバタイザーに対するサブ―ステートマシンを説明するための図である。 本発明の一実施例に係る無線デバイスの構成を示すブロック図である。

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

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

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

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

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

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

ＷＬＡＮシステムの構造

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

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

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

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

さらに、図１では、分配システム（Ｄｉｓｔｒｉｂｕｔｉｏｎ Ｓｙｓｔｅｍ：ＤＳ）、分配システム媒体（Ｄｉｓｔｒｉｂｕｔｉｏｎ Ｓｙｓｔｅｍ Ｍｅｄｉｕｍ：ＤＳＭ）、アクセスポイント（Ａｃｃｅｓｓ Ｐｏｉｎｔ：ＡＰ）などの構成要素について図示する。

ＷＬＡＮで直接的なステーション―対―ステーションの距離は、ＰＨＹ性能によって制限され得る。いずれかの場合は、このような距離の限界が十分であり得るが、場合に応じては、より遠い距離のステーション間の通信が必要であり得る。拡張されたカバレッジを支援するために分配システム（ＤＳ）を構成することができる。

ＤＳは、各ＢＳＳが互いに連結される構造を意味する。具体的には、図１に示すように、ＢＳＳが独立的に存在する代わりに、複数のＢＳＳで構成されたネットワークの拡張された形態の構成要素としてＢＳＳが存在する場合もある。

ＤＳは、論理的な概念であり、分配システム媒体（ＤＳＭ）の特性によって特定することができる。これと関して、ＩＥＥＥ ８０２．１１標準では無線媒体（Ｗｉｒｅｌｅｓｓ Ｍｅｄｉｕｍ：ＷＭ）と分配システム媒体（ＤＳＭ）を論理的に区分している。それぞれの論理的媒体は、異なる目的のために使用され、異なる構成要素によって使用される。ＩＥＥＥ ８０２．１１標準の定義では、このような各媒体が同一のものと制限することもなく、異なるものと制限することもない。このように複数の媒体が論理的に異なるという点で、ＩＥＥＥ ８０２．１１ ＬＡＮ構造（ＤＳ構造または他のネットワーク構造）の柔軟性を説明することができる。すなわち、ＩＥＥＥ ８０２．１１ ＬＡＮ構造は多様に具現することができ、それぞれの具現例の物理的な特性によって独立的に該当のＬＡＮ構造を特定することができる。

ＤＳは、複数のＢＳＳのシームレス（ｓｅａｍｌｅｓｓ）統合を提供し、目的地へのアドレスを取り扱うのに必要な論理的サービスを提供することによって移動機器を支援することができる。

ＡＰは、関連付けられた各ＳＴＡに対してＷＭを通じてＤＳへのアクセスを可能にし、ＳＴＡ機能性を有するエンティティ（ｅｎｔｉｔｙ）を意味する。ＡＰを通じてＢＳＳとＤＳとの間のデータ移動を行うことができる。例えば、図１で示すＳＴＡ２及びＳＴＡ３は、ＳＴＡの機能性を有しながら、関連付けられた各ＳＴＡ（ＳＴＡ１及びＳＴＡ４）をＤＳにアクセスさせる機能を提供する。また、全てのＡＰは、基本的にＳＴＡに該当するので、全てのＡＰはアドレス可能なエンティティである。ＷＭ上での通信のためにＡＰによって使用されるアドレスとＤＳＭ上での通信のためにＡＰによって使用されるアドレスは、必ずしも同一である必要はない。

ＡＰと関連付けられた各ＳＴＡのうち一つからそのＡＰのＳＴＡアドレスに送信されるデータは、常に非制御ポート（ｕｎｃｏｎｔｒｏｌｌｅｄ ｐｏｒｔ）で受信され、ＩＥＥＥ ８０２．１Ｘポートアクセスエンティティによって処理され得る。また、制御ポート（ｃｏｎｔｒｏｌｌｅｄ ｐｏｒｔ）が認証されると、送信データ（またはフレーム）はＤＳに伝達され得る。

層構造

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

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

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

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

無線ＬＡＮの進化

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

図８（ａ）に示すように、第２のＳＴＡ（８２０、以下、Ｂという）は、既存のＷＦＤ通信においてグループオーナーとして動作中にある。既存のＷＦＤ通信においてグループクライアント８３０とＷＦＤ通信中にある場合、Ｂ８２０を発見した、ＷＦＤ通信を行っていない第１のＳＴＡ（８１０、以下、Ａという）が、Ｂ８２０との新たなＷＦＤ通信のためにリンク設定を試みる。この場合、Ｂ８２０がリンク設定を受諾した場合、Ａ８１０とＢ８２０との間の新たなＷＦＤ通信リンクが設定され、Ａ８１０は、既存のＢ８２０のＷＦＤグループのクライアントとして動作することになる。このような場合、Ａ８１０がＢ８２０のＷＦＤ通信グループに参加した場合となる。Ａ８１０は、グループオーナーであるＢ８２０とのみＷＦＤ通信を行うことができ、Ａ８１０と既存のＷＦＤ通信のクライアント８３０とのＷＦＤ通信は支援されないこともある。Ｗｉ―ＦｉダイレクトのＰ２Ｐグループケーパビリティのうちイントラ―ＢＳＳオプションが活性化（またはオンに設定）される場合であると、Ａ８１０と既存のＷＦＤ通信のクライアント８３０との間のＷＦＤ直接通信（すなわち、Ｗｉ―ＦｉダイレクトＢＳＳ内での各クライント間の直接通信）を行うこともできる。

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

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

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

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

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

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

ＡＳＰは、共通共有プラットフォーム（ｃｏｍｍｏｎ ｓｈａｒｅｄ ｐｌａｔｆｏｒｍ）であり、その上位のアプリケーション（Ａｐｐｌｉｃａｔｉｏｎ）層とその下位のＷｉ―Ｆｉダイレクト層との間でセッション（ｓｅｓｓｉｏｎ）管理、サービスの命令処理、ＡＳＰ間の制御及び保安機能を行う。

ＡＳＰの上位にはサービス（Ｓｅｒｖｉｃｅ）層が定義される。サービス層は、用途（ｕｓｅ ｃａｓｅ）特定サービスを含む。ＷＦＡでは、４個の基本サービスである伝送（Ｓｅｎｄ）、プレイ（Ｐｌａｙ）、ディスプレイ（Ｄｉｓｐｌａｙ）、プリント（Ｐｒｉｎｔ）サービスを定義する。また、イネーブル（Ｅｎａｂｌｅ）ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）は、基本サービスの他に、サードパーティー（３ｒｄ ｐａｒｔｙ）アプリケーションを支援する場合にＡＳＰ共通プラットフォームを利用できるようにするために定義される。

図１０では、サービスの例示として、伝送、プレイ、ディスプレイ、プリント、またはサードパーティーアプリケーションで定義するサービスなどを図示するが、本発明の適用範囲がこれに制限されることはない。例えば、本文書で「サービス」という用語は、前記伝送、プレイ、ディスプレイ、プリント、またはサードパーティーアプリケーションで定義するサービスの他にも、Ｗｉ―Ｆｉシリアルバス（Ｗｉ―Ｆｉ Ｓｅｒｉａｌ Ｂｕｓ：ＷＳＢ）、Ｗｉ―Ｆｉドッキング（Ｗｉ―Ｆｉ Ｄｏｃｋｉｎｇ）、及び隣接認知ネットワーク（Ｎｅｉｇｈｂｏｒ Ａｗａｒｅｎｅｓｓ Ｎｅｔｗｏｒｋｉｎｇ：ＮＡＮ）を支援するためのサービスのうちいずれか一つであってもよい。

伝送（Ｓｅｎｄ）は、二つのＷＦＤＳデバイス間のファイル伝送を行えるサービス及びアプリケーションを意味する。プレイ（Ｐｌａｙ）は、二つのＷＦＤＳデバイス間ＤＬＮＡ（Ｄｉｇｉｔａｌ Ｌｉｖｉｎｇ Ｎｅｔｗｏｒｋ Ａｌｌｉａｎｃｅ）基盤のオーディオ／ビデオ（Ａ／Ｖ）、写真、音楽などを共有またはストリーミングするサービス及びアプリケーションを意味する。プリント（Ｐｒｉｎｔ）は、文書、写真などのコンテンツを有しているデバイスとプリンターとの間での文書、写真出力を可能にするサービス及びアプリケーションを意味する。ディスプレイ（Ｄｉｓｐｌａｙ）は、ＷＦＡのミイラキャスト（Ｍｉｒａｃａｓｔ）ソースとシンクとの間の画面共有を可能にするサービス及びアプリケーションを意味する。

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

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

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

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

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

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

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

ユーザーがデバイスＡとデバイスＢとの間でサービスＸを利用しようとする場合、それぞれのデバイス上の各ＡＳＰは、サービスＸ専用のＡＳＰ―セッションをデバイス間に生成する。その後、ユーザーがサービスＹを利用しようとする場合、該当のサービスのための新たなＡＳＰ―セッションが樹立（ｅｓｔａｂｌｉｓｈ）される。

図１２は、ＷＦＤＳでのＡＳＰセッションセットアップシーケンスを説明するための図である。

ＷＦＤＳでは、二つのピアデバイス間の動作を定義するにおいて、そのうちいずれかのデバイスはサービスアドバタイザーとしての役割をし、他のデバイスはサービスシーカーとしての役割をすることができる。サービスシーカーは、サービスアドバタイザーを発見（ｄｉｓｃｏｖｅｒ）し、所望のサービスを探した場合、サービスアドバタイザーとの連結を要求することもできる。図１２の例示では、デバイスＡがサービスアドバタイザーとしての役割をし、デバイスＢがサービスシーカーとしての役割をする場合を例示的に示す。

図１２のＡＳＰセッションセットアップ動作について簡略に説明すると、いずれかのＷＦＤＳデバイスの特定サービスが他のＷＦＤＳデバイス及びサービスを探索し、サービスを要求し、Ｗｉ―Ｆｉダイレクト連結を樹立し、アプリケーションが動作する過程を示す。

図１２において、デバイスＡは、自身のサービスをアドバタイズ（ａｄｖｅｒｔｉｓｅ）し、他のデバイスが該当のサービスを探すことができるように待機することができる。デバイスＡのＡＳＰは、サービス層から提供されるＡｄｖｅｒｔｉｓｅｍｅｎｔ（）メソッドに含まれる情報に基づいて他のデバイスに応答することができる。

デバイスＢは、サービスを探して開始しようとするデバイスである。デバイスＢは、上位アプリケーションまたはユーザーの要求に応じてサービスを支援するデバイスを探す過程を行う。デバイスＢのサービス層は、アプリケーション層からサービスを使用するという（Ｕｓｅ Ｓｅｒｖｉｃｅ）意図を示す情報を受信すると、ＳｅｅｋＳｅｒｖｉｃｅ（）メソッドに必要な情報を含ませてＡＳＰに伝達することができる。

これによって、デバイスＢのＡＳＰは、他のデバイスにプローブ要求フレームを伝送することができる。このとき、プローブ要求フレーム内に自身が探そうとするサービスまたは自身が支援可能なサービスのサービス名称（ｓｅｒｖｉｃｅ ｎａｍｅ）をハッシュ（ｈａｓｈ）形態で含ませて要求する。

プローブ要求フレームを受信したデバイスＡは、ハッシュマッチング（ｈａｓｈ ｍａｔｃｈｉｎｇ）を試み、ハッシュ値に該当するサービスを支援する場合、プローブ応答フレームをデバイスＢに伝送することができる。プローブ応答フレーム内には、サービス名称、アドバタイズメントＩＤ値などを含ませることができる。

このようなプローブ要求／応答フレームを取り交わす過程は、デバイスＡとＢが互いにＷＦＤＳを支援するデバイスということと、各自が支援するサービスが何かを知ることができるデバイス探索過程と称することができる。

さらに、デバイスＡとＢは、Ｐ２Ｐサービス発見過程を通じて特定サービスに対する具体的な事項に対する情報を取り交わすことができる。例えば、サービス名称（複数のサービスに対する支援有無を探索する場合は、複数のサービス名称）、サービス情報要求などの情報がサービス発見要求メッセージを通じてデバイスＢからデバイスＡに伝達され得る。これに対して、デバイスＡはサービス情報マッチングを行い、マッチングされる場合は、該当のサービスを提供できるとデバイスＢに知らせることができる。例えば、サービス発見応答メッセージには、サービス名称、アドバタイズメントＩＤ、サービス状態（ｓｅｒｖｉｃｅ ｓｔａｔｕｓ）などの情報を含ませることができる。サービス状態情報は、サービスアドバタイザー側で遠隔デバイスから要求されるサービスが利用可能であるか否かを知らせる情報である。このようなサービス発見過程は、ＩＥＥＥ ８０２．１１ｕシステムで定義するＧＡＳ（Ｇｅｎｅｒｉｃ Ａｄｖｅｒｔｉｓｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）を使用して行うことができる。

デバイスＢのＡＳＰは、サービス層が要求したＳｅｅｋＳｅｒｖｉｃｅ（）メソッドによって要求された動作が完了すると、その結果（すなわち、ＳｅａｒｃｈＲｅｓｕｌｔ）をサービスを通じてアプリケーション及びユーザーに知らせることができる。

この時点まではＷｉ―Ｆｉダイレクトのグループが形成されない状態であり、ユーザーがサービスを選択し、サービスがセッション連結（すなわち、ＣｏｎｎｅｃｔＳｅｓｓｉｏｎ）を行う場合にＰ２Ｐグループ形成（ｇｒｏｕｐ ｆｏｒｍａｔｉｏｎ）が進行される。このとき、プロビジョン発見要求（Ｐｒｏｖｉｓｉｏｎ Ｄｉｓｃｏｖｅｒｙ Ｒｅｑｕｅｓｔ）及びプロビジョン発見応答（Ｐｒｏｖｉｓｉｏｎ Ｄｉｓｃｏｖｅｒｙ Ｒｅｓｐｏｎｓｅ）を通じて、セッション情報と連結ケーパビリティ（ｃｏｎｎｅｃｔｉｏｎ ｃａｐａｂｉｌｉｔｙ）情報が交換される。

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

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

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

デバイスＡのＡＳＰがＣｏｎｆｉｒｍＳｅｒｖｉｃｅ（）の伝達を受けると、後続（ｆｏｌｌｏｗ―ｏｎ）プロビジョン発見過程を行うことができる。すなわち、デバイスＡは、デバイスＢにプロビジョン発見要求メッセージを伝達することができる。これを後続プロビジョン発見過程と称することができる。このメッセージには、該当のサービスに対する状態が成功（ｓｕｃｃｅｓｓ）であることを示す情報と共に、サービス情報を含ませることができる。これによって、デバイスＢのＡＳＰは、サービス層にＣｏｎｅｃｔＳｔａｔｕｓイベントを伝達しながらサービス要求が収容されたことを知らせることができる。また、デバイスＢのＡＳＰは、プロビジョン発見応答メッセージを装置Ａに伝達することができ、これには、連結ケーパビリティ情報を含ませることができる。

Ｐ２Ｐプロビジョン発見過程が行われた後、ＧＯ交渉または招待過程を通じてＰ２Ｐグループが生成され、第２の層Ｌ２連結及びＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）連結が行われる。ＧＯ交渉過程についての詳細な説明は省略する。

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

これを受け取ったデバイスＡは、セッションが連結されたことを上位サービス／アプリケーションに知らせ、サービス層は、該当のセッションに対するポート（ｐｏｒｔ）情報を要求し、該当のセッションとポートをバインディング（ｂｉｎｄｉｎｇ）させることができる。これによって、ＡＳＰは、該当のポートを開放し（ＡＳＰは、ポートを防火壁（ｆｉｒｅｗａｌｌ）内で開放することができる）、ポートが準備されたことをサービス層に知らせることができる。サービス層は、セッションが準備されたこと（ＳｅｓｓｉｏｎＲｅａｄｙ（））をＡＳＰに知らせることができる。

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

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

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

これによって、デバイスＢのＡＳＰは、デバイスＡにＲＥＭＯＶＥ＿ＳＥＳＳＩＯＮメッセージを通じて連結されたサービスの終了を要求することができる。ＲＥＭＯＶＥ＿ＳＥＳＳＩＯＮメッセージには、アドバタイズメントＩＤ、ＭＡＣアドレス、セッションＩＤなどを含ませることができる。

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

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

図１２の例示を通じて、サービス要求がＰ２Ｐプロビジョン発見過程を用いて開始された場合、サービスシーカーとサービスアドバタイザーとの間のメッセージシーケンスに対して説明した。図１２の例示では、ａｕｔｏ＿ａｃｃｅｐｔがＦＡＬＳＥに設定される場合を仮定した（ａｕｔｏ＿ａｃｃｅｐｔがＴＲＵＥに設定されると、ＡＳＰは、サービスからのＣｏｎｆｉｒｍＳｅｒｖｉｃｅメソッドがなくても、全てのＡＳＰ―セッションサービス要求を収容するように動作することができる）。また、それぞれのＡＳＰは、現在の状態をＳｅｓｓｉｏｎＳｔａｔｕｓイベント及びＣｏｎｎｅｃｔｉｏｎＳｔａｔｕｓイベントを用いてサービスに知らせることができる。

サービス転換方案

二つのＷＦＤＳデバイスは、ＡＳＰコーディネーションプロトコルを通じてＡＳＰ―セッションの要求（ＲＥＱＵＥＳＴ）、追加（ＡＤＤ）、拒絶（ＲＥＪＥＣＴ）、除去（ＲＥＭＯＶＥ）などを行うことができる。ＡＳＰコーディネーションプロトコルは、ＷＦＤＳで定義した別途の制御プロトコルであり、ＡＳＰ間ＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）を通じて通信する方法を提供する。

従来技術では、二つのＷＦＤＳデバイスが共通に提供できるサービスの種類が多数である場合、一つのサービスを連結する方案に対しては定義しているが、互いに異なるサービス間の転換及び元のサービスへの復帰などのサービス間相互動作に対しては定義していない。

例えば、ＷＦＤＳデバイスＡとＷＦＤＳデバイスＢがいずれもプレイサービス及びディスプレイサービスを支援する場合、従来技術によると、独立的にそれぞれのサービスを行うことは定義されている。しかし、プレイとディスプレイとの間の転換及び復帰に関する内容は全く定義されていない。

プレイ（例えば、ＤＬＮＡ）は、Ａ／Ｖ、写真、音楽などのファイル基盤のローカルコンテンツを共有またはストリーミングするサービスである。ディスプレイサービス（例えば、ミイラキャスト）は、プレイサービスと類似するが、ファイル基盤のコンテンツの共有／ストリーミングではなく、送信側（ＴＸ）デバイスの画面を実時間でエンコーディングして受信（ＲＸ）デバイスに送るスクリーンミラーリング（ｓｃｒｅｅｎ ｍｉｒｒｏｒｉｎｇ）技術である。

表１は、ディスプレイサービスとプレイサービスの特性を比較したものである。

表１に示すように、ディスプレイサービスは、ホーム画面、アプリケーション画面、通常的でないＡ／Ｖコンテンツの共有に適しているが、ファイルコンテンツの場合は、トランスコーディングの負担のため適していない。プレイサービスは、ファイル基盤のメディアストリーミングを、元の品質を毀損せずに行えるという長所を有するが、スクリーン自体のミラーリングは支援することができない。

このように、プレイとディスプレイの二つの画面共有サービスは、画面にコンテンツを表示するサービスという点では共通しているが、相互補完的または代案的（ａｌｔｅｒｎａｔｉｖｅ）に適用される。ＴＸデバイスがファイル基盤のＡ／Ｖコンテンツをミイラキャストを用いて伝送する場合、Ａ／Ｖコンテンツをローカルでデコーディングした後、再びエンコーディングして伝送しなければならないオーバーヘッドが発生し、再びエンコーディングする場合、画質劣化が発生する。この場合、ディスプレイサービスの代わりに、プレイサービスに伝送することがより効率的である。または、ＴＸデバイスがゲームやホーム画面などのファイル基盤でないコンテンツをＲＸデバイスと共有しようとする場合は、プレイサービスでは画面共有を具現しにくいので、ディスプレイサービスを適用することが効率的である。このように相互補完的で且つ代案的なサービスの場合は、サービス間の転換、変更、復帰などの動作をＡＳＰが支援する方案が要求される。

このように、ディスプレイサービスの遂行中にプレイサービスに転換したり、その反対に転換する場合を仮定して本発明の各例示を説明する。しかし、本発明はこれに制限されるものではなく、他の例示として、第１の層／第２の層（Ｌ１／Ｌ２）処理率（ｔｈｒｏｕｇｈｐｕｔ）がディスプレイサービスと伝送サービスの全てを支援するのに不足している場合、ディスプレイサービスの遂行中に伝送サービスに転換したり、その反対に転換する場合にも、本発明で提案する原理を同一に適用することができる。

アプリケーションがサービスを転換しようとする場合として、次のような状況を仮定することができる。

例えば、シーカーデバイスのアプリケーションがサービスに受信側プレイサービスの探索（ＳｅｅｋＳｅｒｖｉｃｅ（ｏｒｇ．ｗｉ―ｆｉ．ｗｆｄｓ．ｐｌａｙ．ｒｘ，…）及び受信側ディスプレイサービスの探索（ＳｅｅｋＳｅｒｖｉｃｅ（ｏｒｇ．ｗｉ―ｆｉ．ｗｆｄｓ．ｄｉｓｐｌａｙ．ｒｘ，…）を呼び出す場合を仮定することができる。この場合、アプリケーションは、ユーザーの入力、デバイス政策（ｐｏｌｉｃｙ）、処理率測定などの多様な情報に基づいてサービスを転換することに決定することができる。

または、送信側プレイサービスの待機（ＡｄｖｅｒｔｉｓｅＳｅｒｖｉｃｅ（ｏｒｇ．ｗｉ―ｆｉ．ｗｆｄｓ．ｐｌａｙ．ｔｘ，…）を呼び出したアドバタイザーデバイスが、送信側プレイサービスの探索（ＳｅｅｋＳｅｒｖｉｃｅ（ｏｒｇ．ｗｉ―ｆｉ．ｗｆｄｓ．ｐｌａｙ．ｔｘ，…））を呼び出したシーカーデバイスが受信側ディスプレイサービス（ｏｒｇ．ｗｉ―ｆｉ．ｗｆｄｓ．ｄｉｓｐｌａｙ．ｒｘ）を支援できるか否かを知るために、受信側ディスプレイサービスの探索（ＳｅｅｋＳｅｒｖｉｃｅ（ｏｒｇ．ｗｉ―ｆｉ．ｗｆｄｓ．ｄｉｓｐｌａｙ．ｒｘ，…））を呼び出す場合を仮定することができる。この場合、アプリケーションは、ユーザーの入力、デバイス政策、処理率測定などの多様な情報に基づいてサービスを転換することに決定することができる。

図１３〜図１６は、本発明の一実施例に係るサービス転換を説明するための図である。

図１３〜図１４の動作は、すなわち、サービスＡに対するＡＳＰ―セッションセットアップ動作を示す。図１３は、プローブ要求／応答、サービス発見要求／応答、サービスＡに対するプロビジョン発見要求／応答、ＧＯ交渉過程を示す。

図１３に示す過程を通じて、第１のサービス（すなわち、サービスＡ）と第２のサービス（サービスＢ）の２つのサービスに対する探索（ｓｅｅｋ）が行われる。すなわち、第２のデバイス（デバイスＢ）は、第１のデバイス（デバイスＡ）がサービスＡ及びサービスＢを支援するか否かをデバイス発見過程及び／またはサービス発見過程などを通じて確認することができる。デバイスＡ及びＢがサービスＡ及びＢを全て支援する場合、図１３の例示では、デバイスＡとデバイスＢとの間でサービスＡに対するプロビジョン発見要求／応答過程を通じてサービスＡに対するセッション情報及び連結ケーパビリティを交換することができる。

具体的には、デバイスＡは、サービスＡ及びサービスＢを支援することができ、また、デバイスＢも、サービスＡ及びサービスＢを支援すると仮定する。デバイスＡのサービスＡ及びサービスＢは、それぞれＡＳＰにＡｄｖｅｒｔｉｓｅＳｅｒｖｉｃｅ（）メソッドを用いて自身が支援するサービスに対して知らせる。また、デバイスＢでも、サービスＡ及びサービスＢは、それぞれＡＳＰにＡｄｖｅｒｔｉｓｅＳｅｒｖｉｃｅ（）メソッドを用いて自身が支援するサービスに対して知らせる。

アプリケーション／ユーザーが新たなサービスを探し、該当のサービスを駆動させるために入力すると、該当のサービスは、ＡＳＰを通じて周辺のＷＦＤＳ支援デバイスのうち該当のサービスを支援するデバイスを探索するようになる。

図１３の例示では、デバイスＢのアプリケーション／ユーザーがサービスＡを使用しようとする場合を仮定する（Ｕｓｅ Ｓｅｒｖｉｃｅ）。これによって、サービスＡは、ＡＳＰにＳｅｅｋＳｅｒｖｉｃｅ（）メソッドを伝達するようになる。これによって、ＡＳＰは、Ｐ２Ｐプローブ要求／応答メッセージを用いてサービスＡを支援する周辺のＷＦＤＳデバイスを探索することができる。

具体的には、プローブ要求メッセージには、探索対象になるサービスのハッシュ値を含ませることができる。これを受信したデバイスＡは、サービスハッシュ値がマッチングされる場合、プローブ応答メッセージにハッシュ値またはサービス名称を含ませて伝送することができる。複数のサービスを支援するＷＦＤＳデバイスをスキャニングしようとする場合、プローブ要求フレームに複数のサービス名称、または複数のサービスハッシュ値を含ませることができる。

表２及び表３は、本発明で提案するプローブ応答メッセージに追加的に含まれ得る情報のフォーマットを示す。

既存の方式に従うと、プローブ応答メッセージ内に一つのサービスに対する情報が含まれていたので、多数のサービスに対するデバイス探索を行うためには、多数回のプローブ要求／応答フレームの交換が必要であった。

本発明によると、Ｐ２Ｐプローブ応答フレーム内にアドバタイズされるサービス情報（Ａｄｖｅｒｔｉｓｅｄ Ｓｅｒｖｉｃｅ Ｉｎｆｏ）というフィールドを定義し、アドバタイズされるサービス情報内に一つ以上のアドバタイズされるサービス記述子（Ａｄｖｅｒｔｉｓｅｄ Ｓｅｒｖｉｃｅ Ｄｅｓｃｒｉｐｔｏｒ）が含まれ、一つのアドバタイズされるサービス記述子は、一つのサービスに対する情報を含むものと定義することができる。すなわち、一つのプローブ応答メッセージ内に前記表２のようなアドバタイズされるサービス情報が含まれ、アドバタイズされるサービス情報には、前記表３または表４のようなアドバタイズされるサービス記述子情報を一つまたは複数含ませることができる。表３または表４は、一つのアドバタイズされるサービス記述子の各サブフィールドのフォーマットを示す。

アドバタイズされるサービス記述子内には、該当のサービスが支援可能であるか否かを示すサービス通知（Ｓｅｒｖｉｃｅ Ｎｏｔｉｃｅ）フィールド、及び該当のサービスがサービスハンドオーバーを支援するか否かを示す情報のうち一つ以上を含ませることができる。サービスハンドオーバーフィールドが０ｘ０１に設定されたアドバタイズされるサービス記述子に対応するサービスは、サービスハンドオーバーが適用され得ることを示すことができる。

このようなＰ２Ｐプローブ要求／応答過程を通じたデバイス発見後、追加的にサービス発見要求／応答過程を行うことができる。

下記の表５及び表６は、サービス発見応答メッセージに含まれるサービス情報を示す。

既存の方式に従うと、サービス発見応答メッセージ内に一つのサービスに対する情報が含まれていたので、多数のサービスに対するサービス発見を行うためには多数回のサービス発見要求／応答フレームの交換が必要であった。

本発明によると、Ｐ２Ｐサービス発見応答フレーム内に一つ以上のサービス情報記述子（Ｓｅｒｖｉｃｅ Ｉｎｆｏ Ｄｅｓｃｒｉｐｔｏｒ）というフィールドを定義することができる。前記表５に示すように、サービス情報記述子がいくつ含まれるかに対する情報を含むフィールドも共に定義することができる。前記表６は、一つのサービス情報記述子の各サブフィールドのフォーマットを示す。サービス情報記述子は、サービス状態（ｓｅｒｖｉｃｅ ｓｔａｔｕｓ）、サービスハンドオーバー、サービス名称長さ、サービス名称、サービス情報長さ、及びサービス情報フィールドのうち一つ以上を含むことができる。

このように、デバイスＡ及びデバイスＢは、１回のデバイス発見過程、サービス発見過程を通じて、サービスＡ及びサービスＢに対するデバイス発見及びサービス発見を行うことができる。

図１４では、サービスＡに対するセッション要求、サービスＡに対するセッション追加過程を示す。

図１４に示す過程の詳細な事項は、図１２の対応過程と同一であるので、重複する説明は省略する。図１３〜図１４に示す動作の結果として、サービスＡに対するセッションが開始される。

図１５〜図１６では、サービスＢに対するＡＳＰ―セッションセットアップ動作を示す。

図１５に示すように、サービスＡに対するセッションが存在している二つのデバイス間でアプリケーションによってサービスＢが呼び出される場合は、サービスＡからサービスＢへの転換が行われなければならない。このために、新たなサービスＢに対するセッションをセットアップしなければならない。

この場合、従来技術によると、いずれかの各デバイス間に新たなサービスＢを追加するためには、プロビジョン発見要求／応答、ＧＯ交渉過程、セッション要求、セッション追加過程を行うことに定義されている。しかし、デバイスＡとデバイスＢとの間にＰ２Ｐ連結が既に存在している場合、サービスＢに対するセッションのセットアップのためにデバイスＡとデバイスＢとの間にプロビジョン発見要求／応答過程を通じて連結ケーパビリティ情報を交換することは不要または非効率的である。

したがって、図１５に示すように、サービスＡからサービスＢへの転換を行うために、新たなサービスＢに対するセッションセットアップのためにプロビジョン発見要求／応答過程を省略（ｓｋｉｐ）し、直ぐセッション要求、セッション追加過程を行うことができる。

図１５の例を通じて、サービスアドバタイザーとサービスシーカーとの間にＬ２（第２の層）／Ｌ３（第３の層）連結（例えば、ＩＰ連結またはＰ２Ｐ連結）が既に設定されている場合のメッセージシーケンスに対して説明した。この場合、サービスシーカーは、プロビジョン発見過程を行わず、ＲＥＱＵＥＳＴ＿ＳＥＳＳＩＯＮメッセージを用いてサービス要求を開始することができる。

図１６には、ＡＳＰがサービスＡに対するＡＳＰセッションを終了する動作を示す。サービスシーカーデバイスでユーザー入力によってサービスＡに対するセッションの終了が指示されると、これによってサービス終了過程を行うことができる。

図１７は、本発明の追加的な実施例に係るサービス転換を説明するための図である。

図１７は、図１５の代わりに行われる動作を示す。すなわち、本発明の追加的な例示によるサービス転換動作は、図１３、図１４、図１７及び図１６の順にサービスＡに対するセッションセットアップ（図１３及び図１４）、サービスＢに対するセッションセットアップ（図１７）、サービスＡに対するセッション終了（図１６）を行うことができる。

図１７の例示によると、デバイスＢでサービス転換に対するユーザー入力が発生すると、サービスＢは、ＡＳＰにセッション連結を指示することができる。これによって、デバイスＢのＡＳＰは、セッション要求（ＲＥＱＵＥＳＴ＿ＳＥＳＳＩＯＮ）メッセージをデバイスＡに伝達するが、セッション要求メッセージには、セッション情報（すなわち、サービスＢに対するセッション情報）が含まれる。セッション要求に含まれたセッション情報に基づいて、デバイスＡのサービスＢは、アプリケーションを通じてサービスＢに対するセッションセットアップに対するユーザー入力を受けることができる。

サービスＢがデバイスＡで利用可能でないか、ユーザー／アプリケーションによってサービスＢが拒絶される場合は、図１７のＡＤＤＥＤ＿ＳＥＳＳＩＯＮメッセージの代わりにＲＥＪＥＣＴＥＤ＿ＳＥＳＳＩＯＮメッセージが伝達され得る。この場合、元のセッション（すなわち、サービスＡに対するセッション）を維持することができる。

図１７の例を通じて、サービスアドバタイザーとサービスシーカーとの間にＬ２（第２の層）／Ｌ３（第３の層）連結（例えば、ＩＰ連結またはＰ２Ｐ連結）が既に設定されている場合のメッセージシーケンスに対して説明した。この場合、サービスシーカーは、プロビジョン発見過程を行わず、ＲＥＱＵＥＳＴ＿ＳＥＳＳＩＯＮメッセージを用いてサービス要求を開始することができる。ここで、サービス情報（ヒント情報またはメタデータ）はＲＥＱＵＥＳＴ＿ＳＥＳＳＩＯＮメッセージに含まれる。

図１８は、本発明で提案するサービスハンドオーバーを説明するための図である。

各ＷＦＤＳサービス（例えば、ディスプレイサービスとプレイサービス）間のシームレスサービスハンドオーバーは、ユーザー経験の品質を高めるのに非常に重要である。

図１８の例示では、デバイスＡのユーザーの入力によってデバイスＡとデバイスＢとの間のディスプレイサービス（例えば、ミイラキャスト）が開始される場合を仮定する。すなわち、ディスプレイサービスに対して、デバイスＡは送信側またはソース（Ｓｏｕｒｃｅ）としての役割をし、デバイスＢは受信側またはシンク（Ｓｉｎｋ）としての役割をする。ディスプレイサービスにより、デバイスＡで駆動されるホームスクリーン、ゲーム、アプリ（Ａｐｐｓ）などの画面がデバイスＢに表示され得る。

図１８の例示では、ディスプレイサービスが開始され、デバイスＡとデバイスＢとの間のＷＦＤＳディスプレイサービスが樹立されると、例えば、ディスプレイサービスによってデバイスＡのホーム画面がデバイスＢに表示され得る。

この場合、デバイスＡのユーザーがギャラリーアプリを駆動し、いずれかの映画ファイルを選択する場合を仮定する。この場合、ディスプレイサービスは、ファイル基盤のコンテンツを処理するのに適しておらず、プレイサービスによってファイル基盤のコンテンツを表示するサービスを提供することに適している。したがって、ディスプレイサービスからプレイサービスへのハンドオーバー（または、上述したようなサービス転換（ｓｗｉｔｃｈ））が要求される。

図１８の例示において、デバイスＡからデバイスＢにハンドオーバー要求（すなわち、ディスプレイサービスからプレイサービスへのハンドオーバー／転換を要求）メッセージが伝達され、ＷＦＤＳサービスハンドオーバーが行われた後、プレイサービスによってデバイスＡのユーザーが選択した映画ファイルがデバイスＢで再生され得る。すなわち、プレイサービス（例えば、ＤＬＮＡ）に対してデバイスＡが送信側または「＋ＰＵ＋」（Ｐｕｓｈ Ｃｏｎｔｒｏｌｌｅｒ）としての役割をし、デバイスＢは、受信側またはＤＭＲ（Ｄｉｇｉｔａｌ Ｍｅｄｉａ Ｒｅｎｄｅｒｅｒ）としての役割をする。

図１９は、本発明の追加的な実施例に係るサービスハンドオーバー過程を説明するための図である。

図１９の例は、図１３〜図１６を参照して説明したサービス転換方案において、図１５〜図１６の動作を代替することと理解することができる。すなわち、本発明の追加的な例示によるサービスハンドオーバー動作は、図１３及び図１４の順にサービスＡに対するセッションセットアップ（図１３及び図１４）及びサービスＡからサービスＢへのハンドオーバー（図１９）を行うことができる。

デバイスＡとデバイスＢは、いずれもサービスＡ及びサービスＢという同一のサービスを支援し、サービスＡ及びサービスＢはいずれもサービスハンドオーバーを支援すると仮定する。

図１９の例において、デバイスＢのアプリケーション／ユーザーがサービスＡの遂行中にサービスＢにハンドオーバーすることに決定し、これをサービスＡに知らせることができる。これによって、サービスＡは、ＡＳＰにサービスハンドオーバーを指示するメソッド（ＳｅｒｖｉｃｅＨａｎｄｏｖｅｒ（））を伝達することができる。

デバイスＢのサービスＢは、ＡＳＰにＳｅｒｖｉｃｅＨａｎｄｏｖｅｒ（）メソッドを通じてサービスＢへのハンドオーバーを要求する。これを受けたデバイスＢのＡＳＰは、デバイスＡのＡＳＰにＡＳＰコーディネーションプロトコルのＨＡＮＤＯＶＥＲ＿ＳＥＳＳＩＯＮメッセージを用いてハンドオーバーを要求する。このとき、ＨＡＮＤＯＶＥＲ＿ＳＥＳＳＩＯＮ内には、ハンドオーバー対象であるサービスＢのａｄｖｅｒｔｉｓｅｍｅｎｔ＿ｉｄ、ｍａｃ＿ａｄｄｒｅｓｓ、ｓｅｓｓｉｏｎ＿ｉｄ情報を含ませることができる。これを受けたデバイスＡのＡＳＰは、ＳｅｓｓｉｏｎＨａｎｄｏｖｅｒ（）イベントをサービスＡに伝達することができる。このように要求されるサービスハンドオーバーの収容または拒絶の有無は、アプリケーションの設定またはユーザーによって決定することができる。現在進行中のデバイスＡのサービスＡは、ハンドオーバーに対するアプリケーション／ユーザーの収容により、現在のセッションを閉鎖し、使用するポートを解除することができる。その後、アプリケーション／ユーザーは、サービスＢに対するセッションを追加し、この結果をＡＳＰコーディネーションプロトコルのＡＤＤＥＤ＿ＳＥＳＳＩＯＮメッセージを通じてデバイスＢに知らせるようになる。これを受けたデバイスＢのＡＳＰは、デバイスＡでハンドオーバーを収容したことが分かり、サービスＢを行うことができる。

図１９の例のようなセッションハンドオーバー動作のために、ＡＳＰコーディネーションプロトコルで新たなＯｐｃｏｄｅを定義することができる。Ｏｐｃｏｄｅは、メッセージタイプを示すことができる。例えば、下記の表７のように、Ｏｐｃｏｄｅ＝４をＨＡＮＤＯＶＥＲ＿ＳＥＳＳＩＯＮメッセージを指示するものと定義することができる。

表８は、図１９の実施例と関連するＨＡＮＤＯＶＥＲ＿ＳＥＳＳＩＯＮメッセージのフォーマットを示す。

図２０は、本発明の一実施例に係るサービスハンドオーバー過程を説明するための図である。

図２０の例は、図１３〜図１６を参照して説明したサービス転換方案において、図１５〜図１６の動作を代替することと理解することができる。すなわち、本発明の追加的な例によるサービスハンドオーバー動作は、図１３及び図１４の順にサービスＡに対するセッションセットアップ（図１３及び図１４）及びサービスＡからサービスＢへのハンドオーバー（図２０）を行うことができる。

デバイスＡとデバイスＢは、いずれもサービスＡ及びサービスＢという同一のサービスを支援し、サービスＡ及びサービスＢはいずれもサービスハンドオーバーを支援すると仮定する。

図２０の例において、デバイスＢのアプリケーション／ユーザーがサービスＡの遂行中にサービスＢにハンドオーバーすることに決定し、これをサービスＡに知らせることができる。これによって、サービスＡは、ＡＳＰにサービスハンドオーバーを指示するメソッド（ＳｅｒｖｉｃｅＨａｎｄｏｖｅｒ（））を伝達することができる。

サービスハンドオーバーに対するメソッドは、ＳｅｒｖｉｃｅＨａｎｄｏｖｅｒ（ｓｅｒｖｉｃｅ＿ｍａｃ、ａｄｖｅｒｔｉｓｅｍｅｎｔ＿ｉｄ、ｓｅｓｓｉｏｎ＿ｉｎｆｏｒｍａｔｉｏｎ、ｓｅｓｓｉｏｎ＿ｍａｃ、ｓｅｓｓｉｏｎ＿ｉｄ）と定義することができる。

ここで、ｓｅｒｖｉｃｅ＿ｍａｃフィールドは、遠隔Ｐ２ＰデバイスのＭＡＣアドレスを意味する。図１３のＳｅａｒｃｈＲｅｓｕｌｔイベントによってリターンされた値と同一の値を有することができる。ａｄｖｅｒｔｉｓｅｍｅｎｔ＿ｉｄフィールドは、ハンドオーバーターゲットサービス（すなわち、サービスＢ）のアドバタイズメントＩＤを示すことができる。ｓｅｓｓｉｏｎ＿ｉｎｆｏｒｍａｔｉｏｎフィールドは、サービスハンドオーバーを開始するとき、サービスアドバタイザーに伝えられるセッション情報に該当し、場合に応じてＮＵＬＬに設定することもできる。ｓｅｓｓｉｏｎ＿ｍａｃフィールドは、現在のＡＳＰ―セッションに対するｓｅｓｓｉｏｎ＿ｉｄを割り当てたＰ２ＰデバイスのＭＡＣアドレスを意味する。ｓｅｓｓｉｏｎ＿ｉｄフィールドは、現在のＡＳＰ―セッションのセッション識別子を意味する。ＳｅｒｖｉｃｅＨａｎｄｏｖｅｒ（）メソッドによってｓｅｓｓｉｏｎ＿ｍａｃ情報及びｓｅｓｓｉｏｎ＿ｉｄ情報がリターンされ得る。

サービスＡからＳｅｒｖｉｃｅＨａｎｄｏｖｅｒ（）メソッドを受信したデバイスＢのＡＳＰは、デバイスＡにハンドオーバーセッション（ＨＡＮＤＯＶＥＲ＿ＳＥＳＳＩＯＮ）メッセージを送り、サービスＢに初期（Ｉｎｉｔｉａｔｅｄ）に設定されたセッション状態イベントを伝達することができる。これは、サービスシーカー側のＡＳＰがＡＳＰ―セッションを要求したが、未だに使用する準備がされておらず、アドバタイザーの承認を待機しているか、またはネットワーク連結が未だに樹立されていないことを知らせる意味を有する。

デバイスＢがデバイスＡに伝達するハンドオーバーセッションメッセージには、サービスＡに対するセッションＭＡＣ（ｓｅｓｓｉｏｎ＿ｍａｃ）、セッションＩＤ、アドバタイズメントＩＤなどの情報と、サービスＢに対するセッションＭＡＣ、セッションＩＤ、セッション情報などの情報を含ませることができる。セッションＭＡＣ（ｓｅｓｓｉｏｎ＿ｍａｃ）情報は、セッションＩＤを割り当てたＰ２ＰデバイスのＭＡＣアドレスを示すことができる。

これによって、デバイスＡのＡＳＰは、サービスＢにセッション要求イベント（ＳｅｓｓｉｏｎＲｅｑｕｅｓｔ）を伝達し、サービスＢは、アプリケーション／ユーザーにセッション情報を伝達し、ユーザー入力（例えば、収容）を受けることができ、これをサービスＢに知らせると、サービスＢは、ＡＳＰに確認メソッド（ＳｅｓｓｉｏｎＣｏｎｆｉｒｍ（））を伝達することができる。

デバイスＡのＡＳＰは、セッション状態イベントをサービスＢに伝達するが、その状態を要求された（Ｒｅｑｕｅｓｔｅｄ）に設定することができる。これは、サービスアドバタイズ側のＡＳＰが、他のデバイスによってセッションが要求されることをサービス層に知らせる意味を有する。また、デバイスＡのＡＳＰは、開放（Ｏｐｅｎ）に設定されたセッション状態イベントをサービスＢに伝達することができる。これは、ＡＳＰ―セッションセットアップが完了し、使用する準備がされたことを知らせる意味を有する。その後、デバイスＡのサービスＢとＡＳＰとの間のポート要求、ポートバインディング、ポート準備などのメソッド／イベントの交換後にセッション準備メソッド（ＳｅｓｓｉｏｎＲｅａｄｙ（））がＡＳＰに伝達されると、ＡＳＰは、デバイスＢにＡＤＤＥＤ＿ＳＥＳＳＩＯＮメッセージを伝達することができる。ＡＤＤＥＤ＿ＳＥＳＳＩＯＮメッセージには、ＭＡＣアドレス、セッションＩＤなどの情報を含ませることができる。デバイスＢのＡＳＰは、開放（Ｏｐｅｎ）に設定されたセッション状態イベントをサービスＢに伝達し、ＡＣＫメッセージをデバイスＡに送ることができる。

その後、デバイスＢのＡＳＰは、サービスＡに閉鎖（Ｃｌｏｓｅｄ）に設定されたセッション状態イベントを伝達することができる。これは、セッション状態が開放（Ｏｐｅｎ）または初期（Ｉｎｉｔｉａｔｅｄ）から閉鎖（Ｃｌｏｓｅｄ）状態に転換されたことを知らせる意味を有する。これによって、サービスＡは、ＡＳＰにポート解除を指示するメソッド（ＲｅｌｅａｓｅＰｏｒｔ（））を伝達することができる。

また、デバイスＢからＡＣＫメッセージを受信したデバイスＡのＡＳＰは、サービスＡに閉鎖（Ｃｌｏｓｅｄ）に設定されたセッション状態イベントを伝達することができる。これによって、サービスＡは、ＡＳＰにポート解除を指示するメソッド（ＲｅｌｅａｓｅＰｏｒｔ（））を伝達することができる。

一方、デバイスＢのサービスＢは、デバイスＡのサービスＢにアプリケーションソケット連結を知らせ、アプリケーション層によってアプリケーションデータの伝送のためのリンクが形成され、これを通じてアプリケーションデータが送受信され得る状態になり、サービスＢに対するサービスセッションが開始される。

図２０の例において、デバイスＡでサービスＢが利用可能でないか、サービスＢに対する要求がアプリケーション／ユーザーによって拒絶される場合、デバイスＡは、ＡＤＤＥＤ＿ＳＥＳＳＩＯＮメッセージの代わりにＲＥＪＥＣＴＥＤ＿ＳＥＳＳＩＯＮメッセージをデバイスＢに伝送し、元のセッション（すなわち、サービスＡに対するセッション）を維持することができる。

図２０の例のようなセッションハンドオーバー動作のために、ＡＳＰコーディネーションプロトコルで新たなＯｐｃｏｄｅを定義することができる。Ｏｐｃｏｄｅは、メッセージタイプを示すことができる。例えば、前記表６に示すように、Ｏｐｃｏｄｅ＝４をＨＡＮＤＯＶＥＲ＿ＳＥＳＳＩＯＮメッセージを指示するものと定義することができる。

また、ＨＡＮＤＯＶＥＲ＿ＳＥＳＳＩＯＮメッセージのフォーマットは、下記の表９または表１０のように定義することもできる。

前記表９及び表１０において、Ｏｐｃｏｄｅの値が４に設定され、これは、前記表６にしたがってＨＡＮＤＯＶＥＲ＿ＳＥＳＳＩＯＮメッセージタイプであることを示す。

前記表１０は、前記表９に比べて現在のサービスに対するａｄｖｅｒｔｉｓｅｍｅｎｔ＿ｉｄ情報がさらに含まれる例を示す。

また、サービス転換またはサービスハンドオーバーを支援するために、ＲＥＱＵＥＳＴ＿ＳＥＳＳＩＯＮメッセージを利用することもできる。すなわち、ＡＳＰコーディネーションプロトコルにおいて既存のＲＥＱＵＥＳＴ＿ＳＥＳＳＩＯＮメッセージを修正し、ＡＳＰ―セッションが既に存在している状況で新たなＡＳＰ―セッションをセットアップするためのメッセージとして使用することもできる。このような修正されたＲＥＱＵＥＳＴ＿ＳＥＳＳＩＯＮメッセージフォーマットは、下記の表１１のように定義することができる。

図２１は、本発明に係るサービスハンドオーバーの追加的な例を説明するための図である。

図２１の例では、ＷＦＤＳを支援するスマートフォンとＴＶとの間のサービスハンドオーバーを例示的に示す。スマートフォンは、プレイサービスの送信側（ＴＸ）機能及びディスプレイサービスのＴＸ機能を支援するものと仮定する。ＴＶは、プレイサービスの受信側（ＲＸ）機能及びディスプレイサービスのＲＸ機能を支援するものと仮定する。

デバイス発見過程におけるプローブ要求／応答メッセージの交換を通じて、シーカーとしての役割をするスマートフォンは、アドバタイザーとしての役割をするＴＶの支援サービスとサービスハンドオーバーケーパビリティを確認することができる。

その後、ＷＦＤＳ規格によるセッション樹立過程後、ディスプレイサービス（例えば、ミイラキャスト）を開始するようになる。これによって、スマートフォンは、自身の画面をＴＶの画面にスクリーンミラーリングすることができる。ディスプレイサービスの遂行途中で、スマートフォンのユーザーがギャラリー内の特定Ａ／Ｖファイル（すなわち、スマートフォンの格納所に格納されたファイル基盤の動画）を選択することができる。この場合、スマートフォンは、該当のファイル基盤のコンテンツをプレイサービスを通じてＴＶに伝送しようとする。ディスプレイサービスの途中でプレイサービスへの転換またはハンドオーバーの有無は、スマートフォン設定及び／または製造会社の政策などに従うことができる。

サービス転換／ハンドオーバーのために、スマートフォンは、ＨＡＮＤＯＶＥＲ＿ＳＥＳＳＩＯＮメッセージをＴＶのＡＳＰに伝達し、プレイサービスへのハンドオーバーを試みる。ＴＶがハンドオーバーを受諾すると、プレイサービスにハンドオーバーが行われる。ユーザーが選択したファイル基盤の動画が終了したり、ユーザーが中止する場合、設定にしたがって既存のディスプレイサービスに再びハンドオーバーし、元のサービスに復帰することができる。

このように、本発明は、ＷＦＤＳデバイスが共通のサービスを支援する場合、ハンドオーバーの可否をデバイス発見時に知ることができ、ＡＳＰ間の制御メッセージを通じてサービス間のハンドオーバーまたは元のサービスへの復帰を途切れなく行うことができる。

さらに、本発明では、ＡＳＰがサービスに呼び出し（ｃａｌｌ）をするＣｏｎｎｅｃｔｉｏｎＳｔａｔｕｓイベントプリミティブを提案する。ＣｏｎｎｅｃｔｉｏｎＳｔａｔｕｓイベントは、ＡＳＰが自身のグループ形成やサービス要求などに対する進行状況をサービスに報告するために利用される。ＣｏｎｎｅｃｔｉｏｎＳｔａｔｕｓイベントプリミティブは、ＣｏｎｎｅｃｔＳｔａｔｕｓ（ｓｅｓｓｉｏｎ＿ｍａｃ、ｓｅｓｓｉｏｎ＿ｉｄ、ｓｔａｔｕｓ）と定義することができる。

「状態（ｓｔａｔｕｓ）」フィールドは、サービスシーカーまたはサービスアドバタイザー側のＡＳＰのステートマシンの現在の状態を示す。「ｓｅｓｓｉｏｎ＿ｍａｃ」フィールドは、ｓｅｓｓｉｏｎ＿ｉｄを割り当てたＰ２ＰデバイスのＭＡＣアドレスを示す。「ｓｅｓｓｉｏｎ＿ｉｄ」フィールドは、ＡＳＰ―セッションを開始したＡＳＰによって割り当てられるＡＳＰ―セッション識別子を示す。

「状態」フィールドは、ＳｅｒｖｉｃｅＲｅｑｕｅｓｔＳｅｎｔ、ＳｅｒｖｉｃｅＲｅｑｕｅｓｔＲｅｃｅｉｖｅｄ、ｓｅｒｖｉｃｅＲｅｑｕｅｓｔＤｅｆｅｒｒｅｄ、ＳｅｒｖｉｃｅＲｅｑｕｅｓｔＡｃｃｅｐｔｅｄ、ＳｅｒｖｉｃｅＲｅｑｕｅｓｔＦａｉｌｅｄ、ＧｒｏｕｐＦｏｒｍａｔｉｏｎＳｔａｒｔｅｄ、ＧｒｏｕｐＦｏｒｍａｔｉｏｎＣｏｍｐｌｅｔｅ、またはＧｒｏｕｐＦｏｒｍａｔｉｏｎＦａｉｌｅｄに設定することができる。

ＳｅｒｖｉｃｅＲｅｑｕｅｓｔＳｅｎｔは、サービスシーカーによってのみ使用することができる。サービスシーカーで閉鎖（Ｃｌｏｓｅｄ）状態にあるＡＳＰがサービスからＣｏｎｎｅｃｔＳｅｓｓｉｏｎｓメソッドを受信し、意図する（ｉｎｔｅｎｄｅｄ）ピアＡＳＰとのＩＰ連結が存在しない場合、ＡＳＰは、ＳｅｒｖｉｃｅＲｅｑｕｅｓｔＳｅｎｔ状態に変更し、これを示すイベント（例えば、ＣｏｎｎｅｃｔｉｏｎＳｔａｔｕｓイベント）を伝送することができる。

ＳｅｒｖｉｃｅＲｅｑｕｅｓｔＲｅｃｅｉｖｅｄは、サービスアドバタイザーによってのみ使用することができる。サービスアドバタイザーで閉鎖（Ｃｌｏｓｅｄ）状態にあるＡＳＰが、新たなｓｅｓｓｉｏｎ＿ｉｄ及びｓｅｓｓｉｏｎ＿ｍａｃペア（ｐａｉｒ）に対するＰ２Ｐプロビジョン発見要求を受信する場合、またはピアＡＳＰからＲＥＱＵＥＳＴ＿ＳＥＳＳＩＯＮメッセージを受信する場合、ＡＳＰは、ＳｅｒｖｉｃｅＲｅｑｕｅｓｔＳｅｎｔ状態に変更し、これを示すイベントを伝送することができる。

ＳｅｒｖｉｃｅＲｅｑｕｅｓｔＤｅｆｅｒｒｅｄは、サービス要求が直ぐ収容されない場合に使用することができる。サービスシーカーでＳｅｒｖｉｃｅＲｅｑｕｅｓｔＳｅｎｔ状態にあるＡＳＰが、状態＝１に設定されたＰ２Ｐプロビジョン発見応答を受信する場合、ＡＳＰは、ＳｅｒｖｉｃｅＲｅｑｕｅｓｔＤｅｆｅｒｒｅｄ状態に変更し、これを示すイベントを伝送することができる。また、サービスアドバタイザーでＡＳＰがＳｅｒｖｉｃｅＲｅｑｕｅｓｔＲｅｃｅｉｖｅｄ状態にあり、対応するＡｄｖｅｒｔｉｓｅＳｅｒｖｉｃｅメソッドでａｕｔｏ＿ａｃｃｅｐｔがＦＡＬＳＥに設定された場合、ＡＳＰは、ＳｅｒｖｉｃｅＲｅｑｕｅｓｔＤｅｆｅｒｒｅｄ状態に変更し、これを示すイベントを伝送することができる。遠隔デバイスがユーザー入力を待機している場合は、本イベントと後続するＣｏｎｎｅｃｔＳｔａｔｕｓ（ＳｅｒｖｉｃｅＲｅｑｕｅｓｔＡｃｃｅｐｔｅｄ）イベントとの間にまたは本イベントとＣｏｎｎｅｃｔＳｔａｔｕｓ（ＳｅｒｖｉｃｅＲｅｑｕｅｓｔＦａｉｌｅｄ）イベントとの間には長い遅延が発生し得る。本イベントの受信側はタイムアウトを具現しなければならない。

ＳｅｒｖｉｃｅＲｅｑｕｅｓｔＡｃｃｅｐｔｅｄは、サービス要求が収容されることを示す。サービスシーカーでＳｅｒｖｉｃｅＲｅｑｕｅｓｔＳｅｎｔ状態にあるＡＳＰが状態＝０に設定されたＰ２Ｐプロビジョン発見応答を受信し、ＣｏｎｎｅｃｔｉｏｎＣａｐａｂｉｌｉｔｙ交換が成功である場合、ＡＳＰは、ＳｅｒｖｉｃｅＲｅｑｕｅｓｔＡｃｃｅｐｔｅｄ状態に変更し、これを示すイベントを伝送することができる。サービスシーカーでＳｅｒｖｉｃｅＲｅｑｕｅｓｔＤｅｆｆｅｒｅｄ状態にあるＡＳＰが状態＝０に設定されたＰ２Ｐプロビジョン発見応答を受信した場合、ＡＳＰは、ＳｅｒｖｉｃｅＲｅｑｕｅｓｔＡｃｃｅｐｔｅｄ状態に変更し、これを示すイベントを伝送することができる。サービスアドバタイザーでＳｅｒｖｉｃｅＲｅｑｕｅｓｔＤｅｆｆｅｒｅｄ状態にあるＡＳＰがｃｏｎｆｉｒｍｅｄ＝ＴＲＵＥに設定されたＣｏｎｆｉｒｍＳｅｓｓｉｏｎメソッドを受信する場合、ＡＳＰは、ＳｅｒｖｉｃｅＲｅｑｕｅｓｔＡｃｃｅｐｔｅｄ状態に変更し、これを示すイベントを伝送することができる。

ＳｅｒｖｉｃｅＲｅｑｕｅｓｔＦａｉｌｅｄは、次のような場合に利用される。サービスシーカーでＳｅｒｖｉｃｅＲｅｑｕｅｓｔＤｅｆｆｅｒｅｄ状態に設定されたＡＳＰが、所定の時間の間Ｐ２Ｐプロビジョン発見要求を受信できないか、または受信されたＰ２Ｐプロビジョン発見要求に基づいて有効な連結ケーパビリティを設定できない場合、ＡＳＰは、ＳｅｒｖｉｃｅＲｅｑｕｅｓｔＦａｉｌｅｄ状態に変更し、これを示すイベントを伝送することができる。サービスアドバタイザーでＳｅｒｖｉｃｅＲｅｑｕｅｓｔＲｅｃｅｉｖｅｄ状態にあるＡＳＰが、受信されたＰ２Ｐプロビジョン発見要求に基づいて有効な連結ケーパビリティを設定できず、対応するＡｄｖｅｒｔｉｓｅＳｅｒｖｉｃｅメソッドでａｕｔｏ＿ａｃｃｅｐｔがＦＡＬＳＥに設定された場合、ＡＳＰは、ＳｅｒｖｉｃｅＲｅｑｕｅｓｔＦａｉｌｅｄ状態に変更し、これを示すイベントを伝送することができる。サービスアドバタイザーでＳｅｒｖｉｃｅＲｅｑｕｅｓｔＤｅｆｆｅｒｅｄ状態にあるＡＳＰが、ｃｏｎｆｉｒｍｅｄ＝ＦＡＬＳＥに設定されたＣｏｎｆｉｒｍＳｅｓｓｉｏｎメソッドを受信する場合、ＡＳＰは、ＳｅｒｖｉｃｅＲｅｑｕｅｓｔＦａｉｌｅｄ状態に変更し、これを示すイベントを伝送することができる。サービスは、前記のようなイベントを受信した後、ＣｌｏｓｅＳｅｓｓｉｏｎメソッドを呼び出すことができる。

ＧｒｏｕｐＦｏｒｍａｔｉｏｎＳｔａｒｔｅｄは、Ｐ２Ｐグループ形成が開始されることを示す。サービスシーカーでＡＳＰがＳｅｒｖｉｃｅＲｅｑｕｅｓｔＡｃｃｅｐｔｅｄ状態にある場合、ＡＳＰは、ＧｒｏｕｐＦｏｒｍａｔｉｏｎＳｔａｒｔｅｄ状態に変更し、これを示すイベントを伝送することができる。サービスアドバタイザーでＡＳＰがＳｅｒｖｉｃｅＲｅｑｕｅｓｔＲｅｃｅｉｖｅｄ状態にあり、対応するＡｄｖｅｒｔｉｓｅＳｅｒｖｉｃｅメソッドでａｕｔｏ＿ａｃｃｅｐｔがＴＲＵＥに設定された場合、ＡＳＰは、ＧｒｏｕｐＦｏｒｍａｔｉｏｎＳｔａｒｔｅｄ状態に変更し、これを示すイベントを伝送することができる。サービスアドバタイザーでＡＳＰがＳｅｒｖｉｃｅＲｅｑｕｅｓｔＡｃｃｅｐｔｅｄ状態にあり、意図するピアＡＳＰとのＩＰ連結が存在しない場合、ＡＳＰは、ＧｒｏｕｐＦｏｒｍａｔｉｏｎＳｔａｒｔｅｄ状態に変更し、これを示すイベントを伝送することができる。

ＧｒｏｕｐＦｏｒｍａｔｉｏｎＣｏｍｐｌｅｔｅは、Ｐ２Ｐグループが成功裏に形成されたり、またはＰ２Ｐグループが既に形成されていること（すなわち、ＩＰ連結の存在）を示す。

ＧｒｏｕｐＦｏｒｍａｔｉｏｎＦａｉｌｅｄは、Ｐ２Ｐグループ形成に失敗することを示す。

図２２は、本発明に係るＡＳＰ―セッションに対するステートマシンを説明するための図である。

全てのＷＦＤＳデバイスは、それぞれのＡＳＰ―セッションに対するステートマシン（ｓｔａｔｅ ｍａｃｈｉｎｅ）を有することができる。図２２は、一つのＡＳＰ―セッションに対するステートマシンを例示的に示す。

ＡＳＰがサービスからＣｏｎｎｅｃｔＳｅｓｓｉｏｎｓメソッドを受信すると、ＡＳＰは、サービスシーカーとして新たなＡＳＰ―セッション（初期（Ｉｎｉｔｉａｔｅｄ）状態に設定される）を生成することができる。初期（Ｉｎｉｔｉａｔｅｄ）状態は、複数のサブ―ステート（ｓｕｂ―ｓｔａｔｅｓ）で構成することができる。サービスシーカーに対するサブ―ステートマシンは、図２３を参照して後述する。初期（Ｉｎｉｔｉａｔｅｄ）状態で、ＡＳＰがピアＡＳＰから該当のＡＳＰ―セッションに対するＡＤＤ＿ＳＥＳＳＩＯＮメッセージを受信する場合、ＡＳＰ―セッション状態は開放（Ｏｐｅｎ）状態に変更される。ＡＳＰがサービスからＣｌｏｓｅＳｅｓｓｉｏｎメソッドを受信したり、ピアＡＳＰからＲＥＪＥＣＴＥＤ＿ＳＥＳＳＩＯＮメッセージを受信したり、Ｐ２Ｐ交換タイムアウト（またはＰＤ（Ｐｒｏｖｉｓｉｏｎ Ｄｉｓｃｏｖｅｒｙ）交換タイムアウト）イベントが発生したり、連結ケーパビリティ交換失敗が発生したり、または他の連結失敗イベントが発生する場合、ＡＳＰ―セッション状態は初期（Ｉｎｉｔｉａｔｅｄ）状態から閉鎖（Ｃｌｏｓｅｄ）状態に変更される。

ＡＳＰが新たなｓｅｓｓｉｏｎ＿ｍａｃ及びｓｅｓｓｉｏｎ＿ｉｄペアに対するＰ２Ｐ ＰＤ（Ｐｒｏｖｉｓｉｏｎ Ｄｉｓｃｏｖｅｒｙ）要求を受信したり、ＲＥＱＵＥＳＴ＿ＳＥＳＳＩＯＮメッセージを受信する場合、ＡＳＰは、サービスアドバタイザーとして新たなＡＳＰ―セッション（要求された（Ｒｅｑｕｅｓｔｅｄ）状態に設定される）を生成することができる。要求された（Ｒｅｑｕｅｓｔｅｄ）状態は、複数のサブ―ステートで構成することができる。サービスアドバタイザーに対するサブ―ステートマシンは、図２４を参照して後述する。ＡＳＰがサービスからＳｅｔＳｅｓｓｉｏｎＲｅａｄｙメソッドを受信する場合、ＡＳＰ―セッション状態は要求された（Ｒｅｑｕｅｓｔｅｄ）状態から開放（Ｏｐｅｎ）状態に変更される。要求された（Ｒｅｑｕｅｓｔｅｄ）状態にあるＡＳＰがサービスからＣｌｏｓｅＳｅｓｓｉｏｎメソッドまたはＣｏｎｆｉｒｍＳｅｓｓｉｏｎ（ｃｏｎｆｉｒｍｅｄ＝ＦＡＬＳＥ）メソッドを受信したり、または他の連結失敗イベントが発生する場合、ＡＳＰ―セッション状態は閉鎖（Ｃｌｏｓｅｄ）状態に変更される。

サービスアドバタイザー及びサービスシーカーの全てに対して開放（Ｏｐｅｎ）状態で、ＡＳＰがサービスからＣｌｏｓｅＳｅｓｓｉｏｎメソッドを受信したり、ピアＡＳＰからＲＥＭＯＶＥＤ＿ＳＥＳＳＩＯＮメッセージを受信したり、または他の連結失敗イベントが発生する場合、ＡＳＰ―セッション状態は閉鎖（Ｃｌｏｓｅｄ）状態に変更される。

図２３は、サービスシーカーに対するサブ―ステートマシンを説明するための図である。

図２３のステートマシンは、初期（Ｉｎｉｔｉａｔｅｄ）ステート上でのサービスシーカーに対するステートマシンを示す。

エントリー（Ｅｎｔｒｙ）ステートでピアデバイスとのＩＰ連結が存在する場合は、グループ形成完了（ＧｒｏｕｐＦｏｒｍａｔｉｏｎＣｏｍｐｌｅｔｅ）ステートに遷移（ｔｒａｎｓｉｔ）する。エントリー（Ｅｎｔｒｙ）ステートでピアデバイスとのＩＰ連結が存在しない場合は、ＰＤ（Ｐｒｏｖｉｓｉｏｎ Ｄｉｓｃｏｖｅｒｙ）要求をピアＡＳＰに伝送し、サービス要求伝送（ＳｅｒｖｉｃｅＲｅｑｕｅｓｔＳｅｎｔ）ステートに遷移する。

ＳｅｒｖｉｃｅＲｅｑｕｅｓｔＳｅｎｔステートでＡＳＰがピアＡＳＰから状態＝０に設定されたＰ２Ｐ ＰＤ応答を受信する場合、ピアＡＳＰからのＰ２Ｐ ＰＤ応答の連結ケーパビリティが有効であるとＳｅｒｖｉｃｅＲｅｑｕｅｓｔＡｃｃｅｐｔｅｄステートに遷移し、ピアＡＳＰからのＰ２Ｐ ＰＤ応答の連結ケーパビリティが有効でないと閉鎖（Ｃｌｏｓｅｄ）ステートに遷移する。ＳｅｒｖｉｃｅＲｅｑｕｅｓｔＳｅｎｔステートでＡＳＰがピアＡＳＰから状態＝１に設定されたＰ２Ｐ ＰＤ応答を受信する場合、ＳｅｒｖｉｃｅＲｅｑｕｅｓｔＤｅｆｅｒｒｅｄステートに遷移する。

ＳｅｒｖｉｃｅＲｅｑｕｅｓｔＤｅｆｅｒｒｅｄステートでＡＳＰがピアＡＳＰから状態＝０に設定されたＰ２Ｐ ＰＤ要求を受信する場合、ピアＡＳＰにＰ２Ｐ ＰＤ応答を送信し、ＡＳＰがＰ２Ｐ ＰＤ応答に対する有効な連結ケーパビリティを設定できないとＳｅｒｖｉｃｅＲｅｑｕｅｓｔＦａｉｌｅｄステートに遷移し、ＡＳＰがＰ２Ｐ ＰＤ応答に対する有効な連結ケーパビリティを設定できるとＳｅｒｖｉｃｅＲｅｑｕｅｓｔＡｃｃｅｐｔステートに遷移する。ＳｅｒｖｉｃｅＲｅｑｕｅｓｔＤｅｆｅｒｒｅｄステートでＡＳＰが所定の時間内にＰＤ要求を受信できないとＳｅｒｖｉｃｅＲｅｑｕｅｓｔＦａｉｌｅｄステートに遷移する。

ＳｅｒｖｉｃｅＲｅｑｕｅｓｔＦａｉｌｅｄステートから閉鎖（Ｃｌｏｓｅｄ）ステートに遷移する。

ＳｅｒｖｉｃｅＲｅｑｕｅｓｔＡｃｃｅｐｔｅｄステートからＧｒｏｕｐＦｏｒｍａｔｉｏｎＳｔａｒｔｅｄステートに遷移する。

ＧｒｏｕｐＦｏｒｍａｔｉｏｎＳｔａｒｔｅｄステートで、Ｐ２Ｐ ＧＯ交渉プロセスに失敗したり、自律（ａｕｔｏｎｏｍｏｕｓ）ＧＯ生成に失敗したり、存在しているＰ２Ｐグループにジョイン（ｊｏｉｎ）することに失敗したり、または他の理由により、ＧｒｏｕｐＦｒｏｍａｔｉｏｎＦａｉｌｅｄステートに遷移するようになる。ＧｒｏｕｐＦｏｒｍａｔｉｏｎＳｔａｒｔｅｄステートで、Ｐ２Ｐグループ形成が成功であるとＧｒｏｕｐＦｒｏｍａｔｉｏｎＣｏｍｐｌｅｔｅステートに遷移する。

ＧｒｏｕｐＦｏｒｍａｔｉｏｎＦａｉｌｅｄステートから閉鎖（Ｃｌｏｓｅｄ）ステートに遷移する。

ＧｒｏｕｐＦｏｒｍａｔｉｏｎＣｏｍｐｌｅｔｅステートで、必要な場合（新たなＰ２Ｐグループの場合）ＩＰアドレスをセットアップしたり、ＡＳＰコーディネーションプロトコルに対するＵＤＰソケットをセットアップしたり、サービスシーカーにＲＥＱＵＥＳＴ＿ＳＥＳＳＩＯＮメッセージを送信したり、サービスシーカーがサービスアドバタイザーからＡＤＤＥＤ＿ＳＥＳＳＩＯＮメッセージを受信すると開放（Ｏｐｅｎ）ステートに遷移したり、サービスシーカーがサービスアドバタイザーからＲＥＪＥＣＴ＿ＳＥＳＳＩＯＮメッセージを受信すると閉鎖（Ｃｌｏｓｅｄ）ステートに遷移したり、サービスシーカーがサービスからＣｌｏｓｅＳｅｓｓｉｏｎメソッドを受信すると閉鎖（Ｃｌｏｓｅｄ）ステートに遷移することができる。

他の失敗の場合に閉鎖（Ｃｌｏｓｅｄ）ステートに遷移する。

ＳｅｒｖｉｃｅＲｅｑｕｅｓｔＦａｉｌｅｄステート、ＧｒｏｕｐＦｏｒｍａｔｉｏｎＦａｉｌｅｄステート及びＳｅｒｖｉｃｅＲｅｑｕｅｓｔＡｃｃｅｐｔｅｄステートは、該当のステート内で何ら動作（ａｃｔｉｏｎ）もないので、閉鎖（Ｃｌｏｓｅｄ）ステートになり得る。

図２４は、サービスアドバタイザーに対するサブ―ステートマシンを説明するための図である。

図２４のステートマシンは、Ｒｅｑｕｅｓｔｅｄステート上でのサービスアドバタイザーに対するステートマシンを示す。

エントリー（Ｅｎｔｒｙ）ステートで、ＡＳＰが新たなｓｅｓｓｉｏｎ＿ｉｄ及びｓｅｓｓｉｏｎ＿ｍａｃペアに対するＰ２Ｐ ＰＤ要求を受信したり、またはＡＳＰがサービスシーカーからＲＥＱＥＵＳＴ＿ＳＥＳＳＩＯＮメッセージを受信すると、ＡＳＰ―セッションはＳｅｒｖｉｃｅＲｅｑｕｅｓｔＲｅｃｅｉｖｅｄステートになり得る。

ＳｅｒｖｉｃｅＲｅｑｅｕｓｔＲｅｃｅｉｖｅｄステートで、サービスアドバタイザーがａｕｔｏ＿ａｃｃｅｐｔをＦＡＬＳＥに設定すると、ｓｅｓｓｉｏｎ＿Ｒｅｑｕｅｓｔイベントをサービスに送り、ＳｅｒｖｉｃｅＲｅｑｕｅｓｔＤｅｆｅｒｒｅｄステートに遷移する。ＳｅｒｖｉｃｅＲｅｑｅｕｓｔＲｅｃｅｉｖｅｄステートで、サービスアドバタイザーがａｕｔｏ＿ａｃｃｅｐｔをＴＲＵＥに設定し、ピアＡＳＰとのＩＰ連結が存在しないと、Ｐ２Ｐ ＰＤ応答をピアＡＳＰに送り、ＡＳＰがＰ２Ｐ ＰＤ応答に対して有効な連結ケーパビリティを設定できるとＧｒｏｕｐＦｏｒｍａｔｉｏｎＳｔａｒｔｅｄステートに遷移し、ＡＳＰがＰ２Ｐ ＰＤ応答に対する有効な連結ケーパビリティを設定できないとＳｅｒｖｉｃｅＲｅｑｕｅｓｔＦａｉｌｅｄステートに遷移する。ＳｅｒｖｉｃｅＲｅｑｅｕｓｔＲｅｃｅｉｖｅｄステートで、サービスアドバタイザーがａｕｔｏ＿ａｃｃｅｐｔをＴＲＵＥに設定し、ピアＡＳＰとのＩＰ連結が存在すると、ＳｅｒｖｉｃｅＲｅｑｕｅｓｔＡｃｃｅｐｔｅｄステートに遷移する。

ＳｅｒｖｉｃｅＲｅｑｕｅｓｔＤｅｆｅｒｒｅｄステートで、ＡＳＰがサービスからｃｏｎｆｉｒｍｅｄ＝ＦＡＬＳＥに設定されたＣｏｎｆｉｒｍＳｅｓｓｉｏｎメソッドを受信するとＳｅｒｖｉｃｅＲｅｑｅｕｓｔＦａｉｌｅｄステートに遷移し、ＡＳＰがｃｏｎｆｉｒｍｅｄ＝ＴＲＵＥに設定されたＣｏｎｆｉｒｍＳｅｓｓｉｏｎメソッドを受信するとＳｅｒｖｉｃｅＲｅｑｅｕｓｔＡｃｃｅｐｔｅｄステートに遷移する。

ＳｅｒｖｉｃｅＲｅｑｕｅｓｔＦａｉｌｅｄステートから閉鎖（Ｃｌｏｓｅｄ）ステートに遷移する。

ＳｅｒｖｉｃｅＲｅｑｅｕｅｓｔＡｃｃｅｐｔｅｄステートで、ピアデバイスとのＩＰ連結が存在しない場合（すなわち、Ｐ２Ｐ ＰＤ交換によってサービス要求が開始された場合）、状態＝０に設定されたＰ２Ｐ ＰＤ要求メッセージをピアＡＳＰに送り、ＡＳＰがピアＡＳＰからＰ２Ｐ ＰＤ応答で有効な連結ケーパビリティを受信するとＧｒｏｕｐＦｏｒｍａｔｉｏｎＳｔａｒｔｅｄステートに遷移し、ＡＳＰがピアＡＳＰからＰ２Ｐ ＰＤ応答で有効でない連結ケーパビリティを受信すると閉鎖（Ｃｌｏｓｅｄ）ステートに遷移する。ＳｅｒｖｉｃｅＲｅｑｅｕｅｓｔＡｃｃｅｐｔｅｄステートで、ピアデバイスとのＩＰ連結が存在する場合（すなわち、ＲＥＱＵＥＳＴ＿ＳＥＳＳＩＯＮメッセージによってサービス要求が開始された場合）、ＡＳＰがサービスからＳｅｔＳｅｓｓｉｏｎＲｅａｄｙメソッドを受信すると開放（Ｏｐｅｎ）ステートに遷移する。ＳｅｒｖｉｃｅＲｅｑｅｕｅｓｔＡｃｃｅｐｔｅｄステートで、ＡＳＰがサービスからＣｌｏｓｅＳｅｓｓｉｏｎメソッドを受信すると閉鎖（Ｃｌｏｓｅｄ）ステートに遷移する。

ＧｒｏｕｐＦｏｒｍａｔｉｏｎＳｔａｒｔｅｄステートで、Ｐ２Ｐ ＧＯ交渉に失敗したり、自律（ａｕｔｏｎｏｍｏｕｓ）ＧＯ生成に失敗したり、存在しているＰ２Ｐグループにジョインすることに失敗したり、または他の理由により、ＧｒｏｕｐＦｒｏｍａｔｉｏｎＦａｉｌｅｄステートに遷移するようになる。ＧｒｏｕｐＦｏｒｍａｔｉｏｎＳｔａｒｔｅｄステートで、Ｐ２Ｐグループ形成が成功であるとＧｒｏｕｐＦｒｏｍａｔｉｏｎＣｏｍｐｌｅｔｅステートに遷移する。

ＧｒｏｕｐＦｏｒｍａｔｉｏｎＦａｉｌｅｄステートから閉鎖（Ｃｌｏｓｅｄ）ステートに遷移する。

ＧｒｏｕｐＦｏｒｍａｔｉｏｎＣｏｍｐｌｅｔｅステートで、必要な場合（新たなＰ２Ｐグループの場合）ＩＰアドレスをセットアップしたり、ＡＳＰコーディネーションプロトコルに対するＵＤＰソケットをセットアップしたり、ＡＳＰがサービスからＳｅｔＳｅｓｓｉｏｎＲｅａｄｙを受信すると開放（Ｏｐｅｎ）ステートに遷移したり、ＡＳＰがＣｌｏｓｅＳｅｓｓｉｏｎメソッドを受信すると閉鎖（Ｃｌｏｓｅｄ）ステートに遷移することができる。

他の失敗の場合に閉鎖（Ｃｌｏｓｅｄ）ステートに遷移する。

ＳｅｒｖｉｃｅＲｅｑｕｅｓｔＦａｉｌｅｄステート及びＧｒｏｕｐＦｏｒｍａｔｉｏｎＦａｉｌｅｄステートは、該当のステート内で何ら動作もないので、閉鎖（Ｃｌｏｓｅｄ）ステートになり得る。

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

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

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

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

図２５の無線デバイス１０は、Ｗｉ―Ｆｉダイレクトサービスを支援し、セッションセットアップを行うように設定することができる。プロセッサ１１は、第１のサービスに対するセッションを生成するために、前記第１の無線デバイスと第２の無線デバイスとの間のプロビジョン発見過程を含む、前記第１の無線デバイスと前記第２の無線デバイスとの間のＰ２Ｐ（Ｐｅｅｒ―ｔｏ―Ｐｅｅｒ）連結をセットアップするように設定することができる。プロセッサ１１は、第２のサービスに対するセッションを生成するために、前記第１の無線デバイスから前記第２の無線装置にセッション要求（ＲＥＱＵＥＳＴ＿ＳＥＳＳＩＯＮ）メッセージを伝送するように（または無線デバイス１０が第２の無線デバイスである場合は、セッション要求（ＲＥＱＵＥＳＴ＿ＳＥＳＳＩＯＮ）メッセージを受信するように）前記送受信機を制御するように設定することができる。前記第２のサービスに対するセッション情報は、前記セッション要求メッセージに含ませることができる。

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

上述した本発明の各実施例は、多様な手段を通じて具現することができる。例えば、本発明の各実施例は、ハードウェア、ファームウェア、ソフトウェアまたはそれらの結合などによって具現することができる。

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

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

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

上述した本発明の多様な実施形態は、ＩＥＥＥ ８０２．１１システムを中心に説明したが、多様な移動通信システムに同一の方式で適用することができる。

Claims (20)

1. Ｗｉ―Ｆｉダイレクトサービスを支援する第１の無線デバイスでセッションをセットアップする方法において、
   第１のサービスに対するセッションを生成するために、前記第１の無線デバイスと第２の無線デバイスとの間のプロビジョン発見過程を含む、前記第１の無線デバイスと前記第２の無線デバイスとの間の連結をセットアップする段階と、
   第２のサービスに対するセッションを生成するために、前記第１の無線デバイスから前記第２の無線デバイスにセッション要求（ＲＥＱＵＥＳＴ＿ＳＥＳＳＩＯＮ）メッセージを伝送する段階と、を含み、
   前記第２のサービスに対するセッション情報は前記セッション要求メッセージに含まれる、セッションセットアップ方法。
2. 前記第１の無線デバイスが第２の無線デバイスとの連結を有している場合、前記第２のサービスに対するセッション生成過程でプロビジョン発見過程は省略される、請求項１に記載のセッションセットアップ方法。
3. 前記第１のサービスに対するセッション情報はプロビジョン発見要求メッセージに含まれる、請求項１に記載のセッションセットアップ方法。
4. 前記連結をセットアップする前に、デバイス発見過程及びサービス発見過程のうち一つ以上が行われる、請求項１に記載のセッションセットアップ方法。
5. 前記デバイス発見過程は、前記第１の無線デバイスから前記第２の無線デバイスへのプローブ要求フレームの送信、及び前記第１の無線デバイスで前記第２の無線デバイスからのプローブ応答フレームの受信を含み、
   前記プローブ要求フレーム及び前記プローブ応答フレームのうち一つ以上には、前記第１のサービス及び第２のサービスに対する複数のサービス名称及び複数のサービスハッシュ値のうち一つ以上が含まれる、請求項４に記載のセッションセットアップ方法。
6. 前記連結をセットアップする段階はＰ２Ｐグループ形成過程をさらに含む、請求項１に記載のセッションセットアップ方法。
7. 前記第１の無線デバイスのＡＳＰ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｉｃｅ Ｐｌａｔｆｏｒｍ）が前記第１の無線デバイスのサービス層からＣｏｎｎｅｃｔＳｅｓｓｉｏｎメソッドを受信する場合、前記ＡＳＰは、サービスシーカーとして新たなＡＳＰ―セッションを生成し、初期（Ｉｎｉｔｉａｔｅ）ステートに遷移する、請求項１に記載のセッションセットアップ方法。
8. 前記セッション要求（ＲＥＱＵＥＳＴ＿ＳＥＳＳＩＯＮ）メッセージに応答するセッション追加（ＡＤＤＥＤ＿ＳＥＳＳＩＯＮ）メッセージを前記第２の無線デバイスから受信する場合、前記第１の無線デバイスのＡＳＰは、前記初期ステートから開放（Ｏｐｅｎ）ステートに遷移する、請求項７に記載のセッションセットアップ方法。
9. 前記第１の無線デバイスと前記第２の無線デバイスとの間の連結が存在する場合、前記第１の無線デバイスのＡＳＰはグループ形成完了（ＧｒｏｕｐＦｏｒｍａｔｉｏｎＣｏｍｐｌｅｔｅ）ステートに遷移し、
   前記第１の無線デバイスと前記第２の無線デバイスとの間の連結が存在しない場合、前記第１の無線デバイスのＡＳＰはサービス要求伝送（ＳｅｒｖｉｃｅＲｅｑｕｅｓｔＳｅｎｔ）ステートに遷移する、請求項７に記載のセッションセットアップ方法。
10. 前記セッション要求（ＲＥＱＵＥＳＴ＿ＳＥＳＳＩＯＮ）メッセージに応答するセッション拒絶（ＲＥＪＥＣＴＥＤ＿ＳＥＳＳＩＯＮ）メッセージを前記第２の無線デバイスから受信する場合、前記第１の無線デバイスのＡＳＰは前記初期ステートから閉鎖（Ｃｌｏｓｅｄ）ステートに遷移する、請求項７に記載のセッションセットアップ方法。
11. 前記第２のサービスに対するセッションが生成される場合、前記第１のサービスに対するセッションに対して割り当てられたポートは解除される、請求項１に記載のセッションセットアップ方法。
12. 前記第１のサービスは、伝送（Ｓｅｎｄ）、プレイ（Ｐｌａｙ）、ディスプレイ（Ｄｉｓｐｌａｙ）、プリント（Ｐｒｉｎｔ）、及びサードパーティーアプリケーションを支援するためのサービスのうちいずれか一つであり、
    前記第２のサービスは、前記第１のサービス以外の他のサービスである、請求項１に記載のセッションセットアップ方法。
13. 前記第１の無線デバイスはサービスシーカーで、
    前記第２の無線デバイスはサービスアドバタイザーである、請求項１に記載のセッションセットアップ方法。
14. 前記第１の無線デバイスと前記第２の無線デバイスとの間の連結は、Ｐ２Ｐ（Ｐｅｅｒ―ｔｏ―Ｐｅｅｒ）連結またはＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）連結である、請求項１に記載のセッションセットアップ方法。
15. Ｗｉ―Ｆｉダイレクトサービスを支援する第２の無線デバイスでセッションをセットアップする方法において、
    第１のサービスに対するセッションを生成するために、第１の無線デバイスと第２の無線デバイスとの間のプロビジョン発見過程を含む、前記第１の無線デバイスと前記第２の無線デバイスとの間の連結をセットアップする段階と、
    第２のサービスに対するセッションを生成するために、前記第２の無線デバイスで前記第１の無線デバイスからセッション要求（ＲＥＱＵＥＳＴ＿ＳＥＳＳＩＯＮ）メッセージを受信する段階とを含み、
    前記第２のサービスに対するセッション情報は前記セッション要求メッセージに含まれる、セッションセットアップ方法。
16. 前記第２の無線デバイスのＡＳＰが前記第１の無線デバイスから前記セッション要求（ＲＥＱＵＥＳＴ＿ＳＥＳＳＩＯＮ）メッセージを受信する場合、前記ＡＳＰは、サービスアドバタイザーとして新たなＡＳＰ―セッションを生成し、要求される（Ｒｅｑｕｅｓｔｅｄ）ステートに遷移する、請求項１５に記載のセッションセットアップ方法。
17. 前記第１の無線デバイスと前記第２の無線デバイスとの間の連結が存在する場合、前記第２の無線デバイスのＡＳＰが前記第１の無線デバイスから前記セッション要求（ＲＥＱＵＥＳＴ＿ＳＥＳＳＩＯＮ）メッセージを受信すると、前記第２の無線デバイスのＡＳＰによって前記第２の無線デバイスのユーザーまたはアプリケーションに前記セッション要求メッセージの受信が知られ、前記セッション要求に対する受諾（ａｃｃｅｐｔ）または拒絶（Ｒｅｊｅｃｔ）を示す情報が前記ユーザーまたは前記アプリケーションから受信される、請求項１５に記載のセッションセットアップ方法。
18. 前記第２の無線デバイスのＡＳＰが前記第１の無線デバイスから前記セッション要求（ＲＥＱＵＥＳＴ＿ＳＥＳＳＩＯＮ）メッセージを受信した場合、サービス要求受信（ＳｅｒｖｉｃｅＲｅｑｕｅｓｔＲｅｃｅｉｖｅｄ）ステートに遷移し、
    前記第１の無線デバイスと前記第２の無線デバイスとの間の連結が存在すると、前記第２の無線デバイスのＡＳＰは、前記サービス要求受信（ＳｅｒｖｉｃｅＲｅｑｕｅｓｔＲｅｃｅｉｖｅｄ）ステートから開放（Ｏｐｅｎ）ステートに遷移し、
    前記第１の無線デバイスと前記第２の無線デバイスとの間の連結が存在しない場合、前記第２の無線デバイスのＡＳＰは、前記サービス要求受信（ＳｅｒｖｉｃｅＲｅｑｕｅｓｔＲｅｃｅｉｖｅｄ）ステートからグループ形成開始（ＧｒｏｕｐＦｏｒｍａｔｉｏｎＳｔａｒｔｅｄ）ステートに遷移する、請求項１５に記載のセッションセットアップ方法。
19. Ｗｉ―Ｆｉダイレクトサービスを支援し、セッションセットアップを行う第１の無線デバイスにおいて、
    送受信機と、
    プロセッサとを含み、
    前記プロセッサは、第１のサービスに対するセッションを生成するために、前記第１の無線デバイスと第２の無線デバイスとの間のプロビジョン発見過程を含む、前記第１の無線デバイスと前記第２の無線デバイスとの間の連結をセットアップするように設定され、 前記プロセッサは、第２のサービスに対するセッションを生成するために、前記第１の無線デバイスから前記第２の無線デバイスにセッション要求（ＲＥＱＵＥＳＴ＿ＳＥＳＳＩＯＮ）メッセージを伝送するように前記送受信機を制御するように設定され、
    前記第２のサービスに対するセッション情報は前記セッション要求メッセージに含まれる、セッションセットアップを行う第１の無線デバイス。
20. Ｗｉ―Ｆｉダイレクトサービスを支援し、セッションセットアップを行う第２の無線デバイスにおいて、
    送受信機と、
    プロセッサとを含み、
    前記プロセッサは、第１のサービスに対するセッションを生成するために、第１の無線デバイスと第２の無線デバイスとの間のプロビジョン発見過程を含む、前記第１の無線デバイスと前記第２の無線デバイスとの間の連結をセットアップするように設定され、
    前記プロセッサは、第２のサービスに対するセッションを生成するために、前記第２の無線デバイスで前記第１の無線デバイスからセッション要求（ＲＥＱＵＥＳＴ＿ＳＥＳＳＩＯＮ）メッセージを受信するように前記送受信機を制御するように設定され、
    前記第２のサービスに対するセッション情報は前記セッション要求メッセージに含まれる、セッションセットアップを行う第２の無線デバイス。