JP4820583B2 - 呼制御方法、呼制御プログラムおよびｒｔｃクライアント - Google Patents

Description

本発明は、リアルタイムコミュニケーション（ＲＴＣ）を実現する呼制御方法、呼制御プログラムおよびＲＴＣクライアントに関する。

リアルタイムコミュニケーションは、無線ＬＡＮにおける音声通信（ＶｏＩＰ：Ｖｏｉｃｅ ｏｖｅｒ ＩＰ）に代表される。たとえば、無線ＬＡＮ環境において、１つのアクセスポイント（ＡＰ）に、ＶｏＩＰ端末に代表される多数のＲＴＣクライアントが接続される。ＡＰには、さらに、データ通信クライアント、つまり、リアルタイム通信によって接続していない静止画の画像データやテキストデータを送受信するクライアントが混在する場合には、無線ＬＡＮ上のトラフィック量に応じて、ＲＴＣの通信品質（たとえば音声通話品質）が低下する。ウェブやメールにアクセスしているデータ通信クライアントは、大きなパケット遅延やその揺らぎ、パケットロスに伴う通信品質の悪化による影響を受けにくい。しかしながら、ＲＴＣクライアントにおいては、アプリケーションの通信品質、たとえば、音声通話品質に直接かかわるため、非常に大きな影響をうけやすい。

これを回避するためには、ＳＩＰサーバなど呼制御装置において、全体のＲＴＣクライアントの登録数や呼量を制限する方法が考えられる。しかしながら、このような方法では、全体としての呼量は多くないが、特定のＡＰに呼が集中している場合などに対応することができないという問題点があった。
特開平４−３７３３２５号公報 特開平１１−２２０４７７号公報

また、特許文献１には、通信トラフィックに応じて発呼および位置登録を制御する移動通信システムにおいて、トラフィック特性に適応した最適な規制を行う技術が開示されている。特許文献１においては、移動端末が、基地局（ＡＰに相当する）からの発呼規制および位置登録規制信号をモニタし、乱数発生により一定の割合で、端末自らが発呼や登録要求を取りやめるように構成され、基地局からの規制信号で送信される規制値を、トラヒックに応じて動的に変更している。

しかしながら、この手法を、たとえば、無線ＬＡＮ環境におけるＲＴＣクライアントに適用するために、規制信号を送受信するための機構をＡＰに組み込む必要がある。ネットワーク上に数多く存在するＡＰの構成を改変することは容易ではなく、コスト的にも望ましくない。或いは、呼制御装置が、規制信号を発する構成を考えると、全体のトラフィックをモニタすることは可能であっても、それぞれのＡＰの状態を考慮して、個別に規制信号を出すことはできないという問題点がある。

また、特許文献２には、ＬＡＮ構内交換ネットワークシステムにおいて、トラフィック量の増大時に効果的に発呼規制することにより、通話品質を維持する技術が開示されている。この技術においては、ＬＡＮ構内交換機においてトラフィック量を測定し、発呼制限が必要と判断された場合には、ＬＡＮ基地局やＬＡＮ電話機に対して、「発呼規制メッセージ」を一斉同報する。これにより、それ以降の発呼規制を、基地局ごとに分散制御可能としている。

この手法においても、ＬＡＮ構内交換ネットワークのトラフィック量の測定結果に基づいている。このため、これを無線ＬＡＮ環境に適用すると、全体のトラフィック量は少ないが、特定の基地局下のトラフィック量が集中し、当該基地局下のＲＴＣクライアントのＱｏＳが低下しているときには、適切に対応することができないという問題点があった。

本発明は、それぞれのＡＰの状態を考慮して、個別に適切に登録や接続を規制することができる呼制御方法、呼制御プログラムおよびＲＴＣクライアントを提供することを目的とする。

本発明の目的は、リアルタイム通信するリアルタイム通信クライアント（ＲＴＣクライアント）と、当該ＲＴＣクライアントと接続される末端中継装置と、を含むネットワーク環境において、前記ＲＴＣクライアントの呼を制御する呼制御方法であって、
前記ＲＴＣクライアントにおいて、自己のＱｏＳに関する情報に基づき、前記リアルタイム通信の品質を表すＱｏＳ値が所定の閾値より悪化した場合に、アラームを示す情報を、前記ネットワークおよび前記末端中継装置を介して、呼制御装置に送信するステップと、
前記呼制御装置において、前記ネットワークを介して、前記ＲＴＣクライアントを特定する情報および当該ＲＴＣクライアントの属する末端中継装置の情報を含む第１のパラメータ群を受信するステップと、
前記ＲＴＣクライアントから、前記アラームを示す情報を受信するステップと、
前記アラームを示す情報にしたがって、前記ＲＴＣクライアントが属する末端中継装置ごとのＱｏＳに関する情報を記憶した状態情報テーブルを更新するステップと、
前記ＲＴＣクライアントによる登録要求、或いは、接続要求を受信したときに、前記第１のパラメータ群に基づき、ＲＴＣクライアントおよび当該ＲＴＣクライアントが属する末端中継装置を特定し、かつ、前記状態情報テーブルを参照して、前記ＲＴＣクライアントが属する末端中継装置のＱｏＳに関する情報を参照して、登録の可否或いは接続の可否を判断するステップと、を備えたことを特徴とする呼制御方法により達成される。

制御装置は、ＲＴＣクライアントから登録要求や接続要求があったときに、当該ＲＴＣクライアントが属する末端制御装置の状態、特に、前記アラームに基づくＱｏＳに関する情報に基づき、登録の可否や接続の可否を判断する。したがって、よりの粒度の高いＲＴＣの品質制御が可能となる。また、ＲＴＣクライアントと非ＲＴＣクライアントが混在している場合にも、ＲＴＣクライアントのＱｏＳに関する情報に基づいて、登録や接続の可否を判断するため、実際のＲＴＣクライアントによるトラフィック状況に応じた登録・接続制限を実現できる。

さらに、本発明においては、ＲＴＣクライアントにおいて、ＱｏＳの悪化というイベントが生じた際に、呼制御装置に、アラームを通知する。したがって、ＲＴＣクライアントと呼制御装置との間のトラヒックの増大を抑制しつつ、上述した登録・接続制限を実現することができる。

なお、末端中継装置には、無線ＬＡＮ環境におけるアクセスポイント（ＡＰ）や、エッジルータが含まれる。

好ましい実施態様においては、前記ＲＴＣクライアントにおいて、ケット遅延時間の揺らぎであるジッタ値、パケットロス数および／または往復遅延時間に基づくＱｏＳ値を算出するステップを備える。

また、好ましい実施態様においては、前記状態情報テーブルが、ＱｏＳに関する情報の項目として、前記末端中継装置ごとの、前記ＲＴＣクライアントから通知されたアラームの合計数を含み、
前記登録の可否を判断するステップが、前記状態情報テーブル中、該当する末端中継装置に関する前記アラームの合計数を参照して、登録の可否を判断するステップを含む。

より好ましい実施態様においては、前記状態情報テーブルが、項目として、前記末端中継装置ごとの、ＲＴＣクライアントの接続数を含み、
前記登録の可否を判断するステップが、前記状態情報テーブル中、前記ＲＴＣクライアントが属する末端中継装置に関する接続数に対するアラームの合計数の割合を参照して、登録の可否を判断するステップを含む。

また、別の好ましい実施態様においては、前記状態情報テーブルが、ＱｏＳに関する情報の項目として、前記末端中継装置ごとの、前記ＲＴＣクライアントから通知されたアラームの合計数を含み、
前記接続の可否を判断するステップが、前記状態情報テーブル中、該当する末端中継装置に関する前記アラームの合計数を参照して、接続の可否を判断するステップを含む。

より好ましい実施態様においては、前記状態情報テーブルが、項目として、前記末端中継装置ごとの、ＲＴＣクライアントの接続数を含み、
前記接続の可否を判断するステップが、前記状態情報テーブル中、前記ＲＴＣクライアントが属する末端中継装置に関する接続数に対するアラームの合計数の割合を参照して、接続の可否を判断するステップを含む。

さらに別の好ましい実施態様においては、前記状態情報テーブルが、項目として、前記末端中継装置ごとの、ＲＴＣクライアントの登録数を含み、
前記登録の可否を判断するステップが、前記状態情報テーブル中、前記ＲＴＣクライアントが属する末端中継装置に関する登録数を参照して、当該登録の可否を判断するステップを含み、かつ、
前記登録の可否の判断の結果、登録が可能である場合に、前記状態情報テーブル中、前記ＲＴＣクライアントが属する末端中継装置に関する登録数を更新するステップを備える。

さらに別の好ましい実施態様においては、前記状態情報テーブルが、項目として、前記末端中継装置ごとの、ＲＴＣクライアントの接続数を含み、
前記接続の可否を判断するステップが、前記状態情報テーブル中、前記ＲＴＣクライアントが属する末端中継装置に関する接続数を参照して、当該接続の可否を判断するステップを含み、かつ、
前記接続の可否の判断の結果、接続が可能である場合に、前記状態情報テーブル中、前記ＲＴＣクライアントが属する末端中継装置に関する接続数を更新するステップを備える。

好ましい実施態様においては、前記登録の可否或いは接続の可否を判断するステップが、参照された項目と、当該項目のそれぞれの閾値を格納した接続制限情報テーブル中の閾値とを比較するステップを含む。

