ноябрь 2002 г. Мобильные системы №11

Вадим Саякин
Генеральный директор компании NV Consulting

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

Миграция от состояния однородной сети к новой мультисервисной среде состоит из следующих взаимосвязанных процессов всеобъемлющего планирования:

1. Аудит существующей сетевой инфраструктуры
2. Разработка основных требований и технического задания
3. Анализ рассматриваемых технологий и сервисов
4. Разработка технического дизайна и планирования пропускной способности
5. Анализ возврата инвестиций
6. Разработка поэтапного плана внедрения

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

Рассматривая технологии мультисервисных сетей, наибольший интерес представляют третий и четвертый этапы этого плана, которые подробно рассмотрены ниже.

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

Транспортная сеть, которая может быть построена на основе IP, Frame Relay или ATM, формирует традиционное "облако". На границах этой сети находятся устройства или компоненты, называемые голосовыми шлюзами. Задача этих устройств состоит в изменении голосовой информации, из ее традиционной формы в форму, приемлемую для пакетной передачи. Сеть, в данном случае, направляет пакет в другой голосовой шлюз, являющийся пунктом назначения или вызываемой стороной.

При рассмотрении технологий построения мультисервисных сетей существуют три альтернативы при построении WAN - среды: IP, Frame Relay или ATM.

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

Frame Relay - относительно недорогая технология для передачи голоса, использующая низкоскоростные WAN-механизмы. Сервисы Frame Relay могут обеспечивать постоянные или коммутируемые виртуальные соединения (PVC или SVC). Оценивая сигнальную, адресную и маршрутизирующую функциональность, мы приходим к базовой топологии "точка-точка", что не всегда может быть удобно.

ATM, как ориентированная на соединения технология, типично используется в качестве ядра сети на уровне OC3. Несмотря на хорошую оптимизацию ATM для передачи голоса (в том числе по параметрам задержки), эта технология используется в основном в больших оптических сетях.

Таким образом, в зависимости от специфики исходной ситуации необходимо принять решение о выборе технологии - либо VoIP, либо VoFR, либо VoATM.

При использовании VoIP на сессионном уровне модели OSI может применяться один из основных протоколов - H.323, SIP или MGCP.

H.323 - один из ранних ITU-стандартов, который широко применяется в большинстве продуктов. H.323 включает несколько связанных стандартов: H.225 (call control), H.425 (Media path and parameter negotiation), H.235 (Security), H.225 (Registration, Admission and Status - RAS), H.323 (Gatekeeper protocol) и H.450 (Supplementary services).

SIP, Session Initiation Protocol, определен в IETF RFC 2543. Также как H.323, SIP представляют собой распределенную модель, в которой процедуры обработки вызовов встроены в шлюзы и фактически не требуют дополнительной помощи от других сетевых элементов. Тем не менее, существуют дополнительные возможности, реализованные на серверном уровне, для H.323 - в терминах Gatekeepers, а для SIP - в терминах SIP Proxy.

MGSP, Media Gateway Control Protocol, также является стандартом IETF, но представляет собой централизованную модель, в которой есть центральный Call Agent server, выполняющий обработку вызовов. Для создания функционирующей среды необходимо наличие, по крайней мере, двух конечных точек и одного Call Agent.

Если исходить из полной реализации проекта на оборудовании Cisco, то удобнее использовать протокол H.323.

В качестве основного протокола при передаче голоса используется Real - time Protocol (RTP), который в свою очередь использует в качестве транспортного протокола User Datagram Protocol (UDP). Сигнальный трафик использует также протокол TCP.

Еще один важный технологический выбор состоит в том, посредством какой сигнализации существующие АТС или точки входа в ТфОП соединяются с мультисервисной инфраструктурой. Голосовые шлюзы обычно поддерживают широкий диапазон протоколов сигнализации, что позволяет выбрать наиболее приемлемый. Голосовые шлюзы терминируют телефонную сигнализацию, так что ее тип между АТС и шлюзом в точке входа может отличаться от выбранного типа между шлюзом и АТС в точке выхода. Для цифровых интерфейсов Е1 используется как CCS (Common Channel Signalling), предполагающий выделенный канал для сигнальной информации, так и CAS (Channel Associated Signalling), использующий для этих целей биты ABCD. К CCS относятся такие протоколы как SS7, ISDN Q.931 PRI и BRI, Q.SIG. Критериями выбора типа сигнализации между АТС и границей мультисервисной сети являются следующие факторы:

• АТС по возможности не должны подвергаться модификации;
• должны учитываться поддерживаемые региональные установки;
• удовлетворение "предпочтений" со стороны ТфОП;
• сформулированные требования по характеристикам вызовов (например, отображение Caller ID);
• возможности обработки ошибок на интерфейсе (здесь преимущества имеет CCS).

Как правило, выбор типа сигнализации проводится после дополнительного обсуждения с Заказчиком. Следует учитывать, что тип сигнализации R1.5 зачастую не поддерживается оборудованием мультисервисной сети.

На этапе 4 необходимо рассмотреть технический дизайн предлагаемого решения с той целью, чтобы будущая сеть смогла обеспечить приемлемое качество голоса.

Основным стандартом в этой области является PCM (Pulse Code Modulation), представляющий голос в виде потока шириной в 64 Кбит/c. Методы компрессии снижают полосу ниже 64 Кбит/c.

Методы компрессии	Стандарт ITU	Полоса, Кбит/с	Оценка MOS	Задержка, мс.
PCM	G.711	64 (DS0)	4.1	0.75
ADPCM	G.726	32	3.85	1
LD-CELP	G.728	16	3.61	3-5
CS-ACELP	G.729	8	3.9	10
CS-ACELP	G.729а	8	3.85	10
MP-MLQ/ ACELP	G.723.1	6.3/5.3	3.8/3.75	30

В таблице представлены типы кодеков и их параметры. Естественно, что большое значение имеет экономия полосы, но кроме этого необходимо помнить о качестве голоса.

В таблице также представлен параметр MOS (Mean Opinion Score), который определяет среднюю оценку качества голоса, полученную экспертным путем. Наивысший балл - 5, низший балл - 1, при этом:

• баллы 4-5 показывают эталон качества, так называемое, toll-quality
• баллы 3-4 - уровень приемлемого коммуникационного качества
• баллы ниже 3 - это синтетическое качество.

Параметр MOS дает субъективную оценку, но эта методика является официальной, она описывается в документах ITU. Метод Perceptual Speech Quality Measurement (PSQM) является более современным, он был разработан недавно и уже получил свое отражение в стандарте ITU P.861. Возможно, через некоторое время получится дать более точные оценки, используемые при разработке дизайна мультисервисных сетей.

По данным компании Cisco, сегодня доминирующим в использовании типом кодека является G.729. По методу MOS при существенном сжатии его качество воспроизводимого голоса оценивается лишь на 0,2 балла ниже, чем G.711. Именно поэтому, кодек G.711 пользуется особой популярностью.

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

Эхо возникает в сети в тех случаях, когда происходит передача сигналов с двухпроводных на четырехпроводные линии. Для того чтобы компенсировать это, в оборудовании используются стандартные схемы эхоподавления (G.165).

Задержка имеет две компоненты: фиксированную и переменную составляющую, называемую так же джиттером. Для минимизации задержки и джиттера для голосового трафика применяют механизмы качества сервиса.

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

Задержка

Существуют рекомендации ITU по допустимым уровням задержки. В большинстве случаев она не должна превышать 150 мс. Задержки от 150 до 400 мс также могут быть приемлемыми, если принимаются к рассмотрению вопросы экономического характера (в первую очередь, стоимость разговора). В общем случае голосовые сети проектируются с задержкой распространения в одну сторону не более чем 200 мс.

Составляющие фиксированной задержки:

• Задержка распространения рассчитывается в зависимости от расстояния между исходной точкой и точкой назначения. В расчетах обычно принимают задержку распространения равной 6 мкс на километр.
• Интерфейсная задержка (задержка при передаче в канал) возникает в процессе помещения битов во внешний интерфейс. Интерфейсная задержка является существенной для каналов с пропускной способностью менее 768 кбит/с. В качестве иллюстративного примера, демонстрирующего разницу интерфейсной задержки можно привести следующие цифры. Помещение 1 байта на интерфейс 64 Кбит/c дает задержку в 125 мс. Тот же самый байт, помещенный на интерфейс 155 Мбит/с, дает задержку всего лишь в 0,05 мс.
• Задержка обработки включает в себя алгоритмическую задержку и задержку пакетизации. Алгоритмическая задержка связана с обработкой голоса. Обычно она составляет от 1 до 30 мс для типовых кодеков. Задержка пакетизации возникает в процессе удержания голосовых образцов при помещении их в пакет IP до тех пор, пока их достаточное количество не заполнит этот пакет.

Составляющие переменной задержки:

• Задержка в очереди вызвана ожиданием обслуживания предшествующих пакетов на интерфейсе. Время ожидания сильно зависит от размера тех пакетов, которые находятся во главе очереди. Для того чтобы минимизировать этот тип задержки, необходима соответствующая конфигурация маршрутизаторов.
• Задержка в деджиттер-буфере (воспроизводящем буфере) образуется на приемном конце при выравнивании возникающей вариации задержки голосовых пакетов.

