Приложение Diameter Credit-Control — это сетевой протокол для приложения Diameter , используемый для реализации контроля кредитов в реальном времени для различных услуг конечных пользователей.
Это стандарт IETF, впервые определенный в RFC 4006 и обновленный в RFC 8506.
Целью приложения Diameter Credit Control является предоставление структуры для взимания платы в режиме реального времени, в первую очередь предназначенной для связи между шлюзами/контрольными точками и внутренними системами учета/баланса (обычно это система онлайн-взимания платы ).
В заявке указаны методы для:
Приложение Diameter Credit Control не определяет, какие типы единиц покупаются/используются и какие элементы оплачиваются. Это остается в контексте обслуживания, который должен быть указан отдельно, как и часть семантики.
Примеры использованных/купленных единиц:
Примеры взимаемых сборов:
Кредитный контроль Diameter также определяет, как справиться с довольно сложной проблемой использования/начисления нескольких типов единиц с одного баланса пользователя. Например, пользователь может платить как за онлайн-время, так и за байты загрузки, но иметь только один баланс счета.
Процесс контроля кредита на основе сеанса использует несколько опросов, которые могут включать первый, промежуточный и последний опрос. Во время опроса деньги резервируются со счета пользователя. Тарификация на основе сеанса обычно используется для сценариев, где тарифицируемые единицы расходуются непрерывно, например, тарификация за загрузку/выгрузку байтов.
Процесс управления кредитом на основе событий использует события как механизм тарификации. Тарификация на основе событий обычно используется, когда единицы не потребляются непрерывно, например, пользователь отправляет MMS.
Для поддержки контроля кредита через Diameter существуют два сообщения Diameter: CCR (запрос контроля кредита) и CCA (ответ контроля кредита). Код команды для CCR/CCA — 272, как определено в RFC 4006
Для управления квотами клиент отправляет CCR на сервер, запрашивая единицы и сообщая о потреблении. Сервер предоставляет единицы и взимает плату с пользователя. Для простого дебета/кредита клиент отправляет CCR, запрашивая сервер о кредитовании/дебетовании счета пользователя. Для запросов цен клиент запрашивает у сервера цену единицы, и сервер отвечает ценой.
Потоки сообщений в целом управляются контрольной точкой, запрашивающей единицы, и сервером, предоставляющим их. Сообщение также может быть сгенерировано другими приложениями Diameter, такими как NASREQ (RFC4005) для сеансов, которые ограничены по времени/использованию.
На следующей диаграмме показан упрощенный поток сообщений для сеанса с использованием квот.
Клиент начинает с запроса 10 единиц с сервера. Сервер проверяет, что у пользователя/подписчика достаточно баланса для этого. В этом примере сервер предоставляет клиенту все запрошенные им единицы. Если бы у подписчика было недостаточно баланса, он мог бы предоставить меньше единиц или полностью отклонить его.
Когда или до того, как сеанс подписчика использовал предоставленные единицы, клиент отправляет обновление на сервер, сообщая ему, сколько единиц было использовано и сколько он хотел бы получить на этот раз. Клиенту разрешено запрашивать единицы до того, как предыдущий грант будет полностью использован, чтобы избежать приостановки сеанса подписчика во время разговора с сервером. В этом примере клиент отправляет запрос, когда было использовано 7 единиц из 10 ранее предоставленных единиц; и запрашивает еще 10 единиц, которые сервер предоставляет. Сервер может использовать количество использованных единиц для списания баланса подписчика (предоставление единиц не означает, что они будут использованы. AVP использованных единиц содержит фактическое использование). Сервер также может сообщить клиенту, как долго действует грант, и в этом случае ожидается, что клиент отправит обновление по истечении таймера гранта.
Во время сеанса может быть много сообщений об обновлениях.
Наконец, подписчик завершил сеанс, и клиент отправляет сообщение о завершении на сервер, содержащее последние Used-Units. Сервер может использовать сообщение о завершении для очистки любых связанных резервирований, сделанных в системе управления балансом на внутреннем сервере. Если бы подписчик не завершил сеанс сам, а вместо этого исчерпал свой баланс, то сервер ответил бы ранее с отклонением на сообщение об обновлении, возможно, указав клиенту/контрольной точке перенаправить трафик (обычно это имеет смысл только для трафика HTTP / WAP ).
Новые коды команд, CCA и CCR, могут потребовать некоторые AVP, как указано ниже. Жирные AVP являются новыми для DCCA.
В таблице используются следующие символы: