JP2007329617A

JP2007329617A - 通信制御処理実行方法およびシステム、ならびにそのプログラム

Info

Publication number: JP2007329617A
Application number: JP2006158067A
Authority: JP
Inventors: Akio Masuda; 暁生増田
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 2006-06-07
Filing date: 2006-06-07
Publication date: 2007-12-20

Abstract

【課題】高負荷時においても接続要求処理を迅速に応答し、また、負荷に対するサーバの耐性を向上することが可能な通信制御処理実行方法およびシステムを実現する。
【解決手段】ＩＰネットワークでの呼処理サーバに関し、呼処理バッファに優先度の異なる２種類以上のキュー６０，７０を用意することにより、接続要求処理の実行を切断要求処理の実行よりも優先して行う。呼処理タスクが次の処理を行うために、キュー６０，７０からイベントを取り出す際に、キュー６０，７０の間で取り出し順の優先制御を行う。ルータなどのパケット転送処理と同様に、ＰＱ、あるいは、ＷＲＲなどのスケジューリングアルゴリズムを適用し、応答時間条件の厳しい処理要求呼を優先して処理する。Ｔｐは各要求呼に対する処理の所要時間であリ、Ｔｑはキューにおける平均待ち時間であり、ｓはサーバが同時に処理を並行実行できる数である。
【選択図】図４

Description

本発明は、ＩＰネットワークなどの通信網において、通信サービスの開始・終了時の呼設定・切断処理や通話中のセッション状態管理を行う通信制御サーバのソフトウェアにおける通信制御処理実行方法およびシステム、ならびにそのプログラムに関する。

ＩＰネットワークなどのパケット通信では、複数の利用者が共通のネットワークを用いてそれぞれパケットの送受信を行っている。ネットワークは有限の通信リソース（回線の帯域幅、ノードのバッファ量など）を持っているため、利用者数が大きくなってネットワークの転送能力を超える量のパケットが流入すると、パケットの到着の遅延が大きくなったり、廃棄（パケットのロス）が発生したりして、通信サービスの品質が劣化してしまう。

これに対して、ノードでのパケット転送時に優先制御を行う方法が普及している。例えば、ＩＰネットワークにおけるＤｉｆｆｓｅｒｖという方式は、パケットのヘッダに優先度を付けておき、ルータで転送能力を超えるパケットが流入した際には、優先度の低いパケットを廃棄したり、後回しにして、優先度の高いパケットを優先的に転送するものであって、これにより、パケットの遅延や廃棄確率などの品質条件を相対的に高く保つことが可能になる（Ｓ．Ｂｌａｋｅ，Ｄ．Ｂｌａｃｋ，Ｍ．Ｃａｒｌｓｏｎ，Ｅ．Ｄａｖｉｅｓ，Ｚ．Ｗａｎｇ，ａｎｄＷ．Ｗｅｉｓｓ：Ａｎａｒｃｈｉｔｅｃｔｕｒｅｆｏｒｄｉｆｆｅｒｅｎｔｉａｔｅｄｓｅｒｖｉｃｅｓ，ＲＦＣ２４７５，ＤＥＣＥＭＢＥＲ１９９８．を参照（非特許文献４））。

近年、市販されているルータにも、上記の機能が実装されているものが多い。
パケット通信においては、利用者が転送したい情報を１つまたは複数のパケットを使用して送信する。一般的に、あるネットワークの利用（あるデータの転送開始から終了まで、ある電話の通話開始から終了まで、など）をセッションと呼び、そのセッションのために連続的に転送されるパケットの集合のことをフローと呼ぶ。
優先制御の主な利用方法としては、パケットごとに転送優先度を決定するのではなく、フロー単位で優先度を付ける。

ところで、前記の優先制御について、この方法では転送優先度の高いフローと低いフローが混在している場合には、高優先フローの転送品質の確保に効果があるが、高優先度フロー数が増加し、それだけでネットワークリソースを使い切ってしまうような場合には、高優先フローであっても転送品質の劣化は免れない。高優先フローをネットワークのリソース容量以上に収容することは可能であるが、サービス品質の劣化が全利用者に及んでしまう、という問題があった。

（受付制御）
前記の問題を解決し、転送品質を維持するために、ネットワークのリソース容量以上の利用要求を拒絶するという制御を行う方法が有効であり、これを受付制御（ＡｄｍｉｓｓｉｏｎＣｏｎｔｒｏｌ）と呼ぶ（前記の非特許文献２および非特許文献３参照）。
前記非特許文献２，３では、ＩＰネットワークにおいて、ネットワーク中の全てのリンクのリソース容量と利用されているリソース量を把握しておくことで、新たなセッションの発生による利用要求を受信した際に受付判定を行う方法、およびシステムが記述されている。

