JP4158972B2 - マルチホップ通信方法 - Google Patents

Description

本発明はマルチホップ通信方法に係り、特に、アドホックなネットワークにおいて、通信キャリアによる課金が容易であり、かつ通信の安全性に優れたマルチホップ通信方法に関する。

近年、1xEV-DOや無線LAN等の種々の無線アクセス方式の普及および通信速度の向上により、モバイルユーザの通信事情は格段に向上しつつある。広域網は全国的に展開されており、ほとんどのエリアがカバーされている。無線LANにおいては、通信範囲は狭いが数十Mbpsのスループットを提供可能である。

このような無線通信技術の向上および普及により、通信端末を保持したユーザがいたるところに点在するという状況を利用して、通信端末同士でアドホックにネットワークを構成し、既存インフラを使わずに通信する方式が広く検討されている。

このようなアドホックモードでは、端末同士の通信は１対１で行われるが、これをさらに拡張し、アドホックルーティング技術を利用することにより、自分に隣接した相手のみならず、離れた相手に対しても、間に位置する端末が中継ノードとなるマルチホップ通信が提案され、例えば特許文献１に開示されている。アドホックルーティングに関しては様々な方式が活発に検討されているが、中でもAODV(RFC-3561）、DSR(draft-ietf-manet-dsr-09.txt）は非常に注目されるアドホックルーティングプロトコルである。
特開２００３−２７３７８８号公報

従来のアドホックルーティングには以下のような技術課題がある。第１に、通信キャリアが個々の通信に関与できないために、課金や固有サービスの提供が困難であること。第２に、通信の高い安全性を確保することが困難であること。

第２の課題についてさらに具体的に説明すれば、アドホックに構築される無線ネットワークには正しい動作をするノードだけが存在するとは限らない。場合によっては、悪意の第三者が存在し、さまざまな攻撃を行うこともあり得る。アドホックルーティング技術では、端末から送信されたデータパケットが複数の中継ノードを経由することになるが、従来のアドホックルーティング技術では、途中の中継ノードに不正を働く者がいたとしても、それを知ることが困難である。

また、従来のルーティング技術では、相互に通信を行うエンド端末（送信元端末および宛先端末）が送信パケットに対して、相手端末を一意に特定できる固有アドレスを登録する必要があった。このために、通信を行っているエンド端末が中継ノード全体に知れてしまい、通信の匿名性が著しく失われてしまう。

本発明の目的は、上記した従来技術の課題を解決し、無線LANなどで構成されるアドホックなマルチホップネットワークにおいて、通信キャリアによる課金が容易であり、かつ通信の安全性に優れたマルチホップ通信方法を提供することにある。

上記した目的を達成するために、本発明は、複数の端末(S，T…X)および少なくとも一つの経路制御サーバ(RM)を含み、送信元の端末と宛先の端末とが中継用の端末を介して通信を行うマルチホップ通信方法において、以下の手順を含むことを特徴とする。

(1)送信元端末(S)が、宛先端末(T)を指定した経路確立開始要求(RST)を経路制御サーバ(RM)へ送信する第１手順と、前記経路制御サーバ(RM)が非対称暗号鍵ペア(KS，Ks)を生成する第２手順と、前記経路制御サーバが、前記暗号鍵ペア(KS，Ks)を送信元端末(S)および宛先端末(T)へ通知する第３手順と、前記送信元端末(S)が、自端末に固有のホップ情報(from，to，IPs，Ts)を前記暗号鍵ペアの一方(Ks)で暗号化して暗号化情報を生成する第４手順と、前記送信元端末(S)が、前記一方の暗号鍵(Ks)および前記暗号化情報を含むRREQパケットをブロードキャストする第５手順と、

前記RREQを受信した端末であって、その宛先以外の端末が、当該RREQに既登録の暗号化情報を、自端末に固有のホップ情報と共に、当該RREQに含まれる前記一方の暗号鍵(Ks)で再暗号化する第６手順と、前記宛先以外の端末が、前記一方の暗号鍵(Ks)および前記再暗号化された暗号化情報を含むRREQをブロードキャストする第７手順と、前記RREQを受信した他の端末であって、その宛先以外の各端末が、前記第６および第７手順を繰り返す第８手順と、前記RREQを受信した宛先端末(T)が、その暗号化情報を前記暗号鍵ペア(KS，Ks)で順次に復号化する第９手順と、前記宛先端末(T)が、前記復号化された各ホップ情報に基づいて、送信元端末(S)から宛先端末(T)へ至るホップリストを生成する第１０手順と、前記宛先端末(T)が経路制御サーバ(RM)へ、前記ホップリストを通知する第１１手順と、前記経路制御サーバ(RM)が、前記通知されたホップリストに基づいて、前記送信元端末(S)および宛先端末(T)間に通信経路を確立する第１２手順とを含む。

(2)確立された経路が切断されたときに、この切断リンクを挟んで対向する一対のリンク切れ端末の一方が前記経路制御サーバ(RM)へリンクダウンを通知する第１３手順と、前記経路制御サーバ(RM)が、送信元端末(S)から切断リンクへ至る第１経路および宛先端末(T)から切断リンク切れ端末へ至る経路の一方を選択する第１４手順と、前記選択された経路のエンド端末（送信元端末または宛先端末）が他方のエンド端末（宛先端末または送信元端末）との間に経路を確立しようとする際に送信するRREQを前記選択された経路のリンク切れ端末が受信して中継する際に送信すると予測されるRREQと同等のRRPRパケットの送信を、前記経路制御サーバが前記選択された経路のリンク切れ端末へ指示する第１５手順と、前記RRPRの送信を指示されたリンク切れ端末がRRPRを送信する第１６手順と、前記RRPRを受信した端末であって、前記他方のエンド端末以外の端末が、当該RRPRに既登録の暗号化情報を、自端末に固有のホップ情報と共に、当該RRPRに含まれる前記一方の暗号鍵(Ks)で再暗号化する第１７手順と、前記他方のエンド端末以外の端末が、前記一方の暗号鍵(Ks)および前記再暗号化された暗号化情報を含むRRPRをブロードキャストする第１８手順と、前記RRPRを受信した他の端末であって、前記他方のエンド端末以外の各端末が、前記第１７および第１８手順を繰り返す第１９手順と、前記RRPRを受信した他方のエンド端末が、その暗号化情報を前記暗号鍵ペア(KS，Ks)で順次に復号化する第２０手順と、前記他方のエンド端末が、前記復号化された各端末のホップ情報に基づいて、前記一方のエンド端末から他方のエンド端末へ至るホップリストを生成する第２１手順と、前他方のエンド端末が経路制御サーバ(RM)へ、前記ホップリストを通知する第２２手順と、前記経路制御サーバ(RM)が、前記通知されたホップリストに基づいて、前記各エンド端末間に通信経路を確立する第２３手順とを含む。

本発明によれば、以下のような効果が達成される。
(1)エンド端末間に通信経路を確立するための手順に経路制御サーバが介入できるので、通信キャリアが経路制御サーバを管理するようにすれば、課金や各種サービスの提供が容易になる。
(2)RREQを中継する端末は、当該RREQに追加登録する自身のホップ情報を暗号化するので、他の端末がRREQを参照しても、このRREQにより生成される経路やそのエンド端末を認識できない。
(3)宛先端末(T)は、RREQに含まれる暗号化情報を復号化して得られるホップ情報の正当性を確認し、正当性が確認された場合のみ、このホップ情報に基づいて生成したホップリストを経路制御サーバ(RM)へ通知するので、改竄されたホップ情報に基づいてホップリストが生成されることがない。
(4)経路制御サーバ(RM)は、宛先端末(T)から通知されたホップリストの正当性を確認し、正当性が確認された場合のみ、このホップリストに基づいて通信経路を確立するので、改竄されたホップリストに基づいて通信経路が確立されてしまうことがない。
(5)宛先端末(T)においてホップ情報の正当性が否認され、あるいは経路制御サーバ(RM)においてホップリストの正当性が否認されると、その元となるRREQを中継あるいは受信した各端末が当該RREQに基づいて登録した情報が全て削除され、次に受信されるRREQに基づいて同様の処理が実行されるので、改竄等の不正行為が発覚した状況から容易に復帰できる。
(6)確立された通信経路にリンクダウンが発生し、これを修復する場合も、エンド端末間で送受信されるRRPR（RREQと同等）に各中継端末が登録するホップ情報は暗号化されるので、経路修復時にも高い安全性が確保される。

以下、図面を参照して本発明の好ましい実施の形態について詳細に説明する。図１は、本発明のマルチホップ通信方法が適用されるアドホックネットワークの構成例を示した図であり、複数の移動端末(S，A，B，…T)および少なくとも一つの経路制御サーバ(RM)が含まれる。ここでは、移動端末Sが送信元端末として振る舞い、移動端末Tが宛先端末として振る舞う場合を例にして説明する。

本実施形態では、図２に一覧表示したように、各移動端末Xに付与されているIPアドレスをIPxと表現し、各移動端末Xにおいて登録されるタイムスタンプをTxと表現し、各移動端末に固有の（より具体的には、各移動端末をネットワークに接続するインターフェースに固有の：以下同様）マックアドレスをMACxと表現する。さらに、本実施形態では送信元端末Sおよび宛先端末T間に経路を確立し、その後、この経路上で送受されるフレームの宛先を識別するために前記送信元端末Sおよび宛先端末Tに付与するユニークなアドレスを、それぞれFWs，FWtと表現する。

前記経路制御サーバ(RM)は、以下の条件(1)〜(3)を満たしている。
(1)各移動端末との間にSSL(Secure Sockets Layer protocol)等の安全なセッションを確立可能である。
(2)非対称暗号化方式の暗号鍵ペアを生成可能である。
(3)エンド端末および中継端末の情報を保持し、適切にシグナリングを行える。

前記各移動端末は、以下の条件(1)から(6)を満たしている。
(1)２つの無線通信インターフェースを保持する。
(2)RMとの間にSSL等の安全なセッションを確立可能である。
(3)非対称暗号化方式の暗号化、復号化が可能である。
(4)高度な無線通信路暗号方式(TKIP:Temporal Key Integrity ProtocolやAES:Advanced Encryption Standardなど)をサポートし、アドホックモードで通信が可能である。また、暗号化モードと平文モードの両者を混在させて通信可能である。
(5)レイヤー２でフレームのフラッディングおよび転送が可能である。
(6)隣接する中継端末とのリンク切断を検知可能である。

図３は、前記経路制御サーバ(RM)および各移動端末X（送信元端末S、宛先端末T、中継端末）が管理する主要なデータの一覧を示した図である。経路制御サーバ(RM)は、図４に一例を示した「経路データベース(DB)」、「ホップリスト」および「修復情報」を管理する。全ての移動端末は、図５に一例を示した「転送リスト」および「接続リスト」を管理する。また、移動端末のうち、特にエンド端末としての送信元端末Sおよび宛先端末Tは、図６に一例を示した「経路情報テーブル」をさらに管理する。

前記RMが管理する「経路DB」（図４）には、一つのコネクション（送信元端末Sと宛先端末Tとの組）に対して、一意に決まるID、非対称暗号鍵ペア（Ks、KS)、通信暗号鍵(KEY)などが登録される。各エントリには「有効フラグ(v)」，「ペンディングフラグ(p)」，「修復フラグ(r)」が用意されている。前記有効フラグ(v)は、送信元端末Sと宛先端末Tとの間に経路が確立されて、後に詳述するユニークアドレスFWs、FWtを用いたデータ通信が可能になるとセットされる。前記ペンディングフラグ(p)は、後述するRREQパケットやRRPRパケットを利用して経路確立が行われている途中の状態でセットされる。「修復フラグ(r)」は、RRPRパケットを利用して経路が修復されている最中にセットされる。

前記送信元端末Sおよび宛先端末Tが管理する「経路情報テーブル」（図６）には、一つのコネクションに対して、一意に決まるID、非対称暗号鍵ペア(Ks、KS)、通信暗号鍵(KEY)が登録される。各エントリには、前記「有効フラグ(v)」，「ペンディングフラグ(p)」，「修復フラグ(r)」が用意されている。

前記全ての移動端末が管理する「転送リスト」（図５）には、一つのコネクションに対して、一意に決まるID、非対称暗号鍵ペアの一方（Ks)、後述するユニークアドレスFWs、FWtが登録される。「接続リスト」（図５）には、隣接端末がリストアップされる。

