JP2006050371A - アドホックネットワークにおけるデータ送信方法 - Google Patents

Abstract

【課題】 アドホックネットワークのように各端末が送信端末、受信端末、中継端末になり得るネットワークシステムにおいて、端末のリソースを有効に利用できるデータ送信方法を提供することにある。
【解決手段】 複数の端末がマルチホップ接続されたネットワークシステムにおいて、第１端末から第２端末に、少なくとも１つの他の端末をデータ中継端末として、データ送信する第１ステップと、上記データ中継端末から第１端末に、中継データの送信量を制御するための制御メッセージを送信する第２ステップと、第１端末が、上記制御メッセージの内容に従って、第２端末宛のデータの送信モードを変更する第３ステップとからなることを特徴とするデータ送信方法。
【選択図】 図６

Description

本発明は、例えば、ワークステーション、パーソナルコンピュータ、ハンドヘルドコンピュータ、携帯電話、小型センサなどの複数の情報処理端末が、有線または無線よって接続されたマルチホップネットワークにおけるデータ転送方法に関し、特に、複数の情報処理端末が周囲の状況に応じて動的に接続されるアドホックネットワークにおける大容量ストリーミングデータの送信に適したデータ送信方法に関するものである。

近年、携帯電話、PDA、カーナビゲーションシステムなど、小型の情報処理端末が普及している。また、これらの情報処理端末を随時に接続し、互いに連携動作させるための通信ネットワーク技術として、アドホックネットワークが注目されつつある。アドホックネットワークは、複数の端末にバケツリレー形式でパケットを中継させることにより、基地局やネットワークへのアクセスポイントとなるサーバ等の通信インフラストラクチャーを使用することなく、端末間を相互接続する通信方式である。

アドホックネットワークに適したアプリケーションとして、例えば、映像監視システムや音声通話システムなどがある。図１は、アドホックネットワークを用いた映像監視システムの１例を示す。

ここに示した映像監視システムは、無線回線で接続された複数のカメラ付端末１０１（１０１−１〜１０１−９）と、モニタ端末１０２とからなる。監視範囲の周辺に位置したカメラ付端末１０１−１からの出力映像は、カメラ付端末１０１−５〜１０１−７を中継端末として、モニタ端末１０２に送信される。同様に、カメラ付端末１０１−２からの出力映像は、カメラ付端末１０１−８、１０１−６、１０１−７を中継端末として、モニタ端末１０２に送信され、カメラ付端末１０１−３からの出力映像は、カメラ付端末１０１−９と１０１−７を中継端末、カメラ付端末１０１−４からの出力映像は、カメラ付端末１０１−７を中継端末として、それぞれモニタ端末１０２に送信される。即ち、モニタ端末１０２は、無線マルチホップネットワークを介して、複数のカメラ付端末と接続されている。

モニタ端末１０２では、カメラ付端末から送信された映像データを受信し、ディスプレイ１０３に複数サイトの画像の一覧できるように表示したり、特定サイトの画像のみを選択的に表示したりすることができる。この方式によれば、中継端末１０１−５〜１０１−９を経由して、モニタ端末１０２とカメラ付端末１０１−１〜１０１−４をマルチホップ接続することにより、モニタ端末１０２が、無線電波が直接届かない離間した位置にある端末からの映像を受信可能となるため、監視対象地域に複数のカメラ付端末を配置するだけで、容易に映像監視システムを構築することができる。

上述したアドホックネットワークでは、データの送信元端末（上記例ではカメラ付端末）と宛先端末（モニタ端末）との間に介在する中継端末の台数（ホップ数）や中継区間で発生する無線ノイズ等に応じて、データの伝送遅延時間やスループットにばらつきが発生するという問題がある。例えば、モニタ端末１０２から最も離間した位置にあるカメラ付端末１０１−１からの画像データは、比較的近い位置にあるカメラ付端末１０１−４からの画像データよりも、経由する中継端末の台数が多くなっているため、遅延時間が大きく、且つ、スループットも低下する。そのため、モニタ端末１０２のディスプレイ１０３に複数サイトの映像を一覧表示した場合、カメラ付端末１０１−１からの映像が、他のサイトの映像よりも時間的に遅れて表示されたり、中継区間でのスループットの低下によって、表示フレームに欠落が発生する可能性が大となる。即ち、アドホックネットワークを利用してストリーミングデータのような大容量のデータを送信する場合、限られたネットワーク帯域を効率的に利用するためのＱｏＳ制御が重要な課題となる。

この問題を解決するために、例えば、特開２００３−２７３７８８号公報（特許文献１）では、ホップ数の大きい通信区間の送信パケットを複数パケットに分割して送信したり、高い優先度で中継処理することを提案している。また、ストリーミングデータの品質調整が可能な伝送プロトコルとして、ＲＴＰ（Real-time Transport Protocol）がある。ＲＴＰについては、RFC1889の「RTP: A Transport Protocol for Real-Time Applications」、http://www.ietf.org/rfc/rfc1889.txt（第３−５頁）（非特許文献１）に記載されている。ＲＴＰでは、各送信パケットに付加されたタイムスタンプ情報やシーケンス番号に基づいて遅延時間を検出し、これをＲＴＣＰ（RTP Control Protocol）によってデータ送信元サーバに報告し、サーバがパケットの通信状態に応じて送信データの優先度指定値を調節することによって、伝送遅延を軽減できるようにしている。

特開２００３−２７３７８８号公報（第５−６頁、第１−２図） 「RTP: A Transport Protocol for Real-Time Applications」、RFC1889、http:// www.ietf.org/rfc/rfc1889.txt（第３−５頁）

無線アドホックネットワークにおいては、各中継端末は、他の端末からの送信データを宛先端末に転送する動作の他に、中継端末自身が送信元となってデータを送信したり、端末独自のアプリケーション処理を実行する可能性がある。図１に示したネットワーク構成において、例えば、中継端末１０１−６は、カメラ付端末１０１−１と１０１−２からの送信データを別の中継端末１０１−７に転送する動作と並行して、自分がカメラで撮影した映像データの録画、あるいは他の端末への送信のためのデータ処理を実行する場合がある。

ここで、中継端末１０１−６は、端末１０１−１や１０１−２で発生した送信データの転送によって無線通信帯域の多くが消費されていた場合、自分がカメラで撮影した映像データを送信しようとしても、必要な帯域を確保できないという問題が発生する。また、他の端末からの受信データの転送処理によって、端末ハードウェアリソース、例えば、ＣＰＵの処理能力やメモリ容量が消費され、自分自身のためのアプリケーションの実行に必要なＣＰＵ処理や空きメモリが不足するという問題が発生する。

上記特許文献１や非特許文献１の方法は、宛先装置での受信データの品質を確保するために、送信端末のデータ送信タイミングを指定したり、中継端末におけるパケット転送順序を変更するものであり、中継端末自身が必要とするリソースを随時に確保可能とするものではない。従って、無線アドホックネットワークでは、各中継端末にとっては、他端末から利用されるだけで自端末の処理が満足に実行できないという問題があり、送信端末にとっては、中継端末が独自の端末動作を実行し始めると中継区間のデータスループットが変動するという問題があった。

本発明の目的は、アドホックネットワークのように各端末が送信端末、受信端末、中継端末になり得るネットワークシステムにおいて、端末のリソースを有効に利用できるデータ送信方法を提供することにある。
本発明の他の目的は、複数の端末がマルチホップ接続されたアドホックネットワークにおいて、特に動画や音声などの大容量のデータを送信するときに、中継端末の状態に応じて、中継データの量を制御することにより、中継端末のリソースを有効利用できるようにしたデータ送信方法を提供することにある。

上記目的を達成するために、本発明は、複数の端末がマルチホップ接続されたネットワークシステムにおけるデータ送信方法において、第１端末から第２端末に、少なくとも１つの他の端末をデータ中継端末として、データ送信する第１ステップと、上記データ中継端末から第１端末に、中継データの送信量を制御するための制御メッセージを送信する第２ステップと、第１端末が、上記制御メッセージの内容に従って、第２端末宛のデータの送信モードを変更する第３ステップとからなることを特徴とする。

