JP4886852B2

JP4886852B2 - 通信ネットワークにおいてデータパケットをルーティングするための方法とネットワークノード

Info

Publication number: JP4886852B2
Application number: JP2009525066A
Authority: JP
Inventors: バールミヒャエル
Original assignee: Siemens AG
Current assignee: Siemens AG
Priority date: 2006-08-24
Filing date: 2007-08-22
Publication date: 2012-02-29
Anticipated expiration: 2027-08-22
Also published as: DE502007002506D1; US9414297B2; JP2010502069A; CN101507206A; ATE453988T1; WO2008031698A1; US20090196227A1; EP2055056A1; EP2055056B1; CN101507206B

Description

本発明は、請求項１の上位概念に記載されている通信ネットワークにおいてデータをルーティングするための方法および請求項１８の上位概念に記載されている通信ネットワークにおいてデータをルーティングするためのネットワークノードに関する。

データパケットの経路を求める際に、ネットワークノードはデータパケットを例えば可能な限り高速に受信側のネットワークノードに到達させるためにはどの経路においてデータパケットを転送すべきかを決定することが公知である。この工程はいわゆるルーティングとして公知である。ルーティングを実施するための種々のアプローチから種々のルーティングプロトコルが生じている。

その種のルーティングプロトコルによれば、求められたルートがライフタイム（「Lifetime」）、すなわちタイムアウトと関連付けられるが、付加的な制御パケットが無く求められたルートを確認できない場合にはライフタイムによってセットされたタイマの経過後にルーティングテーブルからルートが削除される。

モバイルのいわゆるアドホックネットワーク、殊に無線メッシュネットワーク（wireless mesh networks）に使用され、また距離ベクトル（Distance-Vector）方式に基づくリアクティブ型ルーティングプロトコル、例えばいわゆる「アドホックオンデマンド距離ベクトル」（ＡＯＤＶ）プロトコル（Perkins, C. E., Belding-Royer, E. M., and Das, S. R. "Ad hoc On-Demand Distance Vector (AODV) Routing"IETF Experimental RFC 3561, July 2003. AODV RFCを参照されたい）または「ハイブリッド無線メッシュプロトコル」（ＨＷＭＰ）プロトコル（IEEE P802.11sm/D0.03, Draft amendment to Standard IEEE 802.11 TM: ESS Mesh Networking. IEEE, August 2006, work in Progressを参照されたい）においても同様のことが行われている。

通常の場合、ルートはネットワークにおいてルーティングテーブル内の相応のエントリを介してネットワークノードによって規定されている。送信元ノード（Source）から宛先ノード（Destination）までの経路上の各ネットワークノードは自身のルーティングテーブルに宛先ノードに関するエントリを有し、このエントリは宛先ノードＤまでのルート上の隣接するホップ、すなわち制御すべき隣接するネットワークノードを示す。

ＡＯＤＶプロトコルおよびＨＷＭＰプロトコルは、全てのネットワークノードから送信元ノードまでのいわゆる「反転ルート（reverse routes）」を確立するいわゆる「ルート要求（Route Request）」メッセージ（ＲＲＥＱ）をネットワーク全体にブロードキャストすることにより応答型のルート検索を開始する。宛先ノードは同様に１つまたは複数のＲＲＥＱを受信する。受信した各ＲＲＥＱパケットは送信元ノードまでの考えられるルートを表す。宛先ノードは選択された反転ルートにおいて「ルート応答（Route Reply）」メッセージ（ＲＲＥＰ）をユニキャスト方式で送信し、このＲＲＥＰメッセージはいわゆる「転送ルート（forward route）」を選択された経路上の全てのネットワークノードにエントリする。

このやり方における問題は、ＲＲＥＰが送信元ノードＳに返送されてからこの送信元ノードＳがデータを宛先ノードにＤに送信し始めるときに反転ルートも依然として存在していなければならないので、ＲＲＥＱによって形成される反転ルートのライフタイムは十分に長くなければならないことである。
US 2005/094594 A1からは、ネットワークの目下の有効範囲がルーティングプロシージャの最適化のために求められ、このために端部ノードのライフタイムが使用される方法ならびに装置が公知である。
WO 2005/091576 Aからは、ネットワークの目下の状態データ、例えばバッテリ寿命が最適なルートを決定するために使用される方法および装置が公知である。
W02005/062554 Aからは、データパケットのルーティングが目下のコネクションの状態（「リンク状態（link status）」）を基礎として行われる、ルーティングの効率を高める方法ならびに装置が公知である。

本発明が基礎とする課題は、従来技術の欠点を解消する方法ならびに装置を提供することである。

この課題は、請求項１の上位概念に記載されている方法を基礎として、その特徴部分に記載されている特徴的構成によって解決され、また請求項１８の上位概念に記載されているネットワークノードを基礎として、その特徴部分に記載されている特徴的構成によって解決される。

通信ネットワーク、殊に複数のネットワークノードから形成されている無線通信ネットワークにおいてデータパケットをルーティングするための本発明による方法においては、データパケットのソースとして機能する第１のネットワークノードから、データパケットのシンクとして機能する第２のネットワークノードにデータパケットを伝送するために、データパケットが通信ネットワークの送信元ノードには接続されていない少なくとも１つの別のネットワークノード（Ａ，Ｂ，Ｇ，Ｄ）を用いて伝送され、送信元ノードから出発して、別のネットワークノードがシンクノード（Ｄ）と一致するまで各別のネットワークノードに第１のネットワークメッセージが連続的に転送されるように、少なくとも複数の別のネットワークノードに第１のネットワークメッセージが伝送され、ここで第１のネットワークメッセージはこの第１のネットワークメッセージに対応付けられている第１の有効期間の値を含み、第１のメッセージに基づき、送信元ノードまでの経路上にある次のネットワークノードに関する第１の情報ならびに第１の有効期間の値が目下の別のネットワークノードに一時的に記憶されるように各別のネットワークノードにルート情報が提供され、シンクノードから送信された、第１のネットワークメッセージを確認する第２のネットワークメッセージが送信元ノードによって受信されるまで全ての第１の情報が少なくとも記憶され続けるようにその都度の第１の有効期間の値が記憶される。

この方法によって、ネットワークノードのうちの１つにおけるそれぞれの反転ルートの早期のタイムアウト、もしくは空白部分の発生も回避するライフタイムが反転ルートの一部を成す全てのネットワークノードに対して使用されることが保証されている。さらにはネットワークノードにおける第１の有効期間の値を時点として表すこともできる。これにより有利には、中間ノードが無くともシンクノードに到達することができる。これは全体で僅か２つのノード、すなわちソースとシンクしか存在しない場合にも機能する。

さらには本発明による方法によって、各ルート要求に対して、または各ルート要求を用いて種々のライフタイムをコンフィギュレートすることができるので、ネットワークまたは個々のネットワークノードの目下の特性に良好に適合させることができる。

有利には、第１の有効期間の値が記憶されるが、この記憶は目下のネットワークノード内にその第１の有効期間の値よりも大きい値が既に記憶されている場合には行われない。つまりは必要に応じてより良好に適合されている比較的大きい値を維持し続けることができ、また急速なタイムアウトまたはルート内の空白部分を回避する最小のライフタイムを本発明により確保することも保証される。

さらに有利には、本発明による方法では第１の有効期間の値が動的に生成される。これによって、最小ライフタイムが最適に目下のネットワーク特性に適合されていることが保証されるので、本発明によれば信頼性が高いという利点が達成される。

本方法の別の有利な実施形態によれば、値の形成がＡＯＤＶプロトコルに従い関数
max(ExistingLifetime, MinimalLifetime)
ただし、
MinimalLifetime = (current_time + 2*NET_TRAVERSAL_TIME - 2*HopCount*NODE_TRAVERSAL_TIME)
によって定義されている。ここで、
ExistingLifetimeは、送信元ノードまでの既に存在しているルートのライフタイムを表し、
MinimalLifetimeは、少なくともセットすべきライフタイムの推定値を表し、
current_timeは、目下のシステムタイムを表し、
NET_TRAVERSAL_TIMEは、ネットワークを介するＲＲＥＱの送信の最大持続時間の推定値を表す、ネットワークノード毎に調整可能な第１のパラメータを表し、
HopCountは、ＲＲＥＱの更新されたフィールドrreq.hopcountから取得することができる、目下のノードも含めたネットワークノードまでにＲＲＥＱパケットが通過する別のネットワークノードの数を表し、
NODE_TRAVERSAL_TIMEは、ネットワークノードにおけるパケットの最大処理時間の推定値を表す、ネットワークノード毎に調整可能な第２のパラメータを表す。殊に、正確なHopCountが存在するためには、受信後にHopCountフィールドを１高める必要がある。この実施形態は殊に無線メッシュネットワークに適している。

択一的または付加的に、本方法の有利な実施形態によれば、第１の有効期間の値がＨＷＭＰプロトコルに従い
current_time + HWMP_ACTIVE_ROUTE_TIMEOUT
によって規定される。ただし、
current_timeは、目下のシステムタイムであり、
HWMP_ACTIVE_ROUTE_TIMEOUTはネットワークノード毎にコンフィギュレート可能なパラメータである。ここでもまた標準IEEE802.11に従い公知であるような無線メッシュネットワークとしての特性が得られる。

有利には第１のメッセージがルート要求「ＲＲＥＱ」メッセージとして形成される。何故ならば、このタイプのメッセージは反転ルートを確立するために必要とされ、また関与する全てのネットワークノードに到達するからである。

