Беспроводные сети : Cisco ASR серии 5000

Настройте обрабатывающие сбой и недостижимые сервером механизмы для разрешения сбоя OCS на ASR5K

20 октября 2016 - Машинный перевод
Другие версии: PDF-версия:pdf | Английский (21 апреля 2016) | Отзыв

Введение

Этот документ описывает, как настроить Обработку сбоя (FH) и механизмы Server-Unreachable (SU) на интерфейсе Gy для решения вопросов, с которыми встречаются на Онлайновой тарификационной системе (OCS) или в отношении подключения между Функцией Осуществления Политики и Зарядки (PCEF) и OCS. Информация, которая описана в этом документе, применима к Home Agent (HA),   Узел поддержки General Packet Radio Service (GPRS) шлюза (GGSN) и Пакетная сеть передачи данных шлюз (PGW) функциональность, которая работает на Cisco маршрутизатор (ASR5K) Aggregated Services серии 5000.

Внесенный Shashank Varshney, специалистом службы технической поддержки Cisco.

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

Требования

Cisco рекомендует, чтобы ваша система удовлетворила эти требования для использования механизмов SU и FH:

  • Улучшенное заряженное обслуживание (ECS) доступно

  • PCEF существует в HA, GGSN или PGW

  • Существует надлежащее подключение диаметра через диабаз

  • Приложение кредитного контроля диаметра (DCCA) доступно

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

Сведения в этом документе основываются на всех версиях ASR5K.

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

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

PCEF связан с OCS по интерфейсу Gy, который использует Диаметр в качестве основного протокола и DCCA. Это - поток сообщений между PCEF и OCS:

  • Запрос кредитного контроля (CCR) – Это сообщение передается от PCEF до OCS. Существует три типа сообщений CCR: Начальная буква, Обновление, и Оконечный.

  • Ответ кредитного контроля (CCA) – Это сообщение передается от OCS до PCEF в ответ на CCR. Существует также три типа сообщений CCA: Начальная буква, Обновление, и Оконечный.

  • Когда переавторизация сеанса требуется, перезапрос авторизации (RAR) – Это сообщение передается от OCS до PCEF.

  • Ответ переавторизации (RAA) – Это - ответ на RAR от PCEF до OCS.

Подключение диаметра установлено между PCEF и OCS для включения потока сообщений. Существует возможность, что OCS мог бы передать отрицательные сообщения, транспортное соединение могло бы отказать между PCEF и OCS, или сообщение могло бы таймаут, который может вызвать сбой в установке сеанса абонента. Это может предотвратить абонента от использования сервисов.

Эти два механизма могут использоваться для решения этого вопроса:

  • Механизм FH

  • Механизм SU

Настройка

В этом разделе описываются конфигурации, которые требуются для поддержки механизмов SU и FH.

Схема сети

Сведения в этом документе используют эту топологию:

Истечение tx

Это - таймер уровня приложения для DCCA, который конфигурируем в параметрах настройки кредитного контроля диаметра. Значение может расположиться между 1 и 300 секундами.

Например:

[local]host_name(config-dcca)# diameter pending-timeout <value>

Тайм-аут ответа/b>

Это - таймаут диабаза и конфигурируемо в параметрах настройки Оконечной точки Диаметра. Значение может расположиться между 1 и 300 секундами.

Примечание: Значение, которое настроено для этого таймера, должно быть больше, чем используемый для Окончания отсчета таймера tx.

Например:

[context_name]host_name(config-ctx-diameter)# response-timeout <value>

Аварийное переключение сеанса диаметра

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

Например:

local]host_name(config-dcca)# diameter session failover

Механизм FH

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

Примечание: FH включен и настроен по умолчанию.

Конфигурация механизма FH

Механизм FH может быть настроен в параметрах настройки кредитного контроля диаметра. Вот синтаксис, который используется в конфигурации FH:

failure-handling { initial-request | terminate-request | update-request } { continue
[ go-offline-after-tx-expiry | retry-after-tx-expiry ] | retry-and-terminate,
[ retry-after-tx-expiry ] | terminate }

Первый раздел задает тип запроса: Начальная буква (CCR-I), Обновление (CCR-U), и Оконечный (CCR-T).

