JP3712624B2 - 電話システムのインテリジェントネットワークにおける動的トラフィック管理 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、電話システムにおけるトラフィック管理に関し、特に、電話システムのインテリジェントネットワーク（ＩＮ）における動的トラフィック管理に関する。
【０００２】
【従来の技術及び発明が解決しようとする課題】
欧州電気通信標準化協会（ＥＴＳＩ）−ＩＮＡＰやＩＴＵ（ＣＳ−１Ｒ）およびＣＳ−２）におけるシステムのような、現在運用しているシステムにおいて、トラフィック管理は、サービスまたはネットワーク管理センターが、輻輳状態、または手動開始制御を要するなにか他の状態を検出した時に、手動で開始される。この状態では、ネットワーク管理センターの人は、ＳＣＰにおいて適当なサービスロジックを呼出し、コール ギャップ コマンドおよび／またはアクチベイト サービス フィルタリング（ＡＳＦ）コマンドを送って指定ルートを介する呼をろ波する前に、指定ルートを介する失敗した呼の数が、限界を超えたか否かに関する判定を行う必要がある。
【０００３】
かけがえとして、既知のＥＴＳＩ−ＩＮＡＰ動作を有するＳＣＰは、間接的な方法によって自動呼輻輳のための決定を行うことができる。この間接的な方法は、たとえば、ＩＮ呼ごとにＥＤＰ−４Ｒを備えさせ、その後、ＳＣＰのエンドにあるカウンタを維持して、コール ギャップまたはＡＳＦを送ることを決定する前に、ある時間にわたって失敗した呼の数の判定を行う方法である。ろ波基準は、トリガ基準が満足された場合に、被呼アドレス値および／またはサービスキーに基づくか、呼がＴＤＰ−ＴＤＰ２，ＴＤＰ３，ＴＤＰ４−のうちのいずれかに達した後か、などのいずれかで行われる。ＩＴＵ ＣＳ−１Ｒにより、ＴＤＰ４は、あるルートを介する失敗した呼を監視するのに使用できる通知モードで備えられる。しかしながら、これらの方法は、ＳＳＰとＳＣＰ間のＳＳ７リンクを介するトラフィックを不必要に増加させる。
【０００４】
ここで使用される略語：
ＡＳＦ−アクチベイト サービス フィルタリング
ＡＳＮ−１−アブストラクト シンタックス ノーテーション ナンバー ワンＡインフォ−アナライズ インフォメーション
Ａ'ド インフォ−アナライズド インフォメーション
ＢＣＳＭ−ベイシック コール ステート モデル
ＣＳ１−ケーパビリティ セット１
ＣＳ２−ケーパビリティ セット２
ＥＤＰ−イベント デテクション ポイント
ＥＲＢＣＳＭ−イベント レポートＢＣＳＭ
ＩＮＡＰ−インテリジェント ネットワーク アプリケーション プロトコル
ＩＮ−インテリジェント ネットワーク
ＩＴＵ−インターナショナル テレコミュニケーション ユニオン
ＲＲＢＣＳＭ−リクエスト レポートＢＣＳＭ
ＲＳＦ−ルート セレクト フェイルア
ＳＣＰ−サービス コントロール ポイント
ＳＳ７−シグナリング システム＃７
ＳＳＰ−サービス スイッチング ポイント
ＴＤＰ−トリガ デテクション ポイント
【０００５】
【課題を解決するための手段】
簡単に述べると、本発明の一態様によれば、上述の分野の問題は、、サービスコントロール ポイント（ＳＣＰ）等のインテリジェント ネットワーク ノードを用いたトラフィック管理方法を提供することにより克服され、技術上の進歩が達成される。この方法は、ＳＣＰが、指定ルート上のトラフィックを監視することによりインテリジェント決定を行うことができる方法を提供する。
【０００６】
本発明の他の態様によれば、上述の問題は、サービス コントロール ポイント（ＳＣＰ）に接続されたサービス スイッチング ポイント（ＳＳＰ）を有するシステムにおいて呼トラフィックを管理する方法および装置であって、ＳＣＰからＳＳＰへトラフィック監視開始要求を送信するステップと、トラフィック監視要求にしたがってＳＳＰにおける呼トラフィックを監視するステップと、上記監視の結果を含む応答をＳＣＰに送信するステップと、上記結果から、トラフィック管理が適用される必要があるかどうかを判定するステップと、
トラフィック管理が適用される必要がある場合は、トラフィック管理を適用するステップとからなる方法および装置を提供することによって克服され、技術上の進歩が達成される。
【０００７】
【発明の実施の形態】
図１は、現在既存の技術を用いたＩＮＡＰトラフィック管理動作中のＳＳＰ１２とＳＣＰ１４間のＥＴＳＩ ＩＮＡＰシステム１０における情報通信のフロー図を示す。第１システムの人は、イニシャルＤＰおよび／またはアナライズド インフォメーション メッセージをＳＣＰ１４に送信する。イニシャルＤＰメッセージは、ＩＮ呼ごとに、ＥＤＰ−４Ｒ等のイベント デテクション ポイントを備え、その後、ＳＣＰのエンドにあるカウンタを維持して、ある時間にわたって失敗した呼の数の判定を行う招待状である。ＳＣＰ１４は、ベイシック コール ステート モデルに基づくレポートの要求で応答し、特に、データアイテム４ｒ，７ｎおよび９ｂｒのレポートを要求する。また、ＳＣＰ１４は、ＳＳＰ１２から次の接続動作のためのアナライズド インフォメーションも要求する。それに応じて、ＳＳＰ１２は、ベイシック コール ステート モデル ルート セレクト フェイルアに基づくイベント レポート（ＥＲＢＣＳＭ−ＲＳＦ）を送信する。ＥＲＢＣＳＭ−ＲＳＦの送信後、ＳＳＰ１２は、他のイニシャルＤＰおよび／またはアナライズド インフォメーション メッセージをＳＣＰに送信する。ＳＣＰ１４は、他の処理をスタートして、後続のＥＲＢＣＳＭ−ＲＳＦを入手する。ＳＣＰ１４は、より多くのデータを集めた後、コール ギャップを送る新たな行き先ルーティングアドレス（ＤＲＡ）を送信する前に、失敗ルートを覚えておく。知られているように、ＳＳＰ１２とＳＣＰ１間にはこのようなメッセージシーケンスが多く存在し、それにより、それらの間のＳＳ７接続が重くローディングされる。これが、本発明前の技術状態である。
【０００８】
図２に示されるように、方法２００は、ＳＳＰ１２'とＳＣＰ１４'間のＳＳ７接続を負担させるという欠点を持っていない。ＳＳＰ１２'とＳＣＰ１４'は、図１のＳＳＰ１２およびＳＣＰ１４と非常に似ているが、本発明による動作を提供するソフトウェアを持っている。システム１０'のための新たな方法２００は、ＳＣＰ'が送信する非呼関連動作ＭｏｎｉｔｏｒＲｏｕｔｅＲｅｑｕｅｓｔ（新）を有し、これは、ＳＣＰ'１２が監視されるべきルート／ルートリストを指定するものである。この動作は、ＳＳＰ１２'で失敗が高い水準に達した時にＳＣＰ'１４に通知する（図３に示される）か、指定時間の間の指定間隔内に指定ルートを介する失敗した呼の数をＳＣＰ１４'に通知する（図４に示される）かのどちらかをするためにＳＳＰ１２'に要求することができるパラメータを有する。これは、ＳＣＰ１４'が、ルート／ルートリストの指定セットのためにＤＰ４（ルートセレクト失敗）を動的に備えるようにＳＳＰ１２'に要求し、指定されたルートを介する呼がこの特定のＤＰ４に適合する時はいつでもカウンタをインクリメントすることによって行われる。これは、ＴＤＰ−４を静的に備えることと同じではない。ＳＣＰ１４'は、指定ルートを介する呼が失敗した時はいつでも、ＳＳＰ１２'に、ルートセレクトフェィルアカウンタをインクリメントするように要求する。監視基準が満足された場合は、ＳＳＰ１２'は、指定間隔の間にルートセレクトフェイルアの数を伴う、または高い水準標が達成されたことを示すパラメータに書き入れることにより、ＴＣ−Ｂｅｇｉｎでモニター ルート レポートを送信する。次いで、ＳＣＰ１４'は、適当なろ波基準を有するコールギャップまたはＡＳＦのどちらかを送信することを決定できる。ろ波基準は、１つのレポートか数個のレポートのいずれかに集められた情報のため、指定された持続時間において失敗したこの数に基づくことができる。ＳＣＰ１４'は、通過すべき呼の数と、切れ目が設けられろ波される必要がある呼の数を計算するサービスロジックを持つことができる。総合的結果は、ＳＣＰ１４'が、ＳＳＰ１２'で検出されるようにスイッチにおけるトラフィック問題のより良いリアルタイム制御を持つことになる。呼の切れ目を設けること／ろ波することは、動的であり、人間のオペレータの介在なしに行うことができる。かけがえとして、ＳＣＰ１４'は、ＳＳＰ１２'にコネクト／アナライズ インフォメーション動作を送信する場合にこの情報を使用する。失敗ルート情報のため、ＳＣＰ１４'は、さもなければネットワーク輻輳に起因する失敗の高い可能性があるルートに重なるそれらのＤＲＡ（行き先ルーティングアドレス）を回避することができる。このような場合には、他のルートが、コネクト／アナライズ インフォメーション動作中にＤＲＡで送信される。これは、ネットワーク輻輳に起因するＩＮ呼失敗の失敗率が低くなり、ネットワークロードが、妥当な限界内に維持され、それにより、呼のより大きなパーセンテージが、システム１０'で満たされるのが可能になる。また，このようなサービスは、ネットワーク輻輳の時間中、自動呼分配（ＡＣＤ）呼のより高いパーセンテージを満たすためにネットワーク輻輳に向かう責任があるルートを介するＡＣＤに使用することができる。
【０００９】
モニター ルート リクエストは、クラス１動作であり、この動作のためにエラーと返送結果の両方を送信できることを意味する。この動作は、非呼関連動作であり、呼に関して送信されるべきではない。
【００１０】
以下は、方法２００とエラーメッセージも提供するように、ＳＳＰ１２'とＳＣＰ１４'を動作させるＳＣＰ機能（ＳＣＦ）とＳＳＰ機能（ＳＳＦ）の技術的な定義である。この技術的な定義は、ＣＣＩＴＴ Ｘ．２０８（１９９９）で定義されたＡＳＮ−１（アブストラクト シンタックス ノーテイション^#1）で指定される。
【００１１】
【表１】

