4 курс (заочка) / Лекции / 3, 4, 5 лекции МИС (SIP, RTP)

1.5. Видео

Видео является последовательностью кадров, показываемых с определенной скоростью, обычно 24 или 30 кадров в секунду. Цифровое видео, как и оцифрованный звук, передается по сети потоком дискретных пакетов. Требования к пропускной способности зависят от уровня избыточности информации, как в каждом кадре, так и в их последовательности. Оба этих вида избыточности информации могут быть использованы для алгоритмов сжатия видео. Таблица 1.4 иллюстрирует некоторые распространенные [6] схемы сжатия видео.

Таблица 1.4

Ограничения на наличие ошибок передачи и передачу в реальном времени аналогичны ограничениям для звука.

1.6.Требования к передаче мультимедиа по сетям

Вэтом разделе мы рассмотрим требования, накладываемые распределенными мультимедийными приложениями на передающую сеть. Они могут быть разбиты на две категории [7] – требования к трафику и функциональные требования. Первые включают требования реального времени (задержки и нестабильность, пропускная способность и досто-

11

верность), а вторые включают поддержку сервисов мультимедиа (мультикастинг, безопасность, мобильность и управление сессиями). Требования к трафику могут быть удовлетворены только расширением базовой архитектуры Интернет, в то время как функциональные требования можно выполнить введением новых протоколов в стеке протоколов TCP/IP. Функциональные требования не являются абсолютно необходимыми, в том смысле, что распределенные мультимедийные приложения могут работать с высокой производительностью путем внедрения необходимых функций в само приложение.

1.6.1. Характеристики реального времени (ограничения на задержки и нестабильность)

Как рассматривалось в разделах 1.1- 1.5, такие компоненты мультимедиа, как звук и видео, накладывают требования по передаче в режиме реального времени. Например, они должны проигрываться с той же скоростью, с которой они оцифровывались. При любой задержке в передаче это сразу будет обнаружено. В Интернет-телефонии человек может спокойно относиться к задержкам не более 200 мс. Таким образом, передача мультимедиа в реальном времени накладывает жесткие ограничения на задержку пакетов и нестабильность интервалов их поступления.

1.6.2. Требование высокой пропускной способности

Очевидно, что мультимедийные приложения требуют существенно более высокой пропускной способности сетей, чем обычные текстовые приложения, широко распространенные в прошлом. Более того, мультимедийные потоки передаются с использованием протокола UDP, который не имеет механизма контроля перегрузок сети. Таблица 1.5 показывает требования к пропускной способности для наиболее распространенных типов мультимедиа.

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

12

Таблица 1.5

Требования к пропускной способности для различных элементов мультимедиа

1.6.3. Требования к ошибкам

Как отмечалось ранее, разные типы мультимедиа имеют разные требования к наличию ошибок при их передаче по сетям. Ошибки возникают при повреждении или потере пакетов. Большинство приложений, допускающих ошибки при передаче, используют технику маскиро-

вания ошибок (error concealment techniques – FEC), которая позволяет восстановить потерянную информацию на основе информации из других пакетов.

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

13

1.6.4. Поддержка мультикаста

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

Мультикаст легче обеспечить при односторонней передаче информации, чем при двусторонней. Например, в случае использования Ин- тернет-радио мультикаст обеспечивается созданием дерева связи с вершиной у отправителя информации, ветвями – у ее получателей и соответствующим дублированием пакетов в узлах дерева. Однако в случае двусторонней коммуникации как, например, в Интернет-телефонии для нескольких участников, необходимо иметь некоторый функционал для корректного смешивания голосовых потоков от разных участников. В противном случае придется поддерживать множество двусторонних каналов связи каждого участника с остальными, что может дать слишком высокую нагрузку на передающую сеть.

1.6.5. Управление сессиями

Управление сессиями включает:

Описание типа мультимедиа. Эта информация необходима распределенным мультимедийным приложениям для указания таких параметров сессии, как тип мультимедиа (звук, видео или данные), схемы кодирования, время начала и окончания сессии, IP адреса используемых хостов и т.д. Часто очень важно описать сессию до ее начала, так как участники сессии могут иметь разные возможности по приему мультимедиа.

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

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

14

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

Управление сессией. Информация, содержащаяся в разных потоках, может иметь внутренние связи и это должно быть учтено при ее передаче. Это называется синхронизацией мультимедиа и может быть достигнуто расстановкой меток времени (timestamps) в передаваемых пакетах. Более того, получатели потокового мультимедиа могут захотеть иметь возможность управления воспроизведением [8], как это делается в обычных видеомагнитофонах.

1.6.6. Безопасность