Второй раздел задает действие, которое должно быть выполнено, когда активирован механизм FH. Эти три действия возможны с механизмом FH:

  • Continue – Это позволяет сеансу продолжаться и преобразовывает его в оффлайн. Эта функция использует две опции, которые отнесены к истечению Tx:

    • Go-offline-after-tx-expiry – Это начинает оффлайн заряжать после того, как произойдет истечение Tx.

    • Retry-after-tx-expiry – Это повторяет дополнительный сервер после того, как произойдет истечение Tx.

  • Повторять-и-завершать – Это завершает сеанс после того, как система повторяет дополнительный сервер, если дополнительный сервер не доступен также. Это также использует Retry-after-tx-expiry опцию, которая повторяет дополнительный сервер после того, как происходит истечение Tx.

  • Оконечный – Это завершает сеанс без любых попыток связаться с дополнительным сервером.

Поведение по умолчанию механизма FH

Когда никакая конфигурация не присутствует, этот раздел описывает поведение по умолчанию FH. По умолчанию механизм FH активирован во время Времени ожидания ответа (RT), кроме тех случаев, когда настроено Оконечное действие.

Если Credit-Control-Failure-Handling Пара значений атрибутов (AVP) получена от сервера, то полученные параметры настройки применены.

Приведем несколько примеров:

  • Исходный запрос> Оконечный

  • Запрос обновления> Повторять-и-завершать

  • Terminate-Request> Повторять-и-завершать

Механизм FH подробный поток вызовов

В этом разделе описываются подробный поток вызовов механизма FH со всеми возможными вариантами.

Исходный запрос

Значение CCFHКоманда CLIПоведение в TxПоведение в RTВторичный подключенВторичный не работает

Continue

исходный запрос
continue

Н/Д

Continue

Вспомогательный
вступает во владение после
RT

Оффлайн после другого RT.
Больше запросов квоты не выполнено
для любой группы оценки в сеансе
после сбоя DCCA (даже если
подключение к DCCA восстановлено),

исходный запрос
продолжите go-offline-after-
истечение tx

Оффлайн

Н/Д

Оффлайн в Tx

Оффлайн в Tx

исходный запрос
продолжите retry-after-
истечение tx

Continue

Н/Д

Вспомогательный
вступает во владение после
Tx

Оффлайн после другого Tx

Повторять-и-завершать

исходный запрос
повторять-и-завершать

Н/Д

Повторить

Вспомогательный
вступает во владение после
RT

Оконечный после другого RT

исходный запрос
повторять-и-завершать
retry-after-tx-expiry

Повторить

Н/Д

Вспомогательный
вступает во владение после
Tx

Оконечный после другого Tx

Оконечный

исходный запрос
оконечный

Оконечный

Н/Д

Оконечный после Tx

Оконечный после Tx

Запрос обновления

Значение CCFHКоманда CLIПоведение в TxПоведение в RTВторичный подключенВторичный не работает

Continue

запрос обновления
continue

Н/Д

Continue

Вспомогательный
вступает во владение после
RT

Оффлайн после другого RT

запрос обновления
продолжите go-offline-after-
истечение tx

Оффлайн

Н/Д

Оффлайн в Tx

Оффлайн в Tx

запрос обновления
продолжите retry-after-
истечение tx

Continue

Н/Д

Вспомогательный
вступает во владение после
Tx

Оффлайн после другого Tx

Повторять-и-завершать

запрос обновления
повторять-и-завершать

Н/Д

Повторить

Вспомогательный
вступает во владение после
RT

Передает CCR-T после другого RT

запрос обновления
повторять-и-завершать
retry-after-tx-expiry

Повторить

Н/Д

Вспомогательный
вступает во владение после
Tx

Передает CCR-T после другого Tx

Оконечный

запрос обновления
оконечный

Оконечный

Н/Д

Передает CCR-T после Tx

Передает CCR-T после Tx

Terminate-Request

Значение CCFHКоманда CLIПоведение в TxПоведение в RTВторичный подключенВторичный не работает

Continue

оконечный запрос
continue

Н/Д

Повторить

CCR-T передается
к вторичному устройству
после RT

Оконечный после другого RT

оконечный запрос
продолжите go-offline-after-
истечение tx

Повторить

Н/Д

CCR-T передается
к вторичному устройству
после Tx

Оконечный после другого Tx

оконечный запрос
продолжите retry-after-
истечение tx

Повторить

Н/Д

CCR-T передается
к вторичному устройству
после Tx

Оконечный после другого Tx

Повторять-и-завершать

оконечный запрос
повторять-и-завершать

Н/Д

