JP2006108834A - 呼制御方法、および、呼制御装置 - Google Patents

Abstract

【課題】 それぞれのＡＰの状態を考慮して、個別に適切に登録や接続を規制する。
【解決手段】 呼制御装置１２は、ネットワーク１１を介して、ＲＴＣクライアント１６を特定する情報およびＲＴＣクライアントの属するアクセスポイント（ＡＰ）１４の情報を含む第１のパラメータ群を受信し、また、ＲＴＣクライアントにおけるＱｏＳに関する情報を含む第２のパラメータ群を受信して、第２のパラメータ群にしたがって、ＲＴＣクライアント１６が属するＡＰ１４ごとのＱｏＳに関する情報を記憶した状態情報テーブル３０を更新する。ＲＴＣクライアントによる登録要求、或いは、接続要求を受信すると、呼制御装置１２は、第１のパラメータ群に基づき、ＲＴＣクライアントおよびその属するＡＰを特定し、かつ、状態情報テーブルを参照して、ＲＴＣクライアントが属するＡＰのＱｏＳに関する情報を参照して、登録の可否或いは接続の可否を判断する。
【選択図】 図１

Description

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

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

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

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

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

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

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

本発明は、それぞれのＡＰの状態を考慮して、個別に適切に登録や接続を規制することができるデータ通信方法、呼制御装置、呼制御プログラムを提供することを目的とする。

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

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

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

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

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

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

この実施態様によれば、接続要求にかかるＲＴＣクライアントおよび接続相手となるＲＴＣクライアントの双方にかかる末端中継装置の状況にしたがって接続の可否が判断される。

なお、ＲＴＣクライアントと末端中継装置が無線にて接続され得る場合に、当該ＲＴＣクライアントが他の末端中継装置を介してネットワークに接続中に移動することにより、当該ＲＴＣクライアントからの接続要求が前記末端中継装置に受信されることがある。このように、既にＲＴＣクライアントが接続中である場合には、状態情報テーブル中、接続要求にかかる前記末端中継装置に関する登録数および／または接続数にかかわらず、その登録および接続を認め、前記情報状態テーブル中、他の末端中継装置に関する登録数および接続数、ならびに、接続要求にかかる末端中継装置に関する登録数および接続数を更新するのが望ましい。これにより、ＲＴＣクライアントは、ＲＴＣ通信を継続することができる。

また、別の好ましい実施態様においては、前記第２のパラメータ群が、ＲＴＣクライアントにおけるパケット遅延時間の揺らぎであるジッタ値、パケットロス数および／または往復遅延時間を含み、前記状態情報テーブルを更新するステップが、前記ジッタ値の統計値、パケットロス数の統計値、および／または往復遅延時間の統計値を更新するステップを含む。

さらに別の好ましい実施態様においては、前記状態情報テーブルを更新するステップが、前記ジッタ値の統計値、パケットロス数の統計値、および／または往復遅延時間の統計値に基づくＱｏＳ値を更新するステップを含み、前記登録の可否或いは接続の可否を判断するステップが、前記ＱｏＳ値を参照するステップを含む。このＱｏＳ値として、Ｒ値やＭＯＳ値を用いることができる。

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

ある実施態様においては、前記ＲＴＣクライアントにおいて、登録要求の際に、前記第１のパラメータ群を送信するステップを備え、前記呼制御装置において、前記ＲＴＣクライアントから送信された前記第１のパラメータ群を受信する。或いは、前記ＲＴＣクライアントを認証する認証サーバ、および、ＤＨＣＰ（Ｄｙｎａｍｉｃ Ｈｏｓｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）サーバから送信された情報に基づき、前記呼制御装置において、前記第１のパラメータ群を取得するように構成しても良い。

また、ある実施態様においては、前記呼制御装置において、前記ＲＴＣクライアントが属する末端中継装置から送信された前記第１のパラメータ群を受信する。或いは、前記ＲＴＣクライアントにおいて、前記第２のパラメータ群を送信するステップを備え、前記呼制御装置において、前記ＲＴＣクライアントから送信された前記第２のパラメータ群を受信するように構成しても良い。また、前記呼制御装置において、前記末端中継装置からＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｃｏｔｏｌ）を利用した前記第２のパラメータ群を取得するように構成しても良い。

また、本発明の目的は、リアルタイム通信するリアルタイム通信クライアント（ＲＴＣクライアント）と、当該ＲＴＣクライアントと接続される末端中継装置と、を含むネットワーク環境において、ネットワークおよび前記末端中継装置を介して、ＲＴＣクライアントとデータ通信可能な呼制御装置であって、
前記ネットワークを介して、ＲＴＣクライアントを特定する情報および当該ＲＴＣクライアントの属する末端中継装置の情報を含む第１のパラメータ群を受信する第１の受信手段と、前記ＲＴＣクライアントにおけるＱｏＳに関する情報を含む第２のパラメータ群を受信する第２の受信手段と、前記第２の受信手段による第２のパラメータ群にしたがって、前記ＲＴＣクライアントが属する末端中継装置ごとのＱｏＳに関する情報を記憶した状態情報テーブルを更新する状態情報処理手段と、前記ＲＴＣクライアントによる登録要求、或いは、接続要求を受信したときに、前記第１のパラメータ群に基づき、ＲＴＣクライアントおよび当該ＲＴＣクライアントが属する末端中継装置を特定し、かつ、前記状態情報テーブルを参照して、前記ＲＴＣクライアントが属する末端中継装置のＱｏＳに関する情報を参照して、登録の可否或いは接続の可否を判断する判断手段と、を備えたことを特徴とする呼制御装置によっても達成される。

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

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

さらに好ましい実施態様においては、前記判断手段が、前記状態情報テーブル中、接続相手となるＲＴＣクライアントが属する末端中継装置に関する接続数を参照して、接続の可否を判断するように更新され、かつ、前記状態情報処理手段が、前記接続の可否の判断の結果、接続が可能である場合に、前記状態情報テーブル中、前記接続相手となるＲＴＣクライアントが属する末端中継装置に関する接続数を更新するように構成されている。

また、好ましい実施態様においては、前記第２のパラメータ群が、ＲＴＣクライアントにおけるパケット遅延時間の揺らぎであるジッタ値、パケットロス数および／または往復遅延時間を含み、前記状態情報処理手段が、前記ジッタ値の統計値、パケットロス数の統計値、および／または往復遅延時間の統計値を更新するように構成されている。

さらに好ましい実施態様においては、前記状態情報処理手段が、前記ジッタ値の統計値、パケットロス数の統計値、および／または往復遅延時間の統計値に基づくＱｏＳ値を更新するように構成され、かつ、前記判断手段が、前記ＱｏＳ値を参照するように構成されている。

また、好ましい実施態様においては、前記判断手段が、参照された項目と、当該項目のそれぞれの閾値を格納した接続制限情報テーブル中の閾値とを比較するように構成されている。

なお、本明細書において、接続要求には発呼要求を含む。この場合に、接続要求にかかるＲＴＣクライアントは発呼元となり、接続相手となるＲＴＣクライアントは着呼先となる。

本発明によれば、それぞれのＡＰの状態を考慮して、個別に適切に登録や接続を規制することができるデータ通信方法、呼制御装置、呼制御プログラムを提供することが可能となる。

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

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

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

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

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

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

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

ＱｏＳ情報送信処理部４０は、呼制御装置１２のＱｏＳ情報送信処理部２０に対して、現在接続中のＲＴＣに関するＱｏＳ情報（第２のパラメータ群）を送信する。このＱｏＳ情報は、パケット遅延時間の揺らぎ（パケット到着間隔の揺らぎ：ジッタ値）、パケットロス数、往復遅延時間（ＲＴＴ）などを含む。

たとえば、ＱｏＳ情報送信処理部４０は、ＲＴＰ（ＲＦＣ１８８９）で定義されているＲＴＣＰのＲＲ（Ｒｅｃｅｉｖｅｒ Ｒｅｐｏｒｔ）、ＳＲ（Ｓｅｎｄｅｒ Ｒｅｐｏｒｔ）を利用することで実装できる。なお、本来、ＲＴＣＰパケットは、通信相手のみ、または、マルチキャストで送信されるので、呼制御装置１２に対して同じパケットを送信させるように構成する必要がある。なお、呼制御装置１２のＩＰアドレスは、ＲＴＣに予め設定されているので、新たにそのアドレスを取得する手段を考慮する必要は無い。

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

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

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

メディア転送部４４は、メディアストリームを送受信し、メディアごとのＣＯＤＥＣ処理やパケット送受信処理を実行する。

ＱｏＳ情報受信処理部２０は、ＱｏＳ情報送信処理部４０からのＱｏＳ情報（第２のパラメータ群）を受信して、ＡＰ状態情報処理部２４に、以下のデータの組を通知する。

（クライアントＩＤ、ジッタ値、パケットロス数、往復遅延時間（ＲＴＴ））
登録処理部２２は、ＲＴＣクライアント１６の登録処理および登録解除処理を実行する。登録処理部２２は、ＡＰ状態情報テーブル３０を作成、更新するとともに、呼制御処理部２６と協働して、ＡＰ状態情報テーブル３０および接続制限情報テーブル３２を参照して、ＲＴＣクライアント１６の登録の可否を判断する。

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

ＲＴＣ登録数は、現在、ＡＰ＿ＩＤで特定されるＡＰにおいて登録されているＲＴＣクライアントの数を示す。ＲＴＣ接続数は、現在、リアルタイム通信中のＲＴＣクライアントの数を示す。ジッタ統計値は、ＡＰ＿ＩＤで特定されるＡＰごとに、当該ＡＰに登録しているＲＴＣクライアントからの第２のパラメータ群中のジッタ値を平均化したものである。同様に、ロス統計値、ＲＴＴ統計値も、それぞれ、パケットロス数、往復遅延時間を平均化したものである。また、本実施の形態においては、ＱｏＳ値として、上記ジッタ統計値、ロス統計値およびＲＴＴ統計値に基づき算出されたＲ値を用いている。無論、ＱｏＳ値として他の値、たとえば、ＭＯＳ（Ｍｅａｎ
Ｏｐｉｎｉｏｎ Ｓｃｏｒｅ）値を利用しても良い。

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

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

接続制限情報テーブル４１０は、予め、ＡＰごと個別に又は複数のＡＰに一律に値を決定しておき、ＤＢ２８に格納される。また、ＡＰ状態情報テーブル３０は、ＡＰ状態情報処理部２４がＱｏＳ情報（第２のパラメータ群）を受信することに応答して、ＡＰ状態情報処理部２４により更新される。

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

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

呼制御処理部２６が、ＲＴＣクライアントからのメッセージを受信すると（ステップ６０１）、受信したことを示す通知を受けた登録処理部２２は、当該メッセージが登録要求であるか、登録解除であるかを判断する。登録解除の必要が無い場合（ステップ６０２でノー(No)）、つまり、登録要求である場合には、登録処理部２２は、受信したメッセージに含まれる第１のパラメータ群および登録位置情報テーブルを参照して、ＲＴＣクライアントが接続中であるかどうかを判断する（ステップ６０３）。ステップ６０３でノー(No)と判断された場合には、登録処理部２２は、第１のパラメータ群中のＡＰ＿ＩＤから、当該ＲＴＣクライアントが属するＡＰについてのＡＰ状態情報テーブルおよび接続制限情報テーブルのレコードを、それぞれ特定し、当該レコード中の値を参照する（ステップ６０４）。次いで、登録処理部２２は、ＲＴＣ登録数とＲＴＣ登録数制限値、ＲＴＣ接続数とＲＴＣ接続数制限値、ＱｏＳ値とＱｏＳ値制限値を、それぞれ比較し、ＲＴＣ登録数がＲＴＣ登録数制限値より小さく（ｃｖ＿ｒ＜ｓｖ＿ｒ）、ＲＴＣ接続数がＲＴＣ接続数制限値より小さく（ｃｖ＿ｃ＜ｓｖ＿ｃ）、かつ、ＱｏＳ値が、ＱｏＳ値制限値より大きい（ｃｖ＿ｑｏｓ＞ｓｖ＿ｑｏｓ）場合に（ステップ６０５でイエス(Yes)）、当該ＲＴＣクライアントの登録が可能と判断する。したがって、登録処理部２６はＡＰ状態情報処理部２４にＡＰ状態情報テーブルの更新を指示するとともに、ＡＰ状態情報処理部２４に、第１のパラメータ群を登録情報として与える。