При обсуждении процесса передачи мультимедиа часто забывают про вопросы безопасности. Однако с ростом использования сервисов реального времени вопросы безопасности становятся достаточно важными. Безопасность для данных мультимедиа выражается в трех аспектах: целостность, аутентичность, шифрованность. Например, публичное вещание требует целостности и аутентичности данных, а частное – их шифрования. Для этого можно использовать различные криптографические схемы [9].

Еще одна проблема – в сохранении авторских прав на компоненты мультимедиа. Например, рассмотрим доставку фильмов по предварительной оплате. Существует возможность использования полученных фильмов в коммерческих целях. Современные цифровые технологии [11], добавляющие дополнительные данные в мультимедиа, могут помочь в предотвращении таких нарушений.

1.6.7. Поддержка мобильности

Все более широкое использование беспроводных и сотовых сетей подталкивает приложения мультимедиа к мобильности. Сотовые сети покрывают огромную площадь и поддерживают высокий уровень мобильности. Беспроводные сети, таки е как IEEE 802.11x [12], покрывают относительно небольшие участки и имеют ограниченный уровень мобильности. Однако такие сети обладают большей скоростью передачи и более удобны для подключения пользователей.

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

15

Глава 2. Поддержка распределенного мультимедиа трафика в Интернете

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

2.1. Поддержка трафика реального времени в Интернете

Трафик реального времени имеет жесткие требования на задержку пакетов и неустойчивость их передачи, а сегодняшнее состояние сети Интернет часто им не соответствует. Требуются дополнительные стадии передачи пакетов и новая технология уменьшения потерь в процессе этой передачи. Рассмотрим эти изменения более детально [12].

2.1.1. Задержки при обработке пакетов

Это постоянные задержки, которые может присутствовать как на стороне отправителя пакетов, так и на стороне их получателя. Причиной задержек может быть необходимость преобразования данных из аналоговой формы в цифровую и их пакетизации на протоколах разного уровня до непосредственной передачи по каналу связи. На этапе получения данных может потребоваться обратная процедура. Обычно эти задержки определяются используемой операционной системой и мультимедийным приложением. Для уменьшения таких задержек даже может использоваться специализированная мультимедийная операционная система [13].

2.1.2. Задержки при передаче пакетов

Это время, затрачиваемое на физическом уровне для передачи пакетов. Оно зависит от нескольких факторов, например:

Число активных сессий. На физическом уровне пакеты передаются по схеме FIFO, поэтому при наличии нескольких активных сессий задержка становится значительной, особенно при отсутствии в операционной системе специализированных алгоритмов управления мультимедийным трафиком.

Пропускная способность канала. Увеличение пропускной способности канала уменьшает задержки передачи пакетов. Так при пе-

реходе от 10 Mbps Ethernet к 100 Mbps fast Ethernet задержки передачи должны уменьшиться в 10 раз.

16

Medium Access Control (MAC) задержка. Если канал переда-

чи делится несколькими приложениями, то может использоваться соответствующий уровень сетевого доступа и обнаружения ошибок (MAC протокол) [14]. Выбор MAC протокола существенно влияет на величину задержки. Например, если пропускная способность C bps, а длина пакета L бит, время передачи для выделенной линии равно L/C. Но если

MAC протокол использует TDMA (Time Division Multiple Access), ска-

жем, при m слотах, задержка будет равна mL/C. Большие сети Ethernet не могут дать никаких гарантий на величину этой задержки из-за неопределенности прогноза коллизий между различными потоками данных в канале [16]. Fast Ethernet работает по той же схеме, как и 10 Mbps Ethernet и также не дает таких гарантий. Изохронный Ethernet и Ethernet

сзапросами приоритетов могут обеспечить качество передачи, но их распространение пока под вопросом.

Переключатель контекста в ОС. Отсылка и получение паке-

тов подразумевает некоторое время на работу контекстных переключателей. Следовательно, существует некоторый максимум для скорости передачи пакетов компьютером. Для 10 Mbps LAN эта задержка может быть несущественной, но для гигабитных сетей ее уже надо учитывать. Для уменьшения этой задержки требуется улучшение драйверов устройств и повышение частоты работы компьютера.

2.1.3. Задержка передачи

Верхним порогом скорости передачи сигнала является скорость света. В случае передачи в одном здании на расстояние 200 метров задержка составит около одной микросекунды. Если же передача происходит между странами на расстояние 20,000 км, задержка составит 0.1секунды. Эти значения являются физическими ограничениями и не могут быть уменьшены. Если интерактивная сессия мультимедиа требует задержек не более 200 миллисекунд, то на таком расстоянии заданное качество передачи не может быть обеспечено.

