JP2016527770A - コンテキスト管理 - Google Patents

Abstract

システム、方法、および装置の実施形態が、媒体アクセス制御層におけるコンテキスト情報管理のために、本明細書に説明される。一実施形態では、システムは、ピアツーピア通信を介して通信する複数のピアを備えている。本システムでは、コンテキスト情報は、ＭＡＣ層において交換され得る。コンテキスト情報の実施例は、限定ではないが、場所情報、移動情報、デバイス能力、ユーザ情報、アプリケーションカテゴリ、マルチホップ情報、チャネル状況、アプリケーション情報、関連付け識別子、およびデバイス情報を含む。複数のピアの各々は、各ピアデバイス上に常駐するコンテキストマネージャを含み得る。例えば、複数のピアの第１のピア上に常駐する第１のコンテキストマネージャは、コンテキスト情報を、複数のピアの第２のピア上に常駐する第２のコンテキストマネージャと交換し得る。

Description

（関連出願の引用）
本願は、米国仮特許出願第６１／８３７，８４５号（２０１４年６月２１日出願）、米国仮特許出願第６１／８４４，６８９号（２０１３年６月１０日出願）、および米国仮特許出願第６１／８３７，９９３号（２０１３年６月２１日出願）の利益を主張し、上記出願の全ての開示は、それらの全体が記載されているかのように参照により本明細書に引用される。

ピアツーピア（Ｐ２Ｐ）近接通信は、互に近接した範囲内のピア間のインフラストラクチャベースまたはインフラストラクチャレスの通信を指し得る。ピアは、例えば、２Ｇシステムにおける移動局（ＭＳ）、あるいはＩＥＥＥ ８０２．１５無線パーソナルエリアネットワーク（ＷＰＡＮ）におけるフル機能デバイス（ＦＦＤ）または低減機能デバイス（ＲＦＤ）等、ユーザまたはデバイスを指し得る。Ｐ２Ｐデバイスの実施例は、コネクテッドカー、医療デバイス、スマートメータ、スマートフォン、タブレット、ラップトップ、ゲーム機、セットトップボックス、カメラ、プリンタ、センサ、ホームゲートウェイ等を含む。Ｐ２Ｐ近接通信は、インフラストラクチャベースまたはインフラストラクチャレス構成において、所望のサービスに対するその近さを認識しているピアに焦点を当て得る。例えば、Ｐ２Ｐ通信は、集中型コントローラを含む集中型システム、または中央コントローラを伴わない完全分散型システムにおいて実装され得る。インフラストラクチャレスのＰ２Ｐ通信とは対照的に、インフラストラクチャベースの通信は、多くの場合、例えば、ユーザ情報を取り扱い、ユーザ間をスケジューリングし、接続を管理するための、集中型コントローラを含む（例えば、セルラー通信）。インフラストラクチャレスのＰ２Ｐ通信では、ピアは、典型的には、通信セッションを開始、維持、および終了させることに対して等しい責任を有する。近接ベースのアプリケーションおよびサービスは、最近の社会技術的傾向を表す。Ｐ２Ｐ近接通信は、例えば、ソーシャルネットワーク、広告、緊急事態、ゲーム、スマート輸送、およびネットワークシナリオのネットワーク等、種々の実装において使用される。

典型的なソーシャルネットワークの実装では、近接したピアは、アプリケーションレベルにおいて互に相互作用することができる（例えば、Ｆａｃｅｂｏｏｋ、Ｔｗｉｔｔｅｒ）。２つ以上のピア間での双方向通信は、多くの場合、Ｐ２Ｐ近接通信のソーシャルネットワークの実装において要求される。トラフィックデータレートは、低（例えば、テキストベースのチャット）または高（例えば、コンテンツ共有）であり得る。Ｐ２Ｐ近接通信の例示的な広告の実装では、店舗は、その宣伝およびクーポンを、店舗の場所の近接範囲内にいる潜在的顧客（ピア）にブロードキャストする。本例示的シナリオでは、低データトラフィックを伴う一方向通信が典型的であるが、（例えば、個別化された広告のために）双方向通信が使用され得る。

緊急事態でのＰ２Ｐ近接通信の実装は、通常、例えば、非常アラーム等、一方向通信を伴う。他の緊急事態の実装は、緊急事態安全管理シナリオの間等、双方向通信を必要とする。Ｐ２Ｐの緊急事態サービス／アプリケーションは、他のＰ２Ｐサービス／アプリケーションよりも高い優先順位を有し得、いくつかの緊急事態サービス／アプリケーションは、より高いプライバシー要件を有し得る。Ｐ２Ｐの例示的なゲーム機の実装では、複数のピアが、双方向ゲーム（例えば、あるルールに従うオンラインマルチプレーヤゲーム等）を初期化し、またはこれに参加する。双方向Ｐ２Ｐゲームは、多くの場合、低待ち時間を要求する。Ｐ２Ｐ近接通信の例示的なスマート輸送の実装では、カーツーカーおよび／またはカーツーインフラストラクチャ通信を介したコネクテッドカーが、例えば、混雑／事故／イベントの通知、カープールおよび列車スケジューリング等の双方向輸送管理、スマート交通制御等を含む、高度なアプリケーションをサポートすることができる。スマート輸送の実装におけるデータレートは、多くの場合、低いが、スマート輸送は、非常に信頼性のあるメッセージ送達、および非常に短い待ち時間を要求し得る。ネットワークツーネットワークＰ２Ｐは、インフラストラクチャの範囲を拡張し、インフラストラクチャからオフロードするために使用され得る。マルチホップは、独特の特徴であり得る。

前述のＰ２Ｐ通信の例示的実装は、マシンツーマシン（Ｍ２Ｍ）およびモノのインターネット（ＩｏＴ）のアプリケーションに関し得る。Ｍ２Ｍ／ＩｏＴのアプリケーションのための近接通信に対する既存のアプローチは、性能問題を有する。例えば、コンテキスト情報は、多くの場合、コンテキスト情報が種々の層またはピアの間で共有されない孤立した様式で管理されている。

場所情報、移動情報、デバイス能力、ユーザ情報、アプリケーションカテゴリ、マルチホップ情報、チャネル状況、アプリケーション情報、関連付け識別子、デバイス情報等、コンテキスト情報の管理に対する現在のアプローチは、ピアツーピア（Ｐ２Ｐ）システムにおける能力を欠いている。例えば、コンテキスト情報は、多くの場合、コンテキスト情報が種々の層またはピアの間で共有されないように、孤立した様式で管理される。システム、方法、および装置の実施形態が、媒体アクセス制御（ＭＡＣ）層におけるコンテキスト情報管理のために、本明細書に説明される。

例示的実施形態によると、システムは、ピアツーピア通信を介して通信する、複数のピアを備えている。各ピアデバイスは、コンテキストマネージャを含み得る。複数のデバイスのうちの第１のデバイスの第１のコンテキスマネージャは、１つ以上のパラメータを備えているコンテキスト情報要求フレームを受信し得る。１つ以上のパラメータは、コンテキスト動作のリスト、コンテキスト識別のリスト、または応答タイプのうちの少なくとも１つを示し得る。コンテキスト情報要求フレームに基づいて、第１のデバイスは、残りの応答の数、１つ以上のコンテキストフレームのうちの選択された１つに適用可能な肯定応答要件、１つ以上のコンテキストフレームのうちの選択された１つに適用可能な動作のリスト、１つ以上のコンテキストフレームのうちの選択された１つに適用可能なコンテキスト識別のリスト、または１つ以上のコンテキスト値のうちの少なくとも１つを示す、１つ以上のコンテキスト情報応答フレームを生成し得る。コンテキスト情報要求フレームは、媒体アクセス制御（ＭＡＣ）層を経由して受信され得る。さらに、第１のデバイスは、ＭＡＣ層を経由して、１つ以上のコンテキストフレームのうちの選択された１つを、複数のデバイスのうちの第２のデバイスの第２のコンテキストマネージャに送信し得る。

本概要は、発明を実施するための形態において以下でさらに説明される、簡略化形態の概念の選択を導入するように提供される。本概要は、請求された主題の主要な特徴または不可欠な特徴を識別することを目的としておらず、また、請求された主題の範囲を限定するために使用されることも目的としていない。さらに、請求された主題は、本開示の任意の部分で記述されるいずれかまたは全ての不利点を解決する制限に限定されない。

図１は、ある例示的実施形態による、近接通信のためのコンテキスト管理アーキテクチャを描写するブロック図である。 図２は、ある例示的実施形態による、プロキシベースのコンテキスト管理アーキテクチャを描写するブロック図である。 図３は、ある例示的実施形態による、リモートコンテキスト動作のためのコールフローである。 図４Ａは、ある例示的実施形態による、ローカルコンテキスト動作のためのコールフローを例証する。 図４Ｂは、別の実施形態による、ローカルコンテキスト動作のための別のコールフローを例証する。 図５は、ある例示的実施形態による、プロキシベースのコンテキスト動作のためのコールフローを例証する。 図６は、別の例示的実施形態による、プロキシベースのコンテキスト動作のための別のコールフローを例証する。 図７は、ある例示的実施形態による、セッションベースのコンテキスト動作のためのコールフローを例証する。 図８Ａは、ある実施形態による、例示的かつ非限定的な修正されたおよび／または拡張された一般的ＭＡＣフレーム形式を例証する。 図８Ｂは、ある実施形態による、例示的かつ非限定的なフレーム制御フィールド形式を例証する。 図９Ａは、ある実施形態による、例示的かつ非限定的な修正および／または拡張されたビーコンフレーム形式を例証する。 図９Ｂは、ある実施形態による、例示的かつ非限定的なスーパーフレーム情報形式を例証する。 図９Ｃは、ある実施形態による、例示的かつ非限定的なアプリケーションフレーム情報形式を例証する。 図１０Ａは、ある実施形態による、例示的かつ非限定的な関連付け要求フレーム形式を例証する。 図１０Ｂは、ある実施形態による、例示的かつ非限定的な関連付け応答フレーム形式を例証する。 図１０Ｃは、ある実施形態による、例示的かつ非限定的な分離要求フレーム形式を例証する。 図１０Ｄは、ある実施形態による、例示的かつ非限定的な分離応答フレーム形式を例証する。 図１０Ｅは、ある実施形態による、例示的かつ非限定的な関連付け更新通知フレーム形式を例証する。 図１０Ｆは、ある実施形態による、例示的かつ非限定的な関連付け更新応答フレーム形式を例証する。 図１１Ａは、ある実施形態による、例示的かつ非限定的なＰ２ＰＮＷ間チャネル分配要求フレーム形式を例証する。 図１１Ｂは、ある実施形態による、例示的かつ非限定的なＰ２ＰＮＷ間チャネル分配応答フレーム形式を例証する。 図１１Ｃは、ある実施形態による、例示的かつ非限定的なＰ２ＰＮＷ内チャネル分配要求フレーム形式を例証する。 図１１Ｄは、ある実施形態による、例示的かつ非限定的なＰ２ＰＮＷ内チャネル分配応答フレーム形式を例証する。 図１２Ａは、１つ以上の開示される実施形態が実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）またはモノのインターネット（ＩｏＴ）の通信システムの系統図である。 図１２Ｂは、図１２Ａに例証されるＭ２Ｍ／ＩｏＴ通信システム内で使用され得る、例示的アーキテクチャの系統図である。 図１２Ｃは、図１２Ａに例証される通信システム内で使用され得る、例示的Ｍ２Ｍ／ＩｏＴ端子またはゲートウェイデバイスまたはピアデバイスの系統図である。 図１２Ｄは、図１２Ａの通信システムの側面が実施され得る、例示的コンピューティングシステムのブロック図である。

ピアツーピア（Ｐ２Ｐ）ネットワーク（Ｐ２ＰＮＷ）は、例えば、アプリケーションまたはサービス等、所望のコンテキストによって形成され得る。異なる層からのコンテキスト情報が、Ｐ２Ｐ通信の管理に大きく関わり得る。本明細書に使用される場合、コンテキスト情報は、概して、サービス、アプリケーション、デバイス、ネットワーク、またはその組み合わせの場面的状態または状況を、説明、追跡、および／または推測するために使用され得る情報を指し得る。コンテキスト情報の例は、例として提示され、限定ではないが、場所情報、時間情報、アプリケーションカテゴリ、サービス電力カテゴリ、任意のユーザ情報、マルチホップ情報、移動情報、チャネル状況情報、関連付け情報、デバイス情報、他のアプリケーションまたはサービス情報等を含む。コンテキスト情報の取り扱いに対する既存のアプローチは、典型的には、孤立した方法で行われる。例えば、コンテキスト情報は、層またはエンティティにおいて記憶され得、層またはエンティティ間で渡されない。このアプローチは、Ｐ２Ｐ通信に対して非効率的であり得る。例えば、Ｐ２ＰＮＷが形成されるとき、ピアの発見／関連付けは、アプリケーション情報に基づく決定を伴い得、より低い層からの測定を伴い得る。本明細書に使用される場合、ピアの発見は、Ｐ２Ｐ近接通信を有効化するために、ピアの関連付けの前に、１つ以上の他のピアを見出すために、ピアに対して使用されるプロセスを指し得る。ピアの関連付けは、Ｐ２Ｐデータ伝送が始まり得る前に、１つ以上の他のピアとの論理的関係を確立するために、ピアに対して使用されるプロセスを指し得る。ピアの関連付けはまた、限定されないが、ピアアタッチメント、ピアリング、ペアリング、またはリンク確立とも称され得る。例示的実施形態によると、コンテキスト情報は、Ｐ２Ｐ通信のために、異なる層を横断して効率的に管理される。

多くの場合、コンテキスト情報の取り扱いに対する既存のアプローチでは、異なるアプリケーションからのコンテキスト情報は、共有されない。Ｐ２Ｐ通信では、同じコンテキスト情報は、類似した手順に関わり得る。例えば、場所情報は、ゲームアプリケーション、広告／ショッピングアプリケーション、およびソーシャルネットワークアプリケーションによって共有され得る。例示的実施形態によると、異なるアプリケーションに対するコンテキスト情報が、種々のピアが異なるアプリケーションからのコンテキスト情報を要求し、これにアクセスできるように、効率的に共有および管理される。

例示的実施形態では、コンテキスト情報は、Ｐ２Ｐ通信の間、ピア間で直接交換される。例えば、Ｐ２Ｐ通信のためのピアの関連付けの間、コンテキスト情報（例えば、アプリケーション情報、関連付け識別子、ユーザおよび／またはデバイス情報）が交換され得る。以下に説明されるのは、Ｐ２Ｐ通信におけるコンテキスト管理のためのメッセージおよび基準点である。例えば、クライアント／サーバベースおよびプロキシベースのＭＡＣ層コンテキスト管理アーキテクチャが、以下に説明される。

コンテキスト管理機能および方法の種々の実施形態が、本明細書にさらに説明される。一実施形態によると、効率的なコンテキスト動作が、ピアまたはデバイス間で発生し、１つのコンテキスト動作要求が、複数のＭＡＣフレームを応答としてもたらし得る。本明細書に説明されるように、効率的なコンテキスト動作は、プロトコル層間で発生し得、同じピアデバイス上で機能する。別の例示的実施形態では、プロキシベースのコンテキスト動作が発生し、ピアは、他のピアを代表してコンテキスト情報を要求および動作することができる。さらに別の例示的実施形態では、セッションベースのコンテキスト動作が発生し、複数（例えば、２つ）のピアまたはデバイスが、継続してコンテキスト情報を交換するために、ＭＡＣ層セッションを確立することができる。

近接通信のアプリケーション（実装）は、ピア間でコンテキスト情報を交換することから利益を享受し得る。例として、４つのピアが、オンラインゲームをプレイする間、近接範囲内にあり得る。ピアは、例えば、限定ではないが、その場所情報、移動情報、デバイス能力（例えば、音声、スクリーンサイズ等をサポートするかどうか）、ユーザ情報（例えば、ゲームでのレベルまたは精通度）等、コンテキスト情報を交換し得る。そのようなコンテキスト情報の交換は、ユーザのゲーム体験を改善し得る。前述の例は、コンテキスト情報が４つのデバイス間で交換されるシナリオを描写するが、コンテキスト情報の交換は、所望に応じて、ピアデバイスの任意の数の間で発生し得ることが理解されるであろう。

図１を参照すると、例示的コンテキスト管理システム１００は、各々が近接通信を介して通信する１つ以上のピアデバイス１０２を含み得る。例証されるように、コンテキスト管理システム１００は、第１のピアデバイス１０２ａおよび第２のピアデバイス１０２ｂを含む。本明細書に使用されるように、ピアデバイスは、単純に、ピアと称され得、ピアは、通信チャネルまたはネットワークを介して別のデバイスに接続される任意のデバイスを指し得る。ピアは、タブレット、スマートフォン、音楽プレーヤ、ゲーム機、携帯情報端末、ラップトップ、ＰＣ、医療デバイス、コネクテッドカー、スマートメータ、ホームゲートウェイ、モニタ、アラーム、センサ、セットトップボックス、プリンタ、２Ｇネットワーク内の移動局（ＭＳ）、３Ｇネットワーク内のユーザ機器（ＵＥ）、あるいはＩＥＥＥ ８０２．１５（無線パーソナルエリアネットワーク（ＷＡＮ））ネットワーク内の１つまたはグループのフル機能デバイス（ＦＦＤ）または低減機能（ＲＦＤ）であり得る。一実施例として、ピアは、図１２Ｃに例証されるハードウェアアーキテクチャを有し得、これまたはその変形例は、以下でより完全に説明され、あるいはピアは、図１２Ｄに例証されるコンピューティングシステムのアーキテクチャを有し得、これもまた、以下でより完全に説明される。例示的システム１００は、開示される主題の説明を促進するために簡略化され、本開示の範囲を限定することは意図されないことが理解されるであろう。システム１００等のシステムに加えて、またはこれの代わりに、他のデバイス、システム、および構成が、本明細書に開示される実施形態を実装するために使用され得、全てのそのような実施形態は、本開示の範囲内であると見なされる。

図１を参照すると、システム１００は、１つ以上のコンテキストマネージャ１０４を含み得る。システム１００における各ピアデバイス１０２は、コンテキストマネージャ（ＣＭ）１０４を含み得る。デバイスのコンテキストマネージャ１０４は、１つ以上のピアデバイスに関連付けられるコンテキスト情報を管理するデバイスのプロセッサ上で実行するハードウェアおよび／またはソフトウェアモジュールであり得る。例証される第１のピア１０２ａは、第１のコンテキストマネージャ１０４ａを含み、例証される第２のピア１０２ｂは、第２のコンテキストマネージャ１０４ｂを含む。ピアデバイス１０４ａは、物理（ＰＨＹ）層１０６ａ、媒体アクセス制御（ＭＡＣ）層１０８ａ、およびＭＡＣ層１０８ａよりも高い層を含み、これは、より高い層１１０ａと称される。ピアデバイス１０４ｂは、物理（ＰＨＹ）層１０６ｂ、媒体アクセス制御（ＭＡＣ）層１０８ｂ、およびＭＡＣ層１０８ｂよりも高い層を含み、これは、より高い層１１０ｂと称される。コンテキストマネージャ１０４ａおよび１０４ｂは、媒体アクセス制御（ＭＡＣ）層１０６上で機能し得、したがって、コンテキストマネージャ１０４ａおよび１０４ｂは、概して、例えば、ＭＡＣ層論理機能と称され得る。他のＭＡＣ層機能、例えば、ＭＡＣ層論理機能１１２ａおよび１１２ｂは、ＭＡＣ層１０８におけるピアデバイス１０４上に常駐し得る。ＭＡＣ層論理機能１１２ａおよび１１２ｂは、例えば、発見、関連付け、中継等の機能性を含み得る。コンテキストマネージャ１０４の各々は、それらのそれぞれのピアデバイス内でコンテキストデータベースを維持し得る。コンテキスト情報は、コンテキストデータベース内に記憶され得る。コンテキストデータベースは、コンテキストデータベースが常駐するピアデバイスに関連付けられるコンテキスト情報を含み得る。加えて、または代替として、コンテキストデータベースは、コンテキストデータベースとは別個に位置する他のピアデバイスに関連付けられるコンテキスト情報を含み得る。

コンテキストマネージャ、例えば、第１のＣＭ１０４ａは、コンテキスト管理関連要求を、他のコンテキストマネージャ１０４、例えば、第２のＣＭ１０４ｂに発行し得る。コンテキストマネージャ１０４はまた、他のコンテキストマネージャ１０４から要求を受信し、要求への応答を生成し得る。例示的実施形態によると、第１のコンテキストマネージャ１０４ａは、ローカルのより高い層１０６ａ、ローカルＭＡＣ機能１１２ａ、およびローカル物理（ＰＨＹ）層１０６ａから要求を受信し得る。ＣＭ１０４ａは、そのような要求に応答し得る。ＣＭ１０４ａは、例えば、発見、関連付け、中継等、他のＭＡＣ論理機能１０８ａによって直接アクセスされ得る。ＣＭ１０４ａは、層間プリミティブを通して、例えば、１つ以上のアプリケーション等、より高い層１１０ａと、ＰＨＹ層１０８ａと直接相互作用し得る。

継続して図１を参照すると、ピアデバイスのＣＭ、例えば、第１のデバイス１０２ａの第１のＣＭ１０４ａは、別のピアのＣＭ、例えば、第２のデバイス１０４ｂの第２のＣＭ１０４ｂに、ＣＭインタフェース（Ｉｃｍ）１１４を経由するＭＡＣ層フレームを通して、通信することができる。少なくとも２つのコンテキストマネージャが互に通信するとき、クライアント／サーバモデルが、例示的実施形態に従って使用され得る。例えば、第１のＣＭ１０４ａが第２のＣＭ１０４ｂと通信するとき、コンテキストマネージャ１０４ａおよび１０４ｂのうちの一方は、クライアントとして機能し得、コンテキストマネージャ１０４ａおよび１０４ｂのうちの他方は、サーバとして機能し得る。したがって、ＣＭ１０４は、クライアントＣＭ（ＣＭＣ）またはサーバＣＭ（ＣＭＳ）と称され得る。クライアントＣＭは、要求を、サーバＣＭに送信し得、サーバＣＭからの応答を待ち得る。ある例示的実施形態では、サーバＣＭは、同時に、マルチキャスト／ブロードキャストを介して、他のピア上の複数の他のコンテキストマネージャと通信することができる。より高い層、ＰＨＹ層、またはＭＡＣ層機能が、要求されるコンテキスト情報をローカルＣＭ（同じピア上のＣＭ）から見出せない例示的シナリオでは、ローカルＣＭは、要求されるコンテキスト情報のための要求を送信することによって、リモートＣＭ（別のピア上のＣＭ）にコンタクトすることができる。ＣＭは、例えば、コンテキストフィルタリング、コンテキスト要約、コンテキスト集約等、コンテキスト分析または動作を実施し得る。

図２を参照すると、例示的なプロキシベースのコンテキスト管理システム２００は、近接通信を介して互に通信する１つ以上のピアデバイス１０２を含み得る。例証されるように、システム２００は、クライアントＣＭとしての機能を果たし得る第１のＣＭ１０４ａと、サーバＣＭとしての機能を果たし得る第２のＣＭ１０４ｂとを含む。例証される実施形態によると、例示的システム２００は、１つ以上のコンテキストマネージャ１０４と通信し得るコンテキストマネージャプロキシ（ＣＭＰ）２０２を含む。例示的システム２００は、開示される主題の説明を促進するために簡略化され、本開示の範囲を限定することは意図されないことが理解されるであろう。システム２００等のシステムに加えて、またはこれの代わりに、他のデバイス、システム、および構成が、本明細書に開示される実施形態を実装するために使用され得、全てのそのような実施形態は、本開示の範囲内であると見なされる。

依然として図２を参照すると、例証される配列によると、ＣＭ１０２ａは、コンテキスマネージャクライアント（ＣＭＣ）１０２ａとも称され得、ＣＭ１０２ｂは、コンテキスマネージャサーバ（ＣＭＳ）１０２ｂとも称され得る。ＣＭＣ１０２ａは、ＣＭＰ２０２を介してＣＭＳ１０２ｂと間接的に通信し得る。コンテキストマネージャ１０４ａおよび１０４ｂ、ならびにＣＭＰ２０２は、媒体アクセス制御（ＭＡＣ）層１０６上で機能し得、したがって、ＣＭＰ２０２ならびにコンテキストマネージャ１０４ａおよび１０４ｂは、概して、ＭＡＣ層機能と称され得る。さらに、ピアデバイス１０２のＣＭ１０４は、ＣＭＣ、ＣＭＰ、および／またはＣＭＳの組み合わせとして機能し得る。図２を参照すると、例証される実施例によると、ＣＭＣ１０４ａは、１つ以上の要求２０４を、ＣＭＰ２０２に発行し得、ＣＭＣ１０２ａは、１つ以上の応答２０６を、ＣＭＰから受信し得る。ＣＭＰ２０２が要求２０４ａをＣＭＣ１０４ａから受信すると、ＣＭＰ２０２は、種々の機能を実施し得る。例えば、ＣＭＰ２０２は、必要に応じて、要求２０４ａを、ＣＭＳ１０４ｂが理解できる形式に変換し得る。ＣＭＰは、変換された要求であり得る要求２０４ｂを、ＣＭＳ１０４ｂに自動転送し得る。要求２０４ｂに応答して、ＣＭＳ１０４ｂは、応答２０６ａを、ＣＭＰ２０２に送信し得、ＣＭＰ２０２は、次いで、応答２０６ｂを、ＣＭＣ１０４ｂに送信し得る。代替として、ＣＭＰ２０２は、応答２０６ｂを、ＣＭＣ１０４ａに、ＣＭＳ１０４ｂにコンタクトすることなく直接送信し得る。ＣＭＳ１０４は、変換された要求２０４ｂをＣＭＰ２０２から受信し得、応答２０６ａを、ＣＭＣ１０４ａに返信し得る。例として、ピアであるプレーヤのグループ内の１人のゲームプレーヤは、プレーヤ間でコンテキスト情報の交換を管理および制御するために、ＣＭＰ２０２として作用し得る。さらなる例として、ゲームシナリオ内のＣＭＰ２０２は、コンテキスト情報が他のピアによって共有および発見され得るように、ピアについてのコンテキスト情報を収集し得る。

図１および２に関して前述されるようなコンテキストマネージャ１０２は、例として提示され、限定ではないが、リモートコンテキスト動作、ローカルコンテキスト動作、プロキシベースのコンテキスト動作、およびセッションベースのコンテキスト動作等、種々の動作を実施し得る。リモートコンテキスト動作の実施例では、１つのピアのＣＭが、異なるピアの他のコンテキストマネージャによって維持されるコンテキスト情報に対する動作を実施する。リモートコンテキスト動作は、例えば、コンテキスト情報を追加すること、コンテキスト情報を読み出すこと、コンテキスト情報を更新すること、コンテキスト情報に加入すること、コンテキスト情報の複数のインスタンスを集約すること等を含み得る。例示的実施形態によると、ローカルコンテキスト動作は、ピアのＣＭ、例えば、第１のピアデバイス１０２ａの第１のＣＭ１０４ａと、そのピアデバイスの他の層、例えば、ピアデバイス１０２ａの他のＭＡＣ層機能１１２ａまたはＰＨＹ層１０６ａとの間で実施されるコンテキスト動作を指す。さらなる例として、第１のＣＭ１０４ａが、特定の動作を実施するために要求されるコンテキスト情報を有しない場合、ＣＭ１０４ａは、例えば、第２のＣＭ１０４ｂ等、リモートＣＭにコンタクトするために、リモートコンテキスト動作を活用し得る。プロキシベースのコンテキスト動作は、１つのＣＭが、ＣＭＣとＣＭＳとの間の通信を調整するためのプロキシとして作用する動作を指す（図２参照）。図１を参照すると、例として、第１のＣＭ１０４ａおよび第２のＣＭ１０４ｂは、コンテキスト情報を交換する前に、ＭＡＣ層においてセッションを確立し得る。したがって、続くコンテキスト動作は、セッションベースのコンテキスト動作と称され得、これは、ピアデバイス１０２ａと１０２ｂとの間でのコンテキスト情報の効率的な交換をもたらし得る。

