ность абонента (FF13–FF2), а после выбора услуги — его права на предоставление услуги (FF14) как с точки зрения перечня услуг, так и баланса его лицевого счета (FF14–F8). При балансе счета, достаточном для предоставления услуги, услуга пре- доставляется и тарифицируется (FF15) в процессе предоставления. Формируется транзакция (FF16), которая запоминается в таблице транзакций (FF15). В текущем счете отражается накопительная стоимость услуги, а в лицевом счете баланс умень- шается на стоимость оказанной услуги.

При авторизации по паролю доступа (FF13) первое обращение за получением ус- луги проводится к FF1, а последующие к FF3. Авторизации для функции пополне- ния всегда проводится к FF1, при этом перевод средств как со счета предоплачен- ных инструментов на аналогичный счет, так и со счета предоплаченного инстру- мента на персонифицированный лицевой счет проводится в рамках компоненты FF17 и ее взаимосвязей с компонентами FF8 через компоненту FF7.

Генерация отчетов реализуется FF18, при этом для получения разного типа отче- тов по услугам или состояний этих счетов проводится обращение к соответствую- щим компонентам ведения счетов, а для получения детализированных отчетов — к компоненте FF12.

При рассмотрении второго примера (см. рис. 5.8) обратим внимание в основном на новые функциональные компоненты и их взаимосвязи.

Как и в первом примере, организуются предварительные функциональные ком- поненты в виде FF1, FF2, FF4, FF6. Среди функциональных компонент присутствуют аналогичные первому примеру компоненты FF7, FF8, FF10, FF12, FF18. Ряд компо- нент, аналогичных по функциям, например FF13 и FF15, присутствуют в модифици- рованном виде. Кроме того, появляются новые компоненты FF19, FF20, FF21.

Логика предоставления услуги будет выглядеть следующим образом: с помощью FF19 (которая реально может быть представлена в виде двух компонент сбора и предоб- работки) проводится накопление CDR в УБС, далее в соответствии с данными FF8 про- водится авторизация модифицированной компонентой FF13, после чего реализуется компоненты FF15 и FF20, на выходе которых имеются транзакции, направляемые в FF12.

Пополнение лицевых счетов осуществляется путем перевода средств от FF7 че- рез FF21. И наконец, генерация отчетов проводится стандартными методами с помо- щью FF18.

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

5.4. Поддержка предоставления услуг

При рассмотрении концептуальной модели УБС в ней выделены пункт эксплуата- ционной поддержки и администрирования услуг (SMAP) и пункт администрирова- ния услуг (SMP). Функции SMAP должны осуществлять системное и технологиче- ское администрирование услуг, а также проведение программно-технической под- держки. SMP, основной функцией которой является создание среды услуг, в каче-

стве дополнительной и естественной функции берет на себя мониторинг функцио- нирования как ИУ УБС, так и всей системы в целом, а также статистическую обра- ботку накопленной информации.

Реализация вышеперечисленных функций должна обеспечиваться двумя основ- ными возможностями: интеграцией обеих точек в сетевую структуру УБС и нали- чием соответствующих функциональных компонент отдельно или в совокупности, позволяющих решать поставленные задачи.

Интеграция SMP и SMAP в сетевую структуру УБС обеспечивается подключени- ем их к локальной сети центрального узла (СBSN), а также основана на использова-

нии аналогичных возможностей с SCP CBSN по доступу к другим периферийным уз- лам (см. рис. 5.4) и их SCP. При этом, как упоминалось выше, существует однознач-

ная зависимость от способа построения телекоммуникационной сети (см. Приложе- ние 3.2). Исходя из этого, становится очевидным, что шлюзы, используемые для ин- теграции SMP и SMAP в сетевую структуру УБС, аналогичны шлюзам SCP.

