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

 

【課題】無線通信システムにおいてデバイス探索及びそのための装置を提供する。
【解決手段】第1の無線デバイスのデバイス探索実行方法は、プローブ要求フレームを送信するステップと、前記プローブ要求フレームに対する応答として、第2の無線デバイスからプローブ応答フレームを受信するステップとを有することができる。ここで、前記プローブ応答フレームは、前記第2の無線デバイスが現在接続しているAP(Access Point)の情報を含むことができる。
【選択図】図25

 

 

以下の説明は、無線通信システムに関し、特に、直接通信システムにおいてデバイスを探索する方法及び装置に関する。
近年、情報通信技術の発展に伴って様々な無線通信技術が開発されている。その中でも無線LAN(WLAN)は、無線周波数技術に基づいて個人携帯用情報端末機(Personal Digital Assistant;PDA)、ラップトップコンピュータ、携帯用マルチメディアプレーヤー(Portable Multimedia Player;PMP)などのような携帯用端末機を用いて家庭、企業又は特定サービス提供地域において無線でインターネットにアクセスできるようにする技術である。
既存の無線LANシステムにおいて基本的に要求される無線アクセスポイント(AP)なしに、デバイス(device)が互いに容易に接続できるようにする直接通信技術として、Wi−Fiダイレクト(Wi−Fi Direct)またはWi−Fi P2P(peer−to−peer)の導入が議論されている。Wi−Fiダイレクトによれば、複雑な設定過程を経ることなくデバイスが互いに接続可能であり、ユーザに様々なサービスを提供するために、一般的な無線LANシステムの通信速度で互いにデータをやり取りする動作をサポートすることができる。
近年、様々なWi−Fiサポートデバイスが用いられており、特に、AP無しでWi−Fiデバイス間の通信が可能なWi−Fiダイレクトサポートデバイスの個数が増加している。WFA(Wi−Fi Alliance)ではWi−Fiダイレクトリンクを用いた様々なサービス(例えば、送信(Send)、プレイ(Play)、ディスプレイ(Display)、プリント(Print)など)をサポートするプラットホームを導入する技術が議論されている。これをWi−Fiダイレクトサービス(WFDS)と呼ぶことができる。
WFDSのうち、ディスプレイサービスによれば、Wi−Fiディスプレイ(WFD、Wi−Fi Display)ソース(Source)及びWi−Fiディスプレイシンク(Sink)は、プローブ要求及び応答フレームに含まれたWFD情報要素(IE、Information Element)を用いてお互いを探索することができる。
本発明は、WFDサービスにおいてデバイスを探索する方法を提供することを目的とする。具体的には、本発明では、WFDソースがWFDシンクから受信する情報に基づいて、WFDシンクの接続しているAP(Access Point)を確認する方法を提供することを目的とする。
本発明で達成しようとする技術的課題は、以上に言及した技術的課題に制限されず、言及していない他の技術的課題は、以下の記載から、本発明の属する技術の分野における通常の知識を有する者に明確に理解されるであろう。
上記の技術的課題を解決するために、本発明の一実施例に係る、第1の無線デバイスのデバイス探索方法は、プローブ要求フレームを送信するステップと、前記プローブ要求フレームに対する応答として、第2の無線デバイスからプローブ応答フレームを受信するステップとを有することができる。このとき、前記プローブ応答フレームは、前記第2の無線デバイスが現在接続しているAP(Access Point)の情報を含むことができる。
上記の技術的課題を解決するために、本発明の一実施例に係る、第1の無線デバイスのデバイス探索時の応答方法は、第2の無線デバイスからプローブ要求フレームを受信するステップと、前記プローブ要求フレームに対する応答として、第2の無線デバイスにプローブ応答フレームを送信するステップとを有することができる。ここで、前記プローブ応答フレームは、前記第1の無線デバイスが現在接続しているAP(Access Point)の情報を含むことができる。
上記の技術的課題を解決するための本発明の一実施例に係る、デバイス探索を行う第1の無線デバイスは、送受信器と、プロセッサとを備えることができる。ここで、前記プロセッサは、プローブ要求フレームを送信するように前記送受信器を制御し、前記送受信器が第2の無線デバイスから前記プローブ要求フレームに対する応答としてプローブ応答フレームを受信すると、前記プローブ応答フレームから、前記第2の無線デバイスが現在接続しているAP(Access Point)の情報をデコーティングすることができる。
前記の技術的課題を解決するための本発明の一実施例に係る、デバイス探索に応答するための第1の無線デバイスは、送受信器と、プロセッサとを備えることができる。ここで、前記プロセッサは、前記送受信器が第2の無線デバイスからプローブ要求フレームを受信すると、前記第1の無線デバイスが現在接続しているAP(AccessPoint)の情報を含むプローブ応答フレームが前記第2の無線デバイスに送信されるように制御することができる。
本発明について前述した一般的な説明と後述する詳細な説明は例示的なものであり、請求項に記載の発明に関する更なる説明のためのものである。
本発明によれば、WFDサービスにおいてデバイスを探索する方法及びそのための装置を提供することができる。具体的には、本発明では、WFDソースがWFDシンクから受信する情報に基づいて、WFDシンクの接続しているAPを確認する方法及び装置を提供することができる。
本発明から得られる効果は、以上に言及した効果に制限されず、言及していない他の効果は、以下の記載から、本発明の属する技術の分野における通常の知識を有する者にとって明らかになるであろう。
本明細書に添付される図面は、本発明に関する理解を提供するためのものであり、本発明の様々な実施の形態を示し、明細書の記載と共に本発明の原理を説明する。
本発明を適用可能なIEEE 802.11システムの例示的な構造を示す図である。 Wi−Fiダイレクトネットワークを例示する図である。 WFDネットワークを構成する過程を説明するための図である。 近隣発見過程を説明するための図である。 WFDネットワークの新しい様子を説明するための図である。 WFD通信のためのリンクを設定する方法を説明するための図である。 WFD通信をしている通信グループに参加(association)する方法を説明するための図である。 WFD通信のためのリンクを設定する方法を説明するための図である。 WFD通信グループに参加するリンクを設定する方法を説明するための図である。 WFDSフレームワーク構成要素を説明するための図である。 WFDソースとWFDシンクとの間にWFDセッションが構築される過程を説明するためのフローチャートである。 図11に示した過程によって、WFDソースとWFDシンクとの間にWFDセッションが構築される場合のトポロジを図式化した図である。 WFDソースとWFDシンクとの間に既にダイレクトリンクが存在する場合に、WFDセッションが構築されるトポロジを図式化した図である。 WFDソースがAPと接続されており、WFDシンクはAPと接続されていない時に、WFDセッションが構築されるトポロジを図式化した図である。 WFDソースがAPと接続されており、WFDソースとWFDシンクとの間に既にダイレクトリンクが存在する場合に、WFDセッションが構築されるトポロジを図式化した図である。 WFDソース及びWFDシンクが同一APと接続されている場合に、WFDセッションが構築されるトポロジを図式化した図である。 WFDソース及びWFDシンクが同一APと接続されている場合に、WFDセッションが構築されるトポロジを図式化した図である。 WFDソース及びWFDシンクが同一APと接続されている場合に、WFDセッションが構築されるトポロジを図式化した図である。 WFDソース及びWFDシンクが同一APと接続されている場合に、WFDセッションが構築されるトポロジを図式化した図である。 WFDシンクがAPに接続されている場合に、WFDセッションが構築されるトポロジを図式化した図である。 WFDシンクがAPに接続されている場合に、WFDセッションが構築されるトポロジを図式化した図である。 WFDソース及びWFDシンクが異なったAPに接続されている時に、WFDセッションが構築されるトポロジを図式化した図である。 WFDソース及びWFDシンクが異なったAPに接続されている時、WFDセッションが構築されるトポロジを図式化した図である。 プローブ要求フレーム及びプローブ応答フレームのフォーマットを簡略に示す図である。 WFDシンクがAPに関連付けられているとき、WFDシンクが、関連付けられたAPに関する情報を、WFDソースに知らせる例を示す図である。 WFDソースがマルチタスクを実行しているとき、タスク別エンコーディングデータが異なったWFDシンクにストリーミングされる例を示す図である。 WFDソースがマルチタスクを実行しているとき、タスク別エンコードされた複数のデータが単一のWFDシンクにストリーミングされる例を示す図である。 WFDソースがフォアグラウンド状態であるタスクとバックグラウンド状態であるタスクを異なったWFDシンクにストリーミングする例を示す図である。 WFDソースが複数のウィンドウをディスプレイしているとき、ウィンドウ別エンコーディングデータが異なったWFDシンクにストリーミングされる例を示す図である。 タスクの属性に応じてデータがストリーミングされる例を示す図である。 WFDソースに保存された写真のスライドショーをエンコーディングしたデータがWFDシンクにストリーミングされる例を説明するための図である。 WFDソースがマルチディスプレイ環境で動作しているとき、ディスプレイ別エンコーディングデータが異なったWFDシンクにストリーミングされる例を示す図である。 WFDシンクが自身の実行しているタスクと共に、受信したデータを出力する例を示す図である。 WFDソースがWFDシンクのディスプレイ別に異なるデータがストリーミングされるように制御する例を示す図である。 WFDソースがWFDシンクのディスプレイ別に異なるデータがストリーミングされるように制御する例を示す図である。 本発明の一実施例に係る無線デバイスの構成を示すブロック図である。
以下、本発明の好適な実施形態を、添付の図面を参照して詳細に説明する。添付の図面と共に以下に開示される詳細な説明は、本発明の例示的な実施形態を説明するためのもので、本発明を実施できる唯一の実施形態を示すものではない。以下の詳細な説明は、本発明の完全な理解を提供するために具体的な細部の事項を含む。しかし、当業者には、本発明がそれらの具体的な細部の事項なしにも実施可能であるということが理解される。
以下の実施例は、本発明の構成要素及び特徴を所定の形態で結合したものである。各構成要素又は特徴は、特別の言及がない限り、選択的なものとして考慮することができる。各構成要素又は特徴は、他の構成要素や特徴と結合されない形態で実施可能である。また、一部の構成要素及び/又は特徴を結合して本発明の実施例を構成してもよい。本発明の実施例で説明される動作の順序は変更可能である。ある実施例の一部の構成や特徴は、別の実施例に含まれてもよく、別の実施例の対応する構成又は特徴に取り替えられてもよい。
以下の説明で使用される特定の用語は、本発明の理解を助けるために提供されたもので、これらの特定の用語の使用は、本発明の技術的思想から逸脱しない範囲で他の形態に変更可能である。
場合によっては、本発明の概念が曖昧になることを避けるために、公知の構造及び装置を省略したり、各構造及び装置の中核的な機能を中心にしたブロック図の形式で図示したりすることができる。また、本明細書全体にわたって同一の構成要素には同一の図面符号を付して説明する。
本発明の実施例は、無線アクセスシステムである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)、IEEE802−20、E−UTRA(Evolved UTRA)などのような無線技術によって実現することができる。明確性のために、以下ではIEEE 802.11システムを中心に説明するが、本発明の技術的思想がこれに制限されるものではない。
WLANシステムの構造
図1は、本発明を適用できるIEEE802.11システムの例示的な構造を示す図である。
IEEE802.11構造は複数個の構成要素を含むことができ、これらの相互作用によって上位層に対してトランスペアレントな移動性をサポートするWLANを提供することができる。基本サービスセット(Basic Service Set;BSS)はIEEE 802.11 LANにおける基本的な構成ブロックに該当し得る。図1では、2個のBSS(BSS1及びBSS2)が存在し、それぞれのBSSのメンバーとして2個のSTAが含まれること(STA1及びSTA2はBSS1に含まれ、STA3及びSTA4はBSS2に含まれる)を例示的に示している。図1において、BSSを示す楕円は、当該BSSに含まれたSTAが通信を維持するカバレッジ領域を示すものと理解してもよい。この領域をBSA(Basic Service Area)と呼ぶことができる。STAがBSAの外へ移動すると、当該BSA内の他のSTAと直接通信できなくなる。
IEEE 802.11 LANにおいて最も基本的なタイプのBSSは、独立したBSS(IndependentBSS;IBSS)である。例えば、IBSSは、2個のSTAだけで構成された最小の形態を有することができる。また、最も単純な形態であるとともに他の構成要素が省略されている図1のBSS(BSS1又はBSS2)がIBSSの代表的な例示に該当し得る。このような構成は、STA同士が直接通信できる場合に可能である。また、このような形態のLANは、予め計画して構成されるものではなく、LANが必要な場合に構成され、これをアドホック(ad−hoc)ネットワークと呼ぶこともできる。
STAの電源オン/オフ、STAのBSS領域への出入りなどによって、BSSでのSTAのメンバーシップが動的に変更され得る。BSSのメンバーになるためには、STAは同期化過程を用いてBSSにジョインすることができる。BSS基盤構造の全てのサービスにアクセスするためには、STAはBSSに関連付けられて(associated)いなければならない。このような関連付け(association)は動的に設定することができ、分配システムサービス(Distribution System Service;DSS)の利用を含むことができる。
層構造
無線LANシステムで動作するSTAの動作は、層(layer)構造の観点で説明することができる。装置構成の面で層構造はプロセッサによって実現することができる。STAは複数の層の構造を有することができる。例えば、802.11標準文書において扱う層構造は、主にDLL(Data Link Layer)のMAC副層(sublayer)及び物理(PHY)層である。PHYは、PLCP(Physical Layer Convergence Procedure)エンティティ、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)から層に依存した状態を収集し、層特有のパラメータなどの値をほぼ同一に設定するなどの機能を担当するものと見られる。一般に、SMEは、一般のシステム管理エンティティを代表して(on behalf of)このような機能を行い、標準管理プロトコルを実現することができる。
前述したエンティティは、様々な方式で相互作用する。例えば、エンティティ間ではGET/SETプリミティブ(primitive)を交換(exchange)することによって相互作用することができる。プリミティブは、特定の目的に関連した要素(element)やパラメータのセットを意味する。XX−GET.requestプリミティブは、与えられたMIB attribute(管理情報ベースの属性情報)の値を要求するために使用される。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.4.GHz又は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には、Wi−Fiダイレクト(Wi−Fi Direct)ネットワークを例示する。Wi−Fiダイレクトネットワークは、Wi−Fi装置がホームネットワーク、オフィスネットワーク及びホットスポットネットワークに参加しなくても、互いにデバイス対デバイス(Device to Device;D2D)(或いは、Peer−to−Peer;P2P)通信が可能なネットワークであり、Wi−Fiアライアンス(Alliance)によって提案された。以下、Wi−Fiダイレクトベースの通信を、Wi−FiダイレクトD2D通信(単に、D2D通信)或いはWi−FiダイレクトP2P通信(単に、P2P通信)と呼ぶ。また、Wi−FiダイレクトP2P実行デバイスを、Wi−FiダイレクトP2Pデバイス、単に、P2Pデバイス又はピア(Peer)デバイスと呼ぶ。
Wi−Fiダイレクトネットワーク200は、図2に示すように、第1のP2Pデバイス202及び第2のP2Pデバイス204のように、少なくとも一つのWi−Fiデバイスを含むことができる。P2Pデバイスとしては、ディスプレイ装置、プリンタ、デジタルカメラ、プロジェクター及びスマートフォンなどの、Wi−Fiをサポートするデバイスを含む。また、P2Pデバイスは、Non−AP STA及びAP STAを含む。図の例示では、第1のP2Pデバイス202は携帯電話であり、第2のP2Pデバイス204はディスプレイ装置である。Wi−Fiダイレクトネットワーク内のP2Pデバイスは互いに直接接続することができる。具体的には、P2P通信は、2つのP2Pデバイス間の信号送信経路が、第3のデバイス(例えば、AP)又は既存ネットワーク(例えば、APを経てWLANに接続)を経由せずに当該P2Pデバイスの間に直接設定された場合を意味することができる。ここで、両P2Pデバイスの間に直接設定された信号送信経路は、データ送信経路に制限されてもよい。例えば、P2P通信は、複数のNon−STAがAPの介入無しでデータ(例、音声/画像/文字情報など)を送信する場合を意味することができる。制御情報(例、P2P設定のためのリソース割り当て情報、無線デバイス識別情報など)のための信号送信経路は、P2Pデバイス(例えば、Non−AP STA対Non−AP STA、Non−AP STA対AP)間に直接設定されたり、APを経由して両P2Pデバイス(例えば、Non−AP STA対Non−AP STA)間に設定されたり、又はAPと当該P2Pデバイス(例えば、AP対Non−AP STA#1、AP対Non−AP STA#2)との間に設定されてもよい。
図3は、Wi−Fiダイレクトネットワークを構成する過程を説明するための図である。
図3を参照すると、Wi−Fiダイレクトネットワーク構成過程は、2つの過程に大別できる。第一の過程は、近隣発見過程(Neighbor Discovery(ND)procedure)であり(S302a)、第二の過程は、P2Pリンク設定及び通信過程である(S304)。近隣発見過程で、P2Pデバイス(例えば、図2の202)は(自身の無線)カバレッジ内の他の近隣P2Pデバイス(例えば、図2の204)を探し、当該P2Pデバイスとの関連付け(association)、例えば、事前関連付け(pre−association)に必要な情報を取得することができる。ここで、事前関連付けは、無線プロトコルにおける第2層の事前関連付けを意味することができる。事前関連付けに必要な情報は、例えば、近隣P2Pデバイスに関する識別情報などを含むことができる。近隣発見過程は、使用可能な無線チャネル別に行うことができる(S302b)。その後、P2Pデバイス202は、他のP2Pデバイス204とWi−Fiダイレクト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がユーザのサービス要求事項を満たす場合には、両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個のソーシャルチャネルから一つのチャネルのみを選択して受信状態に維持する。このとき、他のP2Pデバイス(例、202)が検索モードで送信したプローブ要求フレームが受信された場合、P2Pデバイス(例えば、204)は、プローブ応答フレーム(probe response frame)で応答する。聴取モードS414の時間はランダムに与えられてもよい(例えば、100、200、300TU(Time Unit))。P2Pデバイスは、検索モードと受信モードを繰り返してお互いの共通チャネルに到達することができる。P2Pデバイスは他のP2Pデバイスを発見した後、当該P2Pデバイスに選択的に結合するために、プローブ要求フレームとプローブ応答フレームを用いてデバイスタイプ、メーカー又は親しみのあるデバイス名(name)を発見/交換することができる。近隣発見過程で周辺P2Pデバイスを発見し、必要な情報を得た場合、P2Pデバイス(例えば、202)は、SME/アプリケーション/ユーザ/ベンダーにP2Pデバイス発見を知らせることができる(S418)。
現在、P2Pは主に、遠隔プリント、写真共有などのような半静的(semi−static)な通信のために用いられている。しかし、Wi−Fiデバイスの一般化と位置ベースのサービスなどによって、P2Pの活用は拡大の一路にある。例えば、ソーシャルチャット(例えば、SNS(Social Network Service)に加入した無線デバイスが位置ベースサービスに基づいて近接地域の無線デバイスを認識して情報を送受信)、位置ベースの広告提供、位置ベースのニュース放送、無線デバイス間のゲーム連動などにP2Pが盛んに用いられると予想される。便宜上、このようなP2P応用を、新規P2P応用と呼ぶ。
図5は、Wi−Fiダイレクトネットワークの新しい様子を説明するための図である。
図5の例示は、新規P2P応用(例えば、ソーシャルチャット、位置ベースのサービス提供、ゲーム連動など)が適用される場合のWi−Fiダイレクトネットワークの様子と理解してもよい。
図5を参照すると、Wi−Fiダイレクトネットワークにおいて多数のP2Pデバイス502a〜502dがP2P通信510を行っており、P2Pデバイスの移動によってWi−Fiダイレクトネットワークを構成するP2Pデバイスが随時変更されたり、Wi−Fiダイレクトネットワーク自体が動的に/短時間で新しく生成されたり消滅したりする。このように、新規P2P応用部分の特徴は、密集(dense)ネットワーク環境において相当数のP2Pデバイス間で動的に/短時間にP2P通信がなされ、終了し得るという点である。
図6は、Wi−Fiダイレクト通信のためのリンクを設定する方法を説明するための図である。
図6aに示すように、第1のSTA(610、以下、Aと称する。)は、既存のWi−Fiダイレクト通信においてグループオーナー(Group Owner)として動作している。既存Wi−Fiダイレクト通信のグループクライアント630との通信中にA(610)が、新しいWi−Fiダイレクト通信対象である、Wi−Fiダイレクト通信をしていない、第2のSTA(620、以下、Bと称する。)を発見した場合、A(610)はB(620)とのリンク設定を試みる。この場合、新しいWi−Fiダイレクト通信は、A(610)とB(620)との間のWi−Fiダイレクト通信であり、Aはグループオーナーであるから、既存のグループクライアント630との通信とは別に通信設定を行うことができる。一つのWi−Fiダイレクトグループは一つのグループオーナーと一つ以上のグループクライアントとで構成でき、ここでは、一つのグループオーナーであるA(610)を満たすので、図6bに示すように、Wi−Fiダイレクトリンクを設定することができる。これは、A(610)が既存のWi−Fiダイレクト通信グループにB(620)を招待(invitation)した場合であり、Wi−Fiダイレクト通信の特性上、A(610)とB(620)との間、A(610)と既存のグループクライアント630との間のWi−Fiダイレクト通信が可能である。なお、B(620)と既存のグループクライアント630との間のWi−Fiダイレクト通信も、デバイスの能力(capability)に応じて選択的にサポート可能である。
図7は、Wi−Fiダイレクト通信をしている通信グループに参加(association)する方法を説明するための図である。
図7aに示すように、第1のSTA(710、以下、Aと称する。)は、グループクライアント730に対してグループオーナーとして通信中であり、第2のSTA(720、以下、Bと称する。)は、グループクライアント740に対してグループオーナーとして通信中である。図7bに示すように、A(710)は、既存のWi−Fiダイレクト通信を終了(termination)し、B(720)の属したWi−Fiダイレクト通信グループに参加(association)することができる。A(710)は、B(720)がグループオーナーであるから、Bのグループクライアントとなる。A(710)は、B(720)に関連付けを要求する前に、既存のWi−Fiダイレクト通信を終了することが好ましい。
図8は、Wi−Fiダイレクト通信のためのリンクを設定する方法を説明するための図である。
図8aに示すように、第2のSTA(820、以下、Bと称する。)は、既存のWi−Fiダイレクト通信においてグループオーナー(Group Owner)として動作中である。既存のWi−Fiダイレクト通信においてグループクライアント830とWi−Fiダイレクト通信中である場合、B(820)を発見した、Wi−Fiダイレクト通信をしていない第1のSTA(810、以下、Aと称する。)がB(820)との新しいWi−Fiダイレクト通信のためにリンク設定を試みる。この場合、B(820)がリンク設定を受諾すると、A(810)とB(820)との間の新しいWi−Fiダイレクト通信リンクが設定され、A(810)は既存のB(820)のWi−Fiダイレクトグループのクライアントとして動作するようになる。これは、A(810)がB(820)のWi−Fiダイレクト通信グループに参加(association)した場合となる。A(810)はグループオーナーであるB(820)のみとWi−Fiダイレクト通信することができる。なお、A(810)と既存のWi−Fiダイレクト通信のクライアント830との間のWi−Fiダイレクト通信は、デバイスの能力に応じて選択的に可能である。
図9は、Wi−Fiダイレクト通信グループに参加するリンクを設定する方法を説明するための図である。
図9aに示すように、第1のSTA(910、以下、Aと称する。)は、グループオーナー930に対してグループクライアントとしてWi−Fiダイレクト通信中である。このとき、他のWi−Fiダイレクト通信のグループクライアント940に対してグループオーナーとして通信中である第2のSTA(920、以下、Bと称する。)を発見したA(910)は、グループオーナー930とのリンクを終了(termination)し、B(920)のWi−Fiダイレクト通信グループに参加することができる。
Wi−Fiダイレクトサービス(WFDS)
Wi−Fiダイレクトは、リンク層(Link layer)の動作まで定義するネットワーク接続標準技術である。Wi−Fiダイレクトによって構成されたリンクの上位層で動作するアプリケーションに対する標準が定義されていないことから、Wi−Fiダイレクトをサポートするデバイスが相互接続された後にアプリケーションを駆動する場合の互換性をサポートすることが難しかった。このような問題を解決するために、Wi−Fiダイレクトサービス(WFDS)という上位層アプリケーションの動作に対する標準化がWi−Fiアライアンス(WFA)で議論されている。
図10は、WFDSフレームワーク構成要素を説明するための図である。
図10のWi−Fiダイレクト層は、Wi−Fiダイレクト標準によって定義されるMAC層を意味する。Wi−Fiダイレクト層は、Wi−Fiダイレクト標準と互換性のあるソフトウェアとして構成することができる。Wi−Fiダイレクト層の下位には、Wi−Fi PHYと互換性のある物理層(図示せず)によって無線接続が構成されてもよい。Wi−Fiダイレクト層の上位にASP(Application Service Platform)というプラットホームが定義される。
ASPは、サービスが必要とする機能を実行する論理エンティティである。ASPは共通共有プラットホーム(common shared platform)であり、上位のアプリケーション(Application)層と下位のWi−Fiダイレクト層との間においてデバイス探索(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は、両WFDSデバイス間でファイル伝送が可能なサービス及びアプリケーションを意味する。送信サービスは、ピア機器間のファイルを伝送するためのものである点で、ファイル伝送サービス(File Transfer Service、FTS)と呼ぶこともできる。Playは、DLNA(Digital Living Network Alliance)に基づき、2つのWFDSデバイス間でオーディオ/ビデオ(A/V)、写真、音楽などを共有又はストリーミングするサービス及びアプリケーションを意味する。Printは、文書、写真などのコンテンツを有するデバイスとプリンタとの間で文書、写真の出力を可能にするサービス及びアプリケーションを意味する。Displayは、WFAのミラキャスト(Miracast)ソースとシンクとの間に画面共有を可能にするサービス及びアプリケーションを意味する。
図10に示すイネーブル(Enable)API(Application Program Interface)は、WFDSで定める基本サービスの他にサードパーティー(3rd party)アプリケーションをサポートする場合にASP共通プラットホームを利用可能にするために定義される。サードパーティーアプリケーションのために定義されるサービスは、一つのアプリケーションでのみ利用されてもよく、様々なアプリケーションで一般に(又は共通に)利用されてもよい。
説明の便宜のために、WFDSによって定義されたサービスはWFDSサービス、WFA以外のサードパーティーによって新しく定義されるサービスはイネーブルサービスと呼ぶものとする。
アプリケーション層はユーザインターフェース(UI)を提供することができ、情報を人にとって認識可能な形態で表現し、ユーザの入力を下位層に伝達するなどの機能を果たす。
上述した説明に基づいて、WFDSのうちディスプレイ(Display)サービスについてより詳しく説明する。
Wi−Fi Display
WFDSのうち、ディスプレイサービスは、P2Pデバイス間に画面共有を可能にするサービス及びアプリケーションを意味する。ディスプレイサービスを利用するP2Pデバイスを、WFDデバイスと呼ぶことができ、WFDデバイスのうち、P2Pリンクを介してマルチメディアコンテンツのストリーミングをサポートする機器をWi−Fiディスプレイ(WFD)ソース(Source)、P2Pリンクを介してWFDソース機器から受信してレンダリングする機器をWFDシンク(Sink)と呼ぶことができる。
図11は、WFDソースとWFDシンクとの間にWFDセッションが構築される過程を説明するためのフローチャートである。WFDソース及びWFDシンクはまず、WFDデバイス探索(WFD Device Discovery)によって、WFD接続セットアップに先立ってお互いの存在を探索することができる。具体的には、WFDデバイスは、WFD情報要素(WFD IE)を含むプローブ要求フレーム及びプローブ応答フレームを用いてお互いの存在を認識できる。WFD情報要素は、デバイスタイプ及びデバイス状態などの、WFDデバイス間の最適な接続を構築するための基本情報を含むことができる。WFDデバイスが、WFD IEを含むプローブ要求フレームを受信すると、それに対する応答として、自身のWFD IEを含むプローブ応答フレームを送信することができる。
仮にWFDデバイスがAPと関連付けられており、Wi−Fi P2Pデバイスとして動作する場合、物理的な一つのデバイスに2個以上のWi−Fi送受信機が論理的に動作するようになる。このとき、WFDデバイス探索のためには、このうちの、Wi−Fiダイレクト送受信機を使用するようになる。WFDデバイスの探索のためのプローブ要求フレームには、WFD IEの他、P2P情報要素(IE)が含まれてもよく、これは、Wi−Fiダイレクト送受信機によってデコーディング可能である。
その後、WFDソース及びWFDシンクは、WFD接続セットアップに先立ってお互いのサービス能力を探索することができる。具体的には、いずれか一つのWFDデバイスが、WFD能力が情報副要素(information subelement)として含まれるサービス探索要求フレームを送信すると、他のWFDデバイスはそれに対する応答として、自身のWFD能力が情報副要素として含まれるサービス探索応答フレームを送信することができる。サービス探索手順は選択的な手順であり、サービス探索手順をサポートするWFDデバイスは、サービス探索手順をサポートする探索されたWFDデバイスとサービス探索手順を行うことができる。サービス探索手順を行うために、デバイス探索手順に用いられるプローブ要求フレーム及び応答フレームには、WFDデバイスがサービス探索手順をサポートする能力を有するか否かを示す情報が含まれてもよい。
その後、WFDソース又はWFDシンクは、WFD接続セットアップのためのピアWFDデバイスを選択することができる。ユーザの入力によってWFD接続セットアップを行うピアWFDデバイスが選択されてもよく、ポリシー(policy)によって自動でWFD接続セットアップを行うピアWFDデバイスが選択されてもよい。
その後、WFDデバイスは、選択されたピアWFDデバイスとWFD接続セットアップ方法を選択することができる。具体的には、WFDデバイスは、Wi−Fi P2P又はTDLSのいずれかの接続スキーム(Connectivity Scheme)でWFD接続を構築することができる。WFDデバイスは、好ましい接続(Preferred Connectivity)情報と、WFD情報要素と併せて伝達される関連付けられたBSSID副要素とに基づいて、接続スキームを決定することができる。
WFDデバイスの間に、Wi−Fi P2P又はTDLSを用いて正常にWFDセットアップが行われると、WFDデバイスはWFD能力交渉(WFD capability negotiation)を行うことができる。具体的には、WFDソース及びWFDシンクは、RTSP(Real−Time Streaming Protocol)プロトコルを用いてメッセージを交換することによって、WFDセッションにおけるオーディオ/ビデオペイロード(payload)を定義するパラメータセットを決定することができる。
WFD能力交渉段階が正常に終了すると、WFDソースとWFDシンクとの間にWFDセッション(又はミラキャストセッション)が構築され、WFDソースからWFDシンクにオーディオ/ビデオコンテンツをストリーミングすることができる。
図12は、図11に示した過程によって、WFDソースとWFDシンクとの間にWFDセッションが構築される場合のトポロジを図式化した図である。図12の例示のように、WFDソース及びWFDシンクは、WFDデバイス探索/サービス探索を行った後、ダイレクトリンク(例えば、Wi−Fi P2Pリンク又はTDLSリンク)を構築することができる。その後、WFDセッション(又はミラキャストセッション)が構築されると、WFDソースからWFDシンクにコンテンツをストリーミングすることができる。
この例示とは違い、WFDソースとWFDシンクとの間に既にダイレクトリンク(例えば、Wi−Fi P2Pリンク又はTDLSリンク)が構築されていてもよい。この場合、WFDソース及びWFDシンクは、既に構築されたダイレクトリンクを解除し、新しくダイレクトリンクを構築する代わりに、既存のダイレクトリンクを用いてWFDセッションを構築することもできる。
一例として、図13は、WFDソースとWFDシンクとの間に既にダイレクトリンクが存在する場合に、WFDセッションが構築されるトポロジを図式化した図である。WFDソースとWFDシンクとの間に既にダイレクトリンクが存在すると、該ダイレクトリンクをミラキャストに再使用することができる。
図13に示す例のように、WFDデバイス間に既にIP接続が構築されている状態では、WFDデバイス間のWFDデバイス探索/サービス探索はIPパケットによって行われてもよく、図11で説明したとおり、プローブ要求及び応答フレーム、サービス要求及び応答フレームによって行われてもよい。
なお、WFDセッションは、IPパケット又はLayer2フレーム(例えば、MACフレーム)を用いて既存のダイレクトリンク上で接続が開始されてもよい。
次に、WFDソースがAPと接続された状態でWFDセッションが構築される過程について説明する。図14は、WFDソースがAPと接続されており、WFDシンクはAPと接続されていないときに、WFDセッションが構築されるトポロジを図式化した図である。WFDソースが複数のP2Pリンクを有してもよいP2P同時サポートモード(P2P Concurrent Mode)をサポートするなら、WFDソースはAPとの接続を維持した状態でWFDデバイス探索/サービス探索を行った後、既存APとの接続を維持しながら、WFDシンクとダイレクトリンクを生成することができる。
これと違い、WFDソースがP2P同時サポートモードをサポートしないなら、WFDソースは、既存APとのインフラストラクチャーリンクを解除した後、WFDデバイス探索/サービス探索を行うことができる。これによって、WFDソースはAPとの接続が解除された状態で、WFDシンクとダイレクトリンクを生成することができる。
WFDソースとWFDシンクとの間にダイレクトリンクが生成されると、WFDソース及びWFDシンクはダイレクトリンクを介してWFDセッションを開始し、コンテンツをストリーミングすることができる。
WFDソースがAPと接続されており、WFDソースとWFDシンクとの間に既にダイレクトリンクも存在する場合には、WFDソースとWFDシンクとの間のダイレクトリンクをミラキャストに再使用することができる。一例として、図15は、WFDソースがAPと接続されており、WFDソースとWFDシンクとの間に既にダイレクトリンクが存在する場合に、WFDセッションが構築されるトポロジを図式化した図である。
図15に示す例のように、WFDデバイス間に既にIP接続が構築されている状態では、WFDデバイス間のWFDデバイス探索/サービス探索は、IPパケットによって行われてもよく、図11で説明したとおり、プローブ要求及び応答フレーム、サービス要求及び応答フレームによって行われてもよい。
なお、WFDセッションは、IPパケット又はLayer2フレーム(例えば、MACフレーム)を用いて既存のダイレクトリンク上で接続が開始されてもよい。
次に、WFDソース及びWFDシンクが同一のAPと接続されている場合に、WFDセッションが構築されるトポロジについて詳しく説明する。
図16乃至図19は、WFDソース及びWFDシンクが同一のAPと接続されている場合に、WFDセッションが構築されるトポロジを図式化した図である。
WFDソースとWFDシンクが同一のAPに接続された状態では、WFDデバイスはAPを経由するIPパケットを用いてWFDデバイス探索/サービス探索を行ってもよく、図11の例示のように、プローブ要求及び応答フレーム、サービス要求及び応答フレームを用いてWFDデバイス探索/サービス探索を行ってもよい。
一例として、図16及び図17では、WFDソース及びWFDシンクがAPを経由しないプローブ要求及び応答フレーム、サービス要求及び応答フレームを用いてWFDデバイス探索/サービス探索を行うことを示しており、図18及び図19では、WFDソース及びWFDシンクがAPを経由するデバイス/サービス探索要求パケットとデバイス/サービス探索応答パケットを用いてWFDデバイス探索/サービス探索を行うことを示している。
WFDデバイス探索/サービス探索の後、WFDソース及びWFDシンクは、図16及び図19の例示のように、WFDセッションの接続のためにダイレクトリンクを生成することができる。WFDソースとWFDシンクとの間にダイレクトリンクが生成されると、WFDソース及びWFDシンクは、図16及び図19の例示のように、ダイレクトリンクを介してWFDセッションを開始し、コンテンツをストリーミングすることができる。
これと違い、WFDソース及びWFDシンクは、図17及び図18の例示のように、両者間にダイレクトリンクを生成せず、既存APとの接続(すなわち、インフラストラクチャーリンク)を再使用してWFDセッションを開始することもできる。ただし、この場合、WFDソース及びWFDシンクは互いに同一のAPに接続されていることを事前に認識する必要がある。WFDソースとWFDシンクとの間の離隔距離が長いため、Wi−Fiダイレクト通信を行うには不適であるが、WFDソース及びWFDシンクが同一のAPと接続されているなら、既存APとの接続を再使用する方が、WFDセッションの構築には効果的であろう。
次に、WFDソース及びWFDシンクのうちWFDシンクのみがAPに接続されている場合に、WFDセッションが構築される過程について説明する。
図20及び図21は、WFDシンクがAPに接続されている場合に、WFDセッションが構築されるトポロジを図式化した図である。まず、WFDソースはプローブ要求フレーム及び応答フレームの送受信によってWFDシンクを探索することができる。
その後、WFDソース及びWFDシンクは、図20の例示のように、WFDセッションを生成するためのダイレクトリンクを生成し、生成されたダイレクトリンクを介してWFDセッションを開始することができる。WFDソースは、WFDセッションを介してWFDシンクにコンテンツをストリーミングすることができる。
仮に、WFDソースがWFDシンクの接続しているAPを知っていると、WFDソースは、WFDシンクとダイレクトリンクを生成する代わりに、図21の例示のように、WFDシンクが接続しているAPに接続した後、APとの接続を用いてWFDセッションを構築することもできる。WFDソースはWFDセッションを介してWFDシンクにコンテンツをストリーミングすることができる。
図22及び図23は、WFDソース及びWFDシンクが異なったAPに接続されているときに、WFDセッションが構築されるトポロジを図式化した図である。WFDソースとWFDシンクが異なったAPに接続している場合、WFDシンクは、プローブ要求フレーム及び応答フレームの送受信を用いてWFDシンクを探索することができる。
その後、WFDソース及びWFDシンクは、図22の例示のように、WFDセッションを生成するためのダイレクトリンクを生成し、生成されたダイレクトリンクを介してWFDセッションを開始することができる。WFDソースはWFDセッションを介してWFDシンクにコンテンツをストリーミングすることができる。
これと違い、WFDソースは、図23の例示のように、WFDシンクが接続しているAPに接続した後、WFDソースとWFDシンクとが共通に接続しているAPとの接続を用いてWFDセッションを構築することもできる。一例として、WFDソースがAP1に接続している状態で、WFDシンクがAP2に接続していると、WFDソースは、AP1との接続を切ってAP2に接続した後、WFDソース及びWFDシンクとが共通に接続しているAP2との接続を用いてWFDセッションを構築することができる。これによって、WFDソースは、AP2を経由するようにして生成されたWFDセッションを用いて、WFDシンクにコンテンツをストリーミングすることができる。
図12乃至図23に示す種々のトポロジの例において、基本的に、WFDソース及びWFDシンクはダイレクトリンクを構築した後、ダイレクトリンクを用いてコンテンツストリーミングのためのWFDセッションを開始することができる。これと違い、WFDソースとWFDシンクが同一のAPに接続している状態であるか、WFDソースがWFDシンクの接続しているAPに接続可能な場合には、ダイレクトリンクを構築せず、APとの接続を用いてコンテンツストリーミングのためのWFDセッションを開始することもできる。図示してはいないが、WFDシンクがWFDソースの接続しているAPに接続可能であると、この場合にもダイレクトリンクを構築せず、APとの接続を用いてコンテンツストリーミングのためのWFDセッションを開始することができる。
ただし、共通に接続しているAPを介してWFDセッションを開始するとき、WFDソースは、WFDシンクが接続中であるAPに関する情報を取得する必要がある。WFDソースがAPに接続中であれば、WFDシンクを探索するためのデバイス/サービス探索要求パケットのブロードキャスティング範囲を自身の属したサブネット(subnet)に限定することによって、同一のAPに接続しているWFDシンクを探索できるが、WFDシンクがWFDソースと異なるAPに接続している場合、又はWFDソースがAPに接続していない状態なら、デバイス/サービス探索要求パケットのブロードキャスティングを用いてはWFDシンク或いはWFDシンクの接続しているAP情報が取得し難い。
そこで、本発明では、WFDソースがWFDデバイスの探索過程及びサービス探索過程でWFDソースの接続しているAP情報をWFDシンクに知らせたり、WFDソースがWFDシンクの接続しているAP情報を取得したりする方法について提案する。
WFDソース及びWFDシンクは、プローブ要求フレーム及びプローブ応答フレームを用いてお互いを探索することができる。具体的には、プローブ要求フレーム及びプローブ応答フレームは、P2P情報要素及びWFD情報要素の少なくとも一つを含むことができる。
表1には、WFD情報要素のフォーマットを示す。

要素IDフィールドは、プローブ要求フレーム及びプローブ応答フレーム内のWFD情報要素を識別する役割を担う。長さフィールドは、WFD情報要素の長さ又は長さフィールドに続く残りのフィールドの長さを示すことができる。
OUI(Organizationally Unique identifier)フィールドは、WFA(Wi−Fi Alliance)で定めた値を有することができる。OUIタイプフィールドは、WFD情報要素のバージョンを示す。一例として、OUIタイプフィールドの値が0x0Aであれば、これはWFD v1.0を示すことができる。
WFD情報要素には、WFD副要素が含まれてもよい。表2に、WFD情報要素に含まれるWFD副要素のフォーマットを説明する。

表2の副要素IDフィールドは、WFD副要素のタイプを識別し、長さフィールドは、WFD副要素の長さ又は長さフィールドに続く残りのフィールドの長さを示すことができる。
副要素ボディーフィールドには、副要素に応じた適切な値を挿入することができる。
WFD副要素として使用可能な情報は、表3のとおりである。

表3に列挙されたとおり、WFD情報要素は、WFDデバイス情報、WFDデバイスと関連付けられたBSSID、WFDオーディオフォーマット、WFDビデオフォーマット、WFD3Dビデオフォーマット、WFDコンテンツ保護、接続されたシンク情報、拡張されたWFDセッション能力、WFDセッション情報、代替MACアドレスなどを含むことができる。
ここで、WFDデバイス情報は、WFDデバイス情報及びセッション管理制御ポートに関する情報を含むことができ、関連付けられたBSSID情報は、WFDデバイスが関連付けられたBSSIDの情報を含むことができる。
WFDオーディオフォーマット、WFDビデオフォーマット及びWFD3Dビデオフォーマットは、WFDデバイスがサポートするビデオ/オーディオフォーマット及び3Dビデオフォーマットの情報を含むことができる。また、WFDコンテンツ保護フィールドは、コンテンツ保護方法に関する情報を含むことができ、接続されたシンク情報は、WFDシンクがWFDソースを探索する場合、WFDシンクが接続されたシンクモードをサポートする場合に含まれてもよい。拡張されたWFD能力は、WFDデバイスがTDLS持続能力(TDLS persistence capability)をサポートする場合に含まれてもよい。
次に、表4は、P2P情報要素のフォーマットを説明するためのものである。

表4に列挙されたとおり、P2P情報要素は、デバイスのP2P能力、P2Pデバイス情報、P2PグループID、意図したP2Pインターフェースアドレス、デバイス状態、動作チャネル、チャネルリスト、セッション情報データ情報、接続能力情報、広告ID情報、タイムアウト設定情報、聴取チャネル、セッションID情報、特定能力、永続的なグループ情報などの、WFDソースとWFDシンクとの間に既に構築されたダイレクトリンクを用いるための情報を含むことができる。
プローブ要求フレーム及びプローブ応答フレームがP2P情報要素及びWFD情報要素の両方を含む場合、WFDソース及びWFDシンクは、P2P情報要素を用いてP2P接続を構築することができ、WFD情報要素を用いてWFDセッション(又はミラキャストセッション)接続を構築することができる。
プローブ要求フレーム及びプローブ応答フレームには、WSC(Wi−Fi Simple Configuration)情報要素がさらに含まれてもよい。WSC情報要素としては、WSC又はWPS(Wi−Fi Protected Setup)のための情報を含むことができるが、具体的には、WSC情報要素としては、UUID−E、メーカー、モデル名、モデル番号、シリアル番号、主デバイスタイプ(Primary Device Type)、デバイス名、設定方法などの情報を含むことができる。
図24は、プローブ要求フレーム及びプローブ応答フレームのフォーマットを簡略に示す図である。
ここで、WFDソース又はWFDシンクがAPと関連付けられた状態であれば、APと関連付けられたWFDデバイスは、プローブ要求フレーム又はプローブ応答フレームを用いて、自身が関連付けられたAPの情報を他のWFDデバイスに知らせることができる。
具体的には、WFDデバイスは、プローブ要求フレーム及びプローブ応答フレームのP2P情報要素及びWFD情報要素の少なくとも一つに、自身が関連付けられたAPに関する情報を含めることによって、関連付けられたAPに関する情報を他のWFDデバイスに伝達することができる。ここで、APに関する情報は、インフラストラクチャーBSS属性情報と呼ぶことができるが、この名称に限定されるものではない。
インフラストラクチャーBSS属性情報は、P2P情報要素に含まれてもよく、WFD情報要素に含まれてもよく、P2P情報要素及びWFD情報要素の両方に含まれてもよい。
インフラストラクチャーBSS属性情報を受信したWFDデバイスは、インフラストラクチャーBSS属性情報をデコーティングし、相手WFDデバイスが関連付けられたAPの情報及び相手WFDデバイスにAPから割り当てられたIPアドレスなどを認識することができる。
一例として、表5は、インフラストラクチャーBSS属性情報のフォーマットを説明するためのものである。

表5に列挙された項目のうち、属性IDフィールドは、P2P情報要素又はWFD情報要素内のインフラストラクチャーBSS属性情報を識別する役割を担う。なお、長さフィールドは、インフラストラクチャーBSS属性情報の長さ又は長さフィールドに続く残りのフィールドの長さを示すことができる。
MACアドレスフィールドは、APのBSSIDを示すことができる。
国文字列フィールドは、動作クラス及びチャネルナンバーフィールドが有効な国コードを明示する。
動作クラスフィールドは、APが動作する周波数帯域(frequency band)を示し、チャネル番号フィールドは、APが動作するチャネル番号を示す。動作クラスフィールド及びチャネル番号フィールドを用いて、WFDデバイスは、自身と関連付けられたAPの周波数帯域及びチャネル番号に関する情報を相手WFDデバイスに知らせることができる。
SSID長フィールドは、APのSSIDの長さを示し、SSIDフィールドは、APのSSIDを示す。WFDデバイスは、SSID長フィールド及びSSIDフィールドを用いて相手WFDデバイスに自身が関連しているAPのSSIDを知らせることができる。
IPバージョンフィールドは、IPバージョンを示す。一例として、IPバージョンフィールドの値が0x04であると、IP v4が用いられることを示し、0x06であると、IP v6が用いられることを示すことができる。
IPアドレスフィールドは、APに接続されたWi−FiインターフェースのIPアドレスを示す。WFDデバイスは、IPアドレスフィールドを用いて相手WFDデバイスに自身のIPアドレスを知らせることができる。
WFDソースがインフラストラクチャーBSS属性情報を含むプローブ要求フレームをブロードキャストすると、WFDシンクは、インフラストラクチャーBSS属性情報から、WFDソースと同じAPに関連付けられているか確認したり、WFDソースが関連付けられたAPへの接続を試みたりすることができる。
逆に、WFDシンクがインフラストラクチャーBSS属性情報を含むプローブ応答フレームをWFDソースに送信すると、WFDソースは、インフラストラクチャーBSS属性情報から、WFDシンクが関連付けられたAPと同じAPに関連付けられているか確認したり、WFDシンクが関連付けられたAPへの接続を試みたりすることができる。
WFDデバイスは、サービス探索要求フレーム及びサービス探索応答フレームを用いて、自身が関連しているAPに関する情報を知らせることもできる。この場合、インフラストラクチャーBSS属性情報は、属性フレームフォーマット又はUTF−8文字列の形態でサービス探索要求フレーム及びサービス探索応答フレームに含まれてもよい。
インフラストラクチャーBSS属性情報は、サービス探索手順において、サービス探索要求フレーム及びサービス探索応答フレームに含まれてもよい。この場合、インフラストラクチャーBSS属性情報は、属性フレームフォーマット又はUTF−8文字列の形態でサービス探索要求フレーム及びサービス探索応答フレームに含まれてもよい。
WFDソースが、インフラストラクチャーBSS属性情報を含むサービス探索要求フレームをWFDシンクに送信すると、WFDシンクは、インフラストラクチャーBSS属性情報から、WFDソースと同じAPに関連付けられているか確認したり、WFDソースが関連付けられたAPへの接続を試みたりすることができる。
逆に、WFDシンクが、インフラストラクチャーBSS属性情報を含むサービス探索応答フレームをWFDソースに送信すると、WFDソースは、インフラストラクチャーBSS属性情報から、WFDシンクが関連付けられたAPと同じAPに関連付けられているか確認したり、WFDシンクが関連付けられたAPへの接続を試みたりすることができる。
一例として、図25は、WFDシンクがAPに関連付けられたとき、WFDシンクが関連付けられたAPに関する情報をWFDソースに知らせる例を示す図である。図25の例示のように、WFDシンクは、プローブ要求フレームに対する応答として、AP情報(具体的には、インフラストラクチャーBSS属性情報)を含むプローブ応答フレームをWFDソースに送信することもでき、サービス探索要求フレームに対する応答として、AP情報(具体的には、インフラストラクチャーBSS属性情報)を含むサービス探索応答フレームをWFDソースに送信することもできる。
図25の例示のように、インフラストラクチャーBSS属性情報は、プローブ応答フレーム及びサービス探索応答フレームの両方に含まれてもよいが、プローブ応答フレーム及びサービス探索応答フレームのいずれか一方にのみ含まれてもよい。ただし、サービス探索手順が行われるか否かは、WFDデバイス能力に応じて選択的に決定されるため、サービス探索応答フレームよりはプローブ応答フレームにインフラストラクチャーBSS属性情報を含めることが好ましいだろう。
WFDソースは、プローブ応答フレーム(又は、サービス探索応答フレーム)に含まれたAP情報に基づいて、WFDシンクが接続しているAPに接続することができる。これと同様に、WFDシンクは、プローブ要求フレーム(又は、サービス探索要求フレーム)に含まれたAP情報に基づいて、WFDソースが接続しているAPに接続することができる。WFDソース及びWFDシンクが同一のAPに接続すると、図16乃至図19で説明したとおり、APとの接続を用いてWFDセッションを構築することができる。
プローブ要求フレーム及びプローブ応答フレーム(又は、サービス探索要求フレーム及びサービス探索応答フレーム)の交換の結果、WFDソース及びWFDシンクが同一のAPに接続していると確認される場合にも、図16乃至図19で説明したとおり、APとの接続を用いてWFDセッションを構築することができる。
なお、図12乃至図25では、Wi−Fiダイレクトサービスのうち、ディスプレイサービス或いはWi−Fiディスプレイ(Miracast)のみを対象にして説明したが、デバイス探索手順又はサービス探索手順においてP2PデバイスがAP情報を送信又は受信する特徴は、ディスプレイサービス以外のサービス(例えば、プレイ、プリント、送信及びイネーブルサービスなど)にも適用可能であることはいうまでもない。
タスク単位の画像/音声ストリーミング
WFDセッションが構築されると、WFDソースは、自身の出力している音声及び画像データ(以下、AV(Audio/Video)データという。)を実時間でエンコーディングした後、WFDセッションを介してWFDシンクに、エンコードされたデータをストリーミングすることができる。すなわち、WFDソースは、自身の出力している音声と画像全体をエンコーディングし、WFDシンクは、受信したストリームをデコーティングして全体画面として出力することによって、ディスプレイサービスを行うことができる。しかし、このように、WFDソースが自身の出力している画像全体をエンコーディングしたり、WFDシンクが、受信したストリームを全体画面として出力したりすると、ディスプレイサービス中にWFDソース及びWFDシンクで他のタスク(task)が処理し難いという問題点がある。
そこで、本発明では、WFDソースが、ディスプレイされている映像全体ではなくタスク(task)単位でAVデータをエンコーディングしてストリーミングする方法を提案する。
一例として、図26は、WFDソースがマルチタスクを実行しているとき、タスク別のエンコーディングデータが異なったWFDシンクにストリーミングされる例を示す図である。図26の例示のように、WFDソースがマルチタスクを実行している間に、第1のWFDシンク及び第2のWFDシンクとWFDセッションを構築した場合には、WFDソースは、実行中の複数のタスクのいずれか一つのAVデータに対応するエンコーディングデータを第1のWFDシンクにストリーミングし、他のAVデータに対応するエンコーディングデータを第2のWFDシンクにストリーミングすることができる。一例として、図26の例示のように、第1のWFDシンクがTVであり、第2のWFDシンクがラップトップであれば、WFDソースはTVに、第1のタスクのAVデータをエンコーディングした第1のデータをストリーミングし、ラップトップに、第2のタスクのAVデータをエンコーディングした第2のデータをストリーミングすることができる。
第1のデータ及び第2のデータはWFDソースによってディスプレイされている画像や出力される音声ではなくタスク別のRAW画像及び音声をエンコーディング対象にして生成されたものであるため、WFDソースが第1のタスク及び第2のタスクをディスプレイするとき、図26に示す例のように、第2のタスクの一部が第1のタスクによって隠されていても、第2の画像は第2のタスクを正常に表現することができる。これと同様に、WFDソース上で第1のタスクが活性化状態にあり、第2のタスクが非活性化状態にあり、第2のタスクが半透明表示されている状態であっても、第2の画像は第2のタスクを正常に表現することができる。
なお、WFDソースが第1のタスクの音声及び第2のタスクの音声を同時に出力する場合であっても、第1のWFDシンクは第1のタスクの音声のみをストリーミングし、第2のWFDシンクは第2のタスクの音声のみをストリーミングすることができる。
第1のデータを第1のWFDシンクにストリーミングし、第2のデータを第2のWFDシンクにストリーミングするために、WFDソースは、第1のWFDシンク及び第2のWFDシンクと個別にWFDセッションを構築しなければならない。ただし、WFDセッション別にタスクの特性(例えば、動画解像度、オーディオ又はビデオコーデックなど)は独立していてもよい。
複数のタスクのうちのいずれをWFDシンクデバイスにストリーミングするかは、ユーザ入力によって選択されてもよく、既に設定された値によって自動で選択されてもよい。
他の例として、図27は、WFDソースがマルチタスクを実行しているとき、タスク別にエンコードされた複数のデータが単一のWFDシンクにストリーミングされる例を示す図である。WFDソースが複数のタスクを実行している間にWFDシンクとWFDセッションが構築されると、WFDソースは、実行中の複数のタスクの一部に対してエンコーディングを行った後、エンコードされたデータを別個のストリームとしてWFDシンクに送信することができる。一例として、図27に示すように、第1のタスク及び第2のタスクに対して2個のエンコーディングデータが生成された場合には、WFDソースは2個のエンコーディングデータを別々のストリームとしてWFDシンクに送信することができる。
2個のエンコーディングデータを受信したWFDシンクは、ユーザの好み又は既に設定された値によって適切に2個のデータを配置してディスプレイすることができる。一例として、WFDソースでは第1のタスクを背景にして第2のタスクがディスプレイされている状態であるとしでも、WFDシンクは、第1のタスクを対象にした第1の画像及び第2のタスクを対象にした第2の画像を別個のストリームとして受信するので、WFDソースとは異なるように第1のタスク及び第2のタスクを配置することもできる。図27では、WFDソースは第1のタスクを背景にして第2のタスクをディスプレイしているが、WFDシンクは第2のタスクを背景にして第1のタスクをディスプレイしている。
WFDソースは、バックグラウンド状態として実行されているタスクをWFDシンクにストリーミングすることもできる。一例として、図28は、WFDソースがフォアグラウンド状態であるタスクとバックグラウンド状態であるタスクを別々のWFDシンクにストリーミングする例を示している。説明の便宜のために、WFDソースは、図28の例示のように、文書作成プログラムをフォアグラウンド状態として実行し、動画再生プログラムをバックグラウンド状態として実行していると仮定する。この場合、WFDソースは、フォアグラウンド状態として実行中の文書作成プログラムを対象にしてエンコードされた第1のデータ、及びバックグラウンド状態として実行中の動画再生プログラムを対象にしてエンコードされた第2のデータを、それぞれ、第1のWFDシンク及び第2のWFDシンクにストリーミングすることができる。
これによって、現在WFDソースが第2のタスクに対する画像(及び音声)を出力していなくても、WFDシンクは第2のタスクに対する画像(及び音声)を出力可能になる。
WFDソースは、ウィンドウ単位でAVデータをエンコーディングし、WFDシンクにストリーミングすることもできる。
一例として、図29は、WFDソースが複数のウィンドウをディスプレイしているときに、ウィンドウ別エンコーディングデータが異なったWFDシンクにストリーミングされる例を示す図である。図29の例示のように、WFDソースが複数のウィンドウをディスプレイしている間に、第1のWFDシンク及び第2のWFDシンクとWFDセッションを構築した場合には、WFDソースは、ディスプレイされている複数のウィンドウのうちいずれか一つのAVデータに対するエンコーディングデータを第1のWFDシンクにストリーミングし、いずれか他のAVデータに対するエンコーディングデータを第2のWFDシンクにストリーミングすることができる。
一例として、図29の例示のように、第1のWFDシンクがTVであり、第2のWFDシンクがプロジェクターであれば、WFDソースはTVに、第1のウィンドウのAVデータをエンコーディングした第1のデータをストリーミングし、プロジェクターに、第2のウィンドウのAVデータをエンコーディングした第2のデータをストリーミングすることができる。
WFDソースが実行しているタスクが音声再生と関連したものであれば、WFDソースは音声機器タイプのWFDシンクに、当該タスクに対するエンコーディングデータをストリーミングし、実行しているタスクが画像の表示が必要なものであれば、WFDソースは画像機器タイプのWFDシンクに、当該タスクに対するエンコーディングデータをストリーミングすることができる。
一例として、図30は、タスクの属性によってデータがストリーミングされる例を示す図である。説明の便宜のために、WFDソースは、動画再生プログラム及び音声再生プログラムを実行中であり、WFDソースは、TV及びオーディオとWFDセッションを生成した状態であると仮定する。
この場合、WFDソースは、動画再生プログラムのAVデータをエンコーディングしたデータはTVにストリーミングし、音声再生プログラムの音声データをエンコーディングしたデータはオーディオにストリーミングすることができる。
WFDソースに写真が保存されていると、WFDソースは、保存された写真をスライドショーとして構成した画像をエンコーディングしたデータがWFDシンクに送信されるように制御することができる。なお、WFDシンクは、スライドショーの再生時に再生するように設定されたバックグラウンドミュージックもWFDシンクにストリーミングすることができる。
一例として、図31は、WFDソースに保存された写真のスライドショーをエンコーディングしたデータがWFDシンクにストリーミングされる例を説明するための図である。WFDソースに写真が保存されていると、WFDソースは、保存されている写真がスライドショーとしてディスプレイされていなくても、保存されている写真をスライドショーとして構成した時に予想される画像をエンコーディングすることができる。なお、スライドショーの再生時に再生されるように設定されたバックグラウンドミュージックが存在すると、WFDソースは、バックグラウンドミュージックをエンコーディングしたデータを生成することができる。
WFDソースは、エンコーディングしたデータをWFDシンクにストリーミングすることができる。この時、エンコードされた画像及び音声は、同じWFDシンク(例えば、TV)に送信されてもよく、エンコードされた画像は第1のWFDシンク(例えば、TV)に、エンコードされた音声は第2のWFDシンク(例えば、オーディオ)に送信されてもよい。
WFDソースがマルチディスプレイ環境で動作する場合には、WFDソースは、ディスプレイ別エンコーディングデータを異なったWFDシンクにストリーミングすることもできる。
一例として、図32は、WFDソースがマルチディスプレイ環境で動作しているとき、ディスプレイ別エンコーディングデータが別々のWFDシンクにストリーミングされる例を示す図である。図32の例示のように、WFDソースは、ラップトップであり、自身のディスプレイ及びモニタを用いたマルチディスプレイ環境を構築した状態であると仮定する。
この場合、WFDソースは、自身のディスプレイ部から出力される画像をエンコーディングした第1のデータは第1のWFDシンクに送信し、追加のモニタから出力される画像をエンコーディングした第2のデータは第2のWFDシンクに送信することができる。
第1のWFDシンクがTVであり、第2のWFDシンクがプロジェクターであれば、第1のデータを受信したTVは、ラップトップのディスプレイ部と同じ画面を出力することができ、第2のデータを受信したプロジェクターは、ラップトップに接続されたモニタと同じ画面を出力することができる。
WFDソースからデータを受信したWFDシンクは、受信したデータをデコーティングして出力することができる。この時、WFDシンクは、WFDソースから受信したデータを画面全体に出力する代わりに、自身が実行している既存タスクと共に、受信したデータを出力することもできる。
一例として、図33は、WFDシンクが、自身が実行しているタスクと共に、受信したデータを出力する例を示す図である。WFDシンクは、WFDシンクから受信したデータ(すなわち、WFDストリーム)を、自身が実行していた既存タスク(例えば、アプリケーション又は放送など)と共に出力することができる。このとき、WFDシンクは、受信したデータが自身の実行していた既存タスクを隠すことを防止するために、受信したデータを半透明にディスプレイすることもできる。なお、WFDシンクは、受信したデータの透明度を調節するための透明度調節バーなどがディスプレイされるように制御してもよい。
さらに、WFDシンクは、受信したデータを全体画面にディスプレイするか否かを調節するためのボタン、受信したデータを最小化するか否かを調節するためのボタン、受信したデータを終了するか否かを決定するためのボタンなどをディスプレイしてもよい。受信したデータがディスプレイされる位置及び大きさは、ユーザ入力によって変化してもよいことはいうまでもない。
WFDシンク自身が行っていたタスクが音声出力であれば、WFDシンクは、図33の例示のように、WFDソースからビデオだけを受信して出力することもできる。これと違い、WFDシンクは、自身が行っていたタスクの音声出力を中止し、WFDソースからビデオ及びオーディオを受信して出力することもできる。
1つのWFDシンクが複数のディスプレイ装置と物理的又は論理的に接続されていてもよい。例えば、図32に例示したとおり、マルチディスプレイ環境で動作しているコンピュータがWFDシンクとして動作する場合は、WFDシンクが物理的に複数のディスプレイ装置に接続されている場合と仮定することができ、車両のシートに取り付けられたヘッドユニット及びセンターフェイシアディスプレイを制御するための制御装置がWFDシンクとして動作すると、WFDシンクが複数のディスプレイ装置(すなわち、ヘッドユニット及びセンターフェイシアディスプレイ)と物理的に接続されている場合と仮定することができる。
このように、WFDシンクが複数のディスプレイ装置と接続されている状態では、WFDソースは、WFDシンクが接続されている複数のディスプレイ装置別に異なるデータがストリーミングされるように制御してもよい。一例として、図34及び図35は、WFDソースが、WFDシンクのディスプレイ別に異なるデータがストリーミングされるように制御する例を示す図である。図34の例示では、WFDシンクの第1のディスプレイ部にはWFDソースの第1のタスクがストリーミングされており、第2のディスプレイ部にはWFDソースの第2のタスクがストリーミングされており、第3ディスプレイ部にはWFDソースの第3タスクがストリーミングされている。
そのために、WFDソース及びWFDシンクは複数個のWFDセッションを生成しなければならず、WFDソース及びWFDシンクの少なくとも一つがデータ別にストリーミングするディスプレイを指定しなければならない。なお、WFDソースは、WFD機器探索/サービス探索手順又はWFD能力交渉手順において、WFDシンクと接続されているディスプレイ装置の個数を取得することができる。
WFDシンクが複数のWFDソースとWFDセッションを構築した場合には、ディスプレイ別に異なるWFDソースのAVデータが出力されるように制御することができる。一例として、図35では、WFDシンクの第1のディスプレイ部には第1のWFDソースのAVデータがストリーミングされており、第2のディスプレイ部には第2のWFDソースのAVデータがストリーミングされており、第3のディスプレイ部には第3のWFDソースのAVデータがストリーミングされている。
図36は、本発明の一実施例に係る無線デバイスの構成を示すブロック図である。
無線デバイス10は、プロセッサ11、メモリ12、送受信器13を備えることができる。送受信器13は、無線信号を送信/受信することができ、例えば、IEEE 802システムに基づく物理層を実現することができる。プロセッサ11は、送受信器13と電気的に接続されて、IEEE 802システムに基づく物理層及び/又はMAC層を実現することができる。また、プロセッサ11は、WFDサービスのためのオーディオ/ビデオのエンコーディング及びデコーディングの動作を行うように構成されてもよい。また、前述した本発明の様々な実施例に係る無線デバイスの動作を実現するモジュールがメモリ12に格納され、プロセッサ11によって実行されてもよい。メモリ12は、プロセッサ11の内部に含まれたり、又はプロセッサ11の外部に設けられて、プロセッサ11と公知の手段によって接続されたりしてもよい。図示してはいないが、無線デバイス10は、画像及び音声を出力するためのディスプレイ部及び音声出力部をさらに備えることができる。
図36の無線デバイス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)、プロセッサ、コントローラ、マイクロコントローラ、マイクロプロセッサなどによって実現することができる。
ファームウェアやソフトウェアによる実現の場合、本発明の実施例に係る方法は、以上で説明された機能又は動作を実行するモジュール、手順又は関数などの形態として実現することができる。ソフトウェアコードはメモリユニットに格納され、プロセッサによって駆動されてもよい。メモリユニットは、プロセッサの内部又は外部に設けられ、既に公知である様々な手段によってプロセッサとデータを交換することができる。
以上開示された本発明の好適な実施の形態に関する詳細な説明は、当業者が本発明を実現して実施できるように提供された。以上では本発明の好適な実施の形態を参照して説明したが、当該技術分野における熟練した当業者にとって、添付した特許請求の範囲に記載された本発明の思想及び領域から逸脱しない範囲内で本発明を様々に修正及び変更可能であることは明らかである。したがって、本発明は、ここに開示された実施の形態に制限しようとするものではなく、ここに開示された原理及び新規な特徴と一致する最も広い範囲を与えようとするものである。
上述した本発明の様々な実施の形態については、IEEE 802.11システムを中心に説明したが、様々な移動通信システムに同様に適用可能である。



  1. Wi−Fiダイレクトサービスをサポートする第1の無線デバイスでデバイス探索を行う方法であって、
    プローブ要求フレームを送信するステップと、
    前記プローブ要求フレームに対する応答として、第2の無線デバイスからプローブ応答フレームを受信するステップと、
    を有し、
    前記プローブ応答フレームは、前記第2の無線デバイスが現在接続しているAP(Access Point)の情報を含む、方法。

  2. 前記APの情報は、前記第2の無線デバイスと関連付けられたAPが動作する周波数帯域に関する情報、前記第2の無線デバイスと関連付けられたAPが動作するチャネル情報、及び前記第2の無線デバイスのIPアドレス情報を含む、請求項1に記載の方法。

  3. 前記APの情報に基づいて前記第1の無線デバイスが前記APに接続するステップを有する、請求項1に記載の方法。

  4. 前記第1の無線デバイスが接続された前記APを介して前記第2の無線デバイスとのセッションを開始するステップを有する、請求項3に記載の方法。

  5. 前記プローブ要求フレームは、前記第1の無線デバイスが現在接続しているAPの情報を含む、請求項1に記載の方法。

  6. 前記第1の無線デバイス及び前記第2の無線デバイスが同一のAPに接続している場合、前記第1の無線デバイスが前記APを介して前記第2の無線デバイスとのセッションを開始するステップを含む、請求項5に記載の方法。

  7. 前記プローブ応答フレームは、WFD(Wi−Fi Display)情報要素及びP2P(Peer to Peer)情報要素を含み、
    前記APの情報は、前記WFD情報要素及び前記P2P情報要素のうち少なくとも一つの副要素として前記プローブ応答フレームに含まれる、請求項1に記載の方法。

  8. 前記第1の無線デバイス及び前記第2の無線デバイスがサービス探索手順を行う能力を有する場合、
    前記第2の無線デバイスにサービス探索要求フレームを送信するステップと、
    前記サービス探索要求フレームに対する応答として、前記第2の無線デバイスからプローブ応答フレームを受信するステップと、を有する、請求項1に記載の方法。

  9. 前記サービス探索要求フレームは、前記第1の無線デバイスが現在接続しているAPの情報を含み、
    前記サービス探索応答フレームは、前記第2の無線デバイスが現在接続しているAPの情報を含む、請求項8に記載の方法。

  10. Wi−Fiダイレクトサービスをサポートする第1の無線デバイスがデバイス探索に応答する方法であって、
    第2の無線デバイスからプローブ要求フレームを受信するステップと、
    前記プローブ要求フレームに対する応答として、前記第2の無線デバイスにプローブ応答フレームを送信するステップと、
    を有し、
    前記プローブ応答フレームは、前記第1の無線デバイスが現在接続しているAP(AccessPoint)の情報を含む、方法。

  11. デバイス探索を行い、かつWi−Fiダイレクトサービスをサポートする第1の無線デバイスであって、
    送受信器と、
    プロセッサと、
    を備え、
    前記プロセッサは、プローブ要求フレームを送信するように前記送受信器を制御し、
    前記送受信器が第2の無線デバイスから前記プローブ要求フレームに対する応答としてプローブ応答フレームを受信すると、
    前記プローブ応答フレームから、前記第2の無線デバイスが現在接続しているAP(AccessPoint)の情報をデコーティングする、第1の無線デバイス。

  12. デバイス探索に応答し、かつWi−Fiダイレクトサービスをサポートする第1の無線デバイスであって、
    送受信器と、
    プロセッサと、
    を備え、
    前記プロセッサは、前記送受信器が第2の無線デバイスからプローブ要求フレームを受信すると、
    前記第1の無線デバイスが現在接続しているAP(Access Point)の情報を含むプローブ応答フレームが前記第2の無線デバイスに送信されるように制御する、第1の無線デバイス。

 

 

Patent trol of patentswamp
類似の特許
無線通信システムにおいて第1装置の装置対装置間信号送受信方法であって、第2装置からディスカバリ信号を受信するステップと、前記ディスカバリ信号送信に関連したアンテナポートの個数を判断するステップと、前記アンテナポートの個数に基づいて前記ディスカバリ信号を復号するステップとを有し、前記DMRSを構成するシーケンスの初期値は、セルIDに関連したパラメータによって決定され、前記セルIDに関連したパラメータの値は、物理セルID及び仮想セルIDのそれぞれが可能な値とは異なる値の範囲から選択される、信号送受信方法を提供する。
【選択図】図6
無線ネットワークにおけるマシンタイプ通信のためのeNodeBおよび方法の実施形態が本明細書において概して記載される。いくつかの実施形態において、進化型ノードB(eNodeB)の回路によって実行される方法は、ユーザ機器(UE)がマシンタイプ通信(MTC)に用いられるよう設定されるという通知をeNodeBが受信する段階を含み得る。当該方法は、UEが無線リソース制御接続(RRC_Connected)状態にあるかどうかを決定する段階と、UEが省電力モードに入り得るかどうかを決定する段階とを含み得る。当該方法は、UEがRRC_Connected状態にあり、かつ、UEが省電力モードに入り得ると決定することに応答して、RRCディープアイドルモードに移行するようUEを設定する段階を含み得る。
デバイスツーデバイス(D2D)のためのスケジューリングを実装するためのシステム、方法および手段が提供される。WTRU(例えば、D2D WTRU)は、WTRUが送信するためのD2Dデータを有するかどうかを判定することができる。WTRUは、SAの送信のための、許可されたSAリソースのセットおよび/または許可されたD2Dデータリソースを判定することができる。WTRUは、(許可されたSAリソースのセットおよび/または許可されたD2Dデータリソースから)送信のためのSAリソースおよび/またはD2Dデータリソースを選択することができる。WTRUは、1または複数の送信パラメータを選択することができる。WTRUは、1または複数の送信パターンを選択することができる。WTRUは、選択された送信パターンを使用して、かつ選択された送信パラメータに従って、許可されたD2Dリソースのセットを通じてD2Dデータを送信することができる。
本発明の実施例は電力制御方法及びユーザ装置を提供する。該方法は、ユーザ装置が2つ又は2つ以上のコネクティビティのために電力制御パラメータをそれぞれ構成するステップと、該電力制御パラメータに基づいて対応するコネクティビティにおける信号の電力を制御し、該2つ又は2つ以上のコネクティビティについて電力をそれぞれ制御するステップと、を含む。本発明の実施例によれば、複数のリンクを有するシナリオの要求を満たすことができる。
【選択図】図1
無線通信システムにおいて第1端末がD2D(Device−to−Device)信号を送信する方法において、周波数ホッピング(frequency−hopping)によって物理リソースブロックを決定するステップと、前記決定された物理リソースブロックにデータをマッピングするステップとを有し、前記D2D信号を受信する第2端末が、前記第1端末の属した第1セル以外の第2セルに属した場合、前記周波数ホッピングには、前記第1セルと前記第2セルに共通するホッピングオフセット値が用いられる、信号送信方法を提供する。
【選択図】図7
本発明の実施例は、情報送信方法及び装置を提供し、ここで、第1のサブフレームにおいてユーザ装置の間で直接通信が実行されるとともに、ユーザ装置の間で実行された直接通信のチャネル状態情報が第2のサブフレームにおいて第3の装置に対して送信され、したがって、第3の装置は、ユーザ装置の間のチャネル状態情報を学習することができるとともに、直接通信を実行するユーザ装置に関してリソーススケジューリングを更に実行することができる。
クライアントデバイス(506)と制約リソースデバイス(502、70、90)との間で第1の秘密鍵を確立するための方法および制約リソースデバイスが開示される。本発明はまた、クライアントデバイス(506)と制約リソースデバイスとの間で第1の秘密鍵を確立することを可能にする方法および認可サーバ(504、60、80)に関する。制約RDとASとの間で共有される第2の秘密鍵に基づき、制約リソースデバイスとクライアントデバイスとの間で共有される(508)第1の秘密鍵を確立することができる。リソース制約のあるデバイスは、セキュア識別情報を共有するために追加メッセージが必要となるようなプロトコルを利用することができない。本発明の実施形態の利点は、認証プロトコル内で秘密識別情報を確立できること、および秘密識別情報を確立するために追加メッセージが必要ないことである。
【選択図】図5
セキュアシステム1は、通信を要求する要求デバイス(L01)と、前記要求デバイス(L01)からの通信要求を受信する受信デバイス(L03)とを備える。要求デバイス(L01)及び受信デバイス(L03)は、要求デバイス(L01)が受信デバイス(L03)を発見した場合の特定のグループのメンバーである。要求デバイス(L01)は、特定のグループにより使用されるネットワークにより、又は、特定のグループにより使用されるネットワークにより提供される証拠における受信デバイスにより、要求デバイス(L01)と通信することが許可され、デバイス(L01)及び(L03)は、直接無線インタフェースを介して相互認証を実行可能であり、又は、受信デバイス(L03)はproseサービス目的のためのデバイスの特定のグループのメンバーにおけるユーザにより維持されるリストを検査する。
【選択図】図3
本発明の実施形態は、情報を伝達するための方法、基地局、及びユーザ機器を提供する。方法は、ユーザ機器により、信号が送信されるよりも前に、信号のタイミングアドバンスTが決定されるステップと、ユーザ機器により、少なくともTに従ってタイミング調整量の指示Nが決定されるステップと、ユーザ機器により、Nを搬送するスケジュール割り当て信号が送信されるステップとを有する。異なるユーザ集団に対して同一でない時間−周波数資源の割り当てを使用することによって、ユーザ機器の送信したタイミングアドバンスを搬送するスケジュール割り当て信号は、より有用な情報を持つことができ、それによって、不必要な資源浪費が回避される。
第1の無線コンピューティングデバイスを備える装置は、第1のメモリと、少なくとも1つのプロセッサと、をさらに備える。少なくとも1つのプロセッサは、無線通信チャネルを介しての第2の無線コンピューティングデバイスへのWi−Fi Directサービス(WFDS)接続を確立するように構成し、前記WFDS接続を確立したことに応じて、第1の無線コンピューティングデバイスと第2の無線コンピューティングデバイスとの間でWFDSアプリケーションサービスプラットフォーム(ASP)セッションを確立するように構成し、ここにおいて、ASPセッションは、WFDS接続を介してのメディアアクセス制御(MAC)アドレスに基づくデータリンク層通信を使用し、及び、インターネットプロトコル(IP)通信を使用せず、及び、ASPセッションを確立したことに応じて、ASPセッションを用いて、第2の無線コンピューティングデバイスに通信するように構成することができる。
To top