JP2018057003A - スリーピノードをサポートするための近隣発見 - Google Patents

Abstract

【課題】スリーピノードをサポートする近隣発見の提供。【解決手段】多くのモノのインターネット（ＩｏＴ）は、「スリーピ」であり、従って時としてスリープモードになる。本明細書で使用されるようにノードの接続されたネットワーク内のノードは、ネットワーク内の他のノードがスリーピであることを決定し得る。さらに例えばエンドポイントデバイスおよびルータ等のノードは、それらの近隣ノードの到達可能性状態に基づいてネットワーク内のパケットを処理し得る。一実施形態において、方法は第１のノードにおいて、第２のノードを目標とするパケットを受信することと第２のノードがスリーピノードであることを決定することであって、スリーピノードは、低電力状態になり第１のノードとの通信を一時停止するように構成されていることと、第２のノードの到達可能性状態を決定することと、決定された到達可能性状態に基づいてパケットを処理することとを含む。【選択図】図１０

Description

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

モノのインターネット（ＩｏＴ）とは、概して、モノをインターネットに相互接続する、大域的なインフラストラクチャを指す。ＩｏＴ内のモノとは、ネットワーク接続を介してアクセス可能である、一意に識別可能な物理的なモノまたは仮想のモノを指し得る。そのようなモノは、知的インターフェースを通して情報ネットワークに組み込まれ得る。ＩｏＴシステムとは、モノのインターネット内の任意のシステムを指し得る。ＩｏＴシステムは、例えば、フロントエンドと称され得る、センサ等の１つ以上のエンドデバイスを含み得る。ＩｏＴシステムは、バックエンドと称され得る、他のネットワークへのゲートウェイを含み得る。多くのＩｏＴデバイスは、限定されたバッテリ電力、少ないメモリフットプリント、または低スループットリンクの少なくともある組み合わせを有する。加えて、これらのデバイスのうちの多くは、「スリーピ（ｓｌｅｅｐｙ）」であり、スリーピとは、デバイスがスリープモードになり得ることを意味する、。スリープモードとは、概して、電力を節約する低電力状態を指す。スリープモードであるとき、デバイスは、多くの場合、ネットワーク通信を一時停止する。デバイスは、スリープモードであった後に、起動して通信を再確立し得、したがって、ネットワーク通信の一時停止は、一時的であり得る。例えば、デバイスは、発生するイベントに応答して起動し得、またはデバイスは、事前構成された時間量が満了した後に起動させられ得る。

ＩｏＴエンドポイントデバイスおよびＩｏＴルータの両方が、スリーピであり得る。例示的ＩｏＴ実装が、図１に示されている。図１は、例えば、無線センサネットワーク（ＷＳＮ）等の例示的システム１００のブロック図である。システム１００は、本質的にマルチホップであり得、エンドポイントデバイスとして機能するバッテリ式ＩｏＴデバイスを含み得る。例えば、システム１００は、複数のＩｏＴデバイス１０２を含み得る。デバイス１０２は、エンドポイントデバイス１０４、またはパケットをエンドポイントデバイス１０４へ／から上流および下流に経路指定するルータデバイス１０６として機能し得る。ＩｏＴのスリーピノード（ｓｌｅｅｐｙ ｎｏｄｅ）をサポートすることへの既存のアプローチは、いくつかの欠点を有する。例えば、ノードは、多くの場合、ネットワーク内の他のノードがスリーピであるかどうかを認識しておらず、したがって、スリーピノードとネットワーク内で効率的および効果的に通信しない。

システム、方法、および装置の実施形態が、モノのインターネット（ＩｏＴ）等のネットワーク内のノードのスリープ認識に対して本明細書で説明される。一実施形態では、システムは、モノのインターネット（ＩｏＴ）を介して通信する複数のノードを備えている。複数のノードのうちの第１のノードは、複数のノードのうちの第２のノードがスリーピノードであることを決定し得る。スリーピノードは、低電力状態になり、第１のノードとの通信を一時停止するように構成される。第１のノードはまた、スリーピノードに対応する、種々のスリープ変数を決定し得る。スリープ変数は、第１のノードが第２のノードと通信すること、または代りのノードと通信することを可能にし得る。複数のノードは、エンドポイントデバイスと、少なくとも１つのルータとを備えている。ルータは、スリーピノードとして構成され得、および／またはエンドポイントデバイスは、スリーピノードとして構成され得る。

１つの例示的実施形態では、ネットワークを介して互に通信する複数のノードのうちの第１のノードは、複数のノードのうちの第２のノードを目標とするパケットを受信する。第１のノードは、第２のノードが、低電力状態になり、第１のノードとの通信を一時停止するように構成されているスリーピノードであることを決定し得る。第１のノードは、第２のノードの到達可能性状態を決定し、決定された到達可能性状態に基づいて、パケットを処理する。第１のノードは、第２のノードのスリーピ属性を示す１つ以上のスリーピノードの変数を含む要請メッセージを受信し得る。例えば、第２のノードがスリープしており、したがって、決定された到達可能性状態がスリープ状態であるときに、第１のノードは、スリーピノードの変数のうちの１つで特定されている持続時間の間、パケットを記憶し得る。持続時間が経過したとき、第１のノードは、パケットを第２のノードに送信し得る。代替として、決定された到達可能性状態がスリープ状態であるとき、第１のノードは、パケットを送信したノードにアラートを送信し得る。アラートは、第２のノードが起動する前に残っているスリープ時間を含み得る。別の実施形態によると、決定された到達可能性状態がスリープ状態であるとき、第１のノードは、スリーピノードの変数のうちの１つによって特定されているリダイレクトノードにパケットを送信し得る。リダイレクトノードは、第２のノードのためのプロキシ、または第２のノードと機能的に同等のものであり得る。

本概要は、発明を実施するための形態において以下でさらに説明される、簡略化形態の概念の選択を導入するように提供される。本概要は、請求された主題の主要な特徴または不可欠な特徴を識別することを目的としておらず、また、請求された主題の範囲を限定するために使用されることも目的としていない。さらに、請求された主題は、本開示の任意の部分で記述されるいずれかまたは全ての不利点を解決する制限に限定されない。
本発明はさらに、例えば、以下を提供する。
（項目１）
ネットワークを介して互に通信する複数のノードを備えているシステムで、前記複数のノードのうちの第１のノードにおいて、
前記複数のノードのうちの第２のノードを目標とするパケットを受信することと、
前記第２のノードがスリーピノードであることを決定することであって、前記スリーピノードは、低電力状態になり、前記第１のノードとの通信を一時停止するように構成されている、ことと、
前記第２のノードの到達可能性状態を決定することと、
前記決定された到達可能性状態に基づいて、前記パケットを処理することと
を含む、方法。
（項目２）
前記方法は、前記第２のノードのスリーピ属性を示す１つ以上のスリーピノードの変数を含む要請メッセージを受信することをさらに含む、項目１に記載の方法。
（項目３）
前記決定された到達可能性状態は、スリープ状態であり、前記方法は、
前記スリーピノードの変数のうちの１つで特定されている持続時間の間、前記パケットを記憶することと、
前記持続時間が経過すると、前記パケットを前記第２のノードに送信することと
をさらに含む、項目２に記載の方法。
（項目４）
前記決定された到達可能性状態は、スリープ状態であり、前記方法は、
前記パケットを送信したノードにアラートを送信することをさらに含み、前記アラートは、前記第２のノードが起動する前に残っているスリープ時間を含む、項目２に記載の方法。
（項目５）
前記決定された到達可能性状態は、スリープ状態であり、前記方法は、
前記スリーピノードの変数のうちの１つによって特定されているリダイレクトノードに前記パケットを送信することをさらに含み、前記リダイレクトノードは、前記第２のノードのためのプロキシ、または前記第２のノードと機能的に同等のもののうちの少なくとも１つである、項目２に記載の方法。
（項目６）
前記決定された到達可能性状態は、スリープ状態であり、前記方法は、
前記パケットを送信したノードにリダイレクトメッセージを送信することをさらに含み、前記リダイレクトメッセージは、リダイレクトノードのアドレスを示す前記スリーピノードの変数のうちの１つを含み、前記リダイレクトノードは、前記第２のノードのためのプロキシ、または前記第２のノードと機能的に同等のもののうちの少なくとも１つである、項目２に記載の方法。
（項目７）
前記方法は、
前記第２のノードに関連付けられている近隣キャッシュエントリに前記第２のノードの前記到達可能性状態を記憶することと、
前記決定された到達可能性状態が到達不可能な状態であるとき、前記第２のノードに関連付けられている前記近隣キャッシュエントリを除去することと
をさらに含む、項目１に記載の方法。
（項目８）
前記方法は、前記第１のノードのスリーピ属性を示す１つ以上のスリーピノードの変数を含む広告メッセージを生成することをさらに含む、項目１に記載の方法。
（項目９）
前記スリーピ属性は、前記第１のノードに関連付けられているスリープパターン、前記第１のノードに関連付けられているデューティサイクル、および前記第２のノードのスリープ状態が変化するときに前記第１のノードが通知されるという要件のうちの少なくとも１つを含む、項目８に記載の方法。
（項目１０）
接続されたノードのネットワーク内の第１のネットワークノードであって、前記第１のネットワークノードは、
コンピュータ読み取り可能命令を実行するように適合されている第１のプロセッサと、
前記第１のプロセッサに通信可能に連結されている第１のメモリと
を備え、
前記第１のメモリは、コンピュータ読み取り可能命令を記憶しており、前記命令は、前記第１のプロセッサによって実行されると、
前記接続されたノードのネットワーク内の第２のネットワークを目標とするパケットを受信することと、
前記第２のネットワークがスリーピノードであることを決定することであって、前記スリーピノードは、低電力状態になり、前記第１のノードとの通信を一時停止するように構成されている、ことと、
前記第２のネットワークノードの到達可能性状態を決定することと、
前記決定された到達可能性状態に基づいて、前記パケットを処理することと
を含む動作を前記プロセッサに行わせる、第１のネットワークノード。
（項目１１）
前記動作は、前記第２のネットワークノードのスリーピ属性を示す１つ以上のスリーピノードの変数を含む要請メッセージを受信することをさらに含む、項目１０に記載の第１のネットワークノード。
（項目１２）
前記決定された到達可能性状態は、スリープ状態であり、前記動作は、
前記スリーピノードの変数のうちの１つで特定されている持続時間の間、前記パケットを記憶することと、
前記持続時間が経過すると、前記パケットを前記第２のネットワークノードに送信することと
をさらに含む、項目１１に記載の第１のネットワークノード。
（項目１３）
前記決定された到達可能性状態は、スリープ状態であり、前記動作は、
前記接続されたノードのネットワーク内の前記パケットを送信したノードにアラートを送信することをさらに含み、前記アラートは、前記第２のネットワークノードが起動する前に残っているスリープ時間を含む、項目１１に記載の第１のネットワークノード。
（項目１４）
前記決定された到達可能性状態は、スリープ状態であり、前記動作は、
前記パケットを前記接続されたノードのネットワーク内のリダイレクトノードに送信することをさらに含み、前記リダイレクトノードは、前記スリーピノードの変数のうちの１つによって特定され、前記リダイレクトノードは、前記第２のネットワークノードのためのプロキシ、または前記第２のネットワークノードと機能的に同等のもののうちの少なくとも１つである、項目１１に記載の第１のネットワークノード。
（項目１５）
前記決定された到達可能性状態は、スリープ状態であり、前記動作は、
前記接続されたノードのネットワーク内の前記パケットを送信したノードにリダイレク
トメッセージを送信することをさらに含み、前記リダイレクトメッセージは、前記接続されたノードのネットワーク内のリダイレクトノードのアドレスを示す前記スリーピノードの変数のうちの１つを含み、前記リダイレクトノードは、前記第２のネットワークノードのためのプロキシ、または前記第２のネットワークノードと機能的に同等のもののうちの少なくとも１つである、項目１１に記載の第１のネットワークノード。
（項目１６）
前記動作は、
前記第２のネットワークノードに関連付けられている近隣キャッシュエントリに前記第２のネットワークノードの前記到達可能性状態を記憶することと、
前記決定された到達可能性状態が到達不可能な状態であるとき、前記第２のネットワークノードに関連付けられている前記近隣キャッシュエントリを除去することと
をさらに含む、項目１０に記載の第１のネットワークノード。
（項目１７）
前記動作は、前記第１のネットワークノードのスリーピ属性を示す１つ以上のスリーピノードの変数を含む広告メッセージを生成することをさらに含む、項目１０に記載の第１のネットワークノード。
（項目１８）
前記スリーピ属性は、前記第１のネットワークノードに関連付けられているスリープパターン、前記第１のネットワークノードに関連付けられているデューティサイクル、または前記第２のネットワークノードのスリープ状態が変化するときに前記第１のネットワークノードが通知されるという要件のうちの少なくとも１つを含む、項目１７に記載の第１のネットワークノード。

