JP2018078589A - データ伝送のためのクロス層およびクロスアプリケーション肯定応答 - Google Patents

Abstract

【課題】データ伝送のためのクロス層およびクロスアプリケーション肯定応答の提供。
【解決手段】システムおよび方法は、アプリケーションレベルの肯定応答および媒体アクセス制御層肯定応答等、肯定応答を統合し得る。クロス層肯定応答方法のある実施形態では、媒体アクセス制御層肯定応答およびアプリケーション層肯定応答は、単一の媒体アクセス制御層肯定応答として統合され得る。クロスアプリケーションの肯定応答方法のある実施形態では、第１のアプリケーションのためのアプリケーション層肯定応答および第２のアプリケーションのためのアプリケーション層肯定応答は、単一の媒体アクセス制御層フレーム内に統合され得る。
【選択図】図１Ｂ

Description

（関連出願の引用）
本願は、米国仮特許出願第６１／８３７，７４６号（２０１３年６月２１日出願、名称「ＭＥＴＨＯＤＳ ＯＦ ＣＲＯＳＳ−ＬＡＹＥＲ ＡＮＤ ＣＲＯＳＳ−ＡＰＰＬＩＣＡＴＩＯＮ ＡＣＫＮＯＷＬＥＤＧＭＥＮＴ ＦＯＲ ＤＡＴＡ ＴＲＡＮＳＭＩＳＳＩＯＮ ＩＮ ＰＲＯＸＩＭＩＴＹ ＣＯＭＭＵＮＩＣＡＴＩＯＮＳ」）の利益を主張し、上記出願の内容は、参照により本明細書に引用される。

モノのインターネット（ＩｏＴ）は、ヒューマンツーヒューマン（Ｈ２Ｈ）に基づいたインターネットサービスに物体やモノを導入する。これは、サービスのインターネット（ＩｏＳ）を可能にするために、物理的または仮想的物体が相互接続されるインターネットの段階を示す。これらのサービスの多くは、とりわけ、スマートショッピング、スマートホーム、スマートオフィス、スマートヘルス、スマート輸送、スマートパーキング、スマートグリッド、およびスマートシティ等、近接ベースである。

近接サービスは、近接したピアツーピア（Ｐ２Ｐ）通信に基づき得る。Ｐ２Ｐデバイスは、とりわけ、タブレット、スマートフォン、音楽プレーヤ、ゲーム機、携帯情報端末、ラップトップ／ＰＣ、医療デバイス、コネクテッドカー、スマートメータ、センサ、ゲートウェイ、モニタ、アラーム、セットトップボックス、プリンタ、グーグルグラス、ドローン、およびサービスロボットを含む。Ｐ２Ｐ通信システムは、インフラストラクチャの役割を果たす、コントローラまたはコアネットワークを伴うセントラルシステム、あるいはインフラストラクチャの役割を果たす、コントローラまたはコアネットワークを伴わない分散型システムであり得る。近接サービスは、ヒューマンツーヒューマン（Ｈ２Ｈ）近接サービス、マシンツーマシン（Ｍ２Ｍ）近接サービス、マシンツーヒューマン（Ｍ２Ｈ）近接サービス、ヒューマンツーマシン（Ｈ２Ｍ）近接サービス、およびネットワーク近接サービスのネットワークを含み得る。

近接ベースのアプリケーションおよびサービスは、コアインフラストラクチャから重いローカルインターネットトラフィックをオフロードする傾向を示し、マルチホッピングを介してインフラストラクチャに接続を提供する。多くの規格は、３ＧＰＰ、ｏｎｅＭ２Ｍ、ＩＥＴＦ、ＩＥＥＥ、およびＯＭＡ等、それらの規格化作業グループの一部として近接サービスのユースケースを識別している。サービス層は、クロス層技法同様に、これらのサービスを可能にするための規格化領域である。

近接サービスは、ＩＥＥＥ ８０２．１５およびＩＥＥＥ ８０２．１１規格シリーズに規定されるように、信頼性のあるデータ伝送のためのさまざまな肯定応答（すなわち、ＡＣＫ）機構を有する無線ネットワークを使用し得る。

「ＩＥＥＥ ８０２．１５．４ｅ：ＩＥＥＥ ８０２．１５．４−２００６に関するＭＡＣ層拡張」ＡＣＫ情報要素（ＩＥ）は、コーディネータが、ギャランティードタイムスロット（ＧＴＳ）内で伝送される複数のデータフレームを肯定応答するために定義されている。グループＡＣＫは、再伝送のために新しいタイムスロットを分配する役割を果たす。ＡＣＫフレームは、ＩＥとして追加のコンテンツを含むことができる。マルチチャネル適応およびスイッチは、送信側および受信側の対が、それらの通信チャネルを切り替えるために定義される。

「低エネルギー志向インフラストラクチャネットワークのためのＰＨＹ／ＭＡＣ改正に関するＩＥＥＥ ８０２．１５．４ｋ」では、漸増的ＡＣＫ（ＩＡＣＫ）が、信頼性のあるＭＡＣフラグメント伝送を補助するために定義されている。各ＩＡＣＫは、正常に伝送されたフラグメントと失敗したフラグメントとの両方を示す。ＩＡＣＫは、ＡＣＫおよびＮＡＣＫの組み合わせとして説明されることができる。

ＩＥＴＦ制約アプリケーションプロトコル（ＣｏＡＰ）では、ＣｏＡＰプロトコル内にＡＣＫおよび再伝送が存在する。実質的には、ＣｏＡＰクライアントが、最初に、要求をＣｏＡＰサーバに送信する。次いで、ＣｏＡＰサーバは、要求が確認される必要がある場合、ＡＣＫをＣｏＡＰクライアントに返信する必要がある。加えて、ＣｏＡＰサーバはまた、ＡＣＫと一緒に応答をピギーバックすることもできる。そのようなＡＣＫおよび応答は、アプリケーションと関連するＣｏＡＰレベル機能であり、これらは、ＭＡＣ層ＡＣＫから完全に独立している。ＭＡＣ層ＡＣＫが存在するかどうかにかかわらず、ＣｏＡＰプロトコルは、：ＩＥＴＦ ＣｏＡＰに規定されるような、分離されたＣｏＡＰ ＡＣＫとＣｏＡＰ応答、またはピギーバックされたＣｏＡＰ ＡＣＫおよびＣｏＡＰ応答のような方法で機能するであろう。

前述のような信頼性のあるデータ伝送のための従来の肯定応答（例えば、ＡＣＫ）機構はさらに、最適化され得る。

従来のプロトコルにおけるＭＡＣ層肯定応答は、アプリケーション無関心またはアプリケーション独立である。本明細書に開示されるのは、アプリケーションレベルの肯定応答および媒体アクセス制御層肯定応答等、肯定応答を統合するシステムおよび方法である。ある実施形態では、統合された肯定応答は、媒体アクセス制御層肯定応答およびアプリケーション層肯定応答の両方の役割を果たすように活用される。別の実施形態では、統合された肯定応答は、同じＡＣＫフレーム内で複数のアプリケーションを肯定応答するために活用され得る。

