Приложение 1 ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ к

ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ
к системе мониторинга сервисов IP TV
Версия: 1.
ОАО «МГТС»
г. Москва, 2015
1
Введение
Правила трактования информации
В данном документе перед параграфом (абзацем) текста устанавливается
специальный маркер в квадратных скобках для корректного понимания его сути
Участником Запроса:
[M] – параграф текста представляет собой требование, обязательное для
выполнения. Если Участник не подтверждает выполнение хотя бы одного обязательного
требования, Заказчик может исключить предложение из рассмотрения в рамках Запроса.
Ответ должен содержать детальное описание его реализации/достижения.
[O] – параграф текста представляет собой опциональное требование, которое
является дополнительным и необязательным к выполнению, но его наличие будет учтено
при комплексной оценке предложений участников;
[Q] – параграф текста определяет запрос информации от Участника. Участник
должен детально ответить на запрос, ответ будет использован Заказчиком в оценке
предложения;
[I] – определяет информационный параграф, который содержит дополнительные
данные для Участника.
Требования к ответам
Ответ Участника должен содержать маркер соответствия под каждым требованием.
Возможны следующие типы маркеров соответствия требованиям:
 Full compliance - полное соответствие и принятие требования в предложенной
Заказчиком формулировке, реализация которого в полном объеме включено в
коммерческое предложение;
 Non compliance - требование Заказчика не выполнимо, и/или не поддерживается
Решением, и его реализация не включена в коммерческое предложение;
 Partial compliance - требование Заказчика выполнимо не полностью, и/или частично
поддерживается Решением, но при этом его реализация в полном объеме включена в
коммерческое предложение. Участник должен дать исчерпывающий комментарий,
который позволит Заказчику оценить степень соответствия требованиям;
 Alternative - требование выполнимо альтернативным способом, отличающимся от
запрашиваемого и его реализация в полном объеме включена в коммерческое
предложение. Участник должен дать исчерпывающий комментарий, который позволит
Заказчику оценить степень достижения цели, обозначенной в требовании;
 Not Applicable - требование не может быть выполнено Участником, так как оно не
применимо к предложению от Участника и, следовательно, его реализация не
включена в коммерческое предложение.
Поставщик обязан предоставить документ SoC (подтверждение о соответствии) по
каждому пункту требований. Все комментарии к требованиям типа "Full compliance"
должны сопровождаться конкретной ссылкой на документальное описание указанного
модуля или функционала и означает, что Поставщик имеет готовый законченный
функционал и при необходимости готов его продемонстрировать. В случае отсутствия
документации или невозможности продемонстрировать заявленный функционал, такой
функционал считается не реализованным и отсутствующим (Non compliance).
2
1
Назначение системы мониторинга.
1.1
Система мониторинга сервисов IP TV ОАО “МГТС” (далее Система) создаётся для
обеспечения контроля качества ТВ сигналов в узловых точках пути доставки
контента до абонентов (точки приёма multicast, backbone и core сети).
1.2
Система предназначена для:
1.3

Автоматического сбора данных с пробов, установленных на сети Заказчика в
контрольных точках в реальном масштабе времени одновременно по всем
сервисам IPTV с учётом требований к глубине контроля каждого сервиса;

Автоматической фиксации аварий в реальном масштабе времени и их
отображения в интерфейсе пользователя (GUI) Системы;

Формирования сообщений об авариях для операторов, осуществляющих
контроль за работоспособностью услуги;

Обработки данных мониторинга, в т.ч. накопления, хранения, агрегации
статистики по вещаемым сервисам и формирования на их основе необходимых
отчётов.
Система должна обеспечивать непрерывный мониторинг в реальном масштабе
времени одновременно:

Не менее 500 SD сервисов и не менее 150 HD сервисов на выходе головной
станции на уровнях QOS и QOE в интерфейсе 10G

Не менее 500 SD сервисов и не менее 150 HD сервисов в точках приёма
мультикаст-трафика от ОАО “МТС” на уровне QOS в интерфейсе 10G;

Не менее 400 SD сервисов и не менее 100 HD сервисов в объектах ядра сети
МГТС на уровне QOS в интерфейсе 10G;

Не менее 10 SD и/или HD сервисов в узловых точках backbone и core сети с
возможностью перебора по списку.

