Организация prepaid-услуг в сетях GPRS

Эволюция сетей подвижной связи привела к появлению новых возможностей в сфере предоставления услуг prepaid-абонентам. Развитие prepaid-технологий объясняется и тем, что предоплаченный сервис продолжает оставаться эффективным маркетинговым инструментом, приносящим реальную прибыль операторам [94, 95]. Кроме того, остается востребованной самая привлекательная характеристика prepaid – полный контроль над балансом пользователя в процессе оказания услуги, что гарантирует отсутствие дебиторской задолженности у оператора связи и позволяет повысить эффективность бизнеса в целом.

Ситуация на современном рынке требует новых технологий в предоставлении предоплаченного сервиса. Предпосылками этого являются следующие факторы:

- средняя доля prepaid-абонентов сегодня превышает 50%;

- prepaid-абоненты хотят быть активными пользователями самых разнообразных дополнительных услуг;

- сегмент prepaid-клиентов становится все более дифференцированным. Prepaid-абонентов привлекают предоплаченные схемы расчетов за услуги связи, так как позволяют избавиться от неудобств со счетами и исключить абонентскую плату. Также предоплаченная схема обслуживания дает возможность им строго контролировать свои расходы на мобильную связь и не замораживать средства в виде авансовых вложений;

- prepaid-абоненты в совокупности склонны к миграции между различными операторами связи.

Указанные факторы говорят о том, что операторам необходимы новые технологии работы с prepaid-абонентами и иной подход к их обслуживанию. В этом ключе первостепенными задачами становятся поиск источников, ведущих к увеличению показателя ARPU, и разработка программ лояльности, которые приведут не только к удержанию prepaid-абонентов, но и будут являться стимулом к более активному пользованию услугами [95].

Современная prepaid-система должна помочь оператору реализовать программы лояльности за счет поддержки следующих возможностей:

- prepaid-абонент сможет самостоятельно изменять пакет услуг с помощью систем управления услугами и абонентскими профилями;

- поддержка для prepaid-абонентов множества гибких тарифных планов;

- реализация поощрительных программ и бонусов;

- предложение персонализированных сервисов, которые привязывают prepaid-абонента к оператору;

- поддержка голосовых и текстовых сообщений-напоминаний пользователям о стоимости во время звонка или предоставления услуги.

Основными отличительными особенностями prepaid-систем нового поколения можно назвать следующие [95]:

- внедрение интеллектуальной платформы (IN) как базовой технологии, способной работать в сетях второго и третьего поколения, обеспечивающей управление вызовами и тарификацию в реальном времени;

- возможность развертывания и гибкая тарификация дополнительных сервисов и контента;

- контроль предоставления сервиса в реальном времени для повторного кредитования недоставленных сообщений или потерянных данных;

- поддержка мультиязычности сообщений;

- гибкий механизм для создания поощрительных схем;

- возможность осуществления и тарификации вызовов и дополнительных услуг в роуминге, в режиме реального времени;

- возможность различных способов оплаты;

- предсобытийное управление балансом.

Таким образом, на сегодняшний момент полноценным решением, поддерживающим разворачивание услуг передачи данных для prepaid-абонентов, является решение Prepaid, реализованное на интеллектуальной платформе, с использованием протокола CAMEL для сетей GSM. Данное решение помимо тарификации голосовых услуг обеспечивает тарификацию полного набора дополнительных сервисов и контента для prepaid-абонентов в режиме реального времени, в том числе и в роуминге. Тарификация осуществляется в зависимости от объема и качества предоставляемой информации, местоположения абонента и др. [94,95].

Дадим краткую характеристику организации prepaid-услуг для абонентов сети GPRS с использованием архитектуры CAMEL3 в рамках концепции интеллектуальной сети с учетом ее роли в конвергенции различных сетей связи, опираясь на работы Б.С. Гольдштейна [17,18, 89].

Основу концепции Интеллектуальной сети IN (Intelligence Network) составляет принцип отделения организации услуг от коммутации.