本発明の１実施例では、データ中継端末が、データ処理種別と所要リソース量と送信データ抑制内容との関係を定義した管理テーブルを有し、現在の空きリソース量が、実行しようとするデータ処理の種別と対応して上記管理テーブルが示す所要リソース量に満たない時、上記管理テーブルが示す送信データ抑制内容に従って生成した制御メッセージを第１端末に送信する。

本発明において、データ中継端末は、例えば、該端末で実行するデータ処理に要するリソースに不足が生じた時、上記制御メッセージを送信する。但し、データ中継端末から第１端末に、該データ中継端末のリソースの状態を示す制御メッセージを定期的に送信しておき、第１端末が、上記制御メッセージの内容に従って、第２端末宛のデータ送信モードを変更するようにしてもよい。また、データ中継端末から第２端末に、該データ中継端末のリソースの状態を示す制御メッセージを定期的に送信しておき、第２端末が、上記制御メッセージの内容に従って、第１端末から該第２端末宛の送信データ量を制御するようにしてもよい。この場合、第２端末は、例えば、第１端末からのデータの取得間隔を変更することによって、データ中継端末を経由するデータ量を制御できる。

本発明によれば、アドホックネットワークにおける端末リソースが、他端末からの送信データの中継サービスのために消費され、該端末自身のデータ処理を実行する時、ＣＰＵ能力、メモリ容量、ネットワーク帯域などのリソースが不足して、満足な動作を実行できないという不都合を解決できる。また、データ送信端末またはデータ受信端末として動作中の端末にとっては、通信中に中継端末が何の前触れも無く独自のデータ処理を開始したため、通信データの転送処理が急に遅くなるといった問題の発生を回避して、通信環境に適合したデータ通信ができるという利点がある。

以下、本発明の実施例について図面を参照して説明する。
図２は、本発明のアドホックネットワークの構成要素となる情報処理端末のブロック構成図を示す。図２（Ａ）は、データ送信元となる情報処理端末１０１−Ｔｘ、図２（Ｂ）は、中継端末となる情報処理端末１０１−Ｒ、図２（Ｃ）は、データ受信端末となる情報処理端末１０２の構成を示している。これらの情報処理端末としては、例えば、ワークステーション、パーソナルコンピュータ、ハンドヘルドコンピュータ、携帯電話、小型センサなどが適用される。これら情報処理端末（以下、単に端末と言う）は、有線チャネル、無線チャネル、あるいはこれらのチャネルが混在したアドホックネットワークを介して、マルチホップ接続されている。

データ送信元端末１０１−Ｔｘは、図１のネットワークシステムにおけるカメラ付端末１０１−１〜１０１−４のうちの１つに対応し、中継端末１０１−Ｒは、図１の中継端末１０１−５〜１０１−９のうちの１つに対応する。端末１０１−Ｔｘ、１０１−Ｒ、１０２は、それぞれプロセッサ１１０と、カメラやマイクなどの入力装置１１１と、ディスプレイやＬＥＤなどの表示装置１１２と、無線ＬＡＮなどのネットワークに接続するための通信インタフェース１１３と、プログラムメモリ１１４と、データメモリ１１５からなり、これらの要素はバス１１６によって相互接続されている。

中継端末１０１−Ｒは、状況によっては、データ送信元端末１０１−Ｔｘとして機能する。また、データ送信元端末１０１−Ｔｘも、状況によっては、中継端末１０１−Ｒとして機能する。従って、実際の応用において、各端末は、データ送信元端末１０１−Ｔｘと中継端末１０１−Ｒの両方の機能を備えたものとして提供されるが、ここでは、発明の理解を容易にするため、図２（Ａ）には、データ送信元端末１０１−Ｔｘとして必要な機能を示し、図２（Ｂ）には、中継端末１０１−Ｒとして必要な機能を示してある。但し、送信端末１０１−Ｔｘと中継端末１０１−Ｒにとって、表示装置１１２は必須の構成要件ではない。

