JP4503526B2 - 呼制御方法および呼制御システム - Google Patents

Description

本発明は、着呼側の処理量を緩和する呼制御方法および呼制御システムに関する。

従来の電話交換機は、各エリアの加入者を収容し、その加入者を収容している交換機に搭載されたＣＰＵを使って呼を接続する処理を行っていたため、災害発生などによって特定の交換機に着信が集中、あるいは発信呼数が増えると、該交換機が過負荷状態になっていた。

また、ＩＰネットワークを利用した電話系サービス（以下、ＶｏＩＰ）のシステムにおいては、加入者をＩＰネットワークに収容する装置（以下、エッジノード）と、呼を制御する装置であるコールエージェントＣＡ（以下、ノード）が分離されているため、ノードが制御する加入者はエッジノードが収容する加入者と独立である（例えば非特許文献１参照）が、加入者データの配置や、エッジノードの制御との関連などから、多くの場合においては、ある加入者の接続処理を行うノードは固定的であった。このため、災害発生などによる想定外のトラヒックが加わる状況になっても、即座にノード間でのロードバランスを行うことは困難であった。

このため従来の技術では、例えば、地震等の災害が発生した場合には、地震直後、県外から震災地域の住民への安否の確認のための電話が殺到し、特定の交換機あるいはノードに呼が集中することにより、震災地域の通信機器が輻輳を起こし、通信の疎通率が著しく低下する輻輳状態が発生してしまう場合がある。また、輻輳をそのまま放置しておくと、県外からの電話が繋がりにくいため再ダイヤルが増加し更なる輻輳が発生することもある。
ＲＦＣ２５４３"ＳＩＰ：Session Initiation Protocol"(１９９９ ＩＥＴＦ) １．４．２Ｌｏｃａｔｉｎｇ ａ ＳＩＰ Ｓｅｒｖｅｒおよび１．４．５Ｌｏｃａｔｉｎｇ ａ Ｕｓｅｒ

本発明は、このような事情に鑑みてなされたもので、その目的は、着呼側の処理量を緩和する呼制御方法および呼制御システムを提供することにある。

この発明は上述した課題を解決するためになされたものであり、請求項１に記載の発明は、複数の端末の呼処理に関する情報を保持するデータベースと、前記端末の呼の制御を行う呼制御装置と、前記端末を収容する収容装置とが、ネットワークを介して互いに接続される呼制御システムにおいて用いられる呼制御方法において、前記複数の呼制御装置が、輻輳を生じた呼制御装置を特定する呼制御装置情報を保持しており、呼を着呼側端末に送信する場合に、前記保持した呼制御装置情報に前記着呼側端末が収容される着呼側呼制御装置が含まれるか否かを判定し、前記着呼側呼制御装置が前記保持した呼制御装置情報に含まれる場合には、前記着呼側端末を収容する着呼側データベースにアクセスし前記着呼側端末の呼処理に関する情報を取得し、前記取得した情報に基づいて、前記着呼側端末への呼制御を行い、前記呼制御装置は、自身の呼制御装置を指定する情報と前記呼制御装置情報を比較し、自身の呼制御装置を指定する情報が前記呼制御装置情報に含まれる場合には、自身の呼制御装置と関連して端末の呼の処理を行っている収容装置のアクセス制限の解除を行う、ことを特徴とする呼制御方法である。

請求項２に記載の発明は、複数の端末の呼処理に関する情報を保持するデータベースと、前記端末の呼の制御を行う呼制御装置と、前記端末を収容する収容装置とが、ネットワークを介して互いに接続される呼制御システムにおいて用いられる呼制御方法において、前記複数の呼制御装置が、輻輳を生じた呼制御装置を特定する呼制御装置情報を保持しており、呼を着呼側端末に送信する場合に、前記保持した呼制御装置情報に前記着呼側端末が収容される着呼側呼制御装置が含まれるか否かを判定し、前記着呼側呼制御装置が前記保持した呼制御装置情報に含まれる場合には、前記着呼側端末を収容する着呼側データベースにアクセスし前記着呼側端末の呼処理に関する情報を取得し、前記取得した情報に基づいて、前記着呼側端末への呼制御を行い、前記呼制御装置は、自身の呼制御装置を指定する情報と前記呼制御装置情報を比較し、自身の呼制御装置を指定する情報が前記呼制御装置情報に含まれる場合には、自身の呼制御装置と関連して端末の呼の処理を行っている収容装置のアクセス処理を自身以外の呼制御装置からも制御ができるようにし、呼を着呼側端末に送信する場合に、前記保持した呼制御装置情報に前記着呼側端末が収容される着呼側呼制御装置が含まれるか否かを判定し、前記着呼側呼制御装置が前記保持した呼制御装置情報に含まれる場合には、前記着呼側端末を収容する着呼側データベースにアクセスし前記着呼側端末の呼処理に関する情報を取得し、前記着呼側端末に関わる収容装置とのアクセス制御を行い、前記着呼側端末への呼制御を行う、ことを特徴とする呼制御方法である。

