Рейтинг биллинговых систем для интернет провайдеров

Обновлено: 05.07.2024

Сравнительная таблица биллингов для интернет-операторов

Название биллинга

LANBilling 1.8

LANBilling 1.9

Примерное количество существующих инсталляций

Минимальная удельная стоимость лицензии (в расчете на одного абонента) в базовой комплектации, позволяющей тарифицировать услуги ШПД, Телефонии, Телематики для оператора с абонентской базой 10000 пользователей

Возможность тарификации услуг ШПД. Поддержка DHCP Option 82 и 802.1x. Поддержка методов: EAP-MD5, EAP-TLS, EAP-TTLS, PEAP-MSCHAP v2 средствами собственного RADIUS сервера

Полностью (интегрируется с FreeRADIUS)

DHCP Option 82 и 802.1x - Нет, EAP-MD5 - Да, EAP-TLS - Нет, EAP-TTLS - нет, PEAP-MSCHAP - Нет

Eсть: Поддержка DHCP Option 82, поддержка 802.1X — EAP-MD5

Eсть все перечисленное

Полностью (интегрируется с FreeRADIUS)

Наличие модуля Web авторизации

Нет (Eсть возможность сделать собственныймодуль, используя API)

Для пользователей Web-кабинет

Возможность тарификации услуг телефонии в т.ч. карточной платформы. Наличие агентской схемы взаиморасчетов за услуги телефонии

Агентская схема – в стадии разработки.

Возможность тарификации услуг телематических служб (разовые и периодические услуги)

Eсть, в том числе интеграция с хостингом и почтовым сервером

Наличие системы инвентаризации и SNMP управление активной сетевой аппаратуры

Eсть система инвентаризации. Нет модуля управления.

Наличие встроенных элементов BSS системы (CRM/HelpDesk)

Наличие возможности работы с внешними платежными системами (Какими?)

Eсть. (Прием платежей вручную, Загрузка выписок из

интернет-банка (в полуавтоматическом режиме), Пластиковые карты

(VISA/Mastercard и другие): Cyberplat, ROBOKASSA, Банкоматы Сбербанка,

NCC/UC. Терминалы оплаты: Qiwi (ОСМП), Cyberplat, Кассира.нет,

MoneyMoney, Собственные терминалы заказчика (это выделить!),

Электронные деньги: Яндекс.Деньги, WebMoney. Прочие способы:

ROBOKASSA, Через функции API, Через командную строку.

Eсть: ОСМП, E-port, Rapida, Яндекс.Деньги, Уникасса, WebMoney, HandyBank (Элекснет), Кредит-Пилот, Z-pay, CyberPlat, Sms4Pay , Одно касание, PayPal, Хронопэй, Волжский банк, Номинал, Свободная касса

ОСМП, Свободная касса, Сбербанк, Балтийский Банк

Eсть. ОСМП, Яндекс-Деньги, ФСГ и д.р.

Наличие встраиваемых модулей для 1С: Предприятие 7.7 и 8.1

Eсть только для версии 1С 7.7

Eсть: 1С версии 7.7 и 8.0

1С 8.0 опционально

Наличие дежурного персонала технической поддержки в режиме 24х7

Наличие Web управления

Наличие возможности локализации интерфейса без участия разработчиков

Наличие документированного API (способ реализации: собственный протокол, стандартный протокол и т.п.)

Открытая структура БД

Eсть. (Напрямую через Oracle client, XML-RPC, REST, SOAP)

Eсть, Oracle PL/SQL

Eсть, недокументированное (хранимые процедуры)

Наличие открытой и документированной структуры БД хранилища

Eсть для получения данных. Изменение информации в БД возможно только через API.

Наличие Mediation уровня (перечислить основные протоколы по которым возможно получение первичных данных об оказанных услугах)

RADIUS, Netflow, Sflow, SNMP, CDR, RS-232

RADIUS, Netflow, Sflow, Netstream, SNMP, SOAP, CDR, RS-232

Eсть. (Netflow, SNMP, CDR, RADIUS accounting, Cisco Raw Data

Records (RDR), sFlow, Нестандартные схемы (текстовый формат))

RADIUS, Netflow, SNMP, SOAP, File (FTP и SMB)

RADIUS, Netflow, Sflow, jFlow, SNMP, CDR, RS-232

Eсть: Netflow, Cisco IP-accounting, SNMP, RADIUS, FTP, SFTP, Netbios (Samba), RS-232

RADIUS, NetFlow, SNMP, CDR, File, SQL

RADIUS, Netflow, Sflow, SNMP, SOAP, CDR,

Нестандартные схемы (текстовый формат))

