9.5.2. Концептуальная модель убс

Если обратиться к абстрактной концептуальной модели ИСС, то в соответствии с рекомендациями ITU-T 1.312/Q. 120.1, она состоит из четырех плоскостей, отражаю­щих абстрактный подход к описанию ИСС. Модель разделяет аспекты, относящие-ся к услугам, и аспекты, связанные с сетью, на базе которой предоставляются услу­ги [1, 2].

Данный подход справедлив и для построения концептуальной модели УБС (рис. 9.1).

Рис. 9.1.

Естественно, что данный подход применительно к УБС имеет свои отличия, в частности, вместо вызовов из модели ИИС в модели УБС должны использоваться запросы и записи детализации соединения (Connection Detail Records, CDR, см. гла­ву 4), но в целом, как будет показано ниже, этот подход позволяет достаточно про­сто и логично построить концептуальную модель биллинговой системы.

Итак, первая плоскость — плоскость услуг (Service Plane) - - представляет взгляд на УБС исключительно с точки зрения услуг. В этой плоскости отсутствует информация о том, как именно осуществляется предоставление услуг биллинга данной системой.

Вторая плоскость — глобальная функциональная плоскость (Global Functional Plane, GFP) — описывает возможности УБС, которые необходимы разработчикам для внедрения услуг. В этой плоскости УБС рассматривается как единое целое и вводятся базовые процессы обработки событий (Basic Event Process, ВЕР) и незави­симые от услуг конструктивные блоки (Service-Independent Building Block, SIB).

Третья плоскость — распределенная функциональная плоскость (Distributed Functional Plane, DFP) -- описывает функции, реализуемые узлами УБС. В этой плоскости УБС рассматривается как совокупность функциональных элементов, по­рождающих информационные потоки.

Четвертый уровень — физическая плоскость (Physical Plane, PP) — описывает узлы УБС с содержащимися в них функциональными элементами и протоколами взаимодействия.

Остановимся подробнее на каждой из перечисленных плоскостей.

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

Под операцией мы будем понимать обработку (прием, собственно обработку, ответ) отдельных запросов, законченные действия с информацией и другие дейст­вия, которые могут быть реализованы с помощью элементарных стандартных бло­ков. Под функциональными компонентами (Function Feature, FF) мы будем пони­мать совокупность операций (например, процесс авторизации может состоять из операций приема, анализа и ответа), которая подразумевает не только их набор, но и последовательность действий. Совокупность функциональных компонент позво­ляет реализовать компоненты услуги (Service Feature, SF) биллинга, из которых и состоит конечная услуга-вещество.

Раннее мы рассматривали различные виды биллинга, характеристиками ко­торых являются способы предоставления услуги off-line, on-line и hot-line. С дру­гой стороны, услуги биллинга можно подразделить по типу взаиморасчетов меж­ду субъектами: post-paid (кредитный), pro-paid (дебетовый) и p/pre-paid (псев­додебетовый). (Напомним, что псевдодебетовый способ предусматривает тарифи­кацию и начисление оплаты сразу по окончании предоставления услуги, т.е. на сче­ту пользователя может образоваться отрицательное сальдо только за счет предос­тавления последней услуги.) Таким образом, каждая из услуг биллинга может быть представлена совокупностью определенных компонент услуги по виду и типу биллинга. В свою очередь, каждая из компонент услуги состоит из набора функцио­нальных компонент, выполняемых в определенной последовательности.

Определим следующий набор компонент услуги (SF) или, в частном случае, простой услуги:

• off-line post-paid;

• on- line post-paid;

• on-line p/pre-paid;

• hot-line post-paid;

• hot-line pre-paid;

• пополнение hot-line pre-paid;

• пополнение hot-line post-paid;

• пополнение hot-line post-paid;

• пополнение on -line post-paid;

• роуминг.

Рассматривая компоненты услуг биллинга, необходимо учитывать, что даже од­нородные компоненты будут различны для сетей с коммутацией каналов и пакет­ной коммутацией, а также для основных и дополнительных услуг, оказываемых этими сетями. Таким образом, каждая из указанных выше компонент услуги будет иметь свою модификацию в области услуг связи.

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

В реальной плоскости услуг каждая компонента может быть связана как с од­ной, так с различными услугами биллинга, поэтому целесообразно выделить про­стые и составные компоненты.

Обозначим услугу биллинга как SB, простую компоненту как SBf, а составную компоненту как SBF. В этом случае сложная компонента SBFy будет сочетанием простой компоненты SBf_b определяющей вид и тип биллинга, и простой компонен­ты SBfj как одной из составляющей биллингуемой услуги. Поскольку, как отмечено выше, каждая из услуг может быть реализована как одной, так и совокупностью компонент, то SB_m = {SBFy}. В Приложении 5.1 данные вопросы рассматриваются более подробно. При этом можно отметить, что на реальной плоскости услуг будут отражена вся совокупность услуг SB = {SB_m}.

Рассматривая плоскость услуг (см. рис. 5.1), мы выделяем на ней функциональ­ные компоненты FFk, которые могут быть реализованы совокупностью простых операций, имея в виду, что SB_m = {FF_k}.

Глобальная функциональная плоскость (GFP) в рамках концептуальной модели включает следующие основные элементы:

• базовый процесс обработки событий (ВЕР);

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

• точки инициации (POI) и точки завершения (POR).

Базовый процесс обработки событий (ВЕР) по сути представляет собой специа­лизированный конструктивный блок. Поскольку под событием мы будем понимать как обработку запросов для формирования CDR, так и собственно обработку CDR, то для обработки события необходимы две базовые процедуры: для запросов -BRqP (Basic Request Process) и для записей — BRP (Basic Records Process). Блоки SIB обеспечивают выполнение стандартных многократно используемых сетевых функций. Базовый процесс обработки событий является специализированным SIB, который взаимодействует с другими блоками посредством точек инициации и за­вершения. В частности, когда в процессе обработки записей встречается одна из то­чек инициации, то это приводит к соответствующей последовательности обраще­ний к блокам SIB (см. рис. 9.1). По завершении этой последовательности осуществ­ляется воздействие на процесс обработки CDR, зависящее от точки завершения. В результате такого взаимодействия может быть инициирован компонент услуги. Та­ким образом, BRP описывает процесс обработки CDR, поступающих из узла пре­доставления услуг, или формирования CDR в процессе предоставления услуг. В случае обработки последовательности запросов, в результате которой формируется CDR, точки инициализации и завершения для последовательности SIB могут отно­ситься как к каждому запросу, так и к их последовательности. Надо отметить, что реакцией на запрос может быть передача как логической функции, так и функции управления, в частности управляющие команды для взаимодействия с пользовате­лем. Услуги, определенные в разрезе первой плоскости модели ВС, декомпозиру­ются на компоненты и на плоскости GFP и объединяются в совокупность SIB, кото­рые при взаимодействии определяют глобальную логику услуги GSL (Global Ser­vice Logic) (см. рис. 9.1).

На рис. 9.2 показан пример процесса взаимодействия GSL и BRP, осуществляе­мого через точки POI и POR

Рисунок 9.2. - Пример взаимодействия GSL и BRP

В распределенной функциональной плоскости определяются общесетевые функ­ции в виде отдельных функциональных объектов (Function Element, FE). Специфи­цированные на плоскости GFD блоки SIB реализуются на плоскости DFP в виде по­следовательности функциональных объектов (Function Element Array, FEA), в ре­зультате выполнения которой возникают информационные потоки (Information Flows, IF).

В свою очередь, функции делятся на четыре основные категории: 1 — функции, управления событиями; 2 — функции управления услугами; 3 — функции взаимо­действия между функциями 1 и 2 категорий; 4 — функции, обеспечивающие услуги (эксплуатационная поддержка и администрирование сети).

К функциям управления событиями (Event Control Function, ECF) относятся:

• функция управления запросами (Request Control Function, RqCF);

• функция управления доступом к запросам (Request Control Agent Function RqCAF), которая обеспечивает системе получение доступа в любую сеть, т.е. является интерфейсом между системой предоставления услуг и RqCF;

• интегрированная функция управления записью (Integrated Records Control Function, IRCF), при этом термин «интегрированная» подчеркивает возмож­ность обслуживания CDR из различных сетей;

• интегрированная функция управления доступом к записи (Integrated Records Control Agent Function, IRCAF), которая обеспечивает системе получение дос­тупа в любую сеть, т.е. является интерфейсом между системой предоставле­ния услуг и IRCF;

• функция взаимодействия с административным уровнем пользователей (User Administration Interaction Function, UAIF), которая поддерживает диалог с вспомогательным уровнем;

• функция взаимодействия с пользователем (User Interaction Function, UIF), ко­торая через SSF поддерживает диалог с пользователями-клиентами;

• функция доступа к специализированным ресурсам систем предоставления услуг (Integrated Specialized Resources Function ISRF), которая обеспечивает доступ сетевых объектов к различным категориям сетевых средств.

Ко второй категории относится функция управления услугами (Service Control Functin SCF), которая определяет логику услуг и управляет услугой, связанной с выполняемым процессом, а также и осуществляет взаимодействие между пользова­телем и функцией ISRF.

К третьей категории относятся:

• функция коммутации услуг (Service Switching Function, SSF), которая обеспе­чивает интерфейс между SCF и ECF;

• функция поддержки данных услуг (Service Data Function, SDF), которая управляет доступом услуг к базам данных сети и обеспечивает контроль данных, при этом обеспечивая логическую связь функции SCF с данными, «скрывая» от нее их реальное представление.

И наконец, к четвертой категории — обеспечения услуг — относятся (также как и для ГИС):

• функция среды создания услуг (Service Creation Environment Function, SCEF), которая используется для спецификации, создания, тестирования и загрузки программ логики услуг, а также для преобразования формата сообщений при организации диалога с пользователем;

