Заявление о кредитном контроле диаметра
Приложение Diameter Credit-Control — это сетевой протокол для приложения Diameter, используемый для внедрить кредитный контроль в режиме реального времени для различных услуг для конечных пользователей.
Это стандарт IETF, впервые определенный в RFC 4006 и обновленный в RFC 8506.
Цель
[ редактировать ]Целью приложения контроля кредита диаметра является обеспечение структуры для взимания платы в режиме реального времени, в первую очередь предназначенной для связи между шлюзами/точками управления и внутренними системами учета/баланса (обычно системой онлайн-взимания платы ).
Приложение определяет методы для:
- Управление квотами (резервировать, повторно авторизовать, отказаться)
- Простой дебет/кредит
- Проверка баланса
- Ценовые запросы
Приложение контроля кредита диаметра не указывает, какие типы единиц покупаются/используются и за какие позиции взимается плата. Это оставлено на усмотрение контекста службы, который должен быть указан отдельно, как и некоторая семантика.
Примеры использованных/купленных единиц:
- Время
- Загрузка/выгрузка байтов
- SMS (текстовые сообщения)
Примеры взимаемых товаров:
- Деньги
- Очки
- Единицы измерения (например, если баланс сохраняется в тех же единицах, что и используемые)
Контроль кредита Diameter также определяет, как решать довольно сложную проблему, связанную с использованием/списанием нескольких типов единиц с одного баланса пользователя. Например, пользователь может платить как за онлайн-время, так и за загружаемые байты, но имеет только один баланс на счете.
Тарификация на основе сеанса
[ редактировать ]Процесс кредитного контроля на основе сеанса использует несколько запросов, которые могут включать в себя первый, промежуточный и последний запрос. Во время опроса деньги резервируются со счета пользователя. Тарификация на основе сеанса обычно используется в сценариях, в которых начисляемые единицы потребляются непрерывно, например, взимается плата за загрузку/выгрузку байтов.
Тарификация по событию
[ редактировать ]Процесс кредитного контроля на основе событий использует события в качестве механизма взимания платы. Тарификация на основе событий обычно используется, когда единицы не потребляются постоянно, например, когда пользователь отправляет MMS.
Коды команд
[ редактировать ]Для поддержки кредитного контроля через Diameter существует два сообщения Diameter: CCR (запрос кредитного контроля) и CCA (ответ кредитного контроля). Код команды для CCR/CCA — 272, как определено в RFC 4006.
Для управления квотами клиент отправляет CCR на сервер, запрашивая единицы и сообщая о потреблении. Сервер предоставляет единицы и взимает плату с пользователя. Для простого дебета/кредита клиент отправляет CCR с просьбой к серверу кредитовать/дебетовать счет пользователя. При запросе цен клиент спрашивает сервер, какова цена за единицу, и сервер отвечает, сообщая цену.
Потоки сообщений
[ редактировать ]Потоки сообщений обычно управляются контрольной точкой, запрашивающей единицы, и сервером, предоставляющим их. Сообщение также может быть сгенерировано другими приложениями диаметра, такими как NASREQ (RFC4005) для сеансов, которые ограничены по времени/использованию.
На следующей диаграмме показан упрощенный поток сообщений для сеанса с использованием квот.
Клиент начинает с запроса 10 единиц с сервера. Сервер проверяет, достаточно ли у пользователя/подписчика баланса. В этом примере сервер предоставляет клиенту все запрошенные единицы. если бы у абонента был недостаточный баланс, он мог бы предоставить меньше единиц или полностью отклонить их.
Когда или до того, как сеанс подписчика использовал предоставленные единицы, клиент отправляет на сервер обновление, сообщая ему, сколько единиц было использовано и сколько он хотел бы предоставить на этот раз. Клиенту разрешено запрашивать единицы до того, как предыдущий грант будет полностью использован, чтобы избежать приостановки сеанса подписчика во время разговора с сервером. В этом примере клиент отправляет запрос, когда 7 единиц из 10 ранее предоставленных единиц были использованы; и запросите еще 10 единиц, которые сервер предоставит. Сервер может использовать счетчик использованных единиц для списания абонентского баланса (предоставление единиц не означает, что они будут использованы. AVP использованных единиц содержит фактическое использование). Сервер также может сообщить клиенту, как долго действителен грант, и в этом случае ожидается, что клиент отправит обновление по истечении таймера гранта.
Во время сеанса может быть много сообщений об обновлении.
Наконец, подписчик завершил сеанс, и клиент отправляет на сервер сообщение о завершении, содержащее последние использованные единицы. Сервер может использовать сообщение о завершении для очистки любых связанных резервирований, сделанных во внутренней системе управления балансом. Если бы абонент не завершил сеанс сам, а вместо этого исчерпал свой баланс, тогда сервер раньше ответил бы отказом на сообщение обновления, возможно, сообщая клиенту/точке управления перенаправить трафик (обычно это имеет смысл только для HTTP / WAP) трафика . ).
AVP-матрица
[ редактировать ]AVP для новых командных кодов
[ редактировать ]Новые коды команд CCA и CCR могут потребовать некоторых AVP, как указано ниже. Жирные AVP — новинка для DCCA.
| Код команды | ||
|---|---|---|
| Имя атрибута | CCR | Приблизительно |
| Acct-Multi-Session-Id | 0–1 | 0–1 |
| Идентификатор приложения аутентификации | 1 | 1 |
| CC-Идентификатор корреляции | 0–1 | 0 |
| CC-сеанс-переключение при отказе | 0 | 0–1 |
| CC-номер запроса | 1 | 1 |
| CC-Тип запроса | 1 | 1 |
| CC-Sub-Session-Id | 0–1 | 0–1 |
| Проверка-Баланс-Результат | 0 | 0–1 |
| Информация о стоимости | 0 | 0–1 |
| Кредитный контроль-обработка сбоев | 0 | 0–1 |
| Место назначения-Хост | 0–1 | 0 |
| Область назначения | 1 | 0 |
| Обработка сбоев прямого дебетования | 0 | 0–1 |
| Временная метка события | 0–1 | 0–1 |
| Ошибка – AVP | 0 | 0+ |
| Индикация конечной единицы измерения | 0 | 0–1 |
| Предоставленный сервисный блок | 0 | 0–1 |
| Несколько услуг кредитного контроля | 0+ | 0+ |
| Индикатор нескольких услуг | 0–1 | 0 |
| Исходный хост | 1 | 1 |
| Origin-Realm | 1 | 1 |
| Идентификатор исходного состояния | 0–1 | 0–1 |
| Информация о прокси | 0+ | 0+ |
| Перенаправление-Хост | 0 | 0+ |
| Перенаправление-использование хоста | 0 | 0–1 |
| Redirect-Max-Cache-Time | 0 | 0–1 |
| Запрошенное действие | 0–1 | 0 |
| Запрошенный сервисный блок | 0–1 | 0 |
| Маршрут-Запись | 0+ | 0+ |
| Код результата | 0 | 1 |
| Идентификатор контекста службы | 1 | 0 |
| Идентификатор службы | 0–1 | 0 |
| Информация о сервисных параметрах | 0+ | 0 |
| Идентификатор сеанса | 1 | 1 |
| Идентификатор подписки | 0+ | 0 |
| Прекращение-Причина | 0–1 | 0 |
| Информация о пользователе-оборудовании | 0–1 | 0 |
| Б/у сервисный блок | 0+ | 0 |
| Имя пользователя | 0–1 | 0–1 |
| Срок действия | 0 | 0–1 |
Новые AVP для кодов команд базового протокола
[ редактировать ]| Код команды | ||
|---|---|---|
| Имя атрибута | РАР | РАА |
| CC-Sub-Session-Id | 0–1 | 0–1 |
| Идентификатор пула GSU | 0–1 | 0–1 |
| Идентификатор службы | 0–1 | 0–1 |
| Рейтинг-группа | 0–1 | 0–1 |
В таблице используются следующие символы:
- 0 AVP НЕ ДОЛЖЕН присутствовать в сообщении.
- 0+ В сообщении МОГУТ присутствовать ноль или более экземпляров AVP.
- 0–1 В сообщении МОЖЕТ присутствовать ноль или один экземпляр AVP. Считается ошибкой, если существует более одного экземпляра AVP.
- 1 В сообщении ДОЛЖЕН присутствовать один экземпляр AVP.
- 1+ В сообщении ДОЛЖЕН присутствовать хотя бы один экземпляр AVP.
Сопутствующие стандарты
[ редактировать ]- RFC 4005 — Приложение сервера доступа к сети Diameter.
- RFC 4006 - Приложение кредитного контроля Diameter (устарело)
- RFC 8506 — Приложение кредитного контроля диаметра.
- 3GPP 32.299 — Управление электросвязью 3GPP — Управление зарядкой — Приложения для зарядки по диаметру.