Это приложение является наиболее сложным с точки зрения как самих алгоритмов обработки, так и их реализации, поскольку именно оно анализирует исходную информацию о соединении, определяет класс предоставляемой услуги и параметры трафика — направление вызова, источник, зоны взаиморасчетов и условия роуминга. В состав данной подсистемы входит декодер исходной информации о соединениях (например, о вызовах типа CDR — Call Detail Record или AMA — Absolute Mail Address), который извлекает данные из соответствующего файла, формируемого сетевыми коммутаторами, и обеспечивает трансляцию маршрута CDR или AMA в тарифный маршрут с учетом установленных в системе направлений и зон соединения (как внутри страны, так и международных).
Одна из сложнейших процедур этой подсистемы — поддержка роуминга. И дело даже не в необходимости применения множества таблиц для расчетов, а в том, что требуется конвертировать роуминговые записи всевозможных форматов от разных коммутаторов (с учетом различных стандартов передачи информации в канале связи) и разных биллинговых систем в тот формат записи, который используется в конкретной системе. Неудивительно, что производители сетевого оборудования и операторы связи (особенно сотовой) проявляют немалую активность в разработке биллинговых стандартов для роуминга. Сейчас наиболее распространены три стандарта, которые применяются главным образом в сетях подвижной связи. Один из них представляет собой «симбиоз» ANSI 124 и NSDP-B&S (Non-Signaling Data Protocol for Billing and Settlement) и регламентирует параметры биллинга при обмене информацией между коммутаторами различных моделей и разных производителей. Два других ориентированы на определенные стандарты сотовой связи: CIBER (Celluar Intercarrier Billing Exchange Roamer Record) — на AMPS, а семейство спецификаций TAP (Transfer Account Procedure) — на GSM.
Биллинговый стандарт определяет структуру файла для обмена данными между операторами связи. В нем указывается число полей в записях файла, содержатся описания и допустимые значения этих полей. Наряду с записями о вызовах и услугах в спецификации предусмотрены поля для сумм начислений и налогов, а также для специфических характеристик вызовов, соединений или услуг (поля детализации). Несмотря на различия используемых стандартов их структуры весьма схожи, и все они используют записи фиксированной длины, поэтому между полями разных файлов можно установить некоторое соответствие (так, абонент в файле стандарта CIBER идентифицируется полем MIN, а согласно спецификации ТАР — полями IMSI и MSISDN). Можно соотнести также поля, идентифицирующие абонентское оборудование, компании-операторы, которые являются отправителями, получателями или передают информацию транзитом, поля кодов смещения времени и абсолютного времени соединения и некоторые другие.
Подсистема предварительной обработки должна уметь преобразовывать всю исходную информацию о соединениях и трафике (включая роуминговую) в формат, принятый в конкретной биллинговой системе. Кроме того, она учитывает виды предоставляемых клиенту услуг, определяет соответствующие тарифы и маршруты вызова. Подробное описание предоставления каждой услуги записано в файле, поступающем из коммутатора, или в роуминговом файле. ПО тарифицирует все записи о соединениях между операторами (согласно проходящему трафику) и создает служебные таблицы, которые используются остальными подсистемами для выполнения расчетов с абонентами, взаиморасчетов операторов связи и формирования отчетов. Современные биллинговые системы позволяют обрабатывать различные телекоммуникационные услуги, обеспечивая удобное выставление счетов (один клиент — один баланс — один счет). И это достигается за счет применения «интеллектуальных» систем предварительной обработки исходной информации о соединениях, трафике и услугах, выполняющих тарификацию независимо от вида связи.
Данная подсистема, которую часто называют hot-billing, дает возможность автоматически или через оператора биллинговой системы изменять условия подписки абонентов на коммутаторе, т.е. блокировать связь конкретного абонента или снимать эту блокировку, включать или отменять услугу. Она периодически опрашивает коммутатор о вызовах и услугах и играет роль «цербера» для неплательщиков.
Подсистема работает непосредственно с коммутатором сети, используя для формирования соответствующих команд драйверы сетевых устройств. Очевидно, что это возможно только в том случае, если биллинговая система поддерживает соответствующий коммутатор. К сожалению, универсальных решений для работы с разными коммутаторами пока не найдено (при огромной номенклатуре типов коммутаторов сомнительно, что они будут найдены вообще). Приобретая биллинговую систему, следует учитывать, с какими моделями коммутаторов она работает.
Неотъемлемая часть современного биллинга — подсистема оповещения клиентов с помощью голосовых или электронных сообщений. Информацию для рассылки уведомлений и объявлений данная подсистема «черпает» из всех таблиц базы данных (и содержащих информацию о контрактах клиентов или новой услуге, и из списка должников).
В реальных биллинговых системах не всегда соблюдается строгое деление на функциональные подсистемы. Чаще всего их структуру обуславливают бизнес-процессы предприятий связи, а модульность самих программ обеспечивает определенную гибкость формирования комплектов ПО, адаптированных к требованиям конкретной организации. При этом некоторые функции предварительной обработки исходной информации могут выполняться в других исполнительных подсистемах: например, функция тарификации — в подсистеме расчета с клиентами, а функции подсистемы продаж — в подсистемах работы с абонентами (продажа услуг) и складского учета (продажа оборудования).
Назад | Содержание | Вперед