アドホックネットワークの経路修復方法
【課題】送信元と送信先との間のホップ数が大きい大規模のアドホックネットワークにおいて、小さな負荷で経路を修復できる経路修復方法を提供する。
【解決手段】送信元ノードAと送信先ノードKとの間に９個の無線ノードB，C…Jを中継する経路が確立されており、経路上では所定のホップ数ごとに管理ノードA，F，Kが配置されている。無線ノードI，J間の経路が消失すると、これを検知した無線ノードIが送信元方向で直近の管理ノードFを宛先としてRERR（経路無効通知）を送信する。このRERRを受信した管理ノードFは、送信先方向で直近の管理ノード（ここでは、送信先ノードK）を宛先とするRepair_REQ（経路修復要求）を送信して局所的な経路修復を実施し、消失した経路をバイパスする新たな経路を２つの管理ノードF，K間に確立する。
【解決手段】送信元ノードAと送信先ノードKとの間に９個の無線ノードB，C…Jを中継する経路が確立されており、経路上では所定のホップ数ごとに管理ノードA，F，Kが配置されている。無線ノードI，J間の経路が消失すると、これを検知した無線ノードIが送信元方向で直近の管理ノードFを宛先としてRERR（経路無効通知）を送信する。このRERRを受信した管理ノードFは、送信先方向で直近の管理ノード（ここでは、送信先ノードK）を宛先とするRepair_REQ（経路修復要求）を送信して局所的な経路修復を実施し、消失した経路をバイパスする新たな経路を２つの管理ノードF，K間に確立する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、アドホックネットワークの経路修復方法に係り、特に、送信元ノードと送信先ノードとの間のホップ数が大きくなる大規模のアドホックネットワークに好適な経路修復方法に関する。
【背景技術】
【０００２】
無線ノードが互いに通信を行うアドホックネットワーク上でパケット通信を行う技術としてAODV（Adhoc On-demand Distance Vector）ルーティングプロトコルが知られている。AODVによれば、パケットの発信元と送信先とが直接通信できない場合であっても、送信元ノードと送信先ノードとの間に存在する１又は複数の無線ノードにパケットを中継させることにより、送信元と送信先との間でデータ転送を行うことができる。
【０００３】
オンデマンド型のルーティングプロトコルを用いた無線アドホックネットワークにおいて、経路の一部が切断されときに通信経路を修復するためのパケットをブロードキャストで送信して経路を再構築する技術が特許文献１に開示されている。
【０００４】
図１５は、従来の経路再構築手順を示した図であり、同図(a)に示したように、ノードA（送信元）→ノードB→ノードC→ノードD→ノードE（送信先）という経路でパケットが送信されているときに、ノードD，E間の経路が消失し、これがノードDで検知されると、ノードDでは以下の２通りの経路修復が実行される。
【０００５】
第１の経路修復手順では、同図(b)に示したように、ノードDから送信元側の経路にRERR（経路無効通知）メッセージが送信される。このRERRはノードC→ノードBの経路でノードAに至る。前記RERRを受け取ったノードAでは、改めてノードEを送信先とするRREQ（経路要求）がフラッディングされ、このRREQを受け取ったノードEがRREP（経路応答）をノードAに返信することにより経路が再構築される。
【０００６】
第２の経路修復手順では、同図(c)に示したように、ノードDが自ら、ノードEを送信先とするRREQをフラッディングしてノードEとの間に別の経路を確立する。
【特許文献１】特開２００５−２６９６２３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
第１の経路修復手順は、送信元ノードと送信先ノードとの間のホップ数が小さい小規模のネットワークには有効であるが、送信元と送信先との間のホップ数が大きい大規模のネットワークでは、RERRが辿る経路や、その後のRREQおよびRREPが辿る経路が長くなるので、経路維持の負荷が大きくなってしまう。
【０００８】
同様に、第２の経路修復手順でも、経路の消失を検知したノード（前記ノードD）と送信先ノード（前記ノードE）とが離れていると、RREQおよびRREPが辿る経路が長くなるので、経路維持の負荷が大きくなってしまう。
【０００９】
本発明の目的は、上記した従来技術の課題を解決し、送信元と送信先との間のホップ数が大きい大規模のアドホックネットワークにおいて小さな負荷で経路を修復できる経路修復方法を提供することにある。
【課題を解決するための手段】
【００１０】
上記した目的を達成するために、本発明は、アドホックネットワークにおいて、送信元ノードから複数のノードを中継して送信先ノードへ至る経路を修復する経路修復方法において、送信元ノードと送信先ノードとの間に、所定のノード間隔で管理ノードが配置された経路を確立する手順と、経路消失を検知したノードが、送信元方向で直近の第１管理ノードを宛先とする経路無効通知を送信する手順と、第１管理ノードが前記経路無効通知に応答して、送信先方向で直近の第２管理ノードを宛先とする経路修復要求を送信する手順と、経路修復要求を中継する各ノードが、前記第１管理ノード向けの経路表を生成する手順と、第２管理ノードが前記経路修復要求に応答して、前記第１管理ノードを宛先とする経路修復応答を送信する手順と、経路修復応答を中継する各ノードが、前記第２管理ノード向けの経路表を生成する手順とを含むことを特徴とする。
【発明の効果】
【００１１】
本発明によれば、経路生成時に送信元ノードと送信先ノードの間に一定間隔で管理ノードが配置され、経路が消失すると、当該消失区間を挟んだ管理ノード間で局所的に経路修復が行われるので、経路修復要求パケットのブロードキャスト範囲を限定することができ、その結果、制御オーバーヘッドを減らすことができる。
【発明を実施するための最良の形態】
【００１２】
以下、図面を参照して本発明の最良の実施の形態について詳細に説明する。図１は、本発明に係る経路修復方法の概要を模式的に表現した図であり、ここでは、同図(a)に示したように、送信元ノードAと送信先ノードKとの間に９個の無線ノードB，C…Jを中継する経路が確立されており、経路上では所定のホップ数ごとに管理ノードが配置されている。本実施形態では、二重丸で表現した送信元ノードAおよび送信先ノードK、ならびに無線ノードFが管理ノードとして登録されており、経路上の各無線ノードは、送信先方向で直近の管理ノードおよび送信元方向で直近の管理ノードをそれぞれ認識している。すなわち、無線ノードB，C，D，Eは、無線ノードFを送信先方向の管理ノードと認識し、送信元ノードAを送信元方向の管理ノードと認識している。同様に、無線ノードG，H，I，Jは、送信先ノードKを送信先方向の管理ノードと認識し、無線ノードFを送信元方向の管理ノードと認識している。
【００１３】
このような経路において、同図(b)に示したように、無線ノードI，J間の経路が消失すると、これを検知した無線ノードIが送信元方向で直近の管理ノードFを宛先としてRERR（経路無効通知）を送信する。このRERRを受信した管理ノードFは、送信先方向で直近の管理ノード（ここでは、送信先ノードK）を宛先とするRepair_REQ（経路修復要求）を送信して局所的な経路修復を実施し、消失した経路をバイパスする新たな経路を２つの管理ノードF，K間に確立する。
【００１４】
なお、管理ノードFは送信先ノードKとの間に新たな経路を確立できないと、同図(c)に示したように、送信元ノードAを宛先としてRERRを送信する。このRERRを受信した送信元ノードAは、送信先ノードKを宛先とする経路探索を実施して新たな経路を確立する。
【００１５】
図２は、本実施形態における各無線ノードの構成を示した機能ブロック図であり、ここでは、本発明の説明に不要な構成は図示が省略されている。
【００１６】
各無線ノードは、経路確立や経路修復のための各種メッセージパケットを生成、送信、受信、中継および破棄するメッセージパケット処理部１０と、経路表を宛先ごとに生成して管理する経路表管理部１１と、前記経路表管理部１１に登録されている経路表を利用してデータパケットを転送するデータパケット処理部１２とを主要な構成としている。前記メッセージパケット処理部１０は、後に詳述するRREQ（経路要求）処理部１０１、RREP（経路応答）処理部１０２、RERR（経路無効通知）処理部１０３、RREP_Ack処理部１０４、Repair_REQ（経路修復要求）処理部１０５およびRepair_REP（経路修復応答）処理部１０６を備えている。
【００１７】
図３は、前記経路表の一例を示した図であり、「宛先ノードID」ごとに、「次の管理ノードID」、「経路シーケンス番号」、「管理シーケンス番号」、「次の管理ノードまでのホップ数」、「次ホップノードID」および「ノード状態フラグ」等が登録されている。前記「ノード状態フラグ」には、自ノードが管理ノードであるか否かを示すフラグがセットされる。
【００１８】
次いで、本発明に係る経路修復方法をフローチャートに沿って説明する。図４は、各無線ノードにおける前記メッセージパケット処理部１０の動作を示したフローチャートであり、ステップＳ１では通信要求の有無が判定され、ステップＳ２では経路消失が検知されたか否かが判定され、ステップＳ３ではメッセージパケットが受信されたか否かが判定される。本実施形態では、前記図１に関して説明したように、無線ノードAにおいて無線ノードBを送信先とする通信要求が発生した場合を例にして説明する。
【００１９】
ステップＳ１で通信要求を検知した無線ノードAはステップＳ４へ進み、送信先ノードBに関して有効な経路表が前記経路表管理部１１に既登録であるか否かが判定される。既登録であれば、データパケットの送信処理へ進み、未登録であればステップＳ５へ進む。ステップＳ５では、従来のAODVと同様に、送信元ノードAのノードIDおよび送信先ノードKのノードIDの登録され、経路シーケンス番号がインクリメントされたRREQがブロードキャストで隣接ノードへ送信される。このRREQは、隣接する無線ノードにおいてステップＳ７で受信され、当該隣接する無線ノードでは、ステップＳ３，Ｓ７を経由してステップＳ１３のRREQ受信処理へ進む。
【００２０】
図５は、前記RREQ受信処理の手順を示したフローチャートであり、ステップＳ１３１では、同一のRREQを別経路で受信済みであるか否かが判定される。受信済みであれば、ステップＳ１３２へ進んで当該RREQが破棄される。受信済みでなければステップＳ１３３へ進み、このRREQの宛先に関して有効な経路表が自ノードに既登録であるか否かが判定される。
【００２１】
未登録であれば、ステップＳ１３４へ進んで経路表が作成される。既登録であればステップＳ１３８へ進み、当該RREQに登録されている経路シーケンス番号と既登録の経路表に登録されている経路シーケンス番号とが比較される。RREQに登録されている経路シーケンス番号の方が新しければ、ステップＳ１３９へ進んで既登録の経路表が更新される。
【００２２】
ステップＳ１３５では、RREQの宛先が自ノードであるか否かが判定される。宛先が自ノード以外であれば、ステップＳ１３６において当該RREQがブロードキャストで隣接ノードへ転送される。このRREQを受信した他の無線ノードでも、当該RREQ受信処理が同様に実行される。これに対して、宛先が自ノードであれば、RREPを返信すべくステップＳ１３７のRREP送信処理へ進む。
【００２３】
図６は、前記RREP送信処理の手順を示したフローチャートであり、ステップＳ２０１では、送信元／送信先ノード間の総ホップ数に基づいて、管理ノードの設定間隔が等間隔または略等間隔に決定される。ここでは、管理ノードの設定間隔が「５」ホップに決定されたものとして説明を続ける。ステップＳ２０２ではRREPが生成される。このRREPには、従来のAODVで確保されている「送信元ノードID」や「送信先ノードID」等の各種フィールドに加えて、後述する「次の管理ノードID」フィールド、「ホップ数カウンタ」フィールド、「管理ノード設定間隔」フィールド等が確保されている。
【００２４】
前記「次の管理ノードID」には、管理ノードとなった無線ノードの自ノードIDが登録される。本実施形態では、送信元ノードおよび送信先ノードは管理ノードとなるので、送信先ノードから返信されるRREPの「次の管理ノードID」には、当該送信先ノードのノードIDが登録される。「管理ノード設定間隔」フィールドには、前記管理ノードの設定間隔である「５」が登録される。「ホップ数カウンタ」フィールドには初期値の「０」が登録される。
【００２５】
ステップＳ２０３では、送信元ノードAを宛先とする経路表の「ノード状態フラグ」がセットされて管理ノードになる。ステップＳ２０４では、このRREPが送信元ノードAを宛先としてユニキャストで送信される。おのRREPを受信した経路上の各無線ノードでは、図４のステップＳ３，Ｓ８を経由してステップＳ１４のRREP受信処理へ進む。
【００２６】
図７は、前記RREP受信処理の手順を示したフローチャートであり、ステップＳ１４１では、受信したRREPに基づいて、送信先ノードKを宛先とする経路表が作成されると共に、当該RREPの「次の管理ノードID」フィールドに登録されている管理ノードIDが抽出され、前記経路表に「次の管理ノードID」として登録される。ステップＳ１４２では、当該RREPの宛先が自ノードであるか否かが判定され、宛先が自ノード以外であればステップＳ１４３へ進む。ステップＳ１４３では、当該RREPに登録されているホップ数カウンタの値、および管理ノード設定間隔に基づいて、自ノードが管理ノードの条件を満足しているか否かが判定される。
【００２７】
本実施形態では、RREPの「管理ノード設定間隔」フィールドに「５」が設定されており、前記無線ノードG，H，I，Jであれば、受信したRREPに登録されているホップ数カウンタの値が、それぞれ「０」，「１」，「２」，「３」なので、管理ノードの条件を満足していないと判定されてステップＳ１４８へ進む。ステップＳ１４８ではRREPが更新され、そのホップ数カウンタがインクリメント（＋１）される。
【００２８】
これに対して、前記無線ノードFであれば、受信したRREPに登録されているホップ数カウンタの値が「４」であり、自ノードが前の管理ノードから５ホップ目に位置していることが判るので、管理ノードの条件を満足していると判定してステップＳ１４４へ進む。ステップＳ１４４は、送信先ノードKを宛先とする経路表の「ノード状態フラグ」がセットされて管理ノードになる。ステップＳ１４５では当該RREPが更新され、そのホップ数カウンタがリセットされ、「次の管理ノード」フィールドが自ノード（ここでは、無線ノードF）のIDに書き換えられる。したがって、このRREPを受信する送信元側の各無線ノードB，C，D，Eでは、送信先ノードKを宛先とする経路表に「次の管理ノードID」として登録されている、送信先方向に直近の管理ノードFのIDが登録されることになる。
【００２９】
ステップＳ１４６では、新たに管理ノードとなった無線ノード（ここでは、無線ノードF）が、送信先側の各無線ノードG，H，I，Jの、送信元ノードAを宛先とする経路表に「次の管理ノードID」として自ノード（ここでは、無線ノードF）のIDを登録させるために、自ノードのIDが登録されたRREP_Ackを、送信先方向に直近の「次の管理ノードID」（ここでは、送信先ノードK）を宛先として送信する。ステップＳ１４７では、前記ステップＳ１４５またはＳ１４８で更新されたRREPが、経路上の次の隣接ノードへ転送される。
【００３０】
一方、このRREPを送信元ノードAが受信すると、前記ステップＳ１４２では宛先が自ノードと判定されるのでステップＳ１４９へ進み、経路表の「ノード状態フラグ」がセットされる。ステップＳ１５０では、前記ステップＳ１４６と同様に、自ノードIDが登録されたRREP_Ackを、その宛先を送信先方向に直近の管理ノード（ここでは、無線ノードF）に設定して送信する。
【００３１】
図９は、前記RREP受信処理が終了した時点での各無線ノードの経路表の登録内容を宛先別に示した図であり、宛先が送信先ノードKの経路表には、次ホップノードIDと共に次の管理ノードIDが登録されているのに対して、宛先が送信元ノードAの経路表には、次ホップノードIDのみが登録され、次の管理ノードIDは未登録のままである。
【００３２】
図４へ戻り、このRREP_Ackを受信した経路上の無線ノードでは、図４のステップＳ３，Ｓ９を経由してステップＳ１５のRREP受信処理へ進む。図８は、前記RREP_Ack受信処理の手順を示したフローチャートである。
【００３３】
ステップＳ１５１では、受信したRREP_Ackに登録されている管理ノードIDが抽出され、送信元ノードAを宛先とする経路表に「次の管理ノードID」として登録される。ステップＳ１５２では、当該RREP_Ackの宛先が自ノードであるか否かが判定される。自ノード以外が宛先であればステップＳ１５３へ進み、このRREP_Ackを経路上の隣接ノードへ転送する。自ノードが宛先であれば当該処理を終了する。
【００３４】
図１０は、前記RREP_Ack受信処理が終了した時点での各無線ノードの経路表の登録内容を示した図であり、送信元ノードAを宛先とする経路表でも「次の管理ノードID」に各管理ノードのIDが登録されている。
【００３５】
以上のようにして送信元ノードAと送信先ノードKとの間に経路が確立され、かつ管理ノードA，F，Kが登録されると、データパケットの転送が開始される。そして、いずれかのノード間で経路が消失すると、これを図４のステップＳ２で検知した無線ノードでは、ステップＳ６へ進んで経路修復処理が実行される。ここでは、前記図１に関して説明したように、無線ノードI，J間で経路が消失した場合を例にして説明する。
【００３６】
図１１は、前記経路修復処理の手順を示したフローチャートであり、ステップＳ６０１では、自ノードが当該経路の管理ノードであるか否かが判定される。経路消失を検知した無線ノードが管理ノードであればステップＳ６０３へ進み、送信先ノードKを宛先とする経路表に「次の管理ノードID」として登録されている、送信先方向に直近の管理ノード（ここでは、送信先ノードK）を宛先として、管理ノード間の局所的な経路探索を要求するRepair_REQ（経路修復要求）が送信される。このとき、Repair_REQに登録される管理シーケンス番号がインクリメントされる。
【００３７】
これに対して、経路消失を検知した無線ノードが、前記無線ノードIのように管理ノード以外であればステップＳ６０２へ進み、送信元ノードAを宛先とする経路表に「次の管理ノード」として登録されている、送信元方向に直近の管理ノードを宛先としてRERR（経路無効要求）が送信される。前記図１(b)に示した例では、無線ノードIから管理ノードFへRERRが送信される。このRERRには、送信元ノードIDおよび送信先ノードIDが登録されている。このRERRを受信した経路上の無線ノードでは、図４のステップＳ３，Ｓ１０を経由してステップＳ１６のRERR受信処理へ進む。
【００３８】
図１２は、前記RERR受信処理の手順を示したフローチャートであり、ステップＳ１６１では、受信したRERRに登録されている送信元ノードおよび送信先ノードを宛先とする経路表が無効化される。ステップＳ１６２では、RERRの宛先が自ノードであるか否かが判定される。宛先が自ノード以外であれば、ステップＳ１６３において当該RERRが隣接ノードへ転送される。
【００３９】
これに対して、前記図１(b)に関して説明した管理ノードFであれば、宛先が自ノードと判定されるのでステップＳ１６４へ進む。ステップＳ１６４では、送信先ノードKを宛先とする経路表に「次の管理ノードID」として登録されている、送信先方向に直近の管理ノード（ここでは、送信先ノードK）を宛先として、局所的な経路探索を要求するRepair_REQが送信される。このとき、Repair_REQに登録される管理シーケンス番号がインクリメントされる。
【００４０】
ステップＳ１６５では、このRepair_REQに対して宛先の管理ノードからRepair_REP（経路修復応答）が返信されたか否かが判定される。Repair_REPが返信されるよりも前に、ステップＳ１６６でタイムアウトが検知されるとステップＳ１６７へ進む。ステップＳ１６７では、前記図１(c)に関して説明したように、送信元ノードAを宛先としてRERRが転送される。これ以後は、従来技術と同様に送信元ノードAと送信先ノードKとの間で経路探索が行われて新たな経路が確立される。前記Repair_REQを受信した経路上の各無線ノードでは、ステップＳ３，Ｓ１１を経由してステップＳ１７のRepair_REQ受信処理へ進む。
【００４１】
図１３は、前記Repair_REQ受信処理の手順を示したフローチャートであり、ステップＳ１７１では、同一のRepair_REQを別経路で受信済みであるか否かが判定される。受信済みであれば、ステップＳ１７２へ進んで当該Repair_REQが破棄される。受信済みでなければステップＳ１７３へ進み、このRepair_REQの宛先に関して有効な経路表が自ノードに既登録であるか否かが判定される。
【００４２】
未登録であれば、ステップＳ１７４へ進んで経路表が作成される。既登録であればステップＳ１７８へ進み、当該Repair_REQに登録されている管理シーケンス番号と既登録の経路表に登録されている管理シーケンス番号とが比較される。Repair_REQに登録されている管理シーケンス番号の方が新しければ、ステップＳ１７９へ進んで既登録の経路表が更新される。
【００４３】
ステップＳ１７５では、受信したRepair_REQの宛先が自ノードであるか否かが判定される。宛先が自ノード以外であれば、ステップＳ１７６へ進んで当該Repair_REQが隣接ノードへ転送される。これに対して、送信先ノードKであれば宛先が自ノードと判定されるのでステップＳ１７７へ進み、前記管理ノードFを宛先としてRepair_REPがユニキャストで送信される。このRepair_REPを受信した経路上の各無線ノードでは、図４のステップＳ３，Ｓ１２を経由してステップＳ１８のRepair_REP受信処理へ進む。
【００４４】
図１４は、前記Repair_REP受信処理の手順を示したフローチャートであり、ステップＳ１８１では、受信したRepair_REPに基づいて経路表が作成される。ステップＳ１８２では、Repair_REPの宛先が自ノードであるか否かが判定される。宛先が自ノード以外であれば、ステップＳ１８３において当該Repair_REPが隣接ノードへ転送される。これに対して、宛先が自ノードである管理ノードFでは、当該時点で局所的な経路が確立されているので、当該経路を利用してデータパケットの転送が再開される。
【図面の簡単な説明】
【００４５】
【図１】本発明に係る経路修復方法の概要を模式的に表現した図である。
【図２】本実施形態における各無線ノードの構成を示した機能ブロック図である。
【図３】経路表の一例を示した図である。
【図４】メッセージパケット処理部の動作を示したフローチャートである。
【図５】RREQ受信処理の手順を示したフローチャートである。
【図６】RREP送信処理の手順を示したフローチャートである。
【図７】RREP受信処理の手順を示したフローチャートである。
【図８】RREP_Ack受信処理の手順を示したフローチャートである。
【図９】RREP受信処理が終了した時点での経路表の内容を示した図である。
【図１０】RREP_Ack受信処理が終了した時点での経路表の内容を示した図である。
【図１１】経路修復処理の手順を示したフローチャートである。
【図１２】RERR受信処理の手順を示したフローチャートである。
【図１３】Repair_REQ受信処理の手順を示したフローチャートである。
【図１４】Repair_REP受信処理の手順を示したフローチャートである。
【図１５】従来の経路修復手順を示した図である。
【符号の説明】
【００４６】
１０…メッセージパケット処理部，１１…経路表管理部，１２…データパケット処理部，１０１…RREQ処理部，１０２…RREP処理部，１０３…RERR処理部，１０４…RREP_Ack処理部，１０５…Repair_REQ処理部，１０６…Repair_REP処理部
【技術分野】
【０００１】
本発明は、アドホックネットワークの経路修復方法に係り、特に、送信元ノードと送信先ノードとの間のホップ数が大きくなる大規模のアドホックネットワークに好適な経路修復方法に関する。
【背景技術】
【０００２】
無線ノードが互いに通信を行うアドホックネットワーク上でパケット通信を行う技術としてAODV（Adhoc On-demand Distance Vector）ルーティングプロトコルが知られている。AODVによれば、パケットの発信元と送信先とが直接通信できない場合であっても、送信元ノードと送信先ノードとの間に存在する１又は複数の無線ノードにパケットを中継させることにより、送信元と送信先との間でデータ転送を行うことができる。
【０００３】
オンデマンド型のルーティングプロトコルを用いた無線アドホックネットワークにおいて、経路の一部が切断されときに通信経路を修復するためのパケットをブロードキャストで送信して経路を再構築する技術が特許文献１に開示されている。
【０００４】
図１５は、従来の経路再構築手順を示した図であり、同図(a)に示したように、ノードA（送信元）→ノードB→ノードC→ノードD→ノードE（送信先）という経路でパケットが送信されているときに、ノードD，E間の経路が消失し、これがノードDで検知されると、ノードDでは以下の２通りの経路修復が実行される。
【０００５】
第１の経路修復手順では、同図(b)に示したように、ノードDから送信元側の経路にRERR（経路無効通知）メッセージが送信される。このRERRはノードC→ノードBの経路でノードAに至る。前記RERRを受け取ったノードAでは、改めてノードEを送信先とするRREQ（経路要求）がフラッディングされ、このRREQを受け取ったノードEがRREP（経路応答）をノードAに返信することにより経路が再構築される。
【０００６】
第２の経路修復手順では、同図(c)に示したように、ノードDが自ら、ノードEを送信先とするRREQをフラッディングしてノードEとの間に別の経路を確立する。
【特許文献１】特開２００５−２６９６２３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
第１の経路修復手順は、送信元ノードと送信先ノードとの間のホップ数が小さい小規模のネットワークには有効であるが、送信元と送信先との間のホップ数が大きい大規模のネットワークでは、RERRが辿る経路や、その後のRREQおよびRREPが辿る経路が長くなるので、経路維持の負荷が大きくなってしまう。
【０００８】
同様に、第２の経路修復手順でも、経路の消失を検知したノード（前記ノードD）と送信先ノード（前記ノードE）とが離れていると、RREQおよびRREPが辿る経路が長くなるので、経路維持の負荷が大きくなってしまう。
【０００９】
本発明の目的は、上記した従来技術の課題を解決し、送信元と送信先との間のホップ数が大きい大規模のアドホックネットワークにおいて小さな負荷で経路を修復できる経路修復方法を提供することにある。
【課題を解決するための手段】
【００１０】
上記した目的を達成するために、本発明は、アドホックネットワークにおいて、送信元ノードから複数のノードを中継して送信先ノードへ至る経路を修復する経路修復方法において、送信元ノードと送信先ノードとの間に、所定のノード間隔で管理ノードが配置された経路を確立する手順と、経路消失を検知したノードが、送信元方向で直近の第１管理ノードを宛先とする経路無効通知を送信する手順と、第１管理ノードが前記経路無効通知に応答して、送信先方向で直近の第２管理ノードを宛先とする経路修復要求を送信する手順と、経路修復要求を中継する各ノードが、前記第１管理ノード向けの経路表を生成する手順と、第２管理ノードが前記経路修復要求に応答して、前記第１管理ノードを宛先とする経路修復応答を送信する手順と、経路修復応答を中継する各ノードが、前記第２管理ノード向けの経路表を生成する手順とを含むことを特徴とする。
【発明の効果】
【００１１】
本発明によれば、経路生成時に送信元ノードと送信先ノードの間に一定間隔で管理ノードが配置され、経路が消失すると、当該消失区間を挟んだ管理ノード間で局所的に経路修復が行われるので、経路修復要求パケットのブロードキャスト範囲を限定することができ、その結果、制御オーバーヘッドを減らすことができる。
【発明を実施するための最良の形態】
【００１２】
以下、図面を参照して本発明の最良の実施の形態について詳細に説明する。図１は、本発明に係る経路修復方法の概要を模式的に表現した図であり、ここでは、同図(a)に示したように、送信元ノードAと送信先ノードKとの間に９個の無線ノードB，C…Jを中継する経路が確立されており、経路上では所定のホップ数ごとに管理ノードが配置されている。本実施形態では、二重丸で表現した送信元ノードAおよび送信先ノードK、ならびに無線ノードFが管理ノードとして登録されており、経路上の各無線ノードは、送信先方向で直近の管理ノードおよび送信元方向で直近の管理ノードをそれぞれ認識している。すなわち、無線ノードB，C，D，Eは、無線ノードFを送信先方向の管理ノードと認識し、送信元ノードAを送信元方向の管理ノードと認識している。同様に、無線ノードG，H，I，Jは、送信先ノードKを送信先方向の管理ノードと認識し、無線ノードFを送信元方向の管理ノードと認識している。
【００１３】
このような経路において、同図(b)に示したように、無線ノードI，J間の経路が消失すると、これを検知した無線ノードIが送信元方向で直近の管理ノードFを宛先としてRERR（経路無効通知）を送信する。このRERRを受信した管理ノードFは、送信先方向で直近の管理ノード（ここでは、送信先ノードK）を宛先とするRepair_REQ（経路修復要求）を送信して局所的な経路修復を実施し、消失した経路をバイパスする新たな経路を２つの管理ノードF，K間に確立する。
【００１４】
なお、管理ノードFは送信先ノードKとの間に新たな経路を確立できないと、同図(c)に示したように、送信元ノードAを宛先としてRERRを送信する。このRERRを受信した送信元ノードAは、送信先ノードKを宛先とする経路探索を実施して新たな経路を確立する。
【００１５】
図２は、本実施形態における各無線ノードの構成を示した機能ブロック図であり、ここでは、本発明の説明に不要な構成は図示が省略されている。
【００１６】
各無線ノードは、経路確立や経路修復のための各種メッセージパケットを生成、送信、受信、中継および破棄するメッセージパケット処理部１０と、経路表を宛先ごとに生成して管理する経路表管理部１１と、前記経路表管理部１１に登録されている経路表を利用してデータパケットを転送するデータパケット処理部１２とを主要な構成としている。前記メッセージパケット処理部１０は、後に詳述するRREQ（経路要求）処理部１０１、RREP（経路応答）処理部１０２、RERR（経路無効通知）処理部１０３、RREP_Ack処理部１０４、Repair_REQ（経路修復要求）処理部１０５およびRepair_REP（経路修復応答）処理部１０６を備えている。
【００１７】
図３は、前記経路表の一例を示した図であり、「宛先ノードID」ごとに、「次の管理ノードID」、「経路シーケンス番号」、「管理シーケンス番号」、「次の管理ノードまでのホップ数」、「次ホップノードID」および「ノード状態フラグ」等が登録されている。前記「ノード状態フラグ」には、自ノードが管理ノードであるか否かを示すフラグがセットされる。
【００１８】
次いで、本発明に係る経路修復方法をフローチャートに沿って説明する。図４は、各無線ノードにおける前記メッセージパケット処理部１０の動作を示したフローチャートであり、ステップＳ１では通信要求の有無が判定され、ステップＳ２では経路消失が検知されたか否かが判定され、ステップＳ３ではメッセージパケットが受信されたか否かが判定される。本実施形態では、前記図１に関して説明したように、無線ノードAにおいて無線ノードBを送信先とする通信要求が発生した場合を例にして説明する。
【００１９】
ステップＳ１で通信要求を検知した無線ノードAはステップＳ４へ進み、送信先ノードBに関して有効な経路表が前記経路表管理部１１に既登録であるか否かが判定される。既登録であれば、データパケットの送信処理へ進み、未登録であればステップＳ５へ進む。ステップＳ５では、従来のAODVと同様に、送信元ノードAのノードIDおよび送信先ノードKのノードIDの登録され、経路シーケンス番号がインクリメントされたRREQがブロードキャストで隣接ノードへ送信される。このRREQは、隣接する無線ノードにおいてステップＳ７で受信され、当該隣接する無線ノードでは、ステップＳ３，Ｓ７を経由してステップＳ１３のRREQ受信処理へ進む。
【００２０】
図５は、前記RREQ受信処理の手順を示したフローチャートであり、ステップＳ１３１では、同一のRREQを別経路で受信済みであるか否かが判定される。受信済みであれば、ステップＳ１３２へ進んで当該RREQが破棄される。受信済みでなければステップＳ１３３へ進み、このRREQの宛先に関して有効な経路表が自ノードに既登録であるか否かが判定される。
【００２１】
未登録であれば、ステップＳ１３４へ進んで経路表が作成される。既登録であればステップＳ１３８へ進み、当該RREQに登録されている経路シーケンス番号と既登録の経路表に登録されている経路シーケンス番号とが比較される。RREQに登録されている経路シーケンス番号の方が新しければ、ステップＳ１３９へ進んで既登録の経路表が更新される。
【００２２】
ステップＳ１３５では、RREQの宛先が自ノードであるか否かが判定される。宛先が自ノード以外であれば、ステップＳ１３６において当該RREQがブロードキャストで隣接ノードへ転送される。このRREQを受信した他の無線ノードでも、当該RREQ受信処理が同様に実行される。これに対して、宛先が自ノードであれば、RREPを返信すべくステップＳ１３７のRREP送信処理へ進む。
【００２３】
図６は、前記RREP送信処理の手順を示したフローチャートであり、ステップＳ２０１では、送信元／送信先ノード間の総ホップ数に基づいて、管理ノードの設定間隔が等間隔または略等間隔に決定される。ここでは、管理ノードの設定間隔が「５」ホップに決定されたものとして説明を続ける。ステップＳ２０２ではRREPが生成される。このRREPには、従来のAODVで確保されている「送信元ノードID」や「送信先ノードID」等の各種フィールドに加えて、後述する「次の管理ノードID」フィールド、「ホップ数カウンタ」フィールド、「管理ノード設定間隔」フィールド等が確保されている。
【００２４】
前記「次の管理ノードID」には、管理ノードとなった無線ノードの自ノードIDが登録される。本実施形態では、送信元ノードおよび送信先ノードは管理ノードとなるので、送信先ノードから返信されるRREPの「次の管理ノードID」には、当該送信先ノードのノードIDが登録される。「管理ノード設定間隔」フィールドには、前記管理ノードの設定間隔である「５」が登録される。「ホップ数カウンタ」フィールドには初期値の「０」が登録される。
【００２５】
ステップＳ２０３では、送信元ノードAを宛先とする経路表の「ノード状態フラグ」がセットされて管理ノードになる。ステップＳ２０４では、このRREPが送信元ノードAを宛先としてユニキャストで送信される。おのRREPを受信した経路上の各無線ノードでは、図４のステップＳ３，Ｓ８を経由してステップＳ１４のRREP受信処理へ進む。
【００２６】
図７は、前記RREP受信処理の手順を示したフローチャートであり、ステップＳ１４１では、受信したRREPに基づいて、送信先ノードKを宛先とする経路表が作成されると共に、当該RREPの「次の管理ノードID」フィールドに登録されている管理ノードIDが抽出され、前記経路表に「次の管理ノードID」として登録される。ステップＳ１４２では、当該RREPの宛先が自ノードであるか否かが判定され、宛先が自ノード以外であればステップＳ１４３へ進む。ステップＳ１４３では、当該RREPに登録されているホップ数カウンタの値、および管理ノード設定間隔に基づいて、自ノードが管理ノードの条件を満足しているか否かが判定される。
【００２７】
本実施形態では、RREPの「管理ノード設定間隔」フィールドに「５」が設定されており、前記無線ノードG，H，I，Jであれば、受信したRREPに登録されているホップ数カウンタの値が、それぞれ「０」，「１」，「２」，「３」なので、管理ノードの条件を満足していないと判定されてステップＳ１４８へ進む。ステップＳ１４８ではRREPが更新され、そのホップ数カウンタがインクリメント（＋１）される。
【００２８】
これに対して、前記無線ノードFであれば、受信したRREPに登録されているホップ数カウンタの値が「４」であり、自ノードが前の管理ノードから５ホップ目に位置していることが判るので、管理ノードの条件を満足していると判定してステップＳ１４４へ進む。ステップＳ１４４は、送信先ノードKを宛先とする経路表の「ノード状態フラグ」がセットされて管理ノードになる。ステップＳ１４５では当該RREPが更新され、そのホップ数カウンタがリセットされ、「次の管理ノード」フィールドが自ノード（ここでは、無線ノードF）のIDに書き換えられる。したがって、このRREPを受信する送信元側の各無線ノードB，C，D，Eでは、送信先ノードKを宛先とする経路表に「次の管理ノードID」として登録されている、送信先方向に直近の管理ノードFのIDが登録されることになる。
【００２９】
ステップＳ１４６では、新たに管理ノードとなった無線ノード（ここでは、無線ノードF）が、送信先側の各無線ノードG，H，I，Jの、送信元ノードAを宛先とする経路表に「次の管理ノードID」として自ノード（ここでは、無線ノードF）のIDを登録させるために、自ノードのIDが登録されたRREP_Ackを、送信先方向に直近の「次の管理ノードID」（ここでは、送信先ノードK）を宛先として送信する。ステップＳ１４７では、前記ステップＳ１４５またはＳ１４８で更新されたRREPが、経路上の次の隣接ノードへ転送される。
【００３０】
一方、このRREPを送信元ノードAが受信すると、前記ステップＳ１４２では宛先が自ノードと判定されるのでステップＳ１４９へ進み、経路表の「ノード状態フラグ」がセットされる。ステップＳ１５０では、前記ステップＳ１４６と同様に、自ノードIDが登録されたRREP_Ackを、その宛先を送信先方向に直近の管理ノード（ここでは、無線ノードF）に設定して送信する。
【００３１】
図９は、前記RREP受信処理が終了した時点での各無線ノードの経路表の登録内容を宛先別に示した図であり、宛先が送信先ノードKの経路表には、次ホップノードIDと共に次の管理ノードIDが登録されているのに対して、宛先が送信元ノードAの経路表には、次ホップノードIDのみが登録され、次の管理ノードIDは未登録のままである。
【００３２】
図４へ戻り、このRREP_Ackを受信した経路上の無線ノードでは、図４のステップＳ３，Ｓ９を経由してステップＳ１５のRREP受信処理へ進む。図８は、前記RREP_Ack受信処理の手順を示したフローチャートである。
【００３３】
ステップＳ１５１では、受信したRREP_Ackに登録されている管理ノードIDが抽出され、送信元ノードAを宛先とする経路表に「次の管理ノードID」として登録される。ステップＳ１５２では、当該RREP_Ackの宛先が自ノードであるか否かが判定される。自ノード以外が宛先であればステップＳ１５３へ進み、このRREP_Ackを経路上の隣接ノードへ転送する。自ノードが宛先であれば当該処理を終了する。
【００３４】
図１０は、前記RREP_Ack受信処理が終了した時点での各無線ノードの経路表の登録内容を示した図であり、送信元ノードAを宛先とする経路表でも「次の管理ノードID」に各管理ノードのIDが登録されている。
【００３５】
以上のようにして送信元ノードAと送信先ノードKとの間に経路が確立され、かつ管理ノードA，F，Kが登録されると、データパケットの転送が開始される。そして、いずれかのノード間で経路が消失すると、これを図４のステップＳ２で検知した無線ノードでは、ステップＳ６へ進んで経路修復処理が実行される。ここでは、前記図１に関して説明したように、無線ノードI，J間で経路が消失した場合を例にして説明する。
【００３６】
図１１は、前記経路修復処理の手順を示したフローチャートであり、ステップＳ６０１では、自ノードが当該経路の管理ノードであるか否かが判定される。経路消失を検知した無線ノードが管理ノードであればステップＳ６０３へ進み、送信先ノードKを宛先とする経路表に「次の管理ノードID」として登録されている、送信先方向に直近の管理ノード（ここでは、送信先ノードK）を宛先として、管理ノード間の局所的な経路探索を要求するRepair_REQ（経路修復要求）が送信される。このとき、Repair_REQに登録される管理シーケンス番号がインクリメントされる。
【００３７】
これに対して、経路消失を検知した無線ノードが、前記無線ノードIのように管理ノード以外であればステップＳ６０２へ進み、送信元ノードAを宛先とする経路表に「次の管理ノード」として登録されている、送信元方向に直近の管理ノードを宛先としてRERR（経路無効要求）が送信される。前記図１(b)に示した例では、無線ノードIから管理ノードFへRERRが送信される。このRERRには、送信元ノードIDおよび送信先ノードIDが登録されている。このRERRを受信した経路上の無線ノードでは、図４のステップＳ３，Ｓ１０を経由してステップＳ１６のRERR受信処理へ進む。
【００３８】
図１２は、前記RERR受信処理の手順を示したフローチャートであり、ステップＳ１６１では、受信したRERRに登録されている送信元ノードおよび送信先ノードを宛先とする経路表が無効化される。ステップＳ１６２では、RERRの宛先が自ノードであるか否かが判定される。宛先が自ノード以外であれば、ステップＳ１６３において当該RERRが隣接ノードへ転送される。
【００３９】
これに対して、前記図１(b)に関して説明した管理ノードFであれば、宛先が自ノードと判定されるのでステップＳ１６４へ進む。ステップＳ１６４では、送信先ノードKを宛先とする経路表に「次の管理ノードID」として登録されている、送信先方向に直近の管理ノード（ここでは、送信先ノードK）を宛先として、局所的な経路探索を要求するRepair_REQが送信される。このとき、Repair_REQに登録される管理シーケンス番号がインクリメントされる。
【００４０】
ステップＳ１６５では、このRepair_REQに対して宛先の管理ノードからRepair_REP（経路修復応答）が返信されたか否かが判定される。Repair_REPが返信されるよりも前に、ステップＳ１６６でタイムアウトが検知されるとステップＳ１６７へ進む。ステップＳ１６７では、前記図１(c)に関して説明したように、送信元ノードAを宛先としてRERRが転送される。これ以後は、従来技術と同様に送信元ノードAと送信先ノードKとの間で経路探索が行われて新たな経路が確立される。前記Repair_REQを受信した経路上の各無線ノードでは、ステップＳ３，Ｓ１１を経由してステップＳ１７のRepair_REQ受信処理へ進む。
【００４１】
図１３は、前記Repair_REQ受信処理の手順を示したフローチャートであり、ステップＳ１７１では、同一のRepair_REQを別経路で受信済みであるか否かが判定される。受信済みであれば、ステップＳ１７２へ進んで当該Repair_REQが破棄される。受信済みでなければステップＳ１７３へ進み、このRepair_REQの宛先に関して有効な経路表が自ノードに既登録であるか否かが判定される。
【００４２】
未登録であれば、ステップＳ１７４へ進んで経路表が作成される。既登録であればステップＳ１７８へ進み、当該Repair_REQに登録されている管理シーケンス番号と既登録の経路表に登録されている管理シーケンス番号とが比較される。Repair_REQに登録されている管理シーケンス番号の方が新しければ、ステップＳ１７９へ進んで既登録の経路表が更新される。
【００４３】
ステップＳ１７５では、受信したRepair_REQの宛先が自ノードであるか否かが判定される。宛先が自ノード以外であれば、ステップＳ１７６へ進んで当該Repair_REQが隣接ノードへ転送される。これに対して、送信先ノードKであれば宛先が自ノードと判定されるのでステップＳ１７７へ進み、前記管理ノードFを宛先としてRepair_REPがユニキャストで送信される。このRepair_REPを受信した経路上の各無線ノードでは、図４のステップＳ３，Ｓ１２を経由してステップＳ１８のRepair_REP受信処理へ進む。
【００４４】
図１４は、前記Repair_REP受信処理の手順を示したフローチャートであり、ステップＳ１８１では、受信したRepair_REPに基づいて経路表が作成される。ステップＳ１８２では、Repair_REPの宛先が自ノードであるか否かが判定される。宛先が自ノード以外であれば、ステップＳ１８３において当該Repair_REPが隣接ノードへ転送される。これに対して、宛先が自ノードである管理ノードFでは、当該時点で局所的な経路が確立されているので、当該経路を利用してデータパケットの転送が再開される。
【図面の簡単な説明】
【００４５】
【図１】本発明に係る経路修復方法の概要を模式的に表現した図である。
【図２】本実施形態における各無線ノードの構成を示した機能ブロック図である。
【図３】経路表の一例を示した図である。
【図４】メッセージパケット処理部の動作を示したフローチャートである。
【図５】RREQ受信処理の手順を示したフローチャートである。
【図６】RREP送信処理の手順を示したフローチャートである。
【図７】RREP受信処理の手順を示したフローチャートである。
【図８】RREP_Ack受信処理の手順を示したフローチャートである。
【図９】RREP受信処理が終了した時点での経路表の内容を示した図である。
【図１０】RREP_Ack受信処理が終了した時点での経路表の内容を示した図である。
【図１１】経路修復処理の手順を示したフローチャートである。
【図１２】RERR受信処理の手順を示したフローチャートである。
【図１３】Repair_REQ受信処理の手順を示したフローチャートである。
【図１４】Repair_REP受信処理の手順を示したフローチャートである。
【図１５】従来の経路修復手順を示した図である。
【符号の説明】
【００４６】
１０…メッセージパケット処理部，１１…経路表管理部，１２…データパケット処理部，１０１…RREQ処理部，１０２…RREP処理部，１０３…RERR処理部，１０４…RREP_Ack処理部，１０５…Repair_REQ処理部，１０６…Repair_REP処理部
【特許請求の範囲】
【請求項１】
アドホックネットワークにおいて、送信元ノードから複数のノードを中継して送信先ノードへ至る経路を修復する経路修復方法において、
送信元ノードと送信先ノードとの間に、所定のノード間隔で管理ノードが配置された経路を確立する手順と、
経路消失を検知したノードが、送信元方向で直近の第１管理ノードを宛先とする経路無効通知を送信する手順と、
前記第１管理ノードが前記経路無効通知に応答して、送信先方向で直近の第２管理ノードを宛先とする経路修復要求を送信する手順と、
前記経路修復要求を中継する各ノードが、前記第１管理ノード向けの経路表を生成する手順と、
前記第２管理ノードが前記経路修復要求に応答して、前記第１管理ノードを宛先とする経路修復応答を送信する手順と、
前記経路修復応答を中継する各ノードが、前記第２管理ノード向けの経路表を生成する手順とを含むことを特徴とするアドホックネットワークの経路修復方法。
【請求項２】
経路消失を検知した管理ノードが、送信先方向で直近の管理ノードを宛先とする経路修復要求を送信する手順を含むことを特徴とする請求項１に記載のアドホックネットワークの経路修復方法。
【請求項３】
前記第１管理ノードが、前記経路修復要求に対して前記経路修復応答を受信できないときに、送信元ノードを宛先とする経路無効通知を送信する手順と、
前記送信元ノードが前記経路無効通知に応答して、前記送信先ノードを宛先とする経路要求を送信する手順と、
前記送信先ノードが前記経路要求に応答して、前記送信元ノードを宛先とする経路応答を送信する手順とを含むことを特徴とする請求項１または２に記載のアドホックネットワークの経路修復方法。
【請求項４】
前記管理ノードが配置された経路を確立する手順が、
送信元ノードから送信先ノードを宛先とする経路要求を送信する手順と、
前記経路要求を中継する各ノードが、送信元を宛先とする経路表を生成する手順と、
送信先ノードが前記経路要求に応答して、管理ノード条件、および管理ノードIDとして自ノードIDが登録され、送信元ノードを宛先とする経路応答を送信する手順と、
前記経路応答を中継する各ノードが、送信先を宛先とする経路表を生成する手順と、
前記経路応答を中継する各ノードが、当該経路応答に登録されている管理ノードIDを、送信先方向で直近の管理ノードのIDとして登録する手順と、
前記経路応答を中継するノードのうち、前記経路応答に登録されている管理ノード条件を満足するノードが自ノードを管理ノードとして登録する手順と、
前記管理ノードが、中継する経路応答の管理ノードIDを自ノードIDに変更する手順と、
前記管理ノードが、管理ノードIDとして自ノードIDを含む経路応答Ackを、送信先方向で直近の管理ノードを宛先として送信する手順と、
前記経路応答Ackを中継する各ノードが、当該経路応答Ackに登録されている管理ノードIDを、送信元方向で直近の管理ノードのIDとして登録する手順とを含むことを特徴とする請求項１ないし３のいずれかに記載のアドホックネットワークの経路修復方法。
【請求項５】
前記管理ノード条件が、管理ノードを設置するホップ数の間隔であることを特徴とする請求項４に記載のアドホックネットワークの経路修復方法。
【請求項１】
アドホックネットワークにおいて、送信元ノードから複数のノードを中継して送信先ノードへ至る経路を修復する経路修復方法において、
送信元ノードと送信先ノードとの間に、所定のノード間隔で管理ノードが配置された経路を確立する手順と、
経路消失を検知したノードが、送信元方向で直近の第１管理ノードを宛先とする経路無効通知を送信する手順と、
前記第１管理ノードが前記経路無効通知に応答して、送信先方向で直近の第２管理ノードを宛先とする経路修復要求を送信する手順と、
前記経路修復要求を中継する各ノードが、前記第１管理ノード向けの経路表を生成する手順と、
前記第２管理ノードが前記経路修復要求に応答して、前記第１管理ノードを宛先とする経路修復応答を送信する手順と、
前記経路修復応答を中継する各ノードが、前記第２管理ノード向けの経路表を生成する手順とを含むことを特徴とするアドホックネットワークの経路修復方法。
【請求項２】
経路消失を検知した管理ノードが、送信先方向で直近の管理ノードを宛先とする経路修復要求を送信する手順を含むことを特徴とする請求項１に記載のアドホックネットワークの経路修復方法。
【請求項３】
前記第１管理ノードが、前記経路修復要求に対して前記経路修復応答を受信できないときに、送信元ノードを宛先とする経路無効通知を送信する手順と、
前記送信元ノードが前記経路無効通知に応答して、前記送信先ノードを宛先とする経路要求を送信する手順と、
前記送信先ノードが前記経路要求に応答して、前記送信元ノードを宛先とする経路応答を送信する手順とを含むことを特徴とする請求項１または２に記載のアドホックネットワークの経路修復方法。
【請求項４】
前記管理ノードが配置された経路を確立する手順が、
送信元ノードから送信先ノードを宛先とする経路要求を送信する手順と、
前記経路要求を中継する各ノードが、送信元を宛先とする経路表を生成する手順と、
送信先ノードが前記経路要求に応答して、管理ノード条件、および管理ノードIDとして自ノードIDが登録され、送信元ノードを宛先とする経路応答を送信する手順と、
前記経路応答を中継する各ノードが、送信先を宛先とする経路表を生成する手順と、
前記経路応答を中継する各ノードが、当該経路応答に登録されている管理ノードIDを、送信先方向で直近の管理ノードのIDとして登録する手順と、
前記経路応答を中継するノードのうち、前記経路応答に登録されている管理ノード条件を満足するノードが自ノードを管理ノードとして登録する手順と、
前記管理ノードが、中継する経路応答の管理ノードIDを自ノードIDに変更する手順と、
前記管理ノードが、管理ノードIDとして自ノードIDを含む経路応答Ackを、送信先方向で直近の管理ノードを宛先として送信する手順と、
前記経路応答Ackを中継する各ノードが、当該経路応答Ackに登録されている管理ノードIDを、送信元方向で直近の管理ノードのIDとして登録する手順とを含むことを特徴とする請求項１ないし３のいずれかに記載のアドホックネットワークの経路修復方法。
【請求項５】
前記管理ノード条件が、管理ノードを設置するホップ数の間隔であることを特徴とする請求項４に記載のアドホックネットワークの経路修復方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【公開番号】特開２００８−２８３２６０（Ｐ２００８−２８３２６０Ａ）
【公開日】平成２０年１１月２０日（２００８．１１．２０）
【国際特許分類】
【出願番号】特願２００７−１２３３４１（Ｐ２００７−１２３３４１）
【出願日】平成１９年５月８日（２００７．５．８）
【国等の委託研究の成果に係る記載事項】（出願人による申告）「戦略的情報通信研究開発推進制度」による平成１８年度 「モバイルアドホックネットワークにおけるスケーラブルグループメンバー確認技術に関する研究開発」委託研究、産業再生法第３０条の適用を受ける特許出願
【出願人】（０００２０８８９１）ＫＤＤＩ株式会社 (2,700)
【出願人】（５０６１１１０３３）
【出願人】（５０７１４９７７４）
【Ｆターム（参考）】
【公開日】平成２０年１１月２０日（２００８．１１．２０）
【国際特許分類】
【出願日】平成１９年５月８日（２００７．５．８）
【国等の委託研究の成果に係る記載事項】（出願人による申告）「戦略的情報通信研究開発推進制度」による平成１８年度 「モバイルアドホックネットワークにおけるスケーラブルグループメンバー確認技術に関する研究開発」委託研究、産業再生法第３０条の適用を受ける特許出願
【出願人】（０００２０８８９１）ＫＤＤＩ株式会社 (2,700)
【出願人】（５０６１１１０３３）
【出願人】（５０７１４９７７４）
【Ｆターム（参考）】
[ Back to top ]