(57)【要約】【課題】  ルートメトリックを決定する機械読み取り可能な媒体、方法、装置、およびシステムが開示される。【解決手段】  幾らかの実施形態においては、ノードから他のノードへ送られるパケットの性質が分析される。パケットの性質は、パケットが伝送品質に左右され易いか否か、およびパケットが送信スループットに左右され易いか否か、からなる群の少なくとも１つを示しうる。そして、パケット損失率とデータレートとの間の重み関係が決定されてよく、ここで重み関係は、パケットの性質とともに変化しうる。ノードから他のノードへのルートのルートメトリックは、パケット損失率と、データレートと、重み関係とに基づいて決定されうる。【選択図】  図２
2010515307.tif 000002
【特許請求の範囲】
【請求項１】
パケットの性質を分析する段階と、
ルートのパケット損失率とデータレートとの間の重み関係を決定する段階と、
前記パケット損失率と、前記データレートと、前記重み関係とに基づいて、前記ルートのルートメトリックを決定する段階と、を備え、
前記パケットの前記性質は、前記パケットが伝送品質に左右され易いか否か、および前記パケットが送信スループットに左右され易いか否か、からなる群の少なくとも１つを示し、
前記重み関係は、前記パケットの前記性質とともに変化する、方法。
【請求項２】
前記パケットが前記伝送品質に左右され易い場合、前記重み関係は、前記データレートより前記パケット損失率の重みを大きくすることで決定される、請求項１に記載の方法。
【請求項３】
前記パケットが送信スループットに左右され易い場合、前記重み関係は、前記パケット損失率より前記データレートの重みを大きくすることで決定される、請求項１に記載の方法。
【請求項４】
前記ルートが複数のリンクを含む場合、前記ルートメトリックは、複数のリンクメトリックの合計により決定され、
各リンクメトリックは前記複数のリンクの各々に対応し、前記パケット損失率と、前記データレートと、前記重み関係との関数である、請求項１に記載の方法。
【請求項５】
前記ルートメトリックは、
【数１】
2010515307.tif 000011
に基づいて決定され、ｍｅｔｒｉｃｒｏｕｔｅは前記ルートメトリックを表し、ｍｅｔｒｉｃｌｉｎｋは前記ルートの各リンクの各リンクメトリックを表し、ｎは前記ルートが有するリンクの数を表す整数であり、ｒａｔｅは前記データレートを表し、ｐｒａｔｅは前記データレートにおける前記パケット損失率を表し、ａおよびｂは前記パケット損失率と前記データレートとの間の前記重み関係を決定するパラメータである、請求項１に記載の方法。
【請求項６】
前記ルートメトリックは、
【数２】
2010515307.tif 000012
に基づいて決定され、ｍｅｔｒｉｃｒｏｕｔｅは前記ルートメトリックを表し、ｍｅｔｒｉｃｌｉｎｋは、前記ルートの各リンクの各リンクメトリックを表し、ｎは前記ルートが有するリンクの数を表す整数であり、ｒａｔｅは前記データレートを表し、ｐｒａｔｅは前記データレートにおける前記パケット損失率を表し、ａおよびｂは前記パケット損失率と前記データレートとの間の前記重み関係を決定するパラメータである、請求項１に記載の方法。
【請求項７】
パケットの性質を分析するパケット分析ロジックと、
ルートのパケット損失率とデータレートとの間の重み関係を決定して、前記パケット損失率と、前記データレートと、前記重み関係とに基づいて、前記ルートのルートメトリックを決定するメトリックロジックと、を備え、
前記性質は、前記パケットが伝送品質に左右され易いか否か、および前記パケットが送信スループットに左右され易いか否か、からなる群の少なくとも１つを示し、
前記重み関係は、前記パケットの前記性質とともに変化する、装置。
【請求項８】
前記パケットが前記伝送品質に左右され易い場合、前記重み関係は、前記データレートより前記パケット損失率の重みを大きくすることで決定される、請求項７に記載の装置。
【請求項９】
前記パケットが送信スループットに左右され易い場合、前記重み関係は、前記パケット損失率より前記データレートの重みを大きくすることで決定される、請求項７に記載の装置。
【請求項１０】
前記ルートが複数のリンクを含む場合、前記ルートメトリックは、複数のリンクメトリックの合計により決定され、
各リンクメトリックは前記複数のリンクの各々に対応し、前記パケット損失率と、前記データレートと、前記重み関係との関数である、請求項７に記載の装置。
【請求項１１】
前記ルートメトリックは、
【数１】
2010515307.tif 000013
に基づいて決定され、ｍｅｔｒｉｃｒｏｕｔｅは前記ルートメトリックを表し、ｍｅｔｒｉｃｌｉｎｋは前記ルートの各リンクの各リンクメトリックを表し、ｎは前記ルートが有するリンクの数を表す整数であり、ｒａｔｅは前記データレートを表し、ｐｒａｔｅは前記データレートにおける前記パケット損失率を表し、ａおよびｂは前記パケット損失率と前記データレートとの間の前記重み関係を決定するパラメータである、請求項７に記載の装置。
【請求項１２】
前記ルートメトリックは、
【数２】
2010515307.tif 000014
に基づいて決定され、ｍｅｔｒｉｃｒｏｕｔｅは前記ルートメトリックを表し、ｍｅｔｒｉｃｌｉｎｋは、前記ルートの各リンクの各リンクメトリックを表し、ｎは前記ルートが有するリンクの数を表す整数であり、ｒａｔｅは前記データレートを表し、ｐｒａｔｅは前記データレートにおける前記パケット損失率を表し、ａおよびｂは前記パケット損失率と前記データレートとの間の前記重み関係を決定するパラメータである、請求項７に記載の装置。
【請求項１３】
パケットの性質を分析するパケット分析ロジックと、
複数のルートのうちの各ルートのパケット損失率とデータレートとの間の重み関係を決定して、前記複数のルートに対する複数のルートメトリックを決定するメトリックロジックとを備え、
前記パケットの前記性質は、前記パケットが伝送品質に左右され易いか否か、および前記パケットが送信スループットに左右され易いか否か、からなる群の少なくとも１つを示し、
前記複数のルートメトリックのうちの各ルートメトリックは、前記各ルートに対応し、前記各ルートの前記パケット損失率と、前記データレートと、前記重み関係とに基づいて決定され、
前記重み関係は、前記パケットの前記性質とともに変化する、装置。
【請求項１４】
前記複数のルートメトリックに基づいて、前記パケットを振り分けるルートを前記複数のルートから選択するルートロジックをさらに備える、請求項１３に記載の装置。
【請求項１５】
ドライバをさらに備え、
前記ドライバは、前記パケットの前記性質に対応するルートを表から探し、前記表が、前記ルートを記録していない場合、前記パケットの前記性質を含むルート要求を複数の隣り合うノードに送り、複数のルート要求返信を受信し、
前記複数のルート要求返信の各々は、前記複数の隣り合うノードの各々からのものであり、サブルートを含む、請求項１３に記載の装置。
【請求項１６】
前記メトリックロジックは、前記サブルートのサブルートメトリックにさらに基づいて、前記各ルートの前記各ルートメトリックを決定する、請求項１５に記載の装置。
【請求項１７】
前記パケットが前記伝送品質に左右され易い場合、前記重み関係は、前記データレートより前記パケット損失率の重みを大きくすることで決定される、請求項１３に記載の装置。
【請求項１８】
前記パケットが送信スループットに左右され易い場合、前記重み関係は、前記パケット損失率より前記データレートの重みを大きくすることで決定される、請求項１３に記載の装置。
【請求項１９】
前記メトリックロジックは、前記各ルートメトリックを、
【数１】
2010515307.tif 000015
に基づいて決定し、ｍｅｔｒｉｃｒｏｕｔｅは前記各ルートメトリックを表し、ｍｅｔｒｉｃｌｉｎｋは前記各ルートの各リンクの各リンクメトリックを表し、ｎは前記各ルートが有するリンクの数を表す整数であり、ｒａｔｅは前記各ルートの前記データレートを表し、ｐｒａｔｅは前記データレートにおける前記パケット損失率を表し、ａおよびｂは前記パケット損失率と前記データレートとの間の前記重み関係を決定するパラメータである、請求項１３に記載の装置。
【請求項２０】
前記メトリックロジックは、前記ルートメトリックを、
【数２】
2010515307.tif 000016
に基づいて決定し、ｍｅｔｒｉｃｒｏｕｔｅは前記各ルートメトリックを表し、ｍｅｔｒｉｃｌｉｎｋは前記各ルートの各リンクの各リンクメトリックを表し、ｎは前記各ルートが有するリンクの数を表す整数であり、ｒａｔｅは前記各ルートの前記データレートを表し、ｐｒａｔｅは前記データレートにおける前記パケット損失率を表し、ａおよびｂは前記パケット損失率と前記データレートとの間の前記重み関係を決定する整数である、請求項１３に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
メッシュネットワークでルートメトリックを計測するには一般に、ＥＴＸ（予期送信カウント）およびＥＴＴ（予期送信時間）という、２つのアルゴリズムが利用されうる。ＥＴＸメトリックは、ルート沿いに隣り合う２つのノード間の各リンクのパケット損失率を計測しうる。ＥＴＴメトリックは、パケット損失率とデータレートとを考慮に入れて、ｍｉｎ｛ＥＴＸｒａｔｅ／Ｒａｔｅ｝を各リンクのメトリックとして利用してよく、この中で、ＥＴＸｒａｔｅは異なるデータレートにおける異なるパケット損失率を表しうる。
【図面の簡単な説明】
【０００２】
本発明を、添付図面で限定ではなく例示により示す。例示を簡略化且つ明瞭化すべく、図面の部材は必ずしも原寸に比例して描かれていない。例えば、幾らかの部材の寸法は他の部材に比して強調されて明瞭化を図る場合がある。さらに、適切と考慮される場合には、図面間で参照符号を繰り返すことで、対応する、または類似した部材であることを示している。
【０００３】
【図１】複数のノードを含むメッシュネットワークの１実施形態を示す。
【０００４】
【図２】メッシュネットワークの１ノードの実施形態を示す。
【０００５】
【図３】メッシュネットワークのノードによるルートメトリックによるルート選択方法の１実施形態を示す。
【発明を実施するための形態】
【０００６】
以下の記載においては、ルートメトリックを決定する技術を記載する。以下の記載においては、ロジック実装、疑似コード、オペランド指定法、資源パーティション／共有／複製実装、システムコンポーネント間の相互関係、ロジックパーティンション／統合選択等の幾多の特定の詳細を述べて、本願のより完全な理解を促す。しかし、本発明は、これら特定の詳細なしに実施が可能である。他の場合には、制御構造、ゲートレベル回路および完全なソフトウェア命令シーケンスは詳細には示さないことで、本発明を曖昧にしないよう配慮している。当業者にとっては、本記載を利用して、不当な実験をすることなく適切な機能を実行することができる。
【０００７】
本明細書における「１実施形態（one embodiment）」、「１つの実施形態(an embodiment)」、「１例示的実施形態（an example embodiment）」といった記載は、記載されている実施形態が特定のフィーチャ、構造、または性質を含みうるが、全ての実施形態が必ずしもその特定のフィーチャ、構造、または性質を含まなくてはならないということではない。さらに、このような言い回しの全てが必ずしも同じ実施形態のことを示すわけではない。さらに、特定のフィーチャ、構造、または性質が１つの実施形態との関連で記載されている場合、明示されていようがいまいが、当業者の知識の範囲で、他の実施形態との兼ね合いからそのフィーチャ、構造、または性質を変更することができる。
【０００８】
本発明の実施形態は、ハードウェア、ファームウェア、ソフトウェア、またはそれらの任意の組み合わせによって実装可能である。本発明の実施形態は、さらに、１以上のプロセッサが読み取り、および実行できる機械読み取り可能な媒体に記憶される命令として実装することができる。機械読み取り可能な媒体には、機械（例えばコンピュータデバイス）が読み取り可能な形で情報を記憶、または送信する任意の機構が含まれうる。例えば、機械読み取り可能な媒体は、読み取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、磁気ディスク記憶媒体、光学記憶媒体、フラッシュメモリデバイス、電気、光学、音声、または他の形式の伝播信号（例えば、搬送波、赤外線信号、デジタル信号等）およびその他を含みうる。
【０００９】
図１は、複数のノードを含むメッシュネットワーク１の１実施形態を示す。図示されているように、メッシュネットワークは４つのノード１１０、１２０、１３０、および１４０を含みうる。しかし、メッシュネットワーク１は任意の数のノードを含みうることを理解されたい。各ノードは、１以上の隣り合うノードを有してよく、２つの隣り合うノードは互いに無線リンクを介して通信してよい。ノードの例には、メインフレームコンピュータ、ミニコンピュータ、パソコン、携帯型コンピュータ、ラップトップコンピュータ、およびデータを送信、受信、および処理する他のデバイスが含まれてよい。
【００１０】
メッシュネットワークのルーティングには、ＡＯＤＶ（Ad-hoc On Demand Distance Vector Routing）プロトコル等、多くのプロトコルが利用されうる。これらプロトコルは、パケット損失率およびデータレートといった様々な要素に基づいて、送信先ノード（例えばノード１４０）へ送信元ノード（例えばノード１１０）からデータを振り分けるルートを決定してよい。ルーティングプロトコルは、送信元ノードと送信先ノードとの間の各ルートの特定の性質を計測するルートメトリックを定義して、このルートメトリックに基づいてデータを振り分けるルートを選択してよい。例えば、ノード１１０からノード１４０へは、ノード１１０、１２０および１４０を通るルートと、ノード１１０、１３０、および１４０を通るルートという、２つのルートが存在しうる。ルーティングプロトコルは、各ルートのルートメトリックを計測して、このルートメトリックに基づいて、ノード１１０とノード１４０との間でデータを振り分けるルートを選択してよい。
【００１１】
図１はメッシュネットワークを示しているが、本発明は他の種類のネットワークへの利用も可能であることを理解されたい。
【００１２】
図２は、メッシュネットワークの１ノードの実施形態を示す。図示されているように、ノードは、１以上のプロセッサ２１、メモリ２２、チップセット２３、ネットワークインタフェース２４、ファームウェア２５、そしてまた他のコンポーネントを含みうる。１以上のプロセッサ２１は、プロセッサバス等の１以上のバスを介して、様々なコンポーネント（例えばチップセット２３）と連通可能に連結されてよい。プロセッサ２１は、例えばカリフォルニア州サンタクララのインテルコーポレーションから入手可能なＩｎｔｅｌ(r)Ｘｅｏｎ（登録商標）、Ｉｎｔｅｌ(r)Ｐｅｎｔｉｕｍ（登録商標）、Ｉｎｔｅｌ(r)Ｉｔａｎｉｕｍ（登録商標）アーキテクチャを含む適切なアーキテクチャ下でコードを実行できる１以上のプロセッサコアを含む集積回路（ＩＣ）として実装することができる。
【００１３】
メモリ２２は、オペレーティングシステム２０１およびルーティングアプリケーション２０２の形で命令およびデータを記憶することができる。メモリ２２の例には、同期ダイナミックＲＡＭ（ＳＤＲＡＭ）デバイス、ＲＡＭＢＵＳダイナミックＲＡＭ（ＲＤＲＡＭ）デバイス、ＤＤＲ（double data rate）メモリデバイス、ＳＲＡＭ（static random access memory）、およびフラッシュメモリデバイス等の半導体デバイスの１または任意の組み合わせが含まれうる。
【００１４】
オペレーティングシステム２０１は、ノードがシステム資源を実行・管理することで性能を最適化することができるタスクを管理してよい。オペレーティングシステム２０１の例には、異なるバージョンのＬｉｎｕｘ(r)、Ｍｉｃｒｏｓｏｆｔ(r)、Ｗｉｎｄｏｗｓ(r)、およびＶｘＷｏｒｋｓ(r)等のリアルタイムオペレーティングシステムが含まれうるが、それらに限られない。オペレーティングシステム２０１は、幾らかのモジュールを含んで、上方のアプリケーションと、下方のハードウェアとの間のブリッジを行い、資源を最適化してよい。例えば、オペレーティングシステム２０１は、ドライバ２０１０を含んで、ユーザアプリケーション（例えばルーティングアプリケーション２０２）からのコマンドに従いデバイス（例えばネットワークインタフェース２４）を制御してよい。
【００１５】
ドライバ２０１０は、ルーティングアプリケーション２０２からルーティングコマンドを受信して、ルーティングコマンドで指定されている送信先ノードにデータを方向付けさせる指示をネットワークインタフェース２４に与えてよい。ドライバ２０１０は、さらに、ルーティングされるパケットの、対象となる性質（例えばパケットが伝送品質に左右され易いか否か（例えばボイスパケットであるか）、あるいは、パケットが送信スループットに左右され易いか（例えばファイル転送プロトコルパケットであるか））を分析してよい。ドライバ２０１０は、ルートメトリック計算および／またはルート決定用に、パケットの性質をルーティングアプリケーション２０２に報告してよい。
【００１６】
ドライバ２０１０は、そのノードから複数の送信先ノードへの複数のルートを記録するルート表２０１１を含みうる。ルート表２０１１は様々な形式であってよい。例えば、ルート表２０１１は複数のエントリを含みえて、これら各エントリは各送信先ノードに対応している。各エントリは、送信先ノード、次のホップノード、ルートメトリック、データレート、およびルーティングされるパケットの性質等、複数のアイテムを含みうる。このルート表は、様々な方法を利用してパケットの性質を表してよい。例えば、ルート表は、３以下の「パケット優先度」を利用してパケットが伝送品質に左右され易いことを示し、３より大きい「パケット優先度」を利用してパケットが送信スループットに左右され易いことを示してよい。
【００１７】
ドライバ２０１０はさらに、パケット分析ロジック２０１２を含み、パケットの性質を分析してよい。この性質は、ドライバ２０１０がパケット性質に対応するルートをルート表から探す手助けとなったり、ルーティングアプリケーション２０２がルートのルートメトリックを決定する手助けとなったりするが、具体的にはパケットの性質は、ルートメトリックを計算するのに利用されるパケット損失率とデータレートとの間の重み関係（weight relationship）を決定する手助けをしうる。
【００１８】
ドライバ２０１０は、現在のノードから送信先ノードへデータを振り分けるルートをルート表から探してよく、このルートは分析されたパケットの性質に対応していてよい。しかし、ドライバ２０１０がルート表にそのルートを見つけることができない場合、ドライバ２０１０は、現在のノードから送信先ノードへのルートが存在するか否かを判断しうるルーティングアプリケーション２０２に通知をしてよい。そのようなルートが存在するという応答を受けると、ルーティングアプリケーション２０２は、パケット性質に従いそのルートのルートメトリックを計算して、そのルートとそのルートメトリックとをルート表に追加してよい。しかし、現在のノードから送信先ノードへの複数のルートが存在する場合、例えばノード１１０から１４０にかけて２つのルートが存在する場合には、ルーティングアプリケーション２０２は、パケット性質に従い各ルートのルートメトリックを計算して、これら計算されたルートメトリックに従いデータをルーティングするルートを選択してよい。
【００１９】
ルーティングアプリケーション２０２は、各送信先ノードについてルートを記憶するルート表２０１１を含みうる。ルーティングアプリケーション２０２は、ドライバ２０１０内のルート表と自身のルート表とを、これら両方のルート表を同時に更新することで、互いに整合させておくことができる。
【００２０】
ルーティングアプリケーション２０２はさらに、ドライバ２０１０が分析したパケット性質に従いルートメトリックを計算するメトリックロジック２０２０を含みうる。メトリックロジック２０２０は、以下の式１を利用してルートメトリックを計算してよい。
【００２１】
式１
【数１】
2010515307.tif 000003
【００２２】
ｍｅｔｒｉｃｒｏｕｔｅは、ルートのメトリックを表し、ｍｅｔｒｉｃｌｉｎｋは、ルートのリンクのメトリックを表してよい。２つの隣り合うノードが１つのリンクを構築してよい（例えば、ノード１１０と１２０との間のリンク）。ｎは整数であってよく、ルートが有しうるリンクの数を表してよい。例えば、ルート（１１０、１２０、１４０）は、リンク（１１０、１２０）とリンク（１２０、１４０）という、２つのリンクを有してよい。ｒａｔｅは、リンク上のデータレートを表してよく、データは様々なデータレートでリンク上を送信されてよい。ｐｒａｔｅは、あるデータレートにおけるパケット損失率を表してよく、異なるデータレートが異なるパケット損失率と関連付けられていてよい。ａおよびｂは、パケット損失率（ｐｒａｔｅ）とデータレート（ｒａｔｅ）との間の重み関係を決定しうるパラメータであってよい。
【００２３】
上述のように、パケット性質は、メトリックロジック２０２０がパケット損失率とデータレートとの間の重み関係を決定する手助けとなってよい。例えば、メトリックロジック２０２０は、パケットが伝送品質に左右され易い場合、データレートよりもパケット損失率のほうに大きな重みを割り当ててよいし、パケットが送信スループットに左右され易い場合、パケット損失率よりもデータレートのほうに大きな重みを割り当ててよい。上記の式の場合、品質に左右され易いパケットについては、パラメータａがパラメータｂより大きくてよく（例えばａ＝１０でｂ＝１）、スループットに左右され易いパケットについては、パラメータｂがパラメータａより大きくてよい（例えばｂ＝１０でａ＝１）。
【００２４】
他のアルゴリズムを利用すると、他の方法でルートメトリックを計算することができる。例えば、メトリックロジック２０２０は、以下の式２を利用してルートメトリックを計算してもよい。
式２
【数２】
2010515307.tif 000004
【００２５】
ルーティングアプリケーション２０２はさらに、ルートメトリックに基づき、現在のノードから送信先ノードへの各利用可能なルートについてルート選択するルーティングロジック２０２１を含みうる。上述の式１で計算されるルートメトリックについては、ルーティングロジック２０２１は最小ルートメトリックを有するルートを選択してよい。ルーティングロジック２０２１は、新たなルートでルート表２０１１を更新する等、他の機能を行ってもよい。
【００２６】
本発明においては、同じパケット損失率とデータレートとの組み合わせが利用される場合でも、ルーティングアプリケーション２０２は、異なる性質を有する異なるパケットについて異なるルートを選択してよい。例えば、３つのパケット損失率とデータレートとの組み合わせが、ノード１１０および１２０間のリンク、および、ノード１２０および１４０間のリンク上のデータ送信について利用されうる。
【表１】
2010515307.tif 000005
【００２７】
ノード１１０および１３０間のリンク、および、ノード１３０および１４０間のリンク上のデータ送信については、別のパケット損失率とデータレートとの組み合わせを利用することができる。
【表２】
2010515307.tif 000006
【００２８】
メトリックロジック２０２０は、品質に左右され易いパケットの送信については、パラメータａおよびｂを、１０および１と決定してよく、スループットに左右され易いパケットの送信については、１および１０と決定してよい。故に、伝送品質に左右され易いパケットについては、ノード１１０、１２０、および１４０を通るルートのルートメトリックは、以下のようになる。
【数３】
2010515307.tif 000007
また、ノード１１０、１３０、および１４０を通るルートのルートメトリックは、以下のようになる。
【数４】
2010515307.tif 000008
【００２９】
しかし、送信スループットに左右され易いパケットについては、ノード１１０、１２０、および１４０を通るルートのルートメトリックは、以下のようになる。
【数５】
2010515307.tif 000009
また、ノード１１０、１３０、および１４０を通るルートのルートメトリックは、以下のようになる。
【数６】
2010515307.tif 000010
【００３０】
故に、ルーティングロジック２０２１は、ルート（１１０、１３０、１４０）を伝送品質に左右され易いパケットについて選択し、ルート（１１０、１２０、１４０）を送信スループットに左右され易いパケットについて選択してよい。
【００３１】
チップセット２３は、例えばネットワークインタフェース２４およびファームウェア２５のような１以上のプロセッサ２１、メモリ２２、および他のコンポーネント間に１以上の通信路を提供してよい。
【００３２】
ネットワークインタフェース２４は、メッシュネットワークを介してパケットを送受信してよい。ネットワークインタフェース２４の例としては、ネットワークカード、ブルートゥースデバイス、アンテナ、および他のデータ送受信デバイスが含まれてよい。
【００３３】
ファームウェア２５は、ノードがシステム起動時に実行するＢＩＯＳルーチンを記憶することで、プロセッサ２１、チップセット２３、およびノードおよび／またはＥＦＩルーチンの他のコンポーネントを初期化し、ファームウェア２５をオペレーティングシステム２０１とインタフェースして、オペレーティングシステム２０１を立ち上げる標準的な環境を提供してよい。
【００３４】
図３は、ルートメトリックによるルート選択方法の１実施形態を示す。ブロック３０１において、送信元ノード（例えばノード１１０）は、パケットを送信先ノード（例えばノード１４０）に送信することを決定してよい。ブロック３０２において、送信元ノードのドライバ２０１０は、このパケットの性質を分析してよい。例えば、性質は、パケットが伝送品質に左右され易いか、送信スループットに左右され易いかを示してよい。ブロック３０３において、送信元ノードは、このパケット性質および送信先ノードに対応するエントリを、ルート表２０１１から探してよい。
【００３５】
このエントリがブロック３０４で見つかった場合、送信元ノードのドライバ２０１０は、ブロック３０５でこのパケットをエントリが示すルートを介して送る。このエントリがブロック３０４で見つからなかった場合、送信元ノードは、隣り合うノード（１以上）にルート要求をブロードキャストして、隣り合うノード（１以上）から送信先ノードへのルートを要求する（ブロック３０６）。例えば、ノード１１０は、ルート要求をノード１２０および１３０にブロードキャストして、各隣り合うノードから送信先ノード１４０へのルートを要求してよい。
【００３６】
ルート要求は、送信先ノードとパケット性質とを含んでよい。隣り合うノードは、パケット性質および送信先ノードに対応しうる要求ルートを自身のルート表から探してよく、要求ルートを含むルート要求返信をノードに送り返してよい。しかし、要求ルートが隣り合うノードに記憶されているルート表に見つからない場合、隣り合うノードは、別のルート要求を、自分に隣り合うノード（１以上）にブロードキャストしてよく、そのルートが最終的に見つかった場合、送信元ノードにルート要求返信を送り返してよい。
【００３７】
ブロック３０７で、送信元ノードが複数のルート要求を複数の隣り合うノードから（例えば、ノード１２０および１３０から）受信した場合、ノードのメトリックロジック２０２０は、ブロック３０８で、ルート要求返信の各々が指定する各ルートのルートメトリックを計算してよい。例えば、各ルートは、送信元ノードから、ルート要求返信を送ることのできる隣り合うノードの各々を介して、送信先ノードまでであってよい（例えば、ノード１１０、１２０、および１４０を通るルート、および／または、ノード１１０、１３０、および１４０を通るルート）。メトリックロジック２０２０はさらに、ルートメトリックを計算するときにパケット性質を利用してパケット損失率とデータレートとの間の重み関係を決定してよい。
【００３８】
そして、ブロック３０９において、送信元ノードのルーティングロジック２０２１は、ブロック３０８で計算したルートメトリックに基づいて、パケットを送信元ノードから送信先ノードにルーティングするルートを選択してよい。例えば、ルーティングロジック２０２１は、最小ルートメトリックを有するルートを選択してよい。また、ルーティングロジック２０２１は、選択されたルートおよびそのルートメトリックをルート表に追加することで、ルート表を更新してよい。
【００３９】
ブロック３１０でルート要求返信が１つしか受信されなかった場合、ノードのドライバ２０１０は、パケットを、ブロック３１１でルート要求返信が指定したルートを介して送ってよい。例えば、ルートは、該ノードから、ルート要求返信を送り出すことのできる隣り合うノードを介して、送信先ノードまでであってよい。さらに、ルーティングロジック２０２１は、該ルートのルートメトリックを計算して、該ルートおよびそのルートメトリックをルート表に追加することで、ルート表を更新してよい。ブロック３１０でルート要求返信が１つも受信されなかった場合には、ノードはパケット送信を取り止めてよい。
【００４０】
他の技術でルート選択方法の別の実施形態を実装することもできる。例えば、ルート要求返信はさらに、隣り合うノードから送信先ノードまでのルートのルートメトリックを含んでよい。こうすると、送信元ノードは、送信元ノードと隣り合うノードとの間のリンクのリンクメトリックを計算しさえすれば、このリンクメトリックをルート要求返信のルートメトリックに追加することにより送信元ノードから送信先ノードまでのルートのルートメトリックを得ることができるようになる。
【００４１】
本発明の様々なフィーチャを例示的実施形態との関連で記載してきたが、記載は制限的に解釈されることを意図していない。例示的実施形態の様々な変形例、および、本発明の他の実施形態が、本発明の当業者には明らかであり、本発明の精神および範囲内に含まれる。
【図１】
2010515307.tif 000017
【図２】
2010515307.tif 000018
【図３】
2010515307.tif 000019
【国際調査報告】
2010515307.tif 000020
2010515307.tif 000021