JP2011523290A - 無線マルチホップ・ネットワーク内にあるノード用のネットワーク・インタフェース・ユニット、及び無線マルチホップ・ネットワーク内にあるノード間にネットワーク・パスを確立する方法 - Google Patents

Abstract

本発明は、無線マルチホップ・ネットワークWN内にあるノードD、D1、D2、D3、Da、Db、Dcに対するネットワーク・インタフェース・ユニット10について記述している。
無線マルチホップ・ネットワークWNは、ソース・ノードと目的地ノードとの間に、ネットワーク・パスにより接続されることができる複数のノードD、D1、D2、D3、Da、Db、Dcを有し、当該ネットワーク・インタフェース・ユニット10は、ソース・ノードDの複数ルートのリクエスト・メッセージMREQが、ネットワーク・パスが確立されねばならない特定の複数の目的地ノードD1、D2、D3に対する複数のアドレス41、43、45を含むよう、複数ルートのリクエスト・メッセージMREQを組み立てるための複数ルートのリクエスト組立てモジュール11を有する。ネットワーク・インタフェース10は更に、メッセージMREQを無線マルチホップ・ネットワークWN内の他のノードD1、D2、D3、Da、Db、Dcへと送信するための送信ユニット12を有する。本発明はまた、無線マルチホップ・ネットワークWN内で、斯様なネットワーク・インタフェース・ユニット10を用いてソース・ノードDと複数の目的地ノードD1、D2、D3との間にネットワーク・パスを確立する方法も記述している。

Description

本発明は、無線の多重ジャンプ型の（無線マルチホップ）、好ましくはメッシュ、ネットワーク中のノード用のネットワーク・インタフェース・ユニットに関し、及び、無線マルチホップ・ネットワーク中、好ましくはZigBeeネットワーク中にあるノード間にネットワーク・パスを確立する方法に関する。

自己組織する態様で働くマルチホップ・ネットワークは、産業用の制御、ビルの自動化、埋め込み検出等など、多くの分野において、見出されたアプリケーションである。ネットワーク中のデバイスは、低出力で低コストの電波を用いた無線の態様で、お互いに通信する。本線の接続が無線のデバイス間通信に対しては必要とされないので、これはデバイスの配置において、より多くの自由度を許容する。

急速に確立されてきた斯様なネットワークの無線制御の規格が、ZigBee アライアンスにより開発されたZigBee規格である。ZigBee規格は、低出力のデジタル無線を使用した、デバイス間の高レベルの通信を記述しており、無線パーソナル・エリア・ネットワークWPANsに対する物理PHY層及び媒体アクセスMAC層を順番に定めているIEEE 802.15.4規格に基づいている。

マルチホップ・ネットワークの例は、ランプ、スイッチ、換気扇、運動センサ等など、様々なタイプのデバイスを備えたビルの自動化ネットワークである。各々がネットワークの「ノード」である（即ち、無線インタフェースを備えている）これらのデバイスは、自身をネットワーク内に組織できる。当該ネットワークでは、1つのデバイスがコーディネータとして働き、全ての他のデバイスが「ルータ」又は「端末デバイス」である。ルータは、端末デバイスとは対照的に、中間ノードとして働き、1つのノードから別のノードへとメッセージを通過させることができる。例えば、室内の複数のランプが、ルータ能力を有するスイッチにより制御される端末デバイスであることが出来る。

斯様な無線ネットワーク中のデバイス又はノードは、メッセージ又はネットワーク・コマンドをフレームの形式で交換することによって、通信する。フレームの構造が適切な仕様で用意され、例えばフレームは、通常、ヘッダ及び（データエリアである）ペイロードを有し、フレーム内の特定の「場所」にある特定のフィールドは、受信側に、とりわけ、通過した命令（コマンド）のタイプを通知できる。このタイプの、低出力で低コストのネットワークで使用する送信器の無線範囲が限定されるので、メッセージは送信デバイスから遠隔の受信デバイスまで、「マルチホップ」経路選択と呼ばれる態様で、中間デバイスを用いて送られることが可能である。更に遠くに目標ノードの場所があり、多数の「ホップ」がメッセージを届けるために使われることであろう。メッセージを（目標ノードとも呼ばれる）目的地のノードに送信する前に、（開始ノード又は発信ノードとも呼ばれる）ソース・ノードは、目標ノード又は目的地ノードへのネットワーク・パスを最初に確立しなければならない。即ち、ソース・ノードは、目的地ノードまでのルートを最初に発見しなければならない。マルチホップ・ネットワークでは、ソース・ノードは、可能性がある全てのルートを通じて目的地ノードに接続することができよう。明らかに、少ない数の中間ノードをもつルート、従って、各々が満足できるリンク品質をもつ少ない数の「ホップ」をもつルートが、より多数のホップ又はより弱いリンクを有するルートよりも好ましい。多くの技術が、ソース・ノードから目的地ノードまでの最適ルートを決定する際に援助するために開発されてきた。

現行の規格を用いて、例えばAODV（アドホック・オンデマンド距離ベクトル）経路選択の技術を用いて実施されるルートの発見は、まさしくリソースを消費する作業である。ルート・リクエスト・コマンドRREQsが、当該コマンドが目的地に到達したとの事実にもかかわらず、ソースから（TCP／IPネットワークでは有効期限TTLと呼ばれている）規定された範囲内にある、あらゆるルータによって、再ブロードキャストされる。更にまた、（マルチホップ無線など）共有の媒体ベースの通信のために特に使用されるブロードキャストの信頼性を増すための技術が、一回のルート発見リクエストから生じるパケットの数を更に増加させる。この例が、ZigBee規格で使われている受動的な承認テクニックであり、ルータは、RREQパケットを再ブロードキャストした後に、全ての隣接するルータが更に当該パケットを再ブロードキャストしたかどうかを調べるために、所与の時間の間はトラックを保ち、少なくとも1つのルータが再ブロードキャストしなかった場合、ルータは新たにRREQパケットを送信する。更にまた、より良いパス・コストを有するパスを通じて同じRREQパケットを受信すると、当該パケットが、新たに再ブロードキャストされねばならない。明らかに、各メッセージは、メッセージが意図しない多数のノード、例えば、ソース・ノード並びに目標ノードの両方から遥かに離れているノード、及びソース・ノードと目標ノードとの間に位置していないノードにも到着することであろう。結果は「ブロードキャスト・ストーム」と呼ばれる、−大きなネットワークでは− 数秒間持続する、通信量の少なからぬ突出である。帯域幅の限界と、一回のルート発見リクエストの結果として誘発される高水準の通信量とに起因して、パケットが衝突することがあり、当該リクエスト及び応答が配信されることはなく、リクエストは機能しないことがある。ルート発見リクエストの配信が成功した場合であっても、ブロードキャスト・ストームから生じた衝突又は媒体の占有が、（通常、発見されたパスに沿ってソース・ノードにユニキャストされる）目的地の確認ルート応答パケットがソース・ノードに到達するのを妨げ、この結果、ルート発見は最終的に失敗する。この事は、開始ノードが全ルート発見の手順を繰り返すことを強い、即ち、別のブロードキャスト・ストームが始まる。

更にまた、現行の規格に従ったルート発見は、ソース−目的地のペア（対）ごとに独立して行われなければならない。即ち、ノードが1つの他のノードまでのルートを必要とするたびに、ブロードキャスト・ストームが誘発される。複数の他のノードまでのルートの確定を必要とするノードに対して、上記は、（例えば、照明制御ネットワークのスイッチを入れる）アクションと、意図された反応（このスイッチにより制御されている全てのライトを点灯する）との間の顕著な遅延に至ることがある。また、ブロードキャスト・ストームから生じる高水準の通信量は、ルート発見プロセスの非効率性に至るだけではなく、重要なアプリケーション層のコマンドをブロックすることもあり、結果としてこれらのコマンドが再び発出されることを必要とする。

明らかに、ルート発見におけるこれらの非効率性に対抗する1つの態様は、ネットワーク中の各デバイスが、ネットワーク・ツリー若しくはネットワーク・メッシュ又は自身の地理的位置を認識し、コマンド又はデータ・パケットを送信すべきデバイスの位置を認識していることであろう。明らかに、斯様な情報はデバイスが移動する度又は交換される度に変化することであろう。特に大きなネットワークでは、斯様な位置情報の手動による設定は実行不可能であり、これらの対策が毎日実行されることを必要とさえするかも知れず、結果として高水準の保守要因及び容認できないコスト要因となる。更にまた、パスのデータが提供されねばならないか、又は特別な位置に基づく経路選択アルゴリズムが用いられなければならない。他方、ツリー状の経路選択メカニズムは、通常あまりに長いルート、従って、次善の、場合によっては負担をかけ過ぎるルートであり、ルート上にある1つのノードが（一時的に）機能しない場合、バックアップの可能性がない。ZigBeeにより実施されるツリー状の経路選択メカニズムは、考え得るネットワーク・トポロジを限定し、且つより大きなネットワークに対しては実行不可能であるCskipツリー・アドレス指定法に基づいている。他のツリー・ベースの経路選択メカニズムは、覆われたツリー構造の確立及び保守のために、莫大な通信労力と演算労力とを必要とする。後者については、自己管理型の無線ネットワークの長所− 柔軟性及び使いやすさ−が、事実上無効にされる。明らかに、ツリー状の経路選択は実行可能な解決案ではない。

これ故、上記で概説された課題を回避すると共に、マルチホップ・ネットワークにおけるルート発見を実行する、より効率的な方法を提供することが本発明の目的である。

このために、本発明は、無線マルチホップ・ネットワーク中、好ましくはZigBeeネットワーク中にあるノードに対するネットワーク・インタフェース・ユニットを記述している。当該ユニットは、ソース・ノードと目的地ノードとの間に、ネットワーク・パスを用いて接続されることができる複数のノードを有し、ネットワーク・パスは、ソース・ノードから目的地ノードへと構築され、当該ネットワーク・パスは複数の中間ノードを通過する。ネットワーク・パスは、複数の隣接ノードとの間の複数の物理的な接続から成る（以下では、ネットワーク・パスは、単に「ルート」とも呼ばれる）。通常、マルチホップのメッシュ・ネットワークでは、複数の中間ノードがソース・ノードと目的地ノードとの間にあるが、しかし、ソース・ノードが目的地ノードの直接隣にあり、中間ノードが必要とされない（したがって、ルート発見動作が実行されてはならない）場合もあり得る。本発明によるネットワーク・インタフェース・ユニットは、ソース・ノードの複数ルートのリクエスト・メッセージが、ネットワーク・パスが確立されねばならない特定の複数の目的地ノードに対する複数のアドレスを含むよう複数ルートのリクエスト・メッセージを組み立てるための、複数ルートのリクエスト組み立てモジュールを有する。ネットワーク・インタフェース・ユニットは、メッセージを無線マルチホップ・ネットワーク中の他のノードに送信するための送信ユニットも有する。

ネットワーク中のルート発見の観点からは、ノードは、ルートの開始時ではソース・ノードであり、ルートの終端では目的地ノードであり、又はソース・ノードと目的地ノードとの間では中間ノードであり得る。ソース・ノードは、「ルート・リクエスト」として知られるネットワーク層のコマンドをブロードキャストすることにより、ルート発見手順を開始する。目的地ノードは、ルート・リクエスト中で指定されたアドレスを備えたノードである。中間ノードは、ソースと目的地間のルート上のポテンシャル・ノードとして、ルート・リクエスト・メッセージを受信（及び再送信）する、すべての他のノードである。上述のように、従来のルート発見技術では、ルート・リクエストは、1つの目的地までのルートを発見することに限定され、この結果、ネットワークは、確立されねばならない各ルートに対して少なくとも一回はオーバーフローするにちがいない。このように、各々が複数のアプリケーション層の接続をもつ、何百箇所以上のノードを含む大きなネットワークでは、ネットワーク中の他の通信を事実上ブロックするか又は厳格に阻止する、何千もの、ルート発見の際のブロードキャスト・ストームがあることだろう。更にまた、数百のノードを含む大きなネットワークに対しては、ブロードキャスト・ストームが数秒間持続することがあり、例えば、ユニキャストされたルート応答パケットと、依然として再ブロードキャストされているルート・リクエスト・メッセージとの衝突、又は別の発信者からのブロードキャスト・ストームとの衝突に起因して、目的地へのルート発見が不成功である場合、ネットワークの低信頼性により貢献さえする、ルート発見の全手順が繰り返されなければならない。

本発明によるネットワーク・インタフェースがあると、ソース・ノードに対するルート・リクエストは、当該ソース・ノードと、1つではない、複数の目的地ノードとの間にネットワーク・パスを確立するために必要とされる全ての情報を含む。本発明によるネットワーク・インタフェースを用いる事によって、一回のルート・リクエストを用いて、ルートが、ソース・ノードから複数の目的地ノードまで確立され、従って一回のブロードキャスト・ストームを起こすに過ぎない。即ち、ネットワークは一度オーバーフローすることのみが必要とされる。明らかな長所は、ネットワーク中の保守通信量の減少であり（多数の代わりに一回のルート・リクエストのブロードキャスト・ストームですむ）、したがって、全体のネットワークの信頼性が改善される。別の明らかな長所は、少なからぬ時間が節約されるということである。何故ならば、ソース・ノードは、一回のリクエストで複数の目的地ノードまでのルートを確立できるからである。後述するように、ルート・リクエストを傍受したどの中間ノードも、複数のルートがソース・ノードによってリクエストされているとの表示を検知した場合、これに応じて反応できる。本発明によるネットワーク・インタフェースの更なる考え得る長所は、ノードがより少数のパケットを送ることができるという点であり、したがって、バッテリで動作するデバイスの場合、バッテリのパワーを節約する。特にビーコンが可能なネットワークの場合、メッセージが通過するときにのみノードがアクティブにされ、本発明によるネットワーク・インタフェースによって、通信量の減少が可能にされ、当該ノードがすぐにスリープモード又は休止モードに戻れることにより、バッテリ駆動のノードの寿命をかなり延長できる。

無線マルチホップ・ネットワーク中のソース・ノードと複数の目的地ノードとの間にネットワーク・パスを確立する適切な方法は、複数ルートのリクエスト・メッセージを組み立てるステップを含む。当該複数ルートのリクエスト・メッセージは、ネットワーク・パスが確立されねばならない特定の複数の目的地ノードに対する複数のアドレスを含んでいる。本方法は更に、複数ルートのリクエスト・メッセージを、無線マルチホップ・ネットワーク中の他のノードに送信するステップを含む。

少なくとも幾つかのノードでは、好ましくはネットワークのルータの全てが、複数ルートのリクエスト・メッセージの適切な処理を、例えばネットワーク・インタフェース中の適切な複数ルートのリクエスト処理モジュールにて、実行することができなければならない。

従属請求項及び以下の説明が、本発明の特に有利な実施例及び特徴を開示している。

以下においては、いかなる態様であれ本発明を制限することなく、無線マルチホップ・ネットワークは、ZigBee 2007規格に準拠した、ZigBeeコーディネータZC、ZigBeeルータZR及びZigBee端末デバイスZEDをもつZigBeeネットワークであるとみなされよう。もちろん、本発明は上記の規格のみに決して限定されるのではなく、IEEE802.11s又はZigBee規格の将来の開発版などの他の規格と共に使うことができる。用語「デバイス」及び「ノード」が、以下において交互に用いられることもある。ネットワーク・パケット・ペイロードの個々のフィールドの名前又はアプリケーション層の変数の名前など、以下で使用されている特定の用語は、ZigBee規格などの規格に精通している当業者には知られていることであろう。本発明によるネットワーク・インタフェース及び方法によって必要とされる新語又はフィールドは、明示されている。

ZigBeeネットワークにおいては、ZC、ZRのいずれかである開始デバイスがルート・リクエストを発令したとき、ルート発見が開始される。ZEDsがルート・リクエストを発令するのではなく、ZEDsはデータをZEDsの親に送るだけであり、親が次にルート・リクエストを作る。しかしながら、ZC及びZRのみが中間ノードとして働くことができ、ZEDsは経路選択及びルート発見には関与しない。ルート・リクエストは、構造がZigBee規格により規定されているデータ・パケットである。本発明によるネットワーク・インタフェース及びネットワーク・パスを確立する方法は、複数のルートが単一のパケット・ペイロード内で定められることが可能であるよう、ルート・リクエスト・パケット構造を適応させる（変更する）ことを提案している。本発明は、複数の目的地に関する情報を、新たな「複数ルートのリクエストMREQ」メッセージ内に含むよう、標準のルート・リクエストRREQメッセージを適応させる（変更する）ことを提案している。従って本発明の特に好適な実施例では、ネットワーク・コマンドのペイロード内にあるCommand Optionsフィールドの、従来使われていないビット（ビット7）が、このパケット中で、複数の目的地までのルートがリクエストされていることを示すために使われる。本発明は、このビットを「複数ルートのリクエスト」インジケータ・ビット又はフラグ、略して「MR」と呼ぶことを提案している。MRビット又はMRフラグが、ネットワーク・コマンドのペイロードのCommand Optionsフィールドに設定された場合、このコマンド・パケットを受信したネットワーク・インタフェースは、これに応じて後述するように反応することであろう。

複数ルートのリクエスト・メッセージのCommand Optionsフィールド内に新しく定められた「複数ルートのリクエスト」表示ビットに加えて、本発明による方法を用いて組み立てられたネットワーク・コマンドのペイロードは、好ましくは1バイトを有する「Multiple Requests」フィールドを含む。この新しいフィールドは、発見されねばならないユニキャスト・ルートの数及びマルチキャスト・ルートの数を定めている。例えば、「Multiple Requests」フィールド中の4ビットが、何本のユニキャスト・ルートが発見されねばならないかを示すために用いられることができ、「Multiple Requests」フィールド中の残りの4ビットが、最大15本のマルチキャスト・ルートが発見されねばならない事を示すことができる。ユニキャストされる目的地及びマルチキャストされる目的地の合計数は、パケット・ペイロードのサイズで設定された限度によって最終的に制限される。適正な規格では用意されているように、ネットワーク・コマンドのペイロードは（ネットワーク層のセキュリティが用いられる場合）最大81バイトまでに限定され、（ネットワーク層のセキュリティが用いられない場合）99バイトまでに限定される。ユニキャストされる目的地の各々は、合計最大12バイトを必要とし、短いアドレス用に2バイト、（知られている場合）長いアドレス用に8バイト、パス・コスト用に1バイト、及びルート・リクエストID用に1バイトを必要とする。その一方で、（長いアドレスがマルチキャストされる目的地には存在せず、短いグループ・アドレスのみであるので）マルチキャストされる目的地は4バイトを必要とする。好ましい実施例では、各々の目的地に対して1つのパス・コスト・フィールドをもつ代わりに、単一のパス・コスト・フィールドを全ての複数ルートのリクエストに対して使うことができる。この態様で、ペイロードは、より多くの目的地を収容できる。

ペイロード及びパケットの組み立ては、ネットワーク層の言語により起動され、当該ネットワーク層の言語は、マルチキャスト・アドレスのリスト、ユニキャスト・アドレスのリスト、ユニキャスト・ルート及びマルチキャスト・ルートの各々の数等などの必要とされるパラメータを、メッセージ・フレーム及びペイロード中の適切なフィールドをデータで満たすフレーム組み立てモジュールへと受け渡す。次に、当該フレーム組み立てモジュールは、全てのリクエストされた目的地に対して適切な経路選択テーブル項目をつくる。次に、組み立てられたメッセージが、送信のために下位層に渡される。組み立てられたメッセージは次に、ブロードキャスト（又は、制限されたブロードキャスト）を介してネットワークへと、ネットワーク・インタフェースの送信ユニットにより送信される。

明らかに、以下では「MREQ」とも呼ばれる、本発明による新たな多数ルートのリクエスト・メッセージは、当該メッセージを受信したいかなる中間ノードによっても、正しく解釈されなければならない。従って、本発明によるネットワーク・インタフェースの特に好適な実施例では、複数ルートのリクエスト・メッセージが中間ノードにより受信され、「複数ルートのリクエスト」表示ビットがセットされた場合、複数の目的地ノードの各々に対する経路選択テーブル項目と、RREQ IDの各々に対するルート発見テーブル項目とが、複数ルートのリクエスト・メッセージ中に含まれている目的地ノードのアドレスの各々に対して、前記中間ノードにより生成される。例えば、中間ノードが正しいノードへと応答を送り返すことができるように、これらのテーブル項目が中間ノードにより後で用いられる。これらのテーブル項目の目的及び使用は当業者に知られ、適切な規格により規定されており、ここで詳細に説明する必要はない。MREQフレームについて、複数ルートのリクエストのうちの1つの目的地が、同時に他の目的地に対する中間ノードであることに留意されたい。このように、自身を目標としたRREQに対するルート応答メッセージを作成した後に、ノードは、他の中間ノードと同様、経路選択テーブル項目及び他の目的地に対するルート発見項目も作らねばならず、且つ当該コマンドを再ブロードキャストせねばならない。最適化の1つとして、ノードは、再ブロードキャストする前に、自身を目的地リストから削除できる。

