Публикации

Oracle BRM – применение для целей информационной поддержки взаиморасчетов между операторами

Цель написания статьи

 

Целью данной статьи явилось желание поделиться опытом настройки автоматизированной системы расчетов (АСР) Oracle BRM для поддержки межоператорских расчетов за услуги присоединения и пропуска трафика – задачи, традиционно достаточно сложной в реализации операторского класса.

 

АСР OC BRM (Oracle Communications Billing & Revenue Management) – бывшая система Portal Infranet – имеет опыт уже нескольких инсталляций в России, и по нашему мнению интерес к ней будет только усиливаться, поскольку данный продукт является одним из лучших в своем классе, будучи охарактеризован следующими чертами:

  • Концептуальной логичностью, стройностью и связностью;
  • Имманентно присущей продукту конвергентностью в плане единообразного моделирования артефактов процесса оказания услуг связи, биллинга и оценки стоимости услуг и применения единообразной модели обработки данных для различных услуг;
  • Масштабируемостью;
  • Наличием отдельного продукта в составе Oracle BRM – конвейерного оценщика стоимости услуг (Oracle Pipeline Framework);
  • Наличием огромного числа «кирпичиков», созданных для обеспечения того или иного функционала – грамотное применение этих кирпичиков позволяет собрать решение по сути для любой задачи, связанной с оценкой стоимости услуг и отражением их на счетах пользователей.

 

Вместе с тем, именно наличие множества путей, ведущих к цели с различной эффективностью, в условиях достаточно сложной модели Интерконнекта в России, реализуемой с учетом норм и возможностей Регулятора, делает актуальной оценку всего спектра возможностей и каждого конкретного решения, за видимой вершиной которого лежит невидимая «подошва айсберга» в виде множества вариантов решений, которые не оказались эффективными и были отброшены по ходу настройки и кастомизации АСР для поддержки операторского бизнеса Интерконнекта.

 

Попутно отметим, что в Oracle BRM практически не делается различий между Интерконнектом операторов фиксированной связи и поддержкой роуминговых расчетов операторов мобильных сетей, хотя имеющиеся компоненты «заточены» скорее на поддержку роуминговых взаимодействий, в то время как мы далее будем говорить именно о задаче расчетов за услуги пропуска трафика.

 

Потребности поддержки межоператорских расчетов

 

Перечислим основные требования к поддержке межоператорских расчетов:

  • Возможность выделения на основе данных трафика различных видов услуг пропуска трафика с последующей оценкой их с применением различных тарифных планов;
  • Возможность оценки стоимости записей с использованием различных параметров (учет точки присоединения, транкгруппы, маршрута прохождения соединения, вызывающего и вызываемого номеров, дня и времени соединения, длительности соединения и т.п.);
  • Возможность применения различных схем дисконтирования стоимости;
  • Оценка услуг в различных валютах;
  • Оценка стоимости и контроль доходов как в отношении услуг, оказываемых партнеру (доходы оператора), так и в отношении услуг, оказываемых партнером (расходы оператора)
  • Поддержка процесса формирования и выставления счетов за услуги присоединения и пропуска трафика
  • Поддержка процессов сверки результатов расчетов с данными партнеров.

 

Для моделирования процесса предоставления услуг и расчетов за предоставленные услуги присоединения и пропуска трафика прежде всего необходимо определить соответствующие продукты.

 

Определение продуктов Интерконнекта

 

Продукт (product) является одним из базовых понятий Oracle BRM и достаточно близок к определению продукта (product) в соответствии с материалами TM Forum. Наряду с продуктами в Oracle BRM используются понятия сделки (deal) и плана (plan). Еще более фундаментальным понятием в Oracle BRM является понятие сервиса (service). Говоря о сервисе, используется как сервис в понимании «класс» и в этом смысле на нем определяется продукт – как составная часть каталога продуктов, так и сервис в понимании «экземпляр» - в этом случае продукт в случае продажи плана или сделки устанавливается на сервисе.

 Детальное обсуждение возможных путей отображения понятий Oracle BRM (сервис, продукт, сделка, план) на классические понятия модели TM Forum (ресурс - услуга (сервис) – продукт) выходит за рамки данной статьи, поэтому далее мы иллюстрируем две возможных и при этом доказательно реализуемых схемы такого отображения.

 

Первая схема предусматривает наборы индивидуальных продуктов для каждого оператора – партнера, соответствующие наборам услуг, определенным в договорах между партнерами.

 Для услуг Интерконнекта определим два сервиса: /service/ic/s2p, /service/ic/s2o – именно сервис, предоставляемый партнеру, и сервис, предоставляемый оператору со стороны партнера, все сервисы в Oracle BRM наследуются от одного предка (/service).

 

Для каждой пары взаимодействующих в соответствии с заключенным договором субъектов (оператор и партнер) создается два набора продуктов – один набор основан на сервисах /s2p и представляет, соответственно,  продукты, предлагаемые партнеру в рамках предоставления ему услуг присоединения и пропуска трафика, второй набор основан на сервисах /s2o и представляет продукты, предлагаемые оператору партнером.

 

Для каждого продукта в целях продажи должна быть определена по крайней мере одна сделка. Сделки позволяют управлять изменчивостью продуктов и кастомизировать предложения клиентам, не увеличивая количества базовых продуктов.

 Наконец, продукты (точнее - сделки) объединяются в планы. Соответственно двум наборам продуктов, должны быть созданы и два плана – один определяет все продукты, которые продаются партнеру при заключении договора об услугах присоединении и пропуска трафика, второй – которые продаются оператору.

 

В этой схеме предусмотрено создание планов, включающих такое количество экземпляров сервиса, сколько услуг предусмотрено договором (в каждом направлении – т.е. от Оператора – Партнеру и от Партнера - Оператору), на каждый экземпляр устанавливается соответвующая сделку (продукт). Таким образом, после продажи плана услуг Интерконнекта, состоящего из n сделок (продуктов), каждая из которых определена на одном и том же типе сервиса (/s2o или /s2p), создаются n экземпляров сервисов – каждый экземпляр сервиса соответствует услуге Интерконнекта – именно такой, как она зафиксирована условиями соответствующем договоре. Соотношения между понятиями, определенными выше, иллюстрируют нижеследующием рисунке:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

При создании экземпляра сервиса создается его идентификатор, на основании которого при обработке потока CDR может быть определен соответствующий продукт и далее - лицевой счет, которому он предоставлен. Таким образом, задача сводится к тому, чтобы на основе данных CDR определить идентификатор экземпляра сервиса, или - что то же самое – идентифицировать услугу Интерконнекта в соответствии с условиями договора между партнерами на основе сведений о точках присоединения, транкгруппах, номерах вызывающего и вызываемого и т.п.

 

Вторая схема отличается от первой тем, что набор продуктов создается в соответствии с набором услуг пропуска трафика, определенным Регулятором (услуге пропуска трафика, определенной Регулятором, соответствует единственный продукт) и используется по этой причине для всех партнеров. На основе этих продуктов создаются сделки, которым уже соответствуют услуги, определенные по договору между партнерами, которые объединяются в планы.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

В остальном схемы не отличаются. Для того, чтобы один и тот же продукт мог быть оценен различным образом, с продуктом (в случае применения Oracle Pipeline) связывается план оценки (rate plan) , который, в свою очередь, основан на применении селекторов ценовых моделей (price model selector).

 

Альтернативным по отношению к двум рассмотренным выше схемам способом моделирования связей между продуктами и экземплярами сервисов является применение для характеристики создаваемых сервисов и последующего поиска продукта и лицевого счета метафоры устройств (device) Oracle BRM – в этом случае экземпляр сервиса связывается с неким устройством, которые для услуг Интерконнекта могут представлять атрибуты точек присоединения и идентифицироваться, например, посредством транкгрупп (транкгруппы - не единственный способ определения характеристик точек присоединения). Применение метафоры device для управления предоставлением услуг Интерконнекта в модели Oracle BRM вступает в конфликт с потребностью в ряде случаев вести раздельный учет услуг Интерконнекта, различимых исключительно по атрибутам CDR (например по характеристикам вызывающего/ вызываемого номеров), с другой стороны – нет смысла вести раздельный баланс услуг пропуска трафика по различным транкгруппам. По этой причине эта возможность далее не рассматривается, хотя отметим, что те же идентификаторы экземпляров сервисов, о которых шла речь выше, могут также моделироваться посредством идентификаторов устройств. В этом случае, с одной стороны, для идентификации клиента может использоваться стандартная процедура идентификации на основе создаваемого Oracle BRM т.н. «alias list», ассоциированного с экземпляром сервиса, с другой стороны – это усложняет реализацию, не создавая иных достоинств.

 

Таким образом, последовательность шагов, целью которой является оценка стоимости услуг пропуска трафика, включает:

  • Загрузку данных из систем предбиллинга (mediation system) оператора в систему идентификации услуг пропуска трафика;
  • Идентификацию услуг пропуска трафика (на этом этапе стоимостная оценка не выполняется), результат которой - определение идентификаторов экземпляров сервисов Oracle BRM;
  • Накопление и отображение данных Интерконнекта в натуральных показателях;
  • Стоимостную оценку идентифицированных услуг пропуска трафика и отражение начислений на лицевых счетах партнеров.

 

Данные шаги рассмотрены далее с указанием того, какие функции и компоненты Oracle BRM были использованы при их реализации. Предложенное архитектурное решение расчетов за услуги Интерконнект с использованием Oracle BRM представлено на следующем рисунке:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Загрузка CDR из систем предбиллинга

 

Для загрузки данных из систем предбиллинга оператора для последующей обработки в целях идентификации услуг пропуска трафика целесообразно использовать Oracle BRM Pipeline Manager, что позволяет:

  • Выполнять необходимые операции обработки записей (включая фильтрацию, агрегацию, корреляцию, преобразование форматов и значений, обогащение данных);
  • Обеспечить использование функций контроля доходов (Revenue Assurance) и прослеживание всего тракта обработки исходных файлов CDR в рамках расчетов за услуги Интерконнекта – от поступления исходных файлов до отражения данных на счетах партнеров.

 

Поддержка ведения данных по структуре взаимодействия сетей операторов

 

Для целей идентификации услуг пропуска трафика данных необходима поддержка ведения следующих данных, отражающих структуру взаимодействия сетей операторов:

  • Данных, на основе которых выполняется идентификация точек присоединения (сетевые элементы, транкгруппы,интерфейсы PRI или иные идентификаторы каналов);
  • интервалов, схем и зон нумерации – для выполнения анализа по номерам, присутствующим в атрибутах CDR, если это необходимо для идентификации услуги;
  • правил идентификации услуг пропуска трафика на основе атрибутов CDR в соответствии с условиями договора;

Указанные функции реализуются в отдельном клиентском приложении идентификации услуг пропуска трафика (Interconnect Business Suite).

 

Ведение договоров и лицевых счетов

 

Ведение лицевых счетов (account) выполняется при помощи клиентского Приложения Центр обслуживания абонентов (Oracle BRM Customer Center). Для каждого договора о взаимном предоставлении услуг присоединения и пропуска трафика создаются два лицевых счета – владельцем одного является оператор, другого – его партнер, соответственно на этих лицевых счетах отражаются «доходные» и «расходные» услуги пропуска трафика (определяемые с точки зрения оператора).

 Клиентское Приложение идентификации услуг пропуска трафика предоставляет и использует на уровне GUI ссылки на лицевые счета Oracle BRM, созданные посредством Customer Center, и продукты, созданные посредством клиентского приложения поддержки ведения Каталога продуктов (Oracle BRM Pricing Center).

 

Варианты стоимостной оценки услуг пропуска трафика. Конвейерная оценка стоимости услуг (применение Pipeline Manager)

 

Oracle BRM предусматривает применение двух способов оценки стоимости услуг полученных в составе CDR файлах:

  • Посредством Oracle BRM UEL (Universal Event Loader);
  • Посредством применения Oracle BRM Pipeline Manager с последующей загрузкой услуг через REL (Rated Event Loader).

 

