(57)【特許請求の範囲】
【請求項１】
子端末から１個または複数個の中継端末を介して親端末へデータを伝送するマルチホップネットワークシステムであって、
前記中継端末は前記親端末宛の経路情報と、前記データを受け取った前記親端末からの返信の必要性を認識する認識手段と、返信用の経路情報を記録する記録手段と、前記返信用の経路情報を削除する削除手段とを含み、
前記データには返信が必要か否かを示す返信必要フラグが含まれ、前記認識手段は前記返信必要フラグに基づき返信の要否を判断し、かつ前記記録手段は前記認識手段により返信が必要と認識された場合に前記返信用の経路情報を記録することを特徴とするマルチホップネットワークシステム。
【請求項２】
前記削除手段は前記親端末からの返信を受け取った場合に前記返信用の経路情報を削除することを特徴とする請求項１記載のマルチホップネットワークシステム。
【請求項３】
前記記録手段は返信用の経路情報として、前記データの送信経路と逆順の経路を記録することを特徴とする請求項１または２記載のマルチホップネットワークシステム。
【請求項４】
前記記録手段が前記返信用の経路情報の記録に失敗した場合、前記データの転送処理は中止されることを特徴とする請求項１から３いずれかに記載のマルチホップネットワークシステム。
【請求項５】
さらに前記データは廃棄され、かつ異常応答が前記中継端末から前記子端末へ送信されることを特徴とする請求項４記載のマルチホップネットワークシステム。
【請求項６】
前記子端末、前記中継端末および前記親端末はメッシュ状に配置されてネットワークが形成されることを特徴とする請求項１から５いずれかに記載のマルチホップネットワークシステム。
【請求項７】
前記子端末および中継端末は移動体からのデータを前記親端末へ転送することを特徴とする請求項６記載のマルチホップネットワークシステム。
【請求項８】
子端末から１個または複数個の中継端末を介して親端末へデータを伝送するマルチホップネットワークシステムにおける経路制御方法であって、
前記中継端末は前記親端末宛の経路情報を含み、前記データを受け取った前記親端末からの返信の必要性を認識する認識ステップと、返信用の経路情報を記録する記録ステップと、前記返信用の経路情報を削除する削除ステップとを含み、
前記データには返信が必要か否かを示す返信必要フラグが含まれ、前記認識ステップは前記返信必要フラグに基づき返信の要否を判断し、かつ前記記録ステップは前記認識ステップにより返信が必要と認識された場合に前記返信用の経路情報を記録することを特徴とする経路制御方法。
【請求項９】
前記削除ステップは前記親端末からの返信を受け取った場合に前記返信用の経路情報を削除することを特徴とする請求項８記載の経路制御方法。
【請求項１０】
前記記録ステップは返信用の経路情報として、前記データの送信経路と逆順の経路を記録することを特徴とする請求項８または９記載の経路制御方法。
【請求項１１】
前記記録ステップが前記返信用の経路情報の記録に失敗した場合、前記データの転送処理は中止されることを特徴とする請求項８から１０いずれかに記載の経路制御方法。
【請求項１２】
さらに前記データは廃棄され、かつ異常応答が前記中継端末から前記子端末へ送信されることを特徴とする請求項１１記載の経路制御方法。
【請求項１３】
前記子端末、前記中継端末および前記親端末はメッシュ状に配置されてネットワークが形成されることを特徴とする請求項８から１２いずれかに記載の経路制御方法。
【請求項１４】
前記子端末および中継端末は移動体からのデータを前記親端末へ転送することを特徴とする請求項１３記載の経路制御方法。
【請求項１５】
子端末から１個または複数個の中継端末を介して親端末へデータを伝送するマルチホップネットワークシステムにおける前記中継端末であって、
前記親端末宛の経路情報と、前記データを受け取った前記親端末からの返信の必要性を認識する認識手段と、返信用の経路情報を記録する記録手段と、前記返信用の経路情報を削除する削除手段とを含み、
前記データには返信が必要か否かを示す返信必要フラグが含まれ、前記認識手段は前記返信必要フラグに基づき返信の要否を判断し、かつ前記記録手段は前記認識手段により返信が必要と認識された場合に前記返信用の経路情報を記録することを特徴とする中継端末。
【請求項１６】
前記削除手段は前記親端末からの返信を受け取った場合に前記返信用の経路情報を削除することを特徴とする請求項１５記載の中継端末。
【請求項１７】
前記記録手段は返信用の経路情報として、前記データの送信経路と逆順の経路を記録することを特徴とする請求項１５または１６記載の中継端末。
【請求項１８】
前記記録手段が前記返信用の経路情報の記録に失敗した場合、前記データの転送処理は中止されることを特徴とする請求項１５から１７いずれかに記載の中継端末。
【請求項１９】
さらに前記データは廃棄され、かつ異常応答が前記中継端末から前記子端末へ送信されることを特徴とする請求項１８記載の中継端末。
【請求項２０】
前記子端末、前記中継端末および前記親端末はメッシュ状に配置されてネットワークが形成されることを特徴とする請求項１５から１９いずれかに記載の中継端末。
【請求項２１】
前記子端末および中継端末は移動体からのデータを前記親端末へ転送することを特徴とする請求項２０記載の中継端末。
【請求項２２】
子端末から１個または複数個の中継端末を介して親端末へデータを伝送するマルチホップネットワークシステムにおける経路制御方法のプログラムであって、
前記中継端末は前記親端末宛の経路情報を含み、コンピュータに、前記データを受け取った前記親端末からの返信の必要性を認識する認識ステップと、返信用の経路情報を記録する記録ステップと、前記返信用の経路情報を削除する削除ステップとを実行させるためのプログラムであり、
前記データには返信が必要か否かを示す返信必要フラグが含まれ、前記認識ステップは前記返信必要フラグに基づき返信の要否を判断し、かつ前記記録ステップは前記認識ステップにより返信が必要と認識された場合に前記返信用の経路情報を記録することを特徴とするプログラム。
【請求項２３】
前記削除ステップは前記親端末からの返信を受け取った場合に前記返信用の経路情報を削除することを特徴とする請求項２２記載のプログラム。
【請求項２４】
前記記録ステップは返信用の経路情報として、前記データの送信経路と逆順の経路を記録することを特徴とする請求項２２または２３記載のプログラム。
【請求項２５】
前記記録ステップが前記返信用の経路情報の記録に失敗した場合、前記データの転送処理は中止されることを特徴とする請求項２２から２４いずれかに記載のプログラム。
【請求項２６】
さらに前記データは廃棄され、かつ異常応答が前記中継端末から前記子端末へ送信されることを特徴とする請求項２５記載のプログラム。
【請求項２７】
前記子端末、前記中継端末および前記親端末はメッシュ状に配置されてネットワークが形成されることを特徴とする請求項２２から２６いずれかに記載のプログラム。
【請求項２８】
前記子端末および中継端末は移動体からのデータを前記親端末へ転送することを特徴とする請求項２７記載のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、マルチホップネットワークシステムおよびその経路制御方法ならびにそれを構成する中継端末およびプログラムに関し、特にネットワークが大規模で各端末がルーティング情報を保持するのが困難であり、なおかつネットワークの通信が子端末から親端末（センター端末）への通信に限られるマルチホップネットワークシステムおよびその経路制御方法ならびにそれを構成する中継端末およびプログラムに関する。
【背景技術】
【０００２】
マルチホップとは、いわゆる「バケツリレー方式」で主に無線による通信において、端末自体が通信を中継する能力をもつことで、個々の無線通信の到達距離の何倍もの通信距離を実現するための手法である。このようなマルチホップ機能をもつ端末に自律的なネットワーク構成機能を付加することにより、端末をある程度の密度で無作為に配置することで、自動的にネットワーク（マルチホップネットワーク）を構成することができる。
【０００３】
一方、端末間で緊急時に通報データの送受信が可能な無線ネットワーク端末がそれぞれ搭載され屋外に設置される複数の子機を備え、その複数の子機は、その無線ネットワーク端末をマルチホップ接続してその通報データを送受信するための無線ネットワークを構成し、その無線ネットワーク端末は、その通報データの受信によりマルチホップ接続された無線ネットワークの次子機の無線ネットワーク端末へとその通報データを順次転送して予め測定された最短距離の無線ネットワーク端末から所定の通報機関へと通報を行う緊急通報装置が開示されている（特許文献１）。
【０００４】
また、アドホックネットワークにおいて、効率的な同報通信機能といった高度なネットワーク機能を実現するモバイルアドホックネットワークシステムが開示されている（特許文献２参照）。
【０００５】
また、十分な性能（メモリサイズ）を持った端末が前提で、複数の機能を持った同報通信をひとつにまとめることにより、同報通信の数を減らし、ネットワークの効率化を図る発明が開示されている（特許文献３参照）。
【０００６】
【特許文献１】特開２００５−０７９６８７号公報
【特許文献２】特開２００５−０７２８３４号公報（段落００４３）
【特許文献３】特表２００３−５１６０３４号公報（段落０００１、００２６および００３６）
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかし、マルチホップネットワークを構成する端末が数多くなると、中継のための経路情報（ルーティングテーブル）が膨大になり、端末のメモリ量の増加やルート検索速度の増加など重大な悪影響を与えるおそれがある。
【０００８】
一方、ネットワークの通信形態として、各端末（子端末）がひとつのセンター端末（親端末）にデータを送信し、その送信に対する返信を受け取るのみで、子端末間のデータ通信や親端末から子端末に返信以外のデータを送信することのないネットワーク通信形態を想定すると、子端末から親端末への送信については、ルーティングテーブルに親端末向けの経路情報のみ保持しておけば実現可能であるが、親端末から子端末向けの通信については、全ての子端末の数だけ経路情報を保持するのは困難という課題がある。
【０００９】
一方、特許文献１記載の発明に上記課題を解決する手段は開示されていない。
【００１０】
また、特許文献２記載の発明は本発明が念頭におく「制約のある環境で、機能を制限することによりネットワークの基本機能を実現しようとする際に、発生する問題を解決する」とは目的や想定している端末の性能（メモリサイズ等）が全く相違する。本発明の特徴は、端末のメモリサイズが少ないという前提のもとに、その記憶を効率的に管理することにある。
【００１１】
また、「端末を転送管理テーブルから削除」という記載がこの特許文献２になされているが、この文献記載の発明では、グループ通信の参加端末の管理のため、不参加端末を削除するのに対し、本発明ではメモリ容量削減のため、不要なエントリを削除するのであり、削除の目的が全く相違する。また、その手段はこの特許文献２記載の発明では、削除指示が明示されたメッセージを受け取った端末がそのメッセージに従い削除するのに対し、本発明ではエントリの必要性がなくなったことを認識し削除するものであり、手段も全く相違する。
【００１２】
また、特許文献３記載の発明には、「返信が必要なメッセージを作成」する要素が含まれているが、返信が必要であることを認識できるのは最終的な受信端末のみで、中継端末においては返信の必要性の有無を全く認識しない。これに対し、本発明では返信の必要性を中継端末が認識する必要があり、そのために「返信必要フラグ」なるものを用意し、それを「中継端末が認識できる箇所に設けている。このように、特許文献３記載の発明と本発明とではその構成が全く相違する。
【００１３】
そこで本発明の目的は、経路情報（ルーティングテーブル）のためのメモリ容量を削減し、経路情報（ルーティングテーブル）の検索に要する処理時間を削減することで通信に関わる遅延を削減することが可能なマルチホップネットワークシステムおよびその経路制御方法ならびにそれを構成する中継端末およびプログラムを提供することにある。
【課題を解決するための手段】
【００１４】
前記課題を解決するために本発明によるマルチホップネットワークシステムは、子端末から１個または複数個の中継端末を介して親端末へデータを伝送するマルチホップネットワークシステムであって、前記中継端末は前記親端末宛の経路情報と、前記データを受け取った前記親端末からの返信の必要性を認識する認識手段と、返信用の経路情報を記録する記録手段と、前記返信用の経路情報を削除する削除手段とを含み、前記データには返信が必要か否かを示す返信必要フラグが含まれ、前記認識手段は前記返信必要フラグに基づき返信の要否を判断し、かつ前記記録手段は前記認識手段により返信が必要と認識された場合に前記返信用の経路情報を記録することを特徴とする。
【００１５】
また本発明による経路制御方法は、子端末から１個または複数個の中継端末を介して親端末へデータを伝送するマルチホップネットワークシステムにおける経路制御方法であって、前記中継端末は前記親端末宛の経路情報を含み、前記データを受け取った前記親端末からの返信の必要性を認識する認識ステップと、返信用の経路情報を記録する記録ステップと、前記返信用の経路情報を削除する削除ステップとを含み、前記データには返信が必要か否かを示す返信必要フラグが含まれ、前記認識ステップは前記返信必要フラグに基づき返信の要否を判断し、かつ前記記録ステップは前記認識ステップにより返信が必要と認識された場合に前記返信用の経路情報を記録することを特徴とする。
【００１６】
また、本発明による中継端末は、子端末から１個または複数個の中継端末を介して親端末へデータを伝送するマルチホップネットワークシステムにおける前記中継端末であって、前記親端末宛の経路情報と、前記データを受け取った前記親端末からの返信の必要性を認識する認識手段と、返信用の経路情報を記録する記録手段と、前記返信用の経路情報を削除する削除手段とを含み、前記データには返信が必要か否かを示す返信必要フラグが含まれ、前記認識手段は前記返信必要フラグに基づき返信の要否を判断し、かつ前記記録手段は前記認識手段により返信が必要と認識された場合に前記返信用の経路情報を記録することを特徴とする。
【００１７】
また、本発明によるプログラムは、子端末から１個または複数個の中継端末を介して親端末へデータを伝送するマルチホップネットワークシステムにおける経路制御方法のプログラムであって、前記中継端末は前記親端末宛の経路情報を含み、コンピュータに、前記データを受け取った前記親端末からの返信の必要性を認識する認識ステップと、返信用の経路情報を記録する記録ステップと、前記返信用の経路情報を削除する削除ステップとを実行させるためのプログラムであり、
前記データには返信が必要か否かを示す返信必要フラグが含まれ、前記認識ステップは前記返信必要フラグに基づき返信の要否を判断し、かつ前記記録ステップは前記認識ステップにより返信が必要と認識された場合に前記返信用の経路情報を記録することを特徴とする。
【００１８】
ここで、本発明の作用を述べる。本発明では、子端末から親端末へのデータ送信が行われる際に、親端末から子端末への返信に備えて各中継端末が当該子端末用の経路情報を仮ルーティングテーブルの形で保持することを基本としている。
【００１９】
まず、無駄な仮ルーティングテーブルへの記録処理を避けるため、子端末は返信が必要で、中継端末が仮ルーティングテーブルに当該子端末へのエントリを追加する必要のあるデータを、そのような処理が不要なデータと区別するために、送信データ中に「返信必要フラグ」を立てる（機能１）。
【００２０】
返信必要フラグは中継端末が参照する部分（通信ヘッダ等）に設けられる。なお、システムとして、全データに返信が必要と規定されている場合、機能１は不要であるが、別途記載するパケットフラグメントが発生するような場合は、当該フラグを持つことが好ましい。
【００２１】
返信必要フラグが立っているデータを中継する端末（システムとして全データに返信が必要と規定されている場合は、全データを中継する端末）は、本データの発信元である子端末向けの経路情報を仮ルーティングテーブルに記録する（機能２）。
【００２２】
記録内容としては、（１）最終宛先地として当該データの発信元である子端末、（２）次のホップ先として当該データの直接の送信元、を記録する。このデータの直接の送信元は確認できるシステムであることが必須である。また、同じ子端末から複数の返信必要フラグ付きデータが送られてきた場合、中継端末では仮ルーティングテーブルに複数のエントリを追加してもよいが、メモリ容量削減の意味からはエントリにカウンタを追加し、要求個数を監理する方が望ましい。
【００２３】
このようにして、全ての中継端末に返信用の経路情報（ルーティングテーブル）が記録された状態で、親端末にデータが送信される。なお、途中の中継端末において仮ルーティングテーブルのサイズの問題等で返信用のエントリの追加ができなかった場合は、返信が届くことはあり得ないので、通常のプロトコル的な意味合いからこれ以上のデータ通信は不要である。この場合、データの輻輳を避けるため、当該データの中継自体を中止し、データを廃棄すると同時に、異常応答にてデータ発信元の子端末に応答する（機能４）。
【００２４】
親端末からの応答、もしくは中継端末が返信用のエントリの追加ができなかった場合に送る異常応答は、中継端末によって仮ルーティングテーブルを参照しながら転送される。参照された当該エントリはメモリ節約のため、返送転送終了後直ちに削除される（機能３）。
【００２５】
なお、カウンタにて要求個数を監理している場合は、カウンタを減算し、ゼロになった時点で消去する。また、なんらかの障害によりエントリが削除されることなく滞留することを防ぐために、なんらかのエイジング機能（時間経過によりエントリを削除する機能）をもつことは有効である。
【００２６】
なお、データがフラグメント（パケット分割）される場合は、最初のパケットのみ「返信必要フラグ」を立て、残りのパケットについては「返信必要フラグ」を立てないようにする。
【発明の効果】
【００２７】
本発明によれば、上記構成を含むため、経路情報（ルーティングテーブル）のためのメモリ容量を削減し、経路情報（ルーティングテーブル）の検索に要する処理時間を削減することで通信に関わる遅延を削減することが可能となる。
【発明を実施するための最良の形態】
【００２８】
以下、本発明の実施例について添付図面を参照しながら説明する。
【実施例１】
【００２９】
図１は本発明に係るマルチホップネットワークで用いられる端末の一例の構成図である。同図を参照すると、端末５０はデータを送信する送信部５１と、データを受信する受信部５２と、データ表示を行う表示部５３と、音声を出力するスピーカ５４と、音声を入力するマイクロフォン（マイクと記す）５５と、キーボード等の入力部５６と、マルチホップネットワークの経路制御方法のプログラムが格納されるプログラム格納メモリ５７と、経路情報（ルーティングテーブル）が格納されるルーティングテーブル格納メモリ５８と、各部５１〜５８を制御する制御部５９と、送信アンテナ６１と、受信アンテナ６２とを含んで構成される。
【００３０】
図２は本発明に係るマルチホップネットワークシステムにおいて子端末１から親端末２へデータを送信する場合の動作の一例を示す模式図である。同図（Ａ）は仮ルーティングテーブルの一例の構成図、同図（Ｂ）はマルチホップネットワークを形成する端末のデータ転送経路の一例を示す図、同図（Ｃ）は送信データの一例の構成図である。
【００３１】
同図（Ｂ）を参照すると、データ発信元の子端末１から送信データが中継端末（Ｎ−１）、Ｎ，（Ｎ＋１）等（Ｎは正の整数）を経由してデータ発信先親端末２に転送される様子が模式的に表示されている。このように、子端末１と親端末２間のデータ通信はマルチホップ通信にて行なわれ、データは中継端末Ｎ等により中継される。
【００３２】
なお、子端末１と中継端末Ｎ等は役割を固定されている場合もあるが、通常では一つの端末が子端末と中継端末双方の役割を持ち、データ通信と中継の両方の処理を行う。全ての端末には経路情報を記録するためのルーティングテーブルが用意されており、固定的なエントリとして、親端末２向けの経路情報が記録されている。
【００３３】
同図（Ａ）の左側の仮ルーティングテーブルには、一例として、中継端末Ｎの固定的なエントリとして、親端末２向けの経路情報が記録されている。すなわち、送信データのあて先が親端末２、次ホップが中継端末（Ｎ＋１）、カウンタがＮ／Ａであることを示している。
【００３４】
なお、親端末２向けの経路情報は仮ルーティングテーブルと別のテーブル情報に保持することも可能であるが、仮ルーティングテーブル内の固定的エントリとして記録しておくことも可能で、図２ではそのようなイメージでの記載を行っている。この場合、エントリ削除の制御に用いるカウンタは無意味となるため、Ｎ／Ａ（Ｎｏｔ  Ａｖａｉｌａｂｌｅ）と表記した。
【００３５】
また、親端末２向けのエントリの作成方法については、手動設定、経路情報を交換するネットワークプロトコルによる自動設定、両者の混合など様々な方式が考えられ、いずれかの方法でエントリが作成されるものとする。さらに、中継端末Ｎ等や通信リンクの障害に備えて、親端末２宛のエントリを複数持つような形態も考えられるが、本発明はそのような場合でも特に考慮を加えることなく適用が可能である。
【００３６】
また、仮ルーティングテーブルのサイズについてはシステム的な調整が必要であり、中継端末Ｎ等の上位に位置する端末数、返信が必要なデータの発生頻度、返信処理にかかる時間等のパラメータと利用可能なメモリ量等から適正なサイズを選択する。
【００３７】
なお、各通信リンクは双方向であり、通信方向によって通信可または不可の状況が変わることはないものとする。
【００３８】
次に、子端末１から親端末２に向けてデータを送信する場合の各端末の動作について説明する。図３は子端末１の動作の一例を示すフローチャート、図４は中継端末Ｎの動作の一例を示すフローチャートである。
【００３９】
子端末１から発信された送信データ１００は、通信ヘッダ部１０１と、アップリケーションデータ部１０２とに大別され（図２（Ｃ）参照）、データ受信先である親端末２以外の中継端末Ｎ等では通信ヘッダ部１０１のみを参照してデータの中継を行う。
【００４０】
子端末１では、親端末２からの返信（データ受け取り正常応答等）を必要とする場合（図３のステップＳ１にて“Ｙ”の場合）、通信ヘッダ部１０１内に設けられた返信必要フラグ１０３（図２（Ｃ）参照）をセット（ＯＮ）して（図３のステップＳ２）、データを発信する（同図のステップＳ３）。なお、データがフラグメント（複数パケットに分割）される場合、返信必要フラグ１０３は先頭パケットのみにセットされ、残りのパケットについては返信必要フラグ１０３はクリアしておく。
【００４１】
一方、親端末２からの返信（データ受け取り正常応答等）を必要としない場合（図３のステップＳ１にて“Ｎ”の場合）、返信必要フラグ１０３（図２（Ｃ）参照）をセットしないで、すなわちクリアして（ＯＦＦ）データを発信する（同図のステップＳ３）。
【００４２】
子端末１と親端末２は直接通話できない状況であり、中継端末Ｎ等による中継によりデータを転送する。親端末２にデータを送信する際に、次にどの中継端末にデータを送ればよいかという経路情報はルーティングテーブルの形で子端末１に記録されており、中継が開始される。
【００４３】
以降、中継経路にある中継端末Ｎに注目して、中継時の処理の詳細を説明する。中継端末Ｎでは中継端末（Ｎ−１）より子端末１が発信したデータを受信する（図４のステップＳ１１）。
【００４４】
この時、本データを中継端末（Ｎ−１）から受信したことを認識し、記憶できるものとする。中継端末Ｎは通信ヘッダ部１０１内にある送信先アドレスをチェックし、送信先となっている親端末２にデータを送信するための経路情報を仮ルーティングテーブル（図２（Ａ）の左側の仮ルーティングテーブル１１（転送前）参照）にて検索し（同図のステップＳ１２）、次ホップが中継端末（Ｎ＋１）であることを確認する（同図のステップＳ１３）。
【００４５】
次に、中継端末Ｎでは返信必要フラグ１０３がセットされているかどうかをチェックし（同図のステップＳ１４）、セットされていた場合は（同図のステップＳ１４にて“Ｙ”の場合）、仮ルーティングテーブルに、宛先：子端末１（通信データ内の送信元アドレスから情報を獲得する）、次ホップ：（Ｎ−１）（先ほど記録したデータの直接受信元）というエントリを追加し、カウンタを“１”とする（同図のステップＳ１５）。なお、この時の仮ルーティングテーブルの内容は図２（Ａ）の右側の仮ルーティングテーブル１２（転送後）に表示されている。
【００４６】
ただし、同一の送信元（子端末１）および次ホップ中継端末（Ｎ−１）に関するエントリが既に存在していた場合は、エントリの追加は行わず、カウンタを“１”だけ増加するものとする。
【００４７】
次に、データを中継端末（Ｎ＋１）へ送信する（同図のステップＳ１６）。
【００４８】
一方、返信必要フラグ１０３がセットされていなかった場合は（同図のステップＳ１４にて“Ｎ”の場合）、仮ルーティングテーブルへのエントリの追加は行わずステップＳ１６へ進む。
【００４９】
なお、同じ送信元（子端末１）からのデータを異なる中継端末から受信した場合は、最新の情報の方が有効（障害等による迂回の影響の可能性等）という考え方から、エントリを単純に上書きし、カウンタを“１”だけ増加するという方式も考えられるが、送信時と異なる経路で返信の転送を行うと、カウンタ値の整合が取れなくなるため、そのような上書き方式は採用せずに新規にエントリを追加する方式とする。
【００５０】
この場合、次の返信データの処理時には対応するエントリが複数あり、どちらの次ホップを選択するかの基準は存在しないことになるが、それはやむを得ないものとする。これにより、障害による経路切り替え発生直後に何かしらの通信障害が発生する可能性はあるが、再送等による解決は可能である。
【００５１】
次に、親端末２から子端末１に向けて返信を送信する場合の各端末の動作について説明する。
【００５２】
図５は本発明に係るマルチホップネットワークシステムにおいて親端末２から子端末１へ返信を送信する場合の動作の一例を示す模式図である。同図（Ａ）は仮ルーティングテーブルの一例の構成図、同図（Ｂ）はマルチホップネットワークを形成する端末のデータ転送経路の一例を示す図、同図（Ｃ）は送信データの一例の構成図である。なお、同図は図２とデータの送信方向が逆になった場合の各端末の動作を示している。また、図６は親端末２の動作の一例を示すフローチャート、図７は中継端末Ｎの動作の一例を示すフローチャートである。
【００５３】
まず、親端末２の動作について説明する。前述したような中継を繰り返し、最終的に親端末２にてデータが受信されると（図６のステップＳ２１）、親端末２では受信したデータを処理し（同図のステップＳ２２）、返信を子端末１宛に送信する（同図のステップＳ２３）。
【００５４】
図５（Ｃ）を参照すると、親端末２から子端末１へ返信を送信する場合は、返信必要フラグ１０３は意味論上“ＯＦＦ”とするが、中継端末Ｎ等においては親端末２宛のデータ以外では返信必要フラグ１０３のチェックは行わないため、返信必要フラグ１０３が“ＯＮ”の状態でも処理上は問題がない。返信の中継は元データの送信時の逆順に行われる。
【００５５】
中継端末Ｎでは、子端末１宛のデータを受信すると（図７のステップＳ３１）、仮ルーティングテーブル（図５（Ａ）の左側の仮ルーティングテーブル１３（返信転送前）参照）を検索して、子端末１に適合するエントリを参照し、次ホップ（Ｎ−１）を得る（同図のステップＳ３２）。
【００５６】
次に、本エントリのカウンタ値を“１”だけ減算し、カウンタ値がゼロになった場合は、仮ルーティングテーブルから該当するエントリを削除する（同図のステップＳ３３）。エントリ削除後の仮ルーティングテーブルの一例が図５（Ａ）の右側の仮ルーティングテーブル１４（返信転送後）に表示されている。
【００５７】
その後、中継端末Ｎはデータを中継端末（Ｎ−１）に転送する（同図のステップＳ３４）。
【００５８】
このような中継を繰り返し、返信が子端末１に到達した時点で、全ての中継端末Ｎ等の仮ルーティングテーブルは、子端末１によるデータ発信前の状態に復元される。
【００５９】
次に、子端末１から親端末２へのデータ通信の際に中継端末Ｎにおいて仮ルーティングテーブルへの書き込みがメモリ制約等により失敗した場合について説明する。図８は本発明に係るマルチホップネットワークシステムにおいて、中継端末Ｎにおいて仮ルーティングテーブルへの書き込みがメモリ制約等により失敗した場合の動作の一例を示すフローチャートである。
【００６０】
まず、中継端末Ｎにおいて仮ルーティングテーブルへの書き込みがメモリ制約等により失敗した場合（図８のステップＳ４１）、少なくとも中継端末Ｎにおいて返信データ用のルーティングテーブルが存在しないため、返信データの中継は通信系全体として不可能となる。これは、システム全体から見ると、子端末１から親端末２へのデータ通信自体が失敗したこととなるため、これ以上のデータ転送はネットワーク負荷の増加を招くのみとなるため、転送処理はこの時点で中止し（同図のステップＳ４２）、データを廃棄する（同図のステップＳ４３）。
【００６１】
この時、子端末１から中継端末（Ｎ−１）までの間の中継端末の仮ルーティングテーブルにおいては、子端末１用の返信用のエントリが既に準備されている状態である。そこで、この子端末１から中継端末（Ｎ−１）までの間の中継端末の仮ルーティングテーブル内の子端末１用の返信用のエントリを全て削除する（同図のステップＳ４４）。
【００６２】
そして、データ通信が中継端末において廃棄されたことを子端末１に通知するために、中継端末Ｎから子端末１に「異常応答」が送信される（同図のステップＳ４５）。また、本「異常応答」は中継端末（Ｎ−１）から通常の返信と同様に逆順に転送され、通常の応答と同様に仮ルーティングテーブルから子端末１へのエントリを削除する効果を持つ。
【００６３】
以上説明したように本発明の第１実施例によれば、経路情報（ルーティングテーブル）用のメモリ容量を従来よりも大幅に削減することが可能となる。これにより、経路情報検索の高速化を図ることが可能となる。また、不要データの転送を抑圧することにより、ネットワーク性能の向上を図ることも可能となる。
【実施例２】
【００６４】
図９は本発明に係るマルチホップネットワークシステムの第２実施例の構成図である。
【００６５】
同図を参照すると、メッシュ状に複数個の無線センサー子端末３０（中継端末）を設置してネットワークが形成され、そのネットワークの中央（同図では左上部）に処理サーバ２１（親端末）が設置されている。各無線センサー子端末３０（中継端末）はその周辺の温度、湿度および振動等の状況を定期的にセンシング（ｓｅｎｓｉｎｇ）し、処理サーバ２１（親端末）宛発信する。これらのデータを受け取った処理サーバ２１（親端末）はそれらデータを処理する。無線センサー子端末３０（中継端末）と処理サーバ２１（親端末）との通信形態は無線通信であり、マルチホップネットワークを形成する。また、処理サーバ２１（親端末）へのルーティングについては無線センサー子端末３０（中継端末）設置時に手動で設定するものとし、障害に備えて複数経路を事前に設定しておくものとする。
【００６６】
また、システムのネットワーク負荷を下げるため、各無線センサー子端末３０（中継端末）のデータ発信周期は各無線センサー子端末３０（中継端末）ごとに制御し、通信が輻輳しないようにする。
【００６７】
また、線センサー子端末３０（中継端末）はデータが処理サーバ２１（親端末）に届いていることを確認するために、処理サーバ２１（親端末）からの返信を待ち、返信が受信できない場合は再送を行う。また、処理サーバ２１（親端末）からの返信には次回データ収集タイミング等の情報を付加することも出来、これをシステム制御に活用することが可能である。
【００６８】
以上説明したように本発明の第２実施例によれば、本発明をメッシュ状に複数個の無線センサー子端末３０（中継端末）が設置されたネットワークに適用することが可能となる。
【実施例３】
【００６９】
図１０は本発明に係るマルチホップネットワークシステムの第３実施例の構成図である。
【００７０】
同図を参照すると、第２実施例と同様に、メッシュ状に複数個の中継端末（無線端末）３２を設置してネットワークが形成され、そのネットワークの中央（同図では左上部）に処理サーバ２２（親端末）が設置されているが、子端末自体は中継機能のみを持ち、データ発信機能は本ネットワーク内を移動する移動体３１が持つ。
【００７１】
この場合、移動体３１自身はデータをブロードキャスト（ｂｒｏａｄｃａｓｔ：一斉同報）で発信し、これを受信した中継端末（無線端末）３２が処理サーバ２２（親端末）にデータを送信する。
【００７２】
このデータを受信した中継端末（無線端末）３２の位置から移動体３１の大よその位置を把握することが可能である。この場合、処理サーバ２２（親端末）からの返信を受け取るのは移動体３１からのデータを受信した中継端末（無線端末）３２であり、トポロジーの変化は存在しない。
【００７３】
以上説明したように本発明の第３実施例によれば、第２実施例のネットワークにおける無線センサー子端末３０（中継端末）を、中継端末（無線端末）３２と、この中継端末（無線端末）３２と通信する移動体３１とで置換したシステムに適用することが可能となる。
【実施例４】
【００７４】
第４実施例は経路制御方法のプログラムに関するものである。図１に示したように端末５０（１およびＮ等）はマルチホップネットワークの経路制御方法のプログラムが格納されるプログラム格納メモリ５７を有している。一方、親端末もまたマルチホップネットワークの経路制御方法のプログラムが格納される図示しないプログラム格納メモリを有している。
【００７５】
端末５０（１およびＮ等）のメモリ５７に格納されるプログラムは図３，４，７および８にフローチャートで示す手順をコンピュータ（図１の制御部５９）に実行させるためのプログラムである。
【００７６】
一方、親端末の図示しないメモリに格納されるプログラムは図６にフローチャートで示す手順をコンピュータ（親端末の図示しない制御部）に実行させるためのプログラムである。
【００７７】
端末５０（１およびＮ等）の制御部５９は、メモリ５７からプログラムを読み出し、そのプログラムに従って送信部５１および受信部５２を制御する。その制御の内容は既に述べたのでここでの説明は省略する。
【００７８】
一方、親端末の図示しない制御部は、図示しないメモリからプログラムを読み出し、そのプログラムに従って図示しない送信部および受信部を制御する。その制御の内容は既に述べたのでここでの説明は省略する。
【００７９】
以上説明したように本発明の第４実施例によれば、経路情報（ルーティングテーブル）用のメモリ容量を従来よりも大幅に削減することが可能なプログラムが得られる。
【実施例５】
【００８０】
第１実施例では、返信必要フラグ１０３を設けて返信の必要性を明示するシステムとしているが、システムとして返信が常時必要とされるものも考えられ、その場合は返信必要フラグ１０３を削除し、返信必要フラグは常時セットされているという前提での処理を行う。この場合、データフラグメントは禁止される。
【００８１】
また、中継端末において仮ルーティングテーブルへのエントリ追加が不可能であった場合、第１実施例ではデータ転送自体を中止するとしているが（図８のステップＳ４２参照）、異常応答を発信元に送るのと並行して、親端末２宛へのデータ転送だけは継続するというシステムも考えられる。その場合、転送されるデータの返信必要フラグはクリアされ、親端末２についても返信は行わないよう、何らかの通知手段を設ける必要がある。
【００８２】
また、親端末の数が複数ある場合も、本発明の第１実施例を拡張することで対応が可能である。ただし、この場合はどの親端末との通信であるかを仮ルーティングテーブル内で監理し、その情報も利用して仮ルーティングテーブル内の制御を行う必要がある。
【図面の簡単な説明】
【００８３】
【図１】本発明に係るマルチホップネットワークで用いられる端末の一例の構成図である。
【図２】本発明に係るマルチホップネットワークシステムにおいて子端末１から親端末２へデータを送信する場合の動作の一例を示す模式図である。
【図３】子端末１の動作の一例を示すフローチャートである。
【図４】中継端末Ｎの動作の一例を示すフローチャートである。
【図５】本発明に係るマルチホップネットワークシステムにおいて親端末２から子端末１へ返信を送信する場合の動作の一例を示す模式図である。
【図６】親端末２の動作の一例を示すフローチャートである。
【図７】中継端末Ｎの動作の一例を示すフローチャートである。
【図８】本発明に係るマルチホップネットワークシステムにおいて、中継端末Ｎにおいて仮ルーティングテーブルへの書き込みがメモリ制約等により失敗した場合の動作の一例を示すフローチャートである。
【図９】本発明に係るマルチホップネットワークシステムの第２実施例の構成図である。
【図１０】本発明に係るマルチホップネットワークシステムの第３実施例の構成図である。
【符号の説明】
【００８４】
１  子端末
２  親端末
１１〜１４  中継端末
２１  処理サーバ
２２  処理サーバ
３０  無線センサー子端末
３１  移動体
３２  中継端末
５０  端末
５１  送信部
５２  受信部
５７  プログラム格納メモリ
５８  ルーティングテーブル格納メモリ
５９  制御部
１００  送信データ
１０１  通信ヘッダ部
１０２  アプリケーションデータ部
１０３  返信必要フラグ
【図１】
0004407658.tif 000002
【図２】
0004407658.tif 000003
【図３】
0004407658.tif 000004
【図４】
0004407658.tif 000005
【図５】
0004407658.tif 000006
【図６】
0004407658.tif 000007
【図７】
0004407658.tif 000008
【図８】
0004407658.tif 000009
【図９】
0004407658.tif 000010
【図１０】
0004407658.tif 000011