JP2007527160A - 拡張ｅＭＦＣを用いたアドホックメッシュネットワークのための高信頼メッセージ配信方法 - Google Patents

Abstract

データ配信サービスDDSはアドホックモバイルメッシュネットワーク（１２）内のノード（１４）間で情報を転送する。DDSは、トラフィックを最小限にするために再送信要求を合体させる技術をはじめとして、多くの異なる新規な特徴を含んでおり、イベント指向通信の信頼性を適切なレベルにすることができ、多くのノード（１４）によって使用される再送信をマルチキャストすることができ、マルチキャストトラフィックのためのその他の最適化を行うことができる。拡張マルチキャスト転送キャッシュ（eMFC）は、モバイルメッシュネットワーク（１２）におけるマルチキャスト伝送をサポートしており、DDSと組み合わせて用いることができる。拡張MFCは、メッシュネットワークに特有のメッシュノード移動性、サービス品質、およびセキュリティ要求をサポートするように設計されている。これらの目的を達成するために、拡張MFCは、ユニキャストルーティングプロトコル、マルチキャストアウェアアプリケーション、および配信DDSおよびeMFCサービスによって保持されるグローバル状態から引き出す。eMFCは、eMFC固有のマルチキャストパケットヘッダを用いてこの得られたグローバル状態を配信する。
【選択図】図１

Description

本出願は、２００４年２月９日に提出された米国仮特許出願６０／５４３，３５２および２００４年２月９日に提出された米国仮特許出願６０／５４３，３５３に基づく優先権を主張するものである。

図１は、多数のホップ、リンク、ノード１４等を介してノードＢと通信するノードＡを有する典型的なメッシュネットワーク１２を示している。リンク１４は、無線モデム、ネットワークルータ、スイッチ、携帯情報端末（PDA）、携帯電話、またはメッシュネットワーク１２内で通信可能なその他の種類の移動処理装置を含み得るポータブルコンピュータのような有線または無線移動通信装置の任意の組み合わせとすることができる。

メッシュネットワーク１２内のすべてのネットワークノード１４は、インターネットプロトコル（IP）を用いて互いにメッセージを送信することにより通信を行う。それぞれのメッセージは、１以上のマルチキャストユーザデータグラムプロトコル（UDP）パケットからなる。それぞれのノード１４は、同一のマルチキャストグループの一部となり得るメンバである１以上のネットワークインタフェイスを含んでいる。それぞれのノードは、メッセージのソースと一群の指定受信者の双方を特定するために用いられる対応ノードIDを有している。メッセージはマルチキャストされるため、ルーティングの詳細はアプリケーションには見えない。

固定通信の信頼性を得るためには、直接肯定応答（ACK）ベースの設計を用いた伝送制御プロトコル（TCP）が一般に使用されるが、多数のピアを有するマルチキャストシナリオにおいては、否定応答（NACK）ベースの設計がより効率的なアプローチである。すなわち、データがうまく伝送されたときには、その事実を肯定するために付加的な通信が必要とされず、受領通知がない。パケットロスが検知されると、ソースにNACKが返送され、再伝送を要求する。連続パケットの欠落や不足を検出するために連続番号が使用される。本発明はこのようなNACKベースの設計によるものである。

メッシュネットワークにおいては、異なるノード１４間で所定のデータ整合性を維持する必要がある。例えば、どの装置が同一のマルチキャストグループの一部をなしているのかをすべてのノード１４が把握している必要がある場合がある。これは、ノード１４のすべてが同一のバージョンの異なるマルチキャストテーブルを有していることを要求する。これは、典型的には、ノード１４間でデータを交換した後、データがうまく受信できなかった場合にNACK応答とともに返信を行うことにより行われる。異なるノード１４間でデータ整合性を維持するためには、相当量の帯域幅と処理資源が必要となる。異なるモバイルノード間でデータ整合性を維持するための現在の技術は非効率である。

近代インターネットにおけるコンピュータは、よく知られたルーティングメカニズムに基づいて共通の言語を用いて通信を行っている。インターネットにおけるルータは、すべての既知のコンピュータへの最適経路を算出し、そのようなトラフィックを管理する入出力ユニットの役割を果たす。これらの計算の結果は、転送テーブルとして知られているものの中に格納される。この転送テーブルは、考えられる宛先のそれぞれに対して次のホップを特定するものである。次のホップは、特定の宛先アドレスに対するトラフィックの転送先にしなければならないコンピュータである。

宛先がルータに知られていないときにトラフィックの転送先としての好ましいルータとしてデフォルトルータが指定されることがしばしばある。また、ホストとして知られる、ルータではないコンピュータも転送テーブルを有している。典型的には、ホストは１つのインタフェイスによりインターネットに接続され、指定されたデフォルトルータは多くのアドレスを扱うので、従来のインターネットにおいては、ホストの転送テーブルはルータの転送テーブルよりも非常に簡単なものである傾向がある。これらの前提は、モバイルメッシュネットワークにおけるホストに対しては当てはまらない。図１２および１３は、ノードＡがユニキャスト転送を行う場合のネットワークトポロジを示している。表１は、図１２および１３に示された４ノードネットワークトポロジー用のユニキャスト転送テーブルを示している。

インターネットアドレスは、インターネットプロトコルバージョン４（IPv4）で特定される３２ビット整数アドレスまたはインターネットプロトコルバージョン６（IPv6）で特定される１２８ビットのアドレスである。www.packethop.comのような人間が読めるアドレスは、ディレクトリネームサーバ（DNS）によってその等価な整数に変換される。これらのアドレスは一般にユニキャストアドレスとして知られている。ユニキャストアドレスは、インターネット上の一意なコンピュータを特定するものである。しかしながら、インターネットアドレスの一部はマルチキャスト用に予約されている。

マルチキャストアドレスは、１つのコンピュータから一群のコンピュータに１対多の通信を行うために使用される。マルチキャストアドレスに送られたトラフィックは、１つのコンピュータに到達するのではなく、多くのコンピュータに到達する。マルチキャストを使用した適用例としては、教室での授業やビデオ会議などがある。

マルチキャストトラフィックを受信するルータは、同時にそのマルチキャストトラフィックを１以上の宛先に転送する必要がある。そのために、ルータは、マルチキャスト転送キャッシュ（MFC）として一般に知られている特定のバージョンの転送テーブルを使用する必要がある。マルチキャスト転送キャッシュの動作例が図１４に示されている。ノードＢ、Ｃ、およびＤからなるマルチキャストグループは、単一のマルチキャストアドレスＧによって表される。表２はノードＡのマルチキャスト転送キャッシュを示しており、表３はノードＢのマルチキャスト転送キャッシュを示している。

転送テーブルまたはマルチキャスト転送キャッシュを算出するために、ルータは、まず、ルーティングプロトコルを用いて既知の宛先への経路を算出しなければならない。そのようなルーティングプロトコルはいくつか存在するが、いずれも１７３６年のケーニヒスベルグの橋の問題に関するオイラーの最初の研究に続く数学者によって確立された周知のグラフ理論アルゴリズムに基づいている。

これらのルーティングアルゴリズムは、リンク状態および距離ベクタアルゴリズムに大別することができる。距離ベクタアルゴリズムは、宛先への最短経路距離を通信中のルータ間で交換するものである。この最短経路距離情報に基づいて、それぞれのルータは独立してその転送テーブルを算出する。距離ベクタベースのルーティングアルゴリズムの主な例としては、Routing Information Protocol（RIP）がある。これに対して、リンク状態ルーティングプロトコルは、ネットワークのトポロジーをすべてのノードに配信するものであり、それぞれのノードは独立してその転送テーブルを算出する。リンク状態アルゴリズムの主な例としては、Open Shortest Path First（OSPF）がある。リンク状態ベースのルーティングプロトコルは、インターネットで最も広く利用されている。

ルーティングプロトコルがすべての宛先への最短経路を算出すると、ルータがその転送テーブルを更新する場合がある。通常、これらの更新は、転送テーブルの変化を生じるようにネットワークトポロジが変化するたびに起きる。同様の方法で、ルータは、マルチキャストソースおよび受信者に関する利用可能な情報に基づいてマルチキャスト転送キャッシュを更新しなければならない。マルチキャスト転送キャッシュを更新するために、ルータは、マルチキャストルーティングプロトコルを用いる。マルチキャストルーティングプロトコルは、先に算出されたユニキャストルーティングテーブルを用いてもよいし、用いなくてもよい。例えば、Protocol Independent Multicast（PIM）プロトコルは、ユニキャストルーティングプロトコルにより算出された結果を利用し、Distance Vector Distance Multicast Routing Protocol（DVMRP）は、それ自身の内部ユニキャストルーティングプロトコルを利用する。いずれの場合も、マルチキャストルーティングプロトコルは、各ルータでマルチキャスト転送キャッシュを更新する。

マルチキャスト受信者であるインターネットホストは、Internet Group Management Protocol（IGMP）を用いて隣接するルータに対して自分自身を特定する。その後、各ルータは、このマルチキャストグループ受信者メンバシップ情報をそのマルチキャストルーティングプロトコルを用いてピアルータに配信する。マルチキャストソースであるインターネットホストは、適切なマルチキャストグループアドレス宛のマルチキャストパケットを隣接するルータに送信するだけである。そして、各ルータは、そのマルチキャスト転送キャッシュに記述されているように、これらのマルチキャストパケットを転送する責任を負う。

モバイルメッシュネットワークは、モバイルアドホックネットワーク（MANET）としても知られている。例えば、モバイルメッシュネットワークは、通信ノードが常に移動する無線装置であるような緊急サービスの人員によって使用される。インターネット技術特別調査委員会（IETF）は、モバイルメッシュネットワークルーティング問題に取り組むためにMANETワークグループを設立している。

このIETFのMANET作業部会からは、アドホックルーティングプロトコルと呼ばれる、モバイルメッシュネットワークに固有の４つのユニキャストルーティングプロトコルが出てきた。Topology Dissemination Based on Reverse-Path Forwarding（TBRPF）、Link State Routing Protocol（OLSR）、Ad hoc On-Demand Distance Vector Routing（AODV）、およびDynamic Source Routing Protocol for Mobile Ad Hoc Networks（DSR）である。これらのプロトコルのうち３つは、実験的なRequest For Comment（RFC）ステータス（それぞれRFC3684、3626、3561）まで進んでいる。４つ目のアドホックプロトコルDSRは、まもなく実験的RFCにまで進むと考えられている。マルチキャストアドホックプロトコルはまだ標準化されていない。

メッシュマルチキャスト転送キャッシュ
モバイルメッシュネットワークは、従来のインターネットネットワークと多くの点において異なっている。マルチキャスト転送キャッシュとの関連性での相違点は、移動性があること、ホストとルータとの間の区別がないこと、サービス品質（QoS）の要求があること、およびセキュリティ上の要求があることである。

ノードと呼ばれるモバイルメッシュネットワーク内のコンピュータは、常にその位置とピアノードへの接続を変える可能性がある。より一般的な有線コンピュータネットワーク内のコンピュータと異なり、メッシュノードは、場所、IPアドレス、およびピアへの接続などの属性が常に変化する可能性がある。これは、従来のインターネットプロトコルおよびネットワークの前提の多くを崩すものである。

メッシュノード移動性による２つ目の帰結は、一般に、図１５に示されるような「隠れノード問題」とも呼ばれている。隠れノード問題とは、すべてのメッシュノードが同一の無線インタフェイスを通じて互いのトラフィックを聞くことができないことをいう。これは、有線インタフェイスが、接続された近隣ノードからすべてのトラフィックを聞くことができることと対照的である。従来のマルチキャスト転送キャッシュは、変化するIPアドレスや隠れノード問題が生じるインタフェイスのいずれをもサポートすることができない。例えば、図１５において、ノードＣにはノードＡの伝送が聞こえず、このためノードＣの伝送のスケジューリングが、ノードＡから受信するつもりであるノードＢと干渉する場合が生じる。この意味で、ノードＣはノードＡから隠れており、その逆も同じである。

従来のインターネットにおいては、コンピュータは、そのトポロジーに関する相対的な位置によってルータまたはホストとして見ることができる。ルータはトラフィックをピアに転送するが、ホストは転送しない。典型的なコンピュータユーザがルータを使用することはあったとして極めてまれなことである。これは、ラップトップコンピュータや携帯情報端末（PDA）、パーソナルコンピュータのようにユーザに最も多く使用されているコンピュータに適用される多くの設計上の前提に現れている。例えば、典型的には、マルチキャスト転送キャッシュは、Windows XPやCEのオペレーティングシステムのようなエンドユーザのプラットフォームにおいては利用することができない。しかしながら、モバイルメッシュネットワークにおいては、すべてのノードは、定義上、ルータであり、またホストになることもある。すなわち、それぞれのノードはトラフィックをピアに転送することができなければならない。これは、メッシュノードに関してホストとルータとの区別を曖昧にする。

モバイルメッシュネットワーク無線インタフェイスには、サービス品質（QoS）に関して、有線インタフェイス等価物よりも大きな障害物がある。結果として、モバイルメッシュネットワークのように、インターネットの一部においてQoSは重要であり続ける。しかしながら、従来のマルチキャスト転送キャッシュは、QoSをほとんどまたは全くサポートしていない。また、無線モバイルメッシュネットワークトラフィックは、従来の有線ネットワークよりも傍受されやすい。このように傍受しやすいがために、モバイルメッシュネットワークトラフィックは、トランスポートレベルにおいても、より入念に保護されていなければならない。

これら４つの理由により、従来のマルチキャスト転送キャッシュ技術はモバイルメッシュネットワークノードの要求を満たしていない。本発明は、この問題および他の同様の問題に取り組むものである。

データ配信サービス（DDS）は、アドホックモバイルメッシュネットワーク内のノード間で情報を転送する。DDSは、トラフィックを最小限にするために再送信要求を合体させる技術をはじめとして、多くの異なる新規な特徴を含んでおり、イベント指向通信の信頼性を適切なレベルにすることができ、多くのノードによって使用される再送信をマルチキャストすることができ、マルチキャストトラフィックのためのその他の最適化を行うことができる。

DDSは、通信のためにUDPデータグラムを用いる。通信は、中央認証装置や記憶装置を必要としない正にピアツーピア方式により行われ、純粋にアドホックとすることができ、中央サーバに依存することがない。通常の動作においては従来の肯定パケットの必要性もなくなる。このようなNACKベースのプロトコルは、従来のTCPのようなアプローチに比べより効率的である。

DDSは、非常に長い回復間隔に従いやすく、かなりの期間中カバレッジを失う無線ネットワーク上のノードとよくマッチし、常に変化するネットワークトポロジにもうまく作用する。また、失った無線カバレッジに対応する期間にわたって信頼性を扱うこともできる。

拡張マルチキャスト転送キャッシュ（eMFC）は、モバイルメッシュネットワークにおけるマルチキャスト伝送をサポートしている。拡張MFCは、メッシュネットワークに特有のメッシュノード移動性、サービス品質、およびセキュリティ要求をサポートするように設計されている。これらの目的を達成するために、拡張MFCは、ユニキャストルーティングプロトコル、マルチキャストアウェアアプリケーション、および配信サービスによって保持されるグローバル状態から引き出す。eMFCは、eMFC固有のマルチキャストパケットヘッダを用いてこの得られたグローバル状態を配信する。eMFCヘッダ中に含まれる情報は、各メッシュノードにおいてマルチキャストトラフィック統計を収集し取得するためにも用いられる。上位互換性を維持するために、eMFC固有のヘッダを有しないマルチキャストトラフィックもMFCによって敬意が払われる。従来のインタフェイスタイプだけではなく、ラジオインタフェイスのようなモバイルメッシュネットワーク特有のインタフェイスもサポートされる。認証および暗号化技術を用いることによりセキュリティが維持される。

本発明の上記目的、特徴、効果、およびその他の目的、特徴、効果は、添付図面を参照して説明する本発明の好ましい実施形態についての以下の詳細な説明から容易に理解できるであろう。

図２は、先に図１に示されたメッシュネットワーク１２と同様のメッシュネットワーク２０において動作可能な数個のノード２２を示している。ノード２２は、無線または有線ピアツーピアメッシュ通信を行う任意のタイプの移動装置とすることができる。例えば、無線モデム付きのパーソナルコンピュータ、携帯情報端末（PDA）、携帯電話などである。他のノード２２は、有線または無線IPネットワークを通して他のノードと通信を行う無線ルータとすることができる。

移動装置２２は、ネットワーク２０に入ったり、ネットワーク２０から出たりとアドホックに移動することができ、他のノードとのピアツーピア通信を動的に再確立することができる。それぞれのノード２２Ａ、２２Ｂ、および２２Ｃが異なるデータ項目２６に対して一部またはすべてが同一のバージョンでなければならない場合がある。一例においては、データ項目２６を、ノード２２が他のノードと通信するために使用される所定のコンフィグレーションデータとすることができる。例えば、コンフィグレーションデータ２６は、ノードプロファイル情報やビデオ設定などを含んでいてもよい。他の例においては、データ２６は、同一のマルチキャストグループのメンバであるノードを特定するマルチキャストルーティングテーブルのようなマルチキャスト情報を含むことができる。

データ配信サービス
データ配信サービス（DDS）２４は、異なるノード２２におけるデータ２６間の整合性をより効率的に維持するために使用される。ソースノード２２Ａは、そのローカルデータ２６Ａを内部的に更新した後、他のノード２２Ｂおよび２２Ｃにデータ変更を通知するデータメッセージ２８を送出することができるノードの１つとして定義される。受信者ノード２２Ｂおよび２２Ｃは、ソースノード２２Ａによって内部的になされた変更により更新が必要となったノードとして定義される。

DDS２４は、異なる種々の方法で使用される図３に示されるようなソースデータパケット３８を送信および受信する。例えば、ソースノード２２Ａが他のノード２２Ｂおよび２２Ｃにデータ２６Ａの変更または現在のステータスを通知するステータスまたはデータメッセージ２８をマルチキャストするためにソースデータパケット３８を使用することができる。マルチキャストステータスまたはデータメッセージ２８に応答して、受信者ノード２２Ｂまたは２２Ｃは、否定応答（NACK）メッセージ３２をマルチキャストすることができる。

例えば、受信者ノード２２Ｃは、データ２６Ｃがデータ２６Ａ中のデータ項目のいくつかについて更新を見逃していたときにNACKメッセージ３２をマルチキャストすることができる。例えば、これは、移動装置２２Ｃが一時的にメッシュネットワーク２０に接続できず、データメッセージ２８を受信できないときに起こり得る。NACKメッセージ３２に応答して、ソースノード２２Ａは、修復メッセージ３０をマルチキャストすることができる。修復メッセージ３０は、受信者ノード２２Ｃ中のデータ２６Ｃおよびおそらくは受信者ノード２２Ｂ中のデータ２６Ｂを、データ２６Ａに対する最新の修正で更新するために必要な情報を提供することができる。一例においては、修復メッセージ３０を、要求されたデータ項目がもはや利用できないことを示すEXPIREDメッセージまたは変更されたデータ２６Ａ中のデータ項目を特定するCHANGEメッセージとすることができる。

一実施例におけるデータ配信サービス（DDS）２４は、データ項目２６間の整合性を維持するために、メッシュネットワーク２０内のすべてのノードにわたってシンボリックキー（データ名）を用いる。DDS２４は、信頼できる転送スキーム内に組み込むことができ、あるいは、以下に述べるように実装することができる。DDS２４は、最新のデータ項目だけが要求されたときに、データが持続的に２回バッファされ、特定のデータレコードの以前の修正が再送信されることを防止する。これは、より完全な設計であり、メッシュネットワークにわたって「小さな」データベースを複製することに関連した特定の問題を解決することができる。

概念上、DDS２４は、キー（データ名）を値（データ）に結合した配信ハッシュテーブルとして作用する。ノード２２は、後述するDDSプロトコルを介して互いに会話し、メッシュネットワーク２０全体にわたってデータ２６の整合性を維持するためにマッピングされたキー−値（データ名−データ）の１つの統一ビューを用いる。データ整合性は、各ノード２２におけるデータベース２６を事前に複製することによって得られる。データベース２６は、ノード２２に内部的に格納されたオブジェクトを含むことができる。

DDS２４が多数のネットワークノード２２にわたって隣接するノードのグローバル修正値を検知することによってデータ２６内の変化が追跡され、ローカルノードがどのデータの修正を既に有しているのかが示され、そのような２つの修正の間のデルタを記述した変化リストが要求され、欠落データの再送信が潜在的に要求される。

このようにしてDDS２４は、多くのノード２２に配信された一群のデータ項目２６を維持している。通信が始まる前にデータ２６が既に永続的に格納されているので、DDS２４は、高信頼トランスポートのように伝送を別個にバッファしておく必要がない。

ソースデータパケット
図３は、図２において既に述べたようなソースデータパケット３８の一例を示している。ソースデータパケット３８は、DDS動作を行うために使用されるヘッダ５２を含んでいる。ヘッダ５２中のフィールドの一部または全部を、図２で述べたメッセージ２８、３０、または３２を送信するために用いてもよい。ソースデータパケット３８は、メッセージを送信した元のノードに特有のノードIDフィールド４０を含んでいる。

各ソースデータパケット３８は、パケットを送信した元のノードからのすべての伝送の中でグローバルなパケットIDフィールド４２を含んでいる。パケットIDフィールド４２の値は、単調増加値である。受信者ノード、パケットとしてのレコードパケットIDが受信される。また、ヘッダ５２は、ソースデータパケット３８を送信したノード２２におけるデータ２６に対する最新の修正を特定するグローバル修正フィールド４４内にグローバル修正値（GRV）を含んでいる。GRVは、データ項目やなされた修正のタイプに関係なく、特定のソースノード２２におけるデータ２６に対してなされた最新の修正を定義するものである。例えば、ソースノード２２Ａ用のGRVは、データ２６Ａ（図２）に対してローカルになされた変更の数に対応している。したがって、データ項目Ａに対する第１の修正はGRVを１だけ増やし、異なるデータ項目に対する異なる修正によりGRVが再度１だけ増える。

履歴フィールド４６は、可能な再送信に対して記憶されているパケットID数を示している。GRV値および履歴フィールド４６内の履歴数は、それぞれソースデータパケット３８を受信しているノードにより追跡される。履歴フィールド４６は、GRV４４と組み合わさって、再送信可能であって、ノードIDフィールド４０により特定されるノード２２からのパケットIDのウィンドウを定義する。履歴ベースウィンドウの通信により、期限切れとして把握されたデータに対してピアがNACKを送信することがなくなる。うまく受信できなかったと判断されたパケットの再送信を要求するのは各受信者ノード２２の任務である。

アクションフィールドは、ソースデータパケット３８に関連づけられたメッセージのタイプを特定する。例えば、図６でより詳細に説明するように、STATUS、DATA、NACK、EXPIRED、CHANGE、またはRETRANSMITメッセージを送信するためにソースデータパケット３８を用いてもよい。

データモデル
ソースデータパケット３８にはペイロード５０が含められている。ペイロード５０は、データ−名前（キー）および関連データ−修正番号を含んでいる。本質的に、上述したデータ−名前は、特定のデータ項目を特定するキーである。データ−修正番号は、データ−名前により特定された特定のデータ項目に対する修正を特定する。

例えば、「プロファイル」データ項目に対する第４の修正は、ペイロード５０に「プロファイル：４」というエントリを有していてもよい。「ビデオ設定」データ項目に対する第５の修正は、ペイロード５０において「ビデオ設定：５」として特定され得る。また、ペイロード５０は、ソースノードにより変更されるのと同様に実際に修正されたデータ（データ−値）を含んでいる。ソースデータパケット３８にヘッダ５２の情報の一部または全部を含めることにより、異なるノード２２（図２）におけるデータ２６間の整合性を維持するために付加的な制御トラフィックが必要とされない。

同期細分性はオブジェクトレベルであり、キーの値であることに留意されたい。（関係あれば）オブジェクトのすべての特性は、オブジェクトの一部であり、別個に同期されることを必要としない。それぞれのデータ−名前に対して格納されたデータ２６（図２）は、自身の修正番号（データ−修正）を有しており、メッシュ全体に対して複製するときに、CHANGEメッセージは所定のデータに対する多数の変更を最小数に合体させることができる。

データプロトコル
メッシュネットワーク２０（図２）内のそれぞれのノード２２は、それぞれのパケットの一部としてそのグローバル修正値（GRV）を出す。上述したように、特定のオブジェクトに対する変更、またはノードにおける他のデータ項目は、それぞれのデータ項目に関連づけられた第２のデータ−修正番号を用いてより詳細に追跡することができる。

受信者ノード、例えば、図２における受信者ノード２２Ｂまたは２２Ｃが、［GRV−履歴，データ−修正］により定義される伝送ウィンドウに「穴」を見つけたとき、NACKメッセージ３２をソースノード２２Ａに返信し、修復を要求する（図２）。実際のNACK要求は、NACKメッセージ３２を合体させるように多数の連続番号またはGRV値を含んでいてもよい。すぐにNACKメッセージ３２を送信しなくてもよいが、ランダムバックオフインターバルの後に送信してもよい。このバックオフインターバルは指数関数的に分散させてもよい。修復パケットはマルチキャストされるので、特定のデータ項目を要求するノードは、いずれも他のノード２２に同一のデータ項目を受信させることができる。NACKメッセージのためのランダムバックオフ伝送期間により他のノードは同様のNACK要求をせずにすみ、これにより送信しなければならないNACKの数を少なくすることができる。

さらに説明すると、図４は、データ配信サービス（DDS）２４を提供するソフトウェアを操作する中央処理装置（CPU）５８を含むソースノード２２Ａを示している。CPU５８は、アンテナ６１に連結されたトランシーバ６０を介して無線でDDSメッセージ６３を送受信する。同様に、図５は、DDS２４を操作するソフトウェアを含む受信者ノード２２Ｂまたは２２Ｃの一方の中にあるCPU７８を示している。CPU７８は、アンテナ８４に接続されたトランシーバ８２を介して無線でDDSメッセージを送受信する。

この例におけるソースノード２２Ａは、３つの異なるデータ項目を含んでいる。データ項目５２はプロファイルデータを含み、データ項目５４はビデオ設定を含み、データ項目５６はマルチキャストテーブルまたは他のタイプのコンフィグレーションデータを含んでいる。それぞれのデータ項目は、関連データ−修正番号を含んでいる。例えば、プロファイルデータ項目５２は現在データ−修正＝５を有しており、ビデオ設定５４は現在データ−修正＝４を有している。

また、ソースノード２２ＡのCPU５８は、データ項目５２、５４、および５６のいずれかに対してなされた変更に関連づけられたグローバル修正値（GRV）６２を常に得ている。図４に示された例においては、CPU５８は現在データ項目５２、５４、および５６に対して１２回のGRV変更を行っている。GRV１１はデータ項目５４に対してなされ、GRV１０および１２はデータ項目５２に対してなされた。また、GRVの変更６２を同一のデータ項目における多数の変更によるものとすることができる。例えば、GRV１０をプロファイル５２の修正４によるものとし、GRV１２をプロファイル５２の修正５によるものとする。

説明のために、受信者ノード２２Ｃの現在の状態を図５に示す。受信者ノード２２Ｃは、「プロファイル」データ項目７２、「ビデオ設定」データ項目７４、および「マルチキャストテーブル」データ項目７６を含んでいる。プロファイルデータ項目７２は現在関連データ−修正番号＝３を有しており、ビデオ設定データ項目７４は現在データ−修正番号＝４を有している。受信者ノード２２Ｃは、GRV＝９としてソースノード２２Ａに関連づけられた現在のグローバル修正値（GRV）７９を常に得ている。例えば、ソースノード２２Ａから受信した最後のデータ更新は、関連GRV＝９を有していた。

図６は、異なるメッシュノードにおけるDDS２４によって送信され得る、異なるDDSメッセージを示している。

ステータスメッセージ
他のパケットが送信されていないときに、ソースノード２２ＡによりSTATUSメッセージ９０が定期的に送信される。一実施形態においては、変化がないことを示すためにSTATUSメッセージ９０が定期的に送出される。図６に示される例においては、STATUSメッセージ９０は、ソースノード２２Ａに対するノードID４０と、ソースノード２２Ａに対するグローバル修正値（GRV）４４とを含んでいる。アクションフィールド４８は、STATUSメッセージとしてのパケットを示している。受信者ノード２２Ｂまたは２２Ｃが同一のノードID４０に対して同一のGRV４４を有している場合には、さらなるアクションは要求されない。

図４および５に示される例においては、ソースノード２２Ａにより送信されたステータスメッセージ９０がGRV＝１２を示しており、受信者ノード２２Ｃ中の対応するGRVがGRV＝９である。これは、受信者ノード２２ＣがNACKメッセージ９４を送信するのを促す。

データメッセージ
ソースノード２２Ａがデータ項目の変更、修正、追加、削除などを行うたびにDATAメッセージ９２が送信される。DATAメッセージ９２は、更新する必要のある、または受信者ノード２２Ｂおよび２２Ｃのすべてに追加する必要のある実際のデータを有している。データ２６Ａ（図２）が変更されると、DATAメッセージ９２がメッシュネットワーク２０内の他のノードにマルチキャストされ、DATAメッセージ９２はデータ−名前とそのデータ−修正番号を含む。この例では、DATAメッセージ９２は、データ−名前＝プロファイルおよびデータ−修正＝５を特定し、実際に更新されたバージョン５のプロファイルデータを含んでいる。また、DATAメッセージ９２は、ソースノード２２Ａに対する最新グローバル修正値GRV＝１２も含んでいる。

DATAメッセージ９２またはSTATUSメッセージ４８の受信後、受信者ノード２２Ｃは、DATAまたはSTATUSメッセージ９２内のGRV＝１２を、最も新しく受信したそのノードIDに対するGRVと比較する。通常、このパケットのデータ変化に対応して、ソースノード２２Ａから受信したGRVを１だけ増やす必要がある。この場合、ソースノードからの最も新しいローカル修正がデータメッセージ９２におけるデータで更新される。

否定応答（NACK）
それぞれの受信者ノードは、受信したパケットを常に得ており、パケットIDとその受信タイムスタンプとを、ソースごとに保持される受信パケットリストに追加する。例えば、ソースデータパケット３８（図３）はソースノードIDによってインデックス化される。また、受信ノードは、他のノードに対するグローバル修正値と履歴値を格納し、GRVが変化すると、受信したパケットごとにそれらを更新する。

ウィンドウ外のノードIDはリストから除かれ、その結果得られたリストは欠落パケットIDのためにスキャンされる。欠落データが検出されると、受信者ノードによりNACKメッセージ９４が送信される。NACKメッセージ９４を送出する前に、指数関数的に分散されたランダムな時間間隔を計算して用いることができる。これにより、多数の受信者ノードが同一の要求パケットに対して同時にNACKメッセージ９４を送信しようとするNACKインプロージョンが防止される。受信者ノード２２Ｃは、ランダムな時間間隔の後に起動するようにスケジュールし、再びGRVをチェックして、おそらく欠落したソースデータパケット３８に対応するNACK９４を送信する。

NACK９４に応答してCHANGEメッセージ９８またはEXPIREDメッセージ９６がソースノード２２Ａから受信されると、すべての保留中のNACKが更新され、受信されたパケットがリストから削除される。また、同一の情報を要求した他のノードから受信したNACKメッセージ９４もリストから削除される。伝送ウィンドウの外側にあるパケットIDも削除される。

待機中にNACKリストが空になった場合は、NACKリストが完全に削除される。NACKメッセージ９４が送信されると、送信された時刻のタイムスタンプとともにNACKメッセージ９４が修復要求リストに追加される。同様に、ピアにより送信された次のNACKもこのリストに追加される。

活動をしていないときには、受信者ノード２２Ｃは起動したままですべてのノードのリストをスキャンし、欠落パケットであるが他の活動をしていなかったピアのためのNACKプロセスを再開する。これは、パケットの有効期間が切れるまで再試行される。ノードに対してトラフィックが全く検出されない場合には再試行の期間が調整される。これにより、ノードがメッシュネットワーク２０から完全に消えてしまう場合にもうまく対応することができる。

受信ノード２２ＣがDATAメッセージ９２を見逃した場合、ソースノード２２Ａから次のDATA、STATUS、EXPIRED、またはCHANGEメッセージが受信されるまで通知されない。また、これらのメッセージのすべては、ソースノード２２Ａに対するグローバル修正値（GRV）を含んでいる。その点で、受信ノード２２Ｃは、送信者ノード２２Ａに対するGRV６２が最後に見たもの（GRV＝９）よりも大きいことを示し、欠落したGRV番号を特定するNACKメッセージ９４をマルチキャストする。

例えば、図４において、CPU５８は、GRV＝１２およびソースノード２２Ａに対する関連ソースノードIDとともにステータスメッセージ６３を送出してもよい。受信者ノード２２Ｃは、そのソースノードIDに対する現在のGRVとしてGRV＝９を有している。したがって、受信者ノード２２Ｃは、欠落したGRV１０〜１２を特定する図６に示されるようなNACKメッセージ９４をマルチキャストする。

CHANGE、RETRANSMITおよびEXPIREDメッセージ
ソースノード２２Ａは、NACKメッセージ９４に応答して実際のデータを送信しない。あるいは、ソースノード２２Ａは、NACKメッセージ９４において特定されたGRVに対するキー（データ−名前）とそれらの特定のデータ−修正番号を列挙した変更リストを送信する。その結果得られたCHANGEメッセージ９８（図６）は、注目されているすべてのグローバル修正値と、これらのグローバル修正値に関連づけられたキー／値／修正のリスト９とを列挙する。例えば、図４において、ソースノード２２Ａは、GRV＝１１に対するデータ−名前＝ビデオ設定：４と、GRV＝１２に対するデータ−名前＝プロファイル：５とを含むCHANGEメッセージ９８を返信してもよい。ビデオ設定およびプロファイル双方に対するデータ自体は、CHANGEメッセージ９８により送信されなくてもよい。

他の例においては、他のノードが気づく前にデータ項目が何度も変化する場合、最も新しい１つのデータを送出して古い修復要求を満たすことができる。これは、新しいバージョンの１つのデータで更新すべき古いグローバル修正を特定するCHANGEメッセージ９８により行われる。一実施例においては、古い値は保持されずに、データ項目および対応する修正番号の最も新しいバージョンのみが保持される。

例えば、図４において、GRV＝１０は、もはや有効ではない以前の古いバージョンのプロファイル５２（データ−名前＝プロファイル、データ−修正＝４）に関連づけられているので、ソースノード２２Ａは、GRV＝１０に関連づけられたデータ−修正を返信しなくてもよい。

受信者ノード２２Ｃは、扱われているすべての古いグローバル修正を示し、キー／値／修正を見て、再送信のためにどのキーを要求する必要があるのかを決定し、ソースノード２２ＡにRETRANSMITメッセージ１００（図６）を返信する。例えば、図５の受信者ノード２２Ｃにおける「ビデオ設定」データ項目は、ソースノード２２Ａに関連づけられたノードIDに対してデータ−修正値＝４を有している。これは、図６のCHANGEメッセージ９８に示されたデータ−修正値と同一である。したがって、受信者ノード２２Ｃは、ビデオ設定に関して再送信要求を送信しない。

図５の受信者ノード２２Ｃにおけるプロファイルデータ項目７２は、データ−修正値＝３を有している。しかしながら、図６の変更メッセージ９８におけるプロファイルは、データ−修正値＝５を有している。このようにして、受信者ノード２２Ｃは、現在のプロファイルデータ項目７２の有効期限が切れていることを決定する。したがって、図５のCPU７８は、GRV１２に関連づけられたプロファイルデータを送ることをソースノード２２Ａに要求する図６に示されるようなRETRANSMITメッセージ１００を送信する。ソースノード２２Ａは、図４のプロファイルデータ項目５２を含む図６に示されるような他のDATAメッセージを生成することにより、RETRANSMITメッセージ１００に応答する。

あるいは、図４のプロファイルデータ項目５２が利用不可能である場合は、ソースノード２２ＡがEXPIREDメッセージ９６を送信してもよい。これは、データの有効期限が切れてこの交換が生じたときに、乱調状態を扱う。あるいは、EXPIREDの表示をCHANGEメッセージ９８の一部にすることができる。介在メッセージのいずれかが失われた場合には、すべてのプロセスが最初からやり直される。

ソースノード２２ＡがNACKメッセージ９４（図６）を受信すると、まず、欠陥パケットIDが伝送ウィンドウの内部にあるかをチェックする。なければ、ピアがそれを求めることをやめるべきであることを示すEXPIREDメッセージ９６を送信する。伝送ウィンドウの内部にあれば、元のデータ項目が取り込まれ、再送信される。ソースデータ項目は、再送信の回数に関係なく、元の有効期限が切れるまで送信済みパケットリスト内に残ったままである。最も新しい伝送の時刻を表示するためにエントリが更新される。

ソースノード２２Ａによりデータパケットが送出された後、短時間でNACKメッセージ９４が受信された場合、送信されたデータパケットだけがNACK９４が満たすという仮定の下でNACKメッセージ９４を無視する場合がある。NACK９４をドロップしやすい乱調状態の場合、受信者ノード２２Ｃは、再びデータ項目を要求する。

要求した修復データと特定のデータ修正に対するグローバル修正のマッピングとを有するメッシュネットワーク２０（図２）内のノードは、NACKメッセージ９４に応答可能であることに留意されたい。これにより、上述したように、ソースノード２２Ａは要求したデータを有するノードとなり得る。ランダムバックオフ遅延は、各ノードが同時にそのように動作することを防止するために利用される。この任意的な選択は、修復を提供するノードが、他のすべてのノードに対するデータ修正マッピングへのグローバル修正を格納することを意味している。

特に単一のキーが繰り返し更新されるような場合に、DDSメッセージ交換によりデータが何回も送信されることが防止されるという点で、プロトコルは別の利点を有している。この場合においては、最も新しい値のみが伝送され、高信頼マルチキャスト伝送によりそれぞれの変更が送信され、以前の値が上書きされる。

シナリオ
図７〜１１は、データ整合性操作中に起こり得る、異なるDDS受け渡しシナリオのいくつかを説明するものである。

エラーなし、連続受け渡し
図７は、最も簡単なケースの１つを示しており、ソースノード２２Ａからソースデータパケット３８（図３）が送信され、送信した元の順番で順次うまく受信者ノード２２Ｂに受信されている。それぞれのパケットＮは、受信しているパケットが最も新しいことを示すグローバルバージョン番号を有しており、したがって付加的なアクションを行う必要はない。

エラーなし、受け渡し不順
図８に示される次のケースにおいては、ソースノード２２Ａによってソースデータパケットが送信され、受信者ノードによってうまく受信されるが、送信した元の順番は保持されていない。これにより、遅延時間Ｔが経過する前に「スキップされた」パケットＮ＋１が受信されない限り、ランダム遅延Ｔの後にNACKメッセージ９４（図６）が送信される。図８は、ランダム遅延時間Ｔの経過前にパケットＮ＋１が受信者ノード２２Ｂに受信される場合を示している。この場合においては、NACKメッセージ９４が抑制される。

単純修復
図９は、パケット連続番号を１つスキップし、NACKメッセージ９４が出て行くようにスケジュールされるときになっても、欠落ソースデータパケットＮ＋１がまだ受信されていない場合を示している。この場合においては、NACKメッセージ９４は保留中であり、パケットＮ＋１は時間Ｔの間に受信されない。したがって、受信者ノード２２Ｂは、上述したようにソースデータパケットＮ＋１を特定するNACKメッセージ９４をソースノード２２Ａに送信する。その後、ソースノード２２Ａは、DDSプロトコル（CHANGEおよびRETRANSMITメッセージは図示せず）を通じてソースデータパケットＮ＋１に再送信する。

合体修復
図１０は、１つのソースデータパケットよりも多くのパケットが欠落していると検出されるときの状況を示している。パケット番号、データ項目、またはGRVのセットを１つのNACKメッセージ９４にカプセル化することができる。このとき、NACKメッセージ９４を送信する準備ができており（すなわち、最も短いランダムバックオフインターバル）、パケットＮ＋１およびＮ＋２に対するすべての保留中のNACKがNACKメッセージ９４に含められる。同じく、NACKとデータの再送信との間のプロトコルは示されていない。

NACK抑制
図１１は、多数の受信者ノード２２Ｂおよび２２Ｃが欠落パケットを検出するときの状況を示している。それぞれの受信者ノード２２Ｂおよび２２Ｃは、潜在的にNACKメッセージ９４を送信することができる。しかしながら、それぞれの受信者ノード２２Ｂおよび２２Ｃは、NACKメッセージ９４を送信する前にランダム遅延を用いてもよい。これにより、受信者ノード２２Ｂまたは２２Ｃの一方が他の受信者ノードの前にNACKメッセージを送信する。

例えば、受信者ノード２２Ｃは、ランダムな時間間隔ＴでNACKメッセージ９４を送信するようにスケジュールされ、受信者ノード２２Ｂは、受信者ノード２２Ｃの後にランダムな時間間隔Ｔ＋１で同一のNACKメッセージ９４を送信するようにスケジュールされる。NACKメッセージ９４はマルチキャストされるので、他のノードは受信者ノード２２Ｃにより送信された最初のNACKメッセージ９４を見るであろう。これにより、受信者ノード２２Ｃから受信されたNACKメッセージ９４が受信者ノード２２Ｂにおいて欠落しているパケットIDを含んでいる限りにおいて、受信者ノード２２Ｂは同一のNACKメッセージを送信することを抑制する。同じく、NACKとデータの再送信との間のプロトコルは示されていない。

図１６を参照すると、拡張MFCシステムアーキテクチャ２１２は、配信マルチキャストルーティング機構であり、マルチキャスト転送キャッシュ２２４およびマルチキャストテーブル計算２２２からなっている。これらの２つのコンポーネントは、メッシュノード上で利用可能なグローバルおよびローカル状態から情報を得て、マルチキャストトラフィックを適切にルーティングする。拡張MFC２１２を実行するノードのすべては、モバイルメッシュネットワークと従来のインターネットプロトコル（IP）ベースのネットワークとの双方にわたるオーバーレイネットワークを生成する。

図１６は、メッシュネットワーク内の拡張MFC２１２を操作するノード２７０を示している。マルチキャストアウェアアプリケーション２１６は、ソケットアプリケーションプログラムインタフェイス（API）コール２１７を用いてマルチキャストソケット２２０をオープンし、マルチキャストソースとして宣言し、マルチキャストデータ型（例えば、ビデオ、音声、バルクデータなど）を設定し、マルチキャストデータ２４２を送信し、マルチキャストデータ２４２を受信し、ソケット２２０をクローズする。これらのソケットコール２１７は、基礎マルチキャスト転送キャッシュ２２４に依存してマルチキャストトラフィック２４２を転送するための０以上のネットワークインタフェイス２２６を選択する。

マルチキャスト転送キャッシュ２２４は、マルチキャストテーブル計算コンポーネント２２２によって維持されている。マルチキャストテーブル２２２は、それぞれ既知のマルチキャストソースおよびグループに対するエントリをマルチキャスト転送キャッシュ２２４に書き込む。マルチキャストテーブル計算コンポーネント２２２は、モバイルメッシュネットワーク内で利用可能なグローバル状態情報からこれらのマルチキャストグループ送信者およびグループを得る。そのようなグローバル状態配信プロトコルの公知例としては、ローレンス・バークレー国立研究所（LBNL）でVan Jacobsonによりなされた研究に基づいて作られたマルチキャストセッションディレクトリsdrがある。

マルチキャストテーブル計算コンポーネント２２２は、基礎ユニキャストルーティングプロトコル２１８からネットワークトポロジーを得る。理想的には、プロトコル２１８は、事前型アドホックリンク状態ベースのプロトコルであるが、そうである必要はない。例えば、インターネットマルチキャストプロトコルであるDistance Vector Multicast Routing Protocol（DVMRP）やMulticast Extensions to OSPF（Open Shortest Path First）は、距離ベクタおよびリンク状態プロトコルからそれぞれトポロジー情報を得る。ブロック２１４内の従来の要素は、当業者によく知られており、したがって、さらなる詳細は説明しない。

ブロック２１３には、拡張マルチキャスト操作が示されている。マルチキャストメンバシップ情報２２８およびレガシーマルチキャストサポート２３０がマルチキャストテーブル計算２２２に与えられる。一例においては、マルチキャストメンバシップ情報２２８は、上述した分散配信サービス（DDS）を用いて配信され、すべてのメッシュノードが含んでいるグローバル状態情報である。レガシーマルチキャストサポート２３０は、MFC２２４内またはマルチキャストパケット内の既存のマルチキャストサポートに関するものである。ノードがeMFCヘッダを含んでいない場合は、パケットはレガシーマルチキャストサポート２３０を用いて従来のマルチキャストパケットから復帰することができる。メッシュインタフェイスサポートは特定のメッシュノード情報に関するものである。例えば、ノードが、特定のインタフェイスがメッシュインタフェイスであるかを決定し、したがって、メッシュネットワークのために必要なルーティングの決定を行ってもよい。

図１７により詳細に示されている拡張MFCヘッダ２５０を通してメッシュネットワーク内のノードに中継される配信メンバ状態２３２を介して拡張MFC２１２が提供される。

特に重要な３つのeMFC操作は、重複パケット検出２３６、セキュリティ特徴サポート２３８、およびQoS拡張２４０を含んでいる。

配信マルチキャスト状態
図１７および１８を参照すると、拡張MFC２１２は、マルチキャストパケット２５０上で予め引き延ばされた所有パケットヘッダ２５１を用いてグローバル状態を維持する配信マルチキャストルーティング機構である。この配信状態は、サービス品質やリンク品質対策のような特徴を適切にサポートするために必要である。それぞれのマルチキャストパケット２５０は、メッシュノードを操作する拡張MFC２１２（図１６）を通って流れるので、特定のeMFCヘッダ２５１を予め引き延ばすことによりマークされる。このヘッダ２５１には、eMFC状態をピアメッシュノード２７０に配信し、サービス品質（QoS）のような特徴をサポートするために必要なフィールドが含まれている。

マルチキャストパケット２５０は、モバイルメッシュネットワーク２６９（図１８）を横断して流れるので、同一のeMFCヘッダ２５１が最終マルチキャスト宛先までの経路に沿ってそれぞれの拡張MFC２１２によって見られる。これは、それぞれのメッシュノード２５０がマルチキャストパケット２５０を転送する前にeMFC２１２と相談するからである。

例えば、図１８において、第１のメッシュノード２７０Ａを車両内に配置し、第２のメッシュノード２７０Ｂが携帯情報端末（PDA）を操作し、第３のメッシュノード２７０Ｃが無線ラップトップコンピュータを操作してもよい。マルチキャストパケット２５０は、ノード２７０Ａによって送信され、eMFCヘッダ２５１により予め引き延ばされる。メッシュノード２７０Ｂ内のeMFC２１２は、eMFCヘッダ２５１の情報に従ってマルチキャストパケット２５０をメッシュノード２７０Ｃにルーティングする。メッシュノード２７０Ｃは、マルチキャストパケット２５０を受信し、おそらくeMFCヘッダ２５１の情報に従ってマルチキャストパケット２５０をルーティングし続ける。マルチキャストパケット２５０は、メッシュネットワーク２６９を通って流れ、あるモバイルメッシュネットワークノード２７０から他のモバイルメッシュネットワークノードに移動するので、拡張MFCパケットヘッダ２５１は、このマルチキャストストリームの状態をその経路に沿ってすべてのメッシュノードに配信する役割を有している。

MFCパケットヘッダ２５１は、メッシュノードに、従来のメッシュネットワークでは現在サポートされていない重複パケット検出２３６、セキュリティ特徴サポート２３８、QoS拡張２４０（図１６）などのより効果的なマルチキャスト関連操作を行わせることができる。

eMFCヘッダ２５１の個々のフィールドは、図１９においてより詳細に述べられている。バージョン番号２５２は、他のマルチキャストバージョンとの上位互換のために用いられる。メッシュノード送信マルチキャストパケット２５０はルータ識別子（ルータID）２５４によって識別され、ノード２７０が移動してインタフェイスをオンオフすると経時的に変化するまたは変化しないIPアドレスへの依存をなくすことができる。ルータID２５４は、モバイルメッシュネットワークの有効期間中は一定のままであり、特定のメッシュノードに関連づけられ、いずれのIPソースアドレスにも結びつけられない。したがって、ノードが同一または異なるメッシュネットワーク内の他の場所に移動しても、ルータ識別子２５４はメッシュノード２７０に対して同一のままである。

ヘッダ２５１は、特定のルータID２５４により送信されたマルチキャストストリームにおけるマルチキャストパケット番号を特定する連続番号２５６を含んでいる。宛先アドレス２５７および宛先ポート２５８は、上記表２および３に示されるような特定のマルチキャストグループに対するマルチキャストアドレスを特定する。トラフィックカテゴリ２６０は、メッシュノード２７０におけるQoS操作のために使用される。配信状態に加えて、eMFCヘッダ２５１は、マルチキャストトラフィック統計を得るためにノードで使用することもできる。これらの統計は、後述する品質サービス特徴のために使用することができる。図１７に示されるオプションの暗号化値は、マルチキャストパケット２５０とともに使用される暗号化スキームのタイプを特定するために使用することができる。一実施例においては、eMFCヘッダ２５１は、IPヘッダの後であってデータペイロード２６４の前に位置している。

図２０は、モバイルメッシュネットワーク内のノードがどのようにして同一のメッシュ内の他のノードまたはオーバーレイネットワークを介して他のモバイルメッシュネットワーク内の他のノードに直接接続されるかを示すものである。例えば、メッシュ１とメッシュ２という２つのメッシュがランデブ２８０を介して互いに通信する。ランデブは、トンネル２８１を介してメッシュ１と２を接続する周知の予め確立されたサーバである。

ランデブサーバ２８０自体が拡張MFC２１２を含んでおり、メッシュノード１および２へのメッシュノードピアとして機能する。メッシュ１およびメッシュ２上のノードは、eMFC２１２を用いて互いに通信することができ、あるいは、従来のマルチキャストプロトコルを介してインターネット２８２上の他のノードと通信することができる。このように、異なるメッシュネットワーク上または異なるメッシュおよびインターネットネットワーク上の２つのノードは、eMFCヘッダ２５１（図１７）に含まれるeMFC情報を交換することができる。

メッシュインタフェイスサポート
拡張MFC２１２は、従来のインターネットネットワークインタフェイスおよびメッシュ特有のネットワークインタフェイスの双方においてマルチキャストをサポートしている。すなわち、eMFC２１２は、通常マルチキャストトラフィックを聞いていないマルチキャストリスナーに向いているメッシュノードインタフェイス上でマルチキャストトラフィックを繰り返すことによる隠れノード問題を有するインタフェイスをサポートしている。

図２１および２２を参照すると、従来のインタフェイスから送信されたマルチキャストパケット２５０は、そのインタフェイスに接続されたすべてのピアに到達すると考えてもよい。ハブまたはスイッチ上のイーサネットインタフェイスは、従来のインタフェイスの例である。この仮定が当たっていなくても、例えば、スイッチを通過するマルチキャスト伝送の場合、基礎システムコンポーネント、この場合においてはスイッチが補償するように設計されている。

しかしながら、メッシュインタフェイスの場合、そのような補償は存在しない。その代わりに、メッシュノードは、元のマルチキャスト伝送を聞くことができない下流ノードのためにいくつかのメッシュインタフェイス上でマルチキャストトラフィックを繰り返さなければならない。例えば、図２２において、メッシュノードＡは、ノードＣ宛のマルチキャストパケット２５０を送出することができる。しかしながら、ノードＣが、ノードＡから直接パケット２５０を受信できる範囲にない場合がある。このような状況においては、ノードＢが、ノードＡからノードＣにマルチキャストパケット２５０を中継するルータとして動作する必要がある。しかしながら、範囲内のそれぞれのノードにマルチキャストパケット２５０をむやみに繰り返すことにより、すべてのノードが同一のマルチキャストパケットを放送するというブロードキャストストームが生じるおそれがある。

この問題および他の問題をなくすために、メッシュノードは、マルチキャストパケットの転送に関する決定をするときに、メッシュインタフェイス情報を考慮する。例えば、図２１において、ブロック３００でノードＢ（図２２）がマルチキャストパケットを受信する場合がある。ブロック３０２において、ノードＢは、パケット２５０が拡張MFCヘッダ２５１を有しているかを決定する。決定ブロック３０４におけるノードＢは、受信されたメッシュインタフェイス上でパケットを繰り返さなければならないかを決定する。繰り返さなくてもよい場合には、ブロック３０６で従来のマルチキャストルーティングが行われる。しかしながら、決定ブロック３０４において、受信されたメッシュインタフェイス上でパケットを繰り返さなければならない場合には、ノードは、決定ブロック３０８において、メッシュインタフェイスに関連づけられた下流の受信者がいるかを決定する。いない場合には、マルチキャストパケットを繰り返す必要はなく、ブロック３０６において通常のマルチキャスト操作が行われる。決定ブロック３０８においてノードＢに下流の受信者がいる場合には、ブロック３１０において、受信されたメッシュインタフェイス上で特定された下流ノードへのマルチキャストパケットが繰り返され、受信されたメッシュインタフェイスを聞くことはできるが、元のマルチキャストパケット（図２２）は聞くことができない下流ノードに向けてトラフィックが前方に転送される。

下流ノードは、eMFCヘッダ２５１（図１７）のマルチキャストアドレスに関連づけられたマルチキャストグループのメンバであってもよいし、そうでなくてもよい。例えば、図２２において、マルチキャストパケット２５０は、ノードＡからメッシュノードＢに送信される。ノードＣがマルチキャストグループ内においてマルチキャストパケット２５０に対して識別されない場合であっても、ノードＣはノードＢに対して下流の受信者になるので、ノードＢはパケットをノードＣに転送する。これにより、マルチキャストグループのメンバでありノードＣよりも下流の他のメッシュノードが、ノードＣからマルチキャストパケット２５０をうまく受信することが可能となる。この例においては、ノードＤは、ノードＢに対して指定された下流メッシュノードではない。このため、ノードＣがマルチキャストパケット２５０をメッシュノードＤに伝送することはない。これにより、マルチキャストパケットがメッシュネットワークを越えて送信される場合に通常生じるブロードキャストストームを防止することができる。

図２３は、ノードＢがマルチキャストパケット２５０をルーティングする方法をより詳細に示すものである。ブロック３２０において、ノードＢはマルチキャストパケットを受信する。ブロック３２２において、ノードＢは、eMFCヘッダ２５１のルータID２５４、宛先アドレス２５７、および宛先ポート２５８（図１７）および配信マルチキャストルーティングテーブルに従って、マルチキャストグループのメンバを特定する。ブロック３２２において、eMFCヘッダ２５１のルータ識別子２５４を介してマルチキャストパケットのソースが特定される。

ブロック３２６において、ノードＢ（図２２）は、ローカルルーティングテーブルに従って、マルチキャストパケット２５０を転送するためのノードを特定する。換言すれば、ブロック３２６においては、マルチキャストルーティングテーブルが、マルチキャストパケットをブロック３２２において特定されたソースノードからブロック３２２において特定された１以上のノードに転送することをノードＢに要求してもよい。したがって、ブロック３２８において、ノードＢは、図２１に述べられたメッシュインタフェイス基準を満たせば、マルチキャストパケット２５０を特定されたノードに転送する。

従来のルーティングプロトコルは、関連下流ノードをノードに通知する。これは、例えば、図１６のマルチキャストメンバシップ情報２２８によってなされる。そして、配信されたeMFCヘッダ２５１は、マルチキャストパケット２５０に関連づけられた特定のマルチキャストグループを特定する。

重複パケット検出
メッシュネットワーク内のノードには、重複マルチキャストパケットを受信する不具合が生じる可能性がある。メッシュノードは、移動性やインタフェイス変化をはじめとする種々の理由により、同一のマルチキャストトラフィックの多数のコピーを受信する場合がある。例えば、図２４において、ノードＡはマルチキャストパケット２５０をノードＢに送出することができる。そして、ノードＢは、同一のマルチキャストパケット２５０をノードＣに放送することができる。しかしながら、マルチキャストパケット２５０の同一の放送はノードＡで受信される。重複マルチキャストパケット２５０は、ノードＡが同一のマルチキャストパケットに対して処理を繰り返すことを招く可能性がある。このため、重複パケット検出がモバイルメッシュネットワークの移動無線環境においては特に重要である。重複パケット２５０は、ノードＡのeMFC２１２によって特定され、パケットを処理するアプリケーションに至る前に操作３４６において静かにドロップされる。

図２５は、重複パケットを検出しドロップするためにeMFC２１２で行われる基本ロジックを示すものである。ブロック３４０において、ノードがマルチキャストパケットを受信する。ブロック３４２においては、ノードの拡張MFC２１２がeMFCヘッダ２５１（図１７）中の情報を読み込む。受信されたマルチキャストパケットが同一のノードにより以前に受信されたパケットの複製であることをeMFC情報２５１が示している場合には、ブロック３４６においてパケットがドロップされる。そうでない場合には、ブロック３４８においてパケットが転送される。

重複マルチキャストパケットは、eMFCヘッダ２５１（図１７）のルータID２５４、連続番号２５６、宛先アドレス２５７、および宛先ポート２５８の組み合わせを用いて検出される。これにより、重複パケット受信をより正確に決定することができる。

図２６はより詳細に説明している。ブロック３５０において、メッシュノードがマルチキャストパケットを受信する。eMFC２１２は、パケットヘッダ２５１（図１７）のルータID２５４をチェックする。同一のルータIDを有するパケットが処理されたことがない場合は、ブロック３６０においてノードが通常の方法でマルチキャストパケットを転送する。ブロック３５２においてノードが同一のルータIDを有する他のパケットを受信した場合は、ブロック３５４において、宛先アドレス２５７、宛先ポート２５８、およびパケット連続番号２５６の値がチェックされる。これらの値が最近伝送された他のパケットとは異なっている場合には、ブロック３６０においてパケットが転送される。ブロック３６０においてルータID、宛先アドレス、および連続番号が最近伝送された他のパケット流れと同じ場合には、パケットは重複であると判断され、ブロック３５８において捨てられる。

拡張MFC２１２は、ソースノードの各マルチキャストパケットに単調増加連続番号２５６でタグをつける。したがって、連続番号２５６は、重複マルチキャストパケットを取り除きドロップするために、ソースから受信者への経路における各ホップで使用される。マルチキャストパケットは異なる順序で到達する場合があるので、eMFC２１２は、各マルチキャストストリームに対して単に最大の連続番号の保持ではなく、マルチキャスト連続番号の受信をチェックすることに留意されたい。同様に、連続番号は「ひっくり返る」ことがある。最大連続番号が割り当てられ、次のパケットが最小連続番号でマークされたときに連続番号がひっくり返る。eMFC２１２は、連続番号のひっくり返りも補償する。

セキュリティ特徴サポート
図２７においては、拡張MFC２１２を実行しているノード間のマルチキャストトラフィックは、隣接するノードを認証し、ホップごとにマルチキャストトラフィックを暗号化するなどのセキュリティ特徴をサポートすることによって、セキュリティが確保されている。セキュリティは、モバイルメッシュネットワークのような頻繁に変化する移動無線ネットワークにおいて特に重要である。eMFC２１２を用いたそれぞれの移動ノードＡ〜Ｄは、システム内で利用可能なセキュリティ特徴を利用することができる。例えば、それぞれの移動メッシュノードＡ〜Ｄは、直接接続された隣接するノードに対して自らを認証する。

互いに認証し証明書を交換した後、移動ノードピアは、ホップごとにマルチキャストトラフィックを暗号化する。このため、誤ってラジオレンジ３６６内のリスナに到達した移動ノードピアに宛てられたマルチキャストトラフィックは明文ではない。悪意のあるリスナ３６４は、まず、以前のホップによって送信された暗号化されたマルチキャストパケットを破らなければならない。この暗号化は、メッシュノードＡ〜Ｄとランデブ２８０（図２０）の間で確立されたトンネルを横断して行われる。

加えて、マルチキャストパケット２５０のソースによって使用された暗号化スキームの特定のタイプを特定するために、eMFCヘッダ２５１に暗号化識別子２６２を任意に含めてもよい。

QoS拡張
サービス品質（QoS）の実施は、モバイルメッシュネットワークのように、帯域幅が限られ、混信の可能性がある無線環境においては特に重要である。拡張MFC２１２は、パケット優先順位づけ、承認制御、およびトラフィック整形などのトラフィック計測および実施手段を通じて品質サービスをサポートしている。eMFC２１２に気づいているアプリケーションは、アプリケーションパケットをよく知られたカテゴリにマークすることにより、これらのQoS特徴をサポートしている。レガシーアプリケーションパケットは、デフォルトでは「ベストエフォート」としてマークされている。

さらに説明すると、図２８は、それぞれマルチキャストパケット２５０を伝送および受信可能な多数のメッシュノード２７０を示している。１以上のメッシュノードは、受信したパケットに関してQoS決定をすることができる。例えば、マルチキャストパケット２５０をPDAノード２７０Ｂに送信する車両内にノード２７０Ａを配置することができる。同時に、ＰＣメッシュノード２７０Ｃおよび２７０Ｄも、マルチキャストパケット２５０をPDAノード２７０Ｂに送信することができる。残念なことに、PDAノード２７０Ｂは、ノード２７０Ａ、２７０Ｃ、および２７０Ｄ.から受信したマルチキャストパケットのすべてを処理および転送する能力を有してない場合がある。この場合には、QoS操作３７０においてパケット２５０の一部をドロップする必要がある。あるいは、PDAノード２７０Ｂが、受信したパケット２５０の一部またはすべての処理順序に優先順位をつけてこれらを処理する場合がある。

eMFC２１２によって扱われたマルチキャストパケットは、トラフィックカテゴリ２６０（図１７）に従って優先順位がつけられる。トラフィックカテゴリの例は図３０の優先順位テーブルに示されている。eMFC伝送キューが満杯になりすぎると、トラフィックカテゴリ２６０によって特定されるドロップ優先順位を用いてパケットがドロップされる。例えば、ビデオフレームを構成するすべてのビデオパケットを個々に単にドロップするのではなく、一度にドロップしてもよい。また、eMFC２１２は、IETFにより定義された適切な分化サービスフィールドコードポイント（DSCP）ビットでマルチキャストパケットをマークすることができる。これにより、802.11iインタフェイスのようなトラフィック優先順位づけをサポートするインタフェイスによってeMFC２１２の下のさらなる優先順位づけが可能となる。

図２９は、図２８のノード２７０における拡張MFC２１２がどのようにしてQoSサービスを行うために使用されるのかをより詳細に説明するものである。ブロック３８０において、ノード２７０が異なるトラフィックカテゴリについての優先順位テーブルにより構成される。優先順位テーブルの一例は図３０に示されており、上述したDDSシステムを用いて異なるノード２７０に配信してもよい。

ブロック３８２において、拡張MFC２１２がピアからマルチキャストトラフィックを送信および受信するとき、マルチキャストトラフィックに関してホップごとにリンク品質も測定する。これは、eMFC２１２を実行するそれぞれの直接接続ピアメッシュノードに対してうまく送信および受信されたマルチキャストパケットの数を追跡することによりなされる。これらの測定は、ブロック３８４において、eMFCヘッダ２５１（図１７）のルータID２５４、宛先アドレス２５６、宛先ポート２５８、連続番号２５６、およびトラフィックカテゴリ２６０の異なる組み合わせによりなされる。マルチキャストテーブル計算コンポーネント２２２（図１６）によって計算されたリンクコストは、リンク容量、リンク品質、および時間平均ルータとして機能しようとするノードの意欲の組み合わせである。

最終メトリックは、これらのファクターとCPUスピード、合計メモリ、およびバッテリ容量などのプラットフォーム特性との組み合わせである。リンク品質が変化するとき、リンクコストはその変化を反映し、マルチキャストテーブル計算コンポーネントはマルチキャスト転送キャッシュエントリを計算するときにより良いメトリックを有するそれらのリンクを好む。

それぞれのリンクメトリック、トラフィックカテゴリ分布、および最大リンク容量がブロック３８４において得られたとすると、eMFC２１２は、必要に応じてマルチキャストレート制限を課す。ネットワーク管理により設定されたマルチキャストパケットに対するトラフィック制限に関するポリシーがeMFC２１２により適用される。例えば、モバイルメッシュネットワークにおいて許容されるビデオトラフィックの量に関するサービス品質保証契約（SLA）を適用して、マルチキャスト伝送中に各ホップにおいて許されるビデオトラフィックを制限することができる。この制限を超えたビデオソースは、最初のeMFC２１２を越えては許されず、モバイルメッシュネットワークに過度のトラフィックをかけさせないようになっている。

例えば、ブロック３８６におけるeMFC２１２は、図１７のトラフィックカテゴリ２６０を介してブロック３８６におけるビデオトラフィックを特定する。eMFC２１２は、ブロック３８４において、ルータID２５４および対応する連続番号２５６に従って、ビデオトラフィックのソースおよびそのソースから受信したビデオトラフィックの量を特定する。
その後、eMFC２１２は、ブロック３８８において、図３０に示される優先順位テーブルに従って、ビデオトラフィックの処理の優先順位をつける。図３０の優先順位テーブルに示されているように、最も高い優先順位は異なるタイプの低帯域幅制御トラフィックに対して与えられる場合がある。ビデオデータのような大きなデータトラフィックには低い優先順位が与えられる場合がある。eMFC２１２は、受信したトラフィックの量に従って、ビデオトラフィックの一部または全部の処理をドロップまたは遅らせてもよい。

他の実施例においては、宛先アドレス２５７および宛先ポート２５８によって特定されたマルチキャストグループが、異なる優先順位レベルを有していてもよい。これにより、監督者や緊急用人員などの特定のユーザからのメッセージを、他のユーザよりも高い優先度で送信することが可能となる。このように、特定のユーザのグループに異なる優先順位レベルを割り当てるために、ルータID２５４、宛先アドレス２５７、宛先ポート２５８、およびトラフィックカテゴリ２６０の組み合わせが用いられる。

eMFC２１２は、マルチキャストセッションの数、セッションごとのスループット、またはセッションごとのマルチキャスト参加者などのマルチキャストセッション特性を適用することができる。ブロック３９０において、eMFC２１２は、特定のソース（ルータID）、宛先アドレスおよび／またはポートから受信したパケット、または特定のトラフィックカテゴリを有するパケットのような特定のタイプのデータに対する統計を追跡することができる。この統計は、特定のタイプのトラフィックに対して受信したパケットの量およびうまく処理やドロップなどがなされたそのタイプのトラフィックの割合を特定することができる。

図３１は、eMFC２１２を行うために用いられるメッシュノード２７０内部のコンポーネントを示している。中央処理装置（CPU）４０２は、eMFC２１２操作を実現するソフトウェアにアクセスする。CPU４０２は、トランシーバ４０４およびアンテナ４０６を介してマルチキャストパケットを送信および受信する。メモリ４０２は、上述したマルチキャストルーティングテーブルおよび優先順位テーブルを含んでいてもよい。

レガシーマルチキャストサポート
拡張MFC２１２は、eMFCヘッダ２５１とともに生成されたマルチキャストトラフィックおよびeMFCヘッダ２５１なしに生成されたマルチキャストトラフィックの双方をサポートしている。このため、eMFCは、レガシーマルチキャストアプリケーションおよびeMFCを用いて書かれたアプリケーションの双方をサポートしている。すべてのマルチキャストアプリケーションがeMFC２１２の特徴を利用するわけではない。その結果、レガシーマルチキャストアプリケーションのサポートがeMFCに組み込まれる。このレガシーソースおよび受信者情報を用いることで、eMFC２１２はマルチキャスト転送キャッシュ２２４（図１６）を設定し、eMFC２１２に従ってマルチキャストソースアプリケーションからマルチキャストパケットを転送する。eMFCヘッダ２５１なしで受信したレガシーマルチキャストパケットは、そのマルチキャストグループに対して登録されたアプリケーションに直接渡される。

eMFC２１２をホストしているメッシュノード上で実行しているレガシーマルチキャストアプリケーションは、標準マルチキャストソケットAPIコール２１７（図１６）を用いている。これらのコールは、eMFC２１２によって傍受され、示され、広く知らされる。モバイルメッシュネットワークにおいてeMFC２１２をホストしていないノード上で実行しているレガシーマルチキャストソースは、eMFC２１２を実行している隣接ノードによって検出される。そのようなマルチキャストソースの例は、ビデオマルチキャストトラフィックを送信するメッシュ内のカメラである。eMFC２１２を実行していないモバイルメッシュネットワークにおけるノード上で実行しているマルチキャスト受信者は、各々のマルチキャスト受信者により発行されたIGMPメッセージを介して検出される。レガシーマルチキャスト送信者および受信者情報は、グローバル状態として伝播される。レガシーマルチキャストパケットは、サービスクラスのデフォルト品質である「ベストエフォート」受け渡しのためにマークされる。

上述したシステムは、専用プロセッサシステム、マイクロコントローラ、プログラム可能論理装置、または動作の一部または全部を行うことができるマイクロプロセッサを用いることができる。上述した動作の一部をソフトウェアにより実現し、他の動作をハードウェアにより実現してもよい。