また、より好ましい実施態様においては、さらに、前記ＲＴＣクライアントにおいて、前記ＱｏＳ値が、前記所定の閾値よりも良好となった場合に、前記アラーム解除を示す情報を、前記ネットワークおよび前記末端中継装置を介して、前記呼制御装置に送信するステップと、
前記呼制御装置において、前記ＲＴＣクライアントから、前記アラーム解除を示す情報を受信するステップと、
前記アラーム解除を示す情報にしたがって、前記ＲＴＣクライアントが属する末端中継装置ごとのＱｏＳに関する情報を記憶した状態情報テーブルを更新するステップと、を備える。

また、本発明の目的は、リアルタイム通信するリアルタイム通信クライアント（ＲＴＣクライアント）と、当該ＲＴＣクライアントと接続される末端中継装置と、当該ＲＴＣクライアントの呼を制御する呼制御装置と、を含むネットワーク環境において、前記ＲＴＣクライアントの呼を制御するために、当該ＲＴＣクライアントにより読み出し可能な呼制御プログラムであって、
前記ＲＴＣクライアントに、
自己のＱｏＳに関する情報を取得して、前記リアルタイム通信の品質を表すＱｏＳ値を算出するステップと、
算出されたＱｏＳ値が所定の閾値より悪化した場合に、前記呼制御装置において、前記ＲＴＣクライアントが属する末端中継装置における登録要求或いは接続要求に基づく、他のＲＴＣクライアントの登録或いは接続の制限のために、アラームを示す情報を生成して、前記ネットワークおよび前記末端中継装置を介して、呼制御装置に送信するステップと、を実行させることを特徴とする呼制御プログラムによっても達成される。

好ましい実施態様においては、前記ＱｏＳ値を算出するステップにおいて、前記ＲＴＣクライアントに、
パケット遅延時間の揺らぎであるジッタ値、パケットロス数および／または往復遅延時間に基づくＱｏＳ値を算出するステップを実行させる。

また、別の好ましい実施態様においては、さらに、前記ＲＴＣクライアントに、
前記ＱｏＳ値が、前記所定の閾値よりも良好となった場合に、前記アラーム解除を示す情報を、前記ネットワークおよび前記末端中継装置を介して、前記呼制御装置に送信するステップを実行させる。

さらに、本発明の目的は、リアルタイム通信するリアルタイム通信クライアント（ＲＴＣクライアント）と、当該ＲＴＣクライアントと接続される末端中継装置と、当該ＲＴＣクライアントの呼を制御する呼制御装置と、を含むネットワーク環境において、
自己のＱｏＳに関する情報を取得して、前記リアルタイム通信の品質を表すＱｏＳ値を算出するＱｏＳ値算出手段と、
前記ＱｏＳ算出されたＱｏＳ値が所定の閾値より悪化した場合に、前記呼制御装置において、前記ＲＴＣクライアントが属する末端中継装置における登録要求或いは接続要求に基づく、他のＲＴＣクライアントの登録或いは接続の制限のために、アラームを示す情報を生成して、前記ネットワークおよび前記末端中継装置を介して、呼制御装置に送信するアラーム生成・送信手段と、を備えたことを特徴とするＲＴＣクライアントによっても達成される。

好ましい実施態様においては、前記ＱｏＳ値算出手段が、パケット遅延時間の揺らぎであるジッタ値、パケットロス数および／または往復遅延時間に基づくＱｏＳ値を算出するように構成されている。

別の好ましい実施態様においては、さらに、前記ＱｏＳ値が、前記所定の閾値よりも良好となった場合に、前記アラーム解除を示す情報を、前記ネットワークおよび前記末端中継装置を介して、前記呼制御装置に送信するアラーム解除手段を備えている。

本発明によれば、それぞれのＡＰの状態を考慮して、個別に適切に登録や接続を規制することができる呼制御方法、呼制御プログラムおよびＲＴＣクライアントを提供することが可能となる。

以下、添付図面を参照して、本発明の実施の形態について説明する。図１は、本発明の実施の形態にかかる無線ＬＡＮ通信環境の全体を示すブロックダイヤグラムである。図１に示すように、呼制御装置１２がネットワーク１１に接続される。ネットワークには、たとえば、ルータ１５が設けられる。また、複数のアクセスポイント（ＡＰ）１４−１、１４−２、１４−３、・・・もネットワーク１１に接続される。なお、明細書において、特定のＡＰを指す場合を除いて、ＡＰ１４と表記する。ネットワーク上には、適宜ルータ１５が配置されている。

ＡＰ１４には、複数のクライアントが無線ＬＡＮにて接続され得る。ここに、たとえば、ＶｏＩＰによる音声通信などを実行する端末をＲＴＣクライアント、それ以外の端末を非ＲＴＣクライアントと称する。本実施の形態においては、ＲＴＣクライアントは、音声通信するものとしているがこれに限定されない。また、たとえば、ウェブによるデータ通信やメール送受信を実行するクライアントが、非ＲＴＣクライアントに相当する。図１の例においては、たとえば、ＡＰ１（符号１４−１）には、ＲＴＣクライアント１６−１、１６−２、および、非ＲＴＣクライアント１７−１が接続されている。以下、特定のＲＴＣクライアント、非ＲＴＣクライアントを指すときを除き、ＲＴＣクライアント１６、非ＲＴＣクライアント１７と称する。

ＲＴＣは、主としてＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）を利用する即時性の高いデータ通信であり、ネットワークトラフィックの変動によるパケットの遅延、遅延揺らぎ、ロスなどの影響を大きく受け、その結果、ユーザへの品質（たとえば音声通話品質）に影響を及ぼす。その一方、ウェブによるデータ通信やメールによるデータ送受信を実行する非ＲＴＣクライアントにおいては、主としてＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）を用いるため、トラフィック負荷による影響は、単にユーザへのレスポンスタイム変動として現れる。

呼制御装置１２は、主として、ＲＴＣクライアントの認証、ＩＰアドレスに基づく位置管理や呼制御を実行する。なお、呼制御装置１２は、物理的に単独の装置である必要は無く、ネットワークを介してデータ送受信することにより上記機能を実現しても良い。位置登録／管理や呼制御に関する手順は、ＶｏＩＰで利用されるＳＩＰ(Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ：ＲＦＣ３２６１)やＨ．３２３を代表として標準化されている。

図１に示すように、ＲＴＣクライアント１６および非ＲＴＣクライアント１７は、そのほとんどが、これらを管轄するＡＰ１４の管轄下において混在した状態で、ネットワーク１１に接続されている。ＲＴＣクライアント１６は、自己のＩＰアドレスとＩＤ（たとえば電話番号）を、呼制御装置１２に通知し、現在のロケーション（ＩＰアドレス）を登録することで着信可能となる。この登録処理は定期的に行われ、呼制御装置１２に蓄積された登録情報はリフレッシュされるが、一定時間を経過したにもかかわらずＲＴＣクライアント１６からの再登録が行われない場合には、呼制御装置１２は、登録情報を消去する。

また、ＲＴＣクライアント１６は、ＡＰ１４間を移動可能であり、ルータを越えて異なるサブネットのＡＰに接続した場合（たとえば、ＡＰ−２の管轄する領域１８−２から、ＡＰ−３の管轄する領域１８−３に移動した場合）には、呼制御装置１２に対して、新たに取得したＩＰアドレスを用いて再登録することで、シームレスな着信が可能となっている。

図２は、呼制御装置の構成を示すブロックダイヤグラムである。図２に示すように、呼制御装置１２は、ＱｏＳ情報受信処理部２０、登録処理部２２、ＡＰ状態情報処理部２４、呼制御処理部２６、および、データベース（ＤＢ）２８を有している。ＤＢ２８には、ＡＰ状態情報テーブル３０と、接続制限情報テーブル３２とを含む。また、図３は、ＲＴＣクライアントの構成を示すブロックダイヤグラムである。図３に示すように、ＲＴＣクライアント１６は、ＱｏＳ情報送信処理部４０、登録・呼制御処理部４２、メディア転送部４４、ＱｏＳ判断部４６、および、ハードウェア（Ｈ／Ｗ）ドライバ４８を有する。呼制御装置１２のＱｏＳ情報受信処理部２０と、ＲＴＣクライアント１６のＱｏＳ情報送信処理部４０とが、ネットワークを介してデータを授受する。また、呼制御装置１２の呼制御処理部２６と、ＲＴＣクライアント１６の登録・呼制御処理部４２とが、ネットワークを介してデータを授受する。

ＱｏＳ情報送信処理部４０は、呼制御装置１２のＱｏＳ情報送信処理部２０に対して、現在接続中のＲＴＣに関するＱｏＳ情報（）に基づくアラームおよびアラーム解除要請を送信する。なお、呼制御装置１２のＩＰアドレスは、ＲＴＣに予め設定されているので、新たにそのアドレスを取得する手段を考慮する必要は無い。

ＱｏＳ判断部４６にて実行される処理は後に詳述するが、ＲＴＣクライアント１６自身の受信パケット遅延時間の揺らぎ（パケット到着間隔の揺らぎ：ジッタ値）、パケットロス数、往復遅延時間（ＲＴＴ）などに基づくＱｏＳ値にしたがって、呼制御装置１２に対してアラームを通知すべきか否か、或いは、アラーム解除すべきか否か判断する。

登録・呼制御処理部４２は、主として、登録処理、発呼や着呼のシグナリング処理を実行する。登録処理においては、現在接続中（Ａｓｓｏｃｉａｔｅｄ）のＡＰを特定可能なＩＤ、たとえば、ＢＳＳＩＤ（Basic Service Set identifier）を取得し、登録メッセージの中に含めて送信することができる。したがって、登録処理においては、以下の登録情報（第１のパラメータ群）が送信される。

（クライアントＩＤ、ＡＰ＿ＩＤ）
なお、クライアントＩＤは、ＲＴＣクライアント１６を一意的に特定する値、ＡＰ＿ＩＤは、上記ＢＳＳＩＤに相当する。図５は、ＲＴＣクライアントの登録・呼制御処理部４２が送信するメッセージの例を示す図である。図５に示すように、メッセージ中に「Ｃａｌｌ−Ｉｎｆｏ」として、ＡＰのＢＳＳＩＤが含まれている。

また、シグナリング処理は、現在のＶｏＩＰで主として用いられるＳＩＰ（ＲＦＣ３２６１）やＨ．３２３などの手順に従うことで実装され得る。

メディア転送部４４は、メディアストリームを送受信し、メディアごとのＣＯＤＥＣ処理やパケット送受信処理を実行する。また、メディア転送部４４は、本実施の形態においては、メディア転送部４４は、受信パケットのジッタ値、パケットロス数、および、往復遅延時間（ＲＴＴ値）に基づいて、換算Ｒ値を算出する。算出されたＲ値が、後述するＱｏＳ判断部４６における処理に用いられる。無論、ＱｏＳ値として他の値、たとえば、換算ＭＯＳ（Ｍｅａｎ
Ｏｐｉｎｉｏｎ Ｓｃｏｒｅ）値を利用しても良い。

Ｈ／Ｗドライバ４８は、たとえば、無線ＬＡＮカードドライバであり、ＡＰとの間の電波の電界強度を計測することができる。

呼制御装置１２のＱｏＳ情報受信処理部２０は、ＲＴＣクライアント１６のＱｏＳ情報送信処理部４０からの情報を受信する。ＱｏＳ情報送信処理部４０からの情報には、クライアントＩＤと、アラーム或いはアラーム解除指示が含まれる。したがって、ＱｏＳ情報受信処理部２０は、ＡＰ状態情報処理部２４に、以下のデータの組を通知する。なお、このデータの組を、「アラーム情報」とも称する。

（クライアントＩＤ、アラーム或いはアラーム解除指示）
登録処理部２２は、ＲＴＣクライアント１６の登録処理および登録解除処理を実行する。登録処理部２２は、ＡＰ状態情報テーブル３０を作成、更新するとともに、呼制御処理部２６と協働して、ＡＰ状態情報テーブル３０および接続制限情報テーブル３２を参照して、ＲＴＣクライアント１６の登録の可否を判断する。

図４（ａ）は、ＡＰ状態情報テーブルのデータ構成を示す図である。図４（ａ）に示すように、ＡＰ状態情報テーブル（図４（ａ）の符号４００）のレコード（たとえば、符号４０１、４０２）は、項目として、ＡＰ＿ＩＤ（ａｐ＿ｉｄ）ＲＴＣ登録数（ｃｖ＿ｒ）、ＲＴＣ接続数（ｃｖ＿ｃ）、アラーム数（ｃｖ＿ａｌａｒｍ）、および、登録ＲＴＣリスト（ｃｖ＿ｌｉｓｔ）を含む。ＡＰ＿ＩＤは、アクセスポイントのＩＤを示す。本実施の形態においては、アクセスポイントごとに、ＡＰ状態情報テーブルのレコードが設けられる。

ＲＴＣ登録数は、現在、ＡＰ＿ＩＤで特定されるＡＰにおいて登録されているＲＴＣクライアントの数を示す。ＲＴＣ接続数は、現在、リアルタイム通信中のＲＴＣクライアントの数を示す。アラーム数（ｃｖ＿ａｌａｒｍ）は、通信中のＲＴＣクライアントから送信されたアラームのカウント数に相当する。

また、登録ＲＴＣリストには、ＡＰ＿ＩＤで特定されるＡＰにおいて登録されているＲＴＣクライアントのクライアントＩＤが含まれる。

図４（ｂ）は、接続制限情報テーブルのデータ構成を示す図である。図４（ｂ）に示すように、接続制限情報テーブル（図４（ｂ）の符号４１０）のレコード（たとえば、符号４１１、４１２）は、項目として、ＡＰ＿ＩＤ（ａｐ＿ｉｄ）、ＲＴＣ登録数制限値（ｓｖ＿ｒ）、ＲＴＣ接続数制限値（ｓｖ＿ｃ）、アラーム数割合制限値（ｓｖ＿ａｌａｒｍ）を含む。ＲＴＣ登録数制限値、ＲＴＣ接続数制限値は、それぞれ、ＡＰ＿ＩＤで特定されるＡＰにおける、ＲＴＣクライアントの登録数、接続数の上限を表わす。また、アラーム数割合制限値は、ＲＴＣ接続数（ｃｖ＿ｃ）に対するアラーム数（ｃｖ＿ａｌａｒｍ）の割合の上限を表す。

接続制限情報テーブル３２のレコード（符合４１０参照）は、予め、ＡＰごと個別に、又は、複数のＡＰに一律に、それぞれの項目の値を決定しておき、ＤＢ２８に格納される。また、ＡＰ状態情報テーブル３０は、ＡＰ状態情報処理部２４が、アラーム情報（クライアントＩＤ、アラーム或いはアラーム解除指示）を受信することに応答して、ＡＰ状態情報処理部２４により更新される。

呼制御処理部２６は、ＲＴＣクライアント１６からの呼に関する要求を処理する。ＲＴＣクライアント１６からの登録メッセージや登録解除メッセージを受信すると、これを登録処理部２２に渡す。呼制御処理部２６は、登録処理部２２と協働して、発呼側および着呼側のＲＴＣクライアントが属するＡＰの状態を、ＡＰ状態情報テーブル３０および接続制限情報テーブル３２を参照して判断し、接続可能である場合には、発呼側のＲＴＣクライアントと着呼側のＲＴＣクライアントとの接続を認める。この処理については、後に詳述する。また、呼制御処理部２６は、ＳＩＰ／Ｈ３２３など、他の標準的な処理を実行する。登録処理部２２も、ＳＩＰ／Ｈ３２３など、他の標準的な処理を実行することができる。

このように構成されたＲＴＣクライアント１６および呼制御装置１２にて実行される処理について説明する。図６は、本実施の形態にかかるＲＴＣクライアントにおいて実行されるアラーム通知処理を示すフローチャートである。なお、このアラーム通知処理は、後述するＲＴＣクライアント１６からの要求にしたがって、呼制御装置１２において、当該ＲＴＣクライアント１６の登録処理が終了し（図７参照）、かつ、呼制御装置１２において、当該ＲＴＣクライアントからの発呼要求が受け入れられ（図１１参照）、当該ＲＴＣクライアントが他のＲＴＣクライアントとの間でリアルタイム通信が実行されている際に有効となる（図６のステップ６０２参照）。

図６に示すように、ＲＴＣクライアント１６のＱｏＳ判断部４６は、ＲＴＣクライアント１６が、リアルタイム通信を実行しているか否かを判断する（ステップ６０２）。ステップ６０２でイエス(Yes)と判断された場合には、ＱｏＳ判断部４６は、Ｈ／Ｗドライバ４８から、現在接続中のＡＰからの電波の、測定された電界強度を取得して（ステップ６０３）、電界強度が所定の第１の閾値を越えているか否かを判断する（ステップ６０４）。このステップは、ＲＴＣクライアント１６において、リアルタイム通信の品質が一定のレベルを下回る要因が、電界強度の弱さに起因する場合を除外するために実行される。

ステップ６０４でイエス(Yes)と判断された場合には、ＱｏＳ判断部４６は、メディア転送部４４から、メディア受信状態を示す情報として、ＱｏＳ値を取得する（ステップ６０５）。ＱｏＳ判断部４６は、ＱｏＳ値が、所定の第２の閾値より小さいか否かを判断する（ステップ６０６）。ステップ６０６でイエス(Yes)と判断した場合には、ＱｏＳ判断部４６は、ＱｏＳ情報送信処理部４０に対して、アラーム送信を指示する。ＱｏＳ情報送信処理部４０は、指示に応答して、アラームを送信する（ステップ６０７）。これにより、アラーム情報（クライアントＩＤ、アラーム）を含むパケットが、ＡＰを介して、呼制御装置１２に伝達される。送信後、ＱｏＳ判断部４６は、アラーム送信を示すアラーム送信フラグを、メモリ（図示せず）の何れかの領域にセットしておく（ステップ６０８）。

上記アラーム情報（クライアントＩＤ、アラーム）を受信した呼制御装置１２は、AP状態情報テーブルの登録RTCリストフィールドを参照し、ＲＴＣクライアント１６のクライアントＩＤに基づき、当該ＲＴＣクライアント１６が属するＡＰを特定し、ＡＰ状態情報テーブル３０の当該ＡＰに関するレコード中、アラーム数（ｃｖ＿ａｌａｒｍ）を「＋１」する。このアラームの受信に応答して実行される呼制御装置１２の処理については後述する。

