MMSC Функциональные и технические требования

MMSC

Функциональные и технические требования

Оглавление

1.        Введение        3

2.        Общие требования        3

3.        Функциональные требования        4

3.1        Требования к MMS-обмену        4

3.2        Соответствие стандартам        5

3.3        Требования к дополнительному функционалу        5

3.3.1.        Web-интерфейс и архив сообщений        5

3.3.2.        MMS-Переадресация        7

3.3.3.        MMS-Автоответ        8

3.3.4.        MMS-Black/White lists        9

3.3.5.        MMS-Группа        9

3.3.6.        Тарификация дополнительного функционала        10

4.        Требования к интеграции        11

5.        Технические требования        13

5.1        Общие требования        13

5.2        Требования по нагрузке на систему        14

6.        Требования к гарантийной и послегарантийной поддержке        15

7.        Требования по интеграции        15

8.        Требования по управлению системой        15

9.        Требования по мониторингу        16

10.        Требования по статистике        20

11.        Требования по аудиту        23

12.        Требования по документации        25

13.        Требования к предоставлению консультационных услуг по эксплуатации и управлению решением        27

Введение

Данный документ содержит функциональные и технические требования для центра обмена мультимедийными сообщениями (MMSC), устанавливаемого в Иркутской области в целях оптимизации архитектуры обмена сообщениями MMS в сети .

Общие требования

Центр обмена мультимедийными сообщениями (далее MMSC) должен выполнять следующие основные функции:

Обмен мультимедийными сообщениями (MMS) между абонентами БВК и других операторов с учётом технологии MNP; Обслуживание трафика на всей территории предоставления услуг связи (Иркутская область, Республика Бурятия, Читинская область); Обслуживание обмена MMS-трафиком с внешними операторами; Предоставление расширенных возможностей использования MMS абонентами .

Для реализации указанных функций MMSC должен состоять из следующих основных функциональных элементов:

ПО для обработки сообщений с возможностью размещения на отдельном сервере (кластере серверов); ПО для реализации дополнительных функций с возможностью размещения на отдельном сервере (кластере серверов); ПО для маршрутизации сообщений с возможностью размещения на отдельном сервере (кластере серверов); Хранилище буфера сообщений; Тарификационного модуля для интеграции с биллинговой системой ; БД профилей абонентов; Системы управления и мониторинга; Системы генерации статистики и отчетов.

Функциональные требования Требования к MMS-обмену

Основной функцией MMSC является обеспечение обмена мультимедийными сообщениями между абонентами с учётом технологии MNP, для чего он должен выполнять роль MMS Server/Relay в соответствии со стандартами, перечисленными в п. 3.2 :

Обеспечение приема сообщений от абонентов и передачи сообщения абонентам мобильной сети; Поддержка большого объема сообщений (до 2Мбайт); Хранение сообщения в буфере в течение его срока доставки; Хранение информации о сообщениях  и сами сообщения для СОРМ в течении 30 дней. Поддержка отображения MMS-сообщения через WAP, WEB интерфейс, путем отправки адресату уникальной ссылки в виде SMS-сообщения. MMS-сообщения в виде WAP/WEB ссылки отправляется тем абонентам, который сами изъявили желание получать ссылки вместо MMS-сообщений или тем с которыми не возможен MMS обмен; Маршрутизация сообщений между абонентами, приложениями и другими MMS Server/Relay; Перенаправление абонента на внешнюю платформу(используемые протоколы: MM3, MM4, MM7); Генерация отчетов о доставке/прочтении сообщений, в том числе при маршрутизации сообщений между различными интерфейсами ММ1/3/4/7; Хранение профилей абонентов в БД MMSC; Автопровижионинг абонентов и наличие SOAP-интерфейса для провижионинга из внешних платформ (например АСР); Онлайн-тарификация сообщений/событий по DIAMETER; Выгрузка записей CDR. В рамках поддержки MNP, маршрутизация MMS-сообщении должна осуществляться по IMSI.

Соответствие стандартам

Решение должно соответствовать следующим стандартам и спецификациям, где они применимы:

3GPP TS 22.140 “Multimedia Messaging Service (MMS); Stage 1” Rel. 6 3GPP TS 23.140 “Multimedia Messaging Service (MMS); Functional description; Stage 2” Rel. 6 OMA Multimedia Messaging Service V1.3 RFC 2865 Remote Authentication Dial In User Service RFC 2866 Radius Accounting RFC 2869 Radius Extensions RFC 3588        Diameter Base Protocol. RFC 4006        Diameter Credit-Control Application.

Требования к дополнительному функционалу

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

Указанный в данном разделе дополнительный функционал должен поддерживаться предлагаемым Решением с возможностью демонстрации и запуском в коммерческую эксплуатацию в течение 30 календарных дней после заключения дополнительного соглашения. Стоимость дополнительного функционала должна быть указана отдельными строками в коммерческом предложении на MMSC.

Web-интерфейс и архив сообщений

Решение должно иметь возможность предоставлять абоненту web-интерфейс управления своим профилем на MMSC для изменения списка и/или параметров дополнительных услуг. Абоненту должен быть доступен архив MMS к следующим видам сообщений и самостоятельно производить следующие настройки:

исходящие сообщения, за исключением сообщений, отправленных в рамках автоответа и переадресации; входящие сообщения (включая сообщений от контент-провайдеров); сомнительных (попавших в «черный» список или не попавших в «белый» список при их наличии)

Размер архива (объем, отведенный под хранение сообщений на одного абонента) должен настраиваться. Начальный размер – 100Мб. При приближении использованного объема к границам размера архива, абоненту должна приходить нотификация, содержащая информацию об ограничении емкости архива и о кол-ве свободного места в архиве. В web-интерфейсе архива так же должна быть отражена информация по заполненности архива. Абонент должен иметь возможность увеличить размер архива из web-интерфейса. При превышении доступного объема архива старые сообщения замещаются в порядке их сохранения новыми сообщениями. При недоступности БД архива сообщений, поступающие сообщения должны сохраняться во временном буфере с последующим сохранением в основной БД.

Срок хранения MMS в архиве во время пользования услугой неограничен. Доступная информация: номер абонента, дата, время, статус (отправлено, доставлено, не доставлено), текст и файлы отправленного сообщения.

Web-интерфейс решения должен соответствовать требованиям корпоративного стиля .

MMS-Архив может подключить/отключить сам абонент в web-интерфейсе решения или с помощью отправки команды на сервисный номер по SMS или через доступные каналы управления услугами (ИССА, абонентская служба и т. д.).

В каждом случае при подключении/отключении MMS-Архива абоненту должна приходить SMS-нотификация с оповещением о подключении/отключении услуги.

Помимо абонента должна быть предусмотрена возможность отключить MMS-Архив у абонентской службы.

После отключения MMS-Архива и в случае окончательной блокировки либо передаче SIM-карты другому лицу MMS-Архив должен автоматически удаляться.

Ограничений на использование архива в национальном и международном роуминге не предусматривается.

Возможность хранить в web-интерфейсе адресную книгу абонентов услуги. В следующем формате: Имя (не более 30 знаков латиницей или кириллицей) и MSISDN (не более 4 на одну запись), возможность распределять контакты по различным папкам.

Должна быть обеспечена возможность загрузки адресной книги из файла в формате Microsoft Excel или текстовый файл с разделителями.

Доступ к web-интерфейсу должен осуществляться при помощи пары логин/пароль. Первоначально пароль для входа в web-интерфейс создается платформой и отправляется абоненту, затем абонент должен иметь возможность изменить пароль самостоятельно (при обращении к платформе), при обращении в абонентскую службу, IVR, USSD-команды. При входе в web-интерфейс абоненту должна приходить нотификация об авторизации в WEB-интерфейсе.

MMS-Переадресация

Решение должно позволять абонентам устанавливать переадресацию входящих MMS-сообщений от различных GSM-операторов на MSISDN (любого GSM-оператора).

Переадресация может быть:

безусловная (переадресуются все сообщения); переадресация входящих mms с определенных номеров; безусловная переадресация по времени. 

Переадресацию MMS может подключить/отключить/настроить сам абонент в web-интерфейсе решения или с помощью отправки команды на сервисный номер по SMS или через USSD-запрос.

В каждом случае при подключении/отключении MMS-переадресации абоненту должна приходить SMS-нотификация с оповещением о подключении/отключении услуги.

Необходимо предусмотреть возможность оповещения абонента-получателя о том, что ему поступило переадресованное MMS (Например, в тексте mms-сообщения добавить концовку: «Данное mms-сообщение переадресовано!» или указать префикс “FW>”).

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

