О тарификации в NGN

Важность рассматриваемой темы подчеркивают два обстоятельства: во-первых, это сближение фиксированных  и мобильных сетей, бурный рост новых платных услуг связи, прежде всего, феноменальный рост рынка услуг SMS и ожидаемые успехи MMS, а во-вторых, — рост электронной коммерции, которая, по прогнозам, будет основана на использовании мобильного терминала в качестве универсального кошелька. Эти тенденции предполагают наличие единой развитой системы тарификации (charging), о чем  и  пойдет речь в настоящей статье.

М.А. ШНЕПС-ШНЕППЕ, генеральный директор компании “Абаванет”, доктор технических наук

Отметим предварительно, что важность этого обстоятельства уже в полную меру осознали руководители Связьинвеста, заключив контракт с компаниями Amdocs и IBM по внедрению единой автоматизированной системы расчетов (АСР), которая призвана заменить 186 различных АСР, ныне эксплуатируемых  дочерними предприятиями компании.

Контракт стоимостью в 480 млн. долл. стал крупнейшим на российском рынке ПО. В настоящее время эта грандиозная работа только началась, происходит анализ существующих АСР, изучаются возможности перевода существующих баз данных на новые форматы. Мы надеемся, что анализ международных стандартов в области тарификации, проведенный в настоящей статье, окажется полезным для разработчиков новой системы расчетов, чтобы учесть не только текущие нужды, но и задачи тарификации услуг сетей нового поколения NGN, в том числе мобильных сетей 3-го поколения.

Начнем с двух сообщений о разработке стандартов мобильной коммерции. 31 марта 2005 г. консорциум PayCircle завершил трехлетнюю работу по стандартизации мобильных платежей (mobile payment, m-commerce). Эти стандарты описывают бизнес-процессы средствами web-сервисов, т. е. популярными средствами HTTP и XML. Заметим, что PayCircle был основан в 2002 г. корпорациями: Hewlett-Packard, Lucent, Oracle, Siemens и Sun Microsystems, а сегодня объединяет сотни компаний.

Важность стандартов PayCircle подчеркивает тот факт, что они уже приняты международным объединением Open Mobile Alliance (OMA) и стали основой платежных систем мобильных операторов в мире. Заметим, что членами Open Mobile Alliance, тоже созданного три года назад, являются более 300 мобильных операторов, производителей оборудования связи и компьютеров, контент-провайдеров. С 2003 г. интерфейсы PayCircle Payment API’s объявлены стандартами ETSI и 3GPP (в рамках платформы ParlayX).

Год назад, 21 января 2004 г., консорциум PayCircle заключил важное соглашение о совместной работе с международной организацией Liberty Alliance Project, которая занимается стандартизацией еще нерешенных вопросов идентификации пользователей. Не лишне отметить, что идентификация и платежи — это два ключевых момента для роста мобильных web-сервисов.

Основная схема NGN

Архитектура NGN имеет три уровня (рис. 1):

• ядро сети составляют системные сервисы (маршрутизация вызова, аутентификация, тарификация и биллинг и т. д.), которые действуют в IP-области;

• базовые сети (фиксированные, мобильные, IP) взаимодействуют с ядром по новому протоколу сигнализации SIP, который приходит на смену традиционной системе сигнализации ОКС-7;

• приложения размещаются в домене сторонних разработчиков. Очень важно, что общение между серверами приложений и ядром сети будет происходить по открытым интерфейсам программирования (OSA — Open Service Access). Их реализацией является спецификация Parlay и ее новая версия ParlayX,  которая ориентирована на web-сервисы.

Центральное звено NGN составляет система IMS (IP Multimedia Subsystem), — так предусмотрено стандартами 3GPP. Зафиксировано также, что система IMS действует в режиме коммутации пакетов, и основным протоколом сигнализации является SIP. Тем самым простейшую архитектуру NGN можно представить как на рис. 2: средства доступа к сети могут быть различными (xDSL, GPRS, EDGE, WLAN и т. д.), и все они передают пакеты.