Архитектура IN в условиях конвергенции представлена на рис. 10.20. Узлы коммутации услуг SSP (Switching Service Point) распознают вызовы услуг IN и обслуживают эти вызовы, взаимодействуя с централизованным узлом управления услугами (Service Control Point, SCP). Другой элемент в архитектуре IN не работает в реальном времени, но он не менее важен – это среда создания услуг SCE/SMP (Service Creation Environment/Service Management Point), в которой услуги конструируются самим оператором. Элемент IN, называемый интеллектуальная периферия (Intelligent Peripheral), обеспечивает поддержку услуг IN речевыми сообщениями (например, чтобы информировать инициаторов вызовов об изменении номера, о запрещении вызовов), а также обнаруживает и передает тональные сигналы, накапливает набираемые абонентом цифры для их последующей обработки.

Рис. 10.20. Архитектура IN в условиях конвергенции

Для поддержки информационных потоков между узлами сети IN специфицирован прикладной протокол интеллектуальной сети INAP (Intelligent Network Application Protocol). Он определяет синтаксис и семантику вызываемых операций, назначение и порядок их обработки. Протокол INAP (российская версия INAP-R) вырос из транзакционных взаимодействий между АТС и базой данных в сети ОКС; в настоящее время он базируется на протоколе возможностей транзакций (Transaction Capability, ТС) системы сигнализации ОКС № 7 [89].

Другая часть элементов мобильной IN подразумевает взаимодействие протоколов INAP и ТСАР (Transaction Capability Application Part) с другими протоколами ОКС №7: МАP (Mobile Applications Part), IS-41 и CAMEL (Customized Applications for Mobile Network Enhanced Logic).

В процессе прямого заимствования идей IN (а именно, взаимодействия HLR – VLR в мобильных сетях) проявились некоторые недостатки подхода IN, включая необходимость существенных начальных инвестиций, относительную сложность протоколов INAP и ТСАР, централизацию биллинга и управления услугами с вытекающим отсюда ограничением возможности выполнения этих функций сторонними провайдерами. Еще одной является проблема унификации: узлы управления услугами SCP, интеллектуальная периферия, системы эксплуатационного управления услугами SMP (Service Management Point) и среды создания услуг SCE (Service Creation Environment) оказались сильно зависимыми от поставщика.

Тем не менее, именно интеллектуальная сеть оказалась тем мостом, который позволил как стационарным, так и мобильным сетям взаимодействовать с IP-сетями. Такая тенденции эволюции IN проявляется в появлении протоколов WAP, RADIUS (Remote Authentication Dial-In User Service), LDAP (Lightweight Directory Access Protocol) и соответствующих этим протоколам технологий.

Ряд IN-услуг абонентам мобильных сетей, находящимся как в «домашней», так и в «гостевой» сетях, предоставляются на базе технологии CAMEL с использованием протоколов CAP (CAMEL Application Part) и MAP (Mobile Application Part). Через эти протоколы посылаются запросы инструкций по обслуживанию вызовов в среду CSE (CAMEL Service Environment), осуществляется обмен сообщениями на разных этапах обслуживания абонента.

Протокол CAMEL стандартизован в нескольких фазах, причем первые две фазы соответствуют классической интеллектуальной сети со специфицированным МСЭ и ETSI про токолом INAP и списками услуг CS 1-3 (Capability Sets 1-3). Фаза 3 ориентирована на спецификации 3GPP, а находящаяся в стадии разработки фаза 4 – на мультимедийный трафик сетей с коммутацией каналов, пакетов и IP-сетей. Сравнение фаз CAMEL приведено в табл. 10.9 [89]. I

Таблица 10.9