添付の図面と併せて一例として挙げられる、以下の説明から、より詳細に理解され得る。
図１は、モノのインターネット（ＩｏＴ）を介して互に通信する、ＩｏＴのスリーピエンドポイントデバイスおよびＩｏＴのスリーピルータを含む、実施例のブロック図である。 図２Ａは、近隣発見（ＮＤ）メッセージプロトコルに関係付けられる例示的非効率性を示す。 図２Ｂは、ＮＤメッセージプロトコルに関係付けられる別の例示的非効率性を示す。 図３は、インターネット制御管理プロトコル（ＩＣＭＰ）ヘッダ形式の実施例を示す。 図４は、ＮＤメッセージのタイプ・長さ・値（ＴＬＶ）形式の実施例を示す。 図５は、例示的実施形態による、例示的ノードの種々の到達可能性状態を示す状態図である。 図６は、例示的実施形態による、拡張されたスリーピノードのＮＤ次期ホップ決定のフロー図である。 図７は、そのデフォルトルータに登録するスリーピノードを示し、スリーピノードの変数は、例示的実施形態に従って登録に含まれている、。 図８は、例示的実施形態による、ルータに問い合わせを行うための呼び出しフローを示す。 図９Ａは、いくつかの実施形態による、ノード間で交換することができるメッセージを示す。 図９Ｂは、いくつかの他の実施形態による、ノード間で交換することができるノードを構成するためのメッセージを示す。 図１０は、例示的実施形態による、ネットワーク内のスリーピノードへの要求の記憶および転送を図示する、呼び出しフローである。 図１１は、例示的実施形態による、スリーピノードの変数および／または状態を要求ノードに知らせるための呼び出しフローである。 図１２は、例示的実施形態による、パケットのスリープ認識リダイレクトのための呼び出しフローである。 図１３Ａは、１つ以上の開示された実施形態が実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）またはモノのインターネット（ＩｏＴ）通信システムの系統図である。 図１３Ｂは、図１３Ａで図示されるＭ２Ｍ／ＩｏＴ通信システム内で使用され得る、例示的アーキテクチャの系統図である。 図１３Ｃは、図１３Ａで図示される通信システム内で使用され得る、例示的Ｍ２Ｍ／ＩｏＴ端末またはゲートウェイデバイスの系統図である。 図１３Ｄは、図１３Ａの通信システムの側面が具現化され得る、例示的コンピュータシステムのブロック図である。

本明細書で使用される場合、モノのインターネット（ＩｏＴ）とは、ＩｏＴノードまたはモノをインターネットに相互接続する、インターネットプロトコル（ＩＰ）ベースのインフラストラクチャを指す。本明細書で使用される場合、ＩｏＴという用語は、デバイスが互に通信することができる、任意のネットワークを指し得、したがって、ＩｏＴはまた、ＩｏＴシステムまたはマシンツーマシン（Ｍ２Ｍ）通信システムと称され得る。ＩｏＴシステムは、ＩｏＴモノ、ＩｏＴエンティティ、ＩｏＴサービス、ＩｏＴアプリケーション等から成り得る。デバイス、アプリケーション、サービス等は、多くの場合、本明細書では「ＩｏＴ」デバイス、アプリケーション、サービス等と称されるが、「ＩｏＴ」修飾子は、一例として提示され、限定として提示されないことが理解されるであろう。例えば、ＩｏＴモノまたはノードとは、ネットワーク接続を介してアクセス可能である、一意に識別可能な物理的なモノまたは仮想のモノを指す。したがって、ＩｏＴノードは、ＩｏＴと称され得るネットワークを介して通信する、ホスト、ルータ、または任意の他のデバイスであり得る。本明細書で使用される場合、ＩｏＴホストとは、ルータではないＩｏＴノード（例えば、エンドポイントデバイス）を指し得る。ＩｏＴルータとは、パケットがアドレス指定される別のＩｏＴルータまたはＩｏＴホストにＩＰパケットを転送するＩｏＴノードを指す。本明細書で使用される場合、スリーピノードまたはスリープノードという用語は、モノのインターネット（ＩｏＴ）のスリーピエンドポイントデバイスまたはＩｏＴのスリーピルータを指し得る。「スリーピ（ｓｌｅｅｐｙ）」という用語またはその派生語は、ノードが電力を節約するスリープモードになることが可能であることを示唆する。したがって、ＩｏＴのスリーピノードは、スリープし得、これは、低電力状態、例えば、電力を節約する無電力状態を指す。スリープしている間に、ＩｏＴノードは、起動してネットワーク通信を再確立するまで、一時的にネットワーク通信を一時停止し得る。

低電力無線パーソナルエリアネットワークを経由したインターネットプロトコルバージョン６（ＩＰｖ６）（６ＬｏＷＰＡＮ）は、リソース制約（例えば、ＩｏＴ）デバイスに好適である、ＩＰｖ６ネットワーキングプロトコルのバージョンである。６ＬｏＷＰＡＮ近隣発見変更要求（ＲＦＣ）６７７５は、６ＬｏＷＰＡＮベースのネットワークでの使用を目標にしたＩＰｖ６近隣発見のバージョンである。低電力および損失性ネットワークのためのＩｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ（ＩＥＴＦ）ＩＰｖ６ルーティングプロトコル（ＲＰＬ）は、例えば、無線センサネットワーク（ＷＳＮ）等のＩｏＴネットワークに好適な軽量ＩＰｖ６ルーティングプロトコルである。ＩＥＴＦ ＣｏＡＰは、軽量ＲＥＳＴｆｕｌアプリケーション／トランスポートプロトコルである。本明細書では、前述のプロトコルが、多くの場合、ノードがスリーピであるかどうかを認識することなく実装されることが認識される。さらに、前述のプロトコルは、多くの場合、スリーピノードのスリープ属性またはスリーピノードのスリープ状態の知識を有することなく実装される。

ネットワークノード（例えば、ホストおよびルータ）は、近隣のリンク層アドレスを決定するため、および無効になるキャッシュされた値をパージするために、ＩＰｖ６近隣発見（ＮＤ）を使用し得る。近隣ノードとは、互に直接通信し得るノードを指し、それらの間にいかなる中間ノードも存在しない。ホスト（例えば、エンドポイントデバイス）は、それらの代わりにパケットを転送することができる近隣ルータを見出すために、ＩＰｖ６
ＮＤを実装し得る。さらに、ノードは、どの近隣が到達可能であり、どれが到達可能ではないかを能動的に記録するため、および変更されたリンク層アドレスを検出するために、ＩＰｖ６ ＮＤプロトコルを使用し得る。例えば、ルータまたはルータへの経路が故障したとき、ホストは、機能する代りのものを能動的に検索し得る。以下は、一例として提示される、個々のＩＰｖ６ ＮＤプロトコル特徴の概要である。

ＩＰｖ６ ＮＤプロトコルは、５つの異なるインターネット制御管理プロトコル（ＩＣＭＰ）パケットタイプを定義する。パケットタイプは、例えば、ＩＰｖ４ ＩＣＭＰ ＲＦＣ ７９２およびＩＰｖ６ ＩＣＭＰ ＲＦＣ ４４４３で説明されている。説明されたパケットタイプは、ルータ要請（ｓｏｌｉｃｉｔａｔｉｏｎ）、ルータ広告、近隣要請、近隣広告、およびリダイレクトを含む。ルータ要請パケットは、インターフェースが有効にされたときに送信され得る。例えば、インターフェースが有効にされたとき、ホストは、予定された時間を待つよりもむしろ、即時にルータ広告を生成するようにルータに要求する、ルータ要請を送信し得る。ルータ広告パケット時間とは、ルータが種々のリンクおよびインターネットパラメータでそれらの存在を広告する、シナリオを指す。広告は、周期的であり得るか、またはルータ要請メッセージに応答し得る。ルータ広告は、別のアドレスが同一のリンクを共有するかどうかを決定する（オンリンク決定）ために使用される、プレフィックスを含み得る。ルータ広告プレフィックスはさらに、アドレス構成、提案ホップ制限値等を示す、プレフィックスを含み得る。近隣要請パケットは、近隣のリンク層アドレスを決定するために、またはキャッシュされたリンク層アドレスを介して近隣が依然として到達可能であることを検証するために、ノードによって送信され得る。近隣要請はまた、重複アドレス検出に使用され得る。近隣広告パケットは、近隣要請メッセージに応答して送信され得る。ノードはまた、リンク層アドレス変更を発表するために、要請なしに（ｕｎｓｏｌｉｃｉｔｅｄ）近隣広告を送信し得る。リダイレクトパケットは、特定の宛先のためのより良好な第１のホップをホストに知らせるために、ルータによって使用され得る。

ＩＰｖ６ ＮＤはまた、ノードによって維持され得る、種々のデータ構造も定義する。定義されたデータ構造は、近隣キャッシュ、宛先キャッシュ、プレフィックスリスト、デフォルトルータリスト、およびノード構成変数を含む。トラフィックが最近送信された近隣のエントリのセットを維持するために、近隣キャッシュデータ構造が使用され得る。エントリは、例えば、近隣のリンク層アドレス、近隣がルータまたはホストであるかどうか、アドレス解決が完了することを待つ任意の待ち行列型パケットへのポインタ、到達可能性状態等の情報を記憶するために使用される。トラフィックが最近送信された宛先についてのエントリのセットを維持するために、宛先キャッシュデータ構造が使用され得る。エントリは、宛先ＩＰアドレスを次期ホップ近隣のＩＰアドレスにマップする。エントリは、リダイレクトメッセージから習得される情報を用いて更新される。プレフィックスリストデータ構造は、オンリンクであるアドレスのセットを定義する、プレフィックスのリストを含み得る。デフォルトルータリストデータ構造は、ルータ要請中に発見されるルータのリストを含み得る。ルータのリストは、ノードがパケットを転送し得る、ルータを表し得る。ノード構成変数は、ノードの構成に使用される変数のセットを表し得る。

ＩＰｖ６ ＮＤはまた、もはや到達可能ではない近隣ノードにパケットを送信することに関連付けられる失敗を検出することをサポートし、かつパケットが転送されることができる次期ホップを決定することをサポートする、近隣不到達可能性検出および次期ホップ決定アルゴリズムも定義する。ＲＦＣ ４８６１は、例えば、６ＬｏＷＰＡＮベースのネットワーク等の低電力および損失性ネットワーク向けであるＩＰｖ６ ＮＤの強化を導入する。ＲＦＣ ４８６１によって提案される例示的強化は、以下を含む：ホストのためのマルチキャストベースのアドレス解決動作の排除、スリープしているホストに適応する（ルータ開始型の代わりに）ホスト開始型相互作用、新しいアドレス登録オプション（ＡＲＯ）拡張の定義、６ＬｏＷＰＡＮヘッダ圧縮コンテキストをホストに分配するための近隣発見オプション、プレフィックスおよび６ＬｏＷＰＡＮヘッダのマルチホップ分配、および２つの新しいＩＣＭＰｖ６メッセージタイプを使用するマルチホップ重複アドレス検出（ＤＡＤ）。ＲＦＣ ４８６１はさらに、ホストが、特定の登録寿命で、それらのアドレスをルータに登録することを可能にすることを提案する。例えば、ルータは、近隣要請（ＮＳ）および近隣広告（ＮＡ）メッセージを使用して、アドレス解決を行う必要がないこともある。登録寿命はまた、近隣不到達可能性検出アルゴリズムを強化するために使用され得る。

上で説明されるプロトコル等の既存のインターネットプロトコルは、例えば、スリーピノードのためのサポートを欠く。例えば、既存のプロトコルは、多くの場合、スリーピノードが完全に給電されたままであり、常にネットワーク接続を維持することを仮定する。ＩｏＴタイプデバイスは、多くの場合、元来、リソースが制約されている。したがって、場合によっては、ＩｏＴデバイスは、バッテリ式であり得、少なくともいくらか、例えば、大部分の時間で、スリープし得る。

ＩＰｖ６近隣発見（ＮＤ）プロトコルは、スリーピＩｏＴノード（例えば、スリーピエンドポイントデバイスおよびスリーピルータ）のためのサポートを欠く例示的プロトコルである。場合によっては、現在のプロトコルは、ＩｏＴノードの機能性の認識を欠く。本明細書で使用される場合、スリープ認識とは、概して、ノードのスリープ能力およびスリープ属性の知識を指す。例えば、ＩＰｖ６ ＮＤプロトコルは、ＩｏＴノードがスリープするかどうか、ＩｏＴノードの現在のスリープ状態（例えば、起動対スリープ）、ＩｏＴノードのスリープ持続時間、ＩｏＴのスリーピノードが周期的に（例えば、定義されたスリープスケジュール／パターンに基づいて）起動し、スリープするか、または非周期的に（例えば、イベントベース）起動し、スリープするか等の認識を欠くことによって、スリープ認識を欠く。ノードまたはプロトコルは、上記で一例として提示される属性のうちのいずれか、または上記で一例として提示されないスリープに関連付けられる他の属性の認識を欠くことによって、スリープ認識を欠き得ることが理解されるであろう。

上で説明されるように、６ＬｏＷＰＡＮ ＮＤは、スリーピノードのＮＤ登録寿命を特定するために、アドレス登録オプション（ＡＲＯ）を含む近隣要請メッセージを使用して、スリーピノードが１つ以上のデフォルトルータに登録することを可能にする特徴を定義するが、ここでは、既存のプロトコルが、この特徴をスリーピノードまたはその近隣のために有用にするようにをそれを効果的にサポートしていないことが認識される。

図２Ａおよび２Ｂを参照すると、例えば、デバイス１０２のうちの１つ等のスリーピノードのデューティサイクル２０２が描写されている。示されるように、デューティサイクル２０２は、ノードが起動したままである期間（例えば、起動期間２０６）と、スリープ期間２０８と称され得る、ノードがスリープしている期間とを含む。ＮＤ登録寿命は、例えば、ノードのスリープパターンが本質的に周期的である場合、寿命がスリーピノードのデューティサイクル２０２と調整されるように構成され得る。例示的メッセージ形式２００ａおよび２００ｂが、それぞれ、図２Ａおよび２Ｂに示されている。図２Ａを参照すると、ＮＤ登録寿命２０４ａは、起動期間２０６に合致する持続時間を定義する。図２Ｂを参照すると、ＮＤ登録寿命２０４ｂは、ノードのデューティサイクル２０２に等しい持続時間を定義する。

図２Ａおよび２Ｂに示される実装の両方は、ＮＤプロトコルの観点から問題があり得る。ＮＤ登録寿命２０４ａおよび２０４ｂの開始時に、ノードは、デフォルトルータがメッセージパケットをノードへ送信する／ノードから受信するように、デフォルトルータに登録する。ＮＤ登録寿命２０４ａおよび２０４ｂが満了すると、デフォルトルータがもはやメッセージをノードへ送信しないように／ノードから受信しないように、デフォルトルータは、ノードの近隣キャッシュエントリを削除し得る。したがって、図２Ａを参照すると、スリーピノードのＮＤ登録は、ノードがスリープするときに満了し、これは、デフォルトルータに、その近隣キャッシュからスリーピノードの近隣キャッシュエントリを削除させ得る。その後、スリーピノードが起動してデフォルトルータに再登録するまで、スリーピノードを目標にする、デフォルトルータに到達する任意のパケットが、ルータによってドロップされ得る。図２Ｂを参照すると、ＮＤ登録寿命２０４ｂは、スリーピノードのデューティサイクル２０２に等しい持続時間を定義する。したがって、登録は、ノードが起動してそのデフォルトルータに再登録するたびに、スリーピノードによって更新される。結果として、ルータは、スリーピノードのための近隣キャッシュエントリを保存し得る。しかしながら、場合によっては、ルータは、スリーピノードがスリープする場合およびときを決定することができない場合がある。したがって、ルータは、ノードがスリープしているときに、パケットをスリーピノードに転送し、リンク層リソースの非効率的な使用をもたらし得る。ネットワーク帯域幅が無駄にされ得、スリープしているノードにパケットを不必要に送信することによって、輻輳が引き起こされ得るため、リソースが非効率的に使用され得る。さらに、ノードが起動するまでメッセージが待ち行列に入れられ得るため、リンク層バッファの使用は、非効率的であり得る。図２Ａおよび２Ｂを参照して説明される実施例によって図示されるように、ルータはまた、もはやネットワーク内に存在しないノードを指し得るもはや到達可能ではないノードと、スリープしているノードとを効果的に区別することができない場合がある。ここでは、そのような区別を決定できないことが、ルータが付加価値のあるスリープ認識パケット処理機能性をサポートすることを妨げ得ることが認識される。

一例として、図２Ａおよび２Ｂを参照して説明されるように、上記で識別される例示的問題のうちのいくつかをさらに悪化させることには、いくつかのノードは、非周期的および／または予測不可能にスリープおよび／または起動し得、したがって、スリーピノードが、そのＮＤ登録寿命をそのスリープスケジュール／パターンと相関させる機会がない場合がある。上で説明されるように、ＩＰｖ６および６ＬｏＷＰＡＮ ＮＤプロトコルによるスリープ認識の欠如は、ＮＤプロトコルがスリーピノードを有するＩｏＴネットワークで使用された場合、非効率性をもたらし得る。さらに、スリープ認識を欠く通信プロトコルを使用するネットワークは、これらのネットワークがスリープ認識機能性をサポートすることを妨げ得る。

本明細書で説明される種々の実施形態は、少なくとも上で説明される問題に対処する。例示的実施形態では、ＩＰｖ６および６ＬｏＷＰＡＮ近隣発見（ＮＤ）プロトコルに対する拡張が、スリーピＩｏＴノードをサポートする。例えば、例示的実施形態によると、ノードによってサポートされるスリーピ機能性を発見するために、ＮＤのスリーピノードの変数が問い合わせされることができる。ノードに関連付けられるスリーピノードの変数は、そのノードのスリーピパラメータを示す。一例として、スリーピノードの変数は、本明細書で説明されるように、要請メッセージまたは広告メッセージに含まれ得る。そのような変数は、ノードのスリープ関連機能性を制御または修正するように構成され得る。以下で説明されるように、種々の実施形態は、ノード間で送信されるスリーピノード情報に関連付けられる種々のメッセージをサポートするために、近隣要請、近隣広告、ルータ要請、ルータ広告、およびリダイレクトＩＣＭＰ ＮＤメッセージタイプに対する拡張を実装する。例示的メッセージは、クエリメッセージ、交換メッセージ、構成メッセージ、加入メッセージ、および通知メッセージを含む。さらなる一例として、本明細書で説明される実施形態は、スリーピノードへのパケットの配信失敗の報告をサポートするメッセージを実装する。種々の実施形態はさらに、ネットワーク内の近隣ＩｏＴノードのためのスリーピノードのコンテキスト情報のローカル記憶をサポートするために、ＩｏＴノードの近隣キャッシュ、宛先キャッシュ、およびデフォルトルータリストエントリに対する拡張を実装する。依然としてさらに、実施形態は、スリープ認識、および到達不可能なノードと比較してスリーピノードの区別をサポートするために、次期ホップ決定および近隣不到達可能性検出機構に対する拡張を実装し得る。そのような実施形態は、これらのノードが予測不可能なスリープスケジュール／パターンを有するかどうかにかかわらず、スリーピノードとの効率的な相互作用を可能にし得る。

以下でさらに説明されるように、ＮＤのスリーピノードメッセージングのための例示的拡張は、種々の機能性を有効にすることに役立ち得る。１つの例示的実施形態では、ルータは、スリーピノードのコンテキスト情報に基づいて要請され得る。例えば、ノードは、特定のルータ、例えば、非スリーピルータ、またはある時間量より長く非スリーピルータ等を発見し得る。別の例示的実施形態では、スリーピノードのコンテキスト情報は、ノードがスリープ認識決定を行うことができるように、ネットワークノード間で広告され得る。例示的スリープ認識決定は、限定ではないが、一例として提示される、スリープ認識メッセージルーティング、スリープ認識メッセージ転送等を含む。さらに別の実施形態では、スリープノードの１つ以上のスリープパラメータは、ネットワーク内の他のノードによって構成され得る。そのような構成は、異なるノードのスリープスケジュールを互に調整し得る。以下でさらに説明されるように、種々の実施形態によると、パケットは、１つのノードによって処理され、スリープ認識様式で１つ以上の近隣ノードに転送され得、それによって、近隣ノードは、スリープ認識決定をすることができる。スリープ認識決定の実施例は、ノードが起動している場合、パケットを記憶して転送するための決定、パケットをスリープしているノードと機能的に同等であるか、またはスリープしているノードのためのプロキシであるノードに転送するための決定、送信側がパケットを、スリーピノードと機能的に同等のノードまたはプロキシノードであるノードに再送信するように、送信側をリダイレクトするための決定、パケットをドロップし、宛先ノードが現在スリープしていることを送信側に通知するための決定等を含む。

ＩＰｖ６および６ＬｏＷＰＡＮ ＮＤプロトコルは、ノードがサポートする機能性を発見するために問い合わせされることができるノード変数のセットを説明する。いくつかの変数は、ノードの挙動を制御または修正するように構成され得る。表１を参照して、例示的実施形態によると、ノードに関連付けられるスリープ属性を発見するために、種々の変数を問い合わせることができる。そのような変数は、スリーピノードのＮＤ変数と称され得る。本明細書で説明されるようなスリーピノードの変数は、変数が関連付けられるスリーピノードによってローカルで、またはネットワーク内の他のノードによって遠隔で構成されることができる。例えば、ＮＤ機能性を使用して、スリーピノードの変数のローカル構成が行われ得る。代替として、スリーピノードの変数は、ＮＤプロトコルと、スリーピノード上でホストされる他のプロトコルまたはアプリケーション（例えば、ＭＡＣ層プロトコル、ＣｏＡＰ層プロトコル、アプリケーション等）との間にあるインターフェースを介して、ローカルで構成され得る。本明細書で説明されるＮＤメッセージ拡張を使用して、スリーピノードの変数の遠隔構成が行われ得る。

時間ベースである、スリーピノードの変数、例えば、表１に示されるＴｉｍｅＢｅｆｏｒｅＮｅｘｔＳｌｅｅｐ変数は、ノード間で把握され、ＮＤプロトコルによってサポートされる共有時間基準点に関して定義されることができる。例えば、ノードがそのデフォルトルータに登録するたびに確立され得る、ＮＤ登録寿命窓の開始が、時間の共通基準点として使用され得、したがって、相対的なスリーピノードの持続時間は、登録寿命窓の開始に基づき得る。例示的なスリーピノードの変数を示す、以下の表１を参照すると、ＴｉｍｅＢｅｆｏｒｅＮｅｘｔＳｌｅｅｐ＝２の設定は、ＩｏＴノードが、ＮＤ登録寿命窓の開始後２秒でスリープするであろうことを意味する。表１は、一例として提示される、スリーピノードの変数を含む。追加のスリーピノードの変数は、所望に応じて本明細書で説明される実施形態によって実装され得ることが理解されるであろう。

ＩＰｖ６および６ＬｏＷＰＡＮ ＮＤプロトコルは、近隣キャッシュデータ構造を定義する。近隣キャッシュは、近隣ノードについての情報を含む近隣ノードに関連付けられるエントリを記憶する。以下で説明される例示的実施形態では、強化型近隣キャッシュが、近隣のスリーピノードに関連付けられるコンテキスト情報を記憶して管理する。説明された近隣キャッシュはさらに、例えば、表１に記載される変数等の近隣のスリーピノードの変数を記憶することをサポートする。例えば、近隣キャッシュエントリは、本明細書で説明されるこれらの特徴等の異なるタイプのスリープ認識ＮＤ特徴をサポートするために使用され得る、近隣ノードのスリープ能力およびスリープ状態を記録するために使用され得る。別の例示的実施形態では、スリープ状態は、サポートされた近隣キャッシュエントリ状態である。スリープ状態を使用して、ＩＰｖ６および６ＬｏＷＰＡＮ ＮＤ近隣不到達可能性検出機構に対する拡張が、以下で説明される種々の実施形態に従って実装され得る。

ＩＰｖ６および６ＬｏＷＰＡＮ ＮＤプロトコルはまた、宛先キャッシュデータ構造も定義する。宛先キャッシュに記憶されたエントリは、宛先ＩＰアドレスを次期ホップ近隣のＩＰアドレスにマップする。追加の情報もまた、宛先キャッシュエントリに記憶され得る。例示的実施形態では、強化型宛先キャッシュ構造は、近隣のスリーピノードの変数（例えば、表１に記載される変数）が宛先キャッシュに記憶されることを可能にする。したがって、宛先キャッシュエントリの使用は、スリーピノードの変数によって使用される情報によって適格にされ得る。

ＩＰｖ６および６ＬｏＷＰＡＮ ＮＤプロトコルはまた、デフォルトルータリストデータ構造も定義する。デフォルトルータリストは、ルータ要請を送信し、対応するルータ広告を受信することによって、ノードが発見し得る、利用可能なルータのリストを維持し得る。このリスト内の各エントリは、例えば、ルータのＩＰアドレス等のルータに関連付けられる情報を含む。追加の情報もまた、デフォルトルータリストエントリに記憶され得る。例示的実施形態によると、ルータに関連付けられる、表１で描写されるスリーピノードの変数等のスリーピノードの変数が、デフォルトルータリストのエントリに記憶される。したがって、デフォルトルータリストエントリの使用は、スリーピノードの変数によって示される情報によって適格にされ得る。

ＩＰｖ６および６ＬｏＷＰＡＮ ＮＤプロトコルは、ＩＣＭＰメッセージタイプのセットを定義する。ＩＣＭＰメッセージは、ＩＰパケットのペイロードで搬送される。ＩＣＭＰメッセージは、ＩＰｖ４ ＩＣＭＰ ＲＦＣ ７９２およびＩＰｖ６ ＩＣＭＰ ＲＦＣ ４４４３で説明されるように、８バイトヘッダおよび可変サイズのデータペイロードを有する。例示的ＩＣＭＰメッセージ３００が、図３で描写されている。図３を参照すると、ＩＣＭＰヘッダ３０２の第１の４バイトが、ＩＣＭＰメッセージタイプにわたって一貫している一方で、ヘッダ３０２の第２の４バイトは、ＩＣＭＰメッセージ３００のタイプに基づいて変動し得る。示されるように、ＩＣＭＰタイプフィールド３０４が、ＩＣＭＰメッセージ３００のタイプを特定するために使用される。コードフィールド３０６が、ＩＣＭＰメッセージ３００のサブタイプを示すために使用される。チェックサムフィールド３０８が、エラーチェックに使用され、ＩＣＭＰメッセージ３００のヘッダ３０２およびペイロード３１０にわたって計算されるチェックサムを含む。本明細書で説明される例示的実施形態では、ＩＰｖ６および６ＬｏＷＰＡＮ ＮＤプロトコルによって使用されるＩＣＭＰメッセージタイプのセットは、以下のサブセクションで定義されるスリーピノードのＮＤ ＩＣＭＰメッセージ拡張の各々が、以下の実装のうちの１つ以上のものによって実装されるように、拡張される。

１つの例示的実装では、ＩＣＭＰメッセージタイプは、Ｉｎｔｅｒｎｅｔ Ａｓｓｉｇｎｅｄ Ｎｕｍｂｅｒｓ Ａｕｔｈｏｒｉｔｙ（ＩＡＮＡ）レジストリに関する４２〜２５５の範囲内のＩＣＭＰメッセージタイプを留保することによって定義される。例示的ＩＣＭＰメッセージは、（例えば、コードフィールド３０６を使用する）１つ以上のサブタイプ、（例えば、ＩＣＭＰ８バイトヘッダの上位４バイトを使用する）メッセージ特有のヘッダの４バイト、およびメッセージに合わせられることができる値および長さを伴うデータペイロード３１０をサポートし得る。例えば、これらのサブタイプを使用して、ヘッダの４バイト、およびデータペイロード、スリーピノードの関連情報が、メッセージ３００で搬送されることができる。例えば、種々のＩＣＭＰメッセージタイプが定義しされ、スリーピノードのコンテキスト情報を交換するため、スリーピノードのパラメータ（変数）を構成するため、ノードがスリーピノードの状態の変化を通知されるように、スリーピノードに加入するため、到達不可能なスリーピノードを報告するために使用されることができる。

新しいＩＣＭＰメッセージタイプを定義することへの代替的実装では、別の実施形態によると、ＩＣＭＰサブタイプが、既存のＩＣＭＰメッセージタイプ（例えば、既存のＮＤ
ＩＣＭＰメッセージタイプ）のために定義される。本明細書で説明されるように、例示的ＩＣＭＰサブタイプは、スリーピノードをサポートし、ＩＡＮＡレジストリに関するそれぞれのメッセージのためのＩＣＭＰメッセージコードを留保することによって定義される。実施例では、各ＩＣＭＰメッセージは、最大で２５５個の異なるサブタイプをサポートし得る。例えば、宛先がスリープしているか、または宛先へのルーティング経路内の中間ノードのうちの１つがスリープしているため、宛先を到達不可能として示すことができるように、１つ以上の新しいサブタイプが、既存の宛先到達不可能ＩＣＭＰメッセージに追加され得る。

さらに別の代替的実装では、例示的実施形態によると、本明細書で説明されるスリープノードオプションがサポートされるように、ＮＤメッセージオプションタイプが定義される。図４を参照すると、ＩＰｖ６および６ＬｏＷＰＡＮ ＮＤプロトコルは、一般的なＴＬＶベースのパケット４００を定義し、それは、タイプ・長さ・値（ＴＬＶ）ベースのオプション４００とも称されることができ、例えば、メッセージ３００のペイロード３１０等のＩＣＭＰ ＮＤメッセージのペイロードに含まれることができる。各ＮＤメッセージは、ＮＤプロトコルによって定義されるそれぞれのオプションのセットをサポートする。ＩＰｖ４ ＩＣＭＰ ＲＦＣ ７９２およびＩＰｖ６ ＩＣＭＰ ＲＦＣ ４４４３によって定義されるようなＴＬＶベースのオプション４００の形式が、図４に示されている。図４を参照すると、タイプフィールド４０２は、８ビットの一意の識別子である。長さフィールド４０４は、バイト単位でＴＬＶパケット４００の長さを記憶する８ビットフィールドである。値フィールド４０６は、オプションタイプに依存し得る、可変長フィールドである。本明細書で説明される例示的実施形態によると、例示的なＮＤのスリーピノードオプションが、タイプフィールド４０２の一意の識別子を定義することによってサポートされる。長さおよび値は、各一意の識別子に対応し得る。例えば、表１に記載される、スリーピノードの変数の各々は、タイプフィールド４０２に対して対応するＮＤオプションタイプを定義することによって、ＮＤメッセージで搬送され得る。代替として、複数のスリーピノードの変数が、複数のスリーピノードの変数を搬送するための定義された構造を有する、単一のＮＤオプション内で搬送され得る。

一実施形態によると、ＮＤ ＩＣＭＰメッセージに対するＮＤクエリ拡張が、１つ以上の属性値ペアを含むＮＤ ＩＣＭＰメッセージ内のクエリ文字列を特定するために使用される。クエリ属性値ペアは、例えば、表１に記載されるこれらのリスト等のスリーピノードの変数に基づき得る。本明細書で説明される例示的クエリ拡張は、ルータ要請メッセージまたは近隣要請メッセージ内で使用されることにより、スリーピノードの要件の特定セットを満たす１つ以上の近隣ノードを見出すために、ＩｏＴノードが近隣ノードに問い合わせを行うことを可能にし得る。例えば、ルータが、クエリ文字列を伴うルータ要請ＮＤメッセージを受信すると、ルータは、ルータがルータ広告で返答するかどうかを決定するために文字列を使用し得る。この決定は、ルータの変数の状態に対して属性値ペアを比較することによって行うことができる。合致が起こる場合、例えば、ルータは、ルーティング広告で応答し得る。合致が起こらない場合、例えば、ルータは、要請を無言で無視するか、または他のルータが処理するためにそれをネットワーク内の別のルータに転送し得る。一例として、非スリーピルータを見出すために、「ＩｓＳｌｅｅｐｙＮｏｄｅ＝＝ＦＡＬＳＥ」等のクエリ文字列が、ルータ要請メッセージで使用され得る。

一実施形態によると、ＮＤコンテキスト拡張が、ＮＤ ＩＣＭＰメッセージ内にコンテキスト情報を組み込むために使用される。コンテキスト情報は、メッセージの送信側によって組み込まれ得る。例えば、そのようなＮＤコンテキスト拡張を介して、スリーピノードは、それらが送信するＮＤ ＩＣＭＰメッセージ内にスリーピノードのコンテキストとして変数の情報を含むことによって、ネットワーク内の他のノードにそれらのスリーピノードの変数（例えば、表１に記載されるもの等）を広告し得る。次いで、この情報は、ネットワーク内のスリーピノードの存在を認識するために、受信側ノードによって使用され得る。さらに、受信側ノードは、ネットワーク内のスリーピノードの変化（例えば、スリープ状態）を追跡し得る。したがって、ノードは、近隣のスリーピノードの状態の認識を維持し、スリーピノードにより良好にサービス提供するために、それら自身のの機能性に対して対応するスリープ認識調整を行ない得る。例えば、ノードは、ＮＤ ＩＣＭＰメッセージ（例えば、ルータ要請、近隣要請等）内にコンテキスト情報としてスリープ状態変数を含むことによって、ノードのスリープ状態の変化についてその近隣ノードに最新状態を与え得る。

例示的実施形態によると、ＮＤ構成拡張が、ＮＤ ＩＣＭＰメッセージの受信側の構成パラメータを特定するために使用され得る。したがって、１つ以上のスリーピノードの変数（例えば、表１に記載されるもの等）は、ＮＤ ＩＣＭＰメッセージを使用して構成され得る。例えば、ノードが構成拡張を伴うＮＤ ＩＣＭＰメッセージを受信するとき、ノードは、ノード上で対応するＮＤ変数を構成するためにメッセージを使用し得る。一例として、ルータは、近隣のスリーピノードのスリープ持続時間を調整するために、ルータが送信するルータ広告メッセージ内に構成メッセージを含み得る。ＮＤ ＩＣＭＰメッセージに対する例示的構成拡張を使用して、ルータは、ＴｉｍｅＢｅｆｏｒｅＮｅｘｔＳｌｅｅｐ、ＤｕｒａｔｉｏｎＯｆＮｅｘｔＳｌｅｅｐ、ＤｕｔｙＣｙｃｌｅＡｗａｋｅＤｕｒａｔｉｏｎ、ＤｕｔｙＣｙｃｌｅＳｌｅｅｐＤｕｒａｔｉｏｎ等のスリーピノードの変数を構成することができる。

例示的実施形態によると、ＮＤメッセージに対するＮＤ加入および通知拡張が、ノードに加入し、特定ＮＤ条件またはイベント（例えば、ＮＤ変数状態の変化）の発生に基づいてノードから通知を受信するために使用され得る。加入要求が、例示的実施形態によると、ＮＤ ＩＣＭＰメッセージ内で送信され得る。ＮＤ ＩＣＭＰメッセージに対する加入拡張は、１つ以上の目標変数に関して通知が生成されるべきであるときの対応する基準とともに、例えば、表１に記載されるスリーピノードの変数等の１つ以上の目標変数を含み得る。さらに、通知が、ＮＤ ＩＣＭＰメッセージ内で送信され得る。通知は、例えば、どのＮＤ変数が状態を変化させたか、状態を変化させた変数の新しい値等のイベント情報を含み得る。

ルータ広告メッセージ内で加入拡張を使用することによって、ルータは、スリーピノードのスリープ状態変数が状態を変化させるたびに、スリーピノードから通知を受信するために加入し得る。例えば、これは、ルータ広告に含まれ得る加入拡張に、スリープ状態に基づく基準を含むことによって、達成され得る。したがって、ノードは、それらのスリープ状態が（例えば、ＡＷＡＫＥからＡＳＬＥＥＰへ、およびその逆も同様に）値を変化させるたびに、ルータへの通知を生成し得る。これらの通知に基づいて、ルータは、その近隣ノードのスリープ変数の最新バージョンを効率的に維持し、スリープ認識様式でパケットをより効果的に転送するためにこの情報を使用することができる。

例示的実施形態では、それが目標にしている宛先ノード（または宛先へのルーティング経路に沿った中間ノード）が現在スリープしていることを要求側に知らせるために、宛先スリープＩＣＭＰメッセージ拡張が、ＩｏＴルータによって使用される。したがって、要求側は、要求が宛先ノードに送信されることができないことを知らされる。宛先スリープＩＣＭＰメッセージは、例えば、スリープスケジュール（例えば、ノードが起動することが予期される前の持続時間）、スリーピノードにサービス提供しているプロキシの連絡先情報等のスリープ関連情報を含み得る。要求側は、それに応じて反応するために、本メッセージ（情報）を使用し得る。例えば、情報に応答して、要求側は、例えば、スリーピノードが起動する予定になっているときに再試行すること、スリーピノードのためのプロキシであるネットワーク内のノードを目標にすること、要求をネットワーク内の代りのノードにリダイレクトすること等の種々の動作を行ない得る。

図５は、例えば、例示的システム１００内のデバイス１０２のうちの１つ以上のもの等の例示的ノードによって実装されることができる、スリープ認識動作のための例示的状態図５００を示す。ここで図５を参照すると、図示した実施形態によると、略図５００は、ＮＤ近隣不到達可能性検出（ＮＵＤ）略図５００と称されることもできる。示されるように、略図は、到達可能性状態とも称され得るスリープ状態５０２を含む。他の図示した到達可能性状態は、到達可能な状態５０４、探査状態５０６、不完全な状態５０８、遅延状態５１０、到達不可能な状態５１２、および停滞状態５１４を含む。近隣不到達可能性検出図５００は、例えば、デバイス１０２のうちの１つ等のノードが到達可能であるかどうかを決定するために使用され得る。例えば、システム１００内のデバイス１０２のうちの１つであり得る、第１のノードは、例えば、第１のノードの近隣キャッシュエントリの中で近隣ノードの到達可能性状態を維持し得る。略図５００は、例示的実施形態によると、どのようにして到達可能性状態が維持されるか、および到達可能性状態の間の移行が起こる条件を定義する。

不完全な状態５０８は、アドレス解決が進行中であり、近隣ノードのリンク層アドレスが第１のノードによってまだ決定されていないことを示し得る。到達可能な状態５０４は、近隣ノードが所定の期間内において到達可能であったことが知られていることを示し得る。例えば、第１のノードは、前の１０秒以内に近隣ノードに到達していたかもしれないが、所定の期間は、所望に応じて任意の時間量であり得ることが理解されるであろう。停滞状態５１４は、近隣ノードが到達可能であることがもはや知られていないが、トラフィックがその近隣のある近隣に送信されるまで、その到達可能性を検証するために試行が行われるべきではないことを示し得る。遅延状態５１０は、近隣ノードが到達可能であることがもはや知られておらず、最近、トラフィックがその近隣に送信されたことを示し得る。しかしながら、即時に近隣を探査するよりもむしろ、遅延状態５１０は、例えば、到達可能性確認を提供する機会を上層プロトコルに与えるように、所定の持続時間後に探査が送信されるべきであることを示し得る。探査状態５０６は、近隣ノードが到達可能であることがもはや知られておらず、ユニキャスト近隣要請探査が、近隣ノードの到達可能性を検証するために送信されていることを示し得る。到達不可能な状態５１２は、近隣ノードがもはや到達可能ではないことを示し得る。したがって、第１のノードは、第１のノードの近隣キャッシュから、近隣ノードに関連付けられるエントリを除去し得る。

依然として図５を参照すると、５１５では、近隣ノードが、その近隣ノードに関連付けられている近隣キャッシュエントリを到達可能な状態５０４に設定し得る。例えば、第１のノードは、１つ以上のスリーピノードの変数オプションと、近隣ノードに関連付けられるＡＲＯとを含む、近隣要請メッセージを近隣ノードから受信し得る。ＡＲＯは、上で説明されるように、登録寿命で構成され得る。５１８では、第１のノードは、近隣ノードが到達可能な状態５０４から停滞状態に移行したことを決定し得る。そのような決定は、近隣ノードがスリーピノードではなく（例えば、スリープすることが可能ではない）、かつ、近隣ノードが機能しているという最後の確認以降に、到達可能な時間と称され得る所定の制限時間が経過したことを、第１のノードが決定する場合に行われ得る。５２０では、第１のノードが、近隣ノードに関連付けられている近隣キャッシュエントリを、到達可能な状態５０４からスリープ状態５０２に移行させる。例えば、第１のノードは、近隣ノードがスリープしていることを検出または予測し得る。一例として、第１のノードは、近隣ノードに関連付けられるスリーピノードの変数を評価することによって、または上層プロトコルからの情報を評価することによって、近隣ノードがスリープしていることを検出または予測し得る。５１６では、近隣ノードがスリープしており、したがって、第１のノードは、近隣ノードに関連付けられている近隣キャッシュエントリをスリープ状態５０２で維持する。５２２では、例えば、近隣ノードがもはやスリープしていないような近隣ノードが起動したことを検出または予測した後に、第１のノードが、近隣ノードに関連付けられている近隣キャッシュエントリを、スリープ状態５０２から到達可能な状態５０４に移行させる。例えば、スリーピノードの変数、および上で説明されるＮＤ ＩＣＭＰメッセージ拡張を含む、本明細書で説明される種々の実施形態は、ノードがスリープしているとき、およびそれが起動するときを検出または予測するために使用され得る。例えば、５２２では、アドレス登録オプション（ＡＲＯ）を伴う近隣要請が、第１のノードによって受信され得る。５２４では、例えば、ＡＲＯを伴う以前の近隣要請が第１のノードによって受信された以降に、近隣ノードに関連付けられる登録寿命が経過したため、第１のノードが、近隣ノードに関連付けられている近隣キャッシュエントリを、スリープ状態５０２から停滞状態５１４に移行させる。５２６では、近隣ノードに転送される必要があるいかなるパケットも第１のノードによって受信されず、したがって、近隣ノードに関連付けられている近隣キャッシュエントリが、停滞状態５１４にとどまり得る。５２８では、例えば、ＡＲＯを伴う近隣要請が第１のノードによって受信されたため、第１のノードが、近隣ノードに関連付けられている近隣キャッシュエントリを、停滞状態５１４から到達可能な状態５０４に移行させる。

代替として、図示した実施形態によると、５３０では、例えば、少なくとも１つのパケットが第１のノードによって受信され、近隣ノードに転送されたため、第１のノードが、近隣ノードに関連付けられている近隣キャッシュエントリを、停滞状態５１４から遅延状態５１０に移行させる。５３２では、第１のノードが、近隣ノードに関連付けられている近隣キャッシュエントリを、遅延状態５１０から到達不可能な状態５１２に移行させる。例えば、第１のノードは、近隣ノードがスリーピノードであるとことを決定し得、第１のノードは、遅延状態に関連付けられる定義された期間内に到達可能性確認を受信していない場合がある。定義された期間は、所望に応じて変動し得ることが理解されるであろう。近隣ノードが到達不可能であると決定された場合、近隣ノードに関連付けられている近隣キャッシュエントリは、５３４で第１のノードによって削除され得る。５３６では、第１のノードが、近隣ノードに関連付けられている近隣キャッシュエントリを、遅延状態５１０から探査状態５０６に移行させる。例えば、第１のノードは、近隣ノードがスリーピノードであるとことを決定し得、第１のノードは、探査に関連付けられる定義された期間内に到達可能性確認を受信していない場合がある。５３８では、１つ以上の近隣要請が、第１のノードによって近隣ノードに送信され得る。要請は、再伝送タイマに基づいて周期的に送信され得る。５４０では、最大数の近隣要請メッセージが送信されたとき、第１のノードが、近隣ノードに関連付けられている近隣キャッシュエントリを、探査状態５０６から到達不可能な状態５１２に移行させる。代替として、最大数の要請が送信される前に、近隣ノードからの近隣広告が第１のノードによって受信された場合、第１のノードは、５４２で、近隣ノードに関連付けられている近隣キャッシュエントリを、探査状態５０６から到達可能な状態５０４に移行させる。５４４では、図示した実施形態によると、近隣ノードへの転送経路は、到達可能な時間で機能したままであり、したがって、第１のノードは、近隣ノードに関連付けられている近隣キャッシュエントリを到達可能な状態５０４で維持する。上記の実施形態は、近隣ノードがスリープ状態５０２であるため、近隣ノードが応答していない場合か、または近隣ノードが到達不可能な状態５１２である場合かを第１のノードが区別することを可能にすることが理解されるであろう。

したがって、上で説明されるように、ネットワークを介して互に通信する複数のノードを備えているシステムで、複数のノードのうちの第１のノードは、複数のノードのうちの第２のノードを目標とするパケットを受信し得る。第１のノードは、第２のノードが、低電力状態になり、第１のノードとの通信を一時停止するように構成されるスリーピノードであることを決定し得る。このノードはさらに、第２のノードの到達可能性状態を決定し、決定された到達可能性状態に基づいて、パケットを処理し得る。上で説明されるように、第１のノードは、第２のノードを示す、１つ以上のスリーピノードの変数を含む要請メッセージを受信し得る。したがって、第１のノードは、要請メッセージに従って、それ故に、スリーピノードの変数に従って、パケットを処理し得る。

概して、図５を参照すると、第１のノードは、近隣ノードのスリープ状態を検出または予測するために、本明細書で説明される異なる技法を使用し得ることが理解されるであろう。そのような検出または予測は、例えば、ノードのタイプ、ならびにその対応するスリープパターンおよびスリープ機能性に基づき得る。例えば、そのスリーピノードの変数のうちの１つ以上のものの状態が変化するたびに、スリーピノードが、その近隣に広告または通知することをサポートする場合、第１のノードは、スリープ状態５０２の中／外へ移行に対するこれらの更新に依拠し得る。同様に、スリーピノードが周期的にスリープする場合、スリーピノードが、初期メッセージ交換中に（例えば、デフォルトルータ登録中に）そのスリープスケジュールおよび／またはデューティサイクルをその近隣に提供することができ、近隣は、ノードがスリープしているとき、およびそれが起動しているとき、したがって、それに応じたスリープ状態５０４の中／外へ移行を予測するために、この情報を使用し得る。スリーピノードが予測不可能かつ非周期的にスリープし、そのスリープ状態が変化するたびに、その近隣ノードに最新状態を与えることをサポートしない、例示的シナリオでは、近隣ノードは、スリーピノードに送信されるパケットがそれに到達しているかどうか（例えば、スリーピノードがＣｏＡＰまたはＴＣＰ確認応答で応答しているか）を近隣ノードが決定することを可能にする、上位および／または下層プロトコルからの情報を受信し得る。例えば、上で説明される種々の情報を使用して、近隣ノードは、特定のノードがスリープしているかどうかを決定し得、それに応じて、スリープ状態５０４の中／外への移行を管理し得る。

図５に関して説明される状態情報に基づいて、スリープ認識到達不可能性決定がサポートされる。例えば、スリーピノードがスリープ状態５０２であるとき、スリーピノードに対するパケットは、その時点でパケットがスリーピノードに転送され得る到達可能な状態５０４への状態移行まで記憶され得る。したがって、例えば、第１のノード等のノードは、第２のノードのスリーピ属性を示す複数のスリーピノードの変数のうちの１つで特定されている持続時間の間、第２のノードを目標とするパケットを記憶し得る。一実施例では、持続時間が経過したときに、第１のノードは、パケットを第２のノードに送信し得る。場合によっては、スリーピノードがスリープ状態５０２であるとき、スリーピノードがスリープしていることを要求側が通知されるように、通知が要求側に返信され得る。別の実施例として、要求されたノードがスリープ状態５０２であるとき、要求側ノードは、起動している代りのノード（例えば、スリープしているノードのためにプロキシするノード、または同一のグループのメンバーであるノード等）にリダイレクトされ得る。

図６は、例えば、例示的システム１００内のデバイス１０２のうちの１つ以上のもの等の例示的ノードによって行うことができる、スリープ認識動作の例示的プロセスフローを示す。ＩＰｖ６および６ＬｏＷＰＡＮ ＮＤプロトコルは、どのようにして次期ホップ決定を第１のノードによって行うことができるかという実施例を説明する。次期ホップとは、第１のノードがパケットを転送する第２のノードを指す。次期ホップ決定計算の結果は、上で説明されるように、宛先キャッシュに保存され得る。図６は、例示的実施形態による、ノードによって行うことができる、スリープ認識次期ホップ決定の例示的プロセスフローを示す。

図６を参照すると、例示的ノード、例えば、送信側ノードと称することもできる、第１のノードは、第１のノードがパケットを送信することができる次期ホップノードを決定する。図示した実施形態によると、第１のノードは、要求側または要求ノードと称することができる別のノードから、パケットを受信し、パケットの宛先アドレスを決定する。宛先アドレスは、宛先ノードとも称され得る、第２のノードに対応し得る。６０２では、第１のノードが、その宛先キャッシュの中にパケットの宛先アドレスに対応するエントリがあるかどうかを決定する。エントリが存在する場合、本プロセスは、第１のノードが宛先ノードの到達可能性状態を決定する６０４へ進む。第２のノードがスリープ状態５０２または停滞状態５１４であることを第１のノードが決定する場合、第１のノードは、６０６へ進むことによって、近隣要請メッセージを介して第２のノードの状態を検出する。第２のノードが到達不可能な状態５１２であることを第１のノードが決定する場合、第１のノードは、６０８で、宛先到達不可能メッセージを要求側に送信し得る。第２のノードが到達可能な状態５０４であることを第１のノードが決定する場合、第１のノードは、（６１０で）宛先ノード、または宛先ノードへの途中にあるノードであり得る次期ホップにパケットを伝送し得る。第１のノードが、例えば、第２のノードに関連付けられる１つ以上のスリーピ変数を評価することによって、第２のノードがスリープ状態５０２であると決定する場合、スリーピノードのハンドラ機能６１１が実施され得る。スリーピノードのパケットハンドラ機能６１１は、スリープしているノードを目標にするパケットを処理するための複数のオプションをサポートし得る。一例として、６１２では、第１のノードが、パケットを記憶し、６１０で、第２のノードが起動する時にパケットを転送する。６１４では、図示した実施形態によると、第１のノードが、パケットを代りのノードに送信するために、要求をリダイレクトする。６１６では、第１のノードが、宛先ノードがスリープしていることを要求側に通知する。処理オプション６１２、６１４、および６１６が図示されているが、第１のノードは、所望に応じて本明細書で説明される他の処理オプションを選択できることが理解されるであろう。

スリープしているノードに向かうことになっているパケットを取り扱うために、どの処理オプションが使用されるかを決定するために、スリーピノードのハンドラ機能６１１は、種々の機構をサポートすることができる。図示した実施形態によると、スリーピノードのハンドラ機能６１１は、スリープしているノードに向かうことになっているパケットをどのようにして処理するかを決定するために、ポリシー機能６１３を使用し得る。ポリシー機能６１３は、第１のノード上でプロビジョニングおよび／または構成されることができる、ポリシーのセットを含むことができる。したがって、どのようにしてパケットが処理されるかは、１つ以上のポリシーに基づき得る。スリーピノードのハンドラ機能６１１、したがって、第１のノードはまた、パケットのヘッダ内の１つ以上のフィールドを評価することによって、どのようにしてパケットが処理されるかを決定し得る。ヘッダ内のフィールドは、スリーピノードのハンドラ機能６１１によって、どのようにしてパケットが取り扱われるべきかを特定し得る。図示した実施形態によると、スリープハンドラ機能６１１は、スリープしているノードに向かうことになっているパケットを処理するために、構成機能６１５を使用し得る。スリーピノードである第２のノードは、それがスリープしているときにそのパケットを取り扱うためにデフォルトルータによって使用される、その好ましい技法を特定するために、構成機能６１５と相互作用し得る。例えば、スリーピノードは、デフォルトルータに登録するときに、この情報を特定し得る。したがって、第２のノードが、構成機能６１５にその選好を登録した場合、第１のノードは、構成機能６１５を評価することによって、第２のノードがスリープしているときに、第２のノードに向かうことになっているパケットがどのようにして処理されるべきかを決定し得る。