Не менее 2-х QAM несущих одновременно в узлах DVB-C сети ОАО “МГТС”
Функциональная схема формированию услуги IP TV с указанием точек мониторинга
приведена в Приложении 1.
3
2
Состав Системы.
2.1
Система должна состоять из следующих элементов:
2.1.1 Анализаторов сигналов (АС) с поддержкой протоколов IP-транспорта: multicast
UDP/RTP, unicast UDP/RTP
2.1.2 Анализаторов сигналов (АС) с поддержкой протоколов ВЧ-транспорта: DVBС/QAM,
2.1.3 Центральной серверной системы (далее NMS) сбора и агрегации данных с АС,
с поддержкой функционала визуализации сетевых аварий в реальном времени;
2.1.4 Системы сбора, обработки и хранения исторических данных по авариям (далее
BD)
2.2
Требования к АС (АС).
2.2.1
Все типы
АС должны быть совместимы с существующей серверной
платформой “Система мониторинга качества ТВ сервисов сети МТС” (IneoQuest
iVMS/cVOC/cPAR)
Все типы АС должны обеспечивать:
2.2.2

Поддержку протокола ISO/IEC 13818-1 ”Generic coding of moving pictures and
associated audio information: Systems” (MPEG-2 TS)
 Аппаратный захват контролируемого трафика и первичную его обработку
выделенным процессором (вычислительным узлом);
 Автоматический сбор данных с заданных контрольных точек;
 Автоматическую проверку данных на предмет наличия аварий в соответствии с
действующими стандартами;
 Автоматическую проверку данных на предмет наличия аварий в соответствии с
заданными пользователем порогами;
 Генерацию аварийных сообщений при выходе контролируемых величин за
граничные значения;
 Настройку шаблонов граничных значений для групп потоков, индивидуально;
 Выделенный ethernet-интерфейс управления с поддержкой стандартных
протоколов обмена: HTTP, SSH, FTP, SNMP и др;
 Собственный web-интерфейс, независимый от системы визуализации аварий;
 Сохранение файлов конфигурации содержащие в себе: набор контролируемых
программ, настройку АС, маску порогов срабатывания аварий;
 Оповещение о возникающих аварийных ситуаций по протоколам SNMP (SNMP v1
traps, v2c traps, v traps);
 Загрузку готовых файлов конфигурации с набором программ, типовой
конфигурацией АС, маски срабатывания аварий через протоколы ftp, tftp, http
4
или другие стандартные протоколы не требующих проприетарной
авторизации и позволяющих выполнить соответствующую загрузку
конфигурационных файлов сторонним ПО;
 Возможность записи, хранения и импорта видеопотока в оригинальной IPинкапсуляции, при превышении порогового значений измеряемых параметров
или по команде оператора:
2.2.3 АС осуществляющие QOS мониторинг IP потоков должны обеспечить

Поддержку стандарта TS 102 034 “Transport of MPEG-2 TS based DVB Services
over IP based networks” (MPEG over IP);

Поддержку стандартов ISO/IEC 13818-1 1 ”Generic coding of moving pictures and
associated audio information: Systems” (MPEG2 TS) SPTS/MPTS;

Получение видеотрафика для анализа с граничных маршрутизаторов с
помощью одного из двух режимов:
o в пассивном, (без предварительного IGMP запроса);
o в активном, (с помощью посылок IGMP-запросов в сторону
маршрутизаторов);

Поддержка протоколов UDP, RTP, unicast, multicast, VLAN (тегированный
трафик), IGMP v2, v3 (SSM);

Выделенный порт 10/100 BaseT для управления;

Выделенный порт 1000 BaseT или 10G (зависит от точки установки) для
приёма измеряемого трафика;

Контроль и измерения параметров транспортного потока с видеоданными
форматов MPEG-2 (ISO/IEC 13818-2, -3), MPEG-4 Part 10 / H.264 (ISO/IEC
14496), SD / HD;

Мониторинг параметров в соответствии с ошибками первого и второго
приоритета рекомендаций ETSI TR 101 290 “Measurement guidelines for DVB
systems”;
 Мониторинг характеристик потока в соответствии с RFC 4445 “ A Proposed
Media Delivery Index (MDI)”;

Анализ PSI\SI таблиц транспортного потока в соответствии с действующими
стандартами и рекомендациями;

Возможность перебора списка потоков для последовательного контроля
(сканирование);

[O] возможность загрузки информации о вещаемых сервисах и потоках из NIT
и названий программ из SDT таблиц;

Измерение следующих параметров транспортной среды (QOS – Quality of
Service, Качество обслуживания):
o MDI (RFC4445): DF- джиттер, MLR - потеря видео пакетов;
o Outage – прекращение вещания потока или отдельного PID;
o MLS – количество секунд с ошибками MDI;
5
o Расчёт накопленных значений за 15 минутный и суточный (24 часа)
интервалы;
o Измерение битовой скорости потока в IP-транспорте, в MPEG-2 TS
транспорте;
o IP статистика (VLAN, TTL, метрики RTP, TOS, DSCP);
o Контроль наличия и битрейта потоков PSI/SI;
o Контроль наличия/отсутствия выбранных PID с аудио/видео информацией;
o Контроль битрейта отдельных PID передаваемых в потоке с оценкой
минимального и максимального и среднего значений;
o Анализ шифрованного трафика на уровне синтаксиса транспортного потока;
o Контроль статуса шифрации (есть/нет) сервиса;
o Параметры транспортного потока в соответствии с TR 101 290;
o Измерение джиттера PCR;
2.2.4 Параметры Loss distance, Loss period в соответствии с рекомендациями ITU-T
G.1080;АС осуществляющие QOS мониторинг ВЧ потоков должны обеспечить:

Анализ не менее 2-х QAM несущих одновременно и независимо;

Характеристики ВЧ-входа:
o Поддержка стандартов ITU-T J.83 Annex A, DVB EN 300 429 “Framing
structure, channel coding and modulation for cable systems”;
o Разъем - тип F, 75 Ом;
o Частотный план ГОСТ 7845-92 (OIRT);
o Уровень несущей на входе 50 … 75 dBmkV;
o Полоса канала 8 МГц;
o Демодуляция QAM 64, QAM 256;

Поддержку стандартов ISO/IEC 13818-1 Generic coding of moving pictures and
associated audio information: Systems” (MPEG2 TS) SPTS/MPTS;

Контроль и измерения параметров транспортного потока с видеоданными
форматов MPEG-2 (ISO/IEC 13818-2, -3), MPEG-4 Part 10 / H.264 (ISO/IEC
14496), SD / HD;

Мониторинг параметров в соответствии с ошибками первого и второго
приоритета рекомендаций ETSI TR 101 290 Measurement guidelines for DVB
systems”;

Анализ PSI\SI таблиц транспортного потока в соответствии с действующими
стандартами и рекомендациями;

Возможность перебора списка каналов для последовательного контроля
(сканирование);

[O] возможность загрузки информации о вещаемых сервисах и потоках из NIT
и названий программ из SDT таблиц;

Измерение и отображение ВЧ-параметров (радио параметров):
o Уровень несущей радиосигнала, Power;
o Отношение несущая/шум, C/N;
6

o MER, Modulation Error Ratio – Отношение Модуляция/Ошибка;
o Битовые ошибки, BER, до и после RS коррекции;
o Индекс модуляции;
o Констелляционная диаграмма;
Измерение следующих параметров транспортной среды (QOS – Quality of
Service, Качество обслуживания):
o Outage – прекращение вещания потока или отдельного PID;
o MLS – количество секунд с ошибками MDI;
o Расчёт накопленных значений за 15 минутный и суточный (24 часа)
интервалы;
o Измерение битовой скорости потока в MPEG-2 TS транспорте;
o Контроль наличия и битрейта потоков PSI/SI;
o Контроль наличия/отсутствия выбранных PID с аудио/видео информацией.
o Контроль битрейта PID передаваемых в потоке с оценкой минимального и
максимального значений;
o Анализ шифрованного трафика на уровне синтаксиса транспортного потока.
o Контроль статуса шифрации (есть/нет) программы;
o Параметры транспортного потока в соответствии с TR 101 290;
o Измерение джиттера PCR;
o Параметры Loss distance, Loss period в соответствии с рекомендациями ITUT G.1080.
АС осуществляющие QOE мониторинг IP-потоков должны обеспечить:
2.2.5

Полную поддержку QOS-мониторинга в соответствии с п 2.2.2;

Контроль синтаксиса элементарных потоков видео и звука, передаваемых в
потоках MPEG-2 TS;

Анализ параметров кодирования;

Декодирование видео-кодеков MPEG-1, MPEG-2, H.264/MPEG-4, H.265/HEVC;

Анализ декодированного изображения и декодированного звука;

Отображение данные измерений в табличном и графическом виде;

Хранение истории аварийных событий с возможностью доступа к архиву с
использованием фильтрации (по дате, типу аварии и пр.);

Создание галереи декодированных изображений (слайд-шоу) для каждого
канала (не менее 1 кадра в 1 сек, срок хранения не менее 2 суток) с
возможностью произвольного доступа к элементам галереи с привязкой к
авариям;

Многоуровневая проверка целостности синтаксиса элементарных потоков
видео и звука;

Отображение параметра “Доступность программы” для каждого сервиса в
соответствии с TR-126 & SCTE168-6 для 15-минутного и 24-х часового
интервалов;
Определение характеристик кодирования видео:

7
o
o
o
o
o
o
o

Стандарт (кодек);
Формат изображения;
Разрешение;
Система цветности;
Структура GOP;
Битрейт;
Частота кадров;
Определение характеристик кодирования звука
o Стандарт (кодек);
o Битрейт;
o Частота дискретизации;

Измерение следующих параметров QOE – Quality of Experience, Качество
восприятия):
o Видео



