IР-предбиллинг

2.3 IР-предбиллинг

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

·     с большим количеством сетевых элементов, которые генерируют широкий спектр типов данных;

·     с огромным количеством данных, примерно в 15-50 раз превышающим количество данных, генерируемых традиционными коммутаторами;

·     с новыми приложениями;

·     с возросшими потребностями к системам хранения.

В порядке преобразования данных об использовании IP-сети в записи для биллинговой системы предбиллинг должен принимать потоки данных, поступающие от:

·     элементов сети передачи данных, таких как маршрутизаторы;

·     сетевых сервисов, таких как: DNS, WEB, Mail, RADIUS, LDAP, сетевые экраны и VPN;

·     приложений VoIP;

·     контент-сервисов.

Как и в случае с коммутационными сетями, каждый элемент сети выдаёт данные в своем формате. В отличие от традиционной сети сбор данных с одного элемента не дает достаточной информации для формирования биллинговой записи. В дополнение к этому IP-адрес должен быть соотнесен с объектом биллинга и географическим размещением. Это означает, что IP-предбиллингу необходимо собрать и объединить информацию об IP-событии со всех источников. В процессе агрегации данных в первую очередь нужно отобрать ту часть данных, которая необходима биллинговой системе, и в то же время предоставить информацию, необходимую для предложения гибких тарифов и скидок. Принцип работы предбиллинговой IP- системы системы показан на рис. 2

Рис. 2 Поток информации через IP-предбиллинг

Существует три пути сбора информации из IP-сети:

1.   Анализ логов;

2.   Пробы;

3.   Анализ трафика.

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

2. Физические пробы могут быть активными или пассивными. Они устанавливаются на границах входа и выхода точки доступа и предоставляют информацию со 100% точностью. Этот метод требует инвестиций в программное и аппаратное обеспечение и используется в основном при необходимости в высокой точности измерения, например, при предоставлении сервисов операторского класса.

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

Для биллинговой системы необходимой является информация только сетевого и транспортного уровня, однако, подсчет IP-потока дает дополнительные преимущества:

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

·     каждый пакет виден на уровне протокола (это необходимо системам защиты от мошенничества);

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

·     сравнительно небольшое количество измерителей потока может собирать информацию с большого количества сетевых элементов.

Существует множество стандартов записи IP-данных, изготовленных производителями mediation-систем. Консорциум IPDR Organization работает над стандартизацией этого формата и создает основу открытого протокола для обработки IP-записей. Каждый тип услуги, которую может предоставить IP-сеть, имеет собственную спецификацию. Уже описаны спецификации для услуг: E-mail, доступ к Интернет, voice over IP, видео по запросу.

3. Основные компоненты OSS/BSS

Комплекс решений OSS/BSS одна из систем использующаяся в биллинговых системах. Архитектура OSS/BSS состоит из нескольких уровней. Рассмотрим вкратце каждый из этих уровней и какие задачи они позволяют реализовать.

Уровень сетевого управления Network Management Systems (NMS) - комплекс систем управления узлами и подсетями оператора, формирующий прозрачную для абонента мультисервисную и мультисе-тевую инфраструктуры оператора. С учетом того, что обычно оператор использует оборудование как минимум двух производителей, число управляющих комплексов может достигать нескольких десятков. Для подсчета объема услуг биллингу необходимо взаимодействовать с каждой системой управления или с неким информационным приложением, являющимся посредником между имеющимися ИС. В NMS протоколируются все воздействия на узлы сети, по каждому из них собираются аварийные и сигнальные сообщения. Структурирование этой информации и ее обработка позволяют разграничить информационные потоки и доступ к сетевым ресурсам. Это повышает гибкость всего комплекса и обеспечивает более высокий уровень информационной безопасности: следующий слой автоматизации работает только с информацией, поставляемой с «нижних» слоев. -Уровень автоматизации эксплуатационной деятельности оператора Operation Support System (OSS) обеспечивает интеграцию следующих ключевых подсистем:

- Network Resource Inventory (NRI) - подсистема инвентаризации и технического учета сетевых ресурсов. Она учитывает и отражает физический уровень сети, логический уровень сети, позволяет детализировать трафик с точностью до виртуального канала, временного интервала или информационного потока той или иной услуги;

- Intelligent Fault Management (IFM) - экспертная система анализа и фильтрации аварийных сообщений. Подсистема выявляет причины сбоев в узлах сети, обеспечивает фильтрацию вторичных аварийных сообщений, позволяет своевременно фиксировать деградацию качества каналов, влияющую на качество услуги;

- Service Level Agreement Management (SLAM) - автоматизированная система мониторинга контролируемых параметров, гарантирующих качество обслуживания абонентов. Она играет важную роль в детализации процессов предоставления услуг, определяющих взаиморасчеты с абонентом;

- Problem Management + Help Desk (PMHD) - автоматизированная система формирования и сопровождения заказов на проведение ремонтных и регламентных работ на сети оператора. Она позволяет минимизировать простои за счет автоматической генерации заказов при локализации аварийной ситуации, а также сокращения издержек, связанных со взаимодействием различных служб технической поддержки сети, и прогнозирования возможных отказов в системе IFM и генерации нарядов на плановые регламентные работы, предотвращающие возможные отказы;

- Performance Management System (PMS) - автоматизированная система анализа баланса нагрузки в сети, предназначенная для оптимизации сетевой производительности . Она дает возможность своевременно прогнозировать перегрузки в узлах сети, планировать внедрение новых услуг, необходимую для этого модернизацию сети и приводить их в соответствие с маркетинговым планом;

- Order Management (ODM) - автоматизированная система работы с абонентами, которая принимает и формирует заявки на активацию сервисов, согласует их с техническими возможностями имеющейся инфраструктуры и программой развития сети, фиксирует рекламации, планирует и сопровождает их устранение;

- Working Force Management (WFM)-автоматизированная система управления персоналом. Она координирует техническую переподготовку сотрудников в соответствии с программой развития сети, планирует график работы персонала.

- Уровень автоматизации бизнес-процессов оператора Business Support System (BSS) интегрирует подсистемы автоматизации процессов агрегирования информации, необходимой для работы биллинговой системы, систем учета и управления материально-техническими ресурсами оператора:

- Subscriber Service Support System (SSSS) - подсистема абонентского обслуживания, которая объединяет работу контакт-центра, обрабатывающего обращения абонентов, CRM-системы, фиксирующей историю взаимодействий с абонентами и системы самообслуживания абонента(справочная информация, подписка и т. п.);

- Billing System (BS) - автоматизированная система взаиморасчетов с абонентами и детализации предоставленных услуг. Она выставляет счета абонентам оператора, контролирует своевременность оплаты и позволяет абоненту получить детализацию с точностью до отдельной транзакции и сценария ее реализации;

- Enterprise Resource Planning (ERP)набор интегрированных приложений, которые поддерживают основные аспекты управленческой деятельности оператора: планирование ресурсов, необходимых для предоставления услуг, оперативное управление выполнением планов, учет и анализ результатов деятельности. Среди основных требований, предъявляемых к ERP-системам, - централизация базы данных, работа в режиме он-лайн, поддержка территориально распределенных структур, возможность использования различных СУБД на ряде аппаратно-программных платформ.

4.Выбор системы с накоплением или реального времени

Внутреннее устройство биллинговых систем, являясь личным делом оператора также влияет на взаимоотношения клиента с провайдером. Первые опасности, которые подстерегают и оператора, и его абонентов, — выбор между системой с накоплением и системой реального времени. Система с накоплением обходится куда дешевле, — независимо от того, приобретать ли ее у разработчика в готовом виде или создавать самостоятельно, — и требует минимальных ресурсов. В конце каждого расчетного периода (который может быть равен суткам, месяцу или пяти минутам) такая система «засасывает» данные об услугах, потребленных абонентами, и вычисляет, насколько изменилось состояние каждого счета. Если речь идет о коммутируемом доступе, то поставщиком информации выступает система авторизации (RADIUS или TACACS); если о выделенном — маршрутизатор, через который к пользователю проходят пакеты с данными; если о телефонии — телефонная станция. Продолжительность расчетного периода определяется лишь волей оператора да возможностями имеющегося у него «железа». Например, для корпоративных клиентов, подключенных по выделенным каналам, данные можно рассчитывать раз в месяц, при выставлении счетов, — никаких сюрпризов при этом ожидать не приходится. Специализированный сервер поработает некоторое время, которое в этом случае критического значения не имеет, — и выдаст необходимые сведения и сразу счет на бланке распечатает. Поскольку процедура выставления счетов обычно занимает несколько дней, для этих целей годится и не слишком мощная техника — никто никуда особо не торопится. Компании, использующие Интернет в своем бизнесе, не склонны доводить конфликтную ситуацию до отключения, ведь убытки, которые несет, скажем, турагентство из-за потери связи с внешним миром, обычно во много раз превышают спорные суммы — так что куда лучше сперва оплатить выставленный счет. Когда речь заходит о частных пользователях, вести себя таким же образом как с корпоративными абонентами нельзя, это рискованно для провайдера. Ведь добиться выплаты долга физическим лицом практически невозможно. Клиенту получающему свою реальную зарплату в конверте и сумевшему влезть в огромные долги перед оператором, зачастую попросту дешевле отказаться платить по счету и подключиться к кому-нибудь другому. С весьма высокой степенью вероятности его оставят в покое. По этой причине операторы, работающие на массовом рынке, неохотно предоставляют услуги в кредит, предпочитая авансовую систему оплаты. Пока баланс положительный — клиент пользуется услугой, а как только на счету останутся нули — услуга блокируется. Такая система расчетов знакома, например, многим владельцам мобильных телефонов. И даже если провайдер предоставляет абонентам кредит — этот кредит никогда не бывает безграничным, а равен некой мелкой сумме, одинаковой для всех или гибко определяемой для каждого клиента в зависимости от его платежной истории. Понятно, что в подобной ситуации устанавливать расчетный период равным месяцу никто не будет слишком длительный срок не выгодно. Если клиент за сегодняшний день умудрился наговорить с Занзибаром столько, чтобы свести свой баланс к нулю то не позднее завтрашнего дня биллинговая система должна это выявить и отдать коммутационному оборудованию команду этого клиента не соединять ни с кем, кроме техподдержки и справочных служб, — по крайней мере, до того момента, когда тот не пополнит свой баланс. Чем меньше расчетный период, тем интенсивнее загружается система и тем мощнее должен быть сервер (или группа серверов), на котором она развернута. Платить лишнее никто из операторов не хочет — и потому каждый из них пытается найти оптимальный баланс между ростом стоимости оборудования и риском позволить абоненту слишком многое.  Взглянув на операторскую биллинговую систему чуть пристальнее, можно увидеть, что себестоимость любой услуги делится на две части — условную и безусловную. Например, к условной себестоимости относится какая - бы то ни - было недополученная прибыль. Если пользователь коммутируемого доступа повисит на линии несколько лишних, неоплачиваемых часов, провайдера это, конечно же, не обрадует. Но и особо не огорчит. Да возможно, в то самое время, когда линия была занята халявщиком, ею мог бы воспользоваться добросовестный клиент, который принес бы компании несколько долларов дохода. А возможно, все это время она так и простояла бы свободной. В любом случае, затраты оператора на аренду телефонии под модемный пул ни на копейку бы не возросли. И если владелец виртуального сервера вдруг откажется оплачивать выставленный счет, его файлы можно стереть, а на освободившемся дисковом пространстве разместить сервер другого клиента. Ведь в такой ситуации оператор практически ничего не теряет.