再度、６０２を参照すると、第１のノードが、その宛先キャッシュの中にエントリがあり、第２のノードがスリープしていることをエントリが示すことを決定する場合、本プロセスは、スリーピノードのハンドラ機能６１１へ進み得る。エントリが見出されない場合、本プロセスは、宛先がオンリンクであるかオフリンクであるかを第１のノードが決定する６１８へ進む。一実施形態では、いかなるエントリも宛先のために存在しない場合、新しい宛先キャッシュエントリを作成するために、次期ホップ決定計算が呼び出される。次期ホップのＩＰアドレスが（宛先キャッシュを介して、または次期ホップ決定を介して）把握される場合、次いで、近隣キャッシュが、その近隣についてのリンク層情報に対して調べられ得る。宛先ノードがインリンクである場合、第１のノードは、６２０で、宛先ノードのアドレスを解決し、次いで、６１０で、パケットを伝送する。宛先がオフリンクである場合、図示した実施形態によると、第１のノードは、６２２で、宛先に関連付けられるデフォルトルータリスト内のルータが起動しているかどうかを決定する。リスト内のルータがスリープしている場合、本プロセスは、スリーピノードのハンドラ機能６１１へ続く。起動しているリスト内のルータがある場合、第１のノードは、６１０で、起動したルータである次期ホップにパケットを伝送する。第１のノードは、ルータのスリーピノードの可変状態に基づいて、デフォルトルータのリストからデフォルトルータを選択し得る。

本明細書で説明される種々の実施形態は、ノードがスリープ認識様式で次期ホップ決定を行い得るように、次期ホップ決定機構を強化する。例えば、図７は、そのデフォルトルータに登録するためにスリーピノードによって使用することができる、例示的メッセージ７００を図示する。メッセージ７００は、スリーピノードの変数、例えば、表１を参照して本明細書で説明される、スリーピノードの変数を含む。スリーピノードに関連付けられる、スリーピノードの変数の公開された状態、ならびに上で説明されるような強化型近隣キャッシュ、デフォルトルータリスト、宛先キャッシュ、次期ホップ決定、および近隣不到達可能性検出を使用して、デフォルトルータは、スリーピノードの到達可能性（例えば、スリープ）状態を考慮することによって、スリープ認識様式でパケット処理決定を行うことができる。したがって、種々の例示的実施形態によると、スリープしているノードを目標にするパケットの知的かつ効率的な処理が可能にされる。知的かつ効率的な処理の実施例は、スリープ状態に基づくパケットの記憶および転送、スリープしていない代りのノードまたはプロキシに要求側をリダイレクトすること、適切な措置を講じることができるように、ノードがスリープしていることを要求側に通知すること等を含む。

説明されたスリーピノードのＮＤプロトコル拡張は、それらのサポートされたスリープ属性および状態に基づいて、ルータの要請を可能にするために使用され得る。例えば、ノードによって、ノードが開始するルータ要請メッセージにクエリ拡張が追加され得る。クエリ拡張内に、スリーピノードの変数の状態に基づくクエリ文字列を含むことにより、どのルータがルータ要請メッセージに応答するかを示すことができる。

図８は、例示的システム８００で実装されるルータ要請の実施例を示す。例示的ルータ要請は、スリープ認識様式で行われる。システム８００は、ＩｏＴノード８０２および複数のＩｏＴスリーピルータ８０４、例えば、第１のスリーピルータ８０４ａおよび第２のルータ８０４ｂを含む。例示的システム８００は、開示された主題の説明を促進するように簡略化され、本開示の範囲を限定することを目的としていないことが理解されるであろう。システム８００等のシステムに加えて、またはその代わりに、他のデバイス、システム、および構成が、本明細書で開示される実施形態を実装するために使用され得、全てのそのような実施形態は、本開示の範囲内と見なされる。

図８を参照して、図示した実施形態によると、８０６では、図１で描写されるエンドポイントデバイス１０４のうちの１つであり得るノード８０２は、ノード８０２がスリープしないシステム８００内のルータを要請するであろうことを決定する。そのようなルータは、非スリーピルータと称することができる。これらのルータが最良の利用可能性を有し得、かつパケットを転送することができる最良の候補であり得るため、ノード８０２は、これらのルータを要請する場合がある。８０８では、ノード８０２が、第１のルータ要請メッセージを送信することによって、非スリーピルータを要請し得る。メッセージは、マルチキャストまたはブロードキャストされ得る。メッセージは、所望のルータがスリープしてはならないことを特定するクエリをクエリ文字列メッセージに含み得る。８１０では、第１および第２のルータが、第１のルータ要請メッセージを処理し、第１および第２のルータ８０４ａおよび８０４ｂがスリーピルータであるため、それらが要請メッセージで特定される基準を満たさないことを決定する。図示した実施例によると、ノード８０２は、８０６で、要請に応答して、いかなるルータ広告も受信しない。例えば、限定ではないが、ネットワーク８００とも称され得る、システム８００内に、いかなる非スリーピルータもない場合がある。８１２では、非スリーピルータの要請がタイムアウトする。８０６で、要請の（ルータが非スリーピであるという）特定基準を満たすルータがネットワーク８００内にないため、ノード８０２は、８１４で、第２のルータ要請を伝送することを決定し得る。第２のルータ要請は、マルチキャストメッセージとして、またはブロードキャストメッセージとして送信され得る。示されるように、８１６では、第２のルータ要請メッセージが、ノード８０２によって伝送される。第２のルータ要請は、スリーピノードの属性値ペアのリストを特定する、新しいクエリ拡張を含み得る。図８は、ノード８０２によって特定される、例示的なスリーピノードの属性を例証するが、ノードは、所望に応じて任意のスリーピノードの属性を特定し得ることが理解されるであろう。ＩｏＴノード８０２は、その要件を満たす、所望のスリーピルータ属性値を伴うスリーピノードの属性値ペアを構成し得る。図示した実施例によると、ノード８０２は、ルータが少なくとも６０秒間起動したままであり、６０秒以上スリープせず、それらのスリープ状態が変化するたびに、通知を送信することをサポートする、デューティサイクルを有する、周期的にスリープするルータを要請する。所望に応じて任意の要件を使用して、ノードがルータを要請し得ることが理解されるであろう。

依然として図８を参照すると、８１８では、第１のルータ８０４ａが、第２の要請メッセージを処理し、第１のルータ８０４ａがルータ要請で特定される基準を満たすことを決定する。８２０では、第２のルータ８０４ｂが、第２の要請メッセージを処理し、第２のルータ８０４ｂが第２の要請メッセージで特定される要件のうちの少なくとも１つを満たさないことを決定する。したがって、図示した実施形態によると、ノード８０２は、その要件を満たすルータ（ルータ８０４ａ）を要請することに成功している。８２２では、第１のルータは、ルータ広告メッセージをノード８０２に返信し、それによって、８２４でルータ要請を完了し得る。

図９Ａおよび９Ｂは、システム９００内で交換することができる、種々のスリーピノードのコンテキスト情報の実施例を示す。システム９００は、ＩｏＴノード８０２と、複数のＩｏＴスリーピルータ８０４とを含む。例示的システム９００は、開示された主題の説明を促進するように簡略化され、本開示の範囲を限定することを目的としていないことが理解されるであろう。システム９００等のシステムに加えて、またはその代わりに、他のデバイス、システム、および構成が、本明細書で開示される実施形態を実装するために使用され得、全てのそのような実施形態は、本開示の範囲内と見なされる。図９Ａは、例えば、ノードがスリーピノードであるかどうか、ノードのスリープ状態、ノードがスリープしようとしている前の時間、ノードがその次のスリープに向かっている持続時間等の交換され得るスリーピノードのコンテキスト情報の実施例を示す。代替として、スリーピノードのコンテキスト情報は、本明細書で説明される加入および通知拡張を使用して、ノード間で共有され得る。例えば、加入／通知拡張を伴うＮＤメッセージを使用して、ＩｏＴノードは、スリーピノードの変数が状態を変化させる場合／ときに通知を受信するために、１つ以上の近隣ＩｏＴノードに加入し得る。

図９Ａを参照すると、９０１では、ノード８０２が、所望のスリーピノードのコンテキスト情報を広告する、ルータ要請メッセージをルータ８０４に送信する。図示した実施例によると、９０１では、ノード８０２が、スリーピであるが、現在起動しているルータを要請し、ルータがスリープすることができる前に経過しなければならない時間は、少なくとも５０秒である。実施例の目的で秒が使用されるが、任意の時間単位を所望に応じて特定できることが理解されるであろう。別の図示した実施例では、９０３で、ルータ８０４のうちの１つが、９０１でのメッセージに応答して、ルータ広告メッセージをノード８０２に送信する。具体的には、９０３では、ルータ８０４が、それがスリーピルータであり、現在起動状態であり、ルータ８０４は、１０００秒が経過するまでスリープしないであろうことを広告する。別の図示した実施例によると、１００６では、ノード８０２が、起動状態であり、１秒後にスリープし、３０秒間スリープするであろう、ルータを要請するために、近隣要請メッセージを送信する。９０８では、ルータ８０４のうちの１つが、ルータが起動しており、９５０秒が経過するまでスリープしないであろうことを広告する、近隣広告メッセージを送信する。別の図示した実施例によると、９１０では、ノード８０２が、そのスリーピコンテキスト情報を広告するＩＣＭＰｖ６メッセージを送信する。具体的には、ノード８０２は、ノードが起動しており、１秒後にスリープし、３０秒間スリープするであろうことをルータ８０４に広告する。９１２では、ルータ８０４のうちの１つが、そのスリーピコンテキスト情報を広告するＩＣＭＰｖ６コンテキストメッセージを送信する。具体的には、ルータ８０４は、ルータが起動しており、９５０秒が経過するまでスリープしないであろうことをノード８０２に広告する。

