JP2009130751A - リソース予約装置、システム、方法 - Google Patents

Abstract

【課題】ハンドオーバ前にリソースを予約できるアクセスポイントにおいて、移動局が予約したリソースをどれほどの確率で実際に使用しているか判らないため、正確なリソースの消費予測が立てられない。よってアクセスポイントは移動局からのリソース要求に対して適切な応答ができず、移動局はアクセスポイントの持つリソースを効率的に使用することができなかった。

【解決手段】アクセスポイントは移動局のそのアクセスポイントにおいるリソース予約状況とリソース使用状況とからリソース使用確率を計算する。アクセスポイントはその計算結果に基づいて移動局のリソース要求の受入を判断することにより、リソースの効率的な使用をすることができる。

【選択図】図３

Description

本発明は、通信リソースの予約を行う装置、システム等に関する。

従来、無線ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）では移動局が現在使用しているアクセスポイントから別のアクセスポイントへハンドオーバを行う前に、ハンドオーバ先のアクセスポイントに対して事前にリソースを予約することができなかった。ここで、リソースとは、例えば通信速度に応じて使用される電力、メモリの量、周波数帯域または通信速度そのものなどを指す。そのため、ハンドオーバが発生したときに、ハンドオーバ先のアクセスポイントで通信の継続に必要なリソースが確保できない場合は、ハンドオーバに失敗してしまう。

しかしＩＥＥＥ（Ｔｈｅ Ｉｎｓｔｉｔｕｔｅ ｏｆ Ｅｌｅｃｔｒｉｃａｌ ａｎｄ Ｅｌｅｃｔｒｏｎｉｃｓ Ｅｎｇｉｎｅｅｒｓ） ８０２．１１ｒ規格によって無線ＬＡＮにおいてもハンドオーバ前に事前にアクセスポイントに対して通信リソースを予約することが可能になった。これにより、ハンドオーバを失敗する確率を減らすことができる。

ＩＥＥＥ ８０２．１１ｒ規格（Ｄｒａｆｔ ７．０）で規定されているハンドオーバについて、図1と図２を用いて説明する。

図１は、無線ＬＡＮシステムの構成を示す図である。図１の無線ＬＡＮシステムは、移動局（１１１）、移動局（１１１）が無線通信によりアクセスする複数のアクセスポイント（１０１〜１０７）と、移動局（１１１）がモビリティドメインのネットワークにアクセスすることが許された移動局であることの認証をする認証サーバ（１３１）から構成されており、アクセスポイント（１０１〜１０７）と認証サーバ（１３１）は有線ネットワークにより接続されている。

図２は、ＩＥＥＥ ８０２．１１ｒ規格（Ｄｒａｆｔ ７．０）で規定されているハンドオーバ時のシーケンスを示すシーケンス図である。移動局（１１１）は図１のようにアクセスポイント（１０３）の配下に居て、アクセスポイント（１０３）と通信中であり、アクセスポイント（１０４）の方向に向かっているとする。このとき、移動局（１１１）はアクセスポイント１０４に対して事前にリソースを予約するために、最初に８０２．１１ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔ（２０１）を送信する。するとアクセスポイント１０４は移動局（１１１）に対して８０２．１１ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｒｅｓｐｏｎｓｅを返信する（２０２）。本フレームを受信すると移動局（１１１）はＭｅａｎ Ｄａｔａ Ｒａｔｅや、Ｍｉｎｉｍｕｍ Ｄａｔａ Ｒａｔｅ，Ｐｅａｋ Ｄａｔａ Ｒａｔｅなどの要求リソース量等の情報を含む８０２．１１ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｎｆｉｒｍフレームを送信する（２０３）。それに対してアクセスポイント１０４はそのリソース予約を受け付けるか受け付けないかの返答を載せた８０２．１１ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ＡＣＫフレームを返信する（２０４）。

移動局が要求したリソースが受け入れられた場合は事前予約に関するフレーム交換はこれで終わりだが、受け入れられなかった場合は、移動局は予約したいリソース量を変更して再度のリソース予約をアクセスポイント（１０４）に対して提示することも可能である。この後、初めてこの移動局（１１１）がモビリティドメイン（１４１）に入った際にあるアクセスポイントとの間で行われるＦａｓｔ ＢＳＳ Ｔｒａｎｓｉｔｉｏｎ Ｉｎｉｔｉａｌ Ｍｏｂｉｌｉｔｙ Ｄｏｍａｉｎ Ａｓｓｏｃｉａｔｉｏｎ時にそのアクセスポイントから通知されたＡｕｔｈｅｎｔｉｃａｔｉｏｎ ＡＣＫフレーム内で示される期限Ｒｅａｓｓｏｃｉａｔｉｏｎ ＤｅａｄｌｉｎｅまでにＲｅａｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔ（２０５）を発行すれば、８０２．１１ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｎｆｉｒｍフレーム（２０３）で予約したリソースが有効となり、そのリソースを用いてアクセスポイント１０４との通信が可能となる（例えば、非特許文献１参照）。Ｒｅａｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔ（２０５）に対してアクセスポイント１０４はＲｅａｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅ（２０６）を送信する。

特許文献１には、ハンドオーバ時に移動局固有の優先度に基づいて決定される数の予約基地局数の基地局に対して、移動局が、直接又は他の基地局を介して予約を行う技術が開示されている。直接移動局が基地局に対して予約を行う場合は、移動局が基地局数分の基地局に個別に予約情報を送信する。他の基地局を介する場合には移動局は予約基地局数を含めた予約情報を現在通信中の基地局に送信し、さらにその予約情報を受信した基地局が、予約基地局数分の近隣基地局を選択して、予約情報を転送する。このようにして予約を移動局から直接、または他の基地局を介して受信した各基地局は、移動局から要求されているリソース量と自局の空きリソース量を比較し、空きリソース量が要求されているリソース量以上ならば予約の受け入れを行い、空きリソース量が要求されているリソース量未満ならばリソース予約の受け入れの拒否を行う。

特願２００４−２６６７１３号公報（第４−９頁） ＩＥＥＥ ８０２．１１ｒ規格、Ｄｒａｆｔ ７．０、２００７年７月、１１Ａ６節 第６１−６７頁

しかしながら特許文献１で記載した移動通信システムにおいて、基地局は移動局から要求されているリソース量と空きリソース量を比較してリソース予約の受け入れを判断している。移動局がハンドオーバするのは複数予約したうちの１つの基地局であるにも関わらず、１つの基地局の空きリソース量と要求されているリソース量との比較により、予約の受け入れを行うか否かを判断している。予約が行われたリソース量だけ他の移動局が予約または使用できるリソース量が減るため、特定の移動局が多数の基地局のリソースを予約してしまった場合には、基地局にリソースの予約を受け付けて貰うことができる移動局の数が減ってしまう、または移動局が予約を受け付けてもらえる基地局の数が減ってしまうなど、リソースの予約を効率的にできないという問題があった。
そこで、本発明は上記問題を解決することを課題とし、その目的は、効率的なリソース予約ができる通信システム、装置、およびその方法、プログラムを提供することにある。

上記課題を解決する本発明は、リソースの予約を受けつける通信装置であって、リソースの予約を行う通信装置からのリソース予約要求を受け付けるリソース予約受付判断手段を少なくとも有し、リソース予約受付判断手段は、少なくとも１つのリソースの予約を行う通信装置の自通信装置におけるリソース予約状況とリソース使用状況とから求められるリソース使用確率に基づいて、予約の受付を行うことを特徴とする。

上記課題を解決する本発明は、少なくとも１つのリソースの予約を行う通信装置と少なくとも1つのリソースの予約を受けつける通信装置を含む通信システムであって、リソースの予約を受けつける通信装置は、少なくとも１つのリソースの予約を行う通信装置の自通信装置におけるリソース予約状況とリソース使用状況とから求められるリソース使用確率に基づいて、予約の受付を行うことを特徴とする。

上記課題を解決する本発明は、予約を受けつける通信装置のリソースの予約受付を判断する方法であって、リソースの予約を行う通信装置の自通信装置におけるリソース予約状況とリソース使用状況とから求められるリソース使用確率に基づいて、予約の受付を判断することを特徴とする。

上記課題を解決する本発明は、少なくとも１つのリソースの予約を行う通信装置と少なくとも1つのリソースの予約を受けつける通信装置を含む通信システムの予約受付を判断する方法であって、リソースの予約を行う通信装置の自通信装置におけるリソース予約状況とリソース使用状況とから求められるリソース使用確率に基づいて、予約の受付を判断することを特徴とする。

上記課題を解決する本発明は、情報処理装置に処理を実行させるプログラムであって、プログラムは、情報処理装置にリソースの予約を行う通信装置の自通信装置におけるリソース予約状況とリソース使用状況とから求められるリソース使用確率に基づいて、予約を受けつける通信装置のリソースの予約の受付の処理を実行させることを特徴とする。

本発明によれば、リソースの予約を受けつける通信装置が、リソースの予約を行う通信装置のリソース使用確率に基づいて予約の受付を行うことにより、効率的なリソース予約が可能となる。

（第１の実施の形態）
本実施の形態ではリソースの予約を受けつける通信装置は、リソース使用確率に基づいて、予約の受付を行う。

以下、予約を受けつける通信装置をアクセスポイント、予約を行う通信装置を移動局とし、アクセスポイントと移動局からなる無線ＬＡＮシステムを一例として、説明する。

リソース使用確率とはリソースの予約を行う通信装置が移動局ごとにその移動局のリソース予約状況とリソース使用状況とから求められるものであるが、ここでは一例として予約期限前に移動局がリソースを使用した回数をその移動局がリソースの予約を行った回数で除算することにより求められるものとする。

図１は、本発明の一実施の形態としてのネットワークの構成を示す図である。図1で示されるネットワークは、アクセスポイント（１０１〜１０７）、移動局（１１１）、ネットワーク（１２１）、認証サーバ（１３１）、外部ネットワーク（１５１）から構成される。
アクセスポイント（１０１〜１０７）は、リソース管理機能を提供するアクセスポイントである。以下では、ＩＥＥＥ ８０２．１１ｅ規格、および高速なハンドオーバ機能を提供するＩＥＥＥ ８０２．１１ｒ規格に準拠したアクセスポイントを例として説明する。それぞれのアクセスポイントは例えばＩＥＥＥ８０２．３で規定されているようなネットワークで互いに接続されており、また外部のネットワーク（１５１）とも接続されている。また、説明を簡単とするために、以下では、これらのアクセスポイントは同一のモビリティドメインに属すると仮定する。ここで、モビリティドメインとは、属するアクセスポイント間においてＩＥＥＥ８０２．１１ｒに準拠した高速なハンドオーバが実施可能となるようなドメインである。これらのアクセスポイントは、ＩＥＥＥ ８０２．１１ｋ規格で規定される方式に従って、自身の近隣に存在するアクセスポイントの情報を交換できる機能を持っていても良い。

移動局（１１１）は、無線通信機能及びハンドオーバ前に事前にアクセスポイントに対して通信リソースを予約する機能を備えた移動局である。以下では、ＩＥＥＥ ８０２．１１ｅ規格およびＩＥＥＥ ８０２．１１ｒに準拠した無線ＬＡＮ機能を備えた移動局を例として説明する。

認証サーバ（１３１）は例えばＲＡＤＩＵＳプロトコルなどを用いて、移動局（１１１）がアクセスポイント（１０１〜１０７）に接続する際に、移動局（１１１）がモビリティドメインのネットワークにアクセスすることが許された移動局であることを認証するためのサーバである。

外部ネットワーク（１５１）は、モビリティドメイン（１４１）に属さないネットワークである。

図３は、本発明の一実施の形態としてのアクセスポイント（１０１〜１０７）の構造を示すブロック図である。図３を参照してアクセスポイントの構成例を説明すると、アクセスポイント（１０１〜１０７）は、ＩＥＥＥ ８０２．３ ＰＨＹ部（３０１）、ＩＥＥＥ ８０２．３ ＭＡＣ部（３０２）、ＩＥＥＥ８０２．３ネットワーク（３０３）、アンテナ（３０４）、ＩＥＥＥ ８０２．１１ ＰＨＹ部（３０５）、ＩＥＥＥ ８０２．１１ ＭＡＣ部（３０６）、ブリッジ（３０７）、ＩＥＥＥ ８０２．１１ ＰＬＭＥ部（３０８）、ＩＥＥＥ ８０２．１１ ＭＬＭＥ部（３０９）、ＳＭＥ部（３１０）から構成される。

ＩＥＥＥ ８０２．３ ＰＨＹ部（３０１）は、ＩＥＥＥ ８０２．３規格で規定されるＰＨＹ機能を処理する手段である。

ＩＥＥＥ ８０２．３ ＭＡＣ部（３０２）は、ＩＥＥＥ ８０２．３規格で規定されるＭＡＣ機能を処理する手段である。

ＩＥＥＥ８０２．３ネットワーク（３０３）は、ＩＥＥＥ ８０２．３規格に準拠したネットワークである。

アンテナ（３０４）は、ＩＥＥＥ ８０２．１１ ＰＨＹ部（３０５）で変調された無線信号の送信や他の移動局（１１１）から送信された無線信号を受信するための手段である。

ＩＥＥＥ ８０２．１１ ＰＨＹ部（３０５）は、例えばＩＥＥＥ ８０２．１１ｇで規定されるものであり、ＩＥＥＥ ８０２．１１ ＭＡＣ部（３０６）から送られてくるフレームを電波信号に変調しアンテナ（３０４）を通して送信する機能、およびアンテナ（３０４）から受信した電波信号を復調し、受信フレームとしてＩＥＥＥ ８０２．１１ ＭＡＣ部（３０６）へ渡す機能を持つ。

ＩＥＥＥ ８０２．１１ ＭＡＣ部（３０６）は、ＩＥＥＥ ８０２．１１ｅ仕様で規定される機能およびＩＥＥＥ ８０２．１１ｒ仕様で規定される機能を処理する。

ブリッジ（３０７）は、ＩＥＥＥ ８０２．３ ＭＡＣ部（３０２）から送られてきた受信フレームのあて先アドレスを調べ、もしそのあて先アドレスで示されるノードが本アクセスポイントのカバーエリアに存在する移動局である場合、そのフレームをＩＥＥＥ ８０２．１１ ＭＡＣ部（３０６）へ渡す。逆にＩＥＥＥ ８０２．１１ ＭＡＣ部（３０６）から受け取った受信フレームのあて先がＩＥＥＥ８０２．３ネットワーク（３０３）内のノードであれば、そのフレームをＩＥＥＥ ８０２．３ ＭＡＣ部（３０２）へ渡す。

ＩＥＥＥ ８０２．１１ ＰＬＭＥ部（３０８）はＩＥＥＥ ８０２．１１ ＰＨＹ部（３０５）を制御するためのエンティティであり、ＩＥＥＥ ８０２．１１ｇ、ＩＥＥＥ ８０２．１１ｅ、ＩＥＥＥ ８０２．１１ｒで規定されるＭＬＭＥ＿ＰＬＭＥ＿ＳＡＰおよびＰＬＭＥ＿ＳＡＰを処理できるものである。

ＩＥＥＥ ８０２．１１ ＭＬＭＥ部（３０９）はＳＭＥ部（３１０）からの指示に従い、ＩＥＥＥ ８０２．１１ ＭＡＣ部（３０６）を制御するエンティティである。

なお、本実施の形態で用いるＩＥＥＥ ８０２．１１ ＭＬＭＥ部（３０９）は、ＩＥＥＥ ８０２．１１ｇ、ＩＥＥＥ ８０２．１１ｅ、ＩＥＥＥ ８０２．１１ｒで規定されるＭＬＭＥ＿ＳＡＰを処理する機能に加え、要求リソース量が格納されたＡｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｎｆｉｒｍフレームを受信すると、その数を他のパラメータとともにＳＭＥ部（３１０）に通知できる機能も含むものとする。

ＳＭＥ部（３１０）はＩＥＥＥ ８０２．１１ ＰＨＹ部（３０５）およびＩＥＥＥ ８０２．１１ ＭＡＣ部（３０６）を、ＩＥＥＥ ８０２．１１ ＰＬＭＥ部（３０８）およびＩＥＥＥ ８０２．１１ ＭＬＭＥ部（３０９）を通して管理するエンティティである。ＳＭＥ部（３１０）は、リソース予約受付判断手段（３１１）、リソース管理手段（３１２）、リソース管理データベース（３１３）およびリソース予約・使用履歴データベース（３１４）を含むものである。