Повторить

CCR-T передается
к вторичному устройству
после RT

Оконечный после другого RT

оконечный запрос
повторять-и-завершать
retry-after-tx-expiry

Повторить

Н/Д

CCR-T передается
к вторичному устройству
после Tx

Оконечный после другого Tx

Оконечный

оконечный запрос
оконечный

Оконечный

Н/Д

Оконечный после
Tx

Оконечный после Tx

Механизм SU

Механизм SU подобен механизм FH, но это предоставляет более тонкую настройку по процедурам сбоя. Когда ответы медленные от OCS, в дополнение к продолжению сеанса после сообщения - и уровень соединения (транспорт) сбои, может использоваться этот механизм. Это также предоставляет возможности или продолжать сеанс в течение некоторого времени исчерпание продолжительности/квоты перед завершением или использовать конфигурируемую промежуточную квоту (громкость и время) и конфигурируемые повторные попытки сервера, прежде чем сеанс будет преобразован в офлайновый или завершенный. 

Конфигурация механизма SU

Механизм SU может быть настроен в параметрах настройки кредитного контроля диаметра. Синтаксис, который используется в конфигурации SU, варьируется в соответствии с версией, которая используется.

Для Версий 12.1 и ранее, это - синтаксис, который используется для конфигурации механизма SU:

servers-unreachable { initial-request { continue | terminate [ after-timer-expiry
<
timeout_period> ] } | update-request { continue | terminate [ after-quota-expiry
| aftertimer-expiry <
timeout_period> ] } }

Для Версий 12.2 и позже, это - синтаксис, который используется для конфигурации механизма SU:

servers-unreachable { behavior-triggers { initial-request | update-request }
result-code { any-error | <
result-code> [ to <end-result-code> ] }
| transport-failure [ response-timeout | tx-expiry ] | initial-request
{ continue [ { [ after-interim-time <
timeout_period> ] [ after-interim-volume
<
quota_value> ] } server-retries <retry_count> ] | terminate [ {
[ after-interim-time <
timeout_period> ] [ after-interim-volume <quota_value> ]
} server-retries <
retry_count> | after-timer-expiry <timeout_period> ] }
| update-request { continue [ { [ after-interim-time <
timeout_period> ]
[ after-interim-volume <
quota_value> ] } server-retries <retry_count> ]
| terminate [ { [ after-interim-time <
timeout_period> ] [ after-interim-volume
<
quota_value> ] } server-retries <retry_count> ] | after-quota-expiry |
after-timer-expiry <
timeout_period> ] } }

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

Если сервер возвращает AVP FH CC, и механизм SU настроен для ряда триггеров поведения, то конфигурация SU применена; иначе, значение AVP FH CC применено. По умолчанию результирующие коды такой как 3002, 3004, и 3005 подпадают под ошибку отправки и рассматриваются как СИГНАЛ RTS.

Эти действия возможны с механизмом SU:

  • Триггер поведения – Это задает тип сообщений, которые могут быть Исходными запросами (CCR-I) или Запросы Обновления (CCR-U). Существует три опции, доступные для этих триггеров:

    • Результирующий код – Это позволяет конфигурацию определенных результирующих кодов, диапазон результирующих кодов (3000-5999) или любую ошибку наряду с типом сообщения.

    • Транспортный сбой – Эта спецификация инициирует поведение после транспортного сбоя, который назад совместим с Версией 12.0. Существует две опции, доступные для этой установки:

      • Тайм-аут ответа/b> Эта опция инициирует поведение на RT и должна всегда использоваться с транспортными сбоями.

      • Истечение tx – Эта опция инициирует поведение после истечения Tx и должна всегда использоваться с транспортным сбоем.

    • Действия – Это задает действие, которое выполнено, когда происходит триггер SU для CCR-I или CCR-U. Это действие варьируется в соответствии с типом сообщения и версией программного обеспечения.

  • Continue – Это позволяет сеансу быть преобразованным в офлайновый и продолжаться. Нет никаких дальнейших опций, доступных для использования этого действия в версиях до Версии 12.2. В Версиях 12.2 и позже, промежуточная квота, повторные попытки сервера и опции после-того,-как-истечения-срока-действия-таймера доступны для конфигурации с этим действием.

  • Когда сервер становится недостижимым, оконечный – Это приводит к завершению сеанса. Это действие позволяет промежуточную квоту, повторные попытки сервера и опции после-того,-как-истечения-срока-действия-таймера.

Эти опции могут использоваться с Продолжением или Оконечным действием:

    • After-interim-time – Эта опция позволяет продолжительность или завершение вызова после промежуточного периода ожидания. Это подобно квоте времени, прежде чем будет выполнено действие. Значение отформатировано в секундах и может расположиться между 1 и 4,294,967,295.

    • After-interim-volume – Эта опция назначает промежуточную квоту и позволяет продолжительность или завершение сеанса перед исчерпанием настроенной громкости. Значение отформатировано в байтах и может расположиться между 1 и 4,294,967,295.

    • Повторные попытки сервера – Эта опция позволяет PCEF повторять OCS перед продолжительностью или завершением сеанса. Число повторов может быть настроено, и диапазоны значений между 0 и 65,535. Если значение является нулем, то повторная попытка не происходит, и действие сразу применено.

Примечание: after-interim-time и after-interim-volume опции всегда используются с опцией повторных попыток сервера, или все три могут использоваться одновременно и применяться к и продолжить и завершить действия. after-interim-time и after-interim-volume опции также назначают время, а также квоту громкости и квоту, которая исчерпана первые триггеры повторная попытка сервера.

  • После-того,-как-истечение-срока-действия-таймера – Эта опция задает продолжительность времени (в секундах), для которого сеансы остаются в автономном состоянии, прежде чем произойдет завершение. Значения могут расположиться между 1 и 4,294,967,295. Эта опция только применима для оконечных действий.

  • After-quota-expiry – Эта опция завершает сеанс после исчерпания уже назначенной квоты.

Вот немного важной информации для запоминания:

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

  • after-quota-expiry опция только применима для триггера поведения Запросов Обновления.

  • Опция после-того,-как-истечения-срока-действия-таймера только применима для оконечного действия.

  • after-interim-time, after-interim-volume, и опции повторных попыток сервера только применимы для Версий 12.2 и позже.

  • Если аварийное переключение сеанса диаметра поддерживается (и настроенный), то с дополнительным сервером всегда связываются, прежде чем механизм SU инициирован.

  • Сервер, с которым связались в последний раз перед механизмом SU, инициирован, всегда связывается, когда промежуточное время или промежуточная громкость исчерпаны, и опция повторных попыток сервера настроена со значением, которое больше, чем нуль. Например, если OCS1 пробуют сначала, и OCS2 пробуют после ошибки в OCS1, то связь с OCS2 инициирует механизм SU. Если отрицательный ответ получен от OCS2, во время попытки повторной попытки сервера с OCS2 связываются сначала и затем OCS1.

Диаграммы вызовов механизма SU

Механизм SU может быть инициирован сбоем CCR-I или CCR-U, и причиной может быть код ошибки, транспортный сбой, истечение Tx или RT. Действие может быть выделением промежуточной квоты (время, и/или громкость), количество повторных попыток сервера, значение таймера (заставляет сеанс идти оффлайн в течение заданного времени и только для завершения), или истечение квоты (только для CCR-U и завершения), прежде чем сеанс пойдет оффлайн или завершится.

Промежуточная квота предоставлена на для каждого сеанса основание, не Группа на оценку (RG) основание в сценариях Кредитного контроля множественного обслуживания (MSCC).

Существует возможность, что триггерный сбой транспорта основного сервера и дополнительный сервер инициируют истечение Tx или response-timeout. В этом сценарии последняя ошибка, как полагают, является триггером сбоя.

Если механизм SU не настроен ни для какого триггера сбоя, то механизм FH инициирован.

Примечание: Разделы, которые придерживаются, предоставляют некоторые примеры потока вызовов, которые отнесены к механизму SU. Эти диаграммы вызовов предоставлены под предположением, что аварийное переключение сеанса диаметра поддерживается, и дополнительный сервер настроен со значением истечения Tx, которое является меньше, чем значение RT. Кроме того, предполагается, что механизм SU настроен для транспортного сбоя, истечения Tx и RT.

Исходный запрос без разъединения сеанса

