JPWO2008102504A1 - 無線端末および無線端末のハンドオーバー方法 - Google Patents

Abstract

データ送受信機能とハンドオーバー制御部とを備えた無線端末を構成する。ハンドオーバー制御部は、利用可能なすべての無線チャネルでハンドオーバー先の存在の有無をスキャンする。ハンドオーバー制御部は、ハンドオーバー実行前に事前にハンドオーバー先の存在の有無をスキャンすることにより、ハンドオーバー先の候補を取得し、その候補が、端末から通信可能範囲内にあるか調べるために検証スキャンを実行する。そして、検証スキャンの実行結果に基づいて、ハンドオーバーを行う。

Description

本発明は、無線端末および無線端末のハンドオーバー方法に関する。

情報通信技術の進歩に対応して、無線ＬＡＮが広く普及してきている。無線ＬＡＮを使用した移動通信を適切に実現するための技術として、ハンドオーバーと呼ばれる技術が知られている。特開２００２−０１６９５８号公報には、候補基地局リストで選択された基地局に対応する拡散符号を用いて、基地局からのパイロット信号の受信を試み、ハンドオーバー先の基地局として適当か否かを判定する技術が記載されている。特開２００４−２０７９２２号公報には、無線ＬＡＮシステムに用いるハンドオーバー処理方法として、無線端末装置が、スキャン処理の結果、アクセスポイント（ＡＰ）接続候補リストに無線基地局の情報を格納する技術が記載されている。特開２００５−１７５９３２号公報には、無線ＬＡＮハンドオー場処理に関する技術が記載されている。特開２００５−１８４１６０号公報には、ハンドオーバー解決方法に関する技術が記載されている。

無線ＬＡＮ端末がハンドオーバーを行う場合、あらかじめ収集したアクセスポイントに関する情報を用いて最適なアクセスポイントを選び出し、そのアクセスポイントが使用しているチャネルへ移り、Authentication RequestおよびReassociation Requestフレームを送信する。アクセスポイントに関する情報の収集は、Beaconフレームを受信するか、Probe Requestフレームを利用可能なチャネルにて送信し、そのフレームに対する応答であるProbe Responseフレームを収集することによって行われる。しかし利用可能な全チャネルに渡ってアクセスポイントに関する情報を集める場合、各チャネルごとに無線チャネルの切り替えやBeaconフレームもしくはProbe Responseフレームの収集に時間を費やす。そのため、この動作は、時間的および電力的なコストが大きい。したがって、この動作は、頻繁に行なうことをせず、数秒〜数十秒ごとに行うのが一般的である。最新のアクセスポイントに関する情報は、現在の時刻から最も古い場合で、その情報を収集する周期時間前の情報である。

端末が移動している場合、そのアクセスポイントに関する情報が古いと、最適と判断したアクセスポイントがすでに接続できない状態になっている可能性がある。その場合、再び全チャネルに渡ってアクセスポイントに関する情報を収集し、改めて最適なアクセスポイントを選択する必要がある。
このアクセスポイントに関する情報を集める作業中は、現在使用中のアクセスポイントのチャネルと異なるチャネルで情報を収集している場合、現在使用中のアクセスポイントと通信を行うことはできない。したがって、例えばＶｏＩＰによる通話中にこの情報収集が行われた場合、ユーザが認知できるような音切れとして表れてしまうことがある。

本発明の目的は、ハンドオーバーを行う際に、ハンドオーバー候補として通信が不可能なアクセスポイントを選択してしまうことでハンドオーバーに失敗してしまうことを減らすことである。

本発明では、無線端末が、データ送受信機能とハンドオーバー制御部とを備えている。ハンドオーバー制御部は、利用可能なすべての無線チャネルでハンドオーバー先の存在の有無をスキャンする。ハンドオーバー制御部は、ハンドオーバー実行前に事前にハンドオーバー先の存在の有無をスキャンすることにより、ハンドオーバー先の候補を取得し、その候補が、端末から通信可能範囲内にあるか調べるために検証スキャンを実行し、検証スキャンの実行結果に基づいて、候補にハンドオーバーを行う。

本発明は、ハンドオーバーを行う際に、ハンドオーバー候補として通信が不可能なアクセスポイントを選択してしまうことでハンドオーバーに失敗してしまうことを減らすことができる。

上記発明の目的、効果、特徴は、添付される図面と連携して実施の形態の記述から、より明らかになる。

図１は、ハンドオーバーが行われる無線ＬＡＮ網の概念を例示する概念図である。 図２は、ＶｏＩＰ端末７の構成を例示するブロック図である。 図３は、ＲＯＭ１２に格納されるソフトウェアの構成を例示するブロック図である。 図４は、実施例の動作を例示するシーケンス図である。 図５Ａは、ハンドオーバーの必要性の判断、および、ハンドオーバー処理の手順について記したフローチャートである。 図５Ｂは、ハンドオーバーの必要性の判断、および、ハンドオーバー処理の手順について記したフローチャートである。 図５Ｃは、ハンドオーバーの必要性の判断、および、ハンドオーバー処理の手順について記したフローチャートである。 図６は、全スキャンの動作を例示するフローチャートである。 図７は、スキャン処理の動作を例示するフローチャートである。 図８は、無通信となる時間を割り出す動作を例示するシーケンス図である。 図９は、バックグラウンド全スキャンの動作を例示するフローチャートである。 図１０Ａは、第２実施例の動作を例示するフローチャートである。 図１０Ｂは、第２実施例の動作を例示するフローチャートである。 図１１Ａは、検証スキャンを行わない場合の動作を例示するシーケンス図である。 図１１Ｂは、検証スキャンを行わない場合の動作を例示するシーケンス図である。

本発明の実施の形態について図面を参照しながら説明する。しかしながら、係る形態は本発明の技術的範囲を限定するものではない。

［第１実施例］
図１は、ハンドオーバーが行われる無線ＬＡＮ網の概念を例示する概念図である。その無線ＬＡＮ網は、第１アクセスポイント１（ＡＰ１）と、第２アクセスポイント２（ＡＰ２）と、第１領域３と、第２領域４と、第３領域５と、第４領域６と、ＶｏＩＰ端末７と、有線ネットワーク８と、広域ネットワーク９と、電話端末１０とを含んでいる。

第１アクセスポイント１と、第２アクセスポイント２は、ＩＥＥＥ８０２．１１で規定される仕様に従ったアクセスポイントである。第１領域３は、第１アクセスポイント１の受信電界強度が、切り替え閾値（切り替え閾値については、図３で説明する）以上の領域である。第２領域４は第２アクセスポイント２の受信電界強度が切り替え閾値以上の領域である。第３領域５は、第１アクセスポイント１の受信電界強度が検出閾値（検出閾値については図３で説明する）以上の領域である。第４領域６は、第２アクセスポイント２の受信電界強度が検出閾値以上の領域である。

ＶｏＩＰ端末７は、無線ＬＡＮを用いてＶｏＩＰ通信する機能を備えた端末である。換言すると、ＶｏＩＰ端末７には、無線ＬＡＮ装置が組み込まれ、その無線ＬＡＮ装置は、本実施例のハンドオーバーを実現する機能を有している。
有線ネットワーク８は、第１アクセスポイント１と第２アクセスポイント２とを接続する。例えば、イーサネット（登録商標）のようなネットワークがその代表である。広域ネットワーク９は、電話端末１０と有線ネットワーク８を接続するネットワークであり、インターネットなどがこれに該当する。電話端末１０は、ＶｏＩＰ端末７の通信先の端末である。本実施例において、電話端末１０は、必ずしもＶｏＩＰ電話である必要は無い。

以下に、ＶｏＩＰ端末７について説明を行う。図２は、ＶｏＩＰ端末７の構成を例示するブロック図である。ＶｏＩＰ端末７は、ＣＰＵ（Central Processing Unit）１１、ＲＯＭ（Read Only Memory）１２、ＲＡＭ（Random Access Memory）１３、ＣＯＤＥＣ（coder/decoder）１４、無線ＬＡＮ（Local Area Network）チップ１５、ディスプレイ１７、キーボード１８、スピーカー１９およびマイクロフォン２１を備え、それらはバス２２を介して接続されている。また、アンテナ１６は無線ＬＡＮチップ１５に接続されている。

ＣＰＵ１１は、ＲＯＭやＲＡＭに格納されたソフトウェアを実行する。ＲＯＭ１２は読み込み専用の不揮発性メモリである。ＲＯＭ１２は、ＯＳやＶｏＩＰ端末７を駆動するのに必要なソフトウェアを格納している。ＲＡＭ１３は揮発性メモリであり、一時的なデータを保存するための領域として利用される。なお、ＲＯＭ１２またはＲＡＭ１３は、フラッシュメモリなどに代表されるデータの消去が可能な不揮発性メモリであっても良い。

ＣＯＤＥＣ１４はマイクロフォン２１より入力された音声データを、ＩＴＵ−Ｔ Ｇ．７１１などの形式に従ったデジタルデータに変換したり、逆にＧ．７１１などの形式に従ったデジタルデータをスピーカー１９で再生するためのデジタルデータに変換したりする。無線ＬＡＮチップ１５は、ＩＥＥＥ８０２．１１で規定される無線ＬＡＮプロトコルを処理するチップである。アンテナ１６は、無線ＬＡＮチップ１５から送られてくる信号を電波として送信すると同時に、第１アクセスポイント１および第２アクセスポイント２もしくは他のＶｏＩＰ端末からの電波を受信するための装置である。

ディスプレイ１７は液晶などを用いた表示装置である。キーボード１８は電話番号などを入力するためのキーボードである。スピーカー１９は、ＣＯＤＥＣ１４で変換された音声データを入力すると、音声として出力する。マイクロフォン２１は、音声をデジタル信号に変換する。

以下に、ＶｏＩＰ端末７に備えられるソフトウェアに関して説明を行う。以下の実施例においては、ＯＳを除いたソフトウェアがＲＯＭ１２に格納されることが好ましい。図３は、ＲＯＭ１２に格納されるソフトウェアの構成を例示するブロック図である。ＶｏＩＰ端末７のＲＯＭ１２に格納されるソフトウェアは、ＶｏＩＰアプリケーション２３、ＴＣＰ／ＩＰ処理部２４、無線ＬＡＮドライバ２５、無線ＬＡＮ ＭＡＣ２６、および無線ＬＡＮ ＰＨＹ２７を含んでいる。

ＶｏＩＰアプリケーション２３は、マイクロフォン２１から受け取った音声データをＣＯＤＥＣ１４によって例えばＧ．７１１規定の形式に変換し、別途作成したＲＴＰパケットのペイロード部分に変換したデータを格納し、ＴＣＰ／ＩＰ処理部２４へ渡す。また、ＶｏＩＰアプリケーション２３は、ＴＣＰ／ＩＰ処理部２４から受け取ったＲＴＰパケットのペイロード部分から、Ｇ．７１１形式の音声データを取り出し、取り出したデータをＣＯＤＥＣ１４によってスピーカー１９で再生できる形式に変換し、変換したデータをスピーカー１９へ渡して受信した音声データを再生する。

ＴＣＰ／ＩＰ処理部２４は、ＩＥＴＦで発行されているＲＦＣ７９１およびＲＦＣ７９３で規定されるＴＣＰ／ＩＰプロトコルを処理する部分である。無線ＬＡＮドライバ２５は無線ＬＡＮチップ１５を制御するためのソフトウェアである。無線ＬＡＮ ＭＡＣ２６および無線ＬＡＮ ＰＨＹ２７は無線ＬＡＮチップセット２０５内に格納されており、無線ＬＡＮ ＭＡＣ２６はＩＥＥＥ８０２．１１で規定されるＭＡＣプロトコルを処理する部分である。また無線ＬＡＮ ＰＨＹ２７は、同仕様のＰＨＹプロトコルを処理する部分である。

上述の無線ＬＡＮドライバ２５は、さらに、ハンドオーバー制御部２８と、通信制御部２９と、アクセスポイントテーブル３１と、検証スキャン用パラメータ格納領域３２と、通常スキャン用パラメータ格納領域３３と、切り替え閾値格納領域３４と、検出閾値格納領域３５とを含んで構成されている。ハンドオーバー制御部２８は、周辺に存在するアクセスポイントに関する情報の収集、ハンドオーバーの必要性の判断、ハンドオーバー先の選定、およびハンドオーバーの処理を行う。通信制御部２９は、ハンドオーバー制御部２８で処理される内容以外で通信に必要な制御を行う。アクセスポイントテーブル３１は、ＶｏＩＰ端末７のスキャン動作によって得られたアクセスポイントに関する情報を蓄積する領域であり、ハンドオーバー先の候補のアクセスポイントに関する情報はここに格納される。

切り替え閾値格納領域３４は、切り替え閾値を格納している。検出閾値格納領域３５は、検出閾値を格納している。検出閾値とは、ＶｏＩＰ端末７がアクセスポイントと通信が可能な受信電界強度の最小値である。一方、切り替え閾値は検出閾値よりも若干大きな値であり、具体的にはＶｏＩＰ端末７が移動している際に、通信中のアクセスポイントの受信電界強度が切り替え閾値から検出閾値まで低下するのに要する時間が、以下に説明する検証スキャンとバックグラウンド全スキャンを行うのに要する時間よりも長くなるような値である。切り替え閾値は、ＶｏＩＰ端末７が仕様としてサポートする移動速度に依存する値であり、より高速な移動に対応するのであれば、その分だけ切り替え閾値は検出閾値よりも大きく取る必要がある。

