Відмінності між версіями «Затримки»

Поточна версія на 03:37, 20 листопада 2010

3.1.1 Затримки

При передачі мови по IP-мережі виникають набагато більші, ніж у ТфОП, затримки, які, до того ж, змінюються випадковим чином. Цей факт являє собою проблему і сам по собі, але крім того, ускладнює обговорювану далі в цій главі проблему луни. Затримка (або час запізнювання) визначається як проміжок часу, що витрачаються на те, щоб мовний сигнал пройшов відстань від мовця до слухача. Покажемо, що і як впливає на кількісні характеристики цього проміжку часу.
Вплив мережі
По-перше, нестійкий і погано передбачувано час проходження пакета через мережу. Якщо навантаження мережі відносно мала, маршрутизатори і комутатори, безумовно, можуть обробляти пакети практично миттєво, а лінії зв'язку бувають доступні майже завжди. Якщо завантаження мережі відносно велика, пакети можуть досить довго чекати обслуговування в чергах. Чим більше маршрутизаторів, комутаторів і ліній на маршруті, по якому проходить пакет, тим більше час його запізнення, і тим більше варіація цього часу, тобто джиттер. У главі 10, присвяченій якості обслуговування (QoS), буде показано, яким чином і з використанням яких протоколів і алгоритмів слід будувати мережі, щоб мінімізувати затримки та їх джиттер.
Вплив операційної системи
Більшість додатків IP-телефонії (особливо клієнтських) представляє собою звичайні програми, які виконуються в середовищі якої-небудь операційної системи, такої як Windows або Linux. Ці програми звертаються до периферійних пристроїв (платам обробки мовних сигналів, спеціалізованим платам систем сигналізації) через інтерфейс прикладних програм для взаємодії з драйверами цих пристроїв, а доступ до IP-мережі здійснюють через Socket-інтерфейс.
Більшість операційних систем не може контролювати розподіл часу центрального процесора між різними процесами з точністю, що перевищує кілька десятків мілісекунд, і не може обробляти за такий же час більше одного переривання від зовнішніх пристроїв. Це призводить до того, що затримка в просуванні даних між мережевим інтерфейсом і зовнішнім пристроєм мовного виведення становить, незалежно від використовуваного алгоритму кодування мови, величину такого ж порядку, або навіть більше.
Зі сказаного випливає, що вибір операційної системи є важливим чинником, що впливає на загальну величину затримки. Щоб мінімізувати вплив операційної системи, деякі виробники шлюзів і IP-телефонів використовують так звані ОС реального часу (VxWorks, pSOS, QNX Neutrino і т.д.), які використовують більш складні механізми поділу часу процесора, що діють таким чином, щоб забезпечувати набагато швидку реакцію на переривання і більш ефективний обмін потоками даних між процесами.
Інший, більш плідний підхід - перекласти всі функції, які необхідно виконувати в жорстких часових рамках (обмін даними між мовними кодеками і мережевим інтерфейсом, підтримку RTP і т.д.), на окремий швидкодіючий спеціалізований процесор. При цьому пересилання мовних даних здійснюється через виділений мережевий інтерфейс периферійного пристрою, а операційна система робочої станції підтримує тільки алгоритми управління з'єднаннями і протоколи сигналізації, тобто завдання, для виконання яких жорстких часових рамок не потрібно. Цей підхід реалізовано в платах для додатків IP-телефонії, вироблених фірмами Dialogic, Audiocodes, Natural Microsystems. За такою ж технологією виконаний і шлюз IP-телефонії в платформі Протей-IP, що дозволило забезпечити високу якість передачі мови.
Вплив джіггер-буфера
Проблема джитер досить істотна в пакетно-орієнтованих мережах. Відправник мовних пакетів передає їх через фіксовані проміжки часу (наприклад, через кожні 20 мс), але при проходженні через мережу затримки пакетів виявляються неоднаковими, так що вони прибувають в пункт призначення через різні проміжки часу. Це ілюструє рис. 3.1.

Затримка проходження пакетів по мережі Т може бути представлена як сума постійної складової Т (час поширення плюс середня тривалість затримки в чергах) і змінної величини j, що є результатом джитер: T = T ± j.
Для того, щоб компенсувати вплив джитер, в терміналах використовується т.зв. джиттер-буфер. Цей буфер зберігає в пам'яті прибули пакунки протягом часу, визначеного його ємністю (довжиною). Пакети, які прибувають занадто пізно, коли буфер заповнений, відкидаються. Інтервали між пакетами відновлюються на основі значень часових міток RTP-пакетів. У функції джиттер-буфера зазвичай входить і відновлення вихідної черговості проходження пакетів, якщо при транспортуванні по мережі вони виявилися «переплутані».
Занадто короткий буфер буде приводити до занадто частим втрат "спізнілих» пакетів, а надто довгий - до неприйнятно великий додаткової затримки. Зазвичай передбачається динамічна підстроювання довжини буфера протягом усього часу існування з'єднання. Для вибору найкращої довжини використовуються евристичні алгоритми.
Вплив кодека і кількості переданих в пакеті кадрів Більшість сучасних ефективних алгоритмів кодування / декодування мовлення орієнтоване на передачу інформації кадрами, а не послідовністю кодів окремих відліків. Тому протягом часу, визначеного довжиною кадру кодека, повинна накопичуватися певної довжини послідовність цифрових уявлень відліків. Крім того, деяким кодекам необхідний попередній аналіз більшої кількості мовної інформації, що має міститися в кадрі. Це неминучий час накопичення і попереднього аналізу входить до загального бюджету тривалості затримки пакету.
На перший погляд, можна було б укласти, що чим менше довжина кадру, тим менше повинна бути затримка. Однак, як буде показано нижче, через значне обсягу службової інформації, переданої в RTP / UDP / IP-пакетах, передача маленьких порцій даних дуже неефективна, так що при застосуванні кодеків з малою довжиною кадру доводиться упаковувати декілька кадрів в один пакет. Крім того, кодеки з більшою довжиною кадру більш ефективні, оскільки можуть «спостерігати» сигнал протягом більшого часу і, отже, можуть більш ефективно моделювати цей сигнал.
ITU-T в рекомендації G.114 визначив вимоги до якості передачі мови. Воно вважається гарним, якщо наскрізна затримка при передачі сигналу в один бік не перевищує 150 мс (рис. 3.2). Сучасне обладнання IP-телефонії при включенні "спина до спини» (два пристрої - шлюзу - з'єднуються безпосередньо) вносить затримку близько 60-70 мс. Таким чином, залишається ще близько 90 мс на мережеву затримку при передачі IP-пакета від відправника до пункту призначення, що говорить про можливість забезпечити при сучасному рівні технології передачу мови з досить гарною якістю.

Авторам аж ніяк не хотілося б, щоб у читача склалося враження, ніби тимчасові затримки - проблема виключно IP-телефонії. Саме тому на мал. 3.2 наведені також характеристики супутникової передачі, при якій потрібно приблизно 250 мс для того, щоб сигнал досяг супутника і повернувся назад до Землі (без урахування витрат часу на обробку сигналу). Таким чином, повний час затримки перевищує 250-300 мс. Згідно з рекомендацією G.114, така затримка виходить за межі діапазону, прийнятного для передачі мови. Тим не менше, щодня значну кількість розмов ведеться по супутникових лініях зв'язку. Отже, прийнятну якість мовлення визначається, перш за все, вимогами користувачів.

--Козінцев Олексій 36 гр. 14:18, 16 листопада 2010 (EET)