ＲＲＥＱメッセージが第１の有効期間に関するデータフィールドについて拡張されている場合には、本発明による利点を達成することに殊に適している。ネットワークノードはいずれにせよ必要とされるＲＲＥＱメッセージの評価の際に最小ライフタイムを簡単に抽出することができ、また必要に応じて引き継ぐことができる。これによって得られる大きな利点は、ただ１つのノード（送信元ノードＳ）がルート全体に関するライフタイムを設定することである。したがって、本来的には全て等しいことが望ましい、ノードにおいてセットされる値が種々の値を取る問題は回避される。

有利には、データフィールドに関して４オクテットの長さが確保されている。

ＲＲＥＱメッセージにおける第１の有効期間に関するデータフィールド（rreq.lifetime）を上述の有効期間に応じた値を用いてＡＯＤＶプロトコルに従いソースノードにおいてセットすることができる。ただし
rreq.lifetime = 2*NET_TRAVERSAL_TIME
ここで、
NET_TRAVERSAL_TIMEは、ネットワークノード毎に調整可能な第１のパラメータを表し、この第１のパラメータはネットワークを介するＲＲＥＱの送信の最大持続時間の推定値を表す。この実施形態は殊に無線メッシュネットワークに適している。

択一的または付加的に、ＲＲＥＱメッセージにおける第１の有効期間の値が送信元ノードにおいてＨＷＭＰプロトコルに従い
rreq.lifetime = HWMP_ACTIVE_ROUTE_TIMEOUT
によって規定される。ただし、
HWMP_ACTIVE_ROUTE_TIMEOUTは、ネットワークノード毎にコンフィギュレート可能なパラメータである。ここでもまた標準IEEE802.11に従い公知であるような無線メッシュネットワークとしての特性が得られる。

択一的または付加的に、ＲＲＥＱメッセージにおける第１の有効期間の値を最小限必要とされる有効期間の値よりも大きい任意の値を用いて送信元ノードにおいてセットすることができる。

ＲＲＥＱメッセージを処理する別のネットワークノードは反転ルートの第１の有効期間に関して、第１の有効期間の値rreq.lifetimeを引き継ぐ。

別の有利な実施形態においては、第１の有効期間が相応のネットワークノードに記憶される前に、別のネットワークノードが反転ルートの第１の有効期間をＡＯＤＶの上記の式
max (ExistingLifetime, MinimalLifetime)
ただし
MinimalLifetime = (current_time + rreq.lifetime - X*rreq.hopcount*NODE_TRAVERSAL_TIME)
ただしＸは｛１，２｝
によって適合させる。ＲＲＥＱメッセージにおける第１の有効期間は変更されないままである。この実施形態はＡＯＤＶプロトコルの使用に際しＸ＝２にセットされている場合には殊に有利である。何故ならば、ＲＲＥＰは純粋に理論的に同一の残りのライフタイムで各中間ノードに達するからである。Ｘ＝１により残りのライフタイムは送信元ノードに近付くほど増加するので、このことは反転ルートの最後の部分を比較的長く使用することに関して有利である。

択一的に、この適合をＲＲＥＱメッセージにおける第１の有効期間の低減によって達成することができる。この第１の有効期間は関数
rreq.lifetime := rreq.lifetime - X * NODE_TRAVERSAL_TIME
ただしＸは｛１，２｝、
に応じて更新される。この更新はこの有効期間が目下のネットワークノードにおける第１の有効期間として記憶される前に実施される。転送されるＲＲＥＱメッセージは更新され適合されたライフタイムを含む。

本発明による方法を有利に具体化した実施形態はライフタイムの値のセットに関して以下のヴァリエーションによって表される：
ａ．（中間）ノードにおけるセット
ｉ．max(ExistingLifetime, MinimalLifetime)、ただしMinimalLifetimeはこのＲＲＥＱに関して使用されるべきライフタイムである
ｉｉ．ＡＯＤＶプロトコルに従う：max(ExistingLifetime, MinimalLifetime)、ただしMinimalLifetime = (current_time + 2*NET_TRAVERSAL_TIME - 2*rreq.hopcount*NODE_TRAVERSAL_TIME)
ｉｉｉ．改良されたＡＯＤＶプロトコルに従う：max(ExistingLifetime, MinimalLifetime)、ただしMinimalLifetime = (current_time + 2*NET_TRAVERSAL_TIME - rreq.hopcount*NODE_TRAVERSAL_TIME)
ｉｖ．ＨＷＭＰプロトコルに従う：max(ExistingLifetime, MinimalLifetime)、ただしMinimalLifetime = HWMP_ACTIVE_ROUTE_TIMEOUT
ｖ．max(ExistingLifetime, MinimalLifetime)、ただしMinimalLifetime = rreq.lifetime
ｖｉ．max(ExistingLifetime, MinimalLifetime)、ただしMinimalLifetime = (current_time + rreq.lifetime - X*rreq.hopcount*NODE_TRAVERSAL_TIME)、ここでX = {1,2}
ｂ．第１の有効期間の値のセット（rreq.lifetime）
ｉ．固定の値をＡＯＤＶプロトコルの場合と同様にセットする、ただしrreq.lifetime = 2*NET_TRAVERSAL_TIME（何故ならば送信元ノードにおいては hopcount = 0であるので、第２項は省略される）。中間ノードではＲＲＥＱにおけるこの値が引き継がれる。
ｉｉ．固定の値をＨＷＭＰプロトコルの場合と同様にセットする、ただしrreq.lifetime = HWMP_ACTIVE_ROUTE_TIMEOUT。中間ノードではＲＲＥＱにおけるこの値が引き継がれる。
ｉｉｉ．十分に大きいrreq.lifetimeに関する固定の値をセットする。中間ノードではＲＲＥＱにおけるこの値が引き継がれる。
ｉｖ．ｉ〜ｉｉｉと同様に実施されるが、中間ノードではＲＲＥＱにおけるライフタイムに関する値がrreq.lifetime := rreq.lifetime - X*rreq.hopcount*NODE_TRAVERSAL_TIME)、ただしX = {1,2}、を用いて適合される。

このようにして、ライフタイムを時点（ここではcurrent_timeである）としてセットする技術的な実現形態が達成される。択一的または付加的に、ルーティングテーブルにおいてライフタイムを期間としてセットすることができる。

第２のメッセージがルート応答「ＲＲＥＰ」メッセージとして形成される場合には、本発明の実施形態は殊に無線メッシュネットワークにおいてサポートされる。シンクノードにおいてＲＲＥＰメッセージの第２の有効期間の値が第１の有効期間の値と同じ値にセットされる場合には有利である。往路と復路がほぼ同じ、または非常に近いライフタイムを有する場合には有利である。

本発明によるネットワークノードは、本発明による方法を実施する手段を有しており、それにより本発明による方法の利点も提供できるので、この本発明による方法を実現することができる。

本発明のさらなる詳細ならびに利点を図面に示した本発明の実施例に基づき詳細に説明する。

本発明が基礎とする例示的なシナリオとしての無線メッシュネットワークを示す。ＨＷＭＰプロトコルに従いライフタイムに関するデータフィールドついて本発明により拡張されたＲＲＥＱメッセージの実施例を示す。ルーティングテーブルに基づき示された、本発明による方法の実施例の概略的な経過の一部を示す。ルーティングテーブルに基づき示された、本発明による方法の実施例の概略的な経過の一部を示す。ルーティングテーブルに基づき示された、本発明による方法の実施例の概略的な経過の一部を示す。ルーティングテーブルに基づき示された、本発明による方法の実施例の概略的な経過の一部を示す。ルーティングテーブルに基づき示された、本発明による方法の実施例の概略的な経過の一部を示す。

図１には、従来技術によるネットワーク内に設けることができるようなネットワークノードの例示的な配置構成が示されている。したがってネットワークノードのこの配置構成は、問題を発見するための本発明の基本的な着想を説明するための１つのシナリオを示す。

例示的に無線メッシュネットワークとして構成されているネットワークノードが概略的に示されている。このネットワークに関して存在する無線コネクションは破線によって示唆されている。

さらにこのシナリオにおいてはデータの送信を行う送信元ノードＳが示されており、この送信元ノードＳから宛先ノードＤへのデータの伝送が所望されている。

このために送信元ノードＳは基本的に、ネットワークにおいて送信元ノードＳと宛先ノードＤとの間に存在する全てのネットワークノードＡ〜Ｇを使用することができる。

適切な経路を発見するために、ＡＯＤＶプロトコルおよびＨＷＭＰプロトコルに従い「ルート要求」メッセージ（ＲＲＥＱ）を用いて必要なルート検索が実施され、このルート要求メッセージにより全てのネットワークノードＡ〜Ｇおよび宛先ノードＤから送信元ノードＳまでの「反転ルート」、すなわち送信元ノードＳへと向かうルートが確立される。

上述したように、宛先ノードＤは同様に１つまたは複数のＲＲＥＱを受信する。受信した各ＲＲＥＱパケットは送信元ノードＳまでの考えられるルートを表す。

宛先ノードＤは選択された反転ルートにおいて「ルート応答」メッセージ（ＲＲＥＰ）をユニキャスト方式で送信する。このルート応答メッセージによりいわゆる「転送ルート」、すなわち宛先ノードＤへと向かうルートが選択された経路上の全てのネットワークノードＡ〜Ｇならびに送信元ノードＳにエントリされる。

ＲＲＥＱによって形成される反転ルートのライフタイムは十分に長くなくてはならない。何故ならば、ＲＲＥＰが送信元ノードＳに返送され、この送信元ノードＳが宛先ノードＤへのデータ伝送を開始する場合には反転ルートも依然として存在していなければならないからである。

