### 1.3 Влияние сети на показатели качества IP-телефонии

Задержка.

Задержка создает неудобство при ведении диалога, приводит к перекрытию разговоров и возникновению эхо. Эхо возникает в случае, когда отраженный речевой сигнал вместе с сигналом от удаленного конца возвращается опять в ухо говорящего. Эхо становится трудной проблемой, когда задержка в петле передачи больше, чем 50 мс. Так как эхо является важнейшей проблемой качества, системы с пакетной коммутацией речи должны иметь возможность управлять эхо и использовать эффективные методы эхоподавления.
Затруднение диалога и перекрытие разговоров становятся серьезным вопросом качества, когда задержка в одном направлении передачи превышает 250 мс. Можно выделить следующие источники задержки при пакетной передачи речи из конца в конец (рисунок 1.10).
1. Задержка накопления (иногда называется алгоритмической задержкой): эта задержка обусловлена необходимостью сбора кадра речевых отсчетов, выполняемая в речевом кодере. Величина задержки определяется типом речевого кодера и изменяется от небольших величин (0,125 мкс) до нескольких миллисекунд. Например, стандартные речевые кодеры имеют следующие длительности кадров:
G.729 CS-ACELP (8 кбит/с) - 10 мс
G.723.1 -Multi Rate Coder (5,3; 6,3 кбит/с) - 30 мс.
2. Задержка обработки: процесс кодирования и сбора закодированных отсчетов в пакеты для передачи через пакетную сеть создает определенные задержки. Задержка кодирования или обработки зависит от времени работы процессора и используемого типа алгоритма обработки. Для уменьшения загрузки пакетной сети обычно несколько кадров речевого кодера объединяются в один пакет. Например, три кадра кодовых слов G.729, соответствующих 30 мс речи, могут быть объединены для уменьшения размера одного пакета.
3. Сетевая задержка: задержка обусловлена физической средой и протоколами, используемыми для передачи речевых данных, а также буферами, используемыми для удаления джиттера пакетов на приемном конце. Сетевая задержка зависит от емкости сети и процессов передачи пакетов в сети.

Рисунок 1.10 – Составляющие задержки в сети IP - телефонии

Время задержки при передаче речевого сигнала можно отнести к одному из трех уровней:
a) первый уровень до 200 мс - отличное качество связи. Для сравнения, в телефонной сети общего пользования допустимы задержки до 150-200 мс;
b) второй уровень до 400 мс — считается хорошим качеством связи. Но если сравнивать с качеством связи по сетям ТфОП, то разница будет видна. Если задержки постоянно удерживаются на верхней границе 2-го уровня (на 400 мс), то не рекомендуется использовать эту связь для деловых переговоров;
c) третий уровень до 700 мс - считается приемлемым качеством связи для ведения неделовых переговоров. Такое качество связи возможно также при передаче пакетов по спутниковой связи.
Качество Интернет - телефонии попадает под 2-3 уровни. IP-телефония, работающая по выделенным каналам, попадает под 1-2 уровни. Также необходимо учитывать задержки при кодировании/декодировании голосового сигнала. Средние суммарные задержки при использовании IP-телефонии обычно находятся в пределах 150-250 мс.
Важно отметить тот факт, что задержки в сетях с коммутацией пакетов влияют не только на качество передачи речевого трафика в реальном времени. Не менее важно отметить, что данные задержки в определенных ситуациях могут нарушить правильность функционирования телефонной сигнализации в цифровых трактах Е1/Т1 на стыке голосовых шлюзов с оборудованием коммутируемых телефонных сетей. Причиной этого можно назвать тот факт, что набор рекомендаций Н.323 в момент своего появления в 1997 г. был ориентирован на мультимедийные приложения, осуществляющие аудио и видеоконференцсвязь через сети IP. Данное решение позволяло значительно снизить стоимость таких систем по сравнению с их аналогами, работающими в сетях традиционной телефонии с коммутацией каналов. В процессе выделения IP-телефонии в самостоятельное направление и развития ее до услуги операторского уровня возникла необходимость соединения IP-шлюзов с телефонными станциями ТфОП по цифровым трактам Е1/Т1. При этом, шлюзы осуществляют взаимодействие с цифровыми АТС, используя стандартные механизмы телефонной сигнализации Q.931, интерпретированные через команды Н.225 и транслируемые в IP-сети с использованием протокола TCP. Согласно рекомендации Q.931, при установлении телефонного соединения значения временных задержек между фазами выполнения команд сигнализации строго регламентированы. Однако, при интерпретации в IP-шлюзах команд телефонной сигнализации Q.931 стеком H.225/TCP/IP, задержки, возникшие на пути прохождения сигнала, увеличивают заданные временные интервалы между командами Q.931, и в большинстве случаев нарушают целостность функционирования данного протокола. Хотя версия 2 набора рекомендаций Н.323 в фазе 2 предусматривает процедуру H.323v2 Fast Connect, ускоряющую обработку команд Q.931 стеком Н.225/ТСР, задержки IP-канала, особенно характерные для инфраструктуры Интернет, могут заведомо превышать все допустимые значения временных интервалов протокола Q.931. Данное обстоятельство можно расценивать как еще один аргумент в пользу использования выделенных каналов при построении сетей IP-телефонии.

Джиттер.

Когда речь или данные разбиваются на пакеты для передачи через IP-сеть, пакеты часто прибывают в пункт назначения в различное время и в разной последовательности. Это создает разброс времени доставки пакетов (джиттер). Джиттер приводит к специфическим нарушениям передачи речи, слышимым как трески и щелчки. Различают три формы джиттера:
1) джиттер, зависимый от данных - происходит в случае ограниченной полосы пропускания или при нарушениях в сетевых компонентах;
2) искажение рабочего цикла - обусловлено задержкой распространения между передачей снизу вверх и сверху вниз; 3) случайный джиггер - является результатом теплового шума.
Величины возникающих задержек и их вероятности важны для организации процедуры обработки и выбора параметров обработки. Понятно, что временная структура речевого пакетного потока меняется. Возникает необходимость организации буфера для превращения пакетной речи, отягощенной нестационарными задержками в канале, возможными перестановками пакетов, в непрерывный естественный речевой сигнал реального времени. Параметры буфера определяются компромиссом между величиной запаздывания телефонного сигнала в режиме дуплексной связи и процентом потерянных пакетов.

Сглаживающий буфер.

Речевой трафик может быть охарактеризован как непрерывный и равномерный поток пакетов. Если в процессе обслуживания очередей в маршрутизаторах эта равномерность нарушается (возникает разброс задержки пакетов) и меры для ее восстановления не принимаются, то выдача абоненту речевых фреймов будет происходить с разной задержкой — он услышит «рваную» речь с провалами в принимаемом сигнале. Для гарантии нормального качества необходимо обеспечить равномерное поступление речевых фреймов, что достигается путем организации на приемной стороне сглаживающего буфера.
Этот буфер принимает и хранит фреймы, выдавая их кодеку через равные интервалы времени. Вариация задержки при этом устраняется, но может возникнуть дополнительная задержка, равная суммарной длительности фреймов, хранящихся в буфере. Поэтому важно обеспечить, чтобы в буфере хранилось лишь минимально необходимое для устранения вариации задержки число фреймов.
В шлюзах могут быть реализованы два типа сглаживающих буферов: с фиксированной и с адаптивно изменяющейся задержкой воспроизведения. В первом случае перед тем, как передать каждый полученный пакет в декодер, буфер хранит его в течение определенного времени. При этом, если пакеты приходят из сети с задержкой, меньшей, чем та, на которую рассчитан буфер, они перед воспроизведением задерживаются в нем без необходимости, что приводит к увеличению общей задержки. Если же пакет поступает по истечении времени установленной фиксированной задержки, он сбрасывается, что приводит к необходимости маскирования ошибок.
В адаптивных буферах задержка и ее вариация определяются в начале каждого речевого фрейма, и в соответствии с этими величинами корректируется момент его выдачи в декодер. Для реализации такого алгоритма можно использовать отметку о времени формирования речевого пакета, сравнивая ее с моментом его получения (разница между ними и есть задержка передачи). Протокол RTP (RFC 1889) инкапсулирует речевые фреймы и обеспечивает передачу таких временных отметок. Отметим также, что при адаптивной буферизации размер буфера можно изменять в соответствии с текущей ситуацией в сети.
Хотя качественная реализация сглаживающего буфера в шлюзе IP-телефонии — вещь очень важная, еще важнее — спроектировать IP-сеть таким образом, чтобы минимизировать вариацию задержек.