В случае окончательно блокировки абонента все настройки MMS-переадресации автоматически удаляются.

Переадресованное сообщение абоненту-получателю должно доставляться с номера абонента-отправителя (т. е. абонент А отправляет MMS-сообщение абоненту Б подписчику услуги, у которого стоит переадресация на номер С. Сообщение на номер С должно быть доставлено с номера А).

В детализации счетов абонентов необходимо предусмотреть идентификатор переадресованной MMS (для исходящей записи только). Входящие MMS, до и после запуска механизма переадресации, в детализации счетов абонентов должны отражаться без изменений.

Ограничения на пользование услугой в национальном и международном роуминге не предусматривается.

Переадресованные MMS в сервисе тарифицируются по цене исходящих MMS на ТП абонента.

MMS-Автоответ

Решение должно позволять абонентам устанавливать автоматический ответ на входящие MMS-сообщения (P2P):

безусловный (автоответ отсылается на все входящие сообщения); автоответ на входящие mms с определенных номеров; безусловный автоответ по времени. 

Предусмотреть возможность оповещения абонента, установившего автоответ, об отправленном автоответе и возможность отключить это оповещение абонентом. Исходящие сообщения автоответа должны рассылаться как P2P от абонента, установившего автоответ.

Решение должно иметь возможность отключения отправки автоответа на входящие A2P MMS с сервисных номеров, предназначенных для любых видов рассылок (транспортные, контентные, нотификационные рассылки).

MMS-автоответ может подключить/отключить/настроить сам абонент в web-интерфейсе решения или с помощью отправки команды на сервисный номер по SMS.

В каждом случае при подключении/отключении MMS-автоответа абоненту должна приходить SMS-нотификация с оповещением о подключении/отключении услуги.

В случае окончательно блокировки абонента все настройки MMS-автоответа автоматически удаляются.

Помимо абонента должна быть предусмотрена возможность отключить MMS-автоответ у абонентской службы.

Для создания сообщения, используемого как автоответ, в web-интерфейсе должны быть предусмотрены соответствующие инструменты и шаблоны. У администраторов Решения должны быть инструменты управления (создания, редактирования и активации) шаблонами.

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

MMS-Black/White lists

Решение должно позволять абонентам настраивать «черный» и «белый» списки для входящих MMS, а также контентных номеров.

Решение должно иметь API для внешней платформы «Черно-белый список» используемой для sms и голосовых вызовов и иметь возможность по управлению списками:

добавление/удаление номера в список; активация/деактивация списка.

Решение должно иметь глобальный «черный» и «белый» список, действие которых распространяется на всех абонентов.

MMS-Группа

Решение должно позволять абонентам рассылать исходящие сообщения на группу абонентов любого оператора сотовой связи, используя вместо абонентского номера имя группы. Размер группы – до 30 абонентов. Количество групп у абонента – до 10. Должен быть обеспечен максимально простой вариант пользования услугой с мобильных терминалов для абонентов. Варианты должны быть предоставлены поставщиком Решения.

В web-интерфейсе, должна быть предусмотрена возможность создавать/изменять/удалять группы.

В web-интерфейсе должна быть закладка для создания/редактирования групп и отправки сообщений всем участникам группы.

Номера телефонов должны вводиться без пробелов, в любом формате, через запятую.

Максимально разрешенный размер файла: 500 Kb;

Разрешенные к отправке форматы файлов:
image/gif — gif, image/jpeg — jpg, jpeg, image/png — png, video/3gpp — 3gp, audio/mpeg — mp3, audio/midi — mid, midi, audio/mmf — mmf, audio/amr — amr, audio/x-wav — wav.

Длина имени группы не более 30 символов.

Тарификация зависит от количества адресатов в группе. Выгрузка в CDR по каждому отправленному сегменту.

Должна быть защита от спама, а именно рассылка не более определенного кол-ва сообщений в течение дня.

Тарификация дополнительного функционала

При использовании дополнительных сервисов, должна быть обеспечена возможность тарифицировать:

Тарификация услуг должна происходить по следующим сценариям:

