図面 (/)

技術 スリーピノードをサポートするための近隣発見

出願人 コンヴィーダワイヤレス,エルエルシー
発明者 デールエヌ.シードシャミムアクバルラフマンリジュンドンチョンガンワン
出願日 2017年10月27日 (2年0ヶ月経過) 出願番号 2017-208102
公開日 2018年4月5日 (1年7ヶ月経過) 公開番号 2018-057003
状態 特許登録済
技術分野 広域データ交換 小規模ネットワーク(3)ループ,バス以外 通信制御 移動無線通信システム
主要キーワード 無電力状態 時間基準点 目標変数 停滞状態 ルータデバイス 直接無線リンク ノード変数 周辺コンピュータ
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2018年4月5日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (19)

課題

スリーピノードサポートする近隣発見の提供。

解決手段

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

概要

背景

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

IoTエンドポイントデバイスおよびIoTルータの両方が、スリーピであり得る。例示的IoT実装が、図1に示されている。図1は、例えば、無線センサネットワーク(WSN)等の例示的システム100のブロック図である。システム100は、本質的にマルチホップであり得、エンドポイントデバイスとして機能するバッテリ式IoTデバイスを含み得る。例えば、システム100は、複数のIoTデバイス102を含み得る。デバイス102は、エンドポイントデバイス104、またはパケットをエンドポイントデバイス104へ/から上流および下流に経路指定するルータデバイス106として機能し得る。IoTのスリーピノード(sleepy node)をサポートすることへの既存のアプローチは、いくつかの欠点を有する。例えば、ノードは、多くの場合、ネットワーク内の他のノードがスリーピであるかどうかを認識しておらず、したがって、スリーピノードとネットワーク内で効率的および効果的に通信しない。

概要

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

目的

したがって、ノードは、近隣のスリーピノードの状態の認識を維持し、スリーピノードにより良好にサービス提供する

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

(分野番号表示ON)※整理標準化データをもとに当社作成

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

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

技術分野

0001