リソース管理サーバでは、管理対象のネットワーク中の全てのリンクについて、高優先フローが使用しているリソース量をリアルタイムに管理している。これは、高優先フローの利用開始時に利用要求を受信し、それを記録することにより行われる。また、リソース管理サーバは、ネットワークからの情報収集によって経路情報と各リンクのリソース容量を把握している。利用要求の受信時には、そのフローが通過する全てのリンクを経路情報から検索し、各リンクの使用リソース量を加算して記録する。このとき、使用量がリソース容量を超えてしまう場合には、この利用要求に対して利用すること自体を、または優先フローとして扱うことを拒絶する。後者の場合、該当する要求の通信は非優先フローとして許可される。
このようなリソース管理・受付制御方法により、高優先フローはネットワークのリソース容量が許す限り収容され、容量を超えることは防止されるので、利用を許容されたフローはその品質が確保される。

（受付制御の適用例）
前記機能を持つリソース管理・受付制御サーバは、通信キャリアがＩＰ技術で様々な通信サービスを統合して大規模に展開する次世代ネットワーク（「ＮＧＮ」）の国際標準化の中でもその必要性を認識されており、ＩＴＵ−ＴやＥＴＳＩＴＩＳＰＡＮにおいてＲＡＣＳ（ＲｅｓｏｕｒｃｅａｎｄＡｄｍｉｓｓｉｏｎＣｏｎｔｒｏｌＳｕｂｓｙｓｔｅｍ）としてネットワークアーキテクチャ内に定義されている。

このような適用例の中で、リソース管理・受付制御サーバは、ＩＰ電話，ＴＶ電話，ＶｏＤなどの様々なセッションベースの通信サービスの発信時にアプリケーションサーバやセッション制御サーバから受付制御機能として呼び出され、応答を行うことが期待される。
具体的には、呼の生起（利用者がサービス利用開始の意思を通知する）時に利用者からの接続要求がアプリケーションサーバやセッション制御サーバに通知され、各サーバが接続処理を行う中で、求められる品質で接続することが可能か否かを受付制御サーバに問い合わせる。

受付制御サーバは、前記問い合わせに対してリソースの空き状況を確認し、空きがあると判断されれば受付許可を、空きがないと判断されれば受付拒否を、それぞれ通知する。
また、受付が許可されるた接続が確立された後、その呼が終了する際には、呼の切断処理が行われる。この中で、切断要求を認識したアプリケーションサーバやセッション制御サーバは受付制御サーバに対して該当呼の終了を通知する。ここで、受付制御サーバは、該当呼のために確保していたリソースを解放する処理を行い、切断処理の完了通知を応答する。

（受付制御サーバの呼処理容量の要求条件）
前記受付制御サーバを始め、既存電話網における電話交換機やＩＰネットワークにおけるＷｅｂサーバ、セッション制御サーバ、認証サーバなど、通信サーバにおいて接続を制御するサーバでは、性能に関係する様々な要求条件があるが、その中でも特に「応答時間」，「処理容量」が重要である。応答時間は要求受信から応答するまでの時間であり、これが長くなると利用者の要求通知からサービス使用開始までの待ち時間が長くなり、体感する利用品質に影響するなどの問題が生じる。その一例として、既存電話網の品質基準としては、接続遅延時間は３秒以上となる確率が０．０１以下となること、と規定されている（事業用電気通信設備規則第３５条）。この場合、サービスが開始されるまでにセッション制御サーバ、受付制御サーバなどを何段も介することを考慮すると、１サーバ当りの応答時間は数１００ミリ秒以内である必要がある。

ここで言う応答時間とは接続要求処理に対する応答時間のことであるが、切断要求に対する応答時間にも要求条件がある。通信サービスが通信時間に対する従量課金である場合には、切断時刻を正確に記録する必要がある。呼処理サーバのうち、切断時刻を記録するサーバにおいては、切断要求処理の実行が遅延してしまうと利用者へ過大に課金してしまうことになるので、接続要求処理と同様に、切断要求処理においても大きな処理遅延がないように、サーバの処理容量を確保しておく必要がある。

