Українська   English
ДонНТУ   Портал магистров

Реферат по теме выпускной работы

Содержание

Введение

Огромное распространение сетевых технологий стимулировала разработку широкополосных сетей и различных медиа-приложений. Фактически, уже стало действительностью все сетевое. Целью современных сетей стало максимально быстро и качественно передавать информацию пользователям. В связи с этим, специалисты начали искать способы для расширение диапазона предоставляемых услуг. Технология VoIP сделала возможным использование сети для передачи голосовых данных. Следующим шагом стала передача видео для еще более полного использования сетевых возможностей связи. Яркими примерами этих достижений являются IPTV или Телевидение по протоколу интернета (IP-TV, IP-телевидение) (это технология цифрового телевиденья в сетях передачи данных по протоколу). В последнее время часто путается с технологией OTT (то бишь передача контента от провайдера к пользователю без оператора связи), которая, в свою очередь является подклассом IPTV в области распространения видео-контента. Кроме того, не следует путать и с интернет-телевиденьем, которое передаётся потоковым видео и доступно пользователю напрямую, без посредников (компаний-операторов).

Цели и задачи

Цель – оптимизация передачи IPTV трафика в сети провайдера без потерь качества и скорости (либо же с повышением данных показателей) с учетом стоимостных характеристик оборудования самой сети и оконечных устройств пользователей.

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

Объект исследования: сеть доступа провайдера Интернет и медиауслуг для условий крупного микрорайона мегаполиса.

Предмет исследования: управление передачей IPTV медиа потоков с учетом показателей качества трафика и стоимостных характеристик сетевого и пользовательского оборудования.

В результате разработки подсистемы управления передачей IPTV медиа потоков планируется достижение следующих научных результатов:
1. Разработка модели передачи IPTV трафика в сети доступа провайдера Интернет и медиауслуг;
2. Разработка подхода для оптимизации IPTV трафика в сети доступа провайдера Интернет и медиауслуг.

1. Обзор существующих систем для предоставления услуги IPTV

Архитектура сети с предоставлением услуги IPTV представлена на рис. 1.1. Головная станция.

Архитектура сети с предоставлением услуги IPTV

Рисунок 1.1 – Архитектура сети с предоставлением услуги IPTV

Головная станция – важный компонент решения «IPTV» при построении услуг цифрового телевидения. Головная станция является программно-аппаратным комплексом, который обеспечивает прием сигнала от радио и телевизионных станций и спутников, обеспечивает раскодирование и демультиплексирование цифровых сигналов и MPEG-кодирование аналоговых сигналов с последующим мультиплексированием подготовленных материалов в IP-потоки [1].

Компонентами Головной станции являются (Представлены на рисунке 1.2):
• антенный пост – обеспечивает прием сигналов от эфирных станций и спутников – цифровые спутниковые приемники – дескрипторы – обеспечивают раскодирование цифровых сигналов, полученных с Антенного поста и передачу материалов Стримеру / мультиплексору;
• узел цифрового кодирования – обеспечивает MPEG-кодирование аналоговых и цифровых сигналов и передачу материалов Стримеру / мультиплексору;
• стример / мультиплексор – ключевой элемент Головной станции, обеспечивает мультиплексирование материалов и IP-вещание таким образом, что каждый канал имеет свой уникальный адрес и порт IP вещания.

Компоненты Головной станции

Рисунок 1.2 – Компоненты Головной станции

Система закрытия контента. Система защиты контента от несанкционированного доступа (CAS/DRM) обеспечивает безопасность услуг и защиту видео материалов от несанкционированного просмотра и цифрового копирования (соблюдение авторских прав).

Система CAS/DRM

Рисунок 1.3 – Система CAS/DRM

Система CAS/DRM (рисунок 1.3) осуществляет шифрацию аудио- и видеоматериалов, при этом доступ к материалам абонентам разрешается по авторизации абонентов собственными средствами CAS/DRM или средствами других систем – middleware, биллинг. В качестве средств авторизации используются программные ключи и самые современные и надежные алгоритмы. Дешифрация аудио- и видеоматериалов осуществляется непосредственно на стороне абонента посредством STB.