本実施例では、中継端末１０１−Ｒのデータメモリ１１５には、自端末から特定の端末までのネットワーク経路を示す経路情報テーブル３００と、中継サービス中のデータパケットの送信元と宛先との関係を示す中継管理テーブル３１０と、リソースが不足した時、中継サービス中のデータの送信端末に対して送信すべき送信データ抑制要求メッセージの発行条件を示す送信抑制要求条件テーブル３２０が格納されている。また、中継端末１０１−Ｒのプログラムメモリ１１４には、近隣に存在する端末群を検出して経路情報テーブル２３１を更新するための経路管理ルーチン２００と、経路情報テーブル３００に従って受信パケットを適切な他の端末に転送するデータ転送ルーチン２２０と、中継管理テーブル２３２を更新するための中継管理ルーチン２４０と、入力装置１１１からの入力データを他の特定端末に送信するためのデータ送信ルーチン２６０が用意されている。

送信端末１０１−Ｔｘのデータメモリ１１５には、経路情報テーブル３００と、中継端末からの送信データ抑制要求に応じて更新される送信モードテーブル３３０が格納されている。また、送信端末１０１−Ｔｘのプログラムメモリ１１４には、経路管理ルーチン２００と、データ送信ルーチン２６０が用意されている。

受信端末１０２のデータメモリ１１５には、経路情報テーブル３００が格納され、プログラムメモリ１１４には、経路管理ルーチン２００と、他端末からの受信データを表示装置１１２に出力するためのデータ受信／表示ルーチン２８０が用意されている。

図３は、中継管理テーブル３１０の１実施例を示す。
中継管理テーブル３１０には、中継端末１０１−Ｒが中継サービスを適用中のデータパケットの送信元ＩＰアドレス３１１と、宛先ＩＰアドレス３１２と、最後の中継パケットの処理時刻（最終サービス時刻）３１３との関係を示す複数のエントリ３１−１、３１−２、…が登録されている。

図４は、送信抑制要求条件テーブル３２０の１実施例を示す。
送信抑制要求条件テーブル３２０は、アプリケーション種別３２１と対応して用意された複数のエントリ３２−１、３２−２、３２−３、…からなり、各エントリは、アプリケーション種別３２１で指定されたアプリケーションプログラムの実行時に必要となるリソース量３２２と、リソース量３２２で指定されたリソースを確保できない場合に、中継サービス中のデータ（パケット）の送信元端末に対して送信すべき送信データ抑制要求の内容３２３を示している。送信データ抑制要求は、実行すべきアプリケーションの種別によって異なっており、例えば、映像配信や音声配信のように、リアルタイム情報を扱うアプリケーションの実行時にリソース不足が発生した場合は、中継パケットの送信元に対して、データ送信の中止や送信データ量の削減を求め、テキストデータを扱うアプリケーションの実行時にリソース不足が発生した場合は、中継パケットの送信元に、送信データの優先度ダウンを求める内容となっている。

図５は、送信モードテーブル３３０の１実施例を示す。
送信モードテーブル３３０は、データ送信端末１０１−Ｔｘにおいて実行されるアプリケーションの種別３３１と対応して、中継端末から受ける送信データ抑制要求の内容３３２と、送信データ抑制のためにデータ送信端末で実行すべき送信動作モード３３３とを示す複数のエントリ３３−１、３３−２、…からなっている。

尚、経路情報テーブル３００は、受信パケットの宛先アドレスと次ホップ先との関係を示しており、その内容は経路管理ルーチン２００によって管理されている。経路管理ルーチン２００は、例えば、ＡＯＤＶ（Ad hoc On-Demand Distance Vector）やＯＬＳＲ（Optimized Link State Routing）などのプロトコルを実装したアドホックルーティングソフトにより構成される。また、データ転送ルーチン２２０は、ＯＳのＩＰルーティング機能により、データ受信／表示ルーチン２８０は、Microsoft社のWindows Media Playerなどのクライアントソフトにより構成される。