Наличие подсистемы предбиллинга

Eсть (телефония), Netflow DB (ШПД)

Eсть встроенный минимум

Возможность перерасчета предыдущих отчетных периодов (абонентская плата и услуги)

Наличие возможности тарифных списаний по одному событию с нескольких расчетных счетов (сущностей, например: И с абонента И оператора)

Наличие настраиваемых пользователем шаблонов отчетных документов

Eсть, система документооборота

Возможность пользователю подключать собственные интерфейсные модули в интерфейс управления АСР

Возможность заключения нескольких договоров с одним пользователем (без необходимости дублирования его записи в АСР) и раздельное ведение расчетных счетов по нескольким договорам

Интеграция с системами управления собственностью (PMS), если Eсть, то указать с какими

PMS Fidelio, Отель

Eсть через API (внедрений не было)

Наличие возможностей определения прогрессивных тарифных изменений тарифной ставки (скидок от времени, объема, выходного дня, бонусов, корректировок). Указать какие виды могут быть определены в АСР.

Eсть (от времени суток, объема, выходного дня, бонусы)

Eсть (от времени, объема, выходного дня)

Скидки от времени суток, типа дня, бонусов, корректировок, трафика

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

Настраиваемая система бонусов и скидок, позволяет задать любую логику, в том числе и плавное изменение цен по формуле

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

Да: комбинации от: времени, объёма, средств, израсходованных по услуге за период

Eсть. Спец. дни, время, объем потребленной услуги.

Eсть (от времени суток, объема, выходного дня, бонусы, скидки)

Возможность определения прогрессивных тарифных изменений индивидуально для каждой тарифной категории (направления МГ/МН трафика телефонии, IP сети услуг ШПД и т.п.)

А в ихних Америках уже даже социальные службы обзаводятся такими системами, делая денежные потоки более прозрачными и простыми.

Это отдельный огромный пласт технологий и знаний. И, что логично, сложность зависит от масштабов сети.

Небольшая локальная сеть организации

Начнём, пожалуй, с крохотных SOHO (Small Office/Home Office).

В общем, всё это сети, где в качестве шлюза или, по крайней мере NAT-сервера, выступает Unix-компьютер с iptables и, возможно, прокси-сервером.

Здесь правят бал бесплатные микробиллинговые системы: WinRoute Spy, Squid2mysql, StarGazer Billing System, ipq_traffic. Есть и представители платных, конечно, вроде, Lingate, например.

Но часто админам не хочется допиливать чужое глючное решение, и они садятся сами писать скрипты. В итоге вполне может получить кастомизированное приложение, которое узко заточено под нужды ~~этого админа~~ этой фирмы.

Я лично с такими решениями не знаком совершенно.

Сети крупных предприятий или небольшие провайдеры

Как правило, в качестве сетевого оборудования для маршрутизации трафика здесь используются полноценные аппаратные маршрутизаторы (Cisco/Huawei/HP/Juniper итд) либо, гораздо реже, высокопроизводительные сервера.

Требования к АСР здесь уже несравнимо выше.

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

В-третьих, АСР должна хранить в БД всех клиентов с их атрибутами (счёт, реквзиты, адрес, комментарии, баланс, тариф, квоты), обеспечивать работу сразу нескольких операторов, иметь пользовательский интерфейс для клиентов.

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

В-четвёртых, АСР должна обеспечивать генерацию отчётов любой детализации. Это приводит нас к понятию многоуровневой базы данных. Нужно соблюдать баланс между скоростью составления отчётов и нагрузкой на БД.

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

На втором уровне будут классифицированные и чуть более детализированные данные. Например, вы сможете запросить по конкретному абоненту за нужный час какой объём трафика был по разным сервисам.

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

В случае аппаратных маршрутизаторов для сбора данных используется специальный протокол, такой, например, как NetFlow у Сisco или NetStream у Huawei. Суть его в том, что через определённые промежутки времени будут отправляться данные о трафике на указанный в настройках хост. А можно и то же самое зеркалирование.

В чём разница, спросит юный читатель, между простым зеркалированием и спец. протоколом?

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

При этом зеркалирование настраивается не на адрес хоста, а на физический порт. То есть чтобы довести трафик до биллинг-сервера, нужно прокидывать или прямой кабель или VLAN.

Спец. протоколы могут отправлять не полный поток данных, а с некой периодиченостью усреднённые данные, экономя и ресурсы и пропускную способность.
Плюс в настройках конкретно можно указать адрес хоста, куда нужно данные перенаправлять. Они будут инкапсулированы в IP-пакеты и смаршрутизированы до получателя.

Обычно, помимо биллинга используется ещё специальный анализатор, который позволяет более гибко работать с трафиком, рисовать красивые картинки и создавать годные отчёты. Для Cisco, например, есть Netflow Analyzer.

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

Самые яркие представители АРС данного класса: АСР Ideco, UTM NetUp, Bill-Master, Traffic Inspector итд.
Все они платные и все они сертифицированные. Но если с последним вопрос не стоит, то, возможно, вам будут интересны следующие варианты: Tmeter, NetProfile, Katrin, NeTAMS.

Монстры

Здесь остро встают вопросы межоператорского взаимодействия, роуминга, когда АСР должна уметь интерпретировать данные не только из своей сети, от своих устройств, но и предоставленные третьей стороной, со всеми параметрами и полями, которые важны всем втянутым операторам. ITU (Международный Союз Электросвязи) разработал универсальные стандарты, которых должны придерживаться разработчики систем биллинга.

Основные требования к комплексам такого уровня:

Решения в виде пропуска всего трафика через сервер или netflow тут никак не годятся. Это же десятки, а то и сотни гигабит. Нет, друзья, тут другой подход.
Есть такое понятие как CDR. Расшифровывается это как Call Detail Record.
Оборудование, осуществляющее доставку и коммутацию звонка, формирует запись CDR с некоторой периодичностью или после окончания вызова и передаёт биллинговой системе.
Ну а она в свою очередь на основе этих данных формирует счета.

Это принцип работы в первом приближении.

Несмотря на название сейчас этот термин используется в более широком смысле. CDR сейчас генерируются не только АТС, SGSN и прочим оборудованием голосовой связи, но и устройствами пакетной передачи: GGSN, DPI, маршрутизаторы и прочее.

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

В такой ситуации и SGSN, и GGSN, и DPI могут генерировать CDR, выкладывать их в определённый каталог в хранилище, а биллинговая система будет их забирать и выкатывать счета на основе тарифов (дополнительные данные также содержатся в CDR). То есть в данном случае это будет информация не о времени и направлении звонка, а об объёме трафика и запрошенных ресурсах.

Схема сети с системой OCS (*картинка из официальной документации Huawei)

Phonekeeper - современная биллинговая программа тарификации от компании Т-Софт. Биллинговая система PHONEKEEPER - актуальная система биллинга для операторов связи и корпоративного сектора.

BG Биллинг - универсальная биллинговая система для средних и крупных операторов связи. АСР (автоматизированная система расчетов) высшего уровня автоматизации

биллинг , биллинговая , аср , dialup , vpn

Google PageRank: 0 из 10 Яндекс ТИЦ: 0

биллинг , биллинговая , аср , dialup , vpn

Google PageRank: 0 из 10 Яндекс ТИЦ: 20

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

аср , биллинг , billing

Биллинговая система для провайдеров. Биллинг для RouterOS Mikrotik, pppd, Cisco под управлением Linux и FreeBSD. Динамический шейпер и гибкая тарификация, HotSpot.

