Рейтинг биллинговых систем для интернет провайдеров
За последние несколько лет телекоммуникационная отрасль демонстрировала динамичный экспоненциальный рост, что привело к развитию спроса на эффективные биллинговые системы. Давайте обсудим, какие данные собирает биллинг?
Отрасль
Да, львиная доля спроса на биллинг приходится на телекоммуникационный рынок. Однако некоторые вендоры выбирают узкую специализацию. Так ряд биллинговых систем учитывает особенности сферы ЖКХ, а есть системы только для взаиморасчетов между участниками рынка контент-услуг: операторами, провайдерами, агрегаторами. Если составлять общий рейтинг систем, придется учитывать конечных пользователей биллинга, поскольку программа, заточенная под ЖКХ, не подойдет энергетической компании. Если ваш бизнес не относится к телекому, стоит поискать узкоспециализированных вендоров или выбрать универсальное решение у опытного производителя и доработать его под себя.
Безопасность биллинга
Чрезвычайно важно обеспечить гибкую структуру процесса сбора данных, используя механизм отката для коррекции ошибок. Не в последнюю очередь этот процесс должен подвергаться очень строгому тестированию. Это позволяет сохранить клиентов и снизить административную нагрузку.
Поставщики телекоммуникационных услуг получают огромные преимущества, если они используют проверенные биллинговые системы связи. Эти системы по сути являются интеллектуальными программами, которые могут работать в соответствии с заданными командами в автономном режиме.
Основные требования к компании, использующей биллинговую систему:
Иногда эта информация регистрируется в одной информационной системе, которая также поддерживает выставление счетов. Однако такой подход имеет ряд существенных недостатков. Как правило, это приводит к возникновению неприятных ситуаций, в которых отсутствует возможность внесения в процесс каких-либо изменений.
Чаще используются различные дополнительные программы, которые предоставляют конечные данные для биллинговой системы. В компаниях, осуществляющих услуги связи, это зависит от сетевых операторов.
В открытых источниках нет подробных и структурированных рейтингов биллинга, и этому есть объяснение. Критерии, по которым оцениваются системы, неоднородны. К тому же следует учитывать специфику компании, размер бизнеса и развитие программы под современные требования клиентов.
Персонализация тарифов
Тарифы, который пользователь настраивает под себя ─ новый тренд, который становится нормой. Абонент сам выбирает, сколько ему нужно интернета, звонков, минут и сервисов. Пакеты связи настраивается с точностью до минуты и гигабайта. Чтобы запустить персонализированные услуги, нужна тонкая настройка в биллинге ─ и операторы начинают дорабатывать или обновлять АСР, чтобы не отставать от рынка.
Распространенность
Если бы рейтинг биллинга составляли по популярности, в ТОПе однозначно были ли самописные программы. Несмотря на то, что в 2000-х годах большая часть операторов массово переходила на конвергентные биллинговые системы, мы до сих с завидной регулярностью сталкиваемся с самодельным ПО. На втором месте был бы “базовый” биллинг для малого бизнеса - это недорогие программы с ограниченным функционалом. Такие системы обычно на слуху, их часто обсуждают на форумах.
Благодаря тенденциям сокращения затрат на обслуживание ПО и перехода на облачные технологии набирают популярность и модели SaaS . С созданием облачного биллинга конкурентоспособные программы стали доступны среднему и малому бизнесу, поэтому многие компании телекоммуникационной сферы пользуются возможностью работать в современных системах. Стоит отметить, что Forward Telecom первым вывел на рынок облачный биллинг, и наша команда уже много лет обслуживает и развивает “облака”.
Биллинговые системы для крупных игроков - это целый автоматизированный комплекс управления компанией и полноценный проект внедрения. Такие программы отказоустойчивые, охватывают весь цикл работы с абонентами и умеют обрабатывать большие объемы информации ежесекундно. Переход на новый биллинг или внедрение программы с нуля - затратный и долгий процесс. Вендоры “крупных” биллингов делают ставку на качество, а не на количество, и работают с именитыми компаниями и корпорациями. Ищите информацию о таких внедрениях на тематических ресурсах, сайте производителя и в разделах “Пресс-релизы”.
OTT-сервисы и партнерство
Важность быстрой и качественной доставки мультимедийного контента растет, операторы активно заключают партнерства с онлайн-кинотеатрами, блогерами и т.п. Помимо этого развиваются коллаборации и партнерские предложения. Что это значит для биллинга? Для создания комплексных решений нужна прямая интеграция в биллинг оператора, а сама АСР должна поддерживать разные модели тарификации продуктов партнера и возможность встраивать их в другие сервисы. Еще один вариант реализации договоренностей ─ экосистемы от вендора биллинга, в которую включена программа для работы с партнерами.
Сбор данных - основа успешного биллинга
Качество процесса выставления счетов зависит от правильности использования доступной информации. Без достоверных данных невозможно создать корректные счета. Процесс сбора данных может быть довольно сложным, поэтому многие компании используют биллинг для операторов связи для выставления счетов.
Процессу выставления счетов предшествуют другие действия:
- Приобретение и заказ продукта;
- активация продукта;
- подключение и доставка услуг.
Далее эти процессы генерируют различные виды данных, относящихся к формированию счетов:
- Данные клиента (в том числе и личная информация);
- Данные договора;
- Данные продукта (описания и цены);
- Данные заказа;
- И т.п.
Чтобы собрать всю эту информацию и привести ее в соответствие с биллинговой платформой, необходимо настроить автоматизированный процесс - сбор данных.
Централизация и автономия процесса сбора данных
Выставление счетов за телекоммуникационные услуги - это процесс сбора и группировки услуг или продуктов связи определенных учетных записей, или клиентов с целью регистрации их транзакций. В дальнейшем, используя данные биллинга, производится отправка счетов, а также регистрация и хранение платежей, сделанных на основе учетных записей клиентов.
Сложность, связанная с технологиями мобильных устройств и тарифными планами, предлагаемыми поставщиками телекоммуникационных услуг, в конечном итоге проложила путь к разработке эффективных и надежных биллинговых систем связи.
Динамика и развитие
Биллинг - не та программа, которую можно один раз создать и затем годами тиражировать. У операторской гонки в телекоме - бешеный темп. К биллингу, как к ключевой системе работы провайдеров, требования постоянно растут. Поэтому успешные биллинговые программы сегодня уже останутся далеко позади завтра, если не будут подстраиваться под требования рынка. Это и переход на OSS/BSS-решения, и Big Data, и искусственный интеллект, и интернет вещей, и облачные сервисы, и модульная архитектура. И это только тенденции последних пяти лет.
Операторы заинтересованы в том, чтобы функциональность биллинга росла быстрее, чем стоимость поддержки, при этом система не должна быть сложной. На передний план выходит потребность в оперативном наращивании новых модулей и блоков, чтобы опережать конкурентов и быстро выпускать новые продукты. Меняются и сами операторы - сильными соперниками становятся MVNO, которым требуется недорогой в обслуживании биллинг и быстрый старт системы.
Как вычислить вендоров, которые непрерывно развивают свои продукты? Стоит посмотреть на даты последних проектов и пресс-релизов. Желательно, чтобы у производителя были внедрения в последние 2-3 года - тогда можно с уверенностью сказать, что вендор в курсе новинок рынка и потребностей клиентов. Такую статистику можно найти на Tadviser , сделав отбор по 2017-2019 годам.
Разные цели и размеры как бизнеса, так и биллинговых систем не позволяют составить исчерпывающий рейтинг биллинга. Надеемся, что помогли сориентироваться, где можно добыть информацию и на что обратить внимание при выборе программы.
2020 год стал проверкой на прочность для всех ─ в том числе для телекоммуникационных компаний, которым пришлось резко перестраивать работу под колоссальный рост трафика. А параллельно на пятки наступает eSIM и 5G. Об особенностях внедрения биллинга в 2020 году и ближайших тенденциях ─ в этой статье.
Сначала поговорим о том, что уже известно, но набирает обороты.
Биллинг 2020 ─ новые идеи и технологии
Биллинг для eSIM
Операторы уже начали налаживать бизнес-процессы для подключения абонентов с помощью eSIM ─ некоторые из них уже начали использовать новую технологию, а некоторые подготавливают почву. Хорошая новость ─ с точки зрения биллинга (часть BSS) и железа внедрение eSIM будет для операторов не затратным. Меняется только процесс подключения: здесь изменения уже принципиальные и требуют переработки процессов. Скоро готовое решение для подключения eSIM в биллинге будет обязательным условием для вендоров.
От теории к практике
Нередко компании используют сервера в дата-центре для безопасного хранения данных своих клиентов. Однако далеко не все могут обеспечить их качественное обслуживание. Например, у одного нашего клиента произошла поломка, а он даже не подозревал об этом. Он позвонил в нашу техподдержку, и специалисты выяснили в чем заключалась проблема. Дело в том, что наша система проверяет в режиме реального времени обслуживаемые нами системы. Таким образом, мы заранее можем определить неисправность и сообщить об этом клиенту.
Именно поэтому важно, чтобы данные считывались биллинговой системой напрямую и с высокой частотой (желательно в реальном времени, но не реже одного раза в день) с устройств провайдера. Посредническая платформа может быть включена в настройку телекоммуникационной компании, но также может быть частью программного обеспечения от внешнего поставщика биллинговых услуг.
Экосистемы
Отдельно биллинг внедряют все реже ─ теперь операторы и провайдеры предпочитают обзаводиться целой экосистемой с биллингом во главе. Вместе с АСР внедряют сразу программы для работы с партнерами, для управления оборудованием, BPM, личный кабинет абонентов. Это удобно ─ чаще всего такая экосистема от одного вендора, так что системы легко интегрируются друг с другом и правильно обмениваются информацией.
А теперь поговорим о новшествах ─ чем удивили проекты в этом году и тенденции биллинга в 2021.
Единая система
Операторы и провайдеры, которые еще не успели объединить разрозненные биллинги в один, торопятся сделать это как можно быстрее. Делается это в основном для сокращения Time-to-market, упрощения создания пакетных предложений и снижения операционных расходов.
Если вы думаете, что время MVNO прошло, то спешим заверить, что это не так. Продуктовые ритейлеры и корпорации (Магнит, Яндекс) готовятся к запуску собственных виртуальных операторов, MVNO создаются даже для государственных нужд (ГЛОНАСС). С ростом количества MVNO растет и потребность в простом, недорогом, но при этом современном функциональном биллинге, который поможет быстро стартовать и обеспечит быстрый выпуск продуктов. Не последнюю роль играет и маркетинговый блок. Стартаперы все чаще обращают внимание на облачный биллинг, который закрывает все эти потребности.
Есть и еще одна тенденция ─ виртуальные операторы не просто выбирают модель Full MVNO, но и готовы серьезно дорабатывать биллинг, чтобы выпускать VIP-сервисы или предоставлять премиальное обслуживание (Next Mobile).
Сбор, преобразование и консолидация данных
Современные технологии предлагают достаточно возможностей для передачи данных с одной платформы на другую. Выбор состоит между API, простым импортом файлов или гибридным решением и зависит от нескольких параметров:
- Сроки процесса. Требуются ли использовать дополнительные данные для анализа биллинга.
- Количество записей. Чем больше объем данных, тем сложнее их распределение с точки зрения производительности системы.
Процесс сбора данных должен быть хорошо продуман и точно сопоставлен в соответствии с запросами:
- Какие данные биллингу требуются для процесса выставления счетов за услуги связи?
- Какая система должна их снабжать?
- Как можно сопоставить структуру сбора данных со структурой биллинговой платформы?
- Каким образом опосредуются данные об использовании услуг?
- Нужна ли дополнительная предварительная обработка и как это должно быть сделано?
Эффективное решение для выставления счетов за телекоммуникационные услуги должно позволять компании легко внедрять новые тарифные планы без нарушения каких-либо текущих процессов выставления счетов.
Операторы покупают разработчиков биллинга
Tele2 купил своего партнера Bercut Ltd, который много лет обслуживал и дорабатывал биллинг оператора. По словам представителей, это закономерное развитие многолетней работы и аккумуляции опыта. Теперь IT-поставщик целиком в распоряжении Tele2: это позволит сократить затраты на поддержание биллинга, ускорить запуск новинок, расширить портфель продуктов и быстро корректировать текущие сервисы. В том числе это повлияет и на “фабрику MVNO” ─ оператор будет активно развивать биллинг для виртуальных операторов, работающих на инфраструктуре Tele2, чтобы те предоставляли клиентам инновационные продукты. Возможно, такая эволюция бизнеса оператора связи станет не последней и в скором времени мы узнаем о подобных поглощениях у других игроков рынка.
Биллинг для 5G
Пора готовить биллинги к сетям 5G: в 2020 году Huawei уже запустила первый конвергентный биллинг для монетизации сетей 5G с автономной архитектурой. Для работы с сетями нового поколения нужна универсальная, открытая и гибкая биллинговая система, обеспечивающая монетизацию на всех уровнях. Биллинг должен поддерживать сотни сочетания 5G-услуг, сети с автономной и неавтономной архитектурой, а также желательно контейнеризацию и виртуализацию для сокращения операционных затрат и сокращения времени запуска проектов.
Подведем итог: биллинг 2021 года ─ это гибкий биллинг с персонализацией тарифов, возможностью подключения сложных партнерских программ и готовностью к новым технологиям. Сложно? Да. Интересно? Как разработчики биллинговых систем, мы ответим ─ еще бы!
Каждый начинающий хостер всегда задается вопросом — что лучше использовать в качестве биллинг-системы. При этом вопрос этот сложный, а выбор мучителен. Что лучше — взять дешевле (но потом столкнуться с проблемами в виде недостаточной гибкости и универсальности), или взять дороже (но половину возможностей не использовать)?
Так как по своей работе сталкивался и сталкиваюсь до сих пор с множеством биллингов, постараюсь перечислить наиболее популярные и описать их сильные и слабые стороны.
Итак, начнем-с.
1. RootPanel
- Отечественный разработчик (из Украины)
- Большое количество поддерживаемых платежных систем, регистраторов и панелей управления
- Есть возможность покупки в исходном коде — можно дорабатывать самому
- Простота установки (устанавливается как обычная CMS, специальных требований нет)
- Очень развитое API
- Панель закодирована Zend — поэтому есть проблемы с работой в среде PHP 5.3 + FreeBSD (проще говоря — не поддерживается)
- Приобретая вечную лицензию вы все равно остаетесь привязаны к разработчику — лицензию нужно обновлять каждые 3 месяца (и от него же зависит — продлит он ее или нет). А разработчик может резко пропасть, примеры — тут и тут
- Интерфейс администратора ужасно неудобный (хотя весь функционал на месте)
- Документация практически отсутствует на сайте
2. BillManager
- отечественный разработчик (из Украины)
- приемлимое количество платежных систем, регистраторов и панелей управления
- хорошо работает в связке с другими продуктами ISPSystem
- документация есть на сайте разработчика
- бывают проблемы с установкой, и вы не можете этот процесс контролировать — вы скачиваете только скрипт инсталлятора, который не всегда корректро работает на нестандартных конфигурациях и дистрибутивах (а биллинг написан на С). На личном опыте скажу что иногда удавалось запустить только с третьего раза.
- Практически отсутствует API
- Неочевидность настройки — новичку будет сложно разобраться
3. Bpanel
- простая в работе
- количество платежных систем, регистраторов и панелей управления немного, но начинающиму хватит
- неочевидность настройки и отсутствие документации
- похоже панель остановилась в своем развитии
- API отсутствует
4. Joonte
Цитата с сайта: «система является абсолютно бесплатной». Быстро развивающийся биллинг.
Пока поддерживает слишком мало платежных систем и регистраторов, чтобы говорить о профессионатьном практическом применении.
- Простота установки (устанавливается как обычная CMS, специальных требований нет)
- Огромное количество поддерживаемых платежных систем, регистраторов и панелей управления
- Большая коллекция дополнений, расширений и т.д., дополняющих основной функционал
- Отлично документирована (правда на английском, частично есть русская документация)
- Очень развитое API
- Локализация иногда «похрамывает» — сказывается изначально английский интерфейс
На самом деле систем учета клиентов для хостеров достаточно много — я привел лишь самые популярные и подходящие начинающим. Также я специально не присал про биллинги, которые не адаптированы под на — без перевода и нужных платежных систем они на нашем рынке бесполезны.
Что выбрать — решайте самомостоятельно. Хотя мне кажеться наиболее практичным решение взять для старта RootPanel, немного помучаться, набрать клиентов и перейти на WHMCS (благо скрипт перехода какой-никакой, но есть).
Предыстория:
Некие хорошие люди решили начинать провайдерский бизнес. Растянули и разварили оптику в небольшом районе, поставили ящички, засунули туда минимальные свичи, с помощью которых можно организовать VLAN-Per-User, закупили небольшой, для начала, канал у ближайшего магистрала. Встал у них вопрос о том, чем же считать пользователям трафик/денежки и нарезать скоростя.
Общая схема сети должна выглядеть следующим образом:
Кому интересно, далее под катом очень много букв и картинок.
Условности:
— Шлюз аплинка будет 1.2.3.3
— Сетевые адаптеры NAS смотрящие на аплинка будут в сети 1.2.3.3/24
— Сеть, предоставляемая пользователям, будет 172.16.0.0/18, или, если угодно, 255.255.192.0
— IP адреса 172.16.0.0-172.16.0.10 мы резервируем для серверов доступа и прочих собственных нужд
— Сервер пользовательской статистики будет доступен по адресу stat.isp и, учитывая бюджетность решения, будет находиться на одном хосте с биллинговым сервером, хотя хорошим тоном является не только разделять биллинг и трафик абонентов, но и разносить на раздельные хосты БД, ядро биллинга и веб-интерфейс.
Изначальные потребности были четко оговорены:
— Проектная емкость сети — до 10000 абонентов
— Раздача IP абонентам при помощи DHCP
— Авторизация либо по связке IP+MAC
— Несколько полностью безлимитных тарифов
— Трафик все же считать нужно для контроля
— Очень желательно видеть активность каждого отдельного пользователя
— Разделение прав касиров/бухгалтеров/менеджеров/администраторов
— Возможность масштабирования решения относительно роста количества абонентов
— Так как своей АС еще нету и в наличии имеются три с половиной айпишки, выданных аплинком, первых пользователей предполагается NAT-ить.
— Естественно все это максимально бюджетно :)
Беглое изучение ассортимента opensource биллинговых систем показало, что оптимальным в данной ситуации может оказаться Stargazer по следующим причинам:
— Проект открыт, активно развивается, новые версии выходят с завидным постоянством.
— Не страдает врожденной монстроидальностью и позволяет допиливать функционал не привязываясь к внутренней механике
— Ядро написано на C/C++ и категорически быстрое
— Большой выбор методов подсчета трафика
— На выбор поддержка хранения данных в Файлах/MySQL/Firebird/PostgreSQL
— Волшебный механизм исполнения команд на удаленных серверах
Установка будет проходить на голую FreeBSD 8.2-RELEASE, установленную в варианте kern-developer + порты. Весь трафик пользователей будем рулить через удаленный NAS на все
той же FreeBSD 8.2, производя по нему NAT/Shape/NetFlow и отрисовку графиков загрузки абонентского канала при помощи bandwidthd. В роли вебинтерфейса для stargazer 2.407-p1 у нас будет выступать последний на момент написания топика Ubilling 0.1.7, хотя выбор фронтендов у Stargazer довольно широк — от Win-конфигуратора до нескольких консольных и XML-RPC API.
Далее прямой копипаст из консоли с периодическими заострениями внимания на концептуальных моментах.
Итак приступим к настройке биллингового сервера.
1. Морально готовимся
2. Установка зависимостей
Для простоты isc-dhcp собираем без DHCP_PARANOIA
php5 должен быть собран как минимум с поддержкой CLI и модулем Apache (последний должен нормально подтянуться зависимостью)
Собираем жизненно необходимые расширения PHP, а именно: ставим галочки на MYSQL, MBSTRING и ICONV
3. Собираем сам stargazer и его консольные конфигураторы в две строчки :)
4. Разворачиваем текущую версию Ubilling
5. Делаем особую симлинковую магию
6. Запускаем Apache и MySQL
8. Приводим /etc/stargazer/stargazer.conf к следующему виду
9. Редактируем конфиг /etc/stargazer/rules оставля аж одно нужное нам направление, а именно интернеты.
10. Добавляем наш первый NAS в /etc/stargazer/remote_nas.conf
10. запускаем/останавливаем stargazer
11. Убеждаемся, что умолчальная БД развернулась
12. Редактируем /usr/local/etc/sudoers, добавляя туда пользователя, под которым будет работать Web интерфейс
13. Разворачиваем дамп Ubilling
14. Убеждаемся, что все хорошо
15. Редактируем файл config/billing.ini, доводя его до кондиции:
16. Разворачиваем заготовки стартовых скриптов
17. И делаем прибивание IP+MAC в скрипте /etc/stargazer/OnConnect
18. Редактируем конфиг /etc/stargazer/config, прописывая в него текущие параметры MySQL
19. Аналогично редактируем конфиг config/mysql.ini
20. Запускаем stargazer и меняем пароль администратора по умолчанию
21. приводим наш /etc/rc.conf к виду
22. Добавляем служебную зону ".isp" в /etc/namedb/named.conf
и в /etc/namedb/master/isp
23. Создаем стартовый скрипт запуска stargazer в /etc/rc.d/billing
и назначаем ему нужные права
25. Правим глобальный шаблон по которому будут генерироваться конфиги dhcp, он находиться вот здесь: /usr/local/www/data/billing/config/dhcp/global.template
26. Выставляем нужный уровень логирования для dhcpd в /etc/syslog.conf
27. Можем сделать профилактический ребут чтобы посмотреть как все подымается, либо поперезапускать все, что мы уже понастраивали вручную.
28. А теперь самое интересное ради чего все затевалось :)
Заходим на наш servername.isp/billing и логинимся с логином и паролем по умолчанию admin/demo (не забываем сразу же сменить) и видим следующую картину:
Добавляем нужный нам класс трафика:
Добавляем сеть и сервис (напоминаю, что мы резервируем первых 10 IP под свои нужды)
Добавляем сети обработчик DHCP
и применяем к нему свой шаблон подсети
намекая таким образом, что шлюз по умолчанию должен быть в сторону нашего NAS сервера.
Проверяем, удачно ли создается конфиг dhcpd.conf в справочнике «Сети»
Добавляем свой первый тариф, пусть он будет зваться Unlim-1 и будет безлимиткой с абонплатой 50 денег в месяц
Навешиваем на него симметричную скорость в 1 мегабит/с
Добавляем наш сервер доступа который мы будем настраивать чуть пожже
В справочниках Городов, Улиц и домов добавляем наш населенный пункт, улицы и дома где будут жить абоненты
Ну и вроде все, регистрируем нашего первого абонента
Назначаем ему MAC, тариф, вписываем Ф.И.О. и все что нужно в «редактировании», и, в общем-то, он должен работать.
Настройка NAS сервера.
Опять же, имеем Голую FreeBSD 8.2, от которой хотим, чтобы она выступала шлюзом по умолчанию для наших пользователей.
Нужные модуля можно и просто подгрузить, но это дело привычки, так что соберем ядро руками с попутным выкидыванием всего что нам не нужно.
Заменяем в конфиге нашего нового ядра ident GENERIC на NAS1
И собираем/ставим его в одну строчку:
Следим за тем, чтобы наш /etc/rc.conf имел где-то такой вид:
Отличный сенсор NetFlow
И умеренно врущий, но идеально простой в настройке bandwidthd для отрисовки per-user графиков
PHP собираем с поддержкой CLI
И модуль MYSQL к нему
Приводим наш /etc/firewall.conf к виду:
Выставляем правильные права на наш скрипт инициализации фаервола
Собираем rscriptd и обеспечиваем его запуск при ребуте
редактируем /etc/rc.d/rscriptd, приводя его к виду
и назначаем ему правильные права
Разворачиваем заготовки скриптов Ubilling
Настраиваем bandwidthd для того, чтобы он рисовал красивые графики, которые мы потом должны лицезреть в Ubilling:
В файл /usr/local/bandwidthd/etc/bandwidthd.conf вписываем сеть наших пользователей
добавляем периодический SIGHUP для bandwidthd в crontab -e
Обеспечиваем при загрузке запуск
И как последний штрих, добавляем более-менее универсальные вещи, помогущие хоть как-то поднять быстродействие в дальнейшем в /etc/sysctl.conf
После перезагрузки получаем работающий NAS, получающий удаленно команды от биллинга, отправляющий ему сведения о трафике и все остальное, что от него требовалось.
Хотелось бы еще написать о настройке кабинета пользователя, недокументированых «фичах» с переходом на следующий месяц и прочих вещах, на которых можно споткнуться в первое время. Но статья и так уже получилась слишком монстроидальной и нудной. Обещаюсь, если карма позволит, на недельке описать все эти вещи в отдельном сказании.
Базы данных – коротко о главном
Нельзя отрицать, что наличие надежной системы, которая использует биллинг для услуг связи, является важным компонентом телекоммуникационного оборудования.
Чтобы понять, как работает биллинг, нужно представлять его основной функционал:
Читайте также: