CDR - это обычно используемый акроним для данных, генерирующихся из сети с коммутацией каналов. Количество информации, содержащейся в CDR, гораздо больше необходимого для большинства приложений. Обычно коммутаторы регистрируют 200-300 элементов информации, из которых в CDR попадают 50-100 полей. Из этих полей менее десяти необходимы для дальнейших биллинговых задач. Несмотря на это, в некоторых случаях происходит потеря или повторение CDR, что делает необходимым предбиллинговую коррекцию.
2.2 Передача данных в предбиллинг
Предбиллинг работает по принципу доставки записей. Информация о звонке может быть получена только с коммутатора, поэтому очень важно, чтобы информация была проверена, защищена, собрана и подтверждена. Информация о звонках обычно хранится в буфере самого коммутатора и собрана в последовательности файлов, содержащих десятки тысяч записей. Передача производится в двух режимах: "pull" или "push". В режиме "pull" система предбиллинга посылает запрос коммутатору. Коммутатор подтверждает соединение, передает файл и закрывает соединение. Затем коммутатор сбрасывает буфер записей. В режиме "push" осуществляется постоянный опрос, и соединение с коммутатором всегда остается открытым. Для сбора данных может быть использовано отдельное устройство, собирающее данные по мере поступления для немедленной отправки ожидающему приложению. Этот механизм является базовым для осуществления биллинга в режиме реального или близкого к реальному времени. Предбиллинг распознает множество параметров звонка, включая: протокол коммутации, время сбора и передачи, формат записей, их кодировку и контент. Интерфейсы телефонных коммутаторов поддерживают разнообразные функции "подтверждения" для проверки правильности передачи, включая идентификацию временных точек, подтверждение того, что записи идут в правильной последовательности, а также установление повторяющихся записей. Этот функционал используется при восстановлении в случае сбоя при передаче данных. Иногда системы предбиллинга присваивают каждому файлу CDR записей уникальный идентификатор, для того чтобы отслеживать его в процессе обработки.
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) - автоматизированная система работы с абонентами, которая принимает и формирует заявки на активацию сервисов, согласует их с техническими возможностями имеющейся инфраструктуры и программой развития сети, фиксирует рекламации, планирует и сопровождает их устранение;