リソース予約受付判断手段（３１１）は、移動局（１１１）からＡｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｎｆｉｒｍフレームを受信すると、ＩＥＥＥ ８０２．１１ ＭＬＭＥ部（３０９）よりそれらの情報が渡される。そして、リソース管理データベース（３１３）に記録されている現在のリソースの使用状態とリソースの予約状態、およびＩＥＥＥ ８０２．１１ ＭＬＭＥ部（３０９）より通知された要求リソース量と、予約期限前に移動局がリソースを使用した回数を移動局がリソースの予約を行った回数で除算することによりリソース使用確率を計算する。そして、そのリソース使用確率に基づいてリソース要求を受け入れるかどうか判断する。そのリソース要求を受け入れる場合、リソース確保成功をＩＥＥＥ ８０２．１１ ＭＬＭＥ部（３０９）に対して通知する。それと同時に、リソース管理データベース（３１３）に、要求元移動局のＭＡＣアドレス、８０２．１１ ＡＵＴＨＥＮＴＩＣＡＴＩＯＮ ＣＯＮＦＩＲＭフレーム（２０３）に含まれるＭｅａｎ Ｄａｔａ Ｒａｔｅが示す要求リソース量、そのリソース予約の期限をセットする。そしてまたリソース使用状態に “予約中”という状態をセットする。なお、セットする要求リソースはＭｅａｎ Ｄａｔａ Ｒａｔｅに限らずＭｉｎｉｍｕｍ Ｄａｔａ ＲａｔｅやＭａｘｉｍｕｍ Ｄａｔａ Ｒａｔｅ等でもよい。反対にそのリソース要求を受け入れない場合、リソース確保失敗をＩＥＥＥ ８０２．１１ ＭＬＭＥ部（３０９）に対して発行する。

リソース管理手段（３１２）は、ＩＥＥＥ ８０２．１１ ＭＬＭＥ部（３０９）よりリソースの使用が通知されると、そのプリミティブのパラメータに含まれている送信元のアドレスを調べ、その移動局の予約中のリソースが無いかどうかリソース管理データベース（３１３）を用いて調べる。もし送信元の移動局が予約しているリソースが存在し予約の期限が切れていなければ、そのリソースの状態を“使用中”に変更する。

リソース管理データベース（３１３）は例えば図４に示すようなリソース管理テーブルが格納される。このテーブルには、要求者のアドレス、要求リソース量、リソースの使用状態、リソース予約の期限が記録される。要求者アドレスにはリソースの予約を行う通信装置である移動局のアドレスが記録される。リソースの使用状態には該要求者アドレスの移動局がリソースを使用中であるか、予約中であるかを示す情報が記録される。リソース予約の期限はリソースの使用状態が予約中のリソースであればその期限が記録される。

図４の１行目を例に取るとアドレスがＳＴＡ１のリソースの要求者はリソース量として６４ｋｂｐｓ、リソースの使用状態が予約中であり、リソース予約の期限は２００７年１月２７日の２２時４５分００秒までとなっている。

リソース予約・使用履歴データベース（３１４）は例えば図５に示すようなリソース予約・使用履歴テーブルが格納される。リソース予約・使用履歴テーブルには、要求者のアドレス、リソース予約回数、使用回数が記録される。リソース予約回数にはそのアクセスポイントに対して過去にリソース予約を行った回数が記録される。使用回数には移動局が過去にリソースを予約して実際にそのリソース使用して通信を行った回数が記録される。

図５の１行目を例に取るとアドレスがＳＴＡ１のリソースの要求者は１０回のリソース予約回数に対して、9回実際にそのリソース使用して通信を行ったことが示されている。

移動局が行ったリソースの予約の受入をアクセスポイントが判断する際の処理と、予約されていたリソースが実際に使われ、情報が更新される際の処理について図３及び図６から図９を用いて説明する。

図６はアクセスポイント（１０１〜１０７）内にあるリソース予約受付判断手段（３１１）の動作を示すフローチャートである。この動作は移動局が行ったリソースの予約の受入をアクセスポイントが判断するものである。ＩＥＥＥ ８０２．１１ ＭＬＭＥ（３０９）からリソースの予約要求があったかどうかを調べる（ステップ１０１）。まだ要求がない場合は再び処理をステップ１０１へ戻し、受信するまで待機する。もし要求があった場合は、変数ａｄｄｒにリソース予約を行った移動局のアドレスを示すＰｅｅｒＭＡＣＡｄｄｒｅｓｓを代入する（ステップ１０２）。次にリソース予約・使用履歴データベース確率取得処理（ステップ１０３）を行い、予約期限前に移動局がリソースを使用した回数を移動局がリソースの予約を行った回数で除算することにより計算されるリソース使用確率を得る。リソース予約・使用履歴データベース確率取得処理の詳細は後述する。

リソース使用確率と予め定められた予約受付閾値を比較し（ステップ１０４）、リソース使用確率の方が大きければリソースが確保できたことを通知し（ステップ１０５）、リソース使用確率の方が小さければリソースを確保できなかったことを通知する（ステップ１０６）。ステップ１０６の後はステップ１０１へ戻りリソースの予約要求があるまで待機する。一方、ステップ１０５の後はリソース管理テーブルに予約を受けつけたことを示す情報を追加する（ステップ１０７）。ここでリソース使用状態としては“予約中”をセットされる。そしてリソース予約・使用履歴テーブル更新処理（ステップ１０８）が実行された後はステップ１０１へ戻りリソースの予約要求があるまで待機する。リソース予約・使用履歴テーブル更新処理の詳細は後述する。

図７はリソース予約・使用履歴データベース確率取得処理の動作を示すフローチャートである。

まず初めにリソース使用確率を格納する変数ｐｒｏｂａｂｉｌｉｔｙに０を代入し初期化する（ステップ２０１）。次にリソース予約・使用履歴テーブルの処理行を格納する変数ｉに１をセットする（ステップ２０２）。その後リソース予約・使用履歴テーブルｉ行目の要求者アドレスが変数ａｄｄｒと同じかどうか調べる（ステップ２０３）。同じである場合は予約された回数の合計を格納する変数ｎｕｍ＿ｒｅｓｅｒｖｅｄにリソース予約・使用履歴テーブルｉ行目のリソース予約回数を代入する（ステップ２０４）。また予約が実際に実行された回数の合計を格納する変数ｎｕｍ＿ｉｎｖｏｋｅｄに処理行の使用回数を代入する（ステップ２０５）。次にリソース使用確率を格納する変数ｐｒｏｂａｂｉｌｉｔｙに変数ｎｕｍ＿ｉｎｖｏｋｅｄの値を変数ｎｕｍ＿ｒｅｓｅｒｖｅｄの値で除した値を格納する（ステップ２０６）。確率が計算し終わると本処理の呼び出し元に処理を復帰する。

一方、前述のステップ２０３においてリソース予約・使用履歴テーブルｉ行目の要求者アドレスが変数ａｄｄｒと同じでない場合はｉ行目がリソース予約・使用履歴テーブルの最終行かどうか調べる（ステップ２０７）。最終行である場合は本処理の呼び出し元に処理を復帰する。そうでない場合は変数ｉに１を加え（ステップ２０８）、ステップ２０３に処理を移す。

図８はリソース予約・使用履歴テーブル更新処理の動作を示すフローチャートである。この処理によりリソース予約・使用履歴テーブルのうちリソース予約回数の内容が更新される。

まず初めに、リソース予約・使用履歴テーブルで処理するテーブルの行を示す変数ｉに先頭行である１をセットする（ステップ３０１）。次にリソース予約・使用履歴テーブルのｉ行目の要求者アドレスが変数ａｄｄｒの値と同じかどうか調べる（ステップ３０２）。同じである場合はリソース予約・使用履歴テーブルのｉ行目のリソース予約回数に１を加え（ステップ３０３）、本処理の呼び出し元に処理を復帰する。

一方、リソース予約・使用履歴テーブルのｉ行目の要求者アドレスが変数ａｄｄｒの値と同じでない場合は、ｉ行目はリソース予約・使用履歴テーブルの最終行かどうか調べる（ステップ３０４）。最終行である場合は本処理の呼び出し元に処理を復帰する。最終行でない場合は、変数ｉの値に１を加え（ステップ３０５）、ステップ３０２に処理を戻す。

以上によりアクセスポイントはリソース使用確率に基づいて移動局からが行ったリソースの予約の受入を判断する。このようにリソース使用確率は予約期限前に移動局がリソースを使用した回数を移動局がリソースの予約を行った回数で除算することにより求まるが、ＩＥＥＥ８０２．１１ｒにおける規定では予約内容が上書きされることがありえる。その場合、上書きされた回数をリソースの予約を行った回数に含めてもよいし含めなくてもよい。

