Совместная работа : Cisco ICM Router Software

Общие сведения об ожидаемой задержке (ED)

5 апреля 2016 - Машинный перевод
Другие версии: PDF-версия:pdf | Отзыв


Содержание


Введение

Этот документ перечисляет некоторые типичные проблемы, отнесенные к Ожидаемой задержке (ED), и объясняет, как вычислить ED, куда данные прибывают из, и как решить проблемы.

Предварительные условия

Требования

Компания Cisco рекомендует предварительно ознакомиться со следующими предметами:

Используемые компоненты

Сведения, содержащиеся в данном документе, касаются следующих версий программного и аппаратного обеспечения:

  • ICM Cisco 4.6.2 и позже

Сведения, представленные в этом документе, были получены от устройств, работающих в специальной лабораторной среде. Все устройства, описанные в этом документе, были запущены с чистой (стандартной) конфигурацией. В рабочей сети необходимо изучить потенциальное воздействие всех команд до их использования.

Условные обозначения

Дополнительные сведения об условных обозначениях см. в документе Условные обозначения технических терминов Cisco.

Общие сведения

ED является метрикой, используемой в ICM Cisco, Cisco Network Applications Manager (NAM) и среды Контактного центра ip (IPCC).

В общих чертах ED является предсказанной задержкой (в секундах) для любого нового вызова, добавленного к очереди для Сервиса. ED допустим, только если никакие агенты не доступны.

Примечание: Если агенты доступны, ED является нолем.

Minimum Expected Delay (MED) является стандартным правилом выбора, доступным в Выборе, и Маршрут Выбирают узлы Редактора сценариев. �, Если вы выбираете от множественного обслуживания и используете стандартное правило MED, CallRouter, выбирает сервис наименьшим значением для MED (минимум).

Чтобы полностью понять ED, необходимо знать, как вычислен ED.

Примечание: ED является вычислением только для сервиса.

Вы не можете направить с MED к ряду групп умений. Вот стандартная формула ED:

((CallsQNow + 1) * AHTto5) / Max (Agents Talking [OR] Ready)
  • CallsQNow является количеством текущих вызовов в очереди для сервиса в периферийном устройстве.

  • +1 используется для указания на вызов, который может быть потенциально добавлен к очереди.

  • AHTto5 определен как Average Handle Time (в секундах) для вызовов к сервису во время текущего пятиминутного интервала. �AHTto5 является “прокручивающимся” средним значением из пяти минут (с этого времени, и в течение новых пяти минут), и вычислен в режиме реального времени. Значение �The для AHT вычислено как:

    HandleTimeTo5 / CallsHandledTo5

  • HandleTime отслежен только для входящих вызовов ACD, которые посчитаны, как обрабатывается для сервиса. �HandleTime обращается к общему времени, проведенному на вызов. Поэтому HandleTime является продолжительностью общего количества вызовов со времени, агент ответил на вызов на время, агент завершил операции после вызова. �HandleTime включает любой TalkTime, HoldTime, и WorkTime, привязанный к вызову (от Termination_Call_Detail).� значение AvgHandleTime, обновлен в базе данных, когда агент завершает все операции после вызова, привязанные к вызову.

Примечание: Если не было никаких входящих вызовов ACD, обрабатываемых для сервиса во время нового пятиминутного интервала, ICM Cisco использует значение AHT по умолчанию 120 секунд в формуле ED. �You не может настроить это значение AHT по умолчанию. �It трудно кодирован в приложении router.exe.

В знаменателе CallRouter использует или значение AgentsTalking или значение AgentsReady (какой бы ни значение в настоящее время выше).

  • Значение для AgentsTalking является количеством агентов обслуживания в настоящее время в состоянии разговора. Значение AgentsTalking включает все группы умений в сервис (как определено в Service_Member).

  • Значение AgentsReady прибывает из таблицы Skill_Group_Real_Time и включает агентов в Состояние готовности. �Ready является состоянием, в котором в агента входят система, и или на вызове в настоящее время, или вовлечен в операции после вызова, или доступен для обработки нового вызова. �, Как упомянуто ранее, ED предполагает, что никакие агенты не доступны. Значение AgentsReady включает только тех агентов в группы умений, определенные как основных в Service_Member.

Примечание: Некоторые поддержки агента устройством ACD в нескольках квалификационных подгрупп, с другими приоритетами. CallRouter �The рассматривает AgentsReady, и только включает тех агентов, которые являются участниками количества поднавыка ONE (1).

Устраните неполадки ожидаемой задержки