Предполагается, что сам узел IMS будет содержать три блока  — один контроллер и две базы данных, а именно: менеджер вызова CSCF (Call Session Control Function) — это аналог SSP в интеллектуальной сети IN, абонентскую базу данных HSS (Home Subscriber System) — аналог HLR в сети GSM и медиа-сервер (MRF — Media Resource Function) — аналог интеллектуальной периферии в IN.

Но еще много неясного, и борьба вокруг концепции IMS длится уже более сети лет — с 1998 г., когда под названием UMTS (Universal Mobile Telecommunications System) началась разработка сетей третьего поколения. С 2000 г. эту работу возглавил консорциум 3GPP. К сожалению, работа идет без должного успеха, хотя ведется весьма интенсивно. Активность участников консорциума “подгоняют” просчеты с лицензиями на сети 3G (европейские операторы тогда потеряли 30 млрд. долл.).

В 2003 г. была завершена уже 5-я версия стандартов UMTS, но к тому времени стало очевидно, что IP-телефония не очень годится для мобильной связи: SIP-сигнализация слишком неэкономна, весьма большой объем занимают заголовки по сравнению с полезной нагрузкой. С середины 2005 г. усилия стандартизаторов сосредоточены вокруг Release 7, что включает, в частности,  вопросы роуминга с фиксированной сетью, работу IMS с WLAN, вопросы качества связи в условиях взаимодействия многих операторов.

Тарификация в IMS в режиме online

В сетях NGN особое значение приобретает система тарификации. Она становится ключевой: без наличия единой системы тарификации и взаиморасчетов не может быть никакой конвергенции сетей. По аналогии с услугой SMS в сетях GSM, в сетях 3G внимание, прежде всего, сосредоточено на различных вариантах оплаты услуги MMS, учитывая множество параметров: типы сообщений, их длину, время хранения в памяти и т. д., время доставки, направление передачи (upload/download), кто посылает/получает, число переданных/принятых сообщений, условия роуминга и местоположения, условия предоплаты, вид транспорта.

В спецификациях 3GPP, только в серии 32 “Управление тарификацией (Charging management)”, имеется более 20 стандартов; 12 из них указаны на рис. 3. О них невозможно рассказать в одной статье. Дадим только общие представления, чтобы читатель осмелился приступать к их самостоятельному изучению.

В системе тарификации рассматриваются три уровня:

• тарификация транспорта (bearer), сюда относится особенности коммутации каналов (CS-domain, стандарт 32.250), коммутации пакетов (PS-domain, стандарт 32.251), WLAN (стандарт 32.252);

• тарификация услуг (service charging), особо выделены услуги MMS, LCS, PoC (Push over Cell), MBMS (Multi-Broadband and Multi-Cast). Считается, что они представляют самостоятельный интерес на рынке услуг;

• тарификация в самой системе IMS (стандарт 32.260).

Нижние два ряда (на рис. 3) касаются формирования тарификационных записей CDR и их пересылки, для транспорта используется протокол Diameter (вместе ранее примененного протокола Radius).

Подробнее остановимся на тарификации в режиме реального времени (online charging), как наиболее сложном варианте тарификации (на рис. 3 указан стандарт 32.296 — только один из стандартов, касающихся online charging). Согласно документу 3GPP TS 32.815, во всех разделах сети 3G размещаются триггеры тарификации (Charging Trigger Function, на рис. 4), которые передают сигналы в блок тарификации реального времени OCF (Online Charging Function).

Триггерные сигналы поступают от упомянутых выше трех уровней системы: CS-domain, услуг (service element) и самой системы IMS (sub-system). Одна из важных задач OCF — согласовать эти три потока сообщений, запускающих систему тарификации. Сигналы передаются через интерфейс Ro, точнее по протоколу САР. В подсистеме OCF имеются два блока: функция тарифов (Rating Function), доступная по интерфейсу Rе, и функция управления балансом (Account Balance Management Function), доступная по интерфейсу Rс.