единовременно (плата за подключение пакета услуг) на регулярной основе (ежемесячная абонентская плата за пакет услуг) исходящие сообщения для всех сервисов – в соответствии с тарифным планом абонента; для групповых рассылок – каждое исходящее сообщение в соответствии со списком рассылки (стоимость отправки одного сообщения * количество адресатов в рассылке). В случае онлайн-тарификации при недостаточном балансе для отправки групповой рассылки, она не отправляется целиком;

Требования к интеграции

       MMSC представляет собой программно-аппаратный комплекс, интегрированный с рядом платформ и комплексов на сети (рис.1)

Рисунок 1. Cхема интеграции MMSC  МРМ в сеть

Интеграция MMSC должна производиться со следующими системами :

SMSC: отправка уведомлений о сообщениях; MMS-push: массовые рассылки MMS (MM7); MMSC других регионов/операторов: обмен MMS-трафиком (MM4); MDDrive: провижионинг абонентов (SOAP); MD_CDR: выгрузка CDR (FTP/SFTP); Биллинг: тарификация событий при использовании онлайн-тарификации (DIAMETER); Zabbix: взаимодействие с системой мониторинга и ТП (SNMP/SSH/FTP);

Архитектура системного решения должна быть «прозрачной» для сети. Система должна быть интегрирована в сеть без необходимости вносить изменения в абонентские мобильные устройства.

Для поддержки операций массового мигрирования абонентов должны поддерживаться интерфейсы поточной загрузки данных:

file-based provisioning; SOAP-интерфейс; хранимые процедуры в БД.

Технические требования

       Решение должно быть развернуто на оборудовании текущего решения:

HP ProLiant DL360 G6 CPU E5540 @ 2.53GHz RAM 6Gb – Основной сервер HP ProLiant DL360 G5 CPU E5150 @ 2.66 GHz RAM 3Gb – Резервный сервер Общие требования

Решение должно поддерживать следующие основные принципы:

1)        отказоустойчивость (99,999%, «пять девяток» доступности);

2)        масштабируемость;

3)        управляемость;

4)        безопасность.

Программные компоненты Решения должны иметь подтвержденную возможность разворачивания в виртуальной среде (private cloud) на базе технологий VMware.

Решение должно соответствовать следующим требованиям:

1)        иметь Сертификаты соответствия (Декларации о соответствии) Минсвязи РФ, Сертификаты соответствия ГОСТ Р;

2)        иметь патент или документ, подтверждающий отсутствие необходимости в данном патенте, на сложный программный комплекс в целом или компонент, входящий в состав комплекса;

3)        обеспечивать логическое разделение с управлением доступом для сетевого трафика  управления (management), данных (traffic) и т. д., например, через использование подсетей;

4)        иметь настроенную службу NTP;

5)        иметь настроенную службу SNMP;

6)        иметь настроенный инструментарий резервного копирования и восстановления данных ключевых компонентов. Резервное копирование должно осуществляться ежедневно в автоматическом режиме и без влияния на оказываемый сервис, а данные храниться не менее 1 (одного) месяца. БД профилей абонентов и архив сообщений должны храниться в зашифрованном виде;

7)        поддерживать возможность переноса БД Решения на серверы БД Компании;

8)        ОС, установленные на серверном оборудовании Решения, должны быть серверной версии. Версии ОС и программных модулей должны быть из стабильных релизов не ниже предпоследней версии на момент поставки Решения;

9)        иметь криптографически защищенный GUI-интерфейс управления абонентскими профилями (настройка, подключение/отключение услуг и т. д.) с поддержкой возможности пакетной загрузки;

10)        иметь документированный API;

11)        иметь Интернет-ресурс для взаимодействия с технической поддержкой (ТП) Поставщика по решению инцидентов и проблем. Также Поставщик должен быть готов при необходимости провести бесплатную интеграцию интерфейса по работе с инцидентами/проблемами Компании со своим интерфейсом по работе с инцидентами/проблемами.

Требования по нагрузке на систему

Требования по нагрузке – 20TPS. Профиль трафика приведен в таблице №1.

Таблица 1. Профиль трафика MMS

Интерфейс	0-30 Кб	30-50 Кб	50-100 Кб	> 100 Кб
MM1	32%	10%	17%	41%
MM3	49%	8%	13%	29%
MM4	31%	12%	19%	38%
MM7	65%	6%	12%	17%

БД профилей абонентов MMSC должна рассчитываться для обслуживания 5 млн абонентов.