ＡＯＤＶプロトコルによれば、反転ルートのライフタイムは各ネットワークノードにおいて個別にコンフィギュレートされた定数に基づき計算される。この計算は以下のように実施される：
ＲＲＥＱメッセージを受信すると、送信元ノードに対応付けられているＩＰアドレスの反転ルートのライフタイムに関するエントリがＡＯＤＶプロトコルに従い、最大値
（ExistingLifetime, MinimalLifetime）
としてその都度セットされる。ただしＡＯＤＶプロトコルに従い、
MinimalLifetime = (current time + 2*NET_TRAVERSAL_TIME - 2*HopCount*NODE_TRAVERSAL_TIME)
が規定されている。

ExistingLifetimeは場合によっては既に存在している送信元ノードＳまでの経路のライフタイムである。NET_TRAVERSAL_TIMEおよびNODE_TRAVERSAL_TIMEは、ネットワークノード毎にコンフィギュレート可能であり、且つ各ノードにおいてセットされているパラメータである。これらの値が全てのノードにおいて等しい場合には、本発明の実施にとって殊に有利である。

ＨＷＭＰプロトコルに従い反転ルートのライフタイムは、各メッシュネットワークノードにおいて個別にコンフィギュレートすべき固定のパラメータHWMP_ACTIVE_ROUTE_TIMEOUTに応じてセットされている。

上記のようにコンフィギュレート可能なパラメータに関して相応の標準はデフォルト値を設定している。しかしながら固有の値をパラメータに割り当てることもできる。

ここで選択した例のような従来技術から公知のシナリオでは、ＡＯＤＶプロトコルまたはＨＭＷＰプロトコルを使用した場合でもＲＲＥＱメッセージによって形成される反転ルートの全てのライフタイムが十分に長いことを保証しなくてはならないことが本発明により分かった。このライフタイムが該当するいずれかのネットワークノードＡ〜ＧおよびＤにおいて過度に短いことを回避しなければならない。何故ならば、そのような短いライフタイムを回避できない場合には反転ルートに空白部分もしくは中断部分が生じる虞があるからである。

したがって本発明によれば、ＲＲＥＱメッセージによってセットされたルートのライフタイムに関するフィールドがＲＲＥＱメッセージのデータフィールドに挿入されることよってＲＲＥＱメッセージが拡張されることが提案され、このことは図２に示されている実施例から見て取れる。

本発明の別の実施例として、目下のところＨＷＭＰプロトコルにおいてのみ知られているルート通知（Root Announcement）メッセージも、このメッセージによってセットされている、通知が行われたルートネットワークノードまでのルートのライフタイムに関するフィールドをメッセージのデータフィールドに含むべきである。

本発明によれば、ＲＲＥＱを形成する送信元ノードＳがライフタイムに関する本発明によるフィールド内に、このＲＲＥＱメッセージを用いて形成された送信元ノードＳまでの反転ルートのライフタイムがＲＲＥＱメッセージを受信するネットワークノードのルーティングテーブル内にセットされる期間をエントリするので、シンクノードから送信された、第１のネットワークメッセージを確認する第２のネットワークメッセージが送信元ノードによって受信されるまで少なくとも反転ルートは存在する。

送信元ノードＳは例えばＡＯＤＶプロトコルのようにライフタイムに関する値をＲＲＥＱパケットにおいて、送信元ノードに関してパラメータhopcountの値は「０」であることを考慮して、上記においてＡＯＤＶプロトコルについて説明した式2*NET_TRAVERSAL_TIMEに応じてセットすることができ、他方ではＨＷＭＰプロトコルに従い送信元ノードＳはライフタイムに関する値をＲＲＥＱパケットにおいて例えばパラメータHWMP_ACTIVE_ROUTE_TIMEOUTを用いてセットすることができる。

ＲＲＥＱパケットを受信したネットワークノードは続いて、ＲＲＥＱパケットによって既知にされた送信元ノードＳまでのルートを形成するか更新する。送信元ノードＳまでの反転ルートが形成されると、相応のネットワークノードはＲＲＥＱパケットからのライフタイム値をネットワークノードのルーティングテーブルにおけるルートのライフタイムフィールドに挿入する。

送信元ノードＳまでのルートが既に存在する場合には、本発明によればルーティングテーブルにおける相応のライフタイムフィールドがこのルーティングテーブル内に存在するライフタイムの最大値およびＲＲＥＱパケットからのライフタイムを用いて関数max(ExistingLifetime, rreq.lifetime)に従い更新される。

有利には、ＲＲＥＱパケットからのライフタイムの値は、ネットワークノードがデータパケットの転送によって相応のルートのライフタイムを更新する際に使用できるようにするためにネットワークノードに記憶されるべきである。

