- •ПРЕДИСЛОВИЕ
- •ЧАСТЬ 1. ПРЕДОСТАВЛЕНИЕ УСЛУГ СВЯЗИ
- •Глава 1. УСЛУГИ СВЯЗИ
- •1.1. Предоставление услуг связи
- •1.2. Дополнительные услуги
- •1.2.1. Классификация дополнительных услуг
- •1.2.2. Телематические услуги
- •1.2.3. Услуги с дополнительной интеллектуальной коммутацией
- •1.2.4. Услуги интеллектуального биллинга
- •1.2.5. Услуги передачи данных
- •1.2.6. Дополнительные транспортные услуги
- •1.3. Дополнительные возможности при предоставлении услуг
- •1.4. Составные и совокупные услуги
- •1.4. Некоторые практические выводы
- •Приложение 1.1. Основные аспекты анализа востребованности услуги и пути их продвижения
- •Приложение 1.2. Интеллектуальные услуги
- •Приложение 1.3. Основные сведения об IP-телефонии и ее статусе
- •Приложение 1.4. Предоставление совокупных услуг
- •Глава 2. КОМПЬЮТЕРНАЯ ТЕЛЕФОНИЯ
- •2.1. Исторические аспекты
- •2.2. Функции компьютерной телефонии и их реализация
- •2.2.1. Функциональная архитектура
- •2.2.2. Функциональная реализация
- •2.3. Приложения компьютерной телефонии
- •2.3.1. Универсальная почта
- •2.3.2. Контакт-центр
- •2.3.3. Центры оповещения и записи
- •Приложение 2.1. К вопросу об управлении системами компьютерной телефонии
- •Приложение 2.2. Функциональные возможности центра обработки вызовов
- •Глава 3. ГИБРИДНЫЕ ИНТЕЛЛЕКТУАЛЬНЫЕ СЕТИ
- •3.1. Предпосылки возникновения ГИС
- •3.2. Архитектура интеллектуальных сетей
- •3.3. Общее представление о гибридной интеллектуальной сети
- •3.3.1. Концепция построения ГИС
- •3.3.2. Концептуальная модель ГИС
- •3.3.3. Сетевые принципы взаимодействия
- •3.3.4. Создание логики услуг
- •3.4. Аппаратно-программная структура ГИС
- •Приложение 3.1. Концептуальная модель ИСС1
- •Приложение 3.2. Построение ГИС на базе сети ОКС №7
- •ЧАСТЬ 2. БИЛЛИНГ УСЛУГ СВЯЗИ
- •Глава 4. РАСЧЕТЫ ЗА УСЛУГИ СВЯЗИ
- •4.1. Понятие биллинга
- •4.2. Субъекты расчетов
- •4.3. Технология взаиморасчетов
- •4.4. Объекты бизнес-процесса биллинга
- •4.5. Способы оплаты и принципы взаиморасчетов
- •4.6. Виды биллинга
- •4.7. Инструменты и технологии оплаты
- •4.7.1. Пластиковые карты
- •4.7.2. Телебанкинг
- •4.7.3. Роуминг карт
- •4.8. Универсальный биллинг
- •Приложение 4.1. Оценка эффективности распределенного и централизованного способов биллинга
- •Приложение 4.2. Вопросы безопасности использования телекоммуникационных карт
- •Глава 5. СИСТЕМЫ РАСЧЕТОВ ЗА УСЛУГИ СВЯЗИ
- •5.1. Архитектура универсальной биллинговой системы
- •5.1.1. Концепция построения УБС
- •5.1.2. Концептуальная модель УБС
- •5.1.3. Распределенная структура УБС
- •5.1.4. Принципы взаимодействия
- •5.2. Функциональные компоненты биллинговых систем
- •5.2.1. Аутентификация и авторизация
- •5.2.2. Ведение счетов
- •5.2.3. Генерация счетов
- •5.2.4. Создание, съем и обработка CDR
- •5.2.5. Тарификация
- •5.2.6. Генерация отчетов
- •5.3. Логика услуг
- •5.4. Поддержка предоставления услуг
- •5.5. Клиентский уровень
- •5.6. Общее представление о системе управления предприятием
- •5.7. Техническая архитектура УБС
- •5.8. Система безопасности
- •Приложение 5.1. Реальная плоскость услуг
- •Приложение 5.2. Функциональная компонента генерации пин-кодов
- •Приложение 5.3. Взаимодействие между лицевыми и текущими счетами
- •Приложение 5.4. Оптимизация управления предприятием
- •Приложение 5.5. Корпоративный портал
- •ЧАСТЬ 3. СИСТЕМНАЯ ИНТЕГРАЦИЯ
- •Глава 6. ИНТЕГРАЦИЯ СИСТЕМ ПРЕДОСТАВЛЕНИЯ И БИЛЛИНГА УСЛУГ СВЯЗИ
- •6.1. Принципы построения инфокоммуникационных систем
- •6.2. Системная интеграция на примере системы «Ольга»
- •6.2.1. Функциональная модель
- •6.2.2. Четыре аспекта универсальности системы
- •6.3. Функциональные решения системы «Ольга»
- •6.4. Основные принципы реализации системы «Ольга»
- •6.4.1. Технологические принципы
- •6.4.2. Системные принципы
- •6.4.3. Технические принципы
- •6.5. Примеры использования системы «Ольга»
- •6.5.1. Приложение для операторов фиксированной телефонной сети
- •6.5.2. Приложение для провайдера сети Интернет
- •6.5.3. Приложение для оператора мобильной связи
- •Приложение 6.1. Основные принципы разработки подсистемы телебанкинга
- •Приложение 6.2. Стандарты мобильной связи и технологии передачи данных
- •Глава 7. КОМПЛЕКСНЫЕ ПРИЛОЖЕНИЯ
- •7.1. Инструменты оплаты и платежные системы
- •7.2. Интернет-телефонная бизнес-карта
- •7.2.1. Центр авторизации бизнес-карт
- •7.2.2. Безопасность бизнес-карт
- •7.2.3. Центры расчетов
- •7.3. Новая таксофонная сеть
- •7.3.1. Архитуктура новой таксофонной сети
- •7.3.2. Таксофонный терминал
- •7.3.3. Карманный таксофон
- •7.4. Мобильный банкинг
- •7.4.1. Понятие м-банкинга
- •7.4.2. Разновидности м-банкинга
- •7.4.3. Технология мс-банкинга
- •Список сокращений
- •Литература
202 |
ГЛАВА 5 |
|
|
5.6. Общее представление о системе управления предприятием
Описание функций и возможностей клиентского уровня УБС было бы неполным без
упоминания взаимосвязи этого уровня с системами управления предприятием (СУП) и, в частности, с системами управления ресурсами (СУР) оператора (Enterprise Resource Planning, ERP). Надо отметить, что если первоначально аббревиатура СУР
обозначала учет именно производственных ресурсов, то в дальнейшем ее трактовка расширилась и вобрала в себя всевозможные внутриофисные корпоративные функ- ции, включая финансы, бухгалтерию, работу с персоналом, закупки, заказы и ценооб- разование. Более подробно этот вопрос изложен в Приложении 5.4. Для приложений
УБС важно понимать, что СУП является одним из ключевых элементов управления предприятием как в части управления связями с потребителем (Customer Relationship Management, CRM) и управления цепями поставок (Supply Chain Management, SCM)
услуг, так и управления жизненным циклом продукции (Product Lifecycle Management, PLM) в части предоставления услуг и использования финансовых платежных инструментов. В данном разделе будут определены конкретные службы, с которыми должен взаимодействовать КУ УБС, а также основные потоки обмена информацией.
Сфера предоставления услуг связи достаточно широка, поэтому организацион- ная структура операторской компании может варьироваться в довольно широких приделах. Однако к СУP, которые так или иначе пользуются информацией или пре- доставляют информацию биллинговой системе, можно условно отнести следующие службы:
–бухгалтерия;
–маркетинг и планирование ресурсов;
–финансово-аналитическая служба;
–служба ведения и контроля договоров (учет абонентов);
–служба продаж абонентского оборудования;
–служба подключения и абонентского сервиса (в т.ч. ремонт);
–информационно-справочная служба;
–служба безопасности.
Еще раз необходимо подчеркнуть, что речь идет не о всех направлениях СУП, а только о тех, с которыми в большей мере взаимодействует УБС.
Выше мы уже рассматривали вопросы взаимодействия КУ с бухгалтерской службой. Дополнительно необходимо подчеркнуть, что, рассматривая это взаимо- действие в рамках СУП, необходимо иметь в виду оптимизацию информационных потоков между этой службой и подсистемами УБС, т.е. оптимизировать маршрути- зацию этих потоков.
Говоря о связи служб маркетинга и планирования, а также финансово-аналити- ческой службы с УБС, необходимо учитывать, что основную финансовую инфор- мацию эти службы получают из бухгалтерии. Однако эта информация обобщенная. Детализированную информацию эти службы могут получить через администрато- ров системы при обработке статистической информации по затратам абонентов, ус- лугам и трафику. Например, анализ трафика некоторой услуги по разным тариф- ным планам позволяет оптимизировать цену услуги.
СИСТЕМЫ РАСЧЕТОВ ЗА УСЛУГИ СВЯЗИ |
203 |
|
|
Упоминавшаяся ранее служба ведения и контроля договоров УБС чаще всего является подразделением аналогичной службы всего предприятия так же, как и ин- формационно-справочная служба.
На первый взгляд кажется, что служба продаж абонентского оборудования (на- пример, сотовых телефонов, модемов для доступа в Интернет и т.д.) не имеет от- ношения к службам КУ. Однако, если оператор использует карты оплаты услуг, то склад этой продукции может быть общим, а значит, и общей может быть техноло- гия функционирования служб продаж.
Служба подключения абонентов непосредственно связана с договорным отде- лом, который заключает договора на предоставление услуг, а значит, используются общие информационные ресурсы.
В рамках службы подключения или совместно с ней функционирует служба абонентского сервиса, в том числе бюро ремонта. В частности, для абонентов фик- сированной связи бюро ремонта производит профилактические и ремонтные рабо- ты по оборудованию «последней мили». Для этих целей бюро ремонта использует информацию по подключению абонентов к телекоммуникационному оборудова- нию и дальнейшему подключению до терминала абонента. Учитывая, что техноло- гический процесс ремонта состоит из приема заявки, распределения заявок по ис- полнителям и контроля выполнения заявок, на этапе приема заявок эта служба мо- жет взаимодействовать с пользователем через единую справочно-информационную службу, а на этапе выполнения заявок — со службой разбора претензий, в том чис- ле по фиксации выполненных заявок в единой базе «разбора претензий».
Все вышеизложенное касается и справедливо в большей степени для состав- ляющих SCM и PLM. Как указывалось выше, одной из определяющих частей BRP является CRM (управления связями или взаимоотношениями с потребителями). CRM как составляющая системы управления предприятием реально лежит в основе оптимального функционирования биллинговой системы. При этом оптимизация должна пониматься не только в контексте прямого воздействия на абонента, но, что более важно, в контексте обратной связи между абонентом и оператором, заклю- чающегося в предоставлении абонентам возможности посылки запросов, контроля и объединения счетов, получения необходимых справок и т.д. Основная тенденция такого взаимодействия предусматривает два важных фактора. Во-первых, это взаи- модействие должно осуществляться в реальном времени и быть актуально, а во- вторых, должно вызывать безусловный отклик оператора. Если первый фактор обеспечивается технологическими возможностями CRM (контакт-центрами и кор- поративными порталами), то второй фактор должен обеспечиваться оптимизацией бизнес-процессов компании оператора, характеризуемой внутриуровневой и межу- ровневой интеграцией СУП. Это, в свою очередь, позволяет осуществлять про- смотр и контроль всех объектов и сущностей, характеризующих данного пользова- теля или группу пользователей, что позволяет строить оптимальную маркетинго- вую политику для разных сегментов рынка.
Таким образом, клиентский уровень рассмотренной универсальной биллинго- вой системы позволяет эффективно интегрировать ее в систему управления пред- приятием оператора связи.
204 |
ГЛАВА 5 |
|
|
5.7. Техническая архитектура УБС
В соответствии с предложенной плоскостной концепцией, техническая архитектура универсальной УБС отражает в себе как сетевую архитектуру (физическую организа- цию структуры сети, протоколы и интерфейсы сети), так и архитектуру программно- аппаратных средств. Как упоминалось выше, УБС функционирует на основе универ- сальной среды, включающей в себя в том числе и сеть Интернет. Это, в свою оче- редь, позволяет наряду с клиент-серверными технологиями реализации технической архитектуры использовать современные Интернет-технологии. Функциональное раз- деление универсальной системы на информационный и клиентский уровень, а также необходимость интеграции обоих уровней в систему управления предприятием, со- четающееся с территориальным распределением служб УБС, оптимальным образом может быть реализовано на основе Интернет-технологий.
Одним из вариантов такой реализации является корпоративный портал. Корпо- ративный портал дает возможность организации работы служб оператора в сети та- ким образом, что становится возможным увязать в единую информационную систе- му все автономные службы оператора, генерировать и получать любую информа- цию, управлять ее сбором, хранением, распределением в любое время и в любом объеме в зависимости от уровня доступа, везде, где есть доступ к Интернету, а так- же отдавать распоряжения, контролировать исполнение решений, контролировать ход работы над различными проектами и многое другое (Приложение 5.5). При этом важным вопросом является обеспечение соответствующего уровня безопасно- сти корпоративной информации на всех этапах проекта. Особенно это важно в кон- тексте интеграции УБС в единую систему управления предприятием, когда в соста- ве инфраструктуры имеются различные информационные системы, бухгалтерские программы, финансовые, экспертные системы, системы документооборота и систе- мы управления администрированием, которые часто не связаны между собой и до интеграции использовались локально.
Структура аппаратных средств. При обсуждении физической плоскости реали- зации УБС подчеркивалось, что она отражает физические объекты, способы отобра- жения функциональных объектов на физические и способы реализации сетевых эле- ментов. Показанное на рис. 5.5 распределение функциональных пунктов и их взаимо- связь в архитектуре узлов УБС могут быть реализованы в виде некоторой структуры аппаратно-программного комплекса. На рис. 5.11 показана одна из возможных струк- тур аппаратно-программных средств, реализующих предложенную концепцию.
Как упоминалось выше, функции SSP выполняют все шлюзы с сетями коммута- ции каналов и пакетной коммутации, в том числе сама ГИС как шлюз «горячего биллинга» с фиксированной и подвижной телефонной сетью.
Сервер SCP обеспечивает выполнение услуг и обработку CDR (напомним, что в общем виде CDR трактуется как запись детализации соединения — Connection De-
tail Records), генерацию транзакций — TR (тарифицированные CDR), выполняет функцию управления услугами и поддержки данных. Сервер SCP CBSN (верхнего уровня УБС) имеет прямой доступ к серверу поддержки данных (SDP), а также обеспечивает взаимодействие с SCP PBSN (нижнего уровня УБС).
СИСТЕМЫ РАСЧЕТОВ ЗА УСЛУГИ СВЯЗИ |
205 |
|
|
Рис. 5.11. Структура аппаратно-программного комплекса УБС
Сервер поддержки данных (SDR) содержит базы данных, необходимые для функционирования УБС. Доступ к SDP из SCP нижнего уровня может быть полу- чен либо через соответствующие шлюзы, либо через сервер SCP или сервер обеспе- чения услуг (SMP). Различные сервера поддержки данных, в том числе клиентского уровня, могут быть связаны друг с другом.
Сервер администрирования услуг выполняет функции SMF, SMAF и функцию среды создания услуг SCEF. Данный сервер обеспечивает управление базами дан- ных, мониторинг сети, управление нагрузкой и обработку статистики, а также из- мерение различных характеристик системы биллинга.
Клиентский уровень может быть реализован как на основе автоматизированных рабочих мест различных служб этого уровня, так и на основе web-интерфейсов кор- поративного портала. Типовая организация структуры аппаратно-программных
206 |
ГЛАВА 5 |
|
|
средств строится на основе клиент-серверной архитектуры, включающей в себя сер- вер клиентского уровня, имеющий доступ к серверу баз данных. Организация досту- па пользователей к операторам служб может быть реализована на основе как тради- ционной телефонной связи через PBX, как показано на рис. 5.11, так и IP-телефонии, что дает возможность использовать АРМ или универсальный web-интерфейс с рече- вым взаимодействием как единый речевой и информационный терминал.
Приведенная обобщенная структура аппаратных средств может быть использо- вана для крупного, например, регионального оператора связи, который оказывает весь комплекс основных и дополнительных услуг связи. В случаях, когда оператор оказывает ограниченный комплекс услуг или обслуживает небольшое число або- нентов, структура используемых аппаратных средств может быть упрощена, в част- ности все сервера могут быть объединены в один.
Для примера на рис. 5.12 показана возможная структура аппаратных средств УБС для оператора сотовой связи, который оказывает услуги местной, междугород-
ной и международной связи, а также дополнительные услуги, и осуществляет бил-
линг hot-line pre-paid, on-line псевдо pre-paid и off-line post-paid. Кроме того, данная
структура позволяет обслуживать некоторого регионального оператора фиксиро- ванной связи в режиме off-line post-paid.
Рис. 5.12. Пример структуры аппаратного комплекса для оператора сотовой связи.
СИСТЕМЫ РАСЧЕТОВ ЗА УСЛУГИ СВЯЗИ |
207 |
|
|
На рис. 5.13 показана возможная структура аппаратных средств УБС для про- вайдера услуг Интернета, который предоставляет услуги коммутируемого и посто-
янного доступа в сеть Интернет, а также дополнительные услуги, и осуществляет биллинг в режимах hot-line pre-paid off-line post-paid.
Рис. 5.13. Пример структуры аппаратного комплекса для Интернет-провайдера
Структура программных средств. Обращаясь к общей структуре программных средств универсальной УБС, еще раз необходимо подчеркнуть, что универсальная УБС — это биллинговая система, способная адаптироваться к широкому классу типов и видов биллига основных и дополнительных услуг связи. Однако бессмысленно ис- пользовать все возможности такой универсальной системы в случаях, когда перед биллингом ставятся более узкие задачи. Рассматривая структуру аппаратных средств, мы приводили примеры ограниченного использования их номенклатуры и совмеще- ния функций в случаях, когда это возможно. Рассматривая обобщенную структуру программных средств, мы также должны иметь возможность использовать их в том объеме, который необходим для решения конкретного круга задач биллинга. Это, в свою очередь, требует рассмотрения структуры программных средств в контексте ре- шения двуединой задачи, а именно, структура программного обеспечения универсаль- ной УБС, с одной стороны, должна состоять из набора отдельных программных ком- понент (функциональных программных модулей с универсальным интерфейсом), а с другой стороны, должна быть возможность добавления функциональных компонент без нарушения работоспособности УБС. При этом имеется в виду, что указанная про- граммная компонента является функционально законченной программой, реализован- ной в виде отдельного исполняемого или встраиваемого файла, а множество про- граммных компонент, объединенных по критерию принадлежности к одному из об- щих бизнес-процессов, определяется как подсистема УБС.
208 |
ГЛАВА 5 |
|
|
На рис. 5.14 показана обобщенная структура программного комплекса УБС. Структура включает в себя шесть основных функциональных блоков: управляющее ядро, СУБД информационного и клиентского уровней, программные шлюзы, поль- зовательские и административные интерфейсы.
Рис. 5.14. Обобщенная структура программного комплекса УБС
Прежде чем приступить к более детальному рассмотрению этих функциональ- ных блоков, необходимо дать несколько уточнений. Прежде всего, надо отметить, что для определенного класса средних и малых УБС, СУБД КУ и СУБД ИУ могут объединяться в единую СУБД. Далее, определение интерфейсов КУ как пользова- тельских интерфейсов следует понимать в том смысле, что к категории этих интер- фейсов относятся и интерфейсы взаимодействия УБС с непосредственно пользова- телями (абонентами). И наконец, под термином «программный шлюз» (ПШ) в дан- ном контексте понимается его программная поддержка, а разделение шлюзов на шлюзы с сетями коммутации каналов (СКК) и на шлюзы с сетями с пакетной ком- мутацией (СПК) в явном виде соотносит данный ПШ с видом сети, несмотря на то, что, например, ПШ, который взаимодействует по каналу сигнализации ОКС №7 с сетью коммутации каналов, мы относим к СКК, хотя обмен информацией осущест- вляется в виде пакетов.
Управляющее ядро. Будучи функционально-управляющим блоком, ядро УБС является совокупностью функциональных модулей (Management Functional Module, MFM) и управляющих модулей (Applications Manager Module, AMM) — непосред-
ственных диспетчеров алгоритма функционирования услуги.
СИСТЕМЫ РАСЧЕТОВ ЗА УСЛУГИ СВЯЗИ |
209 |
|
|
AMM охватывают весь спектр алгоритмов услуг в соответствии с формулой универсального биллинга. При этом каждый из них реализует оригинальную или обобщенную последовательность функциональных компонент.
Каждый MFM реализует функциональную компоненту в целом или ее закон- ченный элемент. Таким образом, набор MFM должен быть не меньше, чем набор функциональных компонент. С другой стороны, как указывалось выше, каждая функциональная компонента может иметь свою реализацию для различных видов и типов биллинга, а также вида услуг данной сети.
Однако может существовать и другой подход, когда некоторый MFM реализует общую для компоненты данного вида функцию, и существует набор MFM, который реализует только отличительную часть. Оба подхода имеют право на существова- ние, хотя по мнению автора, первый подход оптимален с точки зрения простого на- ращивания системы, а второй подход оптимален с точки зрения реализации с ис- пользованием современных методов программирования.
Для примера рассмотрим набор MFM для функциональной компоненты автори- зации СКК. Как указывалось выше, функциональная компонента авторизации (FFa) декларирует свою систему отношений в области видов и типов биллинга, а также в
области форматов информации, приходящей из различных сетей. Так, для авториза- ции по номеру терминала для hot-line биллинга из СКК или СПК FFa получает за-
прос на авторизацию в виде некоторого события, осуществляет преобразование формата, осуществляет поиск в базе данных, получает ответ, реагирует на резуль-
тат авторизации, формализует и передает ответ на запрос. Для авторизации по но- меру терминала для on-line (off-line) биллинга из любой сети (в частности, для СКК
это номер телефона, а для СПК — IP адрес) запросом на авторизацию является не событие, а анализ очередного CDR, при этом формат информации уже является стандартным. Далее следует такой же запрос в базу данных, поиск и получение формализованного ответа, реакция на результат авторизации. Как видно из приве- денного примера, существует одинаковый набор действий, которые реализуются в обоих случаях и которые можно выделить в единый функциональный модуль.
Второй пример, иллюстрирующий данный подход, это реализация функцио-
нальной компоненты тарификации. Рассмотрим тарификацию pre-paid hot-line и post-paid off-line для услуг СПК, в частности коммутируемого (dial-up) и постоян-
ного доступа в сеть Интернет. Для случая pre-paid dial-up тарификация производит- ся по оплаченному времени доступа с выделением (для корпоративного пользова- ния, т.е. когда по одному лицевому счету могут получать услугу несколько пользо- вателей) определенных оплаченных квантов времени с контролем остатка по соот- ветствующему лицевому счету. Таким образом, функциональная компонента тари- фикации должна обеспечить: обработку запроса на тарификацию в реальном режи- ме времени, реализацию запроса к базе данных о состоянии счета, выборку тариф- ного плана, выделение кванта времени, а по его окончании запрос следующего кванта, по окончанию предоставления услуги подготовку CDR в виде записи в транзакцию стоимости оказанной услуги. Для post-paid off-line постоянного досту- па к сети Интернет тарификация проводится по объемам принятой и переданной информации. Для выполнения тарификации программным шлюзом уже подготов-
210 |
ГЛАВА 5 |
|
|
лен соответствующий CDR, в котором указаны эти объемы. Соответствующий про- граммный модуль находит в базе данных тарифный план данного пользователя и проводит соответствующую тарификацию, т.е. тарифицирует готовый CDR, пре- вращая его в транзакцию. Как видно из приведенного примера, имеются мало сход- ных функций, позволяющих унифицировать данную функциональную компоненту в виде общего функционального модуля. На рис. 5.15 для примера приведены от- дельные из рассмотренных выше модулей.
Рис. 5.15. Взаимосвязь функциональных, управляющих и интерфейсных модулей
Программные шлюзы. Основной функцией программных шлюзов hot-line и offline является поддержка взаимодействия между управляющим ядром и программно- аппаратными средствами сбора и обработки информации о состоявшихся соединени- ях, характеризующих предоставление той или иной услуги, или соединениях, кото- рые должны состоятся. В терминах функциональных модулей эти программные мо-
дули взаимодействия в режиме hot-line можно назвать модулями обработки событий
(Events Processing Module, EPM), а для режима off-line — модулями обработки запи- сей (Records Processing Module, RPM), имея в виду, что через шлюзы hot-line произ-
водится обмен запросами, а через шлюзы off-line — обмен записями.
Программные шлюзы роуминга осуществляют стык между центральными и пе- риферийными УБС в режимах hot-line как в части авторизации доступа и тарифика- ции услуг, так и в части перевода счетов средств оплаты из одной УБС в другую. В этом случае можно говорить, что программные шлюзы роуминга представляют со- бой совокупность программных модулей роуминга соответственно для обмена за-
СИСТЕМЫ РАСЧЕТОВ ЗА УСЛУГИ СВЯЗИ |
211 |
|
|
просами авторизации и тарификации — MRP (Roaming Processing Module), а для перевода — BPM (Banking Processing Module)
Программные шлюзы межуровневого взаимодействия осуществляют программ-
ное взаимодействие между информационным и клиентским уровнями и реализуют-
ся на основе программных модулей MII (Interlevel Interface Module).
Рассмотрим более подробно отдельные модули.
EPM обеспечивает в реальном времени обмен информацией по авторизации и тарификации услуг между оборудованием предоставления услуг и управляющим ядром УБС. Содержательные аспекты данной информации в основном рассмотре- ны в примерах по описанию функций управляющего ядра. Здесь же необходимо от- метить, что программная реализация EPM для сетей СКК и СПК обычно отличает-
ся по типу используемого протокола, так, в частности, для СКК обычно использу- ется верхние уровни протокола TCP/IP, а для СПК — протокол Radius. В этом слу- чае можно говорить о модулях СКК как EPMc (canel) и EPMb (burst) для СПК.
RPM должны обеспечивать съем и предварительную обработку CDR, которые накапливаются в оборудовании, предоставляющем услуги связи. Несмотря на опре- деленную стандартизацию форматов CDR, которые накапливаются в оборудова- нии, в общем случае RPM отличаются как для стыка с оборудованием различных сетей (соответственно, RPMc и RPMb), так и реально отличаются даже для разного оборудования одного типа сетей.
RPM обычно обеспечивают обмен запросами между центральными и перифе- рийными УБС, а в том случае, если в периферийной УБС отсутствует запрашивае- мый пароль доступа, то RPM обращается в центральную УБС за дополнительной авторизацией. В этом случае RPM обеспечивает безопасный доступ и далее функ- ционирует как EPM, обеспечивая соответствующее согласование протоколов и форматов.
BPM функционирует как модуль безопасного перевода счетов из одной УБС другую в случае, если технология функционирования УБС предусматривает «ми- грацию» счетов из одной УБС в другую. Дополнительной функцией BPM является возможность отражения в базе данных счетов истории их миграции. Это позволяет при получении запроса из другой УБС на перевод счета, который уже переведен, указать «адрес» УБС, к которой необходимо обратиться по данному паролю досту- па к счету. Согласование протоколов сети обмена информацией обычно произво- дится на уровне аппаратных средств.
На рис. 5.15 показана совокупность модулей, принадлежащих блоку программ- ных шлюзов.
Базы данных информационного и клиентского уровней должны содержать совокупность постоянной и переменной информации, необходимой и достаточной для функционирования универсальной УБС. В общем случае базы данных включа- ют в себя информацию о договорах, клиентах, обо всех типах счетов, CDR, тран- закциях, тарифных планах, отчетах, выставленных платежах и расчетах по ним, а также данные статистики, справочные каталоги и другую информацию, необходи- мую для функционирования системы. Распределение баз данных на информацион- ный и клиентский уровень является достаточно условным (см. рис. 5.14). В то же