Рассмотрим совокупность функциональных компонент, обеспечивающих реали- зацию заявленных функций. Поскольку имеется явная аналогия с реализацией логики услуг, функциональные компоненты SMP и SMAP (которые в дальнейшем будем обозначать как FFM) могут быть рассмотрены так же, как и разд. 5.3, и трактоваться как дополнительные услуги администрирования (mSF). Остается открытым вопрос реализации интерфейсов доступа к FFM. Здесь возможны два варианта. Первый и часто используемый в настоящее время вариант реализует интерфейсы администра- тивного уровня на информационном уровне УБС. Это дает возможность разделить уровни УБС не только по функциональным характеристикам, но и по функциям об- служивающего персонала. Однако в соответствии с тенденциями интеграции УБС в единую систему управления оператора связи такой вариант менее приемлем с точки зрения оптимизации системы управления. В предложенной автором концептуальной модели целесообразно вынести эти интерфейсы из информационного уровня (ИУ) на клиентский уровень (КУ), чтобы обеспечить единство управления УБС, а также ре- шить многие аспекты вопросов безопасности, о которых речь пойдет ниже.

Рассмотрим необходимую и достаточную совокупность функциональных ком- понент FFM для реализации мониторинга точек и узлов УБС (mSFM), а также сбо-

ра и анализа статистической информации (mSFS).

В соответствии с определением мониторинг несет в себе две функции: проверку работоспособности отдельных функциональных элементов и совокупности этих эле- ментов и работоспособности системы в целом. Поэтому мониторинг должен быть как минимум трехуровневый. Для реализации первого уровня мониторинга каждый функциональный элемент должен выполнять диагностику работоспособности. На ос- нове анализа результатов диагностики и должны функционировать FFMdr, где r — номер соответствующей функции. Реализация второго и третьего уровня мониторин- га основана на стандартах, принятых для УБС, в частности на российских стандартах сертификации автоматизированных систем расчетов с абонентами. В соответствии с этими стандартами мониторинг может быть реализован путем выполнения локально- го или общего контрольного примера. Суть контрольного примера заключается в по- даче на вход локального функционального узла или всей системы заранее известного

5.5. Клиентский уровень

Рассматривая системную архитектуру УБС, автор не случайно выделил в ней ин- формационный и клиентский уровень (соответственно, ИУ и КУ). К КУ были отне- сены все функции автоматизированного взаимодействия ИУ с пользователем. На клиентский уровень вынесены также интерфейсы административного взаимодейст- вия с информационным уровнем. Таким образом, клиентский уровень УБС можно рассматривать как некоторый универсальный шлюз, через который пользователь и администрация оператора взаимодействуют с УБС. Под взаимодействием служб КУ и ИУ подразумевается как ручное взаимодействие на основе интерфейсов, так и автоматическое взаимодействие между УБС с функциональными автоматизирован- ными системами оператора, например системой бухгалтерского учета. Данный под- ход, по-видимому, справедлив и для других построений КУ. Однако, для опреде- ленности, специально остановимся на конкретной реализации этого уровня.

К основным службам КУ (кроме административной, о которой говорились вы- ше) необходимо отнести (рис. 5.10):

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

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

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

–службу продаж, которая осуществляет технологию продаж платежных инст- рументов, в частности, на основе открытой оферты;

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

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

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

Служба договоров. Взаимодействие данной службы с пользователем осуществ- ляется, как правило, на основе реального контакта. Функционирование службы предусматривает хранение информации по заключенным договорам и передачу на ИУ необходимой информации для генерации лицевых счетов абонента, таких, на- пример, как номер и дата заключения договора, выделенный сетевой номер абонен- та, перечень предоставляемых услуг и т.д. Кроме того, данная информация должна включать индивидуальные договоренности между оператором и абонентом, такие, например, как способ расчетов, принципы и формы осуществления расчетов, инди-

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

Операторы абонентской службы осуществляют управление функциональной компонентой по генерации отчетов за биллинговый период и направляют информа- цию о стоимости предоставленных услуг по каждому лицевому счету в бухгалтер- скую службу, которая формирует счета на оплату. Сформированные счета вместе с отчетами, которые являются детализацией счета, направляются пользователем для оплаты. Средства, полученные от абонентов по каждому лицевому счету, отража- ются в бухгалтерии и напрямую или через операторов абонентской службы расче- тов отражаются на лицевых счетах пользователя в УБС. В течение установленного срока оплаты счетов пользователями абонентская служба расчетов осуществляет контроль поступления средств от пользователей и, в случае отсутствия поступле- ния средств, управляет блокировками их лицевых счетов в УБС.

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

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