Немного о тарификации пакетного трафика 3G/GPRS

9 Окт
2011

image
Это удивительно, как мало мы знаем о базовых принципах и архитектурах сетей мобильной связи. Наблюдая за дискуссиями вокруг онлайн-тарификации пакетного трафика, я понял, что вполне мог бы поделиться тайными знаниями. Шучу, конечно — никаких секретов я раскрывать не буду, а лишь попытаюсь изложить простым языком те аспекты, которые, быть может, кому-то откроют глаза на причины и масштабы проблем, с которыми сталкиваются операторы в области тарификации услуг связи.

Первое, что хотелось бы отметить, это то, чем оператор мобильной связи принципиально отличается от, к примеру, проводного интернет-провайдера: мобильная связь предоставляется всегда и _везде_. Еще раз подчеркиваю слово _везде_. Т.е. по всему миру. Вы можете сесть в самолет в любое время и через несколько часов включить телефон в Европе или в Штатах – не важно. Важно, что он поймает сеть, зарегистрируется и вы тут же сможете позвонить, отправить sms или зайти на свой любимый microhabr.ru И хоть я сейчас выступал в роли КО, но очень похоже, что все настолько привыкли к глобальному роумингу, что уже не воспринимают его как какое-то техническое достижение. И я знаю, почему. Интернет – вот, что можно противопоставить. Мы привыкли, что можем запросто, не сходя с дивана блуждать по всемирной паутине, заказывать китайские безделушки на DX или качать торренты с пол сотни машин по всему миру одновременно. Чудо? Да, но такое сравнение было бы не совсем честным. Мы сидим на диване, в своем доме, куда подведен кабель от провайдера. А кабель уходит в домовой маршрутизатор и пакеты наши обязательно проходят так, как определил наш провайдер. И естественно, когда речь заходит о подсчете трафика, интернет-провайдеру не нужно заморачиваться, где в это время находился клиент или через какой маршрутизатор он подключался. Думаю, это тоже всем понятно.
Итак, что же можно вынести из сказанного? Роуминг уже является услугой, за которую берут деньги. Немного отходя от темы, я выскажу одну мысль: с технической точки зрения, все, абсолютно все абоненты, всегда, в любой момент времени находятся в роуминге. Просто потому, что роуминг — это блуждание, перемещение. А в чьей зоне действия, в какой сети – это вопрос организационный. И он не простой. Вы только представьте, как между операторами должна быть налажена работа, финансовые отношения, техническое взаимодействие, чтобы мы могли пользоваться связью в любой стране, да еще и перебирать между операторами!
А теперь самое время познакомиться с тем, как же «работает роуминг». Я намеренно не стану рисовать классическую архитектуру сети, потому, что, во-первых уже существует масса более других вариаций и отступлений, а во-вторых, я уже и без того наговорил банальностей. Каждый из вас, наверняка и так знает, что HLR – это база данных абонентов компании, MSC – это коммутатор, VLR – база данных абонентов, находящихся в зоне действия MSC, SGSN является пакетным коммутатором, GGSN – что-то вроде шлюза, и что все это хозяйство являет собой CoreNetwork – ядро сети. Так что же происходит, когда мы включаем наш телефон и он находит сеть?
Первое, что делает телефон – он регистрируется в сети. В результате этой процедуры, в VLR, где находится абонент, появляется запись, в которой наиболее важными деталями являются: HLR-адрес, откуда этот абонент явился, его IMSI, телефонный номер, набор доступных услуг, а так же CAMEL-параметры, которые являются краеугольным камнем во всей системе онлайн-тарификации. Одновременно с регистрацией в сети, может происходить и регистрация в пакетной сети – в SGSN. Это может быть справедливо, например, для USB-модемов или для телефонов, у которых режим подключения к GPRS выбран «всегда в сети». В SGSN есть свой аналог VLR со своим адресом. При регистрации, в HLR абонента тоже появляется запись – о том, где, в каком VLR в настоящий момент следует «искать» нашего блудного абонента и если он подключился к пакетной сети, то и адрес SGSN.
Как же взаимодействуют между собой все эти монстры: HLR, VLR/MSC, SGSN, CAMEL-платформа? Это просто и гениально. Каждый такой сетевой элемент имеет адрес, который называется Global Title (GT). Этот GT очень похож на номер телефона в международном формате. Только по нему нельзя позвонить. Зная GT, можно отправить сообщение в подсистеме SCCP. Эта подсистема позволяет общаться всем коммутаторам, HLR, VLR, SGSN и CAMEL-платформам по всему миру. Очень просто: когда телефон регистрируется в VLR, он сообщает ему свой IMSI, который хранится в SIM. Затем VLR выполняет IMSI-анализ, в результате которого в направлении HLR формируется запрос на регистрацию. «В направлении HLR» следует понимать так: поскольку между VLR и HLR в общем случае нет прямого коннекта, наше сигнальное сообщение (запрос) пройдет через ряд транзитных пунктов, на каждом из которых, маршрутизация нашего сообщения будет уточняться и в результате оно поступит в искомый HLR. Правила маршрутизации сигналлинга в мировом масштабе – вещь очень не простая. Обычно, каждый оператор старается как-то упорядочить сигнальный обмен, строит собственные сигнальные сети, но не обходится и без директивного вмешательства регулирующих органов. Так или иначе, запрос поступает в HLR, где сохранятся GT того VLR откуда пришел запрос, а в ответ HLR отправляет респонс, который содержит множество интересных данных, в числе которых есть не только GT самого HLR, но и то, что нам будет интересно далее – GT той CAMEL-платформы, которая будет тарифицировать абонента в режиме онлайн. Эта платформа находится в домашней сети и тесно связана с биллингом. Таким образом, в результате регистрации, обе стороны – HLR и VLR обмениваются GT-адресами, которые в дальнейшем будут использоваться ими для общения. Ну и самое важное для нас — в VLR, где зарегистрировался абонент, появляется GT-адрес CAMEL-платформы, которая потом и будет выполнять тарификацию. Вся эта процедура прошла в подсистеме MAP, которая использует подсистему SCCP в качестве транспорта.
Итак, мы знаем, что все крупные элементы, такие как HLR, MSC, VLR, SGSN и CAMEL-платформа имеют уникальный адрес Global Title, а значит – могут взаимодействовать друг с другом в подсистеме SCCP. Разумеется, это взаимодействие происходит для них прозрачно, через сеть сигнализации ОКС-7, опутавшую весь земной шар — через сетевой уровень MTP-3, расположенный под SCCP, через канальный MTP-2 и физику. Но это тема совсем другого рассказа.
Мы постепенно побираемся к самому главному, но нам еще необходимо рассмотреть роли сетевых элементов в пакетном ядре, а именно: SGSN и GGSN. Как мы знаем, основное обслуживание пакетной сессии осуществляет SGSN – у него даже аббревиатура намекает: Serving GPRS Support Node. GGSN’у отведена более скромная роль – он управляет IP-частью: выдает IP-адрес, пропускает через себя весь трафик (уже в реальный внешний интернет) и даже может его считать. Вот только считать он его может офлайн. Т.е. формирует тарификационные файлы на основе пропущенных мегабайт и отдает их, к примеру, в биллинг. Это тоже вариант и в некоторых случаях он вполне имеет право на существование. Ну а как же онлайн?
Одна из схем онлайн-тарификации выглядит следующим образом:
Для онлайн-тарификации обычно применяется следующая схема: когда абонент выполняет подключение к пакетной сети, SGSN, используя SCCP, запрашивает у CAMEL-платформы квоту – сколько килобайт-мегабайт может скачать абонент? Та отвечает, выдает квоту и SGSN сам считает расход. Считает в онлайн, но очень примитивно: как только квота израсходована – делает запрос следующей. Если квота не израсходована и абонент завершил сессию – остаток сгорает. Вероятно, так можно объяснить округление по 10 или 100 кбайт.
В принципе, главная мысль моего повествования уместилась в предыдущем абзаце. Далее начнем разбираться с вопросами и сложностями. Мы уже говорили, что SCCP – это лишь способ доставки сигнальных сообщений между сетевыми элементами. Разумеется, есть уровни и выше. Один из них – CAP (Camel Application Part). Именно в этом уровне происходит взаимодействие между CAMEL-платформой, выполняющей тарификацию и узлом SGSN. И вот теперь начинается самое интересное. Дело в том, что уровень CAP, а именно – поддержка CAMEL не везде и не у каждого вендора и оператора работает одинаково. Для полноценной онлайн-тарификации, с обеих сторон – в сети регистрации и в CAMEL-платформе домашней сети важно иметь CAMEL 3-й фазы. Именно 3-я фаза обеспечивает возможность обслуживания транзакций для пакетной сети GPRS. Так вот, проблема в том, что 3-ю фазу поддерживают не все операторы. И это большая проблема.
Конечно, и из этой ситуации есть выход, и у некоторых операторов он с успехом применяется. Как мы уже говорили, трафик проходит через GGSN, который назначает IP-адрес и потенциально может быть тем узлом, на котором, теоретически, можно посчитать объем переданных данных по каждому абоненту. Хотя, надо сказать, что обычно GGSN делать этого в реалтайме не умеет. Если рассматривать ситуацию «абонент в сети чужого оператора», то GGSN может использоваться как чужой, так и свой собственный. Какой из сценариев выбирается в том или ином случае, сильно зависит от желания оператора, от тарифного плана, от гостевой сети и APN, с которым выполняется подключение. Для того, чтобы считать трафик онлайн, разумеется, необходимо использовать GGSN домашней сети, за которым, перед выходом в интернет располагается специальная платформа тарификации пакетного трафика. Корявость такого решения в том, что весь пользовательский трафик в таком случае пойдет от SGSN гостевой сети к GGSN домашней сети и вы наверняка догадываетесь, как это сказывается на стоимости — пакетный трафик абонента между операторами ходит не по открытому интернету, а по вполне себе платным VPN-туннелям глобальной сети GRX, которые арендуются у провайдеров дальней связи федерального масштаба. Но есть и бонусы: когда учет трафика ведет отдельная платформа, которая целиком пропускает его через себя, это открывает новые возможности по дифференциальному учету. Эту платформу можно научить распознавать как различные протоколы (и тарифицировать их по разному), так и адреса хостов. Именно поэтому стало возможным создание тарифных опций, включающих «бесплатный» трафик на социальные сети и другие популярные интернет-сервисы. Подобные решения относительно новы на рынке телекоммуникационных услуг и, к сожалению, пока толком не умеют общаться ни друг с другом (разные вендоры и нет стандартизации), ни с сетевыми элементами CoreNeteork. И это не позволяет построить глобальную систему, в которой бы всегда работал онлайн-учет и надежная блокировка по достижению нулевого порога.
Подводя итог, скажу, что несмотря на то, что способы онлайн-контроля баланса существуют и много где внедрены, не стоит забывать, что есть и проблемы, в том числе и не решенные. Уход абонента в глубокие минуса оператору не особо выгоден: это фрод, это потенциально потеря абонента, дебиторская задолженность, суды и еще масса разного геморроя. На этом, предлагаю пока остановиться. Надеюсь, мне удалось пролить немного света на тайны и интриги тарификации.
По материалам Хабрахабр.



загрузка...

Комментарии:

Наверх