Первый способ использует схемы тарификации реального времени, второй - схемы пакетной отложенной обработки записей на платформе Oracle BRM Pipeline Framework. На основе Pipeline Framework конфигурируются экземпляры Pipeline Manager.

 

По понятным причинам нами для обработки потока CDR, прошедших этап идентификации услуг пропуска трафика, был использован вариант конвейерной обработки посредством Pipeline Manager.

Система идентификации не буферизует проходящие через нее данные и в случае, если полученные от нее CDR отбрасываются позднее Pipeline Manager на этапе проведения стоимостной оценки услуг, дальнейшая обработка CDR выполняется в соответствии с одной из политик обработки отброшенных (rejected) записей, предусмотренных Oracle BRM. Сформированный при этом Pipeline Manager файл отброшенных записей (в которые входят в том числе и записи, для которых ранее оказалось невозможным идентифицировать услугу Интерконнекта), повторно направляются на обработку с использованием модуля идентификации услуг Интерконнекта и/или модуля Pipeline Manager, выполняющего стоимостную оценку.

 

Записи, успешно прошедшие обработку Pipeline Manager, предназначенным для стоимостной оценки услуг Интерконнекта, поступают на вход Oracle BRM REL и загружаются в базу данных Oracle BRM, после чего данные об оказанных услугах отражаются на лицевых счетах партнеров Интерконнекта. Вся последующая обработка данных неспецифична для услуг Интерконнект и выполняется аналогично обработке для других услуг.

 

Контроль утечки доходов (Revenue Assurance)

 

Oracle BRM предусматривает богатые возможности контроля за потоками генерации доходов с целью их контроля и недопущения потери. Для целей расчетов за услуги Интерконнект были определены два потока - генерации доходов и расходов соответственно и несколько контрольных точек, в которых в соответствии с выбранными сценариями (Oracle BRM предполагает набор готовых к применению сценариев и возможно создание дополнительных) происходит накопление данных по прохождению потоков, которые затем могут анализироваться при помощи клиентского Приложения Oracle BRM Business Operation Center (Revenue Assurance Center).

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Возможности кастомизации Oracle BRM

 

Oracle BRM предусматривает различные способы кастомизации и настройки, включая настройку предусмотренных конфигурационных объектов, изменение хранимых классов, программ – опкодов, изменение функционала существующих или создание новых клиентских приложений, а также построение различных архитектур конвейерной обработки записей оказания услуг на основе Oracle BRM Pipeline Framework.

 

Выводы

 

В статье рассмотрена реализация задачи поддержки расчетов за услуги присоединения и пропуска трафика (Интерконнект) на основе функциональных возможностей АСР Oracle BRM, предусматривающая совместное использование:

  • механизма конвейерной отложенной обработки (Pipeline Manager) для целей загрузки данных из систем медиации оператора и стоимостной оценки услуг Интерконнекта,
  • Oracle BRM Customer Center для поддержки ведения лицевых счетов партнеров;
  • Oracle BRM Pricing Center для поддержки ведения продуктов Интерконнекта;
  • отдельного разработанного в процессе решения задачи информационной поддержки взаиморасчетов между операторами связи модуля идентификации услуг пропуска трафика (Interconnect Business Suite);
  • сервера отчетов Oracle BI Publisher для предоставления отчетов по услугам присоединения и пропуска трафика.

 

Реализация доказала высокую степень настраиваемости Oracle BRM с целью удовлетворения договорным условиям расчетов по услугам присоединения и пропуска трафика в соответствии с нормами регулятора и возможность применения преимущественно готовых компонентов для решения данной задачи.

 

Авторы выражают свою искреннюю признательность и благодарность господину Хольгеру Зоммерфельду (Holger Sommerfeld) за плодотворное сотрудничество, консультации и всестороннюю помощь в процессе работы с Oracle BRM.

Вячеслав Шатохин, Ярослав Лисовский

Все статьи

+7 495 125 20 36