Протокол IPDC используется разными производителями оборудования IP-телефонии для управления шлюзами и для организации транспортных потоков внутри пакетных сетей при передаче речи. Кроме того, протокол IPDC служит для переноса по IP-сетям сигнальной информации ТфОП/ISDN (например, в одной из реализаций Softswitch сообщения DSS1 преобразуются в сообщения IPDC) (рис.10). Архитектура сети, построенной с использованием протокола IPDC, так же, как и сети на основерекомендации Н.248, базируется на идее декомпозиции шлюзов.

Рисунок 10 - Протокол IPDC

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

5.5 Построение сети IP-телефонии с устройствами Softswitch

Разобрав принцип работы устройства Softswitch, можно рассмотреть процесс установления соединения в сети IP-телефонии, построенной на базе Softswitch. Существует три основных сценария соединений в сети IP-телефонии:

1. Телефон - телефон;

2. Телефон - компьютер;

3. Компьютер - компьютер.

Первый сценарий чаще всего встречается при транзите через IP-сеть телефонного междугороднего/международного трафика. Предположим, что используется система сигнализации ОКС 7 (рис.11). Тогда Softswitch взаимодействует с телефонными коммутаторами, работающими в сети ОКС 7, и выполняет функции пункта сигнализации SIP этой сети.

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

После этого формируется сигнальное сообщение IAM в сторону вызываемой станции, которая может находиться в зоне действия другого Softswitch, и тогда сначала сообщениями будут обмениваться сами устройства Softswitch, а уже от них сообщения будут транслироваться к обеим АТС. Итак, происходит обмен стандартными сообщениями ОКС 7 с вызывающей и вызываемой станциями через IP-сеть. Получив от вызываемой станции сообщение ANM об ответе вызываемого абонента, Softswitch транслирует это сообщение в сторону вызывающей станции. Затем соответствующим транспортным шлюзам дается команда установить соединение, для чего может быть использован, например, интерфейс Н.248 или IPDC (в случае H.248 команда предписывает переместить определенные виртуальные и физические порты шлюза из нулевого во вновь созданный контент). После этого происходит формирование речевого соединения по сети IP (RTP/RTCP). Таким образом, устанавливается соединение двух пользователей ТфОП (или сети подвижной свзи) через IP-сеть.

Рисунок 11 - Установление соединения телефон-телефон с сигнализацией ОКС 7

Во втором сценарии начало установления соединения остается прежним, но дальше Softswitch не взаимодействует с вызываемой АТС (её просто нет), а устанавливает прямое соединение входного транспортного шлюза (к которому поступает поток от вызывающей станции) с терминалом вызываемого абонента через сеть IP-телефонии.

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

Softswitch может также выступать как устройство, обеспечивающее взаимодействие между сетями IP-телефонии, которые построены с использованием различных протоколов SIP, Н.323. В третьем сценарии абоненты могут находиться как в одной и той же сети, построенной на одном стандарте, так и в разных сетях IP-телефонии. Тогда Softswitch будет с одной стороны взаимодействовать, например, с клиентом SIP, а с другой - с терминалом Н.323. В этом случае работа Softswitch будет больше похожа на работу конвертера сигнализации, но, тем не менее, все функции управления будет выполнять именно он [9].

5.6 Роль и структура Softswitch-консорциума

Дальнейшие исследования в этом и во всех других названных выше направлениях осуществляются в рамках международного Softswitch-консорциума, который был создан с целью обеспечить совместимость и взаимодействие систем Softswitch. Консорциум ISC (The International Softswitch Consortium) был создан в мае 1999 года и на данный момент включает в себя примерно 150 членов. Ведущие компании телекоммуникациионного рынка объединили усилия для продвижения во всем мире технологий мультисервисных сетей следующего поколения и организовали представительный форум разработчиков, менеджеров и специалистов в различных областях телекоммуникаций для обсуждения и формирования общей структуры систем Softswitch, их компонентов и функций.

В консорциум входят Alcatel, Cisco, Clarent, Ericsson, Level 3, Lucent Technologies, Marconi, Motorola, Nokia, Radcom, Samsung, Siemens, VocalTec и др.

