(57)【要約】【課題】端末が他のアクセスポイントへローミングするための情報を収集することが可能なアクセスポイントを提供する。【解決手段】端末の、省電力状態から通常状態に移行させるＷＵＲ（Ｗａｋｅ Ｕｐ Ｒａｄｉｏ）機能と通信する、ＩＥＥＥ８０２．１１ｂａに対応したアクセスポイントとして動作する通信装置は、他のアクセスポイントから、当該他のアクセスポイントのＷＵＲに関する情報を収集し、収集した他のアクセスポイントのＷＵＲに関する情報を端末に通知する。【選択図】  図１
2020184700.tif 000002
【特許請求の範囲】
【請求項１】
端末の省電力状態から通常状態に移行させるＷＵＲ（Ｗａｋｅ−Ｕｐ Ｒａｄｉｏ）機能と通信する、ＩＥＥＥ８０２．１１ｂａに対応したアクセスポイントとして動作する通信装置であって、
他のアクセスポイントから、前記他のアクセスポイントのＷＵＲに関する情報を収集する収集手段と、
前記収集手段により収集された前記他のアクセスポイントのＷＵＲに関する情報を端末に通知する通知手段と、を備えることを特徴とする通信装置。
【請求項２】
前記収集手段は、ＤＳＳ（Ｄｉｓｔｒｉｂｕｔｉｏｎ Ｓｙｓｔｅｍ Ｓｅｒｖｉｃｅ）を用いて他のアクセスポイントと通信することによりＷＵＲに関する情報を収集することを特徴とする請求項１に記載の通信装置。
【請求項３】
前記収集手段は、Ｗｉ−ＦｉのＭｕｌｔｉ−ＡＰにおいて規定されている、ＣｏｎｔｒｏｌｌｅｒとＡｇｅｎｔの間の情報交換手順の拡張を用いることを特徴とする請求項２に記載の通信装置。
【請求項４】
前記収集手段は、他のアクセスポイントとの間でＩＥＥＥ８０２．１１シリーズ規格に準拠した通信を行うことによりＷＵＲに関する情報を収集することを特徴とする請求項１乃至３のいずれか１項に記載の通信装置。
【請求項５】
前記収集手段は、他のアクセスポイントから受信したＩＥＥＥ８０２．１１シリーズ規格に準拠したＢｅａｃｏｎから、ＷＵＲに関する情報を取得することを特徴とする請求項４に記載の通信装置。
【請求項６】
前記収集手段は、ＩＥＥＥ８０２．１１シリーズ規格に準拠したＰｒｏｂｅ Ｒｅｑｕｅｓｔの送信に応じて他のアクセスポイントから受信されたＰｒｏｂｅ Ｒｅｓｐｏｎｓｅから、ＷＵＲに関する情報を取得することを特徴とする請求項４または５に記載の通信装置。
【請求項７】
前記収集手段は、他のアクセスポイントからＷＵＲ Ｄｉｓｃｏｖｅｒｙ ｆｒａｍｅを受信することにより、ＷＵＲに関する情報を取得することを特徴とする請求項１乃至６のいずれか１項に記載の通信装置。
【請求項８】
前記収集手段は、自身がＷＵＲサービスを提供するための送信処理が行われない期間に、他のアクセスポイントからのＷＵＲ Ｄｉｓｃｏｖｅｒｙ ｆｒａｍｅをスキャンすることを特徴とする請求項７に記載の通信装置。
【請求項９】
前記通知手段は、Ｂｅａｃｏｎに前記他のアクセスポイントのＷＵＲに関する情報を含めて、端末に向けて送信することを特徴とする請求項１乃至８のいずれか１項に記載の通信装置。
【請求項１０】
前記通知手段が通知する前記他のアクセスポイントのＷＵＲに関する情報は、少なくともＷＵＲの機能を有する他のアクセスポイントの数を含むことを特徴とする請求項１乃至９のいずれか１項に記載の通信装置。
【請求項１１】
前記通知手段が通知する前記他のアクセスポイントのＷＵＲに関する情報は、ＷＵＲの機能を有する他のアクセスポイントがＷＵＲ Ｄｉｓｃｏｖｅｒｙ Ｆｒａｍｅの送信に使用するチャネルを示す情報を含むことを特徴とする請求項１乃至１０のいずれか１項に記載の通信装置。
【請求項１２】
省電力状態から通常状態に移行させるＷＵＲ（Ｗａｋｅ Ｕｐ Ｒａｄｉｏ）機能を有する、ＩＥＥＥ８０２．１１ｂａに対応した端末として動作する通信装置であって、
接続しているアクセスポイントから、他のアクセスポイントのＷＵＲに関する情報の通知を受信する受信手段と、
前記接続しているアクセスポイントから他のアクセスポイントへローミングするローミング手段と、
前記受信手段により受信した他のアクセスポイントのＷＵＲに関する情報に基づいて、前記ローミング手段によるローミング先となるアクセスポイントを決定する決定手段と、を備えることを特徴とする通信装置。
【請求項１３】
前記ＷＵＲに関する情報は、前記接続しているアクセスポイントからのＢｅａｃｏｎに含まれていることを特徴とする請求項１２に記載の通信装置。
【請求項１４】
前記ローミング手段は、前記アクセスポイントからＷＵＲ Ｂｅａｃｏｎを受信できなくなった場合に、他のアクセスポイントへローミングすることを特徴とする請求項１２または１３に記載の通信装置。
【請求項１５】
端末の省電力状態から通常状態に移行させるＷＵＲ（Ｗａｋｅ Ｕｐ Ｒａｄｉｏ）機能と通信する、ＩＥＥＥ８０２．１１ｂａに対応したアクセスポイントとして動作する通信装置の制御方法であって、
他のアクセスポイントから、前記他のアクセスポイントのＷＵＲに関する情報を収集する収集工程と、
接続している端末に、前記収集工程により収集された前記他のアクセスポイントのＷＵＲに関する情報を通知する通知工程と、を備えることを特徴とする通信装置の制御方法。
【請求項１６】
省電力状態から通常状態に移行させるＷＵＲ（Ｗａｋｅ Ｕｐ Ｒａｄｉｏ）機能を有する、ＩＥＥＥ８０２．１１ｂａに対応した端末として動作する通信装置の制御方法であって、
接続しているアクセスポイントから、他のアクセスポイントのＷＵＲに関する情報の通知を受信する受信工程と、
前記接続しているアクセスポイントから他のアクセスポイントへローミングするローミング工程と、
前記受信工程により受信した他のアクセスポイントのＷＵＲに関する情報に基づいて、前記ローミング工程によるローミング先となるアクセスポイントを決定する決定工程と、を備えることを特徴とする通信装置の制御方法。
【請求項１７】
コンピュータを請求項１乃至１４のいずれか１項に記載された通信装置の各手段として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、無線通信を行う通信装置及びその制御方法に関する。
【背景技術】
【０００２】
近年、ＩＥＥＥ（米国電気電子技術者協会）では、ＩＥＥＥ８０２．１１ｂａ規格が検討されている。ＩＥＥＥ８０２．１１ｂａ規格では、省電力性を向上させるため、ＲＦ（Ｒａｄｉｏ Ｆｒｅｑｕｅｎｃｙ）回路であるＰＣＲ（Ｐｒｉｍａｒｙ Ｃｏｎｎｅｃｔｉｖｉｔｙ Ｒａｄｉｏ）とは別に、ＷＵＲ（Ｗａｋｅ−Ｕｐ Ｒａｄｉｏ）回路を設けている。ＷＵＲ回路が無線フレームを受信したときに、ＰＣＲを省電力状態から通常状態に移行させることで、省電力機能を実現している。（特許文献１）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】米国特許出願公開第２０１８／０２４２２４９号明細書
【発明の概要】
【発明が解決しようとする課題】
【０００４】
端末が、第１のアクセスポイントにおいてＷａｋｅ−ｕｐを実行できないことを知った時に、第２のアクセスポイントと接続する（ローミング）ことが考えらえる。しかし、端末が第２のアクセスポイントに接続するための情報を、第１のアクセスポイントまたは端末が把握する方法についての提案は今のところ存在しない。
【０００５】
本発明は、端末が接続中のアクセスポイントから他のアクセスポイントへローミングするための情報を収集することを可能とする技術を提供する。
【課題を解決するための手段】
【０００６】
本発明の一態様による通信装置は以下の構成を備える。すなわち、
端末の、動作状態を省電力状態から通常状態に移行させるＷＵＲ（Ｗａｋｅ−Ｕｐ Ｒａｄｉｏ）機能と通信する、ＩＥＥＥ８０２．１１ｂａに対応したアクセスポイントとして動作する通信装置であって、
他のアクセスポイントから、前記他のアクセスポイントのＷＵＲに関する情報を収集する収集手段と、
前記収集手段により収集された前記他のアクセスポイントのＷＵＲに関する情報を端末に通知する通知手段と、を備える。
【発明の効果】
【０００７】
本発明によれば、端末が他のアクセスポイントへローミングするための情報を収集することが可能なアクセスポイントが提供される。
【図面の簡単な説明】
【０００８】
【図１】実施形態による通信システムの構成例を示す図。
【図２】実施形態による通信装置のハードウェア構成例を示すブロック図。
【図３】ｍａｎａｇｅｍｅｎｔ ｆｒａｍｅに含むことのできるＩＥＥＥ８０２．１１ｂａ関連の情報要素を示す図。
【図４Ａ】ＷＵＲ Ｄｉｓｃｏｖｅｒｙ ｅｌｅｍｅｎｔを説明する図。
【図４Ｂ】ＷＵＲ  Ｄｉｓｃｏｖｅｒｙ  ｅｌｅｍｅｎｔを説明する図。
【図５Ａ】ＷＵＲ Ｄｉｓｃｏｖｅｒｙ ｆｒａｍｅを説明する図。
【図５Ｂ】ＷＵＲ  Ｄｉｓｃｏｖｅｒｙ  ｆｒａｍｅを説明する図。
【図６Ａ】実施形態による無線通信の動作シーケンスを示す図。
【図６Ｂ】実施形態による無線通信の動作シーケンスを示す図。
【図６Ｃ】実施形態による無線通信の動作シーケンスを示す図。
【図７】ＡＰ管理テーブルの例を示す図。
【図８Ａ】実施形態のＡＰによる処理を説明するフローチャート。
【図８Ｂ】実施形態のＡＰによる処理を説明するフローチャート。
【図８Ｃ】実施形態のＡＰによる処理を説明するフローチャート。
【図８Ｄ】実施形態のＡＰによる処理を説明するフローチャート。
【図８Ｅ】実施形態のＡＰによる処理を説明するフローチャート。
【発明を実施するための形態】
【０００９】
以下、添付図面を参照して実施形態を詳しく説明する。尚、以下の実施形態は特許請求の範囲に係る発明を限定するものではない。実施形態には複数の特徴が記載されているが、これらの複数の特徴の全てが発明に必須のものとは限らず、また、複数の特徴は任意に組み合わせられてもよい。さらに、添付図面においては、同一若しくは同様の構成に同一の参照番号を付し、重複した説明は省略する。
【００１０】
実施形態では、アクセスポイントが、省電力機構が動作するステーションがローミングを行うための情報、すなわち、別のアクセスポイントへ接続を切替えるための情報を収集、取得する。
【００１１】
図１は、本実施形態に係る通信システムの構成と無線ネットワークを示す図である。ＡＰ１０１およびＡＰ１０２は、ＩＥＥＥ８０２．１１ｂａ対応のアクセスポイントである。なお、以下では、アクセスポイントをＡＰと記載する。これらの二つのＡＰは、同じＥＳＳＩＤ（Ｅｘｔｅｎｄｅｄ Ｓｅｒｖｉｃｅ Ｓｅｔ ＩＤｅｎｔｉｆｉｅｒ）を備えるものとする。ＳＴＡ１１０は、ＩＥＥＥ８０２．１１ｂａ対応の無線端末（ステーション）である。本明細書では、アクセスポイントとステーションをそれぞれＡＰ、ＳＴＡと記すこともある。なお、説明の簡略化のために、図示はしないが、この他に同様なアクセスポイントが存在する。また、ＡＰ１０１やＡＰ１０２を介してＳＴＡ１１０と通信する無線端末または有線端末も存在する。
【００１２】
図２に、８０２．１１ｂａ対応のＡＰ１０１、ＡＰ１０２と、ＩＥＥＥ８０２．１１ｂａ対応のＳＴＡ１１０に共通なハードウェアの構成例を示す。
【００１３】
記憶部２０１はＲＯＭやＲＡＭ等のメモリにより構成され、後述する各種動作を行うためのプログラムや、無線通信のための通信パラメータ等の各種情報を記憶する。なお、記憶部２０１として、ＲＯＭ、ＲＡＭ等のメモリの他に、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＤＶＤなどの記憶媒体が用いられてもよい。また、記憶部２０１が複数のメモリ等を備えていてもよい。
【００１４】
制御部２０２はＣＰＵやＭＰＵ等のプロセッサにより構成され、記憶部２０１に記憶されたプログラムを実行することにより、１０１、１０２、１０３、１０４のそれぞれの端末を制御する。なお、制御部２０２は、記憶部２０１に記憶されたプログラムとＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）との協働により、それぞれの端末を制御するようにしてもよい。また、制御部２０２がマルチコア等の複数のプロセッサから成り、それぞれの端末を制御するようにしてもよい。また、制御部２０２は、機能部２０３を制御して、アクセスポイント機能、撮像や印刷、投影等の所定の処理を実行する。機能部２０３は、それぞれの端末が所定の処理を実行するためのハードウェアである。
【００１５】
入力部２０４は、ユーザからの各種操作の受付を行う。出力部２０５は、ユーザに対して各種出力を行う。ここで、出力部２０５による出力とは、画面上への表示や、スピーカによる音声出力、振動出力等の少なくとも一つを含む。なお、タッチパネルのように入力部２０４と出力部２０５の両方を１つのモジュールで実現するようにしてもよい。
【００１６】
通信部２０６は、ＩＥＥＥ８０２．１１シリーズ規格やＷｉ−Ｆｉに準拠した無線通信の制御、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）通信の制御、等をおこなう。さらに詳しく言えば、通信部２０６は、ＰＣＲ制御部２０７またはＷＵＲ制御部２０８を切り替えることにより、８０２．１１ｂaに対応するＡＰ／ＳＴＡとして動作可能になっている。ＰＣＲは、Ｐｒｉｍａｒｙ Ｃｏｎｎｅｃｔｉｖｉｔｙ Ｒａｄｉｏの略であり、ＷＵＲはＷａｋｅ−Ｕｐ Ｒａｄｉｏの略である。一般に、ＩＥＥＥ８０２．１１ｂａ対応のＡＰはＷＵＲの送信機能のみ、ＳＴＡはＷＵＲの受信機能のみを動作させる。よって、ＡＰ専用、または、ＳＴＡ専用のハードウェア構成では、ＷＵＲ制御部２０８が、送信のみ、または、受信のみとなる。図２は、説明の簡略化のために、共通なものとして示している。さらに、通信部２０６はアンテナ２０９を制御して、無線通信のための無線信号の送受信を行う。
【００１７】
なお、本明細書で言及するＰＣＲは新規のハードウェアブロックではない。よって、特別に名称を用いることなく、「ＰＣＲ制御部２０７」を「従来の８０２．１１制御部２０７」と称してもよい。同様に、本明細書中の「ＰＣＲ」を「従来の８０２．１１」と称してもよい。ここで、「従来の」とは、「８０２．１１ｂａのＷＵＲに対応していない」という意味である。
【００１８】
２１０は、Ｅｔｈｅｒｎｅｔ（登録商標）や公衆回線とのインタフェースである。これは、アクセスポイントとして動作するときに有効になる部分である。そのため、ＳＴＡの場合には、インタフェース２１０は存在しない。
【００１９】
図３は、ＩＥＥＥ８０２．１１のマネージメントフレーム（例えば、Ｂｅａｃｏｎ、Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔ、など）の各々に含めることのできるＩＥＥＥ８０２．１１ｂａ関連の情報要素を示す。これらのフレームを送受信することで、ＡＰと端末は、８０２．１１ｂａ動作のために必要な情報を得ている。以下、各情報要素の概要を示す。
【００２０】
ＷＵＲ Ｃａｐａｂｉｌｉｔｉｅｓとは、ＷＵＲのＳＴＡの能力を示す情報要素である。ＷＵＲ Ｃａｐａｂｉｌｉｔｉｅｓには、たとえば、「２．４ＧＨｚ」と「４．９ ａｎｄ ５ＧＨｚ」のそれぞれに対して、ＰＣＲの省電力状態から通常状態への遷移までに要する遷移時間がある。
【００２１】
ＷＵＲ Ｏｐｅｒａｔｉｏｎは、ＡＰからＳＴＡに対して、ＷＵＲの動作状況を通知するためのものである。ＷＵＲ Ｏｐｅｒａｔｉｏｎには、たとえば、ＷＵＲ Ｃｈａｎｎｅｌ（ＷＵＲ Ｂｅａｃｏｎが報知されるチャネル）やＷＵＲ Ｂｅａｃｏｎ Ｐｅｒｉｏｄがある。なお、本明細書では、「Ｃｈａｎｎｅｌ」を「ｃｈ」や「チャネル」と表記することがある。
【００２２】
ＷＵＲ Ｄｉｓｃｏｖｅｒｙは、ＡＰが、「当該ＡＰ」と「他のＡＰ」のＷＵＲの動作チャネル（ＷＵＲ Ｄｉｓｃｏｖｅｒｙ Ｃｈａｎｎｅｌ）を通知するためのものである。この情報によってＳＴＡは、複数のＡＰについての動作チャネルを把握した上で、Ｂｅａｃｏｎを待ち受けたり、Ｐｒｏｂｅ Ｒｅｑｕｅｓｔを送信したりして、ＡＰを発見（Ｄｉｓｃｏｖｅｒｙ）することができる。
【００２３】
続いて図４Ａ、図４Ｂを参照して、ＷＵＲ Ｄｉｓｃｏｖｅｒｙに関するＩｎｆｏｒｍａｔｉｏｎ ｅｌｅｍｅｎｔ（情報要素）のフレーム詳細を説明する。この情報要素は、複数のＡＰについてのＷＵＲ Ｄｉｓｃｏｖｅｒｙ ｆｒａｍｅのチャネルに関する情報を含んでいる。これを受信した端末は、そのＣｈａｎｎｅｌ（チャネル）で待ち受けて（スキャンし）、受信したＷＵＲ Ｄｉｓｃｏｖｅｒｙ ｆｒａｍｅ中に含まれるＰＣＲのチャネルを把握できる。
【００２４】
図４Ａの（ａ）において、４００は、情報要素（Ｉｎｆｏｒｍａｔｉｏｎ Ｅｌｅｍｅｎｔ）の全体構成を示す。４０１は、Ｅｌｅｍｅｎｔ ＩＤであり、たとえば、ＳＳＩＤ（Ｓｅｒｖｉｃｅ Ｓｅｔ Ｉｄｅｎｔｉｆｉｅｒ）は０（ゼロ）、ＷＵＲに関する情報要素は２５５の値を持つ。４０２は、情報要素のＬｅｎｇｔｈ（長さ）である。４０３は、Ｅｌｅｍｅｎｔ ＩＤ Ｅｘｔｅｎｓｉｏｎである。ＷＵＲについては、Ｃａｐａｂｉｌｉｔｉｅｓが４８、Ｏｐｅｒａｔｉｏｎが４９、Ｍｏｄｅが５０、Ｄｉｓｃｏｖｅｒｙが５１となる（図４Ａの（ｂ）を参照）。４０４は、Ｉｎｆｏｒｍａｔｉｏｎ（情報要素の内容）であり、長さは内容に応じて可変である。Ｉｎｆｏｒｍａｔｉｏｎ４０４の詳細は、図４Ｂに三段構成で示している。Ｉｎｆｏｒｍａｔｉｏｎ  ４０４をＷＵＲ Ｄｉｓｏｃｅｒｙ ｅｌｅｍｅｎｔとも称する。
【００２５】
図４Ｂにおいて、４１１はＷＵＲ Ｄｉｓｃｏｖｅｒｙ Ｏｐｅｒａｔｉｎｇ Ｃｌａｓｓであり、ＷＵＲ Ｄｉｓｃｏｖｅｒｙ ｆｒａｍｅ用のｃｌａｓｓ値のＩＥＥＥ８０２．１１規格上の表現である。これは、図５Ｂにより後述するＯｐｅｒａｔｉｎｇ Ｃｌａｓｓ５３１のどれかの値となる。４１２はＷＵＲ Ｄｉｓｃｏｖｅｒｙ Ｃｈａｎｎｅｌであり、ＷＵＲ Ｄｉｓｃｏｖｅｒｙ ｆｒａｍｅ用のチャネルを示す。４１３はＷＵＲ ＡＰ Ｃｏｕｎｔであり、後述するＷＵＲ ＡＰ Ｌｉｓｔ４１４に含まれるＷＵＲ ＡＰ Ｐａｒａｍｅｔｅｒｓの数から、１を引いた数である。この値が０（ゼロ）のときは、一つのＷＵＲ ＡＰ Ｐａｒａｍｅｔｅｒｓが存在することを示す。４１４はＷＵＲ ＡＰ Ｌｉｓｔであり、後述する一つ以上のＷＵＲ ＡＰ Ｐａｒａｍｅｔｅｒｓを含む。
【００２６】
なお、Ｉｎｆｏｒｍａｔｉｏｎ４０４は、ＷＵＲが使用するチャンネルごとに生成される。例えば、後述の図７の場合、ＷＵＲ Ｄｉｓｃｏｖｅｒｙ Ｃｈａｎｎｅｌ（項目７０３）が５種類あるので、情報要素４００は５つのＩｎｆｏｒｍａｔｉｏｎ４０４を含むことになる。そして、ＷＵＲ Ｄｉｓｃｏｖｅｒｙ Ｃｈａｎｎｅｌ＝１５３のＩｎｆｏｒｍａｔｉｏｎ４０４では、ＷＵＲ ＡＰ Ｃｏｕｎｔ４１３が３になり、ＷＵＲ ＡＰ Ｌｉｓｔ４１４には４つのＡＰがリストされる。
【００２７】
ＷＵＲ ＡＰ Ｌｉｓｔ４１４に含まれるＷＵＲ ＡＰ Ｐａｒａｍｅｔｅｒｓは、以下の４つのフィールドから成る。４２１は、ＷＵＲ ＡＰ Ｐａｒａｍｅｔｅｒｓ Ｃｏｎｔｒｏｌであり、後に続く３つの項目の有無を示す。４２２はＳｈｏｒｔ−ＳＳＩＤである。これは、ＳＳＩＤから計算される３２ｂｉｔ数であり、ＩＥＥＥ ８０２．１１ａｉ規格で規定されている。４２３はＢＳＳＩＤ（Ｂａｓｉｃ Ｓｅｒｖｉｃｅ Ｓｅｔ Ｉｄｅｎｔｉｆｉｅｒ）である。４２４は、ＷＵＲ Ｄｉｓｃｏｖｅｒｙ Ｐｅｒｉｏｄであり、ＷＵＲ Ｄｉｓｃｏｖｅｒｙ ｆｒａｍｅが送信される時間間隔（単位は、ＴＵ：Ｔｉｍｅ Ｕｎｉｔ）である。
【００２８】
次に、ＷＵＲ ＡＰ Ｐａｒａｍｅｔｅｒｓ Ｃｏｎｔｒｏｌ４２１サブフィールドの詳細を説明する。４３１はＴｒａｎｓｍｉｔｔｉｎｇ ＷＵＲ ＡＰであり、この情報要素を送信しているＡＰについての情報であるときは１、それ以外は０となる１ビットの値である。４３２はＳｈｏｒｔ−ＳＳＩＤ Ｐｒｅｓｅｎｔであり、Ｓｈｏｒｔ−ＳＳＩＤ４２２に４オクテット（４バイト、または、３２ビット）のＳｈｏｒｔ−ＳＳＩＤが含まれる場合は１となる。４３３はＢＳＳＩＤ Ｐｒｅｓｅｎｔであり、ＢＳＳＩＤ４２３に６オクテットのＢＳＳＩＤが含まれる場合は１、それ以外は０となる。４３４はＷＵＲ Ｄｉｓｃｏｖｅｒｙ Ｐｅｒｉｏｄ Ｐｒｅｓｅｎｔであり、ＷＵＲ Ｄｉｓｃｏｖｅｒｙ Ｐｅｒｉｏｄ４２４に２オクテットの値が含まれる場合は１、それ以外は０となる。４３５はＲｅｓｅｒｖｅｄであり、未使用の４ビット領域である。
【００２９】
次に、ＷＵＲ機能により送信されるＷＵＲ Ｄｉｓｃｏｖｅｒｙ ｆｒａｍｅについて説明する。図５Ａは、ＷＵＲ Ｄｉｓｃｏｖｅｒｙ ｆｒａｍｅのデータ構成例を示す図である。図５Ａにおいて、５０１から５０５は、ＩＥＥＥ８０２．１１ｂａで新たに規定されたフレームの共通構成である。
【００３０】
５０１はＦｒａｍｅ Ｃｏｎｔｒｏｌ（８ビット）であり、その詳細は、後述する。５０２はＩＤ（１２ビット）であり、ＷＵＲフレームのｔｙｐｅ５１１によって値が定まる。たとえば、ＷＵＲ Ｄｉｓｃｏｖｅｒｙ ｆｒａｍｅの場合は、このフレームを送信したＴｒａｎｓｍｉｔｔｅｒ ＩＤとなる。５０３はＴｙｐｅ Ｄｅｐｅｎｄｅｎｔ Ｃｏｎｔｒｏｌ（１２ビット）である。５０４はＦｒａｍｅ Ｂｏｄｙ（可変長）である。５０５はＦＣＳ（Ｆｒａｍｅ Ｃｈｅｃｋ Ｓｅｑｕｅｎｃｅ）（１６ビット）である。
【００３１】
５１１から５１４は、Ｆｒａｍｅ Ｃｏｎｔｒｏｌ５０１の詳細を示しており、ＭＡＣ ｈｅａｄｅｒとも称される。５１１はＴｙｐｅ（３ビット）であり、その詳細を図５Ｂの（ａ）に示す。本実施形態と関連するＷＵＲ Ｄｉｓｃｏｖｅｒｙ ｆｒａｍｅでは、Ｔｙｐｅ５１１が「３」となっている。５１２はＬｅｎｇｔｈ Ｐｒｅｓｅｎｔ（１ビット）であり、後続のＬｅｎｇｔｈ／ＭｉｓｃがＬｅｎｇｔｈを示すか否かを示す。５１３はＬｅｎｇｔｈ／Ｍｉｓｃ（１ビット）であり、Ｌｅｎｇｔｈ Ｐｒｅｓｅｎｔ５１２が１のとき、Ｌｅｎｇｔｈを示す。なお、Ｌｅｎｇｔｈ Ｐｒｅｓｅｎｔ５１２が０のときは、Ｍｉｓｃを示すが、その詳細は未定である。５１４はＰｒｏｔｅｃｔｅｄ（３ビット）であり、ＷＵＲ ｆｒａｍｅがＭＩＣ（Ｍｅｓｓａｇｅ Ｉｎｔｅｇｒｉｔｙ Ｃｈｅｃｋ）アルゴリズムで保護されているかを示す。Ｐｒｏｔｅｃｔｅｄ ５１２が１のときはＷＵＲ ｆｒａｍｅがＭＩＣで保護されていることを示し、０のときはＣＲＣ（Ｃｙｃｌｉｃ Ｒｅｄｕｎｄａｎｃｙ Ｃｈｅｃｋ）を含むことを示す。
【００３２】
Ｆｒａｍｅ Ｂｏｄｙ５０４は、Ｃｏｍｐｒｅｓｓｅｄ ＳＳＩＤ５２１とＰＣＲ Ｏｐｅｒａｔｉｎｇ Ｃｈａｎｎｅｌ５２２を有する。Ｃｏｍｐｒｅｓｓｅｄ ＳＳＩＤ５２１は、ｓｈｏｒｔ−ＳＳＩＤ（４バイト）のＬＳＢの１６ビット値である。ＰＣＲ Ｏｐｅｒａｔｉｎｇ Ｃｈａｎｎｅｌ５２２は、１６ビットのＰＣＲ Ｏｐｅｒａｔｉｎｇ Ｃｈａｎｎｅｌである。
この５２２は、二つ８ビット領域からなる。一つは、Ｏｐｅｒａｔｉｎｇ Ｃｌａｓｓ５３１であり、もう一つは、ｃｈａｎｎｅｌ５３２（ｎｕｍｂｅｒ）である。Ｏｐｅｒａｔｉｎｇ Ｃｌａｓｓ５３１の内容を図５Ｂの（ｂ）に示す。Ｏｐｅｒａｔｉｎｇ Ｃｌａｓｓ５３１により特定される項目５４１〜項目５４６は、ＩＥＥＥ８０２．１１規格で共通に定義される運用に関する項目である。なお、５２２を単に「Ｏｐｅｒａｔｉｎｇ Ｃｈａｎｎｅｌ」と称してもよい。
【００３３】
次に図６Ａ、図６Ｂ、図６Ｃを参照して、本実施形態による、ローミングのための情報の収集、ローミング動作を説明する。まず、図６Ａ〜６Ｃで用いられる略語について説明する。
【００３４】
ＡＰの構成要素であるＤＳＳは、Ｄｉｓｔｒｉｂｕｔｉｏｎ Ｓｙｓｔｅｍ Ｓｅｒｖｉｃｅの略であり、ＡＰ自身が管理するＤＳ（Ｄｉｓｔｒｉｂｕｔｉｏｎ Ｓｙｓｔｅｍ）とは別のＤＳとのインタフェースである。一般的な実装では、インタフェース２１０がＥｔｈｅｒｎｅｔを代表とする有線ＬＡＮとなる。ＷＵＲ−Ｔｘは、ＡＰのＷＵＲの３種のｆｒａｍｅ（Ｂｅａｃｏｎ、Ｗａｋｅ−ｕｐ、Ｄｉｓｃｏｖｅｒｙ）の送信機能である。これは、ＷＵＲ制御部２０８および通信部２０６によって実現される。
【００３５】
Ｐｃｈは、ＷＵＲ ｐｒｉｍａｒｙ ｃｈａｎｎｅｌの本明細書における略称であり、ＷＵＲ Ｂｅａｃｏｎが報知されるチャネルを示す。このＢｅａｃｏｎが報知されるチャネルは、ＷＵＲ Ｃｈａｎｎｅｌとも呼ばれる。このＷＵＲ Ｃｈａｎｎｅｌは１オクテット数であり、ＷＵＲ Ｏｐｅｒａｔｉｏｎ ｅｌｅｍｅｎｔ（図３のＷＵＲ Ｏｐｅｒａｔｉｏｎ）のＷＵＲ Ｏｐｅｒａｔｉｏｎ Ｐａｒａｍｅｔｅｒｓの一つの要素である。
【００３６】
Ｌｃｈは、ＷＵＲ Ｌｉｓｔｅｎ ｃｈａｎｎｅｌの本明細書における略称であり、ＳＴＡがＷＵＲ ａｗａｋｅの状態にあるときに、ＷＵＲ Ｗａｋｅ−ｕｐ ｆｒａｍｅを待ち受ける（ｌｉｓｔｅｎする）チャネルである。ＬｃｈはＷＵＲ Ｏｐｅｒａｔｉｏｎ ｅｌｅｍｅｎｔ（図３のＷＵＲ Ｏｐｅｒａｔｉｏｎ）のＷＵＲ Ｏｐｅｒａｔｉｏｎ Ｐａｒａｍｅｔｅｒｓの一つの要素である。
【００３７】
Ｄｃｈは、ＷＵＲ Ｄｉｓｃｏｖｅｒｙ ｃｈａｎｎｅｌの本明細書における略称であり、ＷＵＲ ＡＰがＷＵＲ Ｄｉｓｃｏｖｅｒｙ ｆｒａｍｅを送信するチャネルである。ＳＴＡ１１０はこのｆｒａｍｅを受信することで、ＡＰのＰＣＲチャネルを知ることができる。なお、８０２．１１ｂａ規格では、Ｄｃｈは、２．４ＧＨｚ帯では１ｃｈ、５ＧＨｚ帯では４０、４４、１４９、１５３ｃｈのいずれかであり、ＷＵＲ Ｄｉｓｃｏｖｅｒｙ Ｃｈａｎｎｅｌ４１２により通知される。以上のＰｃｈ、Ｌｃｈ、Ｄｃｈとしてどのチャネルを使用するかは、ＡＰの運用の設定次第である。よって、全てのチャネルが同じ、任意のふたつが同じ、全てが異なる、のいずれであってもよい。なお、ＡＰは、Ａｃｔｉｏｎ ＴｙｐｅがＥｎｔｅｒ ＷＵＲ  Ｍｏｄｅ  ＲｅｓｐｏｎｓｅまたはＥｎｔｅｒ ＷＵＲ  Ｍｏｄｅ  Ｓｕｓｐｅｎｄ ＲｅｓｐｏｎｓｅのＷＵＲ  Ｃｈａｎｎｅｌ  Ｏｆｆｓｅｔによって、ＬｃｈとＰｃｈとの差異をＳＴＡに示す。
【００３８】
ＷＵＲ−Ｒｘは、ＳＴＡ１１０のＷＵＲ受信機能である。これは、ＷＵＲ制御部２０８および通信部２０６によって実現される。なお、ＩＥＥＥ８０２．１１ｂａ規格の策定過程では、ＷＵＲｘと表記されていたことがあるが、本明細書では、ＡＰの送信機能を示すＷＵＲ−Ｔｘとの対比のために、ＷＵＲ−Ｒｘと表記している。また、ＩＥＥＥ８０２．１１ｂａ規格では、ＡＰはＷＵＲの送信側（ｔｒａｎｓｍｉｔｔｅｒ）、ＳＴＡはＷＵＲの受信側（ｒｅｃｅｉｖｅｒ）と定義されているのみである。よって、ＡＰとＳＴＡの両方の機能を備える機器においては、一つの物理的な端末がＷＵＲの送受信機能を備えることも可能である。この場合、ＷＵＲ−Ｒｘ（ＷＵＲｘ）機能とＷＵＲ−Ｔｘ機能のように区別することなく、単にＷＵＲ機能としてもよい。
【００３９】
次に、図６Ａ、図６Ｂ、図６Ｃを用いて、ＳＴＡ１１０がＡＰ１０１からＡＰ１０２にローミングするときの処理シーケンスを説明する。
【００４０】
＜図６Ａ：ＡＰ１０１が近隣のＷＵＲ ＡＰの情報を収集、Ｂｅａｃｏｎで通知＞
まず、ＡＰ１０１が近隣のＡＰについて、ＷＵＲの情報を収集する。その収集のための第一の方法は、ＤＳＳを経由した情報収集（６０１）であり、これは図１の（Ａ：ＷＵＲ情報交換プロトコル）に相当する。これは、ＡＰ１０１とＡＰ１０２が、ＷＵＲに関する情報の予め規定された交換手順に対応している場合のシーケンスである。予め規定された手順には、たとえば、無線ＬＡＮ通信の相互接続性を保証する団体であるＷｉ−Ｆｉ（登録商標）のＭｕｌｔｉ−ＡＰの拡張（Ｖｅｎｄｏｒ Ｅｘｔｅｎｓｉｏｎ）を用いることである。ここで、Ｍｕｌｔｉ−ＡＰとは、複数のＡＰを制御する枠組みであり、Ｃｏｎｔｒｏｌｌｅｒとして機能するＡＰとＡｇｅｎｔとして機能するＡＰが定義されている。Ｃｏｎｔｒｏｌｌｅｒとは、複数のＡＰから成るネットワークを制御する論理機構である。また、Ａｇｅｎｔとは、ＡＰの制御機能を実行し、制御のための情報をＣｏｎｔｒｏｌｌｅｒに提供する論理機構である。すなわち、Ｍｕｌｔｉ−ＡＰにおけるＣｏｎｔｒｏｌｌｅｒとＡｇｅｎｔの間の情報交換手順の拡張により、上述したＷＵＲに関する情報の収集を行うことができる。よって、これらは記憶部２０１内のプログラムとして実現可能である。
【００４１】
例えば、一つのＭｕｌｔｉ−ＡＰ構成においては、一つのＡＰにおいてＣｏｎｔｒｏｌｌｅｒ機能が動作し、他の全てのＡＰにおいてＡｇｅｎｔ機能が動作する。これらのＣｏｎｔｒｏｌｌｅｒとＡｇｅｎｔの間では、Ｗｉ−Ｆｉで共通に規定する情報の他に、Ｖｅｎｄｏｒ Ｅｘｔｅｎｓｉｏｎという拡張規定を用いることにより、独自の情報を交換することが可能になっている。
【００４２】
よって、ＡＰ１０１とＡＰ１０２がＭｕｌｔｉ−ＡＰを構成した場合、Ｃｏｎｔｒｏｌｌｅｒ機能のＶｅｎｄｏｒ Ｅｘｔｅｎｓｉｏｎによって、それぞれのＡＰのＰＣＲおよびＷＵＲに関する情報を交換し合うことができる。ここで、ＰＣＲに関する情報とは、Ｃｏｍｐｒｅｓｓｅｄ ＳＳＩＤ５２１、ＰＣＲ Ｏｐｅｒａｔｉｎｇ Ｃｈａｎｎｅｌ５２２である。また、ＷＵＲに関する情報とは、ＷＵＲ Ｄｉｓｃｏｖｅｒｙ Ｃｈａｎｎｅｌ４１２、Ｓｈｏｒｔ−ＳＳＩＤ４２２、ＢＳＳＩＤ４２３、ＷＵＲ Ｄｉｓｃｏｖｅｒｙ Ｐｅｒｉｏｄ４２４である。
【００４３】
このようにしてＡＰ１０１は、近隣のＷＵＲ対応のＡＰの情報を取得して、ＷＵＲ Ｄｉｓｃｏｖｅｒｙ ｅｌｅｍｅｎｔ（４００）を構築する。しかし、複数のＡＰの間で、ＷＵＲに関する情報の交換手順が既定されていない場合、または、Ｖｅｎｄｏｒ（製造や販売の会社）が異なる場合は、上述した第一の方法（６０１）を使用できない。この場合は、以下に示すように、第二、第三、第四の方法をおこなう。
【００４４】
６０２は、ＡＰ１０１が近隣のＷＵＲ ＡＰの情報を収集する第二の方法であり、Ｂｅａｃｏｎを受信する方法、つまり図１の（Ｂ）に相当する。第二の方法では、ＡＰ１０１は他のＡＰのＢｅａｃｏｎ中のＷＵＲ Ｄｉｓｃｏｖｅｒｙ ｅｌｅｍｅｎｔ（４００）を収集する。なお、可能であれば、ＡＰ１０１のＰＣＲチャネル以外のチャネルのＢｅａｃｏｎを受信して収集する。この処理は、周期的、あるいは、ＡＰの送信処理をおこなわないときに随時実行される。
【００４５】
６０３は、近隣のＷＵＲ ＡＰの情報収集の第三の方法であり、図１の（Ｃ）に相当する。第三の方法は、ＷＵＲのＤｃｈ上に送信されているＷＵＲ Ｄｉｓｃｏｖｅｒｙ ｆｒａｍｅを受信する方法である。第三の方法では、ＡＰ１０１がＷＵＲ−Ｒｘ機能を実行可能であるとしている。また、上述の５つのＷＵＲ Ｄｉｓｃｏｖｅｒｙ Ｃｈａｎｎｅｌ（２．４ＧＨｚ帯では１ｃｈ、５ＧＨｚ帯では４０、４４、１４９、１５３ｃｈ）で定期的、網羅的に受信できるものとしている。
【００４６】
６０４と６０５は、ＡＰ１０１が近隣のＷＵＲ ＡＰの情報を収集するための第四の方法であり、図１の（Ｄ）に相当する。第四の方法では、ＡＰ１０１がＰｒｏｂｅ Ｒｅｑｕｅｓｔを送信して、近隣ＡＰにＰｒｏｂｅ Ｒｅｓｐｏｎｓｅを送信させる、アクティブスキャンをおこなう。なお、Ｐｒｏｂｅ Ｒｅｑｕｅｓｔに含めるＳＳＩＤは、ＡＰ１０１自身のＳＳＩＤでもよいし、値を０（ゼロ）またはＮｕｌｌのＷｉｌｄｃａｒｄ ＳＳＩＤとしてもよい。また、Ｐｒｏｂｅ Ｒｅｑｕｅｓｔを送信するチャネルは、ＡＰ１０１のＯｐｅｒａｔｉｎｇ Ｃｈａｎｎｅｌと同じでもよいし、異なっていてもよい。
【００４７】
以上の四つの方法のうちの任意の方法を実行することで、ＡＰ１０１は、他のＡＰのＷＵＲに関する情報を収集することができる。ＡＰ１０１は、ＷＵＲに関する情報を収集した後、図４Ａ〜４Ｂで示したようなＷＵＲ Ｄｉｓｃｏｖｅｒｙ ｅｌｅｍｅｎｔを構築する（６０７）。そして、ＡＰ１０１は、ＰＣＲ Ｂｅａｃｏｎの送信周期において、構築したＷＵＲ Ｄｉｓｃｏｖｅｒｙ ｅｌｅｍｅｎｔを含むＢｅａｃｏｎを送信する（６０８）。
【００４８】
＜図６Ｂ：ＳＴＡ１１０がＡＰ１０１とＰＣＲ接続、ＷＵＲ動作のネゴシエーション、ＷＵＲ ａｗａｋｅ＞
ＳＴＡ１１０は、ＡＰ１０１に対する利用者の接続操作を認識する（６１１）。ＳＴＡ１１０は、ＡＰ１０１にＰｒｏｂｅ Ｒｅｑｕｅｓｔを送信する（６１２）。ＡＰ１０１は、このＰｒｏｂｅ Ｒｅｑｕｅｓｔに対してＷＵＲ Ｄｉｓｃｏｖｅｒｙ ｅｌｅｍｅｎｔを含むＰｒｏｂｅ Ｒｅｓｐｏｎｓｅを送信する（６１３）。
【００４９】
ＳＴＡ１１０は、ローミングポリシーを決定する（６１４）。ここでは、ローミング先の決定までの時間、複数のローミング先候補が存在するときの選択基準などが決定される。ＳＴＡ１１０とＡＰ１０１との間の接続処理が実行される（６１５）。この接続処理は、Ａｕｔｈｅｎｔｉｃａｔｉｏｎ、Ａｓｓｏｃｉａｔｉｏｎのそれぞれについての要求（Ｒｅｑｕｅｓｔ）と応答（Ｒｅｓｐｏｎｓｅ）である。
【００５０】
次に、ＳＴＡ１１０とＡＰ１０１の間で、ＷＵＲ動作のネゴシエーション手順が実行される（６１６）。これは、ＳＴＡ１１０からＡＰ１０１へＷＵＲ Ｍｏｄｅ Ｓｅｔｕｐ Ｒｅｑｕｅｓｔを送信し、それに対しＡＰ１０１がＷＵＲ Ｍｏｄｅ Ｓｅｔｕｐ Ｒｅｓｐｏｎｓｅで応答する手順である。基本的には、ＳＴＡ１１０からＲｅｑｕｅｓｔを送信して、ＡＰ１０１がその要求をそのまま受け入れる場合は、Ａｃｃｅｐｔの意味を含むＲｅｓｐｏｎｓｅを返す。また、ＡＰ１０１は、要求された値を変更したいときは、Ｒｅｓｐｏｎｓｅによって指定することができる。また、Ｒｅｑｕｅｓｔを受けていない状態で、Ｒｅｓｐｏｎｓｅを送信することもできる。
【００５１】
このようにして、たとえば、ＳＴＡ１１０は、ＷＵＲ受信機能を有効（ＷＵＲ−Ｒｘを「ＯＮ」）にするスケジュールを決定するＤｕｔｙ Ｃｙｃｌｅ Ｐｅｒｉｏｄ、Ｏｎ Ｄｕｒａｔｉｏｎ、Ｓｔａｒｔｉｎｇ ｔｉｍｅを決定する。ここで、Ｏｎ Ｄｕｒａｔｉｏｎとは、Ｄｕｔｙ Ｃｙｃｌｅ Ｐｅｒｉｏｄ期間におけるＷＵＲ−Ｒｘが「ＯＮ」の時間である。つまり、ＷＵＲ−Ｒｘが「ＯＦＦ」になる期間もあり、さらなる省電力が実現されている。なお、ＷＵＲ−Ｒｘが「ＯＦＦ」になる期間が存在しないようにネゴシエーションすることも可能である。また、他のネゴシエーション項目として、ＷＵＲ Ｗａｋｅ−ｕｐ ｆｒａｍｅが送信されるチャネルのＷＵＲ Ｐｒｉｍａｒｙ Ｃｈａｎｎｅｌからのオフセット値がある。
【００５２】
以上のようなＷＵＲ動作のネゴシエーションの後、端末は、ＷＵＲ Ｍｏｄｅ状態に遷移する。ここで、ＷＵＲ Ｍｏｄｅとは、ＡＰ１０１からのＷＵＲ ｓｅｒｖｉｃｅを受けている状態のことである。ＷＵＲ ｓｅｒｖｉｃｅとは、ＷＵＲ Ｂｅａｃｏｎ、ＷＵＲ Ｄｉｓｃｏｖｅｒｙ ｆｒａｍｅ、Ｗａｋｅ−ｕｐ ｆｒａｍｅの提供を指す。このｓｅｒｖｉｃｅによって、ＷＵＲ Ｗａｋｅ−ｕｐ ｆｒａｍｅを受けるタイミングをＳＴＡ１１０のＰＣＲがｄｏｚｅのときに限る、ということも可能である。
【００５３】
ここで、ＳＴＡ１１０がＷＵＲ Ｍｏｄｅ状態に遷移するとは、ＳＴＡ１１０がＡｃｔｉｏｎ ＴｙｐｅがＥｎｔｅｒ ＷＵＲ Ｍｏｄｅ Ｒｅｑｕｓｔのフレームを送信し、ＡＰ１０１から対応するフレームを受信することである。この対応するフレームは、Ａｃｔｉｏｎ ＴｙｐｅがＥｎｔｅｒ  ＷＵＲ Ｍｏｄｅ Ｒｅｓｐｏｎｓｅであって、Ｓｔａｔｕｓ ｆｉｅｌｄの値がＡｃｃｅｐｔ（０：ゼロ）となる。このとき、ＡＰ１０１は、ＳＴＡ１１０をＷＵＲ Ｍｏｄｅ状態にあるとして扱う。また、ＳＴＡ１１０が、Ａｃｔｉｏｎ ＴｙｐｅがＥｎｔｅｒ ＷＵＲ Ｍｏｄｅのフレームを送信し、ＡＰ１０１がＩＥＥＥ８０２．１１のａｃｋを返したときも、ＳＴＡ１１０がＷＵＲ Ｍｏｄｅ状態に遷移したことになる。
【００５４】
ここで、ＳＴＡ１１０は、ＷＵＲ Ｍｏｄｅ状態に遷移したことを契機に、ＰＣＲの省電力機能を開始する。省電力とは、ＰＣＲ制御部２０７をｓｌｅｅｐ、または、ｄｏｚｅにして、送受信をおこなわないことである。このＰＣＲの省電力状態のときに、ＳＴＡ１１０は、ＷＵＲ−Ｒｘを有効（ＯＮ）にして、ＡＰ１０１からのＷａｋｅ−ｕｐ ｆｒａｍｅを受信できるようにしておく。このとき、ＷＵＲ−Ｒｘを有効にするための消費電力は、ＰＣＲの受信を有効にするための消費電力より小さいので、ＳＴＡ１１０全体としては、省電力となる。
【００５５】
ＡＰ１０１は、Ｐｃｈ上でＷＵＲ Ｂｅａｃｏｎを送信する（６１７）。なお、ＩＥＥＥ８０２．１１ｂａ規格では、ＡＰ１０１は、ＷＵＲ ｓｅｒｖｉｃｅを必要としているＳＴＡが存在する限り、ＴＷＢＴＴと呼ばれる間隔で、ＷＵＲ Ｂｅａｃｏｎを送信することになっている。ＴＷＢＴＴとは、Ｔａｒｇｅｔ ＷＵＲ Ｂｅａｃｏｎ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｔｉｍｅの略である。また、ＳＴＡ１１０は、基本的には、このＢｅａｃｏｎを受信する。
【００５６】
また、ＡＰ１０１は、ＷＵＲ Ｄｉｓｃｏｖｅｒｙ ｆｒａｍｅを送信する（６１８）。このフレームの送信間隔は、ＷＵＲ Ｄｉｓｃｏｖｅｒｙ Ｐｅｒｉｏｄ４２４（図４Ｂ）である。図６Ｂでは、ＳＴＡ１１０が、常に、このＷＵＲ Ｄｉｓｃｏｖｅｒｙ ｆｒａｍｅを受信するように記載している。しかし、ＳＴＡ１１０側でこのフレームの必要がなければ、受信しなくてもよい。
【００５７】
なお、図６Ｂには記載していないが、ＷＵＲ ｍｏｄｅ状態に入ったＳＴＡ１１０は、ＷＵＲ Ｄｕｔｙ ＣｙｃｌｅとＯｎ Ｄｕｒａｔｉｏｎに従って、ＬｃｈでＷＵＲ Ｗａｋｅ−ｕｐ ｆｒａｍｅを待ち受ける。ＳＴＡ１１０は、どのチャネルでＷＵＲ Ｗａｋｅ−ｕｐ ｆｒａｍｅを待ち受ければよいかを、ＡＰ１０１から送信されたＷＵＲ Ｏｐｅｒａｔｉｏｎ ｅｌｅｍｅｎｔ（図３のＷＵＲ Ｏｐｅｒａｔｉｏｎに含まれている）の値によって、把握している。
【００５８】
＜図６Ｃ：ＳＴＡ１１０によるＡＰ１０２へローミング＞
ＳＴＡ１１０がＡＰ１０１のＷＵＲ Ｂｅａｃｏｎを正常に受信できない事象が発生したとする（６２１）。この事象の発生原因には、ＡＰ１０１の不具合、ＳＴＡ１１０またはＡＰ１０１の移動や周囲の状況の変化によるＡＰ１０１とＳＴＡ１１０との間の伝搬特性の変化、などがあげられる。
【００５９】
ＡＰ１０１からのＷＵＲ Ｂｅａｃｏｎを正常に受信できない場合、ＳＴＡ１１０はローミングの必要性を判定する（６２２）。ローミングの要否の判断は、例えばＳＴＡ１１０におけるユーザ設定に基づくことができる。図示のシーケンスでは、ＳＴＡ１１０は、「ローミングの必要性がある」と判定したとしている。この場合、ＳＴＡ１１０は、ＡＰ１０１とは別のＡＰを捜索（スキャン）するように動作する。ＳＴＡ１１０は、ＷＵＲ Ｄｉｓｃｏｖｅｒｙ Ｃｈａｎｎｅｌ選択処理をおこなう（６２３）。例えば、ＳＴＡ１１０は、ＷＵＲ ＡＰ Ｌｉｓｔ４１４にリストされている順番にＷＵＲ Ｄｉｓｃｏｖｅｒｙ Ｃｈａｎｎｅｌを選択する。ＳＴＡ１１０は、ＷＵＲ Ｄｉｓｃｏｖｅｒｙ ｆｒａｍｅを、ＷＵＲ Ｄｉｓｃｏｖｅｒｙ Ｃｈａｎｎｅｌ選択処理（６２３）で選択したＤｃｈ上で受信する（６２４）。
【００６０】
ＳＴＡ１１０は、ＷＵＲ Ｄｉｓｃｏｖｅｒｙ ｆｒａｍｅ受信処理を実行し、受信したＷＵＲ Ｄｉｓｃｏｖｅｒｙ ｆｒａｍｅから取得した情報に基づいて、ＰＣＲのＢｅａｃｏｎを待ち受ける状態に移行するかを決定する（６２５）。例えば、ＳＴＡ１１０は、ローミングによる変更後のＡＰと直ちにＰＣＲ通信を行うようにユーザ設定されている場合、ＰＣＲのＢｅａｃｏｎを待ち受ける状態に移行する。そして、ＰＣＲのＢｅａｃｏｎを受け付けると（６２６）、Ｂｅａｃｏｎ ｆｒａｍｅ受信処理を実行する（６２７）。例えば、接続先をＡＰ１０２へ変更（ローミング）する。
【００６１】
その後の、処理６２８、６２９、６３０、６３１は、それぞれ、図６Ｂに示した処理６１２、６１３、６１５、６１６と同様である。なお、処理６３０の後に、処理６１４（図６Ｂ）で行ったローミングポリシーの決定を改めて行うようにしてもよい。一方、ＳＴＡ１１０が、ＷＵＲ Ｄｉｓｃｏｖｅｒｙ ｆｒａｍｅ受信処理（６２５）の結果、ＰＣＲのＢｅａｃｏｎを待ち受ける状態に移行しないと判定した場合は、例えばローミング先を別のＡＰに切り替えて上記処理を繰り返す。
【００６２】
図７を用いて、ＡＰ管理テーブルについて説明する。ＡＰ管理テーブル７００は、ＷＵＲ Ｄｉｓｃｏｖｅｒｙ ｅｌｅｍｅｎｔを構築するための情報を整理したものである。ＡＰ１０１は、後述するように、ＤＳＳ、ＰＣＲ、ＷＵＲによる各通信によって、ＷＵＲ動作に対応した他ＡＰの情報を収集する度に、このＡＰ管理テーブル７００を更新する。
【００６３】
項目７０１は、ＡＰテーブルのｉｎｄｅｘである。ＡＰ１０１は、まず自身のｉｎｄｅｘを０（ゼロ）とする。その後、新たな他のＡＰの情報を取得する度に、このｉｎｄｅｘをインクリメントする。ＷＵＲ Ｄｉｓｃｏｖｅｒｙ ｅｌｅｍｅｎｔを構築するときは、最終ｉｎｄｅｘの値が、ＷＵＲ ＡＰ Ｃｏｕｎｔ４１３の値となる。項目７０２は、Ｔｒａｎｓｍｉｔｔｉｎｇ ＷＵＲ ＡＰ４３１の値を示す。本例では、ｉｎｄｅｘ＝０が「１」となり、それ以降のｉｎｄｅｘについては「０」となる。項目７０３は、ＷＵＲ Ｄｉｓｃｏｖｅｒｙ Ｃｈａｎｎｅｌ４１２の値を示す。項目７０４は、ＷＵＲ Ｄｉｓｃｏｖｅｒｙ ｆｒａｍｅを送信したＡＰのＷＵＲ ＩＤである。これは、１２ｂｉｔ数であるが、便宜上、図７ではＩＤｘｘと表記している。
【００６４】
項目７０５は、Ｓｈｏｒｔ−ＳＳＩＤ４２２の値を示す。ただし、Ｓｈｏｒｔ−ＳＳＩＤ４２２が不明な場合は、ＡＰ管理テーブル７００上では、０ｘ００、０ｘ００、０ｘ００、０ｘ００（４オクテット）とする。項目７０６は、ＢＳＳＩＤ４２３の値を示す。ただし、ＢＳＳＩＤ４２３が不明な場合は、ＡＰ管理テーブル７００上では、０ｘｆｆ、０ｘｆｆ、０ｘｆｆ、０ｘｆｆ、０ｘｆｆ、０ｘｆｆ（６オクテット）とする。項目７０７は、ＷＵＲ Ｄｉｓｃｏｖｅｒｙ Ｐｅｒｉｏｄ４２４の値を示す。項目７０８は、ｉｎｄｅｘに対応するＡＰのＷＵＲ Ｄｉｓｃｏｖｅｒｙ ｆｒａｍｅを受信した直近の日時を示す。
【００６５】
項目７０９は、ＷＵＲ Ｄｉｓｃｏｖｅｒｙ Ｐｅｒｉｏｄの取得方法を示す。ＡＰ１０１自身について、項目７０９は「設定値」という値になる。これは、後述のＳ８１５（図８Ｂ）で入力された値、または、ＩＥＥＥまたはＷｉ−Ｆｉの規定値／既定値／デフォルトであることを示す。項目７０９が「直接」を示す場合、ＤＳＳまたはＰＣＲ通信によって、ＷＵＲ Ｄｉｓｃｏｖｅｒｙ Ｐｅｒｉｏｄの値を取得できていることを示す。項目７０９が「計算」を示す場合、ＷＵＲ Ｄｉｓｃｏｖｅｒｙ Ｐｅｒｉｏｄが、受信した複数のＷＵＲ Ｄｉｓｃｏｖｅｒｙ ｆｒａｍｅから計算によって求めた値であることを示す。この計算式は、たとえば、ＷＵＲ Ｄｉｓｃｏｖｅｒｙ ｆｒａｍｅの受信日時を現時刻と表現するとして、｛[項目７０７]＋（現時刻−[項目７０８]）｝／２となる。ただし、これは、項目７０７が０（ゼロ）以外のときである。項目７０７がゼロのときは、（現時刻−[項目７０８]）となる。なお、３個以上の受信日時を保持しておいて、それぞれの前回との差分の平均値を算出するようにしてもよい。
【００６６】
項目７１０は、Ｃｏｍｐｒｅｓｓｅｄ ＳＳＩＤ５２１の値を示す。項目７１１は、Ｏｐｅｒａｔｉｎｇ Ｃｌａｓｓ５３１の値を示す。７１２は、ｃｈａｎｎｅｌ５３２の値を示す。以上のようなＡＰ管理テーブル７００は、以下で説明する処理により更新される。制御部２０２は、ＡＰ管理テーブル７００が更新されると、更新後のＡＰ管理テーブル７００から図４Ａ〜４Ｂで説明したＷＵＲ Ｄｉｓｃｏｖｅｒｙを生成し、ＢｅａｃｏｎによりＳＴＡ１１０に通知する。
【００６７】
次に、ＡＰ１０１の動作を図８Ａ〜８Ｅのフローチャートを参照して説明する。図８Ａ〜８Ｅは、ＡＰ１０１の定常状態におけるイベント処理を説明するフローチャートである。以降、特に断りがない限り、フローチャートの各ステップの処理の主体は、ＡＰ１０１の制御部２０２である。また、定常状態とは、運用のための初期設定を終えた後の状態である。また、イベントとは、ＡＰ１０１が何らかの制御をおこなう際の契機となるソフトウェアまたはハードウェアによる事象であり、タイマー満了、フレームの送受信、利用者の入力部２０４に対する操作といったものを含む。
【００６８】
図８ＡのＳ８０１において、制御部２０２は、イベントの内容によって、処理の第一の振り分けをおこなう。この第一の振り分けという表現は、次にさらに詳細な振り分けがおこなわれるということを示している。ここで、第一の振り分けによる振り分け先の処理は、「入出力関連」の処理（Ｓ８１０）、「ＤＳＳ関連」の処理（Ｓ８２０）、「ＰＣＲ関連」の処理（Ｓ８３０）、「ＷＵＲ関連」の処理（Ｓ８５０）、「その他」の処理（Ｓ８６０）である。なお、Ｓ８６０における「その他のイベント処理」は、本願にとって特に重要ではないため、その説明を省略する。また、Ｓ８０１における「振り分け不可」のイベントとは、ハードウェアのリセット、ソフトウェアのアボート、例外処理などである。このようなイベントを検出した場合は、制御部２０２は、定常状態を終える。以下、振り分けたイベントの詳細を図８Ｂ〜図８Ｅのフローチャートを参照して説明する。
【００６９】
＜入力関連イベント処理＞
図８Ｂは入出力関連イベント処理（Ｓ８１０）を示すフローチャートである。まず、Ｓ８１１において、制御部２０２は、入力関連イベントの詳細振り分けをおこなう。入力関連イベントが近隣のＷＵＲ ＡＰの情報収集設定に関する入力であった場合、処理はＳ８１２へ進む。Ｓ８１２では、制御部２０２は、Ｍｕｌｔｉ−ＡＰによる問い合わせ間隔を設定する。これは、ＰＣＲおよびＷＵＲの運用状態の問い合わせ間隔である。この問い合わせ間隔の値がゼロ以外のときは、その間隔でＤＳＳ関連のタイマー満了イベントが発生するようになる。他方、問い合わせ間隔の値が０（ゼロ）の場合は、Ｍｕｌｔｉ−ＡＰの機能を用いた問い合わせをおこなわないこととしている。Ｓ８１３で、制御部２０２は、問い合わせタイマーを起動する。
【００７０】
Ｓ８１１で入力関連イベントがＰＣＲ設定に関する入力であった場合、処理はＳ８１４へ進み、制御部２０２は、ＰＣＲ運用管理の設定をおこなう。また、Ｓ８１１で入力関連イベントがＷＵＲ設定に関する入力であった場合、処理はＳ８１５へ進み、制御部２０２は、ＷＵＲ運用管理の設定をおこなう。なお、Ｓ８１４およびＳ８１５において、制御部２０２は、ＡＰ管理テーブル７００のＡＰ自身に関する情報、つまり、ｉｎｄｅｘ＝０の行に関する情報が変更されたときは、それに応じてＡＰ管理テーブル７００を更新する。さらに、これまで説明した入力関連のイベントも存在するが、ここではフローチャートにおける図示および説明を省略する。
【００７１】
＜ＤＳＳ関連イベント処理＞
図８Ｃは、ＤＳＳ関連イベント処理（Ｓ８２０）を示すフローチャートである。Ｓ８２１で、ＤＳＳ関連イベントの詳細振り分けをおこなう。ＤＳＳ関連イベントが、Ｍｕｌｔｉ−ＡＰによる問い合わせタイマー満了の場合、処理はＳ８２２へ進む。ここで、Ｍｕｌｔｉ−ＡＰによる問い合わせタイマーは、Ｓ８１２でその間隔が設定され、定期的にＤＳＳ関連イベントを発行するものである。
【００７２】
Ｓ８２２で、制御部２０２は、問い合わせ送信をおこなう。これは、Ｍｕｌｔｉ−ＡＰを構成するＡＰのＰＣＲおよびＷＵＲ ＡＰの運用情報を問い合わせるものである。ここで、運用情報とは、図７のＡＰ管理テーブル７００の項目７０８を除く項目である。Ｓ８２３で、制御部２０２は、Ｓ８２２で送信した問い合わせに対する応答を受信する。８２４で、制御部２０２は、応答に含まれるＷＵＲ ＡＰの運用情報を基に、ＡＰ管理テーブル７００を更新する。ここで更新する項目は、ＡＰ管理テーブル７００の項目７０２から項目７０７まで、および項目７１０から項目７１２までである。Ｓ８２５で、制御部２０２は、Ｍｕｌｔｉ−ＡＰによる問い合わせタイマーを再スタートする。
【００７３】
一方、Ｓ８２１でＤＳＳ関連イベントがデータフレーム受信であった場合、処理はＳ８２６に進む。Ｓ８２６において、制御部２０２は、受信データを端末毎に送信バッファへ登録する。なお、これまで説明したＤＳＳ関連の他のイベントが存在するが、本実施形態では、フローチャートへの図示および説明を省略する。
【００７４】
＜ＰＣＲ関連イベント処理＞
図８Ｄは、ＰＣＲ関連イベント処理（Ｓ８３０）を示すフローチャートである。Ｓ８３１で、制御部２０２は、ＰＣＲ関連イベントの詳細振り分けをおこなう。ＰＣＲ関連イベントが、ＰＣＲ Ｂｅａｃｏｎタイマー満了のとき、処理はＳ８３１へ進む。ＰＣＲ Ｂｅａｃｏｎタイマーの間隔は、ＰＣＲ運用管理の設定（Ｓ８１４）で指定される値である。なお、特に指定のない場合は、１００ｍｓｅｃである。Ｓ８３１で、制御部２０２は、ＡＰ管理テーブル７００からＷＵＲ Ｄｉｓｃｏｖｅｒｙ ｅｌｅｍｅｎｔを作成する。Ｓ８３２で、制御部２０２は、Ｓ８３１で作成したＷＵＲ Ｄｉｓｃｏｖｅｒｙ ｅｌｅｍｅｎｔを含むＰＣＲ Ｂｅａｃｏｎを送信する。なお、ＰＣＲ Ｂｅａｃｏｎには、タイムスタンプやＳＳＩＤなどの情報要素（ｅｌｅｍｅｎｔ）が含まれるが、これらは一般的な内容である。
【００７５】
Ｓ８３１でＰＣＲ関連イベントが他ＡＰのＢｅａｃｏｎ受信であった場合、処理はＳ８３３へ進む。Ｓ８３３で、制御部２０２は、ＷＵＲ Ｄｉｓｃｏｖｅｒｙ ｅｌｅｍｅｎｔの内容に基づいてＡＰ管理テーブル７００を更新する。ここで更新される項目は、ＡＰ管理テーブル７００の項目７０２から項目７０７までである。また、制御部２０２は、Ｂｅａｃｏｎ中の他の情報要素（ｅｌｅｍｅｎｔ）によって項目７１０を更新する。同様に、制御部２０２は、Ｂｅａｃｏｎが送信されたチャネルによって、項目７１１と項目７１２を更新する。
【００７６】
Ｓ８３１でＰＣＲ関連イベントがＰｒｏｂｅ Ｒｅｑｕｅｓｔ受信の場合、処理はＳ８３４へ進む。Ｓ８３４において、制御部２０２は、ＡＰ管理テーブル７００からＷＵＲ Ｄｉｓｃｏｖｅｒｙ ｅｌｅｍｅｎｔを作成する。Ｓ８３５において、制御部２０２は、少なくともＷＵＲ Ｄｉｓｃｏｖｅｒｙ ｅｌｅｍｅｎｔを含んだＰｒｏｂｅ Ｒｅｓｐｏｎｓｅを送信する。
【００７７】
Ｓ８３１でＰＣＲ関連イベントが、ＷＵＲ Ｓｅｔｕｐ Ｒｅｑｕｅｓｔ受信の場合、処理はＳ８３６へ進む。Ｓ８３６で、制御部２０２は、ＷＵＲ Ｓｅｔｕｐ応答（Ｒｅｓｐｏｎｓｅ）を送信する。Ｓ８３７で、制御部２０２は、Ｓ８３６で送信したＷＵＲ Ｓｅｔｕｐの内容に応じて、ＷＵＲ管理状態を更新する。ＷＵＲ管理状態の情報項目には、ＷＵＲ ｄｕｔｙ ｃｙｃｌｅ ｏｐｅｒａｔｉｏｎがある。この情報により、ＡＰ１０１は端末のＷＵＲ−Ｒｘが「ＯＮ」状態のタイミングを把握した上で、ＷＵＲ Ｗａｋｅ−ｕｐ ｆｒａｍｅを送信する、という処理が可能になる。
【００７８】
Ｓ８３１においてＰＣＲ関連イベントがＰＳ−Ｐｏｌｌ受信の場合、処理はＳ８３８へ進む。Ｓ８３８で、制御部２０２は、送信バッファにＰＳ−Ｐｏｌｌを送信した端末向けのデータが登録されているかを判断する。登録されている場合は、Ｓ８３９において、制御部２０２は、そのデータを含むＤａｔａ ｆｒａｍｅを送信する。
【００７９】
Ｓ８３１において、ＰＣＲ関連イベントが媒体空きの場合、処理はＳ８４０に進む。Ｓ８４０において、制御部２０２は、Ｐｒｏｂｅ Ｒｅｑｕｅｓｔ送信可能かを判断する。Ｐｒｏｂｅ Ｒｅｑｕｅｓｔ送信可能と判断された場合、処理はＳ８４１へ進む。Ｓ８４１において、制御部２０２は、Ｐｒｏｂｅ Ｒｅｑｕｅｓｔを送信する。Ｓ８４２において、制御部２０２は、Ｐｒｏｂｅ Ｒｅｓｐｏｎｓｅを受信する。Ｓ８４３において、制御部２０２は、ＷＵＲ Ｄｉｓｃｏｖｅｒｙ ｅｌｅｍｅｎｔの内容によって、ＡＰ管理テーブル７００を更新する。ここで更新される項目は、項目７０２から項目７０７までである。また、Ｐｒｏｂｅ Ｒｅｓｐｏｎｓｅ中の他の情報要素（ｅｌｅｍｅｎｔ）によって、制御部２０２は項目７１０を更新する。同様に、Ｐｒｏｂｅ Ｒｅｓｐｏｎｓｅが送信されたチャネルによって、制御部２０２は、項目７１１と項目７１２を更新する。
【００８０】
なお、この処理の詳細が、Ｓ８１４におけるＰＣＲ運用管理の設定において決められてもよい。ここで、処理の詳細とは、この処理の実行の有無、実行間隔、Ｐｒｏｂｅ Ｒｅｑｕｅｓｔを送信するチャネルなどである。ここで、チャネルは、一般には、ＡＰ自身のＯｐｅｒａｔｉｏｎａｌ Ｃｈａｎｎｅｌであるが、他のチャネルでもよい。このような設定を可能としているのは、Ｐｒｏｂｅ Ｒｅｑｕｅｓｔを送信することが、無線媒体をｂｕｓｙにしたり、ＡＰの負荷を増加させたりすることになるからである。たとえば、ＡＰの利用者が、ＷＵＲ ＡＰ情報の収集よりもデータ通信を重要な処理として位置付けるときに、Ｓ８４０からの処理をおこなわないようにＳ８１４で設定することができる。
【００８１】
なお、図示はしていないが、収容している端末宛てのデータ受信のイベントを検知したときは、その受信データを送信バッファへ登録する。また、Ｓ８３３およびＳ８４３において、ＷＵＲ Ｄｉｓｃｏｖｅｒｙ ｅｌｅｍｅｎｔ中のＴｒａｎｓｍｉｔｔｉｎｇ ＷＵＲ ＡＰ４３１が「１」の情報は、ＡＰ管理テーブル７００の項目７０２（Ｔｒａｎｓｍｉｔｔｉｎｇ ＷＵＲ ＡＰ）では「０」とする。また、ＡＰ自身についての情報は、ＡＰ自身の設定情報から設定できるので、他ＡＰからのＷＵＲ Ｄｉｓｃｏｖｅｒｙ ｅｌｅｍｅｎｔの値をＡＰ管理テーブル７００の更新には用いない。なお、これまで説明した以外のＰＣＲ関連のイベントも存在するが、フローチャートへの図示および説明を省略する。
【００８２】
＜ＷＵＲ関連イベント＞
図８Ｅは、ＷＵＲ関連イベント処理（Ｓ８５０）を示すフローチャートである。ＳＳ８５１で、制御部２０２は、ＷＵＲ関連イベントの詳細振り分けをおこなう。ＷＵＲ関連イベントが、ＷＵＲ Ｂｅａｃｏｎタイマー満了のとき、処理はＳ８５２に進む。Ｓ８５２で、制御部２０２は、ＷＵＲ ＢｅａｃｏｎをＰｃｈで送信する。
【００８３】
Ｓ８５１でＷＵＲ関連イベントがＷａｋｅ−ｕｐ処理スケジュールであった場合、処理はＳ８５３へ進む。ＷＵＲ ＡＰは、Ｓ８３６およびＳ８３７の手順によって、接続している各端末のＷＵＲ−Ｒｘが「ＯＮ」のタイミングを把握している。Ｓ８５３で、制御部２０２は、ＷＵＲ−ＲｘがＯＮの端末向けのデータが送信バッファに存在するかを判断する。存在する場合、Ｓ８５４で、制御部２０２は、ＷＵＲ Ｗａｋｅ−ｕｐ ｆｒａｍｅをＬｃｈ上で送信する。
【００８４】
Ｓ８５１でＷＵＲ関連イベントがＷＵＲ Ｄｉｓｃｏｖｅｒｙ ｆｒａｍｅタイマー満了であった場合、処理はｓ８５５へ進む。Ｓ８５５で、制御部２０２は、ＷＵＲ Ｄｉｓｃｏｖｅｒｙ ｆｒａｍｅをＤｃｈ上で送信する。そして、Ｓ８５６で、制御部２０２は、他ＡＰのＷＵＲ Ｄｉｓｃｏｖｅｒｙ ｆｒａｍｅを待ち受けるかの判断をおこなう。この待ち受けの実行有無は、Ｓ８１５のＷＵＲ運用管理の設定で決定されている。Ｓ８５６における判断が「待ち受ける」の場合、処理はＳ８５７に進み、制御部２０２は、ＷＵＲ Ｄｉｓｃｏｖｅｒｙ ｆｒａｍｅを受信したかの判断をおこなう。こうして、ＡＰ１０１（制御部２０２）は、自身がＷＵＲサービスを提供するための送信処理が行われない期間に、他のアクセスポイントからのＷＵＲ Ｄｉｓｃｏｖｅｒｙ ｆｒａｍｅをスキャンすることができる。
【００８５】
ＷＵＲ Ｄｉｓｃｏｖｅｒｙ ｆｒａｍｅを受信したと判定された場合、処理はＳ８５８へ進み、制御部２０２は、ＷＵＲ Ｄｉｓｃｏｖｅｒｙ ｆｒａｍｅの内容に応じてＡＰ管理テーブル７００を更新する。ここで更新される項目は、ＡＰ管理テーブル７００の項目７０１から項目７０５、および項目７０７から項目７０９である。一方、Ｓ８５７においてＷＵＲ Ｄｉｓｃｏｖｅｒｙ ｆｒａｍｅを受信していないと判断された場合、Ｓ８５９において、制御部２０２は、既定時間が経過したかを判断する。既定時間内にＷＵＲ Ｄｉｓｃｏｖｅｒｙ ｆｒａｍｅを受信しなかった場合（Ｓ８５７でＮＯ、Ｓ８５９でＹＥＳ）は、イベント処理を終える。
【００８６】
ここで、ＷＵＲ Ｄｉｓｃｏｖｅｒｙ ｆｒａｍｅを待ち受けるチャネルは、ＡＰ自身が用いているチャネルであるが、他のＤｉｓｃｏｖｅｒｙ Ｃｈａｎｎｅｌでもよい。なお、他にもＷＵＲ関連のイベントが存在するが、フローチャートへの図示および説明は省略する。
【００８７】
これらの処理の後、制御部２０２は、ＡＰ管理テーブル７００からＷＵＲ Ｄｉｓｃｏｖｅｒｙ ｅｌｅｍｅｎｔを構築し、ＢｅａｃｏｎまたはＰｒｏｂｅ Ｒｅｓｐｏｎｓｅによって接続対象のＳＴＡに送信する。このとき、状況によっては、ローミング先の候補となるＡＰの数を示すＷＵＲ ＡＰ Ｃｏｕｎｔ４１３のみが明示され、Ｓｈｏｒｔ−ＳＳＩＤ４２２、ＢＳＳＩＤ４２３、ＷＵＲ Ｄｉｓｃｏｖｅｒｙ Ｐｅｒｉｏｄ４２４が存在しない場合もある。このような情報も有効である。なぜなら、その情報を受けたＳＴＡは、ＷＵＲ Ｄｉｓｃｏｖｅｒｙ ｆｒａｍｅの待ち受けをいつまで継続するかを判断することができるからである。
【００８８】
以上、説明したように、実施形態では、ＡＰ１０１が、自身以外のＷＵＲ ＡＰに関する情報を随時収集しておくことで、接続対象のＳＴＡに対して、ローミング候補となるＡＰが動作しているチャネルを知るための情報を事前に通知することができる。ここで、随時とは、ＤＳＳ通信によるＳ８２４のタイミング、ＰＣＲによるＳ８３３またはＳ８４３のタイミング、ＷＵＲ通信によるＳ８５８のタイミングである。
【００８９】
＜他の実施形態＞
上述の実施形態では、ＤＳＳ、ＰＣＲ、ＷＵＲ関連の全てのイベント処理において、ＡＰ管理テーブル７００の更新をおこない、さらに全ての情報をＷＵＲ Ｄｉｓｃｏｖｅｒｙ ｅｌｅｍｅｎｔに反映させていた。しかし、条件に応じて、一部のイベント処理においてのみ、ＡＰ管理テーブル７００の更新をおこなったり、ＷＵＲ Ｄｉｓｃｏｖｅｒｙ ｅｌｅｍｅｎｔに一部のＡＰの情報を含めたりするようにしてもよい。以下、三つの変形例を示す。
【００９０】
＜変形例１：Ｍｕｌｔｉ−ＡＰを構成する全てのＡＰがＷＵＲの交換手順に対応しているとき＞
この条件のときは、Ｓ８２２以降の処理だけをおこなうようにしてもよい。これは、ＷＵＲの交換手順によって、ＷＵＲ Ｄｉｓｃｏｖｅｒｙ ｅｌｅｍｅｎｔを構成するための情報を取得できるからである。
【００９１】
＜変形例２：ＷＵＲ Ｄｉｓｃｏｖｅｒｙ ｅｌｅｍｅｎｔにＢＳＳＩＤが必要であるとき＞
この条件のときは、Ｓ８５６以降の処理を行わないようにしてもよい。その理由は、ＷＵＲ Ｄｉｓｃｏｖｅｒｙ ｆｒａｍｅを受信しても、それを送信したＡＰのＢＳＳＩＤは、すぐにはわからないからである。
【００９２】
＜変形例３：ＥＳＳＩＤ（Ｅｘｔｅｎｄｅｄ Ｓｅｒｖｉｃｅ Ｓｅｔ Ｉｄｅｎｔｉｆｉｅｒ）が同じＡＰをローミング先とするとき＞
この条件のときは、ＡＰ管理テーブル７００において、項目７０５（ｓｈｏｒｔ−ＳＳＩＤ）または項目７１０（Ｃｏｍｐｒｅｓｓｅｄ ＳＳＩＤ）が、ＡＰ１０１と同じＡＰの情報からＷＵＲ Ｄｉｓｃｏｖｅｒｙ ｅｌｅｍｅｎｔを構築する。
【００９３】
なお、変形例１〜３に例示した条件は、Ｓ８１６の「その他」の入力に対する処理において、設定可能となっている。
【００９４】
これら変形例１〜３によれば、最小限の通信処理による必要な情報の取得、および、必要な情報のみの送信を行うことになる。その結果、実施形態で述べた効果に加え、ＡＰの負荷軽減、通信媒体の利用効率の向上という効果が得られる。
【００９５】
（他の実施形態）
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
【００９６】
発明は上記実施形態に制限されるものではなく、発明の精神及び範囲から離脱することなく、様々な変更及び変形が可能である。従って、発明の範囲を公にするために請求項を添付する。
【図１】
2020184700.tif 000003
【図２】
2020184700.tif 000004
【図３】
2020184700.tif 000005
【図４Ａ】
2020184700.tif 000006
【図４Ｂ】
2020184700.tif 000007
【図５Ａ】
2020184700.tif 000008
【図５Ｂ】
2020184700.tif 000009
【図６Ａ】
2020184700.tif 000010
【図６Ｂ】
2020184700.tif 000011
【図６Ｃ】
2020184700.tif 000012
【図７】
2020184700.tif 000013
【図８Ａ】
2020184700.tif 000014
【図８Ｂ】
2020184700.tif 000015
【図８Ｃ】
2020184700.tif 000016
【図８Ｄ】
2020184700.tif 000017
【図８Ｅ】
2020184700.tif 000018