コラボレーション : Cisco ICM Router Software

予測遅延 (ED) の理解

2016 年 10 月 27 日 - 機械翻訳について
その他のバージョン: PDFpdf | 英語版 (2015 年 8 月 22 日) | フィードバック


目次


概要

このドキュメントでは、予測遅延(ED)に関連している既存の一般的な問題をリストに示し、ED 計算方法、データの送信元、および問題をトラブルシューティングする方法について説明します。

前提条件

要件

次の項目に関する知識があることが推奨されます。

使用するコンポーネント

このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づくものです。

  • Cisco ICM 4.6 2 以降

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。 このドキュメントで使用するすべてのデバイスは、クリアな(デフォルト)設定で作業を開始しています。 ネットワークが稼働中の場合は、コマンドが及ぼす潜在的な影響を十分に理解しておく必要があります。

表記法

ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。

背景説明

ED は Cisco ICM、Cisco Network Applications Manager (NAM)、および IP Contact Center (IPCC)環境で使用されるメトリックです。

大まかに言えば、ED はサービスのためのキューに追加されるあらゆる新しいコールのための予測された遅延(秒で)です。 ED はエージェントが利用できないときだけ有効です。

エージェントが利用できる場合、ED はゼロです。

Minimum Expected Delay (MED)はスクリプト エディタの選定されたおよびルート SELECT ノードで利用可能 な標準選択規則です。か。 マルチプルサービスから選択し、標準 MED ルールを使用すれば、CallRouter は MED (最小)に最小値を用いるサービスを選択します。

十分に ED を理解するために、ED がどのように計算されるか知って下さい。

ED はサービスだけ計算です。

一組のスキル グループに MED とルーティングできません。 標準 ED 数式はここにあります:

((CallsQNow + 1) * AHTto5) / Max (Agents Talking [OR] Ready)
  • CallsQNow は周辺装置にサービスのためのキューの現在の呼び出しの数です。

  • +1 がキューに可能性としては追加することができるコールを示すのに使用されています。

  • AHTto5 (秒で)電流の間にサービスに呼び出しのための Average Handle Time と定義されて 5 分 interval.?AHTto5 はです「転送」5分平均(今後、および最新 5 分のために)あり、リアルタイムで計算されます。か。AHT の値はとして計算されます:

    HandleTimeTo5/CallsHandledTo5

  • HandleTime はサービスのために処理されるように数えられる受信 ACD 呼び出しのためにだけトラッキングされます。か。HandleTime はコールに費やされる合計時間を参照します。 従って、HandleTime はトータル コール 期間です時間からエージェントはエージェントがの後コール作業を完了した時間にコールに応答しました。か。HandleTime はコールと関連付けられる TalkTime、HoldTime、および WorkTime が(Termination_Call_Detail から)含まれています。か。 AvgHandleTime 値はデータベースでエージェントがコールと関連付けられるすべてのの後コール作業を完了するときアップデートされます。

最新 5 分 間隔の間に扱われたサービスのための受信 ACD 呼び出しがなかった場合 Cisco ICM は ED 数式で 120 秒のデフォルト AHT 値を使用します。か。このデフォルト AHT 値を設定できません。か。それは router.exe アプリケーションでハードコードされます。

分母では、CallRouter は(どの値が現在より高い) AgentsTalking 値、か AgentsReady 値使用します。

  • AgentsTalking の値は話す状態のサービス エージェントの現在数です。 AgentsTalking 値はサービスですべてのスキル グループが含まれています(Service_Member で定義されたように)。

  • AgentsReady 値は Skill_Group_Real_Time 表から来、READY 状態でエージェントが含まれています。か。準備ができてエージェントがシステムにログオンされる、コールに現在、またはの後コール作業で含まれて、または利用可能 なハンドル新しいコールです状態は。か。 以前に述べられるように、ED はエージェントが利用できないと仮定します。 AgentsReady 値は Service_Member のプライマリと定義されるスキル グループでそれらのエージェントだけ含まれています。

いくつかの ACD は異なる優先順位の複数のサブスキルのエージェントを、サポートします。か。CallRouter は AgentsReady を考慮し、サブスキル第 1 (1)のメンバーであるそれらのエージェントだけが含まれています。

期待された遅延を解決して下さい

ED がどのように計算されるか理解するとき、ED 数式が予期しない値という結果に終る状況を解決できます。か。問題が周辺サービスに関係するので何回も、Cisco ICM および ACD コンフィギュレーションのミスマッチに ED における問題をトレースできます。か。サービスおよびスキル グループ ペリフェラル番号が正しいこと、そして Service_Member 情報が正確であることを確認して下さい。か。エージェントがメンバー スキル グループ ログイン されるようにして下さい。か。サブスキルを使用する場合、エージェントがサブスキル第 1 (1)ログイン されるようにして下さい。

設定が正確である場合、イネーブル特定のトレース問題を確認するため。

外挿

ルータの外挿メカニズムの簡潔な説明はここにあります。 このセクションは外挿が必要なぜである、そしてどのように設定されているか説明します。

外挿例

では、簡単なルーティングスクリプトがキュー内のコール数だけを基にコールのロードバランスを試みて、最小コール数でコールを発信をするとしましょう。

この例がキュー コールを示すが、同じメカニズムは資料で他のいくつかの変数のために、リストされた以降使用されます。

  1. コールは到着します。

  2. ルータはサイトを選び、コールを発信します。

  3. ネットワークはコールを渡します。

  4. ACD はコールが着くのを見キュー コールを送信する内部スクリプトを実行します。

  5. Cisco ICM は(PIM および OPC によって)キュー統計情報のコールおよび変更に注意します。

  6. Cisco ICM はキュー コールの数が更新済であるルータに戻って報告します。

これすべては起こるのに時間をかけます。 発生するためにすべてのこれらのステップのための 7 秒かかる場合があります。 それらの 7 秒に関しては、ルータはまだキュー コールの数が初期値であることを判断します。 ルータがルーティングするべき新しいコールを与えられる場合ルータはまだ同じサイトが最もよいサイトであることを判断します。 大量アプリケーションでは、PG から最終的に更新済キュー カウントを受け取る前にサイトに容易にたくさんの呼び出しを送ることができます。 その時、他のサイトは突然大いによりよく検知 し、ルータはそのサイトにすべての呼び出しを送ります。 現象は「消火ホースルーティング」と呼ばれます。

これは例単にです。 時間数は含まれるネットワーク、ACD、または VRU によって決まります。 ルータにこの問題を解決する限られた情報があります。 特に、ルータにはPG 従って、例えばPG

Cisco ICM で設定されるルータの外挿メカニズムはソリューションです。 実質値を推定することを試みるのにメカニズムが使用されています。 ここに外挿がサービスのための CallsQueueNow のような変数のためにどのようにはたらくかです:

内部的には、CallsQueueNow は 2 人の部で管理されます:

  • 最後に値である CallsQueueNow 基礎値は PG によって、報告しました。

  • ルータによって管理される CallsQueueNow 調整。

ルーティングスクリプトは CallsQueueNow を参照するとき、基礎値および調整の合計を調べます。 CallsQueueNow が AW にリアルタイム供給で送信 される時、基礎値だけが送信 されます。 調整を管理するために、ルータはコールがサービスにルーティングされる追加し、次にタイマーを設定 しますとき 1 つを。 タイマーのデフォルト値は 10 秒です。 タイマーが切れるとき、ルータは調整から 1 つを引きます。

実際の数との例はここにあります:

3 つのキュー コールがあると仮定して下さい:

  1. 最初に、base=3、adjustment=0

  2. コールはサービスに到着し、base=3、adjustment=1 ルーティングされます。 この時点でルーティングされる他の呼び出しは 3+1=4 キュー コールを見ます。

  3. 7 つは数秒後、そこの PG レポート 4 つのキュー コールです。 この場合 base=4、adjustment=1 (まだ)。 この時点でルーティングされる呼び出しは 5 つのキュー コールの過大評価された値を調べます。

  4. 3 つは数秒後、10 秒外挿タイマー切れます。 この場合 base=4、adjustment=0。

この例はキュー コールの数の過大評価を示したものです。

同じようなメカニズムはいくつかのルーティングパラメータで使用されます。 この表は外挿法で推定される変数をリストしたものです:

オブジェクト フィールド 方向
サービス CallsQNow
ExpectedDelay
CallsInProgress
CallsInNow
スキル グループ AgentsAvailable
NetworkTrunkGroup TrunksIdle
CallsInNow

方向カラムは調整が [+1 になされる方向を()または– 1 ()示します]。 外挿メカニズムもエージェントを管理するのに使用されています。

特に、LongestAvailableAgent 変数は全く異なるメカニズムによってここに記述されているものがと管理されます。 ルータは PG から個々 の エージェントのステータスを受け取ります。 内部的には、それはエージェントが利用可能になるとき発注されるすべての対応可能なエージェントのリストをまでに保持します。

エージェントが(たとえば LAA で)選択される時、ルータは 10 秒の間「一時的に利用できない」としてリストのヘッダーでエージェントを示します。 この時間の間に、PG は状態レポートを無視し、エージェントが利用できないとルータは仮定します。 それ以後、エージェントの状態は PG が最後に報告したものは何でもに戻ります。 このメカニズムは ACD が間違ったエージェントにコールを発信することを起こる場合ルータが特定のエージェントの使用を説明するようにしリカバリを有効に します。 この種類のルーティングは他のメトリックより精密である場合もあります。 これは ACD がルータが推測するエージェントに呼び出しを送る限り調整がなされないという理由によります。

時々、AgentsAvailable および LongestAvailable の動作についての混合がある場合もあります。 AgentsAvailable は up/down アルゴリズムによって調節され、利用可能 な エージェントの数を過少見積りできます。 LongestAvailable は対応可能なエージェント リストから独自に計算されます。 LongestAvailable は AgentsAvailable がゼロを示すのに利用可能 な エージェントを示すことができます。 従って、LongestAvailable は上記されるようにより正確、です。

セットによって期待される遅延トレース

期待された遅延トレースは「外挿法で推定される」、rttest によってトレースを設定できます値を表示し。

trace_ed N

N がサービスの SkillTargetID であるところ。 このコマンドはトレースをつけます。

trace_ed N /off

このコマンドはトレースを終えます。

このトレースを有効に するとき、CallRouter はコンソール ウィンドウと .EMS ログファイルにデバッグ レベル Log エントリを置きます。か。 ログファイル出力を表示するのに dumplogInspectLog ビュー ユーティリティを使用して下さい。か。ルータはこのメッセージを印字します:

ED RR NAME(ID) xNN B=(qNN rNN tNN aNN hNN eNN) E=(qNN rNN tNN aNN hNN eNN)

RR はトレースのための原因を表します。 さまざまなコード 記述はここにあります:

コード 説明
T+
トレースはつきます。
T-
トレースは終わります。
E+
外挿はコールがルーティングされるとき)開始します(これは引き起こされます。
E-
外挿は終了します(10 秒タイムアウト)。
SK
スキル グループ 変数が(変更したので更新済 PG は変更を報告します)。
SV
サービス変数が(変更したので更新済 PG は変更を報告します)。

  • NAME (ID)はサービスの名前および ID を表します。

  • XNN は進行中の外挿の数です。 これは最後の 10 秒の呼び出しの数です。

いくつかのコード 記述はここにあります:

コード 説明
QNN
キュー コール。
Rnn
準備ができたエージェント。
Tnn
エージェント話すこと。
Ann
利用可能 な エージェント。
Hnn
5.への Average Handle Time。
Enn
期待された遅延。

2 組のこれらの変数があります:

  • 設定 される B= は() PG によって報告されるようにすべての変数の、設定 される「それらから計算されるベース」および ED です。

  • E() セットは」外挿法で推定される「、最近ルーティングされた呼び出しに基づいて設定 されてです。

期待された遅延を解決する他のツール

MED を解決するのにスクリプト エディタのディスプレイ リアルタイム データの機能を使用できます。か。スクリプト エディタで表示する データが 15 秒または多く古い場合もあるで外挿法で推定された値よりもむしろ基礎値を、表示します頻繁にただことを確認することは重要。

ED を解決するためにリアルタイムのデータを検知 して下さい。か。これのために、CallRouter が知っているさまざまな値をおよび変数を表示するのに rttest 内からの dump_vars コマンドを、使用して下さい。

Rttest: dump_vars /?

リストされている値は外挿法で推定することができます。

構文例

rrtest では、実行して下さい:

dump_vars /service <Service.SkillTargetID>

または

dump_vars /group <Skill_Group.SkillTargetID>

ISQL/W によって SkillTargetID を判別できますまたは速いクエリ機能はスキーマ ヘルプ プログラムで見つけました。

サービスまたはスキル グループ SkillTargetID の適切な値を入力する場合、変数名のリスト(たとえば、AgentsAvailable および AgentsReady)および各変数の値のカラムを表示する rttest。か。通常、値は正の整数であり、値が未定義であることを self-explanatory.?-1 は示します。

解決するとき、rttest で調べられる ACD からの入手可能な情報と値を dump_vars 比較して下さい。か。 データを比較するとき、問題の原因である場合もある可能性のある不規則性を探して下さい。

何人かの Ciscoカスタマー サポートエンジニア(CSE)はまた rttest視聴 コマンドで成功がありました。か。視聴 コマンドは適当な式を評価することを可能にします。か。 視聴 コマンドはカスタム数式を解決して役立ちます(たとえば、「ExpectedDelay」カスタム計算)。か。式の値を変更する場合、CallRouter は現在 の 値を用いる Router Process ウィンドウですぐにエントリが(.ems ファイルで)含まれ。

ここに視聴 コマンドをどのように発行する必要があるかです:

rttest: watch <expression>

ここで、

  • 「式」は有効な式、ですたとえば:

    rttest: watch Service.Boston_Aspect.Support.AgentsReady 
    Watch 0 added.
  • /delete スイッチによって視聴を取除くことができますたとえば:

    rttest: watch 0 /delete

OPCTest におよび Procmon にまたエージェントおよび呼び出しをリストすることを可能にするさまざまなサブルーチンがあります。か。ACD について認知し、CallRouter ものをのこれらの値をクロスレファレンスして下さい。 問題の原因である場合もある可能性のある不規則性を探して下さい。

最近 Cisco ICM およびあなたを始動新しいサービスはじめてインストールしたら、MED は期待するものをと異なります。か。何回も、MED はこれらの原因の 1 つが理由で異なっています:

  • 外挿の効果。

  • 呼び出しは扱われません(デフォルトは AHT のための 120 秒で、期待することができません)。

  • 少数の呼び出しは進行中またはキューにです。

ED 平均するべき多くの項目があるときほとんどは正確あります。か。より多くのエージェントがメンバー スキル グループで利用でき、より多くの呼び出しが扱われるとき、MED 結果はよりよいです。


関連情報


Document ID: 29522