Функции и компоненты аср. Биллинг в мультисервисных сетях. Борьба с мошенничеством.

Структура АСР

Схема организации биллинга не сложна (рисунок 1): информация о соединениях и их продолжительности записывается коммутатором и после предварительной обработки передается в расчетную систему. Расчетной системе "известны" тарифы. Она идентифицирует вызов и выполняет необходимые расчеты, формируя тем самым счет абонента. Очевидно, что в памяти системы должны храниться не только нормативы, тарифы и информация об услугах, но и данные о клиентах, заключенных контрактах с абонентами и сторонними поставщиками услуг связи (если таковые имеются), а также о стоимости передачи информации по разным каналам и направлениям (системой должно быть также предусмотрено наличие дилеров: у них могут быть другие расценки, например, на подключение). Кроме этого, любая БС должна иметь базу, хранящую историю платежей: только эти сведения позволяют контролировать процесс оплаты и автоматизировать так называемую активацию/деактивацию абонентов.

 

Рисунок 1 – Схема организации биллинга

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

В зависимости от требований бизнес-процессов и решаемых задач схема

системы может быть следующей:

• коллекторы информации о потребленных услугах;
• система аутентификации абонентов;
• ядро (бизнес-логика);
• база данных;
• модуль авторизации;
• модуль анализа и тарификации трафика;
• модуль разграничения доступа;
• модуль статистики;
• административный интерфейс для ручного управления абонентами;
• интерфейс управления счетами абонентов и тарифами для отдела продаж.

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

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

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

Ядро (бизнес-логика). Как правило, в ядро биллинговой системы входят модули:

· биллинга;

· тарификации и анализа трафика (в ряде решений выносится из ядра и оформляется как отдельный сервер);

· администрирования.

Основные требования к ядру – это его универсальность и масштабируемость. Интерфейс ядра должен быть разработан таким образом, чтобы его можно было использовать с различными коллекторами и обслуживающими программами (сервисами), которые используют ядро при решении своих конкретных задач. Оно должно иметь возможность работать с неограниченным числом тарифных планов, иметь гибкую тарификацию: различные правила округления, поминутная/посекундная тарификация, цена в зависимости от времени суток или дня недели, мультивалютность (курс USD может ежедневно устанавливаться автоматически по данным с указанного источника).

У биллингового модуля выделяется следующие функции:

· ведение лицевых счетов, биллинговых групп, абонентов и абонируемых услуг;

· формирование начислений за разовые и периодические услуги;

· формирование начислений за трафик;

· блокировку и разблокировку предоставления услуг по различным событиям;

· выставление биллинговых счетов;

· генерацию дополнительных документов;

· оповещение других подсистем о наступлении различных событий.

Для модуля тарификации:

· возможность ведения разнообразных тарифных планов;

· гибкую настройку условий определения стоимости услуг, зависящих от произвольного числа параметров, включая счетчики.

Для модуля администрирования:

· ведение списка пользователей системы;

· управление правами пользователей на подсистемы и функции;

· централизованное управление периодическими процессами, работающими в рамках системы.

База данных - неотъемлемая часть любой информационной системы. От ее правильной организации во многом зависит производительность и надежность работы системы в целом. Значительная часть промышленных биллинговых систем в мире (примерно 9 из 10 продуктов) создавалась на основе СУБД Oracle. СУБД. Операторов с небольшим (несколько тысяч) числом абонентов может устроить и более дешевое решение на базе Btrieve или MySQL. В качестве ОС сервера используются ОС Windows-2000, Linux или Solaris.

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

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

Как правило, выделяют 3 уровня:

1. Максимально детализированная информация без какой-либо обработки.

2. Классифицированная и первично агрегированная информация.

3. Оперативная информация.

Модуль авторизации

Авторизация, применительно к БС – процесс принятия решения о предоставлении или запрете доступа к той или иной услуге. Основными критериями для такого решения является достаточность баланса и доступность запрашиваемой услуги. Однако, возможны случаи, когда абоненту был выделен определенный лимит на использование определенной услуги и при его исчерпании абоненту отказывается в доступе.

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

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

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

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

Интерфейс управления счетами абонентов и тарифами для отдела продаж - входит в состав front-офиса. Содержит в себе набор инструментов, которые позволяют заносить в БС новых абонентов, выбирать для него тарифный план, подключать дополнительные услуги и принимать платежи [11].