2.1.4. Задержки маршрутизации и обработки очередей

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

17

время добавляется к задержке в очереди. Такой тип задержки случаен и является основной причиной несинхронности в передаче данных. Если задержка времени в очереди становится слишком большой, пакет может быть послан повторно. Это может вызвать лавинный эффект и привести к перегрузке и еще большему увеличению задержки в очереди. В современных сервисах Интернета используется специальная технология для предотвращения подобных эффектов. Например, в простейшем случае образуется виртуальный выделенный канал (с выделением ресурсов в форме буферов или частот пропускания) и эта задержка исчезает. По такому принципу работают модели Integrated Services (Intserv) и MultiProtocol Label Switching (MPLS). Другим вариантом является комбинация упорядочивания трафика, контроль входов и модификации технологии обработки очередей с учетом приоритетов пакетов. Этот подход ис-

пользует модель Differentiated Services (Diffserv).

2.2. Требование высокой пропускной способности

Передача потока мультимедиа требует высокой пропускной способности каналов (см. таблицу 5). Модель негарантированной доставки (best effort Internet model) не обеспечивает никаких механизмов для приложений по резервированию сетевых ресурсов при передаче больших объемов информации. Неконтролируемая передача на высокой скорости может привести к перегрузке канала и полной остановке передачи. В данной модели нет механизма предотвращения подобных ситуаций, кроме простого отключения источников информации. Приложения сами должны динамически адаптироваться к перегрузкам каналов. Гибкие приложения, использующие TCP, применяют механизм обрат-

ной связи (closed-loop feedback mechanism), встроенный в TCP для предотвращения перегрузок. Этот метод называется реактивным контролем перегрузок. Однако многие приложения используют при передаче протокол UDP, в котором нет механизмов контроля перегрузок и есть тенденция к полной остановке передачи от перегрузок канала.

Для решения этих проблем, используется управление доступом (admission control), резервирование пропускной способности (bandwidth reservation) и механизмы управления трафиком (traffic policing mechanisms). Приложение должно сначала получить полномочия передавать трафик с заданной скоростью и с некоторыми заданными характеристиками трафика. Если такие полномочия даются, оно создает запас необходимых ресурсов (пропускной способности и буферов) для передачи данных на заданной скорости. Механизмы контроля трафика обеспечивают соблюдение заданных скоростей.

18

2.3. Отклонения характеристик сети

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

Для новых моделей сервисов Интернет приложение-отправитель должно пройти контроль доступа. В этом случае отправитель может указать максимальную ошибку, которую он может терпеть. Если сеть использует алгоритм маршрутизации на основе QoS и не может найти путь, удовлетворяющий этому требованию, она будет просто отвергать соединение или сделать встречное предложение о повышении уровня допустимых ошибок. Другими словами, отправитель предупреждается об отклонениях характеристик сети.

2.4. Предлагаемые модели сервисов Интернет

Мы рассмотрим несколько новых моделей архитектуры Интернет –

Integrated Services (Intserv), Differentiated Services (Diffserv) и Multiprotocol Label Switching (MPLS) – которые предлагаются для удовлетворения требований распределенных приложений мультимедиа при передаче информации по обычной сети. Но, прежде чем углубляться в обсуждение этих моделей, сформулируем некоторые принципы, которые являются для них общими.

2.4.1. Уточнение требований к сервисам и описанию трафика

Для добавления к Интернету поддержки гарантированного обслуживания необходимо определить ее в математических терминах. QoS определяет уровень сервиса, который распределенное мультимедийное приложение ожидает от сети связи. Три параметра QoS представляют первостепенный интерес: пропускная способность, задержки и надежность.

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

19

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

Задержка, в качестве второго параметра, определяет максимальную задержку передачи данных от отправителя до получателя [11]. Значение задержки при передаче мультимедийной информации может варьироваться от одного элемента к другому. Источником этих изменений задержки может быть нестабильность процесса передачи (jitter) и его сдвиг (skew). Нестабильность означает, что в потоке объектов их фактическое время появления отличается от заданного момента (рис. 2.1).

Рис. 2.1. Эффект несинхронности потока объектов:

(a)–исходный поток с регулярными интервалами; (b)–эффект нестабильности; (c)–эффект сдвига.

На рис. 2.1 (a) каждая стрелка представляет позицию объекта через равные промежутки времени. На рис. 2.1 (b) пунктирные стрелки показывают ожидаемые моменты появления объектов, а сплошные – реальное появление. Видно, что существует случайное отклонение от ожидаемого момента появления объекта. Этот эффект называется нестабильностью потока объектов по времени. При передаче видео это выражается в дрожании получаемой картинки.

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

20