簡便のため、様々な相互接続された機能的ブロックまたは別個のソフトウェアモジュールとして上記動作を述べている。しかしながら、これは必要ではなく、これらの機能的ブロックまたはモジュールが、単一の論理装置、プログラム、または明確な境界のない動作に等価的にまとめられる場合がある。いずれにしても、機能的ブロックまたはソフトウェアモジュールまたはフレキシブルインタフェイスの特徴をそれら自身によって、あるいはハードウェアまたはソフトウェアにおける他の動作との組み合わせによって実現することができる。

本発明の原理をその好ましい実施形態について述べ示してきたが、そのような原理から逸脱することなく、本発明の構成上および詳細において改良することができることは明らかであろう。我々は、以下のクレームの精神および範囲内にあるすべての改良および変形を請求する。

図１は、メッシュネットワークの図である。 図２は、メッシュネットワークに設けられたデータ配信サービス（DDS）のブロック図である。 図３は、ソースデータパケットの図である。 図４は、図２に示されたソースノードのブロック図である。 図５は、図２に示された受信者ノードのブロック図である。 図６は、異なるDDSメッセージを示す図である。 図７は、DDSによって提供される異なる通信シナリオを示すものである。 図８は、DDSによって提供される異なる通信シナリオを示すものである。 図９は、DDSによって提供される異なる通信シナリオを示すものである。 図１０は、DDSによって提供される異なる通信シナリオを示すものである。 図１１は、DDSによって提供される異なる通信シナリオを示すものである。 図１２は、従来のネットワークトポロジを示すものである。 図１３は、図１に示される従来のネットワークにおけるノードのユニキャストパスを示すものである。 図１４は、マルチキャストソースＡおよび宛先Ｂ，Ｃのマルチキャストパスを示すものである。 図１５は、隠れノード問題.を示す３つのメッシュノードを示すものである。 図１６は、拡張MFCシステムアーキテクチャを示すものである。 図１７は、拡張MFC（eMFC）パケットヘッダを含むマルチキャストパケットを示すものである。 図１８は、メッシュネットワーク内の異なるノード間で図６のマルチキャストパケットがどのように送信されるかを示すものである。 図１９は、eMFCヘッダ中の異なるフィールドを示す表である。 図２０は、異なるメッシュネットワーク内でマルチキャストパケットをどのようにしてオーバーレイできるかを示すブロック図である。 図２１は、メッシュノードが、メッシュインタフェイス情報に従ってどのようにマルチキャストパケットを転送するかを示す図である。 図２２は、メッシュノードが、メッシュインタフェイス情報に従ってどのようにマルチキャストパケットを転送するかを示す図である。 図２３は、メッシュノードが、メッシュインタフェイス情報に従ってどのようにマルチキャストパケットを転送するかを示す図である。 図２４は、メッシュネットワークにおいて重複マルチキャストパケットがどのように取り扱われるかを示す図である。 図２５は、メッシュネットワークにおいて重複マルチキャストパケットがどのように取り扱われるかを示す図である。 図２６は、メッシュネットワークにおいて重複マルチキャストパケットがどのように取り扱われるかを示す図である。 図２７は、メッシュノードのラジオレンジ内の悪意のあるリスナを示す図である。 図２８は、eMFCを用いてサービス品質（QoS）操作を行う方法を示すものである。 図２９は、eMFCを用いてサービス品質（QoS）操作を行う方法を示すものである。 図３０は、eMFCを用いてサービス品質（QoS）操作を行う方法を示すものである。 図３１は、メッシュノードの１つにおけるコンポーネントのブロック図である。

Claims (21)

1. ネットワーク処理装置に含まれるデータ項目に関連づけられたデータ配信サービス（DDS）メッセージを送信するプロセッサを備え、前記DDSメッセージは、前記ネットワーク処理装置における多数の異なるデータ項目に対する修正状態に関連づけられたグローバル修正値と、個々のデータ項目に対する修正状態を特定するデータ−修正番号とを特定する、ネットワーク処理装置。
2. 前記プロセッサは、メッシュネットワークにわたって伝送されたマルチキャストパケットに対してマルチキャスト転送ヘッダ（MFH）を提供する拡張マルチキャスト転送プロトコルを操作し、前記MFHは、送信ノードに関連づけられたインターネットプロトコル（IP）アドレスとは関係のない送信ノード用装置識別子を含み、さらに、同一のマルチキャストグループに関連づけられたメッシュネットワーク内のノードを特定するマルチキャストグループ識別子を含む、請求項１に記載のネットワーク処理装置。
3. 前記プロセッサは、STATUSメッセージを送信し、該STATUSメッセージは、該STATUSメッセージを送信しているネットワーク処理装置と、特定されたネットワーク処理装置におけるデータ項目に対する最後の修正に関連づけられたグローバル修正値とを特定するものである、請求項１に記載のネットワーク処理装置。
4. 前記プロセッサは、DATAメッセージを送信し、該DATAメッセージは、
   該DATAメッセージを送信しているノードと、
   該DATAメッセージを送信しているノードに対するグローバル修正値と、
   該DATAメッセージに含まれているデータ項目を特定するデータ−名前と、
   前記データ項目に対するデータ−修正値と、
   前記データ−名前により特定された実際のデータ項目と、
   を特定するものである、請求項１に記載のネットワーク処理装置。
5. 前記プロセッサは、うまく受信できなかったデータに対するグローバル修正値を特定する否定応答（NACK）メッセージを受信する、請求項１に記載のネットワーク処理装置。
6. 前記NACKメッセージは、前記特定されたグローバル修正値に関連づけられたネットワーク処理装置を特定するものである、請求項５に記載のネットワーク処理装置。
7. 前記NACKメッセージは、うまく受信できなかった同一または異なるデータ項目にそれぞれ関連づけられた多数のグローバル修正値のグループを含む、請求項５に記載のネットワーク処理装置。
8. 前記プロセッサは、前記NACKメッセージにおいて特定されたグローバル修正値と、データ項目を特定するデータ−名前と、前記特定されたデータ項目に対するデータ−修正番号とを特定するCHANGEメッセージを送信する、請求項５に記載のネットワーク処理装置。
9. 前記プロセッサは、再送信が要求される前記CHANGEメッセージ中のデータ−名前を特定するRETRANSMITメッセージを受信し、前記プロセッサは、該RETRANSMITメッセージに応答して、前記特定されたデータ−名前に対するデータ項目を含むDATAメッセージを送信する、請求項８に記載のネットワーク処理装置。
10. 前記プロセッサは、前記NACKメッセージ中のグローバル修正値に関連づけられたデータ項目の最終バージョンに対してのみ、前記CHANGEメッセージ中のグローバル修正値および関連データ−名前を送信する、請求項８に記載のネットワーク処理装置。
11. 前記プロセッサは、前記データ項目に対するタイムスタンプを保持し、期限切れのタイムスタンプを有するデータ項目に対して要求された更新に対してEXPIREDメッセージを送出する、請求項８に記載のネットワーク処理装置。
12. 前記プロセッサは、前記MFH中のトラフィックカテゴリ、優先順位テーブル、装置識別子、マルチキャストグループ識別子、および連続番号に従って、前記マルチキャストパケットの優先順位づけを行う、請求項２に記載のネットワーク処理装置。
13. 前記プロセッサがマルチキャストパケット処理の優先順位づけに用いる前記優先順位テーブルおよびマルチキャストルーティングテーブルは、前記DDSメッセージを用いて前記ノードに自動的に配信される、請求項１２に記載のネットワーク処理装置。
14. メッシュネットワーク内の隣接するノードと論理固定無線通信を行い、さらに前記メッシュネットワーク内の他のノード間でメッセージを転送するホップを提供する多数の移動ノードを備え、前記ノードは、メッシュネットワークルーティングテーブルおよびマルチキャストパケット中のメッシュベースのマルチキャストヘッダの双方に従って、異なるノード間でマルチキャストパケットを転送するメッシュマルチキャストプロトコルを提供する、アドホックメッシュネットワーク。
15. 前記マルチキャストパケットを送信した特定の装置に関連づけられたマルチキャストヘッダ中に装置識別子を含み、該装置識別子は、前記メッシュネットワーク内、および前記メッシュネットワークの外部の異なる位置に前記装置が移動したときに変化しない、請求項１４に記載のネットワーク。
16. 前記マルチキャストヘッダ中に、同一のマルチキャストグループのメンバである前記メッシュネットワーク内のノードを特定するソースルータID、マルチキャスト宛先アドレスおよびポートアドレスを含む、請求項１５に記載のネットワーク。
17. 前記マルチキャストヘッダ中に、同一のノードから送信され該ノードに返信された重複マルチキャストパケットを特定するために前記装置識別子と組み合わせて用いられる連続番号を含む、請求項１５に記載のネットワーク。
18. 前記マルチキャストヘッダ中に、前記ノードがパケットの処理および前記メッシュネットワーク内の他のノードへの転送の優先順位づけを行うために使用されるトラフィックカテゴリを含む、請求項１４に記載のネットワーク。
19. 前記メッシュネットワーク内の異なるノードに自動的に配信され、前記マルチキャストパケットの処理および転送の優先順位づけを行うために、前記マルチキャストヘッダ中の装置識別子、連続番号、マルチキャストグループアドレス、および前記トラフィックカテゴリと組み合わせて用いられる優先順位テーブルおよびマルチキャストルーティングテーブルを含む、請求項１８に記載のネットワーク。
20. 異なるノードに位置する異なるデータ項目のグループに対する変化を追跡し、前記異なるノード上の前記データ項目のバージョンを一定に保持するためのグローバル修正値（GRV）を用いたDDSメッセージを送信および受信するデータ配信サービス（DDS）を操作するノードの少なくとも一部を含む、請求項１４に記載のネットワーク。
21. 前記DDSメッセージは、前記GRVに関連づけられた個々のデータ項目に対するデータ−修正値を特定し、前記マルチキャストパケットの処理および転送の優先順位づけを行うために、前記マルチキャストヘッダ中の装置識別子、連続番号、マルチキャストグループアドレス、および前記トラフィックカテゴリと組み合わせて用いられる優先順位テーブルおよびマルチキャストルーティングテーブルを前記異なるノードに配信するために用いられる、請求項２０に記載のネットワーク。

Images