JP4609938B2 - データ通信方法およびシステム - Google Patents

Description

本発明は、データ通信方法およびシステムに係り、特に、アドホックネットワーク上で匿名性および秘匿性に優れたマルチホップ通信を可能にするデータ通信方法およびシステムに関する。

携帯電話網や無線LANのように移動端末が無線基地局を介して通信を行う方式以外に、端末同士が直接データのやりとりを行う方式がある。これは、例えば無線LANでは「アドホックモード」という通信モードによってサポートされている。アドホックモードでは、端末同士の通信は１対１で行われるが、これをさらに拡張してアドホックルーティング技術を利用することにより、自身に隣接した相手のみならず、離れた相手に対しても、間に位置する移動端末を中継端末として利用することにより通信を可能にするマルチホップ通信が提案され、例えば特許文献１に開示されている。

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

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

このような技術課題に対して、端末がアドホック通信を行う際に、匿名性、秘匿性を確保しながら通信経路を確立する手法が特許文献１に開示されている。
特願２００３−４２０７５３号

上記した従来技術によれば、経路確立の際に送信端末、宛先端末および中継経路を他の端末に特定されることなく、当該送信端末および宛先端末のぞれぞれにデータ通信用の匿名アドレス(FWs，FWt)を割り当てることができる。

しかしながら、送信端末および宛先端末が中継端末を経由して通信するマルチホップ通信では、送信端末および宛先端末に匿名アドレスが割り当てられていても、送信端末から送出されたデータが中継端末によるデータ転送を繰り返して宛先端末まで転送される際に、各中継端末に固有のアドレスが隣接端末間でのデータ転送用に用いられてしまうと、データ通信の匿名性や秘匿性が損なわれてしまう。

本発明の目的は、上記した従来技術の課題を解決し、送信端末および宛先端末のそれぞれに割り当てられる匿名アドレスを利用して、匿名性や秘匿性が損なわれないデータ通信を可能にするデータ通信方法およびシステムを提供することにある。

上記した目的を達成するために、本発明は、送信元の移動端末および宛先の移動端末が、他の移動端末を中継端末に利用してデータ通信を行うデータ通信方法において、以下のような手段を講じた点に特徴がある。
(1)送信端末および宛先端末のそれぞれに割り当てるマルチキャストの匿名アドレスを、前記送信端末、宛先端末および中継端末に登録する手順と、送信端末が、送信元アドレスに自身の匿名アドレスが登録され、宛先アドレスに宛先端末の匿名アドレスが登録されたデータフレームを送信する手順と、前記データフレームを受信した各移動端末が、その送信元アドレスおよび宛先アドレスの組み合わせに基づいて、自身が当該データフレームの中継端末であるか否かを判定する手順と、中継端末が、前記受信したデータフレームを送信する手順と、前記データフレームを送信した各端末が、当該データフレームと同一のデータフレームが受信されたか否かに基づいて前記送信したデータフレームの受領確認を行う手順とを含むことを特徴とする。
(2)前記データフレームを送信した端末が、所定の期間内に受領確認できなかったデータフレームを再送信する手順をさらに含み、前記再送信されたデータフレームを受信した中継端末は、当該データフレームを再送信ではない他のデータフレームよりも優先的に送信することを特徴とする。
(3)送信端末が、その送信元と宛先との組み合わせに固有のシーケンス番号を当該データフレームに書き込む手順と、前記データフレームを受信した端末が、当該データフレームのシーケンス番号に基づいて、当該データフレームが初めて受信されたデータフレームであるか否かを判定する手順と、前記送信端末が、当該データフレームと同一のデータフレームを受信したときに前記シーケンス番号を更新する手順とを含むことを特徴とする。
(4)前記各端末が、送信元アドレスと宛先アドレスとの組み合わせごとに設けられた送信待ちキューと、各送信待ちキューの先頭フレームを順次にコピーされ、これを送信する送信キューとを備え、送信するデータフレームを前記送信待ちキューへ連結する手順と、各送信待ちキューの先頭フレームを送信キューへ順次にコピーする手順と、前記送信キューにコピーされたデータフレームを送信する手順と、送信済みデータフレームを前記送信キューから削除する手順と、受領確認されたデータフレームを前記送信待ちキューから削除する手順とを含むことを特徴とする。

本発明によれば、以下のような効果が達成される。
(1)データフレームを送信した端末は、当該データフレームが正規に受信されたか否かを、当該データフレームを受信した端末が中継のために送信するデータフレームを受信することで確認できる。したがって、データフレームを受信した端末はACK等の受領確認用の応答パケットを別途に送信する必要がない。
(2)データフレームを受信した端末は、これが再送されたデータフレームであれば、再送以外のデータフレームよりも優先的に処理するので、再送されたデータフレームの遅延が最小限に抑えられる。
(3)データフレームを送信する端末は、送信したデータフレームの受領確認が行われるごとに、次に送信するデータフレームに書き込むシーケンス番号を更新するので、データフレームを中継する各端末では、受信したデータフレームが新規のデータフレームであるのか既に受信されているデータフレームであるのかをシーケンス番号に基づいて簡単に識別できるようになる。
(4)送信元アドレスと宛先アドレスとの組み合わせごとに送信待ちキューが設けられ、送信待ちキューの先頭フレームがコピーされて送信され、送信済みのデータフレームは、そのコピーのみが削除されて送信待ちキューからは削除されない。したがって、送信済みの一部のデータフレームに関して受領確認が遅れても、これによって他のデータフレームの送信までもが遅れてしまうことがない。