• функция доступа к системе эксплуатационной поддержки и администрирова­ния услуг (так называемой рабочей станции) (Service Management Access Function, SMAF), которая обеспечивает интерфейс к функции SMF;

• функция эксплуатационной поддержки и администрирования услуг (Service Management Function, SMF), которая обеспечивает предоставление и админи­ стративное управление услугами.

Интерпретация схемы взаимосвязей, определяющая архитектуру распределен­ной функциональной плоскости, может быть представлена рис. 9.3.

а)

6)

Рисунок 9.3. - Схема взаимосвязей распределенной функциональной плоскости: а — для записей; б — для запросов

Физическая плоскость описывает пункты сети, содержащиеся в них функцио­нальные элементы и протоколы взаимодействия. На этом уровне определяются фи­зические объекты (Physical Element, РЕ), способы отображения функциональных объектов на физические и описываются способы реализации сетевых элементов УБС (рис. 9.4).

Под термином «пункт» (point) будем понимать, аналогично с терминологией ГИС, функционально законченный комплекс, выполняющий заданный круг задач. Для пункта сети, который выполняет функции коммутации услуг, введем так же, как и в ГИС, понятие «шлюз» (gateway), при этом имея в виду выполнение каждым типом шлюза определенного вида сетевых функций.

Некоторую совокупность пунктов ГИС, подключенных к узлу сети связи, назо­вем центральным (Central Billing Service Node, CBSN) или периферийным узлом ус­луг биллинга (Peripheral Billing Service Node, PBSN). Обозначения CBSN и PBSN введены из-за того, что для биллинговой системы узлы биллинга услуг, во-первых, будут иметь несколько другие функции, нежели для ИСС, а во-вторых, они так же, как и для ГИС, могут быть распределены по узлам сети.

Рисунок 9.4. - Физическая плоскость

Для CBSN можно выделить следующие основные виды пунктов:

• SSP (Service Switching Point) — пункт коммутации услуг, который обеспечивает коммутационные функции локальной сети, объединяющей все основные пункты и внешние шлюзы: шлюзы GO on-line и of-line (GOt — для выхода через сеть коммутации каналов и GOi — через сеть пакетной коммутации) и шлюзы GH hot-line (GHt — для выхода через сеть коммутации каналов и GHi — через сеть пакетной коммутации);

• SCP (Service Control Point) — пункт управления услугами;

• SDP (Service Data Point) пункт поддержки данных;

• SMP (Service Management Point) — пункт администрирования услуг;

• SCEP (Service Creation Environment Point) — пункт среды создания услуг;

• SMAP (Service Management Access Point) - - пункт эксплуатационной поддержки и администрирования услуг.

Распределение сетевых функций по пунктам УБС

Распределение сетевых функций по пунктам УБС имеет следующий вид:

Пункт коммутации услуг (SSP) реализует функцию коммутации услуг (SSF) и функцию управления событиями (ECF), в том числе:

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

• через GHi и GHt обеспечивает передачу CDR от SSP ГИС и узлов маршрутизации сети пакетной коммутации в SCP, а также управление через эти шлюзы диалогом с пользо вателем через IVR ГИС;

• через GOi и GOt обеспечивает передачу CDR от узлов коммутации и маршрутизации телекоммуникационной сети;

• через GCi и GCt обмен запросами и записями между SCP CBSN и SCP PBSN, а также обмен между SMP, SCEP, SMAP центрального узла услуг и SCP переферийных узлов;

Пункт управления услугами (SCP) выполняет функции предоставления услуг, обработки данных CDR (реализацию транзакций), управления услуг (SCF) и под­держки данных (SDF). SCP CBSN имеет прямой доступ к пункту поддержки дан­ных SDP CBSN, a SCP PBSN может подсоединяться к ней через соответствующие шлюзы.

Пункт поддержки данных содержит данные, необходимые для предоставления индивидуализированных услуг, в частности индивидуальные тарифные планы, а также для преобразования форматов данных с целью их передачи различным поль­зователям. Доступ к SDP CBSN из SCP PBSN может быть получен либо через соот­ветствующие шлюзы, либо через пункт управления услугами (SCP) или пункт ад­министрирования услуг (SMP). Различные пункты поддержки данных могут быть связаны друг с другом.

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

Пункт среды создания услуг выполняет функцию среды создания услуг и слу­жит для разработки, формирования, тестирования и внедрения услуг в пункте ад­министрирования услуг (SMP).

Пункт эксплуатационной поддержки и администрирования услуг обеспечивает доступ к пункту администрирования услуг (SMP).

Распределение основных функциональных пунктов по узлам предоставления услуг (CBSN и PBSN) и их взаимосвязи показаны на рис. 9.5.

Рисунок 9.5. - Распределение пунктов и их взаимосвязи

Таким образом, концептуальная модель УБС (аналогично ГИС) представляет собой важную часть абстрактной среды для создания услуг биллинга путем их по­следовательного описания «верху вниз»