ここで、図３を参照すると、リモートコンテキスト動作の実施例が例証され、リモートコンテキスト動作は、第１のピア１０２ａおよび第２のピア１０２ｂによって、特に、第１のＣＭ１０４ａおよび第２のＣＭ１０４ｂによって実施される。例証される実施形態によると、３０２において、第１のＣＭ１０４ａは、コンテキスト情報要求フレームを、第２のＣＭ１０４ｂに送信する。コンテキスト要求フレームは、概して、メッセージと称され得、例えば、コンテキスト動作のリスト、コンテキスト識別のリスト、応答指示等、種々のフィールドまたはパラメータを含み得る。したがって、第２のＣＭ１０４ｂは、コンテキスト動作のリスト、コンテキスト識別のリスト、または応答タイプのうちの少なくとも１つを示す、１つ以上のパラメータを受信し得る。コンテキスト情報要求フレームは、媒体アクセス制御（ＭＡＣ）層を経由して受信され得る。コンテキスト動作のリストは、第２のＣＭ１０４ｂによって実施されるべき要求される動作を示し得る。第１のＣＭ１０４ａは、１つ以上の、例えば、複数の動作を、１つのコンテキスト要求フレーム内で要求し得る。コンテキスト識別のリストは、動作が実施されるであろうコンテキストを示し得る。したがって、コンテキストＩＤは、コンテキストデータベースにおいてコンテキストエンティティを識別し得る。コンテキストエンティティは、パラメータ、データセット、アプリケーション、サービス、ピアデバイス等を指し得る。応答指示は、第２のＣＭ１０４ｂから第１のＣＭ１０４ａへの応答が、１つのＭＡＣフレーム内で送信されるべきか、または別個の複数のＭＡＣフレーム内で送信されるべきかを示し得る。

継続して図３を参照すると、３０４において、第２のＣＭ１０４ｂは、コンテキスト情報応答フレームを、第１のＣＭ１０４ａに送信し得る。いくつかの場合では、第１のＣＭ１０４ａへの応答は、長すぎて１つのＭＡＣフレーム内に含まれないことがある。したがって、そのような場合では、複数のＭＡＣフレームが、使用され得る。コンテキスト応答フレームは、概して、メッセージと称され得、例えば、残りの応答の数、肯定応答（ＡＣＫ）指示、動作のリスト、コンテキスト識別（ＩＤ）のリスト、コンテキスト値等、種々のフィールドまたはパラメータを含み得る。したがって、コンテキスト情報要求フレームに基づいて、第２のデバイス１０２ｂ、特に、第２のＣＭ１０４ｂは、残りの応答の数、１つ以上のコンテキストフレームのうちの選択された１つに適用可能な肯定応答要件、１つ以上のコンテキストフレームのうちの選択された１つに適用可能な動作のリスト、１つ以上のコンテキストフレームのうちの選択された１つに適用可能なコンテキスト識別のリスト、または１つ以上のコンテキスト値のうちの少なくとも１つを示す、１つ以上のコンテキスト情報応答フレームを生成し得る。コンテキスト情報要求フレームは、ＭＡＣ層を経由して送信され得る。例示的実施形態では、残りの応答パラメータの数は、応答が３０４において送信された後、いくつの応答が、特に、いくつのコンテキスト応答フレームが、第２のＣＭ１０４ｂによって送信されるために残っているかを示す。ＡＣＫ指示は、肯定応答が、３０４において送信されるコンテキスト応答フレームに対して要求されるかどうかを示し得る。例えば、肯定応答が要求される場合、第１のＣＭ１０４ａは、３０６において肯定応答を送信し得る。ＡＣＫ指示はまた、肯定応答が、残りの応答の各々に対して要求されるか、または肯定応答が、ある数（例えば、一部）の応答のみに対して要求されるかも示し得る。動作のリストは、１つ以上の応答に対応する１つ以上の動作を示し得る。例示的動作は、例として提示され、限定ではないが、「取得」、「読み出し」、または「報告」を含む。コンテキストＩＤのリストは、１つ以上の応答に対応するコンテキストエンティティを示し得る。コンテキスト値は、要求されるコンテキスト情報または関連するコンテキスト情報の値を含み得る。例として、要求されるコンテキスト情報またはコンテキストエンティティは、速度に関し得、したがって、コンテキスト値は、１つ以上の速度値であり得る（例えば、時速３０マイル、時速６５マイル等）。別の例として、要求されるコンテキスト情報は、ピアデバイスに関連付けられる温度を指し得、したがって、読み出され、または報告され得るコンテキスト値は、温度値であり得る。

３０６において、例証される実施形態によると、第１のＣＭ１０４ａは、コンテキスト応答ＡＣＫフレームを、第２のＣＭ１０４ｂに送信する。前述のように、３０４において送信されたメッセージは、３０４におけるコンテキスト応答フレームが第１のＣＭ１０４ａによって受信されたことの確認を提供するそのような肯定応答を要求し得る。３０８において、第２のＣＭ１０４ｂは、残りのコンテキスト応答を、第１のＣＭ１０４ａに送信し得る。３０８において送信された応答は、ステップ３０４を参照して前述されるパラメータに少なくとも類似するパラメータを含み得る。３１０において、第１のＣＭ１０４ａは、コンテキスト応答ＡＣＫを、第２のＣＭ１０４ｂに送信する。ある例示的実施形態では、前述のステップのいくつかまたは全ては、３０２における要求によって要求される全ての応答が、第２のＣＭ１０４ｂから第１のＣＭ１０４ａに伝送されるまで繰り返される。したがって、２つのコンテキスト応答フレームが図３で例証されるが、必要に応じて、コンテキスト応答フレームの任意の数が、要求され得ることが理解されるであろう。さらに、必要に応じて、応答の肯定応答の任意の数が、送信され得ることが理解されるであろう。さらにまた、例証されるコンテキスト応答フレームの数は、応答の肯定応答フレームの数と等しいが、応答の肯定応答の数は、例示的実施形態による、コンテキスト応答フレームの数と比較して変動し得る。

ここで、図４Ａおよび４Ｂを参照すると、ローカルコンテキスト動作の実施例が例証され、ローカルコンテキスト動作は、第１のピア１０２ａによって、特に、第１のＣＭ１０４ａによって実施される。図４Ａを参照すると、例証される実施形態によると、４０２において、より高い層１１０ａ、ＰＨＹ層１０６ａ、またはＭＡＣ層機能１０８ａが、コンテキスト要求プリミティブを、第１のＣＭ１０４ａに発行する。したがって、第１のピアデバイス１０２ａの第１のＣＭ１０４ａは、コンテキスト要求プリミティブを、第１のピアデバイス１０２ａの別の層またはＭＡＣ層機能から受信する。このプリミティブは、例えば、限定ではないが、プリミティブのタイプを示し得るプリミティブ識別子（ＩＤ）、実施されるべき要求されるコンテキスト動作のリスト、動作が実施されるであろうコンテキストＩＤを示し得るコンテキストＩＤのリスト等、種々の情報を含み得る。４０４において、例証される実施形態によると、第１のＣＭ１０４ａは、コンテキスト確認プリミティブを、より高い層１１０ａ、ＰＨＹ層１０６ａ、またはＭＡＣ層機能１０８ａに送信する。４０４におけるプリミティブは、プリミティブのタイプを示すプリミティブＩＤを含み得る。４０４において送信されたプリミティブはさらに、１つ以上のコンテキスト値を含み得、これは、要求されるコンテキスト情報の値を表し得る。

特に、図４Ｂを参照すると、例証される実施形態によると、４０６において、第１のＣＭ１０４ａは、コンテキスト指示プリミティブを、より高い層１１０ａ、ＰＨＹ層１０６ａ、またはＭＡＣ層機能１０８ａに送信する。このプリミティブは、例えば、限定ではないが、プリミティブのタイプを示すプリミティブＩＤ、実施されるべき動作を示し得るコンテキスト動作のリスト、動作が実施されるであろうコンテキストＩＤを示し得るコンテキストＩＤのリストを含み得る。４０８において、より高い層１１０ａ、ＰＨＹ層１０６ａ、またはＭＡＣ機能は、コンテキスト応答プリミティブを、第１のＣＭ１０４ａに、同じピア（ピアデバイス１０２ａ）上で発行し得る。このプリミティブは、プリミティブのタイプを示すプリミティブＩＤおよび要求されるコンテキスト情報の値を示すコンテキスト値を備え得る。

図５は、近接通信を介して互に通信する、１つ以上のピアデバイス１０２を含み得る例示的なプロキシベースのコンテキスト管理システム５００を例証する。例証されるように、システム５００は、第１のピアデバイス１０２ａの第１のＣＭ１０４ａ、第２のピアデバイス１０２ｂの第２のＣＭ１０４ｂ、第３のピアデバイス１０２ｃの第３のＣＭ１０４ｃ、および第４のピアデバイス１０２ｄの第４のＣＭ１０４ｄを含む。例証される実施形態によると、第１のＣＭ１０４ａは、コンテキストマネージャクライアント（ＣＭＣ）１０４ａとしての機能を果たし、第２のＣＭ１０４ｂは、コンテキストマネージャプロキシ（ＣＭＰ）１０４ｂとしての機能を果たし、かつ第３および第４のコンテキストマネージャ１０４ｃおよび１０４ｄは、それぞれ、コテキストマネージャサーバ１０４ｃおよび１０４ｄとしての機能を果たす。例示的システム５００は、開示される主題の説明を促進するために簡略化され、本開示の範囲を限定することは意図されないことが理解されるであろう。システム５００等のシステムに加えて、またはこれの代わりに、他のデバイス、システム、および構成が、本明細書に開示される実施形態を実装するために使用され得、全てのそのような実施形態は、本開示の範囲内であると見なされる。

依然として図５を参照すると、５０２において、第１のピアデバイス１０２ａの第１のＣＭ１０４ａが、コンテキスト応答フレームを、第２のピアデバイス１０２ｂの第２のＣＭ１０４ｂに送信する。例示的コンテキスト要求フレームが、図２を参照して前述されている。５０４において、ＣＭ１０４ｂは、そのローカルコンテキストデータベースをルックアップする。例示的実施形態では、ＣＭ１０４ｂが、５０２からのコンテキスト要求に返答するための十分なコンテキスト情報をデータベース内に見出す場合、第２のＣＭ１０４ｂは、５０４において、コンテキスト応答フレームを、第１のＣＭ１０４ａに送信し得る。例示的コンテキスト応答フレームが、図２を参照して前述されている。代替として、例証される実施形態によると、５０３において、第２のＣＭ１０４ｂは、コンテキスト要求を、別のＣＭ、例えば、第３のＣＭＳ１０４ｃが理解する形式に変換し得る。５０６において、第２のＣＭ１０４ｂは、変換されたコンテキスト要求フレームを、第３のピアデバイス１０２ｃの第３のＣＭ１０４ｃに送信する。５０８において、第３のＣＭ１０４ｃは、コンテキスト応答フレームを、第２のＣＭ１０４ｂに送信する。５１０において、第２のＣＭ１０４ｂは、コンテキスト要求フレームを、第４のピアデバイス１０２ｄの第４のＣＭ１０４ｄ等、別のＣＭに送信し得る。５１２において、第４のＣＭ１０４ｄは、コンテキスト応答フレームを、ＣＭＰの第２のＣＭ１０４ｂに送信し得る。５１３において、第２のＣＭ１０４ｂは、第３および第４のコンテキストマネージャ１０４ｃおよび１０４ｄから受信された応答を集約し得る。例証されるＣＭ１０４ｂは、２つの応答を集約するが、所望に応じて、応答の任意の数が、ＣＭＰとして機能するＣＭによって集約され得ることが理解されるであろう。５１４において、例証される実施形態によると、第２のＣＭ１０４ｂは、１つ以上のコンテキスト応答フレーム内に集約された応答を、例証される実施形態によると、ＣＭＣとしての機能を果たす第１のＣＭ１０４ａに送信する。

図６は、図５において描写されるシステム５００を例証するが、図６は、別の例示的実施形態による、プロキシベースのコンテキスト動作の別の実施例を示す。図６を参照すると、６０２において、例証される実施形態によると、ＣＭＰとして機能する第２のＣＭ１０４ｂが、コンテキスト要求フレームを、例証される実施形態によると、ＣＭＳとして機能する第１のＣＭ１０４ａに送信する。いくつかの場合では、６０２の前に、第２のＣＭ１０４ｂは、第３のピア１０２ｃの第３のＣＭ１０４ｃおよび第４のピア１０４ｄの第４のＣＭ１０４ｄから要求を受信し得、これらは、６０２において要求を送信するように、第２のＣＭ１０４ｂをトリガする。図６において描写され、かつ例証される実施例によると、第３のＣＭ１０４ｃおよび第４のＣＭ１０４ｄは、コンテキストマネージャクライアントとして機能する。６０４において、第１のＣＭ１０４ａは、コンテキスト応答フレームを、第２のＣＭ１０４ｂに送信する。６０６において、第２のＣＭ１０４ｂは、受信した応答を解析し得る。第２のＣＭ１０４ｂは、少なくとも一部の、例えば、全てのコンテキスト応答フレームを、６０６において第３のＣＭ１０４ｃに自動転送し得る。６０８において、第３のＣＭ１０４ｃは、コンテキスト応答ＡＣＫを、第２のＣＭ１０４ｂに送信する。例示的コンテキスト応答の肯定応答が、図３を参照して前述されている。ステップ６１０において、第２のＣＭ１０４ｂは、少なくとも一部の、例えば、全てのコンテキスト応答フレームを、第４のＣＭ１０４ｄに自動転送し得る。第４のＣＭ１０４ｄは、コンテキスト応答フレームを受信し得、６１２において、コンテキスト応答ＡＣＫを、第２のＣＭ１０４ｂに送信し得る。