処理容量とは、単位時間当りに処理できる要求数であり、１秒当りの呼数、１時間当りの呼数などが論じられる。スループットと表されることも多い。処理容量が小さいと、利用者一人当りの発呼頻度が一定であると仮定した場合、そのシステムが収容できる利用者数が少なくなり、システムを多数導入することによりサービス提供のためのコストが上昇し、提供料金に反映されてサービスの利用価値が下がったり、競爭力が低下することにつながる。また、機能の特性上、システムを多数導入することでは収容利用者数を増加できないこともあり、サービス全体のスケール性に影響することもある。

（スループットと応答時間の関係）
前述のようなサーバでは、一般的に要求の到着順に処理を行うが、ある要求に対する処理を実行中に別の要求が到着した場合には、これをバッファに蓄積して待ち合わせることが多い。
このようなシステム内の動作は、待ち行列理論において、これまでに多くの議論がなされている。サーバのスループットより高い頻度で要求が到着する場合、待ち行列（キュー）に追加されて待ち合わせる要求数が多くなり、各要求呼に対する応答時間が長くなっていく。ここで、要求呼の到着間隔が指数分布（平均λ）、各要求呼に対する処理の所要時間がＴ_ｐで一定と仮定し、サーバが同時に処理を並列実行できる数をｓとすると、このシステムはケンドールの記号におけるＭ／Ｄ／Ｓ型の待ち行列モデルと考えることができ、キューにおける平均待ち時間Ｔ_ｑはクロメリン−ポラチェックの公式から下記のように表される。

図３は、Ｔ_ｐ＝８〔ｍｓｅｃ〕としたときの発呼頻度に対するキュー滞在時間の推移を表す図である。
ここで、発呼頻度はスループットＳに対して正規化しており、Ｓ＝ｓ／Ｔｐと表せる。このように、サーバに対する負荷が低く、スループットに対する発呼頻度の大きさが９割程度までは数ミリ秒で応答できていたものが、発呼頻度がスループットと同等程度になると１００ミリ秒前後となり、スループットを超えると急激に上昇してしまうことがわかる。
つまり、スループットと応答時間には深い関係があり、スループットが高いということは、要求条件として定められた時間内に応答できる発呼頻度の限界を高めることができることになる。

なお、前述の非特許文献４の他にも、Ｂ．Ｔｅｉｔｅｌｂａｕｍ，ｅｔａｌ，“ＱＢｏｎｅＢａｎｄｗｉｄｔｈＢｒｏｋｅｒＡｒｃｈｉｔｅｃｔｕｒｅ，”ｈｔｔｐ：／／ｑｂｏｎｅ．ｉｎｔｅｒｎｅｔ２．ｅｄｕ／ｂｂ／ｂｂｏｕｔｌｉｎｅ２．ｈｔｍｌ（非特許文献１）、（笠原，増田，吉田，“パーフローＱｏＳを実現するエージェント型リソース制御システム，”情報処理学会論文誌，Ｖｏｌ．４６Ｎｏ．２，ｐｐ．５１７−５２４，Ｆｅｂ．２００５．（非特許文献２）、および、増田．佐藤，笠原，“受付制御のためのＮＷリソース管理方法の提案，”信学技報，ＮＳ２００３−１７０，ｐｐ．５−８，Ｎｏｖ．２００３．（非特許文献３）がある。

Ｂ．Ｔｅｉｔｅｌｂａｕｍ，ｅｔａｌ，"ＱＢｏｎｅＢａｎｄｗｉｄｔｈＢｒｏｋｅｒＡｒｃｈｉｔｅｃｔｕｒｅ，" ｈｔｔｐ：／／ｑｂｏｎｅ．ｉｎｔｅｒｎｅｔ２．ｅｄｕ／ｂｂ／ｂｂｏｕｔｌｉｎｅ２．ｈｔｍｌ笠原，増田，吉田，"パーフローＱｏＳを実現するエージェント型リソース制御システム，"情報処理学会論文誌，Ｖｏｌ．４６Ｎｏ．２，ｐｐ．５１７−５２４，Ｆｅｂ．２００５．増田．佐藤，笠原，"受付制御のためのＮＷリソース管理方法の提案，"信学技報，ＮＳ２００３−１７０，ｐｐ．５−８，Ｎｏｖ．２００３．Ｓ．Ｂｌａｋｅ，Ｄ．Ｂｌａｃｋ，Ｍ．Ｃａｒｌｓｏｎ，Ｅ．Ｄａｖｉｅｓ，Ｚ．Ｗａｎｇ，ａｎｄＷ．Ｗｅｉｓｓ：Ａｎａｒｃｈｉｔｅｃｔｕｒｅｆｏｒｄｉｆｆｅｒｅｎｔｉａｔｅｄｓｅｒｖｉｃｅｓ，ＲＦＣ２４７５，ＤＥＣＥＭＢＥＲ１９９８．

受付制御サーバが行う主な処理は、前述したように接続要求に対する処理と切断要求に対する処理である。他にも、サーバ間での接続を継続するために行う処理や、システムが正常に稼動を続けるための処理などが実行されているが、受付制御サーバの本来の使用目的は接続・切断要求に対する処理であり、特に高負荷状態は利用者の接続・切断要求の頻度が高まることによって発生するため、高負荷状態において受付制御サーバが行っている処理の殆んどは接続・切断要求処理となる。

受付制御サーバの処理能力を決定する要因のうち、最も重要なものにプロセッサの処理能力がある。前述のように、高負荷状態においてはプロセッサの能力の殆んどは接続要求，切断要求に対する処理に使われる。ここで、ある接続要求に対する受付が成功した場合は、その通信の終了時に切断要求が発生する。従って、接続要求に対する受付制御結果の殆んどが成功であると仮定すると、受付制御サーバに到着する接続要求と切断要求の数はほぼ同じ（切断要求の方がわずかに少ない）となる。

一般的にセッション制御サーバでは、接続要求、切断要求などの処理要求を呼処理バッファ（イベントキュー）に登録し、呼処理を行うプログラムが登録されたイベントを受け取って処理していく。ここで、一般的には接続要求と切断要求処理は、処理の順番という意味では同等に扱われ、発生した順（呼処理バッファに登録された順）に処理されていく。このため、高負荷時においては、受付制御サーバのプロセッサは接続要求の処理と切断要求の処理がほぼ半分ずつ分け合っていることになる。

前述のように、セッション制御サーバでは、利用品質の確保のために接続要求を、課金のための切断時刻記録のために切断要求を、それぞれ迅速に実行する必要がある。しかし、同様にセッション確立時の接続要求と、セッション終了時の切断要求に対する処理を行う呼処理サーバの中には、切断時間の正確な記録が要求されないものがある。この場合、切断要求に対する処理の応答時間の要求条件は、接続条件のそれより厳しくはない。このようなサーバで、前述のように接続要求処理と切断要求処理を同等の優先度で発生順に処理している場合、プロセッサのリソースを効率的に利用しているとは言えない。

（目的）
本発明の目的は、前記課題を解決するため、接続要求処理に対する応答時間の要求条件が厳しく、切断要求処理に対するそれが厳しくない呼処理サーバにおいて、呼処理プログラムで接続要求処理の実行を切断要求処理の実行より優先して行うことで、高負荷時においても接続要求処理を迅速に応答し、また、負荷に対するサーバの耐性を向上することが可能な通信制御処理実行方法およびシステムを提供することにある。

本発明の通信制御処理実行方法およびシステムは、通信サービスの利用開始時に接続要求を受信し、それに対する呼設定処理を、また、利用終了時に終了通知を受信し、それに対する終了処理を行うサーバにおいて、両要求呼に対して異なるキューを持ち、呼処理時のキュー取り出しにおいては接続要求呼を優先することで、高負荷時にもサーバ内の処理待ち時間を短かく抑えることを特徴とする。

本発明によれば、高負荷時の接続処理応答時間を短縮することができるとともに、プロセッサ使用率１００％未満での輻輳制御発動を行う必要がないため、輻輳に対する耐性を向上させることができる。

以下、本発明の原理と実施例を説明する。
（原理）
図４は、本発明の呼処理実行制御方法の原理を示す説明図である。
前述のように、呼処理プログラムでは、到着した処理要求呼を呼処理バッファに蓄積する。呼処理バッファはキュー（待ち行列）となっており、従来の呼処理サーバでは、これを到着順に処理していた。
本発明では、呼処理バッファにおいて優先度の高い（応答時間の厳しい、例えば、接続要求）要求と優先度の低い（応答時間条件が厳しくない、例えば、切断要求）要求に対しては、異なるキューを用意する。一般的に、呼処理サーバに処理要求が到着すると、その要求呼は要求種別に応じて該当するキューに追加される。呼処理プログラム中の呼処理を実行する部分は、キューから要求呼（イベント）を取り出し、これを実行し、終了した後、キューを確認し、イベントがあればこれを取り出し、実行する、ということを繰り返す。なお、キューにイベントがない場合には待ち状態となり、イベントの発生時に再度起動される。

