以下、図面を参照して本発明の実施の形態を説明する。
<第1の実施の形態>
(システム概要)
図2に、本発明の第1の実施の形態におけるシステムの一例を示す。図2に示すシステムは、図1に示したシステムにアクセスコントローラ30が付加されたものである。なお、アクセスコントローラ30は、図2における無線LANスイッチに替えて、もしくは無線LANスイッチ内に備えることも可能である。
図2のシステムにおける各無線APは、当該無線AP配下の端末から受信する信号に基づき、その端末の電波状態(本実施の形態では電波強度)を測定し、それを端末の識別情報と対応付けて保存しておく機能、及びアクセスコントローラ30からの要求に基づきその情報をアクセスコントローラ30に送信する機能を有している。更に、図2のシステムにおける各無線APは、電波干渉状態を示す情報を取得し、保存しておく機能、及びアクセスコントローラ30からの要求に基づきその情報をアクセスコントローラ30に送信する機能を有している。
また、図2のシステムにおけるアクセスコントローラ30は、無線AP毎に端末毎の帯域の割り当て状態を管理する機能、無線APから当該無線AP配下の端末の電波状態の情報を取得する機能、及び無線APから当該無線APの電波干渉状態を示す情報を取得する機能を有している。また、アクセスコントローラ30は、これらのデータに基づき、無線APに対する帯域予約を行うか否かを判定する機能を有している。SIPサーバ40はVoIP通信の発生に応じてアクセスコントローラ30にリソース状態の問い合わせに相当する帯域予約要求を送信し、帯域予約要求に対する応答内容に応じた呼制御を行う機能を有している。なお、本明細書及び特許請求の範囲において、"リソース"とは特に断らない限り通信に用いられる資源全般のことを意味する。また、"リソース状態"とはそのリソースの状態であり、例えば端末の電波状態、無線APの電波干渉状態、無線APの使用帯域等を含むものである。
図3を用いて本実施の形態のシステムの動作概要を説明する。図3において、端末1が無線AP10配下にあるが未だ呼接続はされていないものとする。このような状態で、発信元の端末2から端末1に対する呼接続要求がSIPサーバ40に送信されると(ステップA)、SIPサーバ40はアクセスコントローラ30に、着信先端末である端末1の呼のための帯域予約要求を送信する(ステップB)。アクセスコントローラ30は、無線AP10の電波干渉状態情報、端末1の電波状態情報、及び無線AP10の輻輳状態情報を取得し、これらのうち、予め定めた条件を満たさないものがある場合に、無線AP10において端末1に対するリソースの割り当てができないことをSIPサーバ40に通知する(ステップC)。SIPサーバ40はこの通知を受信し、ステップAの呼接続要求に対する応答として、発信元の端末2に対してビジーを送信する(ステップD)。
図4は、アクセスコントローラ30における判定処理を示すフローチャートである。この図に示すとおり、アクセスコントローラ30は、SIPサーバ40から端末1に係る帯域予約要求(リソース状態問い合わせ)を受信すると(ステップ1)、まず、端末1と無線リンク接続している無線AP10の電波干渉状態を示す情報を当該無線AP10から取得し(ステップ2)、それが予め定めた電波干渉閾値未満かどうかを調べ、電波干渉閾値未満であればステップ4の処理に進む(ステップ3)。ステップ3において無線APの電波干渉状態を示す情報が電波干渉閾値以上である場合は、無線APが電波干渉中であるため、端末1と端末2を接続すべきでないと判定し、無線AP10に対する帯域予約を行わずに、電波干渉中であることを示す応答をSIPサーバ40に送信する(ステップ10)。
ステップ4において、アクセスコントローラ30は、端末1の電波強度を無線AP10から取得し、それが予め定めた電波強度閾値より大きいかどうかを調べ、電波強度閾値より大きければステップ6の処理に進む(ステップ5)。端末1の電波強度が予め定めた電波強度閾値以下である場合は、端末1が低電波状態にあり、端末1と端末2を接続すべきでないと判定し、無線AP10に対する帯域予約を行わずに、低電波状態であることを示す応答をSIPサーバ40に送信する(ステップ11)。
ステップ6において、アクセスコントローラ30は、無線AP10が輻輳中であるかどうかを調べ、輻輳中であれば端末1と端末2を接続すべきでないと判定し、輻輳中であることを示す応答をSIPサーバ40に送信する(ステップ12)。
全ての条件を満たした場合は、ステップ7において帯域予約OKを示す応答をSIPサーバ40に送信する。その後、端末1と端末2との接続のためのシーケンスを経て、端末1と端末2間で音声通話が行われる。一方、ステップ10、11、12の後は、例えばSIPサーバ40が端末2に対してビジーを通知する。
本実施の形態では、電波干渉状態を示す情報として、C.U.(Channel Utilization)値、リトライパケット数、パケット送信分散値、及びパケット受信分散値を使用しており、これら4つのうちどれか1つでも予め定めた閾値より小さければ電波干渉中でないと判定する。つまり、これらのうち全てが閾値以上である場合に電波干渉中であると判定する。なお、これらのうち1つでも予め定めた閾値以上である場合に電波干渉中であると判定することとしてもよい。また、4つのうちの所定の数のパラメータが予め定めた閾値より小さければ電波干渉中でないと判定するといったように、4つのパラメータの組み合わせに種々のバリエーションを設けてもよい。他の実施の形態でも同様である。
C.U.値は、チャネル利用率であり、対象の無線AP以外の電波発生源からの電波を含む電波使用状態を示す値である。リトライパケット数は、無線APが単位時間当たりに再送を行ったパケット数である。これらはいずれも電波干渉中には大きな値となる。パケット送信分散値はパケット送信の分散値である。電波干渉が小さい状態であれば、パケットは一定の間隔で送信することができるが、電波干渉が大きい状態では、パケットを送信できない状態が頻繁に発生するため、パケットの送信にばらつきが生じ、分散値が大きくなる。パケット受信分散値はパケット受信の分散値であり、パケット送信分散値と同様に、電波干渉が大きい状態ではその値が大きくなる。
本実施の形態では、無線AP10が輻輳中である場合のみならず、無線AP10における電波干渉が大きい場合や端末の電波状態が良好でない場合にも、新たな呼接続がなされないため、従来技術の問題が解消される。なお、輻輳時におけるSIPサーバ40の処理としてビジー返却を説明したが、これは一例に過ぎず、他にも様々な処理が可能である。
(システムの動作詳細)
次に、本実施の形態のシステムの動作をシーケンス図を参照して詳細に説明する。各シーケンス図では、各装置内に保持されるデータの構造を適宜示している。また、シーケンス図中にレジストラとSIPサーバが示されているが、これらは別々の装置であってもよいし、SIPサーバ内にレジストラが含まれる構成でもよい。このレジストラは一般的なSIPに基づくレジストラの機能と同様の機能を有している。また、各シーケンス中、MSIDは端末のMACアドレスを示し、APIDは無線APのIDを示し、URIはSIP−URIを示す。
まず、図5を参照してVoIP端末1(以下、端末1と呼ぶ)をアクセスコントローラに登録するためのシーケンスを説明する。図5に示す登録処理は、例えば端末1の電源が入れられたときに自動的に行われるものである。また、図5に示す時点においてSIPサーバにアクセスコントローラが登録されており、アクセスコントローラとSIPサーバ間でSIPに基づくメッセージ送受信が可能となっている。
図5のステップ1において、端末1と無線AP01間で無線LANにおける無線リンク接続処理及び認証処理等が行われる。ここで、無線AP01は端末1のMACアドレス(MSID)を取得し、登録する(ステップ2)。無線AP01は無線AP01のID(AP01)と端末1のMACアドレス(MS01)とを含む端末登録リクエストをアクセスコントローラに対して送信する(ステップ3)。アクセスコントローラは無線AP01から受信した無線AP01のID(AP01)と端末1のMACアドレス(MS01)とを記憶装置に格納することにより登録する(ステップ4)。そして、アクセスコントローラは無線AP01に対して端末登録レスポンスを返す(ステップ5)。
ステップ6において、端末1はレジストラに対してSIPのレジスタメッセージを送信する。送信するメッセージにはMS01と端末1のURI(URI1)が含まれる。レジストラは通常のレジスタ処理を行うとともに、MS01とURI1とを含むURI登録リクエストをアクセスコントローラに送信する(ステップ7)。アクセスコントローラはURI1をAP01及びMS01と対応付けて格納することによりURIの有効化を行い(ステップ8)、URI登録レスポンスをレジストラに送信する(ステップ9)。そして、レジストラはステップ6のレジスタメッセージの応答を端末1に返す(ステップ10)。
なお、ここで説明する例では、端末のMACアドレスとURIとをシーケンスの中でアクセスコントローラに格納しているが、予めこれらのデータをアクセスコントローラに格納しておき、状態変化のみを記録することとしてもよい。この場合、例えば、ステップ4において予め登録されているMS01に対応付けてAP01が記録され、ステップ8においてAP01、MS01、URI1に対応付けてURI1が有効になった旨の情報が記録される。他の実施の形態でも同様である。
次に、図6を参照してアクセスコントローラから登録された端末1を削除する処理について説明する。図6に示す処理は、例えば端末1の電源を切る際に実行されるものである。
図6のステップ1において、端末1は登録削除命令を含むレジスタメッセージをレジストラに送信する。レジストラはアクセスコントローラに対してURI削除リクエストを送信し(ステップ2)、これを受信したアクセスコントローラはデータベースからURI1を削除することによりURIを無効化する(ステップ3)。アクセスコントローラはURI削除レスポンスを返し(ステップ4)、レジストラは端末1に対して応答を返す(ステップ5)。
ステップ6において、端末1は無線AP01から離脱する(無線APとの無線リンクを切断する)場合における無線LANの処理を実行し、これを受けて無線APはMSIDを削除するとともに(ステップ7)、端末削除リクエストをアクセスコントローラに送信し(ステップ8)、これを受信したアクセスコントローラはデータベースからAP01とMS01を削除し(ステップ9)、端末削除レスポンスを無線AP01に返す(ステップ10)。
次に、図7〜図9を参照して、無線AP01が電波干渉中でなく、着信先の端末である端末1の電波状態が良好であり、無線AP01が輻輳中でない場合において、端末1に端末2から着信要求がなされた場合の動作について説明する。なお、以下の図ではレジストラを示していない。
発信元の端末2が呼接続要求(INVITE)をSIPサーバに送信する(ステップ1)。INVITEを受信したSIPサーバは、発信元端末URI(URI2)と着信先端末URI(URI1)と必要帯域幅とを含むQoS予約リクエストをアクセスコントローラに送信する(ステップ2)。アクセスコントローラは着信先URI1に基づきデータベースを検索し、端末1を配下に持つ無線AP01を抽出する(ステップ3)。
そして、アクセスコントローラは、その無線AP01に対して電波干渉状態要求を送信し(ステップ4)、無線AP01は電波干渉状態を示す情報をアクセスコントローラに送信する(ステップ5)。アクセスコントローラは、電波干渉状態を示す各値とそれぞれの閾値とを比較することにより無線AP01の電波干渉状態を判定する(ステップ6)。ここでは電波干渉中でないと判定されるので、アクセスコントローラは、端末1のMSIDであるMS01を含む電波状態要求を無線AP01に送信する(ステップ7)。無線AP01は、端末1の電波強度をアクセスコントローラに送信する(ステップ8)。アクセスコントローラは、端末の電波強度と予め定めた閾値とを比較することにより端末1の電波状態判定を行う(ステップ9)。ここでは電波状態は良好であると判定されるので、アクセスコントローラは、無線AP01に対してMS01と必要帯域幅とを含むQoS予約リクエストを送信する(ステップ10)。無線AP01は、輻輳中ではないので、端末1に対して帯域を予約し(ステップ11)、QoS予約レスポンスをアクセスコントローラに返し(ステップ12)、アクセスコントローラは予約OKを示すQoS予約レスポンスをSIPサーバに返す(ステップ13)。その後、通常のSIPに基づくシーケンスが実行される(図8のステップ14〜ステップ18)。
なお、本シーケンスでは無線AP01が帯域を管理し、帯域予約/確保を行うこととしているが、アクセスコントローラに、無線APの帯域を管理し、帯域予約/確保等の制御を行う機能を持たせてもよい。この場合、無線APとアクセスコントローラ間での帯域予約/確保/解放等に関するメッセージの送受信はなされず、アクセスコントローラ内で帯域予約/確保/解放等の帯域管理がなされる。
無線AP01はタイマ監視をしており、所定の時間内に次のメッセージ(ステップ22)を受信しなければステップ11で予約した帯域を解放する(図8のステップ19)。
ACKの送受信(図8のステップ17、18)を行ったSIPサーバは端末1と端末2間の呼を話中呼として管理している。また、この時点で端末1、2間の帯域幅が決定することから、ステップ20において、SIPサーバはQoS確保リクエストをアクセスコントローラに送信する。その後は、QoS予約リクエストのシーケンス(ステップ3、ステップ10〜ステップ13)と同様のシーケンス(図8のステップ21〜ステップ25)によって無線APでの帯域確保がなされ、端末1、2間での音声通信が実行される(ステップ26)。
図9は、図8のステップ26の後、端末2から呼切断が行われる場合の処理を示すシーケンス図である。ステップ27〜ステップ30において、通常のSIPによる処理が行われることにより、SIPサーバは呼を切断する。ステップ31において、SIPサーバはQoS解放リクエストをアクセスコントローラに送信する。アクセスコントローラは該当の無線AP01を抽出し(ステップ32)、QoS解放リクエストを無線AP01に送信する(ステップ33)。無線AP01は今までMS01に対して確保していた帯域を解放し(ステップ34)、QoS解放レスポンスをアクセスコントローラに返し(ステップ35)、アクセスコントローラはQoS解放レスポンスをSIPサーバに返す(ステップ36)。
図10〜図12は、無線AP01が電波干渉中でなく、端末1の電波状態が良好であり、無線AP01が輻輳中でない場合において、端末1が端末2に対して発信する場合のシーケンスを示す図である。発信端末と着信端末が入れ替わったことにより生じるSIPシーケンスの違いを除き図7〜図9と同じ処理が実行され、帯域予約、帯域確保、帯域解放が行われる。
次に、無線AP01が電波干渉中、端末1が低電波状態、無線AP01が輻輳中のいずれかの場合において、端末1に端末2から着信要求があった場合のシーケンスを図13〜15を参照して説明する。
図13は、無線AP01が電波干渉中である場合のシーケンスを示す図である。図13におけるステップ1〜ステップ5は図7におけるステップ1〜ステップ5と同じである。図13のステップ6において、電波干渉状態通知を受信したアクセスコントローラは、無線AP01において電波干渉が発生していると判定し、電波干渉中であることを示すQoS予約レスポンスをSIPサーバに送信する(ステップ7)。SIPサーバはこのQoS予約レスポンスに基づき、端末2にビジーを送信する(ステップ8)。
図14は、端末1が低電波状態にある場合のシーケンスを示す図である。図14におけるステップ1〜ステップ8は図7におけるステップ1〜ステップ8と同じである。図14のステップ9において、電波状態通知を受信したアクセスコントローラは、端末1が低電波状態にあると判定し、低電波状態であることを示すQoS予約レスポンスをSIPサーバに送信する(ステップ10)。SIPサーバはこのQoS予約レスポンスに基づき、端末2にビジーを送信する(ステップ11)。
図15は、無線AP01が輻輳中である場合のシーケンスを示す図である。図15におけるステップ1〜ステップ10は図7におけるステップ1〜ステップ10と同じである。図15のステップ11において、無線AP01は、現在割り当て可能な帯域をほとんど割り当て済みであり、QoS予約リクエストに含まれる必要帯域幅を予約することができないため、輻輳中と判定する。すると無線AP01は輻輳中であることを示すQoS予約レスポンスをアクセスコントローラに返す(ステップ12)。アクセスコントローラも同様のQoS予約レスポンスをSIPサーバに返し(ステップ13)、SIPサーバはこのQoS予約レスポンスに基づき端末2にビジーを送信する(ステップ14)。
なお、電波干渉状態判定、電波状態判定、輻輳状態判定を行う順番は、図7〜15に示したものに限られず、どのような順番でもよい。例えば、輻輳状態判定を最初に行うことができる。この場合、アクセスコントローラは、無線AP01から輻輳中であることを示すQoS予約レスポンスを受信した後に、電波干渉状態判定、電波状態判定を行わずに、輻輳中であることを示すQoS予約レスポンスをSIPサーバに送信する。また、アクセスコントローラが無線AP01から正常なQoS予約レスポンスを受信した場合は、その後、電波干渉状態判定及び電波状態判定を行い、これらがOKであれば、正常なQoS予約レスポンスをSIPサーバに送信する。アクセスコントローラが無線AP01から正常なQoS予約レスポンスを受信した場合において、その後の電波干渉状態判定及び電波状態判定のうちのいずれかがNGであった場合は、SIPサーバにその旨を示すQoS予約レスポンスを送信するとともに、予約を解放するためのメッセージを無線AP01に送信すればよい。
また、アクセスコントローラが無線AP01の帯域幅を管理し、輻輳状態判定を行う場合は、電波干渉状態判定、電波状態判定、及び輻輳状態判定の全てが良好である場合にのみ正常なQoS予約レスポンスをSIPサーバに送信することになる。
さて、図13〜図15では、電波干渉中等の場合にSIPサーバが端末2にビジーを送信することとしているが、SIPサーバは他に種々の呼制御処理を行うことが可能である。ビジーを送信すること以外の一例を図16に示す。図16は、SIPサーバの処理として携帯電話端末に呼の転送を行う例を示している。この例では、SIPサーバは、VoIP端末(URI)毎に転送先となる携帯電話端末の電話番号を保持している。また、図16に示すGW(ゲートウェイ)は、携帯電話網とVoIP網とを接続するための装置である。
図16に示すように、リソース状態の判定処理の結果、アクセスコントローラが、電波干渉中、低電波状態、輻輳中のうちのいずれかを示すQoS予約レスポンスをSIPサーバに送信する(ステップ1)。当該QoS予約レスポンスを受信したSIPサーバは、端末1に対応する携帯電話端末の電話番号を転送先として取得する(ステップ2)。そして、SIPサーバは、GWを介して端末2と携帯電話端末とを接続するためのSIPシーケンスを実行する(ステップ3、4、ステップ6〜9)とともに、GWと携帯電話端末間で接続処理が行われることにより(ステップ5)、端末2と携帯電話端末間での通話が行われる(ステップ11)。なお、GWを介したVoIP端末と携帯電話端末との間の接続処理自体は従来技術である。
端末1が、VoIP端末の機能と上記携帯電話端末の機能とを備えるデュアル端末である場合、図16に示す処理を行うことにより、端末1の保有者は、無線AP01の状態にかかわらず通話を行うことが可能になる。もちろん、携帯電話端末は端末1と全く別の端末でもよい。また、転送先は携帯電話端末に限られず、他のVoIP端末、固定電話端末等でもよい。
なお、図13〜15では端末1が着信を受ける場合について説明したが、端末1が発信する場合も同様の処理が可能である。端末1が発信する場合は、ビジーがSIPサーバから端末1に送られることになる。
また、無線APの電波干渉状態及び端末の電波状態を取得するタイミングは、上記の実施の形態で説明したタイミングに限られるものでなく、例えば定期的に取得し、それをアクセスコントローラの記憶手段が保持し、記憶手段から電波干渉状態情報、電波状態情報を取得して電波干渉状態判定及び電波状態判定を行うこととしてもよい。
(装置構成概要)
上述した動作を実現するためにSIPサーバ、アクセスコントローラ、無線AP、コンソールが備える主要機能について説明する。
本実施の形態のアクセスコントローラは、無線APに接続された端末への着信又は当該端末からの発信に係る呼接続要求を受信したSIPサーバから当該端末に関するリソース状態の問い合わせを受信する受信手段と、前記端末に関するリソース状態の問い合わせを受信したことに応じて、当該端末に接続されている前記無線APの電波干渉状態を示す電波干渉状態情報を取得し、当該電波干渉状態情報と予め定めた閾値とを比較することにより、前記無線APが電波干渉中であるか否かを判定する手段を有するリソース状態判定手段と、前記リソース状態判定手段による判定結果をSIPサーバに通知する通知手段とを有している。より詳細には次のとおりである。
図17は、SIPサーバ40、アクセスコントローラ30、無線AP10、コンソール50の機能概要例を説明するための図である。
SIPサーバ40は、SIPに基づく呼制御を行うための呼制御機能41に加えて、端末のSIPサーバ(レジストラ)への登録/削除をトリガーにして、アクセスコントローラ30に対してURI登録(有効化)/削除(無効化)のリクエストを行い、SIPメッセージ(INVITE/BYE/レスポンスなど)をトリガーにして、アクセスコントローラ30に対して、QoS予約/確保/解放のリクエストを行う等の機能を有する対アクセスコントローラインタフェース機能42を有している。
アクセスコントローラ30は、SIPサーバ40から受信した上記各リクエストに対応する処理を行い、回答(OK/NG)をSIPサーバ40に対して送信する対SIPサーバインタフェース機能31、無線APの電波干渉状態、及び端末の電波状態を示す情報を収集する電波干渉情報・端末電波状態情報収集機能36、無線APの電波干渉状態、無線APの輻輳状態、及び端末の低電波状態の判定を行う判定機能32、無線APから受信した端末登録/削除のリクエストに対応する処理を行う対無線APインタフェース機能33、コンソールからの入力に応じて(a)端末MACアドレスとSIP−URIの対、(b)無線APの最大帯域、電波干渉状態及び低電波状態判定のための閾値等をデータベース35に設定する対コンソールインタフェース機能34、及びデータベース35を有している。なお、この例はアクセスコントローラ30が各無線APの帯域を管理する場合の例である。
また、無線AP10は無線AP本来の機能である無線AP機能11に加え、端末の無線APへの接続/切断をトリガーに、アクセスコントローラ30に対して端末登録/削除のリクエストを行う対アクセスコントローラインタフェース機能12を有している。
コンソール50は操作者の入力を受け付けるユーザインタフェース機能51と、設定情報をアクセスコントローラ30に送信する対アクセスコントローラインタフェース機能52を有している。
SIPサーバ40、アクセスコントローラ30はそれぞれCPU、記憶装置、通信用装置等を備えたコンピュータに上記各機能を実現するためのプログラムを搭載することにより実現されるものである。他の実施の形態についても同様である。
次に、アクセスコントローラ30が保持するデータベース35内の端末管理データ、無線AP管理データ、及び閾値データについて説明する。
図18に端末管理データの例を示す。ここで示す例では端末MACアドレスと端末SIP−URIとを対応付けて予めアクセスコントローラ30のデータベース35に固定値として登録しておく。そして、図7等で説明したシーケンスにより送受信されるデータに基づき、無線状態、呼状態、接続APをデータベース35に随時記録することにより端末を管理する。
図18に示すデータにおける「無線状態」は端末と無線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確保済"が記録される。
「電波状態」は、端末の電波状態を示す情報であり、本実施の形態では端末の電波強度を示す値である。図7〜15で説明した方法で電波状態判定を行う場合は、この値をデータベース35に保持しておく必要は必ずしもないが、この値をデータベース35に保持しておくことにより、呼接続中の端末毎の電波状態を把握することが可能となる。また、定期的に電波状態情報を取得することにより、電波状態判定を行う場合は、電波状態を示す値をデータベース35に保持しておくことが必要である。
図19に無線AP管理データの例を示す。APIDとリソース上限値は、予め登録される固定値データであり、利用中リソース量、C.U値、リトライパケット数、パケット受信分散値、パケット送信分散値は、随時変更されるデータである。
図19における「APID」は無線AP毎に一意なIDであり、端末管理データの「接続AP」に登録される情報と同じものである。「リソース上限値」は無線APで利用可能なリソース上限値である。「リソース利用量」は無線APで現在使われている帯域量であり、無線APに接続された端末の呼数に応じて動的に変化するものである。この情報と「リソース上限値」との差分により、空きの帯域量を判定でき、当該無線APが輻輳中か否かを判断できる。
なお、無線APがリソース上限値と利用中リソース量を保持してもよい。無線APがこれらのデータを保持する場合には、無線APが輻輳判定を行い輻輳判定結果がアクセスコントローラに送信されることになる。一方、アクセスコントローラがこのデータを保持することにより、無線APに輻輳判定等の機能を設ける必要がなくなる。
C.U値、リトライパケット数、パケット受信分散値、パケット送信分散値は、電波干渉状態を示す値である。図7〜15で説明した方法で電波干渉状態判定を行う場合は、これらの値をデータベース35に保持しておく必要は必ずしもないが、これらの値をデータベース35に保持しておくことにより、無線AP毎の電波干渉状態を把握することが可能となる。また、定期的に電波干渉状態情報取得を行うことにより、電波干渉状態判定を行う場合は、図19に示すように電波干渉状態を示す値をデータベース35に保持しておくことが必要である。
図20に閾値データの例を示す。図20に示すように、閾値データは、端末が低電波状態であるか否かを判定するための閾値、及び無線APが電波干渉中であるか否かを判定するための閾値を含む。なお、図20に示す閾値データは、全ての無線APに共通としてもよいし、無線AP毎に備えることとしてもよい。
(アクセスコントローラ詳細機能構成)
次に、アクセスコントローラ30の詳細機能構成を図21を用いて説明する。図21に示す例は輻輳判定、リソース予約/確保等の無線APリソース管理をアクセスコントローラ30が行う場合の例である。また、図21に示す例は、図18、19に示したデータをデータベース35が保持する場合の例である。また、以下でのリソース予約等におけるリソースとは使用帯域を示している。
図21に示すように、アクセスコントローラ30は、データベース35、SIP連携I/F60、リソース管理機能70、データ管理機能80、無線AP管理機能90、端末管理機能100、無線AP連携I/F110を有している。
以下、各機能部の機能についてより詳細に説明する。
SIP連携I/F60はSIP要求受付部61、SIP要求返却部62を有している。SIP要求受付部61は端末登録要求受付部64とリソース要求受付部65を有している。端末登録要求受付部64はレジストラから端末登録要求を受け付ける。また、端末登録情報を端末登録部(アプリケーション層)101に渡す。リソース要求受付部65はSIPサーバ40からリソース要求を受け付け、リソース要求種別(予約/確保/解放)に応じて、リソース予約/解放部71にリソース操作を要求する。
SIP要求返却部62は端末登録要求返却部66とリソース要求返却部67を有しており、端末登録要求返却部66は端末登録要求受付部64へのリクエストの結果をレジストラに返却し、リソース要求返却部67はリソース要求受付部65へのリクエストの結果をSIPサーバ40に返却する。リクエストの結果としては、正常にリソース要求が受け付けられたことを示すものの他、無線APが電波干渉中であること、無線APが輻輳中であること、端末が低電波状態であること等の異常状態を示すものがある。
リソース管理機能70は状態判定/リソース予約/解放部71を有している。状態判定/リソース予約/解放部71はリソース要求種別(予約/確保/解放)に応じて、データ更新部81にリソース操作を要求する。また、空きリソース量に応じて、輻輳判断を行う。例えば、上限リソース量から使用中リソース量を減算した値が、要求されたリソース量以下である場合に輻輳中であると判断する。更に、状態判定/リソース予約/解放部71は、データベース35に格納されている閾値と、無線APから取得した電波状態情報や電波干渉状態情報とを比較することにより、電波状態判定及び電波干渉状態判定を行い、判定結果をリソース要求返却部67に通知する。
データ管理機能80はデータ更新部81を有している。データ更新部81はデータベース35のデータ読み出し/追加/更新/削除を行う。また、SIP−URIと端末MACアドレスとの相互変換を行う。無線AP管理機能90は、無線AP/リソース登録部91と無線AP状態登録部92を有している。無線AP/リソース登録部91は無線APの登録及び当該無線APに対するリソース上限値をコンソール50からの指示に基づきデータベース35に設定する。また、無線AP状態登録部92は、無線APから取得した電波干渉状態情報をデータ更新部81を介してデータベース35に格納する。
端末管理機能100は、端末登録部(アプリケーション層)101、端末登録部(データリンク層)102、及び端末電波状態登録部103を有している。端末登録部(アプリケーション層)101は端末登録要求受付部64から、リソース管理対象端末のSIP−URIを受け取り、データ更新部81に対してデータ登録を要求する。当該処理により、SIP−URIが本システムで有効化される。また、端末登録部(データリンク層)102は端末MAC登録要求受付部111から、リソース管理対象端末のMACアドレスを受け取り、データ更新部81に対してデータ登録を要求する。当該処理により、端末MACアドレスが本システムで有効化される。また、端末電波状態登録部103は、無線APから受信する端末の電波状態情報をデータ更新部81を介してデータベース35に格納する。
無線AP連携I/F110は、端末MAC登録要求受付部111、無線AP電波干渉状態取得部112、及び端末電波状態取得部113を有している。端末MAC登録要求受付部111は、無線APで発生する端末イベント(Association/Disassociation/Reassociation)を契機として、イベントを受け付け、当該イベントの種別に応じて、端末登録部(データリンク層)102に対して、端末MACアドレスの登録/削除/再登録を要求する。無線AP電波干渉状態取得部112は、無線APに対して無線AP電波干渉状態情報の要求を送信し、無線APから無線AP電波干渉状態情報を受信する。端末電波状態取得部113は、無線APに対して特定の端末の電波状態情報の要求を送信し、無線APから当該端末の電波状態情報を受信する。
<第2の実施の形態>
次に、本発明の第2の実施の形態について説明する。第1の実施の形態では、電波干渉中等にある無線APに接続された端末に対して他の端末から着信があった場合等に、当該他の端末に対してビジー信号を送出する等の呼制御を行う例を説明した。
ある無線APが電波干渉中等で接続不可であっても、隣接する無線APは接続可能である場合があるが、第1の実施の形態では隣接する無線APを有効に活用できていない。そこで、本実施の形態では、電波干渉中等で接続不可の無線APに隣接する無線APを用いて通信を継続する例について説明する。
図22は、本実施の形態の動作概要の一例を示す図である。最初に端末1が無線AP10に接続されている状態で端末1から端末2に対する発信、もしくは端末2から端末1に対する発信が行われたとする。このとき、第1の実施の形態と同様にして無線AP10における電波干渉状態、端末1の電波状態、無線AP10における輻輳状態のチェックがなされ、いずれかが所定の条件を満たさなければ、端末1と無線AP10間の無線リンクを切断する。
端末1は続いて無線AP20へ接続する。すると、無線AP20において上記と同様のチェックがなされ、所定の条件を満たさなければ、端末1と無線AP20間の無線リンクを切断する。このような処理が、予め定めた回数まで行われる。なお、この繰り返しの回数をリトライ回数と呼ぶ。図22に示す例では、無線AP25に端末1が接続することより端末2との呼接続が成功し、端末1と端末2間で通話が行われる。なお、予め定めた回数まで無線APの接続替えを行っても、所定の条件を満たさない場合は、ビジー処理等の呼処理が行われる。
次に、図23を参照して、アクセスコントローラ30における判定処理を説明する。この図に示すとおり、アクセスコントローラ30は、SIPサーバ40から端末1に係る帯域予約要求(リソース状態問い合わせ)を受信すると(ステップ1)、まず、端末1と無線リンク接続している無線APの電波干渉状態を示す情報を当該無線APから取得し(ステップ2)、それが予め定めた電波干渉閾値未満かどうかを調べ、電波干渉閾値未満であればステップ4の処理に進む(ステップ3)。ステップ3において無線APの電波干渉状態を示す情報が電波干渉閾値以上である場合は、無線APが電波干渉中であるため、当該無線APを介して端末1と端末2を接続すべきでないと判定し、リトライ回数が規定値未満であれば無線リンク切断を行う(ステップ10、16)。リトライ回数が規定値以上であれば、電波干渉中であることを示す応答をSIPサーバ40に送信する(ステップ10、11)。
ステップ4において、アクセスコントローラ30は、端末1の電波強度(電波状態)を無線APから取得し、それが予め定めた電波強度閾値より大きいかどうかを調べ、電波強度閾値より大きければステップ6の処理に進む(ステップ5)。端末1の電波状態が予め定めた電波強度閾値以下である場合は、端末1が低電波状態にあり、端末1と端末2を接続すべきでないと判定し、リトライ回数が規定値未満であれば無線リンク切断を行う(ステップ12、16)。リトライ回数が規定値以上であれば、低電波状態であることを示す応答をSIPサーバ40に送信する(ステップ12、13)。
ステップ6において、アクセスコントローラ30は、無線APが輻輳中であるかどうかを調べ、輻輳中であれば端末1と端末2を接続すべきでないと判定し、リトライ回数が規定値未満であれば無線リンク切断を行う(ステップ14、16)。リトライ回数が規定値以上であれば、輻輳中であることを示す応答をSIPサーバ40に送信する(ステップ14、15)。
全ての条件を満たした場合は、ステップ7において帯域予約OKを示す応答をSIPサーバ40に送信する。その後、端末1と端末2との接続のためのシーケンスを経て、端末1と端末2間で音声通話が行われる。一方、ステップ11、13、15の後は、例えばSIPサーバ40が端末2に対してビジーを通知する。また、第1の実施の形態の例と同様に、携帯電話網への接続を行ってもよい。
次に、本実施の形態におけるシステムの動作を詳細に説明する。以下、アクセスコントローラが保持する端末管理データを、呼状態管理テーブルとして示している。また、動作の前提として、保守端末からアクセスコントローラに、リトライ規定値(上限値)と、再接続要求拒否時間が登録されるものとする。この登録は、端末毎にしてもよいし、全ての端末に共通の値として設定してもよい。また、無線AP毎に設定してもよい。
端末1が接続できる状態の無線AP02が存在する環境の下で、接続不可(本例では、電波干渉中)の無線AP01に接続された端末1に端末2から着信があった場合のシステムの動作について図24、図25を参照して詳細に説明する。
図24におけるステップ1〜ステップ6は図13におけるステップ1〜ステップ6と同じである。無線AP01が電波干渉中であることを検出したアクセスコントローラは、呼状態管理テーブルにおける端末1の呼状態を「隣接無線APへ切替中」とし、端末1が隣接無線APへ切替中であること、及び電波干渉中であることを示す情報を含むQoS予約レスポンスをSIPサーバに返す(ステップ7)。
アクセスコントローラは、端末が無線APに接続後、無線APが接続不可であった回数をカウントする。つまり、ステップ8では、"1"をカウントする。この"1"は、1回リトライに失敗したことを示す。なお、この例では、最初の接続を行うことも"リトライ"に入れているが、最初の接続に失敗した後のリトライからカウントを開始することとしてもよい。そして、この数値と予め定めた数値とを比較し、この数値が予め定めた数値に達していた場合は、後述する呼処理に移る。このような判定処理は、リトライが永久に続くことを防止するために行われる。図24の場合は、予め定めた数値は1より大きい数値であるものとし、1回目のリトライ失敗であるから、再接続のための処理に移行する。
ステップ9にて、アクセスコントローラは、MS01と再接続要求拒否時間を含む無線リンク切断要求(隣接無線AP移動指示とも称することができる)を無線AP01に送信する。無線AP01は、端末1に対する再接続要求拒否時間を設定する(ステップ10)。これにより、無線AP01は、端末1から再度接続要求を受けた場合に、再接続要求拒否時間内であれば、その接続要求を拒否する。つまり、接続要求を受けても接続動作を行わない。
無線リンク切断要求を受信した無線AP01は、無線リンク切断指示(Deauthentication)を端末1に送信することにより無線リンクを切断する(ステップ11)。無線リンクを切断された端末1は、隣接する無線APである無線AP02に接続要求(Association)を送信する(ステップ12)。なお、端末1の仕様によっては、無線AP01への接続を再度試みる場合があるが、その場合でも、再接続要求拒否時間の間は、無線AP10から再度端末登録リクエストが送信されることはない。
無線AP02は、端末1のMSIDであるMS01を登録する(ステップ13)。そして、無線AP02は無線AP02のID(AP02)と端末1のMACアドレス(MS01)とを含む端末登録リクエストをアクセスコントローラに対して送信する(ステップ14)。アクセスコントローラは無線AP02から受信した無線APのID(AP02)と端末1のMACアドレス(MS01)とを記憶装置に格納することにより、MSIDとAPIDの更新を行う。(図25のステップ15)。そして、アクセスコントローラは無線AP02に対して端末登録レスポンスを返す(ステップ16)。アクセスコントローラは、端末1に対する呼状態を"無し"にする(ステップ17)。
その後、無線AP02に関し、図7のステップ4〜ステップ13と同様の処理が実行されることにより帯域予約が行われ(図25のステップ18〜27)、更に図8と同様の処理が行われることにより端末1と端末2間での呼接続が行われる。
次に、無線AP01が接続不可(本例では、電波干渉中)であるとともに、隣接無線AP02も接続不可(本例では、電波干渉中)であり、呼の中断を行う場合の動作を図26を参照して説明する。
端末2からのINVITE送信から、無線AP02が電波干渉通知をアクセスコントローラに対して送信するまでの処理は図24のステップ1〜図25のステップ19に示した処理と同じである。
図26のステップ20において、アクセスコントローラは、無線AP02から受信した電波干渉通知に基づき、無線AP02が電波干渉中であると判定する。アクセスコントローラは、現在のリトライ回数と、リトライ回数の上限値とを比較する。本例においては、現在のリトライ回数(=2)が予め規定したリトライ回数(=2)に達したと判定し、リトライを失敗したと判定する(ステップ21)。そこで、アクセスコントローラは、SIPサーバに対して電波干渉中であることを示す情報を含むQoS予約レスポンスを返す(ステップ22)。当該QoS予約レスポンスを受信したSIPサーバは、「呼の中断」を示すメッセージを端末2に送信する(ステップ23)。なお、アクセスコントローラでリトライを繰り返す方式の他、SIPでリトライを繰り返す方式としてもよい。
次に、端末1に接続できる状態の無線AP02が存在する環境の下で、接続不可(本例では、電波干渉中)の無線AP01に接続された端末1が端末2に発信を行う場合のシステムの動作について図27、28を参照して詳細に説明する。
図27におけるステップ1〜ステップ5は図10におけるステップ1〜ステップ5と同じである。ステップ6において、アクセスコントローラは無線AP01が電波干渉中であると判定する。
アクセスコントローラは、呼状態管理テーブルにおける端末1の呼状態を「隣接無線APへ切替中」とし、端末1が隣接無線APへ切替中であることを示す情報と、電波干渉中であることを示す情報とを含むQoS予約レスポンスをSIPサーバに返す(ステップ7)。このQoS予約レスポンスを受信したSIPサーバは、呼の中断を行うためのメッセージを端末1に送信する(ステップ8)。また、アクセスコントローラは、MS01と再接続要求拒否時間を含む無線リンク切断要求(隣接無線AP移動指示)を無線AP01に送信する(ステップ10)。無線AP01は、端末1に対する再接続要求拒否時間を設定する(ステップ11)。これにより、無線AP01は、端末1から再度接続要求を受けた場合に、再接続要求拒否時間内であれば、その接続要求を拒否する。つまり、接続要求を受けても接続動作を行わない。
無線リンク切断要求を受信した無線AP01は、無線リンク切断指示(Deauthentication)を端末1に送信することにより無線リンクを切断する(ステップ12)。無線リンクを切断された端末1は、隣接する無線APである無線AP02に接続要求(Association)を送信する(ステップ13)。
無線AP02は、端末1のMSIDであるMS01を登録する(ステップ14)。そして、無線AP02は無線APのID(AP02)と端末1のMACアドレス(MS01)とを含む端末登録リクエストをアクセスコントローラに対して送信する(図28のステップ15)。アクセスコントローラは無線AP02から受信した無線APのID(AP02)と端末1のMACアドレス(MS01)とを記憶装置に格納することにより、MSIDとAPIDの更新を行う。(ステップ16)。そして、アクセスコントローラは無線AP02に対して端末登録レスポンスを返す(ステップ17)。アクセスコントローラは、端末1に対する呼状態を"無し"にする(ステップ18)。なお、アクセスコントローラは、端末1からの発信に係る接続がNGであったことを認識しているので、これ以降の電波干渉確認等の処理は行わない。
そして、端末1でユーザによる再操作がなされることにより、端末1からINVITEメッセージがSIPサーバに対して送信される(ステップ19)。その後は、無線AP02に関し、図10のステップ1〜図11のステップ25と同様の処理が実行されて、端末1と端末2間での呼接続が行われる。
(装置構成について)
第2の実施の形態における装置の機能概要を図29を参照して説明する。第2の実施の形態における装置の基本的な構成は第1の実施の形態における装置構成と同様である。以下、第1の実施の形態の装置と異なる主な点について説明する。
アクセスコントローラ30は、第1の実施の形態で説明した機能に加えて、呼接続制御機能38と端末制御機能39を有している。
呼接続制御機能38は、呼接続要求で電波干渉状態、輻輳状態、端末の低電波状態検出時に、SIPサーバからのQoS予約要求に対し、"隣接無線APへ切替中"の状態を返却する機能、端末制御機能39から、該当端末の(他の無線APへの)移動完了を受け取ると、判定機能に移動先の無線APのリソース状態をチェック(電波干渉中、輻輳中、端末が低電波状態か否かを判定)するよう指示する機能、及び、移動先の無線APが電波干渉中、輻輳中、端末が低電波状態ではない場合、SIPサーバに対して、QoS予約OKを通知する機能等を有している。
また、端末制御機能39は、電波干渉状態、輻輳検出、端末の低電波状態検出時に、端末に対して隣接する無線APへの移動を指示する機能、多数の無線APに繰り返して移動を行うことが無いように、移動回数をチェックする機能、及び該当端末が隣接APに移動したことを検出し、この契機で呼接続制御機能に対し、移動完了を通知する機能を有している。
図30に、本実施の形態での端末管理データを示す。本実施の形態では、呼状態として、「隣接無線APへ切替中」を含む。アクセスコントローラは、端末が接続する無線APが接続不可の状態であることを検知したことに応じて呼状態を「隣接無線APへ切替中」とする。ただし、リトライ回数が上限値に達していた場合は、切替のための動作を行わないので、呼状態は無しとする。そして、隣接無線APに対する端末の登録が済んだことを契機として、呼状態を「隣接無線APへ切替中」から「無し」にする。
また、本実施の形態における端末管理データは、端末毎の無線リンクリトライ回数(上限値)と、実際の無線リンクリトライ回数を含む。実際の無線リンクリトライ回数が上限値に達した場合に呼接続失敗と判定される。
また、アクセスコントローラは、図19に示した無線AP管理データに加えて、図31に示す再接続要求拒否時間管理用の無線AP管理データを有する。図31に示すように、無線AP毎及び端末毎に、再接続要求拒否時間と、無線リンクを切断してから実際に経過した時間である再接続要求拒否経過時間が記録される。
図32に、本実施の形態におけるアクセスコントローラの詳細機能構成図を示す。以下、第1の実施の形態と異なる部分について主に説明する。
SIP要求返却部62におけるリソース要求返却部67は、無線APが電波干渉状態、輻輳中、もしくは端末が低電波状態である場合に、SIPサーバに"隣接無線APへ切替中"である旨を通知する機能を含む。また、リソース予約/解放部71は、無線APの電波干渉状態、輻輳状態、端末の電波状態を調べ、無線APが電波干渉状態、輻輳中、もしくは端末が低電波状態である場合に、端末の無線リンク切断を要求する機能を有している。また、リソース管理機能70は、ある端末の無線リンクリトライ回数が、予め定めた上限値に達したかどうかを判定する無線リンクリトライ判定部73を有している。
また、データ更新部81は、無線APが電波干渉状態、輻輳中、もしくは端末が低電波状態である場合に、端末の呼状態を「隣接無線APへ切替中」として登録する機能を備えている。また、無線AP連携I/F110は、再接続要求通知部114を有している。再接続要求通知部114は、無線APが電波干渉状態、輻輳中、もしくは端末が低電波状態である場合に、端末を他の隣接無線APへ再接続させるために、無線APに無線リンク切断要求を送信するものである。
<第3の実施の形態>
次に本発明の第3の実施の形態について説明する。第2の実施の形態は、発着信時において、電波干渉中、輻輳中、端末が低電波状態になる無線APを回避し、他のアクセスポイントに迂回して接続するものであったが、第3の実施の形態は、通話中において、接続する無線APが電波干渉中、もしくは端末が低電波状態になった場合に、接続する無線APを自動的に切り替え、端末の通話状態をより良く維持するものである。
図33は、本実施の形態の動作概要の一例を示す図である。本実施の形態では、アクセスコントローラが各無線APの電波干渉情報、通話中端末の電波状態情報を定期的に収集し、保持している。
最初に端末1が無線AP10に接続され、端末2と通話中であるものとする。ここで定期的に収集する電波干渉情報、通話中端末の電波状態情報から、アクセスコントローラが電波干渉状態もしくは端末1の低電波状態を検出して、端末1が無線AP01に接続不可になったものと判定する。すると、アクセスコントローラは、端末1と無線AP10間の無線リンクを切断する。
無線AP10との無線リンクを切断された端末1は無線AP20へ接続する。ここでは、アクセスコントローラは、第1の実施の形態と同様の電波干渉状態、端末1の電波状態、輻輳状態のチェックを行い、いずれも正常であれば無線AP20を介して端末1と端末2とが通話を行うことになる。
図33の例では、無線AP20も接続不可と判定され、無線リンクの切断処理が行われ、端末1は無線AP25への接続を行う。そして、アクセスコントローラは、無線AP25に対して無線AP20と同様のチェックを行う。このような処理が、予め定めた回数まで行われる。なお、この繰り返しの回数をリトライ回数と呼ぶ。図33に示す例では、無線AP25に端末1が接続することより端末2との呼接続が成功し、端末1と端末2間で通話が行われる。なお、予め定めた回数まで無線APの接続替えを行っても、所定の条件を満たさない場合は、呼切断処理等の呼処理が行われる。
次に、図34を参照して、アクセスコントローラ30における判定処理を説明する。ここでは、処理に係る無線AP配下の端末が通話中であるものとする(ステップ1)、アクセスコントローラ30は、各無線APから電波干渉状態情報を取得する処理と、通話中端末の電波強度(電波状態)を取得する処理を例えば定期的に行っている(ステップ2)。なお、これらの処理は同期して行ってもよいし、非同期で行ってもよい。そして、アクセスコントローラは、取得した情報に基づき、通話中の端末が無線APに接続したままでよいかどうかの判定、つまり、無線APの接続替え要否判定を行う(ステップ3)。
ここで、ある無線APについて電波干渉状態であることが検出されるか、もしくは、端末の低電波状態が検出されると、端末に対する無線リンクの切断処理を行う(ステップ4)。なお、低電波状態については低電波状態になっている端末に対して無線リンク切断処理を行う。また、電波干渉状態については、当該無線APに接続している全ての端末に対して無線リンク切断処理を行ってもよいし、後述するように、所定の条件を満たす端末に対してのみ無線リンク切断処理を行ってもよい。ステップ4で、複数の端末の無線リンクが切断された場合は、以下の処理は無線リンクの切断された端末毎に行われることになる。
無線リンクを切断された端末は、別の無線AP(切替先の無線AP)に接続を行う。そして、アクセスコントローラ30は、切替先の無線APの電波干渉状態を示す情報を当該無線APから取得し(ステップ5)、それが予め定めた電波干渉閾値未満かどうかを調べ、電波干渉閾値未満であればステップ7の処理に進む(ステップ6)。ステップ6において無線APの電波干渉状態を示す情報が電波干渉閾値以上である場合は、無線APが電波干渉中であるため、当該無線APを介して端末1と端末2を接続すべきでないと判定し、リトライ回数が規定値未満であれば無線リンク切断を行う(ステップ11、4)。リトライ回数が規定値以上であれば、電波干渉中であることを示す情報を含むAP切替失敗応答をSIPサーバ40に送信する(ステップ12)。
ステップ6において、アクセスコントローラ30は、端末1の電波強度を切替先の無線APから取得し、それが予め定めた電波強度閾値より大きいかどうかを調べ、電波強度閾値より大きければステップ8の処理に進む(ステップ7)。端末1の電波強度が予め定めた電波強度閾値以下である場合は、端末1が低電波状態にあり、端末1と端末2を接続すべきでないと判定し、リトライ回数が規定値未満であれば無線リンク切断を行う(ステップ13、4)。リトライ回数が規定値以上であれば、低電波状態であることを示すAP切替失敗応答をSIPサーバ40に送信する(ステップ14、4)。
ステップ9において、アクセスコントローラ30は、無線APが輻輳中であるかどうかを調べ、輻輳中であれば端末1と端末2を接続すべきでないと判定し、リトライ回数が規定値未満であれば無線リンク切断を行う(ステップ15、4)。リトライ回数が規定値以上であれば、輻輳中であることを示すAP切替失敗応答をSIPサーバ40に送信する(ステップ15、16)。
全ての条件を満たした場合は、ステップ10においてAP切替が完了し、切替先の無線APを介して端末1と端末2間で音声通話が行われる。一方、ステップ12、14、16の後は、例えばSIPサーバ40がビジーを通知する。また、第1の実施の形態の例と同様に、携帯電話網への接続を行ってもよい。
以下、本実施の形態における処理の詳細について説明する。前述したように、本実施の形態では、アクセスコントローラは定期的に通話中の端末が接続している無線APの電波干渉状態を当該無線APから取得し、電波干渉状態の判定を行うととともに、通話中の端末の電波状態を無線APから取得し、電波状態の判定を行っている。
図35Aに、電波干渉状態収集の動作例を示す。図35Aに示すように、端末1が端末2と通話中の状態において(ステップ1)、電波干渉状態要求を送信し(ステップ2)、電波干渉状態通知を受信し(ステップ3)、無線AP管理データ更新を行い(ステップ4)、電波干渉状態の判定を行う(ステップ5)。本例ではステップ5で電波干渉なしと判定されている。
電波干渉状態要求からの処理は定期的(図35Aの例ではT1毎)に行われる。図35Aの例では、2回目の電波干渉状態判定(ステップ9)において電波干渉中であることが検出され、無線APの切り替え処理が行われる(ステップ10)。なお、無線APからの定期的な電波干渉状態情報収集処理は、例えば、当該無線APに少なくとも1つの通話中端末が接続しているときに実行することとする。
図35Bに、端末の電波状態情報収集のシーケンスを示す。端末1が端末2と通話中の状態において(ステップ1)、端末1の電波状態要求を送信し(ステップ2)、端末1の電波状態通知を受信し(ステップ3)、電波状態の判定を行う(ステップ4)。本例ではステップ4で電波状態が良好と判定されている。
電波状態要求からの処理は定期的(図35Bの例ではT2毎)に行われる。なお、T1とT2は同じでもよいし、異なっていてもよい。図35Bの例では、2回目の電波状態判定(ステップ7)において端末1の低電波状態が検出され、無線APの切替処理が行われる(ステップ8)。
なお、1回の電波状態要求で、無線APに接続されている全ての端末の電波状態情報を取得してもよいし、当該無線APを介して通話中の全端末の電波状態を取得することとしてもよい。
次に、電波干渉情報定期収集、判定により無線AP01の電波干渉が検出され、無線AP02への切替を行う場合のシーケンスを図36、図37を参照して説明する。
無線AP01に接続された端末1が端末2と通話中である状態(ステップ1)において、無線AP01に電波干渉が発生しているものとする。電波干渉情報定期収集の中での1つの電波干渉情報収集として、ステップ2において、アクセスコントローラは電波干渉状態要求を無線AP01に送信し、ステップ3において電波干渉状態通知を受信する。
アクセスコントローラは無線AP01が電波干渉中であると判定すると(ステップ4)、ステップ5にて、MS01と再接続要求拒否時間を含む無線リンク切断要求を無線AP01に送信する。また、アクセスコントローラは、端末1の呼状態を無線AP切替中にする。無線AP01は、端末1に対する再接続要求拒否時間を設定する(ステップ6)。これにより、無線AP01は、端末1から再度接続要求を受けた場合でも、再接続要求拒否時間内であれば、その接続要求を拒否する。つまり、接続要求を受けてもその後の動作を行わない。
無線リンク切断要求を受信した無線AP01は、無線リンク切断指示(Deauthentication)を端末1に送信することにより無線リンクを切断する(ステップ7)。無線リンクを切断された端末1は、無線AP01に隣接する無線APである無線AP02に接続要求(Association)を送信する。なお、端末1の仕様によっては、再度数回無線AP010への接続を試み、接続に失敗した場合に隣接無線APへの接続を行う場合があるが、再接続要求拒否時間の間は、無線AP01から再度端末登録リクエストが送信されることはない。
無線AP02は端末1のMACアドレス(MSID)を取得し、登録する(ステップ9)。無線AP02は無線AP02のID(AP02)と端末1のMACアドレス(MS01)とを含む端末登録リクエストをアクセスコントローラに対して送信する(ステップ10)。アクセスコントローラは無線AP02から受信した無線AP02のID(AP02)を端末1のMACアドレス(MS01)と対応付けて記憶装置に格納することにより登録の更新を行う(ステップ11)。そして、アクセスコントローラは無線AP02に対して端末登録レスポンスを返す(ステップ12)。
アクセスコントローラは、端末登録リクエストを送信した無線AP02に対して、電波干渉確認(ステップ13〜14)を行い、干渉がないと判定されると(ステップ15)、端末の電波状態確認(ステップ16、17)を行う。そして、電波状態が良好であると判定される(ステップ18)。アクセスコントローラは、「無線AP切替中」である端末に関する端末登録リクエストを受信した場合は、SIPサーバからのトリガーを受けることなく、MS01と必要帯域幅を含むQoS確保リクエストを送信する(ステップ19)。
ステップ20にて、無線AP02において端末1に対する帯域確保がなされ、QoS確保レスポンスがアクセスコントローラに送信される(ステップ21)。アクセスコントローラは端末1に対する「呼状態」を"QoS確保済"とし、その後、無線AP02を介して端末1と端末2間での通話が行われる(ステップ22)。
次に、電波干渉情報定期収集処理で無線AP01の電波干渉が検出され、切替先の無線AP02も電波干渉中であったが、次の無線AP03で切替が成功する場合の例を図38、図39を参照して説明する。
図38において、ステップ1〜ステップ14までは、図36のステップ1〜ステップ14と同じである。ステップ15において、アクセスコントローラは、無線AP02が電波干渉状態にあることを検出する。
アクセスコントローラは、無線APが接続不可であった回数をカウントする。つまり、図38のステップ16では、"1"をカウントする。この"1"は、1回リトライに失敗したことを示す。そして、この数値と予め定めた数値とを比較し、この数値が予め定めた数値に達していた場合は、後述する呼処理に移る。このような判定処理は、リトライが永久に続くことを防止するために行われる。図38の場合は、予め定めた数値は1より大きい数値であるものとし、1回目のリトライ失敗であるから、呼処理に移行せずに、再接続のための処理に移行する。
ステップ17にて、アクセスコントローラは、MS01と再接続要求拒否時間を含む無線リンク切断要求を無線AP02に送信する。無線AP02は、端末1に対する再接続要求拒否時間を設定する(ステップ18)。これにより、無線AP02は、端末1から再度接続要求を受けた場合でも、再接続要求拒否時間内であれば、その接続要求を拒否する。つまり、接続要求を受けてもその後の動作を行わない。
無線リンク切断要求を受信した無線AP02は、無線リンク切断指示(Deauthentication)を端末1に送信することにより無線リンクを切断する(図39のステップ19)。無線リンクを切断された端末1は、無線AP02に隣接する無線APである無線AP03に接続要求(Association)を送信する。なお、端末1の仕様によっては、再度数回無線AP02への接続を試み、接続に失敗した場合に隣接無線APへの接続を行う場合があるが、再接続要求拒否時間の間は、無線AP02から再度端末登録リクエストが送信されることはない。
無線AP03は端末1のMACアドレス(MSID)を取得し、登録する(ステップ21)。無線AP03は無線AP03のID(AP03)と端末1のMACアドレス(MS01)とを含む端末登録リクエストをアクセスコントローラに対して送信する(ステップ22)。アクセスコントローラは無線AP03から受信した無線AP03のID(AP03)を端末1のMACアドレス(MS01)と対応付けて記憶装置に格納することにより登録の更新を行う(ステップ23)。そして、アクセスコントローラは無線APに対して端末登録レスポンスを返す(ステップ24)。
アクセスコントローラは電波干渉確認(ステップ25〜26)を行い、干渉がないと判定されると(ステップ27)、端末の電波状態確認(ステップ28、29)を行う。そして、電波状態が良好であると判定される(ステップ30)。本実施の形態では、アクセスコントローラは、「無線AP切替中」である端末に関する端末登録リクエストを受信した場合は、SIPサーバからのトリガーを受けることなく、端末登録リクエストを送信した無線AP03に対して、MS01と必要帯域幅を含むQoS確保リクエストを送信する(ステップ31)。
ステップ32にて、無線AP03において端末1に対する帯域確保がなされ、QoS確保レスポンスがアクセスコントローラに送信される(ステップ33)。アクセスコントローラは端末1に対する「呼状態」を"QoS確保済"とし、その後、無線AP03を介して端末1と端末2間での通話が行われる(ステップ34)。
次に、図40〜図41を参照して、無線AP切替に失敗し、端末に対する呼制御が行われる場合の動作例1を説明する。
切替先の無線AP02が電波干渉中であり、図38のステップ1〜図39のステップ26と同様の処理が行われたものとする(図40のステップ1〜図41のステップ27)。本動作例1では、無線AP03も電波干渉中であるので、ステップ27において、アクセスコントローラは無線AP03が電波干渉中であると判定する。
本動作例1では、リトライ回数の規定値が2と設定されているものとする。図41のステップ28において、アクセスコントローラはリトライ回数のカウント値を"2"とし、規定値と比較し、リトライ回数が規定値に達したと判定したため、呼状態管理テーブルの「呼状態」を"無し"に変更する。
そして、アクセスコントローラは、端末1のURIであるURI1と、無線AP切替の失敗理由である"電波干渉中"を含む無線AP切替失敗通知をSIPサーバに送信する(ステップ29)。本動作例1では、無線AP切替失敗通知を受信したSIPサーバは、BYEにより正常終了処理を行う(ステップ30〜ステップ33)。なお、アクセスコントローラでリトライを繰り返す方式の他、SIPでリトライを繰り返す方式としてもよい。
無線AP切替失敗通知を受領した後のSIPサーバの動作には種々のバリエーションがあり、種々のバリエーションのうちどの動作を用いるかは、SIPサーバに予め設定しておくことができる。
次に、無線AP切替失敗通知を受領した後のSIPサーバの動作例2を図42を参照して説明する。動作例2では、端末1が無線AP切替を実施したが、切替先無線APが電波干渉中、端末低電波状態、輻輳中のうちのいずれかにより無線切替が失敗し、別内線のVoIP端末(本例では固定VoIP端末)へ転送が行われる。本動作例2では、第1の実施の形態における図16で示した場合と同様に、SIPサーバには端末毎にその端末に対応する転送先端末を記録した転送先テーブルが登録されているものとする。また、端末1の転送先である端末3(URI3)は有線でネットワーク接続された固定VoIP端末であるものとする。
端末1からBYEに対する応答を受信した後(図42のステップ3)、SIPサーバは、転送先テーブルを参照し、無線AP切替を失敗した端末1(URI1)に対応する転送先URI3(端末番号)を取得する(ステップ4)。そして、SIPサーバは、端末2に対して端末3への接続替えを要求するSIPシーケンスを実行し(ステップ5〜ステップ8)、着信先のURI3を指定したQoS予約リクエストをアクセスコントローラに送信する(ステップ9)。端末3は固定VoIP端末であり、アクセスコントローラの管轄外であるため、アクセスコントローラはQoS予約を行わず、何も行わずにNoMatchをSIPサーバに返す(ステップ10)。その後、SIPサーバは転送のための呼接続処理を行い(図42のステップ11〜ステップ15)、端末3と端末2間での音声通信が行われる(ステップ16)。
次に、AP切替失敗通知を受領した後のSIPサーバの動作例3を図43を参照して説明する。動作例3では、端末1が無線AP切替を実施したが、無線APの電波干渉中、端末低電波状態、無線AP輻輳中のうちのいずれかにより無線AP切替が失敗し、外線の端末(本例では携帯電話端末)へ転送が行われる。また、本動作例3では、VoIP網と携帯電話網を接続するゲートウェイ(GW)が備えられる。このようなゲートウェイ自体は従来技術である。
端末1からBYEに対する応答を受信した後(図43のステップ3)、SIPサーバは、転送先テーブルを参照し、無線AP切替を失敗した端末1(URI1)に対応する転送先の端末番号(携帯電話端末の番号)を取得する(ステップ4)。そして、SIPサーバは、端末2に対し、端末1から携帯電話端末への接続替えを要求するSIPシーケンスを実行する(ステップ5〜ステップ8)。そして、携帯電話端末への接続処理が行われ(ステップ9〜16)、端末2と携帯電話端末間での通話が行われる(ステップ17)。なお、GWを介したVoIP端末と携帯電話端末との間の接続処理自体は従来技術である。
(装置構成について)
本実施の形態におけるアクセスコントローラは、無線APの電波干渉状態を示す電波干渉状態情報を当該無線APから取得する電波干渉状態情報取得手段と、当該電波干渉状態情報と予め定めた閾値とを比較することにより、前記無線APが電波干渉中であるか否かを判定するリソース状態判定手段と、前記リソース状態判定手段により、前記無線APが電波干渉中であると判定された場合に、当該無線APに接続された通話中の端末の無線リンク切断を行うための無線リンク切断要求を前記無線APに送信する無線リンク切断手段とを有している。より詳細には次のとおりである。
第3の実施の形態における装置の機能概要を図44を参照して説明する。第3の実施の形態における装置の基本的な構成は第1の実施の形態における装置構成と同様である。以下、第1の実施の形態の装置と異なる主な点について説明する。
SIPサーバ40における呼制御機能41は、無線AP切替失敗時の呼制御処理を実行する機能も有している。アクセスコントローラ30の電波干渉情報・端末電波状態情報収集機能36は、無線APの電波干渉状態と通信中端末の電波状態を定期的に無線APに問い合わせ、無線AP毎の電波干渉状態と端末の電波状態情報を収集する機能と、無線AP切替時に無線APの電波干渉状態の電波干渉状態と端末の電波状態の情報を収集する機能を有している。
また、アクセスコントローラ30は、第1の実施の形態で説明した機能に加えて、無線リンクリトライ判定機能45、AP接続替え成否判定機能46、及び端末制御機能39を有している。
無線リンクリトライ判定機能45は、無線リンクリトライの失敗回数をカウントし、予め設定した回数に達したかどうかの判定を行う。AP接続替え成否判定機能46は、無線AP切替処理時に無線AP切替が成功したかどうかの判定を行う。具体的には、無線リンクリトライ判定機能45により、無線リンクリトライの失敗回数が予め設定した回数に達したと判定された場合に、無線AP切替に失敗したと判定し、その旨をSIPサーバ40に通知する。なお、無線リンクリトライ判定機能45は第2の実施の形態のアクセスコントローラ30にも備えてもよい。また、端末制御機能39は、電波干渉状態、輻輳検出、端末の低電波状態検出時に、隣接する無線APへの切替を指示する機能、及び多数の無線APに繰り返して切替を行うことが無いように、切替回数をチェックする機能を有する。
図45に、本実施の形態での端末管理データを示す。本実施の形態では、呼状態として、「AP切替中」を含む。アクセスコントローラは、定期的情報収集において無線APにおける電波干渉状態を検出するか、もしくは端末の低電波状態を検出したことに応じて、該当端末の呼状態を「AP切替中」とする。そして、無線AP切替時において、切替先の無線APでの帯域が確保されたことに応じて、呼状態を「AP切替中」から「QoS確保済」にする。
また、本実施の形態における端末管理データは、端末毎の無線リンクリトライ回数(上限値)と、実際の無線リンクリトライ回数を含む。実際の無線リンクリトライ回数が上限値に達した場合に無線AP切替失敗と判定される。
また、本実施形態では、図19に示す無線AP管理データに加えて、図46に示す再接続要求拒否時間管理用の無線AP管理データを含む。図46に示すように、無線AP毎及び端末毎に、再接続要求拒否時間と、無線リンクを切断してから実際に経過した時間である再接続要求拒否経過時間が記録される。
図47に、本実施の形態におけるアクセスコントローラの詳細機能構成図を示す。以下、第1の実施の形態と異なる部分について説明する。
SIP要求返却部62は、AP切替失敗であることをSIPサーバに通知するAP切替失敗通知部69を有する。また、リソース予約/解放部71は、第1の実施の形態の機能に加え、端末のAP切替時に、無線APの電波干渉状態、輻輳状態、端末の電波状態を調べ、無線APが電波干渉状態、輻輳中、もしくは端末が低電波状態である場合に、端末の無線リンク切断を要求する機能を有している。また、リソース管理機能70は、ある端末の無線リンクリトライ回数が、予め定めた上限値に達したかどうかを判定する無線リンクリトライ判定部73を有している。更に、リソースの状態変化を監視するリソース状態変化監視部74を有している。
また、データ更新部81は、第1の実施の形態で説明した機能に加え、無線APが電波干渉状態、輻輳中、もしくは端末が低電波状態である場合に、端末の呼状態を「AP切替中」とする機能を備えている。
また、無線AP状態登録部92は、無線APの電波干渉情報を定期的、もしくは無線AP切替時に取得し、データ更新部に登録する機能を有し、端末電波状態登録部103は、端末の電波状態情報を定期的、またはAP切替時に取得し、データ更新部81に登録する機能を有している。
また、無線AP連携I/F110は、再接続要求通知部114を有している。再接続要求通知部114は、無線APが電波干渉状態、輻輳中、もしくは端末が低電波状態である場合に、端末を他の隣接無線APへ再接続させるために、無線APに無線リンク切断要求を送信するものである。
(無線APの電波干渉検出時の端末選択処理について)
さて、本実施の形態において、ある無線APに接続しているある端末が通話中の状態において、その端末が低電波状態であることを検出した場合には、その端末に対して無線リンク切断指示を送信し、その端末を別の無線APに接続させればよい。
一方、無線APが電波干渉状態にあることを検出した場合には、当該無線APに接続している通話中の端末全てに対して無線リンク切断指示を送信し、当該端末を別の無線APに接続させることとしてもよいし、特定の端末を選択して無線リンク切断指示を送信することとしてもよい。以下、電波干渉状態にある無線APに接続された通話中の端末のうち、最も低い電波状態である端末を選択し、その端末に対して無線APの接続替えを行わせる例について説明する。
本例におけるアクセスコントローラの処理については、図34に示した処理におけるステップ1〜ステップ3の処理が、図48に示すような処理になる。なお、無線リンク切断以降の処理は同じである。また、図48は、電波干渉状態に着目した場合の処理である。
無線APに通話中の端末が存在している状態において(ステップ1)、アクセスコントローラは、電波干渉情報取得を行う(ステップ2)。そして、ステップ3において、ある無線APで電波干渉状態が検出されると、アクセスコントローラは当該無線APに接続される通話中の端末の中で最も電波状態の悪い端末を選択し(ステップ4)、無線リンク切断を行う。 なお、ステップ4において、所定の閾値より電波状態が悪い端末の全てに対して無線リンク切断を行ってもよい。また、ステップ4における電波状態情報は、定期的に取得する電波状態情報を用いることとしてもよいし、ある無線APで電波干渉が検出された時点で、その無線AP配下の端末の電波状態情報を取得することとしてもよい。
次に、端末1、端末2、端末3が無線AP01を介して通信している状態で、無線AP01で電波干渉が検出され、電波状態が最も悪い端末2に無線AP02へのAP切替を行わせる動作例を図49を用いて説明する。
前述したとおり、アクセスコントローラは定期的に端末1〜3の電波状態を収集している(ステップ1〜6)。なお、前述したとおり、ある無線APで電波干渉が検出された時点で、当該無線AP配下の端末の電波状態情報を取得することとしてもよい。また、前述したとおり、1つの電波状態確認で、無線APに接続中の全端末の電波状態を取得することとしてもよいし、無線APで通話中の全端末の電波状態を取得することとしてもよい。
アクセスコントローラは、ステップ7、8で無線AP01の電波干渉状態情報を取得し、ステップ9にて無線AP01が電波干渉状態にあることを検出する。そして、アクセスコントローラは、無線AP切替を行わせる端末の選択を行う。ここでは、無線AP01に接続されている通話中の端末(QoS確保済の状態にある端末)のうち電波強度が最も低い端末2を無線AP切替を行わせる端末であると判定する。
そして、端末2に対する無線リンク切断要求を無線AP01に送信し(ステップ11)、無線AP01はMS02に対して一定時間再接続拒否設定を行い(ステップ12)、Deauthenticationを端末2に送る(ステップ13)。そして、端末2は無線AP02への接続を開始する。その後は、前述した処理と同様に接続処理が行われる。
図50に、本例における端末管理データの例を示す。図50に示すように、端末2に対する電波状態が最も悪く、端末2が無線AP切替対象の端末として選択されることになる。
<第4の実施の形態>
次に、本発明の第4の実施の形態について説明する。第4の実施の形態は、ハンドオーバ時に電波干渉等のチェックを行い、必要に応じて無線APの接続替えを行うものである。第1の実施の形態では、無線APにおける呼の帯域確保はSIPシーケンスを契機として行われるが、ハンドオーバ時には呼の開始/終了を伴わないため、SIPシーケンスは発生しない。そこで、第4の実施の形態では、無線リンク再接続要求(Reassociation)を契機として移動先無線APの帯域確保等を行っている。
図51は、本実施の形態の動作概要の一例を示す図である。最初に端末1が無線AP10に接続され、端末2と通話中であるものとする。ここで端末1が無線AP20にハンドオーバを行うと、アクセスコントローラは、第1の実施の形態と同様の電波干渉状態、端末1の電波状態、輻輳状態のチェックを行い、いずれも正常であれば無線AP20を介して端末1と端末2とが通話を行うことになる。
図51の例では、無線AP20は接続不可と判定され、無線リンクの切断処理が行われ、端末1は無線AP25への接続を行う。そして、アクセスコントローラは、無線AP25に対して無線AP20と同様のチェックを行う。このような処理が、予め定めた回数まで行われる。なお、この繰り返しの回数をリトライ回数と呼ぶ。図51に示す例では、無線AP25に端末1が接続することより端末2との呼接続が成功し、端末1と端末2間で通話が行われる。なお、予め定めた回数まで無線APの接続替えを行っても、所定の条件を満たさない場合は、呼切断処理等の呼処理が行われる。
次に、図52を参照して、アクセスコントローラ30における判定処理を説明する。まず、ある無線APを介して端末2と通話中の端末1がハンドオーバを行う(ステップ1)。アクセスコントローラは、ハンドオーバ先の無線APの電波干渉状態を示す情報を当該無線APから取得し(ステップ2)、それが予め定めた電波干渉閾値未満かどうかを調べ、電波干渉閾値未満であればステップ4の処理に進む(ステップ3)。ステップ3において無線APの電波干渉状態を示す情報が電波干渉閾値以上である場合は、無線APが電波干渉中であるため、当該無線APを介して端末1と端末2を接続すべきでないと判定し、リトライ回数が規定値未満であれば無線リンク切断を行う(ステップ8、9)。リトライ回数が規定値以上であれば、電波干渉中であることを示す情報を含むハンドオーバ失敗応答をSIPサーバ40に送信する(ステップ10)。
ステップ4において、アクセスコントローラ30は、端末1の電波強度をハンドオーバ先の無線APから取得し、それが予め定めた電波強度閾値より大きいかどうかを調べ、電波強度閾値より大きければステップ6の処理に進む(ステップ5)。端末1の電波強度が予め定めた電波強度閾値以下である場合は、端末1が低電波状態にあり、端末1と端末2を接続すべきでないと判定し、リトライ回数が規定値未満であれば無線リンク切断を行う(ステップ11、9)。リトライ回数が規定値以上であれば、低電波状態であることを示すハンドオーバ失敗応答をSIPサーバ40に送信する(ステップ11、12)。
ステップ6において、アクセスコントローラ30は、無線APが輻輳中であるかどうかを調べ、輻輳中であれば端末1と端末2を接続すべきでないと判定し、リトライ回数が規定値未満であれば無線リンク切断を行う(ステップ13、9)。リトライ回数が規定値以上であれば、輻輳中であることを示すハンドオーバ失敗応答をSIPサーバ40に送信する(ステップ13、14)。
全ての条件を満たした場合は、ステップ7においてハンドオーバが完了し、ハンドオーバ先の無線APを介して端末1と端末2間で音声通話が行われる。一方、ステップ10、12、14の後は、例えばSIPサーバ40がビジーを通知する。また、第1の実施の形態の例と同様に、携帯電話網への接続を行ってもよい。
以下、本実施の形態における処理の詳細を説明する。
まず、図53〜図54を参照して移動先の無線AP02が接続可能な場合について説明する。
図53において、まず、端末1と端末2の間で通信がなされているものとする(ステップ1)。ここで、端末1が無線AP01の配下から無線AP02の配下に移動する(ステップ2)。端末1は再接続要求(Reassociation)を無線AP02に送信し(ステップ3)、無線AP02は端末1のMACアドレス(MSID)を取得し、登録する(ステップ4)。無線AP02は無線AP02のID(AP02)と端末1のMACアドレス(MS01)とを含む端末登録リクエストをアクセスコントローラに対して送信する(ステップ5)。アクセスコントローラは無線AP02から受信した無線AP02のID(AP02)を端末1のMACアドレス(MS01)と対応付けて記憶装置に格納することにより登録の更新を行う(ステップ6)。なお、現時点での端末1に対する呼状態は"QoS確保済"である。そして、アクセスコントローラは無線AP02に対して端末登録レスポンスを返す(ステップ7)。
本実施の形態では、アクセスコントローラは、「QoS確保済」である端末に関する端末登録リクエストを受信した場合は、SIPサーバからのトリガーを受けることなく、ハンドオーバ前の無線AP01に対して、当該端末1に関するQoS解放リクエストを送信する(ステップ8、9)。このリクエストを受けた無線AP01は、端末1に対する帯域を解放し、QoS解放レスポンスをアクセスコントローラに送信する(ステップ10、11)。QoS解放レスポンスを受信したアクセスコントローラは、端末1の呼状態を"ハンドオーバ中"に変更する。
続いて、アクセスコントローラは、無線AP02が電波干渉状態でない(ステップ12〜14)ことを確認するとともに、端末1の電波状態が良好であることを確認する(図54のステップ15〜17)。続いて、アクセスコントローラは、MS01と必要帯域幅を含むQoS確保リクエストを無線AP02に送信する(ステップ18)。なお、端末1と端末2の間で必要な帯域幅は既に確定しているため、QoS予約シーケンスは実施しない。
ステップ19にて、無線AP02において端末1に対する帯域確保がなされ、QoS確保レスポンスがアクセスコントローラに送信される(ステップ20)。その後、無線AP02を介して端末1と端末2間での通話が行われる(ステップ21)。
次に、最初の移動先の無線AP02が電波干渉状態であるが、隣接無線AP03に接続することによりハンドオーバが成功する場合の動作例を図55〜図56を参照して説明する。
図55のステップ1〜ステップ11において、図53のステップ1〜ステップ11と同様にしてアクセスコントローラに無線AP02についての端末登録がなされ、無線AP01に対する帯域解放がなされる。
図55のステップ11で、QoS解放レスポンスを受信したアクセスコントローラは、端末1に対する呼状態を"ハンドオーバ中"にする。そして、アクセスコントローラは、無線AP02の電波干渉状態を調べ、無線AP02が電波干渉状態にあることを検出する(ステップ12〜14)。
アクセスコントローラは、無線APが接続不可であった回数をカウントする。つまり、図56のステップ15では、"1"をカウントする。この"1"は、1回リトライに失敗したことを示す。そして、この数値と予め定めた数値とを比較し、この数値が予め定めた数値に達していた場合は、後述する呼処理に移る。このような判定処理は、リトライが永久に続くことを防止するために行われる。図56の場合は、予め定めた数値は1より大きい数値であるものとし、1回目のリトライ失敗であるから、呼処理に移行せずに、再接続のための処理に移行する。
ステップ16にて、アクセスコントローラは、MS01と再接続要求拒否時間を含む無線リンク切断要求を無線AP02に送信する。無線AP02は、端末1に対する再接続要求拒否時間を設定する(ステップ17)。これにより、無線AP02は、端末1から再度接続要求を受けた場合でも、再接続要求拒否時間内であれば、その接続要求を拒否する。つまり、接続要求を受けてもその後の動作を行わない。
無線リンク切断要求を受信した無線AP02は、無線リンク切断指示(Deauthentication)を端末1に送信することにより無線リンクを切断する(ステップ18)。無線リンクを切断された端末1は、無線AP02に隣接する無線APである無線AP03に接続要求(Association)を送信する。なお、端末1の仕様によっては、再度数回無線AP02への接続を試み、接続に失敗した場合に隣接無線APへの接続を行う場合があるが、再接続要求拒否時間の間は、無線AP02から再度端末登録リクエストが送信されることはない。
無線AP03は端末1のMACアドレス(MSID)を取得し、登録する(ステップ20)。無線AP03は無線AP03のID(AP03)と端末1のMACアドレス(MS01)とを含む端末登録リクエストをアクセスコントローラに対して送信する(ステップ21)。アクセスコントローラは無線AP03から受信した無線AP03のID(AP03)を端末1のMACアドレス(MS01)と対応付けて記憶装置に格納することにより登録の更新を行う(ステップ22)。そして、アクセスコントローラは無線APに対して端末登録レスポンスを返す(ステップ23)。
続いて、電波干渉確認(ステップ24〜25)を行い、干渉がないと判定されると(ステップ26)、端末の電波状態確認(ステップ27、28)を行う。そして、電波状態が良好であると判定される(ステップ29)。本実施の形態では、アクセスコントローラは、「ハンドオーバ中」である端末に関する端末登録リクエストを受信した場合は、SIPサーバからのトリガーを受けることなく、端末登録リクエストを送信した無線AP03に対して、MS01と必要帯域幅を含むQoS確保リクエストを送信する(ステップ30)。
ステップ31にて、無線AP03において端末1に対する帯域確保がなされ、QoS確保レスポンスがアクセスコントローラに送信される(ステップ32)。アクセスコントローラは端末1に対する「呼状態」を"QoS確保済"とし、その後、無線AP03を介して端末1と端末2間での通話が行われる。
次に、図57〜図58を参照して、端末1がハンドオーバに失敗し、通話相手端末に対する呼制御が行われる場合の動作例1を説明する。
移動先の無線AP02が電波干渉中であり、図55、図56に示したステップ1〜ステップ25までの処理と同じ処理が行われたものとする(図57のステップ1〜図58のステップ25)。本動作例1では、無線AP03も電波干渉中であるので、ステップ26において、アクセスコントローラは無線AP03が電波干渉中であると判定する。
本動作例1では、リトライ回数の規定値が2と設定されているものとする。図58のステップ27において、アクセスコントローラはリトライ回数のカウント値を"2"とし、規定値と比較し、リトライ回数が規定値に達したと判定したため、呼状態管理テーブルの「呼状態」を"無し"に変更する。
そして、アクセスコントローラは、端末1のURIであるURI1と、ハンドオーバの失敗理由である"電波干渉中"を含むハンドオーバ失敗通知をSIPサーバに送信する(ステップ28)。本動作例1では、ハンドオーバ失敗通知を受信したSIPサーバは、BYEにより正常終了処理を行う(ステップ29〜ステップ32)。なお、アクセスコントローラでリトライを繰り返す方式の他、SIPでリトライを繰り返す方式としてもよい。
ハンドオーバ失敗通知を受領した後のSIPサーバの動作には種々のバリエーションがあり、種々のバリエーションのうちどの動作を用いるかは、SIPサーバに予め設定しておくことができる。
次に、ハンドオーバ失敗通知を受領した後のSIPサーバの動作例2を図59を参照して説明する。動作例2では、端末1がハンドオーバを実施したが、無線AP電波干渉中、端末低電波状態、無線AP輻輳中のうちのいずれかによりハンドオーバが失敗し、別内線のVoIP端末(本例では固定VoIP端末)へ転送が行われる。本動作例2では、第1の実施の形態における図16で示した場合と同様に、SIPサーバには端末毎にその端末に対応する転送先端末を記録した転送先テーブルが登録されているものとする。また、端末1の転送先である端末3(URI3)は有線でネットワーク接続された固定VoIP端末であるものとする。
端末1からBYEに対する応答を受信した後(図59のステップ3)、SIPサーバは、転送先テーブルを参照し、ハンドオーバを失敗した端末1(URI1)に対応する転送先URI3(端末番号)を取得する(ステップ4)。そして、SIPサーバは、端末2に対して端末3への接続換えを要求するSIPシーケンスを実行し(ステップ5〜ステップ8)、着信先のURI3を指定したQoS予約リクエストをアクセスコントローラに送信する(ステップ9)。端末3は固定VoIP端末であり、アクセスコントローラの管轄外であるため、アクセスコントローラはQoS予約を行わず、何も行わずにNoMatchをSIPサーバに返す(ステップ10)。その後、SIPサーバは転送のための呼接続処理を行い(図59のステップ11〜ステップ15)、端末3と端末2間での音声通信が行われる(ステップ16)。
次に、ハンドオーバ失敗通知を受領した後のSIPサーバの動作例3を図60を参照して説明する。動作例3では、端末1がハンドオーバを実施したが、無線AP電波干渉中、端末低電波状態、無線AP輻輳中のうちのいずれかによりハンドオーバが失敗し、外線の端末(本例では携帯電話端末)へ転送が行われる。また、本動作例3では、VoIP網と携帯電話網を接続するゲートウェイ(GW)が備えられる。このようなゲートウェイ自体は従来技術である。
端末1からBYEに対する応答を受信した後(図60のステップ3)、SIPサーバは、転送先テーブルを参照し、ハンドオーバを失敗した端末1(URI1)に対応する転送先の端末番号(携帯電話端末の番号)を取得する(ステップ4)。そして、SIPサーバは、端末2に対し、端末1から携帯電話端末への接続替えを要求するSIPシーケンスを実行する(ステップ5〜ステップ8)。そして、携帯電話端末への接続処理が行われ(ステップ9〜16)、端末2と携帯電話端末間での通話が行われる(ステップ17)。なお、GWを介したVoIP端末と携帯電話端末との間の接続処理自体は従来技術である。
(装置構成について)
本実施の形態のアクセスコントローラは、他の端末と通話中の状態にある端末が、接続中の無線APの配下から、他の無線APである移動先無線APの配下に移動し、当該端末が当該移動先無線APに接続したことに応じて、当該移動先無線APの電波干渉状態を示す電波干渉状態情報を取得し、当該電波干渉状態情報と予め定めた閾値とを比較することにより、前記移動先無線APが電波干渉中であるか否かを判定する手段を有するリソース状態判定手段と、前記リソース状態判定手段による判定結果に異常がない場合に、前記移動先無線APにおける帯域を確保し、前記端末と前記他の端末との通信を継続する手段とを有する。より詳細には次のとおりである。
第4の実施の形態における装置の機能概要を図61を参照して説明する。第4の実施の形態における装置の基本的な構成は第1の実施の形態における装置構成と同様である。以下、第1の実施の形態の装置と異なる主な点について説明する。
SIPサーバ40における呼制御機能41は、ハンドオーバ失敗時の呼制御処理を実行する機能も有している。アクセスコントローラ30は、第1の実施の形態で説明した機能に加えて、無線リンクリトライ判定機能45、ハンドオーバ成否判定機能47、及び端末制御機能39を有している。
無線リンクリトライ判定機能45は、無線リンクリトライの失敗回数をカウントし、予め設定した回数に達したかどうかの判定を行う。ハンドオーバ成否判定機能47は、端末のハンドオーバ時にハンドオーバが成功したかどうかの判定を行う。具体的には、無線リンクリトライ判定機能45により、無線リンクリトライの失敗回数が予め設定した回数に達したと判定された場合に、ハンドオーバに失敗したと判定し、その旨をSIPサーバ40に通知する。また、端末制御機能39は、電波干渉状態、輻輳検出、端末の低電波状態検出時に、隣接する無線APへの移動を指示する機能、及び多数の無線APに繰り返して移動を行うことが無いように、移動回数をチェックする機能を有する。
図62に、本実施の形態での端末管理データを示す。本実施の形態では、呼状態として、「ハンドオーバ中」を含む。アクセスコントローラは、ハンドオーバ時において、ハンドオーバ前の無線APにおける帯域が解放されたことに応じて呼状態を「ハンドオーバ中」とする。そして、ハンドオーバ時において、ハンドオーバ先の無線APでの帯域が確保されたことに応じて、呼状態を「ハンドオーバ中」から「QoS確保済」にする。
また、本実施の形態における端末管理データは、端末毎の無線リンクリトライ回数(上限値)と、実際の無線リンクリトライ回数を含む。実際の無線リンクリトライ回数が上限値に達した場合にハンドオーバ失敗と判定される。
また、本実施形態では、図19に示す無線AP管理データに加えて、図63に示す再接続要求拒否時間管理用の無線AP管理データを含む。図63に示すように、無線AP毎及び端末毎に、再接続要求拒否時間と、無線リンクを切断してから実際に経過した時間である再接続要求拒否経過時間が記録される。
図64に、本実施の形態におけるアクセスコントローラの詳細機能構成図を示す。以下、第1の実施の形態と異なる部分について説明する。
SIP要求返却部62は、ハンドオーバ失敗であることをSIPサーバに通知するハンドオーバ失敗通知部68を有する。また、リソース予約/解放部71は、第1の実施の形態の機能に加え、端末のハンドオーバ時に、無線APの電波干渉状態、輻輳状態、端末の電波状態を調べ、無線APが電波干渉状態、輻輳中、もしくは端末が低電波状態である場合に、端末の無線リンク切断を要求する機能を有している。また、リソース管理機能70は、ある端末の無線リンクリトライ回数が、予め定めた上限値に達したかどうかを判定する無線リンクリトライ判定部73を有している。また、リソース状態変化監視部74を有している。
また、データ更新部81は、第1の実施の形態で説明した機能に加え、無線APが電波干渉状態、輻輳中、もしくは端末が低電波状態である場合に、端末の呼状態を「ハンドオーバ中」とする機能を備えている。
また、無線AP連携I/F110は、再接続要求通知部114を有している。再接続要求通知部114は、無線APが電波干渉状態、輻輳中、もしくは端末が低電波状態である場合に、端末を他の隣接無線APへ再接続させるために、無線APに無線リンク切断要求を送信するものである。
なお、各実施の形態において上述した機能構成は一例に過ぎない。本実施の形態で説明した動作を実現できる構成であればどのような構成でもよい。
本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内において、種々変更・応用が可能である。