ここで、図７を参照すると、セッションベースのコンテキスト動作の実施例が例証され、セッションベースのコンテキスト動作は、第１のピア１０２ａおよび第２のピア１０２ｂによって、特に、第１のＣＭ１０４ａおよび第２のＣＭ１０４ｂによって実施される。７０２において、例証される実施形態によると、第１のＣＭ１０４ａは、コンテキスト開始フレームを、第２のＣＭ１０４ｂに送信し、コンテキスト交換セッション７００の開始を要求する。７０４において、第２のＣＭ１０４ｂは、コンテキスト交換セッション７００のための要求を承認するコンテキスト開始ＡＣＫフレームを第１のＣＭ１０４ａに送信する。したがって、コンテキスト交換セッション７００は、７０６において開始する。ステップ７０６において、第１のＣＭ１０４ａは、コンテキスト要求フレームを、前述のように、第２のＣＭ１０４ｂに送信する。７０８において、第２のＣＭ１０４ｂは、コンテキスト応答フレームを、第１のＣＭ１０４ａに送信する。ステップ７１０および７１２は、それぞれ、ステップ７０６および７０８を繰り返す。コンテキスト要求フレームおよびコンテキスト応答フレームの任意の数が、所望に応じて、第１および第２のＣＭ１０４ａおよび１０４ｂの間で交換され得ることが理解されるであろう。実施例として、７１０において、第１のＣＭ１０４ａは、第２のコンテキスト要求フレームを、第２のＣＭ１０４ｂに送信する。７１２において、第２のＣＭ１０４ｂは、第２のコンテキスト応答フレームを、第１のＣＭ１０４ａに、第２のコンテキスト要求フレームに応答して送信する。ステップ７１４において、第２のＣＭ１０４ｂは、コンテキスト要求フレームを、第１のＣＭ１０４ａに送信する。第２のＣＭ１０４ｂは、第２のＣＭ１０４ｂがコンテキスト応答を第１のＣＭ１０４ａに（７１２において）送信するとき、７１４におけるコンテキスト要求をピギーバックすることができる。したがって、７１２におけるメッセージは、７１４において送信されるメッセージの少なくともいくつかの、例えば、全てのコンテンツを含み得る。例示的実施形態では、第２のＣＭ１０４ｂはまた、第１のＣＭ１０４ａが第２のＣＭ１０４ｂからのコンテキスト情報を要求し終える前に、コンテキスト要求を送信することもできる。７１６において、例証される実施形態によると、第１のＣＭ１０４ａは、コンテキスト応答フレームを、第２のＣＭ１０４ｂに送信する。７１８において、第１のＣＭ１０４ａは、コンテキスト終了フレームを、第２のＣＭ１０４ｂに送信し、現在のコンテキスト交換セッション７００が停止されることを要求する。７２０において、例証される実施形態によると、第２のＣＭ１０４ｂは、コンテキスト交換セッション７００が停止されることを要求するコンテキスト終了フレームを肯定応答するために、コンテキスト終了肯定応答フレームを、第１のＣＭ１０４ａに送信し、それによって、コンテキスト交換セッション７００を終わらせる。

コンテキスト情報は、Ｐ２ＰＮＷを形成し、Ｐ２ＰＮＷ内での通信を有効化するために、ピアアウェア通信（ＰＡＣ）において広く使用される。しかしながら、コンテキスト情報は、既存のＩＥＥＥ ８０２．１５または８０２．１１ ＭＡＣフレームのいずれにも規定されていない。本明細書に説明されるように、コンテキスト情報の交換を有効化するために、かつコンテキストアウェアの発見、コンテキストアウェアの関連付け、コンテキストアウェアの同期、およびコンテキストアウェアの電力制御等、ＭＡＣ機能性をより効率的にするために、以下で開示されるように、現在のＭＡＣフレームへの修正および／または拡張が、実装され得、新しい情報要素（ＩＥ）が、定義され得る。さらに、ある実施形態では、本明細書に説明される修正および拡張されたフレーム形式およびＩＥは、前述のコンテキスト情報要求フレームおよびコンテキスト情報応答フレームを実装するために使用され得る。

ある実施形態では、コンテキストアウェアの発見、関連付け、電力制御、チャネル管理、および同期手順を促進するコンテキスト情報に関連する、ＭＡＣヘッダ内の新しいフィールドを伴う一般的ＭＡＣフレームであり得る、フレーム形式が使用され得る。新しいビーコンフレームがまた、スーパーフレーム構造およびアプリケーションフレームを定義する新しいフィールドとともに使用され得る。新しい管理フレームが、関連付けのプロパティを定義する新しいフィールドおよび関連するコンテキスト情報を示す新しいフィールドとともに、関連付け、分離、再関連付け、ならびに関連付け更新要求および応答をサポートするために使用され得る。別の新しい管理フレームは、コンテキストおよび電力制御についての情報を伝える新しいフィールドを含む、電力制御要求および応答フレームであり得る。さらに別の新しい管理フレームは、スーパーフレーム内のチャネルリソースの分配を伝える新しいフィールドを含む、共通制御／データチャネル（ＣＣＤＣＨ）または専用制御／データチャネル（ＤＣＤＣＨ）要求または応答フレームであり得る。ＣＣＤＣＨは、Ｐ２ＰＮＷ間通信のために定義され、近接したスーパーＶＬ、サブＶＬ、あるいはサービスまたはアプリケーションのピアによって共有される。例として、限定ではないが、ＣＣＤＣＨは、近接したＰ２ＰＮＷ間の共通制御メッセージ、近接したＰ２ＰＮＷへのページングまたはブロードキャストメッセージ、あるいは近接したＰ２ＰＮＷにブロードキャストされる、短く、優先順位の高いデータのために使用され得る。ＤＣＤＣＨは、Ｐ２ＰＮＷ内通信のために定義され、Ｐ２ＰＮＷ内のＶＬ、サブＶＬ、およびピアによって共有される。例として、限定ではないが、ＤＣＤＣＨは、Ｐ２ＰＮＷ内のＶＬ、サブＶＬ、ピア間の共通制御メッセージ、Ｐ２ＰＮＷ内のＶＬ、サブＶＬ、またはピアへのページングまたはブロードキャストメッセージ、あるいはＰ２ＰＮＷ内のＶＬ、サブＶＬ、またはピアにブロードキャストされる、短く、優先順位の高いデータ伝送のために使用され得る。

さらに、ある実施形態では、Ｐ２ＰＮＷ管理および通信のためのコンテキスト情報を伝えるコンテキスト情報ＩＥと、電力制御手順のための最も重要な情報を伝えるコンテキストおよび電力制御情報ＩＥとを含む、新しい情報要素（ＩＥ）が使用され得る。これらのフレームおよびＩＥについてのさらなる詳細が、本明細書に明記される。

図８Ａは、本明細書に説明されるコンテキスト管理手順に関係して使用され得る、修正されたＭＡＣフレーム形式８００の一実施形態を例証する。図８Ａ−Ｂ、９Ａ−Ｃ、１０Ａ−Ｆ、および１１Ａ−Ｄでは、太字、斜字、および下線で示されるフィールドは、新しいかまたは修正されたフィールドであり、それらは、新しいサブフィールドを含み得る。他のフィールドは、既存のＩＥＥＥ ８０２．１５．４および８０２．１１規格で定義されるものと同じ意味を有し得る。

示されるように、フレーム８００は、概して、ＭＡＣヘッダ８０２およびＭＡＣペイロード８０４を備えている。一実施形態では、フレーム内の全てのフィールドが、補助フィールド８１６および補助セキュリティヘッダ８１８を除いて要求され得る。ある実施形態では、シーケンス番号フィールド８０８および補助セキュリティヘッダ８１８は、ＩＥＥＥ ８０２．１５．４規格で定義されるものと同じ意味を有し得る。

本実施形態では、フレーム制御フィールド８０６は、フレームタイプ、肯定応答メッセージの要求されるタイプ、およびアドレッシングモード等、制御情報を伝える。図１１Ｂは、フレーム制御フィールドの形式５００の一実施形態を例証する。ある実施形態では、フレームタイプ、フレーム保留、フレームバージョン、セキュリティイネーブル、およびＩＥ現フィールドは、ＩＥＥＥ ８０２．１５．４規格で定義されるものと同じ意味を有し得る。一実施形態では、フレーム制御フィールド８０６内の全てのフィールドは、必須であり得る。

フレームタイプおよびサブタイプ８２４、８２６は、必須であり得ると同時に、フレームのタイプ、すなわち、フレームの機能を示し得る。一実施形態では、４つの基本フレームタイプである、ビーコン、管理、データ、および肯定応答が存在する。フレームの各タイプは、いくつかのサブタイプを有し得る。加えて、サブタイプフィールドの意味は、異なるフレームタイプに対して変動し得る。以下の表１、２、３、および４は、一実施形態で使用され得るフレームタイプおよびサブタイプの組み合わせを規定する。これらの表において、数値が与えられているが、ビット単位レベルにおいてではない。各サブタイプのための他の値が、使用され得る。各フレームタイプのさらなる詳細が、以下に提供される。

依然として図８Ｂを参照すると、ある実施形態では、フレーム制御フィールド８０６内の要求ＡＣＫタイプフィールド８２８は、どの肯定応答フレームが予期されるかを規定し得る。例えば、要求ＡＣＫタイプフィールドは、以下の表５に示されるように設定され得る。

再び図８Ａを参照すると、アドレッシングフィールドは、ソースアドレス、宛先アドレス、伝送ホップアドレス、および受信ホップアドレスのうちの１つ以上のものから成り得る。ソースアドレスおよび宛先アドレスのフィールドは、フレームのソースおよび宛先アドレスを伝え得る。伝送ホップアドレスおよび受信ホップアドレスのフィールドは、マルチホップのシナリオのために用意され得、中間ピアのアドレス情報を伝える。伝送ホップアドレスは、このフレームを送信するピアのアドレスである。受信ホップアドレスは、このフレームを受信するためのピアのアドレスである。伝送ホップアドレスおよび／または受信ホップアドレスのフィールドの存在は、アドレッシングフィールド指示によって示され得る。

図８Ａに示されるように、ＭＡＣフレーム形式８００はさらに、アドレッシングフィールド８１２内に伝送ホップアドレスおよび受信ホップアドレスの存在の指示を含み得るアドレッシングフィールド指示フィールド８１０を含み得る。ソースおよび宛先アドレスは、常に、アドレッシングフィールド８１２内に存在し得るが、伝送ホップアドレスおよび受信ホップアドレスの存在は、マルチホップのシナリオに対するオプションであり得る。例えば、ワンホップの伝送に対して、いずれも存在せず、マルチホップの伝送内の第１のホップに対して（すなわち、オリジナルソースは、フレームを送信中）、受信ホップアドレスのみが存在し、伝送ホップアドレスは、ソースアドレスと同じであり、マルチホップの伝送内の最終ホップに対して、伝送ホップアドレスのみが存在し、受信ホップアドレスは、宛先アドレスと同じであり、マルチホップの伝送内の他のホップに対して、伝送ホップアドレスおよび受信ホップアドレスの両方が含まれる。加えて、フレームは、アドレッシングフィールド指示が、最後の２つの例（最終ホップおよび他のホップ）としてセットアップされるとき、中継フレームであり得る。

図８Ａにさらに示されるように、Ｐ２ＰＮＷ／ＡＰＰ ＩＤフィールド８１４フィールドは、Ｐ２ＰネットワークＩＤまたはアプリケーションＩＤを含み得る。Ｐ２Ｐネットワーク（ＮＷ）に参加する全てのピアは、局所的に一意のＰ２ＰＮＷ／ＡＰＰ ＩＤを有し得る。フレームが送信されるとき、Ｐ２ＰＮＷ ＩＤが決定されていない場合、このフィールドは、アプリケーションＩＤを伝え得る。Ｐ２ＰＮＷは、アプリケーションまたはサービスによって形成され得るため、Ｐ２ＰＮＷ ＩＤは、アプリケーション特定のＰ２ＰＮＷを定義および区別するために使用され得るネットワーク識別子であり得る。近接サービスの分散される性質に起因して、Ｐ２ＰＮＷ ＩＤは、局所的に一意であり得る。

Ｐ２ＰＮＷ ＩＤは、限定ではないが、所望のサービスまたはアプリケーション（例えば、ソーシャルネットワークのＦａｃｅｂｏｏｋ、ビデオストリーミングのＮｅｔｆｌｉｘ等）を示すＣＡＩＤまたはアプリケーションＩＤ、Ｐ２ＰＮＷの場所を示す場所情報、Ｐ２ＰＮＷ ＩＤを生成したピアのＩＤ、および同じコンテキスト情報を伴う既存のＰ２ＰＮＷを区別するために使用され得るネットワークシーケンス番号を含み得る。Ｐ２ＰＮＷ ＩＤは、情報の各ピースにいくつかの情報ビットが割り当てられ、全ての情報ピースが連結される連結構造、または全ての情報のピースが、ＸＯＲおよびハッシュ等、いくつかの数学的計算を通して合計される並列構造等、異なる構造を使用して生成され得る。