(関連出願の引用
本願は、米国仮特許出願第61/845,635号(2013年7月12日出願)の利益を主張し、上記出願の開示は、その全体が記載されているかのように参照により本明細書に引用される。

背景技術

0002

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

0003

IoTエンドポイントデバイスおよびIoTルータの両方が、スリーピであり得る。例示的IoT実装が、図1に示されている。図1は、例えば、無線センサネットワーク(WSN)等の例示的システム100のブロック図である。システム100は、本質的にマルチホップであり得、エンドポイントデバイスとして機能するバッテリ式IoTデバイスを含み得る。例えば、システム100は、複数のIoTデバイス102を含み得る。デバイス102は、エンドポイントデバイス104、またはパケットをエンドポイントデバイス104へ/から上流および下流に経路指定するルータデバイス106として機能し得る。IoTのスリーピノード(sleepy node)をサポートすることへの既存のアプローチは、いくつかの欠点を有する。例えば、ノードは、多くの場合、ネットワーク内の他のノードがスリーピであるかどうかを認識しておらず、したがって、スリーピノードとネットワーク内で効率的および効果的に通信しない。

課題を解決するための手段

0004

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

0005

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

0006

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

図面の簡単な説明

0007

添付の図面と併せて一例として挙げられる、以下の説明から、より詳細に理解され得る。
図1は、モノのインターネット(IoT)を介して互に通信する、IoTのスリーピエンドポイントデバイスおよびIoTのスリーピルータを含む、実施例のブロック図である。
図2Aは、近隣発見(ND)メッセージプロトコル関係付けられる例示的非効率性を示す。
図2Bは、NDメッセージプロトコルに関係付けられる別の例示的非効率性を示す。
図3は、インターネット制御管理プロトコルICMPヘッダ形式の実施例を示す。
図4は、NDメッセージのタイプ・長さ・値(TLV)形式の実施例を示す。
図5は、例示的実施形態による、例示的ノードの種々の到達可能性状態を示す状態図である。
図6は、例示的実施形態による、拡張されたスリーピノードのND次期ホップ決定のフロー図である。
図7は、そのデフォルトルータ登録するスリーピノードを示し、スリーピノードの変数は、例示的実施形態に従って登録に含まれている、。
図8は、例示的実施形態による、ルータに問い合わせを行うための呼び出しフローを示す。
図9Aは、いくつかの実施形態による、ノード間で交換することができるメッセージを示す。
図9Bは、いくつかの他の実施形態による、ノード間で交換することができるノードを構成するためのメッセージを示す。
図10は、例示的実施形態による、ネットワーク内のスリーピノードへの要求の記憶および転送を図示する、呼び出しフローである。
図11は、例示的実施形態による、スリーピノードの変数および/または状態を要求ノードに知らせるための呼び出しフローである。
図12は、例示的実施形態による、パケットのスリープ認識リダイレクトのための呼び出しフローである。
図13Aは、1つ以上の開示された実施形態が実装され得る、例示的マシンツーマシン(M2M)またはモノのインターネット(IoT)通信システムの系統図である。
図13Bは、図13Aで図示されるM2M/IoT通信システム内で使用され得る、例示的アーキテクチャの系統図である。
図13Cは、図13Aで図示される通信システム内で使用され得る、例示的M2M/IoT端末またはゲートウェイデバイスの系統図である。
図13Dは、図13Aの通信システムの側面が具現化され得る、例示的コンピュータシステムのブロック図である。

実施例

0008

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

0009

低電力無線パーソナルエリアネットワークを経由したインターネットプロトコルバージョン6(IPv6)(6LoWPAN)は、リソース制約(例えば、IoT)デバイスに好適である、IPv6ネットワーキングプロトコルのバージョンである。6LoWPAN近隣発見変更要求(RFC)6775は、6LoWPANベースのネットワークでの使用を目標にしたIPv6近隣発見のバージョンである。低電力および損失性ネットワークのためのInternet Engineering Task Force(IETF)IPv6ルーティングプロトコル(RPL)は、例えば、無線センサネットワーク(WSN)等のIoTネットワークに好適な軽量IPv6ルーティングプロトコルである。IETFCoAPは、軽量RESTfulアプリケーション/トランスポートプロトコルである。本明細書では、前述のプロトコルが、多くの場合、ノードがスリーピであるかどうかを認識することなく実装されることが認識される。さらに、前述のプロトコルは、多くの場合、スリーピノードのスリープ属性またはスリーピノードのスリープ状態の知識を有することなく実装される。

0010

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

0011

IPv6 NDプロトコルは、5つの異なるインターネット制御管理プロトコル(ICMP)パケットタイプを定義する。パケットタイプは、例えば、IPv4 ICMP RFC 792およびIPv6 ICMP RFC 4443で説明されている。説明されたパケットタイプは、ルータ要請(solicitation)、ルータ広告近隣要請近隣広告、およびリダイレクトを含む。ルータ要請パケットは、インターフェースが有効にされたときに送信され得る。例えば、インターフェースが有効にされたとき、ホストは、予定された時間を待つよりもむしろ、即時にルータ広告を生成するようにルータに要求する、ルータ要請を送信し得る。ルータ広告パケット時間とは、ルータが種々のリンクおよびインターネットパラメータでそれらの存在を広告する、シナリオを指す。広告は、周期的であり得るか、またはルータ要請メッセージに応答し得る。ルータ広告は、別のアドレスが同一のリンクを共有するかどうかを決定する(オンリンク決定)ために使用される、プレフィックスを含み得る。ルータ広告プレフィックスはさらに、アドレス構成、提案ホップ制限値等を示す、プレフィックスを含み得る。近隣要請パケットは、近隣のリンク層アドレスを決定するために、またはキャッシュされたリンク層アドレスを介して近隣が依然として到達可能であることを検証するために、ノードによって送信され得る。近隣要請はまた、重複アドレス検出に使用され得る。近隣広告パケットは、近隣要請メッセージに応答して送信され得る。ノードはまた、リンク層アドレス変更を発表するために、要請なしに(unsolicited)近隣広告を送信し得る。リダイレクトパケットは、特定の宛先のためのより良好な第1のホップをホストに知らせるために、ルータによって使用され得る。

0012

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

0013

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

0014

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

0015

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

0016

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

0017

図2Aおよび2Bを参照すると、例えば、デバイス102のうちの1つ等のスリーピノードのデューティサイクル202が描写されている。示されるように、デューティサイクル202は、ノードが起動したままである期間(例えば、起動期間206)と、スリープ期間208と称され得る、ノードがスリープしている期間とを含む。ND登録寿命は、例えば、ノードのスリープパターンが本質的に周期的である場合、寿命がスリーピノードのデューティサイクル202と調整されるように構成され得る。例示的メッセージ形式200aおよび200bが、それぞれ、図2Aおよび2Bに示されている。図2Aを参照すると、ND登録寿命204aは、起動期間206に合致する持続時間を定義する。図2Bを参照すると、ND登録寿命204bは、ノードのデューティサイクル202に等しい持続時間を定義する。

0018

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

0019

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

0020

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

0021

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

0022

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

0023

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

0024

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

0025

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

0026

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

0027

IPv6および6LoWPAN NDプロトコルは、ICMPメッセージタイプのセットを定義する。ICMPメッセージは、IPパケットのペイロードで搬送される。ICMPメッセージは、IPv4 ICMP RFC 792およびIPv6 ICMP RFC 4443で説明されるように、8バイトヘッダおよび可変サイズデータペイロードを有する。例示的ICMPメッセージ300が、図3で描写されている。図3を参照すると、ICMPヘッダ302の第1の4バイトが、ICMPメッセージタイプにわたって一貫している一方で、ヘッダ302の第2の4バイトは、ICMPメッセージ300のタイプに基づいて変動し得る。示されるように、ICMPタイプフィールド304が、ICMPメッセージ300のタイプを特定するために使用される。コードフィールド306が、ICMPメッセージ300のサブタイプを示すために使用される。チェックサムフィールド308が、エラーチェックに使用され、ICMPメッセージ300のヘッダ302およびペイロード310にわたって計算されるチェックサムを含む。本明細書で説明される例示的実施形態では、IPv6および6LoWPAN NDプロトコルによって使用されるICMPメッセージタイプのセットは、以下のサブセクションで定義されるスリーピノードのND ICMPメッセージ拡張の各々が、以下の実装のうちの1つ以上のものによって実装されるように、拡張される。

0028

1つの例示的実装では、ICMPメッセージタイプは、Internet Assigned Numbers Authority(IANA)レジストリに関する42〜255の範囲内のICMPメッセージタイプを留保することによって定義される。例示的ICMPメッセージは、(例えば、コードフィールド306を使用する)1つ以上のサブタイプ、(例えば、ICMP8バイトヘッダの上位4バイトを使用する)メッセージ特有のヘッダの4バイト、およびメッセージに合わせられることができる値および長さを伴うデータペイロード310をサポートし得る。例えば、これらのサブタイプを使用して、ヘッダの4バイト、およびデータペイロード、スリーピノードの関連情報が、メッセージ300で搬送されることができる。例えば、種々のICMPメッセージタイプが定義しされ、スリーピノードのコンテキスト情報を交換するため、スリーピノードのパラメータ(変数)を構成するため、ノードがスリーピノードの状態の変化を通知されるように、スリーピノードに加入するため、到達不可能なスリーピノードを報告するために使用されることができる。

0029

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

0030

さらに別の代替的実装では、例示的実施形態によると、本明細書で説明されるスリープノードオプションがサポートされるように、NDメッセージオプションタイプが定義される。図4を参照すると、IPv6および6LoWPAN NDプロトコルは、一般的なTLVベースのパケット400を定義し、それは、タイプ・長さ・値(TLV)ベースのオプション400とも称されることができ、例えば、メッセージ300のペイロード310等のICMPNDメッセージのペイロードに含まれることができる。各NDメッセージは、NDプロトコルによって定義されるそれぞれのオプションのセットをサポートする。IPv4 ICMP RFC 792およびIPv6 ICMP RFC 4443によって定義されるようなTLVベースのオプション400の形式が、図4に示されている。図4を参照すると、タイプフィールド402は、8ビットの一意の識別子である。長さフィールド404は、バイト単位TLVパケット400の長さを記憶する8ビットフィールドである。値フィールド406は、オプションタイプに依存し得る、可変長フィールドである。本明細書で説明される例示的実施形態によると、例示的なNDのスリーピノードオプションが、タイプフィールド402の一意の識別子を定義することによってサポートされる。長さおよび値は、各一意の識別子に対応し得る。例えば、表1に記載される、スリーピノードの変数の各々は、タイプフィールド402に対して対応するNDオプションタイプを定義することによって、NDメッセージで搬送され得る。代替として、複数のスリーピノードの変数が、複数のスリーピノードの変数を搬送するための定義された構造を有する、単一のNDオプション内で搬送され得る。

0031

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

0032

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

0033

例示的実施形態によると、ND構成拡張が、NDICMPメッセージの受信側の構成パラメータを特定するために使用され得る。したがって、1つ以上のスリーピノードの変数(例えば、表1に記載されるもの等)は、ND ICMPメッセージを使用して構成され得る。例えば、ノードが構成拡張を伴うND ICMPメッセージを受信するとき、ノードは、ノード上で対応するND変数を構成するためにメッセージを使用し得る。一例として、ルータは、近隣のスリーピノードのスリープ持続時間を調整するために、ルータが送信するルータ広告メッセージ内に構成メッセージを含み得る。ND ICMPメッセージに対する例示的構成拡張を使用して、ルータは、TimeBeforeNextSleep、DurationOfNextSleep、DutyCycleAwakeDuration、DutyCycleSleepDuration等のスリーピノードの変数を構成することができる。

0034

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

0035

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

0036

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

0037

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

0038

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

0039

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

0040

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

0041

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

0042

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

0043

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

0044

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

0045

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

0046

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

0047

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

0048

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

0049

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

0050

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

0051

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

0052

依然として図8を参照すると、818では、第1のルータ804aが、第2の要請メッセージを処理し、第1のルータ804aがルータ要請で特定される基準を満たすことを決定する。820では、第2のルータ804bが、第2の要請メッセージを処理し、第2のルータ804bが第2の要請メッセージで特定される要件のうちの少なくとも1つを満たさないことを決定する。したがって、図示した実施形態によると、ノード802は、その要件を満たすルータ(ルータ804a)を要請することに成功している。822では、第1のルータは、ルータ広告メッセージをノード802に返信し、それによって、824でルータ要請を完了し得る。

0053

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

0054

図9Aを参照すると、901では、ノード802が、所望のスリーピノードのコンテキスト情報を広告する、ルータ要請メッセージをルータ804に送信する。図示した実施例によると、901では、ノード802が、スリーピであるが、現在起動しているルータを要請し、ルータがスリープすることができる前に経過しなければならない時間は、少なくとも50秒である。実施例の目的で秒が使用されるが、任意の時間単位を所望に応じて特定できることが理解されるであろう。別の図示した実施例では、903で、ルータ804のうちの1つが、901でのメッセージに応答して、ルータ広告メッセージをノード802に送信する。具体的には、903では、ルータ804が、それがスリーピルータであり、現在起動状態であり、ルータ804は、1000秒が経過するまでスリープしないであろうことを広告する。別の図示した実施例によると、1006では、ノード802が、起動状態であり、1秒後にスリープし、30秒間スリープするであろう、ルータを要請するために、近隣要請メッセージを送信する。908では、ルータ804のうちの1つが、ルータが起動しており、950秒が経過するまでスリープしないであろうことを広告する、近隣広告メッセージを送信する。別の図示した実施例によると、910では、ノード802が、そのスリーピコテキスト情報を広告するICMPv6メッセージを送信する。具体的には、ノード802は、ノードが起動しており、1秒後にスリープし、30秒間スリープするであろうことをルータ804に広告する。912では、ルータ804のうちの1つが、そのスリーピコンテキスト情報を広告するICMPv6コンテキストメッセージを送信する。具体的には、ルータ804は、ルータが起動しており、950秒が経過するまでスリープしないであろうことをノード802に広告する。

0055

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

0056

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

0057

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

0058

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

0059

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

0060

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

0061

図13Aは、1つ以上の開示された実施形態が実装され得る、例示的マシンツーマシン(M2M)、モノのインターネット(IoT)、またはモノのウェブ(WoT)通信システム10の略図である。例えば、図1−12を参照して説明される種々のスリーピノードは、以下でさらに説明されるように、図13Aで描写される種々のデバイスであり得る。概して、M2M技術は、IoT/WoTのための構成要素を提供し、任意のM2Mデバイス、ゲートウェイ、またはサービスプラットフォームは、IoT/WoTの構成要素ならびにIoT/WoTサービス層等であり得る。

0062

図13Aに示されるように、M2M/IoT/WoT通信システム10は、通信ネットワーク12を含む。通信ネットワーク12は、固定ネットワーク(例えば、Ethernet(登録商標)、ファイバISDN、PLC等)または無線ネットワーク(例えば、WLAN、セルラー等)、もしくは異種ネットワークのネットワークであり得る。例えば、通信ネットワーク12は、音声、データ、ビデオ、メッセージング、ブロードキャスト等のコンテンツを複数のユーザに提供する、複数のアクセスネットワークを備え得る。例えば、通信ネットワーク12は、符号分割多重アクセス(CDMA)、時分割多重アクセスTDMA)、周波数分割多重アクセス(FDMA)、直交FDMA(OFDMA)、単一キャリアFDMA(SC−FDMA)等の1つ以上のチャネルアクセス方法を採用し得る。さらに、通信ネットワーク12は、例えば、コアネットワーク、インターネット、センサネットワーク、工業制御ネットワーク、パーソナルエリアネットワーク、融合個人ネットワーク衛星ネットワークホームネットワーク、または企業ネットワーク等の他のネットワークを備え得る。

