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



Скачать 236.17 Kb.
Дата02.03.2018
Размер236.17 Kb.
#14048



MMSC

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

Оглавление


2.Введение 3

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

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

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

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

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

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

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

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

4.3.4.MMS-Black/White lists 9

4.3.5.MMS-Группа 10

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

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

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

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

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

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

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

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

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

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

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

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

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




  1. Введение


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


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

  • Обмен мультимедийными сообщениями (MMS) между абонентами БВК и других операторов с учётом технологии MNP;

  • Обслуживание трафика на всей территории предоставления услуг связи ЗАО «Байкалвестком» (Иркутская область, Республика Бурятия, Читинская область);

  • Обслуживание обмена MMS-трафиком с внешними операторами;

  • Предоставление расширенных возможностей использования MMS абонентами ЗАО «Байкалвестком».

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



  • ПО для обработки сообщений с возможностью размещения на отдельном сервере (кластере серверов);

  • ПО для реализации дополнительных функций с возможностью размещения на отдельном сервере (кластере серверов);

  • ПО для маршрутизации сообщений с возможностью размещения на отдельном сервере (кластере серверов);

  • Хранилище буфера сообщений;

  • Тарификационного модуля для интеграции с биллинговой системой ЗАО «Байкалвестком»;

  • БД профилей абонентов;

  • Системы управления и мониторинга;

  • Системы генерации статистики и отчетов.



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

    1. Требования к MMS-обмену


Основной функцией MMSC является обеспечение обмена мультимедийными сообщениями между абонентами с учётом технологии MNP, для чего он должен выполнять роль MMS Server/Relay в соответствии со стандартами, перечисленными в п. 4.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.
    1. Соответствие стандартам


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

  • 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.



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


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

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


      1. 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-интерфейсе.

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


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

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



  • безусловная (переадресуются все сообщения);

  • переадресация входящих mms с определенных номеров;

  • безусловная переадресация по времени.

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

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

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

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

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

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

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

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

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

      1. MMS-Автоответ


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

  • безусловный (автоответ отсылается на все входящие сообщения);

  • автоответ на входящие mms с определенных номеров;

  • безусловный автоответ по времени.

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

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

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

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

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

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

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

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


      1. MMS-Black/White lists


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

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



  • добавление/удаление номера в список;

  • активация/деактивация списка.

Решение должно иметь глобальный «черный» и «белый» список, действие которых распространяется на всех абонентов.
      1. 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 по каждому отправленному сегменту.

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


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


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

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



  • единовременно (плата за подключение пакета услуг)

  • на регулярной основе (ежемесячная абонентская плата за пакет услуг)

  • исходящие сообщения для всех сервисов – в соответствии с тарифным планом абонента;

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


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


MMSC представляет собой программно-аппаратный комплекс, интегрированный с рядом платформ и комплексов на сети ЗАО «Байкалвестком» (рис.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-интерфейс;

  • хранимые процедуры в БД.



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


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

  1. HP ProLiant DL360 G6 CPU E5540 @ 2.53GHz RAM 6Gb – Основной сервер

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


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

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


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


Требования по нагрузке – 20TPS. Профиль трафика приведен в таблице №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. Требования к гарантийной и послегарантийной поддержке


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

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

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

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


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

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

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

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



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


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

  1. конфигурирования Решения;

  2. сбора статистики по работе Решения;

  3. мониторинга всех узлов Решения и процессов, запущенных на них;

  4. управления настройками абонентов;

  5. удалённого администрирования;

  6. управления Решением в зависимости от уровня доступа (оператор, администратор, абонентская служба).

  7. Customer Care (для разбора инцидентов) для всего реализованного функционала.

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

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


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


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

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 cleared. Such 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).



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


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

  • осуществлять сбор статистических данных о работоспособности/доступности ее узлов и компонентов;

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

  • значения счетчиков должны отображать изменение наблюдаемого показателя за прошедший интервал времени;

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

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

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

  • отображать статистическую информацию в графическом виде посредством 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. Требования по аудиту


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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


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

  • Техническое описание Решения:

    • Общее описание Решения;

    • Техническую документацию по эксплуатации Решения;

    • Документацию на интерфейсы массового провижионинга;

    • Перечень атрибутов доступа (логинов/паролей) к интерфейсам Решения;

    • Описание продукта с детальной документацией по устройству системы, её логическим модулям, подробное описание внутренних и внешних интерфейсов взаимодействия, правил настройки и администрирования модулей и интерфейсов;

    • Документацию по формированию и мониторингу аварийных/информационных сообщений;

    • Описание методов сбора и анализа статистической информации;

    • Схему интеграции оборудования в локальную/коммутационную сеть;

    • Схему взаимодействия внутренних компонентов системы (сетевая, электрическая, коммутационная и др.);

  • Методику расчета расширения Решения, включающую в себя:

    • Описание принципов расширения и резервирования;

    • Описание максимально возможной конфигурации Решения;

    • Описание принципов увеличения производительности системы (программно и аппаратно);

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

  • Методики функционального и технического тестирования поставляемого Решения. Во время приемки участники комиссии оставляют за собой право проводить любое дополнительное тестирование функциональности системы;

  • Сертификат соответствия Минсвязи РФ на поставляемое Решение. Поставщик отвечает за получение сертификатов соответствия в уполномоченных на то сертифицированных органах РФ на Решение, поставляемое им и его субподрядчиками к моменту подписания акта приемки системы, и несёт все связанные с этим расходы.

  • Описание Решения должно быть предоставлено на русском языке;

  • Описание Решения также должно подробно отображать:

    • Логику предоставления сервисов (use-cases);

    • Графический интерфейс администратора, пользователя услуги;

    • Дополнительные возможности Решения, заявленные поставщиком/производителем.

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

  • Описание процесса оформление прав ЗАО «Байкалвестком» на передаваемое ПО.


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


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

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



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

  • Администрирование решения

  • Сбор статистики

  • Troubleshooting

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

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

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

Скачать 236.17 Kb.

Поделитесь с Вашими друзьями:




База данных защищена авторским правом ©vossta.ru 2022
обратиться к администрации

    Главная страница