アクセス制御装置、無線ＩＰ電話システム、及びアクセス制御方法
【課題】無線APのリソース状態に応じた呼制御を行う。
【解決手段】無線ＩＰ電話システムにおけるアクセス制御装置において、端末から無線APへの接続を契機として、前記端末の下位レイヤ識別情報と無線AP識別情報とを含む登録要求を受信し、当該無線AP識別情報を前記下位レイヤ識別情報に対応付けて登録する手段と、前記端末の呼制御で用いられる上位レイヤ識別情報と前記下位レイヤ識別情報とを含む登録要求をVoIP呼制御手段から受信し、上位レイヤ識別情報を下位レイヤ識別情報に対応付けて登録する手段と、呼接続要求を受信したVoIP呼制御手段からリソース状態の問い合わせを受信し、当該問い合わせに含まれる上位レイヤ識別情報に基づき前記無線APを検出し、当該無線APが輻輳状態にあるか否かの判定結果を取得し、輻輳状態にある場合に前記無線APが輻輳中であることを通知する手段とを備える。
【解決手段】無線ＩＰ電話システムにおけるアクセス制御装置において、端末から無線APへの接続を契機として、前記端末の下位レイヤ識別情報と無線AP識別情報とを含む登録要求を受信し、当該無線AP識別情報を前記下位レイヤ識別情報に対応付けて登録する手段と、前記端末の呼制御で用いられる上位レイヤ識別情報と前記下位レイヤ識別情報とを含む登録要求をVoIP呼制御手段から受信し、上位レイヤ識別情報を下位レイヤ識別情報に対応付けて登録する手段と、呼接続要求を受信したVoIP呼制御手段からリソース状態の問い合わせを受信し、当該問い合わせに含まれる上位レイヤ識別情報に基づき前記無線APを検出し、当該無線APが輻輳状態にあるか否かの判定結果を取得し、輻輳状態にある場合に前記無線APが輻輳中であることを通知する手段とを備える。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は無線LAN技術を用いた無線ＩＰ電話システムに関し、特に、無線LANアクセスポイント毎に輻輳制御を行う無線ＩＰ電話システムに関するものである。
【背景技術】
【０００２】
図１に従来の無線ＩＰ電話システムの構成例を示す。図１に示すように、この無線ＩＰ電話システムは、複数の無線LANアクセスポイント（以下、無線APと呼ぶ）、複数の無線APを管理する無線LANスイッチ、ＩＰ電話の呼制御を行うSIPサーバを含む。また、無線APの配下には無線VoIP端末等の端末が存在し、無線APと接続する。このシステムでは、SIPに基づく呼接続処理により、端末間で音声チャネルが確立され、ＲＴＰによる音声通信が行われる。
【０００３】
無線LANスイッチは、端末と無線APとの間のハンドオーバをサポートする機能、端末から無線APへの接続を分散させる機能等を備えており、これにより高速なハンドオーバや、帯域が不足している無線APを回避して帯域に余裕のある無線APへの接続を行うことなどが可能である（例えば、非特許文献１参照）。
【非特許文献１】日経コミュニケーション、ｐｐ．９６〜１０３、日経ＢＰ社 ２００５．７．１５
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、従来の無線ＩＰ電話システムには次のような問題がある。
【０００５】
例えば図１のシステムにおける無線AP１０に多数の端末が接続され、無線AP１０にて限界に近い無線APリソースが利用されている状態において、無線AP１０の配下に存在しているが未だ呼接続がなされていない端末１に対する新たな呼接続要求が端末２から発信されたものとする。
【０００６】
一般に無線APにおける各接続端末に対するリソース配分は、サービス品質(QoS)の保証がないベストエフォート型であるため、呼接続処理の中で無線AP１０に端末１の呼に対するリソースが割り当てられ、端末１と発信元端末２間で音声チャネルが確立され、音声通信が行われる。
【０００７】
しかし、無線AP１０は端末１の接続前の時点で限界に近い無線APリソースを利用していたたため、端末１が接続したことにより、無線AP１０のリソースは更に消費され、無線AP１０は輻輳状態となる。これにより、端末１において良い音声品質が得られないばかりでなく、もともと無線AP１０に接続していた全端末における音声品質が低下し、雑音、音抜けの発生、通信断等が発生する。
【０００８】
このように従来の無線ＩＰ電話システムでは、無線AP配下の端末に対して呼接続要求があった場合、その無線APが混雑状態であっても、その端末に対して呼が確立してしまい、無線AP配下の全端末に対して悪影響を及ぼすという問題があった。
【０００９】
また、従来の無線LANスイッチと無線APからなるシステムにおいて、無線APで収容可能な呼数を制限する技術はあるが、アプリケーションレイヤ（例えばSIPによる呼制御を実行するレイヤ）での制御を行うことができないため、発信元端末が呼接続に失敗した場合に、発信元端末は着信先端末もしくは無線APのどちらが原因で呼接続が失敗したか等を把握できない。このように、従来のシステムではアプリケーションレイヤでの柔軟な対応が実現できなかった。
【００１０】
更に、従来の無線ＩＰ電話システムでは、通話中の端末に対する無線APの輻輳管理・制御を行うことができないので、端末が、接続中の無線APの配下から別の無線APの配下にハンドオーバする際に、別の無線APが限界に近い無線APリソースを利用していた場合であっても、別の無線APはハンドオーバしてきた端末の接続を受け付ける。従って、この端末を受け付けた別の無線APでは、図１に示す端末２からの着信を受け付けた無線APと同様の問題が発生する。つまり、ハンドオーバ先の無線APを利用している端末の呼の通話品質が低下したり、不通状態等が発生する。また、ハンドオーバした端末が不通状態になった場合に、通信相手端末はその端末がどのような状態にあるかを知ることができないため、不通状態となった通話を切断してよいかどうか判断できず、不要な待機状態が発生してしまうという問題もある。
【００１１】
また、無線APが隣接して複数配置されている環境では、ある無線APが輻輳していても、隣接する無線APでは輻輳していない場合があり、ある無線APが輻輳中の場合に、それを検知し、隣接する無線APを利用して通信を継続したいという要求がある。
【００１２】
本発明は上記の点に鑑みてなされたものであり、上記従来技術の問題を解消し、無線APのリソース状態に応じた制御を行うための技術を提供することを目的とする。
【課題を解決するための手段】
【００１３】
上記の課題は、無線APとVoIP呼制御手段とを有する無線ＩＰ電話システムにおけるアクセス制御装置であって、端末から前記無線APへ接続がなされたことを契機として、データリンク層における前記端末の識別情報である下位レイヤ識別情報と無線AP識別情報とを含む端末登録要求を前記無線APから受信し、当該無線AP識別情報を前記下位レイヤ識別情報に対応付けて記憶手段に登録する下位レイヤ登録手段と、前記端末の呼制御で用いられる識別情報である上位レイヤ識別情報と前記下位レイヤ識別情報とを含む端末登録要求を前記VoIP呼制御手段から受信し、当該上位レイヤ識別情報を前記下位レイヤ識別情報に対応付けて前記記憶手段に登録する上位レイヤ登録手段と、前記端末への着信または前記端末からの発信に係る呼接続要求を受信した前記VoIP呼制御手段からリソース状態の問い合わせを受信し、当該問い合わせに含まれる前記端末の上位レイヤ識別情報に基づき前記記憶手段を検索して前記端末を収容する前記無線APを検出し、当該無線APが輻輳状態にあるか否かの判定結果を取得し、輻輳状態にある場合に前記無線APが輻輳中であることを前記VoIP呼制御手段に通知する通知手段とを有することを特徴とするアクセス制御装置により解決できる。なお、上位レイヤ識別情報を下位レイヤ識別情報に対応付けて記憶手段に登録することは、予め記憶手段に格納されている上位レイヤ識別情報と下位レイヤ識別情報とに対応付けて当該上位レイヤ識別情報が登録状態になったことを示す情報を記録することも含むものとする。
【００１４】
前記アクセス制御装置の記憶手段は、前記無線AP識別情報と前記無線APのリソース上限値と前記無線APで使用中のリソース量とを対応付けて格納しており、前記通知手段は前記無線APのリソース上限値及び使用中リソース量と、前記リソース状態の問い合わせに含まれる前記端末に対する必要リソース量とに基づき前記無線APが輻輳状態にあるか否かを判定する判定手段を含むこととしてもよい。
【００１５】
また、本発明は、前記アクセス制御装置と前記VoIP呼制御手段とを有する無線ＩＰ電話システムであって、前記VoIP呼制御手段は、前記リソース状態の問い合わせに対する応答として前記無線APが輻輳中である旨の通知を前記アクセス制御装置から受信した場合に、前記呼接続要求を保留させ、当該呼接続要求を送信した端末に対して通信路が輻輳中であることを通知し、前記無線APが輻輳状態から回復した旨の通知を前記アクセス制御装置から受信したことを契機として、着信先端末への呼接続を行う呼制御手段を有することを特徴とする無線ＩＰ電話システムとして構成することもできる。
【００１６】
本発明は、無線APとVoIP呼制御手段とアクセス制御装置とを有する無線ＩＰ電話システムにおけるアクセス制御方法であって、前記アクセス制御装置が、端末から前記無線APへ接続がなされたことを契機として、データリンク層における前記端末の識別情報である下位レイヤ識別情報と無線AP識別情報とを含む端末登録要求を前記無線APから受信し、当該無線AP識別情報を前記下位レイヤ識別情報に対応付けて記憶手段に登録する下位レイヤ登録ステップと、前記アクセス制御装置が、前記端末の呼制御で用いられる識別情報である上位レイヤ識別情報と前記下位レイヤ識別情報とを含む端末登録要求を前記VoIP呼制御手段から受信し、当該上位レイヤ識別情報を前記下位レイヤ識別情報に対応付けて前記記憶手段に登録する上位レイヤ登録ステップと、前記VoIP呼制御手段が、前記端末への着信または前記端末からの発信に係る呼接続要求を受信し、当該端末の呼に対して必要なリソース状態の問い合わせを前記アクセス制御装置に送信するリソース状態問い合わせステップと、前記アクセス制御装置が、前記問い合わせに含まれる前記端末の上位レイヤ識別情報に基づき前記記憶手段を検索して前記端末を収容する前記無線APを検出し、当該無線APが輻輳状態にあるか否かの判定結果を取得し、輻輳状態にある場合に前記無線APが輻輳中であることを前記VoIP呼制御手段に通知する通知ステップと、前記VoIP呼制御手段が、前記無線APが輻輳中であることに応じた呼制御を実行する呼制御ステップとを有することを特徴とするアクセス制御方法として構成することもできる。
【００１７】
また、本発明は、複数の無線APとVoIP呼制御手段とを有する無線ＩＰ電話システムにおけるアクセス制御装置であって、端末からある無線APへ接続がなされたことを契機として、データリンク層における前記端末の識別情報である下位レイヤ識別情報と無線AP識別情報とを含む端末登録要求を前記無線APから受信し、当該無線APの識別情報を前記下位レイヤ識別情報に対応付けて記憶手段に登録する下位レイヤ登録手段と、前記端末の呼制御で用いられる識別情報である上位レイヤ識別情報と前記下位レイヤ識別情報とを含む端末登録要求を前記VoIP呼制御手段から受信し、当該上位レイヤ識別情報を下位レイヤ識別情報に対応付けて前記記憶手段に登録する上位レイヤ登録手段と、前記端末への着信または前記端末からの発信に係る呼接続要求を受信した前記VoIP呼制御手段からのリソース予約要求を契機として、当該要求に含まれる前記端末の上位レイヤ識別情報に基づき前記記憶手段を検索して前記端末を収容する前記無線APを検出し、前記無線APにおける前記端末に対する通信リソースの割り当て制御を行うリソース制御手段とを有し、前記VoIP呼制御手段により前記端末と相手端末間での呼接続が行われ、前記端末が前記相手端末と通信中の状態において、前記端末が、接続中の無線APの配下から、他の無線APである移動先無線APの配下に移動した場合に、前記端末から前記移動先無線APへ接続がなされたことを契機として、前記下位レイヤ登録手段は、前記端末の下位レイヤ識別情報と前記移動先無線APの識別情報とを含む端末登録要求を前記移動先無線APから受信し、当該移動先無線APの識別情報を前記下位レイヤ識別情報及び前記上位レイヤ識別情報に対応付けて前記記憶手段に登録し、前記リソース制御手段は、前記VoIP呼制御手段からの要求を受けることなく、前記無線APにおいて前記端末に対して割り当てられていたリソースを解放し、前記移動先無線APが輻輳状態でない場合に、当該移動先無線APにおいて前記端末に対する通信リソースの確保を行うことを特徴とするアクセス制御装置として構成することもできる。
【００１８】
前記リソース制御手段は、前記移動先無線APにおけるリソースの確保を行う前に、前記移動先無線APが輻輳状態にあるか否かの判定結果を取得し、当該移動先無線APが輻輳状態にある場合に、前記アクセス制御装置は、前記端末との無線リンク切断要求を前記移動先無線APに送信するようにしてもよい。
【００１９】
この構成において、前記無線リンク切断要求を受信した移動先無線APから無線リンク切断指示を受信した前記端末が、他の無線APへの接続を行ったことを契機として、前記下位レイヤ登録手段は、前記他の無線APの識別情報を前記下位レイヤ識別情報及び前記上位レイヤ識別情報に対応付けて前記記憶手段に登録し、前記リソース制御手段は、前記他の無線APが輻輳状態でない場合に、前記他の無線APにおいて前記端末に対するリソースの確保を行うことができる。
【００２０】
また、前記アクセス制御装置は、前記端末が接続する無線APが輻輳状態にあるためにリソース確保に失敗した回数を保持し、その回数と所定の回数とを比較し、リソース確保に失敗した回数が前記所定の回数に達していない場合に、リソース確保に失敗した無線APに無線リンク切断要求を送信し、リソース確保に失敗した回数が前記所定の回数に達している場合には、ハンドオーバ失敗通知を前記VoIP呼制御装置に送信するようにしてもよい。
【００２１】
上記アクセス制御装置と前記VoIP呼制御手段とを有する無線ＩＰ電話システムにおいて、前記VoIP呼制御手段は、前記ハンドオーバ失敗通知を前記アクセス制御装置から受信した場合に、前記相手端末に対する呼制御を行うようにしてもよい。
【００２２】
また、本発明は、複数の無線APとVoIP呼制御手段とアクセス制御装置とを有する無線ＩＰ電話システムにおけるアクセス制御方法であって、前記アクセス制御装置が、端末からある無線APへ接続がなされたことを契機として、データリンク層における前記端末の識別情報である下位レイヤ識別情報と無線AP識別情報とを含む端末登録要求を前記無線APから受信し、当該無線APの識別情報を前記下位レイヤ識別情報に対応付けて記憶手段に登録する下位レイヤ登録ステップと、前記アクセス制御装置が、前記端末の呼制御で用いられる識別情報である上位レイヤ識別情報と前記下位レイヤ識別情報とを含む端末登録要求を前記VoIP呼制御手段から受信し、当該上位レイヤ識別情報を下位レイヤ識別情報に対応付けて前記記憶手段に登録する上位レイヤ登録ステップと、前記VoIP呼制御手段が、前記端末への着信または前記端末からの発信に係る呼接続要求を受信し、リソース予約要求を前記アクセス制御装置に送信するステップと、前記アクセス制御装置が、前記リソース予約要求を受信したことを契機として、当該要求に含まれる前記端末の上位レイヤ識別情報に基づき前記記憶手段を検索して前記端末を収容する前記無線APを検出し、前記無線APにおける前記端末に対する通信リソースの割り当て制御を行うリソース制御ステップとを有し、前記VoIP呼制御手段が前記端末と相手端末間での呼接続処理を行い、前記端末が前記相手端末と通信中の状態において、前記端末が、接続中の無線APの配下から、他の無線APである移動先無線APの配下に移動した場合に、前記端末から前記移動先無線APへ接続がなされたことを契機として、前記移動先無線APは、前記端末の下位レイヤ識別情報と前記移動先無線APの識別情報とを含む端末登録要求を前記アクセス制御装置に送信し、前記端末登録要求を受信した前記アクセス制御装置は、前記移動先無線APの識別情報を前記下位レイヤ識別情報及び前記上位レイヤ識別情報に対応付けて前記記憶手段に登録し、前記VoIP呼制御手段からの要求を受けることなく、前記無線APにおいて前記端末に対して割り当てられていた通信リソースを解放し、前記移動先無線APが輻輳状態でない場合に、前記移動先無線APにおいて前記端末に対する通信リソースの確保を行うことを特徴とするアクセス制御方法として構成することもできる。
【００２３】
また、本発明は、複数の無線APとVoIP呼制御手段とを有する無線ＩＰ電話システムにおけるアクセス制御装置であって、端末からある無線APへ接続がなされたことを契機として、データリンク層における前記端末の識別情報である下位レイヤ識別情報と無線AP識別情報とを含む端末登録要求を前記無線APから受信し、当該無線APの識別情報を前記下位レイヤ識別情報に対応付けて記憶手段に登録する下位レイヤ登録手段と、前記端末の呼制御で用いられる識別情報である上位レイヤ識別情報と前記下位レイヤ識別情報とを含む端末登録要求を前記VoIP呼制御手段から受信し、当該上位レイヤ識別情報を下位レイヤ識別情報に対応付けて前記記憶手段に登録する上位レイヤ登録手段と、前記端末への着信または前記端末からの発信に係る呼接続要求を受信した前記VoIP呼制御手段から当該端末に対するリソース予約要求を受信し、当該要求に含まれる前記端末の上位レイヤ識別情報に基づき前記記憶手段を検索して前記端末を収容する前記無線APを検出し、当該無線APが輻輳状態にあるか否かの判定結果を取得するリソース判定手段とを有し、前記無線APが輻輳状態である場合に、前記アクセス制御装置は、前記端末との無線リンク切断要求を前記無線APに送信し、前記無線リンク切断要求を受信した前記無線APから無線リンク切断指示を受信した前記端末が他の無線APへの接続を行ったことを契機として、前記下位レイヤ登録手段は、前記他の無線APの識別情報を前記下位レイヤ識別情報及び前記上位レイヤ識別情報に対応付けて前記記憶手段に登録することを特徴とするアクセス制御装置として構成してもよい。
【００２４】
前記呼接続要求が、相手端末から前記端末への着信に係るものである場合に、前記リソース判定手段は、前記他の無線APが輻輳状態にあるか否かの判定結果を取得し、前記他の無線APが輻輳状態にない場合に、前記アクセス制御装置は、前記VoIP呼制御手段に、リソース予約に成功したことを示すメッセージを送信するように構成できる。
【００２５】
前記アクセス制御装置と前記VoIP呼制御手段とを有する無線ＩＰ電話システムにおいて、前記VoIP呼制御手段は、前記リソース予約に成功したことを示すメッセージを受信したことに応じて、前記呼接続要求に基づく呼接続処理を継続することができる。
【００２６】
また、前記アクセス制御装置と前記VoIP呼制御手段とを有する無線ＩＰ電話において、前記呼接続要求が前記端末から相手端末への発信に係るものである場合に、前記リソース判定手段は、前記他の無線APが輻輳状態にあるか否かの判定結果を取得し、前記他の無線APが輻輳状態にない場合に、前記VoIP呼制御手段は、前記端末から再度受信する呼接続要求に基づき、前記端末と前記相手端末との間の呼接続処理を行うように構成することができる。
また、前記アクセス制御装置は、前記端末が接続した無線APが輻輳状態にあるためにリソース予約に失敗した回数を保持し、その回数と所定の回数とを比較し、リソース予約に失敗した回数が前記所定の回数に達していない場合に、リソース予約に失敗した無線APに無線リンク切断要求を送信し、リソース予約に失敗した回数が前記所定の回数に達している場合には、無線APが輻輳状態にあることを示すメッセージを前記VoIP呼制御装置に送信するように構成してもよい。
【００２７】
また、本発明は、複数の無線APとVoIP呼制御手段とアクセス制御装置とを有する無線ＩＰ電話システムにおけるアクセス制御方法であって、前記アクセス制御装置が、端末からある無線APへ接続がなされたことを契機として、データリンク層における前記端末の識別情報である下位レイヤ識別情報と無線AP識別情報とを含む端末登録要求を前記無線APから受信し、当該無線APの識別情報を前記下位レイヤ識別情報に対応付けて記憶手段に登録する下位レイヤ登録ステップと、前記アクセス制御装置が、前記端末の呼制御で用いられる識別情報である上位レイヤ識別情報と前記下位レイヤ識別情報とを含む端末登録要求を前記VoIP呼制御手段から受信し、当該上位レイヤ識別情報を下位レイヤ識別情報に対応付けて前記記憶手段に登録する上位レイヤ登録ステップと、前記VoIP呼制御手段が、前記端末への着信または前記端末からの発信に係る呼接続要求を受信するステップと、前記アクセス制御装置が、前記VoIP呼制御手段から前記端末に対するリソース予約要求を受信し、当該要求に含まれる前記端末の上位レイヤ識別情報に基づき前記記憶手段を検索して前記端末を収容する前記無線APを検出し、当該無線APが輻輳状態にあるか否かの判定結果を取得するリソース判定ステップと、前記無線APが輻輳状態である場合に、前記アクセス制御装置が、前記端末との無線リンク切断要求を前記無線APに送信するステップと、前記無線リンク切断要求を受信した前記無線APから無線リンク切断指示を受信した前記端末が他の無線APへの接続を行ったことを契機として、前記アクセス制御装置が、前記他の無線APの識別情報を前記下位レイヤ識別情報及び前記上位レイヤ識別情報に対応付けて前記記憶手段に登録するステップとを有することを特徴とするアクセス制御方法として構成してもよい。
【発明の効果】
【００２８】
本発明によれば、データリンク層における端末の識別情報である下位レイヤ識別情報に基づき無線AP識別情報と端末の呼制御で用いられる識別情報である上位レイヤ識別情報とを対応付けて登録するので、呼制御で用いられる上位レイヤ識別情報に基づき対象端末を収容する無線APを検出できるので、その無線APのリソース状態に応じて当該上位レイヤ識別情報に対応する端末の呼制御を実現できる。よって、無線AP配下の端末に対して呼接続要求があった場合、その無線APが混雑状態であれば、その端末に対して呼を確立させずに例えば発信端末に対してビジーを送信する等といったアプリケーションレイヤでの柔軟な対応が可能となり、無線AP配下の全端末に対して悪影響を及ぼすという従来技術の問題が解消される。
【００２９】
また、アプリケーションレイヤでの柔軟な対応が可能となるため、例えば、呼接続に失敗した発信元端末に対して、呼接続失敗の原因通知、呼の転送、輻輳回復後の呼接続等の様々な対応をとることが可能となる。
【００３０】
また、本発明によれば、通話中の端末に対する無線APの輻輳管理・制御を行いながらハンドオーバを実施することが可能となり、ハンドオーバに関する従来技術の問題が解消される。
【００３１】
また、本発明によれば、無線APが隣接して複数配置されている環境において、接続した無線APが輻輳していても、隣接する無線APが輻輳していない場合には、隣接する無線APを利用して通信を継続することが可能となる。また、これにより、呼の成功確率を高めることができる。
【発明を実施するための最良の形態】
【００３２】
以下、図面を参照して本発明の実施の形態を説明する。
【００３３】
＜第１の実施の形態＞
（システム概要）
図２に、本発明の第１の実施の形態におけるシステムの一例を示す。図２に示すシステムは、図１に示したシステムにアクセスコントローラ３０が付加されたものである。なお、アクセスコントローラ３０は、図２における無線LANスイッチに替えて、もしくは無線LANスイッチ内に備えることも可能である。
【００３４】
図２のシステムにおけるアクセスコントローラ３０は、無線AP毎に端末毎のリソースの割り当て状態を管理する機能を有している。SIPサーバ４０はVoIP通信の発生に応じてアクセスコントローラにリソース状態を問い合わせ、リソース状態に応じた呼制御を行う機能を有している。
【００３５】
図３を用いて本実施の形態のシステムの動作概要を説明する。図３において、無線AP１０は輻輳状態であり、端末１が無線AP１０配下にあるが未だ呼接続はされていないものとする。このような状態で、発信元の端末２から端末１に対する呼接続要求がSIPサーバ４０に送信されると（ステップＡ）、SIPサーバ４０はアクセスコントローラ３０に、着信先端末である端末１の呼のためのリソース状態を問い合わせる（ステップＢ）。アクセスコントローラ３０は、無線AP１０が輻輳状態であり、無線AP１０において端末１に対するリソースの割り当てができないことをSIPサーバ４０に通知する（ステップＣ）。SIPサーバ４０はこの通知を受信し、ステップＡの呼接続要求に対する応答として、発信元の端末２に対してビジーを送信する（ステップＤ）。
【００３６】
このように本実施形態では、無線APが輻輳状態にある場合には新たな呼接続がなされないため、新規の呼接続によりもたらされる無線APに接続されている端末に対する音声劣化等の悪影響を防止できる。なお、輻輳時におけるSIPサーバ４０の処理としてビジー返却を説明したが、これは一例に過ぎず、他にも様々な処理が可能である。
【００３７】
（システムの動作詳細）
次に、本実施の形態のシステムの動作をシーケンス図を参照して詳細に説明する。各シーケンス図では、各装置内に保持されるデータの構造を適宜示している。また、シーケンス図中にレジストラとSIPサーバが示されているが、これらは別々の装置であってもよいし、SIPサーバ内にレジストラが含まれる構成でもよい。このレジストラは一般的なSIPに基づくレジストラの機能と同様の機能を有している。また、各シーケンス中、MSIDは端末のMACアドレスを示し、APIDは無線APのIDを示し、URIはSIP−URIを示す。
【００３８】
まず、図４を参照してVoIP端末１（以下、端末１と呼ぶ）をアクセスコントローラに登録するためのシーケンスを説明する。図４に示す登録処理は、例えば端末１の電源が入れられたときに自動的に行われるものである。また、図４に示す時点においてSIPサーバにアクセスコントローラが登録されており、アクセスコントローラとSIPサーバ間でSIPに基づくメッセージ送受信が可能となっている。
【００３９】
図４のステップ１において、端末１と無線AP間で無線LANにおける無線リンク接続処理及び認証処理等が行われる。ここで、無線APは端末１のMACアドレス（MSID）を取得し、登録する（ステップ２）。無線APは無線APのID（AP０１）と端末１のMACアドレス（MS０１）とを含む端末登録リクエストをアクセスコントローラに対して送信する（ステップ３）。アクセスコントローラは無線APから受信した無線APのID（AP０１）と端末１のMACアドレス（MS０１）とを記憶装置に格納することにより登録する（ステップ４）。そして、アクセスコントローラは無線APに対して端末登録レスポンスを返す（ステップ５）。
【００４０】
ステップ６において、端末１はレジストラに対してSIPのレジスタメッセージを送信する。送信するメッセージにはMS０１と端末１のURI（URI１）が含まれる。レジストラは通常のレジスタ処理を行うとともに、MS０１とURI１とを含むURI登録リクエストをアクセスコントローラに送信する（ステップ７）。アクセスコントローラはURI１をAP０１及びMS０１と対応付けて格納することによりURIの有効化を行い（ステップ８）、URI登録レスポンスをレジストラに送信する（ステップ９）。そして、レジストラはステップ６のレジスタメッセージの応答を端末１に返す（ステップ１０）。
【００４１】
なお、ここで説明する例では、端末のMACアドレスとURIとをシーケンスの中でアクセスコントローラに格納しているが、予めこれらのデータをアクセスコントローラに格納しておき、状態変化のみを記録することとしてもよい。この場合、例えば、ステップ４において予め登録されているMS０１に対応付けてAP０１が記録され、ステップ８においてAP０１、MS０１、URI１に対応付けてURI１が有効になった旨の情報が記録される。他の実施の形態でも同様である。
【００４２】
次に、図５を参照してアクセスコントローラから登録された端末１を削除する処理について説明する。図５に示す処理は、例えば端末１の電源を切る際に実行されるものである。
【００４３】
図５のステップ１において、端末１は登録削除命令を含むレジスタメッセージをレジストラに送信する。レジストラはアクセスコントローラに対してURI削除リクエストを送信し（ステップ２）、これを受信したアクセスコントローラはデータベースからURI１を削除することによりURIを無効化する（ステップ３）。アクセスコントローラはURI削除レスポンスを返し（ステップ４）、レジストラは端末１に対して応答を返す（ステップ５）。
【００４４】
ステップ６において、端末１は無線APから離脱する（無線APとの無線リンクを切断する）場合における無線LANの処理を実行し、これを受けて無線APはMSIDを削除するとともに（ステップ７）、端末削除リクエストをアクセスコントローラに送信し（ステップ８）、これを受信したアクセスコントローラはデータベースからAP０１とMS０１を削除し（ステップ９）、端末削除レスポンスを無線APに返す（ステップ１０）。
【００４５】
次に、図６〜図８を参照して、輻輳状態に無い無線AP配下の端末１に端末２から着信要求がなされた場合の動作について説明する。
【００４６】
発信元の端末２が呼接続要求（INVITE）をSIPサーバに送信する（ステップ１）。INVITEを受信したSIPサーバは、発信元端末URI（URI２）と着信先端末URI（URI１）と必要帯域幅とを含むQoS予約リクエストをアクセスコントローラに送信する（ステップ２）。アクセスコントローラは着信先URI１に基づきデータベースを検索し、端末１を配下に持つ無線APを抽出する（ステップ３）。そして、その無線APに対してMS０１と必要帯域幅とを含むQoS予約リクエストを送信する（ステップ４）。無線APは端末１に対して帯域を予約し（ステップ５）、QoS予約レスポンスをアクセスコントローラに返し（ステップ６）、アクセスコントローラはQoS予約レスポンスをSIPサーバに返す（ステップ７）。その後、通常のSIPに基づくシーケンスが実行される（ステップ８〜ステップ１２）。
【００４７】
なお、本例では無線APが帯域を管理し、帯域予約／確保を行うこととしているが、アクセスコントローラに、無線APの帯域を管理し、帯域予約／確保等のリソース制御を行う機能を持たせてもよい。この場合、無線APとアクセスコントローラ間での帯域予約／確保／解放等に関するメッセージの送受信はなされず、アクセスコントローラ内で帯域予約／確保／解放等のリソース管理がなされる。他の実施の形態でも同様である。
【００４８】
無線APはタイマ監視をしており、所定の時間内に次のメッセージ（ステップ１６）を受信しなければステップで確保した帯域を解放する（図７のステップ１３）。
【００４９】
ＡＣＫの送受信（図６のステップ１１、１２）を行ったSIPサーバは端末１と端末２間の呼を話中呼として管理している。また、この時点で端末１、２間の帯域幅が決定することから、図７のステップ１４において、SIPサーバはQoS確保リクエストをアクセスコントローラに送信する。その後は、QoS予約リクエストのシーケンス（図６のステップ３〜ステップ７）と同じシーケンス（図７のステップ１５〜ステップ１９）によって無線APでの帯域（リソース）確保がなされ、端末１、２間での音声通信が実行される（ステップ２０）。
【００５０】
図８は、図７のステップ２０の後、端末２から呼切断が行われる場合の処理を示すシーケンス図である。ステップ２１〜ステップ２４において、通常のSIPによる処理が行われることにより、SIPサーバは呼を切断する。ステップ２５において、SIPサーバはQoS解放リクエストをアクセスコントローラに送信する。アクセスコントローラは該当の無線APを抽出し（ステップ２６）、QoS解放リクエストを無線APに送信する（ステップ２７）。無線APは今までMS０１に対して確保していた帯域を解放し（ステップ２８）、QoS解放レスポンスをアクセスコントローラに返し（ステップ２９）、アクセスコントローラはQoS解放レスポンスをSIPサーバに返す（ステップ３０）。
【００５１】
図９〜図１１は、輻輳状態に無い無線APの配下の端末１が端末２に対して発信する場合のシーケンスを示す図である。発信端末と着信端末が入れ替わったことにより生じるSIPシーケンスの違いを除き図６〜図８と同じ処理が実行され、帯域予約、帯域確保、帯域解放が行われる。
【００５２】
次に、輻輳中の無線AP配下にある端末１に端末２から着信要求があった場合の動作例１を図１２を参照して説明する。
【００５３】
図１２におけるステップ１〜ステップ４は図６におけるステップ１〜ステップ４と同じである。無線APがアクセスコントローラからQoS予約リクエストを受信した後のステップ５において、無線APは、現在割り当て可能な帯域をほとんど割り当て済みであり、QoS予約リクエストに含まれる必要帯域幅を予約することができないと判定する。すると無線APは輻輳中であることを示すQoS予約レスポンスをアクセスコントローラに返す（ステップ６）。アクセスコントローラも同様のQoS予約レスポンスをSIPサーバに返し（ステップ７）、SIPサーバはこのQoS予約レスポンスに基づき無線APが輻輳中であると判定し、端末２にビジーを送信する（ステップ８）。
【００５４】
次に、輻輳中の無線AP配下にある端末１に端末２から着信要求があった場合の動作例２を図１３、１４を参照して説明する。図１２で説明した動作例１はSIPサーバが発信端末にビジーを返す例であるが、動作例２はSIPサーバが呼の転送を行う例である。この場合、SIPサーバには端末毎にその端末に対応する転送先端末を記録した転送先テーブルが登録されているものとする。また、転送先である端末３（URI３）は有線でネットワーク接続されたVoIP端末であるものとする。
【００５５】
図１３のステップ１〜ステップ７は図１２のステップ１〜ステップ７と同じである。輻輳中であることを示すQoS予約レスポンスをSIPサーバが受信すると、ステップ８において、SIPサーバは転送先テーブルを参照し、着信先である端末１（URI１）に対応する転送先URI３を取得する。そして、SIPサーバは着信先のURI３を指定したQoS予約リクエストをアクセスコントローラに送信する（ステップ９）。アクセスコントローラはURI３の端末３を配下に持つ無線APを探すが（ステップ１０）、データベースにそのような無線APが存在せず、その旨を示すQoS予約レスポンスをSIPサーバに返す（ステップ１１）。その後、SIPサーバは通常の転送のための呼接続処理を行い（図１４のステップ１２〜ステップ１６）、端末３と端末２間での音声通信が行われる（ステップ１７）。ステップ１８〜２１で呼が切断されると、ステップ２２においてSIPサーバはQoS解放リクエストをアクセスコントローラに送信するが（ステップ２２）、アクセスコントローラでは該当無線APは見出されず（ステップ２３）、その旨のQoS解放レスポンスがSIPサーバに送信される（ステップ２４）。
【００５６】
次に、輻輳中の無線AP配下にある端末１に端末２から着信要求があった場合の動作例３を図１５を参照して説明する。動作例３ではメディアサーバが備えられ、ステップ７において輻輳中であることを示すQoS予約メッセージをSIPサーバが受信した後に、メディアサーバと端末２間が接続され（ステップ８〜ステップ１２）、メディアサーバから「輻輳中ですので接続できません」等のガイダンスが端末２に流された後（ステップ１３）、呼が切断される（ステップ１４〜ステップ１７）。
【００５７】
次に、輻輳中の無線AP配下にある端末１に端末２から着信要求があった場合の動作例４を図１６〜１８を参照して説明する。動作例４は、端末１が無線AP輻輳により接続不可能の状態にあり、端末１が通信可能になるまで待ってもらうことを通知するガイダンスを端末２に流し、無線APの輻輳が解消して端末１が通信可能になると端末１と端末２を接続するものである。
【００５８】
ステップ７において、輻輳中であることを示すQoS予約レスポンスをSIPサーバが受信すると、SIPサーバは、発／着信URI、必要帯域幅、CallIDを含むQoS予約＋通知リクエストをアクセスコントローラに送信する（ステップ８）。QoS予約＋通知リクエストは、無線APに対してQoS予約を行おうとしている帯域を通知し、その帯域を確保できるだけの空きができたらその旨を通知するよう要求するためのメッセージである。
【００５９】
ステップ９においてアクセスコントローラは該当する無線APにQoS予約＋通知リクエストを送信する。QoS予約＋通知リクエストを受信した無線APは、MS０１に対して帯域予約があったことを認識し、帯域の監視を開始するとともに（ステップ１０）、QoS予約＋通知リクエストに対するレスポンスを返す（ステップ１１、１２）。
【００６０】
一方、発信元の端末２とメディアサーバとがSIPによる所定の手順で接続され（ステップａ〜ステップｆ）、端末２にガイダンスが流される（ステップ１３）。
【００６１】
図１７において、無線APは帯域幅の空きをチェックし（ステップ１４）、要求された帯域以上の帯域が空けばその旨の通知するためのメッセージであるQoS空き通知をアクセスコントローラに送信する（ステップ１５）。この通知には呼を識別するためのCallIDが含まれる。アクセスコントローラはQoS空き通知をSIPサーバに送信し（ステップ１６）、SIPサーバからQoS空きレスポンスが返される（ステップ１７、１９）。
【００６２】
次に、SIPの所定の手順により、端末２とメディアサーバ間のセッションが終了され（ステップ２０）、端末２から端末１に対する接続処理が開始される（ステップ２１）。その後の処理（ステップ２２〜図１８のステップ３９）は図６のステップ２〜図７のステップ２０の処理と同じである。
【００６３】
次に、図１９〜図２１を参照して、他の動作例として内線グループ一斉呼び出しを行う場合の接続動作を説明する。この例では、SIPサーバが代表番号と子番号集合とを対応付けた内線グループテーブルを保持している。また、URI０を代表番号とする内線グループの端末URI１、URI２、URI３が無線AP配下に存在するものとする。
【００６４】
図１９において、SIPサーバが端末４から代表番号（URI０）を着信先として含むINVITEを受信すると（ステップ１）、SIPサーバは内線グループテーブルを参照し、URI０に対応する子番号（URI１、URI２、URI３）を抽出し、それぞれを着信先とするQoS予約リクエストをアクセスコントローラに送信する（ステップ２〜ステップ４）。アクセスコントローラは着信先毎に対応する無線APの抽出を行い（ステップ５）、MSID、必要帯域幅、CallIDを含むQoS予約リクエストを無線APに送信するが、この例では全ての着信先が同一の無線APの配下にあるので、QoS予約リクエストは全て１つの無線APに送信される（ステップ６〜ステップ８）。なお、CallIDは全ての着信先で同一である。
【００６５】
さて、代表番号での呼び出しによりその代表に属する複数の端末が呼び出されるが、発信元と接続される端末は１つだけである。従って、ステップ９において無線APはCallIDに対応付けて１回線分の帯域を予約する。
【００６６】
その後、ステップ６〜ステップ８のそれぞれに対するレスポンス（ステップ１０）、及びステップ２〜ステップ４のそれぞれに対するレスポンスが返される（ステップ１１）。
【００６７】
その後、SIPサーバは内線グループに属するそれぞれの端末に対してINVITEを送信し、各端末を鳴らす（図２０のステップ１２〜１４）。図２０の例では端末３が応答し、端末３と端末４とが接続される（ステップ１５〜ステップ１８）。その後、図７のステップ１３〜ステップ１９と同様のシーケンスで、端末３に対する無線APにおける帯域確保処理が行われる（ステップ１９〜ステップ２５）。
【００６８】
一方、図２１に示すように、端末１にはINVITEをキャンセルするためのメッセージ送受信が実行される（ステップ２６〜ステップ２９）。そして、端末１を対象とするQoS解放リクエストがSIPサーバからアクセスコントローラに送られ（ステップ３０）、アクセスコントローラから無線APに送信される（ステップ３１）。無線APは端末１のエントリを削除し（ステップ３２）、リクエストに対するレスポンスが返される（ステップ３３、３４）。端末２に対しても端末１と全く同じ処理が行われる（ステップ３５〜ステップ４３）。
【００６９】
次に、図２２〜図２５を参照して、コールパークを行う場合の接続動作例を説明する。ここでは、端末１と端末２が通話中の状態において、端末１で保留操作が行われ、メディアサーバから端末２にガイダンスが流され、その後、端末２と端末３が接続される場合の例を示している。
【００７０】
図２２のステップ２において、端末１におけるパーク保留操作が行われる。これにより、SIPの所定の手順に従ってメディアサーバと端末２とが接続され（ステップ３〜ステップ１５）、ガイダンス送出が行われる（図２３のステップ１６）。その後に接続が切断され（ステップ１７〜ステップ２０）、無線APにおいて端末１に対して確保されていた帯域の解放が行われれる（ステップ２１〜ステップ３０）。
【００７１】
一方、SIPにおける所定の手順を経て（ステップ２７〜ステップ３０）、図２４のステップ３１においてSIPサーバが端末３からINVITEを受信した後、図９のステップ２〜図１０のステップ１９と同様にして端末３を対象とした無線APにおける帯域予約及び帯域確保を含む呼接続処理が実行され、端末３と端末２間で通話が行われる（図２５のステップ５０）。
【００７２】
次に、コールウェイティングを行う場合の接続動作例について図２６〜図２８を用いて説明する。
端末１と端末２が接続中の状態において（図２６のステップ１）、端末３が端末１への接続要求であるINVITEをSIPサーバに送信する（ステップ２）。そして、SIPサーバからQoS予約リクエストが送信され（ステップ３）、これまでに説明した帯域予約と同じ処理を経て、アクセスコントローラが端末１に対するQoS予約リクエストを該当無線APに送信する（ステップ４、５）。
【００７３】
無線APでは端末１に対して１回線分の帯域が既に確保されており、ここではもう１回線分の帯域が予約される（ステップ６〜ステップ８）。
【００７４】
端末１が２回線分のセッションを張れる場合、図２７に示すように、端末１では端末２との通話を保留し、端末１と端末３との間での接続がなされる（ステップ９〜ステップ２０）。端末１が１回線分のセッションのみを張れる場合、端末１がINVITEを受信した後（図２８のステップ９）、図２２、２３のステップ２〜ステップ３０で示した処理により端末２をパーク保留し、端末１と端末３との接続が行われる（図２８のステップ１１〜ステップ２１）。
【００７５】
（装置構成概要）
次に、上述した動作を実現するためにSIPサーバ、アクセスコントローラ、無線AP、コンソールが備える主要機能について説明する。図２９は、SIPサーバ４０、アクセスコントローラ３０、無線AP１０、コンソール５０の機能概要例を説明するための図である。
【００７６】
SIPサーバ４０は、SIPに基づく呼制御を行うための呼制御機能４１に加えて、端末のSIPサーバ（レジストラ）への登録／削除をトリガーにして、アクセスコントローラに対してURI登録（有効化）／削除（無効化）のリクエストを行い、SIPメッセージ（INVITE／ＢＹＥ／レスポンスなど）をトリガーにして、アクセスコントローラに対して、QoS予約／確保／解放のリクエストを行う等の機能を有する対アクセスコントローラインタフェース機能４２を有している。
【００７７】
アクセスコントローラ３０は、SIPサーバ４０から受信した上記各リクエストに対応する処理を行い、回答（ＯＫ／ＮＧ）をSIPサーバに対して送信する対SIPサーバインタフェース機能３１、無線APに設定された上限リソースに基づき輻輳判定を行う判定機能３２、無線APから受信した端末登録／削除のリクエストに対応する処理を行う対無線APインタフェース機能３３、コンソールからの入力に応じて（ａ）端末MACアドレスとSIP−URIの対、（ｂ）無線APの最大リソース量等をデータベース３５に設定する対コンソールインタフェース機能３４、及びデータベース３５を有している。なお、この例はアクセスコントローラが各無線APの帯域を管理する場合の例である。
【００７８】
また、無線AP１０は無線AP本来の無線AP機能１１に加え、端末の無線APへの接続／切断をトリガーに、アクセスコントローラ３０に対して端末登録／削除のリクエストを行う対アクセスコントローラインタフェース機能１２を有している。
【００７９】
コンソール５０は操作者の入力を受け付けるユーザインタフェース機能５１と、設定情報をアクセスコントローラに送信する対アクセスコントローラインタフェース機能５２を有している。
【００８０】
SIPサーバ、アクセスコントローラはそれぞれＣＰＵ、記憶装置、通信用装置等を備えたコンピュータに上記各機能を実現するためのプログラムを搭載することにより実現されるものである。
【００８１】
次に、アクセスコントローラ３０が保持するデータベース３５内の端末管理データと無線AP管理データを説明する。
【００８２】
図３０に端末管理データの例を示す。ここで示す例では端末MACアドレスと端末SIP−URIとを対応付けて予めアクセスコントローラ３０のデータベース３５に固定値として登録しておく。そして、図６等で説明したシーケンスにより送受信されるデータに基づき、無線状態、呼状態、CallID、接続APを随時記録することにより端末を管理する。
【００８３】
図３０に示すデータにおける「無線状態」は端末と無線APとの接続状態を示すデータであり、端末と無線APとが接続状態にあるときは"Link Up"が記録され、切断状態にあるときは"Link Down"が記録される。また、接続状態にあるときの無線APのIDが「接続AP」に記録される。
【００８４】
「呼状態」は呼の状態を示すデータであり、呼接続無しで登録されている状態では"Register"が記録され、登録が削除された状態では"Unregister"が記録される。また、QoS予約リクエストをSIPサーバから受信し、QoS予約レスポンスをSIPサーバに返すまでのQoS予約中の状態では"QoS予約中"が記録され、QoS予約レスポンスをSIPサーバに返してからQoS確保リクエストを受信するまでは"QoS予約済"が記録され、QoS確保リクエストを受信してから、QoS確保レスポンスをSIPサーバに返すまでのQoS確保中の状態では"QoS確保中"が記録され、QoS確保レスポンスをSIPサーバに返してからQoSが確保されている状態では"QoS確保済"が記録される。
【００８５】
「CallID」は、「SIP状態」がQoS予約中／QoS予約済／QoS確保中／QoS確保済の場合にデータが記録されるものであり、呼（SIPセッション）毎のCallIDを設定する。このCallIDは一斉着信時の呼のグループ化及びQoS空きNotify()の呼の特定で利用される。
【００８６】
図３０に示したデータを参照することにより、アクセスコントローラはどの呼がどの無線APのリソースを消費するか判断できる。
【００８７】
図３１に無線AP管理データの例を示す。APIDとリソース上限値が予め登録される固定値データであり、利用中リソース量が随時変更されるデータである。
【００８８】
図３１における「APID」は無線AP毎に一意なIDであり、端末管理データの「接続AP」に登録される情報と同じものである。「リソース上限値」は無線APで利用可能なリソース上限値である。「リソース利用量」は無線APで現在使われているリソース量であり、無線APに接続された端末の呼数に応じて動的に変化するものである。この情報と「リソース上限値」との差分により、空きのリソース量を判定でき、当該無線APが輻輳するか否かを判断できる。
【００８９】
なお、無線APが無線AP管理データを保持してもよい。無線APがこの無線AP管理データを保持する場合には、無線APが輻輳判定を行い輻輳判定結果がアクセスコントローラに送信されることになる。一方、アクセスコントローラがこのデータを保持することにより、無線APに輻輳判定等の機能を設ける必要がなくなる。他の実施の形態でも同様である。
【００９０】
（アクセスコントローラ詳細機能構成）
次に、アクセスコントローラ３０の詳細機能構成を図３２を用いて説明する。図３２に示す例は輻輳判定等の無線APリソース管理をアクセスコントローラ３０が行う場合の例である。図３２に示すように、アクセスコントローラ３０はデータベース３５、SIP連携Ｉ／Ｆ６０、リソース管理機能７０、データ管理機能８０、無線AP管理機能９０、端末管理機能１００、無線AP連携Ｉ／Ｆ１１０を有している。
【００９１】
以下、各機能部の機能についてより詳細に説明する。
【００９２】
SIP連携Ｉ／Ｆ６０はSIP要求受付部６１、SIP要求返却部６２、SIP通知部６３を有している。
【００９３】
SIP要求受付部６１は端末登録要求受付部６４とリソース要求受付部６５を有している。端末登録要求受付部６４はレジストラから端末登録要求を受け付ける。また、端末登録情報を端末登録部（アプリケーション層）１０１に渡す。リソース要求受付部６５はSIPサーバ４０からリソース要求を受け付け、リソース要求種別（予約／予約＋通知／確保／解放）に応じて、リソース予約／解放部７１にリソース操作を要求する。リソース要求種別が"予約＋通知"の場合は、リソース状態変化監視部７２にリソース監視を要求する。
【００９４】
SIP要求返却部６２は端末登録要求返却部６６とリソース要求返却部６７を有しており、端末登録要求返却部６６は端末登録要求受付部６４へのリクエストの結果をレジストラに返却し、リソース要求返却部６７はリソース要求受付部６５へのリクエスト結果をSIPサーバ４０に返却する。
【００９５】
SIP通知部６３はリソース状態変化通知部６８を有しており、リソース状態変化通知部６８はリソース状態変化監視部７２からの要求に応じて、SIPサーバ４０に対してQoS空きNotify()通知を行う。
【００９６】
リソース管理機能７０はリソース予約／解放部７１とリソース状態変化監視部７２を有している。リソース予約／解放部７１はリソース要求種別（予約／確保／解放）に応じて、データ更新部８１にリソース操作を要求する。また、空きリソース量に応じて、輻輳判断も行う。例えば、上限リソース量から使用中リソース量を減算した値が、要求されたリソース量以下である場合に輻輳中であると判断する。リソース状態変化監視部７２は無線APの空きリソースを監視し、空きに状態に遷移した時に、リソース状態変化通知部６８に対して空きを通知する。
【００９７】
データ管理機能８０はデータ更新部８１を有している。データ更新部８１はデータベース３５のデータ読み出し／追加／更新／削除を行う。また、SIP−URIと端末MACアドレスとの相互変換を行う。無線AP管理機能９０は無線AP／リソース登録部９１を有している。無線AP／リソース登録部９１は無線APの登録及び当該無線APに対するリソース上限値をコンソール５０からの指示に基づきデータベース３５に設定する。
【００９８】
端末管理機能１００は端末登録部（アプリケーション層）１０１と端末登録部（データリンク層）１０２を有している。端末登録部（アプリケーション層）１０１は端末登録要求受付部６４から、リソース管理対象端末のSIP−URIを受け取り、データ更新部８１に対してデータ登録を要求する。当該処理により、SIP−URIが本システムで有効化される。また、端末登録部（データリンク層）１０２は端末MAC登録要求受付部１１１から、リソース管理対象端末のMACアドレスを受け取り、データ更新部８１に対してデータ登録を要求する。当該処理により、端末MACアドレスが本システムで有効化される。
【００９９】
無線AP連携Ｉ／Ｆ１１０は端末MAC登録要求受付部１１１を有している。端末MAC登録要求受付部１１１は無線APで発生する端末イベント（Association/Disassociation/Reassociation）を契機として、イベントを受け付け、当該イベントの種別に応じて、端末登録部（データリンク層）１０２に対して、端末MACアドレスの登録／削除／再登録を要求する。
【０１００】
なお、上述した機能構成は一例に過ぎない。本実施の形態で説明した動作を実現できる構成であればどのような構成でもよい。このことは他の実施の形態についても同様である。
【０１０１】
＜第２の実施の形態＞
次に、本発明の第２の実施の形態について説明する。第２の実施の形態では、ハンドオーバ時の問題を解決するための方式について説明する。
【０１０２】
第１の実施の形態では、無線APにおける呼の帯域確保はSIPシーケンスを契機として行われるが、ハンドオーバ時には呼の開始／終了を伴わないため、SIPシーケンスは発生しない。そこで、第２の実施の形態では、無線リンク再接続要求（Reassociation）を契機として移動先無線APの帯域確保等を行っている。
【０１０３】
ある無線AP１０を介して他の端末２と通話中の端末１が他の無線AP２０の配下に移動することによりハンドオーバする際の本実施の形態におけるシステムの全体動作フローを図３３を参照して説明する。
【０１０４】
端末１が他の無線AP２０の配下に移動し、移動先の無線AP２０が輻輳中でなければ（ステップ１のNo）、ハンドオーバは完了する（ステップ２）。移動先の無線AP２０が輻輳中の場合（ステップ１のYes）、当該無線AP２０は端末１との無線リンクを切断し、端末に対して隣接無線AP２５に接続するよう促し、端末１は隣接無線APへの無線リンク接続を行う（ステップ４）。ただし、無線リンク切断／接続リトライは予め定めたリトライ回数まで行い、リトライ回数が予め定めた規定値に達した場合には（ステップ３のYes）、アクセスコントローラはハンドオーバ失敗であると判定し、通話相手の端末に対し、ガイダンスを送出するなどの呼処理を実施する（ステップ５）。
【０１０５】
なお、本実施の形態において、輻輳中の無線AP２０に隣接する無線APとは、無線AP２０の配下に存在する端末から見て、電波到達範囲がVoIP通信時に通信品質が保てる範囲にある無線AP２０以外の無線APの他、端末がある程度移動することにより、電波到達範囲がVoIP通信時に通信品質が保てる範囲となる無線APを含むものとする。このことは、第３の実施の形態でも同様である。
【０１０６】
次に、図３４を参照して、移動先の無線AP２０が輻輳状態にある場合に、すぐに端末２に対する呼処理を行う場合を例にとり、本実施の形態におけるシステムの動作の概要について説明する。基本的なシステム構成は第１の実施の形態におけるシステム構成と同じであり、図３４では、アクセスコントローラ３０に無線AP１０と無線AP２０が接続され、端末１が無線AP１０の配下から無線AP２０の配下に移動する場合を示している。図３４の例では、移動先の無線AP２０が輻輳状態にあるものとする。
【０１０７】
まず、端末１は無線AP１０を介して端末２と通話中であるものとする（ステップA）。そして、端末１が無線AP２０の配下に移動すると、ハンドオーバの機能により、端末１は無線AP２０に対して再接続要求を送信する（ステップB）。この要求を契機として、アクセスコントローラ３０は、無線AP１０に対して端末１に対して割り当てられていた帯域を解放するための帯域解放要求を送信し、無線AP１０は帯域を解放する（ステップC）。
【０１０８】
また、アクセスコントローラ３０は、無線AP２０に帯域確保要求を送信するが、図３４の状態では無線AP２０は輻輳状態にあるため、帯域確保に失敗する（ステップD）。すると、アクセスコントローラ３０はハンドオーバ失敗通知をSIPサーバ４０に送信し（ステップE）、SIPサーバ４０は端末２に対して呼処理を実施する（ステップF）。
【０１０９】
以下、本実施の形態における処理の詳細を図３５〜図４８を参照して説明する。なお、図３５〜図４８において、レジスターはSIPサーバに含まれているものとする。また、アクセスコントローラが保持する端末管理データを、呼状態管理テーブルとして示している。また、動作の前提として、保守端末からアクセスコントローラに、リトライ規定値（上限値）と、再接続要求拒否時間が登録されるものとする。この登録は、端末毎にしてもよいし、全ての端末に共通の値として設定してもよい。また、無線AP毎に設定してもよい。
【０１１０】
まず、図３５〜図３７を参照して移動先の無線AP２０が輻輳中でない場合について説明する。
【０１１１】
図３５において、端末１と端末２の間で、第１の実施の形態で説明したシーケンス（図６のステップ１〜図７のステップ１９等）を実施したことにより通信がなされているものとする（ステップ１）。ここで、端末１が無線AP１０の配下から無線AP２０の配下に移動する（ステップ２）。端末１は再接続要求（Reassociation）を無線AP２０に送信し（ステップ３）、無線AP２０は端末１のMACアドレス（MSID）を取得し、登録する（ステップ４）。無線AP２０は無線AP２０のID（AP０２）と端末１のMACアドレス（MS０１）とを含む端末登録リクエストをアクセスコントローラに対して送信する（ステップ５）。アクセスコントローラは無線AP２０から受信した無線AP２０のID（AP０２）を端末１のMACアドレス（MS０１）と対応付けて記憶装置に格納することにより登録の更新を行う（ステップ６）。なお、現時点での端末１に対する呼状態は"QoS確保済"である。そして、アクセスコントローラは無線AP２０に対して端末登録レスポンスを返す（ステップ７）。
【０１１２】
本実施の形態では、アクセスコントローラは、「QoS確保済」である端末に関する端末登録リクエストを受信した場合は、SIPサーバからのトリガーを受けることなく、ハンドオーバ前の無線AP１０に対して、当該端末１に関するQoS解放リクエストを送信する（ステップ８、９）。このリクエストを受けた無線AP１０は、端末１に対する帯域を解放し、QoS解放レスポンスをアクセスコントローラに送信する（ステップ１０、１１）。
【０１１３】
続いて、アクセスコントローラは、MS０１と必要帯域幅を含むQoS確保リクエストを無線AP２０に送信する（ステップ１２）。なお、端末１と端末２の間で必要な帯域幅は既に確定しているため、QoS予約シーケンスは実施しない。
【０１１４】
ステップ１３にて、無線AP２０において端末１に対する帯域確保がなされ、QoS確保レスポンスがアクセスコントローラに送信される（ステップ１４）。その後、無線AP２０を介して端末１と端末２間での通話が行われる。
【０１１５】
ステップ１６からの処理は呼切断の処理を示している。ステップ１６〜ステップ１９において、通常のSIPによるシーケンス処理が行われることにより、SIPサーバは呼を切断する。ステップ２０において、SIPサーバはQoS解放リクエストをアクセスコントローラに送信する。アクセスコントローラは該当の無線AP２０を抽出し（ステップ２１）、QoS解放リクエストを無線AP２０に送信する（ステップ２２）。無線AP２０は今までMS０１に対して確保していた帯域を解放し（ステップ２３）、QoS解放レスポンスをアクセスコントローラに返し（ステップ２４）、アクセスコントローラは、端末１に対する「呼状態」を"無し"にするとともに、QoS解放レスポンスをSIPサーバに返す（ステップ２５）。
【０１１６】
次に、最初の移動先の無線AP２０が輻輳中であるが、隣接無線AP２５に接続することによりハンドオーバが成功する場合の動作例を図３８〜図４０を参照して説明する。
【０１１７】
図３８のステップ２〜図３９のステップ１１において、図３５のステップ２〜ステップ１１と同様にしてアクセスコントローラに無線AP２０についての端末登録がなされ、無線AP１０に対する帯域解放がなされる。
【０１１８】
図３９のステップ１１で、QoS解放レスポンスを受信したアクセスコントローラは、端末１に対する呼状態を"ハンドオーバ中"にする。そして、アクセスコントローラは、QoS確保リクエストを無線AP２０に送信する（ステップ１２）。ここでは、無線AP２０は、現在割り当て可能な帯域をほとんど割り当て済みであり、QoS確保リクエストに含まれる必要帯域幅を予約することができないと判定する（ステップ１３）。すると無線AP２０は、輻輳中であることを示すQoS確保レスポンスをアクセスコントローラに返す（ステップ１４）。
【０１１９】
アクセスコントローラは、ハンドオーバ後において、無線APが輻輳中であった回数をカウントする。つまり、ステップ１５では、"１"をカウントする。この"１"は、１回リトライに失敗したことを示す。なお、この例では、最初のハンドオーバを行って、移動先の無線APに接続することも"リトライ"に入れているが、最初のハンドオーバに失敗した後のリトライからカウントを開始することとしてもよい。そして、この数値と予め定めた数値とを比較し、この数値が予め定めた数値に達していた場合は、後述する呼処理に移る。このような判定処理は、リトライが永久に続くことを防止するために行われる。図３９の場合は、予め定めた数値は１より大きい数値であるものとし、１回目のリトライ失敗であるから、呼処理に移行せずに、再接続のための処理に移行する。
【０１２０】
ステップ１６にて、アクセスコントローラは、MS０１と再接続要求拒否時間を含む無線リンク切断要求を無線AP２０に送信する。無線AP２０は、端末１に対する再接続要求拒否時間を設定する（図４０のステップ１７）。これにより、無線AP２０は、端末１から再度接続要求を受けた場合でも、再接続要求拒否時間内であれば、その接続要求を拒否する。つまり、接続要求を受けてもその後の動作を行わない。
【０１２１】
無線リンク切断要求を受信した無線AP２０は、無線リンク切断指示（Disassociation）を端末１に送信することにより無線リンクを切断する（ステップ１８）。無線リンクを切断された端末１は、無線AP２０に隣接する無線APである無線AP２５に接続要求（Association）を送信する。なお、端末１の仕様によっては、再度数回無線AP２０への接続を試み、接続に失敗した場合に隣接無線APへの接続を行う場合があるが、再接続要求拒否時間の間は、無線AP２０から再度端末登録リクエストが送信されることはない。
無線AP２５は端末１のMACアドレス（MSID）を取得し、登録する（ステップ２０）。無線AP２５は無線AP２５のID（AP０３）と端末１のMACアドレス（MS０１）とを含む端末登録リクエストをアクセスコントローラに対して送信する（ステップ２１）。アクセスコントローラは無線AP２５から受信した無線AP２５のID（AP０３）を端末１のMACアドレス（MS０１）と対応付けて記憶装置に格納することにより登録の更新を行う（ステップ２２）。そして、アクセスコントローラは無線APに対して端末登録レスポンスを返す（ステップ２３）。
【０１２２】
本実施の形態では、アクセスコントローラは、「ハンドオーバ中」である端末に関する端末登録リクエストを受信した場合は、SIPサーバからのトリガーを受けることなく、端末登録リクエストを送信した無線AP２５に対して、MS０１と必要帯域幅を含むQoS確保リクエストを送信する（ステップ２４、２５）。
【０１２３】
ステップ２６にて、無線AP２５において端末１に対する帯域確保がなされ、QoS確保レスポンスがアクセスコントローラに送信される（ステップ２７）。アクセスコントローラは端末１に対する「呼状態」を"QoS確保済"とし、その後、無線AP２５を介して端末１と端末２間での通話が行われる。呼切断の処理は図３６、３７で説明した処理と同様である。
【０１２４】
次に、図４１〜図４２を参照して、端末１がハンドオーバに失敗し、通話相手端末に対する呼制御が行われる場合の動作例１を説明する。
【０１２５】
移動先の無線AP２０が輻輳中であることから、図３８のステップ２〜図４０のステップ２５までの処理が行われたものとする。
【０１２６】
ステップ２５において、QoS確保リクエストを受信した無線AP２５は、現在割り当て可能な帯域をほとんど割り当て済みであり、QoS確保リクエストに含まれる必要帯域幅を予約することができないと判定する（図４１のステップ２６）。すると無線AP２５は輻輳中であることを示すQoS確保レスポンスをアクセスコントローラに返す（ステップ２７）。
【０１２７】
本動作例１では、リトライ回数の規定値が２と設定されているものとする。図４２のステップ２８において、アクセスコントローラはリトライ回数のカウント値を"２"とし、規定値と比較し、リトライ回数が規定値に達したと判定したため、呼状態管理テーブルの「呼状態」を"無し"に変更する。
【０１２８】
そして、アクセスコントローラは、端末１のURLであるURL１と、ハンドオーバの失敗理由である"輻輳"を含むハンドオーバ失敗通知をSIPサーバに送信する。本動作例１では、ハンドオーバ失敗通知を受信したSIPサーバは、Byeにより正常終了処理を行う（ステップ３０〜ステップ３３）
ハンドオーバ失敗通知を受領した後のSIPサーバの動作には種々のバリエーションがあり、これらのバリエーションのうちどの動作を用いるかは、SIPサーバに予め設定しておくことができる。
次に、ハンドオーバ失敗通知を受領した後のSIPサーバの動作例２を図４３、４４を参照して説明する。図４３、４４では、無線AP２０が輻輳したときにハンドオーバ失敗と判定する例を示している。ハンドオーバ失敗通知をSIPサーバに送信するまでの処理についてはこれまでに説明したとおりである。
【０１２９】
動作例２では、端末１から他の端末への転送が行われる。本動作例では、第１の実施の形態における図１３で示した場合と同様に、SIPサーバには端末毎にその端末に対応する転送先端末を記録した転送先テーブルが登録されているものとする。また、端末１の転送先である端末３（URI３）は有線でネットワーク接続されたVoIP端末であるものとする。
【０１３０】
端末１からByeに対する応答を受信した後（図４３のステップ３）、SIPサーバは、転送先テーブルを参照し、着信先である端末１（URI１）に対応する転送先URI３を取得する（ステップ４）。そして、SIPサーバは、端末２に対して端末３への接続換えを要求するSIPシーケンスを実行し（ステップ５〜ステップ８）、着信先のURI３を指定したQoS予約リクエストをアクセスコントローラに送信する（ステップ９）。アクセスコントローラはURI３の端末３を配下に持つ無線APを探すが（ステップ１０）、データベースにそのような無線APが存在せず、その旨を示すQoS予約レスポンスをSIPサーバに返す（ステップ１１）。その後、SIPサーバは通常の転送のための呼接続処理を行い（図４４のステップ１２〜ステップ１６）、端末３と端末２間での音声通信が行われる（ステップ１７）。ステップ１８〜２１で呼が切断されると、ステップ２２においてSIPサーバはQoS解放リクエストをアクセスコントローラに送信するが（ステップ２２）、アクセスコントローラでは該当無線APは見出されず（ステップ２３）、その旨のQoS解放レスポンスがSIPサーバに送信される（ステップ２４）。
次に、ハンドオーバ失敗通知を受領した後のSIPサーバの動作例３を図４５を参照して説明する。
動作例３ではメディアサーバが備えられ、ステップ３においてByeに対する応答をSIPサーバが受信した後に、メディアサーバと端末２間が接続され（ステップa〜ステップi）、メディアサーバから「輻輳中ですので接続できません」等の終話を促すガイダンスが端末２に流された後（ステップj）、端末２からの終話によって呼が切断される（ステップk〜ステップn）。
次に、ハンドオーバ失敗通知を受領した後のSIPサーバの動作例４を図４６〜図４８を参照して説明する。
動作例４では、端末１が通信可能になるまで待ってもらうことを通知するガイダンスを端末２に流し、無線AP２０の輻輳が解消して端末１が通信可能になったら端末１と端末２を接続するものである。
【０１３１】
ステップ３において、Bye に対する応答をSIPサーバが受信すると、SIPサーバは、発／着信URI、必要帯域幅、CallIDを含むQoS予約＋通知リクエストをアクセスコントローラに送信する（ステップ４）。QoS予約＋通知リクエストは、無線APに対してQoS予約を行おうとしている帯域を通知し、その帯域を確保できるだけの空きができたらその旨を通知するよう要求するためのメッセージである。
【０１３２】
ステップ５においてアクセスコントローラは該当する無線AP２０にQoS予約＋通知リクエストを送信する。QoS予約＋通知リクエストを受信した無線AP２０は、MS０１に対して帯域予約があったことを認識し、帯域の監視を開始するとともに（ステップ６）、QoS予約＋通知リクエストに対するレスポンスを返す（ステップ７、８）。
【０１３３】
一方、端末２とメディアサーバとがSIPによる所定の手順で接続され（ステップａ〜ステップi）、端末２に、無線AP２０のリソースが空くまで待機中であることを通知するためのガイダンスが流される（ステップj）。
【０１３４】
図４７において、無線AP２０は帯域幅の空きをチェックし（ステップ９）、要求された帯域以上の帯域が空けばその旨の通知するためのメッセージであるQoS空き通知をアクセスコントローラに送信する（ステップ１０）。この通知には呼を識別するためのCallIDが含まれる。アクセスコントローラはQoS空き通知をSIPサーバに送信し（ステップ１１）、SIPサーバからQoS空きレスポンスが返される（ステップ１２〜１４）。
【０１３５】
次に、SIPサーバは、端末２に、端末１への再接続のためのSIPメッセージを送信し、接続替えのためのSIPシーケンスを実行する（ステップ１５〜ステップ１９）。そして、第１の実施の形態における、端末２から端末１への着信の場合と同様の手順を経て（図４７のステップ２０〜図４８のステップ３６）、端末１と端末２間での通話が行われる（ステップ３７）。
【０１３６】
（装置構成について）
第２の実施の形態における装置の機能概要を図４９を参照して説明する。第２の実施の形態における装置の基本的な構成は第１の実施の形態における装置構成と同様である。以下、第１の実施の形態の装置と異なる主な点について説明する。
【０１３７】
SIPサーバ４０における呼制御機能４１は、ハンドオーバ失敗時の呼制御処理を実行する機能も有している。アクセスコントローラ３０は、第１の実施の形態で説明した機能に加えて、無線リンクリトライ判定機能３６とハンドオーバ成否判定機能３７を有している。無線リンクリトライ判定機能３６は、無線リンクリトライの失敗回数をカウントし、予め設定した回数に達したかどうかの判定を行う。ハンドオーバ成否判定機能３７は、端末のハンドオーバ時にハンドオーバが成功したかどうかの判定を行う。具体的には、無線リンクリトライ判定機能３６により、無線リンクリトライの失敗回数が予め設定した回数に達したと判定された場合に、ハンドオーバに失敗したと判定し、その旨をSIPサーバ４０に通知する。また、本実施の形態における判定機能３２は、端末の呼接続要求時に無線APの輻輳判定を行う機能も有している。
【０１３８】
図５０に、本実施の形態での端末管理データを示す。本実施の形態では、呼状態として、「ハンドオーバ中」を含む。アクセスコントローラは、ハンドオーバ時において、ハンドオーバ前の無線APにおける帯域が解放されたことに応じて呼状態を「ハンドオーバ中」とする。そして、ハンドオーバ時において、ハンドオーバ先の無線APでの帯域が確保されたことに応じて、呼状態を「ハンドオーバ中」から「QoS確保済」にする。
【０１３９】
また、本実施の形態における端末管理データは、端末毎の無線リンクリトライ回数（上限値）と、実際の無線リンクリトライ回数を含む。実際の無線リンクリトライ回数が上限値に達した場合にハンドオーバ失敗と判定される。
【０１４０】
図５１に、本実施の形態における再接続要求拒否時間管理用の無線AP管理データを示す。図５１に示すように、無線AP毎及び端末毎に、再接続要求拒否時間と、無線リンクを切断してから実際に経過した時間である再接続要求拒否経過時間が記録される。
【０１４１】
図５２に、本実施の形態におけるアクセスコントローラの詳細機能構成図を示す。以下、第１の実施の形態と異なる部分について説明する。
【０１４２】
SIP要求返却部６２は、ハンドオーバ失敗であることをSIPサーバに通知するハンドオーバ失敗通知部６９を有する。また、リソース予約／解放部７１は、第１の実施の形態の機能に加え、端末のハンドオーバ時に、無線APのリソースを調べ、輻輳状態かどうかを判定する機能を有している。また、リソース管理機能７０は、ある端末の無線リンクリトライ回数が、予め定めた上限値に達したかどうかを判定する無線リンクリトライ判定部７３を有している。
【０１４３】
また、データ更新部８１は、第１の実施の形態で説明した機能に加え、端末のハンドオーバ時に、移動元無線APのリソース解放後、端末の呼状態を「ハンドオーバ中」とする機能を備えている。また、無線AP連携I／F１１０は、無線リンク切断要求部１１２を有している。無線リンク切断要求部１１２は、ハンドオーバ時に、再接続先の無線APのリソースが確保できなかった際に、端末を他の隣接無線APへ再接続させるために、再接続先の無線APに無線リンク切断要求を送信するものである。
【０１４４】
＜第３の実施の形態＞
次に、本発明の第３の実施の形態について説明する。第１の実施の形態では、輻輳中の無線APに接続された端末に対して他の端末から着信があった場合に、当該他の端末に対してガイダンスを流す等の呼制御を行う例を説明した。
【０１４５】
ある無線APが輻輳していても、隣接する無線APは輻輳中でない場合があるが、第１の実施の形態では隣接する無線APを有効に活用できていない。そこで、本実施の形態では、輻輳中の無線APに隣接する無線APを用いて通信を継続する例について説明する。
【０１４６】
まず、図５３を参照して、輻輳中の無線AP１０に接続された端末１に端末２から着信があった場合のシステムの動作概要について説明する。
【０１４７】
まず、端末１は無線AP１０と無線リンクで接続中であるものとする。端末２が端末１に対する接続要求を送信すると（ステップA）、SIPサーバ４０は帯域予約要求をアクセスコントローラ３０に送信する（ステップB）。アクセスコントローラ３０は、無線AP１０に対して帯域予約要求を送信するが、無線AP１０は輻輳中であるため帯域予約に失敗する（ステップC）。そして、アクセスコントローラ３０は、端末１が隣接無線APへ切替中である旨をSIPサーバ４０に通知する（ステップD）。その後、アクセスコントローラ３０は端末１に対する無線リンク切断要求を無線AP１０に送信し、無線AP１０は端末１との無線リンクを切断する（ステップE）。
【０１４８】
無線AP１０との無線リンクを切断された端末１は、隣接無線AP２０と無線リンク接続する（ステップF）。すると、アクセスコントローラ３０は、無線AP２０からの端末登録要求に応じて無線AP２０に対する帯域予約を行い、帯域予約に成功すると（ステップG）、SIPサーバ４０にその旨を通知し（ステップH）、SIPサーバ４０は呼接続シーケンスを再開し、端末１と端末２が接続される（ステップI）。
【０１４９】
次に、図５４を参照して、輻輳中の無線AP１０に接続された端末１が端末２に発信する場合におけるシステムの動作概要を説明する。
【０１５０】
まず、端末１は無線AP１０と無線リンクで接続中であるものとする。端末１が端末２に対する接続要求を送信すると（ステップA）、帯域予約要求が送信されるが（ステップB）、無線AP１０は輻輳中であるため帯域予約に失敗する（ステップC）。また、アクセスコントローラ３０は、SIPサーバ４０に対して、端末１が隣接無線APへ切替中である旨を通知する（ステップD）。
【０１５１】
すると、SIPサーバ４０は、端末１に対して呼接続のキャンセル通知を行うとともに（ステップE）、アクセスコントローラ３０は、無線AP１０に、端末１に対する無線リンク切断要求を送信し、無線AP１０が端末１との無線リンクを切断する（ステップF）。
【０１５２】
無線リンクを切断された端末１は、隣接無線AP２０と無線リンク接続する（ステップG）。そして、端末１に対してユーザによる操作がなされることにより、端末１は端末２に対する接続要求を送信する（ステップH）。そして、帯域確保が行われて（ステップI）、端末１と端末間の呼が確立される（ステップJ）。なお、上記の方式では、一度呼を切断しているが、端末１の機能により、呼の切断を行わずに呼を継続することも可能である。
【０１５３】
以下、本実施の形態におけるシステムの動作を詳細に説明する。
【０１５４】
本実施の形態において、無線APが輻輳中でない場合において、端末２から端末１に着信があった場合の動作は第１の実施の形態において図６〜図８に示したとおりである。
【０１５５】
また、無線APが輻輳中でない場合において、端末１から端末２に発信がなされた場合における動作は第１の実施の形態において図９〜図１１に示したとおりである。
【０１５６】
輻輳中の無線AP１０に隣接して、輻輳中でない無線AP２０が存在する環境の下で、無線AP１０に接続された端末１に端末２から着信があった場合のシステムの動作について図５５〜図５７を参照して詳細に説明する。
図５５におけるステップ１〜ステップ４は図６におけるステップ１〜ステップ４と同じである。無線AP１０がアクセスコントローラからQoS予約リクエストを受信した後のステップ５において、無線AP１０は、現在割り当て可能な帯域をほとんど割り当て済みであり、QoS予約リクエストに含まれる必要帯域幅を予約することができないと判定する。すると無線AP１０は輻輳中であることを示すQoS予約レスポンスをアクセスコントローラに返す（ステップ６）。アクセスコントローラは、呼状態管理テーブルにおける端末１の呼状態を「隣接無線APへ切替中」とし、端末１が隣接無線APへ切替中であることを示す情報を含むQoS予約レスポンスをSIPサーバに返す（ステップ７）。
【０１５７】
アクセスコントローラは、端末が無線APに接続後、無線APが輻輳中であった回数をカウントする。つまり、ステップ８では、"１"をカウントする。この"１"は、１回リトライに失敗したことを示す。なお、この例では、最初の接続を行うことも"リトライ"に入れているが、最初の接続に失敗した後のリトライからカウントを開始することとしてもよい。そして、この数値と予め定めた数値とを比較し、この数値が予め定めた数値に達していた場合は、後述する呼処理に移る。このような判定処理は、リトライが永久に続くことを防止するために行われる。図５５の場合は、予め定めた数値は１より大きい数値であるものとし、１回目のリトライ失敗であるから、再接続のための処理に移行する。
【０１５８】
図５６のステップ９にて、アクセスコントローラは、MS01と再接続要求拒否時間を含む無線リンク切断要求（隣接無線AP移動指示に相当する）を無線AP１０に送信する。無線AP１０は、端末１に対する再接続要求拒否時間を設定する（ステップ１０）。これにより、無線AP１０は、端末１から再度接続要求を受けた場合に、再接続要求拒否時間内であれば、その接続要求を拒否する。つまり、接続要求を受けても接続動作を行わない。
【０１５９】
無線リンク切断要求を受信した無線AP１０は、無線リンク切断指示（Disassociation）を端末１に送信することにより無線リンクを切断する。無線リンクを切断された端末１は、隣接する無線APである無線AP２０に接続要求（Association）を送信する（ステップ１２）。なお、端末１の仕様によっては、無線AP１０への接続を再度試みる場合があるが、その場合でも、再接続要求拒否時間の間は、無線AP１０から再度端末登録リクエストが送信されることはない。
【０１６０】
無線AP２０は、端末１のMSIDであるMS01を登録する（ステップ１３）。そして、無線AP２０は無線AP２０のID（AP０２）と端末１のMACアドレス（MS０１）とを含む端末登録リクエストをアクセスコントローラに対して送信する（ステップ１４）。アクセスコントローラは無線AP２０から受信した無線APのID（AP０２）と端末１のMACアドレス（MS０１）とを記憶装置に格納することにより、MSIDとAPIDの更新を行う。（ステップ１５）。そして、アクセスコントローラは無線AP２０に対して端末登録レスポンスを返す（ステップ１６）。アクセスコントローラは、端末１に対する呼状態を"無し"にする（ステップ１７）。
【０１６１】
その後、無線AP２０に関し、帯域予約が行われ（図５７のステップ１８〜２１）、図６のステップ８〜図７のステップ１９と同様の処理が実行されて、端末１と端末２間での呼接続が行われる。
【０１６２】
次に、無線AP１０が輻輳中であるとともに、隣接無線AP２０も輻輳中であり、呼の中断を行う場合の動作を図５８を参照して説明する。
【０１６３】
端末２からのINVITE送信から、無線AP２０及びアクセスコントローラに対する端末再登録までの処理は図５５、図５６に示した処理と同じである。
【０１６４】
図５８において、アクセスコントローラは、無線AP２０に対してQoS予約リクエストを送信する（ステップ１８）。無線AP２０は輻輳中なので、輻輳中であることを示すQoS予約レスポンスをアクセスコントローラに返す（ステップ１９、２０）。アクセスコントローラは、現在のリトライ回数と、リトライ回数の上限値とを比較し、現在のリトライ回数（＝２）が予め規定したリトライ回数（＝２）に達したと判定し、リトライを失敗したと判定する（ステップ２１）。そこで、アクセスコントローラは、SIPサーバに対して輻輳中であることを示す情報を含むQoS予約レスポンスを返す（ステップ２２）。当該QoS予約レスポンスを受信したSIPサーバは、「呼の中断」を示すメッセージを端末に送信する（ステップ２３）。
【０１６５】
なお、当該QoS予約レスポンスを受信したSIPサーバは、第１の実施の形態と同様の呼制御を端末２に対して行ってもよい。
【０１６６】
次に、輻輳中の無線AP１０に隣接して、輻輳中でない無線AP２０が存在する環境の下で、無線AP１０に接続された端末１が端末２に発信を行う場合のシステムの動作について図５９、６０を参照して詳細に説明する。
【０１６７】
図５９におけるステップ１〜ステップ４は図６におけるステップ１〜ステップ４と同じである。無線AP１０がアクセスコントローラからQoS予約リクエストを受信した後のステップ５において、無線AP１０は、輻輳中であり、QoS予約リクエストに含まれる必要帯域幅を予約することができないと判定する（ステップ５）。すると無線AP１０は輻輳中であることを示すQoS予約レスポンスをアクセスコントローラに返す（ステップ６）。
【０１６８】
アクセスコントローラは、呼状態管理テーブルにおける端末１の呼状態を「隣接無線APへ切替中」とし、端末１が隣接無線APへ切替中であることを示す情報を含むQoS予約レスポンスをSIPサーバに返す（ステップ７）。このQoS予約レスポンスを受信したSIPサーバは、呼の中断を行うためのメッセージを端末１に送信する（ステップ８）。また、アクセスコントローラは、MS01と再接続要求拒否時間を含む無線リンク切断要求（隣接無線AP移動指示に相当する）を無線AP１０に送信する（ステップ１０）。無線AP１０は、端末１に対する再接続要求拒否時間を設定する（ステップ１１）。これにより、無線AP２０は、端末１から再度接続要求を受けた場合に、再接続要求拒否時間内であれば、その接続要求を拒否する。つまり、接続要求を受けても接続動作を行わない。
【０１６９】
無線リンク切断要求を受信した無線AP１０は、無線リンク切断指示（Disassociation）を端末１に送信することにより無線リンクを切断する（ステップ１２）。無線リンクを切断された端末１は、隣接する無線APである無線AP２０に接続要求（Association）を送信する（ステップ１３）。
【０１７０】
無線AP２０は、端末１のMSIDであるMS01を登録する（ステップ１４）。そして、無線AP２０は無線APのID（AP０２）と端末１のMACアドレス（MS０１）とを含む端末登録リクエストをアクセスコントローラに対して送信する（ステップ１５）。アクセスコントローラは無線AP２０から受信した無線APのID（AP０２）と端末１のMACアドレス（MS０１）とを記憶装置に格納することにより、MSIDとAPIDの更新を行う。（ステップ１６）。そして、アクセスコントローラは無線APに対して端末登録レスポンスを返す（ステップ１７）。アクセスコントローラは、端末１に対する呼状態を"無し"にする。
【０１７１】
そして、端末１でユーザによる再操作がなされることにより、端末１からINVITEメッセージがSIPサーバに対して送信される（ステップ１９）。その後は、無線AP２０に関し、図９のステップ１〜図１０のステップ１９と同様の処理が実行されて、端末１と端末２間での呼接続が行われる。
【０１７２】
上記の場合において、無線AP２０も輻輳中である場合は、無線AP２０に対して図５９のステップ１〜図６０のステップ８の処理が実行され、端末１の接続が切断されることになる。その後、図６０のステップ１２が実行され、それ以降の処理が、隣接無線APに対してなされることになる。なお、発信の場合も、輻輳中であることを示すQoS予約レスポンスを受信したアクセスコントローラがリトライ回数をカウントし、それが上限値に達している場合には、無線リンク切断要求（隣接無線AP移動指示）を送信しないこととすることができる。
【０１７３】
（装置構成について）
第３の実施の形態における装置の機能概要を図６１を参照して説明する。第３の実施の形態における装置の基本的な構成は第１の実施の形態における装置構成と同様である。以下、第１の実施の形態の装置と異なる主な点について説明する。
【０１７４】
アクセスコントローラ３０は、第１の実施の形態で説明した機能に加えて、呼接続制御機能３８と端末制御機能３９を有している。呼接続制御機能３８は、無線APの輻輳を検出した場合に、SIPサーバからのQoS予約リクエストに対する応答として"隣接無線APへ切替中"を示す応答メッセージを返す機能を含む。また、端末制御機能３９は、無線APの輻輳検出時に無線リンク切断要求を送信する機能、及び無線リンクリトライの失敗回数をカウントし、予め設定した回数に達したかどうかの判定を行う。ハンドオーバ成否判定機能３７は、端末のハンドオーバ時にハンドオーバが成功したかどうかの判定を行う。
【０１７５】
図６２に、本実施の形態での端末管理データを示す。本実施の形態では、呼状態として、「隣接無線APへ切替中」を含む。アクセスコントローラは、端末が接続する無線APが輻輳中であることを検知したことに応じて呼状態を「隣接無線APへ切替中」とする。ただし、リトライ回数が上限値に達していた場合は、切替のための動作を行わないので、呼状態は無しとする。そして、隣接無線APに対する端末の登録が済んだことを契機として、呼状態を「隣接無線APへ切替中」から「無し」にする。
【０１７６】
また、本実施の形態における端末管理データは、端末毎の無線リンクリトライ回数（上限値）と、実際の無線リンクリトライ回数を含む。実際の無線リンクリトライ回数が上限値に達した場合に呼接続失敗と判定される。
【０１７７】
図６３に、本実施の形態における再接続要求拒否時間管理用の無線AP管理データを示す。図６３に示すように、無線AP毎及び端末毎に、再接続要求拒否時間と、無線リンクを切断してから実際に経過した時間である再接続要求拒否経過時間が記録される。
【０１７８】
図６４に、本実施の形態におけるアクセスコントローラの詳細機能構成図を示す。以下、第１の実施の形態と異なる部分について主に説明する。
【０１７９】
SIP要求返却部６２におけるリソース要求返却部６７は、無線APが輻輳中である場合に、SIPサーバに"隣接無線APへ切替中"である旨を通知する機能を含む。また、リソース予約／解放部７１は、無線APのリソースを調べ、輻輳状態かどうかを判定し、服装状態である場合に、無線リンク切断を要求する機能を有している。また、リソース管理機能７０は、ある端末の無線リンクリトライ回数が、予め定めた上限値に達したかどうかを判定する無線リンクリトライ判定部７３を有している。
【０１８０】
また、データ更新部８１は、無線APが輻輳中である場合に、端末の呼状態を「隣接無線APへ切替中」とする機能を備えている。また、無線AP連携I／F１１０は、無線リンク切断要求部１１２を有している。無線リンク切断要求部１１２は、無線APが輻輳状態にあるときに、端末を他の隣接無線APへ再接続させるために、無線APに無線リンク切断要求を送信するものである。
【０１８１】
なお、本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内において、種々変更・応用が可能である。
【図面の簡単な説明】
【０１８２】
【図１】従来の無線ＩＰ電話システムの構成例を示す図である。
【図２】本発明の実施の形態におけるシステムの一例を示す図である。
【図３】本発明の第１の実施の形態におけるシステムの動作概要を説明するための図である。
【図４】本発明の第１の実施の形態において、端末１をアクセスコントローラに登録するためのシーケンス図である。
【図５】本発明の第１の実施の形態において、アクセスコントローラから登録された端末１を削除するためのシーケンス図である。
【図６】本発明の第１の実施の形態において、輻輳状態に無い無線AP配下の端末１に端末２から着信要求がなされた場合のシーケンス図である。
【図７】本発明の第１の実施の形態において、輻輳状態に無い無線AP配下の端末１に端末２から着信要求がなされた場合のシーケンス図である。
【図８】本発明の第１の実施の形態において、輻輳状態に無い無線AP配下の端末１に端末２から着信要求がなされた場合のシーケンス図である。
【図９】本発明の第１の実施の形態において、輻輳状態に無い無線APの配下の端末１が端末２に対して発信する場合のシーケンス図である。
【図１０】本発明の第１の実施の形態において、輻輳状態に無い無線APの配下の端末１が端末２に対して発信する場合のシーケンス図である。
【図１１】本発明の第１の実施の形態において、輻輳状態に無い無線APの配下の端末１が端末２に対して発信する場合のシーケンス図である。
【図１２】本発明の第１の実施の形態において、輻輳中の無線AP配下にある端末１に端末２から着信要求があった場合の動作例１を示すシーケンス図である。
【図１３】本発明の第１の実施の形態において、輻輳中の無線AP配下にある端末１に端末２から着信要求があった場合の動作例２を示すシーケンス図である。
【図１４】本発明の第１の実施の形態において、輻輳中の無線AP配下にある端末１に端末２から着信要求があった場合の動作例２を示すシーケンス図である。
【図１５】本発明の第１の実施の形態において、輻輳中の無線AP配下にある端末１に端末２から着信要求があった場合の動作例３を示すシーケンス図である。
【図１６】本発明の第１の実施の形態において、輻輳中の無線AP配下にある端末１に端末２から着信要求があった場合の動作例４を示すシーケンス図である。
【図１７】本発明の第１の実施の形態において、輻輳中の無線AP配下にある端末１に端末２から着信要求があった場合の動作例４を示すシーケンス図である。
【図１８】本発明の第１の実施の形態において、輻輳中の無線AP配下にある端末１に端末２から着信要求があった場合の動作例４を示すシーケンス図である。
【図１９】本発明の第１の実施の形態において、内線グループ一斉呼び出しを行う場合の接続動作を示すシーケンス図である。
【図２０】本発明の第１の実施の形態において、内線グループ一斉呼び出しを行う場合の接続動作を示すシーケンス図である。
【図２１】本発明の第１の実施の形態において、内線グループ一斉呼び出しを行う場合の接続動作を示すシーケンス図である。
【図２２】本発明の第１の実施の形態において、コールパークを行う場合の接続動作を示すシーケンス図である。
【図２３】本発明の第１の実施の形態において、コールパークを行う場合の接続動作を示すシーケンス図である。
【図２４】本発明の第１の実施の形態において、コールパークを行う場合の接続動作を示すシーケンス図である。
【図２５】本発明の第１の実施の形態において、コールパークを行う場合の接続動作を示すシーケンス図である。
【図２６】本発明の第１の実施の形態において、コールウェイティングを行う場合の接続動作を示すシーケンス図である。
【図２７】本発明の第１の実施の形態において、コールウェイティングを行う場合の接続動作を示すシーケンス図である。
【図２８】本発明の第１の実施の形態において、コールウェイティングを行う場合の接続動作を示すシーケンス図である。
【図２９】本発明の第１の実施の形態において、装置の機能概要を説明するための図である。
【図３０】本発明の第１の実施の形態において、端末管理データの例を示す図である。
【図３１】本発明の第１の実施の形態において、無線AP管理データの例を示す図である。
【図３２】本発明の第１の実施の形態において、アクセスコントローラ３０の詳細機能構成図である。
【図３３】本発明の第２の実施の形態におけるシステムの全体動作フローである。
【図３４】本発明の第２の実施の形態におけるシステムの動作の概要を説明するための図である。
【図３５】本発明の第２の実施の形態において、移動先の無線AP２０が輻輳中でない場合の動作を示すシーケンス図である。
【図３６】本発明の第２の実施の形態において、移動先の無線AP２０が輻輳中でない場合の動作を示すシーケンス図である。
【図３７】本発明の第２の実施の形態において、移動先の無線AP２０が輻輳中でない場合の動作を示すシーケンス図である。
【図３８】本発明の第２の実施の形態において、最初の移動先の無線AP２０が輻輳中であるが、隣接無線AP２５に接続することによりハンドオーバが成功する場合の動作例を示すシーケンス図である。
【図３９】本発明の第２の実施の形態において、最初の移動先の無線AP２０が輻輳中であるが、隣接無線AP２５に接続することによりハンドオーバが成功する場合の動作例を示すシーケンス図である。
【図４０】本発明の第２の実施の形態において、最初の移動先の無線AP２０が輻輳中であるが、隣接無線AP２５に接続することによりハンドオーバが成功する場合の動作例を示すシーケンス図である。
【図４１】本発明の第２の実施の形態において、ハンドオーバに失敗し、通話相手端末に対する呼制御が行われる場合の動作例１を示すシーケンス図である。
【図４２】本発明の第２の実施の形態において、ハンドオーバに失敗し、通話相手端末に対する呼制御が行われる場合の動作例１を示すシーケンス図である。
【図４３】本発明の第２の実施の形態において、ハンドオーバに失敗した場合の動作例２を示すシーケンス図である。
【図４４】本発明の第２の実施の形態において、ハンドオーバに失敗した場合の動作例２を示すシーケンス図である。
【図４５】本発明の第２の実施の形態において、ハンドオーバに失敗した場合の動作例３を示すシーケンス図である。
【図４６】本発明の第２の実施の形態において、ハンドオーバに失敗した場合の動作例４を示すシーケンス図である。
【図４７】本発明の第２の実施の形態において、ハンドオーバに失敗した場合の動作例４を示すシーケンス図である。
【図４８】本発明の第２の実施の形態において、ハンドオーバに失敗した場合の動作例４を示すシーケンス図である。
【図４９】本発明の第２の実施の形態において、装置の機能概要を説明するための図である。
【図５０】本発明の第２の実施の形態において、端末管理データの例を示す図である。
【図５１】本発明の第２の実施の形態において、再接続要求拒否時間管理用の無線AP管理データの例を示す図である。
【図５２】本発明の第２の実施の形態において、アクセスコントローラ３０の詳細機能構成図である。
【図５３】本発明の第３の実施の形態において、輻輳中の無線APに接続された端末１に端末２から着信があった場合のシステムの動作概要について説明するための図である。
【図５４】本発明の第３の実施の形態において、輻輳中の無線AP１０に接続された端末１が端末２に発信する場合におけるシステムの動作概要を説明するための図である。
【図５５】本発明の第３の実施の形態において、輻輳中でない無線AP２０が存在する環境の下で、輻輳中の無線AP１０に接続された端末１に端末２から着信があった場合のシステムの動作を示すシーケンス図である。
【図５６】本発明の第３の実施の形態において、輻輳中でない無線AP２０が存在する環境の下で、輻輳中の無線AP１０に接続された端末１に端末２から着信があった場合のシステムの動作を示すシーケンス図である。
【図５７】本発明の第３の実施の形態において、輻輳中でない無線AP２０が存在する環境の下で、輻輳中の無線AP１０に接続された端末１に端末２から着信があった場合のシステムの動作を示すシーケンス図である。
【図５８】本発明の第３の実施の形態において、無線AP１０が輻輳中であるとともに、隣接無線AP２０も輻輳中であり、呼の中断を行う場合の動作を示すシーケンス図である。
【図５９】本発明の第３の実施の形態において、輻輳中の無線AP１０に隣接して、輻輳中でない無線AP２０が存在する環境の下で、無線AP１０に接続された端末１が端末２に発信を行う場合のシステムの動作を示すシーケンス図である。
【図６０】本発明の第３の実施の形態において、輻輳中の無線AP１０に隣接して、輻輳中でない無線AP２０が存在する環境の下で、無線AP１０に接続された端末１が端末２に発信を行う場合のシステムの動作を示すシーケンス図である。
【図６１】本発明の第３の実施の形態において、装置の機能概要を説明するための図である。
【図６２】本発明の第３の実施の形態において、端末管理データの例を示す図である。
【図６３】本発明の第３の実施の形態において、再接続要求拒否時間管理用の無線AP管理データの例を示す図である。
【図６４】本発明の第３の実施の形態において、アクセスコントローラ３０の詳細機能構成図である。
【符号の説明】
【０１８３】
１、２ 端末
１０、２０、２５ 無線AP
１１ 無線AP機能
１２ 対アクセスコントローラインタフェース機能
３０ アクセスコントローラ
３１ 対SIPサーバインタフェース機能
３２ 判定機能
３３ 対無線APインタフェース機能
３４ 対コンソールインタフェース機能
３５ データベース
３６ 無線リンクリトライ判定機能
３７ ハンドオーバ成否判定機能
３８ 呼接続制御機能
３９ 端末制御機能
４０ SIPサーバ
４１ 呼制御機能
４２ 対アクセスコントローラインタフェース機能
５０ コンソール
５１ ユーザインタフェース機能
５２ 対アクセスコントローラインタフェース機能
６０ SIP連携Ｉ／Ｆ
７０ リソース管理機能
８０ データ管理機能
９０ 無線AP管理機能
１００ 端末管理機能
１１０ 無線AP連携Ｉ／Ｆ
【技術分野】
【０００１】
本発明は無線LAN技術を用いた無線ＩＰ電話システムに関し、特に、無線LANアクセスポイント毎に輻輳制御を行う無線ＩＰ電話システムに関するものである。
【背景技術】
【０００２】
図１に従来の無線ＩＰ電話システムの構成例を示す。図１に示すように、この無線ＩＰ電話システムは、複数の無線LANアクセスポイント（以下、無線APと呼ぶ）、複数の無線APを管理する無線LANスイッチ、ＩＰ電話の呼制御を行うSIPサーバを含む。また、無線APの配下には無線VoIP端末等の端末が存在し、無線APと接続する。このシステムでは、SIPに基づく呼接続処理により、端末間で音声チャネルが確立され、ＲＴＰによる音声通信が行われる。
【０００３】
無線LANスイッチは、端末と無線APとの間のハンドオーバをサポートする機能、端末から無線APへの接続を分散させる機能等を備えており、これにより高速なハンドオーバや、帯域が不足している無線APを回避して帯域に余裕のある無線APへの接続を行うことなどが可能である（例えば、非特許文献１参照）。
【非特許文献１】日経コミュニケーション、ｐｐ．９６〜１０３、日経ＢＰ社 ２００５．７．１５
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、従来の無線ＩＰ電話システムには次のような問題がある。
【０００５】
例えば図１のシステムにおける無線AP１０に多数の端末が接続され、無線AP１０にて限界に近い無線APリソースが利用されている状態において、無線AP１０の配下に存在しているが未だ呼接続がなされていない端末１に対する新たな呼接続要求が端末２から発信されたものとする。
【０００６】
一般に無線APにおける各接続端末に対するリソース配分は、サービス品質(QoS)の保証がないベストエフォート型であるため、呼接続処理の中で無線AP１０に端末１の呼に対するリソースが割り当てられ、端末１と発信元端末２間で音声チャネルが確立され、音声通信が行われる。
【０００７】
しかし、無線AP１０は端末１の接続前の時点で限界に近い無線APリソースを利用していたたため、端末１が接続したことにより、無線AP１０のリソースは更に消費され、無線AP１０は輻輳状態となる。これにより、端末１において良い音声品質が得られないばかりでなく、もともと無線AP１０に接続していた全端末における音声品質が低下し、雑音、音抜けの発生、通信断等が発生する。
【０００８】
このように従来の無線ＩＰ電話システムでは、無線AP配下の端末に対して呼接続要求があった場合、その無線APが混雑状態であっても、その端末に対して呼が確立してしまい、無線AP配下の全端末に対して悪影響を及ぼすという問題があった。
【０００９】
また、従来の無線LANスイッチと無線APからなるシステムにおいて、無線APで収容可能な呼数を制限する技術はあるが、アプリケーションレイヤ（例えばSIPによる呼制御を実行するレイヤ）での制御を行うことができないため、発信元端末が呼接続に失敗した場合に、発信元端末は着信先端末もしくは無線APのどちらが原因で呼接続が失敗したか等を把握できない。このように、従来のシステムではアプリケーションレイヤでの柔軟な対応が実現できなかった。
【００１０】
更に、従来の無線ＩＰ電話システムでは、通話中の端末に対する無線APの輻輳管理・制御を行うことができないので、端末が、接続中の無線APの配下から別の無線APの配下にハンドオーバする際に、別の無線APが限界に近い無線APリソースを利用していた場合であっても、別の無線APはハンドオーバしてきた端末の接続を受け付ける。従って、この端末を受け付けた別の無線APでは、図１に示す端末２からの着信を受け付けた無線APと同様の問題が発生する。つまり、ハンドオーバ先の無線APを利用している端末の呼の通話品質が低下したり、不通状態等が発生する。また、ハンドオーバした端末が不通状態になった場合に、通信相手端末はその端末がどのような状態にあるかを知ることができないため、不通状態となった通話を切断してよいかどうか判断できず、不要な待機状態が発生してしまうという問題もある。
【００１１】
また、無線APが隣接して複数配置されている環境では、ある無線APが輻輳していても、隣接する無線APでは輻輳していない場合があり、ある無線APが輻輳中の場合に、それを検知し、隣接する無線APを利用して通信を継続したいという要求がある。
【００１２】
本発明は上記の点に鑑みてなされたものであり、上記従来技術の問題を解消し、無線APのリソース状態に応じた制御を行うための技術を提供することを目的とする。
【課題を解決するための手段】
【００１３】
上記の課題は、無線APとVoIP呼制御手段とを有する無線ＩＰ電話システムにおけるアクセス制御装置であって、端末から前記無線APへ接続がなされたことを契機として、データリンク層における前記端末の識別情報である下位レイヤ識別情報と無線AP識別情報とを含む端末登録要求を前記無線APから受信し、当該無線AP識別情報を前記下位レイヤ識別情報に対応付けて記憶手段に登録する下位レイヤ登録手段と、前記端末の呼制御で用いられる識別情報である上位レイヤ識別情報と前記下位レイヤ識別情報とを含む端末登録要求を前記VoIP呼制御手段から受信し、当該上位レイヤ識別情報を前記下位レイヤ識別情報に対応付けて前記記憶手段に登録する上位レイヤ登録手段と、前記端末への着信または前記端末からの発信に係る呼接続要求を受信した前記VoIP呼制御手段からリソース状態の問い合わせを受信し、当該問い合わせに含まれる前記端末の上位レイヤ識別情報に基づき前記記憶手段を検索して前記端末を収容する前記無線APを検出し、当該無線APが輻輳状態にあるか否かの判定結果を取得し、輻輳状態にある場合に前記無線APが輻輳中であることを前記VoIP呼制御手段に通知する通知手段とを有することを特徴とするアクセス制御装置により解決できる。なお、上位レイヤ識別情報を下位レイヤ識別情報に対応付けて記憶手段に登録することは、予め記憶手段に格納されている上位レイヤ識別情報と下位レイヤ識別情報とに対応付けて当該上位レイヤ識別情報が登録状態になったことを示す情報を記録することも含むものとする。
【００１４】
前記アクセス制御装置の記憶手段は、前記無線AP識別情報と前記無線APのリソース上限値と前記無線APで使用中のリソース量とを対応付けて格納しており、前記通知手段は前記無線APのリソース上限値及び使用中リソース量と、前記リソース状態の問い合わせに含まれる前記端末に対する必要リソース量とに基づき前記無線APが輻輳状態にあるか否かを判定する判定手段を含むこととしてもよい。
【００１５】
また、本発明は、前記アクセス制御装置と前記VoIP呼制御手段とを有する無線ＩＰ電話システムであって、前記VoIP呼制御手段は、前記リソース状態の問い合わせに対する応答として前記無線APが輻輳中である旨の通知を前記アクセス制御装置から受信した場合に、前記呼接続要求を保留させ、当該呼接続要求を送信した端末に対して通信路が輻輳中であることを通知し、前記無線APが輻輳状態から回復した旨の通知を前記アクセス制御装置から受信したことを契機として、着信先端末への呼接続を行う呼制御手段を有することを特徴とする無線ＩＰ電話システムとして構成することもできる。
【００１６】
本発明は、無線APとVoIP呼制御手段とアクセス制御装置とを有する無線ＩＰ電話システムにおけるアクセス制御方法であって、前記アクセス制御装置が、端末から前記無線APへ接続がなされたことを契機として、データリンク層における前記端末の識別情報である下位レイヤ識別情報と無線AP識別情報とを含む端末登録要求を前記無線APから受信し、当該無線AP識別情報を前記下位レイヤ識別情報に対応付けて記憶手段に登録する下位レイヤ登録ステップと、前記アクセス制御装置が、前記端末の呼制御で用いられる識別情報である上位レイヤ識別情報と前記下位レイヤ識別情報とを含む端末登録要求を前記VoIP呼制御手段から受信し、当該上位レイヤ識別情報を前記下位レイヤ識別情報に対応付けて前記記憶手段に登録する上位レイヤ登録ステップと、前記VoIP呼制御手段が、前記端末への着信または前記端末からの発信に係る呼接続要求を受信し、当該端末の呼に対して必要なリソース状態の問い合わせを前記アクセス制御装置に送信するリソース状態問い合わせステップと、前記アクセス制御装置が、前記問い合わせに含まれる前記端末の上位レイヤ識別情報に基づき前記記憶手段を検索して前記端末を収容する前記無線APを検出し、当該無線APが輻輳状態にあるか否かの判定結果を取得し、輻輳状態にある場合に前記無線APが輻輳中であることを前記VoIP呼制御手段に通知する通知ステップと、前記VoIP呼制御手段が、前記無線APが輻輳中であることに応じた呼制御を実行する呼制御ステップとを有することを特徴とするアクセス制御方法として構成することもできる。
【００１７】
また、本発明は、複数の無線APとVoIP呼制御手段とを有する無線ＩＰ電話システムにおけるアクセス制御装置であって、端末からある無線APへ接続がなされたことを契機として、データリンク層における前記端末の識別情報である下位レイヤ識別情報と無線AP識別情報とを含む端末登録要求を前記無線APから受信し、当該無線APの識別情報を前記下位レイヤ識別情報に対応付けて記憶手段に登録する下位レイヤ登録手段と、前記端末の呼制御で用いられる識別情報である上位レイヤ識別情報と前記下位レイヤ識別情報とを含む端末登録要求を前記VoIP呼制御手段から受信し、当該上位レイヤ識別情報を下位レイヤ識別情報に対応付けて前記記憶手段に登録する上位レイヤ登録手段と、前記端末への着信または前記端末からの発信に係る呼接続要求を受信した前記VoIP呼制御手段からのリソース予約要求を契機として、当該要求に含まれる前記端末の上位レイヤ識別情報に基づき前記記憶手段を検索して前記端末を収容する前記無線APを検出し、前記無線APにおける前記端末に対する通信リソースの割り当て制御を行うリソース制御手段とを有し、前記VoIP呼制御手段により前記端末と相手端末間での呼接続が行われ、前記端末が前記相手端末と通信中の状態において、前記端末が、接続中の無線APの配下から、他の無線APである移動先無線APの配下に移動した場合に、前記端末から前記移動先無線APへ接続がなされたことを契機として、前記下位レイヤ登録手段は、前記端末の下位レイヤ識別情報と前記移動先無線APの識別情報とを含む端末登録要求を前記移動先無線APから受信し、当該移動先無線APの識別情報を前記下位レイヤ識別情報及び前記上位レイヤ識別情報に対応付けて前記記憶手段に登録し、前記リソース制御手段は、前記VoIP呼制御手段からの要求を受けることなく、前記無線APにおいて前記端末に対して割り当てられていたリソースを解放し、前記移動先無線APが輻輳状態でない場合に、当該移動先無線APにおいて前記端末に対する通信リソースの確保を行うことを特徴とするアクセス制御装置として構成することもできる。
【００１８】
前記リソース制御手段は、前記移動先無線APにおけるリソースの確保を行う前に、前記移動先無線APが輻輳状態にあるか否かの判定結果を取得し、当該移動先無線APが輻輳状態にある場合に、前記アクセス制御装置は、前記端末との無線リンク切断要求を前記移動先無線APに送信するようにしてもよい。
【００１９】
この構成において、前記無線リンク切断要求を受信した移動先無線APから無線リンク切断指示を受信した前記端末が、他の無線APへの接続を行ったことを契機として、前記下位レイヤ登録手段は、前記他の無線APの識別情報を前記下位レイヤ識別情報及び前記上位レイヤ識別情報に対応付けて前記記憶手段に登録し、前記リソース制御手段は、前記他の無線APが輻輳状態でない場合に、前記他の無線APにおいて前記端末に対するリソースの確保を行うことができる。
【００２０】
また、前記アクセス制御装置は、前記端末が接続する無線APが輻輳状態にあるためにリソース確保に失敗した回数を保持し、その回数と所定の回数とを比較し、リソース確保に失敗した回数が前記所定の回数に達していない場合に、リソース確保に失敗した無線APに無線リンク切断要求を送信し、リソース確保に失敗した回数が前記所定の回数に達している場合には、ハンドオーバ失敗通知を前記VoIP呼制御装置に送信するようにしてもよい。
【００２１】
上記アクセス制御装置と前記VoIP呼制御手段とを有する無線ＩＰ電話システムにおいて、前記VoIP呼制御手段は、前記ハンドオーバ失敗通知を前記アクセス制御装置から受信した場合に、前記相手端末に対する呼制御を行うようにしてもよい。
【００２２】
また、本発明は、複数の無線APとVoIP呼制御手段とアクセス制御装置とを有する無線ＩＰ電話システムにおけるアクセス制御方法であって、前記アクセス制御装置が、端末からある無線APへ接続がなされたことを契機として、データリンク層における前記端末の識別情報である下位レイヤ識別情報と無線AP識別情報とを含む端末登録要求を前記無線APから受信し、当該無線APの識別情報を前記下位レイヤ識別情報に対応付けて記憶手段に登録する下位レイヤ登録ステップと、前記アクセス制御装置が、前記端末の呼制御で用いられる識別情報である上位レイヤ識別情報と前記下位レイヤ識別情報とを含む端末登録要求を前記VoIP呼制御手段から受信し、当該上位レイヤ識別情報を下位レイヤ識別情報に対応付けて前記記憶手段に登録する上位レイヤ登録ステップと、前記VoIP呼制御手段が、前記端末への着信または前記端末からの発信に係る呼接続要求を受信し、リソース予約要求を前記アクセス制御装置に送信するステップと、前記アクセス制御装置が、前記リソース予約要求を受信したことを契機として、当該要求に含まれる前記端末の上位レイヤ識別情報に基づき前記記憶手段を検索して前記端末を収容する前記無線APを検出し、前記無線APにおける前記端末に対する通信リソースの割り当て制御を行うリソース制御ステップとを有し、前記VoIP呼制御手段が前記端末と相手端末間での呼接続処理を行い、前記端末が前記相手端末と通信中の状態において、前記端末が、接続中の無線APの配下から、他の無線APである移動先無線APの配下に移動した場合に、前記端末から前記移動先無線APへ接続がなされたことを契機として、前記移動先無線APは、前記端末の下位レイヤ識別情報と前記移動先無線APの識別情報とを含む端末登録要求を前記アクセス制御装置に送信し、前記端末登録要求を受信した前記アクセス制御装置は、前記移動先無線APの識別情報を前記下位レイヤ識別情報及び前記上位レイヤ識別情報に対応付けて前記記憶手段に登録し、前記VoIP呼制御手段からの要求を受けることなく、前記無線APにおいて前記端末に対して割り当てられていた通信リソースを解放し、前記移動先無線APが輻輳状態でない場合に、前記移動先無線APにおいて前記端末に対する通信リソースの確保を行うことを特徴とするアクセス制御方法として構成することもできる。
【００２３】
また、本発明は、複数の無線APとVoIP呼制御手段とを有する無線ＩＰ電話システムにおけるアクセス制御装置であって、端末からある無線APへ接続がなされたことを契機として、データリンク層における前記端末の識別情報である下位レイヤ識別情報と無線AP識別情報とを含む端末登録要求を前記無線APから受信し、当該無線APの識別情報を前記下位レイヤ識別情報に対応付けて記憶手段に登録する下位レイヤ登録手段と、前記端末の呼制御で用いられる識別情報である上位レイヤ識別情報と前記下位レイヤ識別情報とを含む端末登録要求を前記VoIP呼制御手段から受信し、当該上位レイヤ識別情報を下位レイヤ識別情報に対応付けて前記記憶手段に登録する上位レイヤ登録手段と、前記端末への着信または前記端末からの発信に係る呼接続要求を受信した前記VoIP呼制御手段から当該端末に対するリソース予約要求を受信し、当該要求に含まれる前記端末の上位レイヤ識別情報に基づき前記記憶手段を検索して前記端末を収容する前記無線APを検出し、当該無線APが輻輳状態にあるか否かの判定結果を取得するリソース判定手段とを有し、前記無線APが輻輳状態である場合に、前記アクセス制御装置は、前記端末との無線リンク切断要求を前記無線APに送信し、前記無線リンク切断要求を受信した前記無線APから無線リンク切断指示を受信した前記端末が他の無線APへの接続を行ったことを契機として、前記下位レイヤ登録手段は、前記他の無線APの識別情報を前記下位レイヤ識別情報及び前記上位レイヤ識別情報に対応付けて前記記憶手段に登録することを特徴とするアクセス制御装置として構成してもよい。
【００２４】
前記呼接続要求が、相手端末から前記端末への着信に係るものである場合に、前記リソース判定手段は、前記他の無線APが輻輳状態にあるか否かの判定結果を取得し、前記他の無線APが輻輳状態にない場合に、前記アクセス制御装置は、前記VoIP呼制御手段に、リソース予約に成功したことを示すメッセージを送信するように構成できる。
【００２５】
前記アクセス制御装置と前記VoIP呼制御手段とを有する無線ＩＰ電話システムにおいて、前記VoIP呼制御手段は、前記リソース予約に成功したことを示すメッセージを受信したことに応じて、前記呼接続要求に基づく呼接続処理を継続することができる。
【００２６】
また、前記アクセス制御装置と前記VoIP呼制御手段とを有する無線ＩＰ電話において、前記呼接続要求が前記端末から相手端末への発信に係るものである場合に、前記リソース判定手段は、前記他の無線APが輻輳状態にあるか否かの判定結果を取得し、前記他の無線APが輻輳状態にない場合に、前記VoIP呼制御手段は、前記端末から再度受信する呼接続要求に基づき、前記端末と前記相手端末との間の呼接続処理を行うように構成することができる。
また、前記アクセス制御装置は、前記端末が接続した無線APが輻輳状態にあるためにリソース予約に失敗した回数を保持し、その回数と所定の回数とを比較し、リソース予約に失敗した回数が前記所定の回数に達していない場合に、リソース予約に失敗した無線APに無線リンク切断要求を送信し、リソース予約に失敗した回数が前記所定の回数に達している場合には、無線APが輻輳状態にあることを示すメッセージを前記VoIP呼制御装置に送信するように構成してもよい。
【００２７】
また、本発明は、複数の無線APとVoIP呼制御手段とアクセス制御装置とを有する無線ＩＰ電話システムにおけるアクセス制御方法であって、前記アクセス制御装置が、端末からある無線APへ接続がなされたことを契機として、データリンク層における前記端末の識別情報である下位レイヤ識別情報と無線AP識別情報とを含む端末登録要求を前記無線APから受信し、当該無線APの識別情報を前記下位レイヤ識別情報に対応付けて記憶手段に登録する下位レイヤ登録ステップと、前記アクセス制御装置が、前記端末の呼制御で用いられる識別情報である上位レイヤ識別情報と前記下位レイヤ識別情報とを含む端末登録要求を前記VoIP呼制御手段から受信し、当該上位レイヤ識別情報を下位レイヤ識別情報に対応付けて前記記憶手段に登録する上位レイヤ登録ステップと、前記VoIP呼制御手段が、前記端末への着信または前記端末からの発信に係る呼接続要求を受信するステップと、前記アクセス制御装置が、前記VoIP呼制御手段から前記端末に対するリソース予約要求を受信し、当該要求に含まれる前記端末の上位レイヤ識別情報に基づき前記記憶手段を検索して前記端末を収容する前記無線APを検出し、当該無線APが輻輳状態にあるか否かの判定結果を取得するリソース判定ステップと、前記無線APが輻輳状態である場合に、前記アクセス制御装置が、前記端末との無線リンク切断要求を前記無線APに送信するステップと、前記無線リンク切断要求を受信した前記無線APから無線リンク切断指示を受信した前記端末が他の無線APへの接続を行ったことを契機として、前記アクセス制御装置が、前記他の無線APの識別情報を前記下位レイヤ識別情報及び前記上位レイヤ識別情報に対応付けて前記記憶手段に登録するステップとを有することを特徴とするアクセス制御方法として構成してもよい。
【発明の効果】
【００２８】
本発明によれば、データリンク層における端末の識別情報である下位レイヤ識別情報に基づき無線AP識別情報と端末の呼制御で用いられる識別情報である上位レイヤ識別情報とを対応付けて登録するので、呼制御で用いられる上位レイヤ識別情報に基づき対象端末を収容する無線APを検出できるので、その無線APのリソース状態に応じて当該上位レイヤ識別情報に対応する端末の呼制御を実現できる。よって、無線AP配下の端末に対して呼接続要求があった場合、その無線APが混雑状態であれば、その端末に対して呼を確立させずに例えば発信端末に対してビジーを送信する等といったアプリケーションレイヤでの柔軟な対応が可能となり、無線AP配下の全端末に対して悪影響を及ぼすという従来技術の問題が解消される。
【００２９】
また、アプリケーションレイヤでの柔軟な対応が可能となるため、例えば、呼接続に失敗した発信元端末に対して、呼接続失敗の原因通知、呼の転送、輻輳回復後の呼接続等の様々な対応をとることが可能となる。
【００３０】
また、本発明によれば、通話中の端末に対する無線APの輻輳管理・制御を行いながらハンドオーバを実施することが可能となり、ハンドオーバに関する従来技術の問題が解消される。
【００３１】
また、本発明によれば、無線APが隣接して複数配置されている環境において、接続した無線APが輻輳していても、隣接する無線APが輻輳していない場合には、隣接する無線APを利用して通信を継続することが可能となる。また、これにより、呼の成功確率を高めることができる。
【発明を実施するための最良の形態】
【００３２】
以下、図面を参照して本発明の実施の形態を説明する。
【００３３】
＜第１の実施の形態＞
（システム概要）
図２に、本発明の第１の実施の形態におけるシステムの一例を示す。図２に示すシステムは、図１に示したシステムにアクセスコントローラ３０が付加されたものである。なお、アクセスコントローラ３０は、図２における無線LANスイッチに替えて、もしくは無線LANスイッチ内に備えることも可能である。
【００３４】
図２のシステムにおけるアクセスコントローラ３０は、無線AP毎に端末毎のリソースの割り当て状態を管理する機能を有している。SIPサーバ４０はVoIP通信の発生に応じてアクセスコントローラにリソース状態を問い合わせ、リソース状態に応じた呼制御を行う機能を有している。
【００３５】
図３を用いて本実施の形態のシステムの動作概要を説明する。図３において、無線AP１０は輻輳状態であり、端末１が無線AP１０配下にあるが未だ呼接続はされていないものとする。このような状態で、発信元の端末２から端末１に対する呼接続要求がSIPサーバ４０に送信されると（ステップＡ）、SIPサーバ４０はアクセスコントローラ３０に、着信先端末である端末１の呼のためのリソース状態を問い合わせる（ステップＢ）。アクセスコントローラ３０は、無線AP１０が輻輳状態であり、無線AP１０において端末１に対するリソースの割り当てができないことをSIPサーバ４０に通知する（ステップＣ）。SIPサーバ４０はこの通知を受信し、ステップＡの呼接続要求に対する応答として、発信元の端末２に対してビジーを送信する（ステップＤ）。
【００３６】
このように本実施形態では、無線APが輻輳状態にある場合には新たな呼接続がなされないため、新規の呼接続によりもたらされる無線APに接続されている端末に対する音声劣化等の悪影響を防止できる。なお、輻輳時におけるSIPサーバ４０の処理としてビジー返却を説明したが、これは一例に過ぎず、他にも様々な処理が可能である。
【００３７】
（システムの動作詳細）
次に、本実施の形態のシステムの動作をシーケンス図を参照して詳細に説明する。各シーケンス図では、各装置内に保持されるデータの構造を適宜示している。また、シーケンス図中にレジストラとSIPサーバが示されているが、これらは別々の装置であってもよいし、SIPサーバ内にレジストラが含まれる構成でもよい。このレジストラは一般的なSIPに基づくレジストラの機能と同様の機能を有している。また、各シーケンス中、MSIDは端末のMACアドレスを示し、APIDは無線APのIDを示し、URIはSIP−URIを示す。
【００３８】
まず、図４を参照してVoIP端末１（以下、端末１と呼ぶ）をアクセスコントローラに登録するためのシーケンスを説明する。図４に示す登録処理は、例えば端末１の電源が入れられたときに自動的に行われるものである。また、図４に示す時点においてSIPサーバにアクセスコントローラが登録されており、アクセスコントローラとSIPサーバ間でSIPに基づくメッセージ送受信が可能となっている。
【００３９】
図４のステップ１において、端末１と無線AP間で無線LANにおける無線リンク接続処理及び認証処理等が行われる。ここで、無線APは端末１のMACアドレス（MSID）を取得し、登録する（ステップ２）。無線APは無線APのID（AP０１）と端末１のMACアドレス（MS０１）とを含む端末登録リクエストをアクセスコントローラに対して送信する（ステップ３）。アクセスコントローラは無線APから受信した無線APのID（AP０１）と端末１のMACアドレス（MS０１）とを記憶装置に格納することにより登録する（ステップ４）。そして、アクセスコントローラは無線APに対して端末登録レスポンスを返す（ステップ５）。
【００４０】
ステップ６において、端末１はレジストラに対してSIPのレジスタメッセージを送信する。送信するメッセージにはMS０１と端末１のURI（URI１）が含まれる。レジストラは通常のレジスタ処理を行うとともに、MS０１とURI１とを含むURI登録リクエストをアクセスコントローラに送信する（ステップ７）。アクセスコントローラはURI１をAP０１及びMS０１と対応付けて格納することによりURIの有効化を行い（ステップ８）、URI登録レスポンスをレジストラに送信する（ステップ９）。そして、レジストラはステップ６のレジスタメッセージの応答を端末１に返す（ステップ１０）。
【００４１】
なお、ここで説明する例では、端末のMACアドレスとURIとをシーケンスの中でアクセスコントローラに格納しているが、予めこれらのデータをアクセスコントローラに格納しておき、状態変化のみを記録することとしてもよい。この場合、例えば、ステップ４において予め登録されているMS０１に対応付けてAP０１が記録され、ステップ８においてAP０１、MS０１、URI１に対応付けてURI１が有効になった旨の情報が記録される。他の実施の形態でも同様である。
【００４２】
次に、図５を参照してアクセスコントローラから登録された端末１を削除する処理について説明する。図５に示す処理は、例えば端末１の電源を切る際に実行されるものである。
【００４３】
図５のステップ１において、端末１は登録削除命令を含むレジスタメッセージをレジストラに送信する。レジストラはアクセスコントローラに対してURI削除リクエストを送信し（ステップ２）、これを受信したアクセスコントローラはデータベースからURI１を削除することによりURIを無効化する（ステップ３）。アクセスコントローラはURI削除レスポンスを返し（ステップ４）、レジストラは端末１に対して応答を返す（ステップ５）。
【００４４】
ステップ６において、端末１は無線APから離脱する（無線APとの無線リンクを切断する）場合における無線LANの処理を実行し、これを受けて無線APはMSIDを削除するとともに（ステップ７）、端末削除リクエストをアクセスコントローラに送信し（ステップ８）、これを受信したアクセスコントローラはデータベースからAP０１とMS０１を削除し（ステップ９）、端末削除レスポンスを無線APに返す（ステップ１０）。
【００４５】
次に、図６〜図８を参照して、輻輳状態に無い無線AP配下の端末１に端末２から着信要求がなされた場合の動作について説明する。
【００４６】
発信元の端末２が呼接続要求（INVITE）をSIPサーバに送信する（ステップ１）。INVITEを受信したSIPサーバは、発信元端末URI（URI２）と着信先端末URI（URI１）と必要帯域幅とを含むQoS予約リクエストをアクセスコントローラに送信する（ステップ２）。アクセスコントローラは着信先URI１に基づきデータベースを検索し、端末１を配下に持つ無線APを抽出する（ステップ３）。そして、その無線APに対してMS０１と必要帯域幅とを含むQoS予約リクエストを送信する（ステップ４）。無線APは端末１に対して帯域を予約し（ステップ５）、QoS予約レスポンスをアクセスコントローラに返し（ステップ６）、アクセスコントローラはQoS予約レスポンスをSIPサーバに返す（ステップ７）。その後、通常のSIPに基づくシーケンスが実行される（ステップ８〜ステップ１２）。
【００４７】
なお、本例では無線APが帯域を管理し、帯域予約／確保を行うこととしているが、アクセスコントローラに、無線APの帯域を管理し、帯域予約／確保等のリソース制御を行う機能を持たせてもよい。この場合、無線APとアクセスコントローラ間での帯域予約／確保／解放等に関するメッセージの送受信はなされず、アクセスコントローラ内で帯域予約／確保／解放等のリソース管理がなされる。他の実施の形態でも同様である。
【００４８】
無線APはタイマ監視をしており、所定の時間内に次のメッセージ（ステップ１６）を受信しなければステップで確保した帯域を解放する（図７のステップ１３）。
【００４９】
ＡＣＫの送受信（図６のステップ１１、１２）を行ったSIPサーバは端末１と端末２間の呼を話中呼として管理している。また、この時点で端末１、２間の帯域幅が決定することから、図７のステップ１４において、SIPサーバはQoS確保リクエストをアクセスコントローラに送信する。その後は、QoS予約リクエストのシーケンス（図６のステップ３〜ステップ７）と同じシーケンス（図７のステップ１５〜ステップ１９）によって無線APでの帯域（リソース）確保がなされ、端末１、２間での音声通信が実行される（ステップ２０）。
【００５０】
図８は、図７のステップ２０の後、端末２から呼切断が行われる場合の処理を示すシーケンス図である。ステップ２１〜ステップ２４において、通常のSIPによる処理が行われることにより、SIPサーバは呼を切断する。ステップ２５において、SIPサーバはQoS解放リクエストをアクセスコントローラに送信する。アクセスコントローラは該当の無線APを抽出し（ステップ２６）、QoS解放リクエストを無線APに送信する（ステップ２７）。無線APは今までMS０１に対して確保していた帯域を解放し（ステップ２８）、QoS解放レスポンスをアクセスコントローラに返し（ステップ２９）、アクセスコントローラはQoS解放レスポンスをSIPサーバに返す（ステップ３０）。
【００５１】
図９〜図１１は、輻輳状態に無い無線APの配下の端末１が端末２に対して発信する場合のシーケンスを示す図である。発信端末と着信端末が入れ替わったことにより生じるSIPシーケンスの違いを除き図６〜図８と同じ処理が実行され、帯域予約、帯域確保、帯域解放が行われる。
【００５２】
次に、輻輳中の無線AP配下にある端末１に端末２から着信要求があった場合の動作例１を図１２を参照して説明する。
【００５３】
図１２におけるステップ１〜ステップ４は図６におけるステップ１〜ステップ４と同じである。無線APがアクセスコントローラからQoS予約リクエストを受信した後のステップ５において、無線APは、現在割り当て可能な帯域をほとんど割り当て済みであり、QoS予約リクエストに含まれる必要帯域幅を予約することができないと判定する。すると無線APは輻輳中であることを示すQoS予約レスポンスをアクセスコントローラに返す（ステップ６）。アクセスコントローラも同様のQoS予約レスポンスをSIPサーバに返し（ステップ７）、SIPサーバはこのQoS予約レスポンスに基づき無線APが輻輳中であると判定し、端末２にビジーを送信する（ステップ８）。
【００５４】
次に、輻輳中の無線AP配下にある端末１に端末２から着信要求があった場合の動作例２を図１３、１４を参照して説明する。図１２で説明した動作例１はSIPサーバが発信端末にビジーを返す例であるが、動作例２はSIPサーバが呼の転送を行う例である。この場合、SIPサーバには端末毎にその端末に対応する転送先端末を記録した転送先テーブルが登録されているものとする。また、転送先である端末３（URI３）は有線でネットワーク接続されたVoIP端末であるものとする。
【００５５】
図１３のステップ１〜ステップ７は図１２のステップ１〜ステップ７と同じである。輻輳中であることを示すQoS予約レスポンスをSIPサーバが受信すると、ステップ８において、SIPサーバは転送先テーブルを参照し、着信先である端末１（URI１）に対応する転送先URI３を取得する。そして、SIPサーバは着信先のURI３を指定したQoS予約リクエストをアクセスコントローラに送信する（ステップ９）。アクセスコントローラはURI３の端末３を配下に持つ無線APを探すが（ステップ１０）、データベースにそのような無線APが存在せず、その旨を示すQoS予約レスポンスをSIPサーバに返す（ステップ１１）。その後、SIPサーバは通常の転送のための呼接続処理を行い（図１４のステップ１２〜ステップ１６）、端末３と端末２間での音声通信が行われる（ステップ１７）。ステップ１８〜２１で呼が切断されると、ステップ２２においてSIPサーバはQoS解放リクエストをアクセスコントローラに送信するが（ステップ２２）、アクセスコントローラでは該当無線APは見出されず（ステップ２３）、その旨のQoS解放レスポンスがSIPサーバに送信される（ステップ２４）。
【００５６】
次に、輻輳中の無線AP配下にある端末１に端末２から着信要求があった場合の動作例３を図１５を参照して説明する。動作例３ではメディアサーバが備えられ、ステップ７において輻輳中であることを示すQoS予約メッセージをSIPサーバが受信した後に、メディアサーバと端末２間が接続され（ステップ８〜ステップ１２）、メディアサーバから「輻輳中ですので接続できません」等のガイダンスが端末２に流された後（ステップ１３）、呼が切断される（ステップ１４〜ステップ１７）。
【００５７】
次に、輻輳中の無線AP配下にある端末１に端末２から着信要求があった場合の動作例４を図１６〜１８を参照して説明する。動作例４は、端末１が無線AP輻輳により接続不可能の状態にあり、端末１が通信可能になるまで待ってもらうことを通知するガイダンスを端末２に流し、無線APの輻輳が解消して端末１が通信可能になると端末１と端末２を接続するものである。
【００５８】
ステップ７において、輻輳中であることを示すQoS予約レスポンスをSIPサーバが受信すると、SIPサーバは、発／着信URI、必要帯域幅、CallIDを含むQoS予約＋通知リクエストをアクセスコントローラに送信する（ステップ８）。QoS予約＋通知リクエストは、無線APに対してQoS予約を行おうとしている帯域を通知し、その帯域を確保できるだけの空きができたらその旨を通知するよう要求するためのメッセージである。
【００５９】
ステップ９においてアクセスコントローラは該当する無線APにQoS予約＋通知リクエストを送信する。QoS予約＋通知リクエストを受信した無線APは、MS０１に対して帯域予約があったことを認識し、帯域の監視を開始するとともに（ステップ１０）、QoS予約＋通知リクエストに対するレスポンスを返す（ステップ１１、１２）。
【００６０】
一方、発信元の端末２とメディアサーバとがSIPによる所定の手順で接続され（ステップａ〜ステップｆ）、端末２にガイダンスが流される（ステップ１３）。
【００６１】
図１７において、無線APは帯域幅の空きをチェックし（ステップ１４）、要求された帯域以上の帯域が空けばその旨の通知するためのメッセージであるQoS空き通知をアクセスコントローラに送信する（ステップ１５）。この通知には呼を識別するためのCallIDが含まれる。アクセスコントローラはQoS空き通知をSIPサーバに送信し（ステップ１６）、SIPサーバからQoS空きレスポンスが返される（ステップ１７、１９）。
【００６２】
次に、SIPの所定の手順により、端末２とメディアサーバ間のセッションが終了され（ステップ２０）、端末２から端末１に対する接続処理が開始される（ステップ２１）。その後の処理（ステップ２２〜図１８のステップ３９）は図６のステップ２〜図７のステップ２０の処理と同じである。
【００６３】
次に、図１９〜図２１を参照して、他の動作例として内線グループ一斉呼び出しを行う場合の接続動作を説明する。この例では、SIPサーバが代表番号と子番号集合とを対応付けた内線グループテーブルを保持している。また、URI０を代表番号とする内線グループの端末URI１、URI２、URI３が無線AP配下に存在するものとする。
【００６４】
図１９において、SIPサーバが端末４から代表番号（URI０）を着信先として含むINVITEを受信すると（ステップ１）、SIPサーバは内線グループテーブルを参照し、URI０に対応する子番号（URI１、URI２、URI３）を抽出し、それぞれを着信先とするQoS予約リクエストをアクセスコントローラに送信する（ステップ２〜ステップ４）。アクセスコントローラは着信先毎に対応する無線APの抽出を行い（ステップ５）、MSID、必要帯域幅、CallIDを含むQoS予約リクエストを無線APに送信するが、この例では全ての着信先が同一の無線APの配下にあるので、QoS予約リクエストは全て１つの無線APに送信される（ステップ６〜ステップ８）。なお、CallIDは全ての着信先で同一である。
【００６５】
さて、代表番号での呼び出しによりその代表に属する複数の端末が呼び出されるが、発信元と接続される端末は１つだけである。従って、ステップ９において無線APはCallIDに対応付けて１回線分の帯域を予約する。
【００６６】
その後、ステップ６〜ステップ８のそれぞれに対するレスポンス（ステップ１０）、及びステップ２〜ステップ４のそれぞれに対するレスポンスが返される（ステップ１１）。
【００６７】
その後、SIPサーバは内線グループに属するそれぞれの端末に対してINVITEを送信し、各端末を鳴らす（図２０のステップ１２〜１４）。図２０の例では端末３が応答し、端末３と端末４とが接続される（ステップ１５〜ステップ１８）。その後、図７のステップ１３〜ステップ１９と同様のシーケンスで、端末３に対する無線APにおける帯域確保処理が行われる（ステップ１９〜ステップ２５）。
【００６８】
一方、図２１に示すように、端末１にはINVITEをキャンセルするためのメッセージ送受信が実行される（ステップ２６〜ステップ２９）。そして、端末１を対象とするQoS解放リクエストがSIPサーバからアクセスコントローラに送られ（ステップ３０）、アクセスコントローラから無線APに送信される（ステップ３１）。無線APは端末１のエントリを削除し（ステップ３２）、リクエストに対するレスポンスが返される（ステップ３３、３４）。端末２に対しても端末１と全く同じ処理が行われる（ステップ３５〜ステップ４３）。
【００６９】
次に、図２２〜図２５を参照して、コールパークを行う場合の接続動作例を説明する。ここでは、端末１と端末２が通話中の状態において、端末１で保留操作が行われ、メディアサーバから端末２にガイダンスが流され、その後、端末２と端末３が接続される場合の例を示している。
【００７０】
図２２のステップ２において、端末１におけるパーク保留操作が行われる。これにより、SIPの所定の手順に従ってメディアサーバと端末２とが接続され（ステップ３〜ステップ１５）、ガイダンス送出が行われる（図２３のステップ１６）。その後に接続が切断され（ステップ１７〜ステップ２０）、無線APにおいて端末１に対して確保されていた帯域の解放が行われれる（ステップ２１〜ステップ３０）。
【００７１】
一方、SIPにおける所定の手順を経て（ステップ２７〜ステップ３０）、図２４のステップ３１においてSIPサーバが端末３からINVITEを受信した後、図９のステップ２〜図１０のステップ１９と同様にして端末３を対象とした無線APにおける帯域予約及び帯域確保を含む呼接続処理が実行され、端末３と端末２間で通話が行われる（図２５のステップ５０）。
【００７２】
次に、コールウェイティングを行う場合の接続動作例について図２６〜図２８を用いて説明する。
端末１と端末２が接続中の状態において（図２６のステップ１）、端末３が端末１への接続要求であるINVITEをSIPサーバに送信する（ステップ２）。そして、SIPサーバからQoS予約リクエストが送信され（ステップ３）、これまでに説明した帯域予約と同じ処理を経て、アクセスコントローラが端末１に対するQoS予約リクエストを該当無線APに送信する（ステップ４、５）。
【００７３】
無線APでは端末１に対して１回線分の帯域が既に確保されており、ここではもう１回線分の帯域が予約される（ステップ６〜ステップ８）。
【００７４】
端末１が２回線分のセッションを張れる場合、図２７に示すように、端末１では端末２との通話を保留し、端末１と端末３との間での接続がなされる（ステップ９〜ステップ２０）。端末１が１回線分のセッションのみを張れる場合、端末１がINVITEを受信した後（図２８のステップ９）、図２２、２３のステップ２〜ステップ３０で示した処理により端末２をパーク保留し、端末１と端末３との接続が行われる（図２８のステップ１１〜ステップ２１）。
【００７５】
（装置構成概要）
次に、上述した動作を実現するためにSIPサーバ、アクセスコントローラ、無線AP、コンソールが備える主要機能について説明する。図２９は、SIPサーバ４０、アクセスコントローラ３０、無線AP１０、コンソール５０の機能概要例を説明するための図である。
【００７６】
SIPサーバ４０は、SIPに基づく呼制御を行うための呼制御機能４１に加えて、端末のSIPサーバ（レジストラ）への登録／削除をトリガーにして、アクセスコントローラに対してURI登録（有効化）／削除（無効化）のリクエストを行い、SIPメッセージ（INVITE／ＢＹＥ／レスポンスなど）をトリガーにして、アクセスコントローラに対して、QoS予約／確保／解放のリクエストを行う等の機能を有する対アクセスコントローラインタフェース機能４２を有している。
【００７７】
アクセスコントローラ３０は、SIPサーバ４０から受信した上記各リクエストに対応する処理を行い、回答（ＯＫ／ＮＧ）をSIPサーバに対して送信する対SIPサーバインタフェース機能３１、無線APに設定された上限リソースに基づき輻輳判定を行う判定機能３２、無線APから受信した端末登録／削除のリクエストに対応する処理を行う対無線APインタフェース機能３３、コンソールからの入力に応じて（ａ）端末MACアドレスとSIP−URIの対、（ｂ）無線APの最大リソース量等をデータベース３５に設定する対コンソールインタフェース機能３４、及びデータベース３５を有している。なお、この例はアクセスコントローラが各無線APの帯域を管理する場合の例である。
【００７８】
また、無線AP１０は無線AP本来の無線AP機能１１に加え、端末の無線APへの接続／切断をトリガーに、アクセスコントローラ３０に対して端末登録／削除のリクエストを行う対アクセスコントローラインタフェース機能１２を有している。
【００７９】
コンソール５０は操作者の入力を受け付けるユーザインタフェース機能５１と、設定情報をアクセスコントローラに送信する対アクセスコントローラインタフェース機能５２を有している。
【００８０】
SIPサーバ、アクセスコントローラはそれぞれＣＰＵ、記憶装置、通信用装置等を備えたコンピュータに上記各機能を実現するためのプログラムを搭載することにより実現されるものである。
【００８１】
次に、アクセスコントローラ３０が保持するデータベース３５内の端末管理データと無線AP管理データを説明する。
【００８２】
図３０に端末管理データの例を示す。ここで示す例では端末MACアドレスと端末SIP−URIとを対応付けて予めアクセスコントローラ３０のデータベース３５に固定値として登録しておく。そして、図６等で説明したシーケンスにより送受信されるデータに基づき、無線状態、呼状態、CallID、接続APを随時記録することにより端末を管理する。
【００８３】
図３０に示すデータにおける「無線状態」は端末と無線APとの接続状態を示すデータであり、端末と無線APとが接続状態にあるときは"Link Up"が記録され、切断状態にあるときは"Link Down"が記録される。また、接続状態にあるときの無線APのIDが「接続AP」に記録される。
【００８４】
「呼状態」は呼の状態を示すデータであり、呼接続無しで登録されている状態では"Register"が記録され、登録が削除された状態では"Unregister"が記録される。また、QoS予約リクエストをSIPサーバから受信し、QoS予約レスポンスをSIPサーバに返すまでのQoS予約中の状態では"QoS予約中"が記録され、QoS予約レスポンスをSIPサーバに返してからQoS確保リクエストを受信するまでは"QoS予約済"が記録され、QoS確保リクエストを受信してから、QoS確保レスポンスをSIPサーバに返すまでのQoS確保中の状態では"QoS確保中"が記録され、QoS確保レスポンスをSIPサーバに返してからQoSが確保されている状態では"QoS確保済"が記録される。
【００８５】
「CallID」は、「SIP状態」がQoS予約中／QoS予約済／QoS確保中／QoS確保済の場合にデータが記録されるものであり、呼（SIPセッション）毎のCallIDを設定する。このCallIDは一斉着信時の呼のグループ化及びQoS空きNotify()の呼の特定で利用される。
【００８６】
図３０に示したデータを参照することにより、アクセスコントローラはどの呼がどの無線APのリソースを消費するか判断できる。
【００８７】
図３１に無線AP管理データの例を示す。APIDとリソース上限値が予め登録される固定値データであり、利用中リソース量が随時変更されるデータである。
【００８８】
図３１における「APID」は無線AP毎に一意なIDであり、端末管理データの「接続AP」に登録される情報と同じものである。「リソース上限値」は無線APで利用可能なリソース上限値である。「リソース利用量」は無線APで現在使われているリソース量であり、無線APに接続された端末の呼数に応じて動的に変化するものである。この情報と「リソース上限値」との差分により、空きのリソース量を判定でき、当該無線APが輻輳するか否かを判断できる。
【００８９】
なお、無線APが無線AP管理データを保持してもよい。無線APがこの無線AP管理データを保持する場合には、無線APが輻輳判定を行い輻輳判定結果がアクセスコントローラに送信されることになる。一方、アクセスコントローラがこのデータを保持することにより、無線APに輻輳判定等の機能を設ける必要がなくなる。他の実施の形態でも同様である。
【００９０】
（アクセスコントローラ詳細機能構成）
次に、アクセスコントローラ３０の詳細機能構成を図３２を用いて説明する。図３２に示す例は輻輳判定等の無線APリソース管理をアクセスコントローラ３０が行う場合の例である。図３２に示すように、アクセスコントローラ３０はデータベース３５、SIP連携Ｉ／Ｆ６０、リソース管理機能７０、データ管理機能８０、無線AP管理機能９０、端末管理機能１００、無線AP連携Ｉ／Ｆ１１０を有している。
【００９１】
以下、各機能部の機能についてより詳細に説明する。
【００９２】
SIP連携Ｉ／Ｆ６０はSIP要求受付部６１、SIP要求返却部６２、SIP通知部６３を有している。
【００９３】
SIP要求受付部６１は端末登録要求受付部６４とリソース要求受付部６５を有している。端末登録要求受付部６４はレジストラから端末登録要求を受け付ける。また、端末登録情報を端末登録部（アプリケーション層）１０１に渡す。リソース要求受付部６５はSIPサーバ４０からリソース要求を受け付け、リソース要求種別（予約／予約＋通知／確保／解放）に応じて、リソース予約／解放部７１にリソース操作を要求する。リソース要求種別が"予約＋通知"の場合は、リソース状態変化監視部７２にリソース監視を要求する。
【００９４】
SIP要求返却部６２は端末登録要求返却部６６とリソース要求返却部６７を有しており、端末登録要求返却部６６は端末登録要求受付部６４へのリクエストの結果をレジストラに返却し、リソース要求返却部６７はリソース要求受付部６５へのリクエスト結果をSIPサーバ４０に返却する。
【００９５】
SIP通知部６３はリソース状態変化通知部６８を有しており、リソース状態変化通知部６８はリソース状態変化監視部７２からの要求に応じて、SIPサーバ４０に対してQoS空きNotify()通知を行う。
【００９６】
リソース管理機能７０はリソース予約／解放部７１とリソース状態変化監視部７２を有している。リソース予約／解放部７１はリソース要求種別（予約／確保／解放）に応じて、データ更新部８１にリソース操作を要求する。また、空きリソース量に応じて、輻輳判断も行う。例えば、上限リソース量から使用中リソース量を減算した値が、要求されたリソース量以下である場合に輻輳中であると判断する。リソース状態変化監視部７２は無線APの空きリソースを監視し、空きに状態に遷移した時に、リソース状態変化通知部６８に対して空きを通知する。
【００９７】
データ管理機能８０はデータ更新部８１を有している。データ更新部８１はデータベース３５のデータ読み出し／追加／更新／削除を行う。また、SIP−URIと端末MACアドレスとの相互変換を行う。無線AP管理機能９０は無線AP／リソース登録部９１を有している。無線AP／リソース登録部９１は無線APの登録及び当該無線APに対するリソース上限値をコンソール５０からの指示に基づきデータベース３５に設定する。
【００９８】
端末管理機能１００は端末登録部（アプリケーション層）１０１と端末登録部（データリンク層）１０２を有している。端末登録部（アプリケーション層）１０１は端末登録要求受付部６４から、リソース管理対象端末のSIP−URIを受け取り、データ更新部８１に対してデータ登録を要求する。当該処理により、SIP−URIが本システムで有効化される。また、端末登録部（データリンク層）１０２は端末MAC登録要求受付部１１１から、リソース管理対象端末のMACアドレスを受け取り、データ更新部８１に対してデータ登録を要求する。当該処理により、端末MACアドレスが本システムで有効化される。
【００９９】
無線AP連携Ｉ／Ｆ１１０は端末MAC登録要求受付部１１１を有している。端末MAC登録要求受付部１１１は無線APで発生する端末イベント（Association/Disassociation/Reassociation）を契機として、イベントを受け付け、当該イベントの種別に応じて、端末登録部（データリンク層）１０２に対して、端末MACアドレスの登録／削除／再登録を要求する。
【０１００】
なお、上述した機能構成は一例に過ぎない。本実施の形態で説明した動作を実現できる構成であればどのような構成でもよい。このことは他の実施の形態についても同様である。
【０１０１】
＜第２の実施の形態＞
次に、本発明の第２の実施の形態について説明する。第２の実施の形態では、ハンドオーバ時の問題を解決するための方式について説明する。
【０１０２】
第１の実施の形態では、無線APにおける呼の帯域確保はSIPシーケンスを契機として行われるが、ハンドオーバ時には呼の開始／終了を伴わないため、SIPシーケンスは発生しない。そこで、第２の実施の形態では、無線リンク再接続要求（Reassociation）を契機として移動先無線APの帯域確保等を行っている。
【０１０３】
ある無線AP１０を介して他の端末２と通話中の端末１が他の無線AP２０の配下に移動することによりハンドオーバする際の本実施の形態におけるシステムの全体動作フローを図３３を参照して説明する。
【０１０４】
端末１が他の無線AP２０の配下に移動し、移動先の無線AP２０が輻輳中でなければ（ステップ１のNo）、ハンドオーバは完了する（ステップ２）。移動先の無線AP２０が輻輳中の場合（ステップ１のYes）、当該無線AP２０は端末１との無線リンクを切断し、端末に対して隣接無線AP２５に接続するよう促し、端末１は隣接無線APへの無線リンク接続を行う（ステップ４）。ただし、無線リンク切断／接続リトライは予め定めたリトライ回数まで行い、リトライ回数が予め定めた規定値に達した場合には（ステップ３のYes）、アクセスコントローラはハンドオーバ失敗であると判定し、通話相手の端末に対し、ガイダンスを送出するなどの呼処理を実施する（ステップ５）。
【０１０５】
なお、本実施の形態において、輻輳中の無線AP２０に隣接する無線APとは、無線AP２０の配下に存在する端末から見て、電波到達範囲がVoIP通信時に通信品質が保てる範囲にある無線AP２０以外の無線APの他、端末がある程度移動することにより、電波到達範囲がVoIP通信時に通信品質が保てる範囲となる無線APを含むものとする。このことは、第３の実施の形態でも同様である。
【０１０６】
次に、図３４を参照して、移動先の無線AP２０が輻輳状態にある場合に、すぐに端末２に対する呼処理を行う場合を例にとり、本実施の形態におけるシステムの動作の概要について説明する。基本的なシステム構成は第１の実施の形態におけるシステム構成と同じであり、図３４では、アクセスコントローラ３０に無線AP１０と無線AP２０が接続され、端末１が無線AP１０の配下から無線AP２０の配下に移動する場合を示している。図３４の例では、移動先の無線AP２０が輻輳状態にあるものとする。
【０１０７】
まず、端末１は無線AP１０を介して端末２と通話中であるものとする（ステップA）。そして、端末１が無線AP２０の配下に移動すると、ハンドオーバの機能により、端末１は無線AP２０に対して再接続要求を送信する（ステップB）。この要求を契機として、アクセスコントローラ３０は、無線AP１０に対して端末１に対して割り当てられていた帯域を解放するための帯域解放要求を送信し、無線AP１０は帯域を解放する（ステップC）。
【０１０８】
また、アクセスコントローラ３０は、無線AP２０に帯域確保要求を送信するが、図３４の状態では無線AP２０は輻輳状態にあるため、帯域確保に失敗する（ステップD）。すると、アクセスコントローラ３０はハンドオーバ失敗通知をSIPサーバ４０に送信し（ステップE）、SIPサーバ４０は端末２に対して呼処理を実施する（ステップF）。
【０１０９】
以下、本実施の形態における処理の詳細を図３５〜図４８を参照して説明する。なお、図３５〜図４８において、レジスターはSIPサーバに含まれているものとする。また、アクセスコントローラが保持する端末管理データを、呼状態管理テーブルとして示している。また、動作の前提として、保守端末からアクセスコントローラに、リトライ規定値（上限値）と、再接続要求拒否時間が登録されるものとする。この登録は、端末毎にしてもよいし、全ての端末に共通の値として設定してもよい。また、無線AP毎に設定してもよい。
【０１１０】
まず、図３５〜図３７を参照して移動先の無線AP２０が輻輳中でない場合について説明する。
【０１１１】
図３５において、端末１と端末２の間で、第１の実施の形態で説明したシーケンス（図６のステップ１〜図７のステップ１９等）を実施したことにより通信がなされているものとする（ステップ１）。ここで、端末１が無線AP１０の配下から無線AP２０の配下に移動する（ステップ２）。端末１は再接続要求（Reassociation）を無線AP２０に送信し（ステップ３）、無線AP２０は端末１のMACアドレス（MSID）を取得し、登録する（ステップ４）。無線AP２０は無線AP２０のID（AP０２）と端末１のMACアドレス（MS０１）とを含む端末登録リクエストをアクセスコントローラに対して送信する（ステップ５）。アクセスコントローラは無線AP２０から受信した無線AP２０のID（AP０２）を端末１のMACアドレス（MS０１）と対応付けて記憶装置に格納することにより登録の更新を行う（ステップ６）。なお、現時点での端末１に対する呼状態は"QoS確保済"である。そして、アクセスコントローラは無線AP２０に対して端末登録レスポンスを返す（ステップ７）。
【０１１２】
本実施の形態では、アクセスコントローラは、「QoS確保済」である端末に関する端末登録リクエストを受信した場合は、SIPサーバからのトリガーを受けることなく、ハンドオーバ前の無線AP１０に対して、当該端末１に関するQoS解放リクエストを送信する（ステップ８、９）。このリクエストを受けた無線AP１０は、端末１に対する帯域を解放し、QoS解放レスポンスをアクセスコントローラに送信する（ステップ１０、１１）。
【０１１３】
続いて、アクセスコントローラは、MS０１と必要帯域幅を含むQoS確保リクエストを無線AP２０に送信する（ステップ１２）。なお、端末１と端末２の間で必要な帯域幅は既に確定しているため、QoS予約シーケンスは実施しない。
【０１１４】
ステップ１３にて、無線AP２０において端末１に対する帯域確保がなされ、QoS確保レスポンスがアクセスコントローラに送信される（ステップ１４）。その後、無線AP２０を介して端末１と端末２間での通話が行われる。
【０１１５】
ステップ１６からの処理は呼切断の処理を示している。ステップ１６〜ステップ１９において、通常のSIPによるシーケンス処理が行われることにより、SIPサーバは呼を切断する。ステップ２０において、SIPサーバはQoS解放リクエストをアクセスコントローラに送信する。アクセスコントローラは該当の無線AP２０を抽出し（ステップ２１）、QoS解放リクエストを無線AP２０に送信する（ステップ２２）。無線AP２０は今までMS０１に対して確保していた帯域を解放し（ステップ２３）、QoS解放レスポンスをアクセスコントローラに返し（ステップ２４）、アクセスコントローラは、端末１に対する「呼状態」を"無し"にするとともに、QoS解放レスポンスをSIPサーバに返す（ステップ２５）。
【０１１６】
次に、最初の移動先の無線AP２０が輻輳中であるが、隣接無線AP２５に接続することによりハンドオーバが成功する場合の動作例を図３８〜図４０を参照して説明する。
【０１１７】
図３８のステップ２〜図３９のステップ１１において、図３５のステップ２〜ステップ１１と同様にしてアクセスコントローラに無線AP２０についての端末登録がなされ、無線AP１０に対する帯域解放がなされる。
【０１１８】
図３９のステップ１１で、QoS解放レスポンスを受信したアクセスコントローラは、端末１に対する呼状態を"ハンドオーバ中"にする。そして、アクセスコントローラは、QoS確保リクエストを無線AP２０に送信する（ステップ１２）。ここでは、無線AP２０は、現在割り当て可能な帯域をほとんど割り当て済みであり、QoS確保リクエストに含まれる必要帯域幅を予約することができないと判定する（ステップ１３）。すると無線AP２０は、輻輳中であることを示すQoS確保レスポンスをアクセスコントローラに返す（ステップ１４）。
【０１１９】
アクセスコントローラは、ハンドオーバ後において、無線APが輻輳中であった回数をカウントする。つまり、ステップ１５では、"１"をカウントする。この"１"は、１回リトライに失敗したことを示す。なお、この例では、最初のハンドオーバを行って、移動先の無線APに接続することも"リトライ"に入れているが、最初のハンドオーバに失敗した後のリトライからカウントを開始することとしてもよい。そして、この数値と予め定めた数値とを比較し、この数値が予め定めた数値に達していた場合は、後述する呼処理に移る。このような判定処理は、リトライが永久に続くことを防止するために行われる。図３９の場合は、予め定めた数値は１より大きい数値であるものとし、１回目のリトライ失敗であるから、呼処理に移行せずに、再接続のための処理に移行する。
【０１２０】
ステップ１６にて、アクセスコントローラは、MS０１と再接続要求拒否時間を含む無線リンク切断要求を無線AP２０に送信する。無線AP２０は、端末１に対する再接続要求拒否時間を設定する（図４０のステップ１７）。これにより、無線AP２０は、端末１から再度接続要求を受けた場合でも、再接続要求拒否時間内であれば、その接続要求を拒否する。つまり、接続要求を受けてもその後の動作を行わない。
【０１２１】
無線リンク切断要求を受信した無線AP２０は、無線リンク切断指示（Disassociation）を端末１に送信することにより無線リンクを切断する（ステップ１８）。無線リンクを切断された端末１は、無線AP２０に隣接する無線APである無線AP２５に接続要求（Association）を送信する。なお、端末１の仕様によっては、再度数回無線AP２０への接続を試み、接続に失敗した場合に隣接無線APへの接続を行う場合があるが、再接続要求拒否時間の間は、無線AP２０から再度端末登録リクエストが送信されることはない。
無線AP２５は端末１のMACアドレス（MSID）を取得し、登録する（ステップ２０）。無線AP２５は無線AP２５のID（AP０３）と端末１のMACアドレス（MS０１）とを含む端末登録リクエストをアクセスコントローラに対して送信する（ステップ２１）。アクセスコントローラは無線AP２５から受信した無線AP２５のID（AP０３）を端末１のMACアドレス（MS０１）と対応付けて記憶装置に格納することにより登録の更新を行う（ステップ２２）。そして、アクセスコントローラは無線APに対して端末登録レスポンスを返す（ステップ２３）。
【０１２２】
本実施の形態では、アクセスコントローラは、「ハンドオーバ中」である端末に関する端末登録リクエストを受信した場合は、SIPサーバからのトリガーを受けることなく、端末登録リクエストを送信した無線AP２５に対して、MS０１と必要帯域幅を含むQoS確保リクエストを送信する（ステップ２４、２５）。
【０１２３】
ステップ２６にて、無線AP２５において端末１に対する帯域確保がなされ、QoS確保レスポンスがアクセスコントローラに送信される（ステップ２７）。アクセスコントローラは端末１に対する「呼状態」を"QoS確保済"とし、その後、無線AP２５を介して端末１と端末２間での通話が行われる。呼切断の処理は図３６、３７で説明した処理と同様である。
【０１２４】
次に、図４１〜図４２を参照して、端末１がハンドオーバに失敗し、通話相手端末に対する呼制御が行われる場合の動作例１を説明する。
【０１２５】
移動先の無線AP２０が輻輳中であることから、図３８のステップ２〜図４０のステップ２５までの処理が行われたものとする。
【０１２６】
ステップ２５において、QoS確保リクエストを受信した無線AP２５は、現在割り当て可能な帯域をほとんど割り当て済みであり、QoS確保リクエストに含まれる必要帯域幅を予約することができないと判定する（図４１のステップ２６）。すると無線AP２５は輻輳中であることを示すQoS確保レスポンスをアクセスコントローラに返す（ステップ２７）。
【０１２７】
本動作例１では、リトライ回数の規定値が２と設定されているものとする。図４２のステップ２８において、アクセスコントローラはリトライ回数のカウント値を"２"とし、規定値と比較し、リトライ回数が規定値に達したと判定したため、呼状態管理テーブルの「呼状態」を"無し"に変更する。
【０１２８】
そして、アクセスコントローラは、端末１のURLであるURL１と、ハンドオーバの失敗理由である"輻輳"を含むハンドオーバ失敗通知をSIPサーバに送信する。本動作例１では、ハンドオーバ失敗通知を受信したSIPサーバは、Byeにより正常終了処理を行う（ステップ３０〜ステップ３３）
ハンドオーバ失敗通知を受領した後のSIPサーバの動作には種々のバリエーションがあり、これらのバリエーションのうちどの動作を用いるかは、SIPサーバに予め設定しておくことができる。
次に、ハンドオーバ失敗通知を受領した後のSIPサーバの動作例２を図４３、４４を参照して説明する。図４３、４４では、無線AP２０が輻輳したときにハンドオーバ失敗と判定する例を示している。ハンドオーバ失敗通知をSIPサーバに送信するまでの処理についてはこれまでに説明したとおりである。
【０１２９】
動作例２では、端末１から他の端末への転送が行われる。本動作例では、第１の実施の形態における図１３で示した場合と同様に、SIPサーバには端末毎にその端末に対応する転送先端末を記録した転送先テーブルが登録されているものとする。また、端末１の転送先である端末３（URI３）は有線でネットワーク接続されたVoIP端末であるものとする。
【０１３０】
端末１からByeに対する応答を受信した後（図４３のステップ３）、SIPサーバは、転送先テーブルを参照し、着信先である端末１（URI１）に対応する転送先URI３を取得する（ステップ４）。そして、SIPサーバは、端末２に対して端末３への接続換えを要求するSIPシーケンスを実行し（ステップ５〜ステップ８）、着信先のURI３を指定したQoS予約リクエストをアクセスコントローラに送信する（ステップ９）。アクセスコントローラはURI３の端末３を配下に持つ無線APを探すが（ステップ１０）、データベースにそのような無線APが存在せず、その旨を示すQoS予約レスポンスをSIPサーバに返す（ステップ１１）。その後、SIPサーバは通常の転送のための呼接続処理を行い（図４４のステップ１２〜ステップ１６）、端末３と端末２間での音声通信が行われる（ステップ１７）。ステップ１８〜２１で呼が切断されると、ステップ２２においてSIPサーバはQoS解放リクエストをアクセスコントローラに送信するが（ステップ２２）、アクセスコントローラでは該当無線APは見出されず（ステップ２３）、その旨のQoS解放レスポンスがSIPサーバに送信される（ステップ２４）。
次に、ハンドオーバ失敗通知を受領した後のSIPサーバの動作例３を図４５を参照して説明する。
動作例３ではメディアサーバが備えられ、ステップ３においてByeに対する応答をSIPサーバが受信した後に、メディアサーバと端末２間が接続され（ステップa〜ステップi）、メディアサーバから「輻輳中ですので接続できません」等の終話を促すガイダンスが端末２に流された後（ステップj）、端末２からの終話によって呼が切断される（ステップk〜ステップn）。
次に、ハンドオーバ失敗通知を受領した後のSIPサーバの動作例４を図４６〜図４８を参照して説明する。
動作例４では、端末１が通信可能になるまで待ってもらうことを通知するガイダンスを端末２に流し、無線AP２０の輻輳が解消して端末１が通信可能になったら端末１と端末２を接続するものである。
【０１３１】
ステップ３において、Bye に対する応答をSIPサーバが受信すると、SIPサーバは、発／着信URI、必要帯域幅、CallIDを含むQoS予約＋通知リクエストをアクセスコントローラに送信する（ステップ４）。QoS予約＋通知リクエストは、無線APに対してQoS予約を行おうとしている帯域を通知し、その帯域を確保できるだけの空きができたらその旨を通知するよう要求するためのメッセージである。
【０１３２】
ステップ５においてアクセスコントローラは該当する無線AP２０にQoS予約＋通知リクエストを送信する。QoS予約＋通知リクエストを受信した無線AP２０は、MS０１に対して帯域予約があったことを認識し、帯域の監視を開始するとともに（ステップ６）、QoS予約＋通知リクエストに対するレスポンスを返す（ステップ７、８）。
【０１３３】
一方、端末２とメディアサーバとがSIPによる所定の手順で接続され（ステップａ〜ステップi）、端末２に、無線AP２０のリソースが空くまで待機中であることを通知するためのガイダンスが流される（ステップj）。
【０１３４】
図４７において、無線AP２０は帯域幅の空きをチェックし（ステップ９）、要求された帯域以上の帯域が空けばその旨の通知するためのメッセージであるQoS空き通知をアクセスコントローラに送信する（ステップ１０）。この通知には呼を識別するためのCallIDが含まれる。アクセスコントローラはQoS空き通知をSIPサーバに送信し（ステップ１１）、SIPサーバからQoS空きレスポンスが返される（ステップ１２〜１４）。
【０１３５】
次に、SIPサーバは、端末２に、端末１への再接続のためのSIPメッセージを送信し、接続替えのためのSIPシーケンスを実行する（ステップ１５〜ステップ１９）。そして、第１の実施の形態における、端末２から端末１への着信の場合と同様の手順を経て（図４７のステップ２０〜図４８のステップ３６）、端末１と端末２間での通話が行われる（ステップ３７）。
【０１３６】
（装置構成について）
第２の実施の形態における装置の機能概要を図４９を参照して説明する。第２の実施の形態における装置の基本的な構成は第１の実施の形態における装置構成と同様である。以下、第１の実施の形態の装置と異なる主な点について説明する。
【０１３７】
SIPサーバ４０における呼制御機能４１は、ハンドオーバ失敗時の呼制御処理を実行する機能も有している。アクセスコントローラ３０は、第１の実施の形態で説明した機能に加えて、無線リンクリトライ判定機能３６とハンドオーバ成否判定機能３７を有している。無線リンクリトライ判定機能３６は、無線リンクリトライの失敗回数をカウントし、予め設定した回数に達したかどうかの判定を行う。ハンドオーバ成否判定機能３７は、端末のハンドオーバ時にハンドオーバが成功したかどうかの判定を行う。具体的には、無線リンクリトライ判定機能３６により、無線リンクリトライの失敗回数が予め設定した回数に達したと判定された場合に、ハンドオーバに失敗したと判定し、その旨をSIPサーバ４０に通知する。また、本実施の形態における判定機能３２は、端末の呼接続要求時に無線APの輻輳判定を行う機能も有している。
【０１３８】
図５０に、本実施の形態での端末管理データを示す。本実施の形態では、呼状態として、「ハンドオーバ中」を含む。アクセスコントローラは、ハンドオーバ時において、ハンドオーバ前の無線APにおける帯域が解放されたことに応じて呼状態を「ハンドオーバ中」とする。そして、ハンドオーバ時において、ハンドオーバ先の無線APでの帯域が確保されたことに応じて、呼状態を「ハンドオーバ中」から「QoS確保済」にする。
【０１３９】
また、本実施の形態における端末管理データは、端末毎の無線リンクリトライ回数（上限値）と、実際の無線リンクリトライ回数を含む。実際の無線リンクリトライ回数が上限値に達した場合にハンドオーバ失敗と判定される。
【０１４０】
図５１に、本実施の形態における再接続要求拒否時間管理用の無線AP管理データを示す。図５１に示すように、無線AP毎及び端末毎に、再接続要求拒否時間と、無線リンクを切断してから実際に経過した時間である再接続要求拒否経過時間が記録される。
【０１４１】
図５２に、本実施の形態におけるアクセスコントローラの詳細機能構成図を示す。以下、第１の実施の形態と異なる部分について説明する。
【０１４２】
SIP要求返却部６２は、ハンドオーバ失敗であることをSIPサーバに通知するハンドオーバ失敗通知部６９を有する。また、リソース予約／解放部７１は、第１の実施の形態の機能に加え、端末のハンドオーバ時に、無線APのリソースを調べ、輻輳状態かどうかを判定する機能を有している。また、リソース管理機能７０は、ある端末の無線リンクリトライ回数が、予め定めた上限値に達したかどうかを判定する無線リンクリトライ判定部７３を有している。
【０１４３】
また、データ更新部８１は、第１の実施の形態で説明した機能に加え、端末のハンドオーバ時に、移動元無線APのリソース解放後、端末の呼状態を「ハンドオーバ中」とする機能を備えている。また、無線AP連携I／F１１０は、無線リンク切断要求部１１２を有している。無線リンク切断要求部１１２は、ハンドオーバ時に、再接続先の無線APのリソースが確保できなかった際に、端末を他の隣接無線APへ再接続させるために、再接続先の無線APに無線リンク切断要求を送信するものである。
【０１４４】
＜第３の実施の形態＞
次に、本発明の第３の実施の形態について説明する。第１の実施の形態では、輻輳中の無線APに接続された端末に対して他の端末から着信があった場合に、当該他の端末に対してガイダンスを流す等の呼制御を行う例を説明した。
【０１４５】
ある無線APが輻輳していても、隣接する無線APは輻輳中でない場合があるが、第１の実施の形態では隣接する無線APを有効に活用できていない。そこで、本実施の形態では、輻輳中の無線APに隣接する無線APを用いて通信を継続する例について説明する。
【０１４６】
まず、図５３を参照して、輻輳中の無線AP１０に接続された端末１に端末２から着信があった場合のシステムの動作概要について説明する。
【０１４７】
まず、端末１は無線AP１０と無線リンクで接続中であるものとする。端末２が端末１に対する接続要求を送信すると（ステップA）、SIPサーバ４０は帯域予約要求をアクセスコントローラ３０に送信する（ステップB）。アクセスコントローラ３０は、無線AP１０に対して帯域予約要求を送信するが、無線AP１０は輻輳中であるため帯域予約に失敗する（ステップC）。そして、アクセスコントローラ３０は、端末１が隣接無線APへ切替中である旨をSIPサーバ４０に通知する（ステップD）。その後、アクセスコントローラ３０は端末１に対する無線リンク切断要求を無線AP１０に送信し、無線AP１０は端末１との無線リンクを切断する（ステップE）。
【０１４８】
無線AP１０との無線リンクを切断された端末１は、隣接無線AP２０と無線リンク接続する（ステップF）。すると、アクセスコントローラ３０は、無線AP２０からの端末登録要求に応じて無線AP２０に対する帯域予約を行い、帯域予約に成功すると（ステップG）、SIPサーバ４０にその旨を通知し（ステップH）、SIPサーバ４０は呼接続シーケンスを再開し、端末１と端末２が接続される（ステップI）。
【０１４９】
次に、図５４を参照して、輻輳中の無線AP１０に接続された端末１が端末２に発信する場合におけるシステムの動作概要を説明する。
【０１５０】
まず、端末１は無線AP１０と無線リンクで接続中であるものとする。端末１が端末２に対する接続要求を送信すると（ステップA）、帯域予約要求が送信されるが（ステップB）、無線AP１０は輻輳中であるため帯域予約に失敗する（ステップC）。また、アクセスコントローラ３０は、SIPサーバ４０に対して、端末１が隣接無線APへ切替中である旨を通知する（ステップD）。
【０１５１】
すると、SIPサーバ４０は、端末１に対して呼接続のキャンセル通知を行うとともに（ステップE）、アクセスコントローラ３０は、無線AP１０に、端末１に対する無線リンク切断要求を送信し、無線AP１０が端末１との無線リンクを切断する（ステップF）。
【０１５２】
無線リンクを切断された端末１は、隣接無線AP２０と無線リンク接続する（ステップG）。そして、端末１に対してユーザによる操作がなされることにより、端末１は端末２に対する接続要求を送信する（ステップH）。そして、帯域確保が行われて（ステップI）、端末１と端末間の呼が確立される（ステップJ）。なお、上記の方式では、一度呼を切断しているが、端末１の機能により、呼の切断を行わずに呼を継続することも可能である。
【０１５３】
以下、本実施の形態におけるシステムの動作を詳細に説明する。
【０１５４】
本実施の形態において、無線APが輻輳中でない場合において、端末２から端末１に着信があった場合の動作は第１の実施の形態において図６〜図８に示したとおりである。
【０１５５】
また、無線APが輻輳中でない場合において、端末１から端末２に発信がなされた場合における動作は第１の実施の形態において図９〜図１１に示したとおりである。
【０１５６】
輻輳中の無線AP１０に隣接して、輻輳中でない無線AP２０が存在する環境の下で、無線AP１０に接続された端末１に端末２から着信があった場合のシステムの動作について図５５〜図５７を参照して詳細に説明する。
図５５におけるステップ１〜ステップ４は図６におけるステップ１〜ステップ４と同じである。無線AP１０がアクセスコントローラからQoS予約リクエストを受信した後のステップ５において、無線AP１０は、現在割り当て可能な帯域をほとんど割り当て済みであり、QoS予約リクエストに含まれる必要帯域幅を予約することができないと判定する。すると無線AP１０は輻輳中であることを示すQoS予約レスポンスをアクセスコントローラに返す（ステップ６）。アクセスコントローラは、呼状態管理テーブルにおける端末１の呼状態を「隣接無線APへ切替中」とし、端末１が隣接無線APへ切替中であることを示す情報を含むQoS予約レスポンスをSIPサーバに返す（ステップ７）。
【０１５７】
アクセスコントローラは、端末が無線APに接続後、無線APが輻輳中であった回数をカウントする。つまり、ステップ８では、"１"をカウントする。この"１"は、１回リトライに失敗したことを示す。なお、この例では、最初の接続を行うことも"リトライ"に入れているが、最初の接続に失敗した後のリトライからカウントを開始することとしてもよい。そして、この数値と予め定めた数値とを比較し、この数値が予め定めた数値に達していた場合は、後述する呼処理に移る。このような判定処理は、リトライが永久に続くことを防止するために行われる。図５５の場合は、予め定めた数値は１より大きい数値であるものとし、１回目のリトライ失敗であるから、再接続のための処理に移行する。
【０１５８】
図５６のステップ９にて、アクセスコントローラは、MS01と再接続要求拒否時間を含む無線リンク切断要求（隣接無線AP移動指示に相当する）を無線AP１０に送信する。無線AP１０は、端末１に対する再接続要求拒否時間を設定する（ステップ１０）。これにより、無線AP１０は、端末１から再度接続要求を受けた場合に、再接続要求拒否時間内であれば、その接続要求を拒否する。つまり、接続要求を受けても接続動作を行わない。
【０１５９】
無線リンク切断要求を受信した無線AP１０は、無線リンク切断指示（Disassociation）を端末１に送信することにより無線リンクを切断する。無線リンクを切断された端末１は、隣接する無線APである無線AP２０に接続要求（Association）を送信する（ステップ１２）。なお、端末１の仕様によっては、無線AP１０への接続を再度試みる場合があるが、その場合でも、再接続要求拒否時間の間は、無線AP１０から再度端末登録リクエストが送信されることはない。
【０１６０】
無線AP２０は、端末１のMSIDであるMS01を登録する（ステップ１３）。そして、無線AP２０は無線AP２０のID（AP０２）と端末１のMACアドレス（MS０１）とを含む端末登録リクエストをアクセスコントローラに対して送信する（ステップ１４）。アクセスコントローラは無線AP２０から受信した無線APのID（AP０２）と端末１のMACアドレス（MS０１）とを記憶装置に格納することにより、MSIDとAPIDの更新を行う。（ステップ１５）。そして、アクセスコントローラは無線AP２０に対して端末登録レスポンスを返す（ステップ１６）。アクセスコントローラは、端末１に対する呼状態を"無し"にする（ステップ１７）。
【０１６１】
その後、無線AP２０に関し、帯域予約が行われ（図５７のステップ１８〜２１）、図６のステップ８〜図７のステップ１９と同様の処理が実行されて、端末１と端末２間での呼接続が行われる。
【０１６２】
次に、無線AP１０が輻輳中であるとともに、隣接無線AP２０も輻輳中であり、呼の中断を行う場合の動作を図５８を参照して説明する。
【０１６３】
端末２からのINVITE送信から、無線AP２０及びアクセスコントローラに対する端末再登録までの処理は図５５、図５６に示した処理と同じである。
【０１６４】
図５８において、アクセスコントローラは、無線AP２０に対してQoS予約リクエストを送信する（ステップ１８）。無線AP２０は輻輳中なので、輻輳中であることを示すQoS予約レスポンスをアクセスコントローラに返す（ステップ１９、２０）。アクセスコントローラは、現在のリトライ回数と、リトライ回数の上限値とを比較し、現在のリトライ回数（＝２）が予め規定したリトライ回数（＝２）に達したと判定し、リトライを失敗したと判定する（ステップ２１）。そこで、アクセスコントローラは、SIPサーバに対して輻輳中であることを示す情報を含むQoS予約レスポンスを返す（ステップ２２）。当該QoS予約レスポンスを受信したSIPサーバは、「呼の中断」を示すメッセージを端末に送信する（ステップ２３）。
【０１６５】
なお、当該QoS予約レスポンスを受信したSIPサーバは、第１の実施の形態と同様の呼制御を端末２に対して行ってもよい。
【０１６６】
次に、輻輳中の無線AP１０に隣接して、輻輳中でない無線AP２０が存在する環境の下で、無線AP１０に接続された端末１が端末２に発信を行う場合のシステムの動作について図５９、６０を参照して詳細に説明する。
【０１６７】
図５９におけるステップ１〜ステップ４は図６におけるステップ１〜ステップ４と同じである。無線AP１０がアクセスコントローラからQoS予約リクエストを受信した後のステップ５において、無線AP１０は、輻輳中であり、QoS予約リクエストに含まれる必要帯域幅を予約することができないと判定する（ステップ５）。すると無線AP１０は輻輳中であることを示すQoS予約レスポンスをアクセスコントローラに返す（ステップ６）。
【０１６８】
アクセスコントローラは、呼状態管理テーブルにおける端末１の呼状態を「隣接無線APへ切替中」とし、端末１が隣接無線APへ切替中であることを示す情報を含むQoS予約レスポンスをSIPサーバに返す（ステップ７）。このQoS予約レスポンスを受信したSIPサーバは、呼の中断を行うためのメッセージを端末１に送信する（ステップ８）。また、アクセスコントローラは、MS01と再接続要求拒否時間を含む無線リンク切断要求（隣接無線AP移動指示に相当する）を無線AP１０に送信する（ステップ１０）。無線AP１０は、端末１に対する再接続要求拒否時間を設定する（ステップ１１）。これにより、無線AP２０は、端末１から再度接続要求を受けた場合に、再接続要求拒否時間内であれば、その接続要求を拒否する。つまり、接続要求を受けても接続動作を行わない。
【０１６９】
無線リンク切断要求を受信した無線AP１０は、無線リンク切断指示（Disassociation）を端末１に送信することにより無線リンクを切断する（ステップ１２）。無線リンクを切断された端末１は、隣接する無線APである無線AP２０に接続要求（Association）を送信する（ステップ１３）。
【０１７０】
無線AP２０は、端末１のMSIDであるMS01を登録する（ステップ１４）。そして、無線AP２０は無線APのID（AP０２）と端末１のMACアドレス（MS０１）とを含む端末登録リクエストをアクセスコントローラに対して送信する（ステップ１５）。アクセスコントローラは無線AP２０から受信した無線APのID（AP０２）と端末１のMACアドレス（MS０１）とを記憶装置に格納することにより、MSIDとAPIDの更新を行う。（ステップ１６）。そして、アクセスコントローラは無線APに対して端末登録レスポンスを返す（ステップ１７）。アクセスコントローラは、端末１に対する呼状態を"無し"にする。
【０１７１】
そして、端末１でユーザによる再操作がなされることにより、端末１からINVITEメッセージがSIPサーバに対して送信される（ステップ１９）。その後は、無線AP２０に関し、図９のステップ１〜図１０のステップ１９と同様の処理が実行されて、端末１と端末２間での呼接続が行われる。
【０１７２】
上記の場合において、無線AP２０も輻輳中である場合は、無線AP２０に対して図５９のステップ１〜図６０のステップ８の処理が実行され、端末１の接続が切断されることになる。その後、図６０のステップ１２が実行され、それ以降の処理が、隣接無線APに対してなされることになる。なお、発信の場合も、輻輳中であることを示すQoS予約レスポンスを受信したアクセスコントローラがリトライ回数をカウントし、それが上限値に達している場合には、無線リンク切断要求（隣接無線AP移動指示）を送信しないこととすることができる。
【０１７３】
（装置構成について）
第３の実施の形態における装置の機能概要を図６１を参照して説明する。第３の実施の形態における装置の基本的な構成は第１の実施の形態における装置構成と同様である。以下、第１の実施の形態の装置と異なる主な点について説明する。
【０１７４】
アクセスコントローラ３０は、第１の実施の形態で説明した機能に加えて、呼接続制御機能３８と端末制御機能３９を有している。呼接続制御機能３８は、無線APの輻輳を検出した場合に、SIPサーバからのQoS予約リクエストに対する応答として"隣接無線APへ切替中"を示す応答メッセージを返す機能を含む。また、端末制御機能３９は、無線APの輻輳検出時に無線リンク切断要求を送信する機能、及び無線リンクリトライの失敗回数をカウントし、予め設定した回数に達したかどうかの判定を行う。ハンドオーバ成否判定機能３７は、端末のハンドオーバ時にハンドオーバが成功したかどうかの判定を行う。
【０１７５】
図６２に、本実施の形態での端末管理データを示す。本実施の形態では、呼状態として、「隣接無線APへ切替中」を含む。アクセスコントローラは、端末が接続する無線APが輻輳中であることを検知したことに応じて呼状態を「隣接無線APへ切替中」とする。ただし、リトライ回数が上限値に達していた場合は、切替のための動作を行わないので、呼状態は無しとする。そして、隣接無線APに対する端末の登録が済んだことを契機として、呼状態を「隣接無線APへ切替中」から「無し」にする。
【０１７６】
また、本実施の形態における端末管理データは、端末毎の無線リンクリトライ回数（上限値）と、実際の無線リンクリトライ回数を含む。実際の無線リンクリトライ回数が上限値に達した場合に呼接続失敗と判定される。
【０１７７】
図６３に、本実施の形態における再接続要求拒否時間管理用の無線AP管理データを示す。図６３に示すように、無線AP毎及び端末毎に、再接続要求拒否時間と、無線リンクを切断してから実際に経過した時間である再接続要求拒否経過時間が記録される。
【０１７８】
図６４に、本実施の形態におけるアクセスコントローラの詳細機能構成図を示す。以下、第１の実施の形態と異なる部分について主に説明する。
【０１７９】
SIP要求返却部６２におけるリソース要求返却部６７は、無線APが輻輳中である場合に、SIPサーバに"隣接無線APへ切替中"である旨を通知する機能を含む。また、リソース予約／解放部７１は、無線APのリソースを調べ、輻輳状態かどうかを判定し、服装状態である場合に、無線リンク切断を要求する機能を有している。また、リソース管理機能７０は、ある端末の無線リンクリトライ回数が、予め定めた上限値に達したかどうかを判定する無線リンクリトライ判定部７３を有している。
【０１８０】
また、データ更新部８１は、無線APが輻輳中である場合に、端末の呼状態を「隣接無線APへ切替中」とする機能を備えている。また、無線AP連携I／F１１０は、無線リンク切断要求部１１２を有している。無線リンク切断要求部１１２は、無線APが輻輳状態にあるときに、端末を他の隣接無線APへ再接続させるために、無線APに無線リンク切断要求を送信するものである。
【０１８１】
なお、本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内において、種々変更・応用が可能である。
【図面の簡単な説明】
【０１８２】
【図１】従来の無線ＩＰ電話システムの構成例を示す図である。
【図２】本発明の実施の形態におけるシステムの一例を示す図である。
【図３】本発明の第１の実施の形態におけるシステムの動作概要を説明するための図である。
【図４】本発明の第１の実施の形態において、端末１をアクセスコントローラに登録するためのシーケンス図である。
【図５】本発明の第１の実施の形態において、アクセスコントローラから登録された端末１を削除するためのシーケンス図である。
【図６】本発明の第１の実施の形態において、輻輳状態に無い無線AP配下の端末１に端末２から着信要求がなされた場合のシーケンス図である。
【図７】本発明の第１の実施の形態において、輻輳状態に無い無線AP配下の端末１に端末２から着信要求がなされた場合のシーケンス図である。
【図８】本発明の第１の実施の形態において、輻輳状態に無い無線AP配下の端末１に端末２から着信要求がなされた場合のシーケンス図である。
【図９】本発明の第１の実施の形態において、輻輳状態に無い無線APの配下の端末１が端末２に対して発信する場合のシーケンス図である。
【図１０】本発明の第１の実施の形態において、輻輳状態に無い無線APの配下の端末１が端末２に対して発信する場合のシーケンス図である。
【図１１】本発明の第１の実施の形態において、輻輳状態に無い無線APの配下の端末１が端末２に対して発信する場合のシーケンス図である。
【図１２】本発明の第１の実施の形態において、輻輳中の無線AP配下にある端末１に端末２から着信要求があった場合の動作例１を示すシーケンス図である。
【図１３】本発明の第１の実施の形態において、輻輳中の無線AP配下にある端末１に端末２から着信要求があった場合の動作例２を示すシーケンス図である。
【図１４】本発明の第１の実施の形態において、輻輳中の無線AP配下にある端末１に端末２から着信要求があった場合の動作例２を示すシーケンス図である。
【図１５】本発明の第１の実施の形態において、輻輳中の無線AP配下にある端末１に端末２から着信要求があった場合の動作例３を示すシーケンス図である。
【図１６】本発明の第１の実施の形態において、輻輳中の無線AP配下にある端末１に端末２から着信要求があった場合の動作例４を示すシーケンス図である。
【図１７】本発明の第１の実施の形態において、輻輳中の無線AP配下にある端末１に端末２から着信要求があった場合の動作例４を示すシーケンス図である。
【図１８】本発明の第１の実施の形態において、輻輳中の無線AP配下にある端末１に端末２から着信要求があった場合の動作例４を示すシーケンス図である。
【図１９】本発明の第１の実施の形態において、内線グループ一斉呼び出しを行う場合の接続動作を示すシーケンス図である。
【図２０】本発明の第１の実施の形態において、内線グループ一斉呼び出しを行う場合の接続動作を示すシーケンス図である。
【図２１】本発明の第１の実施の形態において、内線グループ一斉呼び出しを行う場合の接続動作を示すシーケンス図である。
【図２２】本発明の第１の実施の形態において、コールパークを行う場合の接続動作を示すシーケンス図である。
【図２３】本発明の第１の実施の形態において、コールパークを行う場合の接続動作を示すシーケンス図である。
【図２４】本発明の第１の実施の形態において、コールパークを行う場合の接続動作を示すシーケンス図である。
【図２５】本発明の第１の実施の形態において、コールパークを行う場合の接続動作を示すシーケンス図である。
【図２６】本発明の第１の実施の形態において、コールウェイティングを行う場合の接続動作を示すシーケンス図である。
【図２７】本発明の第１の実施の形態において、コールウェイティングを行う場合の接続動作を示すシーケンス図である。
【図２８】本発明の第１の実施の形態において、コールウェイティングを行う場合の接続動作を示すシーケンス図である。
【図２９】本発明の第１の実施の形態において、装置の機能概要を説明するための図である。
【図３０】本発明の第１の実施の形態において、端末管理データの例を示す図である。
【図３１】本発明の第１の実施の形態において、無線AP管理データの例を示す図である。
【図３２】本発明の第１の実施の形態において、アクセスコントローラ３０の詳細機能構成図である。
【図３３】本発明の第２の実施の形態におけるシステムの全体動作フローである。
【図３４】本発明の第２の実施の形態におけるシステムの動作の概要を説明するための図である。
【図３５】本発明の第２の実施の形態において、移動先の無線AP２０が輻輳中でない場合の動作を示すシーケンス図である。
【図３６】本発明の第２の実施の形態において、移動先の無線AP２０が輻輳中でない場合の動作を示すシーケンス図である。
【図３７】本発明の第２の実施の形態において、移動先の無線AP２０が輻輳中でない場合の動作を示すシーケンス図である。
【図３８】本発明の第２の実施の形態において、最初の移動先の無線AP２０が輻輳中であるが、隣接無線AP２５に接続することによりハンドオーバが成功する場合の動作例を示すシーケンス図である。
【図３９】本発明の第２の実施の形態において、最初の移動先の無線AP２０が輻輳中であるが、隣接無線AP２５に接続することによりハンドオーバが成功する場合の動作例を示すシーケンス図である。
【図４０】本発明の第２の実施の形態において、最初の移動先の無線AP２０が輻輳中であるが、隣接無線AP２５に接続することによりハンドオーバが成功する場合の動作例を示すシーケンス図である。
【図４１】本発明の第２の実施の形態において、ハンドオーバに失敗し、通話相手端末に対する呼制御が行われる場合の動作例１を示すシーケンス図である。
【図４２】本発明の第２の実施の形態において、ハンドオーバに失敗し、通話相手端末に対する呼制御が行われる場合の動作例１を示すシーケンス図である。
【図４３】本発明の第２の実施の形態において、ハンドオーバに失敗した場合の動作例２を示すシーケンス図である。
【図４４】本発明の第２の実施の形態において、ハンドオーバに失敗した場合の動作例２を示すシーケンス図である。
【図４５】本発明の第２の実施の形態において、ハンドオーバに失敗した場合の動作例３を示すシーケンス図である。
【図４６】本発明の第２の実施の形態において、ハンドオーバに失敗した場合の動作例４を示すシーケンス図である。
【図４７】本発明の第２の実施の形態において、ハンドオーバに失敗した場合の動作例４を示すシーケンス図である。
【図４８】本発明の第２の実施の形態において、ハンドオーバに失敗した場合の動作例４を示すシーケンス図である。
【図４９】本発明の第２の実施の形態において、装置の機能概要を説明するための図である。
【図５０】本発明の第２の実施の形態において、端末管理データの例を示す図である。
【図５１】本発明の第２の実施の形態において、再接続要求拒否時間管理用の無線AP管理データの例を示す図である。
【図５２】本発明の第２の実施の形態において、アクセスコントローラ３０の詳細機能構成図である。
【図５３】本発明の第３の実施の形態において、輻輳中の無線APに接続された端末１に端末２から着信があった場合のシステムの動作概要について説明するための図である。
【図５４】本発明の第３の実施の形態において、輻輳中の無線AP１０に接続された端末１が端末２に発信する場合におけるシステムの動作概要を説明するための図である。
【図５５】本発明の第３の実施の形態において、輻輳中でない無線AP２０が存在する環境の下で、輻輳中の無線AP１０に接続された端末１に端末２から着信があった場合のシステムの動作を示すシーケンス図である。
【図５６】本発明の第３の実施の形態において、輻輳中でない無線AP２０が存在する環境の下で、輻輳中の無線AP１０に接続された端末１に端末２から着信があった場合のシステムの動作を示すシーケンス図である。
【図５７】本発明の第３の実施の形態において、輻輳中でない無線AP２０が存在する環境の下で、輻輳中の無線AP１０に接続された端末１に端末２から着信があった場合のシステムの動作を示すシーケンス図である。
【図５８】本発明の第３の実施の形態において、無線AP１０が輻輳中であるとともに、隣接無線AP２０も輻輳中であり、呼の中断を行う場合の動作を示すシーケンス図である。
【図５９】本発明の第３の実施の形態において、輻輳中の無線AP１０に隣接して、輻輳中でない無線AP２０が存在する環境の下で、無線AP１０に接続された端末１が端末２に発信を行う場合のシステムの動作を示すシーケンス図である。
【図６０】本発明の第３の実施の形態において、輻輳中の無線AP１０に隣接して、輻輳中でない無線AP２０が存在する環境の下で、無線AP１０に接続された端末１が端末２に発信を行う場合のシステムの動作を示すシーケンス図である。
【図６１】本発明の第３の実施の形態において、装置の機能概要を説明するための図である。
【図６２】本発明の第３の実施の形態において、端末管理データの例を示す図である。
【図６３】本発明の第３の実施の形態において、再接続要求拒否時間管理用の無線AP管理データの例を示す図である。
【図６４】本発明の第３の実施の形態において、アクセスコントローラ３０の詳細機能構成図である。
【符号の説明】
【０１８３】
１、２ 端末
１０、２０、２５ 無線AP
１１ 無線AP機能
１２ 対アクセスコントローラインタフェース機能
３０ アクセスコントローラ
３１ 対SIPサーバインタフェース機能
３２ 判定機能
３３ 対無線APインタフェース機能
３４ 対コンソールインタフェース機能
３５ データベース
３６ 無線リンクリトライ判定機能
３７ ハンドオーバ成否判定機能
３８ 呼接続制御機能
３９ 端末制御機能
４０ SIPサーバ
４１ 呼制御機能
４２ 対アクセスコントローラインタフェース機能
５０ コンソール
５１ ユーザインタフェース機能
５２ 対アクセスコントローラインタフェース機能
６０ SIP連携Ｉ／Ｆ
７０ リソース管理機能
８０ データ管理機能
９０ 無線AP管理機能
１００ 端末管理機能
１１０ 無線AP連携Ｉ／Ｆ
【特許請求の範囲】
【請求項１】
無線APとVoIP呼制御手段とを有する無線ＩＰ電話システムにおけるアクセス制御装置であって、
端末から前記無線APへ接続がなされたことを契機として、データリンク層における前記端末の識別情報である下位レイヤ識別情報と無線AP識別情報とを含む端末登録要求を前記無線APから受信し、当該無線AP識別情報を前記下位レイヤ識別情報に対応付けて記憶手段に登録する下位レイヤ登録手段と、
前記端末の呼制御で用いられる識別情報である上位レイヤ識別情報と前記下位レイヤ識別情報とを含む端末登録要求を前記VoIP呼制御手段から受信し、当該上位レイヤ識別情報を下位レイヤ識別情報に対応付けて前記記憶手段に登録する上位レイヤ登録手段と、
前記端末への着信または前記端末からの発信に係る呼接続要求を受信した前記VoIP呼制御手段からリソース状態の問い合わせを受信し、当該問い合わせに含まれる前記端末の上位レイヤ識別情報に基づき前記記憶手段を検索して前記端末を収容する前記無線APを検出し、当該無線APが輻輳状態にあるか否かの判定結果を取得し、輻輳状態にある場合に前記無線APが輻輳中であることを前記VoIP呼制御手段に通知する通知手段と
を有することを特徴とするアクセス制御装置。
【請求項２】
前記アクセス制御装置の記憶手段は、前記無線AP識別情報と前記無線APのリソース上限値と前記無線APで使用中のリソース量とを対応付けて格納しており、
前記通知手段は前記無線APのリソース上限値及び使用中リソース量と、前記リソース状態の問い合わせに含まれる前記端末に対する必要リソース量とに基づき前記無線APが輻輳状態にあるか否かを判定する判定手段を含むことを特徴とする請求項１に記載のアクセス制御装置。
【請求項３】
請求項１又は２に記載のアクセス制御装置と前記VoIP呼制御手段とを有する無線ＩＰ電話システムであって、前記VoIP呼制御手段は、
前記リソース状態の問い合わせに対する応答として前記無線APが輻輳中である旨の通知を前記アクセス制御装置から受信した場合に、前記呼接続要求を保留させ、当該呼接続要求を送信した端末に対して通信路が輻輳中であることを通知し、前記無線APが輻輳状態から回復した旨の通知を前記アクセス制御装置から受信したことを契機として、着信先端末への呼接続を行う呼制御手段を有することを特徴とする無線ＩＰ電話システム。
【請求項４】
無線APとVoIP呼制御手段とアクセス制御装置とを有する無線ＩＰ電話システムにおけるアクセス制御方法であって、
前記アクセス制御装置が、端末から前記無線APへ接続がなされたことを契機として、データリンク層における前記端末の識別情報である下位レイヤ識別情報と無線AP識別情報とを含む端末登録要求を前記無線APから受信し、当該無線AP識別情報を前記下位レイヤ識別情報に対応付けて記憶手段に登録する下位レイヤ登録ステップと、
前記アクセス制御装置が、前記端末の呼制御で用いられる識別情報である上位レイヤ識別情報と前記下位レイヤ識別情報とを含む端末登録要求を前記VoIP呼制御手段から受信し、当該上位レイヤ識別情報を下位レイヤ識別情報に対応付けて前記記憶手段に登録する上位レイヤ登録ステップと、
前記VoIP呼制御手段が、前記端末への着信または前記端末からの発信に係る呼接続要求を受信し、当該端末の呼に対して必要なリソース状態の問い合わせを前記アクセス制御装置に送信するリソース状態問い合わせステップと、
前記アクセス制御装置が、前記問い合わせに含まれる前記端末の上位レイヤ識別情報に基づき前記記憶手段を検索して前記端末を収容する前記無線APを検出し、当該無線APが輻輳状態にあるか否かの判定結果を取得し、輻輳状態にある場合に前記無線APが輻輳中であることを前記VoIP呼制御手段に通知する通知ステップと、
前記VoIP呼制御手段が、前記無線APが輻輳中であることに応じた呼制御を実行する呼制御ステップと
を有することを特徴とするアクセス制御方法。
【請求項５】
複数の無線APとVoIP呼制御手段とを有する無線ＩＰ電話システムにおけるアクセス制御装置であって、
端末からある無線APへ接続がなされたことを契機として、データリンク層における前記端末の識別情報である下位レイヤ識別情報と無線AP識別情報とを含む端末登録要求を前記無線APから受信し、当該無線APの識別情報を前記下位レイヤ識別情報に対応付けて記憶手段に登録する下位レイヤ登録手段と、
前記端末の呼制御で用いられる識別情報である上位レイヤ識別情報と前記下位レイヤ識別情報とを含む端末登録要求を前記VoIP呼制御手段から受信し、当該上位レイヤ識別情報を下位レイヤ識別情報に対応付けて前記記憶手段に登録する上位レイヤ登録手段と、
前記端末への着信または前記端末からの発信に係る呼接続要求を受信した前記VoIP呼制御手段からのリソース予約要求を契機として、当該要求に含まれる前記端末の上位レイヤ識別情報に基づき前記記憶手段を検索して前記端末を収容する前記無線APを検出し、前記無線APにおける前記端末に対する通信リソースの割り当て制御を行うリソース制御手段とを有し、
前記VoIP呼制御手段により前記端末と相手端末間での呼接続が行われ、前記端末が前記相手端末と通信中の状態において、前記端末が、接続中の無線APの配下から、他の無線APである移動先無線APの配下に移動した場合に、
前記端末から前記移動先無線APへ接続がなされたことを契機として、前記下位レイヤ登録手段は、前記端末の下位レイヤ識別情報と前記移動先無線APの識別情報とを含む端末登録要求を前記移動先無線APから受信し、当該移動先無線APの識別情報を前記下位レイヤ識別情報及び前記上位レイヤ識別情報に対応付けて前記記憶手段に登録し、
前記リソース制御手段は、前記VoIP呼制御手段からの要求を受けることなく、前記無線APにおいて前記端末に対して割り当てられていたリソースを解放し、前記移動先無線APが輻輳状態でない場合に、当該移動先無線APにおいて前記端末に対する通信リソースの確保を行うことを特徴とするアクセス制御装置。
【請求項６】
前記端末が、接続中の無線APの配下から、前記移動先無線APの配下に移動した場合において、前記リソース制御手段は、前記移動先無線APにおけるリソースの確保を行う前に、前記移動先無線APが輻輳状態にあるか否かの判定結果を取得し、
当該移動先無線APが輻輳状態にある場合に、前記アクセス制御装置は、前記端末との無線リンク切断要求を前記移動先無線APに送信することを特徴とする請求項５にアクセス制御装置。
【請求項７】
前記無線リンク切断要求を受信した移動先無線APから無線リンク切断指示を受信した前記端末が、他の無線APへの接続を行ったことを契機として、前記下位レイヤ登録手段は、前記他の無線APの識別情報を前記下位レイヤ識別情報及び前記上位レイヤ識別情報に対応付けて前記記憶手段に登録し、前記リソース制御手段は、前記他の無線APが輻輳状態でない場合に、前記他の無線APにおいて前記端末に対するリソースの確保を行うことを特徴とする請求項６に記載のアクセス制御装置。
【請求項８】
前記アクセス制御装置は、前記端末が接続する無線APが輻輳状態にあるためにリソース確保に失敗した回数を保持し、その回数と所定の回数とを比較し、リソース確保に失敗した回数が前記所定の回数に達していない場合に、リソース確保に失敗した無線APに無線リンク切断要求を送信し、リソース確保に失敗した回数が前記所定の回数に達している場合には、ハンドオーバ失敗通知を前記VoIP呼制御装置に送信することを特徴とする請求項６に記載のアクセス制御装置。
【請求項９】
請求項８に記載のアクセス制御装置と前記VoIP呼制御手段とを有する無線ＩＰ電話システムであって、前記VoIP呼制御手段は、前記ハンドオーバ失敗通知を前記アクセス制御装置から受信した場合に、前記相手端末に対する呼制御を行うことを特徴とする無線ＩＰ電話システム。
【請求項１０】
複数の無線APとVoIP呼制御手段とアクセス制御装置とを有する無線ＩＰ電話システムにおけるアクセス制御方法であって、
前記アクセス制御装置が、端末からある無線APへ接続がなされたことを契機として、データリンク層における前記端末の識別情報である下位レイヤ識別情報と無線AP識別情報とを含む端末登録要求を前記無線APから受信し、当該無線APの識別情報を前記下位レイヤ識別情報に対応付けて記憶手段に登録する下位レイヤ登録ステップと、
前記アクセス制御装置が、前記端末の呼制御で用いられる識別情報である上位レイヤ識別情報と前記下位レイヤ識別情報とを含む端末登録要求を前記VoIP呼制御手段から受信し、当該上位レイヤ識別情報を下位レイヤ識別情報に対応付けて前記記憶手段に登録する上位レイヤ登録ステップと、
前記VoIP呼制御手段が、前記端末への着信または前記端末からの発信に係る呼接続要求を受信し、リソース予約要求を前記アクセス制御装置に送信するステップと、
前記アクセス制御装置が、前記リソース予約要求を受信したことを契機として、当該要求に含まれる前記端末の上位レイヤ識別情報に基づき前記記憶手段を検索して前記端末を収容する前記無線APを検出し、前記無線APにおける前記端末に対する通信リソースの割り当て制御を行うリソース制御ステップとを有し、
前記VoIP呼制御手段が前記端末と相手端末間での呼接続処理を行い、前記端末が前記相手端末と通信中の状態において、前記端末が、接続中の無線APの配下から、他の無線APである移動先無線APの配下に移動した場合に、
前記端末から前記移動先無線APへ接続がなされたことを契機として、前記移動先無線APは、前記端末の下位レイヤ識別情報と前記移動先無線APの識別情報とを含む端末登録要求を前記アクセス制御装置に送信し、
前記端末登録要求を受信した前記アクセス制御装置は、前記移動先無線APの識別情報を前記下位レイヤ識別情報及び前記上位レイヤ識別情報に対応付けて前記記憶手段に登録し、前記VoIP呼制御手段からの要求を受けることなく、前記無線APにおいて前記端末に対して割り当てられていた通信リソースを解放し、前記移動先無線APが輻輳状態でない場合に、前記移動先無線APにおいて前記端末に対する通信リソースの確保を行うことを特徴とするアクセス制御方法。
【請求項１１】
複数の無線APとVoIP呼制御手段とを有する無線ＩＰ電話システムにおけるアクセス制御装置であって、
端末からある無線APへ接続がなされたことを契機として、データリンク層における前記端末の識別情報である下位レイヤ識別情報と無線AP識別情報とを含む端末登録要求を前記無線APから受信し、当該無線APの識別情報を前記下位レイヤ識別情報に対応付けて記憶手段に登録する下位レイヤ登録手段と、
前記端末の呼制御で用いられる識別情報である上位レイヤ識別情報と前記下位レイヤ識別情報とを含む端末登録要求を前記VoIP呼制御手段から受信し、当該上位レイヤ識別情報を下位レイヤ識別情報に対応付けて前記記憶手段に登録する上位レイヤ登録手段と、
前記端末への着信または前記端末からの発信に係る呼接続要求を受信した前記VoIP呼制御手段から当該端末に対するリソース予約要求を受信し、当該要求に含まれる前記端末の上位レイヤ識別情報に基づき前記記憶手段を検索して前記端末を収容する前記無線APを検出し、当該無線APが輻輳状態にあるか否かの判定結果を取得するリソース判定手段とを有し、
前記無線APが輻輳状態である場合に、前記アクセス制御装置は、前記端末との無線リンク切断要求を前記無線APに送信し、前記無線リンク切断要求を受信した前記無線APから無線リンク切断指示を受信した前記端末が他の無線APへの接続を行ったことを契機として、前記下位レイヤ登録手段は、前記他の無線APの識別情報を前記下位レイヤ識別情報及び前記上位レイヤ識別情報に対応付けて前記記憶手段に登録することを特徴とするアクセス制御装置。
【請求項１２】
前記呼接続要求は、相手端末から前記端末への着信に係るものであり、前記リソース判定手段は、前記他の無線APが輻輳状態にあるか否かの判定結果を取得し、
前記他の無線APが輻輳状態にない場合に、前記アクセス制御装置は、前記他の無線APに対するリソース予約を行い、前記VoIP呼制御手段に、リソース予約に成功したことを示すメッセージを送信することを特徴とする請求項１１に記載のアクセス制御装置。
【請求項１３】
請求項１２に記載のアクセス制御装置と前記VoIP呼制御手段とを有する無線ＩＰ電話システムであって、前記VoIP呼制御手段は、前記リソース予約に成功したことを示すメッセージを受信したことに応じて、前記呼接続要求に基づく呼接続処理を継続することを特徴とする無線ＩＰ電話システム。
【請求項１４】
請求項１１に記載のアクセス制御装置と前記VoIP呼制御手段とを有する無線ＩＰ電話システムであって、
前記呼接続要求は、前記端末から相手端末への発信に係るものであり、前記リソース判定手段は、前記他の無線APが輻輳状態にあるか否かの判定結果を取得し、前記他の無線APが輻輳状態にない場合に、前記VoIP呼制御手段は、前記端末から再度受信する呼接続要求に基づき、前記端末と前記相手端末との間の呼接続処理を行うことを特徴とする無線ＩＰ電話システム。
【請求項１５】
前記アクセス制御装置は、前記端末が接続した無線APが輻輳状態にあるためにリソース予約に失敗した回数を保持し、その回数と所定の回数とを比較し、リソース予約に失敗した回数が前記所定の回数に達していない場合に、リソース予約に失敗した無線APに無線リンク切断要求を送信し、リソース予約に失敗した回数が前記所定の回数に達している場合には、無線APが輻輳状態にあることを示すメッセージを前記VoIP呼制御装置に送信することを特徴とする請求項１１に記載のアクセス制御装置。
【請求項１６】
複数の無線APとVoIP呼制御手段とアクセス制御装置とを有する無線ＩＰ電話システムにおけるアクセス制御方法であって、
前記アクセス制御装置が、端末からある無線APへ接続がなされたことを契機として、データリンク層における前記端末の識別情報である下位レイヤ識別情報と無線AP識別情報とを含む端末登録要求を前記無線APから受信し、当該無線APの識別情報を前記下位レイヤ識別情報に対応付けて記憶手段に登録する下位レイヤ登録ステップと、
前記アクセス制御装置が、前記端末の呼制御で用いられる識別情報である上位レイヤ識別情報と前記下位レイヤ識別情報とを含む端末登録要求を前記VoIP呼制御手段から受信し、当該上位レイヤ識別情報を下位レイヤ識別情報に対応付けて前記記憶手段に登録する上位レイヤ登録ステップと、
前記VoIP呼制御手段が、前記端末への着信または前記端末からの発信に係る呼接続要求を受信するステップと、
前記アクセス制御装置が、前記VoIP呼制御手段から前記端末に対するリソース予約要求を受信し、当該要求に含まれる前記端末の上位レイヤ識別情報に基づき前記記憶手段を検索して前記端末を収容する前記無線APを検出し、当該無線APが輻輳状態にあるか否かの判定結果を取得するリソース判定ステップと、
前記無線APが輻輳状態である場合に、前記アクセス制御装置が、前記端末との無線リンク切断要求を前記無線APに送信するステップと、
前記無線リンク切断要求を受信した前記無線APから無線リンク切断指示を受信した前記端末が他の無線APへの接続を行ったことを契機として、前記アクセス制御装置が、前記他の無線APの識別情報を前記下位レイヤ識別情報及び前記上位レイヤ識別情報に対応付けて前記記憶手段に登録するステップとを有することを特徴とするアクセス制御方法。
【請求項１】
無線APとVoIP呼制御手段とを有する無線ＩＰ電話システムにおけるアクセス制御装置であって、
端末から前記無線APへ接続がなされたことを契機として、データリンク層における前記端末の識別情報である下位レイヤ識別情報と無線AP識別情報とを含む端末登録要求を前記無線APから受信し、当該無線AP識別情報を前記下位レイヤ識別情報に対応付けて記憶手段に登録する下位レイヤ登録手段と、
前記端末の呼制御で用いられる識別情報である上位レイヤ識別情報と前記下位レイヤ識別情報とを含む端末登録要求を前記VoIP呼制御手段から受信し、当該上位レイヤ識別情報を下位レイヤ識別情報に対応付けて前記記憶手段に登録する上位レイヤ登録手段と、
前記端末への着信または前記端末からの発信に係る呼接続要求を受信した前記VoIP呼制御手段からリソース状態の問い合わせを受信し、当該問い合わせに含まれる前記端末の上位レイヤ識別情報に基づき前記記憶手段を検索して前記端末を収容する前記無線APを検出し、当該無線APが輻輳状態にあるか否かの判定結果を取得し、輻輳状態にある場合に前記無線APが輻輳中であることを前記VoIP呼制御手段に通知する通知手段と
を有することを特徴とするアクセス制御装置。
【請求項２】
前記アクセス制御装置の記憶手段は、前記無線AP識別情報と前記無線APのリソース上限値と前記無線APで使用中のリソース量とを対応付けて格納しており、
前記通知手段は前記無線APのリソース上限値及び使用中リソース量と、前記リソース状態の問い合わせに含まれる前記端末に対する必要リソース量とに基づき前記無線APが輻輳状態にあるか否かを判定する判定手段を含むことを特徴とする請求項１に記載のアクセス制御装置。
【請求項３】
請求項１又は２に記載のアクセス制御装置と前記VoIP呼制御手段とを有する無線ＩＰ電話システムであって、前記VoIP呼制御手段は、
前記リソース状態の問い合わせに対する応答として前記無線APが輻輳中である旨の通知を前記アクセス制御装置から受信した場合に、前記呼接続要求を保留させ、当該呼接続要求を送信した端末に対して通信路が輻輳中であることを通知し、前記無線APが輻輳状態から回復した旨の通知を前記アクセス制御装置から受信したことを契機として、着信先端末への呼接続を行う呼制御手段を有することを特徴とする無線ＩＰ電話システム。
【請求項４】
無線APとVoIP呼制御手段とアクセス制御装置とを有する無線ＩＰ電話システムにおけるアクセス制御方法であって、
前記アクセス制御装置が、端末から前記無線APへ接続がなされたことを契機として、データリンク層における前記端末の識別情報である下位レイヤ識別情報と無線AP識別情報とを含む端末登録要求を前記無線APから受信し、当該無線AP識別情報を前記下位レイヤ識別情報に対応付けて記憶手段に登録する下位レイヤ登録ステップと、
前記アクセス制御装置が、前記端末の呼制御で用いられる識別情報である上位レイヤ識別情報と前記下位レイヤ識別情報とを含む端末登録要求を前記VoIP呼制御手段から受信し、当該上位レイヤ識別情報を下位レイヤ識別情報に対応付けて前記記憶手段に登録する上位レイヤ登録ステップと、
前記VoIP呼制御手段が、前記端末への着信または前記端末からの発信に係る呼接続要求を受信し、当該端末の呼に対して必要なリソース状態の問い合わせを前記アクセス制御装置に送信するリソース状態問い合わせステップと、
前記アクセス制御装置が、前記問い合わせに含まれる前記端末の上位レイヤ識別情報に基づき前記記憶手段を検索して前記端末を収容する前記無線APを検出し、当該無線APが輻輳状態にあるか否かの判定結果を取得し、輻輳状態にある場合に前記無線APが輻輳中であることを前記VoIP呼制御手段に通知する通知ステップと、
前記VoIP呼制御手段が、前記無線APが輻輳中であることに応じた呼制御を実行する呼制御ステップと
を有することを特徴とするアクセス制御方法。
【請求項５】
複数の無線APとVoIP呼制御手段とを有する無線ＩＰ電話システムにおけるアクセス制御装置であって、
端末からある無線APへ接続がなされたことを契機として、データリンク層における前記端末の識別情報である下位レイヤ識別情報と無線AP識別情報とを含む端末登録要求を前記無線APから受信し、当該無線APの識別情報を前記下位レイヤ識別情報に対応付けて記憶手段に登録する下位レイヤ登録手段と、
前記端末の呼制御で用いられる識別情報である上位レイヤ識別情報と前記下位レイヤ識別情報とを含む端末登録要求を前記VoIP呼制御手段から受信し、当該上位レイヤ識別情報を下位レイヤ識別情報に対応付けて前記記憶手段に登録する上位レイヤ登録手段と、
前記端末への着信または前記端末からの発信に係る呼接続要求を受信した前記VoIP呼制御手段からのリソース予約要求を契機として、当該要求に含まれる前記端末の上位レイヤ識別情報に基づき前記記憶手段を検索して前記端末を収容する前記無線APを検出し、前記無線APにおける前記端末に対する通信リソースの割り当て制御を行うリソース制御手段とを有し、
前記VoIP呼制御手段により前記端末と相手端末間での呼接続が行われ、前記端末が前記相手端末と通信中の状態において、前記端末が、接続中の無線APの配下から、他の無線APである移動先無線APの配下に移動した場合に、
前記端末から前記移動先無線APへ接続がなされたことを契機として、前記下位レイヤ登録手段は、前記端末の下位レイヤ識別情報と前記移動先無線APの識別情報とを含む端末登録要求を前記移動先無線APから受信し、当該移動先無線APの識別情報を前記下位レイヤ識別情報及び前記上位レイヤ識別情報に対応付けて前記記憶手段に登録し、
前記リソース制御手段は、前記VoIP呼制御手段からの要求を受けることなく、前記無線APにおいて前記端末に対して割り当てられていたリソースを解放し、前記移動先無線APが輻輳状態でない場合に、当該移動先無線APにおいて前記端末に対する通信リソースの確保を行うことを特徴とするアクセス制御装置。
【請求項６】
前記端末が、接続中の無線APの配下から、前記移動先無線APの配下に移動した場合において、前記リソース制御手段は、前記移動先無線APにおけるリソースの確保を行う前に、前記移動先無線APが輻輳状態にあるか否かの判定結果を取得し、
当該移動先無線APが輻輳状態にある場合に、前記アクセス制御装置は、前記端末との無線リンク切断要求を前記移動先無線APに送信することを特徴とする請求項５にアクセス制御装置。
【請求項７】
前記無線リンク切断要求を受信した移動先無線APから無線リンク切断指示を受信した前記端末が、他の無線APへの接続を行ったことを契機として、前記下位レイヤ登録手段は、前記他の無線APの識別情報を前記下位レイヤ識別情報及び前記上位レイヤ識別情報に対応付けて前記記憶手段に登録し、前記リソース制御手段は、前記他の無線APが輻輳状態でない場合に、前記他の無線APにおいて前記端末に対するリソースの確保を行うことを特徴とする請求項６に記載のアクセス制御装置。
【請求項８】
前記アクセス制御装置は、前記端末が接続する無線APが輻輳状態にあるためにリソース確保に失敗した回数を保持し、その回数と所定の回数とを比較し、リソース確保に失敗した回数が前記所定の回数に達していない場合に、リソース確保に失敗した無線APに無線リンク切断要求を送信し、リソース確保に失敗した回数が前記所定の回数に達している場合には、ハンドオーバ失敗通知を前記VoIP呼制御装置に送信することを特徴とする請求項６に記載のアクセス制御装置。
【請求項９】
請求項８に記載のアクセス制御装置と前記VoIP呼制御手段とを有する無線ＩＰ電話システムであって、前記VoIP呼制御手段は、前記ハンドオーバ失敗通知を前記アクセス制御装置から受信した場合に、前記相手端末に対する呼制御を行うことを特徴とする無線ＩＰ電話システム。
【請求項１０】
複数の無線APとVoIP呼制御手段とアクセス制御装置とを有する無線ＩＰ電話システムにおけるアクセス制御方法であって、
前記アクセス制御装置が、端末からある無線APへ接続がなされたことを契機として、データリンク層における前記端末の識別情報である下位レイヤ識別情報と無線AP識別情報とを含む端末登録要求を前記無線APから受信し、当該無線APの識別情報を前記下位レイヤ識別情報に対応付けて記憶手段に登録する下位レイヤ登録ステップと、
前記アクセス制御装置が、前記端末の呼制御で用いられる識別情報である上位レイヤ識別情報と前記下位レイヤ識別情報とを含む端末登録要求を前記VoIP呼制御手段から受信し、当該上位レイヤ識別情報を下位レイヤ識別情報に対応付けて前記記憶手段に登録する上位レイヤ登録ステップと、
前記VoIP呼制御手段が、前記端末への着信または前記端末からの発信に係る呼接続要求を受信し、リソース予約要求を前記アクセス制御装置に送信するステップと、
前記アクセス制御装置が、前記リソース予約要求を受信したことを契機として、当該要求に含まれる前記端末の上位レイヤ識別情報に基づき前記記憶手段を検索して前記端末を収容する前記無線APを検出し、前記無線APにおける前記端末に対する通信リソースの割り当て制御を行うリソース制御ステップとを有し、
前記VoIP呼制御手段が前記端末と相手端末間での呼接続処理を行い、前記端末が前記相手端末と通信中の状態において、前記端末が、接続中の無線APの配下から、他の無線APである移動先無線APの配下に移動した場合に、
前記端末から前記移動先無線APへ接続がなされたことを契機として、前記移動先無線APは、前記端末の下位レイヤ識別情報と前記移動先無線APの識別情報とを含む端末登録要求を前記アクセス制御装置に送信し、
前記端末登録要求を受信した前記アクセス制御装置は、前記移動先無線APの識別情報を前記下位レイヤ識別情報及び前記上位レイヤ識別情報に対応付けて前記記憶手段に登録し、前記VoIP呼制御手段からの要求を受けることなく、前記無線APにおいて前記端末に対して割り当てられていた通信リソースを解放し、前記移動先無線APが輻輳状態でない場合に、前記移動先無線APにおいて前記端末に対する通信リソースの確保を行うことを特徴とするアクセス制御方法。
【請求項１１】
複数の無線APとVoIP呼制御手段とを有する無線ＩＰ電話システムにおけるアクセス制御装置であって、
端末からある無線APへ接続がなされたことを契機として、データリンク層における前記端末の識別情報である下位レイヤ識別情報と無線AP識別情報とを含む端末登録要求を前記無線APから受信し、当該無線APの識別情報を前記下位レイヤ識別情報に対応付けて記憶手段に登録する下位レイヤ登録手段と、
前記端末の呼制御で用いられる識別情報である上位レイヤ識別情報と前記下位レイヤ識別情報とを含む端末登録要求を前記VoIP呼制御手段から受信し、当該上位レイヤ識別情報を下位レイヤ識別情報に対応付けて前記記憶手段に登録する上位レイヤ登録手段と、
前記端末への着信または前記端末からの発信に係る呼接続要求を受信した前記VoIP呼制御手段から当該端末に対するリソース予約要求を受信し、当該要求に含まれる前記端末の上位レイヤ識別情報に基づき前記記憶手段を検索して前記端末を収容する前記無線APを検出し、当該無線APが輻輳状態にあるか否かの判定結果を取得するリソース判定手段とを有し、
前記無線APが輻輳状態である場合に、前記アクセス制御装置は、前記端末との無線リンク切断要求を前記無線APに送信し、前記無線リンク切断要求を受信した前記無線APから無線リンク切断指示を受信した前記端末が他の無線APへの接続を行ったことを契機として、前記下位レイヤ登録手段は、前記他の無線APの識別情報を前記下位レイヤ識別情報及び前記上位レイヤ識別情報に対応付けて前記記憶手段に登録することを特徴とするアクセス制御装置。
【請求項１２】
前記呼接続要求は、相手端末から前記端末への着信に係るものであり、前記リソース判定手段は、前記他の無線APが輻輳状態にあるか否かの判定結果を取得し、
前記他の無線APが輻輳状態にない場合に、前記アクセス制御装置は、前記他の無線APに対するリソース予約を行い、前記VoIP呼制御手段に、リソース予約に成功したことを示すメッセージを送信することを特徴とする請求項１１に記載のアクセス制御装置。
【請求項１３】
請求項１２に記載のアクセス制御装置と前記VoIP呼制御手段とを有する無線ＩＰ電話システムであって、前記VoIP呼制御手段は、前記リソース予約に成功したことを示すメッセージを受信したことに応じて、前記呼接続要求に基づく呼接続処理を継続することを特徴とする無線ＩＰ電話システム。
【請求項１４】
請求項１１に記載のアクセス制御装置と前記VoIP呼制御手段とを有する無線ＩＰ電話システムであって、
前記呼接続要求は、前記端末から相手端末への発信に係るものであり、前記リソース判定手段は、前記他の無線APが輻輳状態にあるか否かの判定結果を取得し、前記他の無線APが輻輳状態にない場合に、前記VoIP呼制御手段は、前記端末から再度受信する呼接続要求に基づき、前記端末と前記相手端末との間の呼接続処理を行うことを特徴とする無線ＩＰ電話システム。
【請求項１５】
前記アクセス制御装置は、前記端末が接続した無線APが輻輳状態にあるためにリソース予約に失敗した回数を保持し、その回数と所定の回数とを比較し、リソース予約に失敗した回数が前記所定の回数に達していない場合に、リソース予約に失敗した無線APに無線リンク切断要求を送信し、リソース予約に失敗した回数が前記所定の回数に達している場合には、無線APが輻輳状態にあることを示すメッセージを前記VoIP呼制御装置に送信することを特徴とする請求項１１に記載のアクセス制御装置。
【請求項１６】
複数の無線APとVoIP呼制御手段とアクセス制御装置とを有する無線ＩＰ電話システムにおけるアクセス制御方法であって、
前記アクセス制御装置が、端末からある無線APへ接続がなされたことを契機として、データリンク層における前記端末の識別情報である下位レイヤ識別情報と無線AP識別情報とを含む端末登録要求を前記無線APから受信し、当該無線APの識別情報を前記下位レイヤ識別情報に対応付けて記憶手段に登録する下位レイヤ登録ステップと、
前記アクセス制御装置が、前記端末の呼制御で用いられる識別情報である上位レイヤ識別情報と前記下位レイヤ識別情報とを含む端末登録要求を前記VoIP呼制御手段から受信し、当該上位レイヤ識別情報を下位レイヤ識別情報に対応付けて前記記憶手段に登録する上位レイヤ登録ステップと、
前記VoIP呼制御手段が、前記端末への着信または前記端末からの発信に係る呼接続要求を受信するステップと、
前記アクセス制御装置が、前記VoIP呼制御手段から前記端末に対するリソース予約要求を受信し、当該要求に含まれる前記端末の上位レイヤ識別情報に基づき前記記憶手段を検索して前記端末を収容する前記無線APを検出し、当該無線APが輻輳状態にあるか否かの判定結果を取得するリソース判定ステップと、
前記無線APが輻輳状態である場合に、前記アクセス制御装置が、前記端末との無線リンク切断要求を前記無線APに送信するステップと、
前記無線リンク切断要求を受信した前記無線APから無線リンク切断指示を受信した前記端末が他の無線APへの接続を行ったことを契機として、前記アクセス制御装置が、前記他の無線APの識別情報を前記下位レイヤ識別情報及び前記上位レイヤ識別情報に対応付けて前記記憶手段に登録するステップとを有することを特徴とするアクセス制御方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【図３７】
【図３８】
【図３９】
【図４０】
【図４１】
【図４２】
【図４３】
【図４４】
【図４５】
【図４６】
【図４７】
【図４８】
【図４９】
【図５０】
【図５１】
【図５２】
【図５３】
【図５４】
【図５５】
【図５６】
【図５７】
【図５８】
【図５９】
【図６０】
【図６１】
【図６２】
【図６３】
【図６４】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【図３７】
【図３８】
【図３９】
【図４０】
【図４１】
【図４２】
【図４３】
【図４４】
【図４５】
【図４６】
【図４７】
【図４８】
【図４９】
【図５０】
【図５１】
【図５２】
【図５３】
【図５４】
【図５５】
【図５６】
【図５７】
【図５８】
【図５９】
【図６０】
【図６１】
【図６２】
【図６３】
【図６４】
【公開番号】特開２００７−１３５１９４（Ｐ２００７−１３５１９４Ａ）
【公開日】平成１９年５月３１日（２００７．５．３１）
【国際特許分類】
【出願番号】特願２００６−２６４７７４（Ｐ２００６−２６４７７４）
【出願日】平成１８年９月２８日（２００６．９．２８）
【出願人】（０００１０２７１７）エヌ・ティ・ティ・ソフトウェア株式会社 (43)
【Ｆターム（参考）】
【公開日】平成１９年５月３１日（２００７．５．３１）
【国際特許分類】
【出願日】平成１８年９月２８日（２００６．９．２８）
【出願人】（０００１０２７１７）エヌ・ティ・ティ・ソフトウェア株式会社 (43)
【Ｆターム（参考）】
[ Back to top ]