Протокол учета radius (radius Accounting)

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

Общая схема реализации процедуры учета приведена на рис. 2.7. В слу­чае, когда клиент (NAS-сервер) настроен на использование процедуры RADIUS accounting на начальном этапе, он передает пакет Accounting-Request Start (т.е. Acct-Status-Type = start), описывающий тип предоставляемой услуги. RADIUS-сер­вер должен сформировать и отправить соответствующий отклик на него.

При завершении пользовательского сеанса NAS-сервер генерирует пакет Accounting-Request Stop, который может содержать статистические данные о сес­сии - продолжительность сеанса, число пакетов и байтов, принятых и переданных пользователем. В ответ RADIUS-сервер также должен отправить необходимый отк­лик. В случае отсутствия ответного сообщения клиенту (NAS-серверу) рекомен­дуется повторять передачу пакета Accounting-Request до тех пор, пока не будет получен ответ от RADIUS-сервера.

Клиент может также переслать запрос резервным RADIUS-серверам, если основной сервер не работает или недоступен. Если RADIUS-сервер не может запи­сать пакет учета, то он не должен посылать отклик. В механизме учета предусмот­рена возможность использования RADIUS-серверов в режиме прокси.

Рис. .2.7. Обмен сообщениями по протоколу RADIUS Accounting

Алгоритм работы сервера-посредника RADIUS в режиме accounting приве­ден ниже:

Шаг 1. NAS передает пакеты Accounting-Request пересылающему RADIUS- серверу (прокси).

Шаг 2. Пересылающий сервер, в свою очередь, протоколирует пакет Accounting-Request, добавляет атрибут Proxy-State (если в этом есть необходи­мость) после имеющихся в пакете атрибутов Proxy-State, обновляет значение Request Authenticator и пересылает запрос удаленному серверу.

Шаг 3. Удаленный сервер протоколирует пакет Accounting-Request, копиру­ет все атрибуты Proxy-State, не изменяя их порядка, в пакет отклика и передает отклик Accounting-Response прокси-серверу.

Шаг 4. Пересылающий прокси-сервер удаляет из пакета последний атри­бут Proxy-State (если он был добавлен на шаге 2), обновляет значение Response Authenticator и передает пакет Accounting-Response NAS-серверу.

Для прокси-сервера недопустимо изменение присутствующих в пакете атрибутов Proxy-State или Class. Прокси-сервер может прозрачно пересылать пакеты, передавая повторные пакеты по мере их получения, или принять на себя ответственность за передачу повторных пакетов (это удобно в тех случаях, когда сетевое соединение между посредником и удаленным сервером по своим харак­теристикам существенно отличается отсоединения между посредником и NAS).

3. Реализация ааа в различных сетях aaa-сервер в ims сети

Все больше операторов связи строят мультисервисные телекоммуникационные сети связи нового поколения NGN (New Generation Network) по технологии IMS (IP Multimedia Subsystem). Поэтому поддержка открытых стандартов 3GPP для взаимодействия AAA-сервера с элементами сети оператора связи приобретает особое значение. Открытые стандарты 3GPP описывают узлы IMS сети, интерфейсы взаимодействия между ними и дают рекомендации, какие протоколы использовать в качестве этих интерфейсов. Эта логика позволяет по мере развития протоколов изменять рекомендации, но архитектуру сети оставлять без изменения. При работе AAA-сервер взаимодействует со следующими узлами IMS сети (см. Рисунок 1).

HSS (Home Subscriber Server)

Сервер домашних абонентов, в котором хранятся данные абонентов. HSS является аналогом HLR (HLR - Home Location Registry)  в мобильной связи, но с большим числом функций. Для AAA-сервера наибольшее значение представляют функции аутентификации абонентов и получения информации по услугам абонентов. Если в структуре IMS присутствует GUP (General User Profile) сервер, то AAA-сервер может получать информацию из GUP сервера по Rg интерфейсу. Интерфейс Rg представляет собой набор процедур по управлению профилем абонента, таких как  создание, удаление, изменение, получение нотификаций об изменении профиля и др. В качестве реализации стандарт рекомендует использовать SOAP протокол поверх HTTP.

CCF (Charging Collection Function)

С системой биллинга AAA-сервер взаимодействует по интерфейсам Ro (для on-line) и Rf (для off-line). Ro базируется на IETF Credit Control Application (RFC 4006) и использует команды Diameter протокола Credit-Control Request/Answer (CCR/CCA). Rf базируется на функциональности IETF-diameter base (RFC 3588). Rf использует команды Diameter протокола Accounting Request/Answer ACR/ACA.

BRAS (Broadband Remote Access Server)

Маршрутизатор широкополосного доступа – устройство, к которму подключаются конечные устройства абонентов для выхода в Интернет. BRAS взаимодействует с AAA-сервером по RADIUS протоколу.