Механизмы массового мигрирования должны обладать производительностью не менее 100 операций добавления/удаления абонентов в секунду.

Объем хранилища для сообщений в Архиве должен строиться из расчета обслуживания 100 000 абонентов.

Требования к гарантийной и послегарантийной поддержке

Решение должно иметь гарантийный период 1 год.

Техническая поддержка должна оказываться по схеме 24х7. График работы профильных квалифицированных специалистов должен пересекаться с графиком работы специалистов (GMT+9) не менее чем на  6 часов.

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

Требования по интеграции

Для организации плавной миграции абонентов на новое решение необходимо наличие ММ1 маршрутизатора.

Для осуществления взаимодействия с внешними БД решение должно поддерживать протоколы SOAP, LDAP (W3C SOAP 1.1 standard) и SQL.

Взаимодействие с системой мониторинга должно осуществляться по протоколу SNMP.

Интеграция с SMSC должна осуществляться по протоколу SMPP3.4.

Требования по управлению системой

Система управления должна поддерживать следующие возможности посредством GUI-интерфейса:

конфигурирования Решения; сбора статистики по работе Решения; мониторинга всех узлов Решения и процессов, запущенных на них; управления настройками абонентов; удалённого администрирования; управления Решением в зависимости от уровня доступа (оператор, администратор, абонентская служба). Customer Care (для разбора инцидентов) для всего реализованного функционала.

Вышеуказанные интерфейсы не должны предоставлять доступ непосредственно к сообщениям, обрабатываемым функционалом Решения.

В состав решения должны входить средства тестирования работоспособности внутренних механизмов – генераторы тестовых сообщений для всех реализованных интерфейсов.

Требования по мониторингу

Система мониторинга должна соответствовать следующим требованиям:

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

2)        должны быть предоставлены MIB-файлы;

3)        поддерживать возможности мониторинга по протоколу SNMP;

Система мониторинга должна поддерживать 3 (три) типа трапов:

1)        трап, сигнализирующий о возникновении аварии (newAlarm);

2)        трап, сигнализирующий об устранении аварии (clearAlarm);

3)        трап об аварии, которая не требует устранения (Alarm).

На каждый трап newAlarm обязательно должен приходить clearAlarm. Уникальным ключом в комбинации newAlarm/clearAlarm является связка alarmId/object. На основе этих данных происходит автоматическая очистка списка аварий.

Примеры типов трапов:

1)        при возникновении аварийной ситуации на платформе, формируется трап (пример MIB-файла приведен ниже):

newAlarm {

       severity ::= 5

       alarmId ::= "CPU1_HIGH_LOAD"

       object ::= "hostname"

       text ::= "CPU usage is abnormal"

}

2)        при устранении аварийной ситуации, формируется трап:

clearAlarm {

       severity ::= 1

       alarmId ::= "CPU1_HIGH_LOAD"

       object ::= "hostname"

       text ::= "CPU usage is normal"

}

3)        если требуется информирование о ситуации, которая не может быть устранена (к примеру: ошибка ввода пароля, ошибка в запросе в WEB-интерфейсе и т. д.), формируется трап:

alarm {

       severity ::= 3

       alarmId ::= "SSH_FAILED_LOGIN"

       object ::= "hostname"

       text ::= "Login failed for user root"

}

4)        пример MIB-файла с описанием трапов:

-- Skip some unnecessary definitions like IMPORTS, MODULE-IDENTITY etc.

-- Needed objects

severity OBJECT-TYPE

       SYNTAX  INTEGER {

               critical(5),

               major(4),

               minor(3),

               warning(2),

               normal(1)

       }

       ACCESS  not-accessible

       STATUS  mandatory

       DESCRIPTION

               "Severity of alarm"

       ::= { enterprise 1 }

alarmId OBJECT-TYPE

       SYNTAX DisplayString (SIZE (0..64))

       ACCESS not-accessible

       STATUS mandatory

       DESCRIPTION

               "Identification of alarm"

       ::= { enterprise 2 }

object OBJECT-TYPE

       SYNTAX DisplayString (SIZE (0..64))

       ACCESS not-accessible

       STATUS mandatory

       DESCRIPTION

               "Object"

       ::= { enterprise 3 }

