コア コンポーネントの帯域幅、遅延、および QoS
コアコンポーネントによる帯域幅の使用例
この表は、テスト環境のコアコンポーネントによる帯域幅の使用例を示しています。
Unified CCE Components |
パブリックネットワークの帯域幅(KBps) |
プライベートネットワークの帯域幅(KBps) |
動作条件 |
||||
---|---|---|---|---|---|---|---|
ピーク |
平均 |
第 95 パーセンタイル |
ピーク |
平均 |
第 95 パーセンタイル |
||
特大規模ライブデータ |
44875 |
12546 |
21134 |
該当なし |
該当なし |
該当なし |
24000 SSO エージェント 105 CPS(転送 10%、会議 5% を含む)、ECC: 5 スカラー @ 各 40 バイト、最大クエリ負荷時 200 人のレポートユーザ。 |
ルータ |
2307 |
1189 |
1173 |
1908 |
1048 |
1024 |
12,000 エージェント、105 CPS(転送 10%、会議 5% を含む)、ECC:5 スカラー @ 各 40 バイト、最大クエリ負荷時 200 人のレポートユーザ |
Logger |
14624 |
2696 |
8718 |
12351 |
2184 |
7795 |
|
AW-HDS |
4113 |
1522 |
3215 |
該当なし |
該当なし |
該当なし |
|
HDS-DDS |
3323 |
512 |
1627 |
該当なし |
該当なし |
該当なし |
|
Cisco Identity サーバ(IdS) |
35 |
26 |
33 |
該当なし |
該当なし |
該当なし |
|
大規模ライブデータ |
47073 |
6018 |
8079 |
該当なし |
該当なし |
該当なし |
|
Rogger |
6410 |
2314 |
3498 |
5875 |
1987 |
3185 |
4,000 エージェント、30 CPS、ECC、5 スカラー @ 各 40 バイト、最大クエリ負荷時 200 レポートユーザ |
AW-HDS-DDS |
4891 |
2476 |
3651 |
該当なし |
該当なし |
該当なし |
|
Cisco Identity サーバ(IdS) |
112 |
88 |
105 |
該当なし |
該当なし |
該当なし |
|
小規模ライブデータ |
25086 |
3998 |
5487 |
該当なし |
該当なし |
該当なし |
|
Rogger |
2561 |
1040 |
1338 |
2141 |
789 |
1443 |
2,000 エージェント、15 CPS、ECC、5 スカラー @ @ 各 40 バイト、最大クエリ負荷時 200 レポートユーザ。 |
AW-HDS-DDS |
4014 |
2881 |
3174 |
該当なし |
該当なし |
該当なし |
|
CUIC-LD-Ids |
105544 |
8496 |
10236 |
該当なし |
該当なし |
該当なし |
|
中規模 PG |
12012 |
7702 |
10486 |
8795 |
6478 |
7846 |
|
CUIC |
10620 |
4351 |
7947 |
該当なし |
該当なし |
該当なし |
|
Finesse |
18449 |
16125 |
17381 |
該当なし |
該当なし |
該当なし |
|
CVP Call/VXML |
2198 |
2141 |
2196 |
該当なし |
該当なし |
該当なし |
|
CVP レポート |
2008 |
1980 |
2004 |
該当なし |
該当なし |
該当なし |
イングレス、イーグレス、および VXML ゲートウェイの帯域幅、遅延、および QoS
音声ブラウザと CVP VXML サーバ間のネットワーク遅延は、200 ミリ秒 RTT を超すことはできません。グローバル展開を使用すると、必要な遅延を維持できます。
Unified CVP の帯域幅、遅延、および QoS
Unified CVP および VVB の帯域幅に関する考慮事項
イングレスゲートウェイおよび音声ブラウザは、メディアファイル、VXML ドキュメントおよび呼制御シグナリングを提供するサーバとは別に分離されています。これらの要因により、Unified CVP 帯域幅の要件が発生します。
たとえば、すべてのコールに 1 分間の VRU 処理があり、エージェントへの 1 回の転送が 1 分間あるとします。各ブランチには 20 人のエージェントがいます。各エージェントが 1 時間に 30 コールを処理する場合、ブランチでは 1 時間あたり 600 コール処理することになります。コール平均レートは、ブランチあたり 0.166 コール/秒(CPS)です。
これら変数で小さな変更があったとしてもサイジングには大きな影響となる場合があります。1 秒当たり 0.166 コールが 1 時間の平均となります。通常、コールは 1 時間全体で均一に到着するわけではなく、ビジーな時間帯で山と谷があります。外部要因は、コールの量にも影響します。たとえば、エアラインなどの事業では、悪天候が原因でコールの量が増加しますし、プロモーションがあれば、小売業者でのコールの量が増加します。ビジネスで最も多いトラフィック期間を見つけ、最悪のシナリオに基づいてコール到着率を計算します。
VXML ドキュメント
発信者に再生されるプロンプトごとの VXML ドキュメントが生成されます。このドキュメントは、Unified ICM スクリプトと Cisco Unified Call Studio のいずれかまたは両方を使用して記述した音声アプリケーションスクリプトに基づいて生成されます。VXML ドキュメントのサイズは、使用するプロンプトのタイプに応じて異なります。たとえば、複数選択があるメニュープロンプトは、アナウンスメントのみを再生するプロンプトよりもサイズは大きくなります。
![]() Note |
コールサーバまたは VXML サーバ用の VXML ドキュメントおよびゲートウェイの概算サイズは、7 KBです。 |
帯域幅は次の方法で計算できます。
- プロンプトによって推定される帯域幅
-
ブランチオフィスの帯域幅は次のように推定できます。
CPS * Bits per Prompt * Prompts per call = Bandwidth in bps
前に挙げた、7 KBの VXML ドキュメントの例について考えてみましょう。
7,000 bytes * 8 bits/byte = 56,000 bits per prompt (0.166 calls/second) * (56,000 bits/prompt) * (Number of prompts / call) = bps per branch
- VXML ドキュメントによって推定される帯域幅
-
次の表にリストされている VXML ドキュメントのサイズを使用して、必要な帯域幅を計算します。次の表のドキュメントのサイズは、VXML サーバから音声ブラウザに対して測定されます。
Table 2. VXML ドキュメント タイプの概算サイズ VXML ドキュメント タイプ
推定サイズ(バイト単位)
ルートドキュメント(コールの開始時に必要なもの)
19,000
Subdialog_start(コールの開始時、少なくともコールごとに 1 つ必要)
700
Call-ID および GUID のゲートウェイのクエリー(コールごとに必要)
1300
メニュー(メニューの選択肢の数によってサイズが増大)
メニューの選択肢ごとに 1000 + 2000
通知の再生(単純な .wav ファイル)
1100
クリーンアップ(コール終話に必要なもの)
4000
![]() Note |
より複雑な解決策については、プロンプトによる必要な帯域幅の推定値よりも、この 2 番目のメソッドの方がより正確な推定値を出すことができます。 |
メディア ファイルの取得
メディアファイルまたは プロンプトは、ローカルでIOS 音声ゲートウェイ向けのフラッシュメモリや Cisco VVB 向けファイルシステムに保存できます。メディアファイルをローカルに保存すると、帯域幅の考慮事項がなくなります。ただし、すべてのルータまたは VVB で変更を要求するプロンプトを置き換える必要があるため、これらのプロンプトを維持することは難しいです。HTTP メディアサーバ(または HTTP キャッシュエンジン)上でこれらのプロンプトをローカルに保存すると、ゲートウェイは取得後に音声プロンプトをローカルにキャッシュできます。HTTP メディアサーバは、プロンプトの数とサイズに応じて複数のプロンプトをキャッシュできます。プロンプトの更新期間は HTTP メディア サーバで定義されます。帯域幅の使用量は、各ゲートウェイでのプロンプトの初期ロードに制限されます。これには、更新間隔の有効期限後の定期的な更新も含まれます。
![]() Note |
VVB では HTTP キャッシュを無効にすることはできません。 |
VXML ゲートウェイでプロンプトをキャッシュしない場合、次に大きな影響が出る場合があります。
-
Cisco IOS のパフォーマンスが 35 ~ 45% 低下。
-
追加の帯域幅が必要。たとえば、平均サイズが 50 KB で、更新間隔が 15 分の 50 のプロンプトがある場合、平均帯域幅の使用率は次のようになります。
(50 prompts) * (50,000 bytes/prompt) * (8 bits/byte) = 20,000,000 bits (20,000,000 bits) / (900 second) = 22.2 kbps per branch
![]() Note |
VVB の帯域幅に関する検討事項には、G.711 および G.729 音声トラフィックに関する VXML ドキュメント、メディアファイル取得、RTP ストリームの帯域幅が含まれます。 |
Unified CVP に関するネットワークリンクに関する考慮事項
Unified CVP の場合、WAN および LAN トラフィックを音声トラフィック、呼制御トラフィック、およびデータトラフィックにグループ化できます。
音声トラフィック
音声コールは Real-time Transport Protocol(RTP)パケットで構成されます。これらのパケットには次に送信される音声サンプルが含まれます。
-
PSTN イングレスゲートウェイまたは WAN または LAN 接続を介した発信 IP 電話と、次のいずれかとの間では…
-
別の IP 電話がイングレスゲートウェイまたはコール IP 電話と併置されているかどうか(同じ LAN 上にあるかどうか)。
-
TDM ACD 用のフロントエンドのエグレスゲートウェイ(レガシー ACD または VRU 用)。エグレスゲートウェイは、イングレスゲートウェイと併置されていない場合と、併置されている場合があります。
-
プロンプト/コレクト処理を実行する音声ブラウザ。音声ブラウザは、同じまたは異なるイングレスゲートウェイにすることができます。いずれの場合も、イングレスゲートウェイと音声ブラウザは併置します。
-
-
音声ブラウザと ASR または TTS サーバ間。音声ブラウザと ASR/TTS サーバ間の RTP ストリームは G.711 である必要があります。
SIP を使用した呼制御トラフィック
Unified CVP は、Cisco IOS 音声ゲートウェイと Unified Communications Manager の 3 種類の VoIP エンドポイントで呼制御モードまたはシグナリングモードで動作します。呼制御トラフィックは、次のエンドポイント間で WAN または LAN を通してフローします。
-
コールサーバおよび IME 除外グループ — 着信通話は、Unified CM、Cisco IOS 音声ゲートウェイまたは別の SIP デバイスから着信します。
-
コールサーバおよび発信電話 — 発信電話は、Unified CM、Cisco IOS 音声ゲートウェイから発信されます。エグレスゲートウェイは、プロンプト/コレクト処理を発信者に提供する VXML ゲートウェイです。また、エージェント(Unified CCE または TDM)またはレガシー TDM VRU への転送の対象にもなっています。
VRU PG を使用した呼制御トラフィック
コールサーバと Unified CCE VRU PG は、GED-125 プロトコルを使用して通信します。GED-125 プロトコルには、次の機能があります。
-
コールが到着したときに発信者エクスペリエンスを制御する通知メッセージ。
-
発信者を転送または切断する指示。
-
発信者エクスペリエンスに対する VRU 処理を制御する指示。
VRU PG は、LAN 接続を介して Unified CVP に接続します。ただし、WAN を介したクラスタリングを使用する展開では、Unified CVP を WAN 全体で冗長の VRU PG に接続できます。
セントラルコントローラと VRU PG 間の帯域幅は、VRU PG と Unified CVP 間の帯域幅と同様です。
冗長 VRU PG ペアが WAN で分割されている場合、合計帯域幅は 2 倍になります。セントラルコントローラから VRU-PG への接続では、報告された帯域幅が必要です。VRU-PG から Unified-CVP への接続には同量の帯域幅が必要です。
メディアリソース制御プロトコルトラフィック
VXML ゲートウェイとシスコ仮想化音声ブラウザは、メディアリソース制御プロトコル(MRCP)v1.0 および v2 の両方を使用して ASR/TTS サーバと通信します。このプロトコルにより、Nuance などの ASR/TTS サーバへの接続が確立されます。接続は、LAN または WAN 経由で確立できます。
![]() Note |
シスコは、WAN 環境の音声アプリケーションをテストまたは適格確認していません。設計のガイドライン、WAN でのサポートおよび関連する警告については、各ベンダー専用マニュアルを参照してください。TAC は、音声アプリケーションに関連した問題について(サードパーティの相互運用性認定製品の場合と同様に)限定されたサポートを提供しています。 |
セントラルコントローラから VRU PG トラフィック
セントラルコントローラと VRU PG 間の通信用のサイジングツールはありません。ただしセントラルコントローラと IP IVR PG 間の帯域幅を見積るツールを使うと、1 つの値を置き換えた場合、Unified CVP の正確な測定値が生成されます。
[RUN VRU SCRIPTノードの平均数(Average number of RUN VRU SCRIPT nodes)] フィールドでは、Unified CVP と対話する Unified CCE スクリプトノードの数を代入します。Unified CVP と対話できるノードは次のとおりです。
-
外部スクリプト実行
-
ラベル
-
戻り可能ラベル
-
スキルグループへのキューイング
-
エージェント キューイング
-
エージェント
-
リリース
-
VRU 転送
-
VRU トランスレーション ルート
接続は、WAN または LAN を介して確立できます。
データ トラフィック
データトラフィックには、HTTP リクエストの結果として返される VXML ドキュメントと事前録音されたメディアファイルが含まれます。音声ブラウザは、次のリクエストを実行します。
-
Media File サーバに対する HTTP リクエスト内のメディアファイル — Media File サーバ応答は、HTTP メッセージの本文でメディアファイルを返します。音声ブラウザは、メディアファイルを Real-time Transport Protocol(RTP)パケットに変換し、それを発信者に再生します。接続は、WAN または LAN を介して確立できます。
-
CVP サーバからの VXML ドキュメント — この場合、接続は WAN または LAN 経由で確立できます。
帯域幅のサイジング
一般的に、分散型トポロジは、Unified CVP に対して最も帯域幅を集中的に消費します。イングレスゲートウェイおよび音声ブラウザは、メディアファイル、VXML ドキュメントおよび呼制御シグナリングを提供するサーバとは別に分離されています。
![]() Note |
すべての呼び出しの前の例に、1 分間の VRU 処理と、1 分間のエージェントへの 1 回の転送があるという例を思い出してください。各拠点には 20 のエージェントが存在し、各エージェントは 1 時間当たり 30 コールを処理するため、拠点ごとに 1 時間当たり合計 600 のコールが処理されます。コール平均レートは、ブランチあたり 0.166 コール/秒(CPS)です。 |
SIP シグナリング
SIP とは、VoIP ネットワークなどのマルチメディア通信セッションを制御するためのテキストベースおよびシグナリング通信プロトコルです。また、SIP を使用して、メディアストリームからなるセッションを作成、変更、終了できます。SIP セッションには、インターネット電話の通話、マルチメディアの流通、マルチメディア会議などがあります。SIP は、ツーパーティ(ユニキャスト)またはマルチパーティ(マルチキャスト)セッションに使用できます。
通常の SIP コールフローでは、コールごとに約 17,000 バイトが使用されます。1 秒ごとのコールに基づいた前述の帯域幅の数式を使用すると、平均の帯域幅使用量は次のようになります。
(17,000 bytes/call) * (8 bits/byte) = 136,000 bits per call
(0.166 calls/second) * (136 kilobits/call) = 22.5 average kbps per branch
G.711 および G.729 音声トラフィック
Unified CVP は、G.711 と G.729 の両方のコーデックをサポートします。ただし、所定のコールでのコール レッグおよびすべての VRU は、同じ音声コーデックを使用する必要があります。音声認識では、ASR/TTS サーバが G.711 のみをサポートします。音声 RTP ストリームの詳細については、http://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager/products-implementation-design-guides-list.html の「シスコ コラボレーション システム ソリューション リファレンス ネットワーク 設計(SRND)」を参照してください。
ネットワーク遅延
適切なアプリケーション帯域幅と QoS ポリシーが展開されたら、分散型 CVP 展開のネットワーク遅延を検討します。十分なネットワーク帯域幅がある場合、遅延の主な要因は、音声ブラウザと コールサーバまたは VXML サーバ間の距離となります。分散型 CVP 展開では、遅延を最小限に抑え、ソリューションのパフォーマンスに効果を発揮します。
ネットワーク遅延は、次の方法で分散 CVP 導入に影響します。
-
これは、ネットワーク遅延が、CVP コンポーネント間である場合、エンドユーザの通話エクスペリエンスに影響します。コールサーバと音声ゲートウェイ間の SIP によるコールシグナリングの遅延は、コールの設定時間に影響します。遅延は、この設定中に無音の期間を追加する可能性があります。これには、最初のコール設定、最終的なコールフローの一部である後続の転送や会議などがあります。
-
VXML アプリケーション ドキュメントのダウンロード時間に大きく影響し、発信者の最終的なエクスペリエンスに著しく影響します。
次のシステム設定の変更により、VXML サーバから音声ブラウザが地理的に分離されるなど、WAN の遅延が軽減されます。
-
無音期間中に音声を発信者に提供します。
次の設定は、発信者が切断しないように、通話中断時に折り返し電話と音声を提供します。
-
VRU での通常の通話設定時間よりも長い折り返し電話音を追加するには、存続可能性サービスで
wan-delay-ringback
を 1 に設定します。 -
VRU サブシステム設定を
IVR.FetchAudioDelay
とIVR.FetchAudioMinimum
に追加します。これらの WAN 遅延設定は、ルートドキュメントの取得が WAN リンクを介して遅延している場合に必要です。 -
IVR.FetchAudio
の値をIVR.Fetchaudio= flash:holdmusic.wav
のように指定します。デフォルトを空のままにして、通常のシナリオでは何も再生されないようにします。 -
通常のネットワークシナリオでピッという音を回避するには、デフォルト設定を 2 にします。
-
WAN 遅延を 0 に設定すると、最低 5 秒間、すぐに holdmusic.wav が再生されます。
-
user.microapp.fetchdelay
、user.microapp.fetchminimum
およびuser.microapp.fetchaudio
などの ECC 変数を使用して、getSpeechExternal
マイクロアプリの起動間の ECC 変数をオーバーライドします。
Note
仮想化音声ブラウザにコールがある場合は、ECC 変数を使用できません。
-
-
IOS 音声ゲートウェイでパス MTU ディスカバリを有効にします。
IOS 音声ゲートウェイで
ip tcp path-mtu-discovery
コマンドを追加します。パス MTU メソッドは、TCP 接続のエンドポイント間におけるネットワークの利用可能な帯域幅の使用率を最大化します。
-
VXML サーバと ICM スクリプト間のラウンドトリップを最小化する。
実行中の VXML サーバアプリケーションから渡された制御が、ICM スクリプトに戻されると、大幅な WAN 遅延が発生します。
VXML サーバアプリケーションの実行を開始したら、Unified CCE スクリプトへのトリップ数を最小限に抑える必要があります。VXML サーバと Unified CCE スクリプト間の各ラウンドトリップでは、遅延が発生します。2 つの新しい TCP 接続と、VHTTP サーバルートドキュメントを含む複数の VXML ドキュメントの HTTP 取得が確立されます。
-
VXML サーバのルートドキュメントのサイズを縮小する。
VXML サーバで、ゲートウェイアダプタの plugin.xml ファイルの内容を次のように変更します。
<setting name="vxml_error_handling">default</setting>
次へ:
<setting name="vxml_error_handling">minimal</setting>
たとえば、CISCO DTMF 1 GW アダプターに対する plugin.xml ファイルの場所は、Cisco\CVP\VXMLServer\gateways\cisco_dtmf_01\6.0.1\plugin.xml です。
![]() Note |
HTTP は、発信者に再生される VXML ドキュメントおよび他のメディアファイルを転送します。エンドユーザのコーリングエクスペリエンスを最適なものとするために、HTTP トラフィックは、エンタープライズ ネットワークでの標準規格 HTTP トラフィックの優先順位よりも高い優先順位で処理します。可能な場合は、この HTTP トラフィックを CVP コール シグナリング トラフィックと同じように処理します。この問題を回避するには、VXML サーバを音声ブラウザと同じローカルエリアに移動するか、ワイド エリア アプリケーション サービス(WAAS)を使用します。 |
Unified CVP のポート使用量と QoS 構成
コールサーバは、SIP メッセージの QoS DSCP のみにマーキングします。WAN 全体の CVP トラフィックに QoS が必要な場合は、IP アドレスとポートを使用して QoS に対してネットワークルータを構成し、トラフィックを分類、マークします。次の表に、必要な構成の概要を示します。
CVP-Data キューとシグナリング キューは、Cisco IOS ルータに関する用語では優先順位のキューではありません。音声または他のリアルタイムトラフィックに優先順位キューを使用します。コールシグナリングおよび CVP トラフィックの通話量に基づいて、いくつかの帯域幅を予約します。
コンポーネント | ポート | キュー | PHB | DSCP | 最大遅延(ラウンドトリップ) |
---|---|---|---|---|---|
メディア サーバ | TCP 80 | CVP- データ | AF11 | 10 | 1 秒 |
Unified CVP コール サーバ、SIP | TCP または UDP 5060 | コール シグナリング | CS3 | 24 | 200 ms |
Unified CVP IVR サービス | TCP 8000 | CVP- データ | AF11 | 10 | 1 秒 |
Unified CVP VXML サーバ | TCP 7000 | CVP- データ | AF11 | 10 | 1 秒 |
イングレス音声ゲートウェイ、SIP | TCP または UDP 5060 | コール シグナリング | CS3 | 24 | 200 ms |
音声ブラウザ、SIP | TCP または UDP 5060 | コール シグナリング | CS3 | 24 | 200 ms |
SIP Proxy サーバ | TCP または UDP 5060 | コール シグナリング | CS3 | 24 | 200 ms |
MRCP | TCP 554 | コール シグナリング | CS3 | 24 | 200 ms |
WAN の帯域幅のプロビジョニングと QoS に関する考慮事項
一部の CVP 導入では、すべてのコンポーネントが中央に集中しています。これらの展開では LAN 構造を使用するため、WAN ネットワークトラフィックは問題になりません。次のようなシナリオでは、WAN が CVP の帯域幅と QoS に影響を与える可能性があります。
-
イングレスゲートウェイと Unified CVP サーバの間の WAN を使用する分散 CVP 導入
-
イングレスゲートウェイとエージェントの間に WAN を使用する CVP 導入。
CVP は次の方法で QoS を考慮します。
-
CVP にはプライベート WAN ネットワーク構造がありません。必要な場合、すべての WAN アクティビティはコンバージされた WAN ネットワーク構造で実行されます。
-
CVP では、高優先順位または低優先順位トラフィック用に個別の IP アドレスを使用しません。
![]() Note |
Resource Reservation Protocol(RSVP)はコール アドミッション コントロールに使用されます。ルータは、コールの帯域幅を予約するためにも使用します。RSVP は、SIP の Unified CVP コール サーバを介したコール制御シグナリングには適していません。コール アドミッション コントロールの場合、ソリューションは CVP と Unified CM のロケーション構成を使用する方法です。 |
Unified CCE の帯域幅、遅延、および QoS
Unified CCE の帯域幅と遅延の要件
セントラルコントローラ(ルータ)と PG 間で送信されるトラフィックの量は、そのサイトの負荷通話に大きく基づきます。構成の負荷や特定の構成サイズなど、一時的な境界条件もトラフィック量に影響します。帯域幅の調整機能やサイジングフォーミュラを使用すると、帯域幅の要件をより正確にプロジェクトできます。
ACD と VRU を使用するサイトの帯域幅の調整機能では、両方の周辺機器を考慮する必要があります。1 コールあたり 1000 バイトをルールとして使用しますが、十分な帯域幅が存在することを確認するために、システムが運用可能な状態にし、実際の動作をモニタします。このルールに基づいて、4 つの周辺機器があるサイトでは、それぞれ毎秒 10 コールで、320 kbps の帯域幅が必要です。(Unified CCE は、各パスのセントラル コントローラ サイドと PG サイドの両方でデータ送信統計情報を測定します)。
帯域幅と同様に、Unified CCE では、設計通り機能するようにネットワークリンクに固有の遅延が必要です。冗長のセントラルコントローラと PG ノード間のプライベートネットワークの双方向における最大遅延は、80 ミリ秒です。設計通りの実行するために必要な PG から CC へのパブリックネットワークの双方向における最大遅延は、400 ミリ秒です。これらの遅延要件を満たすか超えるのは、Unified CCE のルーティング後および変換ルートにとって重要です。
![]() Note |
一般に、エージェント グリーティング機能はシステム全体において低遅延を必要とします。たとえば、エージェント グリーティング機能を設計どおりにサポートするために、パブリック ネットワークでは最大ラウンドトリップ遅延が 100 ms になります。 |
Unified CCE の帯域幅と遅延の設計は、基になる IP の優先スキームによって異なります。適切な優先設定を行わないと、WAN 接続は失敗します。
最終的なネットワーク設計に応じて、共有ネットワークの IP キューイング戦略は、Unified CCE トラフィックの優先設定を他の非 DNP トラフィック フローと同時に達成する必要があります。このキューイング戦略は、トラフィックプロファイルと帯域幅の可用性によって異なります。ソリューションの厳しい帯域幅、遅延、および優先要件を満たしない限り、共有ネットワークでの成功は保証できません。
Unified CCE 帯域幅に関する考慮事項
エージェントデスクトップから コールサーバおよびエージェント PG へ
デスクトップ、Unified CCE コールサーバ、エージェント PG 間のトラフィックと帯域幅要件には考慮すべき要素が多数あります。VoIP パケットストリームの帯域幅は、帯域幅の使用に役立つ主な要素です。ただし、呼制御、エージェントの状態シグナリング、サイレントモニタリング、録音、統計などの要因は他にもう 1 つがあります。
Cisco Finesse デスクトップに必要な帯域幅を計算するには、http://www.cisco.com/c/en/us/support/customer-collaboration/finesse/products-technical-reference-list.html の「Finesse 帯域幅調整機能」を参照してください。
Cisco Finesse では、サーバとエージェントデスクトップ間の遅延を 400 ミリ秒のラウンドトリップ時間に制限します。
セントラル コントローラ コンポーネント
Unified CCE Central Controllers(ルータと Logger)では、冗長ペア間に個別のプライベート ネットワーク リンクが必要です。プライベートネットワーク全体の遅延は、往復で 80 ミリ秒を超えてはなりません。
Unified CCE のプライベートネットワーク帯域幅の要件
プライベートネットワークのリンクとキューのサイズを計算するには、このワークシートを使用します。
![]() Note |
どの場合でも、リンクの最小サイズは 1.5Mbps(T1)です。 |
コンポーネント |
実効 BHCA(bps) |
乗数 |
推奨リンク(bps) |
乗数 |
推奨されるキュー(bps) |
|
---|---|---|---|---|---|---|
セントラル コントローラ |
* 30 |
* 0.8 |
セントラルコントローラの高優先順位キュー帯域幅の合計 |
|||
Unified CM PG |
* 100 |
* 0.9 |
これらの番号をまとめて追加し、PG 高優先順位キュー帯域幅の合計を取得します。 |
|||
Unified VRU PG |
* 120 |
* 0.9 |
||||
Unified CVP 変数 |
* ((編集の数 * 平均可変長)/40) |
* 0.9 |
||||
合計リンクサイズ |
PG 高優先順位キュー帯域幅の合計 |
サイト間の 1 つのプライベート ネットワーク リンクの場合は、すべてのリンクサイズをまとめて、表の下部にある [合計リンクサイズ(Total Link Size)] を使用します。それ以外の場合は、セントラル コントローラ プライベート ネットワークの最初の行と、PG プライベートネットワークの他の行の合計を使用します。
WAN 全体に分割されているすべての同様のコンポーネントの実効 BHCA(実効負荷)は、次のように定義されます。
-
セントラルコントローラ — この値は、クレジットカードの BHCA の合計で、会議や転送が含まれています。たとえば、10% の会議または転送がある 10,000 BHCA イングレスは、有効な 11,000 BHCA です。
-
Unified CM PG — この値は、Unified CM が制御し、エージェントに転送される Unified CCE Route Points を介したすべての通話が含まれます。これは、各コールがルートポイントに着信し、最終的にエージェントに送信されることを前提としています。ルートポイントへの 10,000 BHCA着信コールとエージェントへの転送(10% の会議または転送)は、有効な 11,000 BHCA です。
-
Unified VRU PG — この値は、CVP を介した通話処理とキューに対する合計 BHCA です。この計算では、100% の処理が想定されます。たとえば、すべての人が処理を受け、40% がキューに入っている 10,000 BHCA の着信コールは、有効な 14,000 BHCA です。
-
Unified CVP Variables — CVP を介してルートされたすべての通話の Call および ECC 変数の数および可変長。
プライベート帯域幅の計算例
次の表に専用プライベートリンクを次の特性に組み合わせた例を示します。
-
コンタクトセンターに着信する BHCA の数は、10,000 です。
-
CVP は、すべてのコールを処理し、40% がキューに入ります。
-
コールは放棄されない限り、すべてエージェントに送信されます。エージェントへのコールのうち、10% は転送または会議です。
-
通話の処理およびキューに使用される Unified CVP は 4 つで、1 つの PG ペアがそれをサポートします。
-
合計 900 エージェントに対して 1 つの Unified CM PG ペアがあります。
-
コールには、10 つの 40 バイトのコール変数と 10 つの 40 バイトの ECC 変数があります。
コンポーネント |
実効 BHCA(bps) |
乗数 |
推奨リンク(bps) |
乗数 |
推奨されるキュー(bps) |
|
---|---|---|---|---|---|---|
セントラル コントローラ |
11,000 |
* 30 |
330,000 |
* 0.8 |
264,000 |
セントラルコントローラの高優先順位キュー帯域幅の合計 |
Unified CM PG |
11,000 |
* 100 |
1,100,000 |
* 0.9 |
990,000 |
これらの番号をまとめて追加し、PG 高優先順位キュー帯域幅の合計を取得します。 |
Unified VRU PG |
0 |
* 120 |
0 |
* 0.9 |
0 |
|
Unified CVP 変数 |
14,000 |
* ((編集の数 * 平均可変長)/40) |
280,000 |
* 0.9 |
252,000 |
|
合計リンクサイズ |
1,710,000 |
1,242,000 |
PG 高優先順位キュー帯域幅の合計 |
この例にある組み合わせた専用プライベートリンクの計算結果は次のとおりです。
-
合計リンクサイズ = 1,710,000 bps
-
264,000 bps のセントラルコントローラの高優先順位帯域幅キュー
-
1,242,000 bps の PG の高優先順位キュー帯域幅
この例が、セントラル コントローラ プライベートと PG プライベートの 2 つの別個のリンクを持つソリューションの場合、リンクサイズとキューは次のようになります。
-
264,000 bps の優先順位の高い帯域幅キュー付きの 330,000 bps のセントラル コントローラ リンク(事前定義した実際の最小リンクは 1.5 Mb)
-
1,242,000 bps の高優先順位帯域幅キュー付きの 1,380,000 bps のPG リンク
プライベートネットワークに Multilink Point-to-Point Protocol(MLPPP)を使用する場合、MLPPP リンクの次の属性を設定します。
-
パケットごとのロードバランサではなく、接続先ごとにロードバランサを使用します。
-
Point-to-Point Protocol(PPP)フラグメントを有効にして、シリアル化された遅延を軽減します。
![]() Note |
2 つの個別のマルチリンクが必要で、各リンクは、接続先ごとロードバランサ用です。 |
WAN を使用したクラスタ化の帯域幅要件
すべての Unified CCE プライベート、パブリック、CTI、および Unified Communications Manager のクラスタ間通信シグナリング(ICCS)に対して、高可用性(HA)WAN 全体で帯域幅を保証する必要があります。さらに、高可用性 WAN を通過するすべての通話に対して帯域幅を保証する必要があります。高可用性 WAN ですべての Unified CCE シグナリングを扱うために最低限必要な帯域幅は、2 Mbps です。
Unified CVP から VRU PG
現在、VRU PG と Unified CVP 間の通信に特化したツールは存在しません。ただし、前の項で説明したツールでは、必要な帯域幅をかなり正確に測定できます。Unified CCE セントラルコントローラ と VRU PG 間で消費される帯域幅は、VRU PG と CVP 間で消費される帯域幅と似ています。
VRU PG が WAN 全体に分割されている場合、必要な帯域幅の合計はツールがレポートする量の 2 倍になります。セントラルコントローラから PG リンクおよび PG から Unifie CVP リンクに対してレポート済みの帯域幅が必要です。
CTI サーバから Cisco Finesse
Cisco Finesse が WAN リンクを使って CTI サーバに接続する際に必要な帯域幅を確認するには、http://www.cisco.com/c/en/us/support/customer-collaboration/finesse/products-technical-reference-list.html の「Finesse 帯域幅計算機」を参照してください。
Unified CM Intra-Cluster Communication Signalling(ICCS; クラスタ内通信シグナリング)
Contact Center Enterprise ソリューションでは、Communications Manager のみの導入より、サブスクライバ間の Intracluster Communication Signaling(ICCS)に対してより多くの帯域幅が必要です。Unified CCE では、より多くのコールリダイレクトとクラスタ間通信への追加 CTI/JTAPI 通信が必要です。次の公式を使用して、ICCS と Unified CCE サブスクライバ間のデータベーストラフィックに必要な帯域幅を計算します。
-
Intracluster Communications Signaling(ICCS)
Total Bandwidth (Mbps) = (Total BHCA) / 10,000) * [1 + (0.006 * Delay)]
Where Delay = ラウンドトリップ時間のミリ秒単位の遅延
この値は、音声ゲートウェイ、エージェント電話機、およびエージェント PG に接続されている各 Unified CM サブスクライバ間で必要な帯域幅です。このリンクの最小値は 1.544 Mbps です。
Note
この式は、10,000 以上の BHCA を想定しています。BHCA が 10,000 未満の場合は、最低 1.544 Mbps を使用します。
-
データベースおよび他の通信
パブリッシャからリモートのサブスクライバごとに 1.544 Mbps
この ICCS 公式に使用する BHCA 値は、コンタクトセンターに着信するすべてのコールの合計 BHCA です。
-
CTI ICCS
帯域幅(Mbps)=(合計 BHCA/10,000)* 0.53
これらの帯域幅の要件は、適切な設計と導入を想定しています。非効率的な設計(たとえば、サイト 1 への着信コールをサイト 2 で処理する場合)、クラスタ間の通信が多く、定義されている帯域幅の要件を超える可能性があります。
Unified CCE の QoS に関する考慮事項
この項では、Unified CCE パブリック ネットワーク トラフィックとプライベート ネットワーク トラフィックの両方に関する QoS マーキング、マキューイング、およびガイドラインについて説明します。WAN トラフィックフローに適切な Quality of Service(QoS)の適用など、WAN 上のネットワーク トラフィック フローのプロビジョニング ガイドラインを示します。十分な帯域幅のプロビジョニングと QoS の実装は、Contact Center Enterprise ソリューションを成功にするための重要なコンポーネントです。
一般的に、Contact Center Enterprise WAN ネットワーク構造では、プライベートネットワークとパブリックネットワークの両方に対して個別のリンクを使用します。最適なネットワーク パフォーマンス特性(およびフォールトトレラント フェールオーバーのルートの多様性)のために、Unified CCE には専用のプライベート設備、冗長な IP ルータ、および適切なプライオリティキューイングが必要です。
複数のトラフィッククラスを共有するネットワークを展開している企業は、増分、専用ネットワークへの後戻りではなく、既存インフラストラクチャを維持することを望んでいます。ネットワークの集約がコストと運用の運用効率性を両立させ、そのサポートこそが、Cisco Powered Networks の主要な側面となります。
QoS に対応したパブリックネットワークと、QoS に対応したプライベートネットワーク環境で Unified CCE を導入できます。ただし、ソリューションは厳しい遅延と帯域幅の要件を満たしている必要があります。
Unified CCE は、QoS に差別化されたサービス(DiffServ)モデルを使用します。DiffServ は、トラフィックを異なるクラスに分類し、各ネットワークノードのトラフィッククラスに特定の転送処理を適用します。
トラフィックをマーキングする場所
QoS の計画では、Unified CCE またはネットワークエッジのいずれかでトラフィックにマーキングするかについて不明であることがよくあります。各オプションには賛否両論があります。Unified CCE でトラフィックをマークすることで、IP ルータやスイッチでトラフィックを分類するためのアクセスリストを保存します。
Unified CCE でのトラフィックのマーキングにはいくつかの短所があります。まず、各 PG を個別に変更して、パブリック ネットワーク トラフィックのマーキング値を変更します。次に、QoS 信頼をアクセスレイヤのルータとスイッチを有効化します。これによってマーキング レベルが不正に設定された悪意のあるパケットによる攻撃にネットワークがさらされる危険性があります。
![]() Note |
Windows では、グループポリシーエディタを使用して QoS ポリシーを適用し、DSCP レベル 3 のマーキングをパケットに適用できます。これらのポリシーは、Active Directory ドメインコントローラを介して管理できます。これにより、管理の問題が簡易化される場合があります。詳細については、該当する Microsoft 社の資料を参照してください。 |
一方、ネットワークエッジでトラフィックをマーキングすると、中央集中型およびセキュアなマーキングポリシー管理が可能です。アクセスレイヤデバイスで信頼を有効にする必要はありません。Unified CCE パケットを認識するアクセスリストを定義するには、少しのオーバーヘッドがあります。これらは参考用に表で提供されています。Unified CCE トラフィックの認識にはアクセスリストのポート番号を使用しません。ポート番号によって、アクセスリストが複雑になります。新しい顧客インスタンスをシステムに追加するごとに、アクセスリストを変更する必要があります。
トラフィックのマーキング方法
必要に応じて、デフォルトの Unified CCE QoS マーキングを上書きできます。次の表に、各優先順位フローのデフォルトのマーキング、遅延要件、IP アドレス、およびポートを示します。次の表にある i# は、カスタマーインスタンス番号です。パブリックネットワークでは、中優先順位のトラフィックは、高優先順位のパブリック IP アドレスで送信され、高優先順位のトラフィックと同じようにマークされます。ただし、プライベートネットワークでは、低優先順位のプライベート IP アドレスで中優先順位のトラフィックが送信され、低優先順位のトラフィックと同じようにマークされます。
Cisco Unified Communications のパケット分類の詳細については、http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/uc_system/design/guides/UCgoList.html の『シスコ コラボレーション システム ソリューション リファレンス ネットワーク設計』を参照してください。
![]() Note |
シスコでは、音声制御プロトコルのマーキングを DSCP 26(PHB AF31)から DSCP 24(PHB CS3)に変更し始めています。ただし、多くの製品は依然として、シグナリングトラフィックを DSCP 26(PHB AF31)としてマークしています。したがって、暫定的に、AF31 と CS3 の両方をコールシグナリング用にとっておきます。 |
優先度 |
サーバ側の IP アドレスとポート |
一方向の遅延要件 |
DSCP / 802.1p マーキング |
---|---|---|---|
高 |
IP アドレス:ルータの優先順位が高いパブリック IP アドレス TCP ポート:
UDP ポート:UDP ハートビートには 39500 ~ 39999。 |
200 ms |
AF31 / 3 |
中 |
IP アドレス:ルータの優先順位が高いパブリック IP アドレス TCP ポート:
UDP ポート:UDP ハートビートには 39500 ~ 39999。 |
1000 ミリ秒 |
AF31 / 3 |
低 |
IP アドレス:ルータの優先順位が低いパブリック IP アドレス TCP ポート:
UDP ポート:UDP ハートビートには 39500 ~ 39999。 |
5 秒 |
AF11 / 1 |
優先度 |
サーバ側の IP アドレスとポート |
一方向の遅延要件 |
DSCP / 802.1p マーキング |
---|---|---|---|
高 |
IP アドレス:ルータの高優先プライベート IP アドレス TCP ポート:MDS 高優先接続用 41005 + (i# * 40) UDP ポート:UDP ハートビートには 39500 ~ 39999 |
40 ミリ秒 |
AF31 / 3 |
中 |
IP アドレス:ルータの低優先順位プライベート IP アドレス TCP ポート:MDS 中優先接続用 41016 + (i# * 40) |
1000 ミリ秒 |
AF11/1 |
低 |
IP アドレス:ルータの低優先順位プライベート IP アドレス TCP ポート:
|
1000 ミリ秒 |
AF11/1 |
優先度 |
サーバ側の IP アドレスとポート |
一方向の遅延要件 |
DSCP / 802.1p マーキング |
---|---|---|---|
高 |
IP アドレス:PG 高優先順位プライベート IP アドレス TCP ポート:
UDP ポート:UDP ハートビートには 39500 ~ 39999 |
40 ミリ秒 |
AF31/3 |
中 |
IP アドレス:PG 低優先順位プライベート IP アドレス TCP ポート:
|
1000 ミリ秒 |
AF11/1 |
低 |
IP アドレス:PG 低優先順位プライベート IP アドレス TCP ポート:
|
1000 ミリ秒 |
AF11/1 |
Unified CCE での QoS 有効化
QoS は、プライベート ネットワーク トラフィックでデフォルトで有効になっています。
パブリック ネットワーク トラフィックの QoS を無効にします。ほとんどの導入では、パブリック ネットワーク トラフィックの QoS を無効にすると、フェールオーバー処理がタイムリーになります。
Windows グループポリシーを使用して、または IP エッジルータでマーキングを有効にすることで、コンタクトセンター アプリケーション外で、QoS マーキングを追加できます。
インストール中にルータの QoS を有効にする方法については、ソリューションの「インストールマニュアル」を参照してください。
QoS パフォーマンスモニタリング
QoS 対応のプロセスが起動、実行されると、Microsoft Windows Performance Monitor(PerfMon)を使用して、基礎となるリンクに関連付けられているパフォーマンスカウンタを追跡できます。PerfMon の使用の詳細については、Microsoft のマニュアルを参照してください。QoS のパフォーマンスカウンタの詳細についてはhttp://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-enterprise/products-installation-and-configuration-guides-list.html の Cisco Unified ICM/Contact Center Enterprise サービスアビリティ ベスト プラクティス ガイド を参照してください。
仮想化音声ブラウザの QoS
次の表に、Cisco VVB の RTP と SIP のデフォルトの QoS の概要を示します。必要に応じて、図のようにデフォルトを変更できます」。
コンポーネント |
DSCP |
ポート |
---|---|---|
Cisco VVB RTP |
[CS0(FTP)](デフォルト)
|
RTP 24576:32767 |
Cisco VVB SIP |
[CS0(FTP)](デフォルト)
|
TCP/UDP 5060 |
Cisco VVB TCP/UDP から VXML サーバ、コールサーバ、メディアサーバ、ASR、TTS などのサーバへ |
[CS0(FTP)](デフォルト)
|
TCP/UDP 32768:61000 |
Unified CM の帯域幅、遅延、および QoS
Unified CM クラスタへのエージェント電話機の帯域幅
電話機から Unified CM のシグナリングに必要な帯域幅は、電話機ごとに 150 bps です。
たとえば、1000 エージェントソリューションでは、各コンタクト センター サイトで約 150 kbps が必要です。
Cisco Finesse の帯域幅、遅延、および QoS
Cisco Finesse では、エージェントまたはスーパーバイザのサインイン中が最大の帯域幅使用率になります。この操作には、Web ページのロード、CTI サインイン、および初期エージェントの状態の表示が含まれます。デスクトップの Web ページを読み込むと、必要な帯域幅は小さくなります。
スーパーバイザデスクトップは、追加のガジェットのため、サインイン時により多くの帯域幅を消費します。サインイン操作に最小帯域幅を義務付ける必要はありません。サインインに必要な時間に基づいてソリューションに必要な帯域幅を決定します。Cisco Finesse には、特定のクライアントサインイン時間に必要な帯域幅を想定する帯域幅調整機能(http://www.cisco.com/c/en/us/support/customer-collaboration/finesse/products-technical-reference-list.html)が用意されています。
フェールオーバー中は、エージェントは代替 Cisco Finesse サーバにリダイレクトされ、自動的にログインすると、デスクトップが再ロードされます。予想される帯域幅の使用率は、最大で 90 秒間(ピーク時)で 250 Mbps まで達し、2000 人のエージェントすべてが一方のサイドから別のサイドに正常にフェールオーバーされることを確認します。帯域幅の要件は、チームに構成されたガジェットの種類と数に応じて増加します。
詳細については、https://www.cisco.com/c/en/us/support/customer-collaboration/finesse/products-technical-reference-list.html の「Unified Contact Center Enterprise の Finesse 帯域幅調整機能」を参照してください。
![]() Note |
Cisco Finesse 帯域幅の調整機能には、Cisco Finesse コンテナ内のサードパーティ製ガジェットに必要な帯域幅は含まれません。また、帯域幅が競合するエージェント デスクトップ クライアントで実行する別のアプリケーションは考慮されません。 |
Cisco Finesse は Web アプリケーションであるため、キャッシングを行うと必要な帯域幅に大きな影響を及ぼす可能性があります。エージェントの初回サインイン後に、キャッシュによって以降のサインインに必要な帯域幅が大幅に減少します。サインインに必要な帯域幅を最小限に抑えるために、ブラウザのキャッシュを有効します。
サインインが完了すると、エージェントとスーパーバイザの両方が最も集中した操作で、ルートポイントへの発信コールを行います。スーパーバイザの場合は、[チームパフォーマンス(Team Performance)] と [キュー統計(Queue Statistics)] ガジェットの更新が同時に発生する場合があります。Cisco Finesse 帯域幅調整機能を使用すると、すべての Cisco Finesse クライアントと Cisco Finesse サーバ間の接続に必要な合計帯域幅を計算できます。
この帯域幅を共有する音声トラフィックを含む他のアプリケーションのニーズを処理した後で、ソリューションに必要な帯域幅を確保します。十分な帯域幅を連続的に利用できない場合は、Cisco Finesse インターフェイスのパフォーマンスとコールの音声品質が低下する可能性があります。
Cisco Finesse デスクトップの遅延
エージェント PG からリモートでエージェントとスーパーバイザのデスクトップを見つけることができます。設計が不十分な導入では、タイムアウト値が大きくなると、デスクトップサーバとデスクトップクライアント間で極端な遅延が発生する可能性があります。遅延が大きいと、ユーザエクスペリエンスが影響を受け、エージェントが複雑で受け入れられない結果を招きます。たとえば、デスクトップを更新する前に電話機が鳴り始める場合があります。Cisco Finesse では、サーバとエージェントデスクトップ間の遅延を 400 ミリ秒のラウンドトリップ時間に制限します。
Cisco Finesse では、Cisco Finesse サーバと PG 間の遅延を 200 ミリ秒のラウンドトリップ時間に制限する必要があります。Cisco Finesse サーバ間の遅延を 80 ミリ秒のラウンドトリップ時間に制限します。
Cisco Finesse の QoS
Cisco Finesse は、ネットワークトラフィックでの QoS の設定をサポートしていません。通常、トラフィックの QoS 分類とマーキングはスイッチまたはルータレベルで行われます。特に WAN を介するエージェントの場合は、シグナリングトラフィックを優先順位付けできます。
Cisco IM&P の帯域幅と遅延に関する考慮事項
Cisco IM&P サービスは Unified CM と密接に統合されており、ユーザ管理、サービスの有効化と認証を Unified CM に依存しています。
Cisco IM&P は、可用性を保証するためクラスタとして展開できます。ユーザは、クラスタなしで特定のノードのペアを事前構成する必要があります。Cisco IM&P のインストールおよびクラスタ展開の詳細に関しては、https://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager/products-installation-guides-list.html を参照してください。
IM&P サーバの遅延要件の詳細に関しては、https://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager/products-implementation-design-guides-list.html の Unified CM SRND を参照してください。
Cisco IM&P を使用するデスクトップチャット機能は、より高いクライアント帯域幅が必要です。次で Finesse 帯域幅計算ツールを参照してください。https://www.cisco.com/c/en/us/support/customer-collaboration/finesse/products-technical-reference-list.html
Finesse および IM&P ノード間のサポートされている最大遅延は、200 ミリ秒です。
Unified Intelligence Center の帯域幅、遅延、および QoS
帯域幅のレポートに関するパラメータ
次のパラメータは、デスクトップ上の Cisco Unified Intelligence Center の反応とパフォーマンスに複合的な影響を与えます。
-
リアルタイムレポート — 1 人のユーザが同時に実行できる リアルタイムレポート。
-
リアルタイムレポートの更新レート — プレミアムライセンスを所持している場合、レポート定義を編集すると更新レートを変更できます。Unified Intelligence Center のデフォルトの更新レートは 15 秒です。ライブデータのデフォルトの更新レートは、3 秒です。
-
レポートあたりセル数 — レポートで取得、表示する列の数。
-
履歴レポート — 1 人のユーザが 1 時間あたりに実行する 履歴レポートの数。
-
履歴レポートの更新レート — レポートデータが更新される頻度。
-
レポートごとの行 — 1 つのレポート内の行数。
-
ダッシュボードごとのチャート — 1 つのダッシュボードで同時に使用するチャート数(円グラフ、棒グラフ、線グラフ)。
-
ダッシュボードごとのゲージ — 1 つのダッシュボードで同時に使用するゲージ数(スピードメータ)。
ネットワーク帯域幅要件
必要な帯域幅は、更新頻度、各レポートの行と列の数、その他の要因によって異なります。WAN 全体で、Unified Intelligence Center の遅延は 200 ミリ秒以下である必要があります。
Cisco Unified Intelligence Center Bandwidth Calculator(http://www.cisco.com/c/en/us/support/customer-collaboration/unified-intelligence-center/products-technical-reference-list.html)を使用して、Unified Intelligence Center の実装に対する帯域幅要件を計算します。
Unified Intelligence Center の帯域幅要件の例
このサンプルデータは、ローカルの AWDB データベースとレポートを実行するクライアントマシンを使用する LAN でのテストから取得されたデータです。
このテストの負荷では、以下を実行している1人の Unified Intelligence Center ユーザを使用しました。
200 名の Unified Intelligence Center ユーザが、それぞれ同時に実行しています。
-
1 レポートあたり、10 列、100 行の 2 つの リアルタイムレポート。
-
それぞれ 10 列、2000 行の 2 つの2 つの 履歴レポート。
-
それぞれ 10 列、100 行の 2 つの ライブデータレポート。(LD を実行するかどうかは、導入タイプに基づいて調整します)。
この表は、テストで観察された帯域幅の使用状況を示しています。
接続 |
帯域幅 |
---|---|
Unified Intelligence Center <– –> AWDB |
3.4 mbps |
Unified Intelligence Center <– –> ブラウザベースのレポートクライアント |
5.5 mbps |
必要な帯域幅は、各レポートの行数、同時レポート実行数などのパラメータによって異なります。
仮想環境のディスク帯域幅の要件
Unified Intelligence Center が CPU とメモリの予約に加え、C シリーズのサーバ上の VM で実行されている場合は、毎秒 25 KB I/O のサブシステムをプロビジョニングします。平均して、Unified Intelligence Center はフルロードでこの帯域幅を毎秒 10 KB 消費します。I/O スループットのピーク要件は毎秒 25 KB に達します。
シスコライブデータの帯域幅、遅延、および QoS
ライブデータの帯域幅に関する考慮事項
トラフィックの量、したがって、セントラルコントローラ、PG、およびライブデータ間の帯域幅の使用量は、サイトのコール負荷に大きく基づいています。
ライブデータとデスクトップクライアント間の帯域幅の使用量は、レポートに対するコール率とアクティブ サブスクリプションによって異なります。アクティブ サブスクリプションの数は、次に基づいています。
-
CUIC で表示されている ライブデータレポートの数。
-
ログインしているエージェントの数。
-
各エージェントがメンバーであるスキルグループおよび PQ の数。
Cisco IdS の帯域幅に関する検討事項
したがって、トラフィックの量、Cisco IdS と次のコンポーネント間の帯域幅の使用量は、サインインしたエージェントの数にのみ依存します。
-
Cisco Finesse
-
Cisco Unified Intelligence Center
Finesse 帯域幅計算機と Unified Intelligence Center 帯域幅計算機は、エージェントシフト開始時に API コールがわずかに増加することを考慮に入れています。
Finesse と Unified Latenc Center の帯域幅、遅延、および QoS に関する検討事項の詳細については、Cisco Finesse の帯域幅、遅延、および QoS および Unified Intelligence Center の帯域幅、遅延、および QoS を参照してください。