Mlr ошибки что это
Полезное
Смотреть что такое «MLR» в других словарях:
MLR — abbreviation for minimum lending rate * * * MLR UK US noun [U] ► BANKING ABBREVIATION FOR MINIMUM LENDING RATE(Cf. ↑minimum lending rate): »The interest rate will be the bank s MLR minus 3% … Financial and business terms
MLR — may refer to:* Main Line of Resistance * Metro Light Rail light rail in Sydney. * Minimum Lending Rate * Money Laundering Regulations * Modern Law Review * Modern Language Review * Milnrow railway station, England; National Rail station code MLR … Wikipedia
MLR — steht für: Mihin Lanka, sri lankische Fluggesellschaft (ICAO Code) Ministerium für Ernährung und Ländlichen Raum Baden Württemberg Monodisperse Latex Reactor, wissenschaftliches Experiment der Space Shuttle Mission STS 6 Multichannel linear… … Deutsch Wikipedia
MLR — [Abk. für Multichannel linear Recording, dt. »lineare Mehrkanalaufzeichnung«], Aufzeichnungsverfahren für Magnetbänder, das von der Fa. Tandberg auf der Basis von QIC entwickelt wurde. Die Laufwerke verfügen über vier Schreibköpfe sowie über… … Universal-Lexikon
MLR — abbr. minimum lending rate. * * * abbreviation 1. main line of resistance 2. muzzle loading rifle * * * minimum lending rate. * * * abbrev Minimum lending rate * * * MLR (no periods), minimum lending rate (the lowest rate of interest charged by… … Useful english dictionary
MLR — minimum lending rate. * * * … Universalium
MLR — Mixed Lymphocyte Reaction (Academic & Science) Monthly Labor Review (Governmental » US Government) Monthly Labor Review (Community » Media) * Media Literacy Review (Community » Media) * Minimum Lending Rate (Business » Accounting) * Move and Lose … Abbreviations dictionary
MLR — mean length response; middle latency response; mineralocorticoid receptor; mixed lymphocyte reaction; multi linear regression; multivariate linear regression * * * (MLC) mixed lymphocyte reaction (or culture): a test in which lymphocytes from… … Medical dictionary
MLR — Main Line of Resistance ( > IEEE Standard Dictionary ) … Acronyms
MLR — Miet und Lastenbeihilferichtlinien EN guidelines for grants for rents and public charges … Abkürzungen und Akronyme in der deutschsprachigen Presse Gebrauchtwagen
MLR — Mixed lymphocyte reaction (Reacci ón mixta linfocitaria) … Diccionario de siglas médicas y otras abreviaturas
Машинное обучение на языке R с использованием пакета mlr3
В этом сообщении мы рассмотрим самый продуманный на сегодняшний день подход к машинному обучению на языке R — пакет mlr3 и экосистему вокруг него. Данный подход основан на «нормальном» ООП с использованием R6-классов и на представлении всех операций с данными и моделями в виде графа вычислений. Это позволяет создавать упорядоченные и гибкие пайплайны для задач машинного обучения, но на первых порах может показаться сложным и запутанным. Ниже постараемся внести определенную ясность и замотивировать к использованию mlr3 в ваших проектах.
Содержание:
1. Немного истории и сравнение с конкурирующими решениями
caret — старый, но не бесполезный
Пакет caret является первой реализацией инфраструктуры для построения моделей машинного обучения на R и одной из первых библиотек такого рода в целом (релиз на CRAN состоялся в 2007 году). В 2013 году по уже классическому на тот момент пакету была издана не менее классическая книга Applied Predictive Modeling, которую в комплекте с официальной документацией и сейчас можно рекомендовать в качестве вводного практического руководства по машинному обучению.
tidyverse strikes back
Своебразной работой над ошибками стало создание семейства пакетов под общей вывеской tidymodels, основными из которых являются recipes (отвечает за создание «рецептов» предварительной обработки данных, исполняемых внутри ресемплов с обучением на обучающей выборке и применением на обучающей и валидационной), rsample (обеспечивает различные варианты разбивки данных) и относительно новый tune (реализует собственно тюнинг гиперпараметров).
mlr3 vs все остальные
Пакет mlr3 и экосистема вокруг него также представляют собой попытку исправить недостатки как более раннего пакета mlr тех же авторов, так и рассмотренных выше caret и tidymodels. mlr подробно рассматривать не будем ввиду того, что его развитие было остановлено в пользу mlr3.
2. Технические детали: R6-классы и пакет data.table
В основе экосистемы mlr3 лежат «нормальное» ООП, реализуемое путем использования R6-классов. R6-объекты являются изменяемыми, что позволяет работать с ними без копирования и перезаписи. Подробно изучить тему можно по официальной документации и книге Advanced R, мы же ограничимся кратким примером, позаиствованным из упомянутой книги.
Новый R6-класс создается вызовом функции R6Class() :
Функции, заданные внутри списка при определении класса, доступны как методы у экземпляров данного класса:
R6-объекты передаются по ссылке:
Поэтому для создания копий нужно вызывать метод clone() (указав clone(deep = TRUE) для рекурсивного копирования вложенных объектов):
Это все, что нужно знать об R6 в контексте использования пакетов семейства mlr3.
3. Основные составляющие ML-пайплайна в mlr3
Минимальный пример решения задачи машинного обучения при помощи mlr3 выглядит следующим образом:
В процессе участвуют две сущности: задача (task) и модель (learner).
Обученную модель используем для предсказания на новых данных при помощи метода predict_newdata() :
Добавим кросс-валидацию с разбивкой на 5 фолдов:
4. Настройка гиперпараметров
Осталось самое главное — произвести настройку гиперпараметров модели. Тут все немного сложнее, и вызовом одного метода дело не ограничится.
Прежде всего зададим пространство для перебора значений гиперпараметров. Этим функционалом заведует отдельный пакет paradox:
Функция generate_design_grid() позволяет получить таблицу значений гиперпараметров, по которой будет проводиться перебор:
Также реализованы другие способы генерации сетки значений: generate_design_random() для случайной выборки из диапазона и generate_design_lhs() для создания дизайна эксперимента методом латинского гиперкуба.
Объединим все ингредиенты в один объект класса TuningInstance :
Заслуживает внимания тюнер tnr(«design_points») : он позволяет передать созданную заранее таблицу со значениями гиперпараметров, что зачастую удобнее генерации из диапазонов (особенно если нужно перебрать значений на логарифмической шкале — без готовой таблицы придется использовать достаточно громоздкий механизм преобразования параметров, который в mlr3 тоже есть).
Наконец, запустим процесс:
Как видим, result не содержит ничего. Это потому, что вызов tuner$tune() приводит к изменению объекта tuning_instance :
Рассмотрим подробнее, что именно происходит после вызова метода tune() :
Например, можем добавить к таблице значения метрики качества на каждом ресемпле:
5. Обзор экосистемы mlr3
С основными пакетами мы уже знакомы: это mlr3, mlr3tuning и paradox. Вся экосистема представлена на заглавной картинке и в списке, а основные пакеты можно поставить при помощи мета-пакета mlr3verse:
40 метриками качества. В состав mlr3verse не входит, нужно ставить руками.
Следите за страницами по представленным ссылкам, список пакетов будет пополняться.
6. Пайпы и граф вычислений
Про пайпы (pipelines) можно было бы написать много, но много уже написали разработчики, поэтому постараемся максимально кратко изложить наиболее принципиальные для практического использования моменты.
Пайпы последовательно соединяются в граф при помощи оператора %>>% :
У пайпов есть входы и выходы. Для графов с более сложной структурой придется явно указывать, какой выход к какому входу последующего пайпа подключать:
Как сделать пайп из модели, мы уже видели ( po(«learner», learner = lrn(«classif.rpart»)) ). В свою очередь, граф целиком можно сделать моделью:
Третьего дня была реализована невиданная ранее фича, которая обсуждалась в issue How to deal with different preprocessing steps as hyperparameters:
Рассмотренные в первом разделе caret и tidymodels так не умеют!
Надеюсь, данный пост был полезен и зародил интерес к дальнейшему изучению и использованию фреймворка mlr3. Подробнее можно почитать в книге mlr3 book и в галерее примеров.
Важнейшие параметры QoS для определения ошибок вещания
Сохранение лояльности абонентской базы — главный вызов, с которым сегодня сталкиваются операторы. Стабильно высокое качество вещания — один из ключевых факторов успеха. Чтобы поддерживать качество на высоком уровне и находить ошибки в потоке, операторы используют системы мониторинга.
Все отслеживаемые параметры делятся на два типа: одни относятся к качеству обслуживания (Quality of Service — QoS), другие — к качеству восприятия (Quality of Experience — QoE). В этой статье поговорим об основных параметрах QoS.
Отсутствие сигнала — самый критичный параметр, который относится к «красному» состоянию доставки. Такое событие возникает, когда система мониторинга по какой-либо причине не может получить данные для анализа. Чтобы решить эту проблему, необходимо выяснить её причину и быстро определить место её возникновения: сторона контент-провайдера, оборудование или сеть. Для этого потребуется несколько анализаторов или распределенная система мониторинга с несколькими клиентами (зондами).
Уведомления об отсутствии сигнала в системе мониторинга
Для IP вещания в первую очередь необходимо отслеживать два параметра: потеря пакетов и джиттер.
Если пакеты не теряются и гладко проходят всю цепочку доставки, то качество сигнала можно считать высоким. Если возникает потеря пакетов или джиттер превышает пороговые значения, проблемы с доставкой становятся очевидными для пользователей. Поэтому эти два параметра являются важнейшими для обеспечения высокого качества обслуживания. Потерю пакетов можно оценить, проверив счетчик непрерывности (Continuity Counter), встроенный в заголовок TS.
Ошибки Continuity Counter (CC) возникают, если обнаружен некорректный порядок пакетов, если один пакет повторяется более двух раз, или если пакет потерян.
CC ошибки и их влияние на поток
Media Loss Rate (MLR) — метрика, позволяющая детально оценить потери пакетов. Показывает количество потерянных транспортных пакетов в секунду.
Inter-packet Arrival Time (IAT) — значение времени между приходящими пакетами, зафиксированное за одну секунду измерений. Максимальное значение IAT является мерой джиттера. Джиттер определяется как сравнение временных интервалов между приходящими пакетами.
IAT:MLR график в системе мониторинга
Коэффициент задержки (Delay Factor) — еще один из наиболее значимых параметров мониторинга. Это временное значение, показывающее сколько миллисекунд данных должны содержать буферы, чтобы устранить временные искажения (джиттер). Как индикатор качества при мониторинге сети доставки вещания видеосервисов, чувствительной к джиттеру и потере данных, может быть использован индекс MDI (Media Delivery Index — DF:MLR).
Индекс MDI в системе мониторинга
Чтобы обеспечить полный мониторинг качества обслуживания, помимо основных метрик, перечисленных выше, необходимо контролировать и другие параметры.
Несколько источников вещания. Когда несколько источников мультикаст вещания начинают передавать данные в одной группе, могут возникать различные ошибки.
TR 101 290 — стандарт, описывающий порядок измерений для спутниковых, кабельных, эфирных цифровых телевизионных систем. Стандарт содержит пороговые значения для событий, однако для IPTV-потоков строгое соответствие требованиям стандарта не требуется. Анализ TR 101 290 применяется как для IPTV, так и для нешифрованных OTT-сервисов (или для тех, которые могут быть дешифрованы), основанных на технологии фрагментированного транспортного потока. При ошибках TR 101 290 возникают такие дефекты изображения как пикселизация, шумы, замирания аудио и видео, черный экран и другие.
IPTV в России
Мониторинг IPTV или MDI и с чем его едят…
« previous entry | next entry »
май. 7, 2007 | 05:28 pm
Запись опубликована IPTV в России.Пожалуйста, оставляйте коментарии там.
В связи с тем, что тема мониторинга достаточно актуальна, но практически не раскрыта на блоге, я решил написать немного на эту тему… Начать же хочу с описания самой распространенной на данный момент методики — RFC 4445.
Видеосигнал, в процессе его прохождения по пути HeadEnd — STB претерпевает различные изменения, и изменения эти не в лучшую сторону. Для качественного мониторинга и своевременного устранения проблемы возникла задача определить некие параметры качества и контролировать их на всем протяжении транспортной сети.
В связи с этим был утвержден индекс MDI (Media Delivery Index) определенный в методике RFC 4445. Он основан на принципе формирования интегральной оценки качества по совокупности двух самых важных параметров качества на всех участках транспорта IPTV инфраструктуры — джиттера и количества потерянных пакетов. И логика метода MDI заключается в том, что если с транспортом пакетов проблем не будет, то не будет проблем и с контентом. Эти параметры определены как уровень задержки Delay Factor (DF) и уровень потерянных пакетов Media Loss Rate (MLR).
MDI вычисляется за произвольный промежуток времени, обычно это 1 секунда
И если с измерениями уровня MLR, выполняющимися методами пассивного мониторинга все предельно понятно, то с DF дело обстоит сложнее. Джиттером в MDI является задержка между ожидаемым и реальным временем приема пакета (см. рисунок).
где IAT — среднее время доставки соседних IP-фреймов.
По сути DF определяет критический размер буфера на стороне приемника, и в отличие от MLR измерение параметра задержки DF не может быть реализовано методами пассивного мониторинга.
MDI — это простой алгоритм мониторинга уровня транспорта для квалификации качества уровня услуг. За счет применения MDI можно осуществить мониторинг параметров качества на всех основных узлах транспорта начиная HeadEnd и заканчивая STB, выявить участок, где происходит ухудшение качества, и определить в какой степени это критично для услуги IPTV.
Мониторинг современных систем цифрового телевидения
Предоставление полноценной услуги triple-play стало практически нормой для операторов широкополосного доступа. Традиционные широковещательные сети цифрового кабельного телевидения позволяют организовать передачу данных и телефонии с использованием технологии DOCSIS. Однако, вследствие ограниченности частотного ресурса, возникает проблема обеспечения высокой скорости обмена при наращивании абонентской базы. Дальнейшая модернизация таких сетей, в частности переход на новый стандарт DOCSIS 3.0, требует существенных материальных вложений.
В то же время, технология Ethernet давно перестала использоваться только в локальных сетях передачи данных. Вследствие существенного увеличения производительности активного оборудования и снижения его стоимости, на стандарте Ethernet активно строятся современные сети широкополосного доступа. Применение волоконно-оптических технологий на магистральном и распределительном участках позволило существенно увеличить широкополосность таких сетей. Скорости передачи, предоставляемые провайдерами для конечных абонентов, вполне позволяют передавать такой ресурсоемкий трафик, как телевизионные потоки IPTV (Internet Protocol Television) стандартного и высокого качества. Предоставление услуги IPTV позволяет небольшим интернет-провайдерам конкурировать с традиционными кабельными операторами, предоставляя пользователю те же пакеты телепрограмм, но еще и с дополнительным перечнем услуг, недоступных клиентам операторов кабельного ТВ.
Телевизионные услуги нового поколения не только позволяют пользователям оптимизировать затраты на получаемый контент, но и получить доступ к новым возможным видео-услугам («видео по заказу», «заказ программы со сдвигом», «сетевой видеомагнитофон» и т.д.).
Построение сети IPTV
Для реализации технологии IPTV необходимо построение сети (Рис. 1), состоящей из головной станции IPTV, собственно сети передачи данных, и абонентских терминалов. Также для предоставления услуг традиционного телевидения на сети могут быть размещены специальные IP/DVB-шлюзы (Arris Edge-QAM D5, Appear TV и пр.), которые преобразуют потоки IPTV в сигнал одного из стандартов цифрового телевидения (DVB).
Рис. 1 Структура сети IPTV
Однако не любая сеть Ethernet пригодна для предоставления возможных услуг IPTV. При внедрении видео-услуг сеть также должна соответствовать следующим требованиям:
поддержка всеми узлами сети протокола групповой передачи IGMP (Internet Group Management Protocol) версии не ниже 2.
поддержка функции IGMP query (запрос о составе группы) на маршрутизаторе или коммутаторе, на который приходят мультикастовые потоки со всех источников.
если предполагается маршрутизация мультикастовых потоков, то необходима также поддержка протокола PIM (Protocol Independent Multicast).
Тем не менее, даже в современных широкополосных сетях Ethernet могут возникать сложности с обеспечением качественного телевизионного сигнала, связанные со спецификой работы пакетной сети передачи данных. Неверный расчет сети, неправильная настройка сетевого оборудования, временные задержки пакетов, зашумленность медных линий и другие проблемы приводят к видимому ухудшению «картинки», зависаниям, «рассыпанию» кадров и т.д.
Система IPTV, как и любая другая система передачи данных, работает правильно только тогда, когда:
Поэтому оператору IPTV принципиально важно объективно и своевременно определить причину ухудшения параметров видео-сигнала, посмотреть изменение параметров качества во времени. Как показывает практика эксплуатации сетей IPTV, поиск решения некоторых проблем, может занять много времени, а порой и вовсе невозможен без использования специализированных средств диагностики.
Организация мониторинга в сетях IPTV
Рассмотрим обобщенную схему прохождения сигнала от источника к потребителю и этапы контроля показателей качества (Рис. 2). На первом этапе «идеальный» несжатый сигнал (270 Мбит/с для стандартного качества) поступает на устройство кодирования для преобразования его в формат, удобный для передачи по сети. Естественно, что при уменьшении скорости потока, например, в 100 раз, происходит необратимое ухудшение качества видеосигнала. Дальше этот кодированный канал поступает в сеть передачи данных, из которой попадает к конечному абоненту, где декодируется при помощи абонентского терминала – сет-топ бокса (STB).
Рис. 2 Схема контроля качества работы сети IPTV
На качество изображения могут повлиять только работа кодера на передающей стороне (здесь все зависит от степени сжатия и качества применяемых кодеков) и сет-топ бокса. Эти элементы проверяются единожды на начальном этапе перед установкой их в сеть. Для корректного восстановления сигнала на приемной стороне, необходимо, чтобы все UDP пакеты (User Datagram Protocol), формируемые источником, поступили к получателю вовремя и в правильной последовательности. Поэтому сеть должна быть объектом постоянного наблюдения.
Контроль параметров джиттера в сетях IPTV
Все пакеты UDP приходят к получателю один за другим через некоторый интервал времени, Inter-arrival time (IAT, интервал времени между прибытиями пакетов). Этот промежуток времени в идеальном случае должен быть постоянным. Но в реальности он постоянно изменяется как в положительную, так и в отрицательную сторону (Рис. 3), и может достигать недопустимых значений.
Рис. 3 Джиттер пакетов UDP
Изменение интервала времени прибытия пакетов относительно среднего значения называется джиттером. Согласно стандарту ETSI TS 102 034, расхождение между максимальными отклонениями в положительную и отрицательную сторону не должно превышать 40 мс. В противном случае, возможно переполнение или опустошение буфера абонентского сет-топ бокса, что может привести к видимым дефектам изображения.
Причины возникновения повышенного джиттера могут быть различными, но к основным можно отнести:
Рассмотрим отображение джиттера измерительным оборудованием на примере интерфейса анализатора потоков BridgeTech VB120 через сервер мониторинга сети VideoBridge Controller (Рис. 4). Наиболее наглядным способом отображения джиттера является гистограмма, отражающая количество пакетов. Нормальной картиной для джиттера является гистограмма в виде нормального Гауссового распределения с дисперсией, не превышающей 20 мс, т.е. половины максимального джиттера. Как видно из иллюстрации для первого потока, максимальный джиттер составляет меньше 2 миллисекунд, что является пренебрежимо малым по сравнению с пороговым значением.
Рис. 4 Отображение джиттера анализатором потока BridgeTech VB120
На рис. 5 проиллюстрирована другая ситуация для той же сети. Разница заключается в том, что первая диаграмма построена для потока с постоянной скоростью (битрейтом), а вторая – с переменным. Изменение скорости потока на выходе кодера влечет за собой существенное изменение интервала отправки пакетов UDP и частое превышение порога в 20 мс. Такой график не может отражать реальное положение вещей. Так как далеко не всегда у провайдера есть возможность выравнивать скорости потоков, которые в основном вещаются с переменным битрейтом, то для целей контроля вносимого сетью разброса используется генератор эталонных потоков BridgeTech VB230 с постоянной скоростью, который устанавливается на головной станции, а значения джиттера снимаются в точках контроля при помощи анализаторов серий VB12, VB120, VB20 или VB220.
Рис. 5 Отображение джиттера в сети с переменным битрейтом
Определение параметров ошибок в сетях IPTV
Поскольку одной из задач системы мониторинга является контроль доставки пакетов конечному абоненту, то вторым важным параметром является интенсивность потерь пакетов или MLR (Media Loss Rate). Поскольку при формировании передающим оборудованием посылки UDP в нее, как правило, инкапсулируется до семи 188-байтовых транспортного пакета TS (Transport Stream), то потеря хотя бы одной UDP посылки приведет к появлению видимых дефектов изображения. Стандартом ETSI TS 102 034 допускается интенсивность потерь пакетов не более одного в час.
Наиболее распространенными причинами появления MLR являются:
Важным параметром качества, производным от IAT является коэффициент распространения в среде передачи MDI-DF (Media-delivery index ― delivery factor). Он вычисляется как максимальное значение IAT за период измерения 1 с.
Если в течение секундного интервала измерения произошел выброс IAT за пределы порогового значения или же произошла потеря пакета (MLR), то такая секунда считается ошибочной (Errored Second, ES).
Поскольку параметры сети могут быть подвержены колебаниям с течением времени, для оператора важно оценить распределение параметров качества IPTV во времени. Примером такого удачного решения может быть технология быстрого отображения состояния потока BridgeTech MediaWindow (Рис. 6), реализованная во всем оборудовании линейки VB IP-PROBE и microVB. Суть данной технологии заключается в том, что горизонтальная ось является осью времени, а вертикальная − двунаправленная: по положительному направлению откладываются значения DF, или размер занимаемой полосы, по отрицательному − MLR. При превышении определенных порогов столбцы окрашиваются в соответствующий цвет − желтый или красный, с учетом степени превышения порога.
Рис. 6 Интерфейс отображения состояния потока во времени (BridgeTech MediaWindow)
Отображение информации в системе мониторинга BridgeTech
Очень важным является способ отображения статистической информации о потоках. Она должна быть наглядной, легко читаемой, такой, чтоб по ней с первого взгляда можно было оценить качество передачи потока, периодичность и величину ошибок. Удобно, когда информация выдается в графическом виде сразу для нескольких каналов (Рис. 7), что уменьшает необходимость многочисленных переключений в пользовательском интерфейсе.
При помощи технологии BridgeTech MediaWindow можно оценивать входной джиттер даже для потоков с переменным битрейтом путем сравнивания их значения DF сразу после источника и в точке контроля на сети.
Рис.7 Распределение параметров джиттера во времени для различных потоков
Оборудование мониторинга для различных участков сети
Идеология построения эффективной системы мониторинга подразумевает размещение оборудования контроля в следующих точках на сети.
1. Головная станция
Здесь (Рис. 8) основными задачами системы являются:
Рис. 8 Сбор информации с головной станции системой мониторинга VideoBridge
2. Опорная сеть и сеть доступа
Основной целью размещения анализаторов здесь является контроль джиттера и потерь вносимого сетевым оборудованием в ядре сети, а также коммутаторами и маршрутизаторами уровня доступа. Как уже упоминалось, из-за помех в линиях связи на некоторых участках, в маршрутизаторах могут образовываться очереди пакетов, что может приводить к их задержке и потере. Также следует отметить, что оборудование, которое размещается в ядре сети, должно уметь работать с трафиком в разных виртуальных локальных сетях (VLAN), а также производить одновременный мониторинг большого количества потоков IPTV. Примером такого устройства может быть анализатор BridgeTech VB220, который способен анализировать до 260 потоков одновременно.
На другой стороне опорной сети (Рис. 9) может использоваться анализатор BridgeTech VB20, позволяющий контролировать качество потоков на коммутаторе доступа или DSLAM (мультиплексоре доступа цифровой абонентской линии xDSL).
Рис. 9 Сбор информации системой VideoBridge на опорной сети и сети доступа
3. Абонентское оборудование
Оборудование мониторинга, установленное в помещении пользователя, прежде всего, преследует цель решения проблем, возникающих или из-за неправильных действий самих абонентов или проблем, связанных с «последней милей». Таким образом, достигается экономия средств за счет уменьшения выездов специалистов на место установки абонентского оборудования. Установка устройств мониторинга такого типа не должна требовать высокой квалификации установщика, также должна быть предусмотрена возможность устанавливать его силами самого абонента. Примером такого решения является BridgeTech microVB ― анализатор, устанавливаемый на стороне абонента, в разрыв абонентской линии (Рис. 9), который при включении самостоятельно регистрируется в системе мониторинга сети.
Организация мониторинга в цифровых широковещательных сетях
Система мониторинга BridgeTech принципиально пригодна не только для использования на сетях IPTV. Возможно использование сети IP как транспортной сети для построения региональных и местных сетей цифрового кабельного телевидения (эфирного, кабельного). В отдельных сегментах таких сетей важно контролировать параметры сигналов, передаваемых в форматах DVB-C, DVB-T, DVB-S (Рис. 10).
Здесь необходимо осуществлять контроль параметров самого радиосигнала на выходе мультиплексора и модулятора (SNR, BER, MER, уровень сигнала), а также проверять содержание служебной информации, передаваемой в потоке, на соответствие стандарту ETSI ETR 101 290. Эти возможности реализованы в линейке приборов VB120/220 с применением дополнительных интерфейсных модулей для работы в широковещательных сетях стандартов DVB-S/S2 (VB270), DVB-T (VB250), DVB-C (VB260, VB262).
Рис. 10 Контроль качества сигнала в сетях DVB-C/T/S
Формирование отчета о результатах мониторинга
Для предоставления информации о работе сети и о качестве предоставляемых услуг за конкретный период времени должна быть предусмотрена возможность формирования информативных отчетов. На рис. 11 показан пример страницы отчета, сформированного на сервере мониторинга VideoBridge Controller. Здесь отображена общая информация о сформированном отчете, показаны диаграммы, отражающие процент каналов, на которых появлялись ошибки («no signal», MLR и DF). График изменения во времени параметров IAT, MLR и «no signal» (с указанием количества ошибочных секунд). Также приведены пороговые значения ключевых параметров, установленные в соответствии с SLA (Service Level Agreement).
Рис. 11 Образец страницы отчета, сформированной VideoBridge Controller
Таким образом, построение эффективной системы мониторинга является комплексной задачей, каждый из факторов которой в той или иной мере влияет на ее эффективность, а, следовательно, и на качество предоставляемых услуг. Система мониторинга должна быть гибкой и масштабируемой, имеющей возможность адаптации под любые требования провайдера. Таким свойством обладают решения на базе оборудования компании BridgeTech, официальным представителем которой на территории Украины является компания DEPS.
Отдел системной интеграции
