Аналіз навантажень при передачі медіатрафіку в каналах взаємодіючих IP-систем

Аналіз навантажень при передачі медіатрафіку в каналах взаємодіючих IP-систем

ВСТУП

Сьогодні інформаційні та телекомунікаційні технології стають одним з основних чинників формування світової економіки. Їх розвиток і конвергенція - це крок до створення єдиної глобальної інформаційної інфраструктури, невід'ємною частиною якої є сучасні засоби створення, обробки/зберігання, доступу і передачі інформації.

Практично всі мережі є на сьогодні складеними, тобто вмістять у собі декілька мереж, кожна з яких може працювати на основі власної технології канального рівня. Це обумовлено тим, що більшість мереж створювали поступово, об’єднуючи та долучаючи щоразу більшу кількість ізольованих раніше цих сегментів.

Відносно складеної мережі вживається термін <інтермережа>, який визначає сукупність логічних мереж, що взаємодіють між собою на основі протоколів та устаткування мережевого рівня. В свою чергу інтермережу називають IP-мережею.

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

В дипломній роботі буде проведений аналіз протоколів та технології передачі відео та аудіо кодеків, проаналізовані інформаційні параметри протокольних об’єктів ІР систем, а також виконаємо дослідження надлишкової інформації стеків протоколів ІР телефонії та проведемо аналіз навантажень в каналах взаємодіючих систем при передачі кодеків.

1. АНАЛІЗ ПАРАМЕТРІВ ПРОТОКОЛІВ ТА ТЕХНОЛОГІЙ ПЕРЕДАЧІ МЕДІАТРАФІКУ

1.1 Постановка задачі

В теперішній час в IP мережах зростає обсяг передачі мультимедійного трафіку. Мультимедійний трафік це цифровий потік даних, який містить різні види повідомлень - звичайні дані та медіа дані. Мультимедійні потоки даних передаються телекомунікаційною мережею з метою надання віддалених інтерактивних послуг. Найбільш поширеними на сьогоднішній день мультимедійними послугами, наданих користувачам мережі, являються: відео телефонія, високошвидкісна передача мультимедійних даних, IP телефонія, цифрове телевізійне мовлення, мобільний відео зв’язок і цифрове відео за запитом.

Залежно від типу наданого сервісу виділяють дві основні категорії мультимедійного трафіку - трафік реального часу та трафік звичайних даних.

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

Трафік звичайних даних утворюють традиційні розподілені послуги сучасної телекомунікаційної мережі, таких, як електронна пошта, передача файлів, віртуальний термінал, віддалений доступ до баз даних тощо. Основними мультимедійними сервісами є відео телефонія та IP телефонія.

Сервіс відео телефонії здійснює передачу голосу разом з зображенням невисокої якості між двома та більше абонентами. Клієнт цього сервісу, через відповідну комутаційну апаратуру, можуть слухати і бачити один одного в режимі реального часу.

Сервіс IP телефонії здійснює передачу голосового трафіку (голосу) між двома абонентами мережі де в якості мережного протоколу, використовується протокол IP (Internet Protocol) [1].

На завантаження каналів мережі медіа трафіком безумовно впливають не тільки обсяги переданих медіа даних, але і обсяг службової інформації протоколів взаємодіючих систем.

Метою даного розділу є аналіз інформаційних характеристик технологій, протоколів та кодеків систем передачі медіа трафіку.

.2 Аналіз параметрів та характеристик аудіо та відео кодеків

Одним з важливих чинників ефективного використання пропускної здатності IP каналу, є вибір оптимального алгоритму кодування/декодування голосової інформації - кодека.

Кодеки можуть, як кодувати потік/сигнал, так і декодувати. Кодеки часто використовуються при цифровій обробці відео і звуку. Більшість кодеків для звукових та візуальних даних використовують стиснення з втратами, щоб отримувати прийнятний розмір готового (стисненого) файлу. Існують також кодеки, що стискають без втрат (lossless codecs). Але для більшості застосувань кращі кодеки з втратами інформації, так як малопомітне погіршення якості виправдовується значним зменшенням обсягу даних. Майже єдиний виняток - ситуація, коли дані будуть піддаватися подальшій обробці: в цьому випадку повторювані втрати на кодуванні/декодуванні нададуть серйозний вплив на якість

Всі існуючі сьогодні типи голосових кодеків за принципом дії можна розділити на три групи:

Кодеки з імпульсно-кодовою модуляцією (ІКМ) і адаптивною диференціальною імпульсно-кодовою модуляцією (АДІКМ), що з'явилися в кінці 50-х років і використовуються сьогодні в системах традиційної телефонії. У більшості випадків, являють собою поєднання АЦП/ЦАП.

Кодеки з вокодерним перетворенням мовного сигналу виникли в системах мобільного зв'язку для зниження вимог до пропускної здатності радіотракта. Ця група кодеків використовує гармонійний синтез сигналу на підставі інформації про його вокальні складові (фонеми). У більшості випадків, такі кодеки реалізовані як аналогові пристрої.

Комбіновані (гібридні) кодеки поєднують в собі технологію вокодерной перетворення/синтезу мови, але оперують уже з цифровим сигналом за допомогою спеціалізованих DSP. Кодеки цього типу містять в собі ІКМ або АДІКМ кодек і реалізований цифровим способом вокодер.

Розглянемо основні кодеки, які використовують в шлюзах IP телефонії операторського рівня.

Кодек G .711. Рекомендація G.711, затверджена МККТТ в 1984 р, описує кодек, який використовує ІКМ перетворення аналогового сигналу з точністю 8 біт, тактовою частотою 8 кГц і найпростішої компресією амплітуди сигналу. Швидкість потоку даних на виході перетворювача складає 64 кбіт/с (8 біт *8 кГц). Для зниження шуму квантування і поліпшення перетворення сигналів зневеликою амплітудою при кодуванні використовується нелінійне квантування за рівнем згідно зі спеціальним псевдо-логарифмічним законом: А-закон для європейської системи ІКМ-30/32 або m-закон для північноамериканської системи ІКМ-24.

Кодек G.711 широко поширений в системах традиційної телефонії з комутацією каналів. Незважаючи на те, що рекомендація G.711 в стандарті Н.323 є основною і первинною, в шлюзах IP телефонії даний кодек застосовується рідко через високі вимоги до смуги пропускання і затримок у каналі передачі. Використання G.711 в системах IP телефонії обґрунтовано лише в тих випадках, коли потрібно забезпечити максимальну якість кодування голосової інформації при невеликому числі одночасних розмов.