本発明の着想をより有利に使用するために、「重要な」デバイスへのルートが、率先して発見されることができる。例えば、多対一（many-to-one）の経路選択の場合、ブリッジ又はゲートウェイなどの集信器は、ZigBeeコーディネータ、結合キャッシュ、ネットワーク・マネージャ、信用センタ等、などの基盤デバイスに「気づいて」もよい。これらのノードは、ネットワーク中の多くの他のノードにとって興味があると思われるので、集信器は、全てのこれらの基盤デバイスまでのルートを、単一のルート・リクエストを使用して率先して確立できる。

デバイスの幾つかは複数のアプリケーション層の接続部、例えばZigBeeスイッチ、及び例えば、当該スイッチにより制御される（例えば起動又は停止される）複数のZigBeeデバイスをもっており、したがって複数のネットワーク層の接続を確立することを必要とする。例えば、照明スイッチは、当該スイッチに「属する」ランプ又は照明器具（概して同じ部屋にあるランプ）に対してアプリケーション層の接続をもつことが出来、他方、例えばHVAC（暖房、換気、及び空気調節）コントローラは、オフィスビルの複数の部屋の中にある空調ユニット等に対してアプリケーション層の接続をもつことが出来る。本発明による方法を使用して、斯様なスイッチは、全ての担当デバイスまでのルートを迅速に発見できる。スイッチに帰属するデバイスの数、即ちネットワーク・パケットのペイロードに含まれるアドレスの数に応じて、スイッチは1つ以上の多数ルートのリクエストを必要とする。

明らかに、全てのアプリケーション層の接続用のルートを発見するために、開始デバイスは、適切なアドレスを知っていなければならない。これ故、本発明の更なる好ましい実施例では、無線マルチホップ・ネットワーク中のノードのネットワーク・インタフェースは、設定インタフェースを有する。当該設定インタフェースを用いることにより、あるノードが、当該ノードが機能的に関連している他の特定のノードのアドレスを提供されることができる。例えば、適切なインタフェースを用いることにより、バインド情報の形式のデジタルデータが、デバイスのメモリにダウンロードされることができ、後の使用のために記憶されることができる。

冒頭で述べたとおり、従来のブロードキャスト・ストームは、ネットワーク内の衝突に起因して、ソース・ノードと目的地ノードとの間にルートを確立することに失敗する場合がある。ルート・リクエストが首尾よく目的地ノードに到着することができ、この目的地ノードがユニキャストのルート応答を、ルートを確認するために発出した場合でさえ、ネットワーク中の他のノードによって依然としてブロードキャストされているルート・リクエストに起因して、ルート応答メッセージが媒体と衝突、又は媒体にアクセスすることができないとき、ルート発見は依然として失敗する場合がある。これ故、本発明の特に好適な実施例では、ネットワーク・インタフェースは、ルート応答メッセージを少なくとも2回ソース・ノードへと発出するよう実現化されており、この結果、特に単純であるが効果的な解決案では、ルート応答がソース・ノードにうまく到着する可能性が劇的に増す。好ましくは、この反復は、例えば適切な反復間遅延値により規定されるように、時間的に分離されることができる。メッセージの送信が繰り返される回数は、例えば「nwkRouteReplyTransmission」と呼ばれる適切な変数として定められ、反復カウント値によって、例えば3回又は4回と規定されることが出来る。メッセージの送信が繰り返される時間間隔は、例えば「nwkRouteReplyTimeout」と呼ばれる適切な変数として定められ、例えば0.5秒にセットされることができる。

この着想の更なる発展型においては、ネットワーク・インタフェース・ユニットは、最初のルート応答メッセージを遅延の後に発出するよう、好ましくは実現化される。ルート応答を発出する前に短い間待つことによって、ブロードキャスト・ストームの（少なくともルート・リクエストのソースへと戻される）強度が減じる可能性はより高く、衝突又は使用中の媒体に起因するルート応答の失敗の可能性を少なくすることであろう。遅延値は予め規定されることが出来るか、又は設定可能な値であり得、予め規定される場合、本発明によるネットワーク・インタフェースに対して一定の値又は、ネットワーク・サイズ又は他のネットワーク・パラメータ（例えば子ルータの最大数nwkMaxRouters）に依存する、若しくはノードに対して利用できる他のデータ（例えばノード近傍のルータの密度）に依存する値をもつ、適切な変数によって定められることが出来る。例えば「nwkRouteReplyDelay」と呼ばれる提案された変数は、ZigBee規格により規定され、既に使用されている変数から得られる。変数の例は、承認タイムアウト、ブロードキャスト再試行、再試行間隔等などの制御手段に対しても用いられている変数である。例えば、nwkRouteReplyDelay変数に対する固定値は、以下のように得られる：
nwkRouteReplyDelay＝2×nwkPassiveAcktimeout×nwkBroadcastRetries
一方、ネットワークに依存する値は、
nwkRouteReplyDelay＝nwkMaxDepth×nwkcRREQRetryInterval
によって、与えられ、
ここで、変数nwkPassiveAcktimeout、nwkBroadcastRetries、
nwkMaxDepth、及び定数nwkcRREQRetryIntervalは、
ZigBee規格により規定されている。

好ましくはネットワーク・インタフェースは、斯様なデータ変数を記憶するための小型メモリなどの記憶媒体を有する。例えば当該メモリは、複数の目的地ノードのアドレス、及び/又はメッセージの送信を繰り返す回数に対する反復カウント値、及び/又はルート応答メッセージなどのルート応答メッセージの送信に先行する遅延値、を記憶する事が出来る。

明らかに、ルート応答の反復送信及び/又はルート応答の遅延送信が、複数ルートのリクエストに対する応答に限定されることはない。実際、これらの方法は、複数ルートのリクエストとは独立して適用されることができ、例えば、これらの方法は、周知の（単一）ルートのリクエスト・コマンドを使用してルートを確定する従来のZigBeeマルチホップ・ネットワークで適用されることができる。特に斯様なネットワークにとっては、時間及びエネルギの顕著な節約が実現できる。ルート・リクエストの失敗に至る衝突に起因して再度オーバーフローを必要とするネットワークの可能性はかなり低く、マルチホップ・ネットワーク中のデバイスは、エネルギをルート・リクエストの反復に費やしそうにはない。

概して、必要とされるにつれ、ルートは反動的に発見される。ルートが損壊されない限り（例えば中間ノードが機能しない場合、損壊は起こるかもしれない）、このルートは有効であると考えられる。明らかに、斯様な以前に確立されたルートの幾つかの部分又は全ての部分は、別の発信ノード及び目的地ノードの対によって再利用されることが出来、この結果、このノードの対に対するルート発見ステップでは、ネットワーク全体がオーバーフローする必要はない。これ故、本発明の更に好ましい実施例では、受信したノードが、ルート・リクエストで指定された目的地ノードへの、既に以前に確立されたネットワーク・パスの一部である場合、ルート・リクエスト・メッセージを受信するノードのネットワーク・インタフェース・ユニットは、ルート応答メッセージをルート・リクエストのソース・ノードへと発出するよう実現化される。これ故、目的地ノードへの既に確立されたルートを使用して、完全なルートがソース・ノードと目的地ノードとの間で発見されるであろうから、この受信したノードが更にルート・リクエストをブロードキャストすることは、もはや必要ではない。この態様で、ブロードキャスト・ストームはこの位置において終わることが出来、この結果、ルート発見プロセスが効果的に短縮される。

ブロードキャスト・ストームの継続時間を減じる別の態様は、ルート・リクエストを再送信する中間ノードの数を減じることである。即ち、ブロードキャスト・ストームの範囲を制限することである。これ故、本発明の更なる好ましい実施例では、ネットワーク・インタフェース・ユニットは、ソース・ノードにより発出されたルート・リクエスト・メッセージのブロードキャスト半径が、予め規定された範囲に限定されるよう実現化される。当該範囲は、メッセージを再送信する中間ノードの数であってもよく、この結果、ブロードキャスト半径が3の場合、例えば、ルート・リクエストは3個の中間ノードによって再送信されることができる。即ち、メッセージは、3番目の中間ノードがネットワーク中のパスを停止する前に3回「ホップ」する。目的地ノードがブロードキャスト半径外にあるのでルートの確立が機能しない場合、目的地ノードが見出され、ソース・ノードと目的地ノードとの間のルートが確立されるまで、この半径を拡大できる。

無線ネットワークは、種々異なるネットワーク・インタフェースを備えたデバイス又はノードを有することが出来る。例えば、幾つかのデバイスは本発明によるネットワーク・インタフェースをもつことが出来、残りのデバイスは従来のネットワーク・インタフェースをもっていることが出来る。しかしながら、ここで説明されたネットワーク・インタフェースの長所を最大限に活用するために、無線マルチホップ・ネットワークは、本発明による方法を適用できるネットワーク・インタフェースを各々がもっているデバイス又はノードを好ましくは有する。

本発明の他の目的及び他の特徴が、添付の図面に関連して考えられた以下の詳細な説明から明らかになることであろう。しかしながら、添付の図面は単に説明目的のためにだけ企てられ、本発明の範囲を規定するものとして企てられてはいないことを理解すべきである。

典型的な従来のネットワークのルート・リクエスト・コマンド・フレームの伝播を例示しているグラフである。 本発明の第1の実施例によるZigBeeのルート・リクエスト・コマンド・フレームの概略図を示す。 本発明の第2の実施例によるZigBeeのルート・リクエスト・コマンド・フレームの概略図を示す。 本発明の第3の実施例によるZigBeeのルート・リクエスト・コマンド・フレームの概略図を示す。 本発明の更なる実現化によるルート・リクエストのCommand Optionsフィールドを示す。 従来のルート応答パケットの従来のCommand Optionsフィールドと、本発明の実施例によるルート応答パケットのCommand Optionsフィールドとを示す。 本発明の考え得る実施例による無線マルチホップ・ネットワーク中のデバイスの概略図を示す。 図4aの無線ネットワークのマルチホップ・ネットワーク線図を示す。 本発明の実施例によるネットワーク・インタフェースのブロック線図を示す。 本発明の実施例による方法で使われる、関連ルート発見パラメータ値及びブロードキャスト配信パラメータ値と共にブロードキャスト半径値の表を示す。

図において、同様の数値は全体に同様の対象物を引用している。線図中の対象物は、必ずしも一定の縮尺で描かれてはいない。

図1のグラフは、630個のZRノードを有する従来のネットワークのルート・リクエストRREQメッセージの伝播を示し、各々の「＋」が、ノードによってブロードキャストされたRREQメッセージを示す。縦軸は、ソース・ノードにより発出された最初のRREQメッセージと、特定ノードによるRREQメッセージの送信との間で経過した時間を示し、横軸は、ソース・ノードからの特定ノードの距離をメートル（m）にて示す。グラフが示すように、ソース・ノードから最も離れた最後のノードまで、RREQメッセージを転送したブロードキャスト・ストームは強度が増す。最後のノードに達するまで、3.5秒が経過した。この時点で、ネットワークはRREQメッセージによってオーバーフローし、他のアプリケーションメッセージ又はこのRREQに対するルート応答メッセージさえ通じない場合がある。

図2aは、本発明の第1の実施例による多数のルート・リクエストのネットワーク・コマンドMREQの構造を概観的に示す。冒頭で述べたとおり、1つのノードから別のノードへと送られるネットワーク・コマンドは、当業者には知られているように、ネットワーク・ヘッダ1とネットワーク・ペイロード2とを有する。ネットワーク・コマンド・フレームは、NLME-MULTIROUTE-DISCOVERY.request言語に応答して、ネットワーク層のフレーム・アセンブラによって組み立てられる。略語「NLME」は、「Network Layer Management Entity」サービス・アクセス・ポイントのことである。当業者には知られているように、斯様な言語は、フレームを処理及び/又は造るために、当該言語が送信される層によって使われねばならないフィールド又はパラメータの値を定めている。以下は、当該言語によってフレーム・アセンブラへと渡される、本発明による変数のリストである：
NLME-MULTIROUTE-DISCOVERY.request
{
DstAddrMode,
ListOfMany-to-OneAddresses,
NoRouteCache,
ListOfMulticastAdresses,
ListOfUnicastAddresses,
Radius
}
ここで、DstAddrModeは、提供された目的地アドレスの種類及び数を定めている2バイトを有する。ビット3-0は、many-to-oneのルート発見用の16ビットの目的地アドレスの数を定めており、ビット7-4は、マルチキャスト・グループの16ビットのネットワーク・アドレスの数を定めており、ビット11-8は、個々のデバイスの16ビットのアドレスの数を定めており、ビット15-12は、予約済である。変数ListOfMany-to-OneAddressesは、many-to-oneアドレスのリストを含む。NoRouteCacheは、many-to-oneのルートが発見されねばならない場合、ルート記録テーブルが設けられねばならないか（真）、又はその必要はない（偽）かどうかを定めているブール値である。変数ListOfMulticastAdresses及びListOfUnicastAddressesは、アドレスのリストを含み、変数Radiusは、ルート・リクエストによって、ネットワーク中で行われるホップの回数を定めているオプションのパラメータである。

前記言語により提供された情報を用いて、フレーム・アセンブラは、図2に示すように、ヘッダ1及びペイロード2を備えた複数のリクエスト・メッセージMREQを組み立てている。例示目的のために、入れ子になっている機能的には異なる領域1、2、3、4が、異なる描影法により示されている。メッセージ・ヘッダ1は、とりわけ制御情報とセキュリティ情報とを供給しているフィールドの数を有する。ペイロード2は、続くコンテンツ3がコマンドのペイロード3であることを示すために、1バイト長のCommand Identifierフィールド20により示されている。コマンドのペイロード3は、1バイト長のCommand Options フィールド30で始まり、本発明による1バイト長のMultiple Requests フィールド31が続く。Command Optionsフィールド30及びMultiple Requestsフィールド31の内容が、図2の下部に示されている。Command Optionsフィールド30の最初の7ビット、即ちビット0-6は、ZigBee規格に準拠して通常の方法で解釈される。本発明によれば、このCommand Optionsフィールド30の最終ビット、ビット7は、本願明細書ではコマンドのペイロード3が複数のリクエストを含むことを示すために用いられる。続くMultiple Requestsフィールド31の最初の4ビットは、ユニキャストされるルートの数を示し、残りの4ビットは、この複数ルートのリクエストMREQメッセージと共に発見されねばならないマルチキャストされるルートの数を示すために用いられる。ネットワーク・フレームのペイロードのサイズは、ZigBee-2007規格では合計82バイトと限定されており、この結果、本発明による複数ルートのリクエストを用いて発見されることができるユニキャスト・ルートの数及びマルチキャスト・ルートの数も限定される。ネットワークCommand Identifierフィールド、Command Optionsフィールド、及びMultiple Requestsフィールド用に3バイトが必要とされるので、79バイトのペイロードが、ユニキャスト・ルート・リクエスト/マルチキャスト・ルート・リクエスト用に残る。

ペイロード2の残りの4ビットは、ユニキャスト・ルート・リクエストとマルチキャスト・ルート・リクエストとに対するリクエストID、パス・コスト、及びアドレス情報を有する。

本実施例では、各々のユニキャスト・ルート・リクエストは合計12バイトを必要とし、1バイトが RREQ識別子バイト40、2バイトが目的地アドレス・バイト41、1バイトがパス・コスト・バイト42、及び8バイトが目的地IEEEアドレス43である。これらの4つのフィールドのパターンは、発見されねばならないユニキャスト・ルートごとに繰り返される。最大6つまでのユニキャスト・ルート・リクエストがペイロードにより収容されることができ、最大72バイトを必要とする。同様に、各々のマルチキャスト・ルート・リクエストは合計4バイトを必要とし、1バイトが RREQ識別子バイト44、2バイトが目的地アドレス・バイト45、及び1バイトがパス・コスト・バイト46であり、最大15までのマルチキャスト・ルート・リクエストがペイロード内に収容されることができ、最大60バイトを必要とする。これらの3つのフィールドのパターンは、発見されねばならないマルチキャスト・ルートごとに繰り返される。明確にするために、最初のユニキャスト・リクエストのフィールド又は最初のマルチキャスト・リクエストのフィールドのみが、図2において番号をつけられている。

Command Optionsフィールド30の「ビット7」がセットされた場合、即ち「1」である場合、これは、パケットを受信している中間ノードに、後続するフィールド31がMultiple Requestsフィールド31であることを通知する。この時点で中間ノードは、発見されねばならないユニキャスト・ルート及びマルチキャスト・ルートの各々に対する経路選択テーブル項目及び発見テーブル項目を生成できる。実質的に、Command Optionsフィールド30の「ビット7」をセットすることにより、ソース・ノードはペイロードの内容が標準のルート・リクエストRREQのペイロードとは異なることを中間ノードに知らせ、この結果、中間ノードはこれにしたがって反応することであろう。

上で説明したように、ネットワーク・フレームのペイロードのサイズは合計82バイトに限定されており、この結果、発見されることができるルートの数も限定される。しかしながら代替の実施態様では、ルートの合計数は増すことが出来る。図2bに例示したように、ペイロードの全体構造は、基本的に同じままである。しかしながら、図2aの例の場合にあった、ユニキャスト・ルート・リクエスト及びマルチキャスト・ルート・リクエストの各々に対して専用のPath Costフィールドを用意する代わりに、1つのPath costフィールド48が使われている。この場合、ユニキャスト・ルート・リクエストは、1バイトのRREQ識別子バイト40、2バイトの目的地アドレス・バイト41、及び8バイトの目的地IEEEアドレス・バイト43だけを必要とし、一方、マルチキャスト・ルート・リクエストは、1バイトのRREQ識別子バイト44、及び2バイトの目的地アドレス・バイト45を必要とするのみである。これは、数バイトが「節約される」ことができ、新たな1本のユニキャスト・ルートが発見され得ることを意味する。繰り返すが、発見されねばならない各々ユニキャスト・ルート及びマルチキャスト・ルートの合計数は、上の図2aで説明したように、Multiple Requestsフィールド31で指定されている。

例えば、複数の他の重要デバイスに先立ちルートを確立することを要求するゲートウェイ・デバイスがある場合、ネットワーク・ペイロードが、本発明による方法の長所を使用して、many-to-oneルート発見のために使われることもできる。この場合のペイロード2の構造を、図2cに示すことができる。Command Optionフィールド30の第3及び第4のビットが、many-to-one経路選択が実行されていることを示すためにセットされる。Command Optionsフィールド30の最後のビットは、複数のリクエストが扱われることを示す。後続するMultiple Requestsフィールド31の最初の4ビットは、本願明細書では、many-to-oneルートが確立されねばならないノードの数を示し、残りの4ビットは使用されず、1バイト長のPath Costフィールド32はソース、即ち、意図された集信器へのコストを示す。その一方で、1バイト長のRREQ identifierフィールド33は、ネットワーク・ヘッダのソース・アドレスと共に、独自にRREQパケットを識別する。残りのペイロードが、所望のmany-to-oneノードのアドレス用に使われる。繰り返すが、各々のルート・リクエストは合計10バイトを要し、2バイトがソース・アドレス・バイト41、及び8バイトがソースのIEEEアドレス・バイト42であり、この結果、合計最大7本のmany-to-oneルートが1つのMREQメッセージで確立されることができる。繰り返すが、これらの2つのフィールドのパターンは、発見されねばならないルートの各々に対して繰り返され、最初の2つのフィールド40、同41だけが図において番号をつけられている。好ましくはデバイス、例えば集信器、ブリッジ、ゲートウェイ等が当該フィールドを発見したあとで、many-to-oneルートが率先して確立されることができる。上の説明に従った複数のmany-to-oneの目的地をもつMREQコマンドを受信すると、集信器の範囲内にある全てのノードが、複数のmany-to-one経路選択の目標の各々に対して経路選択テーブル項目をつくる。

既に説明したように、本発明による方法は、所望する目的地へのルート上に既にあり、且つルート応答をソース・ノードへと直接発出する中間ノードをもつことによって、ブロードキャスト・ストームの強度を減じるために適用されることが出来る。ルート・リクエストが、これらの中間ノードによって再度ブロードキャストされる必要はない。斯様なルートの再利用を可能にするために、本発明による方法では、ルート・リクエスト・メッセージ（MREQ又はRREQでも）中のFrame ControlフィールドのDiscover Routeフラグが「11」にセットされる。この事が視覚的に図3aに示されている。同図は、8ビット2つを有するFrame Controlフィールド50を備えたルート・リクエスト・メッセージMREQを示し、このうちのビット6及びビット7がセットされた場合、ルートの再利用が要求されていることを示す。本発明による方法でのこれらのビットの使用が、斜交平行線の陰影により示されている。これらの設定されたビットがルート・リクエストを受信する中間ノードにより検出され、当該中間ノードが既に特定の目的地までのルートをもっている場合、中間ノードはルート応答RREPをしかるべく組み立てる。図3bの上側が、従来技術のCommand Optionsフィールド60'を示し、最初の4つのビット0-3は予約済である。本発明に従って組み立てられるルート応答のCommand Optionsフィールド60では、図3bの下側に示されるように、ビット3は、この中間ノードによって申し出されたルートが、恐らくは次善のルートであることを示すようセットされる。本発明による方法におけるこのビットの使用が、斜交平行線の陰影により示されている。

図4aは、無線ネットワークWN内で、考え得る配置をされた複数のデバイスD、D1、D2、D3、Da、Db、Dcの概略図を示す。各デバイスD、D1、D2、D3、Da、Db、DcはZigBee準拠のネットワーク・インタフェース10をもつ。当該インタフェースは、無線マルチホップ・ネットワークWN内で、情報を他のデバイスD、D1、D2、D3、Da、Db、Dcと交換できるよう、メッセージを送受信できる。この例では、デバイスDは、室内の人の存在を検出できる動きセンサ又は何らかの存在検知器の形態をしたスイッチであり、照明器具D1、D2、D3を制御できる。これらの照明器具D1、D2、D3は、機能するマルチキャスト・グループGを有し、グループ・アドレスをもっている。無線ネットワーク中の他のデバイスDa、Db、Dcは、光センサ、サーモスタット、換気扇などである。簡潔に説明するために、照明器具D1、D2、D3及びスイッチDは同じ部屋にあるとみなされるが、しかし、他のデバイスが何処にでも配置されることが出来る。この例は意図的に単純化されており、当業者は、無線マルチホップ・ネットワークは何百又は何千ものノード又はデバイスを有することが出来ることに気づいていることであろう。

図4bは、図4aの無線ネットワークに対するマルチホップ・ネットワーク線図を示す。この線図は、デバイスD、D1、D2、D3、Da、Db、Dcの間に確立されたネットワーク・パス又はネットワーク・ルートを示す。この1つのシナリオでは、スイッチD（存在検知器）は、当該スイッチDが制御するグループG（複数の照明器具）へ、及び別のデバイスDa及びDc（HVACデバイス）へと、ネットワーク・パスを確立した。照明器具D1、D2、D3、及びHVACデバイスDcはスイッチDの直接の範囲にはなく、DからGのグループ・メンバまでのルートはDbを通過して、最も近いグループ・メンバD1へと到着し、Dbを用いてD2及びD3へとメンバ・モード・マルチキャストで送信され、他方、DからDaまでのルートは直接であり、DからDcまでのルートはDb及びD2を経由して行く。従来のルート発見の手順では、これらのルートを確立するためにソース・ノードDは目的地G、Db及びDaの各々に対して1度ずつ、連続して2回ネットワークWNをルート・リクエストRREQでオーバーフローさせねばならなかった。本発明による方法では、ソース・ノードDは、（デバイスDb及びDaに対する）2つのユニキャスト・アドレスと、デバイスD1、D2、D3を有する照明器具グループGに対する1つのマルチキャスト・アドレスと、をもつ複数ルートのリクエスト・メッセージを組み立てることができる。

本発明によるネットワーク・インタフェース10の非常に簡略化されたブロック線図が、図5に示されている。この説明に関連するブロック又はユニットだけが示されている事が強調されなければならず、当業者は、適切に機能するネットワーク・インタフェースとって必要とされる他の何らかのモジュール又はユニットにも気づくことであろう。ここでは、フレーム・アセンブリ・ユニット11は、ネットワーク・インタフェース10が組み込まれるノードにより実行されるアクションに応じて、フレーム、例えば複数ルートのリクエストMREQ又はルート応答RREPを組み立てることができる。設定インタフェース14は、設定されねばならないデバイスのネットワーク・インタフェース10が、例えば委任ステップにおいて、上記のノードが結合されるであろうデバイスに対するアドレス情報を含むことを可能にする。例えば、照明のスイッチは、当該スイッチが起動させるであろうランプ又は照明器具に結合されることが出来る。ここでは設定インタフェース14の一部として示されているが、別個に実現化されることができるメモリ15は、デバイス・アドレスなどの情報と、反復カウント値及びルート応答メッセージを送信するための遅延値などの他のパラメータとを記憶することが出来る。ネットワーク・インタフェースが組み込まれているノードがソース・ノードとして働き、メモリ15にアドレスが記憶されている目的地までのルートを確立したいと望む場合、当該アドレスがメモリから読み出され、フレーム組み立てモジュールは複数のリクエスト・メッセージMREQを組み立て、当該メッセージは次に送信インタフェース12を介して無線ネットワーク内にブロードキャストされる。図2aを用いて既に説明したように、複数ルートのリクエスト・メッセージは、フレームのCommand Optionsフィールド内にある、セットされた又は有効なMultiple RequestsビットMRによって特性を与えられる。

ネットワーク内にあり、ネットワーク・インタフェース10ももつ中間ノードは、受信インタフェース13を用いてフレームを検出し、復号化ユニット16内で当該フレームのフィールドの復号を開始する。当該中間ノードが有効なMRビットの存在を検出した場合、当該中間ノードは複数ルートのリクエスト・メッセージが受信されたことを知り、幾つくらいの数のユニキャスト・ルート及び/又はマルチキャスト・ルートがMultiple Requestsフィールドを用いて確立されねばならないかを決定するステップへと進み、この情報を使用して、テーブル項目T1、T2、T3、例えばこれらの目的地に対する経路選択テーブル項目及びルート発見テーブル項目を生成する。当業者には知られているように、この情報は後の時点で、ソース・ノードと目的地ノードとの間でフレームを受け渡すときに中間ノードによって、使うことができる。明らかに、図5では明快さのために別個のものとして示されている送信器12及び受信器13は、統合された送受信モジュールとして実現化されることができよう。

自身は複数ルートのリクエストMREQにて定められた目的地ノードであるノードは、ルート応答メッセージRREPをコンパイルする事であろう。このルート応答メッセージは、メモリ15に記憶された値により指定された回数だけ発出されることができ、再度、メモリ内に記憶された値にしたがって、送信の前に遅延されることができる。斯様な値が記憶されなかった場合は、ルート応答RREPメッセージは、通常の方法で単に一度だけ送信されることができる。

更にまた、目的地ノードは、自身のもつアドレスを目的地のリストから削除した後、リスト中に何らかのアドレス・リストが残っている場合、MREQを再送信せねばならない。開始ノード、中間ノード、及び目的地ノードの後続の動作は当業者に知られており、ここで更に取扱われる必要はない。