本概要は、発明を実施するための形態において以下でさらに説明される、簡略化形態の概念の選択を導入するように提供される。本概要は、請求された主題の主要な特徴または不可欠な特徴を識別することを目的としておらず、また、請求された主題の範囲を制約するために使用されることも目的としていない。さらに、請求された主題は、本開示の任意の部分で記述されるいずれかまたは全ての不利点を解決する制限に限定されない。
本発明はさらに、例えば、以下を提供する。
（項目１）
デバイスであって、
プロセッサと、
前記プロセッサと通信可能に接続されるメモリと
を備え、
前記メモリは、実行可能な命令を記憶しており、前記命令は、前記プロセッサによって実行されると、
第１のフレームを受信することであって、前記第１のフレームは、第１の媒体アクセス制御データおよび第１のアプリケーションデータを備えている、ことと、
統合されたＡＣＫフレームを伝送する命令を提供することであって、前記統合されたＡＣＫフレームは、前記第１の媒体アクセス制御データの肯定応答と、前記第１のアプリケーションデータの肯定応答とを備えている、ことと
を含む動作を前記プロセッサに達成させる、デバイス。
（項目２）
前記統合されたＡＣＫフレームは、前記アプリケーションデータの肯定応答の利用可能性に対する閾値期間を待った後、伝送される、項目１に記載のデバイス。
（項目３）
前記アプリケーションは、トランスポート層、サービス層、アプリケーションプロトコル層、またはアプリケーション層のうちの少なくとも１つの中に常駐する、項目１に記載のデバイス。
（項目４）
前記統合されたＡＣＫフレームは、第２の媒体アクセス制御データおよび第２のアプリケーションデータをさらに備え、前記第２の媒体アクセス制御データおよび前記第２のアプリケーションデータは、第２のフレーム内で受信される、項目１に記載のデバイス。
（項目５）
前記第１のフレームは、前記デバイスに、前記統合されたＡＣＫフレームを送信するための命令を提供することを示すビットを備えている、項目１に記載のデバイス。
（項目６）
前記統合されたＡＣＫフレームは、前記統合されたＡＣＫフレーム内のアプリケーションＡＣＫの数を示すビットを備えている、項目１に記載のデバイス。
（項目７）
デバイスであって、
プロセッサと、
前記プロセッサと通信可能に接続されるメモリと
を備え、
前記メモリは、実行可能な命令を記憶しており、前記命令は、前記プロセッサによって実行されると、
第１のフレームを送信することであって、前記第１のフレームは、第１の媒体アクセス制御データおよび第１のアプリケーションデータを備えている、ことと、
統合されたＡＣＫフレームを受信することであって、前記統合されたＡＣＫフレームは、前記第１の媒体アクセス制御データの肯定応答と、前記第１のアプリケーションデータの肯定応答とを備えている、ことと、
を含む動作を前記プロセッサに達成させる、デバイス。
（項目８）
さらなる動作が、複数の肯定応答が統合されたＡＣＫフレーム内で許可されていることを示すビットを第１のフレームに対して設定することを含み、前記許可されている複数の肯定応答は、前記第１のアプリケーションデータの肯定応答を備え、ある肯定応答は、
前記第１の媒体アクセス制御データの肯定応答と、
第２の媒体アクセス制御データの肯定応答と、
第２のアプリケーションデータの肯定応答と
のうちの少なくとも１つを備えている、項目７に記載のデバイス。
（項目９）
さらなる動作が、前記統合されたＡＣＫフレームが設定されたビットを有していることを決定することを含み、前記ビットは、クロス層ＡＣＫまたはクロスアプリケーションＡＣＫが前記統合されたＡＣＫフレーム内で使用されていることを示す、項目７に記載のデバイス。
（項目１０）
さらなる動作が、前記デバイスのＭＡＣ層によって、より高い層に前記第１のアプリケーションデータの肯定応答を転送することを含み、前記転送することは、関連付けられているアプリケーション識別子に基づく、項目９に記載のデバイス。
（項目１１）
前記統合されたＡＣＫフレームは、第２のアプリケーションデータの肯定応答をさらに備え、前記第２のアプリケーションデータの肯定応答は、前記第１のアプリケーションデータとは異なるアプリケーションからである、項目７に記載のデバイス。
（項目１２）
前記第１のフレームは、前記統合されたＡＣＫフレーム内で許可されているアプリケーションＡＣＫの最大数を示すビットを備えている、項目７に記載のデバイス。
（項目１３）
前記デバイスは、中継装置である、項目７に記載のデバイス。
（項目１４）
前記第１のフレームは、前記デバイスと無線近接通信する受信デバイスに送信される、項目７に記載のデバイス。
（項目１５）
前記受信デバイスは、前記デバイスから１ホップ以内にある、項目１４に記載のデバイス。
（項目１６）
デバイスであって、
プロセッサと、
前記プロセッサと通信可能に接続されるメモリと
を備え、
前記メモリは、実行可能な命令を記憶しており、前記命令は、前記プロセッサによって実行されると、
第１のフレームをピアデバイスに無線通信を介して送信することであって、前記第１のフレームは、第１のアプリケーションデータを備えている、ことと、
第２のフレームを前記ピアデバイスに無線通信を介して送信することであって、前記第２のフレームは、第２のアプリケーションデータを備えている、ことと、
統合されたＡＣＫフレームを受信することであって、前記統合されたＡＣＫフレームは、前記第１のアプリケーションデータの肯定応答と、前記第２のアプリケーションデータの肯定応答とを備えている、ことと
を含む動作を前記プロセッサに達成させる、デバイス。
（項目１７）
ユーザインタフェース上に前記統合されたＡＣＫの状態の指示を表示するための命令を提供することをさらに含む、項目１６に記載のデバイス。
（項目１８）
前記統合されたＡＣＫの状態は、前記統合されたＡＣＫ内のアプリケーションの肯定応答の量を備えている、項目１７に記載のデバイス。
（項目１９）
前記統合されたＡＣＫの状態は、前記統合されたＡＣＫ内の肯定応答が同じアプリケーションに関連付けられているかどうかの指示を備えている、項目１７に記載のデバイス。
（項目２０）
前記第２のアプリケーションデータは、前記第１のアプリケーションデータとは異なるアプリケーションからである、項目１６に記載のデバイス。

添付の図面と併せて一例として挙げられる、以下の説明から、より詳細に理解され得る。
図１Ａは、クロス層ＡＣＫを使用しないシングルホップのメッセージフローを例証する。 図１Ｂは、クロス層ＡＣＫを使用するシングルホップのメッセージフローを例証する。 図２は、合理化されたクロス層ＡＣＫを使用するシングルホップのメッセージフローを例証する。 図３Ａは、クロス層ＡＣＫのための、メッセージがより高い層から受信されるときの、送信ＵＥの例示的フローチャートを例証する。 図３Ｂは、クロス層ＡＣＫのための、メッセージが物理層から受信されるときの、送信ＵＥの例示的フローチャートを例証する。 図４は、クロス層ＡＣＫのための、受信ＵＥのフローチャートを例証する。 図５Ａは、クロス層ＡＣＫを使用しないマルチホップシナリオのメッセージフローを例証する。 図５Ｂは、クロス層ＡＣＫを使用するマルチホップシナリオのメッセージフローを例証する。 図６は、クロスアプリケーションＡＣＫを使用するシングルホップのメッセージフローを例証する。 図７は、クロス層クロスアプリケーションＡＣＫを使用するシングルホップのメッセージフローを例証する。 図８Ａは、クロス層ＡＣＫを使用しないＩＥＥＥ ８０２．１５．４ネットワークを経由したＣｏＡＰのシングルホップのメッセージフローを例証する。 図８Ｂは、クロス層ＡＣＫを使用するＩＥＥＥ ８０２．１５．４ネットワークを経由したＣｏＡＰのシングルホップのメッセージフローを例証する。 図９は、統合された肯定応答を使用し得るユーザ機器の例示的プロトコルスタックを例証する。 図１０Ａは、３ＧＰＰ ＬＴＥ Ｕｕインタフェースユーザプレーンプロトコルスタックを使用する、統合されたＡＣＫを例証する。 図１０Ｂは、３ＧＰＰ ＬＴＥ Ｕｕインタフェースユーザプレーンプロトコルスタックを使用する、統合されたＡＣＫを例証する。 図１１Ａは、ある実施形態による、例示的かつ非限定的な修正されたおよび／または拡張された一般的ＭＡＣフレーム形式を例証する。 図１１Ａは、ある実施形態による、例示的かつ非限定的なフレーム制御フィールド形式を例証する。 図１２Ａは、１つ以上の開示される実施形態が実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）またはモノのインターネット（ＩｏＴ）の通信システムの系統図である。 図１２Ｂは、図１２Ａに例証されるＭ２Ｍ／ＩｏＴ通信システム内で使用され得る、例示的アーキテクチャの系統図である。 図１２Ｃは、図１２Ａに例証される通信システム内で使用され得る、例示的Ｍ２Ｍ／ＩｏＴ端子またはゲートウェイデバイスの系統図である。 図１２Ｄは、図１２Ａの通信システムの側面が実施され得る、例示的コンピューティングシステムのブロック図である。