次に、本実施の形態において、呼制御装置１２にて実行される処理について以下に詳細に説明する。図７は、本実施の形態にかかる呼制御装置１２で実行される登録処理を示すフローチャートである。図７に示すように、呼制御装置１２の呼制御処理部２６は、初期的には待機状態にある（ステップ７００）。

呼制御処理部２６が、ＲＴＣクライアント１６からのメッセージを受信すると（ステップ７０１）、受信したことを示す通知を受けた登録処理部２２は、当該メッセージが登録要求であるか、登録解除であるかを判断する。登録解除の必要が無い場合（ステップ７０２でノー(No)）、つまり、登録要求である場合には、登録処理部２２は、受信したメッセージに含まれる第１のパラメータ群および登録位置情報テーブルを参照して、ＲＴＣクライアント１６が接続中であるかどうかを判断する（ステップ７０３）。ステップ７０３でノー(No)と判断された場合には、登録処理部２２は、第１のパラメータ群中のＡＰ＿ＩＤから、当該ＲＴＣクライアント１６が属するＡＰについてのＡＰ状態情報テーブル３０および接続制限情報テーブル３２のレコードを、それぞれ特定し、当該レコード中の値を参照する（ステップ７０４）。

次いで、登録処理部２２は、ＲＴＣ登録数とＲＴＣ登録数制限値、ＲＴＣ接続数とＲＴＣ接続数制限値、ＲＴＣ接続数に対するアラームの割合とアラーム数割合制限値を、それぞれ比較し、ＲＴＣ登録数がＲＴＣ登録数制限値より小さく（ｃｖ＿ｒ＜ｓｖ＿ｒ）、ＲＴＣ接続数がＲＴＣ接続数制限値より小さく（ｃｖ＿ｃ＜ｓｖ＿ｃ）、かつ、ＲＴＣ接続数に対するアラームの割合「ｃｖ＿ａｌａｒｍ／ｃｖ＿ｃ」が、アラーム数割合制限値より小さい（ｃｖ＿ａｌａｒｍ／ｃｖ＿ｃ＜ｓｖ＿ａｌａｒｍ）場合に（ステップ７０５でイエス(Yes)）、当該ＲＴＣクライアント１６の登録が可能と判断する。したがって、登録処理部２２はＡＰ状態情報処理部２４にＡＰ状態情報テーブル３０の更新を指示するとともに、ＡＰ状態情報処理部２４に、第１のパラメータ群を登録情報として与える。 図８および図９は、ＡＰ状態情報処理部２４にて実行される処理を示すフローチャートである。ＡＰ状態情報処理部２４は、ＱｏＳ情報受信処理部２０、登録処理部２２、呼制御処理部２６からの指示があるまで待機状態となっている（ステップ８０１）。上記３種類のいずれかの処理部からの指示があると、指示の内容を判断して、指示を出した処理部に対応した所定の処理を実行する。上述した場合には、ＡＰ状態情報処理部２４は、登録情報を受信し（図９のステップ９０１）、指示が削除指令であるか否かを判断する（ステップ９０２）。上記場合は登録の指示であるため、ステップ９０２においてノー(No)と判断される。ＡＰ状態情報処理部２４は、ＡＰ状態情報テーブル３０の該当レコードの、登録ＲＴＣリスト（ｃｖ＿ｌｉｓｔ）に、新規に登録するＲＴＣクライアント１６のクライアントＩＤを追加するとともに、当該レコードのＲＴＣ登録数を「１」だけ増やす（図７のステップ７０６、図９のステップ９０３）。

また、登録処理部２６は、登録位置情報テーブル（図示せず）に、クライアントＩＤ、ＩＰアドレス、登録時刻などを含むレコードを作成する（ステップ７０７）。その後、呼制御処理部２６は、ＲＴＣクライアント１６に対して、登録受信メッセージを返信する（ステップ７０８）。

その一方、ステップ７０５でノー(No)と判断された場合、つまり、ＲＴＣ登録数がＲＴＣ登録数制限値以上、ＲＴＣ接続数がＲＴＣ接続数制限値以上、或いは、「ｃｖ＿ａｌａｒｍ／ｃｖ＿ｃ＜ｓｖ＿ａｌａｒｍ」がアラーム数割合制限値以上の何れかであった場合には、呼制御処理部２６は、ＲＴＣクライアント１６に対して、登録拒否メッセージを送信する（ステップ７０９）。これを受信したＲＴＣクライアント１６は、登録できないことを示す音声メッセージをユーザに伝えても良いし、或いは、表示装置の画面上にテキストメッセージを表示しても良い。また、この登録拒否メッセージには、接続を推奨する近隣のＡＰ（推奨接続先ＡＰ）の情報（たとえば、当該ＡＰのＡＰ＿ＩＤ）を含ませても良い。

次に、登録解除が必要である場合（ステップ７０２でイエス(Yes)）について説明する。この場合には、登録処理部２２は、登録解除の指示とともに第１のパラメータ群をＡＰ状態情報処理部２４に渡す。したがって、ＡＰ状態情報処理部２４において、図９のステップ９０２においてイエス(Yes)と判断される。ＡＰ状態情報処理部２４は、ＡＰ状態情報テーブル３０から、登録ＲＴＣリスト（ｃｖ＿ｌｉｓｔ）に該当するＲＴＣクライアントのクライアントＩＤが含まれたレコードを見出し、見出されたレコードの登録ＲＴＣリストから、ＲＴＣクライアントのクライアントＩＤを削除するとともに、当該レコードのＲＴＣ登録数（ｃｖ＿ｒ）の値を「１」だけ減じる（ステップ７１０、図９のステップ９０４）。また、登録処理部２２は、登録位置情報テーブルから、クライアントＩＤを含むレコードを削除する（ステップ７１１）。

次に、ＲＴＣクライアント１６の移動時の処理について説明する。ＲＴＣ接続（たとえば通話）をしていないときに、ＲＴＣクライアント１６が、あるＡＰ（たとえば、ＡＰ−１（符号１４−１））から、異なるＡＰ（たとえば、ＡＰ−２（符号１４−２））に移動する場合を考える。

本実施の形態においては、ＲＴＣクライアント１６が、新たなＡＰ１４との接続（ａｓｓｏｃｉａｔｉｏｎ）をトリガとして、新しいＡＰ＿ＩＤを付加して登録を行い、成功した場合には、移動元のＡＰのＡＰ＿ＩＤで登録を解除する。この場合、呼制御装置１２の側では単に連続した登録要求と登録解除要求として受信されるので、基本的に、図７および図１０に示すフローチャートに従う。

また、ＲＴＣ通信（たとえば通話）の最中に、ＲＴＣクライアント１６が、あるＡＰ（たとえば、ＡＰ−１（符号１４−１））から、異なるＡＰ（たとえば、ＡＰ−２（符号１４−２））に移動した場合、移動先のＡＰ（たとえば、ＡＰ−２）が混雑している場合には、登録数が登録数制限値を超えてしまう可能性がある。

呼制御装置１２においては、通話中のＲＴＣクライアント１６が把握されている。したがって、上述した場合には、通信中のＲＴＣクライアント１６については、優先的に扱って、当該移動先のＡＰに関する登録数制限値を超えても登録を許可しても良い。より詳細には、上述した場合には、ステップ７０３においてイエス(Yes)と判断される。そこで、登録処理部２２は、移動元のＡＰに関する登録解除の指示および移動先のＡＰに関する登録指示を、ＡＰ状態情報処理部２４に渡す。これに応答して、ＡＰ状態情報処理部２４は、ＡＰ状態情報テーブル３０中、移動元のＡＰに関するレコードについて、当該レコードのＲＴＣ登録数（ｃｖ＿ｒ）およびＲＴＣ接続数（ｃｖ＿ｃ）を、それぞれ「１」ずつ減じるとともに、登録ＲＴＣリストから、ＲＴＣクライアントのクライアントＩＤを削除する（ステップ１００１）。また、ＡＰ状態情報処理部２４は、ＡＰ状態情報テーブル３０中、移動先のＡＰに関するレコードについて、当該レコードのＲＴＣ登録数（ｃｖ＿ｒ）およびＲＴＣ接続数（ｃｖ＿ｃ）を、それぞれ「１」ずつ増大させるとともに、登録ＲＴＣリストに、ＲＴＣクライアントのクライアントＩＤを追加する（ステップ１００２）。その後、ステップ７０７に戻り、登録位置情報テーブルが更新される（ステップ７０７）。

次に、ＲＴＣクライアント１６からの発呼要求や切断要求があった場合の処理について、図１１を参照して説明する。