以下に、第１実施例の動作について説明を行う。図４は、第１実施例の動作を例示するシーケンス図である。まず検証スキャンを行う場合、Probe Requestフレーム（１１０１、１１０２）を送信する。この場合、端末はハンドオーバー候補のアクセスポイントの通信可能領域外にあるため、Probe Responseフレームによる応答はない。検証スキャン用パラメータ格納領域に格納されるMinChannelTime、および、MaxChannelTimeの値は最大で、
「ＶｏＩＰ端末がアクセスポイントから音声フレームを受信した時点からアクセスポイントへ音声フレームを送信するまでの期間」（後述する第１期間Ｌ１）
「ＶｏＩＰ端末がアクセスポイントへ音声フレームを送信した時点からアクセスポイントより音声フレームを受信するまでの期間」（後述する第２期間Ｌ２）
の大きい方の値を取ることができる（第１期間Ｌ１と第２期間Ｌ２に関する詳細は、後述する）。しかし、大きすぎると検証スキャンに要する時間が長くなる。そのため、本実施例では数ｍｓと想定し、かつ両者同じ値とする。よってハンドオーバー候補のアクセスポイントが存在しないと判断するまでに要する時間は、長くて十数ｍｓである。

この検証スキャンを行っている間は、現在通信中のアクセスポイントの通信可能領域内にあり、また端末のデータの送受信を阻害しないように行う。したがって、この間で音切れは発生しない。その後、データ送受信を継続しつつ行う全スキャン（以下、バックグラウンド全スキャンと呼ぶ。）を実施し（１１０３）、新たにハンドオーバー先の候補を見つける。

バックグラウンド全スキャンが終わると、新しいハンドオーバー先の候補とAuthentication Request/Responseメッセージ（１１０４，１１０５）、および、Association Request/Responseメッセージ（１１０６，１１０７）の交換を行い、新しいハンドオーバー先の候補へのアクセスポイントへのハンドオーバーが完了する。

以下に、上述の動作について、フローチャートを用いて詳細に説明する。図５Ａ〜図５Ｃは、ハンドオーバー制御部２８におけるハンドオーバーの必要性の判断、および、ハンドオーバー処理の手順について記したフローチャートである。図５Ａ〜図５Ｃに示されている動作は、ＶｏＩＰ端末７において定期的に実行されている。なお本実施例では、あらかじめセル設計を行い、同一の領域で同じチャネルを用いてサービスを行っているアクセスポイントが存在しない場合に対応して説明を行う。

ステップＳ１０１において、無線ＬＡＮ ＭＡＣ２６でビーコンフレームを受信する。ビーコンフレームの受信は、無線ＬＡＮドライバ２５に割り込みによって通知される。ステップＳ１０２において、無線ＬＡＮドライバ２５は、ビーコンフレーム受信の割り込みを受けると、無線ＬＡＮチップ１５からビーコンフレーム受信時の受信電界強度を取得する。ステップＳ１０３において、無線ＬＡＮドライバ２５は、取得した受信電界強度が切り替え閾値より小さいかどうかチェックする。切り替え閾値以上であれば、ハンドオーバー処理は終了する。

切り替え閾値未満である場合は、処理はステップＳ１０４に進む。ステップＳ１０４において、無線ＬＡＮドライバ２５は、アクセスポイントテーブル３１を参照して、ハンドオーバー先の候補であるアクセスポイントがあるかどうか調べる。通常ＶｏＩＰ端末７は、現在通信しているアクセスポイントの受信電界強度が切り替え閾値以上であっても、定期的に全スキャンするなどにより、ハンドオーバー先の候補としているアクセスポイントは常に保持している。ここにおいて、もし候補が存在しない場合は、処理はステップＳ１０５に進み、全スキャンを行う。

ここで、全スキャンを行う場合の動作について説明を行う。図６は、全スキャンの動作を例示するフローチャートである。ステップＳ２０１において、通常スキャン用パラメータ格納領域３３より、MaxChannelTime、MinChannelTimeそれぞれにセットすべき値を取得する。次に、ステップＳ２０２において、無線ＬＡＮ ＭＡＣ２６に対して、取得したMaxChannelTime、MinChannelTimeをセットする。ステップＳ２０３において、これらの値をセットすると現在のＡＰが使用している無線チャネルに対してスキャン処理を実施する。ステップＳ２０３におけるスキャン処理に関する詳細は、後述する。

ステップＳ２０４において、スキャンを終了すると、次に利用可能なチャネルで未だ調査していないチャネルがあるかどうか調べる。もし残っていない場合は、処理はステップＳ２０５に進み、切り替えるべきチャネルが残っている場合は、処理はステップＳ２０６に進む。

ステップＳ２０５において、アクセスポイントテーブル３１に記録されている情報を参照してその中で最も受信電界強度の高いアクセスポイントをハンドオーバー先の候補として選択した後、全スキャン処理を終了する。ステップＳ２０６において、未調査の次のチャネルに切り替え、新しく切り替えたチャネルにおいて、ステップＳ２０３に戻り、再びスキャン処理を行う。

全スキャンは最低でもMinChannelTime時間、最大でMaxChannelTime時間要する動作である。MinChannelTimeおよびMaxChannelTimeにセットされる値は特に決められていないが、可能な限り多くのアクセスポイントに関する情報を集める意図があるため、通常それぞれ数十ｍｓから数百ｍｓ程度の値がセットされる。そのために、全チャネルのスキャンに１秒以上要することもある。

ここで、上述のステップＳ２０３でのスキャン処理について説明を行う。図７は、スキャン処理の動作を例示するフローチャートである。ステップＳ３０１において、現在セットされている無線チャネルに対してProbe Requestフレームを送信する。ステップＳ３０２において、Probe Requestフレームを送信すると同時にProbeTimerを開始する。ステップＳ３０３において、Probe Responseフレームを受信したかどうかチェックする。このスキャンの過程でまだ１フレームも受信していない場合、処理はステップＳ３０６に進む。ステップＳ３０６において、ProbeTimerがMinChannelTime以上かどうか調べる。もしこのスキャン過程でProbe Responseを１フレームも受信せずにMinChannelTime経過した場合、このチャネルにはアクセスポイントは無いものと判断して、スキャン処理を終了する。ステップＳ３０６において、ProbeTimerがMinChannelTime未満であれば、処理はステップＳ３０３に戻り、MinChannelTime経過するまでProbe Responseフレームが送られてくるのを待機する。

ステップＳ３０３において、スキャン開始後１度でもProbe Responseを受信した場合、処理はステップＳ３０４に進む。Probe Responseを１度でも受信すると、ステップＳ３０４において、ProbeTimerがMaxChannelTime以上かどうか調べる。MaxChannelTime以上でない場合は、処理はステップＳ３０３に戻り、MaxChannelTime時間経過するまでProbe Responseフレームを収集する。MaxChannelTime以上経過すると、処理は、ステップＳ３０５に進む。ステップＳ３０５において、このスキャン過程で受信したProbe Responseフレームについて、Probe Responseフレームの送信元と受信電界強度をアクセスポイントテーブル３１に書き込む。以上でスキャン処理が終了する。

