Транспортный

шлюз - -

Рис. 5.15. Установление соединения телефон-компьютер

5.4.2. Мультисервисная сеть на основе IP/MPLS и Softswitch

В варианте мультисервисной сети, рассмотренном А.Б. Гольд-штейном [10], в качестве транспортной сети взята сеть наоснове MPLS. В эту сеть поступает информация из IP-сети, которая, как известно, не поддерживает гарантированное QoS. Для обеспечения гарантированного QoS и предлагается использовать протокол резервирования ресурсов RSVP.

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

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

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

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

Сообщение Path должно нести в себе шаблон данных отправителя (Sender Template), описывающий тип этих данных. 1иаблон специфицирует фильтр, который может отделять пакеты этого отправителя от других пакетов в пределах сессии. Кроме того, сообщение Path должно содержать спецификацию потока данных отправителя Tspec, которая определяет характеристики этого потока. Спецификация Tspec используется, чтобы предотвратить избыточное резервирование.

Шаблон данных отправителя имеет тот же формат, что и спецификация фильтра в сообщениях Resv. В зависимости от идентификатора протокола, заданного для сессии, шаблон может специфицировать только IP-адрес отправителя или (но не обязательно) также и иОРЛ СР-порт.

Приняв сообщение Path, его получатель передает к маршрутизатору, от которого пришло это сообщение (т.е. по направлению к отправителю), запрос резервирования ресурсов - сообщение Resv. В дополнение к информации Tspec, сообщение Resv содержит спецификацию запроса (Rspec), в которой указываются нужные получателю параметры качества обслуживания, и спецификацию фильтра (filter-spec), которая определяет, к каким пакетам сессии относится данная процедура. Вместе Rspec и filterspec представляют собой дескриптор потока, используемый маршрутизатором для идентификации каждой процедуры резервирования ресурсов.

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

При получении сообщения Resv каждый маршрутизатор резервируемого пути, поддерживающий протокол RSVP, определяет приемлем ли этот запрос, для чего выполняются две процедуры. С помощью механизмов управления доступом проверяется, имеются ли у маршрутизатора ресурсы, необходимые для поддержки запрашиваемого качества обслуживания, а с помощью процедуры режимного контроля (policy control) - правомерен ли запрос резервирования ресурсов. Если запрос не может быть удовлетворен, маршрутизатор отвечает на него сообщением об ошибке.

Если же запрос приемлем, данные о требуемом качестве обслуживания поступают для обработки в соответствующие функциональные блоки (способ обработки параметров QoS маршрутизатором в протоколе RSVP не определен), и маршрутизатор передает сообщение Resv следующему (находящемуся ближе к отправителю данных) маршрутизатору. Это сообщение несет в себе спецификацию flowsptc, содержащую два набора параметров;

Rspec , который определяет желательное QoS;

Тзрес , который описывает информационный поток.

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

После окончания вышеописанной процедуры ее инициатор начинает передавать данные, и на их пути к получателю будет обеспечено заданное QoS. -

Совместное использование двух протоколов - RSVP на уровне доступа и MPLS на уровне транспортной сети - позволяет предоставлять пользователям нашей конвергентной сети гарантированное качество обслуживания.

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

Кроме того, в конвергентную сеть войдут сети IP-телефонии альтернативных операторов, построенные, например, на протоколах Н.323 и SIP. Сегодня такие сети используются, в основном, для междугородной и международной связи, но в условиях конвергентной сети они станут альтернативой ТфОП.

Для управления соединения в конвергентной сети используется Softswitch. Поддерживая все протоколы управления шлюзами и терминалами пакетной сети, Softswitch поддерживает и сигнализацию ТфОП. Он управляет устройствами сети 1Р-телефонии, работающей по протоколам Н.323 и/или SIP, взаимодействует с телефонными станциями по протоколам DSS1 или ОКС-7, а соединение между ними организует с помощью протоколов управления шлюзами MGCP/ MEGACO.

Предлагаемый путь развития телекоммуникационной сети представлен на рис. 5.16.

Пример установления соединения для такой сети дан на рис. 5.17.

Предположим, нужно связать двух пользователей, один из которых является абонентом ТфОП, а второй - пользователем сети IP-телефонии. Пусть инициатором соединения будет VoIP-пользователь (абонент А), а сеть IP-телефонии использует протокол Н.323.

PLMN

Softswitch

( PSTN/ISDN/IN ]

Internet/Intranet j

RSVP

MPLS

Существующие сети ~ Мультисервисные сети

Рис.5.16. Путь развития телекоммуникационной сети

Абонент А Softswitch MPLS- Шлюз VoIP АТС Абонент Б

маршрутизатор Абонент Б

Setup

Запрос RSVP

