JP3888762B2 - マルチタスクシステムの輻輳制御装置 - Google Patents
マルチタスクシステムの輻輳制御装置 Download PDFInfo
- Publication number
- JP3888762B2 JP3888762B2 JP05377498A JP5377498A JP3888762B2 JP 3888762 B2 JP3888762 B2 JP 3888762B2 JP 05377498 A JP05377498 A JP 05377498A JP 5377498 A JP5377498 A JP 5377498A JP 3888762 B2 JP3888762 B2 JP 3888762B2
- Authority
- JP
- Japan
- Prior art keywords
- load
- congestion control
- processing
- dependent
- magnitude
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Exchange Systems With Centralized Control (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、実質的に独立した複数の処理を単一の処理ユニットで並列的に実行するマルチタスクシステムで利用される輻輳制御装置に関する。
特に本発明の輻輳制御装置は、特定の第１の処理の実行に伴って生成される従属データに対して第２の処理を実行するとともに、前記第１の処理と第２の処理とを互いに異なる実行レベルで並列的に実行するマルチタスクシステムで利用される。
例えば、ディジタル交換機を制御するマルチタスクシステムにおいては、メインのサービス（第１の処理）として呼処理を実行する。すなわち、発信側端末装置からの発呼に応答して発信側端末装置と受信側端末装置との回線の接続を確立し、発信側端末装置と受信側端末装置との間におけるデータ転送を処理する。
また、ディジタル交換機の制御においては、メインのサービスに付随して課金データが生成される。課金データに対する処理（第２の処理）は、メインのサービスに比べて優先順位の低い下位の実行レベルで処理される。
【０００２】
【従来の技術】
逐次入力されるデータを処理する様々な処理装置においては、入力データ量が過大になると、プロセッサの処理能力の不足、あるいは利用可能なメモリの不足によって新たな処理の実行ができなくなる。このような輻輳状態の発生を防止するために輻輳制御装置が用いられる。
【０００３】
この種の輻輳制御装置の従来技術としては、特開昭６２ー１１３５５号公報や特開平５ー３４４５５２号公報が知られている。
特開昭６２ー１１３５５号公報の技術では、主プロセッサと従プロセッサを備える交換機の処理装置において、輻輳発生時には、輻輳の発生条件に応じて従プロセッサのみ又は主プロセッサと従プロセッサの両方の負荷を規制する。
【０００４】
特開平５ー３４４５５２号公報の技術では、処理待ちタスク及び処理済みタスクを監視して輻輳の発生を検知する。また、輻輳が発生した場合には、負荷の大きい回線を優先的に規制する。
【０００５】
【発明が解決しようとする課題】
従来の輻輳制御装置においては、主要なサービスを提供するうえで必要な資源、すなわちプロセッサの使用率やメインメモリの使用率に基づいて、輻輳の有無を識別し規制の発動を制御している。
【０００６】
この種の輻輳制御では、主要なサービス（例えば呼処理）の実行に伴って生成される従属データ（例えば課金データ）の特性や条件とは無関係に規制が発動される。
ところで、複数の処理を並列的に処理するマルチタスクシステムにおいては、各々のタスクに優先順位あるいは実行レベルが割り当てられる。優先順位の高いタスクには、比較的高い比率で処理装置の資源（プロセッサの使用率やメモリの使用率）が割り当てられ、優先順位の低いタスクには少ない資源が割り当てられる。
【０００７】
一般に、輻輳の発生によって規制が発動された場合に、優先順位の高い処理が受ける影響は比較的小さい。しかし、優先順位の低い処理は大きな影響を受ける。つまり、優先順位の低い処理は、それを実行可能な機会（タイミング）が大幅に減る。
従って、主要なサービスを優先順位の高いタスクで実行し、主要なサービスによって生成される従属データを優先順位の低いタスクで処理する場合には、輻輳の規制が発動されると、従属データの発生頻度が高いにもかかわらず、優先順位の低いタスクの実行頻度が大幅に低下するので、従属データに対する処理が間に合わなくなる。
【０００８】
例えば、呼処理を優先順位の高いタスクで実行し、課金データの処理を優先順位の低いタスクで実行するディジタル交換機においては、輻輳が発生した場合に課金データ処理の実行頻度が著しく低下する。また、未処理の課金データを保持するためのメモリ容量は有限である。そのため、発生する重要な課金データが部分的に未処理のまま廃棄され、消失する可能性がある。
【０００９】
本発明は、マルチタスクシステムの輻輳制御装置において、輻輳が発生した場合に、第１の処理の実行に伴って発生する未処理の従属データの消失を防止することを主な目的とする。
【００１０】
【課題を解決するための手段】
図１に本発明の請求項１〜請求項１２の構成に対応する機能ブロック図を示す。図１を参照しながら本発明の構成を以下に説明する。
【００１１】
請求項１のマルチタスクシステムの輻輳制御装置は、互いに独立した複数の処理を並列的に実行するとともに、特定の第１の処理１１の実行に伴って生成される従属データ１２に対して、前記第１の処理１１より優先度が低い第２の処理１３をタスク管理に基づいて実行するマルチタスクシステムの輻輳制御装置において、処理の優先度の情報を有する前記従属データ１２の状態に基づいて、前記第２の処理１３に関する負荷の大きさを検出する従属負荷検出手段１５と、前記従属負荷検出手段１５が検出した第２の処理１３に関する負荷の大きさに基づいて、前記第１の処理１１を規制する従属負荷規制手段１６とを設けたことを特徴とする。
【００１２】
請求項１記載の発明においては、輻輳状態が発生して規制が発動されると、前記第２の処理１３の実行頻度が低下するため、未処理の従属データ１２が増大する。この場合、従属負荷検出手段１５が検出する第２の処理１３に関する負荷の大きさも増大する。
従って、従属負荷規制手段１６が第１の処理１１を規制する。第１の処理１１が規制されると、第１の処理１１の実行に伴って発生する従属データ１２の増大が抑制される。
【００１３】
つまり、第２の処理１３の実行頻度が低下してその処理能力が減少すると、第２の処理１３によって処理すべき従属データ１２の発生が抑制されるので、未処理の従属データ１２の消失防止に役立つ。
請求項２は、請求項１記載のマルチタスクシステムの輻輳制御装置において、前記従属データ１２として処理の優先度が互いに異なる複数種類のデータが存在する場合に、前記従属負荷検出手段１５が、第２の処理１３に関する負荷の大きさを、優先度の区分に応じて複数検出することを特徴とする。
【００１４】
例えばディジタル交換機において生成される課金データには、処理上の優先度が高いものと低いものとがある。すなわち、通話毎に料金の計算が必要な課金データについては、通話終了とほぼ同時に出力する必要があるので、処理の優先度が高い。また、定期的に行われる課金パルスの積算処理によって料金が計算される課金データについては、多少の処理の遅れは問題にならないので、処理の優先度が低い。
【００１５】
また、ディジタル交換機の場合には、従属データ１２として課金データの他にトラヒックデータなども生成される。課金データとトラヒックデータとは、処理の優先度や重要度が異なる。
請求項２の発明においては、従属負荷検出手段１５が第２の処理１３に関する負荷の大きさを優先度の区分に応じて複数検出するので、優先度に応じた輻輳制御が可能である。例えば、優先度の高い課金データの消失を防止することを最優先し、優先度の低い従属データの処理の遅れが輻輳制御に及ぼす影響を小さくするように輻輳制御することもできる。
【００１６】
請求項３は、請求項２記載のマルチタスクシステムの輻輳制御装置において、前記従属負荷検出手段１５が、処理対象の従属データ１２の優先度の区分に応じて、予め用意された複数組のパラメータ１４の中から１組のパラメータ１４を選択し、選択された前記パラメータ１４に基づいて第２の処理１３に関する負荷の大きさを識別することを特徴とする。
【００１７】
請求項３の発明においては、複数組のパラメータ１４が用意されているので、優先度が異なる複数の従属データ１２の負荷の大きさを、それぞれに適した条件で求めることができる。
請求項４は、請求項１記載のマルチタスクシステムの輻輳制御装置において、前記従属負荷検出手段１５が、前記従属データ１２の未処理の情報量と、前記従属データ１２に割り当てられた記憶領域の大きさとに基づいて第２の処理１３に関する負荷の大きさを検出することを特徴とする。
【００１８】
輻輳状態に陥り処理の規制が発動されると、第２の処理１３の実行頻度が低下する。一方、規制によって優先度の高い第１の処理１１が受ける影響は小さいので、新たな従属データ１２の発生頻度もあまり変化しない。その結果、第２の処理１３の実行の遅れが生じ、従属データ１２の未処理の情報量が増える。
通常、従属データ１２に割り当てられる記憶領域の大きさは一定なので、従属データ１２の未処理の情報量が増えると、割り当てられた記憶領域全体に占める未処理の従属データ１２の割合、すなわちメモリ使用率が増大する。
【００１９】
請求項４の発明においては、従属データ１２に関するメモリ使用率を監視するので、第２の処理１３の実行の遅れ、すなわち第２の処理１３に関する負荷の大きさを検出することができる。
【００２０】
請求項５は、請求項１記載のマルチタスクシステムの輻輳制御装置において、前記第１の処理１１の実行に伴って変化するシステム資源１７の利用状況に基づいて、第１の処理１１に関する負荷の大きさを検出する一次負荷検出手段１８を更に設け、前記従属負荷規制手段１６が、前記一次負荷検出手段１８の検出した第１の処理１１に関する負荷の大きさと、前記従属負荷検出手段１５の検出した第２の処理１３に関する負荷の大きさとに基づいて前記第１の処理１１を規制することを特徴とする。
【００２１】
第１の処理１１に関する負荷の大きさが増大すると、第２の処理１３に関する負荷の大きさも増大する。従って、第２の処理１３に関する負荷の大きさに基づいて前記第１の処理１１を規制すれば、輻輳状態の緩和に効果がある。
しかし、第１の処理１１の負荷の増大に比べて、第２の処理１３の負荷の増大は多少遅れる。従って、例えば急激にトラヒック量が増大した場合には、輻輳状態の検出及び処理の規制が遅れる可能性がある。
【００２２】
請求項５の発明においては、第１の処理１１に関する負荷の大きさと、第２の処理１３に関する負荷の大きさとに基づいて前記第１の処理１１を規制するので、第１の処理１１の負荷が急激に増大する場合であっても、輻輳状態の検出の遅れが生じにくい。
上記システム資源１７は、各タスクに割り当てられるプロセッサの処理やメモリ領域などを意味する。
【００２３】
請求項６は、請求項５記載のマルチタスクシステムの輻輳制御装置において、前記従属負荷規制手段１６が、前記第１の処理１１に関する負荷の大きさと、第２の処理１３に関する負荷の大きさとを比較して、何れか大きい方に基づいて前記第１の処理１１を規制することを特徴とする。
請求項６においては、第１の処理１１に関する負荷の大きさと、第２の処理１３に関する負荷の大きさとの何れか大きい方に基づいて第１の処理１１が規制される。従って、第１の処理１１の負荷と第２の処理１３の負荷の何れかが増大すれば、第１の処理１１が規制されるので輻輳制御の遅れが生じにくい。
【００２４】
請求項７は、請求項６記載のマルチタスクシステムの輻輳制御装置において、前記従属負荷規制手段１６が、前記第１の処理１１に関する負荷の大きさと、第２の処理１３に関する負荷の大きさとの少なくとも一方を重み付け補正し、重み付け補正後の第１の処理１１に関する負荷の大きさと、第２の処理１３に関する負荷の大きさとを比較して、何れか大きい方に基づいて前記第１の処理１１を規制することを特徴とする。
【００２５】
請求項７においては、第１の処理１１に関する負荷の大きさと、第２の処理１３に関する負荷の大きさの少なくとも一方が重み付け補正される。従って、第１の処理１１及び第２の処理１３の特性や重要度などを考慮した上で両者を比較することができる。
請求項８は、請求項５記載のマルチタスクシステムの輻輳制御装置において、前記従属負荷規制手段１６が、前記第１の処理１１に関する負荷の大きさと、第２の処理１３に関する負荷の大きさとを平均化した結果に基づいて前記第１の処理１１を規制することを特徴とする。
【００２６】
請求項８においては、第１の処理１１の負荷と第２の処理１３の負荷の少なくとも一方が増大すれば、第１の処理１１が規制されるので輻輳制御の遅れが生じにくい。
請求項９は、請求項８記載のマルチタスクシステムの輻輳制御装置において、前記従属負荷規制手段１６が、前記第１の処理１１に関する負荷の大きさと、第２の処理１３に関する負荷の大きさとの少なくとも一方を重み付け補正して、重み付け補正後の第１の処理１１に関する負荷の大きさと、第２の処理１３に関する負荷の大きさとを平均化した結果に基づいて前記第１の処理１１を規制することを特徴とする。
【００２７】
請求項９においては、第１の処理１１に関する負荷の大きさと、第２の処理１３に関する負荷の大きさの少なくとも一方が重み付け補正される。従って、第１の処理１１及び第２の処理１３の特性や重要度などを考慮した上で、第１の処理１１の規制を制御できる。
請求項１０は、請求項５記載のマルチタスクシステムの輻輳制御装置において、処理の優先度が互いに異なる複数種類の従属データ１２が存在する場合に、前記従属負荷規制手段１６が、第２の処理１３に関する複数区分の負荷の大きさを平均化して、平均化された第２の処理１３の負荷の大きさと、前記第１の処理１１に関する負荷の大きさとに基づいて前記第１の処理１１を規制することを特徴とする。
【００２８】
請求項１０においては、優先度の比較的高い従属データ１２に対する第２の処理１３の負荷が増大した場合でも、優先度の比較的低い従属データ１２に対する第２の処理１３の負荷が増大した場合でも、第１の処理１１を規制することができる。
請求項１１は、請求項１記載のマルチタスクシステムの輻輳制御装置において、前記従属負荷検出手段１５が、前記第２の処理１３に関する負荷の大きさを周期的に検出するとともに、検出された負荷の大きさの変化量と予め定めた閾値との比較結果に応じて、検出された第２の処理１３に関する負荷の大きさを補正することを特徴とする。
【００２９】
請求項１１においては、第１の処理１１の規制を制御する際に、第２の処理１３に関する負荷の大きさの変化量、すなわち微分値を考慮することができる。従って、急激な負荷の変動に対する輻輳制御の応答性や、一時的な負荷の変動に対する応答性を調整できる。
請求項１２は、請求項１記載のマルチタスクシステムの輻輳制御装置において、前記従属負荷規制手段１６が、前記従属負荷検出手段１５が検出した第２の処理１３に関する負荷の大きさが予め定めた下限閾値より小さい場合には、前記第１の処理１１の規制を解除もしくは緩和することを特徴とする。
【００３０】
請求項１２においては、輻輳状態の検出によって第１の処理１１の規制が発動された後、第２の処理１３に関する負荷が減少すると、第１の処理１１の規制が自動的に解除もしくは緩和される。
【００３１】
【発明の実施の形態】
（第１の実施の形態）
この形態のマルチタスクシステムの輻輳制御装置の構成と動作を図２〜図１５に示す。この形態は、請求項１〜請求項５並びに請求項８〜請求項１２に対応する。
【００３２】
図２は、マルチタスクシステムの輻輳制御装置を備えるディジタル交換機のハードウェアの構成例を示すブロック図である。図３は、図２のシステム制御部１００で実行されるソフトウェアの主要部の構成を示すブロック図である。
図４は、従属データ処理タスク２２１の課金データ生成シーケンスを示すフローチャートである。図５は、従属データ処理タスク２２１が生成する優先度の大きい課金データの構成を示すマップである。図６は、従属データ処理タスク２２１が生成する優先度の小さい課金データの構成を示すマップである。
【００３３】
図７は、図３の輻輳制御系２００により実現される輻輳制御の制御シーケンスの一部分を示すフローチャートである。図８は、図３の輻輳制御系２００により実現される輻輳制御の制御シーケンスの一部分を示すフローチャートである。図９は、図７のステップ４１１の処理の内容を示すフローチャートである。
図１０は、図８のステップ４２５の処理の内容を示すフローチャートである。図１１は、図７のステップ４３０の処理の内容を示すフローチャートである。図１２は、図７のステップ４３１の処理の内容を示すフローチャートである。
【００３４】
図１３は、図１２の処理によって実現する規制レベルの状態遷移を示すフローチャートである。図１４は、図８のステップ４３５の処理の内容を示すフローチャートである。図１５は、図８のステップ４３５の処理で参照される呼規制ビットマップの構成例を示すマップである。
この形態では、請求項１の第１の処理１１，従属データ１２，第２の処理１３，従属負荷検出手段１５及び従属負荷規制手段１６は、それぞれ呼処理タスク２１１，従属データ２０３，従属データ処理タスク２２１，二次規制値算出タスク２２３及び呼処理規制タスク２３２として具体化されている。
【００３５】
また、請求項５の一次負荷検出手段１８は、一次規制値算出タスク２１３として具体化されている。
図２を参照すると、このディジタル交換機はシステム制御部１００，回線インタフェース部１１０，セルスイッチ部１２０，シグナリング／クロック部１３０，ハードディスク１４０及び保守運用端末装置１５０で構成されている。
【００３６】
回線インタフェース部１１０に接続されるデータ通信回線１１１に含まれる各々の回線は、セルスイッチ部１２０を介して指定された別の回線と接続される。システム制御部１００は、回線インタフェース部１１０，セルスイッチ部１２０及びシグナリング／クロック部１３０を制御して、各回線間でのデータ転送を処理する。
【００３７】
システム制御部１００には、プロセッサバス１０６を介して互いに接続されたプロセッサ１０１，メインメモリ１０２，システムバス制御部１０３，ＳＣＳＩインタフェース１０４及びＬＡＮインタフェース１０５が備わっている。
なお、システムの信頼性を高めるために、図２のディジタル交換機の主要な構成要素は各々２組備わっている。また、２組のシステムは必要に応じて切り替え可能である。しかし、本発明とは直接関連がないので、図２においては１組の構成要素を省略して１組の構成だけを示してある。
【００３８】
図３に示すディジタル交換機の制御系は、図２に示すプロセッサ１０１のソフトウェアの実行によって実現する。ハードウェアと直接関連のある処理や基本的な処理は、オペレーティングシステム２０１によって実現する。
オペレーティングシステム２０１の動作の下で、様々なタスクを並列的に実行することができる。プロセッサ１０１の利用時間は小さいタイムスロット毎に予め区分され、各々のタイムスロットの利用権利が、各々のタスクに割り当てられる。従って、複数のタスクを時分割で実質的に同時に処理できる。
【００３９】
優先順位の高いタスクには、多くのタイムスロットが割り当てられるので、優先順位の高いタスクでは、短い時間で大量の処理を実行できる。優先順位の低いタスクには、僅かなタイムスロットが割り当てられるので、優先順位の低いタスクの処理能力は低い。
例えば、輻輳制御によってプロセッサ１０１の使用率（単位時間当たりのタスクの占有時間）が制限されると、優先順位の低いタスクが実行される頻度は大幅に低下する。
【００４０】
図３に示す制御系においては、オペレーティングシステム２０１上で実行されるタスクとして、メモリ管理タスク２０２，呼処理タスク２１１，呼処理リソース監視タスク２１２，一次規制値算出タスク２１３，従属データ処理タスク２２１，従属データリソース監視タスク２２２，二次規制値算出タスク２２３，規制値識別タスク２３１及び呼処理規制タスク２３２が含まれている。
【００４１】
メモリ管理タスク２０２は、これ以外のタスクに対してメインメモリ１０２上のメモリ領域を割り当てる。また、メモリ管理タスク２０２は他の各タスクに割り当てられたメモリの利用状況を管理する。
図３においては、各タスクとオペレーティングシステム２０１との通信、並びにメモリ管理タスク２０２とそれ以外のタスクとの通信の経路が実線で示してある。また、メモリ管理タスク２０２を除くタスク間通信の経路は点線で示してある。
【００４２】
以下、図３の輻輳制御系２００に含まれる各タスクについて説明する。呼処理タスク２１１では、発呼，入呼，切断など「呼」に関する電話網の接続サービスを実施する。呼処理タスク２１１はディジタル交換機における主要なサービスなので、呼処理タスク２１１の処理上の優先順位は比較的高い。
ところで、呼処理タスク２１１を実行すると、それに付随して課金データやトラヒックデータなどが従属データ２０３として生成される。呼処理タスク２１１に伴って生成された従属データ２０３に関しては、フォーマットの変換，データ蓄積などの二次的な処理を実行しなければならない。この二次的な処理は、呼処理タスク２１１とは別の従属データ処理タスク２２１によって実行される。
【００４３】
従属データ処理タスク２２１は、処理すべき単位時間当たりのデータ量が比較的少ないので、処理の優先順位が呼処理タスク２１１よりも低い。通常の状態では、従属データ処理タスク２２１は呼処理タスク２１１に伴って生成される課金データやトラヒックデータを処理するのに十分な能力を有している。
ところが、輻輳状態になって処理に規制が掛けられた場合、呼処理タスク２１１で生成される課金データやトラヒックデータの量があまり変化しないにもかかわらず、従属データ処理タスク２２１の処理能力は大幅に低下する。
【００４４】
従って、輻輳状態になると、従属データ処理タスク２２１の処理の遅れによって、未処理の課金データやトラヒックデータの量が増大する。各々のタスクに割り当てられるメモリ領域の大きさは有限なので、未処理のデータ量が増大すると、新しいデータを記憶するメモリ領域を確保するために古いデータは廃棄しなければならない。
【００４５】
このため、輻輳状態になると、重要な課金データが未処理のまま消失する可能性がある。このような不具合を無くすために、図３に示す輻輳制御系２００においては、特別な輻輳制御を実施する。
従属データ処理タスク２２１で処理される従属データ２０３には、図５及び図６に示すような２種類の課金データが含まれる。図５に示す課金データは、処理の優先度が高いデータである。図６に示す課金データは、処理の優先度が低いデータである。
【００４６】
課金データ生成シーケンスの内容を図４に示す。なお、図４に示す一時記憶バッファ１０２ａ及びタスク割り当てメモリ１０２ｂは、各々メインメモリ１０２上に割り当てられた特定のメモリ領域である。
図４において、呼処理タスク２１１のステップ３０１で通話完了が検出された後、呼処理タスク２１１は、ステップ３０２で未処理の課金データの内容を従属データ処理タスク２２１に通知する。
【００４７】
従属データ処理タスク２２１では、新しい課金データが通知されると、そのデータをステップ３０３で一時記憶バッファ１０２ａに一時的に蓄える。また、従属データ処理タスク２２１は、一定の周期（500ｍsec）でステップ３０４，３０５，３０６の処理を繰り返し実行する。
ステップ３０４では、一時記憶バッファ１０２ａに保持された未処理の課金データを読み出す。ステップ３０５では、ステップ３０４で読み出した未処理の課金データのデータ形式を予め定めたフォーマットに変換し、図５及び図６に示すような課金データを生成する。生成した課金データは、ステップ３０６でタスク割り当てメモリ１０２ｂに書き込まれる。
【００４８】
更に、従属データ処理タスク２２１では、一定の周期（５sec）でステップ３０７，３０８を繰り返し実行する。ステップ３０７では、タスク割り当てメモリ１０２ｂに保持された課金データを読み出す。この課金データは、次のステップ３０８でハードディスク１４０に書き込まれる。
図３に示す輻輳制御系２００の処理によって実現する輻輳制御の制御シーケンスについて、図７及び図８を参照して説明する。
【００４９】
規制値識別タスク２３１は、図７のステップ４０１で呼処理タスク２１１に対してＣＰＵアイドル時間の出力を要求する。この要求はタスク間通信である。この要求に応答して、呼処理タスク２１１は、ステップ４０２でその時のＣＰＵアイドル時間を検出し、検出したＣＰＵアイドル時間CPUIdleを規制値識別タスク２３１に出力する。
【００５０】
このＣＰＵアイドル時間CPUIdleは、呼処理タスク２１１が利用できるプロセッサ１０１の処理時間のうち、実際に利用されていない空き時間に比例する数値であり、この例では０〜１０００の範囲内の値になる。実際には、呼処理タスク２１１は、オペレーティングシステム２０１に対するシステムコールを利用して、ＣＰＵアイドル時間CPUIdleを得る。
【００５１】
規制値識別タスク２３１は、ＣＰＵアイドル時間CPUIdleを受け取った後、ステップ４０３でＣＰＵ使用率CPUUsgを算出する。ＣＰＵ使用率CPUUsgは次式により算出される。
CPUUsg ＝（1000−CPUIdle）／10 ・・・ (1)
次のステップ４０４では、規制値識別タスク２３１は輻輳に関する規制が必要か否かを識別する。具体的には、ステップ４０３で得たＣＰＵ使用率CPUUsgを、予め定めた閾値CPUUsg0及びABFUsg0と比較する。
【００５２】
ＣＰＵ使用率CPUUsgが閾値CPUUsg0よりも大きいか、又はＣＰＵ使用率CPUUsgが閾値ABFUsg0よりも大きい場合には、規制値識別タスク２３１は規制要とみなしてステップ４０５に進む。ＣＰＵ使用率CPUUsgが閾値CPUUsg0及びABFUsg0以下の場合には、規制不要とみなすので、ステップ４０５，４１３，４３０，４３１及び４３２は実行されない。
【００５３】
ステップ４０５では、規制値識別タスク２３１は二次規制値算出タスク２２３に対して二次規制値の出力を要求する。この要求を受けると、二次規制値算出タスク２２３は、ステップ４０６で従属データリソース監視タスク２２２に対して従属データのメモリ使用率の出力を要求する。
従属データリソース監視タスク２２２は、従属データのメモリ使用率の出力要求を受けると、ステップ４０７で従属データ処理タスク２２１に対して従属データに関する負荷情報の出力を要求する。
【００５４】
従属データ処理タスク２２１は、割り当てられたメモリ領域の大きさD1_ABF，単位データのサイズD2_ABF及び未処理データ数D3_ABFを、従属データの種類（優先度の大きい課金データ，優先度の小さい課金データ，トラヒック情報など）毎にそれぞれ取得して、それらのデータをステップ４０８で従属データリソース監視タスク２２２に通知する。
【００５５】
従属データリソース監視タスク２２２は、従属データ処理タスク２２１から通知されたデータに基づいて、ステップ４０９で従属データの種類毎に従属データのメモリ使用率ABFUsgを算出する。メモリ使用率ABFUsgは次式で算出される。
ABFUsg＝（D2_ABF・D3_ABF）／D1_ABF ・・・ （２）
従属データのメモリ使用率ABFUsgは、従属データ処理タスク２２１の負荷の大きさに応じて変化する。
【００５６】
図４に示す従属データ処理タスク２２１のステップ３０７，３０８の処理は優先順位が非常に低いので、プロセッサ１０１の負荷が過大になると、最初に従属データ処理タスク２２１のステップ３０７，３０８の処理能力が大幅に低下する。その結果、タスク割り当てメモリ１０２ｂからハードディスク１４０へのデータ転送が滞る。
【００５７】
そして、タスク割り当てメモリ１０２ｂから掃き出されるデータの量に比べてタスク割り当てメモリ１０２ｂに書き込まれるデータの量が大きくなる。つまり、輻輳状態になると、タスク割り当てメモリ１０２ｂ上の従属データの量が徐々に増大し、従属データのメモリ使用率ABFUsgが上昇する。
従属データリソース監視タスク２２２が算出した従属データのメモリ使用率ABFUsgは、ステップ４１０の処理で二次規制値算出タスク２２３に通知される。
【００５８】
二次規制値算出タスク２２３は、ステップ４０６における要求に対して従属データのメモリ使用率ABFUsgが通知されると、それに基づいて二次規制値NL_ABFを従属データの種類毎にステップ４１１の処理で算出する。
ステップ４１１の処理の内容については、後で詳細に説明する。ステップ４１１で算出された従属データの種類毎の二次規制値NL_ABFは、ステップ４１２で規制値識別タスク２３１に通知される。つまり、規制値識別タスク２３１のステップ４０５における要求に対して、二次規制値NL_ABFが通知される。
【００５９】
また、規制値識別タスク２３１は、図８に示すステップ４１３で、一次規制値算出タスク２１３に対して一次規制値の出力を要求する。一次規制値算出タスク２１３は、一次規制値の出力要求を受けると、ステップ４２０で呼処理リソース監視タスク２１２に対して呼処理タスク２１１に関するＣＰＵ使用率CPUUsgの出力を要求する。
【００６０】
呼処理リソース監視タスク２１２は、ステップ４２１で呼処理タスク２１１に対して、ＣＰＵアイドル時間の出力を要求する。この要求に応答して、呼処理タスク２１１は、ステップ４２２でその時のＣＰＵアイドル時間を検出し、検出したＣＰＵアイドル時間CPUIdleを呼処理リソース監視タスク２１２に通知する。
呼処理リソース監視タスク２１２は、ＣＰＵアイドル時間CPUIdleを受け取った後、ステップ４２３でＣＰＵ使用率CPUUsgを算出する。この処理の内容は、規制値識別タスク２３１のステップ４０３と同じである（第１式参照）。
【００６１】
呼処理リソース監視タスク２１２は、算出したＣＰＵ使用率CPUUsgをステップ４２４で一次規制値算出タスク２１３に通知する。一次規制値算出タスク２１３は、呼処理リソース監視タスク２１２から得たＣＰＵ使用率CPUUsgに基づいて、ステップ４２５で一次規制値NL_CPUを算出する。
ステップ４２５の処理の内容については、後で詳細に説明する。一次規制値算出タスク２１３は、ステップ４２５で算出された一次規制値NL_CPUをステップ４２６で規制値識別タスク２３１に通知する。
【００６２】
規制値識別タスク２３１は、二次規制値算出タスク２２３から受け取った二次規制値NL_ABFと、一次規制値算出タスク２１３から受け取った一次規制値NL_CPUとに基づいて、ステップ４３０で受付可能呼数ＲＶを決定する。また、次のステップ４３１では規制レベルLV_CPUを算出する。これらの処理については、後で詳細に説明する。
【００６３】
規制値識別タスク２３１は、ステップ４３０で決定した受付可能呼数ＲＶとステップ４３１で算出した規制レベルLV_CPUとを、ステップ４３２で呼処理規制タスク２３２に通知する。また、規制の条件を満たす状態から条件を満たさなくなった場合には、規制緩和の指示を呼処理規制タスク２３２に通知する。
呼処理規制タスク２３２は、規制値識別タスク２３１から通知された受付可能呼数ＲＶ及び規制レベルLV_CPUに基づいて、受付呼数に関する規制率Ｒをステップ４３３で決定する。
【００６４】
実際には、規制レベルLV_CPUと規制率Ｒとを対応付ける呼規制率テーブルが予め用意されている。この例では、規制レベルLV_CPUには０，１，２の３レベルがある。呼規制率テーブルにおいては、規制レベルLV_CPUの「０」，「１」，「２」のそれぞれに対して、「０％」，「５０％」，「１００％」の規制率Ｒが割り当ててある。
【００６５】
呼処理規制タスク２３２は、上記呼規制率テーブルを参照して、規制レベルLV_CPUから規制率Ｒを求める。例えば、規制レベルLV_CPUが「１」の場合には規制率Ｒは５０％になる。なお、呼規制率テーブルの内容の変更は可能である。
また、呼処理規制タスク２３２は、ステップ４３４で受付可能呼数ＲＶ及び規制率Ｒを呼処理タスク２１１に通知する。更に、規制緩和の指示を受けた場合には、それを呼処理タスク２１１に通知する。
【００６６】
呼処理タスク２１１では、呼処理規制タスク２３２から呼の規制を指示する受付可能呼数ＲＶ及び規制率Ｒを通知された場合には、ステップ４３５で呼規制処理を実行する。この呼規制処理によって、呼処理タスク２１１の「呼」に対する処理が規制される。この処理については、後で詳細に説明する。
図７のステップ４１１で実行されるNL_ABF算出処理の内容を図９に示す。図９に記号で示される各パラメータは、次のように定義される。なお、これらのパラメータは従属データの種別に対応付けて複数組設けられている。処理対象の従属データの種別に応じて、１組のパラメータが選択的に使用される。
【００６７】
NL_ABF：従属データ処理タスク２２１の受付可能呼数
NA_ABF：前の処理サイクルにおけるNL_ABF（初期値：０）
ABFUsg：従属データのメモリ使用率
ABFUsgP：前の処理サイクルにおけるABFUsg
ABFUsgMax：ABFUsgの閾値（上限値：初期値は９０）
ABFUsg0：ABFUsgの閾値（NL_ABF算出を実行する下限値：初期値は５０）
ABFUsgRest：ABFUsgの閾値（輻輳検出レベル：初期値は７５）
MI：増加時のNL_ABF補正係数（０〜１の範囲内の値：初期値は０．５）
MD：減少時のNL_ABF補正係数（０〜１の範囲内の値：初期値は０．５）
AD：NL_ABF補正係数（０〜１の範囲内の値：初期値は０．５）
以下、図９を参照してNL_ABF算出処理の各ステップについて説明する。なお図９に示す処理は、例えば１秒周期で繰り返し実行される。
【００６８】
ステップ５０１では、従属データのメモリ使用率ABFUsgと閾値ABFUsg0とを比較する。所定の条件（ABFUsg＞ABFUsg0）を満たす場合にはステップ５０３に進む。この条件を満たさないときに、他のタスクから二次規制値の出力を要求された場合には、ステップ５０２で条件不一致のエラーを通知する。
ステップ５０３では、従属データのメモリ使用率ABFUsgと閾値ABFUsgRestとを比較する。所定の条件（ABFUsg＞ABFUsgRest）を満たす場合にはステップ５０４に進み、条件を満たさない場合にはステップ５０５に進む。
【００６９】
ステップ５０４及び５０５では、それぞれ次の第３式及び第４式に基づいて受付可能呼数NL_ABFを算出する。
NL_ABF＝NA_ABF・(ABFUsgMax−ABFUsg0)／(ABFUsg−ABFUsg0) ・・・(3)
NL_ABF＝NA_ABF・(ABFUsgP−ABFUsg0)／(ABFUsg−ABFUsg0) ・・・(4)
また、受付可能呼数NL_ABFが急激に変化するのを防止するために、ステップ５０６，５０７，５０８，５０９で補正処理を実施する。
【００７０】
受付可能呼数NL_ABFが増大するときには、ステップ５０６の処理によって、処理周期の１サイクルの間の変化量がチェックされる。そして、所定の条件（NL_ABF＞(1+MI)・NA_ABF）を満たす場合には、ステップ５０７で受付可能呼数NL_ABFが補正される。
また、受付可能呼数NL_ABFが減少するときには、ステップ５０８の処理によって、処理周期の１サイクルの間の変化量がチェックされる。そして、所定の条件（NL_ABF＜(1-MD)・NA_ABF）を満たす場合には、ステップ５０９で受付可能呼数NL_ABFが補正される。
【００７１】
また、従属データのメモリ使用率ABFUsgが異常に大きくなった場合には、ステップ５１０，５１１で更に補正を実施する。ステップ５１０では、メモリ使用率ABFUsgを上限値である閾値ABFUsgMaxと比較する。所定の条件（ABFUsg＞ABFUsgMax）を満たす場合には、ステップ５１１で受付可能呼数NL_ABFを補正する。
ステップ５１２では、求めた受付可能呼数NL_ABFを前サイクルの受付可能呼数NA_ABFとして保存する。
【００７２】
なお、図９には示されていないが、従属データは、優先度の高い課金データ，優先度の低い課金データ，トラヒックデータなどの種類毎にそれぞれ算出される。種類の異なる従属データを処理する場合には、それぞれ独立したパラメータが用いられる。
各パラメータの値については、保守運用端末装置１５０の操作により、次に示す制約の範囲内で変更可能である。
【００７３】
50 ≦ ABFUsg0 ≦ ABFUsgRest ≦ ABFUsgMax ≦ 100 ・・・ (5)
図８のステップ４２５で実行されるNL_CPU算出処理の内容を図１０に示す。図１０に記号で示される各パラメータは、次のように定義される。なお、これらのパラメータは従属データの種別に対応付けて複数組設けられている。処理対象の従属データの種別に応じて、１組のパラメータが選択的に使用される。
【００７４】
NL_CPU：呼処理タスク２１１の受付可能呼数
NA_CPU：前の処理サイクルにおけるNL_CPU（初期値：０）
CPUUsg：呼処理タスク２１１のＣＰＵ使用率
CPUUsgP：前の処理サイクルにおけるCPUUsg
CPUUsgMax：CPUUsgの閾値（上限値：初期値は９０）
CPUUsg0：CPUUsgの閾値（NL_CPU算出を実行する下限値：初期値は５０）
CPUUsgRest：CPUUsgの閾値（輻輳検出レベル：初期値は７５）
MA：増加時のNL_CPU補正係数（０〜１の範囲内の値：初期値は０．５）
MB：減少時のNL_CPU補正係数（０〜１の範囲内の値：初期値は０．５）
AD2：NL_CPU補正係数（０〜１の範囲内の値：初期値は０．５）
以下、図１０を参照してNL_CPU算出処理の各ステップについて説明する。なお図１０に示す処理は、例えば１秒周期で繰り返し実行される。
【００７５】
ステップ５５１では、呼処理タスク２１１のＣＰＵ使用率CPUUsgと閾値CPUUsg0とを比較する。所定の条件（CPUUsg＞CPUUsg0）を満たす場合にはステップ５５３に進む。この条件を満たさないときに、他のタスクから一次規制値の出力を要求された場合には、ステップ５５２で条件不一致のエラーを通知する。
ステップ５５３では、呼処理タスク２１１のＣＰＵ使用率CPUUsgと閾値CPUUsgRestとを比較する。所定の条件（CPUUsg＞CPUUsgRest）を満たす場合にはステップ５５４に進み、条件を満たさない場合にはステップ５５５に進む。
【００７６】
ステップ５５４及び５５５では、それぞれ次の第６式及び第７式に基づいて受付可能呼数NL_CPUを算出する。
NL_CPU＝NA_CPU・(CPUUsgMax−CPUUsg0)／(CPUUsg−CPUUsg0) ・・・(6)
NL_CPU＝NA_CPU・(CPUUsgP−CPUUsg0)／(CPUUsg−CPUUsg0) ・・・(7)
また、受付可能呼数NL_CPUが急激に変化するのを防止するために、ステップ５５６，５５７，５５８，５５９で補正処理を実施する。
【００７７】
受付可能呼数NL_CPUが増大するときには、ステップ５５６の処理によって、処理周期の１サイクルの間の変化量がチェックされる。そして、所定の条件（NL_CPU＞(1+MA)・NA_CPU）を満たす場合には、ステップ５５７で受付可能呼数NL_CPUが補正される。
また、受付可能呼数NL_CPUが減少するときには、ステップ５５８の処理によって、処理周期の１サイクルの間の変化量がチェックされる。そして、所定の条件（NL_CPU＜(1-MB)・NA_CPU）を満たす場合には、ステップ５５９で受付可能呼数NL_CPUが補正される。
【００７８】
また、従属データのメモリ使用率CPUUsgが異常に大きくなった場合には、ステップ５６０，５６１で更に補正を実施する。ステップ５６０では、呼処理タスク２１１のＣＰＵ使用率CPUUsgを上限値である閾値CPUUsgMaxと比較する。所定の条件（CPUUsg＞CPUUsgMax）を満たす場合には、ステップ５６１で受付可能呼数NL_CPUを補正する。
【００７９】
ステップ５６２では、求めた受付可能呼数NL_CPUを前サイクルの受付可能呼数NA_CPUとして保存する。
上記各パラメータの値については、保守運用端末装置１５０の操作により、次に示す制約の範囲内で変更可能である。
50 ≦ CPUUsg0 ≦ CPUUsgRest ≦ CPUUsgMax ≦ 100 ・・・ (8)
規制値識別タスク２３１のステップ４３０で実行される処理の内容を図１１に示す。図１１に記号で示す各パラメータは、次のように定義される。
【００８０】
RV：最終的に決定された受付可能呼数
RV2：従属データ処理タスク２２１に関する受付可能呼数
NL_ABF(1)：優先度の高い従属データ（図５）に対するNL_ABF
NL_ABF(0)：優先度の低い従属データ（図６）に対するNL_ABF
RW，K2：重み係数
図１１を参照して説明する。この処理では、ステップ６０２，６０３，６０７において前記ＣＰＵ使用率CPUUsgと閾値ABFUsg0，CPUUsg0とを比較して、４種類の状態を識別する。
【００８１】
ＣＰＵ使用率CPUUsgが閾値ABFUsg0より大きく、且つ閾値CPUUsg0よりも大きい場合には、ステップ６０４，６０５を実行する。ステップ６０４では、次式により従属データ処理タスク２２１に関する受付可能呼数RV2を算出する。
RV2＝(NL_ABF(1)+NL_ABF(0)・RW)／2 ・・・ (9)
つまり、優先度の高い従属データに対する受付可能呼数NL_ABF(1)と、優先度の低い従属データに対する受付可能呼数NL_ABF(0)とを平均化した結果が、受付可能呼数RV2になる。また、受付可能呼数NL_ABF(1)，NL_ABF(0)は重み係数RWで重み付けされる。
【００８２】
ステップ６０５では、次式により受付可能呼数RVを算出する。
RV＝(NL_CPU＋RV2・K2)／2 ・・・ (10)
つまり、呼処理タスク２１１に関する受付可能呼数NL_CPUと、従属データ処理タスク２２１に関する受付可能呼数RV2とを平均化した結果が、最終的な受付可能呼数RVになる。また、呼処理タスク２１１に関する受付可能呼数と従属データ処理タスク２２１に関する受付可能呼数RV2とは、重み係数K2で重み付けされる。
【００８３】
ＣＰＵ使用率CPUUsgが閾値ABFUsg0より大きく、且つ閾値CPUUsg0以下の場合には、ステップ６０６を実行する。ステップ６０６では、次式により受付可能呼数RVを算出する。
RV＝K2・(NL_ABF(1)+NL_ABF(0)・RW)／2 ・・・ (11)
つまり、優先度の高い従属データに対する受付可能呼数NL_ABF(1)と、優先度の低い従属データに対する受付可能呼数NL_ABF(0)とを平均化した結果が、最終的な受付可能呼数RVになる。また、受付可能呼数NL_ABF(1)，NL_ABF(0)は重み係数RWで重み付けされる。従って、最終的な受付可能呼数RVは呼処理タスク２１１に関する受付可能呼数とは無関係に決定される。
【００８４】
ＣＰＵ使用率CPUUsgが閾値ABFUsg0以下で、且つ閾値CPUUsg0より大きい場合には、ステップ６０８を実行する。ステップ６０８では、呼処理タスク２１１に関する受付可能呼数NL_CPUが最終的な受付可能呼数RVとして決定される。従って、最終的な受付可能呼数RVは、従属データ処理タスク２２１に関する受付可能呼数NL_ABF(1)，NL_ABF(0)とは無関係に決定される。
【００８５】
図８のステップ４３１の規制レベル算出処理の内容を図１２に示す。図１２に記号で示す各パラメータは、次のように定義される。
CPUUsgP：１サイクル前の処理で検出されたCPUUsg
CPUUsg1：CPUUsgに関する閾値（輻輳緩和条件：初期値は５０）
CPUUsg2：CPUUsgに関する閾値（輻輳条件：初期値は７５）
LV_CPU：呼処理タスク２１１に対する規制のレベル(0,1,2：初期値は0)
図８に示す規制レベル算出処理においては、ステップ６１１，６１２，６１３，６１５，６１６，６１７によって、「規制強化」，「規制緩和」，「状態維持」の３種類の状態が識別される。
【００８６】
すなわち、ステップ６１１，６１２，６１３の全ての条件が成立する場合には、「規制強化」をするためにステップ６１４を実行する。ステップ６１４では、規制レベルLV_CPUを１レベル上げる。規制レベルLV_CPUの上限が２なので、ステップ６１３の条件が成立しないときには、ステップ６１４は実行しない。
また、ステップ６１５，６１６，６１７の全ての条件が成立する場合には、「規制緩和」をするためにステップ６１８を実行する。ステップ６１８では、規制レベルLV_CPUを１レベル下げる。規制レベルLV_CPUの下限が０なので、ステップ６１７の条件が成立しないときには、ステップ６１８は実行しない。
【００８７】
ステップ６１１，６１２，６１３，６１５，６１６，６１７の何れかの条件が成立しない場合には、「状態維持」をするために規制レベルLV_CPUの更新は実行しない。
つまり、呼処理タスク２１１のＣＰＵ使用率CPUUsgが閾値CPUUsg2より大きい状態が２サイクル連続すると、「規制強化」のために規制レベルLV_CPUを１レベル上げる。また、ＣＰＵ使用率CPUUsgが閾値CPUUsg1より小さい状態が２サイクル連続すると、「規制緩和」のために規制レベルLV_CPUを１レベル下げる。
【００８８】
図１３を参照して、規制レベルLV_CPUの状態遷移を説明する。ＣＰＵ使用率CPUUsgが閾値CPUUsg2より大きい状態が継続する場合には、条件Ａが成立するので、「状態１」→「状態２」→「状態３」→「状態４」→「状態５」と順次に変化する。「状態２」及び「状態４」では規制レベルLV_CPUは前の値から変化しない。
また、ＣＰＵ使用率CPUUsgが閾値CPUUsg1より小さい状態が継続する場合には、条件Ｂが成立するので、「状態５」→「状態４」→「状態３」→「状態２」→「状態１」と順次に変化する。「状態２」及び「状態４」では規制レベルLV_CPUは前の値から変化しない。
【００８９】
通常、規制を強化するとＣＰＵ使用率CPUUsgは下がる。従って、例えば「状態１」から「状態２」を介して「状態３」に移行し、規制レベルLV_CPUが「０」から「１」に上がると、ＣＰＵ使用率CPUUsgが下がるので、「状態３」から「状態２」を介して「状態１」に移行する場合もある。
上記閾値の値については、保守運用端末装置１５０の操作により、次に示す制約の範囲内で変更可能である。
【００９０】
CPUUsg0 ≦ CPUUsg1 ≦ CPUUsg2 ≦ CPUUsgMax ・・・ (12)
図８のステップ４３５で実行される呼処理タスク２１１の呼規制処理の内容を図１４に示す。この呼規制処理においては、呼処理規制タスク２３２から通知される受付可能呼数RV及び規制率Ｒに従って、「呼」に対する処理の実行を規制する。
【００９１】
規制を開始すると、受付可能呼数RV及び規制率Ｒは定期的に呼処理規制タスク２３２から呼処理タスク２１１に通知される。図１４の呼規制処理の内容について、以下に説明する。
呼処理タスク２１１は、受付可能呼数RV及び規制率Ｒとともに呼規制要求が通知されると、ステップ６５１から６５２に進む。ステップ６５２では、一定期間内（例えば１秒間）に検出された発呼，入呼の呼数を測定する。
【００９２】
ステップ６５３では、ステップ６５２で検出された呼数を受付可能呼数RVと比較する。検出された呼数が受付可能呼数RVを上回ると、次のステップ６５４に進む。
また、受付可能呼数RV及び規制率Ｒが呼処理規制タスク２３２から呼処理タスク２１１に通知されると、ステップ６５２の測定値はクリアされ、呼数の測定が再開される。
【００９３】
「呼」の要求が検出される度に、ステップ６５４からステップ６５６に進む。ステップ６５６では、予め用意された呼規制ビットマップの１つのビットを参照する。
呼規制ビットマップは、図１５に示すように、呼拒否を示す「１」と呼受付を示す「０」とが、規制率Ｒに従って周期的に並べられたテーブルである。この呼規制ビットマップは、前述の呼規制率テーブルの内容が決定された時、及びそれが更新された時に、呼規制率テーブル基づいて作成される。全ての規制率Ｒについて、呼規制ビットマップがそれぞれ作成される。
【００９４】
ステップ６５６では、呼処理規制タスク２３２から通知された規制率Ｒに対応する１つの呼規制ビットマップを選択し、それの１つのビットを参照する。ステップ６５６で参照したビットの状態（１／０）に応じて、ステップ６５８又は６５９が実行される。
【００９５】
ステップ６５８では、ステップ６５４で検出された呼を受付拒否する。また、ステップ６５９では、呼を受け付ける。
ステップ６６０では、ステップ６５６で参照される呼規制ビットマップ上の位置を示すポインタの値を更新する。ステップ６６０の処理によって、ステップ６５６で参照される呼規制ビットマップ上の位置は、参照の度に１ビットずつ移動する。前記ポインタにより定まる参照位置が呼規制ビットマップの最終位置に達すると、参照位置は呼規制ビットマップの先頭位置に移動する。
【００９６】
従って、呼の規制制御中は、呼の受付拒否と受付とが規制率Ｒに従って周期的に生じる。例えば、図１５に示す規制率が５０％の呼規制ビットマップを利用する場合には、２回に１回の割合で周期的に呼の受付が拒否される。
これによって呼処理の実行が間引かれるので、呼処理タスク２１１の負荷が低減される。そして、呼処理タスク２１１の実行に伴って生成される従属データの生成数も減るので、従属データ処理タスク２２１の負荷が低減される。従って、未処理の従属データの消失が回避される。
【００９７】
呼処理タスク２１１が呼処理規制タスク２３２から規制緩和の通知を受けると、図１４のステップ５５５を介してステップ６５１に戻るので、規制処理が解除される。規制処理を実行しないときには、ステップ６６１が実行される。ステップ６６１では、要求された全ての呼を受け付ける。
（第２の実施の形態）
この形態は、上記第１の実施の形態の変形例である。図１１の処理の内容が図１６の内容に変更された以外は、第１の実施の形態と同一である。この形態は、請求項６及び請求項７に対応する。
【００９８】
図１６を参照し、変更された部分を説明する。なお、図１６において図１１と同一の処理は同一のステップ番号で示されている。
図１１と同様に、この処理では、ステップ６０２，６０３，６０７においてＣＰＵ使用率CPUUsgと閾値ABFUsg0，CPUUsg0とを比較して、４種類の状態を識別する。
【００９９】
ＣＰＵ使用率CPUUsgが閾値ABFUsg0より大きく、且つ閾値CPUUsg0よりも大きい場合には、ステップ６０４で従属データ処理タスク２２１に関する受付可能呼数RV2を算出する。この後で、ステップ６１０を実行する。
ステップ６１０では、従属データ処理タスク２２１に関する受付可能呼数RV2に重み係数K2をかけた結果と呼処理タスク２１１に関する受付可能呼数NL_CPUとを比較する。
【０１００】
ステップ６１０の条件を満たす(NL_CPU＞RV2・K2)場合には、ステップ６１１に進み、呼処理タスク２１１に関する受付可能呼数NL_CPUを最終的な受付可能呼数RVに決定する。ステップ６１０の条件を満たさない場合には、ステップ６１２に進み、従属データ処理タスク２２１に関する受付可能呼数RV2に重み係数K2をかけた結果を最終的な受付可能呼数RVに決定する。
【０１０１】
上記第１の実施の形態及び第２の実施の形態においては、一例として、ディジタル交換機の制御装置に本発明を適用する場合について説明した。本発明は、同様に第１の処理の実行に伴って生成される従属データに対して第２の処理を実行するマルチタスクシステムであれば、ディジタル交換機だけでなく様々なシステムに適用しうる。
【０１０２】
また、上記第１の実施の形態及び第２の実施の形態においては、ソフトウェアの実行によって輻輳制御を実現しているが、同様の機能をハードウェアに置き換えることも可能である。
更に、上記第１の実施の形態及び第２の実施の形態で示した制御の詳細については、必要に応じて変更しても良い。
【０１０３】
【発明の効果】
請求項１のマルチタスクシステムの輻輳制御装置によれば、第２の処理１３の実行頻度が低下してその処理能力が減少すると、第２の処理１３によって処理すべき従属データ１２の発生が抑制されるので、未処理の従属データ１２の消失防止に役立つ。
【０１０４】
請求項２のマルチタスクシステムの輻輳制御装置によれば、従属負荷検出手段１５が第２の処理１３に関する負荷の大きさを優先度の区分に応じて複数検出するので、優先度に応じた輻輳制御が可能である。
請求項３のマルチタスクシステムの輻輳制御装置によれば、複数組のパラメータ１４が用意されているので、優先度が異なる複数の従属データ１２の負荷の大きさを、それぞれに適した条件で求めることができる。
【０１０５】
請求項４のマルチタスクシステムの輻輳制御装置によれば、従属データ１２に関するメモリ使用率を監視するので、第２の処理１３の実行の遅れ、すなわち第２の処理１３に関する負荷の大きさを検出することができる。
請求項５のマルチタスクシステムの輻輳制御装置によれば、第１の処理１１に関する負荷の大きさと、第２の処理１３に関する負荷の大きさとに基づいて前記第１の処理１１を規制するので、第１の処理１１の負荷が急激に増大する場合であっても、輻輳状態の検出の遅れが生じにくい。
【０１０６】
請求項６のマルチタスクシステムの輻輳制御装置によれば、第１の処理１１の負荷と第２の処理１３の負荷の何れかが増大すると、第１の処理１１が規制されるので輻輳制御の遅れが生じにくい。
請求項７のマルチタスクシステムの輻輳制御装置によれば、第１の処理１１及び第２の処理１３の特性や重要度などを考慮した上で両者を比較することができる。
【０１０７】
請求項８のマルチタスクシステムの輻輳制御装置によれば、第１の処理１１の負荷と第２の処理１３の負荷の少なくとも一方が増大すれば、第１の処理１１が規制されるので輻輳制御の遅れが生じにくい。
請求項９のマルチタスクシステムの輻輳制御装置によれば、第１の処理１１及び第２の処理１３の特性や重要度などを考慮した上で、第１の処理１１の規制を制御できる。
【０１０８】
請求項１０のマルチタスクシステムの輻輳制御装置によれば、優先度の比較的高い従属データ１２に対する第２の処理１３の負荷が増大した場合でも、優先度の比較的低い従属データ１２に対する第２の処理１３の負荷が増大した場合でも、第１の処理１１を規制することができる。
請求項１１のマルチタスクシステムの輻輳制御装置によれば、急激な負荷の変動に対する輻輳制御の応答性や、一時的な負荷の変動に対する応答性を調整できる。
【０１０９】
請求項１２のマルチタスクシステムの輻輳制御装置によれば、輻輳状態の検出によって第１の処理１１の規制が発動された後、第２の処理１３に関する負荷が減少すると、第１の処理１１の規制が自動的に解除もしくは緩和される。
【図面の簡単な説明】
【図１】本発明の請求項１〜請求項１２の構成に対応する機能ブロック図である。
【図２】マルチタょスクシステムの輻輳制御装置を備えるディジタル交換機のハードウェアの構成例を示すブロック図である。
【図３】図２のシステム制御部１００で実行されるソフトウェアの主要部の構成を示すブロック図である。
【図４】従属データ処理タスク２２１の課金データ生成シーケンスを示すフローチャートである。
【図５】従属データ処理タスク２２１が生成する優先度の大きい課金データの構成を示すマップである。
【図６】従属データ処理タスク２２１が生成する優先度の小さい課金データの構成を示すマップである。
【図７】図３の輻輳制御系２００により実現される輻輳制御の制御シーケンスの一部分を示すフローチャートである。
【図８】図３の輻輳制御系２００により実現される輻輳制御の制御シーケンスの一部分を示すフローチャートである。
【図９】図７のステップ４１１の処理の内容を示すフローチャートである。
【図１０】図８のステップ４２５の処理の内容を示すフローチャートである。
【図１１】第１の実施の形態における、図７のステップ４３０の処理の内容を示すフローチャートである。
【図１２】図７のステップ４３１の処理の内容を示すフローチャートである。
【図１３】図１２の処理によって実現する規制レベルの状態遷移を示すフローチャートである。
【図１４】図８のステップ４３５の処理の内容を示すフローチャートである。
【図１５】図８のステップ４３５の処理で参照される呼規制ビットマップの構成例を示すマップである。
【図１６】第２の実施の形態における受付可能呼数決定処理の内容を示すフローチャートである。
【符号の説明】
１００ システム制御部
１０１ プロセッサ
１０２ メインメモリ
１０３ システムバス制御部
１０４ ＳＣＳＩインタフェース
１０５ ＬＡＮインタフェース
１０６ プロセッサバス
１１０ 回線インタフェース部
１１１ データ通信回線
１２０ セルスイッチ部
１３０ シグナリング／クロック部
１４０ ハードディスク
１５０ 保守運用端末装置
１６０ システムバス
２００ 輻輳制御系
２０１ オペレーティングシステム
２０２ メモリ管理タスク
２０３ 従属データ
２１１ 呼処理タスク
２１２ 呼処理リソース監視タスク
２１３ 一次規制値算出タスク
２２１ 従属データ処理タスク
２２２ 従属データリソース監視タスク
２２３ 二次規制値算出タスク
２３１ 規制値識別タスク
２３２ 呼処理規制タスク
【発明の属する技術分野】
本発明は、実質的に独立した複数の処理を単一の処理ユニットで並列的に実行するマルチタスクシステムで利用される輻輳制御装置に関する。
特に本発明の輻輳制御装置は、特定の第１の処理の実行に伴って生成される従属データに対して第２の処理を実行するとともに、前記第１の処理と第２の処理とを互いに異なる実行レベルで並列的に実行するマルチタスクシステムで利用される。
例えば、ディジタル交換機を制御するマルチタスクシステムにおいては、メインのサービス（第１の処理）として呼処理を実行する。すなわち、発信側端末装置からの発呼に応答して発信側端末装置と受信側端末装置との回線の接続を確立し、発信側端末装置と受信側端末装置との間におけるデータ転送を処理する。
また、ディジタル交換機の制御においては、メインのサービスに付随して課金データが生成される。課金データに対する処理（第２の処理）は、メインのサービスに比べて優先順位の低い下位の実行レベルで処理される。
【０００２】
【従来の技術】
逐次入力されるデータを処理する様々な処理装置においては、入力データ量が過大になると、プロセッサの処理能力の不足、あるいは利用可能なメモリの不足によって新たな処理の実行ができなくなる。このような輻輳状態の発生を防止するために輻輳制御装置が用いられる。
【０００３】
この種の輻輳制御装置の従来技術としては、特開昭６２ー１１３５５号公報や特開平５ー３４４５５２号公報が知られている。
特開昭６２ー１１３５５号公報の技術では、主プロセッサと従プロセッサを備える交換機の処理装置において、輻輳発生時には、輻輳の発生条件に応じて従プロセッサのみ又は主プロセッサと従プロセッサの両方の負荷を規制する。
【０００４】
特開平５ー３４４５５２号公報の技術では、処理待ちタスク及び処理済みタスクを監視して輻輳の発生を検知する。また、輻輳が発生した場合には、負荷の大きい回線を優先的に規制する。
【０００５】
【発明が解決しようとする課題】
従来の輻輳制御装置においては、主要なサービスを提供するうえで必要な資源、すなわちプロセッサの使用率やメインメモリの使用率に基づいて、輻輳の有無を識別し規制の発動を制御している。
【０００６】
この種の輻輳制御では、主要なサービス（例えば呼処理）の実行に伴って生成される従属データ（例えば課金データ）の特性や条件とは無関係に規制が発動される。
ところで、複数の処理を並列的に処理するマルチタスクシステムにおいては、各々のタスクに優先順位あるいは実行レベルが割り当てられる。優先順位の高いタスクには、比較的高い比率で処理装置の資源（プロセッサの使用率やメモリの使用率）が割り当てられ、優先順位の低いタスクには少ない資源が割り当てられる。
【０００７】
一般に、輻輳の発生によって規制が発動された場合に、優先順位の高い処理が受ける影響は比較的小さい。しかし、優先順位の低い処理は大きな影響を受ける。つまり、優先順位の低い処理は、それを実行可能な機会（タイミング）が大幅に減る。
従って、主要なサービスを優先順位の高いタスクで実行し、主要なサービスによって生成される従属データを優先順位の低いタスクで処理する場合には、輻輳の規制が発動されると、従属データの発生頻度が高いにもかかわらず、優先順位の低いタスクの実行頻度が大幅に低下するので、従属データに対する処理が間に合わなくなる。
【０００８】
例えば、呼処理を優先順位の高いタスクで実行し、課金データの処理を優先順位の低いタスクで実行するディジタル交換機においては、輻輳が発生した場合に課金データ処理の実行頻度が著しく低下する。また、未処理の課金データを保持するためのメモリ容量は有限である。そのため、発生する重要な課金データが部分的に未処理のまま廃棄され、消失する可能性がある。
【０００９】
本発明は、マルチタスクシステムの輻輳制御装置において、輻輳が発生した場合に、第１の処理の実行に伴って発生する未処理の従属データの消失を防止することを主な目的とする。
【００１０】
【課題を解決するための手段】
図１に本発明の請求項１〜請求項１２の構成に対応する機能ブロック図を示す。図１を参照しながら本発明の構成を以下に説明する。
【００１１】
請求項１のマルチタスクシステムの輻輳制御装置は、互いに独立した複数の処理を並列的に実行するとともに、特定の第１の処理１１の実行に伴って生成される従属データ１２に対して、前記第１の処理１１より優先度が低い第２の処理１３をタスク管理に基づいて実行するマルチタスクシステムの輻輳制御装置において、処理の優先度の情報を有する前記従属データ１２の状態に基づいて、前記第２の処理１３に関する負荷の大きさを検出する従属負荷検出手段１５と、前記従属負荷検出手段１５が検出した第２の処理１３に関する負荷の大きさに基づいて、前記第１の処理１１を規制する従属負荷規制手段１６とを設けたことを特徴とする。
【００１２】
請求項１記載の発明においては、輻輳状態が発生して規制が発動されると、前記第２の処理１３の実行頻度が低下するため、未処理の従属データ１２が増大する。この場合、従属負荷検出手段１５が検出する第２の処理１３に関する負荷の大きさも増大する。
従って、従属負荷規制手段１６が第１の処理１１を規制する。第１の処理１１が規制されると、第１の処理１１の実行に伴って発生する従属データ１２の増大が抑制される。
【００１３】
つまり、第２の処理１３の実行頻度が低下してその処理能力が減少すると、第２の処理１３によって処理すべき従属データ１２の発生が抑制されるので、未処理の従属データ１２の消失防止に役立つ。
請求項２は、請求項１記載のマルチタスクシステムの輻輳制御装置において、前記従属データ１２として処理の優先度が互いに異なる複数種類のデータが存在する場合に、前記従属負荷検出手段１５が、第２の処理１３に関する負荷の大きさを、優先度の区分に応じて複数検出することを特徴とする。
【００１４】
例えばディジタル交換機において生成される課金データには、処理上の優先度が高いものと低いものとがある。すなわち、通話毎に料金の計算が必要な課金データについては、通話終了とほぼ同時に出力する必要があるので、処理の優先度が高い。また、定期的に行われる課金パルスの積算処理によって料金が計算される課金データについては、多少の処理の遅れは問題にならないので、処理の優先度が低い。
【００１５】
また、ディジタル交換機の場合には、従属データ１２として課金データの他にトラヒックデータなども生成される。課金データとトラヒックデータとは、処理の優先度や重要度が異なる。
請求項２の発明においては、従属負荷検出手段１５が第２の処理１３に関する負荷の大きさを優先度の区分に応じて複数検出するので、優先度に応じた輻輳制御が可能である。例えば、優先度の高い課金データの消失を防止することを最優先し、優先度の低い従属データの処理の遅れが輻輳制御に及ぼす影響を小さくするように輻輳制御することもできる。
【００１６】
請求項３は、請求項２記載のマルチタスクシステムの輻輳制御装置において、前記従属負荷検出手段１５が、処理対象の従属データ１２の優先度の区分に応じて、予め用意された複数組のパラメータ１４の中から１組のパラメータ１４を選択し、選択された前記パラメータ１４に基づいて第２の処理１３に関する負荷の大きさを識別することを特徴とする。
【００１７】
請求項３の発明においては、複数組のパラメータ１４が用意されているので、優先度が異なる複数の従属データ１２の負荷の大きさを、それぞれに適した条件で求めることができる。
請求項４は、請求項１記載のマルチタスクシステムの輻輳制御装置において、前記従属負荷検出手段１５が、前記従属データ１２の未処理の情報量と、前記従属データ１２に割り当てられた記憶領域の大きさとに基づいて第２の処理１３に関する負荷の大きさを検出することを特徴とする。
【００１８】
輻輳状態に陥り処理の規制が発動されると、第２の処理１３の実行頻度が低下する。一方、規制によって優先度の高い第１の処理１１が受ける影響は小さいので、新たな従属データ１２の発生頻度もあまり変化しない。その結果、第２の処理１３の実行の遅れが生じ、従属データ１２の未処理の情報量が増える。
通常、従属データ１２に割り当てられる記憶領域の大きさは一定なので、従属データ１２の未処理の情報量が増えると、割り当てられた記憶領域全体に占める未処理の従属データ１２の割合、すなわちメモリ使用率が増大する。
【００１９】
請求項４の発明においては、従属データ１２に関するメモリ使用率を監視するので、第２の処理１３の実行の遅れ、すなわち第２の処理１３に関する負荷の大きさを検出することができる。
【００２０】
請求項５は、請求項１記載のマルチタスクシステムの輻輳制御装置において、前記第１の処理１１の実行に伴って変化するシステム資源１７の利用状況に基づいて、第１の処理１１に関する負荷の大きさを検出する一次負荷検出手段１８を更に設け、前記従属負荷規制手段１６が、前記一次負荷検出手段１８の検出した第１の処理１１に関する負荷の大きさと、前記従属負荷検出手段１５の検出した第２の処理１３に関する負荷の大きさとに基づいて前記第１の処理１１を規制することを特徴とする。
【００２１】
第１の処理１１に関する負荷の大きさが増大すると、第２の処理１３に関する負荷の大きさも増大する。従って、第２の処理１３に関する負荷の大きさに基づいて前記第１の処理１１を規制すれば、輻輳状態の緩和に効果がある。
しかし、第１の処理１１の負荷の増大に比べて、第２の処理１３の負荷の増大は多少遅れる。従って、例えば急激にトラヒック量が増大した場合には、輻輳状態の検出及び処理の規制が遅れる可能性がある。
【００２２】
請求項５の発明においては、第１の処理１１に関する負荷の大きさと、第２の処理１３に関する負荷の大きさとに基づいて前記第１の処理１１を規制するので、第１の処理１１の負荷が急激に増大する場合であっても、輻輳状態の検出の遅れが生じにくい。
上記システム資源１７は、各タスクに割り当てられるプロセッサの処理やメモリ領域などを意味する。
【００２３】
請求項６は、請求項５記載のマルチタスクシステムの輻輳制御装置において、前記従属負荷規制手段１６が、前記第１の処理１１に関する負荷の大きさと、第２の処理１３に関する負荷の大きさとを比較して、何れか大きい方に基づいて前記第１の処理１１を規制することを特徴とする。
請求項６においては、第１の処理１１に関する負荷の大きさと、第２の処理１３に関する負荷の大きさとの何れか大きい方に基づいて第１の処理１１が規制される。従って、第１の処理１１の負荷と第２の処理１３の負荷の何れかが増大すれば、第１の処理１１が規制されるので輻輳制御の遅れが生じにくい。
【００２４】
請求項７は、請求項６記載のマルチタスクシステムの輻輳制御装置において、前記従属負荷規制手段１６が、前記第１の処理１１に関する負荷の大きさと、第２の処理１３に関する負荷の大きさとの少なくとも一方を重み付け補正し、重み付け補正後の第１の処理１１に関する負荷の大きさと、第２の処理１３に関する負荷の大きさとを比較して、何れか大きい方に基づいて前記第１の処理１１を規制することを特徴とする。
【００２５】
請求項７においては、第１の処理１１に関する負荷の大きさと、第２の処理１３に関する負荷の大きさの少なくとも一方が重み付け補正される。従って、第１の処理１１及び第２の処理１３の特性や重要度などを考慮した上で両者を比較することができる。
請求項８は、請求項５記載のマルチタスクシステムの輻輳制御装置において、前記従属負荷規制手段１６が、前記第１の処理１１に関する負荷の大きさと、第２の処理１３に関する負荷の大きさとを平均化した結果に基づいて前記第１の処理１１を規制することを特徴とする。
【００２６】
請求項８においては、第１の処理１１の負荷と第２の処理１３の負荷の少なくとも一方が増大すれば、第１の処理１１が規制されるので輻輳制御の遅れが生じにくい。
請求項９は、請求項８記載のマルチタスクシステムの輻輳制御装置において、前記従属負荷規制手段１６が、前記第１の処理１１に関する負荷の大きさと、第２の処理１３に関する負荷の大きさとの少なくとも一方を重み付け補正して、重み付け補正後の第１の処理１１に関する負荷の大きさと、第２の処理１３に関する負荷の大きさとを平均化した結果に基づいて前記第１の処理１１を規制することを特徴とする。
【００２７】
請求項９においては、第１の処理１１に関する負荷の大きさと、第２の処理１３に関する負荷の大きさの少なくとも一方が重み付け補正される。従って、第１の処理１１及び第２の処理１３の特性や重要度などを考慮した上で、第１の処理１１の規制を制御できる。
請求項１０は、請求項５記載のマルチタスクシステムの輻輳制御装置において、処理の優先度が互いに異なる複数種類の従属データ１２が存在する場合に、前記従属負荷規制手段１６が、第２の処理１３に関する複数区分の負荷の大きさを平均化して、平均化された第２の処理１３の負荷の大きさと、前記第１の処理１１に関する負荷の大きさとに基づいて前記第１の処理１１を規制することを特徴とする。
【００２８】
請求項１０においては、優先度の比較的高い従属データ１２に対する第２の処理１３の負荷が増大した場合でも、優先度の比較的低い従属データ１２に対する第２の処理１３の負荷が増大した場合でも、第１の処理１１を規制することができる。
請求項１１は、請求項１記載のマルチタスクシステムの輻輳制御装置において、前記従属負荷検出手段１５が、前記第２の処理１３に関する負荷の大きさを周期的に検出するとともに、検出された負荷の大きさの変化量と予め定めた閾値との比較結果に応じて、検出された第２の処理１３に関する負荷の大きさを補正することを特徴とする。
【００２９】
請求項１１においては、第１の処理１１の規制を制御する際に、第２の処理１３に関する負荷の大きさの変化量、すなわち微分値を考慮することができる。従って、急激な負荷の変動に対する輻輳制御の応答性や、一時的な負荷の変動に対する応答性を調整できる。
請求項１２は、請求項１記載のマルチタスクシステムの輻輳制御装置において、前記従属負荷規制手段１６が、前記従属負荷検出手段１５が検出した第２の処理１３に関する負荷の大きさが予め定めた下限閾値より小さい場合には、前記第１の処理１１の規制を解除もしくは緩和することを特徴とする。
【００３０】
請求項１２においては、輻輳状態の検出によって第１の処理１１の規制が発動された後、第２の処理１３に関する負荷が減少すると、第１の処理１１の規制が自動的に解除もしくは緩和される。
【００３１】
【発明の実施の形態】
（第１の実施の形態）
この形態のマルチタスクシステムの輻輳制御装置の構成と動作を図２〜図１５に示す。この形態は、請求項１〜請求項５並びに請求項８〜請求項１２に対応する。
【００３２】
図２は、マルチタスクシステムの輻輳制御装置を備えるディジタル交換機のハードウェアの構成例を示すブロック図である。図３は、図２のシステム制御部１００で実行されるソフトウェアの主要部の構成を示すブロック図である。
図４は、従属データ処理タスク２２１の課金データ生成シーケンスを示すフローチャートである。図５は、従属データ処理タスク２２１が生成する優先度の大きい課金データの構成を示すマップである。図６は、従属データ処理タスク２２１が生成する優先度の小さい課金データの構成を示すマップである。
【００３３】
図７は、図３の輻輳制御系２００により実現される輻輳制御の制御シーケンスの一部分を示すフローチャートである。図８は、図３の輻輳制御系２００により実現される輻輳制御の制御シーケンスの一部分を示すフローチャートである。図９は、図７のステップ４１１の処理の内容を示すフローチャートである。
図１０は、図８のステップ４２５の処理の内容を示すフローチャートである。図１１は、図７のステップ４３０の処理の内容を示すフローチャートである。図１２は、図７のステップ４３１の処理の内容を示すフローチャートである。
【００３４】
図１３は、図１２の処理によって実現する規制レベルの状態遷移を示すフローチャートである。図１４は、図８のステップ４３５の処理の内容を示すフローチャートである。図１５は、図８のステップ４３５の処理で参照される呼規制ビットマップの構成例を示すマップである。
この形態では、請求項１の第１の処理１１，従属データ１２，第２の処理１３，従属負荷検出手段１５及び従属負荷規制手段１６は、それぞれ呼処理タスク２１１，従属データ２０３，従属データ処理タスク２２１，二次規制値算出タスク２２３及び呼処理規制タスク２３２として具体化されている。
【００３５】
また、請求項５の一次負荷検出手段１８は、一次規制値算出タスク２１３として具体化されている。
図２を参照すると、このディジタル交換機はシステム制御部１００，回線インタフェース部１１０，セルスイッチ部１２０，シグナリング／クロック部１３０，ハードディスク１４０及び保守運用端末装置１５０で構成されている。
【００３６】
回線インタフェース部１１０に接続されるデータ通信回線１１１に含まれる各々の回線は、セルスイッチ部１２０を介して指定された別の回線と接続される。システム制御部１００は、回線インタフェース部１１０，セルスイッチ部１２０及びシグナリング／クロック部１３０を制御して、各回線間でのデータ転送を処理する。
【００３７】
システム制御部１００には、プロセッサバス１０６を介して互いに接続されたプロセッサ１０１，メインメモリ１０２，システムバス制御部１０３，ＳＣＳＩインタフェース１０４及びＬＡＮインタフェース１０５が備わっている。
なお、システムの信頼性を高めるために、図２のディジタル交換機の主要な構成要素は各々２組備わっている。また、２組のシステムは必要に応じて切り替え可能である。しかし、本発明とは直接関連がないので、図２においては１組の構成要素を省略して１組の構成だけを示してある。
【００３８】
図３に示すディジタル交換機の制御系は、図２に示すプロセッサ１０１のソフトウェアの実行によって実現する。ハードウェアと直接関連のある処理や基本的な処理は、オペレーティングシステム２０１によって実現する。
オペレーティングシステム２０１の動作の下で、様々なタスクを並列的に実行することができる。プロセッサ１０１の利用時間は小さいタイムスロット毎に予め区分され、各々のタイムスロットの利用権利が、各々のタスクに割り当てられる。従って、複数のタスクを時分割で実質的に同時に処理できる。
【００３９】
優先順位の高いタスクには、多くのタイムスロットが割り当てられるので、優先順位の高いタスクでは、短い時間で大量の処理を実行できる。優先順位の低いタスクには、僅かなタイムスロットが割り当てられるので、優先順位の低いタスクの処理能力は低い。
例えば、輻輳制御によってプロセッサ１０１の使用率（単位時間当たりのタスクの占有時間）が制限されると、優先順位の低いタスクが実行される頻度は大幅に低下する。
【００４０】
図３に示す制御系においては、オペレーティングシステム２０１上で実行されるタスクとして、メモリ管理タスク２０２，呼処理タスク２１１，呼処理リソース監視タスク２１２，一次規制値算出タスク２１３，従属データ処理タスク２２１，従属データリソース監視タスク２２２，二次規制値算出タスク２２３，規制値識別タスク２３１及び呼処理規制タスク２３２が含まれている。
【００４１】
メモリ管理タスク２０２は、これ以外のタスクに対してメインメモリ１０２上のメモリ領域を割り当てる。また、メモリ管理タスク２０２は他の各タスクに割り当てられたメモリの利用状況を管理する。
図３においては、各タスクとオペレーティングシステム２０１との通信、並びにメモリ管理タスク２０２とそれ以外のタスクとの通信の経路が実線で示してある。また、メモリ管理タスク２０２を除くタスク間通信の経路は点線で示してある。
【００４２】
以下、図３の輻輳制御系２００に含まれる各タスクについて説明する。呼処理タスク２１１では、発呼，入呼，切断など「呼」に関する電話網の接続サービスを実施する。呼処理タスク２１１はディジタル交換機における主要なサービスなので、呼処理タスク２１１の処理上の優先順位は比較的高い。
ところで、呼処理タスク２１１を実行すると、それに付随して課金データやトラヒックデータなどが従属データ２０３として生成される。呼処理タスク２１１に伴って生成された従属データ２０３に関しては、フォーマットの変換，データ蓄積などの二次的な処理を実行しなければならない。この二次的な処理は、呼処理タスク２１１とは別の従属データ処理タスク２２１によって実行される。
【００４３】
従属データ処理タスク２２１は、処理すべき単位時間当たりのデータ量が比較的少ないので、処理の優先順位が呼処理タスク２１１よりも低い。通常の状態では、従属データ処理タスク２２１は呼処理タスク２１１に伴って生成される課金データやトラヒックデータを処理するのに十分な能力を有している。
ところが、輻輳状態になって処理に規制が掛けられた場合、呼処理タスク２１１で生成される課金データやトラヒックデータの量があまり変化しないにもかかわらず、従属データ処理タスク２２１の処理能力は大幅に低下する。
【００４４】
従って、輻輳状態になると、従属データ処理タスク２２１の処理の遅れによって、未処理の課金データやトラヒックデータの量が増大する。各々のタスクに割り当てられるメモリ領域の大きさは有限なので、未処理のデータ量が増大すると、新しいデータを記憶するメモリ領域を確保するために古いデータは廃棄しなければならない。
【００４５】
このため、輻輳状態になると、重要な課金データが未処理のまま消失する可能性がある。このような不具合を無くすために、図３に示す輻輳制御系２００においては、特別な輻輳制御を実施する。
従属データ処理タスク２２１で処理される従属データ２０３には、図５及び図６に示すような２種類の課金データが含まれる。図５に示す課金データは、処理の優先度が高いデータである。図６に示す課金データは、処理の優先度が低いデータである。
【００４６】
課金データ生成シーケンスの内容を図４に示す。なお、図４に示す一時記憶バッファ１０２ａ及びタスク割り当てメモリ１０２ｂは、各々メインメモリ１０２上に割り当てられた特定のメモリ領域である。
図４において、呼処理タスク２１１のステップ３０１で通話完了が検出された後、呼処理タスク２１１は、ステップ３０２で未処理の課金データの内容を従属データ処理タスク２２１に通知する。
【００４７】
従属データ処理タスク２２１では、新しい課金データが通知されると、そのデータをステップ３０３で一時記憶バッファ１０２ａに一時的に蓄える。また、従属データ処理タスク２２１は、一定の周期（500ｍsec）でステップ３０４，３０５，３０６の処理を繰り返し実行する。
ステップ３０４では、一時記憶バッファ１０２ａに保持された未処理の課金データを読み出す。ステップ３０５では、ステップ３０４で読み出した未処理の課金データのデータ形式を予め定めたフォーマットに変換し、図５及び図６に示すような課金データを生成する。生成した課金データは、ステップ３０６でタスク割り当てメモリ１０２ｂに書き込まれる。
【００４８】
更に、従属データ処理タスク２２１では、一定の周期（５sec）でステップ３０７，３０８を繰り返し実行する。ステップ３０７では、タスク割り当てメモリ１０２ｂに保持された課金データを読み出す。この課金データは、次のステップ３０８でハードディスク１４０に書き込まれる。
図３に示す輻輳制御系２００の処理によって実現する輻輳制御の制御シーケンスについて、図７及び図８を参照して説明する。
【００４９】
規制値識別タスク２３１は、図７のステップ４０１で呼処理タスク２１１に対してＣＰＵアイドル時間の出力を要求する。この要求はタスク間通信である。この要求に応答して、呼処理タスク２１１は、ステップ４０２でその時のＣＰＵアイドル時間を検出し、検出したＣＰＵアイドル時間CPUIdleを規制値識別タスク２３１に出力する。
【００５０】
このＣＰＵアイドル時間CPUIdleは、呼処理タスク２１１が利用できるプロセッサ１０１の処理時間のうち、実際に利用されていない空き時間に比例する数値であり、この例では０〜１０００の範囲内の値になる。実際には、呼処理タスク２１１は、オペレーティングシステム２０１に対するシステムコールを利用して、ＣＰＵアイドル時間CPUIdleを得る。
【００５１】
規制値識別タスク２３１は、ＣＰＵアイドル時間CPUIdleを受け取った後、ステップ４０３でＣＰＵ使用率CPUUsgを算出する。ＣＰＵ使用率CPUUsgは次式により算出される。
CPUUsg ＝（1000−CPUIdle）／10 ・・・ (1)
次のステップ４０４では、規制値識別タスク２３１は輻輳に関する規制が必要か否かを識別する。具体的には、ステップ４０３で得たＣＰＵ使用率CPUUsgを、予め定めた閾値CPUUsg0及びABFUsg0と比較する。
【００５２】
ＣＰＵ使用率CPUUsgが閾値CPUUsg0よりも大きいか、又はＣＰＵ使用率CPUUsgが閾値ABFUsg0よりも大きい場合には、規制値識別タスク２３１は規制要とみなしてステップ４０５に進む。ＣＰＵ使用率CPUUsgが閾値CPUUsg0及びABFUsg0以下の場合には、規制不要とみなすので、ステップ４０５，４１３，４３０，４３１及び４３２は実行されない。
【００５３】
ステップ４０５では、規制値識別タスク２３１は二次規制値算出タスク２２３に対して二次規制値の出力を要求する。この要求を受けると、二次規制値算出タスク２２３は、ステップ４０６で従属データリソース監視タスク２２２に対して従属データのメモリ使用率の出力を要求する。
従属データリソース監視タスク２２２は、従属データのメモリ使用率の出力要求を受けると、ステップ４０７で従属データ処理タスク２２１に対して従属データに関する負荷情報の出力を要求する。
【００５４】
従属データ処理タスク２２１は、割り当てられたメモリ領域の大きさD1_ABF，単位データのサイズD2_ABF及び未処理データ数D3_ABFを、従属データの種類（優先度の大きい課金データ，優先度の小さい課金データ，トラヒック情報など）毎にそれぞれ取得して、それらのデータをステップ４０８で従属データリソース監視タスク２２２に通知する。
【００５５】
従属データリソース監視タスク２２２は、従属データ処理タスク２２１から通知されたデータに基づいて、ステップ４０９で従属データの種類毎に従属データのメモリ使用率ABFUsgを算出する。メモリ使用率ABFUsgは次式で算出される。
ABFUsg＝（D2_ABF・D3_ABF）／D1_ABF ・・・ （２）
従属データのメモリ使用率ABFUsgは、従属データ処理タスク２２１の負荷の大きさに応じて変化する。
【００５６】
図４に示す従属データ処理タスク２２１のステップ３０７，３０８の処理は優先順位が非常に低いので、プロセッサ１０１の負荷が過大になると、最初に従属データ処理タスク２２１のステップ３０７，３０８の処理能力が大幅に低下する。その結果、タスク割り当てメモリ１０２ｂからハードディスク１４０へのデータ転送が滞る。
【００５７】
そして、タスク割り当てメモリ１０２ｂから掃き出されるデータの量に比べてタスク割り当てメモリ１０２ｂに書き込まれるデータの量が大きくなる。つまり、輻輳状態になると、タスク割り当てメモリ１０２ｂ上の従属データの量が徐々に増大し、従属データのメモリ使用率ABFUsgが上昇する。
従属データリソース監視タスク２２２が算出した従属データのメモリ使用率ABFUsgは、ステップ４１０の処理で二次規制値算出タスク２２３に通知される。
【００５８】
二次規制値算出タスク２２３は、ステップ４０６における要求に対して従属データのメモリ使用率ABFUsgが通知されると、それに基づいて二次規制値NL_ABFを従属データの種類毎にステップ４１１の処理で算出する。
ステップ４１１の処理の内容については、後で詳細に説明する。ステップ４１１で算出された従属データの種類毎の二次規制値NL_ABFは、ステップ４１２で規制値識別タスク２３１に通知される。つまり、規制値識別タスク２３１のステップ４０５における要求に対して、二次規制値NL_ABFが通知される。
【００５９】
また、規制値識別タスク２３１は、図８に示すステップ４１３で、一次規制値算出タスク２１３に対して一次規制値の出力を要求する。一次規制値算出タスク２１３は、一次規制値の出力要求を受けると、ステップ４２０で呼処理リソース監視タスク２１２に対して呼処理タスク２１１に関するＣＰＵ使用率CPUUsgの出力を要求する。
【００６０】
呼処理リソース監視タスク２１２は、ステップ４２１で呼処理タスク２１１に対して、ＣＰＵアイドル時間の出力を要求する。この要求に応答して、呼処理タスク２１１は、ステップ４２２でその時のＣＰＵアイドル時間を検出し、検出したＣＰＵアイドル時間CPUIdleを呼処理リソース監視タスク２１２に通知する。
呼処理リソース監視タスク２１２は、ＣＰＵアイドル時間CPUIdleを受け取った後、ステップ４２３でＣＰＵ使用率CPUUsgを算出する。この処理の内容は、規制値識別タスク２３１のステップ４０３と同じである（第１式参照）。
【００６１】
呼処理リソース監視タスク２１２は、算出したＣＰＵ使用率CPUUsgをステップ４２４で一次規制値算出タスク２１３に通知する。一次規制値算出タスク２１３は、呼処理リソース監視タスク２１２から得たＣＰＵ使用率CPUUsgに基づいて、ステップ４２５で一次規制値NL_CPUを算出する。
ステップ４２５の処理の内容については、後で詳細に説明する。一次規制値算出タスク２１３は、ステップ４２５で算出された一次規制値NL_CPUをステップ４２６で規制値識別タスク２３１に通知する。
【００６２】
規制値識別タスク２３１は、二次規制値算出タスク２２３から受け取った二次規制値NL_ABFと、一次規制値算出タスク２１３から受け取った一次規制値NL_CPUとに基づいて、ステップ４３０で受付可能呼数ＲＶを決定する。また、次のステップ４３１では規制レベルLV_CPUを算出する。これらの処理については、後で詳細に説明する。
【００６３】
規制値識別タスク２３１は、ステップ４３０で決定した受付可能呼数ＲＶとステップ４３１で算出した規制レベルLV_CPUとを、ステップ４３２で呼処理規制タスク２３２に通知する。また、規制の条件を満たす状態から条件を満たさなくなった場合には、規制緩和の指示を呼処理規制タスク２３２に通知する。
呼処理規制タスク２３２は、規制値識別タスク２３１から通知された受付可能呼数ＲＶ及び規制レベルLV_CPUに基づいて、受付呼数に関する規制率Ｒをステップ４３３で決定する。
【００６４】
実際には、規制レベルLV_CPUと規制率Ｒとを対応付ける呼規制率テーブルが予め用意されている。この例では、規制レベルLV_CPUには０，１，２の３レベルがある。呼規制率テーブルにおいては、規制レベルLV_CPUの「０」，「１」，「２」のそれぞれに対して、「０％」，「５０％」，「１００％」の規制率Ｒが割り当ててある。
【００６５】
呼処理規制タスク２３２は、上記呼規制率テーブルを参照して、規制レベルLV_CPUから規制率Ｒを求める。例えば、規制レベルLV_CPUが「１」の場合には規制率Ｒは５０％になる。なお、呼規制率テーブルの内容の変更は可能である。
また、呼処理規制タスク２３２は、ステップ４３４で受付可能呼数ＲＶ及び規制率Ｒを呼処理タスク２１１に通知する。更に、規制緩和の指示を受けた場合には、それを呼処理タスク２１１に通知する。
【００６６】
呼処理タスク２１１では、呼処理規制タスク２３２から呼の規制を指示する受付可能呼数ＲＶ及び規制率Ｒを通知された場合には、ステップ４３５で呼規制処理を実行する。この呼規制処理によって、呼処理タスク２１１の「呼」に対する処理が規制される。この処理については、後で詳細に説明する。
図７のステップ４１１で実行されるNL_ABF算出処理の内容を図９に示す。図９に記号で示される各パラメータは、次のように定義される。なお、これらのパラメータは従属データの種別に対応付けて複数組設けられている。処理対象の従属データの種別に応じて、１組のパラメータが選択的に使用される。
【００６７】
NL_ABF：従属データ処理タスク２２１の受付可能呼数
NA_ABF：前の処理サイクルにおけるNL_ABF（初期値：０）
ABFUsg：従属データのメモリ使用率
ABFUsgP：前の処理サイクルにおけるABFUsg
ABFUsgMax：ABFUsgの閾値（上限値：初期値は９０）
ABFUsg0：ABFUsgの閾値（NL_ABF算出を実行する下限値：初期値は５０）
ABFUsgRest：ABFUsgの閾値（輻輳検出レベル：初期値は７５）
MI：増加時のNL_ABF補正係数（０〜１の範囲内の値：初期値は０．５）
MD：減少時のNL_ABF補正係数（０〜１の範囲内の値：初期値は０．５）
AD：NL_ABF補正係数（０〜１の範囲内の値：初期値は０．５）
以下、図９を参照してNL_ABF算出処理の各ステップについて説明する。なお図９に示す処理は、例えば１秒周期で繰り返し実行される。
【００６８】
ステップ５０１では、従属データのメモリ使用率ABFUsgと閾値ABFUsg0とを比較する。所定の条件（ABFUsg＞ABFUsg0）を満たす場合にはステップ５０３に進む。この条件を満たさないときに、他のタスクから二次規制値の出力を要求された場合には、ステップ５０２で条件不一致のエラーを通知する。
ステップ５０３では、従属データのメモリ使用率ABFUsgと閾値ABFUsgRestとを比較する。所定の条件（ABFUsg＞ABFUsgRest）を満たす場合にはステップ５０４に進み、条件を満たさない場合にはステップ５０５に進む。
【００６９】
ステップ５０４及び５０５では、それぞれ次の第３式及び第４式に基づいて受付可能呼数NL_ABFを算出する。
NL_ABF＝NA_ABF・(ABFUsgMax−ABFUsg0)／(ABFUsg−ABFUsg0) ・・・(3)
NL_ABF＝NA_ABF・(ABFUsgP−ABFUsg0)／(ABFUsg−ABFUsg0) ・・・(4)
また、受付可能呼数NL_ABFが急激に変化するのを防止するために、ステップ５０６，５０７，５０８，５０９で補正処理を実施する。
【００７０】
受付可能呼数NL_ABFが増大するときには、ステップ５０６の処理によって、処理周期の１サイクルの間の変化量がチェックされる。そして、所定の条件（NL_ABF＞(1+MI)・NA_ABF）を満たす場合には、ステップ５０７で受付可能呼数NL_ABFが補正される。
また、受付可能呼数NL_ABFが減少するときには、ステップ５０８の処理によって、処理周期の１サイクルの間の変化量がチェックされる。そして、所定の条件（NL_ABF＜(1-MD)・NA_ABF）を満たす場合には、ステップ５０９で受付可能呼数NL_ABFが補正される。
【００７１】
また、従属データのメモリ使用率ABFUsgが異常に大きくなった場合には、ステップ５１０，５１１で更に補正を実施する。ステップ５１０では、メモリ使用率ABFUsgを上限値である閾値ABFUsgMaxと比較する。所定の条件（ABFUsg＞ABFUsgMax）を満たす場合には、ステップ５１１で受付可能呼数NL_ABFを補正する。
ステップ５１２では、求めた受付可能呼数NL_ABFを前サイクルの受付可能呼数NA_ABFとして保存する。
【００７２】
なお、図９には示されていないが、従属データは、優先度の高い課金データ，優先度の低い課金データ，トラヒックデータなどの種類毎にそれぞれ算出される。種類の異なる従属データを処理する場合には、それぞれ独立したパラメータが用いられる。
各パラメータの値については、保守運用端末装置１５０の操作により、次に示す制約の範囲内で変更可能である。
【００７３】
50 ≦ ABFUsg0 ≦ ABFUsgRest ≦ ABFUsgMax ≦ 100 ・・・ (5)
図８のステップ４２５で実行されるNL_CPU算出処理の内容を図１０に示す。図１０に記号で示される各パラメータは、次のように定義される。なお、これらのパラメータは従属データの種別に対応付けて複数組設けられている。処理対象の従属データの種別に応じて、１組のパラメータが選択的に使用される。
【００７４】
NL_CPU：呼処理タスク２１１の受付可能呼数
NA_CPU：前の処理サイクルにおけるNL_CPU（初期値：０）
CPUUsg：呼処理タスク２１１のＣＰＵ使用率
CPUUsgP：前の処理サイクルにおけるCPUUsg
CPUUsgMax：CPUUsgの閾値（上限値：初期値は９０）
CPUUsg0：CPUUsgの閾値（NL_CPU算出を実行する下限値：初期値は５０）
CPUUsgRest：CPUUsgの閾値（輻輳検出レベル：初期値は７５）
MA：増加時のNL_CPU補正係数（０〜１の範囲内の値：初期値は０．５）
MB：減少時のNL_CPU補正係数（０〜１の範囲内の値：初期値は０．５）
AD2：NL_CPU補正係数（０〜１の範囲内の値：初期値は０．５）
以下、図１０を参照してNL_CPU算出処理の各ステップについて説明する。なお図１０に示す処理は、例えば１秒周期で繰り返し実行される。
【００７５】
ステップ５５１では、呼処理タスク２１１のＣＰＵ使用率CPUUsgと閾値CPUUsg0とを比較する。所定の条件（CPUUsg＞CPUUsg0）を満たす場合にはステップ５５３に進む。この条件を満たさないときに、他のタスクから一次規制値の出力を要求された場合には、ステップ５５２で条件不一致のエラーを通知する。
ステップ５５３では、呼処理タスク２１１のＣＰＵ使用率CPUUsgと閾値CPUUsgRestとを比較する。所定の条件（CPUUsg＞CPUUsgRest）を満たす場合にはステップ５５４に進み、条件を満たさない場合にはステップ５５５に進む。
【００７６】
ステップ５５４及び５５５では、それぞれ次の第６式及び第７式に基づいて受付可能呼数NL_CPUを算出する。
NL_CPU＝NA_CPU・(CPUUsgMax−CPUUsg0)／(CPUUsg−CPUUsg0) ・・・(6)
NL_CPU＝NA_CPU・(CPUUsgP−CPUUsg0)／(CPUUsg−CPUUsg0) ・・・(7)
また、受付可能呼数NL_CPUが急激に変化するのを防止するために、ステップ５５６，５５７，５５８，５５９で補正処理を実施する。
【００７７】
受付可能呼数NL_CPUが増大するときには、ステップ５５６の処理によって、処理周期の１サイクルの間の変化量がチェックされる。そして、所定の条件（NL_CPU＞(1+MA)・NA_CPU）を満たす場合には、ステップ５５７で受付可能呼数NL_CPUが補正される。
また、受付可能呼数NL_CPUが減少するときには、ステップ５５８の処理によって、処理周期の１サイクルの間の変化量がチェックされる。そして、所定の条件（NL_CPU＜(1-MB)・NA_CPU）を満たす場合には、ステップ５５９で受付可能呼数NL_CPUが補正される。
【００７８】
また、従属データのメモリ使用率CPUUsgが異常に大きくなった場合には、ステップ５６０，５６１で更に補正を実施する。ステップ５６０では、呼処理タスク２１１のＣＰＵ使用率CPUUsgを上限値である閾値CPUUsgMaxと比較する。所定の条件（CPUUsg＞CPUUsgMax）を満たす場合には、ステップ５６１で受付可能呼数NL_CPUを補正する。
【００７９】
ステップ５６２では、求めた受付可能呼数NL_CPUを前サイクルの受付可能呼数NA_CPUとして保存する。
上記各パラメータの値については、保守運用端末装置１５０の操作により、次に示す制約の範囲内で変更可能である。
50 ≦ CPUUsg0 ≦ CPUUsgRest ≦ CPUUsgMax ≦ 100 ・・・ (8)
規制値識別タスク２３１のステップ４３０で実行される処理の内容を図１１に示す。図１１に記号で示す各パラメータは、次のように定義される。
【００８０】
RV：最終的に決定された受付可能呼数
RV2：従属データ処理タスク２２１に関する受付可能呼数
NL_ABF(1)：優先度の高い従属データ（図５）に対するNL_ABF
NL_ABF(0)：優先度の低い従属データ（図６）に対するNL_ABF
RW，K2：重み係数
図１１を参照して説明する。この処理では、ステップ６０２，６０３，６０７において前記ＣＰＵ使用率CPUUsgと閾値ABFUsg0，CPUUsg0とを比較して、４種類の状態を識別する。
【００８１】
ＣＰＵ使用率CPUUsgが閾値ABFUsg0より大きく、且つ閾値CPUUsg0よりも大きい場合には、ステップ６０４，６０５を実行する。ステップ６０４では、次式により従属データ処理タスク２２１に関する受付可能呼数RV2を算出する。
RV2＝(NL_ABF(1)+NL_ABF(0)・RW)／2 ・・・ (9)
つまり、優先度の高い従属データに対する受付可能呼数NL_ABF(1)と、優先度の低い従属データに対する受付可能呼数NL_ABF(0)とを平均化した結果が、受付可能呼数RV2になる。また、受付可能呼数NL_ABF(1)，NL_ABF(0)は重み係数RWで重み付けされる。
【００８２】
ステップ６０５では、次式により受付可能呼数RVを算出する。
RV＝(NL_CPU＋RV2・K2)／2 ・・・ (10)
つまり、呼処理タスク２１１に関する受付可能呼数NL_CPUと、従属データ処理タスク２２１に関する受付可能呼数RV2とを平均化した結果が、最終的な受付可能呼数RVになる。また、呼処理タスク２１１に関する受付可能呼数と従属データ処理タスク２２１に関する受付可能呼数RV2とは、重み係数K2で重み付けされる。
【００８３】
ＣＰＵ使用率CPUUsgが閾値ABFUsg0より大きく、且つ閾値CPUUsg0以下の場合には、ステップ６０６を実行する。ステップ６０６では、次式により受付可能呼数RVを算出する。
RV＝K2・(NL_ABF(1)+NL_ABF(0)・RW)／2 ・・・ (11)
つまり、優先度の高い従属データに対する受付可能呼数NL_ABF(1)と、優先度の低い従属データに対する受付可能呼数NL_ABF(0)とを平均化した結果が、最終的な受付可能呼数RVになる。また、受付可能呼数NL_ABF(1)，NL_ABF(0)は重み係数RWで重み付けされる。従って、最終的な受付可能呼数RVは呼処理タスク２１１に関する受付可能呼数とは無関係に決定される。
【００８４】
ＣＰＵ使用率CPUUsgが閾値ABFUsg0以下で、且つ閾値CPUUsg0より大きい場合には、ステップ６０８を実行する。ステップ６０８では、呼処理タスク２１１に関する受付可能呼数NL_CPUが最終的な受付可能呼数RVとして決定される。従って、最終的な受付可能呼数RVは、従属データ処理タスク２２１に関する受付可能呼数NL_ABF(1)，NL_ABF(0)とは無関係に決定される。
【００８５】
図８のステップ４３１の規制レベル算出処理の内容を図１２に示す。図１２に記号で示す各パラメータは、次のように定義される。
CPUUsgP：１サイクル前の処理で検出されたCPUUsg
CPUUsg1：CPUUsgに関する閾値（輻輳緩和条件：初期値は５０）
CPUUsg2：CPUUsgに関する閾値（輻輳条件：初期値は７５）
LV_CPU：呼処理タスク２１１に対する規制のレベル(0,1,2：初期値は0)
図８に示す規制レベル算出処理においては、ステップ６１１，６１２，６１３，６１５，６１６，６１７によって、「規制強化」，「規制緩和」，「状態維持」の３種類の状態が識別される。
【００８６】
すなわち、ステップ６１１，６１２，６１３の全ての条件が成立する場合には、「規制強化」をするためにステップ６１４を実行する。ステップ６１４では、規制レベルLV_CPUを１レベル上げる。規制レベルLV_CPUの上限が２なので、ステップ６１３の条件が成立しないときには、ステップ６１４は実行しない。
また、ステップ６１５，６１６，６１７の全ての条件が成立する場合には、「規制緩和」をするためにステップ６１８を実行する。ステップ６１８では、規制レベルLV_CPUを１レベル下げる。規制レベルLV_CPUの下限が０なので、ステップ６１７の条件が成立しないときには、ステップ６１８は実行しない。
【００８７】
ステップ６１１，６１２，６１３，６１５，６１６，６１７の何れかの条件が成立しない場合には、「状態維持」をするために規制レベルLV_CPUの更新は実行しない。
つまり、呼処理タスク２１１のＣＰＵ使用率CPUUsgが閾値CPUUsg2より大きい状態が２サイクル連続すると、「規制強化」のために規制レベルLV_CPUを１レベル上げる。また、ＣＰＵ使用率CPUUsgが閾値CPUUsg1より小さい状態が２サイクル連続すると、「規制緩和」のために規制レベルLV_CPUを１レベル下げる。
【００８８】
図１３を参照して、規制レベルLV_CPUの状態遷移を説明する。ＣＰＵ使用率CPUUsgが閾値CPUUsg2より大きい状態が継続する場合には、条件Ａが成立するので、「状態１」→「状態２」→「状態３」→「状態４」→「状態５」と順次に変化する。「状態２」及び「状態４」では規制レベルLV_CPUは前の値から変化しない。
また、ＣＰＵ使用率CPUUsgが閾値CPUUsg1より小さい状態が継続する場合には、条件Ｂが成立するので、「状態５」→「状態４」→「状態３」→「状態２」→「状態１」と順次に変化する。「状態２」及び「状態４」では規制レベルLV_CPUは前の値から変化しない。
【００８９】
通常、規制を強化するとＣＰＵ使用率CPUUsgは下がる。従って、例えば「状態１」から「状態２」を介して「状態３」に移行し、規制レベルLV_CPUが「０」から「１」に上がると、ＣＰＵ使用率CPUUsgが下がるので、「状態３」から「状態２」を介して「状態１」に移行する場合もある。
上記閾値の値については、保守運用端末装置１５０の操作により、次に示す制約の範囲内で変更可能である。
【００９０】
CPUUsg0 ≦ CPUUsg1 ≦ CPUUsg2 ≦ CPUUsgMax ・・・ (12)
図８のステップ４３５で実行される呼処理タスク２１１の呼規制処理の内容を図１４に示す。この呼規制処理においては、呼処理規制タスク２３２から通知される受付可能呼数RV及び規制率Ｒに従って、「呼」に対する処理の実行を規制する。
【００９１】
規制を開始すると、受付可能呼数RV及び規制率Ｒは定期的に呼処理規制タスク２３２から呼処理タスク２１１に通知される。図１４の呼規制処理の内容について、以下に説明する。
呼処理タスク２１１は、受付可能呼数RV及び規制率Ｒとともに呼規制要求が通知されると、ステップ６５１から６５２に進む。ステップ６５２では、一定期間内（例えば１秒間）に検出された発呼，入呼の呼数を測定する。
【００９２】
ステップ６５３では、ステップ６５２で検出された呼数を受付可能呼数RVと比較する。検出された呼数が受付可能呼数RVを上回ると、次のステップ６５４に進む。
また、受付可能呼数RV及び規制率Ｒが呼処理規制タスク２３２から呼処理タスク２１１に通知されると、ステップ６５２の測定値はクリアされ、呼数の測定が再開される。
【００９３】
「呼」の要求が検出される度に、ステップ６５４からステップ６５６に進む。ステップ６５６では、予め用意された呼規制ビットマップの１つのビットを参照する。
呼規制ビットマップは、図１５に示すように、呼拒否を示す「１」と呼受付を示す「０」とが、規制率Ｒに従って周期的に並べられたテーブルである。この呼規制ビットマップは、前述の呼規制率テーブルの内容が決定された時、及びそれが更新された時に、呼規制率テーブル基づいて作成される。全ての規制率Ｒについて、呼規制ビットマップがそれぞれ作成される。
【００９４】
ステップ６５６では、呼処理規制タスク２３２から通知された規制率Ｒに対応する１つの呼規制ビットマップを選択し、それの１つのビットを参照する。ステップ６５６で参照したビットの状態（１／０）に応じて、ステップ６５８又は６５９が実行される。
【００９５】
ステップ６５８では、ステップ６５４で検出された呼を受付拒否する。また、ステップ６５９では、呼を受け付ける。
ステップ６６０では、ステップ６５６で参照される呼規制ビットマップ上の位置を示すポインタの値を更新する。ステップ６６０の処理によって、ステップ６５６で参照される呼規制ビットマップ上の位置は、参照の度に１ビットずつ移動する。前記ポインタにより定まる参照位置が呼規制ビットマップの最終位置に達すると、参照位置は呼規制ビットマップの先頭位置に移動する。
【００９６】
従って、呼の規制制御中は、呼の受付拒否と受付とが規制率Ｒに従って周期的に生じる。例えば、図１５に示す規制率が５０％の呼規制ビットマップを利用する場合には、２回に１回の割合で周期的に呼の受付が拒否される。
これによって呼処理の実行が間引かれるので、呼処理タスク２１１の負荷が低減される。そして、呼処理タスク２１１の実行に伴って生成される従属データの生成数も減るので、従属データ処理タスク２２１の負荷が低減される。従って、未処理の従属データの消失が回避される。
【００９７】
呼処理タスク２１１が呼処理規制タスク２３２から規制緩和の通知を受けると、図１４のステップ５５５を介してステップ６５１に戻るので、規制処理が解除される。規制処理を実行しないときには、ステップ６６１が実行される。ステップ６６１では、要求された全ての呼を受け付ける。
（第２の実施の形態）
この形態は、上記第１の実施の形態の変形例である。図１１の処理の内容が図１６の内容に変更された以外は、第１の実施の形態と同一である。この形態は、請求項６及び請求項７に対応する。
【００９８】
図１６を参照し、変更された部分を説明する。なお、図１６において図１１と同一の処理は同一のステップ番号で示されている。
図１１と同様に、この処理では、ステップ６０２，６０３，６０７においてＣＰＵ使用率CPUUsgと閾値ABFUsg0，CPUUsg0とを比較して、４種類の状態を識別する。
【００９９】
ＣＰＵ使用率CPUUsgが閾値ABFUsg0より大きく、且つ閾値CPUUsg0よりも大きい場合には、ステップ６０４で従属データ処理タスク２２１に関する受付可能呼数RV2を算出する。この後で、ステップ６１０を実行する。
ステップ６１０では、従属データ処理タスク２２１に関する受付可能呼数RV2に重み係数K2をかけた結果と呼処理タスク２１１に関する受付可能呼数NL_CPUとを比較する。
【０１００】
ステップ６１０の条件を満たす(NL_CPU＞RV2・K2)場合には、ステップ６１１に進み、呼処理タスク２１１に関する受付可能呼数NL_CPUを最終的な受付可能呼数RVに決定する。ステップ６１０の条件を満たさない場合には、ステップ６１２に進み、従属データ処理タスク２２１に関する受付可能呼数RV2に重み係数K2をかけた結果を最終的な受付可能呼数RVに決定する。
【０１０１】
上記第１の実施の形態及び第２の実施の形態においては、一例として、ディジタル交換機の制御装置に本発明を適用する場合について説明した。本発明は、同様に第１の処理の実行に伴って生成される従属データに対して第２の処理を実行するマルチタスクシステムであれば、ディジタル交換機だけでなく様々なシステムに適用しうる。
【０１０２】
また、上記第１の実施の形態及び第２の実施の形態においては、ソフトウェアの実行によって輻輳制御を実現しているが、同様の機能をハードウェアに置き換えることも可能である。
更に、上記第１の実施の形態及び第２の実施の形態で示した制御の詳細については、必要に応じて変更しても良い。
【０１０３】
【発明の効果】
請求項１のマルチタスクシステムの輻輳制御装置によれば、第２の処理１３の実行頻度が低下してその処理能力が減少すると、第２の処理１３によって処理すべき従属データ１２の発生が抑制されるので、未処理の従属データ１２の消失防止に役立つ。
【０１０４】
請求項２のマルチタスクシステムの輻輳制御装置によれば、従属負荷検出手段１５が第２の処理１３に関する負荷の大きさを優先度の区分に応じて複数検出するので、優先度に応じた輻輳制御が可能である。
請求項３のマルチタスクシステムの輻輳制御装置によれば、複数組のパラメータ１４が用意されているので、優先度が異なる複数の従属データ１２の負荷の大きさを、それぞれに適した条件で求めることができる。
【０１０５】
請求項４のマルチタスクシステムの輻輳制御装置によれば、従属データ１２に関するメモリ使用率を監視するので、第２の処理１３の実行の遅れ、すなわち第２の処理１３に関する負荷の大きさを検出することができる。
請求項５のマルチタスクシステムの輻輳制御装置によれば、第１の処理１１に関する負荷の大きさと、第２の処理１３に関する負荷の大きさとに基づいて前記第１の処理１１を規制するので、第１の処理１１の負荷が急激に増大する場合であっても、輻輳状態の検出の遅れが生じにくい。
【０１０６】
請求項６のマルチタスクシステムの輻輳制御装置によれば、第１の処理１１の負荷と第２の処理１３の負荷の何れかが増大すると、第１の処理１１が規制されるので輻輳制御の遅れが生じにくい。
請求項７のマルチタスクシステムの輻輳制御装置によれば、第１の処理１１及び第２の処理１３の特性や重要度などを考慮した上で両者を比較することができる。
【０１０７】
請求項８のマルチタスクシステムの輻輳制御装置によれば、第１の処理１１の負荷と第２の処理１３の負荷の少なくとも一方が増大すれば、第１の処理１１が規制されるので輻輳制御の遅れが生じにくい。
請求項９のマルチタスクシステムの輻輳制御装置によれば、第１の処理１１及び第２の処理１３の特性や重要度などを考慮した上で、第１の処理１１の規制を制御できる。
【０１０８】
請求項１０のマルチタスクシステムの輻輳制御装置によれば、優先度の比較的高い従属データ１２に対する第２の処理１３の負荷が増大した場合でも、優先度の比較的低い従属データ１２に対する第２の処理１３の負荷が増大した場合でも、第１の処理１１を規制することができる。
請求項１１のマルチタスクシステムの輻輳制御装置によれば、急激な負荷の変動に対する輻輳制御の応答性や、一時的な負荷の変動に対する応答性を調整できる。
【０１０９】
請求項１２のマルチタスクシステムの輻輳制御装置によれば、輻輳状態の検出によって第１の処理１１の規制が発動された後、第２の処理１３に関する負荷が減少すると、第１の処理１１の規制が自動的に解除もしくは緩和される。
【図面の簡単な説明】
【図１】本発明の請求項１〜請求項１２の構成に対応する機能ブロック図である。
【図２】マルチタょスクシステムの輻輳制御装置を備えるディジタル交換機のハードウェアの構成例を示すブロック図である。
【図３】図２のシステム制御部１００で実行されるソフトウェアの主要部の構成を示すブロック図である。
【図４】従属データ処理タスク２２１の課金データ生成シーケンスを示すフローチャートである。
【図５】従属データ処理タスク２２１が生成する優先度の大きい課金データの構成を示すマップである。
【図６】従属データ処理タスク２２１が生成する優先度の小さい課金データの構成を示すマップである。
【図７】図３の輻輳制御系２００により実現される輻輳制御の制御シーケンスの一部分を示すフローチャートである。
【図８】図３の輻輳制御系２００により実現される輻輳制御の制御シーケンスの一部分を示すフローチャートである。
【図９】図７のステップ４１１の処理の内容を示すフローチャートである。
【図１０】図８のステップ４２５の処理の内容を示すフローチャートである。
【図１１】第１の実施の形態における、図７のステップ４３０の処理の内容を示すフローチャートである。
【図１２】図７のステップ４３１の処理の内容を示すフローチャートである。
【図１３】図１２の処理によって実現する規制レベルの状態遷移を示すフローチャートである。
【図１４】図８のステップ４３５の処理の内容を示すフローチャートである。
【図１５】図８のステップ４３５の処理で参照される呼規制ビットマップの構成例を示すマップである。
【図１６】第２の実施の形態における受付可能呼数決定処理の内容を示すフローチャートである。
【符号の説明】
１００ システム制御部
１０１ プロセッサ
１０２ メインメモリ
１０３ システムバス制御部
１０４ ＳＣＳＩインタフェース
１０５ ＬＡＮインタフェース
１０６ プロセッサバス
１１０ 回線インタフェース部
１１１ データ通信回線
１２０ セルスイッチ部
１３０ シグナリング／クロック部
１４０ ハードディスク
１５０ 保守運用端末装置
１６０ システムバス
２００ 輻輳制御系
２０１ オペレーティングシステム
２０２ メモリ管理タスク
２０３ 従属データ
２１１ 呼処理タスク
２１２ 呼処理リソース監視タスク
２１３ 一次規制値算出タスク
２２１ 従属データ処理タスク
２２２ 従属データリソース監視タスク
２２３ 二次規制値算出タスク
２３１ 規制値識別タスク
２３２ 呼処理規制タスク
Claims (12)
- 互いに独立した複数の処理を並列的に実行するとともに、特定の第１の処理の実行に伴って生成される従属データに対して、前記第１の処理より優先度が低い第２の処理をタスク管理に基づいて実行するマルチタスクシステムの輻輳制御装置において、
処理の優先度の情報を有する前記従属データの状態に基づいて、前記第２の処理に関する負荷の大きさを検出する従属負荷検出手段と、
前記従属負荷検出手段が検出した第２の処理に関する負荷の大きさに基づいて、前記第１の処理を規制する従属負荷規制手段と
を設けたことを特徴とするマルチタスクシステムの輻輳制御装置。 - 請求項１記載のマルチタスクシステムの輻輳制御装置において、前記従属データとして処理の優先度が互いに異なる複数種類のデータが存在する場合に、前記従属負荷検出手段が、第２の処理に関する負荷の大きさを、優先度の区分に応じて複数検出することを特徴とするマルチタスクシステムの輻輳制御装置。
- 請求項２記載のマルチタスクシステムの輻輳制御装置において、前記従属負荷検出手段が、処理対象の従属データの優先度の区分に応じて、予め用意された複数組のパラメータの中から１組のパラメータを選択し、選択された前記パラメータに基づいて第２の処理に関する負荷の大きさを識別することを特徴とするマルチタスクシステムの輻輳制御装置。
- 請求項１記載のマルチタスクシステムの輻輳制御装置において、前記従属負荷検出手段が、前記従属データの未処理の情報量と、前記従属データに割り当てられた記憶領域の大きさとに基づいて第２の処理に関する負荷の大きさを検出することを特徴とするマルチタスクシステムの輻輳制御装置。
- 請求項１記載のマルチタスクシステムの輻輳制御装置において、
前記第１の処理の実行に伴って変化するシステム資源の利用状況に基づいて、第１の処理に関する負荷の大きさを検出する一次負荷検出手段を更に設け、
前記従属負荷規制手段が、前記一次負荷検出手段の検出した第１の処理に関する負荷の大きさと、前記従属負荷検出手段の検出した第２の処理に関する負荷の大きさとに基づいて前記第１の処理を規制する
ことを特徴とするマルチタスクシステムの輻輳制御装置。 - 請求項５記載のマルチタスクシステムの輻輳制御装置において、前記従属負荷規制手段が、前記第１の処理に関する負荷の大きさと、第２の処理に関する負荷の大きさとを比較して、何れか大きい方に基づいて前記第１の処理を規制することを特徴とするマルチタスクシステムの輻輳制御装置。
- 請求項６記載のマルチタスクシステムの輻輳制御装置において、前記従属負荷規制手段が、前記第１の処理に関する負荷の大きさと、第２の処理に関する負荷の大きさとの少なくとも一方を重み付け補正し、重み付け補正後の第１の処理に関する負荷の大きさと、第２の処理に関する負荷の大きさとを比較して、何れか大きい方に基づいて前記第１の処理を規制することを特徴とするマルチタスクシステムの輻輳制御装置。
- 請求項５記載のマルチタスクシステムの輻輳制御装置において、前記従属負荷規制手段が、前記第１の処理に関する負荷の大きさと、第２の処理に関する負荷の大きさとを平均化した結果に基づいて前記第１の処理を規制することを特徴とするマルチタスクシステムの輻輳制御装置。
- 請求項８記載のマルチタスクシステムの輻輳制御装置において、前記従属負荷規制手段が、前記第１の処理に関する負荷の大きさと、第２の処理に関する負荷の大きさとの少なくとも一方を重み付け補正して、重み付け補正後の第１の処理に関する負荷の大きさと、第２の処理に関する負荷の大きさとを平均化した結果に基づいて前記第１の処理を規制することを特徴とするマルチタスクシステムの輻輳制御装置。
- 請求項５記載のマルチタスクシステムの輻輳制御装置において、処理の優先度が互いに異なる複数種類の従属データが存在する場合に、前記従属負荷規制手段が、第２の処理に関する複数区分の負荷の大きさを平均化して、平均化された第２の処理の負荷の大きさと、前記第１の処理に関する負荷の大きさとに基づいて前記第１の処理を規制することを特徴とするマルチタスクシステムの輻輳制御装置。
- 請求項１記載のマルチタスクシステムの輻輳制御装置において、前記従属負荷検出手段が、前記第２の処理に関する負荷の大きさを周期的に検出するとともに、検出された負荷の大きさの変化量と予め定めた閾値との比較結果に応じて、検出された第２の処理に関する負荷の大きさを補正することを特徴とするマルチタスクシステムの輻輳制御装置。
- 請求項１記載のマルチタスクシステムの輻輳制御装置において、前記従属負荷規制手段が、前記従属負荷検出手段が検出した第２の処理に関する負荷の大きさが予め定めた下限閾値より小さい場合には、前記第１の処理の規制を解除もしくは緩和することを特徴とするマルチタスクシステムの輻輳制御装置。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP05377498A JP3888762B2 (ja) | 1998-03-05 | 1998-03-05 | マルチタスクシステムの輻輳制御装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP05377498A JP3888762B2 (ja) | 1998-03-05 | 1998-03-05 | マルチタスクシステムの輻輳制御装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH11249914A JPH11249914A (ja) | 1999-09-17 |
| JP3888762B2 true JP3888762B2 (ja) | 2007-03-07 |
Family
ID=12952175
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP05377498A Expired - Fee Related JP3888762B2 (ja) | 1998-03-05 | 1998-03-05 | マルチタスクシステムの輻輳制御装置 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3888762B2 (ja) |
-
1998
- 1998-03-05 JP JP05377498A patent/JP3888762B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JPH11249914A (ja) | 1999-09-17 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP0991253B1 (en) | Predictive overload control for SPC switching systems | |
| US6687257B1 (en) | Distributed real-time operating system providing dynamic guaranteed mixed priority scheduling for communications and processing | |
| US7809876B2 (en) | Distributed real-time operating system | |
| EP0822494B1 (en) | Load balancing method and apparatus | |
| JP2940450B2 (ja) | クラスタ型コンピュータのジョブスケジュール方法及び装置 | |
| US7636310B2 (en) | Communication control system and communication control method | |
| US6134216A (en) | Integrated overload control for overload control for distributed real time systems | |
| US20080071947A1 (en) | Method of balancing I/O device interrupt service loading in a computer system | |
| JPH0964987A (ja) | 信号局輻輳制御システム | |
| KR970002740B1 (ko) | 계층 구조를 갖는 분산 교환 시스템의 상위 프로세서 과부하 제어 방법 | |
| JPS594398A (ja) | 中央制御装置の過負荷防止方法および装置 | |
| EP0913771B1 (en) | Autonomous overload control for distributed real time systems | |
| KR960016662B1 (ko) | 집중과 분산 운용의 혼성 교환기 시스템에서의 과부하 제어 방법 | |
| US8171484B2 (en) | Resource management apparatus and radio network controller | |
| JP3888762B2 (ja) | マルチタスクシステムの輻輳制御装置 | |
| CN115470006B (zh) | 一种基于微内核的负载均衡方法 | |
| US7353366B2 (en) | Processing device | |
| JPH10190730A (ja) | トラフィック制御方法および装置 | |
| RU2802911C1 (ru) | Способ балансировки трафика в узле коммутации транспортной сети связи | |
| JP3995972B2 (ja) | 輻輳制御方法、及びトラヒックコントロールシステム | |
| JP3166118B2 (ja) | サービス制御ノードにおける自律輻輳制御方法 | |
| JP3601426B2 (ja) | 輻輳制御システムと輻輳制御方法およびその処理プログラムを記録した記録媒体 | |
| JPH07297913A (ja) | 呼種別受け付け呼数決定方法 | |
| JP2938630B2 (ja) | 複数の処理方法を有するシステムにおける負荷制御方式 | |
| JP3225585B2 (ja) | 構内自動交換機 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20060201 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060214 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060417 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20060711 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060911 |
|
| A911 | Transfer of reconsideration by examiner before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20061004 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20061121 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20061128 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20091208 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101208 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111208 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111208 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121208 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121208 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131208 Year of fee payment: 7 |
|
| LAPS | Cancellation because of no payment of annual fees |