呼制御処理部２６が発呼要求や切断要求の受信待ちの状態で（ステップ１１００）、登録されたＲＴＣクライアント１６からの発呼要求を受信すると（ステップ１１０１）、第１のパラメータ群および登録位置情報テーブルを参照して、発呼要求を送信したＲＴＣクライアントが接続中であるか否かが判断される（ステップ１１０２）。ステップ１１０２でノー(No)と判断された場合には、呼制御処理部２６は、発呼要求に含まれる発呼元および着信先のＲＴＣクライアントがそれぞれ属するＡＰのＡＰ＿ＩＤを特定し、ＡＰ状態情報テーブル３０中、当該ＡＰ＿ＩＤを含むそれぞれのレコードを特定する（ステップ１１０３）。呼制御処理部２６は、ＡＰ状態情報テーブル３０中、発呼元のＲＴＣクライアントが属するＡＰについてのレコードを参照して、ＲＴＣ接続数がＲＴＣ接続数制限値より小さく（ｃｖ＿ｃ＜ｓｖ＿ｃ）、かつ、アラームの割合がアラーム数割合制限値より小さい（ｃｖ＿ａｌａｒｍ／ｃｖ＿ｃ＜ｓｖ＿ａｌａｒｍ）か否かを判断する（ステップ１１０４）。

ステップ１１０４でイエス(Yes)と判断された場合には、呼制御処理部２６は、着呼先のＲＴＣクライアントが属するＡＰについても、ＡＰ状態情報テーブル３０のレコードを参照して、ＲＴＣ接続数がＲＴＣ接続数制限値より小さく（ｃｖ＿ｃ＜ｓｖ＿ｃ）、かつ、アラームの割合がアラーム数割合制限値より小さい（ｃｖ＿ａｌａｒｍ／ｃｖ＿ｃ＜ｓｖ＿ａｌａｒｍ）か否かを判断する（ステップ１１０５）。ステップ１１０５でもイエス(Yes)と判断されると、呼制御処理部２６は、ＡＰ状態情報処理部２４にＡＰ状態情報テーブル３０の更新を指示するとともに、呼接続情報として、発呼元および着呼先双方についての第１のパラメータ群を渡す。

ＡＰ状態情報処理部２４は、呼接続情報を受信すると（図８のステップ８０２）、削除指令であるか否かを判断する（ステップ８０３）。この場合、ステップ８０３においてノー(No)と判断されるため、ＡＰ状態情報処理部２４は、ＡＰ状態情報テーブル３０中、発呼側および着呼側のＡＰのＡＰ＿ＩＤを含むレコードのＲＴＣ接続数（ｃｖ＿ｃ）を「１」だけ増やす（ステップ１１０６、図８のステップ８０４）。

また、登録処理部２２は、登録位置情報テーブルにおいてそれぞれのクライアントＩＤを有するレコードに、着呼先の情報（たとえば、着呼先のＲＴＣクライアントのクライアントＩＤ）や発呼時刻など必要な情報を追加しておく。その後、呼制御処理部２６は、ＳＩＰ／Ｈ３２３などの手順に基づいて呼接続処理を実行する（ステップ１１０７）。このようにして、発呼元のＲＴＣクライアントと着信先のＲＴＣクライアントとの間のリアルタイム通信が開始される。

たとえば、ステップ１１０４でノー(No)或いはステップ１１０５でノー(No)と判断された場合には、呼制御処理部２２は発呼拒否処理を実行する（ステップ１１０８）。たとえば、呼制御処理部２２は、ＳＩＰ／Ｈ３２３などの手順にしたがって、ビジー状態を示すメッセージパケット、音声、或いは、ＩＶＲ（Ｉｎｔｅｒａｃｔｉｖｅ Ｖｏｉｃｅ Ｒｅｓｐｏｎｓｅ）を、ＲＴＣクライアントに返送する。

次に、ＲＴＣクライアント１６からの切断要求を受信すると（ステップ１１０９）、呼制御処理部２６は、ＡＰ状態情報処理部２４に、切断要求に伴うＡＰ状態情報テーブル３０の更新を指示するとともに、必要な情報を与える。ＡＰ状態情報処理部２４は、ＡＰ状態情報テーブル３０中、発呼元および着呼先のＲＴＣクライアントが属するＡＰのＡＰ＿ＩＤを、それぞれ含むレコードを特定し、これらレコードのＲＴＣ接続数（ｃｖ＿ｃ）を「１」だけ減ずる（ステップ１１１０、図８のステップ８０５）。

また、登録処理部２２は、登録位置情報テーブルにおいて、それぞれのクライアントＩＤの有するレコードに、呼切断時刻など必要な情報を追加しておく。その後、呼制御処理部２６は、ＳＩＰ／Ｈ３２３などの手順にしたがって、ＲＴＣクライアント間の呼を切断する（ステップ１１１１）。

次に、ＲＴＣクライアント１６の移動時における呼処理について説明する。ＲＴＣ通信中の移動では、基本的に新たな呼接続処理は発生しないことから、これにかかわる呼接続処理（図１１参照）は必要ない。しかしながら、たとえば、ＳＩＰにおいて、通信中にＱｏＳが低下して、音声コーデックを、より帯域の低いものに変更するような、動的な属性変更は可能である。この場合でも、接続中のＲＴＣクライアント１６からの再発呼処理（ｒｅＩｎｖｉｔｅ）であることが呼制御装置１２において判断可能である。したがって、このような場合には、本発明にかかる発呼規制の手順をふまずに、通常の標準的な手順にしたがってメッセージを処理することが可能である。ＲＴＣクライアント１６から再発呼（ｒｅＩｎｖｉｔｅ）の要求を受信すると、呼制御装置１２においては、図１１のステップ１１０２においてイエス(Yes)と判断される。この場合には、ステップ１１０３〜１１０６の処理を経ることなく、呼接続処理（ステップ１１０７）が実行される。

このように、本実施の形態によれば、ＡＰごとに、当該ＡＰに属するＲＴＣクライアントの登録数、リアルタイム通信による接続数、アラーム数？などをＡＰ状態情報テーブル３０に保持し、登録数、接続数、アラーム数の割合が、予め定められた制限値に達していない場合に、ＲＴＣクライアントの登録を認める。また、発呼元のＲＴＣクライアントおよび着呼先のＲＴＣクライアントがそれぞれ属するＡＰについて、ＲＴＣクライアントの接続数、アラーム数の割合が、上記制限値に達していない場合に、これらＲＴＣクライアント間のリアルタイム通信を認める。これにより、粒度の高い呼制御を実現することが可能となる。

図６を参照して、ＲＴＣクライアント１６におけるアラーム通知処理について、説明した。本実施の形態では、ＲＴＣクライアント１６は、アラームを呼制御装置１２に通知した後、ＱｏＳ値が改善した場合には、アラーム解除を、呼制御装置１２に送信する。図１２は、本実施の形態にかかるＲＴＣクライアント１６において実行されるアラーム解除通知処理を示すフローチャートである。

図１２に示すように、ＲＴＣクライアント１６のＱｏＳ判断部４６は、一定時間の待機状態の後（ステップ１２０１）、ＲＴＣクライアント１６がリアルタイム通信を実行しているか否かを判断する（ステップ１２０２）。ステップ６０２でイエス(Yes)と判断された場合には、ＱｏＳ判断部４６は、ＲＴＣクライアント１６自身のメモリの何れかの領域に設けられたアラーム送信フラグが「１」である（つまりセットされた状態であるか）、あるいは、「０」であるかを判断する（ステップ１２０３）。

アラーム送信フラグが「１」である場合には（ステップ１２０３でイエス(Yes)）、ＱｏＳ判断部４６は、Ｈ／Ｗドライバ４８から、現在接続中のＡＰからの電波の、測定された電界強度を取得して（ステップ１２０４）、電界強度が所定の第１の閾値を越えているか否かを判断する（ステップ１２０５）。

ステップ１２０５でイエス(Yes)と判断された場合には、ＱｏＳ判断部４６は、メディア転送部４４から、メディア受信状態を示す情報として、ＱｏＳ値を取得する（ステップ１２０６）。ＱｏＳ判断部４６は、ＱｏＳ値が、所定の第２の閾値以上か否かを判断する（ステップ１２０７）。つまり、ステップ１２０７において、ＱｏＳ値が一定以上に回復しているかを調べている。

ステップ１２０７でイエス(Yes)と判断した場合には、ＱｏＳ判断部４６は、ＱｏＳ情報送信処理部４０に対して、アラーム解除指示の送信を指示する。ＱｏＳ情報送信処理部４０は、指示に応答して、アラーム解除指示を送信する（ステップ１２０８）。これにより、アラーム情報（クライアントＩＤ、アラーム解除指示）を含むパケットが、ＡＰを介して、呼制御装置１２に伝達される。送信後、ＱｏＳ判断部４６は、メモリ中にセットされていたアラーム送信を示すアラーム送信フラグをリセットする（ステップ１２０９）。

上記アラーム情報（クライアントＩＤ、アラーム解除指示）を受信した呼制御装置１２は、AP状態情報テーブルの登録RTCリストフィールドを参照して、ＲＴＣクライアント１６のクライアントＩＤに基づき、当該ＲＴＣクライアント１６が属するＡＰを特定し、ＡＰ状態情報テーブル３０の当該ＡＰに関するレコード中、アラーム数（ｃｖ＿ａｌａｒｍ）を「−１」する。このアラームの受信に応答して実行される呼制御装置１２の処理については、以下に説明する。 次に、ＡＰ状態情報処理部２４によるアラームに関する処理について説明する。前述したように、ＲＴＣクライアント１６のＱｏＳ情報送信処理部４０から、呼制御装置１２のＱｏＳ情報受信処理部２０に対して、アラーム情報（クライアントＩＤ、アラーム或いはアラーム解除指示）が送信され、呼制御装置１２において、ＡＰ状態情報処理部２４には、（クライアントＩＤ、アラーム或いはアラーム解除指示）というデータの組が通知される。