択一的または付加的に、ＲＲＥＱメッセージに対するＲＲＥＰメッセージを形成するネットワークノードはＲＲＥＱパケットからのライフタイムの値をＲＲＥＰパケット内のライフタイムに関する値として使用することができる。これは有利であるが、必ずしも必要ではない。

本発明によればＲＲＥＱメッセージに関して全てのネットワークノードが、ＲＲＥＱメッセージにおいて設定されている、送信元ノードＳまでの反転ルートに関するライフタイムを少なくとも使用することが保証される。

これによって、ネットワークノードにおける反転ルートの非常に速いタイムアウトに起因するルート内の個々の空白部分が回避される。

さらに本発明によれば反転ルートのライフタイムは所定のルート要求にのみ結び付けられている。これによって種々のルート要求が種々のライフタイムを設定することができる。従来技術によれば全てのネットワークノードにおいてライフタイムに関して同一の値がコンフィギュレートされるので、その値を変更無く全てのＲＲＥＱに対して使用しなければならない。

図２に示されている例のような本発明によるライフタイムの挿入を使用して、図１に示した例示的なトポロジに基づき以下では本発明により実現されるルーティングの経過を説明する。

宛先ノードＤまでのルートを求めるために、送信元ノードＳは検索された目的地としての宛先ノードＤおよびパラメータrreq.lifetime＝５によって設定されたライフタイムを用いてルート要求を開始する。

図３Ａにおいては、ＲＲＥＱメッセージが送信される前の選択されたメッシュネットワークノードＡ〜Ｓのルーティングテーブルが示されている。

この状態から出発して、図３Ｂには第１のネットワークノードＡによって送信元ノードＳからのＲＲＥＱメッセージが受信された後の同一のネットワークノードが示されている。この実施例においては、第１のネットワークノードＡによってＲＲＥＱメッセージが処理された後にこの第１のネットワークノードＡのルーティングテーブルは変更されていないことが見て取れる。これは既に存在する送信元ノードＳまでのルートの既存のライフタイムがパラメータrreq.lifetimeによって設定された値よりも大きいという結果を表しており、したがって絶対的に必要とされるライフタイムを本発明により確保することは確実に保証されている。

図３Ｃにおいては、第２のネットワークノードＢが第１のネットワークノードＡから転送されたＲＲＥＱメッセージを受信するとテーブルはどのように表されるかが示されている。この第２のネットワークノードＢにおいても第１のネットワークノードＡと同様に既存のルーティングテーブルは変更されていないことが見て取れる。何故ならば、この第２のネットワークノードＢにもパラメータrreq.lifetimeによって設定された値よりも大きいライフタイムの値がエントリされていたからである。

図３Ｄにおいては、第２のネットワークノードＢがＲＲＥＱメッセージを宛先ノードＤまでの経路上にある第３のネットワークノードＧに転送するとテーブルはどのように表されるかが示されている。第２のネットワークノードＢから転送されたＲＲＥＱメッセージが第３のネットワークノードＧによって受信された後に、ＲＲＥＱメッセージの評価の結果として第３のネットワークノードＧに関するテーブルにエントリが行われたことが見て取れる。

第３のネットワークノードＧはＲＲＥＱメッセージを受信する時点まで送信元ノードＳまでのルートを有していなかったのでこのエントリが行われている。さらには、第３のネットワークノードＧがＲＲＥＱメッセージから取得することができたライフタイム（rreq.lifetime＝５）もテーブルにエントリされる。何故ならば、それまで第３のネットワークＧはライフタイムに関する値を有しておらず、またパラメータrreq.lifetimeの値によって本発明に従いライフタイムの最小必要値を取得して設定したからである。

最後に、宛先ノードＤが第３のネットワークノードＧから転送されたＲＲＥＱメッセージを受信する。宛先ノードＤはそれまで送信元ノードＳまでのルートを有していなかったのでルートがエントリされる。これは図３Ｅに示されている。さらには第３のネットワークノードＧの場合と同じやり方で、ＲＲＥＱパケットに包含されているパラメータrreq.lifetimeからライフタイムが引き継がれる。

したがって本発明による方法を使用することにより、送信元ノードＳまでの反転ルートに関する全てのエントリが値５の少なくとも１つのライフタイムを有し、このライフタイムは所属のＲＲＥＰメッセージが送信元ノードＳに到達するまでに関与する全てのネットワークノードが反転ルートを維持することを保証する。

Claims