請求項３に記載の発明は、請求項１または請求項２に記載の呼制御方法において、前記呼制御装置は、前記着呼側呼制御装置が前記保持した呼制御装置情報に含まれる場合には、前記着呼側端末を収容する着呼側データベースにアクセスし前記着呼側端末の呼処理に関する情報を取得し、付加サービス提供の可否判定を行い、前記可否判定が否の場合には要求された付加サービスを拒否し、可の場合には前記取得した情報に基づいて、前記着呼側端末への呼制御を行うこと、を特徴とする。

請求項４に記載の発明は、請求項１から３のうちいずれか１項に記載の呼制御方法において、前記呼制御システムは、更にネットワーク管理手段を含み、前記ネットワーク管理手段が、複数の呼制御装置の輻輳状態または故障状態を監視し、または、前記呼制御装置から輻輳または故障の状態を示す信号を受信し、前記呼制御装置の輻輳または故障を判断し、いずれかの呼制御装置が輻輳または故障を生じた場合には、前記呼制御装置へ、輻輳または故障を生じた呼制御装置を特定する呼制御装置情報として通知し、前記呼制御装置は、更に前記通知された呼制御装置情報を保持することを特徴とする。

請求項５に記載の発明は、請求項１から４のうちいずれか１項に記載の呼制御方法において、前記呼制御装置は、前記着呼側呼制御装置が前記保持した呼制御装置情報に含まれる場合には、自身の呼制御装置および前記着呼側端末が収容される着呼側呼制御装置以外の第三の呼制御装置を選択し、前記第三の呼制御装置へ呼を転送すること、を特徴とする。

請求項６に記載の発明は、複数の端末の呼処理に関する情報を保持するデータベースと、前記端末の呼の制御を行う呼制御装置と、前記端末を収容する収容装置とが、ネットワークを介して互いに接続される呼制御システムにおいて、前記複数の呼制御装置が、輻輳を生じた呼制御装置を特定する呼制御装置情報を保持する手段と、呼を着呼側端末に送信する場合に、前記保持した呼制御装置情報に前記着呼側端末が収容される着呼側呼制御装置が含まれるか否かを判定する手段と、前記着呼側呼制御装置が前記保持した呼制御装置情報に含まれる場合には、前記着呼側端末を収容する着呼側データベースにアクセスし前記着呼側端末の呼処理に関する情報を取得する手段と、前記取得した情報に基づいて、前記着呼側端末への呼制御を行う手段と、自身の呼制御装置を指定する情報と前記呼制御装置情報を比較し、自身の呼制御装置を指定する情報が前記呼制御装置情報に含まれる場合には、自身の呼制御装置と関連して端末の呼の処理を行っている収容装置のアクセス制限の解除を行う手段とを含む、こと特徴とする呼制御システムである。

請求項７に記載の発明は、複数の端末の呼処理に関する情報を保持するデータベースと、前記端末の呼の制御を行う呼制御装置と、前記端末を収容する収容装置とが、ネットワークを介して互いに接続される呼制御システムにおいて、前記複数の呼制御装置が、輻輳を生じた呼制御装置を特定する呼制御装置情報を保持する手段と、呼を着呼側端末に送信する場合に、前記保持した呼制御装置情報に前記着呼側端末が収容される着呼側呼制御装置が含まれるか否かを判定する手段と、前記着呼側呼制御装置が前記保持した呼制御装置情報に含まれる場合には、前記着呼側端末を収容する着呼側データベースにアクセスし前記着呼側端末の呼処理に関する情報を取得する手段と、前記取得した情報に基づいて、前記着呼側端末への呼制御を行う手段と、自身の呼制御装置を指定する情報と前記呼制御装置情報を比較し、自身の呼制御装置を指定する情報が前記呼制御装置情報に含まれる場合には、自身の呼制御装置と関連して端末の呼の処理を行っている収容装置のアクセス処理を自身以外の呼制御装置からも制御ができるようにし、呼を着呼側端末に送信する場合に、前記保持した呼制御装置情報に前記着呼側端末が収容される着呼側呼制御装置が含まれるか否かを判定し、前記着呼側呼制御装置が前記保持した呼制御装置情報に含まれる場合には、前記着呼側端末を収容する着呼側データベースにアクセスし前記着呼側端末の呼処理に関する情報を取得し、前記着呼側端末に関わる収容装置とのアクセス制御を行い、前記着呼側端末への呼制御を行う手段とを含む、こと特徴とする呼制御システムである。

この発明によれば、着呼側が輻輳となった場合、他のノード（発呼ノード）により着呼側のノードの処理が代行され、着信側のノードの負荷が緩和されるので、着呼側が輻輳時における着呼側の疎通率を改善することができる。

また、請求項２の発明によれば、着呼側が輻輳となった場合、着呼側への要求された付加サービスを拒否することにより、複雑な処理を軽減でき、着呼側が輻輳時における着呼側の疎通率を改善することができる。また、発呼側ノードおよび着呼側ノードにおける複雑な処理を軽減できる。

また、請求項３の発明によれば、着呼側ノードと着呼側エッジノードの間でアクセス制御がなされている場合であっても、着呼側が輻輳となった場合、着呼側ノードがアクセス制御を解除し着呼側のアクセス制御を行わないようにすることにより、着呼側が輻輳時における着呼側の疎通率を改善することができる。また、着呼側ノードが着呼側エッジノードのアクセス制御を解除することにより、適切な呼制御を行うことができるようになる。

また、請求項４の発明によれば、着呼側ノードと着呼側エッジノードの間でアクセス制御がなされている場合であっても、着呼側が輻輳となった場合、着呼側のノードが着呼側エッジノードのアクセス制御を発呼側ノードから代行することを許容し、発呼側のノードが着呼側のエッジノードとの間のアクセス制御を代行することにより、着呼側にアクセス制御がある場合においても、着呼側が輻輳時における着呼側の疎通率を改善することができる。また、発呼側ノードが着呼側エッジノードのアクセス制御を代行することにより、適切な呼制御を行うことができるようになる。

また、請求項５の発明によれば、ネットワーク管理手段により特定のノードの輻輳または故障が各ノードに通知され、各ノードが輻輳または故障した特定のノードに関する情報を保持することにより、着呼側が輻輳時における着呼側の疎通率を改善することができる。

また、請求項６の発明によれば、着呼側が輻輳となった場合、自身の呼制御装置および着呼側端末が収容される着呼側呼制御装置以外の第三の呼制御装置へ呼を転送することにより、着呼側が輻輳時における着呼側の疎通率を改善することができる。

また、請求項７の発明によれば、着呼側が輻輳となった場合、他のノード（発呼ノード）により着呼側のノードの処理が代行され、着信側のノードの負荷が緩和されるので、着呼側が輻輳時における着呼側の疎通率を改善することができる。

最初に、実施の形態の概要を説明する。
例えば、ＶｏＩＰの場合において、ユーザは電話をかける操作として電話番号をダイヤルする。ＶｏＩＰにおいてはダイヤルされた電話番号はＩＰアドレスで認識される必要があり、電話番号からＩＰアドレスへの変換が必要になる。
大規模なネットワークでは、この変換のためにデータベースを用いており、電話番号を基に該当するデータベースへ問い合わせることにより相手先のＩＰアドレスへＶｏＩＰとして電話をかけることになる。
以上のようにして（ノードと加入者データベースを用いて）呼の経路を設立し、その後、ノードとエッジノード（呼制御機器）により通話が行われる。
呼制御については、ＳＩＰであっても、Ｈ．３２３でもＭＧＣＰでも基本的には同じである。

このようなＶｏＩＰにおいて、例えば、災害が発生した場合には、被災エリアの加入者を処理するノードへの呼の集中が発生し、そのノードは処理能力を超えた状態になる。結果、加入者データベースには余裕があったとしても、処理能力を超えたそのノードが加入者データベースにアクセスすることが困難となり、そのノードおよびそのノードと関連した加入者データベースに収容された端末の加入者への呼の疎通が不可能となる。このような状態を解決するには、処理が集中しているノードの処理を他のノードが実行する必要がある。
そこで、本実施形態は、前記ＶｏＩＰシステムのエッジノードとノードに見られるように、加入者収容装置と呼制御を行う装置が分離されたシステムに適用され、処理が特定のノードに集中した場合、処理に余裕のある他のノード（発呼側のノード）で処理を代行する。
また、処理の代行中においては、音声品質を低下させ一部サービスの提供を見合わせるなどの処理を行い、サービス品質を低下させても呼の疎通を優先し、効率的な接続処理を実行する。

以下、図面を参照して、この発明の実施の形態について説明する。図１から図９において同じ番号によって示される構成要素は、全て同じ構成要素を示す。
図１は、この発明の第一の実施の形態による呼制御方法を適用した呼制御システムの構成を示すブロック図である。
この図１では、特定のノードに負荷が集中していない通常時のシステム状態を示している。この図において、１は呼制御を行うノード３に収容される端末であり、発端末１−１に関する制御は発ノード３−１の発側制御４−１で、着端末１−２に関する制御は着ノードの着側制御４−２で実施される。呼制御を行うために必要になる加入者の契約情報などは加入者データ５に保持されており、発側制御４−１は発端末の加入者データ５−１を、着側制御４−２は着端末の加入者データ５−２を参照する。また、エッジノード２、発ノード３および加入者データ５はそれぞれネットワーク９を介して通信を行う。

第一の実施の形態における各ノード３はＮＷ管理手段により、その輻輳状態を監視している。ＮＷ管理手段は、ノードからの通知によりノードの輻輳状態を含む情報を取得し、または、ＮＷ管理手段がノードをポーリングすることによりノードの輻輳状態を含む情報を取得する。また、ＮＷ管理手段は、取得した情報を基に、輻輳を自動的に判断する。または、ＮＷ管理手段は、取得したノードの輻輳に関する情報を、ネットワークを管理する人（保守者）に提示し、保守者の判断による輻輳状態の決定入力のための入力手段を提供する。
このＮＷ管理手段は、着呼側の呼制御手段、発呼側の呼制御手段、または、発呼側および着呼側以外の第三の呼制御手段に含まれてもよい。また、実施の形態や図には特に明示しなかった他の手段でもよい。また、保守者の判断による入力手段によって行われてもよい。そのため、ＮＷ管理手段は特に図中には明示していない。

図２は、図１の実施の形態において、着ノード３−２に負荷が集中し、着ノード３−２が輻輳したときのシステム状態である。この時、着側制御４−２は発ノード３−１で実行され、着端末の加入者データ５−２は発ノード３−１が参照する。以下、その動作を詳述する。

図３は、第一の実施の形態の動作の流れを説明するための、フローチャートである。まず、着ノード３−２が輻輳状態に陥ると（ステップＳ０１）、ＮＷ管理手段は輻輳ノード３−２のアドレス８をネットワーク内の各ノードに設定する（ステップＳ０２）。次に、発ノード３−１が加入者の端末１−１からの発信を受け付けると、発ノード３−１は着端末１−２のアドレスを元にして着信ノードのアドレスを取得して、ステップＳ０２で設定されたアドレス８と比較し（ステップＳ０３）、一致しない場合は通常の接続処理を行う（ステップＳ０４，ステップＳ０５）。一方、一致した場合は、発ノード３−１で着側制御４−２を起動すると共に、この着側制御４−２によって、着端末の加入者データ５−２にアクセスし（ステップＳ０６）、着端末１−２に着信する（ステップＳ０７）。

先の説明においては、発ノード３−１が加入者の端末１−１からの発信を受け付けると、発ノード３−１は着端末１−２のアドレスを元にして着信ノードのアドレスを取得するとしたが、例えば、発ノード３−１が加入者の端末１−１からの発信を受け付けると、発ノード３−１は着端末１−２のアドレスを元にアドレス変換サーバにアクセスし、アドレス変換サーバより着信ノードのアドレスを取得してもよい。
また、各ノードは、例えば、着端末１−２のアドレスから、着信ノードのアドレスを一意に決められるルールが設けられており、各ノードでそれらは実行される。
これらはＳＩＰ等において通常なされる処理である。発ノード３−１から着端末１−２のアドレスを元にして着ノード３−２を調べる方法としては、他の全ての従来技術において成されてもよい。