Вот поток сообщений для этого сценария:

  1. PCEF передает CCR-I к OCS.

  2. Таймаут или транспортный сбой обнаружены. Если транспортный сбой обнаружен, то PCEF сразу повторяет с дополнительным сервером; иначе, истечение Tx инициировано.

  3. Если дополнительный сервер также имеет транспортный сбой или таймаут, то механизм SU инициирован. Это сразу происходит для транспортных сбоев, или после истечения Tx для таймаута.

  4. Если промежуточная громкость и/или время настроена, то промежуточная квота назначена на сеанс.

  5. После исчерпания промежуточной квоты (время или громкость) и если значение повторных попыток сервера больше, чем нуль, то CCR-I снова передается серверу, который инициировал механизм SU. Если существует другой сбой, CCR-I передается другому серверу.

  6. Если транспортный сбой или Tx-timeout снова обнаружены, то Шаги 2 - 5 повторены, пока значение повторных попыток сервера не исчерпано, или успешный ответ не прибывает из OCS.

  7. Если проблема все еще существует, то сеанс продолжен (преобразованный в офлайновый) или завершился согласно конфигурации.

Примечание: О промежуточной квоте, которая использована, в то время как сеанс входит в режим SU из-за CCR-I, не сообщают в следующем CCR-I. Обо всей используемой промежуточной квоте сообщают в CCR-U, который придерживается успешного CCA-I.

Исходный запрос с разъединением сеанса

Вот поток сообщений для этого сценария:

  1. PCEF передает CCR-I к OCS.

  2. Таймаут или транспортный сбой обнаружены. Если транспортный сбой обнаружен, то PCEF сразу повторяет с дополнительным сервером; иначе, истечение Tx инициировано.

  3. Если дополнительный сервер также имеет транспортный сбой или таймаут, то механизм SU инициирован. Это сразу происходит для транспортных сбоев, или после истечения Tx для таймаута.

  4. Если промежуточная громкость и/или время настроена, то промежуточная квота назначена на сеанс.

  5. После исчерпания промежуточной квоты (время или громкость) и если значение повторных попыток сервера больше, чем нуль, то CCR-I снова передается серверу, который инициировал механизм SU. Если существует другой сбой, CCR-I передается другому серверу.

  6. Если транспортный сбой или Tx-timeout снова обнаружены, то Шаги 2 - 5 повторены, пока значение повторных попыток сервера не исчерпано, или успешный ответ не прибывает из OCS. На этом этапе сеанс разъединен без потребления всей промежуточной квоты.

  7. После завершения сеанса PCEF снова передает CCR-I для начала нового сеанса. Если это успешно, то PCEF передает CCR-T, который сообщает о целой временной квоте, которая использовалась.

Запрос обновления без разъединения сеанса

Вот поток сообщений для этого сценария:

  1. PCEF передает CCR-U к OCS.

  2. Таймаут или транспортный сбой обнаружены. Если транспортный сбой обнаружен, то PCEF сразу повторяет с дополнительным сервером; иначе, истечение Tx инициировано.

  3. Если дополнительный сервер также имеет транспортный сбой или таймаут, то механизм SU инициирован. Это сразу происходит для транспортных сбоев, или после истечения Tx для таймаута.

  4. Если промежуточная громкость и/или время настроена, то промежуточная квота назначена на сеанс.

  5. После исчерпания промежуточной квоты (время или громкость) и если значение повторных попыток сервера больше, чем нуль, то CCR-U снова передается серверу, который инициировал механизм SU. Если существует другой сбой, CCR-U передается другому серверу, который содержит всю использованную квоту, о которой не сообщают.

  6. Если транспортный сбой или Tx-timeout снова обнаружены, то Шаги 2 - 5 повторены, пока значение повторных попыток сервера не исчерпано, или успешный ответ не прибывает из OCS.

  7. Обо всей использованной квоте сообщают OCS с успешным CCR-U.

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

Запрос обновления с разъединением сеанса

Вот поток сообщений для этого сценария:

  1. PCEF передает CCR-U к OCS.

  2. Таймаут или транспортный сбой обнаружены. Если транспортный сбой обнаружен, то PCEF сразу повторяет с дополнительным сервером; иначе, истечение Tx инициировано.

  3. Если дополнительный сервер также имеет транспортный сбой или таймаут, то механизм SU инициирован. Это сразу происходит для транспортных сбоев, или после истечения Tx для таймаута.

  4. Если промежуточная громкость и/или время настроена, то промежуточная квота назначена на сеанс.

  5. После исчерпания промежуточной квоты (время или громкость) и если значение повторных попыток сервера больше, чем нуль, то CCR-U снова передается серверу, который инициировал механизм SU. Если существует другой сбой, CCR-U передается другому серверу, который содержит всю использованную квоту, о которой не сообщают.

  6. Если транспортный сбой или Tx-timeout снова обнаружены, то Шаги 2 - 5 повторены, пока значение повторных попыток сервера не исчерпано, или успешный ответ не прибывает из OCS. На этом этапе сеанс разъединен, прежде чем он использует всю временную квоту.

  7. PCEF передает CCR-T к OCS для создания отчетов обо всей использованной квоте.

  8. Если OCS отвечает результирующим кодом 2002 года, то дополнительные отчёты не необходимы.