На рис. 5 приведен пример потоковой диаграммы в смысле транзакций тарификации (по протоколу Diameter и в виде SIP-сообщений) между гостевой (visited network) и домашней сетью (home network). Рассматривается случай успешного установления соединения. Тут фигурируют пять объектов: пользователь UE, два менеджера вызова:  Р-CSCF (прокси — в гостевой сети), S-CSCF (serving — в домашней сети) и две функции формирования CDR соответственно.

Перечислим основные шаги алгоритма, опуская детали многочисленных SIP-сообщений:

• сеанс связи инициализирован;

• вызываемый абонент отвечает и окончательный ответ получен;

• менеджер вызова  S-CSCF посылает сигнал о начале тарификации Accounting-Request и формирование записи CDR;

• блок тарификации CDF подтверждает открытие записи S-CSCF CDR.

То же следует для P-CSCF и для P-CSCF CDR.

Идеология тарификации PayCircle

PayCircle является международной бесприбыльной организацией, независимой от производителей оборудования, которая ставит своей целью стандартизацию платежных технологий. Она разрабатывает открытые интерфейсы на основе XML, SOAP, Java и на других средствах Интернета. PayCircle пытается охватить все множество платежных сценариев, включая плату за измеряемые объекты, как видео-передача, игры по требованию, за “штучный товар”, как фиксированный файл или видеоклип, абонентскую плату, покупку через автомат, оплату поездки в такси через мобильный телефон.

Абстрактная модель платежной системы (рис.6) показывает взаимодействие между четырьмя действующими лицами (административными доменами):

• покупатель (customer);

• продавец (merchant);

• провайдер платежного сервиса (Payment Service Provider, PSP);

• провайдер финансового сервиса (Financial Service Provider, FSP)

• и шестью программами (их названия даны в овалах).

Это взаимодействие определяют шесть интерфейсов:

• доставка оплачиваемой услуги. Через этот интерфейс  пользователь (customer) получает услугу предоставляемую продавцом (merchant). Этот интерфейс можем быть реализован по разному: по протоколу HTTP, посредством общения с кассиром при покупке в магазине и т. п.;

• пользовательский диалог (User Dialogue) между покупателем и программой  “confirmation engine” (подтверждение запроса покупателя);

• оплата. Взаимодействуют программы “request engine” и “payment engine”;

• авторизация. Программа “authorization engine” производит разные проверки, что включает взаимодействие с  пользователем;

• взаимодействие с банком (с базой карт предоплаты);

• тарификация. Программа “request engine” запрашивает цену, если объект заранее не тарифицирован.

Приведем упрощенную схему сеанса тарификации (рис. 7). В этом примере производится предварительное бронирование оплаты и взаимодействуют три участника: пользователь, мобильный и платежный сервисы.

Сеанс тарификации состоит из шести шагов:

• Create Charging Session: мобильный сервис создает сеанс тарификации (Charging Session). Все сообщения данного сеанса тарификации имеют один и тот же контекст, который в частности содержит идентификатор пользователя;

• Rate Request/Price Presentation: мобильный сервис запрашивает стоимость услуги, она сообщается пользователю для одобрения;

• Reserve Charging by Volume: резервируется некоторая сумма денег;

• Deliver Service: мобильный сервис предоставляет услугу;

• Charge Point/Debit Against Reservation: в некоторый промежуточный момент мобильный сервис производит расчет за указанную часть услуги. Для этого посылается сообщение Debit Against Reservation к платежному сервису и деньги переводятся на счет провайдера мобильных сервисов;

• Terminate Service/Release: в любой момент мобильный сервис может завершить сеанс связи и вернуть неиспользованную сумму денег.

Тарификация в Parlay Х

Сейчас мы рассмотрим, как приведенная схема реализована посредством web-сервисов в платформе Parlay Х, точнее рассмотрим  web-сервисы расчета с абонентом. В эту группу входят: Payment (Тарификация) и Account Management (Управление расчетами с абонентом).

Payment. Наличие открытых интерфейсов “payment APIs” является ключевым для рынка услуг и защиты инвестиций в области связи. Web-сервис Payment поддерживает систему расчетов с абонентами в открытой web-подобной среде. Сервис Payment обеспечивает как режим предоплаты (pre-paid payments), так и авансовую оплату (post-paid payments), а также режим резервирования. Поддерживает тарификацию в виде денег (currency amounts) или объемных показателей (volume amounts), поддерживает диалог с абонентом для решения спорных вопросов. Заметим, что часть параметров согласовываются заранее — в режиме off-line. Например, тип валюты, объемных показателей, процедура начисления налогов и т. д.

Поясним суть методов “payment APIs” на примере получения записи футбольного матча:

• абонент выбирает матч и заключает договор с провайдером;

• провайдер, со своей стороны, получает идентификатор абонента MSISDN и другие данные о нем;

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

• провайдер может резервировать некоторый аванс до начала передачи (reserveAmount) как гарантию обязательств абонента;

• когда передача начинается, провайдер периодически снимает часть аванса (chargeReservation);

• если аванс кончается, его можно дополнить методом reserveAdditionalAmount;

• после матча фиксируется остаток денег (releaseReservation), который можно сохранить на следующую передачу.

Рассмотренный сценарий можно расширить участием абонента в тотализаторе, что может уменьшить его расходы — при выигрыше часть денег возвращается (refundAmount).

Интерфейс Amount Charging API имеет два метода: chargeAmount(EndUserIdentifier endUserIdentifier, Decimal amount, String billingText, String referenceCode) и refundAmount с такими же параметрами. Другие методы имеют похожие на chargeAmount параметры, поэтому их не будем указывать.

Account Management. Абоненты, которые подписались на режим оплаты Prepaid, независимо от вида услуги (предоплаченный телефонный разговор, SMS или передача данных) имеют аванс у провайдера, который уменьшается по мере получения услуг или обнуляется по истечении срока действия договора. Следовательно, время от времени абонент должен пополнять счет. Это производится напрямую через кассу или через WAP/web-страницу или даже SMS.

Использование кредитной карты требует еще удостоверения личности, и после верификации деньги зачисляются на счет абонента. Все эти разнообразные формы общения с абонентом предусмотрены в интерфейсах Parlay X Account Management API. Рассмотрим два сценария, которые поясняют суть методов сервиса Account Management.

Сценарий 1. Абонент пользуется новой картой предоплаты.

Рrepaid-абонент желает пополнить счет и запрашивает состояние баланса. Он общается с оператором посредством системы IVR. Абонент вводит номер карты пред-оплаты (voucher), личный идентификатор MSISDN и PIN-код. Система IVR общается с внешней базой данных и проверяет номер счета, после чего баланс абонента изменяется (voucherUpdate). Пользуясь методом getBalance, абонент узнает об изменении счета.

Сценарий 2. Абонент платит непосредственно.

Предполагаем, что абонент общается с web-страницей. После введения идентификатора MSISDN и PIN-кода он запрашивает баланс (getBalance). Для изменения счета абонент вводит данные своей кредитной карты, после чего состояние его счета и сроки его годности (expiration date) меняются (balanceUpdate). Для верности абонент запрашивает новый срок годности (getCreditExpiryDate).

Нерешенные вопросы идентификации

Международная организация Liberty Alliance была создана в декабре 2001 г. и изначально объединила 20 компаний, а ныне их более 160. Ее цель — разработать стандарты идентификации, точнее: набор web-сервисов, который бы обеспечил сохранность личных данных и безопасность для всех участников процесса идентификации: пользователей, провайдеров идентификации и провайдеров услуг. Областью действия стандартов Liberty являются практически все аспекты платежной системы, приведенной на рис. 6.

К настоящему моменту эти стандарты еще не разработаны. В августе 2004 г. Консорциум PayCircle опубликовал доклад, в котором описываются  перспективы интеграции спецификаций PayCircle в составе документов Liberty. Работа ведется над двумя моделями стандартизации службы идентификации.

Модель 1. Сервер идентификации принадлежит мобильному оператору. В этом случае следует рассмотреть шесть связей (рис. 8):

• пользователь просматривает сайт продавца и посылает запрос на покупку;

• продавец (Merchant) проводит аутентификацию пользователя — посылает запрос серверу идентификации;

• продавец желает обеспечить гарантированную оплату и посылает запрос в платежную систему (payment service). Эта связь может включать несколько транзакций;

• платежная система общается с сервером идентификации для обеспечения безопасности транзакций;

• взаимодействие с пользователем (User Interaction) для получения его согласия на покупку. Liberty изучает три варианта взаимодействия: идти через сайт продавца, используя его как прокси для запроса согласия. Этот вариант предполагает высокое доверие к продавцу, например, следует получить подпись покупателя, что предполагает наличие физического соединения между покупателем и продавцом, например, в виде Web- или WAP-сеанса. Перенаправить пользователя к платежной службе, что является наиболее типичным для web-приложений. Особенно, если платежная служба является клиентом солидного банка или национального мобильного оператора. Конечно, это опять предполагает наличие физического соединения между покупателем и продавцом, например, Web или WAP-сеанса. Воспользоваться независимым сервисом, например, подтвердить согласие при помощи SMS или WAP Push. Этот вариант не требует наличия физического соединения между покупателем и продавцом;

• доставка требуемой услуги (игра, мелодия и т. п.), подтверждение покупки.

Модель 2. Наличие внешней платежной службы. Основное отличие от прежней модели состоит в том, что продавец не входит в единую область доверия. (Circle of Trust, CoT —  группа провайдеров услуг и провайдеров идентификации, объединенных деловыми контактами и операционными соглашениями (согласно архитектуре Liberty), которые позволяют безопасно общаться с пользователями.) Например, в условиях роуминга пользователь хочет что-то купить в местном магазине. Та же ситуация разрыва единой связи доверия возникает, когда  продавец имеет соглашение с компанией кредитных карт, а пользователь (покупатель) — с банком.

В этой модели имеются две области доверия (рис. 9): платежная (Payment CoT) и операторская (Operator CoT). Когда продавец пытается аутентифицировать пользователя, он не получает ответа на запрос аутентификации, поскольку не имеет непосредственной деловой связи с пользователем. Для решения этой задачи Liberty вводит модель прокси-аутентификации, которая имеет следующие шаги:

• пользователь посылает запрос на покупку (как в прежней модели);

• продавец посылает запрос аутентификации. Однако он не имеет связи с провайдером идентификации пользователя (Customer IDP), а может послать запрос только в собственный IDP (Identity Provider, IDP — это Web-портал, который создает и хранит информацию по идентификации. Он имеет свой интерфейс, службу аутентификации, справочную по пользователям);

• на основе соглашения между двумя областями доверия (Inter CoT Business agrement), Payment IDP общается с Operator CoT и переправляет запрос аутентификации;

• продавец общается с местной платежной служба Local PayCircle;

• платежное требование переправляется в платежную систему пользователя Remote PayCircle;

• платежная служба запрашивает согласие пользователя;

• возвращение окончательного платежного документа.

Заключение

Ядром архитектуры сетей связи нового поколения NGN является мультимедийная подсистема IMS, а в ней ключевую роль играют вопросы тарификации, которые всесторонне разрабатываются консорциумом 3GPP.

Рассмотрены сервисы тарификации в архитектуры Parlay X, которые разработаны организацией PayCircle и приняты в качестве стандартов в ETSI и 3GPP.

Рассмотрены еще нерешенные вопросы идентификации, чем сегодня заняты организации PayCircle и Liberty Alliance. В работе этих организации следовало бы принимать участие представителям российских мобильных операторов.