再び、図５のフローチャートの動作について説明を行う。図５を参照すると、ステップＳ１０５の全スキャンを行った後に、処理はステップＳ１０６に進む。ステップＳ１０６において、アクセスポイントテーブル３１を参照して全スキャンの結果ハンドオーバー先として選出されたアクセスポイントの受信電界強度と切り替え閾値を比較する。その比較の結果、候補のアクセスポイントの受信電界強度の方が切り替え閾値よりも大きい場合、処理はステップＳ１０７に進む。ステップＳ１０７において、そのアクセスポイントを、実際に通信が可能なハンドオーバー先の候補のアクセスポイントとする。その後、処理はステップＳ１２２に進み、ハンドオーバーを実施する。ステップＳ１０６の比較の結果、候補のアクセスポイントの受信電界強度の方が切り替え閾値よりも小さい場合は、全スキャン動作に戻り、切り替え閾値よりも受信電界強度の高いアクセスポイントが現れるまで全スキャン動作を繰り返す。

次に、ステップＳ１０４の処理ので、ハンドオーバー先の候補が存在する場合について説明する。ハンドオーバー先の候補が存在する場合、ステップＳ１０８において、そのハンドオーバー先の候補に関する情報の新鮮さをチェックするために、閾値Ｔ１秒以上前にそれが決定されたものかどうかの判断を行う。

その判断の結果、閾値Ｔ１秒未満の間に決定されたものであれば、この情報は新鮮であり情報の確からしさが高いと見なし、検証スキャンを実施せずにステップＳ１２２に進みそのままハンドオーバーの処理を実施する。ハンドオーバー先の候補の情報がＴ１秒以上経った古い情報の場合、処理はステップＳ１０９に進み検証スキャンを実施する。ステップＳ１０９において、上りおよび下り方向のＶｏＩＰフレームの送受信時刻より無通信となる時間を割り出し、無通信時を見計らってハンドオーバー先の候補のアクセスポイントが使用するチャネルへ切り替える。

ここにおいて、無通信となる時間を割り出す動作について説明する。図８は、無通信となる時間を割り出す動作を例示するシーケンス図である。本実施例において、無通信となる時間の割り出しは、ＶｏＩＰフレームの周期性を利用している。まず現在の時刻をｔ５とする。また、このＶｏＩＰ端末７は、過去アクセスポイントより時刻ｔ１と時刻ｔ３にアクセスポイントからＶｏＩＰフレームを受信したとする。さらに、時刻ｔ２および時刻ｔ４に、ＶｏＩＰ端末７が上り方向のフレームを送信したとする。

図８を参照すると、ＶｏＩＰ端末は、次にアクセスポイントよりフレームを受信する時刻を、
時刻ｔ６＝時刻ｔ３＋（時刻ｔ３−時刻ｔ１）
と予想できる。またその次にアクセスポイントよりフレームを受信する時刻ｔ８についても同様に、
時刻ｔ８＝時刻ｔ６＋（時刻ｔ３−時刻ｔ１）
と予想できる。またＶｏＩＰ端末は自身が上りにフレームを送信する時刻を、
時刻ｔ７＝時刻ｔ４＋（時刻ｔ４−時刻ｔ２）
と予測できる。

検証スキャンを行うタイミングとして、ＶｏＩＰ端末がアクセスポイントから音声フレームを受信した時点からアクセスポイントへ音声フレームを送信するまでの期間（以下、第１期間Ｌ１と呼ぶ）と、ＶｏＩＰ端末がアクセスポイントへ音声フレームを送信した時点からアクセスポイントより音声フレームを受信するまでの期間（以下、第２期間Ｌ２と呼ぶ。）の２通りがある。

この場合第１期間Ｌ１および第２期間Ｌ２はそれぞれ、
第１期間Ｌ１＝時刻ｔ７−時刻ｔ６
第２期間Ｌ２＝時刻ｔ８−時刻ｔ７
で算出することができる。次に第１期間Ｌ１と第２期間Ｌ２でどちらの期間が長いか調べ、もし第１期間Ｌ１の方が長い場合は、時刻ｔ６でＶｏＩＰフレームを受信した直後に検証スキャンを実施する。第２期間Ｌ２の方が長い場合は上り方向のフレームを送信した直後に検証スキャンを実施する。以上のようにして無通信となる時間を割り出す。

図５のフローチャートの説明に戻る。ステップＳ１０９で、ハンドオーバー先の候補が使用するチャネルへ切り替える。その後、ステップＳ１１０において、MinChannelTimeおよびMaxChannelTimeの値を、検証スキャン用パラメータ格納領域３２から取得し、それぞれにセットする。検証スキャンでは目的のアクセスポイントが存在するかどうかを調べるのが目的である。そのため、ここでMinChannelTimeおよびMaxChannelTimeの値として数ｍｓを想定する。本実施例では、同じ領域で同じチャネルを用いてサービスを行っているアクセスポイントは、ほとんど無いと仮定している。そのため、Probe Requestに対して応答を返すのは、ＶｏＩＰ端末が調べる目的としているアクセスポイントのみである。

ステップＳ１１１において、Probe Requestフレームを送信する。Probe Requestフレームを送信すると、ステップＳ１１２において、Probe Requestフレームに対する応答であるProbe Responseフレームをハンドオーバー先の候補のアクセスポイントからMinChannelTime時間以内に受信したかどうかチェックする。そのチェックの結果、受信しなかった場合、処理はステップＳ１１３に進む。

ステップＳ１１３において、閾値Ｔ２に示される回数以上連続してProbe Requestフレームに対する応答を受信しなかったのかどうかをチェックする。もし閾値Ｔ２に示される回数以上連続してProbe Requestに対する応答をハンドオーバー先の候補のアクセスポイントから受信しなかった場合は、この場合はハンドオーバー先の候補のアクセスポイントが存在しないとみなし、処理はステップＳ１０５に進み、全スキャンを実施する。そのチェックの結果、まだ閾値Ｔ２に示される回数に達していない場合は、処理はステップＳ１１１に戻り、再びProbe Requestフレームを送信する。

閾値Ｔ２についてであるが、この値を大きくしすぎると検証スキャンに要する時間が長くなるため、せいぜい閾値Ｔ２＝２程度とする。ステップＳ１１２の処理において、Probe ResponseフレームをMinChannelTime以内にハンドオーバー先の候補のアクセスポイントから受信した場合、処理はステップＳ１１４に進み、Probe Responseフレームの受信電界強度をチェックする。ステップＳ１１５において、その受信レベルと切り替え閾値の大きさを比較する。その比較の結果、Probe Responseフレームの受信電界強度が、切り替え閾値よりも小さい場合、処理はステップＳ１１６に進む。この場合は既にハンドオーバー先の候補のアクセスポイントの通信可能範囲外に移動してしまったとみなし、ハンドオーバー先の候補のアクセスポイントを再探索する。

ただし、現在の通信を妨害しないようにするため、バックグラウンドで全スキャンを実施して再探索することが好ましい。そのために、ステップＳ１１６において、MinChannelTime、および、MaxChannelTimeには、通常スキャン用パラメータ格納領域に格納されているパラメータに戻し、現在通信中のアクセスポイントのチャネルに切り替える。ステップＳ１１７において、通信の合間に全スキャンを行うバックグラウンド全スキャンを実施する。

ここにおいて、バックグラウンド全スキャンの動作について説明を行う。図９は、バックグラウンド全スキャンの動作を例示するフローチャートである。図９を参照すると、ステップＳ４０１において、同じチャネルに対してスキャンを行った回数が保存される変数ｎに１を代入する。ステップＳ４０２において、MaxChannelTime、MinChannelTimeに無通信区間の残り時間をセットする。上述したように、無通信区間が終わる時間はあらかじめわかるため、残り時間は無通信区間が終わる時間から現在の時間を減算することにより得られる。

ステップＳ４０３において、スキャン処理を実行する。このスキャン処理は上述のステップＳ１０５の処理と同様である。スキャン処理が終了するタイミングは、ＶｏＩＰ端末がデータの送受信を行うタイミングである。ステップＳ４０４において、スキャンを行ったチャネルを保存するために、変数ＣＨに現在のチャネルを代入する。

ステップＳ４０５において、現在のチャネルを変数ＣＨにセットすると、チャネルをこの端末が通信中のアクセスポイントが使用しているチャネルに切り替える。チャネル切り替えが終了すると、ステップＳ４０６において、データの送信もしくは受信の処理を行う。データの送信もしくは受信の処理が終わると、ステップＳ４０７において、変数ＣＨを参照しチャネルを先ほどスキャンしたチャネルへ切り替える。

ステップＳ４０８において、同じチャネルに対して何度スキャンしたかを調査する。その調査の結果、もし、ある閾値Ｔ４に示される回数未満の回数しかスキャンしていないのであれば、処理はステップＳ４０９に進む。ステップＳ４０９において、変数ｎに１を加え、処理を９０２へ戻す。一方、既に閾値Ｔ４に示される回数以上スキャンしているのであれば、処理はステップＳ４１０に進む。

ステップＳ４１０において、次に切り替えるべき未調査のチャネルが残っているかどうかの調査を行う。その調査の結果、もし未調査のチャネルが残っている場合は、処理はＳ４１１に進む。ステップＳ４１１において、次に利用可能な未調査のチャネルに切り替え、処理を９０２へ戻す。未調査のチャネルが残っていない場合は、処理はＳ４１２に進む。ステップＳ４１２において、アクセスポイントテーブル３１を参照し、最も受信電界強度の大きいアクセスポイントをハンドオーバー先の候補とする。

ここで説明したバックグラウンド全スキャンでは、閾値Ｔ４を大きくすると、より確実なスキャンを実施することができるが、大きくしすぎるとバックグラウンド全スキャンの所要時間が大きくなるため、１〜２を閾値Ｔ４にセットするのが妥当である。

図５のフローチャートの説明に戻る。ステップＳ１１７のバックグラウンド全スキャンを実施した後、処理はステップＳ１１８に進む。ステップＳ１１８において、アクセスポイントテーブル３１を参照しハンドオーバー先の候補となるアクセスポイント受信電界強度と切り替え閾値の大小を比較する。その比較の結果、ハンドオーバー先の候補の受信電界強度が切り替え閾値よりも小さい場合、再びバックグラウンド全スキャンを実施し、適切なアクセスポイントが現れるまで繰り返す。

その比較の結果、ハンドオーバー先の候補の受信電界強度が切り替え閾値よりも大きかった場合、処理はステップＳ１１９に進む。ステップＳ１１９において、そのハンドオーバー先の候補のアクセスポイントを正式なハンドオーバー先とした後、ステップＳ１２２に進みハンドオーバーを実施する。

ステップＳ１１５の処理の結果、Probe Responseフレームの受信レベルが、切り替え閾値以上な場合、処理はステップＳ１２０に進む。ステップＳ１２０において、ハンドオーバー先の候補としているアクセスポイントは現時点でもハンドオーバー可能なアクセスポイント先であるとみなす。この場合、ハンドオーバー先の候補の再探索はしない。ＶｏＩＰ端末７は現在通信中のアクセスポイントが使用しているチャネルに切り替える。

ステップＳ１２１において、MinChannelTime、および、MaxChannelTimeにセットする値を通常スキャン用パラメータ格納領域３３から取得し、それぞれセットする。そして、ステップＳ１２２において、ハンドオーバー先の候補のアクセスポイントへハンドオーバーを実施する。

なお、本実施例で用いた検証スキャンは、既存のＩＥＥＥ８０２．１１仕様に準拠する範囲で検証スキャンを実施するために、MinChannelTime、MaxChannelTimeを数ｍｓに減らした手段を用いて説明した。この方法以外にも、ＩＥＥＥ８０２．１１仕様の修正が必要ではあるが、例えばProbe Requestフレームにユニキャストアドレスをセットすることを許すように修正し、もしアクセスポイントが自身のアドレスがセットされたProbe Requestフレームを受信した場合、ＳＩＦＳ（Short Interframe Space）時間後にＡｃｋ（Acknowledgement）フレームを応答するような手順を許すように修正すれば、より素早く確実に検証スキャンを実施することが可能になる。

［第２実施例］
以下に、本願発明の第２実施例について説明を行う。なお、第２実施例におけるＶｏＩＰ端末７の構成は、上述の実施例と同様である。したがって、以下では重複する説明を省略する。検証スキャンは、現在通信中のアクセスポイントの受信電界強度が切り替え閾値以上の領域でも有用である。

図１０Ａ、図１０Ｂは、第２実施例の動作を例示するフローチャートである。第２実施例では、既に以前実施された全スキャンなどにより、ハンドオーバー先の候補となるアクセスポイントを保持しているものとする。

ステップＳ５０１において、閾値Ｔ３に示される秒数以上バックグラウンド全スキャンをしていないかどうかの判断を実行する。その判断の結果、閾値Ｔ３に示される秒数以上バックグラウンド全スキャンを実施していないのであれば、処理はステップＳ５０７に進む。ステップＳ５０７において、バックグラウンド全スキャンを実施する。

ステップＳ５０１の判断の結果、閾値Ｔ３に示される秒数以上バックグラウンド全スキャンを実施いる場合、処理はステップＳ５０２に進む。ステップＳ５０２において、次に上りおよび下り方向のＶｏＩＰフレームの送受信時刻より無通信となる時間を割り出し、無通信時間を見計らってハンドオーバー先の候補が使用するチャネルに切り替える。