図９はリソース管理手段（３１２）の動作を示すフローチャートである。この処理により予約されていたリソースが実際に使われた際にリソース予約・使用履歴テーブルのうち使用約回数の内容が更新される。

まず初めに、ＩＥＥＥ ８０２．１１ ＭＬＭＥ（３０９）からリソースの使用が通知されたかをチェックする（ステップ４０１）。通知されていない場合は再び処理をステップ４０１へ戻し通知まで待機する。通知された場合、変数ａｄｄｒにリソース予約を行った移動局のアドレスを示すＰｅｅｒＳＴＡＡｄｄｒｅｓｓを代入する（ステップ４０２）。次にリソース管理テーブルの処理する行を示す変数ｉを１に初期化する（ステップ４０３）。そして、リソース管理テーブルのｉ行目のリソース要求者のアドレスがａｄｄｒと同じかどうか調べる（ステップ４０４）。同じであった場合、リソース管理テーブルのｉ行目の状態を“使用中”に変更する（ステップ４０５）。そしてリソース予約・使用履歴テーブルを更新するために、変数ｊを１に初期化し（ステップ４０６）、ステップ４０９へ進む。

一方前述のステップ４０４においてリソース要求者のアドレスがａｄｄｒと異なる場合は、リソース管理テーブルのｉ行目が最後の行かどうか調べる（ステップ４０７）。最後の行である場合はリソース管理テーブルに要求者アドレス等を含んだ行を追加し（ステップ４１３）、ステップ４０６へ進む。最後の行でない場合は、変数ｉに１を加え処理をステップ４０４に戻す（ステップ４０８）。

ステップ４０６の後、リソース予約・使用履歴テーブルのｊ行目の要求者のアドレスがａｄｄｒと同じかどうか調べる（ステップ４０９）。同じである場合、リソース予約・使用履歴テーブルのｊ行目の使用回数に１を加え（ステップ４１０）、処理をステップ４０１へ戻す。一方、リソース予約・使用履歴テーブルのｊ行目の要求者のアドレスがａｄｄｒと同じでない場合、テーブルのｊ行目はリソース予約・使用履歴テーブルの最終行かどうか調べる（ステップ４１１）。最終行である場合は処理をステップ４０１へ戻しイベントの受信を待機する。そうでない場合は変数ｊに１を加え（ステップ４１２）、再び処理をステップ４０９へ戻す。なお、本実施の形態では使用回数を保持する形態としたが、使用されなかった回数を保持し、予約回数から予約が使用されなかった回数を減算することで使用回数を求めるという形態でもよい。

本実施の形態では無線ＬＡＮ、特にアクセスポイントと移動局との間のハンドオーバとして記載したが、アクセスポイントの代わりが移動局であるようなアドホック通信である移動局間の通信にも適用してもよい。また、リソース予約回数及び使用回数によりリソース使用確率が計算され、リソース使用確率に基づいてリソースの予約を受けつけるか判断するという処理を行っていれば無線、有線を問わず適用できることは言うまでもない。

また、本実施例では予約されたリソースが実際に使用される確率を考慮しているためアクセスポイントにおいて効率的にリソースを使用することが可能となる。

（第２の実施の形態）
第1の実施の形態ではリソース使用確率と予約受入閾値の大小を比較することで受入を判断したが、本実施の形態では予約を受けつける通信装置は、リソース使用確率と同じ確率で受入を判断することを特徴としている。

以下、予約を受けつける通信装置をアクセスポイント、予約を行う通信装置を移動局とし、アクセスポイントと移動局からなる無線ＬＡＮシステムを一例として、説明する。

本実施の形態についてその基本的構成は第１の実施の形態の通りであるが、図３の構成に示されるアクセスポイント（１０１〜１０７）におけるリソース予約受付判断手段（３１１）の動作が異なる。

図１０は本実施の形態におけるリソース予約受付判断手段（３１１）の動作を示すフローチャートである。

第１の実施の形態ではリソース予約・使用履歴データベース確率取得処理（ステップ１０３）を行った後はリソース使用確率と予約受付閾値の大小を比較していたが、本実施の形態ではステップ１０３の後、０〜１の乱数を発生させ（ステップ５０１）、リソース使用確率とステップ５０１で発生させた乱数の大小を比較する（ステップ５０２）。そして、リソース使用確率の方が大きければリソースが確保できたことを通知し（ステップ１０５）、リソース使用確率の方が小さければリソースが確保できなかったことを通知する。

本実施の形態ではリソース使用確率そのものの確率を基に割り当てを行うとして説明を行ったが、リソース使用確率そのものの確率に限ったものではなく、例えば０を下限、１を上限として（リソース使用確率＋L）の確率で割り当てを行うなどリソース使用確率に比例するような形態であってもよい（Lは−１から1の間の数）。

また、リソース使用確率そのものではなく、リソース使用確率に応じて閾値を段階的に設定するという形態でもよい。

図１１は閾値を段階的に設定するリソース予約受付確率テーブルの一例を示すものである。リソース予約受付確率テーブルには上限使用確率と予約受付確率が記載されている。上限使用確率は、その行に示す値から次の行に示す値の範囲にある確率を示すものである。例えば１行目に記載されている１が意味するものは確率の値が２行目の０．８よりも大きく１以下のものがこの範囲に該当する。予約受付確率はこの確率でリソースの受付を行う値である。例えばリソース使用確率が０．７であるならば、範囲が０．６より大きく０．８以下である上限使用確率が０．８の行に対応するため確率０．９でリソースの予約を受けつけるように処理する。

第１の実施の形態では、リソース使用確率と閾値を比較してリソースの予約受付の判断を行っていたが、本実施の形態ではリソース使用確率と同一の確率でリソースの受入を判断しているため細かいリソースの制御が可能となる。この処理によりアクセスポイントにおいてリソースの効率的な使用ができるという効果がある。

（第３の実施の形態）
本実施の形態では予約を受けつける通信装置は、リソース使用確率に基づいて予約の受入を判断することに加えて、要求されたリソース量、使用中のリソース量、既に予約が行われているリソース量を加味して予約の受入を判断することを特徴としている。

以下、予約を受けつける通信装置をアクセスポイント、予約を行う通信装置を移動局とし、アクセスポイントと移動局からなる無線ＬＡＮシステムを一例として、説明する。

本実施の形態についてその基本的構成は第１の実施の形態の通りであるが、図３の構成に示されるアクセスポイント（１０１〜１０７）におけるリソース予約受付判断手段（３１１）の動作が異なる。

図１２は本実施の形態におけるリソース予約受付判断手段（３１１）の動作を示すフローチャートである。図６と比較して要求されたリソース量、使用中のリソース量、既に予約が行われているリソース量を加味して予約の受入を判断する処理であるステップ６０１〜ステップ６１４が追加されていることが異なる。

以下、図６と比較して異なる点であるステップ６０１〜ステップ６１４の説明を行う。

ステップ１０４においてリソース使用確率が予約受付閾値より大きい場合、要求リソース量を示す変数ｒｅｑｕｅｓｔに８０２．１１ ＡＵＴＨＥＮＴＩＣＡＴＩＯＮ ＣＯＮＦＩＲＭフレーム（２０３）に含まれるＭｅａｎ Ｄａｔａ Ｒａｔｅを代入する（ステップ６０１）。次に使用リソース量を示す変数ｕｓｅｄに０を代入し、初期化を行う（ステップ６０２）。さらにリソース管理テーブルの行数を示す変数ｉに１を代入する（ステップ６０３）。ここでリソース管理テーブルのｉ行目のリソース使用状態が“使用中”であるか調査する（ステップ６０４）。

ｉ行目のリソース使用状態が“使用中”であればｕｓｅｄにｉ行目のＭｅａｎ Ｄａｔａ Ｒａｔｅの値を加えたものをｕｓｅｄに代入する（ステップ６０５）。その後、ｉ行目はリソース管理テーブルの最終行であるか調査する（ステップ６０６）。なお、ステップ６０４においてｉ行目のリソース使用状態が“使用中”でなければステップ６０６へ処理を進める。ステップ６０６においてｉ行目が最終行であれば既に予約が行われているリソース量を示す変数ｒｅｓｅｒｖｅｄに０を代入し、初期化を行い（ステップ６０７）、ｉに１を代入する（ステップ６０８）。一方、ステップ６０６においてｉ行目が最終行でなければｉに１を加え（ステップ６０９）、ステップ６０４へ戻す。