0063

図13Aに示されるように、M2M/IoT/WoT通信システム10は、インフラストラクチャドメインと、フィールドドメインとを含み得る。インフラストラクチャドメインとは、エンドツーエンドM2M展開のネットワーク側を指し、フィールドドメインとは、通常はM2Mゲートウェイの後ろにある、エリアネットワークを指す。フィールドドメインは、M2Mゲートウェイ14と、端末デバイス18とを含む。任意の数のM2Mゲートウェイデバイス14およびM2M端末デバイス18が、所望に応じてM2M/IoT/WoT通信システム10に含まれ得ることが理解されるであろう。ゲートウェイデバイス14または端末デバイス18は、上で説明される実施形態によると、スリープ認識動作を行うシステム内のスリーピノードとして構成され得る。ゲートウェイデバイス14および/または端末デバイス18は、上で説明されるノードとして構成され得、したがって、ゲートウェイデバイス14および端末デバイス18の各々は、互のスリープ属性を認識し得る。さらに、ゲートウェイデバイス14の各々は、図12を参照して上で説明されるように、リダイレクトノード1005として構成され得る。M2Mゲートウェイデバイス14およびM2M端末デバイス18の各々は、通信ネットワーク12または直接無線リンクを介して、信号を伝送および受信するように構成される。M2Mゲートウェイデバイス14は、無線M2Mデバイス(例えば、セルラーおよび非セルラー)ならびに固定ネットワークM2Mデバイス(例えば、PLC)が、通信ネットワーク12等のオペレータネットワークを通して、または直接無線リンクを通してのいずれかにおいて、通信することを可能にする。例えば、M2Mデバイス18は、データを収集し、通信ネットワーク12または直接無線リンクを介して、表1で描写されるスリーピ変数等のデータをM2Mアプリケーション20またはM2Mデバイス18に送信し得る。M2Mデバイス18はまた、M2Mアプリケーション20またはM2Mデバイス18からデータを受信し得る。さらに、データおよび信号は、以下で説明されるように、M2Mサービス層22を介して、M2Mアプリケーション20に送信され、そこから受信され得る。M2Mデバイス18およびゲートウェイ14は、例えば、セルラー、WLAN、WPAN(例えば、Zigbee(登録商標)、6LoWPAN、Bluetooth(登録商標))、直接無線リンク、および有線を含む、種々のネットワークを介して通信し得る。端末デバイス18およびゲートウェイデバイス14は、上で説明されるように、NDメッセージを交換するために、種々のネットワークを介して通信し得る。例えば、上で説明されるスリープ認識メッセージングは、複数の端末デバイス18の間で直接、複数のゲートウェイデバイス14の間で直接、または端末デバイス18とゲートウェイデバイス14との間で直接、起こることができる。