ＡＰ状態情報処理部２４は、アラーム情報として上記データの組を受信すると（ステップ８０６）、ＡＰ状態情報テーブル３０中、当該ＲＴＣクライアントが属するＡＰのＡＰ＿ＩＤを有するレコードを検索する（ステップ８０７）。次いで、ＡＰ状態情報処理部２４は、受信したデータの組中の、「アラーム」或いは「アラームの解除」という情報にしたがって、ＡＰ状態情報テーブル３０のレコード中、「アラーム数」の項目を更新する（ステップ８０８）。データの組（アラーム情報）が、（クライアントＩＤ、アラーム）であれば、ＡＰ状態情報処理部２４は、ＡＰ状態情報テーブル３０のレコード中、「アラーム数」の項目を「＋１」し、その一方、データの組（アラーム情報）が、（クライアントＩＤ、アラーム解除指示）であれば、ＡＰ状態情報処理部２４は、上記レコード中、「アラーム数」の項目を「−１」する。

このステップ８０７、８０８の処理は、上記データの組を受信するごとに実行しても良いし、或いは、所定の時間、データの組を一時的に保持しておき、適当なタイミングで実行するように構成しても良い。或いは、ＱｏＳ情報受信部２０が、所定の時間データの組を一時的に保持し、適当なタイミングで、これらをＡＰ状態情報処理部２４に通知しても良い。

このように、本実施の形態によれば、ＡＰ状態情報テーブル３０中のアラーム情報に基づくアラーム数を、更新することで、最適な呼制御を実現可能としている。

本実施の形態によれば、リアルタイム通信中のＲＴＣクライアント１６において、通信品質が所定のレベルより悪化した場合に、呼制御装置１２に対して、アラームを通知する。呼制御装置１２は、ＲＴＣクライアントの属するＡＰごとにアラーム数を把握しておき、そのアラーム数やアラームの割合に基づいて、新たなＲＴＣクライアントの登録の可否や接続の可否を判断する。本実施の形態では、ＲＴＣクライアントが、通信品質の悪化というイベントに応答して、呼制御装置１２にアラームを通知するため、適切な登録制限、接続制限を実現するために、ＲＴＣクライアント１６と呼制御装置１２との間のトラヒックを増大させることが無い。

次に、本発明の第２の実施の形態について説明する。第１の実施の形態においては、ＲＴＣクライアント１６が、通信品質が所定のレベルに回復した際に、当該ＲＴＣクライアント１６が、アラーム解除指示を、呼制御装置１２に通知している。このアラーム解除通知に応答して、呼制御装置１２において、ＡＰ状態情報テーブル３０の該当レコード中のアラーム数を減じている。

第２の実施の形態では、ＲＴＣクライアント１６がアラーム解除通知をすることなく、呼制御装置１２が、ＡＰ状態情報テーブル３０の該当レコード中のアラーム数を減じている。つまり、ＲＴＣクライアント１６からは、「アラーム」のみが呼制御装置１２に通知される。第２の実施の形態にかかる呼制御装置１２においては、アラームを通知してきたＲＴＣクライアント１６からの切断要求を受信したときに、ＡＰ状態情報テーブル３０の、当該ＲＴＣクライアント１６が属するＡＰに関するレコード中、「アラーム数」を「１」だけ減じる。

より具体的には、呼制御装置１２が、ＲＴＣクライアント１６からアラームを受信し、それに応答して、ＡＰ状態情報処理部２４がアラーム情報（クライアントＩＤ、アラーム）を受信すると（図８のステップ８０６参照）、ＡＰ状態情報処理部２４は、図１３（ａ）に示すように、データの組中の、ＲＴＣクライアントの「クライアントＩＤ」に基づいて、ＡＰ状態情報テーブル３０中、当該ＲＴＣクライアントが属するＡＰのＡＰ＿ＩＤを有するレコードを検索する（ステップ１３０１）。次いで、ＡＰ状態情報処理部２４は、ＡＰ状態情報テーブル３０のレコード中、「アラーム数」の項目を「＋１」する（ステップ１３０２）。また、第２の実施の形態では、状態情報テーブル３０に、「アラーム通知にかかるＲＴＣリスト」の項目を設けておき（図示せず）、ＡＰ状態情報処理部２４は、ＡＰ状態情報テーブル３０の該当レコード中、「アラーム通知にかかるＲＴＣリスト」に、アラームを通知してきたＲＴＣクライアント１６のクライアントＩＤを格納する（ステップ１３０３）。

また、呼制御装置１２がＲＴＣクライアント１６からの切断要求を受信した場合に、ＡＰ状態情報処理部２４が以下の処理を実行する。図８のステップ８０３で、「削除指令」であると判断されると、ＡＰ状態情報処理部２４は、図１３（ｂ）に示すように、ＡＰ状態情報テーブル３０中、発呼元および着呼先のＲＴＣクライアントが属するＡＰのＡＰ＿ＩＤを、それぞれ含むレコードを特定し、これらレコードのＲＴＣ接続数（ｃｖ＿ｃ）を「１」だけ減ずる（ステップ１３１１）。また、ＡＰ状態情報処理部２４は、ＡＰ状態情報テーブル３０のそれぞれのレコードについて、「アラーム通知にかかるＲＴＣリスト」に、発呼元或いは着呼先のＲＴＣクライアントのクライアントＩＤが格納されているか否かを判断する（ステップ１３１２）。ステップ１３１２でイエス(Yes)と判断された場合には、ＡＰ状態情報処理部２４は、レコード中、「アラーム通知にかかるＲＴＣリスト」から、そのクライアントＩＤを削除する（ステップ１３１３）とともに、「アラーム数」の項目を「−１」する（ステップ１３１４）。

これにより、アラームを通知してきたＲＴＣクライアント１６における呼が切断されたときに、アラーム数を「１」だけ減じることができる。

次に、本発明の第３の実施の形態について説明する。第２の実施の形態では、アラームを通知してきたＲＴＣクライアント１６が切断することで、ＡＰ状態情報テーブル３０の該当レコード中、「アラーム数」の項目を減じている。第３の実施の形態では、ＲＴＣクライアント１６からアラームが通知され、ＡＰ状態情報テーブル３０中の該当レコードの「アラーム数」が「＋１」された後、所定の時間が経過すると、「アラーム数」を「−１」する。たとえば、これは、ＡＰ状態情報テーブル３０に、「アラーム数」を「＋１」した時刻を示す項目を設けておき、アラーム情報受信に応じたＡＰ状態情報処理部２４による処理中、図８のステップ８０８において、「時刻」の項目に、処理日時を格納しておく。また、ＡＰ状態情報処理部２４は、所定のタイミングで、ＡＰ状態情報テーブル３０中、各レコードの「時刻」の項目を参照して、現在日時が、格納された処理日時から所定の時間経過している場合には、当該「処理日時」を削除するとともに、「アラーム数」の項目を「−１」すれば良い。

第２の実施の形態および第３の実施の形態によれば、ＲＴＣクライアント１６は、アラームのみを呼制御装置１２に通知すれば良く、ＲＴＣクライアント１６における処理負荷をより軽減することができる。また、ＲＴＣクライアント１６と呼制御装置１２との間のトラヒック量をより削減することが可能となる。

本発明は、以上の実施の形態に限定されることなく、特許請求の範囲に記載された発明の範囲内で、種々の変更が可能であり、それらも本発明の範囲内に包含されるものであることは言うまでもない。

たとえば、前記第１の実施の形態〜第３の実施の形態においては、登録情報（第１のパラメータ群）をＲＴＣクライアント１６から取得しているが、これに限定されず、たとえば、認証サーバやＤＨＣＰ（Ｄｙｎａｍｉｃ Ｈｏｓｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）サーバから登録情報を取得しても良い。

或いは、上記登録情報を、ＡＰから取得しても良い。ＡＰにおいては、通常接続（ａｓｓｏｃｉａｔｉｏｎ）されたクライアントのＭＡＣアドレスおよびＩＰアドレスが対応付けられている。そこで、ＲＴＣクライアント１６からの登録要求があったときに、呼制御装置１２がＡＰに対して、これらの情報を問い合わせればよい。ここで、全てのＡＰに対して問合せするのは非効率であるため、ｓｙｓｌｏｇ等を利用して、ＡＰから呼制御装置１２に報告させるように構成することも可能である。なお、ＲＴＣクライアント１６の移動時に、この実施の形態においては、その移動に伴って、ＡＰからｓｙｓｌｏｇ等により、呼制御装置１２に通知される。したがって、ＡＰ状態情報テーブル３０中、移動元のＡＰや移動先のＡＰに関するレコードの更新、登録位置情報テーブルの更新が実現可能である。

