также пароль. Значения IP–и MAC–адреса должны подставляться внешним скриптом авторизации.
В случае указания неправильного имени юнита получится:
login:0#login name r546–1a
parse: FAIL: unit with name= r546–1a is not exist
Неправильного пароля:
login:0#login name r546–1 password 123
parse: FAIL: password incorrect
Успешной авторизации:
login:0#login name r546–1 password 123456
parse: OK: login success from ip:0.0.0.0, mac:00:00:00:00:00:00
При этом в лог–файле сервера появится соответствующая запись.
logout {name AAA | oid BBBB}
password CCCC
[ip A.B.C.D]
[mac JJ:JJ:JJ:JJ:JJ:JJ]
Команда отключения пользователя, параметры такие же, как и у login.
[service billing]
NeTAMS разрабатывался изначально не как система биллинга, а как система учета трафика. Вследствие этого основными учетными единицами являются юниты. К сожалению, концепции юнитов, имеющих основным свойством статический IP–адрес, не достаточно для реализации полноценного биллинга. Для решения проблемы был организован новый сервис, service billing, основной целью которого стала «правильная» поддержка других типов учетных единиц — пользовательских аккаунтов.
Как сервис биллинга интегрируется в ядро NeTAMS:
1. Создается и поддерживается структура аккаунтов, где каждый аккаунт представляет собой учетную запись пользователя, имеющую следующие параметры:
а) имя, идентификатор, описание
б) индекс текущего тарифного плана, и того который вступит в действие со след. месяца
в) баланс
г) даты создания, модификации и прочее
д) список ассоциированных юнитов
е) емаил, пароль
ж) статус
2. При создании аккаунта необходимо привязать к нему один или несколько юнитов, по которым будет осуществлен учет трафика (юниты имеют IP–адрес и список политик учета трафика). При необходимости юниты создаются автоматически через веб–интерфейс.
3. Каждый аккаунт, если не включена его добровольная блокировка, имеет активный тарифный план (и план «на будущее»). Тарифный план характеризуется именем, описанием и списком «подпланов». Этим достигается возможность создания «гибких» планов.
4. Каждый подплан характеризуется:
а) политикой учета трафика. Она автоматически выставится для каждого юнита, который принадлежит соответствию «юнит–аккаунт–план–подплан»
б) количеством включенного в абонентскую плату трафика (раздельно входящий/исходящий, значение в мегабайтах или без лимита)
в) месячная абонентская плата: правило съема этой платы (единовременно/ежедневно и др.)
г) плата за превышение трафика, включенного в аб. плату, в у.е. за мегабайт (раздельно входящий/исходящий; «бесплатно»)
Набор скриншотов с веб–интерфейса управления биллингом:
• Сведения об аккаунте
• Настройки тарифного подплана
• Настройки тарифного плана
• Список юнитов
• Политики учета
• Лог–файл действий с аккаунтом
• Управление отдельным аккаунтом
• Карточка пользовательских сведений об аккаунте; задается шаблоном
subplan N
fee NNN
spread { monthly | daily | hourly }
included { XXX | unlimited } sum |
[ { XXX | unlimited } in ] [ { XXX | unlimited } out ] }
policy MMM
overdraft [ AA in ] [ BB out ] [ CC sum ]
adjust–included {yes|no}
adjust–fee {yes|no}
Команда subplan формирует тарифный подплан, из которого потом можно будет создать сложный тарифный план. Номер подплана N есть короткое число (это НЕ oid).
• fee NNN — определяет количество денег «абонентской платы», снимаемых за месяц, по данному подплану.
• spread { monthly | daily | hourly } - определяет, как будут сниматься эта «абонентская плата» — раз в месяц, раз в неделю или раз в час (в последних двух случаях снимается доля, пропорциональная указанному периоду)
• included { { XXX | unlimited } sum } | [ { XXX | unlimited } in ] [ { XXX | unlimited } out ] } - определяет, сколько (кило-, мега-, гига-)байт трафика включено в абонентскую плату. Величина XXX указывает на точное значение (возможны спецификаторы K, M и G после цифры). unlimited показывает, что включен весь трафик (нет ограничения). Задается ИЛИ раздельно для входящего и выходящего трафика, ИЛИ одно значение для суммы.
• policy MMM — задает заранее описанную политику acct–policy сервиса processor, которая будет применена для учета трафика для юнитов, принадлежащих клиенту.
• overdraft [ AA in ] [ BB out ] - определяет, сколько будет стоить превышение трафика (ИЛИ раздельно входящего и исходящего, ИЛИ суммы) в случае, если скачано больше, чем описано в параметре included
• adjust–included {yes|no} - определяет, будет ли проводиться перерасчет включенного в субплан абонентского трафика, если клиент подключился в середине месяца. Если значение равно «yes» (по умолчанию), то включенный трафик пересчитается пропроционально количеству дней, оставшихся до конца месяца. В противном случае клиент получит возможность бесплатно скачать весь предвключенный трафик.
• adjust–fee {yes|no} - определяет, будет ли проводиться перерасчет масячной абонентской платы, если клиент подключился в середине месяца. Если значение равно «no» (по умолчанию), то абонентская плата спишется полностью независмо от дня подключения, иначе — пропорционально числу оставшихся до конца месяца дней.
Команда subplan не умеет обрабатывать сразу все параметры, поэтому при конфигурировании придётся давать эту команду несколько раз с разными параметрами. Параметры этой команды группируются следующим образом:
subplan N fee NNN spread { monthly | daily | hourly }
subplan N included [ { XXX | unlimited } in ]