上記の技術の何れかが、本発明による方法の他のバリエーション、即ち、ブロードキャスト・ストームの範囲を限定するための制限されたブロードキャスト半径のアプリケーションと、更に組み合わされることができる。図6は、関連するルート発見パラメータ値及びブロードキャスト配信パラメータ値と共に、ブロードキャスト半径値の表を示す。発信デバイス内にある本発明によるネットワーク・インタフェースは、小さなブロードキャスト半径、例えば2を選択することができ、この結果、ルート・リクエストは2回の「ホップ」に対して送り届けられるに過ぎない。小さなブロードキャスト半径では、応答のための時間も、より短いことが予想され、この結果、時間に関するパラメータ、即ち発信ノード及び中間ノードが、RREPパケットが受信されるのを待ちながらルート発見項目を保持せねばならない時間と、特定のブロードキャスト・パケットに対応する項目が、複製を回避するために、ブロードキャスト処理テーブルBTT内に保持される時間と、をそれぞれ定めている「nwkcRouteDiscoveryTime」及び「nwkBroadcastDeliveryTime」は、対応するブロードキャスト半径値と一致する指定された値である。この小さなブロードキャスト半径が充分ではない場合、即ち、ソース・ノードが、対応するパラメータにより指定された所与の時間内にルート応答を受信しない場合、ブロードキャスト半径即ちホップ回数を増すことができる。必要ならば、ルート発見が成功するまで、及びルート応答が目的地ノードの各々から受信されるまで、ブロードキャスト半径を連続して増すことができる。

本発明による方法を適用することによって、本願明細書で説明されているように、複数の目的地へのルートを確立するのに必要とする時間が、このように大幅に減らされることができ、ネットワーク全体のオーバーフローが回避されることができ、より信頼性が高いルート発見手順の確認が、全て最小限の努力で可能である。

本発明が、好ましい実施例及び実施例のバリエーションの形で開示されたにもかかわらず、多くの付加的な修正及び変更が、本発明の範囲を逸脱することなく、当該実施例に成され得ることが理解されよう。明確にするために、本アプリケーションを通じて「a」又は「an」の使用が複数を除外することはなく、「有する」が他のステップ又はエレメントを除外しないことを理解すべきである。特に明記しない限り、「ユニット」又は「モジュール」は、多数のユニット又はモジュールを含むことができる。

Claims (14)

1. ソース・ノードと目的地ノードとの間にあるネットワーク・パスを用いて接続されることが出来る、複数のノードを有する無線のマルチホップ・ネットワーク内にあるノードに対するネットワーク・インタフェース・ユニットであって、
   −前記ソース・ノードの複数ルートのリクエスト・メッセージMREQが、ネットワーク・パスが確立されねばならない特定の複数の目的地ノードに対する複数のアドレスを含むよう、当該複数ルートのリクエスト・メッセージMREQを組み立てるための複数ルートのリクエスト組立てモジュールと、
   −前記メッセージMREQを前記無線マルチホップ・ネットワーク内の他のノードに送信するための送信ユニットと、
   を有する、ネットワーク・インタフェース・ユニット。
2. 前記ソース・ノードの前記複数ルートのリクエスト組立てモジュールは、前記無線マルチホップ・ネットワーク内の前記ソース・ノードと複数の目的地との間に、前記ネットワーク・パスが要求されていることを示すために、前記複数ルートのリクエスト・メッセージMREQが複数ルートのリクエスト・インジケータMRを有するよう組み立てることを実現化することを特徴とする、請求項１に記載のネットワーク・インタフェース・ユニット。
3. 前記複数ルートのリクエストMREQ内にある前記複数ルートのリクエスト・インジケータMRが前記中間ノードにより検出された場合、前記複数の目的地ノードの各々に対するテーブル項目が、前記複数ルートのリクエスト・メッセージMREQ内に含まれている目的地のノード・アドレスに基づいて、前記中間ノードによって作られるよう、前記ネットワーク・インタフェース・ユニットが実現化されることを特徴とする、請求項１又は２に記載のネットワーク・インタフェース・ユニット。
4. 前記無線マルチホップ・ネットワーク内にある他の特定のノードのアドレスを得るために、設定インタフェースを有することを特徴とする、請求項１乃至３の何れか一項に記載のネットワーク・インタフェース・ユニット。
5. 前記ネットワーク・インタフェース・ユニットが、前記ソース・ノードに対してルート応答メッセージRREPを少なくとも2度発出するよう実現化されることを特徴とする、請求項１乃至４の何れか一項に記載のネットワーク・インタフェース・ユニット。
6. 前記ネットワーク・インタフェース・ユニットが、遅延値に従った遅延の後にルート応答メッセージRREPを発出するよう実現化されることを特徴とする、請求項１乃至５の何れか一項に記載のネットワーク・インタフェース・ユニット。
7. 前記ネットワーク・インタフェース・ユニットが、
   −前記複数の目的地ノードに対するアドレス、及び/又は、
   −前記ルート応答メッセージRREPの送信を繰り返す回数に対する反復カウント値、及び/又は、
   −前記ルート応答メッセージRREPの送信に先行する遅延値、
   を記憶するための記憶媒体を有することを特徴とする、請求項１乃至６の何れか一項に記載のネットワーク・インタフェース・ユニット。
8. 前記ノードをもつ前記ネットワーク・インタフェース・ユニットは、当該ノードが前記目的地ノードへの以前確立されたルート上にある場合、前記ソース・ノードに対して前記ルート応答メッセージRREPを発出するよう実現化されていることを特徴とする、請求項１乃至７の何れか一項に記載のネットワーク・インタフェース・ユニット。
9. 前記ネットワーク・インタフェース・ユニットは、前記ソース・ノードにより発出された前記ルート・リクエスト・メッセージMREQのブロードキャスト半径が予め規定された範囲に限定されるよう実現化されることを特徴とする、請求項１乃至８の何れか一項に記載のネットワーク・インタフェース・ユニット。
10. 請求項１乃至８の何れか一項に記載のネットワーク・インタフェース・ユニットを備えた、複数のノードを有する無線マルチホップ・ネットワーク。
11. 無線マルチホップ・ネットワーク内でソース・ノードと複数の目的地ノードとの間にネットワーク・パスを確立する方法であって、
    −複数ルートのリクエスト・メッセージMREQを発信ノードによって組み立てるステップと、
    −前記複数ルートのリクエスト・メッセージMREQを無線マルチホップ・ネットワーク内の他のノードへと送信するステップと、
    を含み、前記複数ルートのリクエスト・メッセージMREQが、前記ネットワーク・パスが確立されねばならない前記特定の複数の目的地ノードに対する複数のアドレスを含むことを特徴とする、方法。
12. 前記複数ルートのリクエスト・メッセージMREQを組み立てるステップが、前記無線マルチホップ・ネットワーク内の前記ソース・ノードと前記複数の目的地との間に前記ネットワーク・パスが要求されていることを示す、複数ルートのリクエスト・インジケータMRを含むステップを有することを特徴とする、請求項１１に記載の方法。
13. 前記複数ルートのリクエスト・メッセージMREQが、前記ソース・ノードと前記目的地ノードとの間にある中間ノードにより受信された場合、前記複数ルートのリクエスト・メッセージMREQで指定された前記複数の目的地ノードの各々に対して、当該中間ノードがテーブル項目を作ることを特徴とする、請求項１１又は１２に記載の方法。
14. 前記特定の複数の目的地に対する前記アドレスが、設定インタフェースを用いて前記ソース・ノードに提供されることを特徴とする、請求項１１乃至１３の何れか一項に記載の方法。

Images