Структура системы Мы выяснили, какие задачи должна выполнять разрабатываемая система и рассмотрев типичных представителей данного класса систем далее необходимо спланировать внутреннюю архитектуру биллинговой системы. Она должна включать следующие элементы:
коллекторы информации о потребленных услугах;
система аутентификации абонентов;
ядро (бизнес-логика);
многоуровневая БД;
модуль авторизации;
модуль анализа типов трафика (локальный, пиринговый, etc);
модуль разграничения доступа;
модуль статистики;
административный интерфейс для ручного управления абонентами;
интерфейс управления счетами абонентов и тарифами.
Для обеспечения возможности модификации системы в целом и отдельных её компонентов, а также добавления модулей, расширяющих функциональность системы необходимо соблюдать модульный принцип построения системы. Структуру взаимосвязи модулей системы можно увидеть на диаграмме компонентов системы, представленной на рисунке 12.
Рисунок 12 – Диаграмма компонентов системы
Модуль пересчета дневных лимитов трафика В корпоративной среде Интернет играет немаловажную роль. Многие компании используют как минимум электронную почту и имеют возможность выхода в Интернет. Некоторые имеют интернет-представительство — сайт. Еще некоторая часть компаний имеет свои порталы для внутреннего пользования, а также с возможностью внешнего входа для своих же сотрудников или клиентов.
Для части руководителей Интернет так же уже давно перестал быть экзотикой: это не только статья затрат, но и источник возможной прибыли, иногда даже конкурентное преимущество.
С другой стороны, существуют и проблемы:
интернет-каналы достаточно дороги, особенно если речь идет о высокой пропускной
способности (хотя ситуация здесь с каждым годом улучшается);
использование новейших технологий для получения дополнительных возможностей стоит
денег, иногда немалых;
существует необходимость обеспечения и поддержания постоянно высокого уровня
информационной безопасности, защиты от вирусов и хакерских атак.
Поэтому с ходом развития сетей связи и требований заказчиков у многих разработчиков систем учета и контроля Интернет трафика возникает необходимость не только вести учет потребления трафика, но и предоставлять дополнительные возможности.
Так, например, в связи с все ещё высокой стоимостью трафика, требуется оптимизировать использование канала Интернет.
Если переходить уже к рассмотрению проблем использования Интернет в учебном заведении, кроме того, что нельзя превысить выделенный вышестоящим провайдером лимит трафика на месяц, но и по возможности использовать эти объемы трафика по максимуму.
Со случаем попыток перерасхода трафика, бороться просто с помощью всего лишь одного управляющего воздействия – отключения пользователей, однако за период функционирования предыдущей версии биллинговой системы были выявлены следующие ситуации недорасхода оплаченного трафика:
Равномерное, малое расходование трафика всеми пользователями;
Потребление трафика не всеми пользователями;
Потребление трафика лишь часть расчетного периода;
Наличие большого числа выходных и праздничных дней.
В связи с этими проблемами получается следующая ситуация, когда для некоторых пользователей заблокирован доступ в Интернет, поскольку они исчерпали выделенный на их тарифный план лимиты трафика, другие, не используют Интернет по каким либо причинам, а в результате получается, что в конце месяца остается неизрасходованный трафик. В связи с этим был предложен метод пересчета лимитов трафика для тарифов.
Метод основан на определении выставлении рангов каждому тарифу, который определяет коэффициент участия тарифа в общем потреблении трафика.
Суть метода заключается в следующем. Каждому тарифу может соответствовать либо строго зафиксированный лимит трафика на месяц, в этом случае каждый пользователь данного тарифа имеет возможность использовать Интернет пока не израсходует положенную ему месячную норму, либо определенный ранг, в соответствии с которым для тарифа пересчитывается дневная норма.
Алгоритм функционирования этого метода представлен на рисунке 13.
Рисунок 13 – Обобщенный алгоритм работы модуля пересчета дневных лимитов трафика
где - предельное количество трафика, Мб;
- время до конца расчетного периода, дней;
- объем дневного трафика, Мб;
- количество трафика на 1 балл ранга, Мб;
- количество пользователей i-ого тарифа, чел;
- ранг i-ого тарифа;
- коэффициент участия данного тарифа в общем потреблении трафика;
- дневной лимит трафика, Мб;
- число, характеризующее допустимое для данного тарифа превышение дневной нормы (в количестве дневных норм). Рассмотрим алгоритм работы данного модуля. Имеется строго заданный лимит трафика на месяц, превышение которого влечет за собой финансовые потери. В каждый момент времени мы имеем фиксированный объем оставшегося трафика, и для расчета базового значения разрешенного объема дневного трафика просто поделим весь оставшийся трафик на количество дней до конца расчетного периода. Далее определяем количество трафика приходящегося на один балл ранга, для чего дневную норму делим на сумму баллов ранга всех тарифов. После чего для каждого тарифа рассчитываем коэффициент участия данного тарифа в общем потреблении трафика по формуле:
Именно для расчета этого коэффициента и была введена величина , дабы избавить администратора системы от расчетов данного коэффициента при выставлении рангов тарифа.
Первоначальное значение дневного лимита трафика для тарифа считается как произведение общего объема дневного трафика на коэффициент .
Теперь, рассмотрим то, что касается разрешенного превышения дневной нормы трафика. В системе предусмотрена возможность превышения установленной дневной нормы трафика пользователями тарифов, для этого каждому тарифу ставится в соответствие величина , которая показывает, во сколько раз пользователи данного тарифного плана могут превысить дневную норму потребления трафика. Если произведение дневной нормы рассчитанной ранее для тарифа и коэффициента превышения не превосходит величины объема рассчитанного для данного тарифного плана трафика, то значение этого произведения считается за конечную дневную норму. В противном же случае максимальный объем месячного трафика для данного тарифа принимается за дневную норму, что позволяет пользователю израсходовать весь полагаемый ему трафик за один день, после чего доступ в Интернет ему будет закрыт. Введение данного условия позволяет как не превысить выделенный на весь месяц трафик, так и не обделить при превышении пользователей других тарифов, так как для них действует своя норма трафика.
Кроме того, применение данного алгоритма при управлении трафиком обеспечивает возможность для технического персонала учебного заведения выбрать время для обновления лицензионного программного обеспечения через Интернет, например при соизмеримом с объемом этих обновлений остатке трафика в конце месяца.
|