0064

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

0065

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

0066

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

0067

本願のスリープ認識動作は、サービス層の一部として実装され得る。本明細書で使用される場合、サービス層とは、アプリケーションプログラミングインターフェースAPI)および基礎的ネットワーキングインターフェースのセットを通して付加価値サービス能力をサポートする、ソフトウェアミドルウェア層を指し得る。ETSIM2MおよびoneM2Mの両方は、本明細書で説明されるコンテキストマネージャを含み得る、サービス層を使用する。ETSI M2Mのサービス層は、サービス能力層(SCL)と称される。本明細書で説明される実施形態は、SCLの一部として実装され得、メッセージは、例えば、MQTTまたはAMQP等の種々のプロトコルに基づき得る。SCLは、M2Mデバイス(デバイスSCL(DSCL)と称される)、ゲートウェイ(ゲートウェイSCL(GSCL)と称される)、および/またはネットワークノード(ネットワークSCL(NSCL)と称される)内で実装され得る。oneM2Mサービス層は、共通サービス機能CSF)(例えば、サービス能力)のセットをサポートする。1つ以上の特定のタイプのCSFのセットのインスタンス化は、異なるタイプのネットワークノード(例えば、インフラストラクチャノード、中間ノード、アプリケーション特有のノード)上でホストすることができる、共通サービスエンティティ(CSE)と称される。さらに、本明細書で説明されるスリープ認識動作は、アクセスするために、サービス指向アーキテクチャ(SOA)および/またはリソース指向アーキテクチャ(ROA)を使用する、M2Mネットワークの一部として実装することができる。

0068

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

0069

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

0070

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

0071

伝送/受信要素36は、信号をM2Mサービスプラットフォーム22に伝送し、またはM2Mサービスプラットフォーム22から信号を受信するように構成され得る。例えば、実施形態では、伝送/受信要素36は、RF信号を伝送および/または受信するように構成されるアンテナであり得る。伝送/受信要素36は、WLAN、WPAN、セルラー等の種々のネットワークおよび無線インターフェースをサポートし得る。実施形態では、伝送/受信要素36は、例えば、IR、UV、または可視光信号を伝送および/または受信するように構成されるエミッタ検出器であり得る。さらに別の実施形態では、伝送/受信要素36は、RFおよび光信号の両方を伝送および受信するように構成され得る。伝送/受信要素36は、無線または有線信号の任意の組み合わせを伝送および/または受信するように構成され得ることが理解されるであろう。

0072

加えて、伝送/受信要素36は、単一の要素として図13Cで描写されているが、M2Mデバイス30は、任意の数の伝送/受信要素36を含み得る。より具体的には、M2Mデバイス30は、MIMO技術を採用し得る。したがって、実施形態では、M2Mデバイス30は、無線信号を伝送および受信するための2つまたはそれを上回る伝送/受信要素36(例えば、複数のアンテナ)を含み得る。