図８および図９は、ＡＰ状態情報処理部２４にて実行される処理を示すフローチャートである。ＡＰ状態情報処理部２４は、ＱｏＳ情報受信処理部２０、登録処理部２２、呼制御処理部２６からの指示があるまで待機状態となっている（ステップ８０１）。上記３種類のいずれかの処理部からの指示があると、指示の内容を判断して、指示を出した処理部に対応した所定の処理を実行する。上述した場合には、ＡＰ状態情報処理部２４は、登録情報を受信し（図９のステップ９０１）、指示が削除指令であるか否かを判断する（ステップ９０２）。上記場合は登録の指示であるため、ステップ９０２においてノー(No)と判断される。ＡＰ状態情報処理部２４は、ＡＰ状態情報テーブルの該当レコードの、登録ＲＴＣリスト（ｃｖ＿ｌｉｓｔ）に、新規に登録するＲＴＣクライアントのクライアントＩＤを追加するとともに、当該レコードのＲＴＣ登録数を「１」だけ増やす（図６のステップ６０６、図９のステップ９０３）。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

次に、ＡＰ状態情報処理部２４によるＱｏＳ情報に関する処理について説明する。前述したように、ＲＴＣクライアントのＱｏＳ情報送信処理部４０から、呼制御装置１２のＱｏＳ情報受信処理部２０に対して、ＱｏＳ情報（第２のパラメータ群）が送信され、呼制御装置１２において、ＡＰ状態情報処理部２４には、（クライアントＩＤ、ジッタ値、パケットロス数、往復遅延時間（ＲＴＴ））というデータの組が通知される。

ＡＰ状態情報処理部２４は、ＱｏＳ情報として上記データの組を受信すると（ステップ８０６）、ＡＰ状態情報テーブル中、当該ＲＴＣクライアントが属するＡＰのＡＰ＿ＩＤを有するレコードを検索する（ステップ８０７）。次いで、ＡＰ状態情報処理部２４は、受信したデータの組中の、ジッタ値、パケットロス数、往復遅延時間（ＲＴＴ）に基づいて、レコード中のジッタ統計値、ロス統計値、ＲＴＴ統計値を更新する。つまり、新たなジッタ値、パケットロス数、往復遅延時間（ＲＴＴ）を考慮して、統計値（たとえば平均値）を再度算出すればよい。また、これらの統計値の変更に伴って、ＱｏＳ値も再度算出される。ＡＰ状態情報処理部２４は、算出されたＱｏＳ値、ジッタ統計値、ロス統計値、ＲＴＴ統計値をレコードに格納する（ステップ８０８）。

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

このように、本実施の形態によれば、ＡＰ状態情報テーブル中のＱｏＳに関する値を、適宜変更することで、最適な呼制御を実現可能としている。

次に、本発明の第２の実施の形態について説明する。第１の実施の形態においては、登録情報（第１のパラメータ群）をＲＴＣクライアントから取得している。第２の実施の形態においては、認証サーバやＤＨＣＰ（Ｄｙｎａｍｉｃ Ｈｏｓｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）サーバから登録情報を取得する。

図１０は、第２の実施の形態にかかる呼制御装置１１２の構成を示すブロックダイヤグラムである。なお、図１０において、図１に示す第１の実施の形態と同一の部材には同一の符号を付している。図１０に示すように、呼制御装置１１２は、ＱｏＳ情報受信処理部２０、登録処理部２２、ＡＰ所歌情報処理部２４、呼制御処理部２６、ＤＢ２８のほか、認証情報取得部１１４およびＤＨＣＰ情報取得部１１６を有している。

認証情報取得部１１４は、ネットワークを介して認証サーバ（図示せず）とデータ通信する。またＤＨＣＰ情報取得部１１６は、ネットワークを介してＤＨＣＰサーバ（図示せず）とデータ通信する。

ＩＥＥＥ８０２．１Ｘにて利用される認証サーバ（主としてＲａｄｉｕｓサーバ）では、ＲＴＣクライアントのＭＡＣアドレスと、そのＲＴＣクライアントが属するＡＰとの対応が把握されている。また、ＤＨＣＰサーバでは、ＲＴＣクライアントのＭＡＣアドレスとＩＰアドレスとの対応を把握しているので、ｓｙｓｌｏｇ等を利用してこれらの情報を取得することにより、呼制御装置１１２は、登録を要求したＲＴＣクライアントのＩＰアドレスをキーとして、そのＲＴＣクライアントが属するＡＰ＿ＩＤを対応付けることが可能となる。なお、ＤＨＣＰを利用しない場合であっても、ＲＴＣクライアントのＩＰアドレスとＭＡＣアドレスとの対応情報を呼制御装置が参照できれば良い。なお、ＲＴＣクライアントの移動時に、第２の実施の形態においては、その移動に伴って、認証サーバおよびＤＨＣＰサーバからｓｙｓｌｏｇ等により、上述した情報が呼制御装置１１２に通知されるようになっている。したがって、ＡＰ状態情報テーブル３０中、移動元のＡＰや移動先のＡＰに関するレコードの更新、登録位置情報テーブルの更新が実現可能である。

次に、本実施例の第３の実施の態様について説明する。第１の実施の形態においては、登録情報をＲＴＣクライアントから、第２の実施の形態においては、認証サーバやＤＨＣＰサーバから、登録情報を取得している。第３の実施の形態においては、ＡＰからこのような情報を取得している。

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

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

たとえば、前記実施の形態においては、ＱｏＳ情報（第２のパラメータ群）をＲＴＣクライアントが、呼制御装置に対して送信しているがこのような構成に限定されるものではなく、ＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｃｏｔｏｌ）についてＩＥＴＦで提案されているＲＴＰ−ＭＩＢ（ＲＦＣ２９５９：Ｒｅａｌ−Ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ Ｍａｎａｇｅｍｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｂａｓｅ）を利用して、ＡＰ或いはＲＴＣクライアントからＱｏＳ情報を取得するように構成しても良い。

また、前記実施の形態において、ＲＴＣクライアントの登録の際に、ＡＰ状態情報テーブルにおいて、ＲＴＣ登録数、ＲＴＣ接続数、および、ＱｏＳ値を、接続制限情報テーブルの制限値を比較しているが、これに限定されるものではなく、ＲＴＣ登録数およびＱｏＳ値のみを考慮しても良い。

また、本発明を、無線ＬＡＮ環境だけでなく、ＲＴＣクライアントが有線でエッジルータに接続されるような環境においても適用することが可能である。

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

また、前記実施の形態においては、登録の可否を判断するために、ＲＴＣ登録数（ｃｖ＿ｒ）とＲＴＣ登録数制限値（ｓｖ＿ｒ）とを比較するとともに、ＲＴＣ接続数（ｃｖ＿ｃ）とＲＴＣ接続数制限値（ｓｖ＿ｃ）とを比較しているが（図６のステップ６０５参照）、これに限定されず、たとえば、ＲＴＣ登録数（ｃｖ＿ｒ）とＲＴＣ登録数制限値（ｓｖ＿ｒ）とを比較するように構成しても良い。

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

符号の説明

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

Claims (21)

1. リアルタイム通信するリアルタイム通信クライアント（ＲＴＣクライアント）と、当該ＲＴＣクライアントと接続される末端中継装置と、を含むネットワーク環境において、前記ＲＴＣクライアントの呼を制御する呼制御方法であって、
   ネットワークおよび前記末端中継装置を介して、ＲＴＣクライアントとデータ通信可能な呼制御装置において、
   前記ネットワークを介して、ＲＴＣクライアントを特定する情報および当該ＲＴＣクライアントの属する末端中継装置の情報を含む第１のパラメータ群を受信するステップと、
   前記ＲＴＣクライアントにおけるＱｏＳに関する情報を含む第２のパラメータ群を受信するステップと、
   前記第２のパラメータ群にしたがって、前記ＲＴＣクライアントが属する末端中継装置ごとのＱｏＳに関する情報を記憶した状態情報テーブルを更新するステップと、
   前記ＲＴＣクライアントによる登録要求、或いは、接続要求を受信したときに、前記第１のパラメータ群に基づき、ＲＴＣクライアントおよび当該ＲＴＣクライアントが属する末端中継装置を特定し、かつ、前記状態情報テーブルを参照して、前記ＲＴＣクライアントが属する末端中継装置のＱｏＳに関する情報を参照して、登録の可否或いは接続の可否を判断するステップと、を備えたことを特徴とする呼制御方法。
2. 前記状態情報テーブルが、項目として、末端中継装置ごとの、ＲＴＣクライアントの登録数を含み、
   前記登録の可否を判断するステップが、前記状態情報テーブル中、前記ＲＴＣクライアントが属する末端中継装置に関する登録数を参照して、当該登録の可否を判断するステップを含み、
   かつ、前記登録の可否の判断の結果、登録が可能である場合に、前記状態情報テーブル中、前記ＲＴＣクライアントが属する末端中継装置に関する登録数を更新するステップを備えたことを特徴とする請求項１に記載の方法。
3. 前記状態情報テーブルが、項目として、末端中継装置ごとの、ＲＴＣクライアントの接続数を含み、
   前記接続の可否を判断するステップが、前記状態情報テーブル中、前記ＲＴＣクライアントが属する末端中継装置に関する接続数を参照して、当該接続の可否を判断するステップを含み、
   さらに、前記接続の可否の判断の結果、接続が可能である場合に、前記状態情報テーブル中、前記ＲＴＣクライアントが属する末端中継装置に関する接続数を更新するステップを備えたことを特徴とする請求項１または２に記載の方法。
4. 前記接続の可否を判断するステップが、前記状態情報テーブル中、接続相手となるＲＴＣクライアントが属する末端中継装置に関する接続数を参照して、接続の可否を判断するステップを含み、
   さらに、前記接続の可否の判断の結果、接続が可能である場合に、前記状態情報テーブル中、前記接続相手となるＲＴＣクライアントが属する末端中継装置に関する接続数を更新するステップを備えたことを特徴とする請求項３に記載の方法。
5. 前記第２のパラメータ群が、ＲＴＣクライアントにおけるパケット遅延時間の揺らぎであるジッタ値、パケットロス数および／または往復遅延時間を含み、
   前記状態情報テーブルを更新するステップが、前記ジッタ値の統計値、パケットロス数の統計値、および／または往復遅延時間の統計値を更新するステップを含むことを特徴とする請求項１ないし４の何れか一項に記載の方法。
6. 前記状態情報テーブルを更新するステップが、前記ジッタ値の統計値、パケットロス数の統計値、および／または、往復遅延時間の統計値に基づくＱｏＳ値を更新するステップを含み、
   前記登録の可否或いは接続の可否を判断するステップが、前記ＱｏＳ値を参照するステップを含むことを特徴とする請求項５に記載の方法。
7. 前記登録の可否或いは接続の可否を判断するステップが、参照された項目と、当該項目のそれぞれの閾値を格納した接続制限情報テーブル中の閾値とを比較するステップを含むことを特徴とする請求項１ないし６の何れか一項に記載の方法。
8. 前記ＲＴＣクライアントにおいて、登録要求の際に、前記第１のパラメータ群を送信するステップを備え、
   前記呼制御装置において、前記ＲＴＣクライアントから送信された前記第１のパラメータ群を受信することを特徴とする請求項１に記載の方法。