Резервирование ресурсов

RTP/RTCP соединение

Абонентская сигнализация

Разговорный канал

Завершение разговора

Отмена резервирования

Освобождение канала

Рис. 5.17. Пример установления соединения

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

зываемого абонента Б, терминал абонента А с помощью протокола RSVP занимает ресурс связи с маршрутизатором MPLS, необходимый ему для гарантированной передачи речевого трафика реального времени с соответствующим стандартам качеством.

Дело в том, что терминал абонента А далеко не всегда имеет прямой доступ к сети MPLS. Подключение к ней может идти по каналам обычной (public) сети Интернет, которая гарантированного качества обслуживания не обеспечивает. Именно здесь будет использоваться протокол RSVP.

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

5.5. Оборудование для сетей на основе Softswitch от компании ZTE

Таблица 5.1. Проекты компании ZTE

Компания ZTE считает целесообразным использовать оборудование Softswitch прежде всего для построения NGN классов 4 и 5.

NGN класса 4 (тандемного типа) предоставляет абонентам услуги передачи голоса и данных: местные и междугородные соединения VoIP между абонентами ТфОП и услуги ПД по сети IP. В NGN класса 4 отсутствуют коммутаторы ТфОП с входящими интерфейсами соединительных линий, а подключение ТфОП к IP-сети осуществляется с помощью сигнального и транспортного шлюзов. NGN класса 5 будет предоставлять услуги VoIP, что позволяет избежать крупных инвестиций для построения телефонных узлов и ПД. Исключены любые коммутаторы ТфОП, а медные пары абонентов подключаются непосредственно к шлюзам NGN или устройствам интегрированного доступа.

NGN классов 4 и 5 предложат абонентам большой набор услуг, что делает технологию Softswitch весьма привлекательной для операторов и сервис-провайдеров.

Компания выделяет следующие технологические преимущества своего оборудования:

1. Полностью конвергированные услуги передачи голоса и данных в IP-сети, возможность подключения к ТфОП. Высокие показатели QoS голосовой связи.

Высокая производительность - поддержка более 2 млн соединений в ЧНН при использовании одного контроллера Softswitch и более 6 млн. соединений при каскадном соединении трех котроллеров.

Операторы

China Netcom

China Unicom

China Railway

China Telecom

Thailand TT&T Project

Hong Kong Wharf NGN

Philippine Digital NGN

Romania RPO NGN

Количество абонентов

21 ООО

Трафик, мин./день

170 ООО

Стоимость, долл./мин.

0,03...0,04

Коммерческое тестирование с 10ОО абонентов

Коммерческое тестирование с 10ОО абонентов

> 6000 абонентбких линий в 400 IP phone 150 ООО

1. ZTE, Huawei, Alcatel, Cisco и VocalTel приняли участие в первом этапе тендера по проекту ТТ&Т NGN

2. ZTE и Huawei вышли на второй этап тендера. Softswitch от ZTE прошел все виды тестирования для ТТ&Т. В настоящее время ZTE и ТТ&Т ведут переговоры о дальнейшем сотрудничестве

1. ZTE и Lucent и Nortel приняли участие в первом этапе тендера по проекту Hong Kong Wharf NGN

2. ZTE и Nortel вышли на второй этап тендера. Softswitch от ZTE прошел все тесты для Hong Kong Whart NGN project. В настоящее время ZTE и Hong Kong Wharf NGN ведут переговоры о дальнейшем сотрудничестве

1. ZTE, Huawei, Cisco, Alcatel, UT, Ericsson и Sandra приняли участие в первом этапе тендера по проекту Digital NGN

2. ZTE, Huawei и Cisco вышли на второй этап тендера ZTE - единственный победитель тендера по проекту Romania RPO NGN

Гибкие сетевые решения для построения NGN класса 4 (услуги междугородной связи) и класса 5 (услуги местной связи с помощью устройств интегрированного доступа IAD). Возможность сохранения коммутаторов ТфОП путем подключения NGN к ТфОП с помощью сигнального и транспортного шлюзов.

5. Надежная система управления NGN.

6. Разумные цены и четкое обслуживание абонентов.

Компания имеет большой опыт реализации NGN проектов (табл. 5.1).

Достоинством оборудования Softswitch, производимого компанией ZTE, является его совместимость с оборудованием других вендоров (табл. 5.2).

Отметим также, что решения ZTE предусматривают интеграцию оборудования с интеллектуальными и мобильными платформами. Так, Softswitch ZTE может использоваться в качестве виртуального SSP (пункта коммутации услуг IN) с поддержкой INAP/TCAP. Пока Softswitch соединяется с мобильными платформами через ТфОП, однако в ближайшее время планируется выпуск проводно-