- •ПРЕДИСЛОВИЕ
- •ЧАСТЬ 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. Технология мс-банкинга
- •Список сокращений
- •Литература
186 |
ГЛАВА 5 |
|
|
Лицевые персонифицированные счета несут в себе две функции. Первая функ- ция — это отражение состояния взаиморасчетов с абонентами, а именно, какова об- щая задолженность пользователя за предоставленные услуги до начала текущего расчетного периода, а также история этих взаиморасчетов по всему спектру предос- тавляемых услуг на заданную «глубину». Вторая функция — это расшифровка за- трат пользователя по каждому виду услуг. Счета Lbp открываются на основании за- ключенных с пользователем договоров. Лицевые персонифицированные счета мо- гут быть как кредитовыми, так дебетовыми и смешанными. При этом надо иметь в виду, что смешанные лицевые счета не могут быть одновременно кредитовыми и дебетовыми по одинаковым видам услуг.
Лицевые неперсонифицированные счета отражают только расшифровку затрат пользователя по каждому виду услуг. Взаиморасчеты с пользователем отражаются на текущем счете дебетового платежного инструмента.
Текущие счета платежных инструментов также различаются по своей функции. Так, если текущие кредитовые счета служат только для подтверждения прав поль- зователя, то дебетовые текущие счета совмещают эту функцию с функцией взаимо- расчетов, в том числе по услуге пополнения других дебетовых счетов и пополнения Lbp, а также ведут историю этих взаиморасчетов по всему спектру предоставляе- мых услуг на заданную «глубину».
Счета второго уровеня — это текущие счета (Tb), которые делятся как по виду предоставляемых услуг (Ts), так и по виду взаиморасчетов: кредитные (Tsс) и дебе- товые (Tsd). Текущие счета Tsd, кроме суммы затрат на предоставление данной ус- луги, имеют дополнительный параметр «сумма предоплаты», который позволяет пополнять отдельные текущие счета как со счетов платежных инструментов, так и с
лицевых персонифицированных счетов. Текущие счета взаимосвязаны с лицевыми счетами (см. рис. 5.6).
Примеры взаимодействия между счетами рассмотрены в Приложении 5.3.
5.2.3. Генерация счетов
Вопросы генерации счетов разделяются на три аспекта: генерация счетов платеж- ных инструментов, генерация лицевых счетов, генерация текущих счетов.
Каждый из счетов имеет набор атрибутов, имеющий определенную избыточ- ность. Однако такая избыточность дает возможность проверять область допусти- мых значений атрибутов при их изменении. Кроме того, избыточность атрибутов субъекта позволяет получать многие справочные данные без дополнительного ана- лиза транзакций, произведенных за расчетный период, т.е. увеличить производи- тельность взаимодействия между основным и вспомогательными уровнями УБС.
Лицевые и текущие счета платежных инструментов (счета платежных инст-
рументов) являются сущностями УБС. При этом номер текущего счета часто может являться одновременно номером платежного инструмента. В соответствии с разд. 4.4 текущий счет платежного инструмента для УБС должен содержать сле- дующие атрибуты:
СИСТЕМЫ РАСЧЕТОВ ЗА УСЛУГИ СВЯЗИ |
187 |
|
|
1.Номер счета (номер платежного документа).
2.Пароль доступа (в открытом или шифрованном виде).
3.Лицевой счет пользователя (при генерации отсутствует).
4.Валюта расчетов.
5.Тип счета (кредитовый, дебетовый).
6.Вид счета (индивидуальный, корпоративный).
7.Тип дебетового счета (пополняемый, не пополняемый).
8.Дата активации счета.
9.Сумма на счете на дату активации.
10.Общая сумма пополнения.
11.Остаток на счете на текущую дату.
12.Дата окончания последнего расчетного периода.
13.Общая сумма пополнения счета до начала последнего расчетного периода.
14.Остаток (задолженность) на счете на конец последнего расчетного периода.
15.Сумма пополнения в течение срока текущего расчетного периода.
16.Сумма расходов за текущий расчетный период.
Лицевые счета пользователей являются также сущностями УБС. В соответ- ствии с разд. 4.4 персональный лицевой счет должен содержать следующие атри- буты:
1.Номер персонального лицевого счета.
2.Реквизиты владельца.
3.Перечень разрешенных услуг.
4.Номера тарифных планов по услугам.
5.Номера взаимосвязанных текущих кредитовых и дебетовых счетов, а также номер платежного документа.
6.Валюта расчетов.
7.Вид счета (индивидуальный, корпоративный).
8.Дата активации счета.
9.Общая задолженность (остаток) на кредитовых (дебетовых) текущих счетах до начала расчетного периода.
10.Остаток на счете на текущую дату.
11.Дата окончания последнего расчетного периода.
12.Дата следующего расчетного периода.
13.Задолженность (остаток) на кредитовых (дебетовых) текущих счетах за по- следний расчетный период.
Лицевые неперсонифицированные счета пользователей должны содержать следующие атрибуты:
1.Номер лицевого счета.
2.Номер взаимосвязанного платежного инструмента.
3.Перечень разрешенных услуг.
4.Номера тарифных планов по услугам.
5.Номера взаимосвязанных текущих дебетовых счетов.
188 |
ГЛАВА 5 |
|
|
6.Валюта расчетов.
7.Вид счета (индивидуальный, корпоративный).
8.Дата активации счета.
9.Затраты по каждому из взаимосвязанных текущих счетов.
10.Суммарные затраты по всем взаимосвязанным текущим счетам в реальном времени.
Текущие счета пользователей (так же, как и счета платежных инструментов и лицевые счета) являются сущностями УБС. Текущие счета разделяются на кредито- вые и дебетовые. В свою очередь, дебетовые текущие счета подразделяются на де- бетовые текущие счета с контролем и без контроля остатка на счете.
Кредитовые текущие счета (КТС) и дебетовые текущие счета с контролем ос- татка (ДТС-К) взаимосвязаны с персонифицированными лицевыми счетами, а теку- щие счета без контроля остатка (ДТС) взаимосвязаны с неперсонифицированными лицевыми счетами. В общем случае текущие счета имеют следующие атрибуты:
1.Номер текущего счета.
2.Номер взаимосвязанного лицевого счета.
3.Перечень разрешенных услуг по виду шлюза.
4.Валюта расчетов;
5.Вид счета (индивидуальный, корпоративный).
6.Дата активации счета.
7.Для КТС — общая задолженность до начала расчетного периода; для ДТС-К и ДТС — стоимость общего объем услуг в реальном времени.
8.Для КТС — разница между задолженностью и максимальным кредитом на начало расчетного периода; для ДТС-К — остаток на счете в реальном време- ни; для ДТС — п. 7.
9.Расшифровка п. 7 по услугам.
Генерация текущих счетов производится автоматически при генерации лицевых счетов.
Генерация и ведение счетов платежных документов, лицевых и текущих счетов реализуется с использованием функций IRCF, IRCAF, UAIF, SDF.
5.2.4. Создание, съем и обработка CDR
Во всех режимах CDR формируется оборудованием, предоставляющим соответст- вующие услуги. Однако в режиме on-line и off-line CDR формируются без участия УБС, поскольку оборудование функционирует в режиме предоставления услуг только своим пользователям, номера терминалов (или IP-адреса) которых «пропи- саны» в этом оборудовании. Поскольку авторизация пользователей производится
самим оборудованием, то взаиморасчеты с ними могут проводиться только на осно-
ве post-paid (on-line, off-line) или p/pre-paid (on-line) биллинга. При реализации hotline биллинга имеется возможность реализации как post-paid, так и pre-paid биллин-
га, при этом авторизация производится самой биллинговой системой. Для режима
СИСТЕМЫ РАСЧЕТОВ ЗА УСЛУГИ СВЯЗИ |
189 |
|
|
pre-paid биллинговая система при определении возможности предоставления запра- шиваемой пользователем услуги дополнительно должна проверять состояние счета пользователя (или состояние счета его платежного инструмента).
Таким образом, при формировании CDR выполняется не менее двух запросов к SCP УБС, а именно, на этапе подключения пользователя к системе предоставления услуг — запрос на определение его принадлежности к УБС, а на этапе выбора пользователем вида услуги — запрос на возможность ее предоставления в соответ- ствии с состоянием счета. В результате данных запросов формируется CDR, кото- рый в общем случае имеет следующие атрибуты:
–вид (код) услуги (указывается код услуги в соответствии с принятой класси- фикацией);
–дата, время начала оказания услуги (фиксируется с момента реального начала услуги);
–длительность;
–объем входящей информации (для услуг сетей пакетной коммутации);
–объем исходящей информации (для услуг сетей пакетной коммутации);
–номер счета платежного инструмента, с которого производится оплата услуги;
–номер лицевого счета пользователя (или номер счета инструмента оплаты, на ко- торый перечисляется сумма, при предоставлении услуг по пополнению счета);
–номер терминала пользователя;
–перечисляемая сумма;
–служебная информация (характеристики технических средств, через которые оказывалась услуга, например, номер канала, причина рассоединения и т.д.).
Как видно из перечня атрибутов CDR, заложенная в них информация избыточна как для конкретного вида предоставляемых услуг, так и для средств оплаты, кото- рыми могут быть использованы. Однако такой формат CDR позволяет использо- вать его в качестве единого формата CDR универсального биллинга. Надо отме- тить, что такой формат CDR позволяет предоставлять дополнительные услуги бил- линга (см. главы 1 и 4) по пополнению счетов абонента с помощью платежных ин- струментов.
Как упоминалось выше, в режиме on-line и of-line биллинга CDR могут образо- вываться сторонним оборудованием, которое подключается к узлу УБС в рамках одного узла телекоммуникационной сети или находится в других узлах телекомму- никационной сети. В этих случаях для ввода CDR в УБС необходимо не только по- лучить эти CDR с узла телекоммуникационной сети, но и преобразовать их к виду, стандартному для УБС.
Современное телекоммуникационное оборудование имеет соответствующие средства накопления CDR за заданный период времени. Поэтому цель УБС — со- единиться с данным оборудованием через соответствующий шлюз (см. разд. 5.1.4) по каналу связи и считать эту информации. Несмотря на то, что в настоящее время существуют определенные стандарты форматов CDR для каждого типа оборудова- ния (например, ANSI 124), задача преобразования различных форматов в форматы УБС не может быть реализована одной универсальной программой и требует ис- пользования набора типовых программ.