異なる制御スキームに基づいて、Ｐ２ＰＮＷ ＩＤは、ネットワーク内の異なるパーティによって生成および割り当てられ得る。集中型制御スキームの実施形態では、Ｐ２ＰＮＷ ＩＤは、次いで、ＶＬに通知するスーパーＶＬによって生成され得るか、またはＶＬが、Ｐ２ＰＮＷ ＩＤを生成し、ビーコン内でそれをブロードキャストし、スーパーＶＬおよび他のＶＬに通知し得る。ハイブリッド制御スキームの実施形態では、ＶＬは、Ｐ２ＰＮＷ ＩＤを生成し、ビーコン内でそれをブロードキャストし、他のＶＬに通知し得る。分散型制御スキームの実施形態では、Ｐ２ＰＮＷを形成することを所望するピア（すなわち、新しいアプリケーションフレームを定義するピア）は、Ｐ２ＰＮＷ ＩＤを生成し、ビーコンをブロードキャストし、Ｐ２ＰＮＷ ＩＤの近接範囲内の全ピアに通知し得る。

依然として図８Ａを参照すると、補助フィールドのフィールド８１６は、随意ではあるが、いくつかの機能性に対しては重要であるフィールドを含み得る。例えば、緊急事態サービス、ソーシャルネットワーク、スマートオフィス等、アプリケーションまたはサービスカテゴリを示すコンテキストカテゴリフィールドが含まれ得る。別の実施例として、フレーム送信側が、マルチホップ発見プロセスのために他のフレームを中継する用意があるかどうかを示すホッパ指示フィールドが含まれ得る。

図９Ａは、例示的ビーコンフレーム形式８３０を例証する。ビーコンフレームは、Ｐ２ＰＮＷを形成し、Ｐ２Ｐ通信を有効化する際に、重要な役割を果たし得る。発見手順のためにコンテキスト情報を伝え、チャネル管理プロセスを通して新しいスーパーフレームおよび／またはアプリケーションフレームを定義し、同期のためにフレーム／スロットの境界を決定し、電力制御手順を促進するために使用され得る。

ビーコンフレームは、発見のために使用され得、Ｐ２ＰＮＷ情報だけではなく、コンテキスト情報も伝え得る。ビーコンフレームのためのサブタイプフィールドは、表１に示されるように、２つの部分に分割され得る。ビーコンサブタイプは、具体的ビーコンフレームタイプを定義し得、「発見に関して」のビットは、ビーコンホルダが、発見のために要求されるコンテキスト情報を提供することによって発見されることを所望する場合、「１」に設定され得る。本ビットは、ビーコンホルダが発見されることを所望しない場合、「０」に設定され得る。いくつかのビーコンは、スーパーフレームおよびアプリケーションフレームの両方を定義するが、いくつかは、アプリケーションフレームのみを定義する。

前述の表１は、ビーコンフレーム８３０のためのフレーム制御フィールドのフレームタイプおよびサブタイプフィールドの有効な組み合わせを定義する。ビーコンフレームの各タイプは、制御スキームおよびビーコン送信側の役割（すなわち、スーパーＶＬ／ＶＬ／ピア）に、一意的にマッピングされ得る。ビーコンフレームは、いずれのＡＣＫも要求しない。ビーコンメッセージが、１つ以上のＩＥを伝える場合、ＩＥ現フィールドは、真として設定され、そうでなければ偽として設定され得る。ビーコンが中継されるかどうかに応じて、アドレッシングフィールド指示（図示せず）およびアドレッシングフィールド８３２は、対応して構成される。Ｐ２ＰＮＷ ＩＤフィールド８３４は、ビーコン内で伝えられ得る。コンテキストカテゴリフィールド８３６は、発見および／または同期手順のためのコンテキストを提供するために含まれ得る。ビーコンが発見のために送信される場合、ホッパ指示フィールド８３８が、存在するはずである。

ビーコンペイロードに関して、依然として図９Ａを参照すると、フレーム情報フィールド８４０は、ビーコンペイロードの一部であり得、スーパーフレーム情報およびアプリケーションフレーム情報の、２つの構成要素から成り得る。表１に見られるように、スーパービーコンは、スーパーフレーム情報およびアプリケーションフレーム情報の両方を伝え得る。集中型またはハイブリッド制御下のアプリケーションビーコンは、アプリケーションフレーム情報のみを伝え得る。ハイブリッド制御下の共通アプリケーションビーコンは、スーパーフレーム情報およびアプリケーションフレーム情報の両方を含み得る。分散型制御下のピアビーコンは、発見のためのコンテキスト情報を伝え得る。分散型制御下の共通ピアビーコンは、スーパーフレーム情報およびアプリケーションフレーム情報の両方を含み得る。最後に、分散型制御下の専用ピアビーコンは、アプリケーションフレーム情報のみを伝え得る。

図９Ｂは、ビーコンのフレーム情報フィールド８４０内で提供され得るスーパーフレーム情報８４０ａのための例示的形式を示す。スーパーフレーム情報を伝えるビーコンはまた、新しいスーパーフレームの開始を定義し得る。図９Ｂに示されるように、スーパーフレームの長さは、常に、ビーコン間隔と等しくあり得、したがって、スーパーフレーム情報内にビーコン間隔フィールドは存在しない。ＣＣＤＣＨスロット８４２の数は、ＣＣＤＣＨによって提供されるタイムスロットの数を示し得、これは、ビーコンフレームに従う。ＣＣＤＣＨスロットサイズ８４４は、各ＣＣＤＣＨスロットのスロットサイズを定義し得る。アプリケーションフレームリスト８４６は、現在のスーパーフレーム内に含まれるアプリケーションフレームを説明するためのアイテムのリストを含み得、それらの各々は、スーパーフレーム内にある時間期間を与えられている。アプリケーションフレームリスト内の各アイテムは、異なるアプリケーションフレームを説明し、アプリケーション情報およびアプリケーションフレームオフセットから成り得る。アプリケーションフレームオフセットは、アプリケーションフレームの開始点と、スーパーフレーム内の開始点等のある時間基準との間の時間オフセットを示し得る。このフィールドは、同期を目的として使用され得る。

図９Ｃは、ビーコンのフレーム情報フィールド８４０内で提供され得るアプリケーションフレーム情報８４０ｂのための例示的形式を例証する。アプリケーションフレーム長さ８４８は、新しいアプリケーションフレームの総長を示し得る。ＤＣＤＣＨスロット８５０の数は、ＤＣＤＣＨ内に含まれるタイムスロットの数を示し得、これは、ビーコンフレームに従う。ＤＣＤＣＨおよびＣＦＰは、同じスロットサイズを有し得、これは、スロットサイズフィールド内に定義される。スーパー／共通ビーコンオフセットフィールド８５２は、時間オフセットの観点から、スーパービーコンまたは共通ビーコンがどこに位置するかを示し得る。このフィールドは、同期を目的として使用され得る。

図９Ａのビーコンフレーム形式８３０を再び参照すると、他のビーコンペイロードフィールドは、１つ以上の高い層からの情報を含み得る。

関連付け関連手順は、Ｐ２ＰＮＷを形成および更新する際に、重要な役割を果たし得る。関連付け、分離、再関連付け、および関連付け更新手順のために設計される種々のフレーム形式が、本明細書にて熟慮される。図１０Ａは、ＭＡＣペイロード部分内の全ての列挙されるフィールドが必須であり得る、関連付け要求フレーム８６０の形式を例証する。フレームタイプおよびサブタイプは、表２に示されるように構成され、これが関連付け要求フレームであることを示し得る。長いアドレスまたは完全なアドレスが、関連付け要求フレーム内で使用され得る。関連付け要求フレームは、どんなＡＣＫも要求しない。代わりに、関連付け応答が、関連付け要求への返信として要求され得る。関連付け要求メッセージが、１つ以上のＩＥを伝える場合、ＩＥ現フィールドは、真として設定され、そうでなければ偽として設定されるべきである。関連付け要求が中継されるかどうかに応じて、アドレッシングフィールド指示およびアドレッシングフィールド（図示せず）は、それに応じて、本明細書に説明されるように構成される。Ｐ２ＰＮＷ ＩＤは、関連付け要求内で伝えられ得る。

関連付け要求フレーム８６０のＭＡＣペイロードに関して、デバイス能力８６２は、要求を送信するピアの異なるタイプの能力であり得る。例えば、このフィールドは、送信するピアの伝送データレート能力、バッテリ／電力消費能力、および／またはセキュリティ能力のうちの１つ以上のインジケータを含み得る。ＩＥＥＥ ８０２．１５．８では、Ｐ２ＰＮＷは、所望のアプリケーションによって形成される。関連付けは、デバイスベース、サービスベース、および／またはユーザベースの関連付けとして分類され得る。ピアは、複数のアプリケーションを維持し得、したがって、複数の異なるタイプの関連付け接続を維持し得る。関連付けタイプフィールド８６４は、確立されることが予期される関連付けのタイプを示し得る。特定のアプリケーションに従って、サービスベースまたはユーザベースの関連付けが確立され得るが、マルチホップのシナリオにおいては、デバイスベースの関連付けが、より一般的に使用され得る。

関連付け要求フレーム８６０の要求持続時間フィールド８６６は、要求側によって設定され、関連付け接続がアクティブであることが予期される時間の長さを示し得る。ＶＬ指示フィールド８６８は、要求の送信側がＶＬであるかどうかを示し得る。応答タイプフィールド８７０は、対応する関連付け応答メッセージの一部として他のＭＡＣペイロードフィールド内に要求され得る、随意のフィールドを示すために使用され得る。マルチホップ指示フィールド８７２は、関連付け要求が、受信側のワンホップ範囲外のピアに対して中継されるかどうかを示し得る（すなわち、マルチホップ関連付け）。関連付け要求フレーム８６０の他のＭＡＣペイロード部分では、随意のフィールドが、含まれ得、その実施例が、以下の表６に示される。

図１０Ｂは、例示的関連付け応答フレーム８８０を例証する。フレーム８８０のヘッダ内では、フレームタイプおよびサブタイプは、表２に示されるように構成され、これが関連付け応答フレームであることを示し得る。長いアドレスまたは完全なアドレスが、関連付け応答フレーム８８０内で使用され得る。関連付け応答フレームは、どんなＡＣＫも要求しない。関連付け応答メッセージが１つ以上のＩＥを伝える場合、ＩＥ現フィールドは、真として設定され、そうでなければ偽として設定され得る。関連付け応答が中継されるかどうかに応じて、フレーム８８０のヘッダのアドレッシングフィールド指示およびアドレッシングフィールドは、それに応じて構成され得る。Ｐ２ＰＮＷ ＩＤは、関連付け応答内で伝えられ得る。コンテキストカテゴリまたはホッパ指示フィールドは、いずれも関連付け応答メッセージ内で使用されないこともある。

関連付け応答フレーム８８０のＭＡＣペイロードに関して、応答側のデバイス能力８８２、関連付けタイプ８８４、ＶＬ指示８９２、およびマルチホップ指示８９４のフィールドは、関連付け要求メッセージに関して本明細書に説明されるものと同じ使用法を有し得る（例えば、図１０Ａおよび関連付けられた文章を参照）。関連付けＩＤ８８８は、２つのピア間の関連付けを識別する識別子であり得る。ある実施形態では、関連付けＩＤは、Ｐ２ＰＮＷ ＩＤの生成と同様に生成され得る。関連付け決定フィールド８８６は、関連付け要求が容認されるかどうかを示し得る。本文脈では、「容認」は、関連付け要求における全てのパラメータが容認されることを意味し得ることに留意されたい。

割り当て持続時間フィールド８９０は、確立される関連付けの存続期間を示し得る。応答側は、関連付け要求内の要求持続時間に基づいて存続期間を決定する。これは、関連付け要求の要求持続時間とは異なる値であり得る。割り当てられた短いアドレスは、要求される短いアドレスのフィールドが、要求メッセージ内で真と設定される場合、短いアドレスを含み得る。関連付け要求内の応答タイプに基づいて、関連付け応答は、要求の他のＭＡＣペイロード部分内に規定される、要求される情報を含み得る。表６に示されるフィールドに加えて、追加的かつ代替的なフィールドが、応答メッセージ内に含まれ得、その実施例が、以下の表７に例証される。

再関連付け要求フレームは、本明細書に説明されるように、関連付け要求の構造と非常に類似する構造を有し得る。２つの構造間の主要な差異は、再関連付け要求が、ＭＡＣペイロード内に必須の関連付けＩＤフィールドを含み得ることであり得る。

図１０Ｃは、例示的分離要求フレーム９００を例証する。フレーム９００では、マルチホップ指示９０８、関連するピアの数９１０、およびマルチホップピアＩＤ９１２のフィールドは、関連付け要求フレーム内のものと同じであり得る（例えば、図１０Ａおよび関連付けられた文章を参照）。分離要求メッセージは、関連付けの他方の側に、関連付けがすぐに終了されるであろうことを通知するために送信され得る。ヘッダのフレーム制御フィールド内で要求されるＡＣＫタイプは、分離応答メッセージが要求されるかどうかを示し得る。分離理由フィールド９０４は、分離がシャットダウンされる予定である理由を示し得る。ある実施形態では、可能な理由は、リンク失敗、アプリケーション終了、およびリソース制限を含み得る。分離持続時間フィールド９０６は、分離の持続時間を示し得る。これは、持続時間の後、関連付けがアクティブとなるであろうことを示すことによって、関連付けを一時的に中断または終了するために使用され得る。

図１０Ｄは、分離要求の受信後、関連付けが切断されることを確認するために使用され得る、例示的分離応答フレーム９１４を例証する。いくつかの場合では、分離要求メッセージを受信するピアは、分離応答を送信する必要がない。これは、ヘッダのフレーム制御フィールド内に要求されるＡＣＫタイプの構成に依存し得る。フレーム９１４の分離状態フィールド９１８は、関連付けが永続的に切断されることを示し得る。代替として、分離状態フィールド９１８は、関連付けが、ある時間期間の間、一時的に切断されることを示し得、これはさらに、関連付けが時間期間の満了に応じてアクティブ化されるであろうことを示す。