Запрос обновления с неизвестным сеансом

Вот поток сообщений для этого сценария:

  1. PCEF передает CCR-U к OCS.

  2. Таймаут или транспортный сбой обнаружены. Если транспортный сбой обнаружен, то PCEF сразу повторяет с дополнительным сервером; иначе, истечение Tx инициировано.

  3. Если дополнительный сервер также имеет транспортный сбой или таймаут, то механизм SU инициирован. Это сразу происходит для транспортных сбоев, или после истечения Tx для таймаута.

  4. Если промежуточная громкость и/или время настроена, то промежуточная квота назначена на сеанс.

  5. После исчерпания промежуточной квоты (время или громкость) и если значение повторных попыток сервера больше, чем нуль, то CCR-U снова передается серверу, который инициировал механизм SU. Если существует другой сбой, CCR-U передается другому серверу, который содержит всю использованную квоту, о которой не сообщают.

  6. OCS отвечает с 5002 (неизвестный идентификатор сеанса) результирующему коду для CCR-U, который возможен в сценарии, где OCS перезапустил и потерял информацию об идентификаторе сеанса.

  7. PCEF инициирует новый сеанс с CCR-I и получает CCA-I.

  8. PCEF сообщает обо всей использованной промежуточной квоте через CCR-U в последующих сообщениях.

Запрос обновления со множественным RGs (сценарий MSCC)

Вот поток сообщений для этого сценария:

  1. PCEF передает CCR-U за RG1 к OCS.

  2. Таймаут или транспортный сбой обнаружены. Если транспортный сбой обнаружен, то PCEF сразу повторяет с дополнительным сервером; иначе, истечение Tx инициировано.

  3. Если дополнительный сервер также имеет транспортный сбой или таймаут, то механизм SU инициирован. Это сразу происходит для транспортных сбоев, или после истечения Tx для таймаута.

  4. Если промежуточная громкость и/или время настроена, то промежуточная квота назначена на сеанс

  5. На этом этапе RG2 также исчерпывает всю назначенную квоту, но не инициирует CCR-U, потому что сеанс уже находится в режиме SU и начинает использовать промежуточную квоту.

  6. После исчерпания промежуточной квоты (время или громкость) и если значение повторных попыток сервера больше, чем нуль, то CCR-U снова передается серверу, который инициировал механизм SU. Если существует другой сбой, CCR-U передается другому серверу, который содержит всю использованную квоту, о которой не сообщают, для обоих RGs.

  7. Если транспортный сбой или Tx-timeout снова обнаружены, то Шаги 2 - 6 повторены, пока значение повторных попыток сервера не исчерпано, или успешный ответ не прибывает из OCS.

  8. Обо всей использованной квоте сообщают OCS с успешным CCR-U.

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

Terminate-Request

Вот поток сообщений для этого сценария:

  1. PCEF передает CCR-T к OCS.

  2. Таймаут или транспортный сбой обнаружены. Если транспортный сбой обнаружен, то PCEF сразу повторяет с дополнительным сервером; иначе, истечение Tx инициировано.

  3. Если дополнительный сервер также имеет транспортный сбой или таймаут, то сеанс удален.

Обработка кода ошибки CCR

Вот поток сообщений для этого сценария:

  1. PCEF передают CCR к OCS и ответы OCS с кодом ошибки.

  2. Код ошибки статически настроен в механизме SU.

  3. PCEF предоставляет промежуточную квоту без повторной попытки к дополнительному серверу.

FH и примеры конфигурации SU

Этот раздел предоставляет пример конфигурации для механизмов SU и FH. Когда и FH и механизмы SU настроены, SU имеет приоритет по FH для того же триггера поведения.

Например:

credit-control group test

diameter origin endpoint test

diameter peer-select peer test

quota volume-threshold percent 10

diameter pending-timeout 80 deciseconds msg-type any

diameter session failover

trigger type rat lac

apn-name-to-be-included virtual

quota request-trigger exclude-packet-causing-trigger

failure-handling initial-request continue retry-after-tx-expiry

servers-unreachable initial-request terminate after-interim-volume 200
after-interim-time 3600 server-retries 0

servers-unreachable behavior-triggers initial-request transport-failure
tx-expiry

servers-unreachable update-request continue after-interim-volume 200
after-interim-time 3600 server-retries 50

servers-unreachable behavior-triggers update-request transport-failure
tx-expiry

Проверка

Чтобы проверить, что ваша конфигурация работает должным образом, введите активную зарядку показа сервисная команда <service name>:

# show active-charging service name test



Service name: test



TCP Flow Idle Timeout : 300 (secs)

UDP Flow Idle Timeout : 300 (secs)

ICMP Flow Idle Timeout : 300 (secs)

ICMP Flow Idle Timeout : 300 (secs)

ALG Media Idle Timeout : 120 (secs)



TCP Flow-Mapping Idle Timeout : 300 (secs)

UDP Flow-Mapping Idle Timeout : Not Configured



Deep Packet Inspection: Enabled

Passive Mode : Disabled

CDR Flow Control : Enabled

CDR Flow Control Unsent Queue Size: 75

Unsent Queue high watermark: 56

Unsent Queue low watermark: 18



Content Filtering: Disabled



Dynamic Content Filtering: Disabled



URL-Blacklisting: Disabled

URL-Blacklisting Match-method: Exact



Content Filtering Match-method: Generic





Interpretation of Charging-rule-base-name: active-charging-group-of-ruledefs





Selection of Charging-rule-base AVP : Last



Credit Control:

Group : test



Mode : diameter

APN-name-to-be-included: gn

Trigger-Type : N/A



Failure-Handling:

Initial-Request : continue retry-after-tx-expiry

Update-Request : retry-and-terminate

Terminate-Request: retry-and-terminate



Server Unreachable Failure-Handling:

Initial-Request : terminate

Update-Request : continue

Устранение неполадок

Введите команду statistics кредитного контроля активной зарядки показа для просмотра статистических данных, которые отнесены к механизмам FH и SU. Ниже приведен пример выходных данных:

#show active-charging credit-control statistics
...

OCS Unreachable Stats:

Tx-Expiry: 2291985 Response-TimeOut: 615

Connection-Failure: 2 Action-Continue: 0

Action-Terminated: 0 Server Retries: 2023700



Assumed-Positive Sessions:

Current: 2 Cumulative: 2196851

Вот некоторые важные замечания о выходных данных данного примера:

  • Истечение tx – Это указывает на условие SU из-за истечения Tx.

  • Тайм-аут ответа/b> Это указывает на условие SU из-за RT.

  • Ошибка подключения – Это указывает на условие SU из-за транспортного сбоя.

  • Action-Continue – Это поле указывает на количество сеансов, которые пошли оффлайн.

  • Оконечный действием – Это поле указывает на количество сеансов, которые были завершены.

  • Повторные попытки сервера – Это поле указывает на число раз, что был повторен OCS.

  • Принятый - положительные сеансы:

    • Текущий – Это поле указывает на количество сеансов, которые в настоящее время находятся в условии SU.

    • Кумулятивный – Это поле указывает на общее число сеансов, которые переместились в статус SU.

Введите сеансы активной зарядки показа, полные вся команда для просмотра информации, которая отнесена к состоянию SU сеанса. Ниже приведен пример выходных данных:

#show active-charging sessions full all
..
..

Current Server Unreachable State: CCR-I

Interim Volume in Bytes (used / allotted): 84/ 200

Interim Time in Seconds (used / allotted): 80/ 3600

Server Retries (attempted / configured): 1/ 50

Вот некоторые важные замечания о выходных данных данного примера:

  • Текущий сервер Недостижимое Состояние – Это задает, является ли текущее состояние SU из-за CCR-I или CCR-U.

  • Промежуточная Громкость в Байтах (использовала/выделяла) – Это показывает промежуточную громкость в байтах, используемых по сравнению с выделенными байтами.

  • Промежуточное Время в Секундах (использовало/выделяло) – Это показывает промежуточную громкость в секундах, используемых по сравнению с выделенными секундами.

  • Повторные попытки сервера (делали попытку/настраивали) – Это - количество повторных попыток сервера, предпринятых по сравнению с настроенным.

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



Document ID: 118993