図６は、本発明によるアドホックネットワークシステムの全体的な動作シーケンスを示す。ここでは、端末装置Ｄと端末装置Ｅが送信端末となって、中継端末Ｃを経由して、受信端末Ａにデータを送信している（Ｓ１）。この状態で、中継端末Ｃにデータ送信要求が発生し（Ｓ２）、中継端末Ｃから受信端末Ｂ宛にデータ送信を開始する必要に迫られた場合、本発明では、中継端末Ｃのデータ送信ルーチン２６０が、空き状態にあるリソースの量をチェックし、もし、データ送信に必要な量の空きリソースがないと判った時、中継サービス中のデータの送信端末（ここでは、送信端末ＤとＥ）に対して、送信データ抑制要求メッセージを発行する（Ｓ３）。

送信端末Ｄ、Ｅは、中継端末Ｃから送信データ抑制要求メッセージを受信すると、受信メッセージが示す要求内容に従って、受信端末Ａ宛の送信データ量を削減する（Ｓ４）。中継端末Ｃは、送信端末Ｄ、Ｅからの送信データ量の削減によって、受信端末Ｂ宛のデータ送信に必要なリソースを確保できた状態で、データ送信を開始する（Ｓ５）。尚、中継端末Ｃから受信端末Ｂ宛のデータ送信は、送信データ抑制要求メッセージに対する送信端末Ｄ、Ｅからの応答メッセージの受信を待って、開始するようにしても良い。

図７は、中継端末１０１−Ｒ（図６の中継端末Ｃ）が実行する中継管理ルーチン２４０の１実施例を示すフローチャートである。
中継管理ルーチン２４０では、一定時間Ｔ０の経過を知らせるタイマを起動する（ステップ２４１）。このタイマは、後述するように、中継管理テーブル３１０の登録エントリのうち、最終サービス時刻から所定時間が経過した不要エントリを削除するために利用される。中継管理ルーチン２４０では、次に、ユーザ操作によるプログラム終了指示の有無を判定し（２４２）、終了指示を受けていた場合は、該ルーチンを終了する。終了指示がなければ、上記タイマがタイムアウトとなったか否かをチェックし（ステップ２４３）、タイムアウトとなっていなければ、中継サービスすべきパケットの捕捉（キャプチャリング）を行う（２４４）。中継パケットがなければ、ステップ２４２に戻って、上述した処理を繰り返す。

中継サービスすべきパケットを捕捉した場合は、捕捉パケットを中継処理すると共に、ＩＰヘッダから送信元ＩＰアドレスと宛先ＩＰアドレスを抽出する（２４５）。この後、中継管理テーブル３１０を参照し、送信元ＩＰアドレス３１１と宛先ＩＰアドレス３１２との関係が中継パケットの送信元ＩＰアドレスと宛先ＩＰアドレスの組合せに該当するエントリの有無をチェックする（２４６）。上記ＩＰアドレスの組合せに該当するエントリが中継管理テーブル３１０に登録済みの場合は、該当エントリの最終サービス時刻３１３を現在時刻に更新して（２４８）、ステップ２４２に戻り、未登録の場合は、上記ＩＰアドレスの組合せをもつ新たなエントリを中継管理テーブルに追加（２４７）した後、ステップ２４８を実行する。

ステップ２４３でタイマがタイムアウトとなった場合は、中継管理テーブル３１０の最終サービス時刻３１３をチェックし、最終サービス時刻３１３から所定時間Ｔ１（Ｔ１＞Ｔ０）が経過したエントリを見つける（２４９）。最終サービス時刻３１３から所定時間Ｔ１が経過したエントリがなければ、ステップ４０１に戻り、所定時間Ｔ１が経過したエントリについては、中継サービスすべきパケットの送信が終了したものと判断して、中継管理テーブル３１０から削除（２５０）した後、ステップ４０１に戻る。尚、パケットキャプチャリングは、Etherealなどのソフトウェアによって実現される。