Universal billing system – первая универсальная биллинговая система, сочетающая в себе широкие возможности готового конвергентного биллинга и гибкость, целенаправленность и простоту «Hand Made» решений.

аср , конвергентный , конвергентность , ubs , учет трафика

Google PageRank: 1 из 10

Биллинговая система. Биллинг. Купить внешний биллинг. SaaS решения для операторов связи на платформе АСР Platex.

Google PageRank: 0 из 10 Яндекс ТИЦ: 10

Латера биллинговая компания, биллинг нового поколения

биллинг , латера , гидра

Биллинговая система. Автоматизированая система расчетов. Купить внешний биллинг и аср от Inotech.

Google PageRank: 2 из 10

Google PageRank: 0 из 10 Яндекс ТИЦ: 0

Биллинг - это инструмент для интернет-бизнеса. Включает online-магазин и систему управления хостингом, серверами, доменами, ssl, лицензиями с полной автоматизацей. billing, биллинг, билинг, биллинг для хостинга, панель управления хостингом, русский биллинг.

billing , биллинг , bill , билинг , биллинговая

Google PageRank: 0 из 10 Яндекс ТИЦ: 10

Google PageRank: 0 из 10 Яндекс ТИЦ: 0

Биллинговая система. Автоматизированая система расчетов. Купить внешний биллинг и аср от Inotech.

Google PageRank: 2 из 10

Динамика популярности - Биллинговая система для интернет провайдера

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

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

Обязательное требование, система должна быть сертифицированной.

на вскидку - lanbilling, UTM

Фпомойку этот UTM, бери сразу адекватный биллинг, чтобы потом не расхлебывать - BGBilling.

UTM вообще недоразумение. Хотел оттуда систему тарифов слямзить для своего билинга, так все закручено.

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

Платная, цены разумные, варьируются в зависимости от заказанного функционала. Рекомендую.

здравствуй спамер, ты опупел?

>Операционная система
>Sun Solaris 10 (i86 или SPARC архитектуры)

>СУБД
>ORACLE DATABASE 10g
>ORACLE XE 10g

> здравствуй спамер, ты опупел?

.. конструктивно, ничего не скажешь

Можно такие вещи брать в аутсорс, это дешевле. Для сравнения, "ВладИнфо" - крупный по меркам Владимира ? Насколько я знаю, они так делают.

>.. конструктивно, ничего не скажешь

не вырывайте из контекста, прокоментируйте применения оракела для управления 1000-ю договорами :o)

> не вырывайте из контекста, прокоментируйте применения оракела для управления 1000-ю договорами :o)

1. человек не уточнял речь идет о физ. или юр.лицах, поэтому 1000 договоров это такая не совсем точная фраза 2. они никогда не будут расширяться? 3. не будем холиварить на тему оракла и, например, mySQL - у каждой СУБД свои ниши. И никто не говорит о том, что получение он-лайн актуальной клиентской статистики возможно под mySQL без задержек.

Если ставить вопрос лишь о ведении клиентской базы с 1000 договарами и данными по рабочим процессам в компании - конечно, оракл будет неуместен. В вопросе непосредственно реализации _биллинга_ это уже другой разговор - он вполне уместен и mySQL (например) ему уступает.

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

вот именно. лучше брать бгбиллинг, как уже говорили.

aspa Чего такого используется, чего, скажем, нет в PostgreSQL? Ну и вдогонку вопрос - скока стоит необходимый набор лицензий на Оракл для конечного пользователя?

+ БГБиллинг нормально справляется с 5к пользователей, дальше (15-20к) я бы смотрел в сторону биллинга Forward. В своё время плотно вопрос изучал, и недоразумения вроде BillMaster или UTM оскомину набили.

дык это ERP, как только звучит это словосочитание - вспоминаем или Ораклоидов или МежДелМаш ДБ

Читайте также:

Рейтинг биллинговых систем для интернет провайдеров

Небольшая локальная сеть организации

Сети крупных предприятий или небольшие провайдеры

Монстры

Похожие тематики

Динамика популярности - Биллинговая система для интернет провайдера