JP5252150B2

JP5252150B2 - 無線ネットワーク内に協調型経路を設定する方法とシステム

Info

Publication number: JP5252150B2
Application number: JP2008243026A
Authority: JP
Inventors: エー．ブラウンサードトーマス; エム．ブレアーアダム，; エル．ジョンソンマーク; アール．ハルフォードトーマス
Original assignee: トレリスウェアテクノロジーズインコーポレイテッド
Priority date: 2008-04-11
Filing date: 2008-09-22
Publication date: 2013-07-31
Anticipated expiration: 2028-09-22
Also published as: KR20090108545A; US8457005B2; US8964773B2; US20080198789A1; EP2109228A1; JP2009260911A; EP2109228B1; KR101477820B1; US20140161015A1

Description

関連出願

[0001]本出願は、「ＩｎｆｏｒｍａｔｉｏｎＲｅｌａｔｉｎｇｔｏＯｒｔｈｏｇｏｎａｌＤｉｍｅｎｓｉｏｎＢａｒｒａｇｅＲｅｌａｙ」と題して２００６年１１月８日に出願された米国特許仮出願第６０／８６４９２７号、代理人整理番号０２０９４５−００２６００ＵＳの優先権を主張している本出願であって、「ＭｅｔｈｏｄｓａｎｄＡｐｐａｒａｔｕｓｆｏｒＮｅｔｗｏｒｋＣｏｍｍｕｎｉｃａｔｉｏｎＶｉａＢａｒｒａｇｅＲｅｌａｙＯｎｔｏａｎＩｎｄｅｐｅｎｄｅｎｔＭｅｄｉｕｍＡｌｌｏｃａｔｉｏｎ」と題して２００７年８月２日に出願された米国特許出願第１１／８３３１１３号、代理人整理番号０２０９４５−００２６１０ＵＳの一部継続出願である。これら出願の開示を、それらの全体を参照することによって本明細書に援用する。

発明の背景

[0002]本開示は、通信ネットワークにおいて効率的で強力なマルチホップ協調型経路を構築することが可能なシステムと方法に関するものである。開示する技法は、連続中継（ｂａｒｒａｇｅｒｅｌａｙ）という概念を用い、それにより多重アクセスを目的としたキャリア検知と衝突回避、又は、ルーティングを目的とした各ノードにおける接続テーブルの形成と使用の必要性を回避することによって、音声配信、ストリーミングビデオ及び他の遅延に敏感なアプリケーションに、より詳細には、無線アドホックネットワークに適したものとなっている。少なくとも一つの実施形態では、これらの技法を用いてモバイルアドホックネットワーク（「ＭＡＮＥＴ」）に新しいユニキャストのリアクティブ型ルーティング経路設定プロトコルを形成してもよい。

[0003]ＭＡＮＥＴの理論と実践は、戦術無線通信や関連する商業活動でのアプリケーションに刺激され、昨今、大きな関心を呼んでいる。しかしながら、ＭＡＮＥＴにおけるストリーミング及び他の遅延に敏感なサービス品質（ＱｏＳ）が求められるアプリケーションの迅速な中継とルーティングの要件を充足する効果的かつ拡張可能なソリューションの開発は遅れている。その主な要因は、厳しい地上での伝播、ノードの可動性と信頼性の低いリンクによる不確実なネットワークトポロジ、全体的なインフラ不足、終端間の接続に必要なホップの数の多さ等にある。

[0004]周知のＭＡＮＥＴ技法に関わる設計ベースの問題として、チャネルアクセスと経路設定の欠陥がある。当該欠陥は、元来第２世代及び第３世代の無線ＬＡＮ又はセルラーネットワークを対象とした古典的なプロトコル、即ち、全てのホップ（リンク）においてプロセスの再開にウェイトが置かれているために、現在の環境での使用に適さないプロトコルの使用によってもたらされるものである。こうした好ましくない状況から、ＭＡＮＥＴの新たなアーキテクチャとネットワークプロトコルスタック設計のパラダイムシフトが求められるようになってきている［Ｒ．Ｒａｍａｎａｔｈａｎ、「Ｃｈａｌｌｅｎｇｅｓ：ＡＲａｄｉｃａｌｌｙＮｅｗＡｒｃｈｉｔｅｃｔｕｒｅｆｏｒＮｅｘｔＧｅｎｅｒａｔｉｏｎＭｏｂｉｌｅＡｄＨｏｃＮｅｔｗｏｒｋｓ」、Ｐｒｏｃ．ＡＣＭ／ＩＥＥＥＩｎｔ’ｌＣｏｎｆ．ＭｏｂｉｌｅＣｏｍｐ．及びＮｅｔｗｏｒｋｉｎｇ，Ｃｏｌｏｇｎｅ、ドイツ、２００５年８月、ｐｐ．１３２〜１３９］。本開示は、とりわけＭＡＮＥＴに非常に適したプロセスとプロトコルを設計、実施、テスト及び導入することに関する飛躍をもたらすものであり、待機時間、処理能力、拡張性等に関して古典的なソリューションを大きく上回る実用的な方法と考えられる。

[0005]これらの問題を軽減し、ＭＡＮＥＴネットワーキングの問題に立ち返る最初のステップとして、（前述の）米国特許出願第１１／８３３１１３号は、遅延に対して効果的で、各ノードの各パケット受信の信号対雑音比（ＳＮＲ）を高め、古典的な多重アクセス方式に固有のパケット衝突の問題を回避するように様々なネットワークノードが各種無線リンクにアクセスする方法として、連続中継という概念を導入した。連続中継技法は、ロバストな集合経路設定という現在の命題用の基礎的なメカニズムとして採用されている。したがって、本開示は、自律的に決定され、分散され、待機時間が最短の送信方式、及び、対応するダイバーシティ合成受信方式（合わせて「連続中継」として知られている）の簡易かつ効率的な形式を利用することによって、これまでに知られている古典的なＰＨＹ送信／受信メカニズムに大幅な変更をもたらす。米国特許出願第１１／８３３１１３号の「ｂａｒｒａｇｅ−ｒｅｌａｙ」という概念は、［Ｓ−ＹＮｉ，Ｙ−ＣＴｓｅｎｇ，Ｙ−ＳＣｈｅｎ及びＪ−ＰＳｈｅｕ「ＴｈｅＢｒｏａｄｃａｓｔＳｔｏｒｍＰｒｏｂｌｅｍｉｎａＭｏｂｉｌｅＡｄＨｏｃＮｅｔｗｏｒｋ」、ＭｏｂｉＣｏｍ、ワシントン州シアトル、１９９９年］及び［Ｄ．Ｋ．Ｌｅｅ及びＫ．Ｍ．Ｃｈｕｇｇ、「ＰｒａｇｍａｔｉｃＣｏｏｐｅｒａｔｉｖｅＤｉｖｅｒｓｉｔｙＣｏｍｍｕｎｉｃａｔｉｏｎｓ」、Ｐｒｏｃ．ＩＥＥＥＭｉｌｉｔａｒｙＣｏｍｍ．Ｃｏｎｆ、ワシントンＤＣ、２００６年１０月］の「フラッディングによるブロードキャスト（ｂｒｏａｄｃａｓｔｉｎｇｂｙｆｌｏｏｄｉｎｇ）」及び「協調型ダイバーシティ（ｃｏｏｐｅｒａｔｉｖｅｄｉｖｅｒｓｉｔｙ）」という二つの概念を、各ノードが処理する固有の中継論理と共に含み、これらを結合することに注意されたい。本明細書で提案するルーティングプロトコルは、これらの利点を独特の方法で利用し、それにより所望の協調型経路を迅速かつ強力で効率的な方法で設定する。

[0006]この独特のＰＨＹ−ＭＡＣの組み合わせにより、米国特許出願第１１／８３３１１３号と本開示はいずれも、搬送波感知多重アクセス／衝突回避方式（ＣＳＭＡ／ＣＡ）等の周知のリンクアクセスメカニズムの背後にある論理を大きく変更する。なお、ＣＳＭＡ／ＣＡは、ＩＥＥＥ８０２．１１標準ファミリー（Ｗｉ−Ｆｉ）等に見出すことができ、ノードが衝突を避けるためにパケットの送信とキャリア探知とを交互に行うものである。上記の変更は、ＰＨＹ層の能力を活用して複数の同時の（又は同時に近い状態の）同一パケットからエネルギーを集め、それによりリンク層での衝突を恐れて送信を遅らせ順番に処理する必要性を除去することによって行われる。

[0007]さらに、本開示は、各ノードで接続テーブルを形成する必要性を除去し、それにより当該接続テーブルを形成し維持するために制御信号を送るネットワーク容量に必要な付随的費用を削減することにより、これまで知られているレイヤ３経路指定スキーム、即ち、集合的に「アドホック経路指定プロトコル」（［Ｍ．Ｊ．Ｌｅｅ、Ｊ．Ｚｈｅｎｇ、Ｘ．Ｈｕ、Ｈ．Ｊｕａｎ、Ｃ．Ｚｈｕ、Ｙ．Ｌｉｕ、Ｊ．Ｓ．Ｙｏｏｎ及びＴ．Ｎ．Ｓａａｄａｗｉ「ＡＮｅｗＴａｘｏｎｏｍｙｆｏｒＲｏｕｔｉｎｇＡｌｇｏｒｉｔｈｍｓｆｏｒＷｉｒｅｌｅｓｓＭｏｂｉｌｅＡｄＨｏｃＮｅｔｗｏｒｋｓ：ＴｈｅＣｏｍｐｏｎｅｎｔＡｐｐｒｏａｃｈ」、ＩＥＥＥＣｏｍｍｕｎｉｃａｔｉｏｎｓＭａｇａｚｉｎｅ、ｖｏｌ．４６、ｐｐ．１１６〜１２３、２００６年１１月］（その古典的代表例は、ＭＡＮＥＴ作業グループで提示されたオンデマンド経路指定プロトコル向けのアドホックオンデマンド距離ベクトル（ＡＯＤＶ）プロトコル）として知られているスキームと著しく異なる。

[0008]したがって、本開示は、米国特許出願第１１／８３３１１３号の連続中継という概念に固有の自律的送信、及び、協調型ダイバーシティ受信というＰＨＹ−ＭＡＣ層の特性を、本明細書で示す新たなレイヤ２経路指定（協調型パス設定）メカニズムと共に効果的に結合し、共同のＰＨＹ−ＭＡＣ経路指定プロトコル形成用の効果的なリアクティブ型（オンデマンド）のクロスレイヤ最適化法に至るものである。

発明の概要

[0009]前述の背景に鑑み、同時に存在し作動している複数の協調型パスを介してアドホックネットワークにおけるソースノードと宛先ノードとの間のパケットルーティング（「協調型経路」と呼ぶ。以下で詳述する）を設定するメカニズムを、本発明の少なくとも一つの実施形態に従い提供する。

[0010]本明細書で言及するように、ソースと宛先との間にあって協調型パスはレイヤ又はホップにおいて設けられた中継ノードを用いた（グラフ理論上の）個々のパスの集合であり、各パケットの転送で協調する中継ノードの集合及び誘導されるホップの数を固有の特徴としている。二つのこのような協調パスは、対象の二つの協調パスの同じレイヤインデックスに関係する（すなわち、同じホップ数の）二つのセットのノードが相互排除的な場合に、別個のものと呼ばれる。本明細書で言及するように、協調型経路は、所与のソースと所与の宛先との間にある全ての別個の協調パスの集合である。前述の定義は、図１で明確となる。

[0011]図１は、本発明の実施形態に係る、別個の協調パスの集合としてのソースノード（Ｓ）と宛先ノード（Ｄ）との間にある協調型経路を示している。具体的には、同図は、ＳとＤとの間にある三つの別個の協調パスを示しており、これらパスは、ＳとＤとの間にある協調型経路を構成している。丸の中の番号は、各協調パスにおける中継ノードの各レイヤインデックスを指している。上部の協調パスはＳとＤの間の三つのホップからなる。その下の協調パスは、一番下の協調パスと同様に、ＳとＤの間の四つのホップからなり、これら二つの協調パスの何れにおいても、番号「２」の二つの中継ノード間の協調によって、番号「３」の中継ノードがシグナルを受信する支援がなされる。

[0012]本発明の実施形態によれば、対象のアドホックネットワークのノードは、米国特許出願第１１／８３３１１３号で開示されているような技法に従って送受信を行うが、他の多くの公知のアドホックルーティングプロトコルでは通例であるようには、隣接ノードのトポロジ、それらを接続するリンクの質等を示す接続テーブルを形成、維持、又は更新する必要がない。したがって、各送信ノードは、隣接ノードの存在や、それ自体とその他全ての受信ノードとの間にある仲介チャネルの質について関知しない。チャネル状態情報は、必要であり、各受信ノードで累積的に自律的に生成される。すなわち、推定が必要なのは、対象の受信ノードに到達する送信ノード全てからの受信チャネル全体であり、個々のチャネルではなく、そのことは米国特許出願第１１／８３３１１３号の［００５０］と［００５１］に詳述されている。ネットワーク内の送信ノードも受信ノードも、隣接ノードに関する接続テーブルを形成、維持、更新する必要はなく、例えば、アドホックオンデマンド距離ベクトル（ＡＯＤＶ）及びダイナミックＭＡＮＥＴオンデマンド（ＤＹＭＯ）ルーティングプロトコルが行うように、ソースまでの一時的経路のリストを維持する必要もない。

[0013]本発明の具体的な実施形態に係る協調型ルーティングプロトコルを以下に説明する。このプロトコルでは、ソースが経路要求（ＲＦＲ）パケットをブロードキャストし、次いで、当該ＲＦＲパケットが、前述したように連続中継に従いアドホックネットワーク全体に伝播する。

[0014]ＲＦＲパケットは、ソースノードの固有のＩＤ、指定宛先ノードの固有のＩＤ、ソースからのノードの距離をホップで測定して示すＲＦＲホップカウンタ（ＲＦＲ＿ｈｏｐｓ）として機能するフィールド、非負の整数Ｎである経路「幅」パラメタ。これらのパラメタの目的は、以下に詳述する。

[0015]ソースノードによるＲＦＲパケットの最初のブロードキャスト送信は、ＲＦＲ＿ｈｏｐｓの値を１（又は他の取決められた値）に設定する。ＲＦＲパケットの受信に成功した他のノードは、この受信したＲＦＲ中継数をメモリに格納し、パケットの「ＲＦＲ中継数」フィールドを１増分し、前述したように連続中継の原則に従いパケットを再送信（ブロードキャスト）する。複数の装置が、略同時に同じ媒体割り当てで同一のパケットを送信することがある（また通常はそうしている）ことに留意されたい。

[0016]宛先ノードは、それ自体に宛てられたＲＦＲパケットを受信すると、当該パケットを更に中継してもよく、しなくてもよい。

[0017]宛先ノードがＲＦＲパケットを適切に受信した（また、それ自体が宛先ノードであることを特定した）場合には、当該宛先ノードは、経路設定完了（ＣＴＲ）パケットを送信する。ＣＴＲパケットは、（この宛先ノードまでに形成された）ＲＦＲ中継数の合計、及び、宛先からのノードの距離をホップで測定して示す初期設定１（又は他の取決められた値）のＣＴＲ中継数（ＣＴＲ＿ｈｏｐｓ）を更に含む。この最初のＣＴＲパケットは、連続中継の原則に従い、アドホックネットワークにおいて伝播する。

[0018]このＣＴＲパケットの受信及び復調／復号に成功した中間中継ノードは、メモリにこの受信したＣＴＲ中継数を格納し、以前に格納したＲＦＲ中継数を呼び出し、当該ノードがこの特定の（ソース、宛先）ペアにとって所望のルーティングパスにあるか否かの評価を可能にする論理計算を実行する。この評価は、次いで、このノードが、パケット転送の終了又は時間切れの発生までにこれら二つの特定ノード（ソース及び宛先）間でルーティングされる任意のパケットの中継に参加するか否かを判断する。

[0019]ノードがＲＦＲパケットもＣＴＲパケットも受信していない場合には、当該ノードは前述の計算及び対応の経路に参加しない。

[0020]この論理計算は、前述の経路幅パラメタＮを含む閾値によって制御される。この数値Ｎは、ネットワーク全体で共通に設定してもよく、又は｛ソース、宛先｝ペアＩＤに応じて変更してもよく、更には、個々のパケットのＣＴＲに応じて変更（したがって、優先順位メカニズムを設定）してもよい。

[0021]前述の論理計算によって、特定のノードが｛パス、宛先｝ペアの集合経路上にあり、したがって、当該経路の中継ノードになると判断した場合には、当該ノードは、パケットの「ＣＴＲ中継数」フィールドを１増分し、連続中継の原則に従いＣＴＲパケットを再送信（ブロードキャスト）する。

[0022]ＲＦＲパケットとＣＴＲパケットの双方の受信時に、前述の論理計算によって、特定のノードが、｛パス、宛先｝ペアの集合経路上にないと判断した場合には、当該ノードは監視役として働き、ＣＴＲパケットをそれ以上中継しない。ＣＴＲは監視ノードによってそれ以上中継されないため、ＣＴＲは前述の監視役によって設定されたバリアを越えてネットワーク全体に伝播することはない点に注意されたい。

[0023]本開示の更なる実施形態では、特定経路の（前述の論理計算によって記述されたノード以外の）追加のノードに対する「監視役」の役割の割り当ては、宛先ノードが「監視」パケットと呼ばれる追加パケットを送信し、このパケットのみを受信し他のパケット（ＲＦＲ又はＣＴＲ）を受信しないノードにこの役割を割り当てることによって実現される。

[0024]本開示の更なる実施形態では、宛先ノードは、中間中継ノードにおいてＲＦＲ／ＣＴＲパケットの衝突を回避するために、（ＲＦＲパケットを受信した後）対応するＣＴＲパケットを送信する前に所定数のタイムスロットの間、待機する。

[0025]本開示の更なる実施形態では、元のソースノードは、設定された集合経路上で実際のデータ送信を始める前に、別の所定数のタイムスロットの間、待機する。

発明の詳細な説明

[0030]本セクションでは、本発明の具体的な実施形態に係るプロトコルであって、連続中継ネットワークにおけるバッファ付きユニキャスト経路を設定するためのプロトコルの詳細な説明を行う。ソースノードは、宛先ノードへの（ユニキャスト）経路の設定を望む場合はいつでも、連続中継型のホップカウンタを含むＲＦＲパケット（パケット）をブロードキャストして、全てのリスニングノード（中継されるリスニングノード及び中継し得るリスニングノード）が最終的に、ソースまでの距離をホップで把握するようにする。更なる情報は当面、当該ノードによって保持されない。宛先ノードは、ＲＦＲパケットを受信すると、第２のホップカウンタを含むＣＴＲパケット（パケット）をブロードキャストし、それにより全てのリスニングノードが最終的に、宛先までの距離（このＣＴＲパケットには、ソースから宛先までのホップ距離の合計が含まれる）を把握するようにする。この手順に従い、ノードは、当該ノードがソースノードと宛先ノードとの間の協調型パス上にあるか否かを確認することができる。次いで、このようなノードは、後続のユニキャストフローのための中継となる。フローに隣接するノードは、ＲＦＲ／ＣＴＲパケットからも確認されるものであり、フローのバッファ（監視役）となり、フローとその他のネットワークとを事実上区分し、場合により多重並行フローの存在を可能にする。

[0031]本発明の本実施形態によれば、ネットワークノードは、所与のバッファ付きユニキャストフローに関して、五つの状態のうち何れか一つの状態にある。
（ａ）ソースノード（Ｓ）：これは、所与の宛先への経路要求を生成するノードである。
（ｂ）宛先ノード（Ｄ）：宛先ノードは、ソースからのデータの指定受信者であり、受信データを中継しない。
（ｃ）中継ノード（Ｒ）：本開示における中継ノードは、パケットの初回受信（それ以外は無視）の後、適切なタイムスロットで連続中継の原則に従い当該パケットを中継する。
（ｄ）バッファノード（Ｂ）：本開示におけるバッファノードは、フローをせき止める働きをする。バッファノードは、（フローの内外から）受信したパケットを中継しない。
（ｅ）無関係ノード（Ｕ）：バッファ付きユニキャストフローの外にあるノードは、無関係であり、したがって、異なる並行フローに参加することができる。

[0032]バッファ付きユニキャスト経路設定プロトコルの役割は、ネットワーク内の各ノードに（特定のフローに関して）前述の所与の状態を割り当てることだけである。下記の図２ａ、２ｂ及び２ｃは、以下に説明するプロトコルを適用した後における例示的なネットワーク内のそのような割当を示している。図２（ａ）は、Ｎ＝０の設定の場合のソース（Ｓ）、宛先（Ｄ）、中継ノード（Ｒ）、バッファノード（Ｂ）、及び無関係ノード（Ｕ）を含む複数ノードのネットワークを示す図である。図２（ｂ）は、Ｎ＝１の設定の場合のソース（Ｓ）、宛先（Ｄ）、中継ノード（Ｒ）、バッファノード（Ｂ）、及び無関係ノード（Ｕ）を含む複数ノードのネットワークを示す図である。図２（ｃ）は、Ｎ＝１の設定の場合のソース（Ｓ）、宛先（Ｄ）、中継ノード（Ｒ）、バッファノード（Ｂ）、及び無関係ノード（Ｕ）を含む複数ノードのネットワークを示す図である。

[0033]ここで、本プロトコルは、この割当を実現するために、以下の３種類までのパケット（パケット）を利用する。
（ａ）（ａ．１）ソースノードの固有の識別子（ＩＤ）、（ａ．２）宛先ノードのＩＤ、（ａ．３）所望の経路幅パラメタ、Ｎ、（ａ．４）ソースからのホップ数をカウントするＲＦＲホップカウンタ（ＲＦＲ＿Ｈｏｐｓ）の四つのフィールドを含む経路要求（ＲＦＲ）パケット。
（ｂ）（ｂ．１）ソースＩＤ、（ｂ．２）宛先ＩＤ、（ｂ．３）経路幅パラメタ、Ｎ、（ｂ．４）宛先からのホップ数をカウントするＣＴＲホップカウンタ（ＣＴＲ＿Ｈｏｐｓ）、（ｂ．５）ソースから宛先までのホップ数の合計（ＲＦＲ中継数合計）の五つのフィールを含む経路設定完了（ＣＴＲ）パケット。
（ｃ）（ｃ．１）ソースＩＤ及び（ｃ．２）宛先ＩＤの二つのフィールドを含むバッファ（ＢＵＦ）パケット。

[0034]本発明の他の実施形態では、プロトコルは、前述のＲＦＲパケットとＣＴＲパケットを利用するが、ＢＵＦパケットを利用しない。バッファノードＢは、前述の二つのパケットが中継されたときに、これらのパケット及びこれらのパケットに含まれる情報から直接的に推測される。

[0035]本発明の実施形態によれば、経路幅パラメタＮは、ＲＦＲ及び／又はＣＴＲパケットに含まれる非負の整数であり、ソースと宛先との間にある（必要な最小ホップ数の）最短パス上にない中継ノードを含めることを可能にする。具体的には、最短パスより長いＮホップ以下のパスにあるノードが、中継ノードとして、ソースと宛先との間の協調型経路に含められる。

[0036]本発明の更なる実施形態によれば、経路幅パラメタＮは、ＲＦＲパケットとＣＴＲパケットの送信前にネットワーク内の全ノードに既知である（換言すれば、ネットワークの導入前に設定される）。

[0037]本実施形態のバッファ付きユニキャスト経路設定プロトコルは、以下のように進行する。まず、ソースノードが、ＲＦＲ＿Ｈｏｐｓ＝１のほか、適切に設定されたソースＩＤ、宛先ＩＤ及び経路幅のフィールドを有するＲＦＲパケットをブロードキャストする。

[0038]ノードは、ＲＦＲパケットを受信すると（初回のみ）、受信したＲＦＲ＿Ｈｏｐｓの数をＳｔｏｒｅｄ＿ＲＦＲ＿Ｈｏｐｓとして格納し、次いで、ＲＦＲホップカウントを（１）増分してＲＦＲパケットを中継する。

[0039]所望の宛先ノードは、ＲＦＲパケットを受信すると（初回のみ）、受信したＲＦＲ＿Ｈｏｐｓの値をＴｏｔａｌ＿ＲＦＲ＿Ｒｅｌａｙ＿Ｎｕｍｂｅｒとして格納し、次いで、１に設定したＣＴＲ＿Ｈｏｐｓ、前述のＴｏｔａｌ＿ＲＦＲ＿Ｒｅｌａｙ＿Ｎｕｍｂｅｒ、受信したＲＦＲパケットに設定されていたとおりのソースＩＤ、宛先ＩＤ、及び経路幅パラメタのフィールドを含むＣＴＲパケットを送信する。

[0040]ノードは、ＣＴＲパケットを受信すると（初回のみ）、二つの数値、すなわち、パケットに含まれているＴｏｔａｌ＿ＲＦＲ＿Ｒｅｌａｙ＿Ｎｕｍｂｅｒ及びＣＴＲ＿Ｈｏｐｓの数を格納する。ＣＴＲ＿Ｈｏｐｓ数は、Ｓｔｏｒｅｄ＿ＣＴＲ＿Ｈｏｐｓとして格納される。次いで、そのノードは、同じ｛ソース、宛先｝ペアＩＤをもつ対応のＲＦＲパケットを受信したか否かを確認する。

[0041]そのノードは、同じ｛ソース、宛先｝ペアＩＤをもつ対応のＲＦＲパケットを以前に受信していない場合には、更なる動作は行わない。

[0042]そのノードは、同じ｛ソース、宛先｝ペアＩＤをもつ対応のＲＦＲパケットを以前に受信していた場合には、全て同じ｛ソース、宛先｝ペアＩＤに対応するＳｔｏｒｅｄ＿ＲＦＲ＿Ｈｏｐｓ数、Ｓｔｏｒｅｄ＿ＣＴＲ＿Ｈｏｐｓ数、Ｔｏｔａｌ＿ＲＦＲ＿Ｒｅｌａｙ＿Ｎｕｍｂｅｒ、及び経路幅パラメタＮをメモリから呼び出す。

[0043]前述の数値に基づき、ノードは、それ自体がこの特定の｛ソース、宛先｝ペアについて集合経路上にあるか否かを判断するために、論理計算を実行する。本開示は、以下に例としてこの論理を具体的に説明する。しかしながら、同じ結論、すなわち、ノードが所定の｛ソース、宛先｝ペアについて集合経路上にあるか否かについて同じ結論に達する他の論理計算が、この開示に含まれる。

[0044]前述の論理計算の例として、ノードは以下の比較を行うことができる。
Ｓｔｏｒｅｄ＿ＲＦＲ＿Ｈｏｐｓ＋Ｓｔｏｒｅｄ＿ＣＴＲ＿Ｈｏｐｓ≦Ｔｏｔａｌ＿ＲＦＲＲｅｌａｙ＿Ｎｕｍｂｅｒ＋Ｎ
であれば、このノードは当該ペアについて集合経路上にある。上記の不等式が成り立たない場合には、このノードは当該ペアについて集合経路上にないが、代わりにバッファノードとして機能し、ＣＴＲパケットをそれ以上中継しない。

[0045]上記不等式に従い、そのノードは、それ自体が当該ペアについて集合経路上にあると判断した場合には、当該ノードはＣＴＲ＿Ｈｏｐｓ数を１増分してＣＴＲパケットを中継する。

[0046]ＣＴＲパケットを受信すると、ソースノードは、宛先までの設定済みの集合経路に沿ってメッセージデータの送信を開始する。

[0047]本開示の他の実施形態では、ソースノードは、ＣＴＲパケットを受信すると、所定の時間待機してから宛先までの設定済みの集合経路に沿ってメッセージデータの送信を開始する。

[0048]本開示の他の実施形態では、宛先ノードは、ＲＦＲパケットを受信すると、所定の時間（一般には、前述のソースの待機時間とは異なる）待機してからＣＴＲパケットを送信する。

[0049]本開示の他の実施形態では、所望の宛先ノードは、ＲＦＲパケットを受信すると（初回のみ）、受信したＲＦＲ＿Ｈｏｐｓの値をＴｏｔａｌ＿ＲＦＲ＿Ｒｅｌａｙ＿Ｎｕｍｂｅｒとして格納し、次いで、前述のＣＴＲパケットのほか、［００３４（ｃ）］で述べた別のバッファパケットＢＵＦを送信する。ＢＵＦパケットは、ＲＦＲパケットが受信されてから適切な時間が経過した後に送信される。また、ＢＵＦパケットのみを受信したノードは、バッファノードになる。ソースは、ＣＴＲパケットを受信すると、適切な時間待機してから前述のＢＵＦパケットをブロードキャストする。

[0050]本明細書に開示するバッファ付きユニキャスト経路設定プロトコルの一部であるＲＦＲメッセージは、ネットワークをフラッディング状態とする（溢れさせる）点に留意されたい。こうしたＲＦＲメッセージは、ネットワークを介して急速に伝播するので、ネットワークオーバーヘッドに大きく寄与することはない。一方、ＣＴＲメッセージは、得られる集合経路のみに限定される。

[0051]図２（ａ）と２（ｂ）は、所定のソース（Ｓ）と宛先ノード（Ｄ）の間に設定されたバッファ付きユニキャスト経路を示しており、それぞれＮ＝０、Ｎ＝１の場合に対応している。中継ノード、バッファノード、及び無関係ノードには全て適切に印が付けられている。経路幅パラメタがＮ＝０からＮ＝１に増えると、中継ノード数が増えることに留意されたい。こうしたノードの追加により、ノードの可動性又はリンクの障害に対するロバスト性を高めることができる。ネットワークが利用できるＮの最大値は、タイムスロットの再利用のパターンといった他の要因に左右される。

[0052]図２（ｃ）は、ソースと宛先でのＢＵＦパケットの送信による影響を示している。具体的には、Ｎ＝０でＢＵＦパケット送信がプロトコルに含まれない場合に得られる経路を示している。この場合、ソースに隣接し中継ノードに隣接していないノードが存在しており、したがって、当該ノードはＣＴＲパケットを受信しない。図２（ｃ）の宛先に隣接するネットワーク上の最も下にあるノードは、ソースによって送信されるＣＴＲパケットと隣接するノードの一つによって送信される遅延したＲＦＲパケットとが衝突することによってＣＴＲパケットを受信できず、その結果、バッファノードではなく無関係ノードとして動作する。

本発明の実施形態に係る、別個の協調型パスの集合としてソースノード（Ｓ）と宛先ノード（Ｄ）との間にある協調型経路を示す図である。本発明の実施形態に係り、Ｎ＝０の設定の場合のソース（Ｓ）、宛先（Ｄ）、中継ノード（Ｒ）、バッファノード（Ｂ）、及び無関係ノード（Ｕ）を含む複数ノードのネットワークを示す図である。本発明の実施形態に係り、Ｎ＝１の設定の場合のソース（Ｓ）、宛先（Ｄ）、中継ノード（Ｒ）、バッファノード（Ｂ）、及び無関係ノード（Ｕ）を含む複数ノードのネットワークを示す図である。本発明の実施形態に係り、Ｎ＝１の設定の場合のソース（Ｓ）、宛先（Ｄ）、中継ノード（Ｒ）、バッファノード（Ｂ）、及び無関係ノード（Ｕ）を含む複数ノードのネットワークを示す図である。

符号の説明

Ｓ…ソースノード、Ｄ…宛先ノード、Ｒ…中継ノード、Ｂ…バッファノード、Ｕ…無関係ノード、Ｎ…経路幅パラメータ。

Claims