図８は、送信端末１０１−Ｔｘ（図６の端末Ｄ、Ｅ）および中継端末１０１−Ｒ（図６の端末Ｃ）で実行されるデータ送信ルーチン２２０の１実施例を示すフローチャートである。
データ送信ルーチン２２０では、ユーザ操作等に伴って発生するデータ送信要求を待っており（ステップ２６１）、データ送信要求を受信すると、図３に示した中継管理テーブル３１０の登録エントリの有無によって、自端末が中継端末として動作中か否か、すなわち、データ中継サービスを実行中が否かを判定する（２６２）。中継管理テーブル３１０に有効エントリが未登録となっている（図２（Ａ）では、中継管理テーブル３１０そのものを省略してある）送信端末１０１−Ｔｘの場合、空きリソース量に関係なく、直ちにデータ送信を開始する（２６７）。

中継端末１０１−Ｒの場合は、先ず、自端末における現在の空きリソース量を把握する（２６３）。空きリソース量は、例えば、Linuxの場合、topモジュールによってＣＰＵの使用率やメモリの消費量を把握でき、iftopモジュールによって通信インタフェース毎の帯域使用量を把握できる。次に、図４に示した送信抑制要求条件テーブル２３３から、上記データ送信の要求元となっているアプリケーション種別と対応したエントリを検索し、現在の空きリソース量が上記検索エントリが示す必要リソース量３２２を満たしているか否かを判定する（２６４）。空きリソース量が十分の場合は、直ちにデータ送信を開始する（２６７）。空きリソース量が不足していた場合は、中継管理テーブル３１０から現在中継サービス中のデータの送信端末ＩＰアドレス３１１を取得し（２６５）、送信抑制要求条件テーブル２３３から検索したエントリが示す要求内容３２３に従って、送信データ抑制要求メッセージを生成し、これを各送信端末宛に送信し（２６６）、その後でデータ送信を開始する（２６７）。但し、前述したように、各送信端末からの応答メッセージの受信を待って、データ送信を開始するようにしてもよい。

送信データ抑制要求メッセージは、例えば、図９に示すように、ＩＰヘッダ４０１、ＴＣＰ／ＵＤＰヘッダ４０２、メッセージ種別４０３、該メッセージの送信時刻４０４、要求内容４０５からなる。メッセージ種別４０３には、このメッセージが送信データ抑制要求であることを示すコードが設定され、要求内容４０５には、送信抑制要求条件テーブル２３３から検索した要求内容３２３を示すコード情報が設定される。但し、要求内容３２３をメッセージ種別４０３に設定し、送信データ抑制要求メッセージの要求内容４０５には、削減すべき具体的なデータ量を設定するようにしてもよい。

図８に戻って、データ送信ルーチン２２０では、データ送信を開始（２６７）した後、データ送信の終了指示があったか否かを判断する（２６８）。データ送信の終了指示は、例えば、ユーザ操作等によるアプリケーションプログラムの終了に伴って発生される。終了指示があった場合は、ステップ２６２と同様に、自端末が中継端末として動作中か否かを判定し（２７１）、中継端末として動作中でなければ、このルーチンを終了する。自端末が中継端末として動作中の場合、中継管理テーブル３１０から現在中継サービス中のデータの送信端末ＩＰアドレス３１１を取得し（２７２）、各送信端末宛に送信データ抑制解除メッセージを送信して（２７３）、このルーチンを終了する。

終了指示がなかった場合、他の中継端末からの送信データ抑制制御メッセージ（送信データ抑制要求メッセージまたは送信データ抑制解除メッセージ）の受信の有無を判定する（２６９）。送信データ抑制制御メッセージの受信がなければ、ステップ２６８に戻る。送信データ抑制要求メッセージを受信していた場合は、送信モードテーブル３３０から、送信データの発生元となっているアプリケーション種別と、受信した送信データ抑制要求メッセージが示す要求内容に応じて、変更後の送信動作モード３３３を特定し、該送信動作モードに従って送信データを抑制し、送信データ抑制解除メッセージを受信した場合は、送信データの抑制を解除して、元の送信動作モードに戻す（２７０）。

