- PVSM.RU - https://www.pvsm.ru -
Добрый день
В данном статье вкратце о принципах онлайн тарификации в сетях LTE.
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 переводится в условные единицы:
При подключении мобильной станции OCS выдает ей так называемую квоту, т.е определенное количество килобайт, мегабайт, гигабайт, которое может передать абонент, или количеств секунд, минут, часов, в течение которого мобильная станция может пользоваться определенным сервисом.
Rating Group — это специальный идентификатор определенного типа трафика, для которого PGW будет запрашивать квоту. RG определяет, каким способом будет тарифицироваться тот или иной тип трафика. Например, для HTTP трафика вы можете использовать RG=100, и тарифицировать по объему Uplink и Downlink данные.
PCC фильтр (PCC Filter) — это набор критериев, по которым PGW идентифицирует тот или иной тип трафика. Используются два типа фильтров:
PCC фильтры объединяются в PCC правила (PCC Rules), которым присваивается специальный идентификатор — Rating Group (RG). Каждое PCC правило также имеет целый набор параметров, включая параметры QoS, способы тарификации (Volume, Time или оба сразу), флаг включения/отключения тарификации (бесплатно или нет) и т.д.
Каждое правило имеет свой приоритет — Precedence. Чем он меньше, тем выше приоритет у правила. Т.е правилам, которые используются для идентификации специальных типов трафика, необходимо присваивать более высокий Precedence.
Итак, что происходит, когда мобильная станция подключается к сети и начинает передавать данные. UL данные, отправленные мобильной станции, попадают на PGW.
Этот процесс длится до тех пор, пока абонент не закроет сессию или у него не закончатся деньги. Соответственно, OCS в режиме реального времени контролирует доступ мобильной станции в сеть.
Однa из проблем вышеприведенной схемы — это небольшие задержки при передаче данных во время сигнального обмена между PGW и OCS. Т.е процедуры получения новой квоты или обновления квоты требует времени. В то время, как PGW и OCS обмениваются данными, данные пользователя помещаются в буфер PGW и ждут своей отправки. Процедура получения квоты может занимать менее секунды, а может и 2-3 секунды (например, в часы пиковой нагрузки, когда абонентов очень много и идет интенсивный сигнальный обмен между PGW и OCS). Частично проблему решает увеличение размер выдаваемой квоты, что снижает количество запросов на ее обновление. Однако, как показывает практика, сильного эффекта это решение не дает. Поэтому было разработано два решения, которые позволяют эту проблему полностью или частично устранить
Суть решения следующая. Пока PGW и OCS обмениваются сигнальными данными для получения или обновления квоты, PGW сам выделяет мобильной станции определенную квоту, благодаря чему мобильная станция может передавать данные, даже не получив квоты от OCS. После получения квоты OCS, PGW начинает использовать ее, а потом в следующем запросе добавляет количество потраченной Квоты по умолчанию к общему количеству переданных данных. Минусом этого способа является неточность в вычислениях всех значений квот, что приводит к тому, что часть трафика мобильная станции передает бесплатно
Более эффективный способ, который, в отличие от Квоты по умолчанию, указан в спецификации. Суть в следующем: 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: адрес_сервера
Процедура взаимодействия PGW и OCS выполняется в три этапа:
Функция 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 тарификацию. Оператор хочет реализовать следующую схему:
Для реализации такой схемы нам понадобится 3 правила:
Правило, которое будет обрабатывать весь остальной трафик. Соответственно, параметры правила будут следующими:
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
Правило для обработки 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
Правило для обработки трафика на серверы оператора: например, все серверы *.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
Источник [4]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/lte/40709
Ссылки в тексте:
[1] PS Domain Charging: http://www.3gpp.org/ftp/specs/html-info/32251.htm
[2] Diameter Credit Control Application: http://tools.ietf.org/html/rfc4006
[3] Diameter Charging Applications: http://www.3gpp.org/ftp/Specs/html-info/32299.htm
[4] Источник: http://habrahabr.ru/post/189756/
Нажмите здесь для печати.