ステップＳ５０３において、MinChannelTime、および、MaxChannelTimeにセットする値を、検証スキャン用パラメータ格納領域から取得し、それぞれにセットする。ステップＳ５０４において、Probe Requestフレームを送信する。ステップＳ５０５において、Probe Requestフレームに対する応答フレームであるProbe Responseフレームを、ハンドオーバー先の候補のアクセスポイントからMinChannelTime時間以内に受信したかどうかの判断を実行する。その判断の結果、受信しなかった場合、処理はステップＳ５０６に進む。

ステップＳ５０６において、閾値Ｔ２に示される回数以上連続してProbe Requestに対するProbe Responseを受信しなかったかどうかの判断を行う。その判断の結果、閾値Ｔ２に示される回数未満である場合は、処理はステップＳ５０４に戻り、再びProbe Requestフレームを送信する。その判断の結果、既に閾値Ｔ２に示される回数以上応答が無かった場合は、ＶｏＩＰ端末はハンドオーバー先の候補のアクセスポイントの通信可能範囲外に居るとみなし、新たに別の候補となるアクセスポイントを探す必要があるので、処理はステップＳ５０７に進む、ステップＳ５０７ではバックグラウンド全スキャンを実施する。

ステップＳ５０５の処理の結果、Probe Responseフレームを、ハンドオーバー先の候補のアクセスポイントからMinChannelTime時間以内に受信した場合、処理はステップＳ５０８に進む。ステップＳ５０８において、Probe Responseフレームの受信レベルをチェックする。

ステップＳ５０９において、その受信レベルが切り替え閾値以上であるかどうかの判断を実行する。その判断の結果、その受信レベルが切り替え閾値未満である場合、もはやＶｏＩＰ端末はそのハンドオーバー先の候補のアクセスポイントの通信可能範囲内に居ないから、処理はステップＳ５０７に進みバックグラウンド全スキャンを実施する。

受信レベルが切り替え閾値以上である場合、この場合は現在のハンドオーバー先の候補のアクセスポイントは候補として問題ないので、処理はステップＳ５１０に進み、現在のアクセスポイントのチャネルに切り換える。この場合は全スキャンなどを行ってハンドオーバー先の候補を選びなおす必要はないので、ステップＳ５１１において、MinChannelTime、MaxChannelTimeにセットする値を通常スキャン用パラメータ格納領域から取得し、それぞれに値をセットし、現在通信中のアクセスポイントの受信電界強度が切り替え閾値以上の領域における検証スキャンの処理が終了する。

［第３実施例］
以下に、本願発明の第３実施例について説明を行う。上述の第２実施例では、図１０ＢのステップＳ５０９での処理において、ハンドオーバー先の候補のアクセスポイントからの受信電界強度が切り替え閾値未満になった時点で、バックグラウンド全スキャンを実施した。いかに述べる第３実施例では、検証スキャンによって得られたハンドオーバー先の候補のアクセスポイントからの受信電界強度を記録として残し、図１０ＢのステップＳ５０９での処理において、今回得られた受信電界強度が切り替え閾値以上かどうかを調べるのみならず、前回の検証スキャン時の受信電界強度からの変化も調べそれも記録する。

例えば、前回の検証スキャンで得られた受信電界強度を第１受信電界強度Ｓ１、今回の検証スキャンで得られた受信電界強度を第２受信電界強度Ｓ２とする。次回検証スキャンを行った場合の受信電界強度（予測受信電界強度Ｓ３）は、
予測受信電界強度Ｓ３
＝第２受信電界強度Ｓ２＋（第２受信電界強度Ｓ２−第１受信電界強度Ｓ１）
と予想できる。もし予測受信電界強度Ｓ３が切り替え閾値より低い場合、たとえ第２受信電界強度Ｓ２が切り替え閾値よりも大きな値であってもバックグラウンド全スキャンを実施する。なお、第３実施例では、前回の検証スキャンの結果のみを用いて次の検証スキャンの結果を予想したが、前回の結果のみならずそれ以前の結果を用いて、次回の検証スキャンの結果の予測値の精度を向上させたものを用いても構わない。

上述してきたように、本実施例においては、ハンドオーバーが実施される前にあらかじめハンドオーバー先の候補となるアクセスポイントが有効かどうか検証スキャンを行って調べることにより、ＶｏＩＰ端末がハンドオーバー先の候補の通信可能範囲外に移動してしまった場合におけるＶｏＩＰ通話の音質に対する影響を減らすことができる。

図１１Ａ，図１１Ｂは、上述の実施例の検証スキャンを行わない場合の動作を例示するシーケンス図である。図１１Ａは、検証スキャンを行わない場合で、かつハンドオーバーを現在通信中のアクセスポイントの受信電界強度が、検出閾値となった時点でハンドオーバーを実施する場合の動作を例示している。図１１Ｂは、検証スキャンを行わない場合で、かつハンドオーバーを現在通信中のアクセスポイントの受信電界強度が切り替え閾値となった時点でハンドオーバーを実施する場合の動作を例示するシーケンス図である。図１１Ａ，図１１Ｂのシーケンスは、端末がハンドオーバー先の候補の通信可能領域の範囲外にあった場合を例示している。

図１１Ａを参照すると、現在通信中のアクセスポイントの受信電界強度が検出閾値となると、端末はAuthentication Requestフレームを送信する（１１１１，１１１２，１１１３）。このAuthentication Requestフレームの再送回数、再送間隔は実装依存であるが、Authentication Requestフレームは、アクセスポイントの端末に関する管理状態を変えるフレームであり、アクセスポイント側と端末側とで状態の不一致を避け確実に交換を行うために、比較的大きな回数の再送が行われる。

図１１Ａには、３回再送した場合を図示している。次に、全スキャンを実施し（１１１４）、その後にAuthentication Request/Responseフレーム、Association Request/Responseフレームを交換する（１１１５、１１１６、１１１７、１１１８）。図１１に示されている動作の場合は、通信中であったアクセスポイントの受信電界強度が検出閾値を下回ってからハンドオーバー処理を実行している。そのため、端末が最初のAuthentication Requestフレーム（１１１１）を送信した時点からAssociation Responseを受信（１１１８）するまでの間、端末はデータの送受信が不可能であり音切れが発生する。

図１１Ｂは、現在通信中のアクセスポイントの受信電界強度が切り替え閾値となった時点でハンドオーバーを実行する場合の動作を例示している。この場合、起点が現在通信中のアクセスポイントの受信電界強度が切り替え閾値となった時点となる。なお、それ以外は図１１Ａのシーケンスの場合と同じである。この場合も、端末がAuthentication Request（１１２１）を送信した時点から、Association Responseフレームを受信（１１２８）するまで間、端末はデータフレームを送受信することが出来ず、この間音切れが発生する。

