Русский   English
ДонНТУ   Портал магістрів

Реферат за темою випускної роботи

Зміст

Вступ

Величезне поширення мережевих технологій стимулювала розробку широкосмугових мереж і різних медіа-додатків. Фактично, вже стало дійсністю все мережеве. Метою сучасних мереж стало максимально швидко і якісно передавати інформацію користувачам. У зв’язку з цим, фахівці почали шукати способи для розширення діапазону послуг, що надаються. Технологія VoIP уможливила використання мережі для передачі голосових даних. Наступним кроком стала передача відео для ще більш повного використання мережевих можливостей зв’язку. Яскравими прикладами цих досягнень є IPTV або Телебачення по протоколу інтернету (IPTV, 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.