本明細書に添付される図面は、本発明に関する理解を提供するためのもので、本発明の様々な実施の形態を示し、明細書の記載と共に本発明の原理を説明するためのものである。
以下、本発明の好適な実施形態を、添付の図面を参照して詳細に説明する。添付の図面と共に以下に開示される詳細な説明は、本発明の例示的な実施形態を説明するためのもので、本発明を実施できる唯一の実施形態を示すものではない。以下の詳細な説明は、本発明の完全な理解を提供するために具体的な細部事項を含む。しかし、当業者には、本発明がそれらの具体的な細部事項を伴わなくても実施可能であるということが理解される。
以下の実施例は、本発明の構成要素および特徴を所定の形態で組み合わせたものである。各構成要素または特徴は、特別の言及がない限り、選択的なものとして考慮することができる。各構成要素または特徴は、他の構成要素や特徴と組み合わされない形態で実施可能である。また、一部の構成要素および/または特徴を組み合わせて本発明の実施例を構成してもよい。本発明の実施例で説明される動作の順序は変更可能である。ある実施例の一部の構成や特徴は、別の実施例に含まれてもよく、別の実施例の対応する構成または特徴に取り替えられてもよい。
以下の説明で使用される特定の用語は、本発明の理解を助けるために提供されたもので、これらの特定の用語の使用は、本発明の技術的思想から逸脱しない範囲で他の形態に変更可能である。
場合によっては、本発明の概念が曖昧になることを避けるために、公知の構造および装置を省略したり、各構造および装置の中核機能を中心にしたブロック図の形式で図示することができる。また、本明細書全体にわたって同一の構成要素には同一の図面符号を付して説明する。
本発明の実施例は、無線アクセスシステムであるIEEE 802システム、3GPPシステム、3GPP LTEおよびLTE−A(LTE-Advanced)システム、3GPP2システム並びにWi−Fi Alliance(WFA)システムのうち少なくとも1つの開示された標準文書によって裏付けることができる。すなわち、本発明の実施例において、本発明の技術的思想を明確にするために説明を省いた段階または部分は、上記の文書によって裏付けることができる。また、本文書で開示している用語はいずれも上記の標準文書によって説明することができる。
以下の技術は、CDMA(Code Division Multiple Access)、FDMA(Frequency Division Multiple Access)、TDMA(Time Division Multiple Access)、OFDMA(Orthogonal Frequency Division Multiple Access)、SC−FDMA(Single Carrier Frequency Division Multiple Access)などの様々な無線アクセスシステムに用いることができる。CDMAは、UTRA(Universal Terrestrial Radio Access)やCDMA2000などの無線技術(radio technology)によって具現することができる。TDMAは、GSM(登録商標)(Global System for Mobile communications)/GPRS(General Packet Radio Service)/EDGE(Enhanced Data Rates for GSM Evolution)などの無線技術によって具現することができる。OFDMAは、IEEE 802.11(Wi−Fi)、IEEE 802.16(WiMAX)、IEEE 802−20、E−UTRA(Evolved UTRA)などの無線技術によって具現することができる。明確性のために、以下ではIEEE 802.11システムを中心に説明するが、本発明の技術的思想がこれに制限されるものではない。
WLANシステムの構造
図1は、本発明を適用できるIEEE 802.11システムの例示的な構造を示す図である。
IEEE 802.11構造は複数の構成要素を含むことができ、これらの相互作用によって上位層に対してトランスペアレントなSTA移動性をサポートするWLANを提供することができる。基本サービスセット(Basic Service Set;BSS)は、IEEE 802.11 LANにおける基本的な構成ブロックに該当し得る。図1では、2個のBSS(BSS1およびBSS2)が存在し、それぞれのBSSのメンバとして2個のSTA(STAtion)が含まれること(STA1およびSTA2はBSS1に含まれ、STA3およびSTA4はBSS2に含まれる)を例示的に示している。図1において、BSSを示す楕円は、当該BSSに含まれたSTAが通信を維持するカバレッジ領域を示すものと理解してもよい。この領域をBSA(Basic Service Area)と呼ぶことができる。STAがBSAの外へ移動すると、当該BSA内の他のSTAと直接通信できなくなる。
IEEE 802.11 LANにおいて最も基本的なタイプのBSSは、独立したBSS(Independent BSS;IBSS)である。例えば、IBSSは、2個のSTAだけで構成された最小の形態を有することができる。また、最も単純な形態であるとともに他の構成要素が省略されている図1のBSS(BSS1またはBSS2)がIBSSの代表的な例に該当し得る。このような構成は、STA同士が直接通信できる場合に可能である。また、このような形態のLANは、予め計画して構成されるものではなく、LANが必要な場合に構成され、これをアド−ホック(ad-hoc)ネットワークと呼ぶこともできる。
STAの電源オン/オフ、STAのBSS領域への入/出などによって、BSSでのSTAのメンバシップが動的に変更され得る。BSSのメンバになるためには、STAは同期手順を用いてBSSに参加(ジョイン)する(join)ことができる。BSSベース構造の全てのサービスにアクセスするためには、STAはBSSに関連付けられて(associated with)いなければならない。このような関連付け(association)は動的に設定することができ、配信システムサービス(Distribution System Service;DSS)の利用を含むことができる。
層構造
無線LANシステムで動作するSTAの動作は、層(layer)構造の観点で説明することができる。装置構成の面で層構造はプロセッサによって具現することができる。STAは複数の層構造を有することができる。例えば、802.11標準文書において扱う層構造は、主にDLL(Data Link Layer)上のMACサブレイヤ(sublayer)および物理(PHY)層である。PHYは、PLCP(Physical Layer Convergence Procedure)エンティティ(entity)、PMD(Physical Medium Dependent)エンティティなどを含むことができる。MACサブレイヤおよびPHYは、それぞれ、MLME(MAC subLayer Management Entity)およびPLME(Physical Layer Management Entity)と呼ばれる管理エンティティを概念的に含む。このようなエンティティは、層管理機能が作動する層管理サービスインターフェースを提供する。
正確なMAC動作を提供するために、SME(Station Management Entity)がそれぞれのSTA内に存在する。SMEは、別途の管理プレーン内に存在したり、または別途に離れて(off to the side)いるように見られる、層独立エンティティである。SMEの正確な機能は、本文書で具体的に説明していないが、一般的には様々な層管理エンティティ(LME)から層−従属状態を収集し、層−固有(layer-specific)パラメータなどの値をほぼ同一に設定するなどの機能を担当するものと見られる。一般に、SMEは、一般のシステム管理エンティティを代表して(on behalf of)このような機能を行い、標準管理プロトコルを具現することができる。
前述したエンティティは、様々な方式で相互作用する。例えば、エンティティ間において、GET/SETプリミティブ(primitive)を交換(exchange)することによって相互に作用することができる。プリミティブは、特定の目的に関連した要素(element)やパラメータのセットを意味する。XX−GET.requestプリミティブは、与えられたMIB attribute(管理情報ベースの属性情報)の値を要求する(request)ために使用される。XX−GET.confirmプリミティブは、Status(状態)が“成功”である場合は適切なMIB属性情報値をリターンし、そうでない場合は、Statusフィールドでエラー指示をリターンするために使用される。XX−SET.requestプリミティブは、指示されたMIB属性が与えられた値に設定されるように要求するために使用される。上記MIB属性が特定の動作を意味する場合、これは、該当する動作が行われることを要求するものである。そして、XX−SET.confirmプリミティブは、statusが“成功”である場合は、指示されたMIB属性が要求された値に設定されたことを確認し、そうでない場合は、statusフィールドにエラー状況をリターンするために使用される。MIB属性が特定の動作を意味する場合、これは、該当の動作が行われたことを確認する。
また、MLMEおよびSMEは、様々なMLME_GET/SETプリミティブをMLME_SAP(Service Access Point)を介して交換することができる。また、様々なPLME_GET/SETプリミティブが、PLME_SAPを介してPLMEとSMEとの間で交換されてもよく、MLME−PLME_SAPを介してMLMEとPLMEとの間で交換されてもよい。
無線LANの進化
無線LAN(WLAN)技術に関する標準は、IEEE(Institute of Electrical and Electronics Engineers)802.11グループで開発されている。IEEE 802.11aおよびbは2.4GHzまたは5GHzで無免許帯域(unlicensed band)を利用し、IEEE 802.11bは11Mbpsの伝送速度を提供し、IEEE 802.11aは54Mbpsの伝送速度を提供する。IEEE 802.11gは、2.4GHzで直交周波数分割多重化(Orthogonal Frequency Division Multiplexing;OFDM)を適用し、54Mbpsの伝送速度を提供する。IEEE 802.11nは、多入力多出力OFDM(Multiple Input Multiple Output-OFDM;MIMO−OFDM)を適用し、300Mbpsの伝送速度を提供する。IEEE 802.11nはチャネル帯域幅(channel bandwidth)を40MHzまでサポートし、この場合、600Mbpsの伝送速度を提供する。
IEEE 802.11eに従う無線LAN環境でのDLS(Direct Link Setup)関連プロトコルは、BSS(Basic Service Set)がQoS(Quality of Service)をサポートするQBSS(Quality BSS)を前提とする。QBSSでは、非−AP(Non-AP)STAだけでなく、APもQoSをサポートするQAP(Quality AP)である。ところが、現在商用化されている無線LAN環境(例えば、IEEE 802.11a/b/gなどに従う無線LAN環境)では、たとえNon−AP STAがQoSをサポートするQSTA(Quality STA)であるとしても、APは、QoSをサポートできないレガシ(Legacy)APがほとんどである。その結果、現在商用化されている無線LAN環境では、QSTAであるとしても、DLSサービスを利用することができないという限界がある。
トンネルダイレクトリンク設定(Tunneled Direct Link Setup;TDLS)は、このような限界を克服するために新たに提案された無線通信プロトコルである。TDLSは、QoSをサポートしないが、現在商用化されているIEEE 802.11a/b/gなどの無線LAN環境においてもQSTAがダイレクトリンクを設定できるようにし、節電モード(Power Save Mode;PSM)においてもダイレクトリンクの設定が可能になるようにするものである。したがって、TDLSは、レガシAPが管理するBSSにおいても、QSTAがダイレクトリンクを設定できるようにするための諸手順を規定する。そして、以下では、このようなTDLSをサポートする無線ネットワークをTDLS無線ネットワークという。
Wi−Fiダイレクトネットワーク
従来技術の無線LANは、無線アクセスポイント(AP)がハブとして機能するインフラストラクチャ(infrastructure)BSSの動作を主に扱った。APは、無線/有線接続のための物理層サポート機能、ネットワーク上のデバイスに対するルーティング機能、およびデバイスをネットワークに追加/除去するためのサービス提供などを担当する。この場合、ネットワーク内のデバイスは、APを介して接続されるものであって、相互に直接接続されるものではない。
デバイス間のダイレクト接続をサポートする技術として、Wi−Fiダイレクト(Wi-Fi Direct)標準の制定が完了した。
図2は、WFD(Wi-Fi Direct)ネットワークを例示する。WFDネットワークは、Wi−Fi装置がホームネットワーク、オフィスネットワークおよびホットスポットネットワークに参加しなくても、互いにデバイスツーデバイス(Device to Device;D2D)(あるいは、Peer-to-Peer;P2P)通信を行うことができるネットワークであって、Wi−Fiアライアンス(連合)(Alliance)によって提案された。以下、WFDベースの通信をWFD D2D通信(簡単にはD2D通信)あるいはWFD P2P通信(簡単にはP2P通信)と呼ぶ。また、WFD P2P実行デバイスをWFD P2Pデバイス、簡単にはP2Pデバイスまたはピア(Peer)デバイスと呼ぶ。
図2を参照すると、WFDネットワーク200は、第1のP2Pデバイス202および第2のP2Pデバイス204を含む少なくとも1つのWi−Fiデバイスを含むことができる。P2Pデバイスは、ディスプレイ装置、プリンタ、デジタルカメラ、プロジェクタおよびスマートフォンなどのWi−Fiをサポートするデバイスを含む。また、P2Pデバイスは、Non−AP STAおよびAP STAを含む。図示された例において、第1のP2Pデバイス202は携帯電話であり、第2のP2Pデバイス204はディスプレイ装置である。WFDネットワーク内のP2Pデバイスは互いに直接接続可能である。具体的には、P2P通信は、2つのP2Pデバイス間の信号伝送経路が、第3のデバイス(例えば、AP)または従来のネットワーク(例えば、APを経てWLANに接続)を経ずに当該P2Pデバイス間で直接設定された場合を意味することができる。ここで、2つのP2Pデバイス間に直接設定された信号伝送経路はデータ伝送経路に制限され得る。例えば、P2P通信は、複数のNon−STAがAPを経ずにデータ(例えば、音声/映像/文字情報など)を伝送する場合を意味することができる。制御情報(例えば、P2P設定のためのリソース割当情報、無線デバイス識別情報など)のための信号伝送経路は、P2Pデバイス(例えば、Non−AP STA−対−Non−AP STA、Non−AP STA−対−AP)間に直接設定されるか、またはAPを経由して2つのP2Pデバイス(例えば、Non−AP STA−対−Non−AP STA)間に設定されるか、またはAPと当該P2Pデバイス(例えば、AP−対−Non−AP STA#1、AP−対−Non−AP STA#2)間に設定されてもよい。
図3は、WFDネットワークを構成する手順を説明するための図である。
図3を参照すると、WFDネットワーク構成手順は2つの手順に大別することができる。1番目の手順は、近隣探索手順(Neighbor Discovery;ND procedure)であり(S302a)、2番目の手順は、P2Pリンク設定および通信手順である(S304)。近隣探索手順を通じて、P2Pデバイス(例えば、図2の202)は、(自体の無線)カバレッジ内の他の隣接P2Pデバイス(例えば、図2の204)を探し、当該P2Pデバイスとの関連付け(association)、例えば、事前−関連付け(pre-association)に必要な情報を獲得することができる。ここで、事前−関連付けは、無線プロトコルにおける第2のレイヤ事前−関連付けを意味することができる。事前−関連付けに必要な情報は、例えば、隣接P2Pデバイスに関する識別情報などを含むことができる。近隣探索手順は、使用可能無線チャネルごとに行うことができる(S302b)。その後、P2Pデバイス202は、他のP2Pデバイス204とWFD P2Pリンク設定/通信のための手順を行うことができる。例えば、P2Pデバイス202は、周辺のP2Pデバイス204に関連付けられた後、当該P2Pデバイス204がユーザのサービス要求事項を満足しないP2Pデバイスであるか否かを判断することができる。そのために、P2Pデバイス202は、周辺のP2Pデバイス204との第2のレイヤ事前−関連付け後、当該P2Pデバイス204を検索することができる。当該P2Pデバイス204がユーザのサービス要求事項を満足しない場合、P2Pデバイス202は、当該P2Pデバイス204に対して設定された第2のレイヤ関連付けを解消し、他のP2Pデバイスと第2のレイヤ関連付けを設定することができる。反面、当該P2Pデバイス204がユーザのサービス要求事項を満足する場合、2つのP2Pデバイス(202および204)は、P2Pリンクを介して信号を送受信することができる。
図4は、近隣探索手順を説明するための図である。図4の例は、図3でのP2Pデバイス202とP2Pデバイス204との間の動作として理解することができる。
図4を参照すると、図3の近隣探索手順は、SME(Station Management Entity)/アプリケーション/ユーザ/ベンダの指示により開始されてもよく(S410)、スキャン段階(scan phase)(S412)と見つける段階(find phase)(S414〜S416)とに分けられてもよい。スキャン段階(S412)は、使用可能な全ての無線チャネルに対して802.11方式に従ってスキャンする動作を含む。これによって、P2Pデバイスは、最良の動作チャネルを確認することができる。見つける段階(S414〜S416)は、リッスン(聴取)(listen)モード(S414)と検索(search)モード(S416)とを含み、P2Pデバイスは、リッスンモード(S414)と検索モード(S416)とを交互に繰り返す。P2Pデバイス202,204は、検索モード(S416)でプローブ要求フレーム(Probe request frame)を用いて能動検索を実施し、速い検索のために、検索範囲をチャネル1、6、11(例えば、2412、2437、2462MHz)のソーシャルチャネル(social channel)に限定することができる。また、P2Pデバイス202,204は、リッスンモード(S414)で3つのソーシャルチャネルのうち1つのチャネルのみを選択して受信状態に維持する。このとき、他のP2Pデバイス(例えば、202)が検索モードで伝送した、プローブ要求フレームが受信された場合、P2Pデバイス(例えば、204)は、プローブ応答フレーム(probe response frame)で応答する。リッスンモード(S414)時間はランダムに与えられてもよい(例えば、100、200、300TU(Time Unit))。P2Pデバイスは、検索モードと受信モードとを継続して繰り返す途中、互いの共通チャネルに到達することができる。P2Pデバイスは、他のP2Pデバイスを発見(discover)した後、当該P2Pデバイスに選択的に結合するために、プローブ要求フレームおよびプローブ応答フレームを用いて、デバイスタイプ、製作会社またはフレンドリデバイス名(name)を発見/交換することができる。近隣探索手順を通じて周辺のP2Pデバイスを発見し、必要な情報を得た場合、P2Pデバイス(例えば、202)は、SME/アプリケーション/ユーザ/ベンダにP2Pデバイスの発見を知らせることができる(S418)。
現在、P2Pは、主に遠隔プリント、写真共有などの半−静的(semi-static)通信のために用いられている。しかし、Wi−Fiデバイスの普遍化および位置ベースのサービスなどにより、P2Pの可用性はますます増大している。例えば、ソーシャルチャット(例えば、SNS(Social Network Service)に加入した無線デバイスが、位置ベースのサービスに基づいて近接地域の無線デバイスを認識し、情報を送受信)、位置−ベースの広告提供、位置−ベースのニュース放送、無線デバイス間のゲーム連動などにP2Pが活発に利用されると予想される。便宜上、このようなP2P応用を新P2P応用と呼ぶ。
図5は、WFDネットワークの新しい態様を説明するための図である。
図5の例は、新P2P応用(例えば、ソーシャルチャット、位置−ベースのサービス提供、ゲーム連動など)が適用される場合のWFDネットワークの態様として理解することができる。
図5を参照すると、WFDネットワークにおいて多数のP2Pデバイス(502a〜502d)がP2P通信510を行い、P2Pデバイスの移動によって、WFDネットワークを構成するP2Pデバイスが随時変更されるか、または、WFDネットワーク自体が動的/短時間的に新たに生成されたりまたは消滅したりし得る。このように、新P2P応用の特徴は、高密度(dense)ネットワーク環境においてかなりの数のP2Pデバイス間で動的/短時間にP2P通信が行われ、終了できるという点である。
図6は、WFD通信のためのリンクを設定する方法を説明するための図である。
図6(a)に示すように、第1のSTA(610、以下、Aという)は、従来のWFD通信においてグループオーナ(Group Owner)として動作中である。従来のWFD通信のグループクライアント630との通信中に、A610が、新しいWFD通信対象であり、WFD通信をしていない、第2のSTA(620、以下、Bという)を発見した場合、A610は、B620とのリンク設定を試みる。この場合、新しいWFD通信は、A610とB620との間のWFD通信であり、Aはグループオーナであるので、従来のグループクライアント630の通信と別個に通信設定を実行することができる。1つのWFDグループは、1つのグループオーナと1つまたは複数のグループクライアントとで構成することができるので、1つのグループオーナであるA610は条件を満たすので、図6(b)に示すように、WFDリンクを設定することができる。この場合、A610が従来のWFD通信グループにB620を招待(invitation)しており、WFD通信の特性上、A610とB620との間およびA610と従来のグループクライアント630との間のWFD通信は、それぞれ可能であるが、B620と従来のグループクライアント630との間のWFD通信はサポートされない。両方ともグループクライアントであるからである。
図7は、WFDを行っている通信グループに参加する(との関連付けを行う)(perform association with)方法を説明するための図である。
図7(a)に示すように、第1のSTA(710、以下、Aという)は、グループクライアント730に対してグループオーナとして通信中であり、第2のSTA(720、以下、Bという)は、グループクライアント740に対してグループオーナとして通信中である。図7(b)に示すように、A710は、従来のWFD通信を終了(termination)し、B720が属するWFD通信グループに参加(association)することができる。A710は、B720がグループオーナであるので、Bのグループクライアントとなる。A710は、B720に関連付けを要求する前に従来のWFD通信を終了することが好ましい。
図8は、WFD通信のためのリンクを設定する方法を説明するための図である。
図8(a)に示すように、第2のSTA(820、以下、Bという)は、従来のWFD通信においてグループオーナ(Group Owner)として動作中である。従来のWFD通信においてグループクライアント830とWFD通信中である場合、B820を発見した、WFD通信を行っていない第1のSTA(810、以下、Aという)が、B820との新しいWFD通信のためにリンク設定を試みる。この場合、B820がリンク設定を受諾した(accept)場合、A810とB820との間の新しいWFD通信リンクが設定され、A810は、従来のB820のWFDグループのクライアントとして動作することになる。この場合は、A810がB820のWFD通信グループに参加(association)した場合に対応する。A810は、グループオーナであるB820とのみWFD通信を行うことができ、A810と従来のWFD通信のクライアント830とのWFD通信はサポートされない。両方ともグループクライアントであるからである。
図9は、WFD通信グループに参加するリンクを設定する方法を説明するための図である。
図9(a)に示すように、第1のSTA(910、以下、Aという)は、グループオーナ930に対してグループクライアントとしてWFD通信中である。このとき、他のWFD通信のグループクライアント940に対してグループオーナとして通信中である第2のSTA(920、以下、Bという)を発見したA910は、グループオーナ930とのリンクを終了(termination)し、B920のWi−Fi Directに参加することができる。
Wi−Fiダイレクトサービス(WFDS)
Wi−Fiダイレクトは、リンク層(Link layer)の動作まで定義するネットワーク接続の標準技術である。Wi−Fiダイレクトによって構成されたリンクの上位層で動作するアプリケーションに対する標準が定義されていないため、Wi−Fiダイレクトをサポートするデバイスが互いに接続された後にアプリケーションを駆動する場合の互換性をサポートすることが難しかった。このような問題を解決するために、Wi−Fiダイレクトサービス(WFDS)という上位層アプリケーションの動作に対する標準化がWi−Fiアライアンス(WFA)で議論中である。
図10は、WFDSフレームワーク構成要素を説明するための図である。
図10のWi−Fi Direct層は、Wi−Fiダイレクト標準によって定義されるMAC層を意味する。Wi−Fi Direct層は、Wi−Fiダイレクト標準と互換性のあるソフトウェアとして構成することができる。Wi−Fi Direct層の下位では、WiFi PHYと互換性のある物理層(図示せず)によって無線接続を構成することができる。Wi−Fi Direct層の上位にASP(Application Service Platform)というプラットフォームが定義される。
ASPは、サービスが必要とする機能を実行する論理エンティティである。ASPは、共通共有プラットフォーム(common shared platform)であり、その上位のアプリケーション(Application)層とその下位のWi−Fi Direct層との間で、デバイス探索(Device Discovery)、サービス探索(Service Discovery)、ASPセッション管理(ASP Session management)、接続トポロジ管理(Connection topology management)およびセキュリティ(Security)などのタスクを処理することができる。
ASPの上位には、サービス(Service)層が定義される。サービス層は用途(use case)固有サービスを含む。WFDSでは、4個の基本サービスである伝送(送信)(Send)、プレー(再生)(Play)、ディスプレイ(表示)(Display)、プリント(印刷)(Print)サービスを定義する。WFDSで定義する4個の基本サービスを簡略に説明すると、まず、Sendは、2つのWFDSデバイス間のファイル伝送を行うことができるサービスおよびアプリケーションを意味する。伝送サービスは、ピア機器間のファイルを伝送するためのものであるという点で、ファイル伝送サービス(File Transfer Service;FTS)と呼ぶこともできる。Playは、2つのWFDSデバイス間のDLNA(登録商標)(Digital Living Network Alliance)をベースとするオーディオ/ビデオ(A/V)、写真、音楽などを共有またはストリーミングするサービスおよびアプリケーションを意味する。Printは、文書、写真などのコンテンツを有しているデバイスとプリンタとの間で文書、写真出力を可能にするサービスおよびアプリケーションを意味する。Displayは、WFAのミラキャスト(Miracast)ソースとシンクとの間で画面共有を可能にするサービスおよびアプリケーションを意味する。
図10に示されたイネーブル(Enable)API(Application Program Interface)は、WFDSで定める基本サービス以外にサードパーティ(3rd party)アプリケーションをサポートする場合に、ASP共通プラットフォームを利用できるようにするために定義される。サードパーティアプリケーションのために定義されるサービスは、1つのアプリケーションでのみ利用されてもよく、様々なアプリケーションで一般的に(または共通に)利用されてもよい。
以下、説明の便宜のため、WFDSにより定義されたサービスはWFDSサービス、WFAではなく、サードパーティによって新たに定義されるサービスはイネーブルサービスと呼ぶ。
アプリケーション層は、ユーザインターフェース(UI)を提供することができ、情報を人が認識可能な形態で表現し、ユーザの入力を下位層に伝達するなどの機能を果たす。
図11は、WFDSの動作を説明するための図である。
図11では、2つのピア(peer)デバイスAおよびBが存在するものと仮定する。
ASPは、サービスが必要とする共通の機能を具現する論理エンティティ(logical entity)である。このような機能は、デバイス探索(Device Discovery)、サービス探索(Service Discovery)、ASP−セッション管理、接続トポロジ(topology)管理、セキュリティなどを含むことができる。
ASP−セッションは、デバイスAのASPとデバイスBのASPとの間の論理リンクである。ASP−セッションを開始するために、ピアデバイス間のP2P(Peer-to-Peer)接続が必要である。ASPは、2つのデバイス間に複数のASP−セッションをセットアップすることができる。それぞれのASP−セッションは、ASP−セッションを必要とするASPによって割り当てられるセッション識別子によって識別されてもよい。
サービスは、他のサービスまたはアプリケーションにASPを用いて用途固有機能を提供する論理エンティティである。1つのデバイスのサービスは、1つまたは複数の他のデバイスの対応するサービス、およびサービス−固有プロトコル(これは、サービス標準およびASPプロトコルによって定義できる)を用いて通信することができる。
ASPとサービスとの間のインターフェースは、メソッド(Method)およびイベント(Event)で定義される。Methodは、サービスによって開始される動作を示し、Methodのパラメータ(またはフィールド)には、実行しようとする動作に関する情報が含まれてもよい。Eventは、ASPからサービスに情報を提供する。
一例として、図12は、ASPとサービスとの間のメソッドおよびイベントの伝送例を示す図である。
サービスがメソッド呼び出しを行うと、メソッド呼び出しリターン値(returning value)として制限された情報がサービスにリターンされる(returns)。全てのメソッド呼び出しは、直ちにリターンされることが原則である。したがって、サービスにリターンされる値は、メソッド呼び出しリターンの遅延を引き起こすネットワークを介して獲得された情報またはユーザから獲得された情報に依存してはならない。
ASPは、イベントを介してサービスに情報を提供する。メソッドのように、イベントもパラメータでデータを伝送する。イベントは一方向に伝送されるので、サービスがイベントのコンテンツに基づいてアクションを取ろうとする場合、メソッド呼び出しが後続しなければならない。
ASPと通信する複数のサービスは、メソッドおよびイベントを使用することができる。メソッドは、サービスからASPに伝搬され、イベントは、ASPから特定のサービスに伝搬され得る。イベントは、メソッド呼び出しに対して直ちに応答される必要はない。
再び図11を参照すると、ユーザがデバイスAとデバイスBとの間でサービスXを利用しようとする場合、それぞれのデバイス上のASPは、サービスX専用のASP−セッションをデバイス間で生成する。その後、ユーザがサービスYを利用しようとする場合、当該サービスのための新しいASP−セッションが確立(establish)される。ピア機器間に複数のASPセッションが確立された(established)場合、複数のASPセッションのそれぞれは、ASPセッションの確立を要求したピアデバイス(具体的には、ASPセッションの確立を要求したピアデバイスのASP)によって割り当てられるセッション識別子(Session Identifier)により識別することができる。
WFDSでは、2つのピアデバイス間の動作の定義において、それらのうち一方のデバイスはサービス広告器(advertiser)の役割を担い、他方のデバイスはサービス探索器(seeker)の役割を担うことができる。サービス探索器は、サービス広告器を発見(discover)し、所望のサービスを検索した場合、サービス広告器との接続を要求することもできる。
サービス探索器として設定されたピア機器は、サービス広告器として設定されたピア機器を探索し、サービス広告器として設定されたピア機器から所望のサービスを発見すると、サービス広告器として設定されたピア機器に接続を要求することができる。具体的には、サービス探索器側がサービス広告器側にASPサービスセッション確立を要求すると、サービス広告器側は、サービス探索器側のASPセッション確立要求に応答することができる。
サービス広告器とサービス探索器との関係は固定されたものではない。一例として、サービス広告器およびサービス探索器としての役割は、いずれか1つのASPセッションと次のASPセッションにおいて互いに変わってもよい。ピア機器がサービス広告器として動作するか、サービス探索器として動作するかは、どのピア機器がサービスの探索(search)を開始したか否かに基づいて決定され得る。すなわち、サービスの探索を要求するピア機器がサービス探索器として機能することができる。
また、いずれか1つのピア機器が同じサービスに対して、サービス広告器およびサービス探索器として同時に設定されてもよく、いずれか1つのピア機器が複数のサービス広告器を有するか、または複数のサービス探索器を有してもよい。一例として、いずれか1つのピア機器は、第1のWi−Fiダイレクトサービスおよび第2のWi−Fiダイレクトサービスのサービスに対してはサービス広告器として設定されると同時に、第3のWi−Fiダイレクトサービスおよび第4のWi−Fiダイレクトサービスに対してはサービス探索器として設定されてもよい。
以下では、サービス広告器およびサービス探索器についてより詳細に説明する。
サービス広告器およびサービス探索器
サービス広告器として設定されたピア機器はサービスを広告し、サービス探索器は広告されたサービスを発見(discover)することができる。サービス広告器として設定されたピア機器は、サービス広告中断メソッド(CancelAdvertiseService method)がコール(call)されるか、または広告状態が中断として設定される前まで(例えば、AdvertiseStatusパラメータのstatus値がNotAdvertisedを指示)サービスを広告することができる。サービス広告器がサービスを広告するには、事後関連付け(後連携)(post association)および事前関連付け(早期連携)(pre-association)のうち少なくとも1つを利用することができる。
サービス広告器が広告するサービスは、サービス名で識別することができる。具体的には、ピア機器は、サービス探索の間、各サービスがUTF−8サービス名文字列を含むように制御することができる。ここで、UTF−8でエンコーディングされたサービス名の長さは、255バイトまたはそれ以下であってもよい。サービス名の長さは、サービス探索要求フレームおよびサービス探索応答フレームで利用可能な空間によって決定されてもよい。
“org.wi−fi”という文字列は、WFAサービスを識別するために予約されたものであってもよい。具体的には、WFAサービス名は、次の通りである。
org.wi−fi.wfds.send.tx
org.wi−fi.wfds.send.rx
org.wi−fi.wfds.play.tx
org.wi−fi.wfds.play.rx
org.wi−fi.wfds.display.tx
org.wi−fi.wfds.display.rx
org.wi−fi.wfds.print.tx
org.wi−fi.wfds.print.rx
イネーブルサービスがorg.wi−fiで始まるサービス名を用いて広告または探索することを試み(attempt)る場合、ASPは、広告または探索に対するイネーブルサービスの試み(attempt)を拒絶することができる。イネーブルサービスのためには、逆ドメイン名表記法(Reverse domain name notation)を用いることができる。この表記法によれば、アプリケーション製作者(author)によって所有されるDNS名(例えば、example.com)における各要素(例えば、exampleおよびcom)の順序を変えて配置したもの(例えば、com.example)をイネーブルサービスのサービス名のプレフィックス(prefix)として用いることができる。
これによって、イネーブルサービス名は、次の例のように定義することができる。
com.example.serviceX
com.example.productY
com.example.04cf75db−19d1−4d84−bef3−b13b33fcfa5a
イネーブルサービスは、1つのアプリケーションのために定義されてもよく、様々なアプリケーションにおいて一般的に実行されるために定義されてもよい。
サービスは、サービス名で識別されると同時に、サービス情報で定義される。これによって、サービス名が同じサービスであるとしても、サービス情報が異なる場合、互いに異なるサービスであるものとして取り扱いされ得る。
サービスの広告において、サービス広告器は、広告されるそれぞれのサービスに広告ID(advertisement ID)を割り当てることができる。サービス広告器は、サービスごとに、互いに異なる広告IDが割り当てられるように制御することができる。
サービス広告(Service Advertisement)は、事後関連付け(後連携)(post association)でも利用することができる。そのために、ピア機器は、P2Pグループが形成された(formed)後、追加的なASPセッションの確立を可能にすることができる。
サービス探索手順は、サービス探索器がASPセッションを開始するのに必ず必要なものではない。サービス探索器は、サービス探索手順のために、アウトオブバンド(out of band)メカニズムを可能にする(allow)こともできる。なお、サービス探索器は、ピアデバイスの発見済みのサービスをキャッシュ(caching)することもできる。
サービス探索手順では、ワイルドカードサーチ(またはネームサーチ)をサポートすることができる。ワイルドカードサーチとは、プレフィックスサーチがサポートされることを意味することができる。プレフィックスサーチは、プレフィックスを含む全てのサービスの検索が可能であることを意味することができる。一例として、全てのWFAサービス(即ち、Send、Play、Display、Print)を探索するために、‘org.wi−fi.wfds.*’(または‘org.wi−fi.wfds*)という検索語を含むワイルドカードサーチが可能である。この場合、ワイルドカード検索の結果として、‘org.wi−fi.wfds’というプレフィックスを含む全てのサービスのリストがリターンされ得る。
特定のWFAサービスを探索するためには、‘org.wi−fi.wfds.servicename.*’(または‘org.wi−fi.wfds.servicename*’)(ここで、servicenameは、Send、Play、Display、Printのいずれか1つであってもよい)という検索語を含むワイルドカードサーチが可能である。この場合、ワイルドカード検索の結果として、‘org.wi−fi.wfds.servicename’というプレフィックスを含む全てのサービスのリストがリターンされ得る。イネーブルサービスの場合もワイルドカードが可能で(allowed)もよいことは勿論である。
ワイルドカードサーチは、dot(‘.’)で分離される単語に限って可能である。例えば、イネーブルサービス名が“com.example.serviceX”であれば、‘com.*’(または‘com*’)、‘com.example.*’(または‘com.example*’)に限って、ワイルドカードサーチが可能である。
以下、サービス広告器およびサービス探索器で取り扱われるメソッドおよびイベントについて詳細に説明する。
サービス広告器のメソッド
サービス広告器は、サービスの広告のためにサービス広告メソッド(Advertise Service Method)をコール(Call)することができる。これによって、サービス探索器は、広告されるサービスの検索、発見およびASPセッションを開始することができる。サービス広告メソッドには、サービス名パラメータ(またはサービス名のリストパラメータ)、ポートパラメータ、プロトコルパラメータ、共有パラメータ、自動受諾パラメータおよびサービス情報パラメータのうち少なくとも1つを含むことができる。各パラメータについての説明は、次の通りである。
i)サービス名(またはサービス名のリスト)
サービス名は、サービス探索を要求する(例えば、SeekService Methodコールを実行)サービス探索器によって検索が可能なサービスの特徴を識別する。サービス名とサービス探索器からの問い合わせ(query)に含まれる文字列との比較(comparison)を通じてサービス名マッチングを行うことができる。
マッチングされるサービスが複数である場合、サービス広告メソッドには、複数のサービス名を含むサービス名リストが含まれてもよい。一例として、サービスが同じポートで伝送および受信をサポートすれば、伝送のためのサービス名(例えば、service.tx)および受信のためのサービス名(service.rx)の全てがサービス名リストに含まれてもよい。例えば、検索が要求されるサービス名がorg.wi−fi.wfds.sendであり、サービスがorg.wi−fi.wfds.send.rxおよびorg.wi−fi.wfds.send.txを全てサポートすれば、サービス名リストには、“org.wi−fi.wfds.send”、“org.wi−fi.wfds.send.rx”および“org.wi−fi.wfds.send.tx”が全て含まれてもよい。
サービスが同じポートナンバーで全てのWFAサービスをサポートする場合、サービス名リストには、全てのWFAサービス名および全てのWFAサービスでの伝送のためのサービス名が含まれてもよい。例えば、サービスが全てのWFAサービスをサポートする場合、サービス名リストには、“org.wi−fi.wfds.send.tx、org.wi−fi.wfds.send.rx、org.wi−fi.wfds.send、org.wi−fi.wfds.play.tx、org.wi−fi.wfds.play.rx、org.wi−fi.wfds.play、org.wi−fi.wfds.display.tx、org.wi−fi.wfds.display.rx、org.wi−fi.wfds.display、org.wi−fi.wfds.print.tx、org.wi−fi.wfds.print.rx、org.wi−fi.wfds.print”が含まれてもよい。
ii)サービスポート
サービスポートは、登録されたサービスをリッスンし、サービス探索器から受信される接続のためのIPポートである。サービス広告器は、サービス名検索の結果パラメータとしてサービスポートをサービス探索器に知らせることができる。ただし、サービスポートは、サービス名のようにサービス探索器によって検索可能なものではない。サービスポートは予約されたものであるので、サービスポートを共有するように設定されていない限り(例えば、共有パラメータが“true”に設定されていない限り)、他のサービスまたは他のアクティブASPセッションが同じポートを使用することはできない。
サービス広告を要求するメソッド(AdvertiseService method)が呼び出されたとき、サービスポートが利用可能でなければ、サービス広告が失敗したことを知らせるイベント(例えば、Advertise Failed Event)がASPからサービスに伝送されてもよい。
サービスのためのASPセッションが生成され、ネットワークインターフェースが知られている状態のとき、サービスポートは、アプリケーションによってバインドされて(bound)いてもよい。
iii)プロトコル
プロトコルは、IANA(Internet Assigned Number Authority)で定義された整数として定義することができる。例えば、TCPは数字6として定義し、UDPは数字17として定義することができる。
iv)共有
共有パラメータは、他のサービスおよびサービスポートを可能にするか否かを指示する。一例として、共有パラメータの値が“True”である場合、サービスポートは、他の広告およびASPセッションによって再使用可能である。サービスポートを共有するASPセッションは、サービスポートを独占的に制御してはならない。これとは異なり、共有パラメータの値が“Service”である場合、サービスポートは、同じサービス名を有する他のサービスの広告によって再使用可能である。共有パラメータの値が“False”である場合、1つのサービスがサービスポートを独占的に制御することができる。
サービスが、現在広告中のサービスによって使用されるサービスポートの独占的使用を要求する場合、ASPは、サービスに広告が失敗したことを知らせるイベント(AdvertiseFailed Event)を伝送することができる。サービスが、独占的使用が予約された(reserved)サービスポートの共有を要求した場合にも、ASPは、サービスに広告が失敗したことを知らせるイベントを伝送することができる。なお、サービスが既に他のサービス広告メソッド(Advertise Service Method)と共有されているサービスポートを非共有(non-share)サービスポートとして設定することを要求する場合にも、ASPは、サービスに広告が失敗したことを知らせるイベントを伝送することができる。
v)自動受諾
サービス広告器のASPは、ASPセッションのセットアップのために、セッション要求イベント(SessionRequest Event)をサービス層に伝送することができる。このとき、自動受諾パラメータの値が“True”であれば、サービス広告器は、サービス層でセッション要求イベントに対する応答としてセッション確認メソッド(ConfirmSession Method)が呼び出されなくても、サービス探索器からの全てのASPセッション要求(ASP−session request)を受諾することができる。
ただし、セッション要求イベント(SessionRequest Event)でget_network_config_PINパラメータがTrueに設定されている場合、サービス層からASP層に伝送されるサービス確認メソッド(またはセッション確認メソッド)として伝送される必要がある。
自動受諾パラメータの値が“False”である場合、サービス広告器のASPは、サービスからのセッション確認メソッドの受信を待ち、ASPセッション要求を受諾するか否かを決定することができる。ASPセッションセットアップのためのセッション要求イベントは、自動受諾パラメータの値と関係なく、ASPからサービスに伝送可能である。
vi)サービス情報
サービス情報は、サービス探索手順で使用されるサービスに関する具体的な情報を意味する。サービス情報の内容(content)は、自由な形式であり(free-form)、選択的な(selective)パラメータである。サービス情報が存在する場合、サービス探索応答フレーム内で1つの応答としてサービス情報がサービス探索器に伝達されてもよい。
サービス探索器は、サービス探索メソッド(SeekService Method)内のサービス情報要求を具体化することによって、サービス情報の内容に基づいて検索を行うことができる。
vii)サービス状態
サービス状態は、サービス広告メソッドが呼び出された時点のサービスの状態を指示する。一例として、サービス状態パラメータの値が‘1’であることは、サービスが利用可能であることを指示するもので、サービス状態パラメータの値が‘0’であることは、サービスが利用不可能であることを指示するものであってもよい。ただし、サービスが利用不可能な状態であるとしても、サービス広告器は、プローブ要求フレームまたはサービス探索要求フレームに対する応答として、機器が当該サービスをサポートすることを指示することができる。
サービス状態パラメータが‘0’である場合(即ち、サービスが利用不可能な状態である場合)、ASPは、ASPセッションセットアップのための要求を拒絶することができる。
viii)ネットワークロール(network role)
ネットワークロールは、サービス広告器がP2Pグループでグループオーナ(GO)に設定されなければならないか否かを指示する。一例として、ネットワークロールパラメータが‘1’であることは、P2Pグループ内でサービス広告器がGOに設定されなければならないことを示し、ネットワークロールパラメータが‘0’であることは、サービス広告器の状態(地位)(status)は無視される(regarded)ことを意味してもよい。
ix)ネットワーク設定
ネットワーク設定パラメータは、接続のための好ましいWSC設定メソッド(WSC Config.Method)を指示する。一例として、ネットワーク設定パラメータが‘1’であることは、WFDSデフォルト設定メソッドまたはWSC PINメソッドを指示するものであってもよく、ネットワーク設定パラメータが‘2’であることは、WSC PINメソッドのみを指示するものであってもよい。
x)遅延セッション応答
明示的な特定のサービスではない限り、基本的に、遅延セッション応答パラメータの値はNullであってもよい。なお、遅延セッション応答パラメータは、自動受諾パラメータの値が“False”である場合にのみ存在し得る。
遅延セッションパラメータの値が存在する場合、遅延セッションパラメータは、サービス広告器の自動受諾パラメータの値がFalseに設定されており、サービス探索器がASPセッションを生成しようとする時に、サービス広告器からサービス探索器に伝送されるメッセージフレームと見なされてもよい。
一例として、サービス探索器がASPセッションを生成するためにプロビジョン探索(provision discovery)要求フレームを伝送する場合、遅延セッションパラメータは、サービス広告器から伝送されるプロビジョン探索応答フレームにセッション情報フィールドとして含まれてもよい。
他の例として、サービス探索器がASPセッションを生成するために、セッション要求メッセージ(Request_Session message)を伝送する場合、遅延セッション応答パラメータは、遅延セッションASPコーディネーションプロトコルメッセージ(Defferred_Session ASP coordination protocol message)の遅延セッション応答フィールドとして含まれてもよい。
ASPは、サービス広告メソッドに対して、広告IDをリターンすることができる。広告IDは、ASPによって割り当てられ、広告が要求されるサービスによって操作される機器上で一意に広告を識別する。そして、広告IDは、広告されたサービスのASPセッションの確立のために、サービス探索器に伝送されてもよい。
サービス広告器は、既に存在する(existing)広告の状態が変更された場合、サービス状態変更を知らせる、サービス状態変更メソッド(ServiceStatusChange Method)を呼び出すことができる。サービス状態変更メソッドには、広告IDおよびサービス状態パラメータが含まれてもよい。各パラメータについての説明は、次の通りである。
i)広告ID
サービス広告メソッドによってリターンされる本来の(originally)広告IDが含まれてもよい。
ii)サービス状態
サービスが利用可能な状態である場合、サービス状態パラメータの値は“Available”に設定することができる。サービス広告器によってサポートされるサービスがその瞬間利用不可能な状態である場合、サービス状態パラメータの値は“Unavailable”に設定することができる。サービス状態パラメータ値は、プローブ応答フレームまたはサービス探索応答フレームに含まれてもよい。
サービス広告器は、既に存在している広告を取り消すために、サービス広告取り消しメソッド(CancelAdvertiseService Method)を呼び出すことができる。サービス広告器がサービス広告取り消しメソッドを呼び出した場合、サービス名および関連情報(associated information)はこれ以上広告されず、サービスポートに対する予約(reservation)も解除される。
サービスがASPからセッション要求イベントを受信した場合、サービス広告器は、ASPセッションセットアップ(setup)を受諾する(accept)か否かを決定するために、セッション確認メソッド(SessionCorfirm Method)を呼び出すことができる。セッション確認メソッドは、特定のサービスに対するセッションセットアップを受諾するか否かを指示するという点で、サービス確認メソッド(ConfirmService Method)と呼ぶこともできる。ただし、広告が自動的に始まった場合(例えば、サービス広告メソッド(AdvertiseService Method)の自動受諾パラメータの値が“True”である場合)にはASPセッションセットアップが自動的に受諾されるので、セッション確認メソッドが呼び出されなくてもよい。
セッション確認メソッドには、セッションMACパラメータ、セッションIDパラメータおよび確認(Confirmed)パラメータのうち少なくとも1つが含まれてもよい。各パラメータについての詳細な説明は、次の通りである。
i)セッションMAC
セッションIDが割り当てられた機器のMACアドレスを指示する。
ii)セッションID
ASPセッションの識別子(Identifier)を指示する。
iii)確認(Confirmed)
確認パラメータの値がTrueであれば、ASPセッションセットアップを行うことができる。なお、P2Pグループが存在しない場合、グループの形成(form)も行うことができる。これとは異なり、確認パラメータの値がFalseである場合、要求されたASPセッションは終了(closed)し得る。
サービス探索器のメソッド
サービス探索器は、サービス広告器として機能するピアデバイスが有するサービスを検索するためのサービス探索を要求する、サービス探索メソッド(SeekService Method)を呼び出すことができる。検索の範囲は、選択的にMACアドレスによって制限されてもよい。サービス探索メソッドは、サービス名、完全一致(正確な)検索(exact search)、MACアドレスおよびサービス情報要求パラメータのうち少なくとも1つを含むことができる。各パラメータについての具体的な説明は、次の通りである。
i)サービス名
サービス名パラメータは、検索しなければならないサービスの名を指示する。サービス名パラメータに含まれる文字列は、検索されなければならないサービス名の正確な(完全に一致する)名であってもよく、検索されなければならないサービス名のプレフィックスであってもよい。
プレフィックスサーチの一例として、特定のサービスに対する受信サービスおよび送信サービスを検索するために、受信サービスおよび送信サービスの両方の名を含ませずに、特定のサービスの名のみを含ませることができる。例えば、Sendサービスに対して、サービスがorg.wi−fi.wfds.send.rxおよびorg.wi−fi.wfds.send.txを検索するためには、両者が共通に含むorg.wi−fi.wfds.sendをサービス名パラメータに挿入することができる。
全てのWFAサービスを検索するためには、全てのWFAサービス名が共通に含む文字列である“org.wi−fi.wfds”をサービス名パラメータに含ませることができる。
ii)完全一致検索
完全一致検索パラメータの値が“True”であれば、完全一致検索が行われる。具体的には、プローブ要求および応答フレームの交換を通じて、サービス名パラメータに含まれた文字列と完全に(正確に)一致するサービスを検索することができる。
完全一致検索パラメータの値が“False”であれば、プレフィックス検索が行われる。具体的には、プレフィックス検索のために、プローブ要求/応答フレームの交換に加えて、サービス探索要求/応答フレームの交換を行うことができる。サービス探索要求/応答フレームの交換を通じて、サービス名パラメータに含まれた文字列をプレフィックスとして含む全てのサービスを検索することができる。
機器探索の間、サービス名パラメータに含まれた文字列と完全に一致する機器のみがプローブ要求に応答するはずなので、完全一致検索はプレフィックスよりも速い。
iii)MACアドレス
全てのピアWi−Fiダイレクト機器上のサービスを検索するためのものであるので、一般に、MACアドレスパラメータはNULLに設定することができる。ただし、MACアドレスパラメータに特定のピア機器のMACアドレス値が含まれる場合、サービス検索は、明示されたMACアドレスに限って制限的に行われてもよい。ピアアドレスのMACアドレスは、コロン(:)により区分される正準フォーマット(canonical format)(例えば、“00:14:bb:11:22:33”)で含まれてもよい。
iv)サービス情報要求
サービス情報要求パラメータには、サービス広告器とサービス探索要求/応答フレームが交換されるサービス情報探索の間に追加情報を要求するための文字列が含まれてもよい。
サービス情報要求を問い合わせ(query)る文字列が、サービス広告メソッド(AdvertiseService method)に含まれたサービス情報セットの従属文字列(substring)である場合、検索結果イベント(SearchResult Event)が呼び出されてもよい。例えば、“ABC”の問い合わせ(query)文字列は、多数のサービス情報のうち“ABCpdq”または“ABC”と読まれるサービス情報とマッチングされ得る。
サービス探索要求メソッド(例えば、ServiceSeek Method)に対応して、サービス探索取り消しメソッド(例えば、CancelSeekService Method)のために使用できるハンドル(handle)パラメータがリターンされてもよい。
サービス探索器は、サービス探索を取り消すサービス探索取り消しメソッド(CancelSeek Method)を呼び出すことができる。サービス探索取り消しメソッドには、サービス探索メソッドによってリターンされるハンドルパラメータが含まれてもよい。
サービス広告器のイベント
遠隔デバイスが、広告されるサービスに対するASPセッションを始めようとする時に、サービス広告器のASPは、セッション要求イベント(SessionRequest Event)をサービスに伝送することができる。このとき、セッション要求イベントは、サービスの始まりを開始するためのものであるという点で、サービス要求イベント(ServiceRequest Event)と呼ぶこともできる。具体的には、セッション要求イベントは、サービス広告器のASPがプロビジョン探索要求フレームを受信するか、またはREQUEST_SESSION ASPコーディネーションプロトコルメッセージを受信する場合にトリガされてもよい。セッション要求イベントには、次のパラメータが含まれてもよい。
i)広告ID
サービス広告メソッドが呼び出されるとき、ASPによって割り当てられた広告識別子が含まれてもよい。
ii)セッションMAC
セッションIDが割り当てられたP2P機器のMACアドレスが含まれてもよい。
iii)サービスデバイス名
遠隔デバイスのデバイス名(具体的には、WSCによって定義されたデバイス名)が含まれてもよい。
iv)セッションID
遠隔ASPによって割り当てられたセッション識別子が含まれてもよい。
v)セッション情報
サービス固有データペイロードが含まれてもよい。セッション情報は、最大144バイトの長さを有することができる。
vi)ネットワーク設定PIN獲得(get_network_config_PIN)
サービス広告器が、サービス広告器でサービスネットワークをセットアップするためのPIN(Personal Identification Number)を必要とするWSC設定メソッド(WSC Config method)と共に、プロビジョン探索要求フレームを受信する場合、ネットワーク設定PIN獲得パラメータの値は“True”であり得る。ユーザによって入力されたWSC PINは、セッション確認メソッドに含まれてASPに提供され得る。
サービス広告器が、サービス広告器でサービスネットワークをセットアップするためのPIN(Personal Identification Number)を必要としないWSC設定メソッド(WSC Config method)と共に、プロビジョン探索要求フレームを受信するか、またはREQUEST_SESSION ASPコーディネーションプロトコルメッセージによってサービス要求イベントがトリガされた場合、ネットワーク設定PIN獲得パラメータの値は“False”であり得る。
vii)ネットワーク設定PIN
サービス広告器のASPが、サービスネットワークをセットアップするためにディスプレイされるPINを必要とするWSC設定メソッドと共にプロビジョン探索要求を受信する場合、ASPは、WSC PIN値を生成し、生成されたWSC PIN値をサービスに提供して、WSC PIN値がディスプレイされるようにすることができる。
サービス広告器のASPが、サービスネットワークをセットアップするためにディスプレイされるPINを必要としないWSC設定メソッドと共にプロビジョン探索要求を受信する場合、またはREQUEST_SESSION ASPコーディネーションプロトコルメッセージによってサービス要求イベントがトリガされた場合、ネットワーク設定PINパラメータの値は‘0’であり得る。
サービスをこれ以上広告できないか、またはサービスの広告を開始できない場合、広告の失敗を知らせるイベント(例えば、AdvertiseFailed Event)を伝送することができる。広告失敗を知らせるイベントには、広告IDおよび失敗理由パラメータが含まれてもよい。各パラメータについて簡略に説明すると、次の通りである。
i)広告ID
サービス広告メソッド(AdvertiseService Method)によってリターンされる広告ID値を指示することができる。
ii)理由
広告失敗の理由が含まれてもよい。広告失敗の理由は、サービスポートが既に共有中の場合(一例として、非共有サービスポートを要求したが、当該サービスポートが既に共有サービスポートとして利用される場合)、サービスポートが既に私的に用いられている場合(一例として、サービスポートを要求したが、サービスポートが既に私的な(専用の)サービスポートとして利用されている場合)、またはその他の失敗事由のいずれか1つを指示することができる。
サービス探索器のイベント
検索が実行中のとき、ピア機器から発見されたそれぞれの広告されるサービスのために検索結果を知らせる、検索結果イベント(SearchResult Event)が伝送されてもよい。検索結果イベントには、ハンドル、サービスMAC、広告ID、サービス名、サービス情報およびサービス状態パラメータのうち少なくとも1つが含まれてもよい。各パラメータについての説明は、次の通りである。
i)ハンドル
サービス探索メソッドによってリターンされる値を指示する。
ii)サービスMAC
ピアデバイスのMACアドレスを指示する。
iii)広告ID
ピアデバイスによって定義された広告IDを指示する。
iv)サービス名
ピアデバイスによって定義されたフル(full)サービス名を指示する。
v)サービス情報
サービス広告器とサービス検索器との間で定義された追加サービス(ベンダ(vendor))固有パラメータまたはNULL文字列が含まれる。
vi)サービス状態
サービスが利用可能な状態である場合、サービス状態パラメータの値は“Available”に設定することができる。サービス広告器によってサポートされるサービスがその瞬間利用不可能な状態である場合、サービス状態パラメータの値は“Unavailable”に設定することができる。
サービス探索器は、サービス探索メソッド(SeekService Method)によって開始された検索を中断するか、またはこれ以上の検索結果イベント(Searchresult Event)が生成されることを防止するための検索終了イベント(SearchTerminated Event)を伝送することができる。検索終了イベントには、ハンドルおよび終了理由パラメータが含まれてもよい。各パラメータについての説明は、次の通りである。
i)ハンドル
終了される検索を指示する。
ii)理由
検索の終了理由が指示されてもよい。検索の終了理由として、タイムアウト(Timeout)またはシステム誤り(System Failure)が指示されてもよい。
サービス探索器は、広告されるサービスのASPセッションを開始するために、サービス要求イベント(ServiceRequest Event)を伝送することができる。サービス要求イベントには、広告ID、セッションMAC、セッションIDおよびセッション情報パラメータのうち少なくとも1つが含まれてもよい。各パラメータについての説明は、次の通りである。
i)広告ID
ピア機器によって定義された広告識別子が含まれてもよい。
ii)セッションMAC
セッションIDが割り当てられたピアデバイスのMACアドレスが含まれてもよい。
iii)セッションID
ASPセッション識別子が含まれてもよい。
iv)セッション情報
アプリケーション固有データペイロード(payload)が含まれてもよい。
サービス探索およびASPセッションセットアップ
上述した説明に基づいて、本発明に係るサービス探索およびASPセッションセットアップ手順について詳細に説明する。
図13乃至図15は、サービス探索およびASPセッションのセットアップ動作の流れ図である。図13乃至図15に示したASPセッションセットアップ動作は、あるP2Pデバイスの特定のサービスが他のP2Pデバイスおよびサービスを探索し、サービスを要求して、Wi−Fiダイレクト接続を確立し、アプリケーションが動作する手順を意味する。
説明の便宜のため、図13乃至図15において、デバイスAは、自体のサービスを広告するサービス広告器として動作し、デバイスBは、サービスを探索するサービス探索器として動作するものと仮定する。
デバイスAのサービス層がASPにサービス広告メソッド(AdvertiseService())を伝送すると、デバイスAのASPは、サービス広告メソッドに含まれた情報に基づいて自体のサービスを広告し、他のデバイスが当該サービスを発見することができるように待機することができる。
デバイスBのサービス層がASPにサービス探索メソッド(SeekService())を伝送すると、デバイスBのASPは、受信したサービス探索メソッドに含まれた情報に基づいて、上位アプリケーションまたはユーザの所望のサービスをサポートするデバイスを探索することができる。一例として、デバイスBのサービス層が、アプリケーション層からサービスを使用する旨(Use Service)の意図を示す情報を受信すると、検索を必要とするサービスに関する情報を含むサービス探索メソッドをASPに伝達することができる。
サービス探索メソッドを受信したデバイスBのASPは、所望のサービスをサポートするデバイスを探索するために、プローブ要求フレームを伝送することができる。このとき、プローブ要求フレームには、発見しようとするまたは自体がサポート可能なサービスのサービス名(service name)をハッシュ(hash)形態に変換したハッシュ値が含まれてもよい。ハッシュ値は、ASPがサービス名またはサービス名のプレフィックス(prefix)をハッシュ形態に変換したものであって、6オクテットの長さを有することができる。プローブ要求フレームはブロードキャスト伝送されてもよく、特定の機器に対してユニキャスト伝送されてもよい。
プローブ要求フレームを受信したデバイスAは、ハッシュマッチング(hash matching)を試み、プローブ要求フレームに含まれたハッシュ値にマッチングするサービスをサポートすると判断される場合、プローブ応答フレーム(Probe Response frame)をデバイスBに伝送することができる。このとき、プローブ応答フレームには、サービス名および広告IDフィールドのうち少なくとも1つが含まれてもよい。
ハッシュ値、広告IDフィールドおよびサービス通知情報フィールドのうち少なくとも1つが、プローブ応答フレームに含まれてもよい。ハッシュ値は、プローブ要求フレームを介して要求されるハッシュ値にマッチングするサービスのハッシュ値を指示するもので、広告IDフィールドは、ASPの内部で各サービスに対する広告を一意に識別するために、ASPによって割り当てられた値であってもよい。
デバイスAから、デバイスBが発見しようとするサービスがサポートされることを知らせるプローブ要求フレームを受信すると、デバイスBは、デバイスAのサービス情報(service_information)を探索するために、サービス探索要求フレームをトリガすることができる。このとき、サービス探索要求フレームにはサービス名フィールドが含まれてもよい。サービス名フィールドは、検索しようとする完全な(complete)サービス名または検索しようとするサービス名のプレフィックスを含むことができる。
これに対して、デバイスAは、サービス名マッチング(ネームマッチ)を行って、デバイスBが発見しようとするサービスを提供するか否かを知らせるサービス探索応答フレームをデバイスBに伝送することができる。サービス探索応答フレームには、サービス名、サービス状態、広告IDおよびサービス情報が含まれてもよい。ここで、サービス名は、広告されるサービスのサービス名を指示する文字列を含むことができる。
デバイスAが、デバイスBが発見しようとするサービスをサポートするとしても、サービス探索応答フレームを伝送する時点で、デバイスBが、デバイスAが提供するサービスを利用できない場合が発生し得る。例えば、デバイスAが、デバイスAが検索するプリント(Print)サービスをサポートするが、サービス探索応答フレームを伝送する時点で、最大数の使用可能デバイスと関連付けられている(連携中である)(associated with)ので、これ以上のピアデバイスとの関連付け(連携)(association)を可能にできなければ、デバイスAは、デバイスBが検索しようとするサービスをサポートするにもかかわらず、デバイスBは、デバイスAが提供するサービスを利用できなくなる。これによって、本発明に係るデバイスAは、サービス探索応答フレームが伝送される瞬間に当該サービスを利用可能であるか否かを指示するサービス状態情報をサービス探索応答フレームに含ませることができる。
すなわち、サービス探索応答フレームが伝送される時点で当該サービスの利用が不可能であれば、サービス状態情報は、当該サービスが利用不可能であることを指示する一方、サービス探索応答フレームが伝送される時点で当該サービスの利用が可能であれば、サービス状態情報は、当該サービスを利用できることを指示することができる。サービス状態情報は、1ビットの指示子(インジケータ)(indicator)であってもよい。
広告IDフィールドは、ASPの内部で各サービスに対する広告を一意に識別するためのものであってもよい。
サービス情報フィールドは、サービス広告器であるデバイスAがサービス探索器であるデバイスBと共有できるオプション(選択的な)(optional)情報を含むことができる。与えられたサービス(即ち、デバイスBが発見しようとするサービス)に関するサービス情報が存在する場合、サービス情報フィールドには、与えられたサービスとマッチングされるプローブ応答フレームを介して伝送されたハッシュ値が含まれてもよい。
上述したサービス探索要求および応答フレームは、IEEE 802.11uシステムで定義するGAS(Generic Advertisement Protocol)を用いて行われてもよい。
デバイスBのASPは、サービス層が要求したサービス探索メソッドによって要求された動作が完了すると、検索結果イベント(SearchResult)を介して、その結果をサービスを介してアプリケーションおよびユーザに知らせることができる。
この時点までは、Wi−Fi Directのグループは形成されていない状態である。デバイスAによって提供されるサービスが利用可能であり、ユーザがデバイスAのサービスを選択してサービスがセッション接続メソッド(ConnectSession Method)(ConnectSession())を呼び出す場合、P2Pグループ形成(group formation)のために、プロビジョン探索手順を実行することができる。デバイスBとデバイスAとの間では、プロビジョン探索要求フレームおよびプロビジョン探索応答フレームを交換することができる。プロビジョン探索要求フレームおよびプロビジョン探索応答フレームの交換を通じてデバイスAとデバイスBとの間でセッション情報および接続能力情報を交換することができる。
セッション情報は、サービスを要求するデバイスが要求するサービスの概略的な情報を知らせるヒント(hint)情報である。セッション情報は、例えば、ファイル伝送サービスを要求しようとする場合に、ファイルの数、サイズなどを知らせることによって、相手がサービス要求に対する受諾/拒絶(accept/reject)を決定できるようにする情報である。接続能力は、GO交渉(Group Owner negotiation)およびP2P招待(invitation)手順でグループを生成するための情報として利用することができる。
そのために、プロビジョン探索要求フレームには、デバイスBのP2P能力(P2P capability)、P2P機器情報(P2P Device Info)、接続能力情報(Connection Capability Info)および広告IDが含まれてもよい。デバイスBのサービスが呼び出すセッション接続メソッド(ConnectSession Method)のセッション情報(session_information)がNULLでない場合、セッション情報を含むサービスインスタンスデータ(Service Instance Data)がプロビジョン探索要求フレームにさらに含まれてもよい。
サービス探索器がサービス広告器に最初に伝送するプロビジョン探索要求フレームには状態情報が含まれる必要がない。例え、サービス広告器に最初に伝送するプロビジョン探索要求フレームに状態情報が含まれるとしても、状態情報は成功(Success)であることを指示することができる。
デバイスBが、デバイスAに、デバイスBの接続能力情報を含むプロビジョン探索要求フレームを伝達すると、デバイスAのASPは、自動受諾パラメータ(Auto_Accept)の値に応じて、セッション確認メソッド(SessionConfirm Method)の受信を待たなければならないか否かを決定することができる。
図13に例示したように、自動受諾パラメータがTrueである場合、デバイスAのASPは、セッション確認メソッドがなくても、状態情報が成功(success)であることを指示するプロビジョン探索応答フレームを伝達することができる。状態情報が成功であることを指示するプロビジョン探索応答フレームには、デバイスAの接続能力情報が含まれてもよい。デバイスAのASPは、サービス層にConnectStatus(接続状態)イベントを伝達しながら、サービス要求が受諾されたことを知らせることができる。
これとは異なり、図14に例示したように、自動受諾パラメータの値がFalseである場合、デバイスAのASPは、サービス情報などを含むセッション要求イベント(SessionRequest Event)をサービス層に伝達し、サービス層は、サービス情報をアプリケーション/ユーザに伝達する。アプリケーション/ユーザが、セッション情報に基づいて当該セッションを受諾すると決定すると、サービス層を介してサービス確認メソッド(ConfirmService())がASPに伝達される。
その間、デバイスAのASPは、デバイスBにプロビジョン探索応答フレームを伝達し、その状態情報は‘延期(deferred)’に設定することができる。これは、当該サービスが即時には受諾されないことを示し、ユーザの入力を待っていることを知らせるためである。これによって、デバイスBのASPは、サービス層にConnectStatus(接続状態)イベントを伝達しながら、サービス要求が延期されたことを知らせることができる。この場合、サービスインスタンスデータ情報に含まれるセッション情報は、ユーザにサービス要求に対する受諾/拒絶を決定するためのヒントとして使用されてもよい。
ユーザがサービス要求を受諾(accept)すると、デバイスAのサービスは、サービス確認メソッドをASPに伝送し、その後、後続(follow-on)プロビジョン探索手順が行われる。すなわち、デバイスAは、デバイスBにプロビジョン探索要求フレームを伝達することができる。これを、follow−onプロビジョン探索手順と呼ぶことができる。後続プロビジョン探索手順でのプロビジョン探索要求フレームには、状態情報、接続能力および広告IDが含まれてもよい。後続プロビジョン探索手順において、プロビジョン探索要求フレームの状態情報は成功(success)であることを指示することができ、広告IDは、デバイスBがデバイスAに伝送したプロビジョン探索要求フレームに含まれた広告IDの値と同一に設定することができる。
デバイスAからプロビジョン探索要求フレームを受信すると、デバイスBのASPは、サービス層にConnectStatusイベントを伝達しながら、サービス要求が受諾されたことを知らせることができる。また、デバイスBのASPは、状態情報が成功であることを指示するプロビジョン探索応答フレームをデバイスAに伝達することができる。このとき、後続プロビジョン探索手順でのプロビジョン探索応答フレームには、状態情報、接続能力および広告IDが含まれてもよい。後続プロビジョン探索手順において、プロビジョン探索要求フレームの状態情報は成功(success)であることを指示することができる。
ユーザがサービス要求を拒否(reject)したり、デバイスAが予め設定された時間内にユーザ入力を受信できなかった場合、または、デバイスBが、サービス要求が遅延されたことを知らせるConnectStatusイベントを伝送した後、所定時間内にデバイスAからプロビジョン探索要求フレームを受信できなかった場合、デバイスAとデバイスBとの間のASPセッションセットアップは失敗し得る。
図15に例示したように、デバイスAとデバイスBとの間のASPセッションセットアップが失敗した場合、デバイスBのサービスは、アプリケーション端に相手の応答がないことを知らせ、セッション終了メソッド(SessionClose Method)(CloseSession())をASPに伝送することができる。ASPは、セッションが終了したことを知らせるセッション状態イベント(SessionStatus Event)をサービスに伝送することができる。
以下では、デバイスAとデバイスBとの間のプロビジョン探索手順が成功して終了したことを前提に、デバイスAとデバイスBとの間のP2Pグループセットアップ手順について説明する。
P2Pグループ形成方法
説明の便宜のため、図13に例示したように、サービス広告器の自動応答パラメータの値がTrueであることから、サービス広告器が直ちにプロビジョン探索要求フレームに対する応答としてプロビジョン探索応答フレームを伝送するプロビジョン探索手順を‘即時応答ケース’(または自動受諾モード)と呼ぶことにし、図14に例示したように、サービス広告器の自動応答パラメータの値がFalseであることから、後続プロビジョン探索手順を伴う場合のプロビジョン探索手順を‘遅延成功ケース’(または遅延モード)と呼ぶことにする。
また、状態情報が成功(Success)であることを指示するプロビジョン探索応答フレームを伝送するP2Pデバイスを、PD応答器(Provision Discovery Responder)または第2のP2Pデバイスと呼ぶことにする。なお、状態情報が成功(Success)であることを指示するプロビジョン探索応答フレームをトリガするプロビジョン探索要求フレームを伝送するP2Pデバイスを、PD要求器(Provision Discovery Requestor)または第1のP2Pデバイスと呼ぶことにする。
これによって、‘即時応答ケース’では、サービス探索器の役割を有するP2Pデバイス(図13におけるデバイスB)が第1のP2PデバイスまたはPD要求器であり、サービス広告器の役割を有するP2Pデバイス(図13におけるデバイスA)が第2のP2PデバイスまたはPD応答器である一方、‘遅延成功ケース’では、サービス広告器の役割を有するP2Pデバイス(図14におけるデバイスA)が第1のP2PデバイスまたはPD要求器であり、サービス探索器の役割を有するP2Pデバイス(図14におけるデバイスB)が第2のP2PデバイスまたはPD応答器であり得る。
P2Pグループのセットアップのために、第1のP2Pデバイスは、プロビジョン探索要求フレームを伝送するとき、第1のP2Pデバイスの接続能力(Connection Capability)をプロビジョン探索要求フレームに含ませることができる。接続能力は、P2Pグループを新規生成するか否かを指示するための‘新規(New)’指示子、P2Pグループにおいてグループオーナとして動作するか否かを指示するための‘グループオーナ(Group Owner;GO)’指示子、およびP2Pグループにおいてグループクライアントとして動作するか否かを指示するための‘クライアント(Client)’指示子を含むことができる。
具体的には、第1のP2Pデバイスの接続能力の新規指示子の値が1であることは、第1のP2PデバイスがGO交渉手順を通じて新しいP2Pグループを作ることを望んでいることを指示することができる。そうでない場合、新規指示子の値は0であってもよい。第1のP2Pデバイスのグループオーナ指示子の値が1であることは、第1のP2Pデバイスがグループオーナであるか、またはグループオーナになることを望んでいることを指示することができる。そうでない場合、グループオーナ指示子の値は0であり得る。第1のP2Pデバイスのクライアント指示子の値が1であることは、第1のP2Pデバイスがクライアントであるか、またはクライアントになることを望んでいることを指示することができる。そうでない場合、クライアント指示子の値は0であり得る。
新規指示子、グループオーナ指示子およびクライアント指示子は、それぞれ1bitのサイズを有することができる。表1は、新規指示子、グループオーナ指示子およびクライアント指示子のうち有効な指示子(即ち、値が1である指示子)の組み合わせに基づいたプロビジョン探索要求フレームにおける接続能力の属性(attribute)値を表で表したものである。
表1に列挙したように、接続能力の属性値0x01は、第1のP2Pデバイスの接続能力が新規を指示(即ち、新規指示子の値が1)するもので、接続能力の属性値0x02は、第1のP2Pデバイスの接続能力がクライアントを指示するもので、接続能力の属性値0x04は、第1のP2Pデバイスの接続能力がグループオーナを指示(即ち、グループオーナ指示子の値が1)するものであってもよい。
プロビジョン探索要求フレームを伝送する第1のP2Pデバイスの接続能力は、新規、クライアントおよびグループオーナのうち複数を指示することもできる。一例として、接続能力の属性値が0x03であることは、第1のP2Pデバイスの接続能力が新規およびクライアントを指示し、接続能力の属性値が0x05であることは、第1のP2Pデバイスの接続能力が新規およびグループオーナを指示し、接続能力の属性値が0x06であることは、第1のP2Pデバイスの接続能力がクライアントおよびグループオーナを指示するものであってもよい。なお、接続能力の属性値が0x07であることは、第1のP2Pデバイスの接続能力が新規、クライアントおよびグループオーナを全て指示するものであってもよい。
第1のP2Pデバイスからプロビジョン探索要求フレームを受信した第2のP2Pデバイスは、第2のP2Pデバイスの接続能力を含むプロビジョン探索応答フレームを伝送することができる。第2のP2Pデバイスの接続能力も第1のP2Pデバイスの接続能力と同様に、‘新規’指示子、‘グループオーナ’指示子および‘クライアント’指示子を含むことができる。
具体的には、第2のP2Pデバイスの接続能力の新規指示子の値が1であることは、第2のP2Pデバイスが新しいP2PグループにおけるGOを決定するためにGO交渉手順を利用できることを指示するものであってもよい。そうでない場合、新規指示子の値は0であり得る。第2のP2Pデバイスのグループオーナ指示子の値が1であることは、第1のP2Pデバイスが第2のP2PデバイスのP2Pグループに参加しなければならないことを指示するものであってもよい。そうでない場合、グループオーナ指示子の値は0であり得る。第2のP2Pデバイスのクライアント指示子の値が1であることは、第2のP2Pデバイスが第1のP2PデバイスのP2Pグループに参加したり、または第1のP2Pデバイスが独自に(independently)(自律的に(autonomously))形成したP2Pグループに参加しなければならないことを指示するものであってもよい。そうでない場合、クライアント指示子の値は0であり得る。
表2は、新規指示子、グループオーナ指示子およびクライアント指示子のうち有効な指示子(即ち、値が1である指示子)の組み合わせに基づいたプロビジョン探索応答フレームにおける接続能力の属性(attribute)値を表で表したものである。
表2に列挙したように、接続能力の属性値0x01は、第2のP2Pデバイスの接続能力が新規を指示(即ち、新規指示子の値が1)するもので、接続能力の属性値0x02は、第2のP2Pデバイスの接続能力がクライアントを指示するもので、接続能力の属性値0x04は、第2のP2Pデバイスの接続能力がグループオーナを指示(即ち、グループオーナ指示子の値が1)するものであってもよい。
プロビジョン探索応答フレームを伝送する第2のP2Pデバイスの接続能力は、第1のP2Pデバイスとは異なり、新規、クライアントおよびグループオーナのいずれか1つのみを指示するように設定することができる。
第1のP2Pデバイスおよび第2のP2Pデバイスは、各自の接続能力の属性値に応じて、GO交渉手順を開始するか否かおよび相手デバイスのP2Pグループに参加するか否かを決定することができる。
一例として、表3は、第1のP2Pデバイスおよび第2のP2Pデバイスの接続能力に基づいたP2Pグループの形成方法を表で表したものである。
表3において、要求器(Requestor)は、PD(Provision Discovery)要求フレームを伝送する第1のP2Pデバイスを意味し、応答器(Responder)は、PD要求フレームに対応してPD応答フレームを伝送する第2のP2Pデバイスを意味するものであってもよい。
表3に列挙した例のように、第1のP2Pデバイスおよび第2のP2Pデバイスの接続能力が全て新規を指示する場合、第1のP2Pデバイスおよび第2のP2Pデバイスは新しいP2Pグループを形成するために、GO交渉手順を開始することができる。具体的には、第1のP2Pデバイスの接続能力属性値が0x01であり(即ち、新規指示子の値が‘1’)、第2のP2Pデバイスの接続能力属性値も0x01である場合、第1のP2Pデバイスおよび第2のP2PデバイスはGO交渉手順を開始することができる。
一例として、図16および図17は、第1のP2Pデバイスと第2のP2Pデバイスとの間にGO交渉手順が開始される例を示した図である。図16は、即時応答ケースを例示した図であり、図17は、遅延応答ケースを例示した図である。
GO交渉手順は、第1のP2Pデバイスおよび第2のP2Pデバイスのいずれか一方が他方にP2P GO交渉要求(P2P GO Negotiation Request)フレームを伝送することによって開始することができる。このとき、P2P GO交渉要求フレームの伝送は、PD要求フレームを伝送した要求器(Requestor)側(即ち、第1のP2Pデバイス)から応答器側(即ち、第2のP2Pデバイス)に伝送されることが好ましいが、必ずこれに限定されるものではない。
他の例として、図16および図17に例示したように、常にサービス探索器として動作するP2PデバイスがP2P GO交渉要求フレームを伝送するように設定されてもよく、図示していないが、サービス広告器として動作するP2PデバイスがP2P GO交渉要求フレームを伝送するように設定されてもよい。
第1のP2Pデバイスおよび第2のP2Pデバイスの接続能力のいずれか一方はグループオーナを指示し、他方はクライアントを指示する場合、クライアントを指示する接続能力を有するP2Pデバイスは、グループオーナを指示するP2PデバイスのP2Pグループに参加(join)することができる。すなわち、グループオーナを指示するP2Pデバイスは、P2PグループにおいてGOとして設定され、クライアントを指示するP2Pデバイスは、P2Pグループにおいてクライアントとして設定され得る。
グループオーナを指示するP2PデバイスのP2Pグループ(具体的には、グループオーナを指示するP2PデバイスがグループオーナであるP2Pグループ)が存在しない場合、グループオーナを指示するP2Pデバイスは、GOとして、独自にP2Pグループを開始することができる。クライアントを指示する接続能力を有するP2Pデバイスは、グループオーナを指示する接続能力を有するP2Pデバイスによって開始されたP2Pグループにクライアントとして参加することができる。
具体的には、第1のP2Pデバイスの接続能力の属性値が0x02であり(即ち、クライアント指示子の値が‘1’)、第2のP2Pデバイスの接続能力の属性値が0x04である(即ち、グループオーナ指示子の値が‘1’)場合、第1のP2Pデバイスは、第2のP2PデバイスのP2Pグループにクライアントとして参加することができる。第2のP2PデバイスのP2Pグループが存在しなければ、第2のP2Pデバイスは、GOとして、独自にP2Pグループを開始し、第1のP2Pデバイスは、クライアントとして、第2のP2Pデバイスが独自に開始したP2Pグループに参加することができる。
これとは逆に、第1のP2Pデバイスの接続能力の属性値が0x04であり(即ち、グループオーナ指示子の値が‘1’)、第2のP2Pデバイスの接続能力の属性値が0x02である(即ち、クライアント指示子の値が‘1’)場合、第2のP2Pデバイスは、第1のP2PデバイスのP2Pグループにクライアントとして参加することができる。第1のP2PデバイスのP2Pグループが存在しなければ、第1のP2Pデバイスは、GOとして、独自にP2Pグループを開始し、第2のP2Pデバイスは、クライアントとして、第1のP2Pデバイスが独自に開始したP2Pグループに参加することができる。
一例として、図18は、第1のP2Pデバイスの接続能力がグループオーナを指示し、第2のP2Pデバイスの接続能力がクライアントを指示するときの動作を説明するために例示した図である。
第1のP2Pデバイス(デバイスB)と第2のP2Pデバイス(デバイスA)との間の接続能力情報が交換されると、GOとしての役割を有する第1のP2Pデバイスは、招待手順を開始することができる。具体的に、第1のP2Pデバイスは、クライアントとしての役割を有する第2のP2Pデバイスに招待要求フレームを伝送することができる。なお、第1のP2PデバイスのASPは、P2Pグループの形成が開始されたことを知らせるConnectStatusイベントをサービスに伝送することができる。
第1のP2Pデバイスから招待要求フレームを受信した第2のP2Pデバイスは、P2Pグループの形成が開始されたことを知らせるConnectStatusイベントをサービスに伝送し、招待要求フレームに対する応答として、第1のP2Pデバイスに招待応答フレームを伝送することができる。なお、第1のP2Pデバイスは、グループの形成が完了したことを知らせるConnectStatusイベントをサービスに伝送することができる。
第2のP2Pデバイスから招待応答フレームを受信した第1のP2Pデバイスが、グループの形成が完了したことを知らせるConnectStatusイベントをサービスに伝送することによって、第1のP2Pデバイスと第2のP2Pデバイスとの間のP2Pグループの形成が完了し得る。
図18では、第1のP2PデバイスがGOの役割を有するものと例示したが、第2のP2PデバイスがGOの役割を有する場合、第2のP2Pデバイスが第1のP2Pデバイスに招待要求フレームを伝送することによって招待手順を開始することもできる。
図18は、第1のP2Pデバイスが招待要求フレームを伝送する一例であるが、場合によって、招待要求フレームおよび招待応答フレームは省略してもよい。
ここで、第2のP2Pデバイスが参加しなければならないP2Pグループに関する情報(例えば、P2Pグループの識別子)は、プロビジョン要求メッセージまたはプロビジョン応答メッセージを介して、第1のP2Pデバイスと第2のP2Pデバイスとの間で共有されてもよい。
第1のP2Pデバイスおよび第2のP2Pデバイスの接続能力のいずれか一方は新規を指示し、他方はクライアントを指示する場合、新規を指示する接続能力を有するP2Pデバイスは、GOとして、独自にP2Pグループを開始し、クライアントを指示する接続能力を有するP2Pデバイスは、新規を指示する接続能力を有するP2Pデバイスによって開始されたP2Pグループにクライアントとして参加することができる。
具体的には、第1のP2Pデバイスの接続能力の属性値が0x01であり(即ち、新規指示子の値が‘1’)、第2のP2Pデバイスの接続能力の属性値が0x02である(即ち、クライアント指示子の値が‘1’)場合、第1のP2Pデバイスは、GOとして、独自にP2Pグループを開始し、第2のP2Pデバイスは、クライアントとして、第1のP2Pデバイスが独自に開始したP2Pグループに参加することができる。
逆に、第1のP2Pデバイスの接続能力の属性値が0x02であり(即ち、クライアント指示子の値が‘1’)、第2のP2Pデバイスの接続能力の属性値が0x01である(即ち、新規指示子の値が‘1’)場合、第2のP2Pデバイスは、GOとして、独自にP2Pグループを開始し、第1のP2Pデバイスは、クライアントとして、第2のP2Pデバイスが独自に開始したP2Pグループに参加することができる。
第1のP2Pデバイスおよび第2のP2Pデバイスの接続能力のいずれか一方は新規を指示し、他方はグループオーナを指示する場合、新規を指示する接続能力を有するP2Pデバイスは、グループオーナを指示するP2PデバイスのP2Pグループに参加することができる。すなわち、グループオーナを指示するP2Pデバイスは、P2PグループにおいてGOとして設定され、新規を指示するP2Pデバイスは、P2Pグループにおいてクライアントとして設定され得る。
グループオーナを指示するP2PデバイスのP2Pグループ(具体的には、グループオーナを指示するP2PデバイスがグループオーナであるP2Pグループ)が存在しない場合、グループオーナを指示するP2Pデバイスは、GOとして、独自にP2Pグループを開始し、新規を指示する接続能力を有するP2Pデバイスは、グループオーナを指示する接続能力を有するP2Pデバイスによって開始されたP2Pグループにクライアントとして参加することができる。
具体的には、第1のP2Pデバイスの接続能力の属性値が0x01であり(即ち、新規指示子の値が‘1’)、第2のP2Pデバイスの接続能力の属性値が0x04である(即ち、グループオーナ指示子の値が‘1’)場合、第1のP2Pデバイスは、第2のP2PデバイスのP2Pグループにクライアントとして参加することができる。第2のP2PデバイスのP2Pグループが存在しなければ、第2のP2Pデバイスは、GOとして、独自にP2Pグループを開始し、第1のP2Pデバイスは、クライアントとして、第2のP2Pデバイスが独自に開始したP2Pグループに参加することができる。
これとは逆に、第1のP2Pデバイスの接続能力の属性値が0x04であり(即ち、グループオーナ指示子の値が‘1’)、第2のP2Pデバイスの接続能力の属性値が0x01である(即ち、新規指示子の値が‘1’)場合、第2のP2Pデバイスは、第1のP2PデバイスのP2Pグループにクライアントとして参加することができる。第1のP2PデバイスのP2Pグループが存在しなければ、第1のP2Pデバイスは、GOとして、独自にP2Pグループを開始し、第2のP2Pデバイスは、クライアントとして、第1のP2Pデバイスが独自に開始したP2Pグループに参加することができる。
第1のP2Pデバイスおよび第2のP2Pデバイスの接続能力が全てクライアントのみを指示するか、またはグループオーナのみを指示する場合、P2PデバイスにおけるGOおよびクライアントの役割が明確に区分されないため、第1のP2Pデバイスと第2のP2Pデバイスとの間のP2Pグループの形成は失敗することがある。
プロビジョン探索要求フレームを伝送する第1のP2Pデバイスの接続能力は、新規、クライアントおよびグループオーナのうち複数を指示してもよいことは、先に表1を参照して説明した通りである。
第1のP2Pデバイスの接続能力が新規およびクライアントの両方を指示する場合、第1のP2Pデバイスと第2のP2Pデバイスとの間の動作は、第1のP2Pデバイスの接続能力が新規を指示する場合と同一に動作することができる。
具体的には、第1のP2Pデバイスの接続能力の属性値が0x03であり(即ち、新規指示子およびクライアント指示子の値が‘1’)、第2のP2Pデバイスの接続能力の属性値が0x01である(即ち、新規指示子の値が‘1’)場合、第1のP2Pデバイスの接続能力が0x01であった場合と同様に、第1のP2Pデバイスおよび第2のP2Pデバイスは、新しいP2Pグループの形成のためのGO交渉手順を開始することができる。
第1のP2Pデバイスの接続能力の属性値が0x03であり(即ち、新規指示子およびクライアント指示子の値が‘1’)、第2のP2Pデバイスの接続能力の属性値が0x02である(即ち、クライアント指示子の値が‘1’)場合、第1のP2Pデバイスの接続能力が0x01であった場合と同様に、第1のP2Pデバイスは、GOとして、独自にP2Pグループを開始し、第2のP2Pデバイスは、クライアントとして、第1のP2Pデバイスが独自に開始したP2Pグループに参加することができる。
第1のP2Pデバイスの接続能力の属性値が0x03であり(即ち、新規指示子およびクライアント指示子の値が‘1’)、第2のP2Pデバイスの接続能力の属性値が0x04である(即ち、グループオーナ指示子の値が‘1’)場合、第1のP2Pデバイスの接続能力が0x02(または0x01)であった場合と同様に、第1のP2Pデバイスは、第2のP2PデバイスのP2Pグループにクライアントとして参加することができる。第2のP2PデバイスのP2Pグループが存在しなければ、第2のP2Pデバイスは、GOとして、独自にP2Pグループを開始し、第1のP2Pデバイスは、クライアントとして、第2のP2Pデバイスが独自に開始したP2Pグループに参加することができる。
第1のP2Pデバイスの接続能力が新規およびグループオーナの両方を指示する場合、第1のP2Pデバイスおよび第2のP2PデバイスはGO交渉手順を開始してもよく、第1のP2Pデバイスおよび第2のP2Pデバイスのいずれか一方が他方のP2Pグループに参加してもよい。
具体的には、第1のP2Pデバイスの接続能力の属性値が0x05であり(即ち、新規指示子およびグループオーナ指示子の値が‘1’)、第2のP2Pデバイスの接続能力の属性値が0x01である(即ち、新規指示子の値が‘1’)場合、第1のP2Pデバイスの接続能力の属性値が0x01であった場合と同様に、第1のP2Pデバイスおよび第2のP2Pデバイスは、新しいP2Pグループの形成のためのGO交渉手順を開始することができる。
第1のP2Pデバイスの接続能力の属性値が0x05であり(即ち、新規指示子およびグループオーナ指示子の値が‘1’)、第2のP2Pデバイスの接続能力の属性値が0x02である(即ち、クライアント指示子の値が‘1’)場合、第1のP2Pデバイスの接続能力の属性値が0x04であった場合と同様に、第2のP2Pデバイスは、第1のP2PデバイスのP2Pグループにクライアントとして参加することができる。第1のP2PデバイスのP2Pグループが存在しなければ、第1のP2Pデバイスは、GOとして、独自にP2Pグループを開始し、第2のP2Pデバイスは、クライアントとして、第1のP2Pデバイスが独自に開始したP2Pグループに参加することができる。
第1のP2Pデバイスの接続能力の属性値が0x06であり(即ち、新規指示子およびグループオーナ指示子の値が‘1’)、第2のP2Pデバイスの接続能力の属性値が0x04である(即ち、グループオーナ指示子の値が‘1’)場合、第1のP2Pデバイスの接続能力の属性値が0x01であった場合と同様に、第1のP2Pデバイスは、第2のP2PデバイスのP2Pグループにクライアントとして参加することができる。第2のP2PデバイスのP2Pグループが存在しなければ、第2のP2Pデバイスは、GOとして、独自にP2Pグループを開始し、第1のP2Pデバイスは、クライアントとして、第2のP2Pデバイスが独自に開始したP2Pグループに参加することができる。
第1のP2Pデバイスの接続能力がクライアントとグループオーナの両方を指示する場合、第2のP2Pデバイスの接続能力がグループオーナを指示しない限り、第1のP2Pデバイスは、P2PグループにおいてGOとして設定可能である。
具体的には、第1のP2Pデバイスの接続能力の属性値が0x06であり(即ち、クライアント指示子およびグループオーナ指示子の値が‘1’)、第2のP2Pデバイスの接続能力の属性値が0x01である(即ち、新規指示子の値が‘1’)場合、第1のP2Pデバイスは、GOとして、独自にP2Pグループを開始し、第2のP2Pデバイスは、第1のP2Pデバイスが独自に開始したP2Pグループにクライアントとして参加することができる。
第1のP2Pデバイスの接続能力の属性値が0x06であり(即ち、クライアント指示子およびグループオーナ指示子の値が‘1’)、第2のP2Pデバイスの接続能力の属性値が0x02である(即ち、クライアント指示子の値が‘1’)場合、第1のP2Pデバイスの接続能力の属性値が0x04であった場合と同様に、第2のP2Pデバイスは、第1のP2PデバイスのP2Pグループにクライアントとして参加することができる。第1のP2PデバイスのP2Pグループが存在しなければ、第1のP2Pデバイスは、GOとして、独自にP2Pグループを開始し、第2のP2Pデバイスは、クライアントとして、第1のP2Pデバイスが独自に開始したP2Pグループに参加することができる。
第1のP2Pデバイスの接続能力の属性値が0x06であり(即ち、クライアント指示子およびグループオーナ指示子の値が‘1’)、第2のP2Pデバイスの接続能力の属性値が0x04である(即ち、グループオーナ指示子の値が‘1’)場合、第1のP2Pデバイスの接続能力の属性値が0x02であった場合と同様に、第1のP2Pデバイスは、第2のP2PデバイスのP2Pグループにクライアントとして参加することができる。第2のP2PデバイスのP2Pグループが存在しなければ、第2のP2Pデバイスは、GOとして、独自にP2Pグループを開始し、第1のP2Pデバイスは、クライアントとして、第2のP2Pデバイスが独自に開始したP2Pグループに参加することができる。
第1のP2Pデバイスの接続能力が新規、クライアントおよびグループオーナを全て指示する場合、第1のP2Pデバイスおよび第2のP2PデバイスはGO交渉手順を開始してもよく、第1のP2Pデバイスおよび第2のP2Pデバイスのいずれか一方が他方のP2Pグループに参加してもよい。
具体的には、第1のP2Pデバイスの接続能力の属性値が0x07であり(即ち、新規、クライアントおよびグループオーナ指示子の値が‘1’)、第2のP2Pデバイスの接続能力の属性値が0x01である(即ち、新規指示子の値が‘1’)場合、第1のP2Pデバイスの接続能力の属性値が0x01であった場合と同様に、第1のP2Pデバイスおよび第2のP2PデバイスはGO交渉手順を開始することができる。
第1のP2Pデバイスの接続能力の属性値が0x07であり(即ち、新規、クライアントおよびグループオーナ指示子の値が‘1’)、第2のP2Pデバイスの接続能力の属性値が0x02である(即ち、クライアント指示子の値が‘1’)場合、第1のP2Pデバイスの接続能力の属性値が0x04であった場合と同様に、第2のP2Pデバイスは、第1のP2PデバイスのP2Pグループにクライアントとして参加することができる。第1のP2PデバイスのP2Pグループが存在しなければ、第1のP2Pデバイスは、GOとして、独自にP2Pグループを開始し、第2のP2Pデバイスは、クライアントとして、第1のP2Pデバイスが独自に開始したP2Pグループに参加することができる。
第1のP2Pデバイスの接続能力の属性値が0x07であり(即ち、新規、クライアントおよびグループオーナ指示子の値が‘1’)、第2のP2Pデバイスの接続能力の属性値が0x04である(即ち、グループオーナ指示子の値が‘1’)場合、第1のP2Pデバイスの接続能力の属性値が0x02であった場合と同様に、第1のP2Pデバイスは、第2のP2PデバイスのP2Pグループにクライアントとして参加することができる。第2のP2PデバイスのP2Pグループが存在しなければ、第2のP2Pデバイスは、GOとして、独自にP2Pグループを開始し、第1のP2Pデバイスは、クライアントとして、第2のP2Pデバイスが独自に開始したP2Pグループに参加することができる。
パーシステントグループを用いたP2Pグループの形成
第1のP2Pデバイスおよび第2のP2PデバイスのASPは、P2Pグループを形成またはP2Pグループに参加(join)する代わりに、既に存在する(existing)パーシステント(persistent)グループの活用を選択してもよい。そのために、第1のP2Pデバイスの接続能力および第2のP2Pデバイスの接続能力は、パーシステントグループを活用するか否かを指示するパーシステントグループオーナ(Persistent Group Owner;PGO)指示子をさらに含むこともできる。
パーシステントグループ(またはP2Pパーシステントグループ)は、第1のP2Pデバイスおよび第2のP2Pデバイスが過去に形成したP2Pグループを意味することができる。具体的には、最初のグループ交渉を通じて第1のP2Pデバイスと第2のP2Pデバイスとの間にP2Pグループが生成されると、第1のP2Pデバイスおよび第2のP2Pデバイスのいずれか一方はグループオーナの役割を担い、他方はグループクライアントの役割を担う。第1のP2Pデバイスおよび第2のP2Pデバイスのうちグループオーナの役割を担うP2Pデバイスは、BSSIDを生成し、まるでアクセスポイント(Access Point;AP)のようにアクセスおよび認証のための共有キー(Shared key)を生成することができる。このとき、P2Pデバイスは、P2Pグループでの各P2Pデバイスの役割(例えば、グループオーナまたはグループクライアント)、相手P2PデバイスのMACアドレス、P2PグループのID(例えば、BSSID)および共有キーなどの接続情報を内部に格納することができる。上記のような接続情報はクレデンシャル(Credential)と呼ぶこともできる。クレデンシャルを格納しているP2Pデバイスは、以降のパーシステントグループの構成および接続時に、以前のアクセス情報であるクレデンシャルに基づいてパーシステントグループを再開始(re-invoke)することができる。
具体的には、P2Pパーシステントグループが再開始される場合、以前のグループ形成時に担っていた役割を再び担うことになる。すなわち、最初のグループの生成時にグループオーナの役割を担っていたデバイスはパーシステントグループオーナであり、以降、P2Pパーシステントグループが再開始されるとき、再びグループオーナの役割を担うことになる。この場合、以前に格納したクレデンシャルの共有キーに基づいてP2Pグループを生成することによって、パーシステントグループのクライアントがアクセスを試みるときに認証準備手順(プロビジョニング)(Provisioning)を省略することができる。
第1のP2Pデバイスの接続能力がPGOを指示することは(即ち、PGO指示子の値が‘1’)、パーシステントグループを再使用する旨を指示することができる。そうでない場合、PGO指示子の値は‘0’に設定されてもよい。
一例として、表4は、新規指示子、グループオーナ指示子、クライアント指示子およびPGO指示子のうち有効な指示子(即ち、値が1である指示子)の組み合わせに基づいたプロビジョン探索要求フレームでの接続能力の属性値を表で表したものである。
表1は、新規指示子、グループオーナ指示子およびクライアント指示子のうち有効な指示子(即ち、値が1である指示子)の組み合わせに基づいたプロビジョン探索要求フレームにおける接続能力の属性(attribute)値を表で表したものである。
表1に列挙したように、接続能力の属性値が0x08であることは、第1のP2Pデバイスの接続能力がPGOを指示(即ち、PGO指示子の値が‘1’)するものであってもよい。それに加えて、接続能力の属性値が0x09であることは、第1のP2Pデバイスの接続能力が新規およびPGOを指示するものであり、接続能力の属性値が0x0Aであることは、第1のP2Pデバイスの接続能力がクライアントおよびPGOを指示するものであってもよい。
第2のP2Pデバイスの接続能力もPGOを指示することができる。第2のP2Pデバイスの接続能力がPGOを指示することは(即ち、PGO指示子の値が‘1’)、パーシステントグループを再使用(re-invoke)することを指示することができる。そうでない場合、PGO指示子の値は‘0’に設定されてもよい。
一例として、表5は、新規指示子、グループオーナ指示子およびクライアント指示子のうち有効な指示子(即ち、値が1である指示子)の組み合わせに基づいたプロビジョン探索応答フレームにおける接続能力の属性(attribute)値を表で表したものである。
表5に列挙したように、接続能力の属性値が0x08であることは、第2のP2Pデバイスの接続能力がPGOを指示(即ち、PGO指示子の値が‘1’)するものであってもよい。
プロビジョン探索応答フレームを伝送する第2のP2Pデバイスの接続能力は、第1のP2Pデバイスとは異なり、新規、クライアント、グループオーナおよびPGOのいずれか1つのみを指示するように設定することができる。
第1のP2Pデバイスおよび第2のP2Pデバイスは、各自の接続能力の属性値に応じて、パーシステントグループを再開始するか否か、GO交渉手順を開始するか否かおよび相手デバイスのP2Pグループに参加するか否かを決定することができる。
一例として、表6は、第1のP2Pデバイスおよび第2のP2Pデバイスの接続能力に基づいたP2Pグループの形成方法を表で表したものである。
表6に示した様々な事例において少なくとも一部は、第1のP2Pデバイス(即ち、PD要求器)および第2のP2Pデバイス(即ち、PD応答器)の動作について表3を参照して解釈することができる。具体的には、表6において、第1のP2Pデバイスと第2のP2Pデバイスとの接続能力の組み合わせ(combination of connection capabilities)のうち(New,New)、(Client,GO)および(GO,Client)の組み合わせは、表3を参照して解釈することができる。
具体的には、表6において(New,New)の組み合わせは(例えば、第1のP2Pデバイスの接続能力の属性値が0x01であり、第2のP2Pデバイスの接続能力の属性値が0x01である場合、第1のP2Pデバイスの接続能力の属性値が0x05であり、第2のP2Pデバイスの接続能力の属性値が0x01である場合、第1のP2Pデバイスの属性値が0x09であり、第2のP2Pデバイスの接続能力の属性値が0x01である場合など)、表3において、第1のP2Pデバイスの接続能力の属性値が0x01であり、第2のP2Pデバイスの接続能力の属性値が0x01である時の動作が発生するということを意味することができる。言い換えると、第1のP2Pデバイスと第2のP2Pデバイスとの間にGO交渉手順が開始され得ることを意味することができる。
そして、表6において(Client,GO)の組み合わせは(例えば、第1のP2Pデバイスの接続能力の属性値が0x01であり、第2のP2Pデバイスの接続能力の属性値が0x04である場合、第1のP2Pデバイスの接続能力の属性値が0x02であり、第2のP2Pデバイスの接続能力の属性値が0x04である場合、第1のP2Pデバイスの接続能力の属性値が0x05であり、第2のP2Pデバイスの接続能力の属性値が0x04である場合、第1のP2Pデバイスの接続能力の属性値が0x06であり、第2のP2Pデバイスの接続能力の属性値が0x04である場合、第1のP2Pデバイスの接続能力の属性値が0x09であり、第2のP2Pデバイスの接続能力の属性値が0x04である場合、第1のP2Pデバイスの接続能力の属性値が0x0Aであり、第2のP2Pデバイスの接続能力の属性値が0x04である場合など)、表3において、第1のP2Pデバイスの接続能力の属性値が0x02であり、第2のP2Pデバイスの接続能力の属性値が0x04である時の動作が発生するということを意味することができる。言い換えると、第1のP2Pデバイスが第2のP2PデバイスのP2Pグループに参加したり、または第2のP2PデバイスがGOとして独自に開示したP2Pグループに、第1のP2Pデバイスがクライアントとして参加できることを意味することができる。
そして、表6において(GO,Client)の組み合わせは(例えば、第1のP2Pデバイスの接続能力の属性値が0x01であり、第2のP2Pデバイスの接続能力の属性値が0x02である場合、第1のP2Pデバイスの接続能力の属性値が0x04であり、第2のP2Pデバイスの接続能力の属性値が0x02である場合、第1のP2Pデバイスの接続能力の属性値が0x05であり、第2のP2Pデバイスの接続能力の属性値が0x02である場合、第1のP2Pデバイスの接続能力の属性値が0x06であり、第2のP2Pデバイスの接続能力の属性値が0x02である場合など)、表3において、第1のP2Pデバイスの接続能力の属性値が0x04であり、第2のP2Pデバイスの接続能力の属性値が0x02である時の動作が発生するということを意味することができる。言い換えると、第2のP2Pデバイスが第1のP2PデバイスのP2Pグループに参加したり、または第1のP2PデバイスがGOとして独自に開始したP2Pグループに、第2のP2Pデバイスがクライアントとして参加できることを意味することができる。
表6において(PGO,Client)の組み合わせ(例えば、第1のP2Pデバイスの接続能力の属性値が0x08であり、第2のP2Pデバイスの接続能力の属性値が0x02である場合、第1のP2Pデバイスの接続能力の属性値が0x09であり、第2のP2Pデバイスの接続能力の属性値が0x02である場合、第1のP2Pデバイスの接続能力の属性値が0x0Aであり、第2のP2Pデバイスの接続能力の属性値が0x02である場合など)および(Client,PGO)の組み合わせ(例えば、第1のP2Pデバイスの接続能力の属性値が0x01であり、第2のP2Pデバイスの接続能力の属性値が0x08である場合、第1のP2Pデバイスの接続能力の属性値が0x02であり、第2のP2Pデバイスの接続能力の属性値が0x08である場合、第1のP2Pデバイスの接続能力の属性値が0x06であり、第2のP2Pデバイスの接続能力の属性値が0x08である場合、第1のP2Pデバイスの接続能力の属性値が0x09であり、第2のP2Pデバイスの接続能力の属性値が0x08である場合、第1のP2Pデバイスの接続能力の属性値が0x0Aであり、第2のP2Pデバイスの接続能力の属性値が0x08である場合など)は、第1のP2Pデバイスおよび第2のP2Pデバイスのうちクライアントの接続能力を有するいずれか一方が、PGOの接続能力を有する他方のパーシステントグループ(Persistent Group)にクライアントとして参加することを意味することができる。
例えば、第1のP2PデバイスがPGOの役割を担い、第2のP2Pデバイスがクライアントの役割を担う場合、第1のP2Pデバイスは、パーシステントグループのグループオーナとして設定され、第2のP2Pデバイスは、パーシステントグループのクライアントとして参加することができる。
(Client,GO)の組み合わせ、または(GO,Client)の組み合わせにおいて、GOの役割を担うP2Pデバイスは、PD(Provision Discovery)手順に成功した後、P2Pグループを有していない場合、独自にGOになってP2Pグループを開始することができる。この場合、クライアントの役割を担うP2Pデバイスは、GOの役割を担うP2Pデバイスが独自に開始したP2Pグループに参加するために、プロビジョニング(Provisioning)手順を行わなければならない。
これとは異なり、(Client,PGO)の組み合わせ、または(PGO,Client)の組み合わせにおいて、クライアントの役割を担うP2Pデバイスがパーシステントグループに関するクレデンシャル(Credential)情報をキャッシュ(caching)していれば、プロビジョニング手順の実行を伴わずに直ちに関連付け(連携)(Association)手順を行うことができる。クライアントの役割を担うP2Pデバイスがパーシステントグループに関するクレデンシャル情報をキャッシュしていない場合であれば、パーシステントグループに参加するためにプロビジョニング手順を行わなければならないことは、上述した(Client,GO)の組み合わせの場合と同様である。
プロビジョン探索要求フレームおよびプロビジョン探索応答フレームの構造
プロビジョン探索手順は、ASPセッションのためのP2P接続をセットアップする前の主要手順である。プロビジョン探索手順を通じて、各P2Pデバイスのネットワーク上の役割(GOまたはクライアント)を確認することができ、各P2Pデバイスのネットワーク上の役割を通じて、動作チャネルなどの様々なパラメータを決定することができる。プロビジョン探索手順は、上述したように、自動受諾モードおよび後続プロビジョン探索手順が伴われる遅延モードで定義することができる。
表7は、自動受諾モードでのプロビジョン探索要求フレームおよびプロビジョン探索応答フレームのフォーマットを図式化したものである。
プロビジョン探索要求フレームに含まれる属性について説明すると、まず、P2PグループID(P2P Group ID)属性は、PD応答器が参加するP2Pグループの識別情報を指示する。P2PグループID属性は、PD要求器の接続能力がNew、Go、(New,GO)、(Client,GO)、PGO、(New,PGO)または(Client,PGO)を指示するときにのみプロビジョン探索要求フレームに存在することができる。
プロビジョン探索要求フレームの動作チャネル属性(Operating Channel attribute)は、P2Pデバイスが参加することが期待されるP2Pグループの意図された(intended)または現在(current)の動作チャネルを指示することができる。動作チャネル属性は、PD要求器の接続能力が、New、GO、(New,GO)、(Client,GO)、PGO、(New,PGO)または(Client,PGO)を指示する場合にのみプロビジョン探索要求フレームに含まれてもよい。
プロビジョン探索要求フレームのチャネルリスト属性(Channel List attribute)は、P2Pグループのオーナ(Group Owner)になるP2PデバイスのASPが、P2Pグループの動作チャネルとしてサポートすることができるチャネルを指示する。動作チャネル属性で指示されるチャネルは、チャネルリスト属性におけるチャネルのうちいずれか1つであってもよい。チャネルリスト属性は、PD要求器の接続能力がNew、(New,GO)または(New,PGO)である場合にのみプロビジョン探索要求フレームに含まれてもよい。
接続能力情報(Connection Capability Info)属性は、PD要求器の接続能力を指示する。PD要求器の接続能力がNew、GO、ClientおよびPGOのうち少なくとも1つを指示することができる。
広告ID情報(Advertisement ID Info)属性は、利用しようとするサービスの広告IDを指示する。広告IDは、サービス広告器のASPに割り当てられたものであってもよい。
プロビジョン探索要求フレームの設定タイムアウト属性(Configuration Timeout attribute)は、プロビジョン探索手順を通じた接続能力の交換の結果として新しいP2Pグループが生成される場合、ASPがプロビジョニング(Provisioning)手順を開始するために利用できる最長時間を指示する。設定タイムアウト属性は、PD要求器の接続能力がNew、(New,GO)、(GO,Client)、(New,PGO)または(PGO,Client)を指示するときにのみプロビジョン探索要求フレームに含まれてもよい。
プロビジョン探索要求フレームのリッスンチャネル属性(Listen Channel attribute)は、ASPおよびこれに対応するP2Pデバイスが、状態情報が失敗(fail)(または遅延、defer)であるプロビジョン探索応答フレームを受信した後にモニタ(monitor)しなければならないチャネルを指示することができる。リッスンチャネル属性は、PD要求器の接続能力がNewまたはClientを指示するときにのみプロビジョン探索要求フレームに含まれてもよい。
次に、プロビジョン探索応答フレームに含まれる属性を説明すると、まず、P2PグループID属性は、PD要求器が参加するP2Pグループの識別情報を指示する。P2PグループID属性は、PD応答器の接続能力がGOまたはPGOを指示するときにのみプロビジョン探索応答フレームに含まれてもよい。
プロビジョン探索応答フレームの動作チャネル属性(Operating Channel attribute)は、P2Pデバイスが参加することが期待されるP2Pグループの意図された(intended)または現在(current)の動作チャネルを指示することができる。動作チャネル属性は、PD応答器の接続能力がGOまたはPGOを指示するときにのみプロビジョン探索応答フレームに含まれてもよい。
プロビジョン探索応答フレームのチャネルリスト属性は、プロビジョン探索要求フレームを介して提供されたチャネルリストのサブセット(subset)を含むことができる。動作チャネル属性で指示されるチャネルは、チャネルリスト属性におけるチャネルのうちいずれか1つであってもよい。チャネルリスト属性は、PD応答器の接続能力が、Client、GOまたはPGOを指示するときにのみプロビジョン探索応答フレームに含まれてもよい。
プロビジョン探索要求フレームの接続能力情報属性は、PD応答器の接続能力を指示する。接続能力情報属性は、状態属性の値が成功(Success)であることを指示する場合にのみ含まれてもよい。
プロビジョン探索要求フレームの広告ID情報属性は、利用しようとするサービスの広告IDを指示する。広告IDは、サービス広告器のASPに割り当てられたものであってもよい。
プロビジョン探索要求フレームの設定タイムアウト属性(Configuration Timeout attribute)は、プロビジョン探索手順を通じた接続能力の交換の結果として新しいP2Pグループが生成される場合、ASPがプロビジョニング(Provisioning)手順を開始するために利用できる最長時間を指示する。設定タイムアウト属性は、PD応答器の接続能力がGO、ClientまたはPGOを指示する場合にのみプロビジョン探索要求フレームに含まれてもよい。
プロビジョン探索要求フレームには状態(Status)属性が含まれてもよい。ASPによってサポートされる共通の(commonly)チャネルが存在しなければ、共通チャネルがないため失敗であることを知らせる状態コード(例えば、“Fail;no common channels”)が状態属性に含まれてもよい。
ASPが、既にプロビジョン探索手順を開始した状況で他の広告IDのプロビジョン探索要求フレームを受信した場合であれば、要求を受諾できないため失敗であることを知らせる状態コード(例えば、“Fail;unable to accommodate request”)が状態属性に含まれてもよい。
サービス広告メソッド(AdvertiseService Method)の自動受諾パラメータが“Fasle”である場合、情報が現在利用不可能であるため失敗であることを知らせる状態コード(例えば、“Fail;information is currently unavailable”)が状態属性に含まれてもよい。なお、ASPは、上位層(即ち、サービス層)にセッション要求イベント(SessionRequest Event)を伝送し、予め設定された時間(例えば、120秒)のタイマを開始することができる。予め設定された時間が満了すると、プロビジョン探索手順は失敗したと見なされ、P2P接続セットアップは中断され得る。
ASPが、サービスから、confirmedパラメータの値がTrueまたはFalseであるセッション確認メソッド(ConfirmSession Method)を受信すれば、タイマを止め、リッスンチャネル属性が指示するチャネル(リッスンチャネル属性がプロビジョン探索要求フレームに含まれていない場合には動作チャネル属性が指示するチャネル)を介して後続(follow-on)プロビジョン探索要求フレームを相手P2Pデバイスに伝送することができる。
具体的には、セッション確認メソッドのconfirmedパラメータの値がTrueである場合、ユーザによって受諾されて成功したことを知らせる状態コード(例えば、“Success;Accepted by user”)が状態属性に含まれてもよい。これとは異なり、セッション確認メソッドのconfirmedパラメータの値がFalseである場合、ユーザによって拒絶されて失敗したことを知らせる状態コード(例えば、Fail;Rejected by User)が状態属性に含まれてもよい。
プロビジョン応答フレームのセッションID情報(Session ID Info)属性、広告ID情報属性、リッスンチャネル属性および動作チャネル属性は、プロビジョン探索要求フレームでの値と同じ値を有することができる。
表8は、遅延モードでのプロビジョン探索要求フレームおよびプロビジョン探索応答フレームのフォーマットを図式化したものである。
遅延モードにおける後続(follow-on)プロビジョン探索要求フレームは、自動受諾モードにおけるプロビジョン探索要求フレームとは異なり、常に状態属性を含むことができる。
遅延モードでの後続(follow-on)プロビジョン探索応答フレームは、後続プロビジョン探索要求フレームの状態属性が成功を指示する場合(例えば、状態属性が“Success;Accepted by user”という状態コードを含む場合)にのみ伝送されてもよい。
上述した実施例で説明する本発明の例示的な方法は、説明の簡明さのために一連の動作(a series of operations)として表現されているが、これは、段階が行われる順序を制限するためのものではなく、必要な場合には、それぞれの段階が同時にまたは異なる順序で行われてもよい。また、本発明で提案する方法を具現するために、図面で例示する全ての段階が必ず必要なものではない。
また、本発明に係る方法において、前述した本発明の様々な実施例で説明した事項は独立して適用されたり、または2つ以上の実施例が同時に適用されるように具現されてもよい。
図19は、本発明の一実施例に係る無線デバイスの構成を示すブロック図である。
無線デバイス10は、プロセッサ11、メモリ12、送受信器13を備えることができる。送受信器13は、無線信号を送信/受信することができ、例えば、IEEE 802システムに基づく物理層を具現することができる。プロセッサ11は、送受信器13と電気的に接続されて、IEEE 802システムに基づく物理層および/またはMAC層を具現することができる。また、プロセッサ11は、前述した本発明の様々な実施例に係るアプリケーション、サービス、ASP層のうちの1つまたは複数の動作を行うように構成されてもよい。また、前述した本発明の様々な実施例に係る無線デバイスの動作を具現するモジュールがメモリ12に格納され、プロセッサ11によって実行されてもよい。メモリ12は、プロセッサ11の内部に含まれるか、またはプロセッサ11の外部に設置されて、プロセッサ11と公知の手段によって接続されてもよい。
図19の無線デバイス10の具体的な構成は、前述した本発明の様々な実施例で説明した事項が独立して適用されたり、または2つ以上の実施例が同時に適用されるように具現されてもよく、重複する内容は明確性のために説明を省略する。
上述した本発明の実施例は様々な手段を用いて具現することができる。例えば、本発明の実施例は、ハードウェア、ファームウェア(firmware)、ソフトウェアまたはそれらの組み合わせなどによって具現することができる。
ハードウェアによる具現の場合、本発明の実施例に係る方法は、1つまたは複数のASICs(Application Specific Integrated Circuits)、DSPs(Digital Signal Processors)、DSPDs(Digital Signal Processing Devices)、PLDs(Programmable Logic Devices)、FPGAs(Field Programmable Gate Arrays)、プロセッサ、コントローラ、マイクロコントローラ、マイクロプロセッサなどによって具現することができる。
ファームウェアやソフトウェアによる具現の場合、本発明の実施例に係る方法は、以上で説明された機能または動作を実行するモジュール、手順または関数などの形態で具現することができる。ソフトウェアコードは、メモリユニットに格納されてプロセッサによって駆動されてもよい。メモリユニットは、上記プロセッサの内部または外部に位置して、既に公知の様々な手段によってプロセッサとデータを交換することができる。
上述したように開示された本発明の好ましい実施形態についての詳細な説明は、当業者が本発明を具現し、実施できるように提供された。以上では本発明の好ましい実施形態を参照して説明したが、当該技術分野における熟練した当業者は、下記の特許請求の範囲に記載された本発明の思想および領域から逸脱しない範囲内で本発明を様々に修正および変更できるということが理解できる。したがって、本発明は、ここに開示された実施形態に制限されるものではなく、ここに開示された原理および新規の特徴と一致する最も広い範囲を与えるためのものである。