以上より、検証スキャンを行わない場合は検証スキャンを行う場合に比べ、Authentication Requestフレームの送信および再送に要する時間、Authentication Requestフレームの再送間隔時間、および全スキャンに要する時間それぞれを加えた時間だけ長く音切れが発生する。

仮に、図１１Ｂに示される動作において、Authentication Request/Responseメッセージの交換、および全スキャンの動作が、端末のデータの送受信に影響を与えないように実施できたと仮定する。この場合の音切れ時間は、新しいハンドオーバー先の候補にAuthentication Request（１１２５）を送信してからAssociation Response（１１２８）を受信するまでの間だけとなり、検証スキャンを行う場合と行わない場合とで長さは同じになる。

しかし、何度もAuthentication Requestフレームを再送（１１２２、１１２３）すると、通信中のアクセスポイントと通信できる領域の外へ出てしまう可能性があり音切れが発生する。これを防止するために切り替え閾値をより大きな値にすると、切り替え閾値以上の受信電界強度を提供する領域が狭くなり、その結果ハンドオーバーがより頻繁に発生し、これは好ましいことではない。

上述した実施例の構成・動作を備え、まず検証スキャンを行うことによって、音切れが発生する可能性がある期間を、Authentication Requestを送信（１１０４）してから、Association Responseを受信（１１０７）するまでの期間にすることができる。

上述の実施例では、ハンドオーバーが近いと予想される事態になると、より時間的および電力的なコストの低い検証スキャンを実施し、ハンドオーバー先の候補の通信可能範囲内にあるかどうか調べている。そして、ハンドオーバー先の候補の通信可能範囲外に居ると判明した場合、現在使用しているアクセスポイントとの間で行われている通信を阻害しないように、通信の合間に利用可能なチャネルでアクセスポイントに関する情報を収集している。これにより適切なハンドオーバー先を見つけ、そこへハンドオーバーすることが可能となる。例えば、ＶｏＩＰ通話中に、ハンドオーバー候補として通信が不可能なアクセスポイントを選択してしまうことで音切れが発生してしまうことを減らすことが可能となる。

また、上述の実施例では、ハンドオーバー先の候補のアクセスポイントを調べる際に検証スキャンを織り交ぜることで、全スキャンを行う頻度を減らして消費電力を下げることが可能となる。また、ハンドオーバー先の候補のアクセスポイントの妥当性のチェックをより頻繁に行うことが可能となる。妥当性のチェックをより頻繁に行えば、それだけハンドオーバー先の候補のアクセスポイントがより妥当なものとなる。したがって、例えば、ＶｏＩＰ通話中に、ハンドオーバーに失敗する確率が減ることになり、ハンドオーバー時のＶｏＩＰ通話の音質の劣化を避けることができる。

なお、当業者は上記実施例の様々な変形を容易に実施することができる。したがって、本発明は上記実施例に限定されることはなく、請求項やその均等物によって参酌される最も広い範囲で解釈される。

Claims (26)

1. 無線を使用してデータを送受信するデータ送受信部と、
   利用可能なすべての無線チャネルでハンドオーバー先の存在の有無をスキャンするハンドオーバー制御部と
   を具備し、
   前記ハンドオーバー制御部は、
   ハンドオーバー実行前に事前にハンドオーバー先の存在の有無をスキャンすることによりハンドオーバー先の候補を取得し、
   前記候補が、端末から通信可能範囲内にあるか調べるために検証スキャンを実行し、
   前記検証スキャンの実行結果に基づいて、前記候補にハンドオーバーを行う
   無線端末。
2. 請求の範囲１に記載の無線端末において、
   前記データ送受信部と前記ハンドオーバー制御部とは、無線ＬＡＮドライバに備えられ、
   前記無線ＬＡＮドライバは、
   前記データの送受信と前記検証スキャンとを時分割で実行する
   無線端末。
3. 請求の範囲１に記載の無線端末において、
   前記ハンドオーバー制御部は、
   前記データの周期性を利用して前記データの発生しない期間を前もって予測し、前記データの発生しない期間であると予測された予測期間に前記検証スキャンを実行する
   無線端末。
4. 請求の範囲１に記載の無線端末において、
   前記ハンドオーバー制御部は、
   前記ハンドオーバー先の候補が存在するかどうか調べるためのフレームを送信し、送信した前記フレームに対する応答フレームの受信の有無により、前記ハンドオーバー先の候補が通信可能範囲内にあるかどうかを調べる
   無線端末。
5. 請求の範囲４に記載の無線端末において、
   前記ハンドオーバー先の候補が通信可能範囲内にあるか否かを判断する条件として、
   ある閾値回数以上前記検証スキャンを実施しても前記ハンドオーバー先の候補からの前記応答フレームが受信されない場合、前記端末は前記ハンドオーバー先の候補の通信範囲外にあると判断する
   無線端末。
6. 請求の範囲４に記載の無線端末において、
   前記検証スキャンを行う際に使用する前記ハンドオーバー先の候補が存在するかどうかを調べるためのフレームおよび前記応答フレームとしてＩＥＥＥ８０２．１１仕様で規定されるＰｒｏｂｅ ＲｅｑｕｅｓｔフレームおよびＰｒｏｂｅ Ｒｅｓｐｏｎｓｅフレームを使用する
   無線端末。
7. 請求の範囲６に記載の無線端末において、
   前記Ｐｒｏｂｅ Ｒｅｑｕｅｓｔフレームを送信した送信時刻から、前記Ｐｒｏｂｅ Ｒｅｓｐｏｎｓｅフレームを受信するために最低限待機しなければならない最低待機時間と、前記Ｐｒｏｂｅ Ｒｅｓｐｏｎｓｅフレームを１以上の受信した場合に適用される待機時間とを、
   前記データの送受信を阻害しない程度に小さな値にセットする
   無線端末。
8. 請求の範囲１記載の無線端末において、
   前記ハンドオーバー制御部は、
   前記検証スキャンの開始条件として、
   前記ハンドオーバー先の候補を決定した候補決定時刻から、所定の閾値時間を越えた場合に、前記検証スキャンを実施する
   無線端末。
9. 請求の範囲１に記載の無線端末において、
   前記ハンドオーバー制御部は、
   前記検証スキャンの開始判断に、前記データの受信電界強度を用いる
   無線端末。
10. 請求の範囲９に記載の無線端末において、
    前記検証スキャンの開始条件として、
    前記無線ＬＡＮシステムにおいて通信が可能な受信電界強度の最小値よりも大きな値を閾値とし、
    前記端末が通信中のアクセスポイントの受信電界強度が前記閾値未満となることを条件とする
    無線端末。
11. 請求の範囲１０に記載の無線端末において、
    前記ハンドオーバー制御部は、
    前記検証スキャン後の前記ハンドオーバー先の候補が通信可能範囲内にあるかどうかを判断し、前記ハンドオーバー先の候補からの前記応答フレームを受信した際の受信電界強度が、前記受信電界強度の最小値よりも大きな値とした閾値よりも小さい場合、前記無線ＬＡＮ端末の通信を阻害しないように利用可能なすべての無線チャネルをスキャンしてハンドオーバー先の候補を再探索する
    無線端末。