【００１２】
【表２】

【００１３】
モニター ルート リクエスト手順
この動作を受信した場合、ＳＳＦは、ＤＰ４ヒット（ルート セレクト フェイルア）のために指定されたルートを監視する。ＳＳＦは、あるスレショールド（しきい値）が達成された時（監視基準）か停止時間に達した時のいずれかの時に、この動作の結果を転送する。
パラメータ：
１．ルートリスト：このパラメータは、監視すべき発信中継線グループを指定するのに使用される。また、ルートの順番を提供することができる。
２．相関ＩＤ：このパラメータは、モニター ルート リクエストをＤＤＦより送信されるモニター ルート レポートと関連付けるために、ＳＣＦで使用される。
３．監視基準：このパラメータは、監視結果がＳＣＰに送信されるべきである場合に指定される。
Ａ．スレショールド−このパラメータは、スレショールドを超えた時はいつでも、レポートが送信されるべきであることを指定する。
Ｂ．インターバル−このパラメータは、監視レポートがインターバルタイマーの満了時に送信されるべきであることを示す。
４．監視タイムアウト：このパラメータは、監視が能動になっている持続時間を示す。
Ａ．持続時間−持続時間タイマーが満了すると、監視が解除される。
‘０'の持続時間は、監視が解除されるべきであることを示す。
‘−１'の持続時間は、無限持続時間を示す。
Ｂ．停止時間：停止時間が満足されると、ルート監視は解除される。
５．開始時間：このパラメータは、ろ波が開始される時を定義する。“開始時間"が提供されないか、または既に満足されていた場合は、ＳＳＦは、直ちに監視を開始する。
【００１４】
質問エンティテイ（ＳＣＦ）
通常手順
ＳＣＦ前条件
１）サービス ロジック プログラム インスタンス（ＳＬＰＩ）は、指定ルートを介するトラフィックを監視するのを決定する。
ＳＣＦ後条件
１）サービス ロジック プログラム インスタンス（ＳＬＰＩ）は、アプリケーションタイマーをスタートさせて、監視ルートの予想されるエンドを監視する。
２）サービス コントロール ファンクショナリティ マネジメント エンティテイ（ＳＣＭＥ）は、“ＳＳＦモニタリング ルート レポートの待ち受け"状態になる。
【００１５】
応答エンティテイ（ＳＳＦ）
通常手順
ＳＳＦ前条件：
１．なし
ＳＳＦ後条件
１．サービス スイッチング ファンクショナリティ マネジメント エンティテイ（ＳＳＭＥ）有限状態マシン（ＦＳＭ）は、“非呼関連処理"状態になる。
【００１６】
【表３】