この『呼処理の実行部分』は、呼処理シナリオなどと呼ばれ、１つまたは複数のタスク、プロセス、スレッドなどのコンピュータの実行単位として動作する。実行単位は呼処理サーバの環境（オペレーティングシステムの対応、最適性）によって異なる。以後、本文では、『呼処理タスク』と呼ぶ。
本発明では、呼処理タスクが次の処理を行うために、キューからイベントを取り出す際に、キュー間で取り出し順の優先制御を行う。ルータなどのパケット転送処理と同様に、ＰＱ（プライオリティ・キューイング）、ＷＲＲ（ウェイテッド・ラウンドロビン）などのスケジューリングアルゴリズムを適用し、応答時間条件の厳しい処理要求呼を優先して処理する。

ＰＱの場合を例にとると、呼処理タスクはある呼処理が終了した後、まず高優先キューを確認し、イベントがあればそれを取り出して実行する。なければ、次に優先度の高いキュー（キューが高／低の２種類しかなければ、低優先度キュー）を確認し、イベントがあればこれを処理する。全てのキューにイベントがなければ、待ち状態に入り、後にイベントが発生して、呼び出されるまで待機する。

図４は、キューが高／低の２種類しか設けられていない場合の構成を示しており、高優先度として接続要求キュー６０、低優先度として切断要求キュー７０がそれぞれ設けられる。Ｔ_ｐは各要求呼に対する処理の所要時間であって、一定と仮定される。また、Ｔ_ｑはキューにおける平均待ち時間であって、前式〔数１〕で表わされる。また、ｓは、サーバが同時に処理を並行実行できる数である。
まず、キューに対して優先度を付ける。接続要求キュー６０を高優先、切断要求キュー７０を低優先とする。呼処理タスクはある呼処理が終了した後、まず高優先の接続要求キュー６０を確認し、イベントがあればそれを取り出して実行する。なければ、低優先の切断要求キュー７０を確認し、イベントがあれば処理する。全てのキュー６０，７０にイベントがなければ、待ち状態に入り、後にイベントが発生し呼び出されるまで待機する。
このようなスケジューリングでプロセッサに渡されたイベントは、ｓだけ同時に並列処理され、所要時間Ｔｐで処理が完了する。

図１は、本発明の一実施例に係る接続要求、切断要求の処理手順を示す図である。
利用者端末１からセッション制御サーバ３０に対して、利用開始（接続）要求を行うと、セッション制御サーバ３０は呼設定処理を行って、受付制御サーバ２０に対してリソース確保（接続）要求を行う。受付制御サーバ２０はリソース確保処理を行い、セッション制御サーバ３０に対して、リソース確保応答を行う。セッション制御サーバ３０は呼設定処理を行って、要求のあった利用者端末１に対して、利用開始応答を行う。
利用者端末１が相手方と接続された後、通信を行い、用件が終了したときには、利用者端末１からセッション制御サーバ３０に対して、利用終了（切断）通知を行う。セッション制御サーバ３０は、終了処理を行って、受付制御サーバ２０に対してリソース解放（切断）要求を行う。受付制御サーバ２０は、リソース解放処理を行い、セッション制御サーバ３０に対してリソース解放応答を行う。これにより、セッション制御サーバ３０は、切断時刻記録を行う。

図２は、本発明における利用開始時の通信制御サーバの連携の例を示す図である。
利用者端末を収容するセッション制御サーバと、ネットワークで使用するリソースを管理する受付制御サーバとは、図２に示すような連携を行っている。
丸内の数字の順序で処理が進行される。
（１）利用者１（発信者）の端末からのこの端末を収容しているセッショ制御サーバ３１に対して利用開始要求が送信されると、（２）セッション制御サーバ３１は、利用開始要求の着信先の利用者２が収容されているセッション制御サーバ３２に対して利用開始要求を転送する。（３）セッション制御サーバは、利用者２（着信）の端末に着信の通知を行う。また、（４）セッション制御サーバ３２は、受付制御サーバ２２に対してリソース確保要求を送信する。（５）受付制御サーバ２２が管理するリソースを確保すると、セッション制御サーバ３２は、セッション制御サーバ３１に対して利用開始要求応答を返送する。（６）セッション制御サーバ３１は、受付制御サーバ２１に対してリソース確保要求を送信する。（７）受付制御サーバ２１が管理するリソースを確保すると、セッション制御サーバ３１は、利用者１（発信）の端末に対して利用開始要求応答（通話開始）を返送する。このような連携により、利用者１はネットワーク１１を経由して利用者２と通話することができる。

（実施例）
以下、図２により説明する。
Ｉ）セッション制御サーバと受付制御サーバの連携
受付制御サーバを例にとり説明する。ある利用者がＩＰ電話のサービスにおいて発信したと仮定する。まず、利用者１の端末から通話開始の意思を表す呼設定開始（セットアップ）通知が発信される。呼設定開始の通知は、ＳＩＰ（ＳｅｓｓｉｏｎＩｎｉｔｉａｔｉｏｎＰｒｏｔｏｃｏｌ）などを使用して、セッション制御サーバ３１に達する。セッション制御サーバ３１では、利用者の認証や電話番号から着信者の位置の特定などの処理を行う。ネットワーク規模などにもよるが、呼設定は複数台のセッション制御サーバを経由して行われることもある。着信者側までの通話開始条件が解決されると、着信者２の端末への呼び出し信号の送出、発信者１への通話開始通知などが順次行われる。

ここで、サービス品質の確保のため、帯域管理・受付制御を適用している場合には、これらの呼設定処理の途中で、受付制御サーバ２１，２２に対して該当通信が使用するネットワークリソースが利用可能か否かの問い合わせ、および、そのリソース確保が要求される。これが、リソース確保処理であり、受付制御サーバ２１，２２にとっての接続要求に該当する。
また、通信が終了したときには、セッション制御サーバ３１，３２に通話切断が通知される。ここで、セッション制御サーバ３１，３２では、課金のための切断時刻の記録が行われる。また、切断処理の中で、接続処理のときと同様に受付制御サーバ２１，２２にも切断通知が行われる。これは、受付制御サーバ２１，２２において、該当呼に対して確保しておいたネットワークリソースを解放するためであり、受付制御サーバ２１，２２にとっての切断要求である。
セッション制御サーバ３１，３２と受付制御サーバ２１，２２間には、この他にもサービス運用を継続するためのメッセージのやり取りが多く必要であるが、本発明は呼設定処理に関連するものであり、特に呼設定処理中の接続要求処理・切断要求処理がサーバ処理容量の大部分を占める状況での処理方式に関するものであるため、ここでは説明を省略する。

II）受付制御サーバ内の呼処理
受付制御サーバが行うべき処理は様々であるが、本発明の適用において主に論じられる高負荷状況では、その処理の殆んどが接続（リソース確保）要求処理と切断（リソース解放）要求処理に占められるため、ここではこの２つの処理について説明する。
前述のように、受付制御サーバにはセッション制御サーバから接続要求・切断要求呼が頻繁に到着する。受付制御サーバは、接続要求と切断要求に対しては異なるキューを持ち、要求呼の到着時に各キューに振り分ける。

III）スケジューリングにＰＱを適用する場合
ＰＱ（プライオリティ・キューイング）は、呼処理タスクがキューからイベントを取り出す際に、キュー間で取り出し順序の優先制御を行うスケジューリングアルゴリズムである。
キューに対して優先度を付ける。接続要求キューを高優先、切断要求キューを低優先とする。呼処理タスクはある呼処理が終了した後、まず高優先の接続要求キューを確認し、イベントがあればそれを取り出して実行する。なければ、低優先の切断要求キューを確認し、イベントがあれば処理する。全てのキューにイベントがなければ、待ち状態に入り、後にイベントが発生し呼び出されるまで待機する。

IV）スケジューリングにＷＲＲを適用する場合
ＷＲＲ（ウェイテッド・ラウンドロビン）は、呼処理タスクがキューからイベントを取り出す際に、キュー間で取り出し順序の優先制御を行うスケジューリングアルゴリズムである。
キューに対して優先度を付ける。接続要求キューを高優先、切断要求キューを低優先とする。呼処理タスクは、ある呼処理が終了した後のキューの取り出しにおいて、接続要求キューと切断要求キューの取り出し頻度を差別化する。例えば、接続要求を４度取り出す（または、接続要求キューに待ちイベントがなくなる）までは切断要求キューからの取り出しを行わわず、切断要求キューからは１度の取り出しを行ったならば、接続要求キューからの取り出しに戻る、と言うような制御を行うと、接続要求処理が８０％、切断要求処理が２０％の割合で処理実行を差別化することができる。