В настоящее время создано шесть рабочих групп: группа приложений (Applications WG), группа управления устройствами (Device Control WG), группа маркетинга (Marketing WG), группа SIP (SIP WG), административная группа (Session Management WG) и юридическая группа (Legal Intercept WG).

Под эгидой консорциума организован учебный центр, проводятся семинары и конференции по тематике современных технологий. Кроме того, работает Интернет-форум, где проходит обсуждение многих аспектов технологий и самого консорциума?. Работа такого консорциума представляется особенно важной в свете создания (конечно, в будущем, может быть - далеком, а может быть - и не очень) единой мультисервисной сети, охватывающей всю планету.

5.7 Варианты применения Softswitch в составе ЕСЭ РФ

Регулирующие отечественный телекоммуникационный рынок документы предусматривают различные варианты Softswitch в зависимости от применения, места, занимаемого им в сети, а также от выполняемых функций. В этой дипломной работе рассматриваются наиболее распространенные варианты использования технологии Softswitch. Существуют следующие варианты применения Softswitch в составе ЕСЭ РФ:

· Softswitch в качестве транзитного узла;

· Softswitch в качестве распределенной оконечной станции коммутации;

· Оборудование Softswitch в качестве распределенного SSP;

· Оборудование Softswitch в качестве распределенного узла телематических служб.

Более подробно эти варианты применения представлены и описаны в Приложении 2.

6. Концепция IMS

В 2002 г. партнерство 3GPP, разрабатывающее стандарты для мобильных сетей 3G, предложило концепцию IMS для сетей мобильной связи, заключающуюся в создании домена IP Multimedia Domain в дополнение к уже имеющимся доменам пакетной передачи данных и коммутации каналов. Несколько позже появился проект TISPAN (Telecommunications and Internet converged Services and Protocols for Advanced Networking), распространяющий архитектуру IMS на фиксированные сети и стимулирующий конвергенцию фиксированных и мобильных сетей FMC (Fixed-Mobile Convergence).

6.1 Общие сведения о IMS

Унифицированная сервисная архитектура IMS поддерживает широкий спектр сервисов, основанных на гибкости протокола SIP (Session Initiation Protocol). Как показано на рис.13, IMS поддерживает множество серверов приложений, предоставляющих как обычные телефонные услуги, так и новые сервисы (обмен мгновенными сообщениями, мгновенная многоточечная связь, передача видеопотоков, обмен мультимедийными сообщениями и т.д.).

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

6.1.1 Уровень абонентских устройств и транспорта

На этом уровне инициируется и терминируется сигнализация SIP, необходимая для установления сеансов и предоставления базовых услуг, таких как преобразование речи из аналоговой или цифровой формы в IP-пакеты с использованием протокола RTP (Realtime Transport Protocol). На этом уровне функционируют медиашлюзы, преобразующие базовые потоки VoIP в телефонный формат TDM. Медиасервер предоставляет различные медиасервисы, в том числе конференц-связь, воспроизведение оповещений, сбор тоновых сигналов, распознавание речи, синтез речи и т.п. Ресурсы медиасервера доступны всем приложениям, т.е. любое приложение (голосовая почта, бесплатный номер 800, интерактивные VXML-сервисы и т.д.), которому необходимо воспроизвести оповещение или получить цифры набранного номера, может использовать общий сервер. Медиасерверы также поддерживают и нетелефонные функции, например, тиражирование голосовых потоков для оказания сервиса мгновенной многоточечной связи (PTT). При использовании для различных сервисов общего пула медиасерверов отпадает необходимость в планировании и инжиниринге медиаресурсов для каждого отдельного приложения.

6.1.2 Уровень управления вызовами и сеансами