9. 前記ＲＴＣクライアントを認証する認証サーバ、および、ＤＨＣＰ（Ｄｙｎａｍｉｃ Ｈｏｓｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）サーバから取得された情報に基づき、前記呼制御装置において、前記第１のパラメータ群を構成することを特徴とする請求項１に記載の方法。
10. 前記呼制御装置において、前記ＲＴＣクライアントが属する末端中継装置から前記第１のパラメータ群を取得することを特徴とする請求項１に記載の方法。
11. 前記ＲＴＣクライアントにおいて、前記第２のパラメータ群を送信するステップを備え、
    前記呼制御装置において、前記ＲＴＣクライアントから送信された前記第２のパラメータ群を受信することを特徴とする請求項１に記載の方法。
12. 前記呼制御装置において、前記末端中継装置から、ＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｃｏｔｏｌ）を利用した前記第２のパラメータ群を取得することを特徴とする請求項１に記載の方法。
13. リアルタイム通信するリアルタイム通信クライアント（ＲＴＣクライアント）と、当該ＲＴＣクライアントと有線にて接続される有線用末端中継装置と、を含む有線ネットワーク環境において、前記ＲＴＣクライアントの呼を制御する呼制御方法であって、
    前記ネットワークおよび前記有線用末端中継装置を介して、ＲＴＣクライアントとデータ通信可能な呼制御装置において、
    前記ネットワークを介して、ＲＴＣクライアントを特定する情報および当該ＲＴＣクライアントの属する有線用末端中継装置の情報を含む第１のパラメータ群を受信するステップと、
    前記ＲＴＣクライアントにおけるＱｏＳに関する情報を含む第２のパラメータ群を受信するステップと、
    前記第２のパラメータ群にしたがって、前記ＲＴＣクライアントが属する有線用末端中継装置ごとのＱｏＳに関する情報を記憶した状態情報テーブルを更新するステップと、
    前記ＲＴＣクライアントによる登録要求、或いは、接続要求を受信したときに、前記第１のパラメータ群に基づき、ＲＴＣクライアントおよび当該ＲＴＣクライアントが属する有線用末端中継装置を特定し、かつ、前記状態情報テーブルを参照して、前記ＲＴＣクライアントが属する有線用末端中継装置のＱｏＳに関する情報を参照して、登録の可否或いは接続の可否を判断するステップと、を備えたことを特徴とする呼制御方法。
14. リアルタイム通信するリアルタイム通信クライアント（ＲＴＣクライアント）と、当該ＲＴＣクライアントと接続される末端中継装置と、を含むネットワーク環境において、ネットワークおよび前記末端中継装置を介して、ＲＴＣクライアントとデータ通信可能な呼制御装置であって、
    前記ネットワークを介して、ＲＴＣクライアントを特定する情報および当該ＲＴＣクライアントの属する末端中継装置の情報を含む第１のパラメータ群を受信する第１の受信手段と、
    前記ＲＴＣクライアントにおけるＱｏＳに関する情報を含む第２のパラメータ群を受信する第２の受信手段と、
    前記第２の受信手段による第２のパラメータ群にしたがって、前記ＲＴＣクライアントが属する末端中継装置ごとのＱｏＳに関する情報を記憶した状態情報テーブルを更新する状態情報処理手段と、
    前記ＲＴＣクライアントによる登録要求、或いは、接続要求を受信したときに、前記第１のパラメータ群に基づき、ＲＴＣクライアントおよび当該ＲＴＣクライアントが属する末端中継装置を特定し、かつ、前記状態情報テーブルを参照して、前記ＲＴＣクライアントが属する末端中継装置のＱｏＳに関する情報を参照して、登録の可否或いは接続の可否を判断する判断手段と、を備えたことを特徴とする呼制御装置。
15. 前記状態情報テーブルが、項目として、末端中継装置ごとの、ＲＴＣクライアントの登録数を含み、
    前記判断手段が、前記状態情報テーブル中、前記ＲＴＣクライアントが属する末端中継装置に関する登録数を参照して、当該登録の可否を判断するように構成され、かつ、
    前記状態情報処理手段が、前記登録の可否の判断の結果、登録が可能である場合に、前記状態情報テーブル中、前記ＲＴＣクライアントが属する末端中継装置に関する登録数を更新するように構成されたことを特徴とする請求項１４に記載の呼制御装置。
16. 前記状態情報テーブルが、項目として、末端中継装置ごとの、ＲＴＣクライアントの接続数を含み、
    前記判断手段が、前記状態情報テーブル中、前記ＲＴＣクライアントが属する末端中継装置に関する接続数を参照して、当該接続の可否を判断するように構成され、かつ、
    前記状態情報処理手段が、前記接続の可否の判断の結果、接続が可能である場合に、前記状態情報テーブル中、前記ＲＴＣクライアントが属する末端中継装置に関する接続数を更新するように構成されたことを特徴とする請求項１４または１５に記載の呼制御装置。
17. 前記判断手段が、前記状態情報テーブル中、接続相手となるＲＴＣクライアントが属する末端中継装置に関する接続数を参照して、接続の可否を判断するように更新され、かつ、
    前記状態情報処理手段が、前記接続の可否の判断の結果、接続が可能である場合に、前記状態情報テーブル中、前記接続相手となるＲＴＣクライアントが属する末端中継装置に関する接続数を更新するように構成されたことを特徴とする請求項１６に記載の呼制御装置。
18. 前記第２のパラメータ群が、ＲＴＣクライアントにおけるパケット遅延時間の揺らぎであるジッタ値、パケットロス数および／または往復遅延時間を含み、
    前記状態情報処理手段が、前記ジッタ値の統計値、パケットロス数の統計値、および／または往復遅延時間の統計値を更新するように構成されたことを特徴とする請求項１４ないし１７の何れか一項に記載の呼制御装置。
19. 前記状態情報処理手段が、前記ジッタ値の統計値、パケットロス数の統計値、および／または、往復遅延時間の統計値に基づくＱｏＳ値を更新するように構成され、かつ、
    前記判断手段が、前記ＱｏＳ値を参照するように構成されたことを特徴とする請求項１８に記載の呼制御装置。
20. 前記判断手段が、参照された項目と、当該項目のそれぞれの閾値を格納した接続制限情報テーブル中の閾値とを比較するように構成されたことを特徴とする請求項１４ないし１９の何れか一項に記載の呼制御装置。
21. リアルタイム通信するリアルタイム通信クライアント（ＲＴＣクライアント）と、当該ＲＴＣクライアントと有線にて接続される有線用末端中継装置と、を含むネットワーク環境において、ネットワークおよび前記有線用末端中継装置を介して、ＲＴＣクライアントとデータ通信可能な呼制御装置であって、
    前記ネットワークを介して、ＲＴＣクライアントを特定する情報および当該ＲＴＣクライアントの属する有線用末端中継装置の情報を含む第１のパラメータ群を受信する第１の受信手段と、
    前記ＲＴＣクライアントにおけるＱｏＳに関する情報を含む第２のパラメータ群を受信する第２の受信手段と、
    前記第２の受信手段による第２のパラメータ群にしたがって、前記ＲＴＣクライアントが属する有線用末端中継装置ごとのＱｏＳに関する情報を記憶した状態情報テーブルを更新する状態情報処理手段と、
    前記ＲＴＣクライアントによる登録要求、或いは、接続要求を受信したときに、前記第１のパラメータ群に基づき、ＲＴＣクライアントおよび当該ＲＴＣクライアントが属する有線用末端中継装置を特定し、かつ、前記状態情報テーブルを参照して、前記ＲＴＣクライアントが属する有線用末端中継装置のＱｏＳに関する情報を参照して、登録の可否或いは接続の可否を判断する判断手段と、を備えたことを特徴とする呼制御装置。

Images