Middleware (рисунок 1.4).

Middleware – программно аппаратный комплекс, который обеспечивает управление всеми компонентами решения «IPTV», обрабатывает запросы от абонентских устройств, обеспечивает взаимодействие с системами Оператора связи.

Middleware

Рисунок 1.4 – Middleware

Middleware позволяет осуществлять [3]:

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

Абонентское устройство (рисунок 1.5)

Абонентское устройство

Рисунок 1.5 – Абонентское устройство

Абонентское устройство является связующим звеном между системами формирования и доставки аудио- и видеоматериалов и телевизором абонента.STB-устройство представляет собой миникомпьютер с операционной системой и WEB-браузером.

Обмен командами управления и медиа материалами осуществляется через сетевой интерфейс.

Система распределения контента (рисунок 1.6)

Система распределения контента

Рисунок 1.6 – Система распределения контента

При построении услуг IPTV сосредотачивать аудио и видео материалы в единой точке обмена – не целесообразно. Данный шаг приводит к повышенной загрузке сети, нерациональному использованию компонентов решения, отсутствию возможности предоставлять качественные услуги большому количеству абонентов.

Как следствие, необходимо качественно распределить в сети Заказчика видеосерверы, что бы было обеспечены условия:

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

Система распределения получает от middleware запросы абонентов на доступ к контенту, определяет, на каком сервере с минимальной загрузкой и в максимальной близости к абоненту находятся требуемые данные, и разрешает абоненту получить их с выбранного сервера. Если на минимально загруженном, но максимально приближенном к абоненту, сервере требуемого контента не обнаружено, то запрос будет переадресован на другой, схожий по условиям, сервер.

Видео сервер (рисунок 1.7)

Видео сервер

Рисунок 1.7 – Видео сервер

Видеосерверы используются для реализации услуг NVoD, VoD, PVR. Видеосервер представляет собой дисковый массив большой емкости с установленным программным обеспечением.

Программное обеспечение реализует multicast – трансляцию видеоматериалов для услуги NVoD и unicast – трансляцию при предоставлении услуги VoD. Видеосервер позволяет осуществлять перехват и запись multicast-потоков, то есть поддерживать услугу PVR.

Методы передачи трафика в IP-сетях: unicast, broadcast и multicast:

  1. Трафик unicast (одноцелевая передача пакетов) используется, прежде всего, для сервисов персонального характера. Каждый абонент может запросить персональный видеоконтент в произвольное, удобное ему время. Трафик unicast направляется из одного источника к одному IP-адресу. Число абонентов, которые могут получать трафик unicast одновременно, ограничено доступной в магистральной части сети шириной потока (скоростью потока).
  2. Трафик broadcast (широковещательная передача пакетов) использует специальный IP-адрес, чтобы посылать один и тот же поток данных ко всем абонентам данной IP-сети. Например, такой IP-адрес может оканчиваться на 255 (допустим. 192.0.2.255) или иметь 255 во всех четырех полях (255.255.255.255). Важно знать, что трафик broadcast принимается всеми включенными компьютерами (или STB) в сети независимо от желания пользователя.
  3. Трафик multicast (групповая передача пакетов) используется для передачи потокового видео, когда необходимо доставить видеоконтент неограниченному числу абонентов, не перегружая сеть. Это наиболее часто используемый тип передачи данных в сетях IPTV, когда одну и ту же телевизионную программу смотрит большое число абонентов. В реальной IPTV-сети присутствуют одновременно все три вида трафика: broadcast, multicast и unicast. Оператор, планируя оптимальную величину пропускной способности сети, должен учитывать разные механизмы влияния различных технологий IP-адресации на объем трафика [1].