次に、第二の実施の形態について説明する。この実施の形態のシステム構成は図１および図２と同じである。
図４は、第二の実施の形態の動作を説明するためのフローチャートである。ここで、ステップＳ０６までの手順は、第一の実施の形態の図３と同様に行われる。そして、ステップＳ０６に続いて付加サービスの要求の有無を判定する（ステップＳ１１）。ここで、付加サービスとは、例えば、キャッチホンや、電話系サービスには基本接続に代表される一対一の通信でなく、多者通話のような一対多の通信といったサービスである。
ステップＳ１１で付加サービスを要求された場合には、要求された付加サービスを拒否し、例えば該当の呼を切断し（ステップＳ１２）、基本接続であれば着端末１−２に着信を行う（ステップＳ０７）。前述のステップＳ１１における付加サービスが要求されているかどうかの判定は、例えば、アクセスした着端末の加入者データ５−２に記憶された情報に基づいて行われる。以上の手続きにより、輻輳ノード３−２の処理を発ノード３−１が代行する場合において、発ノード３−１の負荷を抑制し、かつ、接続処理の簡易化が可能となる。

この実施形態において、加入者データ５には、加入者端末に関する付加サービスに関する情報を含むようにしたが、加入者データ５には、例えば、付加サービスの実現のための情報として通話中等の呼状態情報等を含んでもよい。
また、前述の付加サービスについては、発ノード３−１により、ステップＳ０３における比較において一致した場合には、要求された付加サービスを拒否するようにしてもよい。

また、第二の実施の形態におけるサービスの制限として、付加サービスの有無に基づいて呼を切断するようにしたが、付加サービス以外に、通信の帯域やデータ通信の優先度、音声の品質などを低下させるようにしてもよい。
また、例えばリソースの都合で該当ノードでは不可能なサービスを提供しない、あるいは、単に基本サービス以外は提供しないようにすることも可能である。

次に、アクセス制御がある場合の実施の形態を説明する。アクセス制御とは、例えば、発呼側から着呼側への呼の経路を確立することができるか否かに関わり、経路確立後の会話のための双方向のデータ通信のフィルタリングを行うものである。つまり、発呼側と着呼側両方においてアクセス制御が正常に行わなければ、会話が出来ないことになる。
着呼側にこのようなアクセス制御がある場合に、着呼側において輻輳が発生した場合、着呼側のアクセス制御にも負荷のために、着呼側への呼の疎通が出来ない可能性がある。以下の第三および第四の実施の形態において、このように着呼側にアクセス制御がある場合においても、着呼側への疎通が出来る方法について説明する。

図５は、第三および第四の実施の形態によるアクセス制御がある場合であって通常時の着呼側の処理量を緩和する呼制御方法および呼制御システムの構成を示すブロック図である。
図５は特定のノードに負荷が集中していない通常時のシステム状態である。図１のシステム構成に加えて、エッジノード２はアクセス制御６の機能を有する。このアクセス制御は端末１がネットワークの様々な装置ヘアクセスすることを制限するなどの機能であり、例えば、発端末１−１はノード３−１にはアクセスできても、ノード３−２にはアクセスできないようにフィルタリングを行う機能を有する。このアクセス制御６はエッジノード２を制御する上位装置にあたるノード３のエッジノード制御７の指示により動作する。

図６は、第三の実施の形態によるアクセス制御がある場合であって輻輳時にエッジノードを制御しない着呼側の処理量を緩和する呼制御方法および呼制御システムの構成を示すブロック図である。
この図６では、特定のノードに負荷が集中し、図５の着ノード３−２が輻輳したときのシステム状態を示している。また、この図６において、着側制御４−２は発ノード３−１で実行される点は第一の実施の形態と同様であるが、アクセス制御６−２を解除し、着側制御４−２ではエッジノード制御を実施してない点が相違する。

図７のフローチャートを用いて、図５および図６の第三の実施の形態の動作を説明する。まず、着ノード３−２が輻輳状態に陥ると（ステップＳ０１）、ＮＷ管理手段は輻輳ノード３−２のアドレス８をネットワーク内の各ノードに設定する（ステップＳ０２）。輻輳ノード３−２はエッジノード２−２のアクセス制御部６−２を無効化する（ステップＳ２１）。これによって、着端末１−２は発ノード３―１と直接メッセージの交換が可能になる。次に発ノード３−１で制御される加入者の端末１−１からの発信を受け付けると、発ノード３−１は着端末１−２のアドレスを元にして着信ノードのアドレスを取得して、ステップＳ０２で設定されたアドレス８と比較し（ステップＳ０３）、一致しない場合には、通常の接続処理を行う（ステップＳ０４、ステップＳ２２、ステップＳ０５）。一方、一致した場合は、発ノード３−１で着側制御４−２を起動すると共に、着端末の加入者データ５−２にアクセスする（ステップＳ０６）。そして、着側制御４―２ではエッジノード２−２のアクセス制御をスキップし（ステップＳ２３）、制御着端末１−２に着信する（ステップＳ０７）。

図８は、この発明の第四の実施の形態によるアクセス制御がある場合であって輻輳時にエッジノードを制御する着呼側の処理量を緩和する呼制御方法および呼制御システムの構成を示すブロック図である。
この図８では、特定のノードに負荷が集中し、図５の着ノード３−２が輻輳したときのシステム状態を示している。この時、着側制御４−２は発ノード３−１で実行される点は第一の実施の形態と同様であるが、発ノード３−１にてアクセス制御６−２に関するエッジノード制御７−２を代行する点が異なる。

次に図面を用いて、第四の実施の形態の動作の流れを説明する。図９は、図５および図８の第四の実施の形態において用いられるフローチャートである。まず、着ノード３−２が輻輳状態に陥ると（ステップＳ０１）、ＮＷ管理手段は輻輳ノード３−２のアドレス８をネットワーク内の各ノードに設定する（ステップＳ０２）。輻輳ノード３−２はエッジノード２−２に対して、アクセス制御部６−２の制御を、発ノードから代行できるように許容する（ステップＳ３１）。次に発ノード３−１で制御される加入者の端末１−１からの発信を受け付けると、発ノード３−１は着端末１−２のアドレスを元にして着信ノードのアドレスを取得して、ステップＳ０２で設定されたアドレス８と比較し（ステップＳ０３）、一致しない場合には、通常の接続処理を行う（ステップＳ０４、ステップＳ３２、ステップＳ０５）。一方、一致した場合は、発ノード３−１で着側制御４−２を起動すると共に、着端末の加入者データ５−２にアクセスする（ステップＳ０６）。さらにエッジノード制御７−２によりエッジノード２−２のアクセス制御６−２を行い（ステップＳ３３）、制御着端末１−２に着信する（ステップＳ０７）。

図９の第四の実施の形態の説明においては、予めエッジノード２−２におけるアクセス制御６−２があるものとして説明を行った。しかし、予めアクセス制御があると決めず、必要に応じてアクセス制御を発呼側で行うことも可能である。
例えば、エッジノード２−２にアクセス制御６−２があるという情報を着端末の加入者データ５−２に保存しておき、これを基に、アクセス制御が必要であるか不要であるかの判定を行い、必要であれば、前述と同様の処理を行うことも可能である。
例えば、図９のフローチャートにおいて、ステップＳ０６までは共通であり、着端末の加入者データ５−２にアクセスし（ステップＳ０６）、その後、例えば、アクセスした着端末の加入者データ５−２からの情報により、エッジノード２−２のアクセス制御６−２が必要であるか否かを判定する。アクセス制御が必要である場合には、さらにエッジノード制御７−２によりエッジノード２−２のアクセス制御６−２を行い（ステップＳ３３）、制御着端末１−２に着信する（ステップＳ０７）。アクセス制御が必要でない場合には、そのまま、制御着端末１−２に着信する（ステップＳ０７）。

本実施の形態においては、発呼側で行われる制御として、発ノード３−１で制御される加入者の端末１−１からの発信を受け付けると、発ノード３−１は着端末１−２のアドレスを元にして着信ノードのアドレスを取得した後、アドレス８と比較する例を示した。
このように発呼側が、着呼アドレスから直接的に着呼ノードの情報を取得するだけでなく、着呼アドレスから一旦ホーム網を経由してローミング先のノードの情報を取得するように、間接的にノードの情報を取得する形態においても本発明は適応可能である。

また、本実施の形態として、着呼側の輻輳時において、発呼側で着呼側の処理を代行することにより着呼側の負荷を緩和することにより着呼側の疎通を改善したが、着呼側の処理を着呼側および発呼側以外の第三のノードで代行することも可能である。
第三のノードとしては、例えば、負荷の軽いノードを選択しても良いし、いくつかの候補の中からラウンドロビン方式で選択してもよい。

また、本実施の形態においては、着ノードの輻輳時について説明を行ったが、着ノードの故障の場合にも、本発明による方法は適応可能である。この場合も、ＮＷ管理手段によりノードの輻輳と同様にノードの故障が判断される。

また、本発明の適応としてＶｏＩＰを例にして示したが、ＶｏＩＰのように、加入者収容装置と呼制御を行う装置が分離されたシステムであれば本発明は適応可能である。例えば、携帯電話やＩＰ携帯電話においても、以上のような構成であれば、適応可能である。

また、本発明の適応として特に災害時の着呼側の輻輳を問題としてきたが、災害時でなく通常発生する輻輳時においても本発明は適応可能である。

また、発明の実施の形態として、第一から第四の実施の形態を用いて説明を行ったが、これら第一から第四において説明されたそれぞれの機能は、独立に用いてもよいし、また、互いに組み合わせて用いてもよい。

以上、この発明の実施の形態を、図面を参照して詳述してきたが、具体的な構成はこの実施の形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。

この発明は、ＶｏＩＰシステムのような加入者収容を行う装置と呼制御を行う装置が分離された呼制御システムに用いて最適である。

この発明の第一および第二の実施の形態による呼制御システムの構成を示すブロック図である。 この発明の第一の実施の形態における呼制御システムの輻輳時のシステム状態を示すブロック図である。 同第一の実施の形態の動作を説明するためのフローチャートを示す図である。 この発明の第二の実施の形態の動作を説明するためのフローチャートを示す図である。 この発明の第三および第四の実施の形態による呼制御システムの構成を示すブロック図である。 この発明の第三の実施の形態による呼制御システムの輻輳時のシステム状態を示すブロック図である。 この発明の第三の実施の形態の動作を説明するためのフローチャートを示す図である。 この発明の第四の実施の形態による呼制御システムの輻輳時のシステム状態を示すブロック図である。 この発明の第四の実施の形態の動作を説明するためのフローチャートを示す図である。

符号の説明

１ 発側および着側の端末
２ 発側および着側のエッジノード
３ 発側および着側のノード
４ 発側および着側の制御
５ 発側および着側の加入者データ
６ 発側および着側のアクセス制御
７ 発側および着側のエッジノード制御
８ 輻輳ノードのアドレス
９ ネットワーク

Claims (7)

1. 複数の端末の呼処理に関する情報を保持するデータベースと、前記端末の呼の制御を行う呼制御装置と、前記端末を収容する収容装置とが、ネットワークを介して互いに接続される呼制御システムにおいて用いられる呼制御方法において、
   前記複数の呼制御装置が、輻輳を生じた呼制御装置を特定する呼制御装置情報を保持しており、呼を着呼側端末に送信する場合に、前記保持した呼制御装置情報に前記着呼側端末が収容される着呼側呼制御装置が含まれるか否かを判定し、前記着呼側呼制御装置が前記保持した呼制御装置情報に含まれる場合には、前記着呼側端末を収容する着呼側データベースにアクセスし前記着呼側端末の呼処理に関する情報を取得し、前記取得した情報に基づいて、前記着呼側端末への呼制御を行い、
   前記呼制御装置は、自身の呼制御装置を指定する情報と前記呼制御装置情報を比較し、自身の呼制御装置を指定する情報が前記呼制御装置情報に含まれる場合には、自身の呼制御装置と関連して端末の呼の処理を行っている収容装置のアクセス制限の解除を行う、
   ことを特徴とする呼制御方法。
2. 複数の端末の呼処理に関する情報を保持するデータベースと、前記端末の呼の制御を行う呼制御装置と、前記端末を収容する収容装置とが、ネットワークを介して互いに接続される呼制御システムにおいて用いられる呼制御方法において、
   前記複数の呼制御装置が、輻輳を生じた呼制御装置を特定する呼制御装置情報を保持しており、呼を着呼側端末に送信する場合に、前記保持した呼制御装置情報に前記着呼側端末が収容される着呼側呼制御装置が含まれるか否かを判定し、前記着呼側呼制御装置が前記保持した呼制御装置情報に含まれる場合には、前記着呼側端末を収容する着呼側データベースにアクセスし前記着呼側端末の呼処理に関する情報を取得し、前記取得した情報に基づいて、前記着呼側端末への呼制御を行い、
   前記呼制御装置は、自身の呼制御装置を指定する情報と前記呼制御装置情報を比較し、自身の呼制御装置を指定する情報が前記呼制御装置情報に含まれる場合には、自身の呼制御装置と関連して端末の呼の処理を行っている収容装置のアクセス処理を自身以外の呼制御装置からも制御ができるようにし、呼を着呼側端末に送信する場合に、前記保持した呼制御装置情報に前記着呼側端末が収容される着呼側呼制御装置が含まれるか否かを判定し、前記着呼側呼制御装置が前記保持した呼制御装置情報に含まれる場合には、前記着呼側端末を収容する着呼側データベースにアクセスし前記着呼側端末の呼処理に関する情報を取得し、前記着呼側端末に関わる収容装置とのアクセス制御を行い、前記着呼側端末への呼制御を行う、
   ことを特徴とする呼制御方法。
3. 前記呼制御装置は、前記着呼側呼制御装置が前記保持した呼制御装置情報に含まれる場合には、前記着呼側端末を収容する着呼側データベースにアクセスし前記着呼側端末の呼処理に関する情報を取得し、付加サービス提供の可否判定を行い、前記可否判定が否の場合には要求された付加サービスを拒否し、可の場合には前記取得した情報に基づいて、前記着呼側端末への呼制御を行うこと、
   を特徴とする請求項１または請求項２に記載の呼制御方法。
4. 前記呼制御システムは、更にネットワーク管理手段を含み、
   前記ネットワーク管理手段が、複数の呼制御装置の輻輳状態または故障状態を監視し、または、前記呼制御装置から輻輳または故障の状態を示す信号を受信し、前記呼制御装置の輻輳または故障を判断し、いずれかの呼制御装置が輻輳または故障を生じた場合には、前記呼制御装置へ、輻輳または故障を生じた呼制御装置を特定する呼制御装置情報として通知し、
   前記呼制御装置は、更に前記通知された呼制御装置情報を保持すること
   を特徴とする、請求項１から３のうちいずれか１項に記載の呼制御方法。
5. 前記呼制御装置は、前記着呼側呼制御装置が前記保持した呼制御装置情報に含まれる場合には、自身の呼制御装置および前記着呼側端末が収容される着呼側呼制御装置以外の第三の呼制御装置を選択し、前記第三の呼制御装置へ呼を転送すること、
   を特徴とする請求項１から４のうちいずれか１項に記載の呼制御方法。
6. 複数の端末の呼処理に関する情報を保持するデータベースと、前記端末の呼の制御を行う呼制御装置と、前記端末を収容する収容装置とが、ネットワークを介して互いに接続される呼制御システムにおいて、
   前記複数の呼制御装置が、輻輳を生じた呼制御装置を特定する呼制御装置情報を保持する手段と、呼を着呼側端末に送信する場合に、前記保持した呼制御装置情報に前記着呼側端末が収容される着呼側呼制御装置が含まれるか否かを判定する手段と、前記着呼側呼制御装置が前記保持した呼制御装置情報に含まれる場合には、前記着呼側端末を収容する着呼側データベースにアクセスし前記着呼側端末の呼処理に関する情報を取得する手段と、前記取得した情報に基づいて、前記着呼側端末への呼制御を行う手段と、自身の呼制御装置を指定する情報と前記呼制御装置情報を比較し、自身の呼制御装置を指定する情報が前記呼制御装置情報に含まれる場合には、自身の呼制御装置と関連して端末の呼の処理を行っている収容装置のアクセス制限の解除を行う手段とを含む、
   こと特徴とする呼制御システム。
7. 複数の端末の呼処理に関する情報を保持するデータベースと、前記端末の呼の制御を行う呼制御装置と、前記端末を収容する収容装置とが、ネットワークを介して互いに接続される呼制御システムにおいて、
   前記複数の呼制御装置が、輻輳を生じた呼制御装置を特定する呼制御装置情報を保持する手段と、呼を着呼側端末に送信する場合に、前記保持した呼制御装置情報に前記着呼側端末が収容される着呼側呼制御装置が含まれるか否かを判定する手段と、前記着呼側呼制御装置が前記保持した呼制御装置情報に含まれる場合には、前記着呼側端末を収容する着呼側データベースにアクセスし前記着呼側端末の呼処理に関する情報を取得する手段と、前記取得した情報に基づいて、前記着呼側端末への呼制御を行う手段と、自身の呼制御装置を指定する情報と前記呼制御装置情報を比較し、自身の呼制御装置を指定する情報が前記呼制御装置情報に含まれる場合には、自身の呼制御装置と関連して端末の呼の処理を行っている収容装置のアクセス処理を自身以外の呼制御装置からも制御ができるようにし、呼を着呼側端末に送信する場合に、前記保持した呼制御装置情報に前記着呼側端末が収容される着呼側呼制御装置が含まれるか否かを判定し、前記着呼側呼制御装置が前記保持した呼制御装置情報に含まれる場合には、前記着呼側端末を収容する着呼側データベースにアクセスし前記着呼側端末の呼処理に関する情報を取得し、前記着呼側端末に関わる収容装置とのアクセス制御を行い、前記着呼側端末への呼制御を行う手段とを含む、
   こと特徴とする呼制御システム。

Images