複数のネットワークノードを有するメッシュ型無線データ網の動作方法
本発明では、複数のネットワークノード（ＭＮ）を有するメッシュ型の無線データ網の動作方法であって、前記無線データ網のネットワークノード（Ａ，Ｂ，Ｃ，Ｄ，Ｆ，Ｇ，Ｓ）である送信元ノード（ＳＮ）から、該無線データ網のネットワークノード（ＭＮ）である１つまたは複数の中継ノード（ＩＮ）を介して、該無線データ網のネットワークノード（ＭＮ）である送信先ノード（ＤＮ）へデータフレームを伝送する動作方法を開示する。前記ネットワークノード（ＭＮ）のうち、データフレームを受信した少なくとも複数のネットワークノードによるデータフレームの伝送時に、前記送信先ノード（ＤＮ）に関して該データフレームの送信先ノード（ＤＮ）に割り当てられたプリカーソルリストに基づいて、該データフレームを送信したネットワークノード（ＭＮ）が該プリカーソルリストに含まれているか否かを検査し、前記検査の結果がポジティブであった場合、前記データフレームを別の後続のネットワークノード（ＭＮ）へ伝送し、前記検査の結果がネガティブであった場合、前記データフレームを破棄するか、または誤り処理ルーティンを実施する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のネットワークノードを有するメッシュ型無線データ網の動作方法であって、前記メッシュ型無線データ網のネットワークノードである送信元ノードから、該メッシュ型無線データ網のネットワークノードである１つまたは複数の中継ノードを介して、該メッシュ型無線データ網のネットワークノードである送信先ノードへ、データフレームを伝送する動作方法に関する。
【０００２】
メッシュ型データ網では原則的に、前記送信元ノードと送信先ノードとの間で、複数の異なるルートを介してデータフレームを伝送することができる。ルートとは、相互に隣接して配置されている複数のネットワークノードであって、両端において送信元ノードおよび送信先ノードまでのデータ接続を有する複数のネットワークノードを指す。送信元ノードから送信先ノードまでのデータフレームの伝送が偶然に委られないようにするためには、送信元ノードはいわゆる経路問い合わせメッセージ（いわゆるルート要求（route request））をすべての隣接するネットワークノードへ送信し（いわゆるブロードキャスト）、これらのすべての隣接するネットワークノードもこの経路問い合わせメッセージをブロードキャストで、該ネットワークノードに隣接するネットワークノードへ転送し、このことは、該経路問い合わせメッセージが最終的に送信先ノードに到達するまで行われる。この送信先ノードによって、経路応答メッセージ（いわゆるルートリプライ（route reply））が開始される。経路問い合わせメッセージを伝送する場合と、経路応答メッセージが送信元ノードまで宛先指向で伝送される場合（いわゆるユニキャスト）には、各ネットワークノードにおいていわゆる経路選択テーブル（いわゆるルーティングテーブル）にエントリが作成される。これによって、送信元ノードと送信先ノードとの間でデータフレームを伝送するための経路が定義される。
【０００３】
それゆえ本発明では、経路またはデータ経路（英語：route）とは、送信元ノードと送信先ノードとの間で１つまたは複数の特定の中継ノードを介してデータフレームを伝送する経路を指す。送信元ノードから送信先ノードまでデータ経路上で伝送されるデータフレームは、順方向ルート（いわゆる forward route）上で伝送される。データフレームが送信先ノードから送信元ノードへ伝送される場合、このことを下記では逆方向ルート（いわゆる reverse route）と称する。
【０００４】
このようなメッシュ型無線データ網では、個々のデータフレームが送信元ノードと送信先ノードとの間の経路上で誤って伝送されることがあるという問題がある。これによって、ループまたはデータループが発生してしまう。これによって、送信元ノードと送信先ノードとの間のデータ通信は阻害されてしまう。このようなデータフレームの伝送誤りは、公知のどの伝送プロトコル（いわゆるルーティングプロトコル）でも発生する可能性がある。このような不所望のデータループは、間違ったネットワークノードによって発生するか、または、経路上において伝送方向で見て伝送ネットワークノードより上流にあるネットワークノードまでのデータフレームの伝送時に偶然または悪意によって発生することがある。ループ形成時にはデータフレームは、経路上で送信元ノードに順方向でより密接するネットワークノードへ転送される。このことによって、ネットワークの使用可能な帯域幅は縮小されてしまう。
【０００５】
誤転送されたデータフレームがさらに転送されるのを阻止するために、データフレーム内にライフタイム情報を組み込むことが公知である。これはたとえば、インターネットプロトコル（ＩＰ）によるデータパケットと、ＩＥＥＥ８０２．１１ｓ仕様のデータパケットとにおいて変換される。このライフタイム情報は、Time to Live（ｔｔｌ）と称される。これは整数値であり、通常はデータフレームの送信側によって２５５に設定される。このデータフレームが新たなネットワークノードへ転送されるたびに、この値は１だけ減分される。ライフタイム値が０になるとこのデータフレームは破棄され、データ網内でもはや転送されなくなる。
【０００６】
別の公知のセーフティメカニズムに、いわゆる「ソースルーティング（source routing）」がある。このソースルーティングでは、データフレームの送信側（Transmitter）がこのデータフレームを受信側へ転送する権限を有するか否かを該データフレームの受信側が検査することができる。この検査は、データフレームに含まれる経路情報に基づいて行われる。
【０００７】
さらに、データフレームの伝送で一義的な連続番号を使用することが公知である。これによって、データフレームがすでに伝送されたか否かを確認することができる。このような連続番号に基づいて、データフレームが１つのネットワークノードにおいて２回または繰り返し到達した場合、ループが形成されたことを推定することができる。
【０００８】
アドホックオンデマンド距離ベクトル経路選択（ＡＯＤＶ）アルゴリズムによって、いわゆるプリカーソルリストを使用することが公知である。このアルゴリズムはたとえば、ＲＦＣ３５６１においてＩＰ ＭＡＮＥＴルーティングに関して説明されている。このプリカーソルリストは、ネットワークノードの誤り通知に使用される。その際にはプリカーソルリストは、データ経路の順方向にも逆方向にも作成される。プリカーソルリストの作成は、送信先ノードから送信された経路応答メッセージの処理中に行われる。このようなプロセスは、両方向（順方向および逆方向）が同一の経路を辿ることを基礎とする。しかし、ＡＯＤＶにおいて使用されるプリカーソルリストによってループ発生を阻止することはできない。
【０００９】
それゆえ本発明の課題は、メッシュ型無線データ網においてデータフレームの伝送時にデータループを回避できる方法を提供することである。さらに本発明の課題は、メッシュ型無線データ網においてデータフレームの伝送時に、データ網が提供するリソースを可能な限り高効率で使用できる方法を提供することである。
【００１０】
前記課題は、請求項１の特徴部分に記載の構成を有する方法によって解決される。従属請求項に有利な実施形態が記載されている。
【００１１】
複数のネットワークノードを有するメッシュ型無線データ網を動作させるための本発明の動作方法では、前記メッシュ型無線データ網のネットワークノードである送信元ノードから、該メッシュ型無線データ網のネットワークノードである１つまたは複数の中継ノードを介して、該メッシュ型無線データ網のネットワークノードである送信先ノードへ、データフレームを伝送する。データフレームの伝送時には、該データフレームを受信したネットワークノードのうち少なくとも複数によって、該データフレームの送信先ノードに割り当てられたプリカーソルリストに基づいて、該データフレームを送信したネットワークノードが該プリカーソルリストに含まれているか否かが検査される。正である場合、このデータフレームはさらに別のネットワークノードへ伝送される。否である場合、このデータフレームは破棄されるか、または誤り処理ルーティンが実施される。
【００１２】
本発明は、該当のデータフレームを伝送することを許可されていないかまたは該当のデータフレームを伝送するように設けられていないネットワークから到来した該データフレームを発見するためにプリカーソルリストを使用することを提案する。プリカーソルリストは、直接隣接するネットワークノードに関するステートメントを有するリストである。これによって、メッシュ型無線データ網においてデータループを回避することができる。データループをこのように回避することにより、データ網において有益な帯域幅の浪費を回避することができる。待機ループを確実に回避するためには、ネットワークノードは、データフレームを送信したネットワークノードがプリカーソルリストに含まれるか否かを検査しなければならない。この検査は好適には、すべてのネットワークノードによって行われる。送信先ノードによる検査は、必ず必要というわけではない。
【００１３】
また、送信先ノードと、送信先ノードと、送信先ノードの直前の中継ノードとを除くすべてのネットワークノードによって前記検査が行われる変形態様も可能である。相応に、送信元ノードがメッセージの送信先である場合にも（いわゆる逆方向経路）、前記検査は該送信元ノードの直前の中継ノードによっては行われない構成も可能である。
【００１４】
１つの実施形態では、送信元ノードと送信先ノードと中継ノードとに対してそれぞれ、それぞれ少なくとも１つのエントリを有する経路選択テーブル（いわゆるルーティングテーブル）が設けられる。経路選択テーブルの各エントリごとに、データフレームを該当のネットワークノードへ伝送できる直接隣接するネットワークノードを含むプリカーソルリストが設けられる。これによって各ネットワークノードごとに、データ経路内でどの隣接するネットワークノードからデータフレームを受信できるかが規定されている。
【００１５】
経路選択テーブルの作成は、送信元ノードによって開始される経路問い合わせメッセージの伝送時と、送信先ノードによって開始される経路応答メッセージの伝送時に行われる。経路問い合わせメッセージは、ルート要求（Route Request）メッセージとも称される。経路応答メッセージは、ルートリプライ（Route Reply）メッセージとして当業者に周知である。経路問い合わせメッセージはブロードキャストメッセージとして、送信元ノードから送信される。それとは逆に、送信先ノードによって開始される経路応答メッセージはユニキャストメッセージとして伝送される。経路選択テーブル内のエントリは、データ経路の順方向に対してもデータ経路の逆方向に対しても設けられる。データ経路の順方向は、送信元ノードから送信先ノードへの方向である。相応に逆方向は、送信先ノードから送信元ノードへの方向である。
【００１６】
別の実施形態では、プリカーソルリストの作成および／または更新は、送信先ノードによって開始される経路応答メッセージの枠内で行われる。
【００１７】
別の実施形態ではデータフレームは、送信元ノードのアドレスと、送信先ノードのアドレスと、該データフレームを送信したネットワークノードのアドレスと、該データフレームを受信するネットワークノードのアドレスとを含む。データフレームを受信したネットワークノードは、該ネットワークノードに割り当てられたアドレスが該データフレーム内に含まれる送信先ノードのアドレスに相応するか否かを検査する。この検査結果が正である場合、このデータフレームは処理のための別のユニットへ供給され、とりわけＯＳＩ参照モデルのより上位の層へ供給される。このことは、データフレームが送信先ノードに到達したことを意味する。
【００１８】
別の実施形態では、プリカーソルリスト中のエントリは、媒体アクセス制御アドレス（Media Access Control＝ＭＡＣ）またはＩＰアドレスと該エントリのライフタイムとを含む。したがって、プリカーソルリストはＭＡＣアドレスまたはＩＰアドレスのリストである。
【００１９】
プリカーソルリストの要素は、ネットワークノードに直接隣接するネットワークノードであって、該ネットワークノードがデータフレームを伝送することができる直接隣接するネットワークノードである。このことは、該当のネットワークノードへデータフレームを伝送するネットワークノードが、送信先ノードまでのデータ経路上に存在することに拠る。その際には、経路選択テーブルのエントリごとにプリカーソルリストが作成される。多くのルーティングプロトコルではこのことは、送信先ノードごとにエントリが設けられるのと同義である。というのも、各送信先ノードに設けられるルーティングテーブルエントリは１つずつだけであるからだ。それゆえこのことは、プリカーソルリストは各１つの送信先ノードに対してｎ個のエントリを有することができることを意味し、ただし、ｎ∈［１，Ｎ］である。Ｎは、このノードを介するアクティブなデータ経路を有することができる送信先の数（Ｎ≧１）である。
【００２０】
誤転送されるデータフレームを検出するためにプリカーソルリストを使用する他に、本発明はさらに、そのために使用されるこのプリカーソルリストを作成および処理する手法を提案する。
【００２１】
本発明では、プリカーソルリストに格納されるエントリとして、ＭＡＣアドレスまたはＩＰアドレスとライフタイムとの値対が格納される。エントリのライフタイムは、ＡＯＤＶアルゴリズムにおけるライフタイム値とに匹敵する。基本的原理は、ネットワークノードが、エントリ内のＭＡＣアドレスに相応するアドレスを有するネットワークノードからデータフレームを受信した場合、該ネットワークノードのプリカーソルリストのエントリのライフタイムを初期値にリセットすることである。順方向および逆方向のエントリのライフタイムの更新は、相応のデータフレームの受信時にルーティングテーブルのエントリのライフタイムが順方向でも逆方向でも更新される場合にも行われる。さらに、プリカーソルリスト内のエントリのライフタイムが経過した場合、該エントリは消去される。このことによって、データループが形成される危険性が低減されることを保証することができる。
【００２２】
プリカーソルリスト内のエントリのライフタイムの長さは最大で、送信元ノードから送信先ノードまでの経路の経路ライフタイム値に等しい。この経路ライフタイム値は、ルーティングテーブルのエントリ内に情報として含まれる。
【００２３】
１つの実施形態では、プリカーソルリスト内のエントリのライフタイムの更新と、該当のルーティングテーブルエントリ内の経路ライフタイム値の更新とは同時に行われる。ライフタイムの更新はたとえば、経路応答メッセージ（ルートリプライメッセージ）によって行うことができる。それに対して、経路問い合わせメッセージ（ルート要求メッセージ）はプリカーソルリストの更新を行うようには構成されない。
【００２４】
その理由は以下の通りである：プリカーソルリストは、送信元ノードと送信先ノードとの間のデータ経路を決定するためのいわゆるルートディスカバリ中に作成される。その基本的なメカニズムは、ＡＯＤＶの本来の仕様に由来する。このことに関しては、文献［１］に公開されている。ここでは、従来技術から公知のプロセスに対する補足として、プリカーソルリストのエントリにライフタイムを追加する。送信元ノードからデータ網のすべてのネットワークノードへ送信される経路問い合わせメッセージが、すべてのネットワークノードから送信元ノードへの逆方向の方向を生成する。この逆方向ルートが終点から、すなわち送信先ノードから形成された後も、先行のネットワークノードはなお未知であるから、プリカーソルリスト内に送信元ノードの経路選択テーブルエントリに関して何も入力することができない。それに対して、送信先ノードから送信元ノードまでユニキャストメカニズムを使用して伝送される経路応答メッセージによって、プリカーソルリスト内に入力されるエントリが、順方向ルートでも逆方向ルートでも生成される。その際には、"destination_node"情報および"source_node"情報が経路応答メッセージの相応のフィールドから取り出される。
【００２５】
ルーティングテーブルの書き込みに関しては、以下のステップを実施する：
- routingtable (destination_node).create;
- routingtable (desitnation_node).lifetime.update (RREP. lifetime);
- routingtable (destination_node).precursor_list.add
(routingtable (source_node) next_hop, RREP.lifetime);
- routingtable (source_node).precursor_list.add (weg-antwortnachricht.transmitter, routingtable (source node).lifetime).
中継ノードが送信元ノードと送信先ノードとの間のデータフレーム伝送ルートにおいて該送信元ノードに隣接する場合、ないしは、送信元ノードと送信先ノードとの間のデータフレーム伝送ルートにおいて送信先ノードに隣接する場合には、該中継ノードにおいて相応のルーティングテーブルエントリに対してプリカーソルリストを作成する必要はない。しかし、このような場合でもプリカーソルリストを作成することにより、本方法は簡略化され、迅速になる。
【００２６】
ＡＯＤＶでもＨＷＭＰ（Hybrid Wireless Mesh Protocol）でも、中継ノードが送信先ノードまでの有効なルートを把握している場合には、該中継ノードは経路問い合わせメッセージに対して経路応答メッセージによって応答することができる。このような場合には、経路応答メッセージを生成する中継ノードの経路選択テーブルにおいて以下の更新を行わなければならない。その際には、経路応答メッセージの相応のフィールドから、"destination_node"フィールドおよび"source_node"が取り出される：
- routingtable (destination_node).precursor_list.add(routingtable (source_node).next_hop, routingtable (destination_node).lifetime)
- routingtable (source_node).precursor_list.add(routingtable (destination_node).next_hop, routingtable (source_ node).lifetime)
１つの実施形態では、送信元ノードと、送信先ノードと、該送信元ノードと該送信先ノードとの間のデータ経路における中継ノードのうちいずれかの中継ノードのうちいずれかでない別のネットワークノードが、該送信元ノードの経路問い合わせメッセージの受信後（経路応答メッセージ受信後でない）に、該送信元ノードまでの逆方向経路上で次のネットワークノードである別の中継ノードであって、該送信元ノードに対するルーティングエントリのプリカーソルリストに該別のネットワークノードを含まない次のネットワークノードである別の中継ノードを介して該送信元ノードへデータフレームを伝送した場合、この別の中継ノードは、該別のネットワークノードから受信されたデータフレームを破棄する。
【００２７】
別の実施形態では、この別のネットワークノードと送信元ノードとの間に形成されたデータ経路は無効として標識される。この別のネットワークノードから送信元ノードへデータフレームが不必要に送信されるのを回避するためには、このような経路をマーキングし、この別のネットワークノードが送信元ノードまでのルートディスカバリを行えなくする。このことは、送信元ノードと別のネットワークノードとの間でルートディスカバリを行う際に形成された逆方向経路を使用する代わりに行われる。
【００２８】
別の択一的な構成では、別のネットワークノードから送信元ノードへデータフレームが伝送される前に、該別のネットワークノードと送信元ノードとの間の経路に関してプリカーソルリストを充填する。このことはたとえば、前記別のネットワークノードから送信元ノードへ経路応答メッセージを送信することによって行われる。
【００２９】
さらに別の択一的な実施形態では、経路問い合わせメッセージの受信時に、１つのネットワークノードに隣接するすべてのネットワークノードのアドレスを、経路問い合わせメッセージの受信時のシーケンス値とともに、このネットワークノードのプリカーソルリストに一時的なエントリとして入力する。
【００３０】
その際には、別の構成では、このネットワークノードに隣接し経路問い合わせメッセージを送信したネットワークノードは、このネットワークノードのプリカーソルリストに入力されない。
【００３１】
別の構成では、プリカーソルリストに入力された前記一時的なエントリに、経路問い合わせメッセージによって形成された逆方向経路と等しい値を有するシーケンス値（たとえば、ＩＰＶ４等のインターネットプロトコルヘッダ内のＴＴＬ（Time-to-Live 値）を設ける。
【００３２】
別のオプションの構成では、送信先ノードによって開始された経路応答メッセージの枠内でプリカーソルリスト内にエントリが作成される際に、前記一時的なエントリを該プリカーソルリストから消去することができる。
【００３３】
ＨＷＭＰにおいて、いわゆるツリールーティングのプロアクティブな拡大時のプロアクティブな経路問い合わせメッセージでも、同様の問題が存在する。開始ノードからの無方向性のツリー（ルートツリー（root tree））に経路問い合わせメッセージが突き当たり、該経路問い合わせメッセージは、この開始ノードに接続されたすべてのネットワークノードに伝送される。この過程によって開始ノードまでの逆方向経路が生成されるが、プリカーソルリストが形成されることはない。その際には、ＨＷＭＰは本発明で提案するのと同様の手段を使用する。プロアクティブな経路応答メッセージフラグがセットされると、経路問い合わせメッセージに応答して経路応答メッセージが送信される。これによって、通常のようにプリカーソルリストを充填することができる。プロアクティブな経路応答メッセージフラグがセットされていない場合、経路応答メッセージをデータフレームの前に送信することができ、プリカーソルリストは「適時（just in time）」に作成される。
【００３４】
本発明では、意図的または誤った転送に起因してデータループが生成されるのを回避するために、誤転送されるデータフレームを発見するための簡単なメカニズムを提供する。このことは、誤転送されるデータフレームを発見するためにプリカーソルリストを使用することによって実現される。その際には、データフレームを送信した送信側と、プリカーソルリスト内に存在する許可された先行者（＝送信側または送信局）とが比較される。このようにして本発明は、ＡＯＤＶの仕様と同様に、プリカーソルリストのメカニズムを拡張する。エントリにはライフタイムがプリカーソルリスト内で割り当てられ、該プリカーソルリストの内容は、メッシュ型無線データ網内のアクティブなデータ経路に相応するようにされる。
【００３５】
以下で本発明を、図面に基づいて詳細に説明する。
【図面の簡単な説明】
【００３６】
【図１】複数のネットワークノードを有するメッシュ型データ網を示し、このメッシュ型データ網に基づいて、本発明の基本的な方法を説明する。
【図２】発明の詳細な説明で使用される概念の定義を示す図である。
【図３】図１に示されたネットワークノードのルーティングを行うためのルーティングテーブルを示しており、同図では、図１のデータ網のネットワークノードのうち２つのネットワークノード間のデータ経路が形成される際のルーティングテーブルの割り当てと、該ルーティングテーブルに含まれるプリカーソルリストとを説明する。
【図４】図１に示されたネットワークノードのルーティングを行うためのルーティングテーブルを示しており、同図では、図１のデータ網のネットワークノードのうち２つのネットワークノード間のデータ経路が形成される際のルーティングテーブルの割り当てと、該ルーティングテーブルに含まれるプリカーソルリストとを説明する。
【図５】図１に示されたネットワークノードのルーティングを行うためのルーティングテーブルを示しており、同図では、図１のデータ網のネットワークノードのうち２つのネットワークノード間のデータ経路が形成される際のルーティングテーブルの割り当てと、該ルーティングテーブルに含まれるプリカーソルリストとを説明する。
【図６】図１に示されたネットワークノードのルーティングを行うためのルーティングテーブルを示しており、同図では、図１のデータ網のネットワークノードのうち２つのネットワークノード間のデータ経路が形成される際のルーティングテーブルの割り当てと、該ルーティングテーブルに含まれるプリカーソルリストとを説明する。
【図７】図１に示されたネットワークノードのルーティングを行うためのルーティングテーブルを示しており、同図では、図１のデータ網のネットワークノードのうち２つのネットワークノード間のデータ経路が形成される際のルーティングテーブルの割り当てと、該ルーティングテーブルに含まれるプリカーソルリストとを説明する。
【図８】図１に示されたネットワークノードのルーティングを行うためのルーティングテーブルを示しており、同図では、図１のデータ網のネットワークノードのうち２つのネットワークノード間のデータ経路が形成される際のルーティングテーブルの割り当てと、該ルーティングテーブルに含まれるプリカーソルリストとを説明する。
【図９】図３〜８で使用される記号の凡例を示す。
【００３７】
図１に一例として、複数のネットワークノードＭＮを備えたメッシュ型データ網を示す。ネットワークノードＭＮは部分的に相互に、データ交換を行うために通信区間ＫＳを介して相互に接続されている。通信区間ＫＳは無線で形成されている。各ネットワークノードＭＮに一意のアドレスが割り当てられており、このアドレスに基づいて、送信元ノードから送信先ノードへデータフレームを伝送することができる。図１中、ネットワークノードＭＮのアドレスは参照符号Ｓ，Ｂ，Ａ，Ｃ，Ｄ，ＦおよびＧによって示されている。通信区間ＫＳを介して行われるネットワークノードＭＮから隣接するネットワークノードＭＮへのデータフレームの伝送は、矢印によって示されている。このデータ網では、送信元ノード、送信先ノードおよび１つまたは複数の中継ノードが該データ網のネットワークノードによって形成され、該１つまたは複数の中継ノードを介して行われる該データ網の送信元ノードから該データ網の送信先ノードへのデータフレームの伝送はホップバイホップで行われる。すなわち、ネットワークノードごとに行われる。
【００３８】
たとえば、図１中のデータ網の送信元ノードＳからデータフレームを、該データ網の送信先ノードＤへ伝送する場合、まずはデータ経路を求め、該データ経路内で、該送信元ノードＳと該送信先ノードＤとの間に存在する中継ノード（この実施例では、ネットワークノードＢ，ＡおよびＣ）を求めなければならない。これらのネットワークノードにはそれぞれ、経路選択テーブルが配属されている。下記では、この経路選択テーブルをルーティングテーブルと称する。図１では、これらのルーティングテーブルに参照符号ＲＴが付されている。同図中の実施例では、ルーティングテーブルＲＴのエントリは３つの値を含む。第１の値は送信先ノードのアドレスを示す。第２の値は経路メトリクスを示す。これは、到達すべき送信先ノードまでのホップ数と同義である。第３の値は、次のネットワークノードとしてデータフレームを伝送すべき伝送先であるネットワークノードのアドレスを示す。これは、「next hop（次のホップ）」とも称される。
【００３９】
データ経路は、いわゆる「ルートディスカバリ（route discovery）」によって求められる。このルートディスカバリは、メッシュ型無線データ網の動作によって十分に既知である。こうするためには、送信元ノードＳによって経路問い合わせメッセージが生成され、該送信元ノードに接続されたすべてのネットワークノードへ伝送される。ブロードキャストと称されるこの伝送方式は、このような経路問い合わせメッセージを受信した中継ノードによっても実施される。以下では、この経路問い合わせメッセージをルート要求メッセージまたはルートリクエストと称する。送信先ノードＤがこのようなルート要求メッセージを受信すると、経路応答メッセージによって応答する。以下では、この経路応答メッセージをルートリプライまたはルートリプライメッセージと称する。しかしこのルートリプライは、ルート要求メッセージとは逆に、宛先指向で送信元ノードＳへ伝送される。このような伝送はユニキャストとも称される。
【００４０】
ルートディスカバリの枠内では、各中継ノードのルーティングテーブルをデータ経路に作成および充填することができる。
【００４１】
図２に、メッシュ型のデータ網の記述で慣用される取り決めを示す。ここでは簡略化するために、送信元ノードＳＮは１つの中継ノードＩＮのみを介して送信先ノードＤＮに接続されていることを基礎とする。送信元ノードＳＮと中継ノードＩＮとの間、ないしは中継ノードＩＮと送信先ノードＤＮとの間には、それぞれ無線通信区間ＫＳが形成されている。ネットワークノードＳＮ，ＩＮおよびＤＮは、データフレームを伝送するためのデータ経路ＤＰに存在する。データ経路ＤＰは、上記のルートディスカバリ手法によって求められたものである。送信元ノードＳＮから送信先ノードＤＮへ伝送されるデータフレームは、順方向ないしは順方向ルートＦＲ上で伝送される。送信先ノードＤＮから送信元ノードＳＮへ伝送されるデータフレームは、逆方向ないしは逆方向ルートＲＲ上で伝送される。以下ではこれらの取り決めを基礎とする。
【００４２】
以下で図１に基づいて課題を簡単に説明するにあたり、送信元ノードであるネットワークノードＳと送信先ノードであるネットワークノードＤとの間のデータ経路は、Ｓ‐Ｂ‐Ａ‐Ｃ‐Ｄであることを前提とする。送信元ノードであるネットワークノードＧと送信先ノードであるネットワークノードＤとの間に別のデータ経路が形成されることとする。このデータ経路は、たとえばＧ‐Ｆ‐Ｂ‐Ａ‐Ｃ‐Ｄである。
【００４３】
中継ノードとなるネットワークノードＢは、送信先ノードとしてネットワークノードＤが含まれるルーティングテーブルエントリを有する。ネットワークノードＤに到達するまでには３ホップが必要であり、Ｂが受信したデータフレームはネットワークノードＡ（これも中継ノード）へ伝送しなければならない。このことに相応してネットワークノードＡは、ネットワークノードＤが送信先ノードとして含まれるルーティングテーブルエントリを有する。ネットワークノードＤに到達するまでには２ホップが必要であり、Ａが受信したデータフレームはネットワークノードＣ（これも中継ノード）へ伝送しなければならない。このことに相応してネットワークノードＣは、ネットワークノードＤが送信先ノードとして含まれるルーティングテーブルエントリを有する。ネットワークノードＤに到達するまでには１ホップが必要であり、Ｃが受信したデータフレームはネットワークノードＤ（送信先ノード）へ伝送しなければならない。ネットワークノードＦ（これも中継ノード）が送信先ノードＤに対するデータフレームを受信した場合、ルーティングテーブルエントリから、該送信先ノードまでに４ホップを解決しなければならないという情報を得る。ネットワークノードＦが受信したデータフレームはさらに、ネットワークノードＢへ伝送しなければならない。
【００４４】
意図的または誤りが原因であるネットワークノードＡの誤り挙動が発生した場合、データフレームはネットワークノードＣへ伝送されず、ネットワークノードＦへ伝送されてしまう事態が生じることがある。このことはたとえば、ネットワークノードＡがネットワークノードＦから受信した経路問い合わせメッセージ中の情報によって支援される。このことによって、図１に破線の矢印で示されたデータループが形成される。つまりネットワークノードＦは、該ネットワークノードＦのルーティングテーブルエントリによってデータフレームをＢへ転送し、Ｂは該データフレームをＡへ伝送する。
【００４５】
このようなループの形成によって、メッシュ型無線データ網において有益な帯域幅が失われてしまうので、本発明ではルーティングテーブルエントリにそれぞれプリカーソルリストを補足する。このプリカーソルリストを設けることにより、データフレームを受信するネットワークノードへ該データフレームを送信してはならないネットワークノードからのデータフレームを検出することができる。このことによってデータループを回避することができる。
【００４６】
ルーティングテーブルエントリごとに作成される各プリカーソルリストは、媒体アクセス制御（ＭＡＣ）アドレスのリストを示す。プリカーソルリストの要素は、プリカーソルリストを有するネットワークノードに直接隣接するネットワークノードであって、該プリカーソルリストを有するネットワークノードへネットワークノードへルーティングプロトコルによって求められたルートにしたがってデータフレームを伝送するネットワークノードである。したがって、Ｎが次のような送信元ノードの数、すなわち、当該ノードを経由するアクティブなデータ経路を有する送信元ノード数であるとすると、１つのネットワークノードのルーティングテーブルエントリのプリカーソルリストはｎ∈［１，Ｎ］個のエントリを有することができる。
【００４７】
ＩＥＥＥ８０２．１１ｓ標準規格（WLAN Mesh Networking）において、６つのアドレスを含むデータフレームのフォーマットが定義されている。ここで定義されたデータフレームはとりわけ、該データフレームを伝送したネットワークノードのアドレス（transmitter address）を含む。このネットワークノードは、データ経路において先行のネットワークノード（hop）である。したがって換言すると、このネットワークノードは先行者またはプリカーソルということになる。このアドレス、すなわち送信側アドレスは、所望の送信先ノードまでの経路上のプリカーソルリスト内に含まれるアドレスと比較される。受信ノードが送信先ノードである場合、この比較を行う必要はもはや無くなる。というのも、データフレームを送信先ノードへ伝送することによってデータループが発生することはないからである。
【００４８】
この手法を実施するためには、送信先ノードのアドレスと、データフレームを伝送するネットワークノードのアドレスと、該データフレームを受信するネットワークノードのアドレスの３つのアドレスが必要である。既述のように、送信先アドレスが、データフレームを受信するネットワークノードのアドレスに相応するか否かの比較が実施される。そうである場合、受信されたデータフレームはより上位の処理層へ供給される。送信先アドレスが、データフレームを受信するネットワークノードのアドレスに相応しない場合、送信したネットワークノード（送信側）のアドレスが、送信先ノードに対するルーティングテーブルエントリのプリカーソルリストに含まれているか否かを検査する。そうである場合、データフレームは適正に伝送されたことになる。したがって、このデータフレームを受信したネットワークノードは該データフレームを、相応のルーティングテーブルエントリに次のホップとして含まれるネットワークノードへ伝送する。この検査結果がネガティブである場合、データフレームは誤転送されたと見なされる。というのも、送信側はデータ経路上で先行するネットワークノードではなく、データフレームを隣接ネットワークノードへ伝送してはならなかったからである。それゆえ、データフレームは破棄されるか、または誤り処理ルーティンへ供給される。
【００４９】
プリカーソルリストの各エントリにはさらに、ライフタイム値（life time）が補足される。したがって、プリカーソルリスト内のエントリはこの値対｛ＭＡＣアドレス、ライフタイム｝を含む。ライフタイム値を補足することにより、プリカーソルリストをデータ網内のアクティブなデータ経路へ通信できるようになる。換言するとこのことによって、プリカーソルリスト内のエントリはアクティブなデータ経路に対してのみ設けられることが保証される。
【００５０】
プリカーソルリスト内のエントリのライフタイムが終了すると、当該のエントリがプリカーソルリストから消去される。データフレームがネットワークノードによって受信され、相応のプリカーソルリストエントリが設けられている場合には必ず、ライフタイム値の検査ないしは更新が行われる。プリカーソルリストエントリのライフタイムはデータ経路の双方向で、すなわち順方向および逆方向で更新することができる。このことは、ＡＯＤＶ／ＨＷＭＰで説明したプロセスに相応する。
【００５１】
ライフタイムエントリの新たな値は、ライフタイムがとることができる最大値である。好適なのは、プリカーソルリストエントリのライフタイム値は、データ経路の相応のライフタイム値を上回らないことである。基本的に、プリカーソルリストにおけるライフタイム値の更新は、ルーティングテーブルエントリのライフタイム値の更新とともに行われる。プリカーソルリストエントリのライフタイム値は、ルートリプライメッセージが該当のネットワークノードを介して伝送される場合にも更新される。それに対してルート要求メッセージは、プリカーソルリストのライフタイムエントリの更新を行わない。
【００５２】
ルーティングテーブルエントリに割り当てられるプリカーソルリストも、ルートディスカバリの枠内で生成される。その際には、ルートディスカバリプロセス中に特別な事態が発生する。送信元ノードＳが送信先ノードＤと通信したい場合、該送信元ノードＳによってルートディスカバリが開始され、ルート要求メッセージがデータ網内のすべてのネットワークノードへ伝送される。ルート要求メッセージによって、すべてのネットワークノードから送信元ノードＳまでの逆方向経路が生成される。しかし冒頭に述べたように、送信元ノードＳと送信先ノードＤとの間にはデータ経路は１つだけ形成され、この１つのデータ経路で送信先ノードＤはルートリプライを送信する。このルートリプライメッセージによって、ネットワークノードにプリカーソルリストが生成される。このことは、データ経路上においてＳとＤとの間にあるネットワークノードでのみ行われる。冒頭に述べたようにデータ経路はＳ‐Ｂ‐Ａ‐Ｃ‐Ｄである。しかし他のネットワークノードでは、この実施例ではネットワークノードＦおよびＧでは、所属のルーティングテーブルエントリにおいてこのようなプリカーソルリストは生成されない。それにもかかわらず、実際には、ネットワークノードＧから送信元ノードＳまでの逆方向経路が有効である。
【００５３】
ネットワークノードＧが送信元ノードＳへ逆方向経路でデータフレームを伝送する場合、データフレームを次のネットワークノードへ送信する。この次のネットワークノードは、この実施例ではネットワークノードＦである。しかし、ネットワークノードＧに隣接するネットワークノードＦは、ネットワークノードＧに対応するプリカーソルリストエントリを有さない。それゆえ、Ｇから伝送されたデータフレームはそれ自体では有効な経路で伝送されたにもかかわらず、ネットワークノードＦにおいて破棄される。
【００５４】
この問題を解決するために３つの手段が存在する。
【００５５】
1. ＧとＳとの間に形成された逆方向経路を、無効な経路と見なす。データフレームが不必要に送信されるのを回避するためには、ネットワークノードＧが、Ｓによって開始されたルートディスカバリによって開始されたＳまでの逆方向経路を使用する代わりに、ネットワークノードＳまでのルートディスカバリを開始できるように、この経路を適切にマーキングしなければならない。
【００５６】
2. 本来のデータフレームがＧからＳの方向へ伝送される前に、ルートリプライメッセージをＳへ伝送することにより、プリカーソルリストを生成する。
【００５７】
3. 択一的に、隣接するすべてのネットワークノードのアドレスを、逆方向経路に対応するプリカーソルリストに挿入する。このことは、ルート要求メッセージを送信したネットワークノードには必要ない。ネットワークノードＦに関してはこのようなネットワークノードは、隣接するネットワークノードＡおよびＧということになる。隣接するネットワークノードＢをプリカーソルリストに取り込む必要はない。というのも、このネットワークノードＢはルート要求メッセージを送信したネットワークノードであるからだ。これらのエントリにはタイムアウトが設けられ、このタイムアウトの値は、ルート要求メッセージによって形成された逆方向ルートの値に等しい。しかし、このような簡単な手法の欠点は、ルートディスカバリ中に、データループ形成が防止されない短い時間が生じることである。
【００５８】
以下の図３〜８では、プリカーソルリストが割り当てられたルーティングテーブルエントリをどのように生成するかを説明する。この説明では、図１に示されたデータ網を参照する。より理解しやすくするため、図９に、図３〜８で使用される記号の凡例を示す。
【００５９】
ルーティングテーブルＲＴは５つのエントリを有する：
送信先ノードのアドレス（"destination"）
送信先ノードまでデータ経路内に存在する中継ノードの数（"distance (hops)"）
次のネットワークノードのアドレス（"next hop"）
ルーティングテーブルエントリのライフタイム値（"time out (life time)"）
各エントリがネットワークノードのアドレスとライフタイムエントリとを有するプリカーソルリスト（"precursor list (node, life time)"）
本願明細書では、２種類のメッセージタイプＮＴを使用する。ＲＲＥＱは、ルート要求または経路問い合わせメッセージを意味する。ＲＲＥＰはルートリプライメッセージまたは経路応答メッセージを意味する。両ルーティングメッセージＲＮは以下の値を有する：
時点（"time/at"）
送信したネットワークノードのアドレス（"transmitter"）
送信元ノードのアドレス（"source"）
送信先ノードのアドレス（"destination"）
送信先ノードまでのネットワークノード数（"hop count"）
ライフタイム（"life time"）
図３中、ステップＳ１〜Ｓ６で、送信元ノードであるネットワークノードＧと送信先ノードであるネットワークノードＤとの間のデータ経路の形成を示す。ここではとりわけ、ネットワークノードＧによってルート要求メッセージが送信された後にネットワークノードＳ，Ｂ，Ａ，Ｃ，Ｄ，ＦおよびＧそれぞれのルーティングテーブルがどのように生成されるかを示す。個々のテーブルにおいて強調されているフィールドは、ルート要求メッセージの送信者と、ルーティングテーブルにおいてルート要求メッセージの処理によって変化したフィールドとを示す。ステップＳ１においてネットワークノードＧからルート要求メッセージＲＲＥＱが送信される。このことにより、ネットワークノードＧはメッセージの送信者となる。それと同時にＧはデータ網の送信元ノードとなり、"source"フィールド内にもＧが入力される。送信先としてルート要求メッセージはネットワークノードＤを含む（destination）。このメッセージの送信者および送信元は同一であるから、hop count 値に０が入力される。ライフタイム値として値８が任意選択される。ネットワークノードＧおよびＦに割り当てられたルーティングテーブルには、Ｇがメッセージの送信側であることが示されている。ルート要求メッセージＲＲＥＱをＧから受信するネットワークノードＦのルーティングテーブルには、逆方向ルートに関する情報が記憶されている。それゆえ、送信先（destination）としてネットワークノードＧのアドレスが検出される。というのも、このネットワークノードＧはルート要求メッセージの送信元ノードであるからだ。このノードまでの距離は１ホップである。逆方向ルートの送信先である送信元に到達するためには、次のノード（next hop）としてノードＧに到達しなければならない。送信元ノードＧまでの逆方向ルートに対応するルーティングテーブルエントリのライフタイムとして、ルート要求メッセージから８単位時間が選択される。
【００６０】
ステップＳ２においてルート要求メッセージＲＲＥＱが、通信区間ＫＳを介してネットワークノードＦに接続されたネットワークノードへ送信される。これは図１の実施例では、ネットワークノードＢ，ＡおよびＧである。ルート要求メッセージＲＲＥＱは、該メッセージの送信側すなわち送信者がネットワークノードＦであるという情報を含む。ルート要求メッセージＲＲＥＱは送信元ノードＧによって開始されたので、この送信元ノードＧは送信元フィールドに入力されている。さらに、送信先は送信先ノードＤであるから、これは送信先フィールドに入力されている。ネットワークノードＦとＧとの間の距離は１ホップカウントである。ライフタイムは、所定の値８のままである。ルート要求メッセージをＦから受信したネットワークノードＢ，ＡおよびＧではそれぞれルーティングテーブルエントリが入力され、ネットワークノードＢおよびＡにおいては送信者ネットワークノードＦに対しても送信元ノードＧに対しても入力され、ネットワークノードＧにおいては送信者ノードＦに対してのみ入力される。逆方向ルートの送信先（送信元）までの距離は値２に適合される。
【００６１】
このようにしてルート要求メッセージＲＲＥＱは、最終的にステップＳ６において送信先ノードＤに到達するまで転送される。ネットワークノードＤは２つのルーティングテーブルエントリを有し、これらのうち１つは、ネットワークノードＣに対して送信先として情報を含み、もう１つはネットワークノードＧに対して送信先として情報を含む。
【００６２】
図４においてステップＳ７〜１１で、送信先ノードＤから送信されるルートリプライメッセージを示す。ここでは、送信元ノードＧはルートリプライメッセージの受信者である。ここでは各ルーティングテーブルにおいて、ルーティングテーブルエントリのうち複数のルーティングテーブルエントリに対して、データ経路において先行するネットワークノードのアドレスとライフタイム値とを有するプリカーソルリストが入力されているのが理解できる。
【００６３】
ルートリプライメッセージはネットワークノードＤによって送信され、隣接するネットワークノードＣへ伝送される。"source"フィールドにはさらに、ルート要求メッセージを開始した送信元ノードＧがある。さらに送信先ノードはＤであり、これは、送信元ノードＧがデータ経路を確立したい送信先である。ホップカウントはルートリプライメッセージの送信側から見てカウントされるので、値は０である。ライフタイムはルート要求メッセージ内のライフタイムに相応して８に設定されているが、原則的には任意に選択することができる。ルートリプライメッセージをネットワークノードＤから受信したネットワークノードＣは、ネットワークノードＤに対応する新たなルーティングテーブルエントリを入力することができる。また、ネットワークノードＧおよびＤ（それぞれ destination）までのルーティングテーブルエントリに対してプリカーソルリストエントリを入力することができる。ネットワークノードＣから送信先であるネットワークノードＧへメッセージを送信する場合、ネットワークノードＤはデータ経路において先行者となる。それに対してネットワークノードＣからデータフレームを、受信側であるネットワークノードＤへ送信する場合には、ネットワークノードＡがデータ経路において先行者となる。この情報は、受信側であるネットワークノードＧまでのルーティングテーブルエントリから取り出すことができる。というのも、このエントリではＡが次のホップとして含まれているからだ。
【００６４】
相応に、ルートリプライメッセージがネットワークノードＣからネットワークノードＡへ転送され、該ネットワークノードＡからネットワークノードＢへ転送され、最終的にネットワークノードＦへ転送された後にネットワークノードＧへ転送される。そのつど、上記のようにルーティングテーブルエントリが補足され、それぞれのプリカーソルリストが生成される。
【００６５】
図６に関連する図５および図７において、図３および４に相応する過程を説明する。しかしここでは、送信元ノードであるネットワークノードＳからルート要求メッセージが送信され、ネットワークノードＤは送信先ノードとして決定されている。たとえば図５のステップＳ１３から理解できるように、このルート要求メッセージによって生成されて更新されたルーティングテーブルエントリのライフタイムが時点は、異なる時点である（時点８ではなく時点１１）。ステップＳ１８〜Ｓ２１を考察するとさらに、複数のルーティングテーブルエントリ（たとえばステップＳ２０の、ネットワークノードＤに対応するルーティングテーブルエントリを参照されたい）においてプリカーソルリストに付加的に１エントリが補足されているのが理解できる。図７中のステップＳ２１において、図１の実施例のデータ網のすべてのネットワークノードの最終的なルーティングテーブルを示している。ここで、図１を参照して説明したように、ネットワークノードＡが誤って、ネットワークノードＤへ送信するためのデータをネットワークノードＣへ送信するのではなくネットワークノードＦへ送信した場合、このデータフレームは破棄され、データループの発生が阻止される。本発明による方法の結論を再度、以下の実施形態に基づいて再度明瞭にする。この実施形態では以下の略称を使用する。
ＲＡ 受信するネットワークノードのアドレス（"receiver address"）
ＴＡ データフレームを送信したネットワークノードのアドレス（"receiver address"）
ＤＡ 送信先ノードのアドレス（"destination address"）
ＳＡ データフレームの当初の本来の送信元であるアドレス（"source address"）
ネットワークノードＡの考察：
ステップ１：ネットワークノードＡがデータフレームを受信する。ここでは、ＲＡ＝Ａ、ＴＡ＝Ｂ、ＤＡ＝Ｄ、ＳＡ＝ＧまたはＳ。
【００６６】
ステップ２：ネットワークノードＡはデータフレームの送信先ではない（Ａ≠Ｄ）。すなわち、送信先ノードのアドレスはこのネットワークノードのアドレスに相応しない。
【００６７】
ステップ３：データフレームは適正に受信された。というのも、送信したネットワークノードＢは、送信先ノードＤに対するルーティングテーブルエントリのプリカーソルリストに含まれているからである（［Ｄ‐２‐Ｃ‐１１‐（Ｂ，１１）］）。
【００６８】
さらに、ネットワークノードＡがこのデータフレームをＣへ転送すべきであるが（ネットワークノードＤに対するルーティングテーブルエントリは［Ｄ‐２‐Ｃ‐１１‐（Ｂ，１１）］、実際には、ネットワークノードＡがこのデータフレームを誤ってネットワークノードＦへ伝送すると仮定する。
【００６９】
ネットワークノードＦの考察：
ステップ１：ネットワークノードＦがデータフレームを受信する。ここでは、ＲＡ＝Ｆ、ＴＡ＝Ａ、ＤＡ＝Ｄ、ＳＡ＝ＧまたはＳ。
【００７０】
ステップ２：ネットワークノードＦはデータフレームの送信先ノードではない（Ｆ≠Ｄ）。
【００７１】
ステップ３：データフレームは誤って受信された。というのも、送信側（送信者）ＢはネットワークノードＤに対するルーティングテーブルエントリのプリカーソルリストに含まれていないからである（［Ｄ‐４‐Ｂ‐８‐（Ｇ，８）］）。このことによりデータフレームは破棄される。
【００７２】
このようにして本発明は、間違ったネットワークノードが、受信したデータフレームの送信元であるネットワークノードへ該データフレームを伝送し戻した場合に生じるデータループの形成を阻止する。
【００７３】
ここでは、図１のネットワークノードＢが、ネットワークノードＤへ送信するためのデータフレームをネットワークノードＳまたはＦへ送信し戻すことを前提とする。ＳもＦも送信先ノードＤまで有効な経路を有し、ネットワークノードＢが次の送信先ノード、すなわち次のホップである。
【００７４】
ネットワークノードＢの考察：
ステップ１：ネットワークノードＢがデータフレームを受信する。ここでは、ＲＡ＝Ｂ、ＴＡ＝ＳまたはＦ、ＤＡ＝Ｄ、ＳＡ＝ＳまたはＧ。
【００７５】
ステップ２：ネットワークノードＢはデータフレームの送信先ではない（Ｂ≠Ｄ）。
【００７６】
ステップ３：データフレームは適正に受信された。というのも、送信側ＳまたはＦはネットワークノードＤに対するルーティングテーブルエントリのプリカーソルリストに含まれているからである（［Ｄ‐３‐Ａ‐１１‐（Ｆ，８）（Ｓ，１１）］）。
【００７７】
ネットワークノードＢは、データフレームをネットワークノードＡへ伝送するように設けられている。このことは、ネットワークノードに対するルーティングテーブルエントリ：［Ｄ‐３‐Ａ‐１１‐（Ｆ，８）（Ｓ，１１）］から導き出される。しかしこの実施例では、データフレームが誤ってネットワークノードＦまたはＳへ伝送されると仮定する。
【００７８】
ネットワークノードＳの考察：
ステップ１：ネットワークノードＳがデータフレームを受信する。ここでは、ＲＡ＝Ｓ、ＴＡ＝Ｂ、ＤＡ＝Ｄ、ＳＡ＝ＳまたはＧである。
【００７９】
ステップ２：ネットワークノードＳはデータフレームの送信先でない（Ｓ≠Ｄ）。
【００８０】
ステップ３：データフレームは誤って受信された。というのも、送信側（送信者）ＢはネットワークノードＤに対するルーティングテーブルエントリのプリカーソルリストに含まれていないからである（［Ｄ‐４‐Ｂ‐１１‐（ ）］）。このことによりデータフレームは破棄される。
【００８１】
ネットワークノードＦの考察：
ステップ１：ネットワークノードＦがデータフレームを受信する。ここでは、ＲＡ＝Ｆ、ＴＡ＝Ｂ、ＤＡ＝Ｄ、ＳＡ＝ＳまたはＧである。
【００８２】
ステップ２：ネットワークノードＦはデータフレームの送信先ではない（Ｆ≠Ｄ）。
【００８３】
ステップ３：データフレームは誤って受信された。というのも、送信側（送信者）ＢはネットワークノードＤに対するルーティングテーブルエントリのプリカーソルリストに含まれていないからである（［Ｄ‐４‐Ｂ‐８‐（Ｇ，８）］）。
【００８４】
それゆえ、このデータフレームは破棄される。
【００８５】
図８にさらに、相互にオーバーラップするデータ経路のプリカーソルリストの持続的な更新を示す。たとえばネットワークノードＳ，Ｂ，Ａ，Ｃ，Ｄ，ＦおよびＧのルーティングテーブルから、ルーティングテーブルエントリのライフタイムの終了によって、関連するプリカーソルリストエントリが消去されることが理解できる。このことは、強調された空のテーブルエントリによって示されている。したがってルーティングテーブルエントリのライフタイムの終了時には、ルーティングテーブルエントリもプリカーソルリストエントリ自体も除去される。この実施例では、ネットワークノードＧとＤとの間のデータ経路が満了したと仮定する。しかし、ネットワークノードＢ，ＡおよびＣに存在する送信先ノードＤまでのデータ経路は未だ満了していない。というのも、ネットワークノードＳとＤとの間にアクティブなデータ経路が未だ存在するからである。ネットワークノードＢはＤまでのデータ経路でのプリカーソルを有する。すなわち、ＧとＤとの間の経路において１つのプリカーソルを有し、ＳとＤとの間のデータ経路において１つのプリカーソルを有する。ここでは前者のデータ経路のみが満了しており、プリカーソルリストから消去される。
【００８６】
文献リスト：
[1] C.E. Perkins, E. M. Belding-Royer, S. R. Das: Ad hoc Ondemand Distance Vector (AODV) Routing, IETF Experimental RFC 3561, JuIy 2003.
【技術分野】
【０００１】
本発明は、複数のネットワークノードを有するメッシュ型無線データ網の動作方法であって、前記メッシュ型無線データ網のネットワークノードである送信元ノードから、該メッシュ型無線データ網のネットワークノードである１つまたは複数の中継ノードを介して、該メッシュ型無線データ網のネットワークノードである送信先ノードへ、データフレームを伝送する動作方法に関する。
【０００２】
メッシュ型データ網では原則的に、前記送信元ノードと送信先ノードとの間で、複数の異なるルートを介してデータフレームを伝送することができる。ルートとは、相互に隣接して配置されている複数のネットワークノードであって、両端において送信元ノードおよび送信先ノードまでのデータ接続を有する複数のネットワークノードを指す。送信元ノードから送信先ノードまでのデータフレームの伝送が偶然に委られないようにするためには、送信元ノードはいわゆる経路問い合わせメッセージ（いわゆるルート要求（route request））をすべての隣接するネットワークノードへ送信し（いわゆるブロードキャスト）、これらのすべての隣接するネットワークノードもこの経路問い合わせメッセージをブロードキャストで、該ネットワークノードに隣接するネットワークノードへ転送し、このことは、該経路問い合わせメッセージが最終的に送信先ノードに到達するまで行われる。この送信先ノードによって、経路応答メッセージ（いわゆるルートリプライ（route reply））が開始される。経路問い合わせメッセージを伝送する場合と、経路応答メッセージが送信元ノードまで宛先指向で伝送される場合（いわゆるユニキャスト）には、各ネットワークノードにおいていわゆる経路選択テーブル（いわゆるルーティングテーブル）にエントリが作成される。これによって、送信元ノードと送信先ノードとの間でデータフレームを伝送するための経路が定義される。
【０００３】
それゆえ本発明では、経路またはデータ経路（英語：route）とは、送信元ノードと送信先ノードとの間で１つまたは複数の特定の中継ノードを介してデータフレームを伝送する経路を指す。送信元ノードから送信先ノードまでデータ経路上で伝送されるデータフレームは、順方向ルート（いわゆる forward route）上で伝送される。データフレームが送信先ノードから送信元ノードへ伝送される場合、このことを下記では逆方向ルート（いわゆる reverse route）と称する。
【０００４】
このようなメッシュ型無線データ網では、個々のデータフレームが送信元ノードと送信先ノードとの間の経路上で誤って伝送されることがあるという問題がある。これによって、ループまたはデータループが発生してしまう。これによって、送信元ノードと送信先ノードとの間のデータ通信は阻害されてしまう。このようなデータフレームの伝送誤りは、公知のどの伝送プロトコル（いわゆるルーティングプロトコル）でも発生する可能性がある。このような不所望のデータループは、間違ったネットワークノードによって発生するか、または、経路上において伝送方向で見て伝送ネットワークノードより上流にあるネットワークノードまでのデータフレームの伝送時に偶然または悪意によって発生することがある。ループ形成時にはデータフレームは、経路上で送信元ノードに順方向でより密接するネットワークノードへ転送される。このことによって、ネットワークの使用可能な帯域幅は縮小されてしまう。
【０００５】
誤転送されたデータフレームがさらに転送されるのを阻止するために、データフレーム内にライフタイム情報を組み込むことが公知である。これはたとえば、インターネットプロトコル（ＩＰ）によるデータパケットと、ＩＥＥＥ８０２．１１ｓ仕様のデータパケットとにおいて変換される。このライフタイム情報は、Time to Live（ｔｔｌ）と称される。これは整数値であり、通常はデータフレームの送信側によって２５５に設定される。このデータフレームが新たなネットワークノードへ転送されるたびに、この値は１だけ減分される。ライフタイム値が０になるとこのデータフレームは破棄され、データ網内でもはや転送されなくなる。
【０００６】
別の公知のセーフティメカニズムに、いわゆる「ソースルーティング（source routing）」がある。このソースルーティングでは、データフレームの送信側（Transmitter）がこのデータフレームを受信側へ転送する権限を有するか否かを該データフレームの受信側が検査することができる。この検査は、データフレームに含まれる経路情報に基づいて行われる。
【０００７】
さらに、データフレームの伝送で一義的な連続番号を使用することが公知である。これによって、データフレームがすでに伝送されたか否かを確認することができる。このような連続番号に基づいて、データフレームが１つのネットワークノードにおいて２回または繰り返し到達した場合、ループが形成されたことを推定することができる。
【０００８】
アドホックオンデマンド距離ベクトル経路選択（ＡＯＤＶ）アルゴリズムによって、いわゆるプリカーソルリストを使用することが公知である。このアルゴリズムはたとえば、ＲＦＣ３５６１においてＩＰ ＭＡＮＥＴルーティングに関して説明されている。このプリカーソルリストは、ネットワークノードの誤り通知に使用される。その際にはプリカーソルリストは、データ経路の順方向にも逆方向にも作成される。プリカーソルリストの作成は、送信先ノードから送信された経路応答メッセージの処理中に行われる。このようなプロセスは、両方向（順方向および逆方向）が同一の経路を辿ることを基礎とする。しかし、ＡＯＤＶにおいて使用されるプリカーソルリストによってループ発生を阻止することはできない。
【０００９】
それゆえ本発明の課題は、メッシュ型無線データ網においてデータフレームの伝送時にデータループを回避できる方法を提供することである。さらに本発明の課題は、メッシュ型無線データ網においてデータフレームの伝送時に、データ網が提供するリソースを可能な限り高効率で使用できる方法を提供することである。
【００１０】
前記課題は、請求項１の特徴部分に記載の構成を有する方法によって解決される。従属請求項に有利な実施形態が記載されている。
【００１１】
複数のネットワークノードを有するメッシュ型無線データ網を動作させるための本発明の動作方法では、前記メッシュ型無線データ網のネットワークノードである送信元ノードから、該メッシュ型無線データ網のネットワークノードである１つまたは複数の中継ノードを介して、該メッシュ型無線データ網のネットワークノードである送信先ノードへ、データフレームを伝送する。データフレームの伝送時には、該データフレームを受信したネットワークノードのうち少なくとも複数によって、該データフレームの送信先ノードに割り当てられたプリカーソルリストに基づいて、該データフレームを送信したネットワークノードが該プリカーソルリストに含まれているか否かが検査される。正である場合、このデータフレームはさらに別のネットワークノードへ伝送される。否である場合、このデータフレームは破棄されるか、または誤り処理ルーティンが実施される。
【００１２】
本発明は、該当のデータフレームを伝送することを許可されていないかまたは該当のデータフレームを伝送するように設けられていないネットワークから到来した該データフレームを発見するためにプリカーソルリストを使用することを提案する。プリカーソルリストは、直接隣接するネットワークノードに関するステートメントを有するリストである。これによって、メッシュ型無線データ網においてデータループを回避することができる。データループをこのように回避することにより、データ網において有益な帯域幅の浪費を回避することができる。待機ループを確実に回避するためには、ネットワークノードは、データフレームを送信したネットワークノードがプリカーソルリストに含まれるか否かを検査しなければならない。この検査は好適には、すべてのネットワークノードによって行われる。送信先ノードによる検査は、必ず必要というわけではない。
【００１３】
また、送信先ノードと、送信先ノードと、送信先ノードの直前の中継ノードとを除くすべてのネットワークノードによって前記検査が行われる変形態様も可能である。相応に、送信元ノードがメッセージの送信先である場合にも（いわゆる逆方向経路）、前記検査は該送信元ノードの直前の中継ノードによっては行われない構成も可能である。
【００１４】
１つの実施形態では、送信元ノードと送信先ノードと中継ノードとに対してそれぞれ、それぞれ少なくとも１つのエントリを有する経路選択テーブル（いわゆるルーティングテーブル）が設けられる。経路選択テーブルの各エントリごとに、データフレームを該当のネットワークノードへ伝送できる直接隣接するネットワークノードを含むプリカーソルリストが設けられる。これによって各ネットワークノードごとに、データ経路内でどの隣接するネットワークノードからデータフレームを受信できるかが規定されている。
【００１５】
経路選択テーブルの作成は、送信元ノードによって開始される経路問い合わせメッセージの伝送時と、送信先ノードによって開始される経路応答メッセージの伝送時に行われる。経路問い合わせメッセージは、ルート要求（Route Request）メッセージとも称される。経路応答メッセージは、ルートリプライ（Route Reply）メッセージとして当業者に周知である。経路問い合わせメッセージはブロードキャストメッセージとして、送信元ノードから送信される。それとは逆に、送信先ノードによって開始される経路応答メッセージはユニキャストメッセージとして伝送される。経路選択テーブル内のエントリは、データ経路の順方向に対してもデータ経路の逆方向に対しても設けられる。データ経路の順方向は、送信元ノードから送信先ノードへの方向である。相応に逆方向は、送信先ノードから送信元ノードへの方向である。
【００１６】
別の実施形態では、プリカーソルリストの作成および／または更新は、送信先ノードによって開始される経路応答メッセージの枠内で行われる。
【００１７】
別の実施形態ではデータフレームは、送信元ノードのアドレスと、送信先ノードのアドレスと、該データフレームを送信したネットワークノードのアドレスと、該データフレームを受信するネットワークノードのアドレスとを含む。データフレームを受信したネットワークノードは、該ネットワークノードに割り当てられたアドレスが該データフレーム内に含まれる送信先ノードのアドレスに相応するか否かを検査する。この検査結果が正である場合、このデータフレームは処理のための別のユニットへ供給され、とりわけＯＳＩ参照モデルのより上位の層へ供給される。このことは、データフレームが送信先ノードに到達したことを意味する。
【００１８】
別の実施形態では、プリカーソルリスト中のエントリは、媒体アクセス制御アドレス（Media Access Control＝ＭＡＣ）またはＩＰアドレスと該エントリのライフタイムとを含む。したがって、プリカーソルリストはＭＡＣアドレスまたはＩＰアドレスのリストである。
【００１９】
プリカーソルリストの要素は、ネットワークノードに直接隣接するネットワークノードであって、該ネットワークノードがデータフレームを伝送することができる直接隣接するネットワークノードである。このことは、該当のネットワークノードへデータフレームを伝送するネットワークノードが、送信先ノードまでのデータ経路上に存在することに拠る。その際には、経路選択テーブルのエントリごとにプリカーソルリストが作成される。多くのルーティングプロトコルではこのことは、送信先ノードごとにエントリが設けられるのと同義である。というのも、各送信先ノードに設けられるルーティングテーブルエントリは１つずつだけであるからだ。それゆえこのことは、プリカーソルリストは各１つの送信先ノードに対してｎ個のエントリを有することができることを意味し、ただし、ｎ∈［１，Ｎ］である。Ｎは、このノードを介するアクティブなデータ経路を有することができる送信先の数（Ｎ≧１）である。
【００２０】
誤転送されるデータフレームを検出するためにプリカーソルリストを使用する他に、本発明はさらに、そのために使用されるこのプリカーソルリストを作成および処理する手法を提案する。
【００２１】
本発明では、プリカーソルリストに格納されるエントリとして、ＭＡＣアドレスまたはＩＰアドレスとライフタイムとの値対が格納される。エントリのライフタイムは、ＡＯＤＶアルゴリズムにおけるライフタイム値とに匹敵する。基本的原理は、ネットワークノードが、エントリ内のＭＡＣアドレスに相応するアドレスを有するネットワークノードからデータフレームを受信した場合、該ネットワークノードのプリカーソルリストのエントリのライフタイムを初期値にリセットすることである。順方向および逆方向のエントリのライフタイムの更新は、相応のデータフレームの受信時にルーティングテーブルのエントリのライフタイムが順方向でも逆方向でも更新される場合にも行われる。さらに、プリカーソルリスト内のエントリのライフタイムが経過した場合、該エントリは消去される。このことによって、データループが形成される危険性が低減されることを保証することができる。
【００２２】
プリカーソルリスト内のエントリのライフタイムの長さは最大で、送信元ノードから送信先ノードまでの経路の経路ライフタイム値に等しい。この経路ライフタイム値は、ルーティングテーブルのエントリ内に情報として含まれる。
【００２３】
１つの実施形態では、プリカーソルリスト内のエントリのライフタイムの更新と、該当のルーティングテーブルエントリ内の経路ライフタイム値の更新とは同時に行われる。ライフタイムの更新はたとえば、経路応答メッセージ（ルートリプライメッセージ）によって行うことができる。それに対して、経路問い合わせメッセージ（ルート要求メッセージ）はプリカーソルリストの更新を行うようには構成されない。
【００２４】
その理由は以下の通りである：プリカーソルリストは、送信元ノードと送信先ノードとの間のデータ経路を決定するためのいわゆるルートディスカバリ中に作成される。その基本的なメカニズムは、ＡＯＤＶの本来の仕様に由来する。このことに関しては、文献［１］に公開されている。ここでは、従来技術から公知のプロセスに対する補足として、プリカーソルリストのエントリにライフタイムを追加する。送信元ノードからデータ網のすべてのネットワークノードへ送信される経路問い合わせメッセージが、すべてのネットワークノードから送信元ノードへの逆方向の方向を生成する。この逆方向ルートが終点から、すなわち送信先ノードから形成された後も、先行のネットワークノードはなお未知であるから、プリカーソルリスト内に送信元ノードの経路選択テーブルエントリに関して何も入力することができない。それに対して、送信先ノードから送信元ノードまでユニキャストメカニズムを使用して伝送される経路応答メッセージによって、プリカーソルリスト内に入力されるエントリが、順方向ルートでも逆方向ルートでも生成される。その際には、"destination_node"情報および"source_node"情報が経路応答メッセージの相応のフィールドから取り出される。
【００２５】
ルーティングテーブルの書き込みに関しては、以下のステップを実施する：
- routingtable (destination_node).create;
- routingtable (desitnation_node).lifetime.update (RREP. lifetime);
- routingtable (destination_node).precursor_list.add
(routingtable (source_node) next_hop, RREP.lifetime);
- routingtable (source_node).precursor_list.add (weg-antwortnachricht.transmitter, routingtable (source node).lifetime).
中継ノードが送信元ノードと送信先ノードとの間のデータフレーム伝送ルートにおいて該送信元ノードに隣接する場合、ないしは、送信元ノードと送信先ノードとの間のデータフレーム伝送ルートにおいて送信先ノードに隣接する場合には、該中継ノードにおいて相応のルーティングテーブルエントリに対してプリカーソルリストを作成する必要はない。しかし、このような場合でもプリカーソルリストを作成することにより、本方法は簡略化され、迅速になる。
【００２６】
ＡＯＤＶでもＨＷＭＰ（Hybrid Wireless Mesh Protocol）でも、中継ノードが送信先ノードまでの有効なルートを把握している場合には、該中継ノードは経路問い合わせメッセージに対して経路応答メッセージによって応答することができる。このような場合には、経路応答メッセージを生成する中継ノードの経路選択テーブルにおいて以下の更新を行わなければならない。その際には、経路応答メッセージの相応のフィールドから、"destination_node"フィールドおよび"source_node"が取り出される：
- routingtable (destination_node).precursor_list.add(routingtable (source_node).next_hop, routingtable (destination_node).lifetime)
- routingtable (source_node).precursor_list.add(routingtable (destination_node).next_hop, routingtable (source_ node).lifetime)
１つの実施形態では、送信元ノードと、送信先ノードと、該送信元ノードと該送信先ノードとの間のデータ経路における中継ノードのうちいずれかの中継ノードのうちいずれかでない別のネットワークノードが、該送信元ノードの経路問い合わせメッセージの受信後（経路応答メッセージ受信後でない）に、該送信元ノードまでの逆方向経路上で次のネットワークノードである別の中継ノードであって、該送信元ノードに対するルーティングエントリのプリカーソルリストに該別のネットワークノードを含まない次のネットワークノードである別の中継ノードを介して該送信元ノードへデータフレームを伝送した場合、この別の中継ノードは、該別のネットワークノードから受信されたデータフレームを破棄する。
【００２７】
別の実施形態では、この別のネットワークノードと送信元ノードとの間に形成されたデータ経路は無効として標識される。この別のネットワークノードから送信元ノードへデータフレームが不必要に送信されるのを回避するためには、このような経路をマーキングし、この別のネットワークノードが送信元ノードまでのルートディスカバリを行えなくする。このことは、送信元ノードと別のネットワークノードとの間でルートディスカバリを行う際に形成された逆方向経路を使用する代わりに行われる。
【００２８】
別の択一的な構成では、別のネットワークノードから送信元ノードへデータフレームが伝送される前に、該別のネットワークノードと送信元ノードとの間の経路に関してプリカーソルリストを充填する。このことはたとえば、前記別のネットワークノードから送信元ノードへ経路応答メッセージを送信することによって行われる。
【００２９】
さらに別の択一的な実施形態では、経路問い合わせメッセージの受信時に、１つのネットワークノードに隣接するすべてのネットワークノードのアドレスを、経路問い合わせメッセージの受信時のシーケンス値とともに、このネットワークノードのプリカーソルリストに一時的なエントリとして入力する。
【００３０】
その際には、別の構成では、このネットワークノードに隣接し経路問い合わせメッセージを送信したネットワークノードは、このネットワークノードのプリカーソルリストに入力されない。
【００３１】
別の構成では、プリカーソルリストに入力された前記一時的なエントリに、経路問い合わせメッセージによって形成された逆方向経路と等しい値を有するシーケンス値（たとえば、ＩＰＶ４等のインターネットプロトコルヘッダ内のＴＴＬ（Time-to-Live 値）を設ける。
【００３２】
別のオプションの構成では、送信先ノードによって開始された経路応答メッセージの枠内でプリカーソルリスト内にエントリが作成される際に、前記一時的なエントリを該プリカーソルリストから消去することができる。
【００３３】
ＨＷＭＰにおいて、いわゆるツリールーティングのプロアクティブな拡大時のプロアクティブな経路問い合わせメッセージでも、同様の問題が存在する。開始ノードからの無方向性のツリー（ルートツリー（root tree））に経路問い合わせメッセージが突き当たり、該経路問い合わせメッセージは、この開始ノードに接続されたすべてのネットワークノードに伝送される。この過程によって開始ノードまでの逆方向経路が生成されるが、プリカーソルリストが形成されることはない。その際には、ＨＷＭＰは本発明で提案するのと同様の手段を使用する。プロアクティブな経路応答メッセージフラグがセットされると、経路問い合わせメッセージに応答して経路応答メッセージが送信される。これによって、通常のようにプリカーソルリストを充填することができる。プロアクティブな経路応答メッセージフラグがセットされていない場合、経路応答メッセージをデータフレームの前に送信することができ、プリカーソルリストは「適時（just in time）」に作成される。
【００３４】
本発明では、意図的または誤った転送に起因してデータループが生成されるのを回避するために、誤転送されるデータフレームを発見するための簡単なメカニズムを提供する。このことは、誤転送されるデータフレームを発見するためにプリカーソルリストを使用することによって実現される。その際には、データフレームを送信した送信側と、プリカーソルリスト内に存在する許可された先行者（＝送信側または送信局）とが比較される。このようにして本発明は、ＡＯＤＶの仕様と同様に、プリカーソルリストのメカニズムを拡張する。エントリにはライフタイムがプリカーソルリスト内で割り当てられ、該プリカーソルリストの内容は、メッシュ型無線データ網内のアクティブなデータ経路に相応するようにされる。
【００３５】
以下で本発明を、図面に基づいて詳細に説明する。
【図面の簡単な説明】
【００３６】
【図１】複数のネットワークノードを有するメッシュ型データ網を示し、このメッシュ型データ網に基づいて、本発明の基本的な方法を説明する。
【図２】発明の詳細な説明で使用される概念の定義を示す図である。
【図３】図１に示されたネットワークノードのルーティングを行うためのルーティングテーブルを示しており、同図では、図１のデータ網のネットワークノードのうち２つのネットワークノード間のデータ経路が形成される際のルーティングテーブルの割り当てと、該ルーティングテーブルに含まれるプリカーソルリストとを説明する。
【図４】図１に示されたネットワークノードのルーティングを行うためのルーティングテーブルを示しており、同図では、図１のデータ網のネットワークノードのうち２つのネットワークノード間のデータ経路が形成される際のルーティングテーブルの割り当てと、該ルーティングテーブルに含まれるプリカーソルリストとを説明する。
【図５】図１に示されたネットワークノードのルーティングを行うためのルーティングテーブルを示しており、同図では、図１のデータ網のネットワークノードのうち２つのネットワークノード間のデータ経路が形成される際のルーティングテーブルの割り当てと、該ルーティングテーブルに含まれるプリカーソルリストとを説明する。
【図６】図１に示されたネットワークノードのルーティングを行うためのルーティングテーブルを示しており、同図では、図１のデータ網のネットワークノードのうち２つのネットワークノード間のデータ経路が形成される際のルーティングテーブルの割り当てと、該ルーティングテーブルに含まれるプリカーソルリストとを説明する。
【図７】図１に示されたネットワークノードのルーティングを行うためのルーティングテーブルを示しており、同図では、図１のデータ網のネットワークノードのうち２つのネットワークノード間のデータ経路が形成される際のルーティングテーブルの割り当てと、該ルーティングテーブルに含まれるプリカーソルリストとを説明する。
【図８】図１に示されたネットワークノードのルーティングを行うためのルーティングテーブルを示しており、同図では、図１のデータ網のネットワークノードのうち２つのネットワークノード間のデータ経路が形成される際のルーティングテーブルの割り当てと、該ルーティングテーブルに含まれるプリカーソルリストとを説明する。
【図９】図３〜８で使用される記号の凡例を示す。
【００３７】
図１に一例として、複数のネットワークノードＭＮを備えたメッシュ型データ網を示す。ネットワークノードＭＮは部分的に相互に、データ交換を行うために通信区間ＫＳを介して相互に接続されている。通信区間ＫＳは無線で形成されている。各ネットワークノードＭＮに一意のアドレスが割り当てられており、このアドレスに基づいて、送信元ノードから送信先ノードへデータフレームを伝送することができる。図１中、ネットワークノードＭＮのアドレスは参照符号Ｓ，Ｂ，Ａ，Ｃ，Ｄ，ＦおよびＧによって示されている。通信区間ＫＳを介して行われるネットワークノードＭＮから隣接するネットワークノードＭＮへのデータフレームの伝送は、矢印によって示されている。このデータ網では、送信元ノード、送信先ノードおよび１つまたは複数の中継ノードが該データ網のネットワークノードによって形成され、該１つまたは複数の中継ノードを介して行われる該データ網の送信元ノードから該データ網の送信先ノードへのデータフレームの伝送はホップバイホップで行われる。すなわち、ネットワークノードごとに行われる。
【００３８】
たとえば、図１中のデータ網の送信元ノードＳからデータフレームを、該データ網の送信先ノードＤへ伝送する場合、まずはデータ経路を求め、該データ経路内で、該送信元ノードＳと該送信先ノードＤとの間に存在する中継ノード（この実施例では、ネットワークノードＢ，ＡおよびＣ）を求めなければならない。これらのネットワークノードにはそれぞれ、経路選択テーブルが配属されている。下記では、この経路選択テーブルをルーティングテーブルと称する。図１では、これらのルーティングテーブルに参照符号ＲＴが付されている。同図中の実施例では、ルーティングテーブルＲＴのエントリは３つの値を含む。第１の値は送信先ノードのアドレスを示す。第２の値は経路メトリクスを示す。これは、到達すべき送信先ノードまでのホップ数と同義である。第３の値は、次のネットワークノードとしてデータフレームを伝送すべき伝送先であるネットワークノードのアドレスを示す。これは、「next hop（次のホップ）」とも称される。
【００３９】
データ経路は、いわゆる「ルートディスカバリ（route discovery）」によって求められる。このルートディスカバリは、メッシュ型無線データ網の動作によって十分に既知である。こうするためには、送信元ノードＳによって経路問い合わせメッセージが生成され、該送信元ノードに接続されたすべてのネットワークノードへ伝送される。ブロードキャストと称されるこの伝送方式は、このような経路問い合わせメッセージを受信した中継ノードによっても実施される。以下では、この経路問い合わせメッセージをルート要求メッセージまたはルートリクエストと称する。送信先ノードＤがこのようなルート要求メッセージを受信すると、経路応答メッセージによって応答する。以下では、この経路応答メッセージをルートリプライまたはルートリプライメッセージと称する。しかしこのルートリプライは、ルート要求メッセージとは逆に、宛先指向で送信元ノードＳへ伝送される。このような伝送はユニキャストとも称される。
【００４０】
ルートディスカバリの枠内では、各中継ノードのルーティングテーブルをデータ経路に作成および充填することができる。
【００４１】
図２に、メッシュ型のデータ網の記述で慣用される取り決めを示す。ここでは簡略化するために、送信元ノードＳＮは１つの中継ノードＩＮのみを介して送信先ノードＤＮに接続されていることを基礎とする。送信元ノードＳＮと中継ノードＩＮとの間、ないしは中継ノードＩＮと送信先ノードＤＮとの間には、それぞれ無線通信区間ＫＳが形成されている。ネットワークノードＳＮ，ＩＮおよびＤＮは、データフレームを伝送するためのデータ経路ＤＰに存在する。データ経路ＤＰは、上記のルートディスカバリ手法によって求められたものである。送信元ノードＳＮから送信先ノードＤＮへ伝送されるデータフレームは、順方向ないしは順方向ルートＦＲ上で伝送される。送信先ノードＤＮから送信元ノードＳＮへ伝送されるデータフレームは、逆方向ないしは逆方向ルートＲＲ上で伝送される。以下ではこれらの取り決めを基礎とする。
【００４２】
以下で図１に基づいて課題を簡単に説明するにあたり、送信元ノードであるネットワークノードＳと送信先ノードであるネットワークノードＤとの間のデータ経路は、Ｓ‐Ｂ‐Ａ‐Ｃ‐Ｄであることを前提とする。送信元ノードであるネットワークノードＧと送信先ノードであるネットワークノードＤとの間に別のデータ経路が形成されることとする。このデータ経路は、たとえばＧ‐Ｆ‐Ｂ‐Ａ‐Ｃ‐Ｄである。
【００４３】
中継ノードとなるネットワークノードＢは、送信先ノードとしてネットワークノードＤが含まれるルーティングテーブルエントリを有する。ネットワークノードＤに到達するまでには３ホップが必要であり、Ｂが受信したデータフレームはネットワークノードＡ（これも中継ノード）へ伝送しなければならない。このことに相応してネットワークノードＡは、ネットワークノードＤが送信先ノードとして含まれるルーティングテーブルエントリを有する。ネットワークノードＤに到達するまでには２ホップが必要であり、Ａが受信したデータフレームはネットワークノードＣ（これも中継ノード）へ伝送しなければならない。このことに相応してネットワークノードＣは、ネットワークノードＤが送信先ノードとして含まれるルーティングテーブルエントリを有する。ネットワークノードＤに到達するまでには１ホップが必要であり、Ｃが受信したデータフレームはネットワークノードＤ（送信先ノード）へ伝送しなければならない。ネットワークノードＦ（これも中継ノード）が送信先ノードＤに対するデータフレームを受信した場合、ルーティングテーブルエントリから、該送信先ノードまでに４ホップを解決しなければならないという情報を得る。ネットワークノードＦが受信したデータフレームはさらに、ネットワークノードＢへ伝送しなければならない。
【００４４】
意図的または誤りが原因であるネットワークノードＡの誤り挙動が発生した場合、データフレームはネットワークノードＣへ伝送されず、ネットワークノードＦへ伝送されてしまう事態が生じることがある。このことはたとえば、ネットワークノードＡがネットワークノードＦから受信した経路問い合わせメッセージ中の情報によって支援される。このことによって、図１に破線の矢印で示されたデータループが形成される。つまりネットワークノードＦは、該ネットワークノードＦのルーティングテーブルエントリによってデータフレームをＢへ転送し、Ｂは該データフレームをＡへ伝送する。
【００４５】
このようなループの形成によって、メッシュ型無線データ網において有益な帯域幅が失われてしまうので、本発明ではルーティングテーブルエントリにそれぞれプリカーソルリストを補足する。このプリカーソルリストを設けることにより、データフレームを受信するネットワークノードへ該データフレームを送信してはならないネットワークノードからのデータフレームを検出することができる。このことによってデータループを回避することができる。
【００４６】
ルーティングテーブルエントリごとに作成される各プリカーソルリストは、媒体アクセス制御（ＭＡＣ）アドレスのリストを示す。プリカーソルリストの要素は、プリカーソルリストを有するネットワークノードに直接隣接するネットワークノードであって、該プリカーソルリストを有するネットワークノードへネットワークノードへルーティングプロトコルによって求められたルートにしたがってデータフレームを伝送するネットワークノードである。したがって、Ｎが次のような送信元ノードの数、すなわち、当該ノードを経由するアクティブなデータ経路を有する送信元ノード数であるとすると、１つのネットワークノードのルーティングテーブルエントリのプリカーソルリストはｎ∈［１，Ｎ］個のエントリを有することができる。
【００４７】
ＩＥＥＥ８０２．１１ｓ標準規格（WLAN Mesh Networking）において、６つのアドレスを含むデータフレームのフォーマットが定義されている。ここで定義されたデータフレームはとりわけ、該データフレームを伝送したネットワークノードのアドレス（transmitter address）を含む。このネットワークノードは、データ経路において先行のネットワークノード（hop）である。したがって換言すると、このネットワークノードは先行者またはプリカーソルということになる。このアドレス、すなわち送信側アドレスは、所望の送信先ノードまでの経路上のプリカーソルリスト内に含まれるアドレスと比較される。受信ノードが送信先ノードである場合、この比較を行う必要はもはや無くなる。というのも、データフレームを送信先ノードへ伝送することによってデータループが発生することはないからである。
【００４８】
この手法を実施するためには、送信先ノードのアドレスと、データフレームを伝送するネットワークノードのアドレスと、該データフレームを受信するネットワークノードのアドレスの３つのアドレスが必要である。既述のように、送信先アドレスが、データフレームを受信するネットワークノードのアドレスに相応するか否かの比較が実施される。そうである場合、受信されたデータフレームはより上位の処理層へ供給される。送信先アドレスが、データフレームを受信するネットワークノードのアドレスに相応しない場合、送信したネットワークノード（送信側）のアドレスが、送信先ノードに対するルーティングテーブルエントリのプリカーソルリストに含まれているか否かを検査する。そうである場合、データフレームは適正に伝送されたことになる。したがって、このデータフレームを受信したネットワークノードは該データフレームを、相応のルーティングテーブルエントリに次のホップとして含まれるネットワークノードへ伝送する。この検査結果がネガティブである場合、データフレームは誤転送されたと見なされる。というのも、送信側はデータ経路上で先行するネットワークノードではなく、データフレームを隣接ネットワークノードへ伝送してはならなかったからである。それゆえ、データフレームは破棄されるか、または誤り処理ルーティンへ供給される。
【００４９】
プリカーソルリストの各エントリにはさらに、ライフタイム値（life time）が補足される。したがって、プリカーソルリスト内のエントリはこの値対｛ＭＡＣアドレス、ライフタイム｝を含む。ライフタイム値を補足することにより、プリカーソルリストをデータ網内のアクティブなデータ経路へ通信できるようになる。換言するとこのことによって、プリカーソルリスト内のエントリはアクティブなデータ経路に対してのみ設けられることが保証される。
【００５０】
プリカーソルリスト内のエントリのライフタイムが終了すると、当該のエントリがプリカーソルリストから消去される。データフレームがネットワークノードによって受信され、相応のプリカーソルリストエントリが設けられている場合には必ず、ライフタイム値の検査ないしは更新が行われる。プリカーソルリストエントリのライフタイムはデータ経路の双方向で、すなわち順方向および逆方向で更新することができる。このことは、ＡＯＤＶ／ＨＷＭＰで説明したプロセスに相応する。
【００５１】
ライフタイムエントリの新たな値は、ライフタイムがとることができる最大値である。好適なのは、プリカーソルリストエントリのライフタイム値は、データ経路の相応のライフタイム値を上回らないことである。基本的に、プリカーソルリストにおけるライフタイム値の更新は、ルーティングテーブルエントリのライフタイム値の更新とともに行われる。プリカーソルリストエントリのライフタイム値は、ルートリプライメッセージが該当のネットワークノードを介して伝送される場合にも更新される。それに対してルート要求メッセージは、プリカーソルリストのライフタイムエントリの更新を行わない。
【００５２】
ルーティングテーブルエントリに割り当てられるプリカーソルリストも、ルートディスカバリの枠内で生成される。その際には、ルートディスカバリプロセス中に特別な事態が発生する。送信元ノードＳが送信先ノードＤと通信したい場合、該送信元ノードＳによってルートディスカバリが開始され、ルート要求メッセージがデータ網内のすべてのネットワークノードへ伝送される。ルート要求メッセージによって、すべてのネットワークノードから送信元ノードＳまでの逆方向経路が生成される。しかし冒頭に述べたように、送信元ノードＳと送信先ノードＤとの間にはデータ経路は１つだけ形成され、この１つのデータ経路で送信先ノードＤはルートリプライを送信する。このルートリプライメッセージによって、ネットワークノードにプリカーソルリストが生成される。このことは、データ経路上においてＳとＤとの間にあるネットワークノードでのみ行われる。冒頭に述べたようにデータ経路はＳ‐Ｂ‐Ａ‐Ｃ‐Ｄである。しかし他のネットワークノードでは、この実施例ではネットワークノードＦおよびＧでは、所属のルーティングテーブルエントリにおいてこのようなプリカーソルリストは生成されない。それにもかかわらず、実際には、ネットワークノードＧから送信元ノードＳまでの逆方向経路が有効である。
【００５３】
ネットワークノードＧが送信元ノードＳへ逆方向経路でデータフレームを伝送する場合、データフレームを次のネットワークノードへ送信する。この次のネットワークノードは、この実施例ではネットワークノードＦである。しかし、ネットワークノードＧに隣接するネットワークノードＦは、ネットワークノードＧに対応するプリカーソルリストエントリを有さない。それゆえ、Ｇから伝送されたデータフレームはそれ自体では有効な経路で伝送されたにもかかわらず、ネットワークノードＦにおいて破棄される。
【００５４】
この問題を解決するために３つの手段が存在する。
【００５５】
1. ＧとＳとの間に形成された逆方向経路を、無効な経路と見なす。データフレームが不必要に送信されるのを回避するためには、ネットワークノードＧが、Ｓによって開始されたルートディスカバリによって開始されたＳまでの逆方向経路を使用する代わりに、ネットワークノードＳまでのルートディスカバリを開始できるように、この経路を適切にマーキングしなければならない。
【００５６】
2. 本来のデータフレームがＧからＳの方向へ伝送される前に、ルートリプライメッセージをＳへ伝送することにより、プリカーソルリストを生成する。
【００５７】
3. 択一的に、隣接するすべてのネットワークノードのアドレスを、逆方向経路に対応するプリカーソルリストに挿入する。このことは、ルート要求メッセージを送信したネットワークノードには必要ない。ネットワークノードＦに関してはこのようなネットワークノードは、隣接するネットワークノードＡおよびＧということになる。隣接するネットワークノードＢをプリカーソルリストに取り込む必要はない。というのも、このネットワークノードＢはルート要求メッセージを送信したネットワークノードであるからだ。これらのエントリにはタイムアウトが設けられ、このタイムアウトの値は、ルート要求メッセージによって形成された逆方向ルートの値に等しい。しかし、このような簡単な手法の欠点は、ルートディスカバリ中に、データループ形成が防止されない短い時間が生じることである。
【００５８】
以下の図３〜８では、プリカーソルリストが割り当てられたルーティングテーブルエントリをどのように生成するかを説明する。この説明では、図１に示されたデータ網を参照する。より理解しやすくするため、図９に、図３〜８で使用される記号の凡例を示す。
【００５９】
ルーティングテーブルＲＴは５つのエントリを有する：
送信先ノードのアドレス（"destination"）
送信先ノードまでデータ経路内に存在する中継ノードの数（"distance (hops)"）
次のネットワークノードのアドレス（"next hop"）
ルーティングテーブルエントリのライフタイム値（"time out (life time)"）
各エントリがネットワークノードのアドレスとライフタイムエントリとを有するプリカーソルリスト（"precursor list (node, life time)"）
本願明細書では、２種類のメッセージタイプＮＴを使用する。ＲＲＥＱは、ルート要求または経路問い合わせメッセージを意味する。ＲＲＥＰはルートリプライメッセージまたは経路応答メッセージを意味する。両ルーティングメッセージＲＮは以下の値を有する：
時点（"time/at"）
送信したネットワークノードのアドレス（"transmitter"）
送信元ノードのアドレス（"source"）
送信先ノードのアドレス（"destination"）
送信先ノードまでのネットワークノード数（"hop count"）
ライフタイム（"life time"）
図３中、ステップＳ１〜Ｓ６で、送信元ノードであるネットワークノードＧと送信先ノードであるネットワークノードＤとの間のデータ経路の形成を示す。ここではとりわけ、ネットワークノードＧによってルート要求メッセージが送信された後にネットワークノードＳ，Ｂ，Ａ，Ｃ，Ｄ，ＦおよびＧそれぞれのルーティングテーブルがどのように生成されるかを示す。個々のテーブルにおいて強調されているフィールドは、ルート要求メッセージの送信者と、ルーティングテーブルにおいてルート要求メッセージの処理によって変化したフィールドとを示す。ステップＳ１においてネットワークノードＧからルート要求メッセージＲＲＥＱが送信される。このことにより、ネットワークノードＧはメッセージの送信者となる。それと同時にＧはデータ網の送信元ノードとなり、"source"フィールド内にもＧが入力される。送信先としてルート要求メッセージはネットワークノードＤを含む（destination）。このメッセージの送信者および送信元は同一であるから、hop count 値に０が入力される。ライフタイム値として値８が任意選択される。ネットワークノードＧおよびＦに割り当てられたルーティングテーブルには、Ｇがメッセージの送信側であることが示されている。ルート要求メッセージＲＲＥＱをＧから受信するネットワークノードＦのルーティングテーブルには、逆方向ルートに関する情報が記憶されている。それゆえ、送信先（destination）としてネットワークノードＧのアドレスが検出される。というのも、このネットワークノードＧはルート要求メッセージの送信元ノードであるからだ。このノードまでの距離は１ホップである。逆方向ルートの送信先である送信元に到達するためには、次のノード（next hop）としてノードＧに到達しなければならない。送信元ノードＧまでの逆方向ルートに対応するルーティングテーブルエントリのライフタイムとして、ルート要求メッセージから８単位時間が選択される。
【００６０】
ステップＳ２においてルート要求メッセージＲＲＥＱが、通信区間ＫＳを介してネットワークノードＦに接続されたネットワークノードへ送信される。これは図１の実施例では、ネットワークノードＢ，ＡおよびＧである。ルート要求メッセージＲＲＥＱは、該メッセージの送信側すなわち送信者がネットワークノードＦであるという情報を含む。ルート要求メッセージＲＲＥＱは送信元ノードＧによって開始されたので、この送信元ノードＧは送信元フィールドに入力されている。さらに、送信先は送信先ノードＤであるから、これは送信先フィールドに入力されている。ネットワークノードＦとＧとの間の距離は１ホップカウントである。ライフタイムは、所定の値８のままである。ルート要求メッセージをＦから受信したネットワークノードＢ，ＡおよびＧではそれぞれルーティングテーブルエントリが入力され、ネットワークノードＢおよびＡにおいては送信者ネットワークノードＦに対しても送信元ノードＧに対しても入力され、ネットワークノードＧにおいては送信者ノードＦに対してのみ入力される。逆方向ルートの送信先（送信元）までの距離は値２に適合される。
【００６１】
このようにしてルート要求メッセージＲＲＥＱは、最終的にステップＳ６において送信先ノードＤに到達するまで転送される。ネットワークノードＤは２つのルーティングテーブルエントリを有し、これらのうち１つは、ネットワークノードＣに対して送信先として情報を含み、もう１つはネットワークノードＧに対して送信先として情報を含む。
【００６２】
図４においてステップＳ７〜１１で、送信先ノードＤから送信されるルートリプライメッセージを示す。ここでは、送信元ノードＧはルートリプライメッセージの受信者である。ここでは各ルーティングテーブルにおいて、ルーティングテーブルエントリのうち複数のルーティングテーブルエントリに対して、データ経路において先行するネットワークノードのアドレスとライフタイム値とを有するプリカーソルリストが入力されているのが理解できる。
【００６３】
ルートリプライメッセージはネットワークノードＤによって送信され、隣接するネットワークノードＣへ伝送される。"source"フィールドにはさらに、ルート要求メッセージを開始した送信元ノードＧがある。さらに送信先ノードはＤであり、これは、送信元ノードＧがデータ経路を確立したい送信先である。ホップカウントはルートリプライメッセージの送信側から見てカウントされるので、値は０である。ライフタイムはルート要求メッセージ内のライフタイムに相応して８に設定されているが、原則的には任意に選択することができる。ルートリプライメッセージをネットワークノードＤから受信したネットワークノードＣは、ネットワークノードＤに対応する新たなルーティングテーブルエントリを入力することができる。また、ネットワークノードＧおよびＤ（それぞれ destination）までのルーティングテーブルエントリに対してプリカーソルリストエントリを入力することができる。ネットワークノードＣから送信先であるネットワークノードＧへメッセージを送信する場合、ネットワークノードＤはデータ経路において先行者となる。それに対してネットワークノードＣからデータフレームを、受信側であるネットワークノードＤへ送信する場合には、ネットワークノードＡがデータ経路において先行者となる。この情報は、受信側であるネットワークノードＧまでのルーティングテーブルエントリから取り出すことができる。というのも、このエントリではＡが次のホップとして含まれているからだ。
【００６４】
相応に、ルートリプライメッセージがネットワークノードＣからネットワークノードＡへ転送され、該ネットワークノードＡからネットワークノードＢへ転送され、最終的にネットワークノードＦへ転送された後にネットワークノードＧへ転送される。そのつど、上記のようにルーティングテーブルエントリが補足され、それぞれのプリカーソルリストが生成される。
【００６５】
図６に関連する図５および図７において、図３および４に相応する過程を説明する。しかしここでは、送信元ノードであるネットワークノードＳからルート要求メッセージが送信され、ネットワークノードＤは送信先ノードとして決定されている。たとえば図５のステップＳ１３から理解できるように、このルート要求メッセージによって生成されて更新されたルーティングテーブルエントリのライフタイムが時点は、異なる時点である（時点８ではなく時点１１）。ステップＳ１８〜Ｓ２１を考察するとさらに、複数のルーティングテーブルエントリ（たとえばステップＳ２０の、ネットワークノードＤに対応するルーティングテーブルエントリを参照されたい）においてプリカーソルリストに付加的に１エントリが補足されているのが理解できる。図７中のステップＳ２１において、図１の実施例のデータ網のすべてのネットワークノードの最終的なルーティングテーブルを示している。ここで、図１を参照して説明したように、ネットワークノードＡが誤って、ネットワークノードＤへ送信するためのデータをネットワークノードＣへ送信するのではなくネットワークノードＦへ送信した場合、このデータフレームは破棄され、データループの発生が阻止される。本発明による方法の結論を再度、以下の実施形態に基づいて再度明瞭にする。この実施形態では以下の略称を使用する。
ＲＡ 受信するネットワークノードのアドレス（"receiver address"）
ＴＡ データフレームを送信したネットワークノードのアドレス（"receiver address"）
ＤＡ 送信先ノードのアドレス（"destination address"）
ＳＡ データフレームの当初の本来の送信元であるアドレス（"source address"）
ネットワークノードＡの考察：
ステップ１：ネットワークノードＡがデータフレームを受信する。ここでは、ＲＡ＝Ａ、ＴＡ＝Ｂ、ＤＡ＝Ｄ、ＳＡ＝ＧまたはＳ。
【００６６】
ステップ２：ネットワークノードＡはデータフレームの送信先ではない（Ａ≠Ｄ）。すなわち、送信先ノードのアドレスはこのネットワークノードのアドレスに相応しない。
【００６７】
ステップ３：データフレームは適正に受信された。というのも、送信したネットワークノードＢは、送信先ノードＤに対するルーティングテーブルエントリのプリカーソルリストに含まれているからである（［Ｄ‐２‐Ｃ‐１１‐（Ｂ，１１）］）。
【００６８】
さらに、ネットワークノードＡがこのデータフレームをＣへ転送すべきであるが（ネットワークノードＤに対するルーティングテーブルエントリは［Ｄ‐２‐Ｃ‐１１‐（Ｂ，１１）］、実際には、ネットワークノードＡがこのデータフレームを誤ってネットワークノードＦへ伝送すると仮定する。
【００６９】
ネットワークノードＦの考察：
ステップ１：ネットワークノードＦがデータフレームを受信する。ここでは、ＲＡ＝Ｆ、ＴＡ＝Ａ、ＤＡ＝Ｄ、ＳＡ＝ＧまたはＳ。
【００７０】
ステップ２：ネットワークノードＦはデータフレームの送信先ノードではない（Ｆ≠Ｄ）。
【００７１】
ステップ３：データフレームは誤って受信された。というのも、送信側（送信者）ＢはネットワークノードＤに対するルーティングテーブルエントリのプリカーソルリストに含まれていないからである（［Ｄ‐４‐Ｂ‐８‐（Ｇ，８）］）。このことによりデータフレームは破棄される。
【００７２】
このようにして本発明は、間違ったネットワークノードが、受信したデータフレームの送信元であるネットワークノードへ該データフレームを伝送し戻した場合に生じるデータループの形成を阻止する。
【００７３】
ここでは、図１のネットワークノードＢが、ネットワークノードＤへ送信するためのデータフレームをネットワークノードＳまたはＦへ送信し戻すことを前提とする。ＳもＦも送信先ノードＤまで有効な経路を有し、ネットワークノードＢが次の送信先ノード、すなわち次のホップである。
【００７４】
ネットワークノードＢの考察：
ステップ１：ネットワークノードＢがデータフレームを受信する。ここでは、ＲＡ＝Ｂ、ＴＡ＝ＳまたはＦ、ＤＡ＝Ｄ、ＳＡ＝ＳまたはＧ。
【００７５】
ステップ２：ネットワークノードＢはデータフレームの送信先ではない（Ｂ≠Ｄ）。
【００７６】
ステップ３：データフレームは適正に受信された。というのも、送信側ＳまたはＦはネットワークノードＤに対するルーティングテーブルエントリのプリカーソルリストに含まれているからである（［Ｄ‐３‐Ａ‐１１‐（Ｆ，８）（Ｓ，１１）］）。
【００７７】
ネットワークノードＢは、データフレームをネットワークノードＡへ伝送するように設けられている。このことは、ネットワークノードに対するルーティングテーブルエントリ：［Ｄ‐３‐Ａ‐１１‐（Ｆ，８）（Ｓ，１１）］から導き出される。しかしこの実施例では、データフレームが誤ってネットワークノードＦまたはＳへ伝送されると仮定する。
【００７８】
ネットワークノードＳの考察：
ステップ１：ネットワークノードＳがデータフレームを受信する。ここでは、ＲＡ＝Ｓ、ＴＡ＝Ｂ、ＤＡ＝Ｄ、ＳＡ＝ＳまたはＧである。
【００７９】
ステップ２：ネットワークノードＳはデータフレームの送信先でない（Ｓ≠Ｄ）。
【００８０】
ステップ３：データフレームは誤って受信された。というのも、送信側（送信者）ＢはネットワークノードＤに対するルーティングテーブルエントリのプリカーソルリストに含まれていないからである（［Ｄ‐４‐Ｂ‐１１‐（ ）］）。このことによりデータフレームは破棄される。
【００８１】
ネットワークノードＦの考察：
ステップ１：ネットワークノードＦがデータフレームを受信する。ここでは、ＲＡ＝Ｆ、ＴＡ＝Ｂ、ＤＡ＝Ｄ、ＳＡ＝ＳまたはＧである。
【００８２】
ステップ２：ネットワークノードＦはデータフレームの送信先ではない（Ｆ≠Ｄ）。
【００８３】
ステップ３：データフレームは誤って受信された。というのも、送信側（送信者）ＢはネットワークノードＤに対するルーティングテーブルエントリのプリカーソルリストに含まれていないからである（［Ｄ‐４‐Ｂ‐８‐（Ｇ，８）］）。
【００８４】
それゆえ、このデータフレームは破棄される。
【００８５】
図８にさらに、相互にオーバーラップするデータ経路のプリカーソルリストの持続的な更新を示す。たとえばネットワークノードＳ，Ｂ，Ａ，Ｃ，Ｄ，ＦおよびＧのルーティングテーブルから、ルーティングテーブルエントリのライフタイムの終了によって、関連するプリカーソルリストエントリが消去されることが理解できる。このことは、強調された空のテーブルエントリによって示されている。したがってルーティングテーブルエントリのライフタイムの終了時には、ルーティングテーブルエントリもプリカーソルリストエントリ自体も除去される。この実施例では、ネットワークノードＧとＤとの間のデータ経路が満了したと仮定する。しかし、ネットワークノードＢ，ＡおよびＣに存在する送信先ノードＤまでのデータ経路は未だ満了していない。というのも、ネットワークノードＳとＤとの間にアクティブなデータ経路が未だ存在するからである。ネットワークノードＢはＤまでのデータ経路でのプリカーソルを有する。すなわち、ＧとＤとの間の経路において１つのプリカーソルを有し、ＳとＤとの間のデータ経路において１つのプリカーソルを有する。ここでは前者のデータ経路のみが満了しており、プリカーソルリストから消去される。
【００８６】
文献リスト：
[1] C.E. Perkins, E. M. Belding-Royer, S. R. Das: Ad hoc Ondemand Distance Vector (AODV) Routing, IETF Experimental RFC 3561, JuIy 2003.
【特許請求の範囲】
【請求項１】
複数のネットワークノード（ＭＮ）を有するメッシュ型の無線データ網の動作方法であって、
前記無線データ網のネットワークノード（ＭＮ）である送信元ノード（ＳＮ）から、該無線データ網のネットワークノード（ＭＮ）である１つまたは複数の中継ノード（ＩＮ）を介して、該無線データ網のネットワークノード（ＭＮ）である送信先ノード（ＤＮ）へデータフレームを伝送する、無線データ網の動作方法において、
前記ネットワークノード（ＭＮ）のうち、データフレームを受信した少なくとも複数のネットワークノードによるデータフレームの伝送時に、該データフレームの送信先ノード（ＤＮ）に割り当てられたプリカーソルリストに基づいて、該データフレームを送信したネットワークノード（ＭＮ）が該プリカーソルリストに含まれているか否かを検査し、
前記検査の結果がポジティブであった場合、前記データフレームを別の後続のネットワークノード（ＭＮ）へ伝送し、
前記検査の結果がネガティブであった場合、前記データフレームを破棄するか、または誤り処理ルーティンを実施することを特徴とする、無線データ網の動作方法。
【請求項２】
・前記送信元ノード（ＳＮ）と前記送信先ノード（ＤＮ）と前記中継ノード（ＩＮ）とに対してそれぞれ、それぞれ少なくとも１つのエントリを含む経路選択テーブル（ＲＴ）を設け、
・前記経路選択テーブル（ＲＴ）の各エントリごとに、データフレームを該当のネットワークノード（ＭＮ）へデータフレームを伝送できる直接隣接するネットワークノードを含むプリカーソルリストを設ける、請求項１記載の無線データ網の動作方法。
【請求項３】
前記送信元ノード（ＳＮ）によって開始される経路問い合わせメッセージの伝送時と、前記送信先ノード（ＤＮ）によって開始される経路応答メッセージの伝送時に、前記経路選択テーブル（ＲＴ）を作成する、請求項２記載の無線データ網の動作方法。
【請求項４】
前記送信先ノード（ＤＮ）によって開始される経路応答メッセージの枠内で、前記プリカーソルリストを作成または更新する、請求項２または３記載の無線データ網の動作方法。
【請求項５】
前記データフレームは、前記送信先ノード（Ｄ）のアドレスと、該データフレームを送信したネットワークノードのアドレスと、該データフレームを受信するネットワークノードのアドレスと、オプションとして前記送信元ノード（Ｓ）のアドレスとを含み、
前記データフレームを受信したネットワークノードは、該ネットワークノードに割り当てられたアドレスが、該データフレーム内の前記送信先ノードのアドレスに相応するか否かを検査し、
前記検査の結果がポジティブである場合、前記データフレームを受信したネットワークノードは前記データフレームを処理のための別のユニットへ供給し、とりわけＯＳＩ参照モデルのより上位の層へ供給する、請求項１から４までのいずれか１項記載の無線データ網の動作方法。
【請求項６】
前記プリカーソルリスト内のエントリは、媒体アクセス制御（ＭＡＣ）アドレスまたはＩＰアドレスと、該エントリのライフタイムとを含む、請求項１から５までのいずれか１項記載の無線データ網の動作方法。
【請求項７】
前記ネットワークノードが、該ネットワークノードのプリカーソルリストのエントリ内のＭＡＣアドレスまたはＩＰアドレスに相応するアドレスを有するネットワークノードからデータフレームを受信した場合、該エントリのライフタイムを初期値にリセットする、請求項６記載の無線データ網の動作方法。
【請求項８】
前記プリカーソル内のエントリのライフタイムが終了した場合、該エントリを消去する、請求項６または７記載の無線データ網の動作方法。
【請求項９】
前記プリカーソルリスト内のエントリのライフタイムの長さは最大で、前記送信元ノードから前記送信先ノードまでの経路の経路ライフタイム値に等しく、
前記経路ライフタイム値は、ルーティングテーブルのエントリ内に情報として含まれる、請求項６から８までのいずれか１項記載の無線データ網の動作方法。
【請求項１０】
前記プリカーソルリスト内のエントリのライフタイムの更新と、該当するルーティングテーブルエントリ内の経路ライフタイム値の更新とを同時に行う、請求項９記載の無線データ網の動作方法。
【請求項１１】
・前記送信先ノード（ＤＮ）と前記送信元ノード（ＳＮ）との間のデータフレーム伝送ルートにおいて該送信元ノード（ＳＮ）に隣接する中継ノードと、
・該送信元ノード（ＳＮ）と該送信先ノード（ＤＮ）との間のデータフレーム伝送ルートにおいて該送信先ノード（ＤＮ）に隣接する中継ノードと
では、該送信先ノードに対応するルーティングテーブルエントリに対してプリカーソルリストを作成する必要はない、請求項１から１０までのいずれか１項記載の無線データ網の動作方法。
【請求項１２】
前記送信元ノード（ＳＮ）、または前記送信先ノード（ＤＮ）、または、該送信元ノード（ＳＮ）と該送信先ノード（ＤＮ）との間のデータ経路（Ｓ‐Ｂ‐Ａ‐Ｃ‐Ｄ）に存在する前記中継ノードのいずれか１つのうち、いずれかでない別のネットワークノードが該送信元ノードの経路応答メッセージを受信した後、該送信元ノードへの逆方向経路上で次のネットワークノードである別の中継ノードであって、該送信元ノード（ＳＮ）に対するルーティングテーブルエントリのプリカーソルリスト内に該別のネットワークノードを含まない別の中継ノードを介して該送信元ノードへデータフレームを伝送し、
前記別の中継ノードは、前記別のネットワークノードから受信したデータフレームを破棄する、請求項１から１１までのいずれか１項記載の無線データ網の動作方法。
【請求項１３】
前記別のネットワークノードと前記送信元ノードとの間に形成されたデータ経路（Ｇ‐Ｂ‐Ｆ‐Ｓ）を無効として標識する、請求項１２記載の無線データ網の動作方法。
【請求項１４】
前記別のネットワークノードによって、前記送信元ノードまでのルートディスカバリを行う、請求項１３記載の無線データ網の動作方法。
【請求項１５】
前記別のネットワークノードから前記送信元ノード（ＳＮ）まで前記データフレームを伝送する前に、該別のネットワークノードを、前記別の中継ノードの送信元ノードまでの逆方向経路に対するルーティングテーブルエントリのプリカーソルリストに取り込む、請求項１２記載の無線データ網の動作方法。
【請求項１６】
前記別の中継ノードの前記送信元ノードまでの逆方向経路に対するルーティングテーブルエントリのプリカーソルリストに前記別のネットワークノードを取り込むために、前記別のネットワークノードを宛先とし、該送信元ノードをソースとして経路応答メッセージを前記送信元ノードへ送信する、請求項１５記載の無線データ網の動作方法。
【請求項１７】
ネットワークノードに隣接するすべてのネットワークノードのアドレスを、経路応答メッセージの受信時のシーケンス値とともに、該ネットワークノードのプリカーソルリストに一時的なエントリとして入力する、請求項１２記載の無線データ網の動作方法。
【請求項１８】
前記ネットワークノードに隣接し前記経路問い合わせメッセージを送信したネットワークノードを、該ネットワークノードのプリカーソルリストに入力しない、請求項１７記載の無線データ網の動作方法。
【請求項１９】
前記プリカーソルリスト内の前記一時的なエントリに、前記経路問い合わせメッセージによって形成された逆方向経路と同じ値を有するシーケンス値を設ける、請求項１７または１８記載の無線データ網の動作方法。
【請求項２０】
前記送信先ノードによって開始される経路応答メッセージの枠内で前記プリカーソルリスト内にエントリを作成する際に、前記一時的なエントリを該プリカーソルリストから消去する、請求項１７から１９までのいずれか１項記載の無線データ網の動作方法。
【請求項１】
複数のネットワークノード（ＭＮ）を有するメッシュ型の無線データ網の動作方法であって、
前記無線データ網のネットワークノード（ＭＮ）である送信元ノード（ＳＮ）から、該無線データ網のネットワークノード（ＭＮ）である１つまたは複数の中継ノード（ＩＮ）を介して、該無線データ網のネットワークノード（ＭＮ）である送信先ノード（ＤＮ）へデータフレームを伝送する、無線データ網の動作方法において、
前記ネットワークノード（ＭＮ）のうち、データフレームを受信した少なくとも複数のネットワークノードによるデータフレームの伝送時に、該データフレームの送信先ノード（ＤＮ）に割り当てられたプリカーソルリストに基づいて、該データフレームを送信したネットワークノード（ＭＮ）が該プリカーソルリストに含まれているか否かを検査し、
前記検査の結果がポジティブであった場合、前記データフレームを別の後続のネットワークノード（ＭＮ）へ伝送し、
前記検査の結果がネガティブであった場合、前記データフレームを破棄するか、または誤り処理ルーティンを実施することを特徴とする、無線データ網の動作方法。
【請求項２】
・前記送信元ノード（ＳＮ）と前記送信先ノード（ＤＮ）と前記中継ノード（ＩＮ）とに対してそれぞれ、それぞれ少なくとも１つのエントリを含む経路選択テーブル（ＲＴ）を設け、
・前記経路選択テーブル（ＲＴ）の各エントリごとに、データフレームを該当のネットワークノード（ＭＮ）へデータフレームを伝送できる直接隣接するネットワークノードを含むプリカーソルリストを設ける、請求項１記載の無線データ網の動作方法。
【請求項３】
前記送信元ノード（ＳＮ）によって開始される経路問い合わせメッセージの伝送時と、前記送信先ノード（ＤＮ）によって開始される経路応答メッセージの伝送時に、前記経路選択テーブル（ＲＴ）を作成する、請求項２記載の無線データ網の動作方法。
【請求項４】
前記送信先ノード（ＤＮ）によって開始される経路応答メッセージの枠内で、前記プリカーソルリストを作成または更新する、請求項２または３記載の無線データ網の動作方法。
【請求項５】
前記データフレームは、前記送信先ノード（Ｄ）のアドレスと、該データフレームを送信したネットワークノードのアドレスと、該データフレームを受信するネットワークノードのアドレスと、オプションとして前記送信元ノード（Ｓ）のアドレスとを含み、
前記データフレームを受信したネットワークノードは、該ネットワークノードに割り当てられたアドレスが、該データフレーム内の前記送信先ノードのアドレスに相応するか否かを検査し、
前記検査の結果がポジティブである場合、前記データフレームを受信したネットワークノードは前記データフレームを処理のための別のユニットへ供給し、とりわけＯＳＩ参照モデルのより上位の層へ供給する、請求項１から４までのいずれか１項記載の無線データ網の動作方法。
【請求項６】
前記プリカーソルリスト内のエントリは、媒体アクセス制御（ＭＡＣ）アドレスまたはＩＰアドレスと、該エントリのライフタイムとを含む、請求項１から５までのいずれか１項記載の無線データ網の動作方法。
【請求項７】
前記ネットワークノードが、該ネットワークノードのプリカーソルリストのエントリ内のＭＡＣアドレスまたはＩＰアドレスに相応するアドレスを有するネットワークノードからデータフレームを受信した場合、該エントリのライフタイムを初期値にリセットする、請求項６記載の無線データ網の動作方法。
【請求項８】
前記プリカーソル内のエントリのライフタイムが終了した場合、該エントリを消去する、請求項６または７記載の無線データ網の動作方法。
【請求項９】
前記プリカーソルリスト内のエントリのライフタイムの長さは最大で、前記送信元ノードから前記送信先ノードまでの経路の経路ライフタイム値に等しく、
前記経路ライフタイム値は、ルーティングテーブルのエントリ内に情報として含まれる、請求項６から８までのいずれか１項記載の無線データ網の動作方法。
【請求項１０】
前記プリカーソルリスト内のエントリのライフタイムの更新と、該当するルーティングテーブルエントリ内の経路ライフタイム値の更新とを同時に行う、請求項９記載の無線データ網の動作方法。
【請求項１１】
・前記送信先ノード（ＤＮ）と前記送信元ノード（ＳＮ）との間のデータフレーム伝送ルートにおいて該送信元ノード（ＳＮ）に隣接する中継ノードと、
・該送信元ノード（ＳＮ）と該送信先ノード（ＤＮ）との間のデータフレーム伝送ルートにおいて該送信先ノード（ＤＮ）に隣接する中継ノードと
では、該送信先ノードに対応するルーティングテーブルエントリに対してプリカーソルリストを作成する必要はない、請求項１から１０までのいずれか１項記載の無線データ網の動作方法。
【請求項１２】
前記送信元ノード（ＳＮ）、または前記送信先ノード（ＤＮ）、または、該送信元ノード（ＳＮ）と該送信先ノード（ＤＮ）との間のデータ経路（Ｓ‐Ｂ‐Ａ‐Ｃ‐Ｄ）に存在する前記中継ノードのいずれか１つのうち、いずれかでない別のネットワークノードが該送信元ノードの経路応答メッセージを受信した後、該送信元ノードへの逆方向経路上で次のネットワークノードである別の中継ノードであって、該送信元ノード（ＳＮ）に対するルーティングテーブルエントリのプリカーソルリスト内に該別のネットワークノードを含まない別の中継ノードを介して該送信元ノードへデータフレームを伝送し、
前記別の中継ノードは、前記別のネットワークノードから受信したデータフレームを破棄する、請求項１から１１までのいずれか１項記載の無線データ網の動作方法。
【請求項１３】
前記別のネットワークノードと前記送信元ノードとの間に形成されたデータ経路（Ｇ‐Ｂ‐Ｆ‐Ｓ）を無効として標識する、請求項１２記載の無線データ網の動作方法。
【請求項１４】
前記別のネットワークノードによって、前記送信元ノードまでのルートディスカバリを行う、請求項１３記載の無線データ網の動作方法。
【請求項１５】
前記別のネットワークノードから前記送信元ノード（ＳＮ）まで前記データフレームを伝送する前に、該別のネットワークノードを、前記別の中継ノードの送信元ノードまでの逆方向経路に対するルーティングテーブルエントリのプリカーソルリストに取り込む、請求項１２記載の無線データ網の動作方法。
【請求項１６】
前記別の中継ノードの前記送信元ノードまでの逆方向経路に対するルーティングテーブルエントリのプリカーソルリストに前記別のネットワークノードを取り込むために、前記別のネットワークノードを宛先とし、該送信元ノードをソースとして経路応答メッセージを前記送信元ノードへ送信する、請求項１５記載の無線データ網の動作方法。
【請求項１７】
ネットワークノードに隣接するすべてのネットワークノードのアドレスを、経路応答メッセージの受信時のシーケンス値とともに、該ネットワークノードのプリカーソルリストに一時的なエントリとして入力する、請求項１２記載の無線データ網の動作方法。
【請求項１８】
前記ネットワークノードに隣接し前記経路問い合わせメッセージを送信したネットワークノードを、該ネットワークノードのプリカーソルリストに入力しない、請求項１７記載の無線データ網の動作方法。
【請求項１９】
前記プリカーソルリスト内の前記一時的なエントリに、前記経路問い合わせメッセージによって形成された逆方向経路と同じ値を有するシーケンス値を設ける、請求項１７または１８記載の無線データ網の動作方法。
【請求項２０】
前記送信先ノードによって開始される経路応答メッセージの枠内で前記プリカーソルリスト内にエントリを作成する際に、前記一時的なエントリを該プリカーソルリストから消去する、請求項１７から１９までのいずれか１項記載の無線データ網の動作方法。
【図１】
【図２】
【図３】
【図３Ａ】
【図３Ｂ】
【図３Ｃ】
【図４】
【図４Ａ】
【図４Ｂ】
【図４Ｃ】
【図５】
【図５Ａ】
【図５Ｂ】
【図５Ｃ】
【図５Ｄ】
【図６】
【図６Ａ】
【図６Ｂ】
【図７】
【図７Ａ】
【図７Ｂ】
【図７Ｃ】
【図７Ｄ】
【図８】
【図９】
【図２】
【図３】
【図３Ａ】
【図３Ｂ】
【図３Ｃ】
【図４】
【図４Ａ】
【図４Ｂ】
【図４Ｃ】
【図５】
【図５Ａ】
【図５Ｂ】
【図５Ｃ】
【図５Ｄ】
【図６】
【図６Ａ】
【図６Ｂ】
【図７】
【図７Ａ】
【図７Ｂ】
【図７Ｃ】
【図７Ｄ】
【図８】
【図９】
【公表番号】特表２０１０−５３１５９１（Ｐ２０１０−５３１５９１Ａ）
【公表日】平成２２年９月２４日（２０１０．９．２４）
【国際特許分類】
【出願番号】特願２０１０−５１３８２６（Ｐ２０１０−５１３８２６）
【出願日】平成２０年６月６日（２００８．６．６）
【国際出願番号】ＰＣＴ／ＥＰ２００８／０５７０５７
【国際公開番号】ＷＯ２００９／０００６３０
【国際公開日】平成２０年１２月３１日（２００８．１２．３１）
【出願人】（３９００３９４１３）シーメンス アクチエンゲゼルシヤフト (2,104)
【氏名又は名称原語表記】Ｓｉｅｍｅｎｓ Ａｋｔｉｅｎｇｅｓｅｌｌｓｃｈａｆｔ
【住所又は居所原語表記】Ｗｉｔｔｅｌｓｂａｃｈｅｒｐｌａｔｚ ２， Ｄ−８０３３３ Ｍｕｅｎｃｈｅｎ， Ｇｅｒｍａｎｙ
【Ｆターム（参考）】
【公表日】平成２２年９月２４日（２０１０．９．２４）
【国際特許分類】
【出願日】平成２０年６月６日（２００８．６．６）
【国際出願番号】ＰＣＴ／ＥＰ２００８／０５７０５７
【国際公開番号】ＷＯ２００９／０００６３０
【国際公開日】平成２０年１２月３１日（２００８．１２．３１）
【出願人】（３９００３９４１３）シーメンス アクチエンゲゼルシヤフト (2,104)
【氏名又は名称原語表記】Ｓｉｅｍｅｎｓ Ａｋｔｉｅｎｇｅｓｅｌｌｓｃｈａｆｔ
【住所又は居所原語表記】Ｗｉｔｔｅｌｓｂａｃｈｅｒｐｌａｔｚ ２， Ｄ−８０３３３ Ｍｕｅｎｃｈｅｎ， Ｇｅｒｍａｎｙ
【Ｆターム（参考）】
[ Back to top ]