Фазы CAMEL	Фаза 1	Фаза 2	ФазаЗ
Характеристики	•Для вызовов, инициирова-нных или адресованных от/к мобильной сети; • Без тарификации; •Без информационных со-общений; • Ограниченный набор; точек DP	• Тарификация; • Новые точки DP; • Автоинформаторы и то- нальные сигналы; • Прием сигналов тональ- ного набора (DTMF); • USSD-связь между SCP и мобильным терминалом	• Тарификация GPRS; • Тарификация исходящих SMS; • SCP – HLR-интерфейс; •SCP-управление; ожиданием вы-зова, переадресацией и конфе-ренцсвязью; • Функции мобильного управления

Таблица 10.9 (окончание)

Фазы CAMEL	Фаза 1	Фаза 2	ФазаЗ
Типовые услуги	• Фильтрация вызовов; • Перенаправление вызовов; • Перенаправление вызова, перевод номера из вирту-ального в реальный, напри-мер при роуминге по дан-ным VLR/HLR; • Маршрутизация вызова; • Простейшие VPN	• Prepaid-y слуги; • Поиск путей установления соединений; • Сообщения при установ- лении или разрыве соеди- нения; • Бесплатный вызов; • Взимание платы за пре- доставление дополнитель- ных информационных услуг; • Персональные скидки • Скидки, зависящие от местоположения абонента; • Начисление платы за входящие звонки	• Prepaid-услуги для GPRS; • Расширение списка prepaid-услуг; • Сервисные номера; • Множественные абонентские профили

Концептуальная модель CAMEL представлена на рис. 10.21.

Рис. 10.21. Концептуальная архитектура CAMEL3 в сети 3GPP

IN-, GPRS- и SMS-вызовы находятся под управлением узла gsmSCF (GSM Service Control Function). Упоминающиеся в таблице точки детектирования DP (Detection Points), в которых происходит активизация процесса оказания услуг, соответствуют классической модели IN, но определяются не только для вызовов IN, но также для SMS-сообщений и сессий GPRS. Для последних определена функция gprsSSF (GPRS Service Switching Function). CAMEL предусматривает два типа отношений между представленной на рис. 10.21 моделью и узлами gsmSSF/gsmSCF. Это отношения мониторинга и управления. Диалог GPRS - MSC для IN-, GPRS- и SMS-вызовов осуществляется между узлами gprsSSF/gsmSSF и gsmSCF, если обнаружена хотя бы одна точка DP, имеется хотя бы один незаконченный отчет или узлы gsmSSF/gprsSSF находятся в состоянии ожидания [89].

Сегодня технология CAMEL ориентирована преимущественно на коммутацию каналов, а наиболее распространенными являются, скорее всего, prepaid-услуги. Версия же CAMEL3 переносит эти услуги на коммутацию пакетов. Кроме того, в CAMEL3 поддерживается множество ЗG-возможностей, например роуминг услуг и биллинг в режиме реального времени. Следующая версия CAMEL для мультимедийной IP-сети с коммутацией пакетов включает новую функцию ipSSF (Internet Protocol Service Switching Function) и имеет интерфейсы с узлами GGSN (Gateway GPRS Support Node), HLR и gsmSCF.

Рассмотрим алгоритм тарификации в рамках GPRS-сессии. Управление предоплаченными сервисами осуществляется в SCP, различные варианты пополнения счета могут использовать возможности узла SGSN, а информация абоненту доставляется из HLR, например, при активизации GPRS-услуг в ходе процедуры GPRS Attach или во время обмена информацией с узлами SGSN – Inter SGSN RAU (Routing Area Update). В этом случае после запроса абонентского терминала и аутентификации, SGSN передает шлюзовому узлу GGSN запрос на создание определенного PDP-контекста протокола передачи пакетов данных и посылает запрос в направлении SCP, который, как и в случае сети с коммутацией каналов, проверяет состояние prepaid-счета абонента.

На рис. 10.22 приведен пример сценария взаимодействия CAMEL3 с PDP-контекстом [89].

Связь с узлом управления услугами SCP интеллектуальной платформы в данном случае поддерживается с помощью средств CAMEL Phase III. Получив разрешение от системы Prepaid, SCP дает инструкцию SGSN через SSP на подключение пользователя к контент-ресурсам (т.е. может ли продолжаться обслуживание абонента в этом PDP-контексте). Получив разрешение, SGSN продолжает обслуживание и информирует SCP о том, когда PDP-контекст активируется в узле GGSN. После этого SCP дает разрешение на передачу определенного объема данных или на определенный лимит времени (или на то и другое вместе). В процессе оказания услуги данные для начисления оплаты собираются в узлах SGSN и GGSN. SGSN генерирует учетные записи (CDR) и посылает их в ближайший узел начисления платы (Charging Gateway Function, CGF). Узел SGSN через заданные промежутки времени передает узлу SCP посредством протокола CAMEL статусную информацию о предоставляемой услуге (объем, время и пр.), а узел SCP списывает деньги со счета абонента в реальном времени.

Когда отведенный лимит времени или объема данных исчерпывается, узел SGSN опять спрашивает SCP, остались ли деньги для продолжения сеанса, и при положительном ответе цикл повторяется. В противном случае SCP дает команду деактивировать PDP-контекст. Рис. 10.23 иллюстрирует типовую операцию prepaid-услуг в GPRS [95].

Далее SGSN запрашивает SCP, можно ли послать абоненту SMS-сообщение об исчерпании денег на его счете или аналогичное звуковое сообщение в случае IN-вызова. Кроме того, в данном случае предоставляется возможность пополнить счет в реальном масштабе времени и продолжить обслуживание вне зависимости от того, что конкретно в это время делает абонент в узлах SGSN/MSC/SCP, и от типа CAMEL-приложения (вызов в IN, передача данных GPRS, посылка SMS).

Таким образом, HLR, gsmSCF и gsmSRF являются сетевыми элементами и функционально включаются в архитектуру CAMEL. HLR хранит абонентские данные, включая и сведения о том, является ли данный абонент CAMEL-абонентом. Далее HLR передает эти данные (CAMEL Subscription Information, CSI) в сетевой элемент, ответственный за предоставление услуги CAMEL. Соответствующие сетевые элементы пересылают абонентские

данные CSI к VLR «гостевой» сети, a GPRS-CSI и SMS-CSI к SGSN в процессе перемещения абонента или при модификации данных CSI. Непосредственно логика услуги сосредоточена в узле gsinSCF, имеющем интерфейсы с узлами gsmSSF, HLR, VMSC и gsmSRE. Кроме того, в CAMEL3 добавляются два новых интерфейса: к VLR и к gprsSSF.

Рис. 10.22. Сценарии взаимодействия CAMEL3 с PDP-контекстом

Рис. 10.23. Реализация предоплаченных услуг в сети GPRS

CAMEL базируется на сигнализации ОКС № 7. Наряду с собственно CAMEL3 протоколами используются протоколы САР и MAP поверх ТСАР. Причем используются оба варианта диалога ТСАР – короткий для GPRS-услуг (так как для протокола САР не требуется постоянно активное состояние PDP-контекста, а следовательно, сетевые ресурсы можно использовать для других целей) и длинный ТСАР – для SMS-вызовов.

В [89] отмечается, что уже при ста тысячах абонентов CAMEL3 существенной проблемой взаимодействия по САР становится пропускная способность сети ОКС № 7.

Для рассмотренного выше варианта prepaid-услуг, например, узел SCP должен управлять SGSN и MSC, выполнять массу других функций и параллельно собирать от них записи CDR в реальном масштабе времени. Решение этой проблемы видится на пути решений «ОКС № 7-поверх-1Р», разрабатываемых рабочей группой IETF SIGTRAN (Signalling Tram-port) и включенных в спецификации 3GPP Rel. 4 [89]. Здесь уже сигнализация САР и MAP передается поверх M3UA (МТРЗ User Adaptation), SCTP (Simple Control Transmission Protocol) и IP (Internet Protocol) уровней, заменяющих решение МТР по трактам Е1.