(57)【要約】【課題】ハンドオーバ前にリソースを予約できるアクセスポイントにおいて、移動局がいくつのアクセスポイントに対してリソースを要求しているか判らないため、正確なリソースの消費予測が立てられない。よってアクセスポイントは移動局からのリソース要求に対して適切な応答ができず、移動局はアクセスポイントの持つリソースを効率的に使用することができなかった。【解決手段】移動局はハンドオーバの候補先を調べ、その結果を格納し、その情報を用いて、どのアクセスポイントに既にリソースを予約しているか記録する。次に移動局は記録された情報からリソースを要求するアクセスポイント数を求めと要求するリソース量とあわせてリソース要求先のアクセスポイントへフレームを送信する。アクセスポイントはそのフレームを受信することで、要求されたリソースがどの程度の確率で実際に使用されるか予測することができる。【選択図】図３
2009088718.tif 000002
【特許請求の範囲】
【請求項１】
少なくとも１つのリソースの予約を行う通信装置と少なくとも1つのリソースの予約を受けつける通信装置を含む通信システムであって、前記リソースの予約を受けつける通信装置は、予約を行う通信装置が既に予約をしている通信装置数、予約をしようとしている通信装置数、または既に予約をしている通信装置数と予約をしようとしている通信装置数の各々を重み付けして合計した値のいずれかである予約実施通信装置数に基づいて、予約の受付を行うことを特徴とする通信システム。
【請求項２】
前記予約実施通信装置数は、前記リソースの予約を行う通信装置から前記リソースの予約を受けつける通信装置に通知されることを特徴とする請求項１に記載の通信システム。
【請求項３】
前記予約実施通信装置数は、前記予約を受けつける通信装置が、前記リソースの予約を行う通信装置から通知される予約を行う通信装置が既に予約をしている通信装置数と予約をしようとしている通信装置数から算出することを特徴とする請求項１に記載の通信システム。
【請求項４】
前記リソースの予約を行う通信装置は、前記リソースの予約を受けつける通信装置に、前記予約実施通信装置数、または予約を行う通信装置が既に予約をしている通信装置数と予約をしようとしている通信装置数とを、フレームに格納して送信することを特徴とする請求項１または２のいずれか1項に記載の通信システム。
【請求項５】
前記リソースの予約を行う通信装置は、前記リソースの予約を受けつける通信装置に前記予約実施通信装置数、または予約を行う通信装置が既に予約をしている通信装置数と予約をしようとしている通信装置数とを、リソースの予約を実行するプロトコル階層よりも上位のプロトコル階層において送信することを特徴とする請求項１または２のいずれか1項に記載の通信システム。
【請求項６】
前記リソースの予約を受けつける通信装置は、前記リソースの予約を行う通信装置からリソースの予約を受けつけたかを他の通信装置に対して問い合わせ、前記予約実施通信装置数を得ることを特徴とする請求項１に記載の通信システム。
【請求項７】
前記リソースの予約を受けつける通信装置は、前記リソースの予約を行う通信装置からリソースの予約を受けつけた後に他の通信装置に対して予約を受けつけたことを通知し、他の通信装置は前記通知に基づいて前記リソースの予約を行う通信装置の予約実施通信装置数を得ることを特徴とする請求項１に記載の通信システム。
【請求項８】
前記リソースの予約を受けつける通信装置は、該通信装置が現在使用しているリソース量と、前記リソースの予約を行う通信装置が予約をしてきたリソース量を前記予約実施通信装置数で除算したものとを合計したものと、前記リソースの予約を受けつける通信装置が保有している全リソース量とを比較することで予約の受付を行うことを特徴とする請求項１から７のいずれか１項に記載の通信システム。
【請求項９】
前記リソースの予約を受けつける通信装置は、現在使用しているリソース量と、前記リソースの予約を行う通信装置が予約をしてきたリソース量を前記予約実施通信装置数で除算したものと、リソースの予約を行う他の通信装置が予約をしているリソース量の各々を該通信装置に関する予約実施通信装置数で各々除算したものとを合計したものと前記リソースの予約を受けつける通信装置が保有している全リソースとを比較することで予約の受付を行うことを特徴とする請求項１から７のいずれか1項に記載の通信システム。
【請求項１０】
前記リソースの予約を受けつける通信装置は、現在使用しているリソース量と、前記リソースの予約を行う通信装置が予約をしてきたリソース量と、前記リソースの予約を行う他の通信装置が予約をしているリソース量の各々を該通信装置に関する前記予約実施通信装置数の各々で除算したものとを合計したものと、前記リソースの予約を受けつける通信装置が保有している全リソース量とを比較することで予約の受付を行うことを特徴とする請求項１から７のいずれか１項に記載の通信システム。
【請求項１１】
前記リソースの予約を受けつける通信装置は、前記リソース量の比較を行った結果により予約を受諾するか拒否するかを決定し、前記リソースの予約を行う通信装置に前記決定内容を通知することを特徴とする請求項８から１０のいずれか1項に記載の通信システム。
【請求項１２】
前記リソースの予約を行う通信装置から予約されたリソースを割り当てることができないと判断したときに前記リソースの予約を受けつける通信装置は前記リソースの予約を行う通信装置に対してリソースを割り当てることができない可能性があることを示すフレームを送信することを特徴とする請求項８から１０のいずれか1項に記載の通信システム。
【請求項１３】
前記リソースの予約を行う通信装置は、移動局であり、前記リソースの予約を受け付ける通信装置はアクセスポイントであることを特徴とする請求項１から１２のいずれか1項に記載の通信システム。
【請求項１４】
前記リソースの予約を行う通信装置と前記リソースの予約を受け付ける通信装置は、ともに移動局であることを特徴とする請求項１から１２のいずれか1項に記載の通信システム。
【請求項１５】
リソースの予約を受けつける通信装置であって、予約を行う通信装置が既に予約をしている通信装置数、予約をしようとしている通信装置数、または既に予約をしている通信装置数と予約をしようとしている通信装置数の各々を重み付けして合計した値のいずれかである予約実施通信装置数に基づいて、予約の受付を行うリソース予約受付判断手段と前記予約を行う通信装置から受け付けたリソースの予約状態について管理を行うリソース管理手段とを有することを特徴とする通信装置。
【請求項１６】
前記リソース予約受付判断手段は、前記予約実施通信装置数としてリソースの予約を行う通信装置から通知された値を用いることを特徴とする請求項１５に記載の通信装置。
【請求項１７】
前記予約を受けつける通信装置は、前記予約を受けつける通信装置が、前記リソースの予約を行う通信装置から通知される予約を行う通信装置が既に予約をしている通信装置数と予約をしようとしている通信装置数から前記予約実施通信装置数を算出する合計数処理手段を有することを特徴とする請求項１５または１６に記載の通信装置。
【請求項１８】
前記予約を受けつける通信装置は、前記予約を行う通信装置からリソースの予約を受けつけたかを他の予約を受けつける通信装置に対して問い合わせる予約実施アクセスポイント数調査手段と前記問い合わせのパケットを送受信する予約実施アクセスポイント数調査パケット送受信手段と他の予約を受けつける通信装置からの問い合わせに対する応答を行う予約実施アクセスポイント数調査依頼応答手段とを有することを特徴とする請求項１５に記載の通信装置。
【請求項１９】
前記予約を受けつける通信装置は、前記予約を行う通信装置からリソースの予約を受けつけた際に前記他の予約を受けつける通信装置に対して通知するリソース要求受付通知パケット送信手段と他の予約を受けつける通信装置からの通知を受信するリソース要求受付通知パケット受信手段と他の予約を受けつける通信装置から受信した通知パケットを一時的に保存するリソース要求受付通知管理データベースを有することを特徴とする請求項１５に記載の通信装置。
【請求項２０】
前記リソース予約受付判断手段は、現在使用しているリソースと、前記予約を行う通信装置が予約をしているリソースを前記予約実施通信装置数で除算したものとを合計したものと前記通信装置が保有している全リソースとを比較することで予約の受付を行うことを特徴とする請求項１５から１９のいずれか１項に記載の通信装置。
【請求項２１】
前記リソース予約受付判断手段は、現在使用しているリソースと、前記予約を行う通信装置が予約をしているリソースを前記予約実施通信装置数で除算したものと、前記他の予約を行う通信装置が予約をしているリソースを予約実施通信装置数で除算したものとを合計したものと前記通信装置が保有している全リソースとを比較することで予約の受付を行うことを特徴とする請求項１５から１９のいずれか１項に記載の通信装置。
【請求項２２】
前記リソース予約受付判断手段は、現在使用しているリソースと、前記予約を行う通信装置が予約をしているリソースと、前記他の予約を行う通信装置が予約をしているリソースを前記予約実施通信装置数で除算したものとを合計したものと前記通信装置が保有している全リソースとを比較することで予約の受付を行うことを特徴とする請求項１５から１９のいずれか１項に記載の通信装置。
【請求項２３】
前記リソース予約受付判断手段は、前記リソースの比較を行った結果により予約を受諾するか拒否するかを決定し、その内容を前記予約を行う通信装置に通知することを特徴とする請求項２０から２２のいずれか1項に記載の通信装置。
【請求項２４】
前記予約を受けつける通信装置は、前記予約を行う通信装置から予約されたリソースを割り当てることができないと判断したときに前記予約を受けつける通信装置は前記予約を行う通信装置に対してリソースを割り当てることができない可能性があることを示すフレームを送信するリソースＦｕｌｌ通知手段を有することを特徴とする請求項２０から２３のいずれか1項に記載の通信装置。
【請求項２５】
リソースの予約を行う通信装置であって、予約を行う通信装置が既に予約をしている通信装置数、予約をしようとしている通信装置数、または既に予約をしている通信装置数と予約をしようとしている通信装置数の各々を重み付けして合計した値のいずれかである予約実施通信装置数、または予約を行う通信装置が既に予約をしている通信装置数と予約をしようとしている通信装置数とを通知するリソース予約処理手段を有することを特徴とする通信装置。
【請求項２６】
前記リソースの予約を行う通信装置であって、前記予約実施通信装置数、または予約を行う通信装置が既に予約をしている通信装置数と予約をしようとしている通信装置数とを前記予約を行う通信装置が送信するリソース要求フレームに格納する合計数通知対応リソース事前要求フレーム発行要求手段と予約を受けつける通信装置に通知を行う合計数通知対応リソース事前要求フレーム生成手段とを有することを特徴とする請求項２５に記載の通信装置。
【請求項２７】
前記リソースの予約を行う通信装置であって、前記予約実施通信装置数、または予約を行う通信装置が既に予約をしている通信装置数と予約をしようとしている通信装置数とをリソースの予約を実行するプロトコル階層よりも上位のプロトコル階層において送信するリソース予約数通知手段を有することを特徴とする請求項２５に通信装置。
【請求項２８】
前記リソースの予約を受けつける通信装置は、アクセスポイントであることを特徴とする請求項１５から２４のいずれか1項に記載の通信装置。
【請求項２９】
前記リソースの予約を受けつける通信装置は、移動局であることを特徴とする請求項１５から２４のいずれか1項に記載の通信装置。
【請求項３０】
前記リソースの予約を行う通信装置は、移動局であることを特徴とする請求項２５から２７のいずれか1項に記載の通信装置。
【請求項３１】
予約を受けつける通信装置のリソースの予約受付を判断する方法であって、予約を行う通信装置が既に予約をしている通信装置数、予約をしようとしている通信装置数、または既に予約をしている通信装置数と予約をしようとしている通信装置数の各々を重み付けして合計した値のいずれかである予約実施通信装置数に基づいて、予約の受付を判断することを特徴とする予約受付判断方法。
【請求項３２】
前記予約実施通信装置数は、前記リソースの予約を行う通信装置から通知される予約を行う通信装置が既に予約をしている通信装置数と予約をしようとしている通信装置数から算出することを特徴とする請求項３１に記載の予約受付判断方法。
【請求項３３】
予約を受けつける通信装置のリソースの予約受付を判断する方法であって、前記リソースの予約を受けつける通信装置が現在使用しているリソース量と、前記リソースの予約を行う通信装置が予約をしてきたリソース量を前記予約実施通信装置数で除算したものとを合計し、前記リソースの予約を受けつける通信装置が保有している全リソース量と比較することを特徴とする請求項３１または３２のいずれか1項に記載の予約受付判断方法。
【請求項３４】
予約を受けつける通信装置のリソースの予約受付を判断する方法であって、前記リソースの予約を受けつける通信装置が現在使用しているリソース量と、前記リソースの予約を行う通信装置が予約をしてきたリソース量を前記予約実施通信装置数で除算したものと、リソースの予約を行う他の通信装置が予約をしているリソース量の各々を該通信装置に関する予約実施通信装置数で各々除算したものとを合計し、前記リソースの予約を受けつける通信装置が保有している全リソース量と比較することを特徴とする請求項３１または３２のいずれか1項に記載の予約受付判断方法。
【請求項３５】
予約を受けつける通信装置のリソースの予約受付を判断する方法であって、前記リソースの予約を受けつける通信装置が現在使用しているリソース量と、前記リソースの予約を行う通信装置が予約をしてきたリソース量と、リソースの予約を行う他の通信装置が予約をしているリソース量の各々を該通信装置に関する予約実施通信装置数で各々除算したものとを合計し、前記リソースの予約を受けつける通信装置が保有している全リソース量と比較することを特徴とする請求項３１または３２のいずれか1項に記載の予約受付判断方法。
【請求項３６】
予約を行う通信装置が既に予約をしている通信装置数、予約をしようとしている通信装置数、または既に予約をしている通信装置数と予約をしようとしている通信装置数の各々を重み付けして合計した値のいずれかである予約実施通信装置数、または予約を行う通信装置が既に予約をしている通信装置数と予約をしようとしている通信装置数とを通知する方法であって、前記予約実施通信装置数をリソース要求フレームに格納して送信することを特徴とする通知方法。
【請求項３７】
予約を行う通信装置が既に予約をしている通信装置数、予約をしようとしている通信装置数、または既に予約をしている通信装置数と予約をしようとしている通信装置数の各々を重み付けて合計した値のいずれかである予約実施通信装置数、または予約を行う通信装置が既に予約をしている通信装置数と予約をしようとしている通信装置数とを通知する方法であって、前記予約実施通信装置数をリソースの予約を実行するプロトコル階層よりも上位のプロトコル階層において送信することを特徴とする通知方法。
【請求項３８】
情報処理装置のプログラムであって、前記プログラムは、前記情報処理装置に予約を行う通信装置が既に予約をしている通信装置数、予約をしようとしている通信装置数、または既に予約をしている通信装置数と予約をしようとしている通信装置数の各々を重み付けして合計した値のいずれかである予約実施通信装置数に基づいて、予約を受けつける通信装置のリソースの予約の受付の処理を実行させることを特徴とするプログラム。
【請求項３９】
情報処理装置のプログラムであって、前記プログラムは、前記情報処理装置に前記予約実施通信装置数を、前記予約を受けつける通信装置が、前記リソースの予約を行う通信装置から通知される予約を行う通信装置が既に予約をしている通信装置数と予約をしようとしている通信装置数から算出させ、予約を受けつける通信装置のリソースの予約の受付の処理を実行させることを特徴とする請求項３８に記載のプログラム。
【請求項４０】
情報処理装置のプログラムであって、前記プログラムは、前記情報処理装置に前記リソースの予約を受けつける通信装置が現在使用しているリソース量と、前記リソースの予約を行う通信装置が予約をしてきたリソース量を前記予約実施通信装置数で除算したものとを合計し、前記リソースの予約を受けつける通信装置が保有している全リソース量と比較して予約を受けつける通信装置のリソースの予約の受付の処理を実行させることを特徴とする請求項３８または３９のいずれか1項に記載のプログラム。
【請求項４１】
情報処理装置のプログラムであって、前記プログラムは、前記情報処理装置に前記リソースの予約を受けつける通信装置が現在使用しているリソース量と、前記リソースの予約を行う通信装置が予約をしてきたリソース量を前記予約実施通信装置数で除算したものと、リソースの予約を行う他の通信装置が予約をしているリソース量の各々を該通信装置に関する予約実施通信装置数で各々除算したものとを合計し、前記リソースの予約を受けつける通信装置が保有している全リソース量と比較して予約を受けつける通信装置のリソースの予約の受付の処理を実行させることを特徴とする請求項３８または３９のいずれか1項に記載のプログラム。
【請求項４２】
情報処理装置のプログラムであって、前記プログラムは、前記情報処理装置に前記リソースの予約を受けつける通信装置が現在使用しているリソース量と、前記リソースの予約を行う通信装置が予約をしてきたリソース量と、リソースの予約を行う他の通信装置が予約をしているリソース量の各々を該通信装置に関する予約実施通信装置数で各々除算したものとを合計し、前記リソースの予約を受けつける通信装置が保有している全リソース量と比較して予約を受けつける通信装置のリソースの予約の受付の処理を実行させることを特徴とする請求項３８または３９のいずれか1項に記載のプログラム。
【請求項４３】
情報処理装置のプログラムであって、前記プログラムは、前記情報処理装置に予約を行う通信装置が既に予約をしている通信装置数、予約をしようとしている通信装置数、または既に予約をしている通信装置数と予約をしようとしている通信装置数の各々を重み付けして合計した値のいずれかである予約実施通信装置数をリソース要求フレームに格納して送信する処理を実行させることを特徴とするプログラム。
【請求項４４】
情報処理装置のプログラムであって、前記プログラムは、前記情報処理装置に予約を行う通信装置が既に予約をしている通信装置数、予約をしようとしている通信装置数、または既に予約をしている通信装置数と予約をしようとしている通信装置数の各々を重み付けして合計した値のいずれかである予約実施通信装置数をリソースの予約を実行するプロトコル階層よりも上位のプロトコル階層において送信する処理を実行させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信リソースの予約を行うシステム、装置等に関する。
【背景技術】
【０００２】
従来、無線ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）では移動局が現在使用しているアクセスポイントから別のアクセスポイントへハンドオーバを行う前に、ハンドオーバ先のアクセスポイントに対して事前にリソースを予約することができなかった。ここで、リソースとは、例えば通信速度に応じて使用される電力、メモリの量、周波数帯域または通信速度そのものなどを指す。そのため、ハンドオーバが発生したときに、ハンドオーバ先のアクセスポイントで通信の継続に必要なリソースが確保できない場合は、ハンドオーバに失敗してしまう。
【０００３】
しかしＩＥＥＥ（Ｔｈｅ  Ｉｎｓｔｉｔｕｔｅ  ｏｆ  Ｅｌｅｃｔｒｉｃａｌ  ａｎｄ  Ｅｌｅｃｔｒｏｎｉｃｓ  Ｅｎｇｉｎｅｅｒｓ）  ８０２．１１ｒ規格によって無線ＬＡＮにおいてもハンドオーバ前に事前にアクセスポイントに対して通信リソースを予約することが可能になった。これにより、ハンドオーバを失敗する確率を減らすことができる。
【０００４】
ＩＥＥＥ  ８０２．１１ｒ規格（Ｄｒａｆｔ  ７．０）で規定されているハンドオーバについて、図１と図２を用いて説明する。
【０００５】
図１は、無線LANシステムの構成を示す図である。図１の無線LANシステムは、移動局（１１１）、移動局（１１１）が無線通信によりアクセスする複数のアクセスポイント（１０１〜１０７）と、移動局（１１１）がモビリティドメインのネットワークにアクセスすることが許された移動局であることの認証をする認証サーバ（１３１）から構成されており、アクセスポイント（１０１〜１０７）と認証サーバ（１３１）は有線ネットワークにより接続されている。
【０００６】
図２は、ＩＥＥＥ  ８０２．１１ｒ規格（Ｄｒａｆｔ  ７．０）で規定されているハンドオーバ時のシーケンスを示すシーケンス図である。移動局（１１１）は図１のようにアクセスポイント（１０３）の配下に居て、アクセスポイント（１０３）と通信中であり、アクセスポイント（１０４）の方向に向かっているとする。このとき、移動局（１１１）はアクセスポイント１０４に対して事前にリソースを予約するために、最初に８０２．１１  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｒｅｑｕｅｓｔ（２０１）を送信する。するとアクセスポイント１０４は移動局（１１１）に対して８０２．１１  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｒｅｓｐｏｎｓｅを返信する（２０２）。本フレームを受信すると移動局（１１１）は予約したいリソース量に関する情報を載せた８０２．１１  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｃｏｎｆｉｒｍフレームを送信する（２０３）。それに対してアクセスポイント１０４はそのリソース予約を受け付けるか受け付けないかの返答を載せた８０２．１１  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  ＡＣＫフレームを返信する（２０４）。
【０００７】
移動局が要求したリソースが受け入れられた場合は事前予約に関するフレーム交換はこれで終わりだが、受け入れられなかった場合は、移動局は予約したいリソース量を変更して再度のリソース予約をアクセスポイント１０４に対して提示することも可能である。この後、初めてこの移動局（１１１）がモビリティドメイン（１４１）に入った際にあるアクセスポイントとの間で行われるＦａｓｔ  ＢＳＳ  Ｔｒａｎｓｉｔｉｏｎ  Ｉｎｉｔｉａｌ  Ｍｏｂｉｌｉｔｙ  Ｄｏｍａｉｎ  Ａｓｓｏｃｉａｔｉｏｎ時にそのアクセスポイントから通知されたＡｕｔｈｅｎｔｉｃａｔｉｏｎ  ＡＣＫフレーム内で示される期限Ｒｅａｓｓｏｃｉａｔｉｏｎ  ＤｅａｄｌｉｎｅまでにＲｅａｓｓｏｃｉａｔｉｏｎ  Ｒｅｑｕｅｓｔ（２０５）を発行すれば、８０２．１１  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｃｏｎｆｉｒｍフレーム（２０３）で予約したリソースが有効となり、そのリソースを用いてアクセスポイント１０４との通信が可能となる（例えば、非特許文献１参照。）。Ｒｅａｓｓｏｃｉａｔｉｏｎ  Ｒｅｑｕｅｓｔ（２０５）に対してアクセスポイント１０４はＲｅａｓｓｏｃｉａｔｉｏｎ  Ｒｅｓｐｏｎｓｅ（２０６）を送信する。
【０００８】
特許文献１には、ハンドオーバ時に移動局固有の優先度に基づいて決定される数の予約基地局数の基地局に対して、移動局が、直接又は他の基地局を介して予約を行う技術が開示されている。具体的には、直接移動局が基地局に対して予約を行う場合は、移動局が基地局数分の基地局に個別に予約情報を送信し、他の基地局を介する場合には移動局は予約基地局数を含めた予約情報を現在通信中の基地局に送信し、さらにその予約情報を受信した基地局が、予約基地局数分の近隣基地局を選択して、予約情報を転送することによって予約基地局数の基地局に対してのリソースを予約する技術が開示されている。予約を移動局から直接、または他の基地局を介して受信した各基地局は、移動局から要求されているリソース量と自局の空きリソース量を比較し、空きリソース量が要求されているリソース量以上ならば予約の受け入れを行い、空きリソース量が要求されているリソース量未満ならばリソース予約の受け入れの拒否を行う。
【０００９】
【特許文献１】特願２００４−２６６７１３号公報（第４−９頁）
【非特許文献１】ＩＥＥＥ  ８０２．１１ｒ規格、Ｄｒａｆｔ  ７．０、２００７年７月、１１Ａ６節  第６１−６７頁
【発明の開示】
【発明が解決しようとする課題】
【００１０】
しかしながら特許文献１で記載した移動通信システムにおいて、基地局は移動局から要求されているリソース量と空きリソース量を比較してリソース予約の受け入れを判断している。移動局がハンドオーバするのは複数予約したうちの１つの基地局であるにも関わらず、１つの基地局の空きリソース量と要求されているリソース量との比較により、予約の受け入れを行うか否かを判断している。予約が行われたリソース量だけ他の移動局が予約または使用できるリソース量が減るため、特定の移動局が多数の基地局のリソースを予約してしまった場合には、基地局にリソースの予約を受け付けて貰うことができる移動局の数が減ってしまう、または移動局が予約を受け付けてもらえる基地局の数が減ってしまうなど、リソースの予約を効率的にできないという問題があった。 
そこで、本発明は上記問題を解決することを課題とし、その目的は、効率的なリソース予約ができる通信システム、装置、およびその方法、プログラムを提供することにある。
【課題を解決するための手段】
【００１１】
上記課題を解決する本発明は、少なくとも１つのリソースの予約を行う通信装置と少なくとも１つのリソースの予約を受けつける通信装置を含む通信システムであって、前記リソースの予約を受けつける通信装置は、予約を行う通信装置が既に予約をしている通信装置数、予約をしようとしている通信装置数、または既に予約をしている通信装置数と予約をしようとしている通信装置数の各々を重み付けして合計した値のいずれかである予約実施通信装置数に基づいて、予約の受付を行うことを特徴とする。
【００１２】
上記課題を解決する本発明は、リソースの予約を受けつける通信装置であって、予約を行う通信装置が既に予約をしている通信装置数、予約をしようとしている通信装置数、または既に予約をしている通信装置数と予約をしようとしている通信装置数の各々を重み付けして合計した値のいずれかである予約実施通信装置数に基づいて、予約の受付を行うリソース予約受付判断手段と前記予約を行う通信装置から受け付けたリソースの予約状態について管理を行うリソース管理手段とを有することを特徴とする。
【００１３】
上記課題を解決する本発明は、リソースの予約を行う通信装置であって、予約を行う通信装置が既に予約をしている通信装置数、予約をしようとしている通信装置数、または既に予約をしている通信装置数と予約をしようとしている通信装置数の各々を重み付けして合計した値のいずれかである予約実施通信装置数、または予約を行う通信装置が既に予約をしている通信装置数と予約をしようとしている通信装置数とを通知するリソース予約処理手段を有することを特徴とする。
【００１４】
上記課題を解決する本発明は、予約を受けつける通信装置のリソースの予約受付を判断する方法であって、予約を行う通信装置が既に予約をしている通信装置数、予約をしようとしている通信装置数、または既に予約をしている通信装置数と予約をしようとしている通信装置数の各々を重み付けして合計した値のいずれかである予約実施通信装置数に基づいて、予約の受付を判断することを特徴とする。
【００１５】
上記課題を解決する本発明は、予約を行う通信装置が既に予約をしている通信装置数、予約をしようとしている通信装置数、または既に予約をしている通信装置数と予約をしようとしている通信装置数の各々を重み付けして合計した値のいずれかである予約実施通信装置数、または予約を行う通信装置が既に予約をしている通信装置数と予約をしようとしている通信装置数とを通知する方法であって、前記予約実施通信装置数をリソース要求フレームに格納して送信することを特徴とする。
【００１６】
上記課題を解決する本発明は、情報処理装置のプログラムであって、前記プログラムは、前記情報処理装置に予約を行う通信装置が既に予約をしている通信装置数、予約をしようとしている通信装置数、または既に予約をしている通信装置数と予約をしようとしている通信装置数の各々を重み付けして合計した値のいずれかである予約実施通信装置数に基づいて、予約を受けつける通信装置のリソースの予約の受付の処理を実行させることを特徴とする。
【００１７】
上記課題を解決する本発明は、情報処理装置のプログラムであって、前記プログラムは、前記情報処理装置に予約を行う通信装置が既に予約をしている通信装置数、予約をしようとしている通信装置数、または既に予約をしている通信装置数と予約をしようとしている通信装置数の各々を重み付けして合計した値のいずれかである予約実施通信装置数をリソース要求フレームに格納して送信する処理を実行させることを特徴とする。
【発明の効果】
【００１８】
本発明によれば、リソースの予約を受けつける通信装置が、リソースの予約を行う通信装置の予約実施通信装置数に基づいて予約の受付を行うことにより、効率的なリソース予約が可能となる。
【発明を実施するための最良の形態】
【００１９】
（第１の実施の形態）
【００２０】
本実施の形態ではリソースの予約を受けつける通信装置は、リソースの予約を行う通信装置の予約実施通信装置数に基づいて、予約の受付を行う。予約実施通信装置数とは予約を行う通信装置が既に予約をしている通信装置数、予約をしようとしている通信装置数、または既に予約をしている通信装置数と予約をしようとしている通信装置数の各々を重み付けして合計した値のいずれかであるが、ここでは一例としてリソースの予約を行う通信装置が既に予約をしている通信装置数を予約実施通信装置数としてリソースの予約を受けつける通信装置に通知するものとして説明する。
【００２１】
以下、予約を受けつける通信装置をアクセスポイント、予約を行う通信装置を移動局とし、アクセスポイントと移動局からなる無線ＬＡＮシステムを一例として、説明する。
［発明の構成］
図１は、本発明の一実施の形態としてのネットワークの構成を示す図である。図1で示されるネットワークは、アクセスポイント（１０１〜１０７）、移動局（１１１）、ネットワーク（１２１）、認証サーバ（１３１）、外部ネットワーク（１５１）から構成される。
【００２２】
アクセスポイント（１０１〜１０７）は、リソース管理機能を提供するアクセスポイントである。以下では、ＩＥＥＥ  ８０２．１１ｅ規格、および高速なハンドオーバ機能を提供するＩＥＥＥ  ８０２．１１ｒ規格に準拠したアクセスポイントを例として説明する。それぞれのアクセスポイントは例えばＩＥＥＥ８０２．３で規定されているようなネットワークで互いに接続されており、また外部のネットワーク（１５１）とも接続されている。また、説明を簡単とするために、以下では、これらのアクセスポイントは同一のモビリティドメインに属すると仮定する。そして、アクセスポイント間であれば、ハンドオーバを実施することが可能であるとする。ここで、モビリティドメインとは、例えば移動局が同一モビリティドメインに属するアクセスポイント間であれば、ＩＥＥＥ  ８０２．１１ｒに準拠した高速なハンドオーバを実施することが可能であるようなドメインのことである。これらのアクセスポイントは、ＩＥＥＥ  ８０２．１１ｋ規格で規定される方式に従って、自身の近隣に存在するアクセスポイントの情報を交換できる機能を持っていても良い。
【００２３】
移動局（１１１）は、無線通信機能を備えた移動局である。以下では、ＩＥＥＥ  ８０２．１１ｅ規格およびＩＥＥＥ  ８０２．１１ｒに準拠した無線ＬＡＮ機能を備えた移動局を例として説明する。
【００２４】
認証サーバ（１３１）は例えばＲＡＤＩＵＳプロトコルなどを用いて、移動局（１１１）がアクセスポイント（１０１〜１０７）に接続する際に、移動局（１１１）がモビリティドメインのネットワークにアクセスすることが許された移動局であることを認証するためのサーバである。
【００２５】
外部ネットワーク（１５１）は、モビリティドメイン１４１に属さないネットワークである。
【００２６】
次に図３の移動局の構成図を参照して、本発明の一実施の形態としての移動局（１１１）の構成例を説明する。図３によると移動局（１１１）は、アプリケーション（３０１）、ＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）部（３０２）、ＭＡＣ（Ｍｅｄｉｕｍ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ）部（３０３）、ＰＨＹ（Ｐｈｙｓｉｃａｌ  ｌａｙｅｒ）部（３０４）、アンテナ（３０５）、ＰＬＭＥ（Ｐｈｙｓｉｃａｌ  Ｌａｙｅｒ  Ｍａｎａｇｅｍｅｎｔ  Ｅｎｔｉｔｙ）部（３０６）、ＭＬＭＥ（ＭＡＣ  Ｌａｙｅｒ  Ｍａｎａｇｅｍｅｎｔ  Ｅｎｔｉｔｙ）部（３０７）、ＳＭＥ（Ｓｔａｔｉｏｎ  Ｍａｎａｇｅｍｅｎｔ  Ｅｎｔｉｔｙ）部（３０８）から構成される。
【００２７】
アプリケーション（３０１）はＴＣＰ／ＩＰ部（３０２）、ＭＡＣ部（３０３）、ＰＨＹ部（３０４）と経て、他のノードと通信するアプリケーションであり、例えばＶｏＩＰ（Ｖｏｉｃｅ  ｏｖｅｒ  ＩＰ）を用いて音声通話を実現するアプリケーションなどである。
【００２８】
ＴＣＰ／ＩＰ部（３０２）は、ＯＳＩ参照モデルにおけるトランスポート層と、トランスポート層の下位に当たるネットワーク層の処理を行うものである。トランスポート層は標準化団体ＩＥＦＴ（Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ）が規定したＲＦＣ（Ｒｅｑｕｅｓｔ  Ｆｏｒ  Ｃｏｍｍｅｎｔ）７９３で規定されており、ネットワーク層はＲＦＣ７９１で規定されている。また一般的なＴＣＰ／ＩＰ実装にはＵＤＰ（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ）も搭載されており、これはＲＦＣ７６８で規定されている。なお、本例ではＴＣＰ／ＩＰとして記載しているがＡＴＭ（Ａｓｙｎｃｈｒｏｎｏｕｓ  Ｔｒａｎｓｆｅｒ  Ｍｏｄｅ）など他のプロトコルで規定されている処理を行うものでもよい。
【００２９】
ＭＡＣ部（３０３）は、ＩＥＥＥ  ８０２．１１ｅ規格およびＩＥＥＥ  ８０２．１１ｒ規格で規定されるＭＡＣ機能を処理する。このＭＡＣ部（３０３）は、後に図１２を用いて説明する、予約実施アクセスポイント数を搭載することのできるＡｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｃｏｎｆｉｒｍフレームを生成する機能を持つ合計数通知対応リソース事前要求フレーム生成手段（３１５）を含む。
【００３０】
ＰＨＹ部（３０４）はＯＳＩ参照モデルの物理層（Ｐｈｙｓｉｃａｌ  Ｌａｙ
ｅｒ）の処理を行うものであり、例えばＩＥＥＥ  ８０２．１１ｇに準拠するものである。ＭＡＣ部（３０３）から送られてくるフレームを電波信号に変調しアンテナ（３０５）を通して送信する機能、およびアンテナ（３０５）から受信した電波信号を復調し、受信フレームとしてＭＡＣ部（３０３）へ渡す機能を持つ。
【００３１】
ＰＬＭＥ部（３０６）はＰＨＹ部（３０４）を制御するためのエンティティであり、ＩＥＥＥ  ８０２．１１ｇ、ＩＥＥＥ  ８０２．１１ｅ、ＩＥＥＥ  ８０２．１１ｒで規定されるＭＬＭＥ＿ＰＬＭＥ＿ＳＡＰ（Ｓｅｒｖｉｃｅ  Ａｃｃｅｓｓ  Ｐｏｉｎｔ）およびＰＬＭＥ＿ＳＡＰを処理できるものである。
【００３２】
ＭＬＭＥ部（３０７）はＳＭＥ部（３０８）からの指示に従い、ＭＡＣ部（３０３）を制御するエンティティである。なお本実施の形態で用いるＭＬＭＥ部（３０７）は、ＩＥＥＥ  ８０２．１１ｇ、ＩＥＥＥ  ８０２．１１ｅ、ＩＥＥＥ  ８０２．１１ｒで規定されるＭＬＭＥ＿ＳＡＰを処理する機能に加え、予約実施アクセスポイント数をＳＭＥ部（３０８）から受け付けると、その数を格納した図１２で説明するＡｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｃｏｎｆｉｒｍフレームを生成するようにＭＡＣ部（３０３）へ依頼する機能である合計数通知対応リソース事前要求フレーム発行要求手段（３１６）を含む。
【００３３】
また、ＳＭＥ部（３０８）から周辺のアクセスポイントを探索するためにＭＬＭＥ−ＳＣＡＮ．ｒｅｑｕｅｓｔプリミティブを受け取ると、各アクセスポイントの受信電界強度をＭＬＭＥ−ＳＣＡＮ．ｃｏｎｆｉｒｍのパラメータのＢＳＳＤｅｓｃｒｉｐｔｉｏｎとともにＳＭＥ部（３０８）に返す機能がついているものとする。各アクセスポイントの受信電界強度とは、アクティブスキャンの場合はアクセスポイントからのＰｒｏｂｅ  Ｒｅｓｐｏｎｓｅフレームの受信電界強度であり、パッシブスキャンの場合はアクセスポイントからのビーコンフレームの受信電界強度である。受信電界強度はＰＨＹ部（３０４）でフレームを受信するごとに得ることのできる値である。またビーコンフレームの受信電界強度については、パッシブスキャンを実行したときのみならず、帰属しているアクセスポイントからビーコンフレームを受信するごとに、ＳＭＥ部（３０８）へ通知できるものとする。
【００３４】
次にＳＭＥ部（３０８）はアプリケーション（３０１）が目的の相手と通信できるようにＭＡＣ部（３０３）、ＰＨＹ部（３０４）をＭＬＭＥ部（３０７）、ＰＬＭＥ部（３０６）を通して制御・管理するエンティティである。本実施の形態で説明するＳＭＥ部（３０８）は、ハンドオーバ管理手段（３０９）、ハンドオーバ先候補調査手段（３１０）、調査結果格納手段（３１１）、リソース要求先決定手段（３１２）、リソース予約処理手段（３１３）を含む。ＳＭＥ要求手段（３１４）はＳＭＥ部（３０８）のうち特にハンドオーバ管理手段（３０９）、ハンドオーバ先候補調査手段（３１０）、調査結果格納手段（３１１）、リソース要求先決定手段（３１２）、リソース予約処理手段（３１３）から構成されるものである。
【００３５】
ハンドオーバ管理手段（３０９）は、移動局（１１１）が安定して通信を継続できるようにアクセスポイントへの帰属処理を制御する手段である。具体的には移動局（１１１）がまだどのアクセスポイントにも帰属していない場合は、例えばＭＬＭＥ−ＳＣＡＮ．ｒｅｑｕｅｓｔプリミティブをＭＬＭＥ部（３０７）に対して発行し、それに対する応答であるＭＬＭＥ−ＳＣＡＮ．ｃｏｎｆｉｒｍプリミティブをＭＬＭＥ部（３０７）より受信すると、得られたアクセスポイントの中から最も受信電界強度の高いアクセスポイントを選択し、そのアクセスポイントに帰属するためにＭＬＭＥ−ＡＵＴＨＥＮＴＩＣＡＴＥ．ｒｅｑｕｅｓｔ、ＭＬＭＥ−ＡＳＳＯＣＩＡＴＥ．ｒｅｑｕｅｓｔプリミティブをＭＬＭＥ部（３０７）に発行する。
【００３６】
あるアクセスポイントに帰属すると、ハンドオーバ管理手段（３０９）はＰＨＹ部（３０４）で得た現在帰属しているアクセスポイントの受信電界強度をＭＬＭＥ部（３０７）経由で受信し、その値を監視する。もしその受信電界強度が安定的に通信を継続できる最低のレベルよりもやや大きい値を下回ると、ハンドオーバ先候補調査手段（３１０）へハンドオーバ先候補を探すように依頼する。ハンドオーバ先候補調査手段（３１０）から調査が完了した旨の通知を受けると、次にリソース要求先決定手段（３１２）に対して調査結果をもとにリソースを要求するアクセスポイントを決定しリソースを要求するよう依頼する。そして現在帰属中のアクセスポイントのビーコンフレームの受信電界強度が受信電界強度が安定的に通信を継続できる最低のレベルとなった場合、ハンドオーバ管理手段（３０９）はＭＬＭＥ−ＳＣＡＮ．ｒｅｑｕｅｓｔプリミティブをＭＬＭＥ部（３０７）に対して発行する。
【００３７】
ＭＬＭＥ−ＳＣＡＮ．ｃｏｎｆｉｒｍで得られた周辺アクセスポイントの受信電界強度の結果と、調査結果格納手段（３１１）に格納されているリソースの確保状況を勘案してハンドオーバ先を決定し、そのハンドオーバ先に帰属するためにＭＬＭＥ−ＡＵＴＨＥＮＴＩＣＡＴＥ．ｒｅｑｕｅｓｔ、ＭＬＭＥ−ＲＥＡＳＳＯＣＩＡＴＥ．ｒｅｑｕｅｓｔプリミティブを発行する。
【００３８】
ハンドオーバ先候補調査手段（３１０）は、ハンドオーバ管理手段（３０９）からハンドオーバ先の候補を探すように依頼を受けると、周辺アクセスポイントの受信電界強度を調べるためにＭＬＭＥ部（３０７）に対してＭＬＭＥ−ＳＣＡＮ．ｒｅｑｕｅｓｔプリミティブを発行する。
【００３９】
ＭＬＭＥ−ＳＣＡＮ．ｒｅｑｕｅｓｔプリミティブに対する応答であるＭＬＭＥ−ＳＣＡＮ．ｃｏｎｆｉｒｍプリミティブをＭＬＭＥ部（３０７）から受け取ると、そこで得られたアクセスポイントのＢＳＳＩＤ、チャネル、受信電界強度に関する情報を調査結果格納手段（３１１）へ格納する。さらに続けて現在帰属しているアクセスポイントから周辺のアクセスポイントに関する情報を取得するために、ＭＬＭＥ−ＮＥＩＧＨＢＯＲＲＥＰＲＥＱ．ｒｅｑｕｅｓｔプリミティブをＭＬＭＥ部（３０７）に発行し、それに対する応答であるＭＬＭＥ−ＮＥＩＧＨＢＯＲＲＥＰＲＥＳＰ．ｉｎｄｉｃａｔｉｏｎをＭＬＭＥ部（３０７）から受け取ると、そこで得られた情報を調査結果格納手段（３１１）へ格納しても良い。
【００４０】
調査結果格納手段（３１１）はハンドオーバ先候補情報テーブルを保持し、ハンドオーバ先候補調査手段（３１０）の調査結果とリソース要求先決定手段（３１２）のリソース予約状況を記録する手段である。ハンドオーバ先候補情報テーブルの一例を図９に示す。
【００４１】
ここでのハンドオーバ先候補情報テーブルは、見つかったアクセスポイントのＢＳＳＩＤ、受信電界強度、そのアクセスポイントが使用するチャネル、およびそのアクセスポイントに対するリソースの予約状態を記録したテーブルである。リソースの予約状態としては、例えば“未判断”、“予約しない”、“予約処理前”、“予約処理中”、“予約済み”のいずれかが記録するようにすることができる。ハンドオーバ先候補調査手段（３１０）が調査結果格納手段（３１１）に記録した際には各々のハンドオーバ先候補についてリソース予約状況には“未判断”がセットされる。
【００４２】
リソース要求先決定手段（３１２）は、調査結果格納手段（３１１）に記録されているアクセスポイントの中で、リソースの予約状態が“未判断”となっているアクセスポイントに対してリソース予約を実施するか否かを判定する。
【００４３】
実際は電界強度などの情報を用いて予約する／しないを決定し、その決定に従ってハンドオーバ先候補情報テーブルの予約状態を予約するアクセスポイントには“予約処理前”を、予約しないアクセスポイントには“予約しない”などにセットする。
【００４４】
リソース予約処理手段（３１３）は、リソース要求先決定手段（３１２）からリソースを予約するように依頼をうけると、調査結果格納手段（３１１）に格納されているハンドオーバ先候補情報テーブルの予約状態が“予約処理前”となっているアクセスポイントに対してリソースの予約を実施する。
【００４５】
リソースの予約を実施する前に、調査結果格納手段（３１１）内に記載されているアクセスポイントで“予約処理中”または“予約済み”となっているアクセスポイント数を調べる。この数はこの移動局（１１１）が既に予約を行っているアクセスポイントの数である予約実施アクセスポイント数である。
【００４６】
予約実施アクセスポイント数の把握が終わると“予約処理前”のアクセスポイント各々についてＭＬＭＥ部（３０７）に対しＭＬＭＥ−ＲＥＳＯＵＲＣＥ＿ＲＥＱＵＥＳＴ．ｒｅｑｕｅｓｔプリミティブを発行してリソースを予約する。このプリミティブには予約実施アクセスポイント数をＭＬＭＥ部（３０７）に通知するために、パラメータに予約実施アクセスポイント数が含まれている。そして調査結果格納手段（３１１）内の該当するアクセスポイントのリソースの予約状態を“予約処理中”にセットする。ＭＬＭＥ部（３０７）からＭＬＭＥ−ＲＥＳＯＵＲＣＥ＿ＲＥＱＵＥＳＴ．ｃｏｎｆｉｒｍプリミティブを受信すると、送られてきたリソース予約の結果を参照し、予約が無事完了していれば調査結果格納手段（３１１）内の該当するアクセスポイントのリソースの予約状態を“予約済み”にセットする。予約が受けつけられなかったときは調査結果格納手段（３１１）内の該当するアクセスポイントのリソースの予約状態を“予約しない”にセットする。なお、Ｒｅａｓｓｏｃｉａｔｉｏｎ  Ｒｅｑｕｅｓｔで再度リソース予約をしてもよい。また、上記では、予約実施アクセスポイント数として、“予約処理中”または“予約済み”となっているアクセスポイント数を用いるものとして説明したが、“予約済み”となっているアクセスポイント数を用いるものとする、または“予約処理中”のアクセスポイント数を用いるものとすることも可能である。
【００４７】
図１２はＭＬＭＥ−ＲＥＳＯＵＲＣＥ＿ＲＥＱＵＥＳＴ．ｒｅｑｕｅｓｔプリミティブを発行したときに、ＭＡＣ部（３０３）から発行される８０２．１１  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｃｏｎｆｉｒｍフレーム（５０３）の一例を示すものである。
【００４８】
Ｆｒａｍｅ  Ｃｏｎｔｒｏｌフィールド（７０１）には、さらにこの中にＴｙｐｅフィールドやＳｕｂｔｙｐｅフィールドが存在する。８０２．１１  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  ＣｏｎｆｉｒｍフレームではＴｙｐｅフィールドにＭａｎａｇｅｍｅｎｔフレームを意味する０という値が、ＳｕｂｔｙｐｅフィールドにはＡｕｔｈｅｎｔｉｃａｔｉｏｎを意味する１１という値が格納される。Ｄｕｒａｔｉｏｎフィールド（７０２）は他の移動局の送信を抑制するためのＮＡＶ（Ｎｅｔｗｏｒｋ  Ａｌｌｏｃａｔｉｏｎ  Ｖｅｃｔｏｒ）値が格納される。ＤＡ（７０３）はあて先アドレスが格納される。ＳＡ（７０４）は送信者のアドレスが格納される。ＢＳＳＩＤ（７０５）はアクセスポイントのＭＡＣアドレスと同じ値であるＢＳＳＩＤが格納される。Ｓｅｑｕｅｎｃｅ  Ｃｏｎｔｒｏｌフィールド（７０６）にはＦｒａｇｍｅｎｔ  ＮｕｍｂｅｒとＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒが格納される。
【００４９】
Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  ａｌｇｏｒｉｔｈｍ  ｎｕｍｂｅｒ（７０７）にはＡｕｔｈｅｎｔｉｃａｔｉｏｎフレーム交換で使用される認証アルゴリズムがセットされる。Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  ｔｒａｎｓａｃｔｉｏｎ  ｎｕｍｂｅｒ（７０８）にはＡｕｔｈｅｎｔｉｃａｔｉｏｎフレーム交換の状態を表す値である。Ｓｔａｔｕｓ  Ｃｏｄｅ（７０９）にはＡｕｔｈｅｎｔｉｃａｔｉｏｎフレーム交換の過程でのリクエストに対する結果を示す値を格納する。Ｃｈａｌｌｅｎｇｅ  ｔｅｘｔ（７１０）にはＡｕｔｈｅｎｔｉｃａｔｉｏｎ  ＡｌｇｏｒｉｔｈｍとしてＳｈａｒｅｄ  Ｋｅｙを用いた場合に、認証で用いられるチャレンジテキストが格納される。Ｍｏｂｉｌｉｔｙ  Ｄｏｍａｉｎ（７１１）には、モビリティドメインを識別する値が入る。ＲＳＮ（Ｒｏｂｕｓｔ  Ｓｅｃｕｒｉｔｙ  Ｎｅｔｗｏｒｋ）  ｉｎｆｏｒｍａｔｉｏｎ  ｅｌｅｍｅｎｔ（７１３）には、セキュリティに関するパラメータが格納される。ＲＩＣ（Ｒｅｓｏｕｒｃｅ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｃｏｎｔａｉｎｅｒ、７１４）には、リソースに関する情報が格納される。ＦＣＳ（Ｆｒａｍｅ  Ｃｈｅｃｋ  Ｓｅｑｕｅｎｃｅ、７１５）には、誤り検出符号が格納される。
【００５０】
Ｆａｓｔ  ＢＳＳ  Ｔｒａｎｓｉｔｉｏｎ  ｉｎｆｏｒｍａｔｉｏｎ  ｅｌｅｍｅｎｔ（７１２）の内容はＥｌｅｍｅｎｔ  ＩＤ（７１６）、Ｌｅｎｇｔｈ（７１７）、ＭＩＣ  Ｃｏｎｔｒｏｌ（７１８）、ＭＩＣ（７１９）、ＡＮｏｎｃｅ（７２０）、ＳＮｏｎｃｅ（７２１）、Ｒ０ＫＨ−ＩＤ（７２２）、およびＯｐｔｉｏｎａｌ  Ｐａｒａｍｅｔｅｒｓ（７２３）から構成される。Ｅｌｅｍｅｎｔ  ＩＤ（７１６）には、この後続くデータの内容がＦａｓｔ  ＢＳＳ  Ｔｒａｎｓｉｔｉｏｎ  ｉｎｆｏｒｍａｔｉｏｎ  ｅｌｅｍｅｎｔであることを表すＩＤ（例えば５５）が格納される。Ｌｅｎｇｔｈ（７１７）にはこの後に続くデータの長さが格納される。ＭＩＣ  Ｃｏｎｔｒｏｌ（７１８）には、データの改竄がないかどうかをチェックするための値ＭＩＣ（Ｍｅｓｓａｇｅ  Ｉｎｔｅｇｒｉｔｙ  Ｃｈｅｃｋ）を計算する際に用いたｉｎｆｏｒｍａｔｉｏｎ  ｅｌｅｍｅｎｔ数を格納する。ＭＩＣ（７１９）には、ＭＩＣ値が格納される。ＡＮｏｎｃｅ（７２０）およびＳＮｏｎｃｅ（７２１）は、暗号化鍵等を導出する際に使用される乱数値である。Ｒ０ＫＨ−ＩＤ（７２２）には、暗号化鍵Ｒ０ｋｅｙを保持しているノードのＩＤが格納される。Ｏｐｔｉｏｎａｌ  Ｐａｒａｍｅｔｅｒｓ（７２３）には付加的な情報を格納することが可能である。７２５〜７２７は予約実施アクセスポイント数を格納するために用いられるフォーマットの一例である。Ｓｕｂ−ｅｌｅｍｅｎｔ  ＩＤ（７２４）には、ここで格納される情報が予約実施アクセスポイント数であることを表すＩＤ（例えば３）をセットする。Ｌｅｎｇｔｈ（７２５）には、この後に続くデータのサイズを格納する。本実施の形態ではここにセットされる値を１とする。次にＡＰ（Ａｃｃｅｓｓ  Ｐｏｉｎｔ）数（７２６）には、予約実施アクセスポイント数を格納する。
【００５１】
図４は、本発明の一実施の形態としてのアクセスポイント（１０１〜１０７）の構造を示すブロック図である。図4を参照してアクセスポイントの構成例を説明すると、アクセスポイント（１０１〜１０７）は、ＩＥＥＥ  ８０２．３  ＰＨＹ部（４０１）、ＩＥＥＥ  ８０２．３  ＭＡＣ部（４０２）、ネットワーク（４０３）、アンテナ（４０４）、ＩＥＥＥ  ８０２．１１  ＰＨＹ部（４０５）、ＩＥＥＥ  ８０２．１１  ＭＡＣ部（４０６）、ブリッジ（４０７）、ＩＥＥＥ  ８０２．１１  ＰＬＭＥ部（４０８）、ＩＥＥＥ  ８０２．１１  ＭＬＭＥ部（４０９）、ＳＭＥ部（４１０）から構成される。
【００５２】
ＩＥＥＥ  ８０２．３  ＰＨＹ部（４０１）は、ＩＥＥＥ  ８０２．３規格で規定されるＰＨＹ機能を処理する手段である。
【００５３】
ＩＥＥＥ  ８０２．３  ＭＡＣ部（４０２）は、ＩＥＥＥ  ８０２．３規格で規定されるＭＡＣ機能を処理する手段である。
【００５４】
ネットワーク（４０３）は、ＩＥＥＥ  ８０２．３規格に準拠したネットワークである。
【００５５】
アンテナ（４０４）は、ＩＥＥＥ  ８０２．１１  ＰＨＹ部（４０５）で変調された無線信号の送信や他の移動局（１１１）から送信された無線信号を受信するための手段である。
【００５６】
ＩＥＥＥ  ８０２．１１  ＰＨＹ部（４０５）は、例えばＩＥＥＥ  ８０２．１１ｇで規定されるものであり、ＩＥＥＥ  ８０２．１１  ＭＡＣ部（４０６）から送られてくるフレームを電波信号に変調しアンテナ（４０４）を通して送信する機能、およびアンテナ（４０４）から受信した電波信号を復調し、受信フレームとしてＩＥＥＥ  ８０２．１１  ＭＡＣ部（４０６）へ渡す機能を持つ。
【００５７】
ＩＥＥＥ  ８０２．１１  ＭＡＣ部（４０６）は、ＩＥＥＥ  ８０２．１１ｅ仕様で規定される機能およびＩＥＥＥ  ８０２．１１ｒ仕様で規定される機能を処理する。
【００５８】
ブリッジ３０７は、ＩＥＥＥ  ８０２．３  ＭＡＣ部（４０２）から送られてきた受信フレームのあて先アドレスを調べ、もしそのあて先アドレスで示されるノードが本アクセスポイントのカバーエリアに存在する移動局である場合、そのフレームをＩＥＥＥ  ８０２．１１  ＭＡＣ部（４０６）へ渡す。逆にＩＥＥＥ  ８０２．１１  ＭＡＣ部（４０６）から受け取った受信フレームのあて先がネットワーク（４０３）内のノードであれば、そのフレームをＩＥＥＥ  ８０２．３  ＭＡＣ部（４０２）へ渡す。
【００５９】
ＩＥＥＥ  ８０２．１１  ＰＬＭＥ部（４０８）はＩＥＥＥ  ８０２．１１  ＰＨＹ部（４０５）を制御するためのエンティティであり、ＩＥＥＥ  ８０２．１１ｇ、ＩＥＥＥ  ８０２．１１ｅ、ＩＥＥＥ  ８０２．１１ｒで規定されるＭＬＭＥ＿ＰＬＭＥ＿ＳＡＰおよびＰＬＭＥ＿ＳＡＰを処理できるものである。
【００６０】
ＩＥＥＥ  ８０２．１１  ＭＬＭＥ部（４０９）はＳＭＥ部（４１０）からの指示に従い、ＩＥＥＥ  ８０２．１１  ＭＡＣ部（４０６）を制御するエンティティである。
【００６１】
なお本実施の形態で用いるＩＥＥＥ  ８０２．１１  ＭＬＭＥ部（４０９）は、ＩＥＥＥ  ８０２．１１ｇ、ＩＥＥＥ  ８０２．１１ｅ、ＩＥＥＥ  ８０２．１１ｒで規定されるＭＬＭＥ＿ＳＡＰを処理する機能に加え、予約実施アクセスポイント数が格納されたＡｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｃｏｎｆｉｒｍフレームを受信すると、その数を他のパラメータとともにＭＬＭＥ−ＲＥＳＯＵＲＣＥ＿ＲＥＱＵＥＳＴ．ｉｎｄｉｃａｔｉｏｎプリミティブによってＳＭＥ部（４１０）に通知できる機能も含むものとする。
【００６２】
ＳＭＥ部（４１０）はＩＥＥＥ  ８０２．１１  ＰＨＹ部（４０５）およびＩＥＥＥ  ８０２．１１  ＭＡＣ部（４０６）を、ＩＥＥＥ  ８０２．１１  ＰＬＭＥ部（４０８）およびＩＥＥＥ  ８０２．１１  ＭＬＭＥ部（４０９）を通して管理するエンティティである。ＳＭＥ部（４１０）は、リソース予約受付判断手段（４１１）、リソース管理処理手段（４１２）、およびリソース管理データベース（４１３）を含むものである。ＳＭＥリソース受付手段（４１４）は特にリソース予約受付判断手段（４１１）、リソース管理処理手段（４１２）、およびリソース管理データベース（４１３）から構成される。リソース管理手段（４１５）は特にリソース管理処理手段（４１２）、およびリソース管理データベース（４１３）から構成される。
【００６３】
リソース予約受付判断手段（４１１）は、移動局（１１１）から予約実施アクセスポイント数が格納されたＡｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｃｏｎｆｉｒｍフレームを受信すると、ＩＥＥＥ  ８０２．１１  ＭＬＭＥ部（４０９）よりそれらの情報が格納されたＭＬＭＥ−ＲＥＳＯＵＲＣＥ＿ＲＥＱＵＥＳＴ．ｉｎｄｉｃａｔｉｏｎプリミティブを受信する。そして、リソース管理データベース（４１３）に記録されている現在のリソースの使用状態とリソースの予約状態、およびＩＥＥＥ  ８０２．１１  ＭＬＭＥ部（４０９）より通知された要求リソース量と予約実施アクセスポイント数を勘案し、そのリソース要求を受け入れるかどうか判断する。そのリソース要求を受け入れる場合、リソース確保成功を意味するパラメータをセットしたＭＬＭＥ−ＲＥＳＯＵＲＣＥ＿ＲＥＱＵＥＳＴ．ｒｅｓｐｏｎｓｅプリミティブをＩＥＥＥ  ８０２．１１  ＭＬＭＥ部（４０９）に対して発行すると同時に、リソース管理データベース（４１３）に、要求元移動局のＭＡＣアドレス、要求リソース量、予約実施アクセスポイント数、そのリソース予約の期限をセットし、またリソース使用状態として “予約中”という状態をセットする。反対にそのリソース要求を受け入れない場合、リソース確保失敗を意味するパラメータをセットしたＭＬＭＥ−ＲＥＳＯＵＲＣＥ＿ＲＥＱＵＥＳＴ．ｒｅｓｐｏｎｓｅプリミティブをＩＥＥＥ  ８０２．１１  ＭＬＭＥ部（４０９）に対して発行する。
【００６４】
リソース管理処理手段（４１２）は、ＩＥＥＥ  ８０２．１１  ＭＬＭＥ部（４０９）よりＭＬＭＥ−ＲＥＡＳＳＯＣＩＡＴＥ．ｉｎｄｉｃａｔｉｏｎプリミティブを受信すると、そのプリミティブのパラメータに含まれている送信元のアドレスを調べ、その移動局の予約中のリソースが無いかどうかリソース管理データベース（４１３）を用いて調べる。もし送信元の移動局が予約しているリソースが存在し予約の期限が切れていなければ、そのリソースの状態を“使用中”に変更する。
【００６５】
リソース管理データベース（４１３）は例えば図５に示すようなリソース管理テーブルが格納される。このテーブルの一例として、このアクセスポイントにおいて現在使用されているリソースおよび予約中のリソースについて、そのリソースの要求者のアドレスとリソース量、予約中のリソースであれば予約実施アクセスポイント数、そのリソース予約の期限、およびリソースの使用状態が記載されるようなものである。ここでリソースの要求者アドレスはリソースの予約を行う通信装置である移動局のアドレスを示すものである。
【００６６】
図５の１行目を例に取るとリソースの要求者のアドレスがＳＴＡ１、リソース量として６４ｋｂｐｓ、リソースの使用状態が予約中でありこの移動局が３つのアクセスポイントに予約実施しており、リソース予約の期限は２００７年１月２７日の２２時４５分００秒までとなっている。
［動作の説明］
図６は、移動局がハンドオーバ先を決定する場合の動作例を示すフローチャートである。図６と図３の移動局の構成図を参照して、この動作を説明する。移動局のハンドオーバ先候補調査手段（３１０）は、ＳＭＥ部（３０８）内にあるハンドオーバ管理手段（３０９）からハンドオーバ先を決定するよう依頼を受けると、ＭＬＭＥ部（３０７）に対してＭＬＭＥ−ＳＣＡＮ．ｒｅｑｕｅｓｔプリミティブを発行する（ステップ１０１）。次にハンドオーバ先候補調査手段（３１０）はＭＬＭＥ部（３０７）からＭＬＭＥ−ＳＣＡＮ．ｃｏｎｆｉｒｍを受信したかどうか確認する（ステップ１０２）。まだ受信していない場合はステップ１０２へ戻り、受信するまでここで待機する。
【００６７】
受信している場合は、次にＭＬＭＥ−ＳＣＡＮ．ｃｏｎｆｉｒｍプリミティブに含まれるパラメータから、検出できたすべてのアクセスポイントに関するＢＳＳＩＤ、チャネル、受信電界強度に関する情報を取得し、それらの情報を調査結果格納手段（３１１）へ格納する（ステップ１０３）。ステップ１０１からステップ１０３の処理によって移動局（１１１）が直接通信できるアクセスポイントを見つけることができる。
【００６８】
次にアクセスポイントがＩＥＥＥ  ８０２．１１ｋで規定される枠組みを用いて近隣アクセスポイントに関する情報を得るためにＮｅｉｇｈｂｏｒ Ｒｅｐｏｒｔ Ｒｅｑｕｅｓｔフレームを送信することが必要となる。そこでハンドオーバ先候補調査手段（３１０）はＭＬＭＥ部（３０７）に対してＭＬＭＥ−ＮＥＩＧＨＢＯＲＲＥＰＲＥＱ．ｒｅｑｕｅｓｔプリミティブを発行する（ステップ１０４）。  
次に、ＭＬＭＥ部（３０７）からＭＬＭＥ−ＮＥＩＧＨＢＯＲＲＥＰＲＥＳＰ．ｉｎｄｉｃａｔｉｏｎを受信したかどうかをハンドオーバ先候補調査手段（３１０）はチェックする（ステップ１０５）。
【００６９】
もし受信していなければ再びステップ１０５へ戻り受信するまでハンドオーバ先候補調査手段（３１０）は待機する。もし受信すると、ＭＬＭＥ−ＮＥＩＧＨＢＯＲＲＥＰＲＥＳＰ．ｉｎｄｉｃａｔｉｏｎプリミティブのＮｅｉｇｈｂｏｒＬｉｓｔＳｅｔパラメータから近隣アクセスポイントに関する情報を取得し、それらの情報を調査結果格納手段（３１１）へ格納する（ステップ１０６）。
【００７０】
ステップ１０６までの処理を終えると、ハンドオーバ先候補調査手段（３１０）はハンドオーバ管理手段（３０９）に周辺アクセスポイント情報の収集の完了を通知する（ステップ１０７）。
【００７１】
ハンドオーバ先候補調査手段（３１０）からハンドオーバ先候補となるアクセスポイント情報の収集が完了した旨の通知を受けると、ハンドオーバ管理手段（３０９）はリソース要求先決定手段（３１２）に対してどのアクセスポイントに対してリソースを要求するか決定するよう依頼する。リソース要求先決定手段（３１２）は調査結果格納手段（３１１）に格納されている受信電界強度に関する閾値であり、あらかじめ定められたものであるリソース要求受信電界強度を参照し、その閾値よりも受信電界強度が大きいアクセスポイントについてリソースを要求すると決定する。またはハンドオーバ先候補情報テーブルを用いて受信電解強度が強いものから順に予め設定されたアクセスポイントの数分のリソースを要求するなどとしてもよい。
【００７２】
図７はハンドオーバ先候補情報テーブルのリソース予約状態の変更に関する処理を示すフローチャートである。ここでは一例としてリソース要求受信電界強度よりも受信電界強度が大きいアクセスポイントを要求するとした場合の動作を示す。
【００７３】
ハンドオーバ先候補情報テーブルの行数を示す変数ｉに１を代入する（ステップ２０１）。次にテーブルのｉ行目の受信電界強度がリソース要求受信電界強度を上回っているか調査し（ステップ２０２）、上回っている場合はリソース予約状態を“予約処理前”に変更し（ステップ２０３）、下回っている場合は“予約しない”に変更する（ステップ２０４）。ステップ２０３またはステップ２０４の処理の後、ｉ行目はテーブルの最終行であるか調査し（ステップ２０５）、最終行であれば処理を終え、最終行でなければｉに１を加え（ステップ２０６）、ステップ２０２へ戻す。
【００７４】
リソース予約状態の変更に関する処理が終わると、リソース要求先決定手段（３１２）はリソース予約処理手段（３１３）に対してリソースを予約すると決定したアクセスポイント、上記の記載で言えば、ハンドオーバ先候補情報テーブルでのリソース予約状態を“予約処理前”に変更したアクセスポイントに対して実際にリソースを要求するようリソース予約処理手段（３１３）に通知する。
【００７５】
図８は、移動局のリソース予約処理手段（３１３）がリソース要求先決定手段（３１２）からリソースを要求するよう依頼された場合の動作を示すフローチャートである。図８と図３の移動局の構成図を参照して、この動作を説明する。移動局のリソース予約処理手段（３１３）は、予約実施アクセスポイント数を格納する変数ｎｕｍ＿ａｐを０に初期化する（ステップ３０１）。次にハンドオーバ先候補情報テーブルの処理する行を表す変数ｉに１をセットする（ステップ３０２）。次にハンドオーバ先候補情報テーブルのｉ行目のリソース予約状態が“予約処理中”または“予約済み”かどうか調べる（ステップ３０３）。もし“予約処理中”または“予約済み”であればｎｕｍ＿ａｐに１を加える（ステップ３０４）。そうでない場合はステップ３０５へ飛ぶ。次に現在処理しているｉ行目がハンドオーバ先候補情報テーブルの最後の行かどうか調べる（ステップ３０５）。もし最後の行でなければ変数ｉに１を加え（ステップ３０６）、ステップ３０３へ飛ぶ。もし最後の行であれば再びハンドオーバ先候補情報テーブルの処理する行を表す変数ｉに１をセットする（ステップ３０７）。次にハンドオーバ先候補情報テーブルのｉ行目のリソース予約状態が“予約処理前”かどうか調べる（ステップ３０８）。もし“予約処理前”でない場合はステップ３１７へ飛ぶ。もし“予約処理前”ならば、現在指しているｉ行目のＡＰのアドレスに対してＡｕｔｈｅｎｔｉｃａｔｉｏｎフレームの交換を行う。
【００７６】
図１０は、Ａｕｔｈｅｎｔｉｃａｔｉｏｎフレーム交換時の動作を示すシーケンスである。図１０には、ＩＥＥＥ  ８０２．１１ｒ仕様で規定されるＯｖｅｒ−ｔｈｅ−Ａｉｒ方式を用いた場合（図１０上）とＯｖｅｒ−ｔｈｅ−ＤＳ（Ｏｖｅｒ−ｔｈｅ−Ｄｉｓｔｒｉｂｕｔｉｏｎ  Ｓｙｓｔｅｍ）方式を用いた場合（図１０下）の両方のシーケンスが示されている。図１０においてアクセスポイント１とは、移動局が現在使用しているアクセスポイントとし、アクセスポイント２とは移動局がリソースを予約しようとしているアクセスポイントとする。
【００７７】
まずＯｖｅｒ−ｔｈｅ−Ａｉｒ方式の場合のシーケンスを５０１〜５０４に示す。移動局がリソースを予約する場合、移動局はリソースを予約したアクセスポイントが使用しているチャネルに、ＰＨＹ部（３０４）が使用するチャネルを切り替えた後Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｒｅｑｕｅｓｔフレームを送信する（５０１）。
【００７８】
Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｒｅｑｕｅｓｔを受信したアクセスポイント２はＡｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｒｅｓｐｏｎｓｅフレームを送信する（５０２）。Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｒｅｓｐｏｎｓｅフレームを受信した移動局は、要求するリソースに関する情報（ＲＩＣ−Ｒｅｑｕｅｓｔパラメータ）を格納したＲＩＣ−Ｒｅｑｕｅｓｔと、予約実施アクセスポイント数をＦａｓｔ  ＢＳＳ  Ｔｒａｎｓｉｔｉｏｎ  ｉｎｆｏｒｍａｔｉｏｎ  ｅｌｅｍｅｎｔ内のＯｐｔｉｏｎａｌ  Ｐａｒａｍｅｔｅｒｓフィールドに格納したＡｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｃｏｎｆｉｒｍフレームをアクセスポイント２へ送信する。
【００７９】
図１１は、ＲＩＣ−Ｒｅｑｕｅｓｔの構成の一例を示すものである。ＲＩＣ−Ｒｅｑｕｅｓｔは1以上のＲｅｓｏｕｒｃｅ  Ｒｅｑｕｅｓｔ（６０１，６０２，６０３）から構成される。各々のＲｅｓｏｕｒｃｅ  ＲｅｑｕｅｓｔはＲＤＩＥ（Ｒｅｓｏｕｒｃｅ  ｉｎｆｏｒｍａｔｉｏｎ  ｃｏｎｔａｉｎｅｒ  Ｄａｔａ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｅｌｅｍｅｎｔ，６０４）とＲｅｓｏｕｒｃｅ  Ｄｅｓｃｒｉｐｔｅｒ（６０５）から構成される。
【００８０】
ＲＤＩＥはＥｌｅｍｅｎｔ  ＩＤ（６０６）、Ｌｅｎｇｔｈ（６０７）、ＲＤＩＥ  Ｉｄｅｎｔｉｆｉｅｒ（６０８）、Ｒｅｓｏｕｒｃｅ  Ｄｅｓｃｒｉｐｔｅｒ  Ｃｏｕｎｔ（６０９）、Ｓｔａｔｕｓ  Ｃｏｄｅ（６１０）から構成される。Ｅｌｅｍｅｎｔ  ＩＤ（６０６）はＲＤＩＥであることを示す識別子が格納され、ここには例えば値５７が格納される。Ｌｅｎｇｔｈフィールド（６０７）にはＲＤＩＥのＥｌｅｍｅｎｔ  ＩＤ（６０６）とＬｅｎｇｔｈ（６０７）部分を除いた長さが格納され、本実施例では４が格納される。
【００８１】
ＲＤＩＥ  Ｉｄｅｎｔｉｆｉｅｒフィールド（６０８）には、このＲＤＩＥを一意に識別するための値が格納され、移動局がＲＩＣ−Ｒｅｑｕｅｓｔ内の他のＲＤＩＥと重複しないような任意な値をセットする。Ｒｅｓｏｕｒｃｅ  Ｄｅｓｃｒｉｐｔｅｒ  Ｃｏｕｎｔ（６０９）は、本ＲＤＩＥの後ろに存在するＲｅｓｏｕｒｃｅ  Ｄｅｓｃｒｉｐｔｅｒ（６１１、６１２）の数をセットする。Ｓｔａｔｕｓ  Ｃｏｄｅ（６１０）にはステータスコードがセットされ、ＲＩＣ−Ｒｅｑｕｅｓｔ内で用いられる場合は０がセットされる。
【００８２】
Ｒｅｓｏｕｒｃｅ  Ｄｅｓｃｒｉｐｔｅｒ（６０５）は、１以上のＴＳＰＥＣ（Ｔｒａｆｆｉｃ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ）情報エレメントから構成される。ＴＳＰＥＣ情報エレメントは要求するリソースを記述する情報エレメントであり、本情報エレメントには、本実施例で用いるＭｅａｎ  Ｄａｔａ  Ｒａｔｅや、Ｍｉｎｉｍｕｍ  Ｄａｔａ  Ｒａｔｅ，Ｐｅａｋ  Ｄａｔａ  Ｒａｔｅなどの値を格納するフィールドが用意されている。もしＲｅｓｏｕｒｃｅ  Ｄｅｓｃｒｉｐｔｅｒ内に複数のＴＳＰＥＣ情報エレメントが存在する場合は、これらはＯＲ条件を示す。一方、ＲＩＣ−Ｒｅｑｕｅｓｔ内に複数のＲｅｓｏｕｒｃｅ  Ｄｅｓｃｒｉｐｔｅｒが存在する場合は、それらはＡＮＤ条件を意味する。
【００８３】
アクセスポイント２は本フレームを受信すると、要求されたリソースを受け入れることが可能かどうかを判断し、判断結果を記したＲＩＣ−ＲｅｓｐｏｎｓｅをＡｕｔｈｅｎｔｉｃａｔｉｏｎ  ＡＣＫフレームに格納し、それを移動局に送信する（５０４）。
【００８４】
ＲＩＣ−Ｒｅｓｐｏｎｓｅは1以上のＲｅｓｏｕｒｃｅ  Ｒｅｓｐｏｎｓｅ（６１３，６１４，６１５）から構成される。Ｒｅｓｏｕｒｃｅ  ＲｅｓｐｏｎｓｅはＲＤＩＥとＲｅｓｏｕｒｃｅ  Ｄｅｓｃｒｉｐｔｅｒから構成される。ＲＤＩＥはＲＩＣ−Ｒｅｑｕｅｓｔ内のＲＤＩＥと同じである。一方、ＲＩＣ−ＲｅｓｐｏｎｓｅにおけるＲｅｓｏｕｒｃｅ  Ｄｅｓｃｒｉｐｔｅｒは、多くても1つのＴＳＰＥＣ情報エレメントが格納される。
【００８５】
アクセスポイント２がＲＩＣ−Ｒｅｑｕｅｓｔを受け取ると、各々のＲｅｓｏｕｒｃｅ  Ｒｅｑｕｅｓｔについて、その中に記されたＯＲ条件で記されたＴＳＰＥＣ情報エレメント（６１１，６１２）を先頭から調べ、受け入れ可能なＴＳＰＥＣ情報エレメントに遭遇すれば、そのＴＳＰＥＣ情報エレメント（６１８）を残したＲｅｓｏｕｒｃｅ  Ｄｅｓｃｒｉｐｔｅｒ（６１７）を作成する。そして、新たにＲＤＩＥ（６１６）を作成し、作成したＲＤＩＥ内のＥｌｅｍｅｎｔ  ＩＤに５７、Ｌｅｎｇｔｈに４、ＲＤＩＥ  Ｉｄｅｎｔｉｆｉｅｒに処理中のＲｅｓｏｕｒｃｅ  Ｒｅｑｕｅｓｔ内のＲＤＩＥに格納されていたＲＤＩＥ  Ｉｄｅｎｔｉｆｉｅｒ（６０８）と同じ値を、Ｒｅｓｏｕｒｃｅ  Ｄｅｓｃｒｉｐｔｅｒ  Ｃｏｕｎｔに１を、そしてＳｔａｔｕｓ  Ｃｏｄｅに０をセットする。
【００８６】
そして作成したＲＤＩＥ（６１６）とＲｅｓｏｕｒｃｅ  Ｄｅｓｃｒｉｐｔｅｒ（６１７）を結合し１つのＲｅｓｏｕｒｃｅ  Ｒｅｓｐｏｎｓｅ（６１３）が完成する。もし受け入れ可能なＴＳＰＥＣ情報エレメントが存在しない場合は、Ｓｔａｔｕｓ  Ｃｏｄｅ（６１１）に０以外の値をセットし、またＲｅｓｏｕｒｃｅ  Ｄｅｓｃｒｉｐｔｅｒ  Ｃｏｕｎｔｅｒに０をセットしたＲｅｓｏｕｒｃｅ  Ｒｅｓｐｏｎｓｅ（６１３）を作成する。以上の処理を各々のＲｅｓｏｕｒｃｅ  Ｒｅｑｕｅｓｔについて処理し、作成されたＲｅｓｏｕｒｃｅ  Ｒｅｓｐｏｎｓｅ（６１３，６１４，６１５）を結合したものをＲＩＣ−Ｒｅｓｐｏｎｓｅとする。
【００８７】
一方Ｏｖｅｒ−ｔｈｅ−ＤＳの場合、Ｏｖｅｒ−ｔｈｅ−Ａｉｒで交換される４フレームと内容は同じであり、フレーム５０１、５０２、５０３、５０４はそれぞれ、５０５、５０６、５０７、５０８に対応する。ただしそれらのフレームは直接リソースを予約するアクセスポイントに対してではなく現在帰属中のアクセスポイントを経由して交換され、またそれは、Ｆａｓｔ  ＢＳＳ  ｔｒａｎｓｉｔｉｏｎ  ａｃｔｉｏｎフレームを用いて交換される点が異なる。
【００８８】
なおＯｖｅｒ−ｔｈｅ−ＤＳ方式は、移動局と直接通信のできないアクセスポイントに対してリソースを要求できるのに対し、Ｏｖｅｒ−ｔｈｅ−Ａｉｒ方式は移動局と直接通信のできるアクセスポイントに対してのみリソースを要求できる。したがって、図９のハンドオーバ先候補情報テーブルで受信電界強度が−∞なアクセスポイントに対してはＯｖｅｒ−ｔｈｅ−ＤＳ方式を用いてリソースを予約する。
【００８９】
説明をフローチャート図８に戻す。以下はＯｖｅｒ−ｔｈｅ−Ａｉｒ方式を用いた場合について説明する。なおＯｖｅｒ−ｔｈｅ−ＤＳ方式を用いる場合は、ＭＬＭＥ−ＲＥＳＯＵＲＣＥ＿ＲＥＱＵＥＳＴ．ｒｅｑｕｅｓｔの代わりにＭＬＭＥ−ＲＥＭＯＴＥ＿ＲＥＱＵＥＳＴ．ｒｅｑｕｅｓｔプリミティブを、ＭＬＭＥ−ＲＥＳＯＵＲＣＥ＿ＲＥＱＵＥＳＴ．ｃｏｎｆｉｒｍの代わりにＭＬＭＥ−ＲＥＭＯＴＥ＿ＲＥＱＵＥＳＴ．ｃｏｎｆｉｒｍプリミティブを発行する点が異なる以外は基本的に動作は同じである。
【００９０】
まず８０２．１１  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｒｅｑｕｅｓｔフレーム（５０１）を送信するために、ＭＬＭＥ部（３０７）に対してＭＬＭＥ−ＡＵＴＨＥＮＴＩＣＡＴＥ．ｒｅｑｕｅｓｔプリミティブを発行する（ステップ３０９）。本プリミティブを発行するとＭＡＣ部（３０３）はアクセスポイントに対して８０２．１１  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｒｅｑｕｅｓｔフレーム（５０１）を送信する。次にＭＬＭＥ−ＡＵＴＨＥＮＴＩＣＡＴＩＯＮ．ｃｏｎｆｉｒｍプリミティブがＭＬＭＥ部（３０７）から届いたかチェックする（ステップ３１０）。もし届いていない場合は再びステップ３１０へ飛び、本プリミティブが届くまで待機する。もし届いた場合は、８０２．１１  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｃｏｎｆｉｒｍフレーム（５０３）に格納するためのＦａｓｔ  ＢＳＳ  Ｔｒａｎｓｉｔｉｏｎ情報エレメント部分を作成する（ステップ３１１）。
【００９１】
このＦａｓｔ  ＢＳＳ  Ｔｒａｎｓｉｔｉｏｎ情報エレメントのＯｐｔｉｏｎａｌ  Ｐａｒａｍｅｔｅｒｓフィールドには、Ｓｕｂ−ｅｌｅｍｅｎｔ  ＩＤ（７２４）が３であり、Ｌｅｎｇｔｈフィールド（７２５）が１であり、ＡＰ数フィールド（７２６）にｎｕｍ＿ａｐをセットしたＳｕｂ情報エレメントをセットする。次に作成したＦａｓｔ  ＢＳＳ  Ｔｒａｎｓｉｔｉｏｎ情報エレメントをパラメータとして、ＭＬＭＥ部（３０７）に対してＭＬＭＥ−ＲＥＳＯＵＲＣＥ＿ＲＥＱＵＥＳＴ．ｒｅｑｕｅｓｔプリミティブを発行する（ステップ３１２）。
【００９２】
処理ステップ３１２が終了すると、次にステップ３１２で発行したＭＬＭＥ−ＲＥＳＯＵＲＣＥ＿ＲＥＱＵＥＳＴ．ｒｅｑｕｅｓｔに対するＭＬＭＥ−ＲＥＳＯＵＲＣＥ＿ＲＥＱＵＥＳＴ．ｃｏｎｆｉｒｍプリミティブをＭＬＭＥ部（３０７）から受信したかどうかを調べる（ステップ３１３）。もし受信していないのであれば、再びステップ３１３へ戻り同プリミティブを受信するまでここで待機する。
【００９３】
もし受信していれば、受信したＭＬＭＥ−ＲＥＳＯＵＲＣＥ＿ＲＥＱＵＥＳＴ．ｃｏｎｆｉｒｍプリミティブがリソースの予約の成功を意味するものであったかどうかを調べる（ステップ３１４）。もしリソース予約が成功していればハンドオーバ先候補情報テーブルｉ行目のリソース予約状態を“予約済み”に変更する（ステップ３１５）。もしリソースの予約が失敗した場合はハンドオーバ先候補情報テーブルｉ行目のリソース予約状態を“予約しない”に変更する（ステップ３１６）。次にハンドオーバ先候補情報テーブルのｉ行目が最終行かどうかを調べる（ステップ３１７）。もし最終行でなければ変数ｉに１を加え（ステップ３１８）、処理をステップ３０８に戻す。もし最終行の場合はリソース要求先決定手段（３１２）へリソース要求が終了したことを通知し（ステップ３１９）、リソース予約処理手段の処理は終了である。
【００９４】
図１３はアクセスポイント（１０１〜１０７）内にあるリソース予約受付判断手段（４１１）の動作を示すフローチャートである。ＩＥＥＥ  ８０２．１１  ＭＬＭＥからＭＬＭＥ−ＲＥＳＯＵＲＣＥ＿ＲＥＱＵＥＳＴ．ｉｎｄｉｃａｔｉｏｎを受信したかどうかを調べる（ステップ４０１）。まだ受信していない場合は再び処理をステップ４０１へ戻し、受信するまで待機する。もし受信した場合は、変数ｒｅｑｕｅｓｔｅｄに受信したＭＬＭＥ−ＲＥＳＯＵＲＣＥ＿ＲＥＱＵＥＳＴ．ｉｎｄｉｃａｔｉｏｎのパラメータに格納されるＲＩＣ−Ｒｅｑｕｅｓｔで示されるリソース量を予約実施アクセスポイント数で除した結果を変数ｒｅｑｕｅｓｔｅｄに代入する（ステップ４０２）。
【００９５】
本実施の形態では、リソース量として移動局が要求する平均のデータレートであるＭｅａｎ  Ｄａｔａ  Ｒａｔｅの値を用いて説明するが、これ以外の要求のタイプであるＭｉｎｉｍｕｍ  Ｄａｔａ  ＲａｔｅやＰｅａｋ  Ｄａｔａ  Ｒａｔｅを用いた場合についても、全体の使用リソース量が各々の移動局が利用するリソース量の和で表されるようなリソース量であれば適用可能であることは言うまでもない。
【００９６】
また、ｒｅｑｕｅｓｔｅｄに代入する数値はリソース量を予約実施アクセスポイント数で除した結果ではなくＲＩＣ−Ｒｅｑｕｅｓｔに含まれるリソース量そのままを用いてもよい。
【００９７】
なお、移動局（１１１）が要求できるリソースのタイプはＩＥＥＥ  ８０２．１１ｅ仕様で規定されている。以下ではこれらのリソースタイプを例としての説明を行うものとする。次に、現在このアクセスポイントで使用されているリソース量の合計を格納する変数ｕｓｅｄの値を０に初期化する（ステップ４０３）。次に使用中のリソース量の合計を求めるために、リソース管理データベース（４１３）に格納されるリソース管理テーブルの処理行を表す変数ｉに１をセットする（ステップ４０４）。次にリソース管理テーブルｉ行目のリソースの使用状態が“使用中”であるかどうかを調べる（ステップ４０５）。もし使用中でなければステップ４０７へ処理を飛ばす。もし使用中である場合は、変数ｕｓｅｄに現在指しているテーブルの行のＭｅａｎ  Ｄａｔａ  Ｒａｔｅの値を加える（ステップ４０６）。次にｉ行目がリソース管理テーブルにおける最終行かどうかを調べる（ステップ４０７）。もし最終行で無い場合は、変数ｉに１を加え処理を８０５へ飛ばす（ステップ４０８）。もし最終行である場合は、処理の対象をリソース管理テーブルの先頭に移動するため、再び変数ｉに１をセットする（ステップ４０９）。次に現在予約中のリソースの総量を調べるために使用する変数ｒｅｓｅｒｖｅｄを初期化するために０を代入する（ステップ４１０）。
【００９８】
次にリソース管理テーブルｉ行目のリソースの使用状態が“予約中”かどうかを調べる（ステップ４１１）。もし“予約中”でない場合は、処理をステップ４１５へ飛ばす。もし“予約中”である場合は、現在指している行の移動局が実際にそのリソースを使用する確率を格納する変数ｐｒｏｂａｂｉｌｉｔｙに、１をリソース管理テーブルｉ行目の予約実施アクセスポイント数で除した値を格納する（ステップ４１２）。次にｉ行目の移動局が使用するリソースの期待値を求めるために、処理８１２で算出したリソースを要求する確率ｐｒｏｂａｂｉｌｉｔｙにｉ行目のＭｅａｎ  Ｄａｔａ  Ｒａｔｅの値を乗じ、その結果を変数ｅｘｐｅｃｔａｔｉｏｎに格納する（ステップ４１３）。次に、変数ｒｅｓｅｒｖｅｄに求めた期待値であるｅｘｐｅｃｔａｔｉｏｎを加える（ステップ４１４）。
【００９９】
以上の処理が終わると、ｉ行目が最終行かどうかをチェックする（ステップ４１５）。もし最終行で無い場合は、変数ｉに１を加え処理を８１１へ戻す（ステップ４１６）。一方最終行だった場合、次に変数ｕｓｅｄとｒｅｓｅｒｖｅｄとｒｅｑｕｅｓｔｅｄの合計の値が、そのアクセスポイントの持つ合計リソース量、例えば本実施の形態の場合であればアクセスポイントの実効レートの最大値、よりも大きい場合は、要求元にリソースを確保できなかったことを通知する旨のＭＬＭＥ−ＲＥＳＯＵＲＣＥ＿ＲＥＱＵＥＳＴ．ｒｅｓｐｏｎｓｅプリミティブ、つまりパラメータとしてＲＤＩＥのＳｔａｔｕｓ  Ｃｏｄｅを０以外の値にセットしたＲＩＣ−Ｒｅｓｐｏｎｓｅを持つＭＬＭＥ−ＲＥＳＯＵＲＣＥ＿ＲＥＱＵＥＳＴ．ｒｅｓｐｏｎｓｅプリミティブをＩＥＥＥ  ８０２．１１  ＭＬＭＥ部（４０９）に対して発行し（ステップ４１８）、再び処理をステップ４０１へ移し別のリソース要求が発行されるのを待機する。一方、もし変数ｕｓｅｄとｒｅｓｅｒｖｅｄとｒｅｑｕｅｓｔｅｄの合計の値が、そのアクセスポイントの持つ合計リソース量よりも小さい場合は、要求元にリソースを確保できたことを通知する旨のＭＬＭＥ−ＲＥＳＯＵＲＣＥ＿ＲＥＱＵＥＳＴ．ｒｅｓｐｏｎｓｅプリミティブ、つまり本プリミティブのパラメータに含まれるＲＩＣ−Ｒｅｑｕｅｓｔ内にあるＲＤＩＥのＳｔａｔｕｓ  Ｃｏｄｅが０にセットされたプリミティブをＩＥＥＥ  ８０２．１１  ＭＬＭＥ部（４０９）に対して発行する（ステップ４１９）。
【０１００】
次にリソース管理テーブルの処理行を表す変数ｊに１をセットする（ステップ４２０）。ＭＬＭＥ−ＲＥＳＯＵＲＣＥ．ｒｅｑｕｅｓｔに関するリソースの要求者のアドレスとテーブルのｊ行目に記載されているアドレスが一致しているかを調べる（ステップ４２１）。一致していればテーブルの内容である要求されたリソース量であるＭｅａｎ  Ｄａｔａ  Ｒａｔｅ、予約実施アクセスポイント数、予約期限をＭＬＭＥ−ＲＥＳＯＵＲＣＥ．ｒｅｑｕｅｓｔに関するものに更新する（ステップ４２２）。アドレスが一致していなければｊ行目がテーブルの最終行かを調べる（ステップ４２３）。最終行であればリソース管理テーブルに受信したＭＬＭＥ−ＲＥＳＯＵＲＣＥ．ｒｅｑｕｅｓｔに関するリソースの要求者、要求されたリソース量であるＭｅａｎ  Ｄａｔａ  Ｒａｔｅ、予約実施アクセスポイント数、予約期限をセットし、さらにリソース使用状態として“予約中”をセットされた行を追加する（ステップ４２４）。最終行でなければｊに１を加え（ステップ４２５）、ステップ４２１へ戻る。
【０１０１】
以上の処理が終わると、再び処理をステップ４０１へ移し別のリソース要求が発行されるのを待機する。ステップ４１３ではｅｘｐｅｃｔａｔｉｏｎの値はｒｅｓｅｒｖｅｄにｐｒｏｂａｂｉｌｉｔｙを乗じたものとしたが、ｒｅｓｅｒｖｅｄそのものの値を使用するという処理でもよい。また、ステップ４１８ではｕｓｅｄとｒｅｓｅｒｖｅｄとｒｅｑｕｅｓｔｅｄの合計値とアクセスポイントの持つ合計リソース量とを比較するとしたが、厳密に大小を比較する必要はなく合計リソース量のM％を超えた場合は予約を受けつけない、またはN％までは予約を受けつけるなどある程度の幅を持たせるという形にしてもよい。（M、Nは正の数）
本実施の形態では無線ＬＡＮとして記載したが、予約実施通信装置数が受け渡され、その数を使用してリソースの予約を受けつけるか判断するという処理を行っていれば無線、有線また受け渡すフォーマットを問わず適応できることは言うまでもない。
【０１０２】
また、本実施の形態では予約実施アクセスポイント数を用いて説明したがこれは予約を受けつける通信装置をアクセスポイントとしているのに伴い、予約実施通信装置数の一例として示したものである。
【０１０３】
なお、本実施の形態ではリソースの予約を行う通信装置が既に予約をしている通信装置数を予約実施通信装置数としてリソースの予約を受けつける通信装置に通知するものとして説明したが、予約を行う予定であるが、予約を実施していない予約をしようとしている通信装置数を予約実施通信装置数として通知するという形態でもよい。本実施の形態で説明した無線ＬＡＮを例に取ると“予約処理前”という状態にあるアクセスポイントが予約をしようとしているアクセスポイントに該当する。  
（第２の実施の形態）
【０１０４】
本実施の形態では予約を行う通信装置から予約を受けつける通信装置に通知される予約実施通信装置数の一例としてリソースの予約を行う通信装置が既に予約をしている通信装置数とこれから予約をする通信装置数の和が通知されるものとして説明する。
【０１０５】
以下、予約を受けつける通信装置をアクセスポイント、予約を行う通信装置を移動局とし、アクセスポイントと移動局からなる無線ＬＡＮシステムを一例として、説明する。本実施の形態の構成についてその基本的構成は第１の実施の形態のとおりであるが、図3の構成に示される移動局（１１１）におけるリソース予約処理手段（３１３）の動作が異なっている。
【０１０６】
図１４は予約を行う通信装置におけるリソース予約処理手段（３１３）の動作を示すフローチャートである。
【０１０７】
第１の実施の形態ではハンドオーバ先候補情報テーブルのｉ行目のリソース予約状態が“予約処理中”または“予約済み”かどうかを調べ（ステップ３０３）、該当すればｎｕｍ＿ａｐに１を加えて（ステップ３０４）いたが、本実施の形態では “予約処理中”または“予約済み”または“予約処理前”かどうかを調べ（ステップ５０１）、ｎｕｍ＿ａｐに１を加える（ステップ３０４）。この処理によって得られたｎｕｍ＿ａｐを予約実施アクセスポイント数としてＡＰ数（７２６）に格納し（ステップ３１２）、ＭＬＭＥ部（３０７）に対してＭＬＭＥ−ＲＥＳＯＵＲＣＥ＿ＲＥＱＵＥＳＴ．ｒｅｑｕｅｓｔプリミティブを発行する（ステップ３１２）という処理は第1の実施の形態と同一である。
【０１０８】
なお、本形態では移動局において既に予約している通信装置数とこれから予約をする通信装置数を合計し送信していたが、移動局から２つの数のそれぞれを報告し、アクセスポイントにおいてその和を取るという形態でもよい。
【０１０９】
図１５はこの形態を取る場合の８０２．１１  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｃｏｎｔｒｏｌフレーム（５０３）の構成例を示したものである。図１５のＯｐｔｉｏｎａｌ  Ｐａｒａｍｅｔｅｒｓ（７２３）にＲｅｓｅｒｖｅｄ  ＡＰ数（８０１）及びＲｅｓｅａｒｖｉｎｇ  ＡＰ数（８０２）という２つのフォーマットを用意し、それぞれ既に予約している通信装置数及びこれから予約をする通信装置数を格納して予約実施アクセスポイント数として送信する。
【０１１０】
図１６は本形態のアクセスポイント（１０１〜１０７）の構成の一例を示すブロック図である。ＩＥＥＥ  ８０２．１１  ＳＭＥ部（４１０）において前記Ｏｐｔｉｏｎａｌ  Ｐａｒａｍｅｔｅｒｓに予約実施通信装置数として前記Ｒｅｓｅｒｖｅｄ  ＡＰ数及びＲｅｓｅａｒｖｉｎｇ  ＡＰ数という２つの要素がある場合に、それらを合計する処理が行われる合計数処理手段（９０１）が含まれ、合計した数は予約実施アクセスポイント数としてリソース予約受付判断手段（４１１）に報告される。リソース予約受付判断手段（４１１）の処理は第１の実施の形態と同一である。なお、合計数処理手段（９０１）はＩＥＥＥ  ８０２．１１  ＳＭＥ部（４１０）に含むものとして説明をしたが、ＩＥＥＥ  ８０２．１１  ＭＬＭＥ部（４０９）に含んでもよいし、リソース予約受付判断手段（４１１）内部にその機能が含まれていてもよい。
【０１１１】
また、第１の実施の形態同様、アクセスポイント（１０１〜１０７）のリソース予約受付判断手段（４１１）の処理を示す図１３に含まれるステップ４０２ではリソース量として移動局が要求する平均のデータレートであるＭｅａｎ  Ｄａｔａ  Ｒａｔｅの値だけではなくこれ以外の要求のタイプであるＭｉｎｉｍｕｍ  Ｄａｔａ  ＲａｔｅやＰｅａｋ  Ｄａｔａ  Ｒａｔｅを用いた場合についても、全体の使用リソース量が各々の移動局が利用するリソース量の和で表されるようなリソース量であれば適用可能であることは言うまでもない。また、ｒｅｑｕｅｓｔｅｄに代入する数値はＲＩＣ  Ｉｎｆｏｒｍａｔｉｏｎ  ｅｌｅｍｅｎｔｓに含まれるリソース量そのままを用いてもよい。
【０１１２】
なお、既に予約している通信装置数及びこれから予約をする通信装置数の合計もしくは２つの値を送信するとして説明をしたが、これらの値は通信装置数そのものでなく重み付けした値または重み付けした値の合計を移動局からアクセスポイントに通知する形態もしくは通信装置数そのものの値で移動局からアクセスポイントに通知されたものをアクセスポイントにて重み付けして合計数処理手段（９０１）で合計するという形態でもよい。合計数処理手段（９０１）はＩＥＥＥ  ８０２．１１  ＳＭＥ部（４１０）、ＩＥＥＥ  ８０２．１１  ＭＬＭＥ部（４０９）、リソース予約受付判断手段（４１１）内部いずれに含まれてもよい。
（第３の実施の形態）
【０１１３】
本実施の形態では予約を受けつける通信装置は、予約を受けつける通信装置が現在使用しているリソース量と、予約を行う通信装置が予約を受けつける通信装置に対して予約をしているリソース量を予約実施通信装置数で除算した結果との和を計算し、その結果と予約を受けつける通信装置が保有している全リソース量とを比較することで予約の受付を行うことを特徴としている。
【０１１４】
以下、予約を受けつける通信装置をアクセスポイント、予約を行う通信装置を移動局とし、アクセスポイントと移動局からなる無線ＬＡＮシステムを一例として、説明する。
【０１１５】
本実施の形態の構成についてその基本的構成は第１の実施の形態のとおりであるが、図４の構成に示されるアクセスポイント（１０１〜１０７）におけるリソース予約受付判断手段（４１１）の動作が異なる。
【０１１６】
図１７は第３の実施の形態におけるリソース予約処理手段（３１１）の動作を示すフローチャートである。
【０１１７】
第１の実施の形態ではステップ４１１から４１６でｒｅｓｅｒｖｅｄとして他の予約を行う通信装置が予約を行っているリソースに関する処理を行っているが、本実施の形態ではその処理を省いている。また第１の実施の形態においてはステップ４１７の処理でｕｓｅｄとｒｅｓｅｒｖｅｄ及びｒｅｑｕｅｓｔｅｄの合計とそのアクセスポイントの合計リソース量を比較していたが、本実施の形態ではｕｓｅｄ及びｒｅｑｕｅｓｔｅｄの合計とそのアクセスポイントの合計リソース量を比較し（ステップ６０１）、予約を受けつけるか否かを判断している。
【０１１８】
また、本実施の形態においても第１の実施の形態同様厳密に大小を比較する必要はなく合計リソース量の９５％を超えた場合は予約を受けつけない、または１１０％までは予約を受けつけるなどある程度の幅を持たせるという形にしてもよい。
（第４の実施の形態）
【０１１９】
本実施の形態は予約を受けつける通信装置と予約を行う通信装置がともに移動局であることを特徴としている。
【０１２０】
以下、移動局間でアドホック通信を行うような無線ＬＡＮシステムを一例として、説明する。
【０１２１】
図１８は本実施の形態での無線LANシステムの構成を示す図である。本ネットワークは移動局（１００１、１００２、１００３、１００４）から構成される。
【０１２２】
図１９は本実施の形態における移動局（１００１〜１００４）の構造を示すブロック図である。移動局（１００１〜１００４）のＳＭＥ（１１０１）は移動局（１１１）に含まれるＳＭＥリソース要求手段（３１４）及びアクセスポイント（１０１〜１０７）に含まれるＳＭＥリソース受付手段（４１４）から構成される。ＳＭＥ以外の構成は第１の実施の形態の移動局と同一であるため説明を省略する。
【０１２３】
移動局（１００４）は現在移動局（１００２）を介して移動局（１００１）から提供される情報を受信しているが、移動局（１００４）の移動や電界強度の変化などにより経路が変更される可能性がある。例えば移動局（１００２）を介した経路から移動局（１００３）を介したものへと変更されるようなものである。経路の変更の際には変更先である移動局（１００３）で予めリソースを確保しておくことが望ましい。
【０１２４】
第１の実施の形態では予約を受付ける動作はアクセスポイントにて行っていたが本実施の形態ではその動作が移動局によって行われる点及び通知されるパラメータが予約実施アクセスポイント数ではなく予約実施移動局数であること以外の処理等は同一であるため説明は省略する。
【０１２５】
なお、本実施の形態では第１の実施の形態に基づく形としたが予約実施移動局数の決定の方法及びリソースの受付を判断する方法は第２または第３の実施の形態に基づく形でもよい。
（第５の実施の形態）
【０１２６】
本実施の形態では予約を行う通信装置は予約を受けつける通信装置に通信装置数をリソースの予約を実行するプロトコル階層よりも上位のプロトコル階層において送信することを特徴としている。
【０１２７】
以下、予約を受けつける通信装置をアクセスポイント、予約を行う通信装置を移動局とし、アクセスポイントと移動局からなる無線ＬＡＮシステムを一例として、説明する。
【０１２８】
本実施の形態はその基本的構成は第１の実施の形態のとおりであるが、図3の構成に示される移動局（１１１）に含まれるＭＡＣ部（３０３）および図４の構成に示されるアクセスポイント（１０１〜１０７）内に含まれるＭＡＣ部（３０６）にＩＥＥＥ  ８０２．１１ｒ仕様で規定されない部分を混入しないように工夫している。
【０１２９】
図２０は本実施の形態における移動局（１１１）の構造を示す図である。本実施の形態における移動局（１１１）の構造は基本的に図３と同じであるが、ＭＡＣ部（１２０１）、ＭＬＭＥ部（１２０２）、リソース予約処理手段（１２０３）の機能が異なり、また予約実施アクセスポイント数通知手段（１２０４）が追加されている点が異なる。
【０１３０】
ＭＡＣ部（１２０１）は、ＩＥＥＥ  ８０２．１１ｅ規格およびＩＥＥＥ  ８０２．１１ｒ規格で規定されるＭＡＣ機能を処理するものであり、第１から第３の実施の形態のような予約実施アクセスポイント数をＡｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｃｏｎｆｉｒｍフレームに搭載する機能は必要ない。
【０１３１】
ＭＬＭＥ部（１２０２）は、予約実施アクセスポイント数をＳＭＥ部（３０８）から受け取る機能がない点以外は図３のＭＬＭＥ部（３０７）と同じである。
【０１３２】
リソース予約処理手段（９０３）は、予約実施アクセスポイント数の合計数をＭＬＭＥ部（１２０２）ではなく予約実施アクセスポイント数通知手段（１２０４）に通知する点以外は図３のリソース予約処理手段（３１３）と同じである。
【０１３３】
予約実施アクセスポイント数通知手段（１２０４）は、リソース予約処理手段（１２０３）から予約実施アクセスポイント数を受け取ると、ＴＣＰ／ＩＰ部（３０２）からリソース要求先のアクセスポイントへ予約実施アクセスポイント数を含んだパケットを送信する。
【０１３４】
図２１は本実施の形態におけるアクセスポイント（１０１〜１０７）の構造を示すブロック図である。本実施の形態におけるアクセスポイント（１０１〜１０７）の構造は基本的に図４と同じであるが、ブリッジの代わりにＴＣＰ／ＩＰ部（１３０１）が存在し、ＴＣＰ／ＩＰ上で動作するアプリケーションとして予約実施アクセスポイント数受付手段（１３０２）が追加された点が異なる。ＴＣＰ／ＩＰ部（１３０１）は図４で記載したものと同じであるが、本実施の形態ではＩＥＥＥ  ８０２．３  ＭＡＣ部（４０２）とＩＥＥＥ  ８０２．１１  ＭＡＣ部（４０６）の２つのメディアに接続されていることから、ルーティング機能も有している。予約実施アクセスポイント数受付手段（１３０２）は移動局（１１１）から予約実施アクセスポイント数を含んだパケットが送られてくると、パケットのAP数フィールドから予約実施アクセスポイント数を抜き出し、その値をリソース管理データベース（４１３）に格納されるリソース管理テーブル内において、該当する移動局の行の予約実施アクセスポイント数の欄にその値をセットする。
【０１３５】
図２２は本実施の形態における移動局（１１１）内のリソース予約処理手段（１２０３）の処理を示すフローチャートである。本フローチャートは基本的に図８と同じであるが、Ｆａｓｔ  ＢＳＳ  Ｔｒａｎｓｉｔｉｏｎ情報エレメント部分を生成した（ステップ３１１）後に作成したＦａｓｔ  ＢＳＳ  Ｔｒａｎｓｉｔｉｏｎ情報エレメント部分をパラメータとしてＭＬＭＥ部（１２０２）に対してＭＬＭＥ−ＲＥＳＯＵＲＣＥ＿ＲＥＱＵＥＳＴ．ｒｅｑｕｅｓｔプリミティブを発行する（ステップ７０１）処理が変更になっている点と、ｎｕｍ＿ａｐの値とリソースを予約するアクセスポイントのＭＡＣアドレスを予約実施アクセスポイント数通知手段（１２０４）へ通知する（ステップ７０２）処理が追加されている点が異なる。ステップ７０１及びステップ７０２以外の処理は図８と同じである。
【０１３６】
図２３は本実施の形態における移動局（１１１）内の予約実施アクセスポイント数通知手段（１２０４）の動作を示すフローチャートである。リソース予約処理手段（１２０３）から通知されたリソース要求先のアクセスポイントのＭＡＣアドレスを用いて、そのアクセスポイントのＩＰアドレスを取得する（ステップ８０１）。このＩＰアドレスの取得の方法は、ＲＡＲＰプロトコルを用いて取得する方法や、移動局（１１１）内にあらかじめＭＡＣアドレスに対応したＩＰアドレスのデータをセットする方法、およびモビリティドメイン１４１内のネットワーク（１２１）に、ＭＡＣアドレスを問い合わせるとＩＰアドレスを返答するようなサーバを設置する方法などがある。次に送信するデータを作成する（ステップ８０２）。そして作成したデータをＴＣＰ／ＩＰ部へ渡す（ステップ８０３）。
【０１３７】
図２４はＴＣＰ／ＩＰ部（１３０１）がリソース要求先のアクセスポイントへ送信するデータのフォーマットの一例を示すものである。
【０１３８】
ＳＴＡ  Ａｄｄｒｅｓｓ（１４０１）には送信元である自身のＭＡＣアドレスを格納する。Ｔａｒｇｅｔ  ＡＰ  Ａｄｄｒｅｓｓ（１４０２）には、リソースを要求するアクセスポイントのＭＡＣアドレスをセットする。ＡＰ数（１４０３）には、リソース予約処理手段（１２０３）から送られてきたｎｕｍ＿ａｐの値をセットする。
【０１３９】
送信するデータの作成が終わると、作成したデータを処理１２０１で調査したアクセスポイントのＩＰアドレスとともにＳｏｃｋｅｔ  Ｉ／Ｆなどを用いてＴＣＰ／ＩＰ部（３０２）へ渡す。すると本データは予約実施アクセスポイント数通知パケットとしてリソース要求先のアクセスポイントへ送られる。以上で予約実施アクセスポイント数通知手段（１２０４）の処理は終了である。
【０１４０】
図２５は予約実施アクセスポイント数受付手段（１３０２）の動作を示すフローチャートである。図２０のアクセスポイントの構成図を参照して、この動作を説明する。ＴＣＰ／ＩＰ部（１３０１）から予約実施アクセスポイント数通知パケットを受信したかどうかチェックする（ステップ９０１）。受信していない場合は再び処理をステップ９０１へ戻し、受信するまで待機する。受信した場合は、受信したデータのＳＴＡ  Ａｄｄｒｅｓｓ（１４０１）を参照して送信元アドレスを取得し、それを変数ａｄｄｒへ格納する（ステップ９０２）。次に受信したデータから、ＡＰ数（１４０３）に含まれている値を変数ｎｕｍ＿ａｐへ代入する（ステップ９０３）。ステップ９０３の処理が終わると、リソース管理データベース内のリソース管理テーブルの処理行を表す変数ｉに１をセットする（ステップ９０４）。次にｉ行目の要求者のアドレスが変数ａｄｄｒの値と同じかどうか調べる（ステップ９０５）。もし同じである場合はｉ行目の予約実施アクセスポイント数のセルに変数ｎｕｍ＿ａｐの値をセットし（ステップ９０６）、再び処理をステップ９０１へ戻す。もし同じでなかった場合は、ｉ行目がリソース管理データベースにおける最終の行かどうかをチェックする（ステップ９０７）。最終の行であれば処理をステップ９０１へ戻す。最終の行でない場合は、変数ｉに１を加え（ステップ９０８）、処理をステップ９０５へ移す。以上が予約実施アクセスポイント数受付手段の動作である。
【０１４１】
図２６は本実施の形態における交換されるフレームのシーケンスを示すシーケンス図である。本実施の形態では図１０と同じように８０２．１１  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｒｅｑｕｅｓｔ（１５０１）、８０２．１１  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｒｅｓｐｏｎｓｅ（１５０２）、８０２．１１  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｃｏｎｆｉｒｍ（１５０３）、８０２．１１  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ａｃｋ（１５０４）を最初に交換する。８０２．１１  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｃｏｎｆｉｒｍ（１５０３）には予約実施アクセスポイント数は格納されていない。Ａｕｔｈｅｎｔｉｃａｔｉｏｎフレームの交換が終わった後、移動局は予約実施アクセスポイント数をＴＣＰ／ＩＰ層で通知する（１５０５）。これを受信するとアクセスポイントのＴＣＰ／ＩＰ部は確認応答を返す（１５０６）。
【０１４２】
このように、本実施の形態では予約実施アクセスポイント数をＴＣＰ／ＩＰ層で送信するため、移動局は予約実施アクセスポイント数を送るためのＩＥＥＥ  ８０２．１１ｒでは規定されないフレームフォーマットや新たな手段を導入する必要がなく、一般的なＩＥＥＥ  ８０２．１１ｒ実装を用いつつ、アクセスポイントの持つリソースを有効に活用できるという効果が得られる。
（第６の実施の形態）
【０１４３】
本実施の形態では予約を受けつける通信装置は予約を行う通信装置からリソースの予約を受けつけたかを他の予約を受けつける通信装置に対して問い合わせることを特徴としている。
【０１４４】
以下、予約を受けつける通信装置をアクセスポイント、予約を行う通信装置を移動局とし、アクセスポイントと移動局からなる無線ＬＡＮシステムを一例として、説明する。
【０１４５】
本実施の形態では、その基本的構成は第５の実施の形態のとおりであるが、アクセスポイント側で予約実施アクセスポイント数を調査することで、移動局側に特殊な手段を必要としないように工夫している。なお、第１の実施の形態のような構成としてもよい。
【０１４６】
図２７は本実施の形態で用いるアクセスポイント（１０１〜１０７）の構造を示すブロック図である。図２１で示したアクセスポイントの構造と比較し、予約実施アクセスポイント数受付手段（１３０２）が削除され、予約実施アクセスポイント数調査依頼応答手段（１６０１）、予約実施アクセスポイント数調査パケット送受信手段（１６０２）、予約実施アクセスポイント数調査手段（１６０３）が新たに追加されている。なお、予約実施アクセスポイント数調査手段（１６０３）には予約実施アクセスポイント数調査スレッド（１６０５）が含まれる。また、第1の実施の形態と動作が異なるリソース予約受付判断手段（１６０４）が用いられる。
【０１４７】
予約実施アクセスポイント数調査依頼応答手段（１６０１）は、移動局のリソース要求に関する他のアクセスポイントからの問い合わせに対して応答するための手段である。
【０１４８】
予約実施アクセスポイント数調査パケット送受信手段（１６０２）は、予約実施アクセスポイント数調査手段（１６０３）から依頼があると、予約実施アクセスポイント数を把握するために、他のアクセスポイントに対して問い合わせの調査パケットを送信、およびそのパケットに対する応答を受信するための手段である。予約実施アクセスポイント数調査手段（１６０３）は、リソース予約受付判断手段（１６０４）から当該移動局がリソースの予約を要求した旨の通知を受けると、予約実施アクセスポイント数調査パケット送受信手段（１６０２）に対して調査用のパケットを送信するよう依頼し、また調査結果が予約実施アクセスポイント数調査パケット送受信手段（１６０２）から送られてくると、その結果をリソース管理データベース（４１３）に書き込む。
【０１４９】
図２８はリソース予約受付判断手段（１６０４）の動作を示すフローチャートである。本図が図１３と異なる点は、ステップ４０２がステップ１００１へ変更された点と、ステップ１００２が追加された点である。ＩＥＥＥ  ８０２．１１  ＭＬＭＥからＭＬＭＥ＿ＲＥＳＯＵＲＣＥ＿ＲＥＱＵＥＳＴ．ｉｎｄｉｃａｔｉｏｎを受信したか調査し（ステップ４０１）、受信していた場合、移動局が要求したリソース量を格納する変数ｒｅｑｕｅｓｔｅｄに受信したＭＬＭＥ−ＲＥＳＯＵＲＣＥ＿ＲＥＱＵＥＳＴ．ｉｎｄｉｃａｔｉｏｎで送られてきたリソース量を格納する（ステップ１００１）。予約実施アクセスポイント数で除することなく要求リソース量をそのままの値で格納するのは、移動局からリソース要求を受け付けた時点で、アクセスポイント側が該移動局に関する予約実施アクセスポイント数を把握していないからである。また、ステップ４１７で使用中のリソース合計量と予約されたリソースの期待値の合計量と予約されたリソース量の和がアクセスポイントの持つリソース量を比較する。使用中のリソース合計量と予約されたリソースの期待値の合計量の方が少なかった場合、ＭＬＭＥ−ＲＥＳＯＵＲＣＥ＿ＲＥＱＵＥＳＴ．ｒｅｓｐｏｎｓｅプリミティブをＩＥＥＥ  ８０２．１１  ＭＬＭＥへ発行し（ステップ４１９）、リソース管理テーブルを更新した後（ステップ４２０）、予約実施アクセスポイント数調査手段（１６０３）に要求元の移動局のアドレスとともに移動局からリソース要求があったことを移動局のＭＡＣアドレスとともに通知する（ステップ１００２）。ステップ１００１及びステップ１００２以外の処理は、図１３と同じである。
【０１５０】
図２９は予約実施アクセスポイント数調査手段（１６０３）の動作を示すフローチャートである。リソース予約受付判断手段（１６０４）からリソース予約の通知を受信したかどうか調べる（ステップ１１０１）。もし受信した場合は、リソース予約受付判断手段から通知された予約実施アクセスポイント数を調査するために、予約実施アクセスポイント数調査スレッド（１６０５）を１つ起動し、そのスレッドに調査対象の移動局のＭＡＣアドレスを通知する（ステップ１１０２）。本スレッドが起動すると再び処理をステップ１１０１に戻す。ステップ１１０１においてリソース予約受付判断手段（１６０４）からリソース予約の通知を受信していない場合は、予約実施アクセスポイント数調査スレッド（１６０５）が結果を受信したかどうかチェックする（ステップ１１０３）。もし受信していない場合は、処理をステップ１１０１へ戻す。受信していた場合は、調査対象の移動局のＭＡＣアドレスを変数ａｄｄｒに、調査結果を変数ｎｕｍ＿ａｐへセットする（ステップ１１０４）。次に調査結果をリソース管理データベースに反映させるため、リソース管理データベース内のリソース管理テーブルの処理行を表す変数ｉに１をセットする（ステップ１１０５）。次にｉ行目の要求者のアドレスがａｄｄｒと同じかどうかチェックする（ステップ１１０６）。もし同じである場合は、ｉ行目の要求ＡＰ数のセルにｎｕｍ＿ａｐの値を格納し（ステップ１１０７）、処理をステップ１１０１へ戻す。もし同じでなかった場合は、ｉ行目がリソース管理テーブルにおける最終行かどうかチェックする（ステップ１１０８）。もし最終行であれば処理をステップ１１０１へ戻す。そうでない場合はｉに１を加え（ステップ１１０９）、ステップ１１０６へ飛ぶ。
【０１５１】
図３０は予約実施アクセスポイント数調査スレッド（１６０５）の動作を示すフローチャートである。合計アクセスポイント数パケット送受信手段（１６０２）へ調査用パケットの送信を依頼する（ステップ１２０１）。次にアクセスポイントからの応答の受付を締め切る時刻ｄｅａｄｌｉｎｅとして、現在時刻に応答待機時間を加えた時刻をセットする（ステップ１２０２）。応答待機時間は例えば同一モビリティドメインに属するアクセスポイントの数やアクセスポイントが接続されているネットワークの伝送レート、および平均混雑度合いを考慮して決定する時間である。次に予約実施アクセスポイント数を格納する変数ｎｕｍ＿ａｐを０に初期化する（ステップ１２０３）。次に、合計アクセスポイント数パケット送受信手段より処理１９０２で送信したパケットに対する応答パケットの受信の通知が届いたかどうかチェックする（ステップ１２０４）。もし届いた場合は、変数ｎｕｍ＿ａｐに１を加え（ステップ１２０５）、再び処理をステップ１２０４へ戻してイベントの受信を待機する。もし処理１９０１で送信したパケットに対する応答パケットの受信の通知が届いていなかった場合は、次に現在の時刻がｄｅａｄｌｉｎｅを過ぎているかどうかをチェックする（ステップ１２０６）。もし過ぎていない場合は、処理をステップ１２０４へ戻してイベントの受信を待機する。一方過ぎている場合は、スレッド起動元に調査対象の移動局のアドレスと調査結果ｎｕｍ＿ａｐを通知する（ステップ１２０７）。調査結果を通知すると予約実施アクセスポイント数調査スレッド（１６０５）の処理を終了する。
【０１５２】
図３１は予約実施アクセスポイント数調査パケット送受信手段（１６０２）の動作を示すフローチャートである。予約実施アクセスポイント数調査手段（１６０３）より調査パケット送信を依頼されたかどうかチェックする（ステップ１３０１）。もし調査パケット送信を依頼された場合、合計アクセスポイント調査スレッド（１６０５）から受け取ったＭＡＣアドレスを用いて調査パケットを作成する（ステップ１３０２）。
【０１５３】
図３２は予約実施アクセスポイント数調査パケット送受信手段（１６０２）が送信を行う調査パケットの一例を示すものである。この場合はリソース要求移動局ＭＡＣアドレスフィールド（１７０１）から構成され、ここに予約実施アクセスポイント数調査手段（１６０３）から受け取ったＭＡＣアドレスをセットする。調査パケットが完成すると、その調査パケットをブロードキャスト宛に送信する（ステップ１３０３）。ステップ１３０３の処理が終わると再び処理をステップ１３０１へ戻し、イベントの受信を待機する。次にステップ１３０１において予約実施アクセスポイント数調査手段（１６０３）より調査パケット送信を依頼されなかった場合について説明する。この場合、ＴＣＰ／ＩＰ部（１３０１）より調査パケットに対する応答を受信したかどうかを調べる（ステップ１３０４）。もし受信しなかった場合、再び処理をステップ１３０１へ戻しイベントの受信を待機する。一方応答を受信した場合、受信データした応答パケットより調査対象の移動局アドレスを取得する（ステップ１３０５）。
【０１５４】
図３３は調査パケットに対する応答パケットの一例を示すものである。この場合もリソース要求移動局ＭＡＣアドレスフィールド（１８０１）から構成され、ここには受信した調査パケットに格納されていたリソース要求移動局のＭＡＣアドレスがそのままコピーされ格納される。したがって、調査対象の移動局のアドレスはリソース要求移動局ＭＡＣアドレスフィールド（１８０１）の内容を参照すれば取得できる。次に本移動局に対する調査を要請したスレッドに対してパケット受信の旨を通知する（ステップ１３０６）。
【０１５５】
図３４は予約実施アクセスポイント数調査依頼応答手段（１６０１）の動作を示すフローチャートである。他のアクセスポイントより調査パケットをＴＣＰ／ＩＰ部（１３０１）経由で受信したかどうかを調べる（ステップ１４０１）。もし受信していない場合は、再び処理をステップ１４０１へ戻す。もし受信した場合は、調査パケットよりリソース要求移動局のＭＡＣアドレスを変数ａｄｄｒに格納する（ステップ１４０２）。当該移動局がリソース管理データベース内にあって、かつ予約中かどうかを調べるために、リソース管理データベース内のリソース管理テーブルの処理行に、先頭行を示す変数ｉに１をセットする（ステップ１４０３）。次にリソース管理テーブルｉ行目の要求者のアドレスを調べ、その値がａｄｄｒと同じかどうか調べる（ステップ１４０４）。もし異なる場合、まず初めにｉ行目がリソース管理テーブルの最終行かどうか調べる（ステップ１４０８）。  最終行である場合、予約実施アクセスポイント数調査依頼応答手段の処理は終了である。最終行でない場合は、ｉに１を加え（ステップ１４０９）、処理をステップ１４０４へ戻す。ステップ１４０４においてリソース管理テーブルｉ行目の要求者のアドレスが変数ａｄｄｒの値と一致した場合、次にｉ行目のリソース使用状態が“予約中”であるかどうか調べる（ステップ１４０５）。予約中でない場合は、予約実施アクセスポイント数調査依頼応答手段（１６０１）の処理は終了である。予約中である場合は、調査パケットに対する応答パケットを作成する（ステップ１４０６）。ここでは応答パケットのフィールド２４０１に変数ａｄｄｒの値を格納して応答パケットを作成する。そして調査パケットの送信元に対して作成した応答パケットを返信する（ステップ１４０７）。以上で予約実施アクセスポイント数調査依頼応答手段の処理は終了である。
【０１５６】
このようにして得た予約実施アクセスポイント数を予約受付の判断に用いる方法は第１から第３の実施の形態と同一であるため説明を省略する。
【０１５７】
本実施の形態ではアクセスポイント（１０１〜１０７）同士で予約実施アクセスポイント数を調査、応答するため、移動局（１１１）に新たな手段を実装することなく、アクセスポイントの持つリソースを有効に活用できるという効果が得られる。
（第７の実施の形態）
【０１５８】
本実施の形態では予約を受けつける通信装置は予約を行う通信装置からリソースの予約を受けつけたかを他の予約を受けつける通信装置に対して問い合わせること及び調査結果をその通信装置の予約受付の判断に用いることを特徴としている。
【０１５９】
以下、予約を受けつける通信装置をアクセスポイント、予約を行う通信装置を移動局とし、アクセスポイントと移動局からなる無線ＬＡＮシステムを一例として、説明する。
【０１６０】
本実施の形態の構成についてその基本的構成は第６の実施の形態のとおりであるが、図４の構成に示されるアクセスポイント（１０１〜１０７）に含まれるリソース予約受付判断手段（４１１）の動作が異なる。
【０１６１】
第６の実施の形態では移動局（１１１）からリソース要求を受けつけた時点でアクセスポイント（１０１〜１０７）は予約実施アクセスポイント数を把握していないが、本実施の形態では予約実施アクセスポイント数の把握をすることを特徴としている。
【０１６２】
図３５は本実施の形態におけるリソース予約処理手段（４１１）の動作を示すフローチャートである。
【０１６３】
ＩＥＥＥ  ８０２．１１  ＭＬＭＥからＭＬＭＥ＿ＲＥＳＯＵＲＣＥ＿ＲＥＱＵＥＳＴ．ｉｎｄｉｃａｔｉｏｎを受信したか調査し（ステップ４０１）、受信していた場合、アクセスポイント数調査応答待機時間待機する（ステップ１５０１）。ここでアクセスポイント数調査応答待機時間はリソース予約受付判断手段（４１１）には予約実施アクセスポイント数調査スレッド（１６０５）で保持している応答待機時間にマージンを加えて予め設定されるものであり、マージンは予約実施アクセスポイント数調査パケット送受信手段により送信される調査パケットが他のアクセスポイントに届くまでの時間や予約実施アクセスポイント数調査手段（１６０３）がｎｕｍ＿ａｐをリソース管理データベース（４１３）に書き込む時間などが勘案され設定される。次にリソース管理テーブルを参照するための変数ｋを０とする（ステップ１５０２）。リソース管理テーブルのｋ行目の要求者のアドレスがＭＡＣアドレスと一致するか調査し（ステップ１５０３）、一致すればｒｅｑｕｅｓｔｅｄに受信したＭＬＭＥ−ＲＥＳＯＵＲＣＥ＿ＲＥＱＵＥＳＴ．ｉｎｄｉｃａｔｉｏｎで送られてきたリソース量をリソース管理テーブルのｋ行目の予約実施アクセスポイント数で除したものを代入し（ステップ１５０４）、ステップ４０３へと進む。ステップ１５０３においてＭＡＣアドレスと一致しない場合はｋに１を加え（ステップ１５０５）、ステップ１５０３へ戻す。
【０１６４】
このように、本実施の形態ではアクセスポイント（１０１〜１０７）同士で予約実施アクセスポイント数を調査、応答するため、移動局（１１１）に新たな手段を実装することなく、アクセスポイントの持つリソースを有効に活用できるという効果が得られる。
（第８の実施の形態）
【０１６５】
本実施の形態では予約を受けつける通信装置は予約を行う通信装置からリソースの予約を受けつけた際に他の予約を受けつける通信装置に対して通知することを特徴としている。
【０１６６】
以下、予約を受けつける通信装置をアクセスポイント、予約を行う通信装置を移動局とし、アクセスポイントと移動局からなる無線ＬＡＮシステムを一例として、説明する。
【０１６７】
本実施の形態の基本的構成は第６の実施の形態のとおりであるが、アクセスポイントがリソース要求を受け付けるとそのことを他のアクセスポイントへ報知することで、アクセスポイント間で交換されるパケット数を削減する工夫をしている。
【０１６８】
図３６は本実施の形態におけるアクセスポイント（１０１〜１０７）の構造を示すブロック図である。図２７と比較し、予約実施アクセスポイント数調査依頼応答手段（１６０１）、予約実施アクセスポイント数調査パケット送受信手段（１６０２）、予約実施アクセスポイント数調査手段（１６０３）が削除され、新たにリソース要求受付通知管理データベース（１９０２）、リソース要求受付通知パケット送信手段（１９０３）、リソース要求受付通知パケット受信手段（１９０４）、および時刻取得手段（１９０５）が新規に追加されている。またリソース予約受付判断手段（１９０１）は図２７のリソース受付判断手段（１６０４）と動作が異なる。
【０１６９】
リソース予約受付判断手段（１９０１）は、移動局（１１１）からリソース予約を受信すると、リソース管理データベース（４１３）、およびリソース要求受付通知管理データベース（１９０２）を参照して要求を受け入れるかどうかを決定し、決定内容を要求元の移動局に送信する。そしてもし要求を受け入れた場合は、受け入れた内容をリソース管理データベース（４１３）に書き込み、また受け入れたことを他のアクセスポイントに通知するため、リソース要求受付通知パケット送信手段（１９０３）へ通知パケットの送信を依頼する。リソース要求受付通知管理データベース（１９０２）は他のアクセスポイントから受信した通知パケットを一時的に保存するためのデータベースである。
【０１７０】
リソース要求受付通知パケット送信手段（１９０３）は、リソース予約受付判断手段（１９０１）から通知パケットの送信を依頼されると、通知パケットを作成し他のアクセスポイントに対して送信する手段である。
【０１７１】
リソース要求受付通知パケット受信手段（１９０４）は、他のアクセスポイントから通知パケットを受信すると、その内容をリソース要求受付通知管理データベース（１９０２）に書き込む。
【０１７２】
時刻取得手段（１９０５）は正確な時刻を取得するための手段である。
【０１７３】
図３７はリソース予約受付判断手段（１９０１）の動作を示すフローチャートである。図２８と比較し、ステップ４１２が削除され、ステップ４１１とステップ８１３の間にステップ１６０１，ステップ１６０２，ステップ１６０３が追加され、さらにステップ４２０の後にステップ１００２が削除され代わりにステップ１６０４が追加されている。
【０１７４】
ステップ４１１においてリソース管理テーブルの処理行のリソース使用状態が“予約中”である場合、予約中のリソースが使用される期待値を算出するため、ａｄｄｒ＿ｆｏｒ＿ｃｏｕｎｔに現在の処理行の要求者アドレスを格納する（ステップ１６０１）。
【０１７５】
図３８はステップ１６０２であるリソース要求受付管理データベース指定ＡＰ数取得処理の動作を示すフローチャートである。結果を格納する変数ｒｅｓｕｌｔを０に初期化する（ステップ１７０１）。次にリソース要求受付通知テーブルの各行をチェックするために、処理行を表す変数ｉに１をセットする（ステップ１７０２）。リソース要求受付通知管理データベース（１９０２）には、例えば図３９で示されるようなリソース要求受付通知テーブルが格納されている。このテーブルは、通知フレームの送信者、通知フレームの送信者が受信したリソース予約を発行した移動局のアドレス、およびそのアクセスポイントにおけるそのリソースの有効期限が記録されるテーブルである。次にリソース要求受付通知テーブルのｉ行目の移動局のアドレスが変数ａｄｄｒ＿ｆｏｒ＿ｃｏｕｎｔと一致するかどうか調べる（ステップ１７０３）。もし一致しない場合は処理をステップ１７０６へ飛ばす。一致する場合はｉ行目のリソースがまだ有効かどうかを時刻取得手段（１９０５）から取得した時刻を用いて調べる（ステップ１７０４）。もし期限が切れて有効でない場合は処理をステップ１７０６へ飛ばす。一方そのリソースがまだ有効である場合は結果を格納する変数ｒｅｓｕｌｔに１を加える（ステップ１７０５）。次にｉ行目がリソース要求受付通知テーブルの最終行かどうかを調べる（ステップ１７０６）。もし最終行でない場合は、ｉに１を加え（ステップ１７０７）、処理をステップ１７０３へ戻す。一方最終行である場合は、予約実施アクセスポイント数を調べる処理は終わりとなり、本処理の呼び出し元へ戻る。
【０１７６】
予約実施アクセスポイント数が判明すると、その結果を用いて現在の処理行の予約されたリソースが実際に使用される確率ｐｒｏｂａｂｉｌｉｔｙを求めるため、１をｒｅｓｕｌｔで割った値をｐｒｏｂａｂｉｌｉｔｙに格納する（ステップ１６０３）。ここで求めた結果を用いて、使用されるリソース量の期待値を算出する（ステップ４１３）。
【０１７７】
また、ステップ１６０４では現在使用されているリソース量と予約中のリソースが実際に執行されるリソース量の期待値と移動局が要求してきたリソース量の合計が、アクセスポイントの持つ合計リソース量よりも少ない場合（ステップ４１７）、要求元にリソースを確保できたことを通知する旨のＭＬＭＥ−ＲＥＳＯＵＲＣＥ＿ＲＥＱＵＥＳＴ．ｒｅｓｐｏｎｓｅプリミティブをＩＥＥＥ  ８０２．１１  ＭＬＭＥに対して発行する（ステップ４１９）。リソース管理テーブルに受信したＭＬＭＥ−ＲＥＳＯＵＲＣＥ＿ＲＥＱＵＥＳＴ．ｒｅｑｕｅｓｔプリミティブに関する要求者、Ｍｅａｎ  Ｄａｔａ  Ｒａｔｅ、予約実施アクセスポイント数、および予約期限をセットし、状態として“予約中”をセットされた行を追加する（ステップ４２０）。次に、リソース要求受付通知パケット送信手段に要求元の移動局のＭＡＣアドレスと確保したリソースの有効期限を渡して通知フレームの送信を依頼する（ステップ１６０４）。以上の処理が終わると処理を再びステップ４０１へ戻す。
【０１７８】
図４０はリソース要求受付通知パケット送信手段（１９０３）の動作を示すフローチャートである。リソース予約受付判断手段から通知パケットの送信依頼を受信したかどうかを調べる（ステップ１８０１）。もし受信していない場合は処理をステップ１８０１に戻す。一方受信した場合は、通知パケットを作成する（ステップ１８０２）。その後、作成した通知パケットをＴＣＰ／ＩＰ部に渡して送信する（ステップ１８０３）。
【０１７９】
図４１はリソース要求受付通知パケット送信手段（１９０３）から通知される通知パケットの一例を示すものである。送信者ＭＡＣアドレス（２００１）には、このフレームを送信するアクセスポイント、つまり自身のＭＡＣアドレスをセットする。リソース要求者ＭＡＣアドレス（２００２）にはリソース予約受付判断手段（１９０１）から受け取った移動局のＭＡＣアドレスをセットする。予約有効期限（２００３）も同様、リソース予約受付判断手段（１９０１）から受け取ったリソースの要求期限をセットする。通知パケットの作成が完了すると、作成したパケットをＴＣＰ／ＩＰ部に渡して送信する（ステップ２８０３）。これが終了すると再び処理をステップ２８０１へ戻す。
【０１８０】
図４２はリソース要求受付通知パケット受信手段（１９０４）の動作を示すフローチャートである。ＴＣＰ／ＩＰ部から通知フレームを受信したかどうかを調べる（ステップ１９０１）。次に受信した通知パケットの内容を、リソース要求受付通知管理データベースに書き込む（ステップ１９０２）。ステップ１９０２の処理が終了すると、再び処理をステップ１９０１へ戻す。
【０１８１】
なお、本実施の形態ではリソース要求受付通知テーブルからｒｅｓｕｌｔを計算する処理を行ったが、予約受付の判断を行った時点などで各移動局に対するｒｅｓｕｌｔの値をリソース管理テーブルの予約実施アクセスポイント数に記載し、他の予約受付の判断時にはそれを呼び出して用いるという処理を行ってもよい。
【０１８２】
このように、第６及び第７の実施の形態では移動局からのリソース要求を受け付けたアクセスポイントは調査パケットに対して応答を返す必要があるのに対し、本実施の形態ではリソース要求を受け付けた段階で通知パケットを送信するため、アクセスポイント間で交換されるパケット数を削減できる。
（第９の実施の形態）
【０１８３】
本実施の形態では予約を行う通信装置から予約されたリソースを割り当てることができないと判断したときに予約を受けつける通信装置は予約を行う通信装置に対してリソースを割り当てることができない可能性があることを示すフレームを送信することを特徴としている。
【０１８４】
以下、予約を受けつける通信装置をアクセスポイント、予約を行う通信装置を移動局とし、アクセスポイントと移動局からなる無線ＬＡＮシステムを一例として、説明する。
【０１８５】
本実施の形態は、利用予想以上にアクセスポイントのリソースが使用されてしまい、現在予約中の移動局に対して予約どおり割り当てられる可能性が低くなった場合、リソース予約元の移動局にリソースが既に一杯であることを通知することにより、その移動局がこのアクセスポイントにハンドオーバをしないように工夫している。
【０１８６】
図４３は移動局（１１１）の構造を示すブロック図である。本図は基本的に第１の実施の形態において移動局の構造を表した図３と基本的に同じであるが、新たにリソースＦｕｌｌ受信手段（２１０１）、アクションフレーム受信手段（２１０４）、アクションフレーム通知手段（２１０５）が追加されている。リソースＦｕｌｌ受信手段（２１０１）は、アクセスポイントからリソースＦｕｌｌを示すアクションフレームを受信すると、調査結果格納手段（３１１）に記録されているリソース予約状態を修正する。またＭＡＣ部（２１０３）は図３のＭＡＣ部（３０３）に図４５で示すアクションフレームを受信するアクションフレーム受信手段（２１０４）が新たに追加されたものである。またＭＬＭＥ部（２１０２）は、アクションフレーム通知手段（２１０５）が新たに追加されたものである。アクションフレーム通知手段（２１０５）は図４５で示すアクションフレームを受信すると、リソースＦｕｌｌ受信手段（２１０１）に対してＭＬＭＥ−ＲＥＳＯＵＲＣＥ＿ＦＵＬＬ．ｉｎｄｉｃａｔｉｏｎプリミティブをそのアクションフレームの送信元をパラメータとして通知する
図４４はアクセスポイント（１０１〜１０７）の構造を示すブロック図である。本図も基本的に第１の実施の形態においてアクセスポイントの構造を表した図４と基本的に同じであるが、リソースＦｕｌｌ通知手段（２２０１）、プリミティブ受付手段（２２０４）、アクションフレーム生成手段（２２０５）が追加され、ＩＥＥＥ８０２．１１  ＭＬＭＥ部（２２０２）、ＩＥＥＥ８０２．１１  ＭＡＣ部（２２０３）、リソース管理処理手段（２２０６）の動作が異なる。リソース管理処理手段（４１２）は、アクセスポイントのリソース予測が外れ、例えば予約中のリソース量の期待値の総和が残りのリソース量のN倍（Nは正の数）を上回った場合、リソースＦｕｌｌのメッセージを送信するようにリソースＦｕｌｌ通知手段（２２０１）へ依頼する。リソースＦｕｌｌ通知手段（２２０１）はＩＥＥＥ８０２．１１  ＭＬＭＥ部（２２０２）に対しパラメータとして宛先の移動局のアドレスを持ったＭＬＭＥ−ＲＥＳＯＵＲＣＥ＿ＦＵＬＬ．ｒｅｑｕｅｓｔプリミティブを送信する。ＩＥＥＥ８０２．１１  ＭＬＭＥ部（２２０２）に含まれるプリミティブ受付手段（２２０４）はＭＬＭＥ−ＲＥＳＯＵＲＣＥ＿ＦＵＬＬ．ｒｅｑｕｅｓｔプリミティブ受付けるとＩＥＥＥ  ８０２．１１  ＭＡＣ部（２２０３）に対してアクションフレームを生成するよう依頼する。ＩＥＥＥ  ８０２．１１  ＭＡＣ部（２２０３）に含まれるアクションフレーム生成手段（２２０５）はアクションフレームを生成し、移動局に送信するようＩＥＥＥ  ８０２．１１  ＰＨＹ部（４０５）へ送る。
【０１８７】
図４５は後述する図４７のステップ２１１０の条件を満たしたときにＩＥＥＥ  ８０２．１１  ＭＡＣ部（２２０３）からリソース予約元の移動局に対して通知するアクションフレームの構成の一例を示すものである。Ｆｒａｍｅ  Ｃｏｎｔｒｏｌフィールド（２３０１）にはフレームのタイプやサブタイプなどが格納された領域であり、この場合はＴｙｐｅとして“Ｍａｎａｇｅｍｅｎｔ”が、Ｓｕｂｔｙｐｅとして“Ａｃｔｉｏｎ”がセットされたものである。Ｄｕｒａｔｉｏｎフィールド（２３０２）は他の移動局の送信を抑制するためのＮＡＶ（Ｎｅｔｗｏｒｋ  Ａｌｌｏｃａｔｉｏｎ  Ｖｅｃｔｏｒ）値が格納される。ＤＡ（２３０３）はあて先アドレスが格納される。ＳＡ（２３０４）は送信者のアドレスが格納される。ＢＳＳＩＤ（２３０５）はアクセスポイントのＭＡＣアドレスと同じ値であるＢＳＳＩＤが格納される。Ｓｅｑｕｅｎｃｅ  Ｃｏｎｔｒｏｌフィールド（２３０６）にはＦｒａｇｍｅｎｔ  ＮｕｍｂｅｒとＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒが格納される。Ｃａｔｅｇｏｒｙ（２３０７）にはアクションフレームのカテゴリ番号が格納され、一例として“Ｆａｓｔ  ＢＳＳ  Ｔｒａｎｓｉｔｉｏｎ”を表す値６を格納する。次にＡｃｔｉｏｎフィールド（２３０８）には、リソースが一杯であることを示すものとして割り当てられたＩＤを格納する。このＩＤの一例として５という値を用いる。ＦＣＳ（Ｆｒａｍｅ  Ｃｈｅｃｋ  Ｓｅｑｕｅｎｃｅ、２３０９）には、誤り検出符号が格納される。
【０１８８】
図４６はリソースＦｕｌｌ受信手段（２１０１）の動作を示すフローチャートである。
ＭＬＭＥ部（２１０２）からＭＬＭＥ−ＲＥＳＯＵＲＣＥ＿ＦＵＬＬ．ｉｎｄｉｃａｔｉｏｎが受信されたかどうか調べる（ステップ２００１）。もし受信されていない場合は再び処理をステップ２００１へ戻す。もし受信した場合は、変数ａｄｄｒにＭＬＭＥ−ＲＥＳＯＵＲＣＥ＿ＦＵＬＬ．ｉｎｄｉｃａｔｉｏｎのパラメータとして送られてきたアクセスポイントのアドレスを代入する（ステップ２００２）。次にハンドオーバ先テーブルを処理する行を示す変数ｉに１を代入し初期化する（ステップ２００３）。次にハンドオーバ先テーブルのｉ行目のＡＰアドレスが変数ａｄｄｒの値と同じかどうか調べる（ステップ２００４）。もし同じであった場合は、ハンドオーバ先テーブルのｉ行目のリソース予約状態を“予約しない”にセットする（ステップ２００５）。この状態を“予約しない”にセットすると、この後のこのアクセスポイントに対する動作はリソースを予約しなかった場合と同じ動作となる。そして処理をステップ２００１に戻しＭＬＭＥ−ＲＥＳＯＵＲＣＥ＿ＦＵＬＬ．ｉｎｄｉｃａｔｉｏｎプリミティブの受信待機状態に戻る。一方、前述の３７０４の処理において同じでなかった場合、次にハンドオーバ先テーブルのｉ行目が最終行かどうかを調べる（ステップ２００６）。もし最終行の場合は処理をステップ２００１へ戻す。もし最終行でない場合は変数ｉに１を加え（ステップ２００７）再び処理をステップ２００４に戻す。
【０１８９】
図４７はリソース管理処理手段（３５０１）の動作を示すフローチャートである。ＩＥＥＥ  ８０２．１１  ＭＬＭＥ部（４０９）からＭＬＭＥ−ＲＥＡＳＳＯＣＩＡＴＥ．ｉｎｄｉｃａｔｉｏｎを受信したかどうかチェックする（ステップ２１０１）。もし受信していない場合は再び処理をステップ２１０１へ戻し受信を待機する。もし受信した場合、変数ａｄｄｒにＭＬＭＥ−ＲＥＡＳＳＯＣＩＡＴＥのパラメータＰｅｅｒＳＴＡＡｄｄｒｅｓｓを代入する（ステップ２１０２）。次にリソース管理テーブルの処理する行を示す変数ｉを１に初期化する（ステップ２１０３）。次にリソース管理テーブルのｉ行目のリソース要求者のアドレスがａｄｄｒと同じかどうか調べる（ステップ２１０４）。もし異なる場合は、本テーブルのｉ行目が最後の行かどうか調べる（ステップ２１０５）。最後の行である場合は処理をステップ２１０１へ戻す。最後の行でない場合は、変数ｉに１を加え（ステップ２１０６）処理をステップ２１０４に戻す。一方前述のステップ２１０４においてリソース要求者のアドレスがａｄｄｒと同じであった場合、リソース管理テーブルのｉ行目の状態を“使用中”に変更する（ステップ２１０７）。
【０１９０】
その後変数ｕｓｅｄに現在使用中のリソース量の合計を代入する（ステップ２１０８）。次に変数ｒｅｓｅｒｖｅｄに現在予約中のリソース量の期待値の合計を代入する（ステップ２１０９）。次に現在アクセスポイントに予約されているリソース量の期待値の合計が現在のアクセスポイントのリソースの残量のN倍を上回るかどうか調べる（ステップ２１１０）。もし上回らなかった場合は処理をステップ２１０８へ戻し、処理開始のトリガ待機状態に移る。もし上回った場合は、リソース管理テーブルの処理する行を示す変数ｉに１を代入し初期化する（ステップ２１１１）。次にリソース管理テーブルのｉ行目のリソース状態が“予約中”かどうか調べる（ステップ２１１２）。もし予約中である場合は処理をステップ２１１４へ飛ばす。そうでない場合は、リソース管理テーブルのｉ行目の要求者アドレスをパラメータとして、ＩＥＥＥ  ８０２．１１  ＭＬＭＥへＭＬＭＥ−ＲＥＳＯＵＲＣＥ＿ＦＵＬＬ．ｒｅｑｕｅｓｔプリミティブを発行するようリソースＦｕｌｌ通知手段（２２０１）へ依頼する（ステップ２１１３）。次にｉ行目はリソース管理テーブルの最終行かどうか調べる（ステップ２１１４）。もし最終行であれば、処理をステップ２１０８へ戻し、処理開始のトリガ待機状態に移る。そうでない場合は変数ｉに１を加え、処理をステップ２１１２へ戻す。
【０１９１】
このように本実施の形態では、移動局による予約されたリソースがアクセスポイントの予想以上に実際に使用されてしまった結果、リソースが足りなくなってしまい、現在予約されている移動局に対してリソースが割り当てられる可能性が低くなったときに、リソースが一杯になったことを示すアクションフレームを送信することで、移動局が自身にハンドオーバすることを抑制させ、ハンドオーバの失敗が発生するのを避けることができるという効果がある。
【０１９２】
本実施の形態では移動局やアクセスポイントの構造として第１の実施の形態をもとに説明をしているが、第５の実施の形態など別の実施の形態の構造であっても構わない。
【０１９３】
なお、本実施の形態では予約中のリソース量の期待値の合計がアクセスポイントの残りのリソース量の倍を上回った場合にリソースが一杯であることを表すフレームを送信したが、本フレームを発生させるタイミングはこれに限ったものではない。例えば、１００％の確率で予約されたリソースが確保できないと判った段階で発行しても構わないし、基準となるリソースはアクセスポイントの残りのリソース量ではなくアクセスポイントの全リソース量のN％（Nは正の数）などでも構わない。
【０１９４】
また、本実施の形態ではリソースＦｕｌｌのメッセージを送信する対象として予約している移動局としているが、予め移動局数を決めておき予約期限が最も迫っているもの、もしくは予約期限が最も遅いものから前記移動局数選択し、該当する移動局に対してリソースＦｕｌｌのメッセージを送信するという形態でもよい。
【０１９５】
上述した本発明のアクセスポイント及び移動局は、上記説明からも明らかなように、ハードウェアで構成することも可能であるが、コンピュータプログラムにより実現することも可能である。この場合、プログラムメモリに格納されているプログラムで動作するプロセッサ（情報処理装置）によって、上述した実施の形態と同様の機能、動作を実現させる。尚、上述した実施の形態の一部の機能のみをコンピュータプログラムにより実現することも可能である。
【産業上の利用可能性】
【０１９６】
本発明の活用例として、無線ＬＡＮのアクセスポイント、携帯電話の基地局などの無線通信装置の基地局が挙げられる。
【図面の簡単な説明】
【０１９７】
【図１】無線ＬＡＮシステムの構成を示す図である。
【図２】ＩＥＥＥ  ８０２．１１ｒ規格（Ｄｒａｆｔ  ７．０）で規定されているハンドオーバ時のシーケンス図である。
【図３】第１の実施の形態における移動局（１１１）の構造を示すブロック図である。
【図４】第１の実施の形態におけるアクセスポイント（１０１〜１０７）の構造を示すブロック図である。
【図５】第１の実施の形態におけるリソース管理データベース（４１３）内に格納されるリソース管理テーブルの一例である。
【図６】第１の実施の形態における移動局（１１１）内にあるハンドオーバ先候補調査手段（３１０）の動作例を示すフローチャートである。
【図７】第1の実施の形態における移動局（１１１）の調査結果格納手段（３１１）内にあるハンドオーバ先候補情報テーブルのリソース予約状態の変更に関する処理を示すフローチャートである。
【図８】第１の実施の形態におけるリソース予約処理手段（３１３）の動作を示すフローチャートである。
【図９】第１の実施の形態におけるハンドオーバ先候補情報テーブルの一例を示す図である。
【図１０】第１の実施の形態におけるＯｖｅｒ−ｔｈｅ−Ａｉｒ方式を用いた場合とＯｖｅｒ−ｔｈｅ−ＤＳ方式を用いた場合のＡｕｔｈｅｎｔｉｃａｔｉｏｎフレーム交換部分のシーケンス図である。
【図１１】第１の実施の形態におけるＲＩＣ  Ｒｅｑｕｅｓｔフレームの一例である。
【図１２】第１の実施の形態におけるＡｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｃｏｎｆｉｒｍフレームの一例である。
【図１３】第１の実施の形態におけるリソース予約受付判断手段（４１１）の動作を示すフローチャートである。
【図１４】第２の実施の形態におけるリソース予約処理手段（３１３）の動作を示すフローチャートである。
【図１５】第２の実施の形態におけるＡｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｃｏｎｆｉｒｍフレームの一例である。
【図１６】第２の実施の形態におけるアクセスポイント（１０１〜１０７）の構造の一例を示すブロック図である。
【図１７】第３の実施の形態におけるリソース予約処理手段（３１１）の動作を示すフローチャートである。
【図１８】第４の実施の形態における無線LANシステムの構成を示す図である。
【図１９】第４の実施の形態における移動局（１００１〜１００４）の構造を示すブロック図である。
【図２０】第５の実施の形態における移動局（１１１）の構造を示すブロック図である。
【図２１】第５の実施の形態におけるアクセスポイント（１０１〜１０７）の構造を示すブロック図である。
【図２２】第５の実施の形態における移動局（１１１）内のリソース予約処理手段（１２０３）の動作を示すフローチャートである。
【図２３】第５の実施の形態における移動局（１１１）内の予約実施アクセスポイント数通知手段（１２０４）の動作を示すフローチャートである。
【図２４】第５の実施の形態におけるＴＣＰ／ＩＰ部（３０２）がリソース要求先のアクセスポイントへ送信するデータのフォーマットの一例を示すものである
【図２５】第５の実施の形態におけるアクセスポイント（１０１〜１０７）内の予約実施アクセスポイント数受付手段（１３０２）の動作の示すフローチャートである。
【図２６】第５の実施の形態におけるフレーム交換のシーケンス図である。
【図２７】第６の実施の形態におけるアクセスポイント（１０１〜１０７）の構造を示すブロック図である。
【図２８】第６の実施の形態におけるアクセスポイント（１０１〜１０７）内のリソース予約受付手段（１６０４）の動作を示すフローチャートである。
【図２９】第６の実施の形態におけるアクセスポイント（１０１〜１０７）内の予約実施アクセスポイント数調査手段（１６０３）の動作を示すフローチャートである。
【図３０】第６の実施の形態におけるアクセスポイント（１０１〜１０７）内の予約実施アクセスポイント数調査スレッド（１６０５）の動作を示すフローチャートである。
【図３１】第６の実施の形態におけるアクセスポイント（１０１〜１０７）内の予約実施アクセスポイント数調査パケット送受信手段（１６０２）の動作を示すフローチャートである。
【図３２】第６の実施の形態におけるアクセスポイント（１０１〜１０７）内の予約実施アクセスポイント数調査パケット送受信手段（１６０２）が送信を行う調査パケットのフォーマットの一例を示す図である。
【図３３】第６の実施の形態における調査パケットに対する応答パケットのフォーマットの一例を示す図である。
【図３４】第６の実施の形態におけるアクセスポイント（１０１〜１０７）内の予約実施アクセスポイント数調査依頼応答手段（１６０１）の動作を示すフローチャートである。
【図３５】第７の実施の形態におけるアクセスポイント（１０１〜１０７）内のリソース予約処理手段（４１１）の動作を示すフローチャートである。
【図３６】第８の実施の形態におけるアクセスポイント（１０１〜１０７）の構造を示すブロック図である。
【図３７】第８の実施の形態におけるアクセスポイント（１０１〜１０７）内のリソース予約受付判断手段（１９０１）の動作を示すフローチャートである。
【図３８】第８の実施の形態におけるアクセスポイント（１０１〜１０７）内のリソース要求受付管理データベース指定ＡＰ数取得処理（ステップ１６０２）の動作を示すフローチャートである。
【図３９】第８の実施の形態におけるリソース要求受付通知管理データベース（１９０２）内に格納されるリソース要求受付通知テーブルの一例である。
【図４０】第８の実施の形態におけるアクセスポイント（１０１〜１０７）内のリソース要求受付通知パケット送信手段（１９０３）の動作を示すフローチャートである。
【図４１】第８の実施の形態におけるアクセスポイント（１０１〜１０７）内の要求受付通知パケット送信手段（２５０３）から通知される通知パケットの一例を示すものである。
【図４２】第８の実施の形態におけるアクセスポイント（１０１〜１０７）内のリソース要求受付通知パケット受信手段（１９０４）の動作を示すフローチャートである。
【図４３】第９の実施の形態における移動局（１１１）の構造を示すブロック図である。
【図４４】第９の実施の形態におけるアクセスポイント（１０１〜１０７）の構造を示すブロック図である。
【図４５】第９の実施の形態におけるアクセスポイント（１０１〜１０７）内のＩＥＥＥ  ８０２．１１  ＭＡＣ部（２２０３）から送信されるアクションフレームの構成の一例を示すものである。
【図４６】第９の実施の形態における移動局（１１１）内のリソースＦｕｌｌ受信手段（２１０１）の動作を示すフローチャートである。
【図４７】第９の実施の形態におけるアクセスポイント（１０１〜１０７）内のリソース管理処理手段（３５０１）の動作を示すフローチャートである。
【符号の説明】
【０１９８】
１０１〜１０７  アクセスポイント
１１１  移動局
１２１  ネットワーク
１３１  認証サーバ
１４１  モビリティドメイン
１５１  外部ネットワーク
【図１】
2009088718.tif 000003
【図２】
2009088718.tif 000004
【図３】
2009088718.tif 000005
【図４】
2009088718.tif 000006
【図５】
2009088718.tif 000007
【図６】
2009088718.tif 000008
【図７】
2009088718.tif 000009
【図８】
2009088718.tif 000010
【図９】
2009088718.tif 000011
【図１０】
2009088718.tif 000012
【図１１】
2009088718.tif 000013
【図１２】
2009088718.tif 000014
【図１３】
2009088718.tif 000015
【図１４】
2009088718.tif 000016
【図１５】
2009088718.tif 000017
【図１６】
2009088718.tif 000018
【図１７】
2009088718.tif 000019
【図１８】
2009088718.tif 000020
【図１９】
2009088718.tif 000021
【図２０】
2009088718.tif 000022
【図２１】
2009088718.tif 000023
【図２２】
2009088718.tif 000024
【図２３】
2009088718.tif 000025
【図２４】
2009088718.tif 000026
【図２５】
2009088718.tif 000027
【図２６】
2009088718.tif 000028
【図２７】
2009088718.tif 000029
【図２８】
2009088718.tif 000030
【図２９】
2009088718.tif 000031
【図３０】
2009088718.tif 000032
【図３１】
2009088718.tif 000033
【図３２】
2009088718.tif 000034
【図３３】
2009088718.tif 000035
【図３４】
2009088718.tif 000036
【図３５】
2009088718.tif 000037
【図３６】
2009088718.tif 000038
【図３７】
2009088718.tif 000039
【図３８】
2009088718.tif 000040
【図３９】
2009088718.tif 000041
【図４０】
2009088718.tif 000042
【図４１】
2009088718.tif 000043
【図４２】
2009088718.tif 000044
【図４３】
2009088718.tif 000045
【図４４】
2009088718.tif 000046
【図４５】
2009088718.tif 000047
【図４６】
2009088718.tif 000048
【図４７】
2009088718.tif 000049