従来のプロトコルにおけるＭＡＣ層肯定応答は、アプリケーション無関心またはアプリケーション独立である。本明細書に開示されるのは、アプリケーションレベルのＡＣＫ（例えば、ＣｏＡＰレベルＡＣＫ）およびＭＡＣ層ＡＣＫ（例えば、ＩＥＥＥ ８０２．１５．４ ＡＣＫ）を統合および最適化する方法およびシステムである。最適化は、送信側と受信側との間で要求されるメッセージの数を減らし得る、統合されたＡＣＫメッセージを定義することによって達成され得る。本明細書に議論されるように、統合されたＭＡＣ
ＡＣＫは、クロス層ＡＣＫ、クロスアプリケーションＡＣＫ、またはクロス層クロスアプリケーションＡＣＫを含み得る。

ＡＣＫベースの再伝送機構は、ＩＥＥＥ ８０２．１５およびＩＥＥＥ ８０２．１１シリーズ等、ほとんどのＭＡＣプロトコルにおいて存在し、ＭＡＣ層内で１ホップの信頼性のある伝送を提供する。より高い層のプロトコル（例えば、ＴＣＰ、ＣｏＡＰ）も、エンドツーエンドのＡＣＫ機構に基づくエンドツーエンド（マルチホップまたは１ホップ）の信頼性のある伝送を提供する。しかしながら、ＭＡＣ層の再伝送およびアプリケーション層の再伝送は、互に独立している。言い換えると、以下でさらに詳細に議論されるように、ＭＡＣ層の再伝送は、ＭＡＣ層ＡＣＫに基づき、より高い層の再伝送は、アプリケーション層ＡＣＫにのみ基づく。

ほとんどのアプリケーションが１ホップ以内で発生する近接通信に対して、マルチホップが時々要求されるが、独立的に処理されるＭＡＣ層の再伝送とより高い層の再伝送とは、冗長であり得ることが分かる。アプリケーション層に必要がないほとんどのＭＡＣプロトコル（例えば、ＩＥＥＥ ８０２．１５．４）に、ＭＡＣ層ＡＣＫメッセージが存在する。メッセージの数は、「アプリケーションデータ」がＭＡＣ層ＡＣＫ内でピギーバックされることを可能にすることによって、減らされ得る。「アプリケーションデータ」は、アプリケーションＡＣＫであり得る。

本明細書に議論される方法およびシステムは、複数のアプリケーションのために、ＭＡＣ層の伝送（または再伝送）およびより高い層の伝送（または再伝送）の機構を調整および最適化する方法を開示する。クロス層ＡＣＫ、クロスアプリケーションＡＣＫ、およびクロス層クロスアプリケーションＡＣＫ等、近接通信のための信頼性のあるデータ伝送のための肯定応答機構が、以下でより詳細に説明される。さらに、本明細書により詳細に議論されるように、アプリケーションデータは、層４（例えば、ＴＣＰ、ＳＴＣＰ等）、層５（例えば、ＣｏＡＰ、ＨＴＴＰ等）、または他のＭＡＣ層よりも高い層等、ＭＡＣ層よりも高い層からのデータを意味する。アプリケーションＡＣＫは、アプリケーションデータのためのＡＣＫを意味する。開示される方法およびシステムは、ＩＥＥＥ ８０２．１５．８、ＩＥＥＥ ８０２．１５．４、またはＩＥＥＥ ８０２．１１ｘ等、ＭＡＣ層のプロトコルに影響を与え得る。

クロス層ＡＣＫは、単一ＭＡＣ層ＡＣＫ（以下統合されたＭＡＣ ＡＣＫ）として統合される、ＭＡＣ層ＡＣＫ（例えば、ＩＥＥＥ ８０２．１５．４）とアプリケーション層ＡＣＫ（例えば、ＣｏＡＰ）とを伴う。統合されたＡＣＫは、ＭＡＣ層肯定応答およびアプリケーション層肯定応答の両方の役割を果たすように活用される。図１Ａおよび図１Ｂは、ユーザ機器（ＵＥ）間の通信が１ホップ以内であるシナリオを例証する。ＵＥは、本明細書に議論されるように、移動局、固定またはモバイル加入者ユニット、ポケットベル、携帯電話、携帯情報端末（ＰＤＡ）、スマートフォン、ラップトップ、ネットブック、パーソナルコンピュータ、無線センサまたはアクチュエータ、家庭用電化製品、医療デバイス、自動車等と見なされ得る。

図１Ａは、クロス層ＡＣＫを使用しない従来のメッセージフロー１１０を例証する。ＵＥ１１１は、送信側ＵＥと見なされ得る一方、ＵＥ１１２は、受信側ＵＥと見なされ得る。ステップ１１３では、ＵＥ１１１は、ＵＥ１１２に、アプリケーションデータを含むＭＡＣデータフレームを送信する。ステップ１１４では、ＵＥ１１２は、ＵＥ１１１に、ＭＡＣ ＡＣＫを送信し、これは、ＵＥ１１１に、ＵＥ１１２がステップ１１３のＭＡＣデータフレームを受信したことを肯定応答する。ステップ１１５では、ＵＥ１１２は、アプリケーションＡＣＫを含むＭＡＣデータフレームを送信し、これは、ＵＥ１１１に、ＵＥ１１２がステップ１１３のアプリケーションデータを受信したことを肯定応答する。ステップ１１６では、ＵＥ１１１は、ＵＥ１１２に、ＭＡＣ ＡＣＫを送信し、これは、ステップ１１５のＭＡＣフレームの受信を肯定応答する。

従来のメッセージフロー１１１は、２つのＭＡＣ ＡＣＫフレーム（ステップ１１４およびステップ１１６における）が、ＭＡＣアプリケーションデータを含む２つのＭＡＣデータフレーム（ステップ１１３およびステップ１１５における）に対して要求されることを例証する。要するに、図１Ａに示されるように、ＵＥ１１１とＵＥ１１２との間には４つのメッセージが存在する。ステップ１１３のアプリケーションデータは、アプリケーション要求であり得、ステップ１１５のアプリケーションＡＣＫは、アプリケーション応答であり得る。

図１Ｂは、ＵＥがクロス層ＡＣＫを使用するメッセージフロー１１７を例証する。ステップ１１８では、ＵＥ１１１は、ＵＥ１１２に、アプリケーションデータを含むＭＡＣデータフレームを送信する。ステップ１０２では、ステップ１１８のアプリケーションデータのためのＡｐｐ ＡＣＫが、ＵＥ１１２上で利用可能になる。ステップ１１９では、ＵＥ１１２は、ＵＥ１１１に、統合されたＭＡＣ ＡＣＫを送信する。ステップ１１９の統合されたＭＡＣ ＡＣＫは、「通常」ＭＡＣ ＡＣＫ（ステップ１１４のＭＡＣ ＡＣＫに類似）と「通常」アプリケーションＡＣＫ（ステップ１１５のアプリケーションＡＣＫに類似）とを含む、１つのメッセージである。言い換えると、ステップ１１９の統合されたＭＡＣ ＡＣＫは、同時に２つの目的を果たす。これは、ＵＥ１１１からＵＥ１１２へのステップ１１８の先のＭＡＣデータフレームを肯定応答する目的を果たす。加えて、ステップ１１９の統合されたＭＡＣ ＡＣＫは、ステップ１１８の先のＭＡＣデータフレーム内に含まれるアプリケーションデータを肯定応答する。

クロス層ＡＣＫでは、総メッセージ数は、図１Ｂに例証されるように、４から２に減らされ得る。クロス層ＡＣＫの使用は、各メッセージが、とりわけ、ＭＡＣヘッダ、ＭＡＣフッタ、ＰＨＹヘッダ、およびＰＨＹフッタを含み得るため、伝送されるべき総ビットの減少を補助し得る。加えて、メッセージの減少は、無線を経由したチャネル衝突の可能性を減らし得る。要するに、減少は、とりわけ、待ち時間、スループット、およびエネルギー消費という点で性能を改良し得る。

図１Ｂでは、ＵＥ１１２は、アプリケーションＡＣＫ（以下ＡＰＰ ＡＣＫとも称される）を計算する時間を要し得る。したがって、クロス層ＡＣＫの実装では、統合されたＭＡＣ ＡＣＫは、対のＡｐｐ ＡＣＫが利用可能になるまで発行されないこともある。図２は、「合理化されたクロス層ＡＣＫ」のためのメッセージフロー１２０を例証し、Ａｐｐ ＡＣＫは、必ずしも、アプリケーションデータを伝えたＭＡＣフレームに関連付けられるＭＡＣ ＡＣＫと対にされない。ステップ１２１では、ＵＥ１１１は、ＵＥ１１２に、第１のアプリケーションデータを含むＭＡＣデータフレームを送信する。ステップ１２２では、ＵＥ１１２は、ＵＥ１１１に、ステップ１２１の受信されたＭＡＣデータフレームに関するＭＡＣ ＡＣＫを送信する。ステップ１２３では、ＵＥ１１１は、ＵＥ１１２に、第２のアプリケーションデータを含むＭＡＣデータフレームを送信する。

継続して図２を参照すると、ステップ１２７では、ステップ１２１のアプリケーションデータのためのＡｐｐ ＡＣＫが、ＵＥ１１２上で利用可能になる。ステップ１２４では、ＵＥ１１２は、ＵＥ１１１に、ステップ１２１の第１のアプリケーションデータのためのＡｐｐ ＡＣＫだけではなく、ステップ１２３のＭＡＣデータフレームのためのＭＡＣ
ＡＣＫも含む統合されたＭＡＣ ＡＣＫを送信する。ステップ１２５では、ＵＥ１１１は、ＵＥ１１２に、第３のアプリケーションデータを含むＭＡＣデータフレームを送信する。ステップ１２８では、ステップ１２３のアプリケーションデータのためのＡｐｐ ＡＣＫが、ＵＥ１１２上で利用可能になる。ステップ１２６では、ＵＥ１１２は、ＵＥ１１１に、ステップ１２３の第２のアプリケーションデータのためのＡｐｐ ＡＣＫだけではなく、ステップ１２５のＭＡＣデータフレームのためのＭＡＣ ＡＣＫも含む、統合されたＭＡＣ ＡＣＫを送信する。

図２を参照すると、追加のステップは、複数のＡｐｐ ＡＣＫが閾値時間間隔内で利用可能になる場合、ＵＥ１１２は、複数のＡｐｐ ＡＣＫを保持し、それらを一緒に１つの直近ＭＡＣ ＡＣＫにおいてピギーバックし得ることを例証する。ステップ１２９では、ＵＥ１１１は、ＵＥ１１２に、第４のアプリケーションデータを含むＭＡＣデータフレームを送信する。ステップ１３０では、ステップ１２５の第３のアプリケーションデータのためのＡｐｐ ＡＣＫが、ＵＥ１１２上で利用可能になる。ステップ１３１では、ステップ１２９の第４のアプリケーションデータのためのＡｐｐ ＡＣＫが、ＵＥ１１２上で利用可能になる。ステップ１３２では、ＵＥ１１２は、ＵＥ１１１に、ステップ１２５の第３のアプリケーションデータのためのＡｐｐ ＡＣＫおよびステップ１２９の第４のアプリケーションデータのためのＡｐｐ ＡＣＫだけではなく、ステップ１２９のＭＡＣデータフレームのためのＭＡＣ ＡＣＫも含む、統合されたＭＡＣ ＡＣＫを送信する。

クロス層ＡＣＫを参照すると、いくつかの場合では、次の統合されたＭＡＣ ＡＣＫ内で伝送されるべきＡｐｐ ＡＣＫを保持する場合、遅延が生じ得る。これは、概して、とりわけ、音声、ビデオストリーミング、およびコンテンツ共有等、連続的または双方向性アプリケーションにとって重要な問題ではない。加えて、ＡＰＰ ＡＣＫを遅延させることはまた、アプリケーションの視点から利益をもたらし得る。例えば、ＴＣＰ ＡＣＫを遅延させることは、送信側のウィンドウサイズを減らすことに役立ち得る。無線ＴＣＰに関する研究は、この様式におけるＴＣＰ遅延が、潜在的混雑を軽減または除去し得ること（すなわち、無線近接通信のためのＴＣＰ拡張）を実証している。

図３Ａおよび図３Ｂは、クロス層ＡＣＫ動作のための送信側と見なされ得る、ＵＥ１１１のフローチャートを例証する。図３Ａは、ＵＥ１１１のより高い層（例えば、アプリケーション層）からのメッセージを受信するＵＥ１１１のより低い層（例えば、ＭＡＣ層）のフローチャート１４０を例証する。ステップ１４１では、メッセージは、より高い層から受信される。ステップ１４２では、ＭＡＣ層は、メッセージがＡＣＫを必要とするかどうかを決定し得る。メッセージがＡＣＫを必要とする場合、ステップ１４３では、ＭＡＣ層は、メッセージが全体メッセージまたはフラグメント化されたメッセージかどうかを決定し得る。全体メッセージである場合、クロス層ＡＣＫが、ステップ１４４で有効化される。

ステップ１４５では、クロス層ＡＣＫが有効化された後、クロス層ＡＣＫ ＭＡＣ手順が、実施される。本手順は、ＭＡＣフレーム内でＭＡＣフラグメント化を無効化し、受信側からの統合されたＡＣＫを要求するためのフラグをマーキングすることを含み得る。代替として、フラグメント化が有効化され、統合されたＡＣＫのために最後のフラグメントのみをマーキングし得る。ＵＥ１１１は、ＭＡＣフレームとアプリケーションメッセージ（すなわち、より高い層のデータ）との間のマッピング関係を維持し得る。ステップ１４８では、メッセージは、ＰＨＹフレームを介して送信される。ある実施形態では、ＭＡＣ層に、アプリケーションからのメッセージが、異なる層（例えば、層４、層５）からの「アプリケーション」でグループ化され得るかどうかをアラートするインジケータが存在し得る。

図３Ａのステップ１４２およびステップ１４３を参照すると、より高い層のメッセージがＡＣＫを必要としない場合、またはメッセージがフラグメント化されている場合、ステップ１４６では、クロス層ＡＣＫは、メッセージのために無効化されるか、またはアクティブ化されないこともある。ステップ１４７では、従来のＭＡＣ手順が、実行され得る。

図３Ｂは、ＰＨＹ層（例えば、より低い層）からメッセージを受信するＵＥ１１１のＭＡＣ層のフローチャート１５０を例証する。ステップ１５１では、ＵＥ１１１のＭＡＣ層は、ＰＨＹ層からメッセージを受信する。ステップ１５２では、ＭＡＣ層は、ＭＡＣ ＡＣＫフレームが統合されたＭＡＣ ＡＣＫであるかどうかを決定する。ＭＡＣ ＡＣＫフレームが統合されたＭＡＣ ＡＣＫである場合、ステップ１５３では、クロス層ＭＡＣ手順が、実施される。ステップ１５３では、統合されたＡＣＫは、ＭＡＣデータフレームにマッピングされる。加えて、統合されたＡＣＫは、アプリケーションデータにマッピングされる。また、ステップ１５３では、従来の（すなわち、通常の）アプリケーションＡＣＫが、再構成され、再構成されたアプリケーションＡＣＫは、アプリケーション層に転送される。ステップ１５２を参照すると、ＭＡＣ ＡＣＫフレームが統合されたＭＡＣ ＡＣＫではない場合、従来のＭＡＣ手順が、ステップ１５４で実施される。ＵＥ１１１は、先に送信されたＭＡＣフレームに対して予期される統合されたＭＡＣ ＡＣＫまたは通常ＭＡＣ ＡＣＫを受信側（ＵＥ１１２）から、受信しない場合、ＵＥ１１１は、ＭＡＣフレームを、再伝送時間が終了するまで再伝送する。

図４は、クロス層ＡＣＫ動作のためのＵＥ１１２（すなわち、受信側）のフローチャート１６０を例証する。ステップ１６１では、ＵＥ１１２のＭＡＣ層は、ＵＥ１１２のＰＨＹ層からＭＡＣフレームを受信する。ステップ１６２では、ＵＥ１１２は、統合されたＡＣＫフラグが設定されているかどうかを決定する。フラグが設定されていない場合、通常ＭＡＣ手順が、ブロック１６５で実施される。統合されたＡＣＫフラグが設定されている場合、クロス層ＡＣＫが、ステップ１６３で有効化される。ブロック１６４では、クロス層ＭＡＣ手順が、実施される。ステップ１６４の統合されたＭＡＣ ＡＣＫ手順は、より高い層に渡すアプリケーションデータを含む。加えて、アプリケーションＡＣＫまたは応答が、より高い層から受信される。さらに、ステップ１６４の統合されたＭＡＣ ＡＣＫ手順は、アプリケーションＡＣＫが到達するまでの閾値時間の間、ＭＡＣ ＡＣＫを保持することを含み得る。ＵＥ１１２が、アプリケーションＡＣＫを得るための閾値時間が経過したと見出す場合、ＵＥ１１２は、クロス層ＡＣＫを無効化し、通常ＭＡＣ ＡＣＫ手順を使用し得る。いったんアプリケーションＡＣＫが受信されると、ＡＣＫ ＭＡＣフレームが、送信され得る。ステップ１６６では、ＭＡＣ ＡＣＫフレームは、ＰＨＹフレームを介して伝送される。随意に、ＵＥ１１２は、独立して、通常ＡＣＫまたはクロス層ＡＣＫを使用するかどうかを決定し得る。図３Ａ、図３Ｂ、および図４におけるいくつかのまたは全てのステップは、１つ以上の層の間に分散され得る。

図４を参照すると、ある実施形態では、ＵＥ１１２は、ステップ１６１に関連付けられる統合されたＭＡＣ ＡＣＫを送信する前に、設定期間を待ち得、設定期間は、手動で（例えば、ユーザによる設定される）または自動で（ビデオストリーミングアプリケーション、チャットアプリケーション、ヘルスアプリケーション等、アプリケーションのタイプに基づいて自動的に修正される）事前決定され得る。

図５Ａおよび図５Ｂは、中継装置１８２がＵＥ１８１とＵＥ１８３との間に位置するマルチホップのシナリオを例証する。図５Ａは、クロス層ＡＣＫを使用しないマルチホップフローを例証する。ステップ１８４では、ＵＥ１８１は、中継装置１８２に、第１のアプリケーションデータを含むＭＡＣデータフレームを送信する。ステップ１８５では、中継装置１８２は、ＵＥ１８１に、ＭＡＣ ＡＣＫを送信する。ステップ１８６では、中継装置１８２は、ＵＥ１８３に、ステップ１８４の第１のアプリケーションデータを含むＭＡＣデータフレームを転送する。ステップ１８７では、ＵＥ１８３は、中継装置１８２に、ステップ１８６のＭＡＣデータフレームのためのＭＡＣ ＡＣＫを送信する。ステップ１８８では、ＵＥ１８３は、中継装置１８２に、ステップ１８６で受信された第１のアプリケーションデータのためのＡｐｐ ＡＣＫを伴うＭＡＣデータフレームを送信する。ステップ１８９では、中継装置１８６は、ＵＥ１８３に、ステップ１８８で受信されたＭＡＣデータフレームのためのＭＡＣ ＡＣＫを送信する。ステップ１９０では、中継装置１８２は、ステップ１８６およびステップ１８４の第１のアプリケーションデータのためのＡｐｐ ＡＣＫを含むＭＡＣデータフレームを転送する。ステップ１９１では、ＵＥ１８１は、中継装置１８２に、ステップ１９０で受信されたＭＡＣデータフレームのためのＭＡＣ ＡＣＫを送信する。

図５Ｂは、クロス層ＡＣＫを使用する例示的なマルチホップのシナリオを例証する。ステップ１９３では、ＵＥ１８１は、中継装置１８２に、第１のアプリケーションデータを含むＭＡＣデータフレームを送信する。ステップ１９４では、中継装置１８２は、ＵＥ１８１に、ＭＡＣ ＡＣＫを送信する。ステップ１９５では、中継装置１８２は、ＵＥ１８３に、ステップ１９３の第１のアプリケーションデータを含むＭＡＣデータフレームを転送する。ステップ１９６では、第１のアプリケーションデータのためのＡｐｐ ＡＣＫが、ＵＥ１８３上で利用可能になる。ステップ１９７では、ＵＥ１８３は、中継装置１８２に、ステップ１９５のためのＡｐｐ ＭＡＣならびにステップ１９５およびステップ１９３の第１のアプリケーションデータのためのＡｐｐ ＡＣＫを含む、統合されたＭＡＣ ＡＣＫを送信する。ステップ１９８では、中継装置１８２は、ＵＥ１８１に、ステップ１９３の第１のアプリケーションデータのためのＡｐｐ ＡＣＫを含むＭＡＣデータフレームを送信する。ＭＡＣ ＡＣＫがステップ１９３のＭＡＣデータフレームのためにステップ１９４で送信されているため、統合されたＡＣＫを送信する必要はない。ステップ１９９では、ＵＥ１８１は、中継装置１８２に、ステップ１９８で受信されたＭＡＣデータフレームのためのＭＡＣ ＡＣＫを送信する。

図５Ｂを参照すると、各ホップのためのＭＡＣ ＡＣＫフレームは、信頼性のある伝送を改良するための高度な特徴をサポートするより多くの情報を含み得る。例えば、フラグビットが、対応するデータフレームが転送されるべきかどうかを示すために使用され得る。このビットは、ＵＥ１８１によって設定され得る（ＵＥ１８１がソースベースのルーティングプロトコルを使用する場合）か、またはＵＥ１８１は、中継装置１８２によって設定され得る。ホップの数を示すより多くのビットもまた、存在し得る。ＵＥ１８３から１ホップ離れている中継装置１８２が、クロス層ＡＣＫを有効化するかどうかを決定し得る。ＵＥ１８３（受信側）は、独立して、クロス層ＡＣＫを使用するかどうかを決定し得る。

以下でより詳細に議論されるのは、クロスアプリケーションＡＣＫである。クロスアプリケーションＡＣＫに対して、異なるアプリケーションからのＡＣＫが、同じＭＡＣ ＡＣＫフレーム内で一緒に統合され、伝送される。図６は、ＵＥ２０１（送信側）とＵＥ２０２（受信側）との間の統合されたＡＣＫメッセージフロー２００（クロスアプリケーションＡＣＫメッセージフロー）の別のタイプを例証する。ＵＥ２０１およびＵＥ２０２は、同時に、複数のアプリケーション（例えば、アプリケーション１およびアプリケーション２）を起動し、１ホップ以内であると仮定され得る。

図６を参照すると、ステップ２１０では、ＵＥ２０１は、アプリケーション１データのためのクロスアプリケーションＡＣＫフラグを設定する。クロスアプリケーションＡＣＫフラグは、ＭＡＣデータフレームのヘッダ内のビットであり得る。フラグは、含まれるアプリケーションデータが、他のアプリケーションデータと一緒に合同で肯定応答されることができるかどうかを示す。ステップ２０３では、ＵＥ２０１は、ＵＥ２０２に、クロスａｐｐ ＡＣＫフラグを伴うアプリケーション１データを含むＭＡＣデータフレームを送信する。ステップ２１３では、ＵＥ２０２は、ステップ２０３の受信されたＭＡＣヘッダ内に設定されたクロスアプリケーションＡＣＫフラグビットが存在するかどうかを決定する。フラグビットが設定されている場合、ＵＥ２０２は、アプリケーションデータ１を、クロスアプリケーションＡＣＫのための候補としてマークする。ステップ２０４では、ＵＥ２０２は、ＵＥ２０１に、ステップ２０３のＭＡＣデータフレームのためのＭＡＣ ＡＣＫを送信する。

ステップ２１１では、ＵＥ２０１は、アプリケーション２データのためのクロスアプリケーションＡＣＫフラグを設定する。ステップ２０５では、ＵＥ２０１は、ＵＥ２０２に、設定されたクロスアプリケーションＡＣＫフラグを伴うアプリケーション２データを含むＭＡＣデータフレームを送信する。ステップ２１４では、ＵＥ２０２は、ステップ２０５の受信されたＭＡＣヘッダ内に設定されたクロスアプリケーションＡＣＫフラグビットが存在するかどうかを決定し、ＵＥ２０２は、アプリケーションデータ２を、クロスアプリケーションＡＣＫのための候補としてマークする。ステップ２０６では、ＵＥ２０２は、ＵＥ２０１に、ステップ２０５のＭＡＣデータフレームのためのＭＡＣ ＡＣＫを送信する。

ステップ２１５では、ＵＥ２０２は、クロスアプリケーションＡＣＫがステップ２０７のＭＡＣデータフレーム内に含まれることを示すために、ステップ２０７のＭＡＣデータフレームのヘッダ内にフラグビットを設定する。ステップ２０７では、ＵＥ２０２は、ＵＥ２０１に、ＭＡＣデータフレームを送信する。

ステップ２０８では、ＵＥ２０１は、ＵＥ２０２に、ステップ２０７のＭＡＣデータフレームのためのＭＡＣ ＡＣＫを送信する。ステップ２０７のＭＡＣデータフレームは、クロスａｐｐ ＡＣＫを含み、これは、ステップ２０３のアプリケーション１データおよびステップ２０５のアプリケーション２データの受信を肯定応答するために使用される。アプリケーション１ＡＣＫおよびアプリケーション２ＡＣＫは、ステップ２０７のＭＡＣデータフレームのペイロード内にあり得る。ステップ２１２では、ＵＥ２０１は、フラグ（例えば、ビット）がＭＡＣヘッダ内に設定されていることを決定し、これは、クロスアプリケーションＡＣＫがステップ２０７のＭＡＣデータフレーム内で使用されていることを示す。ＵＥ２０１は、ＭＡＣデータフレームをデコードし、アプリケーション１ＡＣＫおよびアプリケーション２ＡＣＫを、より高い層内の対応するアプリケーションに転送する。

ステップ２０７のＭＡＣデータフレームは、とりわけ、クロスアプリケーションＡＣＫフラグ、アプリケーションＡＣＫパラメータ（現在のフレーム内かつ許可される閾値（最大値）内）の数、およびアプリケーションＩＤのリスト等、クロスアプリケーション層ＡＣＫをサポートするパラメータを含み得る。例えば、アプリケーションパラメータの数は、ステップ２０７のＭＡＣデータフレーム内に含まれるアプリケーションＡＣＫの数を示し得る。アプリケーションＩＤは、ピギーバックされたＡＣＫ（すなわち、ステップ２０７のクロス層ＡＣＫ）が属する対応するアプリケーションを示し得る。

以下でより詳細に議論されるのは、クロス層クロスアプリケーションＡＣＫである。クロス層クロスアプリケーションＡＣＫに対して、異なる層および異なるアプリケーションが、単一ＭＡＣ層ＡＣＫとして統合される。言い換えると、単一の統合されたＭＡＣ ＡＣＫは、異なるアプリケーションからのＭＡＣフレームおよびデータを肯定応答するために活用される。図７は、クロス層クロスアプリケーションのメッセージフロー２２０を例証する。ＵＥ２２１（送信側）およびＵＥ２２２（受信側）は、同時に、複数のアプリケーション（例えば、アプリケーション１およびアプリケーション２）を起動すると仮定され得る。ＵＥ２２１およびＵＥ２２２は、１ホップ内であり、アプリケーション１およびアプリケーション２が、信頼性のある伝送を保証するためのアプリケーションＡＣＫを実装することも仮定され得る。

図７を参照すると、ステップ２２５では、ＵＥ２２１は、ＵＥ２２２に、アプリケーション１データを伴うＭＡＣデータフレームを送信する。ステップ２２７では、ＵＥ２２１は、ＵＥ２２２に、アプリケーション２データを伴うＭＡＣデータフレームを送信する。ステップ２２５およびステップ２２７のＭＡＣデータフレームは、本明細書に議論されるように、とりわけ、クロスａｐｐ ＡＣＫフラグ、アプリケーションパラメータ数、およびアプリケーションＩＤのリストを含み得る。例えば、ＵＥ２２１は、ＵＥ２２２に、クロス層クロスアプリケーションがアプリケーション１およびアプリケーション２のために有効化され得ることをアラートするために、ステップ２２５および２２７のＭＡＣデータフレームのＭＡＣヘッダ内にフラグビットを設定し得る。

ステップ２３０では、ＵＥ２２２は、ＵＥ２２１に、統合されたクロス層クロスアプリケーションＭＡＣ ＡＣＫを送信する。ステップ２３０のＭＡＣ ＡＣＫ内に含まれ得るものの複数の並べ替えが存在する。第１のオプションでは、ステップ２３０の統合されたクロス層クロスアプリケーションＭＡＣ ＡＣＫは、ステップ２２７のＭＡＣデータフレームとステップ２２５のアプリケーション１データとのためのアプリケーションＡＣＫに応答して、従来のＭＡＣ ＡＣＫを含み得る。第１のオプションに対して、ＵＥ２２２は、アプリケーション２データのためのアプリケーションＡＣＫを計算するために待つ必要はない。ＵＥ２２２は、ステップ２２７のＭＡＣデータフレームを受信した後、直ちにＭＡＣ ＡＣＫを発行し、ステップ２２５のアプリケーション１データのためのアプリケーションＡＣＫをピギーバックする。なぜなら、アプリケーション１データのためのアプリケーションＡＣＫが、ＭＡＣ ＡＣＫと同じ時間で送信されるために利用可能であるからである。

継続して図７を参照すると、ステップ２３０での第２のオプションでは、統合されたクロス層クロスアプリケーションＭＡＣ ＡＣＫは、ステップ２２５および２２７のＭＡＣデータフレームおよびアプリケーションの肯定応答を含む。図７における全てのＡＣＫは、ステップ２３０での伝送の前に、閾値期間内で到達していると仮定される。

以下に議論されるのは、本明細書に開示される方法およびシステムと組み合わせて制約アプリケーションプロトコル（ＣｏＡＰ）を使用する実装のための例示的フローである。ＣｏＡＰは、無線センサネットワークノード等のリソース制約インターネットデバイス内で使用され得るアプリケーション層プロトコルである。ＣｏＡＰ ＡＣＫ（すなわち、アプリケーションＡＣＫ）およびＩＥＥＥ ８０２．１５．４ ＡＣＫ（すなわち、ＭＡＣ
ＡＣＫ）の詳細が、以下に議論される。