Ｖ）高負荷時の接続処理応答時間の短縮（効果１）
スケジューリングにＰＱを適用した場合を例に説明する。
待ち行列型のシステムでは、要求呼の到着頻度がシステムの処理容量（単位時間当りの処理量）に近くなり、また、これを超えると、待ち行列中の待ちイベント数が多くなっていく。待ち行列が長いと、各イベントが処理実行開始まで待たされる時間が長くなる。
受付制御サーバに到着する接続要求呼の頻度をｇとし、簡単のために接続要求呼数と切断要求呼数が等しく（すなわち、全ての接続要求に対する呼設定が成功し、接続要求と対になる切断要求が必ず存在する）、受付制御サーバ内の接続要求処理と切断要求処理の処理負荷（処理ステップ数、実行に要する時間）が等しいと仮定する。

このとき、受付制御サーバは、接続・切断を合わせてλ＝２ｇの頻度で処理要求が到着しており、これが受付制御サーバのスループットＳに達すると、システムの処理容量が飽和し、キューにおける処理待ちの発生が多くなる。受付制御サーバのプロセッサの実行制御が効率的に行われる場合、プロセッサ使用率は１００％近くに達する。
ここで、本発明のように、接続・切断要求処理の実行の優先制御が行われていない場合には、呼処理タスクは両方のキューから平等にイベントを取り出すため、両方のキューにおいて同じように待ち行列が長くなり、待ち時間が延びていく。
これに対して、本発明の優先制御が適用されると、接続要求呼は優先的に実行されるため、プロセッサのリソースは接続要求呼に対して優先的に使用され、残りが切断要求呼に使用される。Ｓ＜λ＝２ｇ、つまりｇ＞Ｓ／２の場合には、接続・切断要求呼の総数に対してプロセッサの容量が不足するため、非優先の切断要求呼がリソースを使用できず、待ち行列が伸びていくことになる。
接続要求呼の頻度がさらに高まり、ｇ＞Ｓとなった場合には、プロセッサのリソースの全てを接続要求処理に使用しても不足が生じる。この時、初めて接続要求呼においても、待ち行列の取り出しより到着頻度が高くなり、待ち行列の伸長が発生する。

本発明を適用しなかった場合には、前記の図３に示すように、λがＳに近づくと、つまり接続要求呼の到着頻度ｇがＳ／２に近づくと接続・切断処理ともに処理待ち時間が急激に増加し、利用者に対するサービス品質が保てなくなるが、本発明を適用した場合にはｇがＳに達するまでは数ミリ秒の待ち時間を保ち、処理実行に要する数ミリ秒と合わせても要求条件を満たした範囲内での応答が可能となる。
図５は、本発明を適用した場合の図であって、イベントの取り出しにＰＱ，ＷＲＲのスケジューリングアルゴリズムを適用して、優先制御を行った場合の、計算機シミュレーションによるキュー滞在時間の評価結果のグラフである。

VI）輻輳耐性の向上（効果２）
一般的には、このような要求呼の到着頻度が高まった場合の応答時間の伸長への対策として、キュー長（待ち呼数）の伸長の発生原因であるプロセッサ使用率の上昇を監視し、設定したしきい値を超えた場合に新規呼の到着を規制する輻輳制御機能を実装する。
本発明を適用しなかった場合には、プロセッサ使用率が１００％に達すると応答時間が要求条件を満たせなくなるため、１００％の手前にしきい値を設け、しきい値を超えたならば規制を発動する必要がある。
これに対して、本発明を適用した場合には、プロセッサ使用率が１００％を超えても接続要求の応答時間は要求条件を満たすことが可能であるため、プロセッサ使用率１００％以下での輻輳制御発動を行う必要はなく、輻輳に対する耐性が向上する。

ただし、要求呼の到着頻度がサーバのスループットを超え、プロセッサ使用率が１００％以上に達した状態が継続すると、非優先の切断要求呼のキューが伸長し、キュー長オーバー（バッファ溢れ）や未解放呼の滞留によるリソース効率の低下が発生するため、プロセッサ使用率が１００％以上の状態に耐用できる継続時間には限度があり、継続時間を考慮した別の輻輳制御を導入する必要がある。

図１および図２に示す手順では、セッション制御サーバと受付制御サーバが接続され、両サーバが連携して処理を行う手順の例が示されているが、本発明では、セッション制御サーバと連携するサーバとして、受付制御サーバ以外の呼処理サーバでも適用できる。すなわち、受付制御サーバ以外にも、切断要求処理に対する対応時間が厳しくない呼処理サーバが存在する場合には、受付制御サーバに置換えてその呼処理サーバを連携サーバとしてもよい。

図２のシーケンスチャートを示す手順をプログラムに変換し、そのプログラムをＣＤ−ＲＯＭなどの記録媒体に格納しておけば、記録媒体をセッション制御サーバや受付制御サーバのプロセッサに装着し、記録媒体からプログラムをインストールしてこれを実行させることで、本発明を容易に実現することができる。また、インターネットを介して他のプロセッサにダウンロードすることにより、このプログラムを汎用化することも可能である。

本発明における利用者端末、通信制御サーバ間の接続要求、切断要求の連携と処理手順の例を説明する図である。本発明における利用開始時の利用者端末、通信制御サーバ間の連携方法の例を示す図である。Ｔ_ｐ＝８〔ｍｓｅｃ〕と仮定した場合の要求到着頻度に対するキュー滞在時間の推移をクロメリン−ボラチェックの公式を用いて算出したグラフである。本発明の呼実行制御方法を説明するための原理図である。本発明において、イベントの取り出しにＰＱ，ＷＲＲのスケジューリングアルゴリズムを適用して、優先制御を行った場合の、計算機シミュレーションによるキュー滞在時間の評価結果のグラフである。

符号の説明

１利用者（発信）端末
２利用者（着信）端末
１１ネットワーク
３０，３１，３２セッション制御サーバ
２０，２１，２２受付制御サーバ
６０接続要求キュー
７０切断要求キュー

Claims

通信サービスの利用開始時に接続要求を受信し、それに対する呼設定処理を、および、利用終了時に終了通知を受信し、それに対する終了処理を、それぞれ行うサーバの通信制御処理実行方法において、
前記サーバは、前記両処理の要求呼に対して、優先度の異なる２種類以上のキューを持ち、呼処理時のキュー取り出しにおいては接続要求処理の実行を切断要求処理の実行よりも優先して行うことを特徴とする通信制御処理実行方法。
請求項１に記載の通信制御処理実行方法において、
前記サーバは、キューからイベントを取り出す際に、キュー間で取り出し順の優先制御を行う場合に、ＰＱ（プライオリティ・キューイング）、ＷＲＲ（ウェイテッド・ラウンドロビン）などのスケジューリングアルゴリズムを適用し、応答時間条件の厳しい処理要求呼を優先して処理する特徴とする通信制御処理実行方法。
通信サービスの利用開始時に接続要求を受信し、それに対する呼設定処理を、および、利用終了時に終了通知を受信し、それに対する終了処理を、それぞれ行うシステムにおいて、
利用端末から利用開始要求を受信した際には呼設定処理、および受付制御サーバにリソース確保要求を行い、終了通知を受信した際には呼切断処理、および受付制御サーバにリソース解放要求を行うセッション制御サーバと、
ネットワークで使用するリソースを管理し、前記セッション制御サーバからリソース確保要求を受けた際にリソース確保を行い、リソース解放要求を受けた際にリソースの解放を行う受付制御サーバであって、
優先度の高い要求と優先度の低い要求に対して、呼処理バッファ内の異なる複数のキューに登録し、該キューから要求呼を取り出して、実行する際には、優先度の高い要求を優先度の低い要求より優先して取り出し、実行する受付制御サーバと、
前記セッション制御サーバに利用開始要求を行い、かつ該セッション制御サーバから着信の通知を受け取る利用者端末と
を有することを特徴とする通信制御処理システム。
請求項３に記載の通信制御処理システムにおいて、
前記受付制御サーバを、該受付制御サーバおよびセッション制御サーバ以外の通信制御サーバに置き換えて、同様のキュー登録処理、および優先実行処理を行わせることを特徴とした通信制御処理システム。
受付制御サーバの通信制御処理プログラムであって、
該受付制御サーバのプロセッサに、セッション制御サーバからリソース確保要求を受け取る手順、該リソース確保要求呼を呼処理バッファ内の優先度の高い要求呼を蓄積するキューに登録する手順、優先度の高いキューから該リソース確保要求呼を取り出し、優先的に処理する手順、該リソース確保要求呼が使用するネットワークリソースの使用状況を確認し、該リソース確保要求呼の受付可否を判定する手順、該リソース確保要求呼の受付が可能であった場合にネットワークリソースを確保する手順、受付判定結果を前記セッション制御サーバに通知する手順、前記セッション制御サーバから前記リソース確保要求呼に対応するリソース解放要求を受け取る手順、該リソース解放要求を呼処理バッファ内の優先度の低い要求呼を蓄積するキューに登録する手順、優先度の低いキューから該リソース確保要求呼を取り出し、処理する手順、該リソース確保解放呼に対応するリソース確保が求呼が使用していたネットワークリソースを解放する手順を、それぞれ実行させるための通信制御処理プログラム。