図５に示した送信モードテーブル３３０では、例えば、エントリ３３−２、３３−３の送信抑制要求３３２：「送信データ量の２０％未満の削減」、「送信データ量の２０％以上の削減」が示すように、映像配信アプリケーションを実行中に受信する送信データ抑制要求メッセージで具体的な送信データ削減目標値が示されることを前提として、送信端末がとるべき送信動作変更モード３３３が定義されている。すなわち、送信データ抑制要求メッセージで、例えば、「送信データ量0.3 Mbps削減」と指定された時、送信端末で実行中の映像配信アプリケーションが３Mbpsのデータを送信中であれば、送信データの削減量を１０％と計算して、結果的にエントリ３３−２の送信動作変更モード３３３に従って、データ圧縮方式を「Ｃｏｄｅｃ Ａ」に変更するようにしている。

ここで、送信データ抑制要求メッセージの送信元となる中継端末では、データ送信端末に要求すべき送信データの削減量の決定方法として、幾つかの方法が考えられる。例えば、ＣＰＵ使用量は中継パケット数に略比例しているため、不足するリソースがＣＰＵの処理能力の場合、自端末で必要とするＣＰＵ処理能力を確保するためには、中継パケットの量をどの程度削減すれば良いかが判断できる。従って、削減すべきパケット量から、データ送信端末に要求すべき送信データの削減量を算出できる。

中継データの送信元が複数端末の場合、送信データの削減量を複数の送信端末で分担させるようにしても良い。例えば、中継データの送信元となる端末が３台で、削減すべきネットワーク帯域が３Mbpsの場合、各送信端末に対して１Mbpsずつ送信データの削減を要求すればよい。送信データの削減は、複数の送信端末に対して異なる比率で不均等に割り当てるようにしてもよい。削減量の割り当ては、現在の送信データ量に比例させてもよいし、結果的に中継端末側の所要リソースを確保できるように、送信端末とのネゴシエーションによって配分を決定するようにしてもよい。

送信データ抑制のための送信動作モードとしては、上述した送信データ量の削減以外に、例えば、送信モードテーブル３３０のエントリ３３−１が示すように、経由すべき中継端末を別端末に変更する経路変更や、エントリ３３−５が示すように、中継端末におけるパケット転送優先順位を下げるためのＩＰパケットＴｏｓフィールド値の変更等がある。
以上の実施例では、データ中継サービス中の端末が、自端末のデータ送信を開始する時、確保すべき空きリソースが不足していた場合に、中継データの送信元となる各端末に対して、送信データ抑制を要求する例について説明したが、送信データ抑制要求の発行は、中継端末で実行するアプリケーションがデータ送信を伴うものとは限らない。

本発明の目的を達成するためには、例えば、各中継端末が、自端末のリソースの状態を示す制御メッセージを中継データの送信元となる各端末に定期的に送信し、各送信端末が、上記制御メッセージが示す中継端末の状態に応じて、自主的に送信データ量を制御するようにしてもよい。また、各中継端末が、自端末のリソースの状態を示す制御メッセージを中継データの宛先となる受信端末に定期的に送信し、受信端末が、上記制御メッセージが示す中継端末の状態に応じて、データ送信端末からの取得データ量を制御するようにしてもよい。例えば、受信端末が、送信端末をポーリングすることによってデータを取得している場合、ポーリング間隔を動的に変更することによって、中継端末のリソースの消費量を調整することが可能となる。

また、実施例では、中継管理ルーチン２４０において、中継パケットのキャプチャリングによってデータ送信端末を認識する例について説明した。例えばＤＳＲ（Dynamic Source Routing）プロトコルを採用したアドホックネットワーク上では、Route RequestメッセージやRoute Replyメッセージに経路情報が含まれるため、これらのメッセージから中継データの送信元端末を認識するようにしてもよい。