Типы задержки	Фиксированная	Переменная
Алгоритмическая задержка кодека (G.729)	5 мс	-
Задержка пакетизации (за 2 x 10 байтных голосовых образца)	20 мс	-
Задержка в очереди	-	6 мс
Интерфейсная задержка (зависит от полосы на интерфейсе, при интерфейсе более 512 Кбит/c)	Менее 1 мс	-
Задержка распространения (6 мкс на 1 км)	600 мкс (на 100 км)	-
Задержка в деджиттер-буфере	-	50 мс
Итого:	27 мс	56 мс
Всего:	83 мс

Основываясь на вышеприведенных составляющих задержки, приведем пример ее вычисления (см. таблицу).

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

Используемыми механизмами качества сервиса являются:

• Маркирование (Marking) использует специальный тип маркера в заголовке пакета, в соответствии с которым производится классификация и дальнейшее определение политик. Маркирование позволяет не производить повторную классификацию пакетов в каждой последующей точке пути. Примером маркирования могут быть IP Precedence или DiffServ Code Point (DSCP).
• Классификация (Classification) - это процесс инспекции пакетов для определения, к какому типу трафика они относятся. Средства классификации основываются на различных атрибутах, таких как протокол, номер порта, размер пакета, содержимое заголовка пакета, интерфейс и др. Примером может служить CAR (Committed Access Rate).
• Определение политики (Policing) дает решение, какой трафик и каким способом будет обрабатываться. При этом используются схемы ограничения потоков.
• Механизмы обработки очереди (WFQ, LLQ) обеспечивают сложные схемы приоритезации одного типа трафика над другим.
• Сглаживание трафика (Traffic Shaping) действует как механизм ограничения, но в отличие от него не сбрасывает пакеты, превышающие определенный порог, а буферизирует их и сохраняет в очереди.

Такие механизмы должны быть использованы при настройке маршрутизаторов мультисервисной сети.

Очень важным моментом является процесс расчета требуемой полосы для передачи пакетизированного голоса. Для того чтобы оптимизировать полосу пропускания, помимо применения кодеков следует рассматривать использование таких механизмов как RTP Header Compression (cRTP), VAD (Voice Activity Detection) и MLPPP (Multilink Point-to-Point Protocol).

Компрессия заголовков позволяет существенно снизить их размер. Так, например, суммарная величина заголовка составляет 20 байт (заголовки IP, UDP, RTP), в то время как величина полезной нагрузки в пакете также равна 20 байт (при использовании кодека G.729). Используя алгоритмы сжатия cRTP, можно снизить величину заголовка до 2-4 байт.

VAD особенно помогает на линиях с большим числом голосовых каналов. Оценочная величина на 24 линиях может составлять порядка 35% экономии полосы пропускания. Но эффективность данного алгоритма зависит также от использования такой особенности как music on hold.

И, наконец, MLPPP помогает построить эффективные схемы передачи коротких голосовых пакетов при наличии в потоке больших пакетов с данными. Это происходит путем разбиения больших пакетов и чередования их с короткими. Величина заголовка MLPPP добавляет 6 байт.

Для реального проекта можно рассчитать требуемую полосу для кодека G.729 следующим образом:

1. Размер голосового пакета = MLPPP заголовок + cжатый заголовок RTP + полезная нагрузка = 6 + 2 + 20 = 28 байт

2. Размер пакета в битах = 28 байт * 8 бит = 224 бит

3. Число пакетов в секунду = 8 Кбит/c / 160 бит = 50 пакетов/c; 160 бит = 20 байт (полезной нагрузки) * 8 бит

4. Полоса для 1 голосового канала = 224 бит * 50 пакетов/c = 11,2 Кбит/c

Таким образом, получаем, что реальная полоса для передачи 1 голосового канала при использовании кодека G.729 составляет 11,2 Кбит/c.

Следует отметить особо, что в маршрутизаторах Cisco (начиная с версии IOS 12.0(5)T) есть возможность изменения числа голосовых образцов, попадающих в один и тот же пакет. Вместо 20 голосовых байт (попадаемых в пакет) по умолчанию, можно использовать диапазон значений от 10 до 230 байт. Увеличение величины голосового образца, используемого кодеком, позволяет уменьшить занимаемую полосу. Но к использованию этого механизма надо подходить осторожно, т.к. здесь необходимо учитывать также параметр задержки.

Более подробные данные по различным типам кодеков можно найти ниже в таблице.

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