На этом уровне располагается функция управления вызовами и сеансами CSCF (Call Session Control Function), которая регистрирует абонентские устройства и направляет сигнальные сообщения протокола SIP к соответствующим серверам приложений. Функция CSCF взаимодействует с уровнем транспорта и доступа для обеспечения качества обслуживания по всем сервисам. Уровень управления вызовами и сеансами включает сервер абонентских данных HSS (Home Subscriber Server), где централизованно хранятся уникальные сервисные профили всех абонентов. Профиль содержит текущую регистрационную информацию (например, IP-адрес), данные роуминга, данные по телефонным услугам (например, номер переадресации), данные по обмену мгновенными сообщениями (список абонентов), параметры голосовой почты (например, приветствия) и т.д. Централизованное хранение позволяет различным приложениям использовать эти данные для создания персональных справочников, информации о присутствии в сети абонентов различных категорий, а также совмещенных услуг. Централизация также существенно упрощает администрирование пользовательских данных и гарантирует однородное представление активных абонентов по всем сервисам.

На уровне управления вызовами и сеансами также располагается функция управления медиашлюзами MGCF (Media Gateway Control Function), которая обеспечивает взаимодействие сигнализации SIP с сигнализацией других медиашлюзов (например, H.248). Функция MGCF управляет распределением сеансов по множеству медиашлюзов, для медиасерверов это выполняется функцией MSFC (Media Server Function Control).

6.1.3 Уровень серверов приложений

Этот уровень содержит серверы приложений, которые обеспечивают обслуживание конечных пользователей. Архитектура IMS и сигнализация SIP обеспечивают достаточную гибкость для поддержки разнообразных телефонных и других серверов приложений. Так, разработаны стандарты SIP для сервисов телефонии и сервисов IMS.

Архитектура IMS поддерживает множество серверов приложений для телефонных сервисов. Сервер телефонных приложений TAS (Telephony Application Server) принимает и обрабатывает сообщения протокола SIP, а также определяет, каким образом должен быть инициирован исходящий вызов. Сервисная логика TAS обеспечивает базовые сервисы обработки вызовов, включая анализ цифр, маршрутизацию, установление, ожидание и перенаправление вызовов, конференц-связь и т.д.

TAS также обеспечивает сервисную логику для обращения к медиасерверам при необходимости воспроизведения оповещений и сигналов прохождения вызова. Если вызов инициирован или терминирован в ТфОП, сервер TAS обеспечивает сигнализацию SIP к функции MGCF для выдачи команды медиашлюзам на преобразование битов речевого потока TDM (ТфОП) в поток IP RTP и направление его на IP-адрес соответствующего IP-телефона. абонентский коммутатор концентратор ngn

TAS обрабатывает триггерные точки вызова IN в соответствии с моделью телефонного вызова. При достижении вызовом триггерной точки TAS приостанавливает обработку вызова и проверяет профиль абонента (где содержится информация о том, какие должны быть задействованы серверы приложений) на необходимость выполнения дополнительных услуг. TAS формирует управляющее сообщение ISC (SIP IP Multimedia Service Control) и передает управление вызовом соответствующему серверу приложений. Этот механизм может быть использован для вызова как унаследованных сервисов IN, так и новых сервисов на базе SIP.

В одном сообщении IMS могут содержаться данные о нескольких TAS, предоставляющих определенные услуги различным типам абонентских устройств. Например, один сервер TAS предоставляет услуги IP Centrex (частные планы нумерации, общие справочники, автоматическое распределение вызовов и т.д.), другой сервер поддерживает УАТС и предоставляет услуги VPN. Взаимодействие нескольких серверов приложений осуществляется посредством сигнализации SIP-I для завершения вызовов между абонентскими устройствами различных классов.

Функция коммутации услуг IM-SSF.

Функция коммутации услуг IM-SSF (IP Multimedia ? Services Switching Function) обеспечивает взаимодействие сообщения SIP с соответствующими сообщениями CAMEL, ANSI-41, подсистем INAP (Intelligent Network Application Protocol) или TCAP (Transaction Capabilities Application Part). Это взаимодействие позволяет поддерживаемым IMS IP-телефонам получать доступ к сервисам определения имени вызывающей стороны, бесплатного номера 800, переноса локального номера, и др.

Дополнительные серверы телефонных приложений.

Прикладной уровень может также содержать автономные независимые серверы, предоставляющие дополнительные услуги в любой стадии вызова посредством триггеров. К таким услугам относятся набор номера, переадресация и установление конференц-связи щелчком мыши, услуги голосовой почты, услуги интерактивного речевого взаимодействия (IVR), VoIP VPN, предоплаченный биллинг, блокирование входящих и исходящих вызовов.