以下、図面を参照して本発明の好ましい実施の形態について詳細に説明する。図１は、本発明の経路確立方法が適用されるアドホックネットワークの構成例を示した図であり、無線アクセスポイントAPと、この無線アクセスポイントAPとネットワークを介して接続された経路制御サーバRMと、複数の移動端末(S，A，B，…T)とを主要な構成としている。

本実施形態では、移動端末A，Bのみが無線アクセスポイントAPの通信エリア内すなわちインフラ網の圏内に位置し、移動端末S，C，Tがインフラ網の圏外に位置し、移動端末Sが送信端末として振る舞い、移動端末Tが宛先端末として振る舞う場合を例にして説明する。なお、本実施形態では公開鍵および秘密鍵のペアならびに共有鍵を利用して通信データが秘匿されるので、経路制御サーバRMおよび各移動端末S，A，B，C，Tは、図２に一覧表示したように各種の暗号鍵を管理している。
(a)第１公開鍵KRMp：
経路制御サーバRMにより発行されて全ての移動端末で保持される。
(b)第１秘密鍵KRMs：
前記第１公開鍵KRMpと対をなす鍵であり、サーバRMのみで保持する。
(c)第１共有鍵KRM_x ：
移動端末XおよびサーバRMにより共有される鍵であり、各移動端末XによりサーバRMへ予め登録される。
(d)第２公開鍵Kxp：
各移動端末Xに固有の鍵であり、経路制御サーバRMで保持される。
(e)第２秘密鍵Kxs：
前記各第２公開鍵Kxpと対をなす鍵であり、各移動端末Xで保持される。
(f)第２共有鍵KCx：
RREQをフラッディングする際に各移動端末Xで生成され、その後に受信されるRREPの正当性を確認するために使用される。
(g)セッション鍵SK：
経路確立時に宛先端末Tで生成され、RREPに登録されて各中継端末へ通知される。セッション鍵SKは中継端末の全てが共有するので経路確立後も利用可能である。

図３，４は、経路確立時に各移動端末で実行される経路確立手順を示したフローチャートであり、図５は、経路確立時に経路制御サーバRMで実施される経路確立手順を示したフローチャートであり、図６は、経路確立時のシーケンス図である。

端末Sでは、端末Tを宛先とする経路確立の指示に応答して経路テーブルが検索され、端末Tへ至る経路が既登録であるか否かが確認される。ここでは、端末Tへ至る経路が経路テーブルに未登録であり、新たに経路探索が必要であると判断されたものとして説明を続ける。送信端末Sでは、最終宛先を端末Tとする経路要求メッセージ（RREQ）が生成される。

図７は、各移動端末間および各移動端末と経路制御サーバRMとの間で送受信されるシグナリングメッセージのフォーマットの一例を示した図であり、基本ヘッダとシグナリング部とから構成される。前記基本ヘッダには、メッセージの種別（RREQ、RREP、FWREQ、FWREP等）を表すType値、シグナリング部の長さLenおよびflag値等のパラメータが登録されている。

図８は、RREQの基本フォーマットを示した図であり、前記シグナリング部に格納されて送信される。このRREQには、送信端末SのIPアドレス「IPs」、宛先端末TのIPアドレス「IPt」、後述する匿名アドレスFWs，FWtと一意に対応する「アドレスID」、各セッションと一意に対応する「セッションID」およびその候補値である「セッションID候補」、シーケンス番号「seq」、ホップ上限数「hop limit」、「公開鍵」、メッセージ識別子（ハッシュ符号）「sig」、現在までのホップ数「hop」、後述する「前段ホップ順序ID」、ならびにホップ情報「hop info」の各フィールドが確保されている。

前記送信端末Sおよび宛先端末Tの各IPアドレス「IPs」、「IPt」は、送信端末Sにおいて、第１公開鍵KRMpで暗号化されてRREQに登録される。「セッションID候補」には、送信端末Sにおいてランダム値が登録される。「セッションID」には、送信端末Sにおいて初期値「０」が登録される。「公開鍵」には、送信端末Sから送信される際は第１公開鍵「KRMp」が登録される。メッセージ識別子「sig」は、前記各IPアドレスIPs、IPtの暗号化データ、アドレスID、セッションID候補、セッションID、seq、hop limitおよび公開鍵(KRMp)を署名範囲として、各端末に固有の第１共有鍵KRM_x（送信端末SであればKRM_s)を暗号鍵とした、例えばHMAC-MD5のような鍵付きハッシュ関数の計算により生成される。

前記「hop info」には、各移動端末XのIPアドレス「IPx」、「前段ホップ順序ID」、「自段ホップ順序ID」、「FW値」、「第２共有鍵KCx」、後述する匿名アドレスのペア「FWs」，「FWt」およびチェック値「check」の各フィールドが確保されている。匿名アドレス「FWs」，「FWt」および「check」は、後に経路制御サーバRMから提供されるパラメータであって、送信端末Sからフラッディングされる際はいずれも「０」である。

「前段ホップ順序ID」は、メッセージのポップ順序を代表する識別子の一つであり、メッセージを自身にホップした前段の移動端末が当該RREQに付した序数である。「自段ホップ順序ID」は、自身が当該RREQに付した序数であり、前記「前段ホップ順序ID」よりも大きな値となる。なお、送信端末Sから送信されるRREQでは、「前段ホップ順序ID」および「自段ホップ順序ID」のいずれにも「０」が登録されている。前記「hop info」は第１公開鍵KRMpで暗号化されてRREQに格納される。

