Что такое tr 101 290
Программная опция для анализа параметров ETR 101 290 BridgeTech TR 101 290
Программная опция для анализа параметров ETR 101 290
Добавить в корзину В корзину
Стандарт ETSI TR 101 290 описывает порядок измерения параметров сигнала при цифровом вещании. Классификация методов измерений выполнена по степени серьезности последствий, к которым приводят те или иные ошибки и сбои в работе оборудования (ошибки приоритета 1, 2 и 3).
Bridgetech добавила новые эффективные критерии оценки в технический отчет TR 290. В вышеназванном документе детально описаны измерения, проводимые в соответствии со стандартом ETR 290 оборудованием Bridgetech. При этом проведена четкая грань между критериями ETSI и нововведениями, предложенными Bridgetech. По умолчанию дополнительные функции, предлагаемые Bridgetech, отключены и не могут приводить к формированию ошибок.
Оценка параметров сигнала может производиться по таблицам Комитета по перспективным телевизионным системам (ATSC); при этом в качестве шаблона предельных значений ETR 290 для соответствующего канала устанавливается ATSC, а не DVB (Вещание цифрового видео). В принципе, таблицы ATSC соответствуют таблицам DVB приоритета 3; таким образом, критерии ATCS входят в группу приоритета 3 проба, даже если это не предусмотрено ETSI TR 101 290.
Оборудование Bridgetech, выполняющее оценку по стандарту ETR 290, в графическом пользовательском интерфейсе веб-браузера выводит на экран вкладку ETR 290 ETR
Критерии ETR 290
Приоритет 2
Приоритет 3
Программная опция для анализа параметров ETR 101 290 BridgeTech TR 101 290
Стандарт ETSI TR 101 290 описывает порядок измерения параметров сигнала при цифровом вещании. Классификация методов измерений выполнена по степени серьезности последствий, к которым приводят те или иные ошибки и сбои в работе оборудования (ошибки приоритета 1, 2 и 3).
Bridgetech добавила новые эффективные критерии оценки в технический отчет TR 290. В вышеназванном документе детально описаны измерения, проводимые в соответствии со стандартом ETR 290 оборудованием Bridgetech. При этом проведена четкая грань между критериями ETSI и нововведениями, предложенными Bridgetech. По умолчанию дополнительные функции, предлагаемые Bridgetech, отключены и не могут приводить к формированию ошибок.
Оценка параметров сигнала может производиться по таблицам Комитета по перспективным телевизионным системам (ATSC); при этом в качестве шаблона предельных значений ETR 290 для соответствующего канала устанавливается ATSC, а не DVB (Вещание цифрового видео). В принципе, таблицы ATSC соответствуют таблицам DVB приоритета 3; таким образом, критерии ATCS входят в группу приоритета 3 проба, даже если это не предусмотрено ETSI TR 101 290.
Оборудование Bridgetech, выполняющее оценку по стандарту ETR 290, в графическом пользовательском интерфейсе веб-браузера выводит на экран вкладку ETR 290 ETR
Критерии ETR 290
Приоритет 2
Приоритет 3
Что такое tr 101 290
Введение
Тестирование доставки «традиционных» вещательных услуг по каналам DVB-T эволюционировало от простейшего тестирования на соответствие требованиям TR 101 290 до продвинутых форм тестирования, включающих оценку скорости каждого элементарного потока, определение типов потоков, контроля присутствия услуг и факультативно EPG, проводимых на уровне транспортного потока. Но для DVB-H одного тестирования транспортного потока недостаточно.
В этом материале рассмотрен набор требований к оценке качества услуг, передаваемых по данной технологии. Она предусматривает предварительную инкапсуляцию информации в IP пакеты и требует наличия ESG (Electronic Service Guide) на обязательной основе, так как без него приемное устройство просто не в состоянии обнаружить и обработать услугу. В этом материале также рассмотрены техники многоуровневого и межуровневого тестирования и их применение для контроля за качеством, доставкой и корректным декодированием услуг.
Мониторинг DVB-T
Ограничения стандарта TR 101 290
Сегодня существует множество решений для тестирования традиционных каналов вещания на базе транспортных потоков MPEG-2. Более простые осуществляют тестирование ошибок 1-го, 2-го и 3-го приоритета в соответствии со стандартом TR 101 290. Они проверяют базовую структуру транспортного потока, в частности, синтаксическую корректность таблиц PAT и PMT и реальное присутствие всех заявленных PID-ов. Тем не менее, известно, что это тестирование часто не помогает выявить причин сбоев, например таких, как неправильная информация о передаваемых услугах или отклонения скоростей элементарных потоков от заявленных.
Тестирование с помощью фиксированных образцовых потоков
В более сложных системах к мониторингу по TR 101 290 добавляется тестирование образцовых потоков, допускающее оценку некоторых дополнительных характеристик транспортного потока. В частности, правильность передачи названий услуг, корректное отражение типов PID-ов и замеры минимальной и максимальной скорости для каждого элементарного потока.
Традиционные транспортные потоки DVB-T включают относительно небольшое количество услуг, каждая из которых передается непрерывно на протяжении продолжительного отрезка времени. В таблице EIT передается информация о времени передачи конкретных программ в рамках этого непрерывного потока, но сама структура транспортного потока в целом не дает возможности контролировать передачу каждой конкретной услуги. Обычно считается достаточным убедиться в том, что услуги передаются непрерывно и каждый составляющий элементарный поток имеет адекватную скорость.
Автоматическое формирование образцовых тестовых потоков
Структура образцовых потоков, соответственно, более или менее постоянна на протяжении часов и даже дней. Кроме того, она известна оператору, планирующему загрузку транспортного ресурса услугами на основе долгосрочных договоров с сервис-провайдерами. Но даже в этих условиях создание образцов оказывается сложной задачей, особенно с учетом все возрастающей сложности структур современных рабочих потоков. Наиболее продвинутые варианты генераторов образцовых потоков поддерживают такие возможности, как автоматическое формирование элементов с заданными свойствами и адаптивные системы редактирования.
Тестирование образцовых потоков по расписанию
Следующее требование — возможность автоматизированного и/или удаленного обновления образца. Это позволяет осуществить непрерывное автоматическое тестирование сети, в которой в разное время суток передаются разные услуги.
Типичный сценарий может потребовать множество разных образцов, например, для дневного, вечернего и ночного показа на буднях и в выходные. Автоматическое обновление потока по заданному расписанию обеспечивает активизацию нужного образца в нужный момент времени.
Обзор систем контроля за контентом DVB-H
При тестировании услуг DVB-H во внимание должны быть приняты еще несколько факторов, в первую очередь то, что услуги DVB-H передаются в IP пакетах, инкапсулированных в транспортные потоки MPEG-2.
Радиочастотная и импульсная структура
Во-первых, услуги DVB-H передаются не постоянно во времени, а импульсами до 2 Мбит/с, занимающими определенные временные слоты. Начало импульса индицируется сигнализацией, вводимой как на уровне РЧ сигнала, так и на уровне транспортного потока. Структура импульсной передачи жестко не регламентирована, поэтому в потоке должна присутствовать информация о конкретной схеме ее реализации. При тестировании потока следует контролировать соответствие реальных параметров импульсной передачи с заявленными в сигнализации потока.
Расширенные служебные таблицы и дескриптеры платформенных связей
Во-вторых, наряду с таблицами PAT и PMT, которые по-прежнему необходимы, DVB-H регламентирует также применение дополнительной таблицы INT (IP-MAC Notification Table) и ряд новых дескрипторов, описывающих услуги DVB-H. Сам видео- и аудиоконтент также передается в IP потоках, один элементарный поток (PID) может включать больше одной услуги DVB-H. В этом случае простая констатация присутствия элементарного потока или измерение его скорости никак не гарантирует передачи конкретной услуги.
Электронный сервисный гид (ESG)
В-третьих, DVB-H регламентирует обязательное применение Электронного сервисного гида ESG. Отметим, что сегодня на практике используются два вида гидов, немного различающихся между собой. Один предложен DVB, а другой — OMA (Open Mobile Alliance). Но с точки зрения вопросов, рассматриваемых в этой статье, различия между ними несущественны. ESG для передаваемых услуг может генерировать и оператор сети, но предполагается, что в большинстве случаев гиды для услуг будут индивидуально формироваться сервис-провайдерами. ESG значительно более сложная и информационно-насыщенная структура, чем EIT. Она передается с помощью FLUTE карусели с использованием IP пакетов, инкапсулируемых в определенные PID-ы. Из теории и практики хорошо известно, что ошибки в ESG часто приводят к невозможности выбрать, декодировать или оплатить контент. В сетях DVB-T относительно простая таблица EIT не является столь необходимой, потому что для поиска и декодирования видео и аудио PID-ов нужны только PAT и PMT.
Это ключевое различие связано с тем, что в DVB-T каждому PIDу соответствует только один видео- или аудиопоток. Параметры кодирования в MPEG-2 также хорошо известны и заранее предопределены. Поэтому для начала декодирования ресиверам нужно всего лишь получить таблицы с PID-ами. А услуги DVB-H передаются в IP пакетах. Причем, в потоках с одним PID-ом могут передаваться IP пакеты с несколькими разными адресами, и, более того, в одном IP пакете может передаваться несколько аудио- и видеопотоков. К тому же, DVB-H предусматривает несколько разных вариантов кодирования, и декодер для начала работы должен получить информацию о конкретном варианте.
Поэтому в составе ESG для каждой услуги должен передаваться специальный файл, называемый SDP (Session Description Protocol). Формат SDP полностью документирован в [3], а если кратко, то он должен содержать IP адрес услуги, который с помощью INT ставится в соответствие конкретному PIDу, а также номера портов элементарных видео- и аудиопотоков, передаваемых в IP пакете. SDP может также содержать информацию о способе кодирования потоков. Без соответствующего SDP декодер не сможет найти нужные потоки, ни декодировать их.
Многопрограммные услуги
Дополнительное осложнение создает тот факт, что каждая услуга DVB-H, видео и аудио- составляющие которой могут быть найдены с помощью вышеизложенного механизма, на самом деле могут оказаться набором отдельных коротких программ.
ESG поддерживает и такую возможность. Эти программы будут иметь общие транспортные идентификаторы, но различные параметры кодирования (компрессии) и закрытия, и каждой из них будет поставлен в соответствие свой SDP файл.
Непрерывная, с точки зрения пользователя, услуга может на самом деле состоять из множества отдельных «событий» — спортивных новостей и финансовых репортажей, прогнозов погоды и т.д. Преимущество заключается в том, что абонент может купить каждую из этих программ отдельно. Но ESG при этом может резко разрастись и усложниться, что, в свою очередь, увеличит вероятность сбоев услуги и последующих затрат на ликвидацию этих сбоев.
Каскадирование независимых платформ
В конечном счете, один транспортный поток может содержать множество услуг от разных провайдеров («платформ»), которые, для получения максимальной коммерческой отдачи от выделенной им полосы, могут динамически изменять структуру своих программ. Новые сетевые топологии также предусматривают возможность «каскадирования» различных IP инкапсулированных услуг. Поэтому, в общем случае, сетевой оператор не может заранее знать конкретную структуру услуг каждой отдельной платформы. Эта информация должна предоставляться провайдером услуг в рамках ESG в реальном масштабе времени, одновременно с аудиовидеоматериалами.
Совокупность требований к оценке работоспособности системы
Применяемый в DVB-T упрощенный подход, имеющий в качестве предпосылки более или менее статическую структуру таблиц PAT, PMT и средних скоростей элементарных потоков для сетей DVB-H, может обеспечить только оценку стартовых требований. Более сложный подход предусматривает формирование в реальном времени образцовых потоков с использованием информации ESG. Более того, этот образцовый поток должен позволять контролировать передачу услуг на уровне РЧ сигнала в отношении формирования импульсов, на уровне элементарных потоков MPEG-2, на уровне IP пакетов и непосредственно на уровне компрессированных аудиовидеопотоков.
Процесс должен включать получение ESG, извлечение из него SDP файлов для каждой из услуги и, затем, контроль правильности параметров пересылаемых данных (IP адреса и номера порта) в течение определенного времени.
Многопротокольный контроль DVB-H контента
Тестирование на РЧ уровне
Не будем приводить здесь детальное описание СOFDM передачи. Если коротко, то DVB-H практически идентична DVB-T, но с добавлением дополнительного режима формирования ортогональных несущих 4 К, а также дополнительной опции перемежения данных в режиме 2 К. Для индикации присутствия услуг DVB-H, передаваемых в импульсном режиме, передачи информации о дополнительных режимах и дополнительном помехоустойчивом кодировании используется сигнализация TPS (Transmission Parameter Signalling). На приемной стороне потоки DVB-H, разумеется, могут контролироваться теми же методами, что и потоки DVB-T, равно как возможен и мониторинг уровня сигнала по мощности, измерение величины MER и анализ констелляционных диаграмм. Но, помимо этого, нужно убедиться, что приемная система правильно использует биты сигнализации TPS. Кроме того, импульсный характер передачи и дополнительное помехозащитное кодирование требуют, чтобы любым ошибкам, обнаруженным на РЧ уровне, были поставлены в соответствие временные метки, и их можно было бы коррелировать со сбоями на транспортном уровне MPEG-2, в IP пакетах и с ошибками декодирования аудиовидеопотоков. Это позволяет получить реальную картину качества каждой отдельной услуги DVB-H.
Стандарт TR 101 290 и тестирование с помощью образцового потока
Транспортный поток DVB-Н, будучи усложненным вариантом транспортного потока DVB-T, должен соответствовать всем требованиям первого, второго и третьего приоритетов стандарта TR 101 290. Для этого также можно использовать образцовые потоки, но только эти потоки, равно как и методы их анализа, должны быть усовершенствованы с учетом дополнительных режимов и свойств, добавленных в DVB-H — импульсной передачи, динамической смены услуг, появления таблицы INT и дополнительных дескрипторов.
Устройства, работающие на базе импульсной передачи, могут представлять проблему для упрощенных систем анализа, которые поддерживают только более ранние профили измерений MBG (Measurement Guideline for Bitrates), регламентированных DVB, такие как MGB2 (188,100мс, 1с). При измерении, в соответствии с этим профилем, импульсная передача будет инициировать постоянные сигналы неисправности, так как замеры будут давать либо нулевую, либо слишком высокую скорость трансляции услуги. Специально для измерений в импульсном режиме были введены дополнительные профили, а именно MGB 1A (188, 1c, 10c) и MGB 1B (188, 1c, 30c).
Важно также, чтобы образцовые потоки позволяли различать обязательные, опциональные и «запрещенные» элементы услуг.
Например, в DVB-T большинство таблиц и стандартных услуг являются обязательными и передаются постоянно. Структура же услуг DVB-H не фиксирована. Они могут передаваться разными способами, с разной системой временного и транспортного разделения. Соответственно, их присутствие в потоке будет «факультативным», но если уже они присутствуют, то должны быть сформированы правильно. И, наконец, некоторые из PID-ов (элементарных потоков) будут использоваться в сети другими службами, и если обнаружится, что они задействованы для передачи услуг DVB-H, то следует сформировать сигнал ошибки.
MPE инкапсуляция IP потоков в сетях DVB-H
IP потоки, содержащие либо ESG, либо аудиовидеоконтент, вводятся в транспортный поток MPEG-2 методом многопротокольной инкапсуляции MPE (Multi Protocol Encapsulation) определенного ISO 13818-6[4]. Для полноценного контроля сетей DVB-H необходимо, чтобы тестовая система умела оценивать корректность MPE инкапсуляции, извлекать IP датаграммы из транспортного потока и восстанавливать исходные IP потоки.
Извлечение ESG
Для обработки приемником услуг DVB-T требуется только информация из таблиц PAT и PMT, а таблица EIT предоставляет дополнительную, необязательную информацию.
В сетях DVB-H, напротив, услуги должны быть занесены в таблицу NIT, ссылка на которую дана в PAT, PMT и в новой таблице INT. А также описаны в обязательном гиде ESG, который доставляется как IP услуга. Без ESG и, в первую очередь, без S
DP файла, контент DVB-H не может быть воспроизведен в принципе. Поэтому извлечение из потока ESG является первым необходимым шагом в проверке DVB-H контента. Последовательность извлечения следующая:
1) Следует проанализировать таблицу NIT на предмет поиска связующих дескрипторов, указывающих на присутствие одной или более платформ DVB-H в транспортном потоке.
2) Связующий дескриптор должен содержать идентификатор услуги (Service_ID), информация для которого внесена в таблицу PAT.
3) PAT должна содержать информациюо PID-е, в котором передается PMT для данной услуги.
4) PMT должна включать ссылку на элементарный поток 5-го типа, в котором должна передаваться таблица IPMAC Notification Table (INT).
5) Таблица INT должна содержать список IP потоков, идентифицируемых IP адресами и идентификаторами услуг.
6) Для идентификации того, в каком IP потоке из присутствующих в INT находится данный поток, его идентификатор должен быть сопоставлен с информацией в PAT, а затем с PMT, из которой можно определить конкретный PID, содержащий интересующий IP поток.
7) Затем из найденного элементарного потока (PID) извлекаются IP пакеты, содержащие ESG.
Повторим, что в NIT может быть прописано больше одной платформы, то есть содержаться больше одного связного дескриптора. И каждый из них должен быть проверен индивидуально, хотя платформы могут частично пересекаться. Пользователь, как правило, выбирает между всеми доступными платформами.
Для каждой платформы обычно вещается как минимум два ESG потока. Один из них, со стартовой информацией, передается с использованием заранее известного IP адреса. Этот загрузочный ESG содержит указатели (IP адрес и адреса портов) того IP потока, в котором передается рабочий ESG для услуг данной платформы. Рабочий ESG может содержать информацию об одной или более услуге, и для каждой платформы может передаваться несколько рабочих ESG.
ESG передается в IP пакетах с применением системы FLUTE (File Delivery over Unidirectional Transport), разработанной Т. Paila [5]. Если коротко, то базовые компоненты этой системы — таблица FDT (File Delivery Table) со списком всех файлов, отправляемых в рамках конкретной FLUTE сессии, а также с самими файлами. Каждый файл имеет уникальный идентификатор TOI (Transport Object Identifier). Для систем контроля качества способность выявлять и анализировать FLUTE объекты является обязательной. Она, в частности, должна уметь читать вставляемые протоколом заголовки и идентификаторы TOI.
Анализ ESG
Не будем приводить здесь полное описание структуры ESG, но если коротко, то ESG — это структура передачи метаданных, сформированная из набора xml файлов (фрагментов), которые вместе исчерпывающе описывают параметры услуги, в том числе расписание программ и событий, а также дают информацию о провайдере, условиях покупки и системе закрытия. Кроме того, они включают SDP файлы, содержащие точные инструкции для ресивера, как получить доступ к услуге или событию и декодировать их.
ESG может передаваться в виде набора некомпрессированных xml (текстовых) файлов в рамках FLUTE структурированных IP потоков. Но так как ESG может оказаться достаточно объемным, он так же может быть сжат с использованием zlib компрессии или (что более типично) с применением хорошо оптимизированной схемы компрессии, разработанной специально для метаданных MPEG-7, под названием BiM (Binary MPEG-7) [6]. Информация SDP может непосредственно передаваться в xml файлах (в компрессированном виде), но дополнительно к этому — включаться в поток в качестве отдельного Flute файла, который обеспечивает более простой и быстрый доступ.
Таким образом, система контроля качества должна уметь корректно «прочитать» структуру ESG и декодировать информацию для того, чтобы удостовериться в том, что приемник получит доступ ко всем компонентам ESG, необходимым для идентификации, покупки, открытия и декодирования DVB-H контента.
Контроль структуры импульса 
Импульсный принцип передачи используется в DVB-H для сохранения энергии аккумуляторов приемника, который может включаться только на время импульса.
На рис.2 показаны параметры передаваемого потока, который могут быть напрямую измерены в канале связи.
Кроме того, измеряемые (реальные) параметры можно сравнить с заданными, так как для каждой услуги передается информация о размере каждого импульса, и каждый из них содержит метку времени с информацией о том, когда следует ждать появления следующего импульса. Точность соблюдения этой временной информации весьма важна. В результате неточности, приемник включится либо слишком рано, вхолостую растрачивая заряд аккумуляторов, либо слишком поздно, потеряв при этом часть данных. Компенсировать потери может помочь мощное помехозащитное кодирование, но для получения и обработки контрольных байтов, необходимых для запуска дополнительного процесса восстановления, также потребуется дополнительный расход аккумуляторов. В некоторых случаях информацию восстановить не удастся вовсе, и картинка будет потеряна.
Помимо измерений для отдельных услуг DVB-H, необходимо также проанализировать всю импульсную структуру целиком и все услуги, передаваемые в каждом IP потоке, в рамках каждого PID-а. Это связано с тем, что размеры импульсов и средняя скорость передачи у разных услуг могут различаться. Статистическое мультиплексирование услуг DVB-H, применяемое в системах последнего поколения, может существенно увеличить количество услуг, передаваемое в потоке определенной скорости. Выигрыш получается как раз за счет изменения величины импульса от одной услуг к другой и от одного импульса к другому в рамках одной услуги.
Контроль присутствия программы в потоке
Как отмечено выше, для этой цели недостаточно просто измерить скорость элементарного потока, переносящего определенные IP пакеты, так как один PID может использоваться для передачи нескольких IP потоков. Поэтому следует выделить определенный IP поток, переносящий интересующую услугу, и измерять именно его скорость. Информация о том, что нужно измерить, содержится в SDP файле в ESG. Пример файла SDP приведен ниже:
—————————————————————————-
c=IN IP4 225.1.1.2
m=audio 5566 RTP/AVP 97
a=rtpmap:97 mpeg4-generic/48000
a=fmtp:97 streamtype=5; profile-level-id=15; mode=AAC-hbr
m=video 5564 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=6742c0; sprop-parameter-sets=Z0LADZtAoPiA, aN4liA==;
В первой строчке этого примера указано, что данная DVB-H услуга передается в IP пакетах с адресом 225.1.1.2, который может быть найден приемником через таблицы INT, PAT и PMT, с помощью которых находится PID, переносящий нужные IP пакеты.
Следующие три строчки содержат информацию об аудиоконтенте для этой услуги, в том числе номер порта (5566),
а также способ, которым он должен быть декодирован. В данном случае это аудиопоток AAC. Последние три строчки содержат аналогичную информацию о видео (видео, компрессированное по стандарту H.264, порт 5564). Обратим внимание, что видео и аудио передаются в одном IP потоке с применением RTP протокола в соответствии с ETSI TS 102 005 (7). Поэтому для корректного декодирования услуги ресиверами критичен правильно указанный номер порта.
В случае, когда услуга состоит из множества последовательно транслируемых мини-программ, для каждой из программ может понадобиться свой SDP файл, так как их параметры в отношении кодирования, доставки, закрытия и условий продажи могут различаться. Заданные скоростные ограничения могут быть получены либо из ESG, либо определены на основании типа потока.
Контроль Видео /Аудио
Присутствие IP потока ожидаемой скорости и правильные номера портов в принципе подтверждают, что программа передается с параметрами, соответствующими ее описанию в ESG и, следовательно, может быть обработана приемником. Тем не менее, полновесный контроль качества услуги предполагает периодический контрольный прием видео и аудио. Это требование не связано особенностями DVB-H и с таким же успехом может предъявляться к трансляциям DVB-T, S или С. При простейшем варианте такой проверки система просто периодически декодирует видео- и аудиопотоки, выводя на дисплей маленькие контрольные картинки и обеспечивая возможность дистанционного просмотра для сетевого оператора. Более продвинутые варианты системы автоматически отслеживают замороженные картинки или черный экран, а для аудио — пропажу звука. Система полного контроля в качестве опции может также включать детальный анализ кодированного в H.264 видео и AAC аудио, которые с этой целью извлекаются из входящего транспортного потока. Опция аппаратного декодера, интегрированного с системой, обеспечивает выходы для просмотра видеоматериала в реальном разрешении и прослушивания аудиосопровождения в передаваемом формате. Например, наличие выхода с поддержкой HDMI позволит подключить к приемнику ТВЧ дисплей и систему воcпроизведения звука Dolby 5.1 surround sound.
Заключение
Контроль качества услуг DVB-H требует многоуровневого
и многопротокольного подхода. Он позволяет убедиться не только в том, что трансляции осуществляются с требуемыми РЧ характеристиками и в правильном соответствии с транспортными протоколами, но также в корректности сигнализации, с помощью которой приемник находит и декодирует контент. Анализ корректности ESG, в особенности содержания SDP файла и расписания программ, — важные этапы контроля доставки контента.