図１０Ｅは、他方の側に、既存の関連付けの１つ以上の属性が、更新されるべきであること、または更新されていることを通知するために使用され得る、例示的関連付け更新通知フレーム９２０を例証する。このフレームでは、更新関連付け情報フィールド９２４は、更新する必要がある既存の関連付けについての情報を伴う、１つ以上の情報フィールドを含み得る。関連付け要求フレームおよび応答フレーム内の必須または随意のいずれのフィールドも、更新関連付け情報フィールド内に含まれ得る。

図１０Ｆは、関連付け更新通知フレームによって書き留められている関連付け属性の更新を確認するために使用され得る、例示的関連付け更新応答フレーム９２６を例証する。このフレームの更新状態フィールド９３０は、全ての要求された更新関連付け情報が、更新されるかどうかを示す。このフィールドのコンテンツは、そのような情報が、完全に更新されるか、部分的に更新されるか、または全て拒絶されるかを示し得る。更新関連付け情報フィールド９３２は、更新されていない関連付け更新通知フレーム内の要求更新関連付け情報と、更新されることが関連付け更新応答の送信側によって要求される関連付け情報との２つの関連付け情報のうちの一方または両方を含み得る。

チャネル管理は、近接で、スーパーフレーム構造およびチャネルアクセスを定義する。スーパーフレームは、ＣＣＤＣＨおよび１つ以上のアプリケーションフレームから成り得、アプリケーションフレームの各々はさらに、ＤＣＤＣＨおよびコンテンションフリー期間に分かれ得る。チャネル管理フレームは、表２に示されるように、ＣＣＤＣＨ要求、ＣＣＤＣＨ応答、ＤＣＤＣＨ要求、およびＤＣＤＣＨ応答フレームに分類され得る。全てのこれらのフレームは、チャネルリソースに対して競合し、それを分配するために使用され得る。

図１１Ａは、無線リソースの分配のために、近接で、ＣＣＤＣＨ上で要求をブロードキャストするために使用され得る、例示的Ｐ２ＰＮＷ間チャネル分配要求フレーム９４０を例証する。このフレームのＶＬ指示フィールド９４２は、送信側がＶＬであるかどうかを示し得る。分散型制御スキームの実施形態では、このフィールドは、常に、偽である。所望アプリケーションフレーム長フィールド９４４は、送信側が構築を試みるアプリケーションフレームの所望持続時間を示し得る。スーパーＶＬ用意フィールド９４６は、送信側がスーパーＶＬとして作用する用意があるかどうかを示し得る。このフィールドは、必須であり得る。所望アプリケーションビーコン場所フィールド９４８は、アプリケーションビーコンがブロードキャストされるときを示す、随意のフィールドであり得る。このフィールドは、送信側がスーパーフレーム構造の知識を有し、すでにＰ２ＰＮＷと同期しているときのみ存在し得る。

図１１Ｂは、Ｐ２ＰＮＷ間チャネル分配要求フレーム９４０の後にＣＣＤＣＨ上で送信され得る、例示的Ｐ２ＰＮＷ間チャネル分配応答フレーム９５０を例証する。このフレーム内のスーパーＶＬ指示フィールド９５２は、応答がスーパーＶＬから送信されるかどうかを示し得る。ハイブリッドおよび分散型制御スキームの実施形態では、このフィールドは、常に、偽であり得る。応答決定フィールド９５４は、対応するＰ２ＰＮＷ間チャネル分配要求が容認されるかどうかを示し得る。拒絶理由フィールド９５６は、要求が拒絶される理由を示すために使用され得る。例えば、要求される時間期間は、アプリケーションフレームに分配されている時間期間と全体的または部分的に重なり得る。調節提案フィールド９５８は、利用可能な時間期間の提案を含み得る随意のフィールドであり得る。調節提案は、応答がスーパーＶＬからである場合、より高い優先順位が与えられ得る。

図１１Ｃは、ＤＣＤＣＨを経由して送信され、アプリケーションフレーム内で１つ以上のタイムスロットを要求するために使用され得る、例示的Ｐ２ＰＮＷ内チャネル分配要求フレーム９６０を例証する。ある実施形態では、フレーム９６０の送信側は、Ｐ２ＰＮＷ内チャネル分配要求をブロードキャストするとき、アプリケーションフレーム規格を知り得る。サブＶＬ指示フィールド９６２は、要求側がサブＶＬまたはピアであることを示し得る。分散型制御スキームの実施形態では、このフィールドは、常に、ピアとしてセットアップされる。所望スロットフィールド数９６４は、送信側が要求するタイムスロットの数を示し得る。スロットサイズは、アプリケーションフレーム全体の間、固定され得、ピアは、伝送のためのスロットの数を要求することのみが許可され得る。所望スロット場所フィールド９６６は、アプリケーションフレーム内の所望のタイムスロットの位置を示す随意のフィールドであり得る。

図１１Ｄは、Ｐ２ＰＮＷ内チャネル分配要求に返信として送信され得る、例示的Ｐ２ＰＮＷ内チャネル分配応答メッセージ９７０を例証する。このフレームのＶＬ指示フィールド９７２は、応答メッセージがＶＬによって送信されるかどうかを示す。分散型制御スキームの実施形態では、このフィールドは、常に、偽である。応答決定９７４、拒絶理由９７４、および調節提案９７８のフィールドは、Ｐ２ＰＮＷ間チャネル分配応答フレーム内で使用されるフィールドのものと同じ使用法を有し得る（例えば、図１１Ｂおよび関連付けられた文章を参照）。

前述のように、電力制御要求フレーム（例えば、フレームタイプ＝１；フレームサブタイプ＝８）は、近接範囲内のコンテキストおよび電力制御情報を要求するために使用され得る。表８は、一実施形態による、電力制御要求フレームのＭＡＣペイロード（例えば、フレーム形式８００のＭＡＣペイロード８０４のフレームペイロードフィールド８２２）内に提供され得るいくつかの例示的かつ追加のフィールドを列挙する。一実施形態では、表８内の情報は、近接範囲内で１度だけ交換され得る。本情報のいずれかが変更されるときのみ、情報交換のために電力制御要求にそれが含まれるであろう。サービス電力カテゴリ、伝送電力、および受信信号品質等、他の電力制御関連情報は、さらに以下で説明されるように、１つ以上のＣＰＣＩ ＩＥに含まれ得る。

一実施形態では、電力制御応答は、ピアが電力制御要求メッセージを受信すると、送信され得る。前述のように、電力制御応答メッセージは、電力制御要求を受信するピアの電力制御情報を要求側に提供し得る。電力制御応答メッセージ内に含まれる情報は、電力制御要求内に提供される情報に類似する。

情報要素（ＩＥ）は、効率的なメッセージ交換のために情報をカプセル化するための柔軟で、拡張可能、かつ容易に実装可能な方法を提供し得る。ＩＥは、ＭＡＣヘッダまたはＭＡＣペイロードのいずれかの部分であり得る。図８Ａに例証される例示的フレーム形式８００では、フィールド８２０が、ＩＥを保持するために提供される。複数のＩＥが、１つのフレーム内で連結され得る。

ある実施形態では、コンテキスト情報ＩＥは、フレームを送信するピアのコンテキスト情報を伝え得る。Ｐ２ＰＮＷは、コンテキスト情報に基づいて編成および管理され得るため、コンテキスト情報ＩＥは、より高い重要性を持ち得、ＭＡＣヘッダ内のヘッダＩＥとして取り扱われ得る。一実施形態による、コンテキスト情報ＩＥの実施例は、以下の表９に提供される。

以下の表１０は、電力制御要求または応答フレーム内でＣＰＣＩを伝えるためのＩＥの例示的フィールドを列挙する。

他の実施形態では、コンテキスト情報およびＣＰＣＩ情報は、図８Ａに例証されるものに類似する新しいまたは修正されたフィールドを有する、８０２．１５または８０２．１１ビーコンフレーム内で伝えられ得る。

図１２Ａは、１つ以上の開示された実施形態が実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）、モノのインターネット（ＩｏＴ）、またはモノのウェブ（ＷｏＴ）通信システム１０の略図である。例えば、図１−７を参照して説明されるコンテキストマネージャは、以下にさらに説明されるように、図１２Ａに描写される種々のデバイス上に常駐し得る。概して、Ｍ２Ｍ技術は、ＩｏＴ／ＷｏＴのための構成要素を提供し、任意のＭ２Ｍデバイス、ゲートウェイ、またはサービスプラットフォームは、ＩｏＴ／ＷｏＴの構成要素ならびにＩｏＴ／ＷｏＴサービス層等であり得る。

図１２Ａに示されるように、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０は、通信ネットワーク１２を含む。通信ネットワーク１２は、固定ネットワーク（例えば、イーサネット（登録商標）、ファイバ、ＩＳＤＮ、ＰＬＣ等）または無線ネットワーク（例えば、ＷＬＡＮ、セルラー等）、あるいは異種ネットワークのネットワークであり得る。例えば、通信ネットワーク１２は、音声、データ、ビデオ、メッセージング、ブロードキャスト等のコンテンツを複数のユーザに提供する、複数のアクセスネットワークから成り得る。例えば、通信ネットワーク１２は、符号分割多重アクセス（ＣＤＭＡ）、時分割多重アクセス（ＴＤＭＡ）、周波数分割多重アクセス（ＦＤＭＡ）、直交ＦＤＭＡ（ＯＦＤＭＡ）、単一キャリアＦＤＭＡ（ＳＣ−ＦＤＭＡ）等の１つ以上のチャネルアクセス方法を採用し得る。さらに、通信ネットワーク１２は、例えば、コアネットワーク、インターネット、センサネットワーク、工業制御ネットワーク、パーソナルエリアネットワーク、融合個人ネットワーク、衛星ネットワーク、ホームネットワーク、または企業ネットワーク等の他のネットワークを備え得る。

図１２Ａに示されるように、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０は、インフラストラクチャドメインおよびフィールドドメインを含み得る。インフラストラクチャドメインは、エンドツーエンドＭ２Ｍ展開のネットワーク側を指し、フィールドドメインは、通常はＭ２Ｍゲートウェイの背後にある、エリアネットワークを指す。フィールドドメインは、Ｍ２Ｍゲートウェイ１４と、端末デバイス１８とを含む。任意の数のＭ２Ｍゲートウェイデバイス１４およびＭ２Ｍ端末デバイス１８が、所望に応じてＭ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０に含まれ得ることが理解されるであろう。ゲートウェイデバイス１４または端末デバイス１８は、前述の実施形態による、コンテキスト情報管理を実施するシステム内のピアデバイスとして構成され得る。ゲートウェイデバイス１４および／または端末デバイス１８は、ピアデバイス１０２として構成され得、したがって、ゲートウェイデバイス１４および端末デバイス１８の各々は、コンテキストマネージャ１０４を含み得る。さらに、ゲートウェイデバイス１４および／または端末デバイス１８の各々は、例えば、ＣＭＰ２０２等のコンテキストマネージャプロキシを含み得る。Ｍ２Ｍゲートウェイデバイス１４およびＭ２Ｍ端末デバイス１８の各々は、通信ネットワーク１２または直接無線リンクを介して、信号を伝送および受信するように構成される。Ｍ２Ｍゲートウェイデバイス１４は、無線Ｍ２Ｍデバイス（例えば、セルラーおよび非セルラー）ならびに固定ネットワークＭ２Ｍデバイス（例えば、ＰＬＣ）が、通信ネットワーク１２等のオペレータネットワークを通して、または直接無線リンクを通してのいずれかで、通信することを可能にする。例えば、Ｍ２Ｍデバイス１８は、データを収集し、通信ネットワーク１２または直接無線リンクを介して、データをＭ２Ｍアプリケーション２０またはＭ２Ｍデバイス１８に送信し得る。Ｍ２Ｍデバイス１８はまた、Ｍ２Ｍアプリケーション２０またはＭ２Ｍデバイス１８からデータを受信し得る。さらに、データおよび信号は、以下で説明されるように、Ｍ２Ｍサービス層２２を介して、Ｍ２Ｍアプリケーション２０に送信され、そこから受信され得る。Ｍ２Ｍデバイス１８およびゲートウェイ１４は、例えば、セルラー、ＷＬＡＮ、ＷＰＡＮ（例えば、Ｚｉｇｂｅｅ（登録商標）、６ＬｏＷＰＡＮ、Ｂｌｕｅｔｏｏｔｈ（登録商標））、直接無線リンク、および有線を含む、種々のネットワークを介して通信し得る。端末デバイス１８およびゲートウェイデバイス１４は、前述のように、コンテキスト管理メッセージを交換するために、種々のネットワークを介して通信し得る。例えば、前述のピアツーピア通信は、直接複数の端末デバイス１８間で、直接複数のゲートウェイデバイス１４間で、または直接端末デバイス１８とゲートウェイデバイス１４との間で発生し得る。

また、図１２Ｂを参照すると、フィールドドメイン内の図示したＭ２Ｍサービス層２２は、Ｍ２Ｍアプリケーション２０、Ｍ２Ｍゲートウェイデバイス１４、Ｍ２Ｍ端末デバイス１８、および通信ネットワーク１２のためのサービスを提供する。Ｍ２Ｍサービスプラットフォーム２２は、所望に応じて、任意の数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイデバイス１４、Ｍ２Ｍ端末デバイス１８、および通信ネットワーク１２と通信し得ることが理解されるであろう。Ｍ２Ｍサービス層２２は、１つ以上のサーバ、コンピュータ等によって実装され得る。Ｍ２Ｍサービス層２２は、Ｍ２Ｍ端末デバイス１８、Ｍ２Ｍゲートウェイデバイス１４、およびＭ２Ｍアプリケーション２０に適用される、サービス能力を提供する。Ｍ２Ｍサービス層２２の機能は、例えば、ウェブサーバとして、セルラーコアネットワークで、クラウドで等、種々の方法で実装され得る。

図示したＭ２Ｍサービス層２２と同様に、インフラストラクチャドメイン内にＭ２Ｍサービス層２２’が常駐する。Ｍ２Ｍサービス層２２’は、インフラストラクチャドメイン内のＭ２Ｍアプリケーション２０’および下層通信ネットワーク１２’のためのサービスを提供する。Ｍ２Ｍサービス層２２’はまた、フィールドドメイン内のＭ２Ｍゲートウェイデバイス１４およびＭ２Ｍ端末デバイス１８のためのサービスも提供する。Ｍ２Ｍサービス層２２’は、任意の数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイデバイス、およびＭ２Ｍ端末デバイスと通信し得ることが理解されるであろう。Ｍ２Ｍサービス層２２’は、異なるサービスプロバイダによるサービス層と相互作用し得る。Ｍ２Ｍサービス層２２’は、１つ以上のサーバ、コンピュータ、仮想マシン（例えば、クラウド／計算／記憶ファーム等）等によって実装され得る。

図１２Ｂも参照すると、Ｍ２Ｍサービス層２２および２２’は、多様なアプリケーションおよび垂直線が活用することができる、サービス配信能力のコアセットを提供する。これらのサービス能力は、Ｍ２Ｍアプリケーション２０および２０’がデバイスと相互作用し、データ収集、データ分析、デバイス管理、セキュリティ、課金、サービス／デバイス発見等の機能を果たすことを可能にする。本質的に、これらのサービス能力は、これらの機能性を実装する負担をアプリケーションから取り除き、したがって、アプリケーション開発を単純化し、市場に出す費用および時間を削減する。サービス層２２および２２’はまた、Ｍ２Ｍアプリケーション２０および２０’が、サービス層２２および２２’が提供するサービスと関連して、種々のネットワーク１２および１２’を通して通信することも可能にする。

本願のコンテキストマネージャは、サービス層の一部として実装され得る。 本明細書に使用されるように、サービス層は、アプリケーションプログラミングインターフェース（ＡＰＩ）および下層ネットワーキングインターフェースのセットを通して付加価値サービス能力をサポートする、ソフトウェアミドルウェア層を指し得る。ＥＴＳＩ Ｍ２ＭおよびｏｎｅＭ２Ｍの両方が、 本明細書に説明されるコンテキストマネージャを含み得るサービス層を使用する。ＥＴＳＩ Ｍ２Ｍのサービス層は、サービス能力層（ＳＣＬ）と称される。本明細書に説明される実施形態は、ＳＣＬの一部として実装され得、メッセージは、例えば、ＭＱＴＴまたはＡＭＱＰ等の種々のプロトコルに基づき得る。ＳＣＬは、（それがデバイスＳＣＬ（ＤＳＣＬ）と称される）Ｍ２Ｍデバイス、（それがゲートウェイＳＣＬ（ＧＳＣＬ）と称される）ゲートウェイ、および／または（それがネットワークＳＣＬ（ＮＳＣＬ）と称される）ネットワークノード内で実装され得る。ｏｎｅＭ２Ｍサービス層は、共通サービス機能（ＣＳＦ）（例えば、サービス能力）のセットをサポートする。ＣＦＳの１つ以上の特定のタイプのセットのインスタンス化は、共通サービスエンティティ（ＣＳＥ）と称され、ネットワークノードの異なるタイプ（例えば、インフラストラクチャ、中間ノード、特定用途向けノード）にホストすることができる。さらに、本明細書に説明されるコンテキストマネージャは、アクセスするためにサービス指向アーキテクチャ（ＳＯＡ）および／またはリソース指向アーキテクチャ（ＲＯＡ）を使用する、Ｍ２Ｍネットワークの一部として実装され得る。さらに、本願のコンテキストマネージャは、本願のコンテキストマネージャ等のサービスにアクセスするために、サービス指向アーキテクチャ（ＳＯＡ）および／またはリソース指向アーキテクチャ（ＲＯＡ）を使用する、Ｍ２Ｍネットワークの一部として実装することができる。

Ｍ２Ｍアプリケーション２０および２０’は、限定ではないが、輸送、健康およびウェルネス、コネクテッドホーム、エネルギー管理、資産追跡、ならびにセキュリティおよび監視等、種々の産業におけるアプリケーションを含み得る。前述のように、デバイス、ゲートウェイ、および他のシステムのサーバを横断して起動するＭ２Ｍサービス層は、例えば、データ収集、デバイス管理、セキュリティ、課金、場所追跡／ジオフェンシング、デバイス／サービスの発見、および従来のシステムの統合等の機能をサポートし、サービスとしてのこれらの機能に、Ｍ２Ｍアプリケーション２０および２０’を提供する。

図１２Ｃは、例えば、Ｍ２Ｍ端末デバイス１８またはＭ２Ｍゲートウェイデバイス１４等の例示的Ｍ２Ｍデバイス３０の系統図である。Ｍ２Ｍデバイス３０は、前述の実施形態による、例えば、プロキシベースのコンテキスト管理等、コンテキスト管理を実施するためのネットワークノードとして構成され得る。図１２Ｃに示されるように、Ｍ２Ｍデバイス３０は、プロセッサ３２と、送受信機３４と、伝送／受信要素３６と、スピーカ／マイクロホン３８と、キーパッド４０と、ディスプレイ／タッチパッド／インジケータ４２と、非取り外し可能メモリ４４と、取り外し可能メモリ４６と、電源４８と、全地球測位システム（ＧＰＳ）チップセット５０と、他の周辺機器５２とを含み得る。Ｍ２Ｍデバイス３０は、実施形態と一致したままで、先述の要素の任意の副次的組み合わせを含み得ることが理解されるであろう。ディスプレイ／タッチパッド／インジケータ４２は、概して、例示的実施形態によると、ユーザインタフェースと称され得る。コンテキスト管理インタフェースとも称され得るユーザインタフェースは、ユーザが、例えば、ゲートウェイまたは他のネットワークノード等、ピアデバイス上でのコンテキスト管理をモニタ、管理、および／または構成することを可能にし得る。例えば、ユーザインタフェースは、ユーザに、異なるピア間でのコンテキスト情報の交換および管理を構成またはトリガすることを可能にし得る。ユーザインタフェースは、前述のコンテキスト情報要求フレームまたはコンテキスト情報応答フレームを表示するように構成され得る。したがって、種々のコンテキストパラメータ（例えば、コンテキスト値、コンテキストＩＤ、残りの応答の数等）は、ディスプレイ／タッチパッド／インジケータ４２によって表示され得る。

プロセッサ３２は、汎用プロセッサ、特殊用途プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと関連する１つ以上のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、任意の他のタイプの集積回路（ＩＣ）、状態機械等であり得る。プロセッサ３２は、信号符号化、データ処理、電力制御、入出力処理、および／またはＭ２Ｍデバイス３０が無線環境で動作することを可能にする任意の他の機能性を果たし得る。プロセッサ３２は、伝送／受信要素３６に連結され得る、送受信機３４に連結され得る。図１２Ｃは、プロセッサ３２および送受信機３４を別個の構成要素として描写するが、プロセッサ３２および送受信機３４は、電子パッケージまたはチップに一緒に組み込まれ得ることが理解されるであろう。プロセッサ３２は、アプリケーション層プログラム（例えば、ブラウザ）および／または無線アクセス層（ＲＡＮ）プログラムおよび／または通信を行い得る。プロセッサ３２は、例えば、アクセス層および／またはアプリケーション層等で、認証、セキュリティキー一致、および／または暗号化動作等のセキュリティ動作を行い得る。

伝送／受信要素３６は、信号をＭ２Ｍサービスプラットフォーム２２に伝送し、またはＭ２Ｍサービスプラットフォーム２２から信号を受信するように構成され得る。例えば、実施形態では、伝送／受信要素３６は、ＲＦ信号を伝送および／または受信するように構成されるアンテナであり得る。伝送／受信要素３６は、ＷＬＡＮ、ＷＰＡＮ、セルラー等の種々のネットワークおよび無線インターフェースをサポートし得る。実施形態では、伝送／受信要素３６は、例えば、ＩＲ、ＵＶ、または可視光信号を伝送および／または受信するように構成されるエミッタ／検出器であり得る。さらに別の実施形態では、伝送／受信要素３６は、ＲＦおよび光信号の両方を伝送および受信するように構成され得る。伝送／受信要素３６は、無線または有線信号の任意の組み合わせを伝送および／または受信するように構成され得ることが理解されるであろう。

加えて、伝送／受信要素３６は、単一の要素として図１２Ｃで描写されているが、Ｍ２Ｍデバイス３０は、任意の数の伝送／受信要素３６を含み得る。より具体的には、Ｍ２Ｍデバイス３０は、ＭＩＭＯ技術を採用し得る。したがって、実施形態では、Ｍ２Ｍデバイス３０は、無線信号を伝送および受信するための２つ以上の伝送／受信要素３６（例えば、複数のアンテナ）を含み得る。

送受信機３４は、伝送／受信要素３６によって伝送される信号を変調するように、および伝送／受信要素３６によって受信される信号を変調するように構成され得る。上記のように、Ｍ２Ｍデバイス３０は、マルチモード能力を有し得る。したがって、送受信機３４は、Ｍ２Ｍデバイス３０が、例えば、ＵＴＲＡおよびＩＥＥＥ８０２．１１等の複数のＲＡＴを介して通信することを可能にするための複数の送受信機を含み得る。

プロセッサ３２は、非取り外し可能メモリ４４および／または取り外し可能メモリ４６等の任意のタイプの好適なメモリから情報にアクセスし、そこにデータを記憶し得る。例えば、プロセッサ３２は、前述のように、非取り外し可能メモリ４４および／または取り外し可能メモリ４６に由来するコンテキスト情報を記憶し、これにアクセスし、コンテキスト情報要求を満足させるコンテキスト情報が存在するかどうかを決定し得る。非取り外し可能メモリ４４は、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、ハードディスク、または任意の他のタイプのメモリ記憶デバイスを含み得る。取り外し可能メモリ４６は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカード等を含み得る。他の実施形態では、プロセッサ３２は、サーバまたはホームコンピュータ上等のＭ２Ｍデバイス３０上に物理的に位置しないメモリから情報にアクセスし、そこにデータを記憶し得る。

プロセッサ３２は、電源４８から電力を受け取り得、Ｍ２Ｍデバイス３０内の他の構成要素への電力を分配および／または制御するように構成され得る。電源４８は、Ｍ２Ｍデバイス３０に電力供給するための任意の好適なデバイスであり得る。例えば、電源４８は、１つ以上の乾電池バッテリ（例えば、ニッケルカドミウム（ＮｉＣｄ）、ニッケル亜鉛（ＮｉＺｎ）、ニッケル水素（ＮｉＭＨ）、リチウムイオン（Ｌｉ−ｉｏｎ）等）、太陽電池、燃料電池等を含み得る。

プロセッサ３２はまた、Ｍ２Ｍデバイス３０の現在の場所に関する場所情報（例えば、経度および緯度）を提供するように構成される、ＧＰＳチップセット５０に連結され得る。Ｍ２Ｍデバイス３０は、実施形態と一致したままで、任意の公的な場所決定方法を介して場所情報を獲得し得ることが理解されるであろう。

プロセッサ３２はさらに、追加の特徴、機能性、および／または有線あるいは無線接続を提供する、１つ以上のソフトウェアおよび／またはハードウェアモジュールを含み得る、他の周辺機器５２に連結され得る。例えば、周辺機器５２は、加速度計、ｅ−コンパス、衛星送受信機、センサ、デジタルカメラ（写真またはビデオ用）、ユニバーサルシリアルバス（ＵＳＢ）ポート、振動デバイス、テレビ送受信機、ハンズフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（ＦＭ）ラジオユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザ等を含み得る。

図１２Ｄは、例えば、図８Ａおよび８ＢのＭ２Ｍサービスプラットフォーム２２が実装され得る、例示的なコンピュータシステム９０のブロック図である。コンピュータシステム９０は、コンピュータまたはサーバを備え得、主に、ソフトウェアの形態であり得るコンピュータ読み取り可能な命令によって制御され得、どこでも、またはどのような手段を用いても、そのようなソフトウェアが記憶あるいはアクセスされる。そのようなコンピュータ読み取り可能な命令は、コンピュータシステム９０を稼働させるように、中央処理装置（ＣＰＵ）９１内で実行され得る。多くの既知のワークステーション、サーバ、および周辺コンピュータでは、中央処理装置９１は、マイクロプロセッサと呼ばれる単一チップＣＰＵによって実装される。他の機械では、中央処理装置９１は、複数のプロセッサを備え得る。コプロセッサ８１は、追加の機能を果たすか、またはＣＰＵ９１を支援する、主要ＣＰＵ９１とは明確に異なる、随意的なプロセッサである。

動作時、ＣＰＵ９１は、命令をフェッチ、復号、および実行し、コンピュータの主要データ転送経路であるシステムバス８０を介して、情報を他のリソースへ、およびそこから転送する。そのようなシステムバスは、コンピュータシステム９０内の構成要素を接続し、データ交換のための媒体を定義する。システムバス８０は、典型的には、データを送信するためのデータライン、アドレスを送信するためのアドレスライン、ならびに割り込みを送信するため、およびシステムバスを動作するための制御ラインを含む。そのようなシステムバス８０の実施例は、ＰＣＩ（周辺構成要素相互接続）バスである。

システムバス８０に連結されているメモリデバイスは、ランダムアクセスメモリ（ＲＡＭ）８２および読み取り専用メモリ（ＲＯＭ）９３を含む。そのようなメモリは、情報が記憶されて取り出されることを可能にする回路を含む。ＲＯＭ９３は、概して、容易に修正することができない、記憶されたデータを含む。ＲＡＭ８２に記憶されたデータは、ＣＰＵ９１または他のハードウェアデバイスによって読み取られ、または変更され得る。ＲＡＭ８２および／またはＲＯＭ９３へのアクセスは、メモリコントローラ９２によって制御され得る。メモリコントローラ９２は、命令が実行されると、仮想アドレスを物理的アドレスに変換する、アドレス変換機能を提供し得る。メモリコントローラ９２はまた、システム内のプロセスを分離し、ユーザプロセスからシステムプロセスを分離する、メモリ保護機能を提供し得る。したがって、第１のモードで作動するプログラムは、独自のプロセス仮想アドレス空間によってマップされるメモリのみにアクセスすることができ、プロセス間のメモリ共有が設定されていない限り、別のプロセスの仮想アドレス空間内のメモリにアクセスすることができない。

