特許 6276183 互換性がないネットワークルーティングプロトコルを使用する通信ネットワークにわたるデータフレームの伝達

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6276183

(24)【登録日】2018年1月19日

(45)【発行日】2018年2月7日

(54)【発明の名称】互換性がないネットワークルーティングプロトコルを使用する通信ネットワークにわたるデータフレームの伝達

(51)【国際特許分類】

   H04W 80/04 20090101AFI20180129BHJP

   H04W 4/00 20180101ALI20180129BHJP

   H04W 28/06 20090101ALI20180129BHJP

【ＦＩ】

   H04W80/04

   H04W4/00 111

   H04W28/06

【請求項の数】8

【全頁数】62

(21)【出願番号】特願2014-530886(P2014-530886)

(86)(22)【出願日】2012年9月14日

(65)【公表番号】特表2014-530545(P2014-530545A)

(43)【公表日】2014年11月17日

(86)【国際出願番号】US2012055545

(87)【国際公開番号】WO2013040438

(87)【国際公開日】20130321

【審査請求日】2015年9月14日

(31)【優先権主張番号】61/535,316

(32)【優先日】2011年9月15日

(33)【優先権主張国】US

【前置審査】

(73)【特許権者】

【識別番号】512132022

【氏名又は名称】フィッシャー−ローズマウント システムズ，インコーポレイテッド

(74)【代理人】

【識別番号】100079049

【弁理士】

【氏名又は名称】中島 淳

(74)【代理人】

【識別番号】100084995

【弁理士】

【氏名又は名称】加藤 和詳

(72)【発明者】

【氏名】ニクソン マーク ジェイ．

(72)【発明者】

【氏名】ハン ソン

(72)【発明者】

【氏名】ロットボールド エリック

(72)【発明者】

【氏名】チェン デジ

【審査官】 廣川 浩

(56)【参考文献】

【文献】 特開２００６−２７９１６８（ＪＰ，Ａ）

【文献】 特開２００７−０７４１９８（ＪＰ，Ａ）

【文献】 米国特許出願公開第２００９／００７３９８３（ＵＳ，Ａ１）

【文献】 特表２０１０−５０３２７６（ＪＰ，Ａ）

【文献】 米国特許出願公開第２００９／０１０３７３１（ＵＳ，Ａ１）

【文献】 G.Montenegro et al.，Transmission of IPv6 Packets over IEEE802.15.4 Networks，RFC4944，２００７年 ９月

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｂ ７／２４− ７／２６

Ｈ０４Ｗ ４／００−９９／００

３ＰＰ ＴＳＧ ＲＡＮ ＷＧ１−４

ＳＡ ＷＧ１−４

ＣＴ ＷＧ１、４

(57)【特許請求の範囲】

【請求項1】

第１のネットワークルーティングプロトコル、データリンクプロトコル、および物理プロトコルを含む、第１の通信プロトコルを使用する、第１の通信ネットワーク上で通信するための通信デバイスであって、
前記物理プロトコルを使用してデータパケットを受信および送信する、第１の通信ネットワークに連結される物理層要素と、
前記データリンクプロトコルを使用して前記データパケットを符号化および復号する、第１の物理層要素に連結されるデータリンク層スタック要素と、
第１のネットワークルーティング情報が前記第１のネットワークルーティングプロトコルに準拠する、前記第１のネットワークルーティング情報を前記第１の通信ネットワーク上で送信されるデータパケットに追加することによって、前記通信ネットワーク上で送信されるデータパケットを符号化するように動作する、および前記第１の通信ネットワークを介して受信されるデータパケットから第１のネットワークルーティング情報を読み取ることによって、前記第１の通信ネットワークを介して受信されるデータパケットを復号するように動作する、前記データリンク層スタック要素に連結される第１のネットワークルーティング層スタック要素であって、前記第１のネットワークルーティング情報は、前記第１のネットワークルーティングプロトコルに準拠する、第１のネットワークルーティング層スタック要素と、
前記第１のネットワークルーティング層スタック要素を使用して、前記第１の通信ネットワーク上で通信するアプリケーションを実行する、前記第１のネットワークルーティング層スタック要素に連結される第１のアプリケーション層スタック要素と、
第２のネットワークルーティングプロトコルに準拠するデータパケット内の第２のネットワークルーティング情報を符号化および復号するように動作する、前記第１のネットワークルーティング層スタック要素に連結される第２のネットワークルーティング層スタック要素であって、前記第２のネットワークルーティング層スタック要素は、第２のネットワークルーティング情報が前記第１のネットワークルーティングプロトコルとは異なる第２のネットワークルーティングプロトコルに準拠する、前記第２のネットワークルーティング情報を前記第１の通信ネットワーク上で送信されるデータパケットに追加することによって、前記通信ネットワーク上で送信されるデータパケットを符号化するように動作し、および前記第１のネットワークルーティング層スタック要素から受信されるデータパケットから第２のネットワークルーティング情報を読み取ることによって、前記第１のネットワークルーティング層スタック要素から受信されるデータパケットを復号するように動作し、前記第２のネットワークルーティング情報は、前記第２のネットワークルーティングプロトコルに準拠する、第２のネットワークルーティング層スタック要素と、
前記第２のネットワークルーティング層スタック要素を使用するデータパケットを使用して通信する、アプリケーションを実行する、前記第２のネットワークルーティング層スタック要素に連結される第２のアプリケーション層スタック要素と、
を備え、
前記第１のネットワークルーティング層スタック要素は、
前記データパケットが、前記第２のネットワークルーティングプロトコルと関連付けられるデータを含むかどうかを判定するように、前記第１のネットワークルーティングプロトコルに準拠する前記データリンク層スタック要素から、データパケット内の第１のネットワークルーティング情報を復号し、
前記復号されたデータパケットが前記第２のネットワークルーティングプロトコルと関連付けられるデータを含まない場合、前記復号されたデータパケットを前記第１のアプリケーション層スタック要素に送達し、
前記復号されたデータパケットが前記第２のネットワークルーティングプロトコルと関連付けられるデータを含む場合、前記復号されたデータパケットを前記第２のネットワークルーティング層スタック要素に送達し、
前記第１のネットワークルーティング層スタック要素は、前記第１のアプリケーション層スタック要素および前記第２のネットワークルーティング層スタック要素の両方を介して受信される、データパケットを符号化する、
通信デバイス。

【請求項2】

前記第２のネットワークルーティング層スタック要素は、
その中に第２のネットワークルーティング情報を含むようにデータパケットを符号化し、
符号化された前記データパケットのそれぞれを２つ以上のデータパケットに断片化し、
断片化された前記データパケットを前記第１のネットワークルーティング層スタック要素に提供する、
パケットフラグメンタを含む、請求項１に記載の通信デバイス。

【請求項3】

前記第２のネットワークルーティング層スタック要素は、その中に前記第２のネットワークルーティング情報を含むデータパケットを生じるように、前記第１のネットワークルーティング層スタック要素から受信される２つ以上のデータパケット断片を組み立てる、デフラグメンタを含む、請求項２に記載の通信デバイス。

【請求項4】

前記第１のネットワークルーティング層スタック要素は、前記第１のネットワークルーティングプロトコルに準拠する前記データリンク層スタック要素から受信された前記データパケット内の第１のネットワークルーティング情報内の識別子を読み取ることによって、前記第１のネットワークルーティング情報を復号する、請求項１〜３のいずれか一項に記載の通信デバイス。

【請求項5】

前記第１のネットワークルーティング層スタック要素は、データパケットが前記第２のネットワークルーティングプロトコルと関連付けられるデータを含むという識別子を、前記第２のネットワークルーティング層スタック要素から受信されるデータパケット内の前記第１のネットワークルーティング情報内に配置することによって、前記第２のネットワークルーティング層スタック要素から受信される前記データパケット内の第１のネットワークルーティング情報を符号化する、請求項１〜４のいずれか一項に記載の通信デバイス。

【請求項6】

前記第１の通信ネットワークのトランスポートプロトコルに従って、データパケットのトランスポート情報符号化および復号を行う、前記第１のネットワークルーティング層スタック要素と前記第１のアプリケーション層スタック要素との間に連結される第１のトランスポート層スタック要素をさらに含む、請求項１〜５のいずれか一項に記載の通信デバイス。

【請求項7】

第２の通信ネットワークのトランスポートプロトコルに従って、データパケットのトランスポート情報符号化および復号を行う、前記第２のネットワークルーティング層スタック要素と前記第２のアプリケーション層スタック要素との間に連結される第２のトランスポート層スタック要素をさらに含む、請求項６に記載の通信デバイス。

【請求項8】

前記第２のネットワークルーティングプロトコルは、インターネットプロトコルルーティングを使用するインターネットプロトコル（ＩＰ）であり、
前記第１のネットワークルーティングプロトコルは、非ＩＰプロトコルである、
請求項１〜７のいずれか一項に記載の通信デバイス。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、第２のネットワークルーティングプロトコルを使用してネットワーク上で送信される１つのネットワークルーティングプロトコルを使用して、通信データフレームのルーティングを可能にするように、異なる通信ネットワークを介して、デバイス間でデータフレームを受信、処理、および伝送することに関する。

【背景技術】

【0002】

当初は、プロセスプラントにおいてプロセス制御を達成するために採用されたプロセス制御システムおよびフィールドデバイスは、概して、分散様式で監視および制御されていた。標準化通信プロトコルおよび計算能力を欠いていたため、閉ループ監視および制御は、原位置がプロセスプラント自体に局所的であったプラントオペレータに委ねられたものであった。遠隔集中プロセス制御監視および制御の必要性は、例えば、周知の２線式４〜２０ｍＡ電流ループ計器および他の２点間配線通信システムを採用する、フィールドデバイスの開発ならびに展開をもたらした。

【0003】

低費用で低電力のコンピュータデバイスの可用性が、増進した処理能力（マイクロプロセッサ）および電気通信能力を装備した知的フィールドデバイスの展開を助長した。知的フィールドデバイスは、現在ではますます、相互に、および自動制御を行うように集中プロセス制御システムと通信（ネットワーク化）することができる。この向上したネットワーキング能力は、増進したプロセスプラント制御、その結果として、向上したプロセスプラント出力に変わった。

【0004】

プロセス制御業界で知的フィールドデバイスの受け入れを向上させることに配慮し、部分的に、これらのフィールドデバイス間の内部運用性を向上させるために、フィールドデバイスベンダは、プロセスプラント間フィールドデバイス通信を可能にするように、いくつかのデジタルネットワークプロトコルを開発し、標準化した。標準のうちのいくつか、例えば、ハイウェイアドレス可能遠隔トランスデューサ（ＨＡＲＴ）プロトコルは、フィールドデバイス間でデジタル情報を伝送および受信するように、現在ではプロセスプラント作業場の至る所にある、既存のアナログ２線式４〜２０ｍＡインフラストラクチャを活用したため、特に魅力的であった。他の標準は、ＦＯＵＮＤＡＴＩＯＮ（登録商標）フィールドｂｕｓ標準、Ｐｒｏｆｉｂｕｓ標準等のバスベースのシステムを含んだ。

【0005】

最終的に、計算能力の増加、構成要素統合の増加、および信号処理の一般分野における発展が、プロセス制御業界で使用するための低域で低スループットの無線周波数（ＲＦ）または無線通信標準を開発および展開することを経済的に実行可能にした。これらのプロトコルのうちのいくつかは、２．４ＧＨｚ帯域等の、認可されていない、または認可が緩い、工業、科学、および医療（ＩＳＭ）電磁周波数で動作するように開発された。ＩＳＭ帯域内でそのような低域で低スループットのＲＦ通信プロトコルをサポートする、フィールドデバイスが、プロセスプラント環境で展開され、かつ展開され続けている。無認可であっても、政府機関が、最大伝送電力を制限し得る、規制を制定し得る。したがって、頻繁に、そのようなプロトコルは、低電力通信プロトコルと呼ばれる。また、例えば、ＨＡＲＴプロトコルを含む、いくつかの有線ネットワークプロトコルが、そのようなフィールドデバイスの無線能力を活用するように適合された。具体的には、ＷｉｒｅｌｅｓｓＨＡＲＴプロトコルが、有線ＨＡＲＴプロセスプラントネットワーク内のＷｉｒｅｌｅｓｓＨＡＲＴ対応フィールドデバイスの相互運用性を活用して可能にするように、有線ＨＡＲＴプロトコルから進化した。これらの改良にもかかわらず、プロセスプラント通信は、概して、非常に特異的なロバスト性およびセキュリティの問題を有する、プロセスプラント環境に限定される。

【0006】

しかしながら、別個の業界では、およそ１９６０年代に始まって、パーソナルコンピュータが、ますます世界中で一般的になってきた。同時に、汎用コンピュータネットワーキングの分野で遂げられた進歩は、それを介してパーソナルコンピュータが相互にシームレスに通信する、インターネットの構築につながった。このシームレスな通信は、大部分が、インターネットプロトコルバージョン４（ＩＰｖ４）の受け入れおよび順守によって可能にされてきた。ＩＰｖ４プロトコルは、部分的に、ネットワーク、一般的には、インターネットを介して通信するコンピュータに、一意的なＩＰアドレスを割り当てる。ＩＰｖ４の広範囲に及ぶ受け入れを予想することができず、ＩＰｖ４仕様の開発者は、コンピュータのＩＰアドレスの最大サイズを３２ビットに制約した。しかしながら、サーバ、ハンドヘルドコンピュータ、およびパーソナルコンピュータを含む、相互接続されたコンピュータの増設は、ＩＰｖ４アドレスが予知できる未来に使い尽くされ得る状況を生み出してきた。この状況を先制して阻止するために、新たに提案されたＩＰｖ６プロトコル標準は、部分的に、ＩＰアドレス空間または長を１２８ビットに増加させる。数学的に、これは、３．４×１０^３８個の一意的なＩＰｖ６アドレスに変わる。いずれにしても、有線および無線環境の両方でルーティングおよび他の通信活動を行うためのインターネットプロトコル（本明細書では、概して、ＩＰまたはＩＰネットワークプロトコルと呼ばれる）の使用が、普及してきた。実際に、デバイス外で通信するために現在開発されているほとんどのアプリケーションは、通信のバックボーンとして、またはネットワーク通信を行うために、インターネットプロトコルを使用して開発される。

【0007】

また、プロセスプラント業界での必要性は、ますます、一般コンピューティング技術で遂げられている発展に関係または関連してきている。例えば、精油所、油田、および採掘作業所等のプロセスプラントが、ますます、原材料の場所に近い、地球の最遠隔の隅々で開発されている。グローバル化の増加により、これらのプラントは、別個の大陸上ではないにしても、少なくとも別個の国に位置する、複合企業によって、所有、監視、および制御されている。そのようなプロセスプラントの場所における地政学的な不安定性、天候条件、および／または住みやすい条件の入手不能性が、企業に、そのようなプロセスプラントを遠隔で監視および制御するための手段を探すことを余儀なくさせてきた。携帯電話、セキュリティ監視アプリケーション等の他の種類のネットワーク通信で使用されている、汎用コンピュータネットワーキングの進歩の多くの用途があるが、既存のプロセス制御ネットワークプロトコルは、設備が不十分であり、概して、有意な支援通信インフラストラクチャがないプロセスプラント環境内で、これらのプロトコルの統合を可能にする、ＩＰｖ４またはＩＰｖ６等の汎用コンピュータネットワークプロトコルと互換性がない。実際に、既存のプロセス制御ネットワークプロトコルの大部分は、ＩＰｖ４またはＩＰｖ６通信プロトコル等の現在ではより一般的または包括的な汎用コンピュータプロトコルとは独立して、またはそれらとは関係なく、開発された。さらに、１２８ビット暗号化等の汎用コンピュータプロトコルで利用可能であるロバストなセキュリティ機構は、プロセスプラント作業場ネットワークまで進展しておらず、再度、制御されたプラント環境外にプロセスプラントネットワークを拡張する能力を制限する。実際に、セキュリティ特徴を実装する、全てではないにしても、ほとんどのプロセスプラント通信プロトコルは、広く採用されているＩＰｖ４およびＩＰｖ６セキュリティプロトコルと互換性がない。

【0008】

しかしながら、新たに拡張されたＩＰｖ６アドレス空間を用いて、ＩＰｖ６アドレスとの通信が可能であるプロセスプラント内で各知的フィールドデバイスを割り当てることが、現在は実行可能であり得る。したがって、プラント環境内で通信を行うため、およびこれらの通信をプラント外のデバイスまで容易に拡張可能にするために、ＩＰｖ４またはＩＰｖ６等の汎用コンピュータネットワーキングプロトコルを単純に使用することが、極めて有利になるであろう。しかしながら、全ての知的フィールドデバイスが、ＩＰｖ４またはＩＰｖ６プロトコルに準拠するか、またはそれを使用するように適合されるわけではなく、または容易に適合できるわけではなく、したがって、プロセスプラント環境内で通信および他のルーティング機能を果たすためにＩＰｖ４またはＩＰｖ６通信プロトコルを使用することは、現在実行可能ではない。具体的には、限定されたフィールドデバイスメモリおよび処理能力等のハードウェア制約が、ＩＰｖ４またはＩＰｖ６プロトコルに準拠している、またはそれをサポートするために必要とされるソフトウェアおよび／またはハードウェアを用いて、既存のフィールドデバイスを改造することを技術的に実行不可能にする。同様に、プロセスプラント作業場で遭遇するもの等の、現在の特殊用途ネットワークで実装される既存の低電力で低スループットの通信プロトコルを実装する全ての知的フィールドデバイスを、ＩＰｖ６使用可能フィールドデバイスと交換することは、経済的に実行可能ではない。結果として、たとえプロセスプラント内の多くのコンピュータデバイスが、ＩＰｖ４またはＩＰｖ６通信プロトコル環境内で使用するために開発されるアプリケーションを実行できること、またはそのような通信ネットワークプロトコルを使用するプロセスプラントネットワーク外のデバイスと容易に通信できることから利益を享受し得るとしても、プロセスプラントの中のデバイス内または間で通信を行うために、周知かつ現在では遍在的なＩＰｖ４またはＩＰｖ６プロトコルを使用することは、現在実行可能ではないか、またはあまり実用的ではない。結果として、同時にインターネット上のどこにでも位置するデバイスと通信するように適合される一方で、レガシー無線プロセスプラントネットワーク内で動作するように適合される、フィールドデバイスの必要性がある。

【発明の概要】

【0009】

通信方法は、非ＩＰネットワークルーティングプロトコルを使用する通信ネットワーク、すなわち、メッシュネットワークルーティングプロトコル、または明示宛先アドレス指定プロトコルであるＩＰネットワークルーティングプロトコル以外であるか、またはそれとは互換性がない、暗示宛先あるいはアドレス指定ルーティングプロトコル等のネットワークルーティングプロトコルを実装する通信ネットワーク上で、ＩＰｖ６データフレームまたは他のタイプの汎用コンピュータデータフレーム等のインターネットプロトコル（ＩＰ）データフレームをシームレスに伝送するように動作する。ＷｉｒｅｌｅｓｓＨＡＲＴプロトコルは、（暗示宛先またはアドレス指定ネットワークルーティングプロトコルでもあり、ネットワーク層においてグラフルーティングを使用する）非ＩＰ通信ネットワークの実施例であるため、ＩＰネットワークルーティングプロトコル、例えば、ＩＰアドレスルーティングまたは明示宛先アドレス指定を使用するプロトコルを使用する、ＩＰデータフレームのルーティングを本質的にサポートしない。この通信方法は、例えば、非ＩＰ通信ネットワーク（ＷｉｒｅｌｅｓｓＨＡＲＴ通信プロトコル等のＩＰベースのネットワークルーティングを使用しないネットワーク）を使用するプロセスプラントネットワーク内のフィールドデバイスまたは他の知的デバイスが、プロセスプラントネットワーク内またはプロセスプラントネットワーク外のいずれかで、インターネットプロトコル使用可能デバイスによって生成および受信されるＩＰデータフレームを使用して、メッセージルーティングを行うことを可能にする。重要なことに、本通信方法は、ＩＰベースの通信ネットワーク内で後にメッセージをルートするため、またはＩＰ使用可能デバイスにおいてＩＰメッセージデータフレームを復号して使用するために必要とされる、ＩＰデータフレームのＩＰネットワークルーティング情報を保存しながら、非ＩＰ通信ネットワーク内でＩＰデータフレームを伝送するために非ＩＰ通信ネットワークのネットワークルーティングまたはネットワークルーティングプロトコル構造（メッシュネットワークルーティングプロトコル、または暗示宛先あるいはアドレス指定ルーティングプロトコル等）を使用するため、本通信方法は、非ＩＰ通信ネットワーク内の通常の通信に影響を及ぼさない、または変更しない。概して、この通信方法は、標準ＩＰネットワーク通信を行うために、（非ＩＰ通信ネットワーク内、または非ＩＰ通信ネットワーク外のいずれかで）デバイス内のＩＰ使用可能アプリケーションによってＩＰデータフレームを使用することができるように、ネットワークルーティング経路全体に沿って、および非ＩＰ通信ネットワークとＩＰ通信ネットワークとの間の遷移点において、ＩＰネットワークルーティング情報を保存する。

【0010】

本質的に、本明細書で説明される通信方法は、非ＩＰ通信ネットワークがＩＰデータフレームまたはＩＰネットワークルーティングプロトコルの伝送を本質的にサポートしないときでさえも、非ＩＰネットワークルーティングプロトコルに準拠する通信チャネルを介して、ＩＰデータフレームを伝送および受信するために、非ＩＰ通信ネットワークのネットワークルーティング構造または機構を使用する。本通信方法は、概して、アプリケーションが存在するデバイス内のＩＰデータフレームおよびＩＰスタックを使用して通信するアプリケーションによって、ＩＰ通信ネットワーク内でＩＰネットワークルーティング情報（ＩＰネットワークルーティングプロトコル情報）を使用することができるように、この情報をデータフレーム内で保存しながら、非ＩＰ通信ネットワークのネットワークルーティング機構（ネットワークルーティングプロトコル情報）を使用して、非ＩＰ通信ネットワーク上でＩＰデータフレームをルートすることによって動作する。この特徴は、標準ＩＰデータフレームが、非ＩＰ通信ネットワークのプロトコルスタック（例えば、データリンク層機構および物理層構造）を使用する非ＩＰ通信ネットワークに従って構成されるデータフレームとともに、またはそれと同時に、送信されることを可能にする。ある場合では、本方法は、ＩＰデータフレームを１つ以上の断片に断片化し、例えば、６ＬｏＷＰＡＮプロトコルの一部として開発または提供される断片化技法を使用して、非ＩＰ通信ネットワークの通信チャネルを介して、断片化データフレームをルートしてもよい。

【0011】

有利なことに、本明細書で説明される通信方法は、非ＩＰ通信ネットワーク上のデバイスの処理能力または機能を有意に変化または増大させる必要なく、これらのネットワークにわたってＩＰデータフレームをシームレスに伝達することができるように、ＩＰ通信ネットワークが、プロセス制御情報の送信と関連付けられる特殊通信ネットワーク等の非ＩＰ通信ネットワークにシームレスに接続されることを可能にする。加えて、この通信方法は、ＩＰネットワークルーティングを実装することを非ＩＰ通信ネットワークに強制する必要なく、通信経路の一部分に非ＩＰ通信ネットワークのネットワークルーティング機構を使用し、および通信経路の別の部分にＩＰ通信ネットワークのネットワークルーティング機構を使用して、非ＩＰ通信ネットワーク内で動作するデバイスにおいて生成されるＩＰデータフレームが、（例えば、インターネットを介して）ＩＰ準拠通信ネットワーク内のデバイスに直接送信されることを可能にする。また、本方法は、非ＩＰ通信ネットワーク上で通信を行うために、ＩＰ使用可能スタックを非ＩＰ通信ネットワーク内で動作するデバイスの全てに提供する必要なく、ＩＰ通信ネットワーク内で生成されるＩＰデータフレームが、ＩＰデータフレームとして非ＩＰ通信ネットワーク内のデバイスに送信され、デバイスによって受信されることも可能にする。結果として、この方法は、非ＩＰ通信ネットワーク上のデバイス内で実行されるＩＰデータフレームまたはＩＰベースの通信を生成、受信、および使用し、かつＩＰデータフレームを使用して、非ＩＰ通信ネットワーク上のデバイス内のアプリケーション、またはＩＰ通信ネットワーク等の他のネットワーク上のデバイスのいずれかに、依然として通信するように開発される、ソケットベースのアプリケーションを可能にする。結果として、ＩＰ通信を使用し、それに依存するアプリケーション（例えば、ソケットベースのアプリケーション）は、非ＩＰ通信ネットワーク内のデバイス上で実行することができ、ＩＰデータフレームを使用して、非ＩＰ通信ネットワーク内のデバイスまたは非ＩＰ通信ネットワークに外部から接続されたデバイス上で動作する他のアプリケーションとシームレスに通信することができる。この利点は、異なるタイプの通信ネットワークにわたって使用されるアプリケーションの広範囲の相互運用性を提供する。

【0012】

また、ＩＰデータフレームを生成するため、および非ＩＰ通信ネットワークのネットワークルーティング機構を介してこれらのＩＰデータフレームを送信するために、アプリケーションによって使用することができる関数呼び出しをプログラマに提供することによって、通信方法を実装するために、アプリケーションプログラミングインターフェース（ＡＰＩ）が使用されてもよい。このＡＰＩは、プログラマが、非ＩＰ通信ネットワーク内および外の両方でＩＰベースの通信を提供するように、非ＩＰ通信ネットワーク内でソケットベースのアプリケーションを効率的に設定して使用することを可能にする。また、ソフトウェア開発キット（ＳＤＫ）等のプログラミング環境は、ユーザが、アプリケーションが実行される非ＩＰ通信ネットワーク内で動作するデバイスを選択すること、ＩＰデータフレームを生成するデバイス用のアプリケーションを開発すること、非ＩＰ通信ネットワークのネットワークルーティング機構を介してこれらのＩＰデータフレームを送信すること、およびアプリケーションを試験することを可能にすることによって、非ＩＰ通信ネットワーク内のデバイス上で実行されるアプリケーションをプログラムすることにおいてユーザを支援してもよい。プログラミング環境は、いったん開発されると、アプリケーションを、ＩＰデータフレームの形態で、非ＩＰ通信ネットワーク内で動作するデバイスに伝送する、ルーチンを含んでもよい。

【図面の簡単な説明】

【0013】

【図1】そのうちのいくつかが、ＩＰネットワークルーティングプロトコルをサポートし、そのうちのいくつかが、ＩＰネットワークルーティングプロトコルをサポートしない、非ＩＰ通信ネットワーク内のデバイスが、ネットワーク内で、または異なる通信ネットワークにわたって、ＩＰデータフレームを受信および伝送することができる、通信システム例を図示する。

【図2A】ネットワークデバイスの通信スタック内の標準ＩＰデータフレームの作成を図示する。

【図2B】ＩＰデータフレームが非ＩＰ通信ネットワーク上でルートされることを可能にするための、本明細書で説明される通信方法に従ったＩＰデータフレームの作成を図示する。

【図3】ＩＰネットワークルーティングプロトコルを使用またはサポートしない非ＩＰ通信ネットワークを介して、ＩＰデータフレームを作成および送信する方法を図示する。

【図4A】第１のＩＰネットワークルーティングプロトコルを使用する第１のネットワーク内でＩＰデータフレームを生成するために、およびこのデータフレームを、メッシュネットワークルーティングプロトコル、または暗示宛先あるいはアドレス指定ルーティングプロトコル等の非ＩＰネットワークルーティングプロトコルを使用する第２のネットワーク内のデバイスに送信するために使用され得る、通信方法のフローチャートである。

【図4B】メッシュネットワークルーティングプロトコル、または暗示宛先あるいはアドレス指定ルーティングプロトコル等の非ＩＰネットワークルーティングプロトコルを使用するネットワーク内で、ＩＰデータフレームを生成するため、およびこのデータフレームを、ＩＰネットワークルーティングプロトコル、または明示宛先あるいはアドレス指定ルーティングプロトコルを使用するネットワーク内のデバイスに送信するために使用され得る、通信方法のフローチャートである。

【図5】ＷｉｒｅｌｅｓｓＨＡＲＴフィールドデバイスが、ＩＰｖ６ネットワークルーティングプロトコルをサポートまたは実装する通信ネットワークを使用して、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク内で、および異なるＷｉｒｅｌｅｓｓＨＡＲＴネットワーク間で、ＩＰｖ６データフレームを受信および伝送するように動作し得る、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク例を図示する。

【図6】それを介して、遠隔接続されたコンピュータデバイスが、ＩＰｖ６データフレームを利用してＷｉｒｅｌｅｓｓＨＡＲＴフィールドデバイスと通信し得る、別のＷｉｒｅｌｅｓｓＨＡＲＴネットワーク例を図示する。

【図7】非ＩＰ通信ネットワーク上でＩＰｖ６データフレームのルーティングを同時にサポートしながら、例えば、インターネットから、ＩＰｖ６データフレームを受信および伝送するためにゲートウェイデバイスで使用され得る、ネットワークプロトコルスタック例のブロック図である。

【図8】ＷｉｒｅｌｅｓｓＨＡＲＴ通信ネットワーク上のデバイスを往復して、ＩＰｖ６データフレームならびにＷｉｒｅｌｅｓｓＨＡＲＴデータフレームを受信および伝送するために使用され得る、ネットワークプロトコルスタック例のブロック図である。