Кодек G.723.1. Рекомендація G.723.1 описує гібридні кодеки, що використовують технологію кодування мовної інформації, скорочено звану MP-MLQ (Multy-Pulse Multy Level Quantization множинне імпульсне, багаторівневе квантування. Дані кодеки можна охарактеризувати, як комбінацію АЦП/ЦАП і вокодера. Застосування вокодера дозволяє знизити швидкість передачі даних в каналі, що принципово важливо для ефективного використання радіотракта і IP каналу. Основний принцип роботи вокодера - синтез вихідного мовного сигналу за допомогою адаптивної заміни його гармонійних складових відповідним набором частотних фонем і узгодженими шумовими коефіцієнтами. Кодек G.723.1 здійснює перетворення аналогового сигналу в потік даних зі швидкістю 64 кбіт/с (ІКМ), а потім за допомогою багатосмугового цифрового фільтра/вокодера виділяє частотні фонеми, аналізує їх і передає по IP каналу інформацію тільки про поточний стан фонем в мовному сигналі. Даний алгоритм перетворення дозволяє знизити швидкість кодованої інформації до 5,3 та 6,3 кбіт/с без видимого погіршення якості мови. Кодек має дві швидкості і два варіанти кодування: 6,3 кбіт/с з алгоритмом MP-MLQ і 5,3 кбіт/с з алгоритмом CELP. Кодек G.723.1 широко застосовується в голосових шлюзах та інших пристроях IP телефонії.

Кодек G.728. Кодек використовує оригінальну технологію з малою затримкою LD-CELP (low delay code excited linear prediction) і гарантує оцінки MOS, аналогічні АДІКМ G.726 при швидкості передачі 16 кбіт/с. Даний кодек спеціально розроблявся як більш досконала заміна АДІКМ для обладнання ущільнення телефонних каналів, при цьому було необхідно забезпечити дуже малу величину затримки (менше 5 мс), щоб виключити необхідність застосування ехокомпенсаторів.

Сімейство включає кодеки G.729, включає кодекі G.729 Annex A, G.729 Annex В (містить VAD і генератор комфортного шуму). Кодеки G.729 скорочено називають CS-ACELP (Conjugate Structure-Algebraic Code Excited Linear Predictionс) - сполучена структура з керованим алгебраїчним та кодом лінійним передбаченням. Процес перетворення використовує DSP 21,5 MIPS і вносить затримку 15 мс. Швидкість кодованого голосового сигналу становить 8 кбіт/с. У пристроях VoIP даний кодек займає лідируюче положення, забезпечуючи найкращу якість кодування голосового інформації при досить високій компресії. Основні характеристики розглянутих кодеків наведені в табл. 1.1.

Таблиця 1.1 - Характеристики аудіо кодеків

Виконаємо аналіз інформаційних характеристик відео кодеків. Існує деяка кількість стандартів для стиснення відео високої чіткості. Приведемо короткі характеристики деяких стандартів.

Цифрове відео має п'ять основних характеристик: екранне дозвіл, частота кадрів, глибина кольору, бітрейт (ширина відеопотоку) і якість зображення.

Екранний дозвіл який позначає кількість точок (пікселів) по горизонталі і вертикалі, з яких складається зображення (відеокадр) на екрані. При запису дозволу спочатку вказується значення кількості точок у рядку (горизонтальний дозвіл), а потім число рядків, що беруть участь в побудові зображення (вертикальний дозвіл). Наприклад, для європейського відеостандарту PAL розмір кадру становить 720x576 пікселів, для північноамериканського стандарту NTSC-720x480, для відео високої чіткості (HD 720p) - 1280х720, а для стандарту HDTV (Full HD) - 1920x1080 точок. Чим вище екранне дозвіл, тим якість відео краще.

Частота кадрів - величина вказує, на те, яка кількість кадрів змінюється за секунду. Стандартної швидкістю відтворення відеосигналу вважається величина рівна 30 кадрам/c. Для кіно цей показник дещо менше та становить 24 кадра/с.

Глибина кольору (колірний дозвіл) - характеристика, яка вказує кількість кольорів, які можуть брати участь у формуванні відео зображення. Кількість кольорів у цифровому відео вимірюється в бітах. Так 1 біт може приймати два різних значення (0 або 1) і дозволяє відповідно закодувати тільки два кольори (зазвичай чорний і білий). За допомогою двох біт можна закодувати вже 4 кольору (22 = 4), за допомогою трьох біт - 8 кольорів (23), чотирьох - 16 (24) і так далі.

Як правило, глибина кольору описується за допомогою спеціальних колірних моделей. У комп'ютерній техніці застосовується модель RGB (червоний - зелений - синій), яка може бути представлена наступними найбільш поширеними режимами глибини кольору: 8 біт (256 кольорів), 16 біт (65 536 кольорів) і 24 біта (16 777 216 кольорів).

Бітрейт (ширина відеопотоку) показує кількість оброблюваних біт відеоінформації за одну секунду часу. Інакше кажучи це швидкість відеопотоку, яка вимірюється в мегабітах в секунду (Мбіт/с). Чим вона вища, тим краще якість. Наприклад, для стандарту DVD - відео ширина потоку складає близько 5 Мбіт/c, а для формату телебачення високої чіткості HDTV - уже 10 Мбіт/с.

Якість зображення - характеристика покликана оцінити якість обробленого відео в порівнянні з оригіналом і визначається сукупністю значень дозволу, глибини кольору і швидкості відео потоку.

Стандарти стиснення. Одна хвилина чистого не стисненого оцифрованого звуку займає на жорсткому диску комп'ютера близько 10 Мбайт, внаслідок чого, в переважній більшості, музичні файли зберігаються в стислому вигляді заради економії місця.

Існує кілька десятків популярних форматів стиснення, які використовують різні алгоритми компресії, які відповідно дають різні результати.(Digital Video) - один з найперших алгоритмів стиснення для відеопотоку, розробка якого почалася в 1993 році спільно відразу декількома компаніями, що є найбільшими виробниками відеообладнання (Sony, JVC, Panasonic, Philips і Hitachi). Формат DV забезпечує невисоку ступінь стиснення даних (5:1) і характеризується високим бітрейтом, за рахунок чого виходить відеофайл виходить досить великого розміру. Так одна хвилина DV - відео займає близько 200 Мб (1 година - 12 Гб) на цифрових носіях інформації.

Для стиснення відео можуть використовуватися різні стандарти. Але при цьому, можна стиснути відео абсолютно різними інструментами або програмними засобами, що дає на виході абсолютно різні результати.

Стандарт Н261 відеокодека <#"792084.files/image004.gif">×480

MPEG-1

до 1,5 Мбіт/с

16 (216 кольорів)

25 30

добра

352×288 352×240

MPEG-2

9,8 Мбіт/с

24 (224 кольорів)

25 30

добра

720×576 720×840

MPEG-4

9,8 Мбіт/с

24 (224 кольорів)

25 30

добра

1280×720 1920x1080

1.3 Аналіз параметрів протоколів сигналізації медіатрафіку

В процесі передачі медіа трафіку створюється та підтримується медіа сесія за допомогою протоколів сигналізації. Розвиток IP телефонії призвів до того, що сьогодні в реальних мережах VoIP існують конкурують між собою такі архітектури протоколів сигналізації: Н.323, SIP і MGCP. Протоколи цих трьох сімейств регламентують управління мультимедіа викликами і передачу медіа трафіку в IP мережах, але при цьому реалізують три різних підходи побудови систем телефонної сигналізації.

Введений міжнародним союзом електрозв’язку (МСЕ) набір рекомендацій Н.323. Історично перший і найпоширеніший в даний час. Н.323 став породженням діяльності розробників протоколів мультимедійної зв’язку в мережах ISDN (H.320). Відповідні роботи велися ще c початку 90-х років, коли ніякої IP телефонії і не було. Перша версія цього протоколу була прийнята МСЕ в 1996 р. і по суті була спробою перенести телефонну сигналізацію ISDN Q.931 на IP з’єднання, тобто як би «накласти» традиційну телефонію на мережі передачі даних. Рекомендації H.323 досить докладно описують способи організації мультимедійних конференцій, охоплюючи сервіси передачі голосу, відео і комп’ютерних даних в пакетних мережах.

Наступний по поширеності протокол IP телефонії називається SIP (Session Initiation Protocol); він описаний в рекомендаціях RFC 2543. SIP регламентує встановлення і завершення мультимедійних сесій - сеансів зв’язку, в ході яких користувачі можуть говорити один з одним, обмінюватися відеоматеріалами та текстом, спільно працювати над додатками тощо. SIP і супутні йому протоколи народилися і розвиваються в рамках головного органу стандартизації Інтернету IETF (Internet Engineering <#"792084.files/image003.gif">потоків. Ці потоки обробляються інтелектуальними шлюзами або абонентськими терміналами, які здатні виконувати лише обмежений набір команд, що виходять від керуючого пристрою. Порівняння функціональних особливостей трьох видів протоколів, приведено в табл. 1.3.

Таблиця 1.3 - Порівняння протоколів VoIP мережі

.4 Аналіз параметрів транспортних протоколів медіа систем

Для передачі медіа трафіку в ІР мережах використовуються протоколи транспортного рівня. Ці протоколи забезпечують контроль над передачею даних між мереженими протоколами та додатками прикладного рівня системи. В даний час в локальних мережах найбільш поширено кілька різновидів транспортних протоколів. Розглянемо інформаційні параметри транспортних протоколів, що використовують для передачі трафіку медіа додатків.

Транспортний протокол UDP (User Datagram Protocol). Протокол UDP є один з основних транспортних протоколів. Він працює безпосередньо з IP пакетами та здійснює їх мультиплексування між різними додатками. UDP це один з найпростіших протоколів транспортного рівня моделі OSI, котрий виконує обмін дейтаграмами без підтвердження та гарантії доставки. При використанні протоколу UDP обробка помилок і повторна передача даних має виконуватися протоколом вищого рівня. Але, незважаючи на всі недоліки, протокол UDP є ефективним для серверів, що надсилають невеликі відповіді великій кількості клієнтів. На рис. 1.1 розглянута структура пакету UDP.

Заголовок UDP складається з чотирьох полів, кожне по 2 байти (16 біт). Два з них необов'язкові до використання в IPv4 (рожеві осередки на рис.), в той час як в IPv6 необов'язковий тільки порт відправника.

Порт відправника. У цьому полі вказується номер порту відправника, на який, при необхідності, буде надсилатися відповідь. В іншому ж випадку, значення має бути рівним 0. Якщо хостом джерелом є клієнт, то номер порту буде, швидше за все, динамічним [17].

Рисунок 1.1 - Структура пакету UDP

Порт одержувача. Це поле обов’язкове і містить порт одержувача. Аналогічно порту відправника, якщо хостом одержувачем є клієнт, то номер порту динамічний, якщо одержувач сервер, то це буде відомий порт.

Довжина датаграми. Поле, що задає довжину всієї датаграми (заголовка і даних) в байтах. Мінімальна довжина дорівнює довжині заголовка 8 байт. Теоретично, максимальний розмір поля 65 535 байт для UDP датаграми (8 байт на заголовок і 65527 на дані).

Транспортний протокол RTP (Real-Time Transport Protocol), протокол який працює на прикладному рівні і використовується при передачі трафіку реального часу.

Протокол RTP переносить у своєму заголовку дані, необхідні для відновлення голосу та відео на приймальному вузлі, а також дані про тип кодування інформації (JPEG, MPEG і т. п.). В заголовку цього протоколу, зокрема, передаються мітка і номер пакету. Ці параметри дозволяють при мінімальних затримки визначити порядок і час декодування кожного пакета, а також інтерполювати втрачені пакети.не має стандартного зарезервованого номера порту. Єдине обмеження полягає в тому, що з'єднання проходить з використанням парного номера, а наступний непарний номер використовується для зв'язку з протоколом RTCP. Той факт, що RTP використовує динамічно назначаємо адреси портів, створює йому труднощі для проходження між мережевих екранів, для обходу цієї проблеми, як правило, використовується STUN-сервер. На рис. 1.2 представлений заголовок протоколу RTP.[18]

Рисунок 1.2 - Основний заголовок RTP

Фіксований RTP заголовок містить ряд полів, що ідентифікують такі елементи, як формат пакета, порядковий номер, джерела, межі та тип корисного навантаження. За фіксованим заголовком можуть слідувати інші поля, що містять додаткову інформацію про дані.

Поле версії (2біта). Поле де вказується версія протоколу.

Поле заповнення (1 біт). Це поле сигналізує про наявність заповнюють октетів наприкінці корисного навантаження. Заповнення застосовується, коли додаток вимагає, щоб розмір корисного навантаження був кратний.

Поле розширення заголовка (1 біт). Коли це поле задано, то за основним заголовком слід ще один додатковий, використовуваний в експериментальних розширеннях RTP.

Поле кількості відправників (4 біта). Це поле містить кількість ідентифікаторів відправників, чиї дані знаходяться в пакеті, причому самі ідентифікатори слідують за основним заголовком.

Поле маркера (1 біт). Сенс біта маркера залежить від типу корисного навантаження. Біт маркера використовується зазвичай для позначення меж потоку даних. У випадку відео він задає кінець кадру. У випадку голосу він задає початок розмови після періоду мовчання.

Поле корисного навантаження (7 біт). Це поле ідентифікує тип корисного навантаження і формат даних, включаючи стиснення і шифрування. У стаціонарному стані відправник використовує тільки один тип корисного навантаження протягом сеансу, але він може його змінити у відповідь на зміну умов, якщо про це сигналізує протокол управління передачею в реальному часі (Real-Time Transport Control Protocol).

Поле порядкового номера (16 біт). Кожне джерело починає нумерувати пакети з довільного номера, збільшується потім на одиницю з кожним посланим пакетом даних RTP. Це дозволяє виявити втрату пакетів і визначити порядок пакетів з однаковою відміткою про час. Декілька послідовних пакетів можуть мати одну і ту ж позначку про час, якщо логічно вони породжені в один і той же момент, як, наприклад, пакети, що належать до одного і того ж відеокадру.

Поле позначки про час (32 біта). Це поле містить момент часу, в який перший октет даних корисного навантаження був створений. Одиниці, в яких час вказується в цьому полі, залежать від типу корисного навантаження. Значення визначається по локальних годинах відправника.

Поле ідентифікатора джерела синхронізації (32 біта). Генеруючи випадковим чином число, унікальним чином ідентифікує джерело протягом сеансу і незалежне від мережевого адресу.

Список полів ідентифікаторів джерела (32 біта)

.5 Аналіз параметрів протоколів мережного рівня медіа систем

Для передачі інформації на мережному рівні взаємодіючих систем використовується протокол IP. Сьогодні діють четверта IPv4 та шоста IPv6 версія цього протоколу.

Основним завданням протоколу IР є здійснення передачі блоків даних (дейтаграм) від хоста відправника, до хоста призначення. Відправниками та одержувачами виступають обчислювальні машини, які однозначно ідентифікуються IP адресами фіксованої довжини (IPv4 - 32 біта, а в версії IPv6 -128 біт). Протокол IP здійснює, у разі потреби, фрагментацію даних для передачі їх через інші мережі з меншим розміром пакетів. Цей протокол використовує таблицю маршрутизації для передачі пакетів від відправника до одержувача. Кожен пакет, крім даних, містить в собі і заголовок. Формат заголовка пакету IPv4 представлений на рис. 1.3. [16]

Рисунок 1.3 - Формат заголовка IPv4

У полі версія (4 біта) вказується інформація про версію протоколу.

У полі довжина заголовка (4 біта) вказується обсяг IP пакета у 32 бітних словах. Це дозволяє визначити початок блока даних (payload) у пакеті. Мінімальне коректне значення для цього поля дорівнює п’яти бітовим словам.

Тип сервісу (8 біт). Перші три біта цього поля визначають пріоритет пакету й можуть мати значення від нуля до семи. Мережні пристрої в першу чергу обробляють пакети, з найвищим пріоритетом.

У полі довжина пакету (16 біт) вказується загальна довжина датаграми з урахуванням заголовка і поля даних. Обсяг пакету може сягати 65535 байт.

Поле ідентифікатор пакета (16 біт) - використовують для розпізнавання пакетів, що утворилися шляхом фрагментації вихідного пакета. Всі фрагменти повинні мати однакове значення цього поля.

Прапори - поле яке займає 3 біти. Перший біт повинен завжди дорівнювати нулю, другий біт визначає можливість фрагментації пакета, а третій біт показує, чи не є фрагмент останнім у ланцюжку фрагментів переданої датаграми.

За допомогою поля зміщення фрагмента (13 біт) визначають позицію фрагмента в потоці даних.

У полі кількість переходів (8 біт) задається максимальна кількість маршрутизаторів, які може пройти датаграма (або час життя пакету). При проходженні маршрутизатора значення цього поля зменшується на 1 і досягнувши значення 0, пакет знищується.

У полі протокол (8 біт) вказується ідентифікатор протоколу верхнього рівня, якому належить інформація розміщена в полі даних пакета.

Поле контрольна сума (16 біт) розраховується для усього заголовка і дозволяє визначити цілісність пакета.

Поле параметри (до 320 біт) використовують при налаштуванні мережі. В ньому може бути вказаний точний маршрут проходження пакету в розподіленій мережі, розміщені дані системи безпеки, а також різни часові помітки. Зазвичай заголовок містить 20 октетів, тобто має довжину 20 байт, але ця довжина може змінюватись, що аж ніяк не спрощує процес передачі даних.

Протокол IP не гарантує доставку пакетів. Тобто перед початком передачі не встановлюється з'єднання та не підтверджується доставка пакетів.

До недоліків протоколу IPv4 можна віднести:

дефіцит адресного простору, що обмежує кількість різних пристроїв, які підключаються до мережі Internet;

слабка розширюваність протоколу - розмір заголовка IPv4 не дозволяє розмістити необхідну кількість додаткових параметрів;

проблема безпеки комунікацій - не передбачено будь-яких засобів для розмежування доступу до інформації, розміщеної в мережі;

обмежена підтримка якості обслуговування - не дозволені розміщення інформації про пропускну здатність, затримку, яка необхідна для нормальної роботи деяких мережних додатків.

Також, відсутні деякі механізми, необхідні за сучасними мірками. Це механізми інформаційної безпеки та засоби підтримки класів обслуговування.

Для розширення адресного простору та задоволення сучасних вимог до IP мережі розроблено протокол IPv6, який описано в RFC 2460. Основні відмінності протоколу IPv6 від IPv4 у наступному.

Значно збільшено адресний простір. IPv6 піддержує приблизно 3,4*1038 адрес.

Спрощено заголовок пакета, зокрема:

- відсутня фрагментація пакета за замовчуванням;

поле TTL (Time to Live - час життя) замінено на поле Hop Limit (граничне число кроків);

відсутнє поле контрольної суми (Checksum). Для перевірки цілісності пакета використовується функція протоколу 4-го або 2-го рівня.

Поліпшені механізми автоматичного налаштування пристроїв. Вузол мережі може бути сконфігуровано автоматично при підключенні до мережі з IPv6 маршрутизацією за допомогою протоколу обміну повідомленнями IСМР версії IPv6.

Розширені можливості для підтримки аутентифікації користувачів, цілісності та конфіденційності даних, спрощена маршрутизація, поліпшені механізми забезпечення якості обслуговування(QoS).

Протокол IPv6 вирішує потенційну проблему нестачі IP адрес за допомогою використання 128-розрядних адрес замість 32-розрядних адрес IPv4, завдяки чому адресний простір розширюється в 296 разів. Формат основного заголовка протоколу IPv6 представлено на рис.1.4.

Рисунок 1.4 - Основний заголовок протоколу IPv6

Версія (4 біт) - поле де вказується версія протоколу.

Поле клас трафіку (8 біт) визначає пріоритет трафіку для забезпечення класу обслуговування QoS.

У полі мітка потоку (20 біт) вказується унікальне число, однакове для однорідного потоку пакетів. Якщо шлюз, що обробляє пакет помітив відхилення складу пакету від інших пакетів потоку, він генерує помилку потоку і повідомляє про це відправника. Інформація про потік на шлюзі зберігається протягом 6 секунд. Якщо за цей час через шлюз не пройде жодної дейтаграми потоку, ідентифікатор даного потоку звільняється. З іншого боку, хост відправника, у разі перезапуску (ініціалізації) вузла, не зможе раніше ніж через 6 секунд організувати новий потік.

У полі довжина корисного навантаження(16 біт) вказується обсяг даних пакета (в байтах), які слідують за заголовком.

Поле наступного заголовка (8 біт) містить інформацію про тип заголовка, який слідує за основним заголовком IPv6.

У полі кількість переходів (8 біт) вказується максимальна кількість маршрутизаторів, які може пройти пакет. Якщо це значення досягає 0, пакет знищується.

Поля IP адреса відправника і IP адреса одержувача мають однакову структуру й довжину, яка складає 128 біт [16].

.6 Аналіз параметрів протоколів канального рівня медіа систем

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

Мережна технологія - це набір стандартів, що визначає мінімальний склад програмно-апаратних засобів, достатній для організації взаємодії комп'ютерів в мережі. Як правило, мережева технологія визначає топологію мережі, а також протокол канального рівня (формат кадру, порядок обміну кадрами, MTU).

В даний час існує велика кількість мережних технологій канального рівня. Одна з найбільш популярних в даний час - технологія локальних мереж Ethernet. Технологія Ethernet використовує протокол <#"792084.files/image007.gif">

Рисунок 1.5 - Структура кадру Ethernet

Одним з перспективних напрямків побудови сучасної мережної інфраструктури бути використання оптичних технологій для організації високошвидкісної магістральної мережі та єдиної системи сигналізації, що дозволяє об’єднувати різні типи середовищ і систем передачі інформації. В якості такої об'єднуючої технології зараз розглядається технологія багато протокольної комутації по міткам (Multiprotocol label Switching, MPLS). MPLS являє собою механізм з високопродуктивної телекомунікаційної мережі, який здійснює передачу даних від одного вузла мережі до іншого за допомогою міток.дозволяє досить легко створювати віртуальні канали між вузлами мережі. Так само дана технологія дозволяє інкапсулювати різні протоколи передачі даних. Рішення про подальшу передачу пакету даних іншому вузлу мережі здійснюється тільки на підставі значення присвоєної мітки без необхідності вивчення самого пакета даних. За рахунок цього можливе створення наскрізного віртуального каналу, незалежного від середовища передачі і використовує будь-який протокол передачі даних. На рис. 1.6 представлений формат запису стека міток [2].

Рисунок 1.6 - Формат запису міток технології MPLS

Технологія MPLS основана на обробці заголовка MPLS, який додається до кожного пакету даних. Заголовок MPLS може складатися з однієї або кількох «міток». Кілька записів (міток) в заголовку MPLS називаються стеком міток. Кожен запис в стеку міток складається з наступних чотирьох полів:

значення мітки. Займає 20 біт;

поле класу трафіку (Traffic Class), необхідного для реалізації механізмів QoS (експериментальна підтримка) і явного повідомлення про перевантаження (Explicit Congestion Notification, ECN). Займає 3 біти;

прапор дна стеку (Bottom of stack). Якщо флаг встановлений, то це означає,що поточна мітка остання в стеці. Займає 1 біт;

поле TTL (Time To Live). Займає 8 біт.

1.7 Стислі висновки

Проаналізовані параметри та характеристики аудіо кодеків систем передачі медіатрафіку G.711, G.729, G.726, G.723.1, G.728. Зробивши висновок, можна сказати, що найкращий кодек є G.729, який має маленьку швидкість і високу якість, і помірна реалізація, з ним може конкурувати G.723.1 який має більшу затримку. Такий самий аналіз пророблений з відео стандарту Н.261, Н.263, Н.264, MPEG-1, MPEG-2, MPEG-4. Зробивши висновок, можна сказати що найкращий відео стандарт це MPEG-4, він є основним стандартом стиснення мультимедіа контенту, за допомогою нього практично всі сучасні фото та відеокамери знімають в HD-якості. Але від нього не відстають такі стандарти як Н.254, MPEG-1, MPEG-2.

Також в розділі розглянуті інформаційні характеристики та технології протоколів UDP та RTP який його підтримує. А для передачі інформації на мережному рівні взаємодіючих систем використовується протокол четвертої IPv4 та шостої IPv6 версії. Але в IPv4 адресний простір виснажений тому найбільш доцільно буде використовувати IPv6. Для збільшення продуктивності систем мережі в IP мережах використовується технологія MPLS та Ethernet.

Даний аналіз може бути використаний для аналізу інформаційної надлишковості.

2. АНАЛІЗ МАТЕМАТИЧНИХ МОДЕЛЕЙ ВЗАЄМОДІЇ МЕДІА СИСТЕМ

2.1 Постановка задачі

Мережі будуються за багаторівневим принципом. Для організації зв'язку необхідно спочатку розробити набір правил їх взаємодії, визначити мову їх "спілкування", тобто визначити зміст сигналів, що посилають комп'ютери. Ці правила та визначення називаються протоколом. Для коректної роботи мережі використовується цілий ряд протоколів: наприклад, протокол управління фізичним зв'язком, встановлення зв'язку в мережі, доступу до ресурсів, тощо. Багаторівневу систему було створено з метою спрощення і впорядкування такої величезної кількості протоколів та зв'язків.

Концепція багаторівневої моделі [International Organization for Standardization (ISO)] прийнято семирівневу еталонну модель взаємодії відкритих систем (ВВС) [Open System Interconnection (OSI)]. Вона відіграє визначальну роль у розвитку інфотелекомунікацій, оскільки дає можливість розробляти технології та мережеві продукти, що реалізують функції одного або декількох суміжних рівнів моделі не зачіпаючи функцій інших рівнів. Це дозволяє виробникам мережевих продуктів реалізовувати функції лише певних необхідних частин моделі, наприклад, фізичного рівня, фізичного і канального рівнів і т. п. Завдяки чому оператори зв'язку мають можливість будувати мережі, використовуючи спектр сумісних мережних продуктів різних рівнів моделі і різних виробників

При розробці окремих технологій здійснювалась декомпозиція рівнів та вводилися площини тому [5] запропонована узагальнена модель взаємодії відкритих систем яка моє виміри - рівні та площини.

Для розрахунку навантажень в каналах медіа систем необхідні математичні моделі взаємодії систем. Метою даного розділу є аналіз вербальних та математичних моделі взаємодії відкритих систем.

.2 Вербальні моделі взаємодії відкритих систем

Модель ISO\OSI було прийнято Міжнародним союзом електрозв'язку (МСЕ) [International Telecommunication Union (ITU)]. Розробка і широке використання моделі ВВС дозволили розв'язати найважливішу задачу, організувати взаємодію телекомунікаційного устаткування, створеного різними виробниками.

При розробці окремих технологій здійснювалась декомпозиція деяких рівнів. Наприклад, стандартами IEEE 802.x фізичний рівень подається у вигляді трьох підрівнів, а канальний - у вигляді двох. Іншу декомпозицію рівнів запропоновано при розробці технології АТМ. Така деталізація не порушує загальної стрункості та структури моделі ВВС. Усе залежить від розв'язуваної задачі забезпечення взаємодії відкритих систем, котрі реалізовують конкретну технологію.

Модель ISO стала вже окремим випадком. Це небажано. потрібна нова узагальнена модель, котра охопила б всі існуючі моделі і припускала їхній природний розвиток і декомпозицію. Однозначне проходження плоскої моделі ВВС не лише гальмує вивчення новітніх технологій, але й стає на перешкоді в їхньому розвитку, виявленні напрямів досліджень, усунення недоліків в існуючих технологіях.

При виборі рівнів у моделі ВВС насамперед виходили з функціонального призначення кожного рівня, тобто споріднені функції збиралися на одному рівні. При цьому вибір числа рівнів продиктовано розумним компромісом. Рівнів має бути достатньо, щоб кожний з них не був надто громіздким, а з іншого боку, рівнів не повинно бути надто багато, аби їхня інтеграція й описи в взаємодії не виявилися занадто складними. Такий самий підхід слід застосувати і при введенні площин. При цьому площини, в разі потреби, можуть поділятися на півплощини. Ведення площини визначається її функціональним призначенням.

Відзначимо ще одну особливість площин. Звернімося знову до моделі ВВС [5]. Відомо, що всі рівні моделі реалізовуються в термінальному устаткуванні. Мережне устаткування працює на чотирьох нижніх рівнях моделі. Тому площини можуть не містити всіх рівнів моделі ВВС.

Підсумовуючи й узагальнюючи відомі дані, розглянемо необхідні площини і їхнє функціональне призначення.

Площина користувача забезпечує транспортування даних користувача заданого чи будь-якого виду з заданою якістю обслуговування. Площина користувача може мати дві півплощини, півплощина термінального устаткування і півплощини мережного устаткування.

Площина сигналізації забезпечує встановлення, контроль і поділ з'єднання для технологій, що використовують попереднє встановлення фізичного чи віртуального з'єднання. Площина сигналізації притаманна, наприклад, телефонним мережам загального користування і мережам, працюючим за АТМ технологією. Площина сигналізації, за необхідності, може містити півплощини. Наприклад, півплощина контролю (Control), котра забезпечує встановлення з'єднання в мережному інтерфейсі і півплощина метасигналізаціі, вона забезпечує встановлення з'єднання в інтерфейсі користувач - мережа.

Площина маршрутизації забезпечує просування пакетів мережею від користувача до користувача. Для розв'язання цієї задачі необхідно мати адекватну інформацію про структуру і властивості мережі. Тому доцільно ввести півплощину збирання інформації про стан мережі. Така інформація зазвичай міститься в таблицях. Для автоматизованого складання таблиць розроблено протоколи маршрутизації. Найбільш відомі протоколи маршрутизації RIP (Ronting Information Protocol), OSPF (Open Shortest Path First) - відкритий протокол «найкоротший шлях першим». Для складання таблиць маршрутизації необхідно сформувати маршрутну інформацію, а потім передати її за призначенням, прийняти її і потім опрацювати. Тому потрібен стек протоколів. Наприклад, RIP, TCP, IP, Ethernet. Таким чином, виходячи з даного подання, RIP є протоколом прикладного рівня. В літературі протокол RIP часто відносять до мережного рівня. У кращому разі вводиться функціональна модель маршрутизатора.

Другою може бути півплощина автоматизованого процесу призначення логічних адрес. В мережі Internet - це IP адреси. Тут використовується протокол прикладного рівня Dynamic Host Configuration Protocol (DHCP).

Третьою може бути півплощина установлення відповідності між логічною і фізичною адресами портів (вузлів). Серед таких протоколів найбільш відомий є протокол розрізнення адреси Address Resolution Protocol (ARP).

Четвертою може бути півплощина установлення відповідності між символьними і логічними адресами. Тут існує кілька технологій, як для плоских у локальних мережах Novell Net Ware, Microsoft Windows, IBM OS/2, так і ієрархічних імен у глобальних мережах, де створюється спеціальна система доменних імен (Domain Name System, DNS).

Серед площин обов'язково має бути площина керування, коли одна підсистема керує іншою. Тут нас цікавлять протоколи, що описують взаємодію менеджер - агент. Стандарт керування в Internet базується на протоколі прикладного рівня SNMP - Simpl Network Management Protocol - простий протокол керування мережею. Протокол SNMP може працювати зі стеком протоколів TCP, UDP, IP чи IPX/SPX. У вже згадуваному стандарті ISO - OSI Management Framework - обмін керуючою інформацією уже відбувається між суб'єктами додатків керування системами [Systems Management Application Entities (SMAE)]. Прикладами SMAE є агенти і менеджери. Для обміну інформацією між додатками використовуються всі рівні моделі ВВС, утворюючи площину керування. У цьому стандарті протоколом прикладного рівня є загальний протокол інформації керування [Common Management Information Protocol (CMIP)]. Для обміну інформацією між функціональними блоками на нижніх рівнях моделі ВВС використовуються протоколи (інтерфейси) типів Q, F і Х. Якщо мати на увазі стандарти, розроблені ISO, то площина керування може розбиватися на півплощини, а саме:

Керування системами, коли керування здійснюється на сімох рівнях моделі ВВС;

Керування N-рівнем, коли керування здійснюється на одному чи декількох рівнях моделі ВВС;

Операцій N-рівня, коли керування здійснюється на основі керуючої інформації, що міститься в комунікаційних протоколах лише даного рівня.

Окремі функціональні задачі виконує система синхронізації. Тому необхідно також увести площину синхронізації, хоча вона і не охоплює всіх рівнів.

Однією з головних задач, розв'язуваних мережею зв'язку, є забезпечення безпеки інформації і якості обслуговування. З огляду на важливість даних задач слід в кожній площині виділити півплощини захисту інформації і якості обслуговування. Узагальнену модель взаємодії відкритих систем показано на рисунку 2.1.

Повернімося до семирівневої моделі ВВС. На кожнім рівні до даних, які необхідно передавати, додається інформація про даний рівень у заголовок пакета. Уся додаткова інформація належить до накладних витрат, що зменшує швидкість передавання корисної інформації. окрім цього, сьогодні існує проблема об'єднання мереж, що працюють за різними технологіями. Склалася термінологія «технологія А» поверх (over) «технології В». Наприклад, IP over АTМ, може бути і навпаки АTМ over IP.

2.3 Математичні моделі процесів інкапсуляції та передачі даних

В основі концепції взаємодії телекомунікаційних та інформаційних систем покладена семирівнева модель взаємодії відкритих систем (Open System Interconnection-OSI), яка стандартизована ITU- T. Для оптимальної взаємодії відкритих систем (ВВС) розробники окремих мережевих технологій, зокрема B - ISDN, ввели для структуризації функцій (протоколів) канального і фізичного рівнів поняття площин. Розроблено узагальнену модель ВВС, яка структурує функції взаємодії систем, як по рівнях, так і по площинах. Подальший розвиток моделі ВВС, більшою мірою стосується не вербального, а математичного опису взаємодії систем. Це опис виконано без деталізації функціональних перетворень переданих даних, що з одного боку робить його узагальнюючим, а з іншого боку вимагає в процесі аналізу та оптимізації взаємодії систем конкретизації перетворення функцій.

2.3.1 Узагальнена інформаційна модель взаємодії систем

Для математичного опису цих перетворень в [10] використані матричні рівняння. Ці рівняння застосовані для математичного опису кількісних змін інформації, що відбуваються при передачі та обробці даних відповідно з функціональним призначенням рівнів і площин моделі ВВС. Відповідно, що при русі даних "вниз" від сьомого рівня моделі ВВС до першого (режим передачі) відбувається збільшення кількості інформації, а при русі даних "вгору" від першого рівня до сьомого (режим прийому) - зменшення.

Об'єкти взаємодіючих інфокомунікаційних систем структуровані за N рівнями і підрівнями, а також по M площинах і півплощинах. Для опису процесу зміни кількості інформації об'єктами n-го рівня різних площин ВВС введена квадратна матриця  порядку М

.     (2.1)

Елементами матриці  є перетворення функції , яка описує перетворення даних(сигналів), які призводять до зміни кількості інформації, де. Стрілка у верхньому індексі функції означає, що перетворення виконуються при просуванні інформації від вищого рівня до нижчого рівня. Тому  - вектор-стовпець, елементи якого  відображають кількість інформації на виходах об'єктів k-х площин (півплощин) n-го рівня (підрівня) ВВС, .

Якщо відомий вектор, що описує кількість інформації на виходах М об'єктів n+1рівня моделі ВВС, в також квадратна матриця  транспонована до вихідної матриці  (2.1), то легко знайти вектор  кількості інформації на виходах М об'єктів n-го рівня

. (2.2)

Тут за нульовий рівень (n=0) приймає середу передачі.

У загальному випадку зв'язок між кількістю інформації на виходах М об'єктів n-го і m+1 рівнів моделі ВВС може бути отримана при рекурентному використанні матричного рівняння (2.2) і властивості асоціативності матриць

,        (2.3)

Де mn. Якщо m=n то формула (2.3) збігається з (2.2).

Переймаючись в рівнянні (2.3) значеннями n і m отримаємо всілякі варіанти, математичного опису зміна кількості інформації, які можуть зустрічати при аналізі та оптимізації, як внутрішньо системних, так і міжсистемних взаємодій об'єктів.

Спрощення матричних рівнянь. Між об'єктами n-го рівня різних площин системи можуть бути відсутні взаємні зв'язки. У цьому випадку елементи, які не належать головній діагоналі матриці  і , будуть нульовими. В результаті матричні рівняння значно спрощуються. Наприклад, рівняння (2.3) описують зміну кількості інформації між рівнями m і n передавальної системи, за відсутності зв'язків між об'єктами різних площин прийме вигляд

Формування перетворюють функції. Для оцінки кількості інформації n рівневими об'єктами ВВС необхідно сформувати матрицю перетворення функцій. Обмежимося моделлю ВВС, у якої відсутні зв'язки між об'єктами різних площин. Розглянемо просування інформації від верхніх рівнів моделі ВВС до нижніх. Нехай, наприклад, на вхід об'єктів n-го рівня k-тoй площині надходить деяка кількість інформація . Необхідно оприділити кількість інформації  на виході цих об’єктів.

Припустимо, що інформація передається блоками, а кількість інформації в кожному з них задається щільністю ймовірності появи блоку даних заданого обсягу p=f(I). Нехай середній обсяг блоку даних на n-му рівні дорівнює математичному очікуванню кількості інформації.

Розглянемо випадки, коли об’єкти n-го рівня системи, в залежності від свого функціонального призначення можуть:

не змінювати інформаційних характеристик блоку даних;

- збільшувати кількість інформації в блоках даних на величину ;

виконувати фрагментацію (сегментацію) блока (потоків) даних і доповнювати (сегменти) управляючою інформацією .

В першому випадку матрицю  перетворюючих функцій доцільно описувати одиничною матрицею.

В останньому більш загальному випадку кількість фрагментів . залежить від обсягу даних вступників на вхід об'єкта n-го рівня і використовуваних мережевих технологій передачі даних, що визначають значення

,      (2.5)

де  - кількість інформації в максимальної одиниці передачі даних (Maximum Transmit Unit - MTU), (*) - операція округлення числа до великого цілого значення.

З врахуванням (2.5) найдемо кількість інформації в переданому повідомленні, фрагментованому на  блоків, на виході об’єкта n-го рівня k плоскості

.         (2.6)

З формули (2.6) знайдемо коефіцієнт збільшення кількості інформації на виході об'єктів n-го рівня k-тий площині.

.       (2.7)

Перетворюючі функції  за відсутності зв'язків між об'єктами різних площин збігаються з числовими коефіцієнтами , які більше або рівні одиниці, тобто

кодек аудіо відео протокол

.  (2.8)

Запропонована математична модель, що описує кількісні зміни інформації на кожному рівні і площини узагальненої моделі ВВС, може бути використана:

При структуруванні процесів моделювання та оптимізації взаємодії засобів і систем інфотелекомунікацій;

Для порівняльної оцінки інфокомунікаційних технологій, наприклад, за критерієм пропускної спроможності;

При аналізі інформаційних характеристик взаємодіючих систем під впливом перешкод;

При вирішенні завдань оптимізації взаємодії відкритих систем.

2.3.2 Моделювання процесів формування службової інформації та інкапсуляції даних

Розглянута віще узагальнена інформаційна модель [7] не враховує процедури вирівнювання обсягів даних і агрегатування пакетів, а сегментація даних розглядалася для окремого випадку.

Розглянемо основні протокольні процедури перетворення даних у взаємодіючих системах мереж з комутацією пакетів, які призводять до зміни обсягів переданої інформації.

Формування заголовків пакетів. Однією з протокольних процедур являється формування службових даних в заголовках і кінцевих пакетах передаючої системи. Кількість  службової (керуючої) інформації, формованої в пакеті на n-м рівні (підрівні) системи, залежить від вида керуючої функції  протокола цього рівня (підрівня) і сукупністю параметрів тих процедур,тобто

, ,  (2.9)

де  - кількість інформації, надходить з виходу (n+1)-го рівня (підрівня) на вхід n- го рівня (підрівня) системи; - вектор параметрів процедур протоколу, наприклад адресації, комутації, контролю, пріоритетної обробки, вирівнювання, агрегатування, сегментації, а також стиснення даних; N - кількість рівнів (підрівнів) системи.

Виконавши перетворення(2.9), легко визначимо кількість інформації на виході n-го рівня (підрівня) системи

, .  (2.10)

Багато протоколів системи, обробляючи дані, що не перетворюють їх, а лише формують і додають до них службову інформацію. У цьому випадку формула (2.10) спрощується, а значення  можна знайти за відомим форматом полів номінального (nominal) функціонально необхідного заголовка (heading) і кінцевика протоколу

, ,  (2.11)

Де ,   (2.12)

 і  відповідно сумарний обсяг, і обсяг i-тих полів номінального функціонально необхідного заголовка протоколу n-го рівня (підрівня) системи;   - кількість полів номінального заголовка протоколу n-го рівня (підрівня) системи.

З вищевикладеного випливає, що величина, формована на, n-ному рівні передаючої системи може бути більше нулю, або дорівнювати нулю, а в деяких випадках (стиснення, кодування інформації) - менше нуля.

Інкапсуляція даних. Розглянемо процес перетворення інформації, зокрема зміни її обсягів, між рівнями (підрівнями) m і n передавальної системи, де m>n Застосовуючи формулу (2.12) для рівнів (підрівнів) n+1,n+2,…,m і виконуючи рекурентні підстановки, знайдемо кількість інформації  на виході n-го рівня (підрівня) системи

, ,          (2.13)

де  - кількість інформації, надходить з виходу рівня (підрівня) m +1 на вхід рівня (підрівня) m;   - сумарна кількість службової інформації в блоці даних, що формується модулями комунікаційних протоколів, які функціонують між рівнями (підрівня) m і n

, .  (2.14)

Вважаючи в (2.14) m = N, а n = 1, можна визначити загальний обсяг службової інформації в блоці даних користувача на виході системи.

Розглянута модель процесів формування службової інформації враховує основні процедурні особливості, характерні для широкого спектра протоколів мереж з комутацією пакетів. Зокрема, це формування і вирівнювання обсягів протокольних заголовків і/або даних, інкапсуляція і агрегатування пакетів, сегментування даних.

Використання запропонованої моделі дає можливість надалі :

Проводити дослідження співвідношень між обсягами службової та інформації користувача для широкого спектра протоколів мереж з комутацією пакетів;

Вибирати оптимальні стеки протоколів систем, застосовуючи як критерію, наприклад, мінімум обсягу службових даних (максимум ефективності за пропускної спроможності);

2.4 Стислі висновки

При розробці окремих технології відбувалася декомпозиція рівнів та в водилися площини Проаналізувавши математичні моделі взаємодії систем, також розглянувши моделі процесів формування службової інформації врахувавши основні процедурні особливості, характерні для широкого спектра протоколів мереж з комутацією пакетів. Результати можуть бути використані для аналізу надлишкової інформації. Розроблена математична модель, що описує кількісні зміни інформації на кожному рівні і площині узагальненої моделі ВОС, може бути використана:

При структуруванні процесів моделювання та оптимізації взаємодії засобів і систем інфотелекомунікацій ;

Для порівняльної оцінки інфокомунікаційних технологій, наприклад, за критерієм пропускної спроможності;

При аналізі інформаційних характеристик взаємодіючих систем під впливом перешкод;

3.1 Постановка задачі

Однією із практичних задач вирішуваних при передачі медіатрафіку в ІР мережах є обґрунтування та вибір достатньої пропускної здатності каналу зв’язку. При цьому необхідно враховувати, що частина пропускної здатності каналу зв’язку буде витрачатись на передачу службової інформації протоколів взаємодіючих ІР систем, яку вважають надлишковою по відношенню до інформації додатків користувача.

Метою даного розділу є аналіз інформаційної надлишковості пакетів медіатрафіку в каналах взаємодіючих ІР систем.

Важливими етапами дослідження інформаційної надлишковості пакетів медіатрафіку є застосування математичних моделей оцінки обсягів інформації при інкапсуляції пакетів, аналіз обсягів службової (технологічної) інформації ієрархічних сполучень протоколів ІР систем та формування критерію оцінки інформаційної надлишковості пакетів медіа даних.

3.2 Аналіз обсягів службової інформації протоколів ІР систем передачі медіатрафіку

Комунікаційні протоколи ІР систем відповідно до функцій n-рівневих об’єктів моделі взаємодії відкритих систем OSI мають забезпечити передачу даних у мережі. Ефективність передачі даних при взаємодії цих систем залежить від застосовуваних стеків комунікаційних протоколів, використовуваних мережних технологій, обсягів пакетів з користувальницькими даними, інформаційної надлишковості заголовків цих протоколів тощо.

Розглянемо процедури формування обсягів службової інформації протоколів системи. Об’єкт комунікаційного протоколу і-го рівня/підрівня відкритої системи у процесі формування пакета до інформації отриманої від протоколу (і+1)-го рівня/підрівня додає службову (керуючу) інформацію, обсягом . У загальному випадку, процедура формування обсягу  технологічної інформації комунікаційним протоколом і-го рівня/підрівня відкритої системи може складатися з формування:

основного (basic) заголовка й кінцевика обсягом ;

добавленого (adding) заголовка обсягом ;

розширеного (extension) заголовка обсягом ;

технологічного доповнення (padding) обсягом  в процесі вирівнювання заголовка чи даних тощо.

Тобто, загальний обсяг  технологічної інформації в пакеті даних протоколу і-го рівня/підрівня системи може складатися з зазначених вище обсягів

, . (3.1)

Обсяг інформації у заголовках протоколу і-го рівня/підрівня системи можна знайти за сумою обсягів інформації в присутніх j-х полях цих заголовків, наприклад для основного (базового) заголовка

, .       (3.2)

Для розрахунку обсягу сумарної кількості керуючої (технологічної) інформації транспортних технологій і протоколів для взаємодії систем та передачі даних використаємо розглянуту в другому розділі математичну інформаційну модель інкапсуляції пакетів [6].

У процесі інкапсуляції даних протоколом m-го рівня/підрівня системи необхідно враховувати значення максимальної одиниці передачі даних MTU (Maximum Transmission Unit) протоколу n-го рівня/підрівня. Використовуючи інформаційну модель інкапсуляції (2.13) можна розрахувати значення MTU пакета протоколу m-го рівня/підрівня системи за формулою:

, , (3.3)

де  - значення MTU протоколу n-го рівня/підрівня системи; -сумарна кількість службової інформації в пакеті між рівнями/підрівнями m та n+1 системи.

Параметр (3.3) визначає максимальну кількість корисної інформації у одному пакеті, яку можуть переносити комунікаційні протоколи між рівнями/підрівнями m та n системи.

Виконаємо аналіз обсягів службової інформації протоколів медіа систем. Для розрахунку обсягів  службової інформації, яку формують об’єкти i-х рівнів/підрівнів протокольної моделі OSI розглянемо формати заголовків пакетів, кадрів розглянутих у першому розділі сучасних транспортних технологій та протоколів медіа систем.

Не залежно від швидкості передачі технології Ethernet використовують практично однакові типи МАС (Media Access Control) кадрів [2]. Кадр підрівня МАС стандарту ІЕЕЕ 802.3 утримує 5 полів: адреса призначення DA (Destination Address) та адреса джерела SA (Source Address) по 6 байт; тип протоколу чи довжина даних T/L (2 байта); дані обсягом від 0 до  = 1500 байт; послідовність контролю кадру FCS (Frame Check Sequence) обсягом 4 байта. Якщо обсяг даних менше 46 байт, то за допомогою поля Padding обсяг поля даних доповнюється довільними бітами до 46 байт. За формулами (3.1), (3.2) визначимо обсяг службової інформації МАС кадру Ethernet: , де = 18 байт, а 046 байт.

Для півдуплексного режиму в мережі Gigabit (GbE) Ethernet з максимальним діаметром 200 м обсяг мінімального МАС кадру  = 64 байта доповнюється до 512 байт за рахунок заборонених символів коду 8В/10В у полі розширення (Extention). В цьому випадку обсяг керуючої та технологічної інформації МАС кадру даних технології GbE складатиметься з обсягів: , де 0448 байт.

На фізичному рівні технології Ethernet формуються два поля заголовка: обмежувач початку кадру SFD (Start of Frame Delimiter) 1 байт та преамбула (Preamble) 7 байт. Між кадрами Ethernet при їх послідовній передачі дотримується певна технологічна часова пауза IPG (Inter Packet Gap), протяжність якої еквівалентна передачі 12 байт інформації [2]. Обсяг заголовка фізичного рівня технології Ethernet разом з паузою IPG складає = 20 байт. При інкапсуляції кадру Ethernet в контейнер SDH заголовок фізичного рівня відкидається.

Клин-заголовок технології MPLS для однієї позначки утримує 4 поля: ідентифікатор значення позначки 20 біт, резерв для досліджень та диференціювання класу обслуговування QoS (Quality of Service) 3 біта, ідентифікатор дна стека позначок 1 біт, час життя ТТL (Time to Live) 8 біт. При створенні додаткових lт тунелів в LSP тракті обсяг клин-заголовка MPLS збільшується в lт раз. Отже, керуюча й технологічна інформації клин-заголовка протоколу MPLS складатиметься з обсягів: , де =4 байта;  байт, lт = {1, 2, …}.

Пакет протоколу UDP утримує 5 полів [16]: ідентифікатори портів джерела SP (Source Port) та призначення DP (Destination Port) по 2 байта, поле довжини (Length) датаграми 2 байта, контрольної суми (Checksum) 2 байта, яка розраховується для псевдозаголовка та поле даних обсягом , де  - значення MTU протоколу мережного рівня. Обсяг заголовка UDP складатиме 8 байт.

Пакет протоколу RTP утримує 8 полів основного заголовку обсягом 12 байт, додаткового заголовку, який утримує  ідентифікаторів CSRC сприяючих джерел, чиї дані присутні в корисному навантаженні та розширеного заголовку, який складається з ідентифікаторів профілю навантаження і довжини EHL розширення заголовку по 16 біт та технологічних даних розширеного заголовку, обсягом кратним 32 біт. Загальний обсяг службової інформації протоколу RTP складається з обсягів: , де = 12 байт,  байт, ,  байт.

Пакет протоколу ІРv.4 утримують поля: основного заголовка загальним обсягом 20 байт, розширеного заголовка до 40 байт, вирівнювання розширеного заголовка та дані змінного обсягу . Для протоколу ІРv.4  байт [16]. Практично обсяг даних протоколу ІРv.4 обмежується значенням MTU протоколу канального рівня, тобто . Заголовок протоколу ІРv.4 складатиметься з таких обсягів керуючої й технологічної інформації: , де = 20 байт,  байт, .

Пакет протоколу ІРv.6 утримує поля: основного заголовка загальним обсягом 40 байт, додаткові заголовки змінних чи фіксованих обсягів, наприклад фрагментації (64 біт), аутентифікації (variable, біт) тощо та дані змінного обсягу. Обсяг заголовка ІРv.6 складатиме , де = 40 байт, .

Результати аналізу обсягів службової інформації заголовків протоколів та значення обсягів даних для розглядуваних вище транспортних технологій медіа систем зведено у табл. 3.1.

Таблиця 3.1 - Обсяги інформації протоколів та транспортних технологій

3.3 Критерії оцінки надлишкової інформації протоколів медіа систем

Інформаційну надлишковість стека протоколів систем комутації пакетів оцінюють за допомогою абсолютних та відносних критеріїв:

 - сумарний обсяг службової інформації в пакеті між протокольними підрівнями m та n системи, де ;

 - коефіцієнт зміни кількості інформації між підрівнями m та n системи, який визначають за відношенням ;

 - коефіцієнт додаткових інформаційних втрат, який визначають за відношенням  [8];

 - коефіцієнт надлишкової інформації, який вказує на частку службової інформації в інформаційному пакеті між протокольними підрівнями m та n системи [8].

У подальших дослідженнях для оцінки інформаційної надлишковості стеків протоколів системи будемо використовувати відносний критерій - коефіцієнт надлишкової інформації у пакеті

, .       (3.4)

Критерій (3.4) оцінки інформаційної надлишковості стеків протоколів системи зв’язаний з критеріями  та  простим співвідношенням

, .      (3.5)

3.4 Дослідження інформаційної надлишковості медіа пакетів взаємодіючих ІР систем

.4.1 Аналіз обсягів службової інформації протоколів у медіа пакетах

Для передачі медіатрафіку на прикладному рівні взаємодіючих систем застосовують протокол RTP. Пакети протоколу RTP інкапсулює протокол UDP. Міжмережна взаємодія систем базується на протоколі ІР (Internet Protocol) четвертої IPv4 або шостої IPv6 версій. В фізичних каналах систем комутації пакетів можуть використовувати протоколи технології GbE тощо. Для підвищення продуктивності передачі медіа даних на магістральних ділянках ІР мережі застосовують технологію комутації за позначками MPLS.

Таким чином взаємодію медіа додатків систем в ІР мережі можуть забезпечувати ієрархічні комбінації протоколів, зокрема, RTP/UDP/ІР/GbE. При застосуванні технології MPLS ієрархія протоколів дещо збільшується RTP/UDP/ІР/MPLS/GbE, але маршрутизатори MPLS оброблюють у пакеті заголовки протоколів нижніх рівнів, тобто заголовки MPLS/GbE.

Інформаційний блок даних (пакет, кадр) будь-якої медіа системи складається з інформації кодера (coder), обсягом  та службової інформації у заголовках комунікаційних протоколів системи (system), обсягом, . З урахуванням цих позначень формула (3.4) матиме вигляд

.       (3.6)

Використовуючи дані табл. 3.1 розрахуємо обсяги службової інформації протоколів відкритої системи у медіа пакеті. Результати розрахунків подані в табл. 3.2. Значення  відповідають застосуванню протоколів RTP, ІРv4 та ІРv6 з мінімальними обсягами заголовків. Зауважимо, що пакети технології GbE канального рівня (k = 2), можуть переносити змінні обсяги інформації, але не більше ніж =1500 байт.

Таблиця 3.2 - Обсяги службової інформації протоколів у медіа пакетах

3.4.2 Дослідження надлишкової інформації аудіо пакетів

Для накопичення відліків аудіо кодером потребується затримка передбачення (look-ahead) , та затримка алгоритму кодування . Тому затримка кадру аудіо кодера  є сумою цих затримок [8]

.       (3.7)

Обсяг даних аудіо кодера  у медіа пакеті пропорційний швидкості кодування відліків голосового сигналу  та часу їх кодування

,       (3.8)

У ІР системах для передачі голосу використовують рекомендовані ITU-T аудіо кодеки G.711, G.726, G.723.1, G.729. Результати розрахунків обсягу даних  розглянутих вище аудіо кодерів у медіа пакетах представлені в табл. 3.3.

Використовуючи обсяги службової інформації протоколів системи  (табл. 3.2) та обсяги даних аудіо кодерів  (табл. 3.3) за формулою (3.6) розрахуємо коефіцієнт надлишкової інформації  аудіо пакетів на виході ТСР/ІР систем.

Таблиця 3.3 - Інформаційні параметри аудіо кодеків

Тип аудио кодера               Алгоритм кодирования   ,

кбіт/с,

мс,

мс,

мс,

Результати розрахунків надлишкової інформації  в аудіо пакетах на виході медіа систем представлені в табл. 3.4.

Таблиця 3.4 - Коефіцієнт надлишкової інформації аудіо пакетів

3.4.3 Дослідження надлишкової інформації відео пакетів

Виконаємо аналіз інформаційних параметрів цифрових відео кодеків медіа систем. В якості прикладу розглянемо відео кодек H.264/MPEG-4 Part 10 або AVC (Advanced Video Coding). Цей кодек використовує формат стиснення відео, який даний час є одним з найбільш часто застосовуваних форматів для запису, стиснення і розподілу відеоконтенту. Він містить ряд нових функцій, які дозволяють йому стискати відео набагато ефективніше і забезпечити більшу гнучкість для застосування в найрізноманітніших мережних середовищах.

При кодуванні кадру відео кодеком H.264/AVC виділяються та кодуються макроблоки (macroblock) зображення обсягом 16x16 виборок (пікселів). Кількість макроблоків  у кадрі зображення залежить від кількості пікселів у кадрі (frame)  тобто екранного розширення та кількості пікселів  у макроблоці

.    (3.9)

Максимальна кількість макроблоків, що передається за секунду  пропорційна частоті зміни кадрів

.       (3.10)

Кількість інформації у макроблоці відео кодера  пропорційна кількості пікселів у макроблоці  та кількості біт , якими кодується піксель зображення

.       (3.11)

Стандарт H.264/MPEG-4 Part 10 визначає комплекти можливостей, які називають профілями, що орієнтовані на конкретні класи додатків, наприклад:

-  BP (Baseline Profile) базовий профіль - застосовується в недорогих продуктах, що вимагають додаткової стійкості до втрат (відео конференції, мобільні продукти);

-       ХР (Extended Profile) розширений профіль - призначений для потокового відео, маєс відносно високий ступінь стиснення і додаткові можливості для підвищення стійкості до втрати даних;

-       МР (Main Profile) основний профіль - застосовується для цифрового телебачення стандартної чіткості в трансляціях, що використовують стиснення MPEG-4 відповідно до стандарту DVB;

-       НіР (High Profile) високий профіль - є основним для цифрового мовлення та відео на оптичних носіях, особливо для телебачення високої чіткості. Використовується для Blu-Ray відеодисків і DVB HDTV мовлення;

-       Hі10P (High 10 Profile) високий профіль 10 - додатково підтримує 10-бітову глибину кодування зображення.

В таблиці 3.6 представлений деякі стандартизовані рівні з максимальними параметрами [20]. Рівнем називають певний набір обмежень, що вказують ступінь необхідної продуктивності декодера для профілю. Підтримка рівня й профілю для застосування в декодері вказує на максимальне екранне розширення зображення, частоту кадрів, швидкість відео потоку, максимальну ємність буфера декодованого зображення DPB (Decoded Picture Buffer), що зберігає кадри для забезпечення передбачення значень вибірок в інших картинах. Декодер, який відповідає певному рівню, повинен декодувати всі потоки бітів, які кодуються для цього рівня та для всіх нижчих рівнів.

Таблиця 3.5 - Рівні з максимальними параметрами відео кодерів

  за секунду           у кадрі  ВР, ХР, МР          НіР         Ні10Р    ,

піксель,

Максимальна швидкість передачі відео потоку для базових BP, розширених ХР і основних МР профілів декодера відповідно в 1.25 та 3 рази менша ніж для високих профілів НіР та Hi10P.

Максимальну ємність буфера кадрів декодованого зображення DPB обчислюють таким чином [20]

= min(floor(MaxDpbMbs /(PicWidthInMbs * FrameHeightInMbs)), 16),

де MaxDpbMbs є постійною величиною, яка залежить від номера рівня (табл. 3.7), PicWidthInMbs і FrameHeightInMbs є ширина і висота зображення для кодованих відеоданих, виражена в одиницях макроблоків (округлюється до цілих значень).

Таблиця 3.6 - Залежність MaxDpbMbs від рівня кодера H.264/AVC

Наприклад, для зображення 320×240 пікселів PicWidthInMbs = 320/14 = 20, а FrameHeightInMbs = 15. Для рівня 1.2 декодера максимальна ємність буфера декодованого зображення - floor(2376/(20 * 15)) = 7 кадрів,

Використовуючи характеристики відео кодека H.264/AVC (табл. 3.6), за формулою (3.11) визначимо обсяг даних відео кодера  у медіа пакеті. Результати розрахунків обсягу медіа даних  відео кодека H.264/AVC для розглянутих вище профілів представлені в табл. 3.7.

Таблиця 3.7 - Інформаційні параметри профілів відео кодека H.264/AVC

Результати розрахунків інформаційної надлишковості відео пакетів у каналах ІР систем, які генерують відео кодеки H.264/AVC розглянутих вище профілів приведені в табл. 3.8.

Таблиця 3.8 - Інформаційна надлишковість пакетів кодека H.264/AVC

3.4.4 Аналіз інформаційної надлишковості медіа пакетів

За результатом дослідження інформаційної надлишковості аудіо пакетів взаємодіючих ІР систем для розглянутих вище стеків протоколів та аудіо кодеків можна зробити наступні висновки.

Найбільшою інформаційною надлишковістю володіють голосові пакети, що генеруються кодеком G.726 (32 кбіт/с), а найменшою - G.723.1 (5,3 кбіт/с) (рис. 3.1).

Використання протоколу ІРv6 замість ІРv4 призводить до збільшення коефіцієнта надлишковості аудіо пакета. Зокрема, при використанні технології GbE та кодека G.723.1 (5,3 кбіт/с) інформаційна надлишковість ІРv6 аудіо пакета збільшиться на 0,83%.

Для мінімізації надлишковості переданої голосової інформації системи ІР телефонії доцільно налаштовувати із застосуванням низько швидкісного кодека G.723.1, який агрегує голосові відліки в кадри.

Інформаційна надлишковість аудіо пакетів ІР телефонії у каналах домену з MPLS технологією дещо збільшується. Зокрема, при використанні технології MPLS та протоколу ІРv4 інформаційна надлишковість аудіо пакета кодека G.723.1 (5,3 кбіт/с) збільшиться на 1,04%.

Рисунок 3.1 - Коефіцієнт інформаційної надлишковості аудіо пакетів

За результатом дослідження інформаційної надлишковості відео пакетів, які формуються кодеком H.264/AVC та інкапсулюються вище розглянутими протоколами ІР систем можна зробити наступні висновки.

Відео пакети ІР систем мають значно нижчу інформаційну надлишковість (11…15%) у порівнянні з аудіо пакетами (73…99%).

Використання протоколу ІРv6 замість ІРv4 для передачі відео пакета приводить до збільшення коефіцієнта надлишковості медіа пакета. Зокрема, при використанні технології GbE та кодека H.264/AVC інформаційна надлишковість ІРv6 відео пакета збільшиться на 2,97% (рис. 3.2).

Використання технології MPLS дещо збільшує інформаційну надлишковість аудіо пакетів ІР телефонії. Зокрема, при використанні технології MPLS та протоколу ІРv4 інформаційна надлишковість відео пакета кодека H.264/AVC збільшиться на 1,21%.

Рисунок 3.2 - Коефіцієнт інформаційної надлишковості відео пакета H.264/AVC

3.5 Стислі висновки

Проведені дослідження інформаційної надлишковості стеків протоколів систем ІР телефонії. Проаналізувавши можна сказати що найбільшою інформаційною надлишковістю володіють голосові пакети, що генеруються кодеком G.726 а найменшою - G.723.1.

За результатом дослідження інформаційної надлишковості відео пакетів, які формуються кодеком H.264/AVC і зробивши аналіз можна сказати що відео пакети ІР систем мають значно нижчу інформаційну надлишковість у порівнянні з аудіо пакетами.

Для оцінки інформаційної надлишковості стеків протоколів доцільно використовувати критерій - коефіцієнт надлишкової інформації у пакеті.

4. АНАЛІЗ НАВАНТАЖЕНЬ В КАНАЛАХ СИСТЕМ ПЕРЕДАЧІ МЕДІАТРАФІКУ

4.1 Постановка задачі

Ефективна передача медіа даних в ІР мережі потребує забезпечення балансу між завантаженістю ресурсів мережі та якістю обслуговування. Для вирішення цієї проблеми використовують різні засоби та механізми запобігання перевантажень в ІР мережі, зокрема, динамічна оптимізація шляхів передачі трафіку, застосування ефективних методів комутації пакетів та алгоритмів керування чергами в вузлах мережі, використання механізмів фрагментації пакетів тощо. Тому важливим є проведення досліджень навантажень в каналах взаємодіючих систем, зокрема, при передачі голосових та відео кадрів.

Метою даної роботи є аналіз навантажень в каналах взаємодіючих систем при передачі даних кодеків ІР телефонії.

4.2 Параметри та критерії оцінки навантажень медіа потоків

Основними параметрами, які впливають на трафік медіа потоків є кількість корисної інформації аудіо та відео кодера , кількість службової інформації протоколів медіа системи , продуктивність кодера , швидкість швидкістю кодування інформації кодером  та швидкість передачі інформації медіа пакетів на виході системи .

Продуктивність відео кодера  при відсутній агрегації макроблоків у медіа пакет визначають за формулою (3.10), тобто .

Продуктивність аудіо кодера  при відсутній агрегації голосових кадрів у медіа пакет визначають за швидкістю кодування  голосової інформації та кількістю інформації  у голосових кадрах кодера [9]

.     (4.1)

При агрегації  кадрів кодера в медіа пакет продуктивність генерування кодером агрегатних медіа пакетів  зменшується, а кількість інформації у агрегатному медіа пакеті кодера  збільшується [9]

,      (4.2)

. (4.3)

Кількість інформації на виході системи, яка передається у  агрегатних медіа (аудіо та відео) пакетах за інтервал часу Т (звичайно Т = 1 с) визначимо за формулою [10]

.      (4.4)

Використовуючи формулу (4.4) та вважаючи що кількість агрегатних медіа пакетів, які генерує кодер за термін часу Т пропорційна продуктивності кодера, тобто Т, знайдемо швидкість передачі інформації медіа пакетів на виході системи

,         (4.5)

де  - швидкість передачі службової інформації медіа пакету на виході системи

4.3 Аналіз продуктивності системи при передачі медіатрафіку

Продуктивність медіа системи залежить від продуктивності медіа (аудіо, відео) кодеків і не залежить від застосовуваних транспортних протоколів. Використовуючи формулу (4.2) проведемо аналіз продуктивності системи при передачі агрегатних голосових та відео пакетів.

Результати розрахунків продуктивності системи при передачі аудіо трафіку у залежності від кількості голосових кадрів в агрегатному аудіо пакеті представлені в табл. 4.1.

Таблиця 4.1 - Продуктивність системи при агрегації g голосових кадрів

Агрегація голосових кадрів більш ефективна для високошвидкісних кодерів. Зокрема, при агрегації 100 кадрів кодера G.711 у пакет продуктивність системи зменшується до 80 пак/с, а затримка збільшується до 12,5 мс, що не перевищує продуктивності та затримки кодера G.729 при відсутній функції агрегації кадрів. При агрегації голосових кадрів аудіо кодерів G.729 та G.723.1 у пакет через збільшення затримки агрегації пакету варто обмежити кількість агрегатних кадрів у пакеті значеннями g = 10 та g = 4 відповідно (рис. 4.1).

Рисунок 4.1 - Продуктивність системи при агрегації g голосових кадрів

Результати розрахунків продуктивності медіа системи з відео кодеками H.264/AVC у залежності від кількості макроблоків в агрегатному відео пакеті представлені в табл. 4.2.

Таблиця 4.2 - Продуктивність системи з відео кодеками H.264/AVC при агрегації g макроблоків у відео пакет

Продуктивність відео системи при агрегації g макроблоків відео кадру кодера у пакет зменшується (рис. 4.2). Але через збільшення обсягу пакету та затримки агрегації пакету необхідно обмежити кількість агрегатних макроблоків кодера H.264/AVC у відео пакеті.

Рисунок 4.2 - Продуктивність системи при агрегації g відео кадрів

4.4 Аналіз навантажень в каналах взаємодіючих ІР систем при передачі медіатрафіку

.4.1 Дослідження швидкості передачі агрегатних аудіо пакетів

Використовуючи формулу (4.5) проведемо аналіз швидкості передачі  агрегатних аудіо пакетів у каналах ІР систем в залежності від кількості голосових кадрів у агрегатних голосових пакетах. Результати розрахунку з швидкості передачі голосових пакетів у каналах ІР(/MPLS)/GbE систем представлені в табл. 4.3.

Таблиця 4.3 - Швидкість передачі агрегатних аудіо пакетів

Проведемо дослідження швидкості передачі  агрегатних відео пакетів кодеків H.264/AVC у каналах ІР систем в залежності від кількості макроблоків у агрегатних відео пакетах. Результати розрахунку з швидкості передачі відео пакетів у каналах ІР(/MPLS)/GbE систем представлені в табл. 4.4.

Для розрахунку таблиці 4.4 для рівнів кодека використали профілі ВР, (базовий профіль), ХР (розширений профіль), МР (основний профіль) Для рівня 1 (64кбіт/с), для рівня 1.1 (192 кбіт/с) і для рівня 1.2 (384 кбіт/с).

Таблиця 4.4 - Швидкість передачі агрегатних відео пакетів кодека H.264

4.4.2 Аналіз навантажень в каналах ІР систем при передачі медіатрафіку

За рахунок наявності службової інформації протоколів у медіа пакетах швидкість передачі інформації медіа кодера в каналі взаємодіючих систем значно збільшується. [9]

Зокрема, швидкість передачі інформації аудіо кодера G.711 за рахунок службової інформації стеку протоколів RTP/UDP/ІРv4/GbE збільшується з 64 до 4288 кбіт/с. Але за рахунок агрегації, наприклад, 10 чи 200 голосових кадрів кодера G.711 у пакет зменшується завантаження цього каналу зв’язку відповідно в 8,8 та 45 раз (рис.4.3).

Рисунок 4.3 - Швидкість передачі агрегатних аудіо пакетів G.711

Швидкість передачі інформації аудіо кодера G.729 за рахунок службової інформації стеку протоколів RTP/UDP/ІРv4/GbE збільшується з 8 до 60,8 кбіт/с.

За рахунок агрегації, наприклад, 10 голосових кадрів кодера G.729 у пакет зменшується завантаження каналу цього зв’язку 4,6 раз (рис.4.4).

Рисунок 4.4 - Швидкість передачі агрегатних аудіо пакетів G.729

Швидкість передачі інформації аудіо кодера G.723.1 за рахунок службової інформації протоколів RTP/UDP/ІРv4/GbE збільшується з 6,3 до 23,9 кбіт/с.

За рахунок агрегації, наприклад, 4 голосових кадрів кодера G.723.1 у пакет зменшується завантаження каналу цього зв’язку 3,7 раз (рис.4.5).

Рисунок 4.5 - Швидкість передачі агрегатних аудіо пакетів G.723.1

Швидкість передачі інформації відео кодера H.264/AVC (рівня складності 1) за рахунок службової інформації стеку протоколів RTP/UDP/ІРv4/GbE збільшується з 111,80 кбіт/с до 848,08 кбіт/с (рис.4.6). Тобто службова інформація протоколів RTP/UDP/ІРv4/GbE при передачі відео інформації цього кодера збільшує завантаження каналу в 7,5 раз. Агрегація 4 макроблоків відео кодера H.264/AVC (1b) у пакет зменшить завантаження цього каналу в 2,46 раз.

Рисунок 4.6 - Швидкість передачі агрегатних відео пакетів рівня кодека 1

Швидкість передачі інформації відео кодера H.264/AVC (рівня складності 1.1) за рахунок службової інформації стеку протоколів RTP/UDP/ІРv4/GbE збільшується з 418,2 кбіт/с до 1776 кбіт/с (рис.4.7). Тобто службова інформація протоколів RTP/UDP/ІРv4/GbE при передачі відео інформації цього кодера збільшує завантаження каналу в 4,2 раз.

Рисунок 4.7 - Швидкість передачі агрегатних відео пакетів рівня кодека 1.1

Швидкість передачі інформації відео кодера H.264/AVC (рівня складності 1.1) за рахунок службової інформації стеку протоколів RTP/UDP/ІРv4/GbE збільшується з 836,5 кбіт/с до 3552 кбіт/с (рис.4.7). Службова інформація протоколів RTP/UDP/ІРv4/GbE при передачі відео інформації цього кодера також збільшує завантаження каналу в 4,2 раз

Рисунок 4.8 - Швидкість передачі агрегатних відео пакетів рівня кодека 1.2

4.5 Стислі висновки

По проведеному дослідженню можна сказати що завантаженість каналу значно зменшується якщо використовувати агрегацію аудіо, відео кодеків.

Агрегація голосових кадрів більш ефективна для високошвидкісних кодерів.

Результати розрахунків продуктивності системи при передачі аудіо трафіку залежить від кількості голосових кадрів в агрегатному аудіо пакеті.

Результати розрахунків продуктивності медіа системи з відео кодеками H.264/AVC залежить від кількості макроблоків в агрегатному відео пакеті.

ВИСНОВКИ ТА РЕКОМЕНДАЦІЇ

При виконані дипломної роботи були розглянуті загальні принципи технології передачі медіатрафіку в каналах взаємодіючих IP систем. В першому розділі розглянуто параметри та характеристики протоколів аудіо, відео кодеків, а також технологій передачі медіатрафіку.

В другому розділі проведено аналіз математичних моделей взаємодії медіа систем. Зокрема досліджено вербальні моделі взаємодії відкритих систем, а також проаналізовано математичні моделі процесів інкапсуляції та передачі даних.

Третій розділ роботи направлений на дослідження надлишкової інформації IP систем передачі медіатрафіку. Проведено дослідження обсягів службової інформації протоколів IP систем.

За результатом дослідження інформаційної надлишковості медіа пакетів взаємодіючих ІР систем для різних стеків протоколів можна зробити наступні висновки.

Найбільшою інформаційної надмірністю володіють потоки голосових пакетів, що генеруються кодеком G.726 (32 кбіт/с), а найменшою - G.723.1 (5,3 кбіт/с).

Для мінімізації надлишковості переданої голосової інформації системи ІР телефонії доцільно налаштовувати із застосуванням низько швидкісного кодека G.723.1

За результатом дослідження інформаційної надлишковості відео пакетів, які формуються кодеком H.264/AVC і зробивши аналіз можна сказати що відео пакети ІР систем мають значно нижчу інформаційну надлишковість у порівнянні з аудіо пакетами.

В четвертому розділі проведений аналіз навантажень в каналах систем передачі медіатрафіку. Та аналіз продуктивності системи при передачі медіатрафіку.

Передача трафіку ІР систем в мережах з комутацією пакетів є одним з динамічних напрямків розвитку телекомунікації. Це стосується застосування IP систем в мережі Internet та в корпоративних ТСР/ІР мережах. Незважаючи на низку та механізмів підвищення якості передачі медіа трафіку в ІР мережах проблема забезпечення якості ІР систем, особливо в мережі Internet, залишається актуальною задачею.

ПЕРЕЛІК ПОСИЛАНЬ

1 Росляков А.В. IP-телефония / А.В. Росляков, М.Ю. Самсонов, И.В. Шибаева. - М.: Эко-Трендз, 2003. - 252с.

Технология и протоколы MPLS / Гольдштейн А.Б., Гольдштейн Б.С. - СПб.: БХВ - Санкт-Петербург, 2005.- 304 с.

Телекомунікаційні та інформаційні мережі: Підручник для вищих навчальних закладів / П.П. Воробієнко, Л.А. Нікітюк, П.І. Резніченко. К.: САММІТ-КНИГА, 2010. - 640 с.

Воробієнко П.П. Аналіз обсягів технологічної інформації комунікаційних протоколів систем, що взаємодіють, у мережах з комутацією пакетів / П.П. Воробієнко, М.І. Струкало, С.М. Струкало // Зв’язок. - 2011. - № 2 - С. 13-18.

Воробиенко П.П. Концепция обобщенной эталонной модели взаимодействия открытых систем / П.П. Воробиенко // Электросвязь. - 2001. - № 10. - С. 14-15.

Воробиенко П.П. Моделирование процессов формирования служебной информации при передаче данных в сетях с коммутацией пакетов / [П.П. Воробиенко, М.И. Струкало, И.Ю. Рожновская, С.М. Струкало] // Наукові праці ОНАЗ. - 2009. - № 1. - С. 3-12.

Воробиенко П.П. Обобщенная информационная модель взаимодействия систем инфокоммуникаций / П.П. Воробиенко, М.И. Струкало // Электросвязь. - 2004. - № 6. - С. 24-26.

Струкало М.І. Аналіз надлишкової інформації комунікаційних протоко-лів систем у магістральних ІР мережах / М.І. Струкало, С.М. Горелік // Восточно-Европейский журнал передовых технологий. - 2012. - № 1/9 (55).

Герасимлюк К.В. Аналіз навантажень кодеків ІР телефонії в каналах мереж з комутацією пакетів / К.В. Герасимлюк, С.В. Коваленко, І.М. Струкало // 67-ма наук.-техн. конф. професорсько-викл. складу, науковців, аспірантів та студентів: 5-7 грудня 2012 р.: матеріали конф. Ч.2. - Одеса, 2012. - С. 22-25.

Струкало М.І. Аналіз завантажень каналів систем ІР телефонії агрегатними голосовими пакетами / М.І. Струкало, І.М. Струкало, О.О. Шахов // Інфокомунікації - сучасність та майбутнє: третя міжнародна науково-практична конференція молодих вчених: 17-18 жовтня 2013 р.: збірник тез Ч.1. - Одеса, ОНАЗ, 2013. - С. 74-78.

Шахов О.О. Анализ информационной избыточности голосовых потоков ІР телефонии / О.О. Шахов, С.М. Горелик, М.І. Струкало // 68-ма наук.-техн. конф. професорсько-викл. складу, науковців, аспірантів та студентів: 4-6 грудня 2013 р.: матеріали конф. Ч.2. - Одеса, 2013. - С. 80-83.

Кульгин М. Технологии корпоративных сетей. Энциклопедия. - СПб.: Питер, 2000. - 704 с.

Положення про підготовку та захист випускних кваліфікаційних робіт бакалаврів, спеціалістів і магістрів / М.В. Захарченко, М.М. Балан, О.В. Бондаренко, І.В. Стрелковська. - Одеса: ОНАЗ ім. О.С. Попова, 2013. - 48 с.

Deering S. Internet Protocol, Version 6 (IPv6) Specification [Електронний ресурс] / S. Deering, R. Hinden. - RFC 2460, December 1998. - Режим доступу: http://www.ietf.org/rfc/rfc2460.txt.

ITU-T Recommendation X.200. Information technology. Open Systems Interconnection. Basic Reference Model. The basic model. - ITU-T, 1994.

Postel J. Internet Protocol [Електронний ресурс] / J. Postel. - STD 5, RFC 791, September 1981. - Режим доступу: http://www.ietf.org/rfc/rfc791.txt.

Postel J. User Datagram Protocol [Електронний ресурс] / J. Postel. - STD 6, RFC 768, August 1980. - Режим доступу: http://www.ietf.org/rfc/rfc768.txt.

Schulzrinne H. RTP: A Transport Protocol for Real-Time Applications [Електронний ресурс] / H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson. - RFC 3550, July 2003. - Режим доступу: http://www.ietf.org/rfc/rfc3550.txt.

Smirnov M. Відео стандарти 20.05.2014 [Електронній ресурс] Режим доступу: tp://www.puzzle-tv.ru/help_support_o_video.html#.U2t5O8H5cpD

Smirnov M. Відео кодек H.264/MPEG-4_AVC [Електронний ресурс] 20.05.2014 Режим доступу: http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC