JP5364728B2 - ローカル・ピア・グループ(lpg)に基づく車両アドホックネットワークにおける高信頼度マルチキャスト方法 - Google Patents

ローカル・ピア・グループ(lpg)に基づく車両アドホックネットワークにおける高信頼度マルチキャスト方法 Download PDF

Info

Publication number
JP5364728B2
JP5364728B2 JP2010546885A JP2010546885A JP5364728B2 JP 5364728 B2 JP5364728 B2 JP 5364728B2 JP 2010546885 A JP2010546885 A JP 2010546885A JP 2010546885 A JP2010546885 A JP 2010546885A JP 5364728 B2 JP5364728 B2 JP 5364728B2
Authority
JP
Japan
Prior art keywords
multicast
node
message
group
time
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2010546885A
Other languages
English (en)
Other versions
JP2011515037A (ja
JP2011515037A5 (ja
Inventor
ウェイ チェン
ジョン リー
亮吉 大西
敏朗 疋田
Original Assignee
テルコーディア テクノロジーズ インコーポレイテッド
トヨタ インフォテクノロジー センター,ユー.エス.エー.,インコーポレイテッド
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by テルコーディア テクノロジーズ インコーポレイテッド, トヨタ インフォテクノロジー センター,ユー.エス.エー.,インコーポレイテッド filed Critical テルコーディア テクノロジーズ インコーポレイテッド
Publication of JP2011515037A publication Critical patent/JP2011515037A/ja
Publication of JP2011515037A5 publication Critical patent/JP2011515037A5/ja
Application granted granted Critical
Publication of JP5364728B2 publication Critical patent/JP5364728B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/02Details
    • H04L12/16Arrangements for providing special services to substations
    • H04L12/18Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/189Arrangements for providing special services to substations for broadcast or conference, e.g. multicast in combination with wireless systems
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/16Multipoint routing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W40/00Communication routing or communication path finding
    • H04W40/02Communication route or path selection, e.g. power-based or shortest path routing

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Traffic Control Systems (AREA)

Description

[関連出願の相互参照]
本発明は、共同所有され同時に係属中である、アドホック無線ネットワークにおけるユニキャストおよびマルチキャストメッセージをルーティングするための方法および通信装置と題する、2006年10月23日出願の出願番号第11/585,047の米国特許出願(「’047出願」)に関連する。
[技術分野]
この発明は、移動環境における通信ネットワークに関連する。より具体的には、本発明は、複数の移動装置間のマルチホップ・マルチキャストメッセージをルーティングするための方法に関連する。
無線ホームネットワークや、無線オフィスネットワークや、ローカルカフェ、ファーストフードチェーン又はホテルにおけるいわゆる「ホットスポット」ネットワークや、さらには都市全体でのWiFi技術の実現であれ、無線技術は今日の生活のあらゆる面において一般的なものとなっている。社会においてこのように無線を推し進める目的は、情報へのアクセスを提供し、社会全体がコンピュータネットワーク、特にインターネットを広く受け入れるとともに利用することで享受してきた生産性をさらに向上させるためである。
無線通信社会になるという願望は、移動車両のような移動装置にまで広がっている。この種の無線通信ネットワークは、限定はしないが、緊急路上障害物警告、交差点での協調、隠れた車道に関する警告、車線変更または合流の支援などを含む、車両安全アプリケーションの多くの態様において現れる。
車両安全通信(「VSC」)は大きく分類して、車車間通信とインフラ協調車両通信とに分けることができる。車車間通信では、固定インフラストラクチャからの支援なしに車両同士がお互いに通信する。車両同士が同じ無線通信範囲内に位置する場合や、他の車両を介したマルチホップ通信が可能な場合に、車両同士がお互いに通信する。インフラ協調車両通信では、路側無線アクセスポイントなどのインフラストラクチャの支援を受けて、車両同士がお互いに通信する。この場合、車両はインフラストラクチャのみと通信することもできる。
衝突回避のような種々のVSCアプリケーションを支援するために、重要なVSC性能要件には、遅延時間が短いこと(100ミリ秒のオーダー)と、スループット(近くの車両が警告メッセージを受信に成功する確率と同等)を維持することが含まれる。
’047出願には、1台の移動車両をグループヘッダとして選択し、このグループヘッダを利用してローカル・ピア・グループを維持し、ローカルルーティング情報を生成することで、移動車両のグループをローカル・ピア・グループに組織化することが記述されている。移動車両はユニキャストおよびマルチキャストのルーティングに適合される。しかしながら依然として、スループットをさらに向上し遅延が少ないマルチキャストのルーティング方法に対する要求がある。
したがって、マルチキャストメッセージのルーティング方法が開示される。この方法は
、少なくともメッセージと送信元識別子とシーケンス番号とTime−to−Live値とマルチキャストグループ宛先とを含むマルチキャストメッセージを受信するステップと、前記マルチキャストグループ宛先がマルチキャスト転送テーブル内に存在するか判断するステップと、前記メッセージが以前に受信したものであるか判断するステップと、前記メッセージが以前に受信したものではないと判断された場合に、前記マルチキャストメッセージを前記マルチキャスト転送テーブルに追加するステップと、前記マルチキャストメッセージを受信したノードが転送ノードであるか判断するステップと、前記マルチキャストメッセージを転送するための待機時間をランダムに設定するステップと、前記待機時間が満了したときに、前記マルチキャストメッセージを転送するステップと、を含む。
前記メッセージが以前に受信したものである場合に、少なくとも同一のメッセージと送信元識別子とシーケンス番号とマルチキャストグループ宛先とを含む第2のマルチキャストメッセージを前記ランダムに設定された待機時間内に下流ノードから受信したときは、前記待機時間を停止する。待機時間が停止された場合は、マルチキャストメッセージは転送されない。
第2のマルチキャストメッセージが下流ノードから受信されたかの判断は、第2のマルチキャストメッセージからTime−to−Live値を抽出する工程と、前記Time−to−Live値にプリセット値を加えてオフセットTime−to−Live値を生成する工程と前記マルチキャスト転送テーブルから同一のメッセージを含むマルチキャストメッセージのTime−to−Live値を取り出す工程と、前記オフセットTime−to−Live値と前記取り出されたTime−to−Live値とを比較する工程とを含み、前記取り出されたTime−to−Live値が前記オフセットTime−to−Live値よりも大きい場合に、前記待機時間が停止される。
前記取り出されたTime−to−Live値が前記オフセットTime−to−Live値と等しい場合は、前記待機時間はランダム値にリセットされる。
本方法は、転送後にACKフラグを未確認に設定するステップと、再送時間を所定時間に設定するステップと、をさらに含む。前記メッセージが以前に受信されたものである場合に、本方法は、少なくとも同一のメッセージと送信元識別子とシーケンス番号とマルチキャストグループ宛先とを含む第2のマルチキャストメッセージを下流ノードから受信したときは、前記再送時間を停止するステップをさらに含む。前記再送時間を停止した後に、ACKフラグを確認済みに設定される。
本方法は、前記再送時間が満了したときに、前記マルチキャストメッセージを再送するステップと、再送後に前記送信時間を所定時間に設定するステップと、をさらに含む。
本方法は、再送の上限に達したか判断するステップと、前記判断に基づいて、前記再送時間が満了したときに、前記マルチキャストメッセージを再送するステップと、再送カウンタを増加させるステップと、再送後に前記再送時間を所定時間に設定するステップと、をさらに含む。再送の上限に達した場合には、再送時間が停止される。
前記マルチキャスト転送テーブルは、前記グループ宛先と前記送信元識別子と前記シーケンス番号と前記メッセージと前記ACKフラグと前記再送時間値と前記再送カウンタと前記Time−to−Live値とを含む。
マルチキャストメッセージをルーティングするための別の方法も開示される。本方法は、少なくともメッセージと送信元識別子とシーケンス番号とTime−to−Live値とマルチキャストグループ宛先とを含むマルチキャストメッセージを受信するステップと
、前記マルチキャストグループ宛先がマルチキャスト転送テーブル内に存在するか判断するステップと、前記メッセージが以前に受信したものであるか判断するステップと、前記マルチキャストメッセージが以前に受信したものではないと判断された場合に、前記マルチキャストメッセージを前記マルチキャスト転送テーブルに追加するステップと、前記マルチキャストメッセージを受信したノードがマルチキャスト受信ノードであるか判断するステップと、マルチキャスト受信ノードに確率値をランダムに割り当てるステップと、前記ランダムに割り当てられた確率値とプリセット確率閾値とを比較するステップと、前記比較に基づいて前記マルチキャストメッセージを転送するステップと、を含む。
本方法は、前記プリセット確率閾値を設定するステップをさらに含む。
前記マルチキャスト転送テーブルは、前記グループ宛先と前記送信元識別子と前記シーケンス番号とを含む。
本方法は、転送後にACKフラグを未確認に設定するステップと、再送時間を所定時間に設定するステップと、をさらに含む。
本方法は、再送カウンタを増加させるステップをさらに含む。
前記メッセージが以前に受信されたものである場合に、本方法は、少なくとも同一のメッセージと送信元識別子とシーケンス番号とマルチキャストグループ宛先とを含む第2のマルチキャストメッセージを下流ノードから受信したときに、前記再送時間を停止する工程をさらに含む。
前記再送時間を停止した後に、ACKフラグを確認済みに設定される。
本方法は、再送カウンタの値に基づいて、再送の上限に達したか判断するステップと、前記判断に基づいて、前記再送時間が満了したときに、前記マルチキャストメッセージを再送するステップと、再送カウンタを増加させるステップと、再送後に前記再送時間を所定時間に設定するステップと、をさらに含む。再送の上限に達した場合には、再送時間が停止される。
マルチキャストメッセージをルーティングするための別の方法も開示される。本方法は、少なくともメッセージと送信元識別子とシーケンス番号とTime−to−Live値とマルチキャストグループ宛先とを含むマルチキャストメッセージを受信するステップと、前記マルチキャストグループ宛先がマルチキャスト転送テーブル内に存在するか判断するステップと、前記メッセージが以前に受信したものであるか判断するステップと、を含み、前記メッセージが以前に受信されたものである場合に、前記Time−to−Live値にプリセット値を加えてオフセットTime−to−Live値を生成する工程と、前記オフセットTime−to−Live値と前記マルチキャスト転送テーブル内のTime−to−Live値を比較する工程と、前記オフセットTime−to−Live値が前記マルチキャスト転送テーブル内のTime−to−Live値以上である場合に、前記マルチキャストメッセージを破棄する工程と、を含む。
前記マルチキャストメッセージが以前に受信したものではない場合に、本方法は、ACKフラグを未確認に設定する工程と、再送カウンタを増加させる工程と、再送時間を所定値に設定する工程と、マルチキャストメッセージを転送する工程と、を含む。
前記オフセットTime−to−Live値が前記マルチキャスト転送テーブル内のTime−to−Live値よりも小さい場合に、本方法は、ACKフラグを確認済みに設
定する工程と、前記再送時間を停止する工程と、をさらに含む。
本発明のこれらおよび他の特徴、利益や利点は、以下の図面を参照することによって明らかになる。なお、図面を通して、類似の参照符号は類似の構造を指している。
図1は、マルチキャストメッセージ用に設定されたローカル・ピア・グループの例を説明する。 図2は、ハートビートメッセージの例を説明する。 図3は、メンバシップレポートメッセージの例を説明する。 図4は、本発明の第1の実施形態に係るマルチキャストパケットのルーティング方法を説明する。 図5は、本発明の第1の実施形態に係る、転送ノードおよびマルチキャスト受信ノードのためのMPキャッシュテーブルの例を説明する。 図6は、本発明の第2の実施形態に係るマルチキャストパケットのルーティング方法を説明する。 図7は、本発明の第2の実施形態に係るルーティング方法の例を説明する。 図8は、本発明の第3の実施形態に係るマルチキャストパケットのルーティング方法を説明する。 図9は、本発明の第3の実施形態に係るマルチキャストパケットのルーティング方法を説明する。 図10は、本発明の第3の実施形態に係るマルチキャストパケットのルーティング方法を説明する。 図11は、本発明の第3の実施形態に係る、転送ノードのためのMPキャッシュテーブルの例を説明する。 図12は、本発明の第4の実施形態に係るマルチキャストパケットのルーティング方法を説明する。 図13は、本発明の第4の実施形態に係るマルチキャストパケットのルーティング方法を説明する。 図14Aは、本発明の第4の実施形態に係るマルチキャストパケットのルーティング方法を説明する。 図14Bは、本発明の第4の実施形態に係るマルチキャストパケットのルーティング方法を説明する。 図15Aは、本発明の第4の実施形態に係る、転送ノードのためのMPキャッシュテーブルの例を説明する。 図15Bは、本発明の第4の実施形態に係る、マルチキャスト受信ノードのためのMPキャッシュテーブルの例を説明する。 図16は、本発明の第5の実施形態に係るマルチキャストパケットのルーティング方法を説明する。 図17は、本発明の第6の実施形態に係る、マルチキャスト受信ノードによるマルチキャストパケットのルーティング方法を説明する。 図18は、本発明の第7の実施形態に係るマルチキャストパケットのルーティング方法を説明する。 図19は、本発明の第8の実施形態に係るマルチキャストパケットのルーティング方法を説明する。 図20は、本発明の第9の実施形態に係るマルチキャストパケットのルーティング方法を説明する。 図21は、本発明の第7〜第9の実施形態の係る、転送ノードのためのMPキャッシュテーブルの例を説明する。
[定義]
「ノード」は、チャネルの決定・選択処理や以下の説明で記載される方法を実行するルータである。例えば、通信装置を備える移動車両はノードである。この出願では、ノードと移動車両は同じ意味で使われている。
「マルチキャストメッセージ」は1つまたはそれ以上の宛先を持つメッセージである。詳細な説明では、マルチキャストメッセージはマルチキャストパケット(MP)と称される。「ホップ」はメッセージを中継するノードである。2ノード間、すなわち送信元と宛先の間の「ホップカウント」は、中継ノードの数に1を足したものに等しい。
本発明によれば、ローカル・ピア・グループ(LPG)に組織化されたノードまたは移動車両は、マルチキャストルーティングテーブルを生成するために相対位置、一意の識別子、LPGに関する情報を交換する。後述するハートビートメッセージやメンバシップレポートメッセージのような制御パケット内の情報に基づいて、ルーティングテーブルが生成される。マルチキャストは、1つのマルチキャストセッションについて複数の送信元ノード700とマルチキャスト受信ノード20に対応する。
LPG1は、近くの複数のノード10から動的に形成される。具体的には、第1のノードが無線信号をブロードキャストし、第1のノードの範囲内の他のノード10は、この無線信号を受信する能力がある。LPG1は無線通信範囲に基づいて形成されるので、LPG1内のノードは、固定インフラストラクチャを必要とせずに、1ホップまたはマルチホップで互いに通信できる。ハートビートメッセージおよびメンバシップレポートの送信に基づいて、LPG1は形成および維持される。
図1は、マルチキャストメッセージ用に設定されたモードを持つLPG1を示す。マルチキャストを行うために、ノード10は、マルチキャスト受信ノードと転送ノード90の2つのグループに分けられる。マルチキャスト受信ノード20はマルチキャストメッセージの受信が意図されるノードである。転送ノード90はメッセージを転送する。LPG1内の全てのノード10は、転送ノードにもマルチキャスト受信ノード20にもなりうる。さらに、LPG1内の1つのノードがグループヘッダ(GH)として選択される。GHは、他のノードやインフラストラクチャからの命令なしにLPG1を維持および制御することを指定されたLPG1内の移動装置またはノード10である。ノード10は、メンバシップレポートをGHへ中継するために用いられるときに、FN90になる。LPG1の形成、維持、GHの選択、制御は’047出願に記載されており、その内容は参照により本明細書に含まれる。
図2は、本発明に係るハートビートメッセージ200の例を示す。GHは、ハートビートメッセージ200を定期的に送出して、LPG1を識別(identify)するとともにLPG1に関する情報を提供する。この周期は固定間隔(T)である。この間隔(T)の値は、設計や運用の要求に基づいて選択可能である。GHは、LPG1に含まれる全ノードのリストの維持も行う。このリストには、ノードがLPG1に参加した時のタイムスタンプ、あるいは、GHがノードからステータス更新を受信した時のタイムスタンプが含まれる。このリストは、LPG1に対する種々の維持・管理機能のために用いられる。例えば、このリストは、グループサイズを追跡したり、マルチキャストルーティングテーブルを作成・更新したり、ヘッダ解決のために用いることができる。さらに、このリストは、LPG1内の他の全てのノードに周期的にブロードキャストされる。ハートビートメッセージ200がLPG1内の全ノード10にブロードキャストされる。
ハートビートメッセージ200は、LPG1の識別子、GH ID、シーケンス番号、
ハートビートメッセージの種類(例えば、完全なグループリスト付きのハートビートか、増分(incremental)グループリスト付きのハートビートか、グループリストなしのハートビートか)を含む。ある実施形態では、ハートビートメッセージは全てのパケットにおいて完全なグループリストを含む。完全なグループリストを使うことが、ルーティング制御と正しいグループメンバのリストを維持するための最も正確な方法であるが、完全なグループ付きのハートビートのためには相当量の帯域幅が必要となる。別の実施形態では、ハートビートメッセージ200は、n回おきに完全なグループリストを含む。例えば、3回おきにハートビートが完全なグループリストを含むようにする。ToHbは、ハートビートメッセージの種類を意味する。ハートビートメッセージの種類は、LPG1のトポロジー変化の早さとハートビートのブロードキャスト頻度の影響を受ける。LPG1のトポロジー変化速度が速くなると、全てのハートビートメッセージ200に完全なグループリストを含める必要性が高まる。
ハートビートメッセージ200は、GHからのホップカウント(HC)も含む。最初は、HCは所定値、たとえば1に設定される。ハートビートメッセージ200がノードによって中継されるたびに、中継ノードがHC値を1増加させる。すなわち、HC=HC+1とする。HC値は、LPGのサイズを限定したり、ハートビートメッセージ200内の情報の古さを示したり、オーバヘッドを減らすための制御パケットのルーティングを制御したりするために用いることができる。各LPG1に対して、ルーティングの最大ホップカウント(例えば10)がある。HCが最大ホップカウントに達すると、その制御パケットはそれ以上中継されない。
最大ホップカウント、HCおよびシーケンス番号を用いることで、LPG1内で制御パケットが無限に複製されることを防止できる。ホップカウントは中継戦略のためにも利用される。ノードがハートビートメッセージを転送するときにメッセージにID情報を含めるので、次ホップのノードは、このハートビートメッセージ200を誰が中継するのかを知ることができる。
上述したように、ハートビートメッセージ200はグループリストも含むことができる。グループリストは、LPG1のメンバに関する情報を含むことができる。たとえば、LPG1内のメンバ数、各メンバのIPアドレス、GHからのホップカウントや分類などである。
分類は、たとえばアップリンク、ダウンリンク、ピアのような、GHからの相対的な方向を示すコードであり得る。ピア分類は、ノードがGHと同じ無線通信範囲内であることを示す。すなわち、全てのピアノードは、GHから同じホップカウントを有する。上流ノードはハートビートから決定される。下流ノードは、後述するメンバシップレポート(MR)300に基づいて決定される。上流送信はGH25に向かう方向の通信を意味し、下流送信はGH25からの離れる方向の通信を意味する。分類は相対的な用語である。各ノードはその近隣ノードを異なる3つの種類に分けることができる。他のノードのメンバシップレポートのホップカウント(HC)が自ノードのHCよりも1少なければ、自ノードは上流ノードである。そのHCが自身のHCと同じであれば、自ノードはピアである。そのHCが自身のHCよりも1大きければ、自ノードは下流ノードである。
図3はメンバシップレポート(MR)300の例を示す。MR300はGH以外のノードからブロードキャストされる制御パケットであり、その受取人はGH25である。MR300は、ハートビートメッセージ200に対する応答として生成される。MR300は、メンバシップリスト、下流ノードID、下流ノードに対する次ホップのような収集可能なルーティング情報を含む。MR300は、GIDやグループヘッダIDのような、ハートビートメッセージ200と同じ情報のいくつかを含む。MR300は、MRシーケンス
番号も含む。MRシーケンス番号は、ハートビートメッセージ200のシーケンス番号と同様のものであり、MRの順序を維持するために用いられる。MRシーケンス番号はある特定のノードに対するMRの順序である。典型的には、MRシーケンス番号は、MR300のきっかけとなったハートビートメッセージ200のシーケンス番号と同じ値を有する。
MR300には、発信元ノード、すなわち、MR300を生成したノードのノードIDも含まれる
MR300は次ホップ中継IDも含む。次ホップ中継IDは、GHへ向かうMR300に対する中継の指示である。次ホップの情報は、受信したハートビートメッセージ200から直接決定される。ノード10が新しいすなわち新規のハートビートメッセージ200を受信すると、何らかのパケット処理を行う前にIP層およびMAC層から直前の中継ノードのIDを取り戻す。直前の中継ノードのIDはメモリに格納され、MR300の次ホップ中継IDとして用いられる。ノード10がハートビートメッセージ200を転送するときは、ノード10は自身のIDをパケットに含める。これを受信する次ホップノードは、新しいすなわち新規のハードビートメッセージ200を受信すると、このIDをGH25に達するための次ホップ中継IDとして格納する。新しいすなわち最新のハートビートメッセージ200は、最も小さいHCと新しいシーケンス番号を有する。
MR300は「MR標識の種類」ToMRも含む。MR300には、単一メンバレポートおよび複数集約メンバレポート(aggregated multiple member report)の2つの種類がある。単一メンバMRは発信元ノードからのMR300のみを含む。複数集約メンバレポートは2つ以上のノードのMR300を含む。1つのMR300が複数のMRを含んで送られる。
さらに、MR300はGHからのホップカウント(HCGH)を含んでも良い。(HCGH)は、GHから発信ノードまでのMR300のHC値である。MR300は、報告ノードが利用可能なチャネルのリストを含む。さらに、MRは、MR300をGHに向かって中継した全ノードについての利用可能なチャネルのリストを含んでも良い。さらに、MR300は、その状態またはマルチキャストメッセージを中継可能であるか、すなわち転送ノードステータスを含む。
マルチキャストルーティングテーブルは、マルチキャストセッションが開始された後に、ハートビートメッセージ200およびMR300から作成される。マルチキャストルーティングテーブルは木構造またはメッシュとして視覚化するのが最も適切といえる。木構造またはメッシュは、任意の送信元ノード700からFNを介してマルチキャスト受信ノード20に至る経路またはリンクを提供する。マルチキャストセッションを確立するために、マルチキャストセッションに参加したいノード10はマルチキャストセッションに対応したマルチキャストアプリケーションプログラムを起動する。このアプリケーションプログラムはメモリに格納される。そして、ノードはFNかマルチキャスト受信ノードになり、セッション参加の要求を示す信号(MR300)を発する。これらの信号によって、マルチキャストセッションに対するマルチキャストツリーの生成が開始される。
ノードがMR300をGHに向かって中継すると、そのノードはマルチキャストグループのFN90になる。FN90は、ここで説明される1つまたはそれ以上の方法によって、マルチキャストセッションに関連づけられたマルチキャストパケットを受け付けて転送することができる。木構造またはメッシュ、すなわちマルチキャストルーティングテーブルは、ここに参照によって明示的に組み入れられる’047出願において説明されるいずれかの方法を用いて作成される。マルチキャストルーティングテーブルは、ハートビート
期間ごとに更新される。マルチキャストパケットはマルチキャストルーティングテーブルを用いて経路が定められる。
図4は、本発明の第1の実施形態に係るマルチキャストルーティング方法を示す。本ルーティング方法を、その機能ブロックを用いて説明する。異なる実施形態における同一の機能ブロックは、同一の番号を用いて参照される。
ブロック400で、マルチキャストパケットがノードに到着する。ブロック405で、ノード10はパケットからマルチキャストグループ識別子を抽出して、ノード10がマルチキャストセッションのメンバであるか判断する。この判断はマルチキャストルーティングテーブルに基づく。ノード10は、FN90かマルチキャスト受信ノード20のいずれかであれば、マルチキャストセッションのメンバである。ノード10がマルチキャストセッションのメンバでなければ、ブロック410で、それ以上の処理をせずにマルチキャストパケットは破棄される。ノード10がマルチキャストセッションのメンバであれば、ブロック415で、ノード10は、MPキャッシュテーブル(例えば図5、500)内に、受信したマルチキャストパケットと一致するものがあるか探す。本発明の第1の実施形態では、MPキャッシュテーブル500はFN90とマルチキャスト受信ノード20の両方に対して同一である。MPキャッシュテーブル500は、グループ識別子、送信元識別子、つまりマルチキャストパケットの元々の送信元ノード700、およびシーケンス番号を含む。パケットのシーケンス番号と送信元識別子の両方が同じであれば、マルチキャストパケットは受信パケットと同一である。マルチキャストパケットが同一であれば、ブロック410で、それ以上の処理をせずにマルチキャストパケットは破棄される。
マルチキャストパケットがMPキャッシュテーブル500内のいずれのパケットとも一致しない場合は、ブロック420で、ノード10は、グループ識別子、送信元識別子、マルチキャストパケットの順番のようなマルチキャストに関連する情報をMPキャッシュテーブル500に追加する。マルチキャストパケットがMPキャッシュテーブル500に加えられると、ブロック425で、ノード10はマルチキャストセッションのFN90であるか判断する。この判断はマルチキャストルーティングテーブルに基づく。ノード10がマルチキャストセッションのFN90でなければ、ブロック430で、マルチキャストパケットは破棄される。その後、ブロック440でノード10はアイドルになる。
ノード10がマルチキャストセッションのFN90であれば、ブロック435で、ノードはマルチキャストパケットをN回再マルチキャストすなわち転送する。ある実施形態では、FN90はマルチキャストパケットをN回連続して転送する。パケットが転送される数字「N」回は予め定められていて変更可能である。到達率の増加とデータオーバヘッドの増加にはトレードオフがある。数字「N」が増えるにしたがって、データオーバヘッドが著しく増加するが、到達率もまた増加する。別の実施形態では、FN90はパケットをN回同時に転送する。
マルチキャストパケットを転送した後、ブロック440で、FN90はアイドルになる。
図5は、本発明の第1の実施形態におけるMPキャッシュテーブル500の例を示す。図5に示すように、MPキャッシュテーブル500は、IPアドレスのようなセッションやグループの識別子である追加グループ(GroupAdd)、マルチキャストパケットの送信元ノード700の識別子である送信元識別子、およびパケットのシーケンス番号(SeqNum)を含む。
図6は、本発明の第2の実施形態に係るマルチキャストルーティング方法を示す。ブロ
ック400で、マルチキャストパケットがノード10に到着する。ブロック405で、ノード10はパケットからマルチキャストグループ識別子を抽出して、ノード10がマルチキャストセッションのメンバであるか判断する。この判断はマルチキャストルーティングテーブルに基づく。ノード10は、FN90かマルチキャスト受信ノード20のいずれかであれば、マルチキャストセッションのメンバである。ノード10がマルチキャストセッションのメンバでなければ、ブロック410で、それ以上の処理をせずにマルチキャストパケットは破棄される。ノード10がマルチキャストセッションのメンバであれば、ブロック415で、ノード10は、MPキャッシュテーブル内に、受信したマルチキャストパケットと一致するものがあるか探す。本発明の第2の実施形態では、MPキャッシュテーブル500はFN90と受信ノードの両方に対して同一である。MPキャッシュテーブル500は、グループ識別子、送信元識別子、およびシーケンス番号を含む。パケットのシーケンス番号と送信元識別子の両方が同じであれば、マルチキャストパケットは受信パケットと同一である。マルチキャストパケットが同一であれば、ブロック410で、それ以上の処理をせずにマルチキャストパケットは破棄される。
マルチキャストパケットがMPキャッシュテーブル500内のいずれのパケットとも一致しない場合は、ノード10は、ブロック420で、受信したマルチキャストパケットについての情報をMPキャッシュテーブル500に追加する。マルチキャストパケットに関連する情報がMPキャッシュテーブル500に加えられると、ブロック425で、ノード10はマルチキャストセッションのFN90であるか判断する。この判断はマルチキャストルーティングテーブルに基づく。ノード10がFN90であれば、ブロック605で、ノード10はマルチキャストパケットを一度転送する。ブロック440で、ノード10はアイドルになる。
ノード10がFN90でなければ、ノード10はマルチキャスト受信ノード20である。本実施形態によれば、FN90による通常の転送に加えて、いくつかのマルチキャスト受信ノード20がマルチキャストパケットの転送のために選択される。この追加的な転送によって、マルチキャストセッションのメンバがパケットを受信し損ねる可能性が抑えられる。受け取ったマルチキャストデータパケットごとに割り当てられる確率に基づいて、いくつかのマルチキャスト受信ノード20が選択される。各マルチキャスト受信ノード20は確率閾値とともにプログラムされる。確率閾値は0と1の間の値である。確率閾値は、複数のマルチキャスト受信ノード20について同じではない。ある実施形態では、確率閾値はランダムにプログラムされる。別の実施形態では、確率閾値は、LPG1内のノード10の数またはマルチキャストセッション内のノード数に基づいて割り当てられる。言い換えると、確率閾値は周期的に変化しても良い。ある実施形態では、マルチキャストセッションの送信元ノード700が確率閾値を割り当てても良い。代替として、GHが確率閾値を割り当てても良い。
ブロック600で、マルチキャスト受信ノード20であるノード10は、マルチキャストパケットに割り当てられたランダムな確率と、確率閾値とを比較する。マルチキャストパケットに割り当てられたランダムな確率が確率閾値よりも小さければ、ブロック605で、マルチキャスト受信ノードは受信したマルチキャストパケットを転送する。そして、ブロック440で、マルチキャスト受信ノード20はアイドルになる。
マルチキャストパケットに割り当てられたランダムな確率が確率閾値以上であれば、ブロック430で、マルチキャスト受信ノード20は受信したマルチキャストパケットを破棄する。そして、ブロック440で、マルチキャスト受信ノード20はアイドルになる。
図7は、本発明の第2の実施形態に係る方法を実行するマルチキャストセッションの例を示す。送信元ノード700がマルチキャストセッションを開始し、マルチキャストパケ
ットをマルチキャストする。FN1 901、FN2 902、およびFN3 903は、マルチキャストパケットを受信した後に、ブロック605で、マルチキャストパケットを転送する。マルチキャスト受信ノード201、202、203はマルチキャストデータパケットを転送せずにマルチキャストパケットを破棄する(ブロック430)。しかしながら、マルチキャスト受信ノード204、205、206は、マルチキャストパケットを転送する(ブロック605)。MPキャッシュテーブルは本発明の第1の実施形態と同様である(例えば、500)。MPキャッシュテーブル500は、FN90とマルチキャスト受信ノード20の両方に対して同一である。
図8〜図10は、本発明の第3の実施形態に係るルーティング方法を示す。本発明の第3の実施形態によれば、次ホップノードは転送されたマルチキャストパケットの受信通知を行う。この受信通知(acknowledgement)はパッシブ受信通知方式をとる。FN90によって転送されたマルチキャストパケットは、その次ホップFNによって転送されたマルチキャストパケットによって受信通知が行われる。次ホップFNから転送されたマルチキャストパケットは、傍受(overheard)される。
ブロック400で、マルチキャストパケットがノード10に到着する。マルチキャストパケットは、マルチキャストグループID、シーケンス番号、Time−to−Live(TTL)値、およびデータを含む。TTL値は、マルチキャストパケットが中継されるホップ数である。各ホップで、FN90はTTL値を減少させる。TTL値は、同一のマルチキャストデータパケットが転送させる回数を制限する機能を果たす。
ブロック405で、ノード10はパケットからマルチキャストグループ識別子を抽出して、ノード10がマルチキャストセッションのメンバであるか判断する。この判断はマルチキャストルーティングテーブルに基づく。ノード10がマルチキャストセッションのメンバでなければ、ブロック410で、それ以上の処理をせずにマルチキャストパケットは破棄される。ノード10がマルチキャストセッションのメンバであれば、ブロック800で、ノード10はFN90かマルチキャスト受信ノードであるかを判断する。ノード10がマルチキャスト受信ノードであれば、処理は図10のブロック415に移動する。ノード10がマルチキャストセッションのFN90であれば、ブロック415(図8)で、FN90はマルチキャストパケットがMPキャッシュテーブル(例えば、図11、500a)内にあるか判断する。
マルチキャストパケットがMPキャッシュテーブル500a内のいずれのパケットとも一致しない場合は、ブロック420で、FN90は受信したマルチキャストパケットをMPキャッシュテーブル500aに追加する。この実施形態では、マルチキャストパケットに関連する情報とパケットの両方がMPキャッシュテーブル500aに追加される。
FN90は、マルチキャストグループID、シーケンス番号、送信元識別子、Time−to−Live(TTL)値、およびデータを抽出し、この情報をMPキャッシュテーブル500aに付加する。さらに、FN90は再送カウンタをゼロに初期化する。再送カウンタ(s_mp_c)は、マルチキャストパケットが再送されうる回数を表す。ある実施形態では、マルチキャストメッセージが再送される回数はあらかじめ定められた最大値に制限される。あらかじめ定められた最大値は全ノード10に対して同じであっても良い。別の実施形態では、あらかじめ定められた最大値はGHや送信元ノード700のような特定のノードに対して変更可能としても良い。
MPキャッシュテーブルはFN90とマルチキャスト受信ノードとで異なる。FN90用には、MPキャッシュテーブル500は、マルチキャストパケットについてのマルチキャストセッションID、送信元識別子、シーケンス番号、マルチキャストパケットデータ
、ACK状態、再送タイマ値、再送カウンタ、およびTTL値を含む。ACK状態は「未確認」または「確認済み」のいずれかであり得る。再送タイマ値はオンかオフのいずれかであり得る。タイマがオンであれば、再送タイマ値は初期設定タイマ値といつ再送タイマ値が満了したかの指示も含む。マルチキャスト受信ノード20用には、MPキャッシュテーブル500は、マルチキャストセッションID、送信元識別子、およびシーケンス番号だけを含む。
ブロック805で、FN90はACK状態を「未確認」に初期化する。FN90はどのマルチキャストパケットが受信確認され受信されたかを追跡できる。さらに、FN90は再送タイマ値をオンに初期化し、タイマを再送時間に設定する。再送時間は、データパケットに含まれるデータの種類、FN90の移動速度、およびその他のユーザ定義の基準に応じて変更可能である。例えば、12msの再送時間を利用することができる。メッセージに含まれるデータが高い優先度のメッセージであれば、再送時間を短くしても良い。あるいは、メッセージが低い優先度のメッセージであれば、再送時間を長くしても良い。回復遅延は再送時間の値に依存する。再送時間が小さいほど、遅延は短くなる。しかしながら、小さくしすぎると多くの再送信が発生し、不必要な再送信が生じる。
ブロック810で、再送カウンタが1増分する。すなわちs_mp_c+1にする。再送カウンタが増分された後、ブロック605で、FN90はマルチキャストパケットを一度転送する。FN90は、転送の前にマルチキャストパケットのTTL値から1減算する。したがって、次ホップFNによって受信されるマルチキャストパケットは、最小のTTL値を持つ。ブロック440で、FN90はアイドルになる。
マルチキャストパケットがMPキャッシュテーブル500a内のいずれかのパケットと同一であれば、本方法はブロック815へ進む。
FN90は入力マルチキャストパケットのTTL値を判断する。上記したようにTTL値は特定のマルチキャストパケットのホップ数を制御するために用いられる。さらにこの実施形態では、TTL値は送信ノード10および受信ノード10の相対的な位置を決定するためにも用いられる。具体的には、マルチキャストパケットが転送されるたびに、ノード10はTTL値から1減算する(すなわち、TTL−1)。特定のFN90から下流にあるノード10から受信されたマルチキャストパケットのTTL値は、FN90から転送された同一のマルチキャストパケットのTTL値よりも小さい。特定のFN90から上流にあるノード10から受信されたマルチキャストパケットのTTL値は、FN90から転送された同一のマルチキャストパケットのTTL値よりも大きい。特定のFN90と同じホップ数のノード10から受信されたマルチキャストパケットは、同一のTTL値を持つ。
FN90は、FN90による最初のマルチキャストパケットの転送を補うために、判定されたTTL値にオフセット値の1を加える。これによりオフセットTTL値が生成される。
ブロック815で、FN90は、入力パケットのオフセットTTL値(In_MP_TTL+1)と同一のマルチキャストパケットのTTL値とを比較する。同一のマルチキャストパケットのTTL値は、MPキャッシュテーブル500aから取り出される。MPキャッシュテーブル500aから取り出されたTTL値がオフセット値よりも大きくない場合は、ブロック430で、入力マルチキャストパケットは無視されて破棄される。このマルチキャストパケットは上流ノードから発生したものである。マルチキャストパケットの転送は受信確認されない。ブロック440で、FN90はアイドルになる。
ブロック815においてMPキャッシュテーブルから取り出されたTTL値がオフセット値よりも大きい場合は、ブロック820で、FN90はこのマルチキャストパケットがすでに受信確認されたか判断する。
FN90はMPキャッシュテーブル500aから同一のマルチキャストパケットについてのACK状態を取り出す。同一のマルチキャストパケットがすでに受信確認されていれば、ブロック430で、入力マルチキャストパケットは無視されて破棄される。ブロック440で、FN90はアイドルになる。MPキャッシュテーブル500aに変更はない。ブロック820において同一のマルチキャストパケットが受信確認されていなければ、本方法はブロック825へ進む。
ブロック825で、FN90は再送タイマを停止する。さらに、FN90は、キャッシュテーブル500a内の再送タイマ値を「オフ」に変え、ACK状態を「確認済み」に変える。その後、ブロック430で入力マルチキャストパケットは破棄される。ブロック440で、FN90はアイドルになる。マルチキャストパケット転送の受信が確認される。
図9は、マルチキャストパケットの転送が受信確認される前に再送タイマが満了する場合の機能ブロック図を示す。図9に示される機能ブロック図はFN90によってのみ実行される。
ブロック900で、再送タイマが満了する。FN90は、再送カウンタが最大閾値に達したか判断する。FNは、再送タイマが満了したパケットに対応するマルチキャストパケットの再送カウンタをMPキャッシュテーブル500aから抽出する。再送カウンタは、最大閾値と比較される。再送カウンタが最大閾値以上であれば、FN90はブロック440でアイドルになる。
再送カウンタが最大閾値より小さければ、ブロック805で、FN90はマルチキャストパケットの再送タイマをリセットし、マルチキャストパケットのACK状態を「未確認」に初期化する(図9において「Not ACKed」と示される)。
ブロック810で、再送カウンタが1増分する。すなわちs_mp_c+1にする。再送カウンタが増分された後、ブロック605で、FN90はマルチキャストパケットを一度転送する。FN90は、転送の前にマルチキャストパケットのTTL値から1減算する。したがって、次ホップFNはマルチキャストパケットを送っているFN90よりも小さいTTLを持つマルチキャストパケットを受信する。ブロック440で、FN90はアイドルになる。
図10は、本発明の第3の実施形態に係るマルチキャスト受信ノード20の機能ブロックを示す。図8に示すように、ブロック800においてノード10がFN90でなければ、処理は図10のブロック415に進む。ブロック415で、マルチキャスト受信ノード20は、入力マルチキャストパケットがMPキャッシュテーブル500にリストされているか判断する。マルチキャストパケットがすでにリストされていれば、ブロック430で、パケットは無視されて破棄される。ブロック440で、マルチキャスト受信ノード20はアイドルになる。
マルチキャストパケットがMPキャッシュテーブル500内のいずれのパケットとも一致しない場合は、マルチキャスト受信ノード20は、ブロック420で、入力マルチキャストパケットについての情報をMPキャッシュテーブル500に追加する。具体的には、マルチキャスト受信ノード20は、マルチキャストパケットのマルチキャストセッションID、送信元識別子、およびシーケンス番号をMPキャッシュテーブル500に追加する
。その後、ブロック430で、マルチキャストパケットは破棄される。ブロック440で、マルチキャスト受信ノード20はアイドルになる。
図11は、本発明の第3の実施形態に係るFN用のMPキャッシュテーブル500aの例を示す。図示されるように、MPキャッシュテーブル500aは、2つの異なるマルチキャストパケット(MP1とMP2)を含む。各マルチキャストパケットに対して、MPキャッシュテーブル500aは、マルチキャストセッションID(GroupAdd)、マルチキャストパケットの送信元識別子、マルチキャストパケットのシーケンス番号(SeqNum)、マルチキャストパケットデータ(MPキャッシュ)、受信確認状態(ACK状態)、再送タイマ(Retran_Timer)、再送カウンタ(s_mp_c)、およびマルチキャストパケットのTTL値(C_MP_TTL)を含む。図11に示されるように、マルチキャストパケットの1つは受信確認されており、したがって再送タイマ状態は「オフ」である。
図12〜図14(AおよびB)は、本発明の第4の実施形態に係るルーティング方法を示す。この実施形態によれば、マルチキャスト受信ノード20は受信し損ねたマルチキャストパケットを局所的に回復することができる。マルチキャスト受信ノード20は否定的確認(negative acknowledgement)を用いて、他のノード10にマルチキャストパケットを受信していないことを通知する。受信し損ねたマルチキャストパケットは、受信パケットにおける欠落しているシーケンス番号に基づいて検出される。この検出は受信したマルチキャストパケットの間でのシーケンス番号の比較に基づく。
ブロック400で、マルチキャストパケットがノード10に到着する。マルチキャストパケットはマルチキャストグループID、送信元識別子、シーケンス番号、Time−to−Live(TTL)値、およびデータを含む。TTL値は、マルチキャストパケットが中継されるホップ数である。各ホップで、FN90はTTL値を減少させる。TTL値は、同一のマルチキャストデータパケットが転送させる回数を制限する機能を果たす。
ブロック405で、ノード10はパケットからマルチキャストグループ識別子を抽出して、ノード10がマルチキャストセッションのメンバであるか判断する。この判断はマルチキャストルーティングテーブルに基づく。ノード10がマルチキャストセッションのメンバでなければ、ブロック410で、それ以上の処理をせずにマルチキャストパケットは破棄される。ノード10がマルチキャストセッションのメンバであれば、ブロック800で、ノード10はFN90かマルチキャスト受信ノードであるかを判断する。ノード10がマルチキャスト受信ノード20であれば、処理は図13のブロック415に移動する。
ブロック415で、マルチキャスト受信ノード20は、MPキャッシュテーブル(例えば、図15B、500c)内に入力マルチキャストパケットがリストされているか判断する。
マルチキャストパケットがMPキャッシュテーブル500c内のいずれのパケットとも一致しない場合は、マルチキャスト受信ノード20は、受信したマルチキャストパケットについての情報をMPキャッシュテーブル500cに追加し、ブロック1300でマルチキャストパケットが不足していないか判断する。マルチキャスト受信ノード20は、マルチキャストセッションID、送信元識別子、シーケンス番号、およびマルチキャストパケットデータをMPキャッシュテーブル500cに追加する。マルチキャスト受信ノード500cのMPキャッシュテーブル500cは、ネガティブACK再送タイマ(NACK再送タイマ:NACK_Retran_Timer)も含む。NACK再送タイマは、近くのFN90やマルチキャスト受信ノード20から同一のマルチキャストパケットが複数回再送信される回数を抑制または制限するために用いられる。
NACK再送タイマの時間は、ノード数、データパケットに含まれるデータの種類、ノード10の移動速度、およびその他のユーザ定義の基準に応じて変更可能である。例えば、12msの再送時間を利用することができる。メッセージに含まれるデータが高い優先度のメッセージであれば、再送時間を短くしても良い。あるいは、メッセージが低い優先度のメッセージであれば、再送時間を長くしても良い。回復遅延は再送時間の値に依存する。再送時間が小さいほど、遅延は短くなる。しかしながら、小さくしすぎると多くの再送信が発生し、不必要な再送信が生じる。
マルチキャスト受信ノード20は、受信した全てのマルチキャストパケットについてシーケンス番号を調べることで、受信し損ねたマルチキャストパケットを検出する。検出はブロック1305で行われる。例えば、マルチキャスト受信ノード20がシーケンス番号10、11、13のマルチキャストパケットを受信した場合、シーケンス番号12のマルチキャストパケットが抜けている。
ブロック1305においてマルチキャストパケットが抜けている場合、マルチキャスト受信ノード20は、ブロック1310で、ネガティブACK(NACK)をマルチキャストする。
NACKは、抜けているマルチキャストパケットのマルチキャストセッションID、送信元識別子、およびシーケンス番号を含む。その後、ブロック430で、入力マルチキャストパケットは破棄される。ブロック440で、マルチキャスト受信ノード20はアイドルになる。
ブロック1305でマルチキャストパケットが抜けていない場合、ブロック430で、マルチキャスト受信ノード20は入力マルチキャストパケットを棄てる。ブロック440で、マルチキャスト受信ノード20はアイドルになる。
ブロック415においてマルチキャストパケットがMPキャッシュテーブル500c内のいずれかのパケットと同一であれば、ブロック1200で、マルチキャスト受信ノード20はマルチキャストパケットのNACK再送タイマが「オン」であり満了していないか判断する。この判断はMPキャッシュテーブル500cからの情報に基づく。(ブロック1200において)NACK再送タイマがオンであれば(図12に示す機能ブロックと同じ)、ブロック1205でNACK再送タイマは停止される(図12に示す機能ブロックと同じ)。マルチキャスト受信ノード20は、NACK再送タイマの状態を「オフ」に変更する。これは、同一のマルチキャストが不必要に再送信されるのを抑制するために行われる。そしてブロック430で、マルチキャスト受信ノード20入力マルチキャストパケットを棄てる。ブロック440で、マルチキャスト受信ノード20はアイドルになる。
NACK再送タイマが(ブロック1200において)「オフ」であれば、ブロック430で、マルチキャスト受信ノード20は入力マルチキャストパケットを棄てる。ブロック440で、マルチキャスト受信ノード20はアイドルになる。
図12に戻って、ブロック800においてノード10がFN90であれば、処理はブロック415(図12)へ進む。
マルチキャストパケットがMPキャッシュテーブル(図15A、500b)内のいずれのパケットとも一致しない場合は、ブロック420で、FN90は受信したマルチキャストパケットをMPキャッシュテーブル500bに追加する。
FN90は、マルチキャストグループID、送信元識別子、シーケンス番号、Time−to−Live(TTL)値、およびデータを抽出し、この情報をMPキャッシュテーブル500bに追加する。さらに、FN90は再送カウンタをゼロに初期化する。再送カウンタ(s_mp_c)は、マルチキャストパケットが再送されうる回数を表す。ある実施形態では、マルチキャストメッセージが再送される回数はあらかじめ定められた最大値に制限される。あらかじめ定められた最大値は全ノード10に対して同じであっても良い。別の実施形態では、あらかじめ定められた最大値はGHや送信元ノード700のような特定のノードに対して変更可能としても良い。
MPキャッシュテーブルはFN90とマルチキャスト受信ノード20とで異なる。FN90用には、MPキャッシュテーブル500bは、マルチキャストパケットについてのマルチキャストセッションID、送信元識別子、シーケンス番号、マルチキャストパケットデータ、ACK状態、再送タイマ値、再送カウンタ、TTL値、およびネガティブACK再送タイマ(NACK再送タイマ)を含む。ACK状態は「未確認」または「確認済み」のいずれかであり得る。再送タイマ値はオンかオフのいずれかであり得る。タイマがオンであれば、再送タイマ値は初期設定タイマ値といつ再送タイマ値が満了したかの指示も含む。マルチキャスト受信ノード20用には、MPキャッシュテーブル500cは、マルチキャストセッションID、送信元識別子、およびシーケンス番号だけを含む。
ブロック805で、FN90はACK状態を「未確認」に初期化する。FN90はどのマルチキャストパケットが受信確認され受信されたかを追跡できる。さらに、FN90は再送タイマ値をオンに初期化し、タイマを再送時間に設定する。再送時間は、データパケットに含まれるデータの種類、FN90の移動速度、およびその他のユーザ定義の基準に応じて変更可能である。
ブロック810で、再送カウンタを1増分する。すなわちs_mp_c+1にする。再送カウンタが増分された後、ブロック605で、FN90はマルチキャストパケットを一度転送する。FN90は、転送の前にマルチキャストパケットのTTL値から1減算する。したがって、次ホップFNはマルチキャストパケットを送っているFN90よりも小さいTTL値を含むマルチキャストパケットを受信する。ブロック440で、FN90はアイドルになる。
ブロック415においてマルチキャストパケットがMPキャッシュテーブル500c内のいずれかのパケットと同一であれば、ブロック1200で、マルチキャスト受信ノード20はNACK再送タイマが「オン」であり満了していないか判断する。この判断はMPキャッシュテーブル500cからの情報に基づく。(ブロック1200において)NACK再送タイマがオンであれば、ブロック1205でNACK再送タイマは停止される。マルチキャスト受信ノード20は、NACK再送タイマの状態を「オフ」に変更する。これは、同一のマルチキャストが不必要に再送信されるのを抑制するために行われる。
NACK再送タイマが(ブロック1200において)「オフ」であれば、処理はブロック815へ進む。
ブロック815で、FN90は同一のマルチキャストパケットのオフセットTTL値(In_MP_TTL+1)とTTL値とを比較する。同一のマルチキャストパケットのTTL値はMPキャッシュテーブル500bから取り出される。MPキャッシュテーブル500bから取り出されたTTL値がオフセット値よりも大きくない場合は、ブロック430で、入力マルチキャストパケットは無視されて破棄される。このマルチキャストパケットは上流ノードから発生したものである。マルチキャストパケットの転送は受信確認されない。ブロック440で、FN90はアイドルになる。
ブロック815においてMPキャッシュテーブル500bから取り出されたTTL値がオフセット値よりも大きい場合は、ブロック820で、FN90はこのマルチキャストパケットがすでに受信確認されたか判断する。
FN90はMPキャッシュテーブル500bから同一のマルチキャストパケットについてのACK状態を取り出す。同一のマルチキャストパケットがすでに受信確認されていれば、ブロック430で、入力マルチキャストパケットは無視されて破棄される。ブロック440で、FN90はアイドルになる。MPキャッシュテーブル500bに変更はない。ブロック820において同一のマルチキャストパケットが受信確認されていなければ、本方法はブロック825へ進む。
ブロック825で、FN90は再送タイマを停止する。さらに、FN90は、キャッシュテーブル500b内の再送タイマ値を「オフ」に変え、ACK状態を「確認済み」に変える。その後、ブロック430で入力マルチキャストパケットは破棄される。ブロック440で、FN90はアイドルになる。マルチキャストパケット転送の受信が確認される。
図14Aは、NACKを処理する機能ブロックを示す。NACK処理の動作プロセスは、FN90とマルチキャスト受信ノードとで同じである。
ブロック1400で、ノード10はNACKパケットを受信する。ノード10は、受信パケットに含まれる情報に基づいてそのパケットがNACKパケットであるか判断する。次にブロック405で、ノード10は、マルチキャストの参加者、すなわちFN90またはマルチキャスト受信ノード20であるか判断する。
ブロック405で、ノード10は受信したNACKパケットからマルチキャストグループIDを抽出して、ノード10がマルチキャストセッションのメンバであるか判断する。この判断はマルチキャストルーティングテーブルに基づく。ノード10がマルチキャストセッションのメンバでなければ、ブロック410で、それ以上の処理をせずにそのパケットのNACKは破棄される。ノード10がマルチキャストセッションのメンバであれば、ブロック415で、ノード10はマルチキャストパケットがMPキャッシュテーブル(500bまたは500c)にあるか判断する。例えば、マルチキャストパケットの情報エントリがMPキャッシュテーブル(500bまたは500c)にリストされているか確認する。
ブロック415においてマルチキャストパケットがMPキャッシュテーブル内のいずれかのパケットと同一であれば、ブロック1200で、ノード10はNACK再送タイマが「オン」であるか判断する。この判断はMPキャッシュテーブル(500bまたは500c)からの情報に基づく。NACK再送タイマが(ブロック1200で)オンであれば、ブロック440で、ノード10はアイドルになる。反対に、NACK再送タイマが(ブロック1200で)「オフ」であれば、ブロック1405で、ノード10はNACK再送タイマを所定値に設定する。言い換えると、ノード10はNACK再送タイマの状態を「オン」に変える。NACK再送タイマはNACK期間の計時を開始する。
図14Bは、NACK再送タイマが満了した際のマルチキャストパケットの再送の機能ブロックを示す。ブロック1410で、NACK再送タイマが満了する。ノード10はNACK再送タイマの状態を「オフ」に変える。ブロック605で、ノード10はマルチキャストパケットを再送または転送する。ブロック440で、ノード10はアイドルになる。
図15Aは、本発明の第4の実施形態に係るFN90のMPキャッシュテーブル500bの例を示す。図示されるように、MPキャッシュテーブル500bは、2つの異なるマルチキャストパケット(MP1とMP2)を含む。各マルチキャストパケットに対して、MPキャッシュテーブル500bは、マルチキャストセッションID(GroupAdd)、送信元識別子、マルチキャストパケットのシーケンス番号(SeqNum)、マルチキャストパケットデータ(MPキャッシュ)、受信確認状態(ACK状態)、再送タイマ(Retran_Timer)、再送カウンタ(s_mp_c)、マルチキャストパケットのTTL値(C_MP_TTL)、およびネガティブACK再送タイマ(NACK再送タイマ)を含む。図15Aに示されるように、NACK再送タイマはマルチキャストパケットの一方についてオンである。
図15Bは、本発明の第4の実施形態に係るマルチキャスト受信ノードのMPキャッシュテーブル500Cの例を示す。図示されるように、MPキャッシュテーブル500bは、2つの異なるマルチキャストパケット(MP1とMP2)を含む。各マルチキャストパケットに対して、MPキャッシュテーブル500cは、マルチキャストセッションID(GroupAdd)、送信元識別子、マルチキャストパケットのシーケンス番号(SeqNum)、およびネガティブACK再送タイマ(NACK再送タイマ)を含む。
図16は、本発明の第5の実施形態に係るルーティング方法を示す。本発明の第5の実施形態は、マルチキャストパケットが複数回中継される点を除いて、第3の実施形態と同様である。
ブロック400で、マルチキャストパケットがノード10に到着する。マルチキャストパケットは、マルチキャストグループID、送信元識別子、シーケンス番号、Time−to−Live(TTL)値、およびデータを含む。TTL値は、マルチキャストパケットが中継されるホップ数である。
ブロック405で、ノード10はパケットからマルチキャストグループ識別子を抽出して、ノード10がマルチキャストセッションのメンバであるか判断する。この判断はマルチキャストルーティングテーブルに基づく。ノード10がマルチキャストセッションのメンバでなければ、ブロック410で、それ以上の処理をせずにマルチキャストパケットは破棄される。ノード10がマルチキャストセッションのメンバであれば、ブロック800で、ノード10はFN90かマルチキャスト受信ノードであるかを判断する。ノード10がマルチキャスト受信ノード20であれば、処理は図10の機能ブロック415へ進む。ノード10がマルチキャストセッションのFN90であれば、ブロック415(図16)で、FN90はマルチキャストパケットがMPキャッシュテーブル(例えば、500a)内にあるか判断する。
マルチキャストパケットがMPキャッシュテーブル500a内のいずれのパケットとも一致しない場合は、ブロック420で、FN90は受信したマルチキャストパケットをキャッシュテーブル500aへ追加する。
FN90は、マルチキャストグループID、送信元識別子、シーケンス番号、Time−to−Live(TTL)値、およびデータを抽出し、この情報をMPキャッシュテーブル500aに追加する。さらに、FN90は再送カウンタをゼロに初期化する。再送カウンタ(s_mp_c)は、マルチキャストパケットが再送されうる回数を表す。第3の実施形態と同様に、MPキャッシュテーブルはFN90とマルチキャスト受信ノードとで異なる。MPキャッシュテーブル(例えば、500aおよび500)は、第3の実施形態と同一の情報を含む。
ブロック805で、FN90はACK状態を「未確認」に初期化する。FN90はどのマルチキャストパケットが受信確認され受信されたかを追跡できる。さらに、FN90は再送タイマ値をオンに初期化し、タイマを再送時間に設定する。再送時間は、データパケットに含まれるデータの種類、FN90の移動速度、およびその他のユーザ定義の基準に応じて変更可能である。
ブロック810で、再送カウンタが1増分する。すなわちs_mp_c+1にする。再送カウンタが増分された後、ブロック605で、FN90はマルチキャストパケットをN回転送する。ある実施形態では、FN90はマルチキャストパケットをN回連続して転送する。パケットが転送される数字「N」回は予め定められていて変更可能である。到達率の増加とデータオーバヘッドの増加にはトレードオフがある。数字「N」が増えるにしたがって、データオーバヘッドが著しく増加するが、到達率もまた増加する。別の実施形態では、FN90はパケットをN回同時に転送する。
FN90は、転送の前にマルチキャストパケットのTTL値から1減算する。したがって、次ホップFNはマルチキャストパケットを送っているFN90よりも小さいTTL値を含むマルチキャストパケットを受信する。ブロック440で、FN90はアイドルになる。
マルチキャストパケットがMPキャッシュテーブル500a内のいずれかのパケットと同一であれば、本方法はブロック815へ進む。
FN90は入力マルチキャストパケットのTTL値を判断する。上記したようにTTL値は特定のマルチキャストパケットのホップ数を制御するために用いられる。さらにこの実施形態では、TTL値は送信ノード10および受信ノード10の相対的な位置を決定するためにも用いられる。具体的には、マルチキャストパケットが転送されるたびに、ノード10はTTL値から1減算する(すなわち、TTL−1)。特定のFN90から下流にあるノード10から受信されたマルチキャストパケットのTTL値は、FN90から転送された同一のマルチキャストパケットのTTL値よりも小さい。特定のFN90から上流にあるノード10から受信されたマルチキャストパケットのTTL値は、FN90から転送された同一のマルチキャストパケットのTTL値よりも大きい。特定のFN90と同じホップ数のノード10から受信されたマルチキャストパケットは、同一のTTL値を持つ。
FN90は、FN90による最初のマルチキャストパケットの転送を補うために、判定されたTTL値にオフセット値の1を加える。これによりオフセットTTL値が生成される。
ブロック815で、FN90は、オフセットTTL値(In_MP_TTL+1)と同一のマルチキャストパケットのTTL値とを比較する。同一のマルチキャストパケットのTTL値は、MPキャッシュテーブルから取り出される。MPキャッシュテーブルから取り出されたTTL値がオフセット値よりも大きくない場合は、ブロック430で、入力マルチキャストパケットは無視されて破棄される。このマルチキャストパケットは上流ノードから発生したものである。マルチキャストパケットの転送は受信確認されない。ブロック440で、FN90はアイドルになる。
ブロック815においてMPキャッシュテーブル500aから取り出されたTTL値がオフセット値よりも大きい場合は、ブロック820で、FN90はこのマルチキャストパケットがすでに受信確認されたか判断する。
FN90はMPキャッシュテーブル500aから同一のマルチキャストパケットについてのACK状態を取り出す。同一のマルチキャストパケットがすでに受信確認されていれば、ブロック430で、入力マルチキャストパケットは無視されて破棄される。ブロック440で、FN90はアイドルになる。MPキャッシュテーブル500aに変更はない。ブロック820において同一のマルチキャストパケットが受信確認されていなければ、本方法はブロック825へ進む。
ブロック825で、FN90は再送タイマを停止する。さらに、FN90は、キャッシュテーブル500a内の再送タイマ値を「オフ」に変え、ACK状態を「確認済み」に変える。その後、ブロック430で入力マルチキャストパケットは破棄される。ブロック440で、FN90はアイドルになる。マルチキャストパケット転送の受信が確認される。
残りの機能ブロックは図9および図10で示された機能ブロックと一致しているので、詳しくは説明しない。
図17は、本発明の第6の実施形態に係るマルチキャスト受信ノード20の機能ブロックを示す。本発明の第6の実施形態は、本発明の第2および第3の実施形態の機能ブロックを組み合わせたものである。FN90の機能ブロックは図8および図9で示された機能ブロックと一致しているので、詳しくは説明しない。
ブロック415で、マルチキャスト受信ノード20は、マルチキャストパケットがMPキャッシュテーブル(例えば、500a)内にあるか判断する。マルチキャストパケットがMPキャッシュテーブル500aないにあれば、ブロック430で、マルチキャストパケットは破棄される。ブロック440で、マルチキャスト受信ノード20はアイドルになる。
マルチキャストパケットがMPキャッシュテーブル500内に無い、すなわち、同一ではない場合は、マルチキャストパケットに含まれる情報がMPキャッシュテーブル500aに追加される。ブロック600で、マルチキャスト受信ノード20は、マルチキャストパケットに割り当てられたランダムな確率と、確率閾値とを比較する。マルチキャストパケットに割り当てられたランダムな確率が確率閾値よりも小さければ、ブロック605で、マルチキャスト受信ノード20は受信したマルチキャストパケットを転送する。そして、ブロック440で、マルチキャスト受信ノード20はアイドルになる。
マルチキャストパケットに割り当てられたランダムな確率が確率閾値以上であれば、ブロック430で、マルチキャスト受信ノード20は受信したマルチキャストパケットを破棄する。そして、ブロック440で、マルチキャスト受信ノード20はアイドルになる。
図18は、本発明の第7の実施形態に係るルーティング方法を示す。第7の実施形態によれば、、マルチキャストパケットの送信はあらかじめ定められた基準に基づいて抑制される。
図18に示すように、マルチキャストパケットがノード10に到着する。マルチキャストパケットは、マルチキャストグループID、送信元識別子、シーケンス番号、Time−to−Live(TTL)値、およびデータを含む。TTL値は、マルチキャストパケットが中継されるホップ数である。
ブロック405で、ノード10はパケットからマルチキャストグループ識別子を抽出して、ノード10がマルチキャストセッションのメンバであるか判断する。この判断はマルチキャストルーティングテーブルに基づく。ノード10がマルチキャストセッションのメ
ンバでなければ、ブロック410で、それ以上の処理をせずにマルチキャストパケットは破棄される。ノード10がマルチキャストセッションのメンバであれば、ブロック800で、ノード10はFN90かマルチキャスト受信ノードであるかを判断する。ノード10がマルチキャスト受信ノードであれば、処理はブロック415(受信者用)に移動する。ノード10がマルチキャストセッションのFN90であれば、ブロック415(FN90用)で、FN90はマルチキャストパケットがMPキャッシュテーブル(例えば、500d)内にあるか判断する。
マルチキャストパケットがMPキャッシュテーブル500d内のいずれのパケットとも一致しない場合は、ブロック420で、FN90またはマルチキャスト受信ノード20は受信したマルチキャストパケットをMPキャッシュテーブル500dに付加する。
FN90は、マルチキャストグループID、送信元識別子、シーケンス番号、Time−to−Live(TTL)値、およびデータを抽出し、この情報をMPキャッシュテーブル500dに付加する。さらに、FN90は再送カウンタをゼロに初期化する。再送カウンタ(s_mp_c)は、マルチキャストパケットが再送されうる回数を表す。この実施形態では、s_mp_cの値は「0」か「1」である。FN90のMPキャッシュテーブル500dはランダム転送タイマも含む。
MPキャッシュテーブルはFN90とマルチキャスト受信ノード20とで異なる。マルチキャスト受信ノード20のMPキャッシュテーブル500dは、マルチキャストセッションID、送信元識別子、およびマルチキャストパケットのシーケンス番号を含む。したがって、ブロック420で、マルチキャスト受信ノード20は、マルチキャストセッションID、送信元識別子、およびシーケンス番号をMPキャッシュテーブル500に付加する。
ブロック425で、ノード10はマルチキャストセッションのFN90であるか判断する。この判断は転送テーブルおよびMPキャッシュテーブル(例えば、500)内の情報に基づく。ノード10がマルチキャストパケットのFN90でなければ、ブロック419で、入力マルチキャストパケットは破棄される。ノードがFN90であれば、ブロック1800で、FNは転送タイマをランダム値に設定する。このランダム値によりマルチキャストパケットの転送が妨げられる。FN90は、ランダム値が満了、すなわちランダム転送タイマが満了したときのみマルチキャストパケットを転送する。
ブロック415において、マルチキャストパケットがMPキャッシュテーブル500d内にすでに存在する場合は、ブロック1802で、FN90はこのパケットをすでに転送したか、すなわちs_mp_c=1であるか判断する。カウンタ(s_mp_c)が1に等しければ、パケットはすでに転送されている。カウンタ(s_mp_c)が0に等しければ、パケットはまだ転送されていない。FNはMPキャッシュテーブル500dからカウンタ値を取り出す。ブロック1802においてカウンタ(s_mp_c)が1に等しければ、ステップ430で、マルチキャストパケットは転送されることなく破棄される。ブロック1802で、カウンタ(s_mp_c)が0に等しければ、FN90は入力マルチキャストパケットのTTL値を判断する(ブロック815)。上記したように、TTL値は特定のマルチキャストパケットのホップ数を制御するために用いられる。さらに、この実施形態では、TTL値は送信ノード10および受信ノード10の相対的な位置を決定するためにも用いられる。FN90は、FN90による最初のマルチキャストパケットの転送を補うために、判定されたTTL値にオフセット値の1を加える。これによりオフセットTTL値が生成される。
ブロック815で、FN90は、オフセットTTL値(In_MP_TTL+1)と同
一のマルチキャストパケットのTTL値とを比較する。同一のマルチキャストパケットのTTL値は、MPキャッシュテーブル500dから取り出される。MPキャッシュテーブル500dから取り出されたTTL値がオフセット値よりも大きくない場合は、(ブロック430で)入力マルチキャストパケットは破棄され、FN90はアイドルになる。このマルチキャストパケットは上流ノードまたはピアノードから発生したものである。ブロック815においてMPキャッシュテーブル500dから取り出されたTTL値がオフセット値よりも大きい場合は、入力マルチキャストパケットは例えば下流FN90から発生したものであり、FN90はマルチキャストパケットを転送する必要が無い。
ブロック1805で、FNはマルチキャストパケットのランダム転送タイマを停止する。言い換えると、FNはランダム転送タイマの状態を「オン」から「オフ」に変更する。その後、ブロック430でマルチキャストパケットは破棄される。ブロック440で、FN90はアイドルになる。
ランダム転送タイマが満了したら、FN90はマルチキャストパケットを転送する。ブロック1810で、ランダム転送タイマが満了し、FN90がランダム転送タイマの状態を「オン」から「オフ」に変更する。その後、ブロック605で、FN90はマルチキャストパケットを転送する。FN90はTTL値を1だけ減らす。マルチキャストパケット内のTTL値を1だけ減少させた後、FN90マルチキャストパケットを転送する。さらに、マルチキャストパケットの転送の後、ブロック1812でFNは再送カウンタ(s_mp_c)を1に設定する。ブロック440で、FN90はアイドルになる。第7の実施形態によれば、FN90によるマルチキャストパケットの転送は軽く抑制される。
図19は、本発明の第8の実施形態に係るルーティング方法を示す。第8の実施形態によれば、マルチキャストパケットの転送は厳しく制限される。図19に示される機能ブロックの多くは図18と同じであり、したがって、詳しくは説明しない。第7と第8の実施形態の違いは、ブロック1900における(ブロック815と対照的な)TTL値の比較である。ブロック1900で、入力マルチキャストパケットのTTL値がMPキャッシュテーブル(例えば、500d)に格納されたTTL値と比較される。
入力マルチキャストパケットのTTL値にはオフセット値が加えられない。
MPキャッシュテーブル(例えば、500d)から取り出されたTTL値が入力TTL値より大きくなければ、入力マルチキャストパケットは(ブロック430で)破棄され、ブロック440でFN90はアイドルになる。このマルチキャストパケットは上流ノードから発生したものである。ブロック1900においてMPキャッシュテーブル500dから取り出されたTTL値が入力TTL値より大きければ、入力マルチキャストパケットは例えばピアや下流ノードから発生したものである。FN90は、マルチキャストパケットの転送をやめて、マルチキャストパケットのランダム転送タイマを停止する。
図20は、本発明の第9の実施形態に係るルーティング方法を示す。本発明の第9の実施形態は2段階の抑制方法を用いる。図20は、2つの機能ブロックが追加されている以外は、図18と同様である。同一の機能ブロックについては繰り返しては説明しない。
上述したように、ブロック815で、FN90は、オフセットTTL値(IN_MP_TTL+1)を同一のマルチキャストパケットのTTL値と比較する。同一のマルチキャストパケットのTTL値はMPキャッシュテーブル(例えば、500d)から取り出される。MPキャッシュテーブル500dから取り出されたTTL値がオフセット値よりも大きくなければ、入力マルチキャストパケットは(ブロック430で)破棄され、ブロック440でFN90はアイドルになる。しかしながら、第9の実施形態では、MPキャッシ
ュテーブル500dから取り出されたTTL値がオフセット値よりも大きくなければ、ブロック2000で、FNはMPキャッシュテーブルから取り出されたTTL値がオフセット値と等しいか判断する。MPキャッシュテーブル500dから取り出されたTTL値がオフセット値と等しくなければ、入力マルチキャストパケットは破棄され、ブロック440でFN90はアイドルになる。しかしながら、MPキャッシュテーブル500dから取り出されたTTL値がオフセット値と等しい、すなわち、マルチキャストパケットが周囲のピアから受信されたものであれば、ブロック2005で、マルチキャストパケットのランダム転送タイマが停止されて、別のランダム値に再設定される。マルチキャストパケットのランダム転送タイマ延長される。この時間延長により、同一のマルチキャストパケットのTTL値よりも小さいオフセットTTL値を有する入力マルチキャストパケットを、ランダム転送タイマが満了する前に受信する機会が増える。したがって、不必要な転送が抑制され、重複するパケットが生成することが少ない。
図21は、第7〜第9の実施形態に係るFN90のMPキャッシュテーブル500dの例を示す。図示されるように、MPキャッシュテーブル500dは、2つの異なるマルチキャストパケット(MP1およびMP2)を含む。各マルチキャストパケットに対して、MPキャッシュテーブル500bは、マルチキャストセッションID(Group Add)、送信元識別子、マルチキャストパケットのシーケンス番号(SeqNum)、マルチキャストパケットデータ(MPキャッシュ)、再送カウンタ(s_mp_c)、マルチキャストパケットのTTL値(C_MP_TTL)、およびランダム転送タイマ(Random_Forward_Timer)を含む。図21に示されるように、マルチキャストパケットの一方についてオンである。
本発明の第9の実施形態は、マルチキャストパケットと同様にブロードキャストパケットにも適用できる。しかしながら、ブロードキャスト通信を行うためには、すべてのノードがFN90になる。
本発明はここまで特定の例示的な実施形態を参照して説明されている。本発明の範囲から逸脱することなくいくらかの代替や変更は当業者にとって明らかであろう。例示的な実施形態は説明を意図したものであり、添付の特許請求の範囲によって定義される本発明の範囲を限定するものではない。

Claims (22)

  1. 無線アドホックネットワーク内において、1つのグループヘッダノードと1つまたは複数のグループノードから構成され、前記グループヘッダから送信される第1の制御パケットと、前記第1の制御パケットに応答して前記グループノードから前記グループヘッダノードに対して送信される第2の制御パケットとに基づいて管理されるローカルピアグループにおける、マルチキャストメッセージのルーティングを行う方法であって、
    グループヘッダノードが、前記第1の制御パケットを定期的に送信するステップと、
    グループノードが、前記第1の制御パケットを受信するステップと、
    グループノードが、受信した前記第1の制御パケットを転送するステップと、
    グループノードが、受信した前記第1の制御パケットに応答して、前記第2の制御パケットを、前記グループヘッダノードへ送信するステップと、
    グループノードが、他のグループノードから送信される第2の制御パケットを受信するステップと、
    グループノードが、受信した前記第2の制御パケットを転送するステップと、
    グループノードが、前記第1の制御パケットおよび第2の制御パケットに基づいて、マルチキャストメッセージの転送経路を表すマルチキャスト転送テーブルを生成するステップと、
    グループノードが、少なくともメッセージと送信元識別子とシーケンス番号とTime−to−Live値とマルチキャストグループ宛先とを含むマルチキャストメッセージを受信するステップと、
    前記マルチキャストメッセージを受信したグループノードが、
    前記マルチキャストグループ宛先がマルチキャスト転送テーブル内に存在するか判断するステップと、
    前記メッセージが以前に受信したものであるか判断するステップと、
    前記メッセージが以前に受信したものではないと判断された場合に、前記マルチキャストメッセージを前記マルチキャスト転送テーブルに追加するステップと、
    自ノードが転送ノードであるか判断するステップと、
    前記マルチキャストメッセージを転送するための待機時間をランダムに設定するステップと、
    前記待機時間が満了したときに、前記マルチキャストメッセージを転送するステップと、
    を含む、マルチキャストメッセージのルーティング方法。
  2. 前記メッセージが以前に受信したものである場合に、少なくとも同一のメッセージと送信元識別子とシーケンス番号とマルチキャストグループ宛先とを含む第2のマルチキャストメッセージを前記ランダムに設定された待機時間内に下流ノードから受信したときは、前記ランダムに設定された待機時間を停止するステップをさらに含む、
    請求項1に記載のマルチキャストメッセージのルーティング方法。
  3. 前記待機時間が停止された場合は、前記マルチキャストメッセージは転送されない、
    請求項2に記載のマルチキャストメッセージのルーティング方法。
  4. 第2のマルチキャストメッセージが下流ノードから受信されたかの判断は、
    第2のマルチキャストメッセージからTime−to−Live値を抽出する工程と、
    前記Time−to−Live値にプリセット値を加えてオフセットTime−to−Live値を生成する工程と;
    前記マルチキャスト転送テーブルから同一のメッセージを含むマルチキャストメッセージのTime−to−Live値を取り出す工程と、
    前記オフセットTime−to−Live値と前記取り出されたTime−to−Live値とを比較する工程と、
    を含み、
    前記取り出されたTime−to−Live値が前記オフセットTime−to−Live値よりも大きい場合に、前記待機時間が停止される、
    請求項2に記載のマルチキャストメッセージのルーティング方法。
  5. 前記取り出されたTime−to−Live値が前記オフセットTime−to−Live値と等しい場合に、前記待機時間はランダム値にリセットされる、
    請求項4に記載のマルチキャストメッセージのルーティング方法。
  6. マルチキャストメッセージの転送後に、当該メッセージに対応するACKフラグを未確認に設定するステップと、
    再送時間を所定時間に設定するステップと、
    をさらに含む、請求項1に記載のマルチキャストメッセージのルーティング方法。
  7. 前記メッセージが以前に受信されたものである場合に、少なくとも同一のメッセージと送信元識別子とシーケンス番号とマルチキャストグループ宛先とを含む第2のマルチキャストメッセージを下流ノードから受信したときは、前記再送時間を停止するステップをさらに含む、
    請求項6に記載のマルチキャストメッセージのルーティング方法。
  8. 前記再送時間を停止した後に、前記メッセージに対応するACKフラグを確認済みに設定するステップをさらに含む、
    請求項7に記載のマルチキャストメッセージのルーティング方法。
  9. 前記再送時間が満了したときに、前記マルチキャストメッセージを再送するステップと、
    再送後に前記再送時間を所定時間に設定するステップと、
    をさらに含む、請求項7に記載のマルチキャストメッセージのルーティング方法。
  10. 再送回数の上限に達したか判断するステップと、
    前記判断に基づいて、前記再送時間が満了したときに、前記マルチキャストメッセージを再送するステップと、
    再送カウンタを増加させるステップと、
    再送後に前記再送時間を所定時間に設定するステップと、
    をさらに含み、
    再送回数の上限に達した場合には、再送時間が停止される、
    請求項7に記載のマルチキャストメッセージのルーティング方法。
  11. 無線アドホックネットワーク内において、1つのグループヘッダノードと1つまたは複数のグループノードから構成され、前記グループヘッダから送信される第1の制御パケットと、前記第1の制御パケットに応答して前記グループノードから前記グループヘッダノードに対して送信される第2の制御パケットとに基づいて管理されるローカルピアグループにおける、マルチキャストメッセージのルーティングを行う方法であって、
    グループヘッダノードが、前記第1の制御パケットを定期的に送信するステップと、
    グループノードが、前記第1の制御パケットを受信するステップと、
    グループノードが、受信した前記第1の制御パケットを転送するステップと、
    グループノードが、受信した前記第1の制御パケットに応答して、前記第2の制御パケットを、前記グループヘッダノードへ送信するステップと、
    グループノードが、他のグループノードから送信される第2の制御パケットを受信するステップと、
    グループノードが、受信した前記第2の制御パケットを転送するステップと、
    グループノードが、前記第1の制御パケットおよび第2の制御パケットに基づいて、マルチキャストメッセージの転送経路を表すマルチキャスト転送テーブルを生成するステップと、
    グループノードが、少なくともメッセージと送信元識別子とシーケンス番号とTime−to−Live値とマルチキャストグループ宛先とを含むマルチキャストメッセージを受信するステップと、
    前記マルチキャストメッセージを受信したグループノードが、
    前記マルチキャストグループ宛先がマルチキャスト転送テーブル内に存在するか判断するステップと、
    前記マルチキャストメッセージが以前に受信したものであるか判断するステップと、
    前記マルチキャストメッセージが以前に受信したものではないと判断された場合に、前記マルチキャストメッセージを前記マルチキャスト転送テーブルに追加するステップと、
    自ノードがマルチキャスト受信ノードであるか判断するステップと、
    確率値をランダムに割り当てるステップと、
    前記ランダムに割り当てられた確率値とプリセット確率閾値とを比較するステップと、
    前記比較に基づいて前記マルチキャストメッセージを転送するステップと、
    を含む、マルチキャストメッセージのルーティング方法。
  12. 前記プリセット確率閾値を設定するステップをさらに含む
    請求項11に記載のマルチキャストメッセージのルーティング方法するステップ。
  13. 前記マルチキャスト転送テーブルは、前記グループ宛先と前記送信元識別子と前記シーケンス番号とを含む、
    請求項11に記載のマルチキャストメッセージのルーティング方法。
  14. 前記マルチキャスト転送テーブルは、前記グループ宛先と前記送信元識別子と前記シー
    ケンス番号と前記メッセージと前記ACKフラグと前記再送時間値と前記再送カウンタと前記Time−to−Live値とを含む、
    請求項10に記載のマルチキャストメッセージのルーティング方法。
  15. マルチキャストメッセージの転送後に、当該メッセージに対応するACKフラグを未確認に設定するステップと、
    再送時間を所定時間に設定するステップと、
    をさらに含む、請求項11に記載のマルチキャストメッセージのルーティング方法。
  16. 再送カウンタを増加させるステップをさらに含む、
    請求項11に記載のマルチキャストメッセージのルーティング方法。
  17. 前記メッセージが以前に受信されたものである場合に、少なくとも同一のメッセージと送信元識別子とシーケンス番号とマルチキャストグループ宛先とを含む第2のマルチキャストメッセージを下流ノードから受信したときに、前記再送時間を停止するステップをさらに含む、
    請求項15に記載のマルチキャストメッセージのルーティング方法。
  18. 前記再送時間を停止した後に、前記メッセージに対応するACKフラグを確認済みに設定するステップをさらに含む、
    請求項15に記載のマルチキャストメッセージのルーティング方法。
  19. 再送カウンタの値に基づいて、再送回数の上限に達したか判断するステップと、
    前記判断に基づいて、前記再送時間が満了したときに、前記マルチキャストメッセージを再送するステップと、
    再送カウンタを増加させるステップと、
    再送後に前記再送時間を所定時間に設定するステップと、
    をさらに含み、
    再送回数の上限に達した場合には、再送時間が停止される、
    請求項15に記載のマルチキャストメッセージのルーティング方法。
  20. 無線アドホックネットワーク内において、1つのグループヘッダノードと1つまたは複数のグループノードから構成され、前記グループヘッダから送信される第1の制御パケットと、前記第1の制御パケットに応答して前記グループノードから前記グループヘッダノードに対して送信される第2の制御パケットとに基づいて管理されるローカルピアグループにおける、マルチキャストメッセージのルーティングを行う方法であって、
    グループヘッダノードが、前記第1の制御パケットを定期的に送信するステップと、
    グループノードが、前記第1の制御パケットを受信するステップと、
    グループノードが、受信した前記第1の制御パケットを転送するステップと、
    グループノードが、受信した前記第1の制御パケットに応答して、前記第2の制御パケットを、前記グループヘッダノードへ送信するステップと、
    グループノードが、他のグループノードから送信される第2の制御パケットを受信するステップと、
    グループノードが、受信した前記第2の制御パケットを転送するステップと、
    グループノードが、前記第1の制御パケットおよび第2の制御パケットに基づいて、マルチキャストメッセージの転送経路を表すマルチキャスト転送テーブルを生成するステップと、
    グループノードが、少なくともメッセージと送信元識別子とシーケンス番号とTime−to−Live値とマルチキャストグループ宛先とを含むマルチキャストメッセージを受信するステップと、
    前記マルチキャストメッセージを受信したグループノードが、
    前記マルチキャストグループ宛先がマルチキャスト転送テーブル内に存在するか判断するステップと、
    前記メッセージが以前に受信したものであるか判断するステップと、
    を含み、
    前記メッセージが以前に受信されたものである場合に、
    前記マルチキャストメッセージを受信したグループノードが、
    前記Time−to−Live値にプリセット値を加えてオフセットTime−to−Live値を生成する工程と、
    前記オフセットTime−to−Live値と前記マルチキャスト転送テーブル内のTime−to−Live値を比較する工程と、
    前記オフセットTime−to−Live値が前記マルチキャスト転送テーブル内のTime−to−Live値以上である場合に、前記マルチキャストメッセージを転送することなく破棄する工程と、
    を含む、マルチキャストメッセージのルーティング方法。
  21. 前記マルチキャストメッセージが以前に受信したものではない場合に、
    当該メッセージに対応するACKフラグを未確認に設定する工程と、
    再送カウンタを増加させる工程と、
    再送時間を所定値に設定する工程と、
    マルチキャストメッセージを転送する工程と、
    をさらに含む、請求項20に記載のマルチキャストメッセージのルーティング方法。
  22. 前記オフセットTime−to−Live値が前記マルチキャスト転送テーブル内のTime−to−Live値よりも小さい場合に、
    前記メッセージに対応するACKフラグを確認済みに設定する工程と、
    前記再送時間を停止する工程と、
    をさらに含む、請求項21に記載のマルチキャストメッセージのルーティング方法。
JP2010546885A 2008-02-13 2009-02-12 ローカル・ピア・グループ(lpg)に基づく車両アドホックネットワークにおける高信頼度マルチキャスト方法 Active JP5364728B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US12/069,815 US8068491B2 (en) 2008-02-13 2008-02-13 Methods for reliable multicasting in local peer group (LPG) based vehicle ad hoc networks
US12/069,815 2008-02-13
PCT/US2009/033879 WO2009102841A1 (en) 2008-02-13 2009-02-12 Methods for reliable multicasting in local peer group (lpg) based vehicle ad hoc networks

Publications (3)

Publication Number Publication Date
JP2011515037A JP2011515037A (ja) 2011-05-12
JP2011515037A5 JP2011515037A5 (ja) 2012-02-16
JP5364728B2 true JP5364728B2 (ja) 2013-12-11

Family

ID=40938833

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2010546885A Active JP5364728B2 (ja) 2008-02-13 2009-02-12 ローカル・ピア・グループ(lpg)に基づく車両アドホックネットワークにおける高信頼度マルチキャスト方法

Country Status (3)

Country Link
US (2) US8068491B2 (ja)
JP (1) JP5364728B2 (ja)
WO (1) WO2009102841A1 (ja)

Families Citing this family (46)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7644169B2 (en) * 2001-09-27 2010-01-05 Accudata Technologies, Inc. System and method for providing connectivity between two different networks using different protocols
WO2007026604A1 (ja) * 2005-08-29 2007-03-08 Nec Corporation マルチキャストノード装置とマルチキャスト転送方法ならびにプログラム
US20090268732A1 (en) * 2008-04-29 2009-10-29 Thomson Licencing Channel change tracking metric in multicast groups
JP5052549B2 (ja) * 2009-03-03 2012-10-17 株式会社東芝 無線通信装置及び無線通信方法
CN101854588B (zh) * 2009-04-01 2013-11-06 中兴通讯股份有限公司 一种增强型多媒体广播组播服务中的数据重传方法及装置
WO2010111837A1 (zh) * 2009-04-02 2010-10-07 华为技术有限公司 广播方法及通信设备
US9048895B2 (en) * 2009-06-05 2015-06-02 Broadcom Corporation Multi-user null data packet (MU-NDP) sounding within multiple user, multiple access, and/or MIMO wireless
US9912568B2 (en) * 2009-06-24 2018-03-06 Provenance Asset Group Llc Method and apparatus for handling broken path in peer-to-peer network
US10698859B2 (en) * 2009-09-18 2020-06-30 The Board Of Regents Of The University Of Texas System Data multicasting with router replication and target instruction identification in a distributed multi-core processing architecture
US8903964B2 (en) * 2009-10-05 2014-12-02 Vss Monitoring, Inc. Auto-configuration of network captured traffic device
US8594100B2 (en) 2010-03-31 2013-11-26 International Business Machines Corporation Data frame forwarding using a distributed virtual bridge
US8619796B2 (en) 2010-04-22 2013-12-31 International Business Machines Corporation Forwarding data frames with a distributed fiber channel forwarder
US8379642B2 (en) 2010-04-26 2013-02-19 International Business Machines Corporation Multicasting using a multitiered distributed virtual bridge hierarchy
US8566257B2 (en) 2010-04-26 2013-10-22 International Business Machines Corporation Address data learning and registration within a distributed virtual bridge
US8447909B2 (en) 2010-07-19 2013-05-21 International Business Machines Corporation Register access in distributed virtual bridge environment
DE102010040688A1 (de) * 2010-09-14 2012-03-15 Siemens Aktiengesellschaft Verfahren und Vorrichtung zum Authentisieren von Multicast-Nachrichten
US8804720B1 (en) 2010-12-22 2014-08-12 Juniper Networks, Inc. Pass-through multicast admission control signaling
TWI443034B (zh) * 2011-05-30 2014-07-01 Inst Information Industry 車輛防撞裝置、車輛防撞方法及其電腦程式產品
US8891535B2 (en) * 2012-01-18 2014-11-18 International Business Machines Corporation Managing a global forwarding table in a distributed switch
US8861400B2 (en) 2012-01-18 2014-10-14 International Business Machines Corporation Requesting multicast membership information in a distributed switch in response to a miss event
US9161287B2 (en) * 2012-10-16 2015-10-13 Spectranetix, Inc. Technique for efficient message delivery in Ad Hoc, mesh, wireless computer networks
EP2918052B1 (en) * 2012-11-08 2018-05-30 Telefonaktiebolaget LM Ericsson (publ) Method and apparatus for configuring multicast group
US20140159923A1 (en) * 2012-12-07 2014-06-12 Cisco Technology, Inc. Elastic Clustering of Vehicles Equipped with Broadband Wireless Communication Devices
CN105247901A (zh) * 2013-05-30 2016-01-13 中央大学学术合作基金会 在无线网络中管理多播组的装置及方法
CN106031228B (zh) * 2014-01-31 2019-10-11 飞利浦灯具控股公司 实时无线多播路由器
US9851982B2 (en) 2014-02-28 2017-12-26 Tyco Fire & Security Gmbh Emergency video camera system
US10050865B2 (en) * 2014-02-28 2018-08-14 Tyco Fire & Security Gmbh Maintaining routing information
US10878323B2 (en) 2014-02-28 2020-12-29 Tyco Fire & Security Gmbh Rules engine combined with message routing
US10152864B2 (en) 2014-02-28 2018-12-11 Tyco Fire & Security Gmbh Distributed rules engines for robust sensor networks
JP2017112395A (ja) * 2014-03-17 2017-06-22 日本電気株式会社 無線通信装置、無線通信システム、自動設定方法及びプログラム
US9280389B1 (en) 2014-12-30 2016-03-08 Tyco Fire & Security Gmbh Preemptive operating system without context switching
JP2015119501A (ja) * 2015-02-18 2015-06-25 日本電気株式会社 通信装置、通信方法およびプログラム
US10452399B2 (en) 2015-09-19 2019-10-22 Microsoft Technology Licensing, Llc Broadcast channel architectures for block-based processors
CN109327288B (zh) * 2015-12-14 2023-11-10 华为技术有限公司 数据传输加速方法、装置及***
KR101905963B1 (ko) 2016-08-01 2018-10-08 현대자동차주식회사 차선 노드 트리 구성 시스템 및 그 방법
CN108933735B (zh) * 2017-05-27 2020-12-25 华为技术有限公司 一种报文发送的方法、装置及设备
DE102017209593A1 (de) 2017-06-07 2018-12-13 Continental Teves Ag & Co. Ohg Kommunikationsgerät zur Kommunikation in einem Car-to-X-Kommunikationsnetz
EP3701657B1 (en) * 2017-10-27 2022-08-03 Telefonaktiebolaget LM Ericsson (PUBL) Method and device for updating the number of retransmissions in a wireless mesh network
US10963379B2 (en) 2018-01-30 2021-03-30 Microsoft Technology Licensing, Llc Coupling wide memory interface to wide write back paths
EP3750347A1 (en) * 2018-02-07 2020-12-16 Telefonaktiebolaget LM Ericsson (publ) A method for updating a number of hops that is to be used for communication between a publisher mesh node and a subscriber mesh node in a wireless mesh network
CN110505600B (zh) * 2018-05-18 2022-05-10 华为技术有限公司 路由方法及装置
JP7063723B2 (ja) * 2018-05-22 2022-05-09 本田技研工業株式会社 表示制御装置及びプログラム
EP3831021A1 (en) * 2018-07-27 2021-06-09 Gotenna Inc. VINEtm ZERO-CONTROL ROUTING USING DATA PACKET INSPECTION FOR WIRELESS MESH NETWORKS
CN109285386A (zh) * 2018-11-02 2019-01-29 东莞理工学院 一种面向智能交通的城市车载网络数据传输机制
CN114554421B (zh) * 2020-11-25 2023-06-16 华为技术有限公司 一种通信方法及装置
CN113453302B (zh) * 2021-08-31 2021-11-16 伏诺瓦(天津)科技有限公司 自组网的电力无线LoRa通信方法、装置、***及存储介质

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4974224A (en) * 1989-11-07 1990-11-27 Harris Corporation Distributed split flow routing mechanism for multi-node packet switching communication network
US5519704A (en) * 1994-04-21 1996-05-21 Cisco Systems, Inc. Reliable transport protocol for internetwork routing
US7085869B1 (en) * 2001-04-04 2006-08-01 Advanced Micro Devices, Inc. Arrangement for managing transmitted packets requiring acknowledgement in a host channel adapter
JP2003218886A (ja) * 2002-01-18 2003-07-31 Nec Corp 無線アドホックネットワークにおけるルーティング装置及びローカルネットワーク構成特定方法及びルーティング方法
EP1516449B1 (en) * 2002-06-21 2016-06-22 BRITISH TELECOMMUNICATIONS public limited company Timer-based feedback in multicast communication
AU2002368131A1 (en) 2002-07-31 2004-02-16 Ktfreetel Co., Ltd. Method and apparatus for receivability test and reachability test of explicit multicast
US7356578B1 (en) * 2003-05-28 2008-04-08 Landesk Software Limited System for constructing a network spanning tree using communication metrics discovered by multicast alias domains
CN100346605C (zh) 2003-06-26 2007-10-31 华为技术有限公司 一种组播源控制的方法和***
JP4605427B2 (ja) * 2003-08-08 2011-01-05 ソニー株式会社 通信システム、通信方法、通信端末装置及びその制御方法並びにプログラム
US7532623B2 (en) * 2004-03-24 2009-05-12 Bbn Technologies Corp. Methods for wireless mesh multicasting
US8027327B2 (en) 2004-06-25 2011-09-27 Alcatel Lucent Distributed scheduling in wireless networks with service differentiation
JP2007173941A (ja) * 2005-12-19 2007-07-05 Nec Commun Syst Ltd 無線通信端末、無線マルチホップネットワーク、転送制御方法、プログラム、記録媒体
US20080317047A1 (en) * 2007-06-20 2008-12-25 Motorola, Inc. Method for discovering a route to a peer node in a multi-hop wireless mesh network

Also Published As

Publication number Publication date
US20120039235A1 (en) 2012-02-16
JP2011515037A (ja) 2011-05-12
US8855115B2 (en) 2014-10-07
US20090201928A1 (en) 2009-08-13
US8068491B2 (en) 2011-11-29
WO2009102841A1 (en) 2009-08-20

Similar Documents

Publication Publication Date Title
JP5364728B2 (ja) ローカル・ピア・グループ(lpg)に基づく車両アドホックネットワークにおける高信頼度マルチキャスト方法
US7269147B2 (en) Relaying broadcast packet in a mobile Ad-hoc network including flushing buffer if broadcast count number exceed buffer size
EP2183930B1 (en) Multi-beam optic-wireless vehicle communications
JP5165031B2 (ja) 車両アドホックネットワークにおけるノード
US9119142B2 (en) Device and method for delay optimization of end-to-end data packet transmissions in wireless networks
EP2283585B1 (en) Methods for efficient organization of vehicle peer groups and efficient v2r communications
CN103119887B (zh) 用于对无线网络中的数据分组传输进行调度的设备和方法
US9847887B2 (en) System and method for multicast over highly mobile mesh networks
WO2003105353A2 (en) System and method for multicast media access using broadcast transmissions with multiple acknowledgments in an ad-hoc communications network
Shin et al. EMDOR: Emergency message dissemination with ACK-overhearing based retransmission
Jiang et al. Family ACK tree (FAT): a new reliable multicast protocol for mobile ad hoc networks
Moon et al. Efficient packet routing in highly mobile wireless networks
Mirani et al. DONC: Delay-based Opportunistic Network Coding Protocol
Sangwan et al. Reliable multihop broadcast protocols for inter-vehicular communication in a fading channel
KR101510902B1 (ko) 무선 네트워크에서의 라우팅 정보 전송방법
Reddy et al. Route Resurgence By Congestion Endurance (RRCE): A Strategic Routing Topology For Mobile Ad Hoc Networks
Huang et al. An information relevance related broadcast scheme for safety packets in VANETs
JP5405632B2 (ja) 通信ネットワークにおける情報配信方法、通信ノードおよびその通信方法ならびに通信ネットワーク
Boppana et al. Designing efficient multicast protocols for mobile ad hoc networks
Kumuthini et al. A survey of reputable and dissemination protocol in VANET
Ramchitra Performance enhancement in MANET for duo coverage broadcasting
Wen-Jing et al. On Acknowledgement Confirmation of Inter-Vehicle Safety Broadcasting MAC Protocols

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20111220

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20111220

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20130312

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20130422

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20130625

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20130725

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20130813

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20130909

R150 Certificate of patent or registration of utility model

Ref document number: 5364728

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250