text OBJECT-TYPE

       SYNTAX DisplayString (SIZE (0..255))

       ACCESS not-accessible

       STATUS mandatory

       DESCRIPTION

               "Additional information"

       ::= { enterprise 4 }

-- Traps definition.

newAlarm NOTIFICATION-TYPE

       OBJECTS {

               severity,

               alarmId,

               object,

               text

       }

       STATUS current

       DESCRIPTION

               "Notification indicates that new alarm was occurred."

       ::= {trap 1}

clearAlarm NOTIFICATION-TYPE

       OBJECTS {

               severity,

               alarmId,

               object,

               text

       }

       STATUS current

       DESCRIPTION

               "Notification indicates that alarm was cleared."

       ::= {trap 2}

alarm NOTIFICATION-TYPE

       OBJECTS {

               severity,

               alarmId,

               object,

               text

       }

       STATUS current

       DESCRIPTION

               "Notification indicates about something, which will not be ch as login error, failed querys etc."

       ::= {trap 3}

MIB-файл должен соответствовать международным стандартам (RFC 2578), то есть должен включать в себя полное описание модуля, включая импортируемые типы.

Полный OID трапов должен быть вида 1.3.6.1.4.1.your_enterprise_id.... enterprise id должен быть официально зарегистрирован в соответствующих органах (http://www. iana. org/assignments/enterprise-numbers).

Требования по статистике

Решение должно соответствовать следующим требованиям:

осуществлять сбор статистических данных о работоспособности/доступности ее узлов и компонентов; поддерживать возможность настройки счетчиков по заданным параметрам для дополнительного мониторинга качественных показателей ее работоспособности; значения счетчиков должны отображать изменение наблюдаемого показателя за прошедший интервал времени; предоставлять информацию об используемых/задействованных лицензиях; предоставлять информацию по загрузке основных интерфейсов в разбивке по времени, направлению; предоставлять информацию о количестве активных абонентов, а также общее количество абонентов с возможностью дополнительной выборки за определенный интервал времени (час, день, месяц); отображать статистическую информацию в графическом виде посредством GUI-интерфейса; формировать отчеты за прошедший период в любом интервале времени до 5 (пяти) минут включительно; поддерживать возможность изменения интервала хранения статистических данных, но не менее 6 (шести) месяцев; поддерживать возможность распределения ролей пользователей при формировании статистических отчетов.

В зависимости от типа присоединения к элементам сети Компании перечень требований к статистике может быть расширен. В этом случае он согласуется отдельно в рабочем порядке.

Предложенная система отчетности должна предоставлять GUI интерфейс для просмотра отчетов.

Предложенная система отчетности должна наглядно предоставлять данные о производительности Решения.

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

Статистическая информация о работе системы.

С заданной периодичностью необходимо создавать файлы со статистической информацией (счетчиками) о работе системы. Пример счетчиков: число успешно/неуспешно переданных сообщений, число успешно/неуспешно принятых сообщений, число переданных нотификаций и т. д. Набор счетчиков, выводимый в файл, и периодичность записи статистики должна настраиваться администраторами (от 1 минуты до 24 часов). Значение счетчика, записываемого в файл, должно являтся разницей между текущим значением счетчика и значением счетичика в предыдущий отсчет. Имя файла должно составляться по заданному шаблону (из переменных YYYY, MM, DD, HH24, MI). Необходима возможность записи разного набора счетчиков в разные файлы с разной периодичностью.

Пример:

С периодичностью в 5 минут в файл с именем YYYY-MM-DD_HH24 (если такового нет, файл создается, если есть – добавляется в имеющийся) записываются значения счетчиков: sm_recieved, sm_transmitted, route_info_ok, route_info_fail. Значение, записываемое в файл, является разницей между текущим значением счетчика и значением счетчика 5 минут назад, то есть является относительным значением за указанный интервал времени.

Формат файла следующий:

YYYY-MM-DD HH24:MI (Время снятия данных)

counter, value

counter2,value2

.....

YYYY-MM-DD HH24:MI

counter, value

counter2,value2

Пример файла (2013-08-24_12.txt):

2006-08-24 12:05

sm_recieved,256

sm_transmitted,289

route_info_ok,250

route_info_fail,53

2006-08-24 12:10

sm_recieved,266

sm_transmitted,269

route_info_ok,256

route_info_fail,50

.....

Следующий файл начинает писаться в 13:00 (2013-08-24_13.txt):

2006-08-24 13:00

sm_recieved,26

sm_transmitted,28

route_info_ok,20

route_info_fail,3

2006-08-24 13:05

sm_recieved,66

sm_transmitted,48

route_info_ok,30

route_info_fail,13

.....

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

Отчеты должны экспортироваться в файл ( в форматах Excel, HTML и т. д.).

Требования по аудиту

Решение должна соответствовать следующим требованиям:

1)        поддерживать механизм протоколирования событий;

2)        хранить журналы аудита в оперативном доступе минимум 3 (три) месяца;

3)        предоставлять возможность сохранять журналы аудита на серверном оборудовании Компании;

4)        осуществлять протоколирование следующих событий:

- успешные и неуспешные попытки входа в систему, аутентификации пользователей;

- успешные и неуспешные попытки доступа к объектам защиты (данным конфиденциального характера);

- действия привилегированных пользователей по настройке и изменению конфигурации Решения (в том числе изменение настроек аудита);

- действия привилегированных пользователей по настройке и изменению конфигурации абонентов;

-  успешные и неуспешные попытки доступа пользователя к данным Решения и другим ресурсам;

-  доступ к записям журнала протоколирования событий;

-  действий в ОС, а также ftp/ssh-соединений;

-  запуск и остановка Решения и её компонентов;

-  проведение финансовых транзакций;

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

5)        осуществлять регистрацию следующей информации:

- дату и время события;

- идентификатор пользователя, выполнившего операцию;

- IP-адрес или иной источник события;

- название или тип выполненного события;

- результат события;

- объект, над которым была выполнена операция.

6)        предоставлять средства фильтрации событий журнала аудита по критериям, указанным в пункте выше;

7)        журналы аудита Решения не должны содержать данные конфиденциального характера;

8)        журналы аудита Решения должны быть защищены от изменений.

Требования по документации

Набор необходимой документации должен включать в себя:

Техническое описание Решения:
Общее описание Решения; Техническую документацию по эксплуатации Решения; Документацию на интерфейсы массового провижионинга; Перечень атрибутов доступа (логинов/паролей) к интерфейсам Решения; Описание продукта с детальной документацией по устройству системы, её логическим модулям, подробное описание внутренних и внешних интерфейсов взаимодействия, правил настройки и администрирования модулей и интерфейсов; Документацию по формированию и мониторингу аварийных/информационных сообщений; Описание методов сбора и анализа статистической информации; Схему интеграции оборудования в локальную/коммутационную сеть; Схему взаимодействия внутренних компонентов системы (сетевая, электрическая, коммутационная и др.);
Методику расчета расширения Решения, включающую в себя:

Описание принципов расширения и резервирования; Описание максимально возможной конфигурации Решения; Описание принципов увеличения производительности системы (программно и аппаратно); Описание максимально возможной аппаратной конфигурации предлагаемого оборудования с указанием производительности каждого модуля.

Методики функционального и технического тестирования поставляемого Решения. Во время приемки участники комиссии оставляют за собой право проводить любое дополнительное тестирование функциональности системы; Сертификат соответствия Минсвязи РФ на поставляемое Решение. Поставщик отвечает за получение сертификатов соответствия в уполномоченных на то сертифицированных органах РФ на Решение, поставляемое им и его субподрядчиками к моменту подписания акта приемки системы, и несёт все связанные с этим расходы. Описание Решения должно быть предоставлено на русском языке; Описание Решения также должно подробно отображать:

Логику предоставления сервисов (use-cases); Графический интерфейс администратора, пользователя услуги; Дополнительные возможности Решения, заявленные поставщиком/производителем.

Документы, подтверждающие права поставщика на поставляемое ПО; Описание процесса оформление прав на передаваемое ПО.

Требования к предоставлению консультационных услуг по эксплуатации и управлению решением

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

Проведение консультационного семинара производится силами поставщика с организацией демонстрации работы на реальной системе.

Содержание семинара должно включать в себя:

Администрирование решения Сбор статистики Troubleshooting Прочие необходимые разделы, необходимые для оптимальной эксплуатации, управления и поддержки решения

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

Предложение должно содержать раздел, подробно описывающий процесс организации и содержание консультационного семинара, а также стоимость участия в нем специалистов (в расчете на 1 чел.).