【図9】ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク等の非ＩＰ通信ネットワーク上でＩＰｖ６データフレームのルーティングを提供するように、ＷｉｒｅｌｅｓｓＨＡＲＴ通信ネットワーク内で動作するフィールドデバイスまたはゲートウェイにおいて実装され得る、６ＬｏＷＰＡＮブロック例のブロック図である。

【図10A】図８の６ＬｏＷＰＡＮブロック例で実装され得る、断片化モジュール例のブロック図である。

【図10B】図８の６ＬｏＷＰＡＮブロック例で実装され得る、再組立モジュールのブロック図である。

【図11A】受信したＩＰｖ６データフレームからのＷｉｒｅｌｅｓｓＨＡＲＴネットワークルーティングプロトコルヘッダカプセル化ＩＰｖ６データフレーム断片の生成を図示する。

【図11B】ＩＰｖ６データフレームを示すために利用され得る、ＷｉｒｅｌｅｓｓＨＡＲＴネットワークルーティングプロトコルヘッダの中のデータフィールド例を図示する。

【図11C】ＩＰｖ６データフレームを受信および伝送するために利用され得る、いくつかの可能なセキュリティ機構を示すために利用され得る、ＷｉｒｅｌｅｓｓＨＡＲＴネットワークルーティングプロトコルヘッダのデータフィールド例を図示する。

【図12】ＷｉｒｅｌｅｓｓＨＡＲＴ通信ネットワーク内でＩＰｖ６データフレームおよびＷｉｒｅｌｅｓｓＨＡＲＴデータフレームをルートするように第１の通信技法例を実装する、ＷｉｒｅｌｅｓｓＨＡＲＴ通信ネットワーク上の一組のＷｉｒｅｌｅｓｓＨＡＲＴデバイスを図示する。

【図13】ＷｉｒｅｌｅｓｓＨＡＲＴ通信ネットワーク内でＩＰｖ６データフレームおよびＷｉｒｅｌｅｓｓＨＡＲＴデータフレームをルートするように第２の通信技法例を実装する、ＷｉｒｅｌｅｓｓＨＡＲＴ通信ネットワーク上の一組のＷｉｒｅｌｅｓｓＨＡＲＴデバイスを図示する。

【図14】ＩＰｖ６データフレームまたはＩＰｖ６ネットワークルーティング機構をサポートしないＷｉｒｅｌｅｓｓＨＡＲＴデバイスを使用して、ＷｉｒｅｌｅｓｓＨＡＲＴ通信ネットワーク内でＩＰｖ６データフレームおよびＷｉｒｅｌｅｓｓＨＡＲＴデータフレームをルートするように第３の通信技法例を実装する、ＷｉｒｅｌｅｓｓＨＡＲＴ通信ネットワーク上の一組のＷｉｒｅｌｅｓｓＨＡＲＴデバイスを図示する。

【図15】ＷｉｒｅｌｅｓｓＨＡＲＴ通信ネットワークを介してＩＰｖ６データフレームを受信および伝送するために、フィールドデバイスのアプリケーションプログラミングインターフェース（ＡＰＩ）を利用するように構成される、カスタムアプリケーションを生成するために利用されてもよい、ＳＤＫ例のブロック図である。

【発明を実施するための形態】

【0014】

一般的に言えば、複数の異なる通信ネットワーク上で、ＩＰデータフレーム等の第１のネットワークルーティングプロトコルに基づいて作成されるデータフレームをシームレスに伝達するためのシステムおよび方法は、第１のネットワークルーティングプロトコル、例えば、インターネットプロトコルバージョン６（ＩＰｖ６）プロトコル、または任意の他の明示宛先あるいはアドレス指定ルーティングプロトコル、またはネットワークトポロジーアドレス指定プロトコルと関連付けられる、ネットワークルーティングプロトコル情報（ネットワークルーティング情報とも呼ばれる）を伴って構成されるデータフレームを作成または受信することと、第１のネットワークルーティング情報を維持しながら、ＷｉｒｅｌｅｓｓＨＡＲＴネットワークルーティングプロトコル、または任意の他のメッシュネットワーク、暗示宛先あるいはアドレス指定または非ネットワークトポロジーアドレスベースのルーティングプロトコル等の第２のネットワークルーティングプロトコルによって定義されるようなネットワークルーティングプロトコル情報を追加することと、データフレーム内で第１のネットワークルーティングプロトコルのネットワークルーティング情報を維持しながら、第２の通信ネットワーク上でデータフレームを伝達するために第２の通信ネットワークのネットワークルーティング機構およびプロシージャを使用することとを含む。また、本システムおよび方法は、データフレームが方向付けられるアプリケーションを有するデバイス、または第２の通信ネットワーク内のゲートウェイデバイスにおいて等、例えば、第２の通信ネットワーク内の端末デバイスにおいて、データフレームを復号してもよく、インターネット等の第１のネットワークルーティングプロトコルに準拠する通信ネットワーク内の元のデータフレームの通信を指図するため、または第１のネットワークルーティングプロトコルに準拠するデータフレームを用いてメッセージに応答するために、第１のネットワークルーティングプロトコルのネットワークルーティング情報を使用してもよい。

【0015】

背景として、概して、本明細書では明示宛先（明示アドレス指定とも呼ばれる）ルーティングプロトコルおよび暗示宛先（本明細書では、暗示アドレス指定とも呼ばれる）ルーティングプロトコルと呼ばれる、２つのタイプのネットワークルーティングプロトコルがある。明示宛先または明示アドレス指定ネットワークルーティングプロトコルは、概して、ネットワーク上でルートされるデータパケットの内側に配置されるネットワークルーティング情報の一部として、１つ以上の宛先または宛先アドレスを定義し、そのアドレスは、ネットワーク内の中間デバイスがネットワーク内でルーティングを行うために十分である。送信されているパケット内のネットワークルーティング情報内の宛先情報または宛先アドレスは、パケットが送達されるネットワーク内のデバイスまたは論理位置（宛先）を明示的に（すなわち、それら自体で、または独力で）定義する。このアドレス情報は、データパケットを宛先アドレスと関連付けられる宛先デバイスにルートするために（ネットワーク内のデバイスによって作成されるルーティングテーブルとともに）使用される。データパケットのＩＰ宛先アドレスは、概して、ネットワーク上のデバイスがネットワーク内でデータパケットをルートすることを可能にするために、パケットから必要とされる唯一の情報であるため、ＩＰアドレス指定またはＩＰネットワークルーティングプロトコルは、明示宛先またはアドレス指定ルーティングプロトコルの特定の実施例である。実際に、ＩＰアドレス指定は、宛先アドレスを伴うデバイスに到達するために必要とされる、ルートまたはネットワークトポロジーの関数である、アドレス（例えば、宛先アドレス）を使用する。つまり、ＩＰアドレスは、それを通して宛先デバイスが到達可能である中間デバイスへパケットを送信するように、デバイスがネットワーク内でパケットをルートすることを可能にするか、または支援するよう、ネットワークのトポロジー内のデバイスの場所（ＩＰアドレスが割り当てられる）の関数として、作成されるか、または割り当てられる。したがって、ＩＰアドレス指定は、ネットワークトポロジーベースまたは依存性であるため、本明細書ではネットワークトポロジーベースのアドレス指定プロトコルとも呼ばれる。概して、中間ルーティングデバイスにおける不十分な出力により、またはデバイス間の距離によるネットワーク内のデバイス間の通信チャネルの損失により、ネットワーク内で失われている（ルートされていない）パケットの懸念がほとんどまたは全くないため、多くの２点間有線または高出力ネットワークルーティングプロトコル（ＩＰルーティングプロトコルを含む）は、明示宛先ルーティングまたは宛先アドレス指定ルーティング（ネットワークトポロジーベースのアドレス指定を含む）を使用する。

【0016】

他方で、暗示宛先ルーティングまたは暗示アドレス指定ルーティングは、パケットがネットワークを通してルートされる方法を定義するために、データパケット内の宛先アドレス以外の他の情報を使用する。いくつかの暗示宛先ルーティング技法は、例えば、ネットワークを通した種々のルートを定義するグラフが定義され、次いで、特定のデータパケットがネットワークを通してルートされるであろう方式を示すために使用される、グラフルーティングと呼ばれる概念を使用する。グラフルーティングの使用により、各データパケットは、特定のパケットのためにネットワーク内でルーティングを行うために使用されるグラフを識別する、グラフ識別子（グラフＩＤ）の形態で、ネットワークルーティング情報を提供される。場合によっては、グラフルーティングを使用するネットワークルーティングプロトコルはまた、パケットの中で提供されるネットワークルーティング情報内に１つ以上の宛先アドレスも含むが、これらのアドレスは、パケットのネットワークルーティング情報内のグラフＩＤまたは他の情報と併せて使用され、したがって、それら自体で、かつ独力で、通信ネットワーク内でルーティングを行うために十分ではない。当然ながら、グラフルーティングは、暗示宛先ルーティング技法の一実施例にすぎない。

【0017】

実際に、多くのメッシュ無線ネットワークは、通信スタックまたはネットワーク内のデバイスの電力（バッテリ）容量に過度な負荷をかけることなく、接続性を確保するように、データパケットがネットワークを通して特定の方式でルートされることを確実にする必要があるため、およびこれらのネットワークは、ルーティングに宛先アドレスを使用せず、または使用する場合は、ネットワーク内のデバイスの場所に依存する方式で宛先アドレスを割り当てず（アドレスがネットワークトポロジー依存性ではない）、それにより、宛先アドレスのみに基づいてネットワークルーティングを行うことを困難にするため、これらのネットワークは、グラフルーティング技法等の暗示ネットワークルーティング技法を使用する。これらの理由により、ほとんどのメッシュネットワークルーティングプロトコルは、ＩＰアドレスルーティング等の明示宛先ルーティングを使用せず、実際には、そのようなルーティングプロトコルと互換性がない。

【0018】

一般的に言えば、メッシュネットワークは、各ノードが各自のデータを捕捉して広めるだけでなく、他のノードのための中継としての機能も果たさなければならず、したがって、各ノードが、ネットワーク内でデータを伝搬するように協働しなければならない、あるタイプのネットワーキングである、メッシュネットワーキング（トポロジー）を使用する。無線メッシュネットワーク（ＷＭＮ）は、メッシュトポロジーにおいて組織化される無線ノードで構成される通信ネットワークである。無線メッシュネットワークはしばしば、メッシュクライアント、メッシュルータ、およびゲートウェイを含む。メッシュクライアントが、しばしば、ラップトップ、携帯電話、および他の無線デバイスである一方で、メッシュルータは、インターネットに接続し得るが、その必要はない、ゲートウェイを往復してトラフィックを転送する。単一のネットワークとして稼働する無線ノードの受信可能域は、メッシュクラウドと呼ばれることもある。このメッシュクラウドへのアクセスは、無線ネットワークを作成するように相互と調和して稼働する無線ノードに依存している。メッシュネットワークは、信頼性があり、冗長性を提供する。１つのノードがもはや動作できなくなったとき、他のノードは、直接的に、または１つ以上の中間ノードを通して、依然として相互と通信することができる。メッシュネットワークルーティング技法の実施例は、ＺｉｇＢｅｅネットワークによって使用されるアドホックオンデマンド距離ベクトルルーティング、およびＷｉｒｅｌｅｓｓＨＡＲＴネットワークで採用されるグラフルーティングを含む。ＡＯＤＶでは、宛先デバイスを見出すために、デバイスが、ルート要求をその隣接デバイス等の全てにブロードキャストする。次いで、隣接デバイスは、宛先に到達するまで、要求をそれらの隣接デバイス等にブロードキャストする。いったん宛先に到達すると、それは、ソースに戻る最低費用の経路を辿るユニキャスト伝送を介して、そのルート返信を送信する。いったんソースが返信を受信すると、経路における次のホップおよび経路費用を用いて、宛先アドレスのそのルーティングテーブルを更新するであろう。経路費用は、距離に対応するホップの数を含んでもよい。

【0019】

ここで図１を参照すると、異なる通信ネットワークと関連付けられる複数の異なる物理ネットワーク内で、またはそれにわたって、データフレームまたはデータメッセージをルートするために、複数の異なるネットワークルーティングプロトコルのネットワークルーティング情報を使用する、通信方法を実装するように使用され得る、通信システム例５が図示されている。この実施例では、本通信方法は、ＷｉｒｅｌｅｓｓＨＡＲＴ通信ネットワーク等のメッシュネットワークルーティングプロトコルまたは非ネットワークトポロジーベースのアドレス指定プロトコルのような、暗示宛先ルーティングプロトコル等の第１のネットワークルーティングプロトコルを使用するルーティングをサポートしない、１つ以上の通信ネットワークを介して、ＩＰプロトコル、とりわけ、ＩＰｖ６ネットワークプロトコルのような、明示宛先ルーティングプロトコルまたはネットワークトポロジーアドレスベースのプロトコル等の第１のネットワークルーティングプロトコルを使用して作成される、データフレームをルートする、または送信するために使用されるであろう。したがって、一般的に言えば、本明細書で提供される実施例で説明される第１のネットワークルーティングプロトコルは、（明示宛先ルーティングプロトコルである、およびネットワークトポロジーアドレス指定ベースのルーティングプロトコルである）ＩＰアドレス指定を使用するＩＰｖ４またはＩＰｖ６ネットワークルーティングプロトコル等のＩＰネットワークルーティングプロトコルとなり、このＩＰアドレス指定は、例えば、ＴＣＰ／ＩＰプロトコル、ＵＤＰ／ＩＰプロトコル、またはＩＣＭＰ／ＩＰプロトコル（全て、概して本明細書では、ＩＰネットワークルーティングプロトコルと呼ばれる）であってもよいが、それらに限定されない。また、第２のネットワークルーティングプロトコルは、暗示宛先ルーティングプロトコルまたは非ＩＰネットワークルーティングプロトコル、例えば、ＩＰアドレス、またはＩＰルーティングあるいはネットワークトポロジーベースのアドレス指定ルーティングプロトコルを使用またはサポートしない、ネットワークルーティングプロトコルとして、以下で提供される実施例で説明されるであろう。そのようなプロトコルの実施例は、ＷｉｒｅｌｅｓｓＨＡＲＴプロトコル、ＺｉｇＢｅｅプロトコル等を含む。しかしながら、ネットワークルーティングプロトコルの他のタイプおよび特定の実施例を、本明細書で説明される第１および第２のネットワークルーティングプロトコルとして使用することができ、本明細書で説明される第１および第２のネットワークルーティングプロトコルは、それぞれ、ＩＰおよび非ＩＰプロトコルに限定されないことが理解されるであろう。例えば、本明細書で説明される通信およびルーティング技法は、第１の暗示宛先ルーティングプロトコル、または非ＩＰネットワークルーティングプロトコルあるいは非ネットワークトポロジーアドレス指定ベースのプロトコルのデータパケットが、第２の暗示宛先ルーティングプロトコル、または非ＩＰネットワークルーティングプロトコルあるいは非ネットワークトポロジーアドレス指定ベースのプロトコルを使用する通信ネットワーク上で送信されることを可能にするために、使用することができる。別の実施例として、本明細書で説明される通信およびルーティング技法は、ＩＰネットワークルーティングプロトコルではない第１の明示宛先ルーティングプロトコルのデータパケットが、第２の明示宛先ルーティングプロトコル（ＩＰまたは非ＩＰベース）を使用する通信ネットワーク上で送信されることを可能にするために使用することができ、または、第１の暗示宛先、非ＩＰ、または非ネットワークトポロジーベースのアドレス指定ネットワークルーティングプロトコルのデータパケットが、例えば、Ｐネットワークルーティングプロトコルではない、第２の明示宛先ルーティングプロトコルを使用する通信ネットワーク上で送信されることを可能にするために使用することができる。当然ながら、第１および第２のタイプのネットワークの他の組み合わせも、本明細書で説明される通信およびルーティング技法を実装するために使用することができる。

【0020】

一般的に言えば、図１の通信システム５は、ＩＰネットワークルーティングプロトコルまたは非ＩＰネットワークルーティングプロトコルのいずれかを実装し得る１つ以上の他の物理ネットワークに接続する、インターネット１０の形態でＩＰ通信ネットワークを含む。この場合、インターネットネットワーク１０上の通信は、ＩＰｖ６ネットワークルーティングプロトコルを使用するが、インターネット１０上の通信はまた、または代わりに、ＩＰｖ４ネットワークルーティングプロトコルまたは他のＩＰルーティングプロトコルを使用することができると推定されるであろう。図１のインターネット１０に接続されているものとして図示される通信ネットワークは、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク１２、ＺＩＧＢＥＥネットワーク１３、Ｂｌｕｅｔｏｏｔｈ（登録商標）ピコネット１４、セルラーネットワーク１５、および無線ローカルエリアネットワーク（ＷＬＡＮ）／ローカルエリアネットワーク（ＬＡＮ）１６を含む。理解されるように、ネットワーク１２〜１６は、その中でネットワーク通信を行うように、異なるネットワークルーティングプロトコル（本明細書ではルーティングプロトコルとも呼ばれる）を実装または使用してもよく、これらの通信を行うために異なるデータリンクおよび物理層プロトコルを使用してもよい。Ｂｌｕｅｔｏｏｔｈ（登録商標）ネットワーク、ＷＬＡＮ／ＬＡＮネットワーク、およびセルラーネットワーク等を用いた、多くの場合において、通信ネットワークが、ＩＰネットワークルーティングまたはネットワークトポロジーアドレス指定ルーティングあるいは別の明示宛先ルーティングプロトコルをサポートしてもよい一方で、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク等を用いた他の場合においては、通信ネットワークが、ネットワークルーティング活動にＩＰアドレス指定を使用しなくてもよいため、このネットワークは、ＩＰネットワークルーティングプロトコルまたはネットワークトポロジーアドレス指定ルーティングあるいは他の明示宛先ルーティングプロトコルを使用またはサポートしなくてもよい。例えば、上述のように、ＷｉｒｅｌｅｓｓＨＡＲＴネットワークは、典型的には、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク内でメッセージのルーティングを行うために、グラフルーティングと呼ばれる概念を使用する。

【0021】

以下で説明される通信方法は、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク１２内のデバイスが、ＩＰｖ６またはＩＰｖ４データフレームを作成すること、および非ＩＰネットワークルーティングプロトコルではないＷｉｒｅｌｅｓｓＨＡＲＴネットワーク１２のネットワークルーティングプロトコルが、ルーティング目的でＩＰアドレス指定を使用またはサポートしないため、このネットワークルーティングプロトコルを使用して、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク１２上でこれらのデータフレームを伝達することを可能にするために、使用されてもよい。また、理解されるように、ＷｉｒｅｌｅｓＨＡＲＴネットワークが、メッシュネットワークルーティングプロトコルを実装する一方で、インターネット１０および１つ以上の他の通信ネットワーク１３〜１６は、２点間ルーティングプロトコル等の非メッシュネットワークルーティングプロトコルを使用してもよい。いずれにしても、この通信方法を使用して、これらのＩＰｖ６データフレームは、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク１２内の他のデバイスに、または図１で図示される他の通信ネットワーク１３〜１６のうちの１つ以上の中のデバイスに送信され、それらによって復号されてもよい。同様に、以下で説明される通信方法は、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク１２内のデバイスが、ＩＰｖ６データフレームとしてＩＰｖ６データフレームを受信して復号し、したがって、デバイスがＩＰネットワークルーティング準拠通信ネットワーク（すなわち、ＩＰネットワークルーティング機構を使用する通信ネットワーク）に接続された場合と本質的に同様に、これらのデータフレームを使用し、それらに応答することを可能にするために使用されてもよい。この場合、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク１２内の受信デバイスは、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク１２内の別のデバイスから、または図１の他のネットワーク１３〜１６のうちのいずれか１つの中のデバイスから、ＩＰｖ６データフレームを受信してもよい。

【0022】

一般的に言えば、本明細書で説明される通信方法を実装するために、ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴゲートウェイ１１ａは、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク１２をインターネット１０に接続する。同様に、図１で図示されるように、他のゲートウェイデバイス１１ｂ、１１ｃ、１１ｄ、および１１ｅは、ＺｉｇＢｅｅネットワーク１３、Ｂｌｕｅｔｏｏｔｈ（登録商標）ピコネット１４、セルラーネットワーク１５、およびＷＬＡＮ／ＬＡＮ１６のそれぞれを、インターネット１０に接続する。ゲートウェイデバイス１１ならびに通信ネットワーク１２〜１６内の１つ以上のデバイスは、以下でさらに詳細に説明される通信方法のステップまたは態様を実装するように動作して、例えば、ＩＰベースの通信が、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク１２内の２つのデバイス（またはアプリケーション）間で、またはＷｉｒｅｌｅｓｓＨＡＲＴネットワーク１２内の第１のデバイス（またはアプリケーション）とネットワーク１３〜１６のうちの別のネットワーク内の第２のデバイス（またはアプリケーション）との間で起こることを可能にしてもよい。

【0023】

より具体的には、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク１２内のデバイス（ゲートウェイデバイス１１ａを含む）は、ＩＰネットワークルーティングプロトコル通信を使用またはサポートしないネットワークルーティングプロトコルおよび／またはデータリンク層プロトコルを使用する、通信ネットワークの中または外へＩＰデータフレームをシームレスに送信することができるよう、非ＩＰネットワークルーティング情報およびＩＰネットワークルーティング情報の両方を含むように構成されるデータフレームを使用して、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク１２の物理層を介してデータフレームを受信および伝送するように動作してもよい。実施例として、図１のＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴゲートウェイ１１ａは、インターネット１０を介して、ＩＰｖ６ネットワークルーティングプロトコルに従って情報とともにカプセル化されたデータフレームを受信してもよく、そのようなデータフレームは、インターネット１０内の８０２．３プロトコルデータリンク層および／または任意の標準あるいはサポートされた物理層を使用して、インターネット１０上で通信チャネルを通して伝送される。ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴゲートウェイ１１ａによってインターネット１０から受信されるデータフレームは、本来、例えば、標準ＩＰｖ６データフレームとして、ＺＩＧＢＥＥネットワーク１３、Ｂｌｕｅｔｏｏｔｈ（登録商標）ピコネット１４、セルラーネットワーク１５、またはＷＬＡＮ／ＬＡＮ１６のうちのいずれか１つの中で動作するデバイス内のアプリケーションによって伝送または作成されていてもよい。次いで、ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴゲートウェイ１１ａは、ＷｉｒｅｌｅｓｓＨＡＲＴ準拠ネットワークルーティングプロトコルを使用して、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク１２内で動作するデバイス内のネットワーク位置（例えば、アプリケーション）へ、受信したＩＰｖ６データフレームを伝送し、それにより、ネットワーク１３〜１６のうちの１つの中に位置するデバイスとＷｉｒｅｌｅｓｓＨＡＲＴネットワーク１２内に位置するデバイスとの間で、ＩＰｖ６メッセージまたはデータフレームを送達するように動作してもよい。同様に、ＷｉｒｅｌｅｓｓＨＡＲＴゲートウェイ１１ａは、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク１２内のＩＰ使用可能デバイスによって作成され、したがって、ＩＰｖ６ネットワークルーティングプロトコルに従って最初にカプセル化され、次いで、修正され、本明細書でさらに詳細に説明される方式で構成されるＷｉｒｅｌｅｓｓＨＡＲＴネットワークルーティングプロトコルを使用して、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク１２を介してルートされる、データフレームまたはメッセージを受信してもよい。ＷｉｒｅｌｅｓｓＨＡＲＴゲートウェイ１１ａは、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク１２によって使用される８０２．１５．４データリンク層および物理プロトコルを介して、これらのデータフレームまたはメッセージを受信してもよい。次いで、ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴゲートウェイ１１ａは、ＩＰネットワークルーティングまたはアドレス指定を使用して、データフレームを他のネットワーク１３〜１６のうちの１つの中のデバイスに送信するために、受信したメッセージまたはデータフレーム内のＩＰネットワークルーティング情報を使用してもよい。当然ながら、この場合、ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴゲートウェイ１１ａは、標準８０２．３物理層通信プロトコルおよびＩＰｖ６ネットワークプロトコル技法を使用して、インターネット１０を介して、受信したＩＰｖ６データフレームをアプリケーションまたはデバイスに伝送するように動作する。

【0024】

理解されるように、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク１２内のデバイスは、８０２．１５．４標準に準拠する通信チャネルを介して、データフレームを受信および伝送してもよい。しかしながら、以下でさらに詳細に説明されるように、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク１２上のＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴゲートウェイ１１ａまたは他のＩＰ使用可能デバイスは、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク１２上でＩＰｖ６データフレームを送信するとき、例えば、６ＬｏＷＰＡＮ標準に従って、ＩＰｖ６データフレームをいくつかの断片に断片化してもよい。この場合、デバイスは、ＷｉｒｅｌｅｓｓＨＡＲＴネットワークルーティングプロトコルおよび８０２．１５．４データリンク層プロトコルに準拠する通信チャネルを介して、ＩＰｖ６データフレーム断片をＷｉｒｅｌｅｓｓＨＡＲＴデバイスに伝送してもよい。この場合、ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴゲートウェイ１１ａは、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク１２上でＩＰｖ６データフレーム断片を送信するように、ＷｉｒｅｌｅｓｓＨＡＲＴネットワークルーティングプロトコルに対応するヘッダ情報とともに、これらのＩＰｖ６データフレーム断片をカプセル化してもよい。その後、ＷｉｒｅｌｅｓｓＨＡＲＴプロトコルヘッダに含まれる情報は、ＩＰｖ６データフレーム断片を意図したＷｉｒｅｌｅｓｓＨＡＲＴデバイスまたはアプリケーションにルートするために、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク１２内の１つ以上のＷｉｒｅｌｅｓｓＨＡＲＴデバイスによって利用されてもよい。有意なこととして、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク１２内で動作するＷｉｒｅｌｅｓｓＨＡＲＴデバイスは、非ＩＰアプリケーションデータまたはペイロードを伝達または交換し続けてもよい。これは、ネットワーク内非ＩＰ通信、ならびにネットワーク内および間両方のＩＰ通信を同時に可能にしながら、後方互換性を推進する。

【0025】

ネットワーク上でルートされている特定のＷｉｒｅｌｅｓｓＨＡＲＴメッセージまたはデータフレームが、標準ＷｉｒｅｌｅｓｓＨＡＲＴメッセージであるか、またはカプセル化ＩＰｖ６データメッセージであるかを、ネットワーク１２上のＷｉｒｅｌｅｓｓＨＡＲＴデバイスが認識することを可能にするために、メッセージを生成するＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴゲートウェイ１１ａまたは他のデバイスは、そのデータフレームがＩＰｖ６データフレームまたは標準ＷｉｒｅｌｅｓｓＨＡＲＴデータフレームであることを示すフラグを、データフレームのＷｉｒｅｌｅｓｓＨＡＲＴネットワークルーティング情報の中に含んでもよい。フラグは、ＷｉｒｅｌｅｓｓＨＡＲＴネットワークルーティング情報の中に１つ以上のデータフィールドを備えてもよい。好ましくは、非ＩＰ使用可能およびＩＰ使用可能ＷｉｒｅｌｅｓｓＨＡＲＴデバイス間の後方互換性および相互運用性を推進するために、フラグは、ＷｉｒｅｌｅｓｓＨＡＲＴネットワークルーティング情報の中の以前に使用されていないデータフィールドを利用してもよい。

【0026】

理解されるように、ＩＰｖ６データフレームが断片化され、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク１２上で送信されるとき、図１のＷｉｒｅｌｅｓｓＨＡＲＴネットワーク１２内のＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴゲートウェイ１１ａまたは他のデバイスは、８０２．１５．４通信プロトコルに従って動作する通信チャネルを介して、ＷｉｒｅｌｅｓｓＨＡＲＴネットワークルーティングプロトコル情報とともにカプセル化されたＩＰｖ６データフレーム断片を受信するであろう。ＩＰｖ６データフレーム断片は、上記で示されるように、６ＬｏＷＰＡＮ標準に準拠してもよい。次いで、ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴゲートウェイ１１ａまたは他のＷｉｒｅｌｅｓｓＨＡＲＴデバイスは、データフレームがＩＰｖ６データフレームに対応することを示すフラグを、データフレーム断片のＷｉｒｅｌｅｓｓＨＡＲＴネットワークルーティング情報の中で検出してもよい。この場合、次いで、ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴゲートウェイ１１ａまたは他のＷｉｒｅｌｅｓｓＨＡＲＴデバイスは、ＩＰｖ６データフレームを生成するように６ＬｏＷＰＡＮデータフレームを組み立て直す。次いで、ＷｉｒｅｌｅｓｓＨＡＲＴゲートウェイ１１ａは、標準ＩＰｖ６通信を使用して、ＩＰｖ６データフレームを、ＺＩＧＢＥＥネットワーク１３、Ｂｌｕｅｔｏｏｔｈ（登録商標）ピコネット１４、セルラーネットワーク１５、および／またはＷＬＡＮ／ＬＡＮ１６内のデバイスに送信するために、ＩＰｖ６データフレームおよび標準ＩＰルーティングソフトウェアおよびハードウェアのＩＰ宛先アドレス情報を使用してもよい。当然ながら、組み立て直されたデータフレームのＩＰアドレスが、受信デバイス内のアプリケーションを示す場合、データフレームは、ＩＰｖ６データフレームとしてアプリケーションに送達され、標準ＩＰｖ６準拠技法に従って処理される。