また、前記実施の形態において、呼制御装置１２が、ＲＴＣクライアント１６の登録の際に、ＡＰ状態情報テーブル３０において、ＲＴＣ登録数、ＲＴＣ接続数、および、アラームの割合を、接続制限情報テーブル３２の制限値を比較しているが、これに限定されるものではなく、ＲＴＣ登録数およびアラームの割合のみを考慮しても良い。つまり、図７のステップ７０５において、「ｃｖ＿ｒ＜ｓｖ＿ｒ」かつ「アラームの割合＜ｓｖ＿ａｌａｒｍ」を判断するように構成しても良い。或いは、アラームの割合も判断せず、ＲＴＣ登録数のみを判断し、「ｃｖ＿ｒ＜ｓｖ＿ｒ」が見たされれば、当該ＲＴＣクライアント１６を登録するように構成しても良い。

また、本発明を、無線ＬＡＮ環境だけでなく、ＲＴＣクライアント１６が有線でエッジルータに接続されるような環境においても適用することが可能である。なお、ＲＴＣクライアントとは、携帯電話の形態をとるものに限定されず、ラップトップコンピュータやデスクトップコンピュータの形態をとっていても良い。つまり、本明細書においてＲＴＣクライアントとは、リアルタイム通信をするクライアントを意味し、その外見はどのようなものであっても良い。

さらに、前記実施の形態においては、ＱｏＳ情報として、ジッタ値、パケットロス数、往復遅延時間（ＲＴＴ）を利用しているが、これに限定されるものではなく、これらの何れか一つ或いは複数が利用されても良いし、他の指標が利用されても良い。

図１は、本発明の実施の形態にかかる無線ＬＡＮ通信環境の全体を示すブロックダイヤグラムである。 図２は、本実施の形態にかかる呼制御装置の構成を示すブロックダイヤグラムである。 図３は、本実施の形態にかかるＲＴＣクライアントの構成を示すブロックダイヤグラムである。 図４（ａ）は、ＡＰ状態情報テーブルのデータ構成を示す図、図４（ｂ）は、接続制限情報テーブルのデータ構成を示す図である。 図５は、本実施の形態にかかるＲＴＣクライアントの登録・呼制御処理部が送信するメッセージの例を示す図である。 図６は、本実施の形態にかかるＲＴＣクライアントにおいて実行されるアラーム通知処理を示すフローチャートである。 図７は、本実施の形態にかかる呼制御装置で実行される登録処理を示すフローチャートである。 図８は、本実施の形態にかかるＡＰ状態情報処理部にて実行される処理を示すフローチャートである。 図９は、本実施の形態にかかるＡＰ状態情報処理部にて実行される処理を示すフローチャートである。 図１０は、本実施の形態にかかる呼制御装置で実行される登録処理を示すフローチャートである。 図１１は、本実施の形態において、ＲＴＣクライアントからの発呼要求や切断要求があった場合に呼制御装置で実行される処理を示すフローチャートである。 図１２は、本実施の形態にかかるＲＴＣクライアントにおいて実行されるアラーム解除通知処理を示すフローチャートである。 図１３は、第２の実施の形態にかかる呼制御装置で実行される処理の例を示すフローチャートである。

符号の説明

１１ ネットワーク
１２ 呼制御装置
１４ ＡＰ
１５ ルータ
１６ ＲＴＣクライアント
２０ ＱｏＳ情報受信処理部
２２ 登録処理部
２４ ＡＰ状態情報処理部
２６ 呼制御処理部
２８ ＤＢ
３０ ＡＰ状態情報テーブル
３２ 接続制限情報テーブル
４０ ＱｏＳ情報送信処理部
４２ 登録・呼制御処理部
４４ メディア転送部
４６ ＱｏＳ判断部
４８ Ｈ／Ｗドライバ

Claims (14)

1. リアルタイム通信するリアルタイム通信クライアント（ＲＴＣクライアント）と、当該ＲＴＣクライアントと接続される末端中継装置と、呼制御装置とを含むネットワーク環境において、前記ＲＴＣクライアントの呼を制御する呼制御方法であって、
   前記呼制御装置において、
   前記ＲＴＣクライアントから発行された、当該ＲＴＣクライアントを特定する情報および当該ＲＴＣクライアントの属する末端中継装置の情報を含む第１のパラメータ群を伴う登録要求に応じて、当該登録要求に伴う前記第１のパラメータ群を、当該登録要求を発行したＲＴＣクライアントの登録情報として登録するステップと、
   前記登録情報が登録されたＲＴＣクライアントである登録ＲＴＣクライアントから発行された、他の登録ＲＴＣクライアントとの接続を要求する接続要求に応じて、接続の可否を判定し、接続可と判定された場合に、当該接続要求を発行した登録ＲＴＣクライアントと前記他の登録ＲＴＣクライアントとの接続を制御するステップと、
   他のＲＴＣクライアントと接続中のＲＴＣクライアントである接続ＲＴＣクライアントにおいて、
   自己のＱｏＳに関する情報に基づき、前記リアルタイム通信の品質を表すＱｏＳ値が所定の閾値より悪化した場合に、アラームを示す情報を、前記ネットワークおよび前記末端中継装置を介して、前記呼制御装置に送信するステップと、
   前記呼制御装置において、
   前記接続ＲＴＣクライアントから、前記アラームを示す情報を受信するステップと、
   前記接続ＲＴＣクライアントから受信した前記アラームを示す情報にしたがって、当該アラームを示す情報を送信した接続ＲＴＣクライアントが属する末端中継装置ごとのアラームの発生状況に関する情報を記憶した状態情報テーブルを更新するステップとを有し、
   前記接続を制御するステップにおいて、前記登録ＲＴＣクライアントから発行された接続要求を受信したときに、当該接続要求を発行した登録ＲＴＣクライアントの登録情報として登録されている前記第１のパラメータ群に基づき、当該接続要求を発行した登録ＲＴＣクライアントおよび当該接続要求を発行した登録ＲＴＣクライアントが属する末端中継装置を特定し、かつ、前記状態情報テーブルを参照して、当該接続要求を発行した登録ＲＴＣクライアントが属する末端中継装置のアラームの発生状況に関する情報を参照して、接続の可否を判定することを特徴とする呼制御方法。
2. リアルタイム通信するリアルタイム通信クライアント（ＲＴＣクライアント）と、当該ＲＴＣクライアントと接続される末端中継装置と、呼制御装置とを含むネットワーク環境において、前記ＲＴＣクライアントの呼を制御する呼制御方法であって、
   前記呼制御装置において、
   前記ＲＴＣクライアントから発行された、当該ＲＴＣクライアントを特定する情報および当該ＲＴＣクライアントの属する末端中継装置の情報を含む第１のパラメータ群を伴う登録要求に応じて、登録の可否を判定し、登録可と判定された場合に、当該登録要求に伴う前記第１のパラメータ群を、当該登録要求を発行したＲＴＣクライアントの登録情報として登録するステップと、
   前記登録情報が登録されたＲＴＣクライアントである登録ＲＴＣクライアントから発行された、他の登録ＲＴＣクライアントとの接続を要求する接続要求に応じて、当該接続要求を発行した登録ＲＴＣクライアントと前記他の登録ＲＴＣクライアントとの接続を制御するステップと、
   他のＲＴＣクライアントと接続中のＲＴＣクライアントである接続ＲＴＣクライアントにおいて、
   自己のＱｏＳに関する情報に基づき、前記リアルタイム通信の品質を表すＱｏＳ値が所定の閾値より悪化した場合に、アラームを示す情報を、前記ネットワークおよび前記末端中継装置を介して、前記呼制御装置に送信するステップと、
   前記呼制御装置において、
   前記接続ＲＴＣクライアントから、前記アラームを示す情報を受信するステップと、
   前記接続ＲＴＣクライアントから受信した前記アラームを示す情報にしたがって、当該アラームを示す情報を送信した接続ＲＴＣクライアントが属する末端中継装置ごとのアラームの発生状況に関する情報を記憶した状態情報テーブルを更新するステップとを有し、
   前記ＲＴＣクライアントを登録するステップにおいて、前記ＲＴＣクライアントから発行された登録要求を受信したときに、当該登録要求に伴う前記第１のパラメータ群に基づき、当該登録要求を発行したＲＴＣクライアントおよび当該登録要求を発行したＲＴＣクライアントが属する末端中継装置を特定し、かつ、前記状態情報テーブルを参照して、当該登録要求を発行したＲＴＣクライアントが属する末端中継装置のアラームの発生状況に関する情報を参照して、登録の可否を判定することを特徴とする呼制御方法。
3. 前記ＲＴＣクライアントを登録するステップは、前記登録要求に応じて、登録の可否を判定し、登録可と判定された場合に、当該登録要求に伴う前記第１のパラメータ群を、当該登録要求を発行したＲＴＣクライアントの登録情報として登録するステップであり、
   当該ＲＴＣクライアントを登録するステップにおいて、前記ＲＴＣクライアントから発行された登録要求を受信したときに、当該登録要求に伴う前記第１のパラメータ群に基づき、当該登録要求を発行したＲＴＣクライアントおよび当該登録要求を発行したＲＴＣクライアントが属する末端中継装置を特定し、かつ、前記状態情報テーブルを参照して、当該登録要求を発行したＲＴＣクライアントが属する末端中継装置のアラームの発生状況に関する情報を参照して、登録の可否を判定することを特徴とする請求項１に記載の呼制御方法。