前記RREQは、そのIPヘッダの送信元アドレスにダミーアドレス（例えば、[0.0.0.0]）が登録され、宛先アドレスにブロードキャストアドレス（例えば、[255.255.255.255]）が登録されてネットワーク上にフラッディングされる。

移動端末Aでは、図３のステップＳ１において、前記送信端末SからフラッディングされたRREQが受信されると、ステップＳ２では、当該RREQに登録されている「アドレスID」が参照される。端末Aで受信されるRREQのアドレスIDは未だ「０」であり、これは当該RREQの正当性が未だにサーバRMで検証されていないことを意味している。これは同時に、当該RREQのアドレス情報（IPアドレス「IPs」、「IPt」）が第１公開鍵KRMpで暗号化されたままであって、経路制御サーバRM以外は解読できないことを意味しているので、その解読を試みることなくステップＳ５へ進む。

なお、アドレスIDが「０」以外であれば、RREQのアドレス情報は、後に詳述するように、サーバRMによって、宛先端末Tであれば解読できる第１共有鍵KRM_tで再暗号化されているのでステップＳ３へ進む。ステップＳ３では、当該RREQのアドレス情報が各端末に固有の第１共有鍵KRM_xで復号化され、その解読が試される。ステップＳ４では、解読できたか否かに基づいて、当該RREQの宛先が自身であるか否かが判定される。解読できなければ、受信したRREQの宛先が自身以外と判定されてステップＳ５へ進む。