o Звук
Качество кодирования, Mean Opinion Score (MOS-V), абсолютный,
относительный;
Черный экран (Black Screen);
Заморозка изображения (Still Frame, Freeze);


Качество кодирования, Mean Opinion Score (MOS-A), абсолютный,
относительный;
 Громкость (Loudness, LKFS, стандарт BS.1770);
 Dialnorm (для Dolby Digital);
Анализаторы должны обеспечить анализ DVB-метаданных:
o Карусели данных;
o Метки SCTE-35 (вставка рекламы);
2.3
Требования к центральной серверной системы сбора и агрегации данных
(NMS)
2.3.1 Система должна иметь единое окно, которое визуализирует все аварии,
настроенные администратором;
2.3.2 Система должна поддерживать визуализацию данных в виде динамически
обновляемых панелей (Dashboards) в режиме времени близком к реальному;
2.3.3 Система должна иметь возможность строить отчёты за определённый
задаваемый пользователем период времени;
2.3.4 Система должна иметь возможность графического отображения результатов
мониторинга;
2.3.5 Система должна поддерживать функции фильтрации и поиска аварийных
событий по разным критериям как тип, статус и критичность аварии;
2.3.6 Система должна иметь возможность отображения данных с анализатора, группы
8
анализаторов в режиме реального времени;
2.3.7 Система должна уметь коррелировать и консолидировать аварии с разных АС
для минимализации количества аварий при массовых инцидентах;
2.3.8 Система должна уметь рассылать по электронной почте оповещения о авариях;
2.3.9 Система должна предоставлять возможность группирования АС и пользователей
системы в цель фильтрации информации для определённых групп
пользователей;
2.3.10 Система должна предоставлять функции управления авариями как назначение
ответствующего пользователя на обработку аварии и возможность
редактирования дополнительной информации об аварии;
2.3.11 Система должна иметь единое окно, которое визуализирует состояние всех
сервисов на всех АС в реальном времени;
2.3.12 Должна быть предусмотрена возможность локализации GUI системы с учётом
проектных требований заказчика;
2.4
Требования к системе сбора, обработки и хранения исторических данных (BD)
2.4.1 Хранение данных должно осуществляться не менее 12 месяцев;
2.4.2 Система должна уметь создавать специализированные (customized) отчёты по
любым QoS- и QoE-параметрам;
2.4.3 Система должна уметь автоматизировано создавать отчёты в форматах Excel и
PDF, и рассылать их по электронной почте в соответствие с заданным
расписанием;
3
Требования по внедрению системы
3.1
Внедрение системы должно поэтапно осуществляться:
3.1.1
На первых этапах AC будут устанавливаться на головной станции, на стыках
со сетью МТС и на объектах ядра сети МГТС;
3.1.2
В дальнейшем АС будут устанавливаться на опорных объектах сети МГТС и
на стыках с присоединёнными сетями;
3.2
На всех этапах внедрения системы должна использоваться существующая система
NMS (серверная платформа “Системы мониторинга качества ТВ сервисов сети
МТС”) для обеспечения задач NMS и BD, в т.ч. визуализации аварий, сбора и
хранения исторических данных;
3.3
При необходимости должно быть предусмотрено аппаратное и/или лицензионного
наращивания существующей системы NMS в зависимости от количества и состава
АС, используемых в рамках настоящего ТЗ;
9
4
Конструктивные требования
4.1
Все поставляемое оборудование должно предусматривать размещение в
телекоммуникационных стойках ETSI (19") высотой 42U и глубиной не более 900
мм. без использования дополнительных креплений;
4.2
Поставляемое оборудование должно обеспечивать эксплуатацию в условиях
естественной вентиляции в помещении с температурой окружающего воздуха от 0°С
до 45°С при влажности от 0% до 90% (без образования тумана);
5
Требования по электропитанию
5.1
Электропитание оборудования должно осуществляться от сети постоянного тока
DC, 60В;
5.2
Требований к резервированию блоков питания поставляемого оборудования не
предъявляется.
10
Приложение 1
Схема формирования услуги с точками контроля
Таблица 1. Типы, характеристики и количества точек контроля,
Описание
Уровень
Выход головной станции
QOE, QOS
Стыки с МТС
QOS
Объекты ядра сети МГТС.
QOS
Стыки с присоединёнными сетями QOS
NGN МТС, АМТ, МОФ, Таском.
Опорные объектах сети МГТС
QOS
Объекты DVB-C сети
QOS,
ВЧ/QAM
Кол- Интерфейс Полоса Сервисов
во
1
10G
3G и
750
более
3
10G
10G
750
11
10
10G
1G
56
1G
2
ВЧ
10G
100
Mbit
100
Mbit
100
Mbit
500
10,
перебор
10,
перебор
20,
перебор
11