Когда вы понимаете, как ED вычислен, можно устранить неполадки ситуаций где результаты формулы ED в неожиданных значениях. Времена �Many, можно отследить проблему с ED к несоответствию в ICM Cisco и конфигурациях ACD, потому что проблема принадлежит Периферийной службе. �Ensure, что периферийные номера Сервиса и Группы умений корректны, и что информация о Service_Member точна. �Ensure, что агенты зарегистрированы в задействованные группы умений. �If вы используете поднавыки, гарантируете, что агенты зарегистрированы в поднавык количество одно (1).

Если конфигурация точна, разрешите определенные трассировки для установления проблемы.

Экстраполяция

Вот краткое объяснение механизма экстраполяции маршрутизатора. Этот раздел объясняет, почему экстраполяция необходима и как это внедрено.

Пример экстраполяции

Предположите, что простой сценарий маршрутизации пытается сбалансировать нагрузку вызовов, основанных только на количестве вызовов в очереди, и передает вызов к сайту с наименьшим количеством вызовов.

Примечание: Несмотря на то, что данный пример обращается к вызовам в очереди, тот же механизм используется для многих других переменных, перечисленных позже в документе.

  1. Вызов поступает.

  2. Маршрутизатор выбирает сайт и передает вызов.

  3. Сеть отправляет вызов.

  4. ACD видит, что вызов поступает и выполняет внутренний сценарий, который размещает вызов в очереди.

  5. ICM Cisco (через PIM и OPC) замечает вызов и изменение в статистике очереди.

  6. Отчеты ICM Cisco назад к маршрутизатору, где обновлено количество вызовов в очереди.

Все это занимает время для случая. Может потребоваться семь секунд для всех этих шагов для появления. В течение тех семи секунд маршрутизатор все еще думает, что количество вызовов в очереди является исходным значением. Если маршрутизатору дают новый вызов направить, маршрутизатор все еще думает, что тот же сайт является лучшим сайтом. В крупномасштабном приложении можно легко передать десятки вызовов к сайту перед окончательным получением обновленного счетчика запросов от PG. В той точке некоторый другой сайт внезапно выглядит намного лучше, и маршрутизатор передает все вызовы к тому сайту. Явление называют “маршрутизацией по принципу пожарного шланга”.

Это - просто пример. Период времени зависит от сети, ACD или включенного VRMS. Маршрутизатор ограничил информацию для решения этого вопроса. В частности нет никакого пути к маршрутизатору для соответствия с входящими данные от PG с фактическими вызовами, которые направлены. Поэтому нет никакого способа знать, например, какие вызовы включены в метрику вызовов в очереди, когда PG сообщает о счетчике запросов.

Механизм экстраполяции в маршрутизаторе является решением, внедренным в ICM Cisco. Механизм используется, чтобы попытаться оценить действительное значение. Вот то, как экстраполяция работает для переменной как CallsQueueNow для сервиса:

Внутренне, CallsQueueNow управляют в двух частях:

  • Базовая величина CallsQueueNow, которая является значением, о котором в последний раз сообщает PG.

  • Настройка CallsQueueNow, которой управляет маршрутизатор.

Когда ссылочный CallsQueueNow сценария маршрутизации, это видит сумму базовой величины и корректировки. Когда CallsQueueNow передается в оперативном канале AW, только базовая величина передается. Когда вызов направлен к сервису, и затем устанавливает таймер, для управления корректировкой маршрутизатор добавляет 1. Значение по умолчанию для таймера составляет 10 секунд. Когда таймер истекает, маршрутизатор вычитает 1 из корректировки.

Вот пример с фактическим количеством:

Предположите, что существует 3 вызова в очереди:

  1. В запуске, base=3, adjustment=0

  2. Вызов поступает и направлен к сервису, base=3, adjustment=1. Другие вызовы, направленные на этом этапе, видят 3+1=4 вызовы в очереди.

  3. Семь секунд спустя PG сообщает, что существует 4 вызова в очереди. Теперь base=4, adjustment=1 (все еще). Вызовы, направленные на этом этапе, видят завышенное значение 5 вызовов в очереди.

  4. Три секунды спустя 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 отрегулирован/вниз алгоритм и может недооценить количество доступных агентов. LongestAvailable вычислен независимо из списка доступного агента. LongestAvailable может показать агенту, доступному даже при том, что AgentsAvailable указывает на ноль. Поэтому LongestAvailable более точен, как отмечалось ранее.

Установите ожидаемые следы задержки

Ожидаемая Задержка отслеживает значения показа, которые “экстраполируются”, и можно внедрить следы через rttest .