通信ネットワーク、例えば複数のネットワークノード（Ａ〜Ｓ）から形成されている無線通信ネットワークにおいてデータパケットをルーティングするための方法において、
ａ）前記データパケットのソースとして機能する第１のネットワークノード（Ｓ）から、データパケットのシンクとして機能する第２のネットワークノード（Ｄ）にデータパケットを伝送するために、前記データパケットを少なくとも１つの別のネットワークノード（Ａ，Ｂ，Ｇ，Ｄ）を用いて伝送し、
ｂ）第１の有効期間の値を含む第１のネットワークメッセージを送信元ノードから出発して少なくとも前記別のネットワークノードに伝送し、該別のネットワークノードがシンクノード（Ｄ）と一致するまで前記第１のネットワークメッセージを各別のネットワークノードに連続的に転送し、
ｃ）前記第１のメッセージに基づき各別のネットワークノードにルート情報を提供し、目下の別のネットワークノードに送信元ノードまでの経路上にある次のネットワークノードに関する第１の情報ならびに第１の有効期間の値を一時的に記憶し、
ｄ）シンクノードから送信された、第１のネットワークメッセージを確認する第２のネットワークメッセージが送信元ノードによって受信されるまで全ての第１の情報を少なくとも記憶し続けるようにその都度の第１の有効期間の値を記憶することを特徴とする、通信ネットワークにおいてデータパケットをルーティングするための方法。
前記第１のネットワークメッセージをルート要求「ＲＲＥＱ」メッセージとして形成する、請求項１記載の方法。
前記第１の有効期間の値が目下のネットワークノード内に既に記憶されている値よりも大きい場合に記憶し、小さい場合には記憶しない、請求項２記載の方法。
前記第１の有効期間に関する値を関数
max(ExistingLifetime, MinimalLiftime)
によって求め、求められた値を記憶し、ここで、
ExistingLifetimeは、前記ソースノードまでの既に存在しているルートのライフタイムを表し、
MinimalLifetimeは、少なくともセットすべきライフタイムの推定値を表す、請求項３記載の方法。
前記第１の有効期間に関する値をＡＯＤＶプロトコルに従い関数
max(ExistingLifetime, MinimalLifetime)
ただし、
MinimalLifetime = (current_time + 2*NET_TRAVERSAL_TIME - 2*HopCount*NODE_TRAVERSAL_TIME)
によって求め、求められた値を記憶し、ここで、
ExistingLifetimeは、前記ソースノードまでの既に存在しているルートのライフタイムを表し、
MinimalLifetimeは、少なくともセットすべきライフタイムの推定値を表し、
current_timeは、目下のシステムタイムを表し、
NET_TRAVERSAL_TIMEは、ネットワークを介するＲＲＥＱの送信の最大持続期間の推定値を表す、ネットワークノード毎に調整可能な第１のパラメータを表し、
HopCountは、ＲＲＥＱの更新されたフィールドrreq.hopcountから取得することができる、目下のノードも含めたネットワークノードまでにＲＲＥＱパケットが通過する別のネットワークノードの数を表し、
NODE_TRAVERSAL_TIMEは、ネットワークノードにおけるパケットの最大処理時間の推定値を表す、ネットワークノード毎に調整可能な第２のパラメータを表す、請求項２から４までのいずれか１項記載の方法。
前記第１の有効期間に関する値を改良されたＡＯＤＶプロトコルに従い関数
max(ExistingLifetime, MinimalLifetime)
ただし、
MinimalLifetime = (current_time + 2*NET_TRAVERSAL_TIME - HopCount*NODE_TRAVERSAL_TIME)
によって求め、求められた値を記憶し、ここで、
ExistingLifetimeは、前記ソースノードまでの既に存在しているルートのライフタイムを表し、
MinimalLifetimeは、少なくともセットすべきライフタイムの推定値を表し、
current_timeは、目下のシステムタイムを表し、
NET_TRAVERSAL_TIMEは、ネットワークを介するＲＲＥＱの送信の最大持続期間の推定値を表す、ネットワークノード毎に調整可能な第１のパラメータを表し、
HopCountは、ＲＲＥＱの更新されたフィールドrreq.hopcountから取得することができる、目下のノードも含めたネットワークノードまでにＲＲＥＱパケットが通過する別のネットワークノードの数を表し、
NODE_TRAVERSAL_TIMEは、ネットワークノードにおけるパケットの最大処理時間の推定値を表す、ネットワークノード毎に調整可能な第２のパラメータを表す、請求項２から４までのいずれか１項記載の方法。
前記第１の有効期間に関する値をＨＷＭＰプロトコルに従い関数
max(ExistingLifetime, MinimalLiftime)
ただし、
MinimalLifetime = HWMP_ACTIVE_ROUTE_TIMEOUT
によって求め、求められた値を記憶し、ここで、
ExistingLifetimeは、前記ソースノードまでの既に存在しているルートのライフタイムを表し、
HWMP_ACTIVE_ROUTE_TIMEOUTは、ネットワークノード毎にコンフィギュレート可能なパラメータを表す、請求項２から４までのいずれか１項記載の方法。
前記第１の有効期間に関する値を関数
max(ExistingLifetime, MinimalLiftime)
ただし、
MinimalLiftime = rreq.lifetime
によって求め、求められた値を記憶し、ここで、
ExistingLifetimeは、ソースノードまでの既に存在しているルートのライフタイムを表し、
MinimalLifetimeは、少なくともセットすべきライフタイムを表し、
rreq.lifetimeは、前記第１の有効期間の値を表す、請求項７記載の方法。
前記第１の有効期間に関する値をＡＯＤＶプロトコルに従い関数
max(ExistingLifetime, MinimalLifetime)
ただし、
MinimalLifetime = (current_time + rreq.lifetime - X*rreq.hopcount*NODE_TRAVERSAL_TIME)
且つ
X = {1,2}
によって求め、求められた値を記憶し、ここで、
NODE_TRAVERSAL_TIMEは、ネットワークノードにおけるパケットの最大処理時間の推定値を表す、ネットワークノード毎に調整可能な第２のパラメータを表し、
ExistingLifetimeは、前記ソースノードまでの既に存在しているルートのライフタイムを表し、
MinimalLifetimeは、少なくともセットすべきライフタイムを表し、
rreq.lifetimeは、前記第１の有効期間の値を表し、
current_timeは、目下のシステムタイムを表し、
rreq.hopcountは、ＲＲＥＱの更新されたフィールドrreq.hopcountから取得することができる、目下のノードも含めたネットワークノードまでにＲＲＥＱパケットが通過する別のネットワークノードの数を表す、請求項２から４までのいずれか１項記載の方法。
前記第１の有効期間の値を動的に生成し、
ｉ．固定の値をＡＯＤＶプロトコルの場合と同様にセットし、中間ノードではＲＲＥＱにおける前記値を引き継ぎ、ただしrreq.lifetime = 2*NET_TRAVERSAL_TIME（何故ならば送信元ノードにおいては hopcount = 0であるので、第２項は省略される）
ｉｉ．固定の値をＨＷＭＰプロトコルの場合と同様にセットし、中間ノードではＲＲＥＱにおける前記値を引き継ぎ、ただしrreq.lifetime = HWMP_ACTIVE_ROUTE_TIMEOUT
ｉｉｉ．十分に大きいrreq.lifetimeに関する固定の値をセットし、中間ノードではＲＲＥＱにおける前記値を引き継ぎ、
ｉｖ．ｉ〜ｉｉｉと同様に実施されるが、中間ノードではＲＲＥＱにおけるライフタイムに関する値をrreq.lifetime := rreq.lifetime - X*rreq.hopcount*NODE_TRAVERSAL_TIME、ただしX = {1,2}、を用いて適合させる、請求項２から９までのいずれか１項記載の方法。
前記第１の有効期間の値を
rreq.lifetime = 2*NET_TRAVERSAL_TIME
によって決定し、ここで、
rreq.lifetimeは、前記第１の有効期間の値を表し、
NET_TRAVERSAL_TIMEは、ネットワークを介するＲＲＥＱの送信の最大持続期間の推定値を表す、ネットワークノード毎に調整可能な第１のパラメータを表す、請求項９記載の方法。
前記第１の有効期間の値を
rreq.lifetime = HWMP_ACTIVE_ROUTE_TIMEOUT
によって決定し、ここで、
rreq.lifetimeは、前記第１の有効期間の値を表し、
HWMP_ACTIVE_ROUTE_TIMEOUTは、ネットワークノード毎にコンフィギュレート可能なパラメータを表す、請求項９記載の方法。
前記第１の有効期間の値を
rreq.lifetime := rreq.lifetime - X*rreq.hopcount*NODE_TRAVERSAL, TIME)
且つX = {1,2}
によって決定し、ここで、
rreq.lifetimeは、前記第１の有効期間の値を表し、
rreq.hopcountは、ＲＲＥＱの更新されたフィールドrreq.hopcountから取得することができる、目下のノードも含めたネットワークノードまでにＲＲＥＱパケットが通過する別のネットワークノードの数を表し、
NODE_TRAVERSAL_TIMEは、ネットワークノードにおけるパケットの最大処理時間の推定値を表す、ネットワークノード毎に調整可能な第２のパラメータを表す、請求項２から１２までのいずれか１項記載の方法。
ＲＲＥＱメッセージを前記第１の有効期間に関するデータフィールドについて拡張する、請求項２から１２までのいずれか１項記載の方法。
前記データフィールドに関して４オクテットの長さが確保されている、請求項１４記載の方法。
前記第２のネットワークメッセージをルート応答「ＲＲＥＰ」メッセージとして形成する、請求項２から１５までのいずれか１項記載の方法。
前記シンクノード（Ｄ）においてＲＲＥＰメッセージの第２の有効期間の値を第１の有効期間の値と同じ値にセットする、請求項２から１６までのいずれか１項記載の方法。
請求項１から１７までのいずれか１項記載の方法を実行する手段を備えていることを特徴とする、通信ネットワークにおいてデータパケットをルーティングするためのネットワークノード。