ステップＳ５では、自身がインフラ網の圏内であるか否かが判定される。端末Aであれば圏内と判定されてステップＳ６へ進む。ステップＳ６では、匿名アドレスFWs，FWtをサーバRMに要求するFWアドレス要求メッセージ(FWREQ）が生成され、ステップＳ７においてサーバRMへ送信される。

図９は、前記FWREQの基本フォーマットの一例を示した図であり、前記RREQと同様のフォーマットを有しており、RREQの署名範囲内の各パラメータ、メッセージ識別子「sig」および「Hop Info」等がそのまま登録されて送信される。

図５へ進み、サーバRMでは、ステップＳ５１において前記FWREQが受信されるとステップＳ５２へ進み、このFWREQに格納されている「アドレスID」が参照される。端末Aから送信されたFWREQであれば「アドレスID」が「０」であり、同一のRREQに関して初めて受信されたFWREQであって、これは匿名アドレスFWs，FWtやセッションIDが未割り当てであることを意味するのでステップＳ５３へ進む。

ステップＳ５３では、第１公開鍵KRMpで暗号化されているアドレス情報が第１秘密鍵KRMsで解読され、送信端末SのIPアドレス「IPs」および宛先端末TのIPアドレス「IPt」が抽出される。ステップＳ５４では、サーバRMが送信端末Sと共有する第１共有鍵KRM_sを暗号鍵として、署名範囲のデータにHMAC-MD5等の鍵付きハッシュ関数の計算が実施され、その計算結果と前記FWREQに登録されていたメッセージ識別子「sig」とが比較される。両者が一致して当該FWREQの正当性が確認されればステップＳ５５へ進み、前記各IPアドレス「IPs」，「IPt」が、今度はサーバRMが宛先端末Tと共有する第１共有鍵KRM_tで改めて暗号化される。

ステップＳ５６では、第１公開鍵KRMpで暗号化されている「Hop Info」が第１秘密鍵KRMsで復号化され、さらに宛先端末Tに固有の第２公開鍵Ktpで改めて暗号化される。ステップＳ５７では、FWREQに登録されている「セッションID候補」の値が、既に他のセッションに割り当て済みであるか否かが判定される。未割り当てであればステップＳ５８へ進み、当該セッションID候補の値がセッションIDとしてそのまま登録される。セッションID候補の値が他のセッションに割り当て済みであればステップＳ５９へ進み、未割り当てのIDがセッションIDとして登録される。

ステップＳ６０では、FWアドレス応答メッセージ(FWREP)が生成される。図１０はFWREPの基本フォーマットの一例を示した図であり、受信されたFWREQ（図９）と比較すると、公開鍵が第１公開鍵KRMpから宛先端末Tに固有の第２公開鍵Ktpに変更され、アドレス情報の暗号鍵が第１公開鍵KRMpから宛先端末Tの第１共有鍵KRM_tに変更され、メッセージ識別子「sig」が宛先端末Tの第１共有鍵KRM_tを暗号鍵とする鍵付きハッシュ関数の計算結果に変更されている。

ステップＳ６１では、送信端末Sおよび宛先端末Tの各IPアドレス「IPs」，「IPt」のペアに対して未割り当ての匿名アドレスFWs、FWtが割り当てられてテーブルへ登録される。ステップＳ６２では、テーブルのエントリ番号（または、その値へ１対１で変換できる値）が「アドレスID」として登録され、前記FWs，FWt等と共にFWREPに登録される。ステップＳ６３では、前記FWREPが端末Aへ送信される。

なお、前記ステップＳ５２において、受信されたFWREQのアドレスIDが「０」以外であればステップＳ６４へ進み、その値に基づいて匿名アドレスFWs、FWtのペアがテーブルから抽出される。ステップＳ６５では、抽出された匿名アドレスFWs、FWtとFWREQのHop infoに既登録の匿名アドレスFWs、FWtとが比較され、両者が一致すれば、ステップＳ６３へ進んでFWREPが送信される。

これに対して、両者が不一致であれば何らかの不正が行われているので、ステップＳ６６においてFWREQが破棄されてFWREPも送信されない。なお、ステップＳ５２においてアドレスIDが「０」と判定されているにもかかわらずFWREQに匿名アドレスFWs、FWtが既登録の場合も、何らかの不正が行われているので、当該FWREQが破棄されてFWREPも送信されない。

図３へ戻り、端末Aは前記FWREQの送信後、ステップＳ８において前記FWREPを受信するとステップＳ１０へ進み、そのアドレス情報に自身の第１共有鍵KRM_aで解読を試みる。ステップＳ１１では、解読できたか否かに基づいて、前記RREQが自端末宛であるか否かが改めて判定される。FWREPのアドレス情報は、前記ステップＳ５５において、経路制御サーバRMにより宛先端末Tに固有の第１共有鍵KRM_tで再暗号化されているので端末Aでは解読できない。したがって、ここでも前記RREQの宛先が自身以外と判定されてステップＳ１２へ進む。なお、前記ステップＳ７でFWREQを送信した後、ステップＳ８においてFWREPが受信される前に所定時間が経過し、ステップＳ９でタイムアウトが検知された場合もステップＳ１２へ進む。

ステップＳ１２では、前記受信したRREQに登録されていた前段ホップ順序 IDよりも大きいランダム値が自段ホップ順序IDとして発生される。そして、経路制御サーバRMにより割り当てられてFWREPに追加登録されている匿名アドレスFWs、FWt、自段ホップ順序IDおよび前段ホップ順序ID、ならびに第２共有鍵KCx（端末Xがランダム値として発生させる）等をHop Infoに書き込むと共に、これを前記FWREPに登録されている公開鍵Ktpを用いて多重暗号化し、さらに前段ホップ順序IDを自段ホップ順序IDに書き換えてRREQを更新する。

なお、本実施形態では前記ステップＳ７でFWREQを送信した後、ステップＳ８においてFWREPが受信されるまで待機状態となるが、ステップＳ７でFWREQを送信した後、ひとまず処理を終了し、その後のFWREQの受信を契機に前記ステップＳ１０へ移行するようにしても良い。

図１１は、前記Hop Infoの多重暗号化構造を模式的に表現した図であり、前記経路制御サーバRMにおいて第２公開鍵Ktpで再暗号化されたHop Infoに、当該端末Aで生成されたHop Infoが追加され、まとめて第２公開鍵Ktpで暗号化される。

ステップＳ１３では、前記更新されたRREQがフラッディングされる。ステップＳ１４では、前記FWREPに登録されていたセッションID候補、セッションID、自段ホップ順序ID、seq、check値および第２共有鍵KCxが、相互に対応付けられて自身の転送リストに仮登録される。ただし、匿名アドレスFWs、FWtは登録されない。これらの仮登録に関するライフタイムは、正式登録された場合のライフタイムよりも短くされる。

図１２は、前記端末AからフラッディングされるRREQの一例を示した図であり、送信端末SからフラッディングされたRREQと比較すると、アドレス情報の暗号鍵がKRMpから宛先端末Tに固有の第１共有鍵KRM_tに変更され、公開鍵もKRMpから宛先端末Tに固有の第２公開鍵Ktpに変更されている。

図３へ戻り、RREQを端末Aから受信した端末Bでは、ステップＳ２においてアドレスIDが「０」以外と判定される。アドレスIDが「０」以外であればステップＳ３へ進み、当該RREQに登録されているアドレス情報を自身の第１共有鍵KRM_bで復号化して解読を試みる。ステップＳ４では、解読できたか否かに基づいて、当該RREQの宛先が自身であるか否かが判定される。

RREQの宛先が端末Bであれば、そのアドレス情報は経路制御サーバRMによって、サーバRMが端末Bと共有する第１共有鍵KRM_bで再暗号化されているので解読できる。しかしながら、端末Bが受信したRREQのアドレス情報は、宛先端末Tの第１共有鍵KRM_tで暗号化されているので解読できない。したがって、ここでは自身以外が宛先と判定されてステップＳ５へ進む。これ以降は前記端末Aの場合と同様に、FWREQの送信（Ｓ７）、FWREPの受信（Ｓ８）、RREQの更新（Ｓ１２）、RREQのフラッディング（Ｓ１３）および転送リストの更新（Ｓ１４）等が実行される。

さらに、前記RREQを端末Bから受信した端末Cでは、ステップＳ４において宛先端末ではないと判定された後、ステップＳ５において圏外と判断されるので、FWREQをサーバRMへ送信することなくステップＳ１２へ進み、RREQの更新（Ｓ１２）、RREQのフラッディング（Ｓ１３）および転送リストの更新（Ｓ１４）等が実行される。

なお、圏外の端末では経路制御サーバRMと通信することなく、受信したRREQを直ちに処理する。その際、Hop InfoのFWs、FWtには「０」が登録され、その他はhop数のみが更新され、当該RREQに登録されている公開鍵（前段の端末のいずれかが圏内端末であれば宛先端末Tの第２公開鍵Ktp、前段の端末のいずれもが圏外端末であれば第１公開鍵KRMp、）で暗号化されてフラッディングされる。

一方、宛先端末Tは、ステップＳ１において前記RREQを受信すると、ステップＳ２からステップＳ３へ進んで解読を試みる。このRREQが一度でも圏内の端末を中継していれば、そのアドレス情報はサーバRMにおいて自身に固有の第１共有鍵KRM_tで再暗号化されており、端末Tであれば正しく復号化して解読することができるので、ステップＳ４からステップＳ２１へ進む。ステップＳ２１では、解読により得られた宛先IPアドレスIPtが自身のIPアドレスと一致するか否かが判定される。両者が一致すれば、当該RREQの宛先が自身であると判定されてステップＳ２２へ進む。

なお、宛先端末Tで受信されたRREQが一度も圏内の端末を中継していない場合であっても、宛先端末Tが圏内端末であればステップＳ６以降へ進み、上記と同様にFWREQをサーバRMへ送信（ステップＳ７）してFWREPを受信（ステップＳ８）すれば、当該FWREPではアドレス情報が第１共有鍵KRM_tで再暗号化されており、ステップＳ１１において、このアドレス情報を復号化して解読できるのでステップＳ２２へ進むことができる。

ステップＳ２２では、第１共有鍵KRM_tを暗号鍵として署名範囲の鍵付きハッシュ関数が計算され、その計算結果がRREQに登録されているメッセージ識別子「sig」と比較される。なお、複数の経路をたどって複数のRREQが受信されている場合は、現在処理中（正当性を確認中）のRREQ以外は待ち行列にPending RREQとして一時的に保存される。RREQの正当性が確認されるとステップＳ２３へ進み、第２秘密鍵Ktsを用いて、多重化されている全てのHop Infoが次々と復号化される。ステップＳ２４ではHop Infoの検証が行われる。

この際、圏内の端末で生成されたHop InfoにはFWs，FWtが含まれているが、複数のHop Info間でそれらの値が異なる場合には、何らかの不正が行われていると考えられるので、そのRREQは破棄される。全てのFWs，FWtが一致していれば、各Hop Infoに登録されている前段ホップ順序IDおよび自段ホップ順序IDの連続性、および各ホップ順序IDがホップ順に増加しているか否かに基づいて、その正当性が判定される。経路の正当性判断で問題がなければ、ステップＳ２５へ進んで経路情報が登録される。ステップＳ２６では、経路確立応答（RREP）メッセージが生成され、ステップＳ２７においてフラッディングされる。このRREPでも、そのIPヘッダの送信元アドレスにはダミーアドレス（例えば、[0.0.0.0]）が登録され、宛先アドレスにはブロードキャストアドレス（例えば、[255.255.255.255]）が登録される。

図１３は、前記RREPのフォーマットの一例を示した図であり、seq、セッションIDおよびセッションID候補は、受信されたRREQと同じである。受信されたRREQのHop Infoに多重暗号化されて格納されていた各中継端末のHop Infoは、各Hop Infoに登録されていた第２共有鍵KCxで別々に暗号化されて連結される。各Hop Infoの連結順列はランダムである。なお、適当な数のダミーHop Infoを挿入すれば第三者にHop数を知られにくできる。前記各Hop Infoにおいて、セッション鍵SKは、そのRREPの中の全てのHop Infoに共通であり、RREP送出時に宛先端末Tがランダムに発生させる。

なお、送信端末S用のHop Infoには、図１４に一例を示したように、さらにデータ通信時に用いる暗号鍵（例えば、AES暗号を用いるならAES暗号鍵）と共に、全中継端末（当該RREQの経由端末）の自アドレスIPx，自段ホップ順序IDおよび第２共有鍵KCxが中継アドレス情報として付け加えられる。データ通信用の暗号鍵(AES）は宛先端末Tが発生させる。flagは送信端末Sに各種情報を伝えるためのものであり、ここでは各中継端末が圏内か圏外かを伝えるための情報を含んでいる。

端末Cでは、図３のステップＳ１５において、前記宛先端末TからフラッディングされたRREPが受信されると図４のステップＳ３１へ進み、このRREPに登録されているセッションIDを検索キーとして転送リストが検索される。ステップＳ３２では、セッションIDと対応付けられている第２共有鍵KCxが抽出される。

なお、先にRREQを受信した際に、そのセッション IDが「０」であった場合には、セッションID候補が転送リストに登録されているので、セッションIDで検索できなかった場合には、前記RREPに登録されているセッションID候補で再度検索される。セッション IDまたはセッションID候補による検索が成功した場合には、RREQのセッション IDの値が転送リストに書き込まれ、セッションID候補の値が「０」に更新される。この検索がともに失敗に終わった場合にはRREPが破棄される。

ステップＳ３３では、前記抽出された第２共有鍵KCxを用いて、RREPに登録されている全てのHop Infoが復号化される。ステップＳ３４では、復号化された全データの中に解読可能な有効データが含まれているか否かが判定される。有効データが得られなければ、改ざんを含む何らかの不正が行われている可能性があるのでステップＳ４１へ進み、今回のRREPが破棄される。

有効なデータが得られたHop InfoがあればステップＳ３５へ進み、前記RREPの宛先が自身であるか否かが判定される。端末Cであれば、宛先が自身以外と判定されるのでステップＳ３６へ進み、それらの内容が転送リストに書き込まれる。ただし、この登録に関するライフタイムは正式登録のものよりも短くされる。

ステップＳ３７では、自身が圏内であるか否かが判定され、圏内であればステップＳ３８へ進み、圏内フラグF1がセットされる。ステップＳ３９では、前記有効なデータを得られた自身のHop Info（図１３）から、自段ホップ順序ID以外のデータが全て削除またはダミーデータに書き替えられ、その後、セッション鍵SKを用いて再暗号化される。ステップＳ４０では、前記再暗号化されたHop Infoを含むRREPがフラッディングされる。この際も、IPヘッダの送信元アドレスにはダミーアドレスが登録され、宛先アドレスにはブロードキャストアドレスが登録される。

以上の手順が各中継端末で実行され、全ての中継端末で不正が検知されなければ、RREPは送信端末Sに到達する。送信端末Sが前記RREPを受信すると、前記RREPの宛先が自身であるか否かが判定される。

ステップＳ３５において自身が宛先と判定されるとステップＳ４２へ進み、セッション鍵SKが抽出される。ステップＳ４３では、前記セッション鍵SKを利用して全てのHop Infoが復号化される。ステップＳ４４では、各Hop Infoに登録されている各移動端末の自段ホップ順序IDが抽出される。ステップＳ４５では、前記RREPに登録されている中継アドレス情報（自段ホップ順序ID）の全てが抽出される。ステップＳ４６では、前記各移動端末の自段ホップ順序IDと全ての中継アドレス情報とが比較される。両者が完全に一致すれば、ステップＳ４７において、前記匿名アドレスFWs、FWtやセッションID等が転送リストに登録される。ステップＳ４８では、経路情報テーブルに登録される。ステップＳ４９では、経路確立完了通知(RCMP)が宛先端末Tへ送信される。

前記RCMPでは、その宛先アドレスおよび送信元アドレスに前記FWt、FWsが設定され、前記RREPで通知されたデータ暗号鍵AESを用いて宛先端末Tへ送信される。宛先端末Tは前記RCMPを受け取ると、PendingされていたRREQが破棄され、経路テーブルが確定される。したがって、宛先端末Tでは当該時点からデータ送信が可能になる。

なお、上記した実施形態では、RREQを受信した移動端末が圏内のときに経路制御サーバRMへFWREQが送信されるものとして説明したが、送信端末Sが圏内であれば、当該送信端末Sからも同様にFWREQが送信される。

次いで、上記のようにして割り当てられた匿名アドレスFWs，FWtを利用して、送信端末Sと宛先端末Tとがデータ通信を行う手順について説明する。

図１５は、送信端末Sにおけるデータフレームの作成手順を示したフローチャートであり、ステップＳ１０１において送信データが生じるとステップＳ１０２へ進み、そのデータフレームが作成される。ステップＳ１０３では、前記データフレームにシーケンス番号seqが書き込まれる。前記シーケンス番号seqは通信セッションごと、すなわち送信元アドレス(FWs)と宛先アドレス(FWt)との組み合わせごとに管理されている。ステップＳ１０４では、前記作成されたデータフレームが、通信セッションごとに設けられている送信待ちキューに連結される。

図１６は、前記送信端末Sにおいて、前記送信待ちキューに登録されているデータフレームを送信する手順を示したフローチャートである。

ステップＳ２０１では、データフレームが連結されている送信待ちキューの有無が判定される。データフレームの連結されている送信待ちキューがあればステップＳ２０２へ進み、その先頭フレームが送信キューにコピーされる。ステップＳ２０３では、前記送信キューにコピーされたデータフレームが、送信元アドレスをFWs，宛先アドレスをFWtとするマルチキャストアドレスで送信される。

図１７は、本実施形態における送信待ちキューと送信キューとの関係を模式的に表現した図であり、送信待ちキューPa(Pa1，Pa2…Pan)は通信セッションごと、すなわち送信元アドレスと宛先アドレスとの組み合わせごとに設けられており、送信キューPbは各移動端末に一つずつ設けられている。前記送信キューPbには各送信待ちキューPaの先頭フレームが一つずつコピーされ、送信キューPbにコピーされたデータフレームのみが当該移動端末から送出される。

図１６へ戻り、送信キューPbにコピーされたデータフレームの送信が完了するとステップＳ２０４へ進み、前記送信キューPbから送信済みのコピーフレームが削除される。ただし、この時点ではコピー元の送信待ちキューPaからオリジナルのデータフレームが削除されることはない。ステップＳ２０５では、前記送信したデータフレームに関して再送タイマがスタートされる。ステップＳ２０６では、前記送信したデータフレームの送信元アドレス(FWs)、宛先アドレス(FWt)、シーケンス番号seqおよび再送ビット等のパラメータが各移動端末のフレーム送信管理リストに登録される。

図１８は、前記送信端末Sや他の端末（中継端末）からマルチキャストアドレスで送信されたデータフレームを受信した端末における中継処理の手順を示したフローチャートである。

ステップＳ３０１では、受信したデータフレームの送信元アドレス(FWs)および宛先アドレス(FWt)の組み合わせに基づいて、自身が経路上の端末であるか否かが判定される。自身が経路上の端末であればステップＳ３０２へ進み、受信フレームに再送フラグがセットされているか否かが判定される。再送フラグがセットされていなければステップＳ３０３へ進み、受信フレームに書き込まれているシーケンス番号(seq[1])と、前記送信元アドレス(FWs)と宛先アドレス(FWt)との組み合わせごとに管理されてテーブルに既登録のシーケンス番号(seq[2])とが比較される。seq[1]＞seq[2]であれば、新しいデータフレームの受信と判定されてステップＳ３０４へ進む。

ステップＳ３０４では、当該受信フレームを隣接端末へ転送（中継）するために、受信フレームの送信元アドレス(FWs)および宛先アドレス(FWt)の組み合わせごとに設けられている送信待ちキューの最後尾に前記受信フレームが連結される。ステップＳ３０５では、前記送信待ちキューの先頭フレームが送信キューへコピーされる。

これに対して、前記ステップＳ３０２において、受信フレームに再送フラグがセットされていると判定されると、当該受信フレームを優先的に処理すべくステップＳ３１４へ進み、前記受信フレームが送信キューへ直接コピーされる。送信キューにコピーされたデータフレームは、前記図１６に示した手順と同様の手順で送信される。

これに対して、前記ステップＳ３０３においてseq[1]＞seq[2]以外と判定されればステップＳ３０６へ進み、seq[1]＝seq[2]であるか否かが判定される。seq[1]＝seq[2]であればステップＳ３０７へ進み、確認待ち状態フラグFwaitの状態が判定される。フラグFwaitがセット状態であればステップＳ３０８へ進み、受信フレームに対応したデータフレームが前記送信待ちキューから削除される。

ステップＳ３０９では、フレーム送信管理リストにおいて前記受信フレームに対応したエントリのシーケンス番号が更新される。本実施形態では、現在のシーケンス番号に「１」だけ加算した値が、次の送信フレームに関するシーケンス番号として更新登録される。ステップＳ３１０では、フレーム送信管理リストに登録されている対応エントリにおいて、前記確認待ち状態フラグFwaitがリセットされる。

なお、前記ステップＳ３０６においてseq[1]＝seq[2]以外、すなわちseq[1]＜seq[2]と判定されるか、あるいはステップＳ３０７において、確認待ち状態フラグFwaitがリセット状態と判定されると、ステップＳ３１２において受信フレームが破棄される。

図１９は、各端末においてデータフレームの中継後に実行される中継済処理の手順を示したフローチャートであり、ステップＳ３５１では、前記送信待ちキューから送信キューへコピーされた先頭フレームが送信されたか否かが判定される。送信が完了するとステップＳ３５２へ進み、確認待ち状態フラグFwaitがセットされる。

図２０は、各移動端末におけるデータフレームの再送手順を示した図であり、ここでは、送信端末Sにおける再送手順を例にして説明する。

ステップＳ５０１では、各送信待ちキューの先頭フレームに関する再送タイマが参照され、タイムアウトしているデータフレームがあればステップＳ５０２へ進む。ステップＳ５０２では、当該データフレームの再送フラグがセットされ、ステップＳ５０３において送信キューにコピーされる。ステップＳ５０４では、前記送信キューにコピーされたデータフレームが再送信される。ステップＳ５０５では、前記再送信されたデータフレームが送信キューから削除される。

ステップＳ５０６では、前記再送したデータフレームの再送回数が上限値に達したか否かが判定される。上限値に達していればステップＳ５０７へ進み、前記データフレームが送信待ちキューからも削除される。これに対して、前記ステップＳ５０６において、再送回数が未だ上限値に達していないと判定されればステップＳ５０８へ進み、再送タイマが再スタートされる。

図２１は、上記したデータ通信方法のシーケンス図であり、送信端末Sから、宛先アドレス(Dst)がFWt、送信元アドレス(Src)がFWs、シーケンス番号が「４３」のデータフレームが送信されると、これを受信した移動端末Aでは、受信フレームの宛先アドレスおよび送信元アドレスに基づいて、自身が当該データフレームに関する中継端末であるか否かが判定される。移動端末Aが自身が中継端末であると判定すると、当該受信フレームをそのまま送信する。移動端末Aはさらに、前記受信フレームの宛先アドレス、送信元アドレスおよびシーケンス番号等を自身のフレーム送信管理リストへ登録する。

送信端末Sは、前記移動端末Aから送信されたデータフレームを受信し、当該受信フレームが自身で送信したデータフレームと同一であるとを確認すると、フレーム送信管理リストにおいて、当該データフレームの送信元アドレスおよび宛先アドレスの組み合わせと対応付けられているシーケンス番号が、現在の「４３」から「４４」へインクリメントされる。したがって、次に送信されるデータフレームでは、シーケンス番号が「４３」から「４４」へ変更されている。移動端末Aでは、送信フレームと同一データフレームが受信されると、フレーム送信管理リストに登録されている対応エントリにおいて、受領状態フラグに受領確認状態Dがセットされる。

宛先端末Tでも同様に、宛先アドレス(Dst)がFWt、送信元アドレス(Src)がFWsのデータフレームを受信すると、当該データフレームを自身宛のデータとして適宜に処理すると同時に、受信フレームと同一フレームを送信する。

本発明の経路確立方法が適用されるアドホックネットワークの図である。 経路制御サーバおよび各移動端末で管理される暗号鍵の一覧を示した図である。 経路確立時に各移動端末で実行される経路確立手順を示したフローチャート（その１）である。 経路確立時に各移動端末で実行される経路確立手順を示したフローチャート（その２）である。 経路確立時に経路制御サーバRMで実施される経路確立手順を示したフローチャートである。 経路確立時のシーケンス図である。 シグナリングメッセージのフォーマットの一例を示した図である。 RREQの基本フォーマットを示した図である。 FWREQの基本フォーマットの一例を示した図である。 FWREPの基本フォーマットの一例を示した図である。 Hop Infoの多重暗号化構造を模式的に表現した図である。 図１の移動端末AからフラッディングされるRREQの一例を示した図である。 RREPのフォーマットの一例を示した図である。 送信端末S用のHop Infoの構造を示した図である。 送信端末Sにおけるデータフレームの作成手順を示したフローチャートである。 送信端末Sにおいて送信待ちキューに登録されているデータフレームを送信する手順を示したフローチャートである。 送信待ちキューと送信キューとの関係を模式的に表現した図である。 マルチキャストアドレスのデータフレームを受信した移動端末における中継処理の手順を示したフローチャートである。 各端末においてデータフレームの中継後に実行される中継済処理の手順を示したフローチャートである。 各移動端末におけるデータフレームの再送手順を示した図である。 本発明に係るデータ通信方法のシーケンス図である。

符号の説明

S，A，B，C，T…移動端末
RM…経路制御サーバ
AP…無線アクセスポイント

Claims (7)

1. 送信元の移動端末および宛先の移動端末が、他の移動端末を中継端末に利用してデータ通信を行うデータ通信方法において、
   前記送信端末および宛先端末のそれぞれにマルチキャストアドレスとして割り当てる匿名アドレスを、前記送信端末、宛先端末および中継端末に登録する手順と、
   送信端末が、送信元アドレスに自身の匿名アドレスが登録され、宛先アドレスに宛先端末の匿名アドレスが登録されたデータフレームを送信する手順と、
   前記データフレームを受信した各移動端末が、その送信元アドレスおよび宛先アドレスの組み合わせに基づいて、自身が当該データフレームの中継端末であるか否かを判定する手順と、
   中継端末が、前記受信したデータフレームを送信する手順と、
   前記データフレームを送信した各端末が、当該データフレームと同一のデータフレームが受信されたか否かに基づいて前記送信したデータフレームの受領確認を行う手順とを含むことを特徴とするデータ通信方法。
2. 前記データフレームを送信した端末が、所定の期間内に受領確認できなかったデータフレームを再送信する手順をさらに含み、
   前記再送信されたデータフレームを受信した中継端末は、当該データフレームを再送信ではない他のデータフレームよりも優先的に送信することを特徴とする請求項１に記載のデータ通信方法。
3. 前記送信端末が、その送信元と宛先との組み合わせに固有のシーケンス番号を当該データフレームに書き込む手順と、
   前記データフレームを受信した端末が、当該データフレームのシーケンス番号に基づいて、当該データフレームが初めて受信されたデータフレームであるか否かを判定する手順と、
   前記送信端末が、当該データフレームと同一のデータフレームを受信したときに前記シーケンス番号を更新する手順とを含むことを特徴とする請求項１または２に記載のデータ通信方法。
4. 前記各端末が、
   送信元アドレスと宛先アドレスとの組み合わせごとに設けられた送信待ちキューと、
   各送信待ちキューの先頭フレームを順次にコピーされ、これを送信する送信キューとを備え、
   送信するデータフレームを前記送信待ちキューへ連結する手順と、
   各送信待ちキューの先頭フレームを送信キューへ順次にコピーする手順と、
   前記送信キューにコピーされたデータフレームを送信する手順と、
   送信済みデータフレームを前記送信キューから削除する手順と、
   受領確認されたデータフレームを前記送信待ちキューから削除する手順とを含むことを特徴とする請求項１ないし３のいずれかに記載のデータ通信方法。
5. 送信元の移動端末および宛先の移動端末が、他の移動端末を中継端末に利用してデータ通信を行うデータ通信システムにおいて、
   前記送信端末、宛先端末および中継端末が、前記送信端末および宛先端末のそれぞれに割り当てられた匿名アドレスを記憶する手段を具備し、
   前記送信端末がさらに、
   送信端末の匿名アドレスを送信元アドレス、宛先端末の匿名アドレスを宛先アドレスとするデータフレームを送信する手段を具備し、
   前記中継端末がさらに、
   宛先がマルチキャストアドレスのデータフレームを受信する手段と、
   前記受信フレームの送信元アドレスおよび宛先アドレスの組み合わせに基づいて、自身が中継端末であるか否かを判定する手段と、
   自身が中継端末となる受信フレームを送信する手段とを具備し、
   前記送信端末および中継端末がさらに、
   送信したデータフレームと同一のデータフレームが受信されたか否かに基づいて、前記送信したデータフレームの受領確認を行う手段とを含むことを特徴とするデータ通信システム。
6. 前記データフレームを送信した端末が、所定の期間内に受領確認できなかったデータフレームを再送信する手段をさらに含み、
   前記再送信されたデータフレームを受信した中継端末は、当該データフレームを再送信ではない他のデータフレームよりも優先的に送信することを特徴とする請求項５に記載のデータ通信システム。
7. 前記データフレームを送信する端末が、その送信元と宛先との組み合わせに固有のシーケンス番号を当該データフレームに書き込む手段を具備し、
   前記データフレームを受信した端末が、当該データフレームのシーケンス番号に基づいて、当該データフレームが初めて受信されたデータフレームであるか否かを判定する手段を具備し、
   前記データフレームを送信した端末は、当該データフレームと同一のデータフレームを受信したときに前記シーケンス番号を更新することを特徴とする請求項５または６に記載のデータ通信システム。

Images