0073

送受信機34は、伝送/受信要素36によって伝送される信号を変調するために、および伝送/受信要素36によって受信される信号を復調するように構成され得る。上記のように、M2Mデバイス30は、マルチモード能力を有し得る。したがって、送受信機34は、M2Mデバイス30が、例えば、UTRAおよびIEEE 802.11等の複数のRATを介して通信することを可能にするための複数の送受信機を含み得る。

0074

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

0075

プロセッサ32は、電源48から電力を受容し得、M2Mデバイス30内の他の構成要素への電力を分配および/または制御するように構成され得る。電源48は、M2Mデバイス30に給電するための任意の好適なデバイスであり得る。例えば、電源48は、1つ以上の乾電池バッテリ(例えば、ニッケルカドミウム(NiCd)、ニッケル亜鉛(NiZn)、ニッケル水素(NiMH)、リチウムイオン(Li−ion)等)、太陽電池燃料電池等を含み得る。

0076

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

0077

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

0078

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

0079

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

0080

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

0081

加えて、コンピュータシステム90は、CPU91から、プリンタ94、キーボード84、マウス95、およびディスクドライブ85等の周辺機器に命令を伝達する責任がある、周辺機器コントローラ83を含み得る。

0082

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

0083

さらに、コンピュータシステム90は、図13Aおよび13Bのネットワーク12等の外部通信ネットワークにコンピュータシステム90を接続するために使用され得る、ネットワークアダプタ97を含み得る。

0084

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

0085

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

0086

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

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