リファレンス設計ソリューションのサイジング
Contact Center Enterprise ソリューションでは、リソースの適切なサイジングが必要となります。この章では、こういったリソースのサイジング用ツールおよびメソッドを説明します。サイジング対象には以下のリソースが含まれます。
-
必要なコンタクト センター エージェント数(希望通話量およびサービス レベルなどの顧客の要件に基づく)
-
さまざまなコール シナリオ(コール処理、プロンプトおよび収集、キューイング、セルフサービス アプリケーションなど)に必要な VRU ポートの数
-
着信および発信トラフィック ボリュームを伝送するために必要な音声ゲートウェイ ポート数
適切なサイジングでは、アーラン-B モデルと アーラン-C モデルにカプセル化されたトラフィック エンジニアリングの原則が使用されます。
連絡先でのリソース使用
Contact Center Enterprise ソリューションのサイズを決定する際の主なリソースは以下の通りです。
-
エージェント
-
ゲートウェイ ポート (PSTN トランク)
-
VRU ポート
通話がすぐに応答されない場合は、通話タイムラインに呼び出し遅延時間(ネットワーク呼び出し音)を含めます。平均呼び出し遅延時間は数秒です。計算にはトランクの平均処理時間に追加します。
コンタクト センターのトラフィック用語
これらは、コンタクトセンター リソースのサイジングに関する最も一般的な業界用語です。
- 最繁時または最繁期間
-
ビジー間隔は1時間以下です。最繁期間は、1 日のうちでトラフィックが最も集中する時間帯に発生します。繁忙時間や間隔は、週末や季節の影響などの状況により異なります。最繁時の平均値(1 年で最も混雑する時間の上位 10 の平均値)を使用して設計します。ただし、マーケティング キャンペーンや季節の最繁時(祝日のピークなど)に対応するために人員配置が必要な状況では、必ずしもこの平均値を適用できるわけではありません。コンタクト センターでは、ピーク期間に基づいて最大数のエージェントを配置します。ただし、一定期間毎に(通常は 1 時間毎)その日の残りの要件を計算します。これにより、トレーニングやコーチングなどのオフライン アクティビティのエージェントはスケジュールせずに、コールに応答するエージェントを適切にスケジュールすることができます。トランクあるいは VRU ポートについては、多くの場合、トランクやポートを毎日追加または削除することは現実的ではないため、こういったリソースはピーク期間に合わせてサイジングします。小売業界の環境によっては、ピーク シーズン中に増設用トランクを追加して、その後、切断することもあります。
- 最繁時呼数(BHCA)
-
BHCA とは、トラフィックのピーク時(または期間)にコンタクト センターで受信または受信を試みたコールの総数です。便宜上、音声ゲートウェイに渡されるすべてのコールがコールセンター リソースによって受信され、処理されると想定します。コールは通常、PSTN から発信されますが、コンタクト センターへのコールは、ヘルプ デスク アプリケーションなどによって内部的に生成されることもあります。
- コール ルータから報告される毎秒のコール数(CPS)
-
これは、Unified CCE ルータがコール ルーティング要求を受信するレートです。すべてのコールは、イングレス ゲートウェイから VRU 処理、エージェントへのルーティングまでの単純なコール フローで単一のコール ルーティング要求を生成します。ただし、最終的に適切なエージェントに到達するために、ルータに対して複数のルーティング要求を行う必要があるコールもあります。
この例は、コールを受信した最初のエージェントが、ポスト ルーティングを使用して別のエージェントに転送または会議を行うケースです。これにより、追加のルーティング要求が生成され、同じコールがルーターへの 2 つのルーティング要求を生成します。リソースがコールまたはタスクに必要な場合は、常にルーターに対してルーティング要求が行われます。これらのリクエストには、E メール、チャット、コールバック、特定のアウトバウンド コールのマルチメディア リクエストも含まれます。コールセンターの管理者は、コンタクト センターの規模を決める際に、これらの追加のコール ルーティング要求を考慮する必要があります。
サポートされる最大コール レートは、イングレス ゲートウェイの BHCA ではなく、ルータによって報告されるコール レートです。これらの追加のルーティング要求をイングレス ゲートウェイでの BHCA の計算に含めます。通常、イングレス ゲートウェイの BHCA は、ルータによって報告される対応する CPS レート以下となります。
たとえば、以下の状況が考えられます。イングレス ゲートウェイの BHCA が 36,000 の場合、イングレス ゲートウェイのコール レートは 10 CPS です。コールの 10% がルータを介して転送されると仮定した場合、ルータによって報告される CPS は 11 CPS と同等となります。この場合、ソリューションには 11 CPS の容量が必要です。
- サーバ
- サーバは、トラフィック負荷またはコールを処理するリソースです。コンタクト センターには多くの種類のサーバがあります。タイプ毎に異なるリソースが必要になる場合があります。
- 通話時間
-
通話時間は、エージェントが発信者との通話に費やす時間です。これには、エージェントが発信者を保留にしたり、コンサルテーションの会議中に費やした時間が含まれます。
- ラップアップ時間(コール後の作業時間)
-
コールが終了すると (発信者が電話を切ると)、エージェントは特定のタスクを完了してコールの「後処理」を行います。後処理時間には、データベースの更新、コールのメモの記録、またはエージェントが別のコールに応答できるようになるまで実行されるその他のアクティビティなどのタスクが含まれます。Unified Contact Center Enterprise ソリューションでは、この期間を コール後の業務時間と呼ぶことがあります。
- 平均処理時間(AHT)
-
AHT とは、指定された期間内でのコールの平均継続時間のことです。これは、セルフサービス コールのコール処理時間や、エージェントへのコールの通話時間など、いくつかのタイプの処理時間の合計を指します。最も一般的な定義では、AHT はエージェントの通話時間とエージェントのラップアップ時間の合計となります。
- アーラン
-
アーラン(アーラン)は最繁時のトラフィック負荷を測定する単位です。アーランは、同一の回線、トランク、またはポート上にコールが 3,600 秒(60 分、つまり 1 時間)存在していることに基づきます。(コールの数や平均継続時間に関係なく、1 つの回線が 1 時間にわたって話中になる状態です)。アーラン値の計算には以下の数式を使用します。
Traffic in Erlangs = (Number of calls in the busy hour * AHT in sec) / 3600 sec
コンタクト センターが最繁時に 6 分間のコールを 30 回受信した場合、これは最繁時に 180 分のトラフィック、つまり 3 アーランに相当します。最繁時にコンタクト センターが平均 36 秒のコールを 100 回受信した場合、受信した総トラフィックは 3600 秒、つまり 1 アーラン(3600 秒/3600 秒)になります。
- 最繁時トラフィック(BHT)(アーラン単位)
-
BHT は最繁時のトラフィック負荷です。BHCA と AHT の積として計算され、1 時間で正規化されます。
BHT = (BHCA * AHT seconds) / 3600
たとえば、最繁時にコンタクト センターが平均 2 分間のコールを 600 回受信した場合、最繁時のトラフィック負荷は(600 X 2/60)= 20 アーランとなります。
BHT は通常、PSTN トランクなどのリソースを計算するためにアーラン B モデルで使用されます。
- サービス グレード(ブロック率)
- この測定は、最繁時にリソースまたはサーバが話中になる確率を示します。そのような場合、そのコールは失われるかブロックされます。このブロック率は通常、音声ゲートウェイ ポート、VRU ポート、PBX 回線、トランクなどのリソースに適用されます。音声ゲートウェイの場合、サービス グレードは、総 BHCA に対するブロックされたコールの割合またはビジー トーン(使用可能なトランクなし)を受信したコールの割合となります。たとえば、サービス グレード 0.01 は、最頻時にコールの 1 % がブロックされることを意味します。1 % のブロック率は PSTN トランクを使用する場合の標準値ですが、別のアプリケーションでは異なるサービス グレードが必要になることもあります。
- ブロックされたコール
-
ブロックされたコールとは、即時に対応されないコールのことです。発信者が別のルートまたはトランク グループに再ルーティングされた場合や、先延ばしにされキューに格納された場合、またはトーン(ビジー トーンなど)や応答メッセージで対応された場合、その発信者はブロックされます。ブロックされたコールの性質に応じて、特定のリソースのサイジングに適用されるモデルが決定されます。
- サービス レベル
-
X 秒以内に応答される、提供されたコール ボリューム(音声ゲートウェイおよびその他のソースから受信)の割合の業界標準用語。販売系のコンタクト センターの標準値では、全コールの 90 % が 10 秒未満で応答されます(一部のコールはキューに格納され、待機させられます)。サポート系のコンタクト センターでは、最繁時には全コールの 80 % に 30 秒以内に応答するなど、販売系とは異なるサービス レベルを目標にしていることもあります。サービス レベルの目標に基づき、必要なエージェント数、キューに入れられたコールの割合、コールがキューで費やす平均時間、および必要な PSTN トランクおよび VRU ポートが決定されます。
- キューイング
-
エージェントが他の発信者と通話中である場合や対応できない場合(コール後のラップアップ中)は、エージェントが応答可能になるまで後続の発信者をキューに格納しておく必要があります。希望するサービス レベルとエージェントのスタッフ配置により、キューに入れられたコールの割合とキューで費やされた平均時間が決まります。Contact Center Enterprise ソリューションは、VRU を使用して発信者をキューに配置して、アナウンスを再生します。最初は VRU がすべてのコールを処理します。コール処理を提供し、必要な情報を要求します。VRU は、発信者がエージェントと話す必要なくサービスを受けるセルフサービス アプリケーションを処理します。各シナリオで、それぞれの平均処理時間やコール負荷が異なるため、さまざまなアプリケーションを処理するために必要な IVR ポートの数は異なります。これらの各アプリケーションに必要なトランクまたはゲートウェイポートの数は、それに応じて異なります。
設計ツールとしての アーラン Calculator
テレフォニー システムとリソースのサイジングには、多くのトラフィック モデルを使用することができます。適切なモデルの選択は、3 つの主な要因に依存します。
-
トラフィック ソースの特性(有限または無限)
-
損失コールの処理方法(クリア、保留、遅延)
-
着信パターン (ランダム、スムース、ピーク時)
Contact Center Enterprise ソリューションでは、通常リソースのサイジングにアーラン-B およびアーラン-C トラフィック モデルを使用します。
アーラン計算機は、以下の質問に答える上で役立ちます。
-
必要なトランク数は?
-
必要なエージェント数は?
-
必要な VRU ポート数は?
アーラン計算機に入力が必要な数字は以下の通りです。
-
繁時呼数(BHCA)
-
各リソースの平均処理時間 (AHT)
-
サービス レベル (x 秒以内に応答されるコールの割合)
-
トランクおよび VRU ポートに必要なサービス グレード、またはブロック率
次のセクションでは、一般的な Erlang モデルを簡潔に説明します。また、アーラン モデルの入力と出力、および特定のリソースのサイジングに使用するモデルについても説明します。さまざまなコンタクト センターのサイジング ツールが利用できます。これらはすべて 2 つの基本トラフィック モデルのアーラン-B および アーラン-Cを使用します。
アーラン-B の使用
アーラン-B モデルは、PSTN トランク、ゲートウェイ ポート、または VRU ポートのサイジングに使用します。以下が前提となります。
-
コールはランダムに着信する。
-
すべてのトランクまたはポートが使用中の場合、新しいコールは損失するかブロックされ(ビジートーンを受信し)、キューには入りません。
アーラン B モデルの入力と出力は、以下の 3 つの要素で構成されています。要因のうち、いずれかの 2 つがある場合、モデルが 3 番目を計算します。
-
最繁時トラフィック(BHT)BHT とは、最繁時のコール数(BHCA)と平均処理時間(AHT)の積です。
-
サービス グレード
-
ポート (回線)
アーラン-C の使用
コールをエージェントに提示する前にキューに入れるコンタクト センターのエージェントのサイジングを決定するには、アーラン-C モデルを使用します。このモデルは以下を想定しています。
-
コールはランダムに着信する。
-
すべてのエージェントがビジーの場合、着信コールはキューに入れられ、ブロックされません。
このモデルに必要な入力パラメータは以下の通りです。
-
最繁時にエージェントが応答するコール数(BHCA)
-
平均通話時間および後処理時間
-
希望する遅延またはサービス レベル。これは指定した秒数内に応答したコールの割合として表されます。
このモデルの出力は、必要なエージェント数、エージェントが利用できない場合に遅延するコールの割合、および平均キュー時間を提供します。
Unified CCE 向けダイナミック設定の制限
場合によっては、別のリソースの使用を大幅に減らすことにより、あるリソースの標準制限は超過させることもできます。ソリューションに組み込む前に、計画する特定のトレードオフを一覧にします。以降のセクションでは、特定のリソースのバランスの仕方についてのガイダンスを説明します。
エージェントあたりのスキル グループとプレシジョン キューに対する動的制限
エージェントあたりのスキル グループとプレシジョン キューの数は、次の Unified CCE のサブコンポーネントに大きな影響を与えます。
-
Cisco Finesse サーバ
-
Agent PG
-
ルータ
-
Logger
(注) |
スキル グループとプレシジョン キューに対する共通の用語としてキューを使用しています。 |
ソリューションのパフォーマンスを維持するには、定期的に未使用のキューを削除します。
リファレンス設計では、各 PG のエージェントあたりの平均キュー数に対して標準の上限が設定されています。特定の PG において、一部のエージェントに他のエージェントよりも多くのキューを設定できます。PG のエージェント全体の平均値が制限内である限り、PG に最大数のアクティブ エージェントを設定できます。
たとえば、4000 エージェントのリファレンス設計で PG に 3 つのエージェント グループがある場合を想定してください。
-
グループ A には、5 つのキューを持つ 500 のエージェントが含まれています。
-
グループ B には、15 のキューを持つ 1000 のエージェントが含まれています。
-
グループ C には、25 のキューを持つ 500 のエージェントが含まれています。
これらの 3 つのグループを平均すると、エージェントあたり 15 キューとなるため、標準の上限で単一の PG にそれらすべてを設定できます。
また、各 PG とシステム全体のエージェント数を減らすと、標準の上限を超えることができます。
(注) |
標準制限については、構成制限の章の構成表を参照してください。 |
Cisco Finesse サーバでは、未使用キューの統計情報は表示されません。つまり、設定されているキューの総数よりも、アクティブなキューの数のほうが Cisco Finesse サーバのパフォーマンスに影響します。
Cisco Finesse デスクトップは、10 秒間隔でキュー(スキル グループ)の統計情報を更新します。Cisco Finesse デスクトップは、一定数のキュー統計情報フィールドをサポートしています。これらのフィールドは変更できません。
次の表は、エージェントあたりのキューの増加と、それに伴うソリューションでサポート可能なエージェント数の減少について概算を示しています。
エージェントあたりのキュー数 |
PG あたりの最大エージェント数 |
2000 エージェントのリファレンス設計の最高エージェント数 |
4000 エージェントのリファレンス設計の最大エージェント数1 |
12000 エージェントのリファレンス設計の最高エージェント数 |
24000 エージェントのリファレンス設計の最高エージェント数 |
---|---|---|---|---|---|
10 |
2000 |
2000 |
4000 |
12000 |
24000 |
15 |
2000 |
2000 |
4000 |
12000 |
16000 |
20 |
1500 |
1500 |
3000 |
9000 |
12000 |
30 |
1000 |
1000 |
2000 |
6,000 |
8000 |
40 |
750 |
750 |
1500 |
4500 |
6000 |
50 |
600 |
600 |
1200 |
3600 |
4800 |
Unified CCE は、スーパーバイザ チームのエージェント全体で最大 50 の一意のスキル グループをサポートします。これにはスーパーバイザ自身のスキル グループも含まれます。この数値を超えても、スーパーバイザによってモニタされるすべてのスキル グループは、引き続きスーパーバイザ デスクトップに表示されます。ただし、この数値を超えるとパフォーマンス上の問題が引き起こされる可能性があり、数値の超過はサポートされません。
(注) |
設定されたプレシジョン キューは、各 Agent PG に対してスキル グループを作成し、PG あたりのサポートされるスキル グループ数までカウントしていきます。スキル グループは、プレシジョン キューと同じメディア ルーティング ドメインに作成されます。 |
その他の動的サイジング要因
さまざまな要因によってソリューションのサーバ要件や容量が影響を受ける可能性があります。以下の項では、主要なサイジング変数とそれらがソリューションに影響を及ぼすしくみについて説明します。
最繁時呼数(BHCA)
BHCA が増加すると、すべてのソリューション コンポーネントの負荷が増加し、特に Unified CM、Unified CVP、Agent PG の負荷が増加します。エージェントに対する推定許容数は、1 時間にエージェントあたり最大 30 コールです。ソリューションでさらに高い BHCA が必要な場合は、Agent PG の最大エージェント数を削減します。
Unified CM のサイレント モニタリング
サイレント モニタリングされるコールごとに、PG と Unified CM の処理が増します。サイレント モニタリングされる各コールは、2 つのモニタされないエージェント コールに匹敵します。モニタリングされるコールの割合を受容できる余裕を PG に残してください。
スクリプトの複雑さ
Unified CCE スクリプトの複雑さと数が増加すると、コール ルータと VRU PG のプロセッサおよびメモリのオーバーヘッドが大幅に増加します。データベース クエリなどの機能を使用すると VRU スクリプトの複雑さが増加するので、CVP とルータに対する負荷も増加します。RunExternalScript の再生間での遅延時間も影響を及ぼします。
複雑なスクリプトおよびデータベース クエリのパフォーマンスは、特徴付けることが困難です。ラボで複雑なスクリプトをテストして、さまざまな BHCA でのデータベース クエリの応答時間を調べてください。音声ブラウザ、Unified CVP、PG、ルータのプロセッサやメモリに対する影響を受容できるように、サイジングを調整してください。
サードパーティのデータベースと Cisco Resource Manager の接続
外部デバイスとソフトウェアに対する Unified CCE ソリューション コンポーネントの接続を詳しく調べ、ソリューションに対する全体的な影響を確認してください。Contact Center Enterprise ソリューションは柔軟でカスタマイズ可能ですが、複雑でもあります。一般的に、コンタクト センターは、収益を創出する非常に重要なカスタマー応対業務です。ソリューションの設計に役立つように、適切なエクスペリエンスと認定を備えたシスコ パートナー(またはシスコ アドバンスド サービス)を関与させてください。
拡張コール コンテキスト(ECC)(Expanded Call Context (ECC))
ソリューションでの ECC 変数の使用は、PG、ルータ、Logger、ネットワーク帯域幅に影響を及ぼします。さまざまな方法で ECC 変数を設定して使用できます。容量への影響は ECC の設定に応じて異なります。
モバイル エージェントと PG エージェントの容量
モバイル エージェントは PG と Unified CM の負荷を増加させます。モバイル エージェントを使用すると、PG 上のエージェント容量が次のように縮小します。
-
1000(固定接続、2:1)
-
500(コールバイコール接続、4:1)
同じ PG 上にモバイル エージェントとその他のエージェントを混在させることができます。エージェントの各タイプの重みに注意してください。たとえば、PG 上に固定接続による 200 のアクティブなモバイル エージェントを計画していると仮定します。PG は他のエージェントを 1600 サポートできます。
Additional Agents Allowed = (2000 – (200 * 2)) = 1600 Agents
代わりに、コールバイコール接続による 200 のアクティブなモバイル エージェントを計画している場合、PG は他のエージェントを 1200 サポートできます。
Additional Agents Allowed = (2000 – (200 * 4)) = 1200 Agents
リファレンス設計ソリューションの設定制限
Unified CVP 向けサイジング
コンタクトセンターをサイジングする際、各状態にあるコールの数の最悪の場合のプロファイルを決定します。たとえば、最頻時に最もビジーなインスタントでコンタクト センターを確認する場合は、以下の状態にあるコール数を確認します。
-
セルフ サービス:VXML サーバを使用してアプリケーションを実行するコール。
-
キューとコレクト:エージェントのキューに入っているコール、またはプロンプトおよびコレクト タイプのセルフ サービス アプリケーションを実行するコール。
-
通話中:エージェント、またはサードパーティの TDM VRU アプリケーションに接続されるコール。
(注) |
これらのコールの状態の定義は、ポート ライセンシングの目的で使用される定義とは若干異なります。サイジング目的で、どのコールがどの状態にあるかをカウントする際、ASR および TTS 処理は無視できます。ただし、ASR および TTS 処理は、ライセンスの呼び出し状態のカウントに含まれます。 ソリューションは、通話状態のコールをエージェントに転送するために使用するポート数に応じてサイジングします。Unified CCE エージェントを使用する場合、これらのポートのライセンスは必要ありませんが、TDM エージェントには Call Director ライセンスが必要です。 |
通話中の状態のコールの場合、Unified CVP またはゲートウェイのリソースを使用しているコールのみをカウントします。転送で VoIP が使用されている場合、コールは音声ブラウザのポートと Unified CVP リソースを使用します。Unified CVP は呼び出しを監視し続け、後で取得して再配信できるようにします。Unified CVP はまた、TDMターゲットへの呼び出しを監視し続けます。これらのコールは、同じゲートウェイまたは異なるゲートウェイ(つまり、トール バイパス)で着信と発信の両方の TDM ポートを使用します。こういったコール タイプは両方とも通話中のコールとしてカウントされます。
ただし、転送で * 8 TNT、フックフラッシュ、2 B チャネル転送(TBCT)、または ICM NIC が使用される場合、ゲートウェイと Unified CVP は何らの役割を果たしません。両方のコンポーネントがリソースを再利用します。上記の通話はコール数にカウントされません。
キューイングまたはセルフサービスのために Unified CVP に戻されるコールを全体のコール カウントに含めます。たとえば、ウォーム転送では、Unified CVP はルーティング後の段階でエージェントをキューに入れます。コールは、Unified CVP の2つの個別のコール制御セッションに2つのポートを使用します。通常、転送は全体の通話量のごく一部であり、見落してしまう可能性があります。
全体的なスナップショット プロファイルに加え、最繁期間の CPS も考慮します。正確な最大到達率を特定するのが困難であるため、Contact Center Enterprise ソリューション全体でのこの情報が必要となります。この値は、統計的手段を使用して求めることもできます。
処理されるコールの数と最大コール着信レートに合わせて、Unified CVP サーバのサイジングを行います。
通話フロー |
サポートされる同時コール |
1 秒あたりのコール |
---|---|---|
SIP / TLS、SRTPを使用した包括的なコール フロー |
3000 |
15 |
SIP / TLS、SRTP、HTTPS を使用した包括的なコール フロー |
1500 |
15 |
包括的な SIP |
3000 |
15 |
HTTPS を使用した包括的な SIP |
1500 |
15 |
HTTPS を使用したスタンドアロン SIP |
1500 |
15 |
スタンドアロン VXML |
3000 |
15 |
Req ICM ラベルを使用したスタンドアロン VXML(Tomcat 上の VXML サーバ) |
3000 |
15 |
HTTPS の Req ICM ラベルを使用したスタンドアロン VXML(Tomcat 上の VXML サーバ) |
1500 |
15 |
(注) |
秒あたりのコールについては、ソリューション内のすべてのイングレス ゲートウェイから CVP コールサーバで受信される最大コールレートであり、WAAG が有効になっている最悪のシナリオを想定しています。 |
CVP コール サーバのサイジング
ソリューションには、以下の数式で与えられるより多くのコール サーバが必要です。
(Self Service) + (Queue and Collect) + (Talking) / Simultaneous Calls Supported, rounded up
OR
(Average call arrival rate) / Calls Per Second, rounded up.
また、クラスタ内のサブスクライバ間で Unified CM クラスタへのコールを分散します。サブスクライバあたり 2 CPS を超過しないでください。
詳細に関しては、Unified CVP のサイジング の コール フローの CVP サーバ コール レート の表を参照してください。
ログ ディレクトリのサイズ概算
次の式を使用して、コール サーバのディレクトリ ログ ファイルの 1 日当たりの概算領域(ギガバイト単位)を計算します。
3.5 GB * R
R は、毎秒のコール数です。
適切なサービスアビリティのために、5 ~ 7 日分のログ メッセージを保持するのに十分な領域を確保します。
CVP VXML サーバのサイジング
単一の VXML サーバは「Unified CVP のサイジング」セクションの「コール フローの CVP サーバ コール レート」の表のとおりのコール数を処理することができます。VXML Server を使用している場合、次の公式に従ってサイジングします。
Calls / Simultaneous Calls Supported, rounded up
コール数 とは、時間内にスナップショットで VXML サーバ セルフサービス アプリケーションに存在するコール数を示します。
(注) |
UCS パフォーマンスの値については、 Cisco Unified Customer Voice Portal の仮想化 ページを参照してください。 |
適切な Cisco IOS リリースを使用すると、Unified CVP を設定して、VXML サーバおよび Unified CVP IVRサービスで HTTPS を使用することができます。
(注) |
メインラインの Cisco IOS はサポートされていません。 |
CVP VXMLサーバのパフォーマンスは、VXMLアプリケーションの複雑性によって異なります。
CUSP パフォーマンス ベンチマーク
ソリューションで CUSP を使用する場合、以下の点に注意します。
-
CUSP 基準テストはプロキシ上で隔離して行われています。上記テストのキャパシティ数は、450 TCP または 500 UDP トランザクション / 秒です。この数値は、許容できる最もストレスのかかる状態であるとみなします。
-
プロキシ サーバからの CVP コールには、平均で 4 つの個別の SIP コールが必要です。発信者のインバウンド レッグ、VXML アウトバウンド レッグ、着信音アウトバウンド レッグ、およびエージェント アウトバウンド レッグです。
-
CVP キューイングとのコンサルテーションが発生すると、セッションにはさらに 4 つの SIP トランザクションが発生し、コール数が事実上 2 倍になります。
Contact Center Enterprise ソリューション向けサイジング ゲートウェイ
Cisco ゲートウェイのコールのキャパシティは、イングレスのみを行うか、VXML のみを行うか、この 2 つの組み合わせを行うかによって異なります。音声ブラウザの容量も、ASR / TTSサービスや VXML アプリケーションの種類などの要因によって変化します。たとえば、JavaScript を多用するアプリケーションではコール容量が少なくなります。
通常、イングレスを実行するゲートウェイのサイズは、TDM ケーブル接続ポイントの最大数に制限することができます。
音声ゲートウェイをサイジングする前に、Unified CCE Resource Calculator を使用して、ソリューション全体をサポートするために必要な最大トランク数(DS0)と、VXML VR ポート数を判断してください。
次の表に、各 Cisco IOS バージョンのサイジング情報を示します。サイジング情報は次の要素に基づきます。
-
合計 CPU 使用率が 75% を超えることはありません。
-
サイジングは、ゲートウェイ上の最大同時 VXML セッション数および VoIP コール数を表します。
-
サイジングは、Unified CVP VXML のマニュアルに基づいています。
-
サイジングには、アクティブな会議とアクティブな転送が含まれます。
-
「VXML のみ」欄のサイジングには、ゲートウェイで実行される基本的なルーティングおよび IP 接続のみが含まれます。Fax など、コンタクト センター外トラフィックを必要とするアプリケーションを追加で実行する場合は、そのトラフィックも展開の容量に含める必要があります。「VXML + PTSN」欄に示される VXML セッションと音声コールの数は、同じゲートウェイ上で同時にサポートされる数です。
-
サイジングは、Cisco コール サーバまたは Cisco Unified CVP VXMLサーバを使用することを前提としています。
-
各ゲートウェイは、通常の動作時に、冗長ペアと負荷を共有するよう設定します。通常の動作では、各ゲートウェイは、容量の半分近くのロードを処理します。フェールオーバー シナリオでは、各ゲートウェイは、サポートされている最大負荷で動作します。
-
各ポートは ASR/TTS を含む TDM および VXML 機能を提供します。
Cisco IOS リリース 15.1.4.M7 以降の VXML ゲートウェイ CPU 容量 |
|||||
---|---|---|---|---|---|
プラットフォーム |
VXML のみ |
VXML + PSTN |
メモリ |
||
DTMF |
ASR |
DTMF |
ASR |
推奨 |
|
2901 |
12 |
8 |
9 |
6 |
2 GB |
2911 |
60 |
40 |
47 |
31 |
2 GB |
2921 |
90 |
60 |
71 |
48 |
2 GB |
2951 |
120 |
80 |
95 |
64 |
2 GB |
3925 |
240 |
160 |
190 |
127 |
2 GB |
3945 |
340 |
228 |
270 |
180 |
2 GB |
3925E |
475 |
450 |
380 |
375 |
2 GB |
3945E |
580 |
550 |
460 |
450 |
2 GB |
ISO 15.1.4.M7、G.711、基本コール、Ethernet 出力、CPU NTE 75%()に基づく |
(注) |
単一の組み合わせゲートウェイが、VXML セッションおよび VoIP コールの同時発生数を上回ることはできません。 |
Cisco Voice Gateway プラットフォーム |
専用 VXML ゲートウェイ |
音声ゲートウェイおよび VXML |
|||
---|---|---|---|---|---|
VXML および DTMF |
VoiceXML および ASR/TTS |
VXML および DTMF |
VoiceXML および ASR/TTS |
推奨されるメモリ |
|
AS5350XM |
105 |
85 |
110 |
70 |
512 MB(デフォルト) |
AS5400XM |
105 |
85 |
110 |
70 |
512 MB(デフォルト) |
Cisco Voice Gateway プラットフォーム |
専用 VXML ゲートウェイ |
音声ゲートウェイおよび VXML |
|||
---|---|---|---|---|---|
VXML および DTMF |
VoiceXML および ASR/TTS |
VXML および DTMF |
VoiceXML および ASR/TTS |
推奨されるメモリ |
|
3945E |
510 |
342 |
408 |
270 |
2 GB |
AS5350XM |
155 |
120 |
138 |
95 |
512 MB(デフォルト) |
AS5400XM |
155 |
120 |
138 |
95 |
512 MB(デフォルト) |
(注) |
上記の表 に示されるパフォーマンスの数値は、HTTPS を使用する Cisco 音声ゲートウェイの記載モデルのみに該当する数値です。表 11 に示していないルータ モデルのパフォーマンスの数値を見積もる場合は、3945E ルータの HTTPS パフォーマンス数値を使用してください。 |
着呼率が表に示す容量を超えないようにするには、https://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager/products-implementation-design-guides-list.html の 『Cisco Collaboration System Solution Reference Network Designs』 に記載の「コンタクト センター トラフィックのゲートウェイのサイジング」を参照してください。
CPU 使用率
すべてのゲートウェイで、合計 CPU 使用率が平均で 75 パーセント未満であることを確認してください。次の要因が CPU 使用率に影響します。
-
コール数/秒(CPS)
-
最大同時コール
-
最大同時 VXML セッション数
-
JavaScript を多用するアプリケーション
メモリの考慮事項
注文する DRAM とフラッシュ メモリの量を検討してください。マシンにデフォルトで付属している容量は、ほとんどの目的に十分です。ただし、アプリケーションで以下が必要な場合は、フラッシュ メモリを拡張するために DRAM の量を増やすことを検討してください。
-
多数の個別の .wav ファイル(複雑なセルフサービス アプリケーションと同様)
-
異常に大きな .wav ファイル(拡張ボイス メッセージまたは音楽ファイルの場合など)
(注) |
現在の Cisco IOS リリースでは、HTTP キャッシュを 100 MB までしか拡張できません。 |
サードパーティの VXML アプリケーションに関する考慮事項
Cisco 以外の VXML アプリケーションを使用する場合は、展開において CPU 使用率の要件に従う必要があります。外部 VXML アプリケーションを実行している場合は、完全負荷状態の Cisco ゲートウェイで十分なメモリ量が使用可能であることを確認してください。
パフォーマンスと可用性の情報については、該当アプリケーションのプロバイダーに問い合わせてください。Cisco は、Cisco 環境で相互運用する場合、サードパーティの VXML アプリケーションのパフォーマンス、安定性、または機能の能力に関して、いかなる請求も保証も行いません。
CUBE および仮想 CUBE に関する考慮事項
Cisco UBE の物理あるいは仮想サイジングの詳細については、https://www.cisco.com/c/en/us/support/unified-communications/unified-border-element/products-installation-and-configuration-guides-list.htmlの Cisco Unified Border Element コンフィギュレーション ガイド を参照してください。
CUBE のセッション キャパシティ情報については、https://www.cisco.com/c/en/us/products/unified-communications/unified-border-element/datasheet-listing.htmlの Cisco Unified Border Element データ シート を参照してください。
(注) |
CVP の包括的なコール フローは、Unified CM を使用した VoIP コール フローで、コール レッグ毎に標準の 7 件を超えるメッセージを使用します。このため、Contact Center Enterprise ソリューションの CUBE セッションのサイズは以下の通りです。
|
重要 |
トランスコーダや MTP リソースなどの複数のサービスを CUBE でアクティブ化する際の CUBE のサイズ設定は、さらに複雑になります。Cisco アカウント チームに相談して、CUBE チームにお問合わせください。複雑な CUBE 展開の適切なサイジングをサポートします。 |
基本ビデオサービスのサイジング
Contact Center Enterprise ソリューションにビデオ対応エージェントを含めることができます。
包括的なコール フローで、ビデオ コールと従来の音声コールの両方に同じ Unified CVP コール サーバを使用できます。
基本的なビデオ サービスは、包括的なコール フローを使用します。コール サーバ、VXML サーバ、および IOS VXML ゲートウェイが必要です。これらのコンポーネントのサイズは、音声コールの場合と同じ方法で決定します。
Cisco Unified Videoconferencing ハードウェア、Radvision IVP、および Radvision iContact は、基本ビデオサービスには必要ありません。
(注) |
Video コールは Cisco VVB ではサポートされません。 |
CVP Reporting Server のサイジング
CVP Reporting Server のサイジングには多数の変数が関係します。それぞれの VXML アプリケーションは、レポーティング データの量に影響する異なる特性を備えています。こうした特性の一部を次に示します。
-
アプリケーションの要素のタイプ
-
必要なデータの粒度
-
アプリケーション内のコール フロー
-
コールの長さ
-
コールの数
CVP Reporting Server をサイジングするには、最初に、VXML アプリケーションで生成されるレポート データの量を概算します。
使用しているアプリケーションで生成されるレポーティング メッセージの数を確認した後、各 VXML アプリケーションに対して次の手順を実行します。
-
アプリケーションが受信する CPS を概算します。
-
アプリケーションで生成されるレポーティング メッセージの数を見積もります。
次の等式を使って、VXML アプリケーションで毎秒生成されるレポート メッセージの数を判断します。
A# = %VXML * CPS * MSG
ここで、
-
A# は、アプリケーションで生成される 1 秒あたりのレポーティング メッセージの推定数です。
-
CPS は、1 秒あたりのコールの数です。
-
%VXML は、VXML アプリケーションを使用するコールの割合です。
-
MSG は、このアプリケーションが生成するレポート メッセージの数です。
ソリューションの各 VXML アプリケーションの値を合計して、ソリューションに対する 1 秒あたりのレポート メッセージの推定数を割り出します。
各 CVP Reporting Server は、1 秒あたり 420 のメッセージを処理できます。ソリューションで複数の CVP Reporting Server が必要な場合は、VXML アプリケーションを分割して、特定の Reporting Server を使用するようにします。
複数の CVP レポート サーバを含むソリューション
複数の CVP レポート サーバを必要とするソリューションでは、展開を垂直方向に分割します。
レポート データの負荷を分散するために垂直分割する場合は、以下の要件とガイドラインを考慮します。
-
各コール サーバと VXML サーバを単一の CVP レポート サーバのみに関連付けます。
-
複数の Informix データベースにまたがったレポートを作成することはできない。
-
コール処理メッセージとアプリケーション メッセージを合計した場合に、単一のレポート サーバがサポートするよりも多くのメッセージを生成する複数のアプリケーションを分割します。
-
VXML をフィルタすることができます。不要なデータをフィルタで除外すると、より多くのメッセージ量をサポートする使い勝手の良いデータ リポジトリが作成されます。
-
ダイヤル プランやその他の使用可能な方法を設定して、着信コールを適切なコール サーバおよび VXML サーバに転送します。
要件の詳細については、http://www.cisco.com/c/en/us/support/customer-collaboration/unified-customer-voice-portal/products-installation-and-configuration-guides-list.htmlの 『Cisco Unified Customer Voice Portal レポーティング ガイド』 を参照してください。
複数のデータベースからデータを組み合わせる場合は、以下のオプションを使用することができます。
-
レポート データをスプレッドシートなどの別の形式にエクスポートして、データベース外のデータを結合します。
-
レポーティング データを CSV ファイルにエクスポートし、それをユーザ指定のデータベースにインポートします。
-
ユーザ指定のデータ ウェアハウスにデータを抽出し、そのデータに対するレポートを実行します。
CVP Reporting Server のメッセージの詳細
次の表は、さまざまな要素またはアクティビティによって生成されるレポート メッセージの数を示しています。
要素またはアクティビティ |
レポーティング メッセージの数(フィルタリングなし) |
---|---|
開始 |
2 |
終了(End) |
2 |
Subflow Call |
2 |
Subflow Start |
2 |
Subflow Return |
2 |
Throw |
2 |
アラート(Alert) |
2 |
Subdialog_start |
2 |
Subdialog_return |
2 |
Hotlink |
2 |
HotEvent |
2 |
Transfer w/o Audio |
2 |
Currency w/o Audio |
2 |
フラグ(Flag) |
2 |
Action |
2 |
Decision |
2 |
Application Transfer |
2 |
VXML Error |
2 |
CallICMInfo(コールごと) |
2 |
Session Variable(変更ごと) |
2 |
Custom Log(アイテムごと) |
2 |
Play(音声ファイルまたは TTS) |
2 |
LeaveQueue |
2 |
Callback_Disconnect_Caller |
3 |
Callback_Add |
4 |
Callback_Get_Status |
4 |
Callback_Set_Queue_Defaults |
4 |
Callback_Update_Status |
4 |
Callback_Enter_Queue |
5 |
Callback_Reconnect |
5 |
Get Input(DTMF) |
5 |
Callback_Validate |
6 |
Get Input(ASR) |
9 |
フォーム(Form) |
10 |
Digit_with_confirm |
20 |
Currency_with_confirm |
20 |
ReqICMLabel |
30 |
(注) |
アプリケーションごとにこれらの要素が必要です。これらはフィルタリングできません。 |
Unified CM クラスタのサイジング
Unified CM クラスタは、統合 IP ネットワーク インフラストラクチャ全体にコール処理を分散するメカニズムを提供します。また、クラスタは冗長性を促進し、機能の透過性とスケーラビリティを提供します。
Unified CM クラスタのビューの詳細については、http://www.cisco.com/go/ucsrndの 『Cisco Collaboration System Solution Reference Network Designs』 を参照してください。
クラスタ サイジングの概念
ソリューションの Unified CM クラスタのサイズを決定する前に、以下の設計タスクを実行します。
-
さまざまな種類のコール フローを決定します。
-
必要な展開モデル (単一サイト、集中型、分散型、WAN 経由のクラスタリング、または集中型または分散型展開内のリモート ブランチ) を決定します。
-
使用するプロトコルを決定します。
-
冗長性の要件を決定します。
-
クラスタを Unified CCE 展開と共有する、Cisco Unified Communications の他のすべての顧客要件を決定します。たとえば、Cisco Unified IP フォン、Unified CCE の一部ではないアプリケーション、ルート パターンなどを検討します。
上記タスクを完了したら、必要なクラスタの正確なサイジングを開始することができます。クラスタのサイジングには多くの要因が影響を与えます。以下の一覧では、これらの要因の一部について説明しています。
-
オフィスの電話機の数と電話毎の最繁時通話試行(BHCA)レート
-
着信エージェント電話の数と電話毎の BHCA レート
-
上記 VoIP エンドポイントの CTI ポート数および BHCA レート。(Unified CVP をコール処理、セルフサービス、およびキューイングに使用する場合、上記要因が適用されない場合があります。)
-
上記 VoIP エンドポイントの音声ゲートウェイのポート数および BHCA レート。
-
発信エージェントの電話機の数、発信ダイヤル モード、および電話機毎の BHCA レート
-
アウトバウンド ダイヤラ ポートの数、アウトバウンド キャンペーンの VRU ポート数、および両方のポート毎の BHCA レート
-
モバイル エージェントの数とモバイル エージェントあたりの BHCA レート
-
上記 VoIP エンドポイントへのボイスメールのポート数および BHCA レート。
-
VoIP エンドポイントで使用されるシグナリング プロトコル
-
エージェントのコール転送と会議の割合(%)
-
ダイヤル番号、回線、パーティション、コーリング サーチ スペース、ロケーション、地域、ルート パターン、変換、ルート グループ、ハント グループ、ピックアップ グループ、ルート一覧数など、ダイヤル プランのサイズと複雑度
-
トランス コーディング、会議、暗号化などの機能に必要なメディア リソースの量
-
CTI Manager、E-911、保留音楽などの共存アプリケーションおよびサービス
-
Unified CM リリース (リリースによりサイジングは異なります)
-
Unified CM OVA のタイプ
他の要因がクラスタのサイジングに影響を与える可能性があるとはいえ、上記がリソース消費の観点から最も重要な要因となります。
通常、これらの各要因のリソース消費(CPU、メモリ、および I / O)を推定して、Unified CM クラスタのサイジングを行います。次に、リソース要件を満たす VM を選択します。クラスタを正確にサイジングする前に、上記要因に関する情報を収集します。
クラスタのガイドライン
すべての Unified CM クラスタに以下のガイドラインが適用されます。
-
すべてのプライマリおよびバックアップ サブスクライバは、同じOVFテンプレートを使用する必要があります。クラスタ内のすべてのサブスクライバは、同じ Unified CM ソフトウェア リリースとサービス パックを実行する必要があります。
-
クラスタ内では、Cisco Call Manager サービスで最大 8 つのサブスクライバ(4 つのプライマリ サブスクライバおよび 4 つのバックアップ サブスクライバ)を有効にすることができます。TFTP、パブリッシャ、保留音などの専用機能に、より多くの VM を使用することができます。
-
4000 エージェントのリファレンス設計では、単一の Unified CM クラスタで約 4,000 人のエージェントをサポートすることができます。12,000 エージェントのリファレンス設計では、4 つのプライマリおよび 4 つのバックアップ サブスクライバを持つ Unified CM クラスタで約 8,000 人のエージェントをサポートすることができます。上記の制限は、BHCA コールの負荷および設定されたすべてのデバイスが、1 対 1 の冗長性を備えた 8 つのコール処理サブスクライバに均等に分散されることを前提としています。これらのキャパシティは、特定の展開に応じて異なります。ソリューションのサイジングを Cisco Unified Communications Manager キャパシティ ツールで行います。
サブスクライバは最大 1,000 人のエージェントをサポートすることができます。フェールオーバー シナリオでは、プライマリ サブスクライバは最大 2,000 人のエージェントをサポートします。
(注)
4000 エージェント リファレンス設計では、4 つのサブスクライバ(2 つのプライマリおよび 2 つのバックアップ)を持つクラスタが最大負荷をサポートできます。さらに多くのサブスクライバのクラスタを作成する場合、クラスタの最大エージェント数の 4,000 人を超過させないようにします。
適切な数の CTI リソースのコンタクト センター ソリューションをサポートするようにクラスタのサイジングを行う場合は、以下を考慮します。
-
ログインしていないエージェントの設定済電話数
-
通話録音、アテンダント コンソール、PC クライアントなど、デバイスをリモートで制御するアプリケーション
-
CTI リソースを消費するその他のサードパーティ アプリケーション
たとえば、Unified CMは、複数の回線、コンタクト センター、および録音が同時に使用される場合など、複数の同時 CTI リソースをサポートすることができます。これらのCTIリソースは、『Cisco Collaboration System Solution Reference Network Designs』で説明されている通りの CTI ルールに従います。
-
デバイス(電話、保留音、ルート ポイント、ゲートウェイ ポート、CTI ポート、JTAPI ユーザ、および CTI Manager を含む)は、パブリッシャに常駐させたり、登録してはなりません。パブリッシャに登録されているデバイスがある場合、Unified CM の管理作業は、コール処理と CTI Manager アクティビティに影響を与えます。
-
実稼働環境では、パブリッシャをフェールオーバーまたはバックアップのコール処理サブスクライバとして使用しないでください。逸脱する場合は、Cisco Bid Assurance による個別のレビューが必要となります。
-
150 台以上のエージェント電話を使用する展開では、少なくとも 2 つのサブスクライバ、TFTPおよびパブリッシャの組み合わせが必要です。ロード バランシングは、パブリッシャがバックアップ コール処理サブスクライバである場合には実装できません。
-
構成をサポートするために複数のプライマリ サブスクライバが必要な場合は、すべてのエージェントをサブスクライバ ノード間に均等に分散します。この構成では、BHCA レートがすべてのエージェントで均一であると想定しています。
-
同様に、すべてのゲートウェイ ポートと CTI ポートをクラスタ ノード間で均等に分散します。
-
一部の展開では、複数の Unified CCE JTAPI ユーザ(CTI Manager)と複数のプライマリ サブスクライバが必要です。これらの展開では、可能であれば、同じ VM 上で、Unified CCE ルート ポイントやエージェント デバイスなど、同じ Unified CCE JTAPI ユーザ(サードパーティ アプリケーション プロバイダー)によって監視されるすべてのデバイスをグループ化して構成します。
-
CTI Manager は呼処理サブスクライバでのみ有効にします。これにより、クラスタ内で最大 8 つの CTI Manager が利用できます。最大の復元力、パフォーマンス、および冗長性を提供するには、クラスタ内のさまざまな CTI Manager 全体で CTI アプリケーションの負荷を分散します。CTI Manager に関する考慮事項の詳細は、 http://www.cisco.com/go/ucsrndの 『Cisco Collaboration System Solution Reference Network Designs』 を参照してください。
-
Unified CCE と一般的なオフィスの IP フォンが混在するクラスタがある場合は、可能ならば、各タイプを個別の VM でグループ化および構成します(単体サブスクライバのみが必要な場合を除く)。たとえば、すべての Unified CCE エージェントおよびそれらに関連付けられたデバイスとリソースを、1 つ以上の Unified CM サーバ上に配置します。その後、クラスタのキャパシティが許す限り、すべての一般的なオフィスの IP フォンおよびそれらに関連付けられたデバイス(ゲートウェイ ポートなど)は他の Unified CM サーバ上に配置します。Cisco Unified Communications Manager キャパシティ ツールを使用する場合、各プライマリ Unified CM サーバの特定のデバイス設定でツールを個別に実行します。このツールは、クラスタ内のすべてのデバイスのバランスが均等であると想定しているため、複数回実行する必要があります。Unified CCE では、1:1 の冗長性スキームを使用する必要があることに注意してください。
-
可能な限り、ハードウェア ベースの会議リソースを使用します。ハードウェアの会議リソースは、より費用対効果の高いソリューションを提供し、クラスタ内のスケーラビリティを向上させます。
-
Unified CCE 周辺機器ゲートウェイ (PG) JTAPI ユーザのすべての CTI ルート ポイントを、その Unified CCE PG と通信する CTI Manager インスタンスを実行するサブスクライバ ノードに登録します。
-
Cisco Unified Communications Manager キャパシティ ツールでは、現在、各 VM に対する CTI Manager の影響を個別に測定しません。ただし、CTI Manager はそのプロセスを実行しているサブスクライバに追加の負荷をかけます。このツールは、これらのサブスクライバに基づき、リソースの消費を報告します。その他の Unified CM サブスクライバの実際のリソース消費は、わずかに少ない可能性があります。
-
コンタクトセンター エージェントが使用しない場合でも、Unified CCE PG JTAPI ユーザのすべてのデバイスは、エージェント デバイスとしてカウントします。エージェントが電話を使用していない場合でも、PG にはその電話のすべてのデバイス状態の変更が通知されます。エージェントがデバイスを定期的に使用しない場合、クラスタの拡張性を向上させるために、デバイスは Unified CCE PG JTAPI ユーザーに関連付けないでください。
-
トレーシング レベル:Cisco Unified CM の CPU リソース消費は、有効なトレース レベルによって変化します。Unified CM でトレース レベルをデフォルトからフルに変更すると、高負荷時に CPU 消費が大幅に増加する可能性があります。Cisco Technical Assistance Center は、トレース レベルのデフォルトからトレースなしへの変更をサポートしていません。
-
通常の環境では、同一 LAN または MAN 内にクラスタのすべてのサブスクライバを配置します。クラスタのすべてのメンバーを同一の VLAN またはスイッチに配置することは推奨されません。
-
クラスタが IP WAN にまたがる場合、このガイドおよび 『Cisco Collaboration System Solution Reference Network Designs』の WAN を介したクラスタリングに関するセクションの特定のガイドラインに従ってください。
サポートされるリリースの最新情報については、使用するソリューションの最新バージョンの 互換性マトリクスを参照してください。
Unified CM クラスタのガイドラインの詳細については、http://www.cisco.com/go/ucsrndの 『Cisco Collaboration System Solution Reference Network Designs』 を参照してください。
コンポーネントおよび機能の拡張性に関する影響
一部のオプションのコンポーネントと機能は、ソリューションのスケーラビリティとキャパシティに影響を与えます。この表では、いくつかの影響を一覧にしています。
コンポーネントまたは機能 |
Impact |
---|---|
IPSec |
IPsec を有効化した場合:
|
モバイル エージェント |
Unified CCE はモバイル エージェントの電話機を直接制御しません。コールバイコールと固定接続の2つの配信モードでは、リソースの使用方法が異なります。 |
Cisco アウトバウンド オプション |
アウトバウンド リソースは、キャンペーンのヒット レート、放棄制限、および通話時間に基づいて変化します。すぐに求められ、正確性には欠ける推定値では、アウトバウンド エージェント毎に 2 つのポートが必要というものです。技術的には、アウトバウンド コールに割り当てられた PG 毎に 2,000 人のエージェントを持つことができますが、ダイヤラはおそらくすべてのエージェントが完全に従事した状態を維持することはできません。サイジング ツールを使用して、キャンペーンに必要なアウトバウンド リソースを決定します。 |
エージェントのグリーティング |
エージェント グリーティング機能は、ルータ、ロガー、および Unified CM に影響します。 ルータおよびロガーでは、この機能によりルート要求が増加します。これにより、最大通話レートが約 3 分の 1 に減少します。 |
拡張コール コンテキスト(ECC) |
拡張コール コンテキスト (ECC) の使用の増加は、Unified CCE の重要なコンポーネントのパフォーマンスおよび拡張性に影響を与えます。キャパシティへの影響は、ECC 構成に基づいて異なるため、ケースバイケースの専門的なガイダンスが必要となります。 |
レポート向けリソース要件
クライアント マシンでは 10 以上の同時レポートを実行しないでください。これは、クライアント マシンの Unified Intelligence Center ユーザ インターフェイス、パーマリンク、およびダッシュボードで実行されるレポートの総合的な制限です。
ただし、各ノードの最大レポート ユーザ 200 人に対して 10 件の同時レポートを実行することはできません。キャパシティ テストでは、200人のレポート ユーザはそれぞれ以下のレポートを実行できることが示されています。
-
10 行 100 列の 2 つのライブ データ レポート
-
10 行 100 行の 2 つのリアルタイム レポート(15秒毎の更新)
-
10 行 8,000 行の 2 つの履歴レポート(30分毎の更新)
ノード上のレポート ユーザが上記より少ない場合、さらに多くのレポートを実行することができます。しかし、クライアント マシンは、10 件のレポートの制限を超えることはできません。
(注) |
インターネット スクリプト エディタまたは管理クライアントを使用する各スクリプト エディタ監視ユーザは、1 人のレポート ユーザに相当します。 |
Cisco Virtualized Voice Browser
Cisco VVB のコール キャパシティは、ASR または TTS アクティビティのコール サポートと VXML アプリケーションのタイプに基づいています。たとえば、JavaScript を多用するアプリケーションでは、コール キャパシティが減少し、HTTPS を使用する VVB は HTTP を使用する場合よりもコール キャパシティが減少します。
全体の CPU 使用率が平均で 65% 未満であることを確認してください。次の要因が CPU 使用率に影響します。
-
コール数/秒(CPS)
-
最大同時 VXML セッション数
-
VXML アプリケーションの複雑性
音声ゲートウェイをサイジングする前に、Unified CCE Resource Calculator を使用して、ソリューション全体をサポートするために必要な最大トランク数(DS0)と、VXML VR ポート数を判断します。
ほとんどすべての Unified CVP 展開モデルについて、サイジングは以下の要因に基づいています。
-
最大同時 VXML セッション数
-
Cisco VVB が処理する CPS
(注) |
ASR および TTS 列にリストされているパフォーマンスの数値は、MRCPv1 および v2 にのみ適用されます。 |
システムの仕様 |
CPS |
DTMF (非セキュア) |
TTS / ASR (非セキュア) |
DTMF / TTS / ASR (セキュア) |
---|---|---|---|---|
中規模 OVA (4 CPU, 8-GB RAM) |
20 |
600 |
480 |
480 |
小規模 OVA (4 CPU, 6-GB RAM) |
20 |
480 |
380 |
380 |
KVM [4451 (2 CPU - Gladen), 6-GB RAM] |
6 |
120 |
96 |
96 |
KVM [4431 (6 CPU - Gladen), 6-GB RAM] |
3 |
80 |
70 |
70 |
KVM [4351 (6 CPU - Rangley), 6-GB RAM] |
3 |
60 |
50 |
50 |
KVM [4331 (6 CPU - Rangley), 6-GB RAM] |
2 |
40 |
30 |
30 |
(注) |
|
Cisco Finesse のサイジング
Cisco Finesse では、Cisco Finesse サーバ ペア毎に、HTTP または HTTPS を介して最大 1,800 人のエージェントと 200 人のスーパーバイザ(合計 2,000 人のユーザ)をサポートします。
輻輳制御のサイジング
輻輳制御は、高い通話率に起因する過負荷状態からルータ保護を行います。極端な過負荷が発生した場合、輻輳制御はシステムを定格キャパシティ付近で実行を続行します。
輻輳制御は過負荷状態時に、すべての通話に対するサービスの大幅な低下をもたらさずに、少ない割合のコールで満足のいくサービスを提供します。この機能は、コールのエントリ ポイントでコールを拒否することにより、システムをキャパシティ内に維持します。キャパシティ調整を行うことで、ルーティングされるコールがタイムアウトなしで許容可能なサービスを受けることが保証されます。
輻輳制御には、「呼び出し」には、ユニバーサル キュー API と音声呼び出しを使用するサードパーティのマルチチャネル アプリケーションからの非音声タスクが含まれます。輻輳制御は、上記呼び出しとタスクを同様に処理します。着信コールおよびタスクを監視および調整して、コールまたはタスクがシステムに入った後にドロップが発生しないようにします。つまり、転送と RONA は輻輳制御にカウントされ、スロットリングや拒否が発生しません。
別の例外として、音声通話でのマルチタスクの過程で、E メールなどのタスクを選択することがあります。輻輳制御は、上記のピック タスク要求を拒否しません。
(注) |
タスクが Unified CCE キューで待機中の場合を除き、システムの輻輳状態は、プル タスク要求は拒否されます。輻輳中であっても、Unified CCE システムの混雑解消に役立つため、Unified CCE キューからのプル タスク要求は許可されます。 |
(注) |
企業向けチャットおよび E メールでは、転送されるメール タスクは新しいタスクと見なされ、調整の対象となります。 |
ルータで測定される CPS は、輻輳を識別するためのトリガです。展開タイプにより、ソリューションでサポートされる CPS キャパシティが設定されます。ルータは、すべてのルーティング クライアントからの新しい着信呼び出し要求を測定して、可変加重平均を計算します。平均 CPS がしきい値を超えると、輻輳レベルが変化し、削減率が増加します。輻輳制御アルゴリズムには、3 段階の輻輳レベルがあります。そのレベルの値により、着信コールを拒否または処理します。システムは、輻輳レベルの変化をルーティング クライアントに通知します。
Contact Director リファレンス設計では、輻輳制御は各インスタンスで測定されるコール レートに基づいています。Contact Director は、各ターゲットの輻輳レベルに関する情報を受け取ります。ルーティングの決定に必要な削減を適用します。また、INCRP ルーティング クライアントは、コールをターゲット インスタンスに送信する前に輻輳制御を適用します。
導入タイプの説明
システムをアップグレードまたはインストールした後、システムを有効な展開タイプに設定します。次の表に、サポートされる展開タイプと、有効な展開タイプを選択するためのガイドラインを示します。
この表に記載の要件の詳細については、http://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/uc_system/virtualization/cisco-collaboration-virtualization.htmlの Cisco Collaboration の仮想化 サイトの使用するソリューション ページを参照してください。
展開タイプ コード |
Deployment Name |
選択に関するガイドライン |
||
---|---|---|---|---|
0 |
未指定(Not Specified) |
これはシステムのデフォルトの展開タイプです。このオプションは選択できません。 新規インストールまたはアップグレード後のデフォルト設定です。 |
||
1 |
NAM (廃止) |
Contact Director 展開の NAM インスタンスにこの展開タイプを選択します。システムは、指定された要件を満たす異なる VM にインストールされたルータおよびロガーを使用して分散展開しなければなりません。この展開タイプではエージェントは許可されません。エージェントが設定済みでログインしている場合、キャパシティは Unified CCE 12000 エージェント ソリューションの最大容量に調整されます。 |
||
2 |
Contact Director |
Unified CVP またはサードパーティ VRU システムを使用するセルフサービス コール フロー専用の ICM インスタンスに対して、この展開タイプを選択します。システムは、指定された要件を満たす異なる VM にインストールされたルータおよびロガーを使用して分散展開しなければなりません。この展開タイプではエージェントは許可されません。エージェントが設定済みでログインしている場合、キャパシティは Enterprise Contact Center (Unified CCE 12000 エージェントのルータ / ロガー)の最大容量に調整されます。 |
||
3 |
NAM Rogger (廃止) |
Contact Director 展開の NAM インスタンスにこの展開タイプを選択します。単一の VM に共存するルータおよびロガーは、指定された要件を満たしています。この展開タイプではエージェントは許可されません。エージェントが設定済みでログインしている場合、キャパシティは Enterprise Contact Center (Unified CCE 12000 エージェントのルータ / ロガー)の最大容量に調整されます。 |
||
4 |
ICM Router/Logger |
従来の TDM ACD PG および CCE PG の両方が展開されている ICM エンタープライズ システムのタイプには、この展開を選択します。システムは、指定された要件を満たす異なる VM にインストールされたルータおよびロガーを使用して分散展開しなければなりません。 |
||
5 |
UCCE 8000 エージェント ルータ / ロガー |
CCE PG のみが展開されている CCE エンタープライズ システムのタイプには、この展開を選択します。システムは、8000 CCE エージェントの指定された要件を満たす異なる VM にインストールされたルータおよびロガーを使用して分散展開しなければなりません。 |
||
6 |
UCCE 12000 エージェント ルータ / ロガー |
CCE PG のみが展開されている CCE エンタープライズ システムのタイプには、この展開を選択します。システムは、12000 CCE エージェントの指定された要件を満たす異なる VM にインストールされたルータおよびロガーを使用して分散展開しなければなりません。 |
||
7 |
Packaged CCE: 2000 エージェント |
実稼働環境での Packaged CCE 展開の場合、この展開タイプを選択します。 |
||
8 |
ICM Rogger |
従来の TDM ACD PG および CCE PG の両方が展開されている ICM エンタープライズ システムのタイプには、この展開を選択します。単一の VM に共存するルータおよびロガーは、指定された要件を満たしています。 |
||
9 |
UCCE 4000 Agents Rogger |
CCE PG のみが展開されている CCE エンタープライズ システムのタイプには、この展開を選択します。単一の VM に共存するルータおよびロガーは、指定された要件を満たしています。 |
||
10 |
Packaged CCE: ラボ モード |
実稼働環境での Packaged CCE ラボ展開の場合、この展開タイプを選択します。 |
||
11 |
HCS-CC 2000 エージェント |
Cisco HCS for Contact Center ソリューションの 2000 エージェントのリファレンス設計にこの展開タイプを選択します。2000 エージェントのリファレンス設計のバリエーションである Cisco HCS for Contact Center 500 エージェント設計が含まれています。 |
||
13 |
UCCE: Progger (ラボのみ) |
ルータ、ロガー、および PG が同じ VM 上にない場合でも、すべてのラボ展開では、このタイプを選択します。
|
||
14 |
HCS-CC 4000 エージェント |
Unified CCE PG のみが展開されている Unified CCE システムのタイプには、この展開を選択します。この展開は、4000 Unified CCE エージェントの要件を満たすその他のサーバ上のルータおよびロガーを備えた分散システム用です。 |
||
15 |
HCS-CC 12000 エージェント |
Cisco HCS for Contact Center ソリューションの 12000 エージェントのリファレンス設計にこの展開タイプを選択します。 |
||
16 |
UCCE: 2000 エージェント |
Unified CCE ソリューションの 2000 エージェントのリファレンス設計にこの展開タイプを選択します。 |
||
17 |
Packaged CCE: 4000 エージェント |
Packaged CCE ソリューションの 4000 エージェントのリファレンス設計にこの展開タイプを選択します。 |
||
18 |
Packaged CCE: 12000 エージェント |
Packaged CCE ソリューションの 12000 エージェントのリファレンス設計にこの展開タイプを選択します。 |
||
19 |
UCCE 24000 エージェント ルータ / ロガー |
Unified CCE ソリューションの 24000 エージェントのリファレンス設計にこの展開タイプを選択します。 |
||
20 |
HCS-CC 24000 エージェント |
HCS-CC ソリューションの 24000 エージェントのリファレンス設計にこの展開タイプを選択します。 |
(注) |
構成中にソリューションの適切な展開タイプを設定することが肝心です。誤った展開タイプを選択すると、ソリューションでは過負荷保護されないか、不適切な容量設定に基づいてコールを拒否して処理します。 |
輻輳処置モード
システムには、輻輳が原因で拒否または処理されたコールを処理する 5 つのオプションが提供されています。以下のオプションのいずれかを選択して、コール処理することができます。
-
ダイヤル番号のデフォルト ラベルを使用するコール処理: 拒否されたコールは、着信コールが着信したダイヤル番号のデフォルト ラベルで処理されます。
-
ルーティング クライアントのデフォルト ラベルを使用するコール処理する: 拒否されたコールは、着信コールが到着したルーティング クライアントのデフォルト ラベルで処理されます。
-
システム デフォルト ラベルを使用するコール処理: 拒否されたコールは、輻輳制御設定で設定されたシステム デフォルト ラベルで処理されます。
-
Dialog Fail または RouteEnd を使用したコールの終了: ダイアログ障害を使用して着信ダイアログを終了します。
-
ルーティング クライアントへのリリース メッセージを使用したコール処理: リリース メッセージで着信ダイアログを終了します。
ルーティング クライアントまたはグローバル レベルのいずれかの輻輳設定で処理オプションを設定します。ルーティング クライアントで処理モードを選択すると、システムの輻輳設定よりも優先されます。
(注) |
ラベルを返してアナウンス付きのコールを処理する場合は、Unified CCE インスタンス外部のアナウンス システムを使用します。Unified CCE インスタンスに処理済みのコールを返してさらに処理しないでください。 |
アウトバウンド オプションのコール処理
アウトバウンド オプションは、輻輳制御を使用したコール処理の特殊なケースです。アウトバウンド オプションのメディア ルーティング周辺機器ゲートウェイ(MR PG)を統合する場合、PG のルーティング クライアントを構成して、常にダイアログの失敗が送信されるようにします。ダイヤラは、指定された時間が経過した後に拒否された予約コールを再試行します。
輻輳制御レベルおよびしきい値
輻輳制御アルゴリズムには、3 段階のレベルで動作します。各レベルには、開始値と軽減値があります。平均 CPS が開始値より 1 レベルを超えると、システムはより高い輻輳レベルに移行します。たとえば、システムがレベル 0 で、CPS がレベル 2 の開始容量を超える場合、システムはレベル 2 に直接移動します。平均 CPS が現在のレベルの削減値を下回ると、輻輳レベルが低下します。混雑レベルは一度に複数のレベルに上昇する可能性があります。ただし、減少する際は、輻輳レベルは一度に 1 レベルのみの低減となります。
輻輳レベル |
しきい値 (キャパシティの%) |
説明 |
---|---|---|
レベル1 開始値 |
110 |
平均 CPS がこの値を超えると、輻輳レベルはレベル 1 に移行します。 |
レベル 1 軽減値 |
90 % |
平均 CPS がこの値を下回ると、輻輳レベルはレベル 0(通常の動作レベル)に戻ります。 |
レベル 1 減少 |
10 % |
レベル 1 の輻輳で拒否された着信コールの割合。 |
レベル 2 開始値 |
130% |
平均 CPS がこの値を超えると、輻輳レベルはレベル 2 に移行します。 |
レベル 2 軽減値 |
100 % |
平均 CPS がこの値を下回ると、輻輳レベルはレベル 1 に戻ります。 |
レベル 2 減少 |
30 % |
レベル 2 の輻輳で拒否された着信コールの割合。 |
レベル 3 開始値 |
150% |
平均 CPS がこの値を超えると、輻輳レベルはレベル 3 に移行します。 |
レベル 3 軽減値 |
100 % |
平均 CPS がこの値を下回ると、輻輳レベルはレベル 2 に戻ります。 |
レベル 3 減少 |
100% から 30% への可変削減率 |
レベル 3 の輻輳で拒否された着信コールの割合。輻輳レベルがレベル 3 になると、着信率に応じて削減率は 30% から 100% に変化します。 |
(注) |
開始値、軽減値、および減少の設定を構成することはできません。これらの値は、システムの標準 CPS 容量の割合として定義されます。 |
輻輳制御 CPS の制限
以下の表に、サポートされる展開タイプの最大サポート コール / 秒(CPS)を示します。
展開タイプ |
毎秒の最大コール数 |
注 |
---|---|---|
NAM (廃止) |
300 |
11.5 で廃止済です。 |
Contact Director |
300 |
リファレンス設計 |
NAM Rogger (廃止) |
150 |
11.5 で廃止済です。 |
UCCE: 12000 エージェント |
105 |
リファレンス設計 |
Packaged CCE: 2000 エージェント |
18 |
リファレンス設計 |
UCCE: 4000 エージェント |
35 |
リファレンス設計 |
Packaged CCE: ラボ モード |
1 |
実稼働環境ではサポートされません。 |
HCS-CC 2000 エージェント |
18 |
リファレンス設計 |
UCCE: Progger (ラボのみ) |
4 |
実稼働環境ではサポートされません。 |
HCS-CC 4000 エージェント |
35 |
リファレンス設計 |
HCS-CC 12000 エージェント |
105 |
リファレンス設計 |
UCCE: 2000 エージェント |
18 |
リファレンス設計 |
Packaged CCE: 4000 エージェント |
35 |
リファレンス設計 |
Packaged CCE: 12000 エージェント |
105 |
リファレンス設計 |
UCCE 24000 エージェント ルータ / ロガー |
105 |
リファレンス設計 |
HCS-CC 24000 エージェント |
105 |
リファレンス設計 |