Маскирование ошибок.

При возникновении перегрузок в IP-сети маршрутизаторы могут сильно задержать или сбросить пакеты. В результате этого в регенерируемом речевом сигнале возникнут «пробелы», которые будут восприниматься абонентом как щелчки. Для устранения этого неприятного эффекта используется процедура маскирования ошибок (error concealment).
Понятно, что декодер должен получать речевые фреймы через определенный интервал времени. Если пакет получен слишком поздно и в момент, когда декодеру потребовался очередной фрейм, сглаживающий буфер оказался пуст, процедура маскирования ошибок должна сама сформировать фрейм, чтобы скрыть эту ошибку. Это же должно происходить и при получении фрейма, поврежденного в процессе передачи.
Формируемый процедурой маскирования фрейм может быть точной копией предыдущего фрейма, который допустимо повторять несколько раз без существенного влияния на качество. Это возможно благодаря некой избыточности голоса человека и неспособности его органов слуха различать сигналы аналогичной частоты, следующие друг за другом в течение короткого промежутка времени. Фрейм может быть синтезирован и с помощью метода «наилучшего предположения», то есть когда система на основании предыдущих фреймов моделирует последующий.
Использование процедуры маскирования ошибок позволяет получить приемлемый результат, если потери пакетов не слишком велики. Согласно материалам рабочей группы TIPHON, при потере около 3% пакетов хорошее качество передачи речи сохраняется, а при потере 15% пакетов оно становится уже неприемлемым.

Потеря пакетов.

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

Приоритизация.

Под приоритизацией трафика подразумевается включение в состав пакетов информации о том, каким образом они должны обрабатываться в узлах сети, а также сам процесс соответствующей обработки. В принципе, приоритизация имеет смысл только тогда, когда маршрутизаторы или коммутаторы способны различать разные категории трафика. В большинстве случаев по сети передается разнородный трафик, поэтому механизмы приоритизации очень актуальны.
Возможность указывать приоритет IP-пакетов существует уже давно. Для этого имеется байт «тип сервиса» (Type of Service — ToS), введенный еще в IPv4 (RFC 791). Три его первых бита (0—2) позволяют устанавливать восемь уровней приоритета (IP Precedence):
111 — управление сетью (Network Control);
110 — межсетевое управление (Internetwork Control);
101 — CRITIC/ECP;
100 — сверхсрочный (Flash Override);
011 — срочный (Flash);
010 — неотложный (Immediate);
001 — приоритетный (Priority);
000 — обычный (Routine).
В документе RFC 791 биты 3, 4 и 5 были выделены для указания трех классов обслуживания:
бит 3: 0 — нормальная, 1 — низкая задержка;
бит 4: 0 — нормальная, 1 — высокая пропускная способность;
бит 5: 0 — обычная, 1 — высокая надежность.
Биты же 6 и 7 были зарезервированы для будущего использования. Однако после принятия документа RFC 1349 ранее разобщенные биты 3, 4, 5 и 6 стали рассматриваться как единое целое и называться полем ToS. Они служат для указания следующих классов обслуживания:
1000 — с низкой задержкой;
0100 — с высокой пропускной способностью;
0010 — с высокой надежностью;
0001 — с низкой стоимостью;
0000 — стандартный (normal).
Принципиальная разница между двумя указанными в байте ToS параметрами — уровнем приоритета (IP Precedence) и классом обслуживания (поле ToS) — заключается в следующем: первый предназначен для указания приоритета конкретной дейтаграммы и учитывается при обслуживании очередей; второй позволяет определять, какое соотношение между пропускной способностью, задержкой, надежностью и стоимостью оптимально для данного типа трафика, и соответствующим образом выбирать маршрут его передачи.
Большинство современных маршрутизаторов умеют определять уровень приоритета и класс обслуживания, указанные в байте ToS. Однако нельзя гарантировать, что все маршрутизаторы в сети обеспечат одинаковую обработку трафика конкретного типа. Одни из них используют для классификации трафика уровень приоритета, другие — класс обслуживания, третьи — какую-либо иную информацию. Механизмы обслуживания очередей разных устройств тоже сильно различаются. В ближайшее время рассмотренный выше подход, скорее всего, будет вытеснен новым подходом, который основан на модели дифференцированных услуг (Differentiated Services — Diff-Serv), предоставляющей возможность согласованной обработки различных классов трафика. В соответствии с этой моделью, разработанной рабочей группой IETF Diff-Serv, байт ToS получил название байта DS, а шесть его битов отведены для кода Diff-Serv. Каждому значению этого кода соответствует свой класс пересылки РНВ (Per Hop Behavior Forwarding Class), определяющий ожидаемый уровень обслуживания. В рамках каждого класса пакеты должны обрабатываться в соответствии с определенными для него требованиями к качеству обслуживания. Трафик будет разделяться на ограниченное число классов или «групп поведения» (behavior), что обеспечит возможность масштабируемой дифференциации услуг.
Модель Diff-Serv описывает архитектуру сети как совокупность пограничных участков и ядра сети. Поступающий в сеть трафик классифицируется и нормируется (conditioned) пограничными маршрутизаторами. Нормирование трафика предусматривает измерение его параметров, проверку соответствия заданным правилам предоставления услуг, профилирование (при этом пакеты, не укладывающиеся в рамки установленных правил, могут быть отсеяны) и другие операции. В ядре сети магистральные маршрутизаторы или коммутаторы пересылают трафик в соответствии с классом РНВ, код которого указан в поле DS.
Достоинства модели Diff-Serv состоят в том, что она, во-первых, обеспечивает единое понимание того, как должен обрабатываться трафик определенного класса, а во-вторых, позволяет разделить весь трафик на относительно небольшое число классов, вместо того чтобы отдельно анализировать каждый поток. К настоящему времени в рамках Diff-Serv определены два класса трафика: срочной (Expedited Forwarding PHB Group, RFC 2598) и гарантированной доставки (Assured Forwarding PHB Group, RFC 2597).

Обслуживание очередей.

После того как пакет классифицирован оконечной системой или пограничным маршрутизатором, за дело берутся механизмы обслуживания очередей — именно они должны обеспечить обработку пакета в соответствии с его классом. Обычно используется несколько очередей, каждая из которых связана с определенным уровнем приоритета или классом трафика. Важно обеспечить, чтобы высокоприоритетный трафик обрабатывался с минимальной задержкой, но при этом очереди с высоким приоритетом не захватывали всю полосу пропускания, а трафик всех типов пересылался в строгом соответствии с установленными уровнями приоритета.
Основная задача, связанная с обеспечением гарантированного качества обслуживания, заключается в контроле задержек в очередях на всех узлах маршрута при исключении потерь пакетов. Если же в очередях находится очень много пакетов, задержка или ее вариация могут стать недопустимо большими; такая ситуация требует интеллектуальной обработки очередей. Если же очередь достигает таких размеров, когда механизмы ее обработки не в состоянии гарантировать ожидаемое качество обслуживания, необходимо применить средства управления перегрузками, которые разгрузят очереди, сбросив часть пакетов.
Ниже мы рассмотрим некоторые алгоритмы обслуживания очередей.
1. Схема «Первым пришел — первым ушел» (FIFO) является, вероятно, самой простой и распространенной схемой обработки очередей. Пакеты обслуживаются в порядке поступления без какой-либо специальной обработки. Схема FIFO приемлема в тех случаях, когда исходящий канал маршрутизатора имеет достаточно большую свободную емкость. Более того, в таких ситуациях она становится даже оптимальной, поскольку для ее реализации не требуется больших вычислительных ресурсов.
FIFO относится к так называемым неравноправным (unfair) схемам обслуживания очередей, поскольку при ее использовании одни потоки могут доминировать над другими, получая несправедливо большую долю полосы пропускания. В связи с этим были предложены равноправные (fair) схемы, предусматривающие выделение каждому потоку своего отдельного буфера и равномерное распределение полосы пропускания. Однако в тех случаях, когда необходимо выполнять соглашение по уровню обслуживания или обеспечивать приемлемое качество для трафика реального времени, например телефонного,подобная «уравниловка» неприемлема — полосу пропускания надо распределять в соответствии с уровнями приоритета и типом трафика.
2. Схема Priority Queuing (PQ) позволяет обслуживать пакеты в соответствии с заранее установленными приоритетами, которые могут определяться на основании битов IP Precedence, интерфейса поступления пакета, типа протокола или класса РНВ. Обслуживание менее приоритетных очередей начинается только после полного обслуживания более приоритетных. Таким образом схема PQ предоставляет высокоприоритетному трафику абсолютное преимущество и может оставить совсем без внимания другие типы трафика, поэтому ее часто называют схемой обработки очередей с абсолютным приоритетом.
3. Схема взвешенной справедливой очередности Weighted Fair Queuing (WFQ) представляет собой адаптивную схему, которая основана на выделении потокам некоторой доли ресурсов, пропорциональной заданному для каждого типа трафика весовому коэффициенту. Определив соответствующие коэффициенты, можно обеспечить, например, чтобы интерактивный трафик, скажем телефонный, обрабатывался с меньшими задержками, чем трафик другого типа. Алгоритм присвоения весовых коэффициентов зависит от конкретной реализации и может учитывать значения битов IP Precedence, IP-адреса, идентификаторы сеансов и так далее.
Очереди в модели WFQ могут быть связаны с механизмом профилирования, который работает по принципу воронки (token bucket) и «сглаживает» исходящий поток. Такой механизм используется в основном для трафика данных, поскольку именно он, как правило, имеет очень неравномерный характер.
4. Согласно схеме обслуживания очередей в зависимости от классов Class-Based Queuing (CBQ), каждая очередь ассоциируется с характеристиками конкретного класса, например РНВ. Требования к очередям определяются набором таких параметров, как минимальная скорость передачи, задержка, допустимая доля потерянных пакетов и так далее. В этом случае планировщик очередей каждого класса может быть реализован на основе различных алгоритмов, например FIFO, PQ или WFQ.
Механизмы обслуживания очередей, реализованные в современных маршрутизаторах, очень напоминают механизмы, имеющиеся в коммутаторах ATM. Однако даже самый развитой из таких механизмов обеспечивает лишь распределение ресурсов в отдельно взятом узле, но не решает задачу прогнозирования требований к ресурсам со стороны каждого потока на всем протяжении маршрута от одного конечного узла до другого. В ATM эта задача решается в процессе обмена сигнальными сообщениями, устанавливающими виртуальное соединение. Они резервируют ресурсы, необходимые для выполнения требований по минимальной полосе пропускания, максимально допустимой задержке, ее вариации, уровню потерь пакетов и так далее. Подобный тип резервирования ресурсов возможен и в IP-сети, он осуществляется с помощью протоколов RSVP и MPLS,которые будут рассмотрены во 2 разделе.