Добрый день
В данном статье вкратце о принципах онлайн тарификации в сетях LTE.
Online тарификация
Online тарификация в сетях LTE подразумевает контроль баланса мобильной станции в режиме реального времени. Для Online тарификации в сети LTE используется специальный интерфейс между PGW и Online Charging System (OCS) — Gy.
Стек протоколов интерфейса Gy: DIAMETER, SCTP/TCP, IP, L2/L1
Gy Application ID (Auth-Application-Id): 4
Квота
Каждая мобильная станция имеет определенное количество денег на счету, которая в системе OCS переводится в условные единицы:
- Кб, Мб и Гб — если тарификация идет по объему переданных данных (Volume-based charging). При использовании Volume-based Charging оператор также может отдельно считать UL и DL данные
- Секунды, минуты, часы — если тарификация идет по времени (Time-based charging)
При подключении мобильной станции OCS выдает ей так называемую квоту, т.е определенное количество килобайт, мегабайт, гигабайт, которое может передать абонент, или количеств секунд, минут, часов, в течение которого мобильная станция может пользоваться определенным сервисом.
Rating Group (RG)
Rating Group — это специальный идентификатор определенного типа трафика, для которого PGW будет запрашивать квоту. RG определяет, каким способом будет тарифицироваться тот или иной тип трафика. Например, для HTTP трафика вы можете использовать RG=100, и тарифицировать по объему Uplink и Downlink данные.
PCC правила и фильтры
PCC фильтр (PCC Filter) — это набор критериев, по которым PGW идентифицирует тот или иной тип трафика. Используются два типа фильтров:
- L4 фильтр — идентификация трафик по IP адресу и портам
- L7 фильтр — идентификация трафика по данным на L7 (Application Layer)
PCC фильтры объединяются в PCC правила (PCC Rules), которым присваивается специальный идентификатор — Rating Group (RG). Каждое PCC правило также имеет целый набор параметров, включая параметры QoS, способы тарификации (Volume, Time или оба сразу), флаг включения/отключения тарификации (бесплатно или нет) и т.д.
Каждое правило имеет свой приоритет — Precedence. Чем он меньше, тем выше приоритет у правила. Т.е правилам, которые используются для идентификации специальных типов трафика, необходимо присваивать более высокий Precedence.
Тарификация мобильной станции
Итак, что происходит, когда мобильная станция подключается к сети и начинает передавать данные. UL данные, отправленные мобильной станции, попадают на PGW.
- Мобильная станция генерирует трафик
- PGW запускает процедуру проверки трафика на соответствие созданным правилам и их фильтрам. Порядок проверки зависит от значения Precedence, т.е сначала проверяются правила с меньшим Precedence. Если параметры трафика совпадают с одним из фильтров правила, то PGW шлет сообщение Credit Control Request в сторону OCS, в котором, помимо других параметров, указывает Rating Group правила, фильтру которого соответствует трафик.
- OCS получает это сообщение, проверяет баланс абонента по IMSI, указанному в Credit Control Request, и отправляет сообщение Credit Control Answer в сторону PGW, в котором указывает RG и выделенную для этой RG квоту. Например, 1 Мбайт.
- PGW получает это сообщение, записывает значение выданной квоты для данного типа трафика, и начинает передавать данные абонента.
- В процессе передачи данных PGW постоянно проверяет переданное количество данных и сравнивает их со значением квоты
- После того, как квота закончилась (т.е абонент передал 1 Мбайт), PGW шлет сообщение Credit Control Request, в котором опять указывает Rating Group, а также указывает сколько данных было реально передано абонентом (т.е примерно 1 Мбайт)
- OCS получает это сообщение, вычитает количество переданных байт пользователя из его баланса, опять проверяет баланс (т.е может ли еще выдать квоту) и отправляет сообщение Credit Control Answer, в котором указывает квоту.
- PGW получает это сообщение и продолжает передачу данных.
Этот процесс длится до тех пор, пока абонент не закроет сессию или у него не закончатся деньги. Соответственно, OCS в режиме реального времени контролирует доступ мобильной станции в сеть.
Квота по умолчанию и Threshold
Однa из проблем вышеприведенной схемы — это небольшие задержки при передаче данных во время сигнального обмена между PGW и OCS. Т.е процедуры получения новой квоты или обновления квоты требует времени. В то время, как PGW и OCS обмениваются данными, данные пользователя помещаются в буфер PGW и ждут своей отправки. Процедура получения квоты может занимать менее секунды, а может и 2-3 секунды (например, в часы пиковой нагрузки, когда абонентов очень много и идет интенсивный сигнальный обмен между PGW и OCS). Частично проблему решает увеличение размер выдаваемой квоты, что снижает количество запросов на ее обновление. Однако, как показывает практика, сильного эффекта это решение не дает. Поэтому было разработано два решения, которые позволяют эту проблему полностью или частично устранить
Квота по умолчанию
Суть решения следующая. Пока PGW и OCS обмениваются сигнальными данными для получения или обновления квоты, PGW сам выделяет мобильной станции определенную квоту, благодаря чему мобильная станция может передавать данные, даже не получив квоты от OCS. После получения квоты OCS, PGW начинает использовать ее, а потом в следующем запросе добавляет количество потраченной Квоты по умолчанию к общему количеству переданных данных. Минусом этого способа является неточность в вычислениях всех значений квот, что приводит к тому, что часть трафика мобильная станции передает бесплатно
Quota Threshold
Более эффективный способ, который, в отличие от Квоты по умолчанию, указан в спецификации. Суть в следующем: OCS помимо квоты, добавляет в сообщение Credit Control Answer AVP Threshold (Volume или Time), которое содержит определенный процент от выделенной квоты. Т.е например OCS выдает 20 Мбайт квоты, тогда Threshold может быть 18 Мбайт (90%). PGW получает это сообщение и записывает для данной сессии квоту — 20 Мбайт и Threshold — 18 Мбайт. Мобильная станция начинает передавать данные. Как только мобильная станция передаст 18 Мбайт, PGW шлет запрашивает новую квоту от OCS. В это время мобильная станция продолжает передавать данные, так как у нее еще остается 2 Мбайта. Это способ позволяет минимизировать задержки при получении квоты. Управляя величиной квоты и Threshold можно свести задержки к нулю
Дополнительные функции
Переадресация
Если у абонента закончились деньги, то OCS в сообщении Credit Control Answer может прислать специальный AVP, в котором будет указан адрес сервера, на который необходимо переадресовать абонента. Для работы этой схемы на PGW необходимо создать правило для этого сервера, чтобы PGW не запрашивал для него квоту.
Это способ переадресация называется OCS Dynamic Redirection. В качестве альтернативы, можно использовать функцию переадресации, встроенную в PGW. В этом случае, получив от OCS информацию о том, что у абонента нет денег, PGW автоматически переадресует запросы абонента на необходимый сервер. Например, для HTTP трафика PGW будет отправлять HTTP 302 c Location: адрес_сервера
In-Advance Quota
Процедура взаимодействия PGW и OCS выполняется в три этапа:
- Создание сессии (CCR Initial / CCA Initial)
- Запрос и выдача квоты (CCR Update/CCA Update)
- Закрытие сессии (CCR Terminate/CCA Terminate)
Функция In-Advance Quota позволяет OCS выдавать квоту на этапе создания сессии. Т.е PGW отправляет CCR Initial на OCS, а OCS в ответ присылает CCA Initial и указывает список Rating Group и соответствующие значение выделенных квот. Функция не описана в спецификации, поэтому все делается на усмотрение производителя.
Оптимизация процедуры запроса квоты
Обычно, для каждой Rating Group (т.е определенного типа трафика) PGW шлет отдельный CCR, который будет содержать запрос квоты для данной RG. Функции оптимизации позволяет PGW отправлять запросы квот для нескольких групп в одном сообщении Credit Control Request. Это позволяет значительно снизить количество сигнальных сообщений между PGW и OCS.
Например, у нас два типа трафика — HTTP (RG=20) и DNS (RG=30). Без функции оптимизации, PGW отправит два сообщения CCR: одно для RG=20, второе для RG=30
Credit Control Request #1
> Multiple-Services-Credit-Control
>> Rating-Group = 20
Credit Control Request #2
> Multiple-Services-Credit-Control
>> Rating-Group = 30
Соответственно, и в ответ придет два сообщения. С функцией оптимизации, эти два запроса объединяются в один:
Credit Control Request #1
> Multiple-Services-Credit-Control
>> Rating-Group = 20
> Multiple-Services-Credit-Control
>> Rating-Group = 30
Понятно, что OCS и PGW должны уметь обрабатывать такие запросы. Так как не все производители OCS серверов эту функцию поддерживают, в PGW эту функцию можно включать/выключать в зависимости от конфигурации OCS.
Пример
В конце рассмотрим простой пример Online тарификации. Представим, что у нас есть виртуальный оператор, который хочет использовать Online тарификацию. Оператор хочет реализовать следующую схему:
- Трафик на свои HTTP серверы сделать бесплатным
- DNS трафик сделать бесплатным
- Весь остальной трафик тарифицировать отдельно
Для реализации такой схемы нам понадобится 3 правила:
DEFAULT
Правило, которое будет обрабатывать весь остальной трафик. Соответственно, параметры правила будут следующими:
Name=Default
Rating Group = 100
Precedence = 100
Charging = Online
Metering Type = Volume (тарификация по объему)
Правило будет содержать один фильтр:
Name = Default
Source IP = Any
Destination IP = Any
Protocol ID = Any
Source Port = Any
Destination Port = Any
L7 URI = not applicable
Host-Name: not applicable
DNSRULE
Правило для обработки DNS трафика
Name = DNSRULE
Rating Group = 101
Precedence = 99 (чем меньше precedence, тем выше приоритет правила)
Charging = Off (отключаем тарификацию — трафик будет бесплатным)
Metering Type = None
Это правило будет иметь один фильтр — DNSFILTER
Name = DNSFILTER
Source IP = Any
Destination IP = Any
Protocol ID = 17 (UDP)
Source Port = Any
Destination Port = 53 (DNS UDP порт)
L7 URI = not applicable
Host-Name: not applicable
HTTPSERVER
Правило для обработки трафика на серверы оператора: например, все серверы *.voperator.com
Name = HTTPSERVER
Rating Group = 102
Precedence = 10 (чем меньше precedence, тем выше приоритет правила)
Charging = Online
Metering Type = Volume (тарификация по объему)
Правило будет также содержать один фильтр:
Name = HTTPFILTER
Source IP = Any
Destination IP = Any
Protocol ID = 6 (TCP)
Source Port = Any
Destination Port = 80,8080
L7 URI = /*
Host-Name: *.voperator.com
Т.е сначала PGW будет проверять фильтры правила HTTPSERVER ( у него самый низкий Precedence ), затем DNSRULE, а потом уже DEFAULT. Наличие правила по умолчанию, куда будет попадать трафик, который не попал во все остальные фильтры, обязательно, иначе PGW просто блокирует пакеты.
Спасибо за внимание
Ссылки
Автор: Alexey06