図８Ａは、８０２．１５．４を使用し、クロス層ＡＣＫまたはクロスアプリケーションＡＣＫのいずれも使用しない、従来の（「通常の」）ＣｏＡＰメッセージフロー２３０を例証する。コーディネータ２３１は、ＣｏＡＰクライアントであり、デバイス２３２は、ＣｏＡＰサーバである。ステップ２３３では、デバイス２３２は、コーディネータ２３１に、ＭＡＣデータ要求フレームを送信する。ステップ２３４では、コーディネータ２３１は、デバイス２３２に、ステップ２３３のＭＡＣデータ要求フレームのためのＭＡＣ ＡＣＫを送信する。ステップ２３５では、コーディネータ２３１は、デバイス２３２に、ＣｏＡＰ要求を備えているＭＡＣデータフレームを送信する。ステップ２３６では、デバイス２３２は、コーディネータ２３１に、ステップ２３５のＭＡＣデータフレームのためのＭＡＣ ＡＣＫを送信する。ステップ２３７では、デバイス２３２は、コーディネータ２３１に、ステップ２３５のＣｏＡＰ要求のためのＣｏＡＰ ＡＣＫを送信する。ステップ２３８では、コーディネータ２３１は、デバイス２３２に、ステップ２３７のＭＡＣデータフレームのためのＭＡＣ ＡＣＫを送信する。ステップ２３９では、デバイス２３２は、コーディネータ２３１に、ステップ２３５のＣｏＡＰ要求のためのＣｏＡＰ応答を備えているＭＡＣデータフレームを送信する。ステップ２４０では、コーディネータ２３１は、デバイス２３２に、ステップ２３９のＭＡＣデータフレームのためのＭＡＣ ＡＣＫを送信する。ステップ２４１では、コーディネータ２３１は、デバイス２３２に、ステップ２３９のＣｏＡＰ応答のためのＣｏＡＰ ＡＣＫを備えているＭＡＣデータフレームを送信する。ステップ２４２では、デバイス２３２は、コーディネータ２４２に、ステップ２４１のＭＡＣデータフレームのためのＭＡＣ ＡＣＫを送信する。

図８Ｂは、クロス層ＡＣＫ ＣｏＡＰのメッセージフロー２５０を例証する。ステップ２５１では、デバイス２３２は、コーディネータ２３１に、ＭＡＣデータ要求フレームを送信する。ステップ２５２では、コーディネータ２３１は、デバイス２３２に、ステップ２５１のＭＡＣデータ要求フレームのためのＭＡＣ ＡＣＫを送信する。ステップ２５３では、コーディネータ２３１は、デバイス２３２に、ＣｏＡＰ要求を備えているＭＡＣデータフレームを送信する。ステップ２５４では、デバイス２３２は、コーディネータ２３１に、ステップ２５３のＭＡＣデータフレームおよびＣｏＡＰ要求のためのクロス層ＡＣＫを送信する。ステップ２５５では、デバイス２３２は、コーディネータ２３１に、ＣｏＡＰ応答を備えているＭＡＣデータフレームを送信する。ステップ２５６では、コーディネータ２３１は、デバイス２３２に、ステップ２５５のＭＡＣデータフレームおよびＣｏＡＰ応答のためのクロス層ＡＣＫを送信する。

クロス層ＡＣＫを使用する図８Ｂは、クロス層ＡＣＫを使用しない図８Ａと比較したメッセージの減少を例証する。図８Ａでは１０のステップがあるのに対し、図８Ｂでは６つのステップがある。

前述のように、クロス層、クロスアプリケーション、およびクロス層クロスアプリケーション肯定応答を実装するために加えられる、追加のフィールドまたはパラメータが存在し得る。表１は、ＭＡＣフレーム内で使用され得るいくつかのフィールドの実施例を表す。例えば、現在のＭＡＣデータフレームが、統合されたＭＡＣ ＡＣＫを予期または要求することを示すために、ＭＡＣデータフレームヘッダ内にクロス層ＡＣＫビットが存在し得る。現在のＭＡＣ ＡＣＫが、統合されたＭＡＣ ＡＣＫフレームであることを示すために、ＭＡＣ ＡＣＫフレームヘッダ内にクロス層ＡＣＫビットが存在し得る。

図９は、クロス層またはクロスアプリケーションＡＣＫを使用し得、近接通信に関わり得る、ユーザ機器（例えば、ＵＥ１１１またはＵＥ１１２）の例示的プロトコルスタック２６１を例証する。前述のように、アプリケーション層（すなわち、より高い層）は、本明細書に議論されるように、トランスポート層２６２、アプリケーションプロトコル層２６３、サービス層２６４、アプリケーション層２６５、または他のＭＡＣ層よりも高い層を含み得る。

図１０Ａおよび図１０Ｂは、本明細書に議論されるように、３ＧＰＰ ＬＴＥ Ｕｕインタフェースユーザプレーンプロトコルスタックを使用する、統合されたＡＣＫを例証する。図１０Ａおよび図１０Ｂに例証されるように、３ＧＰＰは、アプリケーション層、アプリケーションプロトコル層、トランスポート層、インターネットプロトコル（ＩＰ）層、パケットデータ収束制御（ＰＤＣＰ）層、無線リンク制御（ＲＬＣ）層、媒体アクセス制御（ＭＡＣ）層、および物理（ＰＨＹ）層を含み得る。開示される統合されたＡＣＫは、３ＧＰＰ ＲＬＣおよび３ＧＰＰ ＭＡＣの一部として実装され、開示される統合されたＡＣＫ方法を介してシステム性能を拡張し得る。いくつかのまたは全てのＭＡＣレベル手順は、前述のように（例えば、図３Ａ、図３Ｂ、図４等）、ＲＬＣ層２７３またはＭＡＣ層２７４を使用して行われ得る。ここでは、統合されたＡＣＫ関連ＭＡＣ手順の少なくとも一部を示すポイント２７２は、ＲＬＣ層２７３およびＭＡＣ層２７４を使用して行われる。ＴＣＰ２７１およびＨＴＴＰ２７０は、統合されたＡＣＫを使用し得、統合されたＡＣＫにおいて、ポイント２７２は、ＡＣＫを異なる層に分配する。図１０Ｂは、複数のアプリケーション（アプリケーション２７７およびアプリケーション２７８）であるが同じ層における別の実施例を例証する。アプリケーション２７７およびアプリケーション２７８は、統合されたＡＣＫを使用し得、統合されたＡＣＫにおいて、ポイント２７９は、ＡＣＫを異なる層に分配する。

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

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

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

フレームタイプおよびサブタイプ４２４、４２６は、必須であり得ると同時に、フレームのタイプ、すなわち、フレームの機能を示し得る。一実施形態では、４つの基本フレームタイプである、ビーコン、管理、データ、および肯定応答が存在する。フレームの各タイプは、いくつかのサブタイプを有し得る。加えて、サブタイプフィールドの意味は、異なるフレームタイプに対して変動し得る。一実施形態では、肯定応答フレームタイプは、本明細書に説明されるクロス層およびクロスアプリケーションの肯定応答において使用するためのフレームを指定するために使用され得る。表２は、肯定応答フレームに対するフレームタイプ４２４およびフレームサブタイプ４２６の値の一実施形態を例証する。示されるように、サブタイプ「４」、「５」、および「６」は、一実施形態では、クロス層、クロスアプリケーション、ならびにクロス層およびクロスアプリケーションの両方の肯定応答に使用するためのフレームを指定するために使用され得る。

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

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

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

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

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

異なる制御スキームに基づいて、Ｐ２ＰＮＷ ＩＤは、ネットワーク内の異なるパーティによって生成および割り当てられ得る。集中型制御スキームの実施形態では、Ｐ２ＰＮＷ ＩＤは、次いで、ＶＬに通知するスーパー仮想リーダ（ＶＬ）によって生成され得るか、またはＶＬが、Ｐ２ＰＮＷ ＩＤを生成し、ビーコン内にそれをブロードキャストし、スーパーＶＬおよび他のＶＬに通知し得る。ハイブリッド制御スキームの実施形態では、ＶＬは、Ｐ２ＰＮＷ ＩＤを生成し、ビーコン内にそれをブロードキャストし、他のＶＬに通知し得る。分散型制御スキームの実施形態では、Ｐ２ＰＮＷを形成することを所望するピア（すなわち、新しいアプリケーションフレームを定義するピア）は、Ｐ２ＰＮＷ
ＩＤを生成し、ビーコンをブロードキャストし、Ｐ２ＰＮＷ ＩＤの近接範囲内の全ピアに通知し得る。仮想リーダ（ＶＬ）は、同じ近接サービスを共有するピアグループ間の、すなわち、Ｐ２ＰＮＷ内のＰ２Ｐ通信を表現、管理、および調整するために、動的に選択され得るピアである。スーパー仮想リーダは、異なる近接サービスのために、近接したＰ２ＰＮＷの全ての仮想リーダを調整するために定義される仮想リーダである。仮想リーダおよびスーパー仮想リーダは、同期、電力制御、干渉管理、チャネル分配、アクセス制御等を目的として使用され得る。

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

３ＧＰＰおよび８０２．１５が背景として説明され、本明細書に説明される種々の実施形態を例証するために使用され得るが、実施形態の実装は、本開示の範囲内に留まりながら変動し得ることが理解される。当業者はまた、開示される実施形態が、前述のように、８０２．１５または３ＧＧＰを使用する実装に限定されず、むしろ、いくつかまたは全てが、ＥＴＳＩ Ｍ２Ｍ、ｏｎｅＭ２Ｍ、ＭＱＴＴ、ならびに他のシステムおよびアーキテクチャ等、他のアーキテクチャおよびシステムとともに実装および統合され得ることも認識するであろう。

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

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

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

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

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

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

いくつかの実施形態では、Ｍ２Ｍアプリケーション２０および２０’は、本明細書に議論されるように、クロス層ＡＣＫ、クロスアプリケーションＡＣＫ、またはクロス層クロスアプリケーションＡＣＫの使用をフラグする望ましいアプリケーションを含み得る。Ｍ２Ｍアプリケーション２０および２０’は、限定ではないが、輸送、保健および健康、コネクテッドホーム、エネルギー管理、アセット追跡、ならびにセキュリティおよび監視等の種々の業界でのアプリケーションを含み得る。上記のように、本システムのデバイス、ゲートウェイ、および他のサーバにわたって作動するＭ２Ｍサービス層は、例えば、データ収集、デバイス管理、セキュリティ、課金、場所追跡／ジオフェンシング、デバイス／サービス発見、およびレガシーシステム統合等の機能をサポートし、サービス等のこれらの機能をＭ２Ｍアプリケーション２０および２０’に提供する。

本願のクロス層ＡＣＫ、クロスアプリケーションＡＣＫ、またはクロス層クロスアプリケーションＡＣＫは、ＡＣＫを使用するサービス層の一部として実装され得る。例えば、サービス層からのメッセージは、クロス層ＡＣＫがそのサービスに対して許可されることを示すフラグを有し得る。サービス層は、アプリケーションプログラミングインターフェース（ＡＰＩ）および下層ネットワーキングインターフェースのセットを通して付加価値サービス能力をサポートする、ソフトウェアミドルウェア層である。Ｍ２Ｍエンティティ（例えば、ハードウェアおよびソフトウェアの組み合わせによって実装され得る、デバイス、ゲートウェイ、またはサービス／プラットフォーム等のＭ２Ｍ機能エンティティ）が、アプリケーションまたはサービスを提供し得る。ＥＴＳＩ Ｍ２ＭおよびｏｎｅＭ２Ｍの両方が、本発明のクロス層ＡＣＫ、クロスアプリケーションＡＣＫ、またはクロス層クロスアプリケーションＡＣＫとともに機能する構成要素を含み得るサービス層を使用する。ＥＴＳＩ Ｍ２Ｍのサービス層は、サービス能力層（ＳＣＬ）と称される。ＳＣＬは、（それがデバイスＳＣＬ（ＤＳＣＬ）と称される）Ｍ２Ｍデバイス、（それがゲートウェイＳＣＬ（ＧＳＣＬ）と称される）ゲートウェイ、および／または（それがネットワークＳＣＬ（ＮＳＣＬ）と称される）ネットワークノード内で実装され得る。ｏｎｅＭ２Ｍサービス層は、共通サービス機能（ＣＳＦ）（すなわち、サービス能力）のセットをサポートする。１つ以上の特定のタイプのＣＳＦのセットのインスタンス化は、異なるタイプのネットワークノード（例えば、インフラストラクチャノード、中央ノード、アプリケーション特有のノード）上でホストすることができる、共通サービスエンティティ（ＣＳＥ）と称される。さらに、本願は、サービスにアクセスするために、サービス指向アーキテクチャ（ＳＯＡ）および／またはリソース指向アーキテクチャ（ＲＯＡ）を使用する、Ｍ２Ｍネットワークの一部として実装され得る。

図１２Ｃは、例えば、Ｍ２Ｍ端末デバイス１８またはＭ２Ｍゲートウェイデバイス１４等、例示的Ｍ２Ｍデバイス３０（例えば、ＵＥ１１１、ＵＥ１１２、ＵＥ２２１、ＵＥ２２２等）の系統図である。図１２Ｃに示されるように、Ｍ２Ｍデバイスは、プロセッサ３２と、送受信機３４と、伝送／受信要素３６と、スピーカ／マイクロホン３８と、キーパッド４０と、ディスプレイ／タッチパッド４２と、非取り外し可能メモリ４４と、取り外し可能メモリ４６と、電源４８と、全地球測位システム（ＧＰＳ）チップセット５０と、他の周辺機器５２とを含み得る。Ｍ２Ｍデバイス３０は、実施形態と一致したままで、先述の要素の任意の副次的組み合わせを含み得ることが理解されるであろう。このデバイスは、クロス層ＡＣＫ、クロスアプリケーションＡＣＫ、またはクロス層クロスアプリケーションＡＣＫのために、開示されたシステムおよび方法を使用するデバイスであり得る。

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

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

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

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

プロセッサ３２は、非取り外し可能メモリ４４および／または取り外し可能メモリ４６等の任意のタイプの好適なメモリから情報にアクセスし、そこにデータを記憶し得る。非取り外し可能メモリ４４は、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、ハードディスク、または任意の他のタイプのメモリ記憶デバイスを含み得る。取り外し可能メモリ４６は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカード等を含み得る。他の実施形態では、プロセッサ３２は、サーバまたはホームコンピュータ上等のＭ２Ｍデバイス３０上に物理的に位置しないメモリから情報にアクセスし、そこにデータを記憶し得る。プロセッサ３２は、クロス層ＡＣＫ、クロスアプリケーションＡＣＫ、またはクロス層クロスアプリケーションＡＣＫの状態または構成に応答して、ディスプレイまたはインジケータ４２上の照明パターン、画像、または色を制御するように構成され得る。本明細書に説明されるように、いくつかの実施形態では、ユーザインタフェース等は、クロス層ＡＣＫ、クロスアプリケーションＡＣＫ、またはクロス層クロスアプリケーションＡＣＫを構成またはトリガすること可能にし得る。いくつかの実施形態では、使用されている能力、状況に基づく拒否、統合されたＡＣＫフレーム内のアプリケーションＡＣＫ数、または他の状態情報が、本明細書に議論されるように、クロス層ＡＣＫ、クロスアプリケーションＡＣＫ、またはクロス層クロスアプリケーションＡＣＫのために表示され得る。状態情報は、とりわけ、図６または図１Ｂと関連する手順等、手順のスループットに関する情報を含み得る。

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

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

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

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

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

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

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

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

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

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

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

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

Claims (1)

1. 明細書に記載された発明。

Images