【００１７】
モニター ルート レポート手順
包括説明
この動作は、前のモニター ルート リクエスト動作のルートリスト カウンタの値を報告するのに使用される。
パラメータ：
１．ルートカウンタ：このパラメータは、監視期間中の選択されたルートを介する失敗した呼のカウントを含む。それは、ルートカウンタＩＤおよび関連値のリストとなる。スレショールドが指定ルートのために指定された場合は、カウンタ値は、指定されたスレショールド値を維持する。
２．相関ＩＤ：このパラメータは、前に送信されたモニター ルート リクエストからモニター ルート レポートを関連付けるためにＳＣＦで使用される。
【００１８】
質問エンティテイ（ＳＳＦ）
通常手順
ＳＳＦ前条件
１）ルートの監視が現在ランしており、インターバルタイマーは満了した；または
２）ルートの監視がランしており、スレショールド値に達した；または
３）監視が終了した（持続時間タイムが満了した、または低し時間が満足した）；または
４）動作モニター ルート リクエストが受信され、能動ルート モニタリング エンティテイに出会う。
ＳＳＦ後条件
１）ルートの監視が進むか、または、持続時間タイムに依存して終了する。
エラー処理：エラー処理に関連する動作は、クラス４動作に起因して適用できない。
【００１９】
応答エンティテイ（ＳＣＦ）
通常手順
ＳＣＦ前条件
１）ルートの監視がランしている。
２）ＳＣＭＥが、“ＳＳＦモニター ルート リクエストの待ち受け"状態にある。
ＳＣＦ後条件
ＳＣＭＥは、受信したカウンタ値をＳＬＰＩに転送する。
【００２０】
すなわち、新規な動的トラフィック管理装置および方法が示され、説明されたことがわかる。本発明は、好適な実施例に関して説明されたが、当業者は、付随の請求項で定義されるように、本発明の範囲から逸脱することなく多くの他の配置を工夫することができる。
【図面の簡単な説明】
【図１】既知のＩＮＡＰ動作を用いたトラフィック管理を示すブロック図である。
【図２】本発明による動作を用いたトラフィック管理を示すブロック図である。
【図３】スレショールドベースのトラフィック管理シーケンスのフロー図である。
【図４】持続時間ベースのトラフィック管理シーケンスのフロー図である。

Claims (10)

1. ＳＳ７接続に接続されたサービス・スイッチング・ポイントＳＳＰを有しサービス・コントロール・ポイントＳＣＰにシグナリングする電話システムにおいて、該ＳＣＰで呼トラフィックの過負荷を管理する方法であって、
   該ＳＳＰで該ＳＣＰから送信されたトラフィック監視開始要求を受信するステップ、
   該トラフィック監視開始要求に従って、該ＳＳＰによって呼トラフィックを監視するステップ、
   該ＳＳＰで該呼トラフィックを監視する時間間隔を決定するステップ、
   該ＳＳＰで該時間間隔の呼の失敗数が所定のしきい値を超えているか否かを判定するステップ、
   呼の該失敗数が該所定のしきい値を超えている場合に、該ＳＳＰから該ＳＣＰへ該監視の結果を含む応答を自動的に送信するステップ、
   該ＳＣＰにおいて、該ＳＳＰから受信したトラフィック負荷情報に基づいて、トラフィック管理が適用される必要があるかどうかを判定するステップ、及び
   トラフィック管理が適用される必要がある場合に、トラフィック管理指令を該ＳＣＰから該ＳＳＰへ送信するステップを含む該ＳＣＰによるトラフィック管理を開始するステップ
   からなる方法。
2. 請求項１記載の方法において、前記トラフィック監視開始要求はＴＣ−Ｂｅｇｉｎ（取引開始）・リクエストである方法。
3. 請求項１記載の方法において、前記トラフィック監視開始要求は監視ルート・リクエストであり、前記ＳＣＰへの応答は、呼の失敗が高水準に達した旨の情報を有する監視ルート・レポートである方法。
4. 請求項１記載の方法において、
   前記トラフィック監視開始要求は監視ルート・リクエストであり、
   前記ＳＣＰへの応答は、呼の失敗が高水準に達した旨の情報を有する監視ルート・レポートであり、
   前記トラフィック管理指令がコール・ギャップ指令からなる方法。
5. 請求項４記載の方法において、コール・ギャップ基準は該コール・ギャップ指令と共に送信される方法。
6. 請求項１記載の方法において、前記トラフィック監視開始要求は、設定された期間に対する呼の全失敗を監視するためのＴＣ−Ｂｅｇｉｎ（取引開始）・リクエストであり、前記ＳＣＰへの応答は、予め設定され満了した期間における呼の失敗数の情報を有する監視ルート・レポートである方法。
7. 請求項１記載の方法において、
   前記トラフィック監視開始要求は設定された期間に対する呼の全失敗を監視するためのＴＣ−Ｂｅｇｉｎ（取引開始）・リクエストであり、
   該ＳＣＰへの前記応答は、該設定された期間における呼の失敗数の情報を有する監視ルート・レポートであり、
   前記トラフィック管理指令がコール・ギャップからなる方法。
8. 請求項１記載の方法において、
   前記トラフィック監視開始要求は設定された期間に対する呼の全失敗を監視するためのＴＣ−Ｂｅｇｉｎ（取引開始）・リクエストであり、
   該ＳＣＰへの前記応答は、該設定された期間における呼の失敗数の情報を有する監視ルート・レポートであり、
   前記トラフィック管理ステップの適用は、さらに、該ＳＳＰに提出された行き先ルートアドレス（ＤＲＡ）データフィールドにおける代替ルートを有する接続解析情報を送信するステップを含む方法。
9. 請求項１記載の方法において、
   前記トラフィック監視開始要求は監視ルート・リクエストであり、
   前記ＳＣＰへの応答は、呼の失敗が高水準に達した旨の情報を有する監視ルート・レポートであり、
   前記トラフィック管理ステップの適用は、該ＳＳＰに提出された行き先ルートアドレス（ＤＲＡ）データフィールドにおける代替ルートを有する接続解析情報を送信するステップを含む方法。
10. ＳＳ７接続に接続されたサービス・スイッチング・ポイントＳＳＰを有しサービス・コントロール・ポイントＳＣＰにシグナリングする電話システムにおいて、該ＳＣＰで呼トラフィックの過負荷を管理する装置であって、
    該ＳＳＰで該ＳＣＰから送信されたトラフィック監視開始要求を受信する手段、
    該トラフィック監視開始要求に従って、該ＳＳＰによって呼トラフィックを監視する手段、
    該ＳＳＰで該呼トラフィックを監視する時間間隔を決定する手段、
    該ＳＳＰで該時間間隔の呼の失敗数が所定のしきい値を超えているか否かを判定する手段、
    呼の該失敗数が該所定のしきい値を超えている場合に、該ＳＳＰから該ＳＣＰへ該監視の結果を含む応答を自動的に送信する手段、
    該ＳＣＰにおいて、該ＳＳＰから受信したトラフィック負荷情報に基づいて、トラフィック管理が適用される必要があるかどうかを判定する手段、及び
    トラフィック管理が適用される必要がある場合に、トラフィック管理指令を該ＳＣＰから該ＳＳＰへ送信することを含む該ＳＣＰによるトラフィック管理を開始する手段
    からなる装置。

Images