ステップ６０８の後、リソース管理テーブルのｉ行目のリソース使用状態が“予約中”であるか調査を行う（ステップ６１０）。“予約中”であれば、ｒｅｓｅｒｖｅｄにｉ行目のＭｅａｎ Ｄａｔａ Ｒａｔｅの値を加え（ステップ６１２）、ｉ行目はリソース管理テーブルの最終行であるか調査する（ステップ６１３）。ステップ６１０においてリソース使用状態が“予約中”でなければ処理をステップ６１３へ進める。

ステップ６１３においてｉ行目が最終行であれば、ｕｓｅｄとｒｅｓｅｒｖｅｄとｒｅｑｕｅｓｔｅｄとを合計したリソース量とアクセスポイントが持つ合計リソース量の比較を行う（ステップ６１４）。両者が等しいもしくはアクセスポイントが持つ合計リソース量の方が大きければステップ１０５へと進む。一方、アクセスポイントが持つ合計リソース量の方が小さければｉに１を加え（ステップ６１５）、処理をステップ６１０へと戻す。

なお、図１２の処理では予約要求がある度にｕｓｅｄ等をリソース管理テーブルの１行目から計算しているが、アクセスポイントは使用リソースを常に把握しておき使用状況に変更があった時等必要な時に計算しなおすという処理でもよい。図１３はこの使用リソース計算処理の一例を示すフローチャートである。使用リソース計算処理が初めて行われるときにｕｓｅｄに０を代入して初期化する（ステップ７０１）。続いてリソース管理テーブルの行数を示す変数ｉに１を代入し、初期化し（ステップ７０２）、通信を開始した移動局があるか調査を行う（ステップ７０３）。通信を開始した移動局があれば変数ａｄｄｒに通信を開始した移動局のアドレスを代入し（ステップ７０４）、通信を開始した移動局がなければ通信を終了した移動局があるか調査を行う（ステップ７０５）。通信を終了した移動局があれば変数ａｄｄｒに通信を終了した移動局のアドレスを代入し（ステップ７０６）、通信を終了した移動局がなければステップ７０３へ処理を戻す。ステップ７０４の後、リソース管理テーブルのｉ行目のリソース要求者がａｄｄｒと一致するか調査を行う（ステップ７０７）。一致していればｕｓｅｄにリソース管理テーブルのｉ行目のＭｅａｎ Ｄａｔａ Ｒａｔｅを加え（ステップ７０８）、一致していなければｉ行目はリソース管理テーブルの最終行であるかを調べる（ステップ７０９）。最終行であればステップ７０２へ処理を戻し、最終行でなければｉに１を加え（ステップ７１０）、処理をステップ７０７へ戻す。ステップ７０８の後もステップ７０２へ処理を戻す。前述のステップ７０６の処理の後、リソース管理テーブルのｉ行目のリソース要求者がａｄｄｒと一致するか調査を行う（ステップ７１１）。一致していればｕｓｅｄからリソース管理テーブルのｉ行目のＭｅａｎ Ｄａｔａ Ｒａｔｅを減算し（ステップ７１２）、一致していなければｉ行目はリソース管理テーブルの最終行であるかを調べる（ステップ７１３）。最終行であればステップ７０２へ処理を戻し、最終行でなければｉに１を加え（ステップ７１４）、処理をステップ７１１へ戻す。ステップ７１２の後もステップ７０２へ処理を戻す。この計算処理によって得られた値をｕｓｅｄとして使用することは図１２のステップ６０２からステップ６０６及びステップ６０９の処理と置き換えることが可能である。なお、この計算はｕｓｅｄについて説明したがｒｅｓｅｒｖｅｄについて適用してもよく、この場合ステップ６０７からステップ６１３及びステップ６１５の処理と置き換える。

本実施の形態ではｕｓｅｄとｒｅｓｅｒｖｅｄとｒｅｑｕｅｓｔｅｄとを合計したリソース量とアクセスポイントが持つ合計リソース量の比較を厳密に行うものとして説明を行ったが、例えばｕｓｅｄとｒｅｓｅｒｖｅｄとｒｅｑｕｅｓｔｅｄとを合計したリソース量が、アクセスポイントが持つ合計リソース量のＭ％を超えた場合に受入を行わないなどのある程度の幅を持たせるというような形態でもよい（Ｍは正の数）。また、必ずしもｕｓｅｄとｒｅｓｅｒｖｅｄとｒｅｑｕｅｓｔｅｄとを合計する必要はなく、例えばｕｓｅｄとｒｅｑｕｅｓｔｅｄとを合計したものを用いてもよい。

それから、本実施の形態は第1の実施の形態をもとに説明を行ったが、第２の実施の形態に要求されたリソース量、使用中のリソース量、既に予約が行われているリソース量を加味するという処理を加えた形態であってもよい。

本実施の形態ではアクセスポイントのリソースの空き状況も加味してリソースの受入を判断しているため移動局がハンドオーバを行った際にリソース不足により通信を継続することができなくなることを防ぐことが可能になるという効果がある。

（第４の実施の形態）
本実施の形態では予約を受けつける通信装置は、リソース使用確率を要求されたリソース量の期待値を求めることに使用し、要求されたリソース量の期待値、使用中のリソース量、既に予約が行われているリソース量に基づいて予約の受入を判断することを特徴としている。

以下、予約を受けつける通信装置をアクセスポイント、予約を行う通信装置を移動局とし、アクセスポイントと移動局からなる無線ＬＡＮシステムを一例として、説明する。

本実施の形態についてその基本的構成は第３の実施の形態の通りであるが、図３の構成に示されるアクセスポイント（１０１〜１０７）におけるリソース予約受付判断手段（３１１）の動作が異なる。

図１４は本実施の形態におけるリソース予約受付判断手段（３１１）の動作を示すフローチャートである。図１２と比較して、ステップ１０４が削除され、変数ｒｅｑｕｅｓｔｅｄに要求されたリソース量であるＭｅａｎ Ｄａｔａ Ｒａｔｅとリソース使用確率を乗算した値を代入するステップ８０１が追加されていることが異なる。この乗算結果は要求されたリソース量の期待値を示す。

なお、図１４の処理では予約要求がある度にｕｓｅｄ等をリソース管理テーブルの１行目から計算しているが、図１２のように使用状況に変更があった時に計算しなおすという形態でもよい。

本実施の形態では要求されたリソース量の期待値を計算し、受入の判断を行ったが、要求されたリソース量だけではなく既に予約が行われているリソース量についても移動局の各々について期待値を計算し、その結果によって予約の受入を判断するという形態でもよい。

また、本実施の形態ではｕｓｅｄとｒｅｓｅｒｖｅｄとｒｅｑｕｅｓｔｅｄとを合計したリソース量とアクセスポイントが持つ合計リソース量の比較を厳密に行うものとして説明を行ったが、例えばｕｓｅｄとｒｅｓｅｒｖｅｄとｒｅｑｕｅｓｔｅｄとを合計したリソース量が、アクセスポイントが持つ合計リソース量のＮ％を超えた場合に受入を行わないなどのある程度の幅を持たせるというような形態でもよい。（Ｎは正の数）
本実施の形態のでは第1から第3までの実施の形態とは異なり、使用量をも見込んでリソースの予約の受入を判断することでアクセスポイントのリソースを効率的に使用することができるという効果がある。

（第５の実施の形態）
第1の実施の形態では予約を受けつける通信装置は、予約を行う通信装置個別のリソース使用確率に基づいて予約の受付を判断していた。一方、本実施の形態では予約を受けつける通信装置は、移動局個別ではなく全ての予約を行う通信装置のリソース使用状況から計算されるリソース使用確率に基づいて予約の受入を判断することを特徴としている。

以下、予約を受けつける通信装置をアクセスポイント、予約を行う通信装置を移動局とし、アクセスポイントと移動局からなる無線ＬＡＮシステムを一例として、説明する。

本実施の形態についてその基本的構成は第１の実施の形態の通りであるが、図３の構成に示されるアクセスポイント（１０１〜１０７）におけるリソース予約受付判断手段（３１１）、特にリソース予約・使用履歴データベース確率取得処理の動作が異なる。

図１５は本実施の形態におけるリソース予約・使用履歴データベース確率取得処理の動作を示すフローチャートである。

第１から第４の実施の形態におけるリソース予約・使用履歴データベース確率取得処理と比較してステップ２０３及びステップ２０７が削除され、ステップ９０１、ステップ９０２、ステップ９０３が追加されている。