Для осуществления передачи видео необходимо использовать протокол транспортного уровня – TCP. Протокол TCP используется в тех случаях, когда требуется надежная доставка сообщений. Он освобождает прикладные процессы от необходимости использовать таймауты и повторные передачи данных для обеспечения надежности. Но не смотря на это протокол не подходит для использования передачи в реальном времени. Эту задачу решает протокол реального времени - RTP (Real-TimeTransportProtocol), который гарантирует передачу данных одному или более адресатам с задержкой в заданных пределах, т. е. данные могут быть воспроизведены в реальном времени. Пакеты RTP содержат следующие поля: идентификатор отправителя (кто из участников генерирует данные), отметки о времени генерирования пакета (чтобы данные могли быть воспроизведены принимающей стороной с правильными интервалами), информация о порядке передачи, а также информация о характере содержимого пакета. Наличие такой информации позволяет оценить величину начальной задержки и объема буфера передачи. Протокол RTP используется только для передачи пользовательских данных всем участникам сеанса. Совместно с RTP работает протокол RTCP (Real-timeTransportControlProtocol), основная задача которого состоит в обеспечении управления передачей RTP. RTCP использует тот же самый базовый транспортный протокол, что и RTP, но другой номер порта.

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

2. Исследование проблем реализации IPTV

Самыми распространёнными проблемами в сети IPTV являются:

  1. Скорость передачи данных;
  2. Качественная передача данных в том числе в ЧНН;
  3. Стоимость оборудования;
  4. Ёмкость самой сети.

Методы решения проблем

Одним из методов оптимизации является IGMP (Internet Group Management Protocol) snooping. Он позволяет настроить ограничение трафика, так как по умолчанию коммутатор передаёт multicast-трафик как broadcast (широковещательный). Это обусловлено тем, что в пакете multicast в качестве MAC-адреса получателя использует специально сформированный адрес, никому не принадлежащий в сети. Если multicast-трафика не много, это не создаёт больших проблем. Но в случае, когда такого трафика много, встаёт задача ограничить его распространение. Тут на помощь и придёт протокол IGMPsnooping.

Ниже мы рассмотрим работу данного протокола в общих чертах:

  1. Первое, что делает коммутатор, определяет, где находится маршрутизатор(ы). Для этого он слушает наличие в сети сообщений IGMP GeneralQuery, PIM, DVMRP и пр.
  2. Устройство отправляет IGMP Report, когда хочет получать тот или иной multicast-трафик. Данное сообщение перехватывает коммутатор. Из него коммутатор получает следующую информацию: устройство с таким-то MAC-адресом, находящееся за определённым портом, хочет получать трафик такой-то multicast группы. Причём для коммутатора при идентификации multicast группы в первую очередь важен не IP-адрес этой группы (IP-адреса multicast групп лежат в диапазоне 224.0.0.0 – 239.255.255.255), а её MAC-адрес. Коммутатору проще работать именно с адресацией на канальном уровне. Как мы знаем, MAC-адрес формируется по определённому правилу из IP адреса multicast группы. Вся эта информация заносится в таблицу MAC-адресов коммутатора.
    Далее коммутатор отправляет в сторону маршрутизатора IGMP Report, содержащий такую же информацию, как была получена от устройства.
  3. Маршрутизатор, получив сообщение IGMP Report, начинает передавать multicast-трафик. Но так как коммутатор знает, где находится устройство, желающее его получать, он ретранслирует трафик только на определённый порт. Теперь в таблице MAC-адресов есть запись с MAC-адресом multicast-группы, которая смотрит на конкретный порт.
  4. Периодически маршрутизатор отправляет в сеть IGMP GeneralQuery. Коммутатор рассылает его через все порты.
  5. Получив IGMP GeneralQuery, устройство отвечает сообщением IGMP Report. Коммутатор перехватывает его и отправляет только в сторону маршрутизатора. Остальные получатели multicast-трафика данное сообщение не получают. А, значит, отвечают своими IGMP Report. Таким образом работа механизма ReportSuppression нарушается. Это необходимо для идентификации всех получателей multicast-трафика. Иначе клиент, услышав IGMP Report от другого, решит, что ему отвечать не нужно, и коммутатор не узнает о его присутствии. Получив от всех IGMP Report, коммутатор обновляет свои записи. В сторону маршрутизатора все сообщения IGMP Report отсылать смысла нет, поэтому отправлется только одно — самое первое.
  6. Если устройство решает прекратить получать трафик для определённой multicast-группы, оно отправляет сообщение IGMP Leave. Коммутатор, как обычно, перехватывает его [2].
  7. Во-первых, коммутатор проверят, нет ли за этим же портом (откуда пришло сообщение IGMP Leave) других получателей multicast-трафика. Ведь в этот порт может быть подключен другой коммутатор. Для этого он отправляет сообщение IGMP Group-SpecificQuery. Если ответа на него не последовало, коммутатор просто убирает закрепление MAC-адреса multicast-группы за данным портом. Если ответ пришёл, продолжает передавать трафик через данный порт.
  8. Далее коммутатор проверяет, а есть ли на нём другие получатели multicast-трафика для данной группы, но находящиеся за другими портами. Для этого он просто смотрит в свою таблицу MAC-адресов.
    • Если такие получатели есть, больше коммутатор ничего не делает. Посылать сообщение IGMP Leave в сторону маршрутизатора смысла никакого нет.
    • Если это был последний получатель для данной multicast-группы, коммутатор отправляет сообщение IGMP Leave в сторону маршрутизатора.
  9. Получив сообщение IGMP Leave, маршрутизатор рассылает сообщения IGMP Group-SpecificQuery, которые коммутатор в свою очередь рассылает через все свои порты. Конечно же, никто не откликается и маршрутизатор перестаёт передавать трафик для данной группы.