Другие серверы приложений.

На прикладном уровне также могут находиться серверы приложений SIP, не использующие модель телефонного вызова. Такие серверы взаимодействуют с клиентами абонентских устройств для предоставления сервисов IM, PTT, сервисов присутствия и т.п. Реализация сервисов на базе SIP (нетелефонных сервисов) в общей архитектуре IMS позволяет осуществлять взаимодействие двух видов сервисов и создавать новые смешанные услуги. В качестве примера можно привести вывод на дисплей списка абонентов с указанием статуса присутствия в сети, причем набор номера и доступ к другим услугам (телефония, IM, PTT) осуществляется щелчком мыши. Другой пример ? использование одного предоплаченного счета для оплаты услуг телефонии и видео по запросу.

Шлюз открытого сервисного доступа OSA-GW.

Гибкость архитектуры IMS позволяет сервис-провайдерам добавлять сервисы в сеть VoIP путем взаимодействия с действующими приложениями или же путем интеграции собственных или разработанных третьими фирмами серверов приложений на базе SIP. Кроме того, сервис-провайдеры могут предоставить возможность своим клиентам разрабатывать и внедрять сервисы, задействующие ресурсы сети VoIP. Например: предприятие может реализовать сервис автоматической генерации речевого или мгновенного сообщения о доставке заказа; триггером такого сообщения является информация о местоположении курьера, передаваемая посредством карманного компьютера. Однако зачастую работающие на таких предприятиях разработчики не знакомы с протоколами телефонной сигнализации (SS7, ANSI41, CAMEL, SIP, ISDN и т.д.), хотя и имеют образование в области информационных технологий. Для решения этой проблемы Форум Parlay в тесном сотрудничестве с 3GPP и ETSI разработал прикладной программный интерфейс Parlay API для организации взаимодействия с телефонными сетями [4]. Взаимодействие SIP и Parlay API осуществляется посредством шлюза OSA-GW (Open Services Access ? Gateway), который входит в прикладной уровень архитектуры 3GPP IMS. Другие прикладные серверы, как говорилось выше, обеспечивают взаимодействие между SIP и протоколами телефонии (ANSI-41, CAMEL, INAP, TCAP, ISUP и т.д.). Шлюз OSA-GW позволяет корпоративным приложениям на базе Parlay получать доступ к информации о присутствии и состоянии вызова, устанавливать и разрывать сеансы связи, независимо управлять сегментами вызова (соединениями с вызывающей и вызываемой сторонами). Шлюз OSA-GW реализует интерфейс Parlay Framework, который позволяет корпоративным серверам приложений регистрироваться в сети и управляет доступом к сетевым ресурсам.

6.2 Развитие архитектуры IMS

Архитектура IMS определена в стандартах 3GPP (3rd Generation Partnership Project), Европейского института стандартов связи ETSI и Форума Parlay. На рис.13 представлен упрощенный вариант архитектуры IMS.

Большинство из описанных в предыдущих разделах сервисов являлись узкополосными сервисами передачи голоса и данных. Однако сигнализация SIP и архитектура IMS поддерживают и широкополосные мультимедийные сервисы, такие как вещательное ТВ с многоадресными (IP multicast) видеопотоками, видео по запросу, видеонаблюдение, видеотелефония, видеоконференцсвязь, виртуальные лекционные залы и многое другое. Для реализации таких сервисов в сети должны быть установлены дополнительные мультимедийные серверы приложений и абонентские устройства (см. рис.14).

Рисунок 13 - Упрощенный вариант архитектуры IMS

Рисунок 14 - Дополнительные услуги IMS

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

Необходимо расширение архитектуры IMS, которая обеспечила бы поддержку расширенного спектра услуг. Многие современные абонентские устройства VoIP, например, IP-УАТС, не поддерживают сигнализацию SIP, используя обычно протокол H.323. Интегрированные устройства доступа IAD с поддержкой VoIP поверх DSL часто используют протокол MGCP.

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

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

7. Расчет транспортной пакетной сети с использованием технологии NGN