図７は、本発明に係るマルチホップ通信方式における経路確立手順を示したシーケンス図であり、ここでは、端末Sが端末Tとの間に経路を確立する際の手順を例にして説明する。

手順(1)：端末Sは自身の経路情報テーブルを検索し、宛先端末Tへ至る経路が既に確立されているか否かを確認する。ここでは、経路が未だ確立されておらず、新たに経路探索が必要であると判断されたものとして説明を続ける。

手順(2)：端末Sは自身の経路情報テーブルへ端末TのIPアドレスおよびタイムスタンプ[IPt, Ts]を書き込んでエントリする。このエントリには、当該エントリが未だに無効であることを意味する「無効」フラグ、およびペンディング中であることを意味する「ペンディング」フラグがセットされる。その後、端末SはRST(Route Start：経路確立開始要求)パケット:Init（経路情報の作成を指示）を生成し、これをSSLで暗号化してRMへ送信する。このRST:Initには、図８(a)に示したように、その送信元(S）および宛先(RM）、パケットタイプ(RST）、確立しようとしている経路の宛先(T）、タイムスタンプ(Ts)ならびに端末Sのマックアドレス(MACs）が登録される。

手順(3)：RMは前記RSTを受信すると、未割り当ての仮想的な非対称暗号鍵ペア[Ks, KS]および通信暗号鍵(KEY)を生成し、これに識別用のIDを割り当てる。さらに、経路DBに新たなエントリを作成して、前記受信したRSTの内容を記録する。

手順(4)：RMはRSTを生成し、これをSSLで暗号化して宛先端末Tへ送信する。このRSTには、図８(b)に示したように、その送信元(RM)および宛先(T）、パケットタイプ(RST）、確立しようとしている経路の送信元(S)および宛先(T）、暗号鍵ペア(Ks, KS）、通信暗号鍵(KEY)、タイムスタンプ(Ts)ならびに端末Sのマックアドレス(MACs）が登録されている。

手順(5)：RMがRSTを生成し、これをSSLで暗号化して端末Sへ送信する。このRSTには、図８(c)に示したように、その送信元(RM)および宛先(S）、パケットタイプ(RST）、確立しようとしている経路の送信元(S)および宛先(T）、暗号鍵ペア(Ks, KS）、通信暗号鍵(KEY）、タイムスタンプ(Ts)ならびに送信元のマックアドレス(MACs)が登録されている。

図９は、前記手順(3)〜(5)を含むRMのRST受信処理を詳細に示したフローチャートであり、前記RST:Initが受信されるごとに起動される。

ステップＳ１１では、未割り当ての仮想的な暗号鍵ペア[Ks, KS]およびKEYが生成され、これにIDが割り当てられる（手順３）。ステップＳ１２では、経路DBにエントリが作成され、受信したRSTの内容が記録される。ステップＳ１３では、RSTが生成されて宛先端末Tへ送信される（手順４）。ステップＳ１４では、宛先端末TからAckが返信されたか否かが判定される。Ackが返信されなければ、ステップＳ１７において前記エントリが経路DBから削除され、ステップＳ１８において、送信元端末SへNakが送信される。

これに対して、ステップＳ１４で宛先端末TからAckが返信されれば、ステップＳ１５において、これがAck_dであるか否かが判定される。このAck_dは、宛先端末Tが送信元端末Sと隣接しているときに送信されるので、Ack_dであればステップＳ１９においてRR(Received Request)受信処理へ進む。Ack_dでなければステップＳ１６へ進み、送信元端末SへRSTが送信される（手順５）。

手順(6)：送信元端末Sが、前記RSTの受信に応答してRREQ（Route Request：経路探索要求）パケットのフラッディングを開始する。このRREQには、図８(d)に示したように、送信元アドレスとしてダミーアドレス[0．0．0．0]が登録され、宛先アドレスとして、ブロードキャスト(b/c）を意味する[255．255．255．255]が登録される。

このRREQには更に、パケットタイプ(RREQ）、シーケンス番号Seq、一方の暗号鍵（公開鍵）Ksおよび[ID, Seq, Ks]の他方の暗号鍵（秘密鍵）KSによる電子署名が登録され、さらに自端末に固有のホップ情報として[from，to，IPx，Tx]が、前記一方の暗号鍵Ksにより暗号化されて追加登録される。ここで、「from」は当該RREQを自身に送信した直前の端末のマックアドレスであり、「to」は自身のマックアドレスである。「IPx」は全ての端末から自端末を一意に特定するための識別子であり、ここではIPアドレスを採用したが他の識別子を採用しても良い。なお、端末Sに限り、「from」および「to」にはいずれも自身のマックアドレスが登録される。したがって、送信元端末Sにより登録されるホップ情報[from，to，IPx，Tx]は[MACa，MACa，IPa，Ta]となる。

手順(7)：RREQを受信した各端末は、その電子署名を一方の暗号鍵Ksで復号化してIDを読み出し、これが経路情報として既登録であるか否かに基づいて、当該RREQの宛先が自身であるか否かを判断する。

手順(8)：RREQを受信した各端末は、その宛先が自身以外であれば、各自に固有のホップ情報をRREQへ追加する。例えば、RREQを端末Sから受信した端末Aであれば、ホップ情報の「from」として端末SのマックアドレスMACs、「to」として自身のマックアドレスMACa、「IPx」として自身のIPアドレスIPa、タイムスタンプTxとして現在時刻（または他と重複しない固有のランダム値：以下同様）Taを追加する。そして、RREQに登録されていた暗号化情報と前記ホップ情報[MACs ，MACa，IPa，Ta]とを暗号鍵Ksで再暗号化[図８(e)]する。

同様に、端末AからRREQを受け取った端末Bであれば、ホップ情報の「from」として端末AのマックアドレスMACa、「to」として自身のマックアドレスMACb、IPxとして自身のIPアドレスIPb、タイムスタンプTxとして現在時刻Tbを追加する。そして、RREQに登録されていた暗号化情報（端末Sのホップ情報および端末Aのホップ情報）と前記自身のホップ情報[MACa ，MACb，IPb，Tb]とを暗号鍵Ksで再暗号化[図８(f)]する。つまり、本実施形態ではホップ数が増加するごとに、各中継端末に固有のホップ情報が多重に暗号化されることになる。

手順(9)：宛先端末Tは、自身宛のRREQを受信すると、多段に暗号化された各中継端末のホップ情報を、予めRMから通知されている暗号鍵ペアー[Ks，KS]で順次に復号化する。そして、隣接する各端末の一方に「from」として登録されているマックアドレスと、他方に「to」として登録されているマックアドレスとが全て一致するか否かに基づいて、各ホップ情報の正当性を判定する。

さらに具体的に説明すれば、前記RREQが端末Sから端末A、Bを経由して端末Tへ達していれば、途中で改竄がなされない限り、端末Sが「to」として登録したマックアドレスと端末Aが「from」として登録したマックアドレスとは一致するはずである。同様に、端末Aが「to」として登録したマックアドレスと端末Bが「from」として登録したマックアドレスとが一致するはずである。端末Tはこのように、隣接する各端末のホップ情報を比較することで、当該各ホップ情報の正当性を判定する。なお、宛先端末Tより手前の各中継端末A，B…は、前記暗号鍵ペアーの一方[Ks]しか知らされていないので、前記暗号化情報を復号化することはできない。なお、宛先端末Tは別経路でもRREQを受信する可能性があるので、今回のRREQに関する処理が完了するまでは、ペンディングリストに今回のRREQを保持しておく。

手順(10)：宛先端末Tは、このようにしてホップ情報の正当性を判定し、正当性が確認されると、これに基づいてホップリストを作成する。ここで得られるホップリストは、[S：Ts，MACs，A：Ta，MACa，B：Tb，MACb，T：Tt，MACt]となる。ただしMACsは前記RSTで得たものを使い、[T：Tt，MACt]は宛先端末Tが自身で付け加える。正当性の確認時に改竄が発見されると、ホップリストを作成することなく当該RREQを破棄して次に到着する他のRREQを待つ。そして、新たにRREQが到着すると、前記と同様に正当性を確認し、正当性が確認されればホップリストを作成する。

手順(11)：宛先端末Tは、図８(g)に示したように、前記ホップリストの登録されたRRパケットを生成してRMへ送信する。

図１０は、前記RREQを受信した各移動端末の動作を示したフローチャートであり、前記手順(6)〜(11)を含む。

ステップＳ３１では、受信したRREQに登録されている電子署名が一方の暗号鍵Ksで復号化される。ステップＳ３２では、RREQに登録されているKs、seqと前記復号化して得られるKs、seqとが比較され、これらが不一致であれば当該RREQが破棄され、一致すればステップＳ３３へ進む。ステップＳ３３では、前記電子署名を復号化して得られるIDが転送リストに既登録であるか否かが判定される。既登録であればシーケンス番号seqが比較され、今回のシーケンス番号が既登録のシーケンス番号よりも新しければステップＳ３６へ進む。また、前記IDが未登録であればステップＳ３５へ進み、転送リストに新しいエントリが追加される。

ステップＳ３６では、前記電子署名を復号化して得られるIDが経路情報テーブルに既登録であるか否かに基づいて、今回のRREQが自身宛であるか否かが判定される。宛先端末T以外であればIDが未登録なので、自身以外の端末宛のRREQであると判定されてステップＳ３７へ進む。ステップＳ３７では、自身に固有のホップ情報[from，to，IPx，Tx]がRREQに追加される。ステップＳ３８では、RREQに登録されている暗号化情報が前記ホップ情報[from，to，IPx，Tx]と共に再暗号化される。ステップＳ３９では、タイムスタンプTxおよびシーケンス番号seqが転送リストに登録される。ステップＳ４０では、前記RREQがブロードキャストされる（以上、手順７，８）。

一方、前記ステップＳ３６において、宛先端末Tであれば前記IDが既登録なので、自身宛のRREQであると判定されてステップＳ４１へ進む。ステップＳ４１ではシーケンス番号seqが比較され、今回のシーケンス番号が既登録のシーケンス番号よりも新しければステップＳ４２へ進む。ステップＳ４２では、RREQに登録されている暗号化情報が、予めRMから通知されている暗号鍵ペアを用いて順次に復号化され、各中継端末により登録されたホップ情報が抽出される。

ステップＳ４３では、経路上で隣接する一方の端末が登録したホップ情報の「from」と他方の端末が登録したホップ情報の「to」とが一致するか否かに基づいて、当該ホップ情報の正当性が判定される（以上、手順９，１０）。正当性が確認されるとステップＳ４４へ進み、前記復号化されたホップ情報に基づいてホップリストが作成される。ステップＳ４５では、前記ホップリストがRMへ送信される（手順１１）。

なお、前記ステップＳ３２，Ｓ４３で正当性が否認されるか、あるいはステップＳ３４，Ｓ４１で今回のシーケンス番号が既登録のシーケンス番号よりも古いと判定されれば、ステップＳ４６，Ｓ４７で今回のRREQが破棄される。この場合、宛先端末(T)は次のRREQ受信を待って当該受信処理を繰り返す。

手順(12)：RMは、ユニークな未割り当てアドレスペア[FWs, FWt]を生成する。ここで、FWsは送信元端末Sに割り当てられるユニークアドレスであり、FWtは宛先端末Tに割り当てられるユニークアドレスである。

手順(13)：RMは更に、端末Tから通知されたホップリストを経路DBに書き込みながら、このホップリストに記載されている全ての端末(ただし、宛先端末T以外)へFWID(Forwarding Indication：転送先指示)パケットを送信する。端末Bへ送信されるFWIDパケットには、図８(h)に示したように、端末Bのホップ情報に登録されていたタイムスタンプTb，端末BがRREQを送信したとされる端末のマックアドレス(MACt)、端末BへRREQを送信したとされる端末のマックアドレス(MACa)と共に、前記ユニークアドレスFWs，FWtが登録される。

同様に、端末Aへ送信されるFWIDには、図８(i)に示したように、端末Aのホップ情報に登録されていたタイムスタンプTa，端末AがRREQを送信したとされる端末のマックアドレス(MACb)、端末AへRREQを送信したとされる端末のマックアドレス(MACs)と共に前記ユニークアドレスFWs，FWtが登録される。

同様に、端末Sへ送信されるFWIDには、図８(j)に示したように、端末Sのホップ情報に登録されていたタイムスタンプTs，端末SがRREQを送信したとされる端末のマックアドレス(MACa)、端末AへRREQを送信したとされる端末のマックアドレス(ダミーアドレス)と共に前記ユニークアドレスFWs，FWtが登録される。ただし、端末Sと端末Tとが直接通信する場合には、ホップリストは送信元端末Sと宛先端末Tのみとなり、FWIDは送信元端末Sへのみ送信される。

手順(14)：前記FWIDを受け取った各端末は、自身の転送リストあるいは経路情報テーブルに登録されているタイムスタンプ、接続リストをチェックすることで、他者の不正(なりすましや反射攻撃(replay attack)をチェックする。不正が検知されなければ前記転送リストに前記ユニークアドレスFWs, FWtをセットする。不正が検知されれば、RMへFWID:malicious（改竄等発見通知）を送信する。

なお、FWID:maliciousを受信したRMは、経路DBのホップリストを参照して改竄の発見された経路を特定する。そして、その情報を各中継端末へはFWID:revocation(転送リスト削除指示)パケットに登録して送信し、端末TへはRCMP(Routing Complete：経路確立完了):malicious(改竄等発見通知)パケットに登録して送信する。各中継端末は、前記FWID:revocationの受信に応答して、対応する転送リストを破棄する。端末Tは、新しいRREQの受信に備えて待機する。

手順(15)：各端末は、正当性が確認されるとRMへAckを返す。送信元端末Sは、この時点で「受信可能」となる。

手順(16)：RMはRCMPパケットを生成して各エンド端末S、Tへ送信する。各エンド端末へ送信されるRCMPには、図８(k)，(l)に示したように、送信元端末Sとこれに割り当てられたユニークアドレス(FWs)との組み合わせ、および宛先端末Tとこれに割り当てられたユニークアドレス(FWt)との組み合わせが登録されている。

エンド端末S，TはRCMPを受け取ると、これを経路情報テーブルに登録し、フラグを「有効」にし、ペンディングフラグを「オフ」にする。端末Sは、経路情報テーブルにIPt → IF_wlan（宛先アドレスがIPtならばアドホックインターフェースへ）、ARPテーブルにIPt = FWt（IPtのマックアドレスとしてFWtを登録）、転送リストにFWsを記録する。同様に、端末Tは経路情報テーブルにIPs → IF_wlan、ARPテーブルにIPs = FWs、転送リストにFWtを書き込み、それぞれ自分宛かどうかを示すフラグをオンにする。その後、エンド端末S，TはRCMPackをRMに返すと共に、RREQに関するペンディングリストを削除する。RMはAckを受け取るとフラグを「有効」、ペンディングをオフにして、ここで経路確立は終了する(端末S,Tともに「送受信可能」）。

図１１は、前記FWIDを受信した各移動端末の動作を示したフローチャートであり、前記手順(14)、(15)を含む。

ステップＳ５１では、受信したFWIDの分類が、転送リスト削除指示(revocation)であるか否かが判定され、revocationでなければ、ステップＳ５２において、このFWIDに登録されているタイムスタンプ等に基づいて正当性が判定される（手順１４）。正当性が確認されると、ステップＳ５３において、このFWIDに登録されているユニークアドレスFWs, FWtが転送リストに登録される。ステップＳ５４では、RMに対してAckが返信される（手順１５）。

一方、前記ステップＳ５２において正当性を確認できなければステップＳ５５へ進み、RMへFWID:malicious(改竄等発見通知)が送信される。ステップＳ５６では、該当する転送リストが破棄される。また、前記ステップＳ５１において、受信したFWIDの分類がrevocationと判定されると、ステップＳ５７において転送リストが破棄される。ステップＳ５８では、RMに対してAckが返信される。

以上のようにして、送信元端末Sおよび宛先端末T間に通信経路が確立されると、各端末は前記ユニークアドレスの一方(FWs)を送信元アドレス、他方(FWt)を宛先アドレスとして通信を開始する。この際、端末S，T間で送受されるフレームは、前記各コネクションに割り当てられる通信暗号鍵(KEY)で暗号化される。

次いで、以上のようにして確立された経路が切断された場合に、これを修復するリンク修復手順について、図１２のシーケンス図を参照して説明する。ここでは、送信元端末S⇔端末A⇔端末B⇔端末C⇔端末D⇔宛先端末Tの順にデータが配送される経路が確立されている状態から、端末A、B間の接続性が失われた場合（したがって、端末A，Bはリンク切れ端末）を例にして説明する。

手順(1)：端末Aは端末Bへデータが届かなくなったことを検出する。これは、例えば送信したデータフレームに対するAckが端末Bから返送されないことに基づいて検出できる。

手順(2)：リンクダウンを検出した端末AがRMへRERR(Route Error：down)を送信してトポロジが変化したことを通知する。このRERRには、端末AのIPアドレスIPaおよびそのタイムスタンプTaと共に、パケットが届かなくなった経路の宛先端末TのユニークアドレスFWtが登録される。

手順(3)：RMは経路DBに修復中フラグを立てる。また、通知されたRERRに登録されている情報(IPa，FWt)および、その反対側の端末Sについての情報(IPbとFWs)が経路DBに登録される。RMがRERRを受信したときに修復フラグが既に立っていた場合は、新たに経路を確立し直すように端末Sへ通知する。

手順(4)：RMは、RRPR(Route Repair：経路修復)パケットを生成し、これを端末Bへ送信する。さらに具体的に説明すれば、RMは自身の経路DBに登録されているホップリストに基づいて、送信元端末Sから切断リンクまでのホップ数と、宛先端末Tから切断リンクまでのホップ数とを比較する。そして、切断リンクまでのホップ数が遠い側の経路として、本実施形態では宛先端末Tからリンク切れ端末Bまでの経路を選択し、その経路情報をホップリストから抜き出す。そして、端末Tが端末Sとの間に経路を確立しようとする際に送出するであろうRREQをリンク切れ端末Bが端末D、Cを経由して受信し、これを中継する際に送信すると予測されるRREQと実質的に同一のRRPRの送出を、リンク切れ端末Bに対して指示する。

図１３は、前記RMがリンク切れ端末Bに対して送信するRRPRパケットのフレーム構造を示した図であり、端末Tから送信されて端末D，C，Bを経由したならば各端末において付与されたであろうホップ情報の暗号化情報が既に添付されている。

手順(5)：前記RRPRを受信したリンク切れ端末Bは、転送リストのSeqを更新すると、RMへAckを返信すると共に当該RRPRを改めてフラッディングする。図１４は、端末Bが前記RMからの指示に応答してブロードキャストするRRPRのフォーマットを示した図である。フラッディング時の各端末での処理は、前記経路確立シーケンス（図７）の手順(8)と同様である。

なお、図１２では図示を省略したが、RMは前記RRPRパケットの送信後、一定時間待っても端末BからのAckを受け取らなかった場合、端末Bをあきらめて、もう一つのリンク切れ端末AにRRPRを送信する。このときに送信されるRRPRは、送信元端末Sが端末Tとの間に経路を確立しようとする際に送出するであろうRREQをリンク切れ端末Aが受信し、これを中継する際に当該端末Aが送信すると予測されるRREQと実質的に同一である。RMは、端末AからもAckを受信できなければ、経路修復をあきらめて経路再構築手順へ移行する。

手順(6)：端末Sは、前記経路確立シーケンス（図７）の手順(9)，(10)と同様に、RRPRを受信すると、多段に暗号化された各中継端末のホップ情報を暗号鍵ペアー[Ks，KS]で順次に復号化する。そして、隣接する各端末の一方に「from」として登録されているマックアドレスと、他方に「to」として登録されているマックアドレスとが全て一致するか否かに基づいて、各ホップ情報の正当性を判定する。正当性が確認されると、これに基づいてホップリストを作成する。なお、宛先端末Sは別経路でもRRPRを受信する可能性があるので、今回のRRPRに関する処理が完了するまでは、ペンディングリストに今回のRRPRを保持しておく。

手順(7)：端末Sは、前記経路確立シーケンスの手順(11)と同様に、改竄の有無を確認した後、正当性が確認されれば、ホップリスト[S：Ts，MACs，N：Tn，MACn，B：Tb，MACb，C：Tc，MACc，D：Td，MACd，T：Tt，MACt]を作成し、これをRRパケットに登録してRMへ送信する。

手順(8)：RMはホップリストを経路DBに上書きしながら、FWID:forwardを新しく経路に追加された端末(この例では、端末N)に送信する。

手順(9)：RMは、ホップリストを上書きする前に、FWID:revocation（転送リスト削除指示）を古い端末（この例では、端末A）へ送信する。

手順(10)：RMはさらに、ホップ先が変更になる端末（この例では、追加された端末Nに隣接する端末S，B）へFWID:forwardを送信する。ここで指定されるFWs、FWtは、リンク切れ前に使用していたものと同じである。

手順(11)：FWIDを受け取った各端末は、前記経路確立シーケンスの手順(14)と同様に、なりすましの有無を含めて正当性の有無をチェックし、正当性が確認されれば、RMへAckを返す。

手順(12)：RMは端末S、TへRCMP:updatedを送信し、修復フラグをオフにして、そのエントリを削除する。端末S、Tは経路情報テーブルと転送リストのSeqを更新し、さらにペンディングリストを削除し、次のRRPR受信に備えて待機する。

本発明のマルチホップ通信方法が適用されるアドホックネットワークの一例を示した図である。 符号を一覧表示した図である。 経路制御サーバ(RM)および各移動端末（送信元端末S、宛先端末T、中継端末）が管理するデータの一覧を示した図である。 経路制御サーバ(RM)が管理するデータの一覧を示した図である。 全ての移動端末が管理するデータの一覧を示した図である。 エンド端末（S，T）が管理するデータの一覧を示した図である。 経路確立手順を示したシーケンス図である。 シグナリングパケットのフレーム構造を示した図である。 RMにおけるRST受信処理のフローチャートである。 各移動端末におけるRREQ受信処理のフローチャートである。 各移動端末におけるFWID受信処理のフローチャートである。 リンク修復手順を示したシーケンス図である。 RMがリンク切れ端末Bに対して送信するRRPRパケットのフレーム構造を示した図である。 リンク切れ端末Bが送信するRRPRパケットのフレーム構造を示した図である。

符号の説明

FWx…端末Xに付与されるユニークアドレス
FWID…転送先指示パケット
IPx…端末Xに付与されるIPアドレス
KEY…通信暗号鍵
KS，Ks…非対称暗号鍵ペア
MACx…端末Xに付与されるマックアドレス
RM…経路制御サーバ
RREQ…経路確立要求パケット
RRPR…経路修復要求パケット
RST…経路確立開始要求
S…送信元端末
T…宛先端末
Tx…端末Xにおけるタイムスタンプ

Claims (10)

1. 複数の端末(S，T…X)および少なくとも一つの経路制御サーバ(RM)を含み、送信元の端末と宛先の端末とが中継用の端末を介して通信を行うマルチホップ通信方法において、
   送信元端末(S)が、宛先端末(T)を指定した経路確立開始要求(RST)を経路制御サーバ(RM)へ送信する第１手順と、
   前記経路制御サーバ(RM)が非対称暗号鍵ペア(KS，Ks)を生成する第２手順と、
   前記経路制御サーバが、前記暗号鍵ペア(KS，Ks)を送信元端末(S)および宛先端末(T)へ通知する第３手順と、
   前記送信元端末(S)が、自端末に固有のホップ情報(from，to，IPs，Ts)を前記暗号鍵ペアの一方(Ks)で暗号化して暗号化情報を生成する第４手順と、
   前記送信元端末(S)が、前記一方の暗号鍵(Ks)および前記暗号化情報を含むRREQパケットをブロードキャストする第５手順と、
   前記RREQを受信した端末であって、その宛先以外の端末が、当該RREQに既登録の暗号化情報を、自端末に固有のホップ情報と共に、当該RREQに含まれる前記一方の暗号鍵(Ks)で再暗号化する第６手順と、
   前記宛先以外の端末が、前記一方の暗号鍵(Ks)および前記再暗号化された暗号化情報を含むRREQをブロードキャストする第７手順と、
   前記RREQを受信した他の端末であって、その宛先以外の各端末が、前記第６および第７手順を繰り返す第８手順と、
   前記RREQを受信した宛先端末(T)が、その暗号化情報を前記暗号鍵ペア(KS，Ks)で順次に復号化する第９手順と、
   前記宛先端末(T)が、前記復号化された各ホップ情報に基づいて、送信元端末(S)から宛先端末(T)へ至るホップリストを生成する第１０手順と、
   前記宛先端末(T)が経路制御サーバ(RM)へ、前記ホップリストを通知する第１１手順と、
   前記経路制御サーバ(RM)が、前記通知されたホップリストに基づいて、前記送信元端末(S)および宛先端末(T)間に通信経路を確立する第１２手順とを含むことを特徴とするマルチホップ通信方法。
2. 前記各端末と経路制御サーバ(RM)とが暗号化通信を行うことを特徴とする請求項１に記載のマルチホップ通信方法。
3. 前記第９手順は、前記復号化された各ホップ情報の正当性を確認する手順をさらに含み、
   前記宛先端末(T)は、ホップ情報の正当性が否認されると前記RREQを破棄して前記第９手順を繰り返し、各ホップ情報の正当性が確認された場合のみ、当該ホップ情報に基づいてホップリストを生成することを特徴とする請求項１または２に記載のマルチホップ通信方法。
4. 前記第１２手順は、前記通知されたホップリストの正当性を確認する手順をさらに含み、
   ホップリストの正当性が否認されると当該ホップリストを破棄して前記第９から第１２手順を繰り返し、前記ホップリストの正当性が確認された場合のみ、当該ホップリストに基づいて前記送信元端末(S)および宛先端末(T)間に通信経路を確立することを特徴とする請求項１または２に記載のマルチホップ通信方法。
5. 前記第１２手順は、
   前記経路制御サーバが、ユニークな未割り当てアドレス(FWs，FWt)の一方(FWs)を送信元端末(S)に割り当て、他方(FWt)を宛先端末(T)に割り当てる手順と、
   前記経路制御サーバが、前記ユニークアドレス(FWs，FWt)の割り当てを前記経路上の各端末へ通知する手順と、
   前記経路上の各端末が、前記通知されたユニークアドレス(FWs，FWt)の割り当てに基づいて転送リストを生成する手順とを含み、
   送信元端末(S)および宛先端末(T)は、フレームを交換する際の送信元アドレスおよび宛先アドレスとして前記ユニークアドレス(FWs，FWt)を採用し、
   前記各端末は、前記ユニークアドレスの一方または他方を宛先とするフレームを、前記転送リストに基づいて転送することを特徴とする請求項１ないし４のいずれかに記載のマルチホップ通信方法。
6. 前記第２手順では、前記経路制御サーバ(RM)が、送信元端末(S)および宛先端末(T)の組み合わせに固有の通信暗号鍵(KEY)をさらに生成し、
   前記第３手順では、前記経路制御サーバが前記通信暗号鍵(KEY)を送信元端末(S)および宛先端末(T)へ通知し、
   送信元端末(S)および宛先端末(T)は、交換するフレームを前記通信暗号鍵(KEY)で暗号化することを特徴とする請求項５に記載のマルチホップ通信方法。
7. 前記確立された経路が切断されたときに、この切断リンクを挟んで対向する一対のリンク切れ端末の一方が前記経路制御サーバ(RM)へリンクダウンを通知する第１３手順と、
   前記経路制御サーバ(RM)が、送信元端末(S)から切断リンクへ至る第１経路および宛先端末(T)から切断リンク切れ端末へ至る第２経路の一方を選択する第１４手順と、
   前記選択された経路のエンド端末（送信元端末または宛先端末）が他方のエンド端末（宛先端末または送信元端末）との間に経路を確立しようとする際に送信するRREQを前記選択された経路のリンク切れ端末が受信して中継する際に送信すると予測されるRREQと同等のRRPRパケットの送信を、前記経路制御サーバが前記選択された経路のリンク切れ端末へ指示する第１５手順と、
   前記RRPRの送信を指示されたリンク切れ端末がRRPRを送信する第１６手順と、
   前記RRPRを受信した端末であって、前記他方のエンド端末以外の端末が、当該RRPRに既登録の暗号化情報を、自端末に固有のホップ情報と共に、当該RRPRに含まれる前記一方の暗号鍵(Ks)で再暗号化する第１７手順と、
   前記他方のエンド端末以外の端末が、前記一方の暗号鍵(Ks)および前記再暗号化された暗号化情報を含むRRPRをブロードキャストする第１８手順と、
   前記RRPRを受信した他の端末であって、前記他方のエンド端末以外の各端末が、前記第１７および第１８手順を繰り返す第１９手順と、
   前記RRPRを受信した他方のエンド端末が、その暗号化情報を前記暗号鍵ペア(KS，Ks)で順次に復号化する第２０手順と、
   前記他方のエンド端末が、前記復号化された各端末のホップ情報に基づいて、前記一方のエンド端末から他方のエンド端末へ至るホップリストを生成する第２１手順と、
   前他方のエンド端末が経路制御サーバ(RM)へ、前記ホップリストを通知する第２２手順と、
   前記経路制御サーバ(RM)が、前記通知されたホップリストに基づいて、前記各エンド端末間に通信経路を確立する第２３手順とを含むことを特徴とする請求項１に記載のマルチホップ通信方法。
8. 前記第１４手順において、前記経路制御サーバは、前記第１経路及び第２経路を比較して短い経路を選択することを特徴とする請求項７に記載のマルチホップ通信方法。
9. 前記他方のエンド端末が前記各ホップ情報の正当性を確認する手順をさらに含み、
   前記他方のエンド端末は、ホップ情報の正当性が確認された場合のみ、当該ホップ情報に基づいてホップリストを生成することを特徴とする請求項７または８に記載のマルチホップ通信方法。
10. 前記経路制御サーバ(RM)が前記ホップリストの正当性を確認する手順をさらに含み、
    前記経路制御サーバ(RM)は、ホップリストの正当性が確認された場合のみ、当該ホップリストに基づいて前記各エンド端末間に通信経路を確立することを特徴とする請求項７または８に記載のマルチホップ通信方法。

Images