追加されたステップについて説明する。ステップ２０１でリソース使用確率ｐｒｏｂａｂｉｌｉｔｙに０を代入して初期化した後、リソース予約回数を示す変数ｎｕｍ＿ｒｅｓｅｒｖｅｄに０を代入して初期化し（ステップ９０１）、使用回数を示す変数ｎｕｍ＿ｉｎｖｏｋｅｄに０を代入して初期化する（ステップ９０２）。また、ステップ２０５でｎｕｍ＿ｉｎｖｏｋｅｄにリソース要求受付通知テーブルのｉ行目の使用回数を加えた後にｉ行目がリソース要求受付通知テーブルの最終行であるか調査する（ステップ９０３）。最終行であればステップ２０６としてリソース利用確率ｐｒｏｂａｂｉｌｉｔｙにｎｕｍ＿ｉｎｖｏｋｅｄをｎｕｍ＿ｒｅｓｅｒｖｅｄで除した結果を代入し、最終行でなければステップ２０８でｉに１を加える。

本実施の形態では各移動局のリソース予約回数及び使用回数の和を取るという処理を行ったが、全ての移動局の総和を計算した行を予め保持し、その値をもとにリソース使用確率を計算するという形態を取ってもよい。また、第1の実施の形態をもとに説明を行ったが、第２から第４の実施の形態に適用することも可能である。

第1から第4の実施の形態のように移動局個別にリソース使用確率を計算していると信頼度が低い場合がある。そのような場合には本実施の形態のように、個別ではなく全ての移動局を考慮することで母数が増え、統計的に見ると信頼度が上がる。よって、アクセスポイントではより高い信頼度に基づいて効率的なリソース使用が可能になるという効果がある。

（第６の実施の形態）
予約を受けつける通信装置は、第1の実施の形態では予約を受けつける通信装置個別の、第5の実施の形態では予約を受けつける通信装置全体のリソース使用確率をもとに予約の受入を判断していた。一方、本実施の形態では予約を受けつける通信装置は、予約を行う通信装置を通信速度やアプリケーションの種類、契約形態などでグループ分けし、リソースの予約をしてきた通信装置と同一のグループに属する予約を行う通信装置のリソース使用状況により計算されるリソース使用確率に基づいて予約の受入を判断することを特徴としている。

以下、予約を受けつける通信装置をアクセスポイント、予約を行う通信装置を移動局とし、アクセスポイントと移動局からなる無線ＬＡＮシステムを一例として、説明する。また、本実施の形態では通信速度をもとにグループ分けを行ったものとして説明する。

本実施の形態についてその基本的構成は第５の実施の形態の通りであるが、図３の構成に示されるアクセスポイント（１０１〜１０７）におけるリソース予約受付判断手段（３１１）、特にリソース予約・使用履歴データベース確率取得処理の動作が異なる。また、リソース予約・使用履歴データベース（３１４）に格納されているリソース予約・使用履歴テーブルの形態が異なる。

図１６は本実施の形態におけるリソース予約・使用履歴テーブルを示すものであり、図１７は本実施の形態におけるリソース予約・使用履歴データベース確率取得処理の動作を示すフローチャートである。

図１６は図５と比較して通信速度を示すＭｅａｎ Ｄａｔａ Ｒａｔｅの項目が追加されている点が異なっており、この項目は移動局のグループ分けを行うことを目的としている。

図１７は図１５と比較してステップ１００１からステップ１００４が追加されている点が異なる。ステップ２０１、ステップ９０１、ステップ９０２、ステップ２０２において変数ｐｒｏｂａｂｉｌｉｔｙｎｕｍ＿ｒｅｓｅｒｖｅｄ、ｎｕｍ＿ｉｎｖｏｋｅｄのそれぞれに０を代入し、ｉに１を代入して初期化する。その後、リソース予約・使用履歴テーブルのｉ行目のＭｅａｄ Ｄａｔａ Ｒａｔｅが８０２．１１ ＡＵＴＨＥＮＴＩＣＡＴＩＯＮ ＣＯＮＦＩＲＭフレーム（２０３）に含まれるＭｅａｎ Ｄａｔａ Ｒａｔｅと一致するか調べる（ステップ１００１）。一致していれば変数ｎｕｍ＿ｒｅｓｅｒｖｅｄにリソース予約・使用履歴テーブルｉ行目のリソース予約回数を加えるステップ２０４へ進み、一致していなければｉ行目がリソース要求テーブルの最終行であるかを調べる（ステップ１００２）。最終行であればリソース要求テーブルに行を追加し、この移動局の要求者アドレス、Ｍｅａｎ Ｄａｔａ Ｒａｔｅを入れ、リソース予約回数に１を、使用回数に０を入れる（ステップ１００３）。本実施の形態ではステップ１００１に示すように通信速度が一致していない場合は別速度としているが、上下Ｒｋｂｐｓまでの範囲は通信速度が一致しているとしてもよい（Rは正の数）。その後、リソース使用確率を示す変数ｐｒｏｂａｂｉｌｉｔｙに０を代入し（ステップ１００４）、リソース予約処理受付判断手段へと復帰する。一方、ステップ１００２において最終行で無かった場合はｉに１を加えるステップ２０８へ進む。リソース予約処理受付判断手段へと復帰した後の処理は第５の実施の形態と同一である。

なお、本実施の形態では第５の実施の形態をもとに説明を行ったが、第1から第4の実施の形態に適用することが可能である。また、本実施の形態では通信速度毎にリソース使用確率を計算するとして説明を行ったが、アプリケーションや契約形態毎に計算するという形態でもよい。同一の移動局において複数のアプリケーションを実行している場合には
本実施の形態では、グループごとに使用状況が似ているという場合には移動局をグループ分けした後にリソース使用確率を計算することでリソース予約回数及び使用回数の母数が増え、リソース使用確率の信頼度が上がるという効果がある。

（第７の実施の形態）
本実施の形態では予約を受けつける通信装置は、予約を行う通信装置のグループに応じて受入閾値を変えることを特徴としている。

以下、予約を受けつける通信装置をアクセスポイント、予約を行う通信装置を移動局とし、アクセスポイントと移動局からなる無線ＬＡＮシステムを一例として、説明する。また、本実施の形態では通信速度をもとにグループ分けを行ったものとして説明する。

本実施の形態についてその基本的構成は第１の実施の形態の通りであるが、図３の構成に示されるアクセスポイント（１０１〜１０７）の構成及びリソース予約受付判断手段（３１１）の動作が異なる。

図１８は本実施の形態におけるアクセスポイント（１０１〜１０７）の構成を示すブロック図である。図３と比較し、閾値データベース（４０１）が加わっている点が異なる。

図１９は閾値データベース（４０１）に含まれる予約閾値テーブルを示すものである。予約閾値テーブルにはＭｅａｎ Ｄａｔａ Ｒａｔｅでグループ化された移動局に対する受入閾値が示されている。

図２０は本実施の形態におけるリソース予約受付判断手段（３１１）の動作を示すフローチャートである。図６と比較してステップ１０４が削除され、ステップ１１０１からステップ１１０６が加わっている点が異なる。ステップ１０３においてリソース使用確率を求め、リソース予約受付判断手段の処理に復帰した後、受入閾値テーブルの行数を示すｉを１へ初期化する（ステップ１１０１）。その後、受入閾値テーブルｉ行目のＭｅａｎ Ｄａｔａ Ｒａｔｅが８０２．１１ ＡＵＴＨＥＮＴＩＣＡＴＩＯＮ ＣＯＮＦＩＲＭフレーム（２０３）に含まれるＭｅａｎ Ｄａｔａ Ｒａｔｅと一致するか調べ（ステップ１１０２）、一致すれば受入閾値テーブルの現在示している行に含まれる受入閾値とリソース使用確率の大小を比較する（ステップ１１０６）。リソース使用確率の方が大きければ、ステップ１０５へ進み、小さければステップ１０６へ進む。

一方、ステップ１１０２で一致していない場合はｉ行目が受入閾値テーブルの最終行であるか調べる（ステップ１１０３）。最終行であるときは受入閾値テーブルに行を追加し、この移動局のＭｅａｎ Ｄａｔａ Ｒａｔｅ、受入閾値を入れ（ステップ１１０４）、最終行でないときはｉに１を加え（ステップ１１０５）、ステップ１１０２へ処理を戻す。

なお、本実施の形態では通信速度に応じて閾値を変更するとして説明を行ったが、アプリケーションの種類に応じて閾値を変更するという形態でもよい。また、本実施の形態では第1の実施の形態をもとに説明を行ったが、第２、第３、第5、第６の実施の形態のそれぞれに適用することも可能である。

本実施例のようにグループごとに受入閾値を変更することで、例えば通信速度の速い移動局は受け入れやすくするなどの移動局に応じたリソースの制御が可能となるという効果がある。

（第８の実施の形態）
本実施の形態では予約を受けつける通信装置は、通信速度をリソース量として統計的に使用してリソース使用確率を求め、その確率に基づいて予約の受入を判断することを特徴としている。例えば、予約を行う通信装置が通信を行う際に実際に使用したリソース量の総和を予約していたリソース量の総和で除算することによりリソース使用確率が計算される。

以下、予約を受けつける通信装置をアクセスポイント、予約を行う通信装置を移動局とし、アクセスポイントと移動局からなる無線ＬＡＮシステムを一例として、説明する。

本実施の形態についてその基本的構成は第１の実施の形態の通りであるが、図３の構成に示されるアクセスポイント（１０１〜１０７）の構成、リソース予約受付判断手段（３１１）及びリソース管理手段（３１２）の動作、リソース管理データベース（３１３）及びリソース予約・使用履歴データベース（３１４）の内容が異なる。

図２１は本実施の形態におけるアクセスポイント（１０１〜１０７）の構成を示すブロック図である。図３と比較してＳＭＥ部（３１０）に通信速度計測手段（５０１）及び通信速度データベース（５０２）が追加されている。通信速度計測手段（５０１）では移動局ごとに当該アクセスポイントにおける実効速度を計測し、通信速度データベース（５０２）に渡される。この計測は一度通信が終了した後はリセットされ、計測しなおされる。

図２２はリソース予約・使用履歴データベース（３１４）に含まれるリソース予約・使用履歴テーブルを示すものである。図５では要求者アドレス、リソース予約回数及び使用回数を記載するものであったが、本実施の形態では要求者アドレス、予約したリソース量の総和である予約量及び実際に使用したリソース量の総和である使用量を記載するものである。

図２３は通信速度データベース（５０２）に含まれる通信速度テーブルを示すものである。このテーブルには要求者アドレス、通信速度計測手段（５０１）において計測された当該アクセスポイントにおける通信の実効速度が記載される。

図２４はリソース予約・使用履歴テーブル更新処理（ステップ１０８）の動作を示すフローチャートである。図８と比較してステップ３０３がステップ１２０１へと変更されている。ステップ３０２においてリソース予約・使用履歴テーブルｉ行目の要求者アドレスがａｄｄｒと一致していればリソース予約・使用履歴テーブルのｉ行目の予約量の項目に記載されている値に８０２．１１ ＡＵＴＨＥＮＴＩＣＡＴＩＯＮ ＣＯＮＦＩＲＭフレーム（２０３）に含まれるＭｅａｎ Ｄａｔａ Ｒａｔｅを加え（ステップ１２０１）、リソース予約処理受付判断手段処理へと復帰する。

図２５はリソース管理手段（３１２）の動作を示すフローチャートである。図９と比較してステップ４０１からステップ４０５がステップ１３０１からステップ１３０４に変更され、ステップ４１０がステップ１３０５に変更されている。

リソース管理手段の処理が開始されると当該アクセスポイントで通信を行っている移動局の通信が終了したか調査を行い（ステップ１３０１）、終了していれば変数ａｄｄｒに通信を終了した移動局のアドレスを代入し（ステップ１３０２）、終了していなければステップ１３０１に戻る。ステップ１３０２の後、通信速度テーブルの行数を示す変数ｉに１を代入する（ステップ１３０３）。その後、リソース管理テーブルのｉ行目のリソース要求者アドレスがａｄｄｒと一致しているか調べ（ステップ１３０４）、一致していればステップ４０６へ進み、一致していなければステップ４０７へ進む。

ステップ４０９においてリソース予約・使用履歴テーブルのｊ行目の要求者アドレスとａｄｄｒが一致していれば、リソース予約・使用履歴テーブルのｊ行目の使用量の値に通信速度テーブル内の要求者アドレスが一致する欄の通信速度を加え（ステップ１３０５）、ステップ１３０１へ戻る。

なお、本実施の形態では再送を考慮した実効速度を使用量とする形態で説明をしたが、プロトコルのオーバヘッドなどを含む通信速度を使用量とする形態でもよい。また、通信速度計測手段（５０１）及び通信速度データベース（５０２）はＳＭＥ部（３１０）に属するものとしたが、他のプロトコルの処理を行う部分に属するという形態でもよい。

また、本実施の形態では第1の実施の形態をもとに説明を行ったが、第２から第７の実施の形態に適用することもできる。

実際の通信においてはリソース使用量が予約していた量よりも少ない場合があると考えられる。本実施の形態のように通信を行う際に使用したリソース量の総和を予約していたリソース量の総和で除算することにより計算されるリソース使用確率に基づいて予約の受入を判断することにより、実際の使用量を考慮することができるため、効率的なリソース使用ができるという効果がある。

（第９の実施の形態）
本実施の形態では予約を受けつける通信装置は、予約を行う通信装置ごとのリソース予約回数が一定の値に達するまではリソース使用確率として予め定められた固定値を使用することを特徴としている。

以下、予約を受けつける通信装置をアクセスポイント、予約を行う通信装置を移動局とし、アクセスポイントと移動局からなる無線ＬＡＮシステムを一例として、説明する。

本実施の形態についてその基本的構成は第１の実施の形態の通りであるが、図３の構成に示されるアクセスポイント（１０１〜１０７）におけるリソース予約受付判断手段（３１１）、特にリソース予約・使用履歴データベース確率取得処理の動作が異なる。

図２６は本実施の形態におけるリソース予約・使用履歴データベース確率取得処理の動作を示すフローチャートである。図７と比較してステップ１４０１、ステップ１４０２が追加されている点が異なる。

ステップ２０３においてリソース予約・使用履歴テーブルのｉ行目のアドレスがａｄｄｒと一致しているか調べ、一致していた場合にはｉ行目のリソース予約回数が予め定められている予約回数閾値以上であるかを調べる（ステップ１４０１）。予約回数閾値以上であれば、ステップ２０４へ進み、予約回数閾値未満であればリソース使用確率ｐｒｏｂａｂｉｌｉｔｙに予め定められている初期確率を代入する（ステップ１４０２）。

本実施の形態は第1の実施の形態をもとに説明を行ったが、第２から第８の実施の形態にも適用することができる。

なお、本実施の形態ではリソース使用確率を切り替え可能とすることとして説明を行ったが、受入閾値を切り替えるという形態でもよい。この場合、受入閾値を用いる第１、第２及び第４から第８の実施の形態に適用することができる。

例えば、アクセスポイント設置直後は移動局のハンドオーバ実施数が少ないため、1回のリソース使用によりリソース使用確率が大きく変化してしまう。本実施の形態のように、リソース予約回数が一定の値に達するまでは固定されたリソース使用確率を使用することで、精度の低いリソース使用確率の使用を防ぐことができるという効果がある。

第１から第９の実施の形態についてリソースの予約状況及び使用状況は蓄積されていくという形態で説明を行ってきたが、蓄積されたデータの全てを用いる必要はなく周期的または管理者の作業等イベントによりリセットしてもよい。リセットをすることで比較的新しいデータのみを用いることにより精度の低いリソース使用確率の使用を防ぐことができるという効果がある。

本発明の活用例として、無線ＬＡＮのアクセスポイント、携帯電話の基地局などの無線通信装置の基地局が挙げられる。

無線ＬＡＮシステムの構成を示す図である。 ＩＥＥＥ ８０２．１１ｒ規格（Ｄｒａｆｔ ７．０）で規定されているハンドオーバ時のシーケンス図である。 第１の実施の形態におけるアクセスポイント（１０１〜１０７）の構造を示すブロック図である。 第１の実施の形態におけるリソース管理データベース（３１３）に格納されるリソース管理テーブルの一例である。 第１の実施の形態におけるリソース予約・使用履歴データベース（３１４）に格納されるリソース予約・使用履歴テーブルの一例である。 第１の実施の形態におけるリソース予約受付判断手段（３１１）の動作を示すフローチャートである。 第１の実施の形態におけるリソース予約受付判断手段（３１１）内のリソース予約・使用履歴データベース確率取得処理の動作を示すフローチャートである。 第１の実施の形態におけるリソース予約受付判断手段（３１１）内のリソース予約・使用履歴テーブル更新処理の動作を示すフローチャートである。 第１の実施の形態におけるリソース管理手段（３１２）の動作を示すフローチャートである。 第２の実施の形態におけるリソース予約受付判断手段（３１１）の動作を示すフローチャートである。 第２の実施の形態におけるリソース予約受付確率テーブルの一例を示すものである。 第３の実施の形態におけるリソース予約受付判断手段（３１１）の動作を示すフローチャートである。 第３の実施の形態における使用リソース計算処理の一例を示すフローチャートである。 第４の実施の形態におけるリソース予約受付判断手段（３１１）の動作を示すフローチャートである。 第５の実施の形態におけるリソース予約・使用履歴データベース確率取得処理の動作を示すフローチャートである。 第６の実施の形態におけるリソース予約・使用履歴テーブルの一例を示すものである。 第６の実施の形態におけるリソース予約・使用履歴データベース確率取得処理の動作を示すフローチャートである。 第７の実施の形態におけるアクセスポイント（１０１〜１０７）の構成を示すブロック図である。 第７の実施の形態における閾値データベース（４０１）に含まれる予約閾値テーブルの一例を示すものである。 第７の実施の形態におけるリソース予約受付判断手段（３１１）の動作を示すフローチャートである。 第８の実施の形態におけるアクセスポイント（１０１〜１０７）の構成を示すブロック図である。 第８の実施の形態におけるリソース予約・使用履歴データベース（３１４）に含まれるリソース予約・使用履歴テーブルの一例を示すものである。 第８の実施の形態における通信速度データベース（５０２）に含まれる通信速度テーブルの一例を示すものである。 第８の実施の形態におけるリソース予約・使用履歴テーブル更新処理の動作を示すフローチャートである。 第８の実施の形態におけるリソース管理手段（３１２）の動作を示すフローチャートである。 第９の実施の形態におけるリソース予約・使用履歴データベース確率取得処理の動作を示すフローチャートである。

符号の説明

１０１〜１０７ アクセスポイント
１１１ 移動局
１２１ ＩＥＥＥ８０２．３ネットワーク
１３１ 認証サーバ
１４１ モビリティドメイン
１５１ 外部ネットワーク

Claims (22)

1. リソースの予約を受けつける通信装置であって、
   リソースの予約を行う通信装置からのリソース予約要求を受け付けるリソース予約受付判断手段を少なくとも有し、
   前記リソース予約受付判断手段は、少なくとも１つの前記リソースの予約を行う通信装置の自通信装置におけるリソース予約状況とリソース使用状況とから求められるリソース使用確率に基づいて、予約の受付を行うことを特徴とする通信装置。
2. 前記リソース予約状況及び前記リソース使用状況は、
   自通信装置において前記リソースの予約を行う通信装置を複数のグループに分け、
   前記グループ毎に求められることを特徴とする請求項１に記載の通信装置。
3. 前記リソース予約状況及び前記リソース使用状況は、
   自通信装置における全ての前記リソースの予約を行う通信装置について求められることを特徴とする請求項１に記載の通信装置。
4. 前記リソース予約状況は前記リソースの予約を行う通信装置が予約を行った回数であり、前記リソース使用状況は前記リソースの予約を行う通信装置がリソースを実際に使用した回数であることを特徴とする請求項１から3のいずれか1項に記載の通信装置。
5. 前記リソース予約状況は前記リソースの予約を行う通信装置が予約を行ったリソース量の合計であり、
   前記リソース使用状況は前記リソースの予約を行う通信装置が実際に使用したリソース量の合計であることを特徴とする請求項１から3のいずれか1項に記載の通信装置。
6. 前記リソース予約受付判断手段は、
   前記リソース使用確率と予め定められた予約受付閾値を比較した結果に基づいて、予約の受付を行うことを特徴とする請求項１から５のいずれか1項に記載の通信装置。
7. 前記リソース予約受付判断手段は、
   前記リソース使用確率をもとに定められた確率で予約の受付を行うことを特徴とする請求項１から５のいずれか1項に記載の通信装置。
8. 前記リソースの予約を受けつける通信装置は、
   さらに自通信装置のリソースの状況を管理するリソース管理手段を有し、
   前記リソース予約受付判断手段は、
   少なくとも自通信装置が予約の受付を判断するときに使用しているリソース量と前記リソースの予約を行う通信装置が予約をしてきたリソース量の期待値とを合計したリソース量と、前記リソースの予約を受けつける通信装置が保有している全リソース量とを比較することで予約の受付を行うことを特徴とする請求項１から５のいずれか1項に記載の通信装置。
9. 前記リソースの予約を受けつける通信装置は、
   さらに自通信装置のリソースの状況を管理するリソース管理手段を有し、
   前記リソース予約受付判断手段は、
   少なくとも自通信装置が予約の受付を判断するときに使用しているリソース量と前記リソースの予約を行う通信装置が予約をしてきたリソース量とを合計したリソース量と、前記リソースの予約を受けつける通信装置が保有している全リソース量とを比較することで予約の受付を行うことを特徴とする請求項６または7のいずれか1項に記載の通信装置。
10. 前記リソース予約受付判断手段は、
    所定の条件下で前記リソース使用確率を固定値と計算した値とで切り替えることを特徴とする請求項１から９のいずれか1項に記載の通信装置。
11. 少なくとも１つのリソースの予約を行う通信装置と少なくとも1つのリソースの予約を受けつける通信装置を含む通信システムであって、
    前記リソースの予約を受けつける通信装置は、少なくとも１つの前記リソースの予約を行う通信装置の自通信装置におけるリソース予約状況とリソース使用状況とから求められるリソース使用確率に基づいて、予約の受付を行うことを特徴とする通信システム。
12. 前記リソース予約状況及び前記リソース使用状況は、
    自通信装置において前記リソースの予約を行う通信装置を複数のグループに分け、
    前記グループ毎に求められることを特徴とする請求項１１に記載の通信システム。
13. 前記リソース予約状況及び前記リソース使用状況は、
    自通信装置における全ての前記リソースの予約を行う通信装置について求められることを特徴とする請求項１１に記載の通信システム。
14. 予約を受けつける通信装置のリソースの予約受付を判断する方法であって、リソースの予約を行う通信装置の自通信装置におけるリソース予約状況とリソース使用状況とから求められるリソース使用確率に基づいて、予約の受付を判断することを特徴とする予約受付判断方法。
15. 前記リソース予約状況及び前記リソース使用状況は、
    自通信装置において前記リソースの予約を行う通信装置を複数のグループに分け、
    前記グループ毎に求められることを特徴とする請求項１４に記載の予約受付判断方法。
16. 前記リソース予約状況及び前記リソース使用状況は、
    自通信装置における全ての前記リソースの予約を行う通信装置について求められることを特徴とする請求項１４に記載の予約受付判断方法。
17. 少なくとも１つのリソースの予約を行う通信装置と少なくとも1つのリソースの予約を受けつける通信装置を含む通信システムの予約受付を判断する方法であって、リソースの予約を行う通信装置の自通信装置におけるリソース予約状況とリソース使用状況とから求められるリソース使用確率に基づいて、予約の受付を判断することを特徴とする予約受付判断方法。
18. 前記リソース予約状況及び前記リソース使用状況は、
    自通信装置において前記リソースの予約を行う通信装置を複数のグループに分け、
    前記グループ毎に求められることを特徴とする請求項１７に記載の予約受付判断方法。
19. 前記リソース予約状況及び前記リソース使用状況は、
    自通信装置における全ての前記リソースの予約を行う通信装置について求められることを特徴とする請求項１７に記載の予約受付判断方法。
20. 情報処理装置に処理を実行させるプログラムであって、前記プログラムは、前記情報処理装置にリソースの予約を行う通信装置の自通信装置におけるリソース予約状況とリソース使用状況とから求められるリソース使用確率に基づいて、予約を受けつける通信装置のリソースの予約の受付の処理を実行させることを特徴とするプログラム。
21. 前記リソース予約状況及び前記リソース使用状況は、
    自通信装置において前記リソースの予約を行う通信装置を複数のグループに分け、
    前記グループ毎に求められることを特徴とする請求項２０に記載のプログラム。
22. 前記リソース予約状況及び前記リソース使用状況は、
    自通信装置における全ての前記リソースの予約を行う通信装置について求められることを特徴とする請求項２０に記載のプログラム。

Images