12. 請求の範囲１０に記載の無線端末において、
    前記ハンドオーバー制御部は、
    前記検証スキャンの開始条件を満たしていない場合に前記検証スキャンを実施して、以前に見つけた前記ハンドオーバー先の通信可能範囲内に前記端末が居ないと判明した場合に、前記利用可能なすべての無線チャネルをスキャンして前記ハンドオーバー先の候補を見つける
    無線端末。
13. 請求の範囲１０に記載の無線端末において、
    前記ハンドオーバー制御部は、
    前記検証スキャンの開始条件を満たしていない場合に前記検証スキャンを実施して、以前に見つけた前記ハンドオーバー先の通信可能範囲内から前記端末が近い将来外れると判断した場合に、前記利用可能なすべての無線チャネルをスキャンして前記ハンドオーバー先の候補を見つける
    無線端末。
14. 無線を使用してデータを送受信するデータ送受信機能と、利用可能なすべての無線チャネルでハンドオーバー先の存在の有無をスキャンする機能とを備える無線ＬＡＮシステムのハンドオーバー方法であって、
    （ａ）ハンドオーバー実行前に事前にハンドオーバー先の存在の有無をスキャンすることによりハンドオーバー先の候補を取得するステップと、
    （ｂ）前記候補先が、端末から通信可能範囲内にあるか調べるために検証スキャンを実行するステップと、
    （ｃ）前記検証スキャンの実行結果に基づいて、前記候補にハンドオーバーを行うステップ
    を具備する
    ハンドオーバー方法。
15. 請求の範囲１４に記載のハンドオーバー方法において、
    前記データの送受信と前記検証スキャンとを時分割で行う
    ハンドオーバー方法。
16. 請求の範囲１４に記載のハンドオーバー方法において、
    前記（ｂ）ステップは、
    前記データの周期性を利用して前記データの発生しない期間を前もって予測するステップと、
    前記データの発生しない期間であると予測された予測期間に前記検証スキャンを行うステップと
    を含む
    ハンドオーバー方法。
17. 請求の範囲１４に記載のハンドオーバー方法において、
    前記（ｂ）ステップは、
    前記ハンドオーバー先の候補が存在するかどうか調べるためのフレームを送信するステップと、
    前記ハンドオーバー先の候補からの応答フレームの受信を待機するステップと、
    前記ハンドオーバー先の候補からの応答フレームの受信の有無により、前記ハンドオーバー先の候補の通信可能範囲内にあるかどうかを調べるステップ
    を含む
    ハンドオーバー方法。
18. 請求の範囲１７に記載のハンドオーバー方法において、
    前記端末が前記ハンドオーバー先の候補の通信可能範囲内にあるか否かを判断する条件として、
    ある閾値回数以上前記検証スキャンを実施しても前記ハンドオーバー先の候補からの前記応答フレームが受信されない場合、前記端末は前記ハンドオーバー先の候補の通信範囲外にあると判断する
    ハンドオーバー方法。
19. 請求の範囲１７に記載のハンドオーバー方法において、
    ＩＥＥＥ８０２．１１仕様で規定されるＰｒｏｂｅ ＲｅｑｕｅｓｔフレームおよびＰｒｏｂｅ Ｒｅｓｐｏｎｓｅフレームを、前記検証スキャンを行う際に使用する前記ハンドオーバー先の候補が存在するかどうかを調べるためのフレームおよび前記応答フレームとして使用する
    ハンドオーバー方法。
20. 請求の範囲１９に記載のハンドオーバー方法において、
    前記Ｐｒｏｂｅ Ｒｅｑｕｅｓｔフレームを前記端末が送信した送信時刻から、前記Ｐｒｏｂｅ Ｒｅｓｐｏｎｓｅフレームを受信するために最低限待機しなければならない最低待機時間と、
    前記Ｐｒｏｂｅ Ｒｅｓｐｏｎｓｅフレームを１以上の受信した場合に適用される待機時間とを、
    前記端末の、前記データの送受信を阻害しない程度に小さな値にセットする
    ハンドオーバー方法。
21. 請求の範囲１４に記載のハンドオーバー方法において、
    前記（ｂ）ステップは、
    前記検証スキャンの開始条件として、
    前記ハンドオーバー先の候補を決定した候補決定時刻から、所定の閾値時間を越えた場合に、前記検証スキャンを実施するステップを含む
    ハンドオーバー方法。
22. 請求の範囲１４に記載のハンドオーバー方法において、
    前記検証スキャンの開始判断に、
    前記データの受信電界強度を用いる
    ハンドオーバー方法。
23. 請求の範囲２２に記載のハンドオーバー方法において、
    前記検証スキャンの開始条件として、
    前記無線ＬＡＮシステムにおいて通信が可能な受信電界強度の最小値よりも大きな値を閾値とし、
    前記端末が通信中のアクセスポイントの受信電界強度が前記閾値未満となることを条件とする
    ハンドオーバー方法。
24. 請求の範囲２３に記載のハンドオーバー方法において、さらに、
    （ｄ）前記検証スキャン後の前記ハンドオーバー先の候補が通信可能範囲内にあるかどうかを判断するステップを含み
    前記（ｄ）ステップは、
    前記ハンドオーバー先の候補からの前記応答フレームを受信した際の受信電界強度が、
    前記受信電界強度の最小値よりも大きな値とした閾値よりも小さい場合、前記無線ＬＡＮ端末の通信を阻害しないように利用可能なすべての無線チャネルをスキャンし、
    ハンドオーバー先の候補を再探索する
    ハンドオーバー方法。
25. 請求の範囲２３に記載のハンドオーバー方法において、さらに、
    （ｅ）前記検証スキャンの開始条件を満たしていない場合で前記ハンドオーバー先の候補を見つけるステップを含み、
    前記（ｅ）ステップは、
    前記検証スキャンを実施して、以前に見つけた前記ハンドオーバー先の通信可能範囲内に前記端末が居ないと判明した場合に、前記利用可能なすべての無線チャネルをスキャンして前記ハンドオーバー先の候補を見つける
    ハンドオーバー方法。
26. 請求の範囲２３に記載のハンドオーバー方法において、さらに、
    （ｆ）前記検証スキャンの開始条件を満たしていない場合で前記ハンドオーバー先の候補を見つけるステップを含み、
    前記（ｆ）ステップは、
    前記検証スキャンを実施して、以前に見つけた前記ハンドオーバー先の通信可能範囲内から前記端末が近い将来外れると判断した場合に、前記利用可能なすべての無線チャネルをスキャンして前記ハンドオーバー先の候補を見つける
    ハンドオーバー方法。

Images