ローカル・ピア・グループ（ＬＰＧ）に基づく車両アドホックネットワークにおける高信頼度マルチキャスト方法
マルチキャストメッセージのルーティング方法は、少なくともメッセージと送信元識別子とシーケンス番号とＴｉｍｅ−ｔｏ−Ｌｉｖｅ値とマルチキャストグループ宛先とを含むマルチキャストメッセージを受信するステップと、前記マルチキャストグループ宛先がマルチキャスト転送テーブル内に存在するか判断するステップと、前記メッセージが以前に受信したものであるか判断するステップと、前記メッセージが以前に受信したものではないと判断された場合に、前記マルチキャストメッセージを前記マルチキャスト転送テーブルに追加するステップと、前記マルチキャストメッセージを受信したノードが転送ノードであるか判断するステップと、前記マルチキャストメッセージを転送するための待機時間をランダムに設定するステップと、前記待機時間が満了したときに、前記マルチキャストメッセージを転送するステップと、を含む。
【発明の詳細な説明】
【技術分野】
【０００１】
［関連出願の相互参照］
本発明は、共同所有され同時に係属中である、アドホック無線ネットワークにおけるユニキャストおよびマルチキャストメッセージをルーティングするための方法および通信装置と題する、２００６年１０月２３日出願の出願番号第１１／５８５，０４７の米国特許出願（「’０４７出願」）に関連する。
【０００２】
［技術分野］
この発明は、移動環境における通信ネットワークに関連する。より具体的には、本発明は、複数の移動装置間のマルチホップ・マルチキャストメッセージをルーティングするための方法に関連する。
【背景技術】
【０００３】
無線ホームネットワークや、無線オフィスネットワークや、ローカルカフェ、ファーストフードチェーン又はホテルにおけるいわゆる「ホットスポット」ネットワークや、さらには都市全体でのＷｉＦｉ技術の実現であれ、無線技術は今日の生活のあらゆる面において一般的なものとなっている。社会においてこのように無線を推し進める目的は、情報へのアクセスを提供し、社会全体がコンピュータネットワーク、特にインターネットを広く受け入れるとともに利用することで享受してきた生産性をさらに向上させるためである。
【０００４】
無線通信社会になるという願望は、移動車両のような移動装置にまで広がっている。この種の無線通信ネットワークは、限定はしないが、緊急路上障害物警告、交差点での協調、隠れた車道に関する警告、車線変更または合流の支援などを含む、車両安全アプリケーションの多くの態様において現れる。
【０００５】
車両安全通信（「ＶＳＣ」）は大きく分類して、車車間通信とインフラ協調車両通信とに分けることができる。車車間通信では、固定インフラストラクチャからの支援なしに車両同士がお互いに通信する。車両同士が同じ無線通信範囲内に位置する場合や、他の車両を介したマルチホップ通信が可能な場合に、車両同士がお互いに通信する。インフラ協調車両通信では、路側無線アクセスポイントなどのインフラストラクチャの支援を受けて、車両同士がお互いに通信する。この場合、車両はインフラストラクチャのみと通信することもできる。
【０００６】
衝突回避のような種々のＶＳＣアプリケーションを支援するために、重要なＶＳＣ性能要件には、遅延時間が短いこと（１００ミリ秒のオーダー）と、スループット（近くの車両が警告メッセージを受信に成功する確率と同等）を維持することが含まれる。
【０００７】
’０４７出願には、１台の移動車両をグループヘッダとして選択し、このグループヘッダを利用してローカル・ピア・グループを維持し、ローカルルーティング情報を生成することで、移動車両のグループをローカル・ピア・グループに組織化することが記述されている。移動車両はユニキャストおよびマルチキャストのルーティングに適合される。しかしながら依然として、スループットをさらに向上し遅延が少ないマルチキャストのルーティング方法に対する要求がある。
【発明の概要】
【０００８】
したがって、マルチキャストメッセージのルーティング方法が開示される。この方法は
、少なくともメッセージと送信元識別子とシーケンス番号とＴｉｍｅ−ｔｏ−Ｌｉｖｅ値とマルチキャストグループ宛先とを含むマルチキャストメッセージを受信するステップと、前記マルチキャストグループ宛先がマルチキャスト転送テーブル内に存在するか判断するステップと、前記メッセージが以前に受信したものであるか判断するステップと、前記メッセージが以前に受信したものではないと判断された場合に、前記マルチキャストメッセージを前記マルチキャスト転送テーブルに追加するステップと、前記マルチキャストメッセージを受信したノードが転送ノードであるか判断するステップと、前記マルチキャストメッセージを転送するための待機時間をランダムに設定するステップと、前記待機時間が満了したときに、前記マルチキャストメッセージを転送するステップと、を含む。
【０００９】
前記メッセージが以前に受信したものである場合に、少なくとも同一のメッセージと送信元識別子とシーケンス番号とマルチキャストグループ宛先とを含む第２のマルチキャストメッセージを前記ランダムに設定された待機時間内に下流ノードから受信したときは、前記待機時間を停止する。待機時間が停止された場合は、マルチキャストメッセージは転送されない。
【００１０】
第２のマルチキャストメッセージが下流ノードから受信されたかの判断は、第２のマルチキャストメッセージからＴｉｍｅ−ｔｏ−Ｌｉｖｅ値を抽出する工程と、前記Ｔｉｍｅ−ｔｏ−Ｌｉｖｅ値にプリセット値を加えてオフセットＴｉｍｅ−ｔｏ−Ｌｉｖｅ値を生成する工程と前記マルチキャスト転送テーブルから同一のメッセージを含むマルチキャストメッセージのＴｉｍｅ−ｔｏ−Ｌｉｖｅ値を取り出す工程と、前記オフセットＴｉｍｅ−ｔｏ−Ｌｉｖｅ値と前記取り出されたＴｉｍｅ−ｔｏ−Ｌｉｖｅ値とを比較する工程とを含み、前記取り出されたＴｉｍｅ−ｔｏ−Ｌｉｖｅ値が前記オフセットＴｉｍｅ−ｔｏ−Ｌｉｖｅ値よりも大きい場合に、前記待機時間が停止される。
【００１１】
前記取り出されたＴｉｍｅ−ｔｏ−Ｌｉｖｅ値が前記オフセットＴｉｍｅ−ｔｏ−Ｌｉｖｅ値と等しい場合は、前記待機時間はランダム値にリセットされる。
【００１２】
本方法は、転送後にＡＣＫフラグを未確認に設定するステップと、再送時間を所定時間に設定するステップと、をさらに含む。前記メッセージが以前に受信されたものである場合に、本方法は、少なくとも同一のメッセージと送信元識別子とシーケンス番号とマルチキャストグループ宛先とを含む第２のマルチキャストメッセージを下流ノードから受信したときは、前記再送時間を停止するステップをさらに含む。前記再送時間を停止した後に、ＡＣＫフラグを確認済みに設定される。
【００１３】
本方法は、前記再送時間が満了したときに、前記マルチキャストメッセージを再送するステップと、再送後に前記送信時間を所定時間に設定するステップと、をさらに含む。
【００１４】
本方法は、再送の上限に達したか判断するステップと、前記判断に基づいて、前記再送時間が満了したときに、前記マルチキャストメッセージを再送するステップと、再送カウンタを増加させるステップと、再送後に前記再送時間を所定時間に設定するステップと、をさらに含む。再送の上限に達した場合には、再送時間が停止される。
【００１５】
前記マルチキャスト転送テーブルは、前記グループ宛先と前記送信元識別子と前記シーケンス番号と前記メッセージと前記ＡＣＫフラグと前記再送時間値と前記再送カウンタと前記Ｔｉｍｅ−ｔｏ−Ｌｉｖｅ値とを含む。
【００１６】
マルチキャストメッセージをルーティングするための別の方法も開示される。本方法は、少なくともメッセージと送信元識別子とシーケンス番号とＴｉｍｅ−ｔｏ−Ｌｉｖｅ値とマルチキャストグループ宛先とを含むマルチキャストメッセージを受信するステップと
、前記マルチキャストグループ宛先がマルチキャスト転送テーブル内に存在するか判断するステップと、前記メッセージが以前に受信したものであるか判断するステップと、前記マルチキャストメッセージが以前に受信したものではないと判断された場合に、前記マルチキャストメッセージを前記マルチキャスト転送テーブルに追加するステップと、前記マルチキャストメッセージを受信したノードがマルチキャスト受信ノードであるか判断するステップと、マルチキャスト受信ノードに確率値をランダムに割り当てるステップと、前記ランダムに割り当てられた確率値とプリセット確率閾値とを比較するステップと、前記比較に基づいて前記マルチキャストメッセージを転送するステップと、を含む。
【００１７】
本方法は、前記プリセット確率閾値を設定するステップをさらに含む。
【００１８】
前記マルチキャスト転送テーブルは、前記グループ宛先と前記送信元識別子と前記シーケンス番号とを含む。
【００１９】
本方法は、転送後にＡＣＫフラグを未確認に設定するステップと、再送時間を所定時間に設定するステップと、をさらに含む。
【００２０】
本方法は、再送カウンタを増加させるステップをさらに含む。
【００２１】
前記メッセージが以前に受信されたものである場合に、本方法は、少なくとも同一のメッセージと送信元識別子とシーケンス番号とマルチキャストグループ宛先とを含む第２のマルチキャストメッセージを下流ノードから受信したときに、前記再送時間を停止する工程をさらに含む。
【００２２】
前記再送時間を停止した後に、ＡＣＫフラグを確認済みに設定される。
【００２３】
本方法は、再送カウンタの値に基づいて、再送の上限に達したか判断するステップと、前記判断に基づいて、前記再送時間が満了したときに、前記マルチキャストメッセージを再送するステップと、再送カウンタを増加させるステップと、再送後に前記再送時間を所定時間に設定するステップと、をさらに含む。再送の上限に達した場合には、再送時間が停止される。
【００２４】
マルチキャストメッセージをルーティングするための別の方法も開示される。本方法は、少なくともメッセージと送信元識別子とシーケンス番号とＴｉｍｅ−ｔｏ−Ｌｉｖｅ値とマルチキャストグループ宛先とを含むマルチキャストメッセージを受信するステップと、前記マルチキャストグループ宛先がマルチキャスト転送テーブル内に存在するか判断するステップと、前記メッセージが以前に受信したものであるか判断するステップと、を含み、前記メッセージが以前に受信されたものである場合に、前記Ｔｉｍｅ−ｔｏ−Ｌｉｖｅ値にプリセット値を加えてオフセットＴｉｍｅ−ｔｏ−Ｌｉｖｅ値を生成する工程と、前記オフセットＴｉｍｅ−ｔｏ−Ｌｉｖｅ値と前記マルチキャスト転送テーブル内のＴｉｍｅ−ｔｏ−Ｌｉｖｅ値を比較する工程と、前記オフセットＴｉｍｅ−ｔｏ−Ｌｉｖｅ値が前記マルチキャスト転送テーブル内のＴｉｍｅ−ｔｏ−Ｌｉｖｅ値以上である場合に、前記マルチキャストメッセージを破棄する工程と、を含む。
【００２５】
前記マルチキャストメッセージが以前に受信したものではない場合に、本方法は、ＡＣＫフラグを未確認に設定する工程と、再送カウンタを増加させる工程と、再送時間を所定値に設定する工程と、マルチキャストメッセージを転送する工程と、を含む。
【００２６】
前記オフセットＴｉｍｅ−ｔｏ−Ｌｉｖｅ値が前記マルチキャスト転送テーブル内のＴｉｍｅ−ｔｏ−Ｌｉｖｅ値よりも小さい場合に、本方法は、ＡＣＫフラグを確認済みに設
定する工程と、前記再送時間を停止する工程と、をさらに含む。
【００２７】
本発明のこれらおよび他の特徴、利益や利点は、以下の図面を参照することによって明らかになる。なお、図面を通して、類似の参照符号は類似の構造を指している。
【図面の簡単な説明】
【００２８】
【図１】図１は、マルチキャストメッセージ用に設定されたローカル・ピア・グループの例を説明する。
【図２】図２は、ハートビートメッセージの例を説明する。
【図３】図３は、メンバシップレポートメッセージの例を説明する。
【図４】図４は、本発明の第１の実施形態に係るマルチキャストパケットのルーティング方法を説明する。
【図５】図５は、本発明の第１の実施形態に係る、転送ノードおよびマルチキャスト受信ノードのためのＭＰキャッシュテーブルの例を説明する。
【図６】図６は、本発明の第２の実施形態に係るマルチキャストパケットのルーティング方法を説明する。
【図７】図７は、本発明の第２の実施形態に係るルーティング方法の例を説明する。
【図８】図８は、本発明の第３の実施形態に係るマルチキャストパケットのルーティング方法を説明する。
【図９】図９は、本発明の第３の実施形態に係るマルチキャストパケットのルーティング方法を説明する。
【図１０】図１０は、本発明の第３の実施形態に係るマルチキャストパケットのルーティング方法を説明する。
【図１１】図１１は、本発明の第３の実施形態に係る、転送ノードのためのＭＰキャッシュテーブルの例を説明する。
【図１２】図１２は、本発明の第４の実施形態に係るマルチキャストパケットのルーティング方法を説明する。
【図１３】図１３は、本発明の第４の実施形態に係るマルチキャストパケットのルーティング方法を説明する。
【図１４Ａ】図１４Ａは、本発明の第４の実施形態に係るマルチキャストパケットのルーティング方法を説明する。
【図１４Ｂ】図１４Ｂは、本発明の第４の実施形態に係るマルチキャストパケットのルーティング方法を説明する。
【図１５Ａ】図１５Ａは、本発明の第４の実施形態に係る、転送ノードのためのＭＰキャッシュテーブルの例を説明する。
【図１５Ｂ】図１５Ｂは、本発明の第４の実施形態に係る、マルチキャスト受信ノードのためのＭＰキャッシュテーブルの例を説明する。
【図１６】図１６は、本発明の第５の実施形態に係るマルチキャストパケットのルーティング方法を説明する。
【図１７】図１７は、本発明の第６の実施形態に係る、マルチキャスト受信ノードによるマルチキャストパケットのルーティング方法を説明する。
【図１８】図１８は、本発明の第７の実施形態に係るマルチキャストパケットのルーティング方法を説明する。
【図１９】図１９は、本発明の第８の実施形態に係るマルチキャストパケットのルーティング方法を説明する。
【図２０】図２０は、本発明の第９の実施形態に係るマルチキャストパケットのルーティング方法を説明する。
【図２１】図２１は、本発明の第７〜第９の実施形態の係る、転送ノードのためのＭＰキャッシュテーブルの例を説明する。
【発明を実施するための形態】
【００２９】
［定義］
「ノード」は、チャネルの決定・選択処理や以下の説明で記載される方法を実行するルータである。例えば、通信装置を備える移動車両はノードである。この出願では、ノードと移動車両は同じ意味で使われている。
【００３０】
「マルチキャストメッセージ」は１つまたはそれ以上の宛先を持つメッセージである。詳細な説明では、マルチキャストメッセージはマルチキャストパケット（ＭＰ）と称される。「ホップ」はメッセージを中継するノードである。２ノード間、すなわち送信元と宛先の間の「ホップカウント」は、中継ノードの数に１を足したものに等しい。
【００３１】
本発明によれば、ローカル・ピア・グループ（ＬＰＧ）に組織化されたノードまたは移動車両は、マルチキャストルーティングテーブルを生成するために相対位置、一意の識別子、ＬＰＧに関する情報を交換する。後述するハートビートメッセージやメンバシップレポートメッセージのような制御パケット内の情報に基づいて、ルーティングテーブルが生成される。マルチキャストは、１つのマルチキャストセッションについて複数の送信元ノード７００とマルチキャスト受信ノード２０に対応する。
【００３２】
ＬＰＧ１は、近くの複数のノード１０から動的に形成される。具体的には、第１のノードが無線信号をブロードキャストし、第１のノードの範囲内の他のノード１０は、この無線信号を受信する能力がある。ＬＰＧ１は無線通信範囲に基づいて形成されるので、ＬＰＧ１内のノードは、固定インフラストラクチャを必要とせずに、１ホップまたはマルチホップで互いに通信できる。ハートビートメッセージおよびメンバシップレポートの送信に基づいて、ＬＰＧ１は形成および維持される。
【００３３】
図１は、マルチキャストメッセージ用に設定されたモードを持つＬＰＧ１を示す。マルチキャストを行うために、ノード１０は、マルチキャスト受信ノードと転送ノード９０の２つのグループに分けられる。マルチキャスト受信ノード２０はマルチキャストメッセージの受信が意図されるノードである。転送ノード９０はメッセージを転送する。ＬＰＧ１内の全てのノード１０は、転送ノードにもマルチキャスト受信ノード２０にもなりうる。さらに、ＬＰＧ１内の１つのノードがグループヘッダ（ＧＨ）として選択される。ＧＨは、他のノードやインフラストラクチャからの命令なしにＬＰＧ１を維持および制御することを指定されたＬＰＧ１内の移動装置またはノード１０である。ノード１０は、メンバシップレポートをＧＨへ中継するために用いられるときに、ＦＮ９０になる。ＬＰＧ１の形成、維持、ＧＨの選択、制御は’０４７出願に記載されており、その内容は参照により本明細書に含まれる。
【００３４】
図２は、本発明に係るハートビートメッセージ２００の例を示す。ＧＨは、ハートビートメッセージ２００を定期的に送出して、ＬＰＧ１を識別（identify）するとともにＬＰＧ１に関する情報を提供する。この周期は固定間隔（Ｔ）である。この間隔（Ｔ）の値は、設計や運用の要求に基づいて選択可能である。ＧＨは、ＬＰＧ１に含まれる全ノードのリストの維持も行う。このリストには、ノードがＬＰＧ１に参加した時のタイムスタンプ、あるいは、ＧＨがノードからステータス更新を受信した時のタイムスタンプが含まれる。このリストは、ＬＰＧ１に対する種々の維持・管理機能のために用いられる。例えば、このリストは、グループサイズを追跡したり、マルチキャストルーティングテーブルを作成・更新したり、ヘッダ解決のために用いることができる。さらに、このリストは、ＬＰＧ１内の他の全てのノードに周期的にブロードキャストされる。ハートビートメッセージ２００がＬＰＧ１内の全ノード１０にブロードキャストされる。
【００３５】
ハートビートメッセージ２００は、ＬＰＧ１の識別子、ＧＨ ＩＤ、シーケンス番号、
ハートビートメッセージの種類（例えば、完全なグループリスト付きのハートビートか、増分（incremental）グループリスト付きのハートビートか、グループリストなしのハートビートか）を含む。ある実施形態では、ハートビートメッセージは全てのパケットにおいて完全なグループリストを含む。完全なグループリストを使うことが、ルーティング制御と正しいグループメンバのリストを維持するための最も正確な方法であるが、完全なグループ付きのハートビートのためには相当量の帯域幅が必要となる。別の実施形態では、ハートビートメッセージ２００は、ｎ回おきに完全なグループリストを含む。例えば、３回おきにハートビートが完全なグループリストを含むようにする。ＴｏＨｂは、ハートビートメッセージの種類を意味する。ハートビートメッセージの種類は、ＬＰＧ１のトポロジー変化の早さとハートビートのブロードキャスト頻度の影響を受ける。ＬＰＧ１のトポロジー変化速度が速くなると、全てのハートビートメッセージ２００に完全なグループリストを含める必要性が高まる。
【００３６】
ハートビートメッセージ２００は、ＧＨからのホップカウント（ＨＣ）も含む。最初は、ＨＣは所定値、たとえば１に設定される。ハートビートメッセージ２００がノードによって中継されるたびに、中継ノードがＨＣ値を１増加させる。すなわち、ＨＣ＝ＨＣ＋１とする。ＨＣ値は、ＬＰＧのサイズを限定したり、ハートビートメッセージ２００内の情報の古さを示したり、オーバヘッドを減らすための制御パケットのルーティングを制御したりするために用いることができる。各ＬＰＧ１に対して、ルーティングの最大ホップカウント（例えば１０）がある。ＨＣが最大ホップカウントに達すると、その制御パケットはそれ以上中継されない。
【００３７】
最大ホップカウント、ＨＣおよびシーケンス番号を用いることで、ＬＰＧ１内で制御パケットが無限に複製されることを防止できる。ホップカウントは中継戦略のためにも利用される。ノードがハートビートメッセージを転送するときにメッセージにＩＤ情報を含めるので、次ホップのノードは、このハートビートメッセージ２００を誰が中継するのかを知ることができる。
【００３８】
上述したように、ハートビートメッセージ２００はグループリストも含むことができる。グループリストは、ＬＰＧ１のメンバに関する情報を含むことができる。たとえば、ＬＰＧ１内のメンバ数、各メンバのＩＰアドレス、ＧＨからのホップカウントや分類などである。
【００３９】
分類は、たとえばアップリンク、ダウンリンク、ピアのような、ＧＨからの相対的な方向を示すコードであり得る。ピア分類は、ノードがＧＨと同じ無線通信範囲内であることを示す。すなわち、全てのピアノードは、ＧＨから同じホップカウントを有する。上流ノードはハートビートから決定される。下流ノードは、後述するメンバシップレポート（ＭＲ）３００に基づいて決定される。上流送信はＧＨ２５に向かう方向の通信を意味し、下流送信はＧＨ２５からの離れる方向の通信を意味する。分類は相対的な用語である。各ノードはその近隣ノードを異なる３つの種類に分けることができる。他のノードのメンバシップレポートのホップカウント（ＨＣ）が自ノードのＨＣよりも１少なければ、自ノードは上流ノードである。そのＨＣが自身のＨＣと同じであれば、自ノードはピアである。そのＨＣが自身のＨＣよりも１大きければ、自ノードは下流ノードである。
【００４０】
図３はメンバシップレポート（ＭＲ）３００の例を示す。ＭＲ３００はＧＨ以外のノードからブロードキャストされる制御パケットであり、その受取人はＧＨ２５である。ＭＲ３００は、ハートビートメッセージ２００に対する応答として生成される。ＭＲ３００は、メンバシップリスト、下流ノードＩＤ、下流ノードに対する次ホップのような収集可能なルーティング情報を含む。ＭＲ３００は、ＧＩＤやグループヘッダＩＤのような、ハートビートメッセージ２００と同じ情報のいくつかを含む。ＭＲ３００は、ＭＲシーケンス
番号も含む。ＭＲシーケンス番号は、ハートビートメッセージ２００のシーケンス番号と同様のものであり、ＭＲの順序を維持するために用いられる。ＭＲシーケンス番号はある特定のノードに対するＭＲの順序である。典型的には、ＭＲシーケンス番号は、ＭＲ３００のきっかけとなったハートビートメッセージ２００のシーケンス番号と同じ値を有する。
【００４１】
ＭＲ３００には、発信元ノード、すなわち、ＭＲ３００を生成したノードのノードＩＤも含まれる
【００４２】
ＭＲ３００は次ホップ中継ＩＤも含む。次ホップ中継ＩＤは、ＧＨへ向かうＭＲ３００に対する中継の指示である。次ホップの情報は、受信したハートビートメッセージ２００から直接決定される。ノード１０が新しいすなわち新規のハートビートメッセージ２００を受信すると、何らかのパケット処理を行う前にＩＰ層およびＭＡＣ層から直前の中継ノードのＩＤを取り戻す。直前の中継ノードのＩＤはメモリに格納され、ＭＲ３００の次ホップ中継ＩＤとして用いられる。ノード１０がハートビートメッセージ２００を転送するときは、ノード１０は自身のＩＤをパケットに含める。これを受信する次ホップノードは、新しいすなわち新規のハードビートメッセージ２００を受信すると、このＩＤをＧＨ２５に達するための次ホップ中継ＩＤとして格納する。新しいすなわち最新のハートビートメッセージ２００は、最も小さいＨＣと新しいシーケンス番号を有する。
【００４３】
ＭＲ３００は「ＭＲ標識の種類」ＴｏＭＲも含む。ＭＲ３００には、単一メンバレポートおよび複数集約メンバレポート（aggregated multiple member report）の２つの種類がある。単一メンバＭＲは発信元ノードからのＭＲ３００のみを含む。複数集約メンバレポートは２つ以上のノードのＭＲ３００を含む。１つのＭＲ３００が複数のＭＲを含んで送られる。
【００４４】
さらに、ＭＲ３００はＧＨからのホップカウント（ＨＣＧＨ）を含んでも良い。（ＨＣＧＨ）は、ＧＨから発信ノードまでのＭＲ３００のＨＣ値である。ＭＲ３００は、報告ノードが利用可能なチャネルのリストを含む。さらに、ＭＲは、ＭＲ３００をＧＨに向かって中継した全ノードについての利用可能なチャネルのリストを含んでも良い。さらに、ＭＲ３００は、その状態またはマルチキャストメッセージを中継可能であるか、すなわち転送ノードステータスを含む。
【００４５】
マルチキャストルーティングテーブルは、マルチキャストセッションが開始された後に、ハートビートメッセージ２００およびＭＲ３００から作成される。マルチキャストルーティングテーブルは木構造またはメッシュとして視覚化するのが最も適切といえる。木構造またはメッシュは、任意の送信元ノード７００からＦＮを介してマルチキャスト受信ノード２０に至る経路またはリンクを提供する。マルチキャストセッションを確立するために、マルチキャストセッションに参加したいノード１０はマルチキャストセッションに対応したマルチキャストアプリケーションプログラムを起動する。このアプリケーションプログラムはメモリに格納される。そして、ノードはＦＮかマルチキャスト受信ノードになり、セッション参加の要求を示す信号（ＭＲ３００）を発する。これらの信号によって、マルチキャストセッションに対するマルチキャストツリーの生成が開始される。
【００４６】
ノードがＭＲ３００をＧＨに向かって中継すると、そのノードはマルチキャストグループのＦＮ９０になる。ＦＮ９０は、ここで説明される１つまたはそれ以上の方法によって、マルチキャストセッションに関連づけられたマルチキャストパケットを受け付けて転送することができる。木構造またはメッシュ、すなわちマルチキャストルーティングテーブルは、ここに参照によって明示的に組み入れられる’０４７出願において説明されるいずれかの方法を用いて作成される。マルチキャストルーティングテーブルは、ハートビート
期間ごとに更新される。マルチキャストパケットはマルチキャストルーティングテーブルを用いて経路が定められる。
【００４７】
図４は、本発明の第１の実施形態に係るマルチキャストルーティング方法を示す。本ルーティング方法を、その機能ブロックを用いて説明する。異なる実施形態における同一の機能ブロックは、同一の番号を用いて参照される。
【００４８】
ブロック４００で、マルチキャストパケットがノードに到着する。ブロック４０５で、ノード１０はパケットからマルチキャストグループ識別子を抽出して、ノード１０がマルチキャストセッションのメンバであるか判断する。この判断はマルチキャストルーティングテーブルに基づく。ノード１０は、ＦＮ９０かマルチキャスト受信ノード２０のいずれかであれば、マルチキャストセッションのメンバである。ノード１０がマルチキャストセッションのメンバでなければ、ブロック４１０で、それ以上の処理をせずにマルチキャストパケットは破棄される。ノード１０がマルチキャストセッションのメンバであれば、ブロック４１５で、ノード１０は、ＭＰキャッシュテーブル（例えば図５、５００）内に、受信したマルチキャストパケットと一致するものがあるか探す。本発明の第１の実施形態では、ＭＰキャッシュテーブル５００はＦＮ９０とマルチキャスト受信ノード２０の両方に対して同一である。ＭＰキャッシュテーブル５００は、グループ識別子、送信元識別子、つまりマルチキャストパケットの元々の送信元ノード７００、およびシーケンス番号を含む。パケットのシーケンス番号と送信元識別子の両方が同じであれば、マルチキャストパケットは受信パケットと同一である。マルチキャストパケットが同一であれば、ブロック４１０で、それ以上の処理をせずにマルチキャストパケットは破棄される。
【００４９】
マルチキャストパケットがＭＰキャッシュテーブル５００内のいずれのパケットとも一致しない場合は、ブロック４２０で、ノード１０は、グループ識別子、送信元識別子、マルチキャストパケットの順番のようなマルチキャストに関連する情報をＭＰキャッシュテーブル５００に追加する。マルチキャストパケットがＭＰキャッシュテーブル５００に加えられると、ブロック４２５で、ノード１０はマルチキャストセッションのＦＮ９０であるか判断する。この判断はマルチキャストルーティングテーブルに基づく。ノード１０がマルチキャストセッションのＦＮ９０でなければ、ブロック４３０で、マルチキャストパケットは破棄される。その後、ブロック４４０でノード１０はアイドルになる。
【００５０】
ノード１０がマルチキャストセッションのＦＮ９０であれば、ブロック４３５で、ノードはマルチキャストパケットをＮ回再マルチキャストすなわち転送する。ある実施形態では、ＦＮ９０はマルチキャストパケットをＮ回連続して転送する。パケットが転送される数字「Ｎ」回は予め定められていて変更可能である。到達率の増加とデータオーバヘッドの増加にはトレードオフがある。数字「Ｎ」が増えるにしたがって、データオーバヘッドが著しく増加するが、到達率もまた増加する。別の実施形態では、ＦＮ９０はパケットをＮ回同時に転送する。
【００５１】
マルチキャストパケットを転送した後、ブロック４４０で、ＦＮ９０はアイドルになる。
【００５２】
図５は、本発明の第１の実施形態におけるＭＰキャッシュテーブル５００の例を示す。図５に示すように、ＭＰキャッシュテーブル５００は、ＩＰアドレスのようなセッションやグループの識別子である追加グループ（ＧｒｏｕｐＡｄｄ）、マルチキャストパケットの送信元ノード７００の識別子である送信元識別子、およびパケットのシーケンス番号（ＳｅｑＮｕｍ）を含む。
【００５３】
図６は、本発明の第２の実施形態に係るマルチキャストルーティング方法を示す。ブロ
ック４００で、マルチキャストパケットがノード１０に到着する。ブロック４０５で、ノード１０はパケットからマルチキャストグループ識別子を抽出して、ノード１０がマルチキャストセッションのメンバであるか判断する。この判断はマルチキャストルーティングテーブルに基づく。ノード１０は、ＦＮ９０かマルチキャスト受信ノード２０のいずれかであれば、マルチキャストセッションのメンバである。ノード１０がマルチキャストセッションのメンバでなければ、ブロック４１０で、それ以上の処理をせずにマルチキャストパケットは破棄される。ノード１０がマルチキャストセッションのメンバであれば、ブロック４１５で、ノード１０は、ＭＰキャッシュテーブル内に、受信したマルチキャストパケットと一致するものがあるか探す。本発明の第２の実施形態では、ＭＰキャッシュテーブル５００はＦＮ９０と受信ノードの両方に対して同一である。ＭＰキャッシュテーブル５００は、グループ識別子、送信元識別子、およびシーケンス番号を含む。パケットのシーケンス番号と送信元識別子の両方が同じであれば、マルチキャストパケットは受信パケットと同一である。マルチキャストパケットが同一であれば、ブロック４１０で、それ以上の処理をせずにマルチキャストパケットは破棄される。
【００５４】
マルチキャストパケットがＭＰキャッシュテーブル５００内のいずれのパケットとも一致しない場合は、ノード１０は、ブロック４２０で、受信したマルチキャストパケットについての情報をＭＰキャッシュテーブル５００に追加する。マルチキャストパケットに関連する情報がＭＰキャッシュテーブル５００に加えられると、ブロック４２５で、ノード１０はマルチキャストセッションのＦＮ９０であるか判断する。この判断はマルチキャストルーティングテーブルに基づく。ノード１０がＦＮ９０であれば、ブロック６０５で、ノード１０はマルチキャストパケットを一度転送する。ブロック４４０で、ノード１０はアイドルになる。
【００５５】
ノード１０がＦＮ９０でなければ、ノード１０はマルチキャスト受信ノード２０である。本実施形態によれば、ＦＮ９０による通常の転送に加えて、いくつかのマルチキャスト受信ノード２０がマルチキャストパケットの転送のために選択される。この追加的な転送によって、マルチキャストセッションのメンバがパケットを受信し損ねる可能性が抑えられる。受け取ったマルチキャストデータパケットごとに割り当てられる確率に基づいて、いくつかのマルチキャスト受信ノード２０が選択される。各マルチキャスト受信ノード２０は確率閾値とともにプログラムされる。確率閾値は０と１の間の値である。確率閾値は、複数のマルチキャスト受信ノード２０について同じではない。ある実施形態では、確率閾値はランダムにプログラムされる。別の実施形態では、確率閾値は、ＬＰＧ１内のノード１０の数またはマルチキャストセッション内のノード数に基づいて割り当てられる。言い換えると、確率閾値は周期的に変化しても良い。ある実施形態では、マルチキャストセッションの送信元ノード７００が確率閾値を割り当てても良い。代替として、ＧＨが確率閾値を割り当てても良い。
【００５６】
ブロック６００で、マルチキャスト受信ノード２０であるノード１０は、マルチキャストパケットに割り当てられたランダムな確率と、確率閾値とを比較する。マルチキャストパケットに割り当てられたランダムな確率が確率閾値よりも小さければ、ブロック６０５で、マルチキャスト受信ノードは受信したマルチキャストパケットを転送する。そして、ブロック４４０で、マルチキャスト受信ノード２０はアイドルになる。
【００５７】
マルチキャストパケットに割り当てられたランダムな確率が確率閾値以上であれば、ブロック４３０で、マルチキャスト受信ノード２０は受信したマルチキャストパケットを破棄する。そして、ブロック４４０で、マルチキャスト受信ノード２０はアイドルになる。
【００５８】
図７は、本発明の第２の実施形態に係る方法を実行するマルチキャストセッションの例を示す。送信元ノード７００がマルチキャストセッションを開始し、マルチキャストパケ
ットをマルチキャストする。ＦＮ1 ９０1、ＦＮ2 ９０2、およびＦＮ3 ９０3は、マルチキャストパケットを受信した後に、ブロック６０５で、マルチキャストパケットを転送する。マルチキャスト受信ノード２０1、２０2、２０3はマルチキャストデータパケットを転送せずにマルチキャストパケットを破棄する（ブロック４３０）。しかしながら、マルチキャスト受信ノード２０4、２０5、２０6は、マルチキャストパケットを転送する（ブロック６０５）。ＭＰキャッシュテーブルは本発明の第１の実施形態と同様である（例えば、５００）。ＭＰキャッシュテーブル５００は、ＦＮ９０とマルチキャスト受信ノード２０の両方に対して同一である。
【００５９】
図８〜図１０は、本発明の第３の実施形態に係るルーティング方法を示す。本発明の第３の実施形態によれば、次ホップノードは転送されたマルチキャストパケットの受信通知を行う。この受信通知（acknowledgement）はパッシブ受信通知方式をとる。ＦＮ９０によって転送されたマルチキャストパケットは、その次ホップＦＮによって転送されたマルチキャストパケットによって受信通知が行われる。次ホップＦＮから転送されたマルチキャストパケットは、傍受（overheard）される。
【００６０】
ブロック４００で、マルチキャストパケットがノード１０に到着する。マルチキャストパケットは、マルチキャストグループＩＤ、シーケンス番号、Ｔｉｍｅ−ｔｏ−Ｌｉｖｅ（ＴＴＬ）値、およびデータを含む。ＴＴＬ値は、マルチキャストパケットが中継されるホップ数である。各ホップで、ＦＮ９０はＴＴＬ値を減少させる。ＴＴＬ値は、同一のマルチキャストデータパケットが転送させる回数を制限する機能を果たす。
【００６１】
ブロック４０５で、ノード１０はパケットからマルチキャストグループ識別子を抽出して、ノード１０がマルチキャストセッションのメンバであるか判断する。この判断はマルチキャストルーティングテーブルに基づく。ノード１０がマルチキャストセッションのメンバでなければ、ブロック４１０で、それ以上の処理をせずにマルチキャストパケットは破棄される。ノード１０がマルチキャストセッションのメンバであれば、ブロック８００で、ノード１０はＦＮ９０かマルチキャスト受信ノードであるかを判断する。ノード１０がマルチキャスト受信ノードであれば、処理は図１０のブロック４１５に移動する。ノード１０がマルチキャストセッションのＦＮ９０であれば、ブロック４１５（図８）で、ＦＮ９０はマルチキャストパケットがＭＰキャッシュテーブル（例えば、図１１、５００ａ）内にあるか判断する。
【００６２】
マルチキャストパケットがＭＰキャッシュテーブル５００ａ内のいずれのパケットとも一致しない場合は、ブロック４２０で、ＦＮ９０は受信したマルチキャストパケットをＭＰキャッシュテーブル５００ａに追加する。この実施形態では、マルチキャストパケットに関連する情報とパケットの両方がＭＰキャッシュテーブル５００ａに追加される。
【００６３】
ＦＮ９０は、マルチキャストグループＩＤ、シーケンス番号、送信元識別子、Ｔｉｍｅ−ｔｏ−Ｌｉｖｅ（ＴＴＬ）値、およびデータを抽出し、この情報をＭＰキャッシュテーブル５００ａに付加する。さらに、ＦＮ９０は再送カウンタをゼロに初期化する。再送カウンタ（ｓ＿ｍｐ＿ｃ）は、マルチキャストパケットが再送されうる回数を表す。ある実施形態では、マルチキャストメッセージが再送される回数はあらかじめ定められた最大値に制限される。あらかじめ定められた最大値は全ノード１０に対して同じであっても良い。別の実施形態では、あらかじめ定められた最大値はＧＨや送信元ノード７００のような特定のノードに対して変更可能としても良い。
【００６４】
ＭＰキャッシュテーブルはＦＮ９０とマルチキャスト受信ノードとで異なる。ＦＮ９０用には、ＭＰキャッシュテーブル５００は、マルチキャストパケットについてのマルチキャストセッションＩＤ、送信元識別子、シーケンス番号、マルチキャストパケットデータ
、ＡＣＫ状態、再送タイマ値、再送カウンタ、およびＴＴＬ値を含む。ＡＣＫ状態は「未確認」または「確認済み」のいずれかであり得る。再送タイマ値はオンかオフのいずれかであり得る。タイマがオンであれば、再送タイマ値は初期設定タイマ値といつ再送タイマ値が満了したかの指示も含む。マルチキャスト受信ノード２０用には、ＭＰキャッシュテーブル５００は、マルチキャストセッションＩＤ、送信元識別子、およびシーケンス番号だけを含む。
【００６５】
ブロック８０５で、ＦＮ９０はＡＣＫ状態を「未確認」に初期化する。ＦＮ９０はどのマルチキャストパケットが受信確認され受信されたかを追跡できる。さらに、ＦＮ９０は再送タイマ値をオンに初期化し、タイマを再送時間に設定する。再送時間は、データパケットに含まれるデータの種類、ＦＮ９０の移動速度、およびその他のユーザ定義の基準に応じて変更可能である。例えば、１２ｍｓの再送時間を利用することができる。メッセージに含まれるデータが高い優先度のメッセージであれば、再送時間を短くしても良い。あるいは、メッセージが低い優先度のメッセージであれば、再送時間を長くしても良い。回復遅延は再送時間の値に依存する。再送時間が小さいほど、遅延は短くなる。しかしながら、小さくしすぎると多くの再送信が発生し、不必要な再送信が生じる。
【００６６】
ブロック８１０で、再送カウンタが１増分する。すなわちｓ＿ｍｐ＿ｃ＋１にする。再送カウンタが増分された後、ブロック６０５で、ＦＮ９０はマルチキャストパケットを一度転送する。ＦＮ９０は、転送の前にマルチキャストパケットのＴＴＬ値から１減算する。したがって、次ホップＦＮによって受信されるマルチキャストパケットは、最小のＴＴＬ値を持つ。ブロック４４０で、ＦＮ９０はアイドルになる。
【００６７】
マルチキャストパケットがＭＰキャッシュテーブル５００ａ内のいずれかのパケットと同一であれば、本方法はブロック８１５へ進む。
【００６８】
ＦＮ９０は入力マルチキャストパケットのＴＴＬ値を判断する。上記したようにＴＴＬ値は特定のマルチキャストパケットのホップ数を制御するために用いられる。さらにこの実施形態では、ＴＴＬ値は送信ノード１０および受信ノード１０の相対的な位置を決定するためにも用いられる。具体的には、マルチキャストパケットが転送されるたびに、ノード１０はＴＴＬ値から１減算する（すなわち、ＴＴＬ−１）。特定のＦＮ９０から下流にあるノード１０から受信されたマルチキャストパケットのＴＴＬ値は、ＦＮ９０から転送された同一のマルチキャストパケットのＴＴＬ値よりも小さい。特定のＦＮ９０から上流にあるノード１０から受信されたマルチキャストパケットのＴＴＬ値は、ＦＮ９０から転送された同一のマルチキャストパケットのＴＴＬ値よりも大きい。特定のＦＮ９０と同じホップ数のノード１０から受信されたマルチキャストパケットは、同一のＴＴＬ値を持つ。
【００６９】
ＦＮ９０は、ＦＮ９０による最初のマルチキャストパケットの転送を補うために、判定されたＴＴＬ値にオフセット値の１を加える。これによりオフセットＴＴＬ値が生成される。
【００７０】
ブロック８１５で、ＦＮ９０は、入力パケットのオフセットＴＴＬ値（Ｉｎ＿ＭＰ＿ＴＴＬ＋１）と同一のマルチキャストパケットのＴＴＬ値とを比較する。同一のマルチキャストパケットのＴＴＬ値は、ＭＰキャッシュテーブル５００ａから取り出される。ＭＰキャッシュテーブル５００ａから取り出されたＴＴＬ値がオフセット値よりも大きくない場合は、ブロック４３０で、入力マルチキャストパケットは無視されて破棄される。このマルチキャストパケットは上流ノードから発生したものである。マルチキャストパケットの転送は受信確認されない。ブロック４４０で、ＦＮ９０はアイドルになる。
【００７１】
ブロック８１５においてＭＰキャッシュテーブルから取り出されたＴＴＬ値がオフセット値よりも大きい場合は、ブロック８２０で、ＦＮ９０はこのマルチキャストパケットがすでに受信確認されたか判断する。
【００７２】
ＦＮ９０はＭＰキャッシュテーブル５００ａから同一のマルチキャストパケットについてのＡＣＫ状態を取り出す。同一のマルチキャストパケットがすでに受信確認されていれば、ブロック４３０で、入力マルチキャストパケットは無視されて破棄される。ブロック４４０で、ＦＮ９０はアイドルになる。ＭＰキャッシュテーブル５００ａに変更はない。ブロック８２０において同一のマルチキャストパケットが受信確認されていなければ、本方法はブロック８２５へ進む。
【００７３】
ブロック８２５で、ＦＮ９０は再送タイマを停止する。さらに、ＦＮ９０は、キャッシュテーブル５００ａ内の再送タイマ値を「オフ」に変え、ＡＣＫ状態を「確認済み」に変える。その後、ブロック４３０で入力マルチキャストパケットは破棄される。ブロック４４０で、ＦＮ９０はアイドルになる。マルチキャストパケット転送の受信が確認される。
【００７４】
図９は、マルチキャストパケットの転送が受信確認される前に再送タイマが満了する場合の機能ブロック図を示す。図９に示される機能ブロック図はＦＮ９０によってのみ実行される。
【００７５】
ブロック９００で、再送タイマが満了する。ＦＮ９０は、再送カウンタが最大閾値に達したか判断する。ＦＮは、再送タイマが満了したパケットに対応するマルチキャストパケットの再送カウンタをＭＰキャッシュテーブル５００ａから抽出する。再送カウンタは、最大閾値と比較される。再送カウンタが最大閾値以上であれば、ＦＮ９０はブロック４４０でアイドルになる。
【００７６】
再送カウンタが最大閾値より小さければ、ブロック８０５で、ＦＮ９０はマルチキャストパケットの送信タイマをリセットし、マルチキャストパケットのＡＣＫ状態を「未確認」に初期化する（図９において「Not ACKed」と示される）。
【００７７】
ブロック８１０で、再送カウンタが１増分する。すなわちｓ＿ｍｐ＿ｃ＋１にする。再送カウンタが増分された後、ブロック６０５で、ＦＮ９０はマルチキャストパケットを一度転送する。ＦＮ９０は、転送の前にマルチキャストパケットのＴＴＬ値から１減算する。したがって、次ホップＦＮはマルチキャストパケットを送っているＦＮ９０よりも小さいＴＴＬを持つマルチキャストパケットを受信する。ブロック４４０で、ＦＮ９０はアイドルになる。
【００７８】
図１０は、本発明の第３の実施形態に係るマルチキャスト受信ノード２０の機能ブロックを示す。図８に示すように、ブロック８００においてノード１０がＦＮ９０でなければ、処理は図１０のブロック４１５に進む。ブロック４１５で、マルチキャスト受信ノード２０は、入力マルチキャストパケットがＭＰキャッシュテーブル５００にリストされているか判断する。マルチキャストパケットがすでにリストされていれば、ブロック４３０で、パケットは無視されて破棄される。ブロック４４０で、マルチキャスト受信ノード２０はアイドルになる。
【００７９】
マルチキャストパケットがＭＰキャッシュテーブル５００内のいずれのパケットとも一致しない場合は、マルチキャスト受信ノード２０は、ブロック４２０で、入力マルチキャストパケットについての情報をＭＰキャッシュテーブル５００に追加する。具体的には、マルチキャスト受信ノード２０は、マルチキャストパケットのマルチキャストセッションＩＤ、送信元識別子、およびシーケンス番号をＭＰキャッシュテーブル５００に追加する
。その後、ブロック４３０で、マルチキャストパケットは破棄される。ブロック４４０で、マルチキャスト受信ノード２０はアイドルになる。
【００８０】
図１１は、本発明の第３の実施形態に係るＦＮ用のＭＰキャッシュテーブル５００ａの例を示す。図示されるように、ＭＰキャッシュテーブル５００ａは、２つの異なるマルチキャストパケット（ＭＰ1とＭＰ2）を含む。各マルチキャストパケットに対して、ＭＰキャッシュテーブル５００ａは、マルチキャストセッションＩＤ（ＧｒｏｕｐＡｄｄ）、マルチキャストパケットの送信元識別子、マルチキャストパケットのシーケンス番号（ＳｅｑＮｕｍ）、マルチキャストパケットデータ（ＭＰキャッシュ）、受信確認状態（ＡＣＫ状態）、再送タイマ（Ｒｅｔｒａｎ＿Ｔｉｍｅｒ）、再送カウンタ（ｓ＿ｍｐ＿ｃ）、およびマルチキャストパケットのＴＴＬ値（Ｃ＿ＭＰ＿ＴＴＬ）を含む。図１１に示されるように、マルチキャストパケットの１つは受信確認されており、したがって再送タイマ状態は「オフ」である。
【００８１】
図１２〜図１４（ＡおよびＢ）は、本発明の第４の実施形態に係るルーティング方法を示す。この実施形態によれば、マルチキャスト受信ノード２０は受信し損ねたマルチキャストパケットを局所的に回復することができる。マルチキャスト受信ノード２０は否定的確認（negative acknowledgement）を用いて、他のノード１０にマルチキャストパケットを受信していないことを通知する。受信し損ねたマルチキャストパケットは、受信パケットにおける欠落しているシーケンス番号に基づいて検出される。この検出は受信したマルチキャストパケットの間でのシーケンス番号の比較に基づく。
【００８２】
ブロック４００で、マルチキャストパケットがノード１０に到着する。マルチキャストパケットはマルチキャストグループＩＤ、送信元識別子、シーケンス番号、Ｔｉｍｅ−ｔｏ−Ｌｉｖｅ（ＴＴＬ）値、およびデータを含む。ＴＴＬ値は、マルチキャストパケットが中継されるホップ数である。各ホップで、ＦＮ９０はＴＴＬ値を減少させる。ＴＴＬ値は、同一のマルチキャストデータパケットが転送させる回数を制限する機能を果たす。
【００８３】
ブロック４０５で、ノード１０はパケットからマルチキャストグループ識別子を抽出して、ノード１０がマルチキャストセッションのメンバであるか判断する。この判断はマルチキャストルーティングテーブルに基づく。ノード１０がマルチキャストセッションのメンバでなければ、ブロック４１０で、それ以上の処理をせずにマルチキャストパケットは破棄される。ノード１０がマルチキャストセッションのメンバであれば、ブロック８００で、ノード１０はＦＮ９０かマルチキャスト受信ノードであるかを判断する。ノード１０がマルチキャスト受信ノード２０であれば、処理は図１３のブロック４１５に移動する。
【００８４】
ブロック４１５で、マルチキャスト受信ノード２０は、ＭＰキャッシュテーブル（例えば、図１５Ｂ、５００ｃ）内に入力マルチキャストパケットがリストされているか判断する。
【００８５】
マルチキャストパケットがＭＰキャッシュテーブル５００ｃ内のいずれのパケットとも一致しない場合は、マルチキャスト受信ノード２０は、受信したマルチキャストパケットについての情報をＭＰキャッシュテーブル５００ｃに追加し、ブロック１３００でマルチキャストパケットが不足していないか判断する。マルチキャスト受信ノード２０は、マルチキャストセッションＩＤ、送信元識別子、シーケンス番号、およびマルチキャストパケットデータをＭＰキャッシュテーブル５００ｃに追加する。マルチキャスト受信ノード５００ｃのＭＰキャッシュテーブル５００ｃは、ネガティブＡＣＫ再送タイマ（ＮＡＣＫ再送タイマ：NACK_Retran_Timer）も含む。ＮＡＣＫ再送タイマは、近くのＦＮ９０やマルチキャスト受信ノード２０から同一のマルチキャストパケットが複数回再送信される回数を抑制または制限するために用いられる。
【００８６】
ＮＡＣＫ再送タイマの時間は、ノード数、データパケットに含まれるデータの種類、ノード１０の移動速度、およびその他のユーザ定義の基準に応じて変更可能である。例えば、１２ｍｓの再送時間を利用することができる。メッセージに含まれるデータが高い優先度のメッセージであれば、再送時間を短くしても良い。あるいは、メッセージが低い優先度のメッセージであれば、再送時間を長くしても良い。回復遅延は再送時間の値に依存する。再送時間が小さいほど、遅延は短くなる。しかしながら、小さくしすぎると多くの再送信が発生し、不必要な再送信が生じる。
【００８７】
マルチキャスト受信ノード２０は、受信した全てのマルチキャストパケットについてシーケンス番号を調べることで、受信し損ねたマルチキャストパケットを検出する。検出はブロック１３０５で行われる。例えば、マルチキャスト受信ノード２０がシーケンス番号１０、１１、１３のマルチキャストパケットを受信した場合、シーケンス番号１２のマルチキャストパケットが抜けている。
【００８８】
ブロック１３０５においてマルチキャストパケットが抜けている場合、マルチキャスト受信ノード２０は、ブロック１３１０で、ネガティブＡＣＫ（ＮＡＣＫ）をマルチキャストする。
【００８９】
ＮＡＣＫは、抜けているマルチキャストパケットのマルチキャストセッションＩＤ、送信元識別子、およびシーケンス番号を含む。その後、ブロック４３０で、入力マルチキャストパケットは破棄される。ブロック４４０で、マルチキャスト受信ノード２０はアイドルになる。
【００９０】
ブロック１３０５でマルチキャストパケットが抜けている場合、ブロック４３０で、マルチキャスト受信ノード２０は入力マルチキャストパケットを棄てる。ブロック４４０で、マルチキャスト受信ノード２０はアイドルになる。
【００９１】
ブロック４１５においてマルチキャストパケットがＭＰキャッシュテーブル５００ｃ内のいずれかのパケットと同一であれば、ブロック１２００で、マルチキャスト受信ノード２０はマルチキャストパケットのＮＡＣＫ再送タイマが「オン」であり満了していないか判断する。この判断はＭＰキャッシュテーブル５００ｃからの情報に基づく。（ブロック１２００において）ＮＡＣＫ再送タイマがオンであれば（図１２に示す機能ブロックと同じ）、ブロック１２０５でＮＡＣＫ再送タイマは停止される（図１２に示す機能ブロックと同じ）。マルチキャスト受信ノード２０は、ＮＡＣＫ再送タイマの状態を「オフ」に変更する。これは、同一のマルチキャストが不必要に再送信されるのを抑制するために行われる。そしてブロック４３０で、マルチキャスト受信ノード２０入力マルチキャストパケットを棄てる。ブロック４４０で、マルチキャスト受信ノード２０はアイドルになる。
【００９２】
ＮＡＣＫ再送タイマが（ブロック１２００において）「オフ」であれば、ブロック４３０で、マルチキャスト受信ノード２０は入力マルチキャストパケットを棄てる。ブロック４４０で、マルチキャスト受信ノード２０はアイドルになる。
【００９３】
図１２に戻って、ブロック８００においてノード１０がＦＮ９０であれば、処理はブロック４１５（図１２）へ進む。
【００９４】
マルチキャストパケットがＭＰキャッシュテーブル（図１５Ａ、５００ｂ）内のいずれのパケットとも一致しない場合は、ブロック４２０で、ＦＮ９０は受信したマルチキャストパケットをＭＰキャッシュテーブル５００ｂに追加する。
【００９５】
ＦＮ９０は、マルチキャストグループＩＤ、送信元識別子、シーケンス番号、Ｔｉｍｅ−ｔｏ−Ｌｉｖｅ（ＴＴＬ）値、およびデータを抽出し、この情報をＭＰキャッシュテーブル５００ｂに追加する。さらに、ＦＮ９０は再送カウンタをゼロに初期化する。再送カウンタ（ｓ＿ｍｐ＿ｃ）は、マルチキャストパケットが再送されうる回数を表す。ある実施形態では、マルチキャストメッセージが再送される回数はあらかじめ定められた最大値に制限される。あらかじめ定められた最大値は全ノード１０に対して同じであっても良い。別の実施形態では、あらかじめ定められた最大値はＧＨや送信元ノード７００のような特定のノードに対して変更可能としても良い。
【００９６】
ＭＰキャッシュテーブルはＦＮ９０とマルチキャスト受信ノード２０とで異なる。ＦＮ９０用には、ＭＰキャッシュテーブル５００ｂは、マルチキャストパケットについてのマルチキャストセッションＩＤ、送信元識別子、シーケンス番号、マルチキャストパケットデータ、ＡＣＫ状態、再送タイマ値、再送カウンタ、ＴＴＬ値、およびネガティブＡＣＫ再送タイマ（ＮＡＣＫ再送タイマ）を含む。ＡＣＫ状態は「未確認」または「確認済み」のいずれかであり得る。再送タイマ値はオンかオフのいずれかであり得る。タイマがオンであれば、再送タイマ値は初期設定タイマ値といつ再送タイマ値が満了したかの指示も含む。マルチキャスト受信ノード２０用には、ＭＰキャッシュテーブル５００ｃは、マルチキャストセッションＩＤ、送信元識別子、およびシーケンス番号だけを含む。
【００９７】
ブロック８０５で、ＦＮ９０はＡＣＫ状態を「未確認」に初期化する。ＦＮ９０はどのマルチキャストパケットが受信確認され受信されたかを追跡できる。さらに、ＦＮ９０は再送タイマ値をオンに初期化し、タイマを再送時間に設定する。再送時間は、データパケットに含まれるデータの種類、ＦＮ９０の移動速度、およびその他のユーザ定義の基準に応じて変更可能である。
【００９８】
ブロック８１０で、再送カウンタを１増分する。すなわちｓ＿ｍｐ＿ｃ＋１にする。再送カウンタが増分された後、ブロック６０５で、ＦＮ９０はマルチキャストパケットを一度転送する。ＦＮ９０は、転送の前にマルチキャストパケットのＴＴＬ値から１減算する。したがって、次ホップＦＮはマルチキャストパケットを送っているＦＮ９０よりも小さいＴＴＬ値を含むマルチキャストパケットを受信する。ブロック４４０で、ＦＮ９０はアイドルになる。
【００９９】
ブロック４１５においてマルチキャストパケットがＭＰキャッシュテーブル５００ｃ内のいずれかのパケットと同一であれば、ブロック１２００で、マルチキャスト受信ノード２０はＮＡＣＫ再送タイマが「オン」であり満了していないか判断する。この判断はＭＰキャッシュテーブル５００ｃからの情報に基づく。（ブロック１２００において）ＮＡＣＫ再送タイマがオンであれば、ブロック１２０５でＮＡＣＫ再送タイマは停止される。マルチキャスト受信ノード２０は、ＮＡＣＫ再送タイマの状態を「オフ」に変更する。これは、同一のマルチキャストが不必要に再送信されるのを抑制するために行われる。
【０１００】
ＮＡＣＫ再送タイマが（ブロック１２００において）「オフ」であれば、処理はブロック８１５へ進む。
【０１０１】
ブロック８１５で、ＦＮ９０は同一のマルチキャストパケットのオフセットＴＴＬ値（Ｉｎ＿ＭＰ＿ＴＴＬ＋１）とＴＴＬ値とを比較する。同一のマルチキャストパケットのＴＴＬ値はＭＰキャッシュテーブル５００ｂから取り出される。ＭＰキャッシュテーブル５００ｂから取り出されたＴＴＬ値がオフセット値よりも大きくない場合は、ブロック４３０で、入力マルチキャストパケットは無視されて破棄される。このマルチキャストパケットは上流ノードから発生したものである。マルチキャストパケットの転送は受信確認されない。ブロック４４０で、ＦＮ９０はアイドルになる。
【０１０２】
ブロック８１５においてＭＰキャッシュテーブル５００ｂから取り出されたＴＴＬ値がオフセット値よりも大きい場合は、ブロック８２０で、ＦＮ９０はこのマルチキャストパケットがすでに受信確認されたか判断する。
【０１０３】
ＦＮ９０はＭＰキャッシュテーブル５００ｂから同一のマルチキャストパケットについてのＡＣＫ状態を取り出す。同一のマルチキャストパケットがすでに受信確認されていれば、ブロック４３０で、入力マルチキャストパケットは無視されて破棄される。ブロック４４０で、ＦＮ９０はアイドルになる。ＭＰキャッシュテーブル５００ｂに変更はない。ブロック８２０において同一のマルチキャストパケットが受信確認されていなければ、本方法はブロック８２５へ進む。
【０１０４】
ブロック８２５で、ＦＮ９０は再送タイマを停止する。さらに、ＦＮ９０は、キャッシュテーブル５００ｂ内の再送タイマ値を「オフ」に変え、ＡＣＫ状態を「確認済み」に変える。その後、ブロック４３０で入力マルチキャストパケットは破棄される。ブロック４４０で、ＦＮ９０はアイドルになる。マルチキャストパケット転送の受信が確認される。
【０１０５】
図１４Ａは、ＮＡＣＫを処理する機能ブロックを示す。ＮＡＣＫ処理の動作プロセスは、ＦＮ９０とマルチキャスト受信ノードとで同じである。
【０１０６】
ブロック１４００で、ノード１０はＮＡＣＫパケットを受信する。ノード１０は、受信パケットに含まれる情報に基づいてそのパケットがＮＡＣＫパケットであるか判断する。次にブロック４０５で、ノード１０は、マルチキャストの参加者、すなわちＦＮ９０またはマルチキャスト受信ノード２０であるか判断する。
【０１０７】
ブロック４０５で、ノード１０は受信したＮＡＣＫパケットからマルチキャストグループＩＤを抽出して、ノード１０がマルチキャストセッションのメンバであるか判断する。この判断はマルチキャストルーティングテーブルに基づく。ノード１０がマルチキャストセッションのメンバでなければ、ブロック４１０で、それ以上の処理をせずにそのパケットのＮＡＣＫは破棄される。ノード１０がマルチキャストセッションのメンバであれば、ブロック４１５で、ノード１０はマルチキャストパケットがＭＰキャッシュテーブル（５００ｂまたは５００ｃ）にあるか判断する。例えば、マルチキャストパケットの情報エントリがＭＰキャッシュテーブル（５００ｂまたは５００ｃ）にリストされているか確認する。
【０１０８】
ブロック４１５においてマルチキャストパケットがＭＰキャッシュテーブル内のいずれかのパケットと同一であれば、ブロック１２００で、ノード１０はＮＡＣＫ再送タイマが「オン」であるか判断する。この判断はＭＰキャッシュテーブル（５００ｂまたは５００ｃ）からの情報に基づく。ＮＡＣＫ再送タイマが（ブロック１２００で）オンであれば、ブロック４４０で、ノード１０はアイドルになる。反対に、ＮＡＣＫ再送タイマが（ブロック１２００で）「オフ」であれば、ブロック１４０５で、ノード１０はＮＡＣＫ再送タイマを所定値に設定する。言い換えると、ノード１０はＮＡＣＫ再送タイマの状態を「オン」に変える。ＮＡＣＫ再送タイマはＮＡＣＫ期間の計時を開始する。
【０１０９】
図１４Ｂは、ＮＡＣＫ再送タイマが満了した際のマルチキャストパケットの再送の機能ブロックを示す。ブロック１４１０で、ＮＡＣＫ再送タイマが満了する。ノード１０はＮＡＣＫ再送タイマの状態を「オフ」に変える。ブロック６０５で、ノード１０はマルチキャストパケットを再送または転送する。ブロック４４０で、ノード１０はアイドルになる。
【０１１０】
図１５Ａは、本発明の第４の実施形態に係るＦＮ９０のＭＰキャッシュテーブル５００ｂの例を示す。図示されるように、ＭＰキャッシュテーブル５００ｂは、２つの異なるマルチキャストパケット（ＭＰ1とＭＰ2）を含む。各マルチキャストパケットに対して、ＭＰキャッシュテーブル５００ｂは、マルチキャストセッションＩＤ（ＧｒｏｕｐＡｄｄ）、送信元識別子、マルチキャストパケットのシーケンス番号（ＳｅｑＮｕｍ）、マルチキャストパケットデータ（ＭＰキャッシュ）、受信確認状態（ＡＣＫ状態）、再送タイマ（Ｒｅｔｒａｎ＿Ｔｉｍｅｒ）、再送カウンタ（ｓ＿ｍｐ＿ｃ）、マルチキャストパケットのＴＴＬ値（Ｃ＿ＭＰ＿ＴＴＬ）、およびネガティブＡＣＫ再送タイマ（ＮＡＣＫ再送タイマ）を含む。図１５Ａに示されるように、ＮＡＣＫ再送タイマはマルチキャストパケットの一方についてオンである。
【０１１１】
図１５Ｂは、本発明の第４の実施形態に係るマルチキャスト受信ノードのＭＰキャッシュテーブル５００Ｃの例を示す。図示されるように、ＭＰキャッシュテーブル５００ｂは、２つの異なるマルチキャストパケット（ＭＰ1とＭＰ2）を含む。各マルチキャストパケットに対して、ＭＰキャッシュテーブル５００ｃは、マルチキャストセッションＩＤ（ＧｒｏｕｐＡｄｄ）、送信元識別子、マルチキャストパケットのシーケンス番号（ＳｅｑＮｕｍ）、およびネガティブＡＣＫ再送タイマ（ＮＡＣＫ再送タイマ）を含む。
【０１１２】
図１６は、本発明の第５の実施形態に係るルーティング方法を示す。本発明の第５の実施形態は、マルチキャストパケットが複数回中継される点を除いて、第３の実施形態と同様である。
【０１１３】
ブロック４００で、マルチキャストパケットがノード１０に到着する。マルチキャストパケットは、マルチキャストグループＩＤ、送信元識別子、シーケンス番号、Ｔｉｍｅ−ｔｏ−Ｌｉｖｅ（ＴＴＬ）値、およびデータを含む。ＴＴＬ値は、マルチキャストパケットが中継されるホップ数である。
【０１１４】
ブロック４０５で、ノード１０はパケットからマルチキャストグループ識別子を抽出して、ノード１０がマルチキャストセッションのメンバであるか判断する。この判断はマルチキャストルーティングテーブルに基づく。ノード１０がマルチキャストセッションのメンバでなければ、ブロック４１０で、それ以上の処理をせずにマルチキャストパケットは破棄される。ノード１０がマルチキャストセッションのメンバであれば、ブロック８００で、ノード１０はＦＮ９０かマルチキャスト受信ノードであるかを判断する。ノード１０がマルチキャスト受信ノード２０であれば、処理は図１０の機能ブロック４１５へ進む。ノード１０がマルチキャストセッションのＦＮ９０であれば、ブロック４１５（図１６）で、ＦＮ９０はマルチキャストパケットがＭＰキャッシュテーブル（例えば、５００ａ）内にあるか判断する。
【０１１５】
マルチキャストパケットがＭＰキャッシュテーブル５００ａ内のいずれのパケットとも一致しない場合は、ブロック４２０で、ＦＮ９０は受信したマルチキャストパケットをキャッシュテーブル５００ａへ追加する。
【０１１６】
ＦＮ９０は、マルチキャストグループＩＤ、送信元識別子、シーケンス番号、Ｔｉｍｅ−ｔｏ−Ｌｉｖｅ（ＴＴＬ）値、およびデータを抽出し、この情報をＭＰキャッシュテーブル５００ａに追加する。さらに、ＦＮ９０は再送カウンタをゼロに初期化する。再送カウンタ（ｓ＿ｍｐ＿ｃ）は、マルチキャストパケットが再送されうる回数を表す。第３の実施形態と同様に、ＭＰキャッシュテーブルはＦＮ９０とマルチキャスト受信ノードとで異なる。ＭＰキャッシュテーブル（例えば、５００ａおよび５００）は、第３の実施形態と同一の情報を含む。
【０１１７】
ブロック８０５で、ＦＮ９０はＡＣＫ状態を「未確認」に初期化する。ＦＮ９０はどのマルチキャストパケットが受信確認され受信されたかを追跡できる。さらに、ＦＮ９０は再送タイマ値をオンに初期化し、タイマを再送時間に設定する。再送時間は、データパケットに含まれるデータの種類、ＦＮ９０の移動速度、およびその他のユーザ定義の基準に応じて変更可能である。
【０１１８】
ブロック８１０で、再送カウンタが１増分する。すなわちｓ＿ｍｐ＿ｃ＋１にする。再送カウンタが増分された後、ブロック６０５で、ＦＮ９０はマルチキャストパケットをＮ回転送する。ある実施形態では、ＦＮ９０はマルチキャストパケットをＮ回連続して転送する。パケットが転送される数字「Ｎ」回は予め定められていて変更可能である。到達率の増加とデータオーバヘッドの増加にはトレードオフがある。数字「Ｎ」が増えるにしたがって、データオーバヘッドが著しく増加するが、到達率もまた増加する。別の実施形態では、ＦＮ９０はパケットをＮ回同時に転送する。
【０１１９】
ＦＮ９０は、転送の前にマルチキャストパケットのＴＴＬ値から１減算する。したがって、次ホップＦＮはマルチキャストパケットを送っているＦＮ９０よりも小さいＴＴＬ値を含むマルチキャストパケットを受信する。ブロック４４０で、ＦＮ９０はアイドルになる。
【０１２０】
マルチキャストパケットがＭＰキャッシュテーブル５００ａ内のいずれかのパケットと同一であれば、本方法はブロック８１５へ進む。
【０１２１】
ＦＮ９０は入力マルチキャストパケットのＴＴＬ値を判断する。上記したようにＴＴＬ値は特定のマルチキャストパケットのホップ数を制御するために用いられる。さらにこの実施形態では、ＴＴＬ値は送信ノード１０および受信ノード１０の相対的な位置を決定するためにも用いられる。具体的には、マルチキャストパケットが転送されるたびに、ノード１０はＴＴＬ値から１減算する（すなわち、ＴＴＬ−１）。特定のＦＮ９０から下流にあるノード１０から受信されたマルチキャストパケットのＴＴＬ値は、ＦＮ９０から転送された同一のマルチキャストパケットのＴＴＬ値よりも小さい。特定のＦＮ９０から上流にあるノード１０から受信されたマルチキャストパケットのＴＴＬ値は、ＦＮ９０から転送された同一のマルチキャストパケットのＴＴＬ値よりも大きい。特定のＦＮ９０と同じホップ数のノード１０から受信されたマルチキャストパケットは、同一のＴＴＬ値を持つ。
【０１２２】
ＦＮ９０は、ＦＮ９０による最初のマルチキャストパケットの転送を補うために、判定されたＴＴＬ値にオフセット値の１を加える。これによりオフセットＴＴＬ値が生成される。
【０１２３】
ブロック８１５で、ＦＮ９０は、オフセットＴＴＬ値（Ｉｎ＿ＭＰ＿ＴＴＬ＋１）と同一のマルチキャストパケットのＴＴＬ値とを比較する。同一のマルチキャストパケットのＴＴＬ値は、ＭＰキャッシュテーブルから取り出される。ＭＰキャッシュテーブルから取り出されたＴＴＬ値がオフセット値よりも大きくない場合は、ブロック４３０で、入力マルチキャストパケットは無視されて破棄される。このマルチキャストパケットは上流ノードから発生したものである。マルチキャストパケットの転送は受信確認されない。ブロック４４０で、ＦＮ９０はアイドルになる。
【０１２４】
ブロック８１５においてＭＰキャッシュテーブル５００ａから取り出されたＴＴＬ値がオフセット値よりも大きい場合は、ブロック８２０で、ＦＮ９０はこのマルチキャストパケットがすでに受信確認されたか判断する。
【０１２５】
ＦＮ９０はＭＰキャッシュテーブル５００ａから同一のマルチキャストパケットについてのＡＣＫ状態を取り出す。同一のマルチキャストパケットがすでに受信確認されていれば、ブロック４３０で、入力マルチキャストパケットは無視されて破棄される。ブロック４４０で、ＦＮ９０はアイドルになる。ＭＰキャッシュテーブル５００ａに変更はない。ブロック８２０において同一のマルチキャストパケットが受信確認されていなければ、本方法はブロック８２５へ進む。
【０１２６】
ブロック８２５で、ＦＮ９０は再送タイマを停止する。さらに、ＦＮ９０は、キャッシュテーブル５００ａ内の再送タイマ値を「オフ」に変え、ＡＣＫ状態を「確認済み」に変える。その後、ブロック４３０で入力マルチキャストパケットは破棄される。ブロック４４０で、ＦＮ９０はアイドルになる。マルチキャストパケット転送の受信が確認される。
【０１２７】
残りの機能ブロックは図９および図１０で示された機能ブロックと一致しているので、詳しくは説明しない。
【０１２８】
図１７は、本発明の第６の実施形態に係るマルチキャスト受信ノード２０の機能ブロックを示す。本発明の第６の実施形態は、本発明の第２および第３の実施形態の機能ブロックを組み合わせたものである。ＦＮ９０の機能ブロックは図８および図９で示された機能ブロックと一致しているので、詳しくは説明しない。
【０１２９】
ブロック４１５で、マルチキャスト受信ノード２０は、マルチキャストパケットがＭＰキャッシュテーブル（例えば、５００ａ）内にあるか判断する。マルチキャストパケットがＭＰキャッシュテーブル５００ａないにあれば、ブロック４３０で、マルチキャストパケットは破棄される。ブロック４４０で、マルチキャスト受信ノード２０はアイドルになる。
【０１３０】
マルチキャストパケットがＭＰキャッシュテーブル５００内に無い、すなわち、同一ではない場合は、マルチキャストパケットに含まれる情報がＭＰキャッシュテーブル５００ａに追加される。ブロック６００で、マルチキャスト受信ノード２０は、マルチキャストパケットに割り当てられたランダムな確率と、確率閾値とを比較する。マルチキャストパケットに割り当てられたランダムな確率が確率閾値よりも小さければ、ブロック６０５で、マルチキャスト受信ノード２０は受信したマルチキャストパケットを転送する。そして、ブロック４４０で、マルチキャスト受信ノード２０はアイドルになる。
【０１３１】
マルチキャストパケットに割り当てられたランダムな確率が確率閾値以上であれば、ブロック４３０で、マルチキャスト受信ノード２０は受信したマルチキャストパケットを破棄する。そして、ブロック４４０で、マルチキャスト受信ノード２０はアイドルになる。
【０１３２】
図１８は、本発明の第７の実施形態に係るルーティング方法を示す。第７の実施形態によれば、、マルチキャストパケットの送信はあらかじめ定められた基準に基づいて抑制される。
【０１３３】
図１８に示すように、マルチキャストパケットがノード１０に到着する。マルチキャストパケットは、マルチキャストグループＩＤ、送信元識別子、シーケンス番号、Ｔｉｍｅ−ｔｏ−Ｌｉｖｅ（ＴＴＬ）値、およびデータを含む。ＴＴＬ値は、マルチキャストパケットが中継されるホップ数である。
【０１３４】
ブロック４０５で、ノード１０はパケットからマルチキャストグループ識別子を抽出して、ノード１０がマルチキャストセッションのメンバであるか判断する。この判断はマルチキャストルーティングテーブルに基づく。ノード１０がマルチキャストセッションのメ
ンバでなければ、ブロック４１０で、それ以上の処理をせずにマルチキャストパケットは破棄される。ノード１０がマルチキャストセッションのメンバであれば、ブロック８００で、ノード１０はＦＮ９０かマルチキャスト受信ノードであるかを判断する。ノード１０がマルチキャスト受信ノードであれば、処理はブロック４１５（受信者用）に移動する。ノード１０がマルチキャストセッションのＦＮ９０であれば、ブロック４１５（ＦＮ９０用）で、ＦＮ９０はマルチキャストパケットがＭＰキャッシュテーブル（例えば、５００ｄ）内にあるか判断する。
【０１３５】
マルチキャストパケットがＭＰキャッシュテーブル５００ｄ内のいずれのパケットとも一致しない場合は、ブロック４２０で、ＦＮ９０またはマルチキャスト受信ノード２０は受信したマルチキャストパケットをＭＰキャッシュテーブル５００ｄに付加する。
【０１３６】
ＦＮ９０は、マルチキャストグループＩＤ、送信元識別子、シーケンス番号、Ｔｉｍｅ−ｔｏ−Ｌｉｖｅ（ＴＴＬ）値、およびデータを抽出し、この情報をＭＰキャッシュテーブル５００ｄに付加する。さらに、ＦＮ９０は再送カウンタをゼロに初期化する。再送カウンタ（ｓ＿ｍｐ＿ｃ）は、マルチキャストパケットが再送されうる回数を表す。この実施形態では、ｓ＿ｍｐ＿ｃの値は「０」か「１」である。ＦＮ９０のＭＰキャッシュテーブル５００ｄはランダム転送タイマも含む。
【０１３７】
ＭＰキャッシュテーブルはＦＮ９０とマルチキャスト受信ノード２０とで異なる。マルチキャスト受信ノード２０のＭＰキャッシュテーブル５００ｄは、マルチキャストセッションＩＤ、送信元識別子、およびマルチキャストパケットのシーケンス番号を含む。したがって、ブロック４２０で、マルチキャスト受信ノード２０は、マルチキャストセッションＩＤ、送信元識別子、およびシーケンス番号をＭＰキャッシュテーブル５００に付加する。
【０１３８】
ブロック４２５で、ノード１０はマルチキャストセッションのＦＮ９０であるか判断する。この判断は転送テーブルおよびＭＰキャッシュテーブル（例えば、５００）内の情報に基づく。ノード１０がマルチキャストパケットのＦＮ９０でなければ、ブロック４１９で、入力マルチキャストパケットは破棄される。ノードがＦＮ９０であれば、ブロック１８００で、ＦＮは転送タイマをランダム値に設定する。このランダム値によりマルチキャストパケットの転送が妨げられる。ＦＮ９０は、ランダム値が満了、すなわちランダム転送タイマが満了したときのみマルチキャストパケットを転送する。
【０１３９】
ブロック４１５において、マルチキャストパケットがＭＰキャッシュテーブル５００ｄ内にすでに存在する場合は、ブロック１８０２で、ＦＮ９０はこのパケットをすでに転送したか、すなわちｓ＿ｍｐ＿ｃ＝１であるか判断する。カウンタ（ｓ＿ｍｐ＿ｃ）が１に等しければ、パケットはすでに転送されている。カウンタ（ｓ＿ｍｐ＿ｃ）が０に等しければ、パケットはまだ転送されていない。ＦＮはＭＰキャッシュテーブル５００ｄからカウンタ値を取り出す。ブロック１８０２においてカウンタ（ｓ＿ｍｐ＿ｃ）が１に等しければ、ステップ４３０で、マルチキャストパケットは転送されることなく破棄される。ブロック１８０２で、カウンタ（ｓ＿ｍｐ＿ｃ）が０に等しければ、ＦＮ９０は入力マルチキャストパケットのＴＴＬ値を判断する（ブロック８１５）。上記したように、ＴＴＬ値は特定のマルチキャストパケットのホップ数を制御するために用いられる。さらに、この実施形態では、ＴＴＬ値は送信ノード１０および受信ノード１０の相対的な位置を決定するためにも用いられる。ＦＮ９０は、ＦＮ９０による最初のマルチキャストパケットの転送を補うために、判定されたＴＴＬ値にオフセット値の１を加える。これによりオフセットＴＴＬ値が生成される。
【０１４０】
ブロック８１５で、ＦＮ９０は、オフセットＴＴＬ値（Ｉｎ＿ＭＰ＿ＴＴＬ＋１）と同
一のマルチキャストパケットのＴＴＬ値とを比較する。同一のマルチキャストパケットのＴＴＬ値は、ＭＰキャッシュテーブル５００ｄから取り出される。ＭＰキャッシュテーブル５００ｄから取り出されたＴＴＬ値がオフセット値よりも大きくない場合は、（ブロック４３０で）入力マルチキャストパケットは破棄され、ＦＮ９０はアイドルになる。このマルチキャストパケットは上流ノードまたはピアノードから発生したものである。ブロック８１５においてＭＰキャッシュテーブル５００ｄから取り出されたＴＴＬ値がオフセット値よりも大きい場合は、入力マルチキャストパケットは例えば下流ＦＮ９０から発生したものであり、ＦＮ９０はマルチキャストパケットを転送する必要が無い。
【０１４１】
ブロック１８０５で、ＦＮはマルチキャストパケットのランダム転送タイマを停止する。言い換えると、ＦＮはランダム転送タイマの状態を「オン」から「オフ」に変更する。その後、ブロック４３０でマルチキャストパケットは破棄される。ブロック４４０で、ＦＮ９０はアイドルになる。
【０１４２】
ランダム転送タイマが満了したら、ＦＮ９０はマルチキャストパケットを転送する。ブロック１８１０で、ランダム転送タイマが満了し、ＦＮ９０がランダム転送タイマの状態を「オン」から「オフ」に変更する。その後、ブロック６０５で、ＦＮ９０はマルチキャストパケットを転送する。ＦＮ９０はＴＴＬ値を１だけ減らす。マルチキャストパケット内のＴＴＬ値を１だけ減少させた後、ＦＮ９０マルチキャストパケットを転送する。さらに、マルチキャストパケットの転送の後、ブロック１８１２でＦＮは再送カウンタ（ｓ＿ｍｐ＿ｃ）を１に設定する。ブロック４４０で、ＦＮ９０はアイドルになる。第７の実施形態によれば、ＦＮ９０によるマルチキャストパケットの転送は軽く抑制される。
【０１４３】
図１９は、本発明の第８の実施形態に係るルーティング方法を示す。第８の実施形態によれば、マルチキャストパケットの転送は厳しく制限される。図１９に示される機能ブロックの多くは図１８と同じであり、したがって、詳しくは説明しない。第７と第８の実施形態の違いは、ブロック１９００における（ブロック８１５と対照的な）ＴＴＬ値の比較である。ブロック１９００で、入力マルチキャストパケットのＴＴＬ値がＭＰキャッシュテーブル（例えば、５００ｄ）に格納されたＴＴＬ値と比較される。
【０１４４】
入力マルチキャストパケットのＴＴＬ値にはオフセット値が加えられない。
【０１４５】
ＭＰキャッシュテーブル（例えば、５００ｄ）から取り出されたＴＴＬ値が入力ＴＴＬ値より大きくなければ、入力マルチキャストパケットは（ブロック４３０で）破棄され、ブロック４４０でＦＮ９０はアイドルになる。このマルチキャストパケットは上流ノードから発生したものである。ブロック１９００においてＭＰキャッシュテーブル５００ｄから取り出されたＴＴＬ値が入力ＴＴＬ値より大きければ、入力マルチキャストパケットは例えばピアや下流ノードから発生したものである。ＦＮ９０は、マルチキャストパケットの転送をやめて、マルチキャストパケットのランダム転送タイマを停止する。
【０１４６】
図２０は、本発明の第９の実施形態に係るルーティング方法を示す。本発明の第９の実施形態は２段階の抑制方法を用いる。図２０は、２つの機能ブロックが追加されている以外は、図１８と同様である。同一の機能ブロックについては繰り返しては説明しない。
【０１４７】
上述したように、ブロック８１５で、ＦＮ９０は、オフセットＴＴＬ値（ＩＮ＿ＭＰ＿ＴＴＬ＋１）を同一のマルチキャストパケットのＴＴＬ値と比較する。同一のマルチキャストパケットのＴＴＬ値はＭＰキャッシュテーブル（例えば、５００ｄ）から取り出される。ＭＰキャッシュテーブル５００ｄから取り出されたＴＴＬ値がオフセット値よりも大きくなければ、入力マルチキャストパケットは（ブロック４３０で）破棄され、ブロック４４０でＦＮ９０はアイドルになる。しかしながら、第９の実施形態では、ＭＰキャッシ
ュテーブル５００ｄから取り出されたＴＴＬ値がオフセット値よりも大きくなければ、ブロック２０００で、ＦＮはＭＰキャッシュテーブルから取り出されたＴＴＬ値がオフセット値と等しいか判断する。ＭＰキャッシュテーブル５００ｄから取り出されたＴＴＬ値がオフセット値と等しくなければ、入力マルチキャストパケットは破棄され、ブロック４４０でＦＮ９０はアイドルになる。しかしながら、ＭＰキャッシュテーブル５００ｄから取り出されたＴＴＬ値がオフセット値と等しい、すなわち、マルチキャストパケットが周囲のピアから受信されたものであれば、ブロック２００５で、マルチキャストパケットのランダム転送タイマが停止されて、別のランダム値に再設定される。マルチキャストパケットのランダム転送タイマ延長される。この時間延長により、同一のマルチキャストパケットのＴＴＬ値よりも小さいオフセットＴＴＬ値を有する入力マルチキャストパケットを、ランダム転送タイマが満了する前に受信する機会が増える。したがって、不必要な転送が抑制され、重複するパケットが生成することが少ない。
【０１４８】
図２１は、第７〜第９の実施形態に係るＦＮ９０のＭＰキャッシュテーブル５００ｄの例を示す。図示されるように、ＭＰキャッシュテーブル５００ｄは、２つの異なるマルチキャストパケット（ＭＰ1およびＭＰ2）を含む。各マルチキャストパケットに対して、ＭＰキャッシュテーブル５００ｂは、マルチキャストセッションＩＤ（Ｇｒｏｕｐ Ａｄｄ）、送信元識別子、マルチキャストパケットのシーケンス番号（ＳｅｑＮｕｍ）、マルチキャストパケットデータ（ＭＰキャッシュ）、再送カウンタ（ｓ＿ｍｐ＿ｃ）、マルチキャストパケットのＴＴＬ値（Ｃ＿ＭＰ＿ＴＴＬ）、およびランダム転送タイマ（Random_Forward_Timer）を含む。図２１に示されるように、マルチキャストパケットの一方についてオンである。
【０１４９】
本発明の第９の実施形態は、マルチキャストパケットと同様にブロードキャストパケットにも適用できる。しかしながら、ブロードキャスト通信を行うためには、すべてのノードがＦＮ９０になる。
【０１５０】
本発明はここまで特定の例示的な実施形態を参照して説明されている。本発明の範囲から逸脱することなくいくらかの代替や変更は当業者にとって明らかであろう。例示的な実施形態は説明を意図したものであり、添付の特許請求の範囲によって定義される本発明の範囲を限定するものではない。
【技術分野】
【０００１】
［関連出願の相互参照］
本発明は、共同所有され同時に係属中である、アドホック無線ネットワークにおけるユニキャストおよびマルチキャストメッセージをルーティングするための方法および通信装置と題する、２００６年１０月２３日出願の出願番号第１１／５８５，０４７の米国特許出願（「’０４７出願」）に関連する。
【０００２】
［技術分野］
この発明は、移動環境における通信ネットワークに関連する。より具体的には、本発明は、複数の移動装置間のマルチホップ・マルチキャストメッセージをルーティングするための方法に関連する。
【背景技術】
【０００３】
無線ホームネットワークや、無線オフィスネットワークや、ローカルカフェ、ファーストフードチェーン又はホテルにおけるいわゆる「ホットスポット」ネットワークや、さらには都市全体でのＷｉＦｉ技術の実現であれ、無線技術は今日の生活のあらゆる面において一般的なものとなっている。社会においてこのように無線を推し進める目的は、情報へのアクセスを提供し、社会全体がコンピュータネットワーク、特にインターネットを広く受け入れるとともに利用することで享受してきた生産性をさらに向上させるためである。
【０００４】
無線通信社会になるという願望は、移動車両のような移動装置にまで広がっている。この種の無線通信ネットワークは、限定はしないが、緊急路上障害物警告、交差点での協調、隠れた車道に関する警告、車線変更または合流の支援などを含む、車両安全アプリケーションの多くの態様において現れる。
【０００５】
車両安全通信（「ＶＳＣ」）は大きく分類して、車車間通信とインフラ協調車両通信とに分けることができる。車車間通信では、固定インフラストラクチャからの支援なしに車両同士がお互いに通信する。車両同士が同じ無線通信範囲内に位置する場合や、他の車両を介したマルチホップ通信が可能な場合に、車両同士がお互いに通信する。インフラ協調車両通信では、路側無線アクセスポイントなどのインフラストラクチャの支援を受けて、車両同士がお互いに通信する。この場合、車両はインフラストラクチャのみと通信することもできる。
【０００６】
衝突回避のような種々のＶＳＣアプリケーションを支援するために、重要なＶＳＣ性能要件には、遅延時間が短いこと（１００ミリ秒のオーダー）と、スループット（近くの車両が警告メッセージを受信に成功する確率と同等）を維持することが含まれる。
【０００７】
’０４７出願には、１台の移動車両をグループヘッダとして選択し、このグループヘッダを利用してローカル・ピア・グループを維持し、ローカルルーティング情報を生成することで、移動車両のグループをローカル・ピア・グループに組織化することが記述されている。移動車両はユニキャストおよびマルチキャストのルーティングに適合される。しかしながら依然として、スループットをさらに向上し遅延が少ないマルチキャストのルーティング方法に対する要求がある。
【発明の概要】
【０００８】
したがって、マルチキャストメッセージのルーティング方法が開示される。この方法は
、少なくともメッセージと送信元識別子とシーケンス番号とＴｉｍｅ−ｔｏ−Ｌｉｖｅ値とマルチキャストグループ宛先とを含むマルチキャストメッセージを受信するステップと、前記マルチキャストグループ宛先がマルチキャスト転送テーブル内に存在するか判断するステップと、前記メッセージが以前に受信したものであるか判断するステップと、前記メッセージが以前に受信したものではないと判断された場合に、前記マルチキャストメッセージを前記マルチキャスト転送テーブルに追加するステップと、前記マルチキャストメッセージを受信したノードが転送ノードであるか判断するステップと、前記マルチキャストメッセージを転送するための待機時間をランダムに設定するステップと、前記待機時間が満了したときに、前記マルチキャストメッセージを転送するステップと、を含む。
【０００９】
前記メッセージが以前に受信したものである場合に、少なくとも同一のメッセージと送信元識別子とシーケンス番号とマルチキャストグループ宛先とを含む第２のマルチキャストメッセージを前記ランダムに設定された待機時間内に下流ノードから受信したときは、前記待機時間を停止する。待機時間が停止された場合は、マルチキャストメッセージは転送されない。
【００１０】
第２のマルチキャストメッセージが下流ノードから受信されたかの判断は、第２のマルチキャストメッセージからＴｉｍｅ−ｔｏ−Ｌｉｖｅ値を抽出する工程と、前記Ｔｉｍｅ−ｔｏ−Ｌｉｖｅ値にプリセット値を加えてオフセットＴｉｍｅ−ｔｏ−Ｌｉｖｅ値を生成する工程と前記マルチキャスト転送テーブルから同一のメッセージを含むマルチキャストメッセージのＴｉｍｅ−ｔｏ−Ｌｉｖｅ値を取り出す工程と、前記オフセットＴｉｍｅ−ｔｏ−Ｌｉｖｅ値と前記取り出されたＴｉｍｅ−ｔｏ−Ｌｉｖｅ値とを比較する工程とを含み、前記取り出されたＴｉｍｅ−ｔｏ−Ｌｉｖｅ値が前記オフセットＴｉｍｅ−ｔｏ−Ｌｉｖｅ値よりも大きい場合に、前記待機時間が停止される。
【００１１】
前記取り出されたＴｉｍｅ−ｔｏ−Ｌｉｖｅ値が前記オフセットＴｉｍｅ−ｔｏ−Ｌｉｖｅ値と等しい場合は、前記待機時間はランダム値にリセットされる。
【００１２】
本方法は、転送後にＡＣＫフラグを未確認に設定するステップと、再送時間を所定時間に設定するステップと、をさらに含む。前記メッセージが以前に受信されたものである場合に、本方法は、少なくとも同一のメッセージと送信元識別子とシーケンス番号とマルチキャストグループ宛先とを含む第２のマルチキャストメッセージを下流ノードから受信したときは、前記再送時間を停止するステップをさらに含む。前記再送時間を停止した後に、ＡＣＫフラグを確認済みに設定される。
【００１３】
本方法は、前記再送時間が満了したときに、前記マルチキャストメッセージを再送するステップと、再送後に前記送信時間を所定時間に設定するステップと、をさらに含む。
【００１４】
本方法は、再送の上限に達したか判断するステップと、前記判断に基づいて、前記再送時間が満了したときに、前記マルチキャストメッセージを再送するステップと、再送カウンタを増加させるステップと、再送後に前記再送時間を所定時間に設定するステップと、をさらに含む。再送の上限に達した場合には、再送時間が停止される。
【００１５】
前記マルチキャスト転送テーブルは、前記グループ宛先と前記送信元識別子と前記シーケンス番号と前記メッセージと前記ＡＣＫフラグと前記再送時間値と前記再送カウンタと前記Ｔｉｍｅ−ｔｏ−Ｌｉｖｅ値とを含む。
【００１６】
マルチキャストメッセージをルーティングするための別の方法も開示される。本方法は、少なくともメッセージと送信元識別子とシーケンス番号とＴｉｍｅ−ｔｏ−Ｌｉｖｅ値とマルチキャストグループ宛先とを含むマルチキャストメッセージを受信するステップと
、前記マルチキャストグループ宛先がマルチキャスト転送テーブル内に存在するか判断するステップと、前記メッセージが以前に受信したものであるか判断するステップと、前記マルチキャストメッセージが以前に受信したものではないと判断された場合に、前記マルチキャストメッセージを前記マルチキャスト転送テーブルに追加するステップと、前記マルチキャストメッセージを受信したノードがマルチキャスト受信ノードであるか判断するステップと、マルチキャスト受信ノードに確率値をランダムに割り当てるステップと、前記ランダムに割り当てられた確率値とプリセット確率閾値とを比較するステップと、前記比較に基づいて前記マルチキャストメッセージを転送するステップと、を含む。
【００１７】
本方法は、前記プリセット確率閾値を設定するステップをさらに含む。
【００１８】
前記マルチキャスト転送テーブルは、前記グループ宛先と前記送信元識別子と前記シーケンス番号とを含む。
【００１９】
本方法は、転送後にＡＣＫフラグを未確認に設定するステップと、再送時間を所定時間に設定するステップと、をさらに含む。
【００２０】
本方法は、再送カウンタを増加させるステップをさらに含む。
【００２１】
前記メッセージが以前に受信されたものである場合に、本方法は、少なくとも同一のメッセージと送信元識別子とシーケンス番号とマルチキャストグループ宛先とを含む第２のマルチキャストメッセージを下流ノードから受信したときに、前記再送時間を停止する工程をさらに含む。
【００２２】
前記再送時間を停止した後に、ＡＣＫフラグを確認済みに設定される。
【００２３】
本方法は、再送カウンタの値に基づいて、再送の上限に達したか判断するステップと、前記判断に基づいて、前記再送時間が満了したときに、前記マルチキャストメッセージを再送するステップと、再送カウンタを増加させるステップと、再送後に前記再送時間を所定時間に設定するステップと、をさらに含む。再送の上限に達した場合には、再送時間が停止される。
【００２４】
マルチキャストメッセージをルーティングするための別の方法も開示される。本方法は、少なくともメッセージと送信元識別子とシーケンス番号とＴｉｍｅ−ｔｏ−Ｌｉｖｅ値とマルチキャストグループ宛先とを含むマルチキャストメッセージを受信するステップと、前記マルチキャストグループ宛先がマルチキャスト転送テーブル内に存在するか判断するステップと、前記メッセージが以前に受信したものであるか判断するステップと、を含み、前記メッセージが以前に受信されたものである場合に、前記Ｔｉｍｅ−ｔｏ−Ｌｉｖｅ値にプリセット値を加えてオフセットＴｉｍｅ−ｔｏ−Ｌｉｖｅ値を生成する工程と、前記オフセットＴｉｍｅ−ｔｏ−Ｌｉｖｅ値と前記マルチキャスト転送テーブル内のＴｉｍｅ−ｔｏ−Ｌｉｖｅ値を比較する工程と、前記オフセットＴｉｍｅ−ｔｏ−Ｌｉｖｅ値が前記マルチキャスト転送テーブル内のＴｉｍｅ−ｔｏ−Ｌｉｖｅ値以上である場合に、前記マルチキャストメッセージを破棄する工程と、を含む。
【００２５】
前記マルチキャストメッセージが以前に受信したものではない場合に、本方法は、ＡＣＫフラグを未確認に設定する工程と、再送カウンタを増加させる工程と、再送時間を所定値に設定する工程と、マルチキャストメッセージを転送する工程と、を含む。
【００２６】
前記オフセットＴｉｍｅ−ｔｏ−Ｌｉｖｅ値が前記マルチキャスト転送テーブル内のＴｉｍｅ−ｔｏ−Ｌｉｖｅ値よりも小さい場合に、本方法は、ＡＣＫフラグを確認済みに設
定する工程と、前記再送時間を停止する工程と、をさらに含む。
【００２７】
本発明のこれらおよび他の特徴、利益や利点は、以下の図面を参照することによって明らかになる。なお、図面を通して、類似の参照符号は類似の構造を指している。
【図面の簡単な説明】
【００２８】
【図１】図１は、マルチキャストメッセージ用に設定されたローカル・ピア・グループの例を説明する。
【図２】図２は、ハートビートメッセージの例を説明する。
【図３】図３は、メンバシップレポートメッセージの例を説明する。
【図４】図４は、本発明の第１の実施形態に係るマルチキャストパケットのルーティング方法を説明する。
【図５】図５は、本発明の第１の実施形態に係る、転送ノードおよびマルチキャスト受信ノードのためのＭＰキャッシュテーブルの例を説明する。
【図６】図６は、本発明の第２の実施形態に係るマルチキャストパケットのルーティング方法を説明する。
【図７】図７は、本発明の第２の実施形態に係るルーティング方法の例を説明する。
【図８】図８は、本発明の第３の実施形態に係るマルチキャストパケットのルーティング方法を説明する。
【図９】図９は、本発明の第３の実施形態に係るマルチキャストパケットのルーティング方法を説明する。
【図１０】図１０は、本発明の第３の実施形態に係るマルチキャストパケットのルーティング方法を説明する。
【図１１】図１１は、本発明の第３の実施形態に係る、転送ノードのためのＭＰキャッシュテーブルの例を説明する。
【図１２】図１２は、本発明の第４の実施形態に係るマルチキャストパケットのルーティング方法を説明する。
【図１３】図１３は、本発明の第４の実施形態に係るマルチキャストパケットのルーティング方法を説明する。
【図１４Ａ】図１４Ａは、本発明の第４の実施形態に係るマルチキャストパケットのルーティング方法を説明する。
【図１４Ｂ】図１４Ｂは、本発明の第４の実施形態に係るマルチキャストパケットのルーティング方法を説明する。
【図１５Ａ】図１５Ａは、本発明の第４の実施形態に係る、転送ノードのためのＭＰキャッシュテーブルの例を説明する。
【図１５Ｂ】図１５Ｂは、本発明の第４の実施形態に係る、マルチキャスト受信ノードのためのＭＰキャッシュテーブルの例を説明する。
【図１６】図１６は、本発明の第５の実施形態に係るマルチキャストパケットのルーティング方法を説明する。
【図１７】図１７は、本発明の第６の実施形態に係る、マルチキャスト受信ノードによるマルチキャストパケットのルーティング方法を説明する。
【図１８】図１８は、本発明の第７の実施形態に係るマルチキャストパケットのルーティング方法を説明する。
【図１９】図１９は、本発明の第８の実施形態に係るマルチキャストパケットのルーティング方法を説明する。
【図２０】図２０は、本発明の第９の実施形態に係るマルチキャストパケットのルーティング方法を説明する。
【図２１】図２１は、本発明の第７〜第９の実施形態の係る、転送ノードのためのＭＰキャッシュテーブルの例を説明する。
【発明を実施するための形態】
【００２９】
［定義］
「ノード」は、チャネルの決定・選択処理や以下の説明で記載される方法を実行するルータである。例えば、通信装置を備える移動車両はノードである。この出願では、ノードと移動車両は同じ意味で使われている。
【００３０】
「マルチキャストメッセージ」は１つまたはそれ以上の宛先を持つメッセージである。詳細な説明では、マルチキャストメッセージはマルチキャストパケット（ＭＰ）と称される。「ホップ」はメッセージを中継するノードである。２ノード間、すなわち送信元と宛先の間の「ホップカウント」は、中継ノードの数に１を足したものに等しい。
【００３１】
本発明によれば、ローカル・ピア・グループ（ＬＰＧ）に組織化されたノードまたは移動車両は、マルチキャストルーティングテーブルを生成するために相対位置、一意の識別子、ＬＰＧに関する情報を交換する。後述するハートビートメッセージやメンバシップレポートメッセージのような制御パケット内の情報に基づいて、ルーティングテーブルが生成される。マルチキャストは、１つのマルチキャストセッションについて複数の送信元ノード７００とマルチキャスト受信ノード２０に対応する。
【００３２】
ＬＰＧ１は、近くの複数のノード１０から動的に形成される。具体的には、第１のノードが無線信号をブロードキャストし、第１のノードの範囲内の他のノード１０は、この無線信号を受信する能力がある。ＬＰＧ１は無線通信範囲に基づいて形成されるので、ＬＰＧ１内のノードは、固定インフラストラクチャを必要とせずに、１ホップまたはマルチホップで互いに通信できる。ハートビートメッセージおよびメンバシップレポートの送信に基づいて、ＬＰＧ１は形成および維持される。
【００３３】
図１は、マルチキャストメッセージ用に設定されたモードを持つＬＰＧ１を示す。マルチキャストを行うために、ノード１０は、マルチキャスト受信ノードと転送ノード９０の２つのグループに分けられる。マルチキャスト受信ノード２０はマルチキャストメッセージの受信が意図されるノードである。転送ノード９０はメッセージを転送する。ＬＰＧ１内の全てのノード１０は、転送ノードにもマルチキャスト受信ノード２０にもなりうる。さらに、ＬＰＧ１内の１つのノードがグループヘッダ（ＧＨ）として選択される。ＧＨは、他のノードやインフラストラクチャからの命令なしにＬＰＧ１を維持および制御することを指定されたＬＰＧ１内の移動装置またはノード１０である。ノード１０は、メンバシップレポートをＧＨへ中継するために用いられるときに、ＦＮ９０になる。ＬＰＧ１の形成、維持、ＧＨの選択、制御は’０４７出願に記載されており、その内容は参照により本明細書に含まれる。
【００３４】
図２は、本発明に係るハートビートメッセージ２００の例を示す。ＧＨは、ハートビートメッセージ２００を定期的に送出して、ＬＰＧ１を識別（identify）するとともにＬＰＧ１に関する情報を提供する。この周期は固定間隔（Ｔ）である。この間隔（Ｔ）の値は、設計や運用の要求に基づいて選択可能である。ＧＨは、ＬＰＧ１に含まれる全ノードのリストの維持も行う。このリストには、ノードがＬＰＧ１に参加した時のタイムスタンプ、あるいは、ＧＨがノードからステータス更新を受信した時のタイムスタンプが含まれる。このリストは、ＬＰＧ１に対する種々の維持・管理機能のために用いられる。例えば、このリストは、グループサイズを追跡したり、マルチキャストルーティングテーブルを作成・更新したり、ヘッダ解決のために用いることができる。さらに、このリストは、ＬＰＧ１内の他の全てのノードに周期的にブロードキャストされる。ハートビートメッセージ２００がＬＰＧ１内の全ノード１０にブロードキャストされる。
【００３５】
ハートビートメッセージ２００は、ＬＰＧ１の識別子、ＧＨ ＩＤ、シーケンス番号、
ハートビートメッセージの種類（例えば、完全なグループリスト付きのハートビートか、増分（incremental）グループリスト付きのハートビートか、グループリストなしのハートビートか）を含む。ある実施形態では、ハートビートメッセージは全てのパケットにおいて完全なグループリストを含む。完全なグループリストを使うことが、ルーティング制御と正しいグループメンバのリストを維持するための最も正確な方法であるが、完全なグループ付きのハートビートのためには相当量の帯域幅が必要となる。別の実施形態では、ハートビートメッセージ２００は、ｎ回おきに完全なグループリストを含む。例えば、３回おきにハートビートが完全なグループリストを含むようにする。ＴｏＨｂは、ハートビートメッセージの種類を意味する。ハートビートメッセージの種類は、ＬＰＧ１のトポロジー変化の早さとハートビートのブロードキャスト頻度の影響を受ける。ＬＰＧ１のトポロジー変化速度が速くなると、全てのハートビートメッセージ２００に完全なグループリストを含める必要性が高まる。
【００３６】
ハートビートメッセージ２００は、ＧＨからのホップカウント（ＨＣ）も含む。最初は、ＨＣは所定値、たとえば１に設定される。ハートビートメッセージ２００がノードによって中継されるたびに、中継ノードがＨＣ値を１増加させる。すなわち、ＨＣ＝ＨＣ＋１とする。ＨＣ値は、ＬＰＧのサイズを限定したり、ハートビートメッセージ２００内の情報の古さを示したり、オーバヘッドを減らすための制御パケットのルーティングを制御したりするために用いることができる。各ＬＰＧ１に対して、ルーティングの最大ホップカウント（例えば１０）がある。ＨＣが最大ホップカウントに達すると、その制御パケットはそれ以上中継されない。
【００３７】
最大ホップカウント、ＨＣおよびシーケンス番号を用いることで、ＬＰＧ１内で制御パケットが無限に複製されることを防止できる。ホップカウントは中継戦略のためにも利用される。ノードがハートビートメッセージを転送するときにメッセージにＩＤ情報を含めるので、次ホップのノードは、このハートビートメッセージ２００を誰が中継するのかを知ることができる。
【００３８】
上述したように、ハートビートメッセージ２００はグループリストも含むことができる。グループリストは、ＬＰＧ１のメンバに関する情報を含むことができる。たとえば、ＬＰＧ１内のメンバ数、各メンバのＩＰアドレス、ＧＨからのホップカウントや分類などである。
【００３９】
分類は、たとえばアップリンク、ダウンリンク、ピアのような、ＧＨからの相対的な方向を示すコードであり得る。ピア分類は、ノードがＧＨと同じ無線通信範囲内であることを示す。すなわち、全てのピアノードは、ＧＨから同じホップカウントを有する。上流ノードはハートビートから決定される。下流ノードは、後述するメンバシップレポート（ＭＲ）３００に基づいて決定される。上流送信はＧＨ２５に向かう方向の通信を意味し、下流送信はＧＨ２５からの離れる方向の通信を意味する。分類は相対的な用語である。各ノードはその近隣ノードを異なる３つの種類に分けることができる。他のノードのメンバシップレポートのホップカウント（ＨＣ）が自ノードのＨＣよりも１少なければ、自ノードは上流ノードである。そのＨＣが自身のＨＣと同じであれば、自ノードはピアである。そのＨＣが自身のＨＣよりも１大きければ、自ノードは下流ノードである。
【００４０】
図３はメンバシップレポート（ＭＲ）３００の例を示す。ＭＲ３００はＧＨ以外のノードからブロードキャストされる制御パケットであり、その受取人はＧＨ２５である。ＭＲ３００は、ハートビートメッセージ２００に対する応答として生成される。ＭＲ３００は、メンバシップリスト、下流ノードＩＤ、下流ノードに対する次ホップのような収集可能なルーティング情報を含む。ＭＲ３００は、ＧＩＤやグループヘッダＩＤのような、ハートビートメッセージ２００と同じ情報のいくつかを含む。ＭＲ３００は、ＭＲシーケンス
番号も含む。ＭＲシーケンス番号は、ハートビートメッセージ２００のシーケンス番号と同様のものであり、ＭＲの順序を維持するために用いられる。ＭＲシーケンス番号はある特定のノードに対するＭＲの順序である。典型的には、ＭＲシーケンス番号は、ＭＲ３００のきっかけとなったハートビートメッセージ２００のシーケンス番号と同じ値を有する。
【００４１】
ＭＲ３００には、発信元ノード、すなわち、ＭＲ３００を生成したノードのノードＩＤも含まれる
【００４２】
ＭＲ３００は次ホップ中継ＩＤも含む。次ホップ中継ＩＤは、ＧＨへ向かうＭＲ３００に対する中継の指示である。次ホップの情報は、受信したハートビートメッセージ２００から直接決定される。ノード１０が新しいすなわち新規のハートビートメッセージ２００を受信すると、何らかのパケット処理を行う前にＩＰ層およびＭＡＣ層から直前の中継ノードのＩＤを取り戻す。直前の中継ノードのＩＤはメモリに格納され、ＭＲ３００の次ホップ中継ＩＤとして用いられる。ノード１０がハートビートメッセージ２００を転送するときは、ノード１０は自身のＩＤをパケットに含める。これを受信する次ホップノードは、新しいすなわち新規のハードビートメッセージ２００を受信すると、このＩＤをＧＨ２５に達するための次ホップ中継ＩＤとして格納する。新しいすなわち最新のハートビートメッセージ２００は、最も小さいＨＣと新しいシーケンス番号を有する。
【００４３】
ＭＲ３００は「ＭＲ標識の種類」ＴｏＭＲも含む。ＭＲ３００には、単一メンバレポートおよび複数集約メンバレポート（aggregated multiple member report）の２つの種類がある。単一メンバＭＲは発信元ノードからのＭＲ３００のみを含む。複数集約メンバレポートは２つ以上のノードのＭＲ３００を含む。１つのＭＲ３００が複数のＭＲを含んで送られる。
【００４４】
さらに、ＭＲ３００はＧＨからのホップカウント（ＨＣＧＨ）を含んでも良い。（ＨＣＧＨ）は、ＧＨから発信ノードまでのＭＲ３００のＨＣ値である。ＭＲ３００は、報告ノードが利用可能なチャネルのリストを含む。さらに、ＭＲは、ＭＲ３００をＧＨに向かって中継した全ノードについての利用可能なチャネルのリストを含んでも良い。さらに、ＭＲ３００は、その状態またはマルチキャストメッセージを中継可能であるか、すなわち転送ノードステータスを含む。
【００４５】
マルチキャストルーティングテーブルは、マルチキャストセッションが開始された後に、ハートビートメッセージ２００およびＭＲ３００から作成される。マルチキャストルーティングテーブルは木構造またはメッシュとして視覚化するのが最も適切といえる。木構造またはメッシュは、任意の送信元ノード７００からＦＮを介してマルチキャスト受信ノード２０に至る経路またはリンクを提供する。マルチキャストセッションを確立するために、マルチキャストセッションに参加したいノード１０はマルチキャストセッションに対応したマルチキャストアプリケーションプログラムを起動する。このアプリケーションプログラムはメモリに格納される。そして、ノードはＦＮかマルチキャスト受信ノードになり、セッション参加の要求を示す信号（ＭＲ３００）を発する。これらの信号によって、マルチキャストセッションに対するマルチキャストツリーの生成が開始される。
【００４６】
ノードがＭＲ３００をＧＨに向かって中継すると、そのノードはマルチキャストグループのＦＮ９０になる。ＦＮ９０は、ここで説明される１つまたはそれ以上の方法によって、マルチキャストセッションに関連づけられたマルチキャストパケットを受け付けて転送することができる。木構造またはメッシュ、すなわちマルチキャストルーティングテーブルは、ここに参照によって明示的に組み入れられる’０４７出願において説明されるいずれかの方法を用いて作成される。マルチキャストルーティングテーブルは、ハートビート
期間ごとに更新される。マルチキャストパケットはマルチキャストルーティングテーブルを用いて経路が定められる。
【００４７】
図４は、本発明の第１の実施形態に係るマルチキャストルーティング方法を示す。本ルーティング方法を、その機能ブロックを用いて説明する。異なる実施形態における同一の機能ブロックは、同一の番号を用いて参照される。
【００４８】
ブロック４００で、マルチキャストパケットがノードに到着する。ブロック４０５で、ノード１０はパケットからマルチキャストグループ識別子を抽出して、ノード１０がマルチキャストセッションのメンバであるか判断する。この判断はマルチキャストルーティングテーブルに基づく。ノード１０は、ＦＮ９０かマルチキャスト受信ノード２０のいずれかであれば、マルチキャストセッションのメンバである。ノード１０がマルチキャストセッションのメンバでなければ、ブロック４１０で、それ以上の処理をせずにマルチキャストパケットは破棄される。ノード１０がマルチキャストセッションのメンバであれば、ブロック４１５で、ノード１０は、ＭＰキャッシュテーブル（例えば図５、５００）内に、受信したマルチキャストパケットと一致するものがあるか探す。本発明の第１の実施形態では、ＭＰキャッシュテーブル５００はＦＮ９０とマルチキャスト受信ノード２０の両方に対して同一である。ＭＰキャッシュテーブル５００は、グループ識別子、送信元識別子、つまりマルチキャストパケットの元々の送信元ノード７００、およびシーケンス番号を含む。パケットのシーケンス番号と送信元識別子の両方が同じであれば、マルチキャストパケットは受信パケットと同一である。マルチキャストパケットが同一であれば、ブロック４１０で、それ以上の処理をせずにマルチキャストパケットは破棄される。
【００４９】
マルチキャストパケットがＭＰキャッシュテーブル５００内のいずれのパケットとも一致しない場合は、ブロック４２０で、ノード１０は、グループ識別子、送信元識別子、マルチキャストパケットの順番のようなマルチキャストに関連する情報をＭＰキャッシュテーブル５００に追加する。マルチキャストパケットがＭＰキャッシュテーブル５００に加えられると、ブロック４２５で、ノード１０はマルチキャストセッションのＦＮ９０であるか判断する。この判断はマルチキャストルーティングテーブルに基づく。ノード１０がマルチキャストセッションのＦＮ９０でなければ、ブロック４３０で、マルチキャストパケットは破棄される。その後、ブロック４４０でノード１０はアイドルになる。
【００５０】
ノード１０がマルチキャストセッションのＦＮ９０であれば、ブロック４３５で、ノードはマルチキャストパケットをＮ回再マルチキャストすなわち転送する。ある実施形態では、ＦＮ９０はマルチキャストパケットをＮ回連続して転送する。パケットが転送される数字「Ｎ」回は予め定められていて変更可能である。到達率の増加とデータオーバヘッドの増加にはトレードオフがある。数字「Ｎ」が増えるにしたがって、データオーバヘッドが著しく増加するが、到達率もまた増加する。別の実施形態では、ＦＮ９０はパケットをＮ回同時に転送する。
【００５１】
マルチキャストパケットを転送した後、ブロック４４０で、ＦＮ９０はアイドルになる。
【００５２】
図５は、本発明の第１の実施形態におけるＭＰキャッシュテーブル５００の例を示す。図５に示すように、ＭＰキャッシュテーブル５００は、ＩＰアドレスのようなセッションやグループの識別子である追加グループ（ＧｒｏｕｐＡｄｄ）、マルチキャストパケットの送信元ノード７００の識別子である送信元識別子、およびパケットのシーケンス番号（ＳｅｑＮｕｍ）を含む。
【００５３】
図６は、本発明の第２の実施形態に係るマルチキャストルーティング方法を示す。ブロ
ック４００で、マルチキャストパケットがノード１０に到着する。ブロック４０５で、ノード１０はパケットからマルチキャストグループ識別子を抽出して、ノード１０がマルチキャストセッションのメンバであるか判断する。この判断はマルチキャストルーティングテーブルに基づく。ノード１０は、ＦＮ９０かマルチキャスト受信ノード２０のいずれかであれば、マルチキャストセッションのメンバである。ノード１０がマルチキャストセッションのメンバでなければ、ブロック４１０で、それ以上の処理をせずにマルチキャストパケットは破棄される。ノード１０がマルチキャストセッションのメンバであれば、ブロック４１５で、ノード１０は、ＭＰキャッシュテーブル内に、受信したマルチキャストパケットと一致するものがあるか探す。本発明の第２の実施形態では、ＭＰキャッシュテーブル５００はＦＮ９０と受信ノードの両方に対して同一である。ＭＰキャッシュテーブル５００は、グループ識別子、送信元識別子、およびシーケンス番号を含む。パケットのシーケンス番号と送信元識別子の両方が同じであれば、マルチキャストパケットは受信パケットと同一である。マルチキャストパケットが同一であれば、ブロック４１０で、それ以上の処理をせずにマルチキャストパケットは破棄される。
【００５４】
マルチキャストパケットがＭＰキャッシュテーブル５００内のいずれのパケットとも一致しない場合は、ノード１０は、ブロック４２０で、受信したマルチキャストパケットについての情報をＭＰキャッシュテーブル５００に追加する。マルチキャストパケットに関連する情報がＭＰキャッシュテーブル５００に加えられると、ブロック４２５で、ノード１０はマルチキャストセッションのＦＮ９０であるか判断する。この判断はマルチキャストルーティングテーブルに基づく。ノード１０がＦＮ９０であれば、ブロック６０５で、ノード１０はマルチキャストパケットを一度転送する。ブロック４４０で、ノード１０はアイドルになる。
【００５５】
ノード１０がＦＮ９０でなければ、ノード１０はマルチキャスト受信ノード２０である。本実施形態によれば、ＦＮ９０による通常の転送に加えて、いくつかのマルチキャスト受信ノード２０がマルチキャストパケットの転送のために選択される。この追加的な転送によって、マルチキャストセッションのメンバがパケットを受信し損ねる可能性が抑えられる。受け取ったマルチキャストデータパケットごとに割り当てられる確率に基づいて、いくつかのマルチキャスト受信ノード２０が選択される。各マルチキャスト受信ノード２０は確率閾値とともにプログラムされる。確率閾値は０と１の間の値である。確率閾値は、複数のマルチキャスト受信ノード２０について同じではない。ある実施形態では、確率閾値はランダムにプログラムされる。別の実施形態では、確率閾値は、ＬＰＧ１内のノード１０の数またはマルチキャストセッション内のノード数に基づいて割り当てられる。言い換えると、確率閾値は周期的に変化しても良い。ある実施形態では、マルチキャストセッションの送信元ノード７００が確率閾値を割り当てても良い。代替として、ＧＨが確率閾値を割り当てても良い。
【００５６】
ブロック６００で、マルチキャスト受信ノード２０であるノード１０は、マルチキャストパケットに割り当てられたランダムな確率と、確率閾値とを比較する。マルチキャストパケットに割り当てられたランダムな確率が確率閾値よりも小さければ、ブロック６０５で、マルチキャスト受信ノードは受信したマルチキャストパケットを転送する。そして、ブロック４４０で、マルチキャスト受信ノード２０はアイドルになる。
【００５７】
マルチキャストパケットに割り当てられたランダムな確率が確率閾値以上であれば、ブロック４３０で、マルチキャスト受信ノード２０は受信したマルチキャストパケットを破棄する。そして、ブロック４４０で、マルチキャスト受信ノード２０はアイドルになる。
【００５８】
図７は、本発明の第２の実施形態に係る方法を実行するマルチキャストセッションの例を示す。送信元ノード７００がマルチキャストセッションを開始し、マルチキャストパケ
ットをマルチキャストする。ＦＮ1 ９０1、ＦＮ2 ９０2、およびＦＮ3 ９０3は、マルチキャストパケットを受信した後に、ブロック６０５で、マルチキャストパケットを転送する。マルチキャスト受信ノード２０1、２０2、２０3はマルチキャストデータパケットを転送せずにマルチキャストパケットを破棄する（ブロック４３０）。しかしながら、マルチキャスト受信ノード２０4、２０5、２０6は、マルチキャストパケットを転送する（ブロック６０５）。ＭＰキャッシュテーブルは本発明の第１の実施形態と同様である（例えば、５００）。ＭＰキャッシュテーブル５００は、ＦＮ９０とマルチキャスト受信ノード２０の両方に対して同一である。
【００５９】
図８〜図１０は、本発明の第３の実施形態に係るルーティング方法を示す。本発明の第３の実施形態によれば、次ホップノードは転送されたマルチキャストパケットの受信通知を行う。この受信通知（acknowledgement）はパッシブ受信通知方式をとる。ＦＮ９０によって転送されたマルチキャストパケットは、その次ホップＦＮによって転送されたマルチキャストパケットによって受信通知が行われる。次ホップＦＮから転送されたマルチキャストパケットは、傍受（overheard）される。
【００６０】
ブロック４００で、マルチキャストパケットがノード１０に到着する。マルチキャストパケットは、マルチキャストグループＩＤ、シーケンス番号、Ｔｉｍｅ−ｔｏ−Ｌｉｖｅ（ＴＴＬ）値、およびデータを含む。ＴＴＬ値は、マルチキャストパケットが中継されるホップ数である。各ホップで、ＦＮ９０はＴＴＬ値を減少させる。ＴＴＬ値は、同一のマルチキャストデータパケットが転送させる回数を制限する機能を果たす。
【００６１】
ブロック４０５で、ノード１０はパケットからマルチキャストグループ識別子を抽出して、ノード１０がマルチキャストセッションのメンバであるか判断する。この判断はマルチキャストルーティングテーブルに基づく。ノード１０がマルチキャストセッションのメンバでなければ、ブロック４１０で、それ以上の処理をせずにマルチキャストパケットは破棄される。ノード１０がマルチキャストセッションのメンバであれば、ブロック８００で、ノード１０はＦＮ９０かマルチキャスト受信ノードであるかを判断する。ノード１０がマルチキャスト受信ノードであれば、処理は図１０のブロック４１５に移動する。ノード１０がマルチキャストセッションのＦＮ９０であれば、ブロック４１５（図８）で、ＦＮ９０はマルチキャストパケットがＭＰキャッシュテーブル（例えば、図１１、５００ａ）内にあるか判断する。
【００６２】
マルチキャストパケットがＭＰキャッシュテーブル５００ａ内のいずれのパケットとも一致しない場合は、ブロック４２０で、ＦＮ９０は受信したマルチキャストパケットをＭＰキャッシュテーブル５００ａに追加する。この実施形態では、マルチキャストパケットに関連する情報とパケットの両方がＭＰキャッシュテーブル５００ａに追加される。
【００６３】
ＦＮ９０は、マルチキャストグループＩＤ、シーケンス番号、送信元識別子、Ｔｉｍｅ−ｔｏ−Ｌｉｖｅ（ＴＴＬ）値、およびデータを抽出し、この情報をＭＰキャッシュテーブル５００ａに付加する。さらに、ＦＮ９０は再送カウンタをゼロに初期化する。再送カウンタ（ｓ＿ｍｐ＿ｃ）は、マルチキャストパケットが再送されうる回数を表す。ある実施形態では、マルチキャストメッセージが再送される回数はあらかじめ定められた最大値に制限される。あらかじめ定められた最大値は全ノード１０に対して同じであっても良い。別の実施形態では、あらかじめ定められた最大値はＧＨや送信元ノード７００のような特定のノードに対して変更可能としても良い。
【００６４】
ＭＰキャッシュテーブルはＦＮ９０とマルチキャスト受信ノードとで異なる。ＦＮ９０用には、ＭＰキャッシュテーブル５００は、マルチキャストパケットについてのマルチキャストセッションＩＤ、送信元識別子、シーケンス番号、マルチキャストパケットデータ
、ＡＣＫ状態、再送タイマ値、再送カウンタ、およびＴＴＬ値を含む。ＡＣＫ状態は「未確認」または「確認済み」のいずれかであり得る。再送タイマ値はオンかオフのいずれかであり得る。タイマがオンであれば、再送タイマ値は初期設定タイマ値といつ再送タイマ値が満了したかの指示も含む。マルチキャスト受信ノード２０用には、ＭＰキャッシュテーブル５００は、マルチキャストセッションＩＤ、送信元識別子、およびシーケンス番号だけを含む。
【００６５】
ブロック８０５で、ＦＮ９０はＡＣＫ状態を「未確認」に初期化する。ＦＮ９０はどのマルチキャストパケットが受信確認され受信されたかを追跡できる。さらに、ＦＮ９０は再送タイマ値をオンに初期化し、タイマを再送時間に設定する。再送時間は、データパケットに含まれるデータの種類、ＦＮ９０の移動速度、およびその他のユーザ定義の基準に応じて変更可能である。例えば、１２ｍｓの再送時間を利用することができる。メッセージに含まれるデータが高い優先度のメッセージであれば、再送時間を短くしても良い。あるいは、メッセージが低い優先度のメッセージであれば、再送時間を長くしても良い。回復遅延は再送時間の値に依存する。再送時間が小さいほど、遅延は短くなる。しかしながら、小さくしすぎると多くの再送信が発生し、不必要な再送信が生じる。
【００６６】
ブロック８１０で、再送カウンタが１増分する。すなわちｓ＿ｍｐ＿ｃ＋１にする。再送カウンタが増分された後、ブロック６０５で、ＦＮ９０はマルチキャストパケットを一度転送する。ＦＮ９０は、転送の前にマルチキャストパケットのＴＴＬ値から１減算する。したがって、次ホップＦＮによって受信されるマルチキャストパケットは、最小のＴＴＬ値を持つ。ブロック４４０で、ＦＮ９０はアイドルになる。
【００６７】
マルチキャストパケットがＭＰキャッシュテーブル５００ａ内のいずれかのパケットと同一であれば、本方法はブロック８１５へ進む。
【００６８】
ＦＮ９０は入力マルチキャストパケットのＴＴＬ値を判断する。上記したようにＴＴＬ値は特定のマルチキャストパケットのホップ数を制御するために用いられる。さらにこの実施形態では、ＴＴＬ値は送信ノード１０および受信ノード１０の相対的な位置を決定するためにも用いられる。具体的には、マルチキャストパケットが転送されるたびに、ノード１０はＴＴＬ値から１減算する（すなわち、ＴＴＬ−１）。特定のＦＮ９０から下流にあるノード１０から受信されたマルチキャストパケットのＴＴＬ値は、ＦＮ９０から転送された同一のマルチキャストパケットのＴＴＬ値よりも小さい。特定のＦＮ９０から上流にあるノード１０から受信されたマルチキャストパケットのＴＴＬ値は、ＦＮ９０から転送された同一のマルチキャストパケットのＴＴＬ値よりも大きい。特定のＦＮ９０と同じホップ数のノード１０から受信されたマルチキャストパケットは、同一のＴＴＬ値を持つ。
【００６９】
ＦＮ９０は、ＦＮ９０による最初のマルチキャストパケットの転送を補うために、判定されたＴＴＬ値にオフセット値の１を加える。これによりオフセットＴＴＬ値が生成される。
【００７０】
ブロック８１５で、ＦＮ９０は、入力パケットのオフセットＴＴＬ値（Ｉｎ＿ＭＰ＿ＴＴＬ＋１）と同一のマルチキャストパケットのＴＴＬ値とを比較する。同一のマルチキャストパケットのＴＴＬ値は、ＭＰキャッシュテーブル５００ａから取り出される。ＭＰキャッシュテーブル５００ａから取り出されたＴＴＬ値がオフセット値よりも大きくない場合は、ブロック４３０で、入力マルチキャストパケットは無視されて破棄される。このマルチキャストパケットは上流ノードから発生したものである。マルチキャストパケットの転送は受信確認されない。ブロック４４０で、ＦＮ９０はアイドルになる。
【００７１】
ブロック８１５においてＭＰキャッシュテーブルから取り出されたＴＴＬ値がオフセット値よりも大きい場合は、ブロック８２０で、ＦＮ９０はこのマルチキャストパケットがすでに受信確認されたか判断する。
【００７２】
ＦＮ９０はＭＰキャッシュテーブル５００ａから同一のマルチキャストパケットについてのＡＣＫ状態を取り出す。同一のマルチキャストパケットがすでに受信確認されていれば、ブロック４３０で、入力マルチキャストパケットは無視されて破棄される。ブロック４４０で、ＦＮ９０はアイドルになる。ＭＰキャッシュテーブル５００ａに変更はない。ブロック８２０において同一のマルチキャストパケットが受信確認されていなければ、本方法はブロック８２５へ進む。
【００７３】
ブロック８２５で、ＦＮ９０は再送タイマを停止する。さらに、ＦＮ９０は、キャッシュテーブル５００ａ内の再送タイマ値を「オフ」に変え、ＡＣＫ状態を「確認済み」に変える。その後、ブロック４３０で入力マルチキャストパケットは破棄される。ブロック４４０で、ＦＮ９０はアイドルになる。マルチキャストパケット転送の受信が確認される。
【００７４】
図９は、マルチキャストパケットの転送が受信確認される前に再送タイマが満了する場合の機能ブロック図を示す。図９に示される機能ブロック図はＦＮ９０によってのみ実行される。
【００７５】
ブロック９００で、再送タイマが満了する。ＦＮ９０は、再送カウンタが最大閾値に達したか判断する。ＦＮは、再送タイマが満了したパケットに対応するマルチキャストパケットの再送カウンタをＭＰキャッシュテーブル５００ａから抽出する。再送カウンタは、最大閾値と比較される。再送カウンタが最大閾値以上であれば、ＦＮ９０はブロック４４０でアイドルになる。
【００７６】
再送カウンタが最大閾値より小さければ、ブロック８０５で、ＦＮ９０はマルチキャストパケットの送信タイマをリセットし、マルチキャストパケットのＡＣＫ状態を「未確認」に初期化する（図９において「Not ACKed」と示される）。
【００７７】
ブロック８１０で、再送カウンタが１増分する。すなわちｓ＿ｍｐ＿ｃ＋１にする。再送カウンタが増分された後、ブロック６０５で、ＦＮ９０はマルチキャストパケットを一度転送する。ＦＮ９０は、転送の前にマルチキャストパケットのＴＴＬ値から１減算する。したがって、次ホップＦＮはマルチキャストパケットを送っているＦＮ９０よりも小さいＴＴＬを持つマルチキャストパケットを受信する。ブロック４４０で、ＦＮ９０はアイドルになる。
【００７８】
図１０は、本発明の第３の実施形態に係るマルチキャスト受信ノード２０の機能ブロックを示す。図８に示すように、ブロック８００においてノード１０がＦＮ９０でなければ、処理は図１０のブロック４１５に進む。ブロック４１５で、マルチキャスト受信ノード２０は、入力マルチキャストパケットがＭＰキャッシュテーブル５００にリストされているか判断する。マルチキャストパケットがすでにリストされていれば、ブロック４３０で、パケットは無視されて破棄される。ブロック４４０で、マルチキャスト受信ノード２０はアイドルになる。
【００７９】
マルチキャストパケットがＭＰキャッシュテーブル５００内のいずれのパケットとも一致しない場合は、マルチキャスト受信ノード２０は、ブロック４２０で、入力マルチキャストパケットについての情報をＭＰキャッシュテーブル５００に追加する。具体的には、マルチキャスト受信ノード２０は、マルチキャストパケットのマルチキャストセッションＩＤ、送信元識別子、およびシーケンス番号をＭＰキャッシュテーブル５００に追加する
。その後、ブロック４３０で、マルチキャストパケットは破棄される。ブロック４４０で、マルチキャスト受信ノード２０はアイドルになる。
【００８０】
図１１は、本発明の第３の実施形態に係るＦＮ用のＭＰキャッシュテーブル５００ａの例を示す。図示されるように、ＭＰキャッシュテーブル５００ａは、２つの異なるマルチキャストパケット（ＭＰ1とＭＰ2）を含む。各マルチキャストパケットに対して、ＭＰキャッシュテーブル５００ａは、マルチキャストセッションＩＤ（ＧｒｏｕｐＡｄｄ）、マルチキャストパケットの送信元識別子、マルチキャストパケットのシーケンス番号（ＳｅｑＮｕｍ）、マルチキャストパケットデータ（ＭＰキャッシュ）、受信確認状態（ＡＣＫ状態）、再送タイマ（Ｒｅｔｒａｎ＿Ｔｉｍｅｒ）、再送カウンタ（ｓ＿ｍｐ＿ｃ）、およびマルチキャストパケットのＴＴＬ値（Ｃ＿ＭＰ＿ＴＴＬ）を含む。図１１に示されるように、マルチキャストパケットの１つは受信確認されており、したがって再送タイマ状態は「オフ」である。
【００８１】
図１２〜図１４（ＡおよびＢ）は、本発明の第４の実施形態に係るルーティング方法を示す。この実施形態によれば、マルチキャスト受信ノード２０は受信し損ねたマルチキャストパケットを局所的に回復することができる。マルチキャスト受信ノード２０は否定的確認（negative acknowledgement）を用いて、他のノード１０にマルチキャストパケットを受信していないことを通知する。受信し損ねたマルチキャストパケットは、受信パケットにおける欠落しているシーケンス番号に基づいて検出される。この検出は受信したマルチキャストパケットの間でのシーケンス番号の比較に基づく。
【００８２】
ブロック４００で、マルチキャストパケットがノード１０に到着する。マルチキャストパケットはマルチキャストグループＩＤ、送信元識別子、シーケンス番号、Ｔｉｍｅ−ｔｏ−Ｌｉｖｅ（ＴＴＬ）値、およびデータを含む。ＴＴＬ値は、マルチキャストパケットが中継されるホップ数である。各ホップで、ＦＮ９０はＴＴＬ値を減少させる。ＴＴＬ値は、同一のマルチキャストデータパケットが転送させる回数を制限する機能を果たす。
【００８３】
ブロック４０５で、ノード１０はパケットからマルチキャストグループ識別子を抽出して、ノード１０がマルチキャストセッションのメンバであるか判断する。この判断はマルチキャストルーティングテーブルに基づく。ノード１０がマルチキャストセッションのメンバでなければ、ブロック４１０で、それ以上の処理をせずにマルチキャストパケットは破棄される。ノード１０がマルチキャストセッションのメンバであれば、ブロック８００で、ノード１０はＦＮ９０かマルチキャスト受信ノードであるかを判断する。ノード１０がマルチキャスト受信ノード２０であれば、処理は図１３のブロック４１５に移動する。
【００８４】
ブロック４１５で、マルチキャスト受信ノード２０は、ＭＰキャッシュテーブル（例えば、図１５Ｂ、５００ｃ）内に入力マルチキャストパケットがリストされているか判断する。
【００８５】
マルチキャストパケットがＭＰキャッシュテーブル５００ｃ内のいずれのパケットとも一致しない場合は、マルチキャスト受信ノード２０は、受信したマルチキャストパケットについての情報をＭＰキャッシュテーブル５００ｃに追加し、ブロック１３００でマルチキャストパケットが不足していないか判断する。マルチキャスト受信ノード２０は、マルチキャストセッションＩＤ、送信元識別子、シーケンス番号、およびマルチキャストパケットデータをＭＰキャッシュテーブル５００ｃに追加する。マルチキャスト受信ノード５００ｃのＭＰキャッシュテーブル５００ｃは、ネガティブＡＣＫ再送タイマ（ＮＡＣＫ再送タイマ：NACK_Retran_Timer）も含む。ＮＡＣＫ再送タイマは、近くのＦＮ９０やマルチキャスト受信ノード２０から同一のマルチキャストパケットが複数回再送信される回数を抑制または制限するために用いられる。
【００８６】
ＮＡＣＫ再送タイマの時間は、ノード数、データパケットに含まれるデータの種類、ノード１０の移動速度、およびその他のユーザ定義の基準に応じて変更可能である。例えば、１２ｍｓの再送時間を利用することができる。メッセージに含まれるデータが高い優先度のメッセージであれば、再送時間を短くしても良い。あるいは、メッセージが低い優先度のメッセージであれば、再送時間を長くしても良い。回復遅延は再送時間の値に依存する。再送時間が小さいほど、遅延は短くなる。しかしながら、小さくしすぎると多くの再送信が発生し、不必要な再送信が生じる。
【００８７】
マルチキャスト受信ノード２０は、受信した全てのマルチキャストパケットについてシーケンス番号を調べることで、受信し損ねたマルチキャストパケットを検出する。検出はブロック１３０５で行われる。例えば、マルチキャスト受信ノード２０がシーケンス番号１０、１１、１３のマルチキャストパケットを受信した場合、シーケンス番号１２のマルチキャストパケットが抜けている。
【００８８】
ブロック１３０５においてマルチキャストパケットが抜けている場合、マルチキャスト受信ノード２０は、ブロック１３１０で、ネガティブＡＣＫ（ＮＡＣＫ）をマルチキャストする。
【００８９】
ＮＡＣＫは、抜けているマルチキャストパケットのマルチキャストセッションＩＤ、送信元識別子、およびシーケンス番号を含む。その後、ブロック４３０で、入力マルチキャストパケットは破棄される。ブロック４４０で、マルチキャスト受信ノード２０はアイドルになる。
【００９０】
ブロック１３０５でマルチキャストパケットが抜けている場合、ブロック４３０で、マルチキャスト受信ノード２０は入力マルチキャストパケットを棄てる。ブロック４４０で、マルチキャスト受信ノード２０はアイドルになる。
【００９１】
ブロック４１５においてマルチキャストパケットがＭＰキャッシュテーブル５００ｃ内のいずれかのパケットと同一であれば、ブロック１２００で、マルチキャスト受信ノード２０はマルチキャストパケットのＮＡＣＫ再送タイマが「オン」であり満了していないか判断する。この判断はＭＰキャッシュテーブル５００ｃからの情報に基づく。（ブロック１２００において）ＮＡＣＫ再送タイマがオンであれば（図１２に示す機能ブロックと同じ）、ブロック１２０５でＮＡＣＫ再送タイマは停止される（図１２に示す機能ブロックと同じ）。マルチキャスト受信ノード２０は、ＮＡＣＫ再送タイマの状態を「オフ」に変更する。これは、同一のマルチキャストが不必要に再送信されるのを抑制するために行われる。そしてブロック４３０で、マルチキャスト受信ノード２０入力マルチキャストパケットを棄てる。ブロック４４０で、マルチキャスト受信ノード２０はアイドルになる。
【００９２】
ＮＡＣＫ再送タイマが（ブロック１２００において）「オフ」であれば、ブロック４３０で、マルチキャスト受信ノード２０は入力マルチキャストパケットを棄てる。ブロック４４０で、マルチキャスト受信ノード２０はアイドルになる。
【００９３】
図１２に戻って、ブロック８００においてノード１０がＦＮ９０であれば、処理はブロック４１５（図１２）へ進む。
【００９４】
マルチキャストパケットがＭＰキャッシュテーブル（図１５Ａ、５００ｂ）内のいずれのパケットとも一致しない場合は、ブロック４２０で、ＦＮ９０は受信したマルチキャストパケットをＭＰキャッシュテーブル５００ｂに追加する。
【００９５】
ＦＮ９０は、マルチキャストグループＩＤ、送信元識別子、シーケンス番号、Ｔｉｍｅ−ｔｏ−Ｌｉｖｅ（ＴＴＬ）値、およびデータを抽出し、この情報をＭＰキャッシュテーブル５００ｂに追加する。さらに、ＦＮ９０は再送カウンタをゼロに初期化する。再送カウンタ（ｓ＿ｍｐ＿ｃ）は、マルチキャストパケットが再送されうる回数を表す。ある実施形態では、マルチキャストメッセージが再送される回数はあらかじめ定められた最大値に制限される。あらかじめ定められた最大値は全ノード１０に対して同じであっても良い。別の実施形態では、あらかじめ定められた最大値はＧＨや送信元ノード７００のような特定のノードに対して変更可能としても良い。
【００９６】
ＭＰキャッシュテーブルはＦＮ９０とマルチキャスト受信ノード２０とで異なる。ＦＮ９０用には、ＭＰキャッシュテーブル５００ｂは、マルチキャストパケットについてのマルチキャストセッションＩＤ、送信元識別子、シーケンス番号、マルチキャストパケットデータ、ＡＣＫ状態、再送タイマ値、再送カウンタ、ＴＴＬ値、およびネガティブＡＣＫ再送タイマ（ＮＡＣＫ再送タイマ）を含む。ＡＣＫ状態は「未確認」または「確認済み」のいずれかであり得る。再送タイマ値はオンかオフのいずれかであり得る。タイマがオンであれば、再送タイマ値は初期設定タイマ値といつ再送タイマ値が満了したかの指示も含む。マルチキャスト受信ノード２０用には、ＭＰキャッシュテーブル５００ｃは、マルチキャストセッションＩＤ、送信元識別子、およびシーケンス番号だけを含む。
【００９７】
ブロック８０５で、ＦＮ９０はＡＣＫ状態を「未確認」に初期化する。ＦＮ９０はどのマルチキャストパケットが受信確認され受信されたかを追跡できる。さらに、ＦＮ９０は再送タイマ値をオンに初期化し、タイマを再送時間に設定する。再送時間は、データパケットに含まれるデータの種類、ＦＮ９０の移動速度、およびその他のユーザ定義の基準に応じて変更可能である。
【００９８】
ブロック８１０で、再送カウンタを１増分する。すなわちｓ＿ｍｐ＿ｃ＋１にする。再送カウンタが増分された後、ブロック６０５で、ＦＮ９０はマルチキャストパケットを一度転送する。ＦＮ９０は、転送の前にマルチキャストパケットのＴＴＬ値から１減算する。したがって、次ホップＦＮはマルチキャストパケットを送っているＦＮ９０よりも小さいＴＴＬ値を含むマルチキャストパケットを受信する。ブロック４４０で、ＦＮ９０はアイドルになる。
【００９９】
ブロック４１５においてマルチキャストパケットがＭＰキャッシュテーブル５００ｃ内のいずれかのパケットと同一であれば、ブロック１２００で、マルチキャスト受信ノード２０はＮＡＣＫ再送タイマが「オン」であり満了していないか判断する。この判断はＭＰキャッシュテーブル５００ｃからの情報に基づく。（ブロック１２００において）ＮＡＣＫ再送タイマがオンであれば、ブロック１２０５でＮＡＣＫ再送タイマは停止される。マルチキャスト受信ノード２０は、ＮＡＣＫ再送タイマの状態を「オフ」に変更する。これは、同一のマルチキャストが不必要に再送信されるのを抑制するために行われる。
【０１００】
ＮＡＣＫ再送タイマが（ブロック１２００において）「オフ」であれば、処理はブロック８１５へ進む。
【０１０１】
ブロック８１５で、ＦＮ９０は同一のマルチキャストパケットのオフセットＴＴＬ値（Ｉｎ＿ＭＰ＿ＴＴＬ＋１）とＴＴＬ値とを比較する。同一のマルチキャストパケットのＴＴＬ値はＭＰキャッシュテーブル５００ｂから取り出される。ＭＰキャッシュテーブル５００ｂから取り出されたＴＴＬ値がオフセット値よりも大きくない場合は、ブロック４３０で、入力マルチキャストパケットは無視されて破棄される。このマルチキャストパケットは上流ノードから発生したものである。マルチキャストパケットの転送は受信確認されない。ブロック４４０で、ＦＮ９０はアイドルになる。
【０１０２】
ブロック８１５においてＭＰキャッシュテーブル５００ｂから取り出されたＴＴＬ値がオフセット値よりも大きい場合は、ブロック８２０で、ＦＮ９０はこのマルチキャストパケットがすでに受信確認されたか判断する。
【０１０３】
ＦＮ９０はＭＰキャッシュテーブル５００ｂから同一のマルチキャストパケットについてのＡＣＫ状態を取り出す。同一のマルチキャストパケットがすでに受信確認されていれば、ブロック４３０で、入力マルチキャストパケットは無視されて破棄される。ブロック４４０で、ＦＮ９０はアイドルになる。ＭＰキャッシュテーブル５００ｂに変更はない。ブロック８２０において同一のマルチキャストパケットが受信確認されていなければ、本方法はブロック８２５へ進む。
【０１０４】
ブロック８２５で、ＦＮ９０は再送タイマを停止する。さらに、ＦＮ９０は、キャッシュテーブル５００ｂ内の再送タイマ値を「オフ」に変え、ＡＣＫ状態を「確認済み」に変える。その後、ブロック４３０で入力マルチキャストパケットは破棄される。ブロック４４０で、ＦＮ９０はアイドルになる。マルチキャストパケット転送の受信が確認される。
【０１０５】
図１４Ａは、ＮＡＣＫを処理する機能ブロックを示す。ＮＡＣＫ処理の動作プロセスは、ＦＮ９０とマルチキャスト受信ノードとで同じである。
【０１０６】
ブロック１４００で、ノード１０はＮＡＣＫパケットを受信する。ノード１０は、受信パケットに含まれる情報に基づいてそのパケットがＮＡＣＫパケットであるか判断する。次にブロック４０５で、ノード１０は、マルチキャストの参加者、すなわちＦＮ９０またはマルチキャスト受信ノード２０であるか判断する。
【０１０７】
ブロック４０５で、ノード１０は受信したＮＡＣＫパケットからマルチキャストグループＩＤを抽出して、ノード１０がマルチキャストセッションのメンバであるか判断する。この判断はマルチキャストルーティングテーブルに基づく。ノード１０がマルチキャストセッションのメンバでなければ、ブロック４１０で、それ以上の処理をせずにそのパケットのＮＡＣＫは破棄される。ノード１０がマルチキャストセッションのメンバであれば、ブロック４１５で、ノード１０はマルチキャストパケットがＭＰキャッシュテーブル（５００ｂまたは５００ｃ）にあるか判断する。例えば、マルチキャストパケットの情報エントリがＭＰキャッシュテーブル（５００ｂまたは５００ｃ）にリストされているか確認する。
【０１０８】
ブロック４１５においてマルチキャストパケットがＭＰキャッシュテーブル内のいずれかのパケットと同一であれば、ブロック１２００で、ノード１０はＮＡＣＫ再送タイマが「オン」であるか判断する。この判断はＭＰキャッシュテーブル（５００ｂまたは５００ｃ）からの情報に基づく。ＮＡＣＫ再送タイマが（ブロック１２００で）オンであれば、ブロック４４０で、ノード１０はアイドルになる。反対に、ＮＡＣＫ再送タイマが（ブロック１２００で）「オフ」であれば、ブロック１４０５で、ノード１０はＮＡＣＫ再送タイマを所定値に設定する。言い換えると、ノード１０はＮＡＣＫ再送タイマの状態を「オン」に変える。ＮＡＣＫ再送タイマはＮＡＣＫ期間の計時を開始する。
【０１０９】
図１４Ｂは、ＮＡＣＫ再送タイマが満了した際のマルチキャストパケットの再送の機能ブロックを示す。ブロック１４１０で、ＮＡＣＫ再送タイマが満了する。ノード１０はＮＡＣＫ再送タイマの状態を「オフ」に変える。ブロック６０５で、ノード１０はマルチキャストパケットを再送または転送する。ブロック４４０で、ノード１０はアイドルになる。
【０１１０】
図１５Ａは、本発明の第４の実施形態に係るＦＮ９０のＭＰキャッシュテーブル５００ｂの例を示す。図示されるように、ＭＰキャッシュテーブル５００ｂは、２つの異なるマルチキャストパケット（ＭＰ1とＭＰ2）を含む。各マルチキャストパケットに対して、ＭＰキャッシュテーブル５００ｂは、マルチキャストセッションＩＤ（ＧｒｏｕｐＡｄｄ）、送信元識別子、マルチキャストパケットのシーケンス番号（ＳｅｑＮｕｍ）、マルチキャストパケットデータ（ＭＰキャッシュ）、受信確認状態（ＡＣＫ状態）、再送タイマ（Ｒｅｔｒａｎ＿Ｔｉｍｅｒ）、再送カウンタ（ｓ＿ｍｐ＿ｃ）、マルチキャストパケットのＴＴＬ値（Ｃ＿ＭＰ＿ＴＴＬ）、およびネガティブＡＣＫ再送タイマ（ＮＡＣＫ再送タイマ）を含む。図１５Ａに示されるように、ＮＡＣＫ再送タイマはマルチキャストパケットの一方についてオンである。
【０１１１】
図１５Ｂは、本発明の第４の実施形態に係るマルチキャスト受信ノードのＭＰキャッシュテーブル５００Ｃの例を示す。図示されるように、ＭＰキャッシュテーブル５００ｂは、２つの異なるマルチキャストパケット（ＭＰ1とＭＰ2）を含む。各マルチキャストパケットに対して、ＭＰキャッシュテーブル５００ｃは、マルチキャストセッションＩＤ（ＧｒｏｕｐＡｄｄ）、送信元識別子、マルチキャストパケットのシーケンス番号（ＳｅｑＮｕｍ）、およびネガティブＡＣＫ再送タイマ（ＮＡＣＫ再送タイマ）を含む。
【０１１２】
図１６は、本発明の第５の実施形態に係るルーティング方法を示す。本発明の第５の実施形態は、マルチキャストパケットが複数回中継される点を除いて、第３の実施形態と同様である。
【０１１３】
ブロック４００で、マルチキャストパケットがノード１０に到着する。マルチキャストパケットは、マルチキャストグループＩＤ、送信元識別子、シーケンス番号、Ｔｉｍｅ−ｔｏ−Ｌｉｖｅ（ＴＴＬ）値、およびデータを含む。ＴＴＬ値は、マルチキャストパケットが中継されるホップ数である。
【０１１４】
ブロック４０５で、ノード１０はパケットからマルチキャストグループ識別子を抽出して、ノード１０がマルチキャストセッションのメンバであるか判断する。この判断はマルチキャストルーティングテーブルに基づく。ノード１０がマルチキャストセッションのメンバでなければ、ブロック４１０で、それ以上の処理をせずにマルチキャストパケットは破棄される。ノード１０がマルチキャストセッションのメンバであれば、ブロック８００で、ノード１０はＦＮ９０かマルチキャスト受信ノードであるかを判断する。ノード１０がマルチキャスト受信ノード２０であれば、処理は図１０の機能ブロック４１５へ進む。ノード１０がマルチキャストセッションのＦＮ９０であれば、ブロック４１５（図１６）で、ＦＮ９０はマルチキャストパケットがＭＰキャッシュテーブル（例えば、５００ａ）内にあるか判断する。
【０１１５】
マルチキャストパケットがＭＰキャッシュテーブル５００ａ内のいずれのパケットとも一致しない場合は、ブロック４２０で、ＦＮ９０は受信したマルチキャストパケットをキャッシュテーブル５００ａへ追加する。
【０１１６】
ＦＮ９０は、マルチキャストグループＩＤ、送信元識別子、シーケンス番号、Ｔｉｍｅ−ｔｏ−Ｌｉｖｅ（ＴＴＬ）値、およびデータを抽出し、この情報をＭＰキャッシュテーブル５００ａに追加する。さらに、ＦＮ９０は再送カウンタをゼロに初期化する。再送カウンタ（ｓ＿ｍｐ＿ｃ）は、マルチキャストパケットが再送されうる回数を表す。第３の実施形態と同様に、ＭＰキャッシュテーブルはＦＮ９０とマルチキャスト受信ノードとで異なる。ＭＰキャッシュテーブル（例えば、５００ａおよび５００）は、第３の実施形態と同一の情報を含む。
【０１１７】
ブロック８０５で、ＦＮ９０はＡＣＫ状態を「未確認」に初期化する。ＦＮ９０はどのマルチキャストパケットが受信確認され受信されたかを追跡できる。さらに、ＦＮ９０は再送タイマ値をオンに初期化し、タイマを再送時間に設定する。再送時間は、データパケットに含まれるデータの種類、ＦＮ９０の移動速度、およびその他のユーザ定義の基準に応じて変更可能である。
【０１１８】
ブロック８１０で、再送カウンタが１増分する。すなわちｓ＿ｍｐ＿ｃ＋１にする。再送カウンタが増分された後、ブロック６０５で、ＦＮ９０はマルチキャストパケットをＮ回転送する。ある実施形態では、ＦＮ９０はマルチキャストパケットをＮ回連続して転送する。パケットが転送される数字「Ｎ」回は予め定められていて変更可能である。到達率の増加とデータオーバヘッドの増加にはトレードオフがある。数字「Ｎ」が増えるにしたがって、データオーバヘッドが著しく増加するが、到達率もまた増加する。別の実施形態では、ＦＮ９０はパケットをＮ回同時に転送する。
【０１１９】
ＦＮ９０は、転送の前にマルチキャストパケットのＴＴＬ値から１減算する。したがって、次ホップＦＮはマルチキャストパケットを送っているＦＮ９０よりも小さいＴＴＬ値を含むマルチキャストパケットを受信する。ブロック４４０で、ＦＮ９０はアイドルになる。
【０１２０】
マルチキャストパケットがＭＰキャッシュテーブル５００ａ内のいずれかのパケットと同一であれば、本方法はブロック８１５へ進む。
【０１２１】
ＦＮ９０は入力マルチキャストパケットのＴＴＬ値を判断する。上記したようにＴＴＬ値は特定のマルチキャストパケットのホップ数を制御するために用いられる。さらにこの実施形態では、ＴＴＬ値は送信ノード１０および受信ノード１０の相対的な位置を決定するためにも用いられる。具体的には、マルチキャストパケットが転送されるたびに、ノード１０はＴＴＬ値から１減算する（すなわち、ＴＴＬ−１）。特定のＦＮ９０から下流にあるノード１０から受信されたマルチキャストパケットのＴＴＬ値は、ＦＮ９０から転送された同一のマルチキャストパケットのＴＴＬ値よりも小さい。特定のＦＮ９０から上流にあるノード１０から受信されたマルチキャストパケットのＴＴＬ値は、ＦＮ９０から転送された同一のマルチキャストパケットのＴＴＬ値よりも大きい。特定のＦＮ９０と同じホップ数のノード１０から受信されたマルチキャストパケットは、同一のＴＴＬ値を持つ。
【０１２２】
ＦＮ９０は、ＦＮ９０による最初のマルチキャストパケットの転送を補うために、判定されたＴＴＬ値にオフセット値の１を加える。これによりオフセットＴＴＬ値が生成される。
【０１２３】
ブロック８１５で、ＦＮ９０は、オフセットＴＴＬ値（Ｉｎ＿ＭＰ＿ＴＴＬ＋１）と同一のマルチキャストパケットのＴＴＬ値とを比較する。同一のマルチキャストパケットのＴＴＬ値は、ＭＰキャッシュテーブルから取り出される。ＭＰキャッシュテーブルから取り出されたＴＴＬ値がオフセット値よりも大きくない場合は、ブロック４３０で、入力マルチキャストパケットは無視されて破棄される。このマルチキャストパケットは上流ノードから発生したものである。マルチキャストパケットの転送は受信確認されない。ブロック４４０で、ＦＮ９０はアイドルになる。
【０１２４】
ブロック８１５においてＭＰキャッシュテーブル５００ａから取り出されたＴＴＬ値がオフセット値よりも大きい場合は、ブロック８２０で、ＦＮ９０はこのマルチキャストパケットがすでに受信確認されたか判断する。
【０１２５】
ＦＮ９０はＭＰキャッシュテーブル５００ａから同一のマルチキャストパケットについてのＡＣＫ状態を取り出す。同一のマルチキャストパケットがすでに受信確認されていれば、ブロック４３０で、入力マルチキャストパケットは無視されて破棄される。ブロック４４０で、ＦＮ９０はアイドルになる。ＭＰキャッシュテーブル５００ａに変更はない。ブロック８２０において同一のマルチキャストパケットが受信確認されていなければ、本方法はブロック８２５へ進む。
【０１２６】
ブロック８２５で、ＦＮ９０は再送タイマを停止する。さらに、ＦＮ９０は、キャッシュテーブル５００ａ内の再送タイマ値を「オフ」に変え、ＡＣＫ状態を「確認済み」に変える。その後、ブロック４３０で入力マルチキャストパケットは破棄される。ブロック４４０で、ＦＮ９０はアイドルになる。マルチキャストパケット転送の受信が確認される。
【０１２７】
残りの機能ブロックは図９および図１０で示された機能ブロックと一致しているので、詳しくは説明しない。
【０１２８】
図１７は、本発明の第６の実施形態に係るマルチキャスト受信ノード２０の機能ブロックを示す。本発明の第６の実施形態は、本発明の第２および第３の実施形態の機能ブロックを組み合わせたものである。ＦＮ９０の機能ブロックは図８および図９で示された機能ブロックと一致しているので、詳しくは説明しない。
【０１２９】
ブロック４１５で、マルチキャスト受信ノード２０は、マルチキャストパケットがＭＰキャッシュテーブル（例えば、５００ａ）内にあるか判断する。マルチキャストパケットがＭＰキャッシュテーブル５００ａないにあれば、ブロック４３０で、マルチキャストパケットは破棄される。ブロック４４０で、マルチキャスト受信ノード２０はアイドルになる。
【０１３０】
マルチキャストパケットがＭＰキャッシュテーブル５００内に無い、すなわち、同一ではない場合は、マルチキャストパケットに含まれる情報がＭＰキャッシュテーブル５００ａに追加される。ブロック６００で、マルチキャスト受信ノード２０は、マルチキャストパケットに割り当てられたランダムな確率と、確率閾値とを比較する。マルチキャストパケットに割り当てられたランダムな確率が確率閾値よりも小さければ、ブロック６０５で、マルチキャスト受信ノード２０は受信したマルチキャストパケットを転送する。そして、ブロック４４０で、マルチキャスト受信ノード２０はアイドルになる。
【０１３１】
マルチキャストパケットに割り当てられたランダムな確率が確率閾値以上であれば、ブロック４３０で、マルチキャスト受信ノード２０は受信したマルチキャストパケットを破棄する。そして、ブロック４４０で、マルチキャスト受信ノード２０はアイドルになる。
【０１３２】
図１８は、本発明の第７の実施形態に係るルーティング方法を示す。第７の実施形態によれば、、マルチキャストパケットの送信はあらかじめ定められた基準に基づいて抑制される。
【０１３３】
図１８に示すように、マルチキャストパケットがノード１０に到着する。マルチキャストパケットは、マルチキャストグループＩＤ、送信元識別子、シーケンス番号、Ｔｉｍｅ−ｔｏ−Ｌｉｖｅ（ＴＴＬ）値、およびデータを含む。ＴＴＬ値は、マルチキャストパケットが中継されるホップ数である。
【０１３４】
ブロック４０５で、ノード１０はパケットからマルチキャストグループ識別子を抽出して、ノード１０がマルチキャストセッションのメンバであるか判断する。この判断はマルチキャストルーティングテーブルに基づく。ノード１０がマルチキャストセッションのメ
ンバでなければ、ブロック４１０で、それ以上の処理をせずにマルチキャストパケットは破棄される。ノード１０がマルチキャストセッションのメンバであれば、ブロック８００で、ノード１０はＦＮ９０かマルチキャスト受信ノードであるかを判断する。ノード１０がマルチキャスト受信ノードであれば、処理はブロック４１５（受信者用）に移動する。ノード１０がマルチキャストセッションのＦＮ９０であれば、ブロック４１５（ＦＮ９０用）で、ＦＮ９０はマルチキャストパケットがＭＰキャッシュテーブル（例えば、５００ｄ）内にあるか判断する。
【０１３５】
マルチキャストパケットがＭＰキャッシュテーブル５００ｄ内のいずれのパケットとも一致しない場合は、ブロック４２０で、ＦＮ９０またはマルチキャスト受信ノード２０は受信したマルチキャストパケットをＭＰキャッシュテーブル５００ｄに付加する。
【０１３６】
ＦＮ９０は、マルチキャストグループＩＤ、送信元識別子、シーケンス番号、Ｔｉｍｅ−ｔｏ−Ｌｉｖｅ（ＴＴＬ）値、およびデータを抽出し、この情報をＭＰキャッシュテーブル５００ｄに付加する。さらに、ＦＮ９０は再送カウンタをゼロに初期化する。再送カウンタ（ｓ＿ｍｐ＿ｃ）は、マルチキャストパケットが再送されうる回数を表す。この実施形態では、ｓ＿ｍｐ＿ｃの値は「０」か「１」である。ＦＮ９０のＭＰキャッシュテーブル５００ｄはランダム転送タイマも含む。
【０１３７】
ＭＰキャッシュテーブルはＦＮ９０とマルチキャスト受信ノード２０とで異なる。マルチキャスト受信ノード２０のＭＰキャッシュテーブル５００ｄは、マルチキャストセッションＩＤ、送信元識別子、およびマルチキャストパケットのシーケンス番号を含む。したがって、ブロック４２０で、マルチキャスト受信ノード２０は、マルチキャストセッションＩＤ、送信元識別子、およびシーケンス番号をＭＰキャッシュテーブル５００に付加する。
【０１３８】
ブロック４２５で、ノード１０はマルチキャストセッションのＦＮ９０であるか判断する。この判断は転送テーブルおよびＭＰキャッシュテーブル（例えば、５００）内の情報に基づく。ノード１０がマルチキャストパケットのＦＮ９０でなければ、ブロック４１９で、入力マルチキャストパケットは破棄される。ノードがＦＮ９０であれば、ブロック１８００で、ＦＮは転送タイマをランダム値に設定する。このランダム値によりマルチキャストパケットの転送が妨げられる。ＦＮ９０は、ランダム値が満了、すなわちランダム転送タイマが満了したときのみマルチキャストパケットを転送する。
【０１３９】
ブロック４１５において、マルチキャストパケットがＭＰキャッシュテーブル５００ｄ内にすでに存在する場合は、ブロック１８０２で、ＦＮ９０はこのパケットをすでに転送したか、すなわちｓ＿ｍｐ＿ｃ＝１であるか判断する。カウンタ（ｓ＿ｍｐ＿ｃ）が１に等しければ、パケットはすでに転送されている。カウンタ（ｓ＿ｍｐ＿ｃ）が０に等しければ、パケットはまだ転送されていない。ＦＮはＭＰキャッシュテーブル５００ｄからカウンタ値を取り出す。ブロック１８０２においてカウンタ（ｓ＿ｍｐ＿ｃ）が１に等しければ、ステップ４３０で、マルチキャストパケットは転送されることなく破棄される。ブロック１８０２で、カウンタ（ｓ＿ｍｐ＿ｃ）が０に等しければ、ＦＮ９０は入力マルチキャストパケットのＴＴＬ値を判断する（ブロック８１５）。上記したように、ＴＴＬ値は特定のマルチキャストパケットのホップ数を制御するために用いられる。さらに、この実施形態では、ＴＴＬ値は送信ノード１０および受信ノード１０の相対的な位置を決定するためにも用いられる。ＦＮ９０は、ＦＮ９０による最初のマルチキャストパケットの転送を補うために、判定されたＴＴＬ値にオフセット値の１を加える。これによりオフセットＴＴＬ値が生成される。
【０１４０】
ブロック８１５で、ＦＮ９０は、オフセットＴＴＬ値（Ｉｎ＿ＭＰ＿ＴＴＬ＋１）と同
一のマルチキャストパケットのＴＴＬ値とを比較する。同一のマルチキャストパケットのＴＴＬ値は、ＭＰキャッシュテーブル５００ｄから取り出される。ＭＰキャッシュテーブル５００ｄから取り出されたＴＴＬ値がオフセット値よりも大きくない場合は、（ブロック４３０で）入力マルチキャストパケットは破棄され、ＦＮ９０はアイドルになる。このマルチキャストパケットは上流ノードまたはピアノードから発生したものである。ブロック８１５においてＭＰキャッシュテーブル５００ｄから取り出されたＴＴＬ値がオフセット値よりも大きい場合は、入力マルチキャストパケットは例えば下流ＦＮ９０から発生したものであり、ＦＮ９０はマルチキャストパケットを転送する必要が無い。
【０１４１】
ブロック１８０５で、ＦＮはマルチキャストパケットのランダム転送タイマを停止する。言い換えると、ＦＮはランダム転送タイマの状態を「オン」から「オフ」に変更する。その後、ブロック４３０でマルチキャストパケットは破棄される。ブロック４４０で、ＦＮ９０はアイドルになる。
【０１４２】
ランダム転送タイマが満了したら、ＦＮ９０はマルチキャストパケットを転送する。ブロック１８１０で、ランダム転送タイマが満了し、ＦＮ９０がランダム転送タイマの状態を「オン」から「オフ」に変更する。その後、ブロック６０５で、ＦＮ９０はマルチキャストパケットを転送する。ＦＮ９０はＴＴＬ値を１だけ減らす。マルチキャストパケット内のＴＴＬ値を１だけ減少させた後、ＦＮ９０マルチキャストパケットを転送する。さらに、マルチキャストパケットの転送の後、ブロック１８１２でＦＮは再送カウンタ（ｓ＿ｍｐ＿ｃ）を１に設定する。ブロック４４０で、ＦＮ９０はアイドルになる。第７の実施形態によれば、ＦＮ９０によるマルチキャストパケットの転送は軽く抑制される。
【０１４３】
図１９は、本発明の第８の実施形態に係るルーティング方法を示す。第８の実施形態によれば、マルチキャストパケットの転送は厳しく制限される。図１９に示される機能ブロックの多くは図１８と同じであり、したがって、詳しくは説明しない。第７と第８の実施形態の違いは、ブロック１９００における（ブロック８１５と対照的な）ＴＴＬ値の比較である。ブロック１９００で、入力マルチキャストパケットのＴＴＬ値がＭＰキャッシュテーブル（例えば、５００ｄ）に格納されたＴＴＬ値と比較される。
【０１４４】
入力マルチキャストパケットのＴＴＬ値にはオフセット値が加えられない。
【０１４５】
ＭＰキャッシュテーブル（例えば、５００ｄ）から取り出されたＴＴＬ値が入力ＴＴＬ値より大きくなければ、入力マルチキャストパケットは（ブロック４３０で）破棄され、ブロック４４０でＦＮ９０はアイドルになる。このマルチキャストパケットは上流ノードから発生したものである。ブロック１９００においてＭＰキャッシュテーブル５００ｄから取り出されたＴＴＬ値が入力ＴＴＬ値より大きければ、入力マルチキャストパケットは例えばピアや下流ノードから発生したものである。ＦＮ９０は、マルチキャストパケットの転送をやめて、マルチキャストパケットのランダム転送タイマを停止する。
【０１４６】
図２０は、本発明の第９の実施形態に係るルーティング方法を示す。本発明の第９の実施形態は２段階の抑制方法を用いる。図２０は、２つの機能ブロックが追加されている以外は、図１８と同様である。同一の機能ブロックについては繰り返しては説明しない。
【０１４７】
上述したように、ブロック８１５で、ＦＮ９０は、オフセットＴＴＬ値（ＩＮ＿ＭＰ＿ＴＴＬ＋１）を同一のマルチキャストパケットのＴＴＬ値と比較する。同一のマルチキャストパケットのＴＴＬ値はＭＰキャッシュテーブル（例えば、５００ｄ）から取り出される。ＭＰキャッシュテーブル５００ｄから取り出されたＴＴＬ値がオフセット値よりも大きくなければ、入力マルチキャストパケットは（ブロック４３０で）破棄され、ブロック４４０でＦＮ９０はアイドルになる。しかしながら、第９の実施形態では、ＭＰキャッシ
ュテーブル５００ｄから取り出されたＴＴＬ値がオフセット値よりも大きくなければ、ブロック２０００で、ＦＮはＭＰキャッシュテーブルから取り出されたＴＴＬ値がオフセット値と等しいか判断する。ＭＰキャッシュテーブル５００ｄから取り出されたＴＴＬ値がオフセット値と等しくなければ、入力マルチキャストパケットは破棄され、ブロック４４０でＦＮ９０はアイドルになる。しかしながら、ＭＰキャッシュテーブル５００ｄから取り出されたＴＴＬ値がオフセット値と等しい、すなわち、マルチキャストパケットが周囲のピアから受信されたものであれば、ブロック２００５で、マルチキャストパケットのランダム転送タイマが停止されて、別のランダム値に再設定される。マルチキャストパケットのランダム転送タイマ延長される。この時間延長により、同一のマルチキャストパケットのＴＴＬ値よりも小さいオフセットＴＴＬ値を有する入力マルチキャストパケットを、ランダム転送タイマが満了する前に受信する機会が増える。したがって、不必要な転送が抑制され、重複するパケットが生成することが少ない。
【０１４８】
図２１は、第７〜第９の実施形態に係るＦＮ９０のＭＰキャッシュテーブル５００ｄの例を示す。図示されるように、ＭＰキャッシュテーブル５００ｄは、２つの異なるマルチキャストパケット（ＭＰ1およびＭＰ2）を含む。各マルチキャストパケットに対して、ＭＰキャッシュテーブル５００ｂは、マルチキャストセッションＩＤ（Ｇｒｏｕｐ Ａｄｄ）、送信元識別子、マルチキャストパケットのシーケンス番号（ＳｅｑＮｕｍ）、マルチキャストパケットデータ（ＭＰキャッシュ）、再送カウンタ（ｓ＿ｍｐ＿ｃ）、マルチキャストパケットのＴＴＬ値（Ｃ＿ＭＰ＿ＴＴＬ）、およびランダム転送タイマ（Random_Forward_Timer）を含む。図２１に示されるように、マルチキャストパケットの一方についてオンである。
【０１４９】
本発明の第９の実施形態は、マルチキャストパケットと同様にブロードキャストパケットにも適用できる。しかしながら、ブロードキャスト通信を行うためには、すべてのノードがＦＮ９０になる。
【０１５０】
本発明はここまで特定の例示的な実施形態を参照して説明されている。本発明の範囲から逸脱することなくいくらかの代替や変更は当業者にとって明らかであろう。例示的な実施形態は説明を意図したものであり、添付の特許請求の範囲によって定義される本発明の範囲を限定するものではない。
【特許請求の範囲】
【請求項１】
少なくともメッセージと送信元識別子とシーケンス番号とＴｉｍｅ−ｔｏ−Ｌｉｖｅ値とマルチキャストグループ宛先とを含むマルチキャストメッセージを受信するステップと、
前記マルチキャストグループ宛先がマルチキャスト転送テーブル内に存在するか判断するステップと、
前記メッセージが以前に受信したものであるか判断するステップと、
前記メッセージが以前に受信したものではないと判断された場合に、前記マルチキャストメッセージを前記マルチキャスト転送テーブルに追加するステップと、
前記マルチキャストメッセージを受信したノードが転送ノードであるか判断するステップと、
前記マルチキャストメッセージを転送するための待機時間をランダムに設定するステップと、
前記待機時間が満了したときに、前記マルチキャストメッセージを転送するステップと、
を含む、マルチキャストメッセージのルーティング方法。
【請求項２】
前記メッセージが以前に受信したものである場合に、少なくとも同一のメッセージと送信元識別子とシーケンス番号とマルチキャストグループ宛先とを含む第２のマルチキャストメッセージを前記ランダムに設定された待機時間内に下流ノードから受信したときは、前記ランダムに設定された待機時間を停止するステップをさらに含む、
請求項１に記載のマルチキャストメッセージのルーティング方法。
【請求項３】
前記待機時間が停止された場合は、前記マルチキャストメッセージは転送されない、
請求項２に記載のマルチキャストメッセージのルーティング方法。
【請求項４】
第２のマルチキャストメッセージが下流ノードから受信されたかの判断は、
第２のマルチキャストメッセージからＴｉｍｅ−ｔｏ−Ｌｉｖｅ値を抽出する工程と、
前記Ｔｉｍｅ−ｔｏ−Ｌｉｖｅ値にプリセット値を加えてオフセットＴｉｍｅ−ｔｏ−Ｌｉｖｅ値を生成する工程と;
前記マルチキャスト転送テーブルから同一のメッセージを含むマルチキャストメッセージのＴｉｍｅ−ｔｏ−Ｌｉｖｅ値を取り出す工程と、
前記オフセットＴｉｍｅ−ｔｏ−Ｌｉｖｅ値と前記取り出されたＴｉｍｅ−ｔｏ−Ｌｉｖｅ値とを比較する工程と、
を含み、
前記取り出されたＴｉｍｅ−ｔｏ−Ｌｉｖｅ値が前記オフセットＴｉｍｅ−ｔｏ−Ｌｉｖｅ値よりも大きい場合に、前記待機時間が停止される、
請求項２に記載のマルチキャストメッセージのルーティング方法。
【請求項５】
前記取り出されたＴｉｍｅ−ｔｏ−Ｌｉｖｅ値が前記オフセットＴｉｍｅ−ｔｏ−Ｌｉｖｅ値と等しい場合に、前記待機時間はランダム値にリセットされる、
請求項４に記載のマルチキャストメッセージのルーティング方法。
【請求項６】
転送後にＡＣＫフラグを未確認に設定するステップと、
再送時間を所定時間に設定するステップと、
をさらに含む、請求項１に記載のマルチキャストメッセージのルーティング方法。
【請求項７】
前記メッセージが以前に受信されたものである場合に、少なくとも同一のメッセージと送信元識別子とシーケンス番号とマルチキャストグループ宛先とを含む第２のマルチキャ
ストメッセージを下流ノードから受信したときは、前記再送時間を停止するステップをさらに含む、
請求項６に記載のマルチキャストメッセージのルーティング方法。
【請求項８】
前記再送時間を停止した後に、ＡＣＫフラグを確認済みに設定するステップをさらに含む、
請求項７に記載のマルチキャストメッセージのルーティング方法。
【請求項９】
前記再送時間が満了したときに、前記マルチキャストメッセージを再送するステップと、
再送後に前記送信時間を所定時間に設定するステップと、
をさらに含む、請求項７に記載のマルチキャストメッセージのルーティング方法。
【請求項１０】
再送の上限に達したか判断するステップと、
前記判断に基づいて、前記再送時間が満了したときに、前記マルチキャストメッセージを再送するステップと、
再送カウンタを増加させるステップと、
再送後に前記再送時間を所定時間に設定するステップと、
をさらに含み、
再送の上限に達した場合には、再送時間が停止される、
請求項７に記載のマルチキャストメッセージのルーティング方法。
【請求項１１】
少なくともメッセージと送信元識別子とシーケンス番号とＴｉｍｅ−ｔｏ−Ｌｉｖｅ値とマルチキャストグループ宛先とを含むマルチキャストメッセージを受信するステップと、
前記マルチキャストグループ宛先がマルチキャスト転送テーブル内に存在するか判断するステップと、
前記メッセージが以前に受信したものであるか判断するステップと、
前記メッセージが以前に受信したものではないと判断された場合に、前記マルチキャストメッセージを前記マルチキャスト転送テーブルに追加するステップと、
前記マルチキャストメッセージを受信したノードがマルチキャスト受信ノードであるか判断するステップと、
マルチキャスト受信ノードに確率値をランダムに割り当てるステップと、
前記ランダムに割り当てられた確率値とプリセット確率閾値とを比較するステップと、
前記比較に基づいて前記マルチキャストメッセージを転送するステップと、
を含む、マルチキャストメッセージのルーティング方法。
【請求項１２】
前記プリセット確率閾値を設定するステップをさらに含む
請求項１１に記載のマルチキャストメッセージのルーティング方法するステップ。
【請求項１３】
前記マルチキャスト転送テーブルは、前記グループ宛先と前記送信元識別子と前記シーケンス番号とを含む、
請求項１１に記載のマルチキャストメッセージのルーティング方法。
【請求項１４】
前記マルチキャスト転送テーブルは、前記グループ宛先と前記送信元識別子と前記シーケンス番号と前記メッセージと前記ＡＣＫフラグと前記再送時間値と前記再送カウンタと前記Ｔｉｍｅ−ｔｏ−Ｌｉｖｅ値とを含む、
請求項１０に記載のマルチキャストメッセージのルーティング方法。
【請求項１５】
転送後にＡＣＫフラグを未確認に設定するステップと、
再送時間を所定時間に設定するステップと、
をさらに含む、請求項１１に記載のマルチキャストメッセージのルーティング方法
【請求項１６】
再送カウンタを増加させるステップをさらに含む、
請求項１１に記載のマルチキャストメッセージのルーティング方法。
【請求項１７】
前記メッセージが以前に受信されたものである場合に、少なくとも同一のメッセージと送信元識別子とシーケンス番号とマルチキャストグループ宛先とを含む第２のマルチキャストメッセージを下流ノードから受信したときに、前記再送時間を停止するステップをさらに含む、
請求項１５に記載のマルチキャストメッセージのルーティング方法。
【請求項１８】
前記再送時間を停止した後に、ＡＣＫフラグを確認済みに設定するステップをさらに含む、
請求項１５に記載のマルチキャストメッセージのルーティング方法。
【請求項１９】
再送カウンタの値に基づいて、再送の上限に達したか判断するステップと、
前記判断に基づいて、前記再送時間が満了したときに、前記マルチキャストメッセージを再送するステップと、
再送カウンタを増加させるステップと、
再送後に前記再送時間を所定時間に設定するステップと、
をさらに含み、
再送の上限に達した場合には、再送時間が停止される、
請求項１５に記載のマルチキャストメッセージのルーティング方法。
【請求項２０】
少なくともメッセージと送信元識別子とシーケンス番号とＴｉｍｅ−ｔｏ−Ｌｉｖｅ値とマルチキャストグループ宛先とを含むマルチキャストメッセージを受信するステップと、
前記マルチキャストグループ宛先がマルチキャスト転送テーブル内に存在するか判断するステップと、
前記メッセージが以前に受信したものであるか判断するステップと、
を含み、
前記メッセージが以前に受信されたものである場合に、
前記Ｔｉｍｅ−ｔｏ−Ｌｉｖｅ値にプリセット値を加えてオフセットＴｉｍｅ−ｔｏ−Ｌｉｖｅ値を生成する工程と、
前記オフセットＴｉｍｅ−ｔｏ−Ｌｉｖｅ値と前記マルチキャスト転送テーブル内のＴｉｍｅ−ｔｏ−Ｌｉｖｅ値を比較する工程と、
前記オフセットＴｉｍｅ−ｔｏ−Ｌｉｖｅ値が前記マルチキャスト転送テーブル内のＴｉｍｅ−ｔｏ−Ｌｉｖｅ値以上である場合に、前記マルチキャストメッセージを転送することなく破棄する工程と、
を含む、マルチキャストメッセージのルーティング方法。
【請求項２１】
前記マルチキャストメッセージが以前に受信したものではない場合に、
ＡＣＫフラグを未確認に設定する工程と、
再送カウンタを増加させる工程と、
再送時間を所定値に設定する工程と、
マルチキャストメッセージを転送する工程と、
をさらに含む、請求項２０に記載のマルチキャストメッセージのルーティング方法。
【請求項２２】
前記オフセットＴｉｍｅ−ｔｏ−Ｌｉｖｅ値が前記マルチキャスト転送テーブル内のＴ
ｉｍｅ−ｔｏ−Ｌｉｖｅ値よりも小さい場合に、
ＡＣＫフラグを確認済みに設定する工程と、
前記再送時間を停止する工程と、
をさらに含む、請求項２０に記載のマルチキャストメッセージのルーティング方法。
【請求項１】
少なくともメッセージと送信元識別子とシーケンス番号とＴｉｍｅ−ｔｏ−Ｌｉｖｅ値とマルチキャストグループ宛先とを含むマルチキャストメッセージを受信するステップと、
前記マルチキャストグループ宛先がマルチキャスト転送テーブル内に存在するか判断するステップと、
前記メッセージが以前に受信したものであるか判断するステップと、
前記メッセージが以前に受信したものではないと判断された場合に、前記マルチキャストメッセージを前記マルチキャスト転送テーブルに追加するステップと、
前記マルチキャストメッセージを受信したノードが転送ノードであるか判断するステップと、
前記マルチキャストメッセージを転送するための待機時間をランダムに設定するステップと、
前記待機時間が満了したときに、前記マルチキャストメッセージを転送するステップと、
を含む、マルチキャストメッセージのルーティング方法。
【請求項２】
前記メッセージが以前に受信したものである場合に、少なくとも同一のメッセージと送信元識別子とシーケンス番号とマルチキャストグループ宛先とを含む第２のマルチキャストメッセージを前記ランダムに設定された待機時間内に下流ノードから受信したときは、前記ランダムに設定された待機時間を停止するステップをさらに含む、
請求項１に記載のマルチキャストメッセージのルーティング方法。
【請求項３】
前記待機時間が停止された場合は、前記マルチキャストメッセージは転送されない、
請求項２に記載のマルチキャストメッセージのルーティング方法。
【請求項４】
第２のマルチキャストメッセージが下流ノードから受信されたかの判断は、
第２のマルチキャストメッセージからＴｉｍｅ−ｔｏ−Ｌｉｖｅ値を抽出する工程と、
前記Ｔｉｍｅ−ｔｏ−Ｌｉｖｅ値にプリセット値を加えてオフセットＴｉｍｅ−ｔｏ−Ｌｉｖｅ値を生成する工程と;
前記マルチキャスト転送テーブルから同一のメッセージを含むマルチキャストメッセージのＴｉｍｅ−ｔｏ−Ｌｉｖｅ値を取り出す工程と、
前記オフセットＴｉｍｅ−ｔｏ−Ｌｉｖｅ値と前記取り出されたＴｉｍｅ−ｔｏ−Ｌｉｖｅ値とを比較する工程と、
を含み、
前記取り出されたＴｉｍｅ−ｔｏ−Ｌｉｖｅ値が前記オフセットＴｉｍｅ−ｔｏ−Ｌｉｖｅ値よりも大きい場合に、前記待機時間が停止される、
請求項２に記載のマルチキャストメッセージのルーティング方法。
【請求項５】
前記取り出されたＴｉｍｅ−ｔｏ−Ｌｉｖｅ値が前記オフセットＴｉｍｅ−ｔｏ−Ｌｉｖｅ値と等しい場合に、前記待機時間はランダム値にリセットされる、
請求項４に記載のマルチキャストメッセージのルーティング方法。
【請求項６】
転送後にＡＣＫフラグを未確認に設定するステップと、
再送時間を所定時間に設定するステップと、
をさらに含む、請求項１に記載のマルチキャストメッセージのルーティング方法。
【請求項７】
前記メッセージが以前に受信されたものである場合に、少なくとも同一のメッセージと送信元識別子とシーケンス番号とマルチキャストグループ宛先とを含む第２のマルチキャ
ストメッセージを下流ノードから受信したときは、前記再送時間を停止するステップをさらに含む、
請求項６に記載のマルチキャストメッセージのルーティング方法。
【請求項８】
前記再送時間を停止した後に、ＡＣＫフラグを確認済みに設定するステップをさらに含む、
請求項７に記載のマルチキャストメッセージのルーティング方法。
【請求項９】
前記再送時間が満了したときに、前記マルチキャストメッセージを再送するステップと、
再送後に前記送信時間を所定時間に設定するステップと、
をさらに含む、請求項７に記載のマルチキャストメッセージのルーティング方法。
【請求項１０】
再送の上限に達したか判断するステップと、
前記判断に基づいて、前記再送時間が満了したときに、前記マルチキャストメッセージを再送するステップと、
再送カウンタを増加させるステップと、
再送後に前記再送時間を所定時間に設定するステップと、
をさらに含み、
再送の上限に達した場合には、再送時間が停止される、
請求項７に記載のマルチキャストメッセージのルーティング方法。
【請求項１１】
少なくともメッセージと送信元識別子とシーケンス番号とＴｉｍｅ−ｔｏ−Ｌｉｖｅ値とマルチキャストグループ宛先とを含むマルチキャストメッセージを受信するステップと、
前記マルチキャストグループ宛先がマルチキャスト転送テーブル内に存在するか判断するステップと、
前記メッセージが以前に受信したものであるか判断するステップと、
前記メッセージが以前に受信したものではないと判断された場合に、前記マルチキャストメッセージを前記マルチキャスト転送テーブルに追加するステップと、
前記マルチキャストメッセージを受信したノードがマルチキャスト受信ノードであるか判断するステップと、
マルチキャスト受信ノードに確率値をランダムに割り当てるステップと、
前記ランダムに割り当てられた確率値とプリセット確率閾値とを比較するステップと、
前記比較に基づいて前記マルチキャストメッセージを転送するステップと、
を含む、マルチキャストメッセージのルーティング方法。
【請求項１２】
前記プリセット確率閾値を設定するステップをさらに含む
請求項１１に記載のマルチキャストメッセージのルーティング方法するステップ。
【請求項１３】
前記マルチキャスト転送テーブルは、前記グループ宛先と前記送信元識別子と前記シーケンス番号とを含む、
請求項１１に記載のマルチキャストメッセージのルーティング方法。
【請求項１４】
前記マルチキャスト転送テーブルは、前記グループ宛先と前記送信元識別子と前記シーケンス番号と前記メッセージと前記ＡＣＫフラグと前記再送時間値と前記再送カウンタと前記Ｔｉｍｅ−ｔｏ−Ｌｉｖｅ値とを含む、
請求項１０に記載のマルチキャストメッセージのルーティング方法。
【請求項１５】
転送後にＡＣＫフラグを未確認に設定するステップと、
再送時間を所定時間に設定するステップと、
をさらに含む、請求項１１に記載のマルチキャストメッセージのルーティング方法
【請求項１６】
再送カウンタを増加させるステップをさらに含む、
請求項１１に記載のマルチキャストメッセージのルーティング方法。
【請求項１７】
前記メッセージが以前に受信されたものである場合に、少なくとも同一のメッセージと送信元識別子とシーケンス番号とマルチキャストグループ宛先とを含む第２のマルチキャストメッセージを下流ノードから受信したときに、前記再送時間を停止するステップをさらに含む、
請求項１５に記載のマルチキャストメッセージのルーティング方法。
【請求項１８】
前記再送時間を停止した後に、ＡＣＫフラグを確認済みに設定するステップをさらに含む、
請求項１５に記載のマルチキャストメッセージのルーティング方法。
【請求項１９】
再送カウンタの値に基づいて、再送の上限に達したか判断するステップと、
前記判断に基づいて、前記再送時間が満了したときに、前記マルチキャストメッセージを再送するステップと、
再送カウンタを増加させるステップと、
再送後に前記再送時間を所定時間に設定するステップと、
をさらに含み、
再送の上限に達した場合には、再送時間が停止される、
請求項１５に記載のマルチキャストメッセージのルーティング方法。
【請求項２０】
少なくともメッセージと送信元識別子とシーケンス番号とＴｉｍｅ−ｔｏ−Ｌｉｖｅ値とマルチキャストグループ宛先とを含むマルチキャストメッセージを受信するステップと、
前記マルチキャストグループ宛先がマルチキャスト転送テーブル内に存在するか判断するステップと、
前記メッセージが以前に受信したものであるか判断するステップと、
を含み、
前記メッセージが以前に受信されたものである場合に、
前記Ｔｉｍｅ−ｔｏ−Ｌｉｖｅ値にプリセット値を加えてオフセットＴｉｍｅ−ｔｏ−Ｌｉｖｅ値を生成する工程と、
前記オフセットＴｉｍｅ−ｔｏ−Ｌｉｖｅ値と前記マルチキャスト転送テーブル内のＴｉｍｅ−ｔｏ−Ｌｉｖｅ値を比較する工程と、
前記オフセットＴｉｍｅ−ｔｏ−Ｌｉｖｅ値が前記マルチキャスト転送テーブル内のＴｉｍｅ−ｔｏ−Ｌｉｖｅ値以上である場合に、前記マルチキャストメッセージを転送することなく破棄する工程と、
を含む、マルチキャストメッセージのルーティング方法。
【請求項２１】
前記マルチキャストメッセージが以前に受信したものではない場合に、
ＡＣＫフラグを未確認に設定する工程と、
再送カウンタを増加させる工程と、
再送時間を所定値に設定する工程と、
マルチキャストメッセージを転送する工程と、
をさらに含む、請求項２０に記載のマルチキャストメッセージのルーティング方法。
【請求項２２】
前記オフセットＴｉｍｅ−ｔｏ−Ｌｉｖｅ値が前記マルチキャスト転送テーブル内のＴ
ｉｍｅ−ｔｏ−Ｌｉｖｅ値よりも小さい場合に、
ＡＣＫフラグを確認済みに設定する工程と、
前記再送時間を停止する工程と、
をさらに含む、請求項２０に記載のマルチキャストメッセージのルーティング方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４Ａ】
【図１４Ｂ】
【図１５Ａ】
【図１５Ｂ】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４Ａ】
【図１４Ｂ】
【図１５Ａ】
【図１５Ｂ】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【公表番号】特表２０１１−５１５０３７（Ｐ２０１１−５１５０３７Ａ）
【公表日】平成２３年５月１２日（２０１１．５．１２）
【国際特許分類】
【出願番号】特願２０１０−５４６８８５（Ｐ２０１０−５４６８８５）
【出願日】平成２１年２月１２日（２００９．２．１２）
【国際出願番号】ＰＣＴ／ＵＳ２００９／０３３８７９
【国際公開番号】ＷＯ２００９／１０２８４１
【国際公開日】平成２１年８月２０日（２００９．８．２０）
【出願人】（３９９０４７９２１）テルコーディア テクノロジーズ インコーポレイテッド (61)
【出願人】（５０７３０２９００）トヨタ インフォテクノロジー センター，ユー．エス．エー．，インコーポレイテッド (10)
【Ｆターム（参考）】
【公表日】平成２３年５月１２日（２０１１．５．１２）
【国際特許分類】
【出願日】平成２１年２月１２日（２００９．２．１２）
【国際出願番号】ＰＣＴ／ＵＳ２００９／０３３８７９
【国際公開番号】ＷＯ２００９／１０２８４１
【国際公開日】平成２１年８月２０日（２００９．８．２０）
【出願人】（３９９０４７９２１）テルコーディア テクノロジーズ インコーポレイテッド (61)
【出願人】（５０７３０２９００）トヨタ インフォテクノロジー センター，ユー．エス．エー．，インコーポレイテッド (10)
【Ｆターム（参考）】
[ Back to top ]