加えて、コンピュータシステム９０は、ＣＰＵ９１からプリンタ９４、キーボード８４、マウス９５、およびディスクドライブ８５等の周辺機器に命令を伝達する責任がある、周辺機器コントローラ８３を含み得る。

ディスプレイコントローラ９６によって制御されるディスプレイ８６は、コンピュータシステム９０によって生成される視覚出力を表示するために使用される。そのような視覚出力は、テキスト、グラフィックス、動画グラフィックス、およびビデオを含み得る。ディスプレイ８６は、ＣＲＴベースのビデオディスプレイ、ＬＣＤベースのフラットパネルディスプレイ、ガスプラズマベースのフラットパネルディスプレイ、またはタッチパネルを伴って実装され得る。ディスプレイコントローラ９６は、ディスプレイ８６に送信されるビデオ信号を生成するために必要とされる、電子構成要素を含む。

さらに、コンピュータシステム９０は、図８Ａおよび８Ｂのネットワーク１２等の外部通信ネットワークにコンピュータシステム９０を接続するために使用され得る、ネットワークアダプタ９７を含み得る。

本明細書で説明されるシステム、方法、およびプロセスのうちのいずれかまたは全ては、命令が、コンピュータ、サーバ、Ｍ２Ｍ端末デバイス、Ｍ２Ｍゲートウェイデバイス等の機械によって実行されたときに、本明細書で説明されるシステム、方法、およびプロセスを行うおよび／または実装される、コンピュータ読み取り可能な記憶媒体上に記憶されたコンピュータ実行可能命令（すなわち、プログラムコード）の形態で具現化され得ることが理解される。具体的には、上記で説明されるステップ、動作、または機能のうちのいずれかは、そのようなコンピュータ実行可能命令の形態で実装され得る。コンピュータ読み取り可能な記憶媒体は、情報の記憶のための任意の方法または技術で実装される、揮発性および不揮発性、取り外し可能および非取り外し可能媒体の両方を含むが、そのようなコンピュータ読み取り可能な記憶媒体は、信号を含まない。コンピュータ読み取り可能な記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）または他の光学ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置または他の磁気記憶デバイス、あるいは所望の情報を記憶するために使用することができ、コンピュータによってアクセスすることができる任意の他の物理的媒体を含むが、それらに限定されない。

図で図示されるような本開示の主題の好ましい実施形態を説明する際に、明確にするために、特定の用語が採用される。しかしながら、請求された主題は、そのように選択された特定の用語に限定されることを目的としておらず、各特定の要素は、類似目的を達成するように同様に動作する、全ての技術的均等物を含むことを理解されたい。

本明細書は、最良の様態を含む、本発明を開示するために、また、当業者が、任意のデバイスまたはシステムを作製して使用すること、および任意の組み込まれた方法を行うことを含む、本発明を実践することを可能にするために、実施例を使用する。本発明の特許性のある範囲は、請求項によって定義され、当業者に想起される他の実施例を含み得る。そのような他の実施例は、請求項の文字通りの言葉とは異ならない構造要素を有する場合に、または請求項の文字通りの言葉とのごくわずかな差異を伴う同等の構造要素を含む場合に、請求項の範囲内であることを目的としている。

本概要は、発明を実施するための形態において以下でさらに説明される、簡略化形態の概念の選択を導入するように提供される。本概要は、請求された主題の主要な特徴または不可欠な特徴を識別することを目的としておらず、また、請求された主題の範囲を限定するために使用されることも目的としていない。さらに、請求された主題は、本開示の任意の部分で記述されるいずれかまたは全ての不利点を解決する制限に限定されない。
本発明はさらに、例えば、以下を提供する。
（項目１）
ピアツーピア通信を介して通信し、各々がそれぞれのコンテキストマネージャを含む複数のデバイスを備えているシステムにおいて、前記複数のデバイスのうちの第１のデバイスの第１のコンテキストマネージャで、
１つ以上のパラメータを備えているコンテキスト情報要求フレームを受信することであって、前記１つ以上のパラメータは、コンテキスト動作のリスト、コンテキスト識別のリスト、または応答タイプのうちの少なくとも１つを示す、ことと、
前記コンテキスト情報要求フレームに基づいて、１つ以上のコンテキスト情報応答フレームを生成することと
を含み、
前記１つ以上のコンテキスト情報応答フレームは、残りの応答の数、前記１つ以上のコンテキストフレームのうちの選択された１つに適用可能な肯定応答要件、前記１つ以上のコンテキストフレームのうちの前記選択された１つに適用可能な動作のリスト、前記１つ以上のコンテキストフレームのうちの前記選択された１つに適用可能なコンテキスト識別のリスト、または１つ以上のコンテキスト値のうちの少なくとも１つを示す、
方法。
（項目２）
前記コンテキスト情報要求フレームは、媒体アクセス制御（ＭＡＣ）層を経由して受信され、前記方法は、
前記ＭＡＣ層を経由して、前記１つ以上のコンテキストフレームのうちの前記選択された１つを前記複数のデバイスのうちの第２のデバイスの第２のコンテキストマネージャに送信することをさらに含む、項目１に記載の方法。
（項目３）
前記コンテキスト情報要求フレームは、前記第１のデバイスおよび前記第２のデバイスが、互に近接範囲内にあることに応答して受信される、項目２に記載の方法。
（項目４）
前記コンテキスト情報要求フレームは、前記第１のデバイスおよび前記第２のデバイスが、事前決定された場所に対して近接範囲内にあることに応答して受信される、項目２に記載の方法。
（項目５）
前記コンテキスト情報要求フレームは、コンテキストマネージャプロキシを介して受信される、項目１に記載の方法。
（項目６）
前記複数のデバイスのうちの第３のデバイスが、前記コンテキストマネージャプロキシを含む、項目１に記載の方法。
（項目７）
前記コンテキスト情報要求フレームまたは前記コンテキスト情報応答フレームのうちの少なくとも１つの状態を表示することをさらに含む、項目１に記載の方法。
（項目８）
接続されたピアデバイスのネットワーク内の第１のピアデバイスであって、前記第１のピアデバイスは、
コンピュータ読み取り可能な命令を実行するように適合されているプロセッサと、
前記プロセッサに通信可能に連結されているメモリと
を備え、
前記メモリは、コンピュータ読み取り可能な命令を記憶しており、前記命令は、前記プロセッサによって実行されると、
１つ以上のパラメータを備えているコンテキスト情報要求フレームを受信することであって、前記１つ以上のパラメータは、コンテキスト動作のリスト、コンテキスト識別のリスト、または応答タイプのうちの少なくとも１つを示す、ことと、
前記コンテキスト情報要求フレームに基づいて、１つ以上のコンテキスト情報応答フレームを生成することと
を含む動作を前記プロセッサに実施させ、
前記１つ以上のコンテキスト情報応答フレームは、残りの応答の数、１つ以上のコンテキストフレームのうちの選択された１つに適用可能な肯定応答要件、前記１つ以上のコンテキストフレームのうちの前記選択された１つに適用可能な動作のリスト、前記１つ以上のコンテキストフレームのうちの前記選択された１つに適用可能なコンテキスト識別のリスト、または１つ以上のコンテキスト値のうちの少なくとも１つを示す、
第１のピアデバイス。
（項目９）
前記コンテキスト情報要求フレームは、媒体アクセス制御（ＭＡＣ）層を経由して受信され、前記動作は、
前記ＭＡＣ層を経由して、前記１つ以上のコンテキストフレームのうちの前記選択された１つを前記接続されたピアデバイスのネットワーク内の第２のピアデバイスのコンテキストマネージャに送信することをさらに含む、項目８に記載の第１のピアデバイス。
（項目１０）
前記コンテキスト情報要求フレームは、前記第１のピアデバイスおよび前記第２のピアデバイスが、互に近接範囲内にあることに応答して受信される、項目９に記載の第１のピアデバイス。
（項目１１）
前記コンテキスト情報要求フレームは、前記第１のピアデバイスおよび前記第２のピアデバイスが、事前決定された場所に対して近接範囲内にあることに応答して受信される、項目１０に記載の第１のピアデバイス。
（項目１２）
前記コンテキスト情報要求フレームは、コンテキストマネージャプロキシを介して受信される、項目８に記載の第１のピアデバイス。
（項目１３）
前記接続されたピアデバイスのネットワーク内の第３のデバイスが、前記コンテキストマネージャプロキシを含む、項目１に記載の方法。
（項目１４）
前記動作は、前記コンテキスト情報要求フレームまたは前記コンテキスト情報応答フレームのうちの少なくとも１つの状態を表示することをさらに含む、項目７に記載の第１のデバイス。

Claims (14)

1. ピアツーピア通信を介して通信し、各々がそれぞれのコンテキストマネージャを含む複数のデバイスを備えているシステムにおいて、前記複数のデバイスのうちの第１のデバイスの第１のコンテキストマネージャで、
   １つ以上のパラメータを備えているコンテキスト情報要求フレームを受信することであって、前記１つ以上のパラメータは、コンテキスト動作のリスト、コンテキスト識別のリスト、または応答タイプのうちの少なくとも１つを示す、ことと、
   前記コンテキスト情報要求フレームに基づいて、１つ以上のコンテキスト情報応答フレームを生成することと
   を含み、
   前記１つ以上のコンテキスト情報応答フレームは、残りの応答の数、前記１つ以上のコンテキストフレームのうちの選択された１つに適用可能な肯定応答要件、前記１つ以上のコンテキストフレームのうちの前記選択された１つに適用可能な動作のリスト、前記１つ以上のコンテキストフレームのうちの前記選択された１つに適用可能なコンテキスト識別のリスト、または１つ以上のコンテキスト値のうちの少なくとも１つを示す、
   方法。
2. 前記コンテキスト情報要求フレームは、媒体アクセス制御（ＭＡＣ）層を経由して受信され、前記方法は、
   前記ＭＡＣ層を経由して、前記１つ以上のコンテキストフレームのうちの前記選択された１つを前記複数のデバイスのうちの第２のデバイスの第２のコンテキストマネージャに送信することをさらに含む、請求項１に記載の方法。
3. 前記コンテキスト情報要求フレームは、前記第１のデバイスおよび前記第２のデバイスが、互に近接範囲内にあることに応答して受信される、請求項２に記載の方法。
4. 前記コンテキスト情報要求フレームは、前記第１のデバイスおよび前記第２のデバイスが、事前決定された場所に対して近接範囲内にあることに応答して受信される、請求項２に記載の方法。
5. 前記コンテキスト情報要求フレームは、コンテキストマネージャプロキシを介して受信される、請求項１に記載の方法。
6. 前記複数のデバイスのうちの第３のデバイスが、前記コンテキストマネージャプロキシを含む、請求項１に記載の方法。
7. 前記コンテキスト情報要求フレームまたは前記コンテキスト情報応答フレームのうちの少なくとも１つの状態を表示することをさらに含む、請求項１に記載の方法。
8. 接続されたピアデバイスのネットワーク内の第１のピアデバイスであって、前記第１のピアデバイスは、
   コンピュータ読み取り可能な命令を実行するように適合されているプロセッサと、
   前記プロセッサに通信可能に連結されているメモリと
   を備え、
   前記メモリは、コンピュータ読み取り可能な命令を記憶しており、前記命令は、前記プロセッサによって実行されると、
   １つ以上のパラメータを備えているコンテキスト情報要求フレームを受信することであって、前記１つ以上のパラメータは、コンテキスト動作のリスト、コンテキスト識別のリスト、または応答タイプのうちの少なくとも１つを示す、ことと、
   前記コンテキスト情報要求フレームに基づいて、１つ以上のコンテキスト情報応答フレームを生成することと
   を含む動作を前記プロセッサに実施させ、
   前記１つ以上のコンテキスト情報応答フレームは、残りの応答の数、１つ以上のコンテキストフレームのうちの選択された１つに適用可能な肯定応答要件、前記１つ以上のコンテキストフレームのうちの前記選択された１つに適用可能な動作のリスト、前記１つ以上のコンテキストフレームのうちの前記選択された１つに適用可能なコンテキスト識別のリスト、または１つ以上のコンテキスト値のうちの少なくとも１つを示す、
   第１のピアデバイス。
9. 前記コンテキスト情報要求フレームは、媒体アクセス制御（ＭＡＣ）層を経由して受信され、前記動作は、
   前記ＭＡＣ層を経由して、前記１つ以上のコンテキストフレームのうちの前記選択された１つを前記接続されたピアデバイスのネットワーク内の第２のピアデバイスのコンテキストマネージャに送信することをさらに含む、請求項８に記載の第１のピアデバイス。
10. 前記コンテキスト情報要求フレームは、前記第１のピアデバイスおよび前記第２のピアデバイスが、互に近接範囲内にあることに応答して受信される、請求項９に記載の第１のピアデバイス。
11. 前記コンテキスト情報要求フレームは、前記第１のピアデバイスおよび前記第２のピアデバイスが、事前決定された場所に対して近接範囲内にあることに応答して受信される、請求項１０に記載の第１のピアデバイス。
12. 前記コンテキスト情報要求フレームは、コンテキストマネージャプロキシを介して受信される、請求項８に記載の第１のピアデバイス。
13. 前記接続されたピアデバイスのネットワーク内の第３のデバイスが、前記コンテキストマネージャプロキシを含む、請求項１に記載の方法。
14. 前記動作は、前記コンテキスト情報要求フレームまたは前記コンテキスト情報応答フレームのうちの少なくとも１つの状態を表示することをさらに含む、請求項７に記載の第１のデバイス。

Images