3. Описание объекта исследования

В качестве объекта исследования рассмотрим участок сети, топологическая схема которого представлена на рис. 3.1

Диаграмма состояний автомата Мура

Рисунок 3.1 – Топологическая схема участка сети как объекта исследования
(анимация: 5 кадров, 7 циклов повторения, 83 килобайтa)

Источник и получатель потокового multicast-трафика будет реализован через VLC mediaplayer (далее VLC проигрыватель) [6-7].

Так же существует проблема передачи multicast.

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

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

Другой способ – применение шлюзов вещания. Данный способ также подразумевает использование unicast, но при этом (в отличие от туннеля) меняется заголовок пакетов. В простейшем случае такой функционал можно реализовать путем установки пары серверов с использованием СПО (например, VLC). Но есть также большое количество решений для операторов IPTV, в которых сервер не только выступает в роли шлюза, но и осуществляет функции хранения и мониторинга видеопотоков.

Выводы

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

При написании данного реферата магистерская работа еще не завершена. Окончательное завершение: июль 2018 года.
Полный текст работы и материалы по теме могут быть получены у автора или его руководителя после указанной даты.

Список источников

  1. Аль-Днебат Саид Али. Применение сетей массового обслуживания для исследования процессов передачи видеопотоков в пакетных сетях / Научная библиотека диссертаций и авторефератов disserCat. [Электронный ресурс]. – Режим доступа: http://www.dissercat.com/....
  2. Алексеев И. Интегрированные услуги нового поколения Internet / Игорь Алексеев. [Электронный ресурс]. – Режим доступа: https://www.osp.ru/....
  3. Мизин И. Телекоммуникационные технологии. Состояние и перспективы развития / И. Мизин. – М.: Электроника НТБ. Выпуск #1 / 1998.
  4. Анатомия VoD – основы видео по запросу [Электронный ресурс]. – Режим доступа: http://internetno.net/....
  5. Бугай А. А. IPTV Вызов традиционному телевидению / Бугай А. А., Яшенкова Н. А. // T-Comm. 2008. № 1. [Электронный ресурс]. – Режим доступа: http://cyberleninka.ru/article/... (дата обращения: 23.01.2018).
  6. Петрусь И. П. Аспекты практического использования беспроводной оптической технологии передачи данных / Петрусь Иван Павлович, Гузенкова Елена Алексеевна // Интернет-журнал Науковедение. 2014. № 2 (21). [Электронный ресурс]. – Режим доступа: http://cyberleninka.ru/article/... (дата обращения: 23.01.2018).
  7. Шалагинов В. А. Требования к построению транспортных сетей операторов мобильной связи // T-Comm. 2012. № 7. – С. 225–227.