本発明が適用されるアドホックネットワークの１例を示す図。 本発明のアドホックネットワークの構成要素となる情報処理端末のブロック構成図。 中継管理テーブル３１０の１実施例を示す図。 送信抑制要求条件テーブル３２０の１実施例を示す図。 送信モードテーブル３３０の１実施例を示す図。 本発明のアドホックネットワークシステムの全体的な動作シーケンスを示す図。 中継管理ルーチン２４０の１実施例を示すフローチャート。 データ送信ルーチン２６０の１実施例を示すフローチャート。 送信データ抑制要求メッセージのフォーマットを示す図。

符号の説明

１０１：カメラ付端末、１０２：モニタ端末、１０３：ディスプレイ、
１１０：プロセッサ、１１１：入力装置、１１２：表示装置、
１１３：通信インタフェース、１１４：プログラムメモリ、１１５：データメモリ、
１１６：バス、２００：経路管理ルーチン、２２０：データ転送ルーチン、
２４０：中継管理ルーチン、２６０：データ送信ルーチン、
２８０：データ受信／表示ルーチン、３００：経路情報テーブル、
３１０：中継管理テーブル、３２０：送信抑制要求条件テーブル、
３３０：送信モードテーブル。

Claims (7)

1. 複数の端末がマルチホップ接続されたネットワークシステムにおけるデータ送信方法において、
   第１端末から第２端末に、少なくとも１つの他の端末をデータ中継端末として、データ送信する第１ステップと、
   上記データ中継端末から上記第１端末に、中継データの送信量を制御するための制御メッセージを送信する第２ステップと、
   上記第１端末が、上記制御メッセージの内容に従って、上記第２端末宛のデータの送信モードを変更する第３ステップとからなることを特徴とするデータ送信方法。
2. 前記データ中継端末が、該端末で実行するデータ処理に要するリソースに不足が生じた時、前記制御メッセージを送信することを特徴とする請求項１に記載のデータ送信方法。
3. 前記データ中継端末が、データ処理種別と所要リソース量と送信データ抑制内容との関係を定義した管理テーブルを有し、現在の空きリソース量が、実行しようとするデータ処理の種別と対応して上記管理テーブルが示す所要リソース量に満たない時、上記管理テーブルが示す送信データ抑制内容に従って生成した制御メッセージを前記第１端末に送信することを特徴とする請求項１に記載のデータ送信方法。
4. 複数の端末がマルチホップ接続されたネットワークシステムにおけるデータ送信方法において、
   第１端末から第２端末に、少なくとも第３端末をデータ中継端末として、データ送信する第１ステップと、
   少なくとも上記第３端末をデータ中継端末として、第４端末から上記第２端末または他の端末にデータ送信する第２ステップと、
   上記第３端末から上記第１、第４端末に、中継データの送信量を制御するための制御メッセージを送信する第３ステップと、
   上記第１、第４端末が、上記制御メッセージの内容に従って、それぞれのデータ送信モードを変更する第４ステップとからなることを特徴とするデータ送信方法。
5. 複数の端末がマルチホップ接続されたネットワークシステムにおけるデータ送信方法において、
   第１端末から第２端末に、少なくとも１つの他の端末をデータ中継端末として、データ送信する第１ステップと、
   上記データ中継端末から上記第１端末に、該データ中継端末のリソースの状態を示す制御メッセージを定期的に送信する第２ステップと、
   上記第１端末が、上記制御メッセージの内容に従って、上記第２端末宛のデータ送信モードを変更する第３ステップとからなることを特徴とするデータ送信方法。
6. 複数の端末がマルチホップ接続されたネットワークシステムにおけるデータ送信方法において、
   第１端末から第２端末に、少なくとも１つの他の端末をデータ中継端末として、データ送信する第１ステップと、
   上記データ中継端末から上記第２端末に、該データ中継端末のリソースの状態を示す制御メッセージを定期的に送信する第２ステップと、
   上記第２端末が、上記制御メッセージの内容に従って、上記第１端末から該第２端末宛の送信データ量を制御する第３ステップとからなることを特徴とするデータ送信方法。
7. 前記第２端末が、前記制御メッセージの内容に従って、前記第１端末からのデータの取得間隔を制御する第３ステップとからなることを特徴とする請求項６に記載のデータ送信方法。

Images