4. 前記状態情報テーブルが、アラームの発生状況に関する情報の項目として、前記末端中継装置ごとの、前記接続ＲＴＣクライアントから通知されたアラームの合計数を含み、
   前記ＲＴＣクライアントを登録するステップにおいて、前記状態情報テーブルの、前記登録要求を発行したＲＴＣクライアントが属する末端中継装置に関する前記アラームの合計数を参照して、登録可否を判定することを特徴とする請求項２または３に記載の呼制御方法。
5. 前記状態情報テーブルが、項目として、前記末端中継装置ごとの、接続ＲＴＣクライアント数を接続数として含み、
   前記ＲＴＣクライアントを登録するステップにおいて、前記状態情報テーブル中の、前記登録要求を発行したＲＴＣクライアントが属する末端中継装置の接続数に対する、当該登録要求を発行したＲＴＣクライアントが属する末端中継装置に関するアラームの合計数の割合が所定のレベル以下である場合に、登録可と判定することを特徴とする請求項４に記載の呼制御方法。
6. 前記状態情報テーブルが、アラームの発生状況に関する情報の項目として、前記末端中継装置ごとの、前記接続ＲＴＣクライアントから通知されたアラームの合計数を含み、
   前記接続を制御するステップにおいて、前記状態情報テーブル中の、前記接続要求を発行した登録ＲＴＣクライアントが属する末端中継装置に関する前記アラームの合計数を参照して、接続可否を判定することを特徴とする請求項１または３に記載の呼制御方法。
7. 前記状態情報テーブルが、項目として、前記末端中継装置ごとの、接続ＲＴＣクライアント数を接続数として含み、
   前記接続の可否を判定するステップにおいて、前記状態情報テーブル中の、前記接続要求を発行した登録ＲＴＣクライアントが属する末端中継装置の接続数に対する、当該接続要求を発行した登録ＲＴＣクライアントが属する末端中継装置に関するアラームの合計数の割合を参照して、接続可否を判定することを特徴とする請求項６に記載の呼制御方法。
8. 前記接続を制御するステップにおいて、前記状態情報テーブル中の、前記接続要求を発行した登録ＲＴＣクライアントが属する末端中継装置に関する前記アラームの合計数に加え、当該接続要求が接続を要求する前記他の登録ＲＴＣクライアントが属する末端中継装置に関する前記アラームの合計数を参照して、接続可否を判定することを特徴とする請求項６に記載の呼制御方法。
9. 前記接続を制御するステップにおいて、前記状態情報テーブル中の、前記接続要求を発行したＲＴＣクライアントが属する末端中継装置の接続数に対する、前記接続要求を発行した登録ＲＴＣクライアントが属する末端中継装置に関するアラームの合計数の割合が所定のレベル以下であり、かつ、当該接続要求が接続を要求する前記他の登録ＲＴＣクライアントが属する末端中継装置の接続数に対する、当該他の登録ＲＴＣクライアントが属する末端中継装置に関するアラームの合計数の割合が所定のレベル以下である場合に接続可と判定することを特徴とする請求項７に記載の呼制御方法。
10. さらに、前記接続ＲＴＣクライアントにおいて、前記ＱｏＳ値が、前記所定の閾値よりも良好となった場合に、前記アラーム解除を示す情報を、前記ネットワークおよび前記末端中継装置を介して、前記呼制御装置に送信するステップと、
    前記呼制御装置において、前記接続ＲＴＣクライアントから、前記アラーム解除を示す情報を受信するステップと、
    前記アラーム解除を示す情報にしたがって、当該アラーム解除を示す情報を送信した前記接続ＲＴＣクライアントが属する末端中継装置ごとのアラームの発生状況に関する情報を記憶した状態情報テーブルを更新するステップと、を備えたことを特徴とする請求項１ないし９の何れか一項に記載の呼制御方法。
11. 前記接続ＲＴＣクライアントにおいて、パケット遅延時間の揺らぎであるジッタ値、パケットロス数および／または往復遅延時間に基づくＱｏＳ値を算出するステップを備えたことを特徴とする請求項１ないし１０に記載の呼制御方法。
12. リアルタイム通信するリアルタイム通信クライアント（ＲＴＣクライアント）と、当該ＲＴＣクライアントと接続される末端中継装置と、呼制御装置とを含むネットワーク環境において、前記ＲＴＣクライアントの呼を制御する前記呼制御装置であって、
    前記ＲＴＣクライアントから発行された、当該ＲＴＣクライアントを特定する情報および当該ＲＴＣクライアントの属する末端中継装置の情報を含む第１のパラメータ群を伴う登録要求に応じて、当該登録要求に伴う前記第１のパラメータ群を、当該登録要求を発行したＲＴＣクライアントの登録情報として登録する登録手段と、
    前記登録情報が登録されたＲＴＣクライアントである登録ＲＴＣクライアントから発行された、他の登録ＲＴＣクライアントとの接続を要求する接続要求に応じて、接続の可否を判定し、接続可と判定された場合に、当該接続要求を発行した登録ＲＴＣクライアントと前記他の登録ＲＴＣクライアントとの接続を制御する接続制御手段と、
    他のＲＴＣクライアントと接続中のＲＴＣクライアントである接続ＲＴＣクライアントにおいて前記リアルタイム通信の品質を表すＱｏＳ値が所定の閾値より悪化した旨のアラームを示す情報を、当該接続ＲＴＣクライアントから受信するアラーム受信手段と、
    前記接続ＲＴＣクライアントから受信した前記アラームを示す情報にしたがって、当該アラームを示す情報を送信した接続ＲＴＣクライアントが属する末端中継装置ごとのアラームの発生状況に関する情報を記憶した状態情報テーブルを更新する状態情報テーブル更新手段とを有し、
    前記接続制御手段は、前記登録ＲＴＣクライアントから発行された接続要求を受信したときに、当該接続要求を発行した登録ＲＴＣクライアントの登録情報として登録されている前記第１のパラメータ群に基づき、当該接続要求を発行した登録ＲＴＣクライアントおよび当該接続要求を発行した登録ＲＴＣクライアントが属する末端中継装置を特定し、かつ、前記状態情報テーブルを参照して、当該接続要求を発行した登録ＲＴＣクライアントが属する末端中継装置のアラームの発生状況に関する情報を参照して、接続の可否を判定することを特徴とする呼制御装置。
13. リアルタイム通信するリアルタイム通信クライアント（ＲＴＣクライアント）と、当該ＲＴＣクライアントと接続される末端中継装置と、呼制御装置とを含むネットワーク環境において、前記ＲＴＣクライアントの呼を制御する前記呼制御装置であって、
    前記ＲＴＣクライアントから発行された、当該ＲＴＣクライアントを特定する情報および当該ＲＴＣクライアントの属する末端中継装置の情報を含む第１のパラメータ群を伴う登録要求に応じて、登録の可否を判定し、登録可と判定された場合に、当該登録要求に伴う前記第１のパラメータ群を、当該登録要求を発行したＲＴＣクライアントの登録情報として登録する登録手段と、
    前記登録情報が登録されたＲＴＣクライアントである登録ＲＴＣクライアントから発行された、他の登録ＲＴＣクライアントとの接続を要求する接続要求に応じて、当該接続要求を発行した登録ＲＴＣクライアントと前記他の登録ＲＴＣクライアントとの接続を制御する接続制御手段と、
    他のＲＴＣクライアントと接続中のＲＴＣクライアントである接続ＲＴＣクライアントにおいて、
    他のＲＴＣクライアントと接続中のＲＴＣクライアントである接続ＲＴＣクライアントにおいて前記リアルタイム通信の品質を表すＱｏＳ値が所定の閾値より悪化した旨のアラームを示す情報を、当該接続ＲＴＣクライアントから受信するアラーム受信手段と、
    前記接続ＲＴＣクライアントから受信した前記アラームを示す情報にしたがって、当該アラームを示す情報を送信した接続ＲＴＣクライアントが属する末端中継装置ごとのアラームの発生状況に関する情報を記憶した状態情報テーブルを更新する状態情報テーブル更新手段とを有し、
    前記登録手段において、前記ＲＴＣクライアントから発行された登録要求を受信したときに、当該登録要求に伴う前記第１のパラメータ群に基づき、当該登録要求を発行したＲＴＣクライアントおよび当該登録要求を発行したＲＴＣクライアントが属する末端中継装置を特定し、かつ、前記状態情報テーブルを参照して、当該登録要求を発行したＲＴＣクライアントが属する末端中継装置のアラームの発生状況に関する情報を参照して、登録の可否を判定することを特徴とする呼制御装置。
14. 前記登録手段は、前記登録要求に応じて、登録の可否を判定し、登録可と判定された場合に、当該登録要求に伴う前記第１のパラメータ群を、当該登録要求を発行したＲＴＣクライアントの登録情報として登録し、
    当該登録手段において、前記ＲＴＣクライアントから発行された登録要求を受信したときに、当該登録要求に伴う前記第１のパラメータ群に基づき、当該登録要求を発行したＲＴＣクライアントおよび当該登録要求を発行したＲＴＣクライアントが属する末端中継装置を特定し、かつ、前記状態情報テーブルを参照して、当該登録要求を発行したＲＴＣクライアントが属する末端中継装置のアラームの発生状況に関する情報を参照して、登録の可否を判定することを特徴とする請求項１２に記載の呼制御装置。

Images