複数のノードを有する無線ネットワークにおけるソースノードと宛先ノードとの間の連続中継通信を構築する方法であって、
複数の中間ノードを介して前記ソースノードから前記宛先ノードに要求メッセージを送信するステップであって、前記複数の中間ノードの各々は前記要求メッセージを受信し、該要求メッセージの一部として含まれる要求ホップカウントを増分し、該要求メッセージを送信することによって該要求メッセージを中継し、各中間ノードによって送信される前記要求メッセージは前記複数の中間ノードのうち一以上に関するパラメータを特定しておらず、前記複数の中間ノードの各々は複数の他の中間ノードから送信された前記要求メッセージを受信できる、該ステップと、
前記宛先ノードにおいて前記要求メッセージを受信するステップと、
前記宛先ノードにおいて前記要求メッセージを受信することに応答して、少なくとも前記複数の中間ノードのうちのサブセットを介して前記宛先ノードから前記ソースノードに受領メッセージを送信するステップであって、前記サブセットの中間ノードの各々は前記受領メッセージを受信し、該受領メッセージの一部として含まれる受領ホップカウントを増分し、該受領メッセージを送信することによって該受領メッセージを中継し、各中間ノードによって送信される前記受領メッセージは前記複数の中間ノードのうち一以上に関するパラメータを特定しておらず、前記サブセットの中間ノードの各々は該サブセットにおける複数の他のノードから送信された前記受領メッセージを受信できる、該ステップと、
前記受領メッセージが前記ソースノードで受信された後に、少なくとも前記サブセットの中間ノードを介して、ソースノードと宛先ノードとの間でデータメッセージを送信するステップであって、前記サブセットの中間ノードの各々は前記データメッセージを受信し該データメッセージを送信することによって該データメッセージを中継し、前記サブセットの中間ノードの各々は該サブセットにおける複数の他のノードから送信された前記データメッセージを受信できる、該ステップと、
を含む方法。
前記複数の中間ノードのうち一以上の中間ノードが、該中間ノードによって受信した前記要求メッセージと前記受領メッセージに基づき、前記ソースノードと前記宛先ノードとの間のデータメッセージの中継に参加するか否かを決定する、請求項１に記載の方法。
前記中間ノードは、前記ソースノードから該中間ノードまでのホップ数を表す要求ホップカウントを得るために前記要求メッセージを調べ、
前記中間ノードは、前記宛先ノードから該中間ノードまでのホップ数を表す受領ホップカウントを得るために前記受領メッセージを調べ、
前記中間ノードは、前記要求ホップカウントと前記受領ホップカウントに基づき、前記ソースノードと前記宛先ノードとの間のデータメッセージの中継に参加するか否かを決定する、
請求項２に記載の方法。
前記中間ノードは、（１）前記要求ホップカウントと前記受領ホップカウントとを合わせることで得られる和と（２）前記ソースノードと前記宛先ノードとの間の最小ホップ数を表すホップ数合計とを比較して、前記ソースノードと前記宛先ノードとの間のデータメッセージの中継に参加するか否かを決定する、請求項３に記載の方法。
前記ホップ数合計は、前記宛先ノードで求められ、前記宛先ノードから送信される前記受領メッセージの一部として含まれる、請求項４に記載の方法。
前記和が前記ホップ数合計を経路幅パラメータＮ上回ることがない場合、前記中間ノードは前記ソースノードと前記宛先ノードとの間のデータメッセージの中継に参加し、ここで、Ｎは、前記要求メッセージ、前記受領メッセージ、又はこれらの双方で送信される非負の整数である、請求項４に記載の方法。
前記要求メッセージ又は前記受領メッセージの送信前に、前記経路幅パラメータＮが前記ネットワーク内の全ノードに既知である、請求項６に記載の方法。
前記中間ノードがデータメッセージの前記中継に参加しないと決定した場合に、該中間ノードは前記受領メッセージの中継を行わない、請求項２に記載の方法。
前記中間ノードがデータメッセージの前記中継に参加しないと決定した場合に、該中間ノードは前記ソースノードと前記宛先ノードとの間のデータメッセージの中継に参加しないバッファノードとして働く、請求項２に記載の方法。
前記宛先ノードが、前記要求メッセージの受信後、一定時間待機してから前記受領メッセージを送信する、請求項１に記載の方法。
前記ソースノードが、前記受領メッセージの受信後、一定時間待機してから前記データメッセージを送信する、請求項１に記載の方法。
前記宛先ノードが、前記要求メッセージを受信後にバッファメッセージを送信し、
前記バッファメッセージを受信するが前記要求メッセージを受信しない前記ネットワーク内のノードが、前記ソースノードと前記宛先ノードとの間のデータメッセージの中継に参加しないバッファノードとして働く、
請求項１に記載の方法。
前記宛先ノードが、前記要求メッセージの受信後、一定時間待機してから前記バッファメッセージを送信する、請求項１２に記載の方法。
前記ソースノードが、前記受領メッセージを受信後にバッファメッセージを送信し、
前記バッファメッセージを受信するが前記受領メッセージを受信しない前記ネットワーク内のノードが、前記ソースノードと前記宛先ノードとの間のデータメッセージの中継に参加しないバッファノードとして働く、請求項１に記載の方法。
前記ソースノードは、前記受領メッセージの受信後に一定時間待機してから前記バッファメッセージを送信する、請求項１４に記載の方法。
前記要求メッセージが、（ａ）前記ソースノードの識別子、（ｂ）前記宛先ノードの識別子、及び、（ｃ）前記要求メッセージが前記ソースノードから送信された後に受けたホップの数を表す要求ホップカウントを含む、請求項１に記載の方法。
前記受領メッセージが、（ａ）前記ソースノードの識別子、（ｂ）前記宛先ノードの識別子、（ｃ）前記受領メッセージが前記宛先ノードから送信された後に受けたホップの数を表す受領ホップカウント、及び、（ｄ）前記ソースノードと前記宛先ノードとの間の最小ホップ数を表すホップ数合計を含む、請求項１に記載の方法。
前記データメッセージが、（ａ）前記ソースノードの識別子及び（ｂ）前記宛先ノードの識別子を含む、請求項１に記載の方法。
複数のノードを有する無線ネットワークにおいて中継通信を構築するシステムであって、
ソースノードと、
宛先ノードと、
複数の中間ノードと、
を備え、
前記ソースノードが前記複数の中間ノードを介して前記宛先ノードに要求メッセージを送信することができ、前記複数の中間ノードの各々が前記要求メッセージを受信し、該要求メッセージの一部として含まれる要求ホップカウントを増分し、前記要求メッセージを送信することによって前記要求メッセージを中継し、各中間ノードによって送信される前記要求メッセージは前記複数の中間ノードのうち一以上に関するパラメータを特定しておらず、前記複数の中間ノードの各々が複数の他の中間ノードから送信される前記要求メッセージを受信でき、
前記宛先ノードが、前記要求メッセージを受信することができ、前記要求メッセージを受信したことに応答して、少なくとも前記複数の中間ノードのうちのサブセットを介して前記ソースノードに受領メッセージを送信することができ、前記サブセットの中間ノードの各々が前記受領メッセージを受信し、該受領メッセージの一部として含まれる受領ホップカウントを増分し、該受領メッセージを送信することによって該受領メッセージを中継し、各中間ノードによって送信される前記受領メッセージは前記複数の中間ノードのうち一以上に関するパラメータを特定しておらず、前記サブセットの中間ノードの各々が該サブセットにおける複数の他のノードから送信された前記受領メッセージを受信することができ、
前記受領メッセージが前記ソースノードで受信された後、前記ソースノードが少なくとも前記サブセットの中間ノードを介して前記宛先ノードにデータメッセージを送信することができ、前記サブセットの中間ノードの各々が前記データメッセージを受信し該データメッセージを送信することによって該データメッセージを中継し、前記サブセットの中間ノードの各々が該サブセットにおける複数の他のノードから送信された前記データメッセージを受信できる、
システム。
前記複数の中間ノードのうち一以上の中間ノードが、前記中間ノードによって受信された前記要求メッセージと前記受領メッセージに基づき、前記ソースノードと前記宛先ノードとの間のデータメッセージの中継に参加するか否かを決定するようになっている、請求項１９に記載のシステム。
前記中間ノードは、前記ソースノードから前記中間ノードまでのホップ数を表す要求ホップカウントを得るために前記要求メッセージを調べるようになっており、
前記中間ノードは、前記宛先ノードから前記中間ノードまでのホップ数を表す受領ホップカウントを得るために前記受領メッセージを調べるようになっており、
前記中間ノードは、前記要求ホップカウントと前記受領ホップカウントに基づき、前記ソースノードと前記宛先ノードとの間のデータメッセージの中継に参加するか否かを決定するようになっている、
請求項２０に記載のシステム。
前記中間ノードは、（１）前記要求ホップカウントと前記受領ホップカウントとを合わせることで得られる和と（２）前記ソースノードと前記宛先ノードとの間の最小ホップ数を表すホップ数合計とを比較することにより、前記ソースノードと前記宛先ノードとの間のデータメッセージの中継に参加するか否かを決定するようになっている、請求項２１に記載のシステム。
前記ホップ数合計は、前記宛先ノードで求められ、前記宛先ノードから送信される前記受領メッセージの一部として含まれる、請求項２２に記載のシステム。
前記和が前記ホップ数合計を経路幅パラメータＮ上回ることがない場合に、前記中間ノードが前記ソースノードと前記宛先ノードとの間のデータメッセージの中継に参加し、ここで、Ｎは前記要求メッセージ、前記受領メッセージ、又はこれらの双方で送信される非負の整数である、請求項２２に記載のシステム。
前記要求メッセージ又は前記受領メッセージの送信前に、前記経路幅パラメータＮが前記ネットワーク内の全ノードに既知である、請求項２４に記載のシステム。
前記中間ノードがデータメッセージの前記中継に参加しないと決定した場合に、該中間ノードは前記受領メッセージの中継を行わない、請求項２０に記載のシステム。
前記中間ノードがデータメッセージの前記中継に参加しないと決定した場合に、該中間ノードは前記ソースノードと前記宛先ノードとの間のデータメッセージの中継に参加しないバッファノードとして働く、請求項２０に記載のシステム。
前記宛先ノードが、前記要求メッセージの受信後、一定時間待機してから前記受領メッセージを送信するように構成されている、請求項１９に記載のシステム。
前記ソースノードが、前記受領メッセージの受信後、一定時間待機してから前記データメッセージを送信するように構成されている、請求項１９に記載のシステム。
前記宛先ノードが、前記要求メッセージの受信後にバッファメッセージを送信するようになっており、
前記バッファメッセージを受信するが前記要求メッセージを受信しない前記ネットワーク内のノードは、前記ソースノードと前記宛先ノードとの間のデータメッセージの中継に参加しないバッファノードとして働く、
請求項１９に記載のシステム。
前記宛先ノードが、前記要求メッセージの受信後、一定時間待機してから前記バッファメッセージを送信するように構成されている、請求項３０に記載のシステム。
前記ソースノードが、前記受領メッセージを受信後にバッファメッセージを送信するようになっており、
前記バッファメッセージを受信するが前記受領メッセージを受信しない前記ネットワーク内のノードが、前記ソースノードと前記宛先ノードとの間のデータメッセージの中継に参加しないバッファノードとして働く、
請求項１９に記載のシステム。
前記ソースノードは、前記受領メッセージの受信後に一定時間待機してから前記バッファメッセージを送信するように構成されている、請求項３２に記載のシステム。
前記要求メッセージが、（ａ）前記ソースノードの識別子、（ｂ）前記宛先ノードの識別子、及び、（ｃ）前記要求メッセージが前記ソースノードから送信された後に受けたホップの数を表す要求ホップカウントを含む、請求項１９に記載のシステム。
前記受領メッセージが、（ａ）前記ソースノードの識別子、（ｂ）前記宛先ノードの識別子、（ｃ）前記受領メッセージが前記宛先ノードから送信された後に受けたホップの数を表す受領ホップカウント、及び、（ｄ）前記ソースノードと前記宛先ノードとの間の最小ホップ数を表すホップ数合計を含む、請求項１９に記載のシステム。
前記データメッセージが、（ａ）前記ソースノードの識別子及び（ｂ）前記宛先ノードの識別子を含む請求項１９に記載のシステム。