【0027】

ＩＰｖ６使用可能通信は、概して、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク１２である非ＩＰネットワークに関して起こるものとして図１で説明されているが、これらの場合において、ネットワーク１３〜１６上のデバイスが、ＷｉｒｅｌｅｓｓＨＡＲＴ物理層、データリンク層、およびネットワークルーティング層プロトコルの代わりに、これらの他のネットワークによってサポートまたは特定される、物理層、データリンク層、およびネットワークルーティング層プロトコルを使用するであろうことを除いて、本明細書で説明される同一の技法を使用して、ＺＩＧＢＥＥネットワーク１３、Ｂｌｕｅｔｏｏｔｈ（登録商標）ピコネット１４、セルラーネットワーク１５、および／またはＷＬＡＮ／ＬＡＮ１６（これらのネットワークが、例えば、非ＩＰネットワークルーティングプロトコルを使用するとき）内等の、他の非ＩＰネットワーク内でＩＰｖ６ベースの通信を行うために、同一の技法を使用できることが理解されるであろう。

【0028】

非ＩＰネットワーク、すなわち、ネットワークルーティングを行うためにＩＰネットワークルーティングプロトコルを使用しないネットワークを介して、ＩＰデータフレームを符号化してルートすることができる、特定の方式をさらに十分に説明するために、データフレーム全般、具体的にはＩＰデータフレームが作成され、通信ネットワークを介してルートされる、一般的な方式を説明することが役立つであろう。まず第１に、データフレームが作成されてルートされる、いくつかの異なる層またはレベルがあると留意することが重要であり、これらの異なるレベルが相互に関連し、ネットワーク通信を行うために現在使用されている種々の異なるネットワークおよび通信プロトコルで使用される方式を理解することが必要である。一般的に言えば、通信ネットワーク上で送信されるデータフレームは、典型的には開放型システム間相互接続（ＯＳＩ）モデルを使用して定義される、いくつかの通信スタック層と関連付けられる、またはそれらによって提供される情報を含む。

【0029】

一般的に言えば、ＯＳＩモデルは、７つの基本層を使用してネットワークプロトコルを実装するためのネットワーキングフレームワークを定義する。メッセージを作成し、通信チャネル上で次のステーションに送信するように、１つのステーションの中の上層から始まって、そのステーションの中の底層へ進んで、１つの層から次の層へ制御が渡される。受信ステーションにおいて、制御が底層に提供され、受信したメッセージの復号を行うように、上層まで階級を再び横断する。一般的に言えば、ＯＳＩモデルの７つの層は、アプリケーション層（層７と呼ばれる上層）、プレゼンテーション層（層６）、セッション層（層５）、トランスポート層（層４）、ネットワーク層（層３）、データリンク層（層２）、および物理層（層１）を含む。概して、アプリケーション層は、アプリケーションおよびエンドユーザプロセスをサポートする。アプリケーション層における全ては、アプリケーション特有であり、アプリケーション層（またはアプリケーション層におけるアプリケーション）は、通信相手、サービスの質、ユーザ認証、プライバシー、データ構文への制約等を定義してもよい。この層はまた、ファイル転送、Ｅメール、および他のネットワークサービスのためのアプリケーションサービスも提供する。構文層と呼ばれることもある、プレゼンテーション層は、アプリケーション形式からネットワーク形式へ、およびその逆も同様に変換することによって、データ表現（例えば、暗号化）の差異からの独立を提供する。したがって、プレゼンテーション層は、データを、例えば、このデータが符号化または暗号化されている場合にアプリケーション層が受け入れることができる形式に変換するように稼働する。したがって、この層は、ネットワークにわたって送信されるデータをフォーマットして暗号化し、互換性の問題を低減または排除する。

【0030】

セッション層は、アプリケーション間の接続を確立し、管理し、および終了させ、概して、通信の両端でアプリケーション間の会話、交換、および対話を設定し、協調させ、終了させる。セッション層はまた、セッションおよび接続協調を扱う。トランスポート層は、終端システムまたはホスト間のトランスペアレントなデータの転送を提供し、終端間エラー回復およびフロー制御に関与する。したがって、この層は、完全なデータ転送を確保する。ネットワーク層は、種々のデータリンク上の一連の交換が、どのようしてネットワーク内の任意の２つのノード間でデータを送達することができるかを説明する。ネットワーク層は、ネットワークのアドレス指定、切替、およびルーティング構造を定義し、ノードからノードへデータを伝送するための仮想回路として知られている、論理経路を作成または定義する。重要なこととして、ネットワーク層は、ネットワークルーティングおよび転送機能、ならびにネットワークアドレス指定方式、インターネット機能、エラー処理、ふくそう制御、およびパケット順序制御を定義する。

【0031】

データリンク層は、データパケットをビットに符号化し、およびビットから復号し、特定の媒体上で伝送されるデータビットの論理的組織を説明する。この層は、物理層におけるパケットのフレーミング、アドレス指定、およびチェックサム（エラー処理）を定義する。データリンク層は、概して、媒体アクセス制御（ＭＡＣ）層および論理リンク制御（ＬＬＣ）層を含む、２つの副層に分割される。ＭＡＣ副層は、ネットワーク上のコンピュータが、どのようにしてデータへのアクセスおよびこのデータを伝送する許可を獲得するかを制御する。ＬＬＣ層は、フレーム同期化、フロー制御、およびエラーチェックを制御する。物理層は、電気および機械レベルでネットワークを通して、例えば、電気インパルス、光、または無線信号を介して、ビットストリームを伝える。物理層は、ケーブル、カード、およびネットワークハードウェアの物理的態様の定義を含む、キャリア上でデータを送信および受信するハードウェア手段を提供する。

【0032】

重要なこととして、いくつかのプロトコルが、最も顕著には、トランスポート層（層４）、ネットワーク層（層３）、データリンク層（層２）、および物理層（層１）を含む、これらの層のうちのいくつかのために定義されている。例えば、ユニバーサルデータグラムプロトコル（ＵＤＰ）、伝送制御プロトコル（ＴＣＰ）、およびインターネット制御メッセージプロトコル（ＩＣＭＰ）を含む、種々のトランスポート層プロトコルが存在する。これらのプロトコルは、例えば、ＩＰネットワーク層プロトコルとともに使用される、特定のトランスポート層規則およびプロシージャを提供する。加えて、最も広範には、ＩＰｖ４およびＩＰｖ６ネットワーク層プロトコル等のＩＰプロトコル、およびＷｉｒｅｌｅｓｓＨＡＲＴネットワーク層プロトコルを含む多くの非ＩＰネットワーク層プロトコルを含む、種々のネットワーク層プロトコルが存在する。ネットワーク層プロトコルは、概して、ネットワーク内の１つの論理点からネットワーク内の別の論理点へメッセージまたはデータフレームをルートするために使用される規則およびプロシージャを定義し、なおもさらに、ネットワークルーティングが起こることを可能にするためにデータパケットの中へ配置される必要があるネットワーク層情報を定義する。ネットワーク層プロトコルはまた、本明細書ではネットワークルーティングプロトコルとも呼ばれる。なおもさらに、例えば、８０２．３データリンク層プロトコル（Ｅｔｈｅｒｎｅｔ（登録商標））、８０２．１５．４物理層プロトコル（例えば、ＷｉｒｅｌｅｓｓＨＡＲＴ物理層プロトコルによって使用される）等を含む、種々の物理層またはデータリンク層プロトコルが定義されている。種々の異なるネットワークが、異なるデータリンク層プロトコルを使用しながら、同一のネットワーク層プロトコルを使用してもよく、または逆も同様であることが理解されるであろう。また、あるデータリンク層プロトコルは、あるネットワーク層プロトコルと互換性がなくてもよい。この問題の一般的な理由は、ネットワーク層プロトコルが、データリンク層プロトコルによって許容されるメッセージサイズよりも長い最大メッセージサイズまたは長を定義し得ることである。

【0033】

本明細書で説明される通信技法は、上記で説明されるいくつかの層を利用してもよいが、いくつかの実装では、本通信方法は、「層状」アプローチを避け、命令の単一モノリシックブロックとして以下で説明される機能性を実装してもよい。このアプローチは、メモリが制約されたデバイスにおいて本通信方法を実装するときに特に魅力的である。しかしながら、命令の単一モノリシックブロックは、依然として、本明細書で説明される層状アプローチで使用される要素またはスタック要素を含む。

【0034】

典型的には、コンピュータデバイスに常駐するコンピュータデバイスおよび／またはアプリケーションは、デバイスが接続される通信ネットワークの物理層上で送信されるメッセージを作成（符号化）するようにＯＳＩモデルの種々の層を実装するか、または下方に横断するため、あるいは通信ネットワークの物理層上で受信されるメッセージを復号するようにＯＳＩモデルの種々の層を上方に横断するために、ネットワークまたは通信スタックを利用してもよい。したがって、デバイスの通信スタックは、データフレームを伝送する前に特定のプロトコルに従ってデータフレームをパッケージ化またはカプセル化するように、あるいはデバイスにおいて受信されるデータフレームを非パッケージ化または復号して、復号されたメッセージを、メッセージが方向付けられるアプリケーションに提供するように、スタックの種々の層における種々のプロトコルによって定義されるプロシージャを実装する、プロセッサにおいて実行されるアプリケーションを備えてもよい。プロトコルに従ってデータフレームをパッケージ化することは、データフレームに現在作用している層のプロトコルによって定義されるようなヘッダおよび／またはトレーラ情報を付加し、次いで、そのデータフレームをスタックの次の下層に渡すことを含んでもよい。同様に、データフレームを非パッケージ化することは、スタックの特定の層のデータフレームからヘッダおよび／またはトレーラ情報を除去および復号し、非パッケージ化されたデータフレームをスタックの中の次の上位層に渡すことを含む。スタックの中の特定の層のデータフレームのヘッダおよび／またはトレーラセクションの中の情報は、典型的には、適切な層における特定のプロトコル標準によって定義される規則に準拠する。例えば、ＴＣＰ／ＩＰプロトコルに従ってデータフレームをパッケージ化することは、（スタックのトランスポート層において）ＴＣＰヘッダをデータフレームに付加し、後に、（スタックのネットワーク層において）ＩＰヘッダを結果として生じるデータフレームに付加することを含む。ＴＣＰヘッダは、ＴＣＰプロトコルに準拠し、ＩＰヘッダは、例えば、ＩＰｖ４またはＩＰｖ６標準に準拠する。ＩＰｖ６プロトコルのうちの特定のものが、ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ２４６０．ｔｘｔで入手可能な仕様で説明されている。他のネットワーク層プロトコルの実施例は、ＷｉｒｅｌｅｓｓＨＡＲＴプロトコル、ＺｉｇＢｅｅネットワーク層プロトコル等を含む。当然ながら、特定のネットワークプロトコルに従ってパッケージ化されるデータフレームは、８０２．３標準（Ｅｔｈｅｒｎｅｔ（登録商標））、８０２．１１ａ／ｂ／ｇ／ｎ標準（Ｗｉ−Ｆｉ）、８０２．１５．４標準、８０２．１６標準（Ｗｉｍａｘ）、ＣＤＭＡ、ＧＳＭ、ＬＴＥ等のセルラー標準等の一組のデータリンク層プロトコルまたは物理層プロトコルのうちのいずれか１つに準拠する通信チャネルを介して、伝送されてもよい。

【0035】

図２Ａは、データフレームまたはデータメッセージがデバイスの通信スタックの種々のＯＳＩ層を通して下方に処理される際に、データフレームまたはデータメッセージを作成する方式を図示する、チャートを描写する。具体的には、（アプリケーション層における）アプリケーションが、アプリケーションによって任意の所望の方式で定義される一組のビットおよびバイトとして、元のデータメッセージ２０を作成し、このメッセージをトランスポート層に提供する。概して、メッセージを層に「提供すること」は、層のアプリケーションプログラミングインターフェース（ＡＰＩ）または「ラッパ」を呼び出すことによって達成されてもよい。当業者はまた、層の「ラッパ機能を呼び出すこと」によってメッセージを提供してもよい。（ここで、セッションおよびプレゼンテーション層の詳細は、詳細に論議されず、スタックのトランスポート層で遂行されると仮定されるであろう。）スタックのトランスポート層は、（図２で図示されるように）アプリケーションからのデータメッセージをペイロードとして扱い、使用されているトランスポート層プロトコルによって定義されるように、ヘッダ（およびおそらくトレーラ）情報をそこに付加する。本明細書ではトランスポート層情報２２と呼ばれる、ヘッダ（およびおそらくトレーラ）情報は、セッション情報の定義（例えば、セッションＩＤ）、使用されているトランスポートプロトコルのタイプの定義または指示等を含んでもよい。結果として生じるメッセージ２３は、図２で図示されるように、トランスポート層からのメッセージ２３をペイロードとして扱う、スタックのネットワーク層に提供される。ネットワーク層において、ネットワークルーティング情報またはネットワークルーティングプロトコル情報２４は、付加的なヘッダおよびトレーラ情報（ヘッダセクションとして図２で図示される）の形態でペイロード２３に付加される。ネットワークルーティング情報２４は、例えば、ネットワークソースおよび宛先の識別（ＩＰネットワークルーティングプロトコルのソースＩＰアドレスおよび宛先ＩＰアドレス、またはＷｉｒｅｌｅｓｓＨＡＲＴネットワークルーティングプロトコルのグラフＩＤ等）、タイムアウト情報（有効期限情報）、チェックサム情報、メッセージまたはペイロード長情報、種々の目的で使用されるフラグ等を含んでもよい。

【0036】

その後、ネットワーク層によって作成されるようなメッセージは、データリンク層に提供され、そこで、ネットワーク層によって作成されたメッセージは、ペイロード２５として扱われ、付加的なデータリンク情報２６が、通信ネットワークで使用されているデータリンクプロトコルによって定義されるように、ヘッダおよび／またはトレーラセクションの形態で追加される。具体的には、データリンク層は、典型的には、デバイスソースおよび宛先識別（ソースおよび宛先ＭＡＣアドレス等）の形態のデータリンク情報、停止および開始ビット等の媒体制御情報、フロー制御ビット、長さ情報、チェックサム情報、および順序情報を含む断片化情報等を追加する。場合によっては、スタックの物理層と関連付けられるアプリケーションは、物理層プロトコル情報をデータフレームに追加する。

【0037】

データリンク層によって作成されるようなメッセージは、物理層上へ出力され、物理層上で、データリンクヘッダ情報２６の中の宛先アドレスによって定義されるようなデバイスへ送信される。理解されるように、デバイス内で復号されているとき、メッセージは、受信デバイスのスタックの上方に進み、スタックの各層は、メッセージを復号し、メッセージの適切な処理を行うために層によって使用される適切なヘッダおよびトレーラ情報を取り除く。したがって、受信デバイスにおいて、スタックのデータリンク層は、メッセージが正しく受信されており、（例えば、データリンク情報２６内のＭＡＣアドレスによって定義されるような）このデバイスにアドレス指定されているかどうかを判定するように、データリンクヘッダおよびトレーラ情報２６を取り除いて復号するであろう。もしそうであれば、データリンク層におけるメッセージのペイロード部分２５は、送信および受信ネットワークアドレスまたは他のルーティング情報を判定するように、ネットワーク層ヘッダおよびトレーラ情報２４を取り除く、ネットワーク層に提供される。スタックのネットワーク層は、このメッセージを受信するものであるネットワーク内の論理点、およびこのメッセージをネットワーク内の正しい点にルートする適切な方式を判定するために、このネットワークルーティング情報を使用してもよい。ネットワーク内のネットワークアドレスまたは論理点が、受信デバイスまたは受信デバイス内のアプリケーションと関連付けられると仮定すると、次いで、残りのペイロード２３が、残りのメッセージ２０をアプリケーション層内の適切なアプリケーションに与える前に、メッセージを処理するためにスタックのトランスポート層によって使用される、メッセージ、データタイプ等で使用するトランスポート層プロトコルを判定するように、トランスポート層情報２２を取り除いて復号する、トランスポート層に提供される。

【0038】

理解されるように、ネットワークルーティング情報（またはネットワークプロトコル情報）は、概して、データフレームの意図した受信側であるコンピュータデバイスまたはアプリケーションの論理アドレスに対応する、情報を含む。データフレームのネットワークルーティング情報はまた、データフレームを伝送したコンピュータデバイスの論理アドレスに対応する、情報を含んでもよい。例えば、データフレームをカプセル化するＩＰネットワークプロトコルのＩＰヘッダは、ソースＩＰアドレスおよび宛先ＩＰアドレスを含む。ソースＩＰアドレスは、データフレームを伝送するコンピュータデバイスまたはアプリケーションの論理アドレスに対応し、宛先ＩＰアドレスは、データフレームの意図した受信側であるコンピュータデバイスまたはアプリケーションの論理アドレスに対応する。（コンピュータデバイスは、１つよりも多くの論理ＩＰアドレスを有してもよい。）ルータ等の中間デバイスは、例えば、データフレームを、データフレームの意図した受信側であるコンピュータデバイスに「ルートする」か、または転送するために、ＩＰアドレスを利用する。

【0039】

しかしながら、本明細書で説明される通信方法は、第１のネットワークルーティングプロトコルまたは技法（明示宛先またはアドレス指定ルーティング技法、非メッシュネットワークルーティング技法、あるいはネットワークトポロジーアドレス指定ベースのルーティング技法等）に準拠し、かつそれらを使用して復号可能であるが、第２の異なるネットワークルーティングプロトコルまたは技法（暗示宛先またはアドレス指定ルーティング技法、メッシュネットワークルーティング技法、あるいは非ネットワークトポロジーアドレス指定ベースの技法等）を使用する通信ネットワークを介して送信される、データメッセージを作成する能力を提供するように、上記で説明されるデータフレーム作成および復号プロセスを変更する。一般的に言えば、新しい通信方法は、メッセージが通信ネットワーク上で送信される際にメッセージに符号化される、複数の異なるネットワークルーティングプロトコルと関連付けられるネットワークルーティング情報またはネットワークプロトコル情報を有する、メッセージを作成する。この特徴は、メッセージが、第１のネットワークルーティングプロトコルを使用して送信されるメッセージとして作成されることを可能にするが、次いで、メッセージが、実際には、第２のネットワークルーティングプロトコルを使用するか、またはそれに準拠する通信ネットワーク上で送信されることを可能にする。加えて、メッセージは、アプリケーション層までメッセージを復号する必要なく、異なるネットワークルーティングプロトコルを使用する２つの通信ネットワーク間の接合点に配置されるゲートウェイデバイスにおいて容易に変換されてもよい。代わりに、ゲートウェイデバイスは、第２のネットワークから第１のネットワークへメッセージを送達するときに、第２のネットワークルーティングプロトコル情報を取り除くか、または第２のネットワーク内のデバイスによって受信されるようにメッセージを第２のネットワークの中へ送信するときに、第２のネットワークルーティングプロトコル情報を追加する必要しかない。

【0040】

図２Ｂおよび３は、例えば、ＷｉｒｅｌｅｓｓＨＡＲＴ通信ネットワーク上でルートされ、ＩＰデータフレームとして、ＷｉｒｅｌｅｓｓＨＡＲＴ通信ネットワーク上でＩＰ使用可能ＷｉｒｅｌｅｓｓＨＡＲＴゲートウェイ等の別のＩＰ使用可能ＷｉｒｅｌｅｓｓＨＡＲＴデバイスによって復号されることが可能である、ＩＰデータフレームをＩＰ使用可能ＷｉｒｅｌｅｓｓＨＡＲＴデバイスの中で作成する方法を説明するために使用されるであろう。具体的には、図２Ｂが、データフレームが本明細書で説明される通信技法に従って作成される際のこのデータフレームを図示する一方で、図３は、図２Ｂのデータフレームを生成するために使用される通信技法のステップを図示するフローチャート４０を描写する。

【0041】

具体的には、図３のフローチャート４０のブロック４１では、メッセージ３０が、ＩＰｖ４またはＩＰｖ６プロトコルによって提供されるもの等の標準ＩＰルーティングを使用して符号化および送信されるであろうと仮定して、ＷｉｒｅｌｅｓｓＨＡＲＴデバイスのアプリケーション層におけるアプリケーションが、データメッセージ３０（図２Ｂ）を生成する。所望であれば、ＷｉｒｅｌｅｓｓＨＡＲＴデバイスのアプリケーション層内のこのアプリケーションまたは別のアプリケーションは、最初に、ＤＮＳ（ドメイン名システム）サービスを実施または実装するように、およびデバイス、ウェブサイト、サーバ、ルータ、Ｅメール受信側等の特定のネットワークエンティティのＩＰアドレス（例えば、ＩＰｖ６またはＩＰｖ４アドレス）をＷｉｒｅｌｅｓｓＨＡＲＴデバイスに提供するようにゲートウェイデバイスに要求するメッセージを、（ＷｉｒｅｌｅｓｓＨＡＲＴネットワークルーティングプロトコルを使用するＷｉｒｅｌｅｓｓＨＡＲＴネットワーク上で）ゲートウェイデバイスに送信してもよい。この場合、ＷｉｒｅｌｅｓｓＨＡＲＴデバイスは、最初に、ウェブサイトホスト名またはＥメールサーバホスト名、あるいはＤＮＳサービスによって使用される任意の他の名前等のネットワークエンティティ（例えば、第２またはＩＰネットワーク内のエンティティ）のドメイン名を提供してもよい。ＤＮＳサービス（ＩＰネットワーク上のゲートウェイまたは別のデバイスにおいて実装され得る）を介してネットワークエンティティのＩＰアドレスを取得した後、次いで、ゲートウェイデバイスは、ＷｉｒｅｌｅｓｓＨＡＲＴネットワークルーティングプロトコルを使用して、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク上で、ネットワークエンティティのＩＰアドレスをＷｉｒｅｌｅｓｓＨＡＲＴデバイス内のアプリケーションに返信し、次いで、アプリケーションは、ＩＰｖ６またはＩＰｖ４データパケットを使用して通信するために、このＩＰアドレスを使用してもよい。アプリケーションは、他のＩＰ使用可能デバイスを用いて通信を行うためにＩＰベースのソケットアドレス指定を使用する、ソケットベースのアプリケーションであってもよい。

【0042】

いずれにしても、ブロック４２では、アプリケーションメッセージが、ＩＰ使用可能ＷｉｒｅｌｅｓｓＨＡＲＴデバイスのスタックのトランスポート層の中で処理され、ＴＣＰヘッダおよびトレーラ情報等の典型的なＩＰベースのトランスポート層情報をデータメッセージ３０（スタックのトランスポート層で作成されているデータフレームのペイロードセクションとして扱われる）に追加する。

【0043】

次に、ＩＰ使用可能デバイスのスタックのネットワーク層で実施され得るブロック４３が、ＩＰソースおよび宛先アドレス情報等のＩＰ準拠ネットワークルーティング情報、データパケット長情報等をデータフレームに追加する。このＩＰネットワークルーティング情報は、ヘッダ情報３４ａとして図２Ｂで図示され、第１のネットワークルーティングプロトコル（この場合はＩＰネットワークルーティングプロトコル）と関連付けられるか、またはそれによって定義されるものとして例証される。上述のように、ＩＰ宛先アドレスは、ＩＰ宛先アドレスを判定するようにＤＮＳサービスを行うか、または呼び出すゲートウェイデバイスとの通信を介して、取得されてもよい。次に、所望であれば、図３のブロック４４が、ＩＰネットワークルーティングによってサポートされるサイズまたは長さのデータフレームをサポートしない、ネットワークルーティングプロトコル、データリンク層プロトコル、または物理層プロトコルを使用して、ブロック４３によって生じさせられたＩＰデータフレームが通信ネットワーク上で送信されることを可能にするように、ブロック４３によって生じさせられたデータフレームを断片化してもよい。そのような断片化は、概して、その中で送信されるデータパケットのサイズまたは長さを、従来のＩＰネットワークルーティングによってサポートされるサイズよりも小さいサイズに限定する、低出力ＩＰネットワークで一般的である。より低い出力のＩＰネットワークで使用される、１つの一般的な断片化技法は、あるサイズを超える各ＩＰｖ６データパケットを、ネットワークのデータリンクおよび物理層プロトコルによってサポートされる長さまたはサイズを有する複数のパケットまたは断片化データフレームに断片化する、６ＬｏＷＰＡＮプロトコルである。６ＬｏＷＰＡＮ断片化技法は、本明細書では断片化およびデフラグ目的で使用されるものとして説明されるが、他のタイプの断片化技法も使用することができる。加えて、場合によっては、例えば、第２のネットワークルーティングプロトコルまたは物理ネットワークが、第１のネットワークプロトコルの長さまたはサイズのデータフレームをサポートする場合において、いかなる断片化も必要とされなくてもよい。これらの場合において、ブロック４４を省略することができる。

【0044】

いずれにしても、断片化が行われると仮定すると、ブロック４６（第２のネットワークルーティングプロトコルを使用するネットワークルーティングを行うことと関連付けられる、スタックのネットワーク層で実施され得る）が、ブロック４４からのデータパケットをペイロードとして扱い、第２のネットワークルーティングプロトコルによって定義されるようなネットワークルーティング情報を各データフレームまたは断片化データフレームに追加する。この点におけるデータパケットは、ブロック４３（またはブロック４４）によって作成されたパケット３５に追加されるヘッダ情報として、第２のネットワークルーティング情報３４ｂを含むものとして図２Ｂで図示される。この第２のネットワークルーティング情報３４ｂは、例えば、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク内のグラフルーティングのグラフＩＤ、ならびに、例えば、ＷｉｒｅｌｅｓｓＨＡＲＴプロトコルのＷｉｒｅｌｅｓｓＨＡＲＴネットワークルーティング層によって定義されるような、データパケットの他のネットワークルーティング情報を含んでもよい。当然ながら、他のメッシュネットワーキング、暗示宛先またはアドレス指定、非ネットワークトポロジーアドレス指定ベース、あるいは非ＩＰネットワークルーティングプロトコル等の他のネットワークルーティングプロトコルを、第２のネットワークルーティングプロトコルとして使用することができる。加えて、このレベルでデータパケットに追加されるネットワークルーティング情報の一部として、ブロック４６は、基礎的データパケットまたはデータフレーム３５が、実際には、第２のネットワークルーティングプロトコルではなく第１のネットワークルーティングプロトコルと関連付けられるデータフレームであることを示すように、ネットワークルーティング情報３４ｂの別様に未使用の部分またはビットの中にフラグ（ビット３９として図２Ｂで図示される１ビットフラグ等）を追加または設定する。より具体的には、典型的には、特定のネットワークルーティングプロトコルによって各データパケットに追加されるネットワークルーティング情報の中に未使用のビットまたはバイトがある。ネットワークルーティングプロトコルを復号するデバイスは、典型的には、復号プロセス中にこれらのビットを無視する。しかしながら、この場合、これらの別様に未使用のビットまたはバイトのうちの１つ以上は、基礎的データパケットが、本来、第１のネットワークルーティングプロトコルまたは第２のネットワークルーティングプロトコルと関連付けられているものであるかどうかを示すフラグとして、使用されてもよい。例えば、第２のネットワークルーティングプロトコルのネットワークルーティング情報３４ｂの中の特定のビットを「１」に設定することにより、基礎的データパケット３５がＩＰｖ６データパケットであることを示してもよい一方で、第２のネットワークルーティングプロトコルのネットワークルーティング情報の中のこの特定のビットを「０」に設定することは、基礎的データが、本来、第２のネットワークルーティングプロトコルを使用して作成またはカプセル化されているデータ（例えば、本来、ＷｉｒｅｌｅｓｓＨＡＲＴデータフレームとして作成されたデータフレーム）を示してもよい。当然ながら、そのようなフラグまたは指示は、単一のビット、複数のビット、バイト、複数のバイト等の任意の所望の長さであってもよい。

【0045】

次に、図３のブロック４７では、スタックのデータリンク層が、（ヘッダおよび／またはトレーラ情報の形態の）データリンク情報３６を、ブロック４６によって作成される結果として生じたパケット３７に追加してもよく、データリンク層情報３６は、第２の通信ネットワークで使用されている特定のデータリンクプロトコルによって定義される。次いで、ブロック４８が、第２の通信ネットワークの物理層によって定義されるように、物理層情報３８を、ブロック４７からの結果として生じたパケットに追加してもよい。次いで、ブロック４９が、データパケット（その中に第１および第２の両方のネットワークルーティングプロトコルの両方のネットワークルーティング情報を有する）を送信または伝送してもよい。

【0046】

一般的に言えば、第２のネットワークルーティングプロトコルを使用する通信ネットワーク（すなわち、第２の通信ネットワーク）内の受信デバイスにおいて、パケットの種々の物理およびデータリンク層情報が、取り除かれて復号され、典型的な方式で使用されるであろう。また、受信デバイスのスタックは、第２のネットワークルーティングプロトコルのネットワークルーティング情報を取り除いて復号する、ネットワーク層を有するであろう。このプロセス中に、受信デバイスのスタックのネットワーク層は、基礎的データパケットが第１または第２のネットワークルーティングプロトコルパケットであるかどうかを示すために、フラグまたは他の指示として使用されている、この第２のネットワークルーティング情報の特定のビットまたはバイトを復号し、その情報をさらなる処理のために使用するであろう。具体的には、フラグまたは指示が、復号されると、基礎的パケットが、第２のネットワークルーティングプロトコルを使用する典型的または通常パケットであることを示す場合、パケットは、第２の通信ネットワークプロトコルに従って動作するスタックのトランスポート層に渡される。他方で、フラグまたは他の指示が、復号されると、例えば、基礎的パケットがＩＰｖ６パケットである（すなわち、第１のネットワークルーティングプロトコルと関連付けられる）ことを示す場合には、パケットは、第１のネットワークルーティングプロトコルに従ってパケットの復号およびルーティングを処理する、スタックのネットワーク層に渡される。例えば、パケットがＩＰｖ６パケットである場合において、ネットワークスタックは、元のＩＰｖ６パケットを形成するように一連の受信したパケットを集結することによって、パケットをデフラグしてもよく、次いで、典型的な方式でトランスポート層復号および処理を行うように、デフラグされたＩＰｖ６パケットを、第１のネットワーク通信プロトコルに従って構成されるスタックのトランスポート層に提供してもよい。このように、ＩＰｖ６パケットは、処理のためにデバイス内の正しいアプリケーションに提供されるか、またはＩＰネットワークルーティングを使用して別のネットワーク上でルートされてもよい。

【0047】

しかしながら、理解されるように、第１のネットワーク通信プロトコル（すなわち、第１のネットワークルーティングプロトコルに依存するもの）を使用して作成されるデータパケットは、第２の通信ネットワーク（ルーティング通信用の第２のネットワークルーティングプロトコルを使用する）上で送信され、第１のネットワークルーティングプロトコルおよび第２のネットワークルーティングプロトコルの両方に対する、またはそれらによって定義されるようなネットワークルーティング情報を含む。この通信技法は、ネットワーク通信用の第１のネットワークルーティングプロトコルを使用しない通信ネットワークに接続されるデバイスでもある、任意のデバイスの中で第１のネットワーク通信プロトコル（ＩＰネットワークルーティングプロトコル等の第１のネットワークルーティングプロトコルに依存する）を使用してネットワーク上で伝送されるであろうということに従って、またはそのように仮定して、データパケットが作成されることを可能にする。この通信技法はまた、第２の通信ネットワークが第１のネットワークルーティングプロトコルを使用するルーティングを使用またはサポートしないときでさえも、第１のネットワークルーティングプロトコルを使用しない第２の通信ネットワーク上のデバイスが、第２の通信ネットワーク上で第１のネットワークルーティングプロトコルに従って作成されるデータパケットを送信および受信することも可能にする。この特徴は、第２の通信ネットワーク上のデバイスが、第１のネットワークルーティングプロトコルに準拠するデータパケットを使用して相互に通信することを可能にし、加えて、第２の通信ネットワーク上のデバイスが、第１のネットワークルーティングプロトコルに従って構成されるデータパケットを使用して、異なる通信ネットワーク（例えば、第１のネットワークルーティングプロトコルを使用するルーティングをサポートするネットワーク）上のデバイスと直接通信することを可能にする。

【0048】

ここで、この通信技法を使用して生じ得る通信のタイプのいくつかの実施例を、さらに詳細に論議する。以下で提供される実施例のうちのいくつかでは、第１の通信ネットワーク上の第１のコンピュータデバイスが、第１のネットワークルーティングプロトコル、例えば、ＴＣＰ／ＩＰを使用する、１つのネットワーク通信プロトコルに従ってデータフレームを作成し、これらのデータフレームを、第２のネットワークルーティングプロトコル、例えば、ＷｉｒｅｌｅｓｓＨＡＲＴプロトコルを使用する、第２の通信ネットワーク上に位置する第２のコンピュータデバイスへ伝送する。（しかしながら、上述のように、ネットワークルーティングプロトコルの他のタイプまたは具体的実施例を第１および第２の通信ネットワークで使用することができる。）以下の実施例では、第１のコンピュータデバイスは、８０２．３標準等のデータリンク層通信プロトコルに準拠する通信チャネルを介して、データフレームを伝送してもよく、第２のコンピュータデバイスは、８０２．１５．４標準等の同一または異なるデータリンクプロトコルに準拠する通信チャネルを介して、データフレームを受信してもよい。本明細書で使用されるように、データリンクプロトコルはまた、概して、物理層プロトコルとも呼ばれる。

【0049】

上述のように、データリンクプロトコルまたは標準は、とりわけ、特定の通信プロトコルに準拠する通信チャネルを介した通信トランザクション中に伝送または受信され得る、データフレームの最大サイズを定義する。データフレームの最大サイズは、概して、最大伝送単位（ＭＴＵ）サイズと呼ばれる。例えば、８０２．１５．４標準に準拠する通信チャネルを介して伝送されるデータフレームのＭＴＵサイズは、典型的には、１０２バイトである。８０２．１１標準に準拠する通信チャネルを介して伝送されるデータフレームのＭＴＵは、典型的には、２２７２バイトである。８０２．３標準に準拠する通信チャネルを介したデータフレームのＭＴＵは、１５００バイトである。

【0050】

別個に、ネットワークルーティングプロトコル標準はまた、ネットワークルーティングプロトコルに従ってパッケージ化されるデータフレームのＭＴＵサイズを定義してもよい。例えば、ＩＰｖ６標準は、典型的には１２８０バイトであるものとして、データフレームのＭＴＵを定義する。したがって、いくつかのシナリオでは、単一のトランザクションにおいて、８０２．１５．４標準に準拠する通信チャネルを介してＩＰｖ６データフレームを伝送することが不可能であり得る。これらのシナリオにおいて、ＩＰｖ６データフレームが８０２．１５．４標準に準拠する通信チャネルを介して伝送される前に、ＩＰｖ６データフレームは、いくつかのデータフレームに断片化されてもよい。データフレーム断片は、受信デバイスにおいてデータフレーム断片の再組立を可能にする情報とともにカプセル化されてもよく、ＩＰｖ６データフレームの意図した受信側であるコンピュータデバイスにおいて組み立て直されてもよい。断片化および再組立は、６ＬｏＷＰＡＮ等のプロトコルを利用することによって行われてもよい。断片化の結果として、ＩＰｖ６データ断片のうちのいくつかまたは全てが、ＩＰヘッダを含まなくてもよい。

【0051】

以下で説明される実施例では、ＩＰｖ６データフレームの断片は、ＷｉｒｅｌｅｓｓＨＡＲＴプロトコルに準拠するデータフレームを処理するように構成されるコンピュータデバイス間のＩＰｖ６データフレームのルーティングを促進するように、第２のネットワークルーティングプロトコル、例えば、ＷｉｒｅｌｅｓｓＨＡＲＴネットワークルーティングプロトコルに対応するヘッダ情報とともにカプセル化されてもよい。いくつかの実施例では、上述のように、ＷｉｒｅｌｅｓｓＨＡＲＴネットワークプロトコルヘッダは、データフレームがＩＰｖ６データフレームであることを示すフラグを含んでもよい。ここで、コンピュータデバイスは、ＷｉｒｅｌｅｓｓＨＡＲＴネットワークプロトコル情報とともにカプセル化されるＩＰｖ６データフレーム断片、およびＷｉｒｅｌｅｓｓＨＡＲＴネットワークプロトコル情報とともにカプセル化される非ＩＰｖ６データフレームを受信および伝送するように構成されてもよい。

【0052】

一般的に言えば、本明細書で説明される通信技法は、ある場合では、第１のタイプのデータフレームを作成すること、すなわち、ＩＰプロトコル等の第１のネットワークプロトコルを使用することと、そのデータフレームを、第１のネットワークプロトコルに従ったネットワークルーティングを使用するネットワーク上で、非ＩＰプロトコル等の第２の異なるネットワークルーティングプロトコルを使用する第２の通信ネットワークに接続される第２のデバイスへ送信することとを伴う。第２のデバイスは、第２のネットワークルーティングプロトコルによって定義されるネットワークルーティング情報を有するデータフレームの中で、その中に第１のネットワークルーティング情報を伴うデータフレームをカプセル化し、データフレームを、第２のネットワークルーティングプロトコルを使用する第２の通信ネットワーク上で、第１のタイプのデータフレーム（例えば、ＩＰデータフレーム）を生じるように受信したデータフレームを復号する第３のデバイスへ送信またはルートする。図４Ａのフローチャート２００は、この方法をさらに詳細に図示し、その上で通信が起こる種々の通信ネットワーク内の異なるデバイスにおいて講じられる、またはデバイスによって行われる、いくつかのステップを含む。

【0053】

具体的には、図４Ａのフローチャート２００のブロック２０２、２０４、および２０６は、ＩＰネットワークルーティングプロトコル（例えば、ＩＰｖ６）等の第１のネットワークルーティングプロトコルを使用する第１の通信ネットワークに接続された第１のデバイスにおいて実施される。ブロック２０８、２１０、および２１２は、第１の通信ネットワークと、第１のネットワークルーティングプロトコルとは異なるＷｉｒｅｌｅｓｓＨＡＲＴ通信ネットワーク等の第２のネットワークルーティングプロトコルを使用する第２の通信ネットワークとの間の接合点に位置する、ゲートウェイデバイス等の第２のデバイスにおいて実施される。（ここでは、ＷｉｒｅｌｅｓｓＨＡＲＴ通信ネットワークは、典型的には、プロセスプラントおよび他のタイプの製造プラントで通信を実装するためにプロセス制御業界で使用される、特殊メッシュネットワークであると留意されるであろう。一般的に言えば、ＷｉｒｅｌｅｓｓＨＡＲＴネットワークプロトコルは、プロセス制御ネットワーク内でより良好なルーティングを可能にするように、プロセス制御またはプロセスシステムコマンド等の種々の他のタイプの情報がデータパケットのネットワークルーティング情報の中に配置されることを求める。そのようなコマンドは、ＩＰネットワークルーティングプロトコルによってサポートされていない。）ブロック２１４、２１６、２１８、および２２０は、第１の通信ネットワーク上の第１のデバイスによって作成される元のデータパケットを受信するデバイスである、第２の通信ネットワークに接続された受信デバイスにおいて実施される。

【0054】

具体的には、ブロック２０２では、第１の通信ネットワーク（例えば、ＩＰベースの通信ネットワーク）上の第１のデバイス内のアプリケーションが、第１のネットワークルーティングプロトコル（この実施例についてはＩＰｖ６プロトコル等のＩＰプロトコルであると仮定される）を使用する通信ネットワーク上で、アプリケーションデータパケットまたはメッセージをルートすることと一致する方式で、そのメッセージを生成する。ブロック２０４は、第１のネットワークルーティングプロトコルに準拠する第１のネットワークルーティング情報とともに、（そのように所望される場合、スタックのプレゼンテーション層、セッション層、およびトランスポート層によって処理されるような）アプリケーションメッセージをカプセル化するように動作する。この実施例では、ブロック２０４の出力は、インターネット等のＩＰネットワーク上で伝送する準備ができている標準ＩＰｖ６データパケットであってもよい。次に、ブロック２０６は、例えば、ＩＰアドレスルーティングを使用して、第１のネットワークルーティングプロトコルを使用する第１の通信ネットワークまたはチャネルにわたって、カプセル化アプリケーションデータパケットを伝送させる。当然ながら、ブロック２０６は、第１の通信ネットワーク上でＩＰｖ６データパケットを送信する前に、通信スタックのデータリンクおよび物理層においてデータパケットを処理してもよい。

【0055】

次に、例えば、第１の通信ネットワークを第２の通信ネットワークに接続するゲートウェイデバイス内のブロック２０８が、データフレームを受信して復号し、データフレームの第１のネットワークルーティング情報内のＩＰアドレスが第２の通信ネットワーク上のデバイスに対するものである、またはそれと関連付けられることを認識する。次いで、ゲートウェイデバイス内のブロック２０８は、第２のネットワークルーティングプロトコルに準拠し、元のＩＰｖ６データパケット内のＩＰアドレスと関連付けられる第２の通信ネットワーク上に位置するデバイスへデータパケットをルートするように構成される、第２のネットワークルーティング情報とともに、受信したデータパケット（第１のネットワークルーティングプロトコルのネットワークルーティング情報を含む）をフレームに入れることによって、第２の通信ネットワークによって使用される第２のネットワークルーティングプロトコルに準拠するデータフレームを生成する。必要または所望であれば、ブロック２０８は、それらの作成されたデータパケットのそれぞれ（またはデータパケット断片）上に第２のネットワークルーティング情報を配置する前に、受信したＩＰｖ６データパケットからいくつかのデータパケットを作成するために、例えば、６ＬｏＷＰＡＮ断片化技法を使用して、受信したＩＰｖ６データパケットを断片化するように動作してもよい。

【0056】

加えて、ブロック２１０は、作成されているパケット内の基礎的データフレームが、第１のネットワークルーティングプロトコルと関連付けられるアプリケーションデータを有することを示す、フラグを、データパケットの第２のネットワークルーティング情報の中に設定すること等によって、指標を生成する。次いで、ゲートウェイデバイス内のブロック２１２は、データパケット内の第２のネットワークルーティングプロトコル情報を使用する第２のネットワークルーティングプロトコルに従って動作する、第２の通信ネットワークまたは第２の通信ネットワーク上のチャネルにわたって、データフレームを伝送させる。

【0057】

受信デバイス、すなわち、元のデータフレームのＩＰアドレスと関連付けられるが、第２の通信ネットワーク上に位置するデバイスにおけるブロック２１４は、データフレームの第２のネットワークルーティング情報に基づいて、スタックの物理、データリンク、およびネットワーク層において、データフレームを受信して復号する。このデバイス内のブロック２１６は、受信したデータパケットの第２のネットワークルーティング情報の中の指標またはフラグの存在または非存在を検出するように動作する。そのようなフラグが存在しない場合、または基礎的データパケットが本来、第２のネットワークルーティングプロトコルと関連付けられたデータパケットとして作成されたことをフラグが示す場合、ブロック２１８は、データパケットを、処理するために、第２のネットワーク通信プロトコルと関連付けられる受信デバイスのスタックのトランスポート層に提供する。しかしながら、指標が存在する場合、または基礎的データパケットが、本来、第１のネットワークルーティングプロトコル（例えば、ＩＰプロトコル）と関連付けられたデータパケットとして作成されたことをフラグが示す場合、ブロック２２０は、パケットを復号して処理するように、データを、第１のネットワークルーティング情報を使用する受信デバイスのスタックのネットワーク層に提供する。スタックのこのネットワーク層は、最初に、元のＩＰｖ６データパケットを組み立て直すように、一連のそのような受信したパケットをデフラグしてもよく、次いで、ＩＰネットワークルーティングプロトコルを使用して受信デバイスに送信されたかのように、ＩＰｖ６データパケットが受信デバイスのスタックの中のアプリケーションまたはアプリケーション層に送達され得るように、標準ＩＰネットワーク層およびトランスポート層処理を使用して、ＩＰｖ６データパケットを処理してもよい。

【0058】

同様に、本明細書で説明される通信技法は、第１のタイプのデータフレームを作成すること、すなわち、ＩＰプロトコル等の第１の通信ネットワークと関連付けられる第１のネットワークプロトコルを使用することと、最初に、そのデータフレームを、第２のネットワークルーティングプロトコル（第１のネットワークルーティングプロトコルとは異なる）を使用する第２のネットワーク上で、第１の通信ネットワークにも接続される第２のデバイスへ送信することとを伴うことができる。この場合、第１のデバイスは、第２のネットワークルーティング情報とともに、その中に第１のネットワークルーティングプロトコル情報を有するデータフレームをカプセル化し、第２のネットワークルーティングプロトコルを使用する第２の通信ネットワーク上で、データフレームを第２のデバイスに送信またはルートする。次いで、第２のデバイスは、第１のタイプのデータフレーム（例えば、ＩＰデータフレーム）を生じるように、第２のネットワークルーティングプロトコルを使用して、受信したデータフレームを復号し、次いで、第１のネットワークルーティングプロトコルを使用する第１の通信ネットワーク上で、復号されたデータフレームを送信する。図４Ｂのフローチャート２５０は、その上で通信が起こる種々の通信ネットワーク内の異なるデバイスにおいて講じられる、またはデバイスによって行われる、いくつかのステップを含むものとして、この方法をさらに詳細に図示する。

【0059】

具体的には、図４Ｂのフローチャート２５０のブロック２５２、２５４、２５６、２５８、および２６０は、ＷｉｒｅｌｅｓｓＨＡＲＴネットワークルーティングプロトコル等の第２のネットワークルーティングプロトコルを使用する、第２の通信ネットワークに接続された第１のデバイスにおいて実施される。ブロック２６２、２６４、および２６８は、第１の通信ネットワーク（例えば、ＩＰベースの通信ネットワーク）と、第２のネットワークルーティングプロトコルを使用する第２の通信ネットワークとの間の接合点に位置する、ゲートウェイデバイス等の第２のデバイスにおいて実施される。ブロック２７０は、第２の通信ネットワーク上の第１のデバイスによって作成される元のデータパケットを受信するデバイスである、第１の通信ネットワークに接続された受信デバイスにおいて実施されてもよい。

【0060】

具体的には、ブロック２５２が、第２の通信ネットワーク上のＩＰ使用可能デバイス（例えば、ＩＰ使用可能ＷｉｒｅｌｅｓｓＨＡＲＴデバイス）内で実施され、データパケットが第１の通信プロトコルに準拠する通信ネットワーク上で送信されるであろう（例えば、ＩＰネットワークプロトコルに準拠するデータパケット）と仮定して、アプリケーションデータパケットを生成する。したがって、このデータパケットを生成するアプリケーションは、ソケットベースのアプリケーションであってもよい。図４Ａに関して上述のように、このデータパケットで使用されるＩＰアドレスは、最初に、例えば、ＩＰネットワークに接続されるＷｉｒｅｌｅｓｓＨＡＲＴ通信ネットワーク上で、ゲートウェイデバイスと通信し、ＷｉｒｅｌｅｓｓＨＡＲＴデバイスによって提供されるドメイン名の正しいＩＰアドレスを判定するように、ゲートウェイデバイスにＤＮＳサービスを行わせる（例えば、ＤＮＳサーバの役割を果たさせる）ことによって、取得されてもよい。ＩＰ使用可能デバイスのブロック２５４は、例えば、ＩＰアドレス指定情報をデータメッセージに追加することによって、第１のネットワークルーティングプロトコルに準拠する第１のネットワークルーティング情報とともに、（ＩＰ使用可能デバイス内のスタックの適切なプレゼンテーション、セッション、およびトランスポート層によって処理された後の）アプリケーションメッセージをカプセル化する。次に、ブロック２５６は、第２のネットワークルーティングプロトコルに準拠する第２のネットワークルーティング情報とともに、ブロック２５４からのアプリケーションデータパケットをフレームに入れることによって、第２のネットワークルーティングプロトコルに準拠するデータフレームを生成する。この場合、ブロック２５６は、第２のネットワークルーティング情報を断片化データパケットのそれぞれに追加する前に、第２の通信ネットワークによって許容されるサイズに準拠する一組のデータパケットを作成するように、ブロック２５４によって作成されたデータパケットを断片化してもよい。ブロック２５８もまた、基礎的データフレームが、第１のネットワークルーティングプロトコルと関連付けられるアプリケーションデータ（例えば、ＩＰｖ６データパケット）を有することを示す指標を、それぞれのそのようなデータパケットの第２のネットワークルーティング情報内に生成または配置する。次いで、ブロック２６０は、これらのパケット内の第２のネットワークルーティング情報を使用する第２のネットワークルーティングプロトコルに従って動作する、第２の通信ネットワークのチャネルにわたって、ブロック２５６および２５８によって作成されたデータフレームを伝送させる。

【0061】

例えば、その異なる入力において、第２の通信ネットワークおよび第１の通信ネットワークの両方に接続される、ゲートウェイデバイスにおいて実施されるブロック２６２は、第２の通信ネットワークを介して受信されるデータフレームを受信し、これらのデータフレーム内の第２のネットワークルーティング情報に基づいて復号する。ブロック２６４は、基礎的ＩＰデータの存在を示す、受信したデータフレームの第２のネットワークルーティング情報の中の指標またはフラグの存在を検出するように、このゲートウェイデバイス内で動作する。そのようなフラグがデータパケットの中に存在しない場合、ブロック２６６は、データを復号して処理するように第２の通信プロトコルに従って動作する受信デバイスのトランスポート層にデータパケットを提供してもよく、または第２の通信ネットワークを介して、そのデータにさらなるルーティングを行ってもよい。しかしながら、フラグが存在するか、または設定されている場合、ブロック２６８は、例えば、元のＩＰｖ６データパケット内にＩＰネットワークルーティング情報を含む、その元のＩＰｖ６データパケットを生じるように、第２の通信ネットワーク上で受信される複数のデータパケットからＩＰデータフレーム情報を復号して組み立て直すことによって、基礎的ＩＰデータフレームを回収する。次いで、ブロック２６８は、第１のネットワークルーティングプロトコルを使用する第１の通信ネットワークの通信チャネルを介して、データパケットを受信側に伝送するために、その組み立て直されたＩＰｖ６データパケット内のＩＰネットワークルーティング情報（例えば、ＩＰアドレス情報）を使用してもよい。ブロック２７０では、受信デバイス（すなわち、第１のデバイスによって作成されるようなＩＰｖ６データパケットのＩＰ宛先アドレスを有するデバイス）が、任意の公知または標準の方式で、ＩＰｖ６データパケットを受信して復号してもよい。

【0062】

理解されるように、これらの基本的通信技法は、その中の通信にＩＰベースのルーティングを使用またはサポートしない、プロセスプラント通信ネットワーク等の通信ネットワーク内で、またはそれにわたって、ＩＰデータメッセージングまたは通信（例えば、ＩＰｖ６データフレーム等のＩＰデータフレームのメッセージング）を提供するために、種々の異なるシナリオで使用することができる。いくつかのこれらのシナリオを、以下で実施例のみとして説明する。

【0063】

図５は、プロセスプラント内のフィールドデバイスが、インターネット５１を介して、およびＩＰネットワークルーティングをサポートしないＷｉｒｅｌｅｓｓＨＡＲＴ通信ネットワークであり得る、１つ以上のプロセス制御ベースの通信ネットワーク５３および７１を介して、ＩＰｖ６データフレームを受信および伝送するように、本明細書で説明される通信方法を実装する、通信ネットワーク例５０を図示する。一般に、化学、石油、または他のプロセスプラントで使用されるもの等のプロセス制御システムは、プロセス内で感知および物理的制御機能を果たす、フィールドデバイス５９〜６５および７６〜８１として図５で図示される、フィールドデバイスを含む。フィールドデバイス５９〜６５および７６〜８１のそれぞれは、例えば、弁、弁ポジショナ、スイッチ、センサ（例えば、温度、圧力、または流速センサ）、ポンプ、ファン、コントローラ、入出力デバイス等であってもよい。フィールドデバイスは、弁を開放または閉鎖すること、およびプロセスパラメータの測定を行うこと等の、プロセスまたはプロセス制御ループ内の制御および／または物理的機能を果たす。無線通信ネットワーク５３および７１では、フィールドデバイス５９〜６５および７６〜８１は、ＷｉｒｅｌｅｓｓＨＡＲＴデータフレームおよびＩＰｖ６データフレーム等のデータフレームの生産装置および消費装置である。ＩＰｖ６データフレームを作成、受信、および使用することが可能である、ネットワーク５３および７１内のデバイスを、本明細書ではＩＰ使用可能デバイスと呼ぶ。

【0064】

概して、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク５３および７１内で、コンピュータデバイスは、データフレームをデータフレームの意図した受信側であるコンピュータデバイスへルートするために、ＷｉｒｅｌｅｓｓＨＡＲＴネットワークルーティング技法を利用する。フィールドデバイスは、典型的であるように、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク５３および７１上で典型的なＷｉｒｅｌｅｓｓＨＡＲＴデータフレームを作成して伝送してもよい。しかしながら、上記の論議から理解されるように、データフレームはまた、ＷｉｒｅｌｅｓｓＨＡＲＴネットワークルーティング情報とともにカプセル化されたＩＰｖ６データフレーム断片を含んでもよく、またはＷｉｒｅｌｅｓｓＨＡＲＴネットワークルーティング情報とともにカプセル化された非ＩＰｖ６データフレーム断片を含んでもよい。この状況において、例えば、ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴゲートウェイ５４は、好適なプロトコル、例えば、６ＬｏＷＰＡＮを利用して、インターネット５１から受信されるＩＰｖ６データフレームを断片化するステップ、およびデータフレーム断片がＷｉｒｅｌｅｓｓＨＡＲＴネットワーク５３内でルートされることを可能にするＷｉｒｅｌｅｓｓＨＡＲＴネットワークプロトコル情報とともに、データフレーム断片をカプセル化するステップを行ってもよい。

【0065】

図５で図示されるように、ネットワーク５３と関連付けられるＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴゲートウェイ５４、およびネットワーク７１と関連付けられるＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴゲートウェイ７０は、インターネット５１に接続される。ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴゲートウェイ５４および７０はそれぞれ、独立型デバイスとして、ワークステーション（図示せず）の拡張スロットの中へ挿入可能なカードとして、プログラマブルロジックコントローラ（ＰＬＣ）ベースのシステムの入出力サブシステムの一部として、または任意の他の方式で実装されてもよい。プロトコルおよびコマンド変換に加えて、ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴゲートウェイ５４および７０は、それぞれ、ＷｉｒｅｌｅｓｓＨＡＲＴ通信ネットワーク５３および７１のスケジューリング方式のタイムスロットおよびスーパーフレーム（時間的に同等に離間された通信タイムスロットのセット）によって使用される同期クロッキングを提供してもよい。

【0066】

加えて、ＷｉｒｅｌｅｓｓＨＡＲＴ通信ネットワーク５３は、ルータデバイス５７および５８を含んでもよい。ルータデバイス５７は、例えば、１つの無線ネットワークデバイスから別の無線ネットワークデバイスへデータフレームを転送する、ネットワークデバイスである。ルータデバイスの役割を果たしているネットワークデバイスは、どの無線ネットワークデバイスが特定のデータフレームの次の受信側であるかを決定するために、内部ルーティングテーブルを使用する。ルータ５７等の独立型ルータは、ＷｉｒｅｌｅｓｓＨＡＲＴ通信ネットワーク５３上の全てのデバイスがルーティングをサポートするシナリオで必要とされなくてもよい。しかしながら、ＷｉｒｅｌｅｓｓＨＡＲＴ通信ネットワーク５３内でルーティング５７等の専用ルータを有すること（例えば、ネットワークを拡張すること、またはネットワーク内のフィールドデバイスの電力を節約すること）が有益であり得る。

【0067】

ＷｉｒｅｌｅｓｓＨＡＲＴ通信ネットワーク５３はまた、ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴフィールドデバイス６２、６３、６４、および６５を含むものとしても図示される。ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴフィールドデバイス６２は、例えば、ＷｉｒｅｌｅｓｓＨＡＲＴネットワークルーティングプロトコル情報内でカプセル化された６ＬｏＷＰＡＮ ＩＰｖ６データフレーム断片を受信して処理することが可能であり得、かつＷｉｒｅｌｅｓｓＨＡＲＴネットワークルーティングプロトコル情報内でカプセル化された６ＬｏＷＰＡＮ ＩＰｖ６データフレーム断片を作成してルートすることが可能であり得る。同様に、ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴフィールドデバイス６２は、例えば、ＷｉｒｅｌｅｓｓＨＡＲＴプロトコルヘッダとともにカプセル化された非ＩＰｖ６データフレームを別のＷｉｒｅｌｅｓｓＨＡＲＴフィールドデバイスへルートすることが可能であり得る。ルーティングを行うために、ＷｉｒｅｌｅｓｓＨＡＲＴフィールドデバイス６２は、例えば、特定のデータフレームをカプセル化するＷｉｒｅｌｅｓｓＨＡＲＴネットワークルーティングヘッダの中のルーティング情報を利用する。

【0068】

ＷｉｒｅｌｅｓｓＨＡＲＴ通信ネットワーク５３はまた、従来のＷｉｒｅｌｅｓｓＨＡＲＴフィールドデバイス５９、６０、および６１を含んでもよい。ＷｉｒｅｌｅｓｓＨＡＲＴフィールドデバイス５９、６０、および６１は、ＷｉｒｅｌｅｓｓＨＡＲＴネットワークプロトコル情報とともにカプセル化されたデータフレームを受信および伝送することが可能である。ＷｉｒｅｌｅｓｓＨＡＲＴフィールドデバイス５９、６０、および６１はまた、ＷｉｒｅｌｅｓｓＨＡＲＴネットワークプロトコルヘッダ内にカプセル化された６ＬｏＷＰＡＮ ＩＰｖ６データフレーム断片を、データフレーム断片の意図した受信側であるＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴフィールドデバイスへルートすることも可能であり得る。ルーティングを行うために、ＷｉｒｅｌｅｓｓＨＡＲＴフィールドデバイス５９は、例えば、ルーティングを行うように６ＬｏＷＰＡＮ ＩＰｖ６データフレーム断片をカプセル化する、ＷｉｒｅｌｅｓｓＨＡＲＴネットワークルーティングプロトコルヘッダの中のルーティング情報を利用する。ＷｉｒｅｌｅｓｓＨＡＲＴ使用可能フィールドデバイス５９、６０、および６１は、その中にＩＰｖ６データフレームを含む、そのようなデータフレームを含む、ＷｉｒｅｌｅｓｓＨＡＲＴメッセージまたはデータフレームをルートすることが可能であるが、これらのデバイスは、ＩＰｖ６データフレーム自体を復号または使用することが可能ではない。

【0069】

ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク５３内のルータ５８は、例えば、フィールドデバイス５９からのＷｉｒｅｌｅｓｓＨＡＲＴネットワークプロトコルヘッダとともにカプセル化されたデータフレームを受信することが可能であり得る。ルータ５８は、例えば、ＷｉｒｅｌｅｓｓＨＡＲＴネットワークプロトコルヘッダの中のルーティング情報に基づいて、データフレームを隣接フィールドデバイス６０へルートしてもよい。

【0070】

図５のシステム例では、ＷｉｒｅｌｅｓｓＨＡＲＴ通信ネットワーク７１は、ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴゲートウェイデバイス７０、１つ以上のルータデバイス７４および７５、いくつかのＩＰｖ６使用可能フィールドデバイス７９、８０、８１、および８２、ならびにいくつかの従来のＷｉｒｅｌｅｓｓＨＡＲＴフィールドデバイス７６、７７、および７８を含む。上述のデバイスは、８０２．１５．４標準に準拠する通信チャネルを介して、データフレームを伝送および受信してもよい。この場合、ＷｉｒｅｌｅｓｓＨＡＲＴ通信ネットワーク７１内のコンピュータデバイス８２は、ハンドヘルドコンピュータデバイスであってもよい。コンピュータデバイス８２は、８０２．１５．４標準に準拠する通信チャネルを介してＷｉｒｅｌｅｓｓＨＡＲＴ通信ネットワーク７１内でデータフレームを伝送および受信することが可能である、アダプタを提供されてもよい。加えて、コンピュータデバイス８２は、ＩＰｖ６使用可能フィールドデバイス８２から、ＷｉｒｅｌｅｓｓＨＡＲＴネットワークプロトコル情報内にカプセル化されたＩＰｖ６データフレーム断片、およびＷｉｒｅｌｅｓｓＨＡＲＴネットワークプロトコル情報内にカプセル化された非ＩＰｖ６データフレームを受信および伝送してもよい。所望であれば、コンピュータデバイス８２は、非ＩＰｖ６使用可能フィールドデバイス８１から、ＷｉｒｅｌｅｓｓＨＡＲＴネットワークプロトコル情報内にカプセル化された非ＩＰｖ６データフレームを受信および伝送してもよい。これらの実施例のそれぞれでは、データフレームをカプセル化するＷｉｒｅｌｅｓｓＨＡＲＴネットワークプロトコルヘッダ内のルーティング情報は、データフレームのＷｉｒｅｌｅｓｓＨＡＲＴネットワーキングルーティング情報に基づいて、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク７１内のデータフレームをデータフレームの意図した受信側であるデバイスへルートするために、中間ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴデバイスおよび非ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴデバイスによって利用される。

【0071】

本明細書で説明される１つのシナリオでは、異なるＷｉｒｅｌｅｓｓＨＡＲＴネットワーク５３および７１内の２つのＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴデバイスはまた、ネットワーク５３および７１のそれぞれの上で送信され、かつインターネット５１を介してネットワーク５３および７１の間で送信される、ＩＰｖ６データフレームを使用して、相互と通信してもよい。実施例として、ネットワーク７１内のコンピュータデバイス８２は、これらのネットワークにわたって、およびインターネット５１上で送信されるＩＰｖ６データフレームを伝送および受信することによって、例えば、他方のＷｉｒｅｌｅｓｓＨＡＲＴネットワーク５３内に位置する、ＩＰｖ６使用可能フィールドデバイス６３と通信してもよい。このシナリオでは、コンピュータデバイス８２において実行する、ウェブブラウザ等のアプリケーションが、ＩＰｖ６データフレームを生成してもよい。実施例のみとして、データフレームの中のデータは、ＩＰｖ６使用可能フィールドデバイス６３からのウェブページデータの要求に対応してもよい。コンピュータデバイス８２は、ウェブページ要求に対応する１つ以上のＩＰｖ６データフレームを生成するためにＴＣＰ／ＩＰネットワークプロトコルスタックを利用してもよい。

【0072】

再度、上述のように、コンピュータデバイス８２は、最初に、標準ＷｉｒｅｌｅｓｓＨＡＲＴメッセージングを使用して、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク７１を通してゲートウェイデバイス７１へ通信することによって、（例えば、デバイスまたはデバイス６３のホストと関連付けられる）ＩＰｖ６データフレームを生成するために使用する１つまたは複数のＩＰアドレスを判定してもよい。この場合、デバイス８２は、デバイス６３において到達されるウェブサイトまたは他のホストのドメイン名等の名前を有するメッセージを送信し、ＤＮＳサービスを実装して（またはインターネット５１上のＤＮＳサーバとしての役割を果たし、あるいはＤＮＳサーバに連絡して）ＩＰアドレスに対するドメイン名を解決するように、ゲートウェイデバイス７１に要求してもよい。次いで、ゲートウェイデバイス７０は、デバイス８２がその中に正しいＩＰｖ６宛先アドレスを伴う（例えば）ＩＰｖ６データパケットを作成することを可能にするように、このＩＰアドレスをデバイス８２に返信してもよい。デバイス８２は、ゲートウェイデバイス７２からＩＰアドレスＤＮＳサービスを要求するために標準ＷｉｒｅｌｅｓｓＨＡＲＴメッセージングを使用することができるが、デバイス８２はまた、本明細書で説明される通信技法を使用して（すなわち、ＷｉｒｅｌｅｓｓＨＡＲＴネットワークルーティング情報の中にそのようなＩＰデータフレームをカプセル化し、処理するためにカプセル化データフレームをゲートウェイデバイス７０に送信し、ゲートウェイデバイス７０内のＩＰまたはソケットベースのアプリケーションによって復号することによって）別のネットワークエンティティのＩＰアドレスを要求するために、ゲートウェイデバイス７０にアドレス指定されたＩＰｖ６データパケットを使用することもできる。同様に、ゲートウェイデバイス７０は、ＷｉｒｅｌｅｓｓＨＡＲＴネットワークルーティング情報の中にカプセル化されたＩＰデータメッセージを介して、または標準ＷｉｒｅｌｅｓｓＨＡＲＴメッセージングを介して、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク７１上で判定されたＩＰアドレスを返信することができる。

【0073】

いったん作成されると、次いで、ＩＰｖ６データフレームは、６ＬｏＷＰＡＮプロトコルスタックによって断片化されてもよく、１つ以上の断片は、図３のフローチャート４０に関して説明される方式でデータフレームをＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴゲートウェイ７０に送信するように設計されている、ＷｉｒｅｌｅｓｓＨＡＲＴネットワークルーティング情報内でカプセル化されてもよい。次いで、コンピュータデバイス８２は、ＷｉｒｅｌｅｓｓＨＡＲＴネットワークルーティングを使用して、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク７１内の８０２．１５．４準拠通信チャネルを介して、データ断片をＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴゲートウェイ７０へ伝送してもよい。データフレーム断片は、ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴゲートウェイ７０によって受信されてもよく、ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴゲートウェイ７０は、ウェブページ要求に対応するＩＰｖ６データフレームを生成するように、いくつかのデータフレーム断片を組み立て直してもよい。

【0074】

次いで、ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴゲートウェイ７０は、インターネット５１を介してＩＰｖ６データフレームをＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴゲートウェイ５４へルートするために、組み立て直されたＩＰｖ６データフレームのＩＰｖ６ヘッダの中で入手可能な宛先ＩＰアドレス情報を利用してもよい。この場合、ＩＰｖ６データパケットの宛先ＩＰアドレスは、ＩＰｖ６使用可能フィールドデバイス６３のＩＰｖ６アドレスに対応し、ゲートウェイ５４は、ネットワーク５３内のデバイスのＩＰアドレスのリストを記憶するであろう。当然ながら、ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴゲートウェイ７０は、インターネットを介したＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴゲートウェイ５４への適切なルートを判定するために、典型的または利用可能なＴＣＰ／ＩＰルーティングプロトコルを利用してもよい。

【0075】

次いで、ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴゲートウェイ５４は、ネットワーク５３上でＩＰｖ６データフレームをＩＰ使用可能フィールドデバイス６３に送信するために、図３のフローチャート４０の後部分の方法を使用してもよい。具体的には、ゲートウェイ５４は、受信したＩＰｖ６データフレームを１つ以上の６ＬｏＷＰＡＮデータフレーム断片に断片化してもよく、次いで、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク５３内のデバイス６３にアドレス指定またはルートされる方式で、そのネットワーク上でデータフレーム断片を伝送する前に、ＷｉｒｅｌｅｓｓＨＡＲＴネットワークルーティングプロトコル情報内でデータフレーム断片をカプセル化してもよい。ＷｉｒｅｌｅｓｓＨＡＲＴネットワークルーティングプロトコル情報は、例えば、中間ＷｉｒｅｌｅｓｓＨＡＲＴデバイス５９、５８、および６５が、（ＷｉｒｅｌｅｓｓＨＡＲＴネットワークルーティング情報内でカプセル化された）ＩＰｖ６データフレーム断片をＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴフィールドデバイス６３へルートすることを可能にする、ＷｉｒｅｌｅｓｓＨＡＲＴルーティング情報を含む。

【0076】

ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴフィールドデバイス６３は、ＷｉｒｅｌｅｓｓＨＡＲＴ通信ネットワーク５３を介して、いくつかのＷｉｒｅｌｅｓｓＨＡＲＴデータパケットの中の（ＷｉｒｅｌｅｓｓＨＡＲＴネットワークルーティング情報の中でカプセル化された）いくつかのデータ断片を受信し、データフレームがデバイス６３に意図されていることを判定するように、ＷｉｒｅｌｅｓｓＨＡＲＴネットワークルーティング情報を使用してデータ断片を復号してもよい。その場合、デバイスは、コンピュータデバイス８２によって伝送されるウェブページ要求に対応するＩＰｖ６データフレームを生成するように、異なるデータパケットからいくつかのデータフレーム断片を組み立て直し、この要求を、ＩＰｖ６データフレームが最初に送信されたアプリケーションに提供する。デバイスは、デバイス６３内の適正な宛先を判定するために、ＩＰｖ６データパケットの中のＩＰアドレス情報を使用してもよい。次いで、ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴフィールドデバイス６３は、例えば、同一の方法論を使用して、すなわち、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク５３、インターネット５１、およびＷｉｒｅｌｅｓｓＨＡＲＴネットワーク７１を介して、これらのＩＰｖ６データパケットを作成して送信することによって、ウェブページデータに対応するハイパーテキストマークアップ言語（ｈｔｍｌ）ＩＰｖ６データフレームを、要求デバイス８２へ戻して伝送してもよい。具体的には、上記で詳述されるもののような類似ステップを実装することによって、ｈｔｍｌ ＩＰｖ６データフレームは、ネットワーク５３内の１つ以上のＷｉｒｅｌｅｓｓＨＡＲＴフィールドデバイス、ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴゲートウェイ５４、インターネット５１、ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴゲートウェイ７０、およびネットワーク７１内の１つ以上のＷｉｒｅｌｅｓｓＨＡＲＴフィールドデバイスを介して、コンピュータデバイス８２によって送信または受信されてもよい。

【0077】

コンピュータデバイス８２はまた、好適な通信プロトコルを利用することによって、１つ以上の他の通信ネットワークと通信してもよい。例えば、図１を参照して、コンピュータデバイス８２は、ゲートウェイデバイス７０を介してセルラーネットワーク１５と通信してもよい。別のシナリオでは、コンピュータデバイス８２は、ゲートウェイデバイス７０を介してＷＬＡＮネットワーク１６と通信してもよい。なおもさらに、ＩＰメッセージまたはデータパケットは、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク５３または７１のうちの１つの中の第１のＩＰ使用可能フィールドデバイスによって作成され、本明細書で説明される通信技法を使用して、同一のＷｉｒｅｌｅｓｓＨＡＲＴネットワーク５３または７１内の別のＩＰ使用可能フィールドデバイスへ送信されてもよく、それにより、非ＩＰ通信ネットワーク上の２つデバイス間のＩＰメッセージングを可能にする。この場合、理解されるように、第１のＩＰ使用可能フィールドデバイスによって作成されるＩＰデータメッセージは、上記で説明される方式で、そのデータをＷｉｒｅｌｅｓｓＨＡＲＴ通信ネットワーク５３または７１上で送信するために使用される、ＷｉｒｅｌｅｓｓＨＡＲＴネットワークルーティング情報を用いて符号化されるであろう。しかしながら、この場合、これらのデバイスが、適切なＷｉｒｅｌｅｓｓＨＡＲＴネットワーク５３または７１内のデバイスのＩＰアドレス間の関連を定義するリンクまたはルーティングテーブル、およびこれらのデバイスのＷｉｒｅｌｅｓｓＨＡＲＴネットワークルーティング情報を記憶するため、メッセージは、依然としてゲートウェイデバイス５４または７０のうちの１つを通過する必要があり得る。しかしながら、別の場合において、ＩＰ使用可能デバイス自体が、ネットワーク内通信用のＩＰアドレスおよびルーティングテーブルを記憶してもよく、かつＷｉｒｅｌｅｓｓＨＡＲＴネットワーク内のルーティングのためにデータパケットのヘッダの中に配置される必要があるＷｉｒｅｌｅｓｓＨＡＲＴネットワークルーティング情報を判定するために、これらのＩＰルーティングテーブルを使用してもよい。

【0078】

図６は、ＷｉｒｅｌｅｓｓＨＡＲＴ通信プロトコルに従って動作するＷｉｒｅｌｅｓｓＨＡＲＴフィールドデバイスが、インターネット１０１を介して、コンピュータデバイス１１５、１１６、および１１７からＩＰｖ６データフレームを受信し、かつそれらへＩＰｖ６データフレームを伝送するように動作し得る、別のＷｉｒｅｌｅｓｓＨＡＲＴ通信ネットワーク例１００を図示する。コンピュータデバイス１１５、１１６、および１１７は、ＷＬＡＮ、ＧＳＭ、ＣＤＭＡ、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＺＩＧＢＥＥ等のプロトコルを実装するネットワーク等の非ＷｉｒｅｌｅｓｓＨＡＲＴネットワークを介して、インターネット１０１に通信可能に連結されてもよい。

【0079】

ＷｉｒｅｌｅｓｓＨＡＲＴ通信ネットワーク１００は、ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴゲートウェイ１０２、いくつかのＷｉｒｅｌｅｓｓＨＡＲＴルータ１０５および１０６、いくつかのＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴフィールドデバイス１０７、１０８、１０９、および１１０、ならびにいくつかの非ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴフィールドデバイス１１１、１１２、および１１３を含む。図６で図示されるように、ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴゲートウェイ１０２は、インターネット１０１に、およびネットワーク１００内のいくつかのフィールドデバイス１０３、１０４、および１１１に通信可能に連結される。

【0080】

一実施例では、コンピュータデバイス１１５は、インターネット１０１およびＷｉｒｅｌｅｓｓＨＡＲＴネットワーク１００の構造の両方を使用して、ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴデバイス１０７からＩＰｖ６データフレームを受信し、かつそこへＩＰｖ６データフレームを伝送する。コンピュータデバイス１１５は、例えば、図１で描写されるように、ＷＬＡＮネットワーク１６を介してインターネット１０１に通信可能に連結されてもよい。しかしながら、これらの実施例では、コンピュータデバイス１１５は、ＩＰｖ６使用可能通信能力のみを有すると仮定され、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク１００内で直接通信することはできないであろう。しかしながら、コンピュータデバイス１１５は、無線周波数識別（ＲＦＩＤ）スキャナ１１５−１等の好適な近距離通信（ＮＦＣ）スキャナを含んでもよい。ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴフィールドデバイス１０７は、ＲＦＩＤタグ１１８を提供されてもよく、このタグは、ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴフィールドデバイス１０７の識別に対応する識別コードまたはＩＤ（例えば、ＩＰアドレス）を記憶してもよい。プラント内のユーザは、例えば、ＲＦＩＤスキャナ１１５−１を介して、デバイス１０７上のＲＦＩＤタグをコンピュータデバイス１１５の中へスキャンしてもよい。ＲＦＩＤタグ上の情報は、ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴフィールドデバイス１０７と関連付けられ得る、ＩＰｖ６アドレス、ウェブＵＲＬ、または他のデータに対応してもよい。別のシナリオでは、コンピュータデバイス１１５は、ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴフィールドデバイス１０７のＩＰｖ６アドレスまたはウェブＵＲＬを受信して、コンピュータデバイス１１５がフィールドデバイス１０７と通信することを可能にするように、ＲＦＩＤタグ１１８から受信される情報を伴う遠隔データベースに問い合わせを行ってもよい。

【0081】

ウェブブラウザ等のコンピュータデバイス１１５上で実行するアプリケーションは、例えば、フィールドデバイス１０７のＩＰアドレスを使用してＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴフィールドデバイス１０７へ伝送される、ウェブページデータの要求に対応するＩＰｖ６データフレームを生成してもよい。そのようなものとして、ＩＰｖ６データフレームのＩＰヘッダの中の宛先ＩＰアドレスは、ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴフィールドデバイス１０７のＩＰｖ６アドレスに対応してもよい。コンピュータデバイス１１５は、ＷＬＡＮネットワーク１６を介して、ＩＰｖ６データフレームを、例えば、インターネット１０１の中へ伝送してもよい。ＩＰｖ６データフレームは、最終的に、標準ＩＰｖ６またはＩＰネットワークルーティングプロトコル技法を使用して、インターネット１０１を介してＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴゲートウェイ１０２へルートされ、それによって受信されてもよい。以前に説明されたように、ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴゲートウェイ１０２は、ＩＰｖ６データフレームのＩＰ宛先アドレスと関連付けられるデバイスがＷｉｒｅｌｅｓｓＨＡＲＴネットワーク１００内にあることを判定するために、ＩＰルーティングテーブルを使用してもよく、ネットワーク１００上で情報をそのデバイスへ送信するために必要とされる、ＷｉｒｅｌｅｓｓＨＡＲＴネットワークルーティング情報を判定してもよい。次いで、ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴゲートウェイ１０２は、受信したＩＰｖ６データフレームを断片化し、これらのデータフレームをネットワーク１００内のデバイス１０７へルートするために必要とされるＷｉｒｅｌｅｓｓＨＡＲＴネットワークルーティング情報を用いてデータフレーム断片のそれぞれを符号化してもよい。ゲートウェイ１０２はまた、基礎的パケットまたは情報がＩＰｖ６データパケットに由来する、またはそれと関連付けられることを示すフラグを用いて、このＷｉｒｅｌｅｓｓＨＡＲＴネットワークルーティング情報を符号化してもよく、次いで、ＷｉｒｅｌｅｓｓＨＡＲＴネットワークルーティングを使用するＷｉｒｅｌｅｓｓＨＡＲＴネットワーク１００を介して、符号化されたデータフレームをフィールドデバイス１０７へ（またはフィールドデバイス１０７と関連付けられるアプリケーションまたはＩＰアドレスへ）送信してもよい。一実施例では、ＷｉｒｅｌｅｓｓＨＡＲＴゲートウェイ１０２は、６ＬｏＷＰＡＮプロトコルに従ってＩＰｖ６データフレームを断片化してもよく、次いで、グラフＩＤ等のＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴフィールドデバイス１０７のＷｉｒｅｌｅｓｓＨＡＲＴアドレス指定情報を含む、ＷｉｒｅｌｅｓｓＨＡＲＴネットワークルーティングプロトコルヘッダの中に結果として生じるデータフレーム断片をカプセル化してもよい。当然ながら、ＷｉｒｅｌｅｓｓＨＡＲＴゲートウェイ１０２は、８０２．１５．４標準に従って動作する通信チャネル等の低出力通信チャネルを介して、ＷｉｒｅｌｅｓｓＨＡＲＴカプセル化ＩＰｖ６データフレーム断片をＷｉｒｅｌｅｓｓＨＡＲＴネットワーク１００の中へ伝送する。

【0082】

この実施例では、ＩＰｖ６使用可能フィールドデバイス１０７は、ネットワーク１００上で、標準ＷｉｒｅｌｅｓｓＨＡＲＴ通信を介してＷｉｒｅｌｅｓｓＨＡＲＴカプセル化ＩＰｖ６データフレームを受信する。ＩＰｖ６使用可能フィールドデバイス１０７は、ＷｉｒｅｌｅｓｓＨＡＲＴカプセル化パケットを受信すると、コンピュータデバイス１１５によって伝送されるＩＰｖ６データフレームに対応するＩＰｖ６データフレームを生成するように、いくつかのデータフレーム断片を組み立て直し、このデータフレームを、パケットがアドレス指定されたフィールドデバイス１０７内のアプリケーションに提供してもよい。次いで、ＩＰｖ６使用可能フィールドデバイス１０７は、コンピュータデバイス１１５によって要求される情報を含むＩＰｖ６データフレームを生成し、本明細書で説明される技法を使用して、これらのＩＰｖ６データフレームをコンピュータデバイス１１５へ送信してもよい。以前に説明されたように、フィールドデバイス１０７において作成されるＩＰｖ６データフレームは、断片化されてもよく、断片は、フィールドデバイス１０７内のＷｉｒｅｌｅｓｓＨＡＲＴネットワーク層プロトコルヘッダとともにカプセル化されてもよい。次いで、ＩＰｖ６使用可能フィールドデバイス１０７は、インターネット１０１を介してデバイス１１５へ送信するために、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク１００を介してデータフレーム断片をＷｉｒｅｌｅｓｓＨＡＲＴゲートウェイデバイス１０２へ伝送してもよい。ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴゲートウェイ１０２は、ＩＰｖ６使用可能フィールドデバイス１０７によって生成されるＩＰｖ６データフレームに対応するＩＰｖ６データフレームを生成するように、受信したデータフレーム断片を組み立て直してもよい。次いで、ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴゲートウェイ１０２は、ＩＰｖ６データフレームのＩＰアドレスを使用して、インターネット１０１を介してＩＰｖ６データフレームをデバイス１１５のＩＰアドレスへ伝送する。コンピュータデバイス１１５は、例えば、ＷＬＡＮネットワーク１６を介してＩＰｖ６データフレームを受信してもよく、ＩＰｖ６データフレームの中の情報を復号し、ウェブブラウザの中で、例えば、ユーザに表示してもよい。したがって、この実施例では、ＷｉｒｅｌｅｓｓＨＡＲＴ通信能力を持たないデバイス１１５は、デバイス間の通信がＷｉｒｅｌｅｓｓＨＡＲＴ通信プロトコル（ＩＰｖ６データフレームルーティングをサポートしない）を使用して起こらなければならない、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク上のフィールドデバイス１０７と直接的にＩＰｖ６データパケットを通信させるために、本明細書で説明される通信技法を使用してもよい。したがって、この技法は、たとえＷｉｒｅｌｅｓｓＨＡＲＴ通信ネットワークがＩＰベースの通信をサポートしなくても、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク１００外のデバイスの中で作動するアプリケーションが、ＩＰベースの通信を使用してＷｉｒｅｌｅｓｓＨＡＲＴネットワーク内のデバイスと通信することを可能にする。この技法はまた、たとえＷｉｒｅｌｅｓｓＨＡＲＴ通信ネットワークがＩＰベースの通信を本質的にサポートしなくても、ＩＰベースの通信またはソケットベースのアプリケーションを使用して、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク外のデバイスと通信するように、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク１００内のデバイスの中で作動するアプリケーションの使用も可能にする。したがって、これらの利点は、標準ＩＰ使用可能アプリケーション（非常に普及し、公知である）が、ＩＰベースの通信を使用しないＷｉｒｅｌｅｓｓＨＡＲＴネットワーク等の特殊通信ネットワーク内のデバイス内で使用されること、およびそれらと通信することを可能にする。したがって、これらの技法は、ひいては、ＷｉｒｅｌｅｓｓＨＡＲＴ通信ネットワーク、またはＩＰベースのネットワークルーティングをサポートまたは使用しない、あるいはＩＰアドレス指定をサポートしない他の通信ネットワークにわたって標準ＩＰベースの通信が起こることを可能にする。

【0083】

別の実施例では、ＱＲリーダ１１６が、ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴフィールドデバイス１０９に添着されたＱＲコード１１９から情報を読み取ってもよい。情報は、例えば、ＩＰベースの通信を使用してＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴフィールドデバイス１０９と通信するためのＩＰｖ６アドレスを含んでもよい。ＱＲリーダ１１６は、有線または無線ネットワークを介してインターネット１０１に通信可能に連結されてもよく、デバイス１１５に関して説明されるのと同様に、インターネット１０１を介して、ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴフィールドデバイス１０９へＩＰｖ６データフレームを伝送し、かつそこから受信するために、ＱＲコード１１９から読み取られた情報を利用してもよい。別の実施例では、バーコードリーダ１１７が、ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴフィールドデバイス１２０に添着されたバーコード１２０を読み取ってもよい。バーコードリーダ１１７は、インターネット１０１を介して、ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴフィールドデバイス１０９へＩＰｖ６データフレームを伝送し、かつそこから受信するために、バーコード１２０の中で符号化された情報を利用してもよい。当然ながら、ネットワーク１００内のＩＰｖ６使用可能フィールドデバイスと通信して、これらのデバイスから情報を取得する、および情報をこれらのデバイスへ送信する（コマンド、命令、データの要求等）ために、多くの他のタイプのアプリケーションが使用されてもよい。したがって、ある場合では、オペレータまたは技術者が、ＩＰベースのネットワークルーティングを使用しないＷｉｒｅｌｅｓｓＨＡＲＴまたは他のネットワーク内のフィールドデバイスから任意のタイプの情報を取得する、または任意の性質の情報をこれらのデバイスへ送信するよう、これらのデバイスと通信するようにインターネットに接続されたデバイス内のＩＰベースのアプリケーションを使用してもよい。

【0084】

図７は、一方で、ＩＰｖ６データフレームをインターネットから受信し、かつそこへ伝送するように、他方で、ＷｉｒｅｌｅｓｓＨＡＲＴネットワークを介してＩＰｖ６データパケットをルートするように、本明細書で説明される通信技法の部分を実装するために使用され得る、ネットワークプロトコルスタック例３００のブロック図である。この場合、通信プロトコルスタック３００は、例えば、図１のＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴゲートウェイ１１ａにおいて、あるいは図５のゲートウェイデバイス５４または７０のいずれか一方において、あるいは図６のゲートウェイデバイス１０２において、実装されてもよい。スタック３００を実装するデバイスは、汎用コンピュータであってもよく、または代替として、例えば、フィールドデバイス（プロセスコントローラであり得る）またはプロセス制御ネットワークと関連付けられる、特殊用途組み込みコンピュータデバイスであってもよい。通信プロトコルスタック３００を備える、いくつかの機能ブロックが、ソフトウェア命令、ハードウェア、ファームウェア、ＡＳＩＣ等を使用して実装されてもよい。ソフトウェア命令が使用される場合において、ソフトウェア命令は、ハードウェアマイクロプロセッサによって実行され得るいくつかのブロックを含んでもよく、これらのブロックは、ソフトウェアメッセージング待ち行列、ソフトウェアコールバック、メモリバッファ、バス等を介して、相互と通信可能に、かつプログラムで連結されてもよい。ソフトウェアブロックは、ＩＰｖ６データフレームを受信および伝送するために、タイマ、ハードウェア割り込み、高速イーサネットコントローラ、シリアル通信コントローラ等のいくつかのハードウェアリソースを使用してもよい。図７に示されていないが、通信プロトコルスタック３００は、リアルタイムオペレーティングシステム（ＲＴＯＳ）とプログラムで連動してもよい。ＲＴＯＳの実施例は、ＰＳＯＳ、ＵＣＯＳ、ＲＴＬｉｎｕｘ等を含む。上述のように、通信プロトコルスタック３００を構成する、いくつかの機能ブロックのうちのいくつかまたは全ては、特定用途向け集積回路（ＡＳＩＣ）において、またはそのように所望される場合はフィールドプログラマブルゲートアレイ（ＦＰＧＡ）デバイスあるいは他のハードウェア／ファームウェアデバイスにおいて実装されてもよい。

【0085】

図７のシステムでは、スタック３００は、概して、第１の分岐３０３および第２の分岐３０５を含む。第１の分岐は、概して、ＩＰネットワークルーティング準拠通信ネットワークを使用して、イーサネットインターフェース３０１を介して、ＩＰｖ６データフレーム等のＩＰデータフレームを受信および復号すること、または符号化および伝送することと関連付けられる。第２の分岐３０５は、概して、ＷｉｒｅｌｅｓｓＨＡＲＴアクセスポイント３１３を介して、ＷｉｒｅｌｅｓｓＨＡＲＴ通信ネットワーク等の非ＩＰネットワークルーティング準拠通信システム上で、ＩＰｖ６データパケットまたは他のタイプのパケットを受信および復号すること、または符号化および伝送することと関連付けられる。分岐３０３および３０５は、相互に、および概して、ＩＰｖ６データフレーム通信に依存する、またはそれを使用するスタックの上層（スタック３００のトランスポートおよび層等）に接続される。

【0086】

より具体的には、通信プロトコルスタック３００の第１の分岐３０３は、この場合、単一の物理的インターフェースを含み得る、イーサネットインターフェース３０１に接続するイーサネットドライバ３０２を含む。他の場合において、イーサネットインターフェース３０１は、２つ以上の物理的インターフェースを含んでもよい。ＩＰｖ４、ＩＰｖ６、およびＩＰｖ４カプセル化ＩＰｖ６データフレームは、イーサネットインターフェース３０１を介してインターネットから受信（進入）され、かつそこへ伝送（退出）されてもよく、したがって、物理層スタック要素および／またはデータリンク層スタック要素を実装する。この実施例では、イーサネットインターフェース３０１は、ＩＥＥＥ ８０２．３標準に従って動作するように適合される。しかしながら、イーサネットインターフェース３０１は、任意の他の数の同期、非同期、および／または等時シリアル通信標準に従って動作してもよく、イーサネットドライバ３０２はまた、必要に応じてイーサネットインターフェース３０１を構成してもよい。当然ながら、典型的であるように、イーサネットドライバ３０２は、イーサネットインターフェース３０１を介して受信されるデータフレームの完全性を受信して検証し、イーサネットドライバ３０２は、スタック３００が操作されるデバイスの中に位置する１つ以上のメモリバッファの中に受信したデータフレームを記憶してもよい。イーサネットドライバ３０２は、データフレームがイーサネットインターフェース３０１を介して受信されるとき、および／またはデータフレームがメモリバッファの中に記憶されるときに、ＩＰｖ４カプセル化／脱カプセル化ブロック３０４に警告してもよく、イーサネットドライバ３０２は、メモリバッファの中の受信したデータフレームの場所に対応する指示をＩＰｖ４カプセル化／脱カプセル化ブロック３０４に提供してもよい。イーサネットドライバ３０２はまた、イーサネットインターフェース３０１を介して、ＩＰｖ４脱カプセル化／カプセル化ブロック３０４から受信されるデータフレームを伝送してもよい。

【0087】

ＩＰｖ４カプセル化／脱カプセル化ブロック３０４は、イーサネットインターフェース３０１を介して受信されるデータフレームを処理するように動作する。ＩＰｖ４カプセル化／脱カプセル化ブロック３０４は、受信されるデータフレームがＩＰｖ４データフレーム、ＩＰｖ６データフレーム、またはＩＰｖ４カプセル化ＩＰｖ６データフレームであるかどうかを判定してもよい。所望であれば、ＩＰｖ４カプセル化／脱カプセル化ブロック３０４は、ＩＰｖ６データフレームを生成するように、ＩＰｖ４カプセル化ＩＰｖ６データフレームに作用してもよい。ＩＰｖ４カプセル化／脱カプセル化ブロック３０４はまた、受信したＩＰｖ４カプセル化ＩＰｖ６データフレームの脱カプセル化の完了中または後に、ＩＰＳｅｃ暗号化／解読ブロック３０６に警告してもよい。

【0088】

当然ながら、ＩＰｖ４カプセル化／脱カプセル化ブロック３０４はまた、ＩＰｓｅｃ暗号化／解読ブロック３０６からデータフレームを受信してもよく、ＩＰｖ４カプセル化／脱カプセル化ブロック３０４は、ＩＰｓｅｃ暗号化／解読ブロック３０６から受信されるデータフレームがＩＰｖ４データフレームまたはＩＰｖ６データフレームであるかどうかを判定してもよい。ＩＰｖ４カプセル化／脱カプセル化ブロック３０４は、ＩＰｓｅｃ暗号化／解読ブロック３０６から受信されるＩＰｖ６データフレームから、ＩＰｖ４カプセル化ＩＰｖ６データフレームを生成するように構成されてもよい。ＩＰｖ４カプセル化／脱カプセル化ブロック３０４は、ＩＰｓｅｃ暗号化／解読ブロック３０６から受信されるＩＰｖ４データフレームをカプセル化しないように動作してもよい。いずれにしても、ＩＰｖ４カプセル化／脱カプセル化ブロック３０４は、イーサネットドライバ３０２にＩＰｖ４カプセル化ＩＰｖ６データフレームまたはＩＰｖ４データフレームを提供する。以前に説明されたように、イーサネットドライバ３０２は、イーサネットインターフェース３０１を介して、ＩＰｖ４脱カプセル化／カプセル化ブロック３０４から受信されるデータフレームを伝送してもよい。純ＩＰｖ６ネットワークでは、ＩＰｖ４カプセル化／脱カプセル化ブロック３０４が必要とされなくてもよい。

【0089】

ＩＰＳｅｃ暗号化／解読ブロック３０６は、ＩＰｖ４カプセル化／脱カプセル化ブロック３０４から脱カプセル化ＩＰｖ６データフレームおよび／またはＩＰｖ４データフレームを受信する。そのようにすると、ＩＰｓｅｃ暗号化／解読ブロック３０６は、受信されるデータフレームが暗号化されているかどうかを判定する。必要であれば、ＩＰｓｅｃ暗号化／解読ブロック３０６は、１つ以上の暗号化／解読アルゴリズムを使用して、受信したデータフレームを解読してもよい。暗号化／解読アルゴリズムの一般的実施例の部分的リストは、データ暗号化標準（ＤＥＳ）、高度暗号化標準（ＡＥＳ）等を含む。暗号化／解読を行うために、ＩＰｓｅｃ暗号化／解読ブロック３０６は、暗号化／解読キーのプログラミングおよび交換を可能にするプロトコル（図示せず）を実装してもよい。終了したとき、ＩＰｓｅｃ暗号化／解読ブロック３０６は、データフレームルーティングブロック３０８に解読されたデータフレームを提供する。

【0090】

他方で、ＩＰｓｅｃ暗号化／解読ブロック３０６はまた、データフレームルーティングブロック３０８からデータフレームを受信し、好適な暗号化アルゴリズムを用いてデータフレームを暗号化するように構成される。この場合、ＩＰｓｅｃ暗号化／解読ブロック３０６は、イーサネットインターフェース３０１を介して伝送される、暗号化されたデータフレームまたは暗号化されていないデータフレームのいずれか一方を、ＩＰｖ４カプセル化／脱カプセル化ブロック３０４に提供する。

【0091】

概して、ネットワークルーティング層スタック要素を実装し得る、または含み得る、データフレームルーティングブロック３０８は、１つ以上のデータフレーム提供側からデータフレームを受信する。受信したデータフレームの中の情報に基づいて、データフレームルーティングブロック３０８は、受信したデータフレームをデータフレームの１つ以上の意図した受信側へ伝送し、その受信側は、スタック３００のアプリケーション層内のアプリケーション、またはイーサネット通信ネットワーク上にあり、スタック分岐３０３を介して到達可能なデバイス、あるいはＷｉｒｅｌｅｓｓＨＡＲＴネットワーク上にあり、スタック分岐３０５を介して到達可能なデバイスの中のアプリケーションのいずれか一方である。当然ながら、１つの場合におけるデータフレームの意図した受信側はまた、他の場合においてデータフレーム提供側として動作してもよい。一般的に言えば、図７のスタックの中の直近のデータフレーム提供側およびデータフレーム受信側は、ＩＰｓｅｃ暗号化／解読ブロック３０６、６ＬｏＷＰＡＮ適合層３１０、およびこの場合、ＴＣＰ、ＵＤＰ、またはＩＣＭＰトランスポートプロトコルを使用する、トランスポート層スタック３１１を含む。

【0092】

動作中、ＩＰｓｅｃ暗号化／解読ブロック３０６からデータフレームを受信すると、データフレームルーティングブロック３０８は、受信したデータフレームの意図した受信側デバイスのＩＰアドレスを判定するように、受信したデータフレームを調べる。データフレームルーティングブロック３０８は、データフレームの意図した受信側がＩＰ拡張ゲートウェイ自体であると判定してもよく、その場合、データフレームルーティングブロック３０８は、データフレームが利用可能であるという指示で、トランスポート層スタック３１１に警告してもよい。トランスポート層スタック３１１の詳細（所望であれば、スタック３００の中のネットワーク層スタック要素の一部であり得るか、またはそれを実装し得る）を、以降でさらに詳細に論議する。代替として、データフレームルーティングブロック３０８は、データフレームの意図した受信側デバイスが、無線アクセスポイント３１３を介してデータフレームルーティングブロック３０８が位置するＩＰ使用可能ゲートウェイデバイスに接続された、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク内に位置する１つ以上のＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴデバイスであると判定してもよい。この場合、データフレームルーティングブロック３０８は、データフレームを６ＬｏＷＰＡＮ適合層３１０に提供する。なおもさらに、データフレームルーティングブロック３０８は、データフレームの意図した受信側デバイスが、イーサネットインターフェース３０１を介して、データフレームルーティングブロック３０８が位置するＩＰ使用可能ゲートウェイデバイスに接続された、１つ以上のデバイスであると判定してもよい。この場合、データフレームルーティングブロック３０８は、データフレームをＩＰＳｅｃ暗号化／解読ブロック３０６に提供する。

【0093】

データフレームルーティングブロック３０８は、特定のデータフレームをルートする場所を判定する際にデータフレームルーティングブロック３０８を支援するように、１つまたはいくつかの「ルーティングテーブル」（ルーティングテーブル３０９として図７で図示される）を維持してもよい。概して、ルーティングテーブル３０９は、１つまたはいくつかのルート入力を含み、各ルート入力は、サブネットマスク、別のゲートウェイまたはルータのＩＰアドレス等を含んでもよい。ルーティングテーブル３０９の中の入力は、データフレームがインターネットに接続された意図した受信側デバイスに到達するために、データフレームが送信され得る、次のゲートウェイ／ルータのアドレスまたは場所を判定するように、データフレームルーティングブロック３０８によって利用されてもよい。ＩＰルーティングテーブル３０９の中でデータフレームルーティングブロック３０８によって維持されるルーティングテーブル入力は、構成可能であり得、ルーティングテーブル３０９は、インターネットから、または場合によってはＷｉｒｅｌｅｓｓＨＡＲＴネットワークを介して受信される、ルート入力を用いて更新されてもよい。

【0094】

データフレームルーティングブロック３０８はまた、６ＬｏＷＰＡＮ適合層３１０からＩＰｖ６データフレームを、および／またはＩＰ使用可能ゲートウェイのネットワーク層スタック３１１からＩＰｖ６データフレームを受信してもよい。データフレームルーティングブロック３０８は、受信したＩＰｖ６データフレームの意図した受信側デバイスのＩＰアドレスを判定してもよく、ルーティングテーブル３０９の中の情報に基づいて、データフレームルーティングブロック３０８は、ＩＰｖ６データフレームを適切なルート入力と関連付けてもよい。次いで、データフレームルーティングブロック３０８は、ＩＰｖ６データフレームを、関連ルート入力とともにＩＰｓｅｃ暗号化／解読ブロック３０６へ伝送してもよく、またはＩＰｖ６パケットのＩＰアドレスがＷｉｒｅｌｅｓｓＨＡＲＴネットワーク内のデバイスと関連付けられる場合、処理してＷｉｒｅｌｅｓｓＨＡＲＴネットワーク上で送信するためにＩＰｖ６データフレームを第２の分岐３０５へ送信してもよい。

【0095】

一般的に言えば、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク上でＩＰｖ６データパケットを送信するために、データフレームが、ＩＰ使用可能ゲートウェイデバイスが接続されるＷｉｒｅｌｅｓｓＨＡＲＴネットワーク内のデバイスへ、またはデバイスと関連付けられるＩＰアドレスへ送信される必要があることを、データフレームルーティングブロック３０８が判定するときに、６ＬｏＷＰＡＮ適合層３１０は、データフレームルーティングブロック３０８からＩＰｖ６データフレームを受信する。この場合、６ＬｏＷＰＡＮ適合層３１０は、データフレームルーティングブロック３０８から受信されるＩＰｖ６データフレームから、１つ以上の６ＬｏＷＰＡＮデータフレームを生成するように、データフレーム断片を行い、そうする際に、６ＬｏＷＰＡＮ適合層３１０は、生成された６ＬｏＷＰＡＮデータフレームのそれぞれを、ＩＰｖ６データフレームの意図した受信側のＩＰｖ６アドレスと関連付けてもよい。当然ながら、ＩＰｖ６データフレームの意図した受信側のＩＰｖ６アドレスは、ＩＰｖ６データフレーム自体から回収されてもよい。

【0096】

しかしながら、図７で図示されるように、６ＬｏＷＰＡＮ適合層３１０は、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク上にある、またはそれに接続されるデバイスへ送達されるように、スタック３００を実装するゲートウェイデバイス内のトランスポート層スタック要素３１１（少なくとも部分的に、ＩＰネットワーク用のネットワーク層スタック要素も実装し得る）から直接、ＩＰｖ６データフレームを受信してもよい。この場合、６ＬｏＷＰＡＮ適合層３１０は、トランスポート層スタック３１１から受信されるＩＰｖ６データフレームから、１つ以上の６ＬｏＷＰＡＮデータフレームを生成するように動作する。一般的に言えば、６ＬｏＷＰＡＮ適合層３１０が、データフレームルーティングブロック３０８から、および／またはスタック３１１から、ＩＰｖ６データフレームを受信するとき、６ＬｏＷＰＡＮ適合層３１０は、受信される各ＩＰｖ６データフレームに対する１つ以上の６ＬｏＷＰＡＮデータフレームを生成する。次いで、６ＬｏＷＰＡＮ適合層３１０は、分岐３０５において、１つ以上の６ＬｏＷＰＡＮデータフレームをＷｉｒｅｌｅｓｓＨＡＲＴネットワーク層３１５（ＷｉｒｅｌｅｓｓＨＡＲＴ通信ネットワーク用のネットワーク層スタック要素である）へ伝送する。この通信の一部として、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク層３１５は、６ＬｏＷＰＡＮ適合ブロック３１０によって作成される１つ以上の６ＬｏＷＰＡＮデータフレームの意図した受信側のＩＰｖ６アドレスを受信してもよく、またはＷｉｒｅｌｅｓｓＨＡＲＴネットワーク層３１５は、データフレーム自体からそのようなＩＰアドレスを判定してもよい。

【0097】

当然ながら、理解されるように、６ＬｏＷＰＡＮ適合層３１０はまた、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク層３１５から６ＬｏＷＰＡＮデータフレームを受信してもよい。この場合において、６ＬｏＷＰＡＮブロック３１０は、これらのデータフレームをデフラグすることによって、すなわち、ＩＰｖ６データフレームを生じるように種々の６ＬｏＷＰＡＮデータフレームまたは断片化データフレームからのデータペイロードを組み合わせることによって、受信した６ＬｏＷＰＡＮデータフレームから１つ以上のＩＰｖ６データフレームを生成するように動作する。この場合、６ＬｏＷＰＡＮブロック３１０は、生成されたＩＰｖ６データフレームをデータフレームルーティングブロック３０８へ、またはトランスポート層スタック３１１へ伝送してもよい。

【0098】

ここで、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク層３１５が６ＬｏＷＰＡＮブロック３１０から６ＬｏＷＰＡＮデータフレームを受信するとき、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク層３１５は、６ＬｏＷＰＡＮデータフレームの中にある、またはそれと関連付けられるＩＰアドレス（元のＩＰｖ６データフレームのＩＰアドレスであろう）を有するＷｉｒｅｌｅｓｓＨＡＲＴネットワーク内のデバイスの場所またはルーティング情報を判定するように、スタック３００の動作の一部として記憶または保持される、ＷｉｒｅｌｅｓｓＨＡＲＴルーティングまたはリンキングテーブル３１６にアクセスしてもよい。当然ながら、ＷｉｒｅｌｅｓｓＨＡＲＴルーティングまたはリンキングテーブル３１６は、いくつかのルーティングテーブル入力および各ルーティングを含んでもよく、またはリンキングテーブル入力は、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク上のＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴデバイスのＩＰｖ６アドレス、およびＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴデバイスのＷｉｒｅｌｅｓｓＨＡＲＴルーティング情報を含んでもよい。したがって、ルーティングまたはリンキングテーブル３１６は、ＷｉｒｅｌｅｓｓＨＡＲＴルーティングプロトコルを使用して、ＷｉｒｅｌｅｓｓＨＡＲＴ通信ネットワーク内のデバイスに到達することを可能にするように、これらのデバイスの特定のＩＰアドレス（すなわち、第１のネットワークルーティングプロトコルの中のルーティング情報）を、これらのデバイスのグラフＩＤ等のＷｉｒｅｌｅｓｓＨＡＲＴルーティング情報（すなわち、第２のネットワークルーティングプロトコルのルーティング情報）と結び付ける、情報を記憶する。この場合、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク層３１５は、ＷｉｒｅｌｅｓｓＨＡＲＴルーティングテーブル３１６からのＩＰｖ６アドレスを有するＷｉｒｅｌｅｓｓＨＡＲＴデバイスのＷｉｒｅｌｅｓｓＨＡＲＴルーティング情報を「調べる」ために、６ＬｏＷＰＡＮデータフレームのそれぞれと関連付けられるＩＰｖ６アドレスを利用してもよい。次いで、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク層３１５は、これらのデータパケット内でＩＰｖ６プロトコルのネットワークルーティング情報を維持しながら、データパケットをＷｉｒｅｌｅｓｓＨＡＲＴネットワーク内のデバイスへルートするために必要とされる、ＷｉｒｅｌｅｓｓＨＡＲＴネットワークルーティングプロトコルに対応するネットワークルーティング情報とともに、６ＬｏＷＰＡＮデータフレームのそれぞれをカプセル化してもよい。加えて、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク層３１５は、基礎的データパケットがＩＰｖ６データパケットである、またはＩＰｖ６データパケットに基づく（すなわち、ＩＰｖ６データパケットの６ＬｏＷＰＡＮ断片である）ことを指示するフラグを用いて、ＷｉｒｅｌｅｓｓＨＡＲＴネットワークルーティング情報を符号化してもよい。

【0099】

当然ながら、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク層３１５はまた、シリアルポートドライバ３１２からＷｉｒｅｌｅｓｓＨＡＲＴカプセル化６ＬｏＷＰＡＮデータフレームを受信してもよい。この場合、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク層３１５は、これらのデータパケットからＷｉｒｅｌｅｓｓＨＡＲＴネットワークルーティング情報を取り除き、生成された６ＬｏＷＰＡＮデータフレームを６ＬｏＷＰＡＮ適合層３１０に提供することによって、受信したＷｉｒｅｌｅｓｓＨＡＲＴカプセル化６ＬｏＷＰＡＮデータフレームから１つ以上の６ＬｏＷＰＡＮデータフレームを生成してもよい。

【0100】

シリアルドライバ３１２は、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク内で通信を提供するように、シリアル受信機／伝送機デバイス（図示せず）と連動してもよい（データリンク層スタック要素および物理層スタック要素を実装し得る）。一実施例では、シリアル受信機／伝送機デバイスが、ＲＳ−２３２プロトコルに従って動作してもよい一方で、他の別の実施例では、シリアル受信機／伝送機デバイスは、ＲＳ−４８５プロトコルに従って動作してもよい。本明細書に記載されるシリアルプロトコルは、実施例としての機能を果たすのみであり、一般に、任意の好適な有線または無線、直列または並列プロトコルが利用されてもよい。いずれにしても、シリアルドライバ３１２は、例えば、シリアル受信機／伝送機デバイスを介して、ＷｉｒｅｌｅｓｓＨＡＲＴカプセル化６ＬｏＷＰＡＮデータフレームを図６のアクセスポイント１０３および１０４等のＷｉｒｅｌｅｓｓＨＡＲＴアクセスポイント（ＡＰ）へ伝送する。当然ながら、シリアルドライバ３１２は、シリアル受信機／伝送機デバイスを介して、ＷｉｒｅｌｅｓｓＨＡＲＴアクセスポイント（ＡＰ）からＷｉｒｅｌｅｓｓＨＡＲＴカプセル化６ＬｏＷＰＡＮデータフレームを受信してもよい。

【0101】

以前に論議されたように、（例えば、ＩＰルーティングテーブル３０９を使用して）トランスポート層スタック３１１がＩＰｖ６データフレームの意図した受信側であることをデータフレームルーティングブロック３０８が判定するとき、データフレームルーティングブロック３０８は、データフレームがＴＣＰ、ＵＤＰ、またはＩＣＭＰデータフレームに対応するかどうかを判定するように、受信したデータフレーム（具体的には、そのデータフレームのヘッダ内のトランスポート情報）を調べてもよい。受信したデータフレームが、それぞれ、ＴＣＰ、ＵＤＰ、またはＩＣＭＰデータフレームに対応することを判定すると、データフレームルーティングブロック３０８は、パケットのＴＣＰブロック３１１−１、ＵＤＰブロック３１１−２、またはＩＣＭＰブロック３１１−３に警告し、パケットをスタック３１１のトランスポート層の適切な部分に提供してもよい。この場合、１つ以上の標準および／またはカスタムアプリケーションが、スタック３００が位置するデバイスのアプリケーション層３１４内に存在してもよく、これらの標準アプリケーションは、例えば、ファイル転送プロトコル（ＦＴＰ）、ＴＥＬＮＥＴ、ハイパーテキスト転送プロトコル（ＨＴＴＰ）、簡易ネットワーク管理プロトコル（ＳＮＭＰ）、動的ホスト制御プロトコル（ＤＨＣＰ）等を実装するものを含んでもよい。カスタムアプリケーションは、例えば、ＩＰ使用可能ゲートウェイの監視および構成を含む、特定のタスクを行うものを含んでもよい。アプリケーション層３１４の中に常駐するアプリケーションは、アプリケーションプログラミングフレームワークおよびインターフェース３１５によって提供されるソフトウェアフレームワーク内で実行してもよい。常駐アプリケーションは、ＴＣＰブロック３１１−１、ＵＤＰブロック３１１−２、またはＩＣＭＰブロック３１１−３からデータフレームを受信するために、アプリケーションプログラミングフレームワークおよびインターフェース層３１５の中に常駐するソフトウェアモジュールを利用してもよい。場合によっては、アプリケーションプログラミングフレームワークおよびインターフェース層３１５は、実行アプリケーションがデータフレームを受信、処理、および送信することを可能にするように、「ソケット」インターフェースを提供してもよい。加えて、常駐アプリケーションは、受信したデータフレームに応答して、データフレームを生成してもよい。常駐アプリケーションは、自律的に、または受信したデータフレームに応答して、データフレームを生成してもよく、常駐アプリケーションは、アプリケーションプログラミングフレームワークおよびインターフェース層３１５の中に常駐するソフトウェアモジュールを利用することによって、生成されたデータフレームを伝送してもよい。これらのモジュールは、ひいては、生成されたデータフレームを、ＴＣＰブロック３１１−１、ＵＤＰブロック３１１−２、またはＩＣＭＰブロック３１１−３のうちのいずれか１つに伝送してもよい。次いで、ＴＣＰブロック３１１−１、ＵＤＰブロック３１１−２、またはＩＣＭＰブロック３１１−３は、付加的な情報をデータフレームに付加し、イーサネットインターフェース３０１またはＷｉｒｅｌｅｓｓＨＡＲＴアクセスポイント３１３のいずれかを介して、何らかの他のデバイスへ送達するために、データフレームをデータフレームルーティングブロック３０８へ伝送してもよい。

【0102】

図８は、ＷｉｒｅｌｅｓｓＨＡＲＴ通信およびＩＰｖ６データフレーム（または任意の他のＩＰデータフレーム）を使用する通信を実装するように、例えば、図５のフィールドデバイス１０９等のＩＰ使用可能ＷｉｒｅｌｅｓｓＨＡＲＴフィールドデバイスにおいて実装され得る、別のネットワークプロトコルスタック例３２０のブロック図である。一般的に言えば、プロトコルスタック３２０は、ＷｉｒｅｌｅｓｓＨＡＲＴ通信プロトコルの物理層およびデータリンク層、ならびにスタック３２０の拡張ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク層を実装する、一般的な一組の下層３２１を有する。プロトコルスタック３２０はまた、２組の上層３２３および３２５も含み、一組の上層のそれぞれは、ＷｉｒｅｌｅｓｓＨＡＲＴ通信ネットワークプロトコル（３２３）またはＩＰ通信ネットワークプロトコル（３２５）のいずれか一方のトランスポートおよびアプリケーション層を実装することに関与する。ここで、一般的な一組の下層３２１は、ＷｉｒｅｌｅｓｓＨＡＲＴ通信ネットワークと関連付けられる８０２．１５．４プロトコル標準に準拠する通信チャネルを介してデータフレームを受信および伝送する、８０２．１５．４ＰＨＹブロック３２２を含むものとして図示される。通信チャネルは、例えば、図６のＷｉｒｅｌｅｓｓＨＡＲＴ通信ネットワーク１００内の通信チャネルに対応してもよい。８０２．１５．４ＰＨＹブロック３２２は、デジタル減衰器、シンセサイザ、アナログフィルタ、アナログ・デジタル変換器（ＡＤＣ）、およびデジタル・アナログ変換器等のハードウェアデバイス、ならびにＷｉｒｅｌｅｓｓＨＡＲＴ通信ネットワーク内の任意の他のデバイスと通信する。そうするために、８０２．１５．４ＰＨＹブロック３２２は、受信したデータフレームの完全性をフィルタにかけ、復調し、および検証するアルゴリズム、伝送前に８０２．１５．４プロトコル標準に準拠する形式にデータフレームを変換するアルゴリズム、および８０２．１５．４プロトコル標準に準拠するようにデータフレームの伝送をスケジュールに入れるアルゴリズムを実装する。一般的な場合のように、８０２．１５．４ＰＨＹブロック３２２は、ＷｉｒｅｌｅｓｓＨＡＲＴ媒体アクセス制御（ＭＡＣ）ブロック３２４に接続され、８０２．１５．４プロトコル標準に準拠するデータフレームが受信されるときに指示をブロック３２４に伝送する。８０２．１５．４ＰＨＹブロック３２２（物理層スタック要素または物理層要素である）はまた、データフレームが８０２．１５．４プロトコル標準に準拠する通信チャネルを介して伝送されるために利用可能であるときに、ＷｉｒｅｌｅｓｓＨＡＲＴ ＭＡＣブロック３２４から指示を受信し、そのような場合において、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク上で、そのデータフレームをＷｉｒｅｌｅｓｓＨＡＲＴネットワーク内の別のデバイスへ伝送するように、標準方式で動作する。

【0103】

一般に、ＷｉｒｅｌｅｓｓＨＡＲＴ ＭＡＣブロック３２４は、ＷｉｒｅｌｅｓｓＨＡＲＴデータリンク層プロトコルに従って受信したデータフレームのルーティングを実装するステップを行い、したがって、データリンク層スタック要素である。ＷｉｒｅｌｅｓｓＨＡＲＴ ＭＡＣブロック３２４は、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク内の受信したデータフレームの意図した受信側デバイスを判定するように、受信したデータフレームのＷｉｒｅｌｅｓｓＨＡＲＴデータリンク層プロトコルヘッダを調べてもよい。例えば、ＷｉｒｅｌｅｓｓＨＡＲＴ ＭＡＣブロック３２４は、受信したデータフレームの意図した受信側を判定するように、ＷｉｒｅｌｅｓｓＨＡＲＴデータリンク層プロトコルヘッダの中の宛先アドレスフィールドを利用してもよい。１つのシナリオでは、受信したデータフレームのＷｉｒｅｌｅｓｓＨＡＲＴプロトコルヘッダの中の宛先アドレスは、ＷｉｒｅｌｅｓｓＨＡＲＴ ＭＡＣブロック３２４を実装するフィールドデバイスのＷｉｒｅｌｅｓｓＨＡＲＴ ＭＡＣアドレスに対応してもよい。この場合、ＷｉｒｅｌｅｓｓＨＡＲＴ ＭＡＣブロック３２４は、このデータパケットの存在を示す指示を拡張ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク層３２６へ伝送してもよく、かつネットワーク層３２６の中で処理するためにパケットを転送してもよい。別のシナリオでは、ＷｉｒｅｌｅｓｓＨＡＲＴ ＭＡＣブロック３２４は、別のフィールドデバイスが受信したデータフレームの意図した受信側であることを判定してもよい。このシナリオでは、ＷｉｒｅｌｅｓｓＨＡＲＴ ＭＡＣブロック３２４は、８０２．１５．４ＰＨＹブロック３２２を介して、受信したデータフレームをデータフレームの意図した受信側へ伝送してもよい。

【0104】

ＷｉｒｅｌｅｓｓＨＡＲＴ ＭＡＣブロック３２４はまた、拡張ＷｉｒｅｌｅｓｓＨＡＲＴネットワークブロック３２６（ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク用のネットワーク層スタック要素である）からデータフレームを受信してもよい。理解されるように、ＷｉｒｅｌｅｓｓＨＡＲＴ ＭＡＣブロック３２４は、ＷｉｒｅｌｅｓｓＨＡＲＴデータリンクプロトコルヘッダとともに、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク上で送信されるデータフレームをカプセル化してもよい。ＷｉｒｅｌｅｓｓＨＡＲＴ ＭＡＣブロック３２４は、例えば、１つまたは複数の意図した受信側のデバイスの宛先アドレスに対応する情報を用いて、ＷｉｒｅｌｅｓｓＨＡＲＴデータリンクプロトコルヘッダを更新してもよい。以前に説明されたように、ＷｉｒｅｌｅｓｓＨＡＲＴ ＭＡＣブロック３２４は、データフレームが伝送されるために利用可能であることを８０２．１５．４ＰＨＹブロック３２２に指示してもよい。

【0105】

拡張ＷｉｒｅｌｅｓｓＨＡＲＴネットワークブロック３２６は、例えば、受信したデータフレームのＷｉｒｅｌｅｓｓＨＡＲＴプロトコルヘッダの中の宛先アドレスが、フィールドデバイスがデータフレームの意図した受信側であることを示すときに、ＷｉｒｅｌｅｓｓＨＡＲＴ ＭＡＣブロック３２４から指示を受信するように動作する。以前に説明されたように、伝送デバイス、例えば、図１のＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴゲートウェイ１１、またはＷｉｒｅｌｅｓｓＨＡＲＴネットワーク内の別のフィールドデバイスは、データフレームが基礎的ＩＰｖ６データパケットまたはデータフレームと関連付けられることを示すフラグを、ＩＰｖ６データフレーム断片をカプセル化するＷｉｒｅｌｅｓｓＨＡＲＴネットワークルーティングプロトコルヘッダの中に含んでもよい。拡張ＷｉｒｅｌｅｓｓＨＡＲＴネットワークブロック３２６は、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク層プロトコルヘッダの中のフラグまたは指示の検出に基づいて、受信したデータフレームがＩＰｖ６データフレーム断片であるかどうか、または代わりに、受信したデータフレームが標準ＷｉｒｅｌｅｓｓＨＡＲＴデータパケットであるかどうかを判定してもよい。パケットがＩＰｖ６パケットまたは断片を含有することを示すフラグを検出すると、拡張ＷｉｒｅｌｅｓｓＨＡＲＴネットワークブロック３２６は、ＩＰｖ６データフレーム断片を待ち行列にコピーしてもよく、かつ１つ以上のＩＰｖ６データフレーム断片が待ち行列にコピーされるという指示を、第２組の上層３２５内の６ＬｏＷＰＡＮブロック３２８に提供してもよい。

【0106】

加えて、動作中、拡張ＷｉｒｅｌｅｓｓＨＡＲＴネットワークブロック３２６は、ＷｉｒｅｌｅｓｓＨＡＲＴネットワークルーティングプロトコルを使用してＷｉｒｅｌｅｓｓＨＡＲＴネットワーク上で送信するために、６ＬｏＷＰＡＮブロック３２８からＩＰｖ６データフレーム断片を受信してもよい。そうするために、ＷｉｒｅｌｅｓｓＨＡＲＴネットワークブロック３２６は、これらのパケット内にＩＰネットワークルーティングプロトコル情報の全てを維持しながら、ＷｉｒｅｌｅｓｓＨＡＲＴネットワークルーティングプロトコルヘッダとともに受信したＩＰｖ６データフレームをカプセル化する。しかしながら、拡張ＷｉｒｅｌｅｓｓＨＡＲＴネットワークブロック３２６はまた、ＷｉｒｅｌｅｓｓＨＡＲＴデータパケット（またはネットワークルーティングプロトコルヘッダ）がＩＰｖ６データフレーム断片をカプセル化することを示すフラグまたは他の指示を、ＷｉｒｅｌｅｓｓＨＡＲＴネットワークルーティングプロトコルヘッダの中に設定する。

【0107】

一組のパケットが、ＩＰデータパケットと関連付けられるスタック３２５の第２組の上層へ送達されるとき、６ＬｏＷＰＡＮブロック３２８は、拡張ＷｉｒｅｌｅｓｓＨＡＲＴネットワークブロック３２６から受信される１つ以上のＩＰｖ６データフレーム断片を組み立て直してＩＰｖ６データフレームを生成するように動作する。６ＬｏＷＰＡＮブロック３２８は、６ＬｏＷＰＡＮブロック３２８がＩＰｖ６データフレームを生成するときに、指示をＩＰｖ６ネットワークルーティング層ブロックおよびトランスポート層プロトコルブロック３３０へ伝送してもよい。６ＬｏＷＰＡＮブロック３２８はまた、ＩＰｖ６ネットワークルーティング層ブロックおよびトランスポートプロトコルブロック３３０からＩＰｖ６データフレームを受信してもよく、この場合、６ＬｏＷＰＡＮブロック３２８は、６ＬｏＷＰＡＮ断片化技法を使用して、ＩＰｖ６データフレームを１つ以上のデータフレーム断片に断片化するように動作する。そうすると、６ＬｏＷＰＡＮブロック３２８は、パケットが伝送されるべきであるＷｉｒｅｌｅｓｓＨＡＲＴデバイスの指示とともに、指示を拡張ＷｉｒｅｌｅｓｓＨＡＲＴネットワークブロック３２６へ伝送し、および／またはＷｉｒｅｌｅｓｓＨＡＲＴネットワークルーティングプロトコルを使用してＷｉｒｅｌｅｓｓＨＡＲＴ通信ネットワーク上で送信するために、ネットワークブロック３２６に生成されたデータフレーム断片を提供する。多くの場合において、この指示は、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク内のゲートウェイデバイスへのものであってもよい。いずれにしても、６ＬｏＷＰＡＮブロック３２８の構造および機能要素は、図９を参照してさらに詳細に論議される。

【0108】

また、スタック３２５の第２組の上層内で、ＩＰｖ６ネットワークルーティング層ブロックおよびトランスポートプロトコルブロック３３０は、ネットワークルーティング層スタック要素、ならびにＩＰベースのネットワークルーティングプロトコル活動およびトランスポート層プロトコル処理を行うトランスポート層スタック要素を実装し、６ＬｏＷＰＡＮブロック３２８によって提供されるＩＰｖ６データフレームを復号するか、またはアプリケーションプログラミングインターフェース（ＡＰＩ）３３２を介してアプリケーションブロック３３４によって提供されるＩＰｖ６データフレームを符号化するかのいずれかである、ＵＤＰ、ＴＣＰ、またはＩＣＭＰトランスポートブロックのうちのいずれかまたは全てを含んでもよい。アプリケーションプログラミングインターフェースの実施例は、ソケットインターフェースを含む。当然ながら、ブロック３３０はまた、ＩＰｖ６データパケットの中のネットワークルーティング情報の符号化および復号等のネットワークルーティング層活動も行う。別個に、アプリケーションブロック３３４の中で実行するアプリケーションは、アプリケーションプログラミングインターフェース３３２を介して、フィールドデバイス特有の情報３３６にアクセスし、それを制御し、および構成してもよい。アプリケーションブロック３３４（ＩＰまたはソケットベースのアプリケーション層スタック要素であるか、またはそれを実装する）の中で実行するアプリケーションは、制約アプリケーションプロトコル（ＣｏＡＰ）に準拠してもよい。ＣｏＡＰプロトコルの詳細は、ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｄｒａｆｔ−ｉｅｔｆ−ｃｏｒｅ−ｃｏａｐ−０３というウェブＵＲＬで入手可能である。

【0109】

実施例として、アプリケーションブロック３３４で実行するアプリケーションは、ＷｉｒｅｌｅｓｓＨＡＲＴ通信ネットワーク１００を介して、遠隔コンピュータデバイス、例えば、図６のデバイス１１６から、フィールドデバイス状態情報の要求を受信してもよい。アプリケーションは、アプリケーションプログラミングインターフェース３３２を介してフィールドデバイス状態情報を回収し、コンピュータデバイス１１６へ送達されるように、ＩＰｖ６トランスポートプロトコルブロック３３０、６ＬｏＷＰＡＮブロック３２８、およびスタックの一般的な一組の下層３２１を介して、１つ以上のＩＰｖ６データフレームとして状態情報を伝送してもよい。図６を参照して以前に説明されたように、ＩＰｖ６データフレームは、ＷｉｒｅｌｅｓｓＨＡＲＴ通信ネットワーク１００を介してコンピュータデバイス１１６へ伝送されてもよい。

【0110】

以前に論議されたように、拡張ＷｉｒｅｌｅｓｓＨＡＲＴネットワークブロック３２６は、ＷｉｒｅｌｅｓｓＨＡＲＴ ＭＡＣブロック３２４から受信される着信データパケットを処理し、そのデータパケットのネットワークルーティング情報内のフラグの存在を検出することによって、ＷｉｒｅｌｅｓｓＨＡＲＴネットワークルーティングプロトコルヘッダによってカプセル化されたデータフレームがＩＰｖ６データフレーム断片に対応することを判定してもよい。しかしながら、受信したデータフレームをカプセル化するＷｉｒｅｌｅｓｓＨＡＲＴプロトコルヘッダがフラグを含まない（またはフラグが基礎的ＩＰｖ６データパケットを示すように設定されていない）場合において、拡張ＷｉｒｅｌｅｓｓＨＡＲＴネットワークブロック３２６は、標準ＷｉｒｅｌｅｓｓＨＡＲＴデータパケットの存在の指示を、スタック３２３の第１組の上層内のＷｉｒｅｌｅｓｓＨＡＲＴトランスポートブロック３３８へ伝送する。次いで、ＷｉｒｅｌｅｓｓＨＡＲＴトランスポート層スタック要素を実装するＷｉｒｅｌｅｓｓＨＡＲＴトランスポートブロック３３８は、このデータパケットにアクセスし、標準ＷｉｒｅｌｅｓｓＨＡＲＴトランスポート層処理を使用してデータパケットを処理し、受信したデータフレームを処理した後に指示をＨＡＲＴアプリケーションブロック３４０（ＷｉｒｅｌｅｓｓＨＡＲＴアプリケーション層スタック要素であるか、またはそれを実装する）へ伝送してもよい。次いで、アプリケーションブロック３４０は、任意の公知または所望の方式でデータパケットを処理するように、ＷｉｒｅｌｅｓｓＨＡＲＴ準拠アプリケーションを実装する。

【0111】

理解されるように、拡張ＷｉｒｅｌｅｓｓＨＡＲＴネットワークブロック３２６は、ＷｉｒｅｌｅｓｓＨＡＲＴトランスポートブロック３３８から、ＷｉｒｅｌｅｓｓＨＡＲＴネットワークを介して伝送するためのＷｉｒｅｌｅｓｓＨＡＲＴデータフレームを受信してもよい。前述のように、ＷｉｒｅｌｅｓｓＨＡＲＴネットワークブロック３２６は、ＷｉｒｅｌｅｓｓＨＡＲＴネットワークプロトコルヘッダとともに、受信したＷｉｒｅｌｅｓｓＨＡＲＴデータフレームをカプセル化するように動作してもよい。しかしながら、この場合、データフレームがＷｉｒｅｌｅｓｓＨＡＲＴトランスポートブロック３３８から受信され、したがって、標準ＷｉｒｅｌｅｓｓＨＡＲＴデータパケットであるため、拡張ＷｉｒｅｌｅｓｓＨＡＲＴネットワークブロック３２６は、ＩＰｖ６データフレーム断片としてＷｉｒｅｌｅｓｓＨＡＲＴトランスポートブロック３３８から受信されるデータフレームにフラグを付けない。この動作の結果として、ＷｉｒｅｌｅｓｓＨＡＲＴネットワークブロック３２６は、ＷｉｒｅｌｅｓｓＨＡＲＴ通信ネットワーク上でＷｉｒｅｌｅｓｓＨＡＲＴパケットを送信するように、公知のＷｉｒｅｌｅｓｓＨＡＲＴネットワークルーティングプロトコルプロシージャに従ってＷｉｒｅｌｅｓｓＨＡＲＴパケットを処理する。

【0112】

前述のように、図７のアプリケーション層３１４の中に常駐するアプリケーション、および図８のアプリケーションブロック３３４は、ＡＰＩを利用することによって動作するように適合されてもよい。ＡＰＩにおける機能性の起動を含むプログラミング情報が、ソフトウェア開発キット（ＳＤＫ）の形態で、フィールドデバイスベンダによって入手可能にされてもよい。動作中、第三者ソフトウェア開発者が、ＣＤ−ＲＯＭ等の有形で非一過性の媒体を介してＳＤＫを受容してもよい。開発者は、ＳＤＫを利用することによって、汎用コンピュータ上でカスタムアプリケーションを作成してもよい。そのようなカスタムアプリケーションは、そのように所望される場合、インターネットおよびＷｉｒｅｌｅｓｓＨＡＲＴネットワークを介してフィールドデバイスに「プッシュ配信」されてもよい。代替として、ベンダは、オンラインアプリケーションストアでそのようなカスタムアプリケーションを「ホスト」してもよい。プラントオペレータは、インターネットおよびＷｉｒｅｌｅｓｓＨＡＲＴネットワークを介して、オンラインアプリケーションストアから、カスタムアプリケーションをフィールドデバイスへ選択的に「引き出し」てもよい。

【0113】

図９は、それぞれ、受信した６ＬｏＷＰＡＮデータフレームからＩＰｖ６データフレームを、および受信したＩＰｖ６データフレームから６ＬｏＷＰＡＮデータフレームを生成し得る、６ＬｏＷＰＡＮブロック例３５０のブロック図である。６ＬｏＷＰＡＮブロック３５０は、図７の６ＬｏＷＰＡＮ適合層３１０に対応してもよく、その場合、６ＬｏＷＰＡＮブロック３５０は、インターフェース３６０を介してデータフレームルーティングブロック３０８（図７）と通信してもよい。６ＬｏＷＰＡＮブロック３５０はまた、インターフェース３６１を介して、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク層３１５（図７）と通信してもよい。別の実施例では、６ＬｏＷＰＡＮブロック３５０は、図８の６ＬｏＷＰＡＮブロック３２８に対応してもよい。この実施例では、６ＬｏＷＰＡＮブロック３５０は、図８のＩＰｖ６トランスポートプロトコルブロック３３０からＩＰｖ６データフレームを受信し、かつそこから伝送してもよく、６ＬｏＷＰＡＮブロック３５０は、図８の拡張ＷｉｒｅｌｅｓｓＨＡＲＴネットワークブロック３２６からＩＰｖ６データフレーム断片を受信し、かつそこから伝送してもよい。

【0114】

図９で図示されるように、６ＬｏＷＰＡＮブロック３５０は、断片化モジュール３５３に通信可能に連結されるヘッダ圧縮モジュール３５１と、ヘッダ解凍モジュール３５２に通信可能に連結される再組立モジュール３５４とを含んでもよい。ここで、ヘッダ圧縮モジュール３５１は、インターフェース３６０−１を介してＩＰｖ６データフレームを受信してもよく、かつ６ＬｏＷＰＡＮ準拠圧縮ＩＰｖ６ヘッダを生成するように受信したＩＰｖ６データフレームに作用してもよい。ヘッダ圧縮モジュール３５１に連結される断片化モジュール３５３は、ヘッダ圧縮モジュール３５１から、圧縮ＩＰｖ６ヘッダを含むＩＰｖ６データフレームを受信し、ＩＰｖ６データフレームをいくつかの６ＬｏＷＰＡＮ準拠データフレームに「断片化」するように動作する。断片化モジュール３５３は、「断片ヘッダ」をいくつかの６ＬｏＷＰＡＮデータフレームのそれぞれに付加してもよい。断片化モジュール例３５３は、図１０Ａを参照して以下で説明される。断片ヘッダは、いくつかの６ＬｏＷＰＡＮデータフレームを元のＩＰｖ６データフレームへ組み立て直すことを可能にする情報を含んでもよい。当然ながら、再組立は、ＩＰｖ６データフレームの意図した受信側であるデバイスにおいて、または中間デバイスにおいて行われてもよい。６ＬｏＷＰＡＮプロトコルに従った、圧縮ＩＰｖ６ヘッダの生成およびＩＰｖ６データフレームの断片化に関する情報は、ＲＦＣ ４９４４， “Ｔｒａｎｓｍｉｓｓｉｏｎ ｏｆ ＩＰｖ６ Ｐａｃｋｅｔｓ ｏｖｅｒ ＩＥＥＥ ８０２．１５．４ Ｎｅｔｗｏｒｋｓ”で、より具体的に説明されている。

【0115】

図９の断片化モジュール３５３は、例えば、インターフェース３６１−１を介して、ＩＰｖ６データフレームから生成されるいくつかの６ＬｏＷＰＡＮ準拠データフレームをＷｉｒｅｌｅｓｓＨＡＲＴネットワーク層３１５へ伝送してもよい。このプロセスの一部として、断片化モジュール３５３は、いくつかの６ＬｏＷＰＡＮ準拠データフレームの意図した受信側のＩＰｖ６アドレスをＷｉｒｅｌｅｓｓＨＡＲＴネットワーク層３１５に提供してもよい。以前に説明されたように、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク層３１５は、いくつかの６ＬｏＷＰＡＮデータフレームの意図した受信側であるＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴデバイスのＷｉｒｅｌｅｓｓＨＡＲＴルーティング情報を、ＷｉｒｅｌｅｓｓＨＡＲＴルーティングテーブル３１６（図７）から「参照する」ために、ＩＰｖ６アドレスを利用してもよい。当然ながら、そのような参照テーブルは、本明細書で説明される他のＩＰ使用可能ＷｉｒｅｌｅｓｓＨＡＲＴデバイスのうちのいずれかの中に存在してもよい。

【0116】

別個に、図９の６ＬｏＷＰＡＮブロック３５０は、例えば、インターフェース３６１−２を介して、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク層３１５から６ＬｏＷＰＡＮデータフレーム断片を受信してもよい。６ＬｏＷＰＡＮデータフレーム自体は、ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴデバイスによってＩＰｖ６フレームから生成されてもよい。次いで、再組立モジュール３５４が、受信した６ＬｏＷＰＡＮデータフレームからＩＰｖ６データフレームを生成してもよい。受信した６ＬｏＷＰＡＮデータフレーム断片のそれぞれは、典型的には、断片ヘッダを含み、再組立モジュール３５４は、任意の公知の方式でＩＰｖ６データフレームを組み立て直すために断片ヘッダを利用するであろう。再組立モジュール例３５４が、図１０Ｂを参照して以下で説明される。再組立モジュール３５４は、（データパケットのＩＰアドレス等のＩＰネットワークルーティングプロトコル情報とともに）元のＩＰｖ６ヘッダを作成するように圧縮ＩＰｖ６ヘッダを「解凍」するヘッダ解凍モジュール３５２へ、組み立て直されたＩＰｖ６データフレームを伝送してもよい。次いで、ヘッダ解凍モジュール３５２は、インターフェース３６０−２を介して、ＩＰｖ６データフレームを、例えば、図７のデータフレームルーティングブロック３０８へ伝送する。

【0117】

図１０Ａは、６ＬｏＷＰＡＮブロック３５０において実装され得る、断片化モジュール例５００を描写する。この場合、待ち行列５０１が、ヘッダ圧縮モジュール３５１から１つ以上のＩＰｖ６データフレームを受信してもよく、フラグメンタ５０２が、１つ以上のＩＰｖ６データフレームが待ち行列５０１の中で受信されるときに指示を受信してもよい。フラグメンタ５０２は、標準６ＬｏＷＰＡＮ断片化技法を使用して、待ち行列５０１から回収される１つ以上のＩＰｖ６データを断片化してもよく、かつ送信バッファ５０３の中に断片を記憶してもよい。ここで、一組の断片５０３−１、５０３−２、および５０３−３のそれぞれは、６ＬｏＷＰＡＮデータフレームからの異なる断片に対応し、これらの断片のサイズ（長さ）は、他の予期されたＷｉｒｅｌｅｓｓＨＡＲＴネットワークルーティング、データリンク、および物理層情報がそれに追加された後に、各断片が、ＷｉｒｅｌｅｓｓＨＡＲＴプロトコル内のデータパケットの最大許容サイズ内に収まるであろうということを確実にするように選択されてもよい。以前に論議されたように、フラグメンタ５０２は、断片ヘッダをいくつかの６ＬｏＷＰＡＮデータフレーム５０３−１、５０３−２、５０３−３等のそれぞれに付加してもよい。所望であれば、６ＬｏＷＰＡＮデータフレーム５０３−１．．．５０３−３が送信バッファ５０３の中に記憶される前に、断片ヘッダが、６ＬｏＷＰＡＮデータフレーム５０３−１．．．５０３−３のそれぞれに付加されてもよい。送信バッファ５０３は単一の連続バッファとして描写されているが、他の実施形態では、送信バッファ５０３は、いくつかの不連続バッファを含んでもよい。

【0118】

フラグメンタ５０２はまた、そのそれぞれが送信バッファ５０３の中の場所を参照する、いくつかのポインタ５０４−１．．．５０４−３を含み得る、送信バッファマップ５０４を含んでもよい。これらのポインタのそれぞれは、６ＬｏＷＰＡＮデータフレームの開始を示してもよい。所望であれば、各ポインタはまた、対応する６ＬｏＷＰＡＮデータフレームの状態を示し得る、状態ブロックと関連付けられてもよい。フラグメンタ５０２は、送信バッファマップ５０４に基づいて送信バッファ５０３にアクセスしてもよく、かつ６ＬｏＷＰＡＮデータフレーム５０３−１．．．５０３−２のそれぞれをアウトバウンド待ち行列５０５に転送してもよい。この場合、フラグメンタ５０２は、６ＬｏＷＰＡＮデータフレーム５０３−１．．．５０３−２のそれぞれがアウトバウンド待ち行列５０５に転送された後に指示をＷｉｒｅｌｅｓｓＨＡＲＴネットワーク層３１５へ伝送してもよく、以前に論議されたように、フラグメンタ５０２は、６ＬｏＷＰＡＮデータフレーム５０３−１．．．５０３−３等の意図した受信側のＩＰアドレスをＷｉｒｅｌｅｓｓＨＡＲＴネットワーク層３１５に提供してもよい。

【0119】

図１０Ｂは、例えば、６ＬｏＷＰＡＮ適合モジュール３５０において実装され得る、再組立モジュール例５２０を描写する。ここで、再組立モジュール５２０は、１つ以上の６ＬｏＷＰＡＮデータフレームがインバウンド待ち行列５２１の中で受信されるときに、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク層（例えば、ネットワーク層３１５）から指示を受信するリアセンブラ５２２を含む。リアセンブラ５２２は、インバウンド待ち行列５２１から受信バッファ５２３の中へ６ＬｏＷＰＡＮデータフレームのそれぞれを転送してもよい。次いで、リアセンブラ５２２は、標準または周知の６ＬｏＷＰＡＮ再組立技法を使用してＩＰｖ６データフレームを生成するように作成されるときに、６ＬｏＷＰＡＮデータフレームのそれぞれに付加された断片ヘッダを利用してもよい。リアセンブラ５２２は、特定のＩＰｖ６データフレームを構成する６ＬｏＷＰＡＮデータフレームのそれぞれの受信を追跡するために、受信側バッファマップ５２４を利用してもよい。１つのシナリオでは、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク層３１５は、順番に反して６ＬｏＷＰＡＮデータフレームを受信してもよく、リアセンブラ５２２は、データフレーム断片を含むデータパケットの全てがインバウンド待ち行列５２１の中で受信されて記憶されたときに、ＩＰｖ６データフレームを依然として組み立て直してもよい。

【0120】

図１１Ａは、ＩＰデータフレームとしてインターネットを介して受信され、低出力断片化技法を使用して、ＷｉｒｅｌｅｓｓＨＡＲＴネットワークルーティングプロトコル等の第２のネットワークルーティングプロトコルを介して伝送され得る、データフレーム例５５０の説明図を描写する。例証の目的で、データフレーム５５０は、ＩＰｖ６データフレームであってもよく、インターネットを介してＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴゲートウェイにおいて受信されると仮定される。図１１Ａで見られるように、データフレーム５５０は、遠隔コンピュータデバイスによって生成され得るアプリケーションペイロードデータ５５０−１、ならびにＩＰデータパケット作成およびルーティングの通常動作に従ってそこに付加される、種々の他のヘッダおよびトレーラを含む。

【0121】

好適なプロトコルが、ＩＰｖ６データフレーム５５０を１つ以上のデータフレーム断片５５２−１．．．５５２−ｎに断片化するために利用されてもよい。この実施例では、ＩＰｖ６データフレーム５５０は、６ＬｏＷＰＡＮプロトコルに準拠する方法を使用して断片化されてもよいが、他の断片化技法が代わりに使用されてもよい。各データフレーム断片は、データフレーム断片５５２−１が断片ヘッダ情報５５３−１とともにカプセル化されるものとして例証されるように、６ＬｏＷＰＡＮ断片ヘッダ情報５５３とともにカプセル化されてもよい。データフレーム断片ヘッダ情報が、断片ヘッダ、圧縮ＩＰプロトコルヘッダ、および（ＩＰトランスポートプロトコル用の）圧縮トランスポートプロトコルヘッダを含むものとして例証される一方で、各データフレーム断片のペイロードは、元のＩＰｖ６データパケットのアプリケーションペイロード５５０−１の一部分である。

【0122】

理解されるように、データフレーム断片５５２−１等の各データフレーム断片は、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク等の低出力ネットワーク内でデータフレーム断片５５２−１のルーティングを可能にするように、好適な第２のネットワークルーティングプロトコルヘッダとともにカプセル化される。この実施例では、データフレーム５５２−１は、ＷｉｒｅｌｅｓｓＨＡＲＴカプセル化ＩＰｖ６データフレーム断片５５４を生成するようにＷｉｒｅｌｅｓｓＨＡＲＴプロトコルヘッダとともにカプセル化されてもよい。ＷｉｒｅｌｅｓｓＨＡＲＴプロトコルヘッダは、ＷｉｒｅｌｅｓｓＨＡＲＴネットワークルーティングヘッダ５５４−１と、ＷｉｒｅｌｅｓｓＨＡＲＴデータリンク層ヘッダ５５４−２とを備える。ＷｉｒｅｌｅｓｓＨＡＲＴカプセル化ＩＰｖ６データフレーム断片５５４はさらに、ＷｉｒｅｌｅｓｓＨＡＲＴ通信ネットワークを介して伝送される前に、低出力通信標準、例えば、８０２．１５．４標準に準拠する、物理的ヘッダ５５４−３および物理的トレーラ５５４−４とともにカプセル化されてもよい。

【0123】

ＷｉｒｅｌｅｓｓＨＡＲＴプロトコルに対応するデータフィールドの中の１つまたはいくつかのビットは、データフレーム断片がＩＰｖ６データフレームに対応することを受信デバイスに示すように割り振られてもよい。図１１Ｂは、ＨＡＲＴネットワークルーティングヘッダ５５４−１のＤＬＰＤＵフィールド５６０を図示する。この実施例では、ＷｉｒｅｌｅｓｓＨＡＲＴヘッダがＩＰｖ６データフレーム断片をカプセル化することを受信デバイスに示すために、ビット７（参照番号５６１によって示される）がフラグとして利用される。ビット７（５６１）は、ＷｉｒｅｌｅｓｓＨＡＲＴデータフレームがＷｉｒｅｌｅｓｓＨＡＲＴデータフレーム内のＩＰｖ６データフレーム断片の存在を示すように伝送される前に、「１」に設定されてもよい。図７および８を参照すると、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク層３１５および拡張ＷｉｒｅｌｅｓｓＨＡＲＴネットワークブロック３２６は、データフレームが伝送される前に、ＷｉｒｅｌｅｓｓＨＡＲＴネットワークルーティングプロトコルヘッダのＤＬＰＤＵフィールド５６０のビット７（５６１）を論理「１」に設定してもよい。

【0124】

図１１Ｃは、ＷｉｒｅｌｅｓｓＨＡＲＴネットワークルーティングヘッダ５５４−１の制御バイト５６５に対応し、制御バイト５６５の中のデータフィールドも、または代わりに、ＷｉｒｅｌｅｓｓＨＡＲＴプロトコルヘッダが暗号化された通信チャネルを介して受信されるデータフレーム断片をカプセル化するかどうかを示すように割り振られてもよい。例えば、データフレーム断片が暗号化されたＷｉｒｅｌｅｓｓＨＡＲＴ通信チャネルを介して受信されるかどうかを示すために、ビット４（参照番号５６６で示される）が利用されてもよい。この実施例では、ビット５（５６７）が、データフレーム断片内のセキュリティヘッダの場所を示すために利用される。

【0125】

以下の表１は、ＷｉｒｅｌｅｓｓＨＡＲＴネットワークルーティング情報内で暗号化およびセキュリティを提供するために使用され得る、制御バイトのビット４（５６６）およびビット５（５６７）の一組の可能な組み合わせを示す。

【表1】

【0126】

ビット４およびビット５の設定は、ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴゲートウェイにおいて、およびＷｉｒｅｌｅｓｓＨＡＲＴネットワーク内のフィールドデバイスの中で構成されてもよい。表１を参照すると、ビット４が論理「０」であるように構成される場合において、ＷｉｒｅｌｅｓｓＨＡＲＴ通信ネットワーク内で動作するフィールドデバイスは、データフレームを受信および伝送するために安全なＩＰ通信を利用してもよい。代替として、フィールドデバイスは、安全でない通信チャネルを介して通信してもよい。安全なＩＰ通信チャネルが利用される場合において、アプリケーションは、安全な通信を実施することに関与し得る。

【0127】

ビット４（５６６）が論理「１」に構成され、ビット５（５６７）が論理「１」に構成される場合において、ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴゲートウェイは、ＷｉｒｅｌｅｓｓＨＡＲＴネットワークヘッダ５５４−１の後にセキュリティヘッダを挿入するように、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク層において方法を実装してもよい。これらの場合において、ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴは、安全なＩＰ通信チャネルを介してインターネットからＩＰｖ６データフレームを受信してもよいが、ＩＰｖ６データフレーム断片は、ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴゲートウェイにおいて断片化される前に解読されてもよい。

【0128】