上で説明されるように、１つのノードのスリーピノードのパラメータは、ネットワーク内の他のノードによって構成され得る。図９Ｂを参照すると、９１４、９１６、９１８、および９２０では、上記のスリーピノードのＮＤプロトコル拡張が、他のノードによるスリーピノードのパラメータの構成を可能にするために使用される。例えば、９１４および９１８では、ノード８０２が、それぞれ、ルータ要請メッセージおよび近隣要請メッセージをルータに送信することによって、ルータ８０４のスリーピノードのパラメータを構成する。他の図示した実施例によると、９１６および９２０では、ルータ８０４では、それぞれ、ルータ広告メッセージおよび近隣広告メッセージをノード８０２に送信することによって、ノード８０２のスリーピノードのパラメータを構成する。一例として、９２２では、ノード８０２が、ＩＣＭＰｖ６コンテキストメッセージをルータ８０４に送信することによって、ルータ８０４のスリーピノードのパラメータを構成する。９２４では、ルータ８０４が、ＩＣＭＰｖ６コンテキストメッセージをノード８０２に送信することによって、ノード８０２のスリーピノードのパラメータを構成する。種々のスリーピノードのパラメータは、種々の実施形態によると、別のノードによって構成され得る。例えば、ノードがスリープしている持続時間、およびスリープに戻る前に起動している持続時間を含むスリーピノードのデューティサイクルは、図９Ｂに示されるメッセージを使用して、別のノードによって構成され得る。さらなる一例として、第１のノードは、第２のノードのスリープ状態が変化するたびに、第１のノードが通知を受信するように、第２のノードを構成し得る。他のパラメータが、所望に応じてノード間で構成され得ることが理解されるであろう。

上記のスリーピノードのＮＤプロトコル拡張は、スリープ認識記憶および転送、スリープ認識リダイレクトメッセージ、スリープ認識アラート等を可能にし得る。図１０−１２は、ネットワーク１０００とも称することができる、例示的システム１０００内の例示的スリープ認識実装を示す。システム１０００は、図１で描写されるデバイス１０２のうちの１つであり得る第１または要求ノード１００２と、デフォルトルータ１００４と、スリープすることが可能であり、したがって、スリーピ宛先ノード１００６と称され得る第２または宛先ノード１００６とを含む。例示的システム１０００は、開示された主題の説明を促進するように簡略化され、本開示の範囲を限定することを目的としていないことが理解されるであろう。システム１０００等のシステムに加えて、またはその代わりに、他のデバイス、システム、および構成が、本明細書で開示される実施形態を実装するために使用され得、全てのそのような実施形態は、本開示の範囲内と見なされる。

具体的には図１０を参照すると、１００８では、宛先ノード１００６が、ルータ要請メッセージをルータ１００４に送信する。１０１０では、ルータ１００４が、ルータ広告メッセージを宛先ノード１００６に返信する。１０１２では、宛先ノード１００６が、近隣要請メッセージをデフォルトルータ１００４に送信する。メッセージは、宛先ノード１００６のアドレス登録と、宛先ノード１００６に関連付けられるスリーピノードの変数とを含み得る。１０１４では、ルータ１００４が、宛先ノード１００６に関連付けられている近隣キャッシュエントリを作成する。ルータ１００４は、宛先ノード１００６に関連付けられるスリーピノードの変数をエントリの中に記憶して維持し得る。１０１５では、宛先ノード１００６がスリープする。１０１６では、ルータ１００４が、ノード１００６がスリープしたことを決定するために、例えば、図５を参照して説明されるように、宛先ノード１００６に関連付けられている近隣キャッシュエントリおよび近隣不到達可能性検出を使用する。１００２では、図示した実施形態によると、要求ノード１００２が、ルータ１００２によって受信される着信要求パケットを送信する。パケットは、スリープしているノード１００６を目標にする。１０２０では、ルータ１００４は、宛先ノード１００６が起動するまでパケットを記憶する。例えば、ルータ１００４は、宛先ノード１００６のスリーピ属性を示す、スリーピノードの変数のうちの１つで特定されている持続時間にわたって、パケットを記憶し得る。１０２１では、ノード１００６が起動する。１０２２では、宛先ノード１００６が、別の近隣要請メッセージをルータ１００４に送信する。１０２４では、ルータ１００４は、ノード１００６が起動していることを検出する。１０２６では、図示した実施形態によると、ノード１００６が起動していることを決定した後に、ルータ１００４がパケットを宛先ノード１００６に送信し、それによって、例示的実施形態による、スリープ認識記憶および転送実装を完成させる。例えば、ルータ１００４は、スリーピノードの変数のうちの１つで特定されている持続時間が経過すると、パケットを宛先ノード１００６に送信し得る。１０２８および１０３０では、宛先ノード１００６が、ルータ１００４を介して応答パケットをノード１００２に送信し得る。

ここで図１１を参照すると、上記のスリーピノードのＮＤプロトコル拡張は、目標宛先ノード１００６がスリープしていることを要求ノード１００２にアラートするために使用することができ、ルータ１００４は、宛先ノード１００６が次に利用可能であるときを要求ノード１００２に知らせることができる。参照番号は、同一または類似特徴を表すように種々の図で繰り返されることが理解されるであろう。スリーピノード１００６は、例えば、ノード１００６がルータ１００４に登録するときに、そのスリーピノードの変数／状態をデフォルトルータ１００４と共有することができる。１１２２では、図示した実施例によると、ノード１００６がスリープしているため、ルータ１１０４が、１０１８で送信されたパケットをドロップする。１１２４では、ルータ１１０４は、ノード１００６が特定の期間にわたってスリープしていることを示す、アラートとも称され得るＩＣＭＰメッセージを、要求ノード１００２に送信する。特定の期間は、その期間が経過した後にノード１００６が起動するように定義される。期間はまた、宛先ノード１００６が起動する前に残っているスリープ時間とも称され得る。１１２６では、図示した実施形態によると、要求ノード１００２は、期間が過ぎるまで待機する。期間が経過した後、１１２８では、要求ノード１００２が、要求パケットをルータ１００４に再送信する。１０２４では、ルータ１００４は、宛先ノード１００６が起動していることを検出する。したがって、１１３０では、ルータ１００４が、起動しておりパケットを受信する宛先ノード１００６にパケットを転送する。したがって、ルータ１００４は、スリープしているスリーピノード１００６を目標にするパケットをドロップすることができ、ルータ１００４は、（１１２４で）対応するアラートを要求ノード１００２に送信し得る。アラートでは、例えば、ルータ１００４は、宛先ノードがスリープしていることを示すことができ、例えば、ノード１００６が起動することが予期される前に残っている時間量等の追加の情報を含み得る。要求ノード１００２は、アラートに応答して、該当する場合、どのような措置を講じるかを決定し得る。例えば、要求ノード１００２は、図１１に示されるように、アラートメッセージ内に含まれるスリープ情報を基づいて、要求を再試行し得る。

ここで図１２を参照すると、スリーピノードの変数／状態、ならびに本明細書で説明されるスリープ認識次期ホップ決定および近隣不到達可能性検出機構を活用することによって、ルータ１００４は、宛先ノード１００６と機能的に同等であるノード、またはノード１００６の代わりに要求を果たすプロキシへの要求のスリープ認識リダイレクトを行うことができる。図１２を参照すると、ネットワーク１０００はさらに、宛先ノード１００６のためのプロキシであり得るか、または宛先ノード１００６と機能的に同等であるノードであり得る、リダイレクトノード１００５を含む。ルータ１００４は、例示的実施形態によると、表１で描写されるＳｌｅｅｐＧｒｏｕｐ変数を介して、１つ以上の機能的に同等のノード、例えば、リダイレクトノード１００５を認識させられることができる。さらに、ルータ１００４は、上記の表１で描写されるＳｌｅｅｐＰｒｏｘｙ変数を介して、１つ以上のプロキシノード、例えば、リダイレクトノード１００５を認識させられることができる。ノード１００６のスリープ状態とともに、ＳｌｅｅｐＧｒｏｕｐ変数またはＳｌｅｅｐＰｒｏｘｙ変数のうちの少なくとも１つを使用して、ルータ１００４は、ノード１００４がスリープしているときに要求をリダイレクトすることができる。したがって、リダイレクトノードは、宛先ノード１００６のスリーピ属性を示す、スリーピノードの変数のうちの１つによって特定されることができる。

依然として図１２を参照して、１つの図示した実施形態によると、要求パケットがルータ１００４によって受信されると、ルータ１００４は、１２０２で、パケットをリダイレクトノード１００５に自律的にリダイレクトするであろうことを決定する。リダイレクトノード１００５の識別は、本明細書で説明される、１つ以上のスリーピ変数によって示され得る。１２０４では、ルータ１００４が、パケットをリダイレクトノード１００５に送信し得る。代替実施形態では、要求パケットがルータ１００４によって受信されると、ルータ１００４は、１２１０で、要求側ノード１００２をリダイレクトノード１００５に向かわせるであろうことを決定する。したがって、１２１２では、ルータ１００４が、リダイレクトノード１００５のアドレスを特定するＮＤリダイレクトメッセージを要求ノード１００２に送信することによって、要求側１００２をリダイレクトし得る。１２１４では、リダイレクトメッセージに基づいて、要求側ノード１００２が、要求パケットをルータ１００４に再送信し得る。１２１４では、要求パケットが、１０１８で目標にしたように、宛先ノード１００６の代わりに、リダイレクトノード１００５を目標にし得る。リダイレクトノード１００５が要求パケットを受信すると、要求パケットが要求ノード１００２から受信されようと、ルータ１００４から受信されようと、リダイレクトノード１００５は、１２０６および１２０８で、ルータ１００４を介して、応答パケットを要求ノード１００２に送信し得る。

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

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

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

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

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

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

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

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

図１３Ｃは、例えば、Ｍ２Ｍ端末デバイス１８またはＭ２Ｍゲートウェイデバイス１４等の例示的Ｍ２Ｍデバイス３０の系統図である。Ｍ２Ｍデバイス３０は、上で説明される実施形態によると、要求ノード、宛先ノード、ルータ、またはリダイレクトノードとして構成され得る。図１３Ｃに示されるように、Ｍ２Ｍデバイス３０は、プロセッサ３２と、送受信機３４と、伝送／受信要素３６と、スピーカ／マイクロホン３８と、キーパッド４０と、ディスプレイ／タッチパッド／インジケータ４２と、非取り外し可能なメモリ４４と、取り外し可能なメモリ４６と、電源４８と、全地球測位システム（ＧＰＳ）チップセット５０と、他の周辺機器５２とを含み得る。Ｍ２Ｍデバイス３０は、実施形態と一致したままで、先述の要素の任意の副次的組み合わせを含み得ることが理解されるであろう。ディスプレイ／タッチパッド／インジケータ４２は、例示的実施形態によると、概して、ユーザインターフェースと称され得る。ユーザインターフェースは、ユーザが、例えば、ゲートウェイ（ルータ）または他のネットワークノード等のノード上で、スリーピ属性を監視、管理、および／または構成することを可能にし得る。例えば、ユーザインターフェースは、ユーザが、エンドポイントデバイスまたはルータ上でデューティサイクルを構成またはトリガすることを可能にし得る。したがって、ノードに関連付けられる種々のスリープ属性が、ディスプレイ／タッチパッド／インジケータ４２によって表示され得る。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Claims (1)

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