trace_ed N

где N является SkillTargetID сервиса. Эта команда включает след.

trace_ed N /off

Эта команда выключает след.

Когда вы разрешаете эту трассировку, CallRouter помещает записи журнала уровня отладки в окно консоли и в файл журнала .EMS. Dumplog Использования � или утилита просмотра InspectLog для просмотра выходных данных файла журнала. Маршрутизатор �The распечатывает это сообщение:

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 сообщает об изменении).

  • НАЗВАНИЕ (ID) представляет название и ID сервиса.

  • XNN является количеством происходящих экстраполяций. Это - количество вызовов за прошлые 10 секунд.

Вот некоторые Описания кода:

Код Описание
QNN
Вызовы в очереди.
Rnn
Готовые агенты.
Tnn
Агенты, говорящие.
Ann
Доступные агенты.
Hnn
Average Handle Time к 5.
Enn
Ожидаемая задержка.

Существует два набора этих переменных:

  • B = () набор является “основным” набором всех переменных, как сообщается PG, и ED вычислил от них.

  • E () набор является “экстраполируемым” набором, на основе недавно направленных вызовов.

Другие программные средства для устранения проблем ожидаемой задержки

Можно использовать функцию Данных реального времени Показа Редактора сценариев для устранения проблем Медианы ¦ю¦¿¦½It, важно, чтобы знать, что данные, отображенные в Редакторе сценариев, могут быть столь же старыми как пятнадцать секунд или больше, и часто только отображает базовые величины, а не экстраполируемые значения.

Посмотрите на данные в режиме реального времени, чтобы устранить неполадки Ed ¦ю¦¿¦½For это, использовать команду dump_vars из rttest, просмотреть различные значения и переменные, которые знает CallRouter.

Rttest: dump_vars /?

Примечание: Значения, которые перечислены, могут экстраполироваться.

Пример синтаксиса

В rrtest работайте:

dump_vars /service <Service.SkillTargetID>

или

dump_vars /group <Skill_Group.SkillTargetID>

Можно определить SkillTargetID через ISQL/W или Быструю функцию Запроса, найденную в Программе предоставления справочной информации Схемы.

При вводе собственного значения для SkillTargetID Сервиса или Группы умений rttest отображает список имен переменной (например, AgentsAvailable и AgentsReady) и столбец со значением каждой переменной. �Usually, значение является положительным положительным, и очевидный. �-1 указывает, что значение неопределено.

Когда вы устраняете неполадки, сравниваете значения, замеченные в rttest, dump_vars с доступной информацией от ACD.� при сравнении данных ищите возможную неоднородность, которая может быть причиной проблемы.

Некоторые Специалисты службы поддержки Клиента Cisco (CSE) также имели успех с командой часов в rttest. Команда часов �The позволяет вам оценить любое применяемое выражение. � команда часов является самой полезной для устранения проблем пользовательских формул (например, пользовательские вычисления “ExpectedDelay”).�If вы, изменяют значение (я) выражения, CallRouter сразу включает запись в окно процесса маршрутизатора (и в файл .ems) с текущим значением.

Вот то, как необходимо выполнить команду часов:

rttest: watch <expression>

где:

  • “Выражение” является любым допустимым выражением, например:

    rttest: watch Service.Boston_Aspect.Support.AgentsReady 
    Watch 0 added.
  • Можно демонтировать часы через/, удаляют коммутатор, например:

    rttest: watch 0 /delete

Opctest и procmon также имеют различные подпрограммы, которые позволяют вам перечислять агентов и вызовы. �Cross-reference эти значения с тем, что вы знаете о ACD и CallRouter. Ищите возможную неоднородность, которая может быть причиной проблемы.

Если вы недавно установили ICM Cisco, и вы переводите новый сервис в рабочее состояние впервые, MED может отличаться от того, что вы ожидаете. Времена �Many, MED является другим из-за одной из этих причин:

  • Эффекты экстраполяции.

  • Никакие вызовы не обрабатываются (по умолчанию составляет 120 секунд для AHT и не может ожидаться).

  • Немного вызовов происходят или в очереди.

Когда существует много элементов к среднему числу, ED является самым точным. �When больше агентов доступно в задействованных группах умений и большем количестве вызовов, обрабатываются, результаты MED лучше.

Связанные обсуждения сообщества поддержки Cisco

В рамках сообщества поддержки Cisco можно задавать и отвечать на вопросы, обмениваться рекомендациями и совместно работать со своими коллегами.


Дополнительные сведения