ビット４（５６６）が論理「１」に構成され、ビット５（５６７）が論理「０」に構成される場合において、ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴゲートウェイは、６ＬｏＷＰＡＮデータフレーム断片ヘッダ５５４−５の後にセキュリティヘッダを挿入するように、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク層において方法を実装してもよい。受信フィールドデバイスが、ＩＰｖ６データフレーム断片を受信および伝送するときに、適切なセキュリティ機構を実施するようにビット４およびビット５を解釈するであろう。

【0129】

図８を参照して論議されたように、拡張ＷｉｒｅｌｅｓｓＨＡＲＴネットワークブロック３２６は、受信したデータフレームのビット７（５６１）が設定されていない（０）ことを判定してもよい。この場合、拡張ＷｉｒｅｌｅｓｓＨＡＲＴネットワークブロック３２６は、標準ＷｉｒｅｌｅｓｓＨＡＲＴ通信を使用して、処理するために指示を着信データフレームのＷｉｒｅｌｅｓｓＨＡＲＴトランスポートブロック３３８へ伝送する。データフレーム５５４は、例えば、どのＷｉｒｅｌｅｓｓＨＡＲＴプロトコルまたはＷｉｒｅｌｅｓｓＨＡＲＴアプリケーションにデータフレーム５５４アプリケーションペイロードが対応するかを判定するために、ＷｉｒｅｌｅｓｓＨＡＲＴトランスポートブロック３３８および／またはＨＡＲＴアプリケーションブロック３４０によって利用される情報を含み得る、ＷｉｒｅｌｅｓｓＨＡＲＴプロトコル指標フィールドを含んでもよい。

【0130】

図６のネットワーク例を再び参照すると、ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴフィールドデバイス１０８は、受信したＩＰｖ６データフレーム断片の意図した受信側が、他のＩＰｖ６使用可能フィールドデバイスである状況で、ＷｉｒｅｌｅｓｓＨＡＲＴ通信ネットワーク１００を介して、ＷｉｒｅｌｅｓｓＨＡＲＴプロトコルカプセル化ＩＰｖ６データフレーム断片を受信してもよい。ＩＰｖ６使用可能フィールドデバイス１０８はまた、受信したＩＰｖ６データフレーム断片の意図した受信側が他のＩＰｖ６使用可能フィールドデバイスである状況で、ＷｉｒｅｌｅｓｓＨＡＲＴ通信ネットワーク１００を介して、ＷｉｒｅｌｅｓｓＨＡＲＴプロトコルカプセル化非ＩＰｖ６データフレームを受信してもよい。ここで、ＷｉｒｅｌｅｓｓＨＡＲＴ通信ネットワーク内でＩＰｖ６データフレーム断片をルートするようにＷｉｒｅｌｅｓｓＨＡＲＴフィールドデバイスにおいて実装され得るいくつかの方法を、さらに詳細に論議する。理解されるように、ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴフィールドデバイス、場合によっては、非ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴフィールドデバイスは、ＷｉｒｅｌｅｓｓＨＡＲＴ通信ネットワーク内でＩＰｖ６データフレーム断片および標準ＷｉｒｅｌｅｓｓＨＡＲＴデータフレームをルートするために、以下で論議されるいくつかの方法のうちのいずれか１つを利用するように構成されてもよい。場合によっては、以下で論議される先述の方法は、２つの他のＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴフィールドデバイスの間でＩＰｖ６データフレーム断片をルートするために、単一の中間ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴデバイスまたは単一の中間非ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴデバイスを使用するが、いくつかの中間ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴデバイスまたは非ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴデバイスが、ＷｉｒｅｌｅｓｓＨＡＲＴ通信ネットワーク内でＩＰｖ６データフレームの「マルチホップ」ルーティングを可能にするために、以下で論議される方法で中間デバイスとして使用されてもよい。

【0131】

図１２は、ＷｉｒｅｌｅｓｓＨＡＲＴ通信ネットワーク例６００内のＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴフィールドデバイスにおいて実装され得る、ルーティング方法例の説明図を描写する。ネットワーク６００内の種々の異なるＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴフィールドデバイスのネットワーク通信スタック６０１、６０２、および６０３はそれぞれ、別個のＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴフィールドデバイスにおいて実装される。理解されるように、スタック６０１、６０２、および６０３は、図８のスタック３２０の記述と同一または同様であり得、概して、それに従って動作してもよい。この場合、ネットワーク通信スタック６０２は、中間ＷｉｒｅｌｅｓｓＨＡＲＴフィールドデバイスにおいて実装され、ネットワーク通信スタック６０１および６０３を実装するフィールドデバイス間で、ＷｉｒｅｌｅｓｓＨＡＲＴデータフレームおよびＷｉｒｅｌｅｓｓＨＡＲＴデータフレームの中にカプセル化されたＩＰｖ６データフレーム断片の両方をルートするように動作する。理解されるように、ＩＰｖ６データフレーム断片は、ＩＰｖ６データフレーム断片のそれぞれ１つをカプセル化するＷｉｒｅｌｅｓｓＨＡＲＴプロトコルヘッダに含まれる情報（ネットワークルーティング情報、データリンク層情報、および物理層プロトコル情報を含む）に基づいて、通信ネットワーク６００上でルートされる。

【0132】

１つのシナリオ例では、スタック６０１内のＨＡＲＴアプリケーションブロック６０１−１の中で実行するアプリケーションは、スタック６０３を実装するデバイスのＨＡＲＴアプリケーションブロック６０３−１の中で実行するアプリケーションに意図されたＷｉｒｅｌｅｓｓＨＡＲＴデータフレームを生成する。アプリケーションブロック６０１−１は、ＷｉｒｅｌｅｓｓＨＡＲＴネットワークルーティング情報をデータパケットに追加し、ネットワーク６００上での処理およびルーティングのために、このデータパケットをＷｉｒｅｌｅｓｓＨＡＲＴ ＭＡＣ（データリンク）層６０１−６および物理層６０１−７へ送信することによって、データパケットを処理する拡張ＷｉｒｅｌｅｓｓＨＡＲＴネットワークブロック６０１−２へ送達するために、そのデータフレームをＷｉｒｅｌｅｓｓＨＡＲＴトランスポートブロック６０１−３に提供する。別のシナリオ例では、アプリケーションブロック６０１−４の中で実行するアプリケーションが、スタック６０３を実装するデバイスのアプリケーションブロック６０３−４の中で実行するＩＰｖ６アプリケーションに意図されたＩＰｖ６データフレームを生成する。図８を参照して以前に説明されたように、スタック６０１のＩＰトランスポート層の中の６ＬｏＷＰＡＮブロック６０１−５は、アプリケーションブロック６０１−４の中で実行するアプリケーションから受信されるＩＰｖ６データフレームを断片化する。この場合、拡張ＷｉｒｅｌｅｓｓＨＡＲＴネットワークブロック６０１−２は、スタック６０１−２、６０１−６、および６０１−７の下層を使用して、上記で説明されるように、ＷｉｒｅｌｅｓｓＨＡＲＴプロトコルヘッダともに、（アプリケーションブロック６０１−４および６ＬｏＷＰＡＮブロック６０１−５からの）ＩＰｖ６データフレーム断片のそれぞれをカプセル化する。当然ながら、拡張ＷｉｒｅｌｅｓｓＨＡＲＴネットワークブロック６０１−２は、ＷｉｒｅｌｅｓｓＨＡＲＴ通信ネットワークを介してデータフレームを伝送する前に、ネットワーク通信スタック６０３を実装するＷｉｒｅｌｅｓｓＨＡＲＴフィールドデバイスの論理アドレス、またはそこへのルートに対応するルーティング情報を用いて、それぞれのそのようなデータフレームに対応するＷｉｒｅｌｅｓｓＨＡＲＴプロトコルヘッダを更新する。この情報は、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク内のデバイスのＩＰアドレスを、これらのデバイスに到達するためのＷｉｒｅｌｅｓｓＨＡＲＴルーティング情報に関係付ける、ルーティングテーブル（図１２では示されていない）の中に記憶されてもよい。拡張ＷｉｒｅｌｅｓｓＨＡＲＴネットワークブロック６０１−２はまた、伝送前に、ＷｉｒｅｌｅｓｓＨＡＲＴプロトコルヘッダがＩＰｖ６データフレーム断片をカプセル化することを示すフラグを用いて、ＩＰｖ６データフレーム断片に対応するデータフレームのＷｉｒｅｌｅｓｓＨＡＲＴプロトコルヘッダを符号化する。

【0133】

ネットワーク上で送信された後、通信スタック６０２を実装するＩＰｖ６使用可能フィールドデバイスは、いくつかのＷｉｒｅｌｅｓｓＨＡＲＴ符号化ＩＰｖ６データフレーム断片またはＷｉｒｅｌｅｓｓＨＡＲＴパケットを受信し、スタック６０２の物理層６０２−７、データリンク層６０２−６、およびネットワーク層６０２−２の部分の中で、これらのパケットを処理する。両方の場合において、各データパケット（ＷｉｒｅｌｅｓｓＨＡＲＴデータパケットまたはＷｉｒｅｌｅｓｓＨＡＲＴプロトコルヘッダとともにカプセル化されたＩＰｖ６データフレーム断片のいずれか一方）のＷｉｒｅｌｅｓｓＨＡＲＴネットワークルーティング情報は、パケットがＷｉｒｅｌｅｓｓＨＡＲＴネットワーク６００内で別のデバイスへ送信されるものであることを示すであろう。通信スタック６０２の下層６０２−７、６０２−６、および６０２−２は、パケットを、次のＷｉｒｅｌｅｓｓＨＡＲＴデバイス、この場合はスタック６０３を実装するデバイスへ送信する前に、このパケットの中の適切なＷｉｒｅｌｅｓｓＨＡＲＴネットワークルーティング、データリンク、および物理層情報を復号および再符号化するように、標準ＷｉｒｅｌｅｓｓＨＡＲＴネットワークルーティングおよびデータリンクおよび物理リンクアドレス指定を使用して、パケットを処理する。理解されるように、データパケット（ＷｉｒｅｌｅｓｓＨＡＲＴデータパケットまたはＷｉｒｅｌｅｓｓＨＡＲＴネットワークルーティング情報とともにカプセル化されるＩＰｖ６データパケット）が、スタック６０２を実装するデバイス内のアプリケーションにアドレス指定されないため、各データパケットは、このデバイスを通してルートされるように、スタック６０２のＷｉｒｅｌｅｓｓＨＡＲＴネットワークブロック６０２−２まで処理される必要しかない。したがって、この場合、拡張ＷｉｒｅｌｅｓｓＨＡＲＴネットワークブロック６０２−２は、（ＷｉｒｅｌｅｓｓＨＡＲＴネットワークおよびデータリンクルーティングプロトコルを使用して）ネットワークおよびデータリンク層ルーティングを行って、受信したデータフレーム断片またはＷｉｒｅｌｅｓｓＨＡＲＴパケットを、通信スタック６０３を実装するＩＰｖ６使用可能フィールドデバイスへ送信するために、受信したデータフレーム断片のそれぞれをカプセル化するＷｉｒｅｌｅｓｓＨＡＲＴプロトコルヘッダの中、またはＷｉｒｅｌｅｓｓＨＡＲＴパケットの中の情報を利用する。経路６１０は、ＩＰｖ６および非ＩＰｖ６データフレームの両方が横断し得る、例証的なルートに対応し、点線は、標準ＷｉｒｅｌｅｓｓＨＡＲＴパケットまたはＩＰｖ６符号化パケットがスタック６０１、６０２、６０３内で横断する、異なる経路を示す。

【0134】

当然ながら、メッセージまたはデータパケットがスタック６０３を実装するデバイスにおいて受信されるとき、メッセージは、図８に関して上記で説明されるように拡張ＷｉｒｅｌｅｓｓＨＡＲＴネットワークブロック６０３−２まで処理される。この場合、パケットは、最終的に、データパケットのネットワークルーティング情報を介して、スタック６０３を実装するデバイスの中のアプリケーションにアドレス指定されるため、ネットワークブロック６０３−２は、復号および処理のために、復号されたパケットをＷｉｒｅｌｅｓｓＨＡＲＴトランスポートブロック６０３−３（パケットがＷｉｒｅｌｅｓｓＨＡＲＴパケットまたはデータフレームであるとき）またはＩＰトランスポート層６０３−５（パケットが断片化ＩＰｖ６データフレームを含有する）のいずれかに提供する。当然ながら、後者の場合、ＩＰネットワークルーティング情報は、受信側アプリケーションのＩＰアドレスを使用および判定することができ、それにより、スタック６０３のアプリケーション層６０３−４の中の正しいアプリケーションへ送達するために、ＩＰｖ６データフレームを適切なソケットへ送達するように、ブロック６０３−５において維持される。

【0135】

図１３は、ＷｉｒｅｌｅｓｓＨＡＲＴ通信ネットワーク例６００内のＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴフィールドデバイスにおいて実装され得る、別のルーティング方法例を図示する。この通信方法は、１つの違い以外、図１２に関して説明されるものと非常に類似する。この方法では、（スタック６０２を実装する）中間ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴフィールドデバイスは、ＷｉｒｅｌｅｓｓＨＡＲＴプロトコルヘッダの中に含まれる情報を利用することによって非ＩＰｖ６データフレーム断片をルートするが、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク６００上で再断片化ＩＰｖ６データフレーム断片を返送する前に、ＩＰｖ６データフレーム断片を組み立て直して再断片化する。この技法は、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク上でデータフレームまたはメッセージをルートするかどうか、またはどのようにしてルートするかを判定するためにＩＰアドレスを使用する必要があり得る、あるいはＩＰｖ６データパケット内のＩＰネットワークルーティング情報の中のデータを使用するＩＰベースのセキュリティ技法を実装し得る、ルータまたはゲートウェイ等のＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴデバイスにおいて必要とされてもよい。

【0136】

ルート線６６０によって図１３で図示されるように、スタック６０１を実装するＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴデバイスは、ネットワーク６００上で送信されるＷｉｒｅｌｅｓｓＨＡＲＴパケットおよび／またはＩＰｖ６データパケットを作成し、これらのパケットは、通信ネットワーク６００上に配置されるように、上記で説明されるようにスタック６０１の中で処理される。通信スタック６０２を実装する中間ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴフィールドデバイスは、標準ＷｉｒｅｌｅｓｓＨＡＲＴルーティング技法を介して、ＩＰｖ６データフレーム断片および非ＩＰｖ６データフレーム（例えば、ＷｉｒｅｌｅｓｓＨＡＲＴデータフレーム）を受信する。受信したパケットは、上記で説明されるように、下スタック層６０２−７、６０２−６、および６０２−２の中で処理される。しかしながら、ここで、ＷｉｒｅｌｅｓｓＨＡＲＴネットワークブロック６０２−２は、データフレームがＩＰｖ６データフレーム断片であることを示す、ＷｉｒｅｌｅｓｓＨＡＲＴプロトコルヘッダの中のフラグの存在を検出するように動作し、そのようなフラグが検出されたとき、拡張ＷｉｒｅｌｅｓｓＨＡＲＴネットワークブロック６０２−２は、ＩＰｖ６データフレーム断片を６ＬｏＷＰＡＮブロック６０２−５へルートする。次いで、拡張ＷｉｒｅｌｅｓｓＨＡＲＴネットワークブロック６０２−５は、例えば、これらのパケットをデフラグし、次いで、標準ＩＰルーティングに必要とされ得るようなＩＰアドレスおよびセキュリティ情報を取得するように、これらのパケットからＩＰｖ６ネットワーク層情報を読み取ることによって、データフレーム断片からＩＰｖ６ネットワーク層情報を復号する。このアクションは、ブロック６０２−５を通る経路６６０の点線部分によって示される。ここで、６ＬｏＷＰＡＮブロック６０２−５は、ＩＰｖ６データフレームを再生するように、６ＬｏＷＰＡＮ断片ヘッダの中の情報を利用して、いくつかのＩＰｖ６データフレーム断片を組み立て直す。次いで、６ＬｏＷＰＡＮブロック６０２−５は、生成されたＩＰｖ６データフレームのＩＰヘッダの中の宛先ＩＰアドレス情報および／またはセキュリティ情報を復号して利用し、セキュリティ処理を行ってもよい。加えて、ブロック６０２−５は、通信スタック６０３を実装するＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴフィールドデバイス、すなわち、ＩＰｖ６アドレス指定を使用してＩＰｖ６データフレームがアドレス指定されるデバイスに対応する、ＷｉｒｅｌｅｓｓＨＡＲＴアドレス情報を調べてもよい。次いで、６ＬｏＷＰＡＮブロック６５２−２は、ＷｉｒｅｌｅｓｓＨＡＲＴ通信ネットワーク６００を介してデータフレームが送信されるべきであるＷｉｒｅｌｅｓｓＨＡＲＴデバイスに関する情報とともに、拡張ＷｉｒｅｌｅｓｓＨＡＲＴネットワークブロック６０２−２を介してＩＰｖ６データフレーム断片を返送する前に、生成されたＩＰｖ６データフレームをいくつかのＩＰｖ６データフレーム断片に断片化してもよい。次いで、拡張ＷｉｒｅｌｅｓｓＨＡＲＴネットワークブロック６０２−２は、ＷｉｒｅｌｅｓｓＨＡＲＴネットワークルーティング情報をこれらのフレームに追加し、ＷｉｒｅｌｅｓｓＨＡＲＴ通信ネットワーク６００上でのルーティングのためにスタック６０２の下位レベル６０２−６および６０２−７において処理するために、これらのフレームを送信する。

【0137】

スタック６０３を実装する受信デバイスにおいて、データパケットは、上記で説明されるように処理され、データフレームのタイプに基づいて、適切なアプリケーション層あるいはブロック６０３−１または６０３−４に提供される。当然ながら、スタック６０２を実装する１つだけの中間デバイスが、図１３で図示されるが、１つよりも多くの中間デバイスが、経路６６０内に位置することができ、それぞれのそのような中間デバイスが、スタック６０２に関して上記で説明される処理を行うことができる。

【0138】

図１４は、ＷｉｒｅｌｅｓｓＨＡＲＴ通信ネットワーク上でＷｉｒｅｌｅｓｓＨＡＲＴデータパケットおよびＩＰｖ６データパケットの両方をルートするか、または送達するために使用することができる、さらに別のルーティングまたは通信方法を図示する。図１４の実施例では、ルーティングは、図１２に関して上記で説明されるのと同様に行われる。しかしながら、この場合、中間デバイスのうちの１つ以上は、非ＩＰ使用可能フィールドデバイスであってもよいため、ＩＰベースのネットワークスタックのネットワーク、トランスポート、およびアプリケーション層を含まない。しかしながら、図１４で図示されるように、各データパケットが、再符号化され、ルートの中の次のデバイスへ送信される前に、ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク層ブロック６０２−２までしか処理されないため、これらの中間デバイスを通して、ＩＰベースのデータフレームおよびＷｉｒｅｌｅｓｓＨＡＲＴデータフレームの両方を依然としてルートすることができる。つまり、この場合、ＷｉｒｅｌｅｓｓＨＡＲＴネットワークの中の中間デバイスを通したルーティングは、ＷｉｒｅｌｅｓｓＨＡＲＴネットワークルーティングプロトコル情報のみを使用して起こることができるため、これらのデバイスは、ＩＰｖ６使用可能である必要がない。結果として、スタック６０２の中のネットワーク層ブロック６０２−２は、基礎的ＩＰｖ６データパケットの存在を認識するか、またはこれらのタイプのデータパケットの存在を示すフラグをＷｉｒｅｌｅｓｓＨＡＲＴネットワークルーティング層情報の中へ符号化する必要がないため、このブロックは、「拡張」ＷｉｒｅｌｅｓｓＨＡＲＴネットワーク層である必要がない。

【0139】

例えば、図７および８を参照して以前に論議されたように、アプリケーション層３１４およびアプリケーションブロック３３４は、ＷｉｒｅｌｅｓｓＨＡＲＴ通信ネットワークを介して、生成されたＩＰｖ６データフレームを受信および伝送するために、アプリケーションプログラミングフレームワークおよびインターフェース３１５ならびにアプリケーションプログラミングインターフェース３３２を利用し得る、カスタムアプリケーションを含んでもよい。図６のＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴフィールドデバイス１０７、１０８、１０９、および１１０のベンダは、例えば、いくつかのシナリオでは、第三者アプリケーション開発者がカスタムアプリケーションを作成して配布することを可能にするように、ソフトウェア開発キット（ＳＤＫ）を作成してもよい。そのようなＳＤＫは、例えば、ＣＤ−ＲＯＭを介して提供されてもよく、またはインターネットを介してサーバ（図示せず）からダウンロードされてもよい。

【0140】

図１５は、開発者が、例えば、ＩＰｖ６データフレームを受信および伝送するために、図７のアプリケーションプログラミングインターフェース３１５を利用し得る、フィールドデバイス特有のカスタムアプリケーションを開発することを可能にする、汎用コンピュータ７０１上にインストールされ得る、ＳＤＫ例７００のブロック図を提供する。ＷｉｒｅｌｅｓｓＨＡＲＴ通信ネットワーク７１６内で動作するＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴフィールドデバイス７１５上で実行されたとき、カスタムアプリケーションは、例えば、ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴフィールドデバイス７１５から、フィールドデバイス特有の構成および状態情報を回収し、別のコンピュータデバイス（例えば、デバイス７０１）へのゲートウェイ７２０を介して、ＩＰｖ６データフレームの中のこの情報をインターネット７１７へ伝送するように構成されてもよい。

【0141】

ＳＤＫ例７００は、図６で参照されるＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴフィールドデバイス１０７、１０８、１０９、および１１０、ならびに、例えば、ベンダによって製造されるＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴフィールドデバイス７１５のうちのいくつかまたは全てのモデルの情報を記憶し得る、フィールドデバイスデータベース７０２を含んでもよい。当然ながら、フィールドデバイスデータベース７０２は、ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴフィールドデバイスのより新しいモデルを用いて、周期的に更新されてもよい。ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴフィールドデバイスの特定のモデルの情報は、サポートされたアプリケーションプログラミングインターフェース、ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴフィールドデバイスの特定のモデルの中に存在するマイクロプロセッサ群を示すプロセッサ識別子等を含んでもよい。

【0142】

フィールドデバイスプロセッサツール連鎖データベース７０４は、実行可能なカスタムアプリケーションを生成するために利用され得る、コンパイラおよびリンカを含んでもよい。当業者であれば、各マイクロプロセッサ群が、ソフトウェアコードをコンパイルして実行可能なカスタムアプリケーションを生成するために各自の一意的なツール連鎖を必要とし得ることを認識するであろう。

【0143】

本明細書で説明されるいくつかのデータベースは、汎用コンピュータ７０１のローカルにあってもよく、または代替として、インターネット７１７に接続された別のコンピュータデバイスに位置し、または「マップ」されてもよい。グラフィカルユーザインターフェース（ＧＵＩ）モジュール７０６は、第三者ソフトウェア開発者（プログラマ）がＳＤＫ７００と相互作用することを可能にしてもよい。当然ながら、ＧＵＩ７０６は、例えば、キーボードおよびマウス７１８を介して、プログラマ入力を受信してもよい。また、ＧＵＩ７０６は、例えば、表示モニタ７１９を介して、ウィンドウベースのソフトウェアインターフェースを提供してもよい。プログラマは、フィールドデバイスセレクタ７０７を介して、例えば、フィールドデバイスデータベース７０２から、ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴフィールドデバイス７１５の特定のモデルを選択するように、ＳＤＫ７００と相互作用してもよい。フィールドデバイスセレクタ７０７は、例えば、ＧＵＩ７０６において、ドロップダウンメニューとして表されてもよい。

【0144】

構築エンジン７０８は、プログラマがフィールドデバイスセレクタ７０７を介してＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴフィールドデバイスを選択するときに、フィールドデバイスプロセッサツール連鎖データベース７０４から適切なツール連鎖を自動的に選択するために使用されてもよい。当然ながら、選択されるツール連鎖は、例えば、ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴフィールドデバイス７１５の選択されたモデルの中に存在するマイクロプロセッサに対応するであろう。

【0145】

ＧＵＩ７０６は、プログラマがコードエディタモジュール７１０にソフトウェアアプリケーション（ソースコード）を書き込むことを可能にする。プログラマは、ソフトウェアアプリケーションをコンパイルし、例えば、ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴフィールドデバイス７１５のモデルのアプリケーションブロック３３４の中で実行され得るカスタムアプリケーションを生成するように、構築エンジン７０８に命令してもよい。構築エンジン７０８は、以前に選択されたツール連鎖を利用するであろう。

【0146】

次いで、プログラマは、フィールドデバイスエミュレータ７１２を介して、実行可能なカスタムアプリケーションを有効にし、試験してもよい。フィールドデバイスエミュレータ７１２は、例えば、ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴフィールドデバイス７１５の選択されたモデルの中に存在するアプリケーションプログラミングインターフェース３３４を含む、ソフトウェア環境を提供してもよい。

【0147】

実行可能なカスタムアプリケーションおよび対応するソースコードは、そのように所望される場合、アプリケーションデータベース７１４の中に記憶されてもよい。プラントオペレータが、所望されるときに、インターネット７１７を介して、実行可能なカスタムアプリケーションをデバイス７１５等のＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴフィールドデバイスにダウンロードしてもよい。カスタムアプリケーションは、例えば、ＩＰｖ６使用可能ＷｉｒｅｌｅｓｓＨＡＲＴフィールドデバイス７１５のアプリケーションブロック３３４において実行し、ブロック３３６においてデバイス特有の機能と相互作用するためにＡＰＩ３３２を利用してもよい。同様に、カスタムアプリケーションは、ＡＰＩ３３２に含まれる機能性および本明細書で説明される技法を利用することによって、ＷｉｒｅｌｅｓｓＨＡＲＴ通信ネットワーク７１７を介して、インターネット７１７からＩＰｖ６データフレームを受信し、かつそこへ伝送してもよい。

【0148】

上述のように、上記の通信方法例および／またはこれらの方法を実装するための装置のうちの少なくともいくつかは、コンピュータプロセッサ上で作動する１つ以上のソフトウェアおよび／またはファームウェアプログラムによって実装されてもよい。しかしながら、全体的または部分的のいずれかで、本明細書で説明される方法および／または装置例のうちのいくつかまたは全てを実装するように、特定用途向け集積回路、プログラマブルロジックアレイ、および他のハードウェアデバイスを含むが、それらに限定されない、専用ハードウェア実装を、同様に構築することができる。さらに、分散処理またはコンポーネント／オブジェクト分散処理、並列処理、または仮想マシン処理を含むが、それらに限定されない、代替的なソフトウェア実装もまた、本明細書で説明される方法および／またはシステム例を実装するように構築することができる。

【0149】

また、本明細書で説明されるソフトウェアおよび／またはファームウェア実装例は、磁気媒体（例えば、磁気ディスクまたはテープ）、光ディスク等の磁気光学または光学媒体、あるいはメモリカードまたは１つ以上の読取専用（不揮発性）メモリを収納する他のパッケージ、ランダムアクセスメモリ、または他の書換可能（揮発性）メモリ等のソリッドステート媒体等の、有形コンピュータ可読記憶媒体上に記憶されることにも留意されたい。したがって、本明細書で説明されるソフトウェアおよび／またはファームウェア例は、上記で説明されるもの等の有形記憶媒体または後続記憶媒体上に記憶することができる。上記の明細書が、特定の標準およびプロトコルを参照して構成要素および機能例を説明する限りでは、本特許の範囲は、そのような標準およびプロトコルに限定されないことが理解される。例えば、インターネットおよび他のパケット交換ネットワーク伝送のための標準のそれぞれ（例えば、伝送制御プロトコル（ＴＣＰ）／インターネットプロトコル（ＩＰ）、ユーザデータグラムプロトコル（ＵＤＰ）／ＩＰ、ハイパーテキストマークアップ言語（ＨＴＭＬ）、ハイパーテキスト転送プロトコル（ＨＴＴＰ））、ＩＰｖ４、ＩＰｖ６、ＷｉｒｅｌｅｓｓＨＡＲＴ等は、現在の最先端技術の実施例を表す。そのような標準は、周期的に、同一の一般機能性を有する、より速い、またはより効率的な同等物に取って代わられる。したがって、同一の機能を有する代替標準およびプロトコルは、本特許によって考慮される同等物であり、添付請求項の範囲内に含まれることを目的としている。

【0150】

加えて、本特許は、ハードウェア上で実行されるソフトウェアまたはファームウェアを含む、方法および装置例を開示するが、そのようなシステムは、例証的にすぎず、限定的と見なされるべきではないことに留意されたい。例えば、これらのハードウェアおよびソフトウェア構成要素のうちのいずれかまたは全てを、独占的にハードウェアで、独占的にソフトウェアで、独占的にファームウェアで、あるいはハードウェア、ファームウェア、および／またはソフトウェアの何らかの組み合わせで、具現化できることが考慮される。したがって、上記の明細書は、方法、システム、および／または機械がアクセス可能な媒体例を説明するが、実施例は、そのようなシステム、方法、および機械がアクセス可能な媒体を実装する唯一の方法ではない。したがって、ある方法、システム、および／または機械がアクセス可能な媒体例が本明細書で説明されているが、本特許の対象範囲は、それらに限定されない。

【図1】

【図2A】

【図2B】

【図3】

【図4A】

【図4B】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10A】

【図10B】

【図11A】

【図11B】

【図11C】

【図12】

【図13】

【図14】

【図15】