(57)【特許請求の範囲】
【請求項１】
アドホックネットワークとの無線通信を無線端末に実行させるプログラムであって，
当該無線端末は，自身が無線プローブ要求を送信する対象となる登録された無線端末に関する無線端末指定情報を含んだ無線通信品質テーブルを備えており，
前記アドホックネットワークに属する他の無線端末のうち，前記無線通信品質テーブルに登録された無線端末に対してのみ，任意のタイミングで無線プローブ要求を送信する第１のステップと，
無線端末から無線プローブ応答を受信する第２のステップと，
前記無線プローブ応答に含まれる無線端末の識別情報が，登録された無線端末に関する識別情報と一致するときのみ，受信時の電波信号強度を取得し，前記無線プローブ応答を送信した無線端末の識別情報と前記電波信号強度とを関連付けて通信品質テーブルに登録する第３のステップと，
前記通信品質テーブルに登録された情報を参照する第４のステップと
を無線端末に実行させるプログラム。
【請求項２】
前記通信品質テーブルに登録された無線端末から無線プローブ応答を受信しなかった場合，当該受信しなかった旨を前記通信品質テーブルに登録するステップを無線端末にさらに実行させる請求項１に記載のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、無線ＬＡＮシステムに関し、特にアドホックネットワークにおいて通信先端末との通信状況をリアルタイムに把握する技術に関する。
【背景技術】
【０００２】
近年、ＩＥＥＥ８０２．１１規格に基づく無線ＬＡＮシステムが広く普及している。無線ＬＡＮシステムには、アクセスポイントを経由して機器同士もしくは有線ＬＡＮ上の機器と通信を行うインフラストラクチャネットワークと、アクセスポイントを介さず、無線端末同士で直接通信を行うアドホックネットワークがある。アドホックネットワークでは、無線通信機能を有した無線端末同士が、必要に応じて相互接続し、無線ＬＡＮシステムを形成する。
【０００３】
インフラストラクチャネットワークの場合、アクセスポイントを経由して通信が行われるので、アクセスポイントと各無線端末との間の通信品質（電波状況など）は、アクセスポイントが一元的に管理することができる。
【０００４】
一方、アドホックネットワークの場合、アクセスポイントのように通信を集中的に管理する機器が存在しないので、アドホックネットワークを構成する個々の無線端末は、通信先端末との通信品質をリアルタイムに把握することはせず、何らかの通信（ＩＥＥＥ８０２．１１規格に基づくデータフレームを使った通信）を行い、その応答がないことで、通信品質の劣化を確認していた。すなわち、従来のアドホックネットワークにおいて無線端末は、その通信先端末との通信品質を個別に知ることができなかった（非特許文献１参照）。
【０００５】
【非特許文献１】ＩＥＥＥ、「ANSI/IEEE Std 802.11, 1998 Edition」、１９９８年
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、他の無線通信先端末の電波状況を個別に知ることができず、また、何らかの通信を行い応答のないことで通信品質の劣化を確認するという従来の方法では、アドホックネットワークにおいて、無線端末が無線通信先端末との通信品質の変化に応じた処理を迅速に行えないという問題がある。
【０００７】
例えば、図６のように、無線端末５０ａが複数の無線端末と通信を確立している状況において、例えば、距離が離れた若しくは遮蔽物により通信が阻害された等の理由により、無線端末５０ｄとの通信品質が劣化した場合であっても、無線端末５０ａは、即座にその情報を取得することができない。この場合、無線端末５０ａの利用者は、無線端末５０ｄを利用する（例えば無線端末５０ｄにデータを送信する）段階になって初めて、通信できないことを知る。また、無線端末５０ｄ以外の無線端末（５０ｂまたは５０ｃ）との通信品質が良好の場合、無線端末５０ａの表示部には、所属無線ネットワークの通信品質が良好である旨の表示がされる可能性があり、この場合、通信品質良好と表示されているにもかかわらず、無線基地局５０ｄとの通信ができないということになり、利用者を困惑させることになる。
【０００８】
本発明は、上記の問題に鑑みてなされたものであり、その目的とするところは、アドホックネットワークにおいて、無線端末がその通信先端末との通信品質をリアルタイムに確認することにある。
【課題を解決するための手段】
【０００９】
第１の発明は、アドホックネットワークと無線で通信するプログラムであって、前記アドホックネットワークに属する他の無線端末に対して任意のタイミングで無線プローブ要求を送信する第１のステップと、前記他の無線端末から無線プローブ応答を受信する第２のステップと、前記無線プローブ応答を受信した場合、受信時の電波信号強度を取得し、前記無線プローブ応答を送信した前記他の無線端末の識別情報と前記電波信号強度とを関連づけて通信品質テーブルに登録する第３のステップと、前記通信品質テーブルに登録された情報を参照する第４のステップとを無線端末に実行させることを特徴とする。
【００１０】
第２の発明は、第１の発明に記載のプログラムであって、前記通信品質テーブルは、無線プローブ要求を送信するタイミングを指定する送信タイミング情報を含み、前記第１のステップは、前記送信タイミング情報に従って無線プローブ要求を送信することを特徴とする。
【００１１】
第３の発明は、第１または第２の発明に記載のプログラムであって、前記通信品質テーブルは、無線プローブ要求の送信対象となる無線端末を指定する無線端末指定情報を含み、前記第１のステップは、前記他の無線端末のうち、前記無線端末指定情報で指定された無線端末に対してのみ無線プローブ要求を送信し、前記第３のステップは、無線プローブ応答を受信した場合、前記無線端末指定情報で指定された無線端末からの無線プローブ応答であるときのみ、受信時の電波信号強度と前記無線端末指定情報とを関連づけて前記通信品質テーブルに登録することを特徴とする。
【００１２】
第４の発明は、第１乃至第３の発明のいずれかに記載のプログラムであって、前記通信品質テーブルに登録された無線端末から無線プローブ応答を受信しなかった場合、当該受信しなかった旨を前記通信品質テーブルに登録するステップを無線端末にさらに実行させることを特徴とする。
【発明の効果】
【００１３】
本発明によれば、無線端末が通信先の無線端末に対して、定期的に、Ｐｒｏｂｅ通信を行うことにより、通信先の無線端末との通信品質をリアルタイムに把握することができるので、アプリケーションや上位レイヤプログラムは、通信先の無線端末との通信品質に応じた制御を行うことができる。
【発明を実施するための最良の形態】
【００１４】
（第１の実施形態）
図１は、本発明の第１の実施形態におけるアドホックネットワークの一例である。アドホックネットワーク１のＳＳＩＤは、「AdHoc_SSID」となっている。また、無線端末２ａは、無線端末２ｂ、無線端末２ｃ、無線端末２ｄ、無線端末２ｅと無線ＬＡＮにおける接続が確立しており、通信可能な状態となっている。
【００１５】
図２は、本発明における無線端末のハードウェア構成例を示す図である。
【００１６】
無線端末２は、例えば、パーソナルコンピュータであり、ＣＰＵ１０と、ＨＤＤ１４と、ＲＯＭ１２と、ＲＡＭ１１と、無線ＬＡＮＩ／Ｆ（無線ＬＡＮインタフェース）１３とを有している。ＣＰＵ１０は、ＨＤＤ１４またはＲＯＭ１２に記憶されたオペレーティングシステムや各種プログラムに従って無線端末２の各部を制御する。ＲＡＭ１１は、ＣＰＵ１０のワークエリアであり実行中のプログラムやデータが一時的に記憶される。ＨＤＤ１４またはＲＯＭ１２には、オペレーティングシステムや無線ドライバ等の各種プログラムが格納されている。無線ＬＡＮＩ／Ｆ１３は、アドホックネットワークと無線通信を行うための無線通信回路等である。
【００１７】
図３は、本発明における無線端末のソフトウェア構成例を示す図である。
【００１８】
図３に示す各ソフトウェアは、ＨＤＤ１４またはＲＯＭ１２に格納されている。オペレーティングシステム（ＯＳ）２０は、無線端末２を制御するための基本ソフトウェアである。無線ドライバ２３は、無線ＬＡＮＩ／Ｆ１３を制御するドライバであり、後述するＰｒｏｂｅ通信と、通信品質テーブル２３ｂの管理・更新を行う。また、無線ドライバ２３はＡＰＩ（ＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）２３ａを提供しており、アプリケーション２１や上位レイヤプログラム２２は、このＡＰＩ２３ａを利用することで、無線ドライバ２３が管理するリソース（通信品質テーブルなど）にアクセスし、また命令を与えることができる。上位レイヤプログラム２２は、無線ドライバ２３の上位レイヤに位置するプログラムで、例えば、インターネット層の通信を司るＩＰ（ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ）等のプログラムである。アプリケーション２１は、Ｗｅｂブラウザ等、利用者に特定の機能を提供する応用ソフトウェアのことであり、オペレーティングシステム２０上で動作している。
【００１９】
図４は、無線ドライバが管理・更新する通信品質テーブルの一例を示す図である。
【００２０】
通信品質テーブルは、例えば、ＲＡＭ１１上に保持される。Ｉｎｄｅｘ３０は、各エントリの識別子である。識別情報３１は、通信先の無線端末を一意に特定する情報であり、一例として、通信先端末のＭＡＣアドレスが記憶されている。ＲＳＳＩ（ＲｅｃｅｉｖｅｄＳｉｇｎａｌ Ｓｔｒｅｎｇｔｈ Ｉｎｄｉｃａｔｉｏｎ）３２は、無線端末が受信する電波信号の強度を示すものである。
【００２１】
次に、第１の実施形態における、無線ＬＡＮシステムの動作について、図１、図３、図４を用いて説明する。
【００２２】
図１において、無線端末２ａ、無線端末２ｂ、無線端末２ｃ、無線端末２ｄ、無線端末２ｅは、ＳＳＩＤ「AdHoc_SSID」を有するアドホックネットワークを形成している。そして、無線端末２ａは、無線端末２ｂ、無線端末２ｃ、無線端末２ｄ、無線端末２ｅと通信可能となっている。
【００２３】
以下、無線端末２ａの動作について説明する。まず、無線端末２ａは、通信先の無線端末（無線端末２ｂ、無線端末２ｃ、無線端末２ｄ、無線端末２ｅ）に対して、定期的にＰｒｏｂｅＲｅｑｕｅｓｔを送信している。
【００２４】
通信先の無線端末（無線端末２ｂ、無線端末２ｃ、無線端末２ｄ、無線端末２ｅ）は、ＰｒｏｂｅＲｅｑｕｅｓｔを受信すると、Ｐｒｏｂｅ Ｒｅｓｐｏｎｓｅを応答する。ＰｒｏｂｅＲｅｓｐｏｎｓｅには、通信先の無線端末の識別情報（ＭＡＣアドレス等）が含まれている。
【００２５】
無線端末２ａの無線ドライバ２３は、Ｐｒｏｂｅ Ｒｅｓｐｏｎｓｅを受信すると、受信したときの電波信号強度を取得し、その内容を通信品質テーブル２３ｂに登録する。具体的には、ＰｒｏｂｅＲｅｓｐｏｎｓｅに含まれる通信先端末の識別情報（ＭＡＣアドレス等）と、取得した電波信号強度とを関連づけて、通信品質テーブル２３ｂに登録する。図１では、通信先の無線端末は４台（無線端末２ｂ、無線端末２ｃ、無線端末２ｄ、無線端末２ｅ）あるので、その全てからＰｒｏｂｅＲｅｓｐｏｎｓｅの応答を受けた場合、通信品質テーブル２３ｂには、４台の情報が登録されることになる。
【００２６】
ここで、通信品質テーブル２３ｂが、図４に示す内容となったとする。Ｉｎｄｅｘ「１」が無線端末２ｂ、「２」が無線端末２ｃ、「３」が無線端末２ｄ、「４」が無線端末２ｅの情報を示している。
【００２７】
アプリケーション２１や上位レイヤプログラム２２は、無線ドライバ２３のＡＰＩ２３ａを呼び出すことによって、通信品質テーブル２３ｂの内容を参照することができる。図４の場合、Ｉｎｄｅｘ「４」に登録された無線端末２ｅとの電波信号強度が弱いため、無線端末２ｅとの通信品質が劣化していることが分かる。
【００２８】
アプリケーション２１や上位レイヤプログラム２２は、例えば、無線端末２ｅとの通信レートを低くする、もしくは、無線端末２ａの利用者に対して無線端末２ｅとの通信品質が劣化したことを通知する、等の処理を行うことができる。
【００２９】
無線端末２ａは、定期的にＰｒｏｂｅ通信（Ｐｒｏｂｅ Ｒｅｑｕｅｓｔの送信・Ｐｒｏｂｅ Ｒｅｓｐｏｎｓｅの受信）を行うことにより、通信品質テーブル２３ｂを更新している。したがって、アドホックネットワーク「AdHoc_SSID」に存在する無線端末について、個々の通信ごとに、どの程度の通信品質が確保されているのかを知ることができる。また、無線端末２ａは、通信先の無線端末からＰｒｏｂｅＲｅｓｐｏｎｓｅを受信しなかった場合、その無線端末がアドホックネットワーク「AdHoc_SSID」から離脱したことを、いち早く知ることができる。
【００３０】
このように、無線端末２ａは、通信品質テーブル２３ｂを参照することにより、通信先端末との通信品質をいち早く把握することができるので、その通信品質に応じた様々な処理を行うことができる。例えば、無線端末２ａは、通信品質の変化に応じて、マルチキャストレートやブロードキャストレートの設定を変更することができる。また、ＲＳＳＩに閾値を設定し、その閾値を基にマルチキャストのアドレスを変更し、通信品質が良好で高速にパケット通信が見込める通信先端末には、速度が要求される通信やデータサイズの大きい通信を行い、通信品質が劣化し低速なパケット通信しかできない通信先端末には、速度が要求されずデータサイズの小さい通信を行うといったように、通信品質に応じて通信方法を変更することもできる。
【００３１】
このように、第１の実施形態によれば、無線端末が通信先の無線端末に対して、定期的に、Ｐｒｏｂｅ通信を行うことにより、通信先の無線端末との通信品質をリアルタイムに把握することができるので、アプリケーションや上位レイヤプログラムは、通信先の無線端末との通信品質に応じた制御を行うことができる。
【００３２】
（第２の実施形態）
第１の実施形態では、無線端末は、全ての通信先の無線端末に対して、定期的にＰｒｏｂｅ通信を行っていたが、第２の実施形態では、Ｐｒｏｂｅ通信を行う通信先端末を特定する場合を説明する。また、Ｐｒｏｂｅ通信を行う通信間隔を指定する場合も併せて説明する。
【００３３】
第２の実施形態における、アドホックネットワークの構成例は図１と同様である。また、無線端末のハードウェア構成例は図２と同様であり、ソフトウェア構成例は図３と同様である。通信品質テーブルの内容が第１の実施形態の場合と異なる。
【００３４】
図５は、第２の実施形態における通信品質テーブルの一例を示す図である。
【００３５】
通信品質テーブルは、第１の実施形態と同様、無線ドライバによって管理されている。Ｉｎｄｅｘ４０は、各エントリの識別子である。ＲＳＳＩ（ＲｅｃｅｉｖｅｄＳｉｇｎａｌ Ｓｔｒｅｎｇｔｈ Ｉｎｄｉｃａｔｉｏｎ）４２は、無線端末が受信する電波信号の強度を示すものである。登録端末情報４１は、Ｐｒｏｂｅ通信の対象となる無線端末を一意に特定する情報であり、一例として、その無線端末のＭＡＣアドレスが記憶されている。ＲｅｌｏａｄＩｎｔｅｒｖａｌ４３は、無線端末がＰｒｏｂｅ通信を行う間隔を示したものである。なお、第２の実施形態の場合、登録端末情報４１とＲｅｌｏａｄＩｎｔｅｒｖａｌ４３は、無線端末の利用者によってあらかじめ指定されている。
【００３６】
なお、通信品質テーブルに登録される情報のうち、登録端末情報４１とＲｅｌｏａｄ Ｉｎｔｅｒｖａｌ４３は、利用者が設定する情報なので、電源切断後の次回起動時でも、その設定が有効となるようにしてもよい。この場合、これらの情報を、ＲＯＭ、ＨＤＤ等に記憶すればよい。
【００３７】
次に、第２の実施形態における、無線ＬＡＮシステムの動作について、図１、図３、図５を用いて説明する。
【００３８】
無線端末２ａの動作について説明する。まず、無線端末２ａの利用者は、通信品質を確認する無線端末の情報（登録端末情報）とＲｅｌｏａｄＩｎｔｅｒｖａｌを、通信品質テーブル２３ｂにあらかじめ登録しておく。具体的には、利用者は、無線端末２ａのＵＩ（Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）から、通信品質テーブル２３ｂの登録端末情報４１の項目とＲｅｌｏａｄ Ｉｎｔｅｒｖａｌ４３の項目にアクセスし、登録すればよい。
【００３９】
ここで、無線端末２ａの利用者は、図５で示す登録端末情報を登録したものとする。図５では、３つの無線端末が登録されており、Ｉｎｄｅｘ「１」が無線端末２ｃ、Ｉｎｄｅｘ「２」が無線端末２ｄ、Ｉｎｄｅｘ「３」が無線端末２ｅとする。無線端末２ｂは登録されていない。
【００４０】
利用者による登録端末情報とＲｅｌｏａｄ Ｉｎｔｅｒｖａｌの設定が終了すると、無線端末２ａは、ＳＳＩＤ「AdHoc_SSID」を有するアドホックネットワークと接続する。
【００４１】
図１において、無線端末２ａ、無線端末２ｂ、無線端末２ｃ、無線端末２ｄ、無線端末２ｅは、ＳＳＩＤ「AdHoc_SSID」を有するアドホックネットワークを形成している。そして、無線端末２ａは、無線端末２ｂ、無線端末２ｃ、無線端末２ｄ、無線端末２ｅと通信可能である。
【００４２】
無線端末２ａは、通信品質テーブル２３ｂに登録された無線端末（無線端末２ｃ、無線端末２ｄ、無線端末２ｅ）に対して、通信品質テーブル２３ｂに登録されたＲｅｌｏａｄＩｎｔｅｒｖａｌ４３の間隔で、Ｐｒｏｂｅ Ｒｅｑｕｅｓｔを送信する。図５の場合、無線端末２ｃと無線端末２ｄと無線端末２ｅが登録されているので、無線端末２ｃに対しては５秒間隔で、無線端末２ｄに対しては１０秒間隔で、無線端末２ｅに対しては８秒間隔で、ＰｒｏｂｅＲｅｑｕｅｓｔを送信する。
【００４３】
通信先の無線端末は、Ｐｒｏｂｅ Ｒｅｑｕｅｓｔを受信すると、ＰｒｏｂｅＲｅｓｐｏｎｓｅを応答する。Ｐｒｏｂｅ Ｒｅｓｐｏｎｓｅには、通信先の無線端末の識別情報（ＭＡＣアドレス等）が含まれている。
【００４４】
無線端末２ａの無線ドライバ２３は、Ｐｒｏｂｅ Ｒｅｓｐｏｎｓｅを受信すると、受信したときの電波信号強度を取得し、その内容を通信品質テーブル２３ｂに登録する。具体的には、ＰｒｏｂｅＲｅｓｐｏｎｓｅに含まれる通信先端末の識別情報（ＭＡＣアドレス等）を取得し、その識別情報が通信品質テーブル２３ｂに登録されている登録端末情報と一致するかどうかを判断する。一致する場合、電波信号強度を取得し、一致する登録端末情報と関連づけて通信品質テーブル２３ｂに登録する。図１では、登録されている無線端末は、無線端末２ｃと無線端末２ｄと無線端末２ｅなので、これ以外の無線端末（例えば無線端末２ｂ）からＰｒｏｂｅＲｅｓｐｏｎｓｅを受信しても、その情報は登録されない。無線端末２ａは、Ｒｅｌｏａｄ Ｉｎｔｅｒｖａｌで指定された間隔でＰｒｏｂｅ通信（Ｐｒｏｂｅ Ｒｅｑｕｅｓｔの送信・ＰｒｏｂｅＲｅｓｐｏｎｓｅの受信）を行うことにより、通信品質テーブルを更新する。
【００４５】
なお、通信品質テーブル２３ｂに登録された無線端末にＰｒｏｂｅ Ｒｅｑｕｅｓｔを送信したが、当該無線端末（例えば、無線端末２ｅ）からＰｒｏｂｅ Ｒｅｓｐｏｎｓｅを受信しなかった場合には、その旨を通信品質テーブル２３ｂに登録する。図５によれば、Ｉｎｄｅｘ「３」に登録された無線端末２ｅのＲＳＳＩが「０」と登録されているが、これは、無線端末２ｅからのＰｒｏｂｅＲｅｓｏｐｎｓｅを受信しなかったことを示す。
【００４６】
アプリケーション２１や上位レイヤプログラム２２は、無線ドライバ２３の通信品質情報取得用のＡＰＩ２３ａを呼び出すことによって、通信品質テーブル２３ｂの内容を参照することができる。アプリケーション２１や上位レイヤプログラム２２が行う処理は、第１の実施形態の場合と同様なので、その説明は省略する。
【００４７】
また、第２の実施形態の場合、無線端末２ａは、通信品質テーブル２３ｂに登録された無線端末に対してＰｒｏｂｅＲｅｑｕｅｓｔを送信するので、例えば、アドホックネットワークへの参加を検出したい無線端末（例えば無線端末２ｆ（図示せず））があれば、その情報を登録端末情報として、あらかじめ無線端末２ａの通信品質テーブル２３ｂに登録しておけばよい。このようにすれば、無線端末２ｆがアドホックネットワークに参加したことを、いち早く検出することができる。
【００４８】
このように、第２の実施形態によれば、あらかじめ登録しておいた無線端末に対してのみＰｒｏｂｅ通信を行うので、Ｐｒｏｂｅ通信のパケットによってアドホックネットワークの負荷が高まることを回避することができる。
【００４９】
また、第２の実施形態によれば、あらかじめ登録しておいた無線端末に対して、ＰｒｏｂｅＲｅｑｕｅｓｔを送信するので、アドホックネットワークへの参加を検出したい無線端末の識別情報が分かっている場合、その情報を通信品質テーブルに登録しておけば、当該無線端末がアドホックネットワークに参加したことを、いち早く検出することができる。
【産業上の利用可能性】
【００５０】
本発明は、無線のアドホックネットワークにおいて、無線端末が通信先端末との通信品質をリアルタイムに把握する場合に、有用である。
【図面の簡単な説明】
【００５１】
【図１】本発明の第１および第２の実施形態におけるアドホックネットワークの構成例を示す図である。
【図２】本発明の第１および第２の実施形態における無線端末のハードウェア構成例を示す図である。
【図３】本発明の第１および第２の実施形態における無線端末のソフトウェア構成例を示す図である。
【図４】本発明の第１の実施形態における通信品質テーブルの一例を示す図である。
【図５】本発明の第２の実施形態における通信品質テーブルの一例を示す図である。
【図６】従来のアドホックネットワークの構成例を示す図である。
【符号の説明】
【００５２】
１                            アドホックネットワーク
２ａ、２ｂ、２ｃ、２ｄ、２ｅ  無線端末
【図１】
0004924948.tif 000002
【図２】
0004924948.tif 000003
【図３】
0004924948.tif 000004
【図４】
0004